# IT-Fehleranalyse & Troubleshooting # Inhaltsangabe / Übersicht ### **IT-Praxiswissen – verbindliche Inhaltsübersicht** **Status: alleinige Referenz für die weitere Ausarbeitung** Diese Inhaltsübersicht ersetzt alle früheren Übersichten, provisorischen Nummerierungen und frei fortgesetzten Seitenfolgen. Verbindliche Regeln: - Jede BookStack-Seite erhält genau die hier angegebene Nummer und exakt den hier angegebenen Titel. - Eine Nummer darf nicht frei ergänzt, verschoben oder doppelt vergeben werden. - Neue Seiten werden zuerst in diese Inhaltsübersicht aufgenommen und erst danach ausgearbeitet. - Unterpunkte innerhalb einer Seite dürfen als `x.y.1`, `x.y.2` und so weiter nummeriert werden. Sie sind keine eigenständigen BookStack-Seiten. - Frühere Entwürfe bleiben nur verwendbar, wenn sie einem Titel dieser Übersicht eindeutig zugeordnet und vollständig neu nummeriert wurden. - Die frühere Seite **„3.6 Erstdiagnose, Lösung und funktionale Eskalation“** wird verbindlich zu **1.6 Erstdiagnose, Lösung und funktionale Eskalation**. - Die frühere Seite **„8.5 macOS – Prozesse, Dienste, Logs und Ressourcen diagnostizieren“** wird verbindlich zu **14.1 macOS – Prozesse, Dienste, Logs und Ressourcen diagnostizieren**. Auch alle internen Unterpunkte müssen von `8.5.x` auf `14.1.x` geändert werden. - Kapitel 8 besitzt ausschließlich die Seiten 8.1 bis 8.4. Eine Seite 8.5 existiert nicht. Nach 8.4 folgt 9.1. --- ### **Kapitel 1 – Methodik, Dokumentation und Eskalation** - **1.1 Zweck, Aufbau und Grundregeln der Fehleranalyse** - **1.2 Störung aufnehmen und Benutzer gezielt befragen** - **1.3 Umfang, Auswirkung, Dringlichkeit und Priorität bestimmen** - **1.4 Timeline, letzte Änderungen und Beweise sichern** - **1.5 Hypothesen bilden und Diagnosemethoden auswählen** - **1.6 Erstdiagnose, Lösung und funktionale Eskalation** - **1.7 Kontrollierte Änderungen, Risiko und Rollback** - **1.8 Verifikation, Nachkontrolle und Abschluss** - **1.9 Root Cause Analysis, Five Whys und Fehlerbaum** - **1.10 Ticketdokumentation, Eskalationspaket und Post-Incident Review** --- ### **Kapitel 2 – Grundwerkzeuge und Diagnosebefehle** - **2.1 Werkzeugauswahl, Sicherheitskennzeichnungen und Platzhalter** - **2.2 Windows-Netzwerkbefehle** - **2.3 PowerShell für die Netzwerk- und Systemdiagnose** - **2.4 Linux-Netzwerk- und Systemwerkzeuge** - **2.5 macOS-Netzwerkdiagnose** - **2.6 Windows – Prozesse, Dienste, Logs und Ressourcen diagnostizieren** - **2.7 Linux – Prozesse, Dienste, Logs und Ressourcen diagnostizieren** - **2.8 Wireshark und TShark** - **2.9 tcpdump und Capture-Filter** - **2.10 Nmap im autorisierten Netzwerk** - **2.11 iPerf3 für kontrollierte Durchsatztests** - **2.12 curl für Web-, API- und Portdiagnosen** - **2.13 OpenSSL für TLS- und Zertifikatsdiagnosen** - **2.14 Microsoft Sysinternals** - **2.15 Protokolle lesen und Ereignisse zeitlich korrelieren** - **2.16 Monitoringdaten, Baselines und Zähler interpretieren** - **2.17 Paketmitschnitte, Debuglogs und Datenschutz** - **2.18 Netzwerkgeräte, Messgeräte und Out-of-Band-Werkzeuge** --- ### **Kapitel 3 – Strom, Hardware und physische Verbindung** - **3.1 Gerät ohne Strom oder ohne Startfunktion** - **3.2 Netzteil, Steckdose, PDU und USV prüfen** - **3.3 Kupferkabel, Kategorien und Leitungslängen** - **3.4 Netzwerkdose, Patchfeld und Patchweg prüfen** - **3.5 Switchport, Netzwerkkarte und Linkstatus prüfen** - **3.6 Link Flapping, Geschwindigkeit und Duplex** - **3.7 CRC-, FCS- und Übertragungsfehler** - **3.8 SFP-Module, Glasfasertypen und Kompatibilität** - **3.9 TX/RX, Faserreinigung und optische Leistung** - **3.10 PoE-Klasse, Leistungsbedarf und PoE-Budget** - **3.11 Temperatur-, Lüfter-, Netzteil- und Hardwarealarme** - **3.12 Systematischer Diagnoseablauf für physische Fehler** --- ### **Kapitel 4 – Ethernet, Switching und VLAN** - **4.1 Ethernet-Grundlagen und MAC-Adresslernen** - **4.2 Access-Ports und VLAN-Zuordnung** - **4.3 Trunks, Tagged, Untagged, PVID und Native VLAN** - **4.4 Voice VLAN und gerätespezifische VLAN-Zuweisung** - **4.5 Fehlende VLANs und unterbrochene Layer-2-Pfade** - **4.6 Spanning Tree und unerwartet blockierte Ports** - **4.7 Layer-2-Schleifen, Broadcast Storms und Root Bridge** - **4.8 BPDU Guard, Root Guard, Err-Disabled und Port Security** - **4.9 MAC-Flapping, doppelte MAC-Adressen und fehlendes MAC-Learning** - **4.10 LACP und Port-Channel-Fehler** - **4.11 MTU, Jumbo Frames, Queue Drops und Microbursts** - **4.12 Multicast und IGMP Snooping** - **4.13 DHCP Snooping und Dynamic ARP Inspection** - **4.14 LLDP, CDP und Abgleich mit der Netzdokumentation** - **4.15 Systematischer Diagnoseablauf für Switching und VLAN** --- ### **Kapitel 5 – IPv4, IPv6, ARP, NDP und Routing** - **5.1 IP-Konfiguration vollständig erfassen und bewerten** - **5.2 Keine IP-Adresse oder APIPA-Adresse** - **5.3 Statische IP-Adresse, Subnetzmaske und Standardgateway** - **5.4 Doppelte IPv4-Adresse, ARP und Proxy ARP** - **5.5 IPv6-Adressierung, SLAAC und DHCPv6** - **5.6 Router Advertisements und NDP** - **5.7 Routingtabelle, Default Route, spezifische Route und Metrik** - **5.8 Mehrere Gateways, Policy-Based Routing und VRF** - **5.9 Routing Loop, Blackhole und asymmetrisches Routing** - **5.10 Rückroute, ICMP, Fragmentierung und Path-MTU-Discovery** - **5.11 NAT, Source NAT, Hairpin NAT und Portweiterleitung** - **5.12 Überlappende Netze zwischen Standorten und VPNs** - **5.13 Systematischer Diagnoseablauf für IP und Routing** --- ### **Kapitel 6 – DHCP** - **6.1 DHCP-Grundlagen und DORA-Ablauf** - **6.2 DHCP-Clientdienst und DHCP-Serverdienst** - **6.3 Scope, Adresspool, Ausschlussbereich und Erschöpfung** - **6.4 Reservierungen, Adresskonflikte und BAD\_ADDRESS** - **6.5 DHCP Relay, IP Helper, GIADDR und VLAN-Zuordnung** - **6.6 UDP 67/68, Firewall und DHCP Snooping** - **6.7 DHCP-Optionen für Gateway, DNS, Suffix, PXE und VoIP** - **6.8 Rogue DHCP Server erkennen und eingrenzen** - **6.9 AD-Autorisierung und Bindung an Netzwerkschnittstellen** - **6.10 DHCP-Failover, Lease-Datenbank, Logs und alte Leases** - **6.11 Systematischer DHCP-Diagnoseablauf mit Paketmitschnitt** --- ### **Kapitel 7 – DNS und Namensauflösung** - **7.1 DNS-Grundlagen und vollständiger Auflösungspfad** - **7.2 Client-DNS, DNS-Server, Suffix, Kurzname und FQDN** - **7.3 A-, AAAA-, CNAME-, PTR- und SRV-Records** - **7.4 Zonen, Delegationen, Secondary Zones und Zonentransfers** - **7.5 Dynamische Updates und AD-integrierte Replikation** - **7.6 Forwarder und Conditional Forwarder** - **7.7 DNS-Cache, negative Antworten, hosts-Datei und Suchdomänen** - **7.8 Split-DNS, VPN-DNS, öffentliche Resolver, DoH und DoT** - **7.9 IPv6- und AAAA-Bevorzugung bei fehlerhaftem IPv6-Pfad** - **7.10 DNSSEC, EDNS, MTU sowie UDP und TCP 53** - **7.11 DNS-Leistung und fehlerhafte Reverse-Lookups** - **7.12 Systematischer DNS-Diagnoseablauf** --- ### **Kapitel 8 – Zeit, NTP und Zeitzonen** - **8.1 Systemzeit, UTC, Zeitzone und Zeitabweichung** - **8.2 NTP-Quellen, Erreichbarkeit, Synchronisationsstatus und Drift** - **8.3 Windows-Domänenzeit und Kerberos-Zeitfehler** - **8.4 Zeitfehler bei Linux, macOS, virtuellen Maschinen, Zertifikaten, Tokens und Logs** --- ### **Kapitel 9 – TCP, UDP, Ports, Firewall, NAT und Proxy** - **9.1 Ports, Sockets, Listener und gebundene Adressen** - **9.2 TCP-Handshake, Timeouts und TCP Reset** - **9.3 UDP-Diagnose und ICMP-Fehlermeldungen** - **9.4 Lokale Host-Firewall prüfen** - **9.5 Netzwerkfirewall, ACL-Reihenfolge und Stateful Inspection** - **9.6 Asymmetrische Pfade, Sessiontabellen und Connection Tracking** - **9.7 Ephemeral Ports und Verbindungsgrenzen** - **9.8 NAT, Portweiterleitung und Hairpin NAT im Datenpfad** - **9.9 Proxy, PAC-Datei und Proxy-Authentifizierung** - **9.10 TLS-Inspection und Zertifikatsfehler** - **9.11 Load Balancer, Healthchecks, Backends und Session Persistence** - **9.12 Reverse Proxy, Header, WAF und Rate Limits** - **9.13 Retransmissions, Zero Window und MTU-Probleme** - **9.14 Systematischer Diagnoseablauf: Ping funktioniert, Anwendung nicht** --- ### **Kapitel 10 – WLAN** - **10.1 WLAN-Grundlagen, Frequenzbänder und Sicherheitsverfahren** - **10.2 WLAN deaktiviert, falsche SSID oder falscher Schlüssel** - **10.3 WPA2-, WPA3- und Client-Inkompatibilitäten** - **10.4 802.1X, EAP, RADIUS und Zertifikate** - **10.5 Association, Authentifizierung und anschließender DHCP-Ablauf** - **10.6 Signalstärke, SNR, Reichweite und Dämpfung** - **10.7 Interferenz, Kanalauslastung, Kanalplanung und Kanalbreite** - **10.8 Regulatory Domain, DFS und Radarwechsel** - **10.9 Roaming, Sticky Clients und 802.11r/k/v** - **10.10 Band Steering, Load Balancing und Clientfähigkeiten** - **10.11 Versteckte SSID, Captive Portal und Client Isolation** - **10.12 VLAN-Zuordnung, AP-Uplink und PoE** - **10.13 AP- und Controllerauslastung, Treiber, Firmware und Energiesparen** - **10.14 Systematischer WLAN-Diagnoseablauf** --- ### **Kapitel 11 – WAN, Internet, VPN und Remotezugriff** - **11.1 Provider, Modem, ONT und PPPoE** - **11.2 Öffentliche IP-Adresse, CGNAT und Erreichbarkeit von außen** - **11.3 WAN-Latenz, Jitter, Paketverlust, Bandbreite und QoS** - **11.4 Site-to-Site-VPN und vollständiger Tunnelpfad** - **11.5 IKE Phase 1, Identität, PSK und Zertifikate** - **11.6 IPsec Phase 2, Proposal, Cipher, Hash, DH und PFS** - **11.7 UDP 500/4500, ESP, NAT-T, DPD und Rekey** - **11.8 Traffic Selectors, überlappende Netze, Tunnelroute und Rückroute** - **11.9 Client-VPN, Split Tunnel und Full Tunnel** - **11.10 VPN-DNS, DNS-Suffix, MTU und MSS** - **11.11 Benutzerberechtigung, MFA, Conditional Access und Clientprofil** - **11.12 RDP, SSH und WinRM über entfernte Netze** - **11.13 Systematischer Diagnoseablauf für WAN und VPN** --- ### **Kapitel 12 – Windows-Clients** - **12.1 Systemzustand, Version, Architektur und letzte Änderungen erfassen** - **12.2 Start-, Anmelde- und Benutzerprofilprobleme** - **12.3 Prozesse, Dienste, Autostarts und geplante Aufgaben** - **12.4 CPU, Arbeitsspeicher, Paging und Datenträgerauslastung** - **12.5 Treiber, Geräte-Manager und Energiesparfunktionen** - **12.6 Windows Update und ausstehende Neustarts** - **12.7 Systemdateien, DLLs, Registry und Anwendungsabhängigkeiten** - **12.8 Lokale Gruppen, NTFS-Rechte und effektive Berechtigungen** - **12.9 Antivirus, EDR, Firewall, Proxy und Zertifikatsspeicher** - **12.10 BitLocker und TPM** - **12.11 Drucker, Spooler, Warteschlangen und Treiber** - **12.12 DNS-, Winsock- und Netzwerkstackprobleme** - **12.13 Anwendungsabsturz, Bluescreen, LiveKernelEvent und Speicherabbild** - **12.14 Systematischer Diagnoseablauf für Windows-Clients** --- ### **Kapitel 13 – Windows Server, Active Directory und Identität** - **13.1 AD-Rollen, Standorte, Domänen und Abhängigkeiten** - **13.2 Domain Controller Locator und AD-DNS** - **13.3 DCDiag, Erreichbarkeit, Advertising und Dienste** - **13.4 AD-Replikation, Replikationslatenz und Objektprobleme** - **13.5 SYSVOL, NETLOGON und DFS-R** - **13.6 FSMO-Rollen und Global Catalog** - **13.7 Secure Channel, Trust und Computerkonto** - **13.8 Benutzerkonto, Kennwort, Sperre und Ablauf** - **13.9 Kerberos-Tickets, SPN und Delegation** - **13.10 LDAP, LDAPS und Zertifikate** - **13.11 Gruppenmitgliedschaften und Zugriffstoken** - **13.12 GPO-Verarbeitung, Priorität, Vererbung und Filter** - **13.13 Logon Scripts, Laufwerkszuordnungen und SYSVOL-Zugriff** - **13.14 AD-Datenbank, Speicherplatz und Replikationsqueues** - **13.15 Systematischer Diagnoseablauf für Active Directory** --- ### **Kapitel 14 – macOS-Clients** - **14.1 macOS – Prozesse, Dienste, Logs und Ressourcen diagnostizieren** - **14.2 App-Start, Hänger, Abstürze, Sample und Spindump** - **14.3 launchd, LaunchAgents und LaunchDaemons** - **14.4 Unified Logging, Konsole, Crash- und Panic-Berichte** - **14.5 CPU, Speicherdruck, Komprimierung und Swap** - **14.6 APFS, Datenträger, Snapshots und Speicherplatz** - **14.7 Unix-Berechtigungen, ACLs, Dateiflags und erweiterte Attribute** - **14.8 TCC, Datenschutzfreigaben und geschützte Ressourcen** - **14.9 Gatekeeper, App-Signatur und Quarantäne** - **14.10 Anmeldeobjekte, Hintergrunddienste und Systemerweiterungen** - **14.11 Netzwerk- und externe Abhängigkeiten von Apps** - **14.12 Sicherer Modus, Apple Diagnose und macOS-Wiederherstellung** - **14.13 Systematischer Diagnoseablauf für macOS-Clients** --- ### **Kapitel 15 – Datei-, Freigabe-, Rechte- und Druckdienste** - **15.1 SMB-Erreichbarkeit, DNS und TCP 445** - **15.2 Freigaberechte, NTFS-Rechte und effektiver Zugriff** - **15.3 Gruppen, Access-Based Enumeration, Kerberos, NTLM und SPN** - **15.4 DFS Namespace, DFS-R und Offline Files** - **15.5 Dateisperren, Pfade, Zeichen, Quotas und voller Datenträger** - **15.6 Eigentümer, ACLs, SMB-Version und Signing** - **15.7 Netzwerkdrucker, TCP/IP-Port, DNS und SNMP-Status** - **15.8 Spooler, CUPS, Warteschlangen, Treiber und Druckrechte** - **15.9 Papier-, Toner-, Mechanik- und Gerätestörungen** - **15.10 Systematischer Diagnoseablauf für Datei- und Druckdienste** --- ### **Kapitel 16 – Linux-Server** - **16.1 Systemzustand, Distribution, Kernel und letzte Änderungen erfassen** - **16.2 systemd Units, Abhängigkeiten und Startreihenfolge** - **16.3 Konfigurationssyntax, Ports und Listener** - **16.4 Benutzer, Gruppen, Dateirechte und ACLs** - **16.5 SELinux und AppArmor** - **16.6 Pakete, Repositories, Bibliotheken und Abhängigkeiten** - **16.7 Kernel, Treiber, Prozesse, OOM Killer und Hänger** - **16.8 CPU, Load, Arbeitsspeicher und Swap** - **16.9 Dateisysteme, Inodes, Mounts und Read-only-Zustände** - **16.10 LVM, RAID, I/O-Wait und Datenträgerleistung** - **16.11 DNS, Routing, Policy Routing und Firewall** - **16.12 Cron, systemd Timer, Logrotation und Zeitdienste** - **16.13 SSH, Schlüssel, Berechtigungen und Zugriffsregeln** - **16.14 Systematischer Diagnoseablauf für Linux-Server** --- ### **Kapitel 17 – Virtualisierung, Cluster und Hochverfügbarkeit** - **17.1 Hypervisor, virtuelle Maschine und Ressourcenpfad** - **17.2 Managementdienste und nicht startende virtuelle Maschinen** - **17.3 CPU-Überbelegung, CPU Ready, NUMA und CPU-Pinning** - **17.4 RAM-Überbelegung, Ballooning, Swapping und Memory Pressure** - **17.5 Datastore, Thin Provisioning, Storage-Latenz und volle Speicherpools** - **17.6 Snapshots, Consolidation und gesperrte virtuelle Festplatten** - **17.7 Virtuelle Switches, Bridges, VLANs, Teaming und virtuelle MAC-Adressen** - **17.8 Hypervisor-Tools und konkurrierende Zeitsynchronisation** - **17.9 Live Migration und gemeinsamer Speicher** - **17.10 Quorum, Witness und Split Brain** - **17.11 HA, Failover, Fencing und STONITH** - **17.12 Replikation, Backupbelastung und systematischer Diagnoseablauf** --- ### **Kapitel 18 – Docker, Container und Kubernetes** - **18.1 Containerarchitektur, Laufzeit und Basiszustand** - **18.2 Containerstart, Exit-Code, Restart Loop und Healthcheck** - **18.3 Images, Tags, CPU-Architektur und Registryzugriff** - **18.4 Umgebungsvariablen, Secrets, Configs und Startabhängigkeiten** - **18.5 Veröffentlichte Ports, Hostports und Listener** - **18.6 Bridge-, benutzerdefinierte und Overlay-Netze** - **18.7 Container-DNS, Namen, Aliase und Compose-Kollisionen** - **18.8 Volumes, Bind-Mounts, UID, GID, Speicherplatz und Inodes** - **18.9 Proxy, DNS, Internetzugriff und MTU im Containerpfad** - **18.10 Ressourcenlimits, OOM, CPU Throttling, Logs und Container-Runtime** - **18.11 Kubernetes Pod Pending, CrashLoopBackOff und ImagePullBackOff** - **18.12 Kubernetes Service, Endpoint, Ingress, DNS und Network Policy** - **18.13 Persistent Volumes, Nodes, CNI, CSI, Zertifikate und Kubeconfig** - **18.14 Systematischer Diagnoseablauf für Container und Kubernetes** --- ### **Kapitel 19 – Storage, RAID, NAS, SAN und Backup** - **19.1 Speicherplatz, Inodes, Quotas, Thin Pools und Snapshots** - **19.2 Datenträgerfehler und SMART-Warnungen** - **19.3 RAID, Rebuild, Controller, Cache und Batterie** - **19.4 HBA, Multipath, iSCSI, LUN Masking und Zoning** - **19.5 NFS, SMB, NAS-Netzwerk, Bonding, VLAN und MTU** - **19.6 Dateisystemfehler, Read-only-Zustand und gesperrte Volumes** - **19.7 IOPS, Datenträgerlatenz und Queue Depth** - **19.8 Backupjob, Ziel, Repository und Zugangsdaten** - **19.9 Retention, Snapshots und anwendungskonsistente Sicherungen** - **19.10 Restore-Test, RPO, RTO und Integritätsnachweis** - **19.11 Replikation sowie immutable und offline Sicherungskopien** - **19.12 Systematischer Diagnoseablauf für Storage und Backup** --- ### **Kapitel 20 – Web, API, TLS, Reverse Proxy und Load Balancer** - **20.1 Vollständiger Web- und API-Anfragepfad** - **20.2 DNS, TCP 80/443, Listener und Zielerreichbarkeit** - **20.3 Zertifikatsgültigkeit, Hostname, SAN, Kette und CA** - **20.4 TLS-Version, Cipher, SNI, OCSP und CRL** - **20.5 Reverse Proxy, Zielhost, Zielport, Header und Redirects** - **20.6 HTTP 400, 401, 403, 404, 405, 408 und 429** - **20.7 HTTP 500, 502, 503, 504, Backends und Timeouts** - **20.8 Load-Balancer-Healthchecks und Session Persistence** - **20.9 API-Key, OAuth, Token und Clientzertifikat** - **20.10 Cookies, SameSite, Secure, CORS und WebSocket** - **20.11 Größenlimits, Uploadlimits, Rate Limits und Verbindungsgrenzen** - **20.12 Cache, CDN, WAF und Anwendungsprotokolle** - **20.13 Systematischer Diagnoseablauf für Web und API** --- ### **Kapitel 21 – Datenbanken, Queues und Backenddienste** - **21.1 Host, Port, Datenbankname, DNS und Firewall** - **21.2 Zugangsdaten, Secrets, TLS und Netzwerkberechtigungen** - **21.3 Connection Pool und maximale Verbindungen** - **21.4 Langsame Abfragen und fehlende Indizes** - **21.5 Locks, Deadlocks und lange Transaktionen** - **21.6 Replikationsverzug und Read-only-Replikate** - **21.7 Storage-Latenz, Transaction Log, WAL und Temp-Bereich** - **21.8 Schema, Migration, Zeichensatz und Collation** - **21.9 Backups und blockierende Wartungsjobs** - **21.10 Message Queues, Consumer, Poison Messages und Retry Storms** - **21.11 Cache-Dienste und veraltete Cache-Inhalte** - **21.12 Systematischer Diagnoseablauf für Backenddienste** --- ### **Kapitel 22 – E-Mail, Collaboration und Cloud/SaaS** - **22.1 SMTP-Pfad, Ports und Smarthost** - **22.2 SMTP-Authentifizierung, TLS, Relay, Queue und Empfängerfehler** - **22.3 MX, SPF, DKIM, DMARC und Reverse DNS** - **22.4 Spam, Quarantäne, Transportregeln und Größenlimits** - **22.5 Postfach, Lizenz, Quota, Freigabe und Kalenderberechtigungen** - **22.6 Service Health, Cloudregion und SaaS-Endpunkte** - **22.7 Tenant, Rollen, IAM, Conditional Access und MFA** - **22.8 Token, Sitzung und veraltete Authentifizierung** - **22.9 API-Quotas und Cloud-Limits** - **22.10 Security Groups, NSG, NACL, Route Tables und Cloud-Firewall** - **22.11 Private Endpoints, Private DNS und Proxyzugriff** - **22.12 Systematischer Diagnoseablauf für E-Mail und Cloud/SaaS** --- ### **Kapitel 23 – Performance und „alles ist langsam“** - **23.1 Leistung objektiv messen und Baselines verwenden** - **23.2 Clientzeit, Netzwerkzeit, Serverzeit und Backendzeit trennen** - **23.3 CPU-Sättigung, Single-Thread-Limit und Scheduling** - **23.4 RAM-Druck, Paging, Swapping und NUMA** - **23.5 I/O-Wait, Datenträgerlatenz und Queue Depth** - **23.6 Latenz, Jitter, Paketverlust, Durchsatz und Retransmissions** - **23.7 Speed, Duplex, Oversubscription, Queue Drops und Microbursts** - **23.8 WLAN-Airtime, Signal, SNR und Kanalauslastung** - **23.9 DNS-, Proxy- und TLS-Latenz** - **23.10 Anwendung, Connection Pool, Datenbanklocks und Queues** - **23.11 Backups, Scans, Wartungsjobs, Snapshots und Logging Storms** - **23.12 Browser, Add-ons, Antivirus und lokale Clientleistung** - **23.13 Lastverteilung, synthetische Messungen und APM** - **23.14 Intermittierende Leistungsfehler und gemeinsame Timeline** - **23.15 Systematischer Diagnoseablauf für Performanceprobleme** --- ### **Kapitel 24 – Security-Vorfälle und verdächtiges Verhalten** - **24.1 Security-Verdacht erkennen und Beweise vor Veränderungen sichern** - **24.2 Ungewöhnliche Anmeldung, Brute Force und Password Spray** - **24.3 Kontoübernahme, Administratorkonten und Gruppenänderungen** - **24.4 Verdächtige Prozesse, Autostarts und PowerShell-Aktivität** - **24.5 Malware- und Ransomware-Verdacht** - **24.6 Ungewöhnlicher Netzwerkverkehr, DNS-Tunneling und Datenabfluss** - **24.7 Rogue DHCP, Rogue DNS und unbekannte Access Points** - **24.8 Unerwartete Ports, manipulierte Dateien und deaktivierte Schutzsysteme** - **24.9 Loglöschung, kompromittierte Zertifikate, Secrets und Cloudtokens** - **24.10 Triage, kontrollierte Isolation und Eindämmung** - **24.11 Bereinigung, Wiederherstellung und Nachkontrolle** - **24.12 Forensische Sicherung und Chain of Custody** - **24.13 Kommunikation, Eskalation und Post-Incident Review** --- ### **Kapitel 25 – Monitoring, Alarmierung und Dokumentation** - **25.1 Monitoringarchitektur, Monitoringserver und Agenten** - **25.2 SNMP, SNMPv3, OIDs, Counter und Engine-ID** - **25.3 Pollingintervalle, Baselines und Schwellenwerte** - **25.4 Alarmflut, Abhängigkeiten und Folgealarme** - **25.5 Dienstprüfung statt reiner Ping-Prüfung** - **25.6 Ende-zu-Ende- und synthetische Prüfungen** - **25.7 Logs, Loglevel, Rotation, Aufbewahrung und Zeitzonen** - **25.8 CMDB, Netzplan und Konfigurationsbackup** - **25.9 Zuordnung von Alarm, Ticket, Change und Runbook** - **25.10 Backupüberwachung und tatsächlich geprüfter Restore** - **25.11 Systematischer Diagnoseablauf für Monitoringfehler** --- ### **Kapitel 26 – Spezialdienste** - **26.1 VoIP-Datenpfad, SIP und RTP** - **26.2 PoE, Voice VLAN, DHCP, DNS und NTP für VoIP** - **26.3 NAT, QoS, Jitter, Paketverlust und einseitiges Audio** - **26.4 RDP, NLA, Zertifikate, Rechte, Sitzungen und Lizenzierung** - **26.5 SSH, Hostkeys, Benutzerschlüssel und Zugriffsregeln** - **26.6 PXE, DHCP Relay, Bootoptionen, TFTP, HTTP und Bootdateien** - **26.7 MDM-Enrollment, Zertifikate, APNs, Compliance und Token** - **26.8 Kameras und IoT – PoE, VLAN, Multicast, Zeit und proprietäre Ports** - **26.9 Videokonferenzen – Bandbreite, QoS, UDP, Proxy, TURN, STUN und ICE** - **26.10 Kompakter Diagnoseablauf für Spezialdienste** --- ### **Kapitel 27 – Schnellreferenzen und Runbooks** - **27.1 Runbook – Ein Client hat kein Netzwerk** - **27.2 Runbook – Mehrere Benutzer oder ein Standort haben kein Netzwerk** - **27.3 Runbook – Name funktioniert nicht, direkte IP funktioniert** - **27.4 Runbook – Ping funktioniert, Anwendung funktioniert nicht** - **27.5 Runbook – Netzwerk ist langsam** - **27.6 Runbook – Fehler tritt nur zeitweise auf** - **27.7 Runbook – Anmeldung an der Domäne funktioniert nicht** - **27.8 Runbook – Server ist langsam** - **27.9 Standardvorlage für jede Fehlerseite** - **27.10 Sicherheits-, Datenschutz- und Betriebsregeln für Diagnosebefehle** - **27.11 Abschluss-, Verifikations- und Dokumentationscheckliste** - **27.12 Schnellreferenz der wichtigsten Werkzeuge und Befehle** --- ### **Verbindliche Fortsetzungsregel** Die Ausarbeitung erfolgt ausschließlich in der Reihenfolge dieser Übersicht. Nach einer fertiggestellten Seite folgt immer die unmittelbar nächste vorhandene Nummer. Existiert in einem Kapitel keine weitere Seite, beginnt das nächste Kapitel mit `.1`. Beispiel für den Übergang von Kapitel 8 zu Kapitel 9: `8.3 → 8.4 → 9.1` Nicht zulässig ist: `8.3 → 8.4 → 8.5` Eine Änderung dieser Übersicht ist nur dann gültig, wenn zuerst dieses Referenzdokument vollständig aktualisiert wird. Eine spontan erzeugte Seite verändert die Inhaltsübersicht nicht. # 1. Grundlagen der systematischen Fehleranalyse # 1.0 Diagnoseansatz – Systematische Fehleranalyse **Zweck dieser Seite** Diese Seite beschreibt die grundlegende Denk- und Arbeitsweise bei der professionellen IT-Fehleranalyse. Sie ist die Einführungsseite des Kapitels. Konkrete Befehle, Befundformulare und detaillierte Diagnoseabläufe folgen auf den nächsten Seiten. --- **Was bedeutet systematische Fehleranalyse?** Systematische Fehleranalyse bedeutet, eine Störung nicht durch zufälliges Ausprobieren zu bearbeiten. Stattdessen wird: 1. das sichtbare Problem beschrieben; 2. der betroffene Bereich eingegrenzt; 3. der technische Datenpfad verstanden; 4. eine mögliche Ursache als Hypothese formuliert; 5. die Hypothese mit einem gezielten Test geprüft; 6. nur die nachgewiesene Ursache behoben; 7. die vollständige Funktion anschließend verifiziert. Das Ziel ist nicht nur, das Symptom kurzfristig zu beseitigen. Die tatsächliche technische Ursache soll gefunden, behoben und dokumentiert werden. --- **Ein Symptom ist keine Ursache** Eine Störung wird zunächst meistens nur als Symptom wahrgenommen. Beispiele: | Symptom | Mögliche Ursachen | | --- | --- | | „Das Internet funktioniert nicht“ | Interface, Kabel, VLAN, DHCP, Gateway, DNS, Proxy, Firewall, VPN oder Provider | | „Der Server ist langsam“ | CPU, RAM, Datenträger, Netzwerk, DNS, Anwendung, Datenbank, Backup oder Hypervisor | | „Die Anmeldung funktioniert nicht“ | Konto, Passwort, DNS, Uhrzeit, Kerberos, Domain Controller, MFA oder Berechtigungen | | „Die Webseite ist nicht erreichbar“ | DNS, Routing, Firewall, TCP-Port, TLS, Proxy, Webserver oder Anwendung | | „Der Container startet nicht“ | Image, Architektur, Konfiguration, Port, Volume, Rechte, Abhängigkeit oder Ressourcenlimit | Aus einem Symptom dürfen deshalb nicht sofort konkrete Reparaturmaßnahmen abgeleitet werden. --- **Typische Denkfehler** **Vorschnelle Festlegung** Nach dem ersten Hinweis wird sofort eine Ursache angenommen. Beispiel: > Der Hostname funktioniert nicht. Also ist der DNS-Server ausgefallen. Der DNS-Server könnte erreichbar sein und trotzdem einen falschen Record liefern. Ebenso könnten DNS-Suffix, Clientcache, hosts-Datei, VPN-DNS oder Split-DNS die Ursache sein. **Bestätigungsfehler** Es werden nur noch Informationen gesucht, welche die eigene Vermutung bestätigen. Widersprechende Befunde werden ignoriert. **Korrelation mit Ursache verwechseln** Ein Fehler tritt nach einem Update auf. Daraus wird geschlossen, dass das Update die Ursache sein muss. Die zeitliche Nähe ist ein wichtiger Hinweis, aber noch kein Nachweis. **Nur die eigene Komponente untersuchen** Der Clientadministrator untersucht nur den Client, der Netzwerkadministrator nur den Switch und der Serveradministrator nur den Server. Eine Verbindung funktioniert jedoch nur, wenn der gesamte Datenpfad funktioniert. **Erfolgreichen Einzeltest überbewerten** Ein erfolgreicher Ping beweist nicht, dass DNS, TCP-Port, TLS, Authentifizierung oder Anwendung funktionieren. **Mehrere Änderungen gleichzeitig durchführen** Werden gleichzeitig DNS geändert, Firewallregeln angepasst und Dienste neu gestartet, kann anschließend nicht mehr festgestellt werden, welche Maßnahme tatsächlich wirksam war. **Neustart mit Fehlerbehebung verwechseln** Ein Neustart kann einen fehlerhaften Zustand vorübergehend beseitigen. Die Ursache ist dadurch nicht automatisch bekannt oder dauerhaft behoben. --- **Grundlegender Diagnosekreislauf** `Symptom → Eingrenzung → Datenpfad → Hypothese → Test → Befund → Korrektur → Verifikation → Dokumentation` Nach jedem Test wird entschieden: - Hypothese bestätigt; - Hypothese widerlegt; - Ergebnis noch nicht eindeutig; - weiterer Test erforderlich. Erst eine bestätigte Hypothese führt zu einer konkreten Korrektur. --- **Die wichtigsten Eingrenzungsmethoden** | Methode | Grundidee | Typischer Einsatz | | --- | --- | --- | | Bottom-up | Von Hardware und Verbindung zur Anwendung arbeiten | Link-, Kabel-, VLAN- und Netzwerkprobleme | | Top-down | Bei Benutzer und Anwendung beginnen | Anwendungs-, Zugriffs- und Authentifizierungsfehler | | Divide and Conquer | Datenpfad in Abschnitte teilen | Lange oder komplexe Verbindungswege | | Follow the Path | Anfrage und Antwort vollständig verfolgen | Routing, Firewall, NAT, Proxy und VPN | | Known Good Comparison | Mit funktionierendem System vergleichen | Einzelne Benutzer, Clients oder Ports | | Controlled Swap | Komponente kontrolliert austauschen | Kabel, Port, SFP, Netzteil oder Client | | Two-Sided Analysis | Sender und Empfänger gleichzeitig untersuchen | Paketverlust und Kommunikationsabbrüche | | Historical Comparison | Aktuellen Zustand mit früherem Zustand vergleichen | Änderungen, Updates und Performanceprobleme | Keine Methode ist grundsätzlich immer die richtige. Die Auswahl hängt vom Symptom und vom bekannten Datenpfad ab. --- **Technischen Datenpfad betrachten** Ein Dienst besteht häufig aus mehreren voneinander abhängigen Komponenten. Beispiel: `Benutzer → Client → Netzwerkinterface → Switch oder Access Point → VLAN → Gateway → Firewall → Server → Anwendung → Datenbank` Für jede Komponente muss geklärt werden: - Erreicht die Anfrage diese Stelle? - Wird die Anfrage angenommen? - Wird sie korrekt weitergeleitet? - Wird eine Antwort erzeugt? - Kommt die Antwort beim Absender an? Dadurch lässt sich der fehlerhafte Abschnitt schrittweise eingrenzen. --- **Sender, Empfänger, Hinweg und Rückweg** Eine vollständige Verbindungsanalyse betrachtet immer vier Bereiche: | Bereich | Fragestellung | | --- | --- | | Sender | Wird die Anfrage korrekt erzeugt und gesendet? | | Hinweg | Erreicht die Anfrage das Ziel? | | Empfänger | Nimmt das Ziel die Anfrage an und antwortet es? | | Rückweg | Erreicht die Antwort den ursprünglichen Sender? | Eine Anfrage kann den Server erreichen, obwohl die Antwort wegen einer fehlenden Rückroute, einer Firewall oder asymmetrischem Routing verloren geht. --- **Vergleich mit einem funktionierenden System** Ein bekannt funktionierendes Vergleichssystem ist häufig aussagekräftiger als eine allgemeine Vermutung. Verglichen werden können: - Benutzer; - Client; - Betriebssystemversion; - Netzwerkkonfiguration; - Switchport; - VLAN; - DNS-Server; - Routingtabelle; - Gruppenmitgliedschaften; - Richtlinien; - Zertifikate; - Softwareversionen; - Konfigurationsdateien. Entscheidend ist, möglichst nur einen Unterschied gleichzeitig zu untersuchen. --- **Beweise vor Veränderungen sichern** Viele technische Informationen sind flüchtig. Dazu gehören: - aktive Verbindungen; - Arbeitsspeicherinhalt; - Prozesse; - temporäre Fehlerzustände; - Interface-Counter; - Routing- und Nachbartabellen; - nicht gespeicherte Logs; - Paketmitschnitte; - Cluster- und Sessionzustände. Deshalb gilt: > Erst den ursprünglichen Zustand erfassen, danach verändern. Welche Informationen konkret gesichert werden, wird auf der Seite `1.4 Flüchtige Informationen und Beweise sichern` behandelt. --- **Eine Änderung pro Test** Jede Änderung muss eine konkrete Hypothese prüfen. Beispiel: > Hypothese: Der Client befindet sich im falschen VLAN. Geeigneter Test: > Switchport-Zuweisung und tatsächlich gelerntes VLAN mit einem funktionierenden Port vergleichen. Erst wenn die Hypothese bestätigt ist, wird die VLAN-Konfiguration korrigiert. Mehrere gleichzeitige Änderungen verhindern eine eindeutige Ursachenbestimmung. --- **Fehlerbehebung und Verifikation trennen** Eine ausgeführte Änderung ist noch keine bestätigte Lösung. Nach der Korrektur muss geprüft werden: - Ist das ursprüngliche Symptom verschwunden? - Funktioniert der tatsächliche Dienst? - Funktioniert die Verbindung in beide Richtungen? - Sind andere Benutzer oder Systeme weiterhin funktionsfähig? - Enthalten die Logs neue Fehler? - Befinden sich Monitoringwerte wieder im Normalbereich? - Wurden temporäre Diagnoseänderungen entfernt? Ein Fehler gilt erst dann als behoben, wenn die ursprüngliche Funktion vollständig getestet wurde. --- **Dokumentation als Teil der Fehlerbehebung** Eine vollständige Fehlerdokumentation enthält: - sichtbares Symptom; - betroffene Systeme und Benutzer; - Beginn und Dauer; - technische Ursache; - durchgeführte Tests; - eindeutige Befunde; - ausgeführte Korrektur; - mögliche Auswirkungen; - Rollback; - abschließende Verifikation; - Präventionsmaßnahme; - relevante Herstellerquelle. Die Dokumentation verhindert, dass derselbe Fehler später erneut vollständig untersucht werden muss. --- **Grundregeln** - Erst eingrenzen, dann verändern. - Ein Symptom ist keine Ursache. - Vermutungen werden als Hypothesen behandelt. - Ein einzelner erfolgreicher Test beweist nicht den gesamten Dienst. - Sender, Empfänger, Hinweg und Rückweg müssen betrachtet werden. - Vergleichssysteme müssen möglichst ähnlich sein. - Nur eine kontrollierte Änderung gleichzeitig durchführen. - Vor Veränderungen flüchtige Informationen sichern. - Eine Änderung ist erst nach erfolgreicher Verifikation eine Lösung. - Neustart und Reset ersetzen keine Ursachenanalyse. - Sicherheitsfunktionen dürfen nicht unkontrolliert umgangen werden. - Jede dauerhafte Korrektur benötigt Dokumentation und Prävention. --- **Seiten dieses Kapitels** - `1.0 Diagnoseansatz – Systematische Fehleranalyse` - `1.1 Störung strukturiert aufnehmen` - `1.2 Fehlerumfang mit Kreuztests bestimmen` - `1.3 Zeitpunkt und letzte Änderungen untersuchen` - `1.4 Flüchtige Informationen und Beweise sichern` - `1.5 Technischen Datenpfad dokumentieren` - `1.6 Grundbefehle für Windows, Linux und macOS` - `1.7 Logs und Zeitstempel richtig verwenden` - `1.8 Vergleich mit einem funktionierenden System` - `1.9 Hypothesen kontrolliert prüfen` - `1.10 Änderungen, Rollback und Verifikation` - `1.11 Eskalationspaket für Hersteller oder Provider` **Quellen** - [IBM – Systematischer Troubleshooting-Ansatz](https://www.ibm.com/docs/en/qradar-on-cloud?topic=support-techniques-troubleshooting-problem) - [Microsoft – Windows Networking Troubleshooting](https://learn.microsoft.com/en-us/troubleshoot/windows-client/networking/networking-overview) - [Microsoft – Windows Performance Troubleshooting](https://learn.microsoft.com/en-us/troubleshoot/windows-server/performance/troubleshoot-performance-problems-in-windows) - [Cisco – Switchport- und Interfaceprobleme](https://www.cisco.com/c/en/us/support/docs/switches/catalyst-6500-series-switches/12027-53.html) - [Wireshark User’s Guide](https://www.wireshark.org/docs/wsug_html_chunked/) - [NIST – Incident Response Recommendations](https://csrc.nist.gov/pubs/sp/800/61/r3/final) # 1.1 Störung strukturiert aufnehmen **Zweck dieser Seite** Diese Seite dient der vollständigen und einheitlichen Aufnahme einer IT-Störung. Bevor mit der technischen Diagnose begonnen wird, müssen das sichtbare Problem, der Zeitpunkt, die betroffenen Systeme und die verfügbaren Beweise dokumentiert werden. Eine gute Störungsaufnahme verhindert: - falsche Annahmen; - unnötige Tests; - wiederholte Rückfragen; - Verlust flüchtiger Informationen; - Veränderungen ohne dokumentierten Ausgangszustand; - unvollständige Eskalationen an andere Administratoren oder Hersteller. --- **Grundregel** Die Störung wird zunächst beschrieben, aber noch nicht bewertet. Beispiel: Nicht ausreichend: > Das Netzwerk funktioniert nicht. Besser: > Der Client erhält seit dem 30.07.2026 um 14:35 Uhr über Ethernet keine DHCP-Adresse. Windows verwendet stattdessen die IPv4-Adresse 169.254.18.24. Über WLAN erhält derselbe Client eine gültige Adresse und kann auf interne Dienste zugreifen. Die zweite Beschreibung enthält ein beobachtbares Symptom, einen Zeitpunkt, ein betroffenes Interface und einen funktionierenden Vergleich. --- **Die wichtigsten Informationen** | Information | Fragestellung | | --- | --- | | Melder | Wer hat die Störung gemeldet? | | Zeitpunkt | Wann wurde die Störung erstmals festgestellt? | | Letzter funktionierender Zustand | Wann funktionierte der Dienst zuletzt nachweislich? | | Betroffener Benutzer | Welcher Benutzer beobachtet das Problem? | | Betroffenes Gerät | Hostname, Gerätetyp und Betriebssystem | | Betroffener Dienst | Welche Anwendung, Verbindung oder Funktion ist gestört? | | Standort | Gebäude, Raum, Homeoffice, Außenstelle oder Cloud | | Netzwerkverbindung | Ethernet, WLAN, Mobilfunk oder VPN | | Fehlermeldung | Exakter und vollständiger Wortlaut | | Reproduzierbarkeit | Kann der Fehler gezielt erneut ausgelöst werden? | | Häufigkeit | Dauerhaft, gelegentlich, periodisch oder einmalig | | Auswirkung | Was kann der Benutzer oder das Unternehmen nicht durchführen? | | Workaround | Gibt es einen vorübergehend funktionierenden Alternativweg? | | Letzte Änderungen | Was wurde kurz vor dem Auftreten verändert? | | Beweise | Screenshots, Logs, Zeitstempel, Monitoring oder Paketmitschnitt | --- **Exakte Fehlermeldung erfassen** Fehlermeldungen dürfen nicht nur sinngemäß wiedergegeben werden. Dokumentiert werden: - vollständiger Wortlaut; - Fehlercode; - Event-ID; - HTTP-Status; - Uhrzeit; - betroffene Anwendung; - betroffener Vorgang; - sichtbare Details; - Screenshot, falls sinnvoll. Beispiel: Nicht ausreichend: > Anmeldung geht nicht. Besser: > Bei der Anmeldung erscheint um 08:14 Uhr die Meldung „Die Vertrauensstellung zwischen dieser Arbeitsstation und der primären Domäne konnte nicht hergestellt werden.“ Exakte Fehlermeldungen ermöglichen eine gezieltere Suche in Logs und Herstellerdokumentationen. --- **Zeitpunkt dokumentieren** Der genaue Zeitpunkt ist erforderlich, um Ereignisse verschiedener Systeme miteinander zu vergleichen. Dokumentiert werden: - Datum; - Uhrzeit; - Zeitzone; - Beginn der Störung; - letzter erfolgreicher Vorgang; - Zeitpunkt jedes reproduzierten Fehlers. Beispiel: > Fehler reproduziert am 30.07.2026 um 14:42:18 Uhr MESZ. Ungefähre Angaben wie „heute Morgen“ oder „vorhin“ reichen für eine Logkorrelation nicht aus. --- **Zeit und Systeminformationen erfassen** | Prüfung | Windows | Linux | macOS | | --- | --- | --- | --- | | Hostname | `[RO] hostname` | `[RO] hostname` | `[RO] hostname` | | Benutzerkontext | `[RO] whoami` | `[RO] whoami` | `[RO] whoami` | | Systemzeit | `[RO] Get-Date -Format o` | `[RO] date "+%Y-%m-%d %H:%M:%S %Z"` | `[RO] date "+%Y-%m-%d %H:%M:%S %Z"` | | Betriebssystem | `[RO] Get-CimInstance Win32_OperatingSystem \| Select-Object Caption,Version,BuildNumber` | `[RO] cat /etc/os-release` | `[RO] sw_vers` | | Laufzeit | `[RO] (Get-Date) - (Get-CimInstance Win32_OperatingSystem).LastBootUpTime` | `[RO] uptime` | `[RO] uptime` | | Letzter Systemstart | `[RO] Get-CimInstance Win32_OperatingSystem \| Select-Object LastBootUpTime` | `[RO] who -b` | `[RO] sysctl -n kern.boottime` | Diese Befehle verändern keine Konfiguration. --- **Betroffenes System erfassen** Für einen Client oder Server werden mindestens folgende Angaben benötigt: - Hostname; - Gerätetyp; - Hersteller und Modell, falls relevant; - Betriebssystem; - Betriebssystemversion; - Patch- oder Buildstand; - physisches Gerät, virtuelle Maschine oder Container; - Standort; - verwendete Netzwerkverbindung; - Benutzerkontext; - lokale oder zentrale Verwaltung; - relevante Anwendungs- oder Dienstversion. --- **Betroffenen Dienst erfassen** Der betroffene Dienst muss möglichst genau benannt werden. Nicht ausreichend: > Der Server geht nicht. Besser: > Die HTTPS-Anwendung auf `app.example.internal` ist über TCP 443 nicht erreichbar. Der Server antwortet weiterhin auf ICMP und SSH. Mögliche Dienstangaben: - DNS; - DHCP; - HTTPS; - SMB; - RDP; - SSH; - VPN; - Datenbank; - Druckdienst; - Active Directory; - E-Mail; - Containeranwendung; - Cloud-Dienst; - Netzwerkspeicher. --- **Sollzustand und Istzustand trennen** | Zustand | Beschreibung | | --- | --- | | Sollzustand | Was sollte normalerweise geschehen? | | Istzustand | Was geschieht tatsächlich? | | Abweichung | Welcher konkrete Unterschied besteht? | Beispiel: | Zustand | Beobachtung | | --- | --- | | Sollzustand | Client erhält per DHCP eine Adresse aus `192.168.10.0/24` | | Istzustand | Client verwendet `169.254.18.24/16` | | Abweichung | Kein gültiger DHCP-Lease vorhanden | --- **Reproduzierbarkeit dokumentieren** Ein reproduzierbarer Fehler ist leichter zu untersuchen als ein unregelmäßiger Fehler. Dokumentiert werden: 1. Ausgangszustand; 2. genaue Aktion; 3. verwendeter Benutzer; 4. verwendetes Gerät; 5. Zielsystem oder Zieladresse; 6. erwartetes Ergebnis; 7. tatsächliches Ergebnis; 8. genaue Fehlerzeit. Beispiel: 1. Client ist über Ethernet verbunden. 2. Benutzer öffnet `https://app.example.internal`. 3. Browser wartet ungefähr 30 Sekunden. 4. Anschließend erscheint ein Timeout. 5. Fehler reproduziert um 14:42:18 Uhr MESZ. 6. Andere Webseiten funktionieren. --- **Häufigkeit bestimmen** | Auftreten | Dokumentation | | --- | --- | | Dauerhaft | Fehler tritt bei jedem Versuch auf | | Gelegentlich | Fehler tritt unregelmäßig auf | | Periodisch | Fehler tritt in erkennbaren Zeitabständen auf | | Zeitabhängig | Fehler tritt nur zu bestimmten Uhrzeiten auf | | Lastabhängig | Fehler tritt nur bei hoher Nutzung auf | | Standortabhängig | Fehler tritt nur in einem Gebäude oder Netz auf | | Benutzerabhängig | Fehler tritt nur mit einem bestimmten Konto auf | | Geräteabhängig | Fehler tritt nur an einem bestimmten Client auf | | Einmalig | Fehler konnte bisher nicht erneut erzeugt werden | Bei unregelmäßigen Fehlern müssen Zeitpunkt und Begleitumstände besonders genau dokumentiert werden. --- **Letzten funktionierenden Zustand festhalten** Die Frage lautet nicht nur: > Seit wann besteht der Fehler? Zusätzlich muss geklärt werden: > Wann wurde die betroffene Funktion zuletzt nachweislich erfolgreich verwendet? Beispiele: - letzte erfolgreiche Anmeldung; - letzter erfolgreicher Druckauftrag; - letzte erfolgreiche DNS-Abfrage; - letzter erfolgreicher Backupjob; - letzte erfolgreiche VPN-Verbindung; - letzte erfolgreiche Replikation; - letzter erfolgreicher API-Aufruf. Der letzte funktionierende Zustand begrenzt den Zeitraum, in dem eine auslösende Änderung stattgefunden haben kann. --- **Letzte Änderungen erfassen** An dieser Stelle werden Änderungen zunächst nur gesammelt. Die technische Bewertung erfolgt später auf der Seite `1.3 Zeitpunkt und letzte Änderungen untersuchen`. Mögliche Änderungen: - Update oder Patch; - Neustart; - Treiber- oder Firmwareänderung; - neue Anwendung; - neue Hardware; - Benutzer- oder Passwortänderung; - Rechte- oder Gruppenänderung; - GPO-Änderung; - Firewall- oder ACL-Änderung; - VLAN- oder Switchportänderung; - Routing- oder NAT-Änderung; - DNS- oder DHCP-Änderung; - Zertifikatserneuerung; - Migration; - Snapshot oder Restore; - Backupjob; - Provider- oder Cloudänderung. Auch die Antwort „Keine Änderung bekannt“ wird dokumentiert. --- **Auswirkung erfassen** Die technische Störung und ihre betriebliche Auswirkung sind getrennt zu dokumentieren. | Technische Störung | Mögliche Auswirkung | | --- | --- | | Ein Client erhält keine IP-Adresse | Ein Benutzer kann nicht arbeiten | | DHCP für ein VLAN ausgefallen | Eine gesamte Abteilung erhält keine Netzwerkverbindung | | DNS-Auflösung gestört | Mehrere Anwendungen erscheinen gleichzeitig ausgefallen | | Fileserver nicht erreichbar | Gemeinsame Dokumente können nicht geöffnet werden | | VPN ausgefallen | Remotezugriff für Außenstellen oder Homeoffice nicht möglich | | Datenbank nicht erreichbar | Geschäftsanwendung vollständig ausgefallen | | Backup fehlgeschlagen | Wiederherstellbarkeit möglicherweise gefährdet | | Verdächtige Anmeldung | Möglicher Security-Vorfall | --- **Workaround dokumentieren** Ein vorhandener Workaround kann bei der Eingrenzung helfen. Beispiele: - Ethernet funktioniert nicht, WLAN funktioniert; - Hostname funktioniert nicht, direkte IP-Adresse funktioniert; - VPN funktioniert nicht, lokaler Zugriff funktioniert; - ein Browser funktioniert, ein anderer nicht; - ein Benutzer ist betroffen, ein anderer nicht; - ein Server ist betroffen, ein anderer Server funktioniert; - Neustart behebt das Problem nur vorübergehend. Ein Workaround ist keine dauerhafte Fehlerbehebung. --- **Beweise sichern** Mögliche Beweise: - Screenshot; - exportiertes Eventlog; - Logdatei; - Konsolenausgabe; - Monitoringgraph; - Prozessliste; - Liste laufender Dienste; - Netzwerkstatus; - Interface-Counter; - Routingtabelle; - DNS-Ergebnis; - Paketmitschnitt; - Konfigurationsexport; - Hersteller-Supportbundle. Dateinamen sollten den Host und den Zeitpunkt enthalten. Beispiel: `client01_systemlog_2026-07-30_1442.evtx` `server01_network_2026-07-30_1442.pcapng` Sensible Daten, Passwörter, Tokens und private Schlüssel dürfen nicht ungeschützt in Tickets oder Dokumentationen eingefügt werden. --- **Vorlage für die Störungsaufnahme** | Feld | Eintrag | | --- | --- | | Ticket oder Referenz | | | Gemeldet von | | | Aufgenommen am | | | Aufgenommen durch | | | Beginn der Störung | | | Letzter funktionierender Zustand | | | Betroffener Benutzer | | | Betroffenes Gerät | | | Hostname | | | Betriebssystem und Version | | | Standort | | | Netzwerkverbindung | | | Betroffener Dienst | | | Zielsystem oder Zieladresse | | | Sollzustand | | | Istzustand | | | Exakte Fehlermeldung | | | Fehlercode oder Event-ID | | | Reproduzierbar | | | Schritte zur Reproduktion | | | Häufigkeit | | | Bekannte letzte Änderungen | | | Betriebliche Auswirkung | | | Vorhandener Workaround | | | Gesicherte Logs und Beweise | | | Genaue Fehlerzeit mit Zeitzone | | | Security-Verdacht | | | Zusätzliche Hinweise | | --- **Beispiel einer ausgefüllten Störungsaufnahme** | Feld | Eintrag | | --- | --- | | Ticket oder Referenz | INC-2026-0730-01 | | Gemeldet von | Benutzer der Arbeitsstation | | Aufgenommen am | 30.07.2026, 14:40 Uhr MESZ | | Beginn der Störung | ungefähr 14:35 Uhr | | Letzter funktionierender Zustand | 30.07.2026, 12:10 Uhr | | Betroffenes Gerät | Arbeitsplatzrechner | | Hostname | CLIENT-01 | | Betriebssystem und Version | Windows 11 | | Standort | Hauptstandort, Raum 204 | | Netzwerkverbindung | Ethernet | | Betroffener Dienst | DHCP und allgemeiner Netzwerkzugriff | | Sollzustand | IPv4-Adresse aus `192.168.10.0/24` | | Istzustand | IPv4-Adresse `169.254.18.24/16` | | Exakte Fehlermeldung | Keine Fehlermeldung angezeigt | | Reproduzierbar | Ja | | Häufigkeit | Dauerhaft über Ethernet | | Bekannte letzte Änderungen | Keine Änderung bekannt | | Betriebliche Auswirkung | Benutzer kann keine internen Dienste erreichen | | Vorhandener Workaround | WLAN funktioniert | | Gesicherte Beweise | Ausgabe von `ipconfig /all`, Screenshot und Fehlerzeit | | Security-Verdacht | Nein | Diese Aufnahme beschreibt den Zustand. Die technische Eingrenzung erfolgt anschließend auf der Seite `1.2 Fehlerumfang mit Kreuztests bestimmen`. --- **Ungeeignete Störungsbeschreibungen** - „Geht nicht.“ - „Alles ist langsam.“ - „Seit dem Update ist alles kaputt.“ - „Der Server ist offline.“ - „DNS ist defekt.“ - „Die Firewall blockiert.“ - „Der Benutzer macht etwas falsch.“ - „Nach einem Neustart geht es wieder.“ Diese Aussagen enthalten Vermutungen oder sind technisch nicht ausreichend eingegrenzt. --- **Ergebnis dieser Seite** Nach Abschluss der Störungsaufnahme müssen folgende Punkte bekannt sein: - sichtbares Symptom; - Sollzustand; - Istzustand; - exakte Fehlermeldung; - betroffener Benutzer; - betroffenes Gerät; - betroffener Dienst; - Beginn der Störung; - letzter funktionierender Zustand; - Reproduzierbarkeit; - Häufigkeit; - bekannte Änderungen; - betriebliche Auswirkung; - möglicher Workaround; - vorhandene Logs und Beweise. Erst danach beginnt die systematische technische Eingrenzung. --- **Nächste Seite** `1.2 Fehlerumfang mit Kreuztests bestimmen` **Quellen** - [IBM – Systematischer Troubleshooting-Ansatz](https://www.ibm.com/docs/en/qradar-on-cloud?topic=support-techniques-troubleshooting-problem) - [Microsoft – Windows Networking Troubleshooting](https://learn.microsoft.com/en-us/troubleshoot/windows-client/networking/networking-overview) - [Microsoft – DHCP Troubleshooting Checklist](https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/troubleshoot-dhcp-guidance) - [Microsoft – Windows Performance Troubleshooting](https://learn.microsoft.com/en-us/troubleshoot/windows-server/performance/troubleshoot-performance-problems-in-windows) - [NIST – Incident Response Recommendations](https://csrc.nist.gov/pubs/sp/800/61/r3/final) # 1.2 Fehlerumfang mit Kreuztests bestimmen **Zweck dieser Seite** Diese Seite dient dazu, den Umfang einer Störung systematisch einzugrenzen. Nach der Störungsaufnahme ist bekannt, welches Symptom beobachtet wurde. Jetzt wird geprüft, ob die Ursache wahrscheinlich beim Benutzer, beim Gerät, beim Netzwerk, beim Standort, beim Zielsystem oder bei einem zentralen Dienst liegt. In dieser Phase wird die Ursache noch nicht behoben. Das Ziel ist zunächst, die Fehlerdomäne möglichst stark zu verkleinern. --- **Grundprinzip** Ein einzelner Test zeigt häufig nur, dass etwas funktioniert oder nicht funktioniert. Ein Kreuztest verändert gezielt nur eine Bedingung: - gleicher Benutzer, anderes Gerät; - anderer Benutzer, gleiches Gerät; - gleiches Gerät, andere Netzwerkverbindung; - gleiches Gerät, anderer Switchport; - gleiche Quelle, anderes Ziel; - andere Quelle, gleiches Ziel. Dadurch lässt sich erkennen, mit welcher Komponente der Fehler mitwandert. --- **Was ist eine Fehlerdomäne?** Eine Fehlerdomäne ist der technische oder organisatorische Bereich, in dem die Ursache wahrscheinlich liegt. Mögliche Fehlerdomänen: | Fehlerdomäne | Beispiele | | --- | --- | | Benutzer | Konto, Passwort, Gruppen, Rollen, Profil oder persönliche Einstellungen | | Gerät | Betriebssystem, Treiber, lokale Firewall, Software oder Hardware | | Netzwerkinterface | Ethernetadapter, WLAN-Adapter, USB-Adapter oder virtuelle NIC | | Verkabelung | Patchkabel, Dose, Patchfeld oder Gebäudeverkabelung | | Switchport | Portkonfiguration, VLAN, Port Security oder Hardwarefehler | | VLAN oder Subnetz | DHCP, Gateway, ACL, Routing oder Broadcast-Domain | | Standort | Switch, Firewall, WAN, VPN, Provider oder Stromversorgung | | Zielsystem | Server, Anwendung, Dienst, Listener oder lokale Firewall | | Zentraler Dienst | DNS, DHCP, Active Directory, NTP, Proxy oder Cloud-Dienst | | Benutzergruppe | Gruppenrichtlinie, Berechtigung, Lizenz oder Conditional Access | | Betriebssystemgruppe | Update, Treiber, Softwareversion oder Sicherheitsrichtlinie | | Zeitpunkt oder Last | Backup, Wartungsjob, hohe Auslastung oder geplante Änderung | --- **Die wichtigsten Eingrenzungsachsen** | Achse | Fragestellung | | --- | --- | | Benutzer | Ist nur ein bestimmter Benutzer betroffen? | | Gerät | Tritt der Fehler nur an einem Gerät auf? | | Interface | Tritt der Fehler nur über Ethernet, WLAN oder VPN auf? | | Port | Tritt der Fehler nur an einem Switchport auf? | | VLAN | Sind alle Geräte eines VLANs betroffen? | | Subnetz | Sind alle Geräte eines IP-Netzes betroffen? | | Standort | Ist nur ein Gebäude oder eine Außenstelle betroffen? | | Dienst | Ist nur ein bestimmter Dienst betroffen? | | Ziel | Ist nur ein bestimmter Server betroffen? | | Betriebssystem | Sind nur Windows-, Linux- oder macOS-Systeme betroffen? | | Version | Sind nur Systeme mit einem bestimmten Patchstand betroffen? | | Zeit | Tritt der Fehler nur zu bestimmten Zeiten auf? | | Last | Tritt der Fehler nur bei hoher Nutzung auf? | --- **Betroffen und nicht betroffen dokumentieren** Die nicht betroffenen Systeme sind für die Diagnose genauso wichtig wie die betroffenen Systeme. | Kategorie | Betroffen | Nicht betroffen | | --- | --- | --- | | Benutzer | | | | Geräte | | | | Betriebssysteme | | | | Standorte | | | | Switchports | | | | VLANs | | | | Subnetze | | | | Netzwerkverbindungen | | | | Anwendungen | | | | Server | | | | Zeiträume | | | Beispiel: | Kategorie | Betroffen | Nicht betroffen | | --- | --- | --- | | Benutzer | `user` | andere Benutzer | | Gerät | CLIENT-01 | CLIENT-02 | | Netzwerkverbindung | Ethernet | WLAN | | Dienst | interne Dienste | lokale Anwendungen | | Standort | Raum 204 | Raum 205 | Aus diesem Beispiel ergibt sich noch keine endgültige Ursache. Der Fehlerbereich wurde aber bereits auf Ethernet, Verkabelung, Switchport, VLAN-Zuweisung oder die Ethernetkonfiguration des Clients eingegrenzt. --- **Regel für kontrollierte Kreuztests** Bei einem Kreuztest wird möglichst nur eine Bedingung verändert. Ungeeignet: - anderen Benutzer verwenden; - gleichzeitig das Gerät wechseln; - zusätzlich WLAN statt Ethernet verwenden; - gleichzeitig einen anderen Zielserver testen. Bei diesem Test wurden mehrere Bedingungen verändert. Das Ergebnis ist nicht eindeutig. Besser: 1. gleicher Benutzer an anderem Gerät; 2. anderer Benutzer am ursprünglichen Gerät; 3. ursprüngliches Gerät über ein anderes Interface; 4. ursprüngliches Gerät an anderem Switchport. --- **Kreuztest 1 – Gleicher Benutzer an anderem Gerät** **Durchführung** Der betroffene Benutzer testet dieselbe Funktion an einem anderen, nachweislich funktionierenden Gerät. **Auswertung** | Ergebnis | Wahrscheinlicher Bereich | | --- | --- | | Fehler tritt auch am anderen Gerät auf | Benutzerkonto, Berechtigung, Rolle, Lizenz, Profil oder zentral gespeicherte Einstellung | | Fehler tritt am anderen Gerät nicht auf | ursprüngliches Gerät, lokale Konfiguration, Interface oder Software | | Fehler tritt nur an Geräten eines Standortes auf | Standortnetz, Richtlinie oder gemeinsamer Dienst | | Ergebnis abhängig vom Betriebssystem | Clientsoftware, Treiber, Richtlinie oder Kompatibilität | **Wichtig** Es muss wirklich dieselbe Funktion mit demselben Benutzer getestet werden. --- **Kreuztest 2 – Anderer Benutzer am gleichen Gerät** **Durchführung** Ein anderer berechtigter Benutzer testet dieselbe Funktion am betroffenen Gerät. **Auswertung** | Ergebnis | Wahrscheinlicher Bereich | | --- | --- | | Anderer Benutzer ist ebenfalls betroffen | Gerät, Betriebssystem, Netzwerk oder lokale Software | | Anderer Benutzer ist nicht betroffen | Benutzerprofil, Konto, Rechte, Gruppen oder persönliche Einstellungen | | Administrator funktioniert, Standardbenutzer nicht | Rechte, UAC, Richtlinie oder Dateiberechtigung | | Lokaler Benutzer funktioniert, Domänenbenutzer nicht | AD, DNS, Kerberos, GPO oder Netzwerkerreichbarkeit | Anmeldedaten dürfen nicht zwischen Benutzern weitergegeben werden. Der andere Benutzer meldet sich selbst an. --- **Kreuztest 3 – Gleiches Gerät über anderes Netzwerkinterface** Mögliche Vergleiche: - Ethernet gegen WLAN; - WLAN gegen Ethernet; - interne Verbindung gegen VPN; - VPN gegen direkte Standortverbindung; - integrierte NIC gegen bekannten funktionierenden USB-Netzwerkadapter. **Auswertung** | Ergebnis | Wahrscheinlicher Bereich | | --- | --- | | Ethernet fehlerhaft, WLAN funktioniert | Ethernetadapter, Kabel, Switchport, VLAN oder kabelgebundenes Netz | | WLAN fehlerhaft, Ethernet funktioniert | WLAN-Adapter, Funkversorgung, SSID, Authentifizierung oder WLAN-VLAN | | Direkter Zugriff funktioniert, VPN nicht | VPN, Tunnelrouting, VPN-DNS, MTU oder Berechtigung | | VPN funktioniert, lokaler Standortzugriff nicht | Standortnetz, lokales Routing, Firewall oder DNS | | Beide Interfaces fehlerhaft | Betriebssystem, zentrale Dienste, Zielsystem oder allgemeine Konfiguration | Ein funktionierendes alternatives Interface ist ein wichtiger Hinweis, aber noch keine dauerhafte Lösung. --- **Kreuztest 4 – Gleiches Gerät an anderem Switchport** **Durchführung** Das betroffene Gerät wird kontrolliert mit einem nachweislich funktionierenden Port verbunden. Dabei müssen berücksichtigt werden: - Port-VLAN; - Portprofil; - Voice VLAN; - Port Security; - 802.1X; - NAC; - DHCP Snooping; - Geschwindigkeit; - PoE; - Trunk- oder Access-Konfiguration. **Auswertung** | Ergebnis | Wahrscheinlicher Bereich | | --- | --- | | Gerät funktioniert am anderen Port | ursprünglicher Port, Portprofil, VLAN, Kabelweg oder Switchhardware | | Gerät funktioniert auch am anderen Port nicht | Client, Adapter, Betriebssystem oder übergeordneter Netzwerkdienst | | Mehrere Geräte funktionieren am ursprünglichen Port nicht | Port, Kabelweg oder Switchkonfiguration | | Andere Geräte funktionieren am ursprünglichen Port | ursprünglicher Client oder dessen Authentifizierung | Der Vergleichsport muss für denselben Einsatzzweck und dasselbe VLAN vorgesehen sein. --- **Kreuztest 5 – Funktionierendes Gerät am betroffenen Port** **Durchführung** Ein bekannt funktionierendes Gerät wird mit dem ursprünglichen Kabel und Switchport verbunden. **Auswertung** | Ergebnis | Wahrscheinlicher Bereich | | --- | --- | | Vergleichsgerät funktioniert | ursprünglicher Client, NIC, Treiber oder Clientkonfiguration | | Vergleichsgerät funktioniert nicht | Kabel, Dose, Patchfeld, Switchport, VLAN oder Portprofil | | Vergleichsgerät erhält anderes VLAN | 802.1X, NAC, MAC-basierte Zuweisung oder Portprofil | | Vergleichsgerät erhält ebenfalls keine IP | DHCP, VLAN, Relay, Snooping oder Portkonfiguration | --- **Kreuztest 6 – Gleiches Gerät, anderes Ziel** **Durchführung** Vom betroffenen Client werden mehrere technisch vergleichbare Ziele getestet. Beispiele: - anderer Server im gleichen VLAN; - anderer Server im entfernten Netz; - anderer interner Webdienst; - öffentliche IP-Adresse; - interner und externer DNS-Name. **Auswertung** | Ergebnis | Wahrscheinlicher Bereich | | --- | --- | | Nur ein Ziel ist nicht erreichbar | Zielserver, Zieldienst, Ziel-Firewall oder Rückroute | | Alle Ziele eines Subnetzes sind nicht erreichbar | Routing, ACL, Firewall oder Gateway dieses Netzes | | Interne Ziele funktionieren, externe nicht | WAN, NAT, Proxy, Firewall oder Provider | | Externe Ziele funktionieren, interne nicht | internes Routing, VPN, interne DNS-Auflösung oder interne Firewall | | Nur ein bestimmter Dienst ist nicht erreichbar | Port, Listener, Host-Firewall oder Anwendung | --- **Kreuztest 7 – Andere Quelle, gleiches Ziel** **Durchführung** Dasselbe Ziel wird von einem anderen Client, VLAN oder Standort getestet. **Auswertung** | Ergebnis | Wahrscheinlicher Bereich | | --- | --- | | Andere Quelle erreicht das Ziel | ursprünglicher Client oder ursprünglicher Netzwerkpfad | | Keine Quelle erreicht das Ziel | Zielsystem, zentraler Dienst oder allgemeiner Netzwerkpfad | | Nur ein VLAN erreicht das Ziel nicht | VLAN-Gateway, ACL, Routing oder Firewallregel | | Nur ein Standort erreicht das Ziel nicht | WAN, Standortfirewall, VPN oder Provider | | Nur ein Betriebssystem ist betroffen | Clientsoftware, Zertifikat, Richtlinie oder Protokollkompatibilität | --- **Kreuztest 8 – IP-Adresse gegen Hostname** **Durchführung** Das Ziel wird zuerst über die IP-Adresse und anschließend über den Hostnamen geprüft. | Prüfung | Windows | Linux | macOS | | --- | --- | --- | --- | | Ziel-IP testen | `[RO] Test-NetConnection ` | `[RO] ping -c 4 ` | `[RO] ping -c 4 ` | | Hostname testen | `[RO] Test-NetConnection ` | `[RO] ping -c 4 ` | `[RO] ping -c 4 ` | | DNS-Abfrage | `[RO] Resolve-DnsName ` | `[RO] dig ` | `[RO] dig ` | **Auswertung** | Ergebnis | Wahrscheinlicher Bereich | | --- | --- | | IP funktioniert, Hostname nicht | DNS, DNS-Suffix, Clientcache oder hosts-Datei | | IP und Hostname funktionieren nicht | Erreichbarkeit, Routing, Firewall oder Zielsystem | | Hostname löst auf falsche IP auf | DNS-Record, Split-DNS, Cache oder falscher DNS-Server | | A-Record funktioniert, AAAA-Pfad nicht | IPv6-Konfiguration oder IPv6-Routing | | Kurzname funktioniert nicht, FQDN funktioniert | DNS-Suffix oder Suchdomäne | --- **Kreuztest 9 – Ping gegen tatsächlichen Dienstport** Ein Ping prüft nicht den eigentlichen Anwendungsdienst. | Prüfung | Windows | Linux | macOS | | --- | --- | --- | --- | | ICMP | `[RO] Test-NetConnection ` | `[RO] ping -c 4 ` | `[RO] ping -c 4 ` | | TCP-Port | `[RO] Test-NetConnection -Port ` | `[RO] nc -vz ` | `[RO] nc -vz ` | | HTTPS | `[RO] curl -v https:///` | `[RO] curl -v https:///` | `[RO] curl -v https:///` | **Auswertung** | Ergebnis | Wahrscheinlicher Bereich | | --- | --- | | Ping und Port funktionieren | grundlegende Verbindung vorhanden; Anwendung weiter prüfen | | Ping funktioniert, Port nicht | Listener, Dienst, Host-Firewall oder Netzwerkfirewall | | Ping funktioniert nicht, Port funktioniert | ICMP wird wahrscheinlich gefiltert | | Port funktioniert, HTTPS-Anfrage nicht | TLS, Proxy, Host Header oder Anwendung | | TCP-Verbindung wird zurückgesetzt | Zielprozess, Firewall, Proxy oder Load Balancer | `curl -v` kann Header, Zertifikatsinformationen und sensible Sitzungsdaten anzeigen. Ausgaben müssen vor der Weitergabe geprüft werden. --- **Kreuztest 10 – Lokal gegen entfernt** | Test | Zweck | | --- | --- | | Dienst lokal auf dem Server testen | Prüft, ob Anwendung und lokaler Listener funktionieren | | Dienst aus gleichem VLAN testen | Prüft den lokalen Netzwerkzugriff | | Dienst aus anderem VLAN testen | Prüft Routing und Firewall zwischen Netzen | | Dienst über VPN testen | Prüft Tunnel, VPN-Routing und VPN-DNS | | Dienst aus externem Netz testen | Prüft WAN, NAT, Reverse Proxy oder externe Firewall | **Auswertung** | Ergebnis | Wahrscheinlicher Bereich | | --- | --- | | Lokal funktioniert, entfernt nicht | Firewall, Bind-Adresse, Routing, NAT oder Netzwerkpfad | | Lokal funktioniert nicht | Dienst, Anwendung, Konfiguration oder Abhängigkeit | | Gleiches VLAN funktioniert, anderes VLAN nicht | Inter-VLAN-Routing, ACL oder Firewall | | Intern funktioniert, extern nicht | NAT, WAN-Firewall, DNS oder Reverse Proxy | | Extern funktioniert, intern nicht | Hairpin NAT, internes DNS oder interne Route | --- **System- und Netzwerkidentität prüfen** | Prüfung | Windows | Linux | macOS | | --- | --- | --- | --- | | Benutzer | `[RO] whoami` | `[RO] whoami` | `[RO] whoami` | | Hostname | `[RO] hostname` | `[RO] hostname` | `[RO] hostname` | | Interfaces | `[RO] Get-NetAdapter` | `[RO] ip -brief link` | `[RO] ifconfig -l` | | IP-Adressen | `[RO] Get-NetIPAddress` | `[RO] ip -brief address` | `[RO] ifconfig` | | Standardroute | `[RO] Get-NetRoute -DestinationPrefix "0.0.0.0/0"` | `[RO] ip route show default` | `[RO] route -n get default` | | DNS-Server | `[RO] Get-DnsClientServerAddress` | `[RO] resolvectl status` | `[RO] scutil --dns` | Diese Informationen helfen zu prüfen, ob die verglichenen Systeme tatsächlich im erwarteten Netzwerk, VLAN oder Benutzerkontext arbeiten. --- **Empfohlene Reihenfolge der Kreuztests** 1. Betroffenen Benutzer und betroffenes Gerät bestätigen. 2. Anderen Benutzer am gleichen Gerät testen. 3. Gleichen Benutzer an anderem Gerät testen. 4. Gleiches Gerät über anderes Interface testen. 5. Anderes Gerät am gleichen Port testen. 6. Gleiches Gerät an geeignetem Vergleichsport testen. 7. Andere Ziele von gleicher Quelle testen. 8. Gleiches Ziel von anderer Quelle testen. 9. IP-Adresse gegen Hostname testen. 10. Ping gegen tatsächlichen Dienstport testen. 11. lokalen, internen und entfernten Zugriff vergleichen. 12. Ergebnisse in einer Betroffen/Nicht-betroffen-Matrix festhalten. Nicht jeder Fehler benötigt alle Kreuztests. Sobald die Fehlerdomäne eindeutig eingegrenzt ist, wird mit der passenden technischen Detailseite fortgefahren. --- **Auswertungsmatrix** | Beobachtung | Wahrscheinliche Fehlerdomäne | Passende Folgeseite | | --- | --- | --- | | Nur ein Benutzer betroffen | Konto, Rechte oder Profil | Benutzer- und Identitätsdiagnose | | Nur ein Gerät betroffen | Client, Treiber oder lokale Konfiguration | Windows-, Linux- oder macOS-Diagnose | | Nur Ethernet betroffen | NIC, Kabel, Port oder VLAN | Hardware, Switching und VLAN | | Nur WLAN betroffen | Funk, SSID, Authentifizierung oder WLAN-VLAN | WLAN-Diagnose | | Nur ein Port betroffen | Switchport, Kabelweg oder Portprofil | Switching und Verkabelung | | Nur ein VLAN betroffen | Gateway, DHCP Relay, ACL oder Routing | VLAN, DHCP und Routing | | Nur ein Standort betroffen | WAN, VPN, Firewall oder Provider | WAN- und Standortdiagnose | | Nur ein Ziel betroffen | Zielserver, Dienst oder Rückroute | Server- und Dienstdiagnose | | Nur ein Port oder Protokoll betroffen | Listener oder Firewall | TCP-, UDP- und Firewall-Diagnose | | IP funktioniert, Hostname nicht | DNS | DNS-Diagnose | | Alle Benutzer und Geräte betroffen | zentraler Dienst oder Infrastruktur | zentrale Infrastruktur prüfen | | Fehler tritt nur zu bestimmten Zeiten auf | Last, Job, Wartung oder Timeout | Performance- und Zeitdiagnose | --- **Vorlage zur Dokumentation der Kreuztests** | Nummer | Unveränderte Bedingung | Veränderte Bedingung | Ergebnis | Schlussfolgerung | | --- | --- | --- | --- | --- | | 1 | | | | | | 2 | | | | | | 3 | | | | | | 4 | | | | | | 5 | | | | | --- **Beispiel** **Ausgangssituation** CLIENT-01 erhält über Ethernet keine gültige DHCP-Adresse. Über WLAN funktioniert der Netzwerkzugriff. | Kreuztest | Ergebnis | | --- | --- | | Anderer Benutzer an CLIENT-01 über Ethernet | ebenfalls betroffen | | Ursprünglicher Benutzer an CLIENT-02 | funktioniert | | CLIENT-01 über WLAN | funktioniert | | CLIENT-02 am Port von CLIENT-01 | erhält ebenfalls keine DHCP-Adresse | | CLIENT-01 an geeignetem Vergleichsport | erhält gültige DHCP-Adresse | **Schlussfolgerung** Der Fehler ist nicht benutzerabhängig und wahrscheinlich nicht durch die allgemeine Clientkonfiguration verursacht. Die Fehlerdomäne wurde auf folgende Komponenten eingegrenzt: - ursprüngliches Patchkabel; - Netzwerkdose; - Patchfeld; - Switchport; - Port-VLAN; - Portprofil; - DHCP Snooping oder Port Security. Die weitere Diagnose erfolgt im Kapitel zu Verkabelung, Switching und VLAN. --- **Nicht vorschnell verändern** Während der Eingrenzung nicht gleichzeitig: - Benutzerrechte ändern; - Client neu installieren; - Netzwerkstack zurücksetzen; - DNS- oder ARP-Cache löschen; - Switchport neu konfigurieren; - VLAN ändern; - Firewall deaktivieren; - DHCP-Reservierung löschen; - Dienste neu starten. Zuerst muss festgestellt werden, mit welcher Komponente der Fehler zusammenhängt. --- **Ergebnis dieser Seite** Nach Abschluss der Kreuztests sollte bekannt sein, ob die Störung wahrscheinlich abhängig ist von: - Benutzer; - Gerät; - Netzwerkinterface; - Kabel oder Switchport; - VLAN oder Subnetz; - Standort; - Betriebssystem oder Version; - Zielsystem; - Dienst oder Port; - DNS; - VPN; - Zeitpunkt oder Last. Die technische Detaildiagnose beginnt anschließend innerhalb der eingegrenzten Fehlerdomäne. --- **Nächste Seite** `1.3 Zeitpunkt und letzte Änderungen untersuchen` **Quellen** - [IBM – Systematischer Troubleshooting-Ansatz](https://www.ibm.com/docs/en/qradar-on-cloud?topic=support-techniques-troubleshooting-problem) - [Microsoft – Windows Networking Troubleshooting](https://learn.microsoft.com/en-us/troubleshoot/windows-client/networking/networking-overview) - [Microsoft – Test-NetConnection](https://learn.microsoft.com/en-us/powershell/module/nettcpip/test-netconnection?view=windowsserver2025-ps) - [Cisco – Switchport- und Interfaceprobleme](https://www.cisco.com/c/en/us/support/docs/switches/catalyst-6500-series-switches/12027-53.html) - [Apple – Netzwerkprobleme durch Vergleich mit anderem Netzwerk eingrenzen](https://support.apple.com/en-us/102281) - [Red Hat – Netzwerkkonfiguration und Routing](https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/configuring_and_managing_networking/) # 1.3 Zeitpunkt und letzte Änderungen untersuchen **1.3 Zeitpunkt und letzte Änderungen untersuchen** Viele Störungen treten kurz nach einer Änderung auf. Deshalb gehört die Frage „Was hat sich verändert?“ zu den wichtigsten Schritten einer systematischen Fehleranalyse. Dabei gilt jedoch: > Eine zeitliche Übereinstimmung ist ein Hinweis, aber noch kein Beweis für einen ursächlichen Zusammenhang. Ein Update kurz vor einer Störung kann die Ursache sein. Es kann aber ebenso Zufall sein, während beispielsweise gleichzeitig eine Firewall-Regel, ein VLAN oder ein Zertifikat geändert wurde. --- **Ziel dieser Seite** Nach diesem Schritt sollten folgende Fragen beantwortet sein: - Wann funktionierte das System zuletzt nachweislich? - Wann trat der Fehler erstmals nachweislich auf? - Was wurde innerhalb dieses Zeitfensters verändert? - Wer oder welcher Prozess führte die Änderung aus? - Welche Systeme sind von der Änderung betroffen? - Passt die Änderung technisch zum Fehlerbild? - Kann der Zusammenhang durch einen Test bestätigt oder widerlegt werden? --- **1. Das Störungszeitfenster bestimmen** Zuerst wird der Zeitraum eingegrenzt, in dem die Ursache wahrscheinlich entstanden ist. | Zeitpunkt | Bedeutung | Beispiel | |---|---|---| | Letzter bekannter funktionierender Zustand | Funktion wurde erfolgreich verwendet oder geprüft | Benutzer meldete sich um 13:50 Uhr erfolgreich an | | Erste bekannte Störung | Fehler wurde erstmals sicher beobachtet | Anmeldung schlug um 14:35 Uhr fehl | | Meldezeitpunkt | Störung wurde an den Support gemeldet | Ticket wurde um 14:47 Uhr erstellt | | Beginn der Untersuchung | Technische Analyse wurde gestartet | Administrator begann um 15:05 Uhr | | Störungszeitfenster | Zeitraum zwischen „funktioniert“ und „funktioniert nicht“ | 13:50 bis 14:35 Uhr | Je kleiner das Störungszeitfenster ist, desto gezielter können Änderungen, Ereignisse und Protokolle durchsucht werden. **Wichtige Unterscheidung** - „Der Benutzer hat den Fehler um 14:35 Uhr bemerkt“ bedeutet nicht automatisch, dass der Fehler um 14:35 Uhr entstanden ist. - Eine ausgefallene nächtliche Sicherung kann beispielsweise erst am nächsten Morgen auffallen. - Ein Zertifikat kann um Mitternacht ablaufen, obwohl der betroffene Dienst erst Stunden später verwendet wird. - Ein DHCP-, Kerberos- oder DNS-Problem kann bereits bestehen, bevor ein Benutzer eine sichtbare Störung meldet. --- **2. Uhrzeit und Zeitzone prüfen** Bevor Ereignisse verschiedener Systeme verglichen werden, müssen Uhrzeit und Zeitzone geprüft werden. Abweichende Systemzeiten können eine korrekte Ereignisreihenfolge vortäuschen oder verbergen. Besonders relevant ist dies bei: - Active Directory und Kerberos - Zertifikaten - VPN-Verbindungen - Firewalls - Netzwerkkomponenten - Virtualisierungssystemen - Cloud-Diensten - verteilten Anwendungen - SIEM- und Monitoring-Systemen **Aktuelle Uhrzeit anzeigen** | Betriebssystem | Befehl | |---|---| | Windows PowerShell | `[RO] Get-Date -Format o` | | Windows Eingabeaufforderung | `[RO] echo %date% %time%` | | Linux | `[RO] date "+%Y-%m-%d %H:%M:%S %Z"` | | macOS | `[RO] date "+%Y-%m-%d %H:%M:%S %Z"` | **Aktuelle UTC-Zeit anzeigen** | Betriebssystem | Befehl | |---|---| | Windows PowerShell | `[RO] (Get-Date).ToUniversalTime().ToString("o")` | | Linux | `[RO] date -u "+%Y-%m-%dT%H:%M:%SZ"` | | macOS | `[RO] date -u "+%Y-%m-%dT%H:%M:%SZ"` | **Zeitzone und Zeitsynchronisation prüfen** | Betriebssystem | Befehl | |---|---| | Windows PowerShell | `[RO] Get-TimeZone` | | Windows | `[RO] w32tm /query /status` | | Windows | `[RO] w32tm /query /source` | | Linux mit systemd | `[RO] timedatectl status` | | Linux mit chrony | `[RO] chronyc tracking` | | Linux mit chrony | `[RO] chronyc sources -v` | | macOS | `[RO] systemsetup -gettimezone` | | macOS | `[RO] sntp -d time.apple.com` | > `[RO]` bedeutet „Read-only“. Der Befehl liest Informationen aus und soll keine Konfiguration verändern. Bei der Dokumentation sollte immer angegeben werden, ob eine Uhrzeit als lokale Zeit oder als UTC-Zeit notiert wurde. --- **3. Letzten Systemstart bestimmen** Ein Neustart kann eine Störung ausgelöst, beseitigt oder sichtbar gemacht haben. Manche Änderungen werden außerdem erst nach einem Neustart wirksam. | Betriebssystem | Befehl | |---|---| | Windows PowerShell | `[RO] Get-CimInstance Win32_OperatingSystem \| Select-Object LastBootUpTime` | | Windows Eingabeaufforderung | `[RO] systeminfo` | | Linux | `[RO] uptime -s` | | Linux | `[RO] who -b` | | Linux | `[RO] last reboot` | | macOS | `[RO] sysctl -n kern.boottime` | | macOS | `[RO] last reboot` | | Alle Unix-artigen Systeme | `[RO] uptime` | **Windows-Betriebsdauer berechnen** `[RO] (Get-Date) - (Get-CimInstance Win32_OperatingSystem).LastBootUpTime` **Typische Schlussfolgerungen** | Beobachtung | Mögliche Bedeutung | |---|---| | Störung begann direkt nach einem Neustart | Dienststart, Treiber, Update, Abhängigkeit oder Startreihenfolge prüfen | | System wurde unerwartet neu gestartet | Stromversorgung, Absturz, Watchdog, Hypervisor oder automatischer Neustart prüfen | | System wurde lange nicht neu gestartet | Ausstehende Updates, Ressourcenprobleme oder nicht aktivierte Konfigurationsänderungen prüfen | | Fehler verschwindet nach Neustart | Flüchtiger Zustand, Ressourcenleck, blockierter Dienst oder fehlerhafter Cache möglich | | Fehler erscheint erst nach Neustart | Änderung wurde möglicherweise erst beim Systemstart aktiviert | --- **4. Änderungen im Störungszeitfenster sammeln** Folgende Änderungsquellen sollten systematisch geprüft werden: | Bereich | Typische Änderungen | |---|---| | Betriebssystem | Updates, Neustarts, Treiber, Sicherheitsrichtlinien | | Anwendungen | Installation, Update, Deinstallation, Konfigurationsänderung | | Dienste | Start, Stopp, Absturz, Starttyp oder Dienstkonto geändert | | Netzwerk | VLAN, Routing, Switchport, ACL, Firewall-Regel, NAT | | DNS | Neuer, gelöschter oder geänderter Eintrag | | DHCP | Scope, Reservierung, Option, Lease oder Relay geändert | | Active Directory | Benutzer, Gruppe, Gruppenrichtlinie, Computerobjekt | | Berechtigungen | NTFS-, Freigabe-, Rollen- oder Cloud-Berechtigung | | Zertifikate | Ausstellung, Austausch, Ablauf oder Vertrauenskette | | Storage | Datenträger, LUN, Mount, Berechtigung, Speicherplatz | | Virtualisierung | Snapshot, Migration, Ressourcen oder virtuelle Netzwerke | | Backup | Sicherung, Wiederherstellung, Agent- oder Repository-Änderung | | Cloud | Sicherheitsgruppe, Rolle, Richtlinie, Netzwerk oder Ressource | | Automatisierung | Skript, geplante Aufgabe, Cronjob, Pipeline | | Hardware | Austausch, Firmware, Verkabelung oder Portwechsel | | Externe Dienste | Provider-Störung, Wartung oder geänderte Schnittstelle | --- **5. Ereignisse im relevanten Zeitfenster anzeigen** Für die folgenden Beispiele wird dieses Störungszeitfenster verwendet: - Letzter bekannter funktionierender Zustand: 30.07.2026, 14:00 Uhr - Erste bekannte Störung: 30.07.2026, 15:00 Uhr Die Werte müssen an den tatsächlichen Vorfall angepasst werden. --- **Windows-Ereignisse mit PowerShell durchsuchen** **Systemprotokoll innerhalb eines Zeitfensters** `[RO] Get-WinEvent -FilterHashtable @{LogName="System"; StartTime=[datetime]"2026-07-30 14:00:00"; EndTime=[datetime]"2026-07-30 15:00:00"}` **Anwendungsprotokoll innerhalb eines Zeitfensters** `[RO] Get-WinEvent -FilterHashtable @{LogName="Application"; StartTime=[datetime]"2026-07-30 14:00:00"; EndTime=[datetime]"2026-07-30 15:00:00"}` **Warnungen und Fehler anzeigen** `[RO] Get-WinEvent -FilterHashtable @{LogName="System"; Level=2,3; StartTime=[datetime]"2026-07-30 14:00:00"; EndTime=[datetime]"2026-07-30 15:00:00"} | Select-Object TimeCreated, Id, ProviderName, LevelDisplayName, Message` | Level | Bedeutung | |---:|---| | 1 | Kritisch | | 2 | Fehler | | 3 | Warnung | | 4 | Information | | 5 | Ausführlich | **Ereignisse als übersichtliche Tabelle darstellen** `[RO] Get-WinEvent -FilterHashtable @{LogName="System"; StartTime=[datetime]"2026-07-30 14:00:00"; EndTime=[datetime]"2026-07-30 15:00:00"} | Sort-Object TimeCreated | Format-Table TimeCreated, Id, ProviderName, LevelDisplayName -AutoSize` > Nicht jeder Fehler erzeugt ein Ereignis der Stufe „Fehler“. Auch Informationsereignisse können wichtige Hinweise auf Dienststarts, Updates oder Konfigurationsänderungen enthalten. --- **Linux-Ereignisse mit journalctl durchsuchen** **Alle Ereignisse innerhalb eines Zeitfensters** `[RO] journalctl --since "2026-07-30 14:00:00" --until "2026-07-30 15:00:00"` **Nur Warnungen und schwerwiegendere Meldungen** `[RO] journalctl --since "2026-07-30 14:00:00" --until "2026-07-30 15:00:00" -p warning` **Ereignisse eines bestimmten Dienstes** `[RO] journalctl -u --since "2026-07-30 14:00:00" --until "2026-07-30 15:00:00"` Beispiel für SSH: `[RO] journalctl -u sshd --since "2026-07-30 14:00:00" --until "2026-07-30 15:00:00"` **Ereignisse des aktuellen Systemstarts** `[RO] journalctl -b` **Ereignisse des vorherigen Systemstarts** `[RO] journalctl -b -1` **Kernel-Meldungen des aktuellen Systemstarts** `[RO] journalctl -k -b` --- **macOS-Ereignisse durchsuchen** **Systemprotokoll innerhalb eines Zeitfensters** `[RO] log show --start "2026-07-30 14:00:00" --end "2026-07-30 15:00:00" --style compact` **Nur Fehler und Störungen** `[RO] log show --start "2026-07-30 14:00:00" --end "2026-07-30 15:00:00" --predicate 'messageType == error OR messageType == fault' --style compact` **Ereignisse eines bestimmten Prozesses** `[RO] log show --start "2026-07-30 14:00:00" --end "2026-07-30 15:00:00" --predicate 'process == ""' --style compact` Beispiel für den Prozess `softwareupdated`: `[RO] log show --last 2h --predicate 'process == "softwareupdated"' --style compact` Alternativ können Protokolle über die Anwendung **Konsole** untersucht werden. --- **6. Betriebssystem- und Softwareupdates prüfen** **Windows** **Installierte Hotfixes anzeigen** `[RO] Get-HotFix | Sort-Object InstalledOn -Descending` **Ausgewählte Informationen darstellen** `[RO] Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object InstalledOn, HotFixID, Description, InstalledBy` **Windows-Update-Ereignisse anzeigen** `[RO] Get-WinEvent -LogName "Microsoft-Windows-WindowsUpdateClient/Operational" -MaxEvents 100 | Select-Object TimeCreated, Id, LevelDisplayName, Message` **Windows-Update-Ereignisse innerhalb eines Zeitfensters** `[RO] Get-WinEvent -FilterHashtable @{LogName="Microsoft-Windows-WindowsUpdateClient/Operational"; StartTime=[datetime]"2026-07-30 14:00:00"; EndTime=[datetime]"2026-07-30 15:00:00"}` **Windows-Update-Protokolldatei erzeugen** `[RO] Get-WindowsUpdateLog` Das Cmdlet erstellt aus den ETL-Dateien eine lesbare Windows-Update-Protokolldatei. **Grafischer Weg** `Einstellungen → Windows Update → Updateverlauf` > `Get-HotFix` zeigt nicht zwingend jede installierte Aktualisierung an. Die Ausgabe sollte deshalb mit dem Windows-Updateverlauf, dem Ereignisprotokoll und gegebenenfalls dem eingesetzten Patchmanagement verglichen werden. --- **Debian und Ubuntu** **APT-Transaktionsverlauf anzeigen** `[RO] less /var/log/apt/history.log` **DPKG-Aktivitäten anzeigen** `[RO] less /var/log/dpkg.log` **Installationen, Aktualisierungen und Deinstallationen suchen** `[RO] grep -E " install | upgrade | remove " /var/log/dpkg.log` Ältere Protokolle können rotiert und komprimiert vorliegen: `[RO] zgrep -hE " install | upgrade | remove " /var/log/dpkg.log*` --- **Red Hat Enterprise Linux, Rocky Linux, AlmaLinux und Fedora** **DNF-Transaktionen anzeigen** `[RO] dnf history list` **Details einer Transaktion anzeigen** `[RO] dnf history info ` **Letzte Transaktion untersuchen** `[RO] dnf history info last` **Installierte Pakete nach Installationszeit sortieren** `[RO] rpm -qa --last` --- **SUSE Linux Enterprise und openSUSE** **Zypper-Verlauf anzeigen** `[RO] less /var/log/zypp/history` **Nur Paketinstallationen anzeigen** `[RO] grep "|install|" /var/log/zypp/history` **Nur Paketaktualisierungen anzeigen** `[RO] grep "|update|" /var/log/zypp/history` --- **Arch Linux** **Paketmanager-Protokoll anzeigen** `[RO] less /var/log/pacman.log` **Paketänderungen suchen** `[RO] grep -E "\[ALPM\] (installed|upgraded|removed)" /var/log/pacman.log` --- **macOS** **Verlauf der Softwareupdates anzeigen** `[RO] softwareupdate --history` **Installationsverlauf anzeigen** `[RO] system_profiler SPInstallHistoryDataType` **Grafischer Weg** `Systeminformationen → Software → Installationen` Die Liste kann nach dem Installationsdatum sortiert werden. --- **7. Dienständerungen und Dienstabstürze prüfen** **Windows** Besonders interessante Ereignisse des Service Control Managers: | Ereignis-ID | Typische Bedeutung | |---:|---| | 7031 | Dienst wurde unerwartet beendet | | 7034 | Dienst wurde unerwartet beendet | | 7036 | Dienst hat seinen Status geändert | | 7040 | Starttyp eines Dienstes wurde geändert | | 7045 | Ein neuer Dienst wurde installiert | **Relevante Dienstereignisse abfragen** `[RO] Get-WinEvent -FilterHashtable @{LogName="System"; ProviderName="Service Control Manager"; Id=7031,7034,7036,7040,7045; StartTime=[datetime]"2026-07-30 14:00:00"; EndTime=[datetime]"2026-07-30 15:00:00"} | Select-Object TimeCreated, Id, Message` **Aktuellen Zustand eines Dienstes anzeigen** `[RO] Get-Service -Name ` **Dienstkonfiguration anzeigen** `[RO] Get-CimInstance Win32_Service -Filter "Name=''" | Select-Object Name, State, StartMode, StartName, PathName` --- **Linux** **Status eines Dienstes anzeigen** `[RO] systemctl status ` **Protokoll eines Dienstes anzeigen** `[RO] journalctl -u --since "2026-07-30 14:00:00" --until "2026-07-30 15:00:00"` **Fehlgeschlagene Dienste anzeigen** `[RO] systemctl --failed` **Zeitpunkt der Dienstaktivierung anzeigen** `[RO] systemctl show -p ActiveEnterTimestamp -p InactiveEnterTimestamp` --- **macOS** **Geladene launchd-Dienste anzeigen** `[RO] launchctl list` **Nach einem bestimmten Dienst suchen** `[RO] launchctl list | grep -i ""` **Prozessereignisse untersuchen** `[RO] log show --last 2h --predicate 'process == ""' --style compact` --- **8. Geplante und automatisierte Änderungen prüfen** Nicht jede Änderung wird manuell durch einen Administrator ausgelöst. Häufige Ursachen sind: - geplante Aufgaben - Cronjobs - Systemd-Timer - Wartungsskripte - Patchmanagement - Softwareverteilung - CI/CD-Pipelines - Konfigurationsmanagement - Gruppenrichtlinien - Backup- und Cleanup-Jobs - automatische Zertifikatserneuerung - automatische Skalierung oder Cloud-Automatisierung **Windows** **Geplante Aufgaben anzeigen** `[RO] Get-ScheduledTask` **Laufzeitinformationen anzeigen** `[RO] Get-ScheduledTask | Get-ScheduledTaskInfo | Sort-Object LastRunTime -Descending` **Aufgaben mit Fehlerergebnis suchen** `[RO] Get-ScheduledTask | Get-ScheduledTaskInfo | Where-Object {$_.LastTaskResult -ne 0}` **Task-Scheduler-Ereignisse anzeigen** `[RO] Get-WinEvent -LogName "Microsoft-Windows-TaskScheduler/Operational" -MaxEvents 100` > Ein von `0` abweichender Rückgabewert ist ein Hinweis, muss aber anhand der jeweiligen Aufgabe interpretiert werden. --- **Linux** **Systemd-Timer anzeigen** `[RO] systemctl list-timers --all` **Cronjobs des aktuellen Benutzers anzeigen** `[RO] crontab -l` **Systemweite Cron-Verzeichnisse prüfen** `[RO] ls -la /etc/cron.d /etc/cron.hourly /etc/cron.daily /etc/cron.weekly /etc/cron.monthly` **Cron-Ereignisse auf Debian und Ubuntu suchen** `[RO] journalctl -u cron --since "2026-07-30 14:00:00" --until "2026-07-30 15:00:00"` **Cron-Ereignisse auf RHEL-kompatiblen Systemen suchen** `[RO] journalctl -u crond --since "2026-07-30 14:00:00" --until "2026-07-30 15:00:00"` --- **macOS** **Geladene launchd-Aufträge anzeigen** `[RO] launchctl list` **Systemweite LaunchDaemons anzeigen** `[RO] ls -la /Library/LaunchDaemons` **Systemweite LaunchAgents anzeigen** `[RO] ls -la /Library/LaunchAgents` **Benutzerspezifische LaunchAgents anzeigen** `[RO] ls -la ~/Library/LaunchAgents` --- **9. Konfigurationsänderungen vergleichen** Wenn eine frühere Konfigurationsversion vorhanden ist, sollte sie mit dem aktuellen Zustand verglichen werden. **Windows PowerShell** `[RO] Compare-Object (Get-Content "") (Get-Content "")` **Linux und macOS** `[RO] diff -u "" ""` **Git-verwaltete Konfigurationen** `[RO] git status` `[RO] git diff` `[RO] git log --oneline --decorate -n 20` `[RO] git log -p -- ""` **Mögliche Quellen früherer Konfigurationen** - Konfigurationsmanagement - Versionsverwaltung - Systembackup - VM-Snapshot - Firewall-Konfigurationsbackup - Switch-Konfigurationsarchiv - Gruppenrichtlinien-Backup - Dokumentation - Export aus der Verwaltungsoberfläche - gewünschter Zustand aus Infrastructure as Code > Der aktuelle Zustand zeigt nur, wie das System jetzt konfiguriert ist. Ohne Auditierung, Versionsverwaltung oder Backup lässt sich daraus nicht zuverlässig ableiten, wann und durch wen eine Änderung vorgenommen wurde. --- **10. Änderungen an Netzwerkkomponenten prüfen** Bei Netzwerkstörungen sollten nicht nur Server und Clients betrachtet werden. | Komponente | Zu prüfende Änderungen | |---|---| | Switch | Portstatus, VLAN, Trunk, Port-Security, STP, Firmware | | Router | Routing, Interface, NAT, ACL, dynamisches Routing | | Firewall | Regelwerk, NAT, VPN, Objektgruppen, Zertifikate | | WLAN-Controller | SSID, VLAN-Zuordnung, Authentifizierung, Funkkanal | | DHCP-Server | Scope, Optionen, Reservierungen, Relay | | DNS-Server | Einträge, Zonen, Weiterleitungen, Replikation | | Load Balancer | Backend, Health Check, Zertifikat, Listener | | Proxy | Ausnahmen, Authentifizierung, Zertifikat, Filterregel | | NAC-System | Richtlinie, Geräteprofil, Quarantäne | | Provider | Wartung, Routingänderung, Störung | **Zu verwendende Informationsquellen** - Konfigurations- und Auditprotokoll des Gerätes - AAA-, TACACS+- oder RADIUS-Protokoll - Syslog-Server - SIEM - Netzwerkmanagementsystem - Monitoring - Konfigurationsbackup - Change-Ticket - Hersteller- oder Provider-Statusseite - Wartungsankündigungen **Besonders wichtige Angaben** - Benutzer- oder Automationskonto - Zeitpunkt - Quell-IP-Adresse - betroffene Komponente - alter Wert - neuer Wert - Commit-, Revisions- oder Transaktions-ID - zugehörige Ticketnummer --- **11. Active Directory und Gruppenrichtlinien prüfen** Mögliche relevante Änderungen: - Benutzer wurde deaktiviert oder gesperrt - Gruppenmitgliedschaft wurde geändert - Computerobjekt wurde verschoben oder gelöscht - Gruppenrichtlinie wurde geändert - Gruppenrichtlinie wurde neu verknüpft - Sicherheitsfilterung wurde verändert - DNS- oder Replikationsproblem trat auf - Dienstkonto oder Kennwort wurde geändert - Berechtigung wurde entzogen - Vertrauensstellung wurde verändert **Windows-Sicherheitsprotokoll nach Änderungen durchsuchen** `[RO] Get-WinEvent -FilterHashtable @{LogName="Security"; StartTime=[datetime]"2026-07-30 14:00:00"; EndTime=[datetime]"2026-07-30 15:00:00"} | Select-Object TimeCreated, Id, Message` Der Zugriff auf das Sicherheitsprotokoll benötigt entsprechende Berechtigungen. **Resultierende Gruppenrichtlinien anzeigen** `[RO] gpresult /r` **Ausführlichen HTML-Bericht erstellen** `[RO] gpresult /h "\gpresult.html"` > Das Erstellen der HTML-Datei ist keine reine Leseoperation, verändert aber keine Systemkonfiguration. Es wird lediglich eine Berichtsdatei geschrieben. **Zeitpunkt der letzten Richtlinienverarbeitung prüfen** `[RO] Get-WinEvent -LogName "Microsoft-Windows-GroupPolicy/Operational" -MaxEvents 100` Für eine zuverlässige Nachverfolgung von Änderungen müssen die passenden Überwachungsrichtlinien bereits vor dem Vorfall aktiviert worden sein. --- **12. Cloud- und SaaS-Änderungen prüfen** Je nach Umgebung sind unter anderem folgende Protokolle relevant: | Plattform | Typische Quelle | |---|---| | Microsoft Entra ID | Überwachungsprotokolle und Anmeldeprotokolle | | Microsoft 365 | Einheitliches Überwachungsprotokoll | | Microsoft Azure | Activity Log und Resource Logs | | Amazon Web Services | AWS CloudTrail | | Google Cloud | Cloud Audit Logs | | VMware vCenter | Tasks und Events | | Proxmox VE | Task History und Systemprotokoll | | Backup-System | Job-, Audit- und Konfigurationsverlauf | | Endpoint-Management | Geräte-, Richtlinien- und Bereitstellungsverlauf | | Softwareverteilung | Deployment- und Installationsstatus | Zu prüfen sind insbesondere: - Wer führte die Änderung aus? - Wurde die Änderung manuell oder automatisiert ausgeführt? - Von welcher Quell-IP kam die Aktion? - Welche Ressource wurde verändert? - Was war der vorherige Wert? - Was ist der aktuelle Wert? - War die Änderung erfolgreich? - Gibt es eine zugehörige Ticket-, Job- oder Request-ID? --- **13. Zeitachse erstellen** Alle relevanten Ereignisse werden in einer gemeinsamen Zeitachse dokumentiert. | Zeit | Quelle oder System | Ereignis oder Änderung | Benutzer oder Prozess | Beleg | Bewertung | |---|---|---|---|---|---| | 13:50 | Client-PC | Anmeldung erfolgreich | Max Mustermann | Benutzerangabe | Letzter funktionierender Zustand | | 14:10 | Windows Server | Sicherheitsupdate installiert | Patchmanagement | Updateverlauf | Zeitlich auffällig | | 14:31 | Switch | Port in anderes VLAN verschoben | Admin-Konto | Auditprotokoll | Technisch passend | | 14:35 | Client-PC | Anmeldung nicht mehr möglich | Max Mustermann | Ticket und Ereignisprotokoll | Erste bekannte Störung | | 14:42 | Monitoring | Domänencontroller weiterhin erreichbar | Monitoring-System | Messwert | Serverausfall unwahrscheinlich | | 15:12 | Testport | Anmeldung funktioniert | Testbenutzer | Kreuztest | Switchport als Fehlerbereich bestätigt | Dieses Beispiel zeigt: - Das Windows-Update fand zwar vor der Störung statt. - Die VLAN-Änderung liegt jedoch näher am ersten Fehler. - Das Fehlerbild passt technisch zur VLAN-Änderung. - Der Kreuztest über einen anderen Switchport bestätigt den Zusammenhang. - Das Update war lediglich zeitlich auffällig, aber nicht die wahrscheinlichste Ursache. --- **14. Änderungen bewerten** Nicht jede gefundene Änderung besitzt dieselbe Bedeutung. | Kriterium | Frage | |---|---| | Zeitliche Nähe | Liegt die Änderung kurz vor dem ersten Fehler? | | Technische Plausibilität | Kann die Änderung genau dieses Fehlerbild verursachen? | | Betroffener Umfang | Entspricht der Änderungsumfang den betroffenen Benutzern oder Systemen? | | Reproduzierbarkeit | Tritt der Fehler nach der Änderung zuverlässig auf? | | Gegenprobe | Funktioniert es ohne die Änderung oder auf einem unveränderten Vergleichssystem? | | Protokollbeleg | Gibt es passende Fehler, Warnungen oder Statusänderungen? | | Abhängigkeiten | Betrifft die Änderung einen abhängigen Dienst oder ein vorgelagertes System? | | Vergleichswerte | Funktionieren nicht geänderte Systeme weiterhin? | | Bekanntes Problem | Ist das Verhalten vom Hersteller dokumentiert? | **Praktische Priorisierung** | Bewertung | Bedeutung | |---|---| | Hoch | Änderung liegt im Zeitfenster, passt technisch und wird durch Tests gestützt | | Mittel | Änderung liegt im Zeitfenster und ist technisch möglich, aber noch nicht bestätigt | | Niedrig | Änderung liegt nur zeitlich nahe, passt aber kaum zum Fehlerbild | | Ausgeschlossen | Gegenprobe oder Messung widerlegt den Zusammenhang | --- **15. Korrelation und Ursache unterscheiden** **Nur Korrelation** - Update wurde am selben Tag installiert. - Fehler wurde später gemeldet. - Es gibt keine passende Fehlermeldung. - Andere identisch aktualisierte Systeme funktionieren. - Eine Deinstallation verändert das Fehlerbild nicht. **Wahrscheinlicher ursächlicher Zusammenhang** - Fehler trat unmittelbar nach der Änderung auf. - Nur geänderte Systeme sind betroffen. - Nicht geänderte Vergleichssysteme funktionieren. - Protokolle zeigen passende Fehler. - Der Fehler lässt sich reproduzieren. - Eine kontrollierte Rücknahme beseitigt den Fehler. - Erneutes Anwenden der Änderung erzeugt den Fehler wieder. Die stärkste Bestätigung entsteht durch einen kontrollierten A/B-Test: | Zustand A | Zustand B | Schlussfolgerung | |---|---|---| | Änderung vorhanden, Fehler vorhanden | Änderung entfernt, Fehler verschwunden | Zusammenhang wahrscheinlich | | Änderung vorhanden, Fehler vorhanden | Änderung entfernt, Fehler bleibt | Änderung vermutlich nicht ursächlich | | Geändertes System gestört | Unverändertes Vergleichssystem funktioniert | Änderung oder Systemunterschied priorisieren | | Beide Systeme gestört | Gemeinsame Abhängigkeit untersuchen | Lokale Änderung weniger wahrscheinlich | --- **16. Vor einem Rollback beachten** Eine Änderung darf nicht allein aufgrund zeitlicher Nähe unüberlegt zurückgenommen werden. Vor einem Rollback sollten folgende Punkte geklärt sein: - Ist die Änderung dokumentiert? - Ist der ursprüngliche Zustand bekannt? - Existiert eine getestete Rückfallmöglichkeit? - Werden Sicherheitslücken erneut geöffnet? - Entstehen Abhängigkeiten zu anderen Änderungen? - Ist eine Freigabe erforderlich? - Sind Konfiguration, Protokolle und Beweise gesichert? - Kann die Auswirkung des Rollbacks überwacht werden? - Gibt es einen Wartungszeitraum? - Kann das System nach dem Rollback vollständig getestet werden? **Sicheres Vorgehen** 1. Aktuellen Zustand dokumentieren. 2. Relevante Protokolle und Konfigurationen sichern. 3. Rollback-Auswirkungen bewerten. 4. Freigabe einholen. 5. Möglichst nur eine Änderung zurücknehmen. 6. Den ursprünglichen Fehler erneut testen. 7. Abhängige Funktionen prüfen. 8. Ergebnis und Uhrzeit dokumentieren. 9. System anschließend weiter beobachten. > Ein Rollback ist selbst eine Änderung und kann neue Störungen verursachen. --- **17. Häufige Fehler bei der Änderungsanalyse** | Fehler | Folge | Besseres Vorgehen | |---|---|---| | Erstbeste Änderung wird beschuldigt | Falsche Ursache wird verfolgt | Technische Plausibilität und Gegenprobe prüfen | | Nur der Server wird untersucht | Netzwerk-, Client- oder Cloud-Änderung bleibt unentdeckt | Gesamten Kommunikationsweg betrachten | | Uhrzeiten werden ungeprüft verglichen | Falsche Ereignisreihenfolge | Uhrzeit, Zeitzone und Synchronisation prüfen | | Nur Fehlerereignisse werden gelesen | Wichtige Informationsereignisse fehlen | Auch Starts, Stopps und Statusänderungen prüfen | | Aktueller Zustand wird als Verlauf interpretiert | Zeitpunkt und Urheber bleiben unbekannt | Audit-, Versions- und Änderungsprotokolle verwenden | | Mehrere Änderungen werden gleichzeitig zurückgenommen | Ursache kann nicht mehr zugeordnet werden | Möglichst eine Variable pro Test verändern | | Protokolle werden erst nach Neustart gesichert | Flüchtige Informationen gehen verloren | Beweise vor Änderungen und Neustarts sichern | | Benutzerangabe wird als exakter Fehlerbeginn behandelt | Suchzeitraum wird zu eng gewählt | Letzten sicheren Funktionstest und erste sichere Störung trennen | | Nur geplante Änderungen werden geprüft | Automatische oder unautorisierte Änderung fehlt | Audit-, Deployment- und Automationsprotokolle einbeziehen | | Provider oder SaaS wird vergessen | Externe Störung bleibt unberücksichtigt | Service Health und Anbieterstatus prüfen | --- **18. Dokumentationsvorlage** | Feld | Eintrag | |---|---| | Letzter bekannter funktionierender Zustand | | | Quelle dieser Information | | | Erste bekannte Störung | | | Quelle dieser Information | | | Verwendete Zeitzone | | | Zeitabweichungen festgestellt | Ja / Nein | | Letzter Systemstart | | | Änderungen im Zeitfenster | | | Verantwortlicher Benutzer oder Prozess | | | Zugehöriges Change-Ticket | | | Technische Plausibilität | Hoch / Mittel / Niedrig | | Protokollbeleg vorhanden | Ja / Nein | | Vergleichssystem geprüft | Ja / Nein | | Gegenprobe durchgeführt | Ja / Nein | | Rollback durchgeführt | Ja / Nein | | Ergebnis | | | Vermutete Ursache | | | Ursache bestätigt | Ja / Nein | | Noch offene Prüfungen | | --- **Kurzcheckliste** - [ ] Letzten funktionierenden Zustand bestimmt - [ ] Erste bekannte Störung bestimmt - [ ] Meldezeitpunkt nicht mit Fehlerbeginn verwechselt - [ ] Uhrzeit und Zeitzone aller beteiligten Systeme geprüft - [ ] Letzte Neustarts geprüft - [ ] Betriebssystemupdates geprüft - [ ] Softwareinstallationen und Paketänderungen geprüft - [ ] Dienststarts, Dienststopps und Abstürze geprüft - [ ] Geplante Aufgaben und Automatisierungen geprüft - [ ] Netzwerk- und Firewalländerungen geprüft - [ ] DNS-, DHCP- und Active-Directory-Änderungen geprüft - [ ] Cloud- und SaaS-Auditprotokolle geprüft - [ ] Konfiguration mit früherem Zustand verglichen - [ ] Gemeinsame Zeitachse erstellt - [ ] Zeitliche Korrelation von bestätigter Ursache getrennt - [ ] Ursache durch Messung, Vergleich oder Gegenprobe geprüft - [ ] Beweise vor Neustart oder Rollback gesichert - [ ] Ergebnisse im Ticket dokumentiert --- **Ergebnis dieses Arbeitsschrittes** Am Ende sollte eine nachvollziehbare Zeitachse vorliegen. Darin stehen der letzte funktionierende Zustand, der erste bekannte Fehler und alle technisch relevanten Änderungen dazwischen. Eine Änderung gilt erst dann als wahrscheinliche Ursache, wenn sie: - zeitlich zum Fehler passt, - das Fehlerbild technisch erklären kann, - den tatsächlich betroffenen Umfang erklärt und - möglichst durch einen Vergleichs- oder Rücknahmetest bestätigt wurde. **Nächste Seite:** **1.4 Flüchtige Informationen und Beweise sichern** --- **Quellen und weiterführende Dokumentation** - [Microsoft Learn – Get-WinEvent](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.diagnostics/get-winevent) - [Microsoft Learn – Get-HotFix](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.management/get-hotfix) - [Microsoft Learn – Windows-Update-Protokolldateien](https://learn.microsoft.com/en-us/windows/deployment/update/windows-update-logs) - [Microsoft Learn – Problembehandlung bei Windows-Server-Updates](https://learn.microsoft.com/en-us/troubleshoot/windows-server/installing-updates-features-roles/troubleshoot-windows-server-update-guidance) - [Microsoft Learn – Windows-Ereignisanzeige](https://learn.microsoft.com/en-us/shows/inside/event-viewer) - [freedesktop.org – journalctl](https://www.freedesktop.org/software/systemd/man/latest/journalctl.html) - [Red Hat – Configuring basic system settings](https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/configuring_basic_system_settings/) - [Apple Support – Anzeigen von Protokollmeldungen in der Konsole](https://support.apple.com/guide/console/log-messages-cnsl1012/mac) - [Apple Support – Installationsverlauf auf einem Mac anzeigen](https://support.apple.com/en-us/101591) # 1.4 Flüchtige Informationen und Beweise sichern **1.4 Flüchtige Informationen und Beweise sichern** Bei einer Störung ist der erste Impuls häufig: - Anwendung neu starten - Dienst neu starten - Computer neu starten - Kabel abziehen - DNS-Cache leeren - Prozess beenden - Update installieren - Konfiguration zurücksetzen Diese Maßnahmen können die Funktion wiederherstellen. Gleichzeitig können sie jedoch genau die Informationen vernichten, die zur Ermittlung der Ursache benötigt werden. Deshalb gilt: > Erst den aktuellen Zustand sichern, danach kontrolliert verändern. Ein Neustart beseitigt unter anderem laufende Prozesse, bestehende Netzwerkverbindungen, Speicherinhalte, temporäre Zustände und Teile von Caches. Die Störung kann anschließend verschwunden sein, ohne dass ihre Ursache bekannt ist. --- **Ziel dieser Seite** Nach diesem Arbeitsschritt sollten: - Fehlermeldung und genauer Zeitpunkt dokumentiert sein, - aktuelle Prozesse und Dienste erfasst sein, - Netzwerkzustand und Verbindungen erfasst sein, - relevante Protokolle exportiert sein, - wichtige Systemzustände dokumentiert sein, - die gesammelten Dateien eindeutig zugeordnet sein, - sensible Diagnosedaten geschützt sein, - normale Störungsdiagnose und Sicherheitsvorfall unterschieden sein, - erst anschließend kontrollierte Änderungen vorgenommen werden. --- **1. Das Stop–Sichern–Ändern-Prinzip** | Phase | Tätigkeit | |---|---| | Stop | Nicht sofort neu starten, zurücksetzen oder bereinigen | | Sichern | Flüchtige Zustände, Fehlermeldungen und Protokolle erfassen | | Bewerten | Dringlichkeit und mögliches Sicherheitsrisiko beurteilen | | Ändern | Eine kontrollierte Maßnahme durchführen | | Prüfen | Ursprünglichen Fehler erneut testen | | Dokumentieren | Maßnahme, Zeitpunkt und Ergebnis festhalten | Dieses Vorgehen verhindert, dass eine erfolgreiche Sofortmaßnahme die spätere Ursachenanalyse unmöglich macht. --- **2. Was sind flüchtige Informationen?** Flüchtige Informationen verändern sich während des laufenden Betriebs oder gehen beim Neustart verloren. | Information | Warum flüchtig? | |---|---| | Arbeitsspeicher | Inhalt geht beim Ausschalten oder Neustart verloren | | Laufende Prozesse | Werden beendet und beim Start möglicherweise anders aufgebaut | | Prozess-IDs | Werden nach einem Neustart oder Prozessstart neu vergeben | | Netzwerkverbindungen | TCP-Sitzungen und temporäre Verbindungen werden beendet | | Offene Dateien | Zuordnung zwischen Prozess und Datei geht verloren | | ARP-/Neighbor-Cache | Wird automatisch aktualisiert oder beim Neustart geleert | | DNS-Cache | Einträge laufen ab oder werden geleert | | Routingzustand | Dynamische Routen können sich verändern | | Angemeldete Benutzer | Sitzungen werden beendet | | Temporäre Dateien | Können automatisch entfernt werden | | Zwischenspeicher | Ändern sich durch normalen Betrieb | | Auslastungswerte | CPU-, RAM-, Datenträger- und Netzwerklast ändern sich fortlaufend | | Live-Protokollmeldungen | Können durch Logrotation oder begrenzte Speichergröße verschwinden | | Fehlermeldung auf dem Bildschirm | Verschwindet nach Schließen der Anwendung | | Zustand eines hängenden Prozesses | Geht beim Beenden oder Neustart verloren | --- **3. Reihenfolge nach Flüchtigkeit** RFC 3227 empfiehlt, Beweise grundsätzlich von den flüchtigsten zu den weniger flüchtigen Informationen zu sichern. Für die praktische Störungsanalyse kann folgende Reihenfolge verwendet werden: | Priorität | Zu sichernde Information | Beispiel | |---:|---|---| | 1 | Sichtbare Fehlermeldung und Uhrzeit | Screenshot, Fehlercode, betroffene Funktion | | 2 | Laufende Prozesse und Arbeitsspeicherzustand | Prozessliste, CPU- und RAM-Auslastung | | 3 | Aktive Netzwerkverbindungen | TCP-/UDP-Verbindungen, Quell- und Zieladressen | | 4 | Temporäre Netzwerkinformationen | ARP-, Neighbor- und DNS-Cache | | 5 | Angemeldete Benutzer und Sitzungen | Lokale, RDP-, SSH- oder Konsolensitzungen | | 6 | Dienst- und Anwendungszustand | Laufende, gestoppte oder fehlgeschlagene Dienste | | 7 | Aktuelle System- und Kernelmeldungen | Ereignisanzeige, Journal, Unified Log | | 8 | Temporäre Dateien und Laufzeitdaten | PID-Dateien, Sockets, temporäre Verzeichnisse | | 9 | Permanente Protokolle und Konfigurationen | Logdateien, Registry, Konfigurationsdateien | | 10 | Zentrale und externe Daten | SIEM, Monitoring, Firewall, Cloud-Audit | | 11 | Backups und Archivdaten | ältere Konfigurationen, Images, Sicherungen | Die konkrete Reihenfolge muss an den Vorfall angepasst werden. Bei einer laufenden Verschlüsselung oder Datenübertragung kann die Eindämmung wichtiger sein als eine vollständige Sammlung. --- **4. Normale Störung oder möglicher Sicherheitsvorfall?** Vor der Sammlung muss grob eingeschätzt werden, ob es sich um einen normalen technischen Fehler oder einen möglichen Sicherheitsvorfall handelt. | Normale technische Störung | Möglicher Sicherheitsvorfall | |---|---| | Dienst reagiert nicht | Unbekannter oder verdächtiger Prozess | | Festplatte ist voll | Viele Dateien werden unerwartet verschlüsselt | | DNS-Eintrag ist falsch | Unbekannte externe Netzwerkverbindungen | | Update verursacht Kompatibilitätsfehler | Sicherheitssoftware meldet Schadsoftware | | Anwendung ist abgestürzt | Neue unbekannte Administratorkonten | | Netzwerkkabel ist defekt | Protokolle wurden gelöscht oder deaktiviert | | Berechtigung wurde falsch gesetzt | Massenhafte fehlgeschlagene Anmeldungen | | Zertifikat ist abgelaufen | Daten werden unerwartet nach außen übertragen | | Systemressourcen sind ausgelastet | Sicherheitsrichtlinien wurden unerlaubt verändert | | Konfiguration ist fehlerhaft | Ransomware-Nachricht oder Erpressung | **Bei einer normalen Störung** - relevante Zustände sichern, - anschließend kontrollierte Tests durchführen, - pro Test möglichst nur eine Variable verändern, - Ergebnisse dokumentieren. **Bei einem möglichen Sicherheitsvorfall** - Incident-Response-Prozess aktivieren, - zuständige Sicherheitsverantwortliche informieren, - keine unkoordinierten Änderungen durchführen, - keine verdächtigen Dateien öffnen, - keine Protokolle löschen, - keine eigenständige Schadsoftwarebereinigung starten, - System nicht unüberlegt ausschalten, - alle eigenen Aktionen und Uhrzeiten dokumentieren, - Eindämmungsmaßnahmen nach dem vorgesehenen Notfallplan durchführen. > Bei laufender Verschlüsselung, aktiver Ausbreitung oder möglichem Datenabfluss kann eine schnelle Netzwerkisolation erforderlich sein. Die Entscheidung sollte nach dem Incident-Response-Plan und durch die zuständige Stelle erfolgen. Die Beweissicherung darf eine notwendige Eindämmung nicht gefährlich verzögern. --- **5. Was vor der Sicherung vermieden werden sollte** | Maßnahme | Möglicher Informationsverlust | |---|---| | Computer neu starten | Prozesse, Arbeitsspeicher und Verbindungen gehen verloren | | Dienst neu starten | ursprünglicher Dienstzustand und Prozess-ID gehen verloren | | Anwendung schließen | Fehlermeldung und Prozesszustand verschwinden | | Prozess beenden | offene Dateien, Verbindungen und Speicherzustand gehen verloren | | `ipconfig /flushdns` ausführen | Windows-DNS-Cache wird geleert | | ARP- oder Neighbor-Cache leeren | Zuordnung zwischen IP- und MAC-Adressen geht verloren | | Protokolle leeren | Ereignisse werden dauerhaft entfernt | | Datenträgerbereinigung starten | temporäre Dateien und mögliche Belege verschwinden | | Update installieren | Ausgangszustand wird verändert | | Konfiguration zurücksetzen | fehlerverursachende Einstellung ist nicht mehr nachvollziehbar | | Snapshot zurückspielen | aktueller Systemzustand wird überschrieben | | Sicherheitssoftware vollständig scannen lassen | Dateien können verändert, verschoben oder gelöscht werden | | Diagnosewerkzeuge unkontrolliert installieren | Systemzustand und Zeitstempel verändern sich | | Kabel sofort abziehen | Netzwerkzustand und Verbindungen gehen verloren | | Browser oder Anwendung neu laden | Sitzung, Cache und Fehlermeldung können verändert werden | Diese Maßnahmen sind nicht grundsätzlich falsch. Sie sollten nur möglichst erst nach der Sicherung des relevanten Ausgangszustands erfolgen. --- **6. Kennzeichnung der Befehle** | Kennzeichnung | Bedeutung | |---|---| | `[RO]` | Liest Informationen aus und soll keine Konfiguration verändern | | `[FILE]` | Erstellt oder überschreibt eine Ausgabedatei | | `[PRIV]` | Benötigt möglicherweise Administrator- oder Root-Rechte | | `[ACTIVE]` | Startet eine aktive Messung oder Aufzeichnung | | `[SENSITIV]` | Ausgabe kann vertrauliche oder personenbezogene Daten enthalten | > Auch ein `[RO]`-Befehl erzeugt einen Prozess und kann Spuren in Protokollen, Shell-Historien oder Zugriffsdaten hinterlassen. Für eine normale Störungsdiagnose ist das meist vertretbar. Bei einer forensischen Untersuchung müssen die freigegebenen Werkzeuge und Verfahren der Organisation verwendet werden. --- **7. Fehlermeldung vollständig sichern** Folgende Informationen sollten erfasst werden: - vollständiger Fehlertext - Fehlernummer oder Fehlercode - Uhrzeit einschließlich Zeitzone - betroffene Anwendung oder Funktion - Benutzeraktion unmittelbar vor dem Fehler - Benutzerkonto oder technisches Konto - Hostname und IP-Adresse - verwendete URL, Serveradresse oder Freigabe - sichtbarer Anwendungszustand - Häufigkeit und Reproduzierbarkeit - betroffene und nicht betroffene Systeme - verwendeter Screenshot-Dateiname - zugehörige Ticketnummer **Guter Screenshot** Ein guter Screenshot zeigt: - die vollständige Fehlermeldung, - die Titelleiste der Anwendung, - den sichtbaren Kontext, - gegebenenfalls die Adresszeile, - Datum und Uhrzeit, - keine unnötigen geheimen Daten. Ein zu stark zugeschnittener Screenshot kann wichtige Informationen wie Anwendung, Zielsystem oder Zeitpunkt entfernen. **Bei einem möglichen Sicherheitsvorfall** Wenn jede Interaktion mit dem System vermieden werden soll, kann der Bildschirm mit einem zweiten Gerät fotografiert werden. Dabei sind Datenschutz- und Unternehmensrichtlinien zu beachten. --- **8. Aktuellen Zeitpunkt zuerst dokumentieren** **Windows** `[RO] Get-Date -Format o` `[RO] (Get-Date).ToUniversalTime().ToString("o")` `[RO] Get-TimeZone` `[RO] w32tm /query /status` **Linux** `[RO] date --iso-8601=seconds` `[RO] date -u "+%Y-%m-%dT%H:%M:%SZ"` `[RO] timedatectl status` **macOS** `[RO] date "+%Y-%m-%dT%H:%M:%S%z"` `[RO] date -u "+%Y-%m-%dT%H:%M:%SZ"` `[RO] systemsetup -gettimezone` Die Zeitprüfung ist wichtig, damit lokale Systemereignisse mit Firewall-, Server-, Cloud- und Monitoring-Protokollen verglichen werden können. --- **9. Grundzustand des Systems erfassen** **Windows** | Information | Befehl | |---|---| | Hostname | `[RO] hostname` | | Betriebssystem | `[RO] Get-ComputerInfo` | | Windows-Version kompakt | `[RO] Get-CimInstance Win32_OperatingSystem \| Select-Object Caption, Version, BuildNumber, LastBootUpTime` | | Betriebsdauer | `[RO] (Get-Date) - (Get-CimInstance Win32_OperatingSystem).LastBootUpTime` | | Aktueller Benutzer | `[RO] whoami` | | Benutzer und Gruppen | `[RO][SENSITIV] whoami /all` | | Angemeldete Sitzungen | `[RO] quser` | | Umgebungsvariablen | `[RO][SENSITIV] Get-ChildItem Env:` | | Laufwerke | `[RO] Get-Volume` | | Datenträgerbelegung | `[RO] Get-PSDrive -PSProvider FileSystem` | > Umgebungsvariablen können Token, Zugangsdaten, interne Pfade oder andere vertrauliche Werte enthalten. Sie sollten nur erfasst werden, wenn sie für die Störung relevant sind. --- **Linux** | Information | Befehl | |---|---| | Hostname und System | `[RO] hostnamectl` | | Kernel und Architektur | `[RO] uname -a` | | Distribution | `[RO] cat /etc/os-release` | | Betriebsdauer | `[RO] uptime` | | Letzter Systemstart | `[RO] uptime -s` | | Angemeldete Benutzer | `[RO] who -a` | | Benutzeraktivität | `[RO] w` | | Aktueller Benutzer | `[RO] id` | | Dateisystembelegung | `[RO] df -hT` | | Blockgeräte | `[RO] lsblk -f` | | Arbeitsspeicher | `[RO] free -h` | --- **macOS** | Information | Befehl | |---|---| | Hostname | `[RO] hostname` | | macOS-Version | `[RO] sw_vers` | | Kernel und Architektur | `[RO] uname -a` | | Systemübersicht | `[RO] system_profiler SPSoftwareDataType SPHardwareDataType` | | Betriebsdauer | `[RO] uptime` | | Letzter Systemstart | `[RO] sysctl -n kern.boottime` | | Angemeldete Benutzer | `[RO] who` | | Aktueller Benutzer | `[RO] id` | | Dateisystembelegung | `[RO] df -h` | | Arbeitsspeicher | `[RO] vm_stat` | --- **10. Laufende Prozesse sichern** Eine Prozessliste sollte möglichst vor dem Beenden oder Neustarten einer Anwendung erfasst werden. **Windows PowerShell** **Prozessübersicht** `[RO] Get-Process | Sort-Object CPU -Descending` **Prozess, übergeordneter Prozess und Befehlszeile** `[RO][SENSITIV] Get-CimInstance Win32_Process | Select-Object ProcessId, ParentProcessId, Name, ExecutablePath, CommandLine` **Prozess anhand der Prozess-ID untersuchen** `[RO] Get-Process -Id | Format-List *` **Prozesse mit hoher Speichernutzung** `[RO] Get-Process | Sort-Object WorkingSet64 -Descending | Select-Object -First 20 Name, Id, CPU, WorkingSet64` --- **Linux** **Vollständige Prozessliste** `[RO][SENSITIV] ps auxww` **Prozessbaum** `[RO][SENSITIV] ps -ef --forest` **Prozesse nach CPU-Auslastung** `[RO] ps aux --sort=-%cpu | head -n 20` **Prozesse nach Speichernutzung** `[RO] ps aux --sort=-%mem | head -n 20` **Aktuellen Systemzustand einmalig ausgeben** `[RO] top -b -n 1` **Offene Dateien eines Prozesses** `[RO][PRIV][SENSITIV] lsof -p ` --- **macOS** **Vollständige Prozessliste** `[RO][SENSITIV] ps auxww` **Prozesse nach CPU-Auslastung** `[RO] top -l 1 -o cpu` **Prozesse nach Speichernutzung** `[RO] top -l 1 -o mem` **Offene Dateien eines Prozesses** `[RO][PRIV][SENSITIV] lsof -p ` --- **11. Aktive Netzwerkverbindungen sichern** Netzwerkverbindungen sollten vor dem Beenden eines Prozesses, dem Trennen des Netzwerks oder einem Neustart gesichert werden. **Windows** **TCP-Verbindungen** `[RO][PRIV] Get-NetTCPConnection` **TCP-Verbindungen mit zugehörigem Prozess** `[RO][PRIV] Get-NetTCPConnection | Select-Object LocalAddress, LocalPort, RemoteAddress, RemotePort, State, OwningProcess` **UDP-Endpunkte** `[RO][PRIV] Get-NetUDPEndpoint` **Klassische Übersicht** `[RO][PRIV] netstat -ano` Die letzte Spalte enthält unter Windows die Prozess-ID. **Prozess zu einer PID ermitteln** `[RO] Get-Process -Id ` --- **Linux** **TCP-, UDP- und lauschende Sockets** `[RO][PRIV] ss -tulpn` **Alle TCP-Verbindungen** `[RO][PRIV] ss -tanp` **Alle UDP-Endpunkte** `[RO][PRIV] ss -uanp` **Prozesse mit Netzwerkverbindungen** `[RO][PRIV][SENSITIV] lsof -nP -i` Ohne Root-Rechte werden möglicherweise nicht alle Prozessinformationen angezeigt. --- **macOS** **Aktive TCP-Verbindungen** `[RO] netstat -anv -p tcp` **UDP-Endpunkte** `[RO] netstat -anv -p udp` **Lauschende TCP-Prozesse** `[RO][PRIV] lsof -nP -iTCP -sTCP:LISTEN` **Bestehende TCP-Verbindungen** `[RO][PRIV] lsof -nP -iTCP -sTCP:ESTABLISHED` --- **12. Netzwerkkonfiguration und Caches sichern** **Windows** | Information | Befehl | |---|---| | Vollständige IP-Konfiguration | `[RO] ipconfig /all` | | PowerShell-Netzwerkübersicht | `[RO] Get-NetIPConfiguration` | | Routingtabelle | `[RO] route print` | | PowerShell-Routen | `[RO] Get-NetRoute` | | ARP-/Neighbor-Cache | `[RO] arp -a` | | PowerShell-Neighbor-Tabelle | `[RO] Get-NetNeighbor` | | DNS-Cache | `[RO][SENSITIV] ipconfig /displaydns` | | PowerShell-DNS-Cache | `[RO][SENSITIV] Get-DnsClientCache` | | Proxykonfiguration | `[RO] netsh winhttp show proxy` | --- **Linux** | Information | Befehl | |---|---| | IP-Adressen und Interfaces | `[RO] ip -details address show` | | Linkzustand | `[RO] ip -details link show` | | Alle Routingtabellen | `[RO] ip route show table all` | | IPv6-Routen | `[RO] ip -6 route show table all` | | Neighbor-Tabelle | `[RO] ip neigh show` | | Resolverzustand | `[RO] resolvectl status` | | DNS-Konfiguration | `[RO] cat /etc/resolv.conf` | | NetworkManager-Verbindungen | `[RO][SENSITIV] nmcli connection show` | | NetworkManager-Geräte | `[RO] nmcli device status` | `resolvectl` ist nur vorhanden, wenn die entsprechende systemd-Komponente verwendet wird. --- **macOS** | Information | Befehl | |---|---| | Interfaces und IP-Adressen | `[RO] ifconfig -a` | | Routingtabelle | `[RO] netstat -rn` | | Standardroute | `[RO] route -n get default` | | ARP-Cache | `[RO] arp -an` | | DNS-Konfiguration | `[RO][SENSITIV] scutil --dns` | | Netzwerkdienste | `[RO] networksetup -listallnetworkservices` | | Hardwareports | `[RO] networksetup -listallhardwareports` | | Proxykonfiguration | `[RO] scutil --proxy` | --- **13. Dienstzustand sichern** **Windows** **Alle Dienste anzeigen** `[RO] Get-Service | Sort-Object Status, Name` **Detaillierte Dienstinformationen** `[RO][SENSITIV] Get-CimInstance Win32_Service | Select-Object Name, State, StartMode, StartName, ProcessId, PathName` **Nur beendete automatisch startende Dienste** `[RO] Get-CimInstance Win32_Service | Where-Object {$_.StartMode -eq "Auto" -and $_.State -ne "Running"} | Select-Object Name, State, StartMode` --- **Linux** **Fehlgeschlagene Dienste** `[RO] systemctl --failed` **Laufende Dienste** `[RO] systemctl list-units --type=service --state=running` **Alle installierten Diensteinheiten** `[RO] systemctl list-unit-files --type=service` **Bestimmten Dienst untersuchen** `[RO] systemctl status --no-pager` --- **macOS** **Geladene launchd-Dienste** `[RO] launchctl list` **Nach einem Dienst suchen** `[RO] launchctl list | grep -i ""` --- **14. Ressourcen- und Datenträgerzustand sichern** **Windows** | Information | Befehl | |---|---| | Laufwerke und freier Speicher | `[RO] Get-Volume` | | Dateisystemlaufwerke | `[RO] Get-PSDrive -PSProvider FileSystem` | | Speicherauslastung pro Prozess | `[RO] Get-Process \| Sort-Object WorkingSet64 -Descending` | | Datenträgerstatus | `[RO] Get-PhysicalDisk` | | Ereignisse zu Datenträgern | `[RO] Get-WinEvent -FilterHashtable @{LogName="System"; ProviderName="disk"} -MaxEvents 50` | --- **Linux** | Information | Befehl | |---|---| | Arbeitsspeicher | `[RO] free -h` | | Dateisystembelegung | `[RO] df -hT` | | Inode-Belegung | `[RO] df -ih` | | Blockgeräte | `[RO] lsblk -f` | | Mounts | `[RO] findmnt` | | Kernelmeldungen | `[RO][PRIV] dmesg --ctime` | | Laufende I/O-Statistik | `[RO][ACTIVE] iostat -xz 1 5` | `iostat` ist nicht auf jeder Installation vorhanden und gehört üblicherweise zum Paket `sysstat`. --- **macOS** | Information | Befehl | |---|---| | Arbeitsspeicherstatistik | `[RO] vm_stat` | | Dateisystembelegung | `[RO] df -h` | | Laufwerke und Partitionen | `[RO] diskutil list` | | Datenträgerinformationen | `[RO] diskutil info ` | | Laufende I/O-Statistik | `[RO][ACTIVE] iostat -w 1 -c 5` | --- **15. Protokolle exportieren** Protokolle sollten möglichst in ihrem nativen Format gesichert werden. Dadurch bleiben zusätzliche Felder, Ereigniskennungen und Metadaten erhalten. --- **Windows-Ereignisprotokolle exportieren** Zuerst muss ein neuer und freigegebener Zielordner angelegt werden. `[FILE] $target = Join-Path "" "$env:COMPUTERNAME-$(Get-Date -Format 'yyyyMMdd-HHmmss')"` `[FILE] New-Item -ItemType Directory -Path $target` **Systemprotokoll exportieren** `[FILE][PRIV] wevtutil epl System "$target\System.evtx"` **Anwendungsprotokoll exportieren** `[FILE][PRIV] wevtutil epl Application "$target\Application.evtx"` **Sicherheitsprotokoll exportieren** `[FILE][PRIV][SENSITIV] wevtutil epl Security "$target\Security.evtx"` **PowerShell-Protokoll exportieren** `[FILE][PRIV][SENSITIV] wevtutil epl "Microsoft-Windows-PowerShell/Operational" "$target\PowerShell-Operational.evtx"` **Ereignisse nur aus einem bestimmten Zeitfenster als CSV sichern** `[FILE] Get-WinEvent -FilterHashtable @{LogName="System"; StartTime=[datetime]"2026-07-30 14:00:00"; EndTime=[datetime]"2026-07-30 15:00:00"} | Select-Object TimeCreated, Id, ProviderName, LevelDisplayName, Message | Export-Csv "$target\System-Zeitfenster.csv" -NoTypeInformation -Encoding UTF8` > Das Sicherheitsprotokoll kann personenbezogene und sicherheitsrelevante Informationen enthalten und benötigt normalerweise erhöhte Berechtigungen. --- **Linux-Journal exportieren** **Aktuellen Systemstart sichern** `[FILE] journalctl -b --no-pager --output=short-iso-precise > "/journal-current-boot.log"` **Vorherigen Systemstart sichern** `[FILE] journalctl -b -1 --no-pager --output=short-iso-precise > "/journal-previous-boot.log"` **Bestimmtes Zeitfenster sichern** `[FILE] journalctl --since "2026-07-30 14:00:00" --until "2026-07-30 15:00:00" --no-pager --output=short-iso-precise > "/journal-time-window.log"` **Kernelmeldungen sichern** `[FILE][PRIV] dmesg --ctime > "/dmesg.log"` **Dienstprotokoll sichern** `[FILE] journalctl -u --since "2026-07-30 14:00:00" --until "2026-07-30 15:00:00" --no-pager --output=short-iso-precise > "/.log"` Die Umleitung mit `>` erstellt eine Datei oder überschreibt eine vorhandene Datei. Deshalb sollte immer ein neuer Zielordner verwendet werden. --- **macOS-Protokolle exportieren** **Letzte Stunde als Text sichern** `[FILE][SENSITIV] log show --last 1h --style compact > "/macOS-unified-log.txt"` **Bestimmtes Zeitfenster sichern** `[FILE][SENSITIV] log show --start "2026-07-30 14:00:00" --end "2026-07-30 15:00:00" --style compact > "/macOS-time-window.log"` **Nur Fehler und Faults sichern** `[FILE][SENSITIV] log show --last 1h --predicate 'messageType == error OR messageType == fault' --style compact > "/macOS-errors.log"` **Systemdiagnose über die Oberfläche erstellen** `Aktivitätsanzeige → Weitere Optionen → Systemdiagnose` Apple beschreibt diese Funktion als Möglichkeit, einen Diagnosebericht mit Informationen und Protokollen über den Mac zu erstellen. > Ein Systemdiagnosebericht kann umfangreiche und vertrauliche Informationen enthalten. Er darf nur an freigegebenen Speicherorten abgelegt und an berechtigte Empfänger weitergegeben werden. --- **16. Kompakte Windows-Diagnosesammlung** Das folgende Beispiel erstellt einen neuen Diagnoseordner und schreibt den aktuellen Zustand in einzelne Dateien. `` muss vorher durch einen freigegebenen Speicherort ersetzt werden. $target = Join-Path "" "$env:COMPUTERNAME-$(Get-Date -Format 'yyyyMMdd-HHmmss')" New-Item -ItemType Directory -Path $target Get-Date -Format o | Out-File "$target\collection-start.txt" -Encoding utf8 Get-CimInstance Win32_OperatingSystem | Select-Object Caption, Version, BuildNumber, LastBootUpTime | Format-List | Out-File "$target\operating-system.txt" -Encoding utf8 Get-CimInstance Win32_Process | Select-Object ProcessId, ParentProcessId, Name, ExecutablePath, CommandLine | Export-Csv "$target\processes.csv" -NoTypeInformation -Encoding utf8 Get-Service | Sort-Object Status, Name | Export-Csv "$target\services.csv" -NoTypeInformation -Encoding utf8 Get-NetTCPConnection | Select-Object LocalAddress, LocalPort, RemoteAddress, RemotePort, State, OwningProcess | Export-Csv "$target\tcp-connections.csv" -NoTypeInformation -Encoding utf8 Get-NetUDPEndpoint | Export-Csv "$target\udp-endpoints.csv" -NoTypeInformation -Encoding utf8 ipconfig /all | Out-File "$target\ipconfig-all.txt" -Encoding utf8 route print | Out-File "$target\routes.txt" -Encoding utf8 arp -a | Out-File "$target\arp-cache.txt" -Encoding utf8 ipconfig /displaydns | Out-File "$target\dns-cache.txt" -Encoding utf8 Get-Volume | Format-List | Out-File "$target\volumes.txt" -Encoding utf8 wevtutil epl System "$target\System.evtx" wevtutil epl Application "$target\Application.evtx" Get-Date -Format o | Out-File "$target\collection-end.txt" -Encoding utf8 **Hinweise** - Die Sammlung schreibt Dateien, verändert aber keine beabsichtigte Systemkonfiguration. - Einige Informationen benötigen eine administrative PowerShell. - Nicht verfügbare Cmdlets können zu Fehlermeldungen führen. - Die Ausgabe kann Benutzernamen, IP-Adressen, Prozessbefehle und interne Systeminformationen enthalten. - Bei einem Sicherheitsvorfall darf dieses Beispiel nur verwendet werden, wenn es dem freigegebenen Incident-Response-Verfahren entspricht. --- **17. Kompakte Linux-Diagnosesammlung** `` muss durch einen freigegebenen Speicherort ersetzt werden. case_dir="/$(hostname)-$(date +%Y%m%d-%H%M%S)" mkdir -p -- "$case_dir" date --iso-8601=seconds > "$case_dir/collection-start.txt" uname -a > "$case_dir/kernel.txt" cat /etc/os-release > "$case_dir/os-release.txt" uptime > "$case_dir/uptime.txt" who -a > "$case_dir/logged-in-users.txt" ps auxww > "$case_dir/processes.txt" ss -tulpn > "$case_dir/network-sockets.txt" 2>&1 ip -details address show > "$case_dir/ip-addresses.txt" ip route show table all > "$case_dir/routes.txt" ip neigh show > "$case_dir/neighbors.txt" resolvectl status > "$case_dir/dns-status.txt" 2>&1 systemctl --failed --no-pager > "$case_dir/failed-services.txt" free -h > "$case_dir/memory.txt" df -hT > "$case_dir/filesystems.txt" df -ih > "$case_dir/inodes.txt" lsblk -f > "$case_dir/block-devices.txt" journalctl -b --no-pager --output=short-iso-precise > "$case_dir/journal-current-boot.log" dmesg --ctime > "$case_dir/dmesg.log" 2>&1 date --iso-8601=seconds > "$case_dir/collection-end.txt" **Hinweise** - Ohne Root-Rechte fehlen möglicherweise Prozessnamen bei Netzwerkverbindungen und Teile der Kernelmeldungen. - Nicht jedes Linux-System verwendet systemd, `journalctl` oder `resolvectl`. - Fehlerausgaben werden bei einigen Befehlen mit `2>&1` in dieselbe Datei geschrieben. - Bestehende Dateien mit identischem Namen werden durch `>` überschrieben. Deshalb wird ein neuer Zeitstempelordner verwendet. --- **18. Kompakte macOS-Diagnosesammlung** `` muss durch einen freigegebenen Speicherort ersetzt werden. case_dir="/$(hostname)-$(date +%Y%m%d-%H%M%S)" mkdir -p -- "$case_dir" date "+%Y-%m-%dT%H:%M:%S%z" > "$case_dir/collection-start.txt" sw_vers > "$case_dir/macos-version.txt" uname -a > "$case_dir/kernel.txt" system_profiler SPSoftwareDataType SPHardwareDataType > "$case_dir/system-profile.txt" uptime > "$case_dir/uptime.txt" who > "$case_dir/logged-in-users.txt" ps auxww > "$case_dir/processes.txt" ifconfig -a > "$case_dir/interfaces.txt" netstat -rn > "$case_dir/routes.txt" netstat -anv > "$case_dir/network-connections.txt" arp -an > "$case_dir/arp-cache.txt" scutil --dns > "$case_dir/dns-configuration.txt" scutil --proxy > "$case_dir/proxy-configuration.txt" launchctl list > "$case_dir/launchd-services.txt" vm_stat > "$case_dir/memory.txt" df -h > "$case_dir/filesystems.txt" log show --last 1h --style compact > "$case_dir/unified-log-last-hour.txt" date "+%Y-%m-%dT%H:%M:%S%z" > "$case_dir/collection-end.txt" **Hinweise** - `system_profiler` und `log show` können je nach System einige Zeit benötigen. - Die Unified-Log-Ausgabe kann personenbezogene und sicherheitsrelevante Daten enthalten. - Für eine vollständige offizielle Systemdiagnose kann die Aktivitätsanzeige verwendet werden. - Ohne erhöhte Berechtigungen können bestimmte Informationen fehlen. --- **19. Paketaufzeichnung nur gezielt einsetzen** Eine Paketaufzeichnung kann zeigen: - ob eine Verbindung tatsächlich aufgebaut wird, - welche IP-Adresse verwendet wird, - ob DNS-Anfragen beantwortet werden, - ob TCP-Verbindungen zurückgesetzt werden, - ob Pakete mehrfach übertragen werden, - ob ein TLS-Handshake fehlschlägt, - ob ein Server nicht antwortet. Sie kann jedoch auch vertrauliche Inhalte, interne IP-Adressen, Hostnamen, Benutzerkennungen und Sitzungsinformationen enthalten. Vor einer Aufzeichnung müssen deshalb geklärt sein: - technische Notwendigkeit, - zulässige Schnittstelle, - erlaubter Zeitraum, - Datenschutz, - Speicherort, - Zugriffsberechtigung, - Aufbewahrungsdauer. **Windows mit pktmon** **Aufzeichnung starten** `[FILE][ACTIVE][PRIV][SENSITIV] pktmon start --capture --pkt-size 0 --file-name "\capture.etl"` **Aufzeichnung beenden** `[ACTIVE][PRIV] pktmon stop` **ETL-Datei in PCAPNG umwandeln** `[FILE][SENSITIV] pktmon etl2pcap "\capture.etl" --out "\capture.pcapng"` --- **Linux mit tcpdump** `[FILE][ACTIVE][PRIV][SENSITIV] sudo tcpdump -i any -nn -s 0 -w "/capture.pcap"` Beenden mit `Strg + C`. --- **macOS mit tcpdump** `[FILE][ACTIVE][PRIV][SENSITIV] sudo tcpdump -i -nn -s 0 -w "/capture.pcap"` Beenden mit `Strg + C`. Das richtige Interface kann vorher mit folgendem Befehl bestimmt werden: `[RO] networksetup -listallhardwareports` Eine ausführliche Paketanalyse wird später im Netzwerk-Kapitel behandelt. --- **20. Prüfsummen erstellen** Eine kryptografische Prüfsumme hilft zu erkennen, ob eine gesicherte Datei nachträglich verändert wurde. > Eine Prüfsumme beweist nicht automatisch, woher eine Datei stammt. Sie dokumentiert den Zustand der Datei zum Zeitpunkt der Prüfsummenbildung und ermöglicht spätere Integritätsprüfungen. Die Prüfsummen sollten erst erstellt werden, nachdem die Sammlung abgeschlossen wurde und keine weiteren Dateien hinzugefügt werden. --- **Windows** **Prüfsumme einer Datei** `[RO] Get-FileHash "" -Algorithm SHA256` **Prüfsummen eines Diagnoseordners als separate CSV-Datei** `[FILE] Get-ChildItem "$target" -File -Recurse | Get-FileHash -Algorithm SHA256 | Export-Csv "$target-SHA256.csv" -NoTypeInformation -Encoding UTF8` --- **Linux** **Prüfsumme einer Datei** `[RO] sha256sum ""` **Prüfsummen aller Dateien eines Diagnoseordners** `[FILE] (cd "$case_dir" && find . -type f -print0 | sort -z | xargs -0 -r sha256sum) > "${case_dir}-SHA256SUMS.txt"` --- **macOS** **Prüfsumme einer Datei** `[RO] shasum -a 256 ""` **Prüfsummen aller Dateien eines Diagnoseordners** `[FILE] find "$case_dir" -type f -exec shasum -a 256 {} \; > "${case_dir}-SHA256SUMS.txt"` --- **21. Integrität später überprüfen** **Windows** `[RO] Get-FileHash "" -Algorithm SHA256` Die neu berechnete Prüfsumme wird mit der zuvor dokumentierten Prüfsumme verglichen. **Linux** `[RO] sha256sum -c ""` **macOS** Wenn das Prüfsummenformat kompatibel vorliegt: `[RO] shasum -a 256 -c ""` --- **22. Sicheren Speicherort auswählen** Diagnosedaten sollten nicht unkontrolliert auf dem betroffenen System verbleiben. **Geeignete Ziele** - freigegebener Incident- oder Diagnoseordner - geschützter Netzwerkbereich - verschlüsselter administrativer Datenträger - vorgesehenes Ticketsystem - freigegebene Forensikplattform - zentraler Logserver - SIEM - schreibgeschütztes Archiv **Ungeeignete Ziele** - privater USB-Stick - private Cloud - privates E-Mail-Konto - Messenger - öffentlicher Dateiübertragungsdienst - frei zugängliche Netzwerkfreigabe - unverschlüsselter mobiler Datenträger - dauerhaftes Ablegen auf dem Desktop - direktes Hochladen vollständiger Protokolle in öffentliche Foren --- **23. Mögliche sensible Inhalte** | Datenquelle | Mögliche sensible Informationen | |---|---| | Prozessliste | Benutzernamen, Pfade, Befehlszeilen, Token | | Netzwerkverbindungen | interne IP-Adressen, externe Ziele, verwendete Dienste | | DNS-Cache | besuchte oder verwendete Hostnamen | | Ereignisprotokolle | Benutzerkonten, Systeme, Anmeldeereignisse | | Paketaufzeichnung | Nutzdaten, Sitzungen, Hostnamen, Identifikatoren | | Konfigurationsdateien | Kennwörter, API-Schlüssel, Zertifikate | | Umgebungsvariablen | Token, Schlüssel, Zugangsdaten | | Browserdaten | URLs, Sitzungsdaten, Benutzerverhalten | | Systemdiagnose | umfangreiche Hardware-, Benutzer- und Prozessinformationen | | Cloud-Auditdaten | Benutzeraktionen, IP-Adressen, Ressourcennamen | Vor der Weitergabe muss geprüft werden: - Wer darf die Daten sehen? - Welche Informationen sind tatsächlich erforderlich? - Müssen Daten geschwärzt werden? - Darf eine Datei verändert oder muss eine Kopie erstellt werden? - Welche Aufbewahrungsfrist gilt? - Wann und wie müssen die Daten gelöscht werden? Bei Beweismitteln sollte eine unveränderte Originalkopie erhalten bleiben. Geschwärzte Arbeitskopien werden davon getrennt erstellt. --- **24. Beweismittelkette dokumentieren** Bei einem möglichen Sicherheitsvorfall oder einer rechtlich relevanten Untersuchung muss nachvollziehbar bleiben, wer wann mit welchen Daten gearbeitet hat. | Feld | Dokumentation | |---|---| | Fall- oder Ticketnummer | Eindeutige Referenz | | System | Hostname, Gerätetyp und gegebenenfalls Seriennummer | | Eigentümer oder Fachbereich | Verantwortliche Organisationseinheit | | Sammler | Name oder Administratorkonto der erfassenden Person | | Beginn der Sammlung | Datum, Uhrzeit und Zeitzone | | Ende der Sammlung | Datum, Uhrzeit und Zeitzone | | Quelle | System, Datenträger, Anwendung oder Protokoll | | Verwendete Befehle | Exakte Befehle und Parameter | | Verwendete Werkzeuge | Name und Version | | Zielmedium | Speicherort oder Datenträgerkennung | | Dateiname | Eindeutiger Name | | Prüfsumme | SHA-256-Wert | | Übergabe | Von wem, an wen und wann | | Zugriff | Wer öffnete oder kopierte die Daten? | | Zweck | Diagnose, Incident Response oder forensische Untersuchung | | Veränderungen | Jede bekannte Veränderung dokumentieren | **Beispiel für einen eindeutigen Dateinamen** `INC-2026-0042-SRV-DC01-System-20260730-151500.evtx` Der Dateiname enthält: - Fallnummer - Systemname - Inhalt - Datum - Uhrzeit --- **25. Prioritäten bei laufendem Produktionsausfall** Bei einem kritischen Produktionsausfall kann nicht unbegrenzt auf eine vollständige Sammlung gewartet werden. Eine sinnvolle Mindestaufnahme besteht aus: 1. Fehlermeldung und Zeitpunkt 2. betroffenem System und Benutzer 3. Prozess- und Dienstzustand 4. Netzwerkverbindungen 5. IP-Konfiguration und Routing 6. Ressourcen- und Datenträgerzustand 7. relevanten Ereignissen kurz vor dem Fehler 8. ausgeführter Maßnahme 9. Zustand nach der Maßnahme Anschließend kann eine begründete Wiederherstellungsmaßnahme durchgeführt werden. | Priorität | Entscheidung | |---|---| | Menschen oder physische Sicherheit betroffen | Sicherheit hat Vorrang | | Aktiver Sicherheitsangriff | Eindämmung nach Incident-Response-Plan | | Kritischer Produktionsstillstand | Mindestaufnahme, danach freigegebene Wiederherstellung | | Einzelner Arbeitsplatz betroffen | Ausführlichere Diagnose meist möglich | | Fehler gut reproduzierbar | Zustand sichern und kontrollierte Tests durchführen | | Fehler selten oder nicht reproduzierbar | Vor einer Änderung besonders sorgfältig sichern | --- **26. Nach jeder Änderung erneut sichern** Nach einer Maßnahme sollte nicht nur notiert werden, ob „es wieder geht“. Zu dokumentieren sind: - genaue Maßnahme, - ausführende Person, - Start- und Endzeitpunkt, - betroffene Systeme, - Ausgangszustand, - Zustand unmittelbar danach, - ursprünglicher Test, - Testergebnis, - neue Fehlermeldungen, - mögliche Nebenwirkungen, - Beobachtungszeitraum. **Vorher-Nachher-Tabelle** | Prüfpunkt | Vor der Maßnahme | Nach der Maßnahme | |---|---|---| | Fehler reproduzierbar | | | | Dienstzustand | | | | Prozess-ID | | | | CPU-Auslastung | | | | Speichernutzung | | | | Netzwerkverbindung | | | | DNS-Auflösung | | | | Ereignisprotokoll | | | | Benutzerfunktion | | | | Monitoringstatus | | | --- **27. Typische Fehler bei der Beweissicherung** | Fehler | Folge | Besseres Vorgehen | |---|---|---| | Sofortiger Neustart | Flüchtige Zustände gehen verloren | Mindestzustand zuerst sichern | | Screenshot ohne Uhrzeit | Ereignis ist schwer einzuordnen | Zeit und Zeitzone dokumentieren | | Nur Fehlermeldung abschreiben | Kontext und Details fehlen | Vollständigen Screenshot und Fehlercode sichern | | Protokoll als Text kopieren | Metadaten können fehlen | Wenn möglich natives Format exportieren | | Diagnose auf betroffenem System speichern | Daten können beim Ausfall verloren gehen | Freigegebenes externes Ziel verwenden | | Originaldatei bearbeiten | Integrität ist nicht mehr nachvollziehbar | Original schützen, Arbeitskopie verwenden | | Keine Prüfsumme erstellen | Spätere Veränderung schwer erkennbar | SHA-256 dokumentieren | | Mehrere Maßnahmen gleichzeitig | Wirkung ist nicht zuordenbar | Eine Variable pro Test ändern | | Daten unverschlüsselt versenden | Datenschutz- und Sicherheitsrisiko | Freigegebenen Übertragungsweg verwenden | | Vollständige Logs öffentlich hochladen | Interne Daten werden offengelegt | Daten prüfen, minimieren und schwärzen | | Root- oder Admin-Rechte unnötig verwenden | Größerer Eingriff in das System | Niedrigste erforderliche Berechtigung verwenden | | Sicherheitsvorfall wie normalen Fehler behandeln | Spuren werden vernichtet oder Angriff breitet sich aus | Incident-Response-Prozess aktivieren | | Sammlung verzögert notwendige Eindämmung | Schaden kann zunehmen | Sicherheit und Eindämmung priorisieren | | Nur lokale Protokolle sichern | Zentrale Hinweise fehlen | SIEM, Firewall, Cloud und Monitoring einbeziehen | | Shell-Historie enthält sensible Befehle | Zugangsdaten können offengelegt werden | Geheimnisse niemals direkt in Befehle schreiben | --- **28. Dokumentationsvorlage** | Feld | Eintrag | |---|---| | Ticket- oder Fallnummer | | | Datum und Uhrzeit | | | Zeitzone | | | Erfasser | | | Betroffenes System | | | Hostname | | | IP-Adresse | | | Betriebssystem | | | Betroffener Benutzer | | | Sichtbare Fehlermeldung | | | Fehlercode | | | Letzter funktionierender Zustand | | | Erste bekannte Störung | | | Screenshot gesichert | Ja / Nein | | Prozesse gesichert | Ja / Nein | | Verbindungen gesichert | Ja / Nein | | Netzwerkzustand gesichert | Ja / Nein | | Dienstzustand gesichert | Ja / Nein | | Ressourcenstatus gesichert | Ja / Nein | | Protokolle exportiert | Ja / Nein | | Paketaufzeichnung erstellt | Ja / Nein / Nicht erforderlich | | Diagnoseordner | | | Prüfsumme erstellt | Ja / Nein | | SHA-256-Datei | | | Sensible Daten enthalten | Ja / Nein / Unbekannt | | Sicherheitsvorfall vermutet | Ja / Nein | | Incident Response informiert | Ja / Nein / Nicht erforderlich | | Erste durchgeführte Änderung | | | Zeitpunkt der Änderung | | | Ergebnis der Änderung | | | Weitere Maßnahmen | | --- **Kurzcheckliste** - [ ] Nicht sofort neu gestartet - [ ] Fehlermeldung vollständig gesichert - [ ] Uhrzeit und Zeitzone dokumentiert - [ ] Hostname und Betriebssystem erfasst - [ ] Angemeldete Benutzer erfasst - [ ] Laufende Prozesse erfasst - [ ] Dienstzustand erfasst - [ ] Aktive Netzwerkverbindungen erfasst - [ ] IP-Konfiguration erfasst - [ ] Routingtabelle erfasst - [ ] ARP- oder Neighbor-Tabelle erfasst - [ ] DNS-Zustand erfasst - [ ] Ressourcen- und Datenträgerzustand erfasst - [ ] Relevante Protokolle exportiert - [ ] Zentrale Protokollquellen berücksichtigt - [ ] Normalen Fehler und Sicherheitsvorfall unterschieden - [ ] Sensible Inhalte der Sammlung berücksichtigt - [ ] Freigegebenen Speicherort verwendet - [ ] Prüfsummen erstellt - [ ] Sammlung eindeutig dem Ticket zugeordnet - [ ] Erst danach eine kontrollierte Änderung durchgeführt - [ ] Zustand vor und nach der Änderung verglichen - [ ] Alle Maßnahmen mit Uhrzeit dokumentiert --- **Ergebnis dieses Arbeitsschrittes** Am Ende dieses Schrittes liegt ein dokumentierter Ausgangszustand vor. Dadurch kann auch nach einem Neustart, Dienstneustart oder einer Konfigurationsänderung nachvollzogen werden, was vor der Maßnahme auf dem System geschah. Die wichtigste Regel lautet: > Eine schnelle Wiederherstellung behebt möglicherweise die Störung. Eine vorherige Zustandssicherung ermöglicht zusätzlich die Ursachenanalyse. Bei einem möglichen Sicherheitsvorfall gelten die Incident-Response-Vorgaben der Organisation. Eine normale Diagnosesammlung ersetzt keine professionelle forensische Sicherung. **Nächste Seite:** **1.5 Arbeitshypothesen bilden und Prüfungen priorisieren** --- **Offizielle Standards und Herstellerdokumentation** - [NIST – SP 800-61 Revision 3: Incident Response Recommendations and Considerations](https://csrc.nist.gov/pubs/sp/800/61/r3/final) - [RFC Editor – RFC 3227: Guidelines for Evidence Collection and Archiving](https://www.rfc-editor.org/rfc/rfc3227.html) - [Microsoft Learn – wevtutil](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/wevtutil) - [Microsoft Learn – Get-NetTCPConnection](https://learn.microsoft.com/en-us/powershell/module/nettcpip/get-nettcpconnection) - [Microsoft Learn – Packet Monitor](https://learn.microsoft.com/en-us/windows-server/networking/technologies/pktmon/pktmon) - [freedesktop.org – journalctl](https://www.freedesktop.org/software/systemd/man/latest/journalctl.html) - [Red Hat – Configuring basic system settings](https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/configuring_basic_system_settings/) - [Apple Support – Systemdiagnose in der Aktivitätsanzeige erstellen](https://support.apple.com/guide/activity-monitor/run-system-diagnostics-actmntr2225/mac) - [Apple Support – Protokollmeldungen in der Konsole anzeigen](https://support.apple.com/guide/console/log-messages-cnsl1012/mac) - [Apple Support – Diagnoseberichte in der Konsole untersuchen](https://support.apple.com/guide/console/browse-the-log-archive-cnsl4f3fc2df/mac) # 1.5 Arbeitshypothesen bilden und Prüfungen priorisieren Nachdem Störung, Umfang, Zeitpunkt, Änderungen und Ausgangszustand dokumentiert wurden, beginnt die gezielte Ursachensuche. Dabei gilt: > Nicht die erste plausible Erklärung beheben, sondern mehrere mögliche Ursachen aufstellen und mit geeigneten Tests unterscheiden. Eine Arbeitshypothese ist eine vorläufige, überprüfbare Erklärung für das beobachtete Fehlerbild. Sie ist noch keine bestätigte Ursache. --- **Ziel dieser Seite** Nach diesem Arbeitsschritt sollten: - gesicherte Fakten von Vermutungen getrennt sein, - mehrere technisch plausible Ursachen vorliegen, - widersprechende Beobachtungen berücksichtigt sein, - für jede wichtige Hypothese ein geeigneter Test definiert sein, - erwartete Testergebnisse vorher festgelegt sein, - ungefährliche und aussagekräftige Tests priorisiert sein, - Testergebnisse nachvollziehbar dokumentiert werden. --- **1. Kennzeichnung der Befehle** | Kennzeichnung | Bedeutung | |---|---| | `[RO]` | Read-only: liest Informationen aus | | `[TEST]` | Führt eine aktive Prüfung aus, beispielsweise eine DNS- oder TCP-Anfrage | | `[FILE]` | Erstellt oder überschreibt eine Datei | | `[PRIV]` | Benötigt möglicherweise Administrator- oder Root-Rechte | | `[CHANGE]` | Verändert eine Konfiguration oder einen Betriebszustand | | `[SENSITIV]` | Ausgabe kann vertrauliche Daten enthalten | Ein `[TEST]` verändert normalerweise keine Konfiguration, erzeugt aber Netzwerkverkehr und möglicherweise Protokolleinträge. Wiederholte Anmeldeversuche können beispielsweise ein Benutzerkonto sperren. --- **2. Fakten, Vermutungen und Ursachen unterscheiden** | Begriff | Bedeutung | Beispiel | |---|---|---| | Symptom | Sichtbare Auswirkung der Störung | Webseite ist nicht erreichbar | | Fakt | Durch Messung oder Beleg bestätigte Information | TCP-Port 443 ist von Client A nicht erreichbar | | Vermutung | Nicht ausreichend begründete Annahme | „Bestimmt ist die Firewall schuld“ | | Hypothese | Überprüfbare mögliche Erklärung | Eine Firewall-Regel blockiert VLAN 30 zu TCP 443 | | Vorhersage | Erwartetes Ergebnis, wenn die Hypothese stimmt | Clients aus VLAN 40 funktionieren, VLAN 30 nicht | | Test | Gezielte Prüfung der Vorhersage | Porttest aus beiden VLANs | | Ursache | Durch Belege und Gegenproben bestätigte Erklärung | ACL blockiert VLAN 30 zu TCP 443 | | Maßnahme | Veränderung zur Beseitigung der Ursache | Korrektur der freigegebenen ACL-Regel | **Wichtig** „Nach dem Neustart funktionierte es wieder“ ist zunächst nur ein Ergebnis. Daraus folgt noch nicht, warum der Fehler auftrat. Mögliche Erklärungen wären beispielsweise: - blockierter Prozess wurde beendet, - Speicherleck wurde vorübergehend beseitigt, - Netzwerkverbindung wurde neu aufgebaut, - temporärer Cache wurde geleert, - Konfiguration wurde beim Start neu geladen, - abhängiger Dienst wurde in anderer Reihenfolge gestartet. --- **3. Eine präzise Problembeschreibung erstellen** Eine brauchbare Hypothese benötigt eine präzise Problembeschreibung. **Ungeeignet** `Das Netzwerk funktioniert nicht.` **Besser** `Seit ungefähr 14:35 Uhr können Windows-Clients aus VLAN 30 den Server server.example über TCP 443 nicht erreichen. DNS liefert die erwartete IP-Adresse. Clients aus VLAN 40 erreichen denselben Port weiterhin.` Eine gute Problembeschreibung enthält: - betroffene Funktion, - betroffene Benutzer oder Geräte, - nicht betroffene Benutzer oder Geräte, - Quellnetz oder Standort, - Zielsystem, - Protokoll und Port, - Beginn der Störung, - letzte bekannte Funktion, - Fehlermeldung, - bereits bestätigte Fakten, - letzte relevante Änderungen. --- **4. Aufbau einer überprüfbaren Hypothese** Eine gute Arbeitshypothese kann nach diesem Muster formuliert werden: > Wenn `` vorliegt, dann müsste `` auftreten, weil ``. Das prüfen wir mit ``. Widerlegt wäre die Hypothese durch ``. **Beispiel** > Wenn eine Firewall-Regel den Verkehr aus VLAN 30 blockiert, dann müsste der TCP-Port 443 aus VLAN 30 nicht erreichbar sein, während derselbe Port aus einem freigegebenen VLAN erreichbar ist. Widerlegt wäre die Hypothese, wenn die Verbindung aus beiden VLANs identisch fehlschlägt oder die Pakete nachweislich bis zum Server gelangen. --- **5. Schlechte und gute Hypothesen** | Schlechte Formulierung | Problem | Bessere Formulierung | |---|---|---| | Die Firewall ist kaputt | Zu allgemein und nicht überprüfbar | Eine Firewall-Regel blockiert TCP 443 aus VLAN 30 | | Windows macht Probleme | Kein konkreter Mechanismus | Der Windows-DNS-Client verwendet einen veralteten Cacheeintrag | | Der Server ist down | „Down“ ist nicht definiert | Der Webdienst lauscht nicht auf TCP 443 | | Es liegt am Benutzer | Keine technische Erklärung | Dem Benutzer fehlt die erforderliche Anwendungsrolle | | Das Update war schuld | Nur zeitliche Korrelation | Update KB… hat den verwendeten Treiber ersetzt | | DNS geht nicht | Nicht eingegrenzt | Der Client fragt einen nicht erreichbaren DNS-Server ab | | Das Zertifikat ist falsch | Zu ungenau | Der aufgerufene Hostname fehlt im Subject Alternative Name | | Das Netzwerk ist langsam | Keine Messgröße | Zwischen Client und Server treten Paketverluste auf | --- **6. Mögliche Fehlerbereiche systematisch durchgehen** Für eine erste Hypothesenliste können folgende Bereiche verwendet werden: | Fehlerbereich | Typische Ursachen | |---|---| | Benutzer | Bedienfehler, falsche Eingabe, fehlende Berechtigung | | Benutzerkonto | Sperrung, Ablauf, Gruppenmitgliedschaft, MFA | | Client-Hardware | Netzwerkkarte, Datenträger, Arbeitsspeicher | | Client-Betriebssystem | Update, Treiber, lokaler Dienst, Richtlinie | | Client-Konfiguration | IP, DNS, Proxy, Zertifikat, Firewall | | Anwendung | Absturz, Cache, Version, Konfiguration | | Namensauflösung | DNS-Server, Eintrag, Suchdomäne, Cache | | Netzwerkzugang | WLAN, Switchport, VLAN, NAC, Port-Security | | Netzwerkpfad | Routing, ACL, Firewall, NAT, MTU | | Zielserver | Dienst, Ressourcen, Betriebssystem, Listener | | Authentifizierung | Kerberos, LDAP, RADIUS, Zertifikat, Token | | Autorisierung | Rolle, Gruppe, ACL, Dateiberechtigung | | Abhängiger Dienst | Datenbank, DNS, Storage, API, Queue | | Sicherheitskomponente | EDR, Antivirus, Proxy, Webfilter | | Automatisierung | Skript, GPO, Deployment, geplanter Job | | Virtualisierung | Ressourcen, virtuelles Netzwerk, Storage | | Cloud oder Provider | Plattformstörung, Richtlinie, Service Health | | Letzte Änderung | Update, Migration, Konfiguration, Zertifikat | Nicht jeder Bereich muss ausführlich geprüft werden. Die Eingrenzung aus den vorherigen Seiten bestimmt, welche Bereiche plausibel sind. --- **7. Hypothesen aus dem Fehlerumfang ableiten** | Beobachtung | Zu priorisierende Hypothesen | |---|---| | Nur ein Benutzer betroffen | Konto, Berechtigung, Profil, Rolle | | Alle Benutzer eines Clients betroffen | Client, Betriebssystem, lokale Konfiguration | | Ein Benutzer auf allen Clients betroffen | Identität, Konto, Berechtigung | | Nur ein Standort betroffen | WAN, Firewall, DNS, Provider, Standortnetz | | Nur ein VLAN betroffen | Routing, ACL, DHCP, VLAN-Zuordnung | | Alle Clients betroffen | Server, zentraler Dienst, gemeinsame Abhängigkeit | | Nur ein Server betroffen | Dienst, Betriebssystem, Ressourcen, Serverkonfiguration | | Nur ein Browser betroffen | Browserprofil, Proxy, Zertifikat, Erweiterung | | Zugriff per IP funktioniert, per Name nicht | DNS, Hosts-Datei, Suchdomäne | | Port erreichbar, Anwendung funktioniert nicht | Protokoll, Authentifizierung, Anwendung | | Anwendung lokal erreichbar, remote nicht | Listener-Bindung, Firewall, Routing | | Fehler nur zu bestimmten Zeiten | geplanter Job, Last, Lease, Token, Zertifikat | | Fehler nach Update | Kompatibilität, Treiber, Richtlinie, Neustart | | Fehler verschwindet nach Neustart | Prozesszustand, Cache, Ressourcenleck | | Neue Geräte betroffen | DHCP, NAC, Zertifikat, Provisionierung | | Alte Geräte betroffen, neue funktionieren | veraltete Konfiguration oder Software | --- **8. Belege für und gegen eine Hypothese sammeln** Eine professionelle Hypothese enthält nicht nur unterstützende Hinweise. Es müssen auch widersprechende Beobachtungen gesucht werden. | Hypothese | Unterstützende Hinweise | Widersprechende Hinweise | |---|---|---| | DNS-Problem | Name wird nicht aufgelöst | Direkte DNS-Abfrage liefert korrekte Adresse | | Serverdienst ausgefallen | Port ist von allen Clients geschlossen | Dienst lauscht und andere Clients funktionieren | | Benutzerberechtigung fehlt | Nur ein Benutzer betroffen | Derselbe Benutzer funktioniert auf anderem Client | | Lokale Firewall blockiert | Nur ein Client betroffen | Verbindung scheitert auch von anderen Clients | | VLAN-ACL blockiert | Nur ein VLAN betroffen | Pakete erreichen nachweislich den Server | | Zertifikat abgelaufen | TLS-Fehler und Ablaufdatum überschritten | Zertifikat ist gültig und Hostname stimmt | | Datenträger voll | Freier Speicher ist nahezu null | Ausreichend Speicher und keine I/O-Fehler | | Update verursacht Fehler | Fehler beginnt direkt nach Update | Identisch aktualisierte Systeme funktionieren | > Eine Hypothese sollte herabgestuft werden, wenn mehrere gesicherte Fakten ihr widersprechen. --- **9. Prüfungen sinnvoll priorisieren** Nicht automatisch die wahrscheinlichste Hypothese wird zuerst geprüft. Sinnvoll ist zunächst ein Test, der mit geringem Risiko möglichst viele Hypothesen unterscheidet. **Priorisierungskriterien** | Kriterium | Frage | |---|---| | Wahrscheinlichkeit | Passt die Hypothese zum Fehlerbild? | | Informationsgewinn | Wie viele Ursachen kann der Test unterscheiden? | | Sicherheit | Kann der Test Datenverlust oder Ausfall verursachen? | | Aufwand | Wie viel Zeit und Vorbereitung benötigt der Test? | | Reproduzierbarkeit | Kann der Test zuverlässig wiederholt werden? | | Reversibilität | Lässt sich eine Veränderung sicher zurücknehmen? | | Reichweite | Betrifft der Test einen Client oder die Produktion? | | Beweislage | Gibt es bereits unterstützende oder widersprechende Fakten? | --- **10. Prioritätsklassen** | Priorität | Bedeutung | Beispiele | |---|---|---| | P1 | Sicher, schnell und hoher Informationsgewinn | Status, Logs, DNS-, TCP- und Vergleichstest | | P2 | Gezielte Prüfung mit begrenztem Aufwand | Testkonto, anderer Client, isolierte Konfiguration | | P3 | Potenziell störende oder aufwendige Prüfung | Dienstneustart, Failover, Rollback | | P4 | Unwahrscheinlich, widersprochen oder unverhältnismäßig | großflächige Änderung ohne ausreichende Belege | **Sinnvolle Reihenfolge** 1. passive Zustandsabfrage, 2. Vergleich mit funktionierendem System, 3. gezielte Netzwerk- oder Anwendungstests, 4. Test in isolierter Umgebung, 5. reversible Änderung, 6. Dienstneustart oder Failover, 7. Konfigurationsrollback, 8. weitreichende Änderung oder Produktionsunterbrechung. --- **11. Tests müssen Hypothesen unterscheiden** Ein Test ist besonders nützlich, wenn unterschiedliche Hypothesen unterschiedliche Ergebnisse erwarten lassen. **Wenig aussagekräftiger Test** `Der Benutzer soll es noch einmal versuchen.` Dieser Test zeigt lediglich, ob der Fehler weiterhin auftritt. **Aussagekräftiger Test** `Derselbe Benutzer testet dieselbe Funktion auf einem funktionierenden Vergleichsclient.` Mögliche Interpretation: | Ergebnis | Schlussfolgerung | |---|---| | Benutzer funktioniert auf Vergleichsclient | Clientbezogene Ursache wahrscheinlicher | | Benutzer funktioniert auch dort nicht | Konto oder Berechtigung wahrscheinlicher | | Andere Benutzer funktionieren auf betroffenem Client | Benutzerbezogene Ursache wahrscheinlicher | | Kein Benutzer funktioniert auf betroffenem Client | Client- oder Netzwerkursache wahrscheinlicher | --- **12. Vor dem Test das erwartete Ergebnis festlegen** Vor jedem Test sollte dokumentiert werden: - welche Hypothese geprüft wird, - welcher Befehl oder Ablauf verwendet wird, - welches Ergebnis die Hypothese unterstützt, - welches Ergebnis sie widerlegt, - welche Ergebnisse uneindeutig wären, - ob der Test Veränderungen oder Risiken verursacht, - wie der Ausgangszustand wiederhergestellt wird. **Testvorlage** | Feld | Eintrag | |---|---| | Hypothese | | | Technische Begründung | | | Test | | | Erwartetes Ergebnis | | | Widerlegendes Ergebnis | | | Risiko | | | Rückfallmöglichkeit | | | Tatsächliches Ergebnis | | | Bewertung | Bestätigt / Gestützt / Unklar / Widerlegt | | Nächster Schritt | | --- **13. Grundlegender Netzwerk- und Diensttest** Als Beispiel wird ein Webdienst verwendet: - Hostname: `server.example` - Port: `443` - Protokoll: `HTTPS` `server.example` ist ein reservierter Beispieldomainname und muss durch das tatsächliche Ziel ersetzt werden. --- **14. Stufe 1 – Namensauflösung prüfen** **Windows** `[TEST] Resolve-DnsName server.example` **Bestimmten DNS-Server abfragen** `[TEST] Resolve-DnsName server.example -Server ` **Alternative** `[TEST] nslookup server.example` --- **Linux** `[TEST] getent ahosts server.example` `[TEST] dig server.example` **Kurze Ausgabe** `[TEST] dig +short server.example` **Bestimmten DNS-Server abfragen** `[TEST] dig @ server.example` --- **macOS** `[TEST] dscacheutil -q host -a name server.example` `[TEST] dig server.example` **Kurze Ausgabe** `[TEST] dig +short server.example` **Bestimmten DNS-Server abfragen** `[TEST] dig @ server.example` --- **Interpretation der DNS-Prüfung** | Ergebnis | Mögliche Bedeutung | |---|---| | Keine Adresse wird geliefert | DNS-Eintrag, DNS-Server oder Resolverproblem | | Falsche IP-Adresse | veralteter Eintrag, falsche Zone, Cache oder Split-DNS | | Unterschiedliche Clients erhalten unterschiedliche IPs | Split-DNS, Load Balancing, Cache oder andere Resolver | | Bestimmter DNS-Server antwortet korrekt, Standardabfrage nicht | Client verwendet falschen oder nicht erreichbaren DNS-Server | | Name wird korrekt aufgelöst | DNS-Grundfunktion wahrscheinlich vorhanden | | Auflösung dauert sehr lange | DNS-Server, Weiterleitung, Netzwerk oder Suchdomäne prüfen | Eine erfolgreiche DNS-Abfrage beweist noch nicht, dass der Zielservice erreichbar ist. --- **15. Stufe 2 – IP-Erreichbarkeit mit ICMP prüfen** **Windows** `[TEST] ping -n 4 ` **Linux** `[TEST] ping -c 4 ` **macOS** `[TEST] ping -c 4 ` **Interpretation** | Ergebnis | Bedeutung | |---|---| | Antworten werden empfangen | IP-Kommunikation per ICMP funktioniert | | Keine Antwort | Host, Route, Firewall oder ICMP-Filterung möglich | | Hohe Latenz | Netzlast, WAN-Strecke, WLAN oder Zielauslastung möglich | | Paketverlust | instabile Verbindung, Überlastung oder physisches Problem möglich | | „Destination unreachable“ | Route, Gateway oder Zielnetz nicht erreichbar | | Ping per IP funktioniert, per Name nicht | Namensauflösung priorisieren | > Ein fehlgeschlagener Ping beweist nicht, dass der Server ausgefallen ist. ICMP kann blockiert sein, während der eigentliche TCP-Dienst funktioniert. --- **16. Stufe 3 – Zielport prüfen** **Windows** `[TEST] Test-NetConnection server.example -Port 443 -InformationLevel Detailed` Wichtige Felder: - `RemoteAddress` - `RemotePort` - `InterfaceAlias` - `SourceAddress` - `TcpTestSucceeded` **Nur Ergebnis ausgeben** `[TEST] Test-NetConnection server.example -Port 443 -InformationLevel Quiet` --- **Linux** `[TEST] nc -vz -w 3 server.example 443` --- **macOS** `[TEST] nc -vz -w 3 server.example 443` `nc` kann je nach Linux-Installation fehlen und muss gegebenenfalls als freigegebenes Paket installiert werden. --- **Interpretation des Porttests** | Ergebnis | Mögliche Bedeutung | |---|---| | TCP-Verbindung erfolgreich | Netzwerkpfad und TCP-Listener grundsätzlich erreichbar | | Verbindung abgelehnt | Ziel erreichbar, aber kein Listener oder aktive Ablehnung | | Zeitüberschreitung | Paketfilter, Route, Überlastung oder nicht antwortendes Ziel | | Name kann nicht aufgelöst werden | DNS zuerst untersuchen | | Nur ein Client scheitert | Client, lokales Netzwerk oder lokale Firewall | | Nur ein VLAN scheitert | ACL, Firewall, Routing oder VLAN-Konfiguration | | Alle Clients scheitern | Dienst, Server, zentrale Firewall oder gemeinsame Abhängigkeit | Ein erfolgreicher TCP-Test beweist nur den Verbindungsaufbau zum Port. Er bestätigt noch nicht, dass Anmeldung, Anwendung oder Datenbank funktionieren. --- **17. Stufe 4 – Anwendungsebene prüfen** **Windows** `[TEST] curl.exe -v -o NUL https://server.example/` **Linux** `[TEST] curl -v -o /dev/null https://server.example/` **macOS** `[TEST] curl -v -o /dev/null https://server.example/` Die Option `-v` zeigt unter anderem: - aufgelöste IP-Adresse, - TCP-Verbindungsaufbau, - TLS-Aushandlung, - Zertifikatsprüfung, - gesendete HTTP-Anfrage, - empfangenen HTTP-Status. > Beim ersten Test sollte nicht `-k` beziehungsweise `--insecure` verwendet werden. Diese Option deaktiviert die Zertifikatsprüfung und kann genau den Fehler verbergen, der untersucht werden soll. --- **18. HTTP-Ergebnisse interpretieren** | Ergebnis | Interpretation | |---|---| | `200 OK` | Anfrage wurde erfolgreich verarbeitet | | `301` oder `302` | Weiterleitung; Ziel des `Location`-Headers prüfen | | `401 Unauthorized` | Dienst erreichbar, Authentifizierung erforderlich oder fehlgeschlagen | | `403 Forbidden` | Dienst erreichbar, Zugriff wird verweigert | | `404 Not Found` | Dienst erreichbar, Ressource oder Pfad nicht gefunden | | `408 Request Timeout` | Anfrage wurde nicht rechtzeitig verarbeitet | | `429 Too Many Requests` | Rate Limit oder zu viele Anfragen | | `500 Internal Server Error` | serverseitiger Anwendungsfehler | | `502 Bad Gateway` | Proxy oder Gateway erhält ungültige Backend-Antwort | | `503 Service Unavailable` | Dienst oder Backend nicht verfügbar | | `504 Gateway Timeout` | Proxy oder Gateway wartet vergeblich auf Backend | | TLS-Zertifikatsfehler | Zertifikat, Hostname, Vertrauenskette oder Uhrzeit prüfen | | TCP-Verbindungsfehler | Netzwerkpfad, Firewall oder Listener prüfen | Ein HTTP-Status ist ein wichtiger Hinweis, aber die genaue Bedeutung kann von der Anwendung abweichen. --- **19. TLS-Verbindung untersuchen** Auf Linux und macOS sowie unter Windows mit installiertem OpenSSL: `[TEST] openssl s_client -connect server.example:443 -servername server.example -showcerts` Zu prüfen sind: - Zertifikatsinhaber, - Subject Alternative Names, - Aussteller, - Gültigkeitszeitraum, - Zertifikatskette, - verwendete TLS-Version, - verwendete Cipher Suite, - abschließendes Verifikationsergebnis. **Typische Befunde** | Befund | Mögliche Ursache | |---|---| | Zertifikat abgelaufen | Zertifikat wurde nicht rechtzeitig erneuert | | Zertifikat noch nicht gültig | falsche Systemzeit oder falsches Zertifikat | | Hostname stimmt nicht | falsches Zertifikat, Alias oder fehlender SAN-Eintrag | | Unbekannte CA | Stamm- oder Zwischenzertifikat fehlt | | Verbindung ohne Zertifikat beendet | TLS-Listener oder Proxyproblem | | Handshake Failure | inkompatible TLS-Version, Cipher oder Clientzertifikat | | Browser funktioniert, Anwendung nicht | unterschiedlicher Trust Store oder TLS-Stack | --- **20. Netzwerkpfad prüfen** **Windows** `[TEST] tracert server.example` **PowerShell** `[TEST] Test-NetConnection server.example -TraceRoute` --- **Linux** `[TEST] tracepath server.example` Alternativ, wenn installiert: `[TEST] traceroute server.example` --- **macOS** `[TEST] traceroute server.example` **Wichtige Einschränkungen** - Nicht jeder Router beantwortet Traceroute-Anfragen. - Sternchen bedeuten nicht automatisch einen Fehler an diesem Gerät. - Der Hin- und Rückweg kann unterschiedlich sein. - Firewalls können Traceroute blockieren. - Der letzte erreichbare Hop ist nicht automatisch die Fehlerursache. --- **21. Lokal gegen remote testen** Wenn ein Dienst direkt auf dem Server funktioniert, aber von Clients nicht erreichbar ist, wird die Ursache auf Netzwerkpfad, Listener-Bindung oder Firewall eingegrenzt. **Windows-Server** **Dienst lokal testen** `[TEST] Test-NetConnection localhost -Port ` **Listener prüfen** `[RO][PRIV] Get-NetTCPConnection -State Listen -LocalPort ` **Zugehörigen Prozess bestimmen** `[RO] Get-Process -Id ` --- **Linux-Server** **Dienst lokal testen** `[TEST] nc -vz -w 3 localhost ` **Listener prüfen** `[RO][PRIV] ss -lntp | grep ":"` **HTTP-Dienst lokal prüfen** `[TEST] curl -v http://localhost:/` --- **macOS-Server** **Dienst lokal testen** `[TEST] nc -vz -w 3 localhost ` **Listener prüfen** `[RO][PRIV] lsof -nP -iTCP: -sTCP:LISTEN` --- **Interpretation** | Lokaler Test | Remote-Test | Wahrscheinlicher Bereich | |---|---|---| | Erfolgreich | Erfolgreich | Anwendung, Anmeldung oder Benutzerberechtigung | | Erfolgreich | Fehlgeschlagen | Firewall, Routing, NAT oder Listener-Bindung | | Fehlgeschlagen | Fehlgeschlagen | Dienst, Server oder Anwendung | | Fehlgeschlagen | Erfolgreich | ungewöhnlicher Proxy-, Container- oder Load-Balancer-Pfad | | Unterschiedlich je Quellnetz | Unterschiedlich | VLAN, ACL, Firewall oder Routing | --- **22. Dienstzustand und Protokolle prüfen** **Windows** `[RO] Get-Service -Name ` `[RO] Get-WinEvent -FilterHashtable @{LogName="System"; StartTime=(Get-Date).AddHours(-1)} | Select-Object TimeCreated, Id, ProviderName, LevelDisplayName, Message` --- **Linux** `[RO] systemctl status --no-pager` `[RO] journalctl -u --since "1 hour ago" --no-pager` --- **macOS** `[RO] launchctl list | grep -i ""` `[RO] log show --last 1h --predicate 'process == ""' --style compact` **Zu prüfende Hinweise** - Dienst läuft nicht, - Dienst startet wiederholt neu, - Abhängigkeit ist ausgefallen, - Port kann nicht gebunden werden, - Konfigurationsdatei enthält Fehler, - Dienstkonto kann sich nicht anmelden, - Zertifikat kann nicht geladen werden, - Datenträger ist voll, - Datei oder Datenbank ist gesperrt, - Arbeitsspeicher reicht nicht aus. --- **23. Benutzer- und Berechtigungshypothesen prüfen** **Windows** **Benutzeridentität und Gruppen** `[RO][SENSITIV] whoami /all` **NTFS-Berechtigungen** `[RO][SENSITIV] icacls ""` **PowerShell-ACL** `[RO][SENSITIV] Get-Acl "" | Format-List` **Domänenkanal auf Mitgliedscomputern prüfen** `[TEST] Test-ComputerSecureChannel -Verbose` > `Test-ComputerSecureChannel` ist für Domänenmitgliedscomputer vorgesehen. Auf Domänencontrollern ist dieses Cmdlet laut Microsoft nicht zur zuverlässigen Prüfung geeignet. Der Parameter `-Repair` wäre eine Änderung und gehört nicht zum reinen Test. --- **Linux** **Benutzer und Gruppen** `[RO] id ` **Datei- und Verzeichnisrechte** `[RO] ls -ld ""` **Rechte des vollständigen Pfades** `[RO] namei -l ""` **POSIX-ACL anzeigen** `[RO][SENSITIV] getfacl ""` --- **macOS** **Benutzer und Gruppen** `[RO] id ` **Dateirechte und ACL** `[RO][SENSITIV] ls -lde ""` **Typische Vergleichstests** | Test | Interpretation | |---|---| | Anderer Benutzer funktioniert am selben Client | Benutzer oder Berechtigung priorisieren | | Derselbe Benutzer funktioniert an anderem Client | Client oder Benutzerprofil priorisieren | | Testkonto mit gleicher Rolle funktioniert | individuelles Konto untersuchen | | Testkonto mit anderer Rolle funktioniert | Rollen- oder Gruppenberechtigung untersuchen | | Dateizugriff direkt möglich, Anwendung nicht | Anwendung oder Dienstkonto untersuchen | Bei Anmeldetests muss eine mögliche Kontosperrung berücksichtigt werden. --- **24. Konfigurationen vergleichen** **Windows PowerShell** `[RO] Compare-Object (Get-Content "") (Get-Content "")` **Prüfsumme vergleichen** `[RO] Get-FileHash "" -Algorithm SHA256` --- **Linux und macOS** `[RO] diff -u "" ""` **Prüfsumme unter Linux** `[RO] sha256sum ""` **Prüfsumme unter macOS** `[RO] shasum -a 256 ""` **Zu vergleichende Werte** - Softwareversion, - Konfigurationsdatei, - DNS-Server, - Proxy, - Standardgateway, - Zertifikat, - Gruppenmitgliedschaft, - Dateiberechtigung, - Dienstkonto, - Firewallprofil, - Umgebungsvariablen, - installierte Updates, - Richtlinien, - Feature Flags. > Eine unterschiedliche Prüfsumme zeigt nur, dass Dateien verschieden sind. Sie zeigt nicht, welcher Unterschied relevant ist. --- **25. Diagnosematrix für typische Ergebnisse** | Testergebnis | Wahrscheinlicher Fehlerbereich | |---|---| | DNS-Abfrage schlägt fehl | DNS-Client, DNS-Server oder Netzwerk zum DNS-Server | | DNS liefert falsche IP | Zone, Cache, Hosts-Datei oder Split-DNS | | IP-Ping funktioniert, Name nicht | Namensauflösung | | Ping scheitert, TCP funktioniert | ICMP wird wahrscheinlich blockiert | | TCP-Port ist erreichbar, HTTP scheitert | Anwendung, TLS, Authentifizierung oder Protokoll | | TCP-Verbindung wird abgelehnt | Kein Listener oder aktive Ablehnung | | TCP-Verbindung läuft in Timeout | Filterung, Routing, Überlastung oder Ziel antwortet nicht | | Lokal funktioniert, remote nicht | Firewall, Routing, Listener-Bindung oder NAT | | Andere Clients funktionieren | Clientbezogene Ursache | | Andere Benutzer funktionieren | Benutzer, Konto, Profil oder Berechtigung | | Gleiches VLAN betroffen | VLAN, ACL, DHCP oder Gateway | | Alle VLANs betroffen | Server, Dienst oder zentrale Komponente | | HTTP 401 | Authentifizierung untersuchen | | HTTP 403 | Autorisierung oder Richtlinie untersuchen | | HTTP 500 | Anwendung oder Backend untersuchen | | HTTP 502/504 | Proxy, Load Balancer oder Backend untersuchen | | Zertifikatsfehler | Zeit, Hostname, Trust Store oder Zertifikatskette | | Dienst läuft, aber kein Listener | Konfiguration, Bindung oder Startfehler | | Listener vorhanden, Anwendung reagiert nicht | Prozesszustand, Abhängigkeit oder Ressourcen | | Datenträger voll | Speicherverbrauch und Logwachstum untersuchen | --- **26. Mehrdeutige Ergebnisse erkennen** Ein einzelner Test liefert häufig keine eindeutige Ursache. **Beispiel: TCP-Timeout** Mögliche Ursachen: - lokale Firewall, - zentrale Firewall, - fehlende Route, - falsches Gateway, - Zielsystem ausgeschaltet, - Dienst überlastet, - asymmetrisches Routing, - falsche IP-Adresse, - Sicherheitsfilter verwirft Pakete, - Providerproblem. Deshalb folgt auf einen mehrdeutigen Test ein zweiter Test, der diese Möglichkeiten weiter trennt. **Geeignete Folgeprüfungen** - Test von anderem Client, - Test aus anderem VLAN, - Test direkt auf dem Server, - Listener auf dem Server prüfen, - Firewall-Logging prüfen, - Paketaufzeichnung auf Client oder Server, - Routingtabellen vergleichen, - Monitoring und zentrale Protokolle prüfen. --- **27. Beispiel einer vollständigen Hypothesenliste** **Störung** Clients aus VLAN 30 können `https://server.example` nicht öffnen. Clients aus VLAN 40 funktionieren. DNS liefert in beiden VLANs dieselbe IP-Adresse. | Nr. | Hypothese | Belege dafür | Belege dagegen | Test | Priorität | |---:|---|---|---|---|---| | H1 | ACL blockiert VLAN 30 zu TCP 443 | Nur VLAN 30 betroffen | Noch keine | TCP-Test und Firewall-Log | P1 | | H2 | Falsches Gateway in VLAN 30 | gesamtes VLAN betroffen | Andere Ziele erreichbar | Route und Gateway prüfen | P1 | | H3 | DNS liefert falsche Adresse | Webdienst nicht erreichbar | Beide VLANs erhalten dieselbe IP | DNS-Ergebnisse vergleichen | P4 | | H4 | Webdienst ist ausgefallen | Verbindung schlägt fehl | VLAN 40 funktioniert | lokaler und externer Porttest | P4 | | H5 | MTU-Problem im Netzwerkpfad | HTTPS betroffen | noch keine Größenabhängigkeit bekannt | Paketgröße und Paketaufzeichnung | P2 | | H6 | Proxy wird nur in VLAN 30 verwendet | nur bestimmte Clients betroffen möglich | noch ungeprüft | Proxykonfiguration vergleichen | P2 | **Erste Prüfung** `Test-NetConnection server.example -Port 443` Ergebnis: - VLAN 30: `TcpTestSucceeded: False` - VLAN 40: `TcpTestSucceeded: True` Dadurch werden H1, H2 oder H6 wahrscheinlicher. H3 und H4 werden weniger wahrscheinlich. **Zweite Prüfung** - Standardgateway in VLAN 30 ist korrekt. - Andere Ziele über dasselbe Gateway funktionieren. - Firewall protokolliert einen verworfenen Verbindungsversuch von VLAN 30 zu TCP 443. Damit wird H1 stark gestützt. **Bestätigung** Nach einer freigegebenen Korrektur der betroffenen ACL-Regel funktioniert derselbe definierte Test aus VLAN 30. Die Firewall protokolliert nun eine erlaubte Verbindung. --- **28. Hypothesenstatus verwenden** | Status | Bedeutung | |---|---| | Offen | Noch nicht geprüft | | Gestützt | Hinweise sprechen dafür | | Teilweise gestützt | Einige Ergebnisse passen, andere sind offen | | Unklar | Test war nicht eindeutig | | Widerlegt | Ergebnis widerspricht der Vorhersage | | Bestätigt | Mehrere Belege und Gegenprobe stützen die Ursache | | Zurückgestellt | Derzeit geringe Priorität | | Nicht prüfbar | Werkzeug, Zugriff oder Vergleichssystem fehlt | Eine Hypothese sollte nicht bereits nach einem passenden Einzelbefund als bestätigt gelten. --- **29. Wann gilt eine Ursache als bestätigt?** Eine Ursache ist ausreichend bestätigt, wenn möglichst mehrere Kriterien erfüllt sind: - sie erklärt das gesamte Fehlerbild, - sie erklärt den betroffenen Umfang, - sie passt zum zeitlichen Verlauf, - passende technische Belege sind vorhanden, - alternative Hypothesen wurden widerlegt, - der Fehler kann reproduziert werden, - eine Gegenprobe verändert das Ergebnis wie erwartet, - die Korrektur beseitigt den ursprünglichen Fehler, - die Korrektur verursacht keine neuen Störungen. **Besonders starke Bestätigung** | Zustand | Ergebnis | |---|---| | Fehlerzustand vorhanden | definierter Test schlägt fehl | | Ursache kontrolliert entfernt | derselbe Test funktioniert | | Ursache in Testumgebung erneut hergestellt | derselbe Test schlägt wieder fehl | | Ursache erneut entfernt | derselbe Test funktioniert wieder | In Produktionsumgebungen ist ein erneutes absichtliches Herstellen des Fehlers häufig nicht vertretbar. In diesem Fall müssen Protokolle, Vergleichssysteme und technische Plausibilität gemeinsam bewertet werden. --- **30. Typische Denkfehler vermeiden** | Denkfehler | Beschreibung | Gegenmaßnahme | |---|---|---| | Bestätigungsfehler | Es werden nur Belege für die Lieblingshypothese gesucht | aktiv nach widersprechenden Fakten suchen | | Fixierung | Erste Erklärung wird nicht mehr hinterfragt | mindestens mehrere Hypothesen notieren | | Zeitliche Verwechslung | Änderung vor Fehler wird automatisch zur Ursache | technische Verbindung und Gegenprobe verlangen | | Autoritätseffekt | Aussage einer erfahrenen Person wird ungeprüft übernommen | Messwerte und Protokolle verwenden | | Verfügbarkeitseffekt | Kürzlich erlebter Fehler wird überall vermutet | aktuellen Umfang und aktuelle Fakten prüfen | | Aktionismus | Sichtbare Aktivität ersetzt systematische Diagnose | erwartetes Testergebnis vorab definieren | | Erfolgsfehlschluss | Nach Neustart geht es, daher sei Ursache gefunden | Wiederherstellung und Ursachenbestätigung trennen | | Werkzeuggläubigkeit | Ausgabe eines Werkzeugs wird als absolute Wahrheit angesehen | Messgrenzen und Gegenprüfung beachten | | Scheingenauigkeit | Punktwert wird mit Gewissheit verwechselt | Priorisierung als Hilfsmittel verwenden | | Gruppendenken | Team übernimmt eine Vermutung ohne Gegenargument | gezielt eine alternative Erklärung verlangen | --- **31. Regeln für aussagekräftige Tests** - Möglichst nur eine Variable verändern. - Vorher und nachher denselben Test verwenden. - Erwartetes Ergebnis vorher festlegen. - Funktionierendes Vergleichssystem verwenden. - Quell- und Zielsystem dokumentieren. - Uhrzeit und Zeitzone dokumentieren. - Exakten Befehl dokumentieren. - Vollständige Ausgabe sichern. - Fehlercode nicht nur sinngemäß wiedergeben. - Test möglichst mehrfach reproduzieren. - Belastung und Nebenwirkungen berücksichtigen. - Nach negativer Prüfung Hypothese herabstufen. - Bei unklarem Ergebnis einen trennschärferen Test wählen. - Keine produktionsweite Änderung als ersten Test verwenden. --- **32. Dokumentationsvorlage für Hypothesen** | Nr. | Hypothese | Technische Begründung | Belege dafür | Belege dagegen | Geplanter Test | Erwartetes Ergebnis | Risiko | Priorität | Ergebnis | Status | |---:|---|---|---|---|---|---|---|---|---|---| | H1 | | | | | | | | | | | | H2 | | | | | | | | | | | | H3 | | | | | | | | | | | | H4 | | | | | | | | | | | --- **33. Dokumentationsvorlage für einen Test** | Feld | Eintrag | |---|---| | Ticketnummer | | | Hypothese | | | Testnummer | | | Datum und Uhrzeit | | | Zeitzone | | | Ausführende Person | | | Quellsystem | | | Quell-IP | | | Zielsystem | | | Ziel-IP | | | Protokoll und Port | | | Ausgangszustand | | | Exakter Befehl | | | Erwartetes Ergebnis | | | Tatsächliches Ergebnis | | | Vollständige Ausgabe gesichert | Ja / Nein | | Hypothese gestützt | Ja / Nein / Unklar | | Nebenwirkungen | | | Rückfall erforderlich | Ja / Nein | | Nächster Test | | --- **Kurzcheckliste** - [ ] Problembeschreibung präzise formuliert - [ ] Fakten und Vermutungen getrennt - [ ] Betroffene und nicht betroffene Systeme berücksichtigt - [ ] Mehrere plausible Hypothesen aufgestellt - [ ] Für jede Hypothese technischer Zusammenhang beschrieben - [ ] Unterstützende Belege notiert - [ ] Widersprechende Belege notiert - [ ] Erwartetes Testergebnis vorher definiert - [ ] Widerlegendes Ergebnis vorher definiert - [ ] Risiko und Aufwand des Tests bewertet - [ ] Sichere Tests mit hohem Informationsgewinn priorisiert - [ ] Funktionierendes Vergleichssystem verwendet - [ ] Möglichst nur eine Variable verändert - [ ] Exakten Befehl und Zeitpunkt dokumentiert - [ ] Testergebnis vollständig gesichert - [ ] Hypothesenstatus nach jedem Test aktualisiert - [ ] Alternative Ursachen nicht vorschnell ausgeschlossen - [ ] Wiederherstellung und Ursachenbestätigung getrennt - [ ] Ursache durch Gegenprobe oder mehrere Belege bestätigt --- **Ergebnis dieses Arbeitsschrittes** Am Ende liegt keine unsortierte Sammlung von Vermutungen mehr vor, sondern ein priorisierter Prüfplan. Jede wichtige Hypothese enthält: - eine konkrete mögliche Ursache, - einen technischen Zusammenhang, - unterstützende und widersprechende Fakten, - einen möglichst sicheren Test, - ein erwartetes Ergebnis, - ein widerlegendes Ergebnis, - einen dokumentierten Status. Dadurch wird die Fehlersuche nachvollziehbar, reproduzierbar und wesentlich effizienter. **Nächste Seite:** **1.6 Prüfungen kontrolliert durchführen und Ergebnisse bewerten** --- **Offizielle Hersteller- und Standarddokumentation** - [Microsoft Learn – Test-NetConnection](https://learn.microsoft.com/en-us/powershell/module/nettcpip/test-netconnection) - [Microsoft Learn – Resolve-DnsName](https://learn.microsoft.com/en-us/powershell/module/dnsclient/resolve-dnsname) - [Microsoft Learn – DNS-Clientprobleme untersuchen](https://learn.microsoft.com/en-us/troubleshoot/windows-client/networking/troubleshoot-dns-client-resolution-issues) - [Microsoft Learn – Test-ComputerSecureChannel](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.management/test-computersecurechannel) - [freedesktop.org – systemctl](https://www.freedesktop.org/software/systemd/man/latest/systemctl.html) - [freedesktop.org – journalctl](https://www.freedesktop.org/software/systemd/man/latest/journalctl.html) - [curl – Offizielle Befehlsreferenz](https://curl.se/docs/manpage.html) - [OpenSSL – openssl s_client](https://docs.openssl.org/master/man1/openssl-s_client/) - [RFC Editor – RFC 9110: HTTP Semantics](https://www.rfc-editor.org/rfc/rfc9110.html) - [Apple Support – Protokollmeldungen in der Konsole anzeigen](https://support.apple.com/guide/console/log-messages-cnsl1012/mac) # 1.6 Prüfungen kontrolliert durchführen und Ergebnisse bewerten Eine gute Hypothese ist nur dann nützlich, wenn sie mit einem kontrollierten und aussagekräftigen Test geprüft wird. Dabei gilt: > Gleicher Ausgangszustand, gleicher Test, nur eine veränderte Variable und ein vorher festgelegtes erwartetes Ergebnis. Wer mehrere Dinge gleichzeitig verändert, kann die Wirkung später keiner einzelnen Maßnahme zuordnen. --- **Ziel dieser Seite** Nach diesem Arbeitsschritt sollten: - Prüfziel und Hypothese eindeutig feststehen, - Ausgangszustand und Vergleichswerte dokumentiert sein, - Risiken und mögliche Auswirkungen des Tests bekannt sein, - Erfolgskriterien und Abbruchkriterien definiert sein, - möglichst nur eine Variable verändert werden, - Befehle, Ausgaben und Rückgabewerte gesichert sein, - Ergebnisse reproduzierbar sein, - unklare Tests nicht als Bestätigung interpretiert werden, - der Zustand nach dem Test erneut geprüft sein. --- **1. Kennzeichnung der Befehle** | Kennzeichnung | Bedeutung | |---|---| | `[RO]` | Read-only: liest Informationen aus | | `[TEST]` | Führt eine aktive Prüfung aus und kann Netzwerkverkehr oder Protokolleinträge erzeugen | | `[FILE]` | Erstellt oder überschreibt eine Datei | | `[PRIV]` | Benötigt möglicherweise Administrator- oder Root-Rechte | | `[CHANGE]` | Verändert Konfiguration oder Betriebszustand | | `[DISRUPTIV]` | Kann Benutzer oder produktive Dienste beeinträchtigen | | `[SENSITIV]` | Ausgabe kann vertrauliche Daten enthalten | Auch ein `[RO]`- oder `[TEST]`-Befehl ist nicht vollständig spurlos. Er startet mindestens einen Prozess und kann in Protokollen, Shell-Historien, Firewalls oder SIEM-Systemen erscheinen. --- **2. Der kontrollierte Prüfablauf** | Phase | Tätigkeit | |---|---| | 1. Prüfziel | Welche Frage soll der Test beantworten? | | 2. Hypothese | Welche mögliche Ursache wird geprüft? | | 3. Ausgangszustand | Welche Messwerte liegen vor dem Test vor? | | 4. Vorhersage | Welches Ergebnis wird erwartet? | | 5. Risiko | Welche Nebenwirkungen kann der Test haben? | | 6. Abbruchkriterium | Wann muss der Test sofort beendet werden? | | 7. Durchführung | Exakten Befehl oder Ablauf verwenden | | 8. Aufzeichnung | Zeit, Ausgabe und Rückgabewert sichern | | 9. Wiederholung | Ergebnis bei Bedarf kontrolliert reproduzieren | | 10. Rückkehr | Ausgangszustand wiederherstellen | | 11. Vergleich | Vorher- und Nachher-Ergebnis vergleichen | | 12. Bewertung | Hypothese bestätigen, stützen, offenlassen oder widerlegen | --- **3. Testarten nach Eingriffsrisiko** | Testart | Beschreibung | Beispiel | Risiko | |---|---|---|---| | Passive Abfrage | Liest vorhandenen Zustand | Prozessliste, Logs, Routingtabelle | Sehr niedrig | | Aktiver Funktionstest | Sendet eine kontrollierte Anfrage | DNS-, Ping-, TCP- oder HTTP-Test | Niedrig | | Vergleichstest | Vergleicht betroffenes und funktionierendes System | Client A gegen Client B | Niedrig | | Wiederholungstest | Prüft, ob das Ergebnis reproduzierbar ist | fünf identische TCP-Tests | Niedrig bis mittel | | Isolationstest | Verändert nur den Testkontext | bestimmtes Backend mit `curl --resolve` | Niedrig bis mittel | | Reversible Änderung | Verändert vorübergehend eine Einstellung | freigegebene Testregel | Mittel | | Dienstbezogener Test | Startet oder beendet einen Dienst | Dienstneustart | Hoch | | Failover-Test | Verlagert produktiven Betrieb | Wechsel auf zweiten Server | Hoch | | Lasttest | Erzeugt zusätzliche Last | viele parallele Anfragen | Hoch | | Wiederherstellungstest | Setzt Konfiguration oder Version zurück | Rollback | Hoch | | Destruktiver Test | Kann Daten oder Zustand zerstören | Löschen, Zurücksetzen, Neuinstallation | Sehr hoch | Passive, aktive und vergleichende Tests sollten normalerweise vor verändernden oder potenziell störenden Tests durchgeführt werden. --- **4. Prüfung und Reparatur nicht vermischen** **Reine Prüfung** `[TEST] Test-ComputerSecureChannel -Verbose` Dieser Befehl prüft auf einem Windows-Domänenmitglied den sicheren Kanal. **Verändernde Reparatur** `[CHANGE] Test-ComputerSecureChannel -Repair` Der Parameter `-Repair` verändert den Zustand und ist keine reine Prüfung mehr. Ein ähnlicher Unterschied besteht bei vielen Werkzeugen: | Prüfung | Veränderung | |---|---| | `Get-Service` | `Restart-Service` | | `systemctl status` | `systemctl restart` | | `ipconfig /displaydns` | `ipconfig /flushdns` | | `Get-NetRoute` | `New-NetRoute` oder `Remove-NetRoute` | | `journalctl` | Löschen oder Rotieren von Logs | | `diff` | Überschreiben der Konfiguration | | Firewall-Log ansehen | Firewall-Regel ändern | | Zertifikat anzeigen | Zertifikat ersetzen | | Updateverlauf anzeigen | Update installieren oder entfernen | Prüfung und Reparatur sollten im Ticket als getrennte Schritte dokumentiert werden. --- **5. Prüfziel präzise formulieren** **Ungeeignet** `Ich teste das Netzwerk.` **Besser** `Es wird geprüft, ob Client PC-030 aus VLAN 30 am 30.07.2026 um 15:30 Uhr eine TCP-Verbindung zu server.example auf Port 443 herstellen kann.` **Noch besser** `Hypothese H1: Eine ACL blockiert TCP 443 aus VLAN 30. Erwartet wird, dass der TCP-Test aus VLAN 30 fehlschlägt und derselbe Test aus VLAN 40 erfolgreich ist.` Ein präzises Prüfziel enthält: - Hypothesennummer, - Quellsystem, - Quell-IP oder Quellnetz, - Zielsystem, - Ziel-IP, - Protokoll, - Port, - Benutzerkontext, - Zeitpunkt und Zeitzone, - erwartetes Ergebnis, - widerlegendes Ergebnis. --- **6. Ausgangszustand als Baseline erfassen** Eine Baseline ist der dokumentierte Zustand vor dem Test. **Typische Baseline-Werte** - aktuelle Uhrzeit, - Systemzustand, - Dienststatus, - Prozess-ID, - CPU- und Speicherauslastung, - Netzwerkverbindungen, - IP-Konfiguration, - DNS-Ergebnis, - Routingweg, - Anwendungsergebnis, - Antwortzeit, - Fehlercode, - Ereignisprotokolle, - Monitoringzustand. **Beispiel** | Messwert | Vor dem Test | |---|---| | Zeitpunkt | 2026-07-30 15:30:00 CEST | | Quelle | PC-030 | | Quell-IP | 192.0.2.30 | | Quell-VLAN | VLAN 30 | | Ziel | server.example | | Ziel-IP | 198.51.100.20 | | Zielport | TCP 443 | | DNS-Auflösung | erfolgreich | | TCP-Test | fehlgeschlagen | | HTTP-Test | keine Verbindung | | Ping | keine Antwort | | Andere Ziele | erreichbar | | Vergleichsclient aus VLAN 40 | funktioniert | Die IP-Adressen aus den Netzen `192.0.2.0/24` und `198.51.100.0/24` sind für Dokumentationsbeispiele reserviert. --- **7. Nur eine Variable verändern** **Ungeeigneter Test** Gleichzeitig werden: - Client neu gestartet, - DNS-Cache geleert, - Netzwerkkabel gewechselt, - Firewall deaktiviert, - Update installiert, - Dienst neu gestartet. Wenn der Fehler danach verschwunden ist, bleibt unklar, welche Maßnahme wirksam war. **Besseres Vorgehen** 1. Ausgangszustand sichern. 2. DNS-Auflösung prüfen. 3. TCP-Verbindung prüfen. 4. Vergleichsclient testen. 5. anderes Kabel oder anderen Port testen. 6. nach jedem Schritt denselben Funktionstest wiederholen. 7. erst danach eine freigegebene Konfigurationsänderung durchführen. --- **8. Kontrollvariable und Vergleichssystem verwenden** Ein Vergleichssystem hilft zu erkennen, ob eine Ursache: - benutzerbezogen, - clientbezogen, - netzwerkbezogen, - serverbezogen oder - anwendungsbezogen ist. | Test | Konstante Werte | Veränderte Variable | |---|---|---| | Gleicher Benutzer, anderer Client | Benutzer, Ziel, Funktion | Client | | Anderer Benutzer, gleicher Client | Client, Ziel, Funktion | Benutzer | | Gleicher Client, anderes VLAN | Client, Benutzer, Ziel | Netzwerkpfad | | Gleiches VLAN, anderer Client | Netzwerk, Ziel | Client | | Gleiches Ziel, direkter Porttest | Client, Netzwerk, Ziel | Anwendungsebene | | Gleiche URL, bestimmtes Backend | Client, URL, Hostname | Backend | | Gleiche Datei, anderes Konto | Datei, Client, Pfad | Berechtigung | | Gleicher Dienst, localhost | Server, Dienst, Port | Netzwerkpfad entfällt | Je weniger Variablen sich zwischen den Testfällen unterscheiden, desto aussagekräftiger ist der Vergleich. --- **9. Testzeitpunkt dokumentieren** **Windows** `[RO] Get-Date -Format o` **UTC-Zeit** `[RO] (Get-Date).ToUniversalTime().ToString("o")` **Linux** `[RO] date --iso-8601=seconds` **macOS** `[RO] date "+%Y-%m-%dT%H:%M:%S%z"` Der Zeitpunkt sollte unmittelbar vor und nach dem Test erfasst werden. Dadurch kann die Ausgabe mit Server-, Firewall-, Proxy- und SIEM-Protokollen verglichen werden. --- **10. PowerShell-Sitzung protokollieren** PowerShell kann Befehle und Konsolenausgaben einer Sitzung in einer Transkriptdatei aufzeichnen. **Protokollierung starten** `[FILE][SENSITIV] Start-Transcript -Path "\Testprotokoll.txt" -IncludeInvocationHeader -NoClobber` **Protokollierung beenden** `[FILE] Stop-Transcript` `-IncludeInvocationHeader` ergänzt Zeitinformationen zu den ausgeführten Befehlen. `-NoClobber` verhindert, dass eine bereits vorhandene Datei überschrieben wird. **Zu beachten** - Das Transkript kann Benutzernamen, interne Pfade und Befehlsparameter enthalten. - Zugangsdaten oder Token dürfen nicht direkt in Befehle geschrieben werden. - GUI-Aktionen werden nicht erfasst. - Nicht jede externe Anwendung wird vollständig abgebildet. - Die Datei muss an einem freigegebenen Speicherort abgelegt werden. --- **11. Linux- und macOS-Terminalsitzung protokollieren** Das Werkzeug `script` erstellt eine Aufzeichnung der Terminalsitzung. **Aufzeichnung starten** `[FILE][SENSITIV] script "/Testprotokoll.txt"` Anschließend werden die vorgesehenen Diagnosebefehle ausgeführt. **Aufzeichnung beenden** `exit` Alternativ kann die Sitzung mit `Strg + D` beendet werden. **Zu beachten** - Die Datei kann Steuerzeichen enthalten. - Eingaben und Ausgaben können sensible Informationen enthalten. - Interaktive Programme werden nicht immer als sauberer Text dargestellt. - Der genaue Funktionsumfang unterscheidet sich zwischen Linux und macOS. - Die lokale Dokumentation kann mit `man script` aufgerufen werden. --- **12. Einzelne PowerShell-Ausgabe in Datei und Konsole schreiben** `Tee-Object` zeigt die Ausgabe auf der Konsole an und speichert sie gleichzeitig in einer Datei. `[FILE] Test-NetConnection server.example -Port 443 -InformationLevel Detailed | Tee-Object -FilePath "\tcp-test.txt"` **Mit Zeitstempel** Get-Date -Format o | Tee-Object -FilePath "\tcp-test.txt" Test-NetConnection server.example -Port 443 -InformationLevel Detailed | Tee-Object -FilePath "\tcp-test.txt" -Append `-Append` fügt die Ausgabe an die vorhandene Datei an. --- **13. Einzelne Linux- oder macOS-Ausgabe sichern** **Ausgabe und Fehlermeldungen in eine Datei schreiben** `[FILE] > "/test-output.txt" 2>&1` **Ausgabe gleichzeitig anzeigen und speichern** `[FILE] 2>&1 | tee "/test-output.txt"` > Bei einer Pipeline mit `tee` kann der direkt danach angezeigte Rückgabewert zur letzten Komponente der Pipeline gehören. Wenn der ursprüngliche Rückgabewert wichtig ist, sollte der Befehl zunächst ohne Pipeline ausgeführt und anschließend die Datei angezeigt werden. **Rückgabewert zuverlässig sichern** started_at=$(date "+%Y-%m-%dT%H:%M:%S%z") curl --connect-timeout 5 --max-time 15 https://server.example/ > "/curl-test.txt" 2>&1 test_rc=$? ended_at=$(date "+%Y-%m-%dT%H:%M:%S%z") echo "Start: $started_at" echo "Ende: $ended_at" echo "Exit-Code: $test_rc" cat "/curl-test.txt" Der Rückgabewert muss unmittelbar nach dem geprüften Befehl in einer Variablen gesichert werden. --- **14. Rückgabewerte unter Windows auswerten** **PowerShell-Cmdlets** `$?` zeigt an, ob die unmittelbar vorherige PowerShell-Operation erfolgreich abgeschlossen wurde. `[RO] $?` Mögliche Werte: - `$true` - `$false` **Native Programme** `$LASTEXITCODE` enthält den Rückgabewert des zuletzt ausgeführten nativen Programms. curl.exe --connect-timeout 5 --max-time 15 https://server.example/ $curlExitCode = $LASTEXITCODE "curl Exit-Code: $curlExitCode" **Windows-Eingabeaufforderung** `[RO] echo %ERRORLEVEL%` > Der Rückgabewert muss direkt nach dem betreffenden Programm geprüft werden. Ein nachfolgender Befehl kann den gespeicherten Wert verändern. --- **15. Rückgabewerte unter Linux und macOS auswerten** `$?` enthält den Rückgabewert des zuletzt ausgeführten Befehls. curl --connect-timeout 5 --max-time 15 https://server.example/ test_rc=$? echo "Exit-Code: $test_rc" Unter Unix-artigen Systemen bedeutet üblicherweise: | Rückgabewert | Allgemeine Bedeutung | |---:|---| | `0` | Programm meldet Erfolg | | ungleich `0` | Programm meldet Fehler oder besonderen Zustand | Die genaue Bedeutung hängt vom jeweiligen Programm ab und muss in dessen Dokumentation geprüft werden. --- **16. Erfolg des Werkzeugs und Erfolg der Funktion unterscheiden** Ein Rückgabewert `0` bedeutet nicht automatisch, dass die vom Benutzer benötigte Funktion erfolgreich war. **Beispiel mit curl** Ohne zusätzliche Option kann curl eine HTTP-Antwort `404`, `403` oder `500` empfangen und trotzdem mit Exit-Code `0` enden. Die Netzwerkübertragung war erfolgreich, obwohl die Anwendung einen Fehlerstatus zurückgab. Deshalb müssen mindestens zwei Ebenen getrennt werden: | Ebene | Beispiel | |---|---| | Werkzeugausführung | curl konnte eine HTTP-Antwort empfangen | | Fachliche Funktion | Benutzer konnte sich erfolgreich anmelden | | Anwendungsstatus | Server antwortete mit HTTP 200 | | Inhaltliche Richtigkeit | Gelieferte Daten sind vollständig und korrekt | **HTTP-Fehler als curl-Fehler behandeln** `[TEST] curl --fail --connect-timeout 5 --max-time 15 https://server.example/` Die Option `--fail` lässt curl bei HTTP-Statuscodes ab 400 einen Fehler melden. Dabei wird der Antworttext normalerweise nicht ausgegeben. Für eine Diagnose ist es häufig besser, zunächst HTTP-Status und Ausgabe separat zu dokumentieren. --- **17. Zeitbegrenzungen verwenden** Tests sollten nicht unbegrenzt warten. **Windows** `[TEST] curl.exe --connect-timeout 5 --max-time 15 https://server.example/` **Linux** `[TEST] curl --connect-timeout 5 --max-time 15 https://server.example/` **macOS** `[TEST] curl --connect-timeout 5 --max-time 15 https://server.example/` | Option | Bedeutung | |---|---| | `--connect-timeout 5` | maximal fünf Sekunden für die Verbindungsphase | | `--max-time 15` | maximal 15 Sekunden für den gesamten Transfer | Zur Verbindungsphase gehören bei curl unter anderem DNS-Auflösung sowie TCP-, TLS- oder QUIC-Verbindungsaufbau. --- **18. HTTP-Zeiten gezielt messen** curl kann einzelne Zeitabschnitte einer HTTP-Verbindung ausgeben. **Windows PowerShell** `[TEST] curl.exe -sS -o NUL -w 'code=%{http_code} remote=%{remote_ip} dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} first_byte=%{time_starttransfer} total=%{time_total}\n' --connect-timeout 5 --max-time 15 https://server.example/` **Linux und macOS** `[TEST] curl -sS -o /dev/null -w "code=%{http_code} remote=%{remote_ip} dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} first_byte=%{time_starttransfer} total=%{time_total}\n" --connect-timeout 5 --max-time 15 https://server.example/` **Bedeutung der Werte** | Wert | Bedeutung | |---|---| | `http_code` | empfangener HTTP-Status | | `remote_ip` | tatsächlich verwendete Ziel-IP | | `time_namelookup` | Zeit bis zum Abschluss der Namensauflösung | | `time_connect` | Zeit bis zum TCP-Verbindungsaufbau | | `time_appconnect` | Zeit bis zum Abschluss des TLS-Handshakes | | `time_starttransfer` | Zeit bis zum ersten empfangenen Byte | | `time_total` | gesamte Übertragungszeit | Die Zeitwerte werden in Sekunden ausgegeben. --- **19. HTTP-Zeitwerte interpretieren** | Beobachtung | Mögliche Ursache | |---|---| | `time_namelookup` hoch | DNS-Server, Resolver oder Weiterleitung langsam | | `time_connect` hoch | Netzwerkpfad, Firewall, Überlastung oder Server | | `time_appconnect` deutlich höher | TLS-Handshake, Zertifikat oder Kryptografie | | `time_starttransfer` hoch | Anwendung oder Backend benötigt lange | | `time_total` hoch, erstes Byte schnell | langsame Datenübertragung oder große Antwort | | wechselnde `remote_ip` | DNS-Rotation, Load Balancer oder mehrere Backends | | wechselnder HTTP-Status | unterschiedliche Backends oder instabiler Dienst | | `http_code=000` | keine gültige HTTP-Antwort empfangen | Ein einzelner Messwert reicht bei sporadischen Fehlern nicht aus. Mehrere Messungen mit Zeitstempel sind aussagekräftiger. --- **20. Tests wiederholen, ohne unnötige Last zu erzeugen** **Windows-Ping** `[TEST] ping -n 10 ` **Linux und macOS** `[TEST] ping -c 10 ` **Wiederholter TCP-Test unter Windows** 1..5 | ForEach-Object { $result = Test-NetConnection server.example -Port 443 -InformationLevel Detailed [pscustomobject]@{ Time = Get-Date -Format o RemoteAddress = $result.RemoteAddress SourceAddress = $result.SourceAddress Success = $result.TcpTestSucceeded } Start-Sleep -Seconds 2 } **Wiederholter TCP-Test unter Linux und macOS** for test_number in 1 2 3 4 5 do date "+%Y-%m-%dT%H:%M:%S%z" nc -vz -w 3 server.example 443 sleep 2 done Vor Wiederholungstests ist zu prüfen: - Wie viel Last erzeugt eine Anfrage? - Kann ein Konto gesperrt werden? - Greift ein Rate Limit? - Wird ein Alarm im SIEM ausgelöst? - Kann die Anwendung Daten verändern? - Ist der Test in der Produktion zulässig? --- **21. Sporadische Fehler richtig untersuchen** Ein sporadischer Fehler kann übersehen werden, wenn nur ein einzelner Test durchgeführt wird. Zu dokumentieren sind: - Anzahl der Tests, - zeitlicher Abstand, - Anzahl erfolgreicher Tests, - Anzahl fehlgeschlagener Tests, - genaue Fehlercodes, - verwendete Ziel-IP, - verwendetes Backend, - Antwortzeiten, - Zeitpunkt jedes Fehlers. **Beispiel** | Versuch | Uhrzeit | Ziel-IP | TCP | HTTP | Gesamtzeit | |---:|---|---|---|---:|---:| | 1 | 15:30:00 | 198.51.100.20 | erfolgreich | 200 | 0,21 s | | 2 | 15:30:05 | 198.51.100.21 | erfolgreich | 503 | 4,92 s | | 3 | 15:30:10 | 198.51.100.20 | erfolgreich | 200 | 0,19 s | | 4 | 15:30:15 | 198.51.100.21 | erfolgreich | 503 | 5,01 s | | 5 | 15:30:20 | 198.51.100.20 | erfolgreich | 200 | 0,22 s | Das Muster deutet auf ein Problem mit dem Backend `198.51.100.21` hin. --- **22. Bestimmtes HTTPS-Ziel ohne DNS-Änderung testen** Der Aufruf einer HTTPS-Seite direkt über ihre IP-Adresse kann zu falschen Ergebnissen führen, weil: - der HTTP-Host-Header verändert wird, - TLS-SNI nicht zum erwarteten Hostnamen passt, - das Zertifikat nicht für die IP-Adresse ausgestellt ist, - ein anderer virtueller Host antwortet. Mit `curl --resolve` kann für einen einzelnen Test ein bestimmter Hostname einer bestimmten IP-Adresse zugeordnet werden, ohne DNS oder Hosts-Datei zu verändern. **Windows** `[TEST] curl.exe --resolve "server.example:443:" -v -o NUL https://server.example/` **Linux und macOS** `[TEST] curl --resolve "server.example:443:" -v -o /dev/null https://server.example/` Dadurch bleiben erhalten: - URL-Hostname, - HTTP-Host-Header, - TLS-SNI, - normale Zertifikatsprüfung. Nur die Ziel-IP wird für diesen curl-Aufruf vorgegeben. **Beispiel für zwei Backends** `[TEST] curl --resolve "server.example:443:198.51.100.20" -v -o /dev/null https://server.example/` `[TEST] curl --resolve "server.example:443:198.51.100.21" -v -o /dev/null https://server.example/` > Das direkte Testen eines Backends kann Load Balancer, WAF oder andere Schutzsysteme umgehen. Es darf nur erfolgen, wenn dieser Test technisch vorgesehen und autorisiert ist. --- **23. Lokalen Dienst und Netzwerkpfad getrennt testen** **Windows-Server** `[TEST] Test-NetConnection localhost -Port ` `[TEST] Test-NetConnection -Port ` `[TEST] Test-NetConnection -Port ` --- **Linux-Server** `[TEST] nc -vz -w 3 localhost ` `[TEST] nc -vz -w 3 ` `[TEST] nc -vz -w 3 ` --- **macOS-Server** `[TEST] nc -vz -w 3 localhost ` `[TEST] nc -vz -w 3 ` `[TEST] nc -vz -w 3 ` **Interpretation** | localhost | Eigene IP | Remote-Client | Möglicher Fehlerbereich | |---|---|---|---| | erfolgreich | erfolgreich | erfolgreich | Netzwerkgrundfunktion vorhanden | | erfolgreich | erfolgreich | fehlgeschlagen | Netzwerkpfad oder Firewall | | erfolgreich | fehlgeschlagen | fehlgeschlagen | Listener-Bindung oder lokale Firewall | | fehlgeschlagen | fehlgeschlagen | fehlgeschlagen | Dienst oder Anwendung | | fehlgeschlagen | erfolgreich | erfolgreich | besondere Proxy-, Container- oder Weiterleitungskonfiguration | --- **24. Test mit und ohne Namensauflösung** **DNS-basierter Test** `[TEST] Test-NetConnection server.example -Port 443` **Direkter TCP-Test zur bekannten IP** `[TEST] Test-NetConnection -Port 443` Unter Linux und macOS: `[TEST] nc -vz -w 3 server.example 443` `[TEST] nc -vz -w 3 443` **Interpretation** | Name | IP | Möglicher Fehlerbereich | |---|---|---| | erfolgreich | erfolgreich | DNS und TCP-Grundfunktion vorhanden | | fehlgeschlagen | erfolgreich | DNS oder Namensauswahl | | erfolgreich | fehlgeschlagen | Testfehler oder unterschiedliche Zieladresse prüfen | | fehlgeschlagen | fehlgeschlagen | Netzwerk, Firewall, Dienst oder Zielsystem | Der direkte IP-Test ist für TCP geeignet. Für HTTPS sollte wegen Host-Header, SNI und Zertifikatsprüfung `curl --resolve` verwendet werden. --- **25. Anwendungstest und Benutzerfunktion trennen** Ein technischer Test kann erfolgreich sein, obwohl die Benutzerfunktion weiterhin fehlschlägt. | Prüfebene | Beispiel | |---|---| | DNS | Hostname wird aufgelöst | | Netzwerk | Ziel-IP ist erreichbar | | Transport | TCP-Port ist erreichbar | | TLS | Zertifikat und Handshake funktionieren | | HTTP | Server liefert eine Antwort | | Authentifizierung | Benutzer kann sich anmelden | | Autorisierung | Benutzer darf die Funktion verwenden | | Anwendung | gewünschte Aktion wird verarbeitet | | Datenebene | Datenbank speichert oder liefert korrekte Daten | | Geschäftsprozess | gesamter Arbeitsablauf funktioniert | **Beispiel** - TCP 443 erreichbar - TLS erfolgreich - HTTP 200 auf Startseite - Anmeldung erfolgreich - Datei-Upload schlägt fehl Die Ursache liegt dann nicht in der grundlegenden Erreichbarkeit, sondern möglicherweise in: - Upload-Berechtigung, - Dateigrößenlimit, - Reverse Proxy, - WAF, - Speicherplatz, - Anwendung, - Datenbank, - Backend-Storage. --- **26. Vorher- und Nachher-Test identisch durchführen** Nach einer Maßnahme muss derselbe definierte Test erneut ausgeführt werden. **Ungeeigneter Vergleich** - Vorher: Benutzer berichtet, dass es nicht funktioniert. - Nachher: Administrator pingt den Server. Diese Ergebnisse prüfen unterschiedliche Funktionen. **Geeigneter Vergleich** - Vorher: `curl` gegen dieselbe URL mit dokumentiertem Benutzerkontext. - Maßnahme: eine freigegebene Konfiguration wird geändert. - Nachher: derselbe `curl`-Befehl vom selben Client. - Danach: ursprünglicher Benutzerablauf wird wiederholt. --- **27. Vorher-Nachher-Protokoll** | Feld | Vorher | Nachher | |---|---|---| | Zeitpunkt | | | | Quellsystem | | | | Quell-IP | | | | Benutzer | | | | Zielsystem | | | | Ziel-IP | | | | Protokoll und Port | | | | DNS-Ergebnis | | | | TCP-Ergebnis | | | | TLS-Ergebnis | | | | HTTP-Status | | | | Antwortzeit | | | | Anwendungsfunktion | | | | Fehlermeldung | | | | Monitoringstatus | | | | Rückgabewert | | | --- **28. Erfolgskriterien definieren** Ein Erfolgskriterium muss messbar sein. **Ungeeignet** `Das System läuft wieder normal.` **Besser** - TCP-Verbindung ist bei fünf aufeinanderfolgenden Tests erfolgreich. - HTTP-Status ist fünfmal `200`. - Antwortzeit liegt unter dem vereinbarten Schwellenwert. - Benutzer kann sich anmelden. - Datei kann hochgeladen und wieder heruntergeladen werden. - Monitoring meldet für 30 Minuten keinen neuen Fehler. - Ereignisprotokoll enthält keine neuen relevanten Fehler. - Vergleichssystem und betroffenes System zeigen dasselbe Ergebnis. Schwellenwerte dürfen nicht frei erfunden werden. Sie müssen aus: - SLA, - Monitoring-Baseline, - Herstellerangabe, - Anwendungsanforderung oder - dokumentiertem Normalzustand abgeleitet werden. --- **29. Abbruchkriterien definieren** Ein Test muss abgebrochen werden, wenn beispielsweise: - Datenintegrität gefährdet ist, - unerwartete Systeme betroffen sind, - Fehlerrate stark ansteigt, - CPU-, RAM- oder I/O-Auslastung kritisch steigt, - Benutzer produktiv beeinträchtigt werden, - Monitoring neue kritische Alarme meldet, - eine Sicherheitswarnung auftritt, - eine Rückfallmaßnahme nicht funktioniert, - der Test außerhalb des genehmigten Umfangs wirkt, - das erwartete Zeitfenster überschritten wird. **Abbruchvorlage** | Feld | Eintrag | |---|---| | Abbruchbedingung | | | Messgröße | | | Grenzwert | | | Verantwortliche Person | | | Sofortmaßnahme | | | Rückfallmaßnahme | | | Kommunikationsweg | | --- **30. Testergebnisse klassifizieren** | Status | Bedeutung | |---|---| | Bestanden | Definiertes Erfolgskriterium vollständig erreicht | | Nicht bestanden | Definiertes Erfolgskriterium nicht erreicht | | Teilweise bestanden | Nur ein Teil der Kriterien erreicht | | Nicht eindeutig | Ergebnis lässt mehrere Erklärungen zu | | Nicht reproduzierbar | Fehler trat bei Wiederholung nicht erneut auf | | Abgebrochen | Abbruchkriterium wurde erreicht | | Nicht durchgeführt | Test konnte nicht ausgeführt werden | | Ungültig | Testbedingungen oder Messung waren fehlerhaft | „Nicht eindeutig“ ist ein gültiges Ergebnis. Es ist besser als eine unberechtigte Bestätigung. --- **31. Hypothese nach dem Test bewerten** | Testergebnis | Bewertung der Hypothese | |---|---| | Vorhersage vollständig eingetroffen | Hypothese wird gestützt | | Vorhersage mehrfach reproduziert | Hypothese wird stark gestützt | | Gegenprobe erfolgreich | Ursache möglicherweise bestätigt | | Ergebnis teilweise passend | Hypothese bleibt offen | | Ergebnis mehrdeutig | neuer trennschärferer Test erforderlich | | Vorhersage nicht eingetroffen | Hypothese wird geschwächt | | Widerlegendes Ergebnis eingetroffen | Hypothese gilt als widerlegt | | Testbedingungen fehlerhaft | keine Bewertung möglich | > Ein fehlgeschlagener Test bestätigt nicht automatisch die untersuchte Ursache. Er zeigt zunächst nur, dass die getestete Funktion unter den verwendeten Bedingungen fehlgeschlagen ist. --- **32. Falsch positive Ergebnisse** Ein Test meldet einen Fehler, obwohl die eigentliche Funktion verfügbar ist. **Beispiele** | Test | Falsch positives Ergebnis | |---|---| | Ping | keine Antwort, weil ICMP blockiert ist | | Traceroute | Sternchen, obwohl Ziel erreichbar ist | | Portscanner | Port wirkt gefiltert, weil Sicherheitskomponente reagiert | | DNS-Test | anderer Load-Balancer wird als „falsche IP“ interpretiert | | Zertifikatstest | direkter IP-Aufruf erzeugt absichtlich Namensfehler | | Dienststatus | Dienst ist gestoppt, weil er socket-aktiviert gestartet wird | | HTTP-HEAD | Server lehnt `HEAD` ab, verarbeitet aber `GET` | | Monitoring | veralteter Alarm bleibt nach Wiederherstellung aktiv | --- **33. Falsch negative Ergebnisse** Ein Test meldet Erfolg, obwohl die Benutzerfunktion weiterhin gestört ist. **Beispiele** | Test | Falsch negatives Ergebnis | |---|---| | Ping erfolgreich | Anwendung oder Port kann trotzdem ausgefallen sein | | TCP-Port erreichbar | Anwendung kann fehlerhafte Antworten liefern | | HTTP 200 | Anmeldung oder Fachfunktion kann trotzdem fehlschlagen | | Dienststatus „Running“ | Prozess kann intern hängen | | DNS-Auflösung erfolgreich | zurückgegebene Adresse kann falsch sein | | Einzelner Test erfolgreich | sporadischer Fehler wird nicht erfasst | | Testkonto funktioniert | normales Benutzerkonto kann weiterhin falsche Rechte haben | | Ein Backend funktioniert | anderes Backend kann fehlerhaft sein | | Speicherplatz vorhanden | Inodes oder Quota können trotzdem erschöpft sein | --- **34. Testwerkzeug und Testpunkt dokumentieren** Ein Ergebnis ist nur verständlich, wenn bekannt ist, wo und wie gemessen wurde. **Zu dokumentieren** - Werkzeugname, - Werkzeugversion, - Betriebssystem, - genauer Befehl, - Quellsystem, - Quell-IP, - Quell-VLAN, - Benutzerkontext, - Zielname, - Ziel-IP, - Protokoll, - Port, - Zeitpunkt, - Zeitzone, - Wiederholungsanzahl, - vollständige Ausgabe, - Rückgabewert. **Werkzeugversionen anzeigen** **PowerShell** `[RO] $PSVersionTable` **curl** `[RO] curl --version` **OpenSSL** `[RO] openssl version -a` **Linux-Kernel** `[RO] uname -a` **macOS** `[RO] sw_vers` Unterschiedliche Werkzeugversionen können verschiedene Optionen, Protokolle oder Standardwerte verwenden. --- **35. Produktivumgebung gegen Testumgebung abwägen** | Umgebung | Vorteil | Nachteil | |---|---|---| | Produktionssystem | reales Fehlerbild | Risiko für Benutzer und Daten | | Testsystem | geringeres Risiko | möglicherweise nicht identische Konfiguration | | Staging | produktionsähnlich | möglicherweise andere Daten oder Last | | isolierter Client | einzelne Variable kontrollierbar | nicht jeder Netzwerkpfad wird abgebildet | | Snapshot-Kopie | Zustand kann untersucht werden | flüchtige Informationen fehlen möglicherweise | | Labor | Tests gut reproduzierbar | Produktionsabhängigkeiten fehlen | Ein Testsystem ist nur dann aussagekräftig, wenn relevante Unterschiede zur Produktion dokumentiert sind. --- **36. Änderungen in der Produktion absichern** Vor einer verändernden Prüfung sollten geklärt sein: - Freigabe, - Wartungsfenster, - betroffene Systeme, - betroffene Benutzer, - Backup oder Konfigurationssicherung, - Rückfallplan, - Abbruchkriterien, - Monitoring, - Kommunikation, - verantwortliche Person, - erwartete Testdauer, - Beobachtungszeit nach der Änderung. **Freigabevorlage** | Feld | Eintrag | |---|---| | Ticketnummer | | | Hypothese | | | geplante Änderung | | | betroffene Systeme | | | erwartete Auswirkung | | | Risiko | | | Wartungsfenster | | | Backup vorhanden | Ja / Nein | | Rückfallplan | | | Abbruchkriterium | | | Freigabe durch | | | ausführende Person | | | beobachtende Person | | --- **37. Tests mit Anmeldungen vorsichtig durchführen** Anmeldetests können: - Konten sperren, - MFA-Anfragen auslösen, - Sicherheitsalarme erzeugen, - Sitzungen beenden, - Token erzeugen, - Lizenzplätze belegen, - Änderungen im Benutzerprofil auslösen. Vor einem Anmeldetest prüfen: - Ist das Kennwort sicher bekannt? - Wie viele Fehlversuche sind erlaubt? - Existiert ein freigegebenes Testkonto? - Wird MFA ausgelöst? - Darf das Konto auf diesem System verwendet werden? - Kann die Sitzung wieder sauber beendet werden? - Werden durch den Test Daten verändert? - Wird ein SIEM-Alarm erwartet? Kennwörter, Token und API-Schlüssel dürfen nicht in Protokolldateien, Terminaltranskripten oder Befehlszeilen erscheinen. --- **38. Beispiel eines kontrollierten Tests** **Störung** Eine Webanwendung liefert sporadisch HTTP `503`. **Hypothesen** - H1: DNS liefert zeitweise eine falsche IP-Adresse. - H2: Eines von zwei Backends ist fehlerhaft. - H3: Der TLS-Handshake schlägt sporadisch fehl. - H4: Der Client verliert zeitweise die Netzwerkverbindung. **Prüfplan** | Schritt | Test | Erwarteter Erkenntnisgewinn | |---:|---|---| | 1 | DNS mehrfach abfragen | verwendete Zieladressen bestimmen | | 2 | curl-Zeitmessung wiederholen | HTTP-Status, Ziel-IP und Zeitstufe erfassen | | 3 | Backends einzeln mit `--resolve` testen | fehlerhaftes Backend identifizieren | | 4 | TCP- und TLS-Ergebnisse vergleichen | Netzwerk- und TLS-Ursachen bewerten | | 5 | Serverlogs zum Zeitpunkt prüfen | Backendfehler bestätigen | **Ergebnis** - DNS liefert abwechselnd `198.51.100.20` und `198.51.100.21`. - Anfragen an `.20` liefern HTTP `200`. - Anfragen an `.21` liefern HTTP `503`. - TCP- und TLS-Verbindung funktionieren zu beiden Adressen. - Backendprotokoll von `.21` zeigt eine nicht erreichbare Datenbank. **Bewertung** - H1 wird widerlegt: Beide DNS-Adressen sind vorgesehen. - H2 wird stark gestützt: Der Fehler ist an Backend `.21` gebunden. - H3 wird widerlegt: TLS funktioniert bei beiden Backends. - H4 wird widerlegt: TCP-Verbindungen sind stabil. - Als nächste Hypothese wird die Datenbankverbindung von Backend `.21` geprüft. --- **39. Testprotokoll-Vorlage** | Feld | Eintrag | |---|---| | Ticketnummer | | | Testnummer | | | Hypothesennummer | | | Prüfziel | | | Datum | | | Startzeit | | | Endzeit | | | Zeitzone | | | ausführende Person | | | Quellsystem | | | Quell-IP und VLAN | | | Zielsystem | | | Ziel-IP | | | Protokoll und Port | | | Benutzerkontext | | | Werkzeug und Version | | | exakter Befehl | | | Ausgangszustand | | | erwartetes Ergebnis | | | widerlegendes Ergebnis | | | tatsächliches Ergebnis | | | Rückgabewert | | | Ausgabedatei | | | Hypothesenbewertung | | | Nebenwirkungen | | | Rückfall durchgeführt | Ja / Nein / Nicht erforderlich | | Zustand nach dem Test | | | nächster Schritt | | --- **Kurzcheckliste** - [ ] Prüfziel eindeutig formuliert - [ ] Hypothese und Vorhersage dokumentiert - [ ] Widerlegendes Ergebnis festgelegt - [ ] Ausgangszustand gesichert - [ ] Quell- und Zielsystem dokumentiert - [ ] Benutzerkontext dokumentiert - [ ] Risiko bewertet - [ ] Freigabe bei veränderndem Test eingeholt - [ ] Rückfallplan vorhanden - [ ] Abbruchkriterien definiert - [ ] Möglichst nur eine Variable verändert - [ ] Vergleichssystem verwendet - [ ] Start- und Endzeit dokumentiert - [ ] Exakten Befehl dokumentiert - [ ] Vollständige Ausgabe gesichert - [ ] Rückgabewert gesichert - [ ] Test bei Bedarf kontrolliert wiederholt - [ ] Werkzeugversion dokumentiert - [ ] Vorher- und Nachher-Test identisch durchgeführt - [ ] Benutzerfunktion zusätzlich technisch geprüft - [ ] Falsch positive Ergebnisse berücksichtigt - [ ] Falsch negative Ergebnisse berücksichtigt - [ ] Hypothesenstatus aktualisiert - [ ] Zustand nach dem Test kontrolliert - [ ] Ergebnis im Ticket dokumentiert --- **Ergebnis dieses Arbeitsschrittes** Am Ende dieses Schrittes liegt ein nachvollziehbares und reproduzierbares Testergebnis vor. Ein brauchbares Testergebnis beantwortet: - Was wurde geprüft? - Welche Hypothese wurde untersucht? - Von welchem System wurde getestet? - Unter welchem Benutzerkontext wurde getestet? - Wann wurde getestet? - Welcher genaue Befehl wurde verwendet? - Was wurde vorher erwartet? - Was wurde tatsächlich beobachtet? - Welcher Rückgabewert wurde erzeugt? - Welche Hypothese wird dadurch gestützt oder widerlegt? - Wurde der Ausgangszustand wiederhergestellt? - Welcher nächste Schritt ergibt sich daraus? **Nächste Seite:** **1.7 Ursache bestätigen und alternative Erklärungen ausschließen** --- **Offizielle Hersteller- und Projektdokumentation** - [Microsoft Learn – Start-Transcript](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.host/start-transcript) - [Microsoft Learn – Tee-Object](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.utility/tee-object) - [Microsoft Learn – Automatische PowerShell-Variablen](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_automatic_variables) - [Microsoft Learn – PowerShell-Fehlerbehandlung](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_error_handling) - [Microsoft Learn – Test-NetConnection](https://learn.microsoft.com/en-us/powershell/module/nettcpip/test-netconnection) - [curl – Offizielle Befehlsreferenz](https://curl.se/docs/manpage.html) - [curl – Exit-Codes](https://curl.se/docs/manpage.html#EXITCODES) - [util-linux – script(1), technischer Manual-Spiegel](https://man7.org/linux/man-pages/man1/script.1.html) - [GNU Bash – Exit Status](https://www.gnu.org/software/bash/manual/html_node/Exit-Status.html) # 1.7 Ursache bestätigen und alternative Erklärungen ausschließen Eine plausible Hypothese ist noch keine bestätigte Ursache. Auch wenn eine Maßnahme scheinbar erfolgreich war, kann ein anderer gleichzeitig veränderter Zustand für die Wiederherstellung verantwortlich gewesen sein. Deshalb gilt: > Eine Ursache muss das Fehlerbild technisch erklären, zu Umfang und Zeitpunkt passen und durch Belege oder Gegenproben gestützt werden. In komplexen IT-Systemen existiert häufig nicht nur eine einzelne Ursache. Meist wirken Auslöser, technische Fehler, Abhängigkeiten und begünstigende Bedingungen zusammen. --- **Ziel dieser Seite** Nach diesem Arbeitsschritt sollten: - Symptom und Ursache getrennt sein, - unmittelbare Ursache und Grundursache unterschieden sein, - Auslöser und begünstigende Faktoren identifiziert sein, - abhängige Systeme berücksichtigt sein, - widersprechende Beobachtungen geprüft sein, - alternative Erklärungen bewertet sein, - die Ursache mit mehreren Belegen bestätigt sein, - verbleibende Unsicherheiten dokumentiert sein. --- **1. Kennzeichnung der Befehle** | Kennzeichnung | Bedeutung | |---|---| | `[RO]` | Read-only: liest Informationen aus | | `[TEST]` | Führt eine aktive Prüfung aus | | `[FILE]` | Erstellt oder überschreibt eine Datei | | `[PRIV]` | Benötigt möglicherweise Administrator- oder Root-Rechte | | `[CHANGE]` | Verändert Konfiguration oder Betriebszustand | | `[DISRUPTIV]` | Kann Benutzer oder produktive Dienste beeinträchtigen | | `[SENSITIV]` | Ausgabe kann vertrauliche Daten enthalten | --- **2. Symptom, unmittelbare Ursache und Grundursache unterscheiden** | Ebene | Bedeutung | Beispiel | |---|---|---| | Symptom | Sichtbare Auswirkung | Webanwendung liefert HTTP 503 | | Unmittelbare technische Ursache | Zustand, der das Symptom direkt erzeugt | Backend kann keine Datenbankverbindung aufbauen | | Auslöser | Ereignis, das den Fehler aktiviert hat | Neue Konfiguration wurde bereitgestellt | | Grundursache | Systemischer Grund, warum der Fehler möglich war | Pipeline prüfte den Datenbank-Hostnamen nicht | | Begünstigender Faktor | Bedingung, die Entstehung oder Auswirkung verstärkte | Änderung wurde gleichzeitig auf allen Backends verteilt | | Erkennungslücke | Grund für eine verspätete Erkennung | Monitoring prüfte nur, ob TCP 443 erreichbar war | | Wiederherstellungsfaktor | Maßnahme, die den Betrieb wiederherstellte | Konfigurationsrollback | | Präventionsmaßnahme | Maßnahme gegen eine Wiederholung | Validierung und schrittweise Bereitstellung einführen | --- **3. Beispiel einer vollständigen Ursachenkette** | Ebene | Feststellung | |---|---| | Symptom | Benutzer erhalten HTTP 503 | | Direkte Ursache | Webanwendung erreicht die Datenbank nicht | | Technischer Mechanismus | Falscher Datenbank-Hostname in der Anwendungskonfiguration | | Auslöser | Deployment um 14:31 Uhr | | Grundursache | Deployment-Pipeline akzeptiert ungeprüfte Konfigurationswerte | | Begünstigender Faktor | Änderung wurde auf allen Instanzen gleichzeitig ausgerollt | | Erkennungslücke | Kein Ende-zu-Ende-Monitoring der Anmeldung | | Wiederherstellung | Vorherige Konfiguration wurde wiederhergestellt | | Prävention | Schema-Validierung, Staging-Test und schrittweiser Rollout | Die Aussage „Das Deployment war schuld“ wäre zu ungenau. Erst die vollständige Ursachenkette zeigt, was technisch fehlschlug und wodurch eine Wiederholung verhindert werden kann. --- **4. Nicht vorschnell nach einer einzigen Ursache suchen** Komplexe Störungen entstehen häufig durch eine Kombination mehrerer Bedingungen. **Beispiel** Ein einzelnes fehlerhaftes Backend führt nicht zwangsläufig zu einem Gesamtausfall. Der Ausfall entsteht möglicherweise erst, weil zusätzlich: - der Load Balancer fehlerhafte Health Checks verwendet, - alle Anfragen zum fehlerhaften Backend geleitet werden, - die verbleibenden Backends überlastet werden, - kein automatisches Failover erfolgt, - Monitoring die wachsende Fehlerquote nicht erkennt. In diesem Fall gibt es mehrere relevante Ursachen und beitragende Faktoren. **Zu dokumentierende Ursachenarten** - technische Ursache, - Konfigurationsursache, - Prozessursache, - organisatorische Ursache, - fehlende Schutzmaßnahme, - fehlende Erkennung, - fehlende oder unwirksame Wiederherstellung. --- **5. Eine Ursache gilt nicht allein durch zeitliche Nähe als bestätigt** **Unzureichende Aussage** `Der Fehler begann nach dem Update, also war das Update die Ursache.` **Erforderliche Zusatzfragen** - Welche konkrete Komponente wurde verändert? - Passt diese Komponente technisch zum Fehlerbild? - Sind nur aktualisierte Systeme betroffen? - Funktionieren identisch aktualisierte Vergleichssysteme? - Gibt es passende Protokolleinträge? - Verändert ein Rollback das Ergebnis? - Könnte der Neustart während des Updates entscheidend gewesen sein? - Wurden gleichzeitig weitere Änderungen ausgeführt? - Trat der Fehler möglicherweise bereits vor dem Update auf? --- **6. Stärke von Belegen bewerten** | Beleg | Aussagekraft | |---|---| | Vermutung ohne Messwert | Sehr gering | | Einzelne Benutzerangabe | Gering | | Zeitliche Nähe | Gering bis mittel | | Passende Fehlermeldung | Mittel | | Reproduzierbares Muster | Mittel bis hoch | | Konfigurationsunterschied zum funktionierenden System | Hoch | | Protokoll zeigt direkten technischen Fehler | Hoch | | Paketaufzeichnung bestätigt Kommunikationsfehler | Hoch | | Fehler verschwindet nach kontrollierter Entfernung der Ursache | Sehr hoch | | Fehler erscheint in Testumgebung nach kontrollierter Wiederherstellung der Ursache erneut | Sehr hoch | | Mehrere voneinander unabhängige Belege stimmen überein | Sehr hoch | Eine zuverlässige Bestätigung verwendet möglichst mehrere voneinander unabhängige Belege. --- **7. Kriterien für eine bestätigte Ursache** Eine Ursache sollte möglichst folgende Fragen beantworten: | Kriterium | Frage | |---|---| | Technischer Mechanismus | Wie erzeugt die Ursache das beobachtete Symptom? | | Fehlerumfang | Warum sind genau diese Systeme oder Benutzer betroffen? | | Zeitlicher Zusammenhang | Warum begann der Fehler zu diesem Zeitpunkt? | | Reproduzierbarkeit | Lässt sich das Verhalten kontrolliert wiederholen? | | Vergleich | Warum funktionieren nicht betroffene Systeme? | | Gegenprobe | Verschwindet das Symptom ohne die vermutete Ursache? | | Alternativen | Welche anderen Erklärungen wurden geprüft? | | Widersprüche | Gibt es Fakten, die nicht zur Ursache passen? | | Beweislage | Welche Logs, Messwerte oder Vergleiche bestätigen sie? | | Wiederholungsschutz | Welche Maßnahme verhindert ein erneutes Auftreten? | Wenn eine vermutete Ursache den Umfang oder den technischen Mechanismus nicht erklären kann, ist sie wahrscheinlich unvollständig. --- **8. Die Gegenfrage stellen** Eine besonders wichtige Frage lautet: > Was müsste beobachtet werden, wenn die vermutete Ursache nicht stimmt? **Beispiel** Hypothese: `Eine Firewall-Regel blockiert TCP 443 aus VLAN 30.` Mögliche Gegenbelege: - Pakete aus VLAN 30 erreichen den Server nachweislich. - Der Server sendet eine Antwort zurück. - Der Fehler tritt auch innerhalb des Servernetzes auf. - Ein lokaler Test auf dem Server schlägt ebenfalls fehl. - Die Firewall protokolliert eine erlaubte Verbindung. - Andere Dienste über denselben Netzwerkpfad sind ebenfalls betroffen. - Der Fehler besteht nach Rücknahme der Firewall-Regel weiter. Gegenbelege müssen genauso sorgfältig dokumentiert werden wie unterstützende Belege. --- **9. Kontrafaktische Prüfung** Eine kontrafaktische Prüfung untersucht, was ohne die vermutete Ursache geschehen würde. | Frage | Bedeutung | |---|---| | Wäre die Störung ohne diese Bedingung aufgetreten? | Prüft die Notwendigkeit der Ursache | | Existiert dieselbe Bedingung auf funktionierenden Systemen? | Prüft, ob sie allein ausreichend ist | | Verschwindet der Fehler, wenn die Bedingung entfernt wird? | Prüft den direkten Zusammenhang | | Erscheint der Fehler in einer Testumgebung erneut? | Prüft Reproduzierbarkeit | | Erklärt die Ursache auch die nicht betroffenen Systeme? | Prüft den Fehlerumfang | | Gibt es einen anderen Faktor mit derselben Wirkung? | Prüft alternative Erklärungen | Eine Bedingung kann notwendig, aber allein nicht ausreichend sein. Beispielsweise kann ein fehlerhaftes Backend erst zusammen mit einer fehlerhaften Load-Balancer-Konfiguration einen vollständigen Ausfall verursachen. --- **10. Ursachenbestätigung mit A/B-Vergleich** | Zustand A | Zustand B | Mögliche Interpretation | |---|---|---| | Betroffenes System | Funktionierendes System | Unterschiede priorisieren | | Fehlerhafte Konfiguration | Bekannte funktionierende Konfiguration | Konfigurationsunterschied prüfen | | Benutzer A gestört | Benutzer B funktioniert | Konto oder Berechtigung prüfen | | VLAN 30 gestört | VLAN 40 funktioniert | Netzwerkpfad oder ACL prüfen | | Backend 1 funktioniert | Backend 2 gestört | Backend-spezifische Ursache | | Anwendungsversion alt funktioniert | neue Version gestört | Versionsänderung priorisieren | | Proxy verwendet | direkter Test funktioniert | Proxy oder Proxyrichtlinie prüfen | | DNS-Auflösung verwendet | festes Ziel funktioniert | DNS oder Zielauswahl prüfen | Der Vergleich ist nur aussagekräftig, wenn alle nicht untersuchten Bedingungen möglichst gleich bleiben. --- **11. Betroffenes und funktionierendes System vergleichen** **Zu vergleichende Eigenschaften** | Bereich | Beispiele | |---|---| | Betriebssystem | Version, Build, Kernel | | Updates | Patchstand und Installationszeit | | Anwendung | Version, Module, Erweiterungen | | Konfiguration | Inhalt, Prüfsumme, Änderungszeit | | Dienste | Status, Starttyp, Dienstkonto | | Netzwerk | IP, VLAN, Gateway, DNS, Proxy | | Sicherheit | Firewallprofil, EDR, Zertifikate | | Benutzer | Gruppen, Rollen, Richtlinien | | Dateien | Version, Besitzer, Rechte, ACL | | Abhängigkeiten | Datenbank, API, Storage, DNS | | Umgebung | Variablen, Pfade, Laufzeitversion | | Ressourcen | CPU, RAM, Datenträger, Quota | --- **12. Dateien und Konfigurationen unter Windows vergleichen** **Dateiinhalte vergleichen** `[RO] Compare-Object (Get-Content "") (Get-Content "")` **SHA-256-Prüfsumme bilden** `[RO] Get-FileHash "" -Algorithm SHA256` **Dateiinformationen anzeigen** `[RO] Get-Item "" | Select-Object FullName, Length, CreationTime, LastWriteTime` **Versionsinformationen einer ausführbaren Datei** `[RO] (Get-Item "").VersionInfo` **Berechtigungen anzeigen** `[RO][SENSITIV] Get-Acl "" | Format-List` **Installierte Hotfixes vergleichen** `[RO] Get-HotFix | Sort-Object InstalledOn -Descending` --- **13. Dateien und Konfigurationen unter Linux vergleichen** **Dateien zeilenweise vergleichen** `[RO] diff -u "" ""` **SHA-256-Prüfsumme bilden** `[RO] sha256sum ""` **Dateiinformationen anzeigen** `[RO] stat ""` **Dateityp bestimmen** `[RO] file ""` **Berechtigungen und ACL anzeigen** `[RO][SENSITIV] getfacl ""` **Debian- oder Ubuntu-Paketversion** `[RO] dpkg-query -W ""` **RHEL-, Rocky-, AlmaLinux- oder Fedora-Paketversion** `[RO] rpm -q ""` --- **14. Dateien und Konfigurationen unter macOS vergleichen** **Dateien zeilenweise vergleichen** `[RO] diff -u "" ""` **SHA-256-Prüfsumme bilden** `[RO] shasum -a 256 ""` **Dateiinformationen anzeigen** `[RO] stat -x ""` **Dateityp bestimmen** `[RO] file ""` **Berechtigungen und ACL anzeigen** `[RO][SENSITIV] ls -lde ""` **Anwendungsversion über Systeminformationen suchen** `[RO] system_profiler SPApplicationsDataType` Bei umfangreichen Installationen kann `system_profiler SPApplicationsDataType` längere Zeit benötigen und eine große Ausgabe erzeugen. --- **15. Prüfsummen richtig interpretieren** | Ergebnis | Bedeutung | |---|---| | Prüfsummen identisch | Dateien sind zum Prüfzeitpunkt binär identisch | | Prüfsummen unterschiedlich | Mindestens ein Byte unterscheidet sich | | Dateiinhalt gleich, Metadaten anders | Besitzer, Rechte oder Zeitstempel können abweichen | | Anwendungsversion gleich, Prüfsumme anders | anderer Build, beschädigte Datei oder Modifikation möglich | | Prüfsumme gleich, Verhalten anders | Ursache liegt wahrscheinlich außerhalb der Datei | Eine identische Prüfsumme beweist nicht, dass die gesamte Umgebung identisch ist. --- **16. Dienstabhängigkeiten unter Windows prüfen** **Benötigte Dienste anzeigen** `[RO] Get-Service -Name -RequiredServices` **Abhängige Dienste anzeigen** `[RO] Get-Service -Name -DependentServices` **Dienstkonfiguration anzeigen** `[RO] sc.exe qc ` **Erweiterte Dienstinformationen** `[RO][SENSITIV] Get-CimInstance Win32_Service -Filter "Name=''" | Select-Object Name, State, StartMode, StartName, PathName, ProcessId` **Dienstereignisse anzeigen** `[RO] Get-WinEvent -FilterHashtable @{LogName="System"; ProviderName="Service Control Manager"; StartTime=(Get-Date).AddHours(-1)} | Select-Object TimeCreated, Id, Message` **Listener eines Dienstes prüfen** `[RO][PRIV] Get-NetTCPConnection -State Listen -LocalPort ` **Prozess zum Listener bestimmen** `[RO] Get-Process -Id ` --- **17. Dienstabhängigkeiten unter Linux prüfen** **Abhängigkeiten eines Dienstes anzeigen** `[RO] systemctl list-dependencies .service --all` **Dienste anzeigen, die vom untersuchten Dienst abhängen** `[RO] systemctl list-dependencies .service --reverse --all` **Deklarierte Abhängigkeiten und Reihenfolge** `[RO] systemctl show .service -p Requires -p Wants -p After -p Before` **Effektive Unit-Konfiguration anzeigen** `[RO] systemctl cat .service` **Dienstzustand anzeigen** `[RO] systemctl status .service --no-pager` **Dienstprotokoll anzeigen** `[RO] journalctl -u .service --since "1 hour ago" --no-pager` **Listener prüfen** `[RO][PRIV] ss -lntp | grep ":"` **Prozess untersuchen** `[RO] ps -p -o pid,ppid,user,lstart,stat,%cpu,%mem,command` --- **18. Dienstzustand unter macOS prüfen** macOS verwendet `launchd`. Die richtige Dienst-Domain hängt davon ab, ob es sich um einen System-, Benutzer- oder GUI-Dienst handelt. **Geladene Dienste anzeigen** `[RO] launchctl list` **Systemdienst untersuchen** `[RO][PRIV] launchctl print system/` **Benutzerdienst untersuchen** `[RO] launchctl print gui//` Die Benutzer-ID kann mit folgendem Befehl ermittelt werden: `[RO] id -u` **Property-List anzeigen** `[RO] plutil -p ""` **Listener prüfen** `[RO][PRIV] lsof -nP -iTCP: -sTCP:LISTEN` **Prozess untersuchen** `[RO] ps -p -o pid,ppid,user,lstart,state,%cpu,%mem,command` `launchd` bildet Abhängigkeiten nicht in derselben Weise wie systemd ab. Deshalb müssen zusätzlich verwendete Sockets, Dateien, Netzwerkziele und Anwendungsprotokolle geprüft werden. --- **19. Technische Abhängigkeiten vollständig betrachten** Ein sichtbarer Dienst kann von vielen weiteren Komponenten abhängen. | Komponente | Mögliche Abhängigkeit | |---|---| | Client | DNS, Proxy, Zertifikat, Richtlinie | | DNS | Zone, Forwarder, Netzwerk, Root-Server | | Webserver | Zertifikat, Dateisystem, Backend | | Reverse Proxy | Upstream, Health Check, DNS | | Anwendung | Datenbank, Cache, Queue, API | | Datenbank | Storage, Speicher, Replikation | | Authentifizierung | Active Directory, LDAP, RADIUS, MFA | | Zertifikat | CA, Zwischenzertifikat, Uhrzeit, Sperrprüfung | | Dateifreigabe | DNS, Kerberos, Berechtigung, Storage | | Container | Netzwerk, Volume, Secret, Image | | Virtuelle Maschine | Hypervisor, Datastore, virtuelles Netzwerk | | Cloud-Dienst | IAM, Sicherheitsgruppe, Region, Provider | | Backup | Agent, Repository, Netzwerk, Dienstkonto | | Monitoring | Agent, Collector, Zeit, Datenbank | --- **20. Abhängigkeitskette dokumentieren** **Beispiel: Anmeldung an einer Webanwendung** | Reihenfolge | Komponente | Erforderliche Funktion | |---:|---|---| | 1 | Client | Netzwerkverbindung vorhanden | | 2 | DNS | Hostname wird korrekt aufgelöst | | 3 | Firewall | TCP 443 wird erlaubt | | 4 | Load Balancer | funktionsfähiges Backend wird gewählt | | 5 | Webserver | TLS und HTTP funktionieren | | 6 | Anwendung | Anmeldeanfrage wird verarbeitet | | 7 | Identitätsdienst | Benutzer wird authentifiziert | | 8 | Datenbank | Benutzer- und Sitzungsdaten sind verfügbar | | 9 | Anwendung | Rolle wird geprüft | | 10 | Browser | Sitzungscookie wird gespeichert | Ein Fehler in einer späteren Abhängigkeit kann nach außen wie ein allgemeiner „Webserverfehler“ wirken. --- **21. Abhängigkeit gezielt umgehen oder isolieren** Eine Komponente kann für einen Test kontrolliert aus dem Pfad genommen werden. Dies darf keine dauerhafte oder unautorisierte Umgehung von Sicherheitskontrollen werden. **DNS für einen einzelnen curl-Test umgehen** `[TEST] curl --resolve "server.example:443:" -v https://server.example/` Dadurch bleiben Hostname, HTTP-Host-Header, SNI und Zertifikatsprüfung erhalten. **Proxy für einen einzelnen curl-Test umgehen** `[TEST] curl --noproxy "*" -v https://server.example/` > Das Umgehen eines Unternehmensproxys kann gegen Sicherheitsrichtlinien verstoßen. Der Test darf nur durchgeführt werden, wenn direkte Verbindungen erlaubt und ausdrücklich autorisiert sind. **Anwendungsebene gegen Transportebene** Windows: `[TEST] Test-NetConnection server.example -Port 443` Linux und macOS: `[TEST] nc -vz -w 3 server.example 443` Anschließend: `[TEST] curl -v https://server.example/` | TCP-Test | HTTP-Test | Wahrscheinlicher Bereich | |---|---|---| | erfolgreich | erfolgreich | grundlegender Dienstpfad funktioniert | | erfolgreich | fehlgeschlagen | TLS, HTTP, Anwendung oder Authentifizierung | | fehlgeschlagen | nicht möglich | Netzwerk, Firewall oder Listener | | wechselnd | wechselnd | Load Balancer, Backend oder instabiler Pfad | --- **22. Alternative Erklärungen bei typischen Beobachtungen** | Beobachtung | Mögliche alternative Erklärungen | |---|---| | Neustart löst Fehler | Cache, Speicherleck, Prozesszustand, Verbindung, Timing | | Dienstneustart löst Fehler | Abhängigkeit wurde neu verbunden, Port freigegeben, Konfiguration neu geladen | | DNS-Cache-Leerung löst Fehler | TTL wäre gleichzeitig abgelaufen, DNS-Eintrag wurde parallel geändert | | Firewall-Änderung löst Fehler | Stateful Session wurde erneuert, NAT oder Route änderte sich | | Update-Rollback löst Fehler | Rollback enthielt ebenfalls Neustart oder Konfigurationsrücksetzung | | Kabelwechsel löst Fehler | Port wurde neu ausgehandelt, Switchport oder DHCP-Lease änderte sich | | Anmeldung mit Testkonto funktioniert | Konto, Rolle, Profil, MFA oder Lizenz unterscheiden sich | | Zugriff über IP funktioniert | DNS möglich, aber HTTPS über IP wurde nicht vollständig geprüft | | Port ist offen | Anwendung kann intern trotzdem fehlerhaft sein | | Dienststatus ist „Running“ | Prozess kann hängen oder Abhängigkeit nicht erreichen | | Ein Test ist erfolgreich | sporadischer Fehler kann weiterhin bestehen | | Fehler verschwindet von selbst | Last, Lease, TTL, Token oder Providerzustand änderte sich | --- **23. Warum „Nach Maßnahme funktioniert es“ nicht immer genügt** Zwischen Maßnahme und erfolgreichem Test können weitere Veränderungen stattgefunden haben: - Cacheeintrag ist abgelaufen, - DHCP-Lease wurde erneuert, - DNS-Eintrag wurde repliziert, - Benutzerkonto wurde entsperrt, - Token wurde erneuert, - Providerstörung wurde behoben, - Failover ist erfolgt, - geplante Aufgabe wurde beendet, - Last ist zurückgegangen, - anderer Backend-Server wurde ausgewählt. Deshalb müssen Zeitpunkt, technische Wirkung und Kontrolltest zusammen betrachtet werden. --- **24. Gegenprobe durchführen** Eine Gegenprobe testet, ob das Ergebnis wirklich von der vermuteten Ursache abhängt. **Geeignete Gegenproben** - gleicher Test vor und nach der Korrektur, - betroffenes und funktionierendes System vergleichen, - Ursache in Testumgebung entfernen, - vorherige Konfiguration kontrolliert wiederherstellen, - bestimmtes Backend direkt testen, - Funktion mit und ohne Proxy vergleichen, - Funktion aus unterschiedlichen VLANs vergleichen, - Benutzer und Client getrennt wechseln. **Nicht geeignete Gegenprobe** Eine produktive Fehlkonfiguration wird absichtlich erneut aktiviert, obwohl dadurch ein weiterer Ausfall entstehen könnte. Eine erneute Fehlererzeugung gehört normalerweise in: - Testumgebung, - Staging, - Labor, - isolierte Kopie, - geplantes Wartungsfenster mit Freigabe. --- **25. Die Fünf-Warum-Methode vorsichtig einsetzen** Die Fünf-Warum-Methode fragt wiederholt nach dem technischen oder organisatorischen Grund eines Fehlers. **Beispiel** | Frage | Antwort | |---|---| | Warum war die Anwendung nicht erreichbar? | Der Dienst konnte nicht starten | | Warum konnte der Dienst nicht starten? | Die Konfigurationsdatei war ungültig | | Warum war die Konfigurationsdatei ungültig? | Ein Deployment setzte einen falschen Portwert | | Warum wurde der falsche Wert akzeptiert? | Es gab keine Schema-Validierung | | Warum fehlte die Validierung? | Sie war im Deploymentprozess nicht vorgesehen | **Mögliche Grundursache** `Der Deploymentprozess validiert Konfigurationswerte nicht vor der produktiven Bereitstellung.` **Mögliche Prävention** - Schema-Validierung, - automatisierter Konfigurationstest, - Staging, - schrittweiser Rollout, - automatische Rücknahme bei fehlgeschlagenem Health Check. --- **26. Grenzen der Fünf-Warum-Methode** Die Methode darf nicht dazu führen, dass eine komplexe Störung künstlich auf eine einzelne lineare Ursache reduziert wird. **Mögliche Probleme** - mehrere unabhängige Ursachen werden übersehen, - gewünschte Antwort wird durch die Fragestellung vorgegeben, - Untersuchung endet bei „menschlichem Fehler“, - technische und organisatorische Faktoren werden vermischt, - fehlende Belege werden durch Vermutungen ersetzt. Für komplexe Störungen ist eine Ursachenmatrix häufig besser. --- **27. Ursachenmatrix** | Faktor | Vorhanden | Notwendig | Allein ausreichend | Belegt | Bewertung | |---|---|---|---|---|---| | Falscher Datenbank-Hostname | Ja | Ja | Nein | Konfigurationsvergleich | Direkte Ursache | | Keine Konfigurationsvalidierung | Ja | Nein | Nein | Pipeline geprüft | Grundursache | | Gleichzeitiger Rollout | Ja | Nein | Nein | Deploymentprotokoll | Verstärkte Auswirkung | | Kein Ende-zu-Ende-Monitoring | Ja | Nein | Nein | Monitoringkonfiguration | Erkennungslücke | | Hohe Benutzerlast | Nein | Nein | Nein | Monitoring | Widerlegt | | Datenbankausfall | Nein | Nein | Nein | Datenbankmonitoring | Widerlegt | --- **28. Menschliche Handlung nicht automatisch als Grundursache verwenden** **Ungeeignet** `Der Administrator hat die falsche Adresse eingetragen.` Diese Aussage beendet die Untersuchung zu früh. **Weiterführende Fragen** - Warum konnte ein ungültiger Wert gespeichert werden? - Gab es eine technische Validierung? - War die Benutzeroberfläche eindeutig? - Wurde die Änderung automatisch geprüft? - Existierte ein Vier-Augen-Prinzip? - War die Dokumentation aktuell? - War ausreichend Zeit für die Änderung vorgesehen? - Konnte der Rollout schrittweise erfolgen? - Gab es eine automatische Rückfallmöglichkeit? - Warum erkannte das Monitoring den Fehler nicht? Eine sachliche Ursachenanalyse untersucht, wie Systeme und Prozesse verbessert werden können, statt einzelne Personen zu beschuldigen. --- **29. Bestätigungsgrade verwenden** | Grad | Bedeutung | |---|---| | Bestätigt | Direkter Mechanismus, mehrere Belege und Gegenprobe vorhanden | | Sehr wahrscheinlich | Mechanismus und mehrere Belege vorhanden, Gegenprobe nicht möglich | | Wahrscheinlich | Plausibel und teilweise belegt | | Möglich | Technisch denkbar, aber kaum belegt | | Unklar | Belege reichen nicht für eine Bewertung | | Unwahrscheinlich | Mehrere Fakten widersprechen | | Widerlegt | Definierte Vorhersage wurde durch Gegenbeleg widerlegt | Wenn eine Gegenprobe aus Sicherheits- oder Produktionsgründen nicht möglich ist, sollte die Ursache als „sehr wahrscheinlich“ und nicht automatisch als vollständig bestätigt dokumentiert werden. --- **30. Wann die Ursachensuche beendet werden kann** Die Untersuchung kann beendet oder in eine spätere Nachanalyse überführt werden, wenn: - der Dienst stabil wiederhergestellt ist, - der technische Mechanismus nachvollzogen wurde, - Umfang und Zeitpunkt erklärt sind, - alternative wahrscheinliche Ursachen geprüft wurden, - ausreichend starke Belege vorhanden sind, - verbleibende Unsicherheiten dokumentiert sind, - Präventionsmaßnahmen abgeleitet werden können, - weiteres Testen ein unverhältnismäßiges Risiko erzeugen würde. Eine Untersuchung sollte nicht endlos fortgeführt werden. Der notwendige Beweisgrad hängt von Auswirkung und Risiko der Störung ab. | Störung | Erforderlicher Beweisgrad | |---|---| | Einzelner unkritischer Arbeitsplatz | technische Plausibilität und dokumentierter Funktionstest | | Wiederkehrende Unternehmensstörung | mehrere Belege und Gegenprobe | | Kritischer Produktionsausfall | ausführliche Ursachenanalyse | | Datenverlust | hohe Beweissicherheit und Managementbeteiligung | | Sicherheitsvorfall | Incident Response und möglicherweise Forensik | | Rechtlich relevanter Vorfall | dokumentierte Beweismittelkette und Fachstellen | --- **31. Vollständiges Praxisbeispiel** **Störung** Seit 14:31 Uhr liefert `https://server.example` abwechselnd HTTP `200` und HTTP `503`. **Fehlerumfang** - alle Benutzer betroffen, - ungefähr jede zweite Anfrage schlägt fehl, - DNS liefert zwei Zieladressen, - TCP und TLS funktionieren zu beiden Adressen. **Hypothesen** | Nr. | Hypothese | |---:|---| | H1 | DNS liefert eine nicht vorgesehene IP-Adresse | | H2 | Eines der Backends ist fehlerhaft | | H3 | Load Balancer verteilt Anfragen falsch | | H4 | Datenbank ist vollständig ausgefallen | | H5 | Clientnetzwerk ist instabil | **Prüfungen** - Beide DNS-Adressen gehören zur vorgesehenen Umgebung. - Backend 1 liefert reproduzierbar HTTP `200`. - Backend 2 liefert reproduzierbar HTTP `503`. - Datenbankmonitoring zeigt keinen allgemeinen Ausfall. - Backend 2 protokolliert einen nicht auflösbaren Datenbank-Hostnamen. - Konfigurationsvergleich zeigt einen Tippfehler. - Der Tippfehler wurde mit dem Deployment um 14:31 Uhr eingeführt. - Die Pipeline akzeptierte den Wert ohne Prüfung. - Der Load Balancer markierte Backend 2 weiterhin als gesund, weil der Health Check nur eine statische Seite prüfte. **Bewertung der Hypothesen** | Hypothese | Bewertung | Begründung | |---|---|---| | H1 | Widerlegt | Beide DNS-Adressen sind vorgesehen | | H2 | Bestätigt | Fehler ist reproduzierbar an Backend 2 gebunden | | H3 | Teilweise bestätigt | Health Check erkennt den Backendfehler nicht | | H4 | Widerlegt | Datenbank und Backend 1 funktionieren | | H5 | Widerlegt | TCP- und TLS-Verbindungen sind stabil | **Ursachenkette** | Ebene | Feststellung | |---|---| | Symptom | ungefähr jede zweite Anfrage liefert HTTP 503 | | Direkte Ursache | Backend 2 erreicht die Datenbank nicht | | Technischer Fehler | falscher Datenbank-Hostname | | Auslöser | Deployment um 14:31 Uhr | | Grundursache | fehlende Validierung der Konfiguration | | Begünstigender Faktor | fehlerhafter Health Check | | Erkennungslücke | Monitoring prüft keine Datenbankfunktion | | Sofortmaßnahme | Backend 2 aus Rotation nehmen oder Konfiguration zurücksetzen | | Prävention | Validierung und anwendungsnahen Health Check einführen | --- **32. Dokumentationsvorlage für die Ursachenkette** | Feld | Eintrag | |---|---| | Ticketnummer | | | Symptom | | | Fehlerumfang | | | Beginn der Störung | | | Direkte technische Ursache | | | Technischer Mechanismus | | | Auslöser | | | Grundursache | | | Begünstigende Faktoren | | | Erkennungslücken | | | Wiederherstellungsfaktoren | | | Unterstützende Belege | | | Widersprechende Belege | | | Geprüfte Alternativen | | | Durchgeführte Gegenprobe | | | Bestätigungsgrad | | | Verbleibende Unsicherheiten | | | Sofortmaßnahme | | | Präventionsmaßnahme | | --- **33. Vorlage für alternative Erklärungen** | Nr. | Alternative Erklärung | Erwartete Beobachtung | Tatsächliche Beobachtung | Beleg | Status | |---:|---|---|---|---|---| | A1 | | | | | Offen | | A2 | | | | | Offen | | A3 | | | | | Offen | | A4 | | | | | Offen | --- **34. Prüffragen zur Grundursache** - Erklärt die Ursache alle beobachteten Symptome? - Erklärt sie, warum bestimmte Systeme nicht betroffen waren? - Erklärt sie den Beginn der Störung? - Ist der technische Mechanismus nachvollziehbar? - Gibt es direkte technische Belege? - Wurde die Ursache mit einem Vergleichssystem geprüft? - Wurde eine Gegenprobe durchgeführt? - Welche alternativen Erklärungen wurden ausgeschlossen? - Welche Beobachtungen widersprechen der Ursache? - Existiert dieselbe Bedingung auf funktionierenden Systemen? - Kann die Ursache in einer Testumgebung reproduziert werden? - Ist die genannte Ursache nur ein menschlicher Fehler? - Welche technische Schutzmaßnahme hätte den Fehler verhindert? - Welche Monitoringfunktion hätte den Fehler früher erkannt? - Sind mehrere Ursachen oder begünstigende Faktoren vorhanden? --- **Kurzcheckliste** - [ ] Symptom und Ursache getrennt - [ ] Direkte technische Ursache bestimmt - [ ] Technischen Mechanismus beschrieben - [ ] Auslöser bestimmt - [ ] Grundursache untersucht - [ ] Begünstigende Faktoren berücksichtigt - [ ] Erkennungslücken berücksichtigt - [ ] Abhängigkeiten geprüft - [ ] Betroffenes und funktionierendes System verglichen - [ ] Konfigurationsunterschiede geprüft - [ ] Datei- und Versionsunterschiede geprüft - [ ] Dienstabhängigkeiten geprüft - [ ] Unterstützende Belege dokumentiert - [ ] Widersprechende Belege dokumentiert - [ ] Alternative Erklärungen aufgestellt - [ ] Alternative Erklärungen geprüft - [ ] Gegenprobe durchgeführt oder begründet ausgelassen - [ ] Zeitliche Korrelation nicht mit Ursache verwechselt - [ ] Wiederherstellungsmaßnahme nicht automatisch als Ursache interpretiert - [ ] Mehrere mögliche Ursachen berücksichtigt - [ ] Menschliche Handlung nicht vorschnell als Grundursache verwendet - [ ] Bestätigungsgrad dokumentiert - [ ] Verbleibende Unsicherheiten dokumentiert - [ ] Präventionsmaßnahmen ableitbar --- **Ergebnis dieses Arbeitsschrittes** Am Ende dieses Schrittes liegt eine nachvollziehbare Ursachenkette vor. Sie unterscheidet: - sichtbares Symptom, - unmittelbare technische Ursache, - technischen Mechanismus, - auslösendes Ereignis, - Grundursache, - begünstigende Faktoren, - Erkennungslücken, - Wiederherstellungsmaßnahmen, - mögliche Präventionsmaßnahmen. Eine Ursache gilt nicht allein deshalb als bestätigt, weil der Fehler nach einer Änderung verschwunden ist. Sie muss zum Fehlerbild passen, durch technische Belege gestützt und gegen alternative Erklärungen geprüft worden sein. **Nächste Seite:** **1.8 Lösung umsetzen, Rückfallplan anwenden und Funktion verifizieren** --- **Offizielle Hersteller-, Standard- und Projektdokumentation** - [NIST – SP 800-61 Revision 3: Incident Response Recommendations and Considerations](https://csrc.nist.gov/pubs/sp/800/61/r3/final) - [Google SRE – Postmortem Culture](https://sre.google/sre-book/postmortem-culture/) - [Google SRE Workbook – Postmortem Practices](https://sre.google/workbook/postmortem-culture/) - [Microsoft Learn – Get-Service](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.management/get-service) - [Microsoft Learn – Compare-Object](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.utility/compare-object) - [Microsoft Learn – Get-FileHash](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.utility/get-filehash) - [Microsoft Learn – Get-WinEvent](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.diagnostics/get-winevent) - [freedesktop.org – systemctl](https://www.freedesktop.org/software/systemd/man/latest/systemctl.html) - [freedesktop.org – systemd-Unit-Abhängigkeiten](https://www.freedesktop.org/software/systemd/man/latest/systemd.unit.html) - [freedesktop.org – journalctl](https://www.freedesktop.org/software/systemd/man/latest/journalctl.html) - [curl – Offizielle Befehlsreferenz](https://curl.se/docs/manpage.html) - [Apple Support – Protokollmeldungen in der Konsole anzeigen](https://support.apple.com/guide/console/log-messages-cnsl1012/mac) # 1.8 Lösung umsetzen, Rückfallplan anwenden und Funktion verifizieren Nachdem die Ursache ausreichend bestätigt wurde, kann eine geeignete Lösung geplant und umgesetzt werden. Dabei gilt: > Eine Störung gilt nicht als behoben, nur weil eine Fehlermeldung verschwunden ist. Die ursprüngliche Funktion, ihre Abhängigkeiten und mögliche Nebenwirkungen müssen anschließend geprüft werden. Jede technische Korrektur ist selbst eine Änderung und kann neue Fehler verursachen. Deshalb benötigt auch eine scheinbar einfache Maßnahme einen definierten Ausgangszustand, Erfolgskriterien und einen Rückfallplan. --- **Ziel dieser Seite** Nach diesem Arbeitsschritt sollten: - Sofortmaßnahme und dauerhafte Lösung getrennt sein, - Ziel und Umfang der Änderung definiert sein, - Risiken und Abhängigkeiten bekannt sein, - Konfiguration oder Ausgangszustand gesichert sein, - ein überprüfbarer Rückfallplan vorliegen, - Erfolgskriterien und Abbruchkriterien definiert sein, - die Änderung möglichst schrittweise erfolgen, - technische Funktion und Benutzerfunktion geprüft sein, - Monitoring und Protokolle nach der Änderung kontrolliert sein, - bei Fehlschlag kontrolliert zurückgefallen werden können. --- **1. Kennzeichnung der Befehle** | Kennzeichnung | Bedeutung | |---|---| | `[RO]` | Read-only: liest Informationen aus | | `[TEST]` | Führt eine aktive Prüfung aus | | `[FILE]` | Erstellt oder überschreibt eine Datei | | `[PRIV]` | Benötigt möglicherweise Administrator- oder Root-Rechte | | `[CHANGE]` | Verändert Konfiguration oder Betriebszustand | | `[DISRUPTIV]` | Kann Benutzer oder produktive Dienste beeinträchtigen | | `[SENSITIV]` | Ausgabe kann vertrauliche Daten enthalten | --- **2. Maßnahmenarten unterscheiden** | Maßnahmenart | Zweck | Beispiel | |---|---|---| | Sofortmaßnahme | Auswirkungen schnell begrenzen | fehlerhaftes Backend aus dem Load Balancer nehmen | | Workaround | Fehler umgehen, ohne Ursache zu entfernen | Benutzer verwendet vorübergehend anderen Server | | Mitigation | Auswirkung oder Wahrscheinlichkeit reduzieren | Traffic auf funktionierende Instanzen begrenzen | | Reparatur | unmittelbaren technischen Fehler beseitigen | fehlerhafte Konfiguration korrigieren | | Dauerhafte Lösung | bestätigte Grundursache beseitigen | automatische Konfigurationsvalidierung einführen | | Präventionsmaßnahme | Wiederholung oder Auswirkung verhindern | Canary-Rollout und Monitoring ergänzen | | Rollback | vorherigen bekannten Zustand wiederherstellen | vorherige Anwendungsversion aktivieren | | Roll-forward | Fehler durch eine neue Korrektur beheben | korrigierte Folgeversion bereitstellen | Ein Workaround kann den Betrieb wiederherstellen, ohne die eigentliche Ursache zu beseitigen. Er muss deshalb als temporär gekennzeichnet und nachverfolgt werden. --- **3. Wiederherstellung und Ursachenbehebung unterscheiden** **Wiederherstellung** Ziel ist, die betroffene Funktion möglichst schnell wieder bereitzustellen. Beispiele: - Dienst neu starten, - fehlerhaftes Backend deaktivieren, - Failover auslösen, - vorherige Konfiguration wiederherstellen, - Ersatzgerät verwenden, - Benutzer auf ein anderes System umleiten. **Ursachenbehebung** Ziel ist, das erneute Auftreten zu verhindern. Beispiele: - Konfigurationsvalidierung ergänzen, - Speicherleck durch Softwarekorrektur beseitigen, - Monitoring erweitern, - fehlerhafte Automatisierung korrigieren, - Redundanz verbessern, - unklare Berechtigungsstruktur bereinigen. Eine Störung kann bereits wiederhergestellt sein, während die dauerhafte Ursachenbehebung noch offen ist. --- **4. Vor jeder Änderung zu klärende Fragen** - Was genau soll verändert werden? - Welche bestätigte Ursache wird damit behandelt? - Welches System und welche Komponente sind betroffen? - Welche Benutzer oder Dienste können beeinträchtigt werden? - Welche Abhängigkeiten bestehen? - Ist die Änderung dokumentiert und freigegeben? - Ist der aktuelle Zustand gesichert? - Existiert ein getesteter Rückfallweg? - Welche Erfolgskriterien gelten? - Welche Abbruchkriterien gelten? - Wie lange darf die Änderung dauern? - Wer führt die Änderung durch? - Wer beobachtet Monitoring und Protokolle? - Wer entscheidet über einen Rollback? - Wie werden betroffene Personen informiert? --- **5. Änderungsumfang möglichst klein halten** Eine Korrektur sollte nur die Komponente verändern, die für die bestätigte Ursache relevant ist. **Ungeeignet** - mehrere Firewall-Regeln gleichzeitig ändern, - Anwendung und Betriebssystem gleichzeitig aktualisieren, - Dienstkonto und Berechtigungen gleichzeitig verändern, - mehrere Backends gleichzeitig neu konfigurieren, - gleichzeitig DNS, Proxy und Routing anpassen. **Besser** 1. eine klar definierte Änderung, 2. definierter Funktionstest, 3. Beobachtung, 4. nächste Änderung nur bei Bedarf. Kleine Änderungen lassen sich leichter: - überprüfen, - zuordnen, - zurücknehmen, - dokumentieren, - auf Nebenwirkungen untersuchen. --- **6. Risiko der Änderung bewerten** | Risikofaktor | Niedriges Risiko | Hohes Risiko | |---|---|---| | Umfang | einzelner Testclient | gesamte Produktion | | Reversibilität | einfache Konfigurationsrücknahme | irreversible Datenmigration | | Verfügbarkeit | redundantes System | einzelner kritischer Server | | Erfahrung | dokumentierte Standardänderung | erstmalige unbekannte Änderung | | Abhängigkeiten | wenige bekannte Abhängigkeiten | viele unbekannte Abhängigkeiten | | Daten | keine Datenänderung | Schema- oder Datenänderung | | Zugang | lokaler Konsolenzugang | nur entfernte Verbindung | | Testbarkeit | funktionierende Testumgebung | nur Produktion verfügbar | | Beobachtung | vollständiges Monitoring | kaum Messwerte vorhanden | | Zeitdruck | geplantes Wartungsfenster | ungeplanter kritischer Ausfall | --- **7. Änderungsplan erstellen** | Feld | Eintrag | |---|---| | Ticket- oder Change-Nummer | | | bestätigte Ursache | | | geplante Änderung | | | technisches Ziel | | | betroffene Systeme | | | betroffene Benutzer | | | Abhängigkeiten | | | erwartete Unterbrechung | | | Risiko | Niedrig / Mittel / Hoch | | ausführende Person | | | beobachtende Person | | | Wartungsfenster | | | Sicherung des Ausgangszustands | | | Erfolgskriterien | | | Abbruchkriterien | | | Rückfallplan | | | Rückfallentscheidung durch | | | Kommunikationsweg | | | Beobachtungsdauer | | --- **8. Backup und Rollback unterscheiden** | Begriff | Bedeutung | |---|---| | Backup | Sicherung von Daten oder Konfiguration | | Restore | Wiederherstellung aus einem Backup | | Rollback | Rückkehr zum vorherigen bekannten Betriebszustand | | Snapshot | Momentaufnahme eines bestimmten Systems oder Datenträgers | | Export | Sicherung einer Konfiguration in einem unterstützten Format | | Roll-forward | Korrektur durch eine nachfolgende Version oder Änderung | Ein vorhandenes Backup ist noch kein vollständiger Rückfallplan. Ein Rückfallplan beantwortet zusätzlich: - Welche Sicherung wird verwendet? - Wie wird sie zurückgespielt? - Welche Dienste müssen vorher beendet werden? - Welche Abhängigkeiten sind betroffen? - Wie lange dauert die Wiederherstellung? - Wie wird der Erfolg des Rollbacks geprüft? - Was geschieht mit Daten, die nach der Änderung entstanden sind? - Wer darf den Rollback freigeben? - Was geschieht, wenn auch der Rollback fehlschlägt? --- **9. Grenzen von Snapshots beachten** Ein Snapshot ersetzt kein reguläres Backup und ist nicht für jede Anwendung als Rückfallmethode geeignet. Besondere Vorsicht gilt unter anderem bei: - Datenbanken, - Active Directory, - verteilten Dateisystemen, - Clustern, - Replikationssystemen, - Transaktionssystemen, - verschlüsselten Volumes, - Anwendungen mit externen Abhängigkeiten. Vor der Nutzung eines Snapshots muss geprüft werden: - Unterstützt der Hersteller diese Wiederherstellung? - Ist der Snapshot anwendungskonsistent? - Welche externen Systeme wurden seitdem verändert? - Entstehen Replikations- oder Transaktionsprobleme? - Gehen nach dem Snapshot erzeugte Daten verloren? - Existiert zusätzlich ein unabhängiges Backup? --- **10. Ausgangskonfiguration sichern** Für produktive Systeme sollte möglichst die vom Hersteller vorgesehene Export-, Backup- oder Versionsverwaltungsfunktion verwendet werden. Einfache Dateikopien sind nur für einzelne Konfigurationsdateien geeignet, wenn Berechtigungen, Besitzer, ACLs, erweiterte Attribute und Anwendungsanforderungen berücksichtigt werden. --- **Windows-Beispiel für eine einzelne Konfigurationsdatei** $backupFile = Join-Path "" "config-$(Get-Date -Format 'yyyyMMdd-HHmmss').bak" Copy-Item "" $backupFile Get-FileHash -Path "", $backupFile -Algorithm SHA256 Kennzeichnung: - `Copy-Item`: `[FILE]` - `Get-FileHash`: `[RO]` Die Prüfsummen sollten bei einer unveränderten Kopie identisch sein. --- **Linux-Beispiel für eine einzelne Konfigurationsdatei** backup_file="/config-$(date +%Y%m%d-%H%M%S).bak" cp --preserve=all -- "" "$backup_file" sha256sum "" "$backup_file" `cp --preserve=all` ist eine GNU-Option und steht nicht auf jedem Unix-System zur Verfügung. --- **macOS-Beispiel für eine einzelne Konfigurationsdatei** backup_file="/config-$(date +%Y%m%d-%H%M%S).bak" cp -p "" "$backup_file" shasum -a 256 "" "$backup_file" `cp -p` erhält wichtige Dateiattribute, garantiert aber nicht für jede Anwendung die vollständige Sicherung aller Metadaten. Für komplexe Anwendungen muss die vorgesehene Backupfunktion verwendet werden. --- **11. Konfiguration vor der Aktivierung validieren** Eine Konfigurationsdatei sollte möglichst vor einem Reload oder Neustart geprüft werden. **JSON unter Windows PowerShell prüfen** `[TEST] Get-Content "" -Raw | ConvertFrom-Json | Out-Null` Bei ungültigem JSON erzeugt PowerShell eine Fehlermeldung. **JSON unter Linux oder macOS mit Python prüfen** `[TEST] python3 -m json.tool "" > /dev/null` **JSON mit jq prüfen, sofern installiert** `[TEST] jq empty ""` **macOS-Property-List prüfen** `[TEST] plutil -lint ""` **systemd-Unit-Datei prüfen** `[TEST] systemd-analyze verify ""` **NGINX-Konfiguration prüfen** `[TEST][PRIV] nginx -t` **Apache-Konfiguration prüfen** `[TEST][PRIV] apachectl configtest` **OpenSSH-Serverkonfiguration prüfen** `[TEST][PRIV] sshd -t` > Die Werkzeuge prüfen unterschiedliche Aspekte. Ein erfolgreicher Syntax-Test bestätigt nicht automatisch, dass Netzwerkziele, Zugangsdaten, Zertifikate und abhängige Dienste funktionieren. --- **12. PowerShell-Änderung mit WhatIf vorprüfen** Einige PowerShell-Cmdlets unterstützen den allgemeinen Parameter `-WhatIf`. **Beispiel** `[TEST] Restart-Service -Name -WhatIf` PowerShell zeigt, welche Aktion vorgesehen ist, führt den Neustart aber nicht aus. **Wichtige Einschränkung** `-WhatIf`: - simuliert nicht die Anwendung selbst, - prüft nicht die spätere Funktionsfähigkeit, - erkennt nicht jede Abhängigkeit, - prüft nicht automatisch den Rückfallplan, - funktioniert nur bei Befehlen, die `-WhatIf` unterstützen. --- **13. Dienständerungen unter Windows** **Aktuellen Zustand prüfen** `[RO] Get-Service -Name ` **Abhängige Dienste prüfen** `[RO] Get-Service -Name -DependentServices` **Benötigte Dienste prüfen** `[RO] Get-Service -Name -RequiredServices` **Dienstkonfiguration prüfen** `[RO][SENSITIV] Get-CimInstance Win32_Service -Filter "Name=''" | Select-Object Name, State, StartMode, StartName, PathName, ProcessId` **Neustart zunächst anzeigen** `[TEST] Restart-Service -Name -WhatIf` **Dienst mit Bestätigungsabfrage neu starten** `[CHANGE][DISRUPTIV][PRIV] Restart-Service -Name -Confirm` **Gestoppten Dienst starten** `[CHANGE][PRIV] Start-Service -Name -Confirm` **Zustand danach prüfen** `[RO] Get-Service -Name ` > `Restart-Service` sendet eine Stopp- und anschließend eine Startanforderung. War der Dienst bereits gestoppt, versucht das Cmdlet ihn zu starten. Vorher müssen abhängige Dienste und Auswirkungen geprüft werden. --- **14. Dienständerungen unter Linux** **Aktuellen Zustand prüfen** `[RO] systemctl status .service --no-pager` **Zustand kompakt prüfen** `[RO] systemctl is-active .service` **Reload-Fähigkeit prüfen** `[RO] systemctl show .service -p CanReload -p ActiveState -p SubState -p MainPID` **Konfiguration neu laden** `[CHANGE][PRIV] sudo systemctl reload .service` Ein Reload funktioniert nur, wenn der Dienst diese Funktion unterstützt. **Dienst neu starten** `[CHANGE][DISRUPTIV][PRIV] sudo systemctl restart .service` **Nur dann neu starten, wenn der Dienst bereits läuft** `[CHANGE][DISRUPTIV][PRIV] sudo systemctl try-restart .service` **Zustand danach prüfen** `[RO] systemctl status .service --no-pager` **Neue Protokolle anzeigen** `[RO] journalctl -u .service --since "5 minutes ago" --no-pager` --- **15. Dienständerungen unter macOS** macOS verwendet `launchd`. Für die Befehle muss der richtige Dienstkontext bekannt sein. **Systemdienst prüfen** `[RO][PRIV] launchctl print system/` **Benutzerdienst prüfen** `[RO] launchctl print gui/$(id -u)/` **Systemdienst beenden und neu starten** `[CHANGE][DISRUPTIV][PRIV] sudo launchctl kickstart -k system/` **Benutzerdienst beenden und neu starten** `[CHANGE][DISRUPTIV] launchctl kickstart -k gui/$(id -u)/` Die Option `-k` beendet eine bereits laufende Instanz, bevor sie neu gestartet wird. **Protokolle danach prüfen** `[RO] log show --last 5m --predicate 'process == ""' --style compact` > Vor dem Einsatz muss die lokale Dokumentation mit `man launchctl` geprüft werden. System-, Benutzer- und GUI-Dienste verwenden unterschiedliche Domains. Ein falscher Dienstkontext kann dazu führen, dass nicht der erwartete Dienst angesprochen wird. --- **16. Reload, Restart und Reboot unterscheiden** | Maßnahme | Wirkung | Typisches Risiko | |---|---|---| | Reload | Konfiguration wird im laufenden Prozess neu geladen | Niedrig bis mittel | | Restart | Prozess wird beendet und neu gestartet | Mittel bis hoch | | Reboot | gesamtes Betriebssystem wird neu gestartet | Hoch | | Failover | Betrieb wechselt auf anderes System | Mittel bis hoch | | Rollback | vorheriger Zustand wird wiederhergestellt | Abhängig von Daten und Anwendung | **Sinnvolle Reihenfolge** 1. anwendungseigene Konfigurationsprüfung, 2. Reload, wenn unterstützt, 3. gezielter Dienstneustart, 4. Failover oder Rollback, 5. vollständiger Systemneustart nur mit technischer Begründung. Ein vollständiger Neustart sollte nicht als Standardlösung verwendet werden, wenn ein einzelner Dienst gezielt behandelt werden kann. --- **17. Änderungen schrittweise ausrollen** | Verfahren | Beschreibung | |---|---| | Einzelner Testclient | Änderung zunächst auf einem ausgewählten Client | | Einzelne Instanz | Änderung auf einem Server innerhalb einer redundanten Gruppe | | Canary | kleiner Anteil produktiver Systeme oder Anfragen | | Rolling Deployment | Instanzen werden nacheinander geändert | | Blue-Green | neue und alte Umgebung existieren parallel | | Staged Rollout | Änderung wird in definierten Stufen erweitert | | Wartungsgruppe | ausgewählte Benutzer oder Systeme werden zuerst umgestellt | **Beispiel für einen stufenweisen Rollout** 1. Testumgebung, 2. einzelne produktionsnahe Instanz, 3. ausgewählte Benutzer, 4. kleiner Produktionsanteil, 5. Monitoring auswerten, 6. weitere Instanzen, 7. vollständiger Rollout. Nach jeder Stufe muss ein Entscheidungspunkt bestehen: - fortsetzen, - beobachten, - stoppen, - zurückfallen. --- **18. Canary und Kontrollgruppe vergleichen** | Messwert | Kontrollgruppe | Canary | Bewertung | |---|---:|---:|---| | Fehlerrate | 0,5 % | 0,6 % | ähnlich | | Antwortzeit | 220 ms | 225 ms | ähnlich | | CPU-Auslastung | 42 % | 44 % | ähnlich | | HTTP 500 | 2 | 3 | beobachten | | erfolgreiche Anmeldungen | 99,5 % | 99,4 % | ähnlich | | neue Protokollfehler | 0 | 0 | unauffällig | Die Bewertung darf nicht nur auf dem Gesamtsystem erfolgen. Ein kleiner Canary kann in aggregierten Messwerten unsichtbar bleiben. Canary und Kontrollgruppe müssen getrennt ausgewertet werden. --- **19. Abbruchkriterien vor dem Rollout festlegen** Mögliche Abbruchkriterien: - Dienst startet nicht, - Health Check schlägt fehl, - Benutzerfunktion funktioniert nicht, - Fehlerquote steigt über den freigegebenen Grenzwert, - Antwortzeit verschlechtert sich erheblich, - Datenintegritätsfehler tritt auf, - unerwartete Systeme sind betroffen, - Administrationszugang geht verloren, - Monitoring meldet kritische Fehler, - Rückfallmöglichkeit ist nicht mehr gewährleistet, - Wartungsfenster wird überschritten. Schwellenwerte müssen aus SLA, SLO, Monitoring-Baseline oder dokumentierten Anforderungen stammen und dürfen nicht frei erfunden werden. --- **20. Technische Verifikation in mehreren Ebenen** | Ebene | Zu prüfende Frage | |---|---| | Prozess | Läuft der erwartete Prozess? | | Dienst | Meldet der Dienst einen gesunden Zustand? | | Listener | Lauscht der erwartete Port? | | Netzwerk | Ist das Ziel vom vorgesehenen Client erreichbar? | | TLS | Funktionieren Zertifikat und Handshake? | | Protokoll | Liefert der Dienst eine gültige Antwort? | | Authentifizierung | Kann sich der Benutzer anmelden? | | Autorisierung | Darf der Benutzer die vorgesehene Funktion verwenden? | | Anwendung | Funktioniert die konkrete Aktion? | | Daten | Werden Daten korrekt gelesen und geschrieben? | | Abhängigkeiten | Funktionieren Datenbank, Storage, DNS und APIs? | | Monitoring | Wird das System korrekt als gesund erkannt? | | Protokolle | Entstehen keine neuen relevanten Fehler? | | Redundanz | Sind verbleibende Instanzen und Failover weiterhin verfügbar? | --- **21. Windows-Verifikation** **Dienststatus** `[RO] Get-Service -Name ` **Prozess-ID des Dienstes** `[RO] Get-CimInstance Win32_Service -Filter "Name=''" | Select-Object Name, State, ProcessId` **TCP-Listener** `[RO][PRIV] Get-NetTCPConnection -State Listen -LocalPort ` **Remote-Porttest** `[TEST] Test-NetConnection -Port -InformationLevel Detailed` **HTTP- oder HTTPS-Test** `[TEST] curl.exe -sS -o NUL -w "HTTP=%{http_code} Ziel=%{remote_ip} Gesamt=%{time_total}\n" --connect-timeout 5 --max-time 15 https:///` **Neue Systemereignisse** `[RO] Get-WinEvent -FilterHashtable @{LogName="System"; StartTime=(Get-Date).AddMinutes(-10)} | Select-Object TimeCreated, Id, ProviderName, LevelDisplayName, Message` **Neue Anwendungsereignisse** `[RO] Get-WinEvent -FilterHashtable @{LogName="Application"; StartTime=(Get-Date).AddMinutes(-10)} | Select-Object TimeCreated, Id, ProviderName, LevelDisplayName, Message` --- **22. Linux-Verifikation** **Dienststatus** `[RO] systemctl status .service --no-pager` **Nur aktiven Zustand abfragen** `[RO] systemctl is-active .service` **Hauptprozess-ID** `[RO] systemctl show .service -p MainPID` **TCP-Listener** `[RO][PRIV] ss -lntp | grep ":"` **Remote-Porttest** `[TEST] nc -vz -w 3 ` **HTTP- oder HTTPS-Test** `[TEST] curl -sS -o /dev/null -w "HTTP=%{http_code} Ziel=%{remote_ip} Gesamt=%{time_total}\n" --connect-timeout 5 --max-time 15 https:///` **Neue Dienstprotokolle** `[RO] journalctl -u .service --since "10 minutes ago" --no-pager` **Neue Fehler des Systems** `[RO] journalctl --since "10 minutes ago" -p err --no-pager` --- **23. macOS-Verifikation** **Systemdienststatus** `[RO][PRIV] launchctl print system/` **Benutzerdienststatus** `[RO] launchctl print gui/$(id -u)/` **TCP-Listener** `[RO][PRIV] lsof -nP -iTCP: -sTCP:LISTEN` **Remote-Porttest** `[TEST] nc -vz -w 3 ` **HTTP- oder HTTPS-Test** `[TEST] curl -sS -o /dev/null -w "HTTP=%{http_code} Ziel=%{remote_ip} Gesamt=%{time_total}\n" --connect-timeout 5 --max-time 15 https:///` **Neue Prozessprotokolle** `[RO] log show --last 10m --predicate 'process == ""' --style compact` **Neue Fehler und Faults** `[RO] log show --last 10m --predicate 'messageType == error OR messageType == fault' --style compact` --- **24. Ursprüngliche Benutzerfunktion prüfen** Eine technische Verifikation reicht nicht aus. Abschließend muss die ursprünglich gestörte Funktion getestet werden. **Beispiele** - Benutzer kann sich anmelden, - Datei kann geöffnet werden, - Datei kann gespeichert werden, - E-Mail kann gesendet und empfangen werden, - Druckauftrag wird vollständig ausgegeben, - VPN-Verbindung wird aufgebaut, - Anwendung kann Datenbankdaten lesen, - Anwendung kann Daten speichern, - Backupjob endet erfolgreich, - Client erhält korrekte DHCP-Optionen, - Gruppenrichtlinie wird angewendet, - API liefert erwartete Daten. Der Test sollte möglichst: - vom ursprünglichen Quellsystem, - mit dem ursprünglichen Benutzerkontext, - über denselben Netzwerkpfad, - mit derselben Zieladresse, - mit derselben Aktion durchgeführt werden. --- **25. Positive und negative Tests durchführen** **Positiver Test** Prüft, ob eine erlaubte Funktion erfolgreich ist. Beispiel: `Ein berechtigter Benutzer kann eine Datei lesen.` **Negativer Test** Prüft, ob eine nicht erlaubte Funktion weiterhin verhindert wird. Beispiel: `Ein unberechtigter Benutzer kann die Datei weiterhin nicht lesen.` **Weitere negative Tests** - geschlossener Port bleibt geschlossen, - nicht autorisierter Benutzer bleibt abgewiesen, - deaktiviertes Konto kann sich nicht anmelden, - abgelaufenes Token wird nicht akzeptiert, - unerlaubtes VLAN erhält keinen Zugriff, - alte verwundbare Schnittstelle bleibt deaktiviert. Eine Lösung ist fehlerhaft, wenn sie die Funktion wiederherstellt, dabei aber Sicherheitskontrollen unbeabsichtigt entfernt. --- **26. Regressionstests durchführen** Ein Regressionstest prüft, ob bisher funktionierende Bereiche nach der Änderung weiterhin funktionieren. | Geänderte Komponente | Mögliche Regressionstests | |---|---| | Firewall | andere erlaubte und gesperrte Verbindungen | | DNS | interne und externe Namensauflösung | | DHCP | neue und bestehende Clients | | Webserver | Anmeldung, Upload, Download, API | | Datenbank | Lesen, Schreiben, Replikation, Backup | | Dateiserver | Lesen, Schreiben, ACL, Freigaben | | Active Directory | Anmeldung, Gruppenrichtlinie, Replikation | | Proxy | erlaubte Seiten, Ausnahmen, Authentifizierung | | Zertifikat | Browser, API, mobile Clients, alte Clients | | Load Balancer | alle Backends, Health Checks, Sitzungen | | Backup | Sicherung und testweise Wiederherstellung | --- **27. Persistenz der Lösung prüfen** Manche Korrekturen funktionieren nur bis zum nächsten: - Neustart, - Dienstneustart, - DHCP-Lease-Wechsel, - Gruppenrichtlinien-Refresh, - Konfigurationsdeployment, - Container-Neustart, - Failover, - Update, - Passwort- oder Zertifikatswechsel. Zu prüfen ist: - Wurde die richtige permanente Konfiguration geändert? - Wird die Datei durch Automatisierung überschrieben? - Stammt die Konfiguration aus einer zentralen Quelle? - Ist die Änderung in Versionsverwaltung übernommen? - Muss ein Deploymenttemplate angepasst werden? - Existieren mehrere Konfigurationskopien? - Wird beim Neustart eine alte Konfiguration geladen? Ein Neustart zur Persistenzprüfung darf nur geplant durchgeführt werden, wenn er technisch erforderlich und freigegeben ist. --- **28. Monitoring nach der Änderung** Nach einer erfolgreichen Funktionsprüfung muss das System weiter beobachtet werden. **Zu beobachtende Werte** - Verfügbarkeit, - Fehlerquote, - Antwortzeit, - CPU-Auslastung, - Speichernutzung, - Datenträgerbelegung, - I/O-Wartezeit, - Netzwerkfehler, - Verbindungsanzahl, - Warteschlangen, - Datenbankverbindungen, - Replikationszustand, - Zertifikatsfehler, - Anmeldefehler, - Benutzerbeschwerden. Die Beobachtungsdauer richtet sich nach dem Fehlerbild. | Fehlerart | Geeignete Beobachtung | |---|---| | dauerhafter Startfehler | unmittelbare Tests nach Start | | sporadischer Fehler | mehrere typische Nutzungszyklen | | nächtlicher Job | mindestens nächster geplanter Lauf | | DHCP-Problem | mindestens ein Lease-Erneuerungszyklus | | Backupfehler | vollständiger Sicherungs- und Prüfzyklus | | Lastproblem | typischer Lastzeitraum | | Zertifikatserneuerung | vollständige Kette und betroffene Clients | | Replikationsproblem | vorgesehener Replikationszyklus | --- **29. Rollback-Auslöser** Ein Rollback sollte ausgelöst werden, wenn: - definiertes Erfolgskriterium nicht erreicht wird, - ursprünglicher Fehler bestehen bleibt, - neue kritische Fehler entstehen, - unerwartete Systeme betroffen sind, - Sicherheitskontrolle nicht mehr funktioniert, - Datenintegrität gefährdet ist, - Administrationszugang verloren zu gehen droht, - Abbruchkriterium erreicht wird, - Wartungsfenster überschritten wird, - weitere sichere Diagnose nicht möglich ist. Die Entscheidung darf nicht erst improvisiert werden, nachdem ein Problem entstanden ist. --- **30. Kontrollierter Rollback-Ablauf** 1. weiteren Rollout stoppen, 2. zuständige Personen informieren, 3. aktuellen Fehlerzustand sichern, 4. Rückfallentscheidung dokumentieren, 5. freigegebenen Rückfallplan ausführen, 6. Dienst- und Systemstatus prüfen, 7. ursprüngliche Funktion testen, 8. negative Tests durchführen, 9. Protokolle und Monitoring kontrollieren, 10. Ergebnis dokumentieren, 11. weitere Untersuchung planen. > Auch ein Rollback ist eine Änderung und kann fehlschlagen. --- **31. Rollback oder Roll-forward wählen** | Situation | Rollback eher geeignet | Roll-forward eher geeignet | |---|---|---| | vorherige Version bekannt funktionsfähig | Ja | Möglich | | Konfiguration einfach reversibel | Ja | Möglich | | Datenbankschema bereits verändert | Riskant | Häufig besser | | neue Daten nicht rückwärtskompatibel | Riskant | Häufig besser | | kritische Sicherheitslücke würde wieder geöffnet | Eher ungeeignet | Besser | | Fehlerkorrektur ist klein und geprüft | Möglich | Häufig besser | | vorheriger Zustand nicht eindeutig | Riskant | Möglicherweise besser | | Rollback bereits getestet | Ja | Nicht zwingend | | Zeit bis zur Folgekorrektur sehr lang | Häufig besser | Eher ungeeignet | | Produktionsauswirkung steigt schnell | schneller sicherer Weg entscheidend | schneller sicherer Weg entscheidend | Ein Rollback darf keine bekannte Sicherheitslücke oder Dateninkonsistenz unbewertet wieder einführen. --- **32. Rollback einfacher Konfigurationsdateien** Eine Konfigurationsdatei darf nur dann direkt zurückkopiert werden, wenn: - die Sicherung eindeutig zugeordnet ist, - die Prüfsumme geprüft wurde, - keine neuen relevanten Änderungen verloren gehen, - Dateibesitzer und Berechtigungen bekannt sind, - keine Datenmigration betroffen ist, - die Anwendung dieses Verfahren unterstützt, - der Dienst anschließend korrekt validiert werden kann. **Windows-Beispiel** `[CHANGE][PRIV] Copy-Item "" "" -Force` **Linux-Beispiel** `[CHANGE][PRIV] sudo cp --preserve=all -- "" ""` **macOS-Beispiel** `[CHANGE][PRIV] sudo cp -p "" ""` > Diese Befehle sind keine universelle Rollbacklösung. Datenbanken, Verzeichnisdienste, Cluster, Containerplattformen und komplexe Anwendungen benötigen die vom Hersteller vorgesehene Wiederherstellungsmethode. Nach dem Zurückkopieren müssen mindestens geprüft werden: - Inhalt, - Prüfsumme, - Besitzer, - Gruppe, - Berechtigungen, - ACL, - Syntax, - Dienststart, - Funktion. --- **33. Kommunikation während der Umsetzung** | Zeitpunkt | Information | |---|---| | Vor Beginn | Umfang, erwartete Auswirkung und Zeitraum | | Zu Beginn | Änderung wurde gestartet | | Währenddessen | relevante Abweichungen oder Verzögerungen | | Bei Abbruch | Grund und eingeleitete Rückfallmaßnahme | | Nach Erfolg | Funktion wiederhergestellt und Beobachtung läuft | | Nach Rollback | vorheriger Zustand wiederhergestellt | | Nach Abschluss | Ergebnis, offene Punkte und Präventionsmaßnahmen | Technische Kommunikation sollte sachlich sein und zwischen folgenden Zuständen unterscheiden: - Störung erkannt, - Ursache vermutet, - Ursache bestätigt, - Workaround aktiv, - Dienst wiederhergestellt, - dauerhafte Lösung umgesetzt, - Beobachtung läuft, - Störung abgeschlossen. --- **34. Vollständiges Praxisbeispiel** **Störung** Ein Backend liefert HTTP `503`, weil die Anwendung einen falschen Datenbank-Hostnamen verwendet. **Bestätigte Ursache** Die neue Konfigurationsdatei enthält `db-prdo.example` statt `db-prod.example`. **Geplante Lösung** - Konfiguration korrigieren, - Syntax validieren, - Änderung zunächst auf einem Backend anwenden, - Dienst neu laden oder neu starten, - technische und fachliche Funktion prüfen, - danach weitere Instanzen ändern. **Rückfallplan** - gesicherte vorherige Konfiguration zurückspielen, - Dienst erneut starten, - Backend aus Load-Balancer-Rotation entfernen, falls es weiterhin fehlerhaft ist. **Erfolgskriterien** - Dienststatus aktiv, - TCP-Listener vorhanden, - Datenbankverbindung erfolgreich, - HTTP-Health-Check erfolgreich, - Anmeldung funktioniert, - keine neuen Fehler im Protokoll, - Fehlerrate entspricht der Kontrollgruppe. **Abbruchkriterien** - Dienst startet nicht, - Datenbankverbindung bleibt gestört, - neue Fehler treten auf, - Antwortzeit verschlechtert sich deutlich, - Benutzerfunktion schlägt fehl. **Ablauf** | Schritt | Maßnahme | |---:|---| | 1 | Ausgangszustand und Protokolle sichern | | 2 | aktuelle Konfiguration sichern und Prüfsumme bilden | | 3 | korrigierte Datei in Testumgebung validieren | | 4 | ein Backend aus der Rotation nehmen | | 5 | Konfiguration auf diesem Backend ändern | | 6 | Konfigurationsprüfung ausführen | | 7 | Dienst kontrolliert neu laden oder starten | | 8 | Listener und Protokolle prüfen | | 9 | Datenbankfunktion prüfen | | 10 | HTTP- und Anmeldetest durchführen | | 11 | Backend mit Kontrollgruppe vergleichen | | 12 | Backend wieder in Rotation nehmen | | 13 | Monitoring beobachten | | 14 | Änderung schrittweise auf weitere Instanzen ausrollen | --- **35. Verifikationsprotokoll** | Feld | Vor Änderung | Nach Änderung | Nach Beobachtung | |---|---|---|---| | Zeitpunkt | | | | | Dienststatus | | | | | Prozess-ID | | | | | Listener | | | | | Ziel-IP | | | | | HTTP-Status | | | | | Antwortzeit | | | | | Authentifizierung | | | | | Benutzerfunktion | | | | | Datenbankverbindung | | | | | Fehler im Protokoll | | | | | Monitoringstatus | | | | | Fehlerrate | | | | | Nebenwirkungen | | | | --- **36. Änderungs- und Rollbackprotokoll** | Feld | Eintrag | |---|---| | Ticket- oder Change-Nummer | | | bestätigte Ursache | | | umgesetzte Änderung | | | Beginn | | | Ende | | | ausführende Person | | | betroffene Systeme | | | Sicherungsdatei oder Backup | | | Prüfsumme | | | Konfigurationsprüfung | Bestanden / Nicht bestanden | | Dienstneustart erforderlich | Ja / Nein | | Erfolgskriterien erreicht | Ja / Nein / Teilweise | | Abbruchkriterium erreicht | Ja / Nein | | Rollback durchgeführt | Ja / Nein | | Rollback-Ergebnis | | | Benutzerfunktion geprüft | Ja / Nein | | Regressionstests durchgeführt | | | Beobachtungsdauer | | | neue Fehler | | | verbleibende Risiken | | | offene Maßnahmen | | --- **37. Häufige Fehler bei der Lösungsumsetzung** | Fehler | Folge | Besseres Vorgehen | |---|---|---| | Keine Sicherung | Ausgangszustand kann nicht wiederhergestellt werden | Konfiguration oder Backup vorher sichern | | Backup mit Rollback verwechselt | Wiederherstellung ist nicht geplant | vollständigen Rückfallablauf dokumentieren | | Mehrere Änderungen gleichzeitig | Wirkung nicht zuordenbar | kleine einzelne Änderungen | | Sofortiger vollständiger Rollout | großer möglicher Ausfall | Canary oder stufenweiser Rollout | | Nur Dienststatus geprüft | Benutzerfunktion kann weiterhin gestört sein | Ende-zu-Ende-Test durchführen | | Nur positiver Test | Sicherheitskontrolle kann unbemerkt fehlen | negativen Test ergänzen | | Keine Abbruchkriterien | zu lange an fehlerhafter Änderung festgehalten | Grenzwerte vorher definieren | | Rollback erst im Fehlerfall geplant | zusätzliche Ausfallzeit | Rollback vor Beginn vorbereiten | | Snapshot als einziges Backup | Wiederherstellung möglicherweise ungeeignet | anwendungsgerechtes Backup verwenden | | Neustart als Standardlösung | unnötige Unterbrechung und Informationsverlust | kleinste geeignete Maßnahme wählen | | Monitoring sofort beendet | sporadischer Fehler bleibt unentdeckt | angemessene Beobachtungsdauer | | Workaround als dauerhafte Lösung behandelt | Grundursache bleibt bestehen | Folgeaufgabe mit Verantwortlichkeit | | Sicherheitsupdate zurückgenommen | bekannte Schwachstelle erneut aktiv | Sicherheitsrisiko bewerten und Roll-forward prüfen | | Dokumentation erst später erstellt | genaue Schritte und Zeiten gehen verloren | während der Änderung dokumentieren | --- **Kurzcheckliste** - [ ] Ursache ausreichend bestätigt - [ ] Sofortmaßnahme und dauerhafte Lösung getrennt - [ ] Änderungsumfang eindeutig definiert - [ ] Auswirkungen und Abhängigkeiten geprüft - [ ] Risiko bewertet - [ ] Freigabe eingeholt - [ ] Wartungsfenster geklärt - [ ] Ausgangszustand dokumentiert - [ ] Konfiguration oder Daten gesichert - [ ] Prüfsummen dokumentiert - [ ] Rückfallplan vorhanden - [ ] Rückfallplan technisch durchführbar - [ ] Erfolgskriterien festgelegt - [ ] Abbruchkriterien festgelegt - [ ] Monitoring vorbereitet - [ ] Kommunikation vorbereitet - [ ] Konfiguration vor Aktivierung validiert - [ ] Änderung möglichst klein gehalten - [ ] Änderung zunächst begrenzt ausgerollt - [ ] Dienststatus geprüft - [ ] Prozess und Listener geprüft - [ ] Netzwerk- und Protokolltest durchgeführt - [ ] ursprüngliche Benutzerfunktion geprüft - [ ] negative Sicherheitstests durchgeführt - [ ] Regressionstests durchgeführt - [ ] Protokolle nach der Änderung geprüft - [ ] Monitoring nach der Änderung beobachtet - [ ] Persistenz der Lösung berücksichtigt - [ ] Rollback bei Erreichen eines Abbruchkriteriums durchgeführt - [ ] Ergebnis und offene Maßnahmen dokumentiert --- **Ergebnis dieses Arbeitsschrittes** Am Ende dieses Schrittes ist die bestätigte Ursache durch eine kontrollierte und dokumentierte Änderung behandelt. Die Lösung gilt erst als erfolgreich, wenn: - technische Prüfungen bestanden sind, - die ursprüngliche Benutzerfunktion funktioniert, - abhängige Funktionen weiterhin funktionieren, - Sicherheitskontrollen weiterhin wirksam sind, - keine neuen relevanten Fehler auftreten, - Monitoring einen stabilen Zustand zeigt, - die Änderung dauerhaft bestehen bleibt, - Rückfall- oder Folgemaßnahmen dokumentiert sind. **Nächste Seite:** **1.9 Störung dokumentieren, abschließen und Wiederholung verhindern** --- **Offizielle Hersteller-, Standard- und Projektdokumentation** - [Microsoft Learn – Restart-Service](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.management/restart-service) - [Microsoft Learn – Start-Service](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.management/start-service) - [Microsoft Learn – Stop-Service](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.management/stop-service) - [Microsoft Learn – Get-Service](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.management/get-service) - [Microsoft Learn – Test-NetConnection](https://learn.microsoft.com/en-us/powershell/module/nettcpip/test-netconnection) - [Microsoft Learn – Get-WinEvent](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.diagnostics/get-winevent) - [Microsoft Learn – Get-FileHash](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.utility/get-filehash) - [freedesktop.org – systemctl](https://www.freedesktop.org/software/systemd/man/latest/systemctl.html) - [freedesktop.org – systemd-analyze](https://www.freedesktop.org/software/systemd/man/latest/systemd-analyze.html) - [freedesktop.org – journalctl](https://www.freedesktop.org/software/systemd/man/latest/journalctl.html) - [Google SRE Workbook – Canarying Releases](https://sre.google/workbook/canarying-releases/) - [Google SRE Workbook – Configuration Design and Best Practices](https://sre.google/workbook/configuration-design/) - [Apple Support – Scriptverwaltung mit launchd](https://support.apple.com/guide/terminal/script-management-with-launchd-apdc6c1077b/mac) - [curl – Offizielle Befehlsreferenz](https://curl.se/docs/manpage.html) # 1.9 Störung dokumentieren, abschließen und Wiederholung verhindern Eine Störung ist nicht allein deshalb abgeschlossen, weil die betroffene Funktion wieder verfügbar ist. Ein vollständiger Abschluss beantwortet zusätzlich: - Was ist passiert? - Welche Systeme und Benutzer waren betroffen? - Wann begann und endete die Störung? - Was war die bestätigte Ursache? - Welche Maßnahme stellte die Funktion wieder her? - Wurde nur ein Workaround oder eine dauerhafte Lösung umgesetzt? - Welche Risiken und offenen Aufgaben bleiben bestehen? - Wie wird eine Wiederholung verhindert oder schneller erkannt? Dabei gilt: > Eine gute Störungsdokumentation ermöglicht einer anderen Person, den Ablauf, die Ursache, die Prüfungen und die Lösung ohne mündliche Zusatzinformationen nachzuvollziehen. --- **Ziel dieser Seite** Nach diesem Arbeitsschritt sollten: - Wiederherstellung und dauerhafte Lösung dokumentiert sein, - eine nachvollziehbare Zeitachse vorliegen, - Ursache, Auslöser und begünstigende Faktoren getrennt sein, - technische Belege und Testergebnisse zugeordnet sein, - Auswirkungen auf Benutzer und Betrieb dokumentiert sein, - verbleibende Risiken bekannt sein, - offene Maßnahmen eine verantwortliche Person besitzen, - Monitoring, Dokumentation und Notfallabläufe aktualisiert sein, - der Abschlussstatus eindeutig sein, - Wissen für zukünftige Störungen erhalten bleiben. --- **1. Kennzeichnung der Befehle** | Kennzeichnung | Bedeutung | |---|---| | `[RO]` | Read-only: liest Informationen aus | | `[TEST]` | Führt eine aktive Prüfung aus | | `[FILE]` | Erstellt oder überschreibt eine Datei | | `[PRIV]` | Benötigt möglicherweise Administrator- oder Root-Rechte | | `[CHANGE]` | Verändert Konfiguration oder Betriebszustand | | `[SENSITIV]` | Ausgabe kann vertrauliche Daten enthalten | --- **2. Wiederhergestellt, gelöst und abgeschlossen unterscheiden** | Status | Bedeutung | |---|---| | Erkannt | Störung wurde registriert | | In Analyse | Ursache wird untersucht | | Workaround aktiv | Funktion ist über einen vorläufigen Umweg verfügbar | | Wiederhergestellt | ursprüngliche Funktion ist wieder verfügbar | | Unter Beobachtung | Funktion läuft, Stabilität wird überwacht | | Technisch gelöst | bestätigte technische Ursache wurde beseitigt | | Dauerhaft gelöst | zusätzlich wurden erforderliche Präventionsmaßnahmen umgesetzt | | Abgeschlossen | Dokumentation, Übergabe und offene Maßnahmen sind vollständig | | Wiedereröffnet | Fehler trat erneut auf oder Abschlusskriterien waren nicht erfüllt | Ein Ticket sollte nicht als „dauerhaft gelöst“ bezeichnet werden, wenn lediglich ein Workaround aktiv ist. --- **3. Incident, Problem und Änderung unterscheiden** | Element | Hauptziel | Beispiel | |---|---|---| | Störung oder Incident | Betrieb schnell wiederherstellen | Webanwendung wieder erreichbar machen | | Problem oder Ursachenanalyse | Grundursache und Wiederholungsrisiko untersuchen | Ursache des wiederkehrenden Ausfalls bestimmen | | Änderung oder Change | kontrollierte technische Anpassung durchführen | Konfigurationsvalidierung einführen | | Wissenseintrag | Wiederverwendbare Lösung dokumentieren | Fehlerbild und Diagnosebefehle dokumentieren | | Präventionsaufgabe | Wiederholung oder Auswirkung verhindern | Monitoring um Ende-zu-Ende-Test ergänzen | Ein einzelner Vorfall kann mehrere verknüpfte Einträge benötigen. --- **4. Abschlusskriterien festlegen** Eine Störung kann abgeschlossen werden, wenn mindestens folgende Punkte geklärt sind: - ursprüngliche Benutzerfunktion funktioniert, - technischer Funktionstest wurde bestanden, - relevante Regressionstests wurden durchgeführt, - Sicherheitskontrollen funktionieren weiterhin, - Monitoring zeigt einen stabilen Zustand, - keine neuen relevanten Fehler treten auf, - betroffene Personen wurden informiert, - Ursache oder Unsicherheit ist dokumentiert, - Workaround oder Lösung ist eindeutig gekennzeichnet, - Rückfallstatus ist dokumentiert, - Belege und Ausgaben sind zugeordnet, - offene Maßnahmen besitzen Verantwortliche und Termine, - verbleibende Risiken wurden akzeptiert oder weitergegeben. --- **5. Abschlussentscheidung** | Frage | Ja | Nein | |---|---:|---:| | Funktioniert die ursprüngliche Benutzeraktion? | | | | Ist der technische Systemzustand stabil? | | | | Sind Abhängigkeiten geprüft? | | | | Sind negative Sicherheitstests bestanden? | | | | Sind relevante Regressionstests bestanden? | | | | Ist das Monitoring unauffällig? | | | | Sind Protokolle nach der Lösung geprüft? | | | | Ist die Ursache ausreichend dokumentiert? | | | | Ist klar, ob es sich um Workaround oder Lösung handelt? | | | | Sind offene Aufgaben zugewiesen? | | | | Sind verbleibende Risiken dokumentiert? | | | | Sind betroffene Personen informiert? | | | Wenn wesentliche Punkte mit „Nein“ beantwortet werden, sollte das Ticket nicht ohne Begründung endgültig geschlossen werden. --- **6. Inhalt einer vollständigen Störungsdokumentation** | Abschnitt | Inhalt | |---|---| | Kurzbeschreibung | Was war sichtbar gestört? | | Auswirkung | Wer oder was war betroffen? | | Beginn | Erster bekannter Fehlerzeitpunkt | | Erkennung | Wie und wann wurde die Störung erkannt? | | Wiederherstellung | Wann funktionierte der Dienst wieder? | | Abschluss | Wann wurde die dauerhafte Lösung bestätigt? | | Systeme | betroffene Clients, Server, Netze und Dienste | | Symptom | Fehlermeldung und beobachtetes Verhalten | | Fehlerumfang | betroffene und nicht betroffene Bereiche | | Zeitachse | wichtige Ereignisse und Maßnahmen | | Ursache | bestätigte technische Ursache | | Auslöser | Ereignis, das den Fehler aktivierte | | Begünstigende Faktoren | Bedingungen, die Auswirkung oder Dauer verstärkten | | Erkennungslücken | Warum wurde der Fehler nicht früher erkannt? | | Diagnose | wichtige Befehle, Ausgaben und Tests | | Wiederherstellung | Sofortmaßnahme oder Workaround | | Dauerhafte Lösung | Beseitigung der Grundursache | | Verifikation | technische und fachliche Funktionstests | | Rollback | vorbereitet, durchgeführt oder nicht erforderlich | | Offene Risiken | verbleibende technische oder organisatorische Risiken | | Folgeaufgaben | Präventions-, Monitoring- und Dokumentationsaufgaben | | Verantwortliche | Zuständigkeit für jede offene Aufgabe | --- **7. Kurzbeschreibung richtig formulieren** **Ungeeignet** `Server war kaputt und wurde repariert.` **Besser** `Am 30.07.2026 konnten Clients aus VLAN 30 zwischen 14:35 und 15:42 Uhr keine HTTPS-Verbindung zu server.example aufbauen. Ursache war eine fehlerhafte Firewall-ACL, die TCP 443 aus VLAN 30 blockierte. Nach Korrektur der ACL waren Porttest, Anmeldung und Monitoring erfolgreich.` Eine gute Kurzbeschreibung enthält: - Zeitraum, - betroffene Funktion, - betroffenen Umfang, - bestätigte Ursache, - Wiederherstellungsmaßnahme, - abschließendes Testergebnis. --- **8. Auswirkung dokumentieren** Die Auswirkung sollte möglichst konkret beschrieben werden. | Bereich | Zu dokumentierende Angaben | |---|---| | Benutzer | Anzahl oder betroffene Gruppen | | Standorte | Gebäude, Niederlassungen oder Netze | | Systeme | Clients, Server, Anwendungen | | Funktionen | Anmeldung, Dateiablage, E-Mail, Produktion | | Dauer | Beginn bis Wiederherstellung | | Daten | Verlust, Verzögerung oder Inkonsistenz | | Sicherheit | mögliche unautorisierte Zugriffe oder Kontrollverlust | | Geschäft | ausgefallene Prozesse oder Verzögerungen | | Externe Parteien | Kunden, Lieferanten oder Provider | | Workaround | verfügbar, eingeschränkt oder nicht vorhanden | Wenn keine genaue Anzahl verfügbar ist, sollte dies ausdrücklich vermerkt und nicht frei geschätzt werden. --- **9. Wichtige Zeitpunkte dokumentieren** | Zeitpunkt | Bedeutung | |---|---| | Letzter funktionierender Zustand | Funktion wurde zuletzt erfolgreich verwendet | | Tatsächlicher Fehlerbeginn | soweit technisch bestimmbar | | Erste Beobachtung | Fehler wurde erstmals bemerkt | | Erkennung | Monitoring oder Support erkannte die Störung | | Meldung | Ticket wurde erstellt | | Bestätigung | Störung wurde technisch nachvollzogen | | Eskalation | weitere Stelle wurde beteiligt | | Eindämmung | Auswirkung wurde begrenzt | | Wiederherstellung | Benutzerfunktion war wieder verfügbar | | Dauerhafte Lösung | Grundursache wurde behandelt | | Ende der Beobachtung | Stabilität wurde ausreichend bestätigt | | Abschluss | Ticket wurde geschlossen | Alle Uhrzeiten sollten dieselbe Zeitzone verwenden oder eindeutig als lokale Zeit beziehungsweise UTC gekennzeichnet sein. --- **10. Zeitkennzahlen berechnen** | Kennzahl | Berechnung | Bedeutung | |---|---|---| | Erkennungszeit | Erkennung minus Fehlerbeginn | Wie lange blieb der Fehler unentdeckt? | | Reaktionszeit | Beginn der Bearbeitung minus Erkennung | Wie schnell begann die Reaktion? | | Eindämmungszeit | Eindämmung minus Erkennung | Wie schnell wurde die Auswirkung begrenzt? | | Wiederherstellungszeit | Wiederherstellung minus Fehlerbeginn | Wie lange war die Funktion beeinträchtigt? | | Lösungszeit | dauerhafte Lösung minus Fehlerbeginn | Wie lange bis zur vollständigen Korrektur? | Abkürzungen wie MTTR werden in verschiedenen Organisationen unterschiedlich verwendet, beispielsweise für „Mean Time to Repair“, „Restore“, „Resolve“ oder „Recovery“. Deshalb sollte die konkret gemeinte Kennzahl ausgeschrieben und definiert werden. --- **11. Zeitachse erstellen** | Zeit | Quelle | Ereignis | Auswirkung oder Erkenntnis | |---|---|---|---| | 14:31 | Deployment | neue Konfiguration verteilt | möglicher Auslöser | | 14:35 | Monitoring | HTTP-Fehlerrate steigt | erster technischer Hinweis | | 14:38 | Benutzer | Anmeldung schlägt fehl | Benutzerwirkung bestätigt | | 14:42 | Support | Ticket erstellt | Bearbeitung beginnt | | 14:48 | Diagnose | Backend 2 liefert HTTP 503 | Fehler eingegrenzt | | 14:55 | Anwendung | falscher Datenbank-Hostname gefunden | unmittelbare Ursache | | 15:05 | Change | Backend 2 aus Rotation genommen | Auswirkung eingedämmt | | 15:17 | Change | Konfiguration korrigiert | technische Lösung | | 15:22 | Test | Anmeldung erfolgreich | Funktion wiederhergestellt | | 15:52 | Monitoring | keine neuen Fehler | Stabilität bestätigt | | 16:00 | Abschluss | Folgeaufgaben erstellt | Incident beendet | **Wichtig** Die Zeitachse sollte Fakten enthalten. Vermutungen werden als solche gekennzeichnet. --- **12. Fakten und Bewertungen trennen** **Fakt** `Um 14:31 Uhr wurde Deployment 2026.07.30-3 ausgeführt.` **Bewertung** `Das Deployment war der Auslöser der Störung.` **Fakt** `Backend 2 protokollierte um 14:35 Uhr einen Fehler bei der Namensauflösung des Datenbankservers.` **Bewertung** `Der falsche Datenbank-Hostname verursachte die HTTP-503-Antworten.` Beide Arten von Informationen sind wichtig, müssen aber voneinander unterscheidbar bleiben. --- **13. Technische Diagnose dokumentieren** Nicht jede vollständige Konsolenausgabe muss direkt in den Tickettext kopiert werden. Das Ticket sollte jedoch die relevanten Befehle, Ergebnisse und Verweise enthalten. | Feld | Beispiel | |---|---| | Prüfzeitpunkt | 2026-07-30 14:48 CEST | | Quellsystem | PC-030 | | Zielsystem | server.example | | Befehl | `Test-NetConnection server.example -Port 443` | | Ergebnis | `TcpTestSucceeded: False` | | Vergleich | Test aus VLAN 40 erfolgreich | | Interpretation | Fehler ist vom Quellnetz abhängig | | Ausgabedatei | `INC-2026-0042-TCP-Test-PC030.txt` | | Hypothese | H1 – ACL blockiert VLAN 30 | | Bewertung | stark gestützt | --- **14. Befehle und Ausgaben nachvollziehbar zuordnen** **Geeignete Dateinamen** `INC-2026-0042-PC030-TCP-Test-20260730-144800.txt` `INC-2026-0042-FW01-Auditlog-20260730-145000.txt` `INC-2026-0042-SRVAPP02-Application.evtx` Ein sinnvoller Dateiname enthält: - Ticketnummer, - System, - Inhalt, - Datum, - Uhrzeit. --- **15. Abschlusszustand unter Windows dokumentieren** **Zeitpunkt** `[RO] Get-Date -Format o` **Dienststatus** `[RO] Get-Service -Name ` **Prozess-ID** `[RO] Get-CimInstance Win32_Service -Filter "Name=''" | Select-Object Name, State, ProcessId` **Listener** `[RO][PRIV] Get-NetTCPConnection -State Listen -LocalPort ` **Funktionstest** `[TEST] Test-NetConnection -Port -InformationLevel Detailed` **Neue Systemfehler** `[RO] Get-WinEvent -FilterHashtable @{LogName="System"; Level=1,2; StartTime=(Get-Date).AddMinutes(-30)} | Select-Object TimeCreated, Id, ProviderName, Message` **Neue Anwendungsfehler** `[RO] Get-WinEvent -FilterHashtable @{LogName="Application"; Level=1,2; StartTime=(Get-Date).AddMinutes(-30)} | Select-Object TimeCreated, Id, ProviderName, Message` --- **16. Abschlusszustand unter Linux dokumentieren** **Zeitpunkt** `[RO] date --iso-8601=seconds` **Dienststatus** `[RO] systemctl status .service --no-pager` **Fehlgeschlagene Dienste** `[RO] systemctl --failed` **Listener** `[RO][PRIV] ss -lntp | grep ":"` **Funktionstest** `[TEST] nc -vz -w 3 ` **Neue Dienstprotokolle** `[RO] journalctl -u .service --since "30 minutes ago" --no-pager` **Neue Systemfehler** `[RO] journalctl --since "30 minutes ago" -p err --no-pager` --- **17. Abschlusszustand unter macOS dokumentieren** **Zeitpunkt** `[RO] date "+%Y-%m-%dT%H:%M:%S%z"` **Systemdienst** `[RO][PRIV] launchctl print system/` **Benutzerdienst** `[RO] launchctl print gui/$(id -u)/` **Listener** `[RO][PRIV] lsof -nP -iTCP: -sTCP:LISTEN` **Funktionstest** `[TEST] nc -vz -w 3 ` **Neue Prozessfehler** `[RO] log show --last 30m --predicate 'process == "" AND (messageType == error OR messageType == fault)' --style compact` --- **18. Plattformübergreifenden HTTP-Abschlusstest durchführen** **Windows** `[TEST] curl.exe -sS -o NUL -w "HTTP=%{http_code} Ziel=%{remote_ip} DNS=%{time_namelookup} TCP=%{time_connect} TLS=%{time_appconnect} Gesamt=%{time_total}\n" --connect-timeout 5 --max-time 15 https:///` **Linux und macOS** `[TEST] curl -sS -o /dev/null -w "HTTP=%{http_code} Ziel=%{remote_ip} DNS=%{time_namelookup} TCP=%{time_connect} TLS=%{time_appconnect} Gesamt=%{time_total}\n" --connect-timeout 5 --max-time 15 https:///` Der Test dokumentiert unter anderem: - HTTP-Status, - tatsächlich verwendete Ziel-IP, - DNS-Zeit, - TCP-Verbindungszeit, - TLS-Zeit, - Gesamtzeit. Die Werte müssen mit bekannten Normalwerten, Monitoring-Baselines oder vereinbarten Anforderungen verglichen werden. --- **19. Prüfsummen für Abschlussunterlagen erstellen** Die Prüfsummen sollten erst erstellt werden, nachdem keine weiteren Dateien mehr zur Sammlung hinzugefügt werden. **Windows** `[FILE] Get-ChildItem "" -File -Recurse | Get-FileHash -Algorithm SHA256 | Export-Csv "-SHA256.csv" -NoTypeInformation -Encoding UTF8` **Linux** `[FILE] (cd "" && find . -type f -print0 | sort -z | xargs -0 -r sha256sum) > "-SHA256SUMS.txt"` **macOS** `[FILE] find "" -type f -exec shasum -a 256 {} \; > "-SHA256SUMS.txt"` Eine Prüfsumme dokumentiert die Integrität der Datei ab dem Zeitpunkt ihrer Berechnung. Sie beweist nicht automatisch Herkunft oder Authentizität. --- **20. Abschlussunterlagen schützen** Diagnose- und Abschlussunterlagen können enthalten: - Benutzernamen, - interne IP-Adressen, - Hostnamen, - Gruppenmitgliedschaften, - Dateipfade, - Zertifikate, - Prozessbefehle, - Sicherheitsprotokolle, - Netzwerkverkehr, - technische Schwachstellen, - Hinweise auf Zugangsdaten. Deshalb muss geklärt sein: - Wer darf die Unterlagen lesen? - Wo dürfen sie gespeichert werden? - Welche Aufbewahrungsfrist gilt? - Müssen personenbezogene Daten minimiert werden? - Muss eine unveränderte Originalkopie erhalten bleiben? - Darf eine geschwärzte Arbeitskopie erstellt werden? - Wann müssen die Daten gelöscht werden? - Gelten rechtliche oder vertragliche Anforderungen? --- **21. Wann eine ausführliche Nachanalyse sinnvoll ist** Eine ausführliche Nachanalyse oder ein Postmortem ist besonders sinnvoll bei: - längerem produktivem Ausfall, - großer Benutzerwirkung, - Datenverlust, - Sicherheitsvorfall, - wiederkehrender Störung, - mehreren beteiligten Teams, - fehlgeschlagener Änderung, - unerwartetem Failover, - hohem manuellem Wiederherstellungsaufwand, - fehlender oder verspäteter Erkennung, - unklarer Ursache, - kritischem Single Point of Failure, - nicht funktionierendem Rückfallplan, - erheblicher SLA- oder SLO-Verletzung. Die Kriterien sollten möglichst bereits vor einer Störung organisatorisch festgelegt werden. --- **22. Sachliche und schuldfreie Nachanalyse** Eine Nachanalyse soll Systeme und Prozesse verbessern, nicht einzelne Personen beschuldigen. **Ungeeignet** `Der Administrator war unvorsichtig und hat den falschen Wert eingetragen.` **Besser** `Die Verwaltungsoberfläche akzeptierte den ungültigen Wert ohne technische Validierung. Die Änderung wurde anschließend ohne Staging- oder Canary-Prüfung auf alle Instanzen verteilt.` **Weiterführende Fragen** - Warum konnte ein ungültiger Wert gespeichert werden? - Warum erkannte kein automatischer Test den Fehler? - Warum wurde die Änderung gleichzeitig überall verteilt? - Warum erkannte das Monitoring die Benutzerwirkung nicht? - Warum war der Rückfallplan nicht verfügbar? - Welche Informationen standen der ausführenden Person zur Verfügung? - Welche technische Schutzmaßnahme hätte den Fehler verhindert? --- **23. Regeln für eine sachliche Formulierung** | Vermeiden | Besser | |---|---| | Schuldzuweisung | technischen Ablauf beschreiben | | persönliche Bewertung | beobachtbare Fakten verwenden | | „offensichtlich“ | konkrete Belege nennen | | „immer“ oder „nie“ | Zeitraum und Umfang nennen | | „Server war kaputt“ | betroffene Funktion beschreiben | | „Netzwerkproblem“ | Protokoll, Quelle und Ziel nennen | | „Benutzerfehler“ | konkrete Eingabe oder Prozesslücke nennen | | „Problem gelöst“ | getestete Funktion und Ergebnis nennen | | „Monitoring versagte“ | fehlende Prüfung oder Alarmbedingung nennen | --- **24. Aufbau einer Nachanalyse** | Abschnitt | Inhalt | |---|---| | Titel | eindeutiger Name und Ticketnummer | | Datum | Datum der Störung und Nachanalyse | | Status | Entwurf, geprüft oder abgeschlossen | | Beteiligte Systeme | technische Komponenten | | Zusammenfassung | kurze sachliche Beschreibung | | Auswirkung | Benutzer, Dienste, Dauer und Daten | | Erkennung | wie und wann die Störung erkannt wurde | | Zeitachse | wichtige Ereignisse | | Ursache | technische Ursache und Mechanismus | | Auslöser | aktivierendes Ereignis | | Begünstigende Faktoren | Bedingungen, die Wirkung verstärkten | | Wiederherstellung | Maßnahmen zur Betriebswiederherstellung | | Lösung | dauerhafte Korrektur | | Was funktionierte gut? | hilfreiche Abläufe und Werkzeuge | | Was funktionierte nicht? | technische oder organisatorische Lücken | | Wo bestand Glück? | Faktoren, die größeren Schaden zufällig verhinderten | | Folgeaufgaben | konkrete Verbesserungsmaßnahmen | | Belege | Protokolle, Tickets, Ausgaben und Changes | --- **25. „Was funktionierte gut?“ dokumentieren** Beispiele: - Monitoring erkannte den Fehler schnell. - Eskalationsweg war bekannt. - Zuständigkeiten waren eindeutig. - Vergleichssystem war verfügbar. - Konfiguration war versioniert. - Rollback war dokumentiert und getestet. - Kommunikation erfolgte regelmäßig. - Protokolle enthielten ausreichende Informationen. - Canary begrenzte die Auswirkung. - Ersatzsystem war verfügbar. Diese Punkte zeigen, welche bestehenden Prozesse beibehalten oder ausgebaut werden sollten. --- **26. „Was funktionierte nicht?“ dokumentieren** Beispiele: - Monitoring prüfte nur Hostverfügbarkeit. - Benutzerfunktion wurde nicht überwacht. - Konfigurationsänderung wurde nicht validiert. - Rückfallplan war unvollständig. - Zuständigkeit war unklar. - wichtige Protokolle fehlten. - Zeitstempel der Systeme wichen voneinander ab. - Dokumentation war veraltet. - Vergleichssystem fehlte. - Änderung wurde gleichzeitig auf allen Systemen ausgeführt. - Workaround war nicht bekannt. - externe Abhängigkeit war nicht dokumentiert. Die Beschreibung sollte konkret genug sein, um daraus eine überprüfbare Aufgabe abzuleiten. --- **27. „Wo bestand Glück?“ dokumentieren** Dieser Abschnitt beschreibt Faktoren, die einen größeren Schaden verhindert haben, obwohl dafür keine verlässliche Schutzmaßnahme existierte. Beispiele: - Störung trat außerhalb der Hauptnutzungszeit auf. - Ein Administrator kannte einen nicht dokumentierten Workaround. - Ein nicht betroffenes Ersatzsystem war zufällig verfügbar. - fehlerhafte Änderung erreichte nicht alle Systeme. - Datenbankverbindung wurde rechtzeitig manuell getrennt. - Benutzer meldete den Fehler frühzeitig. - Backup war verwendbar, obwohl Restore nie getestet wurde. Glück ist keine dauerhafte Schutzmaßnahme. Daraus sollten Verbesserungsaufgaben entstehen. --- **28. Konkrete Folgeaufgaben erstellen** Eine Nachanalyse ohne konkrete und nachverfolgte Maßnahmen verbessert das System nicht. Jede Folgeaufgabe benötigt: - eindeutige Beschreibung, - Verantwortliche, - Ticket- oder Aufgaben-ID, - Priorität, - Zieltermin, - messbaren Endzustand, - Prüfmethode, - Status. **Ungeeignet** `Monitoring verbessern.` **Besser** `Bis zum 14.08.2026 wird für die Webanwendung ein Ende-zu-Ende-Check eingerichtet, der alle fünf Minuten eine Testanmeldung ausführt und bei drei aufeinanderfolgenden Fehlern alarmiert. Verantwortlich: Betriebsteam. Nachweis: erfolgreich ausgelöster Testalarm.` Die konkreten Zeitintervalle und Grenzwerte müssen aus den Anforderungen der jeweiligen Umgebung abgeleitet werden. --- **29. Folgeaufgaben kategorisieren** | Kategorie | Ziel | Beispiel | |---|---|---| | Verhindern | Fehlerentstehung verhindern | Konfigurationsvalidierung | | Begrenzen | Auswirkung reduzieren | Canary oder Rate Limit | | Erkennen | Fehler früher feststellen | Ende-zu-Ende-Monitoring | | Diagnostizieren | Ursache schneller finden | strukturierte Protokolle | | Wiederherstellen | Reparatur beschleunigen | getesteter Rückfallplan | | Dokumentieren | Wissen verfügbar machen | Runbook aktualisieren | | Automatisieren | manuelle Fehler reduzieren | geprüfte Deployment-Pipeline | | Schulen | Verfahren bekannt machen | Übung des Notfallablaufs | | Entfernen | unnötige Abhängigkeit beseitigen | Single Point of Failure abbauen | --- **30. Wirksamkeit von Maßnahmen priorisieren** | Stärke | Maßnahmenart | Beispiel | |---:|---|---| | 1 | Fehler technisch unmöglich machen | ungültige Konfiguration wird abgelehnt | | 2 | Änderung automatisch prüfen | automatischer Syntax- und Funktionstest | | 3 | Auswirkung begrenzen | Canary, Redundanz, automatische Rücknahme | | 4 | Fehler schnell erkennen | Ende-zu-Ende-Monitoring | | 5 | Wiederherstellung beschleunigen | getestetes Runbook | | 6 | Warnhinweis oder Checkliste | manueller Prüfschritt | | 7 | Erinnerung an mehr Aufmerksamkeit | „Beim nächsten Mal besser aufpassen“ | Technische Schutzmaßnahmen und automatisierte Prüfungen sind normalerweise zuverlässiger als eine reine Aufforderung zu größerer Aufmerksamkeit. --- **31. Folgeaufgaben richtig formulieren** | Feld | Beispiel | |---|---| | Aufgabe | JSON-Konfiguration vor Deployment validieren | | Begründung | ungültiger Hostname verursachte Ausfall | | Verantwortlich | Plattformteam | | Priorität | Hoch | | Zieltermin | 14.08.2026 | | messbarer Endzustand | Pipeline lehnt ungültiges Schema ab | | Prüfmethode | Testdeployment mit absichtlich ungültigem Wert | | Ticket-ID | TASK-2026-0182 | | Status | Offen | --- **32. Maßnahmenstatus verwenden** | Status | Bedeutung | |---|---| | Offen | Aufgabe wurde erstellt | | Geplant | Umsetzung ist terminiert | | In Bearbeitung | Umsetzung läuft | | Blockiert | Abhängigkeit verhindert Umsetzung | | Umgesetzt | technische Änderung ist erfolgt | | In Prüfung | Wirksamkeit wird verifiziert | | Abgeschlossen | messbarer Endzustand ist bestätigt | | Verworfen | Aufgabe wurde begründet abgelehnt | | Risiko akzeptiert | Risiko wurde durch zuständige Stelle akzeptiert | „Umgesetzt“ und „wirksam bestätigt“ sollten unterschieden werden. --- **33. Monitoring aus der Störung verbessern** Nach einer Störung sollte geprüft werden: - Wurde der Fehler automatisch erkannt? - Wurde die Benutzerwirkung erkannt? - War der Alarm rechtzeitig? - War der Alarm verständlich? - War der Alarm einer zuständigen Person zugeordnet? - Enthielt der Alarm ausreichend Kontext? - Gab es zu viele irrelevante Alarme? - Fehlte eine wichtige Messgröße? - Funktionierte der Alarm während der Störung? - Wurde die Wiederherstellung korrekt erkannt? **Guter Alarm** Ein guter Alarm ist: - symptomorientiert, - handlungsrelevant, - eindeutig zugeordnet, - mit Zeit und betroffenem System versehen, - mit Runbook oder Diagnosehinweis verknüpft, - anhand eines realistischen Grenzwerts ausgelöst. --- **34. Benutzerwirkung statt nur Komponentenstatus überwachen** | Komponentenprüfung | Zusätzliche Ende-zu-Ende-Prüfung | |---|---| | Server antwortet auf Ping | Benutzer kann Anwendung öffnen | | TCP 443 ist erreichbar | HTTPS-Anmeldung funktioniert | | Dienststatus ist „Running“ | konkrete API-Anfrage funktioniert | | Datenbankprozess läuft | Anwendung kann Daten lesen | | Dateiserver ist erreichbar | Testdatei kann gelesen werden | | Drucker antwortet im Netz | Testseite wird tatsächlich gedruckt | | Backupjob startet | Sicherung wird erfolgreich abgeschlossen und geprüft | | DNS-Dienst läuft | vorgesehener Name wird korrekt aufgelöst | --- **35. Dokumentation und Runbooks aktualisieren** Nach der Störung sollten geprüft werden: - Systemdokumentation, - Netzplan, - Port- und Firewallübersicht, - Dienstabhängigkeiten, - Backup- und Restoreanleitung, - Eskalationskontakte, - Monitoringbeschreibung, - bekannte Fehler, - Installationsanleitung, - Rollbackverfahren, - Notfallzugänge, - Konfigurationsvorlagen, - Befehlsübersichten. **Ein guter Wissenseintrag enthält** - eindeutiges Fehlerbild, - typische Fehlermeldung, - betroffene Systeme, - mögliche Ursachen, - Diagnosebefehle, - Interpretation der Ausgaben, - bestätigte Lösung, - Rückfallmöglichkeit, - Risiken, - Quellen, - Datum der letzten Prüfung. --- **36. Wiederkehrende Störungen erkennen** Einzelne Tickets sollten nach gemeinsamen Merkmalen ausgewertet werden. **Mögliche Suchmerkmale** - gleiche Fehlermeldung, - gleicher Dienst, - gleicher Standort, - gleiches Gerät, - gleiche Anwendungsversion, - gleicher Zeitpunkt, - gleicher Hersteller, - gleicher Auslöser, - gleicher Workaround, - gleiche Grundursache. Bei wiederkehrenden Störungen sollte ein übergeordneter Problem- oder Ursachenanalyse-Eintrag erstellt und mit den einzelnen Tickets verknüpft werden. --- **37. Verbleibende Risiken dokumentieren** Nicht jede Verbesserung kann sofort umgesetzt werden. | Risiko | Wahrscheinlichkeit | Auswirkung | Zwischenmaßnahme | Verantwortlich | Termin | |---|---|---|---|---|---| | Fehler kann bis zur Pipeline-Anpassung erneut auftreten | Mittel | Hoch | Änderungen manuell prüfen | Plattformteam | 14.08.2026 | | Monitoring erkennt Teilfehler nicht | Mittel | Mittel | manuelle Kontrolle | Betriebsteam | 07.08.2026 | | Rollback noch nicht automatisiert | Niedrig | Hoch | dokumentiertes manuelles Verfahren | Entwicklung | 21.08.2026 | Ein Risiko darf nur durch die dafür zuständige Stelle akzeptiert werden. --- **38. Sicherheitsvorfälle gesondert behandeln** Bei einem möglichen oder bestätigten Sicherheitsvorfall darf der normale technische Ticketabschluss nicht allein entscheiden. Zusätzlich können erforderlich sein: - Freigabe durch Incident Response oder SecOps, - Beweismittelerhaltung, - Datenschutzprüfung, - rechtliche Bewertung, - Meldepflichten, - Benachrichtigung betroffener Stellen, - längere Aufbewahrungsfristen, - zusätzliche Kontrollen, - Zugangsdatenwechsel, - Bedrohungssuche, - Überwachung möglicher Folgeaktivitäten. Der technische Dienst kann bereits wiederhergestellt sein, während der Sicherheitsvorfall noch offen bleibt. --- **39. Abschlusskommunikation erstellen** Eine Abschlussmeldung sollte enthalten: - betroffene Funktion, - Zeitraum, - Auswirkung, - Wiederherstellungszeitpunkt, - bestätigte Ursache oder aktueller Kenntnisstand, - umgesetzte Lösung, - verbleibende Einschränkungen, - offene Folgemaßnahmen, - Ansprechpartner oder Ticketnummer. **Beispiel** `Die Störung beim Zugriff auf die Webanwendung ist seit 15:42 Uhr behoben. Betroffen waren Clients aus VLAN 30. Ursache war eine fehlerhafte Firewall-ACL für TCP 443. Die Regel wurde korrigiert und durch Port-, Anmelde- und Monitoringtests bestätigt. Weitere Einschränkungen sind derzeit nicht bekannt. Als Folgemaßnahme wird ein automatischer Verbindungstest aus jedem Client-VLAN eingerichtet. Referenz: INC-2026-0042.` --- **40. Vollständiges Abschlussbeispiel** **Zusammenfassung** Am 30.07.2026 konnten Clients aus VLAN 30 die Anwendung `server.example` über HTTPS nicht erreichen. **Auswirkung** - ein Standort betroffen, - ungefähr 45 Arbeitsplätze, - Anmeldung an der Anwendung nicht möglich, - keine Hinweise auf Datenverlust, - Clients aus VLAN 40 nicht betroffen. **Zeitraum** - letzter erfolgreicher Zugriff: 13:50 Uhr, - erste bekannte Störung: 14:35 Uhr, - Erkennung: 14:42 Uhr, - Wiederherstellung: 15:42 Uhr, - Beobachtung beendet: 16:42 Uhr. **Ursache** Eine Firewall-ACL blockierte TCP 443 aus VLAN 30. **Auslöser** Die ACL wurde bei einer Netzwerkänderung um 14:31 Uhr unvollständig übernommen. **Begünstigender Faktor** Es existierte kein automatischer Verbindungstest aus jedem Client-VLAN. **Diagnose** - DNS-Auflösung korrekt, - Ziel-IP korrekt, - Porttest aus VLAN 30 fehlgeschlagen, - Porttest aus VLAN 40 erfolgreich, - Firewall-Log zeigte verworfene Pakete, - Serverdienst und Listener waren aktiv. **Lösung** Die freigegebene ACL wurde korrigiert. **Verifikation** - TCP 443 aus VLAN 30 erreichbar, - HTTPS-Anmeldung erfolgreich, - andere VLANs weiterhin funktionsfähig, - gesperrte Ports weiterhin gesperrt, - keine neuen relevanten Firewallfehler, - Monitoring über eine Stunde unauffällig. **Folgeaufgaben** | Aufgabe | Verantwortlich | Priorität | Termin | |---|---|---|---| | Verbindungstest aus jedem Client-VLAN einrichten | Monitoringteam | Hoch | 14.08.2026 | | ACL-Änderungsvorlage ergänzen | Netzwerkteam | Mittel | 07.08.2026 | | Rückfallverfahren dokumentieren | Netzwerkteam | Mittel | 07.08.2026 | | Netzplandokumentation aktualisieren | Systemintegration | Mittel | 05.08.2026 | --- **41. Vorlage für eine vollständige Störungsdokumentation** **Ticketnummer:** `` **Titel:** `` **Status:** `Erkannt / In Analyse / Workaround / Wiederhergestellt / Beobachtung / Gelöst / Abgeschlossen` **Zusammenfassung:** `` **Auswirkung:** `` **Beginn der Störung:** `` **Erkennung:** `` **Wiederherstellung:** `` **Ende der Beobachtung:** `` **Betroffene Systeme:** `` **Nicht betroffene Vergleichssysteme:** `` **Fehlermeldung:** `` **Direkte technische Ursache:** `` **Technischer Mechanismus:** `` **Auslöser:** `` **Grundursache:** `` **Begünstigende Faktoren:** `` **Erkennungslücken:** `` **Zeitachse:** `` **Diagnosebefehle und Ergebnisse:** `` **Sofortmaßnahme:** `` **Dauerhafte Lösung:** `` **Rollback:** `` **Verifikation:** `` **Monitoring nach der Lösung:** `` **Verbleibende Risiken:** `` **Folgeaufgaben:** `` **Abschlussfreigabe:** `` --- **42. Abschlusscheckliste** - [ ] Ursprüngliche Benutzerfunktion wiederhergestellt - [ ] Technische Funktion geprüft - [ ] Abhängigkeiten geprüft - [ ] Regressionstests durchgeführt - [ ] Negative Sicherheitstests durchgeführt - [ ] Monitoring beobachtet - [ ] Protokolle nach der Lösung geprüft - [ ] Wiederherstellungszeit dokumentiert - [ ] Abschlusszeit dokumentiert - [ ] Zeitzone angegeben - [ ] Fehlerumfang dokumentiert - [ ] Auswirkung dokumentiert - [ ] Zeitachse erstellt - [ ] Direkte Ursache dokumentiert - [ ] Auslöser dokumentiert - [ ] Grundursache dokumentiert - [ ] Begünstigende Faktoren dokumentiert - [ ] Erkennungslücken dokumentiert - [ ] Workaround und dauerhafte Lösung unterschieden - [ ] Diagnosebefehle und Ergebnisse zugeordnet - [ ] Belege geschützt gespeichert - [ ] Prüfsummen erstellt - [ ] verbleibende Risiken dokumentiert - [ ] Folgeaufgaben erstellt - [ ] jede Folgeaufgabe besitzt eine verantwortliche Person - [ ] jede Folgeaufgabe besitzt einen messbaren Endzustand - [ ] Monitoringverbesserungen geprüft - [ ] Runbooks und Dokumentation geprüft - [ ] betroffene Personen informiert - [ ] Sicherheits- oder Datenschutzprüfung berücksichtigt - [ ] Abschlussstatus eindeutig gesetzt --- **Ergebnis dieses Arbeitsschrittes** Am Ende dieses Schrittes ist nicht nur die technische Funktion wiederhergestellt. Der gesamte Vorfall ist nachvollziehbar dokumentiert, offene Risiken sind bekannt und konkrete Verbesserungsmaßnahmen wurden zugewiesen. Eine Störung sollte erst abgeschlossen werden, wenn: - Wiederherstellung bestätigt ist, - Ursache oder verbleibende Unsicherheit dokumentiert ist, - Auswirkungen und Zeitachse nachvollziehbar sind, - offene Maßnahmen nachverfolgt werden, - Erkenntnisse in Monitoring, Dokumentation und Betriebsprozesse zurückfließen. **Nächste Seite und Abschluss von Kapitel 1:** **1.10 Schnellreferenz – Diagnosebefehle für Windows, Linux und macOS** --- **Offizielle Hersteller-, Behörden- und Projektdokumentation** - [NIST – SP 800-61 Revision 3: Incident Response Recommendations and Considerations](https://csrc.nist.gov/pubs/sp/800/61/r3/final) - [NIST – Incident-Response-Projekt](https://csrc.nist.gov/projects/incident-response) - [Google SRE – Postmortem Culture](https://sre.google/sre-book/postmortem-culture/) - [Google SRE Workbook – Postmortem Practices](https://sre.google/workbook/postmortem-culture/) - [Google SRE – Incident Management Guide](https://sre.google/resources/practices-and-processes/incident-management-guide/) - [Microsoft Learn – Post-incident Activity](https://learn.microsoft.com/en-us/compliance/assurance/assurance-sim-post-incident-activity) - [Microsoft Learn – Incident Management](https://learn.microsoft.com/en-us/azure/well-architected/design-guides/incident-management) - [Microsoft Learn – Get-FileHash](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.utility/get-filehash) - [CISA – Cybersecurity Incident and Vulnerability Response Playbooks](https://www.cisa.gov/resources-tools/resources/federal-government-cybersecurity-incident-and-vulnerability-response-playbooks) - [curl – Offizielle Befehlsreferenz](https://curl.se/docs/manpage.html) # 1.10 Schnellreferenz – Diagnosebefehle für Windows, Linux und macOS **1.10 Schnellreferenz – Diagnosebefehle für Windows, Linux und macOS** Diese Seite fasst die wichtigsten Diagnosebefehle aus Kapitel 1 als plattformübergreifendes Nachschlagewerk zusammen. Sie ist für die schnelle Fehlersuche gedacht. Die ausführliche Vorgehensweise, Einschränkungen und Interpretationen befinden sich auf den vorherigen Seiten. > Befehle nicht wahllos nacheinander ausführen. Zuerst Fehlerbild und Umfang bestimmen, flüchtige Informationen sichern und anschließend gezielt prüfen. Die Bereiche ab Punkt 3 können über die jeweilige Überschrift auf- und zugeklappt werden. --- **1. Kennzeichnungen** | Kennzeichnung | Bedeutung | |---|---| | `[RO]` | Read-only: liest Informationen aus | | `[TEST]` | Führt eine aktive Prüfung aus | | `[FILE]` | Erstellt oder überschreibt eine Datei | | `[PRIV]` | Benötigt möglicherweise Administrator- oder Root-Rechte | | `[CHANGE]` | Verändert Konfiguration oder Betriebszustand | | `[DISRUPTIV]` | Kann Benutzer oder produktive Dienste beeinträchtigen | | `[SENSITIV]` | Ausgabe kann vertrauliche Daten enthalten | Auch `[RO]`-Befehle sind nicht vollständig spurlos. Sie starten Prozesse und können in Shell-Historien, Auditprotokollen oder Sicherheitslösungen erscheinen. --- **2. Platzhalter** Alle Angaben in spitzen Klammern müssen vor der Ausführung ersetzt werden. | Platzhalter | Bedeutung | |---|---| | `` | Hostname oder FQDN des Zielservers | | `` | IPv4- oder IPv6-Adresse | | `` | TCP- oder UDP-Port | | `` | interner Dienstname | | `` | launchd-Label unter macOS | | `` | Name eines Prozesses | | `` | Prozess-ID | | `` | Benutzerkonto | | `` | vollständiger Dateipfad | | `` | Datei- oder Verzeichnispfad | | `` | freigegebener Speicherort | | `` | Netzwerkschnittstelle | | `` | Adresse des abzufragenden DNS-Servers | ---
3. Plattformhinweise | Plattform | Hinweise | |---|---| | Windows | PowerShell möglichst mit normalen Benutzerrechten starten; erhöhte Rechte nur bei Bedarf | | Linux | Befehle unterscheiden sich nach Distribution, Init-System und installierten Paketen | | macOS | Viele Werkzeuge verwenden BSD-Syntax und unterscheiden sich von den Linux-Versionen | | Alle | Befehle mit Schreib-, Neustart- oder Aufzeichnungsfunktion vorher auf Auswirkungen prüfen | **Lokale Hilfe anzeigen** | Windows PowerShell | Linux | macOS | |---|---|---| | `[RO] Get-Help -Full` | `[RO] man ` | `[RO] man ` | | `[RO] Get-Command -Syntax` | `[RO] --help` | `[RO] -h` oder `man ` |
4. Schneller Diagnoseablauf | Reihenfolge | Prüfung | Ziel | |---:|---|---| | 1 | Uhrzeit und Zeitzone | Protokolle korrekt vergleichen | | 2 | Fehler exakt reproduzieren | tatsächliches Symptom bestätigen | | 3 | betroffene und funktionierende Systeme vergleichen | Fehlerumfang eingrenzen | | 4 | IP-Konfiguration prüfen | lokale Netzwerkkonfiguration bestätigen | | 5 | DNS prüfen | Name und Zieladresse bestätigen | | 6 | Routing und Gateway prüfen | Netzwerkpfad bestätigen | | 7 | Zielport prüfen | Transportverbindung testen | | 8 | Protokoll oder Anwendung prüfen | HTTP, TLS oder Anwendungsebene | | 9 | Dienst und Listener prüfen | serverseitigen Zustand bestätigen | | 10 | Protokolle prüfen | technische Fehler und Zeitpunkt finden | | 11 | Ressourcen prüfen | CPU, RAM, Datenträger und I/O | | 12 | letzte Änderungen prüfen | Updates, Deployments und Konfiguration | | 13 | Hypothesen mit Gegenprobe testen | Ursache bestätigen oder widerlegen | | 14 | Ausgangszustand sichern | sichere Änderung und Rückfall ermöglichen | | 15 | Lösung umsetzen und Ende-zu-Ende prüfen | Funktion dauerhaft bestätigen |
5. Datum, Uhrzeit und Zeitzone | Aufgabe | Windows | Linux | macOS | |---|---|---|---| | Lokale Zeit | `[RO] Get-Date -Format o` | `[RO] date --iso-8601=seconds` | `[RO] date "+%Y-%m-%dT%H:%M:%S%z"` | | UTC-Zeit | `[RO] (Get-Date).ToUniversalTime().ToString("o")` | `[RO] date -u "+%Y-%m-%dT%H:%M:%SZ"` | `[RO] date -u "+%Y-%m-%dT%H:%M:%SZ"` | | Zeitzone | `[RO] Get-TimeZone` | `[RO] timedatectl status` | `[RO][PRIV] sudo systemsetup -gettimezone` | | Zeitquelle | `[RO] w32tm /query /source` | `[RO] timedatectl timesync-status` | `[TEST] sntp -d time.apple.com` | | Synchronisationsstatus | `[RO] w32tm /query /status` | `[RO] timedatectl status` | `[TEST] sntp -d time.apple.com` | | chrony-Status | Nicht zutreffend | `[RO] chronyc tracking` | Nicht standardmäßig vorhanden | | chrony-Quellen | Nicht zutreffend | `[RO] chronyc sources -v` | Nicht standardmäßig vorhanden | **Interpretation** | Beobachtung | Mögliche Bedeutung | |---|---| | Systemzeit weicht ab | NTP-, Domänen-, Netzwerk- oder Konfigurationsproblem | | Zeitzonen unterscheiden sich | Ereignisse vor dem Vergleich umrechnen | | Zeitquelle nicht erreichbar | Firewall, DNS, Routing oder Zeitdienst prüfen | | Kerberos- oder Zertifikatsfehler | Systemzeit und Zeitzone zuerst prüfen |
6. Hostname, Betriebssystem und Hardware | Aufgabe | Windows | Linux | macOS | |---|---|---|---| | Hostname | `[RO] hostname` | `[RO] hostname` | `[RO] hostname` | | Systemübersicht | `[RO] Get-ComputerInfo` | `[RO] hostnamectl` | `[RO] system_profiler SPSoftwareDataType SPHardwareDataType` | | Betriebssystem | `[RO] Get-CimInstance Win32_OperatingSystem \| Select-Object Caption,Version,BuildNumber` | `[RO] cat /etc/os-release` | `[RO] sw_vers` | | Kernel und Architektur | `[RO] systeminfo` | `[RO] uname -a` | `[RO] uname -a` | | Prozessor | `[RO] Get-CimInstance Win32_Processor` | `[RO] lscpu` | `[RO] sysctl -n machdep.cpu.brand_string` | | Hardwaremodell | `[RO] Get-CimInstance Win32_ComputerSystem` | `[RO][PRIV] dmidecode -t system` | `[RO] system_profiler SPHardwareDataType` | | Seriennummer | `[RO] Get-CimInstance Win32_BIOS \| Select-Object SerialNumber` | `[RO][PRIV] dmidecode -s system-serial-number` | `[RO] system_profiler SPHardwareDataType` | `dmidecode` ist nicht auf jeder Linux-Installation vorhanden und benötigt üblicherweise Root-Rechte.
7. Systemstart und Betriebsdauer | Aufgabe | Windows | Linux | macOS | |---|---|---|---| | Letzter Start | `[RO] Get-CimInstance Win32_OperatingSystem \| Select-Object LastBootUpTime` | `[RO] uptime -s` | `[RO] sysctl -n kern.boottime` | | Alternative | `[RO] systeminfo` | `[RO] who -b` | `[RO] last reboot` | | Betriebsdauer | `[RO] (Get-Date) - (Get-CimInstance Win32_OperatingSystem).LastBootUpTime` | `[RO] uptime` | `[RO] uptime` | | Neustartverlauf | Ereignisanzeige beziehungsweise Systemprotokoll | `[RO] last reboot` | `[RO] last reboot` | | Aktueller Boot | Ereignisanzeige | `[RO] journalctl -b` | Unified Log über Startzeit eingrenzen | | Vorheriger Boot | Ereignisanzeige | `[RO] journalctl -b -1` | `[RO] last reboot` |
8. Benutzeridentität und Sitzungen | Aufgabe | Windows | Linux | macOS | |---|---|---|---| | Aktueller Benutzer | `[RO] whoami` | `[RO] whoami` | `[RO] whoami` | | Benutzer-ID und Gruppen | `[RO][SENSITIV] whoami /all` | `[RO] id` | `[RO] id` | | Bestimmter Benutzer | lokale oder Domänenverwaltung verwenden | `[RO] id ` | `[RO] id ` | | Angemeldete Benutzer | `[RO] quser` | `[RO] who -a` | `[RO] who` | | Sitzungen und Aktivität | `[RO] query user` | `[RO] w` | `[RO] w` | | Lokale Benutzer | `[RO] Get-LocalUser` | `[RO] getent passwd` | `[RO] dscl . -list /Users` | | Lokale Gruppen | `[RO] Get-LocalGroup` | `[RO] getent group` | `[RO] dscl . -list /Groups` | Ausgaben können Benutzernamen, SIDs, Gruppen und sicherheitsrelevante Informationen enthalten.
9. Prozesse | Aufgabe | Windows | Linux | macOS | |---|---|---|---| | Prozessübersicht | `[RO] Get-Process` | `[RO][SENSITIV] ps auxww` | `[RO][SENSITIV] ps auxww` | | PID, Elternprozess und Befehlszeile | `[RO][SENSITIV] Get-CimInstance Win32_Process \| Select-Object ProcessId,ParentProcessId,Name,ExecutablePath,CommandLine` | `[RO][SENSITIV] ps -ef --forest` | `[RO][SENSITIV] ps -axo pid,ppid,user,lstart,state,%cpu,%mem,command` | | Einzelnen Prozess prüfen | `[RO] Get-Process -Id \| Format-List *` | `[RO] ps -p -o pid,ppid,user,lstart,stat,%cpu,%mem,command` | `[RO] ps -p -o pid,ppid,user,lstart,state,%cpu,%mem,command` | | Nach Namen suchen | `[RO] Get-Process -Name ` | `[RO] pgrep -a ` | `[RO] pgrep -fl ` | | Höchste CPU-Nutzung | `[RO] Get-Process \| Sort-Object CPU -Descending \| Select-Object -First 20` | `[RO] ps aux --sort=-%cpu \| head -n 20` | `[RO] top -l 1 -o cpu` | | Höchste Speichernutzung | `[RO] Get-Process \| Sort-Object WorkingSet64 -Descending \| Select-Object -First 20` | `[RO] ps aux --sort=-%mem \| head -n 20` | `[RO] top -l 1 -o mem` | | Offene Dateien eines Prozesses | kein einheitlicher integrierter PowerShell-Befehl | `[RO][PRIV][SENSITIV] lsof -p ` | `[RO][PRIV][SENSITIV] lsof -p ` |
10. Dienste | Aufgabe | Windows | Linux mit systemd | macOS | |---|---|---|---| | Alle Dienste | `[RO] Get-Service` | `[RO] systemctl list-units --type=service --all` | `[RO] launchctl list` | | Bestimmten Dienst prüfen | `[RO] Get-Service -Name ` | `[RO] systemctl status .service --no-pager` | `[RO][PRIV] launchctl print system/` | | Benutzerdienst prüfen | `[RO] Get-Service -Name ` | `[RO] systemctl --user status .service` | `[RO] launchctl print gui/$(id -u)/` | | Fehlgeschlagene Dienste | Status und Ereignisprotokoll prüfen | `[RO] systemctl --failed` | Prozess und Unified Log prüfen | | Laufende Dienste | `[RO] Get-Service \| Where-Object Status -eq "Running"` | `[RO] systemctl list-units --type=service --state=running` | `[RO] launchctl list` | | Dienstkonfiguration | `[RO][SENSITIV] Get-CimInstance Win32_Service -Filter "Name=''"` | `[RO] systemctl cat .service` | `[RO] plutil -p ""` | | Prozess-ID | `[RO] Get-CimInstance Win32_Service -Filter "Name=''" \| Select-Object ProcessId` | `[RO] systemctl show .service -p MainPID` | `[RO] launchctl print system/` | | Startmodus | `[RO] Get-CimInstance Win32_Service -Filter "Name=''" \| Select-Object StartMode` | `[RO] systemctl is-enabled .service` | Property-List mit `plutil -p` prüfen | | Dienstkonto | `[RO][SENSITIV] Get-CimInstance Win32_Service -Filter "Name=''" \| Select-Object StartName` | `[RO] systemctl show .service -p User -p Group` | `[RO] plutil -p ""` |
11. Dienstabhängigkeiten | Aufgabe | Windows | Linux mit systemd | macOS | |---|---|---|---| | Benötigte Dienste | `[RO] Get-Service -Name -RequiredServices` | `[RO] systemctl list-dependencies .service --all` | keine allgemeine Abhängigkeitsdarstellung | | Abhängige Dienste | `[RO] Get-Service -Name -DependentServices` | `[RO] systemctl list-dependencies .service --reverse --all` | anwendungsspezifisch prüfen | | Reihenfolge und Anforderungen | `[RO] sc.exe qc ` | `[RO] systemctl show .service -p Requires -p Wants -p After -p Before` | Property-List und Dokumentation prüfen | | Effektive Konfiguration | `[RO] Get-CimInstance Win32_Service -Filter "Name=''"` | `[RO] systemctl cat .service` | `[RO] plutil -p ""` |
12. Arbeitsspeicher | Aufgabe | Windows | Linux | macOS | |---|---|---|---| | Arbeitsspeicherübersicht | `[RO] Get-CimInstance Win32_OperatingSystem \| Select-Object TotalVisibleMemorySize,FreePhysicalMemory` | `[RO] free -h` | `[RO] vm_stat` | | Prozessspeicher | `[RO] Get-Process \| Sort-Object WorkingSet64 -Descending` | `[RO] ps aux --sort=-%mem` | `[RO] top -l 1 -o mem` | | Laufende Übersicht | `[RO] Get-Process` oder Task-Manager | `[RO] top` | `[RO] top` | Bei Windows werden `TotalVisibleMemorySize` und `FreePhysicalMemory` in KiB ausgegeben.
13. Datenträger und Dateisysteme | Aufgabe | Windows | Linux | macOS | |---|---|---|---| | Volumes | `[RO] Get-Volume` | `[RO] lsblk -f` | `[RO] diskutil list` | | Freier Speicher | `[RO] Get-PSDrive -PSProvider FileSystem` | `[RO] df -hT` | `[RO] df -h` | | Inode-Belegung | nicht in dieser Unix-Form anwendbar | `[RO] df -ih` | `[RO] df -ih` | | Mounts | `[RO] Get-Volume` | `[RO] findmnt` | `[RO] mount` | | Physische Datenträger | `[RO] Get-PhysicalDisk` | `[RO] lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS` | `[RO] diskutil list` | | Datenträgerinformationen | `[RO] Get-Disk` | `[RO] lsblk -f` | `[RO] diskutil info ` | | I/O-Messung | Performance Monitor oder passende Counter | `[RO][TEST] iostat -xz 1 5` | `[RO][TEST] iostat -w 1 -c 5` | `iostat` gehört unter Linux häufig zum Paket `sysstat`.
14. IP-Konfiguration | Aufgabe | Windows | Linux | macOS | |---|---|---|---| | Vollständige IP-Konfiguration | `[RO] ipconfig /all` | `[RO] ip -details address show` | `[RO] ifconfig -a` | | PowerShell-Netzwerkübersicht | `[RO] Get-NetIPConfiguration` | Nicht zutreffend | Nicht zutreffend | | Interfacezustand | `[RO] Get-NetAdapter` | `[RO] ip -details link show` | `[RO] ifconfig -a` | | NetworkManager-Geräte | Nicht zutreffend | `[RO] nmcli device status` | Nicht zutreffend | | NetworkManager-Verbindungen | Nicht zutreffend | `[RO][SENSITIV] nmcli connection show` | Nicht zutreffend | | Hardwareports | `[RO] Get-NetAdapter` | `[RO] ip link show` | `[RO] networksetup -listallhardwareports` | | Netzwerkdienste | Adapter über PowerShell | NetworkManager oder systemd-networkd | `[RO] networksetup -listallnetworkservices` |
15. DHCP-Informationen am Client | Aufgabe | Windows | Linux | macOS | |---|---|---|---| | DHCP-Server und Lease | `[RO] ipconfig /all` | abhängig vom Netzwerkmanager und DHCP-Client | `[RO] ipconfig getpacket ` | | NetworkManager-DHCP | Nicht zutreffend | `[RO] nmcli device show ` | Nicht zutreffend | | systemd-networkd | Nicht zutreffend | `[RO] networkctl status ` | Nicht zutreffend | | Interface-IP | `[RO] Get-NetIPAddress` | `[RO] ip address show ` | `[RO] ipconfig getifaddr ` | DHCP-Lease-Dateien und Speicherorte unterscheiden sich nach Distribution und verwendetem Netzwerkdienst.
16. DNS-Konfiguration | Aufgabe | Windows | Linux | macOS | |---|---|---|---| | DNS-Server | `[RO] Get-DnsClientServerAddress` | `[RO] resolvectl status` | `[RO][SENSITIV] scutil --dns` | | Resolverdatei | `ipconfig /all` verwenden | `[RO] cat /etc/resolv.conf` | `[RO] cat /etc/resolv.conf` | | Suchdomänen | `[RO] ipconfig /all` | `[RO] resolvectl status` | `[RO][SENSITIV] scutil --dns` | | DNS-Cache | `[RO][SENSITIV] Get-DnsClientCache` | kein einheitlicher systemweiter Cache-Dump | kein einheitlicher systemweiter Cache-Dump | | Alternative Cacheanzeige | `[RO][SENSITIV] ipconfig /displaydns` | abhängig vom Resolver | abhängig vom Resolver |
17. DNS-Auflösung | Aufgabe | Windows | Linux | macOS | |---|---|---|---| | Standardabfrage | `[TEST] Resolve-DnsName ` | `[TEST] getent ahosts ` | `[TEST] dscacheutil -q host -a name ` | | Abfrage mit dig | dig nur wenn installiert | `[TEST] dig ` | `[TEST] dig ` | | Kurze Ausgabe | `[TEST] Resolve-DnsName \| Select-Object Name,Type,IPAddress` | `[TEST] dig +short ` | `[TEST] dig +short ` | | Bestimmten DNS-Server abfragen | `[TEST] Resolve-DnsName -Server ` | `[TEST] dig @ ` | `[TEST] dig @ ` | | nslookup | `[TEST] nslookup ` | `[TEST] nslookup ` | `[TEST] nslookup ` | | Reverse Lookup | `[TEST] Resolve-DnsName ` | `[TEST] dig -x ` | `[TEST] dig -x ` | **Interpretation** | Ergebnis | Mögliche Bedeutung | |---|---| | Name wird nicht aufgelöst | DNS-Server, Clientkonfiguration, Zone oder Netzwerk | | Falsche IP-Adresse | falscher Eintrag, Cache, Hosts-Datei oder Split-DNS | | Verschiedene IP-Adressen | Load Balancing, DNS-Rotation oder unterschiedliche Resolver | | Bestimmter DNS-Server antwortet korrekt | Standardresolver oder Clientkonfiguration prüfen | | IP funktioniert, Name nicht | DNS priorisieren |
18. Hosts-Datei anzeigen | Windows | Linux | macOS | |---|---|---| | `[RO] Get-Content "$env:SystemRoot\System32\drivers\etc\hosts"` | `[RO] cat /etc/hosts` | `[RO] cat /etc/hosts` | Die Hosts-Datei kann DNS-Ergebnisse lokal überschreiben.
19. Routing | Aufgabe | Windows | Linux | macOS | |---|---|---|---| | Routingtabelle | `[RO] route print` | `[RO] ip route show table all` | `[RO] netstat -rn` | | PowerShell-Routen | `[RO] Get-NetRoute` | Nicht zutreffend | Nicht zutreffend | | IPv4-Routen | `[RO] Get-NetRoute -AddressFamily IPv4` | `[RO] ip -4 route show table all` | `[RO] netstat -rn -f inet` | | IPv6-Routen | `[RO] Get-NetRoute -AddressFamily IPv6` | `[RO] ip -6 route show table all` | `[RO] netstat -rn -f inet6` | | Route zu einem Ziel | `[RO] Test-NetConnection -DiagnoseRouting -InformationLevel Detailed` | `[RO] ip route get ` | `[RO] route -n get ` | | Standardroute | `[RO] Get-NetRoute -DestinationPrefix "0.0.0.0/0"` | `[RO] ip route show default` | `[RO] route -n get default` |
20. ARP- und Neighbor-Tabelle | Aufgabe | Windows | Linux | macOS | |---|---|---|---| | ARP-Tabelle | `[RO] arp -a` | `[RO] ip neigh show` | `[RO] arp -an` | | PowerShell-Neighbor | `[RO] Get-NetNeighbor` | Nicht zutreffend | Nicht zutreffend | | Bestimmtes Interface | `[RO] Get-NetNeighbor -InterfaceAlias ""` | `[RO] ip neigh show dev ` | `[RO] arp -an` | **Interpretation** | Zustand | Bedeutung | |---|---| | Reachable | Nachbar wurde kürzlich bestätigt | | Stale | Eintrag vorhanden, aber nicht aktuell bestätigt | | Incomplete oder Failed | Adressauflösung fehlgeschlagen | | unterschiedliche MAC-Adressen | Redundanz, Proxy ARP, IP-Konflikt oder Änderung prüfen |
21. Proxykonfiguration | Aufgabe | Windows | Linux | macOS | |---|---|---|---| | WinHTTP-Proxy | `[RO] netsh winhttp show proxy` | Nicht zutreffend | Nicht zutreffend | | Umgebungsvariablen | `[RO][SENSITIV] Get-ChildItem Env: \| Where-Object Name -Match "proxy"` | `[RO][SENSITIV] env \| grep -i proxy` | `[RO][SENSITIV] env \| grep -i proxy` | | Systemproxy | Internetoptionen und Richtlinien prüfen | Desktop- oder Netzwerkmanager abhängig | `[RO] scutil --proxy` | | curl ohne Proxy | `[TEST] curl.exe --noproxy "*" -v https:///` | `[TEST] curl --noproxy "*" -v https:///` | `[TEST] curl --noproxy "*" -v https:///` | Das Umgehen eines Unternehmensproxys darf nur erfolgen, wenn direkte Verbindungen erlaubt und der Test autorisiert ist.
22. Aktive TCP-Verbindungen | Aufgabe | Windows | Linux | macOS | |---|---|---|---| | TCP-Verbindungen | `[RO][PRIV] Get-NetTCPConnection` | `[RO][PRIV] ss -tanp` | `[RO] netstat -anv -p tcp` | | Verbindungen mit PID | `[RO][PRIV] Get-NetTCPConnection \| Select-Object LocalAddress,LocalPort,RemoteAddress,RemotePort,State,OwningProcess` | `[RO][PRIV] ss -tanp` | `[RO][PRIV] lsof -nP -iTCP` | | Klassische Übersicht | `[RO][PRIV] netstat -ano` | `[RO] netstat -antp` sofern installiert | `[RO] netstat -anv -p tcp` | | Bestehende Verbindungen | `[RO] Get-NetTCPConnection -State Established` | `[RO][PRIV] ss -tanp state established` | `[RO][PRIV] lsof -nP -iTCP -sTCP:ESTABLISHED` |
23. UDP-Endpunkte | Windows | Linux | macOS | |---|---|---| | `[RO][PRIV] Get-NetUDPEndpoint` | `[RO][PRIV] ss -uanp` | `[RO] netstat -anv -p udp` | | `[RO][PRIV] netstat -ano -p udp` | `[RO][PRIV] lsof -nP -iUDP` | `[RO][PRIV] lsof -nP -iUDP` | UDP besitzt keinen TCP-Verbindungszustand wie `Established`. Ein offener UDP-Endpunkt bestätigt nicht, dass eine Anwendung antwortet.
24. TCP-Listener | Aufgabe | Windows | Linux | macOS | |---|---|---|---| | Alle Listener | `[RO][PRIV] Get-NetTCPConnection -State Listen` | `[RO][PRIV] ss -lntp` | `[RO][PRIV] lsof -nP -iTCP -sTCP:LISTEN` | | Bestimmter Port | `[RO][PRIV] Get-NetTCPConnection -State Listen -LocalPort ` | `[RO][PRIV] ss -lntp \| grep ":"` | `[RO][PRIV] lsof -nP -iTCP: -sTCP:LISTEN` | | PID zu Listener | Eigenschaft `OwningProcess` verwenden | Ausgabe von `ss -lntp` | Ausgabe von `lsof` | | Prozess zur PID | `[RO] Get-Process -Id ` | `[RO] ps -p -o pid,user,command` | `[RO] ps -p -o pid,user,command` | Ein Listener bestätigt nur, dass ein Prozess den Port gebunden hat. Die Anwendung kann intern trotzdem fehlerhaft sein.
25. ICMP-Erreichbarkeit | Aufgabe | Windows | Linux | macOS | |---|---|---|---| | Vier Ping-Versuche | `[TEST] ping -n 4 ` | `[TEST] ping -c 4 ` | `[TEST] ping -c 4 ` | | Zehn Versuche | `[TEST] ping -n 10 ` | `[TEST] ping -c 10 ` | `[TEST] ping -c 10 ` | | PowerShell-Test | `[TEST] Test-Connection -ComputerName -Count 4` | PowerShell nur wenn installiert | PowerShell nur wenn installiert | Ein fehlgeschlagener Ping beweist keinen Serverausfall. ICMP kann blockiert sein, während TCP- oder UDP-Dienste funktionieren.
26. TCP-Port testen | Windows | Linux | macOS | |---|---|---| | `[TEST] Test-NetConnection -Port -InformationLevel Detailed` | `[TEST] nc -vz -w 3 ` | `[TEST] nc -vz -w 3 ` | | `[TEST] Test-NetConnection -Port -InformationLevel Quiet` | `nc` verwenden | `nc` verwenden | **Windows-Auswertung** Besonders relevantes Feld: `TcpTestSucceeded` **Interpretation** | Ergebnis | Mögliche Bedeutung | |---|---| | Verbindung erfolgreich | Netzwerkpfad und TCP-Listener grundsätzlich erreichbar | | Connection refused | Ziel erreichbar, aber kein Listener oder aktive Ablehnung | | Timeout | Filterung, Routing, Überlastung oder nicht antwortendes Ziel | | Name nicht auflösbar | DNS zuerst prüfen | | Nur ein Client betroffen | lokales System, lokales Netz oder lokale Sicherheitssoftware | | Nur ein VLAN betroffen | ACL, Routing, Firewall oder VLAN-Konfiguration |
27. Netzwerkpfad verfolgen | Windows | Linux | macOS | |---|---|---| | `[TEST] tracert ` | `[TEST] tracepath ` | `[TEST] traceroute ` | | `[TEST] Test-NetConnection -TraceRoute` | `[TEST] traceroute ` sofern installiert | `[TEST] traceroute ` | Sternchen bedeuten nicht automatisch einen Fehler. Router können Traceroute-Anfragen ignorieren und Nutzverkehr trotzdem weiterleiten.
28. Lokalen und entfernten Dienst vergleichen | Testpunkt | Windows | Linux | macOS | |---|---|---|---| | localhost | `[TEST] Test-NetConnection localhost -Port ` | `[TEST] nc -vz -w 3 localhost ` | `[TEST] nc -vz -w 3 localhost ` | | eigene IP | `[TEST] Test-NetConnection -Port ` | `[TEST] nc -vz -w 3 ` | `[TEST] nc -vz -w 3 ` | | Servername | `[TEST] Test-NetConnection -Port ` | `[TEST] nc -vz -w 3 ` | `[TEST] nc -vz -w 3 ` | **Interpretation** | localhost | Eigene IP | Remote | Möglicher Fehlerbereich | |---|---|---|---| | erfolgreich | erfolgreich | fehlgeschlagen | Netzwerkpfad oder Firewall | | erfolgreich | fehlgeschlagen | fehlgeschlagen | Bindung oder lokale Firewall | | fehlgeschlagen | fehlgeschlagen | fehlgeschlagen | Dienst oder Anwendung | | erfolgreich | erfolgreich | erfolgreich | Transportebene funktioniert |
29. HTTP- und HTTPS-Test | Aufgabe | Windows | Linux | macOS | |---|---|---|---| | Ausführlicher Test | `[TEST] curl.exe -v -o NUL https:///` | `[TEST] curl -v -o /dev/null https:///` | `[TEST] curl -v -o /dev/null https:///` | | Nur Header | `[TEST] curl.exe -vI https:///` | `[TEST] curl -vI https:///` | `[TEST] curl -vI https:///` | | Zeitbegrenzung | `[TEST] curl.exe --connect-timeout 5 --max-time 15 https:///` | `[TEST] curl --connect-timeout 5 --max-time 15 https:///` | `[TEST] curl --connect-timeout 5 --max-time 15 https:///` | | HTTP-Fehler als curl-Fehler | `[TEST] curl.exe --fail https:///` | `[TEST] curl --fail https:///` | `[TEST] curl --fail https:///` | Einige Server unterstützen die HTTP-Methode `HEAD` nicht korrekt. Ein fehlgeschlagener `curl -I`-Test sollte daher mit einem normalen GET-Test verglichen werden.
30. HTTP-Zeiten messen **Windows PowerShell** `[TEST] curl.exe -sS -o NUL -w 'code=%{http_code} remote=%{remote_ip} dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} first_byte=%{time_starttransfer} total=%{time_total}\n' --connect-timeout 5 --max-time 15 https:///` **Linux und macOS** `[TEST] curl -sS -o /dev/null -w "code=%{http_code} remote=%{remote_ip} dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} first_byte=%{time_starttransfer} total=%{time_total}\n" --connect-timeout 5 --max-time 15 https:///` | Wert | Bedeutung | |---|---| | `http_code` | HTTP-Status | | `remote_ip` | verwendete Ziel-IP | | `time_namelookup` | Dauer der Namensauflösung | | `time_connect` | Dauer bis TCP-Verbindungsaufbau | | `time_appconnect` | Dauer bis TLS-Verbindungsaufbau | | `time_starttransfer` | Dauer bis zum ersten Byte | | `time_total` | Gesamtzeit |
31. Bestimmtes HTTPS-Ziel ohne DNS-Änderung testen | Windows | Linux | macOS | |---|---|---| | `[TEST] curl.exe --resolve ":443:" -v -o NUL https:///` | `[TEST] curl --resolve ":443:" -v -o /dev/null https:///` | `[TEST] curl --resolve ":443:" -v -o /dev/null https:///` | `--resolve` behält für diesen curl-Aufruf: - Hostname, - HTTP-Host-Header, - TLS-SNI, - Zertifikatsprüfung. Nur die Ziel-IP wird vorgegeben.
32. TLS prüfen | Aufgabe | Windows | Linux | macOS | |---|---|---|---| | TLS-Verbindung | `[TEST] openssl s_client -connect :443 -servername -showcerts` sofern OpenSSL installiert | `[TEST] openssl s_client -connect :443 -servername -showcerts :443 -servername -showcerts " -noout -text` | `[RO] openssl x509 -in "" -noout -text` | `[RO] openssl x509 -in "" -noout -text` | **Zu prüfen** - Gültigkeitszeitraum, - Hostname und Subject Alternative Names, - Aussteller, - Zertifikatskette, - TLS-Version, - Cipher Suite, - Verifikationsergebnis.
33. HTTP-Status schnell interpretieren | Status | Typische Bedeutung | |---:|---| | 200 | Anfrage erfolgreich | | 301 oder 302 | Weiterleitung | | 400 | ungültige Anfrage | | 401 | Authentifizierung erforderlich oder fehlgeschlagen | | 403 | Zugriff verweigert | | 404 | Ressource oder Pfad nicht gefunden | | 408 | Anfrage-Timeout | | 429 | zu viele Anfragen oder Rate Limit | | 500 | interner Anwendungsfehler | | 502 | Proxy oder Gateway erhält ungültige Backend-Antwort | | 503 | Dienst oder Backend nicht verfügbar | | 504 | Proxy oder Gateway wartet vergeblich auf Backend | | 000 bei curl | keine gültige HTTP-Antwort empfangen | Die genaue Bedeutung kann durch die Anwendung erweitert oder verändert werden.
34. Windows-Ereignisprotokolle | Aufgabe | Befehl | |---|---| | Systemprotokoll | `[RO] Get-WinEvent -LogName "System" -MaxEvents 100` | | Anwendungsprotokoll | `[RO] Get-WinEvent -LogName "Application" -MaxEvents 100` | | Warnungen und Fehler | `[RO] Get-WinEvent -FilterHashtable @{LogName="System"; Level=2,3; StartTime=(Get-Date).AddHours(-1)}` | | Kritische Fehler und Fehler | `[RO] Get-WinEvent -FilterHashtable @{LogName="System"; Level=1,2; StartTime=(Get-Date).AddHours(-1)}` | | Zeitfenster | `[RO] Get-WinEvent -FilterHashtable @{LogName="System"; StartTime=[datetime]"2026-07-30 14:00:00"; EndTime=[datetime]"2026-07-30 15:00:00"}` | | Ereignis-ID | `[RO] Get-WinEvent -FilterHashtable @{LogName="System"; Id=; StartTime=(Get-Date).AddHours(-1)}` | | Anbieter | `[RO] Get-WinEvent -FilterHashtable @{LogName="System"; ProviderName=""; StartTime=(Get-Date).AddHours(-1)}` | | Übersicht | `[RO] Get-WinEvent -LogName "System" -MaxEvents 100 \| Select-Object TimeCreated,Id,ProviderName,LevelDisplayName,Message` | **Windows-Ereignisstufen** | Level | Bedeutung | |---:|---| | 1 | Kritisch | | 2 | Fehler | | 3 | Warnung | | 4 | Information | | 5 | Ausführlich |
35. Windows-Dienstereignisse | Ereignis-ID | Typische Bedeutung | |---:|---| | 7031 | Dienst wurde unerwartet beendet | | 7034 | Dienst wurde unerwartet beendet | | 7036 | Dienstzustand wurde geändert | | 7040 | Starttyp wurde geändert | | 7045 | neuer Dienst wurde installiert | **Abfrage** `[RO] Get-WinEvent -FilterHashtable @{LogName="System"; ProviderName="Service Control Manager"; Id=7031,7034,7036,7040,7045; StartTime=(Get-Date).AddHours(-1)} | Select-Object TimeCreated,Id,Message`
36. Windows-Ereignisprotokolle exportieren | Protokoll | Befehl | |---|---| | System | `[FILE][PRIV] wevtutil epl System "\System.evtx"` | | Application | `[FILE][PRIV] wevtutil epl Application "\Application.evtx"` | | Security | `[FILE][PRIV][SENSITIV] wevtutil epl Security "\Security.evtx"` | | PowerShell Operational | `[FILE][PRIV][SENSITIV] wevtutil epl "Microsoft-Windows-PowerShell/Operational" "\PowerShell-Operational.evtx"` | Vor dem Export sollte ein neuer Zielordner verwendet werden. Vorhandene Dateien dürfen nicht unkontrolliert überschrieben werden.
37. Linux-Journal | Aufgabe | Befehl | |---|---| | Aktueller Boot | `[RO] journalctl -b` | | Vorheriger Boot | `[RO] journalctl -b -1` | | Letzte Stunde | `[RO] journalctl --since "1 hour ago"` | | Zeitfenster | `[RO] journalctl --since "2026-07-30 14:00:00" --until "2026-07-30 15:00:00"` | | Bestimmter Dienst | `[RO] journalctl -u .service --since "1 hour ago"` | | Kernelmeldungen | `[RO] journalctl -k -b` | | Warnungen und schwerer | `[RO] journalctl -p warning --since "1 hour ago"` | | Nur Fehler | `[RO] journalctl -p err --since "1 hour ago"` | | ISO-Zeitstempel | `[RO] journalctl -o short-iso-precise --since "1 hour ago"` | | Ohne Pager | `[RO] journalctl --since "1 hour ago" --no-pager` | | Klassische Kernelmeldungen | `[RO][PRIV] dmesg --ctime` |
38. Linux-Journal exportieren | Aufgabe | Befehl | |---|---| | Aktueller Boot | `[FILE] journalctl -b --no-pager --output=short-iso-precise > "/journal-current-boot.log"` | | Vorheriger Boot | `[FILE] journalctl -b -1 --no-pager --output=short-iso-precise > "/journal-previous-boot.log"` | | Zeitfenster | `[FILE] journalctl --since "2026-07-30 14:00:00" --until "2026-07-30 15:00:00" --no-pager --output=short-iso-precise > "/journal-time-window.log"` | | Dienst | `[FILE] journalctl -u .service --since "1 hour ago" --no-pager --output=short-iso-precise > "/.log"` | | Kernelmeldungen | `[FILE][PRIV] dmesg --ctime > "/dmesg.log"` | Die Umleitung mit `>` überschreibt eine vorhandene Datei. Deshalb sollte ein neuer Zielordner verwendet werden.
39. macOS Unified Log | Aufgabe | Befehl | |---|---| | Letzte Stunde | `[RO][SENSITIV] log show --last 1h --style compact` | | Zeitfenster | `[RO][SENSITIV] log show --start "2026-07-30 14:00:00" --end "2026-07-30 15:00:00" --style compact` | | Fehler und Faults | `[RO][SENSITIV] log show --last 1h --predicate 'messageType == error OR messageType == fault' --style compact` | | Bestimmter Prozess | `[RO][SENSITIV] log show --last 1h --predicate 'process == ""' --style compact` | | Prozessfehler | `[RO][SENSITIV] log show --last 1h --predicate 'process == "" AND (messageType == error OR messageType == fault)' --style compact` | | Live-Ansicht | `[RO][SENSITIV] log stream --style compact` | **Export** `[FILE][SENSITIV] log show --last 1h --style compact > "/macOS-unified-log.txt"` **Grafische Werkzeuge** - Konsole - Aktivitätsanzeige → Weitere Optionen → Systemdiagnose
40. Windows-Updates und Installationsverlauf | Aufgabe | Befehl | |---|---| | Installierte Hotfixes | `[RO] Get-HotFix \| Sort-Object InstalledOn -Descending` | | Hotfixdetails | `[RO] Get-HotFix \| Select-Object InstalledOn,HotFixID,Description,InstalledBy` | | Updateereignisse | `[RO] Get-WinEvent -LogName "Microsoft-Windows-WindowsUpdateClient/Operational" -MaxEvents 100` | | Updateereignisse im Zeitfenster | `[RO] Get-WinEvent -FilterHashtable @{LogName="Microsoft-Windows-WindowsUpdateClient/Operational"; StartTime=[datetime]"2026-07-30 14:00:00"; EndTime=[datetime]"2026-07-30 15:00:00"}` | | Lesbare Updateprotokolldatei | `[FILE] Get-WindowsUpdateLog -LogPath "\WindowsUpdate.log"` | `Get-HotFix` zeigt nicht zwingend jede Aktualisierung. Zusätzlich sollten Windows-Updateverlauf und Patchmanagement geprüft werden.
41. Linux-Paketverlauf | Distribution | Aufgabe | Befehl | |---|---|---| | Debian/Ubuntu | APT-Verlauf | `[RO] less /var/log/apt/history.log` | | Debian/Ubuntu | DPKG-Verlauf | `[RO] less /var/log/dpkg.log` | | Debian/Ubuntu | Paketänderungen | `[RO] grep -E " install \| upgrade \| remove " /var/log/dpkg.log` | | Debian/Ubuntu | rotierte Logs | `[RO] zgrep -hE " install \| upgrade \| remove " /var/log/dpkg.log*` | | RHEL/Rocky/Alma/Fedora | DNF-Verlauf | `[RO] dnf history list` | | RHEL/Rocky/Alma/Fedora | Transaktionsdetails | `[RO] dnf history info ` | | RHEL/Rocky/Alma/Fedora | letzte Transaktion | `[RO] dnf history info last` | | RPM-basiert | Pakete nach Installationszeit | `[RO] rpm -qa --last` | | SUSE/openSUSE | Zypper-Verlauf | `[RO] less /var/log/zypp/history` | | Arch Linux | Pacman-Verlauf | `[RO] less /var/log/pacman.log` | | Arch Linux | Änderungen filtern | `[RO] grep -E "\[ALPM\] (installed\|upgraded\|removed)" /var/log/pacman.log` |
42. macOS-Installationsverlauf | Aufgabe | Befehl | |---|---| | Softwareupdateverlauf | `[RO] softwareupdate --history` | | Installationsverlauf | `[RO] system_profiler SPInstallHistoryDataType` | | Installierte Anwendungen | `[RO] system_profiler SPApplicationsDataType` | Grafischer Weg: `Systeminformationen → Software → Installationen`
43. Geplante Aufgaben und Automatisierung | Aufgabe | Windows | Linux | macOS | |---|---|---|---| | Geplante Aufgaben | `[RO] Get-ScheduledTask` | `[RO] crontab -l` | `[RO] launchctl list` | | Laufzeitinformationen | `[RO] Get-ScheduledTask \| Get-ScheduledTaskInfo \| Sort-Object LastRunTime -Descending` | `[RO] systemctl list-timers --all` | `[RO] launchctl list` | | Auffällige Ergebnisse | `[RO] Get-ScheduledTask \| Get-ScheduledTaskInfo \| Where-Object LastTaskResult -ne 0` | Cron- und Dienstprotokolle prüfen | Unified Log prüfen | | Task-Scheduler-Protokoll | `[RO] Get-WinEvent -LogName "Microsoft-Windows-TaskScheduler/Operational" -MaxEvents 100` | Nicht zutreffend | Nicht zutreffend | | Systemweite Cronjobs | Nicht zutreffend | `[RO] ls -la /etc/cron.d /etc/cron.hourly /etc/cron.daily /etc/cron.weekly /etc/cron.monthly` | Nicht zutreffend | | Debian/Ubuntu-Cronlog | Nicht zutreffend | `[RO] journalctl -u cron --since "1 hour ago"` | Nicht zutreffend | | RHEL-Cronlog | Nicht zutreffend | `[RO] journalctl -u crond --since "1 hour ago"` | Nicht zutreffend | | LaunchDaemons | Nicht zutreffend | Nicht zutreffend | `[RO] ls -la /Library/LaunchDaemons` | | Systemweite LaunchAgents | Nicht zutreffend | Nicht zutreffend | `[RO] ls -la /Library/LaunchAgents` | | Benutzer-LaunchAgents | Nicht zutreffend | Nicht zutreffend | `[RO] ls -la ~/Library/LaunchAgents` | Ein von `0` abweichendes Task-Ergebnis muss anhand der jeweiligen Aufgabe interpretiert werden.
44. Dateiinformationen | Aufgabe | Windows | Linux | macOS | |---|---|---|---| | Dateiinformationen | `[RO] Get-Item "" \| Select-Object FullName,Length,CreationTime,LastWriteTime` | `[RO] stat ""` | `[RO] stat -x ""` | | Dateityp | Erweiterung und Anwendung prüfen | `[RO] file ""` | `[RO] file ""` | | Programmversion | `[RO] (Get-Item "").VersionInfo` | Paketmanager oder `--version` | `--version` oder Systeminformationen | | Dateiinhalt | `[RO] Get-Content ""` | `[RO] less ""` | `[RO] less ""` | | Rohinhalt | `[RO] Get-Content "" -Raw` | `[RO] cat ""` | `[RO] cat ""` | Bei großen oder binären Dateien sollte nicht der gesamte Inhalt unkontrolliert ausgegeben werden.
45. Dateien und Konfigurationen vergleichen | Aufgabe | Windows | Linux | macOS | |---|---|---|---| | Textdateien vergleichen | `[RO] Compare-Object (Get-Content "") (Get-Content "")` | `[RO] diff -u "" ""` | `[RO] diff -u "" ""` | | Binäre Gleichheit | `[RO] Get-FileHash "" -Algorithm SHA256` | `[RO] sha256sum ""` | `[RO] shasum -a 256 ""` | | Git-Arbeitszustand | `[RO] git status` | `[RO] git status` | `[RO] git status` | | Git-Änderungen | `[RO] git diff` | `[RO] git diff` | `[RO] git diff` | | Letzte Commits | `[RO] git log --oneline --decorate -n 20` | `[RO] git log --oneline --decorate -n 20` | `[RO] git log --oneline --decorate -n 20` | | Verlauf einer Datei | `[RO] git log -p -- ""` | `[RO] git log -p -- ""` | `[RO] git log -p -- ""` |
46. Prüfsummen | Aufgabe | Windows | Linux | macOS | |---|---|---|---| | SHA-256 einer Datei | `[RO] Get-FileHash "" -Algorithm SHA256` | `[RO] sha256sum ""` | `[RO] shasum -a 256 ""` | | Prüfsumme prüfen | neu berechnen und vergleichen | `[RO] sha256sum -c ""` | `[RO] shasum -a 256 -c ""` | | Ordner-Manifest | `[FILE] Get-ChildItem "" -File -Recurse \| Get-FileHash -Algorithm SHA256 \| Export-Csv "-SHA256.csv" -NoTypeInformation -Encoding UTF8` | `[FILE] (cd "" && find . -type f -print0 \| sort -z \| xargs -0 -r sha256sum) > "-SHA256SUMS.txt"` | `[FILE] find "" -type f -exec shasum -a 256 {} \; > "-SHA256SUMS.txt"` | Eine Prüfsumme dokumentiert die Dateiintegrität ab dem Zeitpunkt ihrer Berechnung, aber nicht automatisch Herkunft oder Authentizität.
47. Dateiberechtigungen | Aufgabe | Windows | Linux | macOS | |---|---|---|---| | ACL anzeigen | `[RO][SENSITIV] Get-Acl "" \| Format-List` | `[RO][SENSITIV] getfacl ""` | `[RO][SENSITIV] ls -lde ""` | | Klassische Ansicht | `[RO][SENSITIV] icacls ""` | `[RO] ls -ld ""` | `[RO] ls -lde ""` | | Benutzergruppen | `[RO][SENSITIV] whoami /all` | `[RO] id ` | `[RO] id ` | | Vollständigen Pfad prüfen | Pfadabschnitte mit `Get-Acl` prüfen | `[RO] namei -l ""` | Pfadabschnitte mit `ls -lde` prüfen | | Besitzer und Gruppe | `[RO] Get-Acl "" \| Select-Object Owner` | `[RO] stat ""` | `[RO] stat -x ""` |
48. Active Directory und Gruppenrichtlinien | Aufgabe | Windows | |---|---| | Benutzer- und Gruppeninformationen | `[RO][SENSITIV] whoami /all` | | Resultierende Richtlinien kompakt | `[RO] gpresult /r` | | HTML-Bericht | `[FILE] gpresult /h "\gpresult.html"` | | Gruppenrichtlinienprotokoll | `[RO] Get-WinEvent -LogName "Microsoft-Windows-GroupPolicy/Operational" -MaxEvents 100` | | Sicheren Domänenkanal prüfen | `[TEST] Test-ComputerSecureChannel -Verbose` | | Bestimmten Domänencontroller prüfen | `[TEST] Test-ComputerSecureChannel -Server "" -Verbose` | | Sicherheitsereignisse | `[RO][PRIV][SENSITIV] Get-WinEvent -LogName "Security" -MaxEvents 100` | `Test-ComputerSecureChannel` ist für Domänenmitgliedscomputer vorgesehen. Der Parameter `-Repair` wäre eine Änderung und ist kein reiner Test.
49. Konfigurationssyntax prüfen | Format oder Dienst | Windows | Linux | macOS | |---|---|---|---| | JSON mit PowerShell | `[TEST] Get-Content "" -Raw \| ConvertFrom-Json \| Out-Null` | PowerShell nur wenn installiert | PowerShell nur wenn installiert | | JSON mit Python | `[TEST] python3 -m json.tool "" > NUL` | `[TEST] python3 -m json.tool "" > /dev/null` | `[TEST] python3 -m json.tool "" > /dev/null` | | JSON mit jq | `[TEST] jq empty ""` | `[TEST] jq empty ""` | `[TEST] jq empty ""` | | Property List | Nicht zutreffend | Nicht zutreffend | `[TEST] plutil -lint ""` | | systemd-Unit | Nicht zutreffend | `[TEST] systemd-analyze verify ""` | Nicht zutreffend | | NGINX | `[TEST][PRIV] nginx -t` sofern installiert | `[TEST][PRIV] nginx -t` | `[TEST][PRIV] nginx -t` sofern installiert | | Apache | installationsabhängig | `[TEST][PRIV] apachectl configtest` | `[TEST][PRIV] apachectl configtest` | | OpenSSH-Server | `[TEST][PRIV] sshd -t` sofern installiert | `[TEST][PRIV] sshd -t` | `[TEST][PRIV] sshd -t` | Ein erfolgreicher Syntax-Test bestätigt nicht, dass Netzwerkziele, Zertifikate, Berechtigungen und Abhängigkeiten funktionieren.
50. Terminal- und Diagnosesitzung protokollieren | Aufgabe | Windows PowerShell | Linux | macOS | |---|---|---|---| | Aufzeichnung starten | `[FILE][SENSITIV] Start-Transcript -Path "\Testprotokoll.txt" -IncludeInvocationHeader -NoClobber` | `[FILE][SENSITIV] script "/Testprotokoll.txt"` | `[FILE][SENSITIV] script "/Testprotokoll.txt"` | | Aufzeichnung beenden | `[FILE] Stop-Transcript` | `exit` oder `Strg + D` | `exit` oder `Strg + D` | | Anzeigen und speichern | `[FILE] \| Tee-Object -FilePath "\Ausgabe.txt"` | `[FILE] 2>&1 \| tee "/Ausgabe.txt"` | `[FILE] 2>&1 \| tee "/Ausgabe.txt"` | | Ausgabe und Fehler speichern | `[FILE] *> "\Ausgabe.txt"` | `[FILE] > "/Ausgabe.txt" 2>&1` | `[FILE] > "/Ausgabe.txt" 2>&1` | Transkripte können Benutzernamen, Pfade und andere sensible Informationen enthalten.
51. Rückgabewerte prüfen | Plattform | Befehl | Bedeutung | |---|---|---| | PowerShell-Cmdlet | `[RO] $?` | Erfolg der vorherigen PowerShell-Operation | | PowerShell mit externem Programm | `[RO] $LASTEXITCODE` | Exit-Code des letzten nativen Programms | | Windows CMD | `[RO] echo %ERRORLEVEL%` | Exit-Code des letzten Programms | | Linux | `[RO] echo $?` | Exit-Code des letzten Befehls | | macOS | `[RO] echo $?` | Exit-Code des letzten Befehls | Der Wert muss unmittelbar nach dem betreffenden Befehl gesichert werden. Ein Exit-Code `0` bedeutet nur, dass das Werkzeug Erfolg meldet. Die Benutzer- oder Anwendungsfunktion kann trotzdem fehlschlagen.
52. Werkzeugversionen | Aufgabe | Windows | Linux | macOS | |---|---|---|---| | PowerShell-Version | `[RO] $PSVersionTable` | `[RO] pwsh -Version` sofern installiert | `[RO] pwsh -Version` sofern installiert | | curl-Version | `[RO] curl.exe --version` | `[RO] curl --version` | `[RO] curl --version` | | OpenSSL-Version | `[RO] openssl version -a` | `[RO] openssl version -a` | `[RO] openssl version -a` | | Git-Version | `[RO] git --version` | `[RO] git --version` | `[RO] git --version` | | Python-Version | `[RO] python --version` oder `python3 --version` | `[RO] python3 --version` | `[RO] python3 --version` | Unterschiedliche Versionen können verschiedene Optionen, Protokolle oder Standardwerte verwenden.
53. Paketaufzeichnung > Paketaufzeichnungen können vertrauliche Nutzdaten, Hostnamen, IP-Adressen und Sitzungsinformationen enthalten. Berechtigung, Speicherort, Zeitraum und Datenschutz müssen vorher geklärt sein. **Windows mit pktmon** | Aufgabe | Befehl | |---|---| | Aufzeichnung starten | `[FILE][TEST][PRIV][SENSITIV] pktmon start --capture --pkt-size 0 --file-name "\capture.etl"` | | Aufzeichnung beenden | `[TEST][PRIV] pktmon stop` | | In PCAPNG umwandeln | `[FILE][SENSITIV] pktmon etl2pcap "\capture.etl" --out "\capture.pcapng"` | **Linux mit tcpdump** `[FILE][TEST][PRIV][SENSITIV] sudo tcpdump -i any -nn -s 0 -w "/capture.pcap"` **macOS mit tcpdump** `[FILE][TEST][PRIV][SENSITIV] sudo tcpdump -i -nn -s 0 -w "/capture.pcap"` Beenden mit `Strg + C`.
54. Dienständerungen – nur nach Sicherung und Freigabe > Die folgenden Befehle verändern den Betriebszustand und gehören nicht an den Anfang der Diagnose. | Aufgabe | Windows | Linux | macOS | |---|---|---|---| | Neustart nur anzeigen | `[TEST] Restart-Service -Name -WhatIf` | keine vollständige systemctl-Simulation | keine vollständige launchctl-Simulation | | Dienst starten | `[CHANGE][PRIV] Start-Service -Name -Confirm` | `[CHANGE][PRIV] sudo systemctl start .service` | `[CHANGE][PRIV] sudo launchctl kickstart system/` | | Konfiguration neu laden | anwendungsspezifisch | `[CHANGE][PRIV] sudo systemctl reload .service` | anwendungsspezifisch | | Dienst neu starten | `[CHANGE][DISRUPTIV][PRIV] Restart-Service -Name -Confirm` | `[CHANGE][DISRUPTIV][PRIV] sudo systemctl restart .service` | `[CHANGE][DISRUPTIV][PRIV] sudo launchctl kickstart -k system/` | | Nur laufenden Dienst neu starten | Status vorher prüfen | `[CHANGE][DISRUPTIV][PRIV] sudo systemctl try-restart .service` | Status vorher prüfen | | Zustand danach | `[RO] Get-Service -Name ` | `[RO] systemctl status .service --no-pager` | `[RO][PRIV] launchctl print system/` | Ein Reload funktioniert nur, wenn der jeweilige Dienst diese Funktion unterstützt.
55. Konfigurationsdatei sichern **Windows** $backupFile = Join-Path "" "config-$(Get-Date -Format 'yyyyMMdd-HHmmss').bak" Copy-Item "" $backupFile Get-FileHash -Path "", $backupFile -Algorithm SHA256 **Linux** backup_file="/config-$(date +%Y%m%d-%H%M%S).bak" cp --preserve=all -- "" "$backup_file" sha256sum "" "$backup_file" **macOS** backup_file="/config-$(date +%Y%m%d-%H%M%S).bak" cp -p "" "$backup_file" shasum -a 256 "" "$backup_file" Für komplexe Anwendungen, Datenbanken, Verzeichnisdienste und Cluster muss die vorgesehene Backup- oder Exportfunktion verwendet werden.
56. Einfache Konfigurationsdatei zurückspielen > Nur verwenden, wenn Sicherung, Dateirechte, Besitzer, Metadaten und Anwendungsvorgaben geprüft wurden. | Windows | Linux | macOS | |---|---|---| | `[CHANGE][PRIV] Copy-Item "" "" -Force` | `[CHANGE][PRIV] sudo cp --preserve=all -- "" ""` | `[CHANGE][PRIV] sudo cp -p "" ""` | Danach prüfen: - Inhalt, - Prüfsumme, - Besitzer, - Gruppe, - Berechtigungen, - ACL, - Syntax, - Dienststatus, - Benutzerfunktion.
57. Häufige Ergebniskombinationen | Beobachtung | Wahrscheinlicher Prüfbereich | |---|---| | Zugriff per IP funktioniert, per Name nicht | DNS, Hosts-Datei oder Suchdomäne | | DNS liefert unterschiedliche IPs | Split-DNS, Load Balancing oder Cache | | Ping scheitert, TCP funktioniert | ICMP wahrscheinlich blockiert | | Ping funktioniert, TCP scheitert | Port, Listener oder Firewall | | TCP erfolgreich, TLS scheitert | Zertifikat, TLS-Version, Cipher oder SNI | | TLS erfolgreich, HTTP 500 | Anwendung oder Backend | | HTTP 401 | Authentifizierung | | HTTP 403 | Autorisierung oder Sicherheitsrichtlinie | | HTTP 502 oder 504 | Proxy, Load Balancer oder Backend | | localhost funktioniert, Remotezugriff nicht | Listener-Bindung, Firewall oder Netzwerkpfad | | localhost funktioniert nicht | Dienst oder Anwendung | | nur ein Benutzer betroffen | Konto, Rolle, Berechtigung oder Profil | | nur ein Client betroffen | Clientkonfiguration, lokaler Dienst oder Sicherheitssoftware | | nur ein VLAN betroffen | VLAN, ACL, Routing, DHCP oder Gateway | | alle Clients betroffen | Server, Dienst oder gemeinsame Abhängigkeit | | Dienststatus „Running“, aber Port fehlt | Bindungs-, Konfigurations- oder Prozessproblem | | Port vorhanden, Anwendung antwortet nicht | Anwendung hängt oder Abhängigkeit fehlt | | Neustart behebt Fehler vorübergehend | Cache, Speicherleck, Prozesszustand oder Verbindung | | Datenträger frei, Schreiben scheitert | Inodes, Quota, Berechtigung oder Read-only-Mount |
58. Häufige Fehlermeldungen bei Netzwerkverbindungen | Meldung | Mögliche Bedeutung | |---|---| | Connection refused | Ziel erreichbar, aber kein Listener oder aktive Ablehnung | | Connection timed out | Paketverlust, Filterung, Routing oder nicht antwortendes Ziel | | No route to host | Route, Gateway, Interface oder Netz nicht erreichbar | | Network is unreachable | keine geeignete Route oder Schnittstelle | | Name or service not known | Namensauflösung fehlgeschlagen | | Temporary failure in name resolution | DNS-Server oder Resolver vorübergehend nicht verfügbar | | Hostname mismatch | Zertifikat passt nicht zum aufgerufenen Hostnamen | | Certificate expired | Zertifikat ist abgelaufen | | Permission denied | Dateirechte, ACL, Rolle oder Sicherheitsrichtlinie | | Address already in use | Port oder Socket bereits gebunden | | No space left on device | Speicherplatz oder Inodes erschöpft | | Too many open files | Datei- oder Prozesslimit erreicht |
59. Was vor einem Neustart gesichert werden sollte | Priorität | Information | |---:|---| | 1 | Fehlermeldung und Screenshot | | 2 | Uhrzeit und Zeitzone | | 3 | laufende Prozesse | | 4 | Dienstzustand | | 5 | aktive Netzwerkverbindungen | | 6 | Listener | | 7 | IP-Konfiguration und Routing | | 8 | ARP-, Neighbor- und DNS-Cache | | 9 | angemeldete Benutzer | | 10 | CPU-, RAM- und Datenträgerzustand | | 11 | aktuelle Protokolle | | 12 | letzte Änderungen | | 13 | Konfiguration und Prüfsummen |
60. Was nicht unüberlegt ausgeführt werden sollte | Maßnahme | Grund | |---|---| | Computer neu starten | flüchtige Informationen gehen verloren | | Dienst sofort neu starten | ursprünglicher Prozesszustand geht verloren | | Prozess beenden | Verbindungen, Speicher und offene Dateien verschwinden | | DNS-Cache leeren | diagnostisch relevante Cacheeinträge gehen verloren | | ARP-Tabelle leeren | Zuordnungen zwischen IP und MAC gehen verloren | | Protokolle löschen | Belege gehen verloren | | Firewall vollständig deaktivieren | Sicherheitsrisiko und unklarer Test | | Update installieren | Ausgangszustand wird verändert | | Konfiguration zurücksetzen | Fehlerursache ist schwerer nachvollziehbar | | Snapshot unkontrolliert zurückspielen | Daten- und Konsistenzrisiko | | mehrere Änderungen gleichzeitig | Wirkung kann nicht zugeordnet werden |
61. Minimaler Erstsnapshot – Windows | Aufgabe | Befehl | |---|---| | Zeit | `[RO] Get-Date -Format o` | | Betriebssystem | `[RO] Get-CimInstance Win32_OperatingSystem` | | letzter Start | `[RO] Get-CimInstance Win32_OperatingSystem \| Select-Object LastBootUpTime` | | Benutzer | `[RO][SENSITIV] whoami /all` | | Prozesse | `[RO][SENSITIV] Get-CimInstance Win32_Process \| Select-Object ProcessId,ParentProcessId,Name,CommandLine` | | Dienste | `[RO] Get-Service` | | IP-Konfiguration | `[RO] ipconfig /all` | | Routing | `[RO] route print` | | ARP | `[RO] arp -a` | | DNS-Cache | `[RO][SENSITIV] ipconfig /displaydns` | | TCP-Verbindungen | `[RO][PRIV] netstat -ano` | | Volumes | `[RO] Get-Volume` | | Fehlerprotokoll | `[RO] Get-WinEvent -FilterHashtable @{LogName="System"; Level=1,2; StartTime=(Get-Date).AddHours(-1)}` |
62. Minimaler Erstsnapshot – Linux | Aufgabe | Befehl | |---|---| | Zeit | `[RO] date --iso-8601=seconds` | | Betriebssystem | `[RO] cat /etc/os-release` | | Kernel | `[RO] uname -a` | | Betriebsdauer | `[RO] uptime` | | Benutzer | `[RO] who -a` | | Prozesse | `[RO][SENSITIV] ps auxww` | | Dienste | `[RO] systemctl --failed` | | IP-Konfiguration | `[RO] ip -details address show` | | Routing | `[RO] ip route show table all` | | Neighbor | `[RO] ip neigh show` | | DNS | `[RO] resolvectl status` | | Sockets | `[RO][PRIV] ss -tulpn` | | Speicher | `[RO] free -h` | | Dateisysteme | `[RO] df -hT` | | Journal | `[RO] journalctl -b -p warning --no-pager` | | Kernelmeldungen | `[RO][PRIV] dmesg --ctime` |
63. Minimaler Erstsnapshot – macOS | Aufgabe | Befehl | |---|---| | Zeit | `[RO] date "+%Y-%m-%dT%H:%M:%S%z"` | | Betriebssystem | `[RO] sw_vers` | | Kernel | `[RO] uname -a` | | Betriebsdauer | `[RO] uptime` | | Benutzer | `[RO] who` | | Prozesse | `[RO][SENSITIV] ps auxww` | | Dienste | `[RO] launchctl list` | | IP-Konfiguration | `[RO] ifconfig -a` | | Routing | `[RO] netstat -rn` | | ARP | `[RO] arp -an` | | DNS | `[RO][SENSITIV] scutil --dns` | | TCP-Verbindungen | `[RO] netstat -anv -p tcp` | | Speicher | `[RO] vm_stat` | | Dateisysteme | `[RO] df -h` | | Protokollfehler | `[RO][SENSITIV] log show --last 1h --predicate 'messageType == error OR messageType == fault' --style compact` |
64. Abschlussprüfung nach einer Lösung | Ebene | Windows | Linux | macOS | |---|---|---|---| | Zeitpunkt | `Get-Date -Format o` | `date --iso-8601=seconds` | `date "+%Y-%m-%dT%H:%M:%S%z"` | | Dienststatus | `Get-Service -Name ` | `systemctl status .service` | `launchctl print system/` | | Listener | `Get-NetTCPConnection -State Listen -LocalPort ` | `ss -lntp \| grep ":"` | `lsof -nP -iTCP: -sTCP:LISTEN` | | TCP-Test | `Test-NetConnection -Port ` | `nc -vz -w 3 ` | `nc -vz -w 3 ` | | HTTP-Test | `curl.exe https:///` | `curl https:///` | `curl https:///` | | neue Fehler | `Get-WinEvent` | `journalctl` | `log show` | | Benutzerfunktion | ursprünglichen Ablauf wiederholen | ursprünglichen Ablauf wiederholen | ursprünglichen Ablauf wiederholen | | Sicherheit | unerlaubten Zugriff negativ testen | unerlaubten Zugriff negativ testen | unerlaubten Zugriff negativ testen | | Monitoring | zentrale Überwachung prüfen | zentrale Überwachung prüfen | zentrale Überwachung prüfen |
65. Wichtigste Regeln - Erst beobachten, dann verändern. - Fehlermeldung vollständig dokumentieren. - Uhrzeit und Zeitzone prüfen. - Betroffene und funktionierende Systeme vergleichen. - Ping nicht mit Dienstverfügbarkeit verwechseln. - TCP-Porttest nicht mit funktionierender Anwendung verwechseln. - Dienststatus `Running` nicht mit Dienstgesundheit verwechseln. - Zeitliche Korrelation nicht automatisch als Ursache behandeln. - Pro Test möglichst nur eine Variable verändern. - Erwartetes Ergebnis vor dem Test definieren. - Widersprechende Belege aktiv suchen. - Vor Neustart flüchtige Informationen sichern. - Vor Änderungen Konfiguration und Rückfallweg sichern. - Nach der Lösung denselben Test erneut ausführen. - Positive, negative und Regressionstests durchführen. - Workaround und dauerhafte Lösung getrennt dokumentieren. - Offene Maßnahmen mit Verantwortlichkeit und Termin versehen.
--- **Ergebnis dieser Seite** Diese Seite bildet die Schnellreferenz für Kapitel 1. Sie enthält die wichtigsten Befehle für: - Windows, - Linux, - macOS, - Systemzustand, - Prozesse und Dienste, - Netzwerk und DNS, - Routing und Verbindungen, - HTTP und TLS, - Protokolle, - Updates, - geplante Aufgaben, - Berechtigungen, - Konfigurationsvergleiche, - Beweissicherung, - Änderungen und Abschlussprüfungen. Damit ist **Kapitel 1 – Grundlagen der systematischen Fehleranalyse** abgeschlossen. ---
Offizielle Hersteller-, Standard- und Projektdokumentation - [Microsoft Learn – PowerShell-Dokumentation](https://learn.microsoft.com/en-us/powershell/) - [Microsoft Learn – Test-NetConnection](https://learn.microsoft.com/en-us/powershell/module/nettcpip/test-netconnection) - [Microsoft Learn – Resolve-DnsName](https://learn.microsoft.com/en-us/powershell/module/dnsclient/resolve-dnsname) - [Microsoft Learn – Get-WinEvent](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.diagnostics/get-winevent) - [Microsoft Learn – wevtutil](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/wevtutil) - [Microsoft Learn – Get-Service](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.management/get-service) - [Microsoft Learn – Restart-Service](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.management/restart-service) - [Microsoft Learn – Get-FileHash](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.utility/get-filehash) - [Microsoft Learn – Start-Transcript](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.host/start-transcript) - [Microsoft Learn – Windows-Update-Protokolldateien](https://learn.microsoft.com/en-us/windows/deployment/update/windows-update-logs) - [Microsoft Learn – Packet Monitor](https://learn.microsoft.com/en-us/windows-server/networking/technologies/pktmon/pktmon) - [freedesktop.org – systemctl](https://www.freedesktop.org/software/systemd/man/latest/systemctl.html) - [freedesktop.org – journalctl](https://www.freedesktop.org/software/systemd/man/latest/journalctl.html) - [freedesktop.org – systemd-analyze](https://www.freedesktop.org/software/systemd/man/latest/systemd-analyze.html) - [Linux man-pages – ip(8)](https://man7.org/linux/man-pages/man8/ip.8.html) - [Linux man-pages – ss(8)](https://man7.org/linux/man-pages/man8/ss.8.html) - [Linux man-pages – script(1)](https://man7.org/linux/man-pages/man1/script.1.html) - [Apple Support – Protokollmeldungen in der Konsole](https://support.apple.com/guide/console/log-messages-cnsl1012/mac) - [Apple Support – Systemdiagnose in der Aktivitätsanzeige](https://support.apple.com/guide/activity-monitor/run-system-diagnostics-actmntr2225/mac) - [Apple Support – Scriptverwaltung mit launchd](https://support.apple.com/guide/terminal/script-management-with-launchd-apdc6c1077b/mac) - [Apple Support – Installationsverlauf anzeigen](https://support.apple.com/en-us/101591) - [curl – Offizielle Befehlsreferenz](https://curl.se/docs/manpage.html) - [OpenSSL – s_client](https://docs.openssl.org/master/man1/openssl-s_client/) - [RFC Editor – RFC 9110: HTTP Semantics](https://www.rfc-editor.org/rfc/rfc9110.html) - [RFC Editor – RFC 3227: Evidence Collection and Archiving](https://www.rfc-editor.org/rfc/rfc3227.html)
# 2. Grundwerkzeuge und Befehle # 2.0 Werkzeugwahl, Kennzeichnungen und sichere Anwendung **Ziel dieser Seite** Diese Seite erklärt, wie für eine konkrete Diagnosefrage das passende Werkzeug ausgewählt wird. Sie legt außerdem die Kennzeichnungen fest, die in diesem Kapitel vor den Befehlen verwendet werden. Die wichtigste Grundregel lautet: > Erst die Diagnosefrage formulieren, dann das Werkzeug auswählen und erst danach den Befehl ausführen. Ein Werkzeug ist ein Messinstrument. Es ersetzt weder eine Hypothese noch die Bewertung des Ergebnisses. --- **1. Grundhaltung bei der Werkzeugwahl** Administratoren sollten nicht möglichst viele Befehle ausführen, sondern mit möglichst wenigen, gezielten Prüfungen die Fehlerdomäne eingrenzen. Vor jedem Befehl werden deshalb fünf Fragen beantwortet: 1. Was möchte ich mit diesem Befehl feststellen? 2. Welches Ergebnis erwarte ich bei einem funktionierenden System? 3. Welches Ergebnis würde meine Hypothese widerlegen? 4. Kann der Befehl den Zustand des Systems verändern? 5. Welche Daten muss ich zusammen mit dem Ergebnis dokumentieren? Ein Befehl ohne konkrete Diagnosefrage erzeugt häufig nur zusätzliche Informationen, aber noch keine Erkenntnis. **Beispiel** Ungeeignete Fragestellung: > Ich führe erst einmal alle Netzwerkbefehle aus. Geeignete Fragestellung: > Ich möchte feststellen, über welches Interface und welches Gateway der Client das Ziel `192.0.2.25` erreichen würde. Dazu wird zunächst die Routingentscheidung geprüft. Ein Paketmitschnitt oder ein Portscan wäre zu diesem Zeitpunkt normalerweise noch nicht erforderlich. --- **2. Bedeutung der Kennzeichnungen** Die folgenden Kennzeichnungen stehen in diesem Buch vor Befehlen. Sie gehören nicht zum Befehl und dürfen nicht mit eingegeben werden. | Kennzeichnung | Bedeutung | Typische Auswirkung | |---|---|---| | `[RO]` | Read-only beziehungsweise nur lesende Abfrage | Liest Status oder Konfiguration aus, ohne sie absichtlich zu verändern | | `[TEST]` | Aktiver Diagnosetest | Sendet kontrollierte Anfragen oder Testpakete | | `[PRIV]` | Erhöhte Rechte erforderlich | Benötigt Administrator-, Root- oder vergleichbare Rechte | | `[FILE]` | Erzeugt oder exportiert eine Datei | Benötigt einen geeigneten und geschützten Ablageort | | `[SENS]` | Möglicherweise sensible Ausgabe | Kann interne Adressen, Namen, Benutzer-, Zertifikats- oder Nutzdaten enthalten | | `[LOAD]` | Erzeugt relevante Last oder Datenverkehr | Kann Bandbreite, CPU, Speicher oder einen Zielservice belasten | | `[CHANGE]` | Verändert Zustand oder Konfiguration | Erfordert Prüfung, Dokumentation und normalerweise einen Rückfallplan | | `[DISRUPT]` | Möglicherweise dienstunterbrechend | Darf nur mit geklärter Auswirkung und entsprechender Freigabe eingesetzt werden | Kennzeichnungen können kombiniert werden. Beispiele: ```text [RO] ip address # 2.1 Windows-Netzwerkbefehle **Ziel dieser Seite** Diese Seite enthält die wichtigsten klassischen Windows-Befehle für die praktische Netzwerkdiagnose. Sie behandelt vor allem Werkzeuge, die über die Eingabeaufforderung `cmd.exe` oder aus PowerShell heraus gestartet werden können. Die objektorientierten PowerShell-Cmdlets wie `Get-NetIPConfiguration`, `Get-NetRoute`, `Resolve-DnsName` und `Test-NetConnection` folgen auf der nächsten Seite. --- **1. Wichtige Hinweise zur Verwendung** Die Kennzeichnungen wie `[RO]`, `[TEST]` und `[CHANGE]` gehören nicht zum Befehl und dürfen nicht mit eingegeben werden. Die Beispiele verwenden reservierte Dokumentationsadressen und -namen: | Platzhalter | Bedeutung | |---|---| | `192.0.2.25` | Beispielhafte IPv4-Zieladresse | | `192.0.2.53` | Beispielhafter DNS-Server | | `server.example.test` | Beispielhafter vollständiger DNS-Name | | `example.test` | Beispielhafte DNS-Domäne | | `` | Durch echten Hostnamen oder echte IP-Adresse ersetzen | | `` | Durch den tatsächlichen Namen des Netzwerkadapters ersetzen | | `` | Durch eine ermittelte Prozess-ID ersetzen | | `` | Durch einen vorhandenen und geeigneten Speicherort ersetzen | Vor einer Veränderung sollten zuerst die `[RO]`-Befehle ausgeführt und deren Ergebnisse gesichert werden. --- **2. Schnellübersicht** | Aufgabe | Kennzeichnung | Befehl | |---|---|---| | Computername anzeigen | `[RO]` | `hostname` | | MAC-Adressen anzeigen | `[RO]` | `getmac /v` | | Grundlegende IP-Konfiguration | `[RO]` | `ipconfig` | | Vollständige IP-Konfiguration | `[RO][SENS]` | `ipconfig /all` | | DNS-Clientcache anzeigen | `[RO][SENS]` | `ipconfig /displaydns` | | DNS-Clientcache leeren | `[CHANGE]` | `ipconfig /flushdns` | | DHCP-Lease freigeben | `[CHANGE][DISRUPT]` | `ipconfig /release` | | DHCP-Lease erneuern | `[TEST][CHANGE]` | `ipconfig /renew` | | IPv4-Erreichbarkeit testen | `[TEST]` | `ping /4 ` | | IPv6-Erreichbarkeit testen | `[TEST]` | `ping /6 ` | | Netzwerkpfad anzeigen | `[TEST]` | `tracert /d ` | | Pfad und Paketverlust untersuchen | `[TEST]` | `pathping /n ` | | Routingtabelle anzeigen | `[RO]` | `route print` | | IPv4-ARP-Cache anzeigen | `[RO]` | `arp -a` | | DNS-Abfrage ausführen | `[TEST]` | `nslookup ` | | Bestimmten DNS-Server abfragen | `[TEST]` | `nslookup ` | | TCP-Verbindungen und Listener anzeigen | `[RO][SENS]` | `netstat -ano` | | Prozess zu einer PID ermitteln | `[RO]` | `tasklist /FI "PID eq "` | | Status der Netzwerkinterfaces | `[RO]` | `netsh interface show interface` | | IPv4-Nachbartabelle anzeigen | `[RO]` | `netsh interface ipv4 show neighbors` | | IPv6-Nachbartabelle anzeigen | `[RO]` | `netsh interface ipv6 show neighbors` | | WLAN-Verbindung anzeigen | `[RO][SENS]` | `netsh wlan show interfaces` | | Sichtbare WLANs anzeigen | `[TEST][SENS]` | `netsh wlan show networks mode=bssid` | | WLAN-Bericht erzeugen | `[FILE][SENS]` | `netsh wlan show wlanreport` | | WinHTTP-Proxy anzeigen | `[RO][SENS]` | `netsh winhttp show proxy` | | Firewallstatus anzeigen | `[RO]` | `netsh advfirewall show allprofiles state` | --- **3. Empfohlene Reihenfolge für eine erste Windows-Netzwerkdiagnose** | Schritt | Diagnosefrage | Befehl | |---:|---|---| | 1 | Auf welchem Computer wird getestet? | `hostname` | | 2 | Welche Netzwerkadapter sind vorhanden und aktiv? | `netsh interface show interface` | | 3 | Welche IP-, Gateway-, DHCP- und DNS-Konfiguration liegt vor? | `ipconfig /all` | | 4 | Funktioniert der lokale TCP/IP-Stack? | `ping 127.0.0.1` | | 5 | Ist das lokale Standardgateway erreichbar? | `ping ` | | 6 | Ist eine entfernte IP-Adresse erreichbar? | `ping /4 ` | | 7 | Funktioniert die Namensauflösung? | `nslookup ` | | 8 | Sind IP-Adresse und Name unterschiedlich betroffen? | `ping ` und `ping ` | | 9 | Welchen Weg nimmt der Datenverkehr? | `tracert /d ` | | 10 | Gibt es Hinweise auf Verlust oder starke Latenz? | `pathping /n ` | | 11 | Welche Route wird wahrscheinlich verwendet? | `route print` | | 12 | Existiert eine lokale Nachbarzuordnung? | `arp -a` | | 13 | Lauscht lokal ein Prozess auf dem erwarteten Port? | `netstat -ano` | | 14 | Welcher Prozess gehört zur gefundenen PID? | `tasklist /FI "PID eq "` | | 15 | Sind Proxy oder Windows-Firewall relevant? | `netsh winhttp show proxy` und `netsh advfirewall show currentprofile` | Diese Reihenfolge ist ein Ausgangspunkt. Sie wird an das konkrete Fehlerbild angepasst. --- **4. Computername und MAC-Adressen** **Computername anzeigen** Kennzeichnung: `[RO]` ```cmd hostname ``` Der Befehl zeigt den Hostnamenanteil des vollständigen Computernamens an. Das ist nützlich, um sicherzustellen, dass die Diagnose tatsächlich auf dem vorgesehenen System durchgeführt wird. **Computername über die Umgebungsvariable anzeigen** Kennzeichnung: `[RO]` ```cmd echo %COMPUTERNAME% ``` `%COMPUTERNAME%` zeigt üblicherweise denselben Computernamen in Großbuchstaben an. In Clusterumgebungen kann sich die Ausgabe von `hostname` jedoch durch die Variable `_CLUSTER_NETWORK_NAME_` unterscheiden. **MAC-Adressen und zugehörige Adapter anzeigen** Kennzeichnung: `[RO]` ```cmd getmac /v ``` Ausführliche Ausgabe als Liste: ```cmd getmac /v /fo list ``` Ausgabe als CSV: ```cmd getmac /v /fo csv ``` Wichtige Felder: | Feld | Bedeutung | |---|---| | Connection Name | Name des Netzwerkadapters | | Network Adapter | Beschreibung des Netzwerkgeräts | | Physical Address | MAC-Adresse | | Transport Name | Windows-interne Transportzuordnung | **Wichtig** Bei WLAN können private beziehungsweise zufällige MAC-Adressen verwendet werden. Die aktuell verwendete MAC-Adresse muss deshalb nicht dauerhaft mit der auf dem Gerät aufgedruckten Hardwareadresse übereinstimmen. --- **5. IP-Konfiguration mit ipconfig untersuchen** **Grundlegende Konfiguration anzeigen** Kennzeichnung: `[RO]` ```cmd ipconfig ``` Der Befehl zeigt unter anderem: - IPv4-Adressen; - IPv6-Adressen; - Subnetzmasken; - Standardgateways; - Adapter mit getrenntem Medium. **Vollständige Konfiguration anzeigen** Kennzeichnung: `[RO][SENS]` ```cmd ipconfig /all ``` `ipconfig /all` ist einer der wichtigsten ersten Diagnosebefehle auf Windows-Systemen. Die Ausgabe kann interne Adressen, DNS-Suffixe, DHCP-Server und andere Infrastrukturinformationen enthalten und sollte deshalb als sensibel behandelt werden. **Wichtige Felder in der Ausgabe** | Feld | Diagnosebedeutung | |---|---| | Host Name | Name des lokalen Systems | | Primary DNS Suffix | Primäres DNS-Suffix des Computers | | Node Type | Verwendeter NetBIOS-Namensauflösungstyp | | IP Routing Enabled | Gibt an, ob IP-Weiterleitung aktiviert ist | | Adapter Description | Treiber- beziehungsweise Adapterbeschreibung | | Physical Address | MAC-Adresse des Adapters | | DHCP Enabled | Gibt an, ob IPv4 per DHCP konfiguriert wird | | Autoconfiguration Enabled | Zeigt, ob automatische Adressierung möglich ist | | IPv4 Address | Aktuelle IPv4-Adresse | | Subnet Mask | Zugehörige IPv4-Subnetzmaske | | Lease Obtained | Beginn des aktuellen DHCP-Leases | | Lease Expires | Ablaufzeit des aktuellen DHCP-Leases | | Default Gateway | Router für nicht lokal erreichbare Ziele | | DHCP Server | DHCP-Server, von dem die Konfiguration stammt | | DNS Servers | Eingetragene DNS-Server in ihrer Reihenfolge | | Connection-specific DNS Suffix | DNS-Suffix des jeweiligen Adapters | | NetBIOS over Tcpip | Status von NetBIOS über TCP/IP | | Media State | Verbindungszustand eines Adapters | **Typische Auffälligkeiten** | Beobachtung | Mögliche Bedeutung | Nächste Prüfung | |---|---|---| | `Media disconnected` | Adapter besitzt derzeit keine aktive Verbindung | Kabel, WLAN-Verbindung, Adapterstatus und Switchport | | IPv4-Adresse aus `169.254.0.0/16` | Windows verwendet wahrscheinlich APIPA, weil keine verwendbare DHCP-Konfiguration vorliegt | DHCP-Server, VLAN, Relay, Firewall und Link prüfen | | Kein Standardgateway | Ziele außerhalb des lokalen Subnetzes sind normalerweise nicht über eine Default Route erreichbar | DHCP-Optionen, statische Konfiguration und Routingtabelle | | Unerwarteter DNS-Server | DNS-Anfragen können an einen falschen Resolver gehen | DHCP-Option 6, VPN, statische Konfiguration und Richtlinien | | Mehrere Standardgateways | Windows kann einen unerwarteten Ausgangspfad wählen | Routingtabelle und Metriken prüfen | | Altes Lease | Nicht automatisch fehlerhaft, aber bei Netzänderungen relevant | Lease-Zeiten und DHCP-Server vergleichen | | Nur IPv6-Link-Local-Adresse | Keine globale oder standortweite IPv6-Konfiguration erkennbar | Router Advertisements, DHCPv6 und IPv6-Routing | | Falsches DNS-Suffix | Kurznamen können falsch oder gar nicht aufgelöst werden | Adapter-, DHCP-, VPN- und Domänenkonfiguration | **APIPA richtig bewerten** Eine Adresse aus `169.254.0.0/16` wird von Windows automatisch vergeben, wenn ein DHCP-konfigurierter Adapter keine verwendbare DHCP-Antwort erhält. Damit ist unter Umständen Kommunikation mit anderen Systemen im selben lokalen Segment möglich, die ebenfalls eine passende Link-Local-Adresse besitzen. Normale geroutete Kommunikation in andere Subnetze ist damit jedoch nicht möglich. Eine APIPA-Adresse beweist noch nicht, an welcher Stelle DHCP scheitert. Mögliche Ursachen sind unter anderem: - keine physische Verbindung; - falsches VLAN; - DHCP-Server nicht erreichbar; - DHCP-Scope erschöpft oder deaktiviert; - DHCP-Relay fehlt; - Firewall oder DHCP-Snooping blockiert; - DHCP-Clientdienst gestört. --- **6. DNS-Clientcache mit ipconfig prüfen** **DNS-Clientcache anzeigen** Kennzeichnung: `[RO][SENS]` ```cmd ipconfig /displaydns ``` Der Cache kann enthalten: - Einträge aus der lokalen hosts-Datei; - zuvor abgefragte DNS-Einträge; - positive DNS-Antworten; - negative Cacheeinträge; - Record-Typen und TTL-Werte. Die Ausgabe sollte möglichst vor dem Leeren des Caches gesichert werden. **DNS-Clientcache in eine Datei schreiben** Kennzeichnung: `[RO][FILE][SENS]` ```cmd ipconfig /displaydns > "\dns-cache.txt" ``` **DNS-Clientcache leeren** Kennzeichnung: `[CHANGE]` ```cmd ipconfig /flushdns ``` Der Befehl entfernt dynamisch hinzugefügte positive und negative Einträge aus dem DNS-Clientcache. **Nicht sofort ausführen** Das Leeren des Caches kann: - einen wichtigen Fehlerzustand beseitigen; - einen veralteten oder negativen Cacheeintrag als Ursache verbergen; - die anschließende DNS-Anfrage verändern; - dazu führen, dass ein sporadischer Fehler vorübergehend nicht mehr reproduzierbar ist. Deshalb zuerst: ```cmd ipconfig /displaydns ``` Danach bei begründeter Hypothese: ```cmd ipconfig /flushdns ``` Anschließend denselben Namen erneut testen. **Dynamische DNS-Registrierung anstoßen** Kennzeichnung: `[TEST][CHANGE]` ```cmd ipconfig /registerdns ``` Der Befehl stößt die manuelle dynamische Registrierung der konfigurierten DNS-Namen und IP-Adressen an. Er ist für Probleme mit dynamischen DNS-Updates gedacht und nicht als allgemeiner erster Reparaturbefehl. Nach der Ausführung sollten zusätzlich geprüft werden: - DNS-Zone; - Berechtigungen für dynamische Updates; - DNS-Server-Ereignisse; - Windows-Ereignisprotokolle; - tatsächlich angelegte oder aktualisierte Records. --- **7. DHCP-Lease erneuern** **Aktuelle DHCP-Konfiguration eines Adapters freigeben** Kennzeichnung: `[CHANGE][DISRUPT]` ```cmd ipconfig /release "" ``` Für alle DHCP-konfigurierten IPv4-Adapter: ```cmd ipconfig /release ``` Dadurch wird die aktuelle DHCP-Konfiguration verworfen. Die Netzwerkverbindung kann unterbrochen werden. **DHCP-Konfiguration erneuern** Kennzeichnung: `[TEST][CHANGE]` ```cmd ipconfig /renew "" ``` Für alle DHCP-konfigurierten IPv4-Adapter: ```cmd ipconfig /renew ``` **DHCPv6-Konfiguration freigeben und erneuern** Kennzeichnung: `[CHANGE][DISRUPT]` ```cmd ipconfig /release6 "" ``` Kennzeichnung: `[TEST][CHANGE]` ```cmd ipconfig /renew6 "" ``` **Wichtige Sicherheitsregel** `ipconfig /release` darf nicht unüberlegt in einer entfernten Administrationssitzung ausgeführt werden. Die Verbindung zum System kann dadurch sofort abbrechen. **Vorher sichern** ```cmd ipconfig /all ``` **Nachher vergleichen** ```cmd ipconfig /all ``` Zu vergleichen sind insbesondere: - IP-Adresse; - Subnetzmaske; - Standardgateway; - DNS-Server; - DHCP-Server; - DNS-Suffix; - Lease-Beginn; - Lease-Ablauf. **Auswertung** | Ergebnis | Mögliche Schlussfolgerung | |---|---| | Lease wird erfolgreich erneuert | DHCP-Kommunikation funktioniert grundsätzlich | | APIPA-Adresse nach dem Versuch | Keine verwendbare DHCP-Antwort erhalten | | Alte Adresse bleibt bestehen | Lease möglicherweise noch gültig oder Erneuerung nicht erfolgreich | | Neuer falscher Adressbereich | Falsches VLAN, falscher Scope oder nicht autorisierter DHCP-Server möglich | | Gateway oder DNS fehlt | DHCP-Antwort beziehungsweise DHCP-Optionen unvollständig oder falsch | | Befehl betrifft falschen Adapter | Adaptername, virtuelle Adapter und aktive Verbindung prüfen | --- **8. Erreichbarkeit mit ping prüfen** `ping` sendet ICMP-Echoanforderungen und zeigt empfangene Echoantworten sowie die jeweilige Round-Trip-Zeit an. Ein erfolgreicher Ping beweist nicht, dass ein bestimmter TCP- oder UDP-Dienst funktioniert. Ein fehlgeschlagener Ping beweist nicht sicher, dass das Ziel ausgeschaltet ist. ICMP kann gefiltert, begrenzt oder deaktiviert sein. **IPv4-Ziel testen** Kennzeichnung: `[TEST]` ```cmd ping /4 192.0.2.25 ``` **IPv6-Ziel testen** Kennzeichnung: `[TEST]` ```cmd ping /6 server.example.test ``` **Namen testen** Kennzeichnung: `[TEST]` ```cmd ping server.example.test ``` Die erste Ausgabezeile zeigt normalerweise, in welche IP-Adresse der Name aufgelöst wurde. **Mehrere Anfragen senden** Kennzeichnung: `[TEST]` ```cmd ping /n 10 192.0.2.25 ``` Windows sendet standardmäßig vier Echoanforderungen. `/n 10` erhöht die Anzahl auf zehn. **Zeitüberschreitung festlegen** Kennzeichnung: `[TEST]` ```cmd ping /n 10 /w 1000 192.0.2.25 ``` `/w 1000` wartet pro Anfrage maximal 1000 Millisekunden auf eine Antwort. **Dauerhaft testen** Kennzeichnung: `[TEST]` ```cmd ping /t 192.0.2.25 ``` Steuerung: | Tastenkombination | Wirkung | |---|---| | `Strg` + `Unterbrechen` | Zwischenstatistik anzeigen und Test fortsetzen | | `Strg` + `C` | Test beenden und Abschlussstatistik anzeigen | Ein dauerhafter Ping sollte nicht unbeaufsichtigt laufen. **IPv4 oder IPv6 gezielt erzwingen** ```cmd ping /4 server.example.test ``` ```cmd ping /6 server.example.test ``` Damit lässt sich erkennen, ob nur einer der beiden Protokollpfade betroffen ist. **Paketgröße testen** Kennzeichnung: `[TEST]` ```cmd ping /4 /f /l 1472 192.0.2.25 ``` Bedeutung: | Option | Bedeutung | |---|---| | `/4` | IPv4 verwenden | | `/f` | „Do not Fragment“-Bit setzen | | `/l 1472` | ICMP-Datenfeld mit 1472 Byte verwenden | 1472 Byte plus 20 Byte IPv4-Header und 8 Byte ICMP-Header ergeben 1500 Byte. Das ist ein üblicher Startwert für Ethernet mit einer MTU von 1500, aber nicht für jeden Pfad passend. Wenn eine Fragmentierungsmeldung erscheint, kann die Nutzlast schrittweise reduziert werden. Beispiel: ```cmd ping /4 /f /l 1464 192.0.2.25 ``` ```cmd ping /4 /f /l 1400 192.0.2.25 ``` Dieser Test kann Hinweise auf Probleme mit folgenden Komponenten geben: - VPN-Tunnel; - PPPoE; - IPsec; - GRE; - Providerpfad; - falsch konfigurierte MTU; - gestörte Path-MTU-Discovery. **Ping-Ausgaben interpretieren** | Ausgabe | Bedeutung | |---|---| | `Reply from ...` | Eine ICMP-Echoantwort wurde empfangen | | `Request timed out` | Innerhalb der Wartezeit wurde keine passende Echoantwort empfangen | | `Destination host unreachable` | Das meldende System oder ein Router konnte das Ziel nicht erreichen | | `General failure` | Lokaler Versand ist fehlgeschlagen; lokale Konfiguration, Route, Interface oder Netzwerkstack prüfen | | `Ping request could not find host` | Der angegebene Name konnte nicht aufgelöst werden | | Stark wechselnde Laufzeiten | Mögliche Überlastung, WLAN-Störung, Warteschlangen oder wechselnde Pfade | | Paketverlust | Mögliche Filterung, Überlastung oder Verbindungsstörung; weitere Messungen erforderlich | Bei `Destination host unreachable` ist entscheidend, welche IP-Adresse die Meldung sendet: - eigene Adresse: Problem wahrscheinlich lokal oder im lokalen Segment; - Standardgateway: Gateway besitzt möglicherweise keine passende Route; - Zwischenrouter: Fehler weiter entfernt im Datenpfad. **TTL nicht als exakte Hopanzahl interpretieren** Der angezeigte TTL-Wert ist der verbleibende TTL-Wert der empfangenen Antwort. Da der ursprüngliche Startwert des Zielsystems normalerweise nicht sicher bekannt ist, kann daraus nicht zuverlässig die genaue Zahl der durchlaufenen Router berechnet werden. --- **9. Systematischer Ping-Test** Die folgende Reihenfolge grenzt den Fehler schrittweise ein. **1. Lokalen IPv4-Loopback testen** ```cmd ping 127.0.0.1 ``` Prüft grundlegende lokale IPv4-Verarbeitung. Der Test verlässt den Computer nicht. **2. Lokalen IPv6-Loopback testen** ```cmd ping ::1 ``` Prüft grundlegende lokale IPv6-Verarbeitung. **3. Eigene IP-Adresse testen** ```cmd ping ``` Prüft die Bindung der Adresse an den lokalen Netzwerkstack. Der Test beweist noch keine funktionierende physische Verbindung. **4. Standardgateway testen** ```cmd ping ``` Prüft die ICMP-Kommunikation zum Gateway, sofern dieses ICMP beantwortet. **5. Entfernte IP-Adresse testen** ```cmd ping ``` Prüft den gerouteten IP-Pfad ohne Abhängigkeit von der DNS-Namensauflösung. **6. Zielname testen** ```cmd ping server.example.test ``` Vergleich: | IP-Test | Namenstest | Wahrscheinlicher Bereich | |---|---|---| | Erfolgreich | Erfolgreich | Grundlegende IP-Kommunikation und Namensauflösung funktionieren | | Erfolgreich | Fehlgeschlagen | Namensauflösung, Suffix, Cache oder hosts-Datei prüfen | | Fehlgeschlagen | Name wird aufgelöst | Routing, Firewall, Zielsystem oder Rückweg prüfen | | Beide fehlgeschlagen | Keine eindeutige Aussage | Lokale Konfiguration, Gateway, DNS und Pfad getrennt prüfen | --- **10. Netzwerkpfad mit tracert untersuchen** `tracert` erhöht schrittweise den TTL-Wert und versucht dadurch, die Router auf dem Weg zum Ziel sichtbar zu machen. **Pfad zu einem Ziel anzeigen** Kennzeichnung: `[TEST]` ```cmd tracert server.example.test ``` **Namensauflösung der Zwischenstationen deaktivieren** Kennzeichnung: `[TEST]` ```cmd tracert /d 192.0.2.25 ``` `/d` verhindert Reverse-DNS-Abfragen für Zwischenrouter. Dadurch wird die Ausgabe häufig schneller und DNS-Verzögerungen beeinflussen die Messung weniger. **IPv4 erzwingen** ```cmd tracert /4 server.example.test ``` **IPv6 erzwingen** ```cmd tracert /6 server.example.test ``` **Maximale Hopanzahl begrenzen** ```cmd tracert /d /h 15 192.0.2.25 ``` **Wartezeit pro Antwort verringern** ```cmd tracert /d /w 1000 192.0.2.25 ``` `/w 1000` wartet bis zu 1000 Millisekunden auf die jeweilige ICMP-Antwort. **Ausgabe interpretieren** | Beobachtung | Mögliche Bedeutung | |---|---| | Ziel wird erreicht | Ein ICMP-basierter Pfad konnte bis zum Ziel verfolgt werden | | Einzelner Hop zeigt `*`, spätere Hops antworten | Dieser Router antwortet möglicherweise nicht auf TTL-Überschreitungen; Weiterleitung funktioniert trotzdem | | Ab einem Hop nur noch `*` | Filterung, fehlende Rückantwort, Pfadunterbrechung oder nicht antwortende Router möglich | | Erster Hop unerwartet | Falsches Gateway, VPN, virtueller Adapter oder unerwartete Route möglich | | Pfad unterscheidet sich zwischen Tests | Dynamisches Routing, Load Balancing, VPN-Wechsel oder andere Pfadauswahl möglich | | Hohe Laufzeit an einem Hop, spätere Hops wieder normal | Der Router priorisiert seine eigenen ICMP-Antworten möglicherweise niedrig; kein sicherer Beweis für Weiterleitungsverzögerung | | Hohe Laufzeit beginnt an einem Hop und bleibt danach erhöht | Möglicher Engpass oder langsamer Abschnitt ab diesem Bereich | **Wichtig** Drei Sternchen bedeuten nur, dass für diese Versuche keine erwartete ICMP-Antwort empfangen wurde. Sie beweisen nicht automatisch einen Paketverlust für normalen Anwendungsverkehr. --- **11. Paketverlust und Latenz mit pathping untersuchen** `pathping` kombiniert eine Pfadermittlung mit wiederholten ICMP-Messungen zu den Zwischenstationen. **Standardtest** Kennzeichnung: `[TEST]` ```cmd pathping 192.0.2.25 ``` **Ohne Namensauflösung** Kennzeichnung: `[TEST]` ```cmd pathping /n 192.0.2.25 ``` **Anzahl der Abfragen begrenzen** ```cmd pathping /n /q 20 192.0.2.25 ``` **Zeitabstand zwischen aufeinanderfolgenden Pings festlegen** ```cmd pathping /n /q 20 /p 500 192.0.2.25 ``` | Option | Bedeutung | |---|---| | `/n` | Keine Namensauflösung der Zwischenrouter | | `/q 20` | 20 Echoanforderungen pro Router | | `/p 500` | 500 Millisekunden zwischen aufeinanderfolgenden Pings | | `/w 1000` | Bis zu 1000 Millisekunden auf eine Antwort warten | | `/4` | Nur IPv4 verwenden | | `/6` | Nur IPv6 verwenden | **Wartezeit beachten** `pathping` benötigt deutlich länger als `tracert`, weil nach der Pfaderkennung über einen Zeitraum Messwerte gesammelt werden. **Verlust richtig interpretieren** Wenn ein Zwischenrouter bei an ihn gerichteten ICMP-Paketen Verlust zeigt, aber alle folgenden Hops und das Ziel keinen entsprechenden Verlust zeigen, ist die Weiterleitung wahrscheinlich nicht im gleichen Maß betroffen. Mögliche Erklärung: - ICMP-Antworten des Routers werden begrenzt; - der Router priorisiert Transitverkehr höher als eigene Diagnoseantworten; - die Control Plane ist ausgelastet, während die Weiterleitung weiterhin funktioniert. Wird ein Verlust ab einem bestimmten Link angezeigt und setzt sich bis zum Ziel fort, ist dieser Abschnitt wesentlich verdächtiger. **Pathping ist kein Beweis für Anwendungsleistung** Der Befehl prüft ICMP. Eine TCP-, UDP-, TLS- oder Anwendungsstörung muss mit dem tatsächlichen Protokoll weiter untersucht werden. --- **12. Routingtabelle mit route anzeigen** **Gesamte Routingtabelle anzeigen** Kennzeichnung: `[RO][SENS]` ```cmd route print ``` Die Ausgabe enthält: - Interface List; - IPv4-Routingtabelle; - IPv6-Routingtabelle; - aktive Routen; - persistente Routen; - Netzwerkziele; - Netzmasken beziehungsweise Präfixe; - Gateways; - Interfaceadressen; - Metriken. **Routen für einen bestimmten Bereich filtern** Kennzeichnung: `[RO]` ```cmd route print 192.0.2.* ``` **Wichtige Bestandteile** | Spalte | Bedeutung | |---|---| | Network Destination | Zielnetz oder Zielhost | | Netmask | Netzmaske der Route | | Gateway | Nächster Router beziehungsweise Next Hop | | Interface | Lokale Ausgangsadresse | | Metric | Kostenwert der Route | | On-link | Ziel ist über das angegebene Interface direkt erreichbar | **Default Route erkennen** ```text Network Destination: 0.0.0.0 Netmask: 0.0.0.0 ``` Diese Route wird verwendet, wenn keine spezifischere passende IPv4-Route vorhanden ist. **Routenauswahl vereinfacht** Windows berücksichtigt grundsätzlich: 1. passende Zielpräfixe; 2. die spezifischste passende Route; 3. bei gleich spezifischen Routen die Metriken; 4. die zugehörige Interfacemetrik und Routenkonfiguration. Eine Route zu `192.0.2.0/24` ist beispielsweise spezifischer als die Default Route `0.0.0.0/0`. **Typische Auffälligkeiten** | Beobachtung | Mögliche Ursache | |---|---| | Keine Default Route | Kein Gateway konfiguriert oder DHCP-Konfiguration unvollständig | | Mehrere Default Routes | Mehrere Adapter, VPN, virtuelle Netzwerke oder fehlerhafte Konfiguration | | Unerwartet niedrige Metrik | Datenverkehr verwendet möglicherweise den falschen Adapter | | Zielroute zeigt auf VPN | Split-Tunnel- oder VPN-Routing relevant | | Spezifische Route zeigt auf falsches Gateway | Statische Route oder Software hat die Pfadauswahl verändert | | Route ist `On-link`, Ziel liegt aber nicht im lokalen Segment | Falsche Subnetzmaske oder Präfixlänge möglich | | Persistente Route unerwartet vorhanden | Frühere manuelle Konfiguration oder Softwareinstallation prüfen | **Verändernde route-Befehle** Folgende Befehle verändern die Routingtabelle und sind keine reinen Diagnosebefehle: ```text route add route change route delete route /f ``` `route /f` entfernt einen großen Teil der Routingeinträge und kann Netzwerk- sowie Remotesitzungen unterbrechen. Der Befehl darf nicht als allgemeiner Reparaturversuch verwendet werden. --- **13. ARP-Cache und IPv4-Nachbartabelle prüfen** ARP ordnet IPv4-Adressen im lokalen Segment den zugehörigen MAC-Adressen zu. **ARP-Cache aller Interfaces anzeigen** Kennzeichnung: `[RO][SENS]` ```cmd arp -a ``` **Ein bestimmtes Ziel anzeigen** ```cmd arp -a 192.0.2.25 ``` **Tabelle eines bestimmten Interfaces anzeigen** ```cmd arp -a -N ``` **Ausgabe interpretieren** | Typ | Bedeutung | |---|---| | dynamic | Zuordnung wurde dynamisch per ARP gelernt | | static | Zuordnung wurde statisch eingetragen oder vom System vorgegeben | | Kein Eintrag | Ziel wurde noch nicht lokal aufgelöst, liegt nicht im lokalen Segment oder ARP-Auflösung ist fehlgeschlagen | **Gezielte Prüfung** Zuerst das lokale Ziel ansprechen: ```cmd ping 192.0.2.25 ``` Danach ARP-Tabelle prüfen: ```cmd arp -a 192.0.2.25 ``` Wenn das Ziel im selben IPv4-Subnetz liegt, aber trotz eines Kommunikationsversuchs keine passende MAC-Adresse gelernt wird, sollten unter anderem geprüft werden: - VLAN-Zuordnung; - Switchport; - Kabel oder WLAN; - falsche Subnetzmaske; - Zielsystem ausgeschaltet; - ARP-Filterung; - Duplicate Address; - Security-Funktionen wie Dynamic ARP Inspection; - virtuelle Switches und Bridges. **ARP-Eintrag löschen** Kennzeichnung: `[PRIV][CHANGE]` ```cmd arp -d 192.0.2.25 ``` Der Eintrag sollte erst gelöscht werden, nachdem sein vorheriger Zustand dokumentiert wurde. Das Löschen erzwingt bei der nächsten Kommunikation eine neue ARP-Auflösung. Es beweist jedoch nicht, warum ein vorheriger Eintrag falsch oder veraltet war. **IPv6 beachten** `arp` gilt für IPv4. IPv6 verwendet Neighbor Discovery. IPv6-Nachbarn anzeigen: ```cmd netsh interface ipv6 show neighbors ``` --- **14. DNS mit nslookup prüfen** `nslookup` kann DNS-Server direkt abfragen und unterstützt einen nicht interaktiven sowie einen interaktiven Modus. **Einzelnen Namen mit dem Standard-DNS-Server abfragen** Kennzeichnung: `[TEST][SENS]` ```cmd nslookup server.example.test ``` **Bestimmten DNS-Server abfragen** ```cmd nslookup server.example.test 192.0.2.53 ``` So können Antworten unterschiedlicher DNS-Server miteinander verglichen werden. **IPv4-A-Record abfragen** ```cmd nslookup -type=A server.example.test 192.0.2.53 ``` **IPv6-AAAA-Record abfragen** ```cmd nslookup -type=AAAA server.example.test 192.0.2.53 ``` **Mailserver abfragen** ```cmd nslookup -type=MX example.test 192.0.2.53 ``` **Nameserver einer Zone abfragen** ```cmd nslookup -type=NS example.test 192.0.2.53 ``` **TXT-Record abfragen** ```cmd nslookup -type=TXT example.test 192.0.2.53 ``` **SRV-Record abfragen** ```cmd nslookup -type=SRV _ldap._tcp.dc._msdcs.example.test 192.0.2.53 ``` **Reverse Lookup ausführen** ```cmd nslookup 192.0.2.25 192.0.2.53 ``` Dabei wird nach einem PTR-Record gesucht. **Interaktiven Modus starten** ```cmd nslookup ``` Beispiel innerhalb des interaktiven Modus: ```text server 192.0.2.53 set type=AAAA server.example.test exit ``` **Ausgabe interpretieren** | Ausgabe | Bedeutung | |---|---| | `Server` | Verwendeter DNS-Server | | `Address` | Adresse des verwendeten DNS-Servers | | `Name` | Zurückgegebener kanonischer Name | | `Addresses` | Zurückgegebene IP-Adressen | | `Aliases` | Gefundene Aliasnamen | | `Non-authoritative answer` | Antwort stammt nicht direkt vom autoritativen Server | | `NXDOMAIN` beziehungsweise „Non-existent domain“ | Angefragter Name existiert laut Antwort nicht | | `Request timed out` | DNS-Server antwortete innerhalb des Timeouts nicht | | `Server failed` | DNS-Server meldet einen Verarbeitungsfehler | | `Refused` | DNS-Server lehnt die Anfrage ab | **Wichtige Einschränkung** Eine erfolgreiche `nslookup`-Abfrage beweist nicht, dass eine Anwendung denselben Namen auf dieselbe Weise auflöst. Zusätzlich relevant sein können: - Windows-DNS-Clientcache; - hosts-Datei; - DNS-Suffixsuchliste; - VPN-Namensauflösung; - Split-DNS; - DoH in einem Browser; - Proxyauflösung; - anwendungseigener DNS-Cache; - NetBIOS oder LLMNR. Die Anwendung sollte deshalb anschließend ebenfalls direkt getestet werden. --- **15. NetBIOS-Namensauflösung mit nbtstat prüfen** `nbtstat` ist hauptsächlich für ältere beziehungsweise weiterhin verwendete NetBIOS-over-TCP/IP-Umgebungen relevant. **Lokale NetBIOS-Namenstabelle anzeigen** Kennzeichnung: `[RO][SENS]` ```cmd nbtstat /n ``` **NetBIOS-Namenscache anzeigen** ```cmd nbtstat /c ``` **Remote-Tabelle über den NetBIOS-Namen abfragen** Kennzeichnung: `[TEST][SENS]` ```cmd nbtstat /a ``` **Remote-Tabelle über die IPv4-Adresse abfragen** ```cmd nbtstat /A 192.0.2.25 ``` Groß- und Kleinschreibung der Optionen ist hier wichtig: | Option | Abfrage | |---|---| | `/a` | Remotecomputer über NetBIOS-Namen | | `/A` | Remotecomputer über IPv4-Adresse | `nbtstat` sollte nur verwendet werden, wenn NetBIOS, WINS, ältere SMB-Namensauflösung oder eine entsprechende Legacy-Anwendung tatsächlich relevant ist. --- **16. Verbindungen, Listener und Ports mit netstat prüfen** **Aktive TCP-Verbindungen anzeigen** Kennzeichnung: `[RO][SENS]` ```cmd netstat ``` **Alle Verbindungen und Listener numerisch anzeigen** ```cmd netstat -an ``` **Verbindungen, Listener und Prozess-IDs anzeigen** ```cmd netstat -ano ``` Bedeutung: | Option | Funktion | |---|---| | `-a` | Alle aktiven TCP-Verbindungen sowie TCP- und UDP-Listener anzeigen | | `-n` | Adressen und Ports numerisch anzeigen | | `-o` | Zugehörige Prozess-ID anzeigen | | `-b` | Beteiligte ausführbare Datei anzeigen | | `-e` | Ethernet-Statistiken anzeigen | | `-r` | Routingtabelle anzeigen | | `-s` | Protokollstatistiken anzeigen | | `-p` | Ausgabe auf ein Protokoll begrenzen | **Ausführbare Programme anzeigen** Kennzeichnung: `[RO][PRIV][SENS]` ```cmd netstat -abno ``` `-b` kann langsam sein und benötigt ausreichende Rechte. **Nach einem Port filtern** Kennzeichnung: `[RO][SENS]` ```cmd netstat -ano | findstr ":443" ``` **Achtung** Die Suche findet `:443` sowohl bei lokalen als auch bei entfernten Adressen. Das Ergebnis muss anhand der Spalte `Local Address` beziehungsweise `Foreign Address` bewertet werden. **Nur Listener suchen** ```cmd netstat -ano | findstr "LISTENING" ``` Auf einem deutschsprachigen Windows kann die Zustandsbezeichnung lokalisiert ausgegeben werden. Für zuverlässig automatisierbare Abfragen sind die PowerShell-Cmdlets der nächsten Seite besser geeignet. **Prozess zu einer PID suchen** ```cmd tasklist /FI "PID eq 1234" ``` Wenn mehrere Windows-Dienste von einem gemeinsamen `svchost.exe`-Prozess gehostet werden: ```cmd tasklist /SVC /FI "PID eq 1234" ``` **Protokollstatistiken anzeigen** ```cmd netstat -s ``` **Ethernet- und Protokollstatistiken anzeigen** ```cmd netstat -e -s ``` **Routingtabelle über netstat anzeigen** ```cmd netstat -r ``` Das entspricht funktional weitgehend: ```cmd route print ``` **Ausgabe regelmäßig aktualisieren** ```cmd netstat -ano 5 ``` Die Ausgabe wird alle fünf Sekunden aktualisiert. Mit `Strg` + `C` wird die Wiederholung beendet. --- **17. TCP-Zustände interpretieren** | Zustand | Bedeutung | Diagnosehinweis | |---|---|---| | `LISTENING` | Lokaler Prozess wartet auf Verbindungen | Erwarteter Dienst besitzt grundsätzlich einen Listener | | `SYN_SENT` | Verbindungsanfrage wurde gesendet, passende Antwort steht aus | Ziel, Firewall, Route oder Rückweg prüfen | | `SYN_RECEIVED` | Anfrage wurde empfangen und beantwortet, Abschluss des Handshakes steht aus | Clientantwort oder Rückweg prüfen | | `ESTABLISHED` | TCP-Verbindung ist aufgebaut | TCP funktioniert; Anwendung kann trotzdem fehlerhaft sein | | `FIN_WAIT_1` | Lokale Seite hat das Beenden eingeleitet | Kurzzeitig normal | | `FIN_WAIT_2` | Bestätigung liegt vor, Beendigung der Gegenseite steht aus | Viele dauerhafte Einträge können auf Anwendungsprobleme hindeuten | | `CLOSE_WAIT` | Gegenseite hat beendet; lokale Anwendung muss noch schließen | Viele dauerhafte Einträge deuten häufig auf eine nicht sauber schließende Anwendung | | `LAST_ACK` | Lokale Seite wartet auf letzte Bestätigung | Kurzzeitig normal | | `TIME_WAIT` | Verbindung wartet vor vollständiger Freigabe | Viele Einträge können bei hoher Verbindungsrate normal sein | | `CLOSED` | Keine aktive TCP-Verbindung | Normaler Endzustand | Ein einzelner Zustand ist selten ausreichend. Entscheidend sind: - Anzahl; - Dauer; - betroffene lokale und entfernte Endpunkte; - zugehöriger Prozess; - Entwicklung während der Störung; - Vergleich mit einem funktionierenden System. --- **18. Netzwerkinterfaces mit netsh prüfen** **Status aller Netzwerkinterfaces anzeigen** Kennzeichnung: `[RO]` ```cmd netsh interface show interface ``` Typische Felder: | Feld | Bedeutung | |---|---| | Admin State | Administrativ aktiviert oder deaktiviert | | State | Aktueller Verbindungszustand | | Type | Art des Interfaces | | Interface Name | Windows-Name des Interfaces | **IPv4-Interfaces anzeigen** ```cmd netsh interface ipv4 show interfaces ``` **IPv6-Interfaces anzeigen** ```cmd netsh interface ipv6 show interfaces ``` **IPv4-Konfiguration anzeigen** ```cmd netsh interface ipv4 show config ``` **IPv4-Adressen anzeigen** ```cmd netsh interface ipv4 show addresses ``` **IPv4-Routen anzeigen** ```cmd netsh interface ipv4 show route ``` **IPv4-Nachbarn anzeigen** ```cmd netsh interface ipv4 show neighbors ``` **IPv6-Adressen anzeigen** ```cmd netsh interface ipv6 show addresses ``` **IPv6-Routen anzeigen** ```cmd netsh interface ipv6 show route ``` **IPv6-Nachbarn anzeigen** ```cmd netsh interface ipv6 show neighbors ``` **Subinterfaces und MTU anzeigen** ```cmd netsh interface ipv4 show subinterfaces ``` Diese Ausgabe ist unter anderem für folgende Probleme hilfreich: - falsche MTU; - VPN- oder Tunnelinterface; - mehrere aktive Adapter; - unerwartete Interface-Metrik; - falsche Nachbarzuordnung; - IPv4 funktioniert, IPv6 nicht; - Datenverkehr verwendet ein virtuelles Interface. --- **19. WLAN mit netsh untersuchen** **Aktuelle WLAN-Verbindung anzeigen** Kennzeichnung: `[RO][SENS]` ```cmd netsh wlan show interfaces ``` Mögliche Angaben: - Name des WLAN-Interfaces; - Beschreibung und Treiber; - Status; - SSID; - BSSID; - verwendeter Funkstandard; - Authentifizierung; - Verschlüsselung; - Kanal; - Empfangs- und Senderate; - Signalstärke; - Profilname. **WLAN-Treiber und Fähigkeiten anzeigen** ```cmd netsh wlan show drivers ``` Damit lassen sich unter anderem prüfen: - unterstützte Funktypen; - unterstützte Authentifizierungsverfahren; - unterstützte Verschlüsselungsverfahren; - Treiberversion; - Hersteller; - Datum des Treibers; - unterstützte WLAN-Funktionen. **Sichtbare WLANs anzeigen** Kennzeichnung: `[TEST][SENS]` ```cmd netsh wlan show networks ``` **Sichtbare WLANs einschließlich BSSIDs anzeigen** ```cmd netsh wlan show networks mode=bssid ``` Damit können unter anderem verglichen werden: - SSID; - BSSID des Access Points; - Signalstärke; - Kanal; - Authentifizierung; - Verschlüsselung; - mehrere Access Points derselben SSID. **Gespeicherte WLAN-Profile anzeigen** Kennzeichnung: `[RO][SENS]` ```cmd netsh wlan show profiles ``` **Bestimmtes WLAN-Profil anzeigen** ```cmd netsh wlan show profile name="" ``` Die Liste gespeicherter SSIDs kann sensible Informationen über Standorte oder interne Netzwerknamen enthalten. **WLAN-Bericht erzeugen** Kennzeichnung: `[FILE][SENS]` ```cmd netsh wlan show wlanreport ``` Windows erzeugt einen HTML-Bericht und zeigt den Speicherort in der Ausgabe an. Der Bericht kann Informationen enthalten über: - WLAN-Sitzungen; - Verbindungsabbrüche; - Verbindungsdauer; - Fehlergründe; - Netzwerkadapter; - Treiber; - gespeicherte oder verwendete Netzwerke; - Systemereignisse. Der Bericht ist als sensible Diagnosedatei zu behandeln. **Typische WLAN-Auffälligkeiten** | Beobachtung | Mögliche Ursache | |---|---| | Interface State ist `disconnected` | Keine WLAN-Verbindung aktiv | | Unerwartete SSID | Client ist mit dem falschen Netz verbunden | | Unerwartete BSSID | Verbindung mit anderem Access Point als erwartet | | Niedrige Signalstärke | Entfernung, Dämpfung, Antenne oder ungünstiger Standort | | Niedrige Datenrate | Schlechte Funkbedingungen, alter Standard oder Störung | | Stark schwankendes Signal | Bewegung, Interferenz, Roaming oder Treiberproblem | | Überfüllter Kanal | Co-Channel-Interference möglich | | Profil vorhanden, Verbindung scheitert | Authentifizierung, Zertifikat, Schlüssel oder Richtlinie prüfen | | WLAN verbunden, aber APIPA | WLAN-Assoziierung funktioniert, DHCP jedoch möglicherweise nicht | --- **20. Proxykonfiguration prüfen** **WinHTTP-Proxy anzeigen** Kennzeichnung: `[RO][SENS]` ```cmd netsh winhttp show proxy ``` Der Befehl zeigt die Proxykonfiguration für Anwendungen und Dienste an, die WinHTTP verwenden. Mögliche Ausgaben: - direkter Zugriff ohne Proxy; - Proxyserver; - Proxyport; - Bypass-Liste. **Wichtige Einschränkung** Die WinHTTP-Konfiguration ist nicht automatisch identisch mit: - Browser-Proxyeinstellungen; - benutzerspezifischen Systemeinstellungen; - PAC-Dateien; - Proxykonfiguration einer Anwendung; - Umgebungsvariablen; - VPN- oder Security-Agent-Konfigurationen. Ein funktionierender Browser beweist daher nicht, dass ein Windows-Dienst mit WinHTTP ebenfalls den richtigen Proxy verwendet. **Nicht ungeprüft ausführen** Folgende Befehle verändern die Proxykonfiguration: ```text netsh winhttp set proxy netsh winhttp reset proxy netsh winhttp import proxy ``` Sie benötigen eine begründete Änderung, eine dokumentierte Ausgangskonfiguration und einen Rückfallplan. --- **21. Windows-Firewallstatus prüfen** **Status aller Firewallprofile anzeigen** Kennzeichnung: `[RO]` ```cmd netsh advfirewall show allprofiles state ``` **Aktuelles Firewallprofil anzeigen** ```cmd netsh advfirewall show currentprofile ``` **Firewallrichtlinie des aktuellen Profils anzeigen** ```cmd netsh advfirewall show currentprofile firewallpolicy ``` **Protokollierung des aktuellen Profils anzeigen** ```cmd netsh advfirewall show currentprofile logging ``` Zu prüfen sind: - aktives Profil; - Firewallstatus; - Standardaktion für eingehende Verbindungen; - Standardaktion für ausgehende Verbindungen; - Protokollierung verworfener Verbindungen; - Speicherort des Firewalllogs; - Gruppenrichtlinien oder zentrale Verwaltung. **Firewall nicht pauschal deaktivieren** Das vollständige Ausschalten der Firewall ist kein geeigneter erster Diagnosetest. Besser: 1. betroffenes Profil feststellen; 2. Richtung bestimmen; 3. Protokoll und Port bestimmen; 4. lokale und entfernte Adresse bestimmen; 5. passende Regeln und Logs prüfen; 6. nur bei Freigabe eine eng begrenzte temporäre Testregel verwenden; 7. Testregel anschließend wieder entfernen. --- **22. Diagnoseausgaben sichern** **IP-Konfiguration exportieren** Kennzeichnung: `[RO][FILE][SENS]` ```cmd ipconfig /all > "\ipconfig-all.txt" ``` **Routingtabelle exportieren** ```cmd route print > "\route-print.txt" ``` **ARP-Tabelle exportieren** ```cmd arp -a > "\arp-cache.txt" ``` **Verbindungen und Listener exportieren** ```cmd netstat -ano > "\netstat-ano.txt" ``` **Pfadtest exportieren** Kennzeichnung: `[TEST][FILE][SENS]` ```cmd tracert /d 192.0.2.25 > "\tracert.txt" ``` **Standardausgabe und Fehlermeldungen gemeinsam sichern** ```cmd pathping /n 192.0.2.25 > "\pathping.txt" 2>&1 ``` **An eine vorhandene Datei anhängen** ```cmd ipconfig /all >> "\netzdiagnose.txt" ``` Bedeutung: | Operator | Wirkung | |---|---| | `>` | Datei neu erstellen beziehungsweise vorhandenen Inhalt überschreiben | | `>>` | Ausgabe an vorhandene Datei anhängen | | `2>&1` | Fehlermeldungen zusammen mit der Standardausgabe umleiten | Vor dem Überschreiben einer vorhandenen Diagnosedatei muss geprüft werden, ob sie noch benötigt wird. --- **23. Kompakter Erfassungsblock** Die folgenden Befehle verändern keine Netzwerkkonfiguration. Die Ausgabe kann jedoch sensible Informationen enthalten. ```cmd hostname getmac /v ipconfig /all route print arp -a netstat -ano netsh interface show interface netsh interface ipv4 show neighbors netsh interface ipv6 show neighbors netsh winhttp show proxy netsh advfirewall show allprofiles state ``` Bei WLAN-Systemen zusätzlich: ```cmd netsh wlan show interfaces netsh wlan show drivers netsh wlan show profiles ``` Diese Sammlung ist nur eine Bestandsaufnahme. Sie ersetzt keine gezielte Bewertung der Ergebnisse. --- **24. Diagnosepfade für häufige Fehlerbilder** **Fehlerbild: Keine Netzwerkverbindung** ```cmd netsh interface show interface ipconfig /all route print arp -a ``` Prüfen: - Adapter administrativ aktiviert? - Medium verbunden? - gültige IP-Adresse? - Standardgateway vorhanden? - DNS-Server vorhanden? - APIPA-Adresse? - passende Route vorhanden? --- **Fehlerbild: IP-Adresse vorhanden, aber kein Internet** ```cmd ipconfig /all ping ping /4 nslookup tracert /d netsh winhttp show proxy netsh advfirewall show currentprofile ``` Auswertung: | Ergebnis | Verdächtiger Bereich | |---|---| | Gateway nicht erreichbar | lokales Netz, VLAN, WLAN, Kabel oder Gateway | | Gateway erreichbar, externe IP nicht | Routing, Firewall, NAT oder Provider | | Externe IP erreichbar, Name nicht | DNS | | Name und IP erreichbar, Anwendung nicht | Port, TLS, Proxy oder Anwendung | | Nur Dienst verwendet keinen Internetzugriff | WinHTTP-Proxy, Dienstkonto oder Firewall | --- **Fehlerbild: DNS funktioniert nicht** ```cmd ipconfig /all ipconfig /displaydns nslookup server.example.test nslookup server.example.test 192.0.2.53 ping /4 server.example.test ping /6 server.example.test ``` Prüfen: - korrekte DNS-Server? - antworten alle eingetragenen DNS-Server? - unterschiedliche Antworten je DNS-Server? - A- und AAAA-Record korrekt? - negativer Cacheeintrag? - falsches DNS-Suffix? - Split-DNS oder VPN relevant? - hosts-Datei oder Anwendungscache relevant? --- **Fehlerbild: Ein lokaler Dienst ist nicht erreichbar** ```cmd netstat -ano | findstr ":443" tasklist /FI "PID eq " netsh advfirewall show currentprofile ``` Prüfen: - existiert ein `LISTENING`-Eintrag? - lauscht der Dienst auf der erwarteten Adresse? - lauscht er nur auf `127.0.0.1` oder `::1`? - stimmt der Port? - stimmt die PID mit dem erwarteten Prozess überein? - ist die Firewallregel für das aktive Profil gültig? Der Test eines entfernten TCP-Ports folgt auf der nächsten Seite mit `Test-NetConnection`. --- **Fehlerbild: Verbindung ist langsam oder instabil** ```cmd ping /n 50 ping /n 50 tracert /d pathping /n netstat -e -s ``` Bei WLAN zusätzlich: ```cmd netsh wlan show interfaces netsh wlan show networks mode=bssid netsh wlan show wlanreport ``` Prüfen: - Verlust bereits zum Gateway? - nur entferntes Ziel betroffen? - steigende Latenz ab bestimmtem Abschnitt? - schwankendes WLAN-Signal? - Kanal oder BSSID wechseln? - Fehlerzähler steigen während der Störung? - ist nur ICMP oder auch die Anwendung betroffen? --- **Fehlerbild: Nur IPv4 oder nur IPv6 funktioniert** ```cmd ipconfig /all ping /4 server.example.test ping /6 server.example.test tracert /4 server.example.test tracert /6 server.example.test route print netsh interface ipv4 show route netsh interface ipv6 show route netsh interface ipv6 show neighbors ``` Prüfen: - A- und AAAA-Record vorhanden? - IPv6-Adresse außer Link-Local vorhanden? - IPv6-Default-Route vorhanden? - Router Advertisements funktionieren? - VPN oder Firewall behandelt IPv4 und IPv6 unterschiedlich? - Anwendung bevorzugt einen nicht funktionierenden IPv6-Pfad? --- **25. Typische Fehlinterpretationen** | Fehlinterpretation | Richtige Bewertung | |---|---| | Ping funktioniert, also funktioniert das Netzwerk vollständig | Ping prüft nur eine bestimmte ICMP-Kommunikation | | Ping funktioniert nicht, also ist das Ziel ausgeschaltet | ICMP kann gefiltert oder begrenzt sein | | Sternchen bei tracert bedeuten Paketverlust | Der Router hat möglicherweise nur keine ICMP-Antwort gesendet | | Verlust an einem pathping-Zwischenhop beweist einen defekten Router | Entscheidend ist, ob sich der Verlust bis zum Ziel fortsetzt | | `nslookup` funktioniert, also funktioniert DNS für jede Anwendung | Anwendungen können andere Resolverpfade, Caches oder Proxys verwenden | | Eine ARP-Tabelle zeigt alle erreichbaren Systeme | Sie enthält nur bereits gelernte oder statische lokale IPv4-Nachbarn | | `ESTABLISHED` bedeutet, dass die Anwendung funktioniert | Es beweist nur eine aufgebaute TCP-Verbindung | | Viele `TIME_WAIT`-Einträge sind automatisch ein Fehler | Sie können bei hoher normaler Verbindungsrate entstehen | | `169.254.x.x` bedeutet defekte Netzwerkkarte | Es weist normalerweise auf automatische Adressierung ohne verwendbare DHCP-Konfiguration hin | | Mehrere Gateways sind automatisch redundant | Sie können zu unerwarteter Routenauswahl führen | | Firewall ausschalten ist der schnellste Test | Das erzeugt ein Sicherheitsrisiko und liefert oft keine saubere Ursachenanalyse | | DNS-Cache sofort leeren hilft immer | Dabei kann der ursprüngliche Fehlerzustand verloren gehen | --- **26. Befehle mit besonderer Vorsicht** | Befehl | Kennzeichnung | Risiko | |---|---|---| | `ipconfig /release` | `[CHANGE][DISRUPT]` | Entfernt die aktuelle DHCP-Konfiguration | | `ipconfig /renew` | `[TEST][CHANGE]` | Verändert die aktuelle DHCP-Konfiguration | | `ipconfig /flushdns` | `[CHANGE]` | Entfernt den DNS-Clientcache und mögliche Beweise | | `ipconfig /registerdns` | `[TEST][CHANGE]` | Stößt dynamische DNS-Registrierungen an | | `arp -d ` | `[PRIV][CHANGE]` | Entfernt eine Nachbarzuordnung | | `route add` | `[PRIV][CHANGE]` | Fügt eine Route hinzu | | `route change` | `[PRIV][CHANGE]` | Verändert eine Route | | `route delete` | `[PRIV][CHANGE][DISRUPT]` | Entfernt eine Route | | `route /f` | `[PRIV][CHANGE][DISRUPT]` | Entfernt einen großen Teil der Routingtabelle | | `netsh interface set ...` | `[PRIV][CHANGE][DISRUPT]` | Verändert Interfacekonfiguration | | `netsh winhttp reset proxy` | `[PRIV][CHANGE]` | Entfernt die WinHTTP-Proxykonfiguration | | `netsh advfirewall set ...` | `[PRIV][CHANGE][DISRUPT]` | Verändert Firewallrichtlinien | | `netsh wlan disconnect` | `[CHANGE][DISRUPT]` | Trennt eine WLAN-Verbindung | | `netsh wlan delete profile` | `[PRIV][CHANGE]` | Löscht ein gespeichertes WLAN-Profil | Vor diesen Befehlen müssen Ausgangszustand, Auswirkung und Rückfallplan dokumentiert werden. --- **27. Grenzen der klassischen Windows-Befehle** Die klassischen Befehle sind schnell verfügbar und eignen sich gut für eine erste Diagnose. Sie haben jedoch einige Einschränkungen: - Ausgaben sind teilweise sprachabhängig; - Textausgaben sind für Automatisierung schlechter geeignet; - komplexe Filterungen sind umständlich; - IPv4- und IPv6-Informationen sind teilweise getrennt; - strukturierte Weiterverarbeitung ist begrenzt; - ein beliebiger entfernter TCP-Port lässt sich mit den klassischen Grundbefehlen nicht so bequem testen; - mehrere Adapter und Routen sind in Textausgaben schwerer vergleichbar. Für strukturierte und gezielte Windows-Diagnosen folgt deshalb: > **2.2 PowerShell-Netzwerkdiagnose** --- **Quellen und weiterführende Dokumentation** - Microsoft Learn – `hostname`: - Microsoft Learn – `getmac`: - Microsoft Learn – `ipconfig`: - Microsoft Learn – Automatic Private IP Addressing: - Microsoft Learn – `ping`: - Microsoft Learn – `tracert`: - Microsoft Learn – `pathping`: - Microsoft Learn – `route`: - Microsoft Learn – `arp`: - Microsoft Learn – `nslookup`: - Microsoft Learn – `nbtstat`: - Microsoft Learn – `netstat`: - Microsoft Learn – TCP-Zustände: - Microsoft Learn – `tasklist`: - Microsoft Learn – `findstr`: - Microsoft Learn – Network Shell `netsh`: - Microsoft Learn – `netsh interface`: - Microsoft Learn – `netsh wlan`: - Microsoft Learn – `netsh winhttp`: - Microsoft Learn – `netsh advfirewall`: # 2.2 PowerShell-Netzwerkdiagnose PowerShell stellt Netzwerkdaten als strukturierte Objekte bereit. Dadurch lassen sich Informationen gezielt filtern, sortieren, vergleichen und exportieren. Die Cmdlets dieser Seite gehören zu Windows-Modulen wie `NetAdapter`, `NetTCPIP`, `DnsClient` und `NetSecurity`. Sie sind für die Netzwerkdiagnose unter Windows vorgesehen. --- **Kennzeichnungen** | Kennzeichnung | Bedeutung | |---|---| | `[RO]` | Nur lesender Befehl; verändert keine Konfiguration | | `[TEST]` | Führt einen aktiven Netzwerk- oder Verbindungstest aus | | `[PRIV]` | Benötigt möglicherweise eine PowerShell mit Administratorrechten | | `[CHANGE]` | Verändert einen Zustand oder eine Konfiguration | | `[DISRUPT]` | Kann eine bestehende Verbindung oder einen Dienst unterbrechen | | `[FILE]` | Schreibt Informationen in eine Datei | | `[SENS]` | Ausgabe kann sensible System-, Netzwerk- oder Prozessdaten enthalten | > Für die erste Diagnose möglichst mit `[RO]`-Befehlen beginnen. Veränderungen sollten erst erfolgen, wenn die Ursache ausreichend eingegrenzt und eine Rückfallmöglichkeit vorhanden ist. ---
1. PowerShell und benötigte Netzwerkmodule prüfen Bevor ein Cmdlet verwendet wird, sollte geprüft werden, welche PowerShell-Version und welche Windows-Netzwerkmodule vorhanden sind. | Aufgabe | PowerShell-Befehl | |---|---| | PowerShell-Version anzeigen | `[RO] $PSVersionTable` | | Betriebssysteminformationen anzeigen | `[RO] Get-ComputerInfo \| Select-Object WindowsProductName, WindowsVersion, OsBuildNumber` | | Netzwerkmodule suchen | `[RO] Get-Module -ListAvailable NetAdapter, NetTCPIP, DnsClient, NetSecurity` | | Befehle eines Moduls auflisten | `[RO] Get-Command -Module NetTCPIP` | | Hilfe zu einem Cmdlet anzeigen | `[RO] Get-Help Test-NetConnection -Full` | | Verwendungsbeispiele anzeigen | `[RO] Get-Help Resolve-DnsName -Examples` | | Syntax eines Cmdlets anzeigen | `[RO] Get-Command Get-NetAdapter -Syntax` | **Typische Fehler** | Meldung oder Beobachtung | Mögliche Bedeutung | |---|---| | `The term ... is not recognized` | Cmdlet oder Modul ist nicht vorhanden beziehungsweise nicht geladen | | `Access denied` | Administratorrechte oder zusätzliche Berechtigungen erforderlich | | Keine Ausgabe | Filter ist möglicherweise zu eng oder es existiert kein passendes Objekt | | Einzelne Eigenschaften fehlen | Unterschiedliche Windows-, PowerShell- oder Modulversion |
---
2. Netzwerkadapter und Verbindungsstatus prüfen `Get-NetAdapter` zeigt physische und virtuelle Netzwerkadapter einschließlich Status, Geschwindigkeit, MAC-Adresse und Schnittstellenindex. | Aufgabe | PowerShell-Befehl | |---|---| | Alle sichtbaren Netzwerkadapter anzeigen | `[RO] Get-NetAdapter` | | Auch ausgeblendete Adapter anzeigen | `[RO] Get-NetAdapter -IncludeHidden` | | Wichtige Eigenschaften auswählen | `[RO] Get-NetAdapter \| Select-Object Name, InterfaceDescription, Status, LinkSpeed, MacAddress, ifIndex` | | Nur aktive Adapter anzeigen | `[RO] Get-NetAdapter \| Where-Object Status -eq "Up"` | | Nicht aktive Adapter anzeigen | `[RO] Get-NetAdapter \| Where-Object Status -ne "Up"` | | Adapter nach Status gruppieren | `[RO] Get-NetAdapter -IncludeHidden \| Group-Object Status` | | Detailinformationen eines Adapters anzeigen | `[RO] Get-NetAdapter -Name "Ethernet" \| Format-List *` | | Adapterstatistik anzeigen | `[RO] Get-NetAdapterStatistics` | | Fehler- und Verwerfungszähler anzeigen | `[RO] Get-NetAdapterStatistics \| Select-Object Name, ReceivedPacketErrors, OutboundPacketErrors, ReceivedDiscardedPackets, OutboundDiscardedPackets` | | Treiberinformationen anzeigen | `[RO] Get-NetAdapter \| Select-Object Name, DriverDescription, DriverVersion, DriverDate` | | Verbindungstyp und Netzwerkprofil anzeigen | `[RO] Get-NetConnectionProfile` | **Wichtige Eigenschaften** | Eigenschaft | Bedeutung | |---|---| | `Status` | Betriebszustand des Adapters | | `LinkSpeed` | Ausgehandelte Verbindungsgeschwindigkeit | | `MacAddress` | Hardwareadresse des Netzwerkadapters | | `ifIndex` | Schnittstellenindex für weitere Cmdlets | | `ReceivedPacketErrors` | Fehlerhaft empfangene Pakete | | `OutboundPacketErrors` | Fehler beim Senden | | `ReceivedDiscardedPackets` | Empfangene, aber verworfene Pakete | | `OutboundDiscardedPackets` | Zu sendende, aber verworfene Pakete | **Hinweise zur Auswertung** - `Status = Up` bedeutet nur, dass der Adapter aktiv und eine Verbindung erkannt wurde. - Ein aktiver Adapter bestätigt nicht automatisch eine funktionierende IP-Konfiguration. - Eine unerwartet niedrige `LinkSpeed` kann auf Kabel-, Port-, Treiber- oder Aushandlungsprobleme hinweisen. - Steigende Fehler- oder Verwerfungszähler können auf Treiberprobleme, Überlastung oder eine gestörte Verbindung hinweisen. - Virtuelle Adapter von VPN-, Hyper-V-, Container- oder Sicherheitssoftware müssen von physischen Adaptern unterschieden werden.
---
3. IP-Konfiguration vollständig erfassen `Get-NetIPConfiguration` liefert eine zusammengefasste Ansicht der IP-Konfiguration. Für einzelne Eigenschaften stehen zusätzliche Cmdlets zur Verfügung. | Aufgabe | PowerShell-Befehl | |---|---| | Aktive IP-Konfiguration anzeigen | `[RO] Get-NetIPConfiguration` | | Alle IP-Konfigurationen anzeigen | `[RO] Get-NetIPConfiguration -All` | | Ausführliche Ausgabe erzeugen | `[RO] Get-NetIPConfiguration -All \| Format-List *` | | IPv4-Adressen anzeigen | `[RO] Get-NetIPAddress -AddressFamily IPv4` | | IPv6-Adressen anzeigen | `[RO] Get-NetIPAddress -AddressFamily IPv6` | | Verwendbare IPv4-Adressen anzeigen | `[RO] Get-NetIPAddress -AddressFamily IPv4 \| Where-Object AddressState -eq "Preferred"` | | Loopback- und APIPA-Adressen ausblenden | `[RO] Get-NetIPAddress -AddressFamily IPv4 \| Where-Object { $_.IPAddress -notlike "127.*" -and $_.IPAddress -notlike "169.254.*" }` | | IP-Schnittstellen anzeigen | `[RO] Get-NetIPInterface` | | IPv4-Schnittstellen nach Metrik sortieren | `[RO] Get-NetIPInterface -AddressFamily IPv4 \| Sort-Object InterfaceMetric` | | Standardgateways anzeigen | `[RO] Get-NetRoute -DestinationPrefix "0.0.0.0/0"` | | DNS-Serveradressen anzeigen | `[RO] Get-DnsClientServerAddress` | | Nur IPv4-DNS-Server anzeigen | `[RO] Get-DnsClientServerAddress -AddressFamily IPv4` | | DHCP-Status anzeigen | `[RO] Get-NetIPInterface \| Select-Object InterfaceAlias, AddressFamily, Dhcp, ConnectionState` | **Wichtige Prüfpunkte** | Prüffeld | Erwartung beziehungsweise Fehlerhinweis | |---|---| | IP-Adresse | Muss zum vorgesehenen Netzwerk passen | | Präfixlänge | Muss zur Netzmaske des Netzwerks passen | | Standardgateway | Muss im Regelfall aus dem lokalen Netz erreichbar sein | | DNS-Server | Muss erreichbar und für die benötigten Zonen zuständig sein | | DHCP | Muss zur vorgesehenen statischen oder dynamischen Konfiguration passen | | InterfaceMetric | Niedrigerer Wert wird bei konkurrierenden Schnittstellen bevorzugt | | `169.254.x.x` | Kann auf eine fehlgeschlagene DHCP-Zuweisung hinweisen | | Mehrere Standardrouten | Können zu einem unerwarteten Verbindungsweg führen | **Kompakte Bestandsaufnahme** ```powershell Get-NetIPConfiguration -All | Select-Object InterfaceAlias, InterfaceDescription, NetProfile, IPv4Address, IPv6Address, IPv4DefaultGateway, DNSServer ```
---
4. Erreichbarkeit und TCP-Ports testen `Test-NetConnection` kombiniert mehrere klassische Netzwerkprüfungen und liefert strukturierte Ergebnisse. | Aufgabe | PowerShell-Befehl | |---|---| | Grundlegende Erreichbarkeit testen | `[TEST] Test-NetConnection 192.0.2.10` | | Detaillierte Ausgabe anzeigen | `[TEST] Test-NetConnection 192.0.2.10 -InformationLevel Detailed` | | Standardgateway testen | `[TEST] Test-NetConnection 192.0.2.1 -InformationLevel Detailed` | | Internet-IP testen | `[TEST] Test-NetConnection 1.1.1.1 -InformationLevel Detailed` | | HTTPS-Port testen | `[TEST] Test-NetConnection example.com -Port 443 -InformationLevel Detailed` | | SSH-Port testen | `[TEST] Test-NetConnection 192.0.2.10 -Port 22 -InformationLevel Detailed` | | RDP-Port testen | `[TEST] Test-NetConnection 192.0.2.10 -Port 3389 -InformationLevel Detailed` | | SMB-Port testen | `[TEST] Test-NetConnection 192.0.2.10 -Port 445 -InformationLevel Detailed` | | Routenverfolgung durchführen | `[TEST] Test-NetConnection example.com -TraceRoute` | | Nur boolesches Testergebnis ausgeben | `[TEST] Test-NetConnection example.com -Port 443 -InformationLevel Quiet` | > Die Adressen `192.0.2.0/24`, `198.51.100.0/24` und `203.0.113.0/24` sind Dokumentationsnetze. Sie müssen in echten Prüfungen durch die tatsächlichen Zieladressen ersetzt werden. **Wichtige Ergebnisfelder** | Eigenschaft | Bedeutung | |---|---| | `ComputerName` | Angegebenes Ziel | | `RemoteAddress` | Aufgelöste Zieladresse | | `NameResolutionResults` | Ergebnisse der Namensauflösung | | `SourceAddress` | Verwendete lokale Quelladresse | | `InterfaceAlias` | Verwendete Netzwerkschnittstelle | | `NetRoute` | Ausgewählte Route | | `PingSucceeded` | Ergebnis des ICMP-Tests | | `TcpTestSucceeded` | Ergebnis des TCP-Verbindungsversuchs | | `RemotePort` | Getesteter Zielport | **Interpretation** | Ergebnis | Mögliche Bedeutung | |---|---| | `PingSucceeded = False`, TCP-Test erfolgreich | ICMP wird möglicherweise blockiert; der getestete Dienst ist trotzdem erreichbar | | Namensauflösung schlägt fehl, IP-Test funktioniert | DNS-Problem wahrscheinlich | | Gateway erreichbar, externes Ziel nicht erreichbar | Routing, Firewall, Provider oder Upstream-System prüfen | | IP-Adresse erreichbar, TCP-Port nicht erreichbar | Dienst, Zielport oder Firewall prüfen | | Falsches `InterfaceAlias` | Routingmetrik, VPN oder mehrere aktive Adapter prüfen | | Falsche `SourceAddress` | IP-Konfiguration oder Routenauswahl prüfen |
---
5. DNS-Auflösung gezielt untersuchen `Resolve-DnsName` erlaubt präzisere DNS-Abfragen als ein einfacher Verbindungstest. | Aufgabe | PowerShell-Befehl | |---|---| | Namen mit Standardeinstellungen auflösen | `[TEST] Resolve-DnsName example.com` | | Nur DNS verwenden | `[TEST] Resolve-DnsName example.com -DnsOnly` | | IPv4-Adresse abfragen | `[TEST] Resolve-DnsName example.com -Type A -DnsOnly` | | IPv6-Adresse abfragen | `[TEST] Resolve-DnsName example.com -Type AAAA -DnsOnly` | | Mailserver abfragen | `[TEST] Resolve-DnsName example.com -Type MX -DnsOnly` | | Nameserver abfragen | `[TEST] Resolve-DnsName example.com -Type NS -DnsOnly` | | TXT-Einträge abfragen | `[TEST] Resolve-DnsName example.com -Type TXT -DnsOnly` | | Reverse-DNS-Abfrage durchführen | `[TEST] Resolve-DnsName 192.0.2.10 -Type PTR -DnsOnly` | | Bestimmten DNS-Server verwenden | `[TEST] Resolve-DnsName example.com -Server 192.0.2.53 -DnsOnly` | | Nur lokalen DNS-Cache abfragen | `[RO] Resolve-DnsName example.com -CacheOnly` | | DNS-Cache anzeigen | `[RO] Get-DnsClientCache` | | Cache nach einem Namen durchsuchen | `[RO] Get-DnsClientCache \| Where-Object Entry -like "*example.com*"` | | Konfigurierte DNS-Server anzeigen | `[RO] Get-DnsClientServerAddress` | | DNS-Clientkonfiguration anzeigen | `[RO] Get-DnsClient` | **DNS-Vergleichstest** ```powershell Resolve-DnsName example.com -DnsOnly Resolve-DnsName example.com -Server 192.0.2.53 -DnsOnly Resolve-DnsName example.com -Server 1.1.1.1 -DnsOnly ``` **Auswertung** | Beobachtung | Mögliche Ursache | |---|---| | Interner DNS-Server antwortet nicht | DNS-Dienst, Firewall, Routing oder Erreichbarkeit prüfen | | Externer DNS-Server funktioniert, interner nicht | Problem wahrscheinlich beim internen Resolver | | Interne Namen funktionieren extern nicht | Normal, wenn die Zone nur intern vorhanden ist | | Unterschiedliche Antworten verschiedener Resolver | Split-DNS, Cache, Replikationsverzug oder unterschiedliche Zonen | | `NXDOMAIN` | Name existiert aus Sicht des verwendeten DNS-Servers nicht | | `SERVFAIL` | DNS-Server konnte die Anfrage nicht erfolgreich verarbeiten | | Timeout | DNS-Server nicht erreichbar, blockiert oder zu langsam | | Auflösung funktioniert nur aus dem Cache | Aktuelle DNS-Kommunikation möglicherweise gestört | > Öffentliche DNS-Server dürfen nicht unüberlegt zum Test interner Namen verwendet werden. Interne Hostnamen, Domänennamen und Strukturen können sensible Informationen darstellen.
---
6. Routing und ausgewählten Netzwerkweg prüfen | Aufgabe | PowerShell-Befehl | |---|---| | Gesamte Routingtabelle anzeigen | `[RO] Get-NetRoute` | | IPv4-Routen anzeigen | `[RO] Get-NetRoute -AddressFamily IPv4` | | IPv6-Routen anzeigen | `[RO] Get-NetRoute -AddressFamily IPv6` | | Standardroute anzeigen | `[RO] Get-NetRoute -DestinationPrefix "0.0.0.0/0"` | | Routen nach Metrik sortieren | `[RO] Get-NetRoute -AddressFamily IPv4 \| Sort-Object RouteMetric` | | Route einer Schnittstelle anzeigen | `[RO] Get-NetRoute -InterfaceAlias "Ethernet"` | | Wahrscheinlich verwendete Route bestimmen | `[RO] Find-NetRoute -RemoteIPAddress 1.1.1.1` | | Schnittstellenmetriken anzeigen | `[RO] Get-NetIPInterface -AddressFamily IPv4 \| Sort-Object InterfaceMetric` | | Routenverfolgung durchführen | `[TEST] Test-NetConnection example.com -TraceRoute` | **Wichtige Eigenschaften** | Eigenschaft | Bedeutung | |---|---| | `DestinationPrefix` | Zielnetz der Route | | `NextHop` | Nächster Router beziehungsweise Gateway | | `InterfaceAlias` | Verwendete Netzwerkschnittstelle | | `RouteMetric` | Metrik der einzelnen Route | | `InterfaceMetric` | Metrik der Schnittstelle | | `Publish` | Gibt an, ob die Route veröffentlicht wird | | `Protocol` | Herkunft beziehungsweise Routingprotokoll der Route | **Typische Fehlerbilder** - Mehrere Standardrouten konkurrieren miteinander. - Ein VPN installiert eine bevorzugte Route. - Eine Route verwendet den falschen Adapter. - Das Standardgateway befindet sich nicht im erwarteten lokalen Netz. - Eine spezifischere Route überschreibt die allgemeine Standardroute. - Eine niedrige Metrik führt zu einem unerwarteten Netzwerkweg.
---
7. ARP- und IPv6-Nachbartabelle prüfen `Get-NetNeighbor` zeigt bekannte Nachbarn auf direkt angeschlossenen Netzen. Bei IPv4 entspricht dies funktional weitgehend der ARP-Tabelle; bei IPv6 werden Einträge des Neighbor Discovery Protocols angezeigt. | Aufgabe | PowerShell-Befehl | |---|---| | Gesamte Nachbartabelle anzeigen | `[RO] Get-NetNeighbor` | | IPv4-Nachbarn anzeigen | `[RO] Get-NetNeighbor -AddressFamily IPv4` | | IPv6-Nachbarn anzeigen | `[RO] Get-NetNeighbor -AddressFamily IPv6` | | Nachbarn eines Adapters anzeigen | `[RO] Get-NetNeighbor -InterfaceAlias "Ethernet"` | | Einträge nach Zustand sortieren | `[RO] Get-NetNeighbor \| Sort-Object State, InterfaceAlias` | | Bestimmte IP-Adresse suchen | `[RO] Get-NetNeighbor -IPAddress 192.0.2.10` | | Erreichbare Einträge anzeigen | `[RO] Get-NetNeighbor \| Where-Object State -eq "Reachable"` | | Unvollständige Einträge anzeigen | `[RO] Get-NetNeighbor \| Where-Object State -eq "Incomplete"` | **Wichtige Zustände** | Zustand | Bedeutung | |---|---| | `Reachable` | Nachbar wurde kürzlich erfolgreich erreicht | | `Stale` | Eintrag ist vorhanden, wurde aber länger nicht bestätigt | | `Delay` | Erreichbarkeitsprüfung wird verzögert | | `Probe` | Aktive Erreichbarkeitsprüfung läuft | | `Incomplete` | Adressauflösung konnte noch nicht abgeschlossen werden | | `Permanent` | Statischer beziehungsweise dauerhafter Eintrag | **Fehlerhinweise** - `Incomplete` kann auf ein nicht erreichbares Ziel, falsches VLAN, Layer-2-Probleme oder eine falsche IP-Konfiguration hinweisen. - Wechselnde MAC-Adressen zu derselben IP-Adresse können auf doppelte IP-Adressen, Hochverfügbarkeit oder Sicherheitsprobleme hinweisen. - Kein Eintrag bedeutet nicht automatisch einen Fehler. Möglicherweise wurde das Ziel noch nicht angesprochen oder befindet sich nicht im lokalen Netz.
---
8. TCP-Verbindungen, offene Ports und Prozesse untersuchen `Get-NetTCPConnection` zeigt lokale TCP-Endpunkte und bestehende TCP-Verbindungen. | Aufgabe | PowerShell-Befehl | |---|---| | Alle TCP-Verbindungen anzeigen | `[RO] Get-NetTCPConnection` | | Lauschende TCP-Ports anzeigen | `[RO] Get-NetTCPConnection -State Listen` | | Bestehende Verbindungen anzeigen | `[RO] Get-NetTCPConnection -State Established` | | Verbindungen zu einem Zielport suchen | `[RO] Get-NetTCPConnection -RemotePort 443` | | Lokalen Port untersuchen | `[RO] Get-NetTCPConnection -LocalPort 443` | | Nach Zustand gruppieren | `[RO] Get-NetTCPConnection \| Group-Object State` | | Verbindungen sortiert anzeigen | `[RO] Get-NetTCPConnection \| Sort-Object State, LocalPort` | | UDP-Endpunkte anzeigen | `[RO] Get-NetUDPEndpoint` | | Prozess über PID ermitteln | `[RO] Get-Process -Id 1234` | **Lauschende Ports mit Prozessnamen anzeigen** ```powershell Get-NetTCPConnection -State Listen | Select-Object LocalAddress, LocalPort, OwningProcess, @{ Name = "ProcessName" Expression = { (Get-Process -Id $_.OwningProcess -ErrorAction SilentlyContinue).ProcessName } } | Sort-Object LocalPort ``` **Bestehende Verbindungen mit Prozessnamen anzeigen** ```powershell Get-NetTCPConnection -State Established | Select-Object LocalAddress, LocalPort, RemoteAddress, RemotePort, OwningProcess, @{ Name = "ProcessName" Expression = { (Get-Process -Id $_.OwningProcess -ErrorAction SilentlyContinue).ProcessName } } ``` **Interpretation** | Beobachtung | Mögliche Bedeutung | |---|---| | Erwarteter Port fehlt im Zustand `Listen` | Dienst läuft nicht, lauscht auf anderem Port oder konnte den Port nicht binden | | Port lauscht nur auf `127.0.0.1` | Dienst ist nur lokal erreichbar | | Port lauscht auf `0.0.0.0` | Dienst lauscht grundsätzlich auf allen IPv4-Schnittstellen | | Port lauscht auf `::` | Dienst lauscht grundsätzlich auf IPv6 und möglicherweise abhängig von der Anwendung auch auf IPv4 | | Viele Verbindungen im Zustand `SYN_SENT` | Ziel, Route, Dienst oder Firewall antwortet möglicherweise nicht | | Viele Verbindungen im Zustand `TIME_WAIT` | Kann bei vielen kurzlebigen TCP-Verbindungen normal sein | | Unerwarteter Prozess lauscht auf einem Port | Dienstzuordnung und Sicherheitslage prüfen | > Eine Verbindung im Zustand `Listen` bestätigt nur, dass lokal ein Prozess auf dem Port wartet. Sie bestätigt nicht, dass der Port aus einem anderen Netz erreichbar ist.
---
9. Windows-Firewall diagnostizieren Die Firewall sollte zunächst nur ausgelesen werden. Ein vollständiges Abschalten der Firewall ist kein geeigneter erster Diagnoseschritt. | Aufgabe | PowerShell-Befehl | |---|---| | Firewallprofile anzeigen | `[RO] Get-NetFirewallProfile` | | Status der Profile kompakt anzeigen | `[RO] Get-NetFirewallProfile \| Select-Object Name, Enabled, DefaultInboundAction, DefaultOutboundAction` | | Aktivierte Regeln anzeigen | `[RO] Get-NetFirewallRule -Enabled True` | | Aktivierte Blockierungsregeln anzeigen | `[RO] Get-NetFirewallRule -Enabled True -Action Block` | | Eingehende Regeln anzeigen | `[RO] Get-NetFirewallRule -Direction Inbound` | | Regel anhand des Anzeigenamens suchen | `[RO] Get-NetFirewallRule -DisplayName "*Remote Desktop*"` | | Portfilter anzeigen | `[RO] Get-NetFirewallPortFilter` | | Regeln für lokalen Port 443 suchen | `[RO] Get-NetFirewallPortFilter \| Where-Object LocalPort -eq 443 \| Get-NetFirewallRule` | | Regeln für TCP-Port 445 suchen | `[RO] Get-NetFirewallPortFilter \| Where-Object { $_.Protocol -eq "TCP" -and $_.LocalPort -eq 445 } \| Get-NetFirewallRule` | | Adressfilter einer Regel anzeigen | `[RO] Get-NetFirewallRule -DisplayName "REGELNAME" \| Get-NetFirewallAddressFilter` | | Portfilter einer Regel anzeigen | `[RO] Get-NetFirewallRule -DisplayName "REGELNAME" \| Get-NetFirewallPortFilter` | | Anwendungsfilter einer Regel anzeigen | `[RO] Get-NetFirewallRule -DisplayName "REGELNAME" \| Get-NetFirewallApplicationFilter` | **Warum zeigt `Get-NetFirewallRule` nicht alle Ports und Adressen direkt an?** Windows speichert Bedingungen wie Ports, Programme und Adressen in zugeordneten Filterobjekten. Deshalb werden für eine vollständige Analyse zusätzlich folgende Cmdlets verwendet: - `Get-NetFirewallPortFilter` - `Get-NetFirewallAddressFilter` - `Get-NetFirewallApplicationFilter` - `Get-NetFirewallServiceFilter` - `Get-NetFirewallInterfaceFilter` **Sinnvolle Prüfreihenfolge** 1. Aktives Netzwerkprofil mit `Get-NetConnectionProfile` feststellen. 2. Firewallstatus des Profils mit `Get-NetFirewallProfile` prüfen. 3. Prüfen, ob der Dienst lokal auf dem erwarteten Port lauscht. 4. Passende eingehende oder ausgehende Regel suchen. 5. Port-, Adress-, Programm- und Profilfilter der Regel prüfen. 6. Verbindung von einem autorisierten Testsystem aus testen. > Die Firewall nicht pauschal deaktivieren. Dadurch verändert sich die Sicherheitslage und das Testergebnis bildet die ursprüngliche Konfiguration nicht mehr korrekt ab.
---
10. Diagnoseausgaben filtern, vergleichen und exportieren PowerShell-Ausgaben bestehen aus Objekten. Die Filterung sollte deshalb möglichst vor der Formatierung erfolgen. | Aufgabe | PowerShell-Befehl | |---|---| | Bestimmte Eigenschaften auswählen | `[RO] Get-NetAdapter \| Select-Object Name, Status, LinkSpeed` | | Objekte filtern | `[RO] Get-NetAdapter \| Where-Object Status -ne "Up"` | | Ergebnisse sortieren | `[RO] Get-NetRoute \| Sort-Object RouteMetric` | | Ergebnisse gruppieren | `[RO] Get-NetTCPConnection \| Group-Object State` | | Anzahl ermitteln | `[RO] (Get-NetTCPConnection -State Established).Count` | | Tabellenansicht erzeugen | `[RO] Get-NetAdapter \| Format-Table -AutoSize` | | Detailansicht erzeugen | `[RO] Get-NetIPConfiguration \| Format-List *` | | CSV-Datei exportieren | `[RO][FILE][SENS] Get-NetTCPConnection \| Export-Csv -Path ".\tcp-connections.csv" -NoTypeInformation -Encoding UTF8` | | Objekte vollständig speichern | `[RO][FILE][SENS] Get-NetIPConfiguration -All \| Export-Clixml -Path ".\ip-configuration.xml"` | | Textprotokoll erzeugen | `[RO][FILE][SENS] Get-NetIPConfiguration -All \| Format-List * \| Out-File ".\ip-configuration.txt" -Encoding utf8` | **Zwei Messzeitpunkte vergleichen** ```powershell $Vorher = Get-NetTCPConnection Start-Sleep -Seconds 10 $Nachher = Get-NetTCPConnection Compare-Object $Vorher $Nachher -Property State, LocalAddress, LocalPort, RemoteAddress, RemotePort ``` **Hinweise** - `Where-Object` und `Select-Object` verarbeiten Objekte. - `Format-Table` und `Format-List` sind für die Darstellung am Ende einer Pipeline gedacht. - Für eine spätere Weiterverarbeitung sind `Export-Csv` oder `Export-Clixml` geeigneter als formatierter Text. - Exportdateien können IP-Adressen, DNS-Namen, Prozesskennungen, Verbindungen und interne Netzstrukturen enthalten. - Diagnoseexporte müssen entsprechend den betrieblichen Datenschutz- und Sicherheitsvorgaben behandelt werden.
---
11. Eingreifende Befehle nur nach der Diagnose verwenden Die folgenden Befehle verändern einen Zustand und gehören nicht zur rein lesenden Bestandsaufnahme. | Maßnahme | PowerShell-Befehl | Auswirkung | |---|---|---| | DNS-Clientcache leeren | `[CHANGE][PRIV] Clear-DnsClientCache` | Lokal gespeicherte DNS-Antworten werden entfernt | | Netzwerkadapter neu starten | `[CHANGE][PRIV][DISRUPT] Restart-NetAdapter -Name "Ethernet"` | Adapter wird deaktiviert und erneut aktiviert | | DHCP-Lease erneuern | `[CHANGE][PRIV][DISRUPT] ipconfig /release; ipconfig /renew` | Vorhandene DHCP-Adresse wird zunächst freigegeben | | DNS-Registrierung anfordern | `[CHANGE][PRIV] Register-DnsClient` | Dynamische DNS-Registrierung wird angestoßen | **Vor einem Eingriff prüfen** - Besteht eine lokale oder entfernte Administrationsverbindung? - Wird die eigene Remoteverbindung durch den Eingriff getrennt? - Ist die aktuelle Konfiguration dokumentiert? - Ist die Ursache ausreichend eingegrenzt? - Gibt es einen Rückfallweg oder lokalen Zugriff? - Sind Auswirkungen auf Benutzer, Dienste, VPN-Verbindungen oder Cluster bekannt? - Ist ein Wartungsfenster beziehungsweise eine Freigabe erforderlich? > `Restart-NetAdapter` kann eine Remoteverbindung sofort unterbrechen. Der Befehl darf auf entfernten Produktivsystemen nur mit abgesichertem Rückfallweg verwendet werden.
---
12. Praktische PowerShell-Diagnosereihenfolge **Schritt 1 – Adapter prüfen** ```powershell Get-NetAdapter | Select-Object Name, Status, LinkSpeed, MacAddress, ifIndex ``` **Schritt 2 – IP-Konfiguration prüfen** ```powershell Get-NetIPConfiguration -All ``` **Schritt 3 – Standardroute und DNS-Server prüfen** ```powershell Get-NetRoute -DestinationPrefix "0.0.0.0/0" Get-DnsClientServerAddress ``` **Schritt 4 – Lokales Standardgateway testen** ```powershell Test-NetConnection 192.0.2.1 -InformationLevel Detailed ``` **Schritt 5 – Externe IP-Adresse testen** ```powershell Test-NetConnection 1.1.1.1 -InformationLevel Detailed ``` **Schritt 6 – DNS-Auflösung testen** ```powershell Resolve-DnsName example.com -DnsOnly ``` **Schritt 7 – Zielport testen** ```powershell Test-NetConnection example.com -Port 443 -InformationLevel Detailed ``` **Schritt 8 – Route zum Ziel prüfen** ```powershell Find-NetRoute -RemoteIPAddress 1.1.1.1 Test-NetConnection example.com -TraceRoute ``` **Schritt 9 – Lokale Ports und Prozesse prüfen** ```powershell Get-NetTCPConnection -State Listen | Sort-Object LocalPort ``` **Schritt 10 – Firewallstatus prüfen** ```powershell Get-NetFirewallProfile Get-NetFirewallRule -Enabled True | Select-Object DisplayName, Direction, Action, Profile ``` **Diagnoselogik** | Ergebnis | Nächster Schwerpunkt | |---|---| | Adapter nicht aktiv | Kabel, WLAN, Adapter, Treiber oder Port prüfen | | Keine passende IP-Adresse | DHCP oder statische IP-Konfiguration prüfen | | Gateway nicht erreichbar | Lokales Netz, VLAN, WLAN, Switch oder Gateway prüfen | | Externe IP erreichbar, DNS-Name nicht | DNS-Konfiguration und Resolver prüfen | | Ziel-IP erreichbar, Zielport nicht | Dienst, Portbindung und Firewall prüfen | | Falscher Adapter oder falsche Quelladresse | Routing, Metrik, VPN und mehrere Adapter prüfen | | Dienst lauscht lokal, ist extern aber nicht erreichbar | Firewall, NAT, Routing und Dienstbindung prüfen |
--- **Kurzreferenz** | Diagnoseziel | Befehl | |---|---| | Adapterstatus | `[RO] Get-NetAdapter` | | Adapterstatistik | `[RO] Get-NetAdapterStatistics` | | IP-Gesamtübersicht | `[RO] Get-NetIPConfiguration -All` | | IP-Adressen | `[RO] Get-NetIPAddress` | | Schnittstellen und Metriken | `[RO] Get-NetIPInterface` | | Netzwerkprofil | `[RO] Get-NetConnectionProfile` | | DNS-Server | `[RO] Get-DnsClientServerAddress` | | DNS-Auflösung | `[TEST] Resolve-DnsName example.com -DnsOnly` | | DNS-Cache | `[RO] Get-DnsClientCache` | | Verbindungstest | `[TEST] Test-NetConnection example.com` | | TCP-Porttest | `[TEST] Test-NetConnection example.com -Port 443` | | Routenverfolgung | `[TEST] Test-NetConnection example.com -TraceRoute` | | Routingtabelle | `[RO] Get-NetRoute` | | Route zu einem Ziel | `[RO] Find-NetRoute -RemoteIPAddress 1.1.1.1` | | Nachbartabelle | `[RO] Get-NetNeighbor` | | TCP-Verbindungen | `[RO] Get-NetTCPConnection` | | UDP-Endpunkte | `[RO] Get-NetUDPEndpoint` | | Firewallprofile | `[RO] Get-NetFirewallProfile` | | Firewallregeln | `[RO] Get-NetFirewallRule` | --- **Merksatz** > PowerShell-Netzwerkdiagnose bedeutet nicht, möglichst viele Befehle auszuführen. Entscheidend ist, die Ergebnisse als zusammenhängende Beweiskette auszuwerten: Adapter → IP-Konfiguration → Gateway → Route → DNS → Zielport → lokaler Dienst → Firewall. --- **Quellen** - [Microsoft Learn – NetAdapter-Modul](https://learn.microsoft.com/powershell/module/netadapter/) - [Microsoft Learn – NetTCPIP-Modul](https://learn.microsoft.com/powershell/module/nettcpip/) - [Microsoft Learn – DnsClient-Modul](https://learn.microsoft.com/powershell/module/dnsclient/) - [Microsoft Learn – NetSecurity-Modul](https://learn.microsoft.com/powershell/module/netsecurity/) - [Microsoft Learn – Test-NetConnection](https://learn.microsoft.com/powershell/module/nettcpip/test-netconnection) - [Microsoft Learn – Resolve-DnsName](https://learn.microsoft.com/powershell/module/dnsclient/resolve-dnsname) - [Microsoft Learn – Windows-Firewall über die Befehlszeile verwalten](https://learn.microsoft.com/windows/security/operating-system-security/network-security/windows-firewall/configure-with-command-line) # 2.3 Linux-Netzwerkbefehle Linux stellt für die Netzwerkdiagnose verschiedene Werkzeuge bereit. Welche Befehle verfügbar sind, hängt von Distribution, Installation und verwendeter Netzwerkverwaltung ab. Die wichtigsten Werkzeuggruppen sind: - `iproute2` mit `ip` und `ss` - `iputils` mit `ping` und `tracepath` - DNS-Werkzeuge wie `resolvectl`, `dig`, `host` und `getent` - NetworkManager mit `nmcli` - systemd-networkd mit `networkctl` - Treiber- und Linkdiagnose mit `ethtool` - Socket- und Prozessdiagnose mit `ss`, `lsof` und `fuser` - Firewallanalyse mit `nft`, `iptables`, `ufw` oder `firewall-cmd` - Protokollanalyse mit `journalctl` und `dmesg` --- **Kennzeichnungen** | Kennzeichnung | Bedeutung | |---|---| | `[RO]` | Nur lesender Befehl; verändert keine Konfiguration | | `[TEST]` | Führt einen aktiven Netzwerk- oder Verbindungstest aus | | `[PRIV]` | Benötigt Root-Rechte beziehungsweise `sudo` | | `[CHANGE]` | Verändert einen Zustand oder eine Konfiguration | | `[DISRUPT]` | Kann eine Verbindung oder einen Dienst unterbrechen | | `[FILE]` | Schreibt Informationen in eine Datei | | `[SENS]` | Ausgabe kann sensible System-, Netzwerk- oder Prozessdaten enthalten | > Vor Veränderungen sollten zunächst die lesenden `[RO]`-Befehle verwendet und deren Ergebnisse dokumentiert werden. ---
1. Linux-System und verfügbare Werkzeuge prüfen Zunächst muss geklärt werden, welche Distribution, welcher Kernel und welche Netzwerkwerkzeuge vorhanden sind. | Aufgabe | Linux-Befehl | |---|---| | Distribution anzeigen | `[RO] cat /etc/os-release` | | Kernelversion anzeigen | `[RO] uname -r` | | Architektur anzeigen | `[RO] uname -m` | | Hostname anzeigen | `[RO] hostnamectl` | | Aktuellen Benutzer anzeigen | `[RO] id` | | Prüfen, ob ein Befehl vorhanden ist | `[RO] command -v ip` | | Mehrere Werkzeuge prüfen | `[RO] command -v ip ss ping tracepath traceroute mtr dig resolvectl nmcli networkctl ethtool` | | Version von `iproute2` anzeigen | `[RO] ip -Version` | | Hilfe zum `ip`-Befehl anzeigen | `[RO] ip help` | | Handbuchseite öffnen | `[RO] man ip` | | Handbuch für einen Teilbefehl öffnen | `[RO] man ip-route` | | Kurzhilfe eines Teilbefehls anzeigen | `[RO] ip route help` | **Typische Paketnamen** | Werkzeug | Häufiger Paketname | |---|---| | `ip`, `ss` | `iproute2` | | `ping`, `tracepath` | `iputils` beziehungsweise `iputils-ping` und `iputils-tracepath` | | `dig`, `host` | `dnsutils`, `bind-utils` oder `bind-tools` | | `traceroute` | `traceroute` | | `mtr` | `mtr` | | `ethtool` | `ethtool` | | `lsof` | `lsof` | | `nc` | `netcat-openbsd`, `nmap-ncat` oder vergleichbares Paket | > Paketnamen unterscheiden sich zwischen Debian, Ubuntu, Fedora, Red Hat Enterprise Linux, Rocky Linux, AlmaLinux, SUSE, Arch Linux und anderen Distributionen.
---
2. Netzwerkschnittstellen und Linkstatus prüfen `ip link` zeigt Netzwerkschnittstellen unabhängig davon, ob bereits eine IP-Adresse konfiguriert wurde. | Aufgabe | Linux-Befehl | |---|---| | Alle Schnittstellen anzeigen | `[RO] ip link show` | | Kompakte Übersicht anzeigen | `[RO] ip -brief link show` | | Details und Statistiken anzeigen | `[RO] ip -details -statistics link show` | | Einzelne Schnittstelle anzeigen | `[RO] ip link show dev enp1s0` | | Empfangs- und Sendestatistik anzeigen | `[RO] ip -statistics link show dev enp1s0` | | Betriebszustand über sysfs lesen | `[RO] cat /sys/class/net/enp1s0/operstate` | | Physische Trägererkennung lesen | `[RO] cat /sys/class/net/enp1s0/carrier` | | MTU anzeigen | `[RO] cat /sys/class/net/enp1s0/mtu` | | MAC-Adresse anzeigen | `[RO] cat /sys/class/net/enp1s0/address` | | Alle Schnittstellennamen auflisten | `[RO] ls -1 /sys/class/net` | > `enp1s0` ist nur ein Beispiel. Der tatsächliche Name kann beispielsweise `eth0`, `ens18`, `eno1`, `enp3s0`, `wlan0` oder `wlp2s0` lauten. **Wichtige Angaben von `ip link`** | Angabe | Bedeutung | |---|---| | `UP` | Schnittstelle wurde administrativ aktiviert | | `LOWER_UP` | Physische beziehungsweise untergeordnete Verbindung wurde erkannt | | `NO-CARRIER` | Kein physischer Link erkannt | | `state UP` | Schnittstelle ist betriebsbereit | | `state DOWN` | Schnittstelle ist nicht aktiv | | `mtu` | Maximum Transmission Unit | | `link/ether` | MAC-Adresse einer Ethernet-Schnittstelle | | `qlen` | Länge der Sendewarteschlange | **Typische Fehlerbilder** | Beobachtung | Mögliche Bedeutung | |---|---| | `state DOWN` | Schnittstelle wurde deaktiviert oder nicht aktiviert | | `UP`, aber kein `LOWER_UP` | Kein physischer Link, Kabel-, Port- oder WLAN-Problem | | `NO-CARRIER` | Kein Trägersignal erkannt | | Viele `errors` | Kabel, Port, Treiber, Hardware oder Aushandlung prüfen | | Viele `dropped` | Überlastung, Warteschlangen, Treiber oder Puffer prüfen | | Unerwartete MTU | Kann Fragmentierungs- oder Tunnelprobleme verursachen | | Schnittstelle fehlt vollständig | Treiber, Hardwareerkennung, virtuelle Maschine oder Gerätezuordnung prüfen |
---
3. IP-Adressen und Adresszustände prüfen | Aufgabe | Linux-Befehl | |---|---| | Alle Adressen anzeigen | `[RO] ip address show` | | Kompakte Adressübersicht | `[RO] ip -brief address show` | | IPv4-Adressen anzeigen | `[RO] ip -4 address show` | | IPv6-Adressen anzeigen | `[RO] ip -6 address show` | | Adressen einer Schnittstelle anzeigen | `[RO] ip address show dev enp1s0` | | Nur globale IPv4-Adressen anzeigen | `[RO] ip -4 address show scope global` | | Nur globale IPv6-Adressen anzeigen | `[RO] ip -6 address show scope global` | | Adressen ohne Loopback anzeigen | `[RO] ip -brief address show \| grep -v '^lo'` | | Hostadressen kompakt anzeigen | `[RO] hostname -I` | **Wichtige Angaben** | Angabe | Bedeutung | |---|---| | `inet` | IPv4-Adresse | | `inet6` | IPv6-Adresse | | `/24`, `/64` | Präfixlänge | | `scope host` | Nur lokal auf diesem System gültig | | `scope link` | Nur im direkt verbundenen Netz gültig | | `scope global` | Über das lokale System beziehungsweise Netz hinaus verwendbar | | `dynamic` | Adresse wurde dynamisch vergeben | | `secondary` | Zusätzliche Adresse auf derselben Schnittstelle | | `tentative` | IPv6 Duplicate Address Detection ist noch nicht abgeschlossen | | `deprecated` | Adresse soll nicht mehr für neue Verbindungen verwendet werden | | `valid_lft` | Verbleibende Gültigkeitsdauer | | `preferred_lft` | Verbleibende bevorzugte Nutzungsdauer | **Prüfpunkte** - Passt die IP-Adresse zum vorgesehenen Netz? - Ist die Präfixlänge korrekt? - Ist die Adresse an der richtigen Schnittstelle gebunden? - Existieren unerwartete zusätzliche Adressen? - Wird eine dynamische Adresse erwartet? - Ist eine IPv6-Adresse noch `tentative` oder bereits `deprecated`? - Befindet sich eine IPv4-Adresse im Bereich `169.254.0.0/16`? - Existiert nur eine Loopback-Adresse? > Eine Adresse aus `169.254.0.0/16` kann darauf hinweisen, dass keine reguläre IPv4-Konfiguration beziehungsweise keine erfolgreiche DHCP-Zuweisung vorhanden ist.
---
4. Routingtabelle und verwendeten Netzwerkweg prüfen | Aufgabe | Linux-Befehl | |---|---| | IPv4-Routingtabelle anzeigen | `[RO] ip route show` | | IPv6-Routingtabelle anzeigen | `[RO] ip -6 route show` | | Alle Routingtabellen anzeigen | `[RO] ip route show table all` | | Standardroute anzeigen | `[RO] ip route show default` | | Route zu einem Ziel bestimmen | `[RO] ip route get 1.1.1.1` | | Route mit gewünschter Quelladresse prüfen | `[RO] ip route get 1.1.1.1 from 192.0.2.10` | | Route über eine Schnittstelle suchen | `[RO] ip route show dev enp1s0` | | Policy-Routing-Regeln anzeigen | `[RO] ip rule show` | | IPv6-Policy-Regeln anzeigen | `[RO] ip -6 rule show` | | Routingtabellen-Namen anzeigen | `[RO] cat /etc/iproute2/rt_tables` | | Änderungen an Routen überwachen | `[RO] ip monitor route` | **Wichtige Angaben** | Angabe | Bedeutung | |---|---| | `default` | Standardroute für nicht spezifischer bekannte Ziele | | `via` | Nächster Router beziehungsweise Gateway | | `dev` | Verwendete Netzwerkschnittstelle | | `src` | Bevorzugte lokale Quelladresse | | `metric` | Routenmetrik | | `proto dhcp` | Route wurde über DHCP bereitgestellt | | `proto kernel` | Route wurde automatisch durch den Kernel erzeugt | | `table` | Verwendete Routingtabelle | | `scope link` | Ziel befindet sich direkt am lokalen Link | **Beispielausgabe** ```text default via 192.0.2.1 dev enp1s0 proto dhcp src 192.0.2.10 metric 100 192.0.2.0/24 dev enp1s0 proto kernel scope link src 192.0.2.10 metric 100 ``` **Interpretation** - Das Standardgateway ist `192.0.2.1`. - Die Schnittstelle `enp1s0` wird verwendet. - Die bevorzugte Quelladresse ist `192.0.2.10`. - Das Netz `192.0.2.0/24` ist direkt angeschlossen. - Bei mehreren Routen können Präfixlänge, Policy-Regeln und Metriken die Auswahl beeinflussen. **Typische Fehlerbilder** - Keine Standardroute vorhanden. - Standardroute verwendet die falsche Schnittstelle. - VPN- oder Tunnelroute überschreibt den erwarteten Weg. - Falsche Quelladresse wird ausgewählt. - Eine spezifischere Route überschreibt die Standardroute. - Policy Routing verwendet eine andere Routingtabelle. - Mehrere Standardrouten führen zu einem unerwarteten Netzwerkweg.
---
5. ARP- und IPv6-Nachbartabelle prüfen `ip neigh` zeigt IPv4-ARP- und IPv6-Nachbareinträge. | Aufgabe | Linux-Befehl | |---|---| | Nachbartabelle anzeigen | `[RO] ip neighbour show` | | Kompakte Nachbartabelle anzeigen | `[RO] ip -brief neighbour show` | | IPv4-Nachbarn anzeigen | `[RO] ip -4 neighbour show` | | IPv6-Nachbarn anzeigen | `[RO] ip -6 neighbour show` | | Nachbarn einer Schnittstelle anzeigen | `[RO] ip neighbour show dev enp1s0` | | Bestimmte IP-Adresse suchen | `[RO] ip neighbour show 192.0.2.1` | | Fehlgeschlagene Einträge anzeigen | `[RO] ip neighbour show nud failed` | | Unvollständige Einträge anzeigen | `[RO] ip neighbour show nud incomplete` | | Änderungen überwachen | `[RO] ip monitor neighbour` | **Wichtige Zustände** | Zustand | Bedeutung | |---|---| | `REACHABLE` | Nachbar wurde kürzlich erfolgreich erreicht | | `STALE` | Eintrag ist vorhanden, wurde aber länger nicht bestätigt | | `DELAY` | Prüfung der Erreichbarkeit wird verzögert | | `PROBE` | Aktive Erreichbarkeitsprüfung läuft | | `INCOMPLETE` | Adressauflösung ist noch nicht abgeschlossen | | `FAILED` | Adressauflösung beziehungsweise Erreichbarkeitsprüfung ist fehlgeschlagen | | `PERMANENT` | Dauerhaft konfigurierter Eintrag | | `NOARP` | Für diesen Eintrag wird keine normale Nachbarauflösung verwendet | **Fehlerhinweise** - `INCOMPLETE` oder `FAILED` kann auf ein falsches VLAN, eine falsche Netzmaske, einen nicht erreichbaren Nachbarn oder ein Layer-2-Problem hinweisen. - Unterschiedliche MAC-Adressen für dieselbe IP-Adresse können auf doppelte IP-Adressen, Hochverfügbarkeit oder einen Sicherheitsvorfall hinweisen. - Ein fehlender Eintrag ist nicht automatisch ein Fehler. Das Ziel wurde möglicherweise noch nicht angesprochen oder liegt außerhalb des lokalen Netzes.
---
6. Erreichbarkeit mit ping prüfen | Aufgabe | Linux-Befehl | |---|---| | Vier ICMP-Anfragen senden | `[TEST] ping -c 4 192.0.2.1` | | Externe IP-Adresse testen | `[TEST] ping -c 4 1.1.1.1` | | DNS-Namen testen | `[TEST] ping -c 4 example.com` | | Nur IPv4 verwenden | `[TEST] ping -4 -c 4 example.com` | | Nur IPv6 verwenden | `[TEST] ping -6 -c 4 example.com` | | Bestimmte Schnittstelle verwenden | `[TEST] ping -I enp1s0 -c 4 192.0.2.1` | | Bestimmte Quelladresse verwenden | `[TEST] ping -I 192.0.2.10 -c 4 192.0.2.1` | | Timeout pro Antwort begrenzen | `[TEST] ping -c 4 -W 2 192.0.2.1` | | Gesamtlaufzeit begrenzen | `[TEST] ping -c 4 -w 10 192.0.2.1` | | Paketgröße prüfen | `[TEST] ping -c 4 -s 1400 192.0.2.1` | | Keine Fragmentierung erlauben | `[TEST] ping -c 4 -M do -s 1400 192.0.2.1` | **Wichtige Ergebnisse** | Wert | Bedeutung | |---|---| | `time` | Antwortzeit beziehungsweise Round Trip Time | | `ttl` | Verbleibende IPv4 Time to Live | | `icmp_seq` | Nummer der ICMP-Anfrage | | `packet loss` | Anteil verlorener Anfragen | | `min/avg/max` | Minimale, durchschnittliche und maximale Laufzeit | | `mdev` | Streuung der Laufzeiten unter Linux | **Interpretation** | Ergebnis | Mögliche Bedeutung | |---|---| | IP-Adresse erreichbar, DNS-Name nicht | DNS-Problem wahrscheinlich | | Gateway nicht erreichbar | Lokales Netz, VLAN, WLAN, Switch oder Gateway prüfen | | Ziel nicht erreichbar, Gateway erreichbar | Routing, Firewall oder entferntes System prüfen | | Einzelne Paketverluste | Überlastung, Funkstörung, Linkfehler oder Rate Limiting möglich | | Hohe Laufzeitschwankungen | Überlastung, WLAN-Störung oder wechselnder Netzwerkweg | | `Destination Host Unreachable` | Lokales System oder Router kennt keinen funktionierenden Weg | | Keine Antwort | Ziel offline, ICMP blockiert oder Netzwerkweg gestört | > Ein fehlgeschlagener Ping beweist nicht, dass ein Ziel vollständig unerreichbar ist. ICMP kann blockiert sein, während ein TCP-Dienst weiterhin funktioniert.
---
7. Netzwerkpfad mit tracepath, traceroute und mtr untersuchen | Aufgabe | Linux-Befehl | |---|---| | Pfad ohne Root-Rechte prüfen | `[TEST] tracepath example.com` | | IPv4-Pfad prüfen | `[TEST] tracepath -4 example.com` | | IPv6-Pfad prüfen | `[TEST] tracepath -6 example.com` | | Klassische Routenverfolgung | `[TEST] traceroute example.com` | | Keine Namensauflösung durchführen | `[TEST] traceroute -n example.com` | | TCP-Traceroute zu Port 443 | `[TEST][PRIV] sudo traceroute -T -p 443 example.com` | | Laufende kombinierte Messung | `[TEST] mtr example.com` | | Bericht mit 20 Messzyklen | `[TEST] mtr --report --report-cycles 20 example.com` | | Bericht ohne DNS-Auflösung | `[TEST] mtr --report --numeric --report-cycles 20 example.com` | | TCP-MTR zu Port 443 | `[TEST][PRIV] sudo mtr --tcp --port 443 --report example.com` | **Unterschiede** | Werkzeug | Schwerpunkt | |---|---| | `tracepath` | Einfacher Pfadtest und Erkennung der Path MTU; häufig ohne Root-Rechte nutzbar | | `traceroute` | Klassische Routenverfolgung mit verschiedenen Protokolloptionen | | `mtr` | Kombiniert laufende Ping- und Traceroute-Messungen | **Wichtige Hinweise zur Auswertung** - Ein einzelner nicht antwortender Hop beweist keinen Fehler. - Router können Diagnosepakete begrenzen oder ignorieren und trotzdem Nutzdaten weiterleiten. - Paketverlust ist besonders relevant, wenn er ab einem Hop beginnt und auch an allen folgenden Hops einschließlich des Ziels sichtbar bleibt. - Unterschiedliche Pfade können durch Load Balancing entstehen. - Ein erfolgreicher letzter Hop ist wichtiger als einzelne Sterne in der Mitte des Pfades. - ICMP-, UDP- und TCP-Traceroute können unterschiedliche Ergebnisse liefern.
---
8. DNS-Konfiguration und Namensauflösung prüfen Welche DNS-Werkzeuge funktionieren, hängt vom verwendeten Resolver und den installierten Paketen ab. | Aufgabe | Linux-Befehl | |---|---| | Resolver-Konfiguration prüfen | `[RO] cat /etc/resolv.conf` | | systemd-resolved-Status anzeigen | `[RO] resolvectl status` | | DNS-Server pro Schnittstelle anzeigen | `[RO] resolvectl dns` | | DNS-Domänen pro Schnittstelle anzeigen | `[RO] resolvectl domain` | | Namen über den Systemresolver abfragen | `[TEST] resolvectl query example.com` | | Auflösung über NSS testen | `[TEST] getent hosts example.com` | | IPv4- und IPv6-Ergebnisse anzeigen | `[TEST] getent ahosts example.com` | | Standard-DNS-Abfrage durchführen | `[TEST] dig example.com` | | IPv4-Adresse abfragen | `[TEST] dig A example.com` | | IPv6-Adresse abfragen | `[TEST] dig AAAA example.com` | | Mailserver abfragen | `[TEST] dig MX example.com` | | Nameserver abfragen | `[TEST] dig NS example.com` | | Kurzausgabe erzeugen | `[TEST] dig +short example.com` | | Bestimmten DNS-Server verwenden | `[TEST] dig @192.0.2.53 example.com` | | Vollständigen Delegationsweg prüfen | `[TEST] dig +trace example.com` | | Reverse-DNS-Abfrage durchführen | `[TEST] dig -x 192.0.2.10` | | Alternative kompakte Abfrage | `[TEST] host example.com` | | Reverse-Abfrage mit `host` | `[TEST] host 192.0.2.10` | **Warum können die Ergebnisse unterschiedlich sein?** | Werkzeug | Verwendeter Weg | |---|---| | `getent hosts` | Systemweite Name Service Switch-Konfiguration aus `/etc/nsswitch.conf` | | `resolvectl query` | systemd-resolved | | `dig` | Direkte DNS-Abfrage; berücksichtigt nicht automatisch alle NSS-Quellen | | `host` | Direkte DNS-Abfrage | | Anwendung | Kann eigenen Resolver, eigenen Cache oder DNS over HTTPS verwenden | **Zusätzliche Prüfungen** | Aufgabe | Linux-Befehl | |---|---| | NSS-Reihenfolge prüfen | `[RO] grep '^hosts:' /etc/nsswitch.conf` | | Lokale Hosts-Datei prüfen | `[RO] cat /etc/hosts` | | Status von systemd-resolved prüfen | `[RO] systemctl status systemd-resolved --no-pager` | | DNS-Protokoll anzeigen | `[RO][PRIV] sudo journalctl -u systemd-resolved --since "30 minutes ago"` | | DNS-Statistik anzeigen | `[RO] resolvectl statistics` | **Typische Fehlerbilder** - Falscher DNS-Server ist eingetragen. - `/etc/resolv.conf` zeigt auf eine nicht erreichbare Adresse. - `/etc/resolv.conf` ist ein Symlink auf eine unerwartete Datei. - Split-DNS oder VPN weist bestimmten Domänen andere Resolver zu. - `/etc/hosts` überschreibt das erwartete DNS-Ergebnis. - `dig` funktioniert, eine Anwendung jedoch nicht. - Interne Namen werden fälschlicherweise an einen öffentlichen DNS-Server gesendet. - IPv4- und IPv6-Auflösung liefern unterschiedliche Ergebnisse. > Interne Hostnamen und DNS-Zonen können sensible Unternehmensinformationen darstellen. Sie sollten nicht unüberlegt an öffentliche Resolver gesendet werden.
---
9. NetworkManager mit nmcli diagnostizieren `nmcli` ist das Kommandozeilenwerkzeug für NetworkManager. | Aufgabe | Linux-Befehl | |---|---| | Allgemeinen Status anzeigen | `[RO] nmcli general status` | | Prüfen, ob NetworkManager läuft | `[RO] nmcli -terse -fields RUNNING general` | | Gerätestatus anzeigen | `[RO] nmcli device status` | | Details aller Geräte anzeigen | `[RO] nmcli device show` | | Details einer Schnittstelle anzeigen | `[RO] nmcli device show enp1s0` | | Verbindungprofile auflisten | `[RO] nmcli connection show` | | Aktive Profile anzeigen | `[RO] nmcli connection show --active` | | Detailinformationen eines Profils anzeigen | `[RO] nmcli connection show "PROFILNAME"` | | IP-Adressen eines Profils anzeigen | `[RO] nmcli -get-values IP4.ADDRESS connection show "PROFILNAME"` | | DNS-Daten eines Profils anzeigen | `[RO] nmcli -get-values IP4.DNS connection show "PROFILNAME"` | | NetworkManager-Konnektivitätsstatus anzeigen | `[RO] nmcli networking connectivity` | | Konnektivität neu prüfen | `[TEST] nmcli networking connectivity check` | | WLAN-Zustand anzeigen | `[RO] nmcli radio wifi` | | Sichtbare WLANs auflisten | `[TEST] nmcli device wifi list` | | Änderungen überwachen | `[RO] nmcli monitor` | > Für Skripte sollten die vollständigen Befehlsnamen statt möglicherweise mehrdeutiger Abkürzungen verwendet werden. **Wichtige Gerätezustände** | Zustand | Bedeutung | |---|---| | `connected` | Gerät verwendet ein aktives Verbindungsprofil | | `disconnected` | Gerät ist vorhanden, aber nicht verbunden | | `connecting` | Verbindungsaufbau läuft | | `unavailable` | Gerät kann momentan nicht verwendet werden | | `unmanaged` | NetworkManager verwaltet dieses Gerät nicht | **Wichtiger Unterschied** - **Device:** Tatsächliche physische oder virtuelle Netzwerkschnittstelle. - **Connection:** Gespeichertes NetworkManager-Verbindungsprofil. - Ein Gerät kann mehrere passende Profile besitzen, aber normalerweise nur ein aktives Profil gleichzeitig verwenden.
---
10. systemd-networkd mit networkctl diagnostizieren `networkctl` zeigt den Zustand von Schnittstellen, wenn systemd-networkd verwendet wird. | Aufgabe | Linux-Befehl | |---|---| | Schnittstellenübersicht anzeigen | `[RO] networkctl list` | | Gesamtstatus anzeigen | `[RO] networkctl status` | | Einzelne Schnittstelle anzeigen | `[RO] networkctl status enp1s0` | | LLDP-Nachbarn anzeigen | `[RO] networkctl lldp` | | Status von systemd-networkd anzeigen | `[RO] systemctl status systemd-networkd --no-pager` | | Protokoll der letzten 30 Minuten anzeigen | `[RO][PRIV] sudo journalctl -u systemd-networkd --since "30 minutes ago"` | | Konfigurationsdateien auflisten | `[RO] find /etc/systemd/network /run/systemd/network /usr/lib/systemd/network -maxdepth 1 -type f 2>/dev/null` | **Typische Fehlerbilder** - Eine Schnittstelle ist `unmanaged`. - Keine passende `.network`-Datei trifft auf die Schnittstelle zu. - Mehrere Konfigurationsdateien konkurrieren miteinander. - NetworkManager und systemd-networkd sollen dieselbe Schnittstelle verwalten. - DHCP läuft nicht oder liefert keine Adresse. - Die Schnittstelle befindet sich im Zustand `configuring` oder `failed`. > Nicht gleichzeitig davon ausgehen, dass NetworkManager und systemd-networkd dieselbe Schnittstelle verwalten. Zuerst muss festgestellt werden, welcher Dienst tatsächlich zuständig ist.
---
11. Link, Treiber und Hardware mit ethtool prüfen `ethtool` liefert Informationen über Ethernet-Schnittstellen, Treiber und Aushandlung. | Aufgabe | Linux-Befehl | |---|---| | Linkeinstellungen anzeigen | `[RO] ethtool enp1s0` | | Treiberinformationen anzeigen | `[RO] ethtool -i enp1s0` | | Schnittstellenstatistik anzeigen | `[RO][PRIV] sudo ethtool -S enp1s0` | | Offload-Funktionen anzeigen | `[RO] ethtool -k enp1s0` | | Pause-Parameter anzeigen | `[RO] ethtool -a enp1s0` | | Ringpuffer anzeigen | `[RO][PRIV] sudo ethtool -g enp1s0` | | Zeitstempelfunktionen anzeigen | `[RO] ethtool -T enp1s0` | **Wichtige Angaben** | Angabe | Bedeutung | |---|---| | `Speed` | Ausgehandelte Geschwindigkeit | | `Duplex` | Halb- oder Vollduplex | | `Auto-negotiation` | Automatische Aushandlung aktiviert oder deaktiviert | | `Link detected` | Physischer Link erkannt | | `Port` | Verwendeter Anschlusstyp | | `driver` | Verwendetes Kernelmodul | | `version` | Treiberversion | | `firmware-version` | Firmwareversion des Adapters | **Typische Fehlerbilder** - `Link detected: no` - Unerwartet niedrige Geschwindigkeit - Half-Duplex statt Full-Duplex - Unterschiedliche feste Einstellungen an beiden Link-Enden - Steigende CRC-, Frame-, Drop- oder Timeout-Zähler - Falscher oder sehr alter Treiber - Treiber- oder Firmwarefehler im Kernelprotokoll
---
12. Offene Ports, Verbindungen und Prozesse mit ss prüfen `ss` ist das zentrale moderne Werkzeug zur Untersuchung von Sockets und ersetzt viele frühere `netstat`-Anwendungsfälle. | Aufgabe | Linux-Befehl | |---|---| | Socket-Zusammenfassung anzeigen | `[RO] ss -summary` | | Lauschende TCP-Ports anzeigen | `[RO] ss -listen -tcp -numeric` | | Lauschende TCP- und UDP-Ports anzeigen | `[RO] ss -listen -numeric -tcp -udp` | | Ports mit Prozessen anzeigen | `[RO][PRIV] sudo ss -listen -numeric -tcp -udp -processes` | | Alle TCP-Verbindungen anzeigen | `[RO] ss -all -tcp -numeric` | | Bestehende TCP-Verbindungen anzeigen | `[RO] ss -tcp -numeric state established` | | TCP-Verbindungen mit internen Informationen | `[RO] ss -tcp -numeric -info` | | Lokalen Port 443 prüfen | `[RO] ss -listen -tcp -numeric 'sport = :443'` | | Verbindungen zu Zielport 443 anzeigen | `[RO] ss -tcp -numeric 'dport = :443'` | | UNIX-Sockets anzeigen | `[RO] ss -x -all` | **Häufig verwendete Kurzform** ```bash sudo ss -lntup ``` Die Optionen bedeuten: | Option | Bedeutung | |---|---| | `-l` | Nur lauschende Sockets | | `-n` | Numerische Adressen und Ports | | `-t` | TCP | | `-u` | UDP | | `-p` | Zugehörige Prozesse anzeigen | **Interpretation** | Beobachtung | Mögliche Bedeutung | |---|---| | Erwarteter Port fehlt | Dienst läuft nicht oder lauscht auf einem anderen Port | | Dienst lauscht nur auf `127.0.0.1` | Nur lokale Verbindungen möglich | | Dienst lauscht auf `0.0.0.0` | Lauscht grundsätzlich auf allen IPv4-Adressen | | Dienst lauscht auf `::` | Lauscht auf IPv6; IPv4-Verhalten hängt zusätzlich von System und Anwendung ab | | Viele Verbindungen in `SYN-SENT` | Ziel oder Firewall antwortet möglicherweise nicht | | Viele Verbindungen in `SYN-RECV` | Viele eingehende, noch nicht vollständig aufgebaute Verbindungen | | Große `Send-Q` | Daten können möglicherweise nicht schnell genug gesendet werden | | Große `Recv-Q` | Anwendung verarbeitet empfangene Daten möglicherweise nicht schnell genug |
---
13. Ports und Prozesse mit lsof und fuser zuordnen | Aufgabe | Linux-Befehl | |---|---| | Alle Netzwerkdateien anzeigen | `[RO][PRIV] sudo lsof -numeric -P -i` | | Lauschende TCP-Ports anzeigen | `[RO][PRIV] sudo lsof -numeric -P -iTCP -sTCP:LISTEN` | | TCP-Port 443 untersuchen | `[RO][PRIV] sudo lsof -numeric -P -iTCP:443` | | UDP-Port 53 untersuchen | `[RO][PRIV] sudo lsof -numeric -P -iUDP:53` | | Prozess auf TCP-Port 443 suchen | `[RO][PRIV] sudo fuser -verbose 443/tcp` | | Prozess auf UDP-Port 53 suchen | `[RO][PRIV] sudo fuser -verbose 53/udp` | | Prozessdetails anhand der PID anzeigen | `[RO] ps -fp 1234` | | Ausführliche Prozessinformationen anzeigen | `[RO] ps -p 1234 -o pid,ppid,user,group,cmd` | > Bei fehlenden Root-Rechten werden möglicherweise nicht alle Prozessinformationen angezeigt.
---
14. TCP- und UDP-Ports aktiv testen | Aufgabe | Linux-Befehl | |---|---| | TCP-Port testen | `[TEST] nc -verbose -zero -wait 3 example.com 443` | | SSH-Port testen | `[TEST] nc -verbose -zero -wait 3 192.0.2.10 22` | | Mehrere Ports testen | `[TEST] nc -verbose -zero -wait 3 192.0.2.10 22 80 443` | | UDP-Port testen | `[TEST] nc -verbose -zero -udp -wait 3 192.0.2.53 53` | | Bash-TCP-Test durchführen | `[TEST] timeout 3 bash -c ' Ein UDP-Test mit `nc` kann ohne Antwort nicht zuverlässig beweisen, ob der UDP-Port offen oder geschlossen ist. UDP besitzt keinen TCP-Verbindungsaufbau.
---
15. Firewallstatus lesend prüfen Linux-Systeme können unterschiedliche Werkzeuge zur Firewallverwaltung einsetzen. Zuerst muss festgestellt werden, welches System tatsächlich aktiv ist. | Aufgabe | Linux-Befehl | |---|---| | nftables-Regelwerk anzeigen | `[RO][PRIV][SENS] sudo nft list ruleset` | | iptables-Filterregeln anzeigen | `[RO][PRIV][SENS] sudo iptables -S` | | iptables-Regeln mit Zählern anzeigen | `[RO][PRIV][SENS] sudo iptables -L -numeric -verbose` | | IPv6-iptables-Regeln anzeigen | `[RO][PRIV][SENS] sudo ip6tables -S` | | UFW-Status anzeigen | `[RO][PRIV] sudo ufw status verbose` | | firewalld-Status prüfen | `[RO] firewall-cmd --state` | | Aktive firewalld-Zonen anzeigen | `[RO][PRIV] sudo firewall-cmd --get-active-zones` | | Regeln der aktiven Zone anzeigen | `[RO][PRIV][SENS] sudo firewall-cmd --list-all` | | Alle firewalld-Zonen anzeigen | `[RO][PRIV][SENS] sudo firewall-cmd --list-all-zones` | | nftables-Dienststatus anzeigen | `[RO] systemctl status nftables --no-pager` | | firewalld-Dienststatus anzeigen | `[RO] systemctl status firewalld --no-pager` | | UFW-Dienststatus anzeigen | `[RO] systemctl status ufw --no-pager` | **Prüfpunkte** - Welches Firewall-Frontend wird tatsächlich verwendet? - Welches Regelwerk ist im Kernel aktiv? - Welche Eingangs- und Ausgangsregeln gelten? - Auf welche Schnittstelle oder Zone bezieht sich eine Regel? - Stimmen IPv4- und IPv6-Regeln überein? - Erhöhen sich die Paket- oder Bytezähler einer relevanten Regel? - Wird ein Port lokal geöffnet, aber durch die Firewall blockiert? > Die Firewall nicht pauschal deaktivieren. Zuerst müssen Dienstbindung, Route, verwendete Schnittstelle und passende Regeln geprüft werden.
---
16. Netzwerkdienste und Protokolle prüfen | Aufgabe | Linux-Befehl | |---|---| | Fehlgeschlagene Dienste anzeigen | `[RO] systemctl --failed` | | NetworkManager-Status anzeigen | `[RO] systemctl status NetworkManager --no-pager` | | systemd-networkd-Status anzeigen | `[RO] systemctl status systemd-networkd --no-pager` | | systemd-resolved-Status anzeigen | `[RO] systemctl status systemd-resolved --no-pager` | | Dienstprotokoll anzeigen | `[RO][PRIV] sudo journalctl -u NetworkManager --since "30 minutes ago"` | | networkd-Protokoll anzeigen | `[RO][PRIV] sudo journalctl -u systemd-networkd --since "30 minutes ago"` | | resolved-Protokoll anzeigen | `[RO][PRIV] sudo journalctl -u systemd-resolved --since "30 minutes ago"` | | Kernelmeldungen zum Netzwerk filtern | `[RO][PRIV] sudo dmesg --human \| grep -Ei 'link|network|ethernet|firmware|renamed|timeout|carrier'` | | Kernelmeldungen des aktuellen Starts | `[RO][PRIV] sudo journalctl -kernel -boot` | | Letzte Kernelmeldungen live verfolgen | `[RO][PRIV] sudo journalctl -kernel -follow` | | Startzeit eines Dienstes anzeigen | `[RO] systemctl show NetworkManager -property ActiveEnterTimestamp` | **Typische Protokollhinweise** - `link is down` - `link becomes ready` - `carrier lost` - `renamed from eth0` - `DHCP timeout` - `no lease` - `firmware failed to load` - `authentication failed` - `activation failed` - `DNSSEC validation failed` - `network unreachable` > Protokolle müssen immer mit Zeitstempel, betroffener Schnittstelle und vorhergehenden Ereignissen ausgewertet werden. Eine einzelne Meldung ohne Kontext reicht selten zur Ursachenbestimmung.
---
17. Diagnoseinformationen sichern und vergleichen | Aufgabe | Linux-Befehl | |---|---| | Linkinformationen speichern | `[RO][FILE][SENS] ip -details -statistics link show > link-status.txt` | | IP-Adressen speichern | `[RO][FILE][SENS] ip address show > ip-addresses.txt` | | Routingtabellen speichern | `[RO][FILE][SENS] ip route show table all > routes.txt` | | Policy-Regeln speichern | `[RO][FILE][SENS] ip rule show > routing-rules.txt` | | Nachbartabelle speichern | `[RO][FILE][SENS] ip neighbour show > neighbours.txt` | | Ports und Prozesse speichern | `[RO][PRIV][FILE][SENS] sudo ss -lntup > listening-ports.txt` | | NetworkManager-Status speichern | `[RO][FILE][SENS] nmcli device show > networkmanager-devices.txt` | | Resolverstatus speichern | `[RO][FILE][SENS] resolvectl status > resolver-status.txt` | | Netzwerkprotokolle speichern | `[RO][PRIV][FILE][SENS] sudo journalctl -u NetworkManager --since "1 hour ago" > networkmanager-log.txt` | **Zwei Messzeitpunkte vergleichen** ```bash ip -brief address show > addresses-vorher.txt ip route show table all > routes-vorher.txt # Messung oder freigegebene Änderung durchführen ip -brief address show > addresses-nachher.txt ip route show table all > routes-nachher.txt diff -u addresses-vorher.txt addresses-nachher.txt diff -u routes-vorher.txt routes-nachher.txt ``` **Hinweise** - Diagnoseausgaben können interne IP-Adressen, DNS-Namen, MAC-Adressen, Benutzer, Prozesse und Netzstrukturen enthalten. - Dateien müssen entsprechend den betrieblichen Datenschutz- und Sicherheitsvorgaben behandelt werden. - Vor einer Weitergabe müssen vertrauliche Inhalte geprüft und gegebenenfalls redigiert werden. - Passwörter, private Schlüssel, Tokens und vollständige VPN-Konfigurationen gehören nicht in ein allgemeines Diagnoselog.
---
18. Eingreifende Befehle nur nach der Diagnose verwenden Die folgenden Befehle verändern den Systemzustand und können insbesondere über SSH die eigene Verbindung unterbrechen. | Maßnahme | Linux-Befehl | Auswirkung | |---|---|---| | Schnittstelle deaktivieren | `[CHANGE][PRIV][DISRUPT] sudo ip link set dev enp1s0 down` | Verbindung wird unterbrochen | | Schnittstelle aktivieren | `[CHANGE][PRIV] sudo ip link set dev enp1s0 up` | Schnittstelle wird aktiviert | | NetworkManager-Gerät trennen | `[CHANGE][PRIV][DISRUPT] sudo nmcli device disconnect enp1s0` | Aktive Verbindung wird getrennt | | NetworkManager-Gerät verbinden | `[CHANGE][PRIV] sudo nmcli device connect enp1s0` | NetworkManager versucht eine Verbindung aufzubauen | | Verbindungsprofil neu aktivieren | `[CHANGE][PRIV][DISRUPT] sudo nmcli connection up "PROFILNAME"` | Profil wird aktiviert beziehungsweise neu angewendet | | NetworkManager neu starten | `[CHANGE][PRIV][DISRUPT] sudo systemctl restart NetworkManager` | Verwaltete Verbindungen können unterbrochen werden | | systemd-networkd neu starten | `[CHANGE][PRIV][DISRUPT] sudo systemctl restart systemd-networkd` | Verwaltete Verbindungen können unterbrochen werden | | DNS-Cache leeren | `[CHANGE][PRIV] sudo resolvectl flush-caches` | Lokale DNS-Cacheeinträge werden entfernt | **Vor einem Eingriff prüfen** - Erfolgt der Zugriff lokal oder über SSH? - Betrifft die Maßnahme die Schnittstelle der eigenen Sitzung? - Ist die aktuelle Konfiguration dokumentiert? - Ist bekannt, welcher Netzwerkdienst die Schnittstelle verwaltet? - Besteht Konsolen-, Out-of-Band- oder Hypervisorzugriff? - Gibt es eine Rückfallmöglichkeit? - Sind Auswirkungen auf Container, virtuelle Maschinen, Bridges, Bonds oder VLANs bekannt? - Ist eine betriebliche Freigabe erforderlich? > Auf einem entfernten System darf die aktive Managementschnittstelle nicht ohne gesicherten Rückfallweg deaktiviert oder neu gestartet werden.
---
19. Praktische Linux-Diagnosereihenfolge **Schritt 1 – System und Netzwerkverwaltung identifizieren** ```bash cat /etc/os-release systemctl is-active NetworkManager systemctl is-active systemd-networkd ``` **Schritt 2 – Linkstatus prüfen** ```bash ip -brief link show ip -statistics link show ``` **Schritt 3 – IP-Adressen prüfen** ```bash ip -brief address show ``` **Schritt 4 – Standardroute und Routenauswahl prüfen** ```bash ip route show default ip route get 1.1.1.1 ip rule show ``` **Schritt 5 – Nachbartabelle prüfen** ```bash ip neighbour show ``` **Schritt 6 – Standardgateway testen** ```bash ping -c 4 192.0.2.1 ``` **Schritt 7 – Externe IP-Adresse testen** ```bash ping -c 4 1.1.1.1 ``` **Schritt 8 – DNS-Konfiguration prüfen** ```bash cat /etc/resolv.conf resolvectl status ``` **Schritt 9 – DNS-Auflösung testen** ```bash getent hosts example.com dig example.com ``` **Schritt 10 – Zielport testen** ```bash nc -vz -w 3 example.com 443 ``` **Schritt 11 – Lokale Ports und Prozesse prüfen** ```bash sudo ss -lntup ``` **Schritt 12 – Netzwerkpfad untersuchen** ```bash tracepath example.com mtr --report --numeric --report-cycles 20 example.com ``` **Schritt 13 – Firewallstatus prüfen** ```bash sudo nft list ruleset ``` **Schritt 14 – Netzwerkprotokolle prüfen** ```bash sudo journalctl -u NetworkManager --since "30 minutes ago" sudo journalctl -kernel --since "30 minutes ago" ``` **Diagnoselogik** | Ergebnis | Nächster Schwerpunkt | |---|---| | Schnittstelle fehlt | Hardware, Treiber, virtuelle Maschine oder Gerätezuordnung prüfen | | Schnittstelle `DOWN` | Administrativen Zustand und Netzwerkverwaltung prüfen | | Kein `LOWER_UP` beziehungsweise kein Carrier | Kabel, WLAN, Switchport oder Linkpartner prüfen | | Keine passende IP-Adresse | DHCP oder statische Konfiguration prüfen | | Keine Standardroute | Gateway- und Profilkonfiguration prüfen | | Gateway nicht erreichbar | Lokales Netz, VLAN, Bridge, Switch oder WLAN prüfen | | Externe IP erreichbar, DNS-Name nicht | DNS-Konfiguration und Resolver prüfen | | Ziel-IP erreichbar, Zielport nicht | Dienst, Portbindung und Firewall prüfen | | Falsche Quelladresse oder Schnittstelle | Routing, Policy Routing, VPN und Metrik prüfen | | Dienst lauscht lokal, ist extern aber nicht erreichbar | Firewall, Routing, NAT und Bind-Adresse prüfen |
--- **Kurzreferenz** | Diagnoseziel | Linux-Befehl | |---|---| | Schnittstellenstatus | `[RO] ip -brief link show` | | Schnittstellenstatistik | `[RO] ip -statistics link show` | | IP-Adressen | `[RO] ip -brief address show` | | IPv4-Adressen | `[RO] ip -4 address show` | | IPv6-Adressen | `[RO] ip -6 address show` | | Standardroute | `[RO] ip route show default` | | Route zu einem Ziel | `[RO] ip route get 1.1.1.1` | | Policy Routing | `[RO] ip rule show` | | Nachbartabelle | `[RO] ip neighbour show` | | Gateway testen | `[TEST] ping -c 4 192.0.2.1` | | Netzwerkpfad | `[TEST] tracepath example.com` | | Fortlaufende Pfadanalyse | `[TEST] mtr example.com` | | Resolverstatus | `[RO] resolvectl status` | | Namensauflösung über NSS | `[TEST] getent hosts example.com` | | DNS-Abfrage | `[TEST] dig example.com` | | NetworkManager-Status | `[RO] nmcli general status` | | NetworkManager-Geräte | `[RO] nmcli device status` | | systemd-networkd-Status | `[RO] networkctl status` | | Ethernet-Link | `[RO] ethtool enp1s0` | | Treiberinformationen | `[RO] ethtool -i enp1s0` | | Lauschende Ports | `[RO][PRIV] sudo ss -lntup` | | TCP-Port testen | `[TEST] nc -vz -w 3 example.com 443` | | Port einem Prozess zuordnen | `[RO][PRIV] sudo lsof -nP -iTCP:443` | | nftables-Regeln | `[RO][PRIV] sudo nft list ruleset` | | Dienststatus | `[RO] systemctl status DIENST --no-pager` | | Dienstprotokoll | `[RO][PRIV] sudo journalctl -u DIENST` | | Kernelprotokoll | `[RO][PRIV] sudo journalctl -kernel` | --- **Veraltete und moderne Befehle** | Älterer Befehl | Bevorzugter moderner Befehl | |---|---| | `ifconfig` | `ip address`, `ip link` | | `route -n` | `ip route` | | `arp -n` | `ip neighbour` | | `netstat -lntup` | `ss -lntup` | > Ältere Werkzeuge können weiterhin installiert sein. Für neue Dokumentationen und aktuelle Linux-Systeme sollten grundsätzlich die `iproute2`-Werkzeuge verwendet werden. --- **Merksatz** > Die Linux-Netzwerkdiagnose folgt einer festen Kette: Schnittstelle → Link → IP-Adresse → Nachbartabelle → Route → Gateway → DNS → Zielport → lokaler Dienst → Firewall → Protokolle. --- **Quellen** - [Linux-Manpage – ip](https://man7.org/linux/man-pages/man8/ip.8.html) - [Linux-Manpage – ip-address](https://man7.org/linux/man-pages/man8/ip-address.8.html) - [Linux-Manpage – ip-link](https://man7.org/linux/man-pages/man8/ip-link.8.html) - [Linux-Manpage – ip-route](https://man7.org/linux/man-pages/man8/ip-route.8.html) - [Linux-Manpage – ip-neighbour](https://man7.org/linux/man-pages/man8/ip-neighbour.8.html) - [Linux-Manpage – ss](https://man7.org/linux/man-pages/man8/ss.8.html) - [Linux-Manpage – ping](https://man7.org/linux/man-pages/man8/ping.8.html) - [NetworkManager-Dokumentation – nmcli](https://networkmanager.dev/docs/api/latest/nmcli.html) - [NetworkManager-Dokumentation – nmcli-Beispiele](https://networkmanager.dev/docs/api/latest/nmcli-examples.html) - [systemd-Dokumentation – networkctl](https://www.freedesktop.org/software/systemd/man/latest/networkctl.html) - [systemd-Dokumentation – resolvectl](https://www.freedesktop.org/software/systemd/man/latest/resolvectl.html) - [systemd-Dokumentation – journalctl](https://www.freedesktop.org/software/systemd/man/latest/journalctl.html) # 2.4 macOS-Netzwerkdiagnose macOS basiert auf Darwin und stellt zahlreiche BSD- und Apple-spezifische Netzwerkwerkzeuge bereit. Einige Befehle ähneln Linux-Kommandos, verwenden aber teilweise andere Optionen und Ausgabeformate. Wichtige macOS-Werkzeuge sind: - `networksetup` für Netzwerkdienste und deren Konfiguration - `scutil` für System Configuration, DNS, Proxys und Netzwerkstatus - `ifconfig` für Netzwerkschnittstellen - `route` und `netstat` für Routingtabellen - `arp` und `ndp` für Nachbartabellen - `ping` und `traceroute` für Erreichbarkeit und Netzwerkpfade - `dig`, `host` und `dscacheutil` für DNS - `wdutil` und Wireless Diagnostics für WLAN - `networkQuality` für Kapazität und Reaktionsfähigkeit - `lsof`, `netstat` und `nc` für Ports und Verbindungen - `log` für das Unified Logging System - `socketfilterfw` und `pfctl` für die Firewalldiagnose --- **Kennzeichnungen** | Kennzeichnung | Bedeutung | |---|---| | `[RO]` | Nur lesender Befehl; verändert keine Konfiguration | | `[TEST]` | Führt einen aktiven Netzwerk- oder Verbindungstest aus | | `[PRIV]` | Benötigt Administratorrechte beziehungsweise `sudo` | | `[CHANGE]` | Verändert einen Zustand oder eine Konfiguration | | `[DISRUPT]` | Kann eine Verbindung oder einen Dienst unterbrechen | | `[FILE]` | Schreibt Informationen in eine Datei | | `[SENS]` | Ausgabe kann sensible System-, Netzwerk- oder Prozessdaten enthalten | > Vor Änderungen sollten Netzwerkdienst, Schnittstelle, IP-Konfiguration, Route, DNS-Server und aktive VPN- beziehungsweise Proxykonfiguration dokumentiert werden. ---
1. macOS-Version und verfügbare Werkzeuge prüfen | Aufgabe | macOS-Befehl | |---|---| | macOS-Version anzeigen | `[RO] sw_vers` | | Produktversion kompakt anzeigen | `[RO] sw_vers -productVersion` | | Build-Nummer anzeigen | `[RO] sw_vers -buildVersion` | | Kernelversion anzeigen | `[RO] uname -a` | | Prozessorarchitektur anzeigen | `[RO] uname -m` | | Hardwareübersicht anzeigen | `[RO] system_profiler SPHardwareDataType` | | Softwareübersicht anzeigen | `[RO] system_profiler SPSoftwareDataType` | | Prüfen, ob ein Befehl vorhanden ist | `[RO] command -v networkQuality` | | Mehrere Werkzeuge prüfen | `[RO] command -v networksetup scutil ifconfig route netstat arp ndp ping traceroute dig lsof nc wdutil networkQuality` | | Hilfe zu `networksetup` anzeigen | `[RO] networksetup -help` | | Lokale Handbuchseite öffnen | `[RO] man networksetup` | | Handbuchseite zu `scutil` öffnen | `[RO] man scutil` | | Handbuchseite zu `ifconfig` öffnen | `[RO] man ifconfig` | **Hinweis zu macOS-Versionen** Nicht jedes Werkzeug steht in jeder macOS-Version zur Verfügung: - `networkQuality` ist auf aktuellen macOS-Versionen vorhanden. - `wdutil` ist auf aktuellen macOS-Versionen das Kommandozeilenwerkzeug für WLAN-Diagnosedaten. - Das frühere private `airport`-Werkzeug ist auf aktuellen macOS-Versionen nicht mehr als zuverlässiger Standard verfügbar. - Optionen und Ausgaben können sich zwischen macOS-Versionen ändern.
---
2. Netzwerkdienste und Hardwareports zuordnen Unter macOS muss zwischen einem Netzwerkdienst und der technischen Schnittstelle unterschieden werden. Beispiele: | Netzwerkdienst | Mögliche Schnittstelle | |---|---| | `Wi-Fi` | `en0` oder eine andere `en`-Schnittstelle | | `Ethernet` | `en0`, `en1`, `en5` oder eine andere Schnittstelle | | USB-Ethernet | Abhängig vom angeschlossenen Adapter | | Thunderbolt Bridge | Bridge- beziehungsweise Thunderbolt-Schnittstelle | | VPN | Häufig `utun0`, `utun1` oder eine weitere `utun`-Schnittstelle | **Zuordnung prüfen** | Aufgabe | macOS-Befehl | |---|---| | Alle Hardwareports auflisten | `[RO] networksetup -listallhardwareports` | | Alle Netzwerkdienste auflisten | `[RO] networksetup -listallnetworkservices` | | Reihenfolge der Netzwerkdienste anzeigen | `[RO] networksetup -listnetworkserviceorder` | | Informationen zum Dienst Wi-Fi anzeigen | `[RO] networksetup -getinfo "Wi-Fi"` | | Informationen zum Dienst Ethernet anzeigen | `[RO] networksetup -getinfo "Ethernet"` | | Aktive Netzwerksicht anzeigen | `[RO] scutil --nwi` | | Netzwerkkonfiguration über System Profiler anzeigen | `[RO][SENS] system_profiler SPNetworkDataType` | **Wichtiger Unterschied** - `Wi-Fi` ist normalerweise der Name eines Netzwerkdienstes. - `en0` ist der Name einer technischen Netzwerkschnittstelle. - `networksetup` erwartet je nach Option entweder einen Dienstnamen oder einen Gerätenamen. - Der Gerätename darf nicht anhand eines anderen Macs geraten werden. > Vor jedem Befehl mit `en0`, `en1` oder einem Dienstnamen muss die tatsächliche Zuordnung mit `networksetup -listallhardwareports` geprüft werden.
---
3. Netzwerkschnittstellen und Linkstatus prüfen | Aufgabe | macOS-Befehl | |---|---| | Alle Schnittstellen anzeigen | `[RO] ifconfig -a` | | Einzelne Schnittstelle anzeigen | `[RO] ifconfig en0` | | Aktive Schnittstellen anzeigen | `[RO] ifconfig -u` | | Inaktive Schnittstellen anzeigen | `[RO] ifconfig -d` | | Schnittstellennamen auflisten | `[RO] ifconfig -l` | | Schnittstellenstatistik anzeigen | `[RO] netstat -ibn` | | Netzwerkhardware anzeigen | `[RO][SENS] system_profiler SPNetworkDataType` | | Ethernet-Hardwareinformationen anzeigen | `[RO] system_profiler SPEthernetDataType` | **Wichtige Angaben von `ifconfig`** | Angabe | Bedeutung | |---|---| | `UP` | Schnittstelle wurde administrativ aktiviert | | `RUNNING` | Schnittstelle ist betriebsbereit | | `ACTIVE` | Aktiver physischer beziehungsweise logischer Link | | `status: active` | Verbindung wurde erkannt | | `status: inactive` | Keine aktive Verbindung erkannt | | `ether` | MAC-Adresse | | `inet` | IPv4-Adresse | | `inet6` | IPv6-Adresse | | `netmask` | Netzmaske, häufig hexadezimal dargestellt | | `broadcast` | IPv4-Broadcastadresse | | `mtu` | Maximum Transmission Unit | | `media` | Medium, Geschwindigkeit und Duplexmodus | **Typische Fehlerbilder** | Beobachtung | Mögliche Bedeutung | |---|---| | `status: inactive` | Kein Link, WLAN getrennt, Kabel- oder Portproblem | | Schnittstelle fehlt | Adapter, Treiber, USB-/Thunderbolt-Verbindung oder Hardware prüfen | | Keine `inet`-Adresse | Keine verwendbare IPv4-Konfiguration | | Nur `169.254.x.x` | Keine reguläre IPv4-Konfiguration beziehungsweise DHCP-Zuweisung | | Unerwartete MTU | VPN-, Tunnel- oder Fragmentierungsproblem möglich | | Viele Fehler in `netstat -ibn` | Link-, Adapter-, Treiber- oder Überlastungsproblem möglich |
---
4. IP-Konfiguration und DHCP prüfen | Aufgabe | macOS-Befehl | |---|---| | IPv4-Adresse einer Schnittstelle anzeigen | `[RO] ipconfig getifaddr en0` | | Gesamte Schnittstellenkonfiguration anzeigen | `[RO] ifconfig en0` | | Informationen des Dienstes Wi-Fi anzeigen | `[RO] networksetup -getinfo "Wi-Fi"` | | Informationen des Dienstes Ethernet anzeigen | `[RO] networksetup -getinfo "Ethernet"` | | DHCP-Paketinformationen anzeigen | `[RO][PRIV][SENS] sudo ipconfig getpacket en0` | | DHCP-Server auslesen | `[RO][PRIV] sudo ipconfig getoption en0 server_identifier` | | Subnetzmaske auslesen | `[RO][PRIV] sudo ipconfig getoption en0 subnet_mask` | | Router aus DHCP auslesen | `[RO][PRIV] sudo ipconfig getoption en0 router` | | DNS-Server aus DHCP auslesen | `[RO][PRIV] sudo ipconfig getoption en0 domain_name_server` | | IPv6-Konfiguration anzeigen | `[RO] ifconfig en0 \| grep inet6` | | Netzwerkstatus zusammengefasst anzeigen | `[RO] scutil --nwi` | **Prüfpunkte** - Wurde die erwartete IPv4-Adresse vergeben? - Stimmt die Subnetzmaske? - Ist der Router korrekt? - Ist der erwartete DHCP-Server sichtbar? - Sind DNS-Server vorhanden? - Befindet sich die Adresse im Bereich `169.254.0.0/16`? - Existieren mehrere aktive Schnittstellen mit konkurrierenden Routen? - Ist ein VPN aktiv, das die Routenauswahl verändert? > `ipconfig getpacket` zeigt die zuletzt erhaltenen DHCP-Informationen. Die Ausgabe kann interne Netzwerkinformationen enthalten.
---
5. Routingtabelle und verwendeten Netzwerkweg prüfen | Aufgabe | macOS-Befehl | |---|---| | Standardroute anzeigen | `[RO] route -n get default` | | Route zu einer IPv4-Adresse anzeigen | `[RO] route -n get 1.1.1.1` | | Route zu einem DNS-Namen anzeigen | `[RO][TEST] route -n get example.com` | | IPv4-Routingtabelle anzeigen | `[RO] netstat -rn -f inet` | | IPv6-Routingtabelle anzeigen | `[RO] netstat -rn -f inet6` | | Gesamte Routingtabelle anzeigen | `[RO] netstat -rn` | | Netzwerkstatus anzeigen | `[RO] scutil --nwi` | | Aktive VPN-/Tunnel-Schnittstellen suchen | `[RO] ifconfig -l \| tr ' ' '\n' \| grep '^utun'` | | Details einer Tunnel-Schnittstelle anzeigen | `[RO] ifconfig utun0` | **Wichtige Angaben von `route -n get`** | Angabe | Bedeutung | |---|---| | `destination` | Zieladresse | | `gateway` | Nächster Router | | `interface` | Verwendete Schnittstelle | | `flags` | Eigenschaften der Route | | `recvpipe` | Empfangspufferinformationen | | `sendpipe` | Sendepufferinformationen | **Wichtige Flags der Routingtabelle** | Flag | Bedeutung | |---|---| | `U` | Route ist aktiv | | `G` | Ziel wird über ein Gateway erreicht | | `H` | Hostroute zu einem einzelnen Ziel | | `S` | Statische Route | | `C` | Geklonte Route | | `I` | Schnittstellenroute | **Typische Fehlerbilder** - Standardroute fehlt. - Standardroute verwendet die falsche Schnittstelle. - VPN- oder `utun`-Schnittstelle übernimmt die Route. - Ethernet und WLAN sind gleichzeitig aktiv und besitzen konkurrierende Wege. - Die Reihenfolge der Netzwerkdienste entspricht nicht der erwarteten Priorität. - Eine spezifischere Route überschreibt den allgemeinen Weg.
---
6. ARP- und IPv6-Nachbartabelle prüfen | Aufgabe | macOS-Befehl | |---|---| | Gesamte IPv4-ARP-Tabelle anzeigen | `[RO] arp -an` | | Bestimmte IPv4-Adresse prüfen | `[RO] arp -n 192.0.2.1` | | IPv6-Nachbartabelle anzeigen | `[RO] ndp -an` | | IPv6-Standardrouter anzeigen | `[RO] ndp -r` | | IPv6-Präfixinformationen anzeigen | `[RO] ndp -p` | | Schnittstelleninformationen anzeigen | `[RO] ndp -i en0` | **Typische Beobachtungen** | Beobachtung | Mögliche Bedeutung | |---|---| | `(incomplete)` | MAC-Auflösung wurde nicht abgeschlossen | | Kein Gateway-Eintrag | Gateway wurde noch nicht angesprochen oder ist nicht erreichbar | | Unerwartete MAC-Adresse | Doppelte IP-Adresse, anderes Gateway oder Sicherheitsproblem möglich | | Gleiche IP mit wechselnder MAC-Adresse | Hochverfügbarkeit, doppelte Adresse oder Manipulation prüfen | | IPv6-Nachbarstatus nicht erreichbar | Lokalen IPv6-Link und Router Advertisement prüfen | > Ein fehlender ARP-Eintrag beweist nicht automatisch einen Fehler. Ein Eintrag entsteht normalerweise erst, wenn das Ziel angesprochen wurde.
---
7. Erreichbarkeit mit ping prüfen | Aufgabe | macOS-Befehl | |---|---| | Vier Anfragen an das Gateway senden | `[TEST] ping -c 4 192.0.2.1` | | Externe IPv4-Adresse testen | `[TEST] ping -c 4 1.1.1.1` | | DNS-Namen testen | `[TEST] ping -c 4 example.com` | | Bestimmte Quelladresse verwenden | `[TEST] ping -S 192.0.2.10 -c 4 192.0.2.1` | | IPv6-Ziel testen | `[TEST] ping6 -c 4 2001:db8::1` | | IPv6-Link-Local-Ziel mit Schnittstelle testen | `[TEST] ping6 -c 4 fe80::1%en0` | | Paketgröße testen | `[TEST] ping -c 4 -s 1400 192.0.2.1` | | Akustisches Signal bei Antwort | `[TEST] ping -a -c 4 192.0.2.1` | **Wichtige Ergebnisse** | Wert | Bedeutung | |---|---| | `time` | Round Trip Time | | `ttl` | Verbleibende IPv4 Time to Live | | `icmp_seq` | Nummer der ICMP-Anfrage | | `packet loss` | Anteil verlorener Pakete | | `min/avg/max/stddev` | Laufzeitstatistik | **Interpretation** | Ergebnis | Mögliche Bedeutung | |---|---| | Gateway nicht erreichbar | Lokales Netz, WLAN, Kabel, VLAN oder Router prüfen | | IP-Adresse erreichbar, DNS-Name nicht | DNS-Problem wahrscheinlich | | Externe IP nicht erreichbar, Gateway erreichbar | Routing, Firewall, Provider oder Upstream prüfen | | Ping schlägt fehl, TCP-Port funktioniert | ICMP wird möglicherweise blockiert | | Hohe Laufzeitschwankungen | WLAN-Störung, Überlastung oder wechselnder Netzwerkweg | | Paketverlust | Funkstörung, Linkproblem, Überlastung oder Rate Limiting möglich |
---
8. Netzwerkpfad mit traceroute untersuchen | Aufgabe | macOS-Befehl | |---|---| | Netzwerkpfad anzeigen | `[TEST] traceroute example.com` | | Keine DNS-Auflösung durchführen | `[TEST] traceroute -n example.com` | | Anzahl der Hops begrenzen | `[TEST] traceroute -m 15 example.com` | | Wartezeit pro Probe begrenzen | `[TEST] traceroute -w 2 example.com` | | IPv6-Netzwerkpfad anzeigen | `[TEST] traceroute6 example.com` | | ICMP statt UDP verwenden | `[TEST][PRIV] sudo traceroute -I example.com` | **Auswertung** - Ein einzelner Hop ohne Antwort beweist keinen Fehler. - Router können Diagnosepakete ignorieren und Nutzdaten trotzdem weiterleiten. - Mehrere unterschiedliche Hops können durch Load Balancing entstehen. - Entscheidend ist, ob das Ziel erreicht wird. - Ein Abbruch ab einem bestimmten Hop kann auf Routing, Firewall oder eine Netzstörung hinweisen. - Unterschiedliche Protokolle können unterschiedliche Pfade beziehungsweise Antworten zeigen.
---
9. DNS-Konfiguration und Namensauflösung prüfen `scutil --dns` zeigt die tatsächlich vom macOS-System verwendete Resolverkonfiguration. Die Ausgabe kann mehrere Resolver für verschiedene Domänen und Schnittstellen enthalten. | Aufgabe | macOS-Befehl | |---|---| | Gesamte Resolverkonfiguration anzeigen | `[RO][SENS] scutil --dns` | | DNS-Server des Dienstes Wi-Fi anzeigen | `[RO] networksetup -getdnsservers "Wi-Fi"` | | DNS-Server des Dienstes Ethernet anzeigen | `[RO] networksetup -getdnsservers "Ethernet"` | | Suchdomänen anzeigen | `[RO] networksetup -getsearchdomains "Wi-Fi"` | | Namen über den Systemcache abfragen | `[TEST] dscacheutil -q host -a name example.com` | | Standard-DNS-Abfrage durchführen | `[TEST] dig example.com` | | IPv4-Adresse abfragen | `[TEST] dig A example.com` | | IPv6-Adresse abfragen | `[TEST] dig AAAA example.com` | | Mailserver abfragen | `[TEST] dig MX example.com` | | Kurzausgabe erzeugen | `[TEST] dig +short example.com` | | Bestimmten Resolver verwenden | `[TEST] dig @192.0.2.53 example.com` | | Vollständigen Delegationsweg prüfen | `[TEST] dig +trace example.com` | | Reverse-DNS-Abfrage durchführen | `[TEST] dig -x 192.0.2.10` | | Alternative Abfrage durchführen | `[TEST] host example.com` | | Lokale Hosts-Datei anzeigen | `[RO] cat /etc/hosts` | **Warum kann macOS mehrere Resolver anzeigen?** macOS kann Resolver abhängig von folgenden Faktoren auswählen: - Netzwerkdienst - VPN-Verbindung - Suchdomäne - Split-DNS-Konfiguration - verwaltetes Konfigurationsprofil - iCloud Private Relay - Network Extension - lokale Hosts-Datei - Anwendungsinterner DNS-Resolver **Typische Fehlerbilder** | Beobachtung | Mögliche Ursache | |---|---| | `dig` funktioniert, Anwendung jedoch nicht | Anwendung, Cache, Proxy oder eigener Resolver | | Öffentlicher Name funktioniert, interner nicht | Split-DNS, VPN oder interner Resolver prüfen | | Falscher DNS-Server in `scutil --dns` | Netzwerkdienst, VPN oder Profil prüfen | | Mehrere Resolver mit unterschiedlicher Reihenfolge | Domänenspezifische Resolver oder VPN-Konfiguration | | IP-Adresse erreichbar, Name nicht | DNS-Problem wahrscheinlich | | Unterschiedliche Antworten verschiedener DNS-Server | Split-DNS, Cache oder unterschiedliche Zonen | > Für die tatsächliche Resolverauswahl von macOS ist `scutil --dns` normalerweise aussagekräftiger als eine isolierte Betrachtung einzelner Konfigurationsfelder.
---
10. Proxy-, VPN- und Network-Extension-Einflüsse prüfen | Aufgabe | macOS-Befehl | |---|---| | Systemweite Proxykonfiguration anzeigen | `[RO][SENS] scutil --proxy` | | HTTP-Proxy für Wi-Fi anzeigen | `[RO] networksetup -getwebproxy "Wi-Fi"` | | HTTPS-Proxy für Wi-Fi anzeigen | `[RO] networksetup -getsecurewebproxy "Wi-Fi"` | | Automatische Proxykonfiguration anzeigen | `[RO] networksetup -getautoproxyurl "Wi-Fi"` | | Proxy-Bypass-Domänen anzeigen | `[RO][SENS] networksetup -getproxybypassdomains "Wi-Fi"` | | Aktive Netzwerksicht anzeigen | `[RO] scutil --nwi` | | Tunnel-Schnittstellen anzeigen | `[RO] ifconfig -l \| tr ' ' '\n' \| grep '^utun'` | | Systemerweiterungen anzeigen | `[RO][SENS] systemextensionsctl list` | | Netzwerkdienste nach Reihenfolge anzeigen | `[RO] networksetup -listnetworkserviceorder` | **Mögliche Einflussfaktoren** - Unternehmens-VPN - Content-Filter - Endpoint-Security-Software - DNS-Filter - Webproxy - PAC-Datei - iCloud Private Relay - lokale Firewall - Network Extension - Sicherheitssoftware eines Drittanbieters **Typisches Fehlerbild** | Beobachtung | Mögliche Ursache | |---|---| | Ping funktioniert, Webseiten nicht | Proxy, DNS, TLS, Browser oder Filtersoftware | | Nur einzelne Anwendungen betroffen | Anwendungsproxy oder anwendungsspezifische Network Extension | | Verbindung funktioniert ohne VPN | VPN-Routing, DNS oder Richtlinie prüfen | | Interne Namen funktionieren nur mit VPN | Split-DNS oder interne DNS-Zone | | Falsche Route über `utun` | VPN- oder Filtersoftware beeinflusst Routing |
---
11. WLAN-Verbindung und Funkqualität prüfen **Zuordnung und Status** | Aufgabe | macOS-Befehl | |---|---| | Wi-Fi-Hardwareport bestimmen | `[RO] networksetup -listallhardwareports` | | Wi-Fi-Energiezustand anzeigen | `[RO] networksetup -getairportpower en0` | | Verbundenes WLAN anzeigen | `[RO] networksetup -getairportnetwork en0` | | WLAN-Informationen anzeigen | `[RO][PRIV][SENS] sudo wdutil info` | | Ausführliche WLAN-Hardwareinformationen | `[RO][SENS] system_profiler SPAirPortDataType` | | WLAN-Schnittstelle anzeigen | `[RO] ifconfig en0` | > Vor der Verwendung von `en0` muss die tatsächliche Wi-Fi-Schnittstelle mit `networksetup -listallhardwareports` bestimmt werden. **Wichtige WLAN-Werte** | Wert | Bedeutung | |---|---| | `SSID` | Name des WLANs | | `BSSID` | MAC-Adresse des Access Points | | `RSSI` | Empfangssignalstärke | | `Noise` | Grundrauschen | | `Channel` | Verwendeter Funkkanal | | `Tx Rate` | Aktuelle Übertragungsrate | | `PHY Mode` | Verwendeter WLAN-Standard | | `Security` | Sicherheitsverfahren | | `MCS` | Modulation and Coding Scheme | | `NSS` | Anzahl räumlicher Datenströme | **Signalbewertung als grobe Orientierung** | RSSI | Grobe Einordnung | |---|---| | etwa `-30 dBm` | Sehr stark | | etwa `-50 dBm` | Gut | | etwa `-67 dBm` | Für viele Anwendungen noch brauchbar | | etwa `-70 dBm` | Schwach | | unter `-80 dBm` | Häufig instabil | > RSSI-Werte allein beweisen keinen Fehler. Kanalbelegung, Störungen, Rauschen, Wiederholungen, Access-Point-Auslastung und Roaming müssen ebenfalls berücksichtigt werden. **Grafische Wireless Diagnostics öffnen** 1. Wahltaste beziehungsweise `Option` gedrückt halten. 2. In der Menüleiste auf das Wi-Fi-Symbol klicken. 3. **Wireless Diagnostics öffnen** auswählen. 4. Anweisungen des Assistenten befolgen. Wireless Diagnostics verändert laut Apple nicht die Netzwerksettings. Nach einer Analyse kann eine Diagnosedatei unter `/var/tmp` erzeugt werden. Der Dateiname beginnt mit `WirelessDiagnostics` und endet mit `.tar.gz`.
---
12. Netzwerkqualität und Reaktionsfähigkeit messen `networkQuality` misst nicht nur die verfügbare Kapazität, sondern auch die Reaktionsfähigkeit der Verbindung unter Last. | Aufgabe | macOS-Befehl | |---|---| | Standardmessung durchführen | `[TEST] networkQuality` | | Ausführliche Messung durchführen | `[TEST] networkQuality -v` | | Upload und Download nacheinander messen | `[TEST] networkQuality -s` | | Bestimmte Schnittstelle verwenden | `[TEST] networkQuality -I en0` | | Hilfe anzeigen | `[RO] networkQuality -h` | | Lokale Handbuchseite öffnen | `[RO] man networkQuality` | **Typische Ergebnisfelder** | Ergebnis | Bedeutung | |---|---| | `Downlink capacity` | Gemessene Downloadkapazität | | `Uplink capacity` | Gemessene Uploadkapazität | | `Responsiveness` | Reaktionsfähigkeit unter Last | | `Idle Latency` | Latenz ohne zusätzliche Last | | `RPM` | Round-trips per Minute | **Hinweise** - Die Messung erzeugt aktiven Netzwerkverkehr. - Andere Benutzer und Anwendungen können das Ergebnis beeinflussen. - WLAN- und Ethernet-Ergebnisse sollten getrennt betrachtet werden. - Ein einzelner Test ist keine belastbare Langzeitmessung. - Für Vergleiche sollten mehrere Messungen unter ähnlichen Bedingungen durchgeführt werden. - VPN, Proxy, Filtersoftware und Private Relay können das Ergebnis beeinflussen.
---
13. Offene Ports, Verbindungen und Prozesse prüfen | Aufgabe | macOS-Befehl | |---|---| | Lauschende TCP-Ports anzeigen | `[RO][PRIV] sudo lsof -nP -iTCP -sTCP:LISTEN` | | Alle Netzwerkverbindungen anzeigen | `[RO][PRIV] sudo lsof -nP -i` | | TCP-Port 443 untersuchen | `[RO][PRIV] sudo lsof -nP -iTCP:443` | | UDP-Port 53 untersuchen | `[RO][PRIV] sudo lsof -nP -iUDP:53` | | TCP-Sockets anzeigen | `[RO] netstat -anv -p tcp` | | UDP-Sockets anzeigen | `[RO] netstat -anv -p udp` | | Netzwerkstatistik anzeigen | `[RO] netstat -s` | | Schnittstellenstatistik anzeigen | `[RO] netstat -ibn` | | Prozessdetails anzeigen | `[RO] ps -p 1234 -o pid,ppid,user,command` | **Interpretation** | Beobachtung | Mögliche Bedeutung | |---|---| | Erwarteter Port fehlt | Dienst läuft nicht oder lauscht auf einem anderen Port | | Dienst lauscht auf `127.0.0.1` | Nur lokal erreichbar | | Dienst lauscht auf `0.0.0.0` | Lauscht grundsätzlich auf allen IPv4-Schnittstellen | | Dienst lauscht auf `::` | Lauscht auf IPv6; IPv4-Verhalten ist zusätzlich zu prüfen | | Unerwarteter Prozess lauscht | Dienstzuordnung und Sicherheitslage prüfen | | Viele Verbindungen im Verbindungsaufbau | Ziel, Route, Dienst oder Firewall antwortet möglicherweise nicht |
---
14. TCP- und UDP-Ports aktiv testen | Aufgabe | macOS-Befehl | |---|---| | HTTPS-Port testen | `[TEST] nc -vz -w 3 example.com 443` | | SSH-Port testen | `[TEST] nc -vz -w 3 192.0.2.10 22` | | SMB-Port testen | `[TEST] nc -vz -w 3 192.0.2.10 445` | | Mehrere Ports testen | `[TEST] nc -vz -w 3 192.0.2.10 22 80 443` | | UDP-Port testen | `[TEST] nc -vzu -w 3 192.0.2.53 53` | **Mögliche Ergebnisse** | Ergebnis | Bedeutung | |---|---| | `succeeded` | TCP-Verbindung konnte aufgebaut werden | | `Connection refused` | Ziel erreichbar, aber Port geschlossen oder aktiv abgelehnt | | Timeout | Keine rechtzeitige Antwort; Firewall, Route oder Ziel prüfen | | `No route to host` | Kein verwendbarer Netzwerkweg oder entsprechende Rückmeldung | | Namensauflösungsfehler | DNS-Konfiguration prüfen | > Bei UDP kann ein fehlendes Ergebnis nicht zuverlässig beweisen, dass ein Port offen oder geschlossen ist.
---
15. macOS-Firewall und Packet Filter prüfen macOS besitzt verschiedene Sicherheitskomponenten: - Application Firewall - Packet Filter `pf` - Network Extensions - Content Filter und Endpoint-Security-Produkte **Application Firewall** | Aufgabe | macOS-Befehl | |---|---| | Globalen Firewallstatus anzeigen | `[RO] /usr/libexec/ApplicationFirewall/socketfilterfw --getglobalstate` | | Stealth-Modus anzeigen | `[RO] /usr/libexec/ApplicationFirewall/socketfilterfw --getstealthmode` | | Block-all-Modus anzeigen | `[RO] /usr/libexec/ApplicationFirewall/socketfilterfw --getblockall` | | Registrierte Anwendungen anzeigen | `[RO][PRIV][SENS] sudo /usr/libexec/ApplicationFirewall/socketfilterfw --listapps` | **Packet Filter** | Aufgabe | macOS-Befehl | |---|---| | PF-Status anzeigen | `[RO][PRIV] sudo pfctl -s info` | | Geladene Regeln anzeigen | `[RO][PRIV][SENS] sudo pfctl -sr` | | NAT-Regeln anzeigen | `[RO][PRIV][SENS] sudo pfctl -sn` | | Status und Statistiken anzeigen | `[RO][PRIV] sudo pfctl -s all` | | PF-Tabellen anzeigen | `[RO][PRIV][SENS] sudo pfctl -s Tables` | **Prüfreihenfolge** 1. Prüfen, ob der Dienst lokal auf dem erwarteten Port lauscht. 2. Bind-Adresse des Dienstes prüfen. 3. Application-Firewallstatus prüfen. 4. PF-Status und Regeln prüfen. 5. Network Extensions und Sicherheitssoftware berücksichtigen. 6. Port von einem autorisierten zweiten System testen. > Die Firewall nicht pauschal deaktivieren. Dadurch wird die Sicherheitslage verändert und das ursprüngliche Fehlerbild verfälscht.
---
16. Netzwerkprotokolle mit log untersuchen macOS verwendet das Unified Logging System. | Aufgabe | macOS-Befehl | |---|---| | Meldungen der letzten 30 Minuten anzeigen | `[RO][PRIV][SENS] sudo log show --last 30m --style compact` | | Meldungen von mDNSResponder anzeigen | `[RO][PRIV][SENS] sudo log show --last 30m --predicate 'process == "mDNSResponder"' --style compact` | | Meldungen von configd anzeigen | `[RO][PRIV][SENS] sudo log show --last 30m --predicate 'process == "configd"' --style compact` | | WLAN-Prozesse suchen | `[RO][PRIV][SENS] sudo log show --last 30m --predicate 'process CONTAINS[c] "airport" OR process CONTAINS[c] "WiFi"' --style compact` | | DNS-Meldungen live verfolgen | `[RO][PRIV][SENS] sudo log stream --predicate 'process == "mDNSResponder"' --style compact` | | Allgemeine Netzwerkbegriffe suchen | `[RO][PRIV][SENS] sudo log show --last 30m --style compact \| grep -Ei 'network|wifi|ethernet|dhcp|dns|route|link'` | **Prüfpunkte** - Exakter Zeitstempel der Störung - Betroffene Schnittstelle - DHCP-Ereignisse - DNS-Fehler - Verbindungsabbrüche - WLAN-Roaming - Authentifizierungsfehler - VPN- oder Network-Extension-Ereignisse - Interface-Wechsel - Schlaf- und Aufwachereignisse > Das macOS-Protokoll kann private und sensible Inhalte maskieren. Mit Administratorrechten können dennoch schützenswerte System- und Netzwerkdaten sichtbar werden.
---
17. Diagnoseinformationen sichern und vergleichen | Aufgabe | macOS-Befehl | |---|---| | Schnittstellen sichern | `[RO][FILE][SENS] ifconfig -a > interfaces.txt` | | Routingtabelle sichern | `[RO][FILE][SENS] netstat -rn > routes.txt` | | Standardroute sichern | `[RO][FILE][SENS] route -n get default > default-route.txt` | | DNS-Konfiguration sichern | `[RO][FILE][SENS] scutil --dns > dns-status.txt` | | Proxykonfiguration sichern | `[RO][FILE][SENS] scutil --proxy > proxy-status.txt` | | Netzwerkdienste sichern | `[RO][FILE][SENS] networksetup -listnetworkserviceorder > network-services.txt` | | Netzwerkübersicht sichern | `[RO][FILE][SENS] system_profiler SPNetworkDataType > network-profiler.txt` | | Offene Ports sichern | `[RO][PRIV][FILE][SENS] sudo lsof -nP -i > network-connections.txt` | | WLAN-Diagnose sichern | `[RO][PRIV][FILE][SENS] sudo wdutil info > wifi-status.txt` | **Zwei Zustände vergleichen** ```bash ifconfig -a > interfaces-vorher.txt netstat -rn > routes-vorher.txt scutil --dns > dns-vorher.txt # Messung oder freigegebene Änderung durchführen ifconfig -a > interfaces-nachher.txt netstat -rn > routes-nachher.txt scutil --dns > dns-nachher.txt diff -u interfaces-vorher.txt interfaces-nachher.txt diff -u routes-vorher.txt routes-nachher.txt diff -u dns-vorher.txt dns-nachher.txt ``` **Datenschutz** Diagnoseausgaben können enthalten: - interne und externe IP-Adressen - MAC-Adressen - DNS-Suchdomänen - WLAN-Namen und BSSIDs - VPN- und Proxyinformationen - Prozessnamen - Benutzerinformationen - installierte Network Extensions - interne Netzwerkstrukturen Vor einer Weitergabe müssen sensible Angaben redigiert werden.
---
18. Eingreifende Befehle und Rückfallmöglichkeiten Die folgenden Befehle verändern einen Zustand und können eine Remoteverbindung sofort unterbrechen. | Maßnahme | macOS-Befehl | Auswirkung | |---|---|---| | DNS-Cache leeren | `[CHANGE][PRIV] sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder` | Lokale DNS-Cacheeinträge werden verworfen | | Wi-Fi ausschalten | `[CHANGE][PRIV][DISRUPT] sudo networksetup -setairportpower en0 off` | WLAN-Verbindung wird getrennt | | Wi-Fi einschalten | `[CHANGE][PRIV] sudo networksetup -setairportpower en0 on` | WLAN wird wieder aktiviert | | Schnittstelle deaktivieren | `[CHANGE][PRIV][DISRUPT] sudo ifconfig en0 down` | Alle Verbindungen über die Schnittstelle werden getrennt | | Schnittstelle aktivieren | `[CHANGE][PRIV] sudo ifconfig en0 up` | Schnittstelle wird wieder aktiviert | | Netzwerkdienst auf DHCP setzen | `[CHANGE][PRIV][DISRUPT] sudo networksetup -setdhcp "Wi-Fi"` | Vorhandene manuelle IPv4-Konfiguration wird ersetzt | > `en0` und `Wi-Fi` sind Beispiele. Vorher müssen die tatsächliche Schnittstelle und der tatsächliche Netzwerkdienst bestimmt werden. **Vor einem Eingriff prüfen** - Erfolgt der Zugriff lokal oder per Remotezugriff? - Wird die aktive Managementverbindung unterbrochen? - Ist die aktuelle manuelle IP-Konfiguration dokumentiert? - Sind DNS-, Proxy- und VPN-Einstellungen gesichert? - Ist ein lokaler Zugriff auf den Mac möglich? - Wird der Mac durch MDM oder ein Konfigurationsprofil verwaltet? - Existiert eine geeignete Rückfallmöglichkeit? **Rollback-Beispiele** | Änderung | Rückfall | |---|---| | Wi-Fi ausgeschaltet | Wi-Fi mit `networksetup -setairportpower ... on` wieder einschalten | | Schnittstelle deaktiviert | Schnittstelle mit `ifconfig ... up` wieder aktivieren | | DHCP statt statischer IP gesetzt | Dokumentierte IP-, Masken-, Router- und DNS-Werte wiederherstellen | | Netzwerkumgebung gewechselt | Vorherige Netzwerkumgebung wieder auswählen | | Proxy verändert | Dokumentierte Proxywerte wiederherstellen | **Verifikation nach einer Änderung** ```bash networksetup -getinfo "Wi-Fi" ifconfig en0 route -n get default scutil --dns ping -c 4 192.0.2.1 ping -c 4 1.1.1.1 dig example.com nc -vz -w 3 example.com 443 ```
---
19. Praktische macOS-Diagnosereihenfolge **Schritt 1 – macOS-Version erfassen** ```bash sw_vers ``` **Schritt 2 – Netzwerkdienst und Schnittstelle zuordnen** ```bash networksetup -listallhardwareports networksetup -listnetworkserviceorder ``` **Schritt 3 – Schnittstellenstatus prüfen** ```bash ifconfig -a netstat -ibn ``` **Schritt 4 – IP-Konfiguration prüfen** ```bash networksetup -getinfo "Wi-Fi" ipconfig getifaddr en0 ``` **Schritt 5 – Standardroute prüfen** ```bash route -n get default route -n get 1.1.1.1 ``` **Schritt 6 – Nachbartabelle prüfen** ```bash arp -an ndp -an ``` **Schritt 7 – Standardgateway testen** ```bash ping -c 4 192.0.2.1 ``` **Schritt 8 – Externe IP-Adresse testen** ```bash ping -c 4 1.1.1.1 ``` **Schritt 9 – DNS-Konfiguration prüfen** ```bash scutil --dns networksetup -getdnsservers "Wi-Fi" ``` **Schritt 10 – DNS-Auflösung testen** ```bash dscacheutil -q host -a name example.com dig example.com ``` **Schritt 11 – Proxy und VPN prüfen** ```bash scutil --proxy scutil --nwi ifconfig -l | tr ' ' '\n' | grep '^utun' ``` **Schritt 12 – Zielport testen** ```bash nc -vz -w 3 example.com 443 ``` **Schritt 13 – Lokale Ports prüfen** ```bash sudo lsof -nP -iTCP -sTCP:LISTEN ``` **Schritt 14 – Netzwerkpfad prüfen** ```bash traceroute -n example.com ``` **Schritt 15 – Netzwerkqualität messen** ```bash networkQuality -v ``` **Schritt 16 – Firewall und Protokolle prüfen** ```bash /usr/libexec/ApplicationFirewall/socketfilterfw --getglobalstate sudo pfctl -s info sudo log show --last 30m --style compact ``` **Diagnoselogik** | Ergebnis | Nächster Schwerpunkt | |---|---| | Schnittstelle fehlt | Adapter, USB-/Thunderbolt-Verbindung oder Hardware prüfen | | Schnittstelle inaktiv | WLAN, Kabel, Netzwerkdienst oder Port prüfen | | Keine passende IP-Adresse | DHCP oder manuelle Konfiguration prüfen | | Keine Standardroute | Router, Dienstreihenfolge, VPN oder Konfiguration prüfen | | Gateway nicht erreichbar | Lokales Netz, WLAN, VLAN, Switch oder Router prüfen | | Externe IP erreichbar, DNS-Name nicht | Resolver, DNS-Server und Split-DNS prüfen | | Ziel-IP erreichbar, Zielport nicht | Dienst, Bind-Adresse und Firewall prüfen | | Nur Anwendungen betroffen | Proxy, TLS, Private Relay oder Network Extension prüfen | | Falsche Route über `utun` | VPN- beziehungsweise Filtersoftware prüfen | | Schlechte WLAN-Werte | Signal, Kanal, Rauschen, Roaming und Access Point prüfen |
--- **Kurzreferenz** | Diagnoseziel | macOS-Befehl | |---|---| | macOS-Version | `[RO] sw_vers` | | Hardwareports | `[RO] networksetup -listallhardwareports` | | Netzwerkdienste | `[RO] networksetup -listallnetworkservices` | | Dienstreihenfolge | `[RO] networksetup -listnetworkserviceorder` | | Netzwerkschnittstellen | `[RO] ifconfig -a` | | Schnittstellenstatistik | `[RO] netstat -ibn` | | IPv4-Adresse | `[RO] ipconfig getifaddr en0` | | Dienstinformationen | `[RO] networksetup -getinfo "Wi-Fi"` | | Standardroute | `[RO] route -n get default` | | Route zu einem Ziel | `[RO] route -n get 1.1.1.1` | | IPv4-Routingtabelle | `[RO] netstat -rn -f inet` | | ARP-Tabelle | `[RO] arp -an` | | IPv6-Nachbarn | `[RO] ndp -an` | | Gateway testen | `[TEST] ping -c 4 192.0.2.1` | | Netzwerkpfad | `[TEST] traceroute -n example.com` | | DNS-Konfiguration | `[RO] scutil --dns` | | DNS-Abfrage | `[TEST] dig example.com` | | Systemresolver testen | `[TEST] dscacheutil -q host -a name example.com` | | Proxykonfiguration | `[RO] scutil --proxy` | | Netzwerkstatus | `[RO] scutil --nwi` | | WLAN-Informationen | `[RO][PRIV] sudo wdutil info` | | Netzwerkqualität | `[TEST] networkQuality -v` | | Lauschende Ports | `[RO][PRIV] sudo lsof -nP -iTCP -sTCP:LISTEN` | | TCP-Port testen | `[TEST] nc -vz -w 3 example.com 443` | | Application Firewall | `[RO] /usr/libexec/ApplicationFirewall/socketfilterfw --getglobalstate` | | Packet Filter | `[RO][PRIV] sudo pfctl -s info` | | Systemprotokoll | `[RO][PRIV] sudo log show --last 30m --style compact` | --- **Veraltete beziehungsweise nicht mehr zuverlässige Werkzeuge** | Werkzeug | Bewertung | |---|---| | Privates `airport`-Kommandozeilenwerkzeug | Auf aktuellen macOS-Versionen nicht als zuverlässiger Standard verwenden | | `ifconfig` | Unter macOS weiterhin Bestandteil des Systems und für Diagnose geeignet | | `netstat` | Unter macOS weiterhin für Routing-, Socket- und Schnittstellendiagnose verwendbar | | `wdutil` | Auf aktuellen macOS-Versionen für WLAN-Diagnose bevorzugen | | Wireless Diagnostics | Von Apple bereitgestelltes grafisches Diagnosewerkzeug | --- **Merksatz** > Die macOS-Netzwerkdiagnose folgt der Kette: Netzwerkdienst → Schnittstelle → Link → IP-Adresse → Nachbartabelle → Route → Gateway → DNS → Proxy/VPN → Zielport → lokaler Dienst → Firewall → Protokolle. --- **Quellen** - [Apple Support – Internetverbindungsprobleme auf dem Mac lösen](https://support.apple.com/guide/mac-help/mh11395/mac) - [Apple Support – Netzwerkstatus auf dem Mac prüfen](https://support.apple.com/guide/mac-help/check-the-status-of-your-network-on-mac-mchlp2291/mac) - [Apple Support – Wireless Diagnostics verwenden](https://support.apple.com/guide/mac-help/use-wireless-diagnostics-mchlf4de377f/mac) - [Apple Support – Wi-Fi-Statusmenü verwenden](https://support.apple.com/guide/mac-help/mchlfad426fa/mac) - [Apple Support – Wi-Fi-Einstellungen auf dem Mac](https://support.apple.com/guide/mac-help/mh11935/mac) - [Apple Support – Informationen zu networksetup](https://support.apple.com/guide/remote-desktop/about-networksetup-apdd0c5a2d5/mac) - [Apple Support – Terminal-Benutzerhandbuch](https://support.apple.com/guide/terminal/welcome/mac) - Lokale Apple-Manpages: `man networksetup`, `man scutil`, `man ifconfig`, `man route`, `man netstat`, `man arp`, `man ndp`, `man ping`, `man traceroute`, `man networkQuality`, `man pfctl` # 2.5 Wireshark und TShark – Netzwerkverkehr aufzeichnen und analysieren **Ziel dieser Seite** Wireshark und TShark ermöglichen die detaillierte Untersuchung des Netzwerkverkehrs. Sie helfen unter anderem bei der Analyse von: - Verbindungsabbrüchen; - langsamen Netzwerkverbindungen; - DNS-Problemen; - TCP-Verbindungsfehlern; - Paketverlusten und Übertragungswiederholungen; - DHCP-Problemen; - TLS-Verbindungsabbrüchen; - fehlerhaften Anwendungen und Protokollen; - Kommunikationsproblemen zwischen Clients und Servern. Ein Paketmitschnitt sollte erst dann begonnen werden, wenn die betroffenen Systeme, der ungefähre Fehlerzeitpunkt und der erwartete Kommunikationsweg bekannt sind. > **Wichtig:** Paketmitschnitte dürfen ausschließlich in Netzwerken und auf Systemen durchgeführt werden, für die eine entsprechende Berechtigung vorliegt. Aufzeichnungen können Benutzernamen, IP-Adressen, DNS-Anfragen, Sitzungsinformationen und unverschlüsselte Anwendungsdaten enthalten. --- **Kennzeichnungen** | Kennzeichnung | Bedeutung | |---|---| | `[RO]` | Nur lesender beziehungsweise auswertender Befehl | | `[TEST]` | Aktiver Diagnose- oder Aufzeichnungsvorgang | | `[PRIV]` | Erhöhte Berechtigungen können erforderlich sein | | `[FILE]` | Der Befehl erstellt oder verarbeitet eine Datei | | `[SENS]` | Die Ausgabe oder Datei kann sensible Informationen enthalten | | `[DISRUPT]` | Der Vorgang kann Systeme oder Netzwerkverbindungen beeinflussen | --- **1. Was ist der Unterschied zwischen Wireshark, TShark und Dumpcap?**
Werkzeuge und Aufgaben anzeigen | Werkzeug | Aufgabe | Typischer Einsatz | |---|---|---| | Wireshark | Grafische Paketaufzeichnung und Analyse | Interaktive Fehlersuche am Arbeitsplatz | | TShark | Kommandozeilenversion der Wireshark-Analyse | Server, Skripte und automatisierte Auswertungen | | Dumpcap | Spezialisierte Paketaufzeichnung | Ressourcenarme oder länger laufende Mitschnitte | | Capinfos | Zeigt Eigenschaften einer Mitschnittdatei | Kontrolle von Dateiformat, Zeitraum und Paketanzahl | | Mergecap | Führt mehrere Mitschnittdateien zusammen | Gemeinsame Analyse mehrerer Aufzeichnungen | | Editcap | Bearbeitet oder verkleinert Mitschnittdateien | Zeitbereiche oder einzelne Pakete extrahieren | Wireshark und TShark verwenden dieselben Protokoll-Dissektoren und dieselbe Display-Filter-Sprache. Die eigentliche Paketaufzeichnung wird üblicherweise von Dumpcap durchgeführt. **Grundlegende Versionsprüfung** | Aufgabe | Befehl | |---|---| | Wireshark-Version anzeigen | `[RO] wireshark --version` | | TShark-Version anzeigen | `[RO] tshark --version` | | Dumpcap-Version anzeigen | `[RO] dumpcap --version` | | Capinfos-Version anzeigen | `[RO] capinfos --version` |
--- **2. Welche Voraussetzungen müssen vor einem Paketmitschnitt geprüft werden?**
Vorbedingungen und Berechtigungen anzeigen Vor dem Mitschnitt müssen mindestens folgende Punkte geklärt werden: | Prüffrage | Bedeutung | |---|---| | Welches System ist betroffen? | Bestimmt den geeigneten Aufzeichnungspunkt | | Welche Gegenstelle wird angesprochen? | Ermöglicht einen gezielten Host- oder Portfilter | | Wann tritt der Fehler auf? | Verhindert unnötig lange Aufzeichnungen | | Welches Protokoll wird erwartet? | Erleichtert die spätere Analyse | | Welche Schnittstelle transportiert den Verkehr? | Verhindert einen Mitschnitt auf dem falschen Adapter | | Ist der Mitschnitt autorisiert? | Schützt personenbezogene und betriebliche Daten | | Gibt es ausreichend Speicherplatz? | Verhindert eine volle Festplatte | | Sind die Systemuhren synchronisiert? | Ermöglicht den Vergleich mit Server- und Anwendungslogs | **Betriebssystemspezifische Hinweise** | Betriebssystem | Typische Voraussetzung | |---|---| | Windows | Für Live-Mitschnitte wird normalerweise Npcap benötigt | | Linux | Der Benutzer benötigt Zugriff auf Dumpcap beziehungsweise die Capture-Gruppe; alternativ sind erhöhte Rechte erforderlich | | macOS | Die Wireshark-Installation richtet üblicherweise die notwendigen BPF-Berechtigungen ein | | Remote-Server | Häufig wird TShark oder Dumpcap ohne grafische Oberfläche verwendet | Wireshark oder TShark sollten nicht dauerhaft als Administrator beziehungsweise `root` ausgeführt werden. Besser ist eine gezielte Berechtigung ausschließlich für die Paketaufzeichnung.
--- **3. Wie wird die richtige Netzwerkschnittstelle ausgewählt?**
Schnittstellen ermitteln und überprüfen **Verfügbare Capture-Schnittstellen anzeigen** ```text [RO] tshark -D ``` Alternativ: ```text [RO] dumpcap -D ``` Beispielhafte Ausgabe: ```text 1. \Device\NPF_{...} (Ethernet) 2. \Device\NPF_{...} (WLAN) 3. \Device\NPF_Loopback (Adapter for loopback traffic capture) ``` Unter Linux oder macOS können Namen wie diese erscheinen: ```text 1. enp0s31f6 2. wlan0 3. lo ``` oder: ```text 1. en0 2. en1 3. lo0 ``` Die Schnittstelle kann über ihre Nummer oder ihren Namen ausgewählt werden: ```text [TEST][PRIV] tshark -i 1 ``` ```text [TEST][PRIV] tshark -i en0 ``` **Prüfmethode** 1. Die vermutete Schnittstelle auswählen. 2. Einen kurzen Mitschnitt starten. 3. Einen bekannten und autorisierten Test erzeugen, beispielsweise eine DNS-Abfrage oder einen Ping. 4. Prüfen, ob die erwarteten Pakete erscheinen. 5. Erst danach den eigentlichen Fehler reproduzieren. **Typische Fehler bei der Schnittstellenauswahl** - WLAN statt Ethernet ausgewählt; - VPN-Schnittstelle übersehen; - Loopback-Verkehr auf einer physischen Schnittstelle gesucht; - virtuelle Schnittstelle einer VM oder eines Containers übersehen; - nur den Client untersucht, obwohl der Fehler am Server oder Gateway sichtbar wird; - auf einem Switch-Port mitgeschnitten, an dem der betreffende Verkehr nicht vorbeikommt. > Ein leerer Mitschnitt beweist nicht, dass kein Netzwerkverkehr vorhanden war. Zuerst müssen Schnittstelle, Aufzeichnungspunkt, Berechtigung und Capture-Filter geprüft werden.
--- **4. Wie wird mit Wireshark ein kontrollierter Mitschnitt erstellt?**
Vorgehensweise in der grafischen Oberfläche anzeigen **Empfohlener Ablauf** 1. Wireshark starten. 2. Die Schnittstelle anhand der Paketaktivität und der Systemkonfiguration auswählen. 3. Unter **Capture → Options** die Schnittstelle kontrollieren. 4. Falls erforderlich einen Capture-Filter eintragen. 5. Die Aufzeichnung starten. 6. Den Fehler möglichst einmal gezielt reproduzieren. 7. Die Aufzeichnung sofort danach beenden. 8. Die Datei im Format `pcapng` speichern. 9. Zeitpunkt, Client, Server, Testschritt und beobachtetes Verhalten dokumentieren. 10. Für die Analyse Display-Filter verwenden. **Empfohlene Dokumentation** | Feld | Beispiel | |---|---| | Startzeit | `2026-07-31 14:02:10 CEST` | | Endzeit | `2026-07-31 14:03:05 CEST` | | Client | `192.0.2.10` | | Server | `198.51.100.20` | | Benutzer | `Max Mustermann` | | Test | Anmeldung an der Beispielanwendung | | Erwartung | Anmeldeseite wird geladen | | Beobachtung | Verbindungsabbruch nach etwa fünf Sekunden | | Capture-Schnittstelle | Ethernet 1 | | Capture-Filter | `host 198.51.100.20` | Die Aufzeichnung sollte so kurz und zielgerichtet wie möglich sein. Dadurch sinken Speicherbedarf, Analyseaufwand und Datenschutzrisiko.
--- **5. Was ist der Unterschied zwischen Capture-Filter und Display-Filter?**
Filterarten und wichtige Unterschiede anzeigen | Eigenschaft | Capture-Filter | Display-Filter | |---|---|---| | Zeitpunkt | Während der Aufzeichnung | Während oder nach der Analyse | | Wirkung | Nicht passende Pakete werden nicht aufgezeichnet | Pakete bleiben in der Datei, werden aber ausgeblendet | | Sprache | libpcap-/BPF-Syntax | Wireshark-Display-Filter-Syntax | | TShark-Option | `-f` | `-Y` | | Nachträglich änderbar | Nein | Ja | | Leistungsbedarf | Vergleichsweise gering | Bei Live-Analyse möglicherweise höher | | Beispiel | `tcp port 443` | `tcp.port == 443` | **Capture-Filter** ```text tcp port 443 ``` **Display-Filter** ```text tcp.port == 443 ``` Diese beiden Filter dürfen nicht verwechselt werden. Ein Capture-Filter verwirft alle nicht passenden Pakete bereits bei der Aufzeichnung. Fehlende Pakete können später nicht wiederhergestellt werden. Ein Display-Filter verändert die gespeicherte Aufzeichnung nicht. Er kann jederzeit geändert oder entfernt werden. > Für eine Live-Aufzeichnung, die gleichzeitig mit `-w` gespeichert wird, sollte die Eingrenzung mit `-f` erfolgen. Ein mit `-Y` angegebener Display-Filter ist dafür kein Ersatz.
--- **6. Welche Capture-Filter werden häufig verwendet?**
Capture-Filter-Tabelle anzeigen | Aufgabe | Capture-Filter | |---|---| | Verkehr eines IPv4-Hosts | `host 192.0.2.10` | | Nur Verkehr von einem Host | `src host 192.0.2.10` | | Nur Verkehr zu einem Host | `dst host 192.0.2.10` | | Verkehr eines IPv4-Netzes | `net 192.0.2.0/24` | | TCP-Port 443 | `tcp port 443` | | UDP-Port 53 | `udp port 53` | | Zielport 443 | `tcp dst port 443` | | Quellport 443 | `tcp src port 443` | | DNS über TCP oder UDP | `port 53` | | DHCPv4 | `udp port 67 or udp port 68` | | HTTP oder HTTPS | `tcp port 80 or tcp port 443` | | ICMPv4 | `icmp` | | ICMPv6 | `icmp6` | | ARP | `arp` | | Host und Port kombinieren | `host 192.0.2.10 and tcp port 443` | | Zwei Hosts | `host 192.0.2.10 or host 198.51.100.20` | | Host ausschließen | `not host 192.0.2.10` | | SSH-Verkehr ausschließen | `not tcp port 22` | | Broadcast- oder Multicastverkehr | `ether broadcast or ether multicast` | **Beispiel: nur HTTPS-Verkehr zu einem Testserver aufzeichnen** ```text [TEST][PRIV][FILE][SENS] tshark -i 1 -f "host 198.51.100.20 and tcp port 443" -a duration:60 -w https-test.pcapng ``` **Wichtige Filterregeln** - Zusammengesetzte Filter in der Shell in Anführungszeichen setzen. - Bei `and` müssen beide Bedingungen zutreffen. - Bei `or` genügt eine der Bedingungen. - Mit `not` wird eine Bedingung ausgeschlossen. - Klammern verwenden, wenn die logische Reihenfolge sonst unklar ist. - Einen engen Filter erst nach einem kurzen Kontrollmitschnitt einsetzen.
--- **7. Welche Display-Filter werden häufig verwendet?**
Display-Filter-Tabelle anzeigen | Aufgabe | Display-Filter | |---|---| | IPv4-Adresse als Quelle oder Ziel | `ip.addr == 192.0.2.10` | | Nur IPv4-Quelle | `ip.src == 192.0.2.10` | | Nur IPv4-Ziel | `ip.dst == 192.0.2.10` | | IPv4-Netz | `ip.addr == 192.0.2.0/24` | | IPv6-Adresse | `ipv6.addr == 2001:db8::10` | | TCP-Port | `tcp.port == 443` | | UDP-Port | `udp.port == 53` | | Mehrere TCP-Ports | `tcp.port in {80, 443, 8080}` | | ARP | `arp` | | ICMPv4 | `icmp` | | ICMPv6 | `icmpv6` | | DNS | `dns` | | Bestimmter DNS-Name | `dns.qry.name == "example.com"` | | DNS-Fehlerantworten | `dns.flags.response == 1 && dns.flags.rcode != 0` | | DHCPv4 | `dhcp` | | HTTP-Anfragen | `http.request` | | TLS-Handshake | `tls.handshake` | | TCP-SYN ohne ACK | `tcp.flags.syn == 1 && tcp.flags.ack == 0` | | TCP-RST | `tcp.flags.reset == 1` | | TCP-FIN | `tcp.flags.fin == 1` | | TCP-Wiederholungsübertragung | `tcp.analysis.retransmission` | | TCP-Fast-Retransmission | `tcp.analysis.fast_retransmission` | | Duplicate ACK | `tcp.analysis.duplicate_ack` | | Vermutetes verlorenes Segment | `tcp.analysis.lost_segment` | | TCP-Zero-Window | `tcp.analysis.zero_window` | | Bestimmte Paketnummer | `frame.number == 100` | | Pakete ab Sekunde 10 | `frame.time_relative >= 10` | | Zeitbereich von Sekunde 10 bis 20 | `frame.time_relative >= 10 && frame.time_relative <= 20` | | Große Frames | `frame.len > 1500` | | Expert-Information mit Fehlerstufe | `_ws.expert.severity == error` | **Filter kombinieren** ```text ip.addr == 192.0.2.10 && tcp.port == 443 ``` ```text dns || dhcp ``` ```text ip.addr == 192.0.2.10 && (tcp.analysis.retransmission || tcp.analysis.duplicate_ack) ``` **Wichtiger Hinweis zu booleschen Feldern** Dieser Filter prüft nur, ob das Feld vorhanden ist: ```text tcp.flags.syn ``` Um ausschließlich gesetzte SYN-Flags zu finden, muss der Wert geprüft werden: ```text tcp.flags.syn == 1 ```
--- **8. Wie werden mit TShark kurze und kontrollierte Mitschnitte erstellt?**
TShark-Aufzeichnungsbefehle anzeigen | Aufgabe | Befehl | |---|---| | Schnittstellen anzeigen | `[RO] tshark -D` | | Live-Verkehr auf Schnittstelle 1 anzeigen | `[TEST][PRIV][SENS] tshark -i 1` | | Genau 100 Pakete erfassen | `[TEST][PRIV][FILE][SENS] tshark -i 1 -c 100 -w capture.pcapng` | | 60 Sekunden aufzeichnen | `[TEST][PRIV][FILE][SENS] tshark -i 1 -a duration:60 -w capture.pcapng` | | Auf 100.000 KiB Dateigröße begrenzen | `[TEST][PRIV][FILE][SENS] tshark -i 1 -a filesize:100000 -w capture.pcapng` | | HTTPS-Verkehr aufzeichnen | `[TEST][PRIV][FILE][SENS] tshark -i 1 -f "tcp port 443" -a duration:60 -w https.pcapng` | | Verkehr eines Hosts aufzeichnen | `[TEST][PRIV][FILE][SENS] tshark -i 1 -f "host 192.0.2.10" -a duration:60 -w host-test.pcapng` | | DNS-Verkehr aufzeichnen | `[TEST][PRIV][FILE][SENS] tshark -i 1 -f "port 53" -a duration:60 -w dns-test.pcapng` | `-c 100` beendet die Aufzeichnung nach 100 erfassten Paketen. `-a duration:60` beendet die Aufzeichnung nach 60 Sekunden. `-a filesize:100000` beendet sie nach ungefähr 100.000 KiB. `-w capture.pcapng` schreibt die Rohpakete in eine Mitschnittdatei. Es handelt sich nicht um eine normale Textdatei. **Kontrollierter Beispielablauf** ```text [RO] tshark -D ``` ```text [TEST][PRIV][FILE][SENS] tshark -i 1 -f "host 198.51.100.20 and tcp port 443" -a duration:60 -w https-test.pcapng ``` Während der 60 Sekunden wird der Fehler genau einmal reproduziert. Anschließend wird die Datei offline ausgewertet.
--- **9. Wie werden vorhandene Mitschnittdateien mit TShark ausgewertet?**
Offline-Analyse anzeigen | Aufgabe | Befehl | |---|---| | Datei einlesen | `[RO][FILE][SENS] tshark -r capture.pcapng` | | Namensauflösung deaktivieren | `[RO][FILE][SENS] tshark -n -r capture.pcapng` | | Nur DNS anzeigen | `[RO][FILE][SENS] tshark -n -r capture.pcapng -Y "dns"` | | Nur TCP-Port 443 anzeigen | `[RO][FILE][SENS] tshark -n -r capture.pcapng -Y "tcp.port == 443"` | | Paketdetails anzeigen | `[RO][FILE][SENS] tshark -n -r capture.pcapng -Y "frame.number == 100" -V` | | Hexadezimaldaten anzeigen | `[RO][FILE][SENS] tshark -n -r capture.pcapng -Y "frame.number == 100" -x` | | Nur bestimmte Protokolldetails | `[RO][FILE][SENS] tshark -n -r capture.pcapng -Y "dns" -O dns` | Die Option `-n` deaktiviert die Namensauflösung. Dadurch werden: - zusätzliche DNS-Anfragen während der Analyse vermieden; - ursprüngliche IP-Adressen unverändert angezeigt; - Verzögerungen durch Namensauflösung reduziert; - Verwechslungen zwischen aufgezeichneten und nachträglich aufgelösten Namen vermieden. **Pakete aus einer Datei filtern und in eine neue Datei schreiben** ```text [RO][FILE][SENS] tshark -r capture.pcapng -Y "ip.addr == 192.0.2.10" -w host-only.pcapng ``` Dieser Befehl liest eine vorhandene Datei, wendet einen Display-Filter an und schreibt die passenden Pakete in eine neue Mitschnittdatei.
--- **10. Wie werden gezielt Felder oder CSV-Daten ausgegeben?**
Feldextraktion und CSV-Ausgabe anzeigen Mit `-T fields` wird eine tabellarische Feldausgabe erzeugt. Die gewünschten Felder werden mit `-e` angegeben. **DNS-Abfragen extrahieren** ```text [RO][FILE][SENS] tshark -n -r capture.pcapng -Y "dns.qry.name" -T fields -e frame.time -e ip.src -e ip.dst -e dns.qry.name ``` **TCP-Verbindungen untersuchen** ```text [RO][FILE][SENS] tshark -n -r capture.pcapng -Y "tcp" -T fields -e frame.number -e frame.time_relative -e ip.src -e tcp.srcport -e ip.dst -e tcp.dstport -e tcp.flags ``` **CSV-Ausgabe mit Kopfzeile** ```text [RO][FILE][SENS] tshark -n -r capture.pcapng -Y "dns" -T fields -E header=y -E separator=, -E quote=d -e frame.time -e ip.src -e ip.dst -e dns.qry.name ``` **Bedeutung der Optionen** | Option | Bedeutung | |---|---| | `-T fields` | Gibt ausschließlich ausgewählte Felder aus | | `-e Feldname` | Fügt ein Feld zur Ausgabe hinzu | | `-E header=y` | Schreibt die Feldnamen als Kopfzeile | | `-E separator=,` | Verwendet ein Komma als Trennzeichen | | `-E quote=d` | Setzt Feldwerte in doppelte Anführungszeichen | > Bei einem deutschen Tabellenkalkulationsprogramm kann das Komma als Dezimal- oder Listentrennzeichen interpretiert werden. Die Importoptionen müssen deshalb bewusst kontrolliert werden.
--- **11. Welche TShark-Statistiken helfen bei der schnellen Übersicht?**
Statistikbefehle anzeigen | Aufgabe | Befehl | |---|---| | Protokollhierarchie | `[RO][FILE][SENS] tshark -n -r capture.pcapng -q -z io,phs` | | TCP-Konversationen | `[RO][FILE][SENS] tshark -n -r capture.pcapng -q -z conv,tcp` | | UDP-Konversationen | `[RO][FILE][SENS] tshark -n -r capture.pcapng -q -z conv,udp` | | IPv4-Endpunkte | `[RO][FILE][SENS] tshark -n -r capture.pcapng -q -z endpoints,ip` | | IPv6-Endpunkte | `[RO][FILE][SENS] tshark -n -r capture.pcapng -q -z endpoints,ipv6` | | Ethernet-Endpunkte | `[RO][FILE][SENS] tshark -n -r capture.pcapng -q -z endpoints,eth` | | Statistik pro Sekunde | `[RO][FILE][SENS] tshark -n -r capture.pcapng -q -z io,stat,1` | | DNS-Statistik | `[RO][FILE][SENS] tshark -n -r capture.pcapng -q -z dns,tree` | **Bedeutung** - **Protocol Hierarchy** zeigt die Verteilung der enthaltenen Protokolle. - **Conversations** zeigt Kommunikationsbeziehungen zwischen zwei Endpunkten. - **Endpoints** zeigt einzelne IP- oder MAC-Adressen und deren Datenmengen. - **I/O Statistics** zeigt Paket- und Datenmengen über die Zeit. - **DNS Statistics** zeigt unter anderem DNS-Typen und Antwortcodes. In Wireshark befinden sich entsprechende Ansichten überwiegend im Menü **Statistics**.
--- **12. Wie werden große oder länger laufende Mitschnitte begrenzt?**
Ringpuffer und Dateibegrenzung anzeigen Ein unbegrenzter Mitschnitt kann eine Festplatte vollständig füllen. Für längere Aufzeichnungen sollte deshalb ein Ringpuffer verwendet werden. **Zwölf Dateien mit jeweils fünf Minuten Aufzeichnungsdauer** ```text [TEST][PRIV][FILE][SENS] tshark -i 1 -b duration:300 -b files:12 -w capture.pcapng ``` Damit entsteht ein Ringpuffer für ungefähr eine Stunde: ```text 12 Dateien × 5 Minuten = 60 Minuten ``` Wenn die zwölfte Datei vollständig ist, wird die älteste Datei überschrieben. **Fünf Dateien mit jeweils ungefähr 100.000 KiB** ```text [TEST][PRIV][FILE][SENS] tshark -i 1 -b filesize:100000 -b files:5 -w capture.pcapng ``` **Wichtige Regeln** - `-b files:N` benötigt zusätzlich `duration`, `interval` oder `filesize`. - Der Zielordner muss ausreichend Speicherplatz besitzen. - Der Ringpuffer schützt nicht vor einer zu groß gewählten Gesamtgröße. - Nach Auftreten des Fehlers muss die Aufzeichnung rechtzeitig beendet werden, bevor relevante Dateien überschrieben werden. - Die erzeugten Dateien können sensible Inhalte enthalten.
--- **13. Wie werden Mitschnittdateien geprüft und zusammengeführt?**
Capinfos und Mergecap anzeigen **Dateieigenschaften anzeigen** ```text [RO][FILE][SENS] capinfos capture.pcapng ``` Capinfos zeigt unter anderem: - Dateityp; - Kapselungstyp; - Paketanzahl; - Dateigröße; - Aufzeichnungsdauer; - Zeitpunkt des ersten Pakets; - Zeitpunkt des letzten Pakets; - durchschnittliche Paket- und Datenrate; - vorhandene Schnittstelleninformationen. **Kompakte tabellarische Ausgabe** ```text [RO][FILE][SENS] capinfos -T capture.pcapng ``` **Mehrere Dateien zusammenführen** ```text [RO][FILE][SENS] mergecap -w merged.pcapng part1.pcapng part2.pcapng ``` Mergecap ordnet Pakete standardmäßig anhand ihrer Zeitstempel ein. Deshalb müssen die Systemuhren der beteiligten Aufzeichnungssysteme möglichst genau synchronisiert sein. Vor dem Zusammenführen sollten die Zeiträume geprüft werden: ```text [RO][FILE][SENS] capinfos part1.pcapng part2.pcapng ```
--- **14. Wie wird eine TCP-Verbindung systematisch analysiert?**
TCP-Diagnose anzeigen **Schritt 1: Verbindungsaufbau suchen** ```text tcp.flags.syn == 1 && tcp.flags.ack == 0 ``` Ein regulärer TCP-Verbindungsaufbau besteht vereinfacht aus: | Schritt | Richtung | Flags | |---|---|---| | 1 | Client → Server | SYN | | 2 | Server → Client | SYN, ACK | | 3 | Client → Server | ACK | **Interpretation** | Beobachtung | Mögliche Ursache | |---|---| | SYN wird wiederholt, aber kein SYN/ACK sichtbar | Server nicht erreichbar, Firewall verwirft Pakete, Routingproblem oder falscher Aufzeichnungspunkt | | SYN wird mit RST beantwortet | Zielsystem erreichbar, aber Port geschlossen oder Dienst lehnt Verbindung ab | | SYN/ACK sichtbar, abschließendes ACK fehlt | Rückwegproblem, Clientproblem oder Filter-/Aufzeichnungslücke | | Drei-Wege-Handshake vollständig | Grundlegender TCP-Verbindungsaufbau war erfolgreich | | RST während der Sitzung | Verbindung wurde von einem Endpunkt oder einem Zwischensystem abgebrochen | | FIN/ACK-Sequenz | Geordneter Verbindungsabbau | **Hilfreiche Filter** ```text tcp.flags.reset == 1 ``` ```text tcp.analysis.retransmission ``` ```text tcp.analysis.duplicate_ack ``` ```text tcp.analysis.zero_window ``` ```text tcp.analysis.window_full ``` **TCP-Stream isolieren** Nach Auswahl eines TCP-Pakets kann in Wireshark verwendet werden: ```text Analyze → Follow → TCP Stream ``` Alternativ lässt sich nach einer Streamnummer filtern: ```text tcp.stream == 0 ``` > Eine TCP-Wiederholungsübertragung ist zunächst eine Beobachtung und noch keine eindeutige Ursache. Sie kann durch echten Paketverlust, verspätete Pakete, einen unvollständigen Mitschnitt, asymmetrisches Routing oder den Aufzeichnungspunkt entstehen.
--- **15. Wie werden DNS-Probleme untersucht?**
DNS-Diagnose anzeigen **Grundfilter** ```text dns ``` **Nur DNS-Anfragen** ```text dns.flags.response == 0 ``` **Nur DNS-Antworten** ```text dns.flags.response == 1 ``` **Bestimmten Namen untersuchen** ```text dns.qry.name == "example.com" ``` **Fehlerantworten anzeigen** ```text dns.flags.response == 1 && dns.flags.rcode != 0 ``` **Typische Beobachtungen** | Beobachtung | Mögliche Bedeutung | |---|---| | Anfrage sichtbar, aber keine Antwort | DNS-Server nicht erreichbar, Paketverlust, Firewall oder falscher Rückweg | | Antwort `NXDOMAIN` | Der angefragte Name existiert aus Sicht des antwortenden DNS-Servers nicht | | Antwort `SERVFAIL` | DNS-Server konnte die Anfrage nicht erfolgreich verarbeiten | | Mehrere identische Anfragen | Antwort fehlt, kommt verspätet oder wird vom Client nicht akzeptiert | | Antwort enthält unerwartete Adresse | Falscher DNS-Eintrag, falscher DNS-Server, Split-DNS oder Cacheproblem | | Lange Zeit zwischen Anfrage und Antwort | Verzögerter DNS-Server, Weiterleitungs- oder Netzwerkproblem | **TShark-Auswertung** ```text [RO][FILE][SENS] tshark -n -r capture.pcapng -Y "dns" -T fields -e frame.time_relative -e ip.src -e ip.dst -e dns.id -e dns.qry.name -e dns.flags.response -e dns.flags.rcode ``` Bei DNS-Problemen müssen Paketmitschnitt und lokale Resolver-Konfiguration gemeinsam betrachtet werden. Ein korrekter DNS-Austausch beweist noch nicht, dass die Anwendung das Ergebnis richtig verarbeitet hat.
--- **16. Wie werden DHCP-Probleme untersucht?**
DHCP-Diagnose anzeigen **Display-Filter** ```text dhcp ``` **Capture-Filter** ```text udp port 67 or udp port 68 ``` Der reguläre DHCPv4-Ablauf wird häufig als DORA bezeichnet: | Reihenfolge | Nachricht | Richtung | |---|---|---| | 1 | Discover | Client sucht DHCP-Server | | 2 | Offer | DHCP-Server bietet eine Konfiguration an | | 3 | Request | Client fordert das Angebot an | | 4 | ACK | Server bestätigt die Zuweisung | **Interpretation** | Beobachtung | Mögliche Ursache | |---|---| | Discover, aber kein Offer | DHCP-Server nicht erreichbar, Relay fehlt, VLAN falsch oder Adresspool erschöpft | | Offer sichtbar, aber kein Request | Client akzeptiert das Angebot nicht oder Mitschnitt ist unvollständig | | Request, aber kein ACK | Serverproblem, Relayproblem oder Paketverlust | | DHCP NAK | Angeforderte Adresse oder Konfiguration wurde abgelehnt | | Mehrere unterschiedliche Offers | Mehrere DHCP-Server antworten; möglicherweise unerwünschter DHCP-Server | | DORA vollständig | DHCP-Kommunikation war grundsätzlich erfolgreich | Bei VLAN-übergreifendem DHCP muss zusätzlich der DHCP-Relay beziehungsweise IP-Helper untersucht werden.
--- **17. Wie werden TLS- und HTTPS-Probleme untersucht?**
TLS-Diagnose anzeigen **TLS-Verkehr** ```text tls ``` **TLS-Handshake** ```text tls.handshake ``` **TLS-Warnungen und Fehler** ```text tls.alert_message ``` **TCP-Port 443 zusammen mit TLS** ```text tcp.port == 443 && tls ``` **Typischer vereinfachter Ablauf** 1. TCP-Verbindung wird aufgebaut. 2. Client sendet einen TLS-ClientHello. 3. Server sendet einen TLS-ServerHello. 4. Zertifikats- und Schlüsselparameter werden ausgetauscht. 5. Die verschlüsselte Anwendungskommunikation beginnt. **Beobachtungen** | Beobachtung | Mögliche Bedeutung | |---|---| | TCP-Handshake fehlt | Noch kein TLS-Problem; zuerst Netzwerk und TCP untersuchen | | ClientHello ohne ServerHello | Server, Firewall, TLS-Proxy oder Rückweg prüfen | | TLS Alert | TLS-Seite meldet einen Protokoll- oder Zertifikatsfehler | | ServerHello vorhanden, späterer Abbruch | Zertifikat, Cipher Suites, TLS-Version oder Anwendung prüfen | | Verschlüsselte Application Data | TLS-Verbindung wurde mindestens bis zur verschlüsselten Datenübertragung aufgebaut | Der Inhalt moderner HTTPS-Verbindungen ist verschlüsselt. Ohne ausdrücklich autorisierte Schlüssel- oder Debug-Daten sind hauptsächlich Metadaten, TCP-Verhalten und Teile des TLS-Handshakes sichtbar.
--- **18. Welche Analysefehler treten bei Wireshark besonders häufig auf?**
Fehlinterpretationen und Gegenmaßnahmen anzeigen | Fehler | Warum problematisch? | Richtige Reaktion | |---|---|---| | Capture- und Display-Filter verwechselt | Erwartete Pakete werden nicht gespeichert oder Filter funktioniert nicht | Syntax und Einsatzzeitpunkt prüfen | | Falsche Schnittstelle gewählt | Relevanter Verkehr fehlt | Kurzen Kontrollmitschnitt durchführen | | Zu enger Capture-Filter | Entscheidende Begleitpakete fehlen | Zunächst breiter und zeitlich begrenzt aufzeichnen | | Zu langer Mitschnitt | Große Dateien und hoher Analyseaufwand | Fehler gezielt reproduzieren und sofort stoppen | | Namensauflösung aktiviert | Adressen erscheinen verändert oder Analyse erzeugt zusätzliche Anfragen | Für reproduzierbare CLI-Ausgaben `-n` verwenden | | Jedes TCP-Retransmission-Ereignis als Paketverlust bewertet | Analyseindikatoren können durch unvollständige Mitschnitte entstehen | Sequenznummern, Aufzeichnungspunkt und Gegenmitschnitt prüfen | | Rote oder schwarze Markierung als Beweis betrachtet | Farben beruhen auf konfigurierten Regeln | Paketdetails und tatsächliche Felder untersuchen | | Checksum-Fehler sofort als Netzfehler bewertet | Checksum Offloading kann auf dem sendenden Host scheinbar fehlerhafte Prüfsummen erzeugen | Gegenstelle oder Netzwerkpfad vergleichen | | Fehlende Pakete als Beweis für eine Firewall gewertet | Falscher Aufzeichnungspunkt oder asymmetrischer Weg möglich | Auf beiden Seiten oder an einem geeigneten Übergabepunkt mitschneiden | | Promiscuous Mode überschätzt | Ein Switch sendet fremden Unicast-Verkehr nicht automatisch an jeden Port | Autorisierten Mirror-/SPAN-Port oder TAP verwenden | | Zeitstempel verschiedener Systeme ungeprüft verglichen | Abweichende Systemuhren verfälschen die Reihenfolge | NTP-Status und Zeitzonen prüfen | | Verschlüsselten Inhalt erwartet | TLS schützt die Nutzdaten | Handshake, Metadaten und autorisierte Logs auswerten | **Checksum Offloading** Bei ausgehenden Paketen kann das Betriebssystem die endgültige Prüfsumme erst durch die Netzwerkkarte berechnen lassen. Ein Mitschnitt auf dem sendenden System kann das Paket vor dieser Berechnung erfassen. Wireshark kennzeichnet die Prüfsumme dann möglicherweise als fehlerhaft, obwohl sie auf dem Übertragungsmedium korrekt war. **TCP-Analysekennzeichnungen** Filter wie `tcp.analysis.retransmission` sind Ergebnisse der Wireshark-Analyse. Sie sind wertvolle Hinweise, aber keine automatische Ursachenfeststellung.
--- **19. Wo muss der Paketmitschnitt durchgeführt werden?**
Geeigneten Aufzeichnungspunkt bestimmen Der geeignete Mitschnittpunkt hängt vom vermuteten Fehlerbereich ab. | Vermuteter Fehler | Geeigneter Mitschnittpunkt | |---|---| | Anwendung auf dem Client | Direkt auf dem Client | | Server antwortet nicht | Client und möglichst Server | | Firewall oder Routing | Vor und hinter dem betroffenen Übergang | | DHCP über mehrere VLANs | Client-VLAN, Relay und Servernetz | | DNS-Auflösung | Client und gegebenenfalls DNS-Server | | VPN-Verbindung | Physische und virtuelle VPN-Schnittstelle | | Containerkommunikation | Host-, Bridge- und gegebenenfalls Containerschnittstelle | | Virtuelle Maschine | Gastbetriebssystem und gegebenenfalls virtueller Switch | | Sporadischer Paketverlust | Beide Endpunkte oder geeigneter Netzwerk-TAP | In einem geswitchten Ethernet-Netz sieht ein Endgerät normalerweise: - eigene ein- und ausgehende Pakete; - Broadcastverkehr; - bestimmten Multicastverkehr; - nicht automatisch den gesamten Unicastverkehr anderer Systeme. Für fremden Unicastverkehr ist ein autorisierter Mirror-/SPAN-Port, Netzwerk-TAP oder ein Mitschnitt direkt auf einem Endpunkt erforderlich. **Vergleichsmethode** ```text Client-Mitschnitt → Netzwerkübergang → Server-Mitschnitt ``` Wenn ein Paket im Client-Mitschnitt vorhanden ist, aber im Server-Mitschnitt fehlt, liegt die Unterbrechung wahrscheinlich zwischen diesen Punkten. Für eine belastbare Aussage müssen Filter, Zeitstempel und Aufzeichnungsvollständigkeit geprüft werden.
--- **20. Wie sieht ein sicherer Diagnoseablauf mit Wireshark oder TShark aus?**
Empfohlene Schrittfolge anzeigen **Vorbereitung** 1. Störung und erwartetes Verhalten dokumentieren. 2. Client, Server, IP-Adressen, Ports und Protokolle bestimmen. 3. Fehlerzeitpunkt und reproduzierbaren Test festlegen. 4. Berechtigung für den Mitschnitt prüfen. 5. Zeitsynchronisation der beteiligten Systeme prüfen. 6. Speicherort und Speicherplatz kontrollieren. **Aufzeichnung** 7. Richtige Schnittstelle mit `tshark -D` oder Wireshark bestimmen. 8. Einen kurzen Kontrollmitschnitt durchführen. 9. Einen angemessenen Capture-Filter setzen. 10. Zeit-, Paket- oder Dateigrößenbegrenzung festlegen. 11. Aufzeichnung starten. 12. Fehler genau einmal reproduzieren. 13. Aufzeichnung sofort beenden. 14. Datei eindeutig benennen und sicher speichern. **Analyse** 15. Zuerst Protokollhierarchie, Endpunkte und Konversationen prüfen. 16. Relevante Client-Server-Kommunikation isolieren. 17. ARP, DHCP und DNS vor TCP und Anwendung betrachten. 18. TCP-Verbindungsaufbau, Abbruch und Wiederholungen prüfen. 19. Anschließend TLS- oder Anwendungsprotokoll untersuchen. 20. Zeitstempel mit Server-, Firewall- und Anwendungslogs vergleichen. 21. Beobachtung und mögliche Ursache voneinander trennen. **Validierung** 22. Hypothese durch einen kontrollierten Vergleichstest prüfen. 23. Falls erforderlich, Mitschnitte an zwei Punkten vergleichen. 24. Nach einer Änderung denselben Test erneut durchführen. 25. Ergebnis, Änderung und Nachweis dokumentieren.
--- **21. Wie müssen Paketmitschnitte geschützt werden?**
Datenschutz- und Sicherheitsregeln anzeigen Paketmitschnitte können enthalten: - interne und externe IP-Adressen; - MAC-Adressen; - DNS-Anfragen; - Hostnamen; - Benutzernamen; - unverschlüsselte Passwörter; - Cookies und Sitzungstoken; - E-Mail- oder Chat-Inhalte; - übertragene Dateien; - Zertifikatsinformationen; - Informationen über interne Systeme und Dienste. **Mindestmaßnahmen** - nur mit dokumentierter Berechtigung aufzeichnen; - Umfang und Dauer minimieren; - möglichst früh einen geeigneten Capture-Filter verwenden; - Dateien ausschließlich in geschützten Verzeichnissen speichern; - Zugriff auf zuständige Personen beschränken; - Dateien nicht unkontrolliert per E-Mail oder Messenger versenden; - für externe Analysen nur notwendige Pakete bereitstellen; - Aufbewahrungs- und Löschfristen beachten; - Weitergabe und Bearbeitung dokumentieren; - nicht mehr benötigte Mitschnittdateien sicher löschen. Das Öffnen von **Follow TCP Stream**, **Follow HTTP Stream** oder ähnlichen Ansichten kann zusammenhängende Anwendungsdaten sichtbar machen. Diese Funktionen dürfen deshalb nur bei entsprechender Berechtigung verwendet werden.
--- **22. Kurzreferenz**
Die wichtigsten Befehle und Filter anzeigen **TShark-Befehle** | Aufgabe | Befehl | |---|---| | Version | `[RO] tshark --version` | | Schnittstellen | `[RO] tshark -D` | | 100 Pakete aufzeichnen | `[TEST][PRIV][FILE][SENS] tshark -i 1 -c 100 -w capture.pcapng` | | 60 Sekunden aufzeichnen | `[TEST][PRIV][FILE][SENS] tshark -i 1 -a duration:60 -w capture.pcapng` | | Capture-Filter anwenden | `[TEST][PRIV][FILE][SENS] tshark -i 1 -f "tcp port 443" -a duration:60 -w capture.pcapng` | | Datei lesen | `[RO][FILE][SENS] tshark -n -r capture.pcapng` | | Display-Filter anwenden | `[RO][FILE][SENS] tshark -n -r capture.pcapng -Y "dns"` | | Protokollhierarchie | `[RO][FILE][SENS] tshark -n -r capture.pcapng -q -z io,phs` | | TCP-Konversationen | `[RO][FILE][SENS] tshark -n -r capture.pcapng -q -z conv,tcp` | | IPv4-Endpunkte | `[RO][FILE][SENS] tshark -n -r capture.pcapng -q -z endpoints,ip` | | Dateiinformationen | `[RO][FILE][SENS] capinfos capture.pcapng` | | Dateien zusammenführen | `[RO][FILE][SENS] mergecap -w merged.pcapng part1.pcapng part2.pcapng` | **Wichtige Capture-Filter** | Aufgabe | Filter | |---|---| | Host | `host 192.0.2.10` | | Netz | `net 192.0.2.0/24` | | HTTPS | `tcp port 443` | | DNS | `port 53` | | DHCP | `udp port 67 or udp port 68` | | ICMPv4 | `icmp` | | ICMPv6 | `icmp6` | | ARP | `arp` | **Wichtige Display-Filter** | Aufgabe | Filter | |---|---| | Host | `ip.addr == 192.0.2.10` | | HTTPS-Port | `tcp.port == 443` | | DNS | `dns` | | DHCP | `dhcp` | | TLS-Handshake | `tls.handshake` | | TCP-Verbindungsbeginn | `tcp.flags.syn == 1 && tcp.flags.ack == 0` | | TCP-Abbruch | `tcp.flags.reset == 1` | | Wiederholungsübertragung | `tcp.analysis.retransmission` | | Duplicate ACK | `tcp.analysis.duplicate_ack` | | TCP-Stream | `tcp.stream == 0` |
--- **Merksätze** - Erst Aufzeichnungspunkt und Schnittstelle prüfen, dann den Fehler mitschneiden. - Capture-Filter bestimmen, was gespeichert wird; Display-Filter bestimmen, was angezeigt wird. - Ein fehlendes Paket ist nur dann aussagekräftig, wenn Aufzeichnungspunkt, Filter und Mitschnitt vollständig geprüft wurden. - Wireshark-Markierungen und TCP-Analysehinweise sind Indizien, keine fertige Fehlerursache. - Kurze, reproduzierbare und dokumentierte Mitschnitte sind besser als stundenlange unkontrollierte Aufzeichnungen. - Paketmitschnitte sind sensible Diagnosedaten und müssen entsprechend geschützt werden. - Die Paketaufzeichnung zeigt, was auf dem untersuchten Netzwerkabschnitt sichtbar war – nicht automatisch den vollständigen Kommunikationsweg. --- **Quellen** - [Wireshark User’s Guide – Capturing Live Network Data](https://www.wireshark.org/docs/wsug_html_chunked/ChapterCapture.html) - [Wireshark User’s Guide – Capture Filters](https://www.wireshark.org/docs/wsug_html_chunked/ChCapCaptureFilterSection.html) - [Wireshark User’s Guide – Display Filters](https://www.wireshark.org/docs/wsug_html_chunked/ChWorkBuildDisplayFilterSection.html) - [Wireshark Display Filter Reference](https://www.wireshark.org/docs/dfref/) - [Offizielle TShark-Dokumentation](https://www.wireshark.org/docs/man-pages/tshark.html) - [Offizielle Dumpcap-Dokumentation](https://www.wireshark.org/docs/man-pages/dumpcap.html) - [Offizielle Capinfos-Dokumentation](https://www.wireshark.org/docs/man-pages/capinfos.html) - [Offizielle Mergecap-Dokumentation](https://www.wireshark.org/docs/man-pages/mergecap.html) - [Offizielle Editcap-Dokumentation](https://www.wireshark.org/docs/man-pages/editcap.html) # 2.6 tcpdump und Capture-Filter – Paketmitschnitte im Terminal **Ziel dieser Seite** `tcpdump` ist ein Kommandozeilenwerkzeug zum Aufzeichnen und Anzeigen von Netzwerkpaketen. Es eignet sich besonders für: - Linux- und macOS-Systeme ohne grafische Oberfläche; - Server und Netzwerkgeräte; - SSH-Sitzungen; - kurze, gezielte Paketmitschnitte; - automatisierte oder zeitlich begrenzte Aufzeichnungen; - die Vorbereitung einer späteren Analyse mit Wireshark oder TShark; - die Prüfung, ob ein Paket einen bestimmten Aufzeichnungspunkt erreicht. `tcpdump` verwendet die Capture-Filter-Sprache von `libpcap`. Diese Filter bestimmen bereits während des Mitschnitts, welche Pakete verarbeitet und gespeichert werden. > **Wichtig:** Ein Capture-Filter lässt sich nachträglich nicht rückgängig machen. Pakete, die nicht zum Filter passen, werden nicht in die Mitschnittdatei aufgenommen. --- **Kennzeichnungen** | Kennzeichnung | Bedeutung | |---|---| | `[RO]` | Nur lesender beziehungsweise auswertender Befehl | | `[TEST]` | Aktiver Diagnose- oder Aufzeichnungsvorgang | | `[PRIV]` | Erhöhte Berechtigungen können erforderlich sein | | `[FILE]` | Der Befehl erstellt oder verarbeitet eine Datei | | `[SENS]` | Ausgabe oder Datei kann sensible Informationen enthalten | | `[CHANGE]` | Der Befehl verändert eine Einstellung oder Datei | | `[DISRUPT]` | Der Vorgang kann Netzwerk oder Systembetrieb beeinflussen | --- **1. Auf welchen Betriebssystemen kann tcpdump verwendet werden?**
Betriebssystemübersicht anzeigen | Betriebssystem | Verfügbarkeit | Typischer Aufruf | |---|---|---| | Linux | Meist über die Paketverwaltung installierbar | `sudo tcpdump` | | macOS | Standardmäßig vorhanden | `sudo tcpdump` | | FreeBSD/OpenBSD/NetBSD | Üblicherweise vorhanden | `doas tcpdump` oder `sudo tcpdump` | | Windows | Nicht Bestandteil von Windows | Vorzugsweise TShark oder Wireshark mit Npcap | | Netzwerk-Appliance | Häufig vorhanden, aber herstellerabhängig | Herstellerdokumentation beachten | | Container | Nur mit passenden Netzwerk- und Capture-Berechtigungen | Meist besser auf dem Container-Host mitschneiden | **Version prüfen** ```text [RO] tcpdump --version ``` Die Ausgabe nennt normalerweise sowohl die tcpdump- als auch die libpcap-Version. **Linux: Installation prüfen** ```text [RO] command -v tcpdump ``` **macOS: Installationspfad prüfen** ```text [RO] command -v tcpdump ``` **Windows** Unter Windows sollte für eine vergleichbare Aufgabe normalerweise TShark verwendet werden: ```powershell [RO] tshark --version ``` ```powershell [RO] tshark -D ``` WinDump existiert als tcpdump-ähnliches Werkzeug für Windows, ist aber kein Bestandteil der aktuellen Windows-Bordmittel. Für ein modernes Administrationsumfeld sind Wireshark und TShark mit Npcap in der Regel die besser dokumentierte Lösung.
--- **2. Welche Berechtigungen benötigt tcpdump?**
Capture-Berechtigungen und Sicherheitsprinzip anzeigen Das Lesen von Netzwerkpaketen erfordert in der Regel besondere Betriebssystemberechtigungen. Ein normaler Benutzer darf deshalb häufig keinen Live-Mitschnitt starten. **Typischer Aufruf unter Linux und macOS** ```text [TEST][PRIV][SENS] sudo tcpdump ``` Das Lesen einer bereits vorhandenen Mitschnittdatei benötigt normalerweise keine Capture-Berechtigung: ```text [RO][FILE][SENS] tcpdump -r capture.pcap ``` **Sicherheitsprinzip** - tcpdump nur für den erforderlichen Zeitraum mit erhöhten Rechten starten; - nicht dauerhaft als `root` arbeiten; - Ausgabedateien in einem geschützten Verzeichnis speichern; - Dateiberechtigungen nach dem Mitschnitt kontrollieren; - Paketmitschnitte nicht unkontrolliert weitergeben; - nur autorisierte Schnittstellen und Systeme untersuchen. Je nach Linux-Distribution kann tcpdump mit Linux-Capabilities oder einer herstellerspezifischen Berechtigungsregel ausgestattet sein. Solche Änderungen dürfen nicht pauschal aus fremden Anleitungen übernommen werden. Vorher müssen Sicherheitsrichtlinie, Paketquelle und bestehende Berechtigungen geprüft werden.
--- **3. Wie werden Schnittstellen ermittelt und ausgewählt?**
Schnittstellenbefehle anzeigen **Mit tcpdump verfügbare Capture-Schnittstellen anzeigen** ```text [RO] tcpdump -D ``` Alternativ: ```text [RO] tcpdump --list-interfaces ``` Beispielhafte Schnittstellennamen: | System | Typische Namen | |---|---| | Linux | `eth0`, `ens18`, `enp3s0`, `wlan0`, `lo` | | macOS | `en0`, `en1`, `lo0`, `utun0` | | Container-Host | `docker0`, `br-...`, `veth...` | | VPN | `tun0`, `tap0`, `wg0`, `utun...` | **Bestimmte Schnittstelle verwenden** ```text [TEST][PRIV][SENS] sudo tcpdump -i eth0 ``` ```text [TEST][PRIV][SENS] sudo tcpdump -i en0 ``` **Loopbackverkehr aufzeichnen** Linux: ```text [TEST][PRIV][SENS] sudo tcpdump -i lo ``` macOS: ```text [TEST][PRIV][SENS] sudo tcpdump -i lo0 ``` **Mehrere reguläre Schnittstellen erfassen** ```text [TEST][PRIV][SENS] sudo tcpdump -i any ``` Die Pseudoschnittstelle `any` wird auf Linux und aktuellen macOS-Versionen unterstützt. Dabei gelten Einschränkungen: - der Mitschnitt erfolgt nicht im Promiscuous Mode; - unterschiedliche Link-Layer-Typen können auftreten; - die Ausgabe kann mehr Verkehr enthalten als erwartet; - die konkrete Eingangsschnittstelle sollte bei der Auswertung beachtet werden. **Richtige Schnittstelle kontrollieren** ```text [TEST][PRIV][SENS] sudo tcpdump -i en0 -nn -c 20 ``` Danach wird ein bekannter, autorisierter Test erzeugt, beispielsweise: ```text ping 192.0.2.1 ``` Sind die erwarteten Pakete nicht sichtbar, müssen folgende Punkte geprüft werden: - falsche Schnittstelle; - VPN- oder Tunnelschnittstelle übersehen; - Loopbackverkehr auf physischer Schnittstelle gesucht; - falscher Netzwerk-Namespace; - Paket passiert den untersuchten Host nicht; - Capture-Berechtigung fehlt; - Capture-Filter ist zu eng.
--- **4. Welche Optionen werden bei tcpdump häufig verwendet?**
Optionstabelle anzeigen | Option | Bedeutung | |---|---| | `-D` | Verfügbare Capture-Schnittstellen anzeigen | | `-i INTERFACE` | Schnittstelle auswählen | | `-n` | Adressen und andere numerische Angaben nicht in Namen umwandeln | | `-nn` | Insbesondere auch Portnummern numerisch anzeigen | | `-c ANZAHL` | Nach einer bestimmten Paketanzahl beenden | | `-w DATEI` | Rohpakete in eine Datei schreiben | | `-r DATEI` | Pakete aus einer Datei lesen | | `-v` | Ausführlichere Ausgabe | | `-vv` | Noch ausführlichere Ausgabe | | `-vvv` | Maximale standardmäßige Detailstufe | | `-q` | Verkürzte Ausgabe | | `-e` | Link-Layer-Header, beispielsweise MAC-Adressen, anzeigen | | `-A` | Nutzdaten als ASCII anzeigen | | `-x` | Paketdaten hexadezimal anzeigen | | `-X` | Paketdaten hexadezimal und als ASCII anzeigen | | `-XX` | Wie `-X`, einschließlich Link-Layer-Header | | `-tt` | Zeit als Unix-Zeitstempel ausgeben | | `-ttt` | Zeitdifferenz zum vorherigen Paket ausgeben | | `-tttt` | Datum und Uhrzeit pro Paket ausgeben | | `-ttttt` | Zeitdifferenz zum ersten angezeigten Paket ausgeben | | `-s LÄNGE` | Maximale Anzahl aufgezeichneter Bytes je Paket festlegen | | `-B GRÖSSE` | Betriebssystem-Capture-Puffer in KiB festlegen | | `-C GRÖSSE` | Ausgabedatei nach Erreichen einer Größe wechseln | | `-G SEKUNDEN` | Ausgabedatei zeitgesteuert wechseln | | `-W ANZAHL` | Anzahl rotierter Dateien begrenzen | | `-U` | Pakete zeitnah in die Ausgabedatei schreiben | | `-K` | Prüfsummenprüfung bei der Anzeige deaktivieren | | `-Q in\|out\|inout` | Aufzeichnungsrichtung festlegen, sofern unterstützt | | `-p` | Promiscuous Mode nicht aktivieren | | `-F DATEI` | Capture-Filter aus einer Datei lesen | Nicht jede Option wird von jeder Betriebssystem- und libpcap-Version unterstützt. Deshalb sollten Version und lokale Hilfeseite geprüft werden: ```text [RO] tcpdump --version ``` ```text [RO] man tcpdump ```
--- **5. Wie wird ein kurzer, kontrollierter Mitschnitt durchgeführt?**
Grundlegende Mitschnittbefehle anzeigen **20 Pakete anzeigen und danach beenden** ```text [TEST][PRIV][SENS] sudo tcpdump -i eth0 -nn -c 20 ``` **100 Pakete in eine Datei schreiben** ```text [TEST][PRIV][FILE][SENS] sudo tcpdump -i eth0 -nn -c 100 -w capture.pcap ``` **Nur Verkehr eines bestimmten Hosts aufzeichnen** ```text [TEST][PRIV][FILE][SENS] sudo tcpdump -i eth0 -nn -c 500 -w host-test.pcap 'host 192.0.2.10' ``` **Nur HTTPS-Verkehr zu einem Server aufzeichnen** ```text [TEST][PRIV][FILE][SENS] sudo tcpdump -i eth0 -nn -c 1000 -w https-test.pcap 'host 198.51.100.20 and tcp port 443' ``` **Mitschnitt manuell beenden** Ein laufender Mitschnitt wird normalerweise mit folgender Tastenkombination beendet: ```text [Strg] + [C] ``` Nach dem Beenden zeigt tcpdump Zähler an: ```text packets captured packets received by filter packets dropped by kernel ``` Die genaue Bedeutung von `packets received by filter` ist betriebssystemabhängig. Besonders wichtig ist: ```text packets dropped by kernel ``` Ein Wert größer als null weist darauf hin, dass der Capture-Mechanismus Pakete wegen fehlenden Pufferplatzes verworfen hat. Die Aufzeichnung ist dann möglicherweise unvollständig.
--- **6. Wie ist ein tcpdump-Filter grundsätzlich aufgebaut?**
BPF-Filterlogik anzeigen Ein Capture-Filter besteht aus einer oder mehreren Bedingungen. Diese können mit logischen Operatoren verbunden werden. | Operator | Bedeutung | |---|---| | `and` | Beide Bedingungen müssen zutreffen | | `or` | Mindestens eine Bedingung muss zutreffen | | `not` | Bedingung wird ausgeschlossen | | `( )` | Gruppiert mehrere Bedingungen | **Einzelne Bedingung** ```text host 192.0.2.10 ``` **Zwei Bedingungen mit `and`** ```text host 192.0.2.10 and tcp port 443 ``` **Alternative Bedingungen mit `or`** ```text tcp port 80 or tcp port 443 ``` **Bedingung ausschließen** ```text not port 22 ``` **Gruppierung mit Klammern** ```text host 192.0.2.10 and (tcp port 80 or tcp port 443) ``` Filter mit Leerzeichen, Klammern oder Shell-Sonderzeichen sollten immer in einfache Anführungszeichen gesetzt werden: ```text sudo tcpdump -i eth0 -nn 'host 192.0.2.10 and (tcp port 80 or tcp port 443)' ``` Dadurch wird verhindert, dass die Shell Zeichen wie `(`, `)`, `!`, `&` oder `|` selbst interpretiert.
--- **7. Welche Host-, Netz- und Richtungsfilter gibt es?**
Host- und Netzfilter anzeigen | Aufgabe | Filter | |---|---| | Host als Quelle oder Ziel | `host 192.0.2.10` | | Nur Pakete von einem Host | `src host 192.0.2.10` | | Nur Pakete zu einem Host | `dst host 192.0.2.10` | | Einer von zwei Hosts | `host 192.0.2.10 or host 198.51.100.20` | | Kommunikation zwischen zwei Hosts | `host 192.0.2.10 and host 198.51.100.20` | | Host ausschließen | `not host 192.0.2.10` | | IPv4-Netz | `net 192.0.2.0/24` | | Nur Quelle aus einem Netz | `src net 192.0.2.0/24` | | Nur Ziel in einem Netz | `dst net 198.51.100.0/24` | | Netz ausschließen | `not net 192.0.2.0/24` | | Bestimmte Ethernet-Adresse | `ether host 00:11:22:33:44:55` | | Nur Ethernet-Quelle | `ether src 00:11:22:33:44:55` | | Nur Ethernet-Ziel | `ether dst 00:11:22:33:44:55` | **Kommunikation zwischen genau zwei IPv4-Systemen** ```text [TEST][PRIV][SENS] sudo tcpdump -i eth0 -nn 'host 192.0.2.10 and host 198.51.100.20' ``` Bei zwei unterschiedlichen Hosts bedeutet diese Schreibweise praktisch, dass beide Adressen im Paket vorkommen müssen: eine als Quelle und die andere als Ziel. **Nur Verkehr vom Client zum Server** ```text [TEST][PRIV][SENS] sudo tcpdump -i eth0 -nn 'src host 192.0.2.10 and dst host 198.51.100.20' ``` **Nur Rückverkehr** ```text [TEST][PRIV][SENS] sudo tcpdump -i eth0 -nn 'src host 198.51.100.20 and dst host 192.0.2.10' ```
--- **8. Welche Protokoll- und Portfilter werden häufig verwendet?**
Protokoll- und Portfilter anzeigen | Aufgabe | Filter | |---|---| | Nur IPv4 | `ip` | | Nur IPv6 | `ip6` | | TCP | `tcp` | | UDP | `udp` | | ICMPv4 | `icmp` | | ICMPv6 | `icmp6` | | ARP | `arp` | | TCP- oder UDP-Port 53 | `port 53` | | Nur TCP-Port 53 | `tcp port 53` | | Nur UDP-Port 53 | `udp port 53` | | TCP-Quellport 443 | `tcp src port 443` | | TCP-Zielport 443 | `tcp dst port 443` | | Portbereich | `tcp portrange 8000-8100` | | Zielportbereich | `tcp dst portrange 8000-8100` | | TCP-Port 80 oder 443 | `tcp port 80 or tcp port 443` | | TCP-Port 22 ausschließen | `tcp and not port 22` | | Broadcastverkehr | `ether broadcast` | | Multicastverkehr | `ether multicast` | **Wichtiger Unterschied** ```text port 53 ``` erfasst TCP und UDP auf Port 53. ```text udp port 53 ``` erfasst ausschließlich UDP auf Port 53. ```text tcp port 53 ``` erfasst ausschließlich TCP auf Port 53. Dieser Unterschied ist beispielsweise bei DNS wichtig, da DNS sowohl UDP als auch TCP verwenden kann.
--- **9. Welche Filter eignen sich für typische Netzwerkprotokolle?**
Protokolltabelle anzeigen | Protokoll oder Aufgabe | Capture-Filter | |---|---| | ARP | `arp` | | ICMPv4 | `icmp` | | ICMPv6 | `icmp6` | | DNS über TCP und UDP | `port 53` | | DHCPv4 | `udp port 67 or udp port 68` | | DHCPv6 | `udp port 546 or udp port 547` | | HTTP | `tcp port 80` | | HTTPS | `tcp port 443` | | HTTP und HTTPS | `tcp port 80 or tcp port 443` | | SSH | `tcp port 22` | | SMTP | `tcp port 25` | | NTP | `udp port 123` | | SNMP | `udp port 161 or udp port 162` | | LDAP | `tcp port 389 or udp port 389` | | LDAPS | `tcp port 636` | | Kerberos | `port 88` | | SMB | `tcp port 445` | | RDP | `tcp port 3389 or udp port 3389` | | SIP | `port 5060 or port 5061` | | TFTP | `udp port 69` | | WireGuard | Üblicherweise der konfigurierte UDP-Port, beispielsweise `udp port 51820` | | IPsec IKE | `udp port 500 or udp port 4500` | | VXLAN-Standardport | `udp port 4789` | **DNS-Aufzeichnung** ```text [TEST][PRIV][FILE][SENS] sudo tcpdump -i eth0 -nn -w dns.pcap 'port 53' ``` **DHCPv4-Aufzeichnung** ```text [TEST][PRIV][FILE][SENS] sudo tcpdump -i eth0 -nn -e -w dhcp.pcap 'udp port 67 or udp port 68' ``` **SMB-Kommunikation mit einem Server** ```text [TEST][PRIV][FILE][SENS] sudo tcpdump -i eth0 -nn -w smb-test.pcap 'host 198.51.100.20 and tcp port 445' ``` > Portfilter zeigen Verkehr auf den angegebenen Ports. Sie beweisen nicht automatisch, dass der Verkehr tatsächlich das erwartete Anwendungsprotokoll enthält.
--- **10. Wie werden TCP-Verbindungsaufbau und Verbindungsabbruch gefiltert?**
TCP-Flag-Filter anzeigen Die TCP-Steuerflags befinden sich im TCP-Header. Mit `tcp[tcpflags]` lassen sie sich gezielt prüfen. | Aufgabe | Capture-Filter | |---|---| | Alle Pakete mit gesetztem SYN | `tcp[tcpflags] & tcp-syn != 0` | | Initiales SYN ohne ACK | `tcp[tcpflags] & (tcp-syn|tcp-ack) == tcp-syn` | | SYN und ACK gesetzt | `tcp[tcpflags] & (tcp-syn|tcp-ack) == (tcp-syn|tcp-ack)` | | Pakete mit RST | `tcp[tcpflags] & tcp-rst != 0` | | Pakete mit FIN | `tcp[tcpflags] & tcp-fin != 0` | | Pakete mit PSH | `tcp[tcpflags] & tcp-push != 0` | **Neue TCP-Verbindungsversuche anzeigen** ```text [TEST][PRIV][SENS] sudo tcpdump -i eth0 -nn 'tcp[tcpflags] & (tcp-syn|tcp-ack) == tcp-syn' ``` **SYN/ACK-Antworten anzeigen** ```text [TEST][PRIV][SENS] sudo tcpdump -i eth0 -nn 'tcp[tcpflags] & (tcp-syn|tcp-ack) == (tcp-syn|tcp-ack)' ``` **TCP-Resets anzeigen** ```text [TEST][PRIV][SENS] sudo tcpdump -i eth0 -nn 'tcp[tcpflags] & tcp-rst != 0' ``` **Nur TCP-Resets eines bestimmten Servers** ```text [TEST][PRIV][SENS] sudo tcpdump -i eth0 -nn 'host 198.51.100.20 and tcp[tcpflags] & tcp-rst != 0' ``` **Interpretation** | Beobachtung | Mögliche Bedeutung | |---|---| | Wiederholte SYN-Pakete ohne SYN/ACK | Keine Antwort sichtbar, Paketverlust, Firewall, Routing- oder Serverproblem | | SYN wird mit RST beantwortet | System erreichbar, aber Port geschlossen oder Verbindung abgelehnt | | SYN/ACK erreicht Client nicht | Rückweg, Firewall, asymmetrisches Routing oder Aufzeichnungspunkt prüfen | | RST während bestehender Verbindung | Endpunkt oder Zwischensystem bricht die TCP-Verbindung ab | | FIN-Sequenz | Regulärer geordneter Verbindungsabbau möglich | tcpdump kennzeichnet Wiederholungsübertragungen nicht so komfortabel wie Wireshark. Für eine detaillierte TCP-Analyse sollte die Datei anschließend mit Wireshark oder TShark untersucht werden.
--- **11. Wie werden Paketgrößen gefiltert?**
Längenfilter anzeigen | Aufgabe | Filter | |---|---| | Pakete kleiner oder gleich 100 Byte | `less 100` | | Pakete größer oder gleich 1500 Byte | `greater 1500` | | TCP-Pakete größer oder gleich 1500 Byte | `tcp and greater 1500` | | UDP-Pakete kleiner oder gleich 100 Byte | `udp and less 100` | **Große IPv4-Pakete anzeigen** ```text [TEST][PRIV][SENS] sudo tcpdump -i eth0 -nn 'ip and greater 1500' ``` Bei `less` und `greater` ist zu beachten: - `less N` bedeutet kleiner oder gleich `N`; - `greater N` bedeutet größer oder gleich `N`; - die Paketlänge allein beweist noch kein MTU-Problem; - VLAN-, Tunnel- und Link-Layer-Header beeinflussen die beobachtete Größe; - Fragmentierung und Path-MTU-Discovery müssen getrennt untersucht werden.
--- **12. Wie werden VLAN-Pakete gefiltert?**
VLAN-Filter und Fallstricke anzeigen **Pakete mit 802.1Q-VLAN-Tag** ```text vlan ``` **Bestimmte VLAN-ID** ```text vlan 100 ``` **IPv4-Verkehr im VLAN 100** ```text vlan 100 and ip ``` **HTTPS-Verkehr im VLAN 100** ```text vlan 100 and tcp port 443 ``` **Aufzeichnung** ```text [TEST][PRIV][FILE][SENS] sudo tcpdump -i eth0 -nn -e -w vlan100.pcap 'vlan 100' ``` Die Option `-e` zeigt bei der Textausgabe den Link-Layer-Header an und kann dadurch VLAN- und MAC-Informationen sichtbar machen. **Wichtige Einschränkungen** - Netzwerkkarten können VLAN-Tags per Hardware-Offloading entfernen oder separat an das Betriebssystem übergeben. - Ein auf dem Endgerät fehlender VLAN-Tag beweist deshalb nicht automatisch, dass auf dem Kabel kein VLAN-Tag vorhanden war. - Access-Ports liefern dem Endgerät normalerweise ungetaggte Frames. - Trunk-Ports können mehrere getaggte VLANs transportieren. - Bei mehrfach getaggten Frames kann ein weiterer `vlan`-Ausdruck erforderlich sein. Beispiel für doppelte VLAN-Kapselung: ```text vlan 100 and vlan 200 ``` Ob diese Pakete am gewählten Aufzeichnungspunkt sichtbar sind, hängt von Netzwerkkarte, Treiber, Offloading und Switch-Konfiguration ab.
--- **13. Wie wird die Textausgabe sinnvoll formatiert?**
Ausgabeoptionen und Beispiele anzeigen **Numerische Ausgabe mit Datum und Uhrzeit** ```text [TEST][PRIV][SENS] sudo tcpdump -i eth0 -nn -tttt ``` **MAC-Adressen anzeigen** ```text [TEST][PRIV][SENS] sudo tcpdump -i eth0 -nn -e ``` **Ausführliche Ausgabe** ```text [TEST][PRIV][SENS] sudo tcpdump -i eth0 -nn -vv ``` **Hexadezimal- und ASCII-Ausgabe** ```text [TEST][PRIV][SENS] sudo tcpdump -i eth0 -nn -X -c 10 ``` **Link-Layer-Header, Hexadezimal- und ASCII-Daten** ```text [TEST][PRIV][SENS] sudo tcpdump -i eth0 -nn -XX -c 10 ``` **Kurzausgabe** ```text [TEST][PRIV][SENS] sudo tcpdump -i eth0 -nn -q ``` **Bedeutung der Zeitoptionen** | Option | Ausgabe | |---|---| | Keine zusätzliche Option | Uhrzeit seit Mitternacht | | `-tt` | Sekunden seit Unix-Epoche | | `-ttt` | Differenz zum vorherigen Paket | | `-tttt` | Datum und Uhrzeit | | `-ttttt` | Differenz zum ersten Paket | > `-A`, `-X` und `-XX` können sensible Nutzdaten sichtbar machen. Sie sollten nur gezielt und bei entsprechender Berechtigung verwendet werden.
--- **14. Wie werden Mitschnittdateien gespeichert und gelesen?**
Dateibefehle anzeigen **Pakete als Rohdaten speichern** ```text [TEST][PRIV][FILE][SENS] sudo tcpdump -i eth0 -nn -w capture.pcap ``` Während `-w` verwendet wird, schreibt tcpdump die Rohpakete in die Datei. Die normale Paketbeschreibung erscheint dabei nicht automatisch im Terminal. **Vorhandene Datei lesen** ```text [RO][FILE][SENS] tcpdump -nn -r capture.pcap ``` **Mit Datum und ausführlicher Ausgabe lesen** ```text [RO][FILE][SENS] tcpdump -nn -tttt -vv -r capture.pcap ``` **Nur DNS aus einer vorhandenen Datei lesen** ```text [RO][FILE][SENS] tcpdump -nn -r capture.pcap 'port 53' ``` **Nur Verkehr eines Hosts lesen** ```text [RO][FILE][SENS] tcpdump -nn -r capture.pcap 'host 192.0.2.10' ``` **Paketanzahl einer Datei bestimmen, sofern von der installierten Version unterstützt** ```text [RO][FILE][SENS] tcpdump --count -r capture.pcap ``` Alternativ kann das Wireshark-Werkzeug Capinfos verwendet werden: ```text [RO][FILE][SENS] capinfos capture.pcap ``` **Datei während des Mitschnitts paketweise aktualisieren** ```text [TEST][PRIV][FILE][SENS] sudo tcpdump -i eth0 -nn -U -w capture.pcap ``` `-U` sorgt dafür, dass jedes empfangene Paket zeitnah in die Ausgabedatei geschrieben wird. Das kann hilfreich sein, wenn eine Aufzeichnung während eines Absturzes oder Fehlers möglichst aktuell bleiben soll.
--- **15. Wie wird die Größe eines Mitschnitts begrenzt?**
Dateigröße und Ringpuffer anzeigen **Nach ungefähr 100 MB eine neue Datei beginnen** ```text [TEST][PRIV][FILE][SENS] sudo tcpdump -i eth0 -nn -C 100 -w capture.pcap ``` Ohne Einheit verwendet `-C` Millionen Byte: ```text 100 = 100.000.000 Byte ``` Moderne tcpdump-Versionen unterstützen zusätzlich Einheiten: | Angabe | Einheit | |---|---| | `100K` | 100 × 1.024 Byte | | `100M` | 100 × 1.048.576 Byte | | `1G` | 1 × 1.073.741.824 Byte | **Zehn Dateien mit jeweils ungefähr 100 MiB als Ringpuffer** ```text [TEST][PRIV][FILE][SENS] sudo tcpdump -i eth0 -nn -C 100M -W 10 -w capture.pcap ``` Bei Verwendung von `-C` zusammen mit `-W`: - wird nach Erreichen der Dateigröße zur nächsten Datei gewechselt; - wird die Anzahl der Dateien begrenzt; - beginnt tcpdump nach der letzten Datei wieder mit der ersten; - werden ältere Dateien überschrieben; - entsteht ein echter rotierender Ringpuffer. **Ungefähre maximale Gesamtgröße** ```text 10 Dateien × 100 MiB = ungefähr 1.000 MiB ``` Die Größenprüfung erfolgt vor dem Schreiben eines neuen Pakets. Eine Datei kann deshalb geringfügig größer als der angegebene Wert werden.
--- **16. Wie werden Mitschnittdateien zeitgesteuert gewechselt?**
Zeitrotation korrekt verwenden **Alle fünf Minuten eine neue Datei** ```text [TEST][PRIV][FILE][SENS] sudo tcpdump -i eth0 -nn -G 300 -w 'capture-%Y%m%d-%H%M%S.pcap' ``` Beispielhafte Dateinamen: ```text capture-20260731-140000.pcap capture-20260731-140500.pcap capture-20260731-141000.pcap ``` **Nach zwölf Fünf-Minuten-Dateien beenden** ```text [TEST][PRIV][FILE][SENS] sudo tcpdump -i eth0 -nn -G 300 -W 12 -w 'capture-%Y%m%d-%H%M%S.pcap' ``` Das entspricht ungefähr: ```text 12 Dateien × 5 Minuten = 60 Minuten ``` **Wichtiger Unterschied** | Kombination | Verhalten | |---|---| | `-C` und `-W` | Ringpuffer; ältere Dateien werden überschrieben | | `-G` und `-W` | Nach der festgelegten Anzahl Dateien wird tcpdump beendet | | `-C`, `-G` und `-W` gemeinsam | `-W` begrenzt nach aktueller Dokumentation nicht zuverlässig wie bei den einzelnen Varianten und beeinflusst hauptsächlich die Dateinamen | Bei `-G` sollte `-w` einen eindeutigen Zeitplatzhalter enthalten. Andernfalls kann jede neue Datei denselben Namen erhalten und die vorherige Datei überschreiben. **Sicheres Beispiel** ```text -w 'capture-%Y%m%d-%H%M%S.pcap' ``` **Problematisches Beispiel** ```text -w capture.pcap ```
--- **17. Wie wird die Aufzeichnungsdauer auf Linux und macOS begrenzt?**
Zeitlich begrenzte Aufzeichnung anzeigen tcpdump besitzt die Option `-G` für den Dateiw echsel, aber keine allgemeine, plattformübergreifende Option nach dem Muster „nach genau 60 Sekunden stoppen“. **Linux mit GNU `timeout`** ```text [TEST][PRIV][FILE][SENS] sudo timeout 60 tcpdump -i eth0 -nn -w capture.pcap 'host 192.0.2.10' ``` `timeout` gehört nicht zu tcpdump, sondern zu den GNU Coreutils. Der Befehl steht nicht auf jedem Unix-System standardmäßig zur Verfügung. **macOS** Auf macOS ist GNU `timeout` standardmäßig nicht vorhanden. Stattdessen sind folgende Methoden geeignet: - mit `-c` eine maximale Paketanzahl festlegen; - mit `-G` und `-W 1` genau eine zeitlich begrenzte Datei erstellen; - den Mitschnitt kontrolliert mit `[Strg] + [C]` beenden. **macOS: nach einem Zeitintervall beenden** ```text [TEST][PRIV][FILE][SENS] sudo tcpdump -i en0 -nn -G 60 -W 1 -w 'capture-%Y%m%d-%H%M%S.pcap' 'host 192.0.2.10' ``` Dieser Befehl erstellt eine Aufzeichnungsdatei und beendet tcpdump nach dem ersten Rotationsintervall. > Vor dem praktischen Einsatz sollte das Verhalten der lokal installierten tcpdump-Version mit einem kurzen Test geprüft werden.
--- **18. Wie wird die Snapshot-Länge verwendet?**
Snapshot-Länge und Auswirkungen anzeigen Die Snapshot-Länge bestimmt, wie viele Byte eines Pakets gespeichert werden. ```text -s LÄNGE ``` Beispiel: ```text [TEST][PRIV][FILE][SENS] sudo tcpdump -i eth0 -nn -s 128 -w headers.pcap ``` Damit werden höchstens 128 Byte je Paket aufgezeichnet. **Vorteile einer verkürzten Snapshot-Länge** - kleinere Mitschnittdateien; - weniger Nutzdaten werden gespeichert; - geringerer Speicherbedarf; - bei sehr hohem Datenaufkommen möglicherweise weniger Verarbeitungsaufwand. **Nachteile** - Protokollinformationen können abgeschnitten werden; - Anwendungsdaten fehlen; - Pakete lassen sich möglicherweise nicht vollständig analysieren; - VLAN-, Tunnel- und umfangreiche Protokollheader können mehr Platz benötigen; - Wireshark zeigt möglicherweise abgeschnittene Pakete an. Abgeschnittene Pakete können in der tcpdump-Ausgabe mit einer Kennzeichnung wie dieser erscheinen: ```text [|proto] ``` Die aktuelle tcpdump-Standard-Snapshot-Länge ist sehr groß und erfasst normalerweise das vollständige Paket. Eine kleinere Snapshot-Länge sollte nur verwendet werden, wenn klar ist, welche Header und Daten für die Diagnose benötigt werden.
--- **19. Wie werden Paketverluste während des Mitschnitts erkannt?**
Capture-Drops und Gegenmaßnahmen anzeigen Beim Beenden zeigt tcpdump normalerweise unter anderem: ```text packets captured packets received by filter packets dropped by kernel ``` **Bewertung** | Zähler | Bedeutung | |---|---| | `packets captured` | Von tcpdump empfangene und verarbeitete Pakete | | `packets received by filter` | Betriebssystemabhängiger Zähler des Capture-Mechanismus | | `packets dropped by kernel` | Wegen fehlenden Capture-Pufferplatzes verworfene Pakete | Sind Kernel-Drops vorhanden, können folgende Maßnahmen helfen: 1. Capture-Filter enger setzen. 2. Mitschnitt auf eine Datei schreiben statt alles im Terminal auszugeben. 3. Ausgabeoptionen wie `-A`, `-X`, `-XX` oder `-vvv` während des Live-Mitschnitts vermeiden. 4. Capture-Puffer vorsichtig vergrößern. 5. Snapshot-Länge nur bei fachlicher Begründung verkleinern. 6. Auf einem leistungsfähigeren oder geeigneteren System mitschneiden. 7. Festplattenleistung und freien Speicherplatz prüfen. 8. Netzwerk-TAP oder spezielle Capture-Hardware verwenden. **Capture-Puffer beispielsweise auf 4.096 KiB setzen** ```text [TEST][PRIV][FILE][SENS] sudo tcpdump -i eth0 -nn -B 4096 -w capture.pcap ``` Ein größerer Puffer garantiert keinen verlustfreien Mitschnitt. Der Wert muss zum Betriebssystem, Datenaufkommen und verfügbaren Speicher passen.
--- **20. Warum zeigt tcpdump manchmal fehlerhafte Prüfsummen an?**
Checksum-Offloading erklären Netzwerkkarten können Prüfsummenberechnungen für IP, TCP oder UDP übernehmen. Bei ausgehenden Paketen kann tcpdump das Paket erfassen, bevor die Netzwerkkarte die endgültige Prüfsumme eingesetzt hat. Dadurch kann tcpdump scheinbar fehlerhafte Prüfsummen anzeigen, obwohl das Paket korrekt übertragen wurde. **Prüfsummenprüfung bei der Anzeige deaktivieren** ```text [RO][FILE][SENS] tcpdump -K -nn -r capture.pcap ``` Live: ```text [TEST][PRIV][SENS] sudo tcpdump -i eth0 -K -nn ``` `-K` verhindert lediglich die Prüfsummenprüfung durch tcpdump. Es repariert keine Pakete und verändert nicht die Netzwerkkonfiguration. **Sinnvolle Prüfung** - Mitschnitt auf der empfangenden Gegenstelle vergleichen; - Netzwerkpfad oder TAP untersuchen; - Offloading-Einstellungen dokumentieren; - einen angezeigten Prüfsummenfehler nicht ohne weitere Prüfung als Netzwerkdefekt bewerten. Das Deaktivieren von Hardware-Offloading wäre eine Systemänderung und kann Leistung oder Verhalten beeinflussen. Es gehört deshalb nicht zu den ersten Diagnosemaßnahmen.
--- **21. Wie wird eingehender oder ausgehender Verkehr gefiltert?**
Richtungsfilter anzeigen Auf unterstützten Plattformen kann `-Q` verwendet werden: | Option | Bedeutung | |---|---| | `-Q in` | Nur eingehender Verkehr | | `-Q out` | Nur ausgehender Verkehr | | `-Q inout` | Beide Richtungen | **Nur eingehende Pakete** ```text [TEST][PRIV][SENS] sudo tcpdump -i eth0 -Q in -nn ``` **Nur ausgehende DNS-Pakete** ```text [TEST][PRIV][SENS] sudo tcpdump -i eth0 -Q out -nn 'port 53' ``` `-Q` wird nicht auf jeder Plattform und nicht von jeder Capture-Schnittstelle unterstützt. Eine portablere Alternative besteht darin, Quell- und Zieladresse ausdrücklich zu filtern: ```text src host 192.0.2.10 ``` oder: ```text dst host 192.0.2.10 ``` Dabei wird die Richtung anhand der Paketadressen und nicht anhand der Betriebssystem-Schnittstellenrichtung bestimmt.
--- **22. Wie wird ein Filter vor dem eigentlichen Mitschnitt geprüft?**
Filtertest und Fehlermeldungen anzeigen Ein falsch formulierter Filter kann dazu führen, dass tcpdump nicht startet oder unerwartete Pakete erfasst. **Kurzer Praxistest** ```text [TEST][PRIV][SENS] sudo tcpdump -i eth0 -nn -c 10 'host 192.0.2.10 and tcp port 443' ``` **Kompilierten BPF-Code anzeigen** ```text [RO][PRIV] sudo tcpdump -i eth0 -d 'host 192.0.2.10 and tcp port 443' ``` `-d` kompiliert den Filter, gibt die resultierenden BPF-Anweisungen lesbar aus und beendet tcpdump, ohne einen normalen Mitschnitt zu starten. **Filter aus einer Datei lesen** Beispielinhalt einer autorisiert erstellten Filterdatei: ```text host 192.0.2.10 and (tcp port 80 or tcp port 443) ``` Filterdatei verwenden: ```text [TEST][PRIV][SENS] sudo tcpdump -i eth0 -nn -F capture-filter.txt ``` Wird `-F` verwendet, wird ein zusätzlicher Filterausdruck auf der Kommandozeile ignoriert. Deshalb sollte nicht gleichzeitig ein weiterer Filter hinter dem Befehl angegeben werden.
--- **23. Welche typischen Fehler treten bei tcpdump auf?**
Fehlertabelle anzeigen | Fehler oder Beobachtung | Wahrscheinliche Erklärung | Prüfung | |---|---|---| | `tcpdump: command not found` | tcpdump nicht installiert oder nicht im Suchpfad | `command -v tcpdump` | | `You don't have permission to capture` | Capture-Berechtigung fehlt | Berechtigungen und Sicherheitsrichtlinie prüfen | | Keine Pakete sichtbar | Falsche Schnittstelle oder zu enger Filter | `tcpdump -D`, Kontrollmitschnitt ohne Filter | | Namen statt IP-Adressen | Namensauflösung aktiv | `-nn` verwenden | | Mitschnittdatei wächst unbegrenzt | Keine Größen- oder Zeitbegrenzung | `-C`, `-W` oder `-G` verwenden | | Nur eine Datei trotz `-G` | Dateiname enthält keinen eindeutigen Zeitplatzhalter | Zeitformat in `-w` ergänzen | | Alte Dateien werden überschrieben | Ringpuffer aktiv oder Dateiname nicht eindeutig | Optionen und Zielverzeichnis prüfen | | Hohe Anzahl `dropped by kernel` | Capture-Puffer oder Systemleistung reicht nicht | Filter, `-B`, Ausgabe und Speicher prüfen | | `bad udp cksum` oder ähnliche Meldung | Möglicherweise Checksum Offloading | Gegenstelle vergleichen oder Anzeige mit `-K` prüfen | | Pakete erscheinen abgeschnitten | Snapshot-Länge zu klein | `-s`-Einstellung prüfen | | VLAN-Tag fehlt | Access-Port oder Hardware-Offloading | Switch-Port, Treiber und Gegenmitschnitt prüfen | | Fremder Unicastverkehr fehlt | Switch sendet ihn nicht an diesen Port | Autorisierten SPAN-Port oder TAP verwenden | | Filter funktioniert in Wireshark, aber nicht in tcpdump | Display-Filter mit Capture-Filter verwechselt | libpcap-Syntax verwenden | | SSH-Mitschnitt enthält überwiegend eigene Sitzung | Administrationsverbindung wird mitgeschnitten | Eigene SSH-Verbindung gezielt ausschließen | **Eigene SSH-Sitzung ausschließen** ```text [TEST][PRIV][FILE][SENS] sudo tcpdump -i eth0 -nn -w capture.pcap 'not tcp port 22' ``` Dieser Filter schließt allerdings sämtlichen TCP-Verkehr auf Port 22 aus. Falls SSH selbst untersucht werden soll, darf dieser Filter nicht verwendet werden.
--- **24. Wie wird tcpdump über SSH sicher eingesetzt?**
Remote-Diagnose anzeigen Beim Start von tcpdump über SSH wird auch die eigene SSH-Verbindung sichtbar, sofern sie den untersuchten Netzwerkpfad verwendet. **Eigene SSH-Verbindung ausschließen** ```text [TEST][PRIV][FILE][SENS] sudo tcpdump -i eth0 -nn -w capture.pcap 'not tcp port 22' ``` Besser ist ein genauer Ausschluss, wenn die Managementadresse bekannt ist: ```text [TEST][PRIV][FILE][SENS] sudo tcpdump -i eth0 -nn -w capture.pcap 'not (host 192.0.2.50 and tcp port 22)' ``` Dabei ist `192.0.2.50` beispielhaft die autorisierte Managementstation. **Risiken einer Remote-Sitzung** - die eigene SSH-Verbindung kann den Mitschnitt vergrößern; - die Mitschnittdatei kann auf einem produktiven Server Speicherplatz belegen; - ein Verbindungsabbruch kann einen unbegrenzt gestarteten Mitschnitt weiterlaufen lassen; - eine Shell-Pipe kann sensible Paketdaten über die Administrationsverbindung übertragen. Deshalb sollten mindestens eine dieser Begrenzungen verwendet werden: - Paketanzahl mit `-c`; - Dateigröße mit `-C`; - Ringpuffer mit `-C` und `-W`; - zeitliche Begrenzung mit `-G` und `-W`; - enger Capture-Filter. Nach der Diagnose muss geprüft werden, ob tcpdump noch läuft: ```text [RO] pgrep -a tcpdump ``` Dieser Befehl ist auf Linux üblich. Die genaue Verfügbarkeit ist betriebssystemabhängig.
--- **25. Wie werden Container- und VM-Verbindungen untersucht?**
Virtuelle Netzwerke und Namespaces anzeigen Bei Containern und virtuellen Maschinen kann der Verkehr an mehreren Stellen sichtbar sein: ```text Anwendung ↓ Container- oder Gast-Schnittstelle ↓ virtuelle Bridge oder virtueller Switch ↓ Host-Schnittstelle ↓ physisches Netzwerk ``` **Typische Linux-Schnittstellen** | Schnittstelle | Bedeutung | |---|---| | `docker0` | Standard-Docker-Bridge | | `br-...` | Benutzerdefinierte Docker-Bridge | | `veth...` | Virtuelles Ethernet-Paar eines Containers | | `virbr0` | Häufige libvirt-Bridge | | `tap...` | Virtuelle TAP-Schnittstelle | | `eth0` oder `ens...` | Physische oder virtuelle Host-Schnittstelle | **Schnittstellen anzeigen** ```text [RO] ip link show ``` ```text [RO] tcpdump -D ``` **Docker-Bridge untersuchen** ```text [TEST][PRIV][FILE][SENS] sudo tcpdump -i docker0 -nn -w docker-bridge.pcap ``` **Host-Schnittstelle und Container-IP filtern** ```text [TEST][PRIV][FILE][SENS] sudo tcpdump -i any -nn -w container-test.pcap 'host 192.0.2.10' ``` Ein Mitschnitt innerhalb eines Containers benötigt zusätzliche Berechtigungen wie Netzwerk-Capabilities und erweitert die Angriffsfläche. Wenn möglich, sollte deshalb auf dem autorisierten Container-Host oder an der Bridge aufgezeichnet werden. Bei Kubernetes, Overlay-Netzen, VXLAN und Service-Proxys kann die sichtbare Adresse je nach Aufzeichnungspunkt durch NAT oder Kapselung verändert sein.
--- **26. Wie sieht ein systematischer Diagnoseablauf mit tcpdump aus?**
Empfohlene Schrittfolge anzeigen **Vorbereitung** 1. Störung, Sollzustand und Fehlerzeitpunkt dokumentieren. 2. Client, Server, IP-Adressen, Ports und Protokolle ermitteln. 3. Den erwarteten Netzwerkpfad bestimmen. 4. Berechtigung für den Mitschnitt prüfen. 5. Systemzeit und Zeitzone kontrollieren. 6. Freien Speicherplatz prüfen. 7. Schutzbedarf der Mitschnittdatei festlegen. **Schnittstelle prüfen** 8. Verfügbare Schnittstellen mit `tcpdump -D` anzeigen. 9. Einen kurzen Kontrollmitschnitt ohne engen Filter durchführen. 10. Mit einem bekannten Test prüfen, ob die richtige Schnittstelle ausgewählt wurde. **Mitschnitt planen** 11. Einen möglichst gezielten Capture-Filter formulieren. 12. Filter mit einer kleinen Paketanzahl testen. 13. Paket-, Größen- oder Zeitbegrenzung festlegen. 14. Dateinamen, Zielverzeichnis und Berechtigungen prüfen. **Mitschnitt durchführen** 15. tcpdump starten. 16. Fehler genau einmal reproduzieren. 17. Start- und Endzeit notieren. 18. Mitschnitt kontrolliert beenden. 19. Capture-Zähler und Kernel-Drops prüfen. 20. Kontrollieren, ob tcpdump noch läuft. **Analyse** 21. Datei zunächst mit `tcpdump -nn -r` prüfen. 22. Dateieigenschaften mit `capinfos` kontrollieren. 23. Datei anschließend in Wireshark oder TShark öffnen. 24. Kommunikationsrichtung, TCP-Handshake, DNS, TLS und Anwendung untersuchen. 25. Zeitstempel mit System-, Firewall- und Anwendungslogs vergleichen. **Validierung** 26. Beobachtung und vermutete Ursache getrennt dokumentieren. 27. Hypothese durch einen gezielten Vergleichstest prüfen. 28. Falls erforderlich, an einem zweiten Punkt mitschneiden. 29. Nach einer Änderung denselben Test erneut durchführen. 30. Nicht mehr benötigte Mitschnittdateien gemäß Richtlinie löschen.
--- **27. Kurzreferenz – tcpdump-Befehle**
Befehlstabelle anzeigen | Aufgabe | Befehl | |---|---| | Version anzeigen | `[RO] tcpdump --version` | | Schnittstellen anzeigen | `[RO] tcpdump -D` | | 20 Pakete anzeigen | `[TEST][PRIV][SENS] sudo tcpdump -i eth0 -nn -c 20` | | 100 Pakete speichern | `[TEST][PRIV][FILE][SENS] sudo tcpdump -i eth0 -nn -c 100 -w capture.pcap` | | Alle regulären Schnittstellen | `[TEST][PRIV][SENS] sudo tcpdump -i any -nn` | | Datei lesen | `[RO][FILE][SENS] tcpdump -nn -r capture.pcap` | | Datei ausführlich lesen | `[RO][FILE][SENS] tcpdump -nn -tttt -vv -r capture.pcap` | | MAC-Adressen anzeigen | `[TEST][PRIV][SENS] sudo tcpdump -i eth0 -nn -e` | | Hex und ASCII anzeigen | `[TEST][PRIV][SENS] sudo tcpdump -i eth0 -nn -X -c 10` | | Host filtern | `[TEST][PRIV][SENS] sudo tcpdump -i eth0 -nn 'host 192.0.2.10'` | | HTTPS filtern | `[TEST][PRIV][SENS] sudo tcpdump -i eth0 -nn 'tcp port 443'` | | DNS filtern | `[TEST][PRIV][SENS] sudo tcpdump -i eth0 -nn 'port 53'` | | Initiale TCP-SYN-Pakete | `[TEST][PRIV][SENS] sudo tcpdump -i eth0 -nn 'tcp[tcpflags] & (tcp-syn\|tcp-ack) == tcp-syn'` | | TCP-RST-Pakete | `[TEST][PRIV][SENS] sudo tcpdump -i eth0 -nn 'tcp[tcpflags] & tcp-rst != 0'` | | Ringpuffer nach Größe | `[TEST][PRIV][FILE][SENS] sudo tcpdump -i eth0 -nn -C 100M -W 10 -w capture.pcap` | | Dateien alle fünf Minuten | `[TEST][PRIV][FILE][SENS] sudo tcpdump -i eth0 -nn -G 300 -w 'capture-%Y%m%d-%H%M%S.pcap'` | | Nach zwölf Zeitdateien stoppen | `[TEST][PRIV][FILE][SENS] sudo tcpdump -i eth0 -nn -G 300 -W 12 -w 'capture-%Y%m%d-%H%M%S.pcap'` | | Capture-Puffer setzen | `[TEST][PRIV][FILE][SENS] sudo tcpdump -i eth0 -nn -B 4096 -w capture.pcap` | | Datei sofort aktualisieren | `[TEST][PRIV][FILE][SENS] sudo tcpdump -i eth0 -nn -U -w capture.pcap` |
--- **28. Kurzreferenz – Capture-Filter**
Filtertabelle anzeigen | Aufgabe | Filter | |---|---| | IPv4 | `ip` | | IPv6 | `ip6` | | TCP | `tcp` | | UDP | `udp` | | ARP | `arp` | | ICMPv4 | `icmp` | | ICMPv6 | `icmp6` | | Host | `host 192.0.2.10` | | Quellhost | `src host 192.0.2.10` | | Zielhost | `dst host 192.0.2.10` | | IPv4-Netz | `net 192.0.2.0/24` | | Ethernet-Adresse | `ether host 00:11:22:33:44:55` | | TCP- oder UDP-Port | `port 53` | | TCP-Port | `tcp port 443` | | UDP-Port | `udp port 123` | | Zielport | `tcp dst port 443` | | Portbereich | `tcp portrange 8000-8100` | | DHCPv4 | `udp port 67 or udp port 68` | | DHCPv6 | `udp port 546 or udp port 547` | | HTTP oder HTTPS | `tcp port 80 or tcp port 443` | | Initiales TCP-SYN | `tcp[tcpflags] & (tcp-syn\|tcp-ack) == tcp-syn` | | TCP-RST | `tcp[tcpflags] & tcp-rst != 0` | | VLAN 100 | `vlan 100` | | Broadcast | `ether broadcast` | | Multicast | `ether multicast` | | Große Pakete | `greater 1500` | | SSH ausschließen | `not tcp port 22` | | Host und HTTPS | `host 192.0.2.10 and tcp port 443` | | Host und zwei Ports | `host 192.0.2.10 and (tcp port 80 or tcp port 443)` |
--- **Merksätze** - `tcpdump` verwendet Capture-Filter und keine Wireshark-Display-Filter. - Capture-Filter bestimmen, welche Pakete überhaupt verarbeitet und gespeichert werden. - Filterausdrücke sollten in einfache Anführungszeichen gesetzt werden. - `-nn` verhindert störende Namens- und Dienstauflösungen. - `-w` schreibt Rohpakete und keinen normalen Textbericht. - `-r` liest eine vorhandene Mitschnittdatei. - `-C` zusammen mit `-W` erzeugt einen größenbasierten Ringpuffer. - `-G` zusammen mit `-W` beendet tcpdump nach der festgelegten Anzahl Zeitdateien und ist kein Ringpuffer. - `packets dropped by kernel` weist auf einen möglicherweise unvollständigen Mitschnitt hin. - Scheinbar fehlerhafte Prüfsummen können durch Hardware-Offloading entstehen. - Ein fehlendes Paket ist nur aussagekräftig, wenn Schnittstelle, Aufzeichnungspunkt und Filter nachweislich richtig waren. - Paketmitschnitte sind sensible Diagnosedaten und müssen entsprechend geschützt werden. --- **Quellen** - [Offizielles tcpdump-Projekt](https://www.tcpdump.org/) - [Offizieller tcpdump-Quellcode und Dokumentation](https://github.com/the-tcpdump-group/tcpdump) - [Offizielle tcpdump-Manpage im Quellcode](https://github.com/the-tcpdump-group/tcpdump/blob/master/tcpdump.1.in) - [Offizielles libpcap-Projekt](https://github.com/the-tcpdump-group/libpcap) - [Offizielle pcap-filter-Manpage im libpcap-Quellcode](https://github.com/the-tcpdump-group/libpcap/blob/master/pcap-filter.manmisc.in) - [Wireshark User’s Guide – Capture Filters](https://www.wireshark.org/docs/wsug_html_chunked/ChCapCaptureFilterSection.html) - [Offizielle TShark-Dokumentation](https://www.wireshark.org/docs/man-pages/tshark.html) - [Offizielle Capinfos-Dokumentation](https://www.wireshark.org/docs/man-pages/capinfos.html) # 2.7 Nmap im autorisierten Netz – Hosts, Ports und Dienste untersuchen **Ziel dieser Seite** Nmap ist ein Werkzeug zur aktiven Netzwerkerkundung und Portanalyse. Administratoren können damit unter anderem prüfen: - welche Systeme in einem autorisierten Netz erreichbar sind; - welche TCP- und UDP-Ports antworten; - welche Dienste an diesen Ports angeboten werden; - welche Dienstversionen wahrscheinlich verwendet werden; - ob eine Firewall Pakete verwirft oder zurückweist; - ob ein Dienst nur lokal oder auch aus einem anderen Netzsegment erreichbar ist; - ob sich die Erreichbarkeit nach einer Änderung verbessert oder verschlechtert hat; - ob ein dokumentierter Sollzustand mit dem tatsächlich sichtbaren Zustand übereinstimmt. Nmap sendet aktiv Pakete oder Verbindungsversuche an Zielsysteme. Es ist daher kein rein passives Diagnosewerkzeug. > **Nmap darf ausschließlich gegen eigene Systeme oder mit eindeutiger Genehmigung des zuständigen Betreibers verwendet werden.** Vor einem Scan müssen Zielbereich, Zeitraum, Scanart, Quellsystem und zulässige Intensität festgelegt werden. --- **Kennzeichnungen** | Kennzeichnung | Bedeutung | |---|---| | `[RO]` | Lokale Abfrage ohne Netzwerkprüfung | | `[TEST]` | Aktiver Netzwerk- oder Diensttest | | `[PRIV]` | Erhöhte Berechtigungen können erforderlich sein | | `[FILE]` | Befehl erstellt oder verarbeitet Dateien | | `[SENS]` | Ausgabe kann sensible Infrastrukturinformationen enthalten | | `[DISRUPT]` | Test kann Dienste, Geräte oder Überwachungssysteme belasten | | `[CHANGE]` | Befehl verändert eine Einstellung oder Datei | --- **1. Wofür sollte Nmap in der Fehleranalyse verwendet werden?**
Geeignete und ungeeignete Einsatzbereiche anzeigen **Geeignete administrative Aufgaben** | Aufgabe | Beispiel | |---|---| | Einzelnen Dienst prüfen | Ist TCP-Port 443 vom Clientnetz erreichbar? | | Erreichbare Systeme erfassen | Welche freigegebenen Testsysteme antworten im VLAN? | | Firewalländerung kontrollieren | Ist der freigegebene Port nach der Regeländerung erreichbar? | | Dienstinventar vergleichen | Stimmen offene Ports mit der Dokumentation überein? | | Dienstidentifikation | Welcher Dienst antwortet tatsächlich auf einem Port? | | TCP und UDP unterscheiden | Antwortet nur TCP oder auch UDP? | | Erreichbarkeit aus verschiedenen Segmenten vergleichen | Ist der Dienst intern erreichbar, aus dem Gastnetz aber gefiltert? | | Fehlerzustand dokumentieren | Welche Ergebnisse waren vor und nach einer Änderung sichtbar? | **Nmap ist nicht geeignet für** - Scans fremder öffentlicher Systeme ohne Erlaubnis; - unkontrollierte Scans kompletter Unternehmensnetze; - das Umgehen von Firewalls oder Überwachungssystemen; - Verschleierungs-, Spoofing- oder Tarntechniken im normalen Administrationsbetrieb; - Brute-Force-, Exploit- oder Denial-of-Service-Tests; - den Nachweis, dass ein Dienst fachlich korrekt funktioniert; - die alleinige Entscheidung, ob ein System sicher ist. Ein offener Port beweist nur, dass aus Sicht des Scanstandorts eine entsprechende Antwort empfangen wurde. Er beweist nicht, dass: - die Anwendung vollständig funktioniert; - die Anwendung korrekt konfiguriert ist; - eine Benutzeranmeldung möglich ist; - der Dienst keine Sicherheitslücken besitzt; - alle Clients denselben Netzwerkpfad verwenden.
--- **2. Wie wird Nmap auf Windows, Linux und macOS geprüft?**
Installations- und Versionsprüfung anzeigen | Aufgabe | Windows | Linux | macOS | |---|---|---|---| | Programmpfad suchen | `[RO] Get-Command nmap` | `[RO] command -v nmap` | `[RO] command -v nmap` | | Version anzeigen | `[RO] nmap --version` | `[RO] nmap --version` | `[RO] nmap --version` | | Hilfe anzeigen | `[RO] nmap -h` | `[RO] nmap -h` | `[RO] nmap -h` | | Lokale Handbuchseite | Nicht standardmäßig vorhanden | `[RO] man nmap` | `[RO] man nmap` | **Windows** Die offizielle Windows-Installation von Nmap verwendet normalerweise Npcap für Raw-Packet-Funktionen. Für bestimmte Scanarten sollte PowerShell oder die Eingabeaufforderung als Administrator gestartet werden. **Linux und macOS** Scanarten, die Raw-IP-Pakete verwenden, benötigen normalerweise erhöhte Rechte: ```text [TEST][PRIV][SENS] sudo nmap -sS -p 443 192.0.2.10 ``` Ein TCP-Connect-Scan kann gewöhnlich ohne erhöhte Rechte ausgeführt werden: ```text [TEST][SENS] nmap -sT -p 443 192.0.2.10 ``` Die tatsächlich verfügbaren Funktionen hängen von Betriebssystem, Nmap-Version, Rechten und Paket-Capture-Treiber ab.
--- **3. Welche Freigaben müssen vor einem Scan vorliegen?**
Autorisierungscheckliste anzeigen Vor einem Scan sollten mindestens folgende Punkte dokumentiert sein: | Punkt | Beispiel | |---|---| | Auftraggeber | Zuständige IT-Abteilung | | Zielsystem | `192.0.2.10` | | Zielnetz | `192.0.2.0/28` | | Erlaubte Ports | TCP 22, 80 und 443 | | Erlaubte Scanarten | Host Discovery, TCP Connect, Versionserkennung | | Scanquelle | Administrationssystem `192.0.2.50` | | Zeitraum | `14:00–14:15 Uhr` | | Verantwortliche Kontaktperson | Max Mustermann | | Abbruchkriterium | Dienstfehler, hohe Last oder Alarmmeldung | | Protokollierung | Ausgabe als normale, XML- und grepbare Datei | | Erwarteter Sollzustand | TCP 443 offen, TCP 22 gefiltert | **Vor dem Start klären** - Befinden sich empfindliche Altgeräte im Zielbereich? - Sind Drucker, Telefonanlagen, Kameras, Steuerungen oder medizinische Geräte betroffen? - Gibt es Intrusion-Detection- oder Intrusion-Prevention-Systeme? - Muss das Security Operations Center informiert werden? - Gibt es eine maximale Scanrate? - Darf eine Dienst- oder Betriebssystemerkennung durchgeführt werden? - Dürfen NSE-Skripte verwendet werden? - Wie lange dürfen Ergebnisse gespeichert werden? > Die Erlaubnis, einen einzelnen Server zu prüfen, ist keine Erlaubnis zum Scan des gesamten Subnetzes.
--- **4. Wie werden Zielsysteme sicher angegeben?**
Zielspezifikation anzeigen | Zielart | Beispiel | |---|---| | Einzelne IPv4-Adresse | `192.0.2.10` | | Mehrere einzelne Ziele | `192.0.2.10 192.0.2.20` | | DNS-Name | `server.example.com` | | CIDR-Netz | `192.0.2.0/28` | | IPv4-Adressbereich | `192.0.2.10-20` | | IPv6-Adresse | `2001:db8::10` | | Ziele aus einer Datei | `-iL targets.txt` | | Bestimmtes Ziel ausschließen | `--exclude 192.0.2.15` | | Ausschlussliste verwenden | `--excludefile excluded.txt` | **Einzelnes Ziel** ```text [TEST][SENS] nmap 192.0.2.10 ``` **Kleines, ausdrücklich freigegebenes Netz** ```text [TEST][SENS] nmap 192.0.2.0/28 ``` **IPv6-Ziel** ```text [TEST][SENS] nmap -6 2001:db8::10 ``` **Ziele aus einer autorisiert erstellten Datei** ```text [TEST][FILE][SENS] nmap -iL targets.txt ``` **Zielbereich nur auflösen und auflisten, ohne Zielpakete zu senden** ```text [RO][SENS] nmap -sL 192.0.2.0/28 ``` `-sL` führt einen List Scan durch. Dabei werden die Ziele aufgelistet und standardmäßig gegebenenfalls Reverse-DNS-Abfragen durchgeführt. Es findet kein normaler Host- oder Portscan gegen die Zielsysteme statt. **Ohne DNS-Auflösung auflisten** ```text [RO][SENS] nmap -sL -n 192.0.2.0/28 ``` Das Auflisten des Zielbereichs vor dem aktiven Scan hilft, fehlerhafte CIDR-Angaben frühzeitig zu erkennen.
--- **5. Wie wird geprüft, welche Hosts erreichbar sind?**
Host Discovery anzeigen **Nur Host-Erkennung, ohne Portscan** ```text [TEST][SENS] nmap -sn 192.0.2.0/28 ``` `-sn` deaktiviert den anschließenden Portscan. Nmap führt aber weiterhin aktive Host-Erkennungsprüfungen durch. **Ohne Namensauflösung** ```text [TEST][SENS] nmap -sn -n 192.0.2.0/28 ``` **Grund für die Bewertung anzeigen** ```text [TEST][SENS] nmap -sn --reason 192.0.2.0/28 ``` **Lokales Ethernet-Netz** Im lokalen Ethernet-Netz verwendet Nmap für die Host-Erkennung normalerweise ARP beziehungsweise bei IPv6 Neighbor Discovery. Das ist häufig zuverlässiger als ein einfacher ICMP-Echo-Test. **Gezielte ICMP-Echo-Erkennung** ```text [TEST][PRIV][SENS] sudo nmap -sn -PE 192.0.2.0/28 ``` **TCP-SYN-Erkennung auf freigegebenen Ports** ```text [TEST][PRIV][SENS] sudo nmap -sn -PS22,80,443 192.0.2.0/28 ``` **TCP-ACK-Erkennung** ```text [TEST][PRIV][SENS] sudo nmap -sn -PA80,443 192.0.2.0/28 ``` **UDP-Erkennung auf einem gezielt freigegebenen Port** ```text [TEST][PRIV][SENS] sudo nmap -sn -PU53 192.0.2.0/28 ``` **Wichtige Interpretation** | Ergebnis | Aussage | |---|---| | `Host is up` | Nmap hat eine als Erreichbarkeitsnachweis bewertete Antwort erhalten | | Kein Hosteintrag | Keine ausreichende Antwort empfangen | | ICMP antwortet nicht | Host kann trotzdem über TCP oder UDP erreichbar sein | | ARP-Antwort im lokalen Netz | Gerät ist auf Layer 2 erreichbar | | Hohe Latenz | Kann durch Netzwerk, Zielsystem oder Scanverfahren entstehen | Ein fehlender Hosttreffer beweist nicht, dass das System ausgeschaltet ist. Firewalls können die für die Erkennung verwendeten Pakete verwerfen.
--- **6. Was bedeutet `-Pn`, und wann sollte es verwendet werden?**
Portscan ohne vorherige Host-Erkennung anzeigen Mit `-Pn` behandelt Nmap die angegebenen Ziele als erreichbar und überspringt die normale Host-Erkennung. ```text [TEST][SENS] nmap -Pn -p 443 192.0.2.10 ``` **Sinnvoller Einsatz** - der Host ist nachweislich aktiv; - ICMP und andere Discovery-Pakete werden gefiltert; - ein bestimmter Port soll unabhängig von der Host-Erkennung geprüft werden; - nur ein einzelnes oder sehr kleines freigegebenes Ziel wird untersucht. **Auswirkung** Ohne erfolgreiche Host-Erkennung würde Nmap möglicherweise melden: ```text Host seems down. ``` Mit `-Pn` wird der Portscan trotzdem durchgeführt. **Risiko bei großen Zielbereichen** ```text nmap -Pn 192.0.2.0/16 ``` Dieser Scan würde jedes Ziel im Bereich als aktiv behandeln und entsprechend prüfen. Das kann sehr lange dauern und erhebliche Netzlast oder Sicherheitsmeldungen verursachen. > `-Pn` sollte nicht pauschal für große Netze verwendet werden. Es eignet sich hauptsächlich für bekannte, ausdrücklich freigegebene Einzelziele oder kleine Zielgruppen.
--- **7. Welche Portzustände zeigt Nmap an?**
Portzustände und Bedeutung anzeigen | Zustand | Bedeutung | |---|---| | `open` | Eine Anwendung nimmt an diesem Port Verbindungen oder Pakete an | | `closed` | Ziel ist erreichbar, aber an diesem Port antwortet kein Dienst | | `filtered` | Nmap kann wegen eines Filters oder Netzwerkhindernisses nicht bestimmen, ob der Port offen oder geschlossen ist | | `unfiltered` | Port ist erreichbar, der verwendete Scan kann aber nicht zwischen offen und geschlossen unterscheiden | | `open\|filtered` | Nmap kann nicht zwischen offen und gefiltert unterscheiden | | `closed\|filtered` | Nmap kann nicht zwischen geschlossen und gefiltert unterscheiden | **Wichtig** `filtered` bedeutet nicht automatisch: ```text Eine Firewall auf dem Zielsystem blockiert den Port. ``` Mögliche Ursachen sind unter anderem: - Host-Firewall; - Netzwerk-Firewall; - Access Control List; - Routerfilter; - Security Group; - Paketverlust; - asymmetrisches Routing; - IPS oder Rate Limiting; - falscher Rückweg; - unvollständige Scanantwort. Mit `--reason` zeigt Nmap an, auf welcher Antwort oder Nichtantwort die Bewertung beruht: ```text [TEST][SENS] nmap --reason -p 22,80,443 192.0.2.10 ```
--- **8. Welche Ports scannt Nmap standardmäßig?**
Portauswahl anzeigen Ohne ausdrückliche Portangabe untersucht Nmap standardmäßig die 1.000 häufigsten Ports des jeweiligen gescannten Protokolls. Es handelt sich nicht automatisch um alle 65.535 TCP-Ports. **Bestimmte Ports** ```text [TEST][SENS] nmap -p 22,80,443 192.0.2.10 ``` **Portbereich** ```text [TEST][SENS] nmap -p 8000-8100 192.0.2.10 ``` **Alle TCP-Ports** ```text [TEST][SENS] nmap -p- 192.0.2.10 ``` `-p-` steht für die Ports 1 bis 65.535. Ein vollständiger Portscan ist wesentlich umfangreicher als ein Standardscan und muss ausdrücklich freigegeben sein. **Die häufigsten 100 Ports** ```text [TEST][SENS] nmap --top-ports 100 192.0.2.10 ``` **Schneller Scan der häufigsten Ports** ```text [TEST][SENS] nmap -F 192.0.2.10 ``` `-F` reduziert die Anzahl der normalerweise untersuchten Ports. Die genaue Portauswahl hängt von der lokalen Nmap-Dienstdatenbank ab. **Nur offene Ports anzeigen** ```text [TEST][SENS] nmap --open -p 22,80,443,445,3389 192.0.2.10 ``` `--open` verkürzt die Ausgabe. Für die Fehleranalyse können geschlossene und gefilterte Ports jedoch wichtige Informationen liefern. Die vollständige Ausgabe sollte deshalb häufig bevorzugt werden.
--- **9. Was ist ein TCP-Connect-Scan?**
TCP-Connect-Scan `-sT` anzeigen Der TCP-Connect-Scan verwendet die normale `connect()`-Funktion des Betriebssystems. Er kann gewöhnlich ohne Raw-Packet-Rechte ausgeführt werden. ```text [TEST][SENS] nmap -sT -p 22,80,443 192.0.2.10 ``` **Eigenschaften** | Eigenschaft | TCP Connect | |---|---| | Option | `-sT` | | Erhöhte Rechte | Normalerweise nicht erforderlich | | Verbindung | Vollständiger TCP-Verbindungsaufbau zu offenen Ports | | Protokollierung am Ziel | Wahrscheinlich | | Eignung | Funktionale Erreichbarkeitsprüfung einzelner TCP-Ports | | Belastung | Bei wenigen Ports normalerweise gering, aber aktiv | **Einzelnen HTTPS-Port prüfen** ```text [TEST][SENS] nmap -sT -Pn -p 443 --reason 192.0.2.10 ``` Da bei offenen Ports eine vollständige Verbindung aufgebaut wird, kann der Zielserver den Versuch in seinen Logs erfassen. Für einen gezielten administrativen Funktionstest ist das nicht grundsätzlich nachteilig: Der Scan soll nachvollziehbar und autorisiert sein.
--- **10. Was ist ein TCP-SYN-Scan?**
TCP-SYN-Scan `-sS` anzeigen Beim SYN-Scan sendet Nmap ein TCP-SYN-Paket, ohne bei einem offenen Port eine vollständige Anwendungssitzung aufzubauen. ```text [TEST][PRIV][SENS] sudo nmap -sS -p 22,80,443 192.0.2.10 ``` **Typische Antworten** | Antwort | Nmap-Bewertung | |---|---| | SYN/ACK | `open` | | RST | `closed` | | Keine Antwort nach Wiederholungen | `filtered` | | Bestimmte ICMP-Unreachable-Antwort | `filtered` | **Eigenschaften** | Eigenschaft | TCP SYN | |---|---| | Option | `-sS` | | Erhöhte Rechte | Auf Unix-Systemen normalerweise erforderlich | | Vollständige TCP-Verbindung | Nein | | Unterscheidung | `open`, `closed`, `filtered` | | Eignung | Kontrollierte Portprüfung im autorisierten Netz | Der Ausdruck „halb offen“ bedeutet nicht, dass der Scan unsichtbar ist. Firewalls, IDS, IPS und Zielsysteme können SYN-Scans erkennen und protokollieren.
--- **11. Wie werden UDP-Dienste geprüft?**
UDP-Scan `-sU` anzeigen UDP ist verbindungslos. Ein fehlendes Antwortpaket lässt deshalb häufig keine eindeutige Entscheidung zu. **Gezielter UDP-Scan** ```text [TEST][PRIV][SENS] sudo nmap -sU -p 53,123,161 192.0.2.10 ``` **Mit Begründung und Versionserkennung** ```text [TEST][PRIV][SENS] sudo nmap -sU -sV --reason -p 53,123,161 192.0.2.10 ``` **Typische Ergebnisse** | Antwort | Mögliche Bewertung | |---|---| | Gültige UDP-Antwort | `open` | | ICMP Port Unreachable | `closed` | | Bestimmte andere ICMP-Fehler | `filtered` | | Keine Antwort | `open\|filtered` | **Warum UDP-Scans länger dauern** - viele offene UDP-Dienste antworten nur auf gültige Protokollanfragen; - gefilterte Pakete erzeugen häufig keine Antwort; - ICMP-Fehlermeldungen können begrenzt werden; - Nmap muss Zeitüberschreitungen und Wiederholungen abwarten. **Nur die tatsächlich benötigten Ports prüfen** ```text [TEST][PRIV][SENS] sudo nmap -sU -p 53 192.0.2.10 ``` Ein ungeplanter Scan aller 65.535 UDP-Ports kann sehr lange dauern und unnötige Last verursachen.
--- **12. Wie werden TCP und UDP gemeinsam untersucht?**
Kombinierten Scan anzeigen TCP-SYN- und UDP-Scan können kombiniert werden: ```text [TEST][PRIV][SENS] sudo nmap -sS -sU -p T:53,80,443,U:53,123 192.0.2.10 ``` **Bedeutung** | Ausdruck | Geprüfte Ports | |---|---| | `T:53,80,443` | TCP 53, 80 und 443 | | `U:53,123` | UDP 53 und 123 | Ohne die Präfixe `T:` und `U:` kann die Portzuordnung bei einem kombinierten Scan missverständlich werden. **DNS über TCP und UDP prüfen** ```text [TEST][PRIV][SENS] sudo nmap -sS -sU -p T:53,U:53 192.0.2.10 ``` Ein offener TCP- und UDP-Port bestätigt noch nicht, dass DNS-Anfragen korrekt beantwortet werden. Danach sollte ein protokollspezifischer Test folgen, beispielsweise mit `dig`, `Resolve-DnsName` oder `nslookup`.
--- **13. Wie werden Dienste und Versionen erkannt?**
Service- und Versionserkennung `-sV` anzeigen Die Versionserkennung sendet zusätzliche, teilweise protokollspezifische Anfragen an offene oder wahrscheinlich offene Ports. ```text [TEST][SENS] nmap -sV -p 22,80,443 192.0.2.10 ``` **Leichtere Versionserkennung** ```text [TEST][SENS] nmap -sV --version-light -p 22,80,443 192.0.2.10 ``` **Intensität festlegen** ```text [TEST][SENS] nmap -sV --version-intensity 2 -p 22,80,443 192.0.2.10 ``` Der Wertebereich für `--version-intensity` reicht von `0` bis `9`: | Intensität | Verhalten | |---|---| | `0` | Nur wenige, besonders wahrscheinliche Prüfungen | | `2` | Reduzierte, häufig ausreichende Prüfung | | `7` | Standardintensität | | `9` | Alle verfügbaren Versionserkennungs-Probes | **Interpretation** ```text 443/tcp open https nginx 1.24.0 ``` Dabei sind zu unterscheiden: | Feld | Aussage | |---|---| | `443/tcp` | Untersuchte Port-/Protokollkombination | | `open` | Nmap erhielt eine Antwort für einen offenen Port | | `https` | Erkannter oder anhand der Portzuordnung vermuteter Dienst | | `nginx 1.24.0` | Von Nmap ermittelte oder geschätzte Produktversion | Versionsergebnisse können unvollständig oder irreführend sein, beispielsweise durch: - Reverse Proxies; - Load Balancer; - TLS-Termination; - absichtlich veränderte Banner; - Backports von Sicherheitskorrekturen; - herstellerspezifische Builds; - Protokollweiterleitungen; - IDS- oder IPS-Antworten. > Ein Nmap-Versionshinweis sollte mit der lokalen Paketverwaltung, der Anwendungskonfiguration oder der Herstelleroberfläche bestätigt werden.
--- **14. Wie wird eine Betriebssystemerkennung durchgeführt?**
OS-Erkennung `-O` anzeigen Nmap versucht anhand verschiedener Netzwerkmerkmale, das Betriebssystem des Zielsystems zu bestimmen. ```text [TEST][PRIV][SENS] sudo nmap -O 192.0.2.10 ``` **Nur gezielte Ports und OS-Erkennung** ```text [TEST][PRIV][SENS] sudo nmap -O -p 22,80,443 192.0.2.10 ``` **Erkennungsversuche begrenzen** ```text [TEST][PRIV][SENS] sudo nmap -O --osscan-limit 192.0.2.0/28 ``` `--osscan-limit` beschränkt die OS-Erkennung auf Ziele, bei denen Nmap dafür geeignete Bedingungen erkennt. **Voraussetzungen für gute Ergebnisse** Nmap erzielt bessere Resultate, wenn mindestens: - ein offener TCP-Port; - ein geschlossener TCP-Port; - ausreichende Antworten des Zielsystems vorhanden sind. **Mögliche Ungenauigkeiten** - Firewall verändert Antworten; - NAT oder Proxy liegt zwischen Quelle und Ziel; - mehrere Systeme teilen eine IP-Adresse; - Netzwerkgerät beantwortet Pakete stellvertretend; - zu wenige geeignete Ports antworten; - Betriebssystem-Fingerprint ist nicht eindeutig. Die Ausgabe ist eine Netzwerkerkennung beziehungsweise Schätzung und kein sicherer Beweis für das installierte Betriebssystem.
--- **15. Welche einfachen NSE-Skripte können für die Diagnose verwendet werden?**
Nmap Scripting Engine sicher einordnen Die Nmap Scripting Engine, kurz NSE, erweitert Nmap um Skripte. Diese können von einfachen Informationsabfragen bis zu Sicherheits- und Belastungstests reichen. **Standard-Skripte** ```text [TEST][DISRUPT][SENS] nmap -sC -p 22,80,443 192.0.2.10 ``` `-sC` entspricht: ```text --script=default ``` Auch Standardskripte senden zusätzliche Anfragen an Dienste und sollten nur nach Freigabe verwendet werden. **Bestimmtes, zuvor geprüftes Skript** ```text [TEST][SENS] nmap --script http-title -p 80,443 192.0.2.10 ``` **Skriptbeschreibung anzeigen** ```text [RO] nmap --script-help http-title ``` **Mehrere freigegebene Informationsskripte** ```text [TEST][SENS] nmap --script http-title,http-headers -p 80,443 192.0.2.10 ``` Vor einem NSE-Einsatz müssen geprüft werden: - Skriptname; - Skriptbeschreibung; - Kategorie; - benötigte Argumente; - mögliche Auswirkungen; - Zielport; - Umfang der Autorisierung. **Im normalen Troubleshooting nicht pauschal verwenden** ```text --script vuln --script exploit --script brute --script dos --script intrusive ``` Diese Kategorien können Schwachstellenprüfungen, Anmeldeversuche oder belastende Tests enthalten. Sie gehören nicht in eine gewöhnliche Netzwerkdiagnose ohne gesonderten Auftrag. > Auch die Kategorie `safe` ist keine absolute Garantie für Wirkungslosigkeit. Das konkrete Skript muss vor dem Einsatz geprüft werden.
--- **16. Warum sollte `-A` nicht unüberlegt verwendet werden?**
Aggressive Erkennung erklären Die Option `-A` aktiviert mehrere Funktionen gleichzeitig: - Betriebssystemerkennung; - Versionserkennung; - Standardskript-Scan; - Traceroute. ```text [TEST][PRIV][DISRUPT][SENS] sudo nmap -A 192.0.2.10 ``` Für eine gezielte Fehleranalyse ist dieser Befehl häufig zu breit. Er sendet mehr unterschiedliche Prüfungen als ein einfacher Portscan und erzeugt umfangreichere Logs und mögliche Sicherheitsmeldungen. Besser ist eine schrittweise Auswahl: ```text [TEST][SENS] nmap -sT -p 443 192.0.2.10 ``` Danach bei Bedarf: ```text [TEST][SENS] nmap -sV --version-light -p 443 192.0.2.10 ``` Und nur bei begründetem Bedarf: ```text [TEST][PRIV][SENS] sudo nmap -O -p 22,80,443 192.0.2.10 ``` Dadurch bleibt erkennbar, welche Scanoption welche Reaktion verursacht hat.
--- **17. Wie wird die Namensauflösung kontrolliert?**
DNS-Optionen anzeigen **Keine DNS-Auflösung durchführen** ```text [TEST][SENS] nmap -n -p 22,80,443 192.0.2.10 ``` **DNS-Auflösung für alle Ziele erzwingen** ```text [TEST][SENS] nmap -R -p 22,80,443 192.0.2.10 ``` **Bedeutung** | Option | Wirkung | |---|---| | `-n` | Keine Reverse-DNS-Auflösung | | `-R` | Reverse-DNS-Auflösung für alle Ziele | | Keine Option | Nmap entscheidet abhängig vom Scanergebnis | Für reproduzierbare Portprüfungen ist `-n` häufig sinnvoll: - Scan wird nicht durch DNS verzögert; - keine zusätzlichen DNS-Abfragen; - Ergebnisse zeigen die tatsächlichen IP-Adressen; - DNS- und Portprobleme werden getrennt untersucht. Wenn die DNS-Zuordnung selbst Teil der Diagnose ist, sollte sie bewusst separat geprüft werden.
--- **18. Wie wird die Scanrate kontrolliert?**
Timing und Belastungsbegrenzung anzeigen Nmap bietet Timing-Vorlagen: | Vorlage | Name | Einordnung | |---|---|---| | `-T0` | Paranoid | Extrem langsam | | `-T1` | Sneaky | Sehr langsam | | `-T2` | Polite | Reduzierte Geschwindigkeit | | `-T3` | Normal | Standard | | `-T4` | Aggressive | Schneller, nur in stabilen und freigegebenen Netzen | | `-T5` | Insane | Sehr aggressiv; für normales Troubleshooting ungeeignet | **Normale Geschwindigkeit** ```text [TEST][SENS] nmap -T3 -p 22,80,443 192.0.2.10 ``` **Rücksichtsvollere Prüfung** ```text [TEST][SENS] nmap -T2 -p 22,80,443 192.0.2.10 ``` **Maximale Paketrate begrenzen** ```text [TEST][SENS] nmap --max-rate 50 -p 1-1000 192.0.2.10 ``` `--max-rate 50` fordert Nmap auf, im Durchschnitt nicht schneller als 50 Pakete pro Sekunde zu senden. Abhängig von Scanart und Betriebssystem können trotzdem kurzfristige Abweichungen auftreten. **Host-Zeitüberschreitung** ```text [TEST][SENS] nmap --host-timeout 2m -p 22,80,443 192.0.2.10 ``` Wenn ein Ziel nach zwei Minuten nicht vollständig geprüft wurde, beendet Nmap die weitere Bearbeitung dieses Hosts. **Für empfindliche Systeme** - nur einzelne Ziele; - nur benötigte Ports; - `-T2` oder `-T3`; - niedrige `--max-rate`; - keine umfassende Versionserkennung; - keine pauschalen NSE-Skripte; - System- und Dienstüberwachung parallel beobachten.
--- **19. Wie werden Ergebnisse gespeichert?**
Ausgabeformate anzeigen | Option | Format | Verwendung | |---|---|---| | `-oN DATEI` | Normale Textausgabe | Menschliche Auswertung | | `-oX DATEI` | XML | Automatisierte Verarbeitung | | `-oG DATEI` | Grepbares Format | Älteres zeilenorientiertes Format | | `-oA BASISNAME` | Alle drei Formate | Vollständige Dokumentation | **Normale Ausgabe speichern** ```text [TEST][FILE][SENS] nmap -sT -p 22,80,443 -oN server-scan.txt 192.0.2.10 ``` **XML-Ausgabe** ```text [TEST][FILE][SENS] nmap -sT -p 22,80,443 -oX server-scan.xml 192.0.2.10 ``` **Alle Hauptformate** ```text [TEST][FILE][SENS] nmap -sT -p 22,80,443 -oA server-scan 192.0.2.10 ``` Dabei entstehen typischerweise: ```text server-scan.nmap server-scan.xml server-scan.gnmap ``` **Zusätzlich Terminalausgabe mit `tee` speichern** Linux und macOS: ```text [TEST][FILE][SENS] nmap -sT -p 22,80,443 192.0.2.10 | tee server-scan.txt ``` PowerShell: ```powershell [TEST][FILE][SENS] nmap -sT -p 22,80,443 192.0.2.10 | Tee-Object -FilePath server-scan.txt ``` `tee` beziehungsweise `Tee-Object` speichert nur die sichtbare Textausgabe. Für strukturierte Verarbeitung sollte `-oX` oder `-oA` verwendet werden.
--- **20. Wie werden Ergebnisse vor und nach einer Änderung verglichen?**
Vergleichsdiagnose anzeigen **Vor der Änderung** ```text [TEST][FILE][SENS] nmap -n -sT -p 22,80,443 --reason -oA server-before 192.0.2.10 ``` **Nach der Änderung** ```text [TEST][FILE][SENS] nmap -n -sT -p 22,80,443 --reason -oA server-after 192.0.2.10 ``` Linux und macOS: ```text [RO][FILE][SENS] diff -u server-before.nmap server-after.nmap ``` PowerShell: ```powershell [RO][FILE][SENS] Compare-Object (Get-Content .\server-before.nmap) (Get-Content .\server-after.nmap) ``` Für einen aussagekräftigen Vergleich müssen identisch sein: - Scanquelle; - Zieladresse; - Scanart; - Portliste; - Nmap-Version; - Berechtigungsstufe; - DNS-Einstellung; - Timing-Einstellung; - Netzwerkpfad. Andernfalls können Unterschiede durch die Testmethode statt durch die eigentliche Änderung entstehen.
--- **21. Wie wird ein bestimmter Dienst systematisch geprüft?**
Diagnosefolge für einen einzelnen Dienst anzeigen Beispiel: HTTPS auf TCP-Port 443. **1. Namensauflösung getrennt prüfen** Windows: ```powershell [RO] Resolve-DnsName server.example.com ``` Linux oder macOS: ```text [RO] dig server.example.com ``` **2. Host Discovery durchführen** ```text [TEST][SENS] nmap -sn --reason 192.0.2.10 ``` **3. Port unabhängig von Host Discovery prüfen** ```text [TEST][SENS] nmap -Pn -n -sT -p 443 --reason 192.0.2.10 ``` **4. Dienst vorsichtig identifizieren** ```text [TEST][SENS] nmap -Pn -n -sV --version-light -p 443 192.0.2.10 ``` **5. Anwendungsebene prüfen** ```text [TEST][SENS] curl -vkI https://192.0.2.10/ ``` Bei namensabhängigen virtuellen Hosts sollte der korrekte DNS-Name verwendet werden: ```text [TEST][SENS] curl -vI https://server.example.com/ ``` **6. TLS gesondert prüfen** ```text [TEST][SENS] openssl s_client -connect 192.0.2.10:443 -servername server.example.com ``` **Interpretation** | Ergebnis | Nächster Schritt | |---|---| | Port `closed` | Dienststatus und lokale Listener prüfen | | Port `filtered` | Firewall, ACL, Routing und Paketmitschnitt prüfen | | Port `open`, curl fehlschlägt | HTTP-, TLS-, Proxy- oder Anwendungsproblem untersuchen | | Port `open`, TLS falsch | Zertifikat, SNI, TLS-Version und Zeit prüfen | | Nmap erkennt falschen Dienst | Direkten Protokolltest durchführen | | Unterschiedliche Ergebnisse aus zwei Netzen | Firewall- und Routingpfad vergleichen | Nmap beantwortet hauptsächlich die Frage: ```text Wie reagiert dieser Port aus Sicht dieses Scanstandorts? ``` Für die vollständige Fehlerursache sind weitere Werkzeuge erforderlich.
--- **22. Wie wird ein Firewallproblem eingegrenzt?**
Vergleich zwischen Netzsegmenten anzeigen Ein Scan sollte von genau den Standorten erfolgen, deren Erreichbarkeit untersucht wird. ```text Clientnetz A → Firewall → Servernetz Clientnetz B → Firewall → Servernetz ``` **Scan aus Netz A** ```text [TEST][FILE][SENS] nmap -Pn -n -sT -p 443 --reason -oN netz-a.txt 192.0.2.10 ``` **Scan aus Netz B** ```text [TEST][FILE][SENS] nmap -Pn -n -sT -p 443 --reason -oN netz-b.txt 192.0.2.10 ``` **Mögliche Beobachtung** | Netz A | Netz B | Mögliche Schlussfolgerung | |---|---|---| | `open` | `filtered` | Unterschiedliche Firewall-, ACL- oder Routingbehandlung | | `open` | `closed` | Möglicherweise anderes Ziel, NAT oder unterschiedliche Antwortquelle | | `filtered` | `filtered` | Gemeinsamer Filter, fehlender Rückweg oder Ziel nicht erreichbar | | `open` | `open` | Grundlegende Portfreigabe aus beiden Netzen vorhanden | Zusätzlich sollten geprüft werden: - Quell-IP des Scanhosts; - Ziel-IP nach NAT; - Firewall-Logs; - Routingtabellen; - Security Groups; - lokale Host-Firewall; - Paketmitschnitt auf Client, Firewall oder Server; - Rückweg zum jeweiligen Clientnetz. Ein Nmap-Ergebnis allein zeigt nicht, an welchem Gerät ein Paket verworfen wurde.
--- **23. Welche Scanarten sollten im normalen Troubleshooting vermieden werden?**
Nicht empfohlene Optionen anzeigen Folgende Funktionen gehören normalerweise nicht zur alltäglichen Fehleranalyse: | Scanart oder Option | Grund | |---|---| | Idle Scan `-sI` | Verwendet ein fremdes System als sogenanntes Zombie-System | | FTP Bounce `-b` | Missbraucht einen FTP-Server als Relay | | Eigene TCP-Flags `--scanflags` | Kann Filter- und IDS-Umgehung dienen | | Decoys `-D` | Verschleiert die tatsächliche Scanquelle | | Quelladress-Spoofing `-S` | Erschwert Rückverfolgung und kann Netzstörungen verursachen | | Fragmentierung `-f` | Wird häufig zur Filterumgehung eingesetzt | | `--badsum` | Erzeugt absichtlich ungültige Prüfsummen | | NSE-Kategorie `brute` | Führt Anmeldeversuche durch | | NSE-Kategorie `exploit` | Versucht Sicherheitslücken auszunutzen | | NSE-Kategorie `dos` | Kann Dienste beeinträchtigen | | NSE-Kategorie `intrusive` | Kann Systeme oder Anwendungen belasten | | Ungeprüftes `-A` gegen viele Systeme | Kombiniert mehrere aktive Erkennungsverfahren | | `-T5` | Sehr aggressive Zeitsteuerung | Solche Funktionen werden in diesem Troubleshooting-Buch nicht als Standardbefehle empfohlen. Für einen gesonderten Sicherheitstest sind ein eigener Auftrag, eine genaue Risikoanalyse und abgestimmte Abbruchkriterien erforderlich.
--- **24. Welche typischen Fehlinterpretationen gibt es?**
Fehlertabelle anzeigen | Fehlinterpretation | Korrekte Einordnung | |---|---| | `Host seems down` bedeutet ausgeschaltet | Discovery-Pakete können gefiltert worden sein | | `open` bedeutet Anwendung funktioniert | Nur der Port reagiert; Anwendungstest folgt | | `closed` bedeutet Firewall blockiert | Das Ziel antwortet normalerweise aktiv mit „kein Listener“ | | `filtered` bedeutet lokale Host-Firewall | Filter kann an jeder Stelle des Pfads liegen | | `open\|filtered` bedeutet offen | Nmap kann offen und gefiltert nicht unterscheiden | | Dienstname in der Porttabelle ist sicher erkannt | Ohne `-sV` kann er nur aus der Portzuordnung stammen | | Angezeigte Version ist garantiert installiert | Banner, Proxy oder Backport können abweichen | | OS-Erkennung ist ein sicherer Beweis | Es handelt sich um eine Fingerprint-Schätzung | | Kein Ergebnis bei UDP bedeutet geschlossen | Häufig lautet der Zustand `open\|filtered` | | `-Pn` macht den Scan passiv | Portscan bleibt aktiv; nur Host Discovery wird übersprungen | | SYN-Scan ist unsichtbar | IDS, IPS, Firewalls und Systeme können ihn erkennen | | Ein Scan aus dem Servernetz gilt auch für das Clientnetz | Unterschiedliche Netzwerkpfade können andere Ergebnisse liefern | | Nmap ist ein vollständiger Schwachstellenscanner | Nmap ist primär ein Netzwerk- und Portscanner | | Viele Optionen liefern automatisch bessere Ergebnisse | Mehr Prüfungen erhöhen Last, Logs und Fehlinterpretationsrisiko |
--- **25. Wie werden Nmap-Ergebnisse verifiziert?**
Gegenprüfungen anzeigen | Nmap-Beobachtung | Geeignete Gegenprüfung | |---|---| | TCP-Port offen | `Test-NetConnection`, `nc`, `curl` oder anwendungsspezifischer Client | | TCP-Port geschlossen | Lokale Listener mit `Get-NetTCPConnection`, `ss` oder `lsof` prüfen | | Port gefiltert | Firewall-Logs, Routing und Paketmitschnitt prüfen | | DNS-Dienst offen | `Resolve-DnsName`, `dig` oder `nslookup` | | HTTP/HTTPS offen | `curl` | | TLS erkannt | `openssl s_client` | | SSH offen | Autorisierten SSH-Verbindungsaufbau durchführen | | SMB offen | SMB-Client und Serverlogs prüfen | | Dienstversion erkannt | Lokale Paket- oder Anwendungsversion prüfen | | Betriebssystem erkannt | Lokale Systeminformationen oder Inventarsystem prüfen | | Host nicht erkannt | ARP/Neighbor-Tabelle, Ping, TCP-Test und Switchinformationen prüfen | **Lokale Listener prüfen** | Betriebssystem | Befehl | |---|---| | Windows | `[RO] Get-NetTCPConnection -State Listen` | | Linux | `[RO] ss -lntup` | | macOS | `[RO] sudo lsof -nP -iTCP -sTCP:LISTEN` | Ein Port kann lokal lauschen und trotzdem aus dem untersuchten Netzsegment nicht erreichbar sein. Umgekehrt kann NAT oder Portweiterleitung einen extern erreichbaren Port zeigen, obwohl auf der Zieladresse selbst kein entsprechender lokaler Listener sichtbar ist.
--- **26. Wie sieht ein sicherer Nmap-Diagnoseablauf aus?**
Empfohlene Schrittfolge anzeigen **Vorbereitung** 1. Auftrag und Ziel der Prüfung dokumentieren. 2. Zulässige Zieladressen und Ports festlegen. 3. Scanquelle und Netzwerksegment dokumentieren. 4. Empfindliche Systeme identifizieren. 5. Erlaubte Scanarten und maximale Rate festlegen. 6. Ansprechpartner und Abbruchkriterium festlegen. 7. Systemzeit und Speicherort der Ergebnisse prüfen. **Zielkontrolle** 8. Zielbereich zuerst mit `-sL -n` auflisten. 9. CIDR-Präfix und Ausschlüsse kontrollieren. 10. Mit einem einzelnen Testsystem beginnen. **Schrittweise Prüfung** 11. Host Discovery mit `-sn` durchführen. 12. Falls erforderlich einen bekannten Port mit `-Pn` prüfen. 13. Nur benötigte Ports mit `-p` angeben. 14. Zunächst TCP Connect oder SYN Scan verwenden. 15. UDP nur für konkret benötigte Ports prüfen. 16. `--reason` zur Interpretation hinzufügen. 17. Versionserkennung nur bei Bedarf verwenden. 18. NSE-Skripte einzeln prüfen und freigeben. 19. Scanrate und Zielsystemüberwachung beobachten. **Dokumentation** 20. Ausgabe mit `-oA` speichern. 21. Nmap-Version und verwendeten Befehl dokumentieren. 22. Beginn, Ende und Scanquelle festhalten. 23. Ergebnisse als Beobachtung und nicht sofort als Ursache dokumentieren. **Validierung** 24. Offene Ports mit einem Protokollwerkzeug prüfen. 25. Gefilterte Ports mit Firewall-Logs und Paketmitschnitten untersuchen. 26. Lokale Listener auf dem Zielsystem prüfen. 27. Nach einer Änderung denselben Scan erneut ausführen. 28. Ergebnisse vergleichen. 29. Zuständige Personen über Abschluss oder Auffälligkeiten informieren. 30. Scanresultate gemäß Schutz- und Löschrichtlinie behandeln.
--- **27. Kurzreferenz – sichere Basisbefehle**
Nmap-Befehlstabelle anzeigen | Aufgabe | Befehl | |---|---| | Version anzeigen | `[RO] nmap --version` | | Hilfe anzeigen | `[RO] nmap -h` | | Zielbereich nur auflisten | `[RO][SENS] nmap -sL -n 192.0.2.0/28` | | Hosts erkennen | `[TEST][SENS] nmap -sn -n 192.0.2.0/28` | | Grund anzeigen | `[TEST][SENS] nmap -sn -n --reason 192.0.2.0/28` | | Einzelnen TCP-Port prüfen | `[TEST][SENS] nmap -Pn -n -sT -p 443 --reason 192.0.2.10` | | Mehrere TCP-Ports | `[TEST][SENS] nmap -sT -p 22,80,443 192.0.2.10` | | SYN-Scan | `[TEST][PRIV][SENS] sudo nmap -sS -p 22,80,443 192.0.2.10` | | UDP-Ports | `[TEST][PRIV][SENS] sudo nmap -sU -p 53,123,161 192.0.2.10` | | TCP und UDP | `[TEST][PRIV][SENS] sudo nmap -sS -sU -p T:53,80,443,U:53,123 192.0.2.10` | | Häufigste 100 Ports | `[TEST][SENS] nmap --top-ports 100 192.0.2.10` | | Alle TCP-Ports | `[TEST][SENS] nmap -p- 192.0.2.10` | | Nur offene Ports ausgeben | `[TEST][SENS] nmap --open -p 22,80,443 192.0.2.10` | | Dienstversionen vorsichtig prüfen | `[TEST][SENS] nmap -sV --version-light -p 22,80,443 192.0.2.10` | | Betriebssystem schätzen | `[TEST][PRIV][SENS] sudo nmap -O 192.0.2.10` | | IPv6-Ziel | `[TEST][SENS] nmap -6 -p 22,80,443 2001:db8::10` | | Scanrate begrenzen | `[TEST][SENS] nmap --max-rate 50 -p 1-1000 192.0.2.10` | | Ergebnisse vollständig speichern | `[TEST][FILE][SENS] nmap -sT -p 22,80,443 -oA server-scan 192.0.2.10` | | Skriptbeschreibung anzeigen | `[RO] nmap --script-help http-title` | | HTTP-Titel prüfen | `[TEST][SENS] nmap --script http-title -p 80,443 192.0.2.10` |
--- **28. Kurzreferenz – wichtigste Optionen**
Optionstabelle anzeigen | Option | Bedeutung | |---|---| | `-sL` | Ziele nur auflisten | | `-sn` | Nur Host Discovery, kein Portscan | | `-Pn` | Host Discovery überspringen | | `-n` | Keine DNS-Auflösung | | `-R` | Reverse-DNS-Auflösung erzwingen | | `-sT` | TCP Connect Scan | | `-sS` | TCP SYN Scan | | `-sU` | UDP Scan | | `-p` | Ports angeben | | `-p-` | Alle Ports von 1 bis 65.535 | | `-F` | Schneller Scan mit reduzierter Portauswahl | | `--top-ports N` | N häufigste Ports prüfen | | `--open` | Nur offene oder möglicherweise offene Ports anzeigen | | `--reason` | Grund für Host- und Portbewertung anzeigen | | `-sV` | Dienst- und Versionserkennung | | `--version-light` | Reduzierte Versionserkennung | | `-O` | Betriebssystemerkennung | | `-6` | IPv6 verwenden | | `-iL` | Ziele aus Datei lesen | | `--exclude` | Ziel ausschließen | | `--excludefile` | Ausschlüsse aus Datei lesen | | `-T2` | Rücksichtsvolle Timing-Vorlage | | `-T3` | Normale Timing-Vorlage | | `--max-rate` | Maximale durchschnittliche Paketrate begrenzen | | `--host-timeout` | Zeitlimit pro Host | | `-oN` | Normale Ausgabe speichern | | `-oX` | XML-Ausgabe speichern | | `-oG` | Grepbare Ausgabe speichern | | `-oA` | Alle Hauptformate speichern | | `-sC` | Standard-NSE-Skripte ausführen | | `--script` | Bestimmte NSE-Skripte auswählen | | `--script-help` | Beschreibung eines Skripts anzeigen |
--- **Merksätze** - Nmap ist ein aktives Diagnosewerkzeug und benötigt eine eindeutige Autorisierung. - Zuerst den Zielbereich prüfen, dann mit einem einzelnen Ziel und wenigen Ports beginnen. - `-sn` führt Host Discovery ohne anschließenden Portscan durch. - `-Pn` macht einen Scan nicht passiv, sondern überspringt nur die Host-Erkennung. - `-sT` verwendet vollständige TCP-Verbindungen und benötigt normalerweise keine Raw-Packet-Rechte. - `-sS` verwendet Raw-Pakete und benötigt auf Unix-Systemen normalerweise erhöhte Rechte. - `filtered` bedeutet, dass Nmap den Portzustand wegen fehlender oder filternder Antworten nicht bestimmen kann. - UDP-Ergebnisse sind häufig weniger eindeutig als TCP-Ergebnisse. - Ein Dienstname ohne Versionserkennung kann lediglich aus der bekannten Portzuordnung stammen. - Versions- und Betriebssystemergebnisse sind Hinweise und müssen lokal bestätigt werden. - `-A`, NSE-Skripte und aggressive Timing-Optionen dürfen nicht unüberlegt eingesetzt werden. - Ein offener Port bestätigt noch keine funktionierende Anwendung. - Ergebnisse müssen aus dem tatsächlich betroffenen Netzwerksegment erhoben werden. - Nmap-Ergebnisse sollten mit Protokolltests, lokalen Listenern, Logs und Paketmitschnitten verifiziert werden. --- **Quellen** - [Offizielle Nmap-Referenz](https://nmap.org/book/man.html) - [Nmap – Target Specification](https://nmap.org/book/man-target-specification.html) - [Nmap – Host Discovery](https://nmap.org/book/man-host-discovery.html) - [Nmap – Port Scanning Basics](https://nmap.org/book/man-port-scanning-basics.html) - [Nmap – Port Scanning Techniques](https://nmap.org/book/man-port-scanning-techniques.html) - [Nmap – Port Specification and Scan Order](https://nmap.org/book/man-port-specification.html) - [Nmap – Service and Version Detection](https://nmap.org/book/man-version-detection.html) - [Nmap – OS Detection](https://nmap.org/book/man-os-detection.html) - [Nmap – Nmap Scripting Engine](https://nmap.org/book/man-nse.html) - [Nmap – Timing and Performance](https://nmap.org/book/man-performance.html) - [Nmap – Output](https://nmap.org/book/man-output.html) - [Nmap – Legal Notices and Inappropriate Usage](https://nmap.org/book/man-legal.html) - [Offizielle Npcap-Dokumentation](https://npcap.com/guide/) # 2.8 iPerf3 – Bandbreite, Durchsatz, Jitter und Paketverlust messen **Ziel dieser Seite** iPerf3 erzeugt kontrollierten Netzwerkverkehr zwischen zwei Systemen und misst dabei die erreichbare Übertragungsleistung. Es hilft unter anderem bei der Untersuchung von: - zu geringem TCP-Durchsatz; - langsamen LAN-, WLAN-, VPN- oder WAN-Verbindungen; - unterschiedlichen Übertragungsraten je Richtung; - UDP-Paketverlust; - UDP-Jitter; - Performanceproblemen zwischen VLANs oder Standorten; - möglichen Engpässen an Netzwerkadaptern, Firewalls oder VPN-Gateways; - Auswirkungen von Parallelverbindungen; - Unterschieden zwischen Anwendungs- und Netzwerkleistung. iPerf3 besteht aus einem Server und einem Client: ```text iPerf3-Client → Netzwerkpfad → iPerf3-Server ``` Standardmäßig sendet der Client TCP-Testdaten an den Server. Mit `-R` wird die Richtung umgekehrt. > **Wichtig:** iPerf3 erzeugt aktiv Datenverkehr und kann eine Netzwerkverbindung vollständig auslasten. Tests dürfen nur zwischen autorisierten Systemen und mit abgestimmter Testdauer und Datenrate durchgeführt werden. --- **Kennzeichnungen** | Kennzeichnung | Bedeutung | |---|---| | `[RO]` | Lokale Abfrage ohne Netzwerktest | | `[TEST]` | Aktiver Netzwerk- oder Leistungstest | | `[PRIV]` | Erhöhte Berechtigungen können erforderlich sein | | `[FILE]` | Befehl erstellt oder verarbeitet eine Datei | | `[SENS]` | Ausgabe kann sensible Infrastrukturinformationen enthalten | | `[CHANGE]` | Befehl verändert eine Einstellung oder Datei | | `[DISRUPT]` | Test kann Netzwerk, Endgeräte oder andere Verbindungen belasten | --- **1. Was misst iPerf3 – und was misst es nicht?**
Messumfang anzeigen | Messwert | TCP | UDP | |---|---:|---:| | Übertragene Datenmenge | Ja | Ja | | Durchschnittlicher Durchsatz | Ja | Ja | | Durchsatz je Messintervall | Ja | Ja | | TCP-Wiederholungsübertragungen | Systemabhängig, häufig auf Senderseite | Nein | | TCP Congestion Window | Systemabhängig | Nein | | UDP-Jitter | Nein | Ja | | UDP-Paketverlust | Nein | Ja | | Verlorene Datagramme | Nein | Ja | | Empfangene Datagramme | Nein | Ja | | Reihenfolgefehler | Teilweise über UDP-Zähler erkennbar | Ja | iPerf3 misst den Durchsatz zwischen den beiden iPerf3-Prozessen. Das Ergebnis ist nicht automatisch identisch mit: - der Leitungsgeschwindigkeit des Netzwerkadapters; - der Brutto-Datenrate eines WLANs; - der Geschwindigkeit eines Internetanschlusses; - der Geschwindigkeit einer Dateiübertragung; - der Leistung einer Webanwendung; - der Festplattenleistung; - der nutzbaren Geschwindigkeit für jeden einzelnen Benutzer. **iPerf3 umgeht normalerweise folgende Anwendungsfaktoren** - Dateisystem; - Festplattenzugriffe; - SMB- oder NFS-Protokollverarbeitung; - HTTP-Anwendung; - Datenbankabfragen; - Verschlüsselung einer konkreten Anwendung; - Benutzeranmeldung; - Virenscan einer übertragenen Datei. Dadurch kann iPerf3 helfen, Netzwerkpfad und Anwendung voneinander zu trennen: ```text iPerf3 schnell + Anwendung langsam → Ursache wahrscheinlich nicht ausschließlich der reine Netzwerkdurchsatz iPerf3 langsam + Anwendung langsam → Netzwerkpfad oder beteiligte Systeme weiter untersuchen ```
--- **2. Auf welchen Betriebssystemen wird iPerf3 offiziell unterstützt?**
Betriebssystemübersicht anzeigen | Betriebssystem | Offizielle ESnet-Unterstützung | Hinweis | |---|---|---| | Linux | Ja | Vollständiger Haupteinsatzbereich | | FreeBSD | Ja | Offiziell unterstützt | | macOS | Ja | In der ESnet-Dokumentation als OSX bezeichnet | | Windows | Nein | ESnet empfiehlt für Windows iPerf2 | | Andere Systeme | Nicht generell zugesichert | Funktionsumfang kann abweichen | Nach der offiziellen ESnet-FAQ wird iPerf3 nicht offiziell unter Windows unterstützt. Es existieren Community-Builds für Windows, bei denen jedoch nicht alle Optionen funktionieren müssen. **Konsequenz für dieses Buch** - Linux, FreeBSD und macOS: iPerf3 nach offizieller ESnet-Dokumentation; - Windows mit Community-iPerf3: Version, Quelle und Funktionsumfang ausdrücklich dokumentieren; - Windows mit offiziell unterstützter Alternative: iPerf2 verwenden; - iPerf2 und iPerf3 nicht als untereinander kompatibel behandeln. > Ein iPerf3-Client benötigt einen iPerf3-Server. Ein iPerf2-Client benötigt einen iPerf2-Server.
--- **3. Wie wird die installierte Version geprüft?**
Versions- und Hilfebefehle anzeigen | Aufgabe | Windows mit Community-Build | Linux | macOS | |---|---|---|---| | Programmpfad | `[RO] Get-Command iperf3` | `[RO] command -v iperf3` | `[RO] command -v iperf3` | | Version | `[RO] iperf3 --version` | `[RO] iperf3 --version` | `[RO] iperf3 --version` | | Kurzform der Version | `[RO] iperf3 -v` | `[RO] iperf3 -v` | `[RO] iperf3 -v` | | Hilfe | `[RO] iperf3 -h` | `[RO] iperf3 -h` | `[RO] iperf3 -h` | | Handbuch | Nicht standardmäßig | `[RO] man iperf3` | `[RO] man iperf3` | Die Version muss auf Client und Server dokumentiert werden: ```text Client: iPerf 3.x Server: iPerf 3.x ``` Unterschiedliche iPerf3-Versionen funktionieren häufig miteinander, können aber: - unterschiedliche Optionen unterstützen; - Ergebnisse unterschiedlich darstellen; - andere Standardwerte verwenden; - Fehlerkorrekturen enthalten; - bei neueren Funktionen inkompatibel sein. Seit iPerf3 3.16 verwendet jeder parallele Teststream einen eigenen Thread. Ältere Versionen waren für den Testdatenverkehr grundsätzlich auf einen Thread begrenzt. Bei hohen Datenraten kann die verwendete Version deshalb das Ergebnis wesentlich beeinflussen.
--- **4. Welche Freigaben müssen vor einem Leistungstest vorliegen?**
Testplanung anzeigen | Punkt | Beispiel | |---|---| | Client | `192.0.2.10` | | Server | `192.0.2.20` | | Port | TCP/UDP 5201 | | Testprotokoll | TCP und anschließend UDP | | Testdauer | 30 Sekunden je Richtung | | Maximale UDP-Rate | 100 Mbit/s | | Parallelstreams | Zunächst 1, anschließend 4 | | Netzwerkpfad | Client-VLAN → Firewall → Server-VLAN | | Testzeitraum | Wartungsfenster | | Verantwortliche Person | Max Mustermann | | Abbruchkriterium | Hohe Last, Paketverlust anderer Anwendungen oder Alarmmeldung | Vorher prüfen: - Darf die Verbindung ausgelastet werden? - Gibt es produktive Sprach-, Video- oder Echtzeitanwendungen? - Befindet sich der Testpfad hinter einer volumenbasierten Internetabrechnung? - Gibt es QoS- oder Rate-Limit-Regeln? - Muss eine Firewallfreigabe zeitlich begrenzt eingerichtet werden? - Sind Client und Server leistungsfähig genug? - Gibt es WLAN-Teilnehmer, die durch den Test beeinträchtigt werden? - Wird der Test über VPN, Mobilfunk oder einen geteilten WAN-Link durchgeführt? - Sind Monitoring und zuständige Administratoren informiert? > Ein unbegrenzter TCP-Test versucht, so viel Bandbreite wie möglich zu verwenden. Auch ein zehn Sekunden langer Standardtest kann deshalb andere Verbindungen beeinflussen.
--- **5. Welche Netzwerkverbindungen benötigt iPerf3?**
Ports und Verbindungsaufbau anzeigen Der iPerf3-Server lauscht standardmäßig auf Port `5201`. **TCP-Test** ```text Client → Server: TCP 5201 ``` **UDP-Test** ```text Client → Server: TCP 5201 für Steuerung Client → Server: UDP 5201 für Testdaten ``` Auch bei einem UDP-Test verwendet iPerf3 eine TCP-Steuerverbindung. Daher muss neben UDP 5201 auch TCP 5201 erreichbar sein. **Benutzerdefinierter Port** Server: ```text [TEST][DISRUPT] iperf3 -s -p 5002 ``` Client: ```text [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -p 5002 ``` Für einen UDP-Test auf Port 5002 müssen gegebenenfalls beide Protokolle freigegeben sein: ```text TCP 5002 UDP 5002 ``` **Port vor dem Test prüfen** Windows: ```powershell [TEST] Test-NetConnection 192.0.2.20 -Port 5201 ``` Linux: ```text [TEST] nc -vz 192.0.2.20 5201 ``` macOS: ```text [TEST] nc -vz 192.0.2.20 5201 ``` Ein erfolgreicher TCP-Porttest bestätigt nur die Steuerverbindung. Er bestätigt noch nicht, dass ein UDP-Testdatenstrom funktioniert.
--- **6. Wie wird ein iPerf3-Server gestartet?**
Serverbefehle anzeigen **Server auf dem Standardport 5201 starten** ```text [TEST][DISRUPT] iperf3 -s ``` **Server auf einem anderen Port** ```text [TEST][DISRUPT] iperf3 -s -p 5002 ``` **Server an eine bestimmte lokale IP-Adresse binden** ```text [TEST][DISRUPT] iperf3 -s -B 192.0.2.20 ``` **Server nur für einen Test starten und danach beenden** ```text [TEST][DISRUPT] iperf3 -s -1 ``` `-1` beziehungsweise `--one-off` bedeutet: - höchstens eine Clientverbindung bearbeiten; - danach den Serverprozess beenden. Das ist für kontrollierte Einzeltests häufig sicherer als ein dauerhaft laufender Server. **Einmaliger Server auf bestimmter Adresse und bestimmtem Port** ```text [TEST][DISRUPT] iperf3 -s -1 -B 192.0.2.20 -p 5201 ``` **Ausführliche Ausgabe** ```text [TEST][DISRUPT] iperf3 -s -V ``` **Serverausgabe in eine Datei schreiben** ```text [TEST][FILE][SENS][DISRUPT] iperf3 -s --logfile iperf3-server.log --forceflush ``` `--forceflush` schreibt die Intervallergebnisse zeitnah in die Logdatei, statt sie länger zu puffern.
--- **7. Wie wird der laufende Server kontrolliert?**
Listener und Prozess prüfen **Linux: Listener prüfen** ```text [RO] ss -lntp | grep ':5201' ``` **macOS: Listener prüfen** ```text [RO][PRIV] sudo lsof -nP -iTCP:5201 -sTCP:LISTEN ``` **Windows mit Community-Build** ```powershell [RO] Get-NetTCPConnection -LocalPort 5201 -State Listen ``` **Prozess suchen** Linux: ```text [RO] pgrep -a iperf3 ``` macOS: ```text [RO] pgrep -fl iperf3 ``` Windows: ```powershell [RO] Get-Process iperf3 -ErrorAction SilentlyContinue ``` Nach dem Test sollte ein nicht mehr benötigter iPerf3-Server beendet werden. Bei Verwendung von `-1` beendet er sich nach der Clientverbindung automatisch.
--- **8. Wie wird ein grundlegender TCP-Test durchgeführt?**
Standardtest anzeigen **Auf dem Server** ```text [TEST][DISRUPT] iperf3 -s -1 ``` **Auf dem Client** ```text [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 ``` Standardmäßig: - verwendet iPerf3 TCP; - sendet der Client zum Server; - dauert der Test zehn Sekunden; - wird jede Sekunde ein Zwischenergebnis ausgegeben; - wird Port 5201 verwendet. **Test für 30 Sekunden** ```text [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -t 30 ``` **Ausgabe alle fünf Sekunden** ```text [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -t 30 -i 5 ``` **Einheit Mbit/s erzwingen** ```text [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -t 30 -f m ``` **Serverausgabe zusätzlich am Client abrufen** ```text [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -t 30 --get-server-output ``` Die Serverausgabe wird nur abgerufen, wenn der Test vollständig abgeschlossen wird. Bei einem abgebrochenen Test kann sie fehlen.
--- **9. Welche Richtung wird mit iPerf3 gemessen?**
Normal-, Reverse- und Bidirektionstest anzeigen **Standardrichtung** ```text Client → Server ``` ```text [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -t 30 ``` Dabei sendet der Client die Testdaten. **Umgekehrte Richtung** ```text Server → Client ``` ```text [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -t 30 -R ``` `-R` wird auf dem Client angegeben, obwohl anschließend der Server die Testdaten sendet. **Beide Richtungen gleichzeitig** ```text Client ↔ Server ``` ```text [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -t 30 --bidir ``` `--bidir` testet beide Richtungen gleichzeitig. Das erzeugt mehr Last als zwei getrennte Einzeltests und erschwert die Interpretation. **Empfohlene Reihenfolge** 1. Client zum Server testen. 2. Server zum Client mit `-R` testen. 3. Ergebnisse vergleichen. 4. Erst bei begründetem Bedarf `--bidir` verwenden. **Mögliche Ursachen für unterschiedliche Richtungen** - asymmetrisches Routing; - unterschiedliche QoS-Regeln; - Firewall- oder VPN-Verarbeitung; - WLAN-Uplink und WLAN-Downlink; - Sender- oder Empfänger-CPU; - Netzwerkkartentreiber; - TCP-Offloading; - unterschiedliche Upload- und Downloadkapazität; - unterschiedliche Paketverlustrate.
--- **10. Wie wird ein UDP-Test sicher durchgeführt?**
UDP-Test mit kontrollierter Datenrate anzeigen **Wichtiger Unterschied** Bei TCP passt das Protokoll die Senderate unter anderem anhand von Bestätigungen, Verlust und Überlastung an. Bei UDP muss eine gewünschte Senderate festgelegt werden. Die iPerf3-Standardrate für UDP beträgt laut aktueller Dokumentation `1 Mbit/s`. **UDP-Test mit 10 Mbit/s** ```text [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -u -b 10M -t 30 ``` **UDP-Test mit 100 Mbit/s** ```text [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -u -b 100M -t 30 ``` **Umgekehrter UDP-Test** ```text [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -u -b 100M -t 30 -R ``` **UDP-Test ohne iPerf3-interne Bitratenbegrenzung** ```text [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -u -b 0 -t 30 ``` `-b 0` deaktiviert die interne Begrenzung. Dadurch kann der Test sehr viel Verkehr erzeugen und erheblichen Paketverlust verursachen. > `-b 0` sollte in produktiven Netzen nicht als erster Test verwendet werden. **Sichere Steigerung** ```text 10 Mbit/s → 25 Mbit/s → 50 Mbit/s → 100 Mbit/s ``` Nach jeder Stufe werden geprüft: - Paketverlust; - Jitter; - Netzwerkauslastung; - CPU-Auslastung; - Auswirkungen auf andere Anwendungen.
--- **11. Wie werden UDP-Jitter und Paketverlust interpretiert?**
UDP-Messwerte anzeigen Eine UDP-Zusammenfassung kann sinngemäß enthalten: ```text 0.00-30.00 sec 350 MBytes 97.9 Mbits/sec 0.250 ms 1250/250000 (0.5%) ``` | Wert | Bedeutung | |---|---| | `350 MBytes` | Übertragene beziehungsweise empfangene Datenmenge | | `97.9 Mbits/sec` | Gemessene durchschnittliche Datenrate | | `0.250 ms` | Berechneter Jitter | | `1250/250000` | Verlorene Datagramme im Verhältnis zur erwarteten Gesamtzahl | | `0.5%` | Berechnete Verlustquote | **Jitter** Jitter beschreibt bei iPerf3 die Schwankung der Paketlaufzeit, nicht die absolute Latenz. Daher gilt: ```text Niedriger Jitter ≠ automatisch niedrige Latenz ``` Für die absolute Laufzeit werden zusätzlich beispielsweise benötigt: - `ping`; - `fping`; - `pathping`; - Monitoringdaten; - anwendungsspezifische Messungen. **Paketverlust** ```text Verlustquote = verlorene Datagramme / erwartete Datagramme × 100 ``` Ein Paketverlust unter hoher UDP-Last bedeutet nicht automatisch einen Defekt. Er kann auch entstehen, weil: - die eingestellte Senderate höher als die verfügbare Bandbreite ist; - ein QoS-Policer die Rate begrenzt; - Empfangs- oder Sendepuffer überlaufen; - Client oder Server CPU-limitiert ist; - WLAN-Kollisionen oder Funkstörungen auftreten; - die Firewall den Datenstrom nicht schnell genug verarbeitet. Der Test sollte deshalb mit mehreren kontrollierten Datenraten wiederholt werden.
--- **12. Wie wird die maximale UDP-Kapazität schrittweise angenähert?**
Stufentest anzeigen Beispiel für einen freigegebenen 100-Mbit/s-Pfad: **Stufe 1** ```text [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -u -b 10M -t 30 ``` **Stufe 2** ```text [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -u -b 25M -t 30 ``` **Stufe 3** ```text [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -u -b 50M -t 30 ``` **Stufe 4** ```text [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -u -b 90M -t 30 ``` **Dokumentation** | Zielrate | Empfangsrate | Paketverlust | Jitter | Bewertung | |---:|---:|---:|---:|---| | 10 Mbit/s | 10 Mbit/s | 0 % | 0,2 ms | Unauffällig | | 25 Mbit/s | 25 Mbit/s | 0 % | 0,3 ms | Unauffällig | | 50 Mbit/s | 49,8 Mbit/s | 0,1 % | 0,5 ms | Beobachten | | 90 Mbit/s | 72 Mbit/s | 18 % | 5,2 ms | Kapazitätsgrenze überschritten | Die Werte in dieser Tabelle sind lediglich ein Rechen- und Dokumentationsbeispiel und keine allgemein gültigen Grenzwerte. Die sinnvoll nutzbare Rate liegt unterhalb des Punktes, an dem Verlust und Jitter deutlich ansteigen.
--- **13. Wie werden parallele TCP-Streams verwendet?**
Parallelverbindungen `-P` anzeigen **Vier parallele TCP-Streams** ```text [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -P 4 -t 30 ``` **Acht parallele Streams** ```text [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -P 8 -t 30 ``` **Umgekehrte Richtung mit vier Streams** ```text [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -P 4 -t 30 -R ``` Seit iPerf3 3.16 verwendet jeder Teststream einen eigenen Thread. Dadurch können mehrere Streams mehrere CPU-Kerne nutzen. **Warum mehrere Streams mehr Durchsatz erreichen können** - einzelne TCP-Verbindung ist durch Latenz und Empfangsfenster begrenzt; - einzelne CPU oder ein einzelner Stream erreicht seine Grenze; - Paketverlust reduziert das Congestion Window einer einzelnen Verbindung; - Lastverteilung behandelt mehrere Flows unterschiedlich; - mehrere Warteschlangen einer Netzwerkkarte werden verwendet. **Wichtige Interpretation** ```text 1 Stream langsam 4 Streams schnell ``` bedeutet nicht automatisch, dass die Verbindung fehlerfrei ist. Eine einzelne Anwendung verwendet möglicherweise nur eine TCP-Verbindung und erreicht dann weiterhin den niedrigeren Wert. **Empfohlener Vergleich** | Test | Zweck | |---|---| | `-P 1` | Leistung einer einzelnen TCP-Verbindung | | `-P 4` | Verhalten mehrerer paralleler Verbindungen | | `-P 8` | Prüfung auf CPU-, Queue- oder Window-Limit | | `-R` | Vergleich der Gegenrichtung |
--- **14. Wie werden Testdauer, Datenmenge und Warmlaufphase festgelegt?**
Zeit- und Mengenoptionen anzeigen **Testdauer** ```text [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -t 60 ``` `-t 60` testet 60 Sekunden. **Bestimmte Datenmenge übertragen** ```text [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -n 1G ``` **Bestimmte Anzahl Blöcke übertragen** ```text [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -k 10000 ``` Die Optionen `-t`, `-n` und `-k` schließen sich gegenseitig aus. Pro Test darf nur eine davon zur Begrenzung verwendet werden. **Erste fünf Sekunden nicht in die Statistik aufnehmen** ```text [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -t 30 -O 5 ``` `-O 5` führt zunächst fünf Sekunden Warmlauf durch und lässt diese Messwerte aus der abschließenden Teststatistik heraus. Das hilft, den Einfluss des TCP Slow Start auf die Zusammenfassung zu reduzieren. **Sinnvoller stabiler TCP-Test** ```text [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -t 30 -O 5 -i 5 ``` Die gesamte Verbindung besteht dabei aus Warmlaufphase und ausgewerteter Testphase. Die genaue Laufzeit ist daher länger als der reine Auswertungszeitraum.
--- **15. Wie wird eine bestimmte lokale IP-Adresse verwendet?**
Quelladresse und Schnittstellenbindung anzeigen Ein System kann mehrere Netzwerkschnittstellen und IP-Adressen besitzen: - Ethernet; - WLAN; - VPN; - Managementnetz; - Produktionsnetz; - IPv4 und IPv6. **Client an eine lokale IP-Adresse binden** ```text [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -B 192.0.2.10 ``` **Server an eine lokale IP-Adresse binden** ```text [TEST][DISRUPT] iperf3 -s -B 192.0.2.20 ``` **Linux: an ein Interface binden, sofern unterstützt** ```text [TEST][PRIV][DISRUPT][SENS] sudo iperf3 -c 192.0.2.20 --bind-dev eth0 ``` `--bind-dev` ist nicht auf allen Plattformen verfügbar und kann erhöhte Rechte erfordern. **Vorher prüfen** Windows: ```powershell [RO] Get-NetIPConfiguration ``` Linux: ```text [RO] ip address show ``` macOS: ```text [RO] ifconfig ``` Die Quelladresse beeinflusst: - Routing; - Firewallregeln; - VPN-Auswahl; - QoS; - NAT; - Rückweg; - Aussagekraft des Messergebnisses.
--- **16. Wie werden IPv4 und IPv6 getrennt getestet?**
IPv4- und IPv6-Befehle anzeigen **IPv4 erzwingen** ```text [TEST][DISRUPT][SENS] iperf3 -4 -c 192.0.2.20 ``` **IPv6 erzwingen** ```text [TEST][DISRUPT][SENS] iperf3 -6 -c 2001:db8::20 ``` **IPv6-Reversetest** ```text [TEST][DISRUPT][SENS] iperf3 -6 -c 2001:db8::20 -R ``` **IPv6-Link-Local-Adresse** Bei einer Link-Local-Adresse muss die Schnittstelle beziehungsweise Zone angegeben werden: ```text [TEST][DISRUPT][SENS] iperf3 -6 -c fe80::20%en0 ``` Der genaue Schnittstellenname ist betriebssystemspezifisch. **Vergleich** | Test | Ergebnis | |---|---| | IPv4 schnell, IPv6 langsam | IPv6-Routing, MTU, Firewall oder Tunnel prüfen | | IPv4 funktioniert, IPv6 nicht | IPv6-Adresse, Route, Neighbor Discovery und Firewall prüfen | | IPv6 funktioniert, IPv4 nicht | IPv4-Routing, NAT oder Firewall prüfen | | Beide langsam | Gemeinsamen Netzwerkpfad und Endgeräte untersuchen |
--- **17. Wie werden Ergebnisse als JSON gespeichert?**
JSON- und Logausgabe anzeigen **JSON im Terminal ausgeben** ```text [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -J ``` **Linux und macOS: JSON in Datei schreiben** ```text [TEST][FILE][DISRUPT][SENS] iperf3 -c 192.0.2.20 -J > iperf3-result.json ``` **PowerShell mit Community-iPerf3** ```powershell [TEST][FILE][DISRUPT][SENS] iperf3 -c 192.0.2.20 -J | Out-File -Encoding utf8 iperf3-result.json ``` **Direkte Logdatei** ```text [TEST][FILE][DISRUPT][SENS] iperf3 -c 192.0.2.20 --logfile iperf3-result.log ``` **Zeitstempel hinzufügen** ```text [TEST][FILE][DISRUPT][SENS] iperf3 -c 192.0.2.20 --timestamps --logfile iperf3-result.log ``` **Zeilenweise JSON-Objekte während des Tests** ```text [TEST][FILE][DISRUPT][SENS] iperf3 -c 192.0.2.20 --json-stream > iperf3-stream.jsonl ``` `--json-stream` ist eine neuere Funktion. Vor Verwendung muss geprüft werden, ob die installierte Version sie unterstützt. **Für eine vollständige Dokumentation festhalten** - Client-IP; - Server-IP; - Netzwerkpfad; - iPerf3-Versionen; - Befehl; - Datum und Uhrzeit; - Testdauer; - Protokoll; - Richtung; - Anzahl paralleler Streams; - TCP- oder UDP-Rate; - CPU-Auslastung; - Interface-Zähler; - Ergebnisdatei.
--- **18. Wie werden TCP-Ergebnisse interpretiert?**
TCP-Ausgabe erklären Eine TCP-Ausgabe enthält am Ende typischerweise eine Sender- und eine Empfängerzeile: ```text [SUM] 0.00-30.00 sec 3.20 GBytes 916 Mbits/sec sender [SUM] 0.00-30.00 sec 3.19 GBytes 913 Mbits/sec receiver ``` | Feld | Bedeutung | |---|---| | Intervall | Ausgewerteter Zeitraum | | Transfer | Übertragene Datenmenge | | Bitrate | Durchschnittliche Übertragungsrate | | Sender | Messung aus Sicht des Senders | | Receiver | Messung aus Sicht des Empfängers | | Retr | TCP-Wiederholungsübertragungen, sofern verfügbar | | Cwnd | TCP Congestion Window, sofern ausgegeben | **Sender und Receiver** Die Werte können geringfügig voneinander abweichen, beispielsweise durch: - noch unterwegs befindliche Daten; - unterschiedliche Messzeitpunkte; - kurzen Test; - Paketverlust; - Abbruch der Steuerverbindung. Bei sehr kurzen Tests kann die Differenz stärker auffallen. Die ESnet-FAQ weist darauf hin, dass Testdaten noch unterwegs sein können, wenn die Steuerverbindung bereits das Testende verarbeitet. **Retransmissions** Viele Wiederholungsübertragungen können hinweisen auf: - Paketverlust; - Überlastung; - fehlerhafte Leitung; - WLAN-Störungen; - überfüllte Warteschlangen; - MTU- oder Offloading-Probleme. Sie beweisen allein jedoch noch keine bestimmte Ursache. **Schwankender Durchsatz** Mögliche Ursachen: - konkurrierender Datenverkehr; - WLAN-Funkbedingungen; - TCP Congestion Control; - CPU-Auslastung; - Firewall- oder VPN-Verarbeitung; - thermische Drosselung; - Paketverlust; - Load Balancing; - dynamische QoS-Regeln.
--- **19. Wie wird geprüft, ob Client oder Server der Engpass ist?**
Endgerätevergleich anzeigen **1. Normalrichtung** ```text [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -t 30 ``` **2. Gegenrichtung** ```text [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -t 30 -R ``` **3. Einzelstream** ```text [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -P 1 -t 30 ``` **4. Vier Streams** ```text [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -P 4 -t 30 ``` **5. CPU-Auslastung parallel beobachten** Linux: ```text [RO] top ``` macOS: ```text [RO] top ``` Windows: ```powershell [RO] Get-Counter '\Processor(_Total)\% Processor Time' ``` **Interpretationsbeispiele** | Beobachtung | Mögliche Ursache | |---|---| | Normalrichtung langsam, Reverse schnell | Senderseite des Clients oder Empfängerseite des Servers prüfen | | Normalrichtung schnell, Reverse langsam | Senderseite des Servers oder Empfängerseite des Clients prüfen | | Ein Stream langsam, mehrere schnell | Einzelstream-, Latenz-, TCP-Window- oder CPU-Limit | | Beide Richtungen gleich langsam | Gemeinsamer Pfad, Linkrate, Firewall, VPN oder CPU | | CPU erreicht 100 % | Endsystem möglicherweise Messgrenze | | Durchsatz schwankt mit CPU | Verarbeitungslimit wahrscheinlich | | Nur WLAN langsam | Funkstrecke, Kanal, Signal oder Airtime prüfen | | LAN schnell, VPN langsam | VPN-Gateway, Verschlüsselung, MTU oder Routing prüfen |
--- **20. Wie werden Netzwerkkarten- und Interface-Zähler einbezogen?**
Betriebssystemspezifische Kontrollbefehle anzeigen **Windows** ```powershell [RO] Get-NetAdapter ``` ```powershell [RO] Get-NetAdapterStatistics ``` ```powershell [RO] Get-NetAdapter | Select-Object Name, Status, LinkSpeed ``` **Linux** ```text [RO] ip -s link show ``` ```text [RO] ethtool eth0 ``` ```text [RO][PRIV] sudo ethtool -S eth0 ``` **macOS** ```text [RO] ifconfig en0 ``` ```text [RO] netstat -ib ``` **Vor und nach dem iPerf3-Test vergleichen** Zu prüfen sind unter anderem: - Linkgeschwindigkeit; - empfangene und gesendete Byte; - RX- und TX-Fehler; - Drops; - Kollisionen, sofern relevant; - Interface-Resets; - Duplexmodus bei Ethernet; - WLAN-Signal und Übertragungsrate; - CPU-Auslastung. Ein iPerf3-Ergebnis ohne Interface- und Systemauslastung zeigt nur den gemessenen End-to-End-Durchsatz, aber nicht automatisch die Engpassstelle.
--- **21. Welche Rolle spielen MTU, MSS und Paketgröße?**
MTU- und Längenoptionen anzeigen **TCP Maximum Segment Size setzen** ```text [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -M 1460 ``` `-M` setzt die gewünschte TCP-MSS. Der tatsächlich verwendete Wert kann durch Betriebssystem und Netzwerkpfad beeinflusst werden. Für Ethernet mit einer MTU von 1500 Byte ergibt sich bei IPv4 ohne zusätzliche Optionen häufig: ```text 1500 Byte MTU - 20 Byte IPv4-Header - 20 Byte TCP-Header = 1460 Byte TCP-MSS ``` Bei IPv6 sind die Basisheader größer: ```text 1500 Byte MTU - 40 Byte IPv6-Header - 20 Byte TCP-Header = 1440 Byte TCP-MSS ``` Zusätzliche Header, TCP-Optionen, VLAN, VPN oder Tunnel können die nutzbare Größe beeinflussen. **iPerf3-Puffer- beziehungsweise Blocklänge** ```text [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -l 512 ``` `-l` bestimmt die Länge des von iPerf3 gelesenen oder geschriebenen Puffers. Sie ist nicht identisch mit der Ethernet-Framegröße. **UDP mit bestimmter Datagrammlänge** ```text [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -u -b 10M -l 1200 ``` **IPv4-UDP mit gesetztem Don't-Fragment-Bit** ```text [TEST][DISRUPT][SENS] iperf3 -4 -c 192.0.2.20 -u -b 10M -l 1400 --dont-fragment ``` `--dont-fragment` gilt nach der offiziellen Dokumentation nur für UDP über IPv4. > Größenoptionen sollten nur gezielt verändert werden. Ungeeignete Werte können Fragmentierung, Verluste oder irreführende Ergebnisse verursachen.
--- **22. Warum kann der TCP-Durchsatz plötzlich fast auf null fallen?**
Offloading- und Segmentierungsprobleme anzeigen Nach der offiziellen ESnet-FAQ kann ein fast vollständig einbrechender TCP-Durchsatz unter anderem mit fehlerhaftem TCP-Offloading zusammenhängen. Mögliche beteiligte Funktionen: - TCP Segmentation Offload, TSO; - Large Send Offload, LSO; - Generic Segmentation Offload, GSO; - Generic Receive Offload, GRO; - Large Receive Offload, LRO. **Diagnosevergleich** **Normalrichtung** ```text [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -t 30 ``` **Reverse-Richtung** ```text [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -t 30 -R ``` **Kleinere Schreibgröße** ```text [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -t 30 -l 512 ``` **MSS testweise begrenzen** ```text [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -t 30 -M 1460 ``` **Zusätzliche Prüfung** - Paketmitschnitt mit Wireshark oder tcpdump; - ICMP-Fragmentation-Needed-Nachrichten; - Wiederholungsübertragungen; - Interface-Fehler; - MTU des VPN- oder Tunnelpfads; - Treiber- und Firmwarestand. Das Deaktivieren von Offloading ist eine Systemänderung und kann die Leistung beeinflussen. Es sollte erst nach dokumentierter Diagnose, Freigabe und mit Rückfallplan erfolgen.
--- **23. Wie werden WLAN-Verbindungen sinnvoll getestet?**
WLAN-Testaufbau anzeigen Ein geeigneter WLAN-Testaufbau ist: ```text WLAN-Client ↓ Funkstrecke Access Point ↓ Ethernet Kabelgebundener iPerf3-Server ``` Der Server sollte möglichst per Ethernet angebunden sein. Sind Client und Server beide im WLAN, teilen sie sich möglicherweise dieselbe Funkzeit. Das Ergebnis enthält dann zwei Funkübertragungen und ist schwerer zu interpretieren. **Empfohlene Tests** ```text [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -t 30 ``` ```text [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -t 30 -R ``` ```text [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -u -b 10M -t 30 ``` Die UDP-Rate wird anschließend vorsichtig erhöht. **Zusätzlich dokumentieren** - Frequenzband; - Kanal; - Kanalbreite; - Signalstärke; - Noise Floor, sofern verfügbar; - PHY-Linkrate; - Abstand zum Access Point; - Anzahl aktiver Clients; - Roaming; - Energiesparmodus; - verwendeter Access Point. **Wichtiger Unterschied** ```text WLAN-Linkrate ≠ nutzbarer TCP-Durchsatz ``` Die angezeigte PHY-Rate enthält Protokoll-, Funk-, Bestätigungs- und Verwaltungsanteile. Der tatsächlich nutzbare TCP-Durchsatz ist daher niedriger.
--- **24. Wie werden VPN- und Standortverbindungen untersucht?**
Vergleichsmessungen anzeigen **Messung ohne VPN** ```text Client → lokaler iPerf3-Server ``` **Messung durch VPN** ```text Client → VPN-Tunnel → entfernter iPerf3-Server ``` **Normalrichtung** ```text [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -t 30 ``` **Reverse-Richtung** ```text [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -t 30 -R ``` **UDP mit kontrollierter Rate** ```text [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -u -b 20M -t 30 ``` **Mögliche VPN-Engpässe** - CPU des VPN-Gateways; - Verschlüsselungsleistung; - MTU und MSS; - Paketfragmentierung; - Internet-Uplink; - asymmetrische Bandbreite; - Paketverlust; - hohe Laufzeit; - Single-Stream-Limit; - QoS oder Traffic Shaping; - Cloud-Gateway-Größe; - NAT- oder Firewall-Verarbeitung. **Vergleichstabelle** | Test | Ohne VPN | Mit VPN | |---|---:|---:| | TCP Client → Server | 940 Mbit/s | 180 Mbit/s | | TCP Server → Client | 940 Mbit/s | 350 Mbit/s | | UDP ohne Verlust | 800 Mbit/s | 150 Mbit/s | | Jitter | 0,2 ms | 3,5 ms | Diese Zahlen sind nur ein Dokumentationsbeispiel. Sie stellen keine allgemeinen Sollwerte dar.
--- **25. Wie wird zwischen Netzwerk- und Speicherproblem unterschieden?**
iPerf3 und Dateiübertragung vergleichen **Netzwerktest** ```text [TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -t 30 ``` **Anschließend reale Dateiübertragung prüfen** Beispielsweise: - SMB; - NFS; - SFTP; - HTTPS; - Backupsoftware. **Interpretation** | iPerf3 | Dateiübertragung | Mögliche Ursache | |---|---|---| | Schnell | Schnell | Grundsätzlich unauffällig | | Schnell | Langsam | Speicher, Dateisystem, Protokoll, Virenscan oder Anwendung | | Langsam | Langsam | Netzwerkpfad oder Endsysteme weiter prüfen | | Schwankend | Schwankend | Paketverlust, WLAN, CPU, QoS oder konkurrierender Verkehr | iPerf3 bietet außerdem `-F`, um eine Datei als Datenquelle oder -senke zu verwenden: ```text [TEST][FILE][DISRUPT][SENS] iperf3 -c 192.0.2.20 -F testfile.bin ``` Diese Funktion bezieht Speicherzugriffe in die Messung ein. > `-F` macht iPerf3 nicht zu einem zuverlässigen Dateiübertragungsprogramm. Die empfangene Datei kann sich in Länge, Eigenschaften oder Inhalt vom Original unterscheiden.
--- **26. Welche typischen Fehler treten bei iPerf3 auf?**
Fehlertabelle anzeigen | Fehler oder Beobachtung | Mögliche Ursache | Prüfung | |---|---|---| | `command not found` | iPerf3 nicht installiert oder nicht im Suchpfad | `command -v iperf3` beziehungsweise `Get-Command iperf3` | | `unable to connect to server` | Server läuft nicht, falsche IP oder Firewall | Listener und TCP-Port 5201 prüfen | | `Connection refused` | Ziel erreichbar, aber kein Listener am Port | Serverprozess und Port prüfen | | `Connection timed out` | Firewall, Routing oder Rückwegproblem | Nmap, Traceroute und Paketmitschnitt | | UDP-Test startet nicht | TCP-Steuerverbindung fehlt | TCP 5201 prüfen | | TCP funktioniert, UDP nicht | UDP-Port gefiltert oder falsche Firewallregel | UDP-Freigabe und Paketmitschnitt | | Ergebnis viel niedriger als Linkrate | Protokolloverhead, CPU, Verlust oder Pfadbegrenzung | CPU, Interface-Zähler und Gegenrichtung | | Reverse deutlich schneller | Asymmetrie oder unterschiedlicher Endgeräteengpass | Sender- und Empfängerseite vergleichen | | Ein Stream langsam, mehrere schnell | Einzelstream-, Window-, Latenz- oder CPU-Limit | `-P 1` und `-P 4` vergleichen | | Hoher UDP-Verlust | Zielrate zu hoch oder Empfangspfad überlastet | Rate schrittweise reduzieren | | Hoher Jitter | Warteschlangen, WLAN, Überlastung oder QoS | geringere Rate und paralleles Monitoring | | TCP bricht fast auf null ein | Mögliches Offloading- oder MTU-Problem | `-R`, `-l`, `-M` und Paketmitschnitt | | Ergebnis schwankt stark | Test zu kurz oder konkurrierender Verkehr | längerer Test und Monitoring | | Windows-Option funktioniert nicht | Community-Build nicht vollständig kompatibel | Buildquelle und unterstützte Optionen prüfen | | Server bleibt erreichbar | Server ohne `-1` gestartet | Prozess kontrolliert beenden | | JSON-Datei leer | Test nicht abgeschlossen oder Ausgabeproblem | Befehl ohne Umleitung testen | | Port bereits belegt | Anderer iPerf3-Prozess oder Dienst | Listener des Ports prüfen |
--- **27. Welche Fehlinterpretationen müssen vermieden werden?**
Prüfungs- und Praxisfallen anzeigen | Fehlinterpretation | Richtige Einordnung | |---|---| | iPerf3 zeigt die Internetgeschwindigkeit | Es misst nur zwischen dem iPerf3-Client und -Server | | 1-Gbit/s-Link muss exakt 1 Gbit/s TCP erreichen | Protokoll- und Systemanteile reduzieren den Nutzdurchsatz | | Hoher TCP-Durchsatz bedeutet null Paketverlust | TCP kann Verlust durch Wiederholungen ausgleichen | | UDP-Verlust bedeutet defektes Kabel | Die konfigurierte Senderate kann zu hoch sein | | Jitter ist dasselbe wie Latenz | Jitter ist die Schwankung der Laufzeit | | `-R` wird auf dem Server eingegeben | `-R` wird am Client angegeben | | UDP verwendet nur UDP 5201 | Die Steuerverbindung verwendet weiterhin TCP | | Mehrere Streams zeigen die Leistung einer einzelnen Anwendung | Eine Anwendung kann nur einen Stream verwenden | | `--bidir` entspricht zwei getrennten Tests | Gleichzeitiger Verkehr beeinflusst beide Richtungen | | Ein kurzer Test ist immer aussagekräftig | TCP Slow Start und kurzfristige Schwankungen beeinflussen ihn | | iPerf3 prüft Festplattenleistung | Standardmäßig werden synthetische Daten verwendet | | iPerf3 und iPerf2 sind kompatibel | Beide Werkzeuge verwenden unterschiedliche Protokolle | | Community-iPerf3 unter Windows ist offiziell unterstützt | ESnet unterstützt iPerf3 unter Windows nicht offiziell | | Höchstmögliche Rate ist automatisch der richtige Test | Produktive Netze müssen kontrolliert und stufenweise getestet werden |
--- **28. Wie sieht ein systematischer iPerf3-Diagnoseablauf aus?**
Empfohlene Schrittfolge anzeigen **Vorbereitung** 1. Fehlerbild und erwarteten Durchsatz dokumentieren. 2. Client, Server und Netzwerkpfad festlegen. 3. Testgenehmigung und Wartungszeitraum prüfen. 4. Maximale Testdauer und Datenrate festlegen. 5. iPerf3-Versionen auf beiden Endpunkten dokumentieren. 6. CPU-, Interface- und Monitoringansichten vorbereiten. 7. Firewallfreigabe für TCP und gegebenenfalls UDP prüfen. **Server** 8. Server möglichst kabelgebunden und leistungsfähig auswählen. 9. Server an die richtige Adresse binden. 10. Für Einzeltests möglichst `-1` verwenden. 11. Listener auf Port 5201 kontrollieren. **Basistest** 12. TCP-Einzelstream für 30 Sekunden durchführen. 13. TCP-Reverse-Test durchführen. 14. Sender- und Receiverwerte dokumentieren. 15. CPU- und Interface-Zähler prüfen. **Vertiefung** 16. Vier parallele Streams testen. 17. Ergebnis mit Einzelstream vergleichen. 18. UDP bei niedriger Rate beginnen. 19. Rate schrittweise erhöhen. 20. Jitter und Paketverlust dokumentieren. 21. IPv4 und IPv6 bei Bedarf getrennt testen. 22. WLAN-, VPN- oder VLAN-Pfade separat vergleichen. **Analyse** 23. Langsamen Pfad mit Ping, Traceroute und Paketmitschnitt untersuchen. 24. Firewall-, Switch- und VPN-Monitoring vergleichen. 25. MTU, MSS und Offloading nur bei konkreten Hinweisen untersuchen. 26. iPerf3-Ergebnis mit realer Anwendung vergleichen. **Abschluss** 27. Testbefehle und Ergebnisse speichern. 28. Temporäre Firewallfreigaben zurücknehmen. 29. Nicht mehr benötigten Serverprozess beenden. 30. Beobachtung, Hypothese, Änderung und Nachtest dokumentieren.
--- **29. Kurzreferenz – iPerf3-Befehle**
Befehlstabelle anzeigen | Aufgabe | Befehl | |---|---| | Version | `[RO] iperf3 --version` | | Hilfe | `[RO] iperf3 -h` | | Server starten | `[TEST][DISRUPT] iperf3 -s` | | Server für einen Test | `[TEST][DISRUPT] iperf3 -s -1` | | Server an IP binden | `[TEST][DISRUPT] iperf3 -s -B 192.0.2.20` | | Anderen Port verwenden | `[TEST][DISRUPT] iperf3 -s -p 5002` | | TCP-Standardtest | `[TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20` | | 30 Sekunden testen | `[TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -t 30` | | Gegenrichtung | `[TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -t 30 -R` | | Beide Richtungen gleichzeitig | `[TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -t 30 --bidir` | | Vier TCP-Streams | `[TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -P 4 -t 30` | | UDP mit 10 Mbit/s | `[TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -u -b 10M -t 30` | | UDP mit 100 Mbit/s | `[TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -u -b 100M -t 30` | | Reverse-UDP | `[TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -u -b 100M -t 30 -R` | | Warmlaufphase auslassen | `[TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -t 30 -O 5` | | Lokale IP binden | `[TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -B 192.0.2.10` | | IPv4 erzwingen | `[TEST][DISRUPT][SENS] iperf3 -4 -c 192.0.2.20` | | IPv6 erzwingen | `[TEST][DISRUPT][SENS] iperf3 -6 -c 2001:db8::20` | | JSON-Ausgabe | `[TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -J` | | Logdatei | `[TEST][FILE][DISRUPT][SENS] iperf3 -c 192.0.2.20 --logfile result.log` | | Serverausgabe abrufen | `[TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 --get-server-output` | | MSS setzen | `[TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -M 1460` | | Pufferlänge setzen | `[TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -l 512` |
--- **30. Kurzreferenz – wichtigste Optionen**
Optionstabelle anzeigen | Option | Bedeutung | |---|---| | `-s` | Servermodus | | `-c HOST` | Clientmodus und Zielserver | | `-p PORT` | Server- beziehungsweise Zielport | | `-1` | Server nach einer Clientverbindung beenden | | `-t SEKUNDEN` | Testdauer | | `-n MENGE` | Zu übertragende Datenmenge | | `-k ANZAHL` | Anzahl zu übertragender Blöcke | | `-i SEKUNDEN` | Ausgabeintervall | | `-f m` | Ausgabe beispielsweise in Mbit/s | | `-R` | Testrichtung umkehren | | `--bidir` | Beide Richtungen gleichzeitig testen | | `-u` | UDP statt TCP | | `-b RATE` | Zielbitrate setzen | | `-P ANZAHL` | Parallele Streams | | `-O SEKUNDEN` | Warmlaufzeit aus Statistik auslassen | | `-B ADRESSE` | An lokale IP-Adresse binden | | `--bind-dev` | An ein Interface binden, sofern unterstützt | | `-4` | IPv4 erzwingen | | `-6` | IPv6 erzwingen | | `-J` | JSON-Ausgabe | | `--json-stream` | Zeilenweise JSON-Ausgabe | | `--logfile` | Ausgabe in Logdatei | | `--forceflush` | Ausgabe je Intervall sofort schreiben | | `--timestamps` | Zeitstempel voranstellen | | `--get-server-output` | Serverausgabe am Client abrufen | | `-M` | TCP-MSS festlegen | | `-l` | Puffer- beziehungsweise UDP-Datagrammlänge | | `-w` | Socketpuffergröße setzen | | `-N` | Nagle-Algorithmus für TCP/SCTP deaktivieren | | `-Z` | Zero-Copy-Sendemethode verwenden | | `--dont-fragment` | IPv4-DF-Bit bei UDP setzen |
--- **Merksätze** - iPerf3 benötigt immer einen iPerf3-Server und einen iPerf3-Client. - iPerf2 und iPerf3 sind nicht miteinander kompatibel. - iPerf3 wird von ESnet offiziell für Linux, FreeBSD und macOS, aber nicht für Windows unterstützt. - Der Standardport ist 5201. - Bei UDP wird weiterhin eine TCP-Steuerverbindung benötigt. - Standardmäßig sendet der Client zum Server. - `-R` wird am Client angegeben und kehrt die Datenrichtung um. - TCP versucht standardmäßig, die verfügbare Kapazität auszunutzen. - UDP sollte immer mit einer kontrollierten niedrigen Rate begonnen werden. - Jitter ist eine Laufzeitschwankung und nicht die absolute Latenz. - UDP-Paketverlust kann durch eine zu hoch eingestellte Senderate entstehen. - Ein Einzelstream und mehrere Parallelstreams beantworten unterschiedliche Fragen. - Ein schneller iPerf3-Test beweist nicht, dass eine Anwendung schnell arbeitet. - CPU, Interface-Zähler, Linkrate und Netzwerkpfad müssen zusammen mit dem Ergebnis dokumentiert werden. - Vergleichstests müssen dieselben Endpunkte, Richtungen, Versionen und Parameter verwenden. - Leistungstests können produktiven Datenverkehr beeinträchtigen und müssen abgestimmt durchgeführt werden. --- **Quellen** - [Offizielle iPerf3-Dokumentation von ESnet](https://software.es.net/iperf/) - [ESnet – Invoking iPerf3 und offizielle Optionsreferenz](https://software.es.net/iperf/invoking.html) - [Offizielle iPerf3-FAQ von ESnet](https://software.es.net/iperf/faq.html) - [Offizielles iPerf3-Repository von ESnet](https://github.com/esnet/iperf) - [ESnet Fasterdata – iPerf3](https://fasterdata.es.net/performance-testing/network-troubleshooting-tools/iperf/) - [ESnet Fasterdata – Throughput Tool Comparison](https://fasterdata.es.net/performance-testing/network-troubleshooting-tools/throughput-tool-comparision/) - [ESnet Fasterdata – Multi-Stream iPerf3](https://fasterdata.es.net/performance-testing/network-troubleshooting-tools/iperf/multi-stream-iperf3/) # 2.9 curl – HTTP-, HTTPS-, API-, DNS-, Proxy- und Verbindungsdiagnose **Ziel dieser Seite** `curl` überträgt Daten anhand einer URL und eignet sich besonders zur Diagnose von Webdiensten und APIs. Administratoren können damit unter anderem prüfen: - ob ein TCP-Dienst erreichbar ist; - ob ein Webserver auf HTTP oder HTTPS antwortet; - welchen HTTP-Statuscode ein Server zurückgibt; - ob Weiterleitungen funktionieren; - ob DNS-Auflösung und Zielserver zusammenpassen; - ob TLS-Verbindungen und Zertifikatsprüfungen funktionieren; - ob SNI und virtuelle Hosts korrekt verarbeitet werden; - wie lange DNS, TCP-Verbindungsaufbau, TLS und Serverantwort dauern; - ob ein Proxy Verbindungen erlaubt oder verändert; - ob bestimmte HTTP-Header übertragen werden; - ob eine API auf GET-, POST-, PUT-, PATCH- oder DELETE-Anfragen reagiert; - ob IPv4 und IPv6 unterschiedliche Ergebnisse liefern. > `curl` ist kein vollständiger Browser. JavaScript, grafische Darstellung, Browser-Erweiterungen und komplexe Browser-Sitzungen werden nicht wie in einem normalen Webbrowser ausgeführt. --- **Kennzeichnungen** | Kennzeichnung | Bedeutung | |---|---| | `[RO]` | Lokale Informationsabfrage | | `[TEST]` | Aktive Netzwerk- oder Anwendungsanfrage | | `[PRIV]` | Erhöhte Berechtigungen können erforderlich sein | | `[FILE]` | Befehl liest oder erstellt eine Datei | | `[SENS]` | Anfrage oder Ausgabe kann sensible Informationen enthalten | | `[CHANGE]` | Anfrage kann Daten oder einen Zustand verändern | | `[DISRUPT]` | Anfrage kann einen Dienst oder produktive Daten beeinflussen | --- **1. Wie wird curl unter Windows, Linux und macOS aufgerufen?**
Betriebssystemübersicht anzeigen | Aufgabe | Windows | Linux | macOS | |---|---|---|---| | Programmpfad | `[RO] Get-Command curl.exe` | `[RO] command -v curl` | `[RO] command -v curl` | | Version | `[RO] curl.exe --version` | `[RO] curl --version` | `[RO] curl --version` | | Kurzhilfe | `[RO] curl.exe --help` | `[RO] curl --help` | `[RO] curl --help` | | Gesamte Hilfe | `[RO] curl.exe --manual` | `[RO] curl --manual` | `[RO] curl --manual` | | Lokales Handbuch | Nicht standardmäßig | `[RO] man curl` | `[RO] man curl` | **Wichtig unter Windows PowerShell** In älteren Windows-PowerShell-Versionen kann `curl` als Alias für `Invoke-WebRequest` definiert sein. Dann verhält sich der Befehl nicht wie das echte curl-Programm. Deshalb unter Windows eindeutig verwenden: ```powershell [RO] curl.exe --version ``` Alias prüfen: ```powershell [RO] Get-Command curl ``` Wenn als Befehlstyp `Alias` und als Ziel `Invoke-WebRequest` erscheint, muss für die in dieser Seite gezeigte Syntax ausdrücklich `curl.exe` verwendet werden. **Build-Funktionen prüfen** ```text [RO] curl --version ``` Die Ausgabe zeigt unter anderem: - curl-Version; - verwendete TLS-Bibliothek; - unterstützte Protokolle; - unterstützte Funktionen; - HTTP/2- oder HTTP/3-Unterstützung; - IPv6-Unterstützung; - Kompressionsunterstützung. Nicht jede curl-Installation unterstützt alle Optionen und Protokolle. Entscheidend ist der lokal installierte Build.
--- **2. Was passiert bei einem einfachen curl-Aufruf?**
Grundlegende Anfrage anzeigen Linux und macOS: ```text [TEST][SENS] curl https://example.com/ ``` Windows: ```powershell [TEST][SENS] curl.exe https://example.com/ ``` Ohne weitere Optionen schreibt curl den empfangenen Antwortinhalt auf die Standardausgabe. Bei einer HTML-Seite erscheint daher der HTML-Quelltext: ```html ... ``` **Explizites URL-Schema verwenden** Empfohlen: ```text https://example.com/ ``` Nicht empfohlen: ```text example.com ``` Ohne Schema versucht curl, das Protokoll zu erraten. Für reproduzierbare Diagnosen sollte immer ausdrücklich `http://` oder `https://` angegeben werden. **URL in Anführungszeichen setzen** ```text [TEST][SENS] curl 'https://example.com/search?q=test&lang=de' ``` Besonders Zeichen wie diese können von einer Shell interpretiert werden: ```text & ? * [ ] { } ``` In PowerShell und klassischen Windows-Kommandozeilen können sich die Regeln für Anführungszeichen unterscheiden. Bei einfachen URLs funktionieren doppelte Anführungszeichen meist plattformübergreifend: ```text [TEST][SENS] curl "https://example.com/search?q=test&lang=de" ```
--- **3. Wie werden HTTP-Header angezeigt?**
Headeroptionen anzeigen **Nur Antwortheader anfordern** ```text [TEST][SENS] curl -I https://example.com/ ``` `-I` beziehungsweise `--head` veranlasst curl bei HTTP, eine `HEAD`-Anfrage zu senden. **Header und Antwortinhalt anzeigen** ```text [TEST][SENS] curl -i https://example.com/ ``` `-i` fügt die Antwortheader vor dem Inhalt ein. **Antwortheader separat auf die Standardausgabe schreiben** ```text [TEST][SENS] curl -D - https://example.com/ ``` **Header in eine Datei schreiben** ```text [TEST][FILE][SENS] curl -D response-headers.txt -o response-body.html https://example.com/ ``` **Wichtiger Unterschied** | Option | Wirkung | |---|---| | `-I` | Sendet bei HTTP eine HEAD-Anfrage | | `-i` | Zeigt Header und Antwortinhalt einer normalen Anfrage | | `-D DATEI` | Schreibt empfangene Header separat | | `-o DATEI` | Schreibt den Antwortinhalt in eine Datei | Nicht jeder Server behandelt `HEAD` und `GET` identisch. Ein erfolgreicher HEAD-Test beweist deshalb nicht sicher, dass ein GET-Aufruf denselben Status erhält. **GET ausführen, aber Antwortinhalt verwerfen** Linux und macOS: ```text [TEST][SENS] curl -sS -o /dev/null -D - https://example.com/ ``` Windows: ```powershell [TEST][SENS] curl.exe -sS -o NUL -D - https://example.com/ ``` Damit wird eine normale GET-Anfrage durchgeführt, ohne den vollständigen Inhalt im Terminal auszugeben.
--- **4. Wie wird nur der HTTP-Statuscode ausgegeben?**
Statuscode-Prüfung anzeigen Linux und macOS: ```text [TEST] curl -sS -o /dev/null -w "%{http_code}\n" https://example.com/ ``` Windows: ```powershell [TEST] curl.exe -sS -o NUL -w "%{http_code}\n" https://example.com/ ``` **Statuscode und Ziel-URL nach Weiterleitungen** Linux und macOS: ```text [TEST] curl -sS -L -o /dev/null -w "HTTP=%{http_code} URL=%{url_effective}\n" https://example.com/ ``` Windows: ```powershell [TEST] curl.exe -sS -L -o NUL -w "HTTP=%{http_code} URL=%{url_effective}\n" https://example.com/ ``` **HTTP-Statusgruppen** | Bereich | Bedeutung | |---:|---| | `100–199` | Information | | `200–299` | Erfolgreiche Verarbeitung | | `300–399` | Weiterleitung | | `400–499` | Anfrage- oder Clientfehler | | `500–599` | Serverfehler | **Häufige Statuscodes** | Status | Bedeutung | |---:|---| | `200 OK` | Anfrage erfolgreich | | `201 Created` | Ressource erstellt | | `204 No Content` | Erfolgreich, aber ohne Antwortinhalt | | `301 Moved Permanently` | Dauerhafte Weiterleitung | | `302 Found` | Temporäre Weiterleitung | | `304 Not Modified` | Ressource seit Cacheprüfung nicht geändert | | `307 Temporary Redirect` | Temporäre Weiterleitung unter Beibehaltung der Methode | | `308 Permanent Redirect` | Dauerhafte Weiterleitung unter Beibehaltung der Methode | | `400 Bad Request` | Anfrage syntaktisch oder fachlich ungültig | | `401 Unauthorized` | Authentifizierung fehlt oder ist ungültig | | `403 Forbidden` | Anfrage verstanden, Zugriff verweigert | | `404 Not Found` | Ressource nicht gefunden | | `405 Method Not Allowed` | HTTP-Methode nicht erlaubt | | `408 Request Timeout` | Server wartete zu lange auf die Anfrage | | `409 Conflict` | Konflikt mit aktuellem Ressourcenstatus | | `429 Too Many Requests` | Rate Limit erreicht | | `500 Internal Server Error` | Interner Serverfehler | | `502 Bad Gateway` | Gateway oder Proxy erhielt ungültige Upstream-Antwort | | `503 Service Unavailable` | Dienst momentan nicht verfügbar | | `504 Gateway Timeout` | Gateway erhielt nicht rechtzeitig eine Upstream-Antwort | > Ein HTTP-Fehlercode bedeutet, dass die HTTP-Kommunikation grundsätzlich stattgefunden hat. DNS, TCP und normalerweise auch TLS waren bis zu diesem Punkt bereits erfolgreich.
--- **5. Warum liefert curl bei einem HTTP-Fehler trotzdem Exitcode 0?**
HTTP-Status und curl-Exitcode unterscheiden Ohne `--fail` bewertet curl eine erfolgreich empfangene HTTP-Antwort als erfolgreiche Übertragung – auch wenn der Server beispielsweise `404` oder `500` zurückgibt. ```text HTTP-Statuscode 404 curl-Exitcode 0 ``` Das bedeutet: ```text Übertragung technisch erfolgreich Anwendung meldet HTTP-Fehler ``` **Bei HTTP-Fehlern mit Exitcode ungleich 0 beenden** ```text [TEST] curl --fail https://example.com/missing ``` Kurzform: ```text [TEST] curl -f https://example.com/missing ``` **HTTP-Fehlercode liefern und Antwortinhalt behalten** ```text [TEST][SENS] curl --fail-with-body https://example.com/missing ``` `--fail-with-body`: - liefert bei HTTP-Status 400 oder höher einen curl-Fehler; - behält den Server-Antwortinhalt bei; - verwendet bei einem entsprechenden HTTP-Fehler normalerweise curl-Exitcode `22`. **Für Skripte häufig sinnvoll** ```text [TEST] curl -sS --fail-with-body https://example.com/health ``` | Option | Verhalten | |---|---| | `-s` | Fortschrittsanzeige unterdrücken | | `-S` | Fehlermeldung trotz `-s` anzeigen | | `--fail-with-body` | HTTP-Fehler als curl-Fehler behandeln und Inhalt behalten |
--- **6. Wie werden Weiterleitungen untersucht?**
Redirect-Diagnose anzeigen **Nur erste Antwort anzeigen** ```text [TEST][SENS] curl -I http://example.com/ ``` Mögliche Ausgabe: ```text HTTP/1.1 301 Moved Permanently Location: https://example.com/ ``` **Weiterleitungen automatisch verfolgen** ```text [TEST][SENS] curl -L http://example.com/ ``` **Header aller Weiterleitungsstufen anzeigen** ```text [TEST][SENS] curl -L -I http://example.com/ ``` **Maximale Anzahl Weiterleitungen begrenzen** ```text [TEST][SENS] curl -L --max-redirs 5 https://example.com/ ``` **Effektive Ziel-URL ausgeben** Linux und macOS: ```text [TEST] curl -sS -L -o /dev/null -w "%{url_effective}\n" http://example.com/ ``` Windows: ```powershell [TEST] curl.exe -sS -L -o NUL -w "%{url_effective}\n" http://example.com/ ``` **Typische Redirect-Probleme** - HTTP leitet nicht auf HTTPS weiter; - Weiterleitung zeigt auf falschen Hostnamen; - Endlosschleife zwischen zwei URLs; - falscher Port in `Location`; - interne Serveradresse wird offengelegt; - Reverse Proxy erzeugt falsches Schema; - Anwendung berücksichtigt `X-Forwarded-Proto` nicht; - Authentifizierungscookie gilt nicht für das neue Ziel; - Weiterleitung funktioniert im Browser wegen Cache, mit curl aber nicht. > `--location-trusted` kann Zugangsdaten auch an andere Weiterleitungsziele weitergeben. Diese Option sollte aus Sicherheitsgründen nicht unüberlegt verwendet werden.
--- **7. Wie wird eine ausführliche Verbindungsdiagnose durchgeführt?**
Verbose-Ausgabe `-v` anzeigen ```text [TEST][SENS] curl -v https://example.com/ ``` Die ausführliche Ausgabe enthält unter anderem: - DNS-Ergebnis; - ausgewählte IP-Adresse; - TCP-Verbindungsaufbau; - TLS-Verhandlung; - Zertifikatsinformationen; - ausgehandeltes Protokoll; - gesendete HTTP-Header; - empfangene HTTP-Header; - Weiterleitungsinformationen; - Wiederverwendung einer Verbindung. **Kennzeichnungen in der Ausgabe** | Zeichen | Bedeutung | |---|---| | `*` | curl-interne Status- oder Verbindungsinformation | | `>` | Von curl an den Server gesendete Daten beziehungsweise Header | | `<` | Vom Server empfangene Daten beziehungsweise Header | | `{` oder `}` | In bestimmten Trace-Ausgaben übertragene Daten | Beispiel: ```text > GET / HTTP/1.1 > Host: example.com > User-Agent: curl/... > Accept: */* ``` ```text < HTTP/1.1 200 OK < Content-Type: text/html < Content-Length: 1256 ``` **Nur Header und Verbindungsinformationen, Inhalt verwerfen** Linux und macOS: ```text [TEST][SENS] curl -v -o /dev/null https://example.com/ ``` Windows: ```powershell [TEST][SENS] curl.exe -v -o NUL https://example.com/ ``` > Die Verbose-Ausgabe kann Zugangsdaten, Cookies, API-Token oder interne Header enthalten. Sie muss vor einer Weitergabe geprüft und bereinigt werden.
--- **8. Wie wird eine detaillierte Ablaufverfolgung erstellt?**
Trace-Optionen anzeigen **ASCII-Trace in eine Datei schreiben** ```text [TEST][FILE][SENS] curl --trace-ascii curl-trace.txt https://example.com/ ``` **Trace mit Zeitstempeln** ```text [TEST][FILE][SENS] curl --trace-time --trace-ascii curl-trace.txt https://example.com/ ``` **Binären Trace schreiben** ```text [TEST][FILE][SENS] curl --trace curl-trace.bin https://example.com/ ``` Ein Trace kann deutlich mehr Informationen als `-v` enthalten, darunter: - vollständige Header; - Nutzdaten; - Cookies; - Formulardaten; - Authentifizierungsinformationen; - API-Antworten; - interne Adressen. Trace-Dateien sind daher als sensible Diagnosedaten zu behandeln. **Nicht gleichzeitig unkontrolliert verwenden** ```text -v --trace --trace-ascii ``` `--trace` beziehungsweise `--trace-ascii` überschreibt die frühere Auswahl der Trace-Ausgabe. Für eine reproduzierbare Diagnose sollte nur die tatsächlich benötigte Variante verwendet werden.
--- **9. Wie werden DNS-, TCP-, TLS- und Serverzeiten gemessen?**
Zeitmessung mit `--write-out` anzeigen Linux und macOS: ```text [TEST] curl -sS -o /dev/null -w "DNS=%{time_namelookup}s TCP=%{time_connect}s TLS=%{time_appconnect}s TTFB=%{time_starttransfer}s Gesamt=%{time_total}s HTTP=%{http_code}\n" https://example.com/ ``` Windows: ```powershell [TEST] curl.exe -sS -o NUL -w "DNS=%{time_namelookup}s TCP=%{time_connect}s TLS=%{time_appconnect}s TTFB=%{time_starttransfer}s Gesamt=%{time_total}s HTTP=%{http_code}\n" https://example.com/ ``` **Bedeutung der Zeitwerte** | Variable | Bedeutung | |---|---| | `time_namelookup` | Zeit bis zum Abschluss der Namensauflösung | | `time_connect` | Zeit vom Start bis zur hergestellten TCP-Verbindung | | `time_appconnect` | Zeit bis zum Abschluss des TLS- oder anderen Anwendungs-Handshakes | | `time_pretransfer` | Zeit bis unmittelbar vor Beginn der Übertragung | | `time_starttransfer` | Zeit bis zum ersten empfangenen Antwortbyte | | `time_redirect` | Gesamtdauer vorheriger Weiterleitungen | | `time_total` | Gesamtdauer der Übertragung | | `http_code` | Letzter empfangener HTTP-Statuscode | | `remote_ip` | Tatsächlich verwendete Ziel-IP-Adresse | | `remote_port` | Tatsächlich verwendeter Zielport | | `local_ip` | Verwendete lokale IP-Adresse | | `num_redirects` | Anzahl verfolgter Weiterleitungen | | `url_effective` | Effektive URL nach Weiterleitungen | **Erweiterte Messung** Linux und macOS: ```text [TEST] curl -sS -L -o /dev/null -w "Lokal=%{local_ip} Remote=%{remote_ip}:%{remote_port} DNS=%{time_namelookup}s TCP=%{time_connect}s TLS=%{time_appconnect}s TTFB=%{time_starttransfer}s Redirect=%{time_redirect}s Gesamt=%{time_total}s Status=%{http_code} Redirects=%{num_redirects} URL=%{url_effective}\n" https://example.com/ ``` Windows: ```powershell [TEST] curl.exe -sS -L -o NUL -w "Lokal=%{local_ip} Remote=%{remote_ip}:%{remote_port} DNS=%{time_namelookup}s TCP=%{time_connect}s TLS=%{time_appconnect}s TTFB=%{time_starttransfer}s Redirect=%{time_redirect}s Gesamt=%{time_total}s Status=%{http_code} Redirects=%{num_redirects} URL=%{url_effective}\n" https://example.com/ ```
--- **10. Wie werden Zeitmessungen richtig interpretiert?**
Zeitanteile einordnen Die Zeitvariablen sind überwiegend kumulativ seit Beginn des curl-Aufrufs. Für einzelne Phasen müssen Differenzen gebildet werden. **DNS-Dauer** ```text DNS = time_namelookup ``` **TCP-Aufbau nach DNS** ```text TCP-Phase = time_connect - time_namelookup ``` **TLS-Handshake nach TCP-Aufbau** ```text TLS-Phase = time_appconnect - time_connect ``` **Serververarbeitung bis zum ersten Byte** Bei HTTPS vereinfacht: ```text Server-/Anwendungsphase = time_starttransfer - time_appconnect ``` **Übertragung nach dem ersten Byte** ```text Downloadphase = time_total - time_starttransfer ``` **Beispiel** | Messwert | Wert | |---|---:| | `time_namelookup` | 0,020 s | | `time_connect` | 0,050 s | | `time_appconnect` | 0,120 s | | `time_starttransfer` | 0,420 s | | `time_total` | 0,500 s | Daraus folgt: ```text DNS = 0,020 s TCP = 0,050 - 0,020 = 0,030 s TLS = 0,120 - 0,050 = 0,070 s Server bis erstes Byte = 0,420 - 0,120 = 0,300 s Restliche Übertragung = 0,500 - 0,420 = 0,080 s ``` Diese Zuordnung ist eine Diagnosehilfe. Proxys, wiederverwendete Verbindungen, Weiterleitungen und unterschiedliche Protokolle können die Interpretation verändern.
--- **11. Wie werden Verbindungs- und Gesamtzeit begrenzt?**
Timeouts anzeigen **Maximal fünf Sekunden für den Verbindungsaufbau** ```text [TEST] curl --connect-timeout 5 https://example.com/ ``` **Maximal 15 Sekunden für den gesamten Vorgang** ```text [TEST] curl --max-time 15 https://example.com/ ``` Kurzform: ```text [TEST] curl -m 15 https://example.com/ ``` **Kombination** ```text [TEST] curl --connect-timeout 5 --max-time 15 https://example.com/ ``` | Option | Begrenzter Bereich | |---|---| | `--connect-timeout` | Verbindungsphase einschließlich notwendiger DNS-, TCP- und gegebenenfalls Proxy-/TLS-Vorgänge bis zur Verbindung | | `--max-time` | Gesamter curl-Vorgang | **Langsame Übertragung abbrechen** ```text [TEST] curl --speed-limit 1000 --speed-time 10 https://example.com/large-file ``` Der Vorgang wird abgebrochen, wenn die Übertragungsrate während des festgelegten Zeitraums unter dem Grenzwert liegt. > Zu kurze Timeouts können langsame, aber funktionierende Verbindungen fälschlich als Fehler erscheinen lassen.
--- **12. Wie werden IPv4 und IPv6 getrennt geprüft?**
IPv4-/IPv6-Vergleich anzeigen **IPv4 erzwingen** ```text [TEST] curl -4 -v https://example.com/ ``` **IPv6 erzwingen** ```text [TEST] curl -6 -v https://example.com/ ``` **Nur Status und Ziel-IP vergleichen** Linux und macOS: ```text [TEST] curl -4 -sS -o /dev/null -w "IPv4=%{remote_ip} HTTP=%{http_code} Zeit=%{time_total}s\n" https://example.com/ ``` ```text [TEST] curl -6 -sS -o /dev/null -w "IPv6=%{remote_ip} HTTP=%{http_code} Zeit=%{time_total}s\n" https://example.com/ ``` Windows: ```powershell [TEST] curl.exe -4 -sS -o NUL -w "IPv4=%{remote_ip} HTTP=%{http_code} Zeit=%{time_total}s\n" https://example.com/ ``` ```powershell [TEST] curl.exe -6 -sS -o NUL -w "IPv6=%{remote_ip} HTTP=%{http_code} Zeit=%{time_total}s\n" https://example.com/ ``` **Interpretation** | IPv4 | IPv6 | Mögliche Ursache | |---|---|---| | Funktioniert | Funktioniert nicht | IPv6-DNS, Routing, Firewall, Neighbor Discovery oder MTU | | Langsam | Schnell | Unterschiedlicher Netzwerkpfad oder unterschiedliche Gegenstelle | | Schnell | Langsam | IPv6-Pfad, Tunnel oder Zielserver prüfen | | Unterschiedliche Inhalte | DNS-/CDN-/Proxy-Zuordnung untersuchen |
--- **13. Wie wird ein Hostname gezielt gegen eine bestimmte IP-Adresse getestet?**
DNS umgehen, Hostname und TLS-SNI erhalten Für HTTPS muss der Hostname normalerweise gleichzeitig für diese Funktionen erhalten bleiben: - HTTP-`Host`-Header; - TLS-SNI; - Zertifikatsprüfung; - virtuelle Hostauswahl. Dafür eignet sich `--resolve`. ```text [TEST][SENS] curl --resolve example.com:443:192.0.2.20 https://example.com/ ``` Dieser Befehl bedeutet: ```text Hostname in URL: example.com Zielport: 443 Tatsächliche Ziel-IP: 192.0.2.20 HTTP-Host: example.com TLS-SNI: example.com Zertifikatsname: example.com ``` **Ausführlicher Test** ```text [TEST][SENS] curl -v --resolve example.com:443:192.0.2.20 https://example.com/ ``` **HTTP ohne TLS** ```text [TEST][SENS] curl --resolve example.com:80:192.0.2.20 http://example.com/ ``` **Warum nicht nur die IP-Adresse aufrufen?** ```text curl https://192.0.2.20/ ``` Dabei verwendet curl die IP-Adresse als Zielnamen. Das kann verursachen: - falschen virtuellen Host; - falsches TLS-SNI; - Zertifikatsnamensfehler; - andere Serverantwort; - Standardseite des Reverse Proxys. **Nur einen Host-Header setzen** ```text curl -H "Host: example.com" https://192.0.2.20/ ``` setzt zwar den HTTP-Host-Header, aber nicht automatisch das passende TLS-SNI für `example.com`. Für HTTPS ist `--resolve` deshalb in der Regel die richtige Diagnoseoption.
--- **14. Was ist der Unterschied zwischen `--resolve` und `--connect-to`?**
Zielumleitung erklären **`--resolve`** ```text [TEST][SENS] curl --resolve example.com:443:192.0.2.20 https://example.com/ ``` `--resolve` fügt für die angegebene Host-/Portkombination eine temporäre Namenszuordnung hinzu. **`--connect-to`** ```text [TEST][SENS] curl --connect-to example.com:443:192.0.2.20:8443 https://example.com/ ``` Damit verbindet sich curl tatsächlich mit: ```text 192.0.2.20:8443 ``` Die ursprüngliche URL bleibt: ```text https://example.com/ ``` Dadurch bleiben insbesondere: - URL-Hostname; - TLS-SNI; - Zertifikatsprüfung; - HTTP-Host auf `example.com` bezogen. **Typischer Einsatz** - neuen Reverse Proxy vor DNS-Umschaltung testen; - Backend auf einem anderen Port prüfen; - Load-Balancer-Knoten gezielt untersuchen; - Blue-Green-Deployment vergleichen; - fehlerhaften DNS-Eintrag umgehen, ohne Hostname und SNI zu verlieren. Beide Optionen gelten nur für den jeweiligen curl-Aufruf und verändern nicht dauerhaft die lokale DNS-Konfiguration.
--- **15. Wie werden TLS und Zertifikate geprüft?**
TLS-Diagnose anzeigen **Normale Zertifikatsprüfung** ```text [TEST][SENS] curl -v https://example.com/ ``` curl prüft dabei abhängig vom verwendeten TLS-Backend unter anderem: - Vertrauenskette; - Gültigkeitszeitraum; - Hostname; - unterstützte TLS-Versionen; - Zertifizierungsstelle; - TLS-Handshake. **Bestimmte CA-Datei verwenden** ```text [TEST][FILE][SENS] curl --cacert company-ca.pem https://internal.example.com/ ``` **TLS 1.2 oder höher anfordern** ```text [TEST][SENS] curl --tlsv1.2 https://example.com/ ``` `--tlsv1.2` legt die minimale TLS-Version auf 1.2 fest. Neuere Versionen können weiterhin ausgehandelt werden. **Maximal TLS 1.2** ```text [TEST][SENS] curl --tlsv1.2 --tls-max 1.2 https://example.com/ ``` **TLS 1.3 oder höher anfordern** ```text [TEST][SENS] curl --tlsv1.3 https://example.com/ ``` Die Unterstützung hängt von curl-Version und TLS-Bibliothek ab. **Clientzertifikat** ```text [TEST][FILE][SENS] curl --cert client.pem --key client.key https://example.com/ ``` Format und Optionen können vom verwendeten TLS-Backend abhängen. **Zertifikatsprüfung deaktivieren** ```text [TEST][SENS] curl -k https://example.com/ ``` `-k` beziehungsweise `--insecure` deaktiviert die normale Echtheitsprüfung. Dadurch kann curl keine vertrauenswürdige Identität des Servers garantieren. > `-k` darf höchstens als klar gekennzeichneter Vergleichstest verwendet werden. Es ist keine Lösung für ein Zertifikatsproblem. **Sinnvolle Interpretation** | Normaler Test | Mit `-k` | Mögliche Ursache | |---|---|---| | Fehler | Erfolgreich | Zertifikatsvertrauen, Hostname oder Zertifikatskette prüfen | | Fehler | Fehler | Problem wahrscheinlich nicht nur Zertifikatsprüfung | | Erfolgreich | Erfolgreich | Kein Grund, `-k` dauerhaft zu verwenden |
--- **16. Wie werden HTTP-Versionen geprüft?**
HTTP/1.1, HTTP/2 und HTTP/3 anzeigen **HTTP/1.1 anfordern** ```text [TEST][SENS] curl --http1.1 -v https://example.com/ ``` **HTTP/2 anfordern** ```text [TEST][SENS] curl --http2 -v https://example.com/ ``` **HTTP/3 versuchen** ```text [TEST][SENS] curl --http3 -v https://example.com/ ``` **Ausschließlich HTTP/3** ```text [TEST][SENS] curl --http3-only -v https://example.com/ ``` Die Optionen funktionieren nur, wenn der installierte curl-Build die jeweilige Protokollversion unterstützt: ```text [RO] curl --version ``` **Interpretation** | Beobachtung | Mögliche Ursache | |---|---| | HTTP/1.1 funktioniert, HTTP/2 nicht | Proxy, TLS-ALPN, Server- oder curl-Buildproblem | | HTTP/2 funktioniert, HTTP/3 nicht | QUIC/UDP, Firewall, Serverunterstützung oder curl-Build | | HTTP/3 funktioniert nur ohne VPN | VPN oder Firewall blockiert beziehungsweise beeinträchtigt UDP | | Unterschiedliche Antworten | Reverse Proxy oder Anwendung behandelt Protokolle unterschiedlich | HTTP/3 verwendet QUIC über UDP. Ein erfolgreicher HTTPS-Test über TCP beweist deshalb nicht, dass HTTP/3 erreichbar ist.
--- **17. Wie werden eigene Request-Header gesetzt?**
Header mit `-H` anzeigen **Accept-Header setzen** ```text [TEST][SENS] curl -H "Accept: application/json" https://api.example.com/status ``` **Benutzerdefinierten Header setzen** ```text [TEST][SENS] curl -H "X-Diagnostic-ID: test-001" https://example.com/ ``` **Mehrere Header** ```text [TEST][SENS] curl -H "Accept: application/json" -H "X-Diagnostic-ID: test-001" https://api.example.com/status ``` **User-Agent setzen** ```text [TEST][SENS] curl -A "IT-Diagnose/1.0" https://example.com/ ``` Alternativ: ```text [TEST][SENS] curl -H "User-Agent: IT-Diagnose/1.0" https://example.com/ ``` **Header entfernen** ```text [TEST][SENS] curl -H "User-Agent:" https://example.com/ ``` Ein Header mit leerem Wert nach dem Doppelpunkt wird entfernt. **Vorsicht** Benutzerdefinierte Header können: - Routing im Reverse Proxy verändern; - Authentifizierung beeinflussen; - Caches umgehen; - Sicherheitsregeln auslösen; - sensible Informationen enthalten. Header aus Browser-Entwicklerwerkzeugen dürfen nicht ungeprüft übernommen werden. Insbesondere Cookies, Tokens und Sitzungskennungen müssen geschützt werden.
--- **18. Wie werden GET-Parameter korrekt übertragen?**
Query-Parameter anzeigen **Parameter direkt in der URL** ```text [TEST][SENS] curl "https://api.example.com/search?q=server&limit=10" ``` **Parameter URL-codieren** ```text [TEST][SENS] curl -G --data-urlencode "q=Server Fehleranalyse" --data-urlencode "limit=10" https://api.example.com/search ``` `-G` sorgt dafür, dass die mit `--data-urlencode` angegebenen Daten als URL-Query und nicht als POST-Body verwendet werden. Ergebnis sinngemäß: ```text https://api.example.com/search?q=Server%20Fehleranalyse&limit=10 ``` **Warum URL-Encoding wichtig ist** Zeichen wie diese besitzen in URLs eine besondere Bedeutung: ```text Leerzeichen & = ? # + % ``` `--data-urlencode` verhindert viele Fehler durch nicht korrekt codierte Werte.
--- **19. Wie werden POST-, PUT-, PATCH- und DELETE-Anfragen getestet?**
HTTP-Methoden und API-Beispiele anzeigen > Ändernde API-Anfragen dürfen nur gegen ausdrücklich freigegebene Testressourcen ausgeführt werden. **POST mit Formulardaten** ```text [TEST][CHANGE][SENS] curl -X POST -d "name=Max Mustermann" -d "active=true" https://api.example.com/users ``` Bei Verwendung von `-d` wählt curl bei HTTP automatisch POST, sofern keine andere Methode angegeben wird. `-X POST` ist deshalb häufig nicht erforderlich: ```text [TEST][CHANGE][SENS] curl -d "name=Max Mustermann" -d "active=true" https://api.example.com/users ``` **POST mit JSON** ```text [TEST][CHANGE][SENS] curl -H "Content-Type: application/json" -d '{"name":"Max Mustermann","active":true}' https://api.example.com/users ``` Neuere curl-Versionen unterstützen: ```text [TEST][CHANGE][SENS] curl --json '{"name":"Max Mustermann","active":true}' https://api.example.com/users ``` `--json` setzt geeignete JSON-Header und verwendet die Daten als Request-Body. Die Verfügbarkeit hängt von der curl-Version ab. **JSON aus Datei** ```text [TEST][FILE][CHANGE][SENS] curl -H "Content-Type: application/json" --data-binary @request.json https://api.example.com/users ``` **PUT** ```text [TEST][CHANGE][SENS] curl -X PUT -H "Content-Type: application/json" --data-binary @request.json https://api.example.com/users/123 ``` **PATCH** ```text [TEST][CHANGE][SENS] curl -X PATCH -H "Content-Type: application/json" -d '{"active":false}' https://api.example.com/users/123 ``` **DELETE** ```text [TEST][CHANGE][DISRUPT][SENS] curl -X DELETE https://api.example.com/users/123 ``` **OPTIONS** ```text [TEST][SENS] curl -i -X OPTIONS https://api.example.com/users ``` `OPTIONS` kann Hinweise auf erlaubte Methoden oder CORS-Header liefern. Server müssen jedoch nicht alle Fähigkeiten vollständig darüber offenlegen.
--- **20. Was ist der Unterschied zwischen `-d` und `--data-binary`?**
Übertragung von Request-Daten erklären | Option | Verhalten | |---|---| | `-d` beziehungsweise `--data` | Sendet HTTP-Daten; Zeilenenden und Dateieinlesung folgen den Regeln dieser Option | | `--data-raw` | Wie `--data`, aber `@` wird nicht als Dateiverweis behandelt | | `--data-binary` | Überträgt Daten weitgehend unverändert | | `--data-urlencode` | URL-codiert die Daten | | `--json` | Sendet JSON und setzt passende Header | **Textdaten** ```text [TEST][CHANGE][SENS] curl -d "name=Max Mustermann" https://api.example.com/users ``` **Datei binär beziehungsweise unverändert senden** ```text [TEST][FILE][CHANGE][SENS] curl --data-binary @request.json https://api.example.com/import ``` **Wörtliches `@` senden** ```text [TEST][CHANGE][SENS] curl --data-raw "@example" https://api.example.com/test ``` Bei `-d @datei` interpretiert curl den Wert als Dateipfad. Bei `--data-raw` wird ein führendes `@` dagegen wörtlich übertragen.
--- **21. Wie werden Dateien hoch- und heruntergeladen?**
Dateitransfer anzeigen **Antwort in benannte Datei schreiben** ```text [TEST][FILE][SENS] curl -o download.bin https://example.com/file.bin ``` **Remote-Dateinamen verwenden** ```text [TEST][FILE][SENS] curl -O https://example.com/file.bin ``` **Weiterleitung verfolgen und Remote-Dateinamen verwenden** ```text [TEST][FILE][SENS] curl -L -O https://example.com/file.bin ``` **Teilweise Übertragung fortsetzen** ```text [TEST][FILE][SENS] curl -C - -O https://example.com/file.bin ``` **Download bei Fehler entfernen** ```text [TEST][FILE][SENS] curl --fail --remove-on-error -o download.bin https://example.com/file.bin ``` **Datei mit PUT hochladen** ```text [TEST][FILE][CHANGE][SENS] curl -T upload.bin https://example.com/upload.bin ``` **Multipart-Formularupload** ```text [TEST][FILE][CHANGE][SENS] curl -F "file=@upload.bin" https://example.com/upload ``` Vor einem Upload müssen Ziel, Methode, Überschreibverhalten und Berechtigung geprüft werden.
--- **22. Wie wird eine HTTP-Authentifizierung getestet?**
Basic, Digest, Bearer und Negotiate anzeigen **Benutzername angeben und Passwort interaktiv abfragen** ```text [TEST][SENS] curl -u "max.mustermann" https://example.com/protected ``` curl fordert das Passwort interaktiv an. **Benutzername und Passwort direkt angeben** ```text [TEST][SENS] curl -u "max.mustermann:BEISPIELPASSWORT" https://example.com/protected ``` Diese Schreibweise ist für reale Zugangsdaten nicht empfohlen, weil das Passwort: - in der Shell-Historie; - in Prozessinformationen; - in Bildschirmaufzeichnungen; - in Supportprotokollen sichtbar werden kann. **Basic Authentication ausdrücklich verwenden** ```text [TEST][SENS] curl --basic -u "max.mustermann" https://example.com/protected ``` **Digest Authentication** ```text [TEST][SENS] curl --digest -u "max.mustermann" https://example.com/protected ``` **Unterstützte Methode automatisch auswählen** ```text [TEST][SENS] curl --anyauth -u "max.mustermann" https://example.com/protected ``` `--anyauth` kann eine zusätzliche Anfrage erzeugen, um die angebotenen Methoden zu erkennen. **Bearer-Token** ```text [TEST][SENS] curl -H "Authorization: Bearer TOKEN_NICHT_HIER_EINTRAGEN" https://api.example.com/status ``` **Negotiate/Kerberos, sofern Build und Umgebung es unterstützen** ```text [TEST][SENS] curl --negotiate -u : https://example.com/protected ``` > Zugangsdaten, Tokens und Cookies dürfen nicht in BookStack-Seiten, Tickets oder allgemein lesbaren Skripten gespeichert werden.
--- **23. Wie werden Cookies untersucht?**
Cookie-Befehle anzeigen **Cookie direkt senden** ```text [TEST][SENS] curl -b "session=BEISPIELWERT" https://example.com/ ``` **Cookies aus Datei lesen** ```text [TEST][FILE][SENS] curl -b cookies.txt https://example.com/ ``` **Empfangene Cookies speichern** ```text [TEST][FILE][SENS] curl -c cookies.txt https://example.com/login ``` **Cookies lesen und aktualisiert wieder speichern** ```text [TEST][FILE][SENS] curl -b cookies.txt -c cookies.txt https://example.com/ ``` | Option | Bedeutung | |---|---| | `-b` beziehungsweise `--cookie` | Cookies senden oder aus Datei lesen | | `-c` beziehungsweise `--cookie-jar` | Empfangene Cookies speichern | Cookie-Dateien können aktive Sitzungen ermöglichen und sind daher sensible Zugangsdaten. **Typische Cookie-Probleme** - falsche Domain; - falscher Pfad; - `Secure`-Cookie über HTTP; - abgelaufenes Cookie; - SameSite-Verhalten; - Weiterleitung zu anderem Host; - mehrere Cookies mit gleichem Namen; - Anwendung erwartet zusätzliche CSRF-Token. curl bildet nicht jedes Browser-Sicherheitsverhalten vollständig identisch ab. Ein mit curl funktionierender Cookie-Test beweist daher nicht automatisch, dass eine Browseranwendung fehlerfrei arbeitet.
--- **24. Wie wird ein HTTP-Proxy getestet?**
Proxy-Diagnose anzeigen **HTTP-Proxy verwenden** ```text [TEST][SENS] curl -x http://proxy.example.com:8080 https://example.com/ ``` Langform: ```text [TEST][SENS] curl --proxy http://proxy.example.com:8080 https://example.com/ ``` **Proxy-Benutzername interaktiv verwenden** ```text [TEST][SENS] curl -x http://proxy.example.com:8080 -U "max.mustermann" https://example.com/ ``` **Proxy umgehen** ```text [TEST][SENS] curl --noproxy example.com https://example.com/ ``` **Proxy für alle Ziele umgehen** ```text [TEST][SENS] curl --noproxy "*" https://example.com/ ``` **Umgebungsvariablen prüfen** Linux und macOS: ```text [RO][SENS] env | grep -i proxy ``` PowerShell: ```powershell [RO][SENS] Get-ChildItem Env: | Where-Object Name -Match 'proxy' ``` Häufig verwendete Variablen: ```text http_proxy https_proxy all_proxy NO_PROXY no_proxy ``` **Wichtiger Sicherheitshinweis** Die Variable `http_proxy` wird von curl aus Sicherheitsgründen nur in Kleinschreibung akzeptiert. Andere Proxyvariablen können je nach Protokoll und Umgebung unterschiedliche Groß-/Kleinschreibungen unterstützen. **Direkt- und Proxytest vergleichen** Direkt: ```text [TEST][SENS] curl --noproxy "*" -v https://example.com/ ``` Über Proxy: ```text [TEST][SENS] curl -x http://proxy.example.com:8080 -v https://example.com/ ```
--- **25. Wie wird ein SOCKS-Proxy getestet?**
SOCKS4- und SOCKS5-Optionen anzeigen **SOCKS5-Proxy, DNS-Auflösung durch den Proxy** ```text [TEST][SENS] curl --socks5-hostname 192.0.2.50:1080 https://example.com/ ``` **SOCKS5-Proxy, lokale DNS-Auflösung** ```text [TEST][SENS] curl --socks5 192.0.2.50:1080 https://example.com/ ``` **SOCKS4a** ```text [TEST][SENS] curl --socks4a 192.0.2.50:1080 https://example.com/ ``` **Wichtiger Unterschied** | Option | DNS-Auflösung | |---|---| | `--socks5` | Lokal durch curl | | `--socks5-hostname` | Durch den SOCKS5-Proxy | | `--socks4` | Lokal | | `--socks4a` | Durch den Proxy | Der Unterschied ist wichtig, wenn: - interne DNS-Namen nur am Proxy auflösbar sind; - DNS-Leaks vermieden werden sollen; - lokale und entfernte DNS-Ergebnisse voneinander abweichen.
--- **26. Wie werden komprimierte Antworten geprüft?**
Kompression anzeigen ```text [TEST][SENS] curl --compressed -v https://example.com/ ``` Mit `--compressed` fordert curl eine unterstützte komprimierte Antwort an und dekomprimiert sie anschließend. In der Anfrage kann beispielsweise erscheinen: ```text Accept-Encoding: deflate, gzip, br, zstd ``` Die tatsächlich angebotenen Verfahren hängen vom curl-Build ab. **Header prüfen** ```text [TEST][SENS] curl --compressed -I https://example.com/ ``` Mögliche Antwort: ```text Content-Encoding: gzip ``` **Typische Probleme** - Proxy entfernt `Accept-Encoding`; - Server sendet falschen `Content-Length`; - Inhalt wird doppelt komprimiert; - Reverse Proxy und Anwendung komprimieren gleichzeitig; - bestimmte Kompressionsverfahren werden vom curl-Build nicht unterstützt.
--- **27. Wie werden lokale Unix-Sockets getestet?**
Unix-Domain-Socket-Diagnose anzeigen Auf Linux und anderen Unix-Systemen können HTTP-Dienste über einen Unix-Domain-Socket erreichbar sein. ```text [TEST][SENS] curl --unix-socket /run/example/app.sock http://localhost/health ``` curl verbindet sich dabei mit dem lokalen Socket. Der Hostname in der URL wird weiterhin für die HTTP-Anfrage verwendet. **Typische Einsatzbereiche** - Docker Engine API; - lokale Reverse-Proxy-Backends; - PHP-FPM-nahe Testdienste; - lokale Verwaltungs-APIs; - systemd-aktivierte Dienste. **Beispiel Docker-Socket** ```text [TEST][PRIV][SENS] curl --unix-socket /var/run/docker.sock http://localhost/_ping ``` > Zugriff auf `/var/run/docker.sock` entspricht auf vielen Systemen weitreichenden administrativen Rechten. Dieser Zugriff darf nicht leichtfertig vergeben oder in Container durchgereicht werden.
--- **28. Wie werden Wiederholungsversuche verwendet?**
Retry-Optionen anzeigen **Bis zu drei Wiederholungsversuche** ```text [TEST][SENS] curl --retry 3 https://example.com/ ``` **Maximale Gesamtzeit für Wiederholungen** ```text [TEST][SENS] curl --retry 3 --retry-max-time 30 https://example.com/ ``` **Feste Verzögerung zwischen Versuchen** ```text [TEST][SENS] curl --retry 3 --retry-delay 2 https://example.com/ ``` **Auch abgelehnte TCP-Verbindungen erneut versuchen** ```text [TEST][SENS] curl --retry 3 --retry-connrefused https://example.com/ ``` **Alle Fehler wiederholen** ```text [TEST][CHANGE][DISRUPT][SENS] curl --retry 3 --retry-all-errors https://example.com/ ``` `--retry-all-errors` darf bei ändernden Anfragen nicht unüberlegt verwendet werden. Ein POST, PUT oder DELETE könnte auf dem Server bereits verarbeitet worden sein, obwohl curl die Antwort nicht erhalten hat. Dadurch könnte eine Wiederholung: - eine Ressource doppelt anlegen; - eine Buchung doppelt ausführen; - eine Nachricht mehrfach senden; - einen Löschvorgang wiederholen. Wiederholungsversuche sind bei idempotenten GET- oder HEAD-Anfragen meist leichter zu bewerten als bei ändernden API-Aufrufen.
--- **29. Welche curl-Exitcodes sind für die Diagnose wichtig?**
Exitcode-Tabelle anzeigen | Exitcode | Bedeutung | |---:|---| | `0` | Vorgang aus Sicht von curl erfolgreich | | `3` | URL fehlerhaft | | `5` | Proxyname konnte nicht aufgelöst werden | | `6` | Hostname konnte nicht aufgelöst werden | | `7` | Verbindung zum Ziel konnte nicht hergestellt werden | | `22` | HTTP-Fehler bei Verwendung von `--fail` oder `--fail-with-body` | | `23` | Fehler beim Schreiben empfangener Daten | | `26` | Fehler beim Lesen lokaler Daten | | `28` | Zeitüberschreitung | | `35` | TLS-/SSL-Verbindungsfehler | | `47` | Zu viele Weiterleitungen | | `52` | Leere Serverantwort | | `55` | Fehler beim Senden von Netzwerkdaten | | `56` | Fehler beim Empfangen von Netzwerkdaten | | `60` | Zertifikat konnte nicht verifiziert werden | | `77` | Problem beim Lesen der CA-Zertifikatsdatei | | `92` | HTTP/2-Protokollfehler | Die vollständige Liste hängt von der curl-Version ab: ```text [RO] curl --manual ``` **Exitcode unter Linux und macOS anzeigen** ```text curl -sS --fail-with-body https://example.com/health echo $? ``` **Exitcode unter PowerShell anzeigen** ```powershell curl.exe -sS --fail-with-body https://example.com/health $LASTEXITCODE ``` **Wichtige Unterscheidung** ```text HTTP-Statuscode ≠ curl-Exitcode ``` Beispiel: ```text HTTP 404 ohne --fail → curl-Exitcode kann 0 sein HTTP 404 mit --fail → curl-Exitcode 22 ```
--- **30. Wie werden Fehler nach Diagnoseebene eingeordnet?**
Fehlerkette anzeigen | curl-Beobachtung | Wahrscheinliche Ebene | |---|---| | Exitcode 6 | DNS-Auflösung | | Exitcode 7 | TCP-Verbindung, Routing, Firewall oder Listener | | Exitcode 28 | DNS, Verbindung, Server oder Übertragung zu langsam | | Exitcode 35 | TLS-Handshake | | Exitcode 60 | Zertifikatsvertrauen oder Hostname | | HTTP 301/302 | Weiterleitung | | HTTP 401 | Authentifizierung | | HTTP 403 | Autorisierung, WAF oder Richtlinie | | HTTP 404 | URL, Routing oder Ressource | | HTTP 429 | Rate Limit | | HTTP 500 | Anwendung oder Backend | | HTTP 502 | Proxy/Gateway und Upstream | | HTTP 503 | Dienst nicht verfügbar oder Wartungszustand | | HTTP 504 | Gateway wartet vergeblich auf Upstream | | Verbindung funktioniert, Antwort langsam | Anwendung, Datenbank, Upstream oder Serverlast | | IP funktioniert, Name nicht | DNS | | `--resolve` funktioniert, normaler Aufruf nicht | DNS-Zuordnung oder Load-Balancer-Ziel | | `-k` funktioniert, normaler Test nicht | Zertifikatsprüfung | | IPv4 funktioniert, IPv6 nicht | IPv6-DNS, Routing, Firewall oder MTU | | Direkt funktioniert, Proxy nicht | Proxy, Authentifizierung oder Proxy-Richtlinie |
--- **31. Welche typischen Fehlinterpretationen gibt es?**
Praxisfallen anzeigen | Fehlinterpretation | Richtige Einordnung | |---|---| | `curl` ohne Fehler bedeutet HTTP 200 | Ohne `--fail` kann auch HTTP 404 oder 500 Exitcode 0 ergeben | | `-I` prüft exakt dasselbe wie GET | `-I` sendet bei HTTP eine HEAD-Anfrage | | `-k` behebt TLS | Es deaktiviert nur die Zertifikatsprüfung | | Aufruf über IP testet denselben virtuellen Host | Host-Header, SNI und Zertifikatsprüfung können abweichen | | Eigener `Host`-Header setzt automatisch SNI | TLS-SNI wird dadurch nicht zuverlässig angepasst | | `--resolve` verändert lokales DNS dauerhaft | Gilt nur für den jeweiligen curl-Aufruf | | `time_connect` ist nur die TCP-Dauer | Wert ist kumulativ seit Beginn des Aufrufs | | Hohe TTFB beweist Netzwerkproblem | Server, Anwendung oder Backend können langsam sein | | HTTP 403 bedeutet falsches Passwort | Authentifizierung kann korrekt sein, aber Zugriff ist verboten | | HTTP 502 ist immer der Webserver | Häufig meldet ein Gateway ein Upstream-Problem | | Bearer-Token in der Kommandozeile ist sicher | Token kann in Historie und Prozessinformationen erscheinen | | Verbose-Ausgabe kann bedenkenlos geteilt werden | Header, Cookies und Tokens können enthalten sein | | curl verhält sich wie ein Browser | JavaScript und Browserkontext fehlen | | Retry ist bei POST immer sicher | Änderung kann bereits verarbeitet worden sein | | Proxyvariable ist ausgeschlossen, weil `-x` fehlt | curl kann Proxyvariablen aus der Umgebung verwenden |
--- **32. Wie sieht ein systematischer curl-Diagnoseablauf aus?**
Empfohlene Schrittfolge anzeigen **Vorbereitung** 1. Erwartete URL, Methode und Antwort dokumentieren. 2. Hostname, IP-Adresse, Port und Protokoll bestimmen. 3. Prüfen, ob Proxy, VPN oder Load Balancer beteiligt sind. 4. Authentifizierung und Schutzbedarf der Daten klären. 5. Ändernde Anfragen nur gegen freigegebene Testressourcen richten. **Grundtest** 6. curl-Version und unterstützte Funktionen prüfen. 7. URL mit explizitem `https://` oder `http://` verwenden. 8. Verbindung mit `-v` untersuchen. 9. HTTP-Statuscode und effektive URL ausgeben. 10. Exitcode kontrollieren. **Eingrenzung** 11. IPv4 mit `-4` und IPv6 mit `-6` vergleichen. 12. DNS mit `--resolve` kontrolliert umgehen. 13. Direktverbindung und Proxyverbindung vergleichen. 14. Redirect-Kette mit `-L -I` prüfen. 15. TLS normal und höchstens vergleichsweise mit `-k` testen. 16. HTTP/1.1 und HTTP/2 bei Bedarf vergleichen. 17. DNS-, TCP-, TLS-, TTFB- und Gesamtzeit messen. **Anwendung** 18. Header und Content-Type prüfen. 19. Erwartete HTTP-Methode verwenden. 20. Request-Body und Zeichenkodierung kontrollieren. 21. Authentifizierung ohne Offenlegung der Zugangsdaten testen. 22. API-Antwort und Serverlogs zeitlich vergleichen. **Validierung** 23. Ergebnis aus einem zweiten Netzwerksegment vergleichen. 24. Reverse-Proxy-, Firewall- und Anwendungslogs prüfen. 25. Bei Netzwerkverdacht Paketmitschnitt erstellen. 26. Nach einer Änderung denselben curl-Befehl erneut ausführen. 27. Befehl, Zeitpunkt, Exitcode, HTTP-Status und Zeiten dokumentieren. 28. Diagnoseausgaben vor Weitergabe von Secrets bereinigen.
--- **33. Kurzreferenz – häufige curl-Befehle**
Befehlstabelle anzeigen | Aufgabe | Linux/macOS | |---|---| | Version | `[RO] curl --version` | | Seite abrufen | `[TEST][SENS] curl https://example.com/` | | Nur HEAD-Anfrage | `[TEST][SENS] curl -I https://example.com/` | | Header und Inhalt | `[TEST][SENS] curl -i https://example.com/` | | Ausführliche Diagnose | `[TEST][SENS] curl -v https://example.com/` | | Redirects verfolgen | `[TEST][SENS] curl -L https://example.com/` | | Statuscode | `[TEST] curl -sS -o /dev/null -w "%{http_code}\n" https://example.com/` | | HTTP-Fehler als Fehler behandeln | `[TEST] curl -sS --fail-with-body https://example.com/` | | Connect-Timeout | `[TEST] curl --connect-timeout 5 https://example.com/` | | Gesamttimeout | `[TEST] curl --max-time 15 https://example.com/` | | IPv4 | `[TEST] curl -4 https://example.com/` | | IPv6 | `[TEST] curl -6 https://example.com/` | | DNS temporär überschreiben | `[TEST][SENS] curl --resolve example.com:443:192.0.2.20 https://example.com/` | | Bestimmte CA-Datei | `[TEST][FILE][SENS] curl --cacert company-ca.pem https://example.com/` | | HTTP/1.1 | `[TEST] curl --http1.1 https://example.com/` | | HTTP/2 | `[TEST] curl --http2 https://example.com/` | | JSON senden | `[TEST][CHANGE][SENS] curl -H "Content-Type: application/json" -d '{"active":true}' https://api.example.com/item` | | Datei herunterladen | `[TEST][FILE][SENS] curl -o file.bin https://example.com/file.bin` | | Proxy verwenden | `[TEST][SENS] curl -x http://proxy.example.com:8080 https://example.com/` | | Proxy umgehen | `[TEST][SENS] curl --noproxy "*" https://example.com/` | | Trace erstellen | `[TEST][FILE][SENS] curl --trace-time --trace-ascii curl-trace.txt https://example.com/` | **Windows verwendet dieselbe Optionssyntax, aber eindeutig `curl.exe` und `NUL` statt `/dev/null`:** ```powershell [TEST] curl.exe -sS -o NUL -w "HTTP=%{http_code} Zeit=%{time_total}s\n" https://example.com/ ```
--- **34. Kurzreferenz – wichtigste Optionen**
Optionstabelle anzeigen | Option | Bedeutung | |---|---| | `-V`, `--version` | Version und Build-Funktionen anzeigen | | `-v`, `--verbose` | Ausführliche Verbindungsinformationen | | `-I`, `--head` | Bei HTTP HEAD-Anfrage senden | | `-i`, `--show-headers` | Antwortheader zusammen mit Inhalt anzeigen | | `-D`, `--dump-header` | Antwortheader separat schreiben | | `-o`, `--output` | Antwortinhalt in Datei schreiben | | `-O`, `--remote-name` | Remote-Dateinamen verwenden | | `-s`, `--silent` | Fortschritts- und normale Fehlermeldungen unterdrücken | | `-S`, `--show-error` | Fehler trotz `--silent` anzeigen | | `-f`, `--fail` | HTTP-Fehler als curl-Fehler behandeln | | `--fail-with-body` | HTTP-Fehler melden und Inhalt behalten | | `-L`, `--location` | Weiterleitungen verfolgen | | `--max-redirs` | Anzahl der Weiterleitungen begrenzen | | `-w`, `--write-out` | Messwerte und Metadaten ausgeben | | `--connect-timeout` | Verbindungszeit begrenzen | | `-m`, `--max-time` | Gesamtdauer begrenzen | | `-4` | IPv4 erzwingen | | `-6` | IPv6 erzwingen | | `--resolve` | Temporäre Host-/Port-/IP-Zuordnung | | `--connect-to` | Tatsächliches Verbindungsziel ändern | | `-k`, `--insecure` | Zertifikatsprüfung deaktivieren | | `--cacert` | Bestimmte CA-Datei verwenden | | `--cert` | Clientzertifikat verwenden | | `--key` | Privaten Schlüssel verwenden | | `--tlsv1.2` | Mindestens TLS 1.2 | | `--tls-max` | Maximale TLS-Version | | `--http1.1` | HTTP/1.1 verwenden | | `--http2` | HTTP/2 anfordern | | `--http3` | HTTP/3 versuchen | | `-H`, `--header` | Request-Header setzen | | `-A`, `--user-agent` | User-Agent setzen | | `-d`, `--data` | Request-Daten senden | | `--data-binary` | Daten weitgehend unverändert senden | | `--data-urlencode` | Daten URL-codieren | | `--json` | JSON-Daten senden | | `-X`, `--request` | HTTP-Methode ausdrücklich festlegen | | `-u`, `--user` | Serverauthentifizierung | | `-U`, `--proxy-user` | Proxyauthentifizierung | | `-b`, `--cookie` | Cookies senden beziehungsweise lesen | | `-c`, `--cookie-jar` | Cookies speichern | | `-x`, `--proxy` | Proxy verwenden | | `--noproxy` | Proxy für Ziele umgehen | | `--compressed` | Komprimierte Antwort anfordern | | `--retry` | Wiederholungsversuche | | `--trace-ascii` | Lesbaren Trace schreiben | | `--trace-time` | Trace mit Zeitstempeln versehen |
--- **Merksätze** - Unter Windows für echte curl-Syntax ausdrücklich `curl.exe` verwenden. - Eine empfangene HTTP-Fehlerseite kann ohne `--fail` trotzdem curl-Exitcode 0 ergeben. - HTTP-Statuscode und curl-Exitcode beantworten unterschiedliche Fragen. - `-I` sendet bei HTTP eine HEAD-Anfrage und ist nicht identisch mit einem GET-Test. - `-v` zeigt DNS, TCP, TLS und HTTP, kann aber sensible Header enthalten. - `--resolve` umgeht DNS für den Test und erhält Hostname, HTTP-Host, TLS-SNI und Zertifikatsprüfung. - Ein Aufruf über die reine IP-Adresse kann einen anderen virtuellen Host erreichen. - `-k` deaktiviert die Zertifikatsprüfung und behebt kein TLS-Problem. - `time_connect`, `time_appconnect` und `time_starttransfer` sind kumulative Zeitwerte. - Eine hohe TTFB kann durch Anwendung, Datenbank, Proxy oder Backend entstehen. - Bei UDP-basiertem HTTP/3 können andere Fehler als bei HTTP/1.1 oder HTTP/2 auftreten. - Proxyvariablen können einen curl-Aufruf beeinflussen, auch wenn kein `-x` angegeben wurde. - Zugangsdaten, Cookies und Tokens gehören nicht in Dokumentationen oder gemeinsam lesbare Skripte. - POST-, PUT-, PATCH- und DELETE-Anfragen können Daten verändern und benötigen besondere Vorsicht. - curl ist ein präzises Protokollwerkzeug, aber kein vollständiger Webbrowser. --- **Quellen** - [Offizielle curl-Manpage](https://curl.se/docs/manpage.html) - [Offizielle curl-Dokumentationsübersicht](https://curl.se/docs/) - [Everything curl – Command Line Transfers](https://everything.curl.dev/usingcurl/) - [Everything curl – Verbose Operations](https://everything.curl.dev/usingcurl/verbose/) - [Everything curl – Name Resolve Tricks](https://everything.curl.dev/usingcurl/connections/name.html) - [Everything curl – HTTP Responses](https://everything.curl.dev/http/response.html) - [Everything curl – Proxies](https://everything.curl.dev/usingcurl/proxies/index.html) - [curl – Exit Codes](https://curl.se/libcurl/c/libcurl-errors.html) - [curl – SSL Certificate Verification](https://curl.se/docs/sslcerts.html) - [curl – Supported Protocols](https://curl.se/docs/manpage.html#PROTOCOLS) # 2.10 OpenSSL – TLS-Verbindungen, Zertifikate und Zertifikatsketten prüfen **Ziel dieser Seite** OpenSSL ist eine Sammlung von Werkzeugen und Bibliotheken für Kryptografie, Zertifikate und TLS. In der Fehleranalyse wird der Befehl `openssl` unter anderem verwendet, um: - TLS-Verbindungen direkt zu einem Server aufzubauen; - TLS-Version und Cipher Suite zu erkennen; - Server Name Indication, kurz SNI, gezielt zu testen; - Zertifikate eines Servers anzuzeigen; - Zertifikatsketten zu untersuchen; - Zertifikatsnamen und Subject Alternative Names zu prüfen; - Gültigkeitszeiträume zu kontrollieren; - interne Zertifizierungsstellen einzubeziehen; - STARTTLS bei SMTP, IMAP, POP3 und LDAP zu testen; - Clientzertifikate für mTLS-Verbindungen zu verwenden; - Zertifikate, private Schlüssel und CSRs zu untersuchen; - zu prüfen, ob Zertifikat und privater Schlüssel zusammengehören; - PEM-, DER- und PKCS#12-Dateien zu unterscheiden; - Fehler zwischen TCP, TLS, Zertifikat und Anwendung einzugrenzen. > OpenSSL kann private Schlüssel und andere hochsensible kryptografische Daten verarbeiten. Befehle mit privaten Schlüsseln dürfen nur auf autorisierten Systemen und in geschützten Verzeichnissen ausgeführt werden. --- **Kennzeichnungen** | Kennzeichnung | Bedeutung | |---|---| | `[RO]` | Nur lesende lokale Prüfung | | `[TEST]` | Aktiver Netzwerk- oder TLS-Test | | `[PRIV]` | Erhöhte Berechtigungen können erforderlich sein | | `[FILE]` | Befehl liest oder erstellt eine Datei | | `[SENS]` | Ausgabe oder Datei enthält möglicherweise sensible Informationen | | `[CHANGE]` | Befehl erstellt oder verändert Dateien | | `[DISRUPT]` | Test kann Dienst, Sitzung oder produktive Daten beeinflussen | --- **1. Wie wird die OpenSSL-Version geprüft?**
Versions- und Buildinformationen anzeigen | Aufgabe | Windows | Linux | macOS | |---|---|---|---| | Programmpfad | `[RO] Get-Command openssl.exe` | `[RO] command -v openssl` | `[RO] command -v openssl` | | Version | `[RO] openssl.exe version` | `[RO] openssl version` | `[RO] openssl version` | | Ausführliche Version | `[RO] openssl.exe version -a` | `[RO] openssl version -a` | `[RO] openssl version -a` | | Befehlsübersicht | `[RO] openssl.exe help` | `[RO] openssl help` | `[RO] openssl help` | | Hilfe zu `s_client` | `[RO] openssl.exe s_client -help` | `[RO] openssl s_client -help` | `[RO] openssl s_client -help` | **Ausführliche Buildinformationen** ```text [RO] openssl version -a ``` Die Ausgabe kann unter anderem enthalten: - OpenSSL- oder LibreSSL-Version; - Erstellungsdatum; - Zielplattform; - Konfigurationsverzeichnis; - Provider- und Modulpfade; - Compileroptionen; - CPU-Funktionen. **Betriebssystemspezifische Hinweise** | Betriebssystem | Hinweis | |---|---| | Windows | OpenSSL ist kein allgemeines Windows-Bordmittel und muss aus einer vertrauenswürdigen Quelle stammen oder mit einer Anwendung mitgeliefert werden | | Linux | Version und Konfiguration hängen von Distribution und Paketstand ab | | macOS | Der Befehl `openssl` kann je nach Installation LibreSSL oder eine separat installierte OpenSSL-Version aufrufen | | Container | Der Container kann eine andere OpenSSL-Version als der Host verwenden | OpenSSL und LibreSSL sind nicht vollständig optionskompatibel. Vor der Übernahme eines Befehls muss deshalb geprüft werden: ```text openssl version openssl s_client -help ```
--- **2. Wie wird eine grundlegende TLS-Verbindung getestet?**
Verbindung mit `s_client` anzeigen ```text [TEST][SENS] openssl s_client -connect example.com:443 ``` Der Befehl baut eine TCP-Verbindung zu Port 443 auf und startet anschließend einen TLS-Handshake. **Mit ausdrücklich gesetztem SNI** ```text [TEST][SENS] openssl s_client -connect example.com:443 -servername example.com ``` `-servername` setzt die TLS-Erweiterung Server Name Indication. **Kompakte Ausgabe, sofern von der installierten Version unterstützt** ```text [TEST][SENS] openssl s_client -connect example.com:443 -servername example.com -brief ``` **Verbindung beenden** Nach dem TLS-Handshake wartet `s_client` häufig auf weitere Eingaben. Die Sitzung kann normalerweise mit folgender Tastenkombination beendet werden: ```text [Strg] + [C] ``` Neuere OpenSSL-Versionen unterstützen einen nicht interaktiven Modus: ```text [TEST][SENS] openssl s_client -connect example.com:443 -servername example.com -no-interactive ``` Vor Verwendung muss geprüft werden: ```text [RO] openssl s_client -help ``` **Wichtige Ausgabeinformationen** - Ziel-IP und Zielport; - Serverzertifikat; - Zertifikatskette; - TLS-Version; - Cipher Suite; - Schlüsselaustausch; - Signaturalgorithmus; - ALPN-Ergebnis; - Zertifikatsprüfergebnis; - Sitzungsinformationen.
--- **3. Warum muss SNI ausdrücklich berücksichtigt werden?**
SNI und virtuelle Hosts erklären Mehrere HTTPS-Dienste können dieselbe IP-Adresse und denselben Port verwenden: ```text 192.0.2.20:443 ├── wiki.example.com ├── mail.example.com └── api.example.com ``` Der Client teilt dem Server während des TLS-Handshakes mit, welchen Hostnamen er erreichen möchte. Das geschieht über SNI. **Wiki prüfen** ```text [TEST][SENS] openssl s_client -connect 192.0.2.20:443 -servername wiki.example.com ``` **API prüfen** ```text [TEST][SENS] openssl s_client -connect 192.0.2.20:443 -servername api.example.com ``` Der Server kann abhängig vom SNI-Namen unterschiedliche Zertifikate zurückgeben. **Ohne SNI** ```text [TEST][SENS] openssl s_client -connect 192.0.2.20:443 -noservername ``` Mögliche Folgen: - Standardzertifikat des Reverse Proxys; - Zertifikat eines anderen virtuellen Hosts; - TLS-Abbruch; - falsche Anwendung; - irreführender Zertifikatsnamensfehler. > Ein Test gegen eine IP-Adresse ohne passenden SNI-Namen bildet den Zugriff eines normalen Browsers auf einen DNS-Namen nicht zuverlässig nach.
--- **4. Wie wird ein TLS-Server über eine bestimmte IP-Adresse getestet?**
Ziel-IP und Hostname getrennt prüfen Angenommen: ```text Hostname: wiki.example.com Test-IP: 192.0.2.20 Port: 443 ``` **Direkter TLS-Test gegen diese IP mit richtigem SNI** ```text [TEST][SENS] openssl s_client -connect 192.0.2.20:443 -servername wiki.example.com ``` Dadurch wird: - die DNS-Auflösung für die Verbindung umgangen; - die Verbindung direkt zu `192.0.2.20` aufgebaut; - SNI auf `wiki.example.com` gesetzt. Für eine vollständige Hostnamenprüfung sollte zusätzlich verwendet werden: ```text [TEST][SENS] openssl s_client -connect 192.0.2.20:443 -servername wiki.example.com -verify_hostname wiki.example.com -verify_return_error ``` **Vergleich mit curl** ```text [TEST][SENS] curl --resolve wiki.example.com:443:192.0.2.20 https://wiki.example.com/ ``` OpenSSL untersucht hauptsächlich TLS und Zertifikate. curl führt zusätzlich eine HTTP-Anfrage aus.
--- **5. Was bedeutet eine erfolgreiche TLS-Verbindung?**
Handshake, Zertifikat und Anwendung unterscheiden Ein erfolgreicher TLS-Handshake beweist zunächst: - TCP-Verbindung wurde hergestellt; - Client und Server fanden eine gemeinsame TLS-Version; - Client und Server fanden geeignete kryptografische Parameter; - der Server konnte ein Zertifikat oder anderes benötigtes Material bereitstellen; - verschlüsselte Kommunikation konnte grundsätzlich beginnen. Er beweist nicht automatisch: - dass der Zertifikatsname richtig ist; - dass die Zertifikatskette vertrauenswürdig ist; - dass das Zertifikat nicht abgelaufen ist; - dass die Anwendung funktioniert; - dass HTTP einen erfolgreichen Statuscode liefert; - dass eine Benutzeranmeldung möglich ist; - dass eine Sperrprüfung erfolgreich war. **Diagnoseebenen** ```text DNS ↓ TCP ↓ TLS-Handshake ↓ Zertifikatsprüfung ↓ HTTP oder anderes Anwendungsprotokoll ↓ Anwendung ``` Für HTTPS sollte nach dem OpenSSL-Test zusätzlich eine HTTP-Prüfung erfolgen: ```text [TEST][SENS] curl -v https://wiki.example.com/ ```
--- **6. Warum kann `s_client` trotz Zertifikatsfehler eine Verbindung fortsetzen?**
Wichtige Besonderheit der Zertifikatsprüfung anzeigen `openssl s_client` ist ein Diagnosewerkzeug. Standardmäßig kann es nach Zertifikatsprüffehlern fortfahren, damit weitere Probleme sichtbar werden. Eine Ausgabe wie: ```text verify error:num=20:unable to get local issuer certificate ``` bedeutet deshalb nicht zwingend, dass der TLS-Handshake sofort abgebrochen wird. **Bei Zertifikatsfehlern wirklich abbrechen** ```text [TEST][SENS] openssl s_client -connect example.com:443 -servername example.com -verify_return_error ``` **Zusätzlich Hostnamen prüfen** ```text [TEST][SENS] openssl s_client -connect example.com:443 -servername example.com -verify_hostname example.com -verify_return_error ``` **Erwartetes positives Ergebnis** ```text Verification: OK ``` oder in der ausführlichen Ausgabe: ```text Verify return code: 0 (ok) ``` **Wichtig** ```text TLS-Handshake abgeschlossen ≠ Zertifikat erfolgreich validiert ``` Für eine belastbare Prüfung müssen mindestens berücksichtigt werden: - `-verify_return_error`; - der erwartete Hostname; - der richtige Vertrauensspeicher; - die vollständige Zertifikatskette.
--- **7. Wie wird der Zertifikatsname geprüft?**
Hostname und IP-Adresse validieren **DNS-Hostname prüfen** ```text [TEST][SENS] openssl s_client -connect example.com:443 -servername example.com -verify_hostname example.com -verify_return_error ``` **Verbindung gegen IP, aber DNS-Namen prüfen** ```text [TEST][SENS] openssl s_client -connect 192.0.2.20:443 -servername wiki.example.com -verify_hostname wiki.example.com -verify_return_error ``` **IP-Adresse als Zertifikatsidentität prüfen** ```text [TEST][SENS] openssl s_client -connect 192.0.2.20:443 -verify_ip 192.0.2.20 -verify_return_error ``` Ein Zertifikat muss die IP-Adresse dafür als IP-Eintrag im Subject Alternative Name enthalten. Ein DNS-Name oder ein Common Name mit einer IP-ähnlichen Zeichenfolge ist dafür nicht automatisch ausreichend. **Zu unterscheiden** | Option | Aufgabe | |---|---| | `-connect` | Tatsächliches Netzwerkziel | | `-servername` | Im TLS-Handshake gesendeter SNI-Name | | `-verify_hostname` | Erwartete DNS-Identität im Zertifikat | | `-verify_ip` | Erwartete IP-Identität im Zertifikat | Diese Werte können bei gezielten Tests unterschiedlich sein.
--- **8. Wie wird die vom Server gesendete Zertifikatsliste angezeigt?**
Zertifikate mit `-showcerts` anzeigen ```text [TEST][SENS] openssl s_client -connect example.com:443 -servername example.com -showcerts ``` `-showcerts` zeigt die Zertifikate so an, wie der Server sie übermittelt hat. Typische Reihenfolge: ```text 1. Server-/Leaf-Zertifikat 2. Zwischenzertifikat 3. weiteres Zwischenzertifikat ``` Ein Root-Zertifikat wird von einem TLS-Server normalerweise nicht mitgesendet, weil es bereits im Vertrauensspeicher des Clients vorhanden sein soll. **Wichtiger Hinweis** Die Ausgabe von `-showcerts` ist: - die vom Server gesendete Zertifikatsliste; - nicht automatisch eine erfolgreich validierte Kette; - nicht zwingend vollständig; - nicht zwingend in einer brauchbaren Vertrauenskette angeordnet; - kein Beweis, dass alle Zertifikate vertrauenswürdig sind. **Typischer Fehler** ```text Server sendet nur Leaf-Zertifikat → Client kann Aussteller möglicherweise nicht finden → unable to get local issuer certificate ```
--- **9. Wie wird ein Serverzertifikat in eine Datei übernommen?**
Leaf-Zertifikat extrahieren Unter Linux und macOS kann das erste vom Server ausgegebene Zertifikat an `openssl x509` weitergegeben werden: ```text [TEST][FILE][SENS] openssl s_client -connect example.com:443 -servername example.com /dev/null | openssl x509 -outform PEM > server-cert.pem ``` Anschließend prüfen: ```text [RO][FILE][SENS] openssl x509 -in server-cert.pem -noout -subject -issuer -dates ``` **Wichtig** Diese Pipeline übernimmt normalerweise das erste PEM-Zertifikat aus der Ausgabe und damit üblicherweise das Leaf-Zertifikat. Sie speichert nicht automatisch die vollständige Zertifikatskette. Für die vollständige Kette sollte die Ausgabe von `-showcerts` kontrolliert und jedes Zertifikat eindeutig getrennt gespeichert werden. **Unter Windows** Shell-Pipelines und Umleitungen unterscheiden sich zwischen: - PowerShell; - Eingabeaufforderung; - Git Bash; - WSL. Daher sollte unter Windows zunächst die Ausgabe kontrolliert in eine Datei geschrieben und das gewünschte PEM-Zertifikat anschließend eindeutig extrahiert werden. Binärdaten und private Schlüssel dürfen nicht unkontrolliert durch Textkonvertierungen einer Shell verändert werden.
--- **10. Wie wird ein lokales Zertifikat vollständig angezeigt?**
Zertifikatsinhalt mit `openssl x509` anzeigen ```text [RO][FILE][SENS] openssl x509 -in server-cert.pem -noout -text ``` **Kompakte Kerninformationen** ```text [RO][FILE][SENS] openssl x509 -in server-cert.pem -noout -subject -issuer -serial -dates ``` **SHA-256-Fingerabdruck** ```text [RO][FILE][SENS] openssl x509 -in server-cert.pem -noout -fingerprint -sha256 ``` **Public-Key-Information** ```text [RO][FILE][SENS] openssl x509 -in server-cert.pem -noout -pubkey ``` **Wichtige Zertifikatsfelder** | Feld | Bedeutung | |---|---| | Subject | Identität des Zertifikatsinhabers | | Issuer | Ausstellende Zertifizierungsstelle | | Serial Number | Seriennummer des Zertifikats | | Not Before | Beginn der Gültigkeit | | Not After | Ende der Gültigkeit | | Public Key Algorithm | Typ des öffentlichen Schlüssels | | Signature Algorithm | Signaturalgorithmus der CA | | Subject Alternative Name | Gültige DNS-Namen, IP-Adressen oder andere Identitäten | | Key Usage | Zulässige grundlegende Schlüsselverwendungen | | Extended Key Usage | Beispielsweise TLS Web Server Authentication | | Basic Constraints | Kennzeichnung als Endzertifikat oder CA-Zertifikat | | Authority Information Access | Hinweise auf Aussteller und OCSP | | CRL Distribution Points | Verweise auf Sperrlisten |
--- **11. Wie werden Subject Alternative Names angezeigt?**
SAN-Felder prüfen ```text [RO][FILE][SENS] openssl x509 -in server-cert.pem -noout -ext subjectAltName ``` Beispiel: ```text X509v3 Subject Alternative Name: DNS:example.com, DNS:www.example.com, DNS:api.example.com ``` **Weitere Erweiterungen** ```text [RO][FILE][SENS] openssl x509 -in server-cert.pem -noout -ext keyUsage ``` ```text [RO][FILE][SENS] openssl x509 -in server-cert.pem -noout -ext extendedKeyUsage ``` ```text [RO][FILE][SENS] openssl x509 -in server-cert.pem -noout -ext basicConstraints ``` ```text [RO][FILE][SENS] openssl x509 -in server-cert.pem -noout -ext authorityInfoAccess ``` **Wichtig** Moderne TLS-Clients prüfen die Identität hauptsächlich anhand von Subject Alternative Name. Der Common Name allein sollte nicht als verlässlicher Ersatz für fehlende SAN-Einträge betrachtet werden.
--- **12. Wie wird die Gültigkeitsdauer eines Zertifikats geprüft?**
Start-, Ablaufdatum und Restlaufzeit anzeigen **Gültigkeitszeitraum anzeigen** ```text [RO][FILE][SENS] openssl x509 -in server-cert.pem -noout -dates ``` Ausgabe: ```text notBefore=... notAfter=... ``` **Nur Ablaufdatum** ```text [RO][FILE][SENS] openssl x509 -in server-cert.pem -noout -enddate ``` **Prüfen, ob das Zertifikat mindestens noch 30 Tage gültig ist** ```text [RO][FILE][SENS] openssl x509 -in server-cert.pem -noout -checkend 2592000 ``` Berechnung: ```text 30 Tage × 24 Stunden × 60 Minuten × 60 Sekunden = 2.592.000 Sekunden ``` **Exitcode auswerten** Linux und macOS: ```text openssl x509 -in server-cert.pem -noout -checkend 2592000 echo $? ``` PowerShell: ```powershell openssl.exe x509 -in server-cert.pem -noout -checkend 2592000 $LASTEXITCODE ``` | Exitcode | Bedeutung | |---:|---| | `0` | Zertifikat ist über den angegebenen Zeitraum hinaus gültig | | ungleich `0` | Zertifikat läuft innerhalb des Zeitraums ab oder ist bereits abgelaufen | Zusätzlich muss die lokale Systemzeit korrekt sein. Eine falsche Uhr kann gültige Zertifikate als noch nicht gültig oder abgelaufen erscheinen lassen.
--- **13. Wie wird eine Zertifikatskette lokal geprüft?**
Kettenprüfung mit `openssl verify` anzeigen Angenommene Dateien: ```text server-cert.pem intermediate-ca.pem root-ca.pem ``` **Kette prüfen** ```text [RO][FILE][SENS] openssl verify -CAfile root-ca.pem -untrusted intermediate-ca.pem server-cert.pem ``` Erwartetes Ergebnis: ```text server-cert.pem: OK ``` **Zusätzlich Hostnamen prüfen** ```text [RO][FILE][SENS] openssl verify -CAfile root-ca.pem -untrusted intermediate-ca.pem -verify_hostname wiki.example.com server-cert.pem ``` **Für TLS-Serverzweck prüfen** ```text [RO][FILE][SENS] openssl verify -CAfile root-ca.pem -untrusted intermediate-ca.pem -purpose sslserver server-cert.pem ``` **Bedeutung** | Option | Aufgabe | |---|---| | `-CAfile root-ca.pem` | Vertrauensanker | | `-untrusted intermediate-ca.pem` | Nicht direkt vertrautes Zwischenzertifikat zur Kettenbildung | | `-verify_hostname` | Erwarteten DNS-Namen prüfen | | `-purpose sslserver` | Eignung für TLS-Server prüfen | Das Zwischenzertifikat wird mit `-untrusted` zur Kettenbildung bereitgestellt. Dadurch wird es nicht automatisch selbst zum Vertrauensanker.
--- **14. Welche typischen Fehler der Zertifikatskette gibt es?**
Verify-Fehler einordnen | Fehlermeldung | Mögliche Bedeutung | |---|---| | `unable to get local issuer certificate` | Aussteller oder Zwischenzertifikat fehlt beziehungsweise ist nicht auffindbar | | `unable to verify the first certificate` | Kette kann vom Leaf-Zertifikat nicht zu einem vertrauten Root aufgebaut werden | | `self-signed certificate` | Zertifikat ist selbstsigniert und nicht als vertrauenswürdig hinterlegt | | `self-signed certificate in certificate chain` | Selbstsigniertes Zertifikat in der Kette ist nicht als Vertrauensanker akzeptiert | | `certificate has expired` | Zertifikat liegt nach `notAfter` | | `certificate is not yet valid` | Systemzeit liegt vor `notBefore` | | `hostname mismatch` | Erwarteter Name passt nicht zum Zertifikat | | `invalid CA certificate` | Zertifikat ist nicht korrekt als CA verwendbar | | `path length constraint exceeded` | CA-Pfadlängenbegrenzung verletzt | | `unsupported certificate purpose` | Zertifikat ist nicht für den geprüften Zweck vorgesehen | | `certificate signature failure` | Signatur konnte nicht korrekt bestätigt werden | **Prüfreihenfolge** 1. Leaf-Zertifikat untersuchen. 2. Issuer des Leaf-Zertifikats bestimmen. 3. Passendes Zwischenzertifikat prüfen. 4. Issuer und Subject der Kettenglieder vergleichen. 5. CA-Eigenschaften kontrollieren. 6. Vertrauensanker eindeutig festlegen. 7. Gültigkeitszeiten aller Zertifikate prüfen. 8. Hostnamen und Verwendungszweck prüfen.
--- **15. Wie wird eine interne Zertifizierungsstelle verwendet?**
Eigene CA für einen einzelnen Test angeben **TLS-Verbindung mit eigener CA-Datei prüfen** ```text [TEST][FILE][SENS] openssl s_client -connect wiki.example.com:443 -servername wiki.example.com -verify_hostname wiki.example.com -verify_return_error -CAfile company-root-ca.pem ``` **Lokales Zertifikat prüfen** ```text [RO][FILE][SENS] openssl verify -CAfile company-root-ca.pem -untrusted company-intermediate-ca.pem -verify_hostname wiki.example.com server-cert.pem ``` **Wichtig** Die Angabe von `-CAfile` gilt für diesen OpenSSL-Aufruf. Sie installiert die CA nicht automatisch in: - Windows-Zertifikatspeicher; - macOS-Schlüsselbund; - Linux-Systemvertrauensspeicher; - Browser-Vertrauensspeicher; - Java-KeyStore; - Container-Images. Ein erfolgreicher OpenSSL-Test mit eigener CA-Datei beweist deshalb nicht, dass alle Anwendungen dieser CA vertrauen.
--- **16. Wie werden TLS 1.2 und TLS 1.3 getrennt getestet?**
Protokollversionen anzeigen **Ausschließlich TLS 1.2** ```text [TEST][SENS] openssl s_client -connect example.com:443 -servername example.com -tls1_2 ``` **Ausschließlich TLS 1.3** ```text [TEST][SENS] openssl s_client -connect example.com:443 -servername example.com -tls1_3 ``` **Minimalversion festlegen, sofern unterstützt** ```text [TEST][SENS] openssl s_client -connect example.com:443 -servername example.com -min_protocol TLSv1.2 ``` **Maximalversion festlegen** ```text [TEST][SENS] openssl s_client -connect example.com:443 -servername example.com -max_protocol TLSv1.2 ``` **Interpretation** | TLS 1.2 | TLS 1.3 | Mögliche Aussage | |---|---|---| | Erfolgreich | Erfolgreich | Beide Versionen werden unterstützt | | Erfolgreich | Fehler | Server, Proxy oder Client unterstützt TLS 1.3 nicht oder blockiert es | | Fehler | Erfolgreich | Server erlaubt möglicherweise nur TLS 1.3 | | Beide Fehler | TCP, SNI, Zertifikat, Cipher oder Dienst prüfen | Ein Versionsfehler kann auch durch einen zwischengeschalteten Proxy, Load Balancer oder TLS-Inspection-Dienst verursacht werden.
--- **17. Wie werden Cipher Suites geprüft?**
Cipher-Informationen anzeigen **Verfügbare Cipher Suites des lokalen OpenSSL-Builds** ```text [RO] openssl ciphers -v ``` **Nur TLS-1.2-kompatible Auswahl untersuchen** ```text [RO] openssl ciphers -v -tls1_2 ``` **Nur TLS-1.3-Cipher-Suites anzeigen, sofern unterstützt** ```text [RO] openssl ciphers -v -tls1_3 ``` **Bestimmte TLS-1.2-Cipher-Auswahl testen** ```text [TEST][SENS] openssl s_client -connect example.com:443 -servername example.com -tls1_2 -cipher 'ECDHE-RSA-AES128-GCM-SHA256' ``` **Bestimmte TLS-1.3-Cipher-Suite testen** ```text [TEST][SENS] openssl s_client -connect example.com:443 -servername example.com -tls1_3 -ciphersuites 'TLS_AES_128_GCM_SHA256' ``` **Wichtiger Unterschied** | Option | Gilt hauptsächlich für | |---|---| | `-cipher` | TLS 1.2 und älter | | `-ciphersuites` | TLS 1.3 | Die tatsächlich verfügbaren Cipher Suites hängen von: - OpenSSL-Version; - aktivierten Providern; - Sicherheitsstufe; - Betriebssystempaket; - Build-Konfiguration; - kryptografischer Richtlinie ab. > Eine einzelne funktionierende Cipher Suite beweist nicht, dass die gesamte TLS-Konfiguration sicher oder vollständig kompatibel ist.
--- **18. Wie wird ALPN für HTTP/2 und HTTP/1.1 geprüft?**
ALPN-Aushandlung anzeigen **HTTP/2 und HTTP/1.1 anbieten** ```text [TEST][SENS] openssl s_client -connect example.com:443 -servername example.com -alpn 'h2,http/1.1' ``` Mögliche Ausgabe: ```text ALPN protocol: h2 ``` oder: ```text ALPN protocol: http/1.1 ``` **Nur HTTP/2 anbieten** ```text [TEST][SENS] openssl s_client -connect example.com:443 -servername example.com -alpn h2 ``` **Interpretation** | Ergebnis | Bedeutung | |---|---| | `h2` | Server und Client einigten sich auf HTTP/2 | | `http/1.1` | HTTP/1.1 wurde gewählt | | Keine ALPN-Aushandlung | Server, Proxy oder OpenSSL-Build unterstützt beziehungsweise verwendet ALPN nicht | | TLS-Abbruch | Protokoll-, Cipher-, SNI- oder Richtlinienproblem möglich | ALPN bestimmt das Anwendungsprotokoll innerhalb der TLS-Verbindung. OpenSSL `s_client` führt danach nicht automatisch eine vollständige HTTP/2-Anfrage aus. Für den Anwendungstest: ```text [TEST][SENS] curl --http2 -v https://example.com/ ```
--- **19. Wie wird OCSP Stapling geprüft?**
OCSP-Statusantwort anzeigen ```text [TEST][SENS] openssl s_client -connect example.com:443 -servername example.com -status ``` Die Option fordert während des TLS-Handshakes eine gestapelte OCSP-Antwort an. Mögliche Ausgabe: ```text OCSP response: ... Cert Status: good ``` **Mögliche Ergebnisse** | Beobachtung | Einordnung | |---|---| | Gültige Antwort mit `good` | Server lieferte eine auswertbare OCSP-Statusantwort | | `revoked` | Zertifikat wird als gesperrt gemeldet | | `unknown` | OCSP-Responder kennt den Status nicht eindeutig | | `OCSP response: no response sent` | Server lieferte kein OCSP Stapling | | Fehlerhafte Antwort | OCSP-Antwort, Signatur oder Aktualität prüfen | Kein OCSP Stapling bedeutet nicht automatisch, dass das Zertifikat gesperrt oder die TLS-Verbindung ungültig ist. Ob Stapling erforderlich ist, hängt von Zertifikat, Anwendung und Richtlinie ab.
--- **20. Wie wird STARTTLS bei Maildiensten geprüft?**
SMTP, IMAP und POP3 anzeigen Bei STARTTLS beginnt die Verbindung unverschlüsselt und wird anschließend innerhalb des Anwendungsprotokolls auf TLS umgestellt. **SMTP auf Port 25** ```text [TEST][SENS] openssl s_client -starttls smtp -connect mail.example.com:25 -servername mail.example.com ``` **SMTP Submission auf Port 587** ```text [TEST][SENS] openssl s_client -starttls smtp -connect mail.example.com:587 -servername mail.example.com ``` **IMAP mit STARTTLS** ```text [TEST][SENS] openssl s_client -starttls imap -connect mail.example.com:143 -servername mail.example.com ``` **POP3 mit STARTTLS** ```text [TEST][SENS] openssl s_client -starttls pop3 -connect mail.example.com:110 -servername mail.example.com ``` **LMTP mit STARTTLS, sofern unterstützt** ```text [TEST][SENS] openssl s_client -starttls lmtp -connect mail.example.com:24 -servername mail.example.com ``` **Direktes TLS ohne STARTTLS** | Dienst | Typischer Port | Aufruf | |---|---:|---| | SMTPS | 465 | `openssl s_client -connect mail.example.com:465 -servername mail.example.com` | | IMAPS | 993 | `openssl s_client -connect mail.example.com:993 -servername mail.example.com` | | POP3S | 995 | `openssl s_client -connect mail.example.com:995 -servername mail.example.com` | STARTTLS und direktes TLS dürfen nicht verwechselt werden.
--- **21. Wie wird STARTTLS bei LDAP und Datenbanken geprüft?**
LDAP-, PostgreSQL- und MySQL-Beispiele anzeigen **LDAP mit STARTTLS** ```text [TEST][SENS] openssl s_client -starttls ldap -connect ldap.example.com:389 -servername ldap.example.com ``` **LDAPS mit direktem TLS** ```text [TEST][SENS] openssl s_client -connect ldap.example.com:636 -servername ldap.example.com ``` **PostgreSQL mit TLS-Aushandlung** ```text [TEST][SENS] openssl s_client -starttls postgres -connect db.example.com:5432 -servername db.example.com ``` **MySQL mit TLS-Aushandlung, sofern von der installierten OpenSSL-Version unterstützt** ```text [TEST][SENS] openssl s_client -starttls mysql -connect db.example.com:3306 -servername db.example.com ``` Nicht jede OpenSSL- oder LibreSSL-Version unterstützt alle `-starttls`-Protokolle. Verfügbarkeit prüfen: ```text [RO] openssl s_client -help ``` Ein erfolgreicher TLS-Handshake beweist nicht, dass anschließend eine Datenbank- oder LDAP-Anmeldung erfolgreich ist.
--- **22. Wie wird eine Verbindung über einen HTTP-Proxy getestet?**
HTTP-CONNECT-Proxy anzeigen ```text [TEST][SENS] openssl s_client -proxy proxy.example.com:8080 -connect example.com:443 -servername example.com ``` OpenSSL sendet dabei eine HTTP-CONNECT-Anfrage an den Proxy und baut durch den Tunnel die TLS-Verbindung zum Zielserver auf. **Proxybenutzer angeben** ```text [TEST][SENS] openssl s_client -proxy proxy.example.com:8080 -proxy_user max.mustermann -proxy_pass stdin -connect example.com:443 -servername example.com ``` Das Passwort wird über die angegebene Passwortquelle eingelesen. **Wichtiger Sicherheitshinweis** Die von `s_client` unterstützte Proxy-Basisauthentifizierung überträgt die Zugangsdaten vor dem TLS-Tunnel in leicht rückwandelbarer Base64-Form an den Proxy. Sie ist nur in entsprechend geschützten und autorisierten Umgebungen zu verwenden. **Direkt- und Proxytest vergleichen** Direkt: ```text [TEST][SENS] openssl s_client -connect example.com:443 -servername example.com ``` Über Proxy: ```text [TEST][SENS] openssl s_client -proxy proxy.example.com:8080 -connect example.com:443 -servername example.com ``` Unterschiedliche Zertifikate können auf TLS-Inspection oder unterschiedliche Netzwerkpfade hinweisen.
--- **23. Wie wird eine mTLS-Verbindung mit Clientzertifikat geprüft?**
Clientzertifikat und privaten Schlüssel verwenden **Clientzertifikat und Schlüssel getrennt** ```text [TEST][FILE][SENS] openssl s_client -connect api.example.com:443 -servername api.example.com -cert client-cert.pem -key client-key.pem ``` **Zusätzlich Serverzertifikat und Hostname verifizieren** ```text [TEST][FILE][SENS] openssl s_client -connect api.example.com:443 -servername api.example.com -cert client-cert.pem -key client-key.pem -CAfile company-root-ca.pem -verify_hostname api.example.com -verify_return_error ``` **Clientzertifikatskette angeben** ```text [TEST][FILE][SENS] openssl s_client -connect api.example.com:443 -servername api.example.com -cert client-cert.pem -key client-key.pem -cert_chain client-chain.pem -build_chain ``` Die Optionen `-cert_chain` und `-build_chain` sind versionsabhängig. **Mögliche Fehler** - Clientzertifikat fehlt; - privater Schlüssel passt nicht zum Zertifikat; - Clientzertifikat abgelaufen; - Extended Key Usage erlaubt keine Clientauthentifizierung; - ausstellende Client-CA wird vom Server nicht vertraut; - Zwischenzertifikat fehlt; - falsches Dateiformat; - verschlüsselter Schlüssel kann nicht geöffnet werden. > Private Schlüssel dürfen niemals in Tickets, BookStack-Seiten, Chatnachrichten oder Diagnoseausgaben eingefügt werden.
--- **24. Wie wird ein privater Schlüssel geprüft, ohne ihn auszugeben?**
Schlüsselstruktur sicher prüfen **Allgemeinen privaten Schlüssel prüfen** ```text [RO][FILE][SENS] openssl pkey -in server-key.pem -check -noout ``` Bei einem verschlüsselten Schlüssel wird normalerweise eine Passphrase abgefragt. **Nur öffentliche Schlüsselkomponente ausgeben** ```text [RO][FILE][SENS] openssl pkey -in server-key.pem -pubout ``` **Schlüsselinformation ohne private Bestandteile** ```text [RO][FILE][SENS] openssl pkey -in server-key.pem -pubout -text_pub -noout ``` **Nicht unkontrolliert verwenden** ```text openssl pkey -in server-key.pem -text ``` Dieser Befehl kann private Schlüsselbestandteile ausgeben. Solche Ausgaben dürfen nicht in Logs, Terminalsitzungsaufzeichnungen oder Tickets gelangen. **Dateiberechtigungen prüfen** Linux: ```text [RO][FILE][SENS] stat server-key.pem ``` macOS: ```text [RO][FILE][SENS] stat -x server-key.pem ``` Windows: ```powershell [RO][FILE][SENS] Get-Acl .\server-key.pem ```
--- **25. Wie wird geprüft, ob Zertifikat und privater Schlüssel zusammengehören?**
Öffentliche Schlüssel vergleichen Die zuverlässige allgemeine Methode besteht darin, aus beiden Dateien den öffentlichen Schlüssel zu gewinnen und dessen DER-Darstellung zu hashen. **Hash des öffentlichen Schlüssels aus dem Zertifikat** ```text [RO][FILE][SENS] openssl x509 -in server-cert.pem -pubkey -noout | openssl pkey -pubin -outform DER | openssl dgst -sha256 ``` **Hash des öffentlichen Schlüssels aus dem privaten Schlüssel** ```text [RO][FILE][SENS] openssl pkey -in server-key.pem -pubout -outform DER | openssl dgst -sha256 ``` Wenn beide SHA-256-Werte identisch sind, besitzen Zertifikat und privater Schlüssel denselben öffentlichen Schlüssel. **Beispiel** ```text SHA2-256(stdin)= abcdef... SHA2-256(stdin)= abcdef... ``` **Warum nicht nur den RSA-Modulus vergleichen?** Der klassische Modulusvergleich funktioniert nur für bestimmte Schlüsselarten wie RSA. Der Vergleich des normalisierten öffentlichen Schlüssels funktioniert auch für andere von OpenSSL unterstützte Schlüsseltypen, beispielsweise EC-Schlüssel.
--- **26. Wie wird eine Certificate Signing Request geprüft?**
CSR-Inhalt und Signatur anzeigen **Gesamten CSR-Inhalt anzeigen** ```text [RO][FILE][SENS] openssl req -in request.csr -noout -text ``` **Subject anzeigen** ```text [RO][FILE][SENS] openssl req -in request.csr -noout -subject ``` **CSR-Signatur prüfen** ```text [RO][FILE][SENS] openssl req -in request.csr -noout -verify ``` **Öffentlichen Schlüssel des CSR ausgeben** ```text [RO][FILE][SENS] openssl req -in request.csr -noout -pubkey ``` **Zu prüfen** - Subject; - gewünschte DNS-Namen; - Subject Alternative Names; - Schlüsseltyp; - Schlüssellänge beziehungsweise Kurve; - Signaturalgorithmus; - erfolgreiche CSR-Signaturprüfung. Ein CSR ist noch kein Zertifikat. Er enthält: - Identitätsantrag; - öffentlichen Schlüssel; - angeforderte Erweiterungen; - Signatur des zugehörigen privaten Schlüssels. Er enthält nicht den privaten Schlüssel.
--- **27. Wie wird geprüft, ob CSR und privater Schlüssel zusammengehören?**
CSR-Schlüsselvergleich anzeigen **Öffentlichen Schlüssel aus dem CSR hashen** ```text [RO][FILE][SENS] openssl req -in request.csr -pubkey -noout | openssl pkey -pubin -outform DER | openssl dgst -sha256 ``` **Öffentlichen Schlüssel aus dem privaten Schlüssel hashen** ```text [RO][FILE][SENS] openssl pkey -in server-key.pem -pubout -outform DER | openssl dgst -sha256 ``` Sind beide Werte identisch, gehört der private Schlüssel zum CSR. **Nach Ausstellung zusätzlich vergleichen** ```text CSR ↔ privater Schlüssel Zertifikat ↔ privater Schlüssel ``` Dadurch wird geprüft, ob die Zertifizierungsstelle tatsächlich das Zertifikat für den vorgesehenen Schlüssel ausgestellt hat.
--- **28. Wie werden PEM- und DER-Zertifikate unterschieden und konvertiert?**
Zertifikatsformate anzeigen **PEM** PEM ist textbasiert und enthält Markierungen wie: ```text -----BEGIN CERTIFICATE----- ... -----END CERTIFICATE----- ``` **DER** DER ist ein binäres ASN.1-Format und besitzt keine lesbaren BEGIN-/END-Markierungen. **PEM-Zertifikat anzeigen** ```text [RO][FILE][SENS] openssl x509 -in certificate.pem -inform PEM -noout -text ``` **DER-Zertifikat anzeigen** ```text [RO][FILE][SENS] openssl x509 -in certificate.der -inform DER -noout -text ``` **DER nach PEM konvertieren** ```text [CHANGE][FILE][SENS] openssl x509 -in certificate.der -inform DER -out certificate.pem -outform PEM ``` **PEM nach DER konvertieren** ```text [CHANGE][FILE][SENS] openssl x509 -in certificate.pem -inform PEM -out certificate.der -outform DER ``` Die Dateiendung allein beweist das Format nicht. Dateien mit `.cer` oder `.crt` können PEM oder DER enthalten.
--- **29. Wie wird eine PKCS#12-Datei untersucht?**
PFX/P12-Inhalt sicher prüfen PKCS#12-Dateien verwenden häufig die Endungen: ```text .p12 .pfx ``` Sie können enthalten: - Zertifikat; - Zwischenzertifikate; - Root-Zertifikate; - privaten Schlüssel; - Metadaten. **Inhalt anzeigen, aber keine privaten Schlüssel ausgeben** ```text [RO][FILE][SENS] openssl pkcs12 -in bundle.p12 -info -noout ``` **Nur Zertifikate anzeigen, keine privaten Schlüssel** ```text [RO][FILE][SENS] openssl pkcs12 -in bundle.p12 -nokeys ``` **Nur das Client- beziehungsweise Leaf-Zertifikat extrahieren** ```text [CHANGE][FILE][SENS] openssl pkcs12 -in bundle.p12 -clcerts -nokeys -out client-cert.pem ``` **CA-Zertifikate extrahieren** ```text [CHANGE][FILE][SENS] openssl pkcs12 -in bundle.p12 -cacerts -nokeys -out ca-chain.pem ``` **Privaten Schlüssel extrahieren** ```text [CHANGE][FILE][SENS] openssl pkcs12 -in bundle.p12 -nocerts -out client-key-encrypted.pem ``` Dieser Vorgang erzeugt eine Datei mit privatem Schlüssel und ist besonders sensibel. Die Ausgabedatei sollte verschlüsselt und mit streng beschränkten Dateirechten gespeichert werden. **Unverschlüsselten privaten Schlüssel exportieren** Optionen wie `-nodes` beziehungsweise das neuere `-noenc` können unverschlüsselte private Schlüssel erzeugen. Das sollte nur in begründeten Ausnahmefällen, mit dokumentierter Freigabe und geeigneten Dateirechten erfolgen.
--- **30. Wie werden Zertifikatsfingerabdrücke verglichen?**
SHA-256-Fingerprints anzeigen **Zertifikatsfingerabdruck** ```text [RO][FILE][SENS] openssl x509 -in server-cert.pem -noout -fingerprint -sha256 ``` **Hash der gesamten Datei** ```text [RO][FILE][SENS] openssl dgst -sha256 server-cert.pem ``` Diese beiden Werte sind nicht dasselbe: | Prüfung | Gehashte Daten | |---|---| | `openssl x509 -fingerprint -sha256` | DER-codiertes Zertifikat | | `openssl dgst -sha256 server-cert.pem` | Tatsächliche Datei einschließlich PEM-Darstellung | Zwei PEM-Dateien können dasselbe Zertifikat enthalten, aber wegen unterschiedlicher Zeilenenden oder Formatierung unterschiedliche Dateihashes besitzen. Der Zertifikatsfingerabdruck bleibt dagegen identisch. **Betriebssystemspezifischer Dateihash** Windows: ```powershell [RO][FILE][SENS] Get-FileHash .\server-cert.pem -Algorithm SHA256 ``` Linux: ```text [RO][FILE][SENS] sha256sum server-cert.pem ``` macOS: ```text [RO][FILE][SENS] shasum -a 256 server-cert.pem ```
--- **31. Wie werden detaillierte TLS-Zustände und Nachrichten untersucht?**
Erweiterte Diagnoseoptionen anzeigen **TLS-Zustandswechsel anzeigen** ```text [TEST][SENS] openssl s_client -connect example.com:443 -servername example.com -state ``` **TLS-Protokollnachrichten anzeigen** ```text [TEST][SENS] openssl s_client -connect example.com:443 -servername example.com -msg ``` **Umfangreicher Trace, sofern unterstützt** ```text [TEST][SENS] openssl s_client -connect example.com:443 -servername example.com -trace ``` **TLS-Erweiterungen anzeigen** ```text [TEST][SENS] openssl s_client -connect example.com:443 -servername example.com -tlsextdebug ``` **Wichtiger Hinweis** `-debug`, `-msg` und `-trace` können sehr umfangreiche Hexadezimal- und Protokollausgaben erzeugen. Sie sollten erst verwendet werden, wenn: - der normale `s_client`-Test nicht ausreicht; - der Fehler reproduzierbar ist; - die Ausgabe geschützt gespeichert wird; - keine geheimen Anwendungsdaten eingegeben werden.
--- **32. Wie werden IPv4 und IPv6 getrennt getestet?**
IPv4-/IPv6-TLS-Vergleich anzeigen **IPv4 erzwingen** ```text [TEST][SENS] openssl s_client -4 -connect example.com:443 -servername example.com ``` **IPv6 erzwingen** ```text [TEST][SENS] openssl s_client -6 -connect example.com:443 -servername example.com ``` **Direkte IPv6-Adresse** ```text [TEST][SENS] openssl s_client -connect '[2001:db8::20]:443' -servername example.com ``` Bei einer IPv6-Adresse in `host:port`-Schreibweise muss die Adresse in eckige Klammern gesetzt werden. **Interpretation** | IPv4 | IPv6 | Mögliche Ursache | |---|---|---| | Erfolgreich | Fehler | IPv6-DNS, Routing, Firewall, MTU oder Zielkonfiguration | | Fehler | Erfolgreich | IPv4-Routing, NAT, Firewall oder Zielkonfiguration | | Unterschiedliches Zertifikat | Unterschiedlicher Load Balancer oder Server | | Unterschiedliche TLS-Version | Unterschiedliche Proxy- oder Serverkonfiguration |
--- **33. Wie wird ein TLS-Fehler systematisch eingegrenzt?**
Diagnosekette anzeigen **1. DNS prüfen** Windows: ```powershell [RO] Resolve-DnsName example.com ``` Linux: ```text [RO] dig example.com ``` macOS: ```text [RO] dig example.com ``` **2. TCP-Port prüfen** Windows: ```powershell [TEST] Test-NetConnection example.com -Port 443 ``` Linux und macOS: ```text [TEST] nc -vz example.com 443 ``` **3. TLS mit SNI prüfen** ```text [TEST][SENS] openssl s_client -connect example.com:443 -servername example.com ``` **4. Zertifikatsprüfung erzwingen** ```text [TEST][SENS] openssl s_client -connect example.com:443 -servername example.com -verify_hostname example.com -verify_return_error ``` **5. Zertifikatsliste anzeigen** ```text [TEST][SENS] openssl s_client -connect example.com:443 -servername example.com -showcerts ``` **6. TLS-Versionen getrennt prüfen** ```text [TEST][SENS] openssl s_client -connect example.com:443 -servername example.com -tls1_2 ``` ```text [TEST][SENS] openssl s_client -connect example.com:443 -servername example.com -tls1_3 ``` **7. Anwendung prüfen** ```text [TEST][SENS] curl -v https://example.com/ ``` **8. Logs vergleichen** - Reverse Proxy; - Webserver; - Load Balancer; - Firewall; - Anwendung; - Zertifikatsverwaltung; - Systemzeit.
--- **34. Wie werden typische OpenSSL-Fehler eingeordnet?**
Fehlertabelle anzeigen | Fehler oder Beobachtung | Mögliche Ursache | |---|---| | `Connection refused` | Ziel erreichbar, aber kein Listener am Port | | `Connection timed out` | Firewall, Routing, Rückweg oder Ziel nicht erreichbar | | `no peer certificate available` | TLS-Handshake brach vor Zertifikatsübertragung ab | | `wrong version number` | Falsches Protokoll am Port, beispielsweise direktes TLS gegen einen Klartextport | | `unknown protocol` | Ziel spricht kein erwartetes TLS-Protokoll | | `handshake failure` | Keine gemeinsamen Parameter, Richtlinie, Clientzertifikat oder Serverkonfiguration | | `no shared cipher` | Keine gemeinsame Cipher Suite | | `unsupported protocol` | TLS-Version nicht unterstützt oder deaktiviert | | `certificate verify failed` | Vertrauenskette, Zeit, Zweck oder Name fehlerhaft | | `unable to get local issuer certificate` | Zwischenzertifikat oder Aussteller fehlt | | `self-signed certificate` | Nicht vertrautes selbstsigniertes Zertifikat | | `certificate has expired` | Zertifikat abgelaufen | | `certificate is not yet valid` | Systemzeit falsch oder Gültigkeit noch nicht begonnen | | `hostname mismatch` | Zertifikat gilt nicht für erwarteten Namen | | `bad certificate` | Gegenstelle lehnt Zertifikat ab | | `certificate required` | Server verlangt ein Clientzertifikat | | `tlsv1 alert protocol version` | Gegenstelle akzeptiert angebotene TLS-Version nicht | | `unexpected eof while reading` | Gegenstelle oder Zwischenkomponente beendet Verbindung ohne regulären TLS-Abschluss | | Falsches Zertifikat | SNI fehlt, falscher Load Balancer oder falsches Ziel | | `Verify return code: 0 (ok)` trotz falscher Anwendung | TLS-Zertifikat okay, Anwendungsproblem bleibt möglich |
--- **35. Welche Fehlinterpretationen müssen vermieden werden?**
Praxisfallen anzeigen | Fehlinterpretation | Richtige Einordnung | |---|---| | TLS-Handshake erfolgreich bedeutet Zertifikat gültig | `s_client` kann nach Verify-Fehlern fortfahren | | `CONNECTED` bedeutet TLS vollständig erfolgreich | Es bestätigt zunächst die hergestellte Transportverbindung | | `-showcerts` zeigt eine validierte Kette | Es zeigt nur die vom Server gesendeten Zertifikate | | Root-Zertifikat fehlt in Serverausgabe | Root-CA wird normalerweise nicht mitgesendet | | Common Name reicht immer aus | Moderne Clients prüfen hauptsächlich SAN | | Test über IP entspricht Test über DNS-Namen | SNI und Hostnamenprüfung können abweichen | | `-servername` prüft automatisch den Zertifikatsnamen | SNI und Hostnamenvalidierung sind getrennte Funktionen | | `-verify_hostname` setzt automatisch das Netzwerkziel | Das Netzwerkziel wird durch `-connect` bestimmt | | Selbstsigniert bedeutet automatisch unsicher | Es bedeutet zunächst, dass kein externer Vertrauenspfad vorliegt | | `Verify return code: 0` beweist funktionierende Website | Nur die geprüfte TLS-/Zertifikatsebene ist erfolgreich | | Gleiches Subject bedeutet gleiches Zertifikat | Seriennummer, Public Key und Fingerprint können verschieden sein | | Gleicher Dateihash ist der einzige Zertifikatsvergleich | PEM-Formatierung kann Dateihash verändern | | PKCS#12 ist nur ein Zertifikat | Datei kann zusätzlich private Schlüssel und Ketten enthalten | | Private Schlüssel können zur Diagnose angezeigt werden | Private Schlüssel dürfen nicht offengelegt werden | | `-tls1_2` bedeutet mindestens TLS 1.2 | Bei `s_client` erzwingt die Option den Test mit TLS 1.2 | | Fehlendes OCSP Stapling bedeutet gesperrt | Server hat lediglich keine Stapling-Antwort geliefert |
--- **36. Wie sieht ein sicherer OpenSSL-Diagnoseablauf aus?**
Empfohlene Schrittfolge anzeigen **Vorbereitung** 1. Erwarteten Hostnamen, Ziel-IP und Port dokumentieren. 2. Klären, ob direktes TLS oder STARTTLS verwendet wird. 3. OpenSSL- beziehungsweise LibreSSL-Version prüfen. 4. Erwartete Zertifizierungsstelle und Zertifikatsnamen ermitteln. 5. Systemzeit und Zeitzone kontrollieren. 6. Private Schlüssel und Passwortquellen schützen. **Verbindung** 7. DNS-Auflösung prüfen. 8. TCP-Port prüfen. 9. TLS-Verbindung mit richtigem SNI aufbauen. 10. Tatsächlich ausgehandelte TLS-Version und Cipher Suite dokumentieren. 11. ALPN bei HTTP-Diensten prüfen. **Zertifikat** 12. Zertifikatsprüffehlermeldungen beachten. 13. Prüfung mit `-verify_return_error` erzwingen. 14. Hostnamen mit `-verify_hostname` prüfen. 15. Serverzertifikate mit `-showcerts` anzeigen. 16. Leaf- und Zwischenzertifikate getrennt untersuchen. 17. SAN, Issuer, Subject und Gültigkeit prüfen. 18. Kette mit `openssl verify` lokal nachvollziehen. **Vertiefung** 19. TLS 1.2 und TLS 1.3 getrennt testen. 20. IPv4 und IPv6 vergleichen. 21. Direkt- und Proxyverbindung vergleichen. 22. Bei mTLS Clientzertifikat und Schlüsselzuordnung prüfen. 23. Bei STARTTLS das richtige Anwendungsprotokoll angeben. 24. Nur bei Bedarf `-state`, `-msg` oder `-trace` verwenden. **Validierung** 25. HTTPS zusätzlich mit curl prüfen. 26. Server-, Proxy- und Firewall-Logs vergleichen. 27. Bei Netzwerkverdacht Paketmitschnitt erstellen. 28. Nach einer Änderung exakt denselben Test wiederholen. 29. Diagnoseausgaben vor Weitergabe auf sensible Daten prüfen. 30. Temporär extrahierte Schlüssel- oder Zertifikatsdateien sicher behandeln.
--- **37. Kurzreferenz – häufige OpenSSL-Befehle**
Befehlstabelle anzeigen | Aufgabe | Befehl | |---|---| | Version | `[RO] openssl version -a` | | TLS-Verbindung | `[TEST][SENS] openssl s_client -connect example.com:443 -servername example.com` | | Kompakte Ausgabe | `[TEST][SENS] openssl s_client -connect example.com:443 -servername example.com -brief` | | Hostname prüfen | `[TEST][SENS] openssl s_client -connect example.com:443 -servername example.com -verify_hostname example.com -verify_return_error` | | Zertifikatsliste | `[TEST][SENS] openssl s_client -connect example.com:443 -servername example.com -showcerts` | | Eigene CA | `[TEST][FILE][SENS] openssl s_client -connect example.com:443 -servername example.com -CAfile root-ca.pem -verify_return_error` | | TLS 1.2 | `[TEST][SENS] openssl s_client -connect example.com:443 -servername example.com -tls1_2` | | TLS 1.3 | `[TEST][SENS] openssl s_client -connect example.com:443 -servername example.com -tls1_3` | | ALPN | `[TEST][SENS] openssl s_client -connect example.com:443 -servername example.com -alpn 'h2,http/1.1'` | | OCSP Stapling | `[TEST][SENS] openssl s_client -connect example.com:443 -servername example.com -status` | | SMTP STARTTLS | `[TEST][SENS] openssl s_client -starttls smtp -connect mail.example.com:587 -servername mail.example.com` | | IMAP STARTTLS | `[TEST][SENS] openssl s_client -starttls imap -connect mail.example.com:143 -servername mail.example.com` | | LDAP STARTTLS | `[TEST][SENS] openssl s_client -starttls ldap -connect ldap.example.com:389 -servername ldap.example.com` | | Zertifikat anzeigen | `[RO][FILE][SENS] openssl x509 -in server-cert.pem -noout -text` | | Kerndaten | `[RO][FILE][SENS] openssl x509 -in server-cert.pem -noout -subject -issuer -serial -dates` | | SAN anzeigen | `[RO][FILE][SENS] openssl x509 -in server-cert.pem -noout -ext subjectAltName` | | SHA-256-Fingerprint | `[RO][FILE][SENS] openssl x509 -in server-cert.pem -noout -fingerprint -sha256` | | 30 Tage Restlaufzeit | `[RO][FILE][SENS] openssl x509 -in server-cert.pem -noout -checkend 2592000` | | Kette prüfen | `[RO][FILE][SENS] openssl verify -CAfile root-ca.pem -untrusted intermediate-ca.pem server-cert.pem` | | Privaten Schlüssel prüfen | `[RO][FILE][SENS] openssl pkey -in server-key.pem -check -noout` | | CSR prüfen | `[RO][FILE][SENS] openssl req -in request.csr -noout -text -verify` | | PKCS#12 untersuchen | `[RO][FILE][SENS] openssl pkcs12 -in bundle.p12 -info -noout` | | DER nach PEM | `[CHANGE][FILE][SENS] openssl x509 -in certificate.der -inform DER -out certificate.pem -outform PEM` |
--- **38. Kurzreferenz – wichtige `s_client`-Optionen**
Optionstabelle anzeigen | Option | Bedeutung | |---|---| | `-connect host:port` | Netzwerkziel festlegen | | `-servername name` | TLS-SNI setzen | | `-noservername` | Kein SNI senden | | `-verify_hostname name` | DNS-Namen des Zertifikats prüfen | | `-verify_ip adresse` | IP-Identität des Zertifikats prüfen | | `-verify_return_error` | Bei Zertifikatsprüffehlern abbrechen | | `-CAfile datei` | Vertrauenswürdige CA-Datei verwenden | | `-showcerts` | Vom Server gesendete Zertifikate anzeigen | | `-brief` | Kompakte Verbindungsübersicht | | `-no-interactive` | Nicht interaktiver Modus, sofern unterstützt | | `-4` | IPv4 erzwingen | | `-6` | IPv6 erzwingen | | `-tls1_2` | TLS 1.2 erzwingen | | `-tls1_3` | TLS 1.3 erzwingen | | `-min_protocol` | Minimale Protokollversion | | `-max_protocol` | Maximale Protokollversion | | `-cipher` | Cipher-Auswahl für TLS 1.2 und älter | | `-ciphersuites` | Cipher-Suites für TLS 1.3 | | `-alpn` | ALPN-Protokolle anbieten | | `-status` | OCSP-Stapling-Antwort anfordern | | `-starttls` | STARTTLS für ein Anwendungsprotokoll | | `-proxy` | HTTP-CONNECT-Proxy verwenden | | `-cert` | Clientzertifikat angeben | | `-key` | Privaten Clientschlüssel angeben | | `-cert_chain` | Clientzertifikatskette angeben | | `-state` | TLS-Zustände anzeigen | | `-msg` | TLS-Protokollnachrichten anzeigen | | `-trace` | Ausführlichen TLS-Trace anzeigen | | `-tlsextdebug` | TLS-Erweiterungen anzeigen |
--- **Merksätze** - OpenSSL- und LibreSSL-Version sowie lokale Optionen müssen zuerst geprüft werden. - `-connect` bestimmt das Netzwerkziel, `-servername` das SNI und `-verify_hostname` den zu prüfenden Zertifikatsnamen. - Ein abgeschlossener TLS-Handshake beweist nicht automatisch eine erfolgreiche Zertifikatsprüfung. - `s_client` kann ohne `-verify_return_error` nach Zertifikatsfehlern fortfahren. - `Verify return code: 0 (ok)` ist wesentlich aussagekräftiger als nur `CONNECTED`. - `-showcerts` zeigt die vom Server gesendeten Zertifikate, aber keine automatisch validierte Kette. - Das Root-Zertifikat wird normalerweise nicht vom TLS-Server mitgesendet. - Moderne Clients prüfen DNS-Namen hauptsächlich anhand des Subject Alternative Name. - STARTTLS und direktes TLS verwenden unterschiedliche Verbindungsabläufe. - `-tls1_2` und `-tls1_3` erzwingen jeweils eine bestimmte TLS-Version. - TLS-1.2-Cipher werden mit `-cipher`, TLS-1.3-Cipher-Suites mit `-ciphersuites` gewählt. - Eine interne CA mit `-CAfile` gilt nur für den jeweiligen OpenSSL-Aufruf. - Zertifikat, CSR und privater Schlüssel können über ihre öffentlichen Schlüssel sicher miteinander verglichen werden. - Private Schlüssel dürfen niemals in BookStack, Tickets, Chats oder Diagnoseprotokollen veröffentlicht werden. - Eine erfolgreiche TLS-Prüfung ersetzt nicht den anschließenden Anwendungstest mit curl oder einem protokollspezifischen Client. --- **Quellen** - [Offizielle OpenSSL-Dokumentation](https://docs.openssl.org/) - [OpenSSL `s_client`](https://docs.openssl.org/3.6/man1/openssl-s_client/) - [OpenSSL `x509`](https://docs.openssl.org/3.6/man1/openssl-x509/) - [OpenSSL `verify`](https://docs.openssl.org/3.6/man1/openssl-verify/) - [OpenSSL `pkey`](https://docs.openssl.org/3.6/man1/openssl-pkey/) - [OpenSSL `req`](https://docs.openssl.org/3.6/man1/openssl-req/) - [OpenSSL `pkcs12`](https://docs.openssl.org/3.6/man1/openssl-pkcs12/) - [OpenSSL `ciphers`](https://docs.openssl.org/3.6/man1/openssl-ciphers/) - [OpenSSL `version`](https://docs.openssl.org/3.6/man1/openssl-version/) - [OpenSSL Verification Options](https://docs.openssl.org/3.6/man1/openssl-verification-options/) - [OpenSSL Passphrase Options](https://docs.openssl.org/3.6/man1/openssl-passphrase-options/) # 2.11 Microsoft Sysinternals – Windows-Prozesse und Systemaktivitäten analysieren Microsoft Sysinternals ist eine Sammlung spezialisierter Werkzeuge zur Diagnose von Windows-Systemen. Die Programme ermöglichen wesentlich tiefere Einblicke als der Task-Manager oder die üblichen Windows-Bordmittel. Mit Sysinternals lassen sich unter anderem folgende Fragen beantworten: - Welcher Prozess verursacht eine hohe CPU- oder Arbeitsspeicherauslastung? - Welcher Prozess hält eine Datei oder einen Ordner geöffnet? - Welche DLLs wurden von einem Prozess geladen? - Welche Datei-, Registry- und Prozesszugriffe führt eine Anwendung aus? - Welches Programm stellt eine bestimmte Netzwerkverbindung her? - Welche Programme, Dienste und Aufgaben werden automatisch gestartet? - Ist eine ausführbare Datei digital signiert? - Warum startet eine Anwendung nicht? - Warum dauert die Anmeldung ungewöhnlich lange? - Welcher Prozess verursacht einen Speicher- oder Handle-Anstieg? - Wie kann für eine abgestürzte oder nicht reagierende Anwendung ein Speicherabbild erstellt werden? > **Wichtig:** Sysinternals liefert technische Beobachtungen, aber nicht automatisch die Ursache einer Störung. Ein einzelner ungewöhnlicher Eintrag ist noch kein Beweis für einen Fehler oder Schadsoftware. Entscheidend sind Zusammenhang, zeitlicher Ablauf, Vergleichswerte und reproduzierbares Verhalten. ---
1. Kennzeichnungen und Sicherheitsregeln | Kennzeichnung | Bedeutung | |---|---| | `[RO]` | Read-only: liest Informationen aus, ohne den Zustand absichtlich zu verändern | | `[TEST]` | Führt einen aktiven Test aus oder erzeugt zusätzliche Systemlast | | `[PRIV]` | Benötigt möglicherweise Administratorrechte | | `[FILE]` | Erzeugt oder verändert eine Datei | | `[SENS]` | Ergebnis kann vertrauliche Daten enthalten | | `[CHANGE]` | Verändert Einstellungen oder einen Systemzustand | | `[DISRUPT]` | Kann Programme, Verbindungen oder Dienste unterbrechen | Bei der Arbeit mit Sysinternals gelten folgende Grundregeln: 1. Werkzeuge ausschließlich von Microsoft beziehungsweise über die offizielle Sysinternals-Seite beziehen. 2. Vor einer Analyse Zeitpunkt, betroffenen Computer, angemeldeten Benutzer und Fehlerbild dokumentieren. 3. Zuerst nur beobachten und Daten erfassen. 4. Prozesse, Handles, Verbindungen oder Autostarteinträge nicht vorschnell beenden beziehungsweise löschen. 5. Administratorrechte nur verwenden, wenn sie für die Untersuchung erforderlich sind. 6. Speicherabbilder, Process-Monitor-Aufzeichnungen und exportierte Listen als vertrauliche Daten behandeln. 7. VirusTotal-Abfragen nur unter Beachtung der betrieblichen Datenschutz- und Sicherheitsvorgaben verwenden. 8. Änderungen immer mit Rückweg, Sicherung und dokumentiertem Ausgangszustand durchführen.
2. Sysinternals sicher beziehen und starten Die Werkzeuge können einzeln oder als vollständige Sysinternals Suite heruntergeladen werden. Offizielle Bezugsquellen: - Sysinternals-Übersicht: `https://learn.microsoft.com/sysinternals/` - Sysinternals Suite: `https://learn.microsoft.com/sysinternals/downloads/sysinternals-suite` - Sysinternals Live: `https://live.sysinternals.com/` Die Suite eignet sich besonders für einen zentral gepflegten administrativen Werkzeugbestand. **Beispiel für eine lokale Ablage** ```text C:\Admin\Sysinternals\ ``` **Start über Sysinternals Live** ```text \\live.sysinternals.com\tools\procexp.exe ``` ```text \\live.sysinternals.com\tools\procmon.exe ``` Das direkte Starten über Sysinternals Live kann durch Firewall-, Proxy-, WebDAV-, SMB- oder Sicherheitsrichtlinien verhindert werden. Für reproduzierbare Analysen ist eine lokal bereitgestellte und betrieblich freigegebene Version häufig sinnvoller. **Grundlegende Prüfung einer heruntergeladenen Datei** ```powershell [RO] Get-AuthenticodeSignature "C:\Admin\Sysinternals\procexp.exe" ``` ```powershell [RO] Get-FileHash "C:\Admin\Sysinternals\procexp.exe" -Algorithm SHA256 ``` Die Signatur sollte gültig sein und zu Microsoft gehören. Ein Hashwert dient zur eindeutigen Dokumentation einer untersuchten Version, beweist allein aber nicht deren Vertrauenswürdigkeit. **Wichtiger Hinweis zur Lizenzvereinbarung** Viele Sysinternals-Kommandozeilenwerkzeuge unterstützen: ```text -accepteula ``` Damit wird die Lizenzvereinbarung ohne interaktive Rückfrage akzeptiert. Diese Option sollte nur eingesetzt werden, wenn die Lizenzvereinbarung organisatorisch geprüft und akzeptiert wurde.
3. Welches Sysinternals-Werkzeug eignet sich für welches Problem? | Problem oder Fragestellung | Geeignetes Werkzeug | Typische Untersuchung | |---|---|---| | Hohe CPU-Auslastung | Process Explorer, PsList, ProcDump | Verursachenden Prozess und Threads bestimmen | | Ungewöhnlich hoher Speicherverbrauch | Process Explorer, RAMMap, VMMap | Speicherverteilung und Prozesswachstum untersuchen | | Datei oder Ordner ist gesperrt | Process Explorer, Handle | Prozess mit geöffnetem Handle ermitteln | | Anwendung startet nicht | Process Monitor, Autoruns, Sigcheck | Fehlende Dateien, Berechtigungsfehler und Abhängigkeiten suchen | | Anwendung stürzt ab | ProcDump, Process Monitor | Speicherabbild und Aktivitäten vor dem Absturz erfassen | | Anwendung reagiert nicht | Process Explorer, ProcDump | Threads untersuchen und Hang-Dump erzeugen | | Unbekannte Netzwerkverbindung | TCPView, Process Explorer | Verbindung einem Prozess zuordnen | | Langsame Windows-Anmeldung | Autoruns, Process Monitor | Anmeldeobjekte, Dienste und Dateizugriffe untersuchen | | Verdächtiger Autostart | Autoruns, Sigcheck | Herausgeber, Signatur, Pfad und Startmechanismus prüfen | | Unbekannte ausführbare Datei | Sigcheck, Process Explorer | Signatur, Hash, Pfad und laufenden Prozess untersuchen | | DLL-Konflikt | Process Explorer, ListDLLs, Process Monitor | Geladene DLL-Versionen und Suchpfade vergleichen | | Handle-Leak | Process Explorer, Handle | Entwicklung der Handle-Anzahl beobachten | | Speicherverteilung des Systems | RAMMap | Standby-Liste, Dateicache und physische Speichernutzung analysieren | | Speicherbelegung eines Prozesses | VMMap | Private, gemeinsam genutzte und zugeordnete Bereiche untersuchen | | Dauerhafte Ereigniserfassung | Sysmon | Sicherheitsrelevante Systemereignisse protokollieren | | Fernadministration | PsTools | Autorisierte Prozess-, Dienst- und Systemabfragen durchführen |
4. Process Explorer – Prozesse genauer untersuchen Process Explorer ist eine erweiterte Prozessanzeige. Das Werkzeug stellt Prozesse hierarchisch dar und zeigt unter anderem: - übergeordnete und untergeordnete Prozesse, - Prozess-ID und Benutzerkonto, - CPU- und Arbeitsspeicherauslastung, - gestarteten Programmpfad, - Kommandozeile, - digitale Signatur, - geladene DLLs, - geöffnete Handles, - Threads und deren CPU-Auslastung, - Netzwerk- und Datenträgeraktivitäten. **Sinnvoller Diagnoseablauf** 1. Process Explorer möglichst zunächst ohne Administratorrechte starten. 2. Prozessbaum und auffällige Prozesse identifizieren. 3. Bei unvollständiger Sichtbarkeit kontrolliert als Administrator neu starten. 4. Eigenschaften des betroffenen Prozesses öffnen. 5. Pfad, Kommandozeile, Benutzerkonto und übergeordneten Prozess prüfen. 6. CPU-, Speicher-, Datenträger- und Netzwerkentwicklung beobachten. 7. Digitale Signatur kontrollieren. 8. Bei hoher CPU-Auslastung die einzelnen Threads untersuchen. 9. Beobachtungen mit Zeitpunkt und Prozess-ID dokumentieren. **Wichtige Bewertungsfragen** | Eigenschaft | Fragestellung | |---|---| | Image Path | Liegt die Datei im erwarteten Programmverzeichnis? | | Command Line | Mit welchen Parametern wurde der Prozess gestartet? | | Parent Process | Welcher Prozess hat ihn gestartet? | | User Name | Unter welchem Benutzer- oder Dienstkonto läuft er? | | Verified Signer | Ist die Signatur gültig und passt der Herausgeber? | | Start Time | Begann das Problem mit dem Prozessstart? | | Threads | Welcher Thread erzeugt die Auslastung? | | Handles | Steigt die Anzahl dauerhaft an? | | TCP/IP | Baut der Prozess unerwartete Verbindungen auf? | **Datei oder DLL suchen** Über die Suchfunktion von Process Explorer kann nach einem Teil des Datei-, Ordner-, Registry- oder DLL-Namens gesucht werden. Dadurch lässt sich beispielsweise ermitteln, welcher Prozess eine Datei geöffnet hält. ```text Find → Find Handle or DLL ``` **Wichtige Grenzen** - Ein unbekannter Prozess ist nicht automatisch schädlich. - Eine fehlende digitale Signatur ist kein Malware-Beweis. - Eine gültige Signatur beweist nicht, dass ein Programm harmlos ist. - Das Beenden eines Prozesses kann Datenverlust und Dienstausfälle verursachen. - Systemprozesse dürfen nicht ohne vorherige Identifikation beendet werden. - Unterschiedliche Prozesse können denselben Dateinamen verwenden. **Eingreifende Funktionen** | Aktion | Risiko | |---|---| | Prozess beenden | `[CHANGE][DISRUPT]` Ungespeicherte Daten können verloren gehen | | Prozessbaum beenden | `[CHANGE][DISRUPT]` Beendet zusätzlich untergeordnete Prozesse | | Prozess anhalten | `[CHANGE][DISRUPT]` Anwendung oder abhängige Dienste können blockieren | | Handle schließen | `[CHANGE][DISRUPT]` Anwendung kann abstürzen oder Daten beschädigen | | Priorität ändern | `[CHANGE]` Kann Leistungsverhalten und Stabilität beeinflussen | Diese Funktionen gehören nicht zur ersten Diagnosephase.
5. Process Monitor – Datei-, Registry- und Prozesszugriffe verfolgen Process Monitor, kurz Procmon, zeichnet in Echtzeit folgende Aktivitäten auf: - Dateisystemzugriffe, - Registry-Zugriffe, - Prozess- und Thread-Ereignisse, - Laden von Abbildern und DLLs, - Zugriffsresultate, - Prozess-ID, Benutzer und Aufrufpfad, - auf Wunsch zugehörige Aufrufstapel. Process Monitor eignet sich besonders, wenn eine Anwendung: - nicht startet, - eine Datei nicht findet, - keine Konfiguration speichern kann, - einen Berechtigungsfehler meldet, - eine falsche DLL lädt, - auf einen nicht erreichbaren Pfad zugreift, - beim Start ungewöhnlich lange wartet. **Empfohlener Aufnahmeablauf** 1. Fehlerbild und genaue Uhrzeit notieren. 2. Process Monitor starten. 3. Laufende Aufzeichnung zunächst anhalten. 4. Bereits angezeigte Ereignisse leeren. 5. Filter auf den betroffenen Prozess setzen. 6. Aufzeichnung starten. 7. Fehler genau einmal reproduzieren. 8. Aufzeichnung sofort wieder anhalten. 9. Ereignisse unmittelbar vor und nach dem Fehler untersuchen. 10. Originalaufzeichnung im PML-Format sichern. 11. Sensible Daten und Aufbewahrungsregeln beachten. **Nützliche Standard-Tastenkombinationen** | Funktion | Tastenkombination | |---|---| | Aufzeichnung starten oder anhalten | `Strg+E` | | bisher angezeigte Ereignisse löschen | `Strg+X` | | Filterdialog öffnen | `Strg+L` | | Ereignis suchen | `Strg+F` | | Aufnahme speichern | `Strg+S` | **Beispiel für einen Prozessfilter** ```text Process Name is beispiel.exe Include ``` Weitere nützliche Filter: ```text Process ID is 4321 Include Result is ACCESS DENIED Include Path contains \Config\ Include Operation is CreateFile Include ``` Mehrere `Include`-Filter derselben Eigenschaft wirken typischerweise wie eine ODER-Verknüpfung. Unterschiedliche Eigenschaften grenzen das Ergebnis weiter ein. Der Filter sollte deshalb bewusst aufgebaut und im Filterdialog kontrolliert werden. **Häufige Resultate richtig interpretieren** | Resultat | Grundbedeutung | Bewertung | |---|---|---| | `SUCCESS` | Operation war erfolgreich | Kein Fehler für diese einzelne Operation | | `NAME NOT FOUND` | Name oder Objekt wurde nicht gefunden | Kann normaler Suchlauf oder tatsächliche Ursache sein | | `PATH NOT FOUND` | Ein Bestandteil des Pfades fehlt | Pfad, Laufwerk, Freigabe oder Konfiguration prüfen | | `ACCESS DENIED` | Zugriff wurde verweigert | Berechtigungen, Integritätsstufe und Sicherheitssoftware prüfen | | `SHARING VIOLATION` | Objekt ist inkompatibel geöffnet | Öffnenden Prozess und Freigabemodus untersuchen | | `BUFFER OVERFLOW` | bereitgestellter Puffer war zunächst zu klein | Häufig Bestandteil einer normalen Größenabfrage | | `REPARSE` | Zugriff wurde über einen Reparse Point umgeleitet | Junction, symbolischen Link oder Cloud-Platzhalter prüfen | | `END OF FILE` | Dateiende wurde erreicht | Kann bei normalen Lesevorgängen auftreten | > `NAME NOT FOUND` und `BUFFER OVERFLOW` treten bei normalen Windows-Abläufen sehr häufig auf. Entscheidend ist, ob danach ein erfolgreicher Alternativzugriff erfolgt oder die Anwendung unmittelbar anschließend scheitert. **PML-Dateien** Eine gespeicherte PML-Datei kann enthalten: - Benutzernamen, - Dateipfade, - Registry-Pfade, - Server- und Freigabenamen, - Prozessnamen und Kommandozeilen, - Anwendungs- und Dokumentnamen, - Hinweise auf interne Infrastruktur. Daher gilt: ```text [SENS][FILE] PML-Dateien nur geschützt speichern und kontrolliert weitergeben. ```
6. Autoruns – Autostarts und Anmeldeverzögerungen untersuchen Autoruns zeigt zahlreiche Stellen, über die Programme, Dienste, Treiber und Erweiterungen automatisch gestartet werden können. Dazu gehören unter anderem: - Benutzeranmeldung, - Dienste, - Treiber, - geplante Aufgaben, - Explorer-Erweiterungen, - Winlogon-Komponenten, - Browser-Erweiterungen, - WMI-basierte Autostarts, - Winsock- und Netzwerkkomponenten, - Druckmonitor-DLLs, - bekannte DLLs und Image-Hijacks. **Sicherer Diagnoseablauf** 1. Autoruns starten und vollständiges Einlesen abwarten. 2. Betroffenen Benutzer und Systemkontext beachten. 3. Eintrag, Pfad, Herausgeber und digitale Signatur prüfen. 4. Vor Veränderungen einen Export oder Screenshot erstellen. 5. Microsoft-Einträge nur ausblenden, um Fremdsoftware übersichtlicher zu prüfen. 6. Bei einem begründeten Verdacht einen Eintrag zunächst deaktivieren. 7. System oder Anmeldung kontrolliert testen. 8. Ergebnis dokumentieren. 9. Eintrag wieder aktivieren, wenn keine Verbesserung eingetreten ist. Das Entfernen des Häkchens deaktiviert einen Eintrag und ist grundsätzlich leichter rückgängig zu machen als das Löschen. ```text [CHANGE] Deaktivieren: Eintrag abwählen ``` ```text [CHANGE][DISRUPT] Löschen: Eintrag dauerhaft entfernen ``` Autostarteinträge sollten während der Fehleranalyse nicht vorschnell gelöscht werden. **Autorunsc – Kommandozeilenversion** Alle Kategorien anzeigen: ```cmd [RO][PRIV] autorunsc.exe -a * -s ``` Alle Kategorien mit Signaturprüfung und CSV-Ausgabe erfassen: ```cmd [RO][PRIV][FILE] autorunsc.exe -a * -s -c > C:\Temp\autoruns.csv ``` Microsoft-Einträge ausblenden: ```cmd [RO][PRIV] autorunsc.exe -a * -m -s ``` Geplante Aufgaben anzeigen: ```cmd [RO][PRIV] autorunsc.exe -a t -s ``` Dienste und nicht deaktivierte Treiber anzeigen: ```cmd [RO][PRIV] autorunsc.exe -a s -s ``` Anmeldeeinträge anzeigen: ```cmd [RO] autorunsc.exe -a l -s ``` WMI-Autostarts anzeigen: ```cmd [RO][PRIV] autorunsc.exe -a m -s ``` **Wichtige Kategorien** | Option | Kategorie | |---|---| | `-a *` | Alle Kategorien | | `-a b` | Boot-Execute-Einträge | | `-a d` | AppInit-DLLs | | `-a e` | Explorer-Erweiterungen | | `-a h` | Image Hijacks | | `-a i` | Internet-Explorer-Erweiterungen | | `-a k` | Known DLLs | | `-a l` | Anmeldeeinträge | | `-a m` | WMI-Einträge | | `-a n` | Winsock- und Netzwerkprovider | | `-a p` | Druckmonitor-DLLs | | `-a r` | LSA-Sicherheitsprovider | | `-a s` | Dienste und nicht deaktivierte Treiber | | `-a t` | Geplante Aufgaben | | `-a w` | Winlogon-Einträge | **VirusTotal-Hinweis** Die Autoruns- und Autorunsc-Integration kann Hashwerte an VirusTotal übermitteln. Abhängig von den gewählten Optionen können unbekannte Dateien auch hochgeladen werden. ```text [SENS] Keine VirusTotal-Abfrage ohne betriebliche Freigabe durchführen. ``` Insbesondere darf eine Upload-Funktion nicht für vertrauliche, proprietäre oder personenbezogene Dateien verwendet werden. Eine VirusTotal-Erkennung ist außerdem nur ein Hinweis und kein abschließender Malware-Beweis.
7. TCPView und Tcpvcon – Netzwerkverbindungen Prozessen zuordnen TCPView zeigt TCP- und UDP-Endpunkte einschließlich: - lokalem Endpunkt, - entferntem Endpunkt, - Verbindungsstatus, - Prozessname, - Prozess-ID, - zugehörigem Dienst. Damit lässt sich beispielsweise feststellen, welches Programm eine Verbindung zu einer bestimmten IP-Adresse aufgebaut hat oder welcher Prozess auf einem lokalen Port lauscht. **Typischer Untersuchungsablauf** 1. TCPView starten. 2. Nach Prozess, Port oder Zieladresse suchen. 3. Namensauflösung bei Bedarf deaktivieren, damit nur tatsächliche IP-Adressen erscheinen. 4. Prozess-ID und Programmpfad mit Process Explorer abgleichen. 5. Zieladresse, Port, Prozesskontext und Verbindungszeitpunkt dokumentieren. 6. Erst danach bewerten, ob die Verbindung erwartet ist. **Tcpvcon – Kommandozeilenversion** Aktive TCP-Verbindungen anzeigen: ```cmd [RO] tcpvcon.exe ``` Alle TCP- und UDP-Endpunkte anzeigen: ```cmd [RO] tcpvcon.exe -a ``` Namensauflösung deaktivieren: ```cmd [RO] tcpvcon.exe -a -n ``` CSV-Ausgabe erzeugen: ```cmd [RO][FILE] tcpvcon.exe -a -n -c > C:\Temp\tcp-endpoints.csv ``` Bestimmten Prozess untersuchen: ```cmd [RO] tcpvcon.exe -a -n beispiel.exe ``` Bestimmte PID untersuchen: ```cmd [RO] tcpvcon.exe -a -n 4321 ``` | Option | Bedeutung | |---|---| | `-a` | Alle Endpunkte anzeigen | | `-c` | CSV-Ausgabe erzeugen | | `-n` | Adressen nicht in Namen auflösen | | Prozessname oder PID | Ausgabe auf einen Prozess begrenzen | TCPView kann eine bestehende TCP-Verbindung schließen: ```text [CHANGE][DISRUPT] Close Connection ``` Dadurch wird nur die konkrete Verbindung unterbrochen. Der Prozess kann anschließend erneut eine Verbindung herstellen. Diese Funktion ersetzt weder eine Firewall-Regel noch das Beenden oder Konfigurieren des verursachenden Programms.
8. Handle – Dateisperren und offene Objekte ermitteln Handle zeigt geöffnete Handles eines Prozesses an. Damit kann insbesondere festgestellt werden, welches Programm eine Datei oder einen Ordner geöffnet hält. Handle benötigt laut Microsoft Administratorrechte. Nach einem Teil eines Dateinamens suchen: ```cmd [RO][PRIV] handle.exe bericht.xlsx ``` Nach einem Pfadbestandteil suchen: ```cmd [RO][PRIV] handle.exe C:\Daten\Projekt ``` Handles eines bestimmten Prozesses anzeigen: ```cmd [RO][PRIV] handle.exe -p explorer ``` Handles einer bestimmten PID anzeigen: ```cmd [RO][PRIV] handle.exe -p 4321 ``` Besitzenden Benutzer anzeigen: ```cmd [RO][PRIV] handle.exe -u bericht.xlsx ``` Anzahl der verschiedenen Handle-Typen anzeigen: ```cmd [RO][PRIV] handle.exe -s ``` Alle Arten von Handles anzeigen: ```cmd [RO][PRIV] handle.exe -a -p 4321 ``` **Beispielausgabe sinngemäß interpretieren** ```text beispiel.exe pid: 4321 7C: File C:\Daten\Projekt\bericht.xlsx ``` | Feld | Bedeutung | |---|---| | `beispiel.exe` | Prozessname | | `4321` | Prozess-ID | | `7C` | Handle-Wert in hexadezimaler Schreibweise | | `File` | Objekttyp | | Pfad | geöffnetes Objekt | Handle kann ein einzelnes Handle zwangsweise schließen: ```cmd [CHANGE][DISRUPT][PRIV] handle.exe -c 7C -p 4321 ``` > Das erzwungene Schließen eines Handles kann Anwendungen zum Absturz bringen, Daten beschädigen oder das System destabilisieren. Diese Funktion ist kein regulärer erster Lösungsweg. Besser ist es, das verantwortliche Programm geordnet zu schließen oder den zugehörigen Dienst kontrolliert zu beenden. Die Option `-y` unterdrückt die Sicherheitsabfrage beim Schließen und sollte bei einer manuellen Fehleranalyse nicht eingesetzt werden.
9. Sigcheck – Signaturen, Versionen und Hashwerte prüfen Sigcheck zeigt unter anderem: - Dateiversion, - Zeitstempel, - digitale Signatur, - Zertifikatskette, - Hashwerte, - optional den VirusTotal-Status. Erweiterte Dateiinformationen anzeigen: ```cmd [RO] sigcheck.exe -nobanner -a "C:\Programme\Beispiel\beispiel.exe" ``` Hashwerte anzeigen: ```cmd [RO] sigcheck.exe -nobanner -h "C:\Programme\Beispiel\beispiel.exe" ``` Signatur und Zertifikatskette anzeigen: ```cmd [RO] sigcheck.exe -nobanner -i "C:\Programme\Beispiel\beispiel.exe" ``` Kombinierte Prüfung: ```cmd [RO] sigcheck.exe -nobanner -a -h -i "C:\Programme\Beispiel\beispiel.exe" ``` Nicht signierte ausführbare Dateien in `System32` suchen: ```cmd [RO][PRIV] sigcheck.exe -nobanner -u -e C:\Windows\System32 ``` Unterordner rekursiv untersuchen: ```cmd [RO][PRIV] sigcheck.exe -nobanner -u -e -s C:\Windows\System32 ``` | Option | Bedeutung | |---|---| | `-a` | Erweiterte Versionsinformationen anzeigen | | `-e` | Nur ausführbare Images untersuchen | | `-h` | Hashwerte anzeigen | | `-i` | Zertifikatskette und Katalog anzeigen | | `-s` | Unterverzeichnisse rekursiv durchsuchen | | `-u` | Ohne VirusTotal nur nicht signierte Dateien anzeigen | | `-c` | CSV-Ausgabe | | `-ct` | Tabulatorgetrennte Ausgabe | | `-nobanner` | Startbanner ausblenden | | `-accepteula` | Lizenzvereinbarung ohne Dialog akzeptieren | **Bewertung einer Signatur** | Ergebnis | Aussage | |---|---| | Gültige Signatur | Datei wurde signiert und seit der Signierung nicht entsprechend verändert | | Ungültige Signatur | Signaturprüfung ist fehlgeschlagen | | Keine Signatur | Datei besitzt keine auswertbare digitale Signatur | | Bekannter Herausgeber | Herausgeber ergibt sich aus dem Zertifikat | | Unbekannter Herausgeber | Vertrauenskette oder Signatur fehlt beziehungsweise ist nicht vertrauenswürdig | Eine gültige Signatur bedeutet nicht automatisch, dass die Datei sicher oder erwünscht ist. Eine nicht signierte Datei ist umgekehrt nicht automatisch Schadsoftware. **VirusTotal-Optionen** ```text -v ``` fragt den VirusTotal-Status anhand des Dateihashs ab. ```text -vs ``` kann Dateien, die VirusTotal noch nicht kennt, zur Analyse hochladen. ```text [SENS] `-vs` niemals ohne ausdrückliche Datenschutz- und Sicherheitsfreigabe verwenden. ```
10. PsList und weitere PsTools – Prozesse und Dienste per Kommandozeile prüfen Die PsTools enthalten verschiedene Kommandozeilenwerkzeuge für lokale und entfernte Windows-Systeme. | Werkzeug | Aufgabe | Risiko | |---|---|---| | PsList | Prozessinformationen anzeigen | `[RO]` | | PsService | Dienste abfragen und verwalten | Abfrage `[RO]`, Änderungen `[CHANGE][DISRUPT]` | | PsLoggedOn | angemeldete Benutzer anzeigen | `[RO][SENS]` | | PsInfo | Systeminformationen anzeigen | `[RO]` | | PsKill | Prozesse beenden | `[CHANGE][DISRUPT]` | | PsExec | Prozesse lokal oder remote starten | `[PRIV][CHANGE][DISRUPT]` | | PsShutdown | Computer herunterfahren oder neu starten | `[PRIV][CHANGE][DISRUPT]` | Lokale Prozesse anzeigen: ```cmd [RO] pslist.exe ``` Prozessbaum anzeigen: ```cmd [RO] pslist.exe -t ``` Detaillierte Speicherinformationen anzeigen: ```cmd [RO] pslist.exe -m ``` Bestimmte PID untersuchen: ```cmd [RO] pslist.exe 4321 ``` Entfernten Computer abfragen: ```cmd [RO][PRIV] pslist.exe \\PC-023 ``` Remote-Abfragen dürfen ausschließlich auf autorisierten Systemen erfolgen. Windows-Firewall, administrative Freigaben, Namensauflösung, Dienststeuerung und Berechtigungen können den Zugriff beeinflussen. **Umgang mit Zugangsdaten** PsTools können bei manchen Werkzeugen Benutzername und Kennwort als Parameter entgegennehmen. Kennwörter sollten nicht direkt in Befehlszeilen eingetragen werden, da sie beispielsweise in: - Befehlsverläufen, - Prozesslisten, - Skripten, - Protokollen, - Bildschirmaufzeichnungen sichtbar werden können. Wenn möglich, sollte ein bereits autorisierter administrativer Kontext oder eine betrieblich freigegebene Lösung zur privilegierten Administration verwendet werden. **Besonders eingreifende Werkzeuge** ```cmd [CHANGE][DISRUPT] pskill.exe 4321 ``` beendet einen Prozess. ```cmd [PRIV][CHANGE][DISRUPT] psexec.exe \\PC-023 Programm.exe ``` startet einen Prozess auf einem entfernten Computer. Diese Befehle sind keine reinen Diagnosebefehle. Vor ihrer Verwendung müssen Zielsystem, Prozess, Auswirkung, Berechtigung und Rückweg eindeutig geklärt sein.
11. ProcDump – Speicherabbilder bei Abstürzen, Hängern und Lastspitzen erstellen ProcDump kann Speicherabbilder eines Prozesses manuell oder beim Eintreten bestimmter Bedingungen erzeugen. Typische Auslöser sind: - hohe CPU-Auslastung, - nicht reagierendes Programmfenster, - unbehandelte Ausnahme, - Prozessende, - bestimmter Speicherverbrauch, - bestimmter Leistungsindikator. **Vollständiges Speicherabbild einer PID erzeugen** ```cmd [TEST][PRIV][FILE][SENS] procdump.exe -ma 4321 C:\Dumps ``` **Speicherabbild bei nicht reagierendem Fenster** ```cmd [TEST][PRIV][FILE][SENS] procdump.exe -ma -h beispiel.exe C:\Dumps ``` **Bis zu drei Speicherabbilder bei erhöhter CPU-Auslastung** ```cmd [TEST][PRIV][FILE][SENS] procdump.exe -ma -n 3 -s 5 -c 80 beispiel.exe C:\Dumps ``` Der Befehl reagiert, wenn der Prozess die angegebene CPU-Schwelle für die festgelegte Anzahl aufeinanderfolgender Sekunden überschreitet. **Speicherabbild bei einer unbehandelten Ausnahme** ```cmd [TEST][PRIV][FILE][SENS] procdump.exe -ma -e beispiel.exe C:\Dumps ``` **Auf einen noch nicht gestarteten Prozess warten** ```cmd [TEST][PRIV][FILE][SENS] procdump.exe -ma -e -w beispiel.exe C:\Dumps ``` | Option | Bedeutung | |---|---| | `-ma` | vollständiges Speicherabbild | | `-mm` | Mini-Dump; Standard | | `-n 3` | maximal drei Abbilder erzeugen | | `-s 5` | Bedingung muss fünf Sekunden bestehen | | `-c 80` | CPU-Schwelle von 80 Prozent | | `-h` | bei einem nicht reagierenden Fenster auslösen | | `-e` | bei unbehandelter Ausnahme auslösen | | `-e 1` | zusätzlich bei First-Chance-Ausnahmen auslösen | | `-w` | auf den Start des Prozesses warten | | `-t` | beim Beenden des Prozesses auslösen | | `-o` | vorhandene Zieldatei überschreiben | **Warum Speicherabbilder besonders geschützt werden müssen** Ein Speicherabbild kann unter anderem enthalten: - Kennwörter oder Kennwortfragmente, - Sitzungstoken, - personenbezogene Daten, - Inhalte geöffneter Dokumente, - kryptografische Schlüssel, - Verbindungszeichenfolgen, - interne Servernamen, - Anwendungsdaten. ```text [SENS][FILE] Speicherabbilder verschlüsselt ablegen, Zugriff begrenzen und nach der Analyse kontrolliert löschen. ``` Vollständige Abbilder können groß sein und während der Erstellung zusätzliche CPU-, Arbeitsspeicher- und Datenträgerlast verursachen. Auf produktiven Systemen sind Speicherplatz und mögliche Unterbrechungen vorab zu prüfen. ProcDump kann außerdem als systemweiter Postmortem-Debugger registriert werden. Da dies die Systemkonfiguration verändert, gehört eine solche Registrierung nicht in die normale spontane Diagnose: ```cmd [PRIV][CHANGE] procdump.exe -ma -i C:\Dumps ``` Rücknahme: ```cmd [PRIV][CHANGE] procdump.exe -u ```
12. RAMMap und VMMap – Arbeitsspeicher genauer analysieren **RAMMap** RAMMap untersucht die Verwendung des physischen Arbeitsspeichers des gesamten Windows-Systems. Wichtige Ansichten: | Ansicht | Aussage | |---|---| | Use Counts | Speichernutzung nach Verwendungsart | | Processes | physische Speichernutzung nach Prozess | | Priority Summary | Speicher nach Priorität | | Physical Pages | einzelne physische Speicherseiten | | Physical Ranges | physische Speicherbereiche | | File Summary | im RAM befindliche Dateidaten | | File Details | einzelne Dateien und Speicherseiten | RAMMap hilft bei Fragen wie: - Warum wird sehr viel physischer Speicher verwendet? - Wie groß ist der Dateicache? - Welche Dateien befinden sich in der Standby-Liste? - Wie viel Speicher wird durch Treiber oder Kernelstrukturen verwendet? - Entspricht der hohe Speicherverbrauch tatsächlich einem einzelnen Prozess? **VMMap** VMMap untersucht den virtuellen und physischen Speicher eines einzelnen Prozesses. VMMap zeigt unter anderem: - privaten Speicher, - gemeinsam genutzten Speicher, - Images und DLLs, - zugeordnete Dateien, - Heap-Bereiche, - Thread-Stacks, - reservierte und zugesicherte Speicherbereiche. VMMap ist besonders nützlich, wenn der Speicherverbrauch eines bestimmten Prozesses über längere Zeit zunimmt. **Beobachtung statt Momentaufnahme** Bei einem vermuteten Speicherproblem sollten mehrere Messpunkte dokumentiert werden: | Zeitpunkt | Private Bytes | Working Set | Commit | Handles | Threads | |---|---:|---:|---:|---:|---:| | Start | … | … | … | … | … | | nach 15 Minuten | … | … | … | … | … | | nach Reproduktion | … | … | … | … | … | | nach 60 Minuten | … | … | … | … | … | Ein hoher Wert allein beweist kein Speicherleck. Entscheidend ist, ob die Nutzung unter vergleichbaren Bedingungen dauerhaft wächst und nicht wieder freigegeben wird. RAMMap enthält Funktionen zum Leeren bestimmter Speicherlisten. Diese verändern den Systemzustand und können Messergebnisse verfälschen: ```text [CHANGE][DISRUPT] „Empty“-Funktionen nicht während der ursprünglichen Beweissicherung verwenden. ```
13. ListDLLs – geladene DLLs eines Prozesses anzeigen ListDLLs zeigt die von Prozessen geladenen DLLs an. Das Werkzeug kann helfen, wenn: - eine falsche DLL-Version vermutet wird, - eine Anwendung eine DLL aus einem unerwarteten Verzeichnis lädt, - 32-Bit- und 64-Bit-Komponenten verwechselt werden, - mehrere Versionen einer Bibliothek vorhanden sind, - ein Programm nach einem Update nicht mehr startet. DLLs eines bestimmten Prozesses anzeigen: ```cmd [RO] listdlls.exe beispiel.exe ``` DLLs einer bestimmten PID anzeigen: ```cmd [RO] listdlls.exe 4321 ``` Nach Prozessen suchen, die eine bestimmte DLL geladen haben: ```cmd [RO] listdlls.exe beispiel.dll ``` Versionsinformationen anzeigen: ```cmd [RO] listdlls.exe -v beispiel.exe ``` Nicht signierte DLLs hervorheben beziehungsweise anzeigen: ```cmd [RO] listdlls.exe -u beispiel.exe ``` Bei der Bewertung sind mindestens folgende Punkte zu prüfen: - vollständiger DLL-Pfad, - Dateiversion, - Produktversion, - Architektur, - digitaler Herausgeber, - Änderungszeitpunkt, - Übereinstimmung mit einer funktionierenden Referenzinstallation. Eine DLL mit ungewöhnlichem Pfad ist ein Prüfhinweis, aber noch kein Beweis für Manipulation.
14. Sysmon – dauerhafte sicherheitsrelevante Ereigniserfassung Sysmon installiert einen Windows-Systemdienst und einen Treiber. Anschließend protokolliert es abhängig von der Konfiguration detaillierte Systemereignisse, beispielsweise: - Prozessstarts, - Netzwerkverbindungen, - Dateiänderungen, - Treiber- und DLL-Ladevorgänge, - Registry-Aktivitäten, - DNS-Abfragen, - Prozesszugriffe, - WMI-Aktivitäten. Die Ereignisse befinden sich üblicherweise unter: ```text Anwendungs- und Dienstprotokolle └─ Microsoft └─ Windows └─ Sysmon └─ Operational ``` Sysmon ist kein spontanes Read-only-Diagnosewerkzeug. Installation und Konfiguration verändern das System dauerhaft: ```cmd [PRIV][CHANGE] sysmon64.exe -accepteula -i config.xml ``` Aktuelle Konfiguration anzeigen: ```cmd [RO][PRIV] sysmon64.exe -c ``` Konfiguration aktualisieren: ```cmd [PRIV][CHANGE] sysmon64.exe -c config.xml ``` Sysmon deinstallieren: ```cmd [PRIV][CHANGE][DISRUPT] sysmon64.exe -u ``` Vor einer Einführung müssen geklärt werden: - Welche Ereignisse werden benötigt? - Welche Daten dürfen protokolliert werden? - Wie hoch ist das erwartete Datenvolumen? - Wie lange werden Protokolle aufbewahrt? - Wer darf darauf zugreifen? - Werden Ereignisse an ein SIEM weitergeleitet? - Wie wird die Konfiguration getestet und versioniert? - Welche Datenschutz- und Betriebsratsvorgaben gelten? Sysmon bewertet Ereignisse nicht selbst als gutartig oder bösartig. Die Qualität der Ergebnisse hängt wesentlich von der Konfiguration und der anschließenden Auswertung ab.
15. Praxisfall – hohe CPU-Auslastung untersuchen **Ziel:** Verursachenden Prozess und möglichst den auslösenden Thread bestimmen. 1. Uhrzeit und wahrgenommene Auswirkung dokumentieren. 2. Mit Task-Manager oder Process Explorer den Prozess bestimmen. 3. CPU-Verlauf über einen angemessenen Zeitraum beobachten. 4. Prozesspfad, Benutzer, Kommandozeile und übergeordneten Prozess prüfen. 5. In Process Explorer die Prozesseigenschaften öffnen. 6. Unter `Threads` nach CPU-Auslastung sortieren. 7. Auffälligen Thread und zugehöriges Modul dokumentieren. 8. Ereignisanzeige und Anwendungsprotokolle zum selben Zeitpunkt prüfen. 9. Bei reproduzierbaren Lastspitzen kontrolliert ProcDump einsetzen. 10. Speicherabbild an Hersteller oder Entwicklung zur Analyse übergeben. **Nicht vorschnell tun:** - Prozess sofort beenden, - Priorität ohne Begründung verändern, - Sicherheitssoftware deaktivieren, - wiederholt vollständige Dumps ohne Speicherplatzkontrolle erzeugen.
16. Praxisfall – Datei oder Ordner lässt sich nicht ändern, löschen oder umbenennen **Typische Meldungen** - Datei wird von einem anderen Prozess verwendet. - Zugriff verweigert. - Freigabeverletzung. - Ordner kann nicht gelöscht werden. **Diagnoseablauf** 1. Vollständigen Pfad dokumentieren. 2. Berechtigungen und Besitzverhältnisse prüfen. 3. Mit Process Explorer nach Dateiname oder Pfad suchen. 4. Alternativ Handle verwenden: ```cmd [RO][PRIV] handle.exe "C:\Daten\Projekt\bericht.xlsx" ``` 5. Prozessname, PID, Benutzerkonto und Zweck identifizieren. 6. Prüfen, ob der Prozess regulär geschlossen werden kann. 7. Bei einem Dienst den zuständigen Dienst bestimmen. 8. Anwendung oder Dienst kontrolliert schließen. 9. Dateioperation erneut testen. 10. Ergebnis dokumentieren. Ein Handle sollte nicht zwangsweise geschlossen werden, solange ein geordnetes Beenden des verantwortlichen Programms möglich ist.
17. Praxisfall – Anwendung startet nicht **Diagnoseablauf** 1. Exakte Fehlermeldung und Uhrzeit dokumentieren. 2. Anwendungspfad und Version prüfen. 3. Digitale Signatur der Programmdatei prüfen: ```cmd [RO] sigcheck.exe -nobanner -a -h -i "C:\Programme\Beispiel\beispiel.exe" ``` 4. Ereignisanzeige und anwendungseigene Protokolle prüfen. 5. Process Monitor vorbereiten. 6. Filter auf den Prozessnamen setzen. 7. Aufnahme starten und Anwendung einmal starten. 8. Aufnahme sofort stoppen. 9. Letzte Zugriffe vor dem Prozessende untersuchen. 10. Besonders auf folgende Resultate achten: ```text ACCESS DENIED PATH NOT FOUND NAME NOT FOUND SHARING VIOLATION BAD IMAGE ``` 11. Geladene DLLs und deren Pfade prüfen. 12. Vergleich mit einem funktionierenden Referenzsystem durchführen. 13. Erst nach belegter Ursache Berechtigung, Pfad, Konfiguration oder Installation ändern. Viele `NAME NOT FOUND`-Ereignisse sind Teil eines normalen Suchvorgangs. Relevant ist häufig der letzte nicht erfolgreich ersetzte Zugriff unmittelbar vor dem Abbruch.
18. Praxisfall – unbekannte Netzwerkverbindung untersuchen 1. Lokale und entfernte Adresse dokumentieren. 2. Port, Protokoll und Verbindungsstatus erfassen. 3. Prozess-ID mit TCPView oder Tcpvcon bestimmen: ```cmd [RO] tcpvcon.exe -a -n ``` 4. Prozess-ID in Process Explorer untersuchen. 5. Dateipfad, Kommandozeile, Benutzer und übergeordneten Prozess prüfen. 6. Signatur und Hash der ausführbaren Datei erfassen. 7. DNS-Auflösung und Zielsystem kontrollieren. 8. Prüfen, ob die Verbindung zur Funktion der Anwendung passt. 9. Firewall-, Proxy- und Sicherheitsprotokolle zum selben Zeitpunkt vergleichen. 10. Bei tatsächlichem Verdacht das Incident-Response-Verfahren des Unternehmens anwenden. Eine unbekannte externe IP-Adresse kann beispielsweise zu einem CDN, Cloudanbieter, Update-Dienst oder Sicherheitsdienst gehören. Eine Eigentümerabfrage allein beweist daher weder Zweck noch Vertrauenswürdigkeit der Verbindung.
19. Häufige Fehlinterpretationen vermeiden | Beobachtung | Falscher Schluss | Richtige Einordnung | |---|---|---| | Prozess ist unbekannt | Prozess ist Schadsoftware | Pfad, Signatur, Herausgeber, Parent und Funktion prüfen | | Datei ist nicht signiert | Datei ist schädlich | Signatur ist nur ein Bewertungskriterium | | Datei ist signiert | Datei ist sicher | Auch signierte Software kann unerwünscht oder verwundbar sein | | Procmon zeigt `NAME NOT FOUND` | Ursache wurde gefunden | Suchvorgänge erzeugen diesen Status regelmäßig | | Procmon zeigt `BUFFER OVERFLOW` | Speicherüberlauf der Anwendung | Häufig normale Ermittlung der benötigten Puffergröße | | Viele TCP-Verbindungen | System ist kompromittiert | Browser, Cloud- und Kommunikationsprogramme erzeugen viele Verbindungen | | Hoher RAM-Verbrauch | Arbeitsspeicher ist defekt | Cache, Commit, Working Set und Speichertypen getrennt prüfen | | Hohe Handle-Anzahl | Sicheres Handle-Leak | Verlauf und Referenzwerte beobachten | | VirusTotal meldet nichts | Datei ist garantiert sicher | Fehlende Erkennungen sind keine Sicherheitsgarantie | | Autoruns-Eintrag ist unbekannt | Eintrag muss gelöscht werden | Zweck, Pfad und Herausgeber zunächst ermitteln | | Prozess lässt sich beenden | Problem ist gelöst | Ursache kann weiterbestehen und erneut auftreten |
20. Empfohlener Sysinternals-Diagnoseablauf | Phase | Vorgehen | Geeignete Werkzeuge | |---|---|---| | 1. Störung aufnehmen | Fehler, Zeitpunkt und Auswirkung dokumentieren | Ticket, Screenshot, Ereignisanzeige | | 2. Prozess bestimmen | Prozessname, PID und Benutzer ermitteln | Process Explorer, PsList | | 3. Herkunft prüfen | Pfad, Parent, Kommandozeile und Signatur prüfen | Process Explorer, Sigcheck | | 4. Aktivität beobachten | Datei-, Registry-, Prozess- und Netzwerkzugriffe erfassen | Process Monitor, TCPView | | 5. Ressourcen untersuchen | CPU, Handles und Speicherentwicklung prüfen | Process Explorer, Handle, RAMMap, VMMap | | 6. Autostart prüfen | Startmechanismen und Anmeldeobjekte untersuchen | Autoruns | | 7. Fehler reproduzieren | Gefilterte, zeitlich begrenzte Aufnahme erstellen | Process Monitor | | 8. Beweise sichern | PML, CSV, Screenshots oder Dump geschützt speichern | Procmon, Autorunsc, ProcDump | | 9. Hypothese testen | Nur eine kontrollierte Änderung durchführen | abhängig von Ursache | | 10. Ergebnis bestätigen | Ausgangsfehler erneut testen und Nebenwirkungen prüfen | gleiche Messmethode | | 11. Dokumentieren | Ursache, Änderung, Ergebnis und Rückweg festhalten | BookStack, Ticketsystem | **Merksatz** > Erst beobachten, dann zuordnen, anschließend vergleichen und erst danach verändern.
21. Kompakte Befehlsübersicht | Aufgabe | Befehl | Kennzeichnung | |---|---|---| | Signatur mit PowerShell prüfen | `Get-AuthenticodeSignature "C:\Pfad\Datei.exe"` | `[RO]` | | SHA-256-Hash berechnen | `Get-FileHash "C:\Pfad\Datei.exe" -Algorithm SHA256` | `[RO]` | | Alle Autostarts anzeigen | `autorunsc.exe -a * -s` | `[RO][PRIV]` | | Autostarts als CSV speichern | `autorunsc.exe -a * -s -c > C:\Temp\autoruns.csv` | `[RO][PRIV][FILE]` | | Alle Netzwerkendpunkte anzeigen | `tcpvcon.exe -a -n` | `[RO]` | | Endpunkte als CSV speichern | `tcpvcon.exe -a -n -c > C:\Temp\tcp.csv` | `[RO][FILE]` | | Dateiinhaber suchen | `handle.exe bericht.xlsx` | `[RO][PRIV]` | | Handles eines Prozesses anzeigen | `handle.exe -p 4321` | `[RO][PRIV]` | | Dateisignatur und Hash prüfen | `sigcheck.exe -nobanner -a -h -i Datei.exe` | `[RO]` | | Nicht signierte System32-Dateien suchen | `sigcheck.exe -nobanner -u -e C:\Windows\System32` | `[RO][PRIV]` | | Prozessliste anzeigen | `pslist.exe` | `[RO]` | | Prozessbaum anzeigen | `pslist.exe -t` | `[RO]` | | DLLs eines Prozesses anzeigen | `listdlls.exe 4321` | `[RO]` | | vollständiges Prozessabbild erzeugen | `procdump.exe -ma 4321 C:\Dumps` | `[TEST][PRIV][FILE][SENS]` | | Dump bei nicht reagierendem Fenster | `procdump.exe -ma -h beispiel.exe C:\Dumps` | `[TEST][PRIV][FILE][SENS]` | | Sysmon-Konfiguration anzeigen | `sysmon64.exe -c` | `[RO][PRIV]` | | Handle zwangsweise schließen | `handle.exe -c 7C -p 4321` | `[PRIV][CHANGE][DISRUPT]` | | Prozess zwangsweise beenden | `pskill.exe 4321` | `[CHANGE][DISRUPT]` |
22. Dokumentationsvorlage für eine Sysinternals-Analyse ```text Ticketnummer: Analysedatum: Administrator: Betroffener Computer: Betriebssystem: Angemeldeter Benutzer: Fehlerbeginn: Fehlerbeschreibung: Auswirkung: Betroffener Prozess: Prozess-ID: Programmdatei: Dateiversion: Benutzerkonto: Übergeordneter Prozess: Kommandozeile: Digitale Signatur: SHA-256: Verwendete Sysinternals-Werkzeuge: Werkzeugversionen: Verwendete Filter: Aufnahmezeitraum: Beobachtungen: - - - Ermittelte Auffälligkeiten: - - - Arbeitshypothese: Beleg für die Hypothese: Durchgeführter Test: Testergebnis: Durchgeführte Änderung: Rückweg: Abschlussprüfung: Erzeugte Dateien: - PML: - CSV: - Speicherabbild: - Screenshots: Speicherort: Zugriffsberechtigung: Lösch- oder Aufbewahrungsfrist: ```
23. Offizielle Quellen und weiterführende Dokumentation - [Microsoft Sysinternals – Übersicht](https://learn.microsoft.com/sysinternals/) - [Sysinternals Suite](https://learn.microsoft.com/sysinternals/downloads/sysinternals-suite) - [Process Explorer](https://learn.microsoft.com/sysinternals/downloads/process-explorer) - [Process Monitor](https://learn.microsoft.com/sysinternals/downloads/procmon) - [Autoruns und Autorunsc](https://learn.microsoft.com/sysinternals/downloads/autoruns) - [TCPView und Tcpvcon](https://learn.microsoft.com/sysinternals/downloads/tcpview) - [Handle](https://learn.microsoft.com/sysinternals/downloads/handle) - [Sigcheck](https://learn.microsoft.com/sysinternals/downloads/sigcheck) - [PsTools](https://learn.microsoft.com/sysinternals/downloads/pstools) - [PsList](https://learn.microsoft.com/sysinternals/downloads/pslist) - [ProcDump](https://learn.microsoft.com/sysinternals/downloads/procdump) - [RAMMap](https://learn.microsoft.com/sysinternals/downloads/rammap) - [VMMap](https://learn.microsoft.com/sysinternals/downloads/vmmap) - [ListDLLs](https://learn.microsoft.com/sysinternals/downloads/listdlls) - [Sysmon](https://learn.microsoft.com/sysinternals/downloads/sysmon) > Da Microsoft die Sysinternals-Werkzeuge regelmäßig aktualisiert, sollte vor dem produktiven Einsatz immer die aktuelle offizielle Dokumentation der verwendeten Version geprüft werden.
# 2.12 Protokolle und Logs systematisch auswerten Protokolldateien gehören zu den wichtigsten Informationsquellen bei der Fehleranalyse. Sie dokumentieren Ereignisse, Zustandsänderungen, Warnungen und Fehler, die während des Betriebs eines Systems oder einer Anwendung auftreten. Logs können unter anderem folgende Fragen beantworten: - Wann begann die Störung? - Welches System oder welcher Dienst meldete den Fehler zuerst? - Welcher Benutzer, Prozess oder Dienst war beteiligt? - Trat unmittelbar vorher eine Konfigurationsänderung auf? - Ist das Problem einmalig oder wiederkehrend? - Sind mehrere Systeme zur gleichen Zeit betroffen? - Welche Fehlernummer, Ereignis-ID oder Statusmeldung wurde protokolliert? - War ein Fehler die Ursache oder nur eine Folge eines anderen Problems? > **Grundregel:** Nicht mit dem auffälligsten Fehler beginnen, sondern mit dem ersten relevanten Ereignis in der zeitlichen Kette. ---
1. Kennzeichnungen und Sicherheitsregeln | Kennzeichnung | Bedeutung | |---|---| | `[RO]` | Liest Informationen aus, ohne sie absichtlich zu verändern | | `[TEST]` | Führt einen aktiven Test aus oder erzeugt zusätzliche Logeinträge | | `[PRIV]` | Benötigt möglicherweise Administrator- oder Root-Rechte | | `[FILE]` | Erzeugt oder verändert eine Datei | | `[SENS]` | Ausgabe kann vertrauliche Daten enthalten | | `[CHANGE]` | Verändert Konfiguration, Protokollierung oder Systemzustand | | `[DISRUPT]` | Kann Dienste oder Systeme beeinträchtigen | Logs können unter anderem folgende vertrauliche Informationen enthalten: - Benutzernamen und E-Mail-Adressen, - interne Hostnamen und IP-Adressen, - vollständige Datei- und Verzeichnispfade, - aufgerufene URLs und Suchbegriffe, - Sitzungs- und Korrelations-IDs, - Kommandozeilen und Programmparameter, - Datenbank- und Servernamen, - Inhalte von Anfragen und Antworten, - Zugangstoken oder andere Geheimnisse, - personenbezogene oder geschäftliche Daten. Deshalb gilt: 1. Protokolle nur so umfangreich wie erforderlich erfassen. 2. Exportierte Logs geschützt speichern. 3. Zugriff auf autorisierte Personen begrenzen. 4. Vor externer Weitergabe sensible Inhalte redigieren. 5. Originaldateien möglichst unverändert sichern. 6. Arbeitskopien getrennt vom Original anlegen. 7. Aufbewahrungs- und Löschfristen beachten. 8. Protokolle niemals unkontrolliert in öffentliche Analysedienste hochladen.
2. Wie wird eine Log-Analyse systematisch begonnen? Vor dem Öffnen der ersten Protokolldatei sollten mindestens folgende Informationen bekannt sein: | Information | Beispiel | |---|---| | Betroffenes System | `CLIENT-023` | | Betroffener Dienst | DNS-Client | | Fehlerbeginn | `2026-07-31 09:42:15 CEST` | | Letzter bekannter funktionierender Zeitpunkt | `2026-07-31 09:35 CEST` | | Betroffener Benutzer | `Max Mustermann` | | Fehlerbeschreibung | Interne Anwendung nicht erreichbar | | Reproduzierbarkeit | Bei jedem Anmeldeversuch | | Kürzliche Änderung | VPN-Client aktualisiert | | Zeitzone des meldenden Systems | Europe/Berlin | | Vergleichssystem | `CLIENT-024` funktioniert | **Empfohlener Analysezeitraum** Der Zeitraum sollte zunächst eng um das Ereignis gelegt werden: ```text Fehlerzeitpunkt: 09:42 Uhr Erste Untersuchung: 09:37 bis 09:47 Uhr ``` Falls dort keine Ursache erkennbar ist, wird das Zeitfenster schrittweise erweitert. **Bewährte Reihenfolge** 1. Uhrzeit und Zeitzone aller beteiligten Systeme prüfen. 2. Fehler reproduzieren und exakten Zeitpunkt notieren. 3. Passendes Protokoll bestimmen. 4. Zeitfenster begrenzen. 5. Nach Quelle, Dienst, Prozess oder Ereignis-ID filtern. 6. Das erste relevante Ereignis suchen. 7. Vorhergehende und nachfolgende Ereignisse betrachten. 8. Meldungen zwischen beteiligten Systemen zeitlich korrelieren. 9. Hypothese aufstellen. 10. Hypothese durch einen kontrollierten Test überprüfen.
3. Welche Informationen eines Logeintrags sind wichtig? | Feld | Bedeutung | Prüffrage | |---|---|---| | Zeitstempel | Zeitpunkt des Ereignisses | Welche Zeitzone wird verwendet? | | Hostname | meldendes System | Ist es wirklich das betroffene System? | | Quelle oder Provider | erzeugende Komponente | Welcher Dienst oder Treiber meldet das Ereignis? | | Prozess und PID | beteiligter Prozess | Läuft derselbe Prozess noch? | | Benutzer oder UID | Sicherheitskontext | Unter welchem Konto trat der Fehler auf? | | Schweregrad | Einordnung durch die Anwendung | Ist `Error` wirklich die Ursache? | | Ereignis-ID | typisierter Ereigniscode | Ist die ID providerspezifisch? | | Nachricht | menschenlesbare Beschreibung | Enthält sie Ursache, Folge oder nur Status? | | Fehlercode | technischer Rückgabewert | Ist der Code dezimal oder hexadezimal? | | Korrelations-ID | verbindet zusammengehörige Vorgänge | Taucht dieselbe ID in anderen Logs auf? | | Dienst oder Unit | betroffene Komponente | Welche Abhängigkeiten besitzt sie? | | Datei und Zeile | Position im Programmcode | Passt sie zur eingesetzten Version? | | Dauer | Laufzeit einer Operation | Wo entsteht die Verzögerung? | | Remote-Endpunkt | beteiligtes Zielsystem | Waren DNS, Routing und Port erreichbar? | Eine Ereignis-ID ist normalerweise nur zusammen mit der Quelle eindeutig. ```text Ereignis-ID 1000 von Quelle A ≠ Ereignis-ID 1000 von Quelle B ```
4. Wie werden Schweregrade richtig interpretiert? | Allgemeiner Schweregrad | Typische Bedeutung | |---|---| | Trace | sehr detaillierter interner Ablauf | | Debug | Diagnoseinformationen für Entwicklung und Administration | | Information | reguläres Ereignis oder Statusmeldung | | Notice | bemerkenswertes, aber nicht zwingend fehlerhaftes Ereignis | | Warning | unerwarteter Zustand; Verarbeitung kann weiterlaufen | | Error | Operation ist fehlgeschlagen | | Critical | schwerwiegender Fehler mit deutlicher Beeinträchtigung | | Alert | unmittelbares Eingreifen erforderlich | | Emergency | System oder Dienst ist nicht mehr verwendbar | Die genaue Bedeutung hängt von der jeweiligen Anwendung ab. Nicht jedes Programm verwendet dieselbe Einteilung. **Wichtige Regeln** - Eine Warnung ist nicht automatisch die Ursache. - Eine Fehlermeldung kann nur die Folge eines früheren Fehlers sein. - Eine Informationsmeldung kann den entscheidenden Hinweis enthalten. - Debug-Protokollierung kann relevante Informationen liefern, erzeugt aber viel Datenvolumen. - Wiederholte Meldungen können auf automatische Wiederholungsversuche hinweisen. - Eine erfolgreiche Wiederholung kann einen vorherigen Fehler bereits kompensiert haben. **Beispiel einer Ereigniskette** ```text 09:42:10 INFO DNS-Abfrage gestartet 09:42:15 WARNING Zeitüberschreitung bei DNS-Server 192.168.10.10 09:42:15 INFO Zweiter DNS-Server wird verwendet 09:42:16 INFO Name erfolgreich aufgelöst 09:42:16 ERROR HTTPS-Verbindung abgelehnt ``` Hier ist die DNS-Warnung möglicherweise nicht die unmittelbare Ursache, weil die Namensauflösung anschließend erfolgreich war. Die abgelehnte HTTPS-Verbindung muss getrennt untersucht werden.
5. Wie werden Datum, Uhrzeit und Zeitzone geprüft? | Aufgabe | Windows | Linux | macOS | |---|---|---|---| | Lokale Zeit | `[RO] Get-Date -Format o` | `[RO] date --iso-8601=seconds` | `[RO] date "+%Y-%m-%dT%H:%M:%S%z"` | | UTC-Zeit | `[RO] (Get-Date).ToUniversalTime().ToString("o")` | `[RO] date -u "+%Y-%m-%dT%H:%M:%SZ"` | `[RO] date -u "+%Y-%m-%dT%H:%M:%SZ"` | | Zeitzone | `[RO] Get-TimeZone` | `[RO] timedatectl status` | `[RO][PRIV] sudo systemsetup -gettimezone` | | Zeitquelle | `[RO] w32tm /query /source` | `[RO] timedatectl timesync-status` | `[TEST] sntp -d time.apple.com` | | Synchronisationsstatus | `[RO] w32tm /query /status` | `[RO] timedatectl status` | `[TEST] sntp -d time.apple.com` | | chrony-Status | Nicht zutreffend | `[RO] chronyc tracking` | Nicht standardmäßig vorhanden | | chrony-Quellen | Nicht zutreffend | `[RO] chronyc sources -v` | Nicht standardmäßig vorhanden | **Warum ist das wichtig?** Bereits wenige Minuten Zeitabweichung können die Zuordnung zwischen folgenden Systemen erschweren: - Client und Server, - Firewall und Anwendung, - Webserver und Datenbank, - Hypervisor und virtuelle Maschine, - Reverse Proxy und Backend, - Identitätsanbieter und Cloudanwendung. Ein Zeitstempel ohne Zeitzone ist nicht eindeutig. ```text 2026-07-31 14:30:00 ``` Ein Zeitstempel mit Offset ist eindeutig zuordenbar: ```text 2026-07-31T14:30:00+02:00 ``` UTC-Darstellung: ```text 2026-07-31T12:30:00Z ```
6. Wie werden Windows-Ereignisprotokolle grafisch untersucht? Die Windows-Ereignisanzeige wird mit folgendem Befehl geöffnet: ```cmd [RO] eventvwr.msc ``` Wichtige Protokollbereiche: | Protokoll | Typische Inhalte | |---|---| | Anwendung | Anwendungs-, Datenbank- und Laufzeitfehler | | Sicherheit | Anmeldungen, Kontoereignisse und überwachte Zugriffe | | Setup | Installation und Systemkonfiguration | | System | Treiber, Dienste, Netzwerk und Betriebssystem | | Weitergeleitete Ereignisse | zentral gesammelte Ereignisse anderer Systeme | | Anwendungs- und Dienstprotokolle | komponentenspezifische Windows-Protokolle | **Empfohlenes Vorgehen** 1. Passendes Protokoll auswählen. 2. `Aktuelles Protokoll filtern` verwenden. 3. Zeitraum auf den Störungszeitraum begrenzen. 4. Ereignisebene auswählen. 5. Falls bekannt, Quelle und Ereignis-ID eingeben. 6. Ereignis in der Detailansicht öffnen. 7. Allgemeine und XML-Ansicht vergleichen. 8. Ereignisse unmittelbar davor und danach untersuchen. 9. Relevante Ereignisse exportieren oder dokumentieren. **Wichtige Felder** - Protokollname, - Quelle beziehungsweise Provider, - Ereignis-ID, - Ebene, - Benutzer, - Opcode und Aufgabe, - Computername, - Zeitstempel, - Prozess- und Thread-ID, - Ereignisdaten. > Die XML-Ansicht kann Informationen enthalten, die in der allgemeinen Beschreibung nicht vollständig dargestellt werden.
7. Wie werden Windows-Ereignisse mit PowerShell gelesen? **Verfügbare Ereignisprotokolle auflisten** ```powershell [RO] Get-WinEvent -ListLog * | Select-Object LogName, RecordCount, IsEnabled, LogMode, MaximumSizeInBytes ``` Nur aktivierte Protokolle anzeigen: ```powershell [RO] Get-WinEvent -ListLog * | Where-Object IsEnabled | Sort-Object LogName | Select-Object LogName, RecordCount ``` **Neueste Ereignisse des Systemprotokolls** ```powershell [RO] Get-WinEvent -LogName System -MaxEvents 20 ``` **Neueste Ereignisse des Anwendungsprotokolls** ```powershell [RO] Get-WinEvent -LogName Application -MaxEvents 20 ``` **Ereignisse der letzten Stunde** ```powershell [RO] $Start = (Get-Date).AddHours(-1) Get-WinEvent -FilterHashtable @{ LogName = 'System' StartTime = $Start } ``` **Fehler und kritische Ereignisse der letzten 24 Stunden** ```powershell [RO] $Start = (Get-Date).AddHours(-24) Get-WinEvent -FilterHashtable @{ LogName = 'System' Level = 1, 2 StartTime = $Start } | Select-Object TimeCreated, Id, LevelDisplayName, ProviderName, Message ``` | Level | Windows-Ebene | |---:|---| | `1` | Kritisch | | `2` | Fehler | | `3` | Warnung | | `4` | Information | | `5` | Ausführlich | **Nach Ereignis-ID filtern** ```powershell [RO] Get-WinEvent -FilterHashtable @{ LogName = 'System' Id = 7036 } -MaxEvents 20 ``` **Nach Provider filtern** ```powershell [RO] Get-WinEvent -FilterHashtable @{ LogName = 'System' ProviderName = 'Service Control Manager' StartTime = (Get-Date).AddHours(-4) } ``` **Mehrere Ereignis-IDs abfragen** ```powershell [RO] Get-WinEvent -FilterHashtable @{ LogName = 'System' Id = 6005, 6006, 6008, 1074 StartTime = (Get-Date).AddDays(-7) } | Select-Object TimeCreated, Id, ProviderName, Message ``` **Ergebnis übersichtlich ausgeben** ```powershell [RO] Get-WinEvent -FilterHashtable @{ LogName = 'System' Level = 1, 2, 3 StartTime = (Get-Date).AddHours(-2) } | Select-Object TimeCreated, Id, LevelDisplayName, ProviderName, MachineName, Message | Format-List ``` **Nach Text in der Meldung suchen** ```powershell [RO] Get-WinEvent -LogName Application -MaxEvents 1000 | Where-Object Message -Match 'timeout|Zeitüberschreitung' ``` Die Filterung mit `FilterHashtable` erfolgt bereits beim Abruf und ist bei großen Protokollen effizienter als eine nachträgliche Filterung mit `Where-Object`. Eine Textsuche in der formatierten Nachricht erfordert jedoch häufig eine nachträgliche Auswertung.
8. Wie werden Windows-Ereignisse exportiert und archiviert? **Systemprotokoll als EVTX exportieren** ```cmd [RO][PRIV][FILE][SENS] wevtutil epl System C:\Temp\System.evtx ``` **Anwendungsprotokoll exportieren** ```cmd [RO][PRIV][FILE][SENS] wevtutil epl Application C:\Temp\Application.evtx ``` **Ereignisse mit PowerShell als CSV exportieren** ```powershell [RO][FILE][SENS] $Start = (Get-Date).AddHours(-2) Get-WinEvent -FilterHashtable @{ LogName = 'System' StartTime = $Start } | Select-Object TimeCreated, Id, LevelDisplayName, ProviderName, MachineName, Message | Export-Csv -Path 'C:\Temp\System-Events.csv' -NoTypeInformation -Encoding UTF8 ``` **Ereignisse als XML sichern** ```powershell [RO][FILE][SENS] Get-WinEvent -LogName System -MaxEvents 100 | Export-Clixml -Path 'C:\Temp\System-Events.xml' ``` **Verfügbare Protokolle mit wevtutil auflisten** ```cmd [RO] wevtutil el ``` **Letzte zehn Systemereignisse im Textformat anzeigen** ```cmd [RO] wevtutil qe System /c:10 /rd:true /f:text ``` | Option | Bedeutung | |---|---| | `qe` | Ereignisse abfragen | | `epl` | Protokoll exportieren | | `/c:10` | maximal zehn Ereignisse | | `/rd:true` | neueste Ereignisse zuerst | | `/f:text` | Textausgabe | | `/f:xml` | XML-Ausgabe | **Protokoll nicht während der Analyse löschen** Der folgende Befehl löscht ein Ereignisprotokoll und darf nicht als regulärer Diagnoseschritt verwendet werden: ```cmd [PRIV][CHANGE][DISRUPT] wevtutil cl System ``` Das Löschen vernichtet möglicherweise entscheidende Beweise und kann gegen betriebliche oder rechtliche Vorgaben verstoßen.
9. Wie werden Linux-Protokolle mit journalctl untersucht? Bei systemd-basierten Linux-Systemen werden viele Ereignisse im systemd-Journal gespeichert und mit `journalctl` ausgewertet. **Gesamtes Journal anzeigen** ```bash [RO] journalctl ``` **Neueste Einträge zuerst anzeigen** ```bash [RO] journalctl -r ``` **Aktuellen Systemstart untersuchen** ```bash [RO] journalctl -b ``` **Vorherigen Systemstart untersuchen** ```bash [RO] journalctl -b -1 ``` **Verfügbare Systemstarts anzeigen** ```bash [RO] journalctl --list-boots ``` **Nur Kernelmeldungen anzeigen** ```bash [RO] journalctl -k ``` **Kernelmeldungen des aktuellen Starts** ```bash [RO] journalctl -k -b ``` **Protokoll eines Dienstes anzeigen** ```bash [RO] journalctl -u ssh.service ``` ```bash [RO] journalctl -u nginx.service ``` **Protokoll eines Dienstes live verfolgen** ```bash [RO] journalctl -u nginx.service -f ``` Beenden mit: ```text Strg+C ``` **Ereignisse seit einem Zeitpunkt** ```bash [RO] journalctl --since "2026-07-31 09:30:00" ``` **Zeitfenster eingrenzen** ```bash [RO] journalctl \ --since "2026-07-31 09:30:00" \ --until "2026-07-31 10:00:00" ``` **Relative Zeitangaben** ```bash [RO] journalctl --since "30 minutes ago" ``` ```bash [RO] journalctl --since today ``` **Nach Priorität filtern** ```bash [RO] journalctl -p err ``` Fehler und schwerwiegendere Meldungen des aktuellen Starts: ```bash [RO] journalctl -b -p err ``` Warnungen und schwerwiegendere Meldungen eines Dienstes: ```bash [RO] journalctl -u nginx.service -p warning ``` | Priorität | Nummer | |---|---:| | emerg | `0` | | alert | `1` | | crit | `2` | | err | `3` | | warning | `4` | | notice | `5` | | info | `6` | | debug | `7` | Mit `-p warning` werden normalerweise `warning` und alle schwerwiegenderen Prioritäten angezeigt. **Nach Prozess-ID filtern** ```bash [RO] journalctl _PID=4321 ``` **Nach ausführbarer Datei filtern** ```bash [RO] journalctl _EXE=/usr/sbin/sshd ``` **Nach Benutzer-ID filtern** ```bash [RO] journalctl _UID=1000 ``` **Ausgabe ohne Pager** ```bash [RO] journalctl -u nginx.service --no-pager ``` **ISO-Zeitstempel verwenden** ```bash [RO] journalctl -u nginx.service -o short-iso ``` **Ausführliche Felder eines Ereignisses anzeigen** ```bash [RO] journalctl -u nginx.service -n 10 -o verbose ```
10. Wie wird der Status eines Linux-Dienstes einschließlich Logs geprüft? **Dienststatus anzeigen** ```bash [RO] systemctl status nginx.service ``` Ohne interaktiven Pager: ```bash [RO] systemctl status nginx.service --no-pager ``` Vollständige Zeilen ohne Kürzung: ```bash [RO] systemctl status nginx.service --no-pager --full ``` **Prüfen, ob der Dienst aktiv ist** ```bash [RO] systemctl is-active nginx.service ``` **Prüfen, ob der Dienst aktiviert ist** ```bash [RO] systemctl is-enabled nginx.service ``` **Fehlgeschlagene Units anzeigen** ```bash [RO] systemctl --failed ``` **Journal des Dienstes seit dem aktuellen Start** ```bash [RO] journalctl -b -u nginx.service ``` **Wichtige Unterscheidung** | Befehl | Aussage | |---|---| | `systemctl is-active` | Läuft die Unit aktuell? | | `systemctl is-enabled` | Ist ein automatischer Start konfiguriert? | | `systemctl status` | Status, PID und letzte Logmeldungen | | `journalctl -u` | ausführlicher zeitlicher Verlauf der Unit | Ein Dienst kann aktiviert, aber aktuell nicht aktiv sein. Umgekehrt kann ein manuell gestarteter Dienst aktiv sein, obwohl er nicht für den automatischen Start aktiviert wurde.
11. Wie werden klassische Linux-Protokolldateien gelesen? Abhängig von Distribution und Dienst befinden sich Textprotokolle häufig unter: ```text /var/log/ ``` Typische Beispiele: | Pfad | Möglicher Inhalt | |---|---| | `/var/log/syslog` | allgemeine Systemmeldungen bei Debian/Ubuntu | | `/var/log/messages` | allgemeine Systemmeldungen bei RHEL-artigen Systemen | | `/var/log/auth.log` | Authentifizierungsereignisse bei Debian/Ubuntu | | `/var/log/secure` | Authentifizierungsereignisse bei RHEL-artigen Systemen | | `/var/log/kern.log` | Kernelmeldungen | | `/var/log/dmesg` | gespeicherte Boot- und Kernelmeldungen | | `/var/log/nginx/` | Nginx-Zugriffs- und Fehlerprotokolle | | `/var/log/apache2/` | Apache-Protokolle bei Debian/Ubuntu | | `/var/log/httpd/` | Apache-Protokolle bei RHEL-artigen Systemen | Die tatsächlichen Pfade hängen von Distribution, Paket, Konfiguration und Protokollierungsdienst ab. Sie müssen deshalb auf dem konkreten System geprüft werden. **Datei mit less öffnen** ```bash [RO] less /var/log/syslog ``` Nützliche Tasten in `less`: | Taste | Funktion | |---|---| | `G` | zum Dateiende | | `g` | zum Dateianfang | | `/text` | vorwärts suchen | | `?text` | rückwärts suchen | | `n` | nächster Treffer | | `N` | vorheriger Treffer | | `q` | beenden | **Letzte Zeilen anzeigen** ```bash [RO] tail -n 50 /var/log/syslog ``` **Neue Zeilen live verfolgen** ```bash [RO] tail -f /var/log/syslog ``` **Datei auch nach Rotation weiterverfolgen** ```bash [RO] tail -F /var/log/nginx/error.log ``` `tail -F` versucht im Gegensatz zu `tail -f`, die Datei nach einer Rotation oder Neuerstellung erneut zu öffnen. **Bestimmten Begriff suchen** ```bash [RO] grep -i "error" /var/log/syslog ``` **Mehrere Begriffe suchen** ```bash [RO] grep -Ei "error|failed|timeout|denied" /var/log/syslog ``` **Zeilennummern anzeigen** ```bash [RO] grep -Ein "error|failed|timeout|denied" /var/log/syslog ``` **Treffer mit Kontext anzeigen** ```bash [RO] grep -Ein -B 3 -A 5 "timeout" /var/log/syslog ``` | Option | Bedeutung | |---|---| | `-i` | Groß- und Kleinschreibung ignorieren | | `-E` | erweiterte reguläre Ausdrücke | | `-n` | Zeilennummer anzeigen | | `-B 3` | drei Zeilen vor dem Treffer | | `-A 5` | fünf Zeilen nach dem Treffer | | `-C 5` | fünf Zeilen vor und nach dem Treffer |
12. Wie werden rotierte und komprimierte Linux-Logs durchsucht? Protokolle werden häufig rotiert, damit einzelne Dateien nicht unbegrenzt wachsen. Beispiel: ```text auth.log auth.log.1 auth.log.2.gz auth.log.3.gz ``` | Datei | Bedeutung | |---|---| | `auth.log` | aktuelles Protokoll | | `auth.log.1` | vorherige unkomprimierte Generation | | `auth.log.2.gz` | ältere komprimierte Generation | **Komprimiertes Protokoll anzeigen** ```bash [RO] zless /var/log/auth.log.2.gz ``` **Komprimiertes Protokoll durchsuchen** ```bash [RO] zgrep -i "failed" /var/log/auth.log.2.gz ``` **Mehrere rotierte Dateien durchsuchen** ```bash [RO] zgrep -Ei "failed|denied|timeout" /var/log/auth.log.*.gz ``` Aktuelle und ältere unkomprimierte Dateien durchsuchen: ```bash [RO] grep -Ei "failed|denied|timeout" /var/log/auth.log /var/log/auth.log.1 ``` Vor einer Analyse sollte geprüft werden, ob der Störungszeitpunkt bereits in einer rotierten Datei liegt.
13. Wie werden Kernel- und Hardwaremeldungen unter Linux geprüft? **Kernelmeldungen aus dem Journal** ```bash [RO] journalctl -k -b ``` **Klassische dmesg-Ausgabe** ```bash [RO][PRIV] sudo dmesg ``` Menschenlesbare Zeitstempel: ```bash [RO][PRIV] sudo dmesg --human ``` Nur Warnungen und Fehler anzeigen: ```bash [RO][PRIV] sudo dmesg --level=warn,err,crit,alert,emerg ``` Nach typischen Hardware- und Netzwerkproblemen suchen: ```bash [RO][PRIV] sudo dmesg --human | grep -Ei "error|failed|timeout|reset|link.*down|I/O" ``` Typische Hinweise: | Meldung | Mögliche Untersuchungsrichtung | |---|---| | `I/O error` | Datenträger, Kabel, Controller oder Dateisystem | | `link down` | Netzwerkkabel, Switchport, Treiber oder Interface | | `reset` | Gerät, Bus, Treiber oder Stromversorgung | | `out of memory` | Speicherdruck und OOM-Killer | | `segfault` | Programmfehler, Bibliothek oder Speicherproblem | | `read-only filesystem` | Dateisystemfehler oder Schutzreaktion | | `firmware failed to load` | fehlende oder inkompatible Firmware | Eine Meldung beschreibt zunächst nur eine Beobachtung. Beispielsweise kann ein `link down` durch das bewusste Abziehen eines Kabels entstanden sein.
14. Wie werden macOS-Protokolle mit der Konsole untersucht? Die App **Konsole** zeigt unter anderem: - Live-Protokollmeldungen, - System- und Anwendungsaktivitäten, - Absturzberichte, - Diagnoseberichte, - Spin- und Hang-Berichte, - Systemberichte. Öffnen über Spotlight: ```text Konsole ``` Oder über das Terminal: ```bash [RO] open -a Console ``` **Empfohlenes Vorgehen** 1. In der Seitenleiste den lokalen Mac auswählen. 2. Live-Anzeige nur für einen kurzen Zeitraum aktivieren. 3. Suchfeld nach Prozess, Subsystem, Kategorie oder Meldung filtern. 4. Fehler einmal reproduzieren. 5. Live-Anzeige wieder anhalten. 6. Ereignisse unmittelbar vor und nach dem Fehler untersuchen. 7. Detailbereich des Ereignisses öffnen. 8. Prozess, Subsystem, Kategorie und Zeitstempel dokumentieren. Abhängig von Benutzerrechten und Systemeinstellungen sind nicht alle Meldungen sichtbar. Für bestimmte Protokolle kann eine administrative Authentifizierung erforderlich sein.
15. Wie werden macOS-Protokolle mit log show ausgewertet? macOS verwendet das Unified Logging System. Historische Ereignisse werden mit `log show` untersucht. **Letzte zehn Minuten anzeigen** ```bash [RO] log show --last 10m ``` **Letzte Stunde anzeigen** ```bash [RO] log show --last 1h ``` **Kompakte Darstellung** ```bash [RO] log show --last 10m --style compact ``` **Nach Prozess filtern** ```bash [RO] log show \ --last 30m \ --style compact \ --predicate 'process == "Safari"' ``` **Nach Subsystem filtern** ```bash [RO] log show \ --last 30m \ --style compact \ --predicate 'subsystem == "com.apple.network"' ``` Das konkrete Subsystem muss zuvor aus einem passenden Ereignis ermittelt werden. Es darf nicht allein anhand des Produktnamens angenommen werden. **Nach Text in der Ereignismeldung suchen** ```bash [RO] log show \ --last 30m \ --style compact \ --predicate 'eventMessage CONTAINS[c] "error"' ``` **Mehrere Bedingungen kombinieren** ```bash [RO] log show \ --last 30m \ --style compact \ --predicate 'process == "Safari" AND eventMessage CONTAINS[c] "network"' ``` **Informations- und Debugmeldungen einbeziehen** ```bash [RO] log show \ --last 10m \ --info \ --debug \ --style compact ``` Debugmeldungen können sehr umfangreich sein. Das Zeitfenster sollte deshalb möglichst klein gewählt werden. **Bestimmtes Zeitfenster untersuchen** ```bash [RO] log show \ --start '2026-07-31 09:30:00' \ --end '2026-07-31 09:45:00' \ --style compact ``` > Datumsformat, Zeitzone und unterstützte Optionen sollten auf der eingesetzten macOS-Version mit `man log` beziehungsweise `log help show` geprüft werden.
16. Wie werden macOS-Protokolle live verfolgt? **Live-Ausgabe starten** ```bash [RO] log stream ``` **Kompakte Live-Ausgabe** ```bash [RO] log stream --style compact ``` **Bestimmten Prozess verfolgen** ```bash [RO] log stream \ --style compact \ --predicate 'process == "Safari"' ``` **Nach Meldungsinhalt filtern** ```bash [RO] log stream \ --style compact \ --predicate 'eventMessage CONTAINS[c] "timeout"' ``` **Informationsmeldungen einbeziehen** ```bash [RO] log stream --info --style compact ``` Beenden mit: ```text Strg+C ``` **Sicherer Ablauf** 1. Filter vorbereiten. 2. Live-Aufzeichnung starten. 3. Problem genau einmal reproduzieren. 4. Aufzeichnung sofort beenden. 5. Zeitstempel und relevante Ereignisse dokumentieren. Eine ungefilterte Live-Ausgabe kann sehr schnell unübersichtlich werden.
17. Wie werden Docker-Containerlogs untersucht? Docker schreibt standardmäßig die Standardausgabe und Standardfehlerausgabe eines Containers in den konfigurierten Logging-Treiber. Die tatsächlich verfügbaren Logs hängen deshalb von Container, Anwendung und Logging-Konfiguration ab. **Laufende Container anzeigen** ```bash [RO] docker ps ``` Auch beendete Container anzeigen: ```bash [RO] docker ps -a ``` **Logs eines Containers anzeigen** ```bash [RO][SENS] docker logs beispiel-container ``` **Letzte 100 Zeilen anzeigen** ```bash [RO][SENS] docker logs --tail 100 beispiel-container ``` **Zeitstempel einblenden** ```bash [RO][SENS] docker logs --timestamps --tail 100 beispiel-container ``` **Logs live verfolgen** ```bash [RO][SENS] docker logs --follow --tail 100 beispiel-container ``` **Logs seit einem relativen Zeitpunkt** ```bash [RO][SENS] docker logs --since 30m beispiel-container ``` **Logs seit einem absoluten Zeitpunkt** ```bash [RO][SENS] docker logs \ --since "2026-07-31T09:30:00+02:00" \ beispiel-container ``` **Zeitfenster begrenzen** ```bash [RO][SENS] docker logs \ --since "2026-07-31T09:30:00+02:00" \ --until "2026-07-31T09:45:00+02:00" \ --timestamps \ beispiel-container ``` **Docker-Compose-Dienste anzeigen** ```bash [RO] docker compose ps ``` **Logs eines Compose-Dienstes** ```bash [RO][SENS] docker compose logs --tail 100 beispiel-dienst ``` **Compose-Logs live verfolgen** ```bash [RO][SENS] docker compose logs --follow --tail 100 beispiel-dienst ``` **Wichtige Grenzen** - Nicht jede Anwendung schreibt alle Fehler nach `stdout` oder `stderr`. - Ein Container kann zusätzlich interne Logdateien verwenden. - Ein nicht mehr vorhandener Container kann auch nicht mehr direkt mit `docker logs` abgefragt werden. - Logrotation und Logging-Treiber beeinflussen die Verfügbarkeit. - Das Fehlen einer Meldung beweist nicht, dass kein Fehler aufgetreten ist.
18. Wie werden Webserver- und Reverse-Proxy-Logs interpretiert? Webserver führen häufig mindestens zwei getrennte Protokolle: | Protokoll | Inhalt | |---|---| | Access Log | eingegangene HTTP-Anfragen und Antwortstatus | | Error Log | interne Fehler, Verbindungsprobleme und Konfigurationshinweise | Typischer Access-Log-Eintrag: ```text 192.0.2.50 - - [31/Jul/2026:09:42:15 +0200] "GET /login HTTP/1.1" 502 157 ``` | Bestandteil | Bedeutung | |---|---| | `192.0.2.50` | Client-IP-Adresse | | Zeitstempel | Zeitpunkt und Zeitzone | | `GET` | HTTP-Methode | | `/login` | angeforderter Pfad | | `HTTP/1.1` | Protokollversion | | `502` | HTTP-Statuscode | | `157` | übertragene Antwortgröße, abhängig vom Logformat | **Wichtige HTTP-Statusgruppen** | Bereich | Bedeutung | |---:|---| | `1xx` | Information | | `2xx` | erfolgreiche Verarbeitung | | `3xx` | Umleitung | | `4xx` | Anfrage konnte aus Clientsicht nicht verarbeitet werden | | `5xx` | serverseitige Verarbeitung fehlgeschlagen | Typische Statuscodes: | Status | Bedeutung | Untersuchungsrichtung | |---:|---|---| | `200` | Anfrage erfolgreich | Inhalt und Antwortzeit prüfen | | `301`/`302` | Umleitung | Ziel und Weiterleitungskette prüfen | | `400` | ungültige Anfrage | Header, Syntax und Proxy prüfen | | `401` | Authentifizierung erforderlich oder fehlgeschlagen | Anmeldedaten und Authentifizierungsdienst | | `403` | Zugriff verweigert | Berechtigungen und Regeln | | `404` | Ressource nicht gefunden | Pfad, Routing und Deployment | | `429` | zu viele Anfragen | Rate-Limit und Last | | `500` | interner Serverfehler | Anwendungslog prüfen | | `502` | ungültige Antwort vom Backend | Backend-Erreichbarkeit und Proxy | | `503` | Dienst nicht verfügbar | Dienststatus, Wartung und Kapazität | | `504` | Zeitüberschreitung zum Backend | Backend-Laufzeit, Netzwerk und Timeout | Ein `502` wird häufig am Reverse Proxy sichtbar, obwohl die eigentliche Ursache im Backenddienst liegt. Deshalb müssen Proxy- und Backend-Logs über Zeitstempel, Pfad und Korrelations-ID verbunden werden.
19. Wie werden Authentifizierungsfehler untersucht? Bei Anmeldeproblemen können mehrere Systeme beteiligt sein: ```text Client → Anwendung → Reverse Proxy → Identitätsanbieter → Verzeichnisdienst → MFA-Dienst ``` **Zu erfassende Informationen** - exakter Zeitpunkt, - Benutzerkennung, - Client und Quell-IP, - Zielanwendung, - Authentifizierungsverfahren, - verwendeter Identitätsanbieter, - Korrelations- oder Request-ID, - Fehlercode, - Ergebnis einer Vergleichsanmeldung, - mögliche Uhrzeitabweichung. **Typische Ursachen** | Beobachtung | Mögliche Untersuchungsrichtung | |---|---| | Benutzer unbekannt | falscher Mandant, falsche Domäne oder Synchronisation | | Kennwort abgelehnt | falsches Kennwort, Kontosperre oder abgelaufenes Kennwort | | Token abgelaufen | Zeitabweichung oder zu lange Sitzung | | Zertifikat ungültig | Ablaufdatum, Vertrauenskette oder Hostname | | MFA fehlgeschlagen | Endgerät, Push-Dienst oder Richtlinie | | Zugriff verweigert | Rolle, Gruppe oder Conditional-Access-Regel | | LDAP nicht erreichbar | DNS, Routing, Port, TLS oder Dienststatus | | Wiederholte Fehlversuche | gespeicherte alte Zugangsdaten oder automatischer Dienst | Authentifizierungsprotokolle enthalten besonders schützenswerte Informationen. Kennwörter, Tokens oder Cookies dürfen nicht in die Dokumentation kopiert werden.
20. Wie werden Meldungen verschiedener Systeme miteinander korreliert? **Beispiel einer verteilten Anfrage** ```text 09:42:15.120 Client sendet Anfrage 09:42:15.145 Reverse Proxy nimmt Anfrage an 09:42:15.151 Backend beginnt Verarbeitung 09:42:20.152 Backend meldet Datenbank-Timeout 09:42:20.153 Reverse Proxy erhält keine gültige Antwort 09:42:20.154 Client erhält HTTP 504 ``` Der `504`-Fehler auf dem Client ist hier eine Folge. Der erste technisch relevante Fehler ist der Datenbank-Timeout im Backend. **Geeignete Korrelationsmerkmale** | Merkmal | Nutzen | |---|---| | Zeitstempel | grobe zeitliche Zuordnung | | Request-ID | eindeutige Anfrageverfolgung | | Trace-ID | verteilte Ablaufverfolgung | | Session-ID | Zuordnung zu einer Sitzung | | Benutzer-ID | Zuordnung zu einem Konto | | Quell-IP | Zuordnung zu einem Client | | Zielpfad | Zuordnung zu einer Funktion | | Prozess-ID | Zuordnung zu einem lokalen Prozess | | Transaktions-ID | Zuordnung zu einem Geschäftsvorgang | **Korrelationsregel** ```text Gleiche Uhrzeit allein ist kein Beweis für denselben Vorgang. ``` Je mehr Merkmale übereinstimmen, desto belastbarer ist die Zuordnung.
21. Wie wird nach Fehlercodes und Meldungen gesucht? Vor der Internetrecherche sollten folgende Angaben vollständig erfasst werden: - Produktname, - Produktversion, - Betriebssystemversion, - Provider oder Quelle, - Ereignis-ID, - vollständiger Fehlercode, - genaue Fehlermeldung, - betroffene Funktion, - Zeitpunkt und Kontext. **Gute Suchanfrage** ```text Microsoft-Windows-DNS-Client Event ID 1014 Windows 11 ``` **Ungenaue Suchanfrage** ```text Internet geht nicht Fehler ``` **Quellenreihenfolge** 1. offizielle Herstellerdokumentation, 2. offizielle Knowledge Base oder Supportartikel, 3. offizielle Quellcode-Repositories und Issue-Tracker, 4. Dokumentation des eingesetzten Projekts, 5. seriöse Fachquellen, 6. Community-Beiträge als ergänzende Hinweise. Ein Community-Beitrag kann eine nützliche Hypothese liefern, ersetzt aber keine Prüfung am eigenen System.
22. Welche typischen Fehler werden bei der Log-Analyse gemacht? | Fehler | Folge | Besseres Vorgehen | |---|---|---| | Nur nach dem Wort `error` suchen | relevante Warnungen und Statusmeldungen fehlen | Dienst, Zeitfenster und Ereigniskette prüfen | | Nur das letzte Ereignis betrachten | ursprüngliche Ursache wird übersehen | zeitlich rückwärts zum ersten relevanten Fehler gehen | | Zeitzonen ignorieren | Ereignisse werden falsch zugeordnet | Zeit und UTC-Offset dokumentieren | | Gesamtes Log ungefiltert lesen | relevante Ereignisse gehen in der Menge unter | Zeitfenster und Quelle begrenzen | | Logs vor Sicherung löschen | Beweise gehen verloren | zuerst exportieren und Integrität sichern | | Debug-Logging dauerhaft aktivieren | Speicherplatz- und Datenschutzprobleme | kurzzeitig aktivieren und danach zurücksetzen | | Fehlermeldung isoliert suchen | falsche Produkt- oder Versionslösung | Quelle, Version und Kontext ergänzen | | Nur ein System prüfen | verteilte Ursache bleibt verborgen | alle beteiligten Systeme korrelieren | | Fehlerhäufigkeit nicht beachten | Einzelereignis wird überbewertet | Häufigkeit und Vergleichswerte prüfen | | Geheimnisse in Tickets kopieren | Sicherheitsvorfall möglich | Daten vor Weitergabe redigieren | | Logdatei während der Analyse verändern | Beweiskraft sinkt | Original sichern und Arbeitskopie verwenden | | Nur Fehlermeldungen berücksichtigen | erfolgreicher Fallback wird übersehen | gesamte Ereigniskette betrachten |
23. Wie wird eine aussagekräftige Ereigniskette erstellt? Eine gute Ereigniskette enthält nicht sämtliche Logzeilen, sondern die für den Vorgang relevanten Ereignisse. | Zeit | System | Quelle | Ereignis | Bedeutung | |---|---|---|---|---| | 09:42:10.100 | CLIENT-023 | Anwendung | Anfrage gestartet | Benutzeraktion beginnt | | 09:42:10.130 | PROXY-01 | Nginx | Anfrage angenommen | Proxy ist erreichbar | | 09:42:10.150 | APP-01 | Backend | DB-Abfrage gestartet | Backend verarbeitet Anfrage | | 09:42:15.151 | APP-01 | Backend | DB-Timeout | erster belegter Fehler | | 09:42:15.152 | PROXY-01 | Nginx | Upstream timeout | Folgefehler | | 09:42:15.160 | CLIENT-023 | Anwendung | HTTP 504 | sichtbare Auswirkung | **Auswertung** ```text Symptom: Client erhält HTTP 504. Erster belegter Fehler: Datenbank-Timeout auf APP-01. Folgefehler: Reverse Proxy erhält keine rechtzeitige Backend-Antwort. Nächster Prüfschritt: Datenbankerreichbarkeit, Datenbanklast und Abfragedauer im Zeitraum 09:42:10 bis 09:42:15 untersuchen. ```
24. Kompakte Befehlsübersicht für Windows, Linux und macOS | Aufgabe | Windows | Linux | macOS | |---|---|---|---| | Grafische Loganzeige öffnen | `[RO] eventvwr.msc` | abhängig von Desktop und Distribution | `[RO] open -a Console` | | Neueste Systemereignisse | `[RO] Get-WinEvent -LogName System -MaxEvents 20` | `[RO] journalctl -n 20` | `[RO] log show --last 10m --style compact` | | Aktuellen Start untersuchen | Ereignis-IDs und Startzeit filtern | `[RO] journalctl -b` | `[RO] log show --last boot --style compact` | | Vorherigen Start untersuchen | Systemprotokoll nach vorherigem Startzeitraum filtern | `[RO] journalctl -b -1` | über Zeitfenster beziehungsweise Logarchiv | | Kernelmeldungen | Systemprotokoll und providerspezifische Logs | `[RO] journalctl -k -b` | `[RO] log show --last 1h --predicate 'process == "kernel"'` | | Letzte Stunde | `Get-WinEvent` mit `StartTime=(Get-Date).AddHours(-1)` | `[RO] journalctl --since "1 hour ago"` | `[RO] log show --last 1h` | | Dienstprotokoll | nach Provider oder Dienstprotokoll filtern | `[RO] journalctl -u nginx.service` | nach `process` oder `subsystem` filtern | | Live-Anzeige | Ereignisanzeige oder providerspezifisch | `[RO] journalctl -f` | `[RO] log stream --style compact` | | Fehler filtern | `Get-WinEvent` mit `Level=1,2` | `[RO] journalctl -p err` | Predicate nach Prozess, Typ oder Meldung | | Textdatei lesen | `[RO] Get-Content .\app.log` | `[RO] less /var/log/app.log` | `[RO] less /Pfad/app.log` | | Letzte 50 Zeilen | `[RO] Get-Content .\app.log -Tail 50` | `[RO] tail -n 50 /var/log/app.log` | `[RO] tail -n 50 /Pfad/app.log` | | Datei live verfolgen | `[RO] Get-Content .\app.log -Wait -Tail 50` | `[RO] tail -F /var/log/app.log` | `[RO] tail -F /Pfad/app.log` | | Text suchen | `[RO] Select-String -Path .\app.log -Pattern 'error'` | `[RO] grep -i 'error' /var/log/app.log` | `[RO] grep -i 'error' /Pfad/app.log` | | Komprimiertes Log lesen | abhängig vom Archivformat | `[RO] zless /var/log/app.log.2.gz` | `[RO] gzcat /Pfad/app.log.gz \| less` | | Ereignisse exportieren | `[FILE][SENS] wevtutil epl System C:\Temp\System.evtx` | `[FILE][SENS] journalctl --since today > journal.txt` | `[FILE][SENS] log show --last 1h > macos-log.txt` | | Containerlogs | `[RO][SENS] docker logs --tail 100 NAME` | `[RO][SENS] docker logs --tail 100 NAME` | `[RO][SENS] docker logs --tail 100 NAME` | > `log show --last boot` kann je nach eingesetzter macOS-Version beziehungsweise Werkzeugsyntax nicht verfügbar sein. Die lokal unterstützten Optionen sind mit `log help show` zu prüfen. Ein festes Zeitfenster mit `--start` und `--end` ist die eindeutigere Alternative.
25. Dokumentationsvorlage für eine Log-Analyse ```text Ticketnummer: Analysedatum: Betroffenes System: Betriebssystem: Anwendung oder Dienst: Anwendungsversion: Betroffener Benutzer: Fehlerbeschreibung: Fehlerzeitpunkt: Zeitzone: Letzter funktionierender Zeitpunkt: Reproduzierbar: Ja / Nein Untersuchte Protokolle: - - - Verwendete Filter: - Zeitraum: - Quelle/Provider: - Ereignis-ID: - Prozess/PID: - Dienst/Unit: - Benutzer/UID: - Korrelations-ID: - Suchbegriffe: Erster relevanter Fehler: Zeitpunkt: System: Quelle: Ereignis-ID oder Fehlercode: Vollständige Meldung: Vorhergehende Ereignisse: - - - Nachfolgende Ereignisse: - - - Ereigniskette: 1. 2. 3. 4. Arbeitshypothese: Begründung: Kontrollierter Test: Testergebnis: Ermittelte Ursache: Durchgeführte Änderung: Rückweg: Abschlussprüfung: Gesicherte Dateien: - EVTX: - Journal: - Textlog: - CSV: - Diagnosearchiv: Original unverändert gesichert: Ja / Nein Sensible Daten redigiert: Ja / Nein Speicherort: Zugriffsberechtigung: Aufbewahrungs- oder Löschfrist: ```
26. Offizielle Quellen und weiterführende Dokumentation **Microsoft** - [Get-WinEvent – Microsoft Learn](https://learn.microsoft.com/powershell/module/microsoft.powershell.diagnostics/get-winevent) - [wevtutil – Microsoft Learn](https://learn.microsoft.com/windows-server/administration/windows-commands/wevtutil) - [Windows-Ereignisprotokollierung – Microsoft Learn](https://learn.microsoft.com/windows/win32/wes/windows-event-log) **Linux und systemd** - [journalctl – systemd-Dokumentation](https://www.freedesktop.org/software/systemd/man/latest/journalctl.html) - [systemctl – systemd-Dokumentation](https://www.freedesktop.org/software/systemd/man/latest/systemctl.html) - [systemd-journald – systemd-Dokumentation](https://www.freedesktop.org/software/systemd/man/latest/systemd-journald.service.html) - [systemd Journal Fields](https://www.freedesktop.org/software/systemd/man/latest/systemd.journal-fields.html) **Apple** - [Konsole – Benutzerhandbuch für macOS](https://support.apple.com/guide/console/welcome/mac) - [Protokollmeldungen in der Konsole anzeigen](https://support.apple.com/guide/console/view-log-messages-cnsl1012/mac) - [Protokollmeldungen und Aktivitäten suchen](https://support.apple.com/guide/console/find-log-messages-and-activities-cnslbf30b61a/mac) - Lokale Befehlsreferenz: `man log` und `log help` **Docker** - [docker logs – Docker-Dokumentation](https://docs.docker.com/reference/cli/docker/container/logs/) - [Docker Logging Drivers](https://docs.docker.com/engine/logging/) - [docker compose logs](https://docs.docker.com/reference/cli/docker/compose/logs/) > Befehlsoptionen, Protokollpfade und verfügbare Felder können von Betriebssystem-, Distributions- und Anwendungsversion abhängen. Vor dem produktiven Einsatz ist deshalb zusätzlich die lokale Hilfeseite des konkreten Systems zu prüfen.
# 2.13 Monitoringdaten und Leistungswerte richtig interpretieren Monitoring erfasst den Zustand von Systemen und Diensten über einen längeren Zeitraum. Im Gegensatz zu einer einzelnen Momentaufnahme zeigt es Entwicklungen, wiederkehrende Muster und Zusammenhänge zwischen verschiedenen Messwerten. Monitoringdaten helfen unter anderem bei folgenden Fragen: - Wann begann eine Leistungsverschlechterung? - Ist ein Problem dauerhaft, periodisch oder nur kurzfristig? - Welche Ressource ist ausgelastet oder überlastet? - Betrifft die Störung einen einzelnen Host oder mehrere Systeme? - Tritt das Problem nur zu bestimmten Tageszeiten auf? - Gab es unmittelbar vorher ein Update, Deployment oder Backup? - Steigt die Fehlerrate gleichzeitig mit der Antwortzeit? - Wird eine technische Auffälligkeit von Benutzern tatsächlich wahrgenommen? - Entwickelt sich ein Wert langsam in Richtung eines Kapazitätsproblems? - Fehlen Messwerte, weil der Zielhost oder nur das Monitoring ausgefallen ist? > **Grundregel:** Ein einzelner hoher Messwert beweist noch keine Ursache. Entscheidend sind Verlauf, Dauer, Vergleichswerte, Benutzerwirkung und die Korrelation mit anderen Signalen. ---
1. Kennzeichnungen und Sicherheitsregeln | Kennzeichnung | Bedeutung | |---|---| | `[RO]` | Liest Informationen aus, ohne den Zustand absichtlich zu verändern | | `[TEST]` | Führt eine aktive Messung durch oder erzeugt zusätzliche Last | | `[PRIV]` | Benötigt möglicherweise Administrator- oder Root-Rechte | | `[FILE]` | Erzeugt oder verändert eine Datei | | `[SENS]` | Ausgabe kann vertrauliche Daten enthalten | | `[CHANGE]` | Verändert Einstellungen oder den Systemzustand | | `[DISRUPT]` | Kann Dienste oder Systeme beeinträchtigen | Monitoringdaten können vertrauliche Informationen enthalten: - Hostnamen und IP-Adressen, - Benutzer- und Prozessnamen, - interne URLs und Dienstbezeichnungen, - Standort- und Kundenzuordnungen, - Kapazitäts- und Auslastungsdaten, - Datenbank- und Mandantennamen, - Informationen über Sicherheits- und Netzwerkinfrastruktur. Dashboards, Exporte und Screenshots dürfen deshalb nur kontrolliert weitergegeben werden.
2. Was ist der Unterschied zwischen Monitoring und Observability? | Begriff | Bedeutung | |---|---| | Monitoring | Erfasst vorher festgelegte Zustände und Messwerte | | Logging | Dokumentiert einzelne Ereignisse und Meldungen | | Metriken | Numerische Werte über einen Zeitraum | | Tracing | Verfolgt eine Anfrage durch mehrere Komponenten | | Observability | Ermöglicht, den internen Systemzustand aus Metriken, Logs und Traces abzuleiten | | Alerting | Meldet definierte Zustände oder Abweichungen | | Dashboard | Visualisiert ausgewählte Messwerte | | Profiling | Untersucht, wo ein Programm Rechenzeit oder Speicher verwendet | **Zusammenhang** ```text Metrik zeigt: Die Antwortzeit ist seit 09:42 Uhr erhöht. Log zeigt: Datenbankabfragen laufen in ein Timeout. Trace zeigt: Die Verzögerung entsteht im Datenbankzugriff. Profiling zeigt: Eine bestimmte Funktion erzeugt besonders teure Abfragen. ``` Monitoring zeigt häufig, **dass** ein Problem besteht. Logs, Traces und weitere Diagnosewerkzeuge helfen anschließend festzustellen, **warum** es besteht.
3. Wie wird eine Baseline erstellt? Eine Baseline beschreibt den normalen Zustand eines Systems unter vergleichbaren Bedingungen. Sinnvolle Vergleichszeiträume sind beispielsweise: - gleicher Wochentag der Vorwoche, - gleiche Uhrzeit an mehreren Werktagen, - Zeitraum vor einem Update, - Zeitraum mit ähnlicher Benutzerzahl, - funktionierendes Referenzsystem, - Normalbetrieb außerhalb eines Backups, - typischer Monats- oder Quartalsverlauf. **Beispiel** | Messwert | Normalbetrieb | Störungszeitraum | |---|---:|---:| | CPU-Auslastung | 25–45 % | 85–100 % | | Antwortzeit p95 | 180–260 ms | 3.800 ms | | Fehlerrate | 0,2 % | 12 % | | Datenbankverbindungen | 20–35 | 100 | | Datenträgerlatenz | 2–8 ms | 140 ms | | Anfragen pro Sekunde | 100–140 | 110 | Da die Anfragemenge nahezu unverändert ist, die Antwortzeit, Fehlerrate und Datenträgerlatenz aber stark gestiegen sind, sollte die Untersuchung auf Datenträger und Datenbank konzentriert werden. **Eine sinnvolle Baseline berücksichtigt:** - Tages- und Wochenmuster, - Geschäftszeiten, - Backups und Wartungsfenster, - geplante Batch-Verarbeitung, - saisonale Last, - unterschiedliche Hardware, - unterschiedliche Softwareversionen, - Anzahl der Benutzer oder Anfragen. Ein Grenzwert ohne Baseline ist häufig willkürlich.
4. Welche Arten von Metriken gibt es? | Metriktyp | Verhalten | Beispiel | |---|---|---| | Counter | steigt normalerweise an und kann bei Neustart zurückgesetzt werden | Gesamtzahl der HTTP-Anfragen | | Gauge | kann steigen und fallen | aktuelle Speichernutzung | | Histogram | zählt Beobachtungen in Wertebereichen | Verteilung von Antwortzeiten | | Summary | berechnet Beobachtungen und Quantile clientseitig | Antwortzeitquantile | | Rate | Änderung eines Counters pro Zeiteinheit | Fehler pro Sekunde | | Ratio | Verhältnis zweier Werte | Fehleranteil an allen Anfragen | **Counter** ```text requests_total = 150000 ``` Der Gesamtwert ist für eine aktuelle Belastung meist weniger aussagekräftig als seine Änderungsrate. PromQL-Beispiel: ```promql rate(http_requests_total[5m]) ``` **Gauge** ```text active_connections = 42 ``` Der Wert beschreibt den aktuellen Zustand und kann steigen oder fallen. PromQL-Beispiele: ```promql avg_over_time(active_connections[15m]) ``` ```promql max_over_time(active_connections[15m]) ``` **Fehlerrate berechnen** ```promql sum(rate(http_requests_total{status=~"5.."}[5m])) / sum(rate(http_requests_total[5m])) ``` Für eine Prozentdarstellung: ```promql 100 * sum(rate(http_requests_total{status=~"5.."}[5m])) / sum(rate(http_requests_total[5m])) ``` > `rate()` ist für Counter vorgesehen. Auf einen Gauge angewendet würde die Abfrage inhaltlich meist keinen sinnvollen Messwert ergeben.
5. Welche Messstrategien eignen sich für Infrastruktur und Dienste? **USE-Methode für Ressourcen** | Buchstabe | Bedeutung | Fragestellung | |---|---|---| | U | Utilization | Wie stark wird die Ressource verwendet? | | S | Saturation | Gibt es Warteschlangen oder Rückstau? | | E | Errors | Treten Fehler auf? | Beispiel für einen Datenträger: | USE-Bereich | Messwert | |---|---| | Utilization | aktive Zeit des Datenträgers | | Saturation | Warteschlangenlänge | | Errors | I/O-Fehler und Timeouts | **RED-Methode für Dienste** | Buchstabe | Bedeutung | Fragestellung | |---|---|---| | R | Rate | Wie viele Anfragen werden verarbeitet? | | E | Errors | Wie viele Anfragen schlagen fehl? | | D | Duration | Wie lange dauert die Verarbeitung? | **Golden Signals** | Signal | Bedeutung | |---|---| | Latency | Dauer einer Anfrage | | Traffic | aktuelle Nutzung oder Anfragemenge | | Errors | fehlgeschlagene Operationen | | Saturation | Annäherung an eine Kapazitätsgrenze | USE hilft besonders bei der Untersuchung technischer Ressourcen. RED und die Golden Signals zeigen stärker die tatsächliche Benutzerwirkung.
6. Wie werden Durchschnitt, Maximum und Perzentile interpretiert? **Beispiel für zehn Antwortzeiten** ```text 100, 110, 115, 120, 125, 130, 140, 150, 200, 5000 ms ``` Der Durchschnitt wird durch den einzelnen sehr langsamen Wert deutlich beeinflusst. Gleichzeitig kann ein Durchschnitt die Verteilung und einzelne besonders langsame Anfragen verbergen. | Kennzahl | Aussage | |---|---| | Minimum | kleinster gemessener Wert | | Maximum | größter gemessener Wert | | Durchschnitt | arithmetischer Mittelwert | | Median beziehungsweise p50 | 50 % der Werte liegen höchstens hier | | p90 | 90 % der Werte liegen höchstens hier | | p95 | 95 % der Werte liegen höchstens hier | | p99 | 99 % der Werte liegen höchstens hier | **Beispiel** ```text p50 = 120 ms p95 = 800 ms p99 = 4.500 ms ``` Interpretation: - Die typische Anfrage ist schnell. - Ein kleinerer Anteil der Anfragen ist deutlich langsamer. - Der Durchschnitt allein würde das Benutzerproblem möglicherweise verbergen. **Wichtig:** - Ein Perzentil ist kein Prozentwert der Auslastung. - p95 bedeutet nicht, dass 95 % der Anfragen fehlerhaft sind. - Perzentile verschiedener Gruppen dürfen nicht ohne Weiteres gemittelt werden. - Bei sehr wenigen Messwerten können hohe Perzentile wenig belastbar sein. - Erfolgreiche und fehlgeschlagene Anfragen sollten gegebenenfalls getrennt betrachtet werden.
7. Wie wird CPU-Auslastung richtig interpretiert? Hohe CPU-Auslastung bedeutet zunächst nur, dass Rechenzeit verwendet wird. Sie kann sowohl normal als auch problematisch sein. **Zu prüfende Fragen** - Betrifft die Auslastung einen einzelnen Kern oder alle Kerne? - Welcher Prozess verursacht sie? - Ist die Auslastung nur kurzzeitig oder dauerhaft? - Steigt gleichzeitig die Antwortzeit? - Gibt es eine CPU-Warteschlange? - Entsteht die Last im Benutzer-, Kernel- oder Interrupt-Kontext? - Ist die CPU tatsächlich ausgelastet oder wartet das System auf I/O? - Wird die CPU durch Virtualisierung oder Container begrenzt? - Tritt Drosselung durch Temperatur oder Leistungsgrenzen auf? **Typische CPU-Zustände unter Linux** | Zustand | Bedeutung | |---|---| | `us` | Zeit für Benutzerprozesse | | `sy` | Zeit im Kernel | | `id` | Leerlauf | | `wa` | Warten auf I/O | | `st` | Zeit, die einer VM durch den Hypervisor entzogen wurde | | `hi` | Hardware-Interrupts | | `si` | Software-Interrupts | **Beispiele** | Beobachtung | Untersuchungsrichtung | |---|---| | hohes `us` | Anwendungsprozess, Berechnung oder Schleife | | hohes `sy` | Kernel, Treiber, Systemaufrufe oder Netzwerk | | hohes `wa` | Datenträger oder anderes blockierendes I/O | | hohes `st` in VM | Überbelegung oder Belastung des Hypervisors | | hohe Interruptlast | Netzwerkadapter, Treiber oder Hardware | | ein Kern bei 100 % | möglicherweise einzelner nicht parallelisierter Thread | **Windows** ```powershell [RO] Get-Counter '\Processor(_Total)\% Processor Time' ``` Alle logischen Prozessoren: ```powershell [RO] Get-Counter '\Processor(*)\% Processor Time' ``` Prozessbezogene CPU-Werte: ```powershell [RO] Get-Counter '\Process(*)\% Processor Time' ``` Mehrere Messungen im Abstand von zwei Sekunden: ```powershell [RO] Get-Counter '\Processor(_Total)\% Processor Time' ` -SampleInterval 2 ` -MaxSamples 10 ``` **Linux** ```bash [RO] uptime ``` ```bash [RO] top ``` ```bash [RO] vmstat 1 10 ``` Falls `sysstat` installiert ist: ```bash [RO] mpstat -P ALL 1 10 ``` Prozesse nach CPU-Auslastung sortieren: ```bash [RO] ps -eo pid,ppid,user,%cpu,%mem,comm --sort=-%cpu | head ``` **macOS** ```bash [RO] top -l 1 -o cpu ``` ```bash [RO] ps -Ao pid,ppid,user,%cpu,%mem,comm -r | head ``` > Eine kurzzeitige CPU-Auslastung von 100 % ist nicht automatisch ein Problem. Kritisch wird sie insbesondere dann, wenn sie länger anhält, Warteschlangen erzeugt und gleichzeitig die Antwortzeit oder Fehlerrate steigt.
8. Was bedeutet Load Average unter Linux und macOS? Load Average wird typischerweise für die letzten 1, 5 und 15 Minuten angezeigt: ```bash [RO] uptime ``` Beispiel: ```text load average: 8.20, 6.10, 3.40 ``` Die Werte sind keine Prozentwerte. Unter Linux umfasst die Last unter anderem ausführbare beziehungsweise auf CPU wartende Tasks und Tasks in nicht unterbrechbarem Wartezustand, beispielsweise bei bestimmten I/O-Vorgängen. **Logische CPUs bestimmen** Linux: ```bash [RO] nproc ``` macOS: ```bash [RO] sysctl -n hw.logicalcpu ``` **Vereinfachtes Beispiel** ```text 8 logische CPUs Load Average 1 Minute: 8 ``` Das kann bedeuten, dass die ausführbaren Kapazitäten ungefähr vollständig beansprucht sind. Die genaue Bewertung erfordert jedoch zusätzliche Informationen. ```text 8 logische CPUs Load Average 1 Minute: 16 ``` Das deutet auf mehr gleichzeitig wartende oder nicht unterbrechbar blockierte Tasks hin, als unmittelbar abgearbeitet werden können. **Wichtige Einschränkungen** - Load Average ist nicht gleich CPU-Auslastung. - I/O-Wartezustände können die Load erhöhen. - Container sehen je nach Konfiguration Host- oder begrenzte Ressourcen. - CPU-Quotas und virtuelle CPUs müssen berücksichtigt werden. - Ein Wert ist nur im Verhältnis zur verfügbaren Kapazität sinnvoll.
9. Wie wird Arbeitsspeicher richtig interpretiert? Ein fast vollständig belegter physischer Arbeitsspeicher bedeutet nicht automatisch Speichermangel. Betriebssysteme verwenden freien Speicher unter anderem als Cache. Wichtiger als der reine Wert „belegt“ sind: - verfügbarer Speicher, - Speicherdruck, - Paging- beziehungsweise Swap-Aktivität, - Commit-Nutzung, - OOM-Ereignisse, - Entwicklung des Prozessspeichers, - Antwortzeit des Systems. **Begriffe** | Begriff | Bedeutung | |---|---| | Physical Memory | tatsächlich vorhandener RAM | | Available | kurzfristig für Anwendungen verfügbarer Speicher | | Cache | für schnellere Zugriffe verwendeter Speicher | | Working Set | aktuell im RAM befindliche Seiten eines Prozesses | | Private Bytes | nur einem Prozess zugeordneter zugesicherter Speicher | | Commit | zugesicherter virtueller Speicher | | Pagefile beziehungsweise Swap | Auslagerungsspeicher | | Page Fault | Zugriff auf nicht aktuell passend zugeordnete Speicherseite | | Hard Page Fault | benötigte Seite muss aus Datei oder Auslagerung geladen werden | Viele Page Faults sind normal. Erst eine anhaltend hohe Rate teurer Datenträgerzugriffe zusammen mit Speicherdruck und schlechter Leistung ist ein deutlicher Problemhinweis. **Windows** ```powershell [RO] Get-Counter '\Memory\Available MBytes' ``` ```powershell [RO] Get-Counter '\Memory\% Committed Bytes In Use' ``` ```powershell [RO] Get-Counter '\Memory\Pages/sec' ``` Prozesse nach Arbeitsspeichernutzung: ```powershell [RO] Get-Process | Sort-Object WorkingSet64 -Descending | Select-Object -First 10 Name, Id, @{Name='WorkingSetMiB';Expression={ [math]::Round($_.WorkingSet64 / 1MB, 1) }} ``` **Linux** ```bash [RO] free -h ``` ```bash [RO] vmstat 1 10 ``` Prozesse nach Speicheranteil: ```bash [RO] ps -eo pid,user,%mem,rss,vsz,comm --sort=-%mem | head ``` OOM-Ereignisse suchen: ```bash [RO][PRIV] sudo journalctl -k | grep -Ei 'out of memory|oom-killer|killed process' ``` **macOS** ```bash [RO] memory_pressure ``` ```bash [RO] vm_stat ``` ```bash [RO] top -l 1 -o mem ``` **Hinweise auf ein mögliches Speicherproblem** - verfügbarer Speicher bleibt sehr niedrig, - Swap- oder Paging-Aktivität ist dauerhaft hoch, - Speicherdruck steigt, - Anwendungen reagieren gleichzeitig langsamer, - ein Prozess wächst ohne Rückgang weiter, - der OOM-Killer beendet Prozesse, - Commit nähert sich dauerhaft der Grenze.
10. Wie werden Datenträgerauslastung und I/O-Latenz interpretiert? Zu einer Datenträgeranalyse gehören mindestens: - Durchsatz, - Ein- und Ausgabeoperationen pro Sekunde, - Latenz, - Warteschlangen, - Auslastungsgrad, - Fehler und Timeouts, - freier Speicherplatz. | Messwert | Aussage | |---|---| | IOPS | Anzahl der Operationen pro Sekunde | | Throughput | übertragene Datenmenge pro Sekunde | | Latency | Dauer einer Operation | | Queue Length | wartende oder laufende I/O-Anfragen | | Utilization | Anteil der aktiven Messzeit | | Free Space | verfügbarer Speicherplatz | | Errors | fehlerhafte oder abgebrochene Operationen | Hohe IOPS sind nicht automatisch problematisch. Ein Speichersystem kann viele kleine Operationen oder wenige große Übertragungen verarbeiten. Entscheidend ist, ob Latenz und Warteschlange unter der aktuellen Last steigen. **Windows** ```powershell [RO] Get-Counter '\PhysicalDisk(*)\% Disk Time' ``` ```powershell [RO] Get-Counter '\PhysicalDisk(*)\Avg. Disk sec/Read' ``` ```powershell [RO] Get-Counter '\PhysicalDisk(*)\Avg. Disk sec/Write' ``` ```powershell [RO] Get-Counter '\PhysicalDisk(*)\Current Disk Queue Length' ``` ```powershell [RO] Get-Counter '\PhysicalDisk(*)\Disk Reads/sec' ``` ```powershell [RO] Get-Counter '\PhysicalDisk(*)\Disk Writes/sec' ``` Freien Speicherplatz prüfen: ```powershell [RO] Get-Volume | Select-Object DriveLetter, FileSystemLabel, FileSystem, HealthStatus, SizeRemaining, Size ``` > Windows Performance Counter für `Avg. Disk sec/Read` und `Avg. Disk sec/Write` werden in Sekunden ausgegeben. `0,020` entspricht 20 Millisekunden. **Linux** ```bash [RO] df -hT ``` ```bash [RO] df -i ``` Falls `sysstat` installiert ist: ```bash [RO] iostat -xz 1 10 ``` Prozessbezogene I/O-Werte: ```bash [RO] pidstat -d 1 10 ``` Kernelmeldungen zu I/O-Fehlern: ```bash [RO][PRIV] sudo journalctl -k | grep -Ei 'I/O error|timeout|reset|read-only|filesystem' ``` **macOS** ```bash [RO] df -h ``` ```bash [RO] iostat -w 1 -c 10 ``` **Typische Fehlinterpretationen** | Beobachtung | Fehlinterpretation | |---|---| | Datenträger zu 100 % aktiv | maximale Datenübertragungsrate erreicht | | wenig Durchsatz | Datenträger ist nicht belastet | | hoher Durchsatz | Datenträger ist überlastet | | voller Speicherplatz | einzige mögliche Ursache ist Datenmenge | | hohe Latenz | physischer Datenträger ist zwingend defekt | Ein Datenträger kann bei kleinen zufälligen Zugriffen vollständig beschäftigt sein, obwohl der Datendurchsatz gering bleibt.
11. Wie werden Netzwerkmesswerte interpretiert? Wichtige Netzwerkmesswerte: | Messwert | Bedeutung | |---|---| | Bandbreite | theoretische oder konfigurierte Übertragungskapazität | | Throughput | tatsächlich übertragene Datenmenge | | Utilization | genutzter Anteil der Kapazität | | Packets per Second | Pakete pro Sekunde | | Errors | fehlerhafte Frames oder Pakete | | Discards/Drops | verworfene Pakete | | Retransmissions | erneut übertragene TCP-Segmente | | Latency | Laufzeit einer Übertragung | | Jitter | Schwankung der Laufzeit | | Packet Loss | Anteil verlorener Pakete | | Connections | Anzahl aktiver Verbindungen | **Windows** ```powershell [RO] Get-NetAdapter | Select-Object Name, InterfaceDescription, Status, LinkSpeed, MacAddress ``` Adapterstatistiken: ```powershell [RO] Get-NetAdapterStatistics ``` Performance Counter: ```powershell [RO] Get-Counter '\Network Interface(*)\Bytes Total/sec' ``` ```powershell [RO] Get-Counter '\TCPv4\Segments Retransmitted/sec' ``` **Linux** ```bash [RO] ip -s link ``` ```bash [RO] ss -s ``` ```bash [RO] cat /proc/net/dev ``` TCP-Statistik: ```bash [RO] nstat ``` Treiber- und Adapterstatistiken: ```bash [RO][PRIV] sudo ethtool -S eth0 ``` **macOS** ```bash [RO] netstat -ib ``` ```bash [RO] netstat -s ``` ```bash [RO] ifconfig ``` **Zusammenhänge** | Beobachtung | Mögliche Untersuchungsrichtung | |---|---| | steigende RX-Errors | Kabel, Transceiver, Port, Duplex oder Hardware | | steigende Drops ohne Linkfehler | Puffer, CPU, Treiber oder Überlastung | | viele TCP-Retransmissions | Paketverlust, Überlastung oder instabile Verbindung | | hohe Latenz ohne Paketverlust | Warteschlangen, Routing oder überlasteter Dienst | | Bandbreite dauerhaft nahe Kapazität | Kapazitätsengpass möglich | | geringe Bandbreitennutzung und hohe Antwortzeit | Problem möglicherweise in Anwendung oder Zielsystem | | nur ein Client betroffen | lokales Interface, WLAN, Treiber oder Clientkonfiguration | | alle Clients betroffen | gemeinsamer Pfad, Dienst oder Upstream | Zähler sollten mindestens zweimal gemessen werden. Ein seit dem Systemstart aufgelaufener Fehlerzähler ist ohne zeitliche Änderung nur begrenzt aussagekräftig.
12. Wie werden Latenz, Jitter und Paketverlust gemessen? **Erreichbarkeit und Round-Trip-Time** | Aufgabe | Windows | Linux | macOS | |---|---|---|---| | vier ICMP-Anfragen | `[TEST] ping ziel.example` | `[TEST] ping -c 4 ziel.example` | `[TEST] ping -c 4 ziel.example` | | fortlaufender Ping | `[TEST] ping -t ziel.example` | `[TEST] ping ziel.example` | `[TEST] ping ziel.example` | | Route prüfen | `[TEST] tracert ziel.example` | `[TEST] traceroute ziel.example` | `[TEST] traceroute ziel.example` | | kombinierte Pfadanalyse | `[TEST] pathping ziel.example` | `[TEST] mtr ziel.example` | `[TEST] mtr ziel.example` | Nicht jedes System beantwortet ICMP-Anfragen. Ein fehlgeschlagener Ping beweist daher nicht, dass der eigentliche Dienst nicht erreichbar ist. **Anwendungsnahe HTTPS-Messung** Windows, Linux und macOS: ```bash [TEST] curl -o /dev/null -sS \ -w 'DNS: %{time_namelookup}\nTCP: %{time_connect}\nTLS: %{time_appconnect}\nTTFB: %{time_starttransfer}\nGesamt: %{time_total}\n' \ https://example.com/ ``` | curl-Wert | Bedeutung | |---|---| | `time_namelookup` | Dauer bis zum Abschluss der Namensauflösung | | `time_connect` | Dauer bis zur TCP-Verbindung | | `time_appconnect` | Dauer bis zum Abschluss von TLS | | `time_starttransfer` | Zeit bis zum ersten Antwortbyte | | `time_total` | Gesamtdauer | **Interpretationsbeispiel** ```text DNS: 0,010 s TCP: 0,030 s TLS: 0,080 s TTFB: 3,500 s Gesamt: 3,510 s ``` DNS, TCP und TLS sind schnell. Die lange Zeit bis zum ersten Byte weist eher auf Verarbeitung im Server oder Backend hin.
13. Was bedeutet Sättigung und wie wird sie erkannt? Auslastung und Sättigung sind nicht dasselbe. ```text Auslastung: Wie stark wird eine Ressource verwendet? Sättigung: Wie viel Arbeit muss warten, weil die Ressource nicht sofort verfügbar ist? ``` **Beispiele** | Ressource | Auslastung | Sättigung | |---|---|---| | CPU | CPU-Zeit in Prozent | ausführbare Warteschlange | | RAM | belegter Speicher | Speicherdruck und Paging | | Datenträger | aktive Zeit | I/O-Warteschlange | | Netzwerk | übertragene Bitrate | Drops und Warteschlangen | | Datenbank | aktive Verbindungen | wartende Abfragen | | Threadpool | aktive Threads | wartende Tasks | | Connection Pool | belegte Verbindungen | wartende oder abgewiesene Anfragen | Ein System kann noch unter 100 % Auslastung liegen und trotzdem bereits Verzögerungen aufweisen. **Linux Pressure Stall Information** Wenn vom Kernel unterstützt: ```bash [RO] cat /proc/pressure/cpu ``` ```bash [RO] cat /proc/pressure/memory ``` ```bash [RO] cat /proc/pressure/io ``` Beispiel: ```text some avg10=4.20 avg60=2.10 avg300=0.80 total=1234567 full avg10=1.00 avg60=0.40 avg300=0.10 total=234567 ``` | Feld | Bedeutung | |---|---| | `some` | mindestens einige Tasks waren durch die Ressource blockiert | | `full` | alle nicht untätigen Tasks waren gleichzeitig blockiert | | `avg10` | durchschnittlicher Zeitanteil der letzten 10 Sekunden | | `avg60` | durchschnittlicher Zeitanteil der letzten 60 Sekunden | | `avg300` | durchschnittlicher Zeitanteil der letzten 300 Sekunden | | `total` | gesamte Stall-Zeit in Mikrosekunden seit dem Start | PSI misst den Zeitverlust durch Ressourcenknappheit und ergänzt reine Auslastungswerte.
14. Wie werden virtuelle Maschinen und Container richtig bewertet? Bei virtuellen Systemen existieren mehrere Messebenen: ```text Physischer Host → Hypervisor → virtuelle Maschine → Container → Anwendung ``` Ein Wert innerhalb eines Containers zeigt nicht zwingend die vollständige Situation des Hosts. **Zu prüfen** - zugewiesene virtuelle CPUs, - CPU-Limits und CPU-Quotas, - Arbeitsspeicherlimit, - Swap-Konfiguration, - Hypervisor-Überbelegung, - Storage-Latenz des Hosts, - gemeinsam genutzte Netzwerkressourcen, - Container-Restarts, - OOM-Beendigungen, - Ressourcenreservierungen. **Docker-Ressourcen anzeigen** ```bash [RO] docker stats --no-stream ``` Nur ausgewählte Spalten: ```bash [RO] docker stats --no-stream \ --format 'table {{.Name}}\t{{.CPUPerc}}\t{{.MemUsage}}\t{{.MemPerc}}\t{{.NetIO}}\t{{.BlockIO}}\t{{.PIDs}}' ``` Containerstatus prüfen: ```bash [RO] docker ps -a ``` Konfigurierte Limits eines Containers untersuchen: ```bash [RO][SENS] docker inspect beispiel-container ``` OOM-Status prüfen: ```bash [RO] docker inspect \ --format '{{.Name}} OOMKilled={{.State.OOMKilled}} ExitCode={{.State.ExitCode}}' \ beispiel-container ``` **Wichtige Grenzen** - Die CPU-Prozentdarstellung kann sich auf mehrere Kerne beziehen. - Ein Container kann vom Host gedrosselt werden. - Host-Caches beeinflussen die wahrgenommene Speicherbelegung. - Container-I/O kann durch andere Workloads auf demselben Storage beeinflusst werden. - Ein Neustart setzt bestimmte Anwendungszähler zurück.
15. Wie werden fehlende oder veraltete Messwerte erkannt? Keine Daten bedeuten nicht automatisch, dass alles in Ordnung ist. Mögliche Ursachen: - Zielsystem ist ausgefallen, - Exporter oder Agent läuft nicht, - Netzwerkverbindung ist unterbrochen, - Firewall blockiert die Abfrage, - Monitoringserver ist gestört, - Authentifizierung ist fehlgeschlagen, - Zeitstempel liegen außerhalb des Abfragefensters, - Metrik wurde umbenannt, - Ziel wurde aus der Konfiguration entfernt, - Abfrage ist fehlerhaft, - Dashboardvariable filtert alle Werte heraus. **Prometheus-Verfügbarkeit eines Targets** ```promql up ``` Nur nicht erfolgreich abgefragte Targets: ```promql up == 0 ``` Fehlende Zeitreihe erkennen: ```promql absent(up{job="beispiel"}) ``` Metriken ohne aktuelle Stichprobe können veraltet sein. Deshalb müssen folgende Zeitpunkte unterschieden werden: - Zeitpunkt der Messung, - Zeitpunkt der Übertragung, - Zeitpunkt der Speicherung, - Zeitpunkt der Dashboardabfrage, - Zeitpunkt der Alarmauswertung. **Prüfreihenfolge** 1. Zeitbereich des Dashboards prüfen. 2. Zeitpunkt des letzten Datenpunkts prüfen. 3. Target- oder Agentstatus kontrollieren. 4. Datenquelle direkt abfragen. 5. Netzwerkverbindung zwischen Monitoring und Ziel prüfen. 6. Konfigurationsänderungen kontrollieren. 7. Monitoringfehler getrennt vom überwachten Dienst bewerten.
16. Wie werden sinnvolle Schwellenwerte festgelegt? Ein sinnvoller Schwellenwert basiert auf: - normalem Verlauf, - Benutzerwirkung, - technischer Kapazität, - Dauer der Überschreitung, - Wachstumsrate, - Tages- und Wochenmuster, - Wartungsfenstern, - genügend Reaktionszeit, - Erfahrungen aus früheren Störungen. **Ungeeignete Regel** ```text CPU > 80 % → sofort kritischer Alarm ``` **Bessere Regelidee** ```text CPU-Auslastung über 90 % für mindestens 15 Minuten UND Antwortzeit p95 über dem vereinbarten Zielwert ``` **Beispiel für mehrstufige Grenzwerte** | Zustand | Bedingung | Reaktion | |---|---|---| | Information | ungewöhnlicher Trend ohne Auswirkung | Dashboard beobachten | | Warnung | Grenzwert länger überschritten | während Betriebszeit untersuchen | | Kritisch | Benutzerwirkung oder unmittelbarer Ausfall | sofortige Bearbeitung | | Kapazitätswarnung | prognostizierte Erschöpfung in 14 Tagen | Kapazität planen | **Hysterese** Unterschiedliche Ein- und Ausschaltschwellen verhindern, dass ein Alarm ständig wechselt. ```text Alarm aktivieren: Wert über 90 % Alarm beenden: Wert unter 80 % ``` **Pending Period** Eine Bedingung muss für eine festgelegte Dauer bestehen, bevor der Alarm ausgelöst wird. ```text CPU > 90 % für 10 Minuten ``` Dadurch führen kurze Lastspitzen nicht sofort zu einem Alarm.
17. Was sind Flapping und Alert Fatigue? **Flapping** Ein Alarm wechselt häufig zwischen aktiv und normal: ```text 09:00 Alarm 09:01 behoben 09:02 Alarm 09:03 behoben ``` Mögliche Gegenmaßnahmen: - längeres Auswertungsfenster, - Pending Period, - Hysterese, - gleitender Durchschnitt, - sinnvollere Schwellenwerte, - getrennte Warn- und Kritisch-Stufen. **Alert Fatigue** Zu viele oder nicht relevante Meldungen führen dazu, dass wichtige Alarme übersehen werden. Typische Ursachen: - Alarm bei jeder kurzen Lastspitze, - mehrere Meldungen für dieselbe Ursache, - fehlende Zuständigkeit, - keine Handlungsmöglichkeit, - falsche Priorität, - keine Wartungsfenster, - unklare Meldung, - nicht gepflegte Regeln. **Ein guter Alarm beantwortet:** 1. Was ist betroffen? 2. Welche Benutzerwirkung besteht? 3. Seit wann besteht das Problem? 4. Welcher Messwert löste den Alarm aus? 5. Wie lange besteht die Bedingung? 6. Wer ist zuständig? 7. Welches Dashboard und Runbook gehören dazu? 8. Welche ersten Prüfungen sind erforderlich? Wenn aus einer Meldung keine sinnvolle Handlung folgt, eignet sie sich möglicherweise besser für ein Dashboard als für eine Alarmierung.
18. Wie werden Dashboards bei einer Störung gelesen? **Empfohlene Reihenfolge** 1. Zeitfenster auf den Störungszeitraum einstellen. 2. Zeitzone des Dashboards prüfen. 3. Zeitpunkt einer gemeldeten Störung markieren. 4. Benutzerorientierte Signale prüfen: - Verfügbarkeit, - Antwortzeit, - Fehlerrate, - Anfragemenge. 5. Technische Ressourcen prüfen: - CPU, - RAM, - Datenträger, - Netzwerk. 6. Deployments, Updates und Wartungsereignisse einblenden. 7. Betroffene Instanzen mit funktionierenden Instanzen vergleichen. 8. Zeitfenster vor und nach dem Ereignis betrachten. 9. Rohdaten oder detailliertere Ansicht öffnen. 10. Hypothese anhand von Logs oder Traces prüfen. **Zoomfehler vermeiden** Ein Wert kann je nach gewähltem Zeitraum unterschiedlich wirken: ```text 24-Stunden-Ansicht: kurzer, kaum sichtbarer Ausschlag 5-Minuten-Ansicht: deutliche Lastspitze von drei Minuten ``` Umgekehrt kann ein extrem kurzes Zeitfenster einen normalen Ausschlag dramatischer erscheinen lassen, als er im Betriebszusammenhang ist. **Zu prüfen** - automatische Aggregation, - Abfrageintervall, - Datenauflösung, - Mittelwert oder Maximum, - ausgeblendete Datenreihen, - verwendete Einheit, - logarithmische oder lineare Achse, - Beginn der Y-Achse, - lokale Zeit oder UTC.
19. Wie werden typische Messwertkombinationen interpretiert? | Beobachtung | Mögliche Richtung | Nächster Prüfschritt | |---|---|---| | CPU hoch, Antwortzeit normal | erwartete Verarbeitung | Kapazitätsreserve und Dauer prüfen | | CPU hoch, Antwortzeit hoch | CPU-Engpass möglich | Prozess, Threads und Run Queue prüfen | | CPU niedrig, Load hoch | I/O-Wartezustände möglich | `vmstat`, `iostat` und PSI prüfen | | RAM belegt, Available ausreichend | möglicherweise normaler Cache | Paging und Speicherdruck prüfen | | RAM knapp, Swap steigt | Speicherdruck | Prozesse und Wachstum untersuchen | | Datenträger aktiv, Latenz niedrig | hohe, aber verarbeitbare Last | Warteschlange und Trend prüfen | | Datenträger aktiv, Latenz hoch | I/O-Engpass möglich | Prozess-I/O und Storage prüfen | | Netzwerkdurchsatz hoch, keine Fehler | möglicherweise normale Übertragung | Kapazität und Anwendungskontext | | Retransmissions steigen | Paketverlust möglich | Interfacefehler und Pfad prüfen | | Antwortzeit hoch, Ressourcen normal | externe Abhängigkeit möglich | Traces, DNS und Backenddienste | | Fehlerquote hoch, Traffic normal | Funktions- oder Backendfehler | Logs und Deployments prüfen | | Traffic steigt, Fehler und Latenz steigen | Kapazitätsgrenze möglich | Sättigung und Skalierung prüfen | | Messwerte verschwinden | Monitoring- oder Zielausfall | Target, Agent und Datenquelle prüfen | | nur eine Instanz auffällig | lokales Problem | Konfiguration und Host vergleichen | | alle Instanzen gleichzeitig auffällig | gemeinsame Abhängigkeit | Datenbank, Netzwerk und Deployment | Diese Kombinationen sind Ausgangspunkte für Hypothesen und keine automatischen Ursachenfeststellungen.
20. Praxisfall – Anwendung ist zu bestimmten Zeiten langsam **Ausgangslage** ```text Benutzer melden täglich zwischen 02:00 und 02:30 Uhr lange Antwortzeiten. ``` **Vorgehen** 1. Benutzerwirkung mit p95- oder p99-Antwortzeit bestätigen. 2. Anfragerate und Fehlerrate im selben Zeitraum prüfen. 3. CPU-, RAM-, Datenträger- und Netzwerkverlauf vergleichen. 4. Geplante Aufgaben und Backups prüfen. 5. Datenbankverbindungen und Abfragedauer kontrollieren. 6. Logs nach Timeouts und Warteschlangen durchsuchen. 7. Mit einem störungsfreien Zeitraum vergleichen. 8. Abhängigkeiten und Storage überprüfen. 9. Ursache durch kontrollierte zeitliche oder technische Änderung testen. 10. Ergebnis über mehrere Tage beobachten. **Beispiel einer Korrelation** ```text 02:00 Uhr: Backup beginnt 02:02 Uhr: Datenträgerlatenz steigt 02:03 Uhr: Datenbankabfragen werden langsamer 02:04 Uhr: Antwortzeit p95 steigt 02:05 Uhr: erste HTTP-Timeouts 02:30 Uhr: Backup endet 02:32 Uhr: Werte normalisieren sich ``` Diese zeitliche Kette ist ein starker Hinweis, aber die Hypothese muss durch einen kontrollierten Test bestätigt werden.
21. Praxisfall – freier Speicherplatz nimmt kontinuierlich ab **Erforderliche Messwerte** - aktueller freier Speicherplatz, - Änderungsrate pro Stunde oder Tag, - betroffene Partition beziehungsweise Volume, - größte Verzeichnisse, - Logwachstum, - temporäre Dateien, - Datenbank- und Backupwachstum, - Zeitpunkt der voraussichtlichen Erschöpfung. **Windows** ```powershell [RO] Get-Volume | Select-Object DriveLetter, FileSystemLabel, HealthStatus, SizeRemaining, Size ``` Größte Dateien in einem bekannten Untersuchungsverzeichnis: ```powershell [RO][SENS] Get-ChildItem 'C:\Logs' -File -Recurse -ErrorAction SilentlyContinue | Sort-Object Length -Descending | Select-Object -First 20 FullName, @{Name='SizeMiB';Expression={ [math]::Round($_.Length / 1MB, 1) }} ``` **Linux** ```bash [RO] df -hT ``` ```bash [RO][PRIV] sudo du -xhd 1 /var | sort -h ``` **macOS** ```bash [RO] df -h ``` ```bash [RO][PRIV] sudo du -xhd 1 /Library | sort -h ``` **Prognosebeispiel** ```text Freier Speicher: 100 GB Verbrauch: 5 GB pro Tag Vereinfachte Restzeit: ungefähr 20 Tage ``` Die Wachstumsrate kann schwanken. Eine Prognose sollte deshalb auf mehreren Messpunkten und einem geeigneten Zeitraum beruhen. Dateien dürfen erst gelöscht werden, wenn Zweck, Eigentümer, Aufbewahrungspflicht und Wiederherstellbarkeit geklärt sind.
22. Kompakte Befehlsübersicht für Windows, Linux und macOS | Aufgabe | Windows | Linux | macOS | |---|---|---|---| | Leistungsanzeige öffnen | `[RO] perfmon.msc` | abhängig vom Werkzeug | `[RO] open -a "Activity Monitor"` | | Prozessübersicht | `[RO] Get-Process` | `[RO] top` | `[RO] top -l 1` | | CPU messen | `[RO] Get-Counter '\Processor(_Total)\% Processor Time'` | `[RO] mpstat -P ALL 1 10` | `[RO] top -l 1 -o cpu` | | Load Average | kein direkt gleichwertiger Standardwert | `[RO] uptime` | `[RO] uptime` | | logische CPUs | `[RO] (Get-CimInstance Win32_ComputerSystem).NumberOfLogicalProcessors` | `[RO] nproc` | `[RO] sysctl -n hw.logicalcpu` | | verfügbarer RAM | `[RO] Get-Counter '\Memory\Available MBytes'` | `[RO] free -h` | `[RO] memory_pressure` | | Speicheraktivität | `[RO] Get-Counter '\Memory\Pages/sec'` | `[RO] vmstat 1 10` | `[RO] vm_stat 1` | | Prozesse nach RAM | `[RO] Get-Process \| Sort-Object WorkingSet64 -Descending` | `[RO] ps -eo pid,%mem,rss,comm --sort=-%mem` | `[RO] top -l 1 -o mem` | | Dateisystembelegung | `[RO] Get-Volume` | `[RO] df -hT` | `[RO] df -h` | | Inode-Nutzung | nicht direkt vergleichbar | `[RO] df -i` | `[RO] df -i` | | Datenträger-I/O | `[RO] Get-Counter '\PhysicalDisk(*)\% Disk Time'` | `[RO] iostat -xz 1 10` | `[RO] iostat -w 1 -c 10` | | Interfaceübersicht | `[RO] Get-NetAdapter` | `[RO] ip link` | `[RO] ifconfig` | | Interfacezähler | `[RO] Get-NetAdapterStatistics` | `[RO] ip -s link` | `[RO] netstat -ib` | | TCP-Zusammenfassung | `[RO] Get-NetTCPConnection` | `[RO] ss -s` | `[RO] netstat -s` | | Erreichbarkeit | `[TEST] ping ziel.example` | `[TEST] ping -c 4 ziel.example` | `[TEST] ping -c 4 ziel.example` | | Pfadprüfung | `[TEST] tracert ziel.example` | `[TEST] traceroute ziel.example` | `[TEST] traceroute ziel.example` | | Containerressourcen | `[RO] docker stats --no-stream` | `[RO] docker stats --no-stream` | `[RO] docker stats --no-stream` | | Linux-Ressourcendruck | Nicht zutreffend | `[RO] cat /proc/pressure/{cpu,memory,io}` | Nicht standardmäßig vorhanden | > `mpstat`, `iostat`, `pidstat`, `nstat`, `mtr` und `ethtool` sind nicht auf jeder Linux-Installation standardmäßig vorhanden. Fehlende Werkzeuge dürfen nicht ohne Prüfung der Paketquelle und betriebliche Freigabe installiert werden.
23. Systematischer Ablauf einer Monitoringanalyse | Phase | Vorgehen | |---|---| | 1. Symptom bestimmen | Benutzerwirkung und betroffene Funktion dokumentieren | | 2. Zeitraum festlegen | Fehlerbeginn, Ende und Zeitzone bestimmen | | 3. Datenqualität prüfen | letzte Messung, Lücken und Datenquelle kontrollieren | | 4. Baseline wählen | vergleichbaren funktionierenden Zeitraum bestimmen | | 5. RED prüfen | Anfragerate, Fehlerrate und Dauer untersuchen | | 6. USE prüfen | Auslastung, Sättigung und Fehler der Ressourcen untersuchen | | 7. Änderungspunkte prüfen | Updates, Deployments, Backups und Wartung einblenden | | 8. Umfang bestimmen | einzelne Instanz, Dienstgruppe oder gesamte Umgebung | | 9. Hypothese bilden | möglichen Zusammenhang konkret formulieren | | 10. Logs und Traces prüfen | technische Ursache weiter eingrenzen | | 11. Kontrolliert testen | nur eine begründete Änderung durchführen | | 12. Wirkung bestätigen | dieselben Messwerte erneut vergleichen | | 13. Langfristig beobachten | Rückfall und Nebenwirkungen ausschließen | | 14. Dokumentieren | Ursache, Messwerte, Änderung und Ergebnis festhalten | **Formulierung einer guten Hypothese** ```text Wenn die erhöhte Datenträgerlatenz die Ursache der langsamen Anwendung ist, muss die Antwortzeit bei vergleichbarer Anfragemenge mit der Datenträgerlatenz steigen und nach deren Normalisierung wieder sinken. ``` Diese Hypothese ist messbar und überprüfbar.
24. Dokumentationsvorlage für eine Monitoringanalyse ```text Ticketnummer: Analysedatum: Betroffener Dienst: Betroffene Systeme: Benutzerwirkung: Fehlerbeginn: Fehlerende: Zeitzone: Reproduzierbar: Ja / Nein Verwendetes Monitoringsystem: Datenquelle: Abfrageintervall: Auswertungsintervall: Letzter Datenpunkt: Datenlücken vorhanden: Ja / Nein Vergleichszeitraum: Begründung für den Vergleichszeitraum: Benutzerorientierte Messwerte: - Verfügbarkeit: - Anfragerate: - Fehlerrate: - Antwortzeit p50: - Antwortzeit p95: - Antwortzeit p99: Ressourcenwerte: - CPU-Auslastung: - CPU-Sättigung: - verfügbarer RAM: - Paging/Swap: - Datenträgerauslastung: - Datenträgerlatenz: - Datenträgerwarteschlange: - Netzwerkdurchsatz: - Netzwerkfehler: - TCP-Retransmissions: - freier Speicherplatz: Änderungen im Zeitraum: - Deployment: - Update: - Backup: - Wartung: - Konfigurationsänderung: Auffällige Korrelationen: 1. 2. 3. Arbeitshypothese: Erwartetes Messergebnis: Kontrollierter Test: Tatsächliches Ergebnis: Ermittelte Ursache: Durchgeführte Änderung: Rückweg: Abschlussprüfung: Beobachtungszeitraum nach der Änderung: Dashboard: Abfrage: Screenshot oder Export: Sensible Daten redigiert: Ja / Nein ```
25. Offizielle Quellen und weiterführende Dokumentation **Microsoft** - [Get-Counter – Microsoft Learn](https://learn.microsoft.com/powershell/module/microsoft.powershell.diagnostics/get-counter) - [Windows Performance Monitor – Microsoft Learn](https://learn.microsoft.com/windows-server/administration/windows-commands/perfmon) - [Leistungsprobleme unter Windows untersuchen](https://learn.microsoft.com/troubleshoot/windows-server/performance/troubleshoot-performance-problems-in-windows) - [Get-NetAdapterStatistics – Microsoft Learn](https://learn.microsoft.com/powershell/module/netadapter/get-netadapterstatistics) - [Get-Volume – Microsoft Learn](https://learn.microsoft.com/powershell/module/storage/get-volume) **Linux** - [Linux Pressure Stall Information – Kernel-Dokumentation](https://docs.kernel.org/accounting/psi.html) - Lokale Befehlsreferenzen: `man top`, `man vmstat`, `man iostat`, `man mpstat`, `man free` und `man proc` **Prometheus** - [Prometheus-Metriktypen](https://prometheus.io/docs/concepts/metric_types/) - [PromQL-Funktionen](https://prometheus.io/docs/prometheus/latest/querying/functions/) - [Prometheus Alerting Rules](https://prometheus.io/docs/prometheus/latest/configuration/alerting_rules/) - [Prometheus Best Practices](https://prometheus.io/docs/practices/) **Grafana** - [Grafana Alerting](https://grafana.com/docs/grafana/latest/alerting/) - [Best Practices für Grafana-Dashboards](https://grafana.com/docs/grafana/latest/visualizations/dashboards/build-dashboards/best-practices/) - [Umgang mit No Data und Error](https://grafana.com/docs/grafana/latest/alerting/fundamentals/alert-rule-evaluation/nodata-and-error-states/) **Docker** - [docker stats – Docker-Dokumentation](https://docs.docker.com/reference/cli/docker/container/stats/) - [Docker Runtime Metrics](https://docs.docker.com/engine/containers/runmetrics/) > Bezeichnungen, Einheiten und Berechnungsmethoden können sich zwischen Betriebssystemen, Exportern und Monitoringprodukten unterscheiden. Vor einem direkten Vergleich muss immer geprüft werden, was die konkrete Metrik tatsächlich misst.
# 2.14 Sichere Paketmitschnitte, Datenschutz und Beweissicherung Ein Paketmitschnitt zeichnet Netzwerkpakete an einer Netzwerkschnittstelle oder einem definierten Messpunkt auf. Je nach Protokoll und Verschlüsselung kann eine Aufzeichnung nicht nur technische Metadaten, sondern auch Kommunikationsinhalte enthalten. Ein Paketmitschnitt kann unter anderem sichtbar machen: - Quell- und Ziel-IP-Adressen, - MAC-Adressen, - Ports und Protokolle, - DNS-Anfragen und aufgerufene Hostnamen, - Verbindungsaufbau und Verbindungsabbau, - Paketgrößen und Zeitstempel, - TCP-Wiederholungen und Paketverluste, - unverschlüsselte Benutzernamen oder Inhalte, - HTTP-Header und Cookies, - Authentifizierungsinformationen, - interne System- und Dienstnamen, - bei vorhandenen Schlüsseln auch entschlüsselte Anwendungsdaten. > **Grundregel:** So wenig wie möglich, so gezielt wie nötig und nur so lange wie erforderlich mitschneiden. ---
1. Kennzeichnungen und Sicherheitsregeln | Kennzeichnung | Bedeutung | |---|---| | `[RO]` | Liest vorhandene Informationen aus | | `[TEST]` | Führt eine aktive Messung oder Aufzeichnung durch | | `[PRIV]` | Benötigt möglicherweise Administrator- oder Root-Rechte | | `[FILE]` | Erzeugt oder verändert eine Datei | | `[SENS]` | Datei oder Ausgabe kann vertrauliche Daten enthalten | | `[CHANGE]` | Verändert Konfiguration oder Systemzustand | | `[DISRUPT]` | Kann Verbindungen oder Dienste beeinträchtigen | Ein Live-Paketmitschnitt ist keine rein passive Read-only-Aktion. Er liest laufende Kommunikation mit und schreibt sie in eine Datei: ```text [TEST][PRIV][FILE][SENS] ``` Vor jeder Aufzeichnung müssen mindestens folgende Punkte geklärt werden: 1. Gibt es einen konkreten technischen Anlass? 2. Liegt eine ausreichende betriebliche und rechtliche Freigabe vor? 3. Welche Systeme und Kommunikationsverbindungen dürfen erfasst werden? 4. Wer ist für die Aufzeichnung verantwortlich? 5. Welcher Zeitraum ist erforderlich? 6. Welche Daten sollen ausdrücklich nicht erfasst werden? 7. Wo wird die Datei gespeichert? 8. Wer darf die Datei auswerten? 9. Darf sie an Hersteller oder Dienstleister weitergegeben werden? 10. Wann wird sie gelöscht?
2. Warum sind Paketmitschnitte besonders sensibel? Eine PCAP- oder PCAPNG-Datei kann mehr Informationen enthalten, als für die technische Untersuchung zunächst sichtbar sind. Mögliche Inhalte: | Datenart | Beispiel | |---|---| | Netzwerkkennungen | IP- und MAC-Adressen | | Benutzerbezug | Benutzername, Gerät oder interne Zuordnung | | Kommunikationspartner | interne und externe Zielsysteme | | DNS-Daten | angefragte Domains und Hostnamen | | Zeitdaten | Zeitpunkt und Dauer der Kommunikation | | Inhaltsdaten | unverschlüsselte Nachrichten oder Dateien | | Authentifizierungsdaten | Cookies, Tokens oder Anmeldeinformationen | | Organisationsdaten | interne Server-, Standort- und Kundennamen | | Sicherheitsdaten | Ports, Dienste, Zertifikate und Netzwerkstruktur | | Entschlüsselungsgeheimnisse | TLS-Key-Log oder eingebettete Schlüsselblöcke | Auch verschlüsselter Datenverkehr enthält auswertbare Metadaten: - beteiligte IP-Adressen, - Verbindungszeiten, - Datenmengen, - Paketgrößen, - DNS-Anfragen, sofern nicht verschlüsselt, - TLS-Versionen und Zertifikatsinformationen, - teilweise Servernamen, - zeitliche Kommunikationsmuster. Verschlüsselung macht einen Paketmitschnitt daher nicht automatisch datenschutzrechtlich oder sicherheitstechnisch unbedenklich.
3. Welche betrieblichen und rechtlichen Prüfungen sind erforderlich? Die zulässige Verarbeitung hängt vom konkreten Zweck, der Organisation, den betroffenen Personen und den geltenden Vorgaben ab. Diese Seite ersetzt keine rechtliche Prüfung. Möglicherweise einzubeziehende Stellen: - System- oder Serviceverantwortliche, - Informationssicherheitsbeauftragte, - Datenschutzbeauftragte, - Netzwerkverantwortliche, - betroffene Fachabteilung, - Incident-Response-Team, - Betriebs- oder Personalrat, - externe Auftragsverarbeiter, - Rechtsabteilung. Relevante Datenschutzgrundsätze sind unter anderem: | Grundsatz | Bedeutung für Paketmitschnitte | |---|---| | Rechtmäßigkeit und Transparenz | Verarbeitung benötigt eine tragfähige Grundlage | | Zweckbindung | Daten nur für den festgelegten Diagnosezweck verwenden | | Datenminimierung | nur erforderliche Kommunikation erfassen | | Richtigkeit | Zeit, Messpunkt und Dateiintegrität dokumentieren | | Speicherbegrenzung | Datei nicht länger als erforderlich aufbewahren | | Integrität und Vertraulichkeit | Zugriff, Transport und Speicherung schützen | | Rechenschaftspflicht | Zweck, Freigabe und Verarbeitung dokumentieren | **Nicht ausreichend sind Aussagen wie:** ```text „Es ist nur für die Technik.“ ``` ```text „Die Verbindung ist verschlüsselt.“ ``` ```text „Wir schneiden nur kurz mit.“ ``` Auch ein kurzer technischer Mitschnitt kann personenbezogene oder vertrauliche Daten enthalten.
4. Welche Freigaben sollten vor Beginn dokumentiert werden? ```text Ticketnummer: Verantwortliche Person: Auftraggebende Stelle: Technischer Zweck: Betroffene Systeme: Betroffene Netzsegmente: Betroffene Benutzergruppen: Erlaubte Protokolle: Ausgeschlossene Systeme und Daten: Beginn: Geplantes Ende: Maximale Dateigröße: Speicherort: Auswertungsberechtigte Personen: Vorgesehene Weitergabe: Aufbewahrungsfrist: Löschtermin: Datenschutzprüfung erforderlich: Ja / Nein Datenschutzprüfung erfolgt: Ja / Nein Betriebsrat einzubeziehen: Ja / Nein / Nicht zutreffend Informationssicherheit informiert: Ja / Nein Freigabe erteilt durch: Freigabezeitpunkt: ``` Bei einem akuten Sicherheitsvorfall können besondere Incident-Response-Regelungen gelten. Auch dann müssen Zuständigkeit, Beweissicherung und Zugriff nachvollziehbar dokumentiert werden.
5. Wo sollte ein Paketmitschnitt durchgeführt werden? Der Messpunkt bestimmt, welcher Datenverkehr sichtbar ist. | Messpunkt | Sichtbarer Datenverkehr | Typischer Zweck | |---|---|---| | betroffener Client | Kommunikation dieses Clients | lokales Clientproblem | | Anwendungsserver | ein- und ausgehende Serverkommunikation | Backend- oder Dienstproblem | | Reverse Proxy | Client- und Backendverbindungen des Proxys | HTTP- und TLS-Fehler eingrenzen | | DNS-Server | DNS-Anfragen am Server | Auflösungsprobleme | | Firewall | Verkehr an der jeweiligen Schnittstelle | Routing, NAT und Filterung | | Switch-SPAN-Port | gespiegelter Verkehr ausgewählter Ports oder VLANs | segmentübergreifende Analyse | | virtueller Switch | Verkehr virtueller Systeme | VM- und Hypervisoranalyse | | Containerhost | Verkehr von Containern und Bridges | Containerkommunikation | **Grundsatz** ```text So nah wie möglich am vermuteten Problem mitschneiden. ``` Bei komplexen Problemen können zwei gleichzeitige Mitschnitte sinnvoll sein: ```text Client-Mitschnitt + Server-Mitschnitt ``` Damit lässt sich beispielsweise prüfen: - ob ein Paket den Client verlassen hat, - ob es am Server angekommen ist, - wo ein Verlust auftritt, - ob NAT oder Firewall Adressen verändert, - ob die Zeitstempel deutlich voneinander abweichen. Vor einem Vergleich müssen die Systemuhren geprüft werden.
6. Wie wird die richtige Netzwerkschnittstelle bestimmt? **Windows** ```powershell [RO] Get-NetAdapter | Select-Object Name, InterfaceDescription, Status, LinkSpeed, MacAddress, ifIndex ``` IP-Konfiguration zuordnen: ```powershell [RO] Get-NetIPConfiguration ``` Wireshark-Schnittstellen anzeigen: ```cmd [RO] dumpcap.exe -D ``` ```cmd [RO] tshark.exe -D ``` **Linux** ```bash [RO] ip -brief address ``` ```bash [RO] ip route ``` ```bash [RO] dumpcap -D ``` ```bash [RO] tcpdump -D ``` **macOS** ```bash [RO] ifconfig ``` Standardroute und verwendetes Interface: ```bash [RO] route -n get default ``` Wireshark-Schnittstellen: ```bash [RO] dumpcap -D ``` ```bash [RO] tcpdump -D ``` **Typische Schnittstellen** | Name | Mögliche Bedeutung | |---|---| | `Ethernet` | kabelgebundener Windows-Adapter | | `Wi-Fi` | Windows-WLAN | | `eth0`, `enp…`, `ens…` | Linux-Ethernet | | `wlan0`, `wlp…` | Linux-WLAN | | `en0`, `en1` | macOS-Netzwerkschnittstelle | | `lo`, `lo0` | Loopback | | `docker0` | Docker-Bridge | | `br-…` | benutzerdefinierte Container-Bridge | | `vEthernet (…)` | virtueller Windows-Adapter | | `utun…` | macOS-Tunnel oder VPN | | `any` | zusammengefasste Linux-Capture-Schnittstelle | Die Namenskonvention allein reicht nicht. Die Schnittstelle muss über IP-Adresse, Route und tatsächliche Paketaktivität bestätigt werden.
7. Wie wird vor dem Mitschnitt ein Capture-Plan erstellt? ```text Fehler: HTTPS-Aufruf an app.example.intern schlägt sporadisch fehl. Betroffener Client: CLIENT-023 Ziel: 192.0.2.20 Port: TCP 443 Schnittstelle: Ethernet / Index 4 Geplanter Zeitraum: maximal 120 Sekunden Auslöser: Benutzer führt genau einen Anmeldeversuch aus. Capture-Filter: host 192.0.2.20 and tcp port 443 Datei: TICKET-4711_CLIENT-023_20260731T094200+0200.pcapng Maximale Dateigröße: 100 MB Speicherort: geschütztes Diagnoseverzeichnis Nachbereitung: Zeitfenster weiter reduzieren, Hash bilden, Zugriff begrenzen. Löschtermin: nach Abschluss gemäß Ticket und interner Richtlinie ``` Ein guter Capture-Plan verhindert unkontrollierte Daueraufzeichnungen und unnötig große Dateien.
8. Wie wird bereits bei der Aufnahme Datenminimierung umgesetzt? Vier zentrale Begrenzungen: 1. richtige Schnittstelle, 2. enger Capture-Filter, 3. kurze Aufzeichnungsdauer, 4. begrenzte Paketlänge oder Dateigröße. **Capture-Filter nach Host** ```text host 192.0.2.20 ``` **Nur Kommunikation zwischen zwei Systemen** ```text host 192.0.2.10 and host 192.0.2.20 ``` **Nur HTTPS zu einem Ziel** ```text host 192.0.2.20 and tcp port 443 ``` **Nur DNS zu einem bestimmten DNS-Server** ```text host 192.0.2.53 and port 53 ``` **Nur TCP zwischen zwei Systemen** ```text tcp and host 192.0.2.10 and host 192.0.2.20 ``` **Bestimmtes Subnetz ausschließen** ```text host 192.0.2.20 and not net 198.51.100.0/24 ``` **Wichtige Filterbegriffe** | Ausdruck | Bedeutung | |---|---| | `host 192.0.2.20` | Quelle oder Ziel ist dieser Host | | `src host 192.0.2.20` | Host ist Quelle | | `dst host 192.0.2.20` | Host ist Ziel | | `net 192.0.2.0/24` | Verkehr eines Netzes | | `port 53` | Quell- oder Zielport 53 | | `src port 53` | Quellport 53 | | `dst port 443` | Zielport 443 | | `tcp` | nur TCP | | `udp` | nur UDP | | `icmp` | nur ICMP | | `and` | beide Bedingungen müssen zutreffen | | `or` | mindestens eine Bedingung trifft zu | | `not` | Bedingung ausschließen | Capture-Filter verwenden die Syntax von libpcap/BPF. Sie unterscheiden sich von Wireshark-Display-Filtern.
9. Was ist der Unterschied zwischen Capture- und Display-Filter? | Filterart | Zeitpunkt | Wirkung | |---|---|---| | Capture-Filter | während der Aufnahme | nicht passende Pakete werden nicht gespeichert | | Display-Filter | nach beziehungsweise während der Anzeige | Pakete bleiben in der Datei, werden aber ausgeblendet | **Capture-Filter** ```text host 192.0.2.20 and tcp port 443 ``` **Entsprechender Display-Filter** ```text ip.addr == 192.0.2.20 && tcp.port == 443 ``` Ein Display-Filter reduziert nicht den sensiblen Inhalt der gespeicherten Originaldatei. ```text Ausgeblendet ≠ entfernt ``` Vor einer Weitergabe muss eine neue, tatsächlich reduzierte Datei erzeugt und anschließend erneut geprüft werden.
10. Wie wird mit dumpcap eine zeitlich begrenzte Aufnahme erstellt? `dumpcap` ist die spezialisierte Capture-Komponente von Wireshark. Die grafische Wireshark-Anwendung muss dadurch nicht mit erhöhten Rechten ausgeführt werden. **Schnittstellen auflisten** ```bash [RO] dumpcap -D ``` **60 Sekunden auf Schnittstelle 1 mitschneiden** ```bash [TEST][PRIV][FILE][SENS] dumpcap \ -i 1 \ -a duration:60 \ -w capture.pcapng ``` **Gezielter HTTPS-Mitschnitt** ```bash [TEST][PRIV][FILE][SENS] dumpcap \ -i 1 \ -f "host 192.0.2.20 and tcp port 443" \ -a duration:60 \ -w capture.pcapng ``` **Nach 10.000 Paketen stoppen** ```bash [TEST][PRIV][FILE][SENS] dumpcap \ -i 1 \ -f "host 192.0.2.20" \ -c 10000 \ -w capture.pcapng ``` **Nach einer Dateigröße von ungefähr 100.000 kB stoppen** ```bash [TEST][PRIV][FILE][SENS] dumpcap \ -i 1 \ -f "host 192.0.2.20" \ -a filesize:100000 \ -w capture.pcapng ``` Bei `dumpcap` wird `filesize` in Kilobyte zu jeweils 1.000 Byte angegeben. **Wichtige Optionen** | Option | Bedeutung | |---|---| | `-D` | Schnittstellen auflisten | | `-i` | Schnittstelle auswählen | | `-f` | Capture-Filter | | `-a duration:60` | nach 60 Sekunden stoppen | | `-a filesize:100000` | bei ungefähr 100 MB stoppen | | `-c 10000` | nach 10.000 Paketen stoppen | | `-s 96` | maximal 96 Byte jedes Pakets speichern | | `-w` | Ausgabedatei | | `-p` | Promiscuous Mode deaktivieren | | `-q` | reduzierte Statusausgabe | Der tatsächliche Schnittstellenname oder die Nummer muss vorher mit `dumpcap -D` ermittelt werden.
11. Wie wird mit tcpdump eine begrenzte Aufnahme erstellt? `tcpdump` ist unter Linux und macOS häufig verfügbar. Unter Windows werden üblicherweise Wireshark, Dumpcap oder TShark mit Npcap verwendet. **60 Sekunden gezielt aufzeichnen** Linux: ```bash [TEST][PRIV][FILE][SENS] sudo timeout 60 \ tcpdump -i eth0 \ -nn \ -w capture.pcap \ 'host 192.0.2.20 and tcp port 443' ``` `timeout` gehört zum GNU-Coreutils-Umfeld und ist unter macOS nicht standardmäßig in derselben Form vorhanden. **Nach 10.000 Paketen stoppen** Linux und macOS: ```bash [TEST][PRIV][FILE][SENS] sudo tcpdump \ -i en0 \ -nn \ -c 10000 \ -w capture.pcap \ 'host 192.0.2.20 and tcp port 443' ``` **Paketlänge auf 96 Byte begrenzen** ```bash [TEST][PRIV][FILE][SENS] sudo tcpdump \ -i en0 \ -nn \ -s 96 \ -c 10000 \ -w capture-truncated.pcap \ 'host 192.0.2.20 and tcp port 443' ``` **Wichtige Optionen** | Option | Bedeutung | |---|---| | `-i en0` | Aufnahmeschnittstelle | | `-nn` | keine Hostnamen- und Portnamensauflösung | | `-c 10000` | nach 10.000 Paketen stoppen | | `-s 96` | Snapshot-Länge 96 Byte | | `-w DATEI` | Rohpakete in Datei schreiben | | `-r DATEI` | vorhandene Datei lesen | | Filter am Ende | Capture-Filter | > Eine geringe Snapshot-Länge reduziert den gespeicherten Paketinhalt, kann aber wichtige Protokollinformationen abschneiden. Außerdem bleiben Netzwerkheader, Adressen und möglicherweise Teile der Nutzdaten erhalten. Trunkierung ist keine vollständige Anonymisierung.
12. Wie wird eine Ringpuffer-Aufzeichnung sicher begrenzt? Ein Ringpuffer schreibt mehrere Dateien und überschreibt nach Erreichen der festgelegten Anzahl die älteste Datei. Dadurch wird der maximale Speicherverbrauch begrenzt. **Dumpcap: fünf Dateien mit jeweils 60 Sekunden** ```bash [TEST][PRIV][FILE][SENS] dumpcap \ -i 1 \ -f "host 192.0.2.20 and tcp port 443" \ -b duration:60 \ -b files:5 \ -w capture.pcapng ``` **Dumpcap: fünf Dateien mit jeweils ungefähr 50 MB** ```bash [TEST][PRIV][FILE][SENS] dumpcap \ -i 1 \ -f "host 192.0.2.20 and tcp port 443" \ -b filesize:50000 \ -b files:5 \ -w capture.pcapng ``` **tcpdump: fünf Dateien mit ungefähr 50 MB** ```bash [TEST][PRIV][FILE][SENS] sudo tcpdump \ -i eth0 \ -nn \ -C 50 \ -W 5 \ -w capture.pcap \ 'host 192.0.2.20 and tcp port 443' ``` Bei `tcpdump` können Einheit und Verhalten einzelner Rotationsoptionen von der verwendeten Implementierung und Version abhängen. Vor dem Einsatz muss die lokale Dokumentation geprüft werden: ```bash [RO] man tcpdump ``` **Wichtiger Hinweis** Ein Ringpuffer verhindert unbegrenztes Dateiwachstum, löscht aber ältere Aufzeichnungen automatisch durch Überschreiben. Er ist deshalb nicht geeignet, wenn alle Daten unverändert als Beweismittel erhalten bleiben müssen.
13. Wie wird der Promiscuous Mode bewertet? Im Promiscuous Mode nimmt eine Netzwerkkarte zusätzlich Frames entgegen, die nicht unmittelbar an ihre eigene MAC-Adresse adressiert sind. ```text Promiscuous Mode ≠ automatisch gesamter Netzwerkverkehr ``` In einem geswitchten Netzwerk sieht ein Client normalerweise weiterhin nur: - eigenen Unicast-Verkehr, - Broadcasts, - relevante Multicasts, - vom Switch an diesen Port weitergeleiteten Verkehr. Für zusätzlichen Verkehr ist häufig ein korrekt konfigurierter SPAN- beziehungsweise Mirror-Port oder ein anderer geeigneter Messpunkt erforderlich. **Promiscuous Mode mit dumpcap deaktivieren** ```bash [TEST][PRIV][FILE][SENS] dumpcap \ -i 1 \ -p \ -f "host 192.0.2.20" \ -a duration:60 \ -w capture.pcapng ``` Wenn nur lokaler Hostverkehr benötigt wird, kann die Deaktivierung des Promiscuous Mode die Erfassung unbeabsichtigten Verkehrs reduzieren.
14. Was ist bei WLAN-Mitschnitten und Monitor Mode zu beachten? Der WLAN-Monitor-Mode kann rohe 802.11-Frames eines Funkkanals erfassen. Unterstützung und Verhalten hängen ab von: - Betriebssystem, - WLAN-Chipsatz, - Treiber, - Kanal, - Frequenzband, - Verschlüsselung, - aktueller Verbindung. Das Aktivieren des Monitor Mode kann die bestehende WLAN-Verbindung unterbrechen: ```text [CHANGE][DISRUPT] ``` Zusätzlich können Kommunikationsdaten anderer Geräte im Funkbereich erfasst werden. Ein WLAN-Mitschnitt benötigt daher eine besonders klare technische und organisatorische Abgrenzung. Für eine gewöhnliche Client-Fehleranalyse ist häufig ein Mitschnitt am regulären Netzwerkinterface ohne Monitor Mode ausreichend.
15. Wie wird eine laufende Aufnahme überwacht? Während der Aufnahme sind folgende Werte zu kontrollieren: - Dateigröße, - verbleibender Speicherplatz, - Paketanzahl, - verworfene Pakete, - CPU-Auslastung, - Schreibgeschwindigkeit, - Aufnahmezeit, - korrekte Schnittstelle, - korrekter Filter, - Zeitpunkt der Fehlerreproduktion. **Speicherplatz prüfen** Windows: ```powershell [RO] Get-Volume ``` Linux: ```bash [RO] df -h ``` macOS: ```bash [RO] df -h ``` **Dateigröße beobachten** Windows: ```powershell [RO] Get-Item '.\capture.pcapng' | Select-Object FullName, Length, LastWriteTime ``` Linux und macOS: ```bash [RO] ls -lh capture.pcapng ``` Wenn Capture-Pakete verworfen werden, ist die Aufzeichnung möglicherweise unvollständig. Mögliche Ursachen: - Capture-Puffer zu klein, - Datenträger zu langsam, - zu hohe Paketrate, - System zu stark ausgelastet, - zu umfangreiche Live-Anzeige, - ungeeigneter Messpunkt. Ein größerer Capture-Puffer kann helfen, benötigt aber zusätzlichen Arbeitsspeicher und ersetzt keine Bewertung der Systemkapazität.
16. Wie wird ein Mitschnitt unmittelbar nach der Aufnahme geprüft? **Dateiinformationen anzeigen** Windows, Linux und macOS: ```bash [RO][SENS] capinfos capture.pcapng ``` Wichtige Informationen: - Dateiformat, - Dateigröße, - Anzahl der Pakete, - erstes und letztes Paket, - Aufzeichnungsdauer, - Schnittstelle, - Kapselung, - Datenrate, - gespeicherte Paketlängen, - vorhandene Kommentare oder Geheimnisse. **Kurze Protokollübersicht** ```bash [RO][SENS] tshark -r capture.pcapng -q -z io,phs ``` **Kommunikationsbeziehungen** ```bash [RO][SENS] tshark -r capture.pcapng -q -z endpoints,ip ``` ```bash [RO][SENS] tshark -r capture.pcapng -q -z conv,tcp ``` **Prüffragen** 1. Enthält die Datei den erwarteten Zeitraum? 2. Ist die richtige Schnittstelle erfasst? 3. Ist der Zielverkehr enthalten? 4. Wurde unbeabsichtigter Fremdverkehr gespeichert? 5. Sind unverschlüsselte Inhalte sichtbar? 6. Enthält die Datei eingebettete Entschlüsselungsgeheimnisse? 7. Sind Kommentare oder Metadaten vorhanden? 8. Ist eine weitere Reduktion erforderlich? 9. Muss die Originaldatei erhalten bleiben? 10. Wer darf die Datei öffnen?
17. Wie wird aus einer großen Aufzeichnung eine zeitlich begrenzte Arbeitskopie erstellt? Mit `editcap` kann ein Zeitbereich aus einer vorhandenen Datei in eine neue Datei geschrieben werden. **Zeitbereich mit UTC-Offset auswählen** ```bash [RO][FILE][SENS] editcap \ -A "2026-07-31T09:42:00+02:00" \ -B "2026-07-31T09:44:00+02:00" \ original.pcapng \ arbeitskopie.pcapng ``` `-A` nimmt Pakete ab dem angegebenen Zeitpunkt auf. `-B` begrenzt auf Pakete vor dem angegebenen Endzeitpunkt. **Bestimmte Paketnummern übernehmen** Nur Pakete 200 bis 750 schreiben: ```bash [RO][FILE][SENS] editcap \ -r \ original.pcapng \ arbeitskopie.pcapng \ 200-750 ``` **Erste 500 Pakete übernehmen** ```bash [RO][FILE][SENS] editcap \ -r \ original.pcapng \ erste-500.pcapng \ 1-500 ``` Die neue Datei muss anschließend erneut mit Wireshark, TShark oder Capinfos geprüft werden. Eine erfolgreiche Programmausführung beweist nicht, dass alle unerwünschten Daten entfernt wurden.
18. Wie wird eine Datei nach einem Display-Filter exportiert? Mit TShark kann aus einer vorhandenen Aufzeichnung eine gefilterte Datei erzeugt werden. **Nur Verkehr eines bestimmten Hosts exportieren** ```bash [RO][FILE][SENS] tshark \ -r original.pcapng \ -Y "ip.addr == 192.0.2.20" \ -w gefiltert.pcapng ``` **Nur TCP-Port 443 zu einem bestimmten Host** ```bash [RO][FILE][SENS] tshark \ -r original.pcapng \ -Y "ip.addr == 192.0.2.20 && tcp.port == 443" \ -w gefiltert.pcapng ``` **Nur ein bestimmtes TCP-Gespräch** Zunächst Streamnummer in Wireshark oder TShark bestimmen. Anschließend beispielsweise: ```bash [RO][FILE][SENS] tshark \ -r original.pcapng \ -Y "tcp.stream == 4" \ -w tcp-stream-4.pcapng ``` **Wichtig** - Ein Export nach Display-Filter erzeugt eine neue reduzierte Datei. - Das Original bleibt unverändert. - Nicht angezeigte Pakete werden beim Export nicht übernommen. - Die übernommenen Pakete enthalten weiterhin ihre vollständigen gespeicherten Header und Nutzdaten. - Die gefilterte Datei ist deshalb nicht automatisch anonymisiert.
19. Wie werden eingebettete Entschlüsselungsgeheimnisse und Kommentare entfernt? PCAPNG-Dateien können zusätzliche Metadaten enthalten, darunter: - Capture-Kommentare, - Paketkommentare, - Schnittstelleninformationen, - Decryption Secrets Blocks. Vor einer Weitergabe muss geprüft werden, ob solche Informationen vorhanden sind. **Eingebettete Entschlüsselungsgeheimnisse entfernen** ```bash [RO][FILE][SENS] editcap \ --discard-all-secrets \ original.pcapng \ ohne-secrets.pcapng ``` **Capture- und Paketkommentare entfernen** ```bash [RO][FILE][SENS] editcap \ --discard-capture-comment \ --discard-packet-comments \ original.pcapng \ ohne-kommentare.pcapng ``` **Kombiniert** ```bash [RO][FILE][SENS] editcap \ --discard-all-secrets \ --discard-capture-comment \ --discard-packet-comments \ original.pcapng \ bereinigt.pcapng ``` Danach muss die Ausgabedatei erneut geprüft werden: ```bash [RO][SENS] capinfos bereinigt.pcapng ``` Das Entfernen von Geheimnisblöcken und Kommentaren entfernt nicht automatisch IP-Adressen, MAC-Adressen, Hostnamen oder Nutzdaten.
20. Warum ist Trunkierung keine vollständige Anonymisierung? Mit `editcap -s` kann die gespeicherte Länge jedes Pakets begrenzt werden. **Auf 96 Byte kürzen** ```bash [RO][FILE][SENS] editcap \ -s 96 \ original.pcapng \ gekuerzt.pcapng ``` Dadurch können Teile der Nutzdaten entfernt werden. Abhängig von den vorhandenen Protokollheadern können aber weiterhin enthalten sein: - MAC-Adressen, - VLAN-Informationen, - IP-Adressen, - Ports, - TCP-Flags, - DNS-Inhalte, - TLS-Informationen, - Teile der Nutzdaten. Eine feste Snapshot-Länge kann außerdem die technische Analyse beeinträchtigen. ```text Gekürzt ≠ anonymisiert ``` Eine belastbare Anonymisierung erfordert: - Definition der zu schützenden Felder, - geeignetes Werkzeug und Verfahren, - Prüfung der resultierenden Datei, - Berücksichtigung eingebetteter Metadaten, - Berücksichtigung rekonstruierbarer Zusammenhänge. Wireshark und Editcap bieten keine allgemeine Ein-Klick-Anonymisierung, die für jedes Protokoll zuverlässig sämtliche personenbezogenen oder vertraulichen Inhalte entfernt.
21. Wie werden Hashwerte zur Integritätsprüfung erstellt? Ein kryptografischer Hash dokumentiert den Zustand einer Datei zu einem bestimmten Zeitpunkt. Wird die Datei verändert, ändert sich mit sehr hoher Wahrscheinlichkeit auch der Hash. **Windows** ```powershell [RO] Get-FileHash ` 'C:\Diagnose\original.pcapng' ` -Algorithm SHA256 ``` Hash in Datei dokumentieren: ```powershell [RO][FILE] Get-FileHash ` 'C:\Diagnose\original.pcapng' ` -Algorithm SHA256 | Format-List | Out-File 'C:\Diagnose\original.pcapng.sha256.txt' ``` **Linux** ```bash [RO] sha256sum original.pcapng ``` ```bash [RO][FILE] sha256sum original.pcapng \ > original.pcapng.sha256 ``` **macOS** ```bash [RO] shasum -a 256 original.pcapng ``` ```bash [RO][FILE] shasum -a 256 original.pcapng \ > original.pcapng.sha256 ``` **Erneut prüfen** Linux: ```bash [RO] sha256sum -c original.pcapng.sha256 ``` macOS: ```bash [RO] shasum -a 256 -c original.pcapng.sha256 ``` Ein Hash beweist nicht automatisch, wer die Datei erstellt hat oder ob der ursprüngliche Mitschnitt vollständig war. Er hilft aber festzustellen, ob sich genau diese Datei nach der Hashbildung verändert hat.
22. Wie werden Original und Arbeitskopie getrennt? Empfohlene Struktur: ```text TICKET-4711/ ├── original/ │ ├── TICKET-4711_CLIENT-023_original.pcapng │ └── TICKET-4711_CLIENT-023_original.pcapng.sha256 ├── working/ │ ├── TICKET-4711_zeitfenster.pcapng │ └── TICKET-4711_tcp-stream-4.pcapng ├── export/ │ └── TICKET-4711_freigegebene-kopie.pcapng └── dokumentation/ └── TICKET-4711_capture-protokoll.txt ``` **Regeln** - Original nach der Sicherung nicht mehr bearbeiten. - Hash des Originals unmittelbar nach der Aufnahme erstellen. - Analysen auf einer Arbeitskopie durchführen. - Weitergabekopie getrennt erzeugen. - Jede Bearbeitung dokumentieren. - Weitergabekopie vor Übergabe erneut kontrollieren. - Hashwerte von Original und Export getrennt dokumentieren. Das Original enthält möglicherweise mehr sensible Daten als die freigegebene Weitergabekopie und benötigt entsprechend strengere Zugriffsrechte.
23. Wie werden Dateizugriffe technisch eingeschränkt? **Windows-Beispiel** Vererbung entfernen: ```cmd [CHANGE][PRIV] icacls "C:\Diagnose\TICKET-4711" /inheritance:r ``` Einem ausdrücklich festgelegten Konto Zugriff gewähren: ```cmd [CHANGE][PRIV] icacls "C:\Diagnose\TICKET-4711" /grant:r "DOMÄNE\Diagnosekonto:(OI)(CI)F" ``` Vorher müssen Konto, gewünschte Rechte und bestehende Berechtigungen genau geprüft werden. Ein falscher `icacls`-Befehl kann berechtigte Personen aussperren. Aktuelle Berechtigungen anzeigen: ```cmd [RO] icacls "C:\Diagnose\TICKET-4711" ``` **Linux und macOS** Verzeichnis nur für den Eigentümer zugänglich machen: ```bash [CHANGE] chmod 700 /pfad/TICKET-4711 ``` Datei nur für den Eigentümer les- und schreibbar machen: ```bash [CHANGE] chmod 600 /pfad/TICKET-4711/original.pcapng ``` Berechtigungen prüfen: ```bash [RO] ls -ld /pfad/TICKET-4711 ``` ```bash [RO] ls -l /pfad/TICKET-4711 ``` Dateiberechtigungen ersetzen keine Verschlüsselung, keine sichere Übertragung und keine organisatorische Zugriffskontrolle.
24. Wie wird ein Paketmitschnitt sicher weitergegeben? Vor jeder Weitergabe: 1. Empfänger und Zweck bestätigen. 2. Vertragliche und datenschutzrechtliche Zulässigkeit prüfen. 3. Nur den erforderlichen Zeit- und Datenbereich exportieren. 4. Unnötige Pakete entfernen. 5. Kommentare und eingebettete Geheimnisse entfernen. 6. Datei auf unverschlüsselte Inhalte prüfen. 7. Freigegebene Kopie getrennt speichern. 8. Hash der freigegebenen Datei berechnen. 9. Sicheren Übertragungsweg verwenden. 10. Kennwort oder Schlüssel über einen getrennten Kanal übermitteln. 11. Übergabe im Ticket dokumentieren. 12. Löschung beim Empfänger vereinbaren und dokumentieren. **Nicht geeignete Übertragungswege** - öffentlicher Dateilink ohne Zugriffsschutz, - unverschlüsselte E-Mail, - privater Messenger ohne Freigabe, - öffentliches Cloudlaufwerk, - frei zugänglicher Webserver, - unkontrollierter USB-Datenträger. Ein vom Hersteller bereitgestelltes Supportportal ist nicht automatisch für beliebige vertrauliche Daten freigegeben. Vertragslage, Standort, Auftragsverarbeitung und interne Vorgaben müssen geprüft werden.
25. Was ist bei TLS-Entschlüsselung zu beachten? TLS-Entschlüsselung kann Inhalte sichtbar machen, die gerade durch Verschlüsselung geschützt werden sollen. Mögliche Inhalte: - Zugangsdaten, - Sitzungscookies, - API-Token, - personenbezogene Daten, - Formulardaten, - Dateiinhalte, - interne Anwendungsinformationen. TLS-Key-Log-Dateien und private Schlüssel sind besonders schützenswert: ```text [SENS] Eine TLS-Key-Log-Datei kann die Entschlüsselung aufgezeichneter Sitzungen ermöglichen. ``` **Regeln** - nur mit ausdrücklicher Freigabe, - nur für den erforderlichen Prozess oder Testbenutzer, - möglichst in kontrollierter Testumgebung, - Key-Log-Datei getrennt schützen, - nicht gemeinsam mit der Aufzeichnung unkontrolliert versenden, - nach Abschluss kontrolliert löschen, - niemals produktive private Server-Schlüssel exportieren, wenn dies nicht ausdrücklich erforderlich und freigegeben ist. PCAPNG-Dateien können Entschlüsselungsgeheimnisse eingebettet enthalten. Vor einer Weitergabe muss dies ausdrücklich geprüft werden.
26. Welche Fehler treten bei Paketmitschnitten häufig auf? | Fehler | Folge | Besseres Vorgehen | |---|---|---| | falsche Schnittstelle | relevanter Verkehr fehlt | IP-Konfiguration und Route vorher prüfen | | Aufnahme am falschen Messpunkt | Ursache bleibt unsichtbar | Kommunikationsweg zeichnen | | kein Capture-Filter | unnötig viele sensible Daten | Zielhost und Port begrenzen | | nur Display-Filter verwendet | Fremdverkehr bleibt in Datei | reduzierte Datei exportieren | | Aufnahme läuft unbegrenzt | Speicherplatz und Datenschutzproblem | Dauer, Größe oder Ringpuffer begrenzen | | Fehler nicht reproduziert | relevanter Vorgang fehlt | exakten Reproduktionszeitpunkt notieren | | Namensauflösung aktiv | Anzeige wird verfälscht oder zusätzliche DNS-Last entsteht | bei Analyse gegebenenfalls numerische Anzeige verwenden | | Zeitabweichung ignoriert | Client- und Servermitschnitt passen nicht zusammen | Uhren und Zeitzonen prüfen | | Snapshot-Länge zu klein | benötigte Protokolldaten fehlen | Anforderung vor Aufnahme bestimmen | | Snapshot-Länge unbegrenzt | unnötige Nutzdaten werden gespeichert | erforderliche Länge bewusst festlegen | | Original direkt bearbeitet | Nachvollziehbarkeit geht verloren | Original und Arbeitskopie trennen | | Datei unverschlüsselt versendet | Datenabfluss möglich | freigegebenen sicheren Kanal verwenden | | PCAP öffentlich hochgeladen | vertrauliche Daten offengelegt | interne oder freigegebene Analyse | | Datei nur umbenannt | Inhalt bleibt vollständig erhalten | echte Reduktion und Prüfung durchführen | | Hash erst nach Bearbeitung erstellt | ursprünglicher Zustand nicht belegt | Hash unmittelbar nach Sicherung bilden | | Wireshark als Root gestartet | unnötig große Angriffsfläche | Capture-Funktion auf Dumpcap beschränken |
27. Wie läuft ein sicherer Paketmitschnitt vollständig ab? | Phase | Vorgehen | |---|---| | 1. Auftrag klären | technisches Problem und Zweck dokumentieren | | 2. Freigabe einholen | Zuständigkeit, Datenschutz und Sicherheit klären | | 3. Kommunikationsweg zeichnen | Client, Netzwerkkomponenten und Server bestimmen | | 4. Messpunkt wählen | so nah wie möglich am vermuteten Problem | | 5. Schnittstelle prüfen | Interface, IP-Adresse und Route bestätigen | | 6. Filter festlegen | Host, Port und Protokoll begrenzen | | 7. Umfang begrenzen | Dauer, Paketanzahl, Dateigröße und Snapshot-Länge | | 8. Speicher schützen | Zugriffsrechte und freien Speicherplatz prüfen | | 9. Aufnahme starten | Startzeit und Werkzeugversion dokumentieren | | 10. Fehler reproduzieren | genau definierte Aktion ausführen | | 11. Aufnahme stoppen | unmittelbar nach dem relevanten Vorgang | | 12. Datei prüfen | Zeitraum, Pakete, Fremdverkehr und Geheimnisse | | 13. Original sichern | Hash bilden und Original unverändert ablegen | | 14. Arbeitskopie erzeugen | Zeitfenster und relevante Kommunikation reduzieren | | 15. Technisch analysieren | Protokollablauf und Fehlerhypothese untersuchen | | 16. Weitergabe vorbereiten | Daten minimieren und Freigabe einholen | | 17. Ergebnis dokumentieren | Ursache, Belege und Grenzen festhalten | | 18. Daten löschen | Aufbewahrungsfrist und Löschbestätigung beachten |
28. Kompakte Befehlsübersicht | Aufgabe | Befehl | Kennzeichnung | |---|---|---| | Capture-Schnittstellen anzeigen | `dumpcap -D` | `[RO]` | | tcpdump-Schnittstellen anzeigen | `tcpdump -D` | `[RO]` | | 60 Sekunden aufzeichnen | `dumpcap -i 1 -a duration:60 -w capture.pcapng` | `[TEST][PRIV][FILE][SENS]` | | gefiltert aufzeichnen | `dumpcap -i 1 -f "host 192.0.2.20 and tcp port 443" -a duration:60 -w capture.pcapng` | `[TEST][PRIV][FILE][SENS]` | | nach 10.000 Paketen stoppen | `dumpcap -i 1 -c 10000 -w capture.pcapng` | `[TEST][PRIV][FILE][SENS]` | | Paketlänge begrenzen | `dumpcap -i 1 -s 96 -a duration:60 -w capture.pcapng` | `[TEST][PRIV][FILE][SENS]` | | Ringpuffer | `dumpcap -i 1 -b duration:60 -b files:5 -w capture.pcapng` | `[TEST][PRIV][FILE][SENS]` | | Dateiinformationen | `capinfos capture.pcapng` | `[RO][SENS]` | | Protokollhierarchie | `tshark -r capture.pcapng -q -z io,phs` | `[RO][SENS]` | | IP-Endpunkte | `tshark -r capture.pcapng -q -z endpoints,ip` | `[RO][SENS]` | | TCP-Gespräche | `tshark -r capture.pcapng -q -z conv,tcp` | `[RO][SENS]` | | Zeitbereich exportieren | `editcap -A "START" -B "ENDE" original.pcapng arbeitskopie.pcapng` | `[RO][FILE][SENS]` | | Paketbereich exportieren | `editcap -r original.pcapng auszug.pcapng 200-750` | `[RO][FILE][SENS]` | | Pakete nach Filter exportieren | `tshark -r original.pcapng -Y "ip.addr == 192.0.2.20" -w gefiltert.pcapng` | `[RO][FILE][SENS]` | | Geheimnisblöcke entfernen | `editcap --discard-all-secrets original.pcapng bereinigt.pcapng` | `[RO][FILE][SENS]` | | Kommentare entfernen | `editcap --discard-capture-comment --discard-packet-comments original.pcapng bereinigt.pcapng` | `[RO][FILE][SENS]` | | Paketdaten kürzen | `editcap -s 96 original.pcapng gekuerzt.pcapng` | `[RO][FILE][SENS]` | | SHA-256 unter Windows | `Get-FileHash .\capture.pcapng -Algorithm SHA256` | `[RO]` | | SHA-256 unter Linux | `sha256sum capture.pcapng` | `[RO]` | | SHA-256 unter macOS | `shasum -a 256 capture.pcapng` | `[RO]` |
29. Dokumentationsvorlage für einen Paketmitschnitt ```text Ticketnummer: Auftraggebende Stelle: Ausführende Person: Freigabe erteilt durch: Freigabezeitpunkt: Datenschutzprüfung: Informationssicherheit informiert: Betriebsrat einbezogen oder nicht erforderlich: Technischer Zweck: Fehlerbeschreibung: Betroffene Systeme: Betroffene Benutzergruppe: Ausgeschlossene Systeme: Erlaubter Datenumfang: Capture-System: Betriebssystem: Capture-Werkzeug: Werkzeugversion: Capture-Schnittstelle: IP-Adresse der Schnittstelle: Capture-Position: Promiscuous Mode: Ja / Nein Monitor Mode: Ja / Nein Capture-Filter: Snapshot-Länge: Maximale Dauer: Maximale Paketanzahl: Maximale Dateigröße: Ringpuffer: Ja / Nein Anzahl Ringpufferdateien: Startzeit: Endzeit: Zeitzone: Zeitpunkt der Fehlerreproduktion: Durchgeführte Aktion: Originaldatei: Dateigröße: Paketanzahl: Erstes Paket: Letztes Paket: SHA-256 des Originals: Speicherort des Originals: Zugriffsberechtigte Personen: Arbeitskopie: Verwendeter Zeitfilter: Verwendeter Display-Filter: Entfernte Kommentare: Entfernte Entschlüsselungsgeheimnisse: Snapshot-Länge nach Bearbeitung: SHA-256 der Arbeitskopie: Ermittelte Beobachtungen: 1. 2. 3. Arbeitshypothese: Beleg: Gegenprüfung: Ermittelte Ursache: Weitergabe erforderlich: Ja / Nein Empfänger: Rechts- und Datenschutzprüfung: Weitergabedatei: SHA-256 der Weitergabedatei: Übertragungsweg: Übergabezeitpunkt: Löschvereinbarung mit Empfänger: Interne Aufbewahrungsfrist: Geplanter Löschtermin: Tatsächlicher Löschzeitpunkt: Löschung bestätigt durch: ```
30. Offizielle Quellen und weiterführende Dokumentation **Wireshark** - [Wireshark User’s Guide](https://www.wireshark.org/docs/wsug_html/) - [Wireshark Capture Options](https://www.wireshark.org/docs/wsug_html_chunked/ChCapCaptureOptions.html) - [Wireshark Capture Filters](https://www.wireshark.org/docs/wsug_html_chunked/ChCapCaptureFilterSection.html) - [Wireshark Display Filters](https://www.wireshark.org/docs/wsug_html_chunked/ChWorkBuildDisplayFilterSection.html) - [dumpcap – offizielle Manual Page](https://www.wireshark.org/docs/man-pages/dumpcap.html) - [tshark – offizielle Manual Page](https://www.wireshark.org/docs/man-pages/tshark.html) - [editcap – offizielle Manual Page](https://www.wireshark.org/docs/man-pages/editcap.html) - [capinfos – offizielle Manual Page](https://www.wireshark.org/docs/man-pages/capinfos.html) - [Wireshark Manual Pages](https://www.wireshark.org/docs/man-pages/) **tcpdump und libpcap** - [tcpdump – offizielle Dokumentation](https://www.tcpdump.org/manpages/tcpdump.1.html) - [pcap-filter – offizielle Filtersyntax](https://www.tcpdump.org/manpages/pcap-filter.7.html) **Datenschutzrecht** - [Datenschutz-Grundverordnung – EUR-Lex](https://eur-lex.europa.eu/eli/reg/2016/679/oj) - [Bundesbeauftragte für den Datenschutz und die Informationsfreiheit](https://www.bfdi.bund.de/) - [Datenschutzkonferenz des Bundes und der Länder](https://www.datenschutzkonferenz-online.de/) > Welche rechtliche Grundlage, Beteiligung oder Dokumentation im konkreten Unternehmen erforderlich ist, muss durch die zuständigen Datenschutz-, Sicherheits- und Rechtsstellen entschieden werden. Die technische Möglichkeit eines Paketmitschnitts stellt keine automatische Berechtigung zur Durchführung dar.
# 3. Netzwerkfehler systematisch analysieren # 3.0 Netzwerkfehler systematisch eingrenzen Netzwerkstörungen sollten nicht durch zufälliges Ausprobieren einzelner Befehle untersucht werden. Eine zuverlässige Diagnose beginnt beim betroffenen Endgerät und arbeitet sich schrittweise durch die beteiligten Ebenen und Komponenten bis zum Zielsystem vor. Dieses Kapitel behandelt typische Fehler in lokalen Netzwerken, standortübergreifenden Verbindungen und beim Zugriff auf interne oder externe Dienste. > **Grundregel:** Zuerst feststellen, auf welcher Ebene die Kommunikation scheitert. Erst danach wird die konkrete Ursache innerhalb dieser Ebene untersucht. ---
1. Welche Ziele verfolgt dieses Kapitel? Nach diesem Kapitel soll eine Netzwerkstörung strukturiert folgenden Bereichen zugeordnet werden können: - physische Verbindung, - Netzwerkschnittstelle und Treiber, - VLAN und Layer-2-Kommunikation, - IP-Konfiguration und Subnetz, - DHCP, - ARP beziehungsweise IPv6 Neighbor Discovery, - Routing und Standardgateway, - DNS und Namensauflösung, - TCP- und UDP-Ports, - Firewall und Paketfilter, - NAT und Portweiterleitung, - Proxy und Reverse Proxy, - VPN und Tunnel, - WLAN, - Netzwerkperformance, - Paketverlust und Wiederholungen, - MTU und Fragmentierung, - interne oder externe Zielsysteme. Das Ziel ist nicht nur, die Verbindung wiederherzustellen, sondern die tatsächliche Ursache nachvollziehbar zu bestimmen und zu dokumentieren.
2. Welche Seiten enthält das Kapitel? | Seite | Thema | Zentrale Fragestellung | |---:|---|---| | 3.0 | Netzwerkfehler systematisch eingrenzen | Wie wird eine Netzwerkstörung grundsätzlich untersucht? | | 3.1 | Störungsumfang und Kommunikationsweg bestimmen | Wer ist betroffen und welchen Weg nimmt die Verbindung? | | 3.2 | Physische Verbindung und Netzwerkschnittstelle | Bestehen Link, Signal und fehlerfreie Schnittstellenkommunikation? | | 3.3 | IP-Konfiguration und Subnetz prüfen | Besitzt das Endgerät eine gültige und passende Konfiguration? | | 3.4 | DHCP-Fehler analysieren | Warum erhält ein Client keine oder eine falsche IP-Konfiguration? | | 3.5 | ARP und IPv6 Neighbor Discovery | Kann die lokale Zieladresse einer MAC-Adresse zugeordnet werden? | | 3.6 | VLAN- und Layer-2-Fehler | Befinden sich Port und Endgerät im richtigen logischen Netz? | | 3.7 | Standardgateway und Routing | Existiert ein gültiger Weg zum Zielnetz? | | 3.8 | DNS-Fehler analysieren | Ist nur die Namensauflösung oder die gesamte Verbindung gestört? | | 3.9 | Ports und Transportprotokolle prüfen | Ist der benötigte TCP- oder UDP-Dienst erreichbar? | | 3.10 | Firewall und Paketfilter untersuchen | Wo und warum wird Kommunikation zugelassen oder verworfen? | | 3.11 | NAT und Portweiterleitungen | Werden Adressen und Ports korrekt übersetzt? | | 3.12 | Proxy und Reverse Proxy | Scheitert die Verbindung am Proxy, Backend oder Client? | | 3.13 | VPN- und Tunnelprobleme | Sind Tunnel, Routen, DNS und MTU korrekt? | | 3.14 | WLAN-Störungen analysieren | Liegt die Ursache bei Signal, Funkkanal, Authentifizierung oder IP-Konfiguration? | | 3.15 | Paketverlust, Latenz und Jitter | Wo entsteht eine instabile oder langsame Verbindung? | | 3.16 | MTU, MSS und Fragmentierungsprobleme | Sind Pakete für einen Teil des Übertragungsweges zu groß? | | 3.17 | Asymmetrisches Routing | Nehmen Hin- und Rückweg unterschiedliche, problematische Wege? | | 3.18 | Netzwerkfehler mit Wireshark erkennen | Welche Paketsequenz belegt die technische Störung? | | 3.19 | Typische Netzwerkfehler nach Symptomen | Welche Prüfungen passen zu einem konkreten Fehlerbild? | | 3.20 | Befehlsübersicht für Windows, Linux und macOS | Welcher Befehl prüft welche Netzwerkebene? | | 3.21 | Dokumentations- und Eskalationsvorlage | Wie wird die Analyse vollständig übergeben? |
3. Welche Kennzeichnungen werden verwendet? | Kennzeichnung | Bedeutung | |---|---| | `[RO]` | Read-only: liest Informationen aus | | `[TEST]` | führt eine aktive Netzwerkprüfung durch | | `[PRIV]` | benötigt möglicherweise Administrator- oder Root-Rechte | | `[FILE]` | erzeugt oder verändert eine Datei | | `[SENS]` | Ausgabe kann vertrauliche Daten enthalten | | `[CHANGE]` | verändert eine Konfiguration oder einen Systemzustand | | `[DISRUPT]` | kann eine bestehende Verbindung oder einen Dienst unterbrechen | **Beispiele** ```powershell [RO] Get-NetIPConfiguration ``` Der Befehl zeigt die vorhandene Windows-Netzwerkkonfiguration an. ```bash [TEST] ping -c 4 192.0.2.1 ``` Der Befehl sendet aktiv ICMP-Echo-Anfragen. ```powershell [PRIV][CHANGE][DISRUPT] Restart-NetAdapter -Name 'Ethernet' ``` Dieser Befehl startet den Netzwerkadapter neu und unterbricht dabei bestehende Verbindungen. Er darf nicht als erster Diagnoseschritt verwendet werden.
4. Wie wird der Kommunikationsweg dargestellt? Vor der technischen Analyse sollte der erwartete Kommunikationsweg gezeichnet werden. **Beispiel: Zugriff auf eine interne Anwendung** ```text Client → Netzwerkschnittstelle → Access Switch → VLAN → Standardgateway → Firewall → Reverse Proxy → Anwendungsserver → Datenbankserver ``` **Beispiel: Internetzugriff** ```text Client → Switch oder Access Point → lokales Gateway → Firewall → NAT → Internetprovider → externes Zielsystem ``` **Beispiel: VPN-Zugriff** ```text Client → lokales Netzwerk → Internet → VPN-Gateway → VPN-Tunnel → interne Firewall → Zielserver ``` Jede Verbindung besteht aus mehreren möglichen Fehlerstellen. Der Kommunikationsweg verhindert, dass Komponenten untersucht werden, die an der Verbindung überhaupt nicht beteiligt sind.
5. Wie wird eine Netzwerkstörung sinnvoll eingegrenzt? Die Untersuchung sollte vom Allgemeinen zum Spezifischen erfolgen. | Schritt | Fragestellung | |---:|---| | 1 | Was funktioniert konkret nicht? | | 2 | Seit wann besteht die Störung? | | 3 | Wer oder was ist betroffen? | | 4 | Was funktioniert weiterhin? | | 5 | Welche Änderung ging der Störung voraus? | | 6 | Welcher Kommunikationsweg wird erwartet? | | 7 | Auf welcher Ebene liegt der erste Fehler? | | 8 | Ist die Störung reproduzierbar? | | 9 | Welche Messung belegt die Vermutung? | | 10 | Welche einzelne Änderung kann die Hypothese prüfen? | | 11 | Wurde die ursprüngliche Funktion wiederhergestellt? | | 12 | Wurden Ursache, Änderung und Ergebnis dokumentiert? | **Beispiel** ```text Unzureichende Fehlerbeschreibung: „Das Netzwerk funktioniert nicht.“ Bessere Fehlerbeschreibung: „CLIENT-023 kann seit 09:42 Uhr den internen Webserver app.example.intern nicht über TCP 443 erreichen. Andere interne Server sind erreichbar. Weitere Clients im selben VLAN sind nicht betroffen.“ ``` Die zweite Beschreibung grenzt die Störung bereits deutlich ein: - ein Client betroffen, - ein bestimmtes Ziel betroffen, - ein bestimmter Dienst betroffen, - andere Ziele funktionieren, - der Fehler besitzt einen bekannten Startzeitpunkt.
6. Welche Prüfungsreihenfolge ist in der Praxis sinnvoll? | Reihenfolge | Bereich | Beispielprüfung | |---:|---|---| | 1 | Fehlerbild und Umfang | ein Benutzer, mehrere Benutzer oder gesamter Standort? | | 2 | lokale Schnittstelle | Adapter aktiv, Link vorhanden, Fehlerzähler? | | 3 | IP-Konfiguration | Adresse, Präfix, Gateway und DNS korrekt? | | 4 | lokale TCP/IP-Funktion | Loopback und eigene Adresse erreichbar? | | 5 | lokales Netz | Gateway und Nachbarn erreichbar? | | 6 | Routing | existiert eine Route zum Ziel? | | 7 | Namensauflösung | wird der richtige Name zur richtigen Adresse aufgelöst? | | 8 | Transportebene | ist der benötigte TCP- oder UDP-Port erreichbar? | | 9 | Sicherheitskomponenten | blockieren Host-Firewall, Netzwerk-Firewall oder ACL? | | 10 | Anwendungsebene | antwortet der eigentliche Dienst korrekt? | | 11 | Performance | treten Latenz, Paketverlust oder Wiederholungen auf? | | 12 | Paketmitschnitt | welche Paketsequenz belegt den Fehler? | Diese Reihenfolge darf an das konkrete Fehlerbild angepasst werden. Wenn beispielsweise bereits eine falsche IP-Adresse sichtbar ist, muss nicht zuerst ein entfernter Anwendungsserver untersucht werden.
7. Wie helfen OSI- und TCP/IP-Modell bei der Fehleranalyse? | OSI-Schicht | Typische Komponenten | Typische Fehler | |---:|---|---| | 1 – Bitübertragung | Kabel, Funk, Stecker, Transceiver | kein Link, Signalstörung, beschädigtes Kabel | | 2 – Sicherung | Ethernet, MAC, Switch, VLAN | falsches VLAN, Portfehler, Layer-2-Schleife | | 3 – Vermittlung | IPv4, IPv6, Router | falsches Subnetz, fehlende Route, falsches Gateway | | 4 – Transport | TCP, UDP | Port geschlossen, Verbindungsabbruch, Paketverlust | | 5 – Sitzung | Sitzungssteuerung | Sitzung läuft ab oder wird nicht aufgebaut | | 6 – Darstellung | TLS, Kodierung | Zertifikat, Verschlüsselung oder Format inkompatibel | | 7 – Anwendung | DNS, HTTP, SMB, SSH | Dienstfehler, Authentifizierung oder falsche Konfiguration | **Wichtiger Hinweis** Das OSI-Modell ist ein Denk- und Strukturierungsmodell. Reale Protokolle und Anwendungen lassen sich nicht immer vollständig einer einzigen Schicht zuordnen. **Praktische Reihenfolge** ```text Link vorhanden? ↓ gültige IP-Konfiguration? ↓ lokales Gateway erreichbar? ↓ Route zum Ziel vorhanden? ↓ Name korrekt aufgelöst? ↓ Port erreichbar? ↓ Anwendungsprotokoll funktioniert? ```
8. Was bedeutet Bottom-up, Top-down und Divide-and-Conquer? **Bottom-up** Die Untersuchung beginnt auf der untersten Ebene: ```text Kabel → Link → VLAN → IP → Route → Port → Anwendung ``` Geeignet bei: - vollständig fehlender Verbindung, - unbekannter Fehlerstelle, - neu aufgebauter Infrastruktur, - physischen oder lokalen Auffälligkeiten. **Top-down** Die Untersuchung beginnt bei der Anwendung: ```text Anwendung → Port → DNS → Route → IP → Link ``` Geeignet bei: - klarer Anwendungsfehlermeldung, - nur einem betroffenen Dienst, - ansonsten funktionierendem Netzwerk, - bekanntem HTTP-, TLS- oder Authentifizierungsfehler. **Divide-and-Conquer** Die Untersuchung beginnt an einer sinnvollen mittleren Stelle: ```text Kann der Client das Standardgateway erreichen? ``` - Wenn nein: Fehler wahrscheinlich lokal oder im lokalen Netz. - Wenn ja: Untersuchung in Richtung Routing, Firewall und Zielsystem fortsetzen. Diese Methode ist oft besonders effizient, wenn der Kommunikationsweg bekannt ist.
9. Welche Vergleichstests liefern besonders schnell Hinweise? | Vergleich | Aussage | |---|---| | gleicher Client, anderes Ziel | Ist nur ein Ziel betroffen? | | anderer Client, gleiches Ziel | Ist nur ein Client betroffen? | | gleiche Verbindung per IP statt Name | Liegt ein DNS-Problem nahe? | | gleicher Dienst über anderen Port | Ist nur ein Port oder Protokoll betroffen? | | LAN statt WLAN | Liegt die Ursache möglicherweise im Funknetz? | | ohne VPN statt mit VPN | Entsteht das Problem durch Tunnel, Routen oder VPN-DNS? | | funktionierendes Referenzsystem | Welche Konfiguration unterscheidet sich? | | lokaler Zugriff statt entfernter Zugriff | Funktioniert der Dienst grundsätzlich? | | anderer Benutzer am selben Client | Ist das Problem benutzerabhängig? | | gleicher Benutzer an anderem Client | Ist das Problem geräteabhängig? | Ein Vergleich ist besonders aussagekräftig, wenn dabei nur ein relevanter Faktor verändert wird.
10. Welche ersten Prüfungen sind betriebssystemübergreifend möglich? | Aufgabe | Windows | Linux | macOS | |---|---|---|---| | Hostname | `[RO] hostname` | `[RO] hostname` | `[RO] hostname` | | lokale Zeit | `[RO] Get-Date -Format o` | `[RO] date --iso-8601=seconds` | `[RO] date "+%Y-%m-%dT%H:%M:%S%z"` | | Adapterübersicht | `[RO] Get-NetAdapter` | `[RO] ip -brief link` | `[RO] ifconfig` | | IP-Konfiguration | `[RO] Get-NetIPConfiguration` | `[RO] ip -brief address` | `[RO] ifconfig` | | Routingtabelle | `[RO] Get-NetRoute` | `[RO] ip route` | `[RO] netstat -rn` | | ARP-/Nachbartabelle | `[RO] Get-NetNeighbor` | `[RO] ip neigh` | `[RO] arp -an` | | DNS-Konfiguration | `[RO] Get-DnsClientServerAddress` | `[RO] resolvectl status` | `[RO] scutil --dns` | | Name auflösen | `[TEST] Resolve-DnsName example.com` | `[TEST] getent hosts example.com` | `[TEST] dscacheutil -q host -a name example.com` | | Gateway testen | `[TEST] Test-Connection GATEWAY -Count 4` | `[TEST] ping -c 4 GATEWAY` | `[TEST] ping -c 4 GATEWAY` | | Route verfolgen | `[TEST] tracert ZIEL` | `[TEST] traceroute ZIEL` | `[TEST] traceroute ZIEL` | | TCP-Port prüfen | `[TEST] Test-NetConnection ZIEL -Port 443` | `[TEST] nc -vz ZIEL 443` | `[TEST] nc -vz ZIEL 443` | | HTTP(S) prüfen | `[TEST] curl -v https://ZIEL/` | `[TEST] curl -v https://ZIEL/` | `[TEST] curl -v https://ZIEL/` | | Verbindungen anzeigen | `[RO] Get-NetTCPConnection` | `[RO] ss -tulpen` | `[RO] netstat -anv` | Die Platzhalter `GATEWAY` und `ZIEL` müssen durch vorher eindeutig bestimmte Adressen oder Namen ersetzt werden.
11. Wie werden Testergebnisse richtig bewertet? | Ergebnis | Sichere Aussage | Nicht automatisch bewiesen | |---|---|---| | Link ist aktiv | physische beziehungsweise logische Linkerkennung besteht | vollständige Netzwerkfunktion | | Ping erfolgreich | ICMP-Antwort kam zurück | Anwendungsport funktioniert | | Ping fehlgeschlagen | keine ICMP-Antwort erhalten | Zielsystem ist ausgeschaltet | | DNS-Auflösung erfolgreich | Name wurde in eine Adresse aufgelöst | Zieladresse ist erreichbar | | TCP-Port erreichbar | TCP-Verbindung konnte aufgebaut werden | Anwendung arbeitet fachlich korrekt | | HTTP 401 | Webdienst antwortet und fordert Authentifizierung | Zugangsdaten sind falsch | | HTTP 403 | Anfrage wurde verstanden und verweigert | Netzwerk-Firewall blockiert | | HTTP 502 | Proxy erhielt keine gültige Backendantwort | Proxy selbst ist zwingend defekt | | Traceroute endet vor dem Ziel | weitere Antworten fehlen | Fehler liegt sicher am letzten sichtbaren Hop | | Keine Pakete im Mitschnitt | am Messpunkt wurde nichts erfasst | Client hat nichts gesendet | Jeder Test beantwortet nur eine begrenzte technische Frage. Die Aussage darf nicht weiter ausgedehnt werden, als das Testergebnis tatsächlich belegt.
12. Welche Störungsumfänge werden unterschieden? | Umfang | Mögliche Untersuchungsrichtung | |---|---| | ein Benutzer | Benutzerprofil, Berechtigung oder individuelle Konfiguration | | ein Endgerät | Adapter, Treiber, IP-Konfiguration oder lokale Firewall | | ein Switchport | Kabel, Port, VLAN oder Port-Security | | ein VLAN | Gateway, DHCP, ACL oder VLAN-Konfiguration | | ein Standort | WAN, Standortfirewall, DNS oder Internetanschluss | | ein Dienst | Serverprozess, Port, Firewall oder Backend | | mehrere Dienste auf einem Server | Server, Betriebssystem oder gemeinsame Ressource | | alle internen Ziele | lokales Routing, Gateway oder Firewall | | nur externe Ziele | NAT, Proxy, Internetzugang oder Provider | | alle Systeme | zentrale Infrastruktur, Stromversorgung oder großflächige Störung | **Hilfreiche Eingrenzungsfragen** ```text Funktioniert derselbe Zugriff von einem anderen Client? ``` ```text Kann der betroffene Client ein anderes Ziel erreichen? ``` ```text Funktioniert der Zugriff über die IP-Adresse? ``` ```text Ist nur ein Port oder sind alle Dienste des Zielsystems betroffen? ``` ```text Tritt der Fehler per LAN und WLAN auf? ``` ```text Tritt der Fehler nur bei aktivem VPN auf? ```
13. Welche Änderungen sind besonders häufig mit Netzwerkstörungen verbunden? - Änderung einer IP-Adresse oder eines Subnetzes, - neuer DHCP-Bereich, - geänderte DNS-Server, - neue Firewall- oder ACL-Regel, - VLAN-Änderung am Switchport, - Firmware- oder Treiberupdate, - neues Zertifikat, - Proxyänderung, - VPN-Client-Update, - Änderung an NAT oder Portweiterleitung, - Routingänderung, - Wechsel des Internetproviders, - neue Sicherheitssoftware, - Änderung an Load Balancer oder Reverse Proxy, - Server- oder Containerupdate, - Änderung von MTU oder Tunnelkonfiguration, - Ablauf eines Zertifikats oder Kennworts, - Wartungsarbeiten am Switch, Router oder Access Point. Die zeitliche Nähe einer Änderung ist ein wichtiger Hinweis, aber noch kein Beweis für die Ursache.
14. Welche Maßnahmen sollten nicht vorschnell durchgeführt werden? | Maßnahme | Risiko | |---|---| | Netzwerkadapter neu starten | bestehende Verbindungen werden unterbrochen | | DHCP-Lease freigeben | Remotezugriff kann verloren gehen | | IP-Adresse ändern | Adresskonflikt oder vollständiger Verbindungsverlust | | Routingtabelle verändern | falsche oder asymmetrische Wege | | DNS-Cache löschen | Beweise und Vergleichszustand verändern sich | | Firewall deaktivieren | erhebliche Sicherheitslücke | | Switchport neu konfigurieren | mehrere Systeme können betroffen sein | | VLAN ändern | Endgerät verliert möglicherweise jede Erreichbarkeit | | Router oder Firewall neu starten | großflächiger Ausfall | | VPN neu installieren | Konfiguration und Protokolle können verloren gehen | | Zertifikatsprüfung abschalten | Sicherheitsmechanismus wird umgangen | | MTU blind reduzieren | Symptom wird möglicherweise nur verdeckt | | Paketfilterregeln löschen | Sicherheits- und Betriebsrisiko | Vor einer Änderung sollten der Ausgangszustand, die Hypothese, die erwartete Wirkung und der Rückweg dokumentiert werden.
15. Wie wird eine Netzwerkhypothese korrekt formuliert? **Ungeeignete Vermutung** ```text „Bestimmt ist die Firewall schuld.“ ``` **Prüfbare Hypothese** ```text Der Client erreicht das Zielsystem auf ICMP-Ebene, aber der TCP-Verbindungsaufbau zu Port 443 erhält keine Antwort. Andere Clients im selben VLAN können den Port erreichen. Deshalb wird eine clientbezogene Filterung oder ein Rückwegproblem vermutet. ``` **Dazugehörige Prüfungen** 1. Quell-IP des betroffenen Clients bestätigen. 2. TCP-Porttest mit Zeitstempel durchführen. 3. Host-Firewall und Sicherheitssoftware prüfen. 4. Firewall-Logs nach Quell- und Zieladresse durchsuchen. 5. Paketmitschnitt am Client und gegebenenfalls am Ziel vergleichen. 6. Funktionierenden Referenzclient gegenüberstellen. Eine Hypothese muss durch Beobachtungen begründet und durch einen konkreten Test widerlegbar sein.
16. Welche Mindestinformationen gehören in ein Netzwerkticket? ```text Ticketnummer: Meldende Person: Betroffener Benutzer: Betroffenes Endgerät: Standort: Verbindungsart: LAN / WLAN / VPN / Mobilfunk Fehlerbeginn: Zeitzone: Letzter funktionierender Zeitpunkt: Fehler reproduzierbar: Ja / Nein Exakte Fehlermeldung: Quellhostname: Quell-IP: Quell-MAC: Quell-VLAN: Quellgateway: Verwendete DNS-Server: Zielhostname: Ziel-IP: Zielport: Transportprotokoll: Anwendungsprotokoll: Betroffene Benutzer oder Geräte: Funktionierende Vergleichssysteme: Weiterhin funktionierende Verbindungen: Kürzliche Änderungen: Erwarteter Kommunikationsweg: 1. 2. 3. 4. Bisherige Prüfungen: - - - Bisherige Änderungen: - - - Arbeitshypothese: Nächster Prüfschritt: Rückweg bei Änderung: ```
17. Wann muss eine Netzwerkstörung eskaliert werden? Eine Eskalation ist sinnvoll oder erforderlich, wenn: - mehrere Benutzer oder Standorte betroffen sind, - ein geschäftskritischer Dienst ausgefallen ist, - ein Sicherheitsvorfall vermutet wird, - unautorisierte Netzwerkänderungen erkennbar sind, - Administratorrechte oder Zuständigkeiten fehlen, - eine Änderung an produktiver Kerninfrastruktur erforderlich wird, - Provider- oder Herstellerunterstützung benötigt wird, - redundante Systeme ebenfalls ausfallen, - die vereinbarte Bearbeitungszeit überschritten wird, - Paketmitschnitte sensible Daten enthalten, - Datenverlust oder Manipulation möglich ist. **Eine gute Eskalation enthält:** - klare Fehlerbeschreibung, - Auswirkung und Priorität, - betroffene Systeme, - Beginn und Zeitzone, - erwarteten Kommunikationsweg, - bereits durchgeführte Prüfungen, - Messergebnisse und Logauszüge, - ausgeschlossene Ursachen, - aktuelle Hypothese, - konkrete Frage an die nächste Stelle, - sichere Kontakt- und Übergabemöglichkeit.
18. Merkschema für die erste Eingrenzung ```text 1. Wer ist betroffen? 2. Was genau funktioniert nicht? 3. Was funktioniert weiterhin? 4. Seit wann besteht der Fehler? 5. Was wurde vorher geändert? 6. Welcher Kommunikationsweg wird erwartet? 7. Besteht ein Link? 8. Ist die IP-Konfiguration gültig? 9. Ist das Gateway erreichbar? 10. Existiert eine Route? 11. Funktioniert die Namensauflösung? 12. Ist der Zielport erreichbar? 13. Antwortet die Anwendung? 14. Wo befindet sich der erste belegte Fehler? 15. Welche Messung bestätigt die Ursache? ``` **Kurzform** ```text Umfang → Link → IP → Gateway → Route → DNS → Port → Anwendung ```
19. Offizielle Quellen und weiterführende Dokumentation **Microsoft** - [Grundlagen von TCP/IP](https://learn.microsoft.com/troubleshoot/windows-client/networking/tcpip-addressing-and-subnetting) - [Get-NetAdapter](https://learn.microsoft.com/powershell/module/netadapter/get-netadapter) - [Get-NetIPConfiguration](https://learn.microsoft.com/powershell/module/nettcpip/get-netipconfiguration) - [Get-NetRoute](https://learn.microsoft.com/powershell/module/nettcpip/get-netroute) - [Get-NetNeighbor](https://learn.microsoft.com/powershell/module/nettcpip/get-netneighbor) - [Test-NetConnection](https://learn.microsoft.com/powershell/module/nettcpip/test-netconnection) - [Resolve-DnsName](https://learn.microsoft.com/powershell/module/dnsclient/resolve-dnsname) **Linux** - [ip-address – Linux Manual Page](https://man7.org/linux/man-pages/man8/ip-address.8.html) - [ip-link – Linux Manual Page](https://man7.org/linux/man-pages/man8/ip-link.8.html) - [ip-route – Linux Manual Page](https://man7.org/linux/man-pages/man8/ip-route.8.html) - [ip-neighbour – Linux Manual Page](https://man7.org/linux/man-pages/man8/ip-neighbour.8.html) - [ss – Linux Manual Page](https://man7.org/linux/man-pages/man8/ss.8.html) **Apple** - Lokale Befehlsreferenzen: `man ifconfig`, `man route`, `man netstat`, `man arp`, `man ping` und `man traceroute` - [Apple Platform Deployment – Network Services](https://support.apple.com/guide/deployment/network-services-dep2d2d2d2d2/web) **Wireshark und tcpdump** - [Wireshark User’s Guide](https://www.wireshark.org/docs/wsug_html/) - [Wireshark Display Filter Reference](https://www.wireshark.org/docs/dfref/) - [tcpdump Manual Page](https://www.tcpdump.org/manpages/tcpdump.1.html) - [pcap-filter Manual Page](https://www.tcpdump.org/manpages/pcap-filter.7.html) > Die genaue Befehlssyntax und die verfügbaren Optionen können von Betriebssystem- und Werkzeugversion abhängen. Vor Änderungen an produktiven Systemen muss zusätzlich die lokale Dokumentation geprüft werden.
# 3.1 Störungsumfang und Kommunikationsweg bestimmen* Bevor einzelne Netzwerkprotokolle, Firewallregeln oder Server untersucht werden, muss der Umfang der Störung bestimmt werden. Dadurch lässt sich erkennen, ob die Ursache wahrscheinlich auf einem Endgerät, in einem Netzsegment, an einer zentralen Komponente oder am Zielsystem liegt. Danach wird der erwartete Kommunikationsweg vom betroffenen Client bis zum Ziel dokumentiert. > **Grundregel:** Erst bestimmen, wer betroffen ist und welchen Weg die Kommunikation nehmen soll. Danach Messungen an den beteiligten Komponenten durchführen. ---
1. Welche Informationen müssen zuerst aufgenommen werden? | Information | Beispiel | |---|---| | Betroffener Benutzer | Max Mustermann | | Betroffenes Gerät | `CLIENT-023` | | Standort | Berlin | | Verbindungsart | LAN | | Fehlerbeginn | `2026-07-31 09:42 CEST` | | Letzter funktionierender Zeitpunkt | `2026-07-31 09:35 CEST` | | Zielanwendung | interne Webanwendung | | Zielname | `app.example.intern` | | Ziel-IP-Adresse | `192.0.2.20` | | Zielport | TCP 443 | | Exakte Fehlermeldung | Verbindung wegen Zeitüberschreitung fehlgeschlagen | | Reproduzierbarkeit | bei jedem Aufruf | | Betroffene Benutzer | nur ein Benutzer bekannt | | Kürzliche Änderung | VPN-Client wurde aktualisiert | **Ungeeignete Fehlerbeschreibung** ```text „Das Internet funktioniert nicht.“ ``` **Geeignete Fehlerbeschreibung** ```text CLIENT-023 kann seit 09:42 Uhr die interne Anwendung https://app.example.intern nicht öffnen. Der Browser meldet nach ungefähr 30 Sekunden eine Zeitüberschreitung. Andere Internetseiten sind erreichbar. CLIENT-024 kann die interne Anwendung weiterhin öffnen. ``` Diese Beschreibung grenzt den Fehler bereits auf einen Client beziehungsweise dessen Kommunikationsweg ein.
2. Welche Fragen sollten der meldenden Person gestellt werden? 1. Was wollten Sie genau durchführen? 2. Welche Anwendung oder Adresse haben Sie verwendet? 3. Welche Fehlermeldung wird vollständig angezeigt? 4. Seit wann tritt der Fehler auf? 5. Hat die Funktion vorher auf demselben Gerät funktioniert? 6. Tritt der Fehler bei jedem Versuch auf? 7. Sind weitere Benutzer betroffen? 8. Funktionieren andere interne Anwendungen? 9. Funktionieren externe Internetseiten? 10. Besteht die Verbindung über LAN, WLAN oder VPN? 11. Wurde der Arbeitsplatz oder Standort gewechselt? 12. Wurde kurz vorher etwas aktualisiert oder verändert? 13. Funktioniert der Zugriff von einem anderen Gerät? 14. Funktioniert der Zugriff mit einem anderen Benutzerkonto? 15. Welche Auswirkung hat die Störung auf die Arbeit? **Wichtig** Die Fragen sollten möglichst konkrete und überprüfbare Antworten erzeugen. ```text Ungenau: „Ist das Netzwerk langsam?“ Besser: „Wie lange dauert der Aufruf normalerweise und wie lange dauert er jetzt?“ ```
3. Wie wird der Störungsumfang bestimmt? | Prüffrage | Wenn ja | Wenn nein | |---|---|---| | Ist nur ein Benutzer betroffen? | Benutzerkonto, Profil und Berechtigungen prüfen | Umfang auf Geräte oder Gruppen erweitern | | Ist nur ein Endgerät betroffen? | lokale Konfiguration, Adapter und Host-Firewall prüfen | gemeinsame Infrastruktur untersuchen | | Ist nur ein Switchport betroffen? | Kabel, Port, VLAN und Port-Security prüfen | Switch oder VLAN weiter untersuchen | | Ist nur ein VLAN betroffen? | Gateway, DHCP, ACL und VLAN-Konfiguration prüfen | übergeordnete Komponenten untersuchen | | Ist nur ein Standort betroffen? | Standortverbindung, Firewall und lokales DNS prüfen | zentrale oder externe Ursache möglich | | Ist nur ein Zielsystem betroffen? | Zielserver, Dienst, Port und Firewall prüfen | gemeinsamer Netzwerkpfad möglich | | Ist nur ein bestimmter Port betroffen? | Dienst, Firewall und Transportprotokoll prüfen | grundlegende Erreichbarkeit untersuchen | | Sind alle externen Ziele betroffen? | Internetzugang, NAT, Proxy oder Provider prüfen | zielbezogene Störung möglich | | Sind alle internen Ziele betroffen? | lokales Gateway, Routing oder zentrale Firewall prüfen | einzelner Dienst oder Pfad betroffen | | Sind alle Systeme betroffen? | zentrale Infrastruktur oder großflächige Störung prüfen | Fehler weiter eingrenzen | **Mögliche Umfangsebenen** ```text Benutzer → Gerät → Switchport → Access Switch → VLAN → Standort → Unternehmensnetz → Dienst → externer Anbieter ``` Je höher die gemeinsame betroffene Ebene liegt, desto wahrscheinlicher ist eine gemeinsame technische Ursache.
4. Welche Vergleichstests sind besonders aussagekräftig? | Test | Gleichbleibender Faktor | Veränderter Faktor | Mögliche Aussage | |---|---|---|---| | anderer Benutzer am selben Client | Gerät und Netzwerkpfad | Benutzerkonto | Benutzer- oder Berechtigungsproblem | | gleicher Benutzer an anderem Client | Benutzer und Ziel | Endgerät | gerätebezogenes Problem | | anderer Client am selben Anschluss | Switchport und Pfad | Endgerät | Endgerät oder Kabel eingrenzen | | gleicher Client an anderem Anschluss | Client | Port und möglicherweise VLAN | Switchport oder Verkabelung | | LAN statt WLAN | Client und Ziel | Zugangsnetz | WLAN-spezifisches Problem | | WLAN statt LAN | Client und Ziel | Zugangsnetz | LAN-Port, Kabel oder VLAN | | IP-Adresse statt DNS-Name | Client und Zielsystem | Namensauflösung | DNS-Problem möglich | | anderes Ziel im selben Netz | Client und lokaler Pfad | Zielsystem | zielbezogene Störung | | gleiches Ziel über anderen Port | Client und Ziel | Dienst beziehungsweise Port | port- oder dienstbezogen | | ohne VPN statt mit VPN | Client und Ziel | Tunnel, Routen und VPN-DNS | VPN-spezifisches Problem | > Bei einem Vergleichstest sollte möglichst nur ein relevanter Faktor verändert werden. Werden gleichzeitig Benutzer, Gerät, Netzwerk und Standort gewechselt, ist das Ergebnis kaum eindeutig zuzuordnen.
5. Wie wird bestimmt, was weiterhin funktioniert? Die funktionierenden Bereiche sind für die Eingrenzung genauso wichtig wie der eigentliche Fehler. **Beispiel** ```text Funktioniert: - Anmeldung am Client - Zugriff auf andere interne Webanwendungen - Zugriff auf externe Internetseiten - DNS-Auflösung des betroffenen Zielnamens - Ping zum Standardgateway Funktioniert nicht: - TCP-Verbindung zu app.example.intern auf Port 443 ``` Daraus kann zunächst abgeleitet werden: - der Client ist grundsätzlich betriebsbereit, - die Netzwerkschnittstelle funktioniert zumindest teilweise, - eine gültige IP-Kommunikation ist vorhanden, - DNS funktioniert für den geprüften Namen, - der Fehler betrifft möglicherweise den Zielport, den Dienst oder den spezifischen Kommunikationspfad. **Negativtest und Positivtest** | Testart | Beispiel | |---|---| | Negativtest | betroffene Anwendung funktioniert nicht | | Positivtest | andere Anwendung im selben Zielnetz funktioniert | | Referenztest | anderer Client erreicht dieselbe Anwendung | Eine belastbare Eingrenzung verwendet möglichst alle drei Testarten.
6. Wie wird das Quellsystem eindeutig identifiziert? Die Bezeichnung „mein Computer“ reicht für eine technische Analyse nicht aus. Zu erfassen sind: - Hostname, - Betriebssystem, - Benutzerkonto, - Netzwerkschnittstelle, - IP-Adresse und Präfix, - MAC-Adresse, - Standardgateway, - DNS-Server, - Verbindungsart, - gegebenenfalls VLAN, VPN oder Proxy. **Windows** ```powershell [RO] hostname ``` ```powershell [RO] Get-ComputerInfo | Select-Object CsName, WindowsProductName, WindowsVersion, OsBuildNumber ``` ```powershell [RO] Get-NetIPConfiguration ``` ```powershell [RO] Get-NetAdapter | Select-Object Name, InterfaceDescription, Status, LinkSpeed, MacAddress, ifIndex ``` **Linux** ```bash [RO] hostnamectl ``` ```bash [RO] ip -brief address ``` ```bash [RO] ip route ``` ```bash [RO] ip -brief link ``` **macOS** ```bash [RO] scutil --get ComputerName ``` ```bash [RO] sw_vers ``` ```bash [RO] ifconfig ``` ```bash [RO] netstat -rn ``` ```bash [RO] networksetup -listallhardwareports ``` Die erfasste IP-Adresse muss der tatsächlich für die Zielverbindung verwendeten Schnittstelle zugeordnet werden. Ein System kann gleichzeitig LAN, WLAN, VPN, virtuelle Adapter und Containerinterfaces besitzen.
7. Wie wird das Zielsystem eindeutig bestimmt? Ein Dienstname oder eine URL muss in seine technischen Bestandteile zerlegt werden. **Beispiel-URL** ```text https://app.example.intern:8443/login ``` | Bestandteil | Wert | |---|---| | Schema beziehungsweise Protokoll | HTTPS | | Hostname | `app.example.intern` | | expliziter Port | TCP 8443 | | Pfad | `/login` | | erwartetes Zielsystem | Reverse Proxy oder Webserver | | möglicher Backenddienst | Anwendungsserver | | mögliche weitere Abhängigkeit | Datenbank oder Identitätsanbieter | Zu erfassen sind: - vollständige URL oder Freigabe, - Hostname, - aufgelöste IP-Adresse beziehungsweise Adressen, - Transportprotokoll, - Port, - erwarteter Server oder Load Balancer, - Anwendungspfad, - möglicherweise verwendeter Proxy, - mögliche Backendabhängigkeiten. **Windows** ```powershell [RO] Resolve-DnsName app.example.intern ``` ```powershell [TEST] Test-NetConnection app.example.intern -Port 443 ``` **Linux** ```bash [RO] getent ahosts app.example.intern ``` ```bash [TEST] nc -vz app.example.intern 443 ``` **macOS** ```bash [RO] dscacheutil -q host -a name app.example.intern ``` ```bash [TEST] nc -vz app.example.intern 443 ``` Ein Hostname kann mehrere IPv4- und IPv6-Adressen zurückgeben. Es muss dokumentiert werden, welche Adresse der Client beim fehlerhaften Versuch tatsächlich verwendet.
8. Wie wird der erwartete Kommunikationsweg gezeichnet? **Direkter Zugriff im lokalen Netz** ```text CLIENT-023 192.0.2.10/24 │ ├─ Access Switch SW-01 │ VLAN 20 │ └─ SERVER-01 192.0.2.20/24 TCP 443 ``` Da Quelle und Ziel im selben IPv4-Subnetz liegen, ist normalerweise kein Router für die direkte Kommunikation erforderlich. **Zugriff in ein anderes internes Netz** ```text CLIENT-023 192.0.2.10/24 │ ├─ Access Switch SW-01 │ VLAN 20 │ ├─ Standardgateway │ 192.0.2.1 │ ├─ Core Router oder Firewall │ ├─ Server-VLAN 40 │ └─ APP-01 198.51.100.20/24 TCP 443 ``` **Zugriff über Reverse Proxy** ```text Browser → DNS-Auflösung → Reverse Proxy TCP 443 → TLS-Verarbeitung → Backend TCP 8080 → Anwendung → Datenbank ``` **Zugriff über VPN** ```text Client → lokales Gateway → Internet → VPN-Gateway → verschlüsselter Tunnel → interne Route → interne Firewall → Zielserver ``` Zu jeder Verbindung sollte bekannt sein: - welche Komponente als Nächstes angesprochen wird, - welche Adresse sie besitzt, - welches Protokoll und welcher Port verwendet werden, - ob Adressen übersetzt werden, - ob Daten verschlüsselt oder getunnelt werden, - welche Komponente den Rückweg bestimmt.
9. Wie wird geprüft, welchen Weg das Betriebssystem verwenden möchte? **Windows – Route zu einem Ziel untersuchen** ```powershell [RO] Find-NetRoute -RemoteIPAddress 198.51.100.20 ``` Routingtabelle anzeigen: ```powershell [RO] Get-NetRoute -AddressFamily IPv4 | Sort-Object DestinationPrefix, RouteMetric | Format-Table ifIndex, DestinationPrefix, NextHop, RouteMetric, InterfaceMetric ``` Pfad verfolgen: ```cmd [TEST] tracert -d 198.51.100.20 ``` **Linux – ausgewählte Route anzeigen** ```bash [RO] ip route get 198.51.100.20 ``` Beispielausgabe: ```text 198.51.100.20 via 192.0.2.1 dev eth0 src 192.0.2.10 ``` | Feld | Bedeutung | |---|---| | `via 192.0.2.1` | nächster Router | | `dev eth0` | verwendete Schnittstelle | | `src 192.0.2.10` | ausgewählte Quelladresse | Pfad verfolgen: ```bash [TEST] traceroute -n 198.51.100.20 ``` **macOS – ausgewählte Route anzeigen** ```bash [RO] route -n get 198.51.100.20 ``` Pfad verfolgen: ```bash [TEST] traceroute -n 198.51.100.20 ``` > Traceroute zeigt nur antwortende Zwischenstationen. Firewalls und Router können die verwendeten Diagnosepakete verwerfen oder nicht beantworten. Ein Sternchen beweist daher nicht, dass genau dieser Hop den eigentlichen Anwendungsverkehr blockiert.
10. Wie wird bei mehreren Netzwerkschnittstellen die verwendete Schnittstelle bestimmt? Ein Client kann gleichzeitig besitzen: - Ethernet, - WLAN, - VPN, - Mobilfunk, - virtuelle Hypervisoradapter, - Containerbridges, - Loopback, - Tunnelinterfaces. Das Betriebssystem wählt den Weg anhand der Routingtabelle, der Präfixlänge und der Metrik. **Windows** Ausgewählte Route: ```powershell [RO] Find-NetRoute -RemoteIPAddress 198.51.100.20 ``` Schnittstellenmetriken: ```powershell [RO] Get-NetIPInterface | Sort-Object AddressFamily, InterfaceMetric | Select-Object ifIndex, InterfaceAlias, AddressFamily, ConnectionState, InterfaceMetric ``` **Linux** ```bash [RO] ip route get 198.51.100.20 ``` Richtlinienregeln anzeigen: ```bash [RO] ip rule show ``` Alle wichtigen Routingtabellen anzeigen: ```bash [RO] ip route show table all ``` **macOS** ```bash [RO] route -n get 198.51.100.20 ``` Netzwerkdienstreihenfolge grafisch prüfen: ```text Systemeinstellungen → Netzwerk → Aktionsmenü → Reihenfolge der Dienste festlegen ``` Die sichtbare Dienstreihenfolge allein ersetzt nicht die Prüfung der tatsächlich ausgewählten Route.
11. Wie werden lokale und entfernte Ziele unterschieden? Das Endgerät entscheidet anhand von IP-Adresse und Präfix beziehungsweise Subnetzmaske, ob das Ziel lokal erreichbar sein sollte. **Lokales Ziel** ```text Quelle: 192.0.2.10/24 Ziel: 192.0.2.20 ``` Beide Adressen gehören zum Netz: ```text 192.0.2.0/24 ``` Der Client versucht normalerweise, die MAC-Adresse des Zielsystems direkt zu ermitteln. **Entferntes Ziel** ```text Quelle: 192.0.2.10/24 Ziel: 198.51.100.20 ``` Das Ziel liegt außerhalb des lokalen Netzes. Der Client sendet das Paket normalerweise an einen Router beziehungsweise das passende Next Hop. **Bedeutung für die Fehleranalyse** | Zieltyp | Erste technische Untersuchung | |---|---| | lokal | VLAN, ARP beziehungsweise Neighbor Discovery, Switchport | | entfernt | Standardgateway, Route, Firewall und Rückweg | | unklar | lokale IP-Konfiguration und Präfix zuerst prüfen | Eine falsche Subnetzmaske kann dazu führen, dass ein Client ein entferntes Ziel fälschlich für lokal hält oder ein lokales Ziel unnötig an das Gateway sendet.
12. Wie wird bestimmt, ob IPv4 oder IPv6 verwendet wird? Ein Hostname kann IPv4- und IPv6-Adressen besitzen. **Windows** ```powershell [RO] Resolve-DnsName app.example.intern -Type A ``` ```powershell [RO] Resolve-DnsName app.example.intern -Type AAAA ``` Bestehende TCP-Verbindung prüfen: ```powershell [RO] Get-NetTCPConnection | Where-Object RemotePort -eq 443 | Select-Object LocalAddress, LocalPort, RemoteAddress, RemotePort, State, OwningProcess ``` **Linux** ```bash [RO] getent ahosts app.example.intern ``` IPv4 gezielt testen: ```bash [TEST] curl -4 -I https://app.example.intern/ ``` IPv6 gezielt testen: ```bash [TEST] curl -6 -I https://app.example.intern/ ``` **macOS** ```bash [RO] dscacheutil -q host -a name app.example.intern ``` ```bash [TEST] curl -4 -I https://app.example.intern/ ``` ```bash [TEST] curl -6 -I https://app.example.intern/ ``` Wenn IPv4 funktioniert und IPv6 nicht, bedeutet das nicht automatisch, dass IPv6 deaktiviert werden sollte. Stattdessen müssen IPv6-Adresse, Präfix, Router, DNS, Firewall und Rückweg untersucht werden.
13. Wie wird ein Dienst hinter Load Balancer oder Reverse Proxy berücksichtigt? Der im DNS eingetragene Endpunkt ist möglicherweise nicht der eigentliche Anwendungsserver. ```text Client → DNS → virtuelle IP-Adresse → Load Balancer oder Reverse Proxy → Backend 1 → Backend 2 → Backend 3 ``` Zu dokumentieren sind: - DNS-Name, - aufgelöste virtuelle IP-Adresse, - Load-Balancer- beziehungsweise Proxyname, - Frontend-Port, - Backendpool, - Backendadressen, - Backendports, - Health-Check, - TLS-Terminierung, - verwendete Host-Header, - Sitzungsbindung, - mögliche Quelladressübersetzung. **Mögliche Fehlerbilder** | Beobachtung | Untersuchungsrichtung | |---|---| | jeder zweite Aufruf schlägt fehl | einzelnes Backend möglicherweise fehlerhaft | | direkter Backendzugriff funktioniert | Proxy- oder Frontendkonfiguration prüfen | | Proxy antwortet mit 502 | Backendverbindung oder Antwort ungültig | | Proxy antwortet mit 504 | Backend antwortet nicht rechtzeitig | | Zertifikat passt nicht | SNI, Hostname oder TLS-Terminierung prüfen | | nur ein Benutzer betroffen | Sitzung, Cookie oder bestimmtes Backend prüfen | | DNS liefert mehrere Adressen | jede Zieladresse getrennt testen | Ein erfolgreicher Test gegen ein einzelnes Backend beweist nicht, dass der vollständige produktive Weg über den Load Balancer funktioniert.
14. Wie wird ein Proxy im Kommunikationsweg erkannt? **Windows – WinHTTP-Proxy** ```cmd [RO] netsh winhttp show proxy ``` Benutzerbezogene Windows-Proxyeinstellungen: ```powershell [RO] Get-ItemProperty ` 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings' | Select-Object ProxyEnable, ProxyServer, AutoConfigURL ``` **Linux** ```bash [RO][SENS] env | grep -iE '^(http|https|all|no)_proxy=' ``` **macOS** ```bash [RO] scutil --proxy ``` Proxykonfiguration eines bestimmten Netzwerkdienstes: ```bash [RO] networksetup -getwebproxy "Wi-Fi" ``` ```bash [RO] networksetup -getsecurewebproxy "Wi-Fi" ``` **Zu beachten** - Anwendungen können eigene Proxyeinstellungen verwenden. - Umgebungsvariablen können benutzer- oder prozessbezogen sein. - PAC-Dateien können das Ziel dynamisch unterschiedlichen Proxys zuordnen. - WinHTTP- und Benutzer-Proxyeinstellungen können voneinander abweichen. - Ein Browser kann Richtlinien oder eigene Mechanismen verwenden. - `NO_PROXY` beziehungsweise Bypasslisten beeinflussen den tatsächlichen Weg. Ein Proxy muss daher als eigene Komponente in den Kommunikationsweg aufgenommen werden.
15. Wie wird eine Störungsmatrix erstellt? Eine Störungsmatrix macht Muster sichtbar. | Test | CLIENT-023 | CLIENT-024 | CLIENT-025 | |---|---:|---:|---:| | Gateway erreichbar | Ja | Ja | Ja | | DNS-Auflösung | Ja | Ja | Ja | | Ziel-IP erreichbar | Ja | Ja | Ja | | TCP 443 erreichbar | Nein | Ja | Ja | | Anwendung funktioniert | Nein | Ja | Ja | | Internetzugriff | Ja | Ja | Ja | | VLAN | 20 | 20 | 30 | | Betriebssystem | Windows | Windows | Linux | **Erste Einordnung** Da nur `CLIENT-023` betroffen ist und andere Clients denselben Zielport erreichen, sind folgende Bereiche wahrscheinlicher: - lokale Host-Firewall, - Sicherheitssoftware, - falsche lokale Route, - VPN- oder Proxykonfiguration, - clientbezogene Netzwerkzugriffsregel, - fehlerhafte Quelladresszuordnung. Eine allgemeine Störung des Zielservers ist anhand dieser Matrix weniger wahrscheinlich, aber noch nicht vollständig ausgeschlossen.
16. Wie wird eine Zeitlinie der Störung erstellt? | Zeitpunkt | Ereignis | |---|---| | 09:30 | VPN-Client-Update abgeschlossen | | 09:35 | letzter erfolgreicher Anwendungszugriff | | 09:40 | Client wurde neu gestartet | | 09:42 | erster fehlgeschlagener Zugriff | | 09:45 | Fehler im Ticket gemeldet | | 09:50 | anderer Client erfolgreich getestet | | 09:55 | DNS-Auflösung erfolgreich geprüft | | 10:00 | TCP-Porttest schlägt fehl | **Auswertung** Die zeitliche Nähe zwischen VPN-Update und Störung erzeugt eine prüfbare Hypothese. Sie beweist jedoch noch nicht, dass das Update die Ursache ist. Zu prüfen wären beispielsweise: - neue virtuelle Schnittstelle, - geänderte Routingtabelle, - geänderte DNS-Server, - aktivierter Always-on-Tunnel, - neue lokale Filterregeln, - veränderte Proxykonfiguration.
17. Welche typischen Fehlschlüsse müssen vermieden werden? | Beobachtung | Unzulässiger Schluss | Richtige Einordnung | |---|---|---| | ein Benutzer meldet den Fehler | nur ein Benutzer ist betroffen | Umfang aktiv prüfen | | Ping funktioniert | Anwendung funktioniert | nur ICMP-Erreichbarkeit bestätigt | | Ping funktioniert nicht | Host ist offline | ICMP kann blockiert sein | | DNS liefert eine Adresse | DNS ist vollständig korrekt | Adresse und verwendete Antwort prüfen | | Port 443 ist erreichbar | Webanwendung ist fehlerfrei | nur TCP-Verbindungsaufbau bestätigt | | Traceroute zeigt Sterne | dort liegt der Fehler | Hop antwortet möglicherweise nur nicht | | anderer Client funktioniert | Zielserver ist fehlerfrei | clientspezifischer oder intermittierender Fehler möglich | | direkter Backendtest funktioniert | gesamter Dienstpfad funktioniert | Proxy, Load Balancer und DNS fehlen im Test | | Fehler trat nach Update auf | Update ist die Ursache | zeitlicher Zusammenhang ist nur ein Hinweis | | nur WLAN betroffen | Access Point ist defekt | Funk, Authentifizierung, VLAN und Client prüfen | | hohe Latenz an einem Hop | dieser Router verursacht Verzögerung | Antwortpriorisierung kann abweichen |
18. Welche Informationen werden an die nächste Diagnosephase übergeben? Nach der ersten Eingrenzung sollten folgende Ergebnisse vorliegen: ```text Störungsumfang: Nur CLIENT-023 betroffen. Quelle: CLIENT-023 192.0.2.10/24 LAN VLAN 20 Ziel: app.example.intern 198.51.100.20 TCP 443 Erwarteter Weg: CLIENT-023 → SW-01 → Gateway 192.0.2.1 → FW-01 → Reverse Proxy → APP-01 Funktioniert: - Link vorhanden - gültige IP-Adresse - Gateway erreichbar - DNS-Auflösung erfolgreich - andere interne und externe Ziele erreichbar Funktioniert nicht: - TCP-Verbindung zum Zielport 443 Vergleich: CLIENT-024 im selben VLAN erreicht das Ziel. Änderung: VPN-Client wurde kurz vorher aktualisiert. Arbeitshypothese: Lokale Route, VPN-Filter oder Host-Firewall auf CLIENT-023. Nächste Diagnosephase: Physische Schnittstelle, IP-Konfiguration und ausgewählte Route des Clients vollständig prüfen. ``` Damit beginnt die nächste Seite: ```text 3.2 Physische Verbindung und Netzwerkschnittstelle prüfen ```
19. Dokumentationsvorlage ```text Ticketnummer: Bearbeitungsbeginn: Bearbeitende Person: Priorität: Fehlerbeschreibung: Exakte Fehlermeldung: Fehlerbeginn: Letzter funktionierender Zeitpunkt: Zeitzone: Reproduzierbar: Ja / Nein BETROFFENER UMFANG Benutzer: Endgeräte: Switchports: VLANs: Standorte: Dienste: Zielsysteme: Nicht betroffen: QUELLE Hostname: Betriebssystem: Benutzer: Verbindungsart: Schnittstelle: MAC-Adresse: IPv4-Adresse und Präfix: IPv6-Adresse und Präfix: Standardgateway: DNS-Server: VLAN: VPN: Proxy: ZIEL Dienstname: URL oder Freigabe: Hostname: IPv4-Adresse: IPv6-Adresse: Transportprotokoll: Port: Anwendungsprotokoll: Load Balancer: Reverse Proxy: Backend: Weitere Abhängigkeiten: ERWARTETER KOMMUNIKATIONSWEG 1. 2. 3. 4. 5. 6. VERGLEICHSTESTS Gleicher Client, anderes Ziel: Anderer Client, gleiches Ziel: IP-Adresse statt Name: LAN statt WLAN: Ohne VPN: Anderer Benutzer: Referenzsystem: FUNKTIONIERT WEITERHIN - - - FUNKTIONIERT NICHT - - - ZEITLINIE Zeitpunkt: Ereignis: Zeitpunkt: Ereignis: Kürzliche Änderungen: Arbeitshypothese: Begründung: Nächster Prüfschritt: Eskalation erforderlich: Ja / Nein ```
20. Offizielle Quellen und weiterführende Dokumentation **Microsoft** - [Get-NetIPConfiguration](https://learn.microsoft.com/powershell/module/nettcpip/get-netipconfiguration) - [Get-NetAdapter](https://learn.microsoft.com/powershell/module/netadapter/get-netadapter) - [Get-NetRoute](https://learn.microsoft.com/powershell/module/nettcpip/get-netroute) - [Find-NetRoute](https://learn.microsoft.com/powershell/module/nettcpip/find-netroute) - [Get-NetIPInterface](https://learn.microsoft.com/powershell/module/nettcpip/get-netipinterface) - [Get-NetTCPConnection](https://learn.microsoft.com/powershell/module/nettcpip/get-nettcpconnection) - [Resolve-DnsName](https://learn.microsoft.com/powershell/module/dnsclient/resolve-dnsname) - [Test-NetConnection](https://learn.microsoft.com/powershell/module/nettcpip/test-netconnection) - [netsh winhttp](https://learn.microsoft.com/windows-server/administration/windows-commands/netsh-winhttp) **Linux** - [ip-address – Linux Manual Page](https://man7.org/linux/man-pages/man8/ip-address.8.html) - [ip-link – Linux Manual Page](https://man7.org/linux/man-pages/man8/ip-link.8.html) - [ip-route – Linux Manual Page](https://man7.org/linux/man-pages/man8/ip-route.8.html) - [ip-rule – Linux Manual Page](https://man7.org/linux/man-pages/man8/ip-rule.8.html) - [getent – Linux Manual Page](https://man7.org/linux/man-pages/man1/getent.1.html) **Apple** - Lokale Befehlsreferenzen: `man ifconfig`, `man route`, `man netstat`, `man scutil` und `man networksetup` - [Apple Platform Deployment – Network Services](https://support.apple.com/guide/deployment/network-services-dep2d2d2d2d2/web) > Der erwartete Kommunikationsweg muss anhand der tatsächlich eingesetzten Netzwerkarchitektur dokumentiert werden. Beispieladressen und Komponentennamen dürfen nicht ungeprüft auf eine produktive Umgebung übertragen werden.
# 3.2 Physische Verbindung und Netzwerkschnittstelle prüfen Auf der untersten Netzwerkebene wird geprüft, ob zwischen Endgerät und nächster Netzwerkkomponente eine technisch funktionsfähige Verbindung besteht. Dazu gehören Kabel, Stecker, Transceiver, Switchport, WLAN-Signal, Netzwerkkarte, Treiber, Linkstatus, Geschwindigkeit, Duplexmodus und Fehlerzähler. > **Grundregel:** Ein angezeigter Link beweist nur, dass die beteiligten Schnittstellen eine physische beziehungsweise logische Verbindung erkannt haben. Er beweist nicht, dass VLAN, IP-Konfiguration, Routing oder Anwendungen funktionieren. ---
1. Welche Komponenten gehören zur physischen Verbindung? **Kupfer-Ethernet** ```text Endgerät → Netzwerkkarte → RJ45-Stecker → Patchkabel → Netzwerkdose → Gebäudeverkabelung → Patchpanel → Patchkabel → Switchport ``` **Glasfaserverbindung** ```text Gerät → Netzwerkkarte → Transceiver → Glasfaserkabel → Patchfeld → Glasfaserstrecke → Transceiver → Switchport ``` **WLAN-Verbindung** ```text Client → WLAN-Adapter → Funkverbindung → Access Point → Ethernet-Uplink → Switchport ``` Jede Komponente kann vollständig ausfallen oder die Verbindung nur zeitweise beeinträchtigen.
2. Welche Symptome sprechen für einen Fehler auf Layer 1 oder am Netzwerkadapter? - kein Linkstatus, - Adapter wird vom Betriebssystem nicht erkannt, - Verbindung wechselt zwischen aktiv und getrennt, - ausgehandelte Geschwindigkeit ist unerwartet niedrig, - Halbduplex statt Vollduplex, - steigende CRC-, Frame- oder Carrier-Fehler, - steigende Paketverluste direkt an der Schnittstelle, - Verbindung bricht bei Bewegung des Kabels ab, - Switchport meldet häufige Link-Up- und Link-Down-Ereignisse, - Transceiver wird nicht erkannt, - Schnittstelle wird durch Energiesparfunktionen deaktiviert, - Treiber startet wiederholt neu, - nur dieser Switchport oder dieses Kabel ist betroffen, - Datendurchsatz ist deutlich geringer als bei einer Vergleichsverbindung. Einzelne ältere Fehlerzähler beweisen keine aktuelle Störung. Entscheidend ist, ob die Zähler während des Fehlerzeitraums weiter ansteigen.
3. Welche Sichtprüfung sollte zuerst durchgeführt werden? | Prüfung | Fragestellung | |---|---| | Kabel | Ist es geknickt, beschädigt, gequetscht oder ungewöhnlich gespannt? | | Stecker | Sitzt der Stecker vollständig und rastet er ein? | | Netzwerkdose | Ist die richtige und dokumentierte Dose verbunden? | | Patchpanel | Ist die Zuordnung zum Switchport korrekt? | | Switchport | Leuchtet beziehungsweise blinkt die Linkanzeige? | | Netzwerkkarte | Wird ein Link angezeigt? | | Transceiver | Sitzt das Modul vollständig im Steckplatz? | | Glasfaser | Stimmen Fasertyp und Transceivertyp überein? | | Dockingstation | Ist sie mit Strom versorgt und korrekt verbunden? | | USB-Adapter | Wird er vom Betriebssystem erkannt? | | Access Point | Ist der Client tatsächlich mit dem erwarteten AP verbunden? | **Sicherheitsregeln bei Glasfaser** - Niemals direkt in einen Glasfaseranschluss oder Transceiver sehen. - Schutzkappen nicht unnötig entfernen. - Steckerflächen nicht berühren. - Reinigungs- und Prüfverfahren des Herstellers beachten. - Transceiver nicht während einer unklaren produktiven Verbindung entfernen. ```text [CHANGE][DISRUPT] Das Entfernen eines Kabels oder Transceivers unterbricht die Verbindung. ```
4. Was bedeuten Linkstatus, administrativer Status und Betriebsstatus? | Zustand | Bedeutung | |---|---| | administrativ aktiviert | Schnittstelle darf grundsätzlich verwendet werden | | administrativ deaktiviert | Schnittstelle wurde durch Konfiguration abgeschaltet | | Link erkannt | physische beziehungsweise logische Gegenstelle wurde erkannt | | betriebsbereit | Betriebssystem bewertet die Schnittstelle als verwendbar | | verbunden | kann zusätzlich eine höhere logische Verbindung bezeichnen | | getrennt | kein nutzbarer Link oder Dienst | | unbekannt | Treiber oder Betriebssystem liefert keine eindeutige Information | **Linux-Beispiel** ```text ``` | Kennzeichnung | Bedeutung | |---|---| | `UP` | Schnittstelle ist administrativ aktiviert | | `LOWER_UP` | untere Ebene meldet einen aktiven Link | | `RUNNING` | Schnittstelle wird als betriebsbereit gemeldet | Eine Schnittstelle kann administrativ `UP` sein, obwohl kein Kabel angeschlossen und kein physischer Link vorhanden ist.
5. Wie wird der Adapterstatus unter Windows geprüft? **Alle sichtbaren Netzwerkadapter** ```powershell [RO] Get-NetAdapter | Sort-Object Name | Format-Table Name, InterfaceDescription, ifIndex, Status, LinkSpeed, MacAddress ``` **Auch ausgeblendete Adapter anzeigen** ```powershell [RO] Get-NetAdapter -IncludeHidden | Sort-Object Name | Format-Table Name, InterfaceDescription, ifIndex, Status, LinkSpeed, MacAddress ``` **Bestimmten Adapter vollständig anzeigen** ```powershell [RO] Get-NetAdapter -Name 'Ethernet' | Format-List * ``` **Physische Adapter anzeigen** ```powershell [RO] Get-NetAdapter -Physical | Format-Table Name, InterfaceDescription, Status, LinkSpeed, MacAddress ``` **Grafische Adapterübersicht öffnen** ```cmd [RO] ncpa.cpl ``` **Wichtige Felder** | Feld | Bedeutung | |---|---| | `Name` | logischer Windows-Adaptername | | `InterfaceDescription` | Hersteller- oder Treiberbezeichnung | | `ifIndex` | Schnittstellenindex | | `Status` | aktueller Adapterstatus | | `LinkSpeed` | gemeldete Verbindungsgeschwindigkeit | | `MacAddress` | Hardwareadresse des Adapters | Virtuelle Adapter, VPN-Adapter und Hypervisorinterfaces müssen von der tatsächlich verwendeten physischen Schnittstelle unterschieden werden.
6. Wie werden Windows-Adapterstatistiken untersucht? **Grundlegende Statistiken** ```powershell [RO] Get-NetAdapterStatistics ``` **Bestimmten Adapter vollständig anzeigen** ```powershell [RO] Get-NetAdapterStatistics -Name 'Ethernet' | Format-List * ``` **Kompakte Übersicht** ```powershell [RO] Get-NetAdapterStatistics -Name 'Ethernet' | Select-Object Name, ReceivedBytes, ReceivedUnicastPackets, ReceivedDiscardedPackets, ReceivedPacketErrors, SentBytes, SentUnicastPackets, OutboundDiscardedPackets, OutboundPacketErrors ``` **Zähler zu zwei Zeitpunkten vergleichen** ```powershell [RO] $Vorher = Get-NetAdapterStatistics -Name 'Ethernet' Start-Sleep -Seconds 30 $Nachher = Get-NetAdapterStatistics -Name 'Ethernet' [PSCustomObject]@{ ZeitraumSekunden = 30 EmpfangeneBytes = $Nachher.ReceivedBytes - $Vorher.ReceivedBytes GesendeteBytes = $Nachher.SentBytes - $Vorher.SentBytes Empfangsfehler = $Nachher.ReceivedPacketErrors - $Vorher.ReceivedPacketErrors Sendefehler = $Nachher.OutboundPacketErrors - $Vorher.OutboundPacketErrors Empfangsverwerfungen = $Nachher.ReceivedDiscardedPackets - $Vorher.ReceivedDiscardedPackets Sendeverwerfungen = $Nachher.OutboundDiscardedPackets - $Vorher.OutboundDiscardedPackets } ``` `Start-Sleep` verändert keine Netzwerkkonfiguration, verlängert aber die Ausführung der Messung. Die Zähler werden nur gelesen. **Bewertung** | Zähler | Mögliche Bedeutung | |---|---| | `ReceivedPacketErrors` steigt | fehlerhafte empfangene Pakete oder Frames | | `OutboundPacketErrors` steigt | Fehler beim Senden | | `ReceivedDiscardedPackets` steigt | Pakete wurden trotz möglicher Fehlerfreiheit verworfen | | `OutboundDiscardedPackets` steigt | ausgehende Pakete wurden verworfen | | Bytes steigen nicht | möglicherweise keine Aktivität oder falscher Adapter | Die genaue Herkunft einzelner Zähler hängt vom Netzwerktreiber und Adapter ab.
7. Wie werden Windows-Treiber und erweiterte Adaptereigenschaften geprüft? **Treiberinformationen des Adapters** ```powershell [RO] Get-NetAdapter -Name 'Ethernet' | Select-Object Name, InterfaceDescription, DriverInformation, DriverFileName, DriverVersion, DriverDate ``` Falls die Treiberdetails in der Ausgabe des eingesetzten Systems nicht vollständig bereitgestellt werden: ```powershell [RO] Get-CimInstance Win32_PnPSignedDriver | Where-Object DeviceClass -eq 'NET' | Select-Object DeviceName, Manufacturer, DriverProviderName, DriverVersion, DriverDate, IsSigned ``` **Erweiterte Eigenschaften anzeigen** ```powershell [RO] Get-NetAdapterAdvancedProperty -Name 'Ethernet' ``` **Energiespareinstellungen anzeigen** ```powershell [RO] Get-NetAdapterPowerManagement -Name 'Ethernet' ``` **Hardwarestatus über den Geräte-Manager** ```cmd [RO] devmgmt.msc ``` Zu prüfen sind: - Warnsymbol am Gerät, - Gerätestatus, - Treiberversion, - Treiberdatum, - Hersteller, - Energieverwaltung, - Ereignisse des Geräts. Erweiterte Eigenschaften besitzen je nach Hersteller, Treiber und Sprache unterschiedliche Namen. Werte dürfen nicht anhand fremder Beispiele ungeprüft verändert werden. ```text [CHANGE][DISRUPT] Änderungen an Geschwindigkeit, Duplex, Offloading, Puffern oder Energieverwaltung können die Verbindung unterbrechen oder die Leistung verschlechtern. ```
8. Wie wird der Linkstatus unter Linux geprüft? **Kurzübersicht aller Schnittstellen** ```bash [RO] ip -brief link ``` **Bestimmte Schnittstelle** ```bash [RO] ip link show dev eth0 ``` **Linkstatus aus sysfs** ```bash [RO] cat /sys/class/net/eth0/operstate ``` ```bash [RO] cat /sys/class/net/eth0/carrier ``` Typische Ausgabe von `carrier`: | Wert | Bedeutung | |---:|---| | `1` | Link beziehungsweise Carrier erkannt | | `0` | kein Carrier erkannt | Der Zugriff kann abhängig von Treiber, Interfacezustand und Berechtigungen fehlschlagen. **Schnittstellenereignisse live beobachten** ```bash [RO] ip monitor link ``` Beenden mit: ```text Strg+C ``` Damit können Link-Up-, Link-Down- und andere Schnittstellenänderungen während der Fehlerreproduktion beobachtet werden.
9. Wie werden Geschwindigkeit, Duplex und Autonegotiation unter Linux geprüft? Falls `ethtool` installiert ist: ```bash [RO][PRIV] sudo ethtool eth0 ``` Typische relevante Felder: ```text Speed: 1000Mb/s Duplex: Full Auto-negotiation: on Link detected: yes ``` | Feld | Bedeutung | |---|---| | `Supported link modes` | vom Adapter unterstützte Modi | | `Advertised link modes` | der Gegenstelle angebotene Modi | | `Link partner advertised link modes` | von der Gegenstelle angebotene Modi | | `Speed` | ausgehandelte Geschwindigkeit | | `Duplex` | Halb- oder Vollduplex | | `Auto-negotiation` | automatische Aushandlung aktiv oder inaktiv | | `Port` | physischer Medientyp | | `Link detected` | Link erkannt | **Treiber- und Firmwareinformationen** ```bash [RO][PRIV] sudo ethtool -i eth0 ``` **Treiberstatistiken** ```bash [RO][PRIV] sudo ethtool -S eth0 ``` **Pause-Frame-Einstellungen anzeigen** ```bash [RO][PRIV] sudo ethtool -a eth0 ``` **Energy Efficient Ethernet anzeigen** ```bash [RO][PRIV] sudo ethtool --show-eee eth0 ``` Nicht jeder Treiber unterstützt alle Abfragen. Eine Meldung wie `Operation not supported` kann bedeuten, dass Adapter oder Treiber die entsprechende Funktion nicht bereitstellen.
10. Wie werden Linux-Schnittstellenfehler und Verwerfungen geprüft? **Standardstatistiken anzeigen** ```bash [RO] ip -s link show dev eth0 ``` Detailliertere Standardstatistiken: ```bash [RO] ip -s -s link show dev eth0 ``` Beispielstruktur: ```text RX: bytes packets errors dropped missed mcast TX: bytes packets errors dropped carrier collsns ``` **Zähler aus sysfs** ```bash [RO] grep . /sys/class/net/eth0/statistics/* ``` Ausgewählte Zähler: ```bash [RO] for Datei in \ rx_packets rx_bytes rx_errors rx_dropped \ tx_packets tx_bytes tx_errors tx_dropped \ collisions; do printf '%-20s ' "$Datei" cat "/sys/class/net/eth0/statistics/$Datei" done ``` **Zweimal messen** ```bash [RO] ip -s link show dev eth0 ``` Fehler reproduzieren oder einen definierten Zeitraum abwarten: ```bash [RO] ip -s link show dev eth0 ``` Nur wenn sich ein Fehlerzähler im relevanten Zeitraum erhöht, besteht ein zeitlicher Zusammenhang zur aktuellen Störung.
11. Wie werden Link- und Treibermeldungen unter Linux gesucht? **Kernelmeldungen des aktuellen Starts** ```bash [RO][PRIV] sudo journalctl -k -b ``` Nach typischen Netzwerkmeldungen suchen: ```bash [RO][PRIV] sudo journalctl -k -b | grep -Ei 'link.*(up|down)|carrier|duplex|firmware|eth|network|reset|timeout' ``` **Meldungen einer bestimmten Schnittstelle** ```bash [RO][PRIV] sudo journalctl -k -b | grep -F 'eth0' ``` **NetworkManager-Protokoll** ```bash [RO][PRIV] sudo journalctl -b -u NetworkManager ``` **systemd-networkd-Protokoll** ```bash [RO][PRIV] sudo journalctl -b -u systemd-networkd ``` Je nach Distribution und Netzwerkkonfiguration wird nur einer dieser Dienste verwendet. Die tatsächliche Netzwerkverwaltung muss auf dem System bestimmt werden. Typische Hinweise: - `Link is Down`, - `Link is Up`, - `NIC Link is Down`, - Firmware konnte nicht geladen werden, - Adapter wurde zurückgesetzt, - Übertragung ist abgelaufen, - Verbindung wurde neu ausgehandelt.
12. Wie wird der Schnittstellenstatus unter macOS geprüft? **Hardwareports und Gerätenamen zuordnen** ```bash [RO] networksetup -listallhardwareports ``` Beispiel: ```text Hardware Port: Ethernet Device: en0 Ethernet Address: 00:11:22:33:44:55 ``` **Alle Schnittstellen anzeigen** ```bash [RO] ifconfig ``` **Bestimmte Schnittstelle anzeigen** ```bash [RO] ifconfig en0 ``` Wichtige Felder: | Feld | Bedeutung | |---|---| | `status: active` | Link beziehungsweise Dienst ist aktiv | | `status: inactive` | kein aktiver Link | | `ether` | MAC-Adresse | | `media` | aktuelles Medium und ausgehandelter Modus | | `mtu` | Maximum Transmission Unit | | `RX`/`TX`-Informationen | abhängig von Befehl und Ausgabe | **Status eines Netzwerkdienstes** ```bash [RO] networksetup -getinfo "Ethernet" ``` Der Dienstname muss vorher mit folgendem Befehl ermittelt werden: ```bash [RO] networksetup -listallnetworkservices ``` **Medienstatus** ```bash [RO] networksetup -getMedia "Ethernet" ``` Die Verfügbarkeit und Ausgabe von `-getMedia` hängen vom Adapter, Treiber und Netzwerkdienst ab.
13. Wie werden Schnittstellenzähler unter macOS geprüft? **Interfaceübersicht mit Zählern** ```bash [RO] netstat -ib ``` Nur eine bestimmte Schnittstelle: ```bash [RO] netstat -ib -I en0 ``` Regelmäßig aktualisierte Anzeige: ```bash [RO] netstat -w 1 -I en0 ``` Beenden mit: ```text Strg+C ``` Je nach macOS-Version enthält die Ausgabe unter anderem: - eingehende Pakete, - eingehende Fehler, - eingehende Bytes, - ausgehende Pakete, - ausgehende Fehler, - ausgehende Bytes, - Kollisionen, - Drops. **Systembericht zur Netzwerkkonfiguration** ```bash [RO][SENS] system_profiler SPNetworkDataType ``` Der Systembericht kann interne Netzwerk-, Geräte- und Dienstinformationen enthalten und sollte bei einer Weitergabe entsprechend behandelt werden.
14. Wie werden Geschwindigkeit und Duplex richtig bewertet? **Beispiel einer erwarteten Verbindung** ```text Endgerät: Gigabit-Ethernet Switchport: Gigabit-Ethernet Kabel: für Gigabit geeignet Erwartung: 1000 Mbit/s, Full Duplex Gemessen: 100 Mbit/s, Full Duplex ``` Mögliche Ursachen: - beschädigtes oder unvollständig aufgelegtes Kabel, - nicht geeignete Verkabelung, - Switchport auf 100 Mbit/s begrenzt, - USB-Adapter unterstützt nur Fast Ethernet, - Dockingstation oder Zwischenadapter begrenzt die Geschwindigkeit, - manuell erzwungene Einstellung, - Aushandlungsproblem. **Duplex-Mismatch** Ein Duplex-Mismatch kann entstehen, wenn eine Seite fest auf Vollduplex gestellt ist, während die andere Seite anders konfiguriert ist oder keine passende Aushandlung erfolgt. Mögliche Symptome: - geringer Durchsatz, - Kollisionen beziehungsweise Late Collisions, - Framefehler, - gute Leistung in eine Richtung und schlechte in die andere, - stark schwankende Antwortzeiten. **Empfehlung** Bei modernen Ethernetverbindungen sollte Autonegotiation normalerweise auf beiden Seiten konsistent verwendet werden. Eine manuelle Einstellung darf nur entsprechend Herstellerdokumentation und abgestimmt auf beiden Seiten vorgenommen werden. ```text [CHANGE][DISRUPT] Geschwindigkeit und Duplex nicht einseitig und nicht ohne dokumentierten Rückweg verändern. ```
15. Wie werden Fehlerzähler richtig interpretiert? | Zähler | Mögliche technische Bedeutung | |---|---| | RX Errors | allgemeine Empfangsfehler | | TX Errors | allgemeine Sendefehler | | CRC Errors | Frame-Prüfsumme stimmt nicht | | Frame Errors | ungültige Frameausrichtung oder Rahmenfehler | | Length Errors | unerwartete Frame- beziehungsweise Paketlänge | | Dropped/Discards | Paket wurde verworfen | | Overruns | Puffer oder Verarbeitung konnte Daten nicht rechtzeitig übernehmen | | Missed | Adapter oder Treiber konnte Pakete nicht übernehmen | | Carrier Errors | Trägersignalproblem beim Senden | | Collisions | Kollisionen im Halbduplexbetrieb | | Late Collisions | verspätete Kollisionen, häufig Hinweis auf Duplex- oder Segmentproblem | | FEC Corrected | Fehler wurden durch Forward Error Correction korrigiert | | FEC Uncorrectable | Fehler konnten durch FEC nicht korrigiert werden | | Link Down Events | Anzahl erkannter Linkabbrüche | **Wichtige Einschränkungen** - Nicht jeder Treiber stellt alle Zähler bereit. - Gleichnamige Zähler können je nach Hersteller unterschiedlich detailliert sein. - Ein Gesamtwert seit dem letzten Neustart enthält möglicherweise alte Ereignisse. - Zähler können bei Neustart, Treiberneustart oder Gerätewechsel zurückgesetzt werden. - `Dropped` bedeutet nicht automatisch einen physischen Kabeldefekt. - Software, Pufferknappheit und Überlastung können ebenfalls Verwerfungen erzeugen. **Geeignete Messung** ```text 1. Ausgangswerte notieren. 2. Fehler reproduzieren. 3. Zähler erneut erfassen. 4. Differenz berechnen. 5. Gegenseite im selben Zeitraum prüfen. ```
16. Warum müssen beide Seiten einer Ethernetverbindung geprüft werden? Eine Verbindung besitzt zwei Enden: ```text Client-NIC ←→ Switchport ``` Ein Client kann beispielsweise nur Empfangsfehler melden, während der Switch Sendefehler oder Linkabbrüche protokolliert. Auf beiden Seiten sollten geprüft werden: | Client | Switch | |---|---| | Linkstatus | Portstatus | | Geschwindigkeit | ausgehandelte Geschwindigkeit | | Duplex | ausgehandelter Duplexmodus | | RX-Fehler | TX-Fehler | | TX-Fehler | RX-Fehler | | Drops | Discards | | Treibermeldungen | Port- und Systemlogs | | MAC-Adresse | gelernte MAC-Adresse | | Verbindungszeitpunkt | letzte Linkänderung | | Adaptermodell | Port- und Transceivertyp | Die konkreten Switchbefehle unterscheiden sich je nach Hersteller und Betriebssystem. Sie dürfen nicht aus Beispielen anderer Plattformen übernommen werden.
17. Wie wird ein Kabel- oder Portfehler durch einen Vergleichstest eingegrenzt? **Ausgangslage** ```text CLIENT-023 verliert wiederholt den Link. ``` **Kontrollierter Vergleich** | Test | Geänderter Faktor | Ergebnisinterpretation | |---|---|---| | bekannt funktionierendes Patchkabel | Patchkabel | Fehler verschwindet: ursprüngliches Kabel verdächtig | | anderer freigegebener Switchport | Switchport und möglicherweise Konfiguration | Fehler verschwindet: Port oder Portkonfiguration prüfen | | anderer Client am selben Kabel | Endgerät | Fehler bleibt: Kabel, Dose oder Port wahrscheinlicher | | gleicher Client an anderer Dose | Gebäudestrecke und Port | Fehler verschwindet: ursprüngliche Strecke prüfen | | USB-Adapter statt interner NIC | Netzwerkadapter | Fehler verschwindet: interne NIC oder Treiber prüfen | **Wichtig** - Der Ersatz muss für Geschwindigkeit und Medientyp geeignet sein. - Ein anderer Switchport kann einem anderen VLAN zugeordnet sein. - Ein Portwechsel muss genehmigt und dokumentiert werden. - Kabel und Ports dürfen nicht wahllos aus produktiven Verbindungen entfernt werden. - Nach dem Test muss der vorgesehene Zustand wiederhergestellt werden. ```text [CHANGE][DISRUPT] Kabel- und Portwechsel unterbrechen bestehende Verbindungen. ```
18. Wie werden Dockingstationen und USB-Netzwerkadapter untersucht? Zusätzliche mögliche Fehlerstellen: ```text Notebook → USB-C- beziehungsweise Thunderbolt-Port → Dockingstation → interner Netzwerkadapter → RJ45-Port → Netzwerkkabel ``` Zu prüfen sind: - Stromversorgung der Dockingstation, - verwendeter Notebookanschluss, - USB-C- oder Thunderbolt-Verbindung, - Firmware der Dockingstation, - Treiber des integrierten Netzwerkadapters, - Linkgeschwindigkeit, - Energiesparzustand, - Verhalten nach Standby, - Vergleich ohne Dockingstation, - Vergleich mit einem freigegebenen Ersatzadapter. **Typische Symptome** - Adapter verschwindet nach dem Aufwachen, - Link wird erkannt, aber regelmäßig neu ausgehandelt, - Geschwindigkeit ist auf 100 Mbit/s begrenzt, - MAC-Adresse ändert sich, - Verbindung bricht bei hoher Last ab, - mehrere Geräte an der Dockingstation fallen gleichzeitig aus. Ein Treiber- oder Firmwareupdate sollte nur nach Prüfung von Modell, Hardwareversion, Herstellerdokumentation, Freigabe und Rückweg erfolgen.
19. Wie werden Energieverwaltung und Ruhezustand als Ursache geprüft? Mögliche Hinweise: - Fehler tritt nach Standby oder Ruhezustand auf, - Link ist nach dem Aufwachen vorhanden, aber keine Kommunikation möglich, - Adapter verschwindet zeitweise, - Verbindung funktioniert nach Adapterneustart wieder, - Dockingstation muss neu verbunden werden, - Ereignisprotokoll zeigt Treiber- oder Energieereignisse. **Windows-Einstellungen nur anzeigen** ```powershell [RO] Get-NetAdapterPowerManagement -Name 'Ethernet' ``` **Windows-Ereignisse des Netzwerkadapters suchen** ```powershell [RO] Get-WinEvent -LogName System -MaxEvents 1000 | Where-Object { $_.ProviderName -match 'NDIS|Kernel-PnP|Netwtw|e1d|e2f|Network' } | Select-Object TimeCreated, Id, ProviderName, LevelDisplayName, Message ``` Providernamen unterscheiden sich je nach Adapter und Treiber. Der Filter ist deshalb nur eine erste Suche. **Linux** ```bash [RO][PRIV] sudo journalctl -b | grep -Ei 'suspend|resume|link.*(up|down)|network|firmware' ``` **macOS** ```bash [RO] pmset -g log | grep -Ei 'sleep|wake' ``` Energiesparfunktionen sollten nicht dauerhaft deaktiviert werden, solange der Zusammenhang nicht belegt ist.
20. Warum sollten Offloading-Funktionen nicht vorschnell deaktiviert werden? Netzwerkadapter können bestimmte Aufgaben in Hardware oder Treiber ausführen: - Checksum Offload, - Large Send Offload, - Receive Segment Coalescing, - Receive Side Scaling, - VLAN-Offload, - IPsec-Offload, - Generic Segmentation Offload, - Generic Receive Offload. Diese Funktionen können CPU-Last reduzieren und den Durchsatz erhöhen. Gleichzeitig können sie die Darstellung in einem lokalen Paketmitschnitt beeinflussen. Beispielsweise kann Wireshark auf dem sendenden Host scheinbar ungültige Prüfsummen anzeigen, obwohl die korrekte Prüfsumme erst später vom Netzwerkadapter berechnet wird. ```text Angezeigter Checksum-Fehler im lokalen Mitschnitt ≠ automatisch beschädigtes Paket im Netzwerk ``` Vor einer Änderung müssen geprüft werden: - Herstellerdokumentation, - Treiberversion, - bekannte Fehler, - Vergleichsmessung an einem externen Messpunkt, - Auswirkung auf Produktion, - Rückweg. ```text [CHANGE][DISRUPT] Offloading-Funktionen nicht pauschal als „Problemlösung“ deaktivieren. ```
21. Wann ist ein Adapterneustart sinnvoll und welches Risiko besteht? Ein Adapterneustart kann einen vorübergehend fehlerhaften Treiber- oder Gerätezustand beheben. Er beseitigt aber möglicherweise nur das Symptom und zerstört den ursprünglichen Diagnosezustand. **Vorher erfassen** - Adapterstatus, - IP-Konfiguration, - Routingtabelle, - Fehlerzähler, - Treiberversion, - Ereignisprotokolle, - laufende Verbindungen, - Zeitpunkt des letzten Linkwechsels. **Windows** ```powershell [PRIV][CHANGE][DISRUPT] Restart-NetAdapter -Name 'Ethernet' ``` **Linux** ```bash [PRIV][CHANGE][DISRUPT] sudo ip link set dev eth0 down ``` ```bash [PRIV][CHANGE][DISRUPT] sudo ip link set dev eth0 up ``` **macOS** ```bash [PRIV][CHANGE][DISRUPT] sudo ifconfig en0 down ``` ```bash [PRIV][CHANGE][DISRUPT] sudo ifconfig en0 up ``` > Bei einer Remoteverbindung kann der Administrator durch das Deaktivieren der verwendeten Schnittstelle den eigenen Zugriff verlieren. Ein Adapterneustart darf remote nur mit gesichertem alternativem Zugangsweg durchgeführt werden.
22. Welche systematische Prüfungsreihenfolge ist sinnvoll? | Schritt | Prüfung | |---:|---| | 1 | betroffene Schnittstelle eindeutig bestimmen | | 2 | Kabel, Stecker, Adapter und Linkanzeige kontrollieren | | 3 | administrativen und operativen Status abfragen | | 4 | ausgehandelte Geschwindigkeit und Duplex prüfen | | 5 | Ausgangswerte der Fehlerzähler dokumentieren | | 6 | Fehler reproduzieren oder definierten Zeitraum beobachten | | 7 | Fehlerzähler erneut abfragen und Differenzen bestimmen | | 8 | Treiber-, Kernel- und Switchprotokolle vergleichen | | 9 | Gegenstelle beziehungsweise Switchport prüfen | | 10 | bekannt funktionierendes Kabel oder Vergleichsgerät verwenden | | 11 | erst danach eine kontrollierte Änderung durchführen | | 12 | ursprüngliches Fehlerbild erneut testen | | 13 | Ergebnis und Rückweg dokumentieren | **Merksatz** ```text Ansehen → Status lesen → Zähler vergleichen → Gegenseite prüfen → kontrolliert tauschen → erneut messen ```
23. Kompakte Befehlsübersicht für Windows, Linux und macOS | Aufgabe | Windows | Linux | macOS | |---|---|---|---| | Adapterübersicht | `[RO] Get-NetAdapter` | `[RO] ip -brief link` | `[RO] networksetup -listallhardwareports` | | physische Adapter | `[RO] Get-NetAdapter -Physical` | abhängig vom Gerätetyp | über Hardwareportzuordnung | | Adapterdetails | `[RO] Get-NetAdapter -Name 'Ethernet' \| Format-List *` | `[RO] ip link show dev eth0` | `[RO] ifconfig en0` | | Linkstatus | Feld `Status` | `[RO] cat /sys/class/net/eth0/carrier` | Feld `status` in `ifconfig en0` | | Geschwindigkeit | Feld `LinkSpeed` | `[RO][PRIV] sudo ethtool eth0` | `[RO] networksetup -getMedia "Ethernet"` | | Duplex | Adapterdetails beziehungsweise erweiterte Eigenschaften | `[RO][PRIV] sudo ethtool eth0` | Medienausgabe des Adapters | | Fehlerzähler | `[RO] Get-NetAdapterStatistics` | `[RO] ip -s -s link show dev eth0` | `[RO] netstat -ib -I en0` | | Treiberinformationen | `[RO] Get-NetAdapter \| Select Name,DriverInformation,DriverVersion` | `[RO][PRIV] sudo ethtool -i eth0` | `[RO][SENS] system_profiler SPNetworkDataType` | | Treiberstatistiken | `[RO] Get-NetAdapterStatistics -Name 'Ethernet' \| Format-List *` | `[RO][PRIV] sudo ethtool -S eth0` | abhängig vom Adaptertreiber | | erweiterte Eigenschaften | `[RO] Get-NetAdapterAdvancedProperty -Name 'Ethernet'` | `[RO][PRIV] sudo ethtool eth0` | abhängig vom Adapter | | Energieverwaltung | `[RO] Get-NetAdapterPowerManagement -Name 'Ethernet'` | Treiber- und Systemkonfiguration prüfen | `[RO] pmset -g` | | Linkereignisse | Windows-Systemprotokoll | `[RO] ip monitor link` | `[RO] log stream --style compact` | | Kernel-/Treiberlogs | `Get-WinEvent -LogName System` | `[RO][PRIV] sudo journalctl -k -b` | `[RO] log show --last 1h --style compact` | | Adapter neu starten | `[PRIV][CHANGE][DISRUPT] Restart-NetAdapter -Name 'Ethernet'` | `[PRIV][CHANGE][DISRUPT] sudo ip link set eth0 down/up` | `[PRIV][CHANGE][DISRUPT] sudo ifconfig en0 down/up` | Die Beispielnamen `Ethernet`, `eth0` und `en0` müssen durch die zuvor eindeutig ermittelte Schnittstelle ersetzt werden.
24. Dokumentationsvorlage ```text Ticketnummer: Prüfzeitpunkt: Zeitzone: Betroffenes Gerät: Betriebssystem: Standort: Verbindungsart: SCHNITTSTELLE Adaptername: Schnittstellenindex: Adaptermodell: MAC-Adresse: Treiberanbieter: Treiberversion: Treiberdatum: Firmwareversion: Administrativer Status: Operativer Status: Link erkannt: Ja / Nein Geschwindigkeit: Duplex: Autonegotiation: MTU: Energy Efficient Ethernet: Energieverwaltung: PHYSISCHE STRECKE Endgeräteport: Adapter oder Dockingstation: Patchkabel: Netzwerkdose: Patchpanel: Switch: Switchport: VLAN: Transceivertyp: Fasertyp: Linkanzeige Client: Linkanzeige Switch: ZÄHLER VORHER Zeitpunkt: RX-Pakete: RX-Bytes: RX-Fehler: RX-Drops: CRC-Fehler: Framefehler: TX-Pakete: TX-Bytes: TX-Fehler: TX-Drops: Kollisionen: Link-Down-Ereignisse: ZÄHLER NACHHER Zeitpunkt: RX-Pakete: RX-Bytes: RX-Fehler: RX-Drops: CRC-Fehler: Framefehler: TX-Pakete: TX-Bytes: TX-Fehler: TX-Drops: Kollisionen: Link-Down-Ereignisse: DIFFERENZ UND BEWERTUNG - - - VERGLEICHSTEST Getauschte Komponente: Ausgangszustand dokumentiert: Erwartetes Ergebnis: Tatsächliches Ergebnis: Ursprünglicher Zustand wiederhergestellt: TREIBER- UND SWITCHMELDUNGEN - - - Arbeitshypothese: Beleg: Durchgeführte Änderung: Rückweg: Abschlussprüfung: Ermittelte Ursache: ```
25. Offizielle Quellen und weiterführende Dokumentation **Microsoft** - [Get-NetAdapter](https://learn.microsoft.com/powershell/module/netadapter/get-netadapter) - [Get-NetAdapterStatistics](https://learn.microsoft.com/powershell/module/netadapter/get-netadapterstatistics) - [Get-NetAdapterAdvancedProperty](https://learn.microsoft.com/powershell/module/netadapter/get-netadapteradvancedproperty) - [Get-NetAdapterPowerManagement](https://learn.microsoft.com/powershell/module/netadapter/get-netadapterpowermanagement) - [Restart-NetAdapter](https://learn.microsoft.com/powershell/module/netadapter/restart-netadapter) - [Erweiterte NIC-Eigenschaften](https://learn.microsoft.com/windows-server/networking/technologies/hpn/hpn-nic-advanced-properties) **Linux** - [Linux Interface Statistics – Kernel-Dokumentation](https://www.kernel.org/doc/html/latest/networking/statistics.html) - [ethtool-Netlink – Kernel-Dokumentation](https://docs.kernel.org/networking/ethtool-netlink.html) - [ip-link – Linux Manual Page](https://man7.org/linux/man-pages/man8/ip-link.8.html) - Lokale Befehlsreferenz: `man ethtool` **Apple** - [Netzwerkstatus auf dem Mac prüfen](https://support.apple.com/guide/mac-help/check-the-status-of-your-network-mchlp2291/mac) - [Netzwerkumgebungen auf dem Mac verwenden](https://support.apple.com/105129) - Lokale Befehlsreferenzen: `man ifconfig`, `man netstat`, `man networksetup`, `man system_profiler` und `man pmset` > Verfügbare Statistiken und Eigenschaften hängen vom Betriebssystem, Adapter, Treiber, Transceiver und Hersteller ab. Nicht angezeigte Zähler dürfen nicht als Wert null interpretiert werden.
# 3.3 IP-Konfiguration und Subnetz prüfen Nachdem die physische Verbindung und der Netzwerkadapter geprüft wurden, wird die logische IP-Konfiguration untersucht. Ein aktiver Link reicht nicht aus: Das Endgerät benötigt eine zum Netzwerk passende IPv4- oder IPv6-Adresse, eine korrekte Präfixlänge, geeignete Routen sowie gegebenenfalls ein Standardgateway und DNS-Server. > **Grundregel:** Die angezeigte IP-Konfiguration muss mit der vorgesehenen Netzwerkdokumentation verglichen werden. Eine formal gültige Adresse kann trotzdem für den konkreten Standort oder das zugewiesene VLAN falsch sein. ---
1. Welche Angaben gehören zu einer vollständigen IP-Konfiguration? **IPv4** - IPv4-Adresse, - Präfixlänge beziehungsweise Subnetzmaske, - Netzwerkadresse, - Broadcastadresse, - Standardgateway, - DNS-Server, - DHCP aktiviert oder statisch, - DHCP-Server, - Leasebeginn und Leaseende, - Schnittstelle, - Schnittstellenmetrik, - zusätzliche Routen. **IPv6** - globale oder organisationsinterne IPv6-Adresse, - Link-Local-Adresse, - Präfixlänge, - Standardrouter, - DNS-Server, - Adressquelle, - Gültigkeits- und Bevorzugungsdauer, - temporäre Adressen, - Schnittstellenindex beziehungsweise Scope-ID, - zusätzliche Routen. **Beispieldokumentation** ```text Schnittstelle: Ethernet MAC-Adresse: 00-11-22-33-44-55 VLAN: 20 IPv4-Adresse: 192.0.2.23 Präfixlänge: /24 Subnetzmaske: 255.255.255.0 Netzwerkadresse: 192.0.2.0 Broadcastadresse: 192.0.2.255 Standardgateway: 192.0.2.1 DNS-Server: 192.0.2.53, 192.0.2.54 Adressquelle: DHCP ```
2. Welche Symptome sprechen für eine fehlerhafte IP-Konfiguration? - Adresse aus einem unerwarteten Subnetz, - IPv4-Adresse aus `169.254.0.0/16`, - fehlende IPv4-Adresse, - doppelt vergebene IP-Adresse, - falsche Subnetzmaske oder Präfixlänge, - fehlendes oder falsches Standardgateway, - mehrere unerwartete Standardrouten, - falsche DNS-Server, - statische Adresse statt DHCP, - DHCP-Adresse statt vorgesehener statischer Adresse, - alte Konfiguration nach Standort- oder VLAN-Wechsel, - Gateway liegt nicht im direkt erreichbaren Subnetz, - falsche Quelladresse wird für das Ziel ausgewählt, - nur IPv4 oder nur IPv6 funktioniert, - virtuelle Schnittstelle besitzt eine günstigere Route, - VPN-Adapter übernimmt unerwartet den Datenverkehr.
3. Wie wird die IP-Konfiguration unter Windows angezeigt? **Kompakte PowerShell-Übersicht** ```powershell [RO] Get-NetIPConfiguration ``` **Vollständige klassische Ausgabe** ```cmd [RO][SENS] ipconfig /all ``` Die Ausgabe kann Hostname, MAC-Adressen, DNS-Suffixe, DHCP-Server und interne Netzwerkadressen enthalten. **Nur aktive Adapter mit IPv4-Konfiguration** ```powershell [RO] Get-NetIPConfiguration | Where-Object NetAdapter.Status -eq 'Up' | Select-Object InterfaceAlias, InterfaceIndex, IPv4Address, IPv4DefaultGateway, DNSServer ``` **Alle IP-Adressen anzeigen** ```powershell [RO] Get-NetIPAddress | Sort-Object InterfaceIndex, AddressFamily, IPAddress | Format-Table InterfaceAlias, InterfaceIndex, AddressFamily, IPAddress, PrefixLength, PrefixOrigin, SuffixOrigin, AddressState ``` **Nur IPv4-Adressen** ```powershell [RO] Get-NetIPAddress -AddressFamily IPv4 | Format-Table InterfaceAlias, InterfaceIndex, IPAddress, PrefixLength, PrefixOrigin, AddressState ``` **Nur IPv6-Adressen** ```powershell [RO] Get-NetIPAddress -AddressFamily IPv6 | Format-Table InterfaceAlias, InterfaceIndex, IPAddress, PrefixLength, PrefixOrigin, AddressState ``` **Standardrouten anzeigen** ```powershell [RO] Get-NetRoute -DestinationPrefix '0.0.0.0/0' | Sort-Object RouteMetric | Format-Table InterfaceAlias, ifIndex, DestinationPrefix, NextHop, RouteMetric, InterfaceMetric ``` IPv6-Standardrouten: ```powershell [RO] Get-NetRoute -DestinationPrefix '::/0' | Sort-Object RouteMetric | Format-Table InterfaceAlias, ifIndex, DestinationPrefix, NextHop, RouteMetric, InterfaceMetric ```
4. Wie wird die IP-Konfiguration unter Linux angezeigt? **Kompakte Adressübersicht** ```bash [RO] ip -brief address ``` **Ausführliche Adressübersicht** ```bash [RO] ip address show ``` **Bestimmte Schnittstelle** ```bash [RO] ip address show dev eth0 ``` **Nur IPv4** ```bash [RO] ip -4 address show ``` **Nur IPv6** ```bash [RO] ip -6 address show ``` **IPv4-Routingtabelle** ```bash [RO] ip -4 route ``` **IPv6-Routingtabelle** ```bash [RO] ip -6 route ``` **Route und ausgewählte Quelladresse zu einem Ziel** ```bash [RO] ip route get 198.51.100.20 ``` IPv6: ```bash [RO] ip -6 route get 2001:db8:20::20 ``` **NetworkManager-Verbindungen** Falls NetworkManager verwendet wird: ```bash [RO] nmcli connection show ``` Aktive Verbindungen: ```bash [RO] nmcli connection show --active ``` Geräteinformationen: ```bash [RO] nmcli device show ``` **systemd-networkd** Falls systemd-networkd verwendet wird: ```bash [RO] networkctl status ``` ```bash [RO] networkctl status eth0 ``` Nicht jede Linux-Installation verwendet NetworkManager oder systemd-networkd. Zuerst muss bestimmt werden, welche Komponente die Netzwerkkonfiguration verwaltet.
5. Wie wird die IP-Konfiguration unter macOS angezeigt? **Hardwareports und Gerätenamen** ```bash [RO] networksetup -listallhardwareports ``` **Alle Schnittstellen** ```bash [RO] ifconfig ``` **Bestimmte Schnittstelle** ```bash [RO] ifconfig en0 ``` **IPv4-Konfiguration eines Netzwerkdienstes** ```bash [RO] networksetup -getinfo "Ethernet" ``` Der tatsächliche Dienstname muss vorher ermittelt werden: ```bash [RO] networksetup -listallnetworkservices ``` **IPv4-Konfigurationsmethode** ```bash [RO] networksetup -getinfo "Wi-Fi" ``` **DNS-Konfiguration** ```bash [RO][SENS] scutil --dns ``` **IPv4-Routingtabelle** ```bash [RO] netstat -rn -f inet ``` **IPv6-Routingtabelle** ```bash [RO] netstat -rn -f inet6 ``` **Ausgewählte Route zu einem IPv4-Ziel** ```bash [RO] route -n get 198.51.100.20 ``` **Ausgewählte Route zu einem IPv6-Ziel** ```bash [RO] route -n get -inet6 2001:db8:20::20 ``` Die Dienstbezeichnung `Ethernet` oder `Wi-Fi` darf nicht ungeprüft übernommen werden. Sie kann auf einem konkreten Mac anders benannt sein.
6. Wie wird eine IPv4-Adresse einem Subnetz zugeordnet? **Beispiel** ```text IPv4-Adresse: 192.0.2.23 Präfix: /24 Subnetzmaske: 255.255.255.0 ``` Daraus ergibt sich: | Bestandteil | Wert | |---|---| | Netzwerkadresse | `192.0.2.0` | | erster typischer Host | `192.0.2.1` | | letzter typischer Host | `192.0.2.254` | | Broadcastadresse | `192.0.2.255` | | Gesamtzahl Adressen | 256 | | klassisch nutzbare Hostadressen | 254 | **Vergleich zweier Ziele** ```text Client: 192.0.2.23/24 Ziel A: 192.0.2.80 Ziel B: 198.51.100.20 ``` - Ziel A liegt im selben `/24`-Subnetz. - Ziel B liegt außerhalb dieses Subnetzes. - Ziel A wird normalerweise direkt über Layer 2 angesprochen. - Ziel B benötigt normalerweise eine passende Route beziehungsweise ein Gateway. **Wichtig** Die erste und letzte Adresse eines Subnetzes werden bei klassischer IPv4-Subnetznutzung als Netzwerk- und Broadcastadresse verwendet. Sonderfälle wie `/31` für Punkt-zu-Punkt-Verbindungen und `/32` für einzelne Hostrouten müssen gesondert betrachtet werden.
7. Wie werden Präfixlänge und Subnetzmaske umgerechnet? | Präfix | Subnetzmaske | Adressen insgesamt | klassisch nutzbare Hosts | |---:|---|---:|---:| | `/16` | `255.255.0.0` | 65.536 | 65.534 | | `/17` | `255.255.128.0` | 32.768 | 32.766 | | `/18` | `255.255.192.0` | 16.384 | 16.382 | | `/19` | `255.255.224.0` | 8.192 | 8.190 | | `/20` | `255.255.240.0` | 4.096 | 4.094 | | `/21` | `255.255.248.0` | 2.048 | 2.046 | | `/22` | `255.255.252.0` | 1.024 | 1.022 | | `/23` | `255.255.254.0` | 512 | 510 | | `/24` | `255.255.255.0` | 256 | 254 | | `/25` | `255.255.255.128` | 128 | 126 | | `/26` | `255.255.255.192` | 64 | 62 | | `/27` | `255.255.255.224` | 32 | 30 | | `/28` | `255.255.255.240` | 16 | 14 | | `/29` | `255.255.255.248` | 8 | 6 | | `/30` | `255.255.255.252` | 4 | 2 | | `/31` | `255.255.255.254` | 2 | Sonderfall für Punkt-zu-Punkt | | `/32` | `255.255.255.255` | 1 | einzelne Hostadresse | **Berechnung der Gesamtzahl** ```text 2 hoch (32 − Präfixlänge) ``` Beispiel `/27`: ```text 2 hoch (32 − 27) = 2 hoch 5 = 32 Adressen ``` Für gewöhnliche IPv4-Subnetze werden Netzwerk- und Broadcastadresse abgezogen: ```text 32 − 2 = 30 klassische Hostadressen ```
8. Wie wird eine falsche Subnetzmaske erkannt? **Vorgesehene Konfiguration** ```text Client: 192.0.2.130/25 Gateway: 192.0.2.129 ``` Das vorgesehene Subnetz lautet: ```text 192.0.2.128/25 ``` Adressbereich: ```text 192.0.2.128 bis 192.0.2.255 ``` **Fehlerhafte Konfiguration** ```text Client: 192.0.2.130/24 ``` Der Client hält nun den gesamten Bereich `192.0.2.0/24` für lokal. Ein Ziel wie `192.0.2.50` wird deshalb direkt per ARP gesucht, obwohl es nach der vorgesehenen Netzplanung in einem anderen Subnetz liegen kann. **Mögliche Symptome** - einzelne Ziele sind nicht erreichbar, - Gateway funktioniert, andere Subnetze jedoch nicht erwartungsgemäß, - ARP-Anfragen erscheinen für eigentlich entfernte Ziele, - Kommunikation funktioniert nur in eine Richtung, - ein Client verhält sich anders als Vergleichsclients, - Routing auf dem Client wirkt korrekt, die lokale Subnetzentscheidung ist aber falsch. Die Präfixlänge muss mit DHCP-Konfiguration, VLAN-Plan und Referenzsystemen verglichen werden.
9. Was bedeutet eine IPv4-Adresse aus 169.254.0.0/16? Windows und andere Betriebssysteme können eine IPv4-Link-Local-Adresse aus folgendem Bereich verwenden: ```text 169.254.0.0/16 ``` Unter Windows wird dies häufig als APIPA bezeichnet. Beispiel: ```text 169.254.73.22/16 ``` Das ist ein Hinweis darauf, dass keine reguläre IPv4-Konfiguration vorliegt beziehungsweise keine gewünschte DHCP-Konfiguration bezogen werden konnte. Die Adresse ermöglicht nur eingeschränkte lokale Kommunikation mit kompatibel konfigurierten Geräten im selben Link-Local-Bereich. **Mögliche Ursachen** - DHCP-Server nicht erreichbar, - falsches VLAN, - Switchport nicht korrekt konfiguriert, - DHCP-Relay fehlt oder funktioniert nicht, - DHCP-Bereich erschöpft, - DHCP-Verkehr wird gefiltert, - Netzwerkkabel wurde erst nach dem Start verbunden, - DHCP-Clientdienst arbeitet nicht, - Adapter oder Treiber ist fehlerhaft. **Windows-Prüfung** ```powershell [RO] Get-NetIPAddress -AddressFamily IPv4 | Where-Object IPAddress -Like '169.254.*' ``` **Linux-Prüfung** ```bash [RO] ip -4 address show | grep '169\.254\.' ``` **macOS-Prüfung** ```bash [RO] ifconfig | grep '169\.254\.' ``` Eine Link-Local-Adresse sollte nicht durch eine willkürlich gewählte statische Adresse ersetzt werden. Zuerst muss die vorgesehene Adressvergabe geklärt werden.
10. Welche besonderen IPv4-Adressbereiche müssen erkannt werden? | Bereich | Zweck | |---|---| | `0.0.0.0` | nicht spezifizierte IPv4-Adresse | | `0.0.0.0/0` | Standardroute beziehungsweise alle IPv4-Ziele | | `127.0.0.0/8` | Loopback | | `169.254.0.0/16` | IPv4 Link-Local | | `10.0.0.0/8` | privater IPv4-Adressraum | | `172.16.0.0/12` | privater IPv4-Adressraum | | `192.168.0.0/16` | privater IPv4-Adressraum | | `100.64.0.0/10` | Shared Address Space, häufig für Carrier-Grade NAT | | `224.0.0.0/4` | Multicast | | `255.255.255.255` | Limited Broadcast | Die in diesem Buch verwendeten Bereiche `192.0.2.0/24`, `198.51.100.0/24` und `203.0.113.0/24` sind für Dokumentationsbeispiele vorgesehen und sollten nicht als produktive Adressplanung übernommen werden.
11. Wie werden Standardgateway und lokale Erreichbarkeit geprüft? Zuerst muss das konfigurierte Gateway ausgelesen werden. Es darf nicht angenommen werden, dass es immer auf `.1` endet. **Windows** ```powershell [RO] Get-NetIPConfiguration | Select-Object InterfaceAlias, IPv4Address, IPv4DefaultGateway ``` Gateway testen: ```powershell [TEST] Test-Connection 192.0.2.1 -Count 4 ``` **Linux** ```bash [RO] ip route show default ``` Gateway testen: ```bash [TEST] ping -c 4 192.0.2.1 ``` **macOS** ```bash [RO] route -n get default ``` Gateway testen: ```bash [TEST] ping -c 4 192.0.2.1 ``` **Interpretation** | Ergebnis | Aussage | |---|---| | Gateway antwortet | ICMP-Kommunikation zum Gateway funktioniert | | Gateway antwortet nicht | keine ICMP-Antwort; Ursache noch offen | | Nachbartabelle enthält Gateway | Layer-2-Zuordnung wurde ermittelt | | keine Nachbarzuordnung | VLAN-, ARP-, NDP- oder Linkproblem möglich | | andere Clients erreichen Gateway | clientbezogene Ursache wahrscheinlicher | | Gateway blockiert ICMP | Ping ist als Nachweis ungeeignet | Ein fehlgeschlagener Ping beweist nicht, dass das Gateway vollständig unerreichbar ist. Manche Gateways beantworten ICMP nicht oder nur eingeschränkt.
12. Wie wird erkannt, welche Quelladresse für ein Ziel verwendet wird? Bei mehreren Adressen und Schnittstellen ist nicht automatisch die erwartete Quelladresse aktiv. **Windows** ```powershell [RO] Find-NetRoute -RemoteIPAddress 198.51.100.20 ``` Die Ausgabe zeigt unter anderem: - verwendete Schnittstelle, - Next Hop, - ausgewählte lokale IP-Adresse, - passende Route. **Linux** ```bash [RO] ip route get 198.51.100.20 ``` Beispiel: ```text 198.51.100.20 via 192.0.2.1 dev eth0 src 192.0.2.23 ``` **macOS** ```bash [RO] route -n get 198.51.100.20 ``` Zu kontrollieren sind: | Feld | Prüffrage | |---|---| | Interface | Wird der erwartete Adapter verwendet? | | Source | Wird die richtige Quelladresse gewählt? | | Gateway | Wird der erwartete Router verwendet? | | Route | Ist das Ziel als lokal, spezifisch oder über Default geroutet? | | Metrik | Gibt es eine bevorzugte konkurrierende Route? | Eine unerwartete Quelladresse kann zu Firewall-, Rückweg-, NAT- oder Berechtigungsproblemen führen.
13. Wie werden mehrere Standardgateways bewertet? Mehrere Standardrouten können beabsichtigt sein, beispielsweise bei: - mehreren Internetanbindungen, - VPN, - Redundanz, - Policy-Based Routing, - getrennten Netzwerkdiensten, - virtuellen Umgebungen. Sie können aber auch zu unerwarteten Wegen führen. **Windows** ```powershell [RO] Get-NetRoute -DestinationPrefix '0.0.0.0/0' | Sort-Object RouteMetric, InterfaceMetric ``` **Linux** ```bash [RO] ip route show default ``` ```bash [RO] ip rule show ``` **macOS** ```bash [RO] netstat -rn -f inet | grep '^default' ``` **Zu prüfen** - welche Standardroute bevorzugt wird, - welche Schnittstelle zu dieser Route gehört, - ob ein VPN eine neue Route angelegt hat, - ob der Rückweg zur verwendeten Quelladresse passt, - ob die Metrik beabsichtigt ist, - ob eine spezifischere Route die Standardroute übersteuert. ```text Längstes passendes Präfix hat grundsätzlich Vorrang vor einer weniger spezifischen Route. Die Metrik entscheidet erst zwischen geeigneten konkurrierenden Routen nach den Regeln des jeweiligen Betriebssystems. ```
14. Wie werden IPv6-Adressen unterschieden? | IPv6-Typ | Typischer Bereich beziehungsweise Merkmal | Zweck | |---|---|---| | Unspecified | `::` | keine bestimmte Adresse | | Loopback | `::1` | lokaler Host | | Link-Local | `fe80::/10` | Kommunikation auf dem lokalen Link | | Unique Local | `fc00::/7` | interne IPv6-Adressierung | | Global Unicast | typischerweise aus `2000::/3` | global routbare Kommunikation | | Multicast | `ff00::/8` | Gruppenkommunikation | **Link-Local-Adresse** Beispiel: ```text fe80::1234:5678:9abc:def0%12 ``` Die Scope-ID `%12` beziehungsweise ein Interfacebezug ist erforderlich, weil derselbe Link-Local-Bereich auf mehreren Schnittstellen existieren kann. **Windows** ```powershell [RO] Get-NetIPAddress -AddressFamily IPv6 | Format-Table InterfaceAlias, InterfaceIndex, IPAddress, PrefixLength, AddressState, PrefixOrigin, SuffixOrigin ``` **Linux** ```bash [RO] ip -6 address show ``` **macOS** ```bash [RO] ifconfig | grep -E '^[a-z0-9]+:|inet6' ``` Eine vorhandene Link-Local-Adresse beweist nicht, dass globales oder standortübergreifendes IPv6-Routing funktioniert.
15. Was bedeuten bevorzugte, veraltete und vorläufige Adresszustände? Eine IP-Adresse kann vorhanden sein, aber noch nicht vollständig verwendbar sein. **Windows-Feld `AddressState`** | Zustand | Bedeutung | |---|---| | `Tentative` | Prüfung auf Adresskonflikt noch nicht abgeschlossen | | `Duplicate` | doppelte Adresse erkannt | | `Deprecated` | Adresse soll nicht mehr für neue Verbindungen bevorzugt werden | | `Preferred` | Adresse kann normal verwendet werden | | `Invalid` | Adresse ist nicht gültig | **Linux-Ausgabe kann unter anderem zeigen** | Kennzeichnung | Bedeutung | |---|---| | `tentative` | Duplicate Address Detection läuft | | `dadfailed` | Duplicate Address Detection ist fehlgeschlagen | | `deprecated` | Adresse wird für neue Verbindungen nicht bevorzugt | | `temporary` | temporäre IPv6-Adresse | | `dynamic` | dynamisch zugewiesen | **Prüfung unter Linux** ```bash [RO] ip address show ``` Eine Adresse im Zustand `Duplicate` oder `dadfailed` darf nicht als normal funktionsfähig betrachtet werden.
16. Wie wird ein IP-Adresskonflikt erkannt? Mögliche Symptome: - Warnmeldung über doppelte IP-Adresse, - Verbindung funktioniert wechselweise, - ARP-Eintrag ändert seine MAC-Adresse, - ein anderes Gerät ist unter der eigenen Adresse erreichbar, - Verbindungen brechen sporadisch ab, - Switch lernt dieselbe IP-Zuordnung über wechselnde MAC-Adressen, - Windows meldet `Duplicate`, - IPv6 Duplicate Address Detection schlägt fehl. **Windows** ```powershell [RO] Get-NetIPAddress | Where-Object AddressState -ne 'Preferred' | Format-Table InterfaceAlias, IPAddress, AddressFamily, AddressState ``` Systemereignisse untersuchen: ```powershell [RO] Get-WinEvent -LogName System -MaxEvents 1000 | Where-Object { $_.Message -match 'duplicate|conflict|Adressenkonflikt' } | Select-Object TimeCreated, Id, ProviderName, Message ``` **Linux** ```bash [RO] ip address show | grep -E 'tentative|dadfailed|deprecated' ``` Kernel- und Netzwerkprotokolle: ```bash [RO][PRIV] sudo journalctl -b | grep -Ei 'duplicate|conflict|dadfailed' ``` **macOS** ```bash [RO] log show --last 1h --style compact \ --predicate 'eventMessage CONTAINS[c] "duplicate" OR eventMessage CONTAINS[c] "conflict"' ``` **Wichtig** Das absichtliche Senden von ARP-Probes mit zusätzlichen Werkzeugen ist ein aktiver Test und kann Sicherheitsüberwachung auslösen. Solche Werkzeuge dürfen nur im autorisierten Netz eingesetzt werden. Bei einem bestätigten Konflikt müssen DHCP-Leases, statische Zuweisungen, Reservierungen, Dokumentation und die MAC-Adressen beider Geräte geprüft werden.
17. Wie werden DNS-Server innerhalb der IP-Konfiguration geprüft? An dieser Stelle wird nur geprüft, **welche DNS-Server konfiguriert sind**. Die eigentliche DNS-Fehleranalyse erfolgt auf Seite 3.8. **Windows** ```powershell [RO] Get-DnsClientServerAddress | Format-Table InterfaceAlias, InterfaceIndex, AddressFamily, ServerAddresses ``` **Linux mit systemd-resolved** ```bash [RO] resolvectl status ``` Klassische Resolverdatei: ```bash [RO] cat /etc/resolv.conf ``` Die Datei `/etc/resolv.conf` kann automatisch generiert oder ein symbolischer Link sein: ```bash [RO] ls -l /etc/resolv.conf ``` **macOS** ```bash [RO][SENS] scutil --dns ``` Dienstbezogene DNS-Server: ```bash [RO] networksetup -getdnsservers "Wi-Fi" ``` **Zu prüfen** - gehören die Server zur vorgesehenen Umgebung? - sind interne und externe Resolver korrekt getrennt? - hat ein VPN andere DNS-Server eingetragen? - existieren schnittstellen- oder domänenspezifische Resolver? - wird eine lokale Filterlösung verwendet? - ist die Reihenfolge beabsichtigt? Ein Eintrag in der Konfiguration beweist noch nicht, dass der DNS-Server erreichbar ist oder korrekte Antworten liefert.
18. Wie wird DHCP von statischer Adressierung unterschieden? **Windows** ```powershell [RO] Get-NetIPInterface -AddressFamily IPv4 | Select-Object InterfaceAlias, InterfaceIndex, Dhcp, ConnectionState ``` Adressursprung: ```powershell [RO] Get-NetIPAddress -AddressFamily IPv4 | Select-Object InterfaceAlias, IPAddress, PrefixLength, PrefixOrigin, SuffixOrigin ``` Vollständige Leaseinformationen: ```cmd [RO][SENS] ipconfig /all ``` **Linux mit NetworkManager** ```bash [RO] nmcli device show ``` Verbindungsprofil: ```bash [RO][SENS] nmcli connection show ``` Die genaue Verbindung kann anschließend gezielt abgefragt werden: ```bash [RO][SENS] nmcli connection show "VERBINDUNGSNAME" ``` **macOS** ```bash [RO] networksetup -getinfo "Ethernet" ``` **Mögliche Zustände** | Zustand | Bewertung | |---|---| | DHCP vorgesehen und DHCP aktiv | grundsätzlich passend | | DHCP vorgesehen, aber statische Adresse | Fehlkonfiguration möglich | | statische Adresse vorgesehen, aber DHCP aktiv | falsche Adresse möglich | | DHCP-Adresse aus falschem Subnetz | falsches VLAN oder falscher DHCP-Server möglich | | DHCP-Lease abgelaufen | Erneuerung und DHCP-Erreichbarkeit prüfen | | Link-Local-Adresse | reguläre DHCP-Konfiguration vermutlich nicht erhalten | Die detaillierte DHCP-Analyse folgt auf Seite 3.4.
19. Welche lokalen Tests sind nach der Konfigurationsprüfung sinnvoll? Die Adressen müssen durch die tatsächlichen Werte des untersuchten Systems ersetzt werden. | Reihenfolge | Test | Aussage | |---:|---|---| | 1 | Loopback testen | lokaler TCP/IP-Stack reagiert | | 2 | eigene Adresse testen | eigene konfigurierte Adresse reagiert lokal | | 3 | Gateway testen | Kommunikation bis zum lokalen Router | | 4 | Ziel im selben Subnetz testen | lokale Layer-2-Kommunikation | | 5 | entferntes Ziel per IP testen | Routing grundsätzlich möglich | | 6 | Ziel per Name testen | Namensauflösung zusätzlich beteiligt | **Windows** ```powershell [TEST] Test-Connection 127.0.0.1 -Count 4 ``` ```powershell [TEST] Test-Connection 192.0.2.23 -Count 4 ``` ```powershell [TEST] Test-Connection 192.0.2.1 -Count 4 ``` **Linux und macOS** ```bash [TEST] ping -c 4 127.0.0.1 ``` ```bash [TEST] ping -c 4 192.0.2.23 ``` ```bash [TEST] ping -c 4 192.0.2.1 ``` **IPv6-Loopback** Windows: ```powershell [TEST] Test-Connection ::1 -Count 4 ``` Linux und macOS: ```bash [TEST] ping -c 4 ::1 ``` Ein erfolgreicher Test zur eigenen IP-Adresse durchläuft nicht zwangsläufig den vollständigen physischen Netzwerkweg.
20. Warum sollten IP-Einstellungen nicht vorschnell verändert werden? Mögliche Risiken: - Verlust des Remotezugriffs, - doppelter IP-Adresskonflikt, - falsches VLAN wird verdeckt, - DHCP-Fehler bleibt unentdeckt, - bestehende Verbindungen brechen ab, - falsche DNS- oder Gatewaywerte werden eingetragen, - ursprünglicher Diagnosezustand geht verloren, - statische Serverkonfiguration wird überschrieben. **Vor jeder Änderung sichern** **Windows** ```powershell [RO][FILE][SENS] Get-NetIPConfiguration | Format-List * | Out-File 'C:\Temp\NetIPConfiguration-vorher.txt' ``` ```powershell [RO][FILE][SENS] Get-NetIPAddress | Format-List * | Out-File 'C:\Temp\NetIPAddress-vorher.txt' ``` ```powershell [RO][FILE][SENS] Get-NetRoute | Format-Table -AutoSize | Out-File 'C:\Temp\NetRoute-vorher.txt' -Width 300 ``` **Linux** ```bash [RO][FILE][SENS] ip address show > /tmp/ip-address-vorher.txt ``` ```bash [RO][FILE][SENS] ip route show table all > /tmp/ip-route-vorher.txt ``` **macOS** ```bash [RO][FILE][SENS] ifconfig > /tmp/ifconfig-vorher.txt ``` ```bash [RO][FILE][SENS] netstat -rn > /tmp/netstat-route-vorher.txt ``` Die verwendeten Speicherorte müssen zur betrieblichen Umgebung und deren Datenschutzvorgaben passen.
21. Welche eingreifenden Befehle existieren und warum sind sie riskant? **Windows – DHCP-Lease freigeben** ```cmd [PRIV][CHANGE][DISRUPT] ipconfig /release ``` Lease erneut anfordern: ```cmd [PRIV][CHANGE][DISRUPT] ipconfig /renew ``` **Linux mit NetworkManager – Verbindung neu aktivieren** ```bash [PRIV][CHANGE][DISRUPT] sudo nmcli connection down "VERBINDUNGSNAME" ``` ```bash [PRIV][CHANGE][DISRUPT] sudo nmcli connection up "VERBINDUNGSNAME" ``` **macOS – DHCP-Lease erneuern** ```bash [PRIV][CHANGE][DISRUPT] sudo ipconfig set en0 DHCP ``` Der macOS-Befehl setzt die betreffende Schnittstelle auf DHCP und ist deshalb nicht für ein System geeignet, das statisch konfiguriert sein soll. > Diese Befehle dürfen erst verwendet werden, nachdem die vorhandene Konfiguration, der vorgesehene Adressierungsmodus und ein Rückweg dokumentiert wurden. Bei einer Remoteverbindung kann der eigene Zugriff sofort verloren gehen.
22. Wie wird eine Referenzkonfiguration verglichen? Ein funktionierendes Vergleichssystem sollte möglichst folgende Merkmale teilen: - gleicher Standort, - gleiches VLAN, - gleiche Verbindungsart, - gleiche Geräteklasse, - gleiche Betriebssystemversion, - gleiche Netzwerkrolle. **Vergleichstabelle** | Eigenschaft | Betroffener Client | Referenzclient | Bewertung | |---|---|---|---| | VLAN | 20 | 20 | gleich | | IPv4-Adresse | `192.0.2.23` | `192.0.2.24` | plausibel | | Präfix | `/24` | `/24` | gleich | | Gateway | `192.0.2.1` | `192.0.2.1` | gleich | | DNS 1 | `192.0.2.53` | `192.0.2.53` | gleich | | DNS 2 | fehlt | `192.0.2.54` | Abweichung | | DHCP | aktiv | aktiv | gleich | | IPv6 | nur Link-Local | globale Adresse | Abweichung | | Standardroute | Ethernet | Ethernet | gleich | | VPN-Route | vorhanden | nicht vorhanden | relevante Abweichung | Eine Abweichung ist zunächst ein Untersuchungshinweis. Sie ist erst dann eine belegte Ursache, wenn sie zum Fehlerbild passt und durch einen kontrollierten Test bestätigt wird.
23. Welche typischen Fehlinterpretationen müssen vermieden werden? | Beobachtung | Falscher Schluss | Richtige Einordnung | |---|---|---| | IP-Adresse ist vorhanden | Konfiguration ist korrekt | Subnetz, Gateway und Adressquelle vergleichen | | Adresse beginnt mit `192.168` | Adresse gehört zum richtigen Netz | privater Bereich umfasst viele unterschiedliche Netze | | Gateway endet auf `.1` | Gateway ist automatisch korrekt | vorgesehenes Gateway dokumentiert prüfen | | `169.254.x.x` ist vorhanden | Netzwerkkarte ist defekt | reguläre IPv4-Konfiguration fehlt vermutlich | | Ping zur eigenen IP funktioniert | Netzwerkkabel funktioniert | Test kann lokal beantwortet werden | | Gateway antwortet nicht | Gateway ist ausgefallen | ICMP kann blockiert sein | | mehrere Adressen vorhanden | zwingend Fehlkonfiguration | bei IPv6 und mehreren Interfaces normal möglich | | IPv6 ist vorhanden | IPv6-Internet funktioniert | Link-Local-Adresse reicht dafür nicht | | DNS-Server ist eingetragen | DNS funktioniert | Erreichbarkeit und Antwort separat prüfen | | DHCP ist aktiviert | korrekte Lease wurde empfangen | Leasewerte und DHCP-Server prüfen | | `/24` sieht üblich aus | Präfix ist korrekt | Netzplan und Referenzsystem vergleichen | | eine Default Route existiert | richtiger Weg wird verwendet | spezifischere Routen und Metriken prüfen |
24. Wie sieht der systematische Prüfablauf aus? | Schritt | Prüfung | |---:|---| | 1 | tatsächlich verwendete Schnittstelle bestimmen | | 2 | vollständige IPv4- und IPv6-Konfiguration erfassen | | 3 | Adressquelle DHCP, statisch, SLAAC oder andere bestimmen | | 4 | Adresse und Präfix mit dem Netzplan vergleichen | | 5 | Netzwerk- und Broadcastadresse bei IPv4 bestimmen | | 6 | Gateway und DNS-Server vergleichen | | 7 | Adresszustand auf Duplicate, Tentative oder Deprecated prüfen | | 8 | Standardrouten und spezifische Routen untersuchen | | 9 | ausgewählte Route und Quelladresse zum Ziel prüfen | | 10 | Loopback, eigene Adresse und Gateway kontrolliert testen | | 11 | mit funktionierendem Referenzclient vergleichen | | 12 | erst danach DHCP, ARP/NDP oder Routing vertieft untersuchen | | 13 | Änderungen nur mit Sicherung und Rückweg durchführen | | 14 | Ergebnis dokumentieren | **Merksatz** ```text Schnittstelle → Adresse → Präfix → Gateway → DNS → Route → Quelladresse → Vergleich ```
25. Kompakte Befehlsübersicht für Windows, Linux und macOS | Aufgabe | Windows | Linux | macOS | |---|---|---|---| | vollständige Konfiguration | `[RO][SENS] ipconfig /all` | `[RO] ip address show` | `[RO] ifconfig` | | kompakte Übersicht | `[RO] Get-NetIPConfiguration` | `[RO] ip -brief address` | `[RO] networksetup -getinfo "DIENST"` | | IPv4-Adressen | `[RO] Get-NetIPAddress -AddressFamily IPv4` | `[RO] ip -4 address` | `[RO] ifconfig` | | IPv6-Adressen | `[RO] Get-NetIPAddress -AddressFamily IPv6` | `[RO] ip -6 address` | `[RO] ifconfig` | | IPv4-Routen | `[RO] Get-NetRoute -AddressFamily IPv4` | `[RO] ip -4 route` | `[RO] netstat -rn -f inet` | | IPv6-Routen | `[RO] Get-NetRoute -AddressFamily IPv6` | `[RO] ip -6 route` | `[RO] netstat -rn -f inet6` | | Standardroute IPv4 | `[RO] Get-NetRoute -DestinationPrefix '0.0.0.0/0'` | `[RO] ip route show default` | `[RO] route -n get default` | | Route zu Ziel | `[RO] Find-NetRoute -RemoteIPAddress ZIEL-IP` | `[RO] ip route get ZIEL-IP` | `[RO] route -n get ZIEL-IP` | | DNS-Server | `[RO] Get-DnsClientServerAddress` | `[RO] resolvectl status` | `[RO][SENS] scutil --dns` | | DHCP-Status | `[RO] Get-NetIPInterface -AddressFamily IPv4` | `[RO] nmcli device show` | `[RO] networksetup -getinfo "DIENST"` | | Loopback testen | `[TEST] Test-Connection 127.0.0.1 -Count 4` | `[TEST] ping -c 4 127.0.0.1` | `[TEST] ping -c 4 127.0.0.1` | | Gateway testen | `[TEST] Test-Connection GATEWAY -Count 4` | `[TEST] ping -c 4 GATEWAY` | `[TEST] ping -c 4 GATEWAY` | | Lease freigeben | `[PRIV][CHANGE][DISRUPT] ipconfig /release` | abhängig vom Netzwerkmanager | nicht direkt gleichwertig | | Lease erneuern | `[PRIV][CHANGE][DISRUPT] ipconfig /renew` | abhängig vom Netzwerkmanager | `[PRIV][CHANGE][DISRUPT] sudo ipconfig set INTERFACE DHCP` | Die Platzhalter `DIENST`, `INTERFACE`, `GATEWAY` und `ZIEL-IP` müssen durch zuvor eindeutig ermittelte Werte ersetzt werden.
26. Dokumentationsvorlage ```text Ticketnummer: Prüfzeitpunkt: Zeitzone: Betroffenes Gerät: Betriebssystem: Benutzer: Standort: VLAN: Verbindungsart: SCHNITTSTELLE Schnittstellenname: Schnittstellenindex: MAC-Adresse: Status: Linkgeschwindigkeit: MTU: IPV4 IPv4-Adresse: Präfixlänge: Subnetzmaske: Netzwerkadresse: Broadcastadresse: Adresszustand: Adressquelle: DHCP aktiviert: DHCP-Server: Leasebeginn: Leaseende: Standardgateway: DNS-Server: Ausgewählte Quelladresse zum Ziel: Ausgewählte Route: Next Hop: IPV6 Link-Local-Adresse: Globale beziehungsweise interne IPv6-Adresse: Präfixlänge: Adresszustand: Adressquelle: Standardrouter: DNS-Server: Ausgewählte Quelladresse zum Ziel: Ausgewählte Route: Next Hop: LOKALE TESTS Loopback IPv4: Loopback IPv6: Eigene IPv4-Adresse: Eigene IPv6-Adresse: IPv4-Gateway: IPv6-Router: Ziel im lokalen Subnetz: Entferntes Ziel per IP: REFERENZVERGLEICH Referenzgerät: Gleiches VLAN: IPv4-Präfix: Gateway: DNS-Server: Adressquelle: Relevante Abweichungen: AUFFÄLLIGKEITEN - - - Arbeitshypothese: Nächster Prüfschritt: Gesicherter Ausgangszustand: Durchgeführte Änderung: Rückweg: Abschlussprüfung: Ermittelte Ursache: ```
27. Offizielle Quellen und weiterführende Dokumentation **Microsoft** - [Get-NetIPConfiguration](https://learn.microsoft.com/powershell/module/nettcpip/get-netipconfiguration) - [Get-NetIPAddress](https://learn.microsoft.com/powershell/module/nettcpip/get-netipaddress) - [Get-NetIPInterface](https://learn.microsoft.com/powershell/module/nettcpip/get-netipinterface) - [Get-NetRoute](https://learn.microsoft.com/powershell/module/nettcpip/get-netroute) - [Find-NetRoute](https://learn.microsoft.com/powershell/module/nettcpip/find-netroute) - [Get-DnsClientServerAddress](https://learn.microsoft.com/powershell/module/dnsclient/get-dnsclientserveraddress) - [TCP/IP-Adressierung und Subnetting](https://learn.microsoft.com/troubleshoot/windows-client/networking/tcpip-addressing-and-subnetting) **Linux** - [ip-address – Linux Manual Page](https://man7.org/linux/man-pages/man8/ip-address.8.html) - [ip-route – Linux Manual Page](https://man7.org/linux/man-pages/man8/ip-route.8.html) - [ip-rule – Linux Manual Page](https://man7.org/linux/man-pages/man8/ip-rule.8.html) - [NetworkManager nmcli](https://networkmanager.dev/docs/api/latest/nmcli.html) - [systemd networkctl](https://www.freedesktop.org/software/systemd/man/latest/networkctl.html) **Apple** - Lokale Befehlsreferenzen: `man ifconfig`, `man route`, `man netstat`, `man scutil`, `man networksetup` und `man ipconfig` - [Ändern der TCP/IP-Einstellungen auf dem Mac](https://support.apple.com/guide/mac-help/change-tcp-ip-settings-mac-mh14129/mac) - [Ändern der DNS-Einstellungen auf dem Mac](https://support.apple.com/guide/mac-help/change-dns-settings-on-mac-mh14127/mac) **Standards** - [RFC 1918 – Private Address Space](https://www.rfc-editor.org/rfc/rfc1918) - [RFC 3927 – IPv4 Link-Local Addresses](https://www.rfc-editor.org/rfc/rfc3927) - [RFC 4291 – IPv6 Addressing Architecture](https://www.rfc-editor.org/rfc/rfc4291) - [RFC 6164 – IPv6 Prefix Length for Point-to-Point Links](https://www.rfc-editor.org/rfc/rfc6164) - [RFC 3021 – IPv4 /31 Point-to-Point Links](https://www.rfc-editor.org/rfc/rfc3021) - [RFC 5737 – IPv4 Documentation Address Blocks](https://www.rfc-editor.org/rfc/rfc5737) > Adressen, Präfixe, Gateways und DNS-Server müssen immer mit der tatsächlichen Netzwerkdokumentation verglichen werden. Die Beispielwerte auf dieser Seite sind keine Vorgabe für produktive Netze.
# 3.4 DHCP-Fehler analysieren DHCP stellt Clients automatisch Netzwerkparameter zur Verfügung. Dazu gehören typischerweise IP-Adresse, Präfix beziehungsweise Subnetzmaske, Standardgateway, DNS-Server, DNS-Suchdomäne und Lease-Dauer. Eine erfolgreiche DHCP-Zuweisung beweist jedoch nicht automatisch, dass alle übermittelten Parameter korrekt sind. Ein Client kann eine technisch gültige Adresse aus dem falschen Subnetz oder von einem nicht vorgesehenen DHCP-Server erhalten. > **Grundregel:** Zuerst die vorhandene Lease und deren Herkunft dokumentieren. Erst danach darf eine Freigabe oder Erneuerung durchgeführt werden. ---
1. Welche Symptome sprechen für ein DHCP-Problem? - IPv4-Adresse aus `169.254.0.0/16`, - keine reguläre IPv4-Adresse, - Adresse aus einem falschen Subnetz, - falsches Standardgateway, - falsche DNS-Server, - fehlende DHCP-Optionen, - Lease kann nicht erneuert werden, - Verbindung funktioniert erst nach langer Wartezeit, - neue Geräte erhalten keine Adresse, - bestehende Geräte funktionieren noch, - Fehler betrifft nur ein VLAN, - Fehler betrifft nur einen Standort, - ein Client erhält wechselnde Konfigurationen, - DHCP-Adresskonflikt wird gemeldet, - Lease-Dauer ist ungewöhnlich kurz, - nicht autorisierter DHCP-Server antwortet, - DHCP funktioniert über LAN, aber nicht über WLAN, - DHCP funktioniert im Server-VLAN, aber nicht über den Relay-Agenten.
2. Welche Informationen müssen vor einer Veränderung erfasst werden? | Information | Beispiel | |---|---| | Clienthostname | `CLIENT-023` | | MAC-Adresse | `00-11-22-33-44-55` | | Schnittstelle | Ethernet | | VLAN | 20 | | aktuelle IPv4-Adresse | `192.0.2.23` | | Präfix beziehungsweise Maske | `/24` beziehungsweise `255.255.255.0` | | Standardgateway | `192.0.2.1` | | DNS-Server | `192.0.2.53`, `192.0.2.54` | | DHCP aktiviert | Ja | | DHCP-Server | `192.0.2.10` | | Lease erhalten | `2026-07-31 08:00 CEST` | | Lease läuft ab | `2026-08-01 08:00 CEST` | | erwarteter DHCP-Bereich | `192.0.2.20–192.0.2.200` | | Fehlerbeginn | `2026-07-31 09:42 CEST` | Vor einer Lease-Erneuerung sollten zusätzlich gespeichert werden: - vollständige IP-Konfiguration, - Routingtabelle, - DNS-Konfiguration, - DHCP-Clientprotokolle, - relevante Netzwerkereignisse, - Vergleichsdaten eines funktionierenden Clients.
3. Wie funktioniert DHCPv4 grundsätzlich? Der klassische erstmalige DHCPv4-Ablauf wird häufig als DORA bezeichnet: ```text Client DHCP-Server │ │ │──── DHCPDISCOVER ────────────────────────>│ │<─── DHCPOFFER ────────────────────────────│ │──── DHCPREQUEST ─────────────────────────>│ │<─── DHCPACK ──────────────────────────────│ │ │ ``` | Nachricht | Absender | Bedeutung | |---|---|---| | `DHCPDISCOVER` | Client | sucht verfügbare DHCP-Server | | `DHCPOFFER` | Server | bietet Adresse und Parameter an | | `DHCPREQUEST` | Client | fordert ein bestimmtes Angebot an | | `DHCPACK` | Server | bestätigt die Lease | | `DHCPNAK` | Server | lehnt angeforderte Konfiguration ab | | `DHCPDECLINE` | Client | meldet angebotene Adresse als problematisch | | `DHCPRELEASE` | Client | gibt eine Lease frei | | `DHCPINFORM` | Client | fordert Optionen an, ohne eine neue Adresse zu beziehen | DHCPv4 verwendet grundsätzlich: | Richtung | UDP-Port | |---|---:| | Server | 67 | | Client | 68 | Die erste Kommunikation erfolgt häufig per Broadcast, weil der Client zunächst noch keine reguläre IPv4-Adresse und keinen bekannten DHCP-Server besitzt.
4. Wie wird eine bestehende DHCP-Konfiguration unter Windows geprüft? **Vollständige Konfiguration** ```cmd [RO][SENS] ipconfig /all ``` Zu prüfen sind insbesondere: ```text DHCP aktiviert IPv4-Adresse Subnetzmaske Lease erhalten Lease läuft ab Standardgateway DHCP-Server DNS-Server Verbindungsspezifisches DNS-Suffix ``` **DHCP-Status der Schnittstellen** ```powershell [RO] Get-NetIPInterface -AddressFamily IPv4 | Select-Object InterfaceAlias, InterfaceIndex, Dhcp, ConnectionState, InterfaceMetric ``` **Adressursprung** ```powershell [RO] Get-NetIPAddress -AddressFamily IPv4 | Select-Object InterfaceAlias, InterfaceIndex, IPAddress, PrefixLength, PrefixOrigin, SuffixOrigin, AddressState ``` **Konfiguration sichern** ```powershell [RO][FILE][SENS] ipconfig /all | Out-File 'C:\Temp\ipconfig-vor-dhcp-test.txt' ``` ```powershell [RO][FILE][SENS] Get-NetIPConfiguration | Format-List * | Out-File 'C:\Temp\netipconfig-vor-dhcp-test.txt' ``` Die Verzeichnisse müssen vorhanden und für Diagnoseinformationen freigegeben sein.
5. Wie werden DHCP-Clientereignisse unter Windows gelesen? **Verfügbare DHCP-bezogene Protokolle suchen** ```powershell [RO] Get-WinEvent -ListLog '*DHCP*' | Select-Object LogName, IsEnabled, RecordCount ``` Je nach Windows-Version und aktivierten Kanälen können unter anderem DHCP-Client-Protokolle unter folgendem Bereich vorhanden sein: ```text Anwendungs- und Dienstprotokolle → Microsoft → Windows → Dhcp-Client ``` **Aktivierte DHCP-Protokolle auslesen** ```powershell [RO] Get-WinEvent -ListLog '*DHCP*' | Where-Object { $_.IsEnabled -and $_.RecordCount -gt 0 } | ForEach-Object { Get-WinEvent -LogName $_.LogName -MaxEvents 50 -ErrorAction SilentlyContinue } | Sort-Object TimeCreated -Descending | Select-Object TimeCreated, LogName, Id, LevelDisplayName, ProviderName, Message ``` **Systemprotokoll nach DHCP-Meldungen durchsuchen** ```powershell [RO] Get-WinEvent -LogName System -MaxEvents 1000 | Where-Object { $_.ProviderName -Match 'Dhcp' -or $_.Message -Match 'DHCP' } | Sort-Object TimeCreated -Descending | Select-Object TimeCreated, Id, LevelDisplayName, ProviderName, Message ``` Protokollname, Provider und Ereignis-ID können sich zwischen Windows-Versionen unterscheiden. Deshalb sollte zuerst mit `Get-WinEvent -ListLog '*DHCP*'` geprüft werden, welche Kanäle tatsächlich vorhanden sind.
6. Wie wird eine bestehende DHCP-Konfiguration unter Linux geprüft? **Grundlegende IP-Konfiguration** ```bash [RO] ip -4 address ``` ```bash [RO] ip -4 route ``` **Mit NetworkManager** Gerätestatus: ```bash [RO] nmcli device status ``` Ausführliche Gerätedaten: ```bash [RO][SENS] nmcli device show eth0 ``` Aktive Verbindungen: ```bash [RO] nmcli connection show --active ``` Verbindungsprofil: ```bash [RO][SENS] nmcli connection show "VERBINDUNGSNAME" ``` Zu prüfen sind insbesondere Eigenschaften wie: - IPv4-Konfigurationsmethode, - aktuelle IPv4-Adresse, - Gateway, - DNS-Server, - DHCP-Server beziehungsweise DHCP-Optionen, - Domänen- und Suchinformationen. Die tatsächlich verfügbaren Felder hängen von NetworkManager-Version und Backend ab. **Mit systemd-networkd** ```bash [RO] networkctl status eth0 ``` ```bash [RO] networkctl status --all ``` **Lease-Dateien** Speicherort und Format von Lease-Dateien hängen von Distribution und Netzwerkmanager ab. Es sollte nicht von einem festen Pfad ausgegangen werden. Vorhandene Dateien können gesucht werden, ohne sie zu verändern: ```bash [RO][PRIV][SENS] sudo find /run /var/lib \ -maxdepth 4 \ -type f \ \( -iname '*lease*' -o -iname '*dhcp*' \) \ 2>/dev/null ``` Gefundene Dateien dürfen nicht gelöscht oder verändert werden, bevor Netzwerkmanager und Zweck eindeutig bestimmt wurden.
7. Wie werden DHCP-Clientprotokolle unter Linux geprüft? **NetworkManager** ```bash [RO][PRIV] sudo journalctl -b -u NetworkManager ``` Nach DHCP-Meldungen filtern: ```bash [RO][PRIV] sudo journalctl -b -u NetworkManager | grep -Ei 'dhcp|lease|offer|request|ack|nak|timeout' ``` **systemd-networkd** ```bash [RO][PRIV] sudo journalctl -b -u systemd-networkd ``` Nach DHCP-Meldungen filtern: ```bash [RO][PRIV] sudo journalctl -b -u systemd-networkd | grep -Ei 'dhcp|lease|offer|request|ack|nak|timeout' ``` **Allgemeine Protokollsuche** ```bash [RO][PRIV] sudo journalctl -b | grep -Ei 'dhcp|lease|dhclient|NetworkManager|systemd-networkd' ``` **Kernelmeldungen zur Schnittstelle** ```bash [RO][PRIV] sudo journalctl -k -b | grep -E 'eth0|link.*(up|down)|carrier' ``` Vor der Interpretation muss bekannt sein, welcher Dienst die Schnittstelle verwaltet. Meldungen eines installierten, aber nicht verwendeten DHCP-Clients sind möglicherweise irrelevant.
8. Wie wird eine bestehende DHCP-Konfiguration unter macOS geprüft? **Netzwerkdienste auflisten** ```bash [RO] networksetup -listallnetworkservices ``` **Hardwareports zuordnen** ```bash [RO] networksetup -listallhardwareports ``` **Konfiguration eines Dienstes** ```bash [RO] networksetup -getinfo "Ethernet" ``` **DHCP-Paketinformationen einer Schnittstelle** ```bash [RO][SENS] ipconfig getpacket en0 ``` Diese Ausgabe kann unter anderem enthalten: - angebotene IPv4-Adresse, - Subnetzmaske, - Router, - DHCP-Serverkennung, - Lease-Dauer, - DNS-Server, - Domainnamen, - weitere DHCP-Optionen. **Nur die aktuelle IPv4-Adresse** ```bash [RO] ipconfig getifaddr en0 ``` **DNS-Konfiguration** ```bash [RO][SENS] scutil --dns ``` **Systemprotokolle nach DHCP durchsuchen** ```bash [RO] log show \ --last 1h \ --style compact \ --predicate 'process == "bootp" OR eventMessage CONTAINS[c] "DHCP"' ``` Je nach macOS-Version können Prozessname, Subsystem und verfügbare Meldungen abweichen. Eine leere Ausgabe beweist nicht, dass kein DHCP-Vorgang stattgefunden hat.
9. Wie wird geprüft, ob der Client überhaupt DHCP verwendet? Ein Client kann eine statische Adresse besitzen und deshalb keine reguläre DHCP-Lease anfordern. **Windows** ```powershell [RO] Get-NetIPInterface -AddressFamily IPv4 | Select-Object InterfaceAlias, Dhcp, ConnectionState ``` **Linux mit NetworkManager** ```bash [RO] nmcli connection show "VERBINDUNGSNAME" | grep -E '^ipv4\.method' ``` Typische Werte: | Wert | Bedeutung | |---|---| | `auto` | automatische IPv4-Konfiguration, typischerweise DHCP | | `manual` | statische Konfiguration | | `disabled` | IPv4 deaktiviert | | `shared` | geteilte Verbindung mit eigener Adressbereitstellung | **macOS** ```bash [RO] networksetup -getinfo "Ethernet" ``` Die Ausgabe zeigt die verwendete Konfigurationsmethode. **Prüffragen** - Soll diese Schnittstelle DHCP verwenden? - Ist möglicherweise ein altes statisches Profil aktiv? - Verwaltet eine zusätzliche Software die Konfiguration? - Ist ein VPN- oder MDM-Profil beteiligt? - Wird die richtige physische oder virtuelle Schnittstelle untersucht?
10. Wie wird eine DHCPv4-Störung anhand der Nachrichten eingegrenzt? | Sichtbare Nachrichten | Mögliche Untersuchungsrichtung | |---|---| | kein `DHCPDISCOVER` | DHCP-Client, Schnittstelle oder Capture-Punkt prüfen | | `DISCOVER`, aber kein `OFFER` | VLAN, Relay, Filter, Server oder Bereich prüfen | | mehrere `OFFER` | mehrere DHCP-Server vorhanden; Berechtigung prüfen | | `OFFER`, aber kein `REQUEST` | Clientzustand oder nicht gewähltes Angebot prüfen | | `REQUEST`, aber kein `ACK` | Server, Relay, Filter oder Adressprüfung untersuchen | | `REQUEST` gefolgt von `NAK` | angeforderte Adresse ist für Server nicht gültig | | `ACK` mit falschen Optionen | Scope-, Policy- oder Optionskonfiguration prüfen | | wiederholte DORA-Sequenzen | Lease wird nicht übernommen oder Verbindung bricht ab | | `DECLINE` | Client vermutet Adresskonflikt | | Lease funktioniert nur im Server-VLAN | DHCP-Relay oder Routing prüfen | Die Interpretation muss anhand von Transaktions-ID, Client-MAC beziehungsweise Client-Identifier und Zeitstempel erfolgen. Gleichzeitige DHCP-Vorgänge anderer Clients dürfen nicht verwechselt werden.
11. Wie wird DHCP-Verkehr sicher mit Wireshark oder TShark geprüft? **Wireshark-Display-Filter für DHCPv4** ```text dhcp ``` Je nach Wireshark-Version wird auch weiterhin der ältere Protokollname `bootp` in Feldern oder Filtern verwendet. Der folgende Filter ist deshalb ebenfalls verbreitet: ```text bootp ``` **Nur DHCPv4-Ports** ```text udp.port == 67 || udp.port == 68 ``` **TShark-Liveanzeige** ```bash [TEST][PRIV][SENS] tshark \ -i INTERFACE \ -f "udp port 67 or udp port 68" ``` **Zeitlich begrenzte Aufnahme mit dumpcap** ```bash [TEST][PRIV][FILE][SENS] dumpcap \ -i INTERFACE \ -f "udp port 67 or udp port 68" \ -a duration:60 \ -w dhcp-test.pcapng ``` **DHCP-Nachrichtentypen aus einer Datei anzeigen** ```bash [RO][SENS] tshark \ -r dhcp-test.pcapng \ -Y "bootp" \ -T fields \ -e frame.time \ -e eth.src \ -e ip.src \ -e ip.dst \ -e bootp.option.dhcp ``` Feldnamen können sich zwischen Wireshark-Versionen ändern. Die lokal verfügbaren Felder sollten geprüft werden: ```bash [RO] tshark -G fields | grep -Ei 'dhcp|bootp' ``` Ein Paketmitschnitt darf nur mit Freigabe und unter Beachtung der Regeln aus Seite 2.14 erstellt werden.
12. Wie wird ein fehlendes DHCPOFFER untersucht? Wenn der Client `DHCPDISCOVER` sendet, aber kein Angebot erhält, wird der Kommunikationsweg geprüft: ```text Client → Switchport → Client-VLAN → DHCP-Relay oder direktes Broadcastsegment → Netzwerkpfad → DHCP-Server ``` **Prüffragen** 1. Ist der Client im richtigen VLAN? 2. Wird das `DHCPDISCOVER` am Client gesendet? 3. Wird es am Switch beziehungsweise Relay empfangen? 4. Ist für dieses VLAN ein DHCP-Relay konfiguriert? 5. Verwendet das Relay die richtige Serveradresse? 6. Ist der DHCP-Server vom Relay aus erreichbar? 7. Ist UDP 67/68 auf dem Weg erlaubt? 8. Existiert ein aktiver DHCP-Bereich für das Clientnetz? 9. Besitzt der Bereich noch freie Adressen? 10. Ist der Serverdienst aktiv? 11. Wird die Anfrage durch eine Policy abgelehnt? 12. Enthält die Relay-Anfrage die erwarteten Informationen? 13. Wird ein Angebot zurückgesendet? 14. Erreicht das Angebot wieder den Client? Wenn nur ein Client betroffen ist, während andere Clients am selben Anschlussbereich neue Leases erhalten, ist ein vollständiger Ausfall des DHCP-Servers weniger wahrscheinlich.
13. Welche Aufgabe hat ein DHCP-Relay? IPv4-Broadcasts werden normalerweise nicht durch Router weitergeleitet. Befindet sich der DHCP-Server in einem anderen Netz, nimmt ein DHCP-Relay die Clientanfrage entgegen und leitet sie an den Server weiter. ```text Client-VLAN 20 192.0.2.0/24 │ ├─ DHCPDISCOVER als Broadcast │ └─ Gateway/DHCP-Relay │ └─ Weiterleitung zum DHCP-Server 198.51.100.10 ``` Der Server muss anhand der Relayinformationen erkennen können, für welches Clientnetz eine Adresse vergeben werden soll. **Typische Relay-Probleme** - Relay fehlt auf dem VLAN-Interface, - falsche DHCP-Serveradresse, - neues VLAN wurde nicht ergänzt, - Route zum DHCP-Server fehlt, - Rückroute zum Relay fehlt, - Firewall blockiert DHCP-Verkehr, - falsche Relay- beziehungsweise Gatewayadresse, - Policy behandelt Relayinformationen falsch, - redundante Relays verhalten sich unterschiedlich. **Typisches Muster** ```text DHCP funktioniert im selben Netz wie der Server, aber nicht in einem entfernten VLAN. ``` Dies ist ein starker Hinweis auf Relay, Routing, Firewall oder fehlenden Scope für das entfernte Netz.
14. Wie wird ein erschöpfter DHCP-Bereich erkannt? Mögliche Symptome: - bestehende Clients funktionieren weiterhin, - neue Clients erhalten keine Adresse, - nach Ablauf alter Leases können weitere Geräte ausfallen, - Server meldet keine verfügbaren Adressen, - freie Adressen liegen nahe null, - viele veraltete oder ungewöhnlich lange Leases, - Adressen sind durch Reservierungen belegt, - Bereich ist zu klein für die tatsächliche Gerätezahl. **Zu prüfen** | Bereich | Prüffrage | |---|---| | Adresspool | Wie viele Adressen enthält er? | | aktive Leases | Wie viele Adressen sind vergeben? | | freie Adressen | Wie viele können noch vergeben werden? | | Ausschlüsse | Welche Adressen sind ausgeschlossen? | | Reservierungen | Welche Adressen sind fest zugeordnet? | | Lease-Dauer | Passt sie zur Nutzung des Netzes? | | veraltete Einträge | Sind Leases nicht mehr aktiver Geräte vorhanden? | | Konflikterkennung | Wurden Adressen als problematisch markiert? | Eine Vergrößerung des Bereichs ist eine Netzwerkänderung. Präfix, Gateway, VLAN, Routing, Ausschlüsse und mögliche Überschneidungen müssen vorher geprüft werden.
15. Wie wird ein nicht autorisierter DHCP-Server erkannt? Ein nicht vorgesehener DHCP-Server kann Clients falsche Netzwerkparameter liefern. Mögliche Hinweise: - verschiedene Clients erhalten unterschiedliche Gateways, - DNS-Server weichen voneinander ab, - Lease stammt von einer unbekannten Serveradresse, - mehrere `DHCPOFFER` werden sichtbar, - Fehler betrifft nur einen Switchbereich, - Clients erhalten Adressen aus einem fremden Subnetz, - Internetzugriff funktioniert, interne Dienste jedoch nicht. **Prüfung mit einem Paketmitschnitt** ```text DHCPDISCOVER ← DHCPOFFER von Server A ← DHCPOFFER von Server B ``` Zu dokumentieren sind: - Server-Identifier, - Quell-IP-Adresse, - Quell-MAC-Adresse, - angebotene IP-Adresse, - Gateway, - DNS-Server, - Lease-Dauer, - Switchport der Server-MAC-Adresse. **Wichtig** Mehrere DHCP-Server können absichtlich zur Redundanz eingesetzt werden. Mehrere Angebote sind deshalb nicht automatisch ein Sicherheitsvorfall. Die Server müssen mit der vorgesehenen Architektur verglichen werden. Ein tatsächlich unbekannter DHCP-Server ist umgehend an Netzwerk- und Informationssicherheitsverantwortliche zu eskalieren.
16. Wie werden falsche DHCP-Optionen erkannt? Eine Lease kann erfolgreich bestätigt werden und trotzdem falsche Parameter enthalten. Typische DHCP-Optionen: | Option | Zweck | |---:|---| | 1 | Subnetzmaske | | 3 | Router beziehungsweise Standardgateway | | 6 | DNS-Server | | 15 | Domainname | | 42 | NTP-Server | | 51 | Lease-Dauer | | 54 | DHCP-Server-Identifier | | 58 | Renewal Time T1 | | 59 | Rebinding Time T2 | | 66 | TFTP- beziehungsweise Servername, abhängig vom Einsatz | | 67 | Bootdateiname | | 119 | Domain Search List | | 121 | Classless Static Routes | Nicht jede Option wird in jeder Umgebung verwendet. **Typische Fehler** - falsche Subnetzmaske, - Gateway aus einem anderen Netz, - veralteter DNS-Server, - falsches DNS-Suffix, - fehlerhafte statische Route, - falscher Zeitserver, - falsche Bootinformationen, - Scope-Option wird durch Server-, Policy- oder Reservierungsoption überschrieben. Die wirksame Option kann aus mehreren Konfigurationsebenen stammen. Deshalb muss die tatsächlich an den Client übertragene DHCP-Antwort geprüft werden.
17. Wie funktionieren Verlängerung und Rebinding einer Lease? Eine DHCP-Lease besitzt eine begrenzte Gültigkeitsdauer. Vereinfacht: ```text Leasebeginn │ ├─ T1: Client versucht Erneuerung beim bisherigen Server │ ├─ T2: Client versucht Erneuerung über weitere erreichbare Server │ └─ Leaseende: Adresse darf nicht unbegrenzt weiterverwendet werden ``` Typische Standardbeziehungen, sofern der Server nichts anderes vorgibt: ```text T1 ungefähr 50 % der Lease-Dauer T2 ungefähr 87,5 % der Lease-Dauer ``` Die tatsächlich übertragenen Werte sind entscheidend. **Mögliche Fehlerbilder** | Situation | Auswirkung | |---|---| | Erstanfrage funktioniert, Verlängerung nicht | bestehende Verbindung kann bis zum Leaseende bestehen | | Server zeitweise nicht erreichbar | Client versucht weitere Erneuerungen | | DHCPNAK bei Erneuerung | Client muss Konfiguration verwerfen und neu anfordern | | Netzwerkwechsel | alte Adresse passt möglicherweise nicht zum neuen VLAN | | sehr kurze Lease | häufige DHCP-Kommunikation und höhere Serverlast | | sehr lange Lease | Änderungen werden langsamer wirksam |
18. Wann dürfen Lease-Freigabe und -Erneuerung durchgeführt werden? Erst nachdem der Ausgangszustand dokumentiert wurde und geklärt ist, dass die Schnittstelle DHCP verwenden soll. **Windows** Lease freigeben: ```cmd [PRIV][CHANGE][DISRUPT] ipconfig /release ``` Lease erneuern: ```cmd [PRIV][CHANGE][DISRUPT] ipconfig /renew ``` Nur einen benannten Adapter ansprechen: ```cmd [PRIV][CHANGE][DISRUPT] ipconfig /release "Ethernet" ``` ```cmd [PRIV][CHANGE][DISRUPT] ipconfig /renew "Ethernet" ``` Die Behandlung von Platzhaltern und Adapternamen sollte auf dem konkreten Windows-System mit `ipconfig /?` geprüft werden. **Linux mit NetworkManager** Verbindung erneut aktivieren: ```bash [PRIV][CHANGE][DISRUPT] sudo nmcli connection down "VERBINDUNGSNAME" ``` ```bash [PRIV][CHANGE][DISRUPT] sudo nmcli connection up "VERBINDUNGSNAME" ``` Abhängig von NetworkManager-Version und Profil kann auch eine erneute Anwendung vorhandener Einstellungen möglich sein: ```bash [PRIV][CHANGE][DISRUPT] sudo nmcli device reapply eth0 ``` Dies erzwingt nicht in jedem Fall einen vollständigen neuen DHCP-DORA-Ablauf. **macOS** DHCP-Konfiguration auf einer Schnittstelle anfordern: ```bash [PRIV][CHANGE][DISRUPT] sudo ipconfig set en0 DHCP ``` Dieser Befehl setzt die Schnittstelle auf DHCP und darf nicht verwendet werden, wenn eine statische Konfiguration vorgesehen ist. > Bei Remotezugriff kann die Freigabe einer Lease die eigene Administrationsverbindung sofort beenden.
19. Warum sollte dhclient nicht ungeprüft parallel gestartet werden? Der Befehl `dhclient` ist nicht auf jeder Linux-Installation vorhanden. Außerdem kann die Schnittstelle bereits durch NetworkManager, systemd-networkd oder einen anderen Netzwerkdienst verwaltet werden. Ein zusätzlich gestarteter DHCP-Client kann: - mit dem bestehenden Netzwerkmanager konkurrieren, - eine vorhandene Lease verändern, - Routen und DNS-Einstellungen überschreiben, - die Remoteverbindung unterbrechen, - Diagnoseergebnisse verfälschen. Vor einer Verwendung muss geprüft werden: ```bash [RO] ps -ef | grep -E '[d]hclient|[N]etworkManager|[s]ystemd-networkd' ``` ```bash [RO] systemctl --type=service --state=running | grep -Ei 'network|dhcp' ``` `dhclient` sollte nur verwendet werden, wenn er tatsächlich der vorgesehene DHCP-Client dieser Schnittstelle ist und seine lokale Dokumentation geprüft wurde.
20. Wie unterscheidet sich DHCPv6 von DHCPv4? DHCPv6 ist kein direkter identischer Ersatz für DHCPv4. IPv6-Clients können Konfigurationen unter anderem erhalten durch: - Router Advertisements, - Stateless Address Autoconfiguration, - zustandsbehaftetes DHCPv6, - zustandsloses DHCPv6, - statische Konfiguration. DHCPv6 verwendet: | Richtung | UDP-Port | |---|---:| | Client | 546 | | Server | 547 | Vereinfachter DHCPv6-Ablauf: ```text Client DHCPv6-Server │ │ │──── SOLICIT ─────────────────────────────>│ │<─── ADVERTISE ────────────────────────────│ │──── REQUEST ─────────────────────────────>│ │<─── REPLY ────────────────────────────────│ ``` Typische Nachrichten: - `SOLICIT`, - `ADVERTISE`, - `REQUEST`, - `REPLY`, - `RENEW`, - `REBIND`, - `RELEASE`, - `INFORMATION-REQUEST`. **Wireshark-Filter** ```text dhcpv6 ``` Capture-Filter: ```text udp port 546 or udp port 547 ``` > Das IPv6-Standardgateway wird üblicherweise über Router Advertisements und nicht als klassische DHCPv6-Gatewayoption bezogen. Deshalb müssen DHCPv6 und Neighbor Discovery beziehungsweise Router Advertisements gemeinsam betrachtet werden.
21. Wie wird zwischen Client-, Netz- und Serverproblem unterschieden? | Beobachtung | Wahrscheinlichere Richtung | |---|---| | nur ein Client betroffen | Clientzustand, Profil, Adapter oder MAC-bezogene Policy | | alle Clients an einem Port betroffen | Port, VLAN oder lokale Infrastruktur | | alle neuen Clients eines VLANs betroffen | Relay, Scope oder Filter | | alle VLANs betroffen | DHCP-Dienst oder zentrale Infrastruktur | | bestehende Leases funktionieren | Bereich erschöpft oder Neuanfrage gestört | | DISCOVER verlässt Client nicht | Client oder Schnittstelle | | DISCOVER sichtbar, aber nicht am Relay | VLAN- oder Switchingpfad | | DISCOVER erreicht Server, kein OFFER | Server, Scope oder Policy | | OFFER verlässt Server, erreicht Client nicht | Rückweg, Relay oder Filter | | ACK erreicht Client, Konfiguration fehlt | Client übernimmt Lease nicht | | ACK enthält falsche Werte | Server-, Scope-, Policy- oder Reservierungsoption | | mehrere OFFER von unbekannten Servern | möglicher Rogue-DHCP-Server | Diese Zuordnung bildet eine Arbeitshypothese und muss durch Logs, Paketmitschnitte und Vergleichstests bestätigt werden.
22. Welche Serverprüfungen sind erforderlich? Die konkreten Befehle hängen vom DHCP-Serverprodukt ab. Unabhängig vom Produkt sollten folgende Punkte geprüft werden: 1. Läuft der DHCP-Dienst? 2. Ist der Server autorisiert beziehungsweise betrieblich freigegeben? 3. Ist der richtige Bereich aktiv? 4. Passt der Bereich zum Clientnetz? 5. Sind freie Adressen vorhanden? 6. Stimmen Präfix und Subnetzmaske? 7. Stimmen Gateway- und DNS-Optionen? 8. Existiert eine Reservierung für den Client? 9. Gibt es Ausschlussbereiche? 10. Wurde die Adresse als Konflikt markiert? 11. Greift eine Policy oder Geräteklassifizierung? 12. Sind Failover- beziehungsweise Redundanzpartner synchron? 13. Erreichen Anfragen den Server? 14. Verlässt die Antwort den Server? 15. Sind Relayinformationen korrekt? 16. Enthalten Serverlogs einen Ablehnungsgrund? **Wichtig** Die Oberfläche eines DHCP-Servers zeigt möglicherweise einen freien Bereich, während Policies, Reservierungen oder Failoverzustände die tatsächliche Vergabe beeinflussen. Die Serverprotokolle und die reale DHCP-Antwort sind deshalb ebenfalls zu prüfen.
23. Welche typischen Fehlinterpretationen müssen vermieden werden? | Beobachtung | Falscher Schluss | Richtige Einordnung | |---|---|---| | `169.254.x.x` vorhanden | Netzwerkkarte ist defekt | reguläre DHCP-Konfiguration wurde vermutlich nicht bezogen | | DHCP aktiviert | Lease ist korrekt | Server, Adresse und Optionen prüfen | | DHCPOFFER sichtbar | DHCP funktioniert vollständig | REQUEST und ACK müssen folgen | | DHCPACK sichtbar | Netzwerk funktioniert | übertragene Optionen können falsch sein | | mehrere Angebote | Angriff liegt vor | redundante Server können beabsichtigt sein | | bestehende Clients funktionieren | DHCP-Server ist gesund | nur Verlängerung oder freie Adressen können betroffen sein | | Ping zum DHCP-Server scheitert | DHCP muss scheitern | Relay und ICMP-Regeln getrennt bewerten | | Server befindet sich in anderem Netz | DHCP kann nicht funktionieren | Relay kann Broadcasts weiterleiten | | Lease wurde erneuert | Ursache wurde behoben | Fehler kann nur vorübergehend verdeckt sein | | statische Adresse funktioniert | DHCP-Fehler ist bewiesen | VLAN, Routing und Adresskonflikte bleiben möglich | | keine DHCP-Logs vorhanden | keine Anfrage wurde gesendet | falscher Logkanal oder fehlende Protokollierung möglich | | DNS funktioniert nicht | DHCP ist vollständig ausgefallen | möglicherweise nur Option 6 fehlerhaft |
24. Wie sieht der systematische Prüfablauf aus? | Schritt | Prüfung | |---:|---| | 1 | betroffene Schnittstelle und VLAN bestimmen | | 2 | vorhandene Lease vollständig sichern | | 3 | DHCP-Server, Leasezeiten und Optionen dokumentieren | | 4 | mit funktionierendem Client im selben VLAN vergleichen | | 5 | DHCP-Clientprotokolle untersuchen | | 6 | Verfügbarkeit freier Adressen serverseitig prüfen | | 7 | bei Bedarf autorisierten Paketmitschnitt vorbereiten | | 8 | DHCP-Vorgang kontrolliert reproduzieren | | 9 | DORA-Sequenz und Server-Identifier auswerten | | 10 | Relay-, Routing- und Firewallpfad kontrollieren | | 11 | Serverlogs und Scope-Konfiguration prüfen | | 12 | falsche oder fehlende Optionen bestimmen | | 13 | nur eine begründete Änderung durchführen | | 14 | neue Lease mit Ausgangswert vergleichen | | 15 | Gateway, DNS und Zielverbindung testen | | 16 | Ursache und Änderung dokumentieren | **Merksatz** ```text Lease lesen → Clientlog prüfen → DORA verfolgen → Relay prüfen → Server und Scope prüfen → kontrolliert erneuern ```
25. Kompakte Befehlsübersicht für Windows, Linux und macOS | Aufgabe | Windows | Linux | macOS | |---|---|---|---| | vollständige Konfiguration | `[RO][SENS] ipconfig /all` | `[RO] ip address show` | `[RO] ifconfig` | | DHCP-Status | `[RO] Get-NetIPInterface -AddressFamily IPv4` | `[RO] nmcli device show` | `[RO] networksetup -getinfo "DIENST"` | | Adressursprung | `[RO] Get-NetIPAddress -AddressFamily IPv4` | `[RO] nmcli connection show "NAME"` | `[RO] networksetup -getinfo "DIENST"` | | DHCP-Paketdaten | in `ipconfig /all` teilweise sichtbar | abhängig vom Netzwerkmanager | `[RO][SENS] ipconfig getpacket en0` | | Clientlogs | `[RO] Get-WinEvent -ListLog '*DHCP*'` | `[RO][PRIV] sudo journalctl -b -u NetworkManager` | `[RO] log show --last 1h --predicate 'eventMessage CONTAINS[c] "DHCP"'` | | NetworkManager-Status | nicht zutreffend | `[RO] nmcli device status` | nicht zutreffend | | networkd-Status | nicht zutreffend | `[RO] networkctl status` | nicht zutreffend | | DHCPv4-Capture | `dumpcap -f "udp port 67 or udp port 68"` | gleicher Befehl | gleicher Befehl | | DHCPv6-Capture | `dumpcap -f "udp port 546 or udp port 547"` | gleicher Befehl | gleicher Befehl | | Lease freigeben | `[PRIV][CHANGE][DISRUPT] ipconfig /release` | abhängig vom Netzwerkmanager | kein direkt gleichwertiger allgemeiner Lesebefehl | | Lease erneuern | `[PRIV][CHANGE][DISRUPT] ipconfig /renew` | Verbindung kontrolliert neu aktivieren | `[PRIV][CHANGE][DISRUPT] sudo ipconfig set en0 DHCP` | Die Platzhalter `DIENST`, `NAME`, `INTERFACE` und `en0` müssen durch die tatsächlich ermittelten Bezeichnungen ersetzt werden.
26. Dokumentationsvorlage ```text Ticketnummer: Prüfzeitpunkt: Zeitzone: Betroffener Client: Benutzer: Standort: Schnittstelle: MAC-Adresse: Switch: Switchport: VLAN: VORHANDENE KONFIGURATION DHCP aktiviert: IPv4-Adresse: Präfix/Subnetzmaske: Adresszustand: Standardgateway: DNS-Server: DNS-Suchdomäne: DHCP-Server: Lease erhalten: T1: T2: Lease läuft ab: Weitere DHCP-Optionen: ERWARTETE KONFIGURATION DHCP-Bereich: Präfix/Subnetzmaske: Standardgateway: DNS-Server: DHCP-Server: Lease-Dauer: Weitere Optionen: VERGLEICHSCLIENT Hostname: Gleiches VLAN: DHCP-Server: IPv4-Adresse: Präfix: Gateway: DNS-Server: Lease erfolgreich: Relevante Abweichungen: CLIENTPROTOKOLL Zeitpunkt: Meldung: Provider/Dienst: Ereignis-ID: PAKETABLAUF DHCPDISCOVER sichtbar: Ja / Nein DHCPOFFER sichtbar: Ja / Nein Anzahl anbietender Server: DHCPREQUEST sichtbar: Ja / Nein DHCPACK sichtbar: Ja / Nein DHCPNAK sichtbar: Ja / Nein DHCPDECLINE sichtbar: Ja / Nein Transaktions-ID: Client-Identifier: Server-Identifier: Angebotene Adresse: Übertragene Optionen: RELAY Relay erforderlich: Relayadresse: Anfrage erreicht Relay: Anfrage erreicht Server: Antwort erreicht Relay: Antwort erreicht Client: SERVER Dienststatus: Scope aktiv: Freie Adressen: Ausschlüsse: Reservierungen: Konflikte: Policy: Failoverstatus: Serverlog: Arbeitshypothese: Begründung: Gesicherter Ausgangszustand: Durchgeführter Test: Durchgeführte Änderung: Rückweg: Neue Lease: Abschlussprüfung: Ermittelte Ursache: ```
27. Offizielle Quellen und weiterführende Dokumentation **Microsoft** - [DHCP – technische Übersicht](https://learn.microsoft.com/windows-server/networking/technologies/dhcp/dhcp-top) - [DHCP-Bereitstellung und -Verwaltung](https://learn.microsoft.com/windows-server/networking/technologies/dhcp/quickstart-install-configure-dhcp-server) - [Get-NetIPInterface](https://learn.microsoft.com/powershell/module/nettcpip/get-netipinterface) - [Get-NetIPAddress](https://learn.microsoft.com/powershell/module/nettcpip/get-netipaddress) - [Get-WinEvent](https://learn.microsoft.com/powershell/module/microsoft.powershell.diagnostics/get-winevent) - [ipconfig](https://learn.microsoft.com/windows-server/administration/windows-commands/ipconfig) **Linux** - [NetworkManager nmcli](https://networkmanager.dev/docs/api/latest/nmcli.html) - [systemd-networkd](https://www.freedesktop.org/software/systemd/man/latest/systemd-networkd.service.html) - [networkctl](https://www.freedesktop.org/software/systemd/man/latest/networkctl.html) - [ip-address – Linux Manual Page](https://man7.org/linux/man-pages/man8/ip-address.8.html) **Apple** - Lokale Befehlsreferenzen: `man ipconfig`, `man networksetup`, `man scutil` und `man log` - [Ändern der TCP/IP-Einstellungen auf dem Mac](https://support.apple.com/guide/mac-help/change-tcp-ip-settings-mac-mh14129/mac) **Wireshark** - [Wireshark DHCP Display Filter Reference](https://www.wireshark.org/docs/dfref/b/bootp.html) - [dumpcap Manual Page](https://www.wireshark.org/docs/man-pages/dumpcap.html) - [tshark Manual Page](https://www.wireshark.org/docs/man-pages/tshark.html) **Standards** - [RFC 2131 – Dynamic Host Configuration Protocol](https://www.rfc-editor.org/rfc/rfc2131) - [RFC 2132 – DHCP Options](https://www.rfc-editor.org/rfc/rfc2132) - [RFC 3046 – DHCP Relay Agent Information Option](https://www.rfc-editor.org/rfc/rfc3046) - [RFC 8415 – DHCP for IPv6](https://www.rfc-editor.org/rfc/rfc8415) > DHCP-Serverbefehle und Verwaltungsoberflächen unterscheiden sich je nach Hersteller und Produkt. Änderungen an Scopes, Relays, Optionen oder Failoverkonfigurationen dürfen nur anhand der Dokumentation des tatsächlich eingesetzten Systems vorgenommen werden.
# 3.5 ARP und IPv6 Neighbor Discovery analysieren Damit ein Endgerät ein IP-Paket innerhalb eines lokalen Ethernetnetzes übertragen kann, benötigt es die zugehörige MAC-Adresse des nächsten direkten Kommunikationspartners. Bei IPv4 übernimmt diese Zuordnung das Address Resolution Protocol, kurz ARP. IPv6 verwendet dafür Neighbor Discovery, kurz NDP beziehungsweise ND, auf Basis von ICMPv6. > **Grundregel:** Für ein Ziel im lokalen Subnetz wird die MAC-Adresse des Zielsystems benötigt. Für ein Ziel in einem entfernten Subnetz wird normalerweise die MAC-Adresse des nächsten Routers benötigt – nicht die MAC-Adresse des entfernten Zielsystems. ---
1. Welche Aufgabe erfüllt ARP? ARP ordnet eine lokale IPv4-Adresse einer MAC-Adresse zu. **Beispiel im selben Subnetz** ```text CLIENT-023 IPv4: 192.0.2.23/24 MAC: 00-11-22-33-44-55 SERVER-01 IPv4: 192.0.2.80/24 MAC: AA-BB-CC-DD-EE-FF ``` Der Client kennt zunächst nur die IPv4-Adresse des Servers und sendet eine ARP-Anfrage: ```text Wer hat 192.0.2.80? Antwort bitte an 192.0.2.23. ``` Die Anfrage wird als Ethernet-Broadcast gesendet: ```text FF:FF:FF:FF:FF:FF ``` Der Server antwortet normalerweise per Unicast: ```text 192.0.2.80 befindet sich unter AA:BB:CC:DD:EE:FF. ``` Der Client kann die Zuordnung anschließend vorübergehend in seiner Nachbartabelle speichern.
2. Welche MAC-Adresse wird bei einem entfernten IPv4-Ziel aufgelöst? **Ausgangslage** ```text Client: 192.0.2.23/24 Gateway: 192.0.2.1 Ziel: 198.51.100.20 ``` Das Ziel liegt nicht im lokalen Subnetz `192.0.2.0/24`. Der Client ermittelt daher normalerweise nicht die MAC-Adresse von `198.51.100.20`, sondern die MAC-Adresse des nächsten Routers: ```text ARP-Anfrage: Wer hat 192.0.2.1? ``` Anschließend entsteht vereinfacht folgender Frame: ```text Ethernet-Ziel-MAC: MAC-Adresse des Gateways IP-Zieladresse: 198.51.100.20 ``` | Ebene | Ziel | |---|---| | Ethernet | nächster Router | | IPv4 | entferntes Zielsystem | Die Ethernetadressen können sich an jedem gerouteten Abschnitt ändern. Die IP-Zieladresse bleibt ohne NAT normalerweise bis zum Ziel bestehen.
3. Welche Symptome sprechen für ein ARP- oder Neighbor-Discovery-Problem? - Gateway ist trotz korrekter IP-Konfiguration nicht erreichbar, - Ziel im selben Subnetz ist nicht erreichbar, - Nachbareintrag bleibt unvollständig, - dieselbe IP-Adresse erscheint mit wechselnden MAC-Adressen, - Verbindung funktioniert nur sporadisch, - IP-Adresskonflikt wird gemeldet, - ARP-Anfragen werden gesendet, aber nicht beantwortet, - Neighbor Solicitation wird nicht beantwortet, - IPv6-Adresse bleibt im Zustand `tentative`, - IPv6 Duplicate Address Detection schlägt fehl, - falscher statischer Nachbareintrag ist vorhanden, - Proxy ARP oder Proxy NDP antwortet unerwartet, - Switchport befindet sich im falschen VLAN, - WLAN-Client-Isolation verhindert direkte Kommunikation, - Security-Funktion blockiert ARP- oder NDP-Nachrichten, - virtuelle Maschinen oder Container verwenden unerwartete Nachbareinträge.
4. Wie wird entschieden, ob ARP für das Ziel oder für das Gateway verwendet wird? Zuerst wird die ausgewählte Route geprüft. **Windows** ```powershell [RO] Find-NetRoute -RemoteIPAddress 198.51.100.20 ``` **Linux** ```bash [RO] ip route get 198.51.100.20 ``` **macOS** ```bash [RO] route -n get 198.51.100.20 ``` **Bewertung** | Routenergebnis | Aufzulösender direkter Nachbar | |---|---| | Ziel gilt als direkt verbunden | Ziel-IP-Adresse | | Route enthält ein Gateway beziehungsweise Next Hop | Gateway-Adresse | | Route verwendet Tunnelinterface | Verhalten abhängig vom Tunnel | | Route fehlt | keine reguläre Weiterleitung möglich | | Ziel wird fälschlich als lokal behandelt | möglicherweise falsches Präfix | Eine falsche Subnetzmaske kann dazu führen, dass ein Client ARP-Anfragen für ein eigentlich entferntes Ziel sendet.
5. Wie wird die IPv4-Nachbartabelle unter Windows angezeigt? **PowerShell** ```powershell [RO] Get-NetNeighbor -AddressFamily IPv4 ``` **Übersichtliche Darstellung** ```powershell [RO] Get-NetNeighbor -AddressFamily IPv4 | Sort-Object InterfaceIndex, IPAddress | Format-Table InterfaceAlias, InterfaceIndex, IPAddress, LinkLayerAddress, State, PolicyStore ``` **Ein bestimmter Nachbar** ```powershell [RO] Get-NetNeighbor ` -InterfaceAlias 'Ethernet' ` -IPAddress '192.0.2.1' ``` **Klassischer Befehl** ```cmd [RO] arp -a ``` Bestimmte IP-Adresse suchen: ```cmd [RO] arp -a 192.0.2.1 ``` Die PowerShell-Ausgabe zeigt zusätzlich den Zustand des Eintrags. `arp -a` unterscheidet hauptsächlich zwischen dynamischen und statischen Einträgen.
6. Welche Neighbor-Zustände zeigt Windows? Mögliche Zustände von `Get-NetNeighbor`: | Zustand | Bedeutung | |---|---| | `Unreachable` | Nachbar gilt als nicht erreichbar | | `Incomplete` | Auflösung wurde begonnen, aber noch nicht abgeschlossen | | `Probe` | Erreichbarkeit wird aktiv geprüft | | `Delay` | Prüfung wird kurz verzögert | | `Stale` | Eintrag ist vorhanden, wurde aber länger nicht bestätigt | | `Reachable` | Nachbar wurde kürzlich als erreichbar bestätigt | | `Permanent` | statischer beziehungsweise dauerhafter Eintrag | | `Unknown` | Zustand konnte nicht eindeutig bestimmt werden | Ein Eintrag im Zustand `Stale` ist nicht automatisch fehlerhaft. Er kann bei der nächsten Verwendung erneut geprüft werden. Ein dauerhaft `Incomplete` bleibender Eintrag deutet darauf hin, dass die Adressauflösung nicht erfolgreich abgeschlossen wird.
7. Wie wird die IPv4-Nachbartabelle unter Linux angezeigt? **Alle IPv4-Nachbarn** ```bash [RO] ip -4 neighbour show ``` Kurzform: ```bash [RO] ip -4 neigh ``` **Bestimmte Schnittstelle** ```bash [RO] ip -4 neighbour show dev eth0 ``` **Bestimmte IP-Adresse** ```bash [RO] ip -4 neighbour show 192.0.2.1 ``` **Änderungen live beobachten** ```bash [RO] ip monitor neigh ``` Beenden mit: ```text Strg+C ``` **Klassischer ARP-Befehl** ```bash [RO] arp -an ``` Der ältere Befehl `arp` ist nicht auf jeder Linux-Installation standardmäßig vorhanden. Für moderne Systeme ist `ip neighbour` vorzuziehen.
8. Welche Neighbor-Zustände zeigt Linux? | Zustand | Bedeutung | |---|---| | `INCOMPLETE` | Adressauflösung läuft, aber MAC-Adresse fehlt | | `REACHABLE` | Nachbar wurde kürzlich als erreichbar bestätigt | | `STALE` | Eintrag ist bekannt, Bestätigung ist aber älter | | `DELAY` | Erreichbarkeitsprüfung wird verzögert | | `PROBE` | Nachbar wird aktiv geprüft | | `FAILED` | Auflösung beziehungsweise Erreichbarkeitsprüfung ist fehlgeschlagen | | `NOARP` | für diesen Eintrag wird keine normale Nachbarauflösung durchgeführt | | `PERMANENT` | statischer, dauerhafter Eintrag | **Beispiel** ```text 192.0.2.1 dev eth0 lladdr 00:11:22:33:44:01 REACHABLE ``` | Bestandteil | Bedeutung | |---|---| | `192.0.2.1` | IPv4-Adresse des Nachbarn | | `dev eth0` | verwendete Schnittstelle | | `lladdr` | Link-Layer-Adresse folgt | | `00:11:22:33:44:01` | MAC-Adresse | | `REACHABLE` | aktueller Zustand | **Fehlgeschlagener Eintrag** ```text 192.0.2.80 dev eth0 FAILED ``` Dies bedeutet, dass die Nachbarauflösung beziehungsweise Erreichbarkeitsprüfung fehlgeschlagen ist. Die genaue Ursache kann weiterhin bei VLAN, Zielgerät, Switch, WLAN-Isolation oder Filterung liegen.
9. Wie wird die IPv4-Nachbartabelle unter macOS angezeigt? **Alle ARP-Einträge** ```bash [RO] arp -an ``` **Bestimmte IP-Adresse** ```bash [RO] arp -n 192.0.2.1 ``` **Routingtabelle mit Link-Layer-Einträgen** ```bash [RO] netstat -rn -f inet ``` Beispiel eines vollständigen Eintrags: ```text ? (192.0.2.1) at 00:11:22:33:44:01 on en0 ifscope [ethernet] ``` Beispiel eines unvollständigen Eintrags: ```text ? (192.0.2.80) at (incomplete) on en0 ifscope [ethernet] ``` Ein unvollständiger Eintrag bedeutet, dass keine verwendbare MAC-Adresse ermittelt wurde.
10. Wie wird ein Nachbareintrag kontrolliert erzeugt? Wenn noch kein Eintrag vorhanden ist, kann eine normale Kommunikation zum direkten Nachbarn die Auflösung auslösen. **Windows** ```powershell [TEST] Test-Connection 192.0.2.1 -Count 1 ``` Danach: ```powershell [RO] Get-NetNeighbor ` -InterfaceAlias 'Ethernet' ` -IPAddress '192.0.2.1' ``` **Linux** ```bash [TEST] ping -c 1 192.0.2.1 ``` Danach: ```bash [RO] ip neighbour show 192.0.2.1 ``` **macOS** ```bash [TEST] ping -c 1 192.0.2.1 ``` Danach: ```bash [RO] arp -n 192.0.2.1 ``` Auch wenn das Ziel ICMP nicht beantwortet, kann durch die lokale Zustellung ein ARP-Eintrag entstehen. Voraussetzung ist, dass das Betriebssystem das Ziel als direkten Nachbarn behandelt.
11. Wie wird ARP mit arping aktiv geprüft? `arping` sendet aktive ARP-Anfragen auf einer lokalen Ethernetverbindung. Das Werkzeug ist nicht unter jedem Betriebssystem standardmäßig vorhanden. **Linux-Beispiel** ```bash [TEST][PRIV] sudo arping \ -I eth0 \ -c 4 \ 192.0.2.1 ``` | Option | Bedeutung | |---|---| | `-I eth0` | Schnittstelle | | `-c 4` | vier Anfragen | | Zieladresse | direkt zu prüfende lokale IPv4-Adresse | **Einsatzmöglichkeiten** - direkte lokale Erreichbarkeit prüfen, - Antwort-MAC-Adresse bestimmen, - erkennen, ob mehrere Geräte antworten, - ARP unabhängig von ICMP testen. **Einschränkungen** - funktioniert nur für direkt erreichbare IPv4-Nachbarn, - prüft kein geroutetes entferntes Ziel, - kann Sicherheitsüberwachung auslösen, - verschiedene `arping`-Implementierungen besitzen unterschiedliche Optionen, - eine Antwort beweist nicht die Funktion höherer Protokolle. Vor der Verwendung muss die lokale Syntax geprüft werden: ```bash [RO] arping --help ``` oder: ```bash [RO] man arping ```
12. Wie wird ARP mit Wireshark oder TShark untersucht? **Wireshark-Display-Filter** ```text arp ``` Nur Anfragen: ```text arp.opcode == 1 ``` Nur Antworten: ```text arp.opcode == 2 ``` Bestimmte IPv4-Adresse: ```text arp.src.proto_ipv4 == 192.0.2.1 || arp.dst.proto_ipv4 == 192.0.2.1 ``` **Capture-Filter** ```text arp ``` **TShark-Liveanzeige** ```bash [TEST][PRIV][SENS] tshark \ -i INTERFACE \ -f "arp" ``` **Zeitlich begrenzte Aufnahme** ```bash [TEST][PRIV][FILE][SENS] dumpcap \ -i INTERFACE \ -f "arp" \ -a duration:30 \ -w arp-diagnose.pcapng ``` **ARP-Felder anzeigen** ```bash [RO][SENS] tshark \ -r arp-diagnose.pcapng \ -Y "arp" \ -T fields \ -e frame.time \ -e eth.src \ -e eth.dst \ -e arp.opcode \ -e arp.src.proto_ipv4 \ -e arp.src.hw_mac \ -e arp.dst.proto_ipv4 \ -e arp.dst.hw_mac ``` Die lokal verfügbaren Feldnamen können geprüft werden: ```bash [RO] tshark -G fields | grep -E $'\tarp\.' ```
13. Wie wird eine erfolglose ARP-Auflösung im Paketmitschnitt erkannt? Typisches Muster: ```text Client → Broadcast: Who has 192.0.2.80? Client → Broadcast: Who has 192.0.2.80? Client → Broadcast: Who has 192.0.2.80? Keine Antwort ``` Mögliche Ursachen: - Zielsystem ist ausgeschaltet, - Ziel besitzt eine andere IP-Adresse, - Ziel befindet sich nicht im selben VLAN, - Client befindet sich im falschen VLAN, - Switchport ist falsch konfiguriert, - WLAN-Client-Isolation ist aktiv, - Layer-2-Sicherheitsmechanismus blockiert den Verkehr, - falsche Subnetzmaske lässt ein entferntes Ziel lokal erscheinen, - virtuelle Bridge oder Netzwerkschnittstelle ist falsch verbunden, - Ziel antwortet aufgrund eines lokalen Netzwerkproblems nicht. **Wichtiger Gegencheck** Wenn der Client ARP für eine entfernte Zieladresse sendet, muss zuerst Präfix und Route geprüft werden. Die Ursache liegt dann möglicherweise nicht bei ARP, sondern in einer falschen Subnetzkonfiguration.
14. Was ist Gratuitous ARP? Gratuitous ARP ist eine ARP-Nachricht, bei der ein Gerät eine eigene IPv4-/MAC-Zuordnung ohne vorherige normale Anfrage bekannt gibt oder prüft. Mögliche Zwecke: - Erkennung eines Adresskonflikts, - Aktualisierung von Nachbartabellen, - Übernahme einer virtuellen IP-Adresse, - Hochverfügbarkeits-Failover, - Mitteilung nach einem MAC- oder Portwechsel, - Aktualisierung von Switch- und Hostinformationen. **Typisches Szenario** ```text Firewall A besitzt virtuelle IP 192.0.2.1. Firewall A fällt aus. Firewall B übernimmt 192.0.2.1. Firewall B sendet Gratuitous ARP mit ihrer MAC-Adresse. ``` Clients sollen dadurch die neue Zuordnung lernen. Viele Gratuitous-ARP-Nachrichten sind nicht automatisch schädlich. Sie müssen im Zusammenhang mit Hochverfügbarkeit, Clusterbetrieb, Virtualisierung und Adresskonflikten bewertet werden.
15. Was ist Proxy ARP? Beim Proxy ARP antwortet ein Gerät auf eine ARP-Anfrage für eine andere IPv4-Adresse mit seiner eigenen MAC-Adresse. Vereinfacht: ```text Client fragt: Wer hat 192.0.2.80? Router antwortet: 192.0.2.80 befindet sich unter meiner MAC-Adresse. ``` Der Router übernimmt anschließend die Weiterleitung zum eigentlichen Ziel. Proxy ARP kann bewusst eingesetzt werden, beispielsweise für bestimmte Netzdesigns oder Übergangslösungen. Es kann aber auch Fehlkonfigurationen verbergen. **Hinweise auf Proxy ARP** - mehrere IP-Adressen werden derselben Router-MAC zugeordnet, - ein vermeintlich lokales Ziel wird über einen Router erreicht, - Kommunikation funktioniert trotz ungewöhnlicher Subnetzkonfiguration, - Paketmitschnitt zeigt Antworten eines Routers für fremde IP-Adressen. Proxy ARP darf nicht ohne Prüfung der Netzwerkarchitektur als Angriff oder Fehlfunktion bewertet werden.
16. Welche Aufgabe erfüllt IPv6 Neighbor Discovery? IPv6 verwendet kein ARP. Neighbor Discovery arbeitet mit ICMPv6 und übernimmt mehrere Funktionen: - Auflösung von IPv6-Adresse zu MAC-Adresse, - Erreichbarkeitsprüfung von Nachbarn, - Routererkennung, - Präfixinformationen, - Duplicate Address Detection, - Weiterleitung auf einen besseren Router, - teilweise automatische Adresskonfiguration. Wichtige ICMPv6-Nachrichten: | Typ | Nachricht | Aufgabe | |---:|---|---| | 133 | Router Solicitation | Client fordert Routerinformationen an | | 134 | Router Advertisement | Router teilt Präfixe und Parameter mit | | 135 | Neighbor Solicitation | Nachbarauflösung oder Erreichbarkeitsprüfung | | 136 | Neighbor Advertisement | Antwort beziehungsweise Ankündigung eines Nachbarn | | 137 | Redirect | Router weist auf einen besseren nächsten Hop hin | NDP verwendet Multicast statt des aus IPv4 bekannten Broadcasts.
17. Wie funktioniert die IPv6-Nachbarauflösung? Vereinfachter Ablauf: ```text Client IPv6-Nachbar │ │ │──── Neighbor Solicitation ───────────────>│ │<─── Neighbor Advertisement ───────────────│ │ │ ``` Die Neighbor Solicitation wird normalerweise an eine zur Zieladresse gehörende Solicited-Node-Multicast-Adresse gesendet. **Wichtiger Unterschied zu ARP** | IPv4 | IPv6 | |---|---| | ARP | ICMPv6 Neighbor Discovery | | Ethernet-Broadcast | IPv6-Multicast | | separate ARP-Nachricht | Teil von ICMPv6 | | ARP-Tabelle | IPv6-Nachbartabelle | ICMPv6 darf nicht pauschal blockiert werden. Viele ICMPv6-Nachrichten sind für die grundlegende IPv6-Funktion erforderlich.
18. Wie wird die IPv6-Nachbartabelle unter Windows angezeigt? ```powershell [RO] Get-NetNeighbor -AddressFamily IPv6 ``` Übersicht: ```powershell [RO] Get-NetNeighbor -AddressFamily IPv6 | Sort-Object InterfaceIndex, IPAddress | Format-Table InterfaceAlias, InterfaceIndex, IPAddress, LinkLayerAddress, State ``` Bestimmte Link-Local-Adresse: ```powershell [RO] Get-NetNeighbor ` -InterfaceAlias 'Ethernet' ` -IPAddress 'fe80::1' ``` Bei Link-Local-Adressen ist die Schnittstelle beziehungsweise Scope-ID entscheidend, da `fe80::/10` auf mehreren Interfaces verwendet werden kann. **Alternative klassische Anzeige** ```cmd [RO] netsh interface ipv6 show neighbors ```
19. Wie wird die IPv6-Nachbartabelle unter Linux angezeigt? **Alle IPv6-Nachbarn** ```bash [RO] ip -6 neighbour show ``` **Bestimmte Schnittstelle** ```bash [RO] ip -6 neighbour show dev eth0 ``` **Bestimmte Adresse** ```bash [RO] ip -6 neighbour show 2001:db8:20::20 ``` **Änderungen beobachten** ```bash [RO] ip monitor neigh ``` **Router und Standardroute** ```bash [RO] ip -6 route show default ``` **IPv6-Adressen und deren Zustand** ```bash [RO] ip -6 address show dev eth0 ``` Auf folgende Zustände achten: ```text tentative dadfailed deprecated ``` `dadfailed` weist darauf hin, dass Duplicate Address Detection für diese Adresse fehlgeschlagen ist.
20. Wie wird die IPv6-Nachbartabelle unter macOS angezeigt? **IPv6-Nachbartabelle** ```bash [RO] ndp -an ``` **Bestimmten Nachbarn anzeigen** ```bash [RO] ndp -n fe80::1%en0 ``` Die Schnittstellenangabe `%en0` ist bei Link-Local-Adressen häufig erforderlich. **IPv6-Routingtabelle** ```bash [RO] netstat -rn -f inet6 ``` **IPv6-Konfiguration einer Schnittstelle** ```bash [RO] ifconfig en0 ``` Zu prüfen sind: - Link-Local-Adresse, - globale beziehungsweise interne IPv6-Adressen, - Präfixlängen, - Adresszustände, - Standardrouter, - Nachbareinträge und deren MAC-Adressen.
21. Wie wird IPv6 Neighbor Discovery mit Wireshark untersucht? **Alle Neighbor-Discovery-Nachrichten** ```text icmpv6.type >= 133 && icmpv6.type <= 137 ``` **Router Solicitation** ```text icmpv6.type == 133 ``` **Router Advertisement** ```text icmpv6.type == 134 ``` **Neighbor Solicitation** ```text icmpv6.type == 135 ``` **Neighbor Advertisement** ```text icmpv6.type == 136 ``` **Redirect** ```text icmpv6.type == 137 ``` **Bestimmte IPv6-Adresse** ```text ipv6.addr == 2001:db8:20::20 ``` **Capture-Filter für relevante ICMPv6-Nachrichten** ```text icmp6 ``` **Zeitlich begrenzte Aufnahme** ```bash [TEST][PRIV][FILE][SENS] dumpcap \ -i INTERFACE \ -f "icmp6" \ -a duration:30 \ -w ipv6-nd.pcapng ``` **TShark-Auswertung** ```bash [RO][SENS] tshark \ -r ipv6-nd.pcapng \ -Y "icmpv6.type >= 133 && icmpv6.type <= 137" \ -T fields \ -e frame.time \ -e eth.src \ -e eth.dst \ -e ipv6.src \ -e ipv6.dst \ -e icmpv6.type ```
22. Was ist Duplicate Address Detection bei IPv6? Bevor eine neue IPv6-Adresse regulär verwendet wird, prüft der Host normalerweise, ob sie bereits auf dem lokalen Link verwendet wird. Vereinfacht: ```text Neuer Host → Neighbor Solicitation für die eigene geplante Adresse → keine widersprechende Antwort: Adresse kann verwendet werden ``` Antwortet ein anderes Gerät, kann die Adresse als doppelt erkannt werden. **Mögliche Zustände** | Zustand | Bedeutung | |---|---| | `tentative` | Prüfung läuft | | `preferred` | Adresse kann normal verwendet werden | | `deprecated` | Adresse wird nicht mehr für neue Verbindungen bevorzugt | | `dadfailed` beziehungsweise `Duplicate` | Konflikt erkannt | **Mögliche Ursachen eines DAD-Fehlers** - tatsächlich doppelte statische IPv6-Adresse, - fehlerhafte virtuelle Netzwerkkonfiguration, - Loop oder reflektierte Pakete, - fehlerhaftes Proxy-NDP-Verhalten, - duplizierte virtuelle Maschine mit identischer Konfiguration, - Sicherheitsgerät beantwortet Anfragen unerwartet. Ein DAD-Fehler darf nicht durch dauerhaftes Abschalten der Konflikterkennung verdeckt werden.
23. Wie werden Router Advertisements in die Diagnose einbezogen? Router Advertisements können unter anderem mitteilen: - verfügbare Router, - Präfixinformationen, - Präfixlänge, - Gültigkeitsdauer, - bevorzugte Dauer, - ob SLAAC verwendet werden kann, - Hinweise auf DHCPv6, - MTU, - Routeninformationen, - weitere IPv6-Parameter. **Typische Fehlerbilder** - Client erhält nur Link-Local-Adresse, - IPv6-Standardroute fehlt, - falsches Präfix wird angekündigt, - nicht autorisierter Router sendet Advertisements, - mehrere Router kündigen widersprüchliche Informationen an, - Router Advertisement erreicht bestimmte VLANs nicht, - ICMPv6 wird gefiltert, - Präfix ist abgelaufen oder falsch konfiguriert. **Windows-Routen** ```powershell [RO] Get-NetRoute -AddressFamily IPv6 ``` **Linux** ```bash [RO] ip -6 route ``` **macOS** ```bash [RO] netstat -rn -f inet6 ``` Ein vorhandener DHCPv6-Server ersetzt nicht automatisch die Router Advertisements für die Standardrouterinformation.
24. Warum dürfen Nachbartabellen nicht vorschnell geleert werden? Das Leeren einer Nachbartabelle: - verändert den Diagnosezustand, - entfernt möglicherweise den Beleg einer falschen Zuordnung, - erzwingt neue ARP- oder NDP-Auflösungen, - kann Verbindungen kurzfristig unterbrechen, - behebt eine falsche Zuordnung möglicherweise nur vorübergehend, - beseitigt nicht die eigentliche Ursache. Vorher sollten gespeichert werden: **Windows** ```powershell [RO][FILE][SENS] Get-NetNeighbor | Export-Csv 'C:\Temp\nachbartabelle-vorher.csv' ` -NoTypeInformation ` -Encoding UTF8 ``` **Linux** ```bash [RO][FILE][SENS] ip neighbour show \ > /tmp/nachbartabelle-vorher.txt ``` **macOS** ```bash [RO][FILE][SENS] arp -an \ > /tmp/arp-vorher.txt ``` ```bash [RO][FILE][SENS] ndp -an \ > /tmp/ndp-vorher.txt ``` Die Speicherorte müssen den betrieblichen Datenschutz- und Sicherheitsvorgaben entsprechen.
25. Welche eingreifenden Befehle existieren? **Windows – IPv4-Nachbartabelle leeren** ```cmd [PRIV][CHANGE][DISRUPT] netsh interface ip delete arpcache ``` **Linux – dynamische IPv4-Nachbarn einer Schnittstelle leeren** ```bash [PRIV][CHANGE][DISRUPT] sudo ip -4 neighbour flush dev eth0 ``` **Linux – IPv6-Nachbarn einer Schnittstelle leeren** ```bash [PRIV][CHANGE][DISRUPT] sudo ip -6 neighbour flush dev eth0 ``` **macOS – einzelnen ARP-Eintrag entfernen** ```bash [PRIV][CHANGE][DISRUPT] sudo arp -d 192.0.2.1 ``` **macOS – einzelnen IPv6-Nachbareintrag entfernen** ```bash [PRIV][CHANGE][DISRUPT] sudo ndp -d fe80::1%en0 ``` > Diese Befehle sind keine ersten Diagnoseschritte. Bei Remotezugriff kann insbesondere das Entfernen des Gatewayeintrags die aktive Verbindung kurzfristig beeinträchtigen. Syntax und unterstützte Optionen müssen lokal mit der jeweiligen Hilfeseite geprüft werden.
26. Wie werden statische Nachbareinträge bewertet? Statische Einträge können bewusst eingerichtet sein, beispielsweise für: - besondere Appliances, - Hochverfügbarkeitslösungen, - Sicherheitskonzepte, - Testumgebungen, - feste Nachbarzuordnungen. Sie können jedoch veraltet sein, wenn: - Netzwerkkarte ersetzt wurde, - virtuelle Maschine verschoben wurde, - Failover stattgefunden hat, - Gerät eine neue MAC-Adresse verwendet, - Netzwerkarchitektur geändert wurde. **Windows** ```powershell [RO] Get-NetNeighbor | Where-Object State -eq 'Permanent' ``` **Linux** ```bash [RO] ip neighbour show nud permanent ``` **macOS** ```bash [RO] arp -an ``` Statische Einträge dürfen nicht gelöscht werden, bevor Eigentümer, Zweck, Konfigurationsquelle und Rückweg geklärt sind.
27. Wie werden ARP-Spoofing und Neighbor-Discovery-Manipulation erkannt? Mögliche Hinweise: - Gateway-IP wechselt unerwartet zwischen MAC-Adressen, - eine fremde MAC-Adresse beansprucht viele IP-Adressen, - unerwartete Gratuitous-ARP-Nachrichten, - nicht autorisierte Router Advertisements, - mehrere Geräte antworten auf dieselbe Adresse, - Verbindung wird über ein unbekanntes Gerät umgeleitet, - Zertifikatswarnungen treten gleichzeitig auf, - Netzwerküberwachung meldet Dynamic-ARP-Inspection- oder RA-Guard-Verstöße. **Sicheres Vorgehen** 1. aktuelle Nachbartabelle sichern, 2. Zeitpunkt dokumentieren, 3. Switch-MAC-Tabelle und Portzuordnung prüfen, 4. DHCP- und Netzwerkdokumentation vergleichen, 5. Paketmitschnitt nur mit Freigabe erstellen, 6. Hochverfügbarkeits- und Proxyfunktionen ausschließen, 7. Informationssicherheit einbeziehen, 8. verdächtiges Gerät nicht unkoordiniert verändern. Eine gemeinsame MAC-Adresse für mehrere IP-Adressen ist nicht automatisch ein Angriff. Router, Load Balancer, Firewalls, Proxy ARP und Cluster können dieses Muster beabsichtigt erzeugen.
28. Wie wird zwischen Client-, VLAN- und Zielproblem unterschieden? | Beobachtung | Wahrscheinlichere Richtung | |---|---| | nur ein Client erhält keine ARP-Antwort | Client, Port oder lokale Sicherheitsregel | | mehrere Clients im VLAN betroffen | VLAN, Switch oder Zielsystem | | andere VLANs erreichen das Ziel | betroffenes VLAN oder Gatewayinterface | | ARP-Anfrage verlässt Client nicht | Clientstack oder Schnittstelle | | Anfrage sichtbar, Antwort fehlt | Ziel, VLAN-Pfad oder Filter | | Antwort erreicht Switch, aber nicht Client | Port, WLAN oder Sicherheitsfunktion | | falsche MAC antwortet | Proxy, Konflikt oder Manipulation | | Gateway wird aufgelöst, Ziel nicht erreichbar | Problem liegt wahrscheinlich nach Layer 2 | | Ziel wird fälschlich per ARP gesucht | falsches Präfix oder falsche Route | | IPv6 NS ohne NA | Ziel, VLAN, Filter oder NDP-Konfiguration | | nur IPv6 betroffen | ICMPv6, RA, NDP oder IPv6-VLAN-Pfad |
29. Welche typischen Fehlinterpretationen müssen vermieden werden? | Beobachtung | Falscher Schluss | Richtige Einordnung | |---|---|---| | ARP-Tabelle ist leer | Netzwerk ist defekt | möglicherweise wurde noch kein lokaler Nachbar angesprochen | | Eintrag ist `Stale` | Ziel ist nicht erreichbar | Eintrag wird bei Nutzung erneut geprüft | | Eintrag ist `Incomplete` | Ziel ist ausgeschaltet | VLAN, Präfix und Filter bleiben mögliche Ursachen | | entfernte Ziel-IP fehlt in ARP | Fehler liegt vor | nur der lokale Next Hop wird benötigt | | viele IPs haben dieselbe MAC | Angriff | Router, Proxy ARP oder Cluster möglich | | MAC-Adresse wechselt | Angriff | Failover oder Gerätewechsel möglich | | Ping funktioniert nicht | ARP funktioniert nicht | Nachbartabelle getrennt prüfen | | ARP funktioniert | Anwendung funktioniert | nur lokale Adressauflösung bestätigt | | IPv6 hat keine ARP-Tabelle | IPv6 benötigt keine Auflösung | IPv6 verwendet NDP | | ICMPv6 wird blockiert | nur Ping ist betroffen | zentrale IPv6-Funktionen können ausfallen | | Nachbartabelle wurde geleert und es funktioniert | Ursache wurde behoben | Problem kann nur vorübergehend verdeckt sein | | Gratuitous ARP sichtbar | Manipulation | Konfliktprüfung oder Failover möglich |
30. Wie sieht der systematische Prüfablauf aus? | Schritt | Prüfung | |---:|---| | 1 | IP-Adresse und Präfix des Clients bestätigen | | 2 | ausgewählte Route zum Ziel bestimmen | | 3 | direkt aufzulösenden Nachbarn identifizieren | | 4 | vorhandene Nachbartabelle unverändert sichern | | 5 | Zustand und MAC-Adresse des Eintrags prüfen | | 6 | mit funktionierendem Referenzclient vergleichen | | 7 | normale Kommunikation zum direkten Nachbarn auslösen | | 8 | Nachbartabelle erneut prüfen | | 9 | bei Bedarf ARP beziehungsweise NDP kontrolliert mitschneiden | | 10 | Anfrage und Antwort auf Client- und Netzseite verfolgen | | 11 | Switchport, VLAN und MAC-Zuordnung prüfen | | 12 | Proxy-, Cluster- und Hochverfügbarkeitsfunktionen berücksichtigen | | 13 | Konflikt oder Manipulationsverdacht eskalieren | | 14 | Tabelle nur nach Beweissicherung gezielt verändern | | 15 | ursprüngliches Fehlerbild erneut testen | | 16 | Ursache und Ergebnis dokumentieren | **Merksatz** ```text Route bestimmen → direkten Nachbarn bestimmen → Tabelle prüfen → Anfrage verfolgen → Antwort verfolgen ```
31. Kompakte Befehlsübersicht für Windows, Linux und macOS | Aufgabe | Windows | Linux | macOS | |---|---|---|---| | IPv4-Nachbarn | `[RO] Get-NetNeighbor -AddressFamily IPv4` | `[RO] ip -4 neighbour` | `[RO] arp -an` | | IPv6-Nachbarn | `[RO] Get-NetNeighbor -AddressFamily IPv6` | `[RO] ip -6 neighbour` | `[RO] ndp -an` | | einzelner IPv4-Nachbar | `[RO] Get-NetNeighbor -IPAddress ZIEL` | `[RO] ip neighbour show ZIEL` | `[RO] arp -n ZIEL` | | einzelne IPv6-Adresse | `[RO] Get-NetNeighbor -IPAddress ZIEL` | `[RO] ip -6 neighbour show ZIEL` | `[RO] ndp -n ZIEL%INTERFACE` | | Route zum Ziel | `[RO] Find-NetRoute -RemoteIPAddress ZIEL` | `[RO] ip route get ZIEL` | `[RO] route -n get ZIEL` | | Nachbaränderungen live | PowerShell wiederholt abfragen | `[RO] ip monitor neigh` | wiederholt `arp` beziehungsweise `ndp` | | ARP aktiv testen | normales `Test-Connection` | `[TEST][PRIV] sudo arping -I INTERFACE -c 4 ZIEL` | abhängig von installiertem Werkzeug | | ARP mitschneiden | `[TEST][PRIV][SENS] tshark -i INTERFACE -f "arp"` | gleicher Befehl | gleicher Befehl | | NDP mitschneiden | `[TEST][PRIV][SENS] tshark -i INTERFACE -f "icmp6"` | gleicher Befehl | gleicher Befehl | | ARP-Cache leeren | `[PRIV][CHANGE][DISRUPT] netsh interface ip delete arpcache` | `[PRIV][CHANGE][DISRUPT] sudo ip -4 neigh flush dev INTERFACE` | `[PRIV][CHANGE][DISRUPT] sudo arp -d ZIEL` | | IPv6-Nachbarn leeren | nur gezielt nach lokaler Dokumentation | `[PRIV][CHANGE][DISRUPT] sudo ip -6 neigh flush dev INTERFACE` | `[PRIV][CHANGE][DISRUPT] sudo ndp -d ZIEL%INTERFACE` | Die Platzhalter `ZIEL` und `INTERFACE` müssen durch vorher eindeutig bestimmte Werte ersetzt werden.
32. Dokumentationsvorlage ```text Ticketnummer: Prüfzeitpunkt: Zeitzone: Betroffener Client: Betriebssystem: Schnittstelle: MAC-Adresse: VLAN: IP-KONFIGURATION Client-IPv4: IPv4-Präfix: Client-IPv6: IPv6-Präfix: Standardgateway IPv4: Standardrouter IPv6: ZIEL Zielname: Ziel-IPv4: Ziel-IPv6: Ziel laut Präfix lokal: Ja / Nein Ausgewählte Route: Ausgewählte Quelladresse: Next Hop: Direkt aufzulösender Nachbar: NACHBARTABELLE VOR DEM TEST IPv4-Nachbar: MAC-Adresse: Schnittstelle: Zustand: Dynamisch oder statisch: IPv6-Nachbar: MAC-Adresse: Schnittstelle: Zustand: Dynamisch oder statisch: AKTIVER TEST Verwendeter Test: Startzeit: Endzeit: Anfragen gesendet: Antworten empfangen: PAKETMITSCHNITT ARP Request sichtbar: ARP Reply sichtbar: Neighbor Solicitation sichtbar: Neighbor Advertisement sichtbar: Router Advertisement sichtbar: Quell-MAC: Antwort-MAC: Mehrere Antworten: Gratuitous ARP: Proxy ARP vermutet: DAD fehlgeschlagen: NETZWERKSEITE Switch: Switchport: Port-VLAN: Gelernte Client-MAC: Gelernte Ziel-MAC: MAC wechselt zwischen Ports: Port-Security-Ereignisse: ARP-/NDP-Schutzereignisse: REFERENZCLIENT Hostname: Gleiches VLAN: Nachbar-IP: Nachbar-MAC: Nachbarzustand: Relevante Abweichungen: Arbeitshypothese: Begründung: Originaltabelle gesichert: Durchgeführte Änderung: Rückweg: Abschlussprüfung: Ermittelte Ursache: Sicherheitseskalation erforderlich: Ja / Nein ```
33. Offizielle Quellen und weiterführende Dokumentation **Microsoft** - [Get-NetNeighbor](https://learn.microsoft.com/powershell/module/nettcpip/get-netneighbor) - [Find-NetRoute](https://learn.microsoft.com/powershell/module/nettcpip/find-netroute) - [netsh interface](https://learn.microsoft.com/windows-server/administration/windows-commands/netsh-interface) - [IPv6 Neighbor Discovery](https://learn.microsoft.com/windows-server/networking/technologies/ipv6/ipv6-top) **Linux** - [ip-neighbour – Linux Manual Page](https://man7.org/linux/man-pages/man8/ip-neighbour.8.html) - [ip-monitor – Linux Manual Page](https://man7.org/linux/man-pages/man8/ip-monitor.8.html) - [ip-route – Linux Manual Page](https://man7.org/linux/man-pages/man8/ip-route.8.html) - Lokale Befehlsreferenz: `man arping` **Apple** - Lokale Befehlsreferenzen: `man arp`, `man ndp`, `man route`, `man netstat` und `man ifconfig` **Wireshark** - [ARP Display Filter Reference](https://www.wireshark.org/docs/dfref/a/arp.html) - [ICMPv6 Display Filter Reference](https://www.wireshark.org/docs/dfref/i/icmpv6.html) - [dumpcap Manual Page](https://www.wireshark.org/docs/man-pages/dumpcap.html) - [tshark Manual Page](https://www.wireshark.org/docs/man-pages/tshark.html) **Standards** - [RFC 826 – Address Resolution Protocol](https://www.rfc-editor.org/rfc/rfc826) - [RFC 5227 – IPv4 Address Conflict Detection](https://www.rfc-editor.org/rfc/rfc5227) - [RFC 4861 – Neighbor Discovery for IPv6](https://www.rfc-editor.org/rfc/rfc4861) - [RFC 4862 – IPv6 Stateless Address Autoconfiguration](https://www.rfc-editor.org/rfc/rfc4862) - [RFC 6980 – Security Implications of IPv6 Fragmentation with NDP](https://www.rfc-editor.org/rfc/rfc6980) > Nachbarzustände, Zeitlimits und verfügbare Diagnosefelder hängen vom Betriebssystem, Treiber und Netzwerkdesign ab. Eine fehlende Antwort muss immer zusammen mit Route, Präfix, VLAN und tatsächlichem Messpunkt bewertet werden.
# 3.6 VLAN- und Layer-2-Fehler analysieren Virtual LANs teilen eine physische Switchinfrastruktur in getrennte logische Layer-2-Netze. Geräte in unterschiedlichen VLANs können nicht allein über Switching miteinander kommunizieren. Für die Kommunikation zwischen VLANs ist normalerweise ein Router oder eine Layer-3-Switch-Funktion erforderlich. VLAN-Fehler können dazu führen, dass ein Endgerät zwar einen aktiven Link besitzt, aber keine passende DHCP-Adresse erhält, sein Gateway nicht erreicht oder im falschen logischen Netz landet. > **Grundregel:** Linkstatus und VLAN-Zugehörigkeit sind getrennte Eigenschaften. Ein Switchport kann physisch aktiv und gleichzeitig logisch dem falschen VLAN zugeordnet sein. ---
1. Welche Aufgaben erfüllt ein VLAN? Ein VLAN bildet eine eigene Layer-2-Broadcast-Domain. ```text Physischer Switch ├─ VLAN 10 – Verwaltung ├─ VLAN 20 – Clients ├─ VLAN 30 – VoIP ├─ VLAN 40 – Server └─ VLAN 50 – Gäste ``` Innerhalb eines VLANs werden unter anderem folgende Nachrichten verteilt: - Ethernet-Broadcasts, - ARP-Anfragen, - bestimmte IPv4-Broadcasts, - relevante IPv6-Multicasts, - DHCP-Broadcasts vor einem Relay. Ein Router trennt normalerweise die Broadcast-Domains und vermittelt bei Bedarf zwischen den VLANs. **Beispiel** ```text CLIENT-023 in VLAN 20 192.0.2.23/24 SERVER-01 in VLAN 40 198.51.100.20/24 ``` Die Kommunikation benötigt: ```text VLAN 20 → Gateway für VLAN 20 → Layer-3-Routing und mögliche Firewallregeln → Gateway beziehungsweise Interface für VLAN 40 → VLAN 40 ```
2. Was ist der Unterschied zwischen Access-Port und Trunk? | Porttyp | Typischer Einsatz | Verhalten | |---|---|---| | Access-Port | normales Endgerät | gehört normalerweise zu einem ungetaggten VLAN | | Trunk | Verbindung zwischen Switches, Routern, Servern oder Access Points | transportiert mehrere VLANs | | Hybrid-/General-Port | herstellerabhängige Mischform | kombiniert getaggte und ungetaggte VLANs | | Routed Port | Layer-3-Verbindung | arbeitet nicht als gewöhnlicher Switchport | **Access-Port** ```text Client │ ungetaggter Ethernetframe ▼ Switchport als Access-Port in VLAN 20 ``` Der Client muss normalerweise keine VLAN-ID kennen. Der Switch ordnet eingehende ungetaggte Frames dem konfigurierten Access-VLAN zu. **Trunk** ```text Switch A │ VLAN 10 getaggt │ VLAN 20 getaggt │ VLAN 40 getaggt ▼ Switch B ``` Die VLAN-Zugehörigkeit wird bei IEEE 802.1Q über einen VLAN-Tag im Ethernetframe transportiert.
3. Welche Informationen enthält ein IEEE-802.1Q-Tag? Ein 802.1Q-Tag enthält unter anderem: | Feld | Bedeutung | |---|---| | PCP | Prioritätsinformation nach IEEE 802.1p | | DEI | Drop Eligible Indicator | | VLAN ID | VLAN-Kennung | Die VLAN-ID besitzt 12 Bit. Dadurch sind Werte von 0 bis 4095 darstellbar. Die Randwerte sind reserviert beziehungsweise besitzen Sonderbedeutungen; für reguläre VLAN-Zuordnungen werden typischerweise VLAN-IDs 1 bis 4094 verwendet. **Vereinfachter Ethernetframe** ```text Ohne VLAN-Tag: Ziel-MAC Quell-MAC EtherType Nutzdaten FCS ``` ```text Mit 802.1Q-Tag: Ziel-MAC Quell-MAC 802.1Q-Tag EtherType Nutzdaten FCS ``` Der zusätzliche Tag vergrößert den Ethernetframe um vier Byte. Geräte und Netzwerkpfade müssen entsprechend kompatibel sein.
4. Welche Symptome sprechen für einen VLAN-Fehler? - Client erhält keine DHCP-Adresse, - Client erhält eine Adresse aus dem falschen Subnetz, - Gateway ist nicht erreichbar, - nur Geräte an einem Switchport sind betroffen, - ein Gerät funktioniert an einem anderen Port, - gleiche SSID führt an verschiedenen Access Points in unterschiedliche Netze, - Voice-Telefon funktioniert, angeschlossener PC jedoch nicht, - bestimmte VLANs funktionieren über einen Uplink nicht, - Server ist lokal erreichbar, aber nicht über andere Switches, - ungetaggter Verkehr funktioniert, getaggter Verkehr nicht, - virtuelle Maschine befindet sich im falschen Netz, - Container- oder Hypervisorbridge transportiert das VLAN nicht, - VLAN funktioniert nur in eine Richtung, - nach einer Switchänderung fallen mehrere Geräte eines VLANs aus, - Spanning Tree blockiert den erwarteten Pfad, - Port-Security verhindert den Verkehr, - MAC-Adresse wird an einem unerwarteten Port gelernt, - Native-VLAN-Konfiguration unterscheidet sich zwischen zwei Seiten.
5. Welche Informationen müssen vor einer VLAN-Analyse bekannt sein? | Information | Beispiel | |---|---| | Clienthostname | `CLIENT-023` | | Client-MAC-Adresse | `00-11-22-33-44-55` | | Switch | `SW-ACCESS-01` | | Switchport | Port 17 | | vorgesehene VLAN-ID | 20 | | Portmodus | Access | | erwartetes Subnetz | `192.0.2.0/24` | | erwartetes Gateway | `192.0.2.1` | | erwarteter DHCP-Server beziehungsweise Relay | dokumentierte Infrastruktur | | nächster Uplink | `SW-CORE-01` | | Fehlerbeginn | `2026-07-31 09:42 CEST` | | letzte Änderung | Portkonfiguration wurde angepasst | Bei einem Trunk zusätzlich: - erlaubte VLANs, - ungetaggtes beziehungsweise natives VLAN, - Tagging auf beiden Seiten, - LAG- beziehungsweise Port-Channel-Zugehörigkeit, - Spanning-Tree-Zustand je VLAN, - Uplinkpfad zum Ziel.
6. Wie wird ein Access-Port systematisch geprüft? Auf der Switchseite sollten mindestens folgende Eigenschaften geprüft werden: | Eigenschaft | Prüffrage | |---|---| | administrativer Status | Ist der Port aktiviert? | | operativer Status | Besteht ein Link? | | Portmodus | Ist der Port tatsächlich als Access-Port vorgesehen? | | Access-VLAN | Ist das richtige VLAN zugeordnet? | | Voice-VLAN | Existiert eine zusätzliche Telefonzuordnung? | | MAC-Tabelle | Wird die erwartete MAC-Adresse gelernt? | | Port-Security | Ist die Client-MAC zugelassen? | | Authentifizierung | Ist 802.1X beziehungsweise MAB erfolgreich? | | Spanning Tree | Ist der Port forwarding oder blockiert? | | Fehlerzähler | Steigen CRC-, Drop- oder andere Fehler? | | Beschreibung | Passt die Dokumentation zum angeschlossenen Gerät? | **Erwartetes Muster** ```text Switchport: Port 17 Modus: Access Access-VLAN: 20 MAC-Adresse: 00:11:22:33:44:55 Spanning Tree: Forwarding Port-Security: kein Verstoß ``` Wenn die MAC-Adresse des Clients an diesem Port nicht gelernt wird, müssen Link, Kabel, Clientaktivität, Authentifizierung und Portzustand geprüft werden.
7. Wie wird ein Trunk systematisch geprüft? **Prüfpunkte auf beiden Seiten** | Eigenschaft | Seite A | Seite B | |---|---|---| | Portmodus | Trunk | Trunk | | erlaubte VLANs | identische beziehungsweise kompatible Liste | identische beziehungsweise kompatible Liste | | natives VLAN | abgestimmt | abgestimmt | | Tagging | abgestimmt | abgestimmt | | Linkaggregation | gleiche logische Verbindung | gleiche logische Verbindung | | Geschwindigkeit und Duplex | kompatibel | kompatibel | | Spanning Tree | erwarteter Zustand | erwarteter Zustand | **Typischer Fehler** ```text Switch A erlaubt: VLAN 10, 20, 40 Switch B erlaubt: VLAN 10, 40 ``` Auswirkung: ```text VLAN 20 funktioniert nicht über diesen Trunk. VLAN 10 und VLAN 40 funktionieren weiterhin. ``` Dadurch kann der Eindruck entstehen, der Uplink sei grundsätzlich in Ordnung, obwohl nur ein bestimmtes VLAN fehlt.
8. Was ist ein Native-VLAN- oder ungetaggtes VLAN? Auf manchen Trunks wird ein definiertes VLAN ungetaggt übertragen. Die genaue Bezeichnung und das Verhalten sind hersteller- und konfigurationsabhängig. **Fehlkonfiguration** ```text Switch A: ungetaggtes VLAN 10 Switch B: ungetaggtes VLAN 20 ``` Ein ungetaggter Frame wird dann auf beiden Seiten unterschiedlichen VLANs zugeordnet. Mögliche Auswirkungen: - Geräte landen im falschen Netz, - Managementzugriff verhält sich unerwartet, - DHCP-Antworten stammen aus dem falschen Bereich, - Verkehr wird zwischen unerwarteten Broadcast-Domains übergeben, - Sicherheitsgrenzen werden verletzt. **Wichtig** Die Begriffe `native`, `untagged`, `PVID`, `default VLAN` und `access VLAN` werden von Herstellern nicht immer identisch verwendet. Die Dokumentation des konkret eingesetzten Switches muss geprüft werden.
9. Was ist die PVID? PVID steht für Port VLAN Identifier. Sie bestimmt bei vielen Switchplattformen, welchem VLAN ein ungetaggt eingehender Frame zugeordnet wird. Vereinfacht: ```text Untagged Frame trifft auf Port mit PVID 20 → Switch ordnet den Frame VLAN 20 zu ``` Die PVID ist nicht automatisch dasselbe wie die vollständige Liste aus getaggten und ungetaggten VLAN-Mitgliedschaften. Bei einer Prüfung müssen deshalb getrennt betrachtet werden: - VLAN-Mitgliedschaft des Ports, - getaggt oder ungetaggt, - PVID, - zulässige VLAN-Liste, - Verhalten ausgehender Frames.
10. Wie wird die lokale VLAN-Konfiguration unter Windows geprüft? Normale Endgeräte an Access-Ports besitzen häufig keine lokale VLAN-Konfiguration. Die VLAN-Zuordnung erfolgt dann ausschließlich am Switch. **Adapter und erweiterte Eigenschaften anzeigen** ```powershell [RO] Get-NetAdapter | Format-Table Name, InterfaceDescription, Status, LinkSpeed, MacAddress ``` ```powershell [RO] Get-NetAdapterAdvancedProperty -Name 'Ethernet' ``` Nach VLAN-bezogenen Eigenschaften suchen: ```powershell [RO] Get-NetAdapterAdvancedProperty -Name 'Ethernet' | Where-Object { $_.DisplayName -Match 'VLAN|Priority' -or $_.RegistryKeyword -Match 'VLAN|Priority' } | Format-Table DisplayName, DisplayValue, RegistryKeyword, RegistryValue ``` **Wichtige Einschränkung** Bezeichnungen und Verfügbarkeit hängen vom Netzwerktreiber ab. Ein fehlendes VLAN-Feld bedeutet nicht automatisch, dass keine VLAN-Nutzung möglich ist. **Hyper-V-Adapter anzeigen** Falls Hyper-V installiert und der Administrator dafür zuständig ist: ```powershell [RO][PRIV] Get-VMNetworkAdapterVlan -ManagementOS ``` VLAN-Konfiguration virtueller Maschinen: ```powershell [RO][PRIV] Get-VM | Get-VMNetworkAdapter | Get-VMNetworkAdapterVlan ``` Die Hyper-V-Cmdlets sind nur verfügbar, wenn die entsprechenden Hyper-V-Komponenten installiert sind.
11. Wie wird die VLAN-Konfiguration unter Linux geprüft? **Detaillierte Linkinformationen** ```bash [RO] ip -d link show ``` **Bestimmte Schnittstelle** ```bash [RO] ip -d link show dev eth0.20 ``` Beispiel einer VLAN-Schnittstelle: ```text eth0.20@eth0 vlan protocol 802.1Q id 20 ``` | Bestandteil | Bedeutung | |---|---| | `eth0.20` | Name der logischen VLAN-Schnittstelle | | `@eth0` | zugrunde liegende Schnittstelle | | `802.1Q` | VLAN-Tagging-Protokoll | | `id 20` | VLAN-ID 20 | **VLAN-Schnittstellen übersichtlich suchen** ```bash [RO] ip -d -o link show | grep -i 'vlan' ``` **Linux-Bridge-VLANs** Falls Linux Bridging mit VLAN-Filtering verwendet wird: ```bash [RO][PRIV] sudo bridge vlan show ``` Detaillierte Bridge-Links: ```bash [RO][PRIV] sudo bridge -d link show ``` Forwarding-Datenbank beziehungsweise MAC-Tabelle: ```bash [RO][PRIV] sudo bridge fdb show ``` **NetworkManager-Verbindungen** ```bash [RO] nmcli connection show ``` Nur VLAN-Verbindungen: ```bash [RO] nmcli -f NAME,TYPE,DEVICE connection show | grep -i vlan ``` Vollständiges Profil: ```bash [RO][SENS] nmcli connection show "VLAN-VERBINDUNGSNAME" ```
12. Wie wird die VLAN-Konfiguration unter macOS geprüft? **Alle Schnittstellen** ```bash [RO] ifconfig ``` **VLAN-Schnittstellen suchen** ```bash [RO] ifconfig -a | grep -E '^[[:alnum:]].*:|vlan:' ``` Eine VLAN-Schnittstelle kann abhängig von Konfiguration und macOS-Version beispielsweise als `vlan0` erscheinen. **Netzwerkdienste** ```bash [RO] networksetup -listallnetworkservices ``` **Hardwareports** ```bash [RO] networksetup -listallhardwareports ``` Die grafische VLAN-Verwaltung und ihre Verfügbarkeit hängen von macOS-Version, Adapter und Treiber ab. Nicht jeder USB- oder Thunderbolt-Ethernetadapter unterstützt VLAN-Konfigurationen in gleicher Weise. Ein Mac an einem gewöhnlichen Access-Port benötigt normalerweise keine lokale VLAN-ID.
13. Wie wird geprüft, ob der Client im erwarteten VLAN gelandet ist? Der Client sieht die VLAN-ID an einem gewöhnlichen Access-Port normalerweise nicht direkt. Deshalb werden mehrere Informationen kombiniert. | Prüfung | Erwartetes Ergebnis | |---|---| | Switchportkonfiguration | vorgesehenes Access-VLAN | | erhaltene DHCP-Adresse | Subnetz des vorgesehenen VLANs | | Standardgateway | Gateway des vorgesehenen VLANs | | DNS-Server | passende Infrastruktur | | sichtbare Nachbarn | Geräte des erwarteten Netzes | | Switch-MAC-Tabelle | Client-MAC am erwarteten Port und VLAN | | Vergleichsclient | passende Konfiguration am gleichen Standort | **Beispiel** Vorgesehen: ```text VLAN 20 Subnetz 192.0.2.0/24 Gateway 192.0.2.1 ``` Tatsächlich: ```text Clientadresse 198.51.100.45/24 Gateway 198.51.100.1 ``` Dies ist ein starker Hinweis auf: - falsches Access-VLAN, - falsche SSID-zu-VLAN-Zuordnung, - fehlerhafte dynamische VLAN-Zuweisung, - nicht vorgesehenen DHCP-Server, - falsches Netzwerkprofil.
14. Wie wird die MAC-Adresstabelle zur VLAN-Diagnose verwendet? Ein Switch lernt Quell-MAC-Adressen eingehender Frames und ordnet sie normalerweise einem Port und VLAN zu. **Zu prüfende Zuordnung** ```text MAC-Adresse: 00:11:22:33:44:55 VLAN: 20 Port: 17 ``` **Mögliche Auffälligkeiten** | Beobachtung | Mögliche Ursache | |---|---| | MAC nicht gelernt | kein Verkehr, Linkproblem, Authentifizierung oder Port blockiert | | MAC im falschen VLAN | Port- oder Taggingfehler | | MAC am falschen Port | Dokumentationsfehler, Umstecken oder Layer-2-Schleife | | MAC wechselt schnell zwischen Ports | Schleife, redundanter Pfad oder Fehlverkabelung | | viele MACs an Clientport | Switch, Bridge, Hypervisor oder unerlaubtes Gerät angeschlossen | | nur Telefon-MAC sichtbar | PC-Port des Telefons oder Daten-VLAN prüfen | | MAC erscheint hinter Uplink | Client befindet sich an nachgelagertem Switch | Die konkreten Befehle zur MAC-Tabelle sind herstellerabhängig. Suchkriterium sollte die zuvor eindeutig ermittelte Client-MAC-Adresse sein.
15. Wie werden Voice-VLAN und angeschlossener PC berücksichtigt? Ein IP-Telefon kann zwei logische Verbindungen bereitstellen: ```text Switchport → Voice-VLAN für Telefon → Data-VLAN für PC hinter dem Telefon ``` Mögliche Fehlerbilder: - Telefon funktioniert, PC erhält keine Adresse, - PC funktioniert, Telefon registriert sich nicht, - beide Geräte erhalten Adressen aus demselben falschen VLAN, - Telefon kündigt dem PC falsche Parameter an, - Voice-VLAN wird nicht über den Trunk transportiert, - Datenport des Telefons ist deaktiviert, - 802.1X- oder MAB-Reihenfolge ist fehlerhaft. Zu prüfen sind: - Access-/Data-VLAN, - Voice-VLAN, - Erkennungsmechanismus des Telefons, - MAC-Adressen beider Geräte, - Authentifizierungsstatus, - DHCP-Bereiche beider VLANs, - Uplink- und Trunkfreigabe.
16. Wie beeinflussen 802.1X und dynamische VLAN-Zuweisung die Diagnose? Bei portbasierter Netzwerkzugangskontrolle kann ein Gerät abhängig von seiner Authentifizierung einem VLAN zugewiesen werden. Vereinfachter Ablauf: ```text Client → Switch oder Access Point → Authentifizierungsdienst → Zugelassenes VLAN ``` Mögliche Ergebnisse: - vorgesehenes Produktions-VLAN, - Gast-VLAN, - Quarantäne-VLAN, - Authentifizierungsfehler, - eingeschränkter Netzwerkzugriff, - MAC-basierte Ersatzauthentifizierung. **Typische Symptome** - korrekte Zugangsdaten, aber falsches VLAN, - Gerät erhält eine Quarantäneadresse, - Verbindung funktioniert erst nach erneuter Anmeldung, - Zertifikat oder Gerätekonto wird abgelehnt, - Telefon und PC werden unterschiedlich behandelt, - Switchport ist aktiv, aber normaler Datenverkehr wird blockiert. **Zu erfassen** - Authentifizierungsmethode, - Benutzer- oder Geräteidentität, - Ergebnis, - zugewiesenes VLAN, - Zeitstempel, - Switchport, - Richtlinie, - Authentifizierungsserver. Das manuelle Setzen eines festen VLANs kann die eigentliche Authentifizierungsstörung verdecken und Sicherheitsrichtlinien umgehen.
17. Wie beeinflusst Spanning Tree die Layer-2-Kommunikation? Spanning Tree verhindert Layer-2-Schleifen, indem redundante Pfade kontrolliert blockiert werden. Mögliche Portzustände beziehungsweise Rollen unterscheiden sich je nach verwendeter STP-Variante und Hersteller. Für die Diagnose ist entscheidend, ob der erwartete Port Nutzdaten weiterleitet. **Mögliche Symptome** - VLAN ist über einen bestimmten Uplink nicht erreichbar, - Verbindung funktioniert nach Verzögerung, - MAC-Adressen wechseln zwischen Ports, - Broadcastlast steigt stark, - Switch-CPU steigt, - Ports werden wiederholt blockiert und freigegeben, - Topology Changes treten häufig auf, - nur einzelne VLANs sind betroffen. **Wichtige Prüfung** ```text Ist der Port für das betroffene VLAN im Zustand Forwarding? ``` Ein physisch aktiver Port kann durch Spanning Tree logisch blockiert sein. **Warnung** ```text [CHANGE][DISRUPT] Spanning Tree darf nicht als schnelle Fehlerbehebung deaktiviert werden. Dadurch können Layer-2-Schleifen und großflächige Netzwerkausfälle entstehen. ```
18. Was ist eine Layer-2-Schleife und wie wird sie erkannt? Ethernetframes besitzen auf Layer 2 kein mit IP-TTL direkt vergleichbares allgemeines Feld, das eine Schleife zuverlässig beendet. Eine Schleife kann deshalb zu einem Broadcast Storm führen. **Mögliche Symptome** - Netzwerk wird plötzlich extrem langsam, - sehr hohe Broadcast- und Multicastrate, - Switch-CPU ist stark ausgelastet, - MAC-Adressen springen zwischen Ports, - mehrere Switchports blinken dauerhaft stark, - DHCP und ARP funktionieren unzuverlässig, - Managementzugriff auf Switches bricht ab, - Spanning-Tree-Topology-Changes treten wiederholt auf. **Sicheres Vorgehen** 1. Netzwerkverantwortliche und Incident-Prozess aktivieren. 2. betroffene Switches und VLANs bestimmen, 3. STP-Ereignisse und MAC-Flapping prüfen, 4. letzte Verkabelungs- und Portänderungen kontrollieren, 5. Schleifenpfad anhand der Topologie eingrenzen, 6. nur koordiniert einen eindeutig bestimmten Port isolieren, 7. Stabilisierung und Ursache dokumentieren. Ein wahlloses Entfernen von Uplinks kann Redundanz und weitere Standorte beeinträchtigen.
19. Wie wirken Port-Security und MAC-Limits? Port-Security kann die Anzahl oder Identität zugelassener MAC-Adressen begrenzen. Mögliche Reaktionen bei einem Verstoß: - Frames verwerfen, - unbekannte MAC-Adressen blockieren, - Ereignis protokollieren, - Port in einen Fehler- oder Shutdownzustand versetzen, - Alarm an das Monitoring senden. **Typische Ursachen eines Verstoßes** - Endgerät wurde ersetzt, - Dockingstation verwendet andere MAC-Adresse, - IP-Telefon und PC erzeugen zwei MAC-Adressen, - Hypervisor oder Bridge sendet mehrere MAC-Adressen, - kleiner Switch wurde unerlaubt angeschlossen, - zufällige beziehungsweise private MAC-Adresse wird verwendet, - konfigurierte Sticky-MAC ist veraltet. **Zu prüfen** - erlaubte Anzahl MAC-Adressen, - aktuell gelernte MAC-Adressen, - fest konfigurierte oder dynamisch gelernte Einträge, - Verstoßzähler, - Reaktionsmodus, - Portstatus, - Endgerätetyp. Port-Security darf nicht einfach deaktiviert werden, ohne Sicherheitszweck und Richtlinie zu prüfen.
20. Wie werden private oder zufällige MAC-Adressen berücksichtigt? Moderne Betriebssysteme können bei WLAN-Verbindungen private beziehungsweise zufällige MAC-Adressen verwenden. Abhängig von Plattform und Konfiguration kann dies auch die Wiedererkennung eines Geräts beeinflussen. Mögliche Auswirkungen: - DHCP-Reservierung greift nicht, - MAC-basierte Authentifizierung schlägt fehl, - Gerät erscheint als neuer Client, - Port- oder WLAN-Richtlinie greift nicht, - Inventarisierung stimmt nicht, - mehrere Leases werden erzeugt. **Prüfung** Die aktuell verwendete MAC-Adresse muss mit folgenden Stellen verglichen werden: - Betriebssystem, - Switch oder Access Point, - DHCP-Lease, - Netzwerkzugangskontrolle, - Inventarsystem. Eine private MAC-Adresse ist nicht automatisch eine Fehlfunktion. Ihre Verwendung kann beabsichtigter Datenschutzstandard oder durch eine Richtlinie gesteuert sein.
21. Wie werden VLAN-Tags mit Wireshark geprüft? **Wireshark-Display-Filter für VLAN-Tags** ```text vlan ``` Bestimmte VLAN-ID: ```text vlan.id == 20 ``` Mehrere VLAN-IDs: ```text vlan.id == 20 || vlan.id == 40 ``` Nur DHCP in VLAN 20: ```text vlan.id == 20 && (udp.port == 67 || udp.port == 68) ``` **Capture-Filter** ```text vlan ``` Bestimmtes VLAN: ```text vlan 20 ``` Bestimmtes VLAN und Host: ```text vlan 20 and host 192.0.2.23 ``` **Zeitlich begrenzte Aufnahme** ```bash [TEST][PRIV][FILE][SENS] dumpcap \ -i INTERFACE \ -f "vlan 20" \ -a duration:30 \ -w vlan20.pcapng ``` **TShark-Auswertung** ```bash [RO][SENS] tshark \ -r vlan20.pcapng \ -Y "vlan" \ -T fields \ -e frame.time \ -e eth.src \ -e eth.dst \ -e vlan.id \ -e vlan.priority ``` Lokal verfügbare VLAN-Felder: ```bash [RO] tshark -G fields | grep -E $'\tvlan\.' ```
22. Warum ist ein VLAN-Tag im Clientmitschnitt möglicherweise nicht sichtbar? Mögliche Gründe: 1. Der Client befindet sich an einem Access-Port und empfängt ungetaggte Frames. 2. Der Netzwerkadapter entfernt VLAN-Tags in Hardware. 3. Der Treiber übergibt Tags nicht an das Capture-Werkzeug. 4. Offloading beeinflusst die lokale Darstellung. 5. Es wurde auf der falschen Schnittstelle mitgeschnitten. 6. Der Tag befindet sich nur auf einem anderen Abschnitt des Netzwerkweges. 7. Eine virtuelle Bridge oder ein Hypervisor verarbeitet den Tag vor der Aufzeichnung. ```text Kein sichtbarer VLAN-Tag im lokalen Mitschnitt ≠ kein VLAN im Netzwerk ``` Für die Prüfung eines Trunks ist ein geeigneter Messpunkt am Trunk beziehungsweise ein korrekt konfigurierter Mirror-Port erforderlich. Eine solche Aufzeichnung muss autorisiert und datenschutzgerecht durchgeführt werden.
23. Wie werden virtuelle Maschinen und Hypervisor-VLANs berücksichtigt? Mögliche Modelle: **VLAN-Zuordnung am virtuellen Switch** ```text VM sendet ungetaggt → virtueller Switch ordnet VLAN 40 zu → physischer Uplink überträgt VLAN 40 getaggt ``` **VLAN-Zuordnung in der VM** ```text VM erzeugt 802.1Q-Tag → virtueller Switch reicht Tag durch → physischer Trunk transportiert VLAN ``` **Mögliche Fehler** - falsche VLAN-ID am virtuellen Adapter, - physischer Uplink erlaubt VLAN nicht, - virtueller Switch entfernt oder erwartet Tags, - VM und Hypervisor taggen gleichzeitig, - Portgruppe gehört zum falschen VLAN, - Teaming- oder Bond-Uplink ist inkonsistent, - Migration verschiebt VM auf Host ohne passende Trunkfreigabe. Zu prüfen sind: - virtuelle Netzwerkkarte, - Portgruppe beziehungsweise virtueller Switchport, - virtueller Switch, - physischer Uplink, - Switch-Trunk, - erlaubte VLANs auf allen beteiligten Pfaden.
24. Wie werden Linux-Bridge und Container-VLANs berücksichtigt? Vereinfachter Pfad: ```text Container oder VM → virtuelle Schnittstelle → Linux-Bridge → VLAN-Filterung → physische Schnittstelle → Switch-Trunk ``` **Bridge-Übersicht** ```bash [RO][PRIV] sudo bridge link show ``` **VLAN-Zuordnungen** ```bash [RO][PRIV] sudo bridge vlan show ``` **MAC-Tabelle der Bridge** ```bash [RO][PRIV] sudo bridge fdb show ``` **Detaillierte Links** ```bash [RO] ip -d link show ``` Mögliche Fehler: - VLAN-Filtering ist anders konfiguriert als erwartet, - VLAN fehlt am Bridgeport, - PVID ist falsch, - VLAN ist ungetaggt statt getaggt, - physischer Uplink transportiert das VLAN nicht, - Container-MAC wird nicht korrekt gelernt, - Firewall- beziehungsweise Bridge-Filter verwirft Frames. Docker-Standardbridges verwenden nicht automatisch dieselbe VLAN-Struktur wie ein physischer Switch. Das konkrete Container- und Hostnetz muss separat dokumentiert werden.
25. Wie werden VLANs über mehrere Switches verfolgt? **Beispielpfad** ```text CLIENT-023 → SW-ACCESS-01 Port 17 → VLAN 20 → Uplink 1 → SW-DISTRIBUTION-01 → Port-Channel 10 → SW-CORE-01 → Gateway VLAN 20 ``` Für jeden Abschnitt wird geprüft: | Abschnitt | Prüfung | |---|---| | Clientport | Access-VLAN und Client-MAC | | erster Switch | MAC wird im richtigen VLAN gelernt | | Uplink | VLAN 20 ist erlaubt | | nächster Switch | VLAN existiert und ist aktiv | | Linkaggregation | alle Mitglieder sind konsistent | | Spanning Tree | erwarteter Pfad ist forwarding | | Gateway | VLAN-Interface ist aktiv | | Rückweg | führt zurück in dasselbe Client-VLAN | **Methode** Die Client-MAC-Adresse wird vom Access-Port in Richtung Core verfolgt. Die Gateway-MAC-Adresse wird in Gegenrichtung geprüft.
26. Was ist bei Link Aggregation und Port-Channels zu beachten? Mehrere physische Links können zu einer logischen Verbindung gebündelt werden. Mögliche Fehler: - ein Mitglied besitzt andere VLAN-Einstellungen, - nur einige Mitglieder transportieren das betroffene VLAN, - LACP-Zustand ist fehlerhaft, - ein Link ist physisch aktiv, aber nicht im Bundle, - Lastverteilung führt nur bestimmte Verbindungen über den fehlerhaften Link, - native beziehungsweise ungetaggte VLANs unterscheiden sich, - Spanning Tree sieht eine unerwartete Topologie. **Typisches Symptom** ```text Einige Verbindungen funktionieren, andere nicht. Der Fehler hängt von Quell- und Zieladresse oder Sitzung ab. ``` Dies kann auftreten, wenn die Hash-basierte Lastverteilung bestimmte Datenströme über ein fehlerhaftes Mitglied leitet. Auf allen Mitgliedern müssen relevante Konfigurationen konsistent sein. Änderungen dürfen nur über die vorgesehene logische Port-Channel-Konfiguration erfolgen.
27. Wie wird zwischen VLAN-, DHCP- und Routingproblem unterschieden? | Beobachtung | Wahrscheinlichere Richtung | |---|---| | keine DHCP-Adresse, ARP ebenfalls ohne Antwort | VLAN oder Layer 2 möglich | | DHCP-Adresse aus falschem Subnetz | falsches VLAN oder Rogue-DHCP möglich | | korrekte Adresse, Gateway-MAC nicht auflösbar | VLAN, Gatewayinterface oder Layer 2 | | Gateway erreichbar, anderes VLAN nicht | Routing oder Firewall | | Geräte im selben VLAN kommunizieren | lokales Layer 2 grundsätzlich aktiv | | nur ein Trunkabschnitt betroffen | erlaubte VLANs oder Tagging | | nur neue Clients betroffen | DHCP oder Zugangskontrolle | | nur ein Port betroffen | Access-VLAN, Port-Security oder Verkabelung | | alle Ports eines VLANs betroffen | VLAN, Gateway, STP oder Uplink | | VLAN lokal verfügbar, über Uplink nicht | Trunk oder Spanning Tree | | Ziel wird im falschen Subnetz gesucht | Clientpräfix oder DHCP-Option | Ein Fehler kann mehrere Ebenen gleichzeitig betreffen. Beispielsweise kann ein falsches Access-VLAN zu einer falschen DHCP-Konfiguration führen.
28. Welche eingreifenden Änderungen dürfen nicht vorschnell erfolgen? | Änderung | Risiko | |---|---| | Access-VLAN ändern | Client verliert Verbindung oder landet im falschen Sicherheitsbereich | | Trunk-VLAN hinzufügen | unerwartete Netze werden erweitert | | Trunk-VLAN entfernen | gesamtes VLAN fällt über den Uplink aus | | natives VLAN ändern | ungetaggter Verkehr wird falsch zugeordnet | | Port auf Trunk umstellen | Endgerät kann Tags erhalten oder Sicherheitsgrenze verändert sich | | Port-Security deaktivieren | Zugriffsschutz wird aufgehoben | | 802.1X umgehen | Sicherheitsrichtlinie wird umgangen | | Spanning Tree deaktivieren | Layer-2-Schleife und Broadcast Storm möglich | | Port-Channel verändern | mehrere Verbindungen können ausfallen | | VLAN auf Hypervisor ändern | VM- oder Managementzugriff kann ausfallen | | VLAN-Interface löschen | IP-Kommunikation dieses Netzes fällt aus | Vor jeder Änderung müssen dokumentiert werden: - Ausgangskonfiguration, - betroffener Port, - abhängige Geräte, - vorgesehener Sollzustand, - erwartete Wirkung, - Rückweg, - Wartungs- und Kommunikationsplan.
29. Welche typischen Fehlinterpretationen müssen vermieden werden? | Beobachtung | Falscher Schluss | Richtige Einordnung | |---|---|---| | Link ist aktiv | VLAN ist korrekt | Link und VLAN sind getrennte Zustände | | Client sieht keinen VLAN-Tag | kein VLAN vorhanden | Access-Port liefert gewöhnlich ungetaggte Frames | | DHCP funktioniert | VLAN ist korrekt | DHCP kann aus falschem VLAN stammen | | Ping im VLAN funktioniert | Trunk ist vollständig korrekt | andere VLANs können fehlen | | VLAN 20 funktioniert lokal | VLAN 20 funktioniert überall | Uplinkpfad separat prüfen | | MAC fehlt in Tabelle | Gerät ist ausgeschaltet | Authentifizierung, Port oder fehlende Aktivität möglich | | MAC wechselt den Port | Angriff | Schleife, Redundanz oder legitime Migration möglich | | STP blockiert Port | STP ist defekt | Blockierung kann notwendiger Schleifenschutz sein | | mehrere MACs am Port | unerlaubter Switch | Telefon, Hypervisor oder Bridge möglich | | gleiche VLAN-ID | gleiches Layer-2-Netz | getrennte Switchdomänen können dieselbe ID verwenden | | Portwechsel behebt Fehler | Switchport ist defekt | anderer Port kann anderes VLAN oder Policy besitzen | | VLAN hinzufügen behebt Fehler | Änderung war korrekt | Sicherheits- und Architekturprüfung bleibt erforderlich |
30. Wie sieht der systematische Prüfablauf aus? | Schritt | Prüfung | |---:|---| | 1 | Client, MAC-Adresse, Switch und Port bestimmen | | 2 | vorgesehenes VLAN und Subnetz aus Dokumentation ermitteln | | 3 | aktuelle Clientadresse mit dem vorgesehenen VLAN vergleichen | | 4 | Portmodus, Access-VLAN, PVID und Voice-VLAN prüfen | | 5 | Authentifizierungs- und Port-Security-Status prüfen | | 6 | Client-MAC in der Switchtabelle suchen | | 7 | Gateway-MAC und lokale Kommunikation prüfen | | 8 | betroffenen VLAN-Pfad über alle Uplinks verfolgen | | 9 | erlaubte und getaggte VLANs auf beiden Seiten vergleichen | | 10 | Spanning-Tree-Zustand je betroffenem VLAN prüfen | | 11 | Linkaggregation und Mitgliedsports vergleichen | | 12 | virtuelle Switches und Bridges einbeziehen | | 13 | bei Bedarf autorisierten Mitschnitt am geeigneten Messpunkt erstellen | | 14 | Hypothese mit einer einzelnen kontrollierten Änderung testen | | 15 | DHCP, Gateway und Zielverbindung erneut prüfen | | 16 | ursprüngliche Konfiguration beziehungsweise Rückweg dokumentieren | **Merksatz** ```text Client-MAC → Access-Port → VLAN → Uplink → Trunk → Spanning Tree → Gateway ```
31. Kompakte Befehlsübersicht | Aufgabe | Windows | Linux | macOS | |---|---|---|---| | Adapter anzeigen | `[RO] Get-NetAdapter` | `[RO] ip -brief link` | `[RO] ifconfig` | | VLAN-Eigenschaften der NIC | `[RO] Get-NetAdapterAdvancedProperty -Name 'Ethernet'` | `[RO] ip -d link show` | `[RO] ifconfig -a` | | VLAN-Schnittstellen suchen | treiberabhängig | `[RO] ip -d -o link show \| grep -i vlan` | `[RO] ifconfig -a \| grep -E '^[[:alnum:]].*:|vlan:'` | | Hyper-V-VLANs | `[RO][PRIV] Get-VMNetworkAdapterVlan -ManagementOS` | nicht zutreffend | nicht zutreffend | | VM-VLANs | `[RO][PRIV] Get-VM \| Get-VMNetworkAdapter \| Get-VMNetworkAdapterVlan` | hypervisorabhängig | hypervisorabhängig | | Linux-Bridge-VLANs | nicht zutreffend | `[RO][PRIV] sudo bridge vlan show` | nicht standardmäßig gleichwertig | | Linux-Bridge-MAC-Tabelle | nicht zutreffend | `[RO][PRIV] sudo bridge fdb show` | nicht standardmäßig gleichwertig | | VLAN-Tags anzeigen | `[RO][SENS] tshark -r DATEI -Y "vlan"` | gleicher Befehl | gleicher Befehl | | VLAN 20 mitschneiden | `[TEST][PRIV][FILE][SENS] dumpcap -i INTERFACE -f "vlan 20" -a duration:30 -w vlan20.pcapng` | gleicher Befehl | gleicher Befehl | | DHCP in VLAN 20 anzeigen | `[RO][SENS] tshark -r DATEI -Y "vlan.id == 20 && (udp.port == 67 \|\| udp.port == 68)"` | gleicher Befehl | gleicher Befehl | Switchbefehle sind hersteller- und betriebssystemspezifisch. Für produktive Switches müssen ausschließlich die offiziellen Befehle der tatsächlich eingesetzten Plattform verwendet werden.
32. Dokumentationsvorlage ```text Ticketnummer: Prüfzeitpunkt: Zeitzone: Standort: Betroffener Client: Client-MAC: Client-IP: Erwartetes Subnetz: Erwartetes Gateway: Erwartete VLAN-ID: ACCESS-PORT Switch: Switchmodell: Switch-Betriebssystem: Switchport: Portbeschreibung: Administrativer Status: Operativer Status: Portmodus: Access-/Data-VLAN: Voice-VLAN: PVID: Getaggte VLANs: Ungetaggte VLANs: 802.1X-Status: Dynamisch zugewiesenes VLAN: Port-Security-Status: Erlaubte MAC-Anzahl: Gelernte MAC-Adressen: Verstoßzähler: STP-Zustand: Fehlerzähler: UPLINKPFAD Switch 1: Ausgangsport: Erlaubte VLANs: Natives/ungetaggtes VLAN: Port-Channel: STP-Zustand: Switch 2: Eingangsport: Erlaubte VLANs: Natives/ungetaggtes VLAN: Port-Channel: STP-Zustand: Weitere Switches: - GATEWAY Gatewaygerät: VLAN-Interface: Interfacezustand: Gateway-IP: Gateway-MAC: Routing aktiv: Firewall beteiligt: CLIENTPRÜFUNG Erhaltene IPv4-Adresse: Präfix: DHCP-Server: Standardgateway: DNS-Server: Gateway-MAC aufgelöst: Gateway erreichbar: Referenzclient: Relevante Abweichungen: VIRTUELLE INFRASTRUKTUR Hypervisor: Virtueller Switch: Portgruppe: VM-VLAN: Physischer Uplink: Bridge-VLAN: PVID: Getaggt/ungetaggt: PAKETMITSCHNITT Messpunkt: Sichtbare VLAN-ID: Erwartete VLAN-ID: DHCP sichtbar: ARP sichtbar: Unbeabsichtigter Fremdverkehr: Capture-Datei: Hash: Arbeitshypothese: Begründung: Gesicherte Ausgangskonfiguration: Geplante Änderung: Freigabe: Rückweg: Tatsächliches Ergebnis: Abschlussprüfung: Ermittelte Ursache: ```
33. Offizielle Quellen und weiterführende Dokumentation **Microsoft** - [Get-NetAdapterAdvancedProperty](https://learn.microsoft.com/powershell/module/netadapter/get-netadapteradvancedproperty) - [Get-VMNetworkAdapterVlan](https://learn.microsoft.com/powershell/module/hyper-v/get-vmnetworkadaptervlan) - [Hyper-V Virtual Switch](https://learn.microsoft.com/windows-server/virtualization/hyper-v-virtual-switch/hyper-v-virtual-switch) - [Hyper-V-Netzwerkvirtualisierung](https://learn.microsoft.com/windows-server/networking/sdn/technologies/hyper-v-network-virtualization/hyperv-network-virtualization-technical-details-windows-server) **Linux** - [ip-link – Linux Manual Page](https://man7.org/linux/man-pages/man8/ip-link.8.html) - [bridge – Linux Manual Page](https://man7.org/linux/man-pages/man8/bridge.8.html) - [Linux Bridge VLAN Filtering](https://docs.kernel.org/networking/bridge.html) - [NetworkManager nm-settings](https://networkmanager.dev/docs/api/latest/nm-settings-nmcli.html) **Apple** - Lokale Befehlsreferenzen: `man ifconfig` und `man networksetup` - [Netzwerkstatus auf dem Mac prüfen](https://support.apple.com/guide/mac-help/check-the-status-of-your-network-mchlp2291/mac) **Wireshark** - [IEEE 802.1Q VLAN Display Filter Reference](https://www.wireshark.org/docs/dfref/v/vlan.html) - [Wireshark Capture Filters](https://www.wireshark.org/docs/wsug_html_chunked/ChCapCaptureFilterSection.html) - [dumpcap Manual Page](https://www.wireshark.org/docs/man-pages/dumpcap.html) - [tshark Manual Page](https://www.wireshark.org/docs/man-pages/tshark.html) **Standards** - [IEEE 802.1Q – Bridges and Bridged Networks](https://standards.ieee.org/ieee/802.1Q/6844/) > VLAN-Begriffe und Konfigurationsmodelle unterscheiden sich zwischen Switchherstellern. Insbesondere die Bedeutung von Access, Trunk, Tagged, Untagged, Native VLAN und PVID muss anhand der offiziellen Dokumentation des konkret eingesetzten Geräts geprüft werden.
# 3.7 Standardgateway und Routing analysieren Routing bestimmt, über welchen Netzwerkpfad ein IP-Paket sein Ziel erreicht. Liegt das Ziel nicht im direkt angeschlossenen Subnetz, benötigt der Client eine passende Route zu einem Router beziehungsweise Next Hop. Das Standardgateway wird verwendet, wenn keine spezifischere Route zum Ziel vorhanden ist. Eine vorhandene Standardroute beweist jedoch nicht, dass sie korrekt ist oder dass der vollständige Hin- und Rückweg funktioniert. > **Grundregel:** Nicht nur prüfen, ob eine Route vorhanden ist. Es muss geprüft werden, welche Route für das konkrete Ziel tatsächlich ausgewählt wird und ob ein passender Rückweg existiert. ---
1. Welche Aufgaben erfüllt ein Router? Ein Router verbindet unterschiedliche IP-Netze. **Beispiel** ```text Clientnetz: 192.0.2.0/24 Servernetz: 198.51.100.0/24 ``` Kommunikationsweg: ```text CLIENT-023 192.0.2.23/24 │ ├─ Standardgateway 192.0.2.1 │ ├─ Router oder Firewall │ └─ SERVER-01 198.51.100.20/24 ``` Der Client erkennt anhand seines Präfixes, dass `198.51.100.20` nicht im lokalen Subnetz liegt. Er übergibt das Paket deshalb an einen Router. Der Router: 1. liest die Ziel-IP-Adresse, 2. sucht die passendste Route, 3. bestimmt Ausgangsschnittstelle und nächsten Hop, 4. verringert bei IPv4 die TTL beziehungsweise bei IPv6 den Hop Limit, 5. leitet das Paket weiter oder verwirft es.
2. Wann wird das Standardgateway verwendet? Die IPv4-Standardroute lautet: ```text 0.0.0.0/0 ``` Die IPv6-Standardroute lautet: ```text ::/0 ``` Sie passen grundsätzlich auf jedes Ziel der jeweiligen Adressfamilie. Spezifischere Routen werden jedoch bevorzugt. **Beispielroutingtabelle** | Zielpräfix | Next Hop | Bedeutung | |---|---|---| | `192.0.2.0/24` | direkt verbunden | lokales Clientnetz | | `198.51.100.0/24` | `192.0.2.254` | spezifische Route zum Servernetz | | `0.0.0.0/0` | `192.0.2.1` | Standardroute | Für das Ziel `198.51.100.20` wird die spezifische `/24`-Route verwendet und nicht die Standardroute.
3. Was bedeutet Longest Prefix Match? Wenn mehrere Routen zu einem Ziel passen, wird grundsätzlich die Route mit dem längsten passenden Präfix bevorzugt. **Beispiel** | Route | Passt auf `198.51.100.20`? | Präfixlänge | |---|---:|---:| | `0.0.0.0/0` | Ja | 0 | | `198.51.0.0/16` | Ja | 16 | | `198.51.100.0/24` | Ja | 24 | | `198.51.100.20/32` | Ja | 32 | Ausgewählt wird: ```text 198.51.100.20/32 ``` Reihenfolge: ```text Hostroute /32 vor Netzroute /24 vor gröberer Netzroute /16 vor Standardroute /0 ``` Eine Route mit niedrigerer Metrik gewinnt nicht gegen eine passendere Route mit längerem Präfix. Die Metrik wird für konkurrierende, in der Auswahl gleich geeignete Routen relevant.
4. Welche Bestandteile besitzt ein Routingtabelleneintrag? | Bestandteil | Bedeutung | |---|---| | Zielpräfix | Netz oder Host, für den die Route gilt | | Präfixlänge | Genauigkeit der Route | | Next Hop | nächster Router | | Ausgangsschnittstelle | verwendeter Adapter | | Quelladresse | für das Ziel ausgewählte lokale Adresse | | Metrik | Kosten beziehungsweise Priorität | | Protokoll oder Ursprung | statisch, verbunden, DHCP oder Routingprotokoll | | Gültigkeitsdauer | bei dynamischen Einträgen möglicherweise begrenzt | | Routingtabelle | bei Policy Routing eine bestimmte Tabelle | **Beispiel** ```text 198.51.100.0/24 via 192.0.2.254 dev eth0 metric 100 ``` | Feld | Wert | |---|---| | Ziel | `198.51.100.0/24` | | Next Hop | `192.0.2.254` | | Schnittstelle | `eth0` | | Metrik | `100` |
5. Welche Symptome sprechen für einen Routingfehler? - lokale Ziele sind erreichbar, entfernte Ziele jedoch nicht, - Standardgateway fehlt, - falsches Gateway ist eingetragen, - nur ein bestimmtes Zielnetz ist nicht erreichbar, - VPN übernimmt unerwartet die Standardroute, - Zugriff funktioniert nur ohne VPN, - Hinweg funktioniert, Rückweg fehlt, - Traceroute zeigt eine Schleife, - Pakete erreichen die falsche Firewall, - Verbindung funktioniert nur in eine Richtung, - mehrere Standardrouten konkurrieren, - Route zeigt auf eine falsche Schnittstelle, - falsche Quelladresse wird ausgewählt, - ein neues Subnetz ist noch nicht überall bekannt, - Route wurde zusammengefasst und enthält ein nicht erreichbares Teilnetz, - dynamische Route wurde zurückgezogen, - Routingtabelle unterscheidet sich zwischen redundanten Routern, - IPv4 funktioniert, IPv6 jedoch nicht.
6. Wie wird die Routingtabelle unter Windows angezeigt? **IPv4-Routen** ```powershell [RO] Get-NetRoute -AddressFamily IPv4 | Sort-Object DestinationPrefix, RouteMetric | Format-Table ifIndex, InterfaceAlias, DestinationPrefix, NextHop, RouteMetric, InterfaceMetric, Protocol, State ``` **IPv6-Routen** ```powershell [RO] Get-NetRoute -AddressFamily IPv6 | Sort-Object DestinationPrefix, RouteMetric | Format-Table ifIndex, InterfaceAlias, DestinationPrefix, NextHop, RouteMetric, InterfaceMetric, Protocol, State ``` **Klassische Gesamtausgabe** ```cmd [RO] route print ``` Nur IPv4: ```cmd [RO] route print -4 ``` Nur IPv6: ```cmd [RO] route print -6 ``` **Standardrouten** ```powershell [RO] Get-NetRoute -DestinationPrefix '0.0.0.0/0' | Format-Table InterfaceAlias, ifIndex, NextHop, RouteMetric, InterfaceMetric, Protocol ``` IPv6: ```powershell [RO] Get-NetRoute -DestinationPrefix '::/0' ```
7. Wie wird unter Windows die tatsächlich ausgewählte Route geprüft? ```powershell [RO] Find-NetRoute -RemoteIPAddress 198.51.100.20 ``` Die Ausgabe enthält typischerweise: - passende Route, - Ausgangsschnittstelle, - Next Hop, - lokale Quelladresse. **Zusätzliche Schnittstelleninformationen** ```powershell [RO] Get-NetIPInterface | Sort-Object AddressFamily, InterfaceMetric | Format-Table ifIndex, InterfaceAlias, AddressFamily, ConnectionState, InterfaceMetric, AutomaticMetric ``` **Konkrete Zielprüfung** ```powershell [TEST] Test-NetConnection 198.51.100.20 -InformationLevel Detailed ``` Mit Traceroute: ```powershell [TEST] Test-NetConnection 198.51.100.20 ` -TraceRoute ` -InformationLevel Detailed ``` `Test-NetConnection -TraceRoute` prüft den Pfad mit den von Windows dafür vorgesehenen Diagnosemechanismen. Ein nicht antwortender Hop beweist nicht automatisch einen Weiterleitungsfehler.
8. Wie wird die Routingtabelle unter Linux angezeigt? **IPv4-Hauptroutingtabelle** ```bash [RO] ip -4 route show ``` **IPv6-Hauptroutingtabelle** ```bash [RO] ip -6 route show ``` **Alle Routingtabellen** ```bash [RO] ip route show table all ``` IPv6: ```bash [RO] ip -6 route show table all ``` **Standardroute** ```bash [RO] ip route show default ``` IPv6: ```bash [RO] ip -6 route show default ``` **Detaillierte Routen** ```bash [RO] ip -details route show ``` **Routingregeln** ```bash [RO] ip rule show ``` Policy Routing kann dazu führen, dass eine andere Tabelle verwendet wird als die gewöhnliche `main`-Tabelle.
9. Wie wird unter Linux die tatsächlich ausgewählte Route geprüft? ```bash [RO] ip route get 198.51.100.20 ``` Beispiel: ```text 198.51.100.20 via 192.0.2.1 dev eth0 src 192.0.2.23 uid 1000 ``` | Feld | Bedeutung | |---|---| | Ziel | `198.51.100.20` | | `via` | nächster Router | | `dev` | Ausgangsschnittstelle | | `src` | ausgewählte Quelladresse | | `uid` | bei entsprechender Ausgabe berücksichtigte Benutzer-ID | **Route mit bestimmter Quelladresse prüfen** ```bash [RO] ip route get 198.51.100.20 from 192.0.2.23 ``` **IPv6** ```bash [RO] ip -6 route get 2001:db8:20::20 ``` Bei Policy Routing kann die Routenauswahl von folgenden Merkmalen abhängen: - Quelladresse, - Zieladresse, - Eingangsinterface, - Firewallmarkierung, - Benutzerkennung, - Routingtabelle, - Priorität der Regel.
10. Wie wird die Routingtabelle unter macOS angezeigt? **IPv4-Routen** ```bash [RO] netstat -rn -f inet ``` **IPv6-Routen** ```bash [RO] netstat -rn -f inet6 ``` **IPv4-Standardroute** ```bash [RO] route -n get default ``` **Ausgewählte Route zu einem IPv4-Ziel** ```bash [RO] route -n get 198.51.100.20 ``` **Ausgewählte Route zu einem IPv6-Ziel** ```bash [RO] route -n get -inet6 2001:db8:20::20 ``` Typische Felder: | Feld | Bedeutung | |---|---| | `destination` | Ziel | | `gateway` | Next Hop | | `interface` | Ausgangsschnittstelle | | `flags` | Routeneigenschaften | | `recvpipe`/`sendpipe` | interne Routinginformationen | | `mtu` | routenbezogene MTU, falls vorhanden | VPN-Verbindungen erscheinen unter macOS häufig über Tunnelinterfaces wie `utun0`, `utun1` oder weitere nummerierte Varianten.
11. Wie werden mehrere Standardrouten bewertet? Mehrere Standardrouten können beabsichtigt sein: - LAN und WLAN gleichzeitig, - VPN-Full-Tunnel, - redundante Router, - mehrere Internetanschlüsse, - virtuelle Adapter, - Mobilfunk-Fallback. **Windows** ```powershell [RO] Get-NetRoute -DestinationPrefix '0.0.0.0/0' | Sort-Object RouteMetric, InterfaceMetric | Format-Table InterfaceAlias, NextHop, RouteMetric, InterfaceMetric, Protocol ``` **Linux** ```bash [RO] ip route show default ``` ```bash [RO] ip rule show ``` **macOS** ```bash [RO] netstat -rn -f inet | grep '^default' ``` **Prüffragen** 1. Welche Route gehört zur aktiven Schnittstelle? 2. Welche Route besitzt die wirksame Priorität? 3. Gibt es spezifischere VPN-Routen? 4. Welche Quelladresse wird ausgewählt? 5. Passt der Rückweg zu dieser Quelladresse? 6. Ist eine Route nur ein verbliebener Eintrag eines getrennten Adapters? 7. Wird IPv4 anders als IPv6 geroutet? Die numerische Metrik ist nicht zwischen verschiedenen Betriebssystemen direkt vergleichbar.
12. Wie beeinflussen Schnittstellen- und Routenmetrik die Auswahl unter Windows? Windows berücksichtigt unter anderem: - Präfixlänge, - Routenmetrik, - Schnittstellenmetrik. Vereinfacht kann bei gleich spezifischen Routen eine Kombination aus Routen- und Schnittstellenmetrik die bevorzugte Route beeinflussen. **Schnittstellenmetriken** ```powershell [RO] Get-NetIPInterface | Format-Table InterfaceAlias, AddressFamily, AutomaticMetric, InterfaceMetric, ConnectionState ``` **Routenmetriken** ```powershell [RO] Get-NetRoute | Format-Table DestinationPrefix, NextHop, InterfaceAlias, RouteMetric, InterfaceMetric ``` Eine aktivierte automatische Metrik lässt Windows den Wert anhand der Schnittstelleneigenschaften bestimmen. ```text [CHANGE][DISRUPT] Metriken nicht verändern, nur weil eine numerische Reihenfolge unerwartet aussieht. Zuerst die tatsächlich gewählte Route mit Find-NetRoute prüfen. ```
13. Was ist eine Hostroute? Eine Hostroute gilt nur für eine einzelne Zieladresse. **IPv4** ```text 198.51.100.20/32 ``` **IPv6** ```text 2001:db8:20::20/128 ``` Beispiel: ```text 198.51.100.20/32 via 192.0.2.254 0.0.0.0/0 via 192.0.2.1 ``` Nur das Ziel `198.51.100.20` wird über `192.0.2.254` geleitet. Andere Ziele verwenden weiterhin die Standardroute. **Mögliche Fehler** - alte Hostroute zeigt auf nicht mehr vorhandenen Router, - VPN legt eine Hostroute zum VPN-Gateway an, - Sicherheitssoftware installiert spezifische Routen, - statische Testkonfiguration wurde nicht entfernt, - Route gilt nur für IPv4, während die Anwendung IPv6 verwendet.
14. Was ist Policy-Based Routing? Bei gewöhnlichem Routing wird hauptsächlich die Zieladresse betrachtet. Policy-Based Routing kann zusätzliche Kriterien verwenden: - Quellnetz, - eingehende Schnittstelle, - Benutzer oder Anwendung, - DSCP beziehungsweise Traffic-Klasse, - Firewallmarkierung, - Dienst oder Port, - Mandant oder VRF. **Linux-Regeln anzeigen** ```bash [RO] ip rule show ``` Beispielstruktur: ```text 0: from all lookup local 100: from 192.0.2.0/24 lookup firma-a 32766: from all lookup main 32767: from all lookup default ``` Tabelle anzeigen: ```bash [RO] ip route show table firma-a ``` Falls die Tabelle nur eine Nummer besitzt: ```bash [RO] ip route show table 100 ``` Eine korrekte Route in der `main`-Tabelle beweist bei Policy Routing nicht, dass sie für den konkreten Datenstrom verwendet wird.
15. Was ist eine VRF und warum ist sie für die Diagnose wichtig? Eine Virtual Routing and Forwarding Instance stellt eine getrennte Routingdomäne bereit. Vereinfacht: ```text Router ├─ VRF FIRMA-A │ └─ eigene Routingtabelle └─ VRF FIRMA-B └─ eigene Routingtabelle ``` Dieselben IP-Netze können in getrennten VRFs vorkommen, ohne direkt miteinander verbunden zu sein. **Mögliche Fehler** - Schnittstelle befindet sich in falscher VRF, - Route existiert nur in einer anderen VRF, - Firewall prüft falschen Kontext, - Managementzugriff verwendet eine getrennte VRF, - Ping ohne VRF-Angabe testet den falschen Pfad, - Rückroute wurde in falscher Tabelle eingetragen. Linux-VRFs anzeigen, falls verwendet: ```bash [RO] ip -d link show type vrf ``` Routen einer Tabelle: ```bash [RO] ip route show table TABELLENNAME ``` Befehle auf Routern und Firewalls sind herstellerabhängig und müssen im korrekten Routingkontext ausgeführt werden.
16. Wie wird ein fehlender Rückweg erkannt? Für eine funktionierende Kommunikation werden Hin- und Rückweg benötigt. ```text Hinweg: CLIENT-023 → Router A → SERVER-01 Rückweg: SERVER-01 → Router B → CLIENT-023 ``` Ein Rückweg darf anders verlaufen, muss aber: - zur Quelladresse führen, - von Firewalls zugelassen werden, - bei zustandsbehafteten Komponenten zur Sitzung passen, - notwendige NAT-Zustände berücksichtigen. **Typische Symptome eines fehlenden Rückwegs** - SYN verlässt Client, aber keine Antwort kommt zurück, - Anfrage erreicht Server, Antwort verlässt Server, - Antwort kommt an falscher Schnittstelle an, - nur Verbindungen aus einer Richtung funktionieren, - lokale Serverzugriffe funktionieren, entfernte nicht, - Ping vom Client zum Server schlägt fehl, vom Server zum Client ebenfalls, - Firewall meldet ungültigen oder fehlenden Sitzungszustand. **Prüfung** 1. Clientroute zum Server prüfen. 2. Serverroute zur Clientadresse prüfen. 3. Zwischenrouter und Firewalls prüfen. 4. NAT-Zustände berücksichtigen. 5. Paketmitschnitt an mindestens zwei geeigneten Messpunkten vergleichen.
17. Was ist asymmetrisches Routing? Beim asymmetrischen Routing nehmen Hin- und Rückweg unterschiedliche Pfade. ```text Hinweg: Client → Firewall A → Server Rückweg: Server → Firewall B → Client ``` Asymmetrisches Routing ist nicht grundsätzlich fehlerhaft. Es kann jedoch problematisch sein für: - zustandsbehaftete Firewalls, - NAT, - Intrusion-Prevention-Systeme, - Load Balancer, - Pfadmessungen, - MTU-Erkennung, - Paketmitschnitte an nur einer Stelle. **Typische Hinweise** - Firewall A sieht nur Clientpakete, - Firewall B sieht nur Serverantworten, - zustandslose Tests funktionieren, TCP jedoch nicht, - einzelne Verbindungen funktionieren abhängig von Lastverteilung, - Traceroute in Gegenrichtung zeigt anderen Pfad, - Failover führte zu unterschiedlichen Routingtabellen. Die ausführliche Analyse asymmetrischer Wege wird auf Seite 3.17 behandelt.
18. Wie wird der Netzwerkpfad mit tracert oder traceroute untersucht? **Windows** Ohne Namensauflösung: ```cmd [TEST] tracert -d 198.51.100.20 ``` Mit Zielname: ```cmd [TEST] tracert app.example.intern ``` **Linux** ```bash [TEST] traceroute -n 198.51.100.20 ``` **macOS** ```bash [TEST] traceroute -n 198.51.100.20 ``` **Prinzip** Traceroute sendet Pakete mit schrittweise erhöhtem TTL- beziehungsweise Hop-Limit-Wert. ```text TTL 1 → erster Router TTL 2 → zweiter Router TTL 3 → dritter Router ``` Ein Router, an dem der Wert abläuft, kann eine ICMP-Time-Exceeded-Nachricht zurücksenden. **Wichtig** - Router können Diagnosepakete nicht beantworten. - ICMP-Antworten können prioritätsreduziert behandelt werden. - Traceroute-Protokoll und Anwendungsprotokoll können unterschiedlich geroutet oder gefiltert werden. - Der sichtbare Pfad zeigt nur die antwortenden Hops. - Der Rückweg der ICMP-Antwort kann anders verlaufen. - Ein Sternchen beweist keinen Paketverlust des eigentlichen Anwendungsverkehrs.
19. Wie werden Sternchen in einer Traceroute interpretiert? Beispiel: ```text 1 192.0.2.1 1 ms 2 203.0.113.1 5 ms 3 * * * 4 198.51.100.20 12 ms ``` Da Hop 4 antwortet, hat Hop 3 den Verkehr offenbar weitergeleitet. Hop 3 beantwortet nur die Diagnoseanfrage nicht. **Mögliche Gründe für Sternchen** - Router sendet keine TTL-Exceeded-Antwort, - Antwort wird gefiltert, - Rate-Limit für ICMP, - Rückweg der Antwort fehlt, - Gerät priorisiert Weiterleitung höher als Managementantworten, - tatsächlicher Paketverlust. **Erst wenn alle nachfolgenden Hops ebenfalls fehlen**, kann ab dieser Stelle ein Problem vermutet werden. Selbst dann muss geprüft werden, ob das Ziel oder eine Firewall Diagnoseverkehr absichtlich blockiert.
20. Wie wird eine Routing-Schleife erkannt? Eine Routing-Schleife entsteht, wenn Router Pakete wiederholt gegenseitig weiterleiten. Beispiel: ```text Router A → Router B → Router A → Router B ``` Mögliche Traceroute-Ausgabe: ```text 5 192.0.2.1 6 192.0.2.2 7 192.0.2.1 8 192.0.2.2 9 192.0.2.1 ``` **Mögliche Ursachen** - widersprüchliche statische Routen, - fehlerhafte Default Routes, - Routingprotokollproblem, - fehlerhafte Routenumverteilung, - Zusammenfassungsroute ohne passende Detailroute, - Failoverzustand, - falsches Policy Routing, - Tunnelrouting. Die TTL beziehungsweise der Hop Limit verhindert, dass ein einzelnes Paket unbegrenzt zirkuliert. Die Schleife kann trotzdem fortlaufend neue Verbindungen beeinträchtigen.
21. Wie werden Paketverlust und Latenz entlang des Pfades bewertet? **Windows PathPing** ```cmd [TEST] pathping -n 198.51.100.20 ``` PathPing kombiniert eine Pfadermittlung mit längerfristigen Messungen zu den Hops. Die Ausführung kann mehrere Minuten dauern. **Linux und macOS mit MTR** Falls `mtr` installiert und freigegeben ist: ```bash [TEST] mtr -n -r -c 20 198.51.100.20 ``` | Option | Bedeutung | |---|---| | `-n` | keine Namensauflösung | | `-r` | Bericht erzeugen | | `-c 20` | 20 Messzyklen | **Interpretationsregel** ```text Paketverlust an einem Zwischenhop, aber kein Verlust an nachfolgenden Hops → wahrscheinlich nur reduzierte Antwortpriorität dieses Hops. ``` ```text Paketverlust beginnt an einem Hop und setzt sich bis zum Ziel fort → möglicher Verlust ab diesem Pfadabschnitt. ``` Auch dieses Muster ist nur ein Hinweis. Das verwendete Diagnoseprotokoll kann anders behandelt werden als die eigentliche Anwendung.
22. Wie wird ein bestimmter TCP-Dienst entlang des Pfades berücksichtigt? Ein erfolgreicher Traceroute beweist nicht, dass ein bestimmter Port zugelassen ist. **Windows** ```powershell [TEST] Test-NetConnection 198.51.100.20 ` -Port 443 ` -InformationLevel Detailed ``` **Linux** ```bash [TEST] nc -vz -w 5 198.51.100.20 443 ``` **macOS** ```bash [TEST] nc -vz -w 5 198.51.100.20 443 ``` Je nach `nc`-Implementierung können Optionen und Ausgabe abweichen. Lokale Hilfe prüfen: ```bash [RO] nc -h ``` **Bewertung** | Test | Erfolgreich | Fehlgeschlagen | |---|---|---| | Routingprüfung | IP-Pfad grundsätzlich vorhanden | Route, Filter oder Ziel offen | | TCP-Porttest | TCP-Verbindungsaufbau möglich | Filter, Dienst, Rückweg oder Routing offen | | Anwendungstest | Protokollantwort erhalten | Anwendung, Authentifizierung oder Backend offen |
23. Wie wird eine Route mit einem Paketmitschnitt bestätigt? Auf einem Ethernetclient zeigt die Ziel-MAC-Adresse, an welchen direkten Nachbarn das Paket übergeben wird. **Entferntes Ziel** ```text IP-Ziel: 198.51.100.20 Ethernet-Ziel: MAC-Adresse des Gateways ``` **Lokales Ziel** ```text IP-Ziel: 192.0.2.80 Ethernet-Ziel: MAC-Adresse des Zielsystems ``` **Wireshark-Filter** Bestimmtes Ziel: ```text ip.dst == 198.51.100.20 ``` IPv6: ```text ipv6.dst == 2001:db8:20::20 ``` TTL anzeigen beziehungsweise filtern: ```text ip.ttl ``` IPv6 Hop Limit: ```text ipv6.hlim ``` ICMP Time Exceeded: ```text icmp.type == 11 ``` ICMPv6 Time Exceeded: ```text icmpv6.type == 3 ``` Ein lokaler Mitschnitt zeigt nur den Verkehr am ausgewählten Interface. Er beweist nicht, wie nachfolgende Router das Paket weiterleiten.
24. Wie beeinflussen VPN-Verbindungen die Routingtabelle? Ein VPN kann folgende Routen installieren: - neue Standardroute, - spezifische Routen zu internen Netzen, - Hostroute zum VPN-Gateway, - ausgeschlossene lokale Routen, - IPv4- und IPv6-Routen, - richtlinienbasierte Routen. **Full Tunnel** ```text 0.0.0.0/0 → VPN ``` Der gesamte IPv4-Verkehr soll durch den Tunnel geführt werden. **Split Tunnel** ```text 10.0.0.0/8 → VPN 0.0.0.0/0 → lokales Gateway ``` Nur bestimmte Netze werden über das VPN erreicht. **Typische Fehler** - internes Netz fehlt in der Split-Tunnel-Liste, - lokales und entferntes Netz überschneiden sich, - VPN-Route ist spezifischer als lokale Route, - IPv6 wird nicht durch den Tunnel geführt, - Rückroute zum VPN-Adresspool fehlt, - Tunnelinterface bleibt nach Trennung bestehen, - Metriken und Policies wählen falschen Weg. **Vergleich** ```text Routingtabelle vor VPN-Verbindung Routingtabelle nach VPN-Verbindung ``` Dabei dürfen sensible interne Routen nur geschützt dokumentiert werden.
25. Wie werden überlappende Netze erkannt? **Beispiel** Lokales Heimnetz: ```text 192.168.1.0/24 ``` Entferntes Firmennetz über VPN: ```text 192.168.1.0/24 ``` Der Client kann nicht allein anhand der Zieladresse unterscheiden, ob `192.168.1.50` lokal oder über das VPN erreicht werden soll. Mögliche Auswirkungen: - internes Ziel wird im lokalen Netz gesucht, - ARP-Anfragen werden statt VPN-Verkehr erzeugt, - spezifische Hostrouten sind erforderlich, - nur einige Ziele funktionieren, - DNS liefert eine korrekte, aber lokal überlappende Adresse. **Prüfung** **Windows** ```powershell [RO] Find-NetRoute -RemoteIPAddress 192.168.1.50 ``` **Linux** ```bash [RO] ip route get 192.168.1.50 ``` **macOS** ```bash [RO] route -n get 192.168.1.50 ``` Die nachhaltige Lösung erfordert eine abgestimmte Adressplanung oder ein vorgesehenes VPN-/NAT-Konzept. Willkürliche Hostrouten sind häufig nur eine begrenzte Übergangslösung.
26. Wie werden dynamische Routingprotokolle berücksichtigt? Router können Routen dynamisch austauschen, beispielsweise über: - OSPF, - IS-IS, - BGP, - RIP, - herstellerspezifische Verfahren. Zu prüfen sind: - Nachbarschaftsstatus, - empfangene Routen, - angekündigte Routen, - bestes Pfadattribut, - letzte Zustandsänderung, - zurückgezogene Route, - Filter und Route Maps, - Routenumverteilung, - Zusammenfassungen, - gleiche Sicht auf redundanten Routern. **Typische Symptome** - Route fehlt nur auf einem Router, - Pfad ändert sich wiederholt, - nach Failover ist ein Netz nicht erreichbar, - spezifische Route wurde durch Zusammenfassung ersetzt, - Rückroute wird nicht angekündigt, - eine Route wird durch Policy gefiltert. Die konkreten Befehle sind router- und herstellerabhängig. Sie müssen anhand der offiziellen Dokumentation der eingesetzten Plattform ausgewählt werden.
27. Warum dürfen statische Routen nicht vorschnell hinzugefügt werden? Eine zusätzliche statische Route kann ein Symptom kurzfristig umgehen, aber: - dynamischen Routingfehler verdecken, - asymmetrischen Verkehr erzeugen, - falschen Router verwenden, - Sicherheitskontrollen umgehen, - nach einem Failover nicht mehr funktionieren, - zu einer Schleife führen, - nur auf einem einzelnen System gelten, - später vergessen werden. **Vorher dokumentieren** - aktuelle Routingtabelle, - vorgesehene Architektur, - Zielpräfix, - Next Hop, - Schnittstelle, - Metrik, - Persistenz, - Rückroute, - Firewall- und NAT-Auswirkungen, - Rückweg zur Entfernung der Route.
28. Welche eingreifenden Routingbefehle existieren? Die folgenden Beispiele verändern die Routingtabelle und sind keine regulären ersten Diagnoseschritte. **Windows – temporäre Route** ```powershell [PRIV][CHANGE][DISRUPT] New-NetRoute ` -DestinationPrefix '198.51.100.0/24' ` -InterfaceAlias 'Ethernet' ` -NextHop '192.0.2.254' ` -RouteMetric 10 ` -PolicyStore ActiveStore ``` Route entfernen: ```powershell [PRIV][CHANGE][DISRUPT] Remove-NetRoute ` -DestinationPrefix '198.51.100.0/24' ` -InterfaceAlias 'Ethernet' ` -NextHop '192.0.2.254' ``` **Linux – Route hinzufügen** ```bash [PRIV][CHANGE][DISRUPT] sudo ip route add \ 198.51.100.0/24 \ via 192.0.2.254 \ dev eth0 ``` Route entfernen: ```bash [PRIV][CHANGE][DISRUPT] sudo ip route del \ 198.51.100.0/24 \ via 192.0.2.254 \ dev eth0 ``` **macOS – temporäre Route hinzufügen** ```bash [PRIV][CHANGE][DISRUPT] sudo route -n add \ -net 198.51.100.0/24 \ 192.0.2.254 ``` Route entfernen: ```bash [PRIV][CHANGE][DISRUPT] sudo route -n delete \ -net 198.51.100.0/24 \ 192.0.2.254 ``` > Vor der Ausführung müssen Interface, Next Hop, Präfix und Rückweg geprüft werden. Eine falsche Route kann den Remotezugriff sofort unterbrechen. Temporäre Betriebssystemrouten sind außerdem nicht automatisch nach einem Neustart persistent.
29. Welche typischen Fehlinterpretationen müssen vermieden werden? | Beobachtung | Falscher Schluss | Richtige Einordnung | |---|---|---| | Standardroute vorhanden | Routing funktioniert | Next Hop und Rückweg prüfen | | Gateway antwortet auf Ping | alle Ziele sind erreichbar | nur ICMP zum Gateway bestätigt | | Traceroute zeigt Sterne | dort liegt der Fehler | Hop antwortet möglicherweise nur nicht | | hohe Zeit an einem Hop | dieser Hop bremst den Verkehr | Antwortpriorisierung kann abweichen | | Verlust an Zwischenhop | dort gehen Nutzdaten verloren | nachfolgende Hops vergleichen | | Zielroute ist sichtbar | sie wird verwendet | konkrete Auswahl zum Ziel prüfen | | niedrigste Metrik gewinnt immer | Route ist bevorzugt | längstes passendes Präfix zuerst | | Hinweg funktioniert | Verbindung muss funktionieren | Rückweg kann fehlen | | asymmetrischer Pfad | zwingend Fehlkonfiguration | kann beabsichtigt, aber für Stateful-Systeme problematisch sein | | Route hinzufügen behebt Zugriff | Ursache ist gelöst | ursprünglicher Routingfehler kann verdeckt sein | | VPN verbunden | interne Routen sind korrekt | konkrete Zielroute prüfen | | Ping über IP funktioniert | DNS und Anwendung funktionieren | nur IP-/ICMP-Test bestätigt |
30. Wie sieht der systematische Prüfablauf aus? | Schritt | Prüfung | |---:|---| | 1 | Quell- und Zieladresse eindeutig bestimmen | | 2 | Präfix des Clients prüfen | | 3 | feststellen, ob das Ziel lokal oder entfernt ist | | 4 | aktuelle Routingtabelle unverändert sichern | | 5 | ausgewählte Route zum konkreten Ziel bestimmen | | 6 | Ausgangsschnittstelle, Quelladresse und Next Hop prüfen | | 7 | direkten Next Hop über ARP beziehungsweise NDP kontrollieren | | 8 | Ziel per IP und passendem Dienst testen | | 9 | Pfad mit Traceroute oder vergleichbarem Werkzeug untersuchen | | 10 | Router- und Firewallrouting entlang des Pfades prüfen | | 11 | Rückroute vom Ziel zur tatsächlichen Quelladresse kontrollieren | | 12 | VPN, Policy Routing, VRF und NAT berücksichtigen | | 13 | Routingtabellen redundanter Systeme vergleichen | | 14 | Hypothese mit Mitschnitt oder gezieltem Test bestätigen | | 15 | Änderungen nur mit Freigabe und Rückweg durchführen | | 16 | Funktion und Nebenwirkungen abschließend prüfen | **Merksatz** ```text Ziel bestimmen → Longest Prefix Match → Quelladresse → Interface → Next Hop → Hinweg → Rückweg ```
31. Kompakte Befehlsübersicht für Windows, Linux und macOS | Aufgabe | Windows | Linux | macOS | |---|---|---|---| | IPv4-Routen | `[RO] Get-NetRoute -AddressFamily IPv4` | `[RO] ip -4 route` | `[RO] netstat -rn -f inet` | | IPv6-Routen | `[RO] Get-NetRoute -AddressFamily IPv6` | `[RO] ip -6 route` | `[RO] netstat -rn -f inet6` | | klassische Gesamtausgabe | `[RO] route print` | `[RO] ip route show table all` | `[RO] netstat -rn` | | IPv4-Standardroute | `[RO] Get-NetRoute -DestinationPrefix '0.0.0.0/0'` | `[RO] ip route show default` | `[RO] route -n get default` | | IPv6-Standardroute | `[RO] Get-NetRoute -DestinationPrefix '::/0'` | `[RO] ip -6 route show default` | `[RO] netstat -rn -f inet6` | | Route zu IPv4-Ziel | `[RO] Find-NetRoute -RemoteIPAddress ZIEL` | `[RO] ip route get ZIEL` | `[RO] route -n get ZIEL` | | Route zu IPv6-Ziel | `[RO] Find-NetRoute -RemoteIPAddress ZIEL` | `[RO] ip -6 route get ZIEL` | `[RO] route -n get -inet6 ZIEL` | | Routingregeln | Windows-Routingauswahl prüfen | `[RO] ip rule show` | Systemroutingtabelle prüfen | | Schnittstellenmetrik | `[RO] Get-NetIPInterface` | Routingmetriken in `ip route` | Routenflags und Dienstreihenfolge | | Pfad ohne DNS | `[TEST] tracert -d ZIEL` | `[TEST] traceroute -n ZIEL` | `[TEST] traceroute -n ZIEL` | | längere Pfadmessung | `[TEST] pathping -n ZIEL` | `[TEST] mtr -n -r -c 20 ZIEL` | `[TEST] mtr -n -r -c 20 ZIEL` | | TCP-Port prüfen | `[TEST] Test-NetConnection ZIEL -Port 443` | `[TEST] nc -vz -w 5 ZIEL 443` | `[TEST] nc -vz -w 5 ZIEL 443` | | Route hinzufügen | `[PRIV][CHANGE][DISRUPT] New-NetRoute …` | `[PRIV][CHANGE][DISRUPT] sudo ip route add …` | `[PRIV][CHANGE][DISRUPT] sudo route -n add …` | | Route entfernen | `[PRIV][CHANGE][DISRUPT] Remove-NetRoute …` | `[PRIV][CHANGE][DISRUPT] sudo ip route del …` | `[PRIV][CHANGE][DISRUPT] sudo route -n delete …` | `mtr` und teilweise `traceroute` sind nicht auf jeder Linux-Installation standardmäßig vorhanden. Fehlende Werkzeuge dürfen nur aus einer freigegebenen Paketquelle installiert werden.
32. Dokumentationsvorlage ```text Ticketnummer: Prüfzeitpunkt: Zeitzone: Betroffener Client: Standort: VLAN: VPN aktiv: Ja / Nein QUELLE Hostname: IPv4-Adresse/Präfix: IPv6-Adresse/Präfix: Schnittstelle: Schnittstellenindex: Schnittstellenmetrik: MAC-Adresse: ZIEL Hostname: Ziel-IPv4: Ziel-IPv6: Zielport: Transportprotokoll: Ziel laut Clientpräfix lokal: Ja / Nein AUSGEWÄHLTE ROUTE Adressfamilie: Zielpräfix: Präfixlänge: Quelladresse: Ausgangsschnittstelle: Next Hop: Routenmetrik: Schnittstellenmetrik: Routenursprung: Routingtabelle/VRF: Policy-Regel: Direkter Nachbar aufgelöst: Nachbar-MAC: STANDARDROUTEN IPv4-Standardroute: IPv4-Next-Hop: IPv4-Schnittstelle: IPv4-Metrik: IPv6-Standardroute: IPv6-Next-Hop: IPv6-Schnittstelle: IPv6-Metrik: PFAD Hop 1: Hop 2: Hop 3: Hop 4: Letzter antwortender Hop: Ziel erreicht: Sternchen oder Timeouts: Schleife erkennbar: Pfadänderungen: RÜCKWEG Tatsächliche Quelladresse: Route des Zielsystems zur Quelle: Next Hop des Zielsystems: Beteiligte Router: Beteiligte Firewalls: Asymmetrischer Weg: NAT beteiligt: Rückantwort am Ziel sichtbar: Rückantwort am Client sichtbar: VPN/POLICY ROUTING Full Tunnel oder Split Tunnel: Vom VPN installierte Route: Überlappendes lokales Netz: Policy-Regel: Separate Routingtabelle: Tunnelinterface: REFERENZVERGLEICH Referenzclient: Ausgewählte Route: Quelladresse: Next Hop: Pfad: Relevante Abweichungen: Arbeitshypothese: Begründung: Gesicherte Routingtabelle: Geplante Änderung: Freigabe: Rückweg: Tatsächliches Ergebnis: Abschlussprüfung: Ermittelte Ursache: ```
33. Offizielle Quellen und weiterführende Dokumentation **Microsoft** - [Get-NetRoute](https://learn.microsoft.com/powershell/module/nettcpip/get-netroute) - [Find-NetRoute](https://learn.microsoft.com/powershell/module/nettcpip/find-netroute) - [Get-NetIPInterface](https://learn.microsoft.com/powershell/module/nettcpip/get-netipinterface) - [New-NetRoute](https://learn.microsoft.com/powershell/module/nettcpip/new-netroute) - [Remove-NetRoute](https://learn.microsoft.com/powershell/module/nettcpip/remove-netroute) - [Test-NetConnection](https://learn.microsoft.com/powershell/module/nettcpip/test-netconnection) - [route](https://learn.microsoft.com/windows-server/administration/windows-commands/route_ws2008) - [tracert](https://learn.microsoft.com/windows-server/administration/windows-commands/tracert) - [pathping](https://learn.microsoft.com/windows-server/administration/windows-commands/pathping) **Linux** - [ip-route – Linux Manual Page](https://man7.org/linux/man-pages/man8/ip-route.8.html) - [ip-rule – Linux Manual Page](https://man7.org/linux/man-pages/man8/ip-rule.8.html) - [ip-vrf – Linux Manual Page](https://man7.org/linux/man-pages/man8/ip-vrf.8.html) - [traceroute – Linux Manual Page](https://man7.org/linux/man-pages/man8/traceroute.8.html) **Apple** - Lokale Befehlsreferenzen: `man route`, `man netstat`, `man traceroute` und `man nc` **Wireshark** - [IPv4 Display Filter Reference](https://www.wireshark.org/docs/dfref/i/ip.html) - [IPv6 Display Filter Reference](https://www.wireshark.org/docs/dfref/i/ipv6.html) - [ICMP Display Filter Reference](https://www.wireshark.org/docs/dfref/i/icmp.html) - [ICMPv6 Display Filter Reference](https://www.wireshark.org/docs/dfref/i/icmpv6.html) **Standards** - [RFC 1812 – Requirements for IPv4 Routers](https://www.rfc-editor.org/rfc/rfc1812) - [RFC 8200 – IPv6 Specification](https://www.rfc-editor.org/rfc/rfc8200) - [RFC 792 – Internet Control Message Protocol](https://www.rfc-editor.org/rfc/rfc792) - [RFC 4443 – ICMPv6](https://www.rfc-editor.org/rfc/rfc4443) > Routingbefehle auf Firewalls, Routern, Layer-3-Switches und VPN-Gateways sind herstellerabhängig. Für Änderungen muss die offizielle Dokumentation der tatsächlich eingesetzten Plattform verwendet werden.
# 3.8 DNS-Fehler systematisch analysieren Das Domain Name System ordnet Namen technischen Informationen zu. Dazu gehören insbesondere IPv4- und IPv6-Adressen, zuständige Nameserver, Mailserver, Dienstinformationen und Validierungsdaten. Ein DNS-Fehler liegt nahe, wenn ein Dienst über seine IP-Adresse erreichbar ist, aber nicht über seinen Namen. Dieser Vergleich ist jedoch nur dann aussagekräftig, wenn der Dienst einen direkten Zugriff über die IP-Adresse technisch unterstützt. HTTPS, virtuelle Webserver und Load Balancer benötigen häufig zusätzlich den korrekten Hostnamen. > **Grundregel:** Zuerst ermitteln, welcher Name von welchem Client über welchen Resolver aufgelöst werden soll. Danach Antwort, Fehlerstatus, Autorität, Cache, Transportweg und tatsächliche Nutzung durch die Anwendung prüfen. ---
1. Welche Aufgaben erfüllt DNS? DNS kann unter anderem folgende Informationen bereitstellen: | Recordtyp | Aufgabe | |---|---| | `A` | Name zu IPv4-Adresse | | `AAAA` | Name zu IPv6-Adresse | | `CNAME` | Alias auf einen anderen Namen | | `MX` | zuständige Mailserver | | `NS` | autoritative Nameserver einer Zone | | `SOA` | grundlegende Verwaltungsinformationen einer Zone | | `PTR` | IP-Adresse zu Name bei Reverse DNS | | `TXT` | frei definierte Textinformationen und Verifikationsdaten | | `SRV` | Dienst, Zielhost, Port, Priorität und Gewichtung | | `CAA` | zulässige Zertifizierungsstellen | | `DS` | Verweis in der DNSSEC-Vertrauenskette | | `DNSKEY` | öffentlicher DNSSEC-Schlüssel | | `RRSIG` | DNSSEC-Signatur eines Recordsets | **Beispiel** ```text app.example.intern → CNAME proxy.example.intern → A 192.0.2.20 → AAAA 2001:db8:20::20 ``` Die Anwendung kann am Ende IPv4 oder IPv6 verwenden. Daher müssen alle beteiligten Records und der tatsächlich gewählte Zielendpunkt berücksichtigt werden.
2. Welche Symptome sprechen für ein DNS-Problem? - Name kann nicht aufgelöst werden, - IP-Adresse funktioniert, Name jedoch nicht, - falsche IP-Adresse wird zurückgegeben, - interne Namen funktionieren nur im Firmennetz, - Auflösung funktioniert ohne VPN, aber nicht mit VPN, - Auflösung funktioniert mit VPN, aber nicht ohne VPN, - einzelne Clients erhalten andere Antworten, - Antwort wechselt zwischen alten und neuen Adressen, - IPv4 funktioniert, IPv6-Verbindung schlägt fehl, - Reverse-Auflösung fehlt, - DNS-Abfragen laufen in ein Timeout, - Antwort lautet `NXDOMAIN`, `SERVFAIL` oder `REFUSED`, - Suchsuffix erzeugt einen falschen vollständigen Namen, - Anwendung verwendet trotz erfolgreicher manueller Abfrage eine alte Adresse, - Browser und Terminal liefern unterschiedliche Ergebnisse, - nur bestimmte Recordtypen schlagen fehl, - DNSSEC-validierende Resolver lehnen eine Zone ab, - ein nicht vorgesehener DNS-Server wird verwendet, - lokale Hosts-Datei überschreibt die DNS-Antwort.
3. Welche Informationen müssen vor der Analyse erfasst werden? | Information | Beispiel | |---|---| | betroffener Client | `CLIENT-023` | | Betriebssystem | Windows 11 | | betroffener Name | `app.example.intern` | | vollständig qualifizierter Name | `app.example.intern.` | | erwarteter Recordtyp | `A` und `AAAA` | | erwartete IPv4-Adresse | `192.0.2.20` | | erwartete IPv6-Adresse | `2001:db8:20::20` | | verwendeter DNS-Server | `192.0.2.53` | | vorgesehener DNS-Server | `192.0.2.53` | | DNS-Suchdomäne | `example.intern` | | VPN aktiv | Ja | | Fehlerbeginn | `2026-07-31 09:42 CEST` | | letzter funktionierender Zeitpunkt | `2026-07-31 09:35 CEST` | | exakte Fehlermeldung | Name konnte nicht aufgelöst werden | | betroffene Anwendung | Browser | | Vergleichsclient | `CLIENT-024` funktioniert | Zusätzlich sollte geprüft werden: - IPv4- und IPv6-Konnektivität zum Resolver, - Proxy- und VPN-Konfiguration, - lokale Hosts-Datei, - Browserfunktionen wie DNS over HTTPS, - DNS-Cache, - zuständige Zone und autoritative Server.
4. Wie läuft eine rekursive DNS-Auflösung vereinfacht ab? ```text Client → rekursiver Resolver → Root-Nameserver → TLD-Nameserver → autoritativer Nameserver → rekursiver Resolver → Client ``` Für interne Zonen kann der Ablauf anders sein: ```text Client → interner Resolver → interne autoritative Zone → Client ``` Oder über einen Conditional Forwarder: ```text Client → lokaler Resolver → bedingte Weiterleitung für partner.example → Resolver des Partners → autoritative Antwort ``` Caches können den vollständigen Ablauf verkürzen. Eine vorhandene Cacheantwort muss nicht jedes Mal erneut beim autoritativen Server abgefragt werden.
5. Was ist der Unterschied zwischen rekursivem und autoritativem DNS-Server? | Serverrolle | Aufgabe | |---|---| | rekursiver Resolver | ermittelt Antworten im Auftrag des Clients und speichert sie möglicherweise im Cache | | autoritativer Nameserver | liefert verbindliche Daten für eine von ihm verwaltete Zone | | Forwarder | leitet Abfragen an einen anderen Resolver weiter | | Conditional Forwarder | leitet nur bestimmte DNS-Namensräume an definierte Resolver weiter | | Stub Resolver | DNS-Komponente auf dem Endgerät, die Resolver befragt | Ein DNS-Server kann abhängig von Produkt und Konfiguration mehrere Rollen übernehmen. **Wichtige Diagnosefrage** ```text Ist die falsche Antwort bereits auf dem autoritativen Server vorhanden oder entsteht sie erst durch Cache, Weiterleitung oder Clientkonfiguration? ```
6. Welche Ports und Transportprotokolle verwendet DNS? DNS verwendet grundsätzlich: | Transport | Port | Typischer Einsatz | |---|---:|---| | UDP | 53 | viele gewöhnliche Abfragen und Antworten | | TCP | 53 | große Antworten, Wiederholungen nach Truncation und Zonentransfers | | TCP | 853 | DNS over TLS | | TCP | 443 | DNS over HTTPS | | UDP | 443 | DNS over HTTP/3 kann über QUIC verwendet werden | **Wichtig** Eine Firewallregel, die nur UDP 53 erlaubt, kann DNS teilweise funktionieren lassen und bei bestimmten Antworten dennoch Fehler verursachen. Mögliche Ursachen für den Wechsel zu TCP: - Antwort ist für den verwendeten UDP-Transport zu groß, - Antwort wurde als gekürzt markiert, - DNSSEC vergrößert die Antwort, - Anwendung oder Resolver verwendet von Anfang an TCP, - Zonentransfer wird durchgeführt.
7. Wie wird die DNS-Clientkonfiguration unter Windows geprüft? **DNS-Server je Schnittstelle** ```powershell [RO] Get-DnsClientServerAddress | Format-Table InterfaceAlias, InterfaceIndex, AddressFamily, ServerAddresses ``` **DNS-Clientkonfiguration** ```powershell [RO] Get-DnsClient | Format-Table InterfaceAlias, InterfaceIndex, ConnectionSpecificSuffix, RegisterThisConnectionsAddress, UseSuffixWhenRegistering ``` **Vollständige IP-Konfiguration** ```cmd [RO][SENS] ipconfig /all ``` Zu prüfen sind: - DNS-Server, - verbindungsspezifisches DNS-Suffix, - primäres DNS-Suffix, - DNS-Suffixsuchliste, - Schnittstellenreihenfolge, - VPN-Adapter, - virtuelle Adapter. **DNS-over-HTTPS-Konfiguration** Je nach Windows-Version: ```powershell [RO] Get-DnsClientDohServerAddress ``` Das Cmdlet kann abhängig von Windows-Version und installiertem PowerShell-Modul nicht verfügbar sein.
8. Wie werden DNS-Abfragen unter Windows mit Resolve-DnsName durchgeführt? **Standardabfrage** ```powershell [TEST] Resolve-DnsName app.example.intern ``` **A-Record** ```powershell [TEST] Resolve-DnsName app.example.intern -Type A ``` **AAAA-Record** ```powershell [TEST] Resolve-DnsName app.example.intern -Type AAAA ``` **CNAME** ```powershell [TEST] Resolve-DnsName app.example.intern -Type CNAME ``` **MX** ```powershell [TEST] Resolve-DnsName example.com -Type MX ``` **SRV** ```powershell [TEST] Resolve-DnsName ` _ldap._tcp.example.intern ` -Type SRV ``` **PTR beziehungsweise Reverse DNS** ```powershell [TEST] Resolve-DnsName 192.0.2.20 -Type PTR ``` **Bestimmten DNS-Server abfragen** ```powershell [TEST] Resolve-DnsName ` app.example.intern ` -Type A ` -Server 192.0.2.53 ``` **Nur DNS verwenden und zusätzliche lokale Namensauflösungsmechanismen vermeiden** ```powershell [TEST] Resolve-DnsName ` app.example.intern ` -Type A ` -DnsOnly ``` **TCP erzwingen** ```powershell [TEST] Resolve-DnsName ` app.example.intern ` -Type A ` -TcpOnly ``` Mit `-TcpOnly` kann geprüft werden, ob DNS über TCP 53 funktioniert.
9. Wie wird nslookup unter Windows, Linux und macOS verwendet? **Einfache Abfrage** ```bash [TEST] nslookup app.example.intern ``` **Bestimmten Server abfragen** ```bash [TEST] nslookup app.example.intern 192.0.2.53 ``` **Bestimmten Recordtyp abfragen** ```bash [TEST] nslookup -type=AAAA app.example.intern 192.0.2.53 ``` ```bash [TEST] nslookup -type=MX example.com 192.0.2.53 ``` **Reverse DNS** ```bash [TEST] nslookup 192.0.2.20 192.0.2.53 ``` `nslookup` ist weit verbreitet, bildet aber nicht zwingend denselben Auflösungsweg ab wie eine Anwendung oder der native Systemresolver. Für eine vollständige Analyse sollten zusätzlich die betriebssystemspezifischen Werkzeuge verwendet werden.
10. Wie wird die DNS-Clientkonfiguration unter Linux geprüft? **systemd-resolved** ```bash [RO] resolvectl status ``` Bestimmte Schnittstelle: ```bash [RO] resolvectl status eth0 ``` Zu prüfen sind: - aktueller DNS-Server, - konfigurierte DNS-Server, - DNS-Domänen, - Default-Route für DNS, - DNSSEC-Einstellung, - DNS-over-TLS-Einstellung, - schnittstellenbezogene Resolver. **Resolverdatei** ```bash [RO] cat /etc/resolv.conf ``` Prüfen, ob es sich um einen symbolischen Link handelt: ```bash [RO] ls -l /etc/resolv.conf ``` Beispiel: ```text nameserver 127.0.0.53 search example.intern options edns0 trust-ad ``` `127.0.0.53` kann auf den lokalen Stub Resolver von systemd-resolved verweisen. Der tatsächlich verwendete Upstream-DNS-Server muss dann mit `resolvectl status` bestimmt werden. **NetworkManager** ```bash [RO][SENS] nmcli device show | grep -E 'GENERAL.DEVICE|IP4.DNS|IP6.DNS|IP4.DOMAIN|IP6.DOMAIN' ```
11. Wie werden DNS-Abfragen unter Linux mit resolvectl durchgeführt? **Systemresolver verwenden** ```bash [TEST] resolvectl query app.example.intern ``` **Bestimmten Recordtyp abfragen** ```bash [TEST] resolvectl query \ --type=A \ app.example.intern ``` ```bash [TEST] resolvectl query \ --type=AAAA \ app.example.intern ``` **Bestimmte Schnittstelle verwenden** ```bash [TEST] resolvectl query \ --interface=eth0 \ app.example.intern ``` **Resolverstatistik** ```bash [RO] resolvectl statistics ``` **Serverfunktionen zurücksetzen beziehungsweise Cache leeren** Diese Befehle verändern den Resolverzustand und gehören nicht zur ersten Analyse: ```bash [PRIV][CHANGE] sudo resolvectl reset-statistics ``` ```bash [PRIV][CHANGE] sudo resolvectl flush-caches ``` Vor dem Leeren sollte die vorhandene Antwort dokumentiert werden.
12. Wie werden DNS-Abfragen mit dig durchgeführt? `dig` ist nicht auf jedem System standardmäßig installiert. **A- und AAAA-Abfrage** ```bash [TEST] dig app.example.intern A ``` ```bash [TEST] dig app.example.intern AAAA ``` **Bestimmten Resolver abfragen** ```bash [TEST] dig @192.0.2.53 app.example.intern A ``` **Kurze Ausgabe** ```bash [TEST] dig +short @192.0.2.53 app.example.intern A ``` **Vollständige Antwort mit Kommentaren** ```bash [TEST] dig @192.0.2.53 app.example.intern A ``` **TCP verwenden** ```bash [TEST] dig +tcp @192.0.2.53 app.example.intern A ``` **DNSSEC-Daten anfordern** ```bash [TEST] dig +dnssec @192.0.2.53 example.com A ``` **Autoritative Nameserver einer Zone** ```bash [TEST] dig @192.0.2.53 example.intern NS ``` **SOA-Record** ```bash [TEST] dig @192.0.2.53 example.intern SOA ``` **Reverse-Auflösung** ```bash [TEST] dig -x 192.0.2.20 @192.0.2.53 ``` **Delegationsweg verfolgen** ```bash [TEST] dig +trace example.com ``` `dig +trace` befragt die DNS-Hierarchie schrittweise selbst. Es entspricht nicht dem normalen rekursiven Weg über den konfigurierten Resolver und kann durch Firewalls oder interne Zonen eingeschränkt sein.
13. Welche Felder einer dig-Ausgabe sind wichtig? Beispielstruktur: ```text ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12345 ;; flags: qr rd ra ;; QUESTION SECTION: ;app.example.intern. IN A ;; ANSWER SECTION: app.example.intern. 300 IN A 192.0.2.20 ;; Query time: 12 msec ;; SERVER: 192.0.2.53#53 ;; WHEN: ... ;; MSG SIZE rcvd: ... ``` | Feld | Bedeutung | |---|---| | `status` | DNS-Antwortstatus | | `id` | Transaktions-ID | | `qr` | Nachricht ist eine Antwort | | `aa` | autoritative Antwort | | `tc` | Antwort wurde gekürzt | | `rd` | Rekursion wurde angefordert | | `ra` | Rekursion ist verfügbar | | `ad` | validierende Stelle kennzeichnet Daten als authentifiziert | | `cd` | Client fordert deaktivierte DNSSEC-Prüfung | | `ANSWER` | eigentliche Antwortrecords | | `AUTHORITY` | zuständige beziehungsweise autoritative Informationen | | `ADDITIONAL` | zusätzliche hilfreiche Records | | `TTL` | verbleibende Cachelebensdauer | | `SERVER` | tatsächlich abgefragter Resolver | | `Query time` | gemessene Abfragedauer | Das `ad`-Flag muss im Zusammenhang mit dem befragten validierenden Resolver bewertet werden. Es beweist nicht, dass der lokale Client selbst die gesamte DNSSEC-Kette validiert hat.
14. Wie wird die DNS-Konfiguration unter macOS geprüft? **Aktuelle Resolverkonfiguration** ```bash [RO][SENS] scutil --dns ``` macOS kann mehrere Resolverkonfigurationen parallel besitzen, beispielsweise für: - allgemeine Anfragen, - VPN-Domänen, - bestimmte Suchdomänen, - Multicast DNS, - schnittstellenbezogene Namensräume. **DNS-Server eines Netzwerkdienstes** ```bash [RO] networksetup -getdnsservers "Wi-Fi" ``` **Suchdomänen** ```bash [RO] networksetup -getsearchdomains "Wi-Fi" ``` **IP-Konfiguration** ```bash [RO] networksetup -getinfo "Wi-Fi" ``` Der tatsächliche Netzwerkdienst muss vorher bestimmt werden: ```bash [RO] networksetup -listallnetworkservices ``` **Hosts-Auflösung über Systemmechanismen** ```bash [TEST] dscacheutil -q host -a name app.example.intern ``` Dieser Test bildet den macOS-Systemresolver besser ab als eine direkte Abfrage eines einzelnen DNS-Servers mit `dig`.
15. Warum können dig und eine Anwendung unterschiedliche Ergebnisse liefern? `dig` sendet eine direkte DNS-Abfrage. Eine Anwendung kann dagegen weitere Mechanismen verwenden: - Systemresolver, - lokale Hosts-Datei, - DNS-Cache des Betriebssystems, - eigener Anwendungscache, - Browsercache, - DNS over HTTPS, - VPN-spezifischer Resolver, - Multicast DNS, - Suchsuffixe, - Proxy, - Sicherheitssoftware, - andere Reihenfolge von IPv4 und IPv6. **Beispiel** ```text dig @192.0.2.53 app.example.intern → 192.0.2.20 Browser → verwendet eigenen DoH-Resolver → erhält keine interne Adresse ``` Deshalb sollten mindestens zwei Ebenen geprüft werden: 1. direkte DNS-Serverantwort, 2. tatsächliche Auflösung über das Betriebssystem beziehungsweise die Anwendung.
16. Wie wird die lokale Hosts-Datei geprüft? Ein Eintrag in der Hosts-Datei kann DNS für den betreffenden Namen übersteuern. **Windows** ```powershell [RO][PRIV][SENS] Get-Content ` "$env:SystemRoot\System32\drivers\etc\hosts" ``` Nicht auskommentierte Zeilen anzeigen: ```powershell [RO][PRIV][SENS] Get-Content ` "$env:SystemRoot\System32\drivers\etc\hosts" | Where-Object { $_.Trim() -and -not $_.Trim().StartsWith('#') } ``` **Linux** ```bash [RO][SENS] cat /etc/hosts ``` **macOS** ```bash [RO][SENS] cat /etc/hosts ``` **Typische Probleme** - veraltete Testadresse, - falscher Hostname, - Eintrag wurde von Software ergänzt, - IPv4- und IPv6-Einträge widersprechen sich, - Eintrag existiert nur auf einem Client, - Eintrag besitzt unsichtbare Formatierungsfehler. Hosts-Dateien dürfen nicht vorschnell geändert werden. Zuerst müssen Ursprung, Zweck und Konfigurationsmanagement geklärt werden.
17. Wie beeinflusst ein DNS-Suchsuffix die Auflösung? Ein nicht vollständig qualifizierter Name kann durch eine Suchdomäne ergänzt werden. Eingabe: ```text app ``` Suchdomäne: ```text example.intern ``` Mögliche Anfrage: ```text app.example.intern ``` Bei mehreren Suchdomänen können mehrere Abfragen entstehen: ```text app.berlin.example.intern app.example.intern app ``` **Prüfung unter Windows** ```powershell [RO] Get-DnsClient | Select-Object InterfaceAlias, ConnectionSpecificSuffix ``` Zusätzlich: ```cmd [RO][SENS] ipconfig /all ``` **Linux** ```bash [RO] resolvectl status ``` ```bash [RO] cat /etc/resolv.conf ``` **macOS** ```bash [RO][SENS] scutil --dns ``` **Sicherer Vergleich** ```text Kurzname: app Vollqualifizierter Name: app.example.intern. ``` Der abschließende Punkt kennzeichnet in DNS-Werkzeugen einen absoluten Namen und verhindert dort normalerweise die Ergänzung eines Suchsuffixes.
18. Wie werden DNS-Antwortstatus richtig interpretiert? | Status | Bedeutung | |---|---| | `NOERROR` mit Antwort | Abfrage war erfolgreich und enthält Antwortdaten | | `NOERROR` ohne gesuchten Record | Name kann existieren, aber Recordtyp fehlt | | `NXDOMAIN` | abgefragter Name existiert laut Antwort nicht | | `SERVFAIL` | Server konnte keine gültige Antwort liefern | | `REFUSED` | Server verweigert die Abfrage | | `FORMERR` | Abfrageformat wurde als fehlerhaft bewertet | | `NOTIMP` | Operation wird nicht unterstützt | | Timeout | keine rechtzeitige verwertbare Antwort erhalten | **Wichtige Unterscheidung** ```text NXDOMAIN: Der Name existiert laut DNS-Antwort nicht. NOERROR ohne A-Record: Der Name kann existieren, besitzt aber keinen A-Record. ``` **SERVFAIL kann unter anderem entstehen durch:** - DNSSEC-Validierungsfehler, - nicht erreichbaren autoritativen Server, - fehlerhafte Delegation, - Timeout bei Weiterleitung, - Serverfehler, - beschädigte Zone, - fehlende Erreichbarkeit über TCP, - Schleife zwischen Forwardern.
19. Wie wird zwischen NXDOMAIN und fehlendem Recordtyp unterschieden? **A-Record abfragen** ```bash [TEST] dig @192.0.2.53 app.example.intern A ``` Mögliche Ergebnisse: **Fall 1 – Name existiert nicht** ```text status: NXDOMAIN ``` **Fall 2 – Name existiert, besitzt aber keinen A-Record** ```text status: NOERROR ANSWER: 0 ``` Im Authority-Bereich kann ein SOA-Record erscheinen. **Fall 3 – Name besitzt nur AAAA** ```bash [TEST] dig @192.0.2.53 app.example.intern AAAA ``` liefert eine IPv6-Adresse. Diese Unterscheidung ist wichtig, weil das Anlegen eines A-Records bei einem vollständig falschen Namen eine andere Maßnahme wäre als das Ergänzen eines fehlenden Recordtyps.
20. Wie werden CNAME-Ketten untersucht? **Direkte Abfrage** ```bash [TEST] dig @192.0.2.53 app.example.intern CNAME ``` **Vollständige Auflösung** ```bash [TEST] dig @192.0.2.53 app.example.intern A ``` Mögliche Kette: ```text app.example.intern → CNAME proxy.example.intern → CNAME proxy-berlin.example.net → A 192.0.2.20 ``` Zu prüfen sind: - existiert jedes Ziel der Kette? - besitzt das letzte Ziel einen passenden A- oder AAAA-Record? - verweist ein CNAME auf sich selbst? - existiert eine Schleife? - überschreitet die Kette Grenzen zwischen internen und externen Zonen? - stimmt die TTL der beteiligten Records? - passt das TLS-Zertifikat weiterhin zum ursprünglich verwendeten Namen? Der erfolgreiche Abschluss der DNS-Kette beweist noch nicht, dass die Anwendung oder das Zertifikat korrekt ist.
21. Wie wird Split DNS beziehungsweise Split-Horizon DNS geprüft? Bei Split DNS liefert derselbe Name abhängig vom verwendeten Resolver oder Standort unterschiedliche Antworten. **Interner Resolver** ```text app.example.com → 192.0.2.20 ``` **Öffentlicher Resolver** ```text app.example.com → 203.0.113.20 ``` Dies kann beabsichtigt sein. **Vergleichsabfragen** ```bash [TEST] dig @192.0.2.53 app.example.com A ``` ```bash [TEST] dig @ÖFFENTLICHER-RESOLVER app.example.com A ``` Ein öffentlicher Resolver darf nur verwendet werden, wenn dies nach Unternehmensrichtlinie zulässig und aus dem Netz erreichbar ist. **Typische Fehler** - VPN verwendet öffentlichen statt internen Resolver, - interne Zone fehlt auf einem Standort, - Conditional Forwarder fehlt, - Browser umgeht internen DNS per DoH, - Antwort aus öffentlichem Cache wird verwendet, - interne und externe Records wurden verwechselt.
22. Wie beeinflussen VPN und schnittstellenbezogenes DNS die Auflösung? Ein VPN kann: - eigene DNS-Server setzen, - nur bestimmte Domänen über interne Resolver leiten, - alle DNS-Anfragen übernehmen, - Suchdomänen hinzufügen, - DNS over HTTPS blockieren oder konfigurieren, - IPv4 und IPv6 unterschiedlich behandeln. **Prüfung vor und nach VPN-Verbindung** | Eigenschaft | vor VPN | nach VPN | |---|---|---| | DNS-Server | dokumentieren | dokumentieren | | Suchdomänen | dokumentieren | dokumentieren | | Routen zum DNS-Server | dokumentieren | dokumentieren | | A-Antwort | vergleichen | vergleichen | | AAAA-Antwort | vergleichen | vergleichen | | Systemresolver | vergleichen | vergleichen | **Windows** ```powershell [RO] Get-DnsClientServerAddress ``` **Linux** ```bash [RO] resolvectl status ``` **macOS** ```bash [RO][SENS] scutil --dns ``` Ein interner DNS-Server kann korrekt eingetragen sein, aber über die aktuelle Routingtabelle nicht erreichbar sein. Deshalb muss zusätzlich die Route zum Resolver geprüft werden.
23. Wie wird die Erreichbarkeit des DNS-Servers geprüft? **Route zum Resolver** Windows: ```powershell [RO] Find-NetRoute -RemoteIPAddress 192.0.2.53 ``` Linux: ```bash [RO] ip route get 192.0.2.53 ``` macOS: ```bash [RO] route -n get 192.0.2.53 ``` **TCP-Port 53 testen** Windows: ```powershell [TEST] Test-NetConnection 192.0.2.53 -Port 53 ``` Linux und macOS: ```bash [TEST] nc -vz -w 5 192.0.2.53 53 ``` Dieser Test prüft nur TCP 53. **Tatsächliche DNS-Abfrage über UDP** ```bash [TEST] dig @192.0.2.53 app.example.intern A ``` **Tatsächliche DNS-Abfrage über TCP** ```bash [TEST] dig +tcp @192.0.2.53 app.example.intern A ``` **Auswertung** | UDP-Abfrage | TCP-Abfrage | Mögliche Richtung | |---|---|---| | erfolgreich | erfolgreich | Transport grundsätzlich verfügbar | | erfolgreich | fehlerhaft | TCP 53, Firewall oder Serverlistener prüfen | | fehlerhaft | erfolgreich | UDP 53, Fragmentierung oder Filter prüfen | | fehlerhaft | fehlerhaft | Route, Firewall, Server oder falsche Adresse |
24. Wie werden große DNS-Antworten und das TC-Flag untersucht? Das DNS-Headerflag `TC` bedeutet, dass eine Antwort gekürzt wurde. Vereinfachter Ablauf: ```text Client → DNS-Abfrage über UDP Server → gekürzte Antwort mit TC=1 Client → Wiederholung über TCP Server → vollständige Antwort über TCP ``` **dig-Ausgabe über UDP** ```bash [TEST] dig @192.0.2.53 example.com DNSKEY ``` **Vergleich über TCP** ```bash [TEST] dig +tcp @192.0.2.53 example.com DNSKEY ``` **Wireshark-Display-Filter** ```text dns.flags.truncated == 1 ``` Mögliche Fehlerursachen: - TCP 53 wird blockiert, - Fragmentierung oder MTU-Problem, - Firewall verwirft große UDP-Antworten, - EDNS wird fehlerhaft behandelt, - Resolver oder Middlebox arbeitet nicht standardkonform.
25. Wie werden TTL und DNS-Caching interpretiert? TTL steht für Time to Live und gibt an, wie lange ein DNS-Record gecacht werden darf. **Beispiel** ```text app.example.intern. 300 IN A 192.0.2.20 ``` TTL: ```text 300 Sekunden = 5 Minuten ``` Nach einer Änderung können Resolver die alte Antwort bis zum Ablauf der noch vorhandenen TTL verwenden. **Wichtig** - verschiedene Resolver können unterschiedliche verbleibende TTLs besitzen, - Anwendungen können zusätzlich eigene Caches verwenden, - negative Antworten können ebenfalls gecacht werden, - Browser können eigene DNS-Zustände verwalten, - Load Balancer können mehrere Adressen liefern, - alte Antworten müssen nicht auf allen Clients gleichzeitig verschwinden. **Vergleich zu unterschiedlichen Zeitpunkten** ```bash [TEST] dig @192.0.2.53 app.example.intern A ``` Zu dokumentieren: - Antwortadresse, - TTL, - Server, - Zeitpunkt, - Antwortstatus.
26. Was ist negatives DNS-Caching? Auch negative Antworten wie `NXDOMAIN` oder das Fehlen eines bestimmten Recordtyps können zeitweise gecacht werden. Mögliche Situation: ```text 09:00 Name existiert noch nicht. 09:01 Client fragt und erhält NXDOMAIN. 09:05 Record wird angelegt. 09:06 Client erhält weiterhin die gecachte negative Antwort. ``` Die Dauer des negativen Cachings hängt unter anderem von den Zonen- und Resolverinformationen ab. **Diagnose** - autoritativen Server direkt abfragen, - rekursiven Resolver abfragen, - Systemresolver abfragen, - Antwortstatus und SOA-Informationen vergleichen, - Zeitpunkt der Recordänderung dokumentieren. Ein Cache sollte erst geleert werden, nachdem die ursprüngliche Antwort und deren TTL gesichert wurden.
27. Wie wird der DNS-Cache unter Windows geprüft? **Cache anzeigen** ```powershell [RO] Get-DnsClientCache ``` Nach einem Namen suchen: ```powershell [RO] Get-DnsClientCache | Where-Object Entry -Match 'app\.example\.intern' ``` **Klassische Anzeige** ```cmd [RO] ipconfig /displaydns ``` **Cache exportieren** ```powershell [RO][FILE][SENS] Get-DnsClientCache | Export-Csv 'C:\Temp\dns-cache-vorher.csv' ` -NoTypeInformation ` -Encoding UTF8 ``` Der Cache kann interne Namen und aufgerufene Ziele enthalten und ist daher als sensibel zu behandeln.
28. Wann darf ein DNS-Cache geleert werden? Das Leeren des Caches verändert den Diagnosezustand und kann eine fehlerhafte Antwort nur vorübergehend verbergen. **Windows** ```powershell [PRIV][CHANGE] Clear-DnsClientCache ``` Alternative: ```cmd [PRIV][CHANGE] ipconfig /flushdns ``` **Linux mit systemd-resolved** ```bash [PRIV][CHANGE] sudo resolvectl flush-caches ``` Andere Linux-Resolver besitzen eigene Verfahren. Es existiert kein allgemeiner Befehl für alle Linux-Systeme. **macOS** ```bash [PRIV][CHANGE] sudo dscacheutil -flushcache ``` Anschließend kann abhängig von macOS-Version zusätzlich ein HUP-Signal an den DNS-Responder erforderlich sein: ```bash [PRIV][CHANGE] sudo killall -HUP mDNSResponder ``` Diese macOS-Befehle sollten nur nach Prüfung der eingesetzten Version und lokalen Dokumentation verwendet werden. **Vorher sichern** - aktuelle Antwort, - TTL, - verwendeter Resolver, - Betriebssystemcache, - Anwendungszustand, - Zeitpunkt.
29. Wie werden autoritative DNS-Daten geprüft? **Zuständige Nameserver ermitteln** ```bash [TEST] dig @192.0.2.53 example.intern NS ``` **SOA-Record prüfen** ```bash [TEST] dig @192.0.2.53 example.intern SOA ``` **Autoritativen Server direkt abfragen** ```bash [TEST] dig @AUTORITATIVER-SERVER app.example.intern A ``` In der Antwort sollte bei einer autoritativen Antwort typischerweise das `aa`-Flag erscheinen. **Zu prüfen** - richtige Zone, - richtiger Record, - korrekte Adresse, - TTL, - Seriennummer der Zone, - Replikationsstand, - primärer und sekundärer Nameserver, - Delegation, - DNSSEC-Signaturen, - unterschiedliche Antworten mehrerer autoritativer Server. Wenn autoritative Server unterschiedliche Zonenversionen liefern, können Clients abhängig vom befragten Server unterschiedliche Ergebnisse erhalten.
30. Wie wird die SOA-Seriennummer verwendet? Der SOA-Record enthält Verwaltungsinformationen einer DNS-Zone, darunter eine Seriennummer. ```bash [TEST] dig @DNS-SERVER example.intern SOA ``` Mehrere autoritative Server vergleichen: ```bash [TEST] dig @DNS-SERVER-1 example.intern SOA ``` ```bash [TEST] dig @DNS-SERVER-2 example.intern SOA ``` **Mögliche Auffälligkeit** ```text Server 1: Serial 2026073105 Server 2: Serial 2026073002 ``` Dies kann auf eine noch nicht erfolgte oder fehlgeschlagene Zonenübertragung beziehungsweise Replikation hinweisen. Die Bedeutung und das Format der Seriennummer werden durch die DNS-Verwaltung der jeweiligen Umgebung bestimmt. Eine höhere dezimale Darstellung ist häufig, aber nicht jede Organisation verwendet dasselbe Schema.
31. Wie werden Delegationsfehler erkannt? Eine übergeordnete Zone verweist per NS-Records auf die autoritativen Server einer untergeordneten Zone. ```text example.com → Delegation für berlin.example.com → ns1.berlin.example.com → ns2.berlin.example.com ``` Mögliche Fehler: - falscher Nameserver eingetragen, - Nameserver ist nicht erreichbar, - Glue Record fehlt oder ist falsch, - Child- und Parent-NS-Records unterscheiden sich, - Firewall blockiert UDP oder TCP 53, - DNSSEC-DS-Record passt nicht mehr, - autoritativer Server kennt die delegierte Zone nicht, - Schleife in der Delegation. **Öffentliche Delegation verfolgen** ```bash [TEST] dig +trace berlin.example.com ``` Für interne Zonen muss der interne Delegations- und Weiterleitungsweg anhand der Unternehmensarchitektur geprüft werden.
32. Wie werden DNSSEC-Probleme erkannt? DNSSEC ermöglicht die kryptografische Prüfung von DNS-Daten. Ein Fehler in der Vertrauenskette kann dazu führen, dass validierende Resolver mit `SERVFAIL` antworten. **Abfrage mit DNSSEC-Daten** ```bash [TEST] dig +dnssec @192.0.2.53 example.com A ``` **Validierung testweise durch den Resolver anfragen, aber Checking Disabled setzen** ```bash [TEST] dig +cdflag @192.0.2.53 example.com A ``` Wenn eine normale Abfrage `SERVFAIL` liefert, dieselbe Abfrage mit `+cdflag` aber Daten zurückgibt, ist ein DNSSEC-Validierungsproblem eine mögliche Hypothese. **Mögliche Ursachen** - abgelaufene Signatur, - falscher DS-Record, - Schlüsselwechsel nicht korrekt abgeschlossen, - inkonsistente autoritative Server, - falsche Systemzeit, - beschädigte Vertrauenskette, - Antwort wird auf dem Weg verändert oder abgeschnitten. `+cdflag` deaktiviert nicht dauerhaft die Serverkonfiguration. Es kennzeichnet die einzelne Abfrage entsprechend. Das Ergebnis darf nur als Diagnosehinweis verwendet werden.
33. Wie beeinflusst DNS over HTTPS die Fehleranalyse? Bei DNS over HTTPS werden DNS-Abfragen in HTTPS-Verbindungen übertragen. Dadurch kann eine Anwendung den betriebssystemseitig konfigurierten DNS-Server umgehen. Mögliche Auswirkungen: - interne Zonen werden nicht gefunden, - Unternehmensfilter greifen nicht, - Browser liefert andere Antworten als `nslookup`, - DNS-Verkehr ist im gewöhnlichen Port-53-Mitschnitt nicht sichtbar, - Split DNS funktioniert in der Anwendung nicht, - zentrale DNS-Protokolle enthalten die Anfrage nicht. **Prüffragen** - verwendet die Anwendung den Systemresolver? - ist DoH durch Browser, Betriebssystem oder Richtlinie aktiviert? - welcher DoH-Endpunkt wird verwendet? - sollen interne Namen vom Systemresolver aufgelöst werden? - existieren betriebliche Vorgaben für verschlüsseltes DNS? DoH sollte nicht pauschal deaktiviert werden. Zuerst müssen Unternehmensrichtlinie, Sicherheitskonzept und tatsächlicher Auflösungsweg geprüft werden.
34. Wie wird DNS-Verkehr mit Wireshark untersucht? **Alle klassischen DNS-Nachrichten** ```text dns ``` **Nur DNS-Anfragen** ```text dns.flags.response == 0 ``` **Nur DNS-Antworten** ```text dns.flags.response == 1 ``` **Bestimmter Name** ```text dns.qry.name == "app.example.intern" ``` **Bestimmter Recordtyp** A-Record: ```text dns.qry.type == 1 ``` AAAA-Record: ```text dns.qry.type == 28 ``` **NXDOMAIN** ```text dns.flags.rcode == 3 ``` **SERVFAIL** ```text dns.flags.rcode == 2 ``` **Gekürzte Antworten** ```text dns.flags.truncated == 1 ``` **Lange Antwortzeit** ```text dns.time > 1 ``` `dns.time` ist verfügbar, wenn Wireshark Anfrage und passende Antwort einander zuordnen konnte.
35. Wie wird DNS-Verkehr sicher mitgeschnitten? **Capture-Filter für klassischen DNS-Verkehr** ```text port 53 ``` **Nur bestimmter DNS-Server** ```text host 192.0.2.53 and port 53 ``` **Zeitlich begrenzte Aufnahme** ```bash [TEST][PRIV][FILE][SENS] dumpcap \ -i INTERFACE \ -f "host 192.0.2.53 and port 53" \ -a duration:30 \ -w dns-diagnose.pcapng ``` **TShark-Liveanzeige** ```bash [TEST][PRIV][SENS] tshark \ -i INTERFACE \ -f "host 192.0.2.53 and port 53" ``` **Felder aus einer Datei ausgeben** ```bash [RO][SENS] tshark \ -r dns-diagnose.pcapng \ -Y "dns" \ -T fields \ -e frame.time \ -e ip.src \ -e ip.dst \ -e udp.srcport \ -e udp.dstport \ -e dns.id \ -e dns.flags.response \ -e dns.flags.rcode \ -e dns.qry.name \ -e dns.qry.type ``` DNS-Aufzeichnungen können aufgerufene interne und externe Namen offenlegen und müssen gemäß Seite 2.14 geschützt werden.
36. Wie wird eine DNS-Anfrage im Paketmitschnitt ausgewertet? **Erfolgreicher Ablauf** ```text Client → Resolver: Query A app.example.intern Resolver → Client: Response NOERROR A 192.0.2.20 ``` **Timeout** ```text Client → Resolver: Query A app.example.intern Client → Resolver: Wiederholung Keine Antwort ``` **NXDOMAIN** ```text Client → Resolver: Query A app.example.intern Resolver → Client: Response NXDOMAIN ``` **TCP-Fallback** ```text Client → Resolver über UDP: Query Resolver → Client: Response, Truncated Client → Resolver über TCP: SYN, SYN-ACK, ACK DNS Query Resolver → Client über TCP: vollständige DNS Response ``` **Zu prüfen** - Transaktions-ID, - Quell- und Zieladresse, - UDP oder TCP, - abgefragter Name, - Recordtyp, - Antwortstatus, - Antwortrecords, - TTL, - Wiederholungen, - Antwortdauer, - Truncation, - DNSSEC-Flags.
37. Wie wird zwischen Client-, Resolver- und Zonenproblem unterschieden? | Beobachtung | Wahrscheinlichere Richtung | |---|---| | nur eine Anwendung betroffen | Anwendungscache, DoH oder Proxy | | nur ein Client betroffen | Clientcache, Hosts-Datei oder DNS-Konfiguration | | alle Clients eines DNS-Servers betroffen | Resolver, Forwarder oder dessen Netzwerkpfad | | direkter autoritativer Server korrekt, Resolver falsch | Cache oder Weiterleitung | | alle autoritativen Server falsch | Zonendaten | | ein autoritativer Server weicht ab | Replikation oder Zonentransfer | | UDP funktioniert, TCP nicht | Firewall oder TCP-Listener | | TCP funktioniert, UDP nicht | UDP-Filter, Fragmentierung oder Middlebox | | interne Namen nur ohne DoH | Anwendung umgeht internen Resolver | | Auflösung korrekt, Verbindung fehlerhaft | Problem liegt nach DNS | | A funktioniert, AAAA führt zum Fehler | IPv6-Pfad oder Ziel prüfen | | `SERVFAIL` nur bei validierendem Resolver | DNSSEC möglich | | Name mit Punkt funktioniert, Kurzname nicht | Suchsuffix oder Suchreihenfolge |
38. Welche typischen Fehlinterpretationen müssen vermieden werden? | Beobachtung | Falscher Schluss | Richtige Einordnung | |---|---|---| | Ping per IP funktioniert | DNS ist sicher die einzige Ursache | Dienst kann Hostnamen oder TLS benötigen | | nslookup funktioniert | Anwendung verwendet dieselbe Auflösung | Anwendung kann eigenen Resolver verwenden | | DNS-Server ist eingetragen | er wird tatsächlich verwendet | schnittstellen- und anwendungsbezogene Resolver prüfen | | `NXDOMAIN` | DNS-Server ist ausgefallen | Server antwortet, Name existiert laut Antwort nicht | | `SERVFAIL` | Name existiert nicht | Server konnte keine gültige Antwort liefern | | `NOERROR` | gesuchter Record ist vorhanden | Antwort kann leer sein | | DNS-Cache geleert und Zugriff geht | Ursache ist behoben | veraltete Quelle kann erneut cachen | | A-Record ist korrekt | Dienst ist vollständig korrekt | AAAA, CNAME, TLS und Backend prüfen | | öffentliche Antwort unterscheidet sich | eine Seite ist falsch | Split DNS kann beabsichtigt sein | | Port 53 per TCP erreichbar | DNS funktioniert | UDP und tatsächliche Abfrage separat prüfen | | keine Port-53-Pakete sichtbar | Anwendung stellt keine DNS-Anfrage | DoH, Cache oder falscher Messpunkt möglich | | kurze Query Time | gesamte Anwendung ist schnell | nur DNS-Abfragedauer gemessen |
39. Wie sieht der systematische Prüfablauf aus? | Schritt | Prüfung | |---:|---| | 1 | betroffenen Namen und Recordtyp eindeutig bestimmen | | 2 | Clientzeit, Netzwerk und VPN-Zustand dokumentieren | | 3 | konfigurierte und tatsächlich verwendete Resolver bestimmen | | 4 | Hosts-Datei und Suchsuffixe prüfen | | 5 | Systemresolver abfragen | | 6 | konfigurierten DNS-Server direkt abfragen | | 7 | A, AAAA und mögliche CNAME-Kette untersuchen | | 8 | Antwortstatus, TTL, Flags und Server dokumentieren | | 9 | funktionierenden Client oder Resolver vergleichen | | 10 | UDP- und TCP-Abfrage vergleichen | | 11 | autoritative Server direkt prüfen | | 12 | SOA-Seriennummern und Zonendaten vergleichen | | 13 | Split DNS, VPN, DoH und Conditional Forwarding berücksichtigen | | 14 | bei Bedarf autorisierten Paketmitschnitt erstellen | | 15 | Cache erst nach Beweissicherung kontrolliert leeren | | 16 | DNS-Antwort und tatsächliche Dienstverbindung erneut testen | | 17 | Ursache und Änderung dokumentieren | **Merksatz** ```text Name → Recordtyp → Systemresolver → konfigurierter Resolver → autoritativer Server → Cache → tatsächliche Anwendung ```
40. Kompakte Befehlsübersicht für Windows, Linux und macOS | Aufgabe | Windows | Linux | macOS | |---|---|---|---| | DNS-Konfiguration | `[RO] Get-DnsClientServerAddress` | `[RO] resolvectl status` | `[RO][SENS] scutil --dns` | | DNS-Suffixe | `[RO] Get-DnsClient` | `[RO] resolvectl status` | `[RO] networksetup -getsearchdomains "DIENST"` | | vollständige Netzkonfiguration | `[RO][SENS] ipconfig /all` | `[RO] cat /etc/resolv.conf` | `[RO] networksetup -getinfo "DIENST"` | | Systemauflösung | `[TEST] Resolve-DnsName NAME` | `[TEST] resolvectl query NAME` | `[TEST] dscacheutil -q host -a name NAME` | | A-Record | `[TEST] Resolve-DnsName NAME -Type A` | `[TEST] dig NAME A` | `[TEST] dig NAME A` | | AAAA-Record | `[TEST] Resolve-DnsName NAME -Type AAAA` | `[TEST] dig NAME AAAA` | `[TEST] dig NAME AAAA` | | bestimmten Resolver abfragen | `[TEST] Resolve-DnsName NAME -Server DNS-SERVER` | `[TEST] dig @DNS-SERVER NAME` | `[TEST] dig @DNS-SERVER NAME` | | TCP erzwingen | `[TEST] Resolve-DnsName NAME -Server DNS-SERVER -TcpOnly` | `[TEST] dig +tcp @DNS-SERVER NAME` | `[TEST] dig +tcp @DNS-SERVER NAME` | | Reverse DNS | `[TEST] Resolve-DnsName IP -Type PTR` | `[TEST] dig -x IP @DNS-SERVER` | `[TEST] dig -x IP @DNS-SERVER` | | NS-Records | `[TEST] Resolve-DnsName ZONE -Type NS` | `[TEST] dig @DNS-SERVER ZONE NS` | gleicher Befehl | | SOA-Record | `[TEST] Resolve-DnsName ZONE -Type SOA` | `[TEST] dig @DNS-SERVER ZONE SOA` | gleicher Befehl | | Hosts-Datei | `[RO][PRIV][SENS] Get-Content "$env:SystemRoot\System32\drivers\etc\hosts"` | `[RO][SENS] cat /etc/hosts` | `[RO][SENS] cat /etc/hosts` | | DNS-Cache anzeigen | `[RO] Get-DnsClientCache` | `[RO] resolvectl statistics` | kein gleichwertiger vollständiger Standardbefehl | | DNS-Cache leeren | `[PRIV][CHANGE] Clear-DnsClientCache` | `[PRIV][CHANGE] sudo resolvectl flush-caches` | `[PRIV][CHANGE] sudo dscacheutil -flushcache` | | DNS mitschneiden | `[TEST][PRIV][FILE][SENS] dumpcap -i INTERFACE -f "host DNS-SERVER and port 53" -a duration:30 -w dns.pcapng` | gleicher Befehl | gleicher Befehl | Die Platzhalter `NAME`, `ZONE`, `IP`, `DNS-SERVER`, `DIENST` und `INTERFACE` müssen durch vorher eindeutig bestimmte Werte ersetzt werden.
41. Dokumentationsvorlage ```text Ticketnummer: Prüfzeitpunkt: Zeitzone: Betroffener Client: Betriebssystem: Benutzer: Standort: VLAN: VPN aktiv: Betroffene Anwendung: ABFRAGE Eingegebener Name: Vollständig qualifizierter Name: Recordtyp: Erwartete Antwort: Tatsächliche Antwort: Exakte Fehlermeldung: CLIENTKONFIGURATION Schnittstelle: IPv4-Adresse: IPv6-Adresse: DNS-Server IPv4: DNS-Server IPv6: DNS-Suchdomänen: Lokale Hosts-Datei geprüft: Passender Hosts-Eintrag: DoH aktiv oder vermutet: Proxy aktiv: Anwendungscache: SYSTEMRESOLVER Verwendeter Test: Antwortstatus: Antwortrecords: TTL: CNAME-Kette: Antwortzeit: Verwendeter Resolver: IPv4 oder IPv6: DIREKTE DNS-ABFRAGE DNS-Server: UDP erfolgreich: TCP erfolgreich: A-Antwort: AAAA-Antwort: CNAME: Status: Flags: TTL: Query Time: AUTORITATIVE DATEN Zone: Autoritative Nameserver: Direkt abgefragter Server: AA-Flag: A-Record: AAAA-Record: CNAME: SOA-Seriennummer: Weitere autoritative Server: Seriennummern identisch: Delegation korrekt: DNSSEC-Status: VERGLEICH Referenzclient: Verwendeter Resolver: Antwort: TTL: Anwendung funktioniert: Relevante Abweichungen: PAKETMITSCHNITT Messpunkt: DNS-Anfrage sichtbar: DNS-Antwort sichtbar: Transaktions-ID: UDP oder TCP: Response Code: Truncated: Wiederholungen: Antwortzeit: Capture-Datei: Hash: CACHE Clientcache vor Änderung gesichert: Resolvercache vermutet: Negative Antwort: Cache geleert: Ergebnis nach Cacheleerung: Arbeitshypothese: Begründung: Durchgeführter Test: Geplante Änderung: Freigabe: Rückweg: Abschlussprüfung: Ermittelte Ursache: ```
42. Offizielle Quellen und weiterführende Dokumentation **Microsoft** - [DNS – technische Übersicht](https://learn.microsoft.com/windows-server/networking/dns/dns-top) - [Resolve-DnsName](https://learn.microsoft.com/powershell/module/dnsclient/resolve-dnsname) - [Get-DnsClientServerAddress](https://learn.microsoft.com/powershell/module/dnsclient/get-dnsclientserveraddress) - [Get-DnsClient](https://learn.microsoft.com/powershell/module/dnsclient/get-dnsclient) - [Get-DnsClientCache](https://learn.microsoft.com/powershell/module/dnsclient/get-dnsclientcache) - [Clear-DnsClientCache](https://learn.microsoft.com/powershell/module/dnsclient/clear-dnsclientcache) - [nslookup](https://learn.microsoft.com/windows-server/administration/windows-commands/nslookup) **Linux und systemd** - [resolvectl](https://www.freedesktop.org/software/systemd/man/latest/resolvectl.html) - [systemd-resolved](https://www.freedesktop.org/software/systemd/man/latest/systemd-resolved.service.html) - [resolv.conf – Linux Manual Page](https://man7.org/linux/man-pages/man5/resolv.conf.5.html) **ISC BIND** - [BIND 9 Administrator Reference Manual](https://bind9.readthedocs.io/) - [dig Manual](https://bind9.readthedocs.io/en/latest/manpages.html#dig-dns-lookup-utility) **Apple** - Lokale Befehlsreferenzen: `man scutil`, `man networksetup`, `man dscacheutil`, `man dig` und `man nslookup` - [DNS-Einstellungen auf dem Mac ändern](https://support.apple.com/guide/mac-help/change-dns-settings-on-mac-mh14127/mac) **Wireshark** - [DNS Display Filter Reference](https://www.wireshark.org/docs/dfref/d/dns.html) - [dumpcap Manual Page](https://www.wireshark.org/docs/man-pages/dumpcap.html) - [tshark Manual Page](https://www.wireshark.org/docs/man-pages/tshark.html) **Standards** - [RFC 1034 – Domain Names: Concepts and Facilities](https://www.rfc-editor.org/rfc/rfc1034) - [RFC 1035 – Domain Names: Implementation and Specification](https://www.rfc-editor.org/rfc/rfc1035) - [RFC 2308 – Negative Caching of DNS Queries](https://www.rfc-editor.org/rfc/rfc2308) - [RFC 6891 – Extension Mechanisms for DNS](https://www.rfc-editor.org/rfc/rfc6891) - [RFC 7766 – DNS Transport over TCP](https://www.rfc-editor.org/rfc/rfc7766) - [RFC 7858 – DNS over TLS](https://www.rfc-editor.org/rfc/rfc7858) - [RFC 8484 – DNS over HTTPS](https://www.rfc-editor.org/rfc/rfc8484) > DNS-Verwaltungsbefehle und Serverprotokolle unterscheiden sich je nach Produkt. Änderungen an Zonen, Delegationen, Forwardern, DNSSEC oder Resolverrichtlinien dürfen nur anhand der Dokumentation des tatsächlich eingesetzten DNS-Systems vorgenommen werden.
# 3.9 Ports und Transportprotokolle prüfen Ein erreichbarer Host bedeutet noch nicht, dass der benötigte Dienst erreichbar ist. `ping` prüft hauptsächlich die IP-Erreichbarkeit über ICMP. Es prüft weder einen TCP-Port noch zuverlässig die Funktionsfähigkeit eines Anwendungsdienstes. Die zentrale Frage dieser Seite lautet: > Ist der benötigte Dienst über das richtige Transportprotokoll, die richtige Zieladresse und den richtigen Port erreichbar? ---
1. Sicherheits- und Aktionskennzeichnungen | Kennzeichnung | Bedeutung | |---|---| | `[RO]` | Rein lesender Befehl, der normalerweise keine Konfiguration verändert | | `[TEST]` | Aktiver Test, der Netzwerkverkehr oder Protokollanfragen erzeugt | | `[PRIV]` | Erhöhte Rechte beziehungsweise Administrator- oder Root-Rechte können erforderlich sein | | `[FILE]` | Der Befehl schreibt Ausgaben in eine Datei | | `[SENS]` | Die Ausgabe kann sensible Daten enthalten | | `[CHANGE]` | Der Befehl verändert eine Konfiguration | | `[DISRUPT]` | Der Befehl kann einen Dienst oder eine Verbindung beeinträchtigen | **Wichtiger Grundsatz:** Portscans und aktive Verbindungstests dürfen nur auf Systemen durchgeführt werden, für die eine entsprechende Berechtigung vorliegt.
---
2. TCP, UDP und ICMP unterscheiden | Protokoll | Eigenschaft | Typisches Verhalten bei einem Test | |---|---|---| | TCP | Verbindungsorientiert | Vor der Datenübertragung wird eine Verbindung aufgebaut | | UDP | Verbindungslos | Datagramme werden ohne vorherigen Verbindungsaufbau gesendet | | ICMP | Kontroll- und Diagnoseprotokoll | Übermittelt beispielsweise Echo-Antworten oder Fehlermeldungen | | ICMPv6 | Kontrollprotokoll für IPv6 | Wird unter anderem für Fehler, Neighbor Discovery und Path-MTU-Ermittlung benötigt | **TCP-Verbindungsaufbau:** ```text Client Server | | | -------- SYN --------------> | | <----- SYN, ACK ------------ | | -------- ACK --------------> | | | | Verbindung aufgebaut | ``` Der erfolgreiche TCP-Handshake beweist: - Der Client konnte ein TCP-Segment zum Ziel senden. - Das Ziel oder ein vorgeschaltetes System hat geantwortet. - Der Rückweg zum Client funktioniert. - Der betreffende TCP-Port akzeptiert grundsätzlich Verbindungen. Er beweist jedoch noch nicht: - dass die Anwendung fehlerfrei arbeitet, - dass eine Anmeldung möglich ist, - dass TLS-Zertifikate gültig sind, - dass der Benutzer die benötigten Berechtigungen besitzt, - dass die richtige Anwendung hinter dem Port antwortet. **Besonderheit bei UDP:** UDP besitzt keinen vergleichbaren Verbindungsaufbau. Bleibt eine Antwort aus, kann das bedeuten: - Der Dienst ist nicht erreichbar. - Der Port wird durch eine Firewall gefiltert. - Der Dienst antwortet nur auf gültige Protokollanfragen. - Die Antwort geht auf dem Rückweg verloren. - Der UDP-Dienst antwortet grundsätzlich nicht auf die gesendeten Daten. - Das Prüfwerkzeug kann den Zustand nicht eindeutig bestimmen. Ein erfolgreicher UDP-Test benötigt deshalb möglichst eine **gültige Anfrage des jeweiligen Anwendungsprotokolls**, beispielsweise eine DNS-Abfrage anstelle eines beliebigen UDP-Pakets.
---
3. Port, Socket und Verbindung eindeutig beschreiben Ein Port gehört immer zu einem Transportprotokoll. Die Angabe „Port 53“ ist ohne das Protokoll unvollständig, weil TCP-Port 53 und UDP-Port 53 getrennte Endpunkte sind. Eine Netzwerkverbindung wird im Normalfall durch folgende Angaben unterschieden: ```text Transportprotokoll Quell-IP-Adresse Quellport Ziel-IP-Adresse Zielport ``` Beispiel: ```text TCP 192.0.2.25:53144 → 192.0.2.53:443 ``` Dabei ist `53144` normalerweise ein temporärer Clientport und `443` der angesprochene Dienstport. **Wichtige Begriffe:** | Begriff | Bedeutung | |---|---| | Dienstport | Port, auf dem eine Serveranwendung Verbindungen oder Datagramme erwartet | | Quellport | Vom Client verwendeter Port; häufig dynamisch vergeben | | Listening Socket | Lokaler Socket, der auf eingehende TCP-Verbindungen wartet | | UDP Endpoint | Lokaler UDP-Endpunkt, der Datagramme empfangen kann | | Ephemeral Port | Temporärer, vom Betriebssystem vergebener Clientport | | Loopback-Adresse | Nur lokal erreichbare Adresse, beispielsweise `127.0.0.1` oder `::1` | | Wildcard-Adresse | Bindung an mehrere beziehungsweise alle lokalen Adressen | | Verbindungsstatus | Zustand einer TCP-Verbindung, beispielsweise `LISTEN` oder `ESTABLISHED` |
---
4. Häufig verwendete Ports einordnen Die folgende Tabelle enthält typische Standardbelegungen. Anwendungen können jedoch auf abweichende Ports konfiguriert werden. | Dienst | Transportprotokoll | Standardport | |---|---|---:| | SSH | TCP | 22 | | SMTP | TCP | 25 | | DNS | UDP und TCP | 53 | | DHCP-Server | UDP | 67 | | DHCP-Client | UDP | 68 | | HTTP | TCP | 80 | | Kerberos | UDP und TCP | 88 | | NTP | UDP | 123 | | LDAP | TCP und teilweise UDP | 389 | | HTTPS | TCP | 443 | | SMB | TCP | 445 | | LDAPS | TCP | 636 | | Microsoft SQL Server | TCP | 1433 | | MySQL/MariaDB | TCP | 3306 | | RDP | TCP und UDP | 3389 | | PostgreSQL | TCP | 5432 | **Nicht allein auf die Portnummer verlassen:** Ein offener TCP-Port 443 beweist nicht, dass dort tatsächlich ein ordnungsgemäßer HTTPS-Dienst läuft.
---
5. Typische Fehlermeldungen richtig interpretieren | Beobachtung | Wahrscheinliche Bedeutung | |---|---| | Verbindung erfolgreich | TCP-Verbindungsaufbau war möglich | | `Connection refused` | Ziel wurde erreicht, aber der Port wird nicht angenommen oder aktiv abgelehnt | | `Connection timed out` | Keine verwertbare Antwort; Paketverlust, Filterung, Routing- oder Rückwegproblem möglich | | `No route to host` | Lokales oder entferntes Routingproblem beziehungsweise entsprechende ICMP-Rückmeldung | | `Network is unreachable` | Keine geeignete Route oder Schnittstelle vorhanden | | `Host is unreachable` | Ziel oder nächster Hop konnte nicht erreicht werden | | `Name or service not known` | Namensauflösung fehlgeschlagen; der Porttest wurde möglicherweise noch nicht ausgeführt | | `Address already in use` | Ein anderer Prozess oder Socket verwendet bereits die Adresse beziehungsweise den Port | | `Permission denied` | Fehlende Berechtigung oder Sicherheitsrichtlinie verhindert den Zugriff | | Verbindung sofort zurückgesetzt | Anwendung, Zielsystem oder Sicherheitskomponente sendet ein TCP-RST | | TCP-Test erfolgreich, Anwendung fehlerhaft | Fehler liegt wahrscheinlich oberhalb der Transportschicht | Fehlermeldungen können je nach Betriebssystem, Anwendung und Sprache abweichen.
---
6. Auf dem Server prüfen, ob der Port geöffnet wurde Zuerst wird direkt auf dem betroffenen Server geprüft: 1. Läuft der erwartete Prozess? 2. Lauscht er auf dem erwarteten Port? 3. Verwendet er TCP oder UDP? 4. An welche IP-Adresse wurde der Socket gebunden? 5. Ist der Dienst nur über IPv4, nur über IPv6 oder über beides erreichbar? 6. Stimmt der Prozess tatsächlich mit dem erwarteten Dienst überein? | Aufgabe | Windows | Linux | macOS | |---|---|---|---| | TCP-Verbindungen und Listener | `[RO] Get-NetTCPConnection` | `[RO] ss -tan` | `[RO] netstat -anv -p tcp` | | Nur TCP-Listener | `[RO] Get-NetTCPConnection -State Listen` | `[RO] ss -ltn` | `[RO] lsof -nP -iTCP -sTCP:LISTEN` | | UDP-Endpunkte | `[RO] Get-NetUDPEndpoint` | `[RO] ss -lun` | `[RO] lsof -nP -iUDP` | | TCP-Listener mit Prozess | `[RO] Get-NetTCPConnection -State Listen` | `[RO][PRIV] sudo ss -ltnp` | `[RO][PRIV] sudo lsof -nP -iTCP -sTCP:LISTEN` | | UDP-Endpunkte mit Prozess | `[RO] Get-NetUDPEndpoint` | `[RO][PRIV] sudo ss -lunp` | `[RO][PRIV] sudo lsof -nP -iUDP` | | Klassische Übersicht | `[RO] netstat -ano` | `[RO] ss -tuln` | `[RO] netstat -anv` | `lsof` ist auf einigen Linux-Systemen nicht standardmäßig installiert. Unter Linux ist `ss` normalerweise das bevorzugte Werkzeug. **Windows – bestimmten TCP-Port prüfen:** ```powershell [RO] Get-NetTCPConnection -LocalPort 443 -ErrorAction SilentlyContinue ``` **Windows – nur Listener auf einem bestimmten Port:** ```powershell [RO] Get-NetTCPConnection -State Listen -LocalPort 443 -ErrorAction SilentlyContinue ``` **Windows – UDP-Endpunkt prüfen:** ```powershell [RO] Get-NetUDPEndpoint -LocalPort 53 -ErrorAction SilentlyContinue ``` **Windows – Prozess zu einem Listener ermitteln:** ```powershell [RO] Get-NetTCPConnection -State Listen -LocalPort 443 | Select-Object LocalAddress, LocalPort, State, OwningProcess ``` Anschließend die ermittelte Prozess-ID einsetzen: ```powershell [RO] Get-Process -Id 4321 ``` Alternativ mit klassischen Werkzeugen: ```cmd [RO] netstat -ano [RO] tasklist /FI "PID eq 4321" ``` **Linux – TCP-Port 443 prüfen:** ```bash [RO] ss -ltn 'sport = :443' ``` **Linux – UDP-Port 53 prüfen:** ```bash [RO] ss -lun 'sport = :53' ``` **Linux – Prozessinformationen anzeigen:** ```bash [RO][PRIV] sudo ss -ltnp 'sport = :443' ``` ```bash [RO][PRIV] sudo ss -lunp 'sport = :53' ``` **macOS – TCP-Port 443 prüfen:** ```bash [RO] lsof -nP -iTCP:443 -sTCP:LISTEN ``` **macOS – UDP-Port 53 prüfen:** ```bash [RO][PRIV] sudo lsof -nP -iUDP:53 ``` **Achtung:** Eine leere Ausgabe bedeutet meistens, dass kein passender Socket gefunden wurde. Sie ist nicht automatisch ein Programmfehler.
---
7. Bind-Adressen eines Dienstes beurteilen Ein Prozess kann laufen und trotzdem nur über eine falsche oder zu stark eingeschränkte Adresse erreichbar sein. | Lokale Adresse | Typische Bedeutung | |---|---| | `127.0.0.1:8080` | Nur über IPv4-Loopback auf demselben System erreichbar | | `::1:8080` | Nur über IPv6-Loopback auf demselben System erreichbar | | `192.0.2.10:443` | Nur über diese konkrete lokale IPv4-Adresse erreichbar | | `0.0.0.0:443` | An alle passenden lokalen IPv4-Adressen gebunden | | `[::]:443` | IPv6-Wildcard; ob zusätzlich IPv4 angenommen wird, hängt von Betriebssystem und Anwendung ab | **Typischer Fehler:** ```text Dienst läuft ↓ Port ist lokal geöffnet ↓ Dienst lauscht aber nur auf 127.0.0.1 ↓ Lokaler Test funktioniert ↓ Entfernter Zugriff schlägt fehl ``` Eine Bindung an `0.0.0.0` oder `[::]` bedeutet nicht automatisch, dass der Port von außen erreichbar ist. Firewalls, VLANs, Routing, NAT und Sicherheitsrichtlinien gelten weiterhin.
---
8. TCP-Port von einem Client aus prüfen Der Test sollte möglichst von dem System oder Netzwerksegment ausgeführt werden, in dem der Fehler tatsächlich auftritt. | Betriebssystem | TCP-Porttest | |---|---| | Windows | `[TEST] Test-NetConnection server.example.internal -Port 443 -InformationLevel Detailed` | | Linux | `[TEST] nc -vz -w 5 server.example.internal 443` | | macOS | `[TEST] nc -vz -w 5 server.example.internal 443` | | Plattformübergreifend mit Nmap | `[TEST] nmap -sT -p 443 server.example.internal` | **Windows:** ```powershell [TEST] Test-NetConnection server.example.internal -Port 443 -InformationLevel Detailed ``` Besonders relevante Felder: ```text ComputerName RemoteAddress RemotePort InterfaceAlias SourceAddress TcpTestSucceeded ``` Nur das Wesentliche ausgeben: ```powershell [TEST] Test-NetConnection server.example.internal -Port 443 | Select-Object ComputerName, RemoteAddress, RemotePort, SourceAddress, TcpTestSucceeded ``` **Wichtig:** `Test-NetConnection -Port` prüft einen **TCP-Port**. Es ist kein allgemeiner UDP-Porttest. **Linux und macOS:** ```bash [TEST] nc -vz -w 5 server.example.internal 443 ``` Mehrere TCP-Ports einzeln prüfen: ```bash [TEST] nc -vz -w 5 server.example.internal 22 [TEST] nc -vz -w 5 server.example.internal 80 [TEST] nc -vz -w 5 server.example.internal 443 ``` Die verfügbaren `nc`-Optionen unterscheiden sich zwischen Implementierungen. Im Zweifel die lokale Hilfe prüfen: ```bash [RO] nc -h ``` **Nmap – einzelnen TCP-Port prüfen:** ```bash [TEST] nmap -sT -p 443 server.example.internal ``` **Mehrere festgelegte TCP-Ports prüfen:** ```bash [TEST] nmap -sT -p 22,80,443 server.example.internal ``` Nmap nur im freigegebenen Umfang einsetzen. Ein vollständiger Portscan ist für die Prüfung eines bekannten Dienstes normalerweise nicht erforderlich.
---
9. Nmap-Portzustände richtig interpretieren | Zustand | Typische Bedeutung | |---|---| | `open` | Eine Anwendung nimmt Verbindungen oder Datagramme auf diesem Port an | | `closed` | Ziel ist erreichbar, aber auf dem Port lauscht kein Dienst | | `filtered` | Nmap kann wegen Paketfilterung nicht sicher feststellen, ob der Port geöffnet ist | | `unfiltered` | Port ist erreichbar, aber der konkrete Offen-/Geschlossen-Zustand wurde mit der verwendeten Scanmethode nicht bestimmt | | `open\|filtered` | Nmap kann nicht zwischen geöffnet und gefiltert unterscheiden | | `closed\|filtered` | Nmap kann nicht zwischen geschlossen und gefiltert unterscheiden | Die Bewertung hängt von Scanart, Berechtigungen, Zielsystem und den empfangenen Antworten ab.
---
10. UDP-Dienste sinnvoll prüfen Ein allgemeiner UDP-Porttest ist nur eingeschränkt aussagekräftig. Nach Möglichkeit sollte immer das eigentliche Anwendungsprotokoll geprüft werden. | Dienst | Sinnvoller Funktionstest | |---|---| | DNS | `nslookup`, `Resolve-DnsName` oder `dig` | | NTP | `w32tm`, `chronyc`, `ntpq` oder `sntp`, abhängig vom System | | DHCP | DHCP-Ablauf und Paketmitschnitt analysieren | | Syslog über UDP | Empfang auf dem Syslog-Server und Paketmitschnitt prüfen | | SNMP | Autorisierte SNMP-Abfrage mit gültigen Parametern durchführen | **DNS gezielt über UDP testen:** Windows: ```powershell [TEST] Resolve-DnsName example.org -Server 192.0.2.53 -Type A -DnsOnly ``` Linux und macOS, sofern `dig` installiert ist: ```bash [TEST] dig @192.0.2.53 example.org A ``` **DNS gezielt über TCP testen:** Windows: ```powershell [TEST] Resolve-DnsName example.org -Server 192.0.2.53 -Type A -DnsOnly -TcpOnly ``` Linux und macOS: ```bash [TEST] dig +tcp @192.0.2.53 example.org A ``` **Netcat-UDP-Test:** ```bash [TEST] nc -vzu -w 3 192.0.2.53 53 ``` Dieser Test ist nicht mit einem erfolgreichen DNS-Funktionstest gleichzusetzen. Eine scheinbare Erfolgsmeldung kann lediglich bedeuten, dass lokal kein unmittelbarer Fehler festgestellt wurde. **Nmap-UDP-Test:** ```bash [TEST][PRIV] sudo nmap -sU -p 53 192.0.2.53 ``` UDP-Scans können langsam und mehrdeutig sein. Ein Ergebnis wie `open|filtered` ist bei UDP häufig, wenn weder eine Protokollantwort noch eine eindeutige ICMP-Fehlermeldung empfangen wurde.
---
11. Nicht nur den Port, sondern die Anwendung testen Ein Porttest prüft die Transportschicht. Danach sollte ein Test mit dem tatsächlichen Anwendungsprotokoll folgen. | Anwendung | Beispiel | |---|---| | HTTP | `[TEST] curl -v http://server.example.internal/` | | HTTPS | `[TEST] curl -vk https://server.example.internal/` | | HTTPS mit regulärer Zertifikatsprüfung | `[TEST] curl -v https://server.example.internal/` | | TLS-Handshake | `[TEST] openssl s_client -connect server.example.internal:443 -servername server.example.internal` | | DNS über UDP | `[TEST] dig @192.0.2.53 example.org A` | | DNS über TCP | `[TEST] dig +tcp @192.0.2.53 example.org A` | | SSH-Protokolltest | `[TEST] ssh -vvv user@server.example.internal` | **HTTP-Header abrufen:** ```bash [TEST] curl -I https://server.example.internal/ ``` **Ausführliche HTTPS-Diagnose:** ```bash [TEST][SENS] curl -v https://server.example.internal/ ``` Bei `curl -v` können Header, Cookies, interne Hostnamen und weitere sensible Informationen sichtbar werden. Zugangsdaten oder Sitzungstoken dürfen nicht ungeprüft dokumentiert werden. **TLS-Verbindung untersuchen:** ```bash [TEST][SENS] openssl s_client \ -connect server.example.internal:443 \ -servername server.example.internal ``` `-servername` übermittelt den Servernamen per SNI. Das ist wichtig, wenn mehrere TLS-Websites dieselbe IP-Adresse verwenden. **Hinweis zu `curl -k`:** ```bash [TEST] curl -vk https://server.example.internal/ ``` `-k` deaktiviert die Zertifikatsprüfung. Das kann zur Eingrenzung eines Zertifikatsfehlers verwendet werden, darf aber nicht als dauerhafte Lösung betrachtet werden.
---
12. IPv4 und IPv6 getrennt prüfen Ein Hostname kann gleichzeitig eine IPv4- und eine IPv6-Adresse besitzen. Dadurch kann derselbe Porttest je nach ausgewählter Adresse unterschiedlich ausfallen. **Namensauflösung kontrollieren:** Windows: ```powershell [RO] Resolve-DnsName server.example.internal ``` Linux: ```bash [RO] getent ahosts server.example.internal ``` macOS: ```bash [RO] dscacheutil -q host -a name server.example.internal ``` **HTTP gezielt über IPv4 testen:** ```bash [TEST] curl -4 -v https://server.example.internal/ ``` **HTTP gezielt über IPv6 testen:** ```bash [TEST] curl -6 -v https://server.example.internal/ ``` **Netcat gezielt über IPv4 oder IPv6:** ```bash [TEST] nc -4 -vz -w 5 server.example.internal 443 [TEST] nc -6 -vz -w 5 server.example.internal 443 ``` **Windows – aufgelöste Zieladresse beachten:** ```powershell [TEST] Test-NetConnection server.example.internal -Port 443 -InformationLevel Detailed ``` In der Ausgabe muss `RemoteAddress` kontrolliert werden. Ein erfolgreicher IPv4-Test beweist nicht, dass IPv6 funktioniert – und umgekehrt.
---
13. TCP-Zustände beurteilen | TCP-Zustand | Bedeutung | Diagnosehinweis | |---|---|---| | `LISTEN` | Socket wartet auf eingehende Verbindungen | Dienst ist lokal grundsätzlich gebunden | | `SYN-SENT` | Client hat SYN gesendet und wartet | Viele dauerhafte Einträge können auf fehlende Antworten hindeuten | | `SYN-RECEIVED` | SYN wurde empfangen, SYN-ACK gesendet | Viele Einträge können auf fehlende abschließende ACKs hinweisen | | `ESTABLISHED` | TCP-Verbindung besteht | Transportverbindung funktioniert grundsätzlich | | `FIN-WAIT-1` | Aktives Schließen wurde begonnen | Kurzzeitig normal | | `FIN-WAIT-2` | Eigenes FIN wurde bestätigt | Dauerhafte Häufung kann auf Probleme der Gegenstelle hinweisen | | `CLOSE-WAIT` | Gegenstelle hat geschlossen, lokale Anwendung noch nicht | Viele dauerhafte Einträge deuten häufig auf ein Anwendungsproblem hin | | `LAST-ACK` | Lokale Seite wartet auf Bestätigung ihres FIN | Kurzzeitig normal | | `TIME-WAIT` | Verbindung bleibt vorübergehend gespeichert | Viele Einträge können bei hoher Verbindungsrate normal sein | | `CLOSED` | Keine Verbindung vorhanden | Normaler Endzustand | **Windows – bestehende TCP-Verbindungen:** ```powershell [RO] Get-NetTCPConnection -State Established ``` **Windows – Verbindungen zu einem bestimmten Zielport:** ```powershell [RO] Get-NetTCPConnection -RemotePort 443 ``` **Linux – bestehende TCP-Verbindungen:** ```bash [RO] ss -tn state established ``` **Linux – Verbindungen mit Zustand und Timern:** ```bash [RO] ss -tano ``` **macOS – TCP-Zustände:** ```bash [RO] netstat -anv -p tcp ``` Ein einzelner Zustand ist nur eine Momentaufnahme. Bei sporadischen Problemen sind wiederholte Beobachtungen, Anwendungsprotokolle und gegebenenfalls ein Paketmitschnitt erforderlich.
---
14. TCP-Paketmuster interpretieren | Beobachtung im Mitschnitt | Typische Interpretation | |---|---| | `SYN → SYN/ACK → ACK` | TCP-Verbindung wurde aufgebaut | | Wiederholte SYN-Pakete ohne Antwort | Paketverlust, Filterung, falsches Routing, ausgefallenes Ziel oder fehlerhafter Rückweg | | `SYN → RST/ACK` | Ziel ist erreichbar, aber Port ist geschlossen oder wird aktiv abgelehnt | | SYN-ACK kommt an, abschließendes ACK fehlt | Problem auf der Clientseite oder beim Rückweg des ACK möglich | | Verbindung wird aufgebaut und sofort mit RST beendet | Anwendung oder Sicherheitskomponente bricht Verbindung ab | | Viele Retransmissions | Paketverlust, Überlastung, fehlerhafte Verbindung oder asymmetrische Erfassung möglich | | TCP-Verbindung erfolgreich, HTTP-Fehler folgt | Transportschicht funktioniert; Fehler liegt wahrscheinlich auf Anwendungsebene | Ein Paketmitschnitt sollte möglichst gleichzeitig auf Client und Server erfolgen. Dadurch lässt sich feststellen, an welcher Stelle Pakete verloren gehen oder verändert werden.
---
15. Paketmitschnitt für einen Port erstellen Paketmitschnitte können IP-Adressen, Hostnamen, Nutzdaten, Cookies und andere vertrauliche Informationen enthalten. Speicherung und Weitergabe müssen den betrieblichen Datenschutz- und Sicherheitsvorgaben entsprechen. **Linux – TCP-Port 443 mitschneiden:** ```bash [TEST][PRIV][FILE][SENS] sudo tcpdump -i any -nn \ 'host 192.0.2.20 and tcp port 443' \ -w port-443.pcap ``` **Linux – UDP-Port 53 mitschneiden:** ```bash [TEST][PRIV][FILE][SENS] sudo tcpdump -i any -nn \ 'host 192.0.2.53 and udp port 53' \ -w dns-udp.pcap ``` **macOS – vorher Schnittstellen ermitteln:** ```bash [RO] networksetup -listallhardwareports ``` Anschließend beispielsweise: ```bash [TEST][PRIV][FILE][SENS] sudo tcpdump -i en0 -nn \ 'host 192.0.2.20 and tcp port 443' \ -w port-443.pcap ``` **Windows – verfügbare Schnittstellen mit Dumpcap anzeigen:** ```powershell [RO] dumpcap -D ``` **Windows – Mitschnitt auf Schnittstelle 1:** ```powershell [TEST][PRIV][FILE][SENS] dumpcap -i 1 ` -f "host 192.0.2.20 and tcp port 443" ` -w port-443.pcapng ``` Die Schnittstellennummer `1` ist nur ein Beispiel und muss vorher mit `dumpcap -D` ermittelt werden.
---
16. Nützliche Wireshark-Anzeigefilter | Aufgabe | Wireshark-Anzeigefilter | |---|---| | TCP-Port 443 | `tcp.port == 443` | | UDP-Port 53 | `udp.port == 53` | | Verkehr zu oder von einer IP-Adresse | `ip.addr == 192.0.2.20` | | IPv6-Adresse | `ipv6.addr == 2001:db8::20` | | IP-Adresse und TCP-Port | `ip.addr == 192.0.2.20 && tcp.port == 443` | | TCP-SYN-Pakete | `tcp.flags.syn == 1` | | Nur erste SYN-Pakete ohne gesetztes ACK | `tcp.flags.syn == 1 && tcp.flags.ack == 0` | | TCP-Reset | `tcp.flags.reset == 1` | | Vermutete TCP-Wiederholungen | `tcp.analysis.retransmission` | | Doppelte ACKs | `tcp.analysis.duplicate_ack` | | TCP-Verbindungsaufbau | `tcp.connection.syn || tcp.connection.synack` | | ICMP-Meldungen | `icmp` | | ICMPv6-Meldungen | `icmpv6` | Wireshark-Analysehinweise wie `tcp.analysis.retransmission` sind Interpretationen anhand des vorhandenen Mitschnitts. Fehlende Pakete am Beginn oder während der Aufzeichnung können zu irreführenden Markierungen führen.
---
17. Container und veröffentlichte Ports prüfen Bei Containerdiensten müssen mehrere Ebenen unterschieden werden: ```text Client ↓ Host-IP und veröffentlichter Hostport ↓ Portweiterleitung oder Proxy ↓ Container-IP und Containerport ↓ Anwendungsprozess im Container ``` **Laufende Container und Portzuordnungen anzeigen:** ```bash [RO] docker ps --format 'table {{.Names}}\t{{.Ports}}' ``` **Portzuordnung eines Containers anzeigen:** ```bash [RO] docker port webserver ``` **Container detailliert untersuchen:** ```bash [RO][SENS] docker inspect webserver ``` Zu prüfen sind: - Ist der Container gestartet? - Ist der benötigte Containerport veröffentlicht? - Wurde der richtige Hostport verwendet? - Ist der Hostport nur an `127.0.0.1` gebunden? - Lauscht die Anwendung innerhalb des Containers? - Verwendet die Anwendung im Container die richtige Bind-Adresse? - Existiert eine vorgeschaltete Firewall oder ein Reverse Proxy? - Ist der Zugriff nur innerhalb eines Container-Netzwerks vorgesehen? Eine Docker-Ausgabe wie diese: ```text 127.0.0.1:8080->80/tcp ``` bedeutet, dass der veröffentlichte Hostport normalerweise nur über die Loopback-Adresse des Docker-Hosts erreichbar ist. Eine Ausgabe wie: ```text 0.0.0.0:8080->80/tcp ``` zeigt eine Veröffentlichung über die passenden IPv4-Adressen des Hosts. Ob ein entfernter Zugriff erlaubt ist, hängt zusätzlich von Firewall, Routing und Netzwerkrichtlinien ab.
---
18. Typische Fehlerbilder systematisch eingrenzen **Fall A – Auf dem Server existiert kein Listener** ```text Porttest vom Client schlägt fehl ↓ Auf dem Server ist kein LISTEN-Socket vorhanden ↓ Dienststatus, Dienstkonfiguration und Protokolldateien prüfen ``` Mögliche Ursachen: - Dienst wurde nicht gestartet. - Dienst ist abgestürzt. - Falscher Port wurde konfiguriert. - Dienst konnte den Port nicht binden. - Ein anderer Prozess verwendet den Port. - Dienst lauscht nur auf einer anderen Adresse oder einem anderen Protokoll. --- **Fall B – Dienst lauscht nur auf Loopback** ```text Lokaler Test erfolgreich Entfernter Test nicht erfolgreich Listener: 127.0.0.1:PORT oder ::1:PORT ``` Wahrscheinliche Ursache: - Der Dienst ist ausschließlich für lokale Verbindungen konfiguriert. --- **Fall C – Listener vorhanden, entfernter Test läuft in einen Timeout** Mögliche Ursachen: - Host-Firewall filtert den Port. - Netzwerk-Firewall oder Access Control List filtert den Port. - Falsches VLAN oder fehlerhaftes Routing. - Rückweg zum Client fehlt. - NAT- oder Portweiterleitungsregel fehlt. - Es wird die falsche IP-Adresse getestet. - Dienst lauscht nur auf IPv4 oder nur auf IPv6. - Zielsystem ist über einen anderen Netzwerkpfad erreichbar als erwartet. --- **Fall D – `Connection refused`** Mögliche Ursachen: - Kein Prozess lauscht auf dem Zielport. - Dienst lauscht nur auf einer anderen IP-Adresse. - Aktive Firewall-Ablehnung. - Portweiterleitung zeigt auf ein Ziel ohne Listener. - Anwendung wurde während des Tests beendet. --- **Fall E – TCP-Test erfolgreich, Anwendung funktioniert nicht** Die Netz- und Transportschicht funktionieren zumindest grundsätzlich. Anschließend prüfen: - TLS-Handshake und Zertifikatskette - Server Name Indication - HTTP-Statuscode - Authentifizierung - Benutzerberechtigung - Reverse Proxy - Backend-Erreichbarkeit - Anwendungskonfiguration - Datenbankverbindung - Anwendungsprotokolle --- **Fall F – Nur manche Clients sind betroffen** Vergleich zwischen funktionierendem und betroffenem Client: - aufgelöste Ziel-IP-Adresse, - IPv4 oder IPv6, - Quell-IP-Adresse, - VLAN, - Standardgateway, - Routingtabelle, - Proxykonfiguration, - lokale Firewall, - VPN-Verbindung, - DNS-Suffix und DNS-Server, - Zeitpunkt des Tests. --- **Fall G – UDP-Test liefert kein eindeutiges Ergebnis** Vorgehen: 1. Gültige Anfrage des Anwendungsprotokolls senden. 2. Gleichzeitig auf Client und Server mitschneiden. 3. Prüfen, ob die Anfrage den Server erreicht. 4. Prüfen, ob der Server eine Antwort erzeugt. 5. Prüfen, ob die Antwort den Client erreicht. 6. ICMP- beziehungsweise ICMPv6-Fehlermeldungen beachten.
---
19. Empfohlener Diagnoseablauf | Schritt | Prüfung | Ergebnisfrage | |---:|---|---| | 1 | Zielhost, Zieladresse, Transportprotokoll und Port bestimmen | Was soll genau erreicht werden? | | 2 | Namensauflösung kontrollieren | Wird die erwartete IP-Adresse verwendet? | | 3 | Routing und Quelladresse kontrollieren | Wird der erwartete Netzwerkpfad verwendet? | | 4 | Dienststatus auf dem Server prüfen | Läuft die Anwendung? | | 5 | Lokalen Listener oder UDP-Endpunkt prüfen | Lauscht der Dienst auf Port und Adresse? | | 6 | Prozess dem Socket zuordnen | Gehört der Port zur erwarteten Anwendung? | | 7 | Lokal auf dem Server testen | Funktioniert der Dienst lokal? | | 8 | Vom betroffenen Clientsegment testen | Ist der Transportweg funktionsfähig? | | 9 | IPv4 und IPv6 getrennt testen | Ist nur eine Adressfamilie betroffen? | | 10 | Anwendungsprotokoll testen | Antwortet der eigentliche Dienst korrekt? | | 11 | Firewall, ACL, NAT und Proxy prüfen | Wird der Verkehr unterwegs beeinflusst? | | 12 | Paketmitschnitt erstellen | Wo endet der erfolgreiche Paketfluss? | | 13 | Vergleich mit funktionierendem System | Welche relevante Abweichung besteht? | | 14 | Ergebnis dokumentieren | Ist die Diagnose reproduzierbar? | **Grundregel:** ```text Listener vorhanden ≠ Port aus jedem Netz erreichbar ≠ Anwendung funktionsfähig ≠ Benutzer kann den Dienst erfolgreich verwenden ``` Jede dieser Aussagen muss getrennt geprüft werden.
---
20. Kompakte Befehlstabelle | Aufgabe | Windows | Linux | macOS | |---|---|---|---| | TCP-Listener anzeigen | `[RO] Get-NetTCPConnection -State Listen` | `[RO] ss -ltn` | `[RO] lsof -nP -iTCP -sTCP:LISTEN` | | UDP-Endpunkte anzeigen | `[RO] Get-NetUDPEndpoint` | `[RO] ss -lun` | `[RO] lsof -nP -iUDP` | | Listener mit Prozess | `[RO] Get-NetTCPConnection -State Listen` | `[RO][PRIV] sudo ss -ltnp` | `[RO][PRIV] sudo lsof -nP -iTCP -sTCP:LISTEN` | | TCP-Port 443 lokal prüfen | `[RO] Get-NetTCPConnection -State Listen -LocalPort 443` | `[RO] ss -ltn 'sport = :443'` | `[RO] lsof -nP -iTCP:443 -sTCP:LISTEN` | | TCP-Port entfernt testen | `[TEST] Test-NetConnection HOST -Port 443` | `[TEST] nc -vz -w 5 HOST 443` | `[TEST] nc -vz -w 5 HOST 443` | | HTTP testen | `[TEST] curl.exe -v http://HOST/` | `[TEST] curl -v http://HOST/` | `[TEST] curl -v http://HOST/` | | HTTPS testen | `[TEST] curl.exe -v https://HOST/` | `[TEST] curl -v https://HOST/` | `[TEST] curl -v https://HOST/` | | TLS-Handshake | Falls OpenSSL installiert: `[TEST] openssl s_client -connect HOST:443 -servername HOST` | `[TEST] openssl s_client -connect HOST:443 -servername HOST` | `[TEST] openssl s_client -connect HOST:443 -servername HOST` | | TCP-Port mit Nmap | `[TEST] nmap -sT -p 443 HOST` | `[TEST] nmap -sT -p 443 HOST` | `[TEST] nmap -sT -p 443 HOST` | | UDP-Port mit Nmap | Administrator-Konsole: `[TEST][PRIV] nmap -sU -p 53 HOST` | `[TEST][PRIV] sudo nmap -sU -p 53 HOST` | `[TEST][PRIV] sudo nmap -sU -p 53 HOST` | | Bestehende TCP-Verbindungen | `[RO] Get-NetTCPConnection -State Established` | `[RO] ss -tn state established` | `[RO] netstat -anv -p tcp` | | Prozess über PID suchen | `[RO] Get-Process -Id PID` | `[RO] ps -fp PID` | `[RO] ps -p PID -o pid,ppid,user,command` | `HOST`, `PID`, IP-Adressen und Ports müssen durch die Werte des konkreten Störungsfalls ersetzt werden.
---
21. Änderungen erst nach gesicherter Diagnose durchführen Nicht vorschnell: - die Firewall vollständig deaktivieren, - beliebige Ports dauerhaft freigeben, - Dienste unkontrolliert neu starten, - Sicherheitssoftware abschalten, - Listener an alle Adressen binden, - Ports ohne Freigabe scannen, - NAT- oder Firewallregeln ohne Dokumentation verändern. Stattdessen: 1. Fehlerzustand dokumentieren. 2. Erwarteten Sollzustand bestimmen. 3. Ursache möglichst eindeutig nachweisen. 4. Änderung genehmigen lassen. 5. Nur die erforderliche Änderung durchführen. 6. Funktion und Sicherheit anschließend erneut prüfen. 7. Rückfallmöglichkeit und Ergebnis dokumentieren. Ein temporär deaktivierter Paketfilter kann zwar eine Hypothese bestätigen, erzeugt aber ein Sicherheitsrisiko und kann den ursprünglichen Zustand verändern. Besser ist eine gezielte Auswertung von Regeln, Protokollen und Paketmitschnitten.
---
22. Dokumentationsvorlage für Port- und Transportfehler ```text Störung: Zeitpunkt: Betroffener Benutzer beziehungsweise Standort: Clientname: Client-IP-Adresse: Client-VLAN: Client-Betriebssystem: Zielhostname: Aufgelöste Zieladresse: Verwendete Adressfamilie: IPv4 / IPv6 Transportprotokoll: TCP / UDP Zielport: Erwarteter Dienst: Lokaler Listener vorhanden: Ja / Nein Bind-Adresse: Zugehöriger Prozess: Prozess-ID: Dienststatus: Lokaler Funktionstest: Entfernter Porttest: Anwendungsprotokolltest: TCP- beziehungsweise UDP-Ergebnis: Beobachtete Fehlermeldung: Firewall- oder ACL-Prüfung: Paketmitschnitt vorhanden: Beobachtetes Paketmuster: Vergleich mit funktionierendem System: Festgestellte Ursache: Durchgeführte Änderung: Änderung genehmigt durch: Ergebnis der Nachprüfung: Offene Punkte: ``` Vor der Ablage müssen Passwörter, Sitzungstoken, personenbezogene Daten und andere vertrauliche Inhalte entfernt oder geschützt werden.
---
23. Kontrollfragen nach der Diagnose - Wurde wirklich der richtige Host getestet? - Wurde die tatsächlich aufgelöste IP-Adresse dokumentiert? - Wurde zwischen TCP und UDP unterschieden? - Lauscht der Dienst auf dem erwarteten Port? - Gehört der Listener zur erwarteten Anwendung? - Lauscht der Dienst an der richtigen IP-Adresse? - Wurden IPv4 und IPv6 getrennt betrachtet? - Wurde vom tatsächlich betroffenen Netzsegment getestet? - Wurde ein Anwendungstest zusätzlich zum Porttest durchgeführt? - Wurde bei UDP eine gültige Protokollanfrage verwendet? - Wurden Rückweg und Firewallregeln berücksichtigt? - Wurde ein Timeout nicht vorschnell als „Port geschlossen“ bezeichnet? - Wurde ein erfolgreicher TCP-Test nicht mit einer funktionsfähigen Anwendung gleichgesetzt? - Ist die Ursache durch Messergebnisse belegt? - Wurde der Zustand nach einer Änderung erneut geprüft?
---
24. Quellen und weiterführende Dokumentation - Microsoft Learn – Get-NetTCPConnection: https://learn.microsoft.com/powershell/module/nettcpip/get-nettcpconnection - Microsoft Learn – Get-NetUDPEndpoint: https://learn.microsoft.com/powershell/module/nettcpip/get-netudpendpoint - Microsoft Learn – Test-NetConnection: https://learn.microsoft.com/powershell/module/nettcpip/test-netconnection - Linux-Handbuch – `ss(8)`: https://man7.org/linux/man-pages/man8/ss.8.html - RFC 9293 – Transmission Control Protocol: https://www.rfc-editor.org/rfc/rfc9293.html - RFC 768 – User Datagram Protocol: https://www.rfc-editor.org/rfc/rfc768.html - IANA – Service Name and Transport Protocol Port Number Registry: https://www.iana.org/assignments/service-names-port-numbers/ - Nmap – Port Scanning Basics: https://nmap.org/book/man-port-scanning-basics.html - Nmap – Port Scanning Techniques: https://nmap.org/book/man-port-scanning-techniques.html - Wireshark – TCP Display Filter Reference: https://www.wireshark.org/docs/dfref/t/tcp.html - Wireshark – UDP Display Filter Reference: https://www.wireshark.org/docs/dfref/u/udp.html - Docker Docs – Publishing and exposing ports: https://docs.docker.com/get-started/docker-concepts/running-containers/publishing-ports/
# 3.10 Firewall- und Paketfilterfehler analysieren Firewalls können Verbindungen erlauben, verwerfen, ausdrücklich ablehnen, protokollieren oder an andere Ziele weiterleiten. Eine Anwendung kann korrekt laufen und auf dem richtigen Port lauschen, während der Zugriff trotzdem durch einen lokalen oder zentralen Paketfilter verhindert wird. Die zentrale Frage dieser Seite lautet: > Erreicht der Datenverkehr das Zielsystem, und welche Firewallregel entscheidet tatsächlich über das Paket? ---
1. Sicherheits- und Aktionskennzeichnungen | Kennzeichnung | Bedeutung | |---|---| | `[RO]` | Rein lesender Befehl, der normalerweise keine Konfiguration verändert | | `[TEST]` | Aktiver Test, der Netzwerkverkehr erzeugt | | `[PRIV]` | Administrator- oder Root-Rechte können erforderlich sein | | `[FILE]` | Der Befehl schreibt Ausgaben in eine Datei | | `[SENS]` | Die Ausgabe kann sensible Informationen enthalten | | `[CHANGE]` | Der Befehl verändert die Konfiguration | | `[DISRUPT]` | Der Befehl kann Verbindungen oder Dienste beeinträchtigen | Firewallregeln enthalten häufig interne IP-Adressen, Servernamen, Anwendungen, Netzwerkbereiche und Sicherheitsrichtlinien. Entsprechende Ausgaben sind vertraulich zu behandeln.
---
2. Firewallfehler nicht vorschnell vermuten Die Meldung „Das ist bestimmt die Firewall“ ist zunächst nur eine Hypothese. Vor einer Änderung müssen mindestens folgende Punkte geprüft werden: 1. Wurde der richtige Hostname verwendet? 2. Wurde die erwartete IP-Adresse aufgelöst? 3. Ist eine gültige Route zum Ziel vorhanden? 4. Läuft der benötigte Dienst? 5. Lauscht der Dienst auf dem erwarteten Port und Protokoll? 6. Lauscht der Dienst an der richtigen IP-Adresse? 7. Funktioniert der Zugriff lokal auf dem Server? 8. Funktioniert der Zugriff aus einem anderen Netzsegment? 9. Erreicht das Paket das Zielsystem? 10. Wird eine Blockierung protokolliert? **Wichtig:** ```text Timeout ≠ sicherer Nachweis einer Firewallblockierung ``` Ein Timeout kann ebenfalls durch Paketverlust, falsches Routing, einen fehlenden Rückweg, eine falsche Zieladresse, NAT-Fehler oder einen ausgefallenen Host entstehen.
---
3. DROP, REJECT und ALLOW unterscheiden | Aktion | Verhalten | Typische Beobachtung | |---|---|---| | `ALLOW` beziehungsweise `ACCEPT` | Passender Verkehr wird zugelassen | Verbindung kann aufgebaut werden | | `DROP` | Paket wird ohne Antwort verworfen | Client wartet häufig bis zum Timeout | | `REJECT` | Paket wird abgelehnt und eine Fehlermeldung zurückgesendet | Client erhält häufig schnell einen Fehler | | `LOG` | Paketinformationen werden protokolliert | Allein keine endgültige Erlaubnis oder Blockierung | | `DNAT` beziehungsweise Portweiterleitung | Zieladresse oder Zielport wird verändert | Client erreicht möglicherweise ein internes Ziel | | `SNAT` beziehungsweise Masquerading | Quelladresse wird verändert | Ziel erkennt die Adresse des NAT-Systems | | `RETURN` | Verarbeitung kehrt zur aufrufenden Regelkette zurück | Wirkung hängt von weiteren Regeln ab | Bei TCP kann eine aktive Ablehnung beispielsweise durch ein TCP-RST sichtbar werden. Bei anderen Fällen kann eine ICMP- oder ICMPv6-Fehlermeldung zurückgegeben werden. Das genaue Verhalten hängt vom Betriebssystem, Regelwerk und eingesetzten Sicherheitsprodukt ab.
---
4. Prüfen, welche Firewall tatsächlich verwendet wird Auf einem System können mehrere Verwaltungsebenen vorhanden sein: - native Betriebssystem-Firewall, - `firewalld`, - `nftables`, - `iptables`, - `ufw`, - Sicherheitssoftware eines Drittanbieters, - Endpoint-Detection-and-Response-System, - Container-Firewallregeln, - Hypervisor-Firewall, - zentrale Netzwerk-Firewall, - Router-ACL, - Cloud-Sicherheitsgruppe, - VPN- oder Zero-Trust-Client. Eine Oberfläche wie `ufw` oder `firewalld` verwaltet im Hintergrund das eigentliche Paketfiltersystem. Regeln sollten deshalb nicht unkoordiniert über mehrere Werkzeuge verändert werden. | Betriebssystem | Typische lokale Filter | |---|---| | Windows | Windows Defender Firewall, IPsec-Regeln, Sicherheitssoftware | | Linux | nftables, firewalld, ufw, iptables und Sicherheitssoftware | | macOS | Anwendungsfirewall, Packet Filter `pf` und Sicherheitssoftware | **Grundregel:** > Zuerst die aktive Verwaltungs- und Richtlinienebene identifizieren, danach Regeln bewerten.
---
5. Datenfluss und Prüfrichtung festlegen Vor der Regelsuche muss der betroffene Datenfluss eindeutig beschrieben werden. ```text Client-IP:Quellport ↓ Transportprotokoll ↓ Ziel-IP:Zielport ↓ Serveranwendung ``` Zu dokumentieren sind: | Merkmal | Beispiel | |---|---| | Richtung | Client zum Server | | Adressfamilie | IPv4 | | Transportprotokoll | TCP | | Quelladresse | `192.0.2.25` | | Quellport | dynamisch, beispielsweise `53144` | | Zieladresse | `192.0.2.53` | | Zielport | `443` | | Schnittstelle | `Ethernet` beziehungsweise `eth0` | | Netzwerkprofil oder Zone | `Domain` beziehungsweise `public` | | Anwendung | Webserver | | Zeitpunkt | Mit Zeitzone und Sekunden | **Eingehend und ausgehend sind standortabhängig:** ```text Client: ausgehende Verbindung Server: eingehende Verbindung ``` Bei Routern, NAT-Systemen und Firewalls zwischen Netzen kann zusätzlich die Weiterleitungsrichtung betroffen sein.
---
6. Windows-Firewallstatus und aktive Profile prüfen Windows verwendet die Profile: - `Domain` - `Private` - `Public` Je nach aktiver Netzwerkverbindung können unterschiedliche Profile und Regeln gelten. **Aktives Netzwerkprofil prüfen:** ```powershell [RO] Get-NetConnectionProfile | Format-Table InterfaceAlias, Name, NetworkCategory, IPv4Connectivity, IPv6Connectivity ``` **Status aller Firewallprofile:** ```powershell [RO] Get-NetFirewallProfile | Format-Table Name, Enabled, DefaultInboundAction, DefaultOutboundAction ``` **Ausführliche Profileinstellungen:** ```powershell [RO] Get-NetFirewallProfile | Format-List Name, Enabled, DefaultInboundAction, DefaultOutboundAction, AllowInboundRules, AllowLocalFirewallRules, AllowLocalIPsecRules, NotifyOnListen, LogAllowed, LogBlocked, LogFileName, LogMaxSizeKilobytes ``` **Klassische Statusanzeige:** ```cmd [RO] netsh advfirewall show allprofiles ``` Zu kontrollieren sind: - Welches Netzwerkprofil ist aktiv? - Ist die Firewall für dieses Profil aktiviert? - Was ist die Standardaktion für eingehenden Verkehr? - Was ist die Standardaktion für ausgehenden Verkehr? - Dürfen lokale Regeln angewendet werden? - Werden die Einstellungen durch Gruppenrichtlinien verwaltet? - Ist die Protokollierung zugelassener oder blockierter Pakete aktiviert? **Typischer Fehler:** ```text Regel gilt nur für Profil Private ↓ Netzwerk wurde als Public erkannt ↓ Regel greift nicht ``` Das Netzwerkprofil darf nicht allein zur Fehlerbehebung verändert werden. Zuerst ist zu prüfen, warum Windows das Netzwerk entsprechend eingestuft hat und welche Unternehmensrichtlinie gelten soll.
---
7. Windows-Firewallregeln untersuchen **Alle aktivierten Regeln anzeigen:** ```powershell [RO][SENS] Get-NetFirewallRule -Enabled True | Format-Table DisplayName, Direction, Action, Profile ``` **Aktive Blockierungsregeln anzeigen:** ```powershell [RO][SENS] Get-NetFirewallRule -Enabled True -Action Block | Format-Table DisplayName, Direction, Profile ``` **Aktive eingehende Erlaubnisregeln anzeigen:** ```powershell [RO][SENS] Get-NetFirewallRule -Enabled True -Direction Inbound -Action Allow | Format-Table DisplayName, Profile ``` **Bestimmte Regel ausführlich anzeigen:** ```powershell [RO][SENS] Get-NetFirewallRule -DisplayName "NAME DER REGEL" | Format-List * ``` Windows speichert Port-, Adress-, Programm-, Dienst- und Schnittstellenbedingungen in zugehörigen Filterobjekten. `Get-NetFirewallRule` allein zeigt deshalb nicht alle Bedingungen einer Regel. **Portbedingungen einer Regel:** ```powershell [RO] Get-NetFirewallRule -DisplayName "NAME DER REGEL" | Get-NetFirewallPortFilter | Format-List * ``` **Adressbedingungen einer Regel:** ```powershell [RO][SENS] Get-NetFirewallRule -DisplayName "NAME DER REGEL" | Get-NetFirewallAddressFilter | Format-List * ``` **Anwendungsbedingung einer Regel:** ```powershell [RO][SENS] Get-NetFirewallRule -DisplayName "NAME DER REGEL" | Get-NetFirewallApplicationFilter | Format-List * ``` **Dienstbedingung einer Regel:** ```powershell [RO] Get-NetFirewallRule -DisplayName "NAME DER REGEL" | Get-NetFirewallServiceFilter | Format-List * ``` **Schnittstellenbedingung einer Regel:** ```powershell [RO] Get-NetFirewallRule -DisplayName "NAME DER REGEL" | Get-NetFirewallInterfaceFilter | Format-List * ``` **Regeln für lokalen TCP-Port 443 suchen:** ```powershell [RO][SENS] Get-NetFirewallPortFilter -Protocol TCP | Where-Object LocalPort -eq "443" | Get-NetFirewallRule | Format-Table DisplayName, Enabled, Direction, Action, Profile ``` **Regeln für lokalen UDP-Port 53 suchen:** ```powershell [RO][SENS] Get-NetFirewallPortFilter -Protocol UDP | Where-Object LocalPort -eq "53" | Get-NetFirewallRule | Format-Table DisplayName, Enabled, Direction, Action, Profile ``` **Regeln für eine bestimmte Anwendung suchen:** ```powershell [RO][SENS] Get-NetFirewallApplicationFilter | Where-Object Program -like "*\PROGRAMM.exe" | Get-NetFirewallRule | Format-Table DisplayName, Enabled, Direction, Action, Profile ``` Der Programmpfad muss durch den tatsächlichen Pfad beziehungsweise ein eindeutiges Suchmuster ersetzt werden.
---
8. Windows-Regeln vollständig beurteilen Bei einer vermeintlich passenden Regel müssen alle Bedingungen kontrolliert werden: | Bedingung | Kontrollfrage | |---|---| | `Enabled` | Ist die Regel aktiviert? | | `Direction` | Gilt sie eingehend oder ausgehend? | | `Action` | Erlaubt oder blockiert sie? | | `Profile` | Gilt sie für das aktive Profil? | | `Protocol` | TCP, UDP, ICMPv4 oder ICMPv6? | | `LocalPort` | Stimmt der lokale Port? | | `RemotePort` | Ist ein bestimmter entfernter Port vorgegeben? | | `LocalAddress` | Gilt sie für die verwendete lokale Adresse? | | `RemoteAddress` | Ist die Clientadresse oder ihr Netz erlaubt? | | `Program` | Stimmt der ausführbare Programmpfad? | | `Service` | Ist die Regel an einen bestimmten Dienst gebunden? | | `InterfaceType` | Gilt sie für LAN, WLAN oder Remotezugriff? | | `EdgeTraversalPolicy` | Ist spezieller eingehender Verkehr betroffen? | | Richtlinienquelle | Stammt sie lokal, aus Gruppenrichtlinien oder MDM? | **Richtlinienquelle anzeigen:** ```powershell [RO][SENS] Get-NetFirewallRule -PolicyStore ActiveStore | Select-Object DisplayName, Enabled, Direction, Action, Profile, PolicyStoreSourceType, PolicyStoreSource | Format-Table -AutoSize ``` `ActiveStore` repräsentiert die wirksame Zusammenführung der angewendeten Richtlinien. Eine lokal sichtbare Regel kann durch zentral verwaltete Vorgaben eingeschränkt sein. **Wichtig:** Eine scheinbar passende Erlaubnisregel beweist nicht automatisch, dass keine andere wirksame Regel oder Sicherheitskomponente den Datenverkehr blockiert.
---
9. Windows-Firewallprotokollierung prüfen **Konfigurierte Protokolldateien und Einstellungen anzeigen:** ```powershell [RO] Get-NetFirewallProfile | Select-Object Name, LogAllowed, LogBlocked, LogFileName, LogMaxSizeKilobytes | Format-List ``` Der konkrete Speicherort muss aus `LogFileName` übernommen werden. Er sollte nicht angenommen oder fest im Diagnoseablauf vorgegeben werden. **Konfigurierte Protokolldatei lesen:** ```powershell [RO][PRIV][SENS] Get-Content "PFAD AUS LogFileName" -Tail 100 ``` **Datei fortlaufend beobachten:** ```powershell [RO][PRIV][SENS] Get-Content "PFAD AUS LogFileName" -Tail 20 -Wait ``` Während der Beobachtung wird der fehlgeschlagene Verbindungstest erneut ausgeführt. Dabei müssen Zeitpunkt, Quelladresse, Zieladresse, Protokoll und Port abgeglichen werden. **Ereignisprotokolle zur Firewall suchen:** ```powershell [RO][PRIV][SENS] Get-WinEvent -ListLog *Firewall* | Select-Object LogName, IsEnabled, RecordCount ``` Anschließend kann ein tatsächlich vorhandenes Protokoll gezielt abgefragt werden: ```powershell [RO][PRIV][SENS] Get-WinEvent -LogName "ERMITTELTER PROTOKOLLNAME" -MaxEvents 50 ``` Nicht jede Paketblockierung erscheint automatisch im Windows-Ereignisprotokoll. Die erforderliche Überwachung beziehungsweise Protokollierung muss zuvor aktiviert und durch die Unternehmensrichtlinie erlaubt sein.
---
10. Linux-Firewallsystem identifizieren **Vorhandene Werkzeuge ermitteln:** ```bash [RO] command -v firewall-cmd [RO] command -v nft [RO] command -v ufw [RO] command -v iptables ``` **Aktive Dienste prüfen:** ```bash [RO] systemctl is-active firewalld [RO] systemctl is-active nftables [RO] systemctl is-active ufw ``` Eine Ausgabe wie `inactive`, `failed` oder `unknown` muss im Kontext der jeweiligen Distribution bewertet werden. Beispielsweise kann ein nftables-Regelwerk aktiv sein, obwohl kein dauerhaft laufender `nftables`-Dienst angezeigt wird. **Geladene nftables-Regeln prüfen:** ```bash [RO][PRIV][SENS] sudo nft list ruleset ``` **iptables-Regeln prüfen:** ```bash [RO][PRIV][SENS] sudo iptables -S [RO][PRIV][SENS] sudo ip6tables -S ``` **iptables-Regeln mit Zählern:** ```bash [RO][PRIV][SENS] sudo iptables -L -n -v --line-numbers [RO][PRIV][SENS] sudo ip6tables -L -n -v --line-numbers ``` Auf modernen Linux-Systemen kann der Befehl `iptables` ein Kompatibilitätsfrontend für nftables sein. Deshalb muss geprüft werden, welche Verwaltungsebene die Distribution tatsächlich verwendet.
---
11. firewalld analysieren `firewalld` arbeitet mit Zonen. Schnittstellen oder Quellnetze werden einer Zone zugeordnet, für die Dienste, Ports und weitere Regeln gelten. **Status prüfen:** ```bash [RO] firewall-cmd --state ``` **Standardzone anzeigen:** ```bash [RO] firewall-cmd --get-default-zone ``` **Aktive Zonen und zugehörige Schnittstellen anzeigen:** ```bash [RO] firewall-cmd --get-active-zones ``` **Zone einer bestimmten Schnittstelle ermitteln:** ```bash [RO] firewall-cmd --get-zone-of-interface=eth0 ``` `eth0` muss durch die tatsächliche Schnittstelle ersetzt werden. **Komplette Laufzeitkonfiguration einer Zone anzeigen:** ```bash [RO][SENS] firewall-cmd --zone=public --list-all ``` **Alle Zonen anzeigen:** ```bash [RO][SENS] firewall-cmd --list-all-zones ``` **Freigegebene Dienste:** ```bash [RO] firewall-cmd --zone=public --list-services ``` **Freigegebene Ports:** ```bash [RO] firewall-cmd --zone=public --list-ports ``` **Prüfen, ob TCP-Port 443 in der Laufzeitkonfiguration freigegeben ist:** ```bash [RO] firewall-cmd --zone=public --query-port=443/tcp ``` **Prüfen, ob der HTTPS-Dienst freigegeben ist:** ```bash [RO] firewall-cmd --zone=public --query-service=https ``` **Rich Rules anzeigen:** ```bash [RO][SENS] firewall-cmd --zone=public --list-rich-rules ``` **Policies anzeigen:** ```bash [RO][SENS] firewall-cmd --get-policies ``` Bei jeder Prüfung muss die tatsächlich aktive Zone verwendet werden. Die Zone `public` ist nur ein Beispiel.
---
12. firewalld: Laufzeit- und dauerhafte Konfiguration vergleichen `firewalld` trennt zwischen: - **Runtime-Konfiguration:** aktuell im laufenden System wirksam - **Permanent-Konfiguration:** für erneutes Laden beziehungsweise Neustart gespeichert **Aktuelle Laufzeitkonfiguration:** ```bash [RO][SENS] firewall-cmd --zone=public --list-all ``` **Dauerhafte Konfiguration:** ```bash [RO][SENS] firewall-cmd --permanent --zone=public --list-all ``` **Typische Abweichungen:** | Situation | Folge | |---|---| | Port nur zur Laufzeit freigegeben | Freigabe verschwindet nach Reload oder Neustart | | Port nur dauerhaft eingetragen | Freigabe ist noch nicht zwingend zur Laufzeit aktiv | | Falsche Zone bearbeitet | Regel existiert, gilt aber nicht für die betroffene Schnittstelle | | Dienstname freigegeben, aber andere Portdefinition erwartet | Tatsächlicher Dienstport kann abweichen | | Schnittstellenzuordnung geändert | Anderes Zonenregelwerk wird wirksam | Eine Abweichung ist nicht automatisch ein Fehler. Sie muss mit dem vorgesehenen Sollzustand verglichen werden.
---
13. ufw analysieren **Status und Standardrichtlinien anzeigen:** ```bash [RO][PRIV][SENS] sudo ufw status verbose ``` **Regeln nummeriert anzeigen:** ```bash [RO][PRIV][SENS] sudo ufw status numbered ``` **Erweiterte Rohdarstellung anzeigen:** ```bash [RO][PRIV][SENS] sudo ufw show raw ``` Zu kontrollieren sind: - Ist `ufw` aktiv? - Welche Standardaktion gilt eingehend? - Welche Standardaktion gilt ausgehend? - Ist der richtige Port freigegeben? - Gilt die Regel für TCP oder UDP? - Ist die Regel auf eine Quelladresse beschränkt? - Existiert eine separate IPv6-Regel? - Gilt die Regel für die richtige Schnittstelle? - Gibt es vorhergehende Ablehnungsregeln? **Beispiel einer begrenzten Regelbeschreibung:** ```text TCP-Port 443 nur aus 192.0.2.0/24 eingehend über die vorgesehene Schnittstelle ``` Eine Ausgabe wie `443 ALLOW Anywhere` muss zusätzlich hinsichtlich IPv4, IPv6 und der tatsächlich aktiven Backend-Regeln bewertet werden.
---
14. nftables-Regelwerk untersuchen **Gesamtes geladenes Regelwerk anzeigen:** ```bash [RO][PRIV][SENS] sudo nft list ruleset ``` **Tabellen anzeigen:** ```bash [RO][PRIV] sudo nft list tables ``` **Regelwerk mit Handles anzeigen:** ```bash [RO][PRIV][SENS] sudo nft -a list ruleset ``` **Regelwerk mit Zählern und Handles beobachten:** ```bash [RO][PRIV][SENS] sudo nft -a list ruleset ``` Bei nftables sind insbesondere zu prüfen: | Bestandteil | Bedeutung | |---|---| | Familie | `ip`, `ip6`, `inet`, `arp`, `bridge` oder `netdev` | | Tabelle | Logische Sammlung von Chains und Regeln | | Base Chain | An einen Netfilter-Hook gebundene Kette | | Hook | Beispielsweise `input`, `output` oder `forward` | | Priority | Reihenfolge gegenüber anderen Base Chains | | Policy | Standardaktion der Base Chain | | Match | Bedingung wie Adresse, Port, Protokoll oder Schnittstelle | | Verdict | Beispielsweise `accept`, `drop`, `reject`, `jump` oder `return` | | Counter | Anzahl passender Pakete und Bytes | | Handle | Interne Kennung einer Regel | **Wichtige Diagnosefrage:** > Steigt der Zähler der vermuteten Regel, während der Verbindungstest ausgeführt wird? Wenn der Zähler nicht steigt, kann dies bedeuten: - Das Paket erreicht das System nicht. - Das Paket durchläuft eine andere Chain. - Eine vorherige Regel entscheidet bereits. - Protokoll, Port oder Adresse stimmen nicht. - IPv4 und IPv6 wurden verwechselt. - Eine andere Firewallkomponente greift ein.
---
15. iptables-Regeln untersuchen **Filterregeln mit Zählern und Zeilennummern:** ```bash [RO][PRIV][SENS] sudo iptables -L -n -v --line-numbers ``` **IPv6-Regeln:** ```bash [RO][PRIV][SENS] sudo ip6tables -L -n -v --line-numbers ``` **Regeln in Befehlsschreibweise:** ```bash [RO][PRIV][SENS] sudo iptables -S ``` **NAT-Tabelle:** ```bash [RO][PRIV][SENS] sudo iptables -t nat -L -n -v --line-numbers ``` **Weitere häufig relevante Tabellen:** ```bash [RO][PRIV][SENS] sudo iptables -t mangle -L -n -v --line-numbers [RO][PRIV][SENS] sudo iptables -t raw -L -n -v --line-numbers ``` Zu prüfen sind: - Standardrichtlinie der Chain, - Reihenfolge der Regeln, - Quell- und Zieladressen, - Eingangs- und Ausgangsschnittstelle, - Transportprotokoll, - Quell- und Zielport, - Verbindungszustand, - Sprung in benutzerdefinierte Chains, - Paket- und Bytezähler, - IPv4- und IPv6-Regeln, - NAT-Regeln. Bei iptables entscheidet häufig die erste zutreffende Regel, die ein endgültiges Ziel wie `ACCEPT`, `DROP` oder `REJECT` ausführt. Eine Erlaubnisregel unterhalb einer bereits passenden Blockierungsregel wird dann nicht erreicht.
---
16. macOS-Anwendungsfirewall prüfen Die macOS-Anwendungsfirewall kontrolliert hauptsächlich eingehende Verbindungen anhand von Anwendungen und Diensten. Sie ist nicht mit dem Packet Filter `pf` gleichzusetzen. **Grafische Prüfung:** ```text Systemeinstellungen → Netzwerk → Firewall ``` Je nach macOS-Version können die genaue Position und Bezeichnungen abweichen. **Status der Anwendungsfirewall:** ```bash [RO] /usr/libexec/ApplicationFirewall/socketfilterfw --getglobalstate ``` **Prüfen, ob alle eingehenden Verbindungen blockiert werden:** ```bash [RO] /usr/libexec/ApplicationFirewall/socketfilterfw --getblockall ``` **Stealth-Modus prüfen:** ```bash [RO] /usr/libexec/ApplicationFirewall/socketfilterfw --getstealthmode ``` **Automatische Freigabe signierter Software prüfen:** ```bash [RO] /usr/libexec/ApplicationFirewall/socketfilterfw --getallowsigned ``` **Konfigurierte Anwendungen anzeigen:** ```bash [RO][PRIV][SENS] sudo /usr/libexec/ApplicationFirewall/socketfilterfw --listapps ``` Zu kontrollieren sind: - Ist die Anwendungsfirewall eingeschaltet? - Werden alle eingehenden Verbindungen blockiert? - Ist die betroffene Anwendung aufgeführt? - Ist die Anwendung zugelassen oder blockiert? - Hat sich der Programmpfad nach einem Update geändert? - Wird der Dienst durch eine andere ausführbare Datei gestartet? - Wird die Einstellung durch ein Konfigurationsprofil oder MDM verwaltet? Die genaue Ausgabe von `socketfilterfw` kann zwischen macOS-Versionen variieren.
---
17. macOS Packet Filter pf prüfen `pf` ist ein paketbasierter Filter und getrennt von der macOS-Anwendungsfirewall zu betrachten. **Status und grundlegende Informationen:** ```bash [RO][PRIV] sudo pfctl -s info ``` **Geladene Filterregeln anzeigen:** ```bash [RO][PRIV][SENS] sudo pfctl -s rules ``` **NAT-Regeln anzeigen:** ```bash [RO][PRIV][SENS] sudo pfctl -s nat ``` **Alle verfügbaren pf-Informationen anzeigen:** ```bash [RO][PRIV][SENS] sudo pfctl -s all ``` **Zustandstabelle anzeigen:** ```bash [RO][PRIV][SENS] sudo pfctl -s states ``` **Regeln mit zusätzlichen Informationen anzeigen:** ```bash [RO][PRIV][SENS] sudo pfctl -vvs rules ``` Zu kontrollieren sind: - Ist `pf` aktiviert? - Welche Regeln und Anchors wurden geladen? - Gibt es NAT- oder Weiterleitungsregeln? - Stimmen Schnittstelle, Adressfamilie, Adresse, Protokoll und Port? - Erhöhen sich Regelzähler während des Tests? - Wird das Regelwerk durch VPN-, Virtualisierungs- oder Sicherheitssoftware ergänzt? **Nicht ausführen, solange keine ausdrücklich genehmigte Änderung vorgesehen ist:** ```text pf aktivieren oder deaktivieren Regelwerk neu laden Zustandstabellen leeren Anchors verändern ``` Solche Aktionen können bestehende Netzwerkverbindungen und Sicherheitsrichtlinien beeinflussen.
---
18. Host-Firewall oder Netzwerk-Firewall unterscheiden Ein Vergleich mehrerer Messpunkte hilft, die blockierende Stelle einzugrenzen. ```text Client ↓ Client-Firewall ↓ Switch/VLAN ↓ Router oder zentrale Firewall ↓ Server-Firewall ↓ Serveranwendung ``` | Beobachtung | Mögliche Schlussfolgerung | |---|---| | Paket verlässt den Client nicht | Client-Firewall, Anwendung oder lokales Routing prüfen | | Paket verlässt Client, erreicht Server aber nicht | Netzwerkpfad, ACL, VPN, NAT oder zentrale Firewall prüfen | | Paket erreicht Server, aber Anwendung erhält es nicht | Server-Firewall oder falsche Bindung prüfen | | SYN erreicht Server, keine Antwort verlässt ihn | Listener, Server-Firewall oder lokales Routing prüfen | | SYN-ACK verlässt Server, erreicht Client nicht | Rückweg oder Filter zwischen Server und Client prüfen | | Verbindung funktioniert lokal, aber nicht entfernt | Bind-Adresse, Server-Firewall oder Netzwerkfilter prüfen | | Nur ein Quellnetz ist betroffen | Quellnetz-, VLAN-, Zonen- oder Adressregel prüfen | | Nur IPv6 ist betroffen | IPv6-Regeln und ICMPv6 gesondert prüfen | Ein gleichzeitiger Paketmitschnitt auf Client und Server ist wesentlich aussagekräftiger als ein einseitiger Porttest.
---
19. Paketmitschnitt zur Firewallanalyse verwenden **Linux – TCP-Port 443 auf allen Schnittstellen:** ```bash [TEST][PRIV][FILE][SENS] sudo tcpdump -i any -nn \ 'host 192.0.2.25 and tcp port 443' \ -w firewall-test.pcap ``` **macOS – TCP-Port 443 auf einer konkreten Schnittstelle:** ```bash [TEST][PRIV][FILE][SENS] sudo tcpdump -i en0 -nn \ 'host 192.0.2.25 and tcp port 443' \ -w firewall-test.pcap ``` **Windows mit Dumpcap – Schnittstellen ermitteln:** ```powershell [RO] dumpcap -D ``` **Windows – Mitschnitt auf der zuvor bestimmten Schnittstelle:** ```powershell [TEST][PRIV][FILE][SENS] dumpcap -i 1 ` -f "host 192.0.2.25 and tcp port 443" ` -w firewall-test.pcapng ``` Die Schnittstellennamen und -nummern sind Beispiele und müssen vorher ermittelt werden. **Wireshark-Anzeigefilter:** | Aufgabe | Filter | |---|---| | Gesamter Verkehr zwischen zwei IPv4-Systemen | `ip.addr == 192.0.2.25 && ip.addr == 192.0.2.53` | | TCP-Port 443 | `tcp.port == 443` | | Erste TCP-SYN-Pakete | `tcp.flags.syn == 1 && tcp.flags.ack == 0` | | TCP-Reset | `tcp.flags.reset == 1` | | ICMP-Fehler | `icmp` | | ICMPv6-Fehler | `icmpv6` | | Vermutete Wiederholungen | `tcp.analysis.retransmission` | **Interpretation:** | Paketmuster | Mögliche Bedeutung | |---|---| | Wiederholtes SYN ohne Antwort | DROP, Paketverlust, falscher Rückweg oder ausgefallenes Ziel | | SYN gefolgt von RST/ACK | Port geschlossen oder aktive Ablehnung | | ICMP administratively prohibited | Paketfilter oder Richtlinie lehnt Verkehr ausdrücklich ab | | SYN und SYN-ACK sichtbar, ACK fehlt | Rückweg oder Clientseite prüfen | | Vollständiger Handshake sichtbar | Firewall lässt den TCP-Aufbau grundsätzlich zu | | Handshake erfolgreich, danach Abbruch | Anwendungs-, TLS- oder Sitzungsproblem möglich | Der Mitschnitt beweist nur, was am jeweiligen Messpunkt sichtbar war.
---
20. Firewallprotokolle zeitlich korrekt auswerten Für eine zuverlässige Zuordnung werden folgende Werte benötigt: ```text Datum und Uhrzeit Zeitzone Quelladresse Zieladresse Transportprotokoll Quellport Zielport Richtung Aktion Schnittstelle oder Zone Regelname beziehungsweise Regel-ID ``` **Systemzeit prüfen:** | Betriebssystem | Befehl | |---|---| | Windows | `[RO] Get-Date -Format o` | | Linux | `[RO] date --iso-8601=seconds` | | macOS | `[RO] date "+%Y-%m-%dT%H:%M:%S%z"` | Bei zentralen Firewalls können Zeitstempel in UTC gespeichert werden. Client-, Server- und Firewallzeit müssen deshalb einschließlich Zeitzone verglichen werden. **Empfohlener Testablauf:** 1. Exakten Startzeitpunkt notieren. 2. Einen einzelnen reproduzierbaren Verbindungstest durchführen. 3. Exakten Endzeitpunkt notieren. 4. Protokolle auf dieses Zeitfenster beschränken. 5. Quell- und Zieladresse sowie Port abgleichen. 6. Regelname und Aktion dokumentieren. 7. Bei NAT sowohl ursprüngliche als auch übersetzte Adressen berücksichtigen.
---
21. Stateful Inspection und Verbindungszustände berücksichtigen Moderne Firewalls arbeiten häufig zustandsorientiert. Sie verfolgen bestehende Verbindungen und unterscheiden beispielsweise: - neue Verbindung, - bestehende Verbindung, - zugehörige Verbindung, - ungültiger Zustand. Dadurch kann Rückverkehr erlaubt sein, obwohl keine allgemeine eingehende Freigabe für den dynamischen Clientport existiert. **Linux – Conntrack-Werkzeug vorhanden?** ```bash [RO] command -v conntrack ``` **Verbindungseinträge anzeigen, sofern das Werkzeug installiert ist:** ```bash [RO][PRIV][SENS] sudo conntrack -L ``` **Nur TCP-Verbindungen zu Port 443 filtern:** ```bash [RO][PRIV][SENS] sudo conntrack -L -p tcp --dport 443 ``` `conntrack` ist nicht auf jedem Linux-System standardmäßig installiert. Mögliche Fehlerbilder: - asymmetrisches Routing führt nur eine Richtung durch die zustandsorientierte Firewall, - veraltete Zustandseinträge beeinflussen neue Verbindungen, - NAT-Zustände stimmen nicht mit dem aktuellen Pfad überein, - Pakete werden als ungültig bewertet, - mehrere Firewalls sehen unterschiedliche Teile derselben Verbindung. Zustandstabellen dürfen nicht ohne Freigabe geleert werden. Das kann zahlreiche bestehende Verbindungen unterbrechen.
---
22. ICMP und ICMPv6 nicht pauschal blockieren ICMP beziehungsweise ICMPv6 wird nicht nur für `ping` verwendet. Es übermittelt wichtige Netzwerk- und Fehlermeldungen. Dazu gehören unter anderem: - Ziel nicht erreichbar, - Fragmentierung erforderlich, - Packet Too Big, - Time Exceeded, - Echo Request und Echo Reply, - Router- und Neighbor-Discovery-Funktionen bei IPv6. Eine zu weitgehende Blockierung kann zu schwer erkennbaren Fehlern führen: ```text Kleine Pakete funktionieren ↓ Größere Übertragungen bleiben hängen ↓ Erforderliche MTU-Fehlermeldung wird blockiert ↓ Path-MTU-Ermittlung funktioniert nicht richtig ``` Bei IPv6 sind bestimmte ICMPv6-Funktionen für den regulären Betrieb notwendig. „ICMP vollständig blockieren“ ist daher keine geeignete allgemeine Sicherheitsregel.
---
23. Typische Firewallfehler | Fehler | Wirkung | |---|---| | Falsches Windows-Profil | Regel ist vorhanden, aber nicht aktiv | | Falsche firewalld-Zone | Regel gilt nicht für die betroffene Schnittstelle | | TCP statt UDP freigegeben | Anwendung bleibt nicht erreichbar | | UDP statt TCP freigegeben | TCP-Verbindung schlägt weiterhin fehl | | Falscher lokaler oder entfernter Port | Regel passt nicht zum Datenfluss | | Zu enges Quellnetz | Bestimmte Clients funktionieren, andere nicht | | IPv4-Regel ohne IPv6-Entsprechung | Zugriff funktioniert nur über IPv4 | | Falscher Programmpfad | Anwendungsregel greift nach Update nicht mehr | | Erlaubnisregel unterhalb einer Blockierungsregel | Vorherige Regel entscheidet bereits | | Runtime- und permanente Regeln weichen ab | Fehler erscheint nach Reload oder Neustart | | Eingehend und ausgehend verwechselt | Falsche Richtung wurde freigegeben | | INPUT und FORWARD verwechselt | Router- oder Containerverkehr wird falsch bewertet | | Rückweg läuft über andere Firewall | Stateful Inspection kann Verbindung verwerfen | | Lokale und zentrale Richtlinie widersprechen sich | Erwartete lokale Regel ist nicht wirksam | | Containerport nicht veröffentlicht | Host-Firewallregel allein löst das Problem nicht | | Sicherheitssoftware zusätzlich aktiv | Native Firewallregeln erklären das Verhalten nicht vollständig |
---
24. Containerverkehr und Firewalls berücksichtigen Containerverkehr kann zusätzliche Regelketten, Bridges, NAT-Regeln und Weiterleitungen verwenden. ```text Client ↓ Host-Firewall ↓ veröffentlichter Hostport ↓ NAT oder Container-Proxy ↓ Container-Netzwerk ↓ Containerport ``` **Docker-Portzuordnungen prüfen:** ```bash [RO] docker ps --format 'table {{.Names}}\t{{.Ports}}' ``` **Portzuordnung eines Containers:** ```bash [RO] docker port CONTAINERNAME ``` **Docker-Netzwerke anzeigen:** ```bash [RO] docker network ls ``` **Konkretes Netzwerk untersuchen:** ```bash [RO][SENS] docker network inspect NETZWERKNAME ``` Zu prüfen sind: - Ist der Port überhaupt veröffentlicht? - Ist er nur an `127.0.0.1` gebunden? - Stimmen Hostport und Containerport? - Lauscht die Anwendung im Container? - Ist IP-Forwarding erforderlich und aktiv? - Wird der Verkehr durch die `FORWARD`-Kette verarbeitet? - Verwalten Docker und das Host-Firewallsystem gemeinsame Regeln? - Existiert ein Reverse Proxy vor dem Container? Firewallregeln, die von einer Containerplattform erzeugt wurden, dürfen nicht manuell verändert werden, ohne deren Verwaltungslogik und Auswirkungen zu berücksichtigen.
---
25. Sichere Gegenprobe ohne vollständiges Abschalten Eine Firewall vollständig zu deaktivieren ist keine bevorzugte Diagnosemethode. Bessere Gegenproben sind: 1. Regelzähler vor und nach einem einzelnen Test vergleichen. 2. Blockierungsprotokoll aktivieren, sofern genehmigt. 3. Gleichzeitig auf Client und Server mitschneiden. 4. Eine eng begrenzte temporäre Testregel beantragen. 5. Nur eine definierte Quelladresse erlauben. 6. Nur den benötigten Zielport und das richtige Protokoll erlauben. 7. Testzeitraum begrenzen. 8. Änderung und Rückbau dokumentieren. 9. Regel nach dem Test entfernen oder deaktivieren. 10. Anschließend den ursprünglichen Zustand bestätigen. **Beispiel für den Umfang einer genehmigten Testregel:** ```text Quelle: 192.0.2.25 Ziel: 192.0.2.53 Protokoll: TCP Zielport: 443 Richtung: eingehend Gültigkeit: nur während des Wartungsfensters Protokoll: aktiv ``` Die konkreten Änderungsbefehle werden erst nach Prüfung des vorhandenen Regelwerks, der Verwaltungsplattform und des genehmigten Sollzustands erstellt.
---
26. Warum die Firewall nicht einfach deaktiviert werden sollte Ein vollständiges Abschalten kann: - das System ungeschützt erreichbar machen, - gegen Unternehmensrichtlinien verstoßen, - andere Sicherheitsfunktionen beeinträchtigen, - den ursprünglichen Fehlerzustand verändern, - zentrale Richtlinien umgehen oder Konflikte erzeugen, - nicht beweisen, welche konkrete Regel verantwortlich war, - zusätzliche Verbindungen zulassen, die den Test verfälschen, - bei Remoteadministration zum Verbindungsabbruch führen. Microsoft empfiehlt ausdrücklich, die Windows-Firewall nicht einfach zu deaktivieren. Stattdessen sollen gezielte Regeln und Diagnosefunktionen verwendet werden. **Nicht als allgemeiner Diagnoseschritt verwenden:** ```text Windows-Firewall vollständig ausschalten firewalld stoppen ufw deaktivieren nftables-Regelwerk leeren iptables-Regeln leeren pf deaktivieren Sicherheitssoftware beenden ``` Diese Aktionen sind Änderungen mit potenziell weitreichenden Sicherheits- und Betriebsfolgen.
---
27. Systematischer Diagnoseablauf | Schritt | Prüfung | Leitfrage | |---:|---|---| | 1 | Datenfluss definieren | Welche Quelle muss welches Ziel über welches Protokoll und welchen Port erreichen? | | 2 | Fehler reproduzieren | Ist das Verhalten reproduzierbar und zeitlich dokumentiert? | | 3 | DNS und Zieladresse prüfen | Wird wirklich das erwartete System angesprochen? | | 4 | Routing prüfen | Verwendet das Paket den erwarteten Weg? | | 5 | Serverdienst prüfen | Läuft der Dienst und lauscht er richtig? | | 6 | Lokalen Test durchführen | Funktioniert der Dienst direkt auf dem Server? | | 7 | Firewallsystem identifizieren | Welches Werkzeug und welche Richtlinie sind tatsächlich aktiv? | | 8 | Profil, Zone oder Schnittstelle prüfen | Welcher Regelbereich gilt für den Verkehr? | | 9 | Passende Regeln suchen | Stimmen Richtung, Protokoll, Port, Adressen und Anwendung? | | 10 | Reihenfolge und Priorität prüfen | Entscheidet vorher bereits eine andere Regel? | | 11 | Zähler und Protokolle beobachten | Trifft der Testverkehr auf die vermutete Regel? | | 12 | Client- und Servermitschnitt vergleichen | An welcher Stelle verschwindet das Paket? | | 13 | Zentrale Filter prüfen | Gibt es ACL, VPN-, Cloud- oder Netzwerk-Firewalls? | | 14 | Eng begrenzte Änderung planen | Welche minimale Änderung stellt den Sollzustand her? | | 15 | Änderung genehmigen und dokumentieren | Wer hat Umfang und Zeitraum freigegeben? | | 16 | Nachprüfung durchführen | Funktioniert der Dienst und bleibt die Sicherheit erhalten? |
---
28. Kompakte Befehlstabelle | Aufgabe | Windows | Linux | macOS | |---|---|---|---| | Aktives Netzwerkprofil oder Zone | `[RO] Get-NetConnectionProfile` | firewalld: `[RO] firewall-cmd --get-active-zones` | Anwendungsfirewall besitzt keine direkt vergleichbaren Netzwerkprofile | | Firewallstatus | `[RO] Get-NetFirewallProfile` | firewalld: `[RO] firewall-cmd --state` | `[RO] /usr/libexec/ApplicationFirewall/socketfilterfw --getglobalstate` | | Aktive Regeln | `[RO][SENS] Get-NetFirewallRule -Enabled True` | nftables: `[RO][PRIV][SENS] sudo nft list ruleset` | pf: `[RO][PRIV][SENS] sudo pfctl -s rules` | | Blockierungsregeln | `[RO][SENS] Get-NetFirewallRule -Enabled True -Action Block` | Regelwerk nach `drop` beziehungsweise `reject` untersuchen | Anwendungsregeln: `[RO][PRIV][SENS] sudo /usr/libexec/ApplicationFirewall/socketfilterfw --listapps` | | TCP-Portregel suchen | `[RO] Get-NetFirewallPortFilter -Protocol TCP` | firewalld: `[RO] firewall-cmd --zone=ZONE --query-port=443/tcp` | pf-Regeln: `[RO][PRIV][SENS] sudo pfctl -vvs rules` | | UDP-Portregel suchen | `[RO] Get-NetFirewallPortFilter -Protocol UDP` | firewalld: `[RO] firewall-cmd --zone=ZONE --query-port=53/udp` | pf-Regeln: `[RO][PRIV][SENS] sudo pfctl -vvs rules` | | Firewallprofile ausführlich | `[RO] Get-NetFirewallProfile \| Format-List *` | Nicht direkt vergleichbar | `[RO] /usr/libexec/ApplicationFirewall/socketfilterfw --getblockall` | | iptables-Regeln | Nicht zutreffend | `[RO][PRIV][SENS] sudo iptables -L -n -v --line-numbers` | Nicht standardmäßig verwendet | | nftables-Regeln | Nicht zutreffend | `[RO][PRIV][SENS] sudo nft -a list ruleset` | Nicht zutreffend | | ufw-Status | Nicht zutreffend | `[RO][PRIV][SENS] sudo ufw status verbose` | Nicht zutreffend | | pf-Status | Nicht zutreffend | Nicht standardmäßig für alle Distributionen | `[RO][PRIV] sudo pfctl -s info` | | TCP-Porttest | `[TEST] Test-NetConnection HOST -Port 443` | `[TEST] nc -vz -w 5 HOST 443` | `[TEST] nc -vz -w 5 HOST 443` | | Paketmitschnitt | Dumpcap oder pktmon | `[TEST][PRIV][FILE][SENS] sudo tcpdump ...` | `[TEST][PRIV][FILE][SENS] sudo tcpdump ...` | `HOST`, `ZONE`, Schnittstellen, Adressen und Ports müssen durch die Werte des konkreten Störungsfalls ersetzt werden.
---
29. Dokumentationsvorlage für Firewallfehler ```text Störung: Zeitpunkt: Zeitzone: Betroffener Standort: Betroffener Benutzer oder Dienst: Clienthostname: Client-IP-Adresse: Client-VLAN: Client-Schnittstelle: Zielhostname: Ziel-IP-Adresse: Zielport: Transportprotokoll: Adressfamilie: IPv4 / IPv6 Erwartete Anwendung: Dienststatus: Lokaler Listener: Bind-Adresse: Lokaler Funktionstest: Entfernter Verbindungstest: Fehlermeldung: Aktive lokale Firewall: Aktives Profil beziehungsweise aktive Zone: Standardaktion eingehend: Standardaktion ausgehend: Vermutete Regel: Regelrichtung: Regelaktion: Quellbeschränkung: Zielbeschränkung: Portbedingung: Programmbedingung: Richtlinienquelle: Regelzähler vor dem Test: Regelzähler nach dem Test: Firewallprotokolleintrag: Paket am Client sichtbar: Paket am Server sichtbar: Antwort am Server sichtbar: Antwort am Client sichtbar: Zentrale Firewall oder ACL: NAT beteiligt: Container oder Reverse Proxy beteiligt: Festgestellte Ursache: Genehmigte Änderung: Rückfallplan: Ergebnis der Nachprüfung: ```
---
30. Kontrollfragen nach der Diagnose - Wurde der Datenfluss vollständig beschrieben? - Wurde zwischen eingehendem, ausgehendem und weitergeleitetem Verkehr unterschieden? - Wurde TCP, UDP, ICMP oder ICMPv6 korrekt bestimmt? - Wurde die tatsächlich verwendete Zieladresse dokumentiert? - Wurde geprüft, ob der Dienst lokal lauscht? - Wurde das aktive Windows-Profil beziehungsweise die aktive Linux-Zone ermittelt? - Wurde zwischen IPv4- und IPv6-Regeln unterschieden? - Wurden Adress-, Port-, Anwendungs- und Dienstfilter geprüft? - Wurde die Reihenfolge beziehungsweise Priorität der Regeln berücksichtigt? - Wurden zentrale Richtlinien und Drittanbieterprodukte berücksichtigt? - Wurde zwischen Runtime- und permanenter Konfiguration unterschieden? - Wurden Regelzähler während eines reproduzierbaren Tests beobachtet? - Wurden Client- und Servermitschnitt verglichen? - Wurde ein Timeout nicht automatisch als Firewallbeweis gewertet? - Wurde die Firewall nicht unnötig vollständig deaktiviert? - Wurde eine Änderung auf das erforderliche Minimum begrenzt? - Wurde der Sollzustand nach der Änderung erneut geprüft? - Wurde die Änderung einschließlich Rückfallplan dokumentiert?
---
31. Quellen und weiterführende Dokumentation - Microsoft Learn – Windows Firewall overview: https://learn.microsoft.com/windows/security/operating-system-security/network-security/windows-firewall/ - Microsoft Learn – Windows-Firewall über die Befehlszeile verwalten: https://learn.microsoft.com/de-de/windows/security/operating-system-security/network-security/windows-firewall/configure-with-command-line - Microsoft Learn – Get-NetFirewallProfile: https://learn.microsoft.com/powershell/module/netsecurity/get-netfirewallprofile - Microsoft Learn – Get-NetFirewallRule: https://learn.microsoft.com/powershell/module/netsecurity/get-netfirewallrule - Microsoft Learn – Get-NetFirewallPortFilter: https://learn.microsoft.com/powershell/module/netsecurity/get-netfirewallportfilter - Microsoft Learn – Get-NetFirewallAddressFilter: https://learn.microsoft.com/powershell/module/netsecurity/get-netfirewalladdressfilter - firewalld – Offizielle Dokumentation: https://firewalld.org/documentation/ - firewalld – Handbuch zu `firewall-cmd`: https://firewalld.org/documentation/man-pages/firewall-cmd - Netfilter – nftables Wiki: https://wiki.nftables.org/ - Netfilter – nftables-Regelwerk nachverfolgen: https://wiki.nftables.org/wiki-nftables/index.php/Ruleset_debug/tracing - Ubuntu – UFW-Dokumentation: https://documentation.ubuntu.com/server/how-to/security/firewalls/ - Linux-Handbuch – `iptables(8)`: https://man7.org/linux/man-pages/man8/iptables.8.html - Linux-Handbuch – `nft(8)`: https://man7.org/linux/man-pages/man8/nft.8.html - Apple – Firewall-Sicherheit bei macOS: https://support.apple.com/de-de/guide/security/seca0e83763f/web - Apple – Verbindungen auf dem Mac mit einer Firewall blockieren: https://support.apple.com/de-de/guide/mac-help/mh34041/mac - Wireshark – Benutzerhandbuch: https://www.wireshark.org/docs/wsug_html_chunked/
# 3.11 NAT- und Portweiterleitungsfehler analysieren Network Address Translation verändert IP-Adressen und teilweise auch Portnummern während der Übertragung. NAT wird unter anderem an Internetroutern, Firewalls, VPN-Gateways, Virtualisierungshosts und Containerplattformen eingesetzt. Eine Portweiterleitung kann korrekt eingetragen aussehen und trotzdem nicht funktionieren. Neben der eigentlichen NAT-Regel müssen Routing, Firewall, öffentlicher Anschluss, Rückweg und Zielanwendung geprüft werden. Die zentralen Fragen dieser Seite lauten: > Erreicht das Paket das NAT-System, wird es korrekt übersetzt und kann das Zielsystem über einen gültigen Rückweg antworten? ---
1. Sicherheits- und Aktionskennzeichnungen | Kennzeichnung | Bedeutung | |---|---| | `[RO]` | Rein lesender Befehl, der normalerweise keine Konfiguration verändert | | `[TEST]` | Aktiver Test, der Netzwerkverkehr erzeugt | | `[PRIV]` | Administrator- oder Root-Rechte können erforderlich sein | | `[FILE]` | Der Befehl schreibt Ausgaben in eine Datei | | `[SENS]` | Die Ausgabe kann sensible Informationen enthalten | | `[CHANGE]` | Der Befehl verändert eine Konfiguration | | `[DISRUPT]` | Der Befehl kann Verbindungen oder Dienste beeinträchtigen | NAT-Tabellen und Routerkonfigurationen können interne Adressen, öffentliche Adressen und erreichbare Dienste offenlegen. Ausgaben dürfen nicht ungeprüft veröffentlicht werden.
---
2. NAT-Grundbegriffe unterscheiden | Begriff | Bedeutung | |---|---| | NAT | Allgemeiner Begriff für die Übersetzung von Netzwerkadressen | | Source NAT – SNAT | Verändert die Quelladresse eines Pakets | | Destination NAT – DNAT | Verändert die Zieladresse eines Pakets | | PAT | Verändert zusätzlich Portnummern; mehrere Verbindungen können eine öffentliche Adresse teilen | | Masquerading | Dynamische Form von SNAT, häufig mit der Adresse der ausgehenden Schnittstelle | | Portweiterleitung | Eingehender Port wird an eine interne Adresse und gegebenenfalls einen anderen Port weitergeleitet | | Redirect | Verkehr wird auf das NAT-System selbst beziehungsweise einen lokalen Port umgeleitet | | Hairpin NAT | Interne Clients greifen über die öffentliche Adresse auf einen ebenfalls internen Dienst zu | | Static NAT | Feste Zuordnung zwischen Adressen | | Dynamic NAT | Dynamische Zuordnung aus einem Adresspool | | Double NAT | Zwei aufeinanderfolgende Systeme führen NAT durch | | CGNAT | Provider übersetzt mehrere Kundenanschlüsse hinter gemeinsamen öffentlichen Adressen | | NAT-Tabelle | Regel- oder Zustandsspeicher für Übersetzungen | | Conntrack | Zustandsverfolgung von Netzwerkverbindungen | **Wichtig:** Eine Portweiterleitung ist keine automatische Bestätigung, dass der Verkehr auch durch die Firewall erlaubt wird.
---
3. SNAT, DNAT und PAT am Beispiel **Ausgehende Verbindung mit SNAT beziehungsweise PAT:** ```text Interner Client 192.168.10.25:53144 ↓ Internetrouter ↓ Öffentliche Darstellung 203.0.113.10:62001 ↓ Webserver 198.51.100.20:443 ``` Der Webserver sieht als Quelle normalerweise die öffentliche Adresse des NAT-Systems und nicht unmittelbar die private Clientadresse. **Eingehende Portweiterleitung mit DNAT:** ```text Externer Client 198.51.100.25:54000 ↓ 203.0.113.10:8443 Öffentliche Routeradresse und externer Port ↓ DNAT 192.168.10.50:443 Interner Server und interner Port ``` Die vollständige Zuordnung lautet in diesem Beispiel: ```text TCP 203.0.113.10:8443 → TCP 192.168.10.50:443 ``` Diese Angaben müssen getrennt dokumentiert werden: - externe IP-Adresse, - externer Port, - Transportprotokoll, - interne Zieladresse, - interner Zielport, - erlaubte Quelladressen, - verwendete Schnittstelle, - zugehörige Firewallregel.
---
4. Private, öffentliche und gemeinsam genutzte Adressen erkennen **Private IPv4-Adressbereiche nach RFC 1918:** | 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` | **Shared Address Space für Carrier-Grade NAT:** ```text 100.64.0.0/10 ``` Das entspricht: ```text 100.64.0.0 bis 100.127.255.255 ``` **Weitere nicht öffentlich weiterleitbare Beispiele:** | Bereich | Verwendung | |---|---| | `127.0.0.0/8` | IPv4-Loopback | | `169.254.0.0/16` | IPv4-Link-Local | | `224.0.0.0/4` | IPv4-Multicast | | `::1/128` | IPv6-Loopback | | `fe80::/10` | IPv6-Link-Local | | `fc00::/7` | IPv6 Unique Local Addresses | Eine Adresse aus einem privaten oder CGNAT-Bereich auf der WAN-Seite des eigenen Routers ist ein deutlicher Hinweis darauf, dass noch ein vorgeschaltetes NAT-System existiert.
---
5. Häufige Ursachen einer fehlerhaften Portweiterleitung | Ursache | Typische Wirkung | |---|---| | Falsche öffentliche IP-Adresse | Test erreicht nicht den vorgesehenen Router | | Dynamische öffentliche Adresse hat sich geändert | Alter DNS-Eintrag oder alte Dokumentation zeigt auf falsches Ziel | | CGNAT beim Provider | Eingehende Verbindungen erreichen den Kundenrouter nicht direkt | | Double NAT | Weiterleitung existiert nur auf einem von zwei Routern | | Falsches Transportprotokoll | TCP wurde weitergeleitet, Dienst benötigt aber UDP oder umgekehrt | | Falscher externer Port | Client spricht einen anderen Port an | | Falscher interner Port | Weiterleitung endet nicht am Listener der Anwendung | | Falsche interne Zieladresse | Serveradresse wurde geändert oder per DHCP neu vergeben | | Dienst lauscht nur auf Loopback | NAT erreicht den Server, aber nicht den Dienst | | Dienst läuft nicht | Zielport ist geschlossen | | Host-Firewall blockiert | Paket erreicht das Zielsystem, wird dort aber verworfen | | Router-Firewall blockiert | DNAT-Regel allein reicht nicht aus | | Fehlender Rückweg | Antwort nimmt einen anderen oder ungültigen Weg | | Hairpin NAT fehlt | Interner Test über öffentliche Adresse schlägt fehl, externer Zugriff kann trotzdem funktionieren | | Quelladressbeschränkung | Nur bestimmte externe Netze dürfen zugreifen | | Falsche Schnittstelle | Regel gilt nicht für die tatsächliche WAN-Schnittstelle | | IPv4 und IPv6 verwechselt | IPv4-Portweiterleitung beeinflusst eine direkte IPv6-Verbindung nicht | | Mehrfach belegter externer Port | Regelkonflikt oder falsches Ziel | | VPN verändert den Pfad | Anfrage oder Antwort läuft über einen Tunnel | | Containerport nicht veröffentlicht | NAT endet am Host, aber nicht am Container |
---
6. Portweiterleitung vollständig dokumentieren Eine Beschreibung wie „Port 443 ist freigegeben“ ist nicht ausreichend. **Vollständige Beschreibung:** ```text Bezeichnung: Externer Webzugriff Adressfamilie: IPv4 WAN-Schnittstelle: WAN Quelladresse: beliebig oder definierter Bereich Öffentliche IP: 203.0.113.10 Transport: TCP Externer Port: 8443 Internes Ziel: 192.168.10.50 Interner Port: 443 Firewallaktion: Erlauben Protokollierung: Aktiviert Zeitplan: Dauerhaft ``` Zusätzlich sollte dokumentiert werden: - Hersteller und Modell des NAT-Systems, - Firmware- oder Betriebssystemversion, - zuständige Konfigurationsoberfläche, - Zeitpunkt der letzten Änderung, - genehmigender Verantwortlicher, - zugehörige DNS-Namen, - Rückfallplan, - Testergebnis von intern und extern.
---
7. Zuerst den internen Zieldienst prüfen Bevor NAT untersucht wird, muss der Dienst ohne Portweiterleitung direkt im internen Netz funktionieren. **Listener auf dem Zielsystem prüfen:** | Aufgabe | Windows | Linux | macOS | |---|---|---|---| | TCP-Listener | `[RO] Get-NetTCPConnection -State Listen` | `[RO] ss -ltn` | `[RO] lsof -nP -iTCP -sTCP:LISTEN` | | UDP-Endpunkte | `[RO] Get-NetUDPEndpoint` | `[RO] ss -lun` | `[RO] lsof -nP -iUDP` | | TCP-Port 443 | `[RO] Get-NetTCPConnection -State Listen -LocalPort 443` | `[RO] ss -ltn 'sport = :443'` | `[RO] lsof -nP -iTCP:443 -sTCP:LISTEN` | **Dienst direkt über seine interne Adresse testen:** Windows: ```powershell [TEST] Test-NetConnection 192.168.10.50 -Port 443 -InformationLevel Detailed ``` Linux und macOS: ```bash [TEST] nc -vz -w 5 192.168.10.50 443 ``` **Anwendungstest:** ```bash [TEST] curl -v https://192.168.10.50/ ``` Bei HTTPS kann ein Zertifikatsfehler auftreten, wenn das Zertifikat für einen Hostnamen und nicht für die IP-Adresse ausgestellt wurde. Für eine korrekte Anwendungsprüfung sollte möglichst der vorgesehene Hostname verwendet werden. **Entscheidung:** ```text Interner Zugriff funktioniert nicht ↓ Zuerst Dienst, Bind-Adresse, lokale Firewall und internes Routing prüfen ↓ NAT noch nicht als Hauptursache behandeln ```
---
8. Statische interne Zieladresse sicherstellen Eine Portweiterleitung verweist normalerweise auf eine konkrete interne IP-Adresse. Ändert sich diese Adresse durch DHCP, zeigt die Regel anschließend möglicherweise auf das falsche System. **Windows:** ```powershell [RO] Get-NetIPConfiguration ``` ```powershell [RO] Get-NetIPAddress -AddressFamily IPv4 | Format-Table InterfaceAlias, IPAddress, PrefixLength, PrefixOrigin ``` **Linux:** ```bash [RO] ip -br address ``` ```bash [RO] ip address show ``` **macOS:** ```bash [RO] ifconfig ``` ```bash [RO] networksetup -listallhardwareports ``` Zu prüfen sind: - Stimmt die aktuelle Serveradresse mit dem NAT-Ziel überein? - Ist die Adresse statisch konfiguriert? - Existiert eine DHCP-Reservierung? - Liegt eine doppelte IP-Adresse vor? - Wurde der Server in ein anderes VLAN verschoben? - Stimmt das Präfix beziehungsweise die Subnetzmaske? - Ist das Standardgateway korrekt? Eine statische Adresse außerhalb des verwalteten Adressplans kann ebenfalls zu Konflikten führen. Bevorzugt wird eine dokumentierte statische Zuweisung oder DHCP-Reservierung entsprechend der Unternehmensvorgaben.
---
9. Öffentliche Adresse des Anschlusses bestimmen Zuerst wird die WAN-Adresse direkt in der Verwaltungsoberfläche des Routers oder der Firewall abgelesen. Anschließend kann sie mit der von einem externen Dienst erkannten Adresse verglichen werden. **Lokale Adressen anzeigen:** Windows: ```powershell [RO] Get-NetIPAddress | Format-Table InterfaceAlias, AddressFamily, IPAddress, PrefixLength ``` Linux: ```bash [RO] ip -br address ``` macOS: ```bash [RO] ifconfig ``` Lokale Befehle zeigen auf einem Client hinter NAT normalerweise nicht die öffentliche IPv4-Adresse des Internetanschlusses. **Öffentlich sichtbare IPv4-Adresse über einen externen Dienst abfragen:** Windows: ```powershell [TEST][SENS] Invoke-RestMethod -Uri "https://api.ipify.org" ``` Linux und macOS: ```bash [TEST][SENS] curl -4 https://api.ipify.org ``` **Öffentlich sichtbare IPv6-Adresse:** ```bash [TEST][SENS] curl -6 https://api64.ipify.org ``` Dabei wird die öffentliche Quelladresse an einen externen Dienst übertragen. Die Nutzung muss durch die betrieblichen Richtlinien erlaubt sein. **Auswertung:** | Vergleich | Mögliche Bedeutung | |---|---| | Router-WAN-Adresse entspricht externer IPv4-Adresse | Router besitzt wahrscheinlich direkt diese öffentliche IPv4-Adresse | | Router-WAN-Adresse ist privat | Vorgeschalteter Router oder Provider-NAT vorhanden | | Router-WAN-Adresse liegt in `100.64.0.0/10` | CGNAT ist wahrscheinlich | | Router-WAN-Adresse und erkannte öffentliche Adresse unterscheiden sich | Weiteres NAT-System oder Proxy vorhanden | | Keine öffentliche IPv4-Adresse vorhanden | Anschluss kann IPv6, DS-Lite oder andere Providertechnik verwenden | Die genaue Anschlussart muss anhand der Router- und Providerinformationen bestätigt werden.
---
10. CGNAT, DS-Lite und Double NAT erkennen **Double NAT:** ```text Internet ↓ Router oder Modemrouter 1 ↓ privates Netz Router 2 ↓ privates Netz Interner Server ``` Für eine klassische eingehende IPv4-Verbindung kann eine Weiterleitung auf beiden NAT-Systemen erforderlich sein. **Carrier-Grade NAT:** ```text Internet ↓ Öffentliche Provideradresse ↓ Provider-NAT ↓ Kundenrouter mit Adresse aus 100.64.0.0/10 ``` Eine Portweiterleitung auf dem Kundenrouter kann das vorgeschaltete Provider-NAT nicht automatisch konfigurieren. **DS-Lite:** Bei DS-Lite wird IPv4-Verkehr über eine Providerinfrastruktur transportiert und typischerweise auf Providerseite übersetzt. Eine frei erreichbare öffentliche IPv4-Adresse steht dem eigenen Router dabei häufig nicht direkt zur Verfügung. **Prüfschritte:** 1. WAN-Adresse des Routers ablesen. 2. Extern erkannte IPv4-Adresse abfragen. 3. Adressen miteinander vergleichen. 4. Prüfen, ob die WAN-Adresse privat oder aus `100.64.0.0/10` ist. 5. Anschlussinformationen des Providers kontrollieren. 6. Prüfen, ob eine öffentliche IPv4-Adresse gebucht oder verfügbar ist. 7. Alternativen wie IPv6, VPN, Reverse Tunnel oder Providerfreigabe nur nach Sicherheitsprüfung planen.
---
11. Portweiterleitung wirklich von außen testen Ein Test aus demselben LAN über die öffentliche Adresse ist kein zuverlässiger Ersatz für einen externen Test. Er hängt von der Unterstützung für Hairpin NAT ab. Geeignete externe Testquellen sind beispielsweise: - freigegebener Administrationsanschluss an einem anderen Standort, - Mobilfunkverbindung ohne Verbindung zum Firmen-WLAN, - freigegebener externer Monitoring-Server, - autorisiertes System in einem anderen Netz, - definierter Prüfserver in einer Cloudumgebung. **Externer TCP-Test unter Windows:** ```powershell [TEST] Test-NetConnection 203.0.113.10 -Port 8443 -InformationLevel Detailed ``` **Externer TCP-Test unter Linux oder macOS:** ```bash [TEST] nc -vz -w 5 203.0.113.10 8443 ``` **Anwendungstest mit Hostname:** ```bash [TEST] curl -v https://service.example.net:8443/ ``` **Gezielter Nmap-Test:** ```bash [TEST] nmap -sT -p 8443 203.0.113.10 ``` Tests dürfen nur gegen die eigene beziehungsweise ausdrücklich freigegebene Infrastruktur ausgeführt werden.
---
12. Hairpin NAT richtig beurteilen Hairpin NAT wird benötigt, wenn ein interner Client über die öffentliche Adresse oder den öffentlichen DNS-Namen auf einen internen Server zugreift. ```text Interner Client ↓ öffentliche Adresse des eigenen Routers ↓ Portweiterleitung ↓ interner Server im gleichen Standort ``` **Typisches Fehlerbild:** ```text Zugriff über Mobilfunk funktioniert Zugriff aus dem internen LAN über öffentliche Adresse funktioniert nicht Direkter Zugriff über interne Adresse funktioniert ``` Das deutet auf fehlendes oder fehlerhaftes Hairpin NAT hin. Es beweist nicht, dass die allgemeine externe Portweiterleitung defekt ist. **Mögliche Lösungen abhängig von der Infrastruktur:** - Hairpin NAT korrekt konfigurieren, - internes und externes DNS unterschiedlich beantworten, - internen Clients die interne Serveradresse liefern, - Reverse Proxy mit passender interner Erreichbarkeit verwenden. Änderungen an DNS oder NAT müssen zum vorgesehenen Netzdesign passen.
---
13. Split DNS als Alternative zu Hairpin NAT erkennen Bei Split DNS kann derselbe Hostname intern und extern unterschiedliche Antworten liefern. **Extern:** ```text service.example.net → 203.0.113.10 ``` **Intern:** ```text service.example.net → 192.168.10.50 ``` **DNS-Antwort prüfen:** Windows: ```powershell [TEST] Resolve-DnsName service.example.net -Type A ``` Linux und macOS: ```bash [TEST] dig service.example.net A ``` **Bestimmten internen DNS-Server abfragen:** ```bash [TEST] dig @192.168.10.53 service.example.net A ``` **Bestimmten externen DNS-Server abfragen:** ```bash [TEST] dig @1.1.1.1 service.example.net A ``` Die Verwendung öffentlicher DNS-Server muss durch die Netz- und Datenschutzrichtlinien erlaubt sein. Unternehmensinterne Namen dürfen nicht unnötig an externe Resolver übermittelt werden. Zu prüfen sind: - Welche Antwort erhält ein interner Client? - Welche Antwort erhält ein externer Client? - Sind TTL und Cache berücksichtigt? - Verweist der interne Datensatz auf den richtigen Server? - Passt das TLS-Zertifikat weiterhin zum Hostnamen?
---
14. Windows-NAT-Konfiguration prüfen Die folgenden Befehle betreffen Windows-NAT-Konfigurationen, die über das NetNat-Modul verwaltet werden, beispielsweise in bestimmten Hyper-V- oder Windows-Container-Szenarien. Sie zeigen nicht automatisch die NAT-Regeln eines externen Routers an. **Vorhandene Windows-NAT-Objekte anzeigen:** ```powershell [RO][PRIV][SENS] Get-NetNat ``` **Ausführliche Anzeige:** ```powershell [RO][PRIV][SENS] Get-NetNat | Format-List * ``` **Statische Zuordnungen anzeigen:** ```powershell [RO][PRIV][SENS] Get-NetNatStaticMapping ``` **NAT-Sitzungen anzeigen:** ```powershell [RO][PRIV][SENS] Get-NetNatSession ``` **Interne Hyper-V-Switches prüfen, sofern Hyper-V eingesetzt wird:** ```powershell [RO][PRIV] Get-VMSwitch ``` **IP-Adressen der virtuellen Schnittstellen:** ```powershell [RO] Get-NetIPAddress | Where-Object InterfaceAlias -Like "vEthernet*" | Format-Table InterfaceAlias, AddressFamily, IPAddress, PrefixLength ``` Zu prüfen sind: - Existiert das erwartete NAT-Objekt? - Stimmt das interne Adresspräfix? - Existiert die erwartete statische Portzuordnung? - Stimmen externes und internes Protokoll? - Stimmen externe und interne Ports? - Stimmt die interne Zieladresse? - Existiert eine passende Firewallregel? - Besteht ein Konflikt mit Container- oder Virtualisierungssoftware? **Keine NAT-Objekte löschen oder neu erstellen, solange der Sollzustand und die Auswirkungen nicht vollständig geklärt sind.**
---
15. Linux-NAT mit nftables prüfen **Gesamtes nftables-Regelwerk anzeigen:** ```bash [RO][PRIV][SENS] sudo nft list ruleset ``` **Tabellen anzeigen:** ```bash [RO][PRIV] sudo nft list tables ``` **Regelwerk einschließlich Handles anzeigen:** ```bash [RO][PRIV][SENS] sudo nft -a list ruleset ``` Bei NAT-Regeln sind insbesondere folgende Hooks relevant: | Hook | Typische Verwendung | |---|---| | `prerouting` | DNAT eingehender Pakete vor der Routingentscheidung | | `output` | DNAT lokal erzeugter Pakete | | `postrouting` | SNAT oder Masquerading nach der Routingentscheidung | | `input` | Bestimmte SNAT-Sonderfälle für lokal zugestellte Pakete | **Typische nftables-Ausdrücke erkennen:** ```text dnat to 192.168.10.50:443 snat to 203.0.113.10 masquerade redirect to :8080 ``` **Regeln mit Zählern untersuchen:** ```bash [RO][PRIV][SENS] sudo nft -a list ruleset ``` Zu prüfen ist, ob die Paket- und Bytezähler der erwarteten NAT- und Filterregeln während eines einzelnen Tests steigen. **Wichtig:** NAT-Anweisungen sind an NAT-Chains und die dafür vorgesehenen Hooks gebunden. Eine sichtbare Regel beweist nicht, dass das Paket den dazugehörigen Pfad tatsächlich durchläuft.
---
16. Linux-NAT mit iptables prüfen **NAT-Tabelle mit Zählern und Zeilennummern:** ```bash [RO][PRIV][SENS] sudo iptables -t nat -L -n -v --line-numbers ``` **NAT-Regeln in Befehlsschreibweise:** ```bash [RO][PRIV][SENS] sudo iptables -t nat -S ``` **IPv6-NAT-Regeln, sofern in der Umgebung verwendet:** ```bash [RO][PRIV][SENS] sudo ip6tables -t nat -L -n -v --line-numbers ``` **Filterregeln für weitergeleiteten Verkehr:** ```bash [RO][PRIV][SENS] sudo iptables -L FORWARD -n -v --line-numbers ``` **Typische Ziele:** | Ziel | Bedeutung | |---|---| | `DNAT` | Zieladresse oder Zielport verändern | | `SNAT` | Quelladresse oder Quellport verändern | | `MASQUERADE` | Dynamische Quelladressübersetzung | | `REDIRECT` | Verkehr an das lokale System umleiten | | `ACCEPT` | Verkehr zulassen | | `DROP` | Verkehr ohne Antwort verwerfen | | `REJECT` | Verkehr aktiv ablehnen | Eine passende DNAT-Regel allein reicht nicht aus. Weitergeleiteter Verkehr muss zusätzlich durch die Filterregeln zugelassen und korrekt geroutet werden.
---
17. IP-Forwarding prüfen Ein Linux-System, das Pakete zwischen Schnittstellen weiterleiten soll, benötigt eine passende Forwarding-Konfiguration. **IPv4-Forwarding:** ```bash [RO] sysctl net.ipv4.ip_forward ``` Alternative Anzeige: ```bash [RO] cat /proc/sys/net/ipv4/ip_forward ``` Typische Werte: | Wert | Bedeutung | |---:|---| | `0` | IPv4-Weiterleitung deaktiviert | | `1` | IPv4-Weiterleitung aktiviert | **IPv6-Forwarding:** ```bash [RO] sysctl net.ipv6.conf.all.forwarding ``` Die Aktivierung von Forwarding ist eine Konfigurationsänderung und darf nicht automatisch vorgenommen werden. Zuerst muss geklärt werden, ob das System laut Netzdesign als Router arbeiten soll. **Zusätzlich prüfen:** ```bash [RO] ip route show [RO] ip -6 route show ``` NAT ersetzt keine gültige Routingkonfiguration.
---
18. macOS-NAT- und pf-Regeln prüfen macOS kann NAT und Weiterleitung über den Packet Filter `pf` beziehungsweise durch Anwendungen und Systemdienste umsetzen. **pf-Status:** ```bash [RO][PRIV] sudo pfctl -s info ``` **NAT-Regeln anzeigen:** ```bash [RO][PRIV][SENS] sudo pfctl -s nat ``` **Filterregeln anzeigen:** ```bash [RO][PRIV][SENS] sudo pfctl -s rules ``` **Zustände anzeigen:** ```bash [RO][PRIV][SENS] sudo pfctl -s states ``` **Regeln mit zusätzlichen Informationen und Zählern:** ```bash [RO][PRIV][SENS] sudo pfctl -vvs nat ``` ```bash [RO][PRIV][SENS] sudo pfctl -vvs rules ``` **Routingtabelle prüfen:** ```bash [RO] netstat -rn ``` **IPv4-Forwardingstatus:** ```bash [RO] sysctl net.inet.ip.forwarding ``` Zu beachten ist, dass VPN-, Virtualisierungs-, Container- und Sicherheitssoftware eigene `pf`-Anchors oder Regeln verwenden kann. Das Regelwerk darf nicht ohne Kenntnis dieser Abhängigkeiten neu geladen oder geleert werden.
---
19. Connection Tracking und NAT-Zustände prüfen NAT ist normalerweise zustandsorientiert. Das System merkt sich, wie eine Verbindung übersetzt wurde, damit Antwortpakete korrekt zurückübersetzt werden können. **Linux – prüfen, ob conntrack vorhanden ist:** ```bash [RO] command -v conntrack ``` **Alle Verbindungseinträge anzeigen:** ```bash [RO][PRIV][SENS] sudo conntrack -L ``` **TCP-Verbindungen zu einem Zielport filtern:** ```bash [RO][PRIV][SENS] sudo conntrack -L -p tcp --dport 443 ``` **UDP-Verbindungen zu einem Zielport filtern:** ```bash [RO][PRIV][SENS] sudo conntrack -L -p udp --dport 53 ``` Je nach Übersetzungsrichtung können in einem Eintrag ursprüngliche und übersetzte Adressen erscheinen. Zu kontrollieren sind: - Wird beim Test ein Zustandseintrag erzeugt? - Stimmen ursprüngliches und übersetztes Ziel? - Ist Antwortverkehr sichtbar? - Läuft der Eintrag frühzeitig ab? - Gibt es sehr viele Verbindungseinträge? - Ist nur eine Richtung sichtbar? Zustandstabellen dürfen nicht unkontrolliert geleert werden. Dadurch können bestehende Verbindungen unterbrochen werden.
---
20. Rückweg und asymmetrisches Routing prüfen Nach DNAT erreicht ein Paket möglicherweise den internen Server. Der Server muss jedoch über einen gültigen Weg antworten. **Sollzustand:** ```text Externer Client ↓ NAT-Gateway ↓ Interner Server ↓ NAT-Gateway ↓ Externer Client ``` **Problematischer asymmetrischer Rückweg:** ```text Anfrage: Client → NAT-Gateway A → Server Antwort: Server → Gateway B → Client ``` Das NAT-Gateway A sieht die Antwort nicht und kann die notwendige Rückübersetzung nicht durchführen. **Standardgateway des Zielservers prüfen:** Windows: ```powershell [RO] Get-NetRoute -DestinationPrefix "0.0.0.0/0" | Sort-Object RouteMetric | Format-Table InterfaceAlias, NextHop, RouteMetric ``` Linux: ```bash [RO] ip route show default ``` macOS: ```bash [RO] route -n get default ``` **Route zu einer externen Testadresse prüfen:** Windows: ```powershell [RO] Find-NetRoute -RemoteIPAddress 198.51.100.25 ``` Linux: ```bash [RO] ip route get 198.51.100.25 ``` macOS: ```bash [RO] route -n get 198.51.100.25 ``` Die Beispieladresse muss durch die tatsächliche Adresse des autorisierten Testsystems ersetzt werden.
---
21. Paketmitschnitt vor und nach der Übersetzung erstellen Idealerweise wird auf beiden Seiten des NAT-Systems gleichzeitig mitgeschnitten. ```text WAN-Mitschnitt: Ziel 203.0.113.10:8443 LAN-Mitschnitt: Ziel 192.168.10.50:443 ``` **Linux – WAN-Schnittstelle:** ```bash [TEST][PRIV][FILE][SENS] sudo tcpdump -i WAN_INTERFACE -nn \ 'tcp port 8443' \ -w nat-wan.pcap ``` **Linux – LAN-Schnittstelle:** ```bash [TEST][PRIV][FILE][SENS] sudo tcpdump -i LAN_INTERFACE -nn \ 'host 192.168.10.50 and tcp port 443' \ -w nat-lan.pcap ``` **macOS:** ```bash [TEST][PRIV][FILE][SENS] sudo tcpdump -i INTERFACE -nn \ 'tcp port 8443 or tcp port 443' \ -w nat-test.pcap ``` **Windows mit Dumpcap – Schnittstellen ermitteln:** ```powershell [RO] dumpcap -D ``` **Mitschnitt auf einer bestimmten Schnittstelle:** ```powershell [TEST][PRIV][FILE][SENS] dumpcap -i 1 ` -f "tcp port 8443 or tcp port 443" ` -w nat-test.pcapng ``` `WAN_INTERFACE`, `LAN_INTERFACE`, `INTERFACE` und die Dumpcap-Schnittstellennummer müssen vorher ermittelt werden.
---
22. Paketmuster bei NAT-Fehlern interpretieren | WAN-Seite | LAN-Seite | Mögliche Interpretation | |---|---|---| | Kein Paket sichtbar | Kein Paket sichtbar | Falsche öffentliche Adresse, CGNAT, vorgeschalteter Filter oder Clientproblem | | SYN sichtbar | Kein weitergeleitetes SYN | DNAT-Regel, Firewall oder Routing auf dem NAT-System prüfen | | SYN an externen Port sichtbar | SYN an richtiges internes Ziel sichtbar | Übersetzung funktioniert grundsätzlich | | SYN erreicht internen Server | Kein SYN-ACK vom Server | Dienst, Bind-Adresse, Host-Firewall oder Serverrouting prüfen | | SYN-ACK verlässt Server | Keine Antwort auf WAN-Seite | NAT-Zustand, Forwarding, Filter oder Rückweg prüfen | | Vollständiger Handshake auf beiden Seiten | Anwendung schlägt dennoch fehl | Fehler wahrscheinlich oberhalb der Transportschicht | | RST kommt vom internen Server | Ziel erreichbar, aber Port wird nicht angenommen | | ICMP-Fehler sichtbar | Abhängig vom Fehlercode | Routing-, Filter- oder Erreichbarkeitsproblem weiter untersuchen | **Wichtig:** Ein Mitschnitt auf nur einer Schnittstelle zeigt nicht den gesamten Übersetzungsvorgang.
---
23. Docker-Portweiterleitungen prüfen Docker verwendet bei Bridge-Netzwerken Port Publishing, NAT beziehungsweise Firewallregeln, um Hostports an Containerports weiterzuleiten. **Container und Portzuordnungen anzeigen:** ```bash [RO] docker ps --format 'table {{.Names}}\t{{.Ports}}' ``` **Portzuordnung eines bestimmten Containers:** ```bash [RO] docker port CONTAINERNAME ``` **Containerkonfiguration prüfen:** ```bash [RO][SENS] docker inspect CONTAINERNAME ``` **Docker-Netzwerke anzeigen:** ```bash [RO] docker network ls ``` **Netzwerk untersuchen:** ```bash [RO][SENS] docker network inspect NETZWERKNAME ``` **Beispiele:** ```text 0.0.0.0:8080->80/tcp ``` Der Hostport `8080/TCP` wurde an den Containerport `80/TCP` veröffentlicht und ist an den passenden IPv4-Adressen des Hosts gebunden. ```text 127.0.0.1:8080->80/tcp ``` Der Hostport ist an die Loopback-Adresse gebunden und normalerweise nur vom Docker-Host erreichbar. ```text 8080->80/tcp ``` Die genaue Bindung muss über die vollständige Docker-Ausgabe beziehungsweise `docker inspect` geprüft werden. **Wichtig:** ```dockerfile EXPOSE 80 ``` `EXPOSE` dokumentiert den vorgesehenen Containerport, veröffentlicht ihn aber nicht automatisch auf dem Host.
---
24. Docker-NAT systematisch testen **Ebene 1 – Anwendung im Container** ```bash [RO] docker ps ``` ```bash [RO][SENS] docker logs --tail 100 CONTAINERNAME ``` **Ebene 2 – Portzuordnung** ```bash [RO] docker port CONTAINERNAME ``` **Ebene 3 – Zugriff vom Docker-Host** ```bash [TEST] curl -v http://127.0.0.1:8080/ ``` **Ebene 4 – Zugriff über die LAN-Adresse des Hosts** ```bash [TEST] curl -v http://HOST_LAN_IP:8080/ ``` **Ebene 5 – Zugriff aus einem anderen LAN-System** ```bash [TEST] nc -vz -w 5 HOST_LAN_IP 8080 ``` **Ebene 6 – Zugriff über eine externe Routerweiterleitung** ```bash [TEST] nc -vz -w 5 OEFFENTLICHE_IP EXTERNER_PORT ``` Der letzte Test muss wirklich aus einem externen Netz erfolgen, sofern Hairpin NAT nicht ausdrücklich mitgeprüft werden soll.
---
25. IPv4-NAT und IPv6-Zugriff nicht verwechseln Bei IPv4 wird NAT häufig eingesetzt, weil private Adressen nicht direkt aus dem Internet erreichbar sind. Bei IPv6 besitzt ein System häufig eine global routbare Adresse. Eine klassische IPv4-Portweiterleitung ist dann nicht automatisch beteiligt. Der Zugriff wird stattdessen insbesondere durch folgende Komponenten bestimmt: - IPv6-Adressierung, - IPv6-Routing, - IPv6-Firewall, - DNS-AAAA-Eintrag, - Dienstbindung an IPv6, - Provider- und Routerrichtlinien. **DNS-Einträge prüfen:** Windows: ```powershell [TEST] Resolve-DnsName service.example.net -Type A [TEST] Resolve-DnsName service.example.net -Type AAAA ``` Linux und macOS: ```bash [TEST] dig service.example.net A [TEST] dig service.example.net AAAA ``` **HTTPS getrennt testen:** ```bash [TEST] curl -4 -v https://service.example.net/ [TEST] curl -6 -v https://service.example.net/ ``` **Typischer Fehler:** ```text IPv4-Portweiterleitung ist korrekt ↓ Client bevorzugt jedoch den vorhandenen AAAA-Eintrag ↓ Verbindung erfolgt über IPv6 ↓ IPv6-Firewall oder IPv6-Dienstbindung ist fehlerhaft ```
---
26. Dynamisches DNS prüfen Bei wechselnden öffentlichen Adressen wird häufig Dynamic DNS verwendet. Zu prüfen sind: - Welche öffentliche Adresse besitzt der Anschluss aktuell? - Welche Adresse liefert der DNS-Eintrag? - Wann wurde der Eintrag zuletzt aktualisiert? - Wie hoch ist die TTL? - Funktioniert der Update-Client? - Wird IPv4, IPv6 oder beides aktualisiert? - Existiert ein alter A- oder AAAA-Eintrag? **DNS-Eintrag prüfen:** Windows: ```powershell [TEST] Resolve-DnsName service.example.net ``` Linux und macOS: ```bash [TEST] dig service.example.net A [TEST] dig service.example.net AAAA ``` **Autoritativen Nameserver ermitteln:** ```bash [TEST] dig service.example.net NS ``` **Antwort eines bestimmten autoritativen Servers abfragen:** ```bash [TEST] dig @AUTORITATIVER_DNS_SERVER service.example.net A ``` Ein veralteter lokaler Cache kann sich von der bereits aktualisierten autoritativen Antwort unterscheiden.
---
27. NAT-Loopback, Proxy und Reverse Proxy auseinanderhalten Ein öffentlich erreichbarer Dienst kann über mehrere Weiterleitungsstufen verfügen: ```text Internet ↓ Router-DNAT ↓ Reverse Proxy ↓ Container-Port ↓ Anwendung ``` Jede Ebene benötigt eine eigene Prüfung. | Ebene | Prüffrage | |---|---| | Router-DNAT | Wird der externe Port an das richtige interne System weitergeleitet? | | Host-Firewall | Darf der Verkehr den Reverse Proxy erreichen? | | Reverse Proxy | Existiert die richtige Host- und Zielkonfiguration? | | Container Publishing | Ist der Hostport an den Containerport gebunden? | | Anwendung | Lauscht die Anwendung und verarbeitet sie die Anfrage? | | DNS | Zeigt der Hostname auf die erwartete öffentliche Adresse? | | TLS | Stimmt Zertifikat, Hostname und SNI? | Ein funktionierender Router-DNAT beweist nicht, dass der Reverse Proxy oder das Backend funktioniert.
---
28. Keine unkontrollierte Exposition interner Dienste Eine Portweiterleitung macht einen Dienst potenziell aus externen Netzen erreichbar. Vor einer Freigabe müssen mindestens geprüft werden: - Ist die externe Erreichbarkeit wirklich erforderlich? - Unterstützt der Dienst eine sichere Authentifizierung? - Wird eine verschlüsselte Verbindung verwendet? - Ist die Software aktuell? - Ist der Zugriff auf erforderliche Quelladressen beschränkbar? - Kann stattdessen ein VPN oder Zero-Trust-Zugang verwendet werden? - Existiert eine Protokollierung und Überwachung? - Gibt es Schutz vor Brute-Force-Angriffen? - Ist der Dienst für eine Veröffentlichung vorgesehen? - Enthält der Dienst eine administrative Oberfläche? - Ist ein Reverse Proxy mit zusätzlicher Zugriffskontrolle sinnvoll? - Existiert ein dokumentierter Rückbauplan? Besonders Datenbanken, interne Verwaltungsoberflächen, Dateifreigaben und unverschlüsselte Protokolle sollten nicht unkontrolliert direkt veröffentlicht werden. **Keine automatische oder pauschale Portfreigabe über UPnP voraussetzen.** Dynamisch erstellte Weiterleitungen müssen ebenso geprüft und dokumentiert werden.
---
29. Änderungen nur kontrolliert durchführen Nicht vorschnell: - NAT-Tabellen leeren, - Conntrack-Zustände löschen, - Router auf Werkseinstellungen zurücksetzen, - Firewall vollständig deaktivieren, - alle Quelladressen freigeben, - DMZ- beziehungsweise Exposed-Host-Funktionen aktivieren, - mehrere Weiterleitungen für denselben Port erstellen, - interne Server direkt und ungeschützt veröffentlichen, - IPv6-Firewall deaktivieren, - Docker-Regeln manuell überschreiben. **Sicherer Änderungsablauf:** 1. Istzustand exportieren oder dokumentieren. 2. Gewünschten Datenfluss vollständig definieren. 3. Bestehende Regeln und Abhängigkeiten prüfen. 4. Änderung genehmigen lassen. 5. Eng begrenzte Regel erstellen. 6. Protokollierung aktivieren, soweit vorgesehen. 7. Von intern und extern testen. 8. Sicherheitsprüfung durchführen. 9. Ergebnis dokumentieren. 10. Bei Misserfolg den vorherigen Zustand wiederherstellen.
---
30. Systematischer Diagnoseablauf | Schritt | Prüfung | Leitfrage | |---:|---|---| | 1 | Datenfluss dokumentieren | Welche externe Adresse und welcher Port sollen wohin übersetzt werden? | | 2 | Zielanwendung prüfen | Läuft der interne Dienst? | | 3 | Listener prüfen | Lauscht der Dienst auf Adresse, Port und Protokoll? | | 4 | Internen Zugriff testen | Funktioniert der Dienst ohne NAT? | | 5 | Interne Zieladresse prüfen | Stimmt die NAT-Regel noch mit der Serveradresse überein? | | 6 | WAN-Adresse prüfen | Besitzt der Router die erwartete öffentliche Adresse? | | 7 | CGNAT oder Double NAT prüfen | Existiert ein vorgeschaltetes NAT-System? | | 8 | DNS prüfen | Zeigt der Hostname auf die aktuelle öffentliche Adresse? | | 9 | NAT-Regel prüfen | Stimmen Protokoll, externe und interne Ports sowie Zieladresse? | | 10 | Firewallregeln prüfen | Wird der übersetzte Verkehr zugelassen? | | 11 | Forwarding prüfen | Darf das System Pakete zwischen Schnittstellen weiterleiten? | | 12 | Rückweg prüfen | Antwortet der Server über das NAT-Gateway? | | 13 | Extern testen | Erreicht ein Client außerhalb des LANs den Port? | | 14 | Hairpin NAT getrennt testen | Betrifft der Fehler nur interne Clients? | | 15 | Paketmitschnitt auf beiden Seiten | Wird das Paket korrekt übersetzt? | | 16 | NAT- und Regelzähler prüfen | Trifft der Test die erwartete Regel? | | 17 | Container oder Proxy prüfen | Existieren weitere Weiterleitungsstufen? | | 18 | Änderung minimal planen | Welche kleinste genehmigte Korrektur behebt die Ursache? | | 19 | Nachprüfung | Funktioniert der Dienst intern und extern? | | 20 | Dokumentation | Sind Regel, Risiko und Rückfallplan festgehalten? |
---
31. Kompakte Befehlstabelle | Aufgabe | Windows | Linux | macOS | |---|---|---|---| | Lokale IP-Adressen | `[RO] Get-NetIPAddress` | `[RO] ip -br address` | `[RO] ifconfig` | | Standardgateway | `[RO] Get-NetRoute -DestinationPrefix "0.0.0.0/0"` | `[RO] ip route show default` | `[RO] route -n get default` | | Route zu einem Ziel | `[RO] Find-NetRoute -RemoteIPAddress IP` | `[RO] ip route get IP` | `[RO] route -n get IP` | | TCP-Listener | `[RO] Get-NetTCPConnection -State Listen` | `[RO] ss -ltn` | `[RO] lsof -nP -iTCP -sTCP:LISTEN` | | Internen TCP-Port testen | `[TEST] Test-NetConnection IP -Port PORT` | `[TEST] nc -vz -w 5 IP PORT` | `[TEST] nc -vz -w 5 IP PORT` | | Windows-NAT anzeigen | `[RO][PRIV][SENS] Get-NetNat` | Nicht zutreffend | Nicht zutreffend | | Statische Windows-NAT-Zuordnungen | `[RO][PRIV][SENS] Get-NetNatStaticMapping` | Nicht zutreffend | Nicht zutreffend | | nftables-Regeln | Nicht zutreffend | `[RO][PRIV][SENS] sudo nft -a list ruleset` | Nicht zutreffend | | iptables-NAT | Nicht zutreffend | `[RO][PRIV][SENS] sudo iptables -t nat -L -n -v --line-numbers` | Nicht zutreffend | | pf-NAT | Nicht zutreffend | Nicht standardmäßig allgemein vorhanden | `[RO][PRIV][SENS] sudo pfctl -vvs nat` | | IPv4-Forwarding | Abhängig von Windows-Rolle | `[RO] sysctl net.ipv4.ip_forward` | `[RO] sysctl net.inet.ip.forwarding` | | Conntrack | Abhängig von Windows-NAT | `[RO][PRIV][SENS] sudo conntrack -L` | pf: `[RO][PRIV][SENS] sudo pfctl -s states` | | Docker-Portzuordnung | `[RO] docker port CONTAINER` | `[RO] docker port CONTAINER` | `[RO] docker port CONTAINER` | | Öffentliche IPv4 abfragen | `[TEST][SENS] Invoke-RestMethod https://api.ipify.org` | `[TEST][SENS] curl -4 https://api.ipify.org` | `[TEST][SENS] curl -4 https://api.ipify.org` | | DNS-A- und AAAA-Einträge | `[TEST] Resolve-DnsName HOST` | `[TEST] dig HOST A` und `[TEST] dig HOST AAAA` | `[TEST] dig HOST A` und `[TEST] dig HOST AAAA` | | Externen TCP-Port testen | `[TEST] Test-NetConnection PUBLIC_IP -Port PORT` | `[TEST] nc -vz -w 5 PUBLIC_IP PORT` | `[TEST] nc -vz -w 5 PUBLIC_IP PORT` | `IP`, `PORT`, `HOST`, `PUBLIC_IP` und `CONTAINER` müssen durch die Werte des konkreten Störungsfalls ersetzt werden.
---
32. Dokumentationsvorlage für NAT-Fehler ```text Störung: Zeitpunkt: Zeitzone: Betroffener Dienst: Betroffener Standort: Öffentlicher DNS-Name: Aufgelöste IPv4-Adresse: Aufgelöste IPv6-Adresse: Router-WAN-Adresse: Extern erkannte IPv4-Adresse: CGNAT oder Double NAT vermutet: Ja / Nein Anschlussart: Transportprotokoll: Externe IP-Adresse: Externer Port: Interne Zieladresse: Interner Zielport: WAN-Schnittstelle: LAN-Schnittstelle: Erlaubte Quelladressen: Interner Server: Aktuelle Server-IP: Server-Standardgateway: Listener vorhanden: Bind-Adresse: Host-Firewall geprüft: Interner Funktionstest: NAT-System: NAT-Regelname: NAT-Regel aktiviert: DNAT-Regel: SNAT- oder Masquerading-Regel: Forwarding aktiviert: Filterregel: Regelzähler vor Test: Regelzähler nach Test: Test aus internem Netz: Test über öffentliche Adresse aus internem Netz: Test aus externem Netz: Hairpin NAT erforderlich: Paket auf WAN-Seite sichtbar: Paket auf LAN-Seite sichtbar: Antwort des Servers sichtbar: Antwort auf WAN-Seite sichtbar: Container beteiligt: Reverse Proxy beteiligt: VPN beteiligt: Festgestellte Ursache: Genehmigte Änderung: Rückfallplan: Ergebnis der Nachprüfung: ```
---
33. Kontrollfragen nach der Diagnose - Funktioniert der Dienst direkt über seine interne Adresse? - Lauscht der Dienst auf dem richtigen Port und Transportprotokoll? - Stimmt die aktuelle interne Serveradresse mit der NAT-Regel überein? - Ist die Serveradresse dauerhaft reserviert oder statisch verwaltet? - Stimmt die Router-WAN-Adresse mit der extern erkannten Adresse überein? - Liegt die WAN-Adresse in einem privaten oder CGNAT-Adressbereich? - Existiert ein zweiter vorgeschalteter Router? - Zeigt DNS auf die aktuelle öffentliche Adresse? - Wurden A- und AAAA-Einträge getrennt geprüft? - Stimmen externer und interner Port? - Wurde TCP nicht mit UDP verwechselt? - Gilt die NAT-Regel für die richtige Schnittstelle? - Existiert eine passende Firewallregel? - Ist IP-Forwarding entsprechend dem Sollzustand aktiviert? - Verwendet der Server das NAT-System als Rückweg? - Wurde wirklich aus einem externen Netz getestet? - Wurde Hairpin NAT getrennt von der externen Erreichbarkeit bewertet? - Wurden Paketmitschnitte vor und nach der Übersetzung verglichen? - Steigen die Zähler der erwarteten NAT- und Firewallregel? - Existiert eine weitere Ebene wie Container, Proxy oder VPN? - Wurde die öffentliche Freigabe auf das erforderliche Minimum begrenzt? - Wurde der Zustand nach der Änderung erneut intern und extern geprüft?
---
34. Quellen und weiterführende Dokumentation - Microsoft Learn – NAT-Netzwerk mit Windows und Hyper-V einrichten: https://learn.microsoft.com/windows-server/virtualization/hyper-v/setup-nat-network - Microsoft Learn – Get-NetNat: https://learn.microsoft.com/powershell/module/netnat/get-netnat - Microsoft Learn – Get-NetNatStaticMapping: https://learn.microsoft.com/powershell/module/netnat/get-netnatstaticmapping - Microsoft Learn – Get-NetNatSession: https://learn.microsoft.com/powershell/module/netnat/get-netnatsession - Netfilter – Network Address Translation mit nftables: https://wiki.nftables.org/wiki-nftables/index.php/Performing_Network_Address_Translation_(NAT) - Netfilter – Offizielle nftables-Dokumentation: https://netfilter.org/projects/nftables/manpage.html - Linux-Handbuch – iptables: https://man7.org/linux/man-pages/man8/iptables.8.html - Linux-Handbuch – conntrack: https://manpages.debian.org/conntrack/conntrack.8.en.html - Docker Docs – Port publishing and mapping: https://docs.docker.com/engine/network/port-publishing/ - Docker Docs – Container networking: https://docs.docker.com/engine/network/ - Docker Docs – Dockerfile `EXPOSE`: https://docs.docker.com/reference/dockerfile/#expose - RFC 1918 – Address Allocation for Private Internets: https://www.rfc-editor.org/rfc/rfc1918.html - RFC 6598 – Shared Address Space für Carrier-Grade NAT: https://www.rfc-editor.org/rfc/rfc6598.html - RFC 6888 – Common Requirements for Carrier-Grade NAT: https://www.rfc-editor.org/rfc/rfc6888.html - RFC 4787 – NAT Behavioral Requirements for UDP: https://www.rfc-editor.org/rfc/rfc4787.html - RFC 5382 – NAT Behavioral Requirements for TCP: https://www.rfc-editor.org/rfc/rfc5382.html
# 3.12 Proxy- und Reverse-Proxy-Fehler analysieren Ein Proxy befindet sich zwischen Client und Zielsystem. Je nach Proxyart verarbeitet, filtert, protokolliert oder vermittelt er Verbindungen. Dadurch kann eine direkte Verbindung funktionieren, während der Zugriff über den Proxy fehlschlägt – oder umgekehrt. Die zentralen Fragen dieser Seite lauten: > Welcher Proxy wird tatsächlich verwendet, wie wurde er ausgewählt und an welcher Stelle zwischen Client, Proxy und Zielsystem scheitert die Verbindung? ---
1. Sicherheits- und Aktionskennzeichnungen | Kennzeichnung | Bedeutung | |---|---| | `[RO]` | Rein lesender Befehl, der normalerweise keine Konfiguration verändert | | `[TEST]` | Aktiver Test, der Netzwerkverkehr erzeugt | | `[PRIV]` | Administrator- oder Root-Rechte können erforderlich sein | | `[FILE]` | Der Befehl schreibt Ausgaben in eine Datei | | `[SENS]` | Die Ausgabe kann sensible Informationen enthalten | | `[CHANGE]` | Der Befehl verändert eine Konfiguration | | `[DISRUPT]` | Der Befehl kann Verbindungen oder Dienste beeinträchtigen | Proxykonfigurationen und ausführliche HTTP-Ausgaben können interne Hostnamen, Benutzernamen, Cookies, Autorisierungsheader und Sitzungstoken enthalten. Sie dürfen nicht ungeprüft dokumentiert oder weitergegeben werden.
---
2. Proxyarten unterscheiden | Proxyart | Position und Aufgabe | |---|---| | Forward Proxy | Vermittelt Verbindungen von Clients zu externen oder internen Zielen | | Explicit Proxy | Client kennt Proxyadresse und Proxyport ausdrücklich | | Transparent Proxy | Verkehr wird ohne ausdrückliche Proxykonfiguration umgeleitet | | Reverse Proxy | Nimmt Anfragen für Serverdienste entgegen und leitet sie an Backends weiter | | SOCKS-Proxy | Vermittelt TCP-Verbindungen und abhängig von Version und Werkzeug weitere Funktionen | | Caching Proxy | Speichert Antworten zwischen, um Zugriffe zu beschleunigen oder Datenverkehr zu reduzieren | | Filtering Proxy | Filtert Ziele, Kategorien, Inhalte oder Dateitypen | | TLS-Inspection-Proxy | Entschlüsselt und untersucht TLS-Verbindungen entsprechend der Sicherheitsrichtlinie | | PAC-Proxy | Proxy wird durch eine Proxy-Autokonfigurationsdatei ausgewählt | | WPAD | Verfahren zur automatischen Ermittlung einer Proxykonfiguration | | Application Proxy | Gilt nur für eine bestimmte Anwendung oder einen bestimmten Dienst | | System Proxy | Wird durch Betriebssystemkomponenten oder mehrere Anwendungen verwendet | **Wichtig:** Nicht jede Anwendung verwendet automatisch die systemweite Proxykonfiguration.
---
3. Forward Proxy und Reverse Proxy auseinanderhalten **Forward Proxy:** ```text Client ↓ Forward Proxy ↓ Zielserver im Internet oder Netzwerk ``` Der Client oder das Betriebssystem kennt den Proxy normalerweise. **Reverse Proxy:** ```text Client ↓ Reverse Proxy ↓ Backend-Anwendung ``` Der Client kennt normalerweise nur den öffentlichen Dienstnamen. Dass dahinter ein Reverse Proxy und ein oder mehrere Backends stehen, muss für ihn nicht sichtbar sein. | Fehlerstelle | Typische Prüfung | |---|---| | Client zum Forward Proxy | DNS, Route, Port, Authentifizierung | | Forward Proxy zum Zielserver | Proxyprotokoll, Filterregel, DNS und Ausgangsverbindung | | Client zum Reverse Proxy | DNS, Port, TLS und Firewall | | Reverse Proxy zum Backend | Backendadresse, Port, Protokoll, TLS und Anwendung | | Backend selbst | Dienststatus, Listener, Protokolle und Antwortzeit |
---
4. Typische Fehlermeldungen einordnen | Meldung oder Status | Typische Bedeutung | |---|---| | `Could not resolve proxy` | Proxyhostname konnte nicht aufgelöst werden | | `Failed to connect to proxy` | Proxyadresse wurde ermittelt, Verbindung zum Proxyport schlägt fehl | | `407 Proxy Authentication Required` | Forward Proxy verlangt eine Authentifizierung | | `403 Forbidden` | Zugriff wird durch Zielserver, Proxy oder Richtlinie verweigert | | `502 Bad Gateway` | Reverse Proxy erhielt keine gültige Antwort vom Backend | | `503 Service Unavailable` | Dienst oder Backend ist nicht verfügbar | | `504 Gateway Timeout` | Proxy erhielt innerhalb der vorgesehenen Zeit keine Backendantwort | | `Connection refused` | Ziel erreichbar, aber Port wird nicht angenommen | | `Connection timed out` | Keine rechtzeitige Antwort; Filterung, Routing oder Ausfall möglich | | `ERR_PROXY_CONNECTION_FAILED` | Browser konnte den konfigurierten Proxy nicht verwenden | | `ERR_TUNNEL_CONNECTION_FAILED` | Aufbau eines Proxytunnels, häufig per CONNECT, ist fehlgeschlagen | | Zertifikat nicht vertrauenswürdig | Zertifikatskette, TLS-Inspection oder falsches Zertifikat prüfen | | Umleitungsschleife | Proxy-, Anwendungsschema- oder Hostheaderkonfiguration prüfen | | Nur Browser funktioniert | Anwendung verwendet möglicherweise andere Proxyeinstellungen | | Browser funktioniert nicht, CLI schon | Browser-, PAC-, Zertifikats- oder Erweiterungskonfiguration prüfen | Ein HTTP-Statuscode beweist noch nicht eindeutig, welche Komponente ihn erzeugt hat. Antwortheader und Protokolle müssen miteinander verglichen werden.
---
5. Den betroffenen Datenfluss dokumentieren Vor der Diagnose müssen folgende Angaben bekannt sein: ```text Client: Client-IP: Benutzerkontext: Anwendung: Ziel-URL: Zielhostname: Zielport: Proxyart: Proxyhostname: Proxy-IP: Proxyport: PAC-URL: Verwendete Authentifizierung: Zeitpunkt: Fehlermeldung: ``` Zusätzlich prüfen: - Tritt der Fehler bei allen Benutzern auf? - Tritt er bei allen Anwendungen auf? - Sind nur interne oder externe Ziele betroffen? - Funktioniert HTTP, aber HTTPS nicht? - Funktioniert der Zugriff ohne VPN? - Tritt der Fehler nur in einem bestimmten Netzwerk auf? - Ist nur ein einzelner Hostname oder eine gesamte Kategorie betroffen? - Funktioniert derselbe Zugriff auf einem Vergleichssystem?
---
6. Mehrere Proxykonfigurationen berücksichtigen Auf demselben System können unterschiedliche Einstellungen gleichzeitig existieren: - Betriebssystem-Proxy, - WinHTTP-Proxy, - benutzerbezogene Windows-Einstellungen, - Browserkonfiguration, - PAC-Datei, - WPAD, - Umgebungsvariablen, - Anwendungskonfiguration, - Java-Proxyparameter, - Paketmanagerkonfiguration, - Container-Umgebungsvariablen, - Gruppenrichtlinie oder MDM-Profil, - VPN- oder Sicherheitssoftware, - transparenter Netzwerkproxy. **Typisches Fehlerbild:** ```text Browser verwendet PAC-Datei PowerShell-Dienst verwendet WinHTTP CLI-Programm verwendet HTTPS_PROXY Anwendung besitzt eigene Proxykonfiguration ``` Deshalb muss immer genau geprüft werden, **welche Anwendung unter welchem Benutzerkonto** betroffen ist.
---
7. Proxy-Umgebungsvariablen prüfen Häufig verwendete Variablen: ```text http_proxy https_proxy all_proxy no_proxy HTTP_PROXY HTTPS_PROXY ALL_PROXY NO_PROXY ``` Die unterstützte Schreibweise hängt von Anwendung und Bibliothek ab. Bei curl besitzt insbesondere `http_proxy` eine besondere Behandlung und wird aus Sicherheitsgründen nur in Kleinbuchstaben ausgewertet. **Windows PowerShell:** ```powershell [RO][SENS] Get-ChildItem Env: | Where-Object Name -Match '^(http|https|all|no)_proxy$' | Sort-Object Name ``` **Windows CMD:** ```cmd [RO][SENS] set | findstr /I "http_proxy https_proxy all_proxy no_proxy" ``` **Linux und macOS:** ```bash [RO][SENS] env | grep -iE '^(http|https|all|no)_proxy=' ``` **Nur Variablennamen ohne Werte anzeigen:** ```bash [RO] env | sed -n 's/^\([^=]*[Pp][Rr][Oo][Xx][Yy]\)=.*/\1/p' ``` Proxy-URLs können Zugangsdaten enthalten: ```text http://benutzer:passwort@proxy.example.internal:8080 ``` Solche Werte dürfen nicht in Tickets, Bildschirmfotos oder Dokumentationen übernommen werden.
---
8. Windows: WinHTTP-Proxy prüfen WinHTTP wird von bestimmten Windows-Diensten und Anwendungen verwendet. Seine Konfiguration kann von den benutzerbezogenen Proxy-Einstellungen abweichen. **Grundlegende WinHTTP-Konfiguration:** ```cmd [RO][SENS] netsh winhttp show proxy ``` **Erweiterte WinHTTP-Konfiguration:** ```cmd [RO][SENS] netsh winhttp show advproxy ``` Mögliche Informationen: - Proxyserver, - Proxyport, - Umgehungsliste, - PAC-URL, - automatische Erkennung, - direkte Verbindung. **Wichtig:** ```text Direkter Zugriff im Browser funktioniert ≠ WinHTTP-Dienst funktioniert ``` und: ```text WinHTTP funktioniert ≠ Browser verwendet dieselbe Konfiguration ``` Änderungsbefehle wie `netsh winhttp reset proxy`, `set proxy` oder `import proxy` dürfen nicht als rein lesende Diagnosebefehle verwendet werden.
---
9. Windows: benutzerbezogene Proxyeinstellungen prüfen **Relevante Benutzereinstellungen auslesen:** ```powershell [RO][SENS] Get-ItemProperty ` "HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings" | Select-Object ProxyEnable, ProxyServer, ProxyOverride, AutoConfigURL, AutoDetect ``` Je nach Windows-Version und Richtlinienquelle können einzelne Eigenschaften fehlen oder anders verwaltet werden. | Eigenschaft | Typische Bedeutung | |---|---| | `ProxyEnable` | Manuell eingetragener Proxy aktiviert | | `ProxyServer` | Proxyadresse beziehungsweise protokollspezifische Zuordnungen | | `ProxyOverride` | Umgehungsliste | | `AutoConfigURL` | URL einer PAC-Datei | | `AutoDetect` | Automatische Erkennung aktiviert | **Nur vorhandene Werte einzeln prüfen:** ```powershell [RO][SENS] Get-ItemProperty ` "HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings" ` -ErrorAction SilentlyContinue ``` Zu kontrollieren sind: - Wird ein manueller Proxy verwendet? - Ist zusätzlich eine PAC-Datei eingetragen? - Ist automatische Erkennung aktiviert? - Enthält die Umgehungsliste das Ziel? - Wird die Einstellung durch Gruppenrichtlinien verwaltet? - Tritt der Fehler nur bei einem Benutzerprofil auf? Registrywerte sollten nicht direkt verändert werden, solange Verwaltungsquelle und Sollzustand nicht geklärt sind.
---
10. Windows: Richtlinien und Benutzerkontext prüfen **Angewendete Gruppenrichtlinien anzeigen:** ```cmd [RO][FILE][SENS] gpresult /h "%TEMP%\gpresult-proxy.html" ``` Die erzeugte HTML-Datei befindet sich im temporären Verzeichnis des aktuellen Benutzers. **Nur Textausgabe:** ```cmd [RO][SENS] gpresult /r ``` Zu prüfen sind: - Computer- oder Benutzerrichtlinie, - Proxyserver, - PAC-URL, - Browserrichtlinien, - Zertifikatsverteilung, - Sicherheitszonen, - lokale Umgehungsmöglichkeiten, - Richtlinien des Sicherheitsprodukts. **Benutzerkontext bestimmen:** ```powershell [RO] whoami ``` Ein Dienstkonto, Systemkonto oder anderer Benutzer kann eine andere Proxy- und Zertifikatskonfiguration besitzen als der interaktiv angemeldete Benutzer.
---
11. macOS-Proxyeinstellungen prüfen Unter macOS werden Proxyeinstellungen pro Netzwerkdienst verwaltet, beispielsweise getrennt für WLAN und Ethernet. **Netzwerkdienste anzeigen:** ```bash [RO] networksetup -listallnetworkservices ``` Ein Sternchen vor einem Dienstnamen weist in der Ausgabe darauf hin, dass der Netzwerkdienst deaktiviert ist. **HTTP-Proxy eines Netzwerkdienstes:** ```bash [RO][SENS] networksetup -getwebproxy "Wi-Fi" ``` **HTTPS-Proxy:** ```bash [RO][SENS] networksetup -getsecurewebproxy "Wi-Fi" ``` **SOCKS-Proxy:** ```bash [RO][SENS] networksetup -getsocksfirewallproxy "Wi-Fi" ``` **PAC-URL:** ```bash [RO][SENS] networksetup -getautoproxyurl "Wi-Fi" ``` **Proxy-Umgehungsliste:** ```bash [RO][SENS] networksetup -getproxybypassdomains "Wi-Fi" ``` `Wi-Fi` muss durch den tatsächlich verwendeten Netzwerkdienst ersetzt werden. **Alle aktiven Proxyinformationen zusammengefasst anzeigen:** ```bash [RO][SENS] scutil --proxy ``` Zu kontrollieren sind: - Welcher Netzwerkdienst ist aktiv? - Ist der Proxy für diesen Dienst aktiviert? - Stimmen Proxyhostname und Port? - Ist eine PAC-URL aktiv? - Existieren Ausnahmen? - Wird die Konfiguration durch ein MDM-Profil verwaltet? - Ändert ein VPN-Client die Proxykonfiguration?
---
12. Linux-Proxyeinstellungen prüfen Linux besitzt keine für alle Distributionen und Anwendungen einheitliche Proxyverwaltung. Zu prüfen sind insbesondere: - Umgebungsvariablen, - Desktopumgebung, - Paketmanager, - systemd-Dienstkonfiguration, - Anwendungskonfiguration, - Containerkonfiguration, - Shell-Startdateien, - zentrale Konfigurationsverwaltung. **Umgebungsvariablen:** ```bash [RO][SENS] env | grep -iE '^(http|https|all|no)_proxy=' ``` **Systemweite Umgebungsdatei prüfen, sofern vorhanden:** ```bash [RO][SENS] test -f /etc/environment && sed -n '/[Pp][Rr][Oo][Xx][Yy]/p' /etc/environment ``` **systemd-Umgebung eines Dienstes anzeigen:** ```bash [RO][PRIV][SENS] sudo systemctl show DIENSTNAME \ --property=Environment \ --property=EnvironmentFiles ``` **Vollständige Unit-Konfiguration anzeigen:** ```bash [RO][PRIV][SENS] sudo systemctl cat DIENSTNAME ``` **Laufenden Prozess und Benutzer prüfen:** ```bash [RO] systemctl status DIENSTNAME ``` `DIENSTNAME` muss durch den tatsächlichen Dienst ersetzt werden. Ein interaktiver Shell-Test beweist nicht, dass ein systemd-Dienst dieselben Umgebungsvariablen verwendet.
---
13. Manuelle Proxyverbindung mit curl testen **HTTP-Ziel ausdrücklich über einen Proxy testen:** ```bash [TEST][SENS] curl -v \ --proxy http://proxy.example.internal:8080 \ http://example.com/ ``` **HTTPS-Ziel über einen HTTP-Proxy testen:** ```bash [TEST][SENS] curl -v \ --proxy http://proxy.example.internal:8080 \ https://example.com/ ``` Bei HTTPS verwendet curl über einen HTTP-Proxy normalerweise einen CONNECT-Tunnel zum Ziel. **Nur Antwortheader abrufen:** ```bash [TEST][SENS] curl -I \ --proxy http://proxy.example.internal:8080 \ https://example.com/ ``` **Zeitlimit setzen:** ```bash [TEST][SENS] curl -v \ --connect-timeout 5 \ --max-time 15 \ --proxy http://proxy.example.internal:8080 \ https://example.com/ ``` **Wichtige Ausgaben:** ```text Trying PROXY_IP:PORT Connected to proxy CONNECT ziel.example:443 HTTP/1.1 200 Connection established Proxy-Authenticate HTTP-Statuscode TLS-Handshake Zertifikatskette ``` `curl -v` kann sensible Header ausgeben. Vor der Dokumentation müssen Zugangsdaten, Cookies und Token entfernt werden.
---
14. Direkten Zugriff und Proxyzugriff vergleichen **Proxy ausdrücklich umgehen:** ```bash [TEST][SENS] curl -v --noproxy "*" https://example.com/ ``` **Proxy ausdrücklich verwenden:** ```bash [TEST][SENS] curl -v \ --proxy http://proxy.example.internal:8080 \ https://example.com/ ``` **Nur für ein bestimmtes Ziel den Proxy umgehen:** ```bash [TEST][SENS] curl -v \ --noproxy "example.com" \ https://example.com/ ``` **Vergleich:** | Direkter Zugriff | Proxyzugriff | Mögliche Eingrenzung | |---|---|---| | Erfolgreich | Fehlerhaft | Proxy, Authentifizierung, PAC oder Filterrichtlinie prüfen | | Fehlerhaft | Erfolgreich | Direkter Weg blockiert oder Proxy ist vorgeschrieben | | Beide fehlerhaft | Ziel, DNS, Clientnetz oder allgemeine Störung prüfen | | Beide erfolgreich | Fehler ist möglicherweise anwendungsspezifisch | | Nur Browser fehlerhaft | Browserprofil, PAC, Zertifikat oder Erweiterung prüfen | | Nur Systemdienst fehlerhaft | WinHTTP-, Dienstkonto- oder Dienstumgebung prüfen | Ein direkter Test darf nur durchgeführt werden, wenn die Sicherheitsrichtlinie einen Proxy-Bypass erlaubt.
---
15. Proxyhostname, Port und Erreichbarkeit prüfen **Namensauflösung des Proxys:** Windows: ```powershell [TEST] Resolve-DnsName proxy.example.internal ``` Linux: ```bash [TEST] getent ahosts proxy.example.internal ``` macOS: ```bash [TEST] dscacheutil -q host -a name proxy.example.internal ``` **Proxyport testen:** Windows: ```powershell [TEST] Test-NetConnection proxy.example.internal -Port 8080 -InformationLevel Detailed ``` Linux und macOS: ```bash [TEST] nc -vz -w 5 proxy.example.internal 8080 ``` **Route zum Proxy prüfen:** Windows: ```powershell [RO] Find-NetRoute -RemoteIPAddress PROXY_IP ``` Linux: ```bash [RO] ip route get PROXY_IP ``` macOS: ```bash [RO] route -n get PROXY_IP ``` Ein erfolgreicher TCP-Porttest beweist nur, dass eine Verbindung zum Proxyport aufgebaut werden konnte. Er beweist nicht, dass der Proxy die gewünschte Zielverbindung erlaubt.
---
16. PAC-Datei und automatische Proxyauswahl prüfen Eine PAC-Datei enthält JavaScript und liefert über die Funktion `FindProxyForURL()` eine Proxyentscheidung. Typische Rückgabewerte: ```text DIRECT PROXY proxy.example.internal:8080 HTTPS proxy.example.internal:8443 SOCKS socks.example.internal:1080 ``` Mehrere Möglichkeiten können in einer Reihenfolge angegeben werden: ```text PROXY proxy1.example.internal:8080; PROXY proxy2.example.internal:8080; DIRECT ``` **Konfigurierte PAC-URL ermitteln:** - Windows: `AutoConfigURL` beziehungsweise WinHTTP-Advanced-Proxy prüfen - macOS: `networksetup -getautoproxyurl` oder `scutil --proxy` - Linux: Desktop- oder Anwendungskonfiguration prüfen **PAC-Datei kontrolliert abrufen:** ```bash [TEST][SENS] curl -v "http://config.example.internal/proxy.pac" ``` **Ohne möglicherweise bereits gesetzte Proxyvariablen abrufen:** ```bash [TEST][SENS] curl -v --noproxy "*" \ "http://config.example.internal/proxy.pac" ``` Zu prüfen sind: - Ist die PAC-URL per DNS erreichbar? - Ist der Webserver erreichbar? - Wird ein erfolgreicher HTTP-Status geliefert? - Ist der MIME-Typ plausibel? - Ist die Datei syntaktisch gültig? - Welche Entscheidung trifft sie für die konkrete URL? - Werden interne und externe Namen unterschiedlich behandelt? - Gibt es Zeitverzögerungen durch DNS-Abfragen? - Enthält die Datei veraltete Proxynamen? - Wird die PAC-Datei zwischengespeichert? PAC-Dateien sind ausführbarer JavaScript-Code und dürfen nur aus vertrauenswürdigen Quellen bezogen werden.
---
17. WPAD und automatische Erkennung beurteilen WPAD kann eine Proxykonfiguration automatisch bereitstellen. Abhängig von der Umgebung kann die Ermittlung unter anderem über DHCP oder DNS erfolgen. Mögliche Fehler: - falscher WPAD-DNS-Eintrag, - WPAD-Server nicht erreichbar, - veraltete PAC-Datei, - unterschiedliche Suchdomänen, - VPN verändert DNS oder Suchsuffixe, - Client verwendet automatische Erkennung nicht, - Sicherheitsrichtlinie blockiert WPAD, - nicht autorisierter WPAD-Server. **Windows-DNS-Suffixe prüfen:** ```powershell [RO] Get-DnsClient | Select-Object InterfaceAlias, ConnectionSpecificSuffix ``` **Windows-DNS-Konfiguration:** ```powershell [RO] Get-DnsClientGlobalSetting ``` **Linux-Suchdomänen prüfen:** ```bash [RO] resolvectl status ``` Falls `resolvectl` nicht vorhanden ist: ```bash [RO] cat /etc/resolv.conf ``` **macOS-DNS-Konfiguration:** ```bash [RO][SENS] scutil --dns ``` WPAD darf nicht durch willkürlich angelegte DNS-Einträge getestet werden. Eine fehlerhafte oder manipulierte WPAD-Konfiguration kann den gesamten Webverkehr umleiten.
---
18. Proxy-Umgehungslisten prüfen Eine Umgehungsliste bestimmt, welche Ziele direkt und nicht über den Proxy erreicht werden. Typische Einträge: ```text localhost 127.0.0.1 ::1 *.example.internal 192.168.0.0/16 ``` Die unterstützte Syntax unterscheidet sich zwischen Betriebssystemen und Anwendungen. Nicht jede Anwendung versteht CIDR-Netze, Platzhalter oder `` gleich. **Typische Fehler:** - Hostname passt nicht zum Platzhaltermuster. - Kurzname wird umgangen, FQDN jedoch nicht. - IP-Adresse wird umgangen, Hostname dagegen nicht. - Falscher Trenner wurde verwendet. - Portnummer wurde unnötig in das Muster aufgenommen. - IPv6-Ziel fehlt. - `NO_PROXY` enthält Leerzeichen oder eine ungeeignete Syntax. - Anwendung interpretiert führende Punkte anders. - Interner Dienst wird versehentlich über externen Proxy gesendet. **curl-Entscheidung sichtbar machen:** ```bash [TEST][SENS] curl -v https://service.example.internal/ ``` In der ausführlichen Ausgabe kann curl anzeigen, welche Proxy- beziehungsweise `NO_PROXY`-Variable berücksichtigt wurde.
---
19. Proxy-Authentifizierung untersuchen Ein Forward Proxy kann unter anderem folgende Verfahren verwenden: - Basic, - Digest, - NTLM, - Negotiate beziehungsweise Kerberos, - zertifikatsbasierte Authentifizierung, - IP- oder gerätebasierte Freigabe. **Proxyantwort ohne Zugangsdaten prüfen:** ```bash [TEST][SENS] curl -v \ --proxy http://proxy.example.internal:8080 \ https://example.com/ ``` Auf folgende Header achten: ```text HTTP/1.1 407 Proxy Authentication Required Proxy-Authenticate: Basic Proxy-Authenticate: NTLM Proxy-Authenticate: Negotiate ``` **Sicherheitsregeln:** - Passwörter nicht direkt in die Befehlszeile schreiben. - Zugangsdaten nicht in Shell-History speichern. - Autorisierungsheader nicht in Tickets kopieren. - Keine produktiven Kennwörter in PAC-Dateien oder Umgebungsvariablen ablegen. - Authentifizierungsverfahren nicht ohne Freigabe herabsetzen. - Uhrzeit und Domänenanmeldung bei Kerberos-Problemen prüfen. **Benutzerkontext prüfen:** Windows: ```powershell [RO] whoami ``` Linux und macOS: ```bash [RO] id ``` Ein Hintergrunddienst besitzt möglicherweise keine interaktive Benutzersitzung und kann daher keine integrierte Proxyauthentifizierung durchführen.
---
20. TLS-Inspection und Zertifikatsfehler analysieren Bei TLS-Inspection baut die Sicherheitskomponente getrennte TLS-Verbindungen auf: ```text Client ↓ TLS-Verbindung 1 Inspection-Proxy ↓ TLS-Verbindung 2 Zielserver ``` Der Client sieht dabei ein vom Inspection-System ausgestelltes Zertifikat. **Zertifikat über den vorgesehenen Verbindungsweg prüfen:** ```bash [TEST][SENS] curl -v https://example.com/ ``` **TLS-Verbindung zu einem HTTPS-Ziel über HTTP-Proxy untersuchen:** ```bash [TEST][SENS] curl -v \ --proxy http://proxy.example.internal:8080 \ https://example.com/ ``` Zu prüfen sind: - Aussteller des präsentierten Zertifikats, - Hostname im Zertifikat, - Gültigkeitszeitraum, - Vertrauenskette, - Unternehmens-Stammzertifikat, - Zertifikatsspeicher der betroffenen Anwendung, - Systemzeit, - TLS-Version, - SNI, - Ausnahmen von der TLS-Inspection. **Typisches Fehlerbild:** ```text Browser funktioniert CLI-Anwendung meldet unbekannte Zertifizierungsstelle ``` Mögliche Ursache: - Browser und Anwendung verwenden unterschiedliche Zertifikatsspeicher. Die Zertifikatsprüfung darf nicht dauerhaft deaktiviert werden. Optionen wie `curl -k` dienen höchstens einer genehmigten Eingrenzung und stellen keine Fehlerbehebung dar.
---
21. Reverse Proxy vom Backend trennen Ein Reverse-Proxy-Datenfluss besteht mindestens aus zwei Verbindungen: ```text Verbindung 1: Client → Reverse Proxy Verbindung 2: Reverse Proxy → Backend ``` Beide Verbindungen können unterschiedliche Eigenschaften besitzen: | Eigenschaft | Clientseite | Backendseite | |---|---|---| | Protokoll | HTTPS | HTTP oder HTTPS | | Port | 443 | beispielsweise 80, 8080 oder 8443 | | DNS | öffentlicher Dienstname | interner Backendname | | Zertifikat | öffentliches oder internes Frontendzertifikat | gegebenenfalls internes Backendzertifikat | | Authentifizierung | Benutzeranmeldung | Dienst- oder keine zusätzliche Anmeldung | | Firewall | Client zum Proxy | Proxy zum Backend | | Timeout | Frontendtimeout | Upstreamtimeout | Ein erfolgreicher Zugriff auf den Reverse-Proxy-Port beweist nicht, dass das Backend erreichbar ist.
---
22. Reverse Proxy systematisch prüfen **Schritt 1 – DNS des öffentlichen Dienstnamens:** Windows: ```powershell [TEST] Resolve-DnsName service.example.net ``` Linux und macOS: ```bash [TEST] dig service.example.net A [TEST] dig service.example.net AAAA ``` **Schritt 2 – Frontend-Port:** Windows: ```powershell [TEST] Test-NetConnection service.example.net -Port 443 ``` Linux und macOS: ```bash [TEST] nc -vz -w 5 service.example.net 443 ``` **Schritt 3 – Frontend-Anwendung:** ```bash [TEST][SENS] curl -v https://service.example.net/ ``` **Schritt 4 – Backend vom Reverse-Proxy-System aus:** ```bash [TEST][SENS] curl -v http://backend.example.internal:8080/ ``` **Schritt 5 – Backend-Port:** ```bash [TEST] nc -vz -w 5 backend.example.internal 8080 ``` **Schritt 6 – Protokolle des Reverse Proxys:** - Zugriffsprotokoll, - Fehlerprotokoll, - Upstreamstatus, - Antwortzeit, - ausgewähltes Backend, - TLS-Fehler, - Namensauflösungsfehler. Der Backendtest muss vom Reverse-Proxy-System beziehungsweise aus dessen Netzwerk- oder Containerkontext erfolgen. Ein Test von einem Administrator-PC kann einen anderen Netzwerkpfad verwenden.
---
23. Wichtige Reverse-Proxy-Header prüfen Reverse Proxys übermitteln dem Backend häufig Informationen über die ursprüngliche Anfrage. Typische Header: ```text Host X-Forwarded-For X-Forwarded-Host X-Forwarded-Proto Forwarded ``` | Header | Typische Aufgabe | |---|---| | `Host` | Ursprünglich angesprochener Hostname | | `X-Forwarded-For` | Ursprüngliche Clientadresse beziehungsweise Proxykette | | `X-Forwarded-Host` | Ursprünglich verwendeter Host | | `X-Forwarded-Proto` | Ursprüngliches Schema wie `http` oder `https` | | `Forwarded` | Standardisierter Header für Proxyinformationen | **Mögliche Fehler:** - Backend erhält falschen Hostheader. - Anwendung erkennt HTTPS nicht und erzeugt HTTP-Links. - Endlose HTTP-zu-HTTPS-Umleitung. - Client-IP wird nicht korrekt übergeben. - Anwendung vertraut beliebigen `X-Forwarded-For`-Werten. - Mehrere Proxys erzeugen eine fehlerhafte Headerkette. - Anwendung ist nicht für vertrauenswürdige Proxys konfiguriert. Forwarded-Header dürfen nur von ausdrücklich vertrauenswürdigen Proxys als verlässlich behandelt werden.
---
24. Reverse-Proxy-Statuscodes untersuchen | Status | Mögliche Ursache | |---:|---| | `400` | Ungültige Anfrage, fehlerhafter Hostheader oder Protokollfehler | | `401` | Anwendung verlangt Authentifizierung | | `403` | Zugriff durch Proxy oder Backend verweigert | | `404` | Falscher Host, Pfad oder Backendrouting | | `408` | Anfrage wurde nicht rechtzeitig vollständig empfangen | | `413` | Anfrage oder Upload überschreitet eine Größenbegrenzung | | `421` | Anfrage wurde einem unpassenden Ziel beziehungsweise virtuellen Host zugeordnet | | `429` | Rate Limit wurde erreicht | | `431` | Header sind zu groß | | `499` | Nicht standardisierter, insbesondere bei NGINX verwendeter Status für Clientabbruch | | `500` | Interner Anwendungs- oder Proxyfehler | | `502` | Backend nicht erreichbar oder ungültige Backendantwort | | `503` | Kein verfügbares Backend oder Dienst absichtlich nicht verfügbar | | `504` | Backend antwortet nicht rechtzeitig | Zur eindeutigen Zuordnung müssen Antwortheader, Proxyprotokoll und Backendprotokoll zum selben Zeitpunkt verglichen werden.
---
25. NGINX-Reverse-Proxy prüfen Die folgenden Befehle gelten nur, wenn NGINX tatsächlich eingesetzt wird. **Konfigurationssyntax prüfen:** ```bash [RO][PRIV][SENS] sudo nginx -t ``` Dieser Befehl prüft die Konfiguration, lädt sie aber nicht neu. **Vollständig aufgelöste Konfiguration anzeigen:** ```bash [RO][PRIV][SENS] sudo nginx -T ``` Die Ausgabe kann Zertifikatspfade, interne Hostnamen und weitere sensible Konfigurationswerte enthalten. **Dienststatus:** ```bash [RO] systemctl status nginx ``` **Prozess und Listener:** ```bash [RO] ss -ltnp ``` **Dienstprotokolle über systemd:** ```bash [RO][PRIV][SENS] sudo journalctl -u nginx --since "-15 minutes" ``` Zu prüfen sind: - passende `server_name`-Direktive, - `listen`-Adresse und Port, - richtige `location`, - korrektes `proxy_pass`-Ziel, - Backendprotokoll HTTP oder HTTPS, - Namensauflösung des Backends, - TLS-SNI zum Backend, - Weitergabe benötigter Header, - Verbindungs- und Antworttime-outs, - Uploadgrößen, - WebSocket- beziehungsweise Upgrade-Header, - verfügbares Backend. Ein erfolgreicher `nginx -t` beweist nur, dass NGINX die Konfiguration syntaktisch akzeptiert. Er beweist nicht, dass das Backend erreichbar ist.
---
26. Container und Reverse Proxy prüfen Bei containerisierten Anwendungen entstehen zusätzliche Ebenen: ```text Client ↓ Hostport ↓ Reverse-Proxy-Container ↓ Docker-Netzwerk ↓ Backend-Container ↓ Anwendung ``` **Container und Ports anzeigen:** ```bash [RO] docker ps --format 'table {{.Names}}\t{{.Ports}}' ``` **Netzwerke anzeigen:** ```bash [RO] docker network ls ``` **Netzwerk untersuchen:** ```bash [RO][SENS] docker network inspect NETZWERKNAME ``` **Containerprotokolle:** ```bash [RO][SENS] docker logs --tail 100 CONTAINERNAME ``` **Umgebungsvariablen eines Containers kontrollieren:** ```bash [RO][SENS] docker inspect CONTAINERNAME ``` Zu prüfen sind: - Befinden sich Proxy und Backend im selben Docker-Netzwerk? - Wird der richtige Containername als DNS-Name verwendet? - Stimmt der interne Containerport? - Wird versehentlich der veröffentlichte Hostport als Containerziel verwendet? - Lauscht die Anwendung auf `0.0.0.0` beziehungsweise einer erreichbaren Containeradresse? - Startet das Backend später als der Proxy? - Ist der Backendname nach einer Umbenennung veraltet? - Enthält der Container Proxy-Umgebungsvariablen? - Umgeht `NO_PROXY` interne Containerziele korrekt?
---
27. NO_PROXY bei Containern und internen Diensten prüfen Ein Container kann ausgehende Verbindungen über einen Forward Proxy senden. Interne Dienste sollten abhängig vom Sollzustand möglicherweise direkt erreichbar sein. Beispiel: ```text HTTP_PROXY=http://proxy.example.internal:8080 HTTPS_PROXY=http://proxy.example.internal:8080 NO_PROXY=localhost,127.0.0.1,backend,backend.example.internal ``` **Typisches Fehlerbild:** ```text Anwendung möchte internen Backend-Container erreichen ↓ Backendname fehlt in NO_PROXY ↓ Anfrage wird an Unternehmensproxy gesendet ↓ Proxy kann internen Containernamen nicht auflösen ↓ Verbindung schlägt fehl ``` **Konfiguration anzeigen:** ```bash [RO][SENS] docker inspect CONTAINERNAME ``` Die genaue `NO_PROXY`-Syntax hängt von Anwendung und verwendeter Bibliothek ab. Änderungen müssen deshalb mit deren Dokumentation abgeglichen werden.
---
28. DNS-Auflösung aus dem richtigen Kontext prüfen Client, Forward Proxy, Reverse Proxy und Backend können unterschiedliche DNS-Server und Antworten verwenden. | System | Muss auflösen können | |---|---| | Client | Proxyhostname und gegebenenfalls Zielhostname | | Forward Proxy | Externes oder internes Ziel | | Reverse Proxy | Backendhostname | | Backend | Abhängige Datenbanken, APIs und Dienste | | Container | Containername oder internen DNS-Namen | **Windows:** ```powershell [TEST] Resolve-DnsName HOSTNAME ``` **Linux:** ```bash [TEST] getent ahosts HOSTNAME ``` **macOS:** ```bash [TEST] dscacheutil -q host -a name HOSTNAME ``` Der Befehl muss auf dem System ausgeführt werden, das die jeweilige Verbindung tatsächlich aufbaut. **Typisches Beispiel:** ```text Administrator-PC kann backend.example.internal auflösen Reverse-Proxy-Container kann den Namen nicht auflösen ``` Der erfolgreiche Test vom Administrator-PC ist dann für die Backendverbindung nicht ausreichend.
---
29. Zeitüberschreitungen systematisch unterscheiden Ein Proxyweg kann mehrere Time-outs besitzen: ```text Client-Verbindungszeit Proxy-Verbindungszeit zum Backend Zeit zum Senden der Anfrage Zeit bis zum ersten Antwortbyte Zeit zwischen Antwortdaten Gesamtdauer der Anfrage ``` **curl-Zeitmessung:** ```bash [TEST][SENS] curl -sS -o /dev/null \ -w 'DNS: %{time_namelookup}\nConnect: %{time_connect}\nTLS: %{time_appconnect}\nStartTransfer: %{time_starttransfer}\nTotal: %{time_total}\nHTTP: %{http_code}\n' \ https://service.example.net/ ``` **Über einen expliziten Proxy:** ```bash [TEST][SENS] curl -sS -o /dev/null \ --proxy http://proxy.example.internal:8080 \ -w 'DNS: %{time_namelookup}\nConnect: %{time_connect}\nTLS: %{time_appconnect}\nStartTransfer: %{time_starttransfer}\nTotal: %{time_total}\nHTTP: %{http_code}\n' \ https://service.example.net/ ``` Die Zeitwerte müssen mit Proxy- und Backendprotokollen verglichen werden. Ein `504` beweist nicht automatisch, dass das Backend vollständig ausgefallen ist; es kann lediglich später als das konfigurierte Zeitlimit geantwortet haben.
---
30. Paketmitschnitt für Proxyfehler erstellen **Verkehr zwischen Client und Forward Proxy:** ```bash [TEST][PRIV][FILE][SENS] sudo tcpdump -i INTERFACE -nn \ 'host PROXY_IP and tcp port PROXY_PORT' \ -w client-proxy.pcap ``` **Verkehr zwischen Reverse Proxy und Backend:** ```bash [TEST][PRIV][FILE][SENS] sudo tcpdump -i INTERFACE -nn \ 'host BACKEND_IP and tcp port BACKEND_PORT' \ -w proxy-backend.pcap ``` **Windows mit Dumpcap – Schnittstellen anzeigen:** ```powershell [RO] dumpcap -D ``` **Windows – Proxyverkehr aufzeichnen:** ```powershell [TEST][PRIV][FILE][SENS] dumpcap -i 1 ` -f "host PROXY_IP and tcp port PROXY_PORT" ` -w proxy-test.pcapng ``` **Wireshark-Anzeigefilter:** | Aufgabe | Filter | |---|---| | Proxyport 8080 | `tcp.port == 8080` | | HTTP-Statuscodes | `http.response.code` | | Status 407 | `http.response.code == 407` | | Status 502 | `http.response.code == 502` | | Status 504 | `http.response.code == 504` | | HTTP-CONNECT | `http.request.method == "CONNECT"` | | TLS-Handshake | `tls.handshake` | | TCP-Reset | `tcp.flags.reset == 1` | | TCP-Wiederholungen | `tcp.analysis.retransmission` | Verschlüsselter Datenverkehr zeigt ohne zulässige Entschlüsselung nicht den vollständigen HTTP-Inhalt.
---
31. Typische Fehlerbilder systematisch eingrenzen **Fall A – Proxyhostname kann nicht aufgelöst werden** Prüfen: - Proxyname, - DNS-Server, - DNS-Suffix, - VPN, - PAC-Datei, - veralteter Proxyname. --- **Fall B – Proxyport ist nicht erreichbar** Prüfen: - Route, - Firewall, - Proxybetrieb, - falscher Port, - nur aus bestimmten VLANs erlaubt, - IPv4- oder IPv6-Auswahl. --- **Fall C – HTTP 407** Prüfen: - Authentifizierungsverfahren, - Benutzerkonto, - Dienstkonto, - Domänenverbindung, - Systemzeit, - Kerberos, - gespeicherte Anmeldeinformationen, - Unterstützung der Anwendung. --- **Fall D – Browser funktioniert, Dienst nicht** Prüfen: - WinHTTP, - Dienstkonto, - Umgebungsvariablen, - Zertifikatsspeicher, - PAC-Unterstützung der Anwendung, - interaktive Authentifizierung. --- **Fall E – Direkter Zugriff funktioniert, Proxyzugriff nicht** Prüfen: - Proxyfilter, - Zielkategorie, - Proxy-DNS, - Authentifizierung, - CONNECT-Erlaubnis, - TLS-Inspection, - Proxyprotokolle. --- **Fall F – Reverse Proxy liefert 502** Prüfen: - Backenddienst, - Backendname, - Backendport, - HTTP gegenüber HTTPS, - Firewall, - Container-Netzwerk, - ungültige Backendantwort, - TLS-Zertifikat des Backends. --- **Fall G – Reverse Proxy liefert 504** Prüfen: - Backendantwortzeit, - Datenbank oder externe API, - Upstreamtimeout, - Paketverlust, - DNS-Verzögerung, - ausgelastetes Backend. --- **Fall H – Endlose Umleitung** Prüfen: - `X-Forwarded-Proto`, - HTTPS-Erkennung der Anwendung, - HTTP-zu-HTTPS-Regeln, - doppelten Redirect, - Basis-URL der Anwendung, - Hostheader.
---
32. Keine vorschnellen Proxyänderungen durchführen Nicht unkontrolliert: - Systemproxy zurücksetzen, - PAC-URL entfernen, - WPAD-DNS-Einträge anlegen, - Proxy-Authentifizierung deaktivieren, - TLS-Inspection umgehen, - Zertifikatsprüfung dauerhaft abschalten, - Unternehmenszertifikate löschen, - beliebige Ziele auf die Bypassliste setzen, - Forwarded-Header ungeprüft vertrauen, - Proxyprotokolle mit Zugangsdaten weitergeben, - Reverse Proxy neu laden, bevor die Konfiguration geprüft wurde. **Sicheres Vorgehen:** 1. Istkonfiguration dokumentieren. 2. Verwaltungsquelle bestimmen. 3. Betroffene Anwendung und Benutzerkontext feststellen. 4. Direkten und proxied Datenfluss getrennt prüfen. 5. Proxy- und Backendprotokolle zeitlich zuordnen. 6. Ursache nachweisen. 7. Änderung genehmigen lassen. 8. Kleinste erforderliche Änderung durchführen. 9. Funktion und Sicherheit prüfen. 10. Rückfallmöglichkeit dokumentieren.
---
33. Systematischer Diagnoseablauf | Schritt | Prüfung | Leitfrage | |---:|---|---| | 1 | Anwendung und Benutzerkontext bestimmen | Wer baut die Verbindung tatsächlich auf? | | 2 | Ziel-URL dokumentieren | Welcher Host, Port und welches Protokoll werden verwendet? | | 3 | Proxyart bestimmen | Forward Proxy, PAC, transparent oder Reverse Proxy? | | 4 | Konfigurationsquelle ermitteln | System, Anwendung, Richtlinie, Variable oder MDM? | | 5 | Proxyhostname auflösen | Wird die erwartete Proxyadresse verwendet? | | 6 | Proxyport prüfen | Ist der Proxy transportseitig erreichbar? | | 7 | PAC- beziehungsweise WPAD-Auswahl prüfen | Welcher Proxy wird für diese URL gewählt? | | 8 | Umgehungsliste prüfen | Soll das Ziel direkt oder über Proxy erreicht werden? | | 9 | Proxytest durchführen | Welche Antwort liefert der Proxy? | | 10 | Authentifizierung prüfen | Wird 407 oder ein anderes Verfahren verwendet? | | 11 | Direkten Vergleichstest durchführen | Liegt der Fehler nur im Proxyweg? | | 12 | Zertifikatskette prüfen | Ist TLS-Inspection oder ein Vertrauensproblem beteiligt? | | 13 | Reverse-Proxy-Frontend prüfen | Erreicht der Client den Reverse Proxy? | | 14 | Backend vom Proxy aus prüfen | Kann der Proxy das Backend erreichen? | | 15 | Header und Protokoll prüfen | Stimmen Host, Schema und Forwarded-Header? | | 16 | Protokolle vergleichen | Welche Komponente erzeugt den Fehler? | | 17 | Paketmitschnitt erstellen | An welcher Verbindung scheitert der Datenfluss? | | 18 | Minimale Änderung planen | Welche konkrete Korrektur stellt den Sollzustand her? | | 19 | Nachprüfung | Funktionieren Anwendung, Authentifizierung und TLS? | | 20 | Dokumentation | Sind Ursache, Änderung und Rückfallplan festgehalten? |
---
34. Kompakte Befehlstabelle | Aufgabe | Windows | Linux | macOS | |---|---|---|---| | Proxyvariablen | `[RO][SENS] Get-ChildItem Env: \| Where-Object Name -Match 'proxy'` | `[RO][SENS] env \| grep -i proxy` | `[RO][SENS] env \| grep -i proxy` | | WinHTTP-Proxy | `[RO][SENS] netsh winhttp show proxy` | Nicht zutreffend | Nicht zutreffend | | Erweiterter WinHTTP-Proxy | `[RO][SENS] netsh winhttp show advproxy` | Nicht zutreffend | Nicht zutreffend | | Benutzerproxy | `[RO][SENS] Get-ItemProperty "HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings"` | Abhängig von Desktop und Anwendung | `[RO][SENS] scutil --proxy` | | HTTP-Proxy | Abhängig von Anwendung | Über Umgebungs- oder Anwendungskonfiguration | `[RO][SENS] networksetup -getwebproxy "Wi-Fi"` | | HTTPS-Proxy | Abhängig von Anwendung | Über Umgebungs- oder Anwendungskonfiguration | `[RO][SENS] networksetup -getsecurewebproxy "Wi-Fi"` | | PAC-URL | Registry beziehungsweise WinHTTP prüfen | Abhängig von Desktop und Anwendung | `[RO][SENS] networksetup -getautoproxyurl "Wi-Fi"` | | Proxyhostname auflösen | `[TEST] Resolve-DnsName PROXY` | `[TEST] getent ahosts PROXY` | `[TEST] dscacheutil -q host -a name PROXY` | | Proxyport prüfen | `[TEST] Test-NetConnection PROXY -Port PORT` | `[TEST] nc -vz -w 5 PROXY PORT` | `[TEST] nc -vz -w 5 PROXY PORT` | | Expliziter Proxytest | `[TEST][SENS] curl.exe -v --proxy http://PROXY:PORT URL` | `[TEST][SENS] curl -v --proxy http://PROXY:PORT URL` | `[TEST][SENS] curl -v --proxy http://PROXY:PORT URL` | | Proxy umgehen | `[TEST][SENS] curl.exe -v --noproxy "*" URL` | `[TEST][SENS] curl -v --noproxy "*" URL` | `[TEST][SENS] curl -v --noproxy "*" URL` | | Dienstumgebung | Windows-Dienstkontext getrennt prüfen | `[RO][PRIV][SENS] sudo systemctl show DIENST --property=Environment` | Abhängig von LaunchDaemon und Anwendung | | Reverse-Proxy-Backend testen | `[TEST] Test-NetConnection BACKEND -Port PORT` | `[TEST] nc -vz -w 5 BACKEND PORT` | `[TEST] nc -vz -w 5 BACKEND PORT` | | NGINX-Konfiguration | Falls installiert: `[RO] nginx -t` | `[RO][PRIV][SENS] sudo nginx -t` | Falls installiert: `[RO][PRIV][SENS] sudo nginx -t` | | Containerprotokolle | `[RO][SENS] docker logs --tail 100 CONTAINER` | `[RO][SENS] docker logs --tail 100 CONTAINER` | `[RO][SENS] docker logs --tail 100 CONTAINER` | `PROXY`, `PORT`, `URL`, `DIENST`, `BACKEND` und `CONTAINER` müssen durch die Werte des konkreten Störungsfalls ersetzt werden.
---
35. Dokumentationsvorlage für Proxyfehler ```text Störung: Zeitpunkt: Zeitzone: Benutzer: Client: Client-IP: Betriebssystem: Betroffene Anwendung: Anwendungsversion: Ziel-URL: Zielhostname: Ziel-IP: Zielport: HTTP oder HTTPS: Fehlermeldung: HTTP-Statuscode: Proxyart: Proxyhostname: Proxy-IP: Proxyport: Konfigurationsquelle: PAC-URL: WPAD verwendet: Umgehungsliste: Proxy-Authentifizierung: TLS-Inspection: WinHTTP-Konfiguration: Benutzerkonfiguration: Umgebungsvariablen: Anwendungseigene Konfiguration: Gruppenrichtlinie oder MDM: Proxy-DNS erfolgreich: Proxyport erreichbar: Expliziter Proxytest: Direkter Vergleichstest: Zertifikatsaussteller: Proxyprotokolleintrag: Reverse Proxy beteiligt: Frontend erreichbar: Backendhostname: Backend-IP: Backendport: Backendprotokoll: Backend vom Proxy erreichbar: Backenddienst aktiv: Proxy-Fehlerprotokoll: Backend-Fehlerprotokoll: Forwarded-Header geprüft: Paketmitschnitt vorhanden: Festgestellte Ursache: Genehmigte Änderung: Rückfallplan: Ergebnis der Nachprüfung: ```
---
36. Kontrollfragen nach der Diagnose - Welche Anwendung baut die Verbindung auf? - Unter welchem Benutzer- oder Dienstkonto läuft sie? - Wird ein Forward Proxy, Reverse Proxy oder beides verwendet? - Welche Proxykonfiguration verwendet genau diese Anwendung? - Stimmen Proxyhostname und Proxyport? - Kann der Proxyname aufgelöst werden? - Ist der Proxyport erreichbar? - Wird eine PAC-Datei oder WPAD verwendet? - Welche Proxyentscheidung gilt für die konkrete URL? - Soll das Ziel laut Umgehungsliste direkt erreicht werden? - Existieren widersprüchliche Proxyvariablen? - Wurde ein Test mit ausdrücklich gesetztem Proxy durchgeführt? - Wurde ein genehmigter direkter Vergleichstest durchgeführt? - Verlangt der Proxy eine Authentifizierung? - Kann die Anwendung das Verfahren unterstützen? - Wird TLS-Inspection eingesetzt? - Verwendet die Anwendung den richtigen Zertifikatsspeicher? - Erreicht der Client den Reverse Proxy? - Kann der Reverse Proxy das Backend auflösen und erreichen? - Stimmen Backendprotokoll und Backendport? - Werden Host- und Forwarded-Header korrekt übermittelt? - Wurde der HTTP-Statuscode anhand der Protokolle einer Komponente zugeordnet? - Wurden Client-, Proxy- und Backendzeitstempel verglichen? - Wurde die Konfiguration nicht vorschnell zurückgesetzt? - Wurde die Funktion nach einer Änderung erneut vollständig geprüft?
---
37. Quellen und weiterführende Dokumentation - Microsoft Learn – `netsh winhttp`: https://learn.microsoft.com/de-de/windows-server/administration/windows-commands/netsh-winhttp - Microsoft Learn – WinHTTP AutoProxy Support: https://learn.microsoft.com/windows/win32/winhttp/winhttp-autoproxy-support - Microsoft Learn – WPAD-Prozess: https://learn.microsoft.com/windows-server/networking/automatic-tunneling/disable-http-proxy-auth-features - Apple – `networksetup`-Handbuch: Auf dem Mac lokal abrufbar mit `man networksetup` - Apple – Netzwerk-Proxyeinstellungen auf dem Mac: https://support.apple.com/de-de/guide/mac-help/mchlp2591/mac - curl – Proxy-Unterstützung: https://curl.se/docs/manpage.html#-x - curl – Proxy-Umgebungsvariablen: https://curl.se/libcurl/c/libcurl-env.html - curl – Alles rund um Proxys: https://everything.curl.dev/usingcurl/proxies/index.html - MDN – Proxy-Autokonfigurationsdatei: https://developer.mozilla.org/docs/Web/HTTP/Guides/Proxy_servers_and_tunneling/Proxy_Auto-Configuration_PAC_file - MDN – HTTP-Statuscode 407: https://developer.mozilla.org/docs/Web/HTTP/Reference/Status/407 - MDN – HTTP-Statuscode 502: https://developer.mozilla.org/docs/Web/HTTP/Reference/Status/502 - MDN – HTTP-Statuscode 504: https://developer.mozilla.org/docs/Web/HTTP/Reference/Status/504 - NGINX – Reverse Proxy: https://docs.nginx.com/nginx/admin-guide/web-server/reverse-proxy/ - NGINX – Modul `ngx_http_proxy_module`: https://nginx.org/en/docs/http/ngx_http_proxy_module.html - RFC 9110 – HTTP Semantics: https://www.rfc-editor.org/rfc/rfc9110.html - RFC 7239 – Forwarded HTTP Extension: https://www.rfc-editor.org/rfc/rfc7239.html
# 3.13 VPN- und Tunnelverbindungen analysieren Ein Virtual Private Network erweitert die lokale Netzwerkumgebung um einen verschlüsselten oder logisch getrennten Tunnel. Eine angezeigte VPN-Verbindung kann erfolgreich aufgebaut sein, obwohl interne Dienste, DNS-Auflösung oder einzelne Netzbereiche weiterhin nicht funktionieren. Die zentralen Fragen dieser Seite lauten: > Wird der Tunnel vollständig aufgebaut, erhält der Client die richtige Konfiguration und wird der betroffene Datenverkehr tatsächlich durch den vorgesehenen Tunnel geleitet? ---
1. Sicherheits- und Aktionskennzeichnungen | Kennzeichnung | Bedeutung | |---|---| | `[RO]` | Rein lesender Befehl, der normalerweise keine Konfiguration verändert | | `[TEST]` | Aktiver Test, der Netzwerkverkehr erzeugt | | `[PRIV]` | Administrator- oder Root-Rechte können erforderlich sein | | `[FILE]` | Der Befehl schreibt Ausgaben in eine Datei | | `[SENS]` | Die Ausgabe kann sensible Informationen enthalten | | `[CHANGE]` | Der Befehl verändert eine Konfiguration | | `[DISRUPT]` | Der Befehl kann Verbindungen oder Dienste beeinträchtigen | VPN-Ausgaben können Benutzernamen, öffentliche Schlüssel, interne Netze, Serveradressen, Zertifikatsinformationen und Sicherheitsrichtlinien enthalten. Private Schlüssel, Pre-Shared Keys, Passwörter und Sitzungstoken dürfen niemals dokumentiert oder weitergegeben werden.
---
2. VPN- und Tunnelarten unterscheiden | Art | Typische Verwendung | |---|---| | Remote-Access-VPN | Einzelne Clients verbinden sich mit einem Unternehmensnetz | | Site-to-Site-VPN | Zwei oder mehr Netzwerke werden miteinander verbunden | | Full Tunnel | Grundsätzlich wird der gesamte vorgesehene Datenverkehr durch das VPN geleitet | | Split Tunnel | Nur definierte Netze oder Anwendungen verwenden den Tunnel | | Device Tunnel | Verbindung wird im Gerätekontext aufgebaut | | User Tunnel | Verbindung wird im Benutzerkontext aufgebaut | | Always-On-VPN | Tunnel wird automatisch oder dauerhaft aufgebaut | | Policy-Based VPN | Auswahl des Tunnelverkehrs anhand definierter Richtlinien | | Route-Based VPN | Tunnel wird als routbare virtuelle Schnittstelle behandelt | | Application VPN | Nur ausgewählte Anwendungen verwenden den Tunnel | | Overlay-Netzwerk | Virtuelles Netz wird über ein bestehendes Netz gelegt | | Zero-Trust-Zugang | Zugriff wird zusätzlich anhand von Identität, Gerät und Richtlinien bewertet | **Wichtig:** Die Anzeige „Verbunden“ bestätigt häufig nur den Tunnelaufbau. Sie beweist nicht, dass die benötigte Anwendung erreichbar ist.
---
3. Häufige VPN-Protokolle und Transportwege | VPN-Technik | Typischer Transport | |---|---| | IKEv2/IPsec | UDP 500 und bei NAT-T UDP 4500 | | IPsec ESP | IP-Protokollnummer 50, kein TCP- oder UDP-Port | | IPsec AH | IP-Protokollnummer 51, kein TCP- oder UDP-Port | | L2TP | Typischerweise UDP 1701, häufig zusammen mit IPsec | | SSTP | TCP 443 | | OpenVPN | Häufig UDP oder TCP 1194, aber frei konfigurierbar | | WireGuard | UDP, Port frei konfigurierbar; häufig wird 51820 verwendet | | GRE | IP-Protokollnummer 47, kein TCP- oder UDP-Port | | TLS-basierte Hersteller-VPNs | Häufig TCP 443 oder UDP-basierter Transport | | SSH-Tunnel | TCP, häufig Port 22, aber konfigurierbar | Die tatsächlichen Ports und Protokolle müssen immer aus der produktiven VPN-Konfiguration entnommen werden. **Nicht verwechseln:** ```text GRE = IP-Protokoll 47 ESP = IP-Protokoll 50 AH = IP-Protokoll 51 ``` Diese Zahlen sind keine Portnummern.
---
4. Die Diagnose in Phasen aufteilen | Phase | Zentrale Frage | |---|---| | 1. Basisverbindung | Besitzt der Client eine funktionierende Verbindung zum Internet oder Unternehmensnetz? | | 2. Serverauflösung | Kann der VPN-Gatewayname korrekt aufgelöst werden? | | 3. Transport | Ist der benötigte Port beziehungsweise das IP-Protokoll erreichbar? | | 4. Authentifizierung | Werden Benutzer, Gerät, Zertifikat und MFA akzeptiert? | | 5. Tunnelerstellung | Wird eine virtuelle Schnittstelle beziehungsweise Security Association aufgebaut? | | 6. Adressierung | Erhält der Client die vorgesehene Tunneladresse? | | 7. Routing | Werden die benötigten Zielnetze in den Tunnel geleitet? | | 8. DNS | Werden interne Namen über die vorgesehenen Resolver aufgelöst? | | 9. Richtlinie | Darf Benutzer und Gerät auf das Ziel zugreifen? | | 10. Anwendung | Antwortet der eigentliche Dienst? | | 11. Stabilität | Bleibt der Tunnel verbunden und leistungsfähig? | Durch diese Trennung wird verhindert, dass ein Anwendungsfehler fälschlich als VPN-Aufbaufehler behandelt wird.
---
5. Störungsumfang zuerst bestimmen Vor den technischen Prüfungen sind folgende Fragen zu beantworten: - Ist nur ein Benutzer betroffen? - Ist nur ein Gerät betroffen? - Sind alle Benutzer eines Standorts betroffen? - Funktioniert das VPN über ein anderes Netzwerk? - Funktioniert es über Mobilfunk, aber nicht über WLAN? - Ist nur ein internes Ziel betroffen? - Sind alle internen Namen betroffen? - Funktionieren interne IP-Adressen, aber keine Hostnamen? - Funktioniert der Tunnelaufbau, aber kein Datenverkehr? - Bricht die Verbindung nach einer bestimmten Zeit ab? - Begann der Fehler nach Passwort-, Zertifikats- oder Clientänderung? - Betrifft der Fehler IPv4, IPv6 oder beides? - Wird Full Tunnel oder Split Tunnel erwartet? - Existiert eine aktuelle allgemeine VPN-Störung? **Wichtiger Vergleichstest:** ```text Gleiches Gerät + anderes Zugangsnetz Gleiches Benutzerkonto + anderes Gerät Anderer Benutzer + gleiches Gerät Funktionierender und fehlerhafter Client im Vergleich ``` Dabei müssen Datenschutz, Kontosicherheit und betriebliche Berechtigungen eingehalten werden.
---
6. Basisverbindung vor dem VPN prüfen Ein VPN benötigt zunächst eine funktionierende Verbindung zum VPN-Gateway. | Aufgabe | Windows | Linux | macOS | |---|---|---|---| | Schnittstellen | `[RO] Get-NetAdapter` | `[RO] ip -br link` | `[RO] ifconfig` | | IP-Konfiguration | `[RO] Get-NetIPConfiguration` | `[RO] ip -br address` | `[RO] ifconfig` | | Standardroute | `[RO] Get-NetRoute -DestinationPrefix "0.0.0.0/0"` | `[RO] ip route show default` | `[RO] route -n get default` | | DNS-Konfiguration | `[RO] Get-DnsClientServerAddress` | `[RO] resolvectl status` | `[RO][SENS] scutil --dns` | | Internetziel testen | `[TEST] Test-NetConnection example.com -Port 443` | `[TEST] curl -I https://example.com/` | `[TEST] curl -I https://example.com/` | Vor dem Verbindungsversuch dokumentieren: - lokale IP-Adresse, - Standardgateway, - verwendete Schnittstelle, - DNS-Server, - Proxykonfiguration, - öffentliche Quelladresse, - Datum und Uhrzeit. Ein Captive Portal in einem Hotel-, Bahn- oder Gastnetz kann den VPN-Aufbau verhindern, obwohl eine WLAN-Verbindung angezeigt wird.
---
7. VPN-Gateway auflösen und Transportweg prüfen **Namensauflösung:** Windows: ```powershell [TEST] Resolve-DnsName vpn.example.net ``` Linux: ```bash [TEST] getent ahosts vpn.example.net ``` macOS: ```bash [TEST] dscacheutil -q host -a name vpn.example.net ``` **Route zum Gateway prüfen:** Windows: ```powershell [RO] Find-NetRoute -RemoteIPAddress VPN_GATEWAY_IP ``` Linux: ```bash [RO] ip route get VPN_GATEWAY_IP ``` macOS: ```bash [RO] route -n get VPN_GATEWAY_IP ``` **TCP-basierten Gatewayport prüfen:** Windows: ```powershell [TEST] Test-NetConnection vpn.example.net -Port 443 -InformationLevel Detailed ``` Linux und macOS: ```bash [TEST] nc -vz -w 5 vpn.example.net 443 ``` Ein erfolgreicher TCP-Porttest gilt nur für TCP. Er prüft keine UDP-basierten IKEv2-, OpenVPN- oder WireGuard-Verbindungen.
---
8. Windows-VPN-Profile und Status prüfen **VPN-Profile des aktuellen Benutzers:** ```powershell [RO][SENS] Get-VpnConnection ``` **Geräteweite VPN-Profile:** ```powershell [RO][PRIV][SENS] Get-VpnConnection -AllUserConnection ``` **Ausführliche Darstellung:** ```powershell [RO][SENS] Get-VpnConnection | Format-List * ``` **Klassische Anzeige aktiver RAS-Verbindungen:** ```cmd [RO] rasdial ``` **Netzwerkadapter einschließlich virtueller Adapter:** ```powershell [RO] Get-NetAdapter -IncludeHidden | Sort-Object Status, Name | Format-Table Name, InterfaceDescription, Status, LinkSpeed ``` **IP-Konfiguration aller Schnittstellen:** ```powershell [RO][SENS] Get-NetIPConfiguration -All ``` Zu kontrollieren sind: - Name des VPN-Profils, - Tunneltyp, - Serveradresse, - Verbindungsstatus, - Authentifizierungsverfahren, - Split-Tunneling-Einstellung, - Routingrichtlinien, - Benutzer- oder Geräteprofil, - verwendeter virtueller Adapter. `Get-VpnConnection` zeigt nur VPN-Profile, die über die entsprechenden Windows-VPN-Komponenten verwaltet werden. Herstellerclients können eigene Konfigurationen und Diagnosewerkzeuge verwenden.
---
9. Windows-Routen vor und nach dem VPN vergleichen **Routingtabelle:** ```powershell [RO] Get-NetRoute | Sort-Object AddressFamily, DestinationPrefix, RouteMetric | Format-Table AddressFamily, DestinationPrefix, NextHop, InterfaceAlias, RouteMetric ``` **IPv4-Routingtabelle klassisch:** ```cmd [RO] route print -4 ``` **IPv6-Routingtabelle:** ```cmd [RO] route print -6 ``` **Route zu einem internen Ziel bestimmen:** ```powershell [RO] Find-NetRoute -RemoteIPAddress 10.20.30.40 ``` Besonders relevant: ```text DestinationPrefix NextHop InterfaceAlias RouteMetric InterfaceMetric ``` **Vergleichsablauf:** 1. Routingtabelle ohne VPN erfassen. 2. VPN verbinden. 3. Routingtabelle erneut erfassen. 4. Neue und veränderte Routen vergleichen. 5. Route zum betroffenen internen Ziel bestimmen. 6. Prüfen, ob die Route über den VPN-Adapter führt. Eine vorhandene Route beweist noch nicht, dass die VPN-Gegenstelle den Verkehr erlaubt oder korrekt zurückleitet.
---
10. Windows-VPN-Ereignisprotokolle prüfen **Vorhandene VPN- und RAS-Protokolle ermitteln:** ```powershell [RO][PRIV][SENS] Get-WinEvent -ListLog *Ras* | Select-Object LogName, IsEnabled, RecordCount ``` ```powershell [RO][PRIV][SENS] Get-WinEvent -ListLog *VPN* | Select-Object LogName, IsEnabled, RecordCount ``` **RasClient-Protokoll abfragen, sofern vorhanden:** ```powershell [RO][PRIV][SENS] Get-WinEvent ` -LogName "Microsoft-Windows-RasClient/Operational" ` -MaxEvents 100 ``` **Zeitlich begrenzen:** ```powershell [RO][PRIV][SENS] Get-WinEvent ` -FilterHashtable @{ LogName = "Microsoft-Windows-RasClient/Operational" StartTime = (Get-Date).AddMinutes(-30) } ``` Zusätzlich können abhängig vom VPN-Typ Protokolle zu folgenden Komponenten relevant sein: - IKE, - IPsec, - EAP, - Zertifikate, - NPS, - Geräteverwaltung, - Hersteller-VPN-Client. Nicht jede Umgebung aktiviert alle Diagnoseprotokolle standardmäßig.
---
11. Windows-IPsec-Sicherheitszuordnungen prüfen Bei IPsec-basierten Verbindungen können Security Associations wichtige Informationen liefern. **Main-Mode-Sicherheitszuordnungen:** ```powershell [RO][PRIV][SENS] Get-NetIPsecMainModeSA ``` **Quick-Mode-Sicherheitszuordnungen:** ```powershell [RO][PRIV][SENS] Get-NetIPsecQuickModeSA ``` **Main-Mode-Regeln:** ```powershell [RO][PRIV][SENS] Get-NetIPsecMainModeRule ``` **Verbindungs-Sicherheitsregeln:** ```powershell [RO][PRIV][SENS] Get-NetIPsecRule ``` Zu prüfen sind: - lokale und entfernte Adresse, - Authentifizierungsverfahren, - Verschlüsselungs- und Integritätsverfahren, - Status der Security Association, - Lebensdauer, - verwendete Richtlinie. Leere Ausgaben können bedeuten, dass keine entsprechende aktive IPsec-Sicherheitszuordnung existiert oder dass der eingesetzte VPN-Client nicht über diese Windows-Komponenten arbeitet.
---
12. Linux: Tunnel, Verbindungen und Schnittstellen prüfen **Aktive NetworkManager-Verbindungen:** ```bash [RO][SENS] nmcli connection show --active ``` **Gerätestatus:** ```bash [RO] nmcli device status ``` **Alle Schnittstellen:** ```bash [RO] ip -br link ``` **IP-Adressen:** ```bash [RO][SENS] ip -br address ``` **Routingtabelle:** ```bash [RO] ip route show ``` **IPv6-Routingtabelle:** ```bash [RO] ip -6 route show ``` **Policy-Routingregeln:** ```bash [RO] ip rule show ``` **Alle Routingtabellen:** ```bash [RO][SENS] ip route show table all ``` Mögliche Tunnelschnittstellen tragen abhängig von Technik und Hersteller Namen wie: ```text tun0 tap0 wg0 ppp0 ipsec0 Herstellerspezifischer Name ``` Der Name allein bestätigt nicht, dass der Tunnel vollständig funktionsfähig ist.
---
13. Linux-Protokolle prüfen **NetworkManager-Protokolle:** ```bash [RO][PRIV][SENS] sudo journalctl -u NetworkManager --since "-30 minutes" ``` **Aktuelle Kernelmeldungen zu Netzwerkproblemen:** ```bash [RO][PRIV][SENS] sudo journalctl -k --since "-30 minutes" ``` **Vorhandene VPN-Dienste suchen:** ```bash [RO] systemctl list-units --type=service | grep -Ei 'openvpn|wireguard|strongswan|ipsec|vpn' ``` **Protokoll eines konkret ermittelten Dienstes:** ```bash [RO][PRIV][SENS] sudo journalctl -u TATSAECHLICHER_DIENSTNAME \ --since "-30 minutes" ``` Der Unit-Name muss vorher ermittelt werden. Namen wie `openvpn.service` oder `openvpn-client@NAME.service` dürfen nicht ohne Prüfung angenommen werden.
---
14. macOS: VPN-Status und virtuelle Schnittstellen prüfen **VPN-Konfigurationen anzeigen:** ```bash [RO][SENS] scutil --nc list ``` **Status einer bekannten VPN-Konfiguration:** ```bash [RO][SENS] scutil --nc status "VPN-DIENSTNAME" ``` **Alle Schnittstellen anzeigen:** ```bash [RO][SENS] ifconfig ``` **Routingtabelle:** ```bash [RO] netstat -rn ``` **Standardroute:** ```bash [RO] route -n get default ``` **Route zu einem internen Ziel:** ```bash [RO] route -n get 10.20.30.40 ``` **DNS-Konfiguration:** ```bash [RO][SENS] scutil --dns ``` **Proxykonfiguration:** ```bash [RO][SENS] scutil --proxy ``` Viele Hersteller-VPN-Clients verwalten Tunnel und Filter über System Extensions oder Network Extensions. Ihre vollständige Konfiguration ist nicht zwingend über `networksetup` oder `scutil --nc` sichtbar.
---
15. WireGuard-Verbindungen prüfen Die folgenden Befehle gelten nur, wenn WireGuard eingesetzt wird und die Werkzeuge installiert sind. **WireGuard-Status:** ```bash [RO][PRIV][SENS] sudo wg show ``` Typische Angaben: ```text interface public key listening port peer endpoint allowed ips latest handshake transfer persistent keepalive ``` **Bestimmte Schnittstelle:** ```bash [RO][PRIV][SENS] sudo wg show wg0 ``` **Routing und Adresse der Schnittstelle:** ```bash [RO] ip address show dev wg0 ``` ```bash [RO] ip route show ``` Besonders relevant: | Feld | Diagnose | |---|---| | `latest handshake` | Fand kürzlich ein Handshake statt? | | `transfer` | Steigen gesendete und empfangene Datenmengen? | | `endpoint` | Wird die erwartete Gegenstellenadresse verwendet? | | `allowed ips` | Welche Zielnetze werden diesem Peer zugeordnet? | | `persistent keepalive` | Ist bei NAT-Szenarien ein Keepalive konfiguriert? | **Typische Muster:** | Beobachtung | Mögliche Bedeutung | |---|---| | Kein aktueller Handshake | Endpoint, UDP-Port, Schlüssel, Firewall oder Gegenstelle prüfen | | Gesendet steigt, empfangen nicht | Rückweg, Peer-Konfiguration oder Firewall prüfen | | Handshake aktuell, internes Ziel nicht erreichbar | Routen, AllowedIPs, Forwarding und Zielnetz prüfen | | Nur nach Datenverkehr Handshake sichtbar | Kann je nach Nutzung normal sein | | Tunnel funktioniert nur kurz | NAT-Zustand, Keepalive oder Netzwechsel prüfen | Konfigurationsausgaben, die private oder vorab geteilte Schlüssel enthalten könnten, dürfen nicht veröffentlicht werden.
---
16. OpenVPN-Verbindungen prüfen Die folgenden Prüfungen gelten nur, wenn OpenVPN eingesetzt wird. **Installierte Version:** ```bash [RO] openvpn --version ``` **Laufenden Prozess suchen:** ```bash [RO][SENS] ps aux | grep '[o]penvpn' ``` **Ermittelte systemd-Dienste prüfen:** ```bash [RO] systemctl list-units --type=service | grep -i openvpn ``` **Protokoll eines konkret ermittelten Dienstes:** ```bash [RO][PRIV][SENS] sudo journalctl -u TATSAECHLICHER_OPENVPN_DIENST \ --since "-30 minutes" ``` Typische Meldungsgruppen: | Meldung | Mögliche Bedeutung | |---|---| | TLS handshake failed | Zertifikat, Uhrzeit, Transport oder Gegenstelle prüfen | | AUTH_FAILED | Benutzeranmeldung, MFA oder Kontostatus prüfen | | Cannot resolve host address | DNS-Auflösung des Gateways fehlgeschlagen | | Connection timed out | Transportweg, Firewall oder Gateway prüfen | | Inactivity timeout | Kein ausreichender Datenverkehr oder Gegenstelle nicht erreichbar | | Route addition failed | Rechte, Routenkonflikt oder Plattformproblem | | TUN/TAP device error | Virtueller Adapter oder Berechtigung fehlerhaft | | Initialization Sequence Completed | Tunnelinitialisierung wurde abgeschlossen | Die exakte Formulierung hängt von OpenVPN-Version, Plattform und Verwaltungslösung ab.
---
17. VPN-Adressierung prüfen Nach erfolgreichem Aufbau erhält der Client abhängig vom VPN eine Adresse auf einer virtuellen Schnittstelle. **Windows:** ```powershell [RO][SENS] Get-NetIPAddress | Sort-Object InterfaceAlias, AddressFamily | Format-Table InterfaceAlias, AddressFamily, IPAddress, PrefixLength, AddressState ``` **Linux:** ```bash [RO][SENS] ip -br address ``` **macOS:** ```bash [RO][SENS] ifconfig ``` Zu kontrollieren sind: - Existiert eine Tunneladresse? - Stammt sie aus dem erwarteten Adressbereich? - Ist die Präfixlänge korrekt? - Existiert ein Adresskonflikt? - Überschneidet sich das VPN-Netz mit dem lokalen Netz? - Wird IPv4, IPv6 oder beides bereitgestellt? - Ist die Adresse nur temporär oder instabil? - Verwendet der Server die richtige Rückroute zum VPN-Adresspool?
---
18. Überschneidende lokale und entfernte Netze erkennen Ein häufiges Remote-Access-Problem entsteht, wenn das lokale Netz denselben Adressbereich wie das entfernte Unternehmensnetz verwendet. **Beispiel:** ```text Lokales Heimnetz: 192.168.1.0/24 Entferntes Firmennetz: 192.168.1.0/24 ``` Der Client kann dann nicht allein anhand der Zieladresse eindeutig entscheiden, ob das Ziel lokal oder über das VPN erreichbar ist. **Route zum Ziel prüfen:** Windows: ```powershell [RO] Find-NetRoute -RemoteIPAddress 192.168.1.50 ``` Linux: ```bash [RO] ip route get 192.168.1.50 ``` macOS: ```bash [RO] route -n get 192.168.1.50 ``` **Mögliche Lösungen im Netzdesign:** - lokale oder entfernte Netze neu adressieren, - spezifischere VPN-Routen verwenden, - NAT im VPN-Konzept einsetzen, - alternative interne Adressen bereitstellen, - virtualisierte oder anwendungsbasierte Zugänge verwenden. Eine manuell gesetzte Einzelroute ist höchstens eine kontrollierte Zwischenlösung und kann andere lokale Ziele unerreichbar machen.
---
19. Split Tunnel und Full Tunnel prüfen **Full Tunnel:** ```text Interne Ziele → VPN Internetverkehr → VPN ``` **Split Tunnel:** ```text Interne Ziele → VPN Internetverkehr → lokale Verbindung ``` **Windows-Profil prüfen:** ```powershell [RO][SENS] Get-VpnConnection | Select-Object Name, ConnectionStatus, SplitTunneling, TunnelType, ServerAddress ``` **Standardrouten unter Windows:** ```powershell [RO] Get-NetRoute -DestinationPrefix "0.0.0.0/0" | Format-Table InterfaceAlias, NextHop, RouteMetric ``` **Linux:** ```bash [RO] ip route show [RO] ip rule show ``` **macOS:** ```bash [RO] netstat -rn ``` Zu prüfen sind: - Existiert eine Standardroute über das VPN? - Werden nur bestimmte interne Präfixe verteilt? - Fehlt das Netz des betroffenen Dienstes? - Existieren mehrere gleichwertige Routen? - Wird Policy Routing verwendet? - Überschreibt der VPN-Client lokale Routen? - Bleibt der direkte Internetzugang laut Sollzustand erhalten? Split Tunneling ist eine Sicherheits- und Architekturentscheidung und darf nicht eigenmächtig aktiviert oder deaktiviert werden.
---
20. Route zu einem betroffenen Ziel eindeutig bestimmen **Windows:** ```powershell [RO] Find-NetRoute -RemoteIPAddress 10.20.30.40 ``` **Linux:** ```bash [RO] ip route get 10.20.30.40 ``` **macOS:** ```bash [RO] route -n get 10.20.30.40 ``` Zu dokumentieren sind: ```text Zieladresse verwendete Schnittstelle nächster Hop Quelladresse Routenpräfix Metrik ``` **Typische Diagnose:** ```text Tunnel ist verbunden ↓ Route zum Ziel zeigt auf WLAN statt VPN ↓ Benötigte VPN-Route fehlt oder wird durch spezifischere Route verdrängt ``` Die längste passende Präfixroute ist grundsätzlich besonders relevant. Eine spezifischere Route kann eine weniger spezifische VPN-Standardroute übersteuern.
---
21. Interne DNS-Auflösung über VPN prüfen **Windows-DNS-Server pro Schnittstelle:** ```powershell [RO][SENS] Get-DnsClientServerAddress | Format-Table InterfaceAlias, AddressFamily, ServerAddresses ``` **Windows-Suffixe:** ```powershell [RO] Get-DnsClient | Select-Object InterfaceAlias, ConnectionSpecificSuffix, RegisterThisConnectionsAddress ``` **Linux:** ```bash [RO][SENS] resolvectl status ``` **macOS:** ```bash [RO][SENS] scutil --dns ``` **Internen Namen über den vorgesehenen DNS-Server prüfen:** Windows: ```powershell [TEST] Resolve-DnsName server.example.internal ` -Server 10.20.0.53 ``` Linux und macOS: ```bash [TEST] dig @10.20.0.53 server.example.internal A ``` **IP-Adresse und Hostname getrennt testen:** ```text Zugriff über interne IP funktioniert Zugriff über internen Hostnamen funktioniert nicht ``` Das deutet eher auf DNS, Suchsuffixe oder Namensrichtlinien als auf einen allgemeinen Tunnelfehler hin.
---
22. Split DNS und DNS-Leaks beurteilen Bei Split DNS sollen bestimmte interne Namensräume über interne DNS-Server und andere Namen über lokale oder öffentliche Resolver aufgelöst werden. Beispiel: ```text *.example.internal → interner DNS-Server über VPN andere Namen → lokaler oder definierter externer DNS-Server ``` Mögliche Fehler: - interne Zone wird an öffentlichen DNS-Server gesendet, - interner DNS-Server ist nicht über den Tunnel erreichbar, - Suchsuffix fehlt, - lokale Schnittstelle besitzt eine höhere DNS-Priorität, - VPN-Client setzt DNS nur für IPv4, - Browser verwendet DNS over HTTPS unabhängig vom Betriebssystem, - ein lokaler Filter oder Proxy verändert die Namensauflösung. **Vergleichstest:** ```bash [TEST] dig server.example.internal ``` ```bash [TEST] dig @10.20.0.53 server.example.internal ``` Unterschiedliche Antworten zeigen, dass Resolverauswahl, Cache oder Split-DNS-Regeln weiter untersucht werden müssen.
---
23. Authentifizierung, Zertifikate und Uhrzeit prüfen Mögliche Authentifizierungsbestandteile: - Benutzername und Passwort, - Multifaktor-Authentifizierung, - Clientzertifikat, - Gerätezertifikat, - Pre-Shared Key, - Smartcard, - Geräteidentität, - SAML- oder Browseranmeldung, - Kerberos oder EAP. **Systemzeit prüfen:** | Betriebssystem | Befehl | |---|---| | Windows | `[RO] Get-Date -Format o` | | Linux | `[RO] date --iso-8601=seconds` | | macOS | `[RO] date "+%Y-%m-%dT%H:%M:%S%z"` | **Zeitsynchronisation:** Windows: ```powershell [RO] w32tm /query /status ``` Linux: ```bash [RO] timedatectl status ``` macOS: ```bash [RO] systemsetup -getusingnetworktime ``` Für den macOS-Befehl können erhöhte Rechte erforderlich sein: ```bash [RO][PRIV] sudo systemsetup -getusingnetworktime ``` Zu prüfen sind: - Zertifikat noch gültig? - Zertifikat bereits gültig? - Richtiger Aussteller? - Private-Key-Zugriff vorhanden? - Servername passt zum Zertifikat? - Zertifikat wurde widerrufen? - Benutzerkonto gesperrt? - Passwort abgelaufen? - MFA vollständig bestätigt? - Gerätekonformität erfüllt? - Systemzeit korrekt? Private Schlüssel dürfen niemals mit Diagnoseausgaben exportiert werden.
---
24. MTU- und Fragmentierungsprobleme erkennen VPN-Protokolle fügen zusätzliche Header hinzu. Dadurch sinkt die nutzbare Paketgröße innerhalb des Tunnels. **Typische Symptome:** - Tunnel verbindet sich erfolgreich. - Ping mit kleinen Paketen funktioniert. - Webseiten laden nur teilweise. - Dateiübertragungen bleiben hängen. - RDP oder SSH friert sporadisch ein. - Kleine API-Anfragen funktionieren, große nicht. - TLS-Handshake bleibt stehen. - Bestimmte Netze oder Provider sind betroffen. **Windows – IPv4-Paket mit gesetztem Don't-Fragment-Bit:** ```cmd [TEST] ping -4 -f -l 1400 10.20.30.40 ``` **Linux:** ```bash [TEST] ping -4 -M do -s 1400 10.20.30.40 ``` **macOS:** ```bash [TEST] ping -D -s 1400 10.20.30.40 ``` Die angegebene Nutzdatenlänge ist nicht identisch mit der gesamten IP-Paketgröße. Bei IPv4 kommen üblicherweise mindestens IP- und ICMP-Header hinzu. **Schnittstellen-MTU anzeigen:** Windows: ```powershell [RO] Get-NetIPInterface | Format-Table InterfaceAlias, AddressFamily, NlMtu, InterfaceMetric ``` Linux: ```bash [RO] ip link show ``` macOS: ```bash [RO] ifconfig ``` Die MTU darf nicht ohne Messung und Freigabe verändert werden. Eine zu kleine MTU kann Leistung reduzieren; eine zu große MTU kann Fragmentierungs- oder Black-Hole-Probleme verursachen.
---
25. Path-MTU-Discovery und ICMP berücksichtigen Path-MTU-Discovery benötigt bestimmte ICMP- beziehungsweise ICMPv6-Rückmeldungen. Wichtige Meldungen: - IPv4: Fragmentierung erforderlich - IPv6: Packet Too Big Werden diese Meldungen blockiert, kann ein Path-MTU-Black-Hole entstehen: ```text Kleine Pakete funktionieren ↓ Großes Paket überschreitet Pfad-MTU ↓ Router kann oder darf nicht fragmentieren ↓ ICMP-Fehlermeldung wird blockiert ↓ Sender erfährt die zulässige Größe nicht ↓ Übertragung bleibt hängen ``` **Paketmitschnittfilter:** ```text icmp icmpv6 ``` ICMP und ICMPv6 dürfen nicht pauschal als unnötig betrachtet oder vollständig blockiert werden.
---
26. Lokale Firewall und VPN-Kill-Switch prüfen Ein VPN-Client kann zusätzliche Filterregeln installieren, um Verkehr außerhalb des Tunnels zu verhindern. Mögliche Funktionen: - Kill Switch, - Always-On, - Lockdown Mode, - Blockierung lokaler Netze, - Blockierung unverschlüsselten DNS-Verkehrs, - anwendungsbasierte Filterung, - Gerätetunnelrichtlinien, - Filter über System- oder Network Extensions. **Typische Fehlerbilder:** - Nach VPN-Abbruch funktioniert kein Netzwerk mehr. - Lokale Drucker sind während des VPNs nicht erreichbar. - Internet funktioniert nur bei aktivem VPN. - DNS bleibt nach dem Trennen fehlerhaft. - Filterregeln bleiben nach Clientabsturz aktiv. - Herstellerclient zeigt getrennt, Filterkomponente arbeitet aber weiter. Zu prüfen sind: - native Host-Firewall, - Regeln des VPN-Clients, - Sicherheitssoftware, - Filtertreiber beziehungsweise System Extensions, - Proxykonfiguration, - DNS-Konfiguration, - Standardrouten. Kill-Switch- oder Sicherheitsfunktionen dürfen nicht ohne Freigabe deaktiviert werden.
---
27. Lokale Netzwerkzugriffe während des VPNs prüfen Ein VPN kann Zugriffe auf lokale Netze absichtlich unterbinden. Betroffene Beispiele: - lokale Drucker, - NAS-Systeme, - Routeroberfläche, - lokale Entwicklungsserver, - Smartcard- oder Lizenzserver, - Geräte im gleichen WLAN. **Route zum lokalen Ziel prüfen:** Windows: ```powershell [RO] Find-NetRoute -RemoteIPAddress 192.168.1.50 ``` Linux: ```bash [RO] ip route get 192.168.1.50 ``` macOS: ```bash [RO] route -n get 192.168.1.50 ``` Mögliche Ursachen: - Full Tunnel erfasst auch lokale Netze, - Sicherheitsrichtlinie blockiert LAN-Zugriff, - lokales und entferntes Netz überschneiden sich, - VPN-Client setzt spezifische Blockierungsrouten, - Host-Firewall behandelt den VPN-Adapter anders, - lokales Ziel antwortet nicht auf die VPN-Quelladresse. Lokalen LAN-Zugriff während des VPNs zu erlauben ist eine Sicherheitsentscheidung und keine rein technische Komforteinstellung.
---
28. VPN über restriktive Netze prüfen Hotels, Gast-WLANs, Mobilfunkanbieter und Unternehmensnetze können bestimmte VPN-Protokolle einschränken. **Vergleichstest:** ```text VPN über Firmennetz fehlerhaft VPN über Mobilfunk erfolgreich ``` Das deutet auf einen Unterschied im Zugangsnetz hin, beispielsweise: - UDP wird blockiert, - IPsec ESP wird blockiert, - NAT-T wird fehlerhaft behandelt, - Captive Portal ist noch nicht bestätigt, - TCP 443 ist nur über einen Proxy erlaubt, - DNS-Antwort wird verändert, - IPv6- und IPv4-Pfade unterscheiden sich, - Provider verwendet problematisches NAT. **Öffentliche Quelladresse vergleichen:** Windows: ```powershell [TEST][SENS] Invoke-RestMethod -Uri "https://api.ipify.org" ``` Linux und macOS: ```bash [TEST][SENS] curl -4 https://api.ipify.org ``` Die Nutzung eines externen Dienstes muss durch die betrieblichen Richtlinien erlaubt sein.
---
29. Stabilität und wiederkehrende Abbrüche untersuchen Bei sporadischen Abbrüchen dokumentieren: - exakten Zeitpunkt, - Dauer bis zum Abbruch, - Wechsel zwischen WLAN und Mobilfunk, - Standby oder Bildschirmruhe, - DHCP-Erneuerung, - Änderung der öffentlichen Adresse, - MFA- oder Sitzungslaufzeit, - Rekey- beziehungsweise SA-Lebensdauer, - NAT-Timeout, - Paketverlust, - Wechsel des Access Points, - Energiesparzustand, - parallelen VPN-Client, - Anzahl gleichzeitiger Sitzungen. **Kontinuierlicher Test zu einem internen Ziel:** Windows: ```powershell [TEST] ping -t 10.20.30.40 ``` Linux: ```bash [TEST] ping 10.20.30.40 ``` macOS: ```bash [TEST] ping 10.20.30.40 ``` Zusätzlich sollte ein Ziel außerhalb des VPNs getestet werden, um zwischen Verlust der Basisverbindung und Verlust des Tunnels zu unterscheiden. **Windows – zeitlich begrenzte PowerShell-Ausgabe:** ```powershell [TEST] Test-Connection 10.20.30.40 -Count 20 ``` Ping kann durch Richtlinien blockiert sein. Ein fehlender Ping ist deshalb kein alleiniger Nachweis eines Tunnelausfalls.
---
30. Anwendung statt nur Ping testen Nach Routing- und DNS-Prüfung muss der benötigte Dienst getestet werden. | Dienst | Beispiel | |---|---| | HTTPS | `[TEST] curl -v https://service.example.internal/` | | TCP-Port | `[TEST] Test-NetConnection HOST -Port PORT` | | SSH | `[TEST] ssh -vvv user@HOST` | | DNS | `[TEST] Resolve-DnsName HOST -Server DNS_SERVER` | | SMB | Unter Windows: `[TEST] Test-NetConnection HOST -Port 445` | | RDP | Unter Windows: `[TEST] Test-NetConnection HOST -Port 3389` | **Linux und macOS – TCP-Port:** ```bash [TEST] nc -vz -w 5 HOST PORT ``` **Reihenfolge:** ```text Tunnelstatus → Route → DNS → Port → Anwendungsprotokoll → Authentifizierung ``` Ein erfolgreicher VPN-Aufbau beweist nicht, dass eine Zugriffsrichtlinie den jeweiligen Anwendungsdienst erlaubt.
---
31. Paketmitschnitt für VPN-Fehler erstellen Es können zwei Datenebenen betrachtet werden: ```text Äußerer Verkehr: Client ↔ VPN-Gateway Innerer Verkehr: Tunneladresse ↔ internes Ziel ``` **Linux – äußerer Verkehr zum VPN-Gateway:** ```bash [TEST][PRIV][FILE][SENS] sudo tcpdump -i PHYSISCHE_SCHNITTSTELLE -nn \ 'host VPN_GATEWAY_IP' \ -w vpn-outer.pcap ``` **Linux – innerer Verkehr auf einer Tunnelschnittstelle:** ```bash [TEST][PRIV][FILE][SENS] sudo tcpdump -i TUNNEL_INTERFACE -nn \ 'host INTERNES_ZIEL' \ -w vpn-inner.pcap ``` **macOS:** ```bash [TEST][PRIV][FILE][SENS] sudo tcpdump -i INTERFACE -nn \ 'host VPN_GATEWAY_IP' \ -w vpn-test.pcap ``` **Windows – Schnittstellen mit Dumpcap anzeigen:** ```powershell [RO] dumpcap -D ``` **Windows – Mitschnitt:** ```powershell [TEST][PRIV][FILE][SENS] dumpcap -i 1 ` -f "host VPN_GATEWAY_IP" ` -w vpn-test.pcapng ``` Die Schnittstellen müssen vorher eindeutig ermittelt werden.
---
32. Wireshark-Filter für VPN-Diagnosen | Aufgabe | Anzeigefilter | |---|---| | IKE | `isakmp` | | UDP 500 | `udp.port == 500` | | NAT-T über UDP 4500 | `udp.port == 4500` | | ESP | `esp` | | AH | `ah` | | OpenVPN auf Standardport | `udp.port == 1194 || tcp.port == 1194` | | WireGuard auf häufigem Port | `udp.port == 51820` | | SSTP-Verkehr | `tcp.port == 443` | | DNS | `dns` | | ICMP | `icmp` | | ICMPv6 | `icmpv6` | | TCP-Reset | `tcp.flags.reset == 1` | | Wiederholte TCP-Pakete | `tcp.analysis.retransmission` | Die tatsächlichen Ports können abweichen und müssen aus der Konfiguration übernommen werden. Verschlüsselter VPN-Verkehr zeigt im äußeren Mitschnitt normalerweise nicht die ursprünglichen Anwendungsdaten.
---
33. Paketmuster interpretieren | Beobachtung | Mögliche Interpretation | |---|---| | Keine Pakete zum VPN-Gateway | DNS, Route, Anwendung oder lokaler Filter prüfen | | Ausgehende Pakete, keine Antwort | Gateway, Firewall, Provider, NAT oder Rückweg prüfen | | IKE-Austausch beginnt und endet | Authentifizierung, Richtlinie oder Verfahren prüfen | | Tunnelhandshake erfolgreich | Transport und kryptografischer Aufbau funktionieren grundsätzlich | | Tunnelverkehr wird gesendet, nichts empfangen | Gegenstelle, Rückroute oder Filter prüfen | | Inneres Paket verlässt Tunnel, keine Antwort | Zielnetz, Zielhost oder serverseitige Route prüfen | | Antworten kommen im Tunnel an, Anwendung erhält sie nicht | Lokale Firewall, Route oder Anwendung prüfen | | Kleine Pakete funktionieren, große nicht | MTU und Path-MTU-Discovery prüfen | | Häufige Neuverbindungen | Basisnetz, Rekey, NAT-Timeout oder Clientstabilität prüfen | Ein einseitiger Paketmitschnitt zeigt nur den jeweiligen Messpunkt. Bei komplexen Fehlern sollten Client, VPN-Gateway und internes Ziel zeitgleich betrachtet werden.
---
34. Typische Fehlerbilder systematisch eingrenzen **Fall A – VPN-Gatewayname wird nicht aufgelöst** Prüfen: - DNS-Server vor dem VPN, - Gatewayhostname, - Suchsuffix, - Captive Portal, - Proxy, - IPv4- und IPv6-Antworten. --- **Fall B – Authentifizierung schlägt fehl** Prüfen: - Benutzerkonto, - Passwortablauf, - MFA, - Zertifikat, - Systemzeit, - Geräteidentität, - Kontosperre, - Richtlinie, - maximal zulässige Sitzungen. --- **Fall C – VPN verbunden, keine internen Ziele erreichbar** Prüfen: - Tunneladresse, - Routen, - Split Tunnel, - Netzüberlappung, - lokale Firewall, - zentrale VPN-Richtlinie, - serverseitige Rückroute, - DNS. --- **Fall D – Interne IP funktioniert, Hostname nicht** Prüfen: - interne DNS-Server, - DNS-Suffix, - Split DNS, - DNS-Priorität, - DNS over HTTPS, - VPN-DNS-Richtlinie. --- **Fall E – Nur ein internes Netz ist nicht erreichbar** Prüfen: - fehlende Route, - falsches Präfix, - Access Control, - Rückroute, - Firewall zwischen VPN-Pool und Zielnetz, - überlappende Netze. --- **Fall F – VPN funktioniert über Mobilfunk, aber nicht über WLAN** Prüfen: - Captive Portal, - UDP-Blockierung, - lokales NAT, - Router-Firewall, - DNS-Manipulation, - IPsec-Passthrough, - IPv4-/IPv6-Unterschiede. --- **Fall G – Verbindung bricht bei großen Übertragungen ab** Prüfen: - MTU, - ICMP-Blockierung, - Paketverlust, - Time-outs, - Rekey, - Überlastung, - instabile Basisverbindung. --- **Fall H – Nach dem Trennen funktioniert das Internet nicht** Prüfen: - Standardroute, - DNS-Server, - Proxy, - Kill Switch, - Firewallfilter, - virtuellen Adapter, - fehlerhaft beendeten Herstellerclient.
---
35. VPN-Serverseite mit einbeziehen Die Clientdiagnose allein reicht nicht immer aus. Auf der Serverseite sind zu prüfen: - erreicht der Verbindungsversuch das Gateway, - wird die Authentifizierung akzeptiert, - wird eine Tunneladresse vergeben, - wird das richtige Benutzer- oder Geräteprofil angewendet, - werden die vorgesehenen Routen verteilt, - werden DNS-Server und Suffixe verteilt, - greift eine Zugriffsrichtlinie, - existiert eine Route zum VPN-Clientpool, - kennt das interne Netz den Rückweg, - arbeitet NAT wie vorgesehen, - ist der Adresspool erschöpft, - wird eine maximale Sitzungszahl erreicht, - sind Zertifikate gültig, - sind Zeit und Zeitzone synchron, - treten Rekey- oder SA-Fehler auf, - ist der Gateway-Cluster vollständig verfügbar. Client- und Serverprotokolle müssen anhand von Benutzer, Tunneladresse und Zeitstempel zugeordnet werden.
---
36. Keine vorschnellen VPN-Änderungen durchführen Nicht unkontrolliert: - VPN-Profil löschen, - Zertifikate entfernen, - private Schlüssel exportieren, - Split Tunneling aktivieren, - Kill Switch deaktivieren, - Firewall ausschalten, - MTU beliebig verändern, - manuelle Standardroute hinzufügen, - DNS-Server dauerhaft überschreiben, - VPN-Client neu installieren, - Security Associations oder Zustandstabellen leeren, - mehrere VPN-Clients gleichzeitig starten. **Sicherer Ablauf:** 1. Istzustand dokumentieren. 2. Client- und Profilversion feststellen. 3. Fehler reproduzieren. 4. Basisnetz und Gatewaytransport prüfen. 5. Tunnelstatus, Adresse, Route und DNS prüfen. 6. Client- und Serverprotokolle vergleichen. 7. Ursache nachweisen. 8. Änderung genehmigen lassen. 9. Kleinste erforderliche Korrektur durchführen. 10. Tunnelaufbau und Zielanwendung erneut testen. 11. Rückfallmöglichkeit und Ergebnis dokumentieren.
---
37. Systematischer Diagnoseablauf | Schritt | Prüfung | Leitfrage | |---:|---|---| | 1 | Störungsumfang bestimmen | Benutzer, Gerät, Standort oder allgemeine Störung? | | 2 | Basisverbindung prüfen | Funktioniert das Netz ohne VPN? | | 3 | Captive Portal ausschließen | Ist der Internetzugang vollständig freigeschaltet? | | 4 | Gateway auflösen | Wird die richtige VPN-Adresse verwendet? | | 5 | Route zum Gateway prüfen | Läuft der äußere Verkehr über die Basisschnittstelle? | | 6 | Transport prüfen | Erreichen benötigte Ports und Protokolle das Gateway? | | 7 | Authentifizierung prüfen | Werden Konto, MFA und Zertifikat akzeptiert? | | 8 | Tunnelstatus prüfen | Wurde der Tunnel tatsächlich aufgebaut? | | 9 | Tunneladresse prüfen | Hat der Client die vorgesehene Adresse erhalten? | | 10 | Routen vergleichen | Werden die Zielnetze durch den Tunnel geleitet? | | 11 | Netzüberlappungen prüfen | Konfligiert das lokale Netz mit dem Zielnetz? | | 12 | DNS prüfen | Werden interne Namen über richtige Resolver aufgelöst? | | 13 | Zielport testen | Ist der benötigte Dienst transportseitig erreichbar? | | 14 | Anwendung testen | Funktioniert das eigentliche Protokoll? | | 15 | MTU prüfen | Scheitern nur größere Pakete oder Übertragungen? | | 16 | Stabilität beobachten | Wann und unter welchen Bedingungen bricht der Tunnel ab? | | 17 | Protokolle vergleichen | Welche Seite beendet oder verweigert die Verbindung? | | 18 | Paketmitschnitt erstellen | Wo endet der erfolgreiche Datenfluss? | | 19 | Minimale Änderung planen | Welche konkrete Korrektur stellt den Sollzustand her? | | 20 | Nachprüfung | Funktionieren Tunnel, DNS, Routing und Anwendung? |
---
38. Kompakte Befehlstabelle | Aufgabe | Windows | Linux | macOS | |---|---|---|---| | VPN-Profile | `[RO][SENS] Get-VpnConnection` | `[RO][SENS] nmcli connection show` | `[RO][SENS] scutil --nc list` | | Geräteweite Profile | `[RO][PRIV][SENS] Get-VpnConnection -AllUserConnection` | Abhängig vom VPN-Client | Abhängig von MDM und VPN-Client | | Aktiver VPN-Status | `[RO] rasdial` | `[RO][SENS] nmcli connection show --active` | `[RO][SENS] scutil --nc status "VPN-NAME"` | | Schnittstellen | `[RO] Get-NetAdapter -IncludeHidden` | `[RO] ip -br link` | `[RO] ifconfig` | | IP-Adressen | `[RO][SENS] Get-NetIPAddress` | `[RO][SENS] ip -br address` | `[RO][SENS] ifconfig` | | Routingtabelle | `[RO] Get-NetRoute` | `[RO] ip route show` | `[RO] netstat -rn` | | Route zum Ziel | `[RO] Find-NetRoute -RemoteIPAddress IP` | `[RO] ip route get IP` | `[RO] route -n get IP` | | DNS-Konfiguration | `[RO][SENS] Get-DnsClientServerAddress` | `[RO][SENS] resolvectl status` | `[RO][SENS] scutil --dns` | | Gateway auflösen | `[TEST] Resolve-DnsName VPN_HOST` | `[TEST] getent ahosts VPN_HOST` | `[TEST] dscacheutil -q host -a name VPN_HOST` | | TCP-Gatewayport | `[TEST] Test-NetConnection VPN_HOST -Port PORT` | `[TEST] nc -vz -w 5 VPN_HOST PORT` | `[TEST] nc -vz -w 5 VPN_HOST PORT` | | Internen Port testen | `[TEST] Test-NetConnection INTERNER_HOST -Port PORT` | `[TEST] nc -vz -w 5 INTERNER_HOST PORT` | `[TEST] nc -vz -w 5 INTERNER_HOST PORT` | | MTU anzeigen | `[RO] Get-NetIPInterface` | `[RO] ip link show` | `[RO] ifconfig` | | DF-Test | `[TEST] ping -4 -f -l 1400 IP` | `[TEST] ping -4 -M do -s 1400 IP` | `[TEST] ping -D -s 1400 IP` | | WireGuard | Falls installiert: `[RO][PRIV][SENS] wg show` | `[RO][PRIV][SENS] sudo wg show` | Falls installiert: `[RO][PRIV][SENS] sudo wg show` | | NetworkManager-Protokoll | Nicht zutreffend | `[RO][PRIV][SENS] sudo journalctl -u NetworkManager --since "-30 minutes"` | Nicht zutreffend | | RAS-Protokoll | `[RO][PRIV][SENS] Get-WinEvent -LogName "Microsoft-Windows-RasClient/Operational"` | Nicht zutreffend | Nicht zutreffend | `VPN-NAME`, `IP`, `VPN_HOST`, `PORT` und `INTERNER_HOST` müssen durch die Werte des konkreten Störungsfalls ersetzt werden.
---
39. Dokumentationsvorlage für VPN-Fehler ```text Störung: Zeitpunkt: Zeitzone: Benutzer: Gerät: Betriebssystem: VPN-Client: VPN-Clientversion: VPN-Profil: VPN-Technik: Zugangsnetz: Zugangsart: LAN / WLAN / Mobilfunk Lokale IP-Adresse: Standardgateway: Öffentliche IP-Adresse: Captive Portal ausgeschlossen: Proxy vorhanden: VPN-Gatewayname: Aufgelöste Gatewayadresse: Verwendete Adressfamilie: Gatewayport beziehungsweise IP-Protokoll: Route zum Gateway: Transporttest: Authentifizierungsverfahren: MFA: Zertifikat geprüft: Systemzeit geprüft: Tunnelstatus: Tunneladresse: Virtuelle Schnittstelle: Split Tunnel oder Full Tunnel: Verteilte IPv4-Routen: Verteilte IPv6-Routen: Route zum betroffenen Ziel: Lokale Netzüberlappung: VPN-DNS-Server: DNS-Suffixe: Interne Namensauflösung: Betroffenes Ziel: Ziel-IP: Zielport: Transportprotokoll: Porttest: Anwendungstest: MTU-Test: Paketverlust: Abbruchzeitpunkt: Clientprotokoll: Gatewayprotokoll: Serverseitige Richtlinie: Rückroute zum VPN-Adresspool: Paketmitschnitt vorhanden: Vergleich über anderes Zugangsnetz: Vergleich mit anderem Benutzer: Vergleich mit anderem Gerät: Festgestellte Ursache: Genehmigte Änderung: Rückfallplan: Ergebnis der Nachprüfung: ```
---
40. Kontrollfragen nach der Diagnose - Funktioniert das Netzwerk ohne VPN? - Wurde ein Captive Portal ausgeschlossen? - Wird der VPN-Gatewayname richtig aufgelöst? - Führt die Route zum Gateway über die physische Basisschnittstelle? - Ist das benötigte Transportprotokoll erreichbar? - Werden Benutzer, Gerät, MFA und Zertifikat akzeptiert? - Ist der Tunnel wirklich aufgebaut? - Hat der Client eine gültige Tunneladresse erhalten? - Existieren die benötigten Routen? - Führt die Route zum Ziel tatsächlich über das VPN? - Überschneiden sich lokales und entferntes Netz? - Ist Full Tunnel oder Split Tunnel vorgesehen? - Werden die richtigen DNS-Server und Suffixe verwendet? - Funktioniert das Ziel über IP-Adresse? - Funktioniert das Ziel über Hostname? - Ist nur ein bestimmter Port oder Dienst betroffen? - Wurden IPv4 und IPv6 getrennt geprüft? - Gibt es Hinweise auf ein MTU-Problem? - Funktioniert das VPN über ein anderes Zugangsnetz? - Wurde ein Kill Switch beziehungsweise lokaler Filter berücksichtigt? - Wurde der serverseitige Rückweg zum VPN-Adresspool geprüft? - Wurden Client- und Gatewayprotokolle zeitlich abgeglichen? - Wurde die Ursache nachgewiesen, bevor Einstellungen verändert wurden? - Wurde nach der Änderung der gesamte Datenfluss erneut geprüft?
---
41. Quellen und weiterführende Dokumentation - Microsoft Learn – Get-VpnConnection: https://learn.microsoft.com/powershell/module/vpnclient/get-vpnconnection - Microsoft Learn – Windows-VPN-Client und VPN-Protokolle: https://learn.microsoft.com/windows-server/remote/remote-access/vpn/vpn-top - Microsoft Learn – Always-On-VPN: https://learn.microsoft.com/windows-server/remote/remote-access/tutorial-aovpn-deploy-setup - Microsoft Learn – Windows-VPN-Gerätetunnel: https://learn.microsoft.com/windows-server/remote/remote-access/vpn/vpn-device-tunnel-config - Microsoft Learn – Get-NetIPsecMainModeSA: https://learn.microsoft.com/powershell/module/netsecurity/get-netipsecmainmodesa - Microsoft Learn – Get-NetIPsecQuickModeSA: https://learn.microsoft.com/powershell/module/netsecurity/get-netipsecquickmodesa - Apple – VPN-Verbindung auf dem Mac konfigurieren: https://support.apple.com/de-de/guide/mac-help/mchlp2963/mac - Apple – VPN-Einstellungen auf dem Mac ändern: https://support.apple.com/de-de/guide/mac-help/mchlp1579/mac - WireGuard – Offizielle Kurzanleitung: https://www.wireguard.com/quickstart/ - WireGuard – Protokollbeschreibung: https://www.wireguard.com/protocol/ - OpenVPN – Offizielle Dokumentation: https://openvpn.net/community-resources/reference-manual-for-openvpn-2-6/ - NetworkManager – nmcli-Dokumentation: https://networkmanager.dev/docs/api/latest/nmcli.html - strongSwan – Dokumentation: https://docs.strongswan.org/docs/latest/ - RFC 7296 – Internet Key Exchange Protocol Version 2: https://www.rfc-editor.org/rfc/rfc7296.html - RFC 3947 – Negotiation of NAT-Traversal in IKE: https://www.rfc-editor.org/rfc/rfc3947.html - RFC 3948 – UDP Encapsulation of IPsec ESP Packets: https://www.rfc-editor.org/rfc/rfc3948.html - RFC 4301 – Security Architecture for the Internet Protocol: https://www.rfc-editor.org/rfc/rfc4301.html - RFC 8201 – Path MTU Discovery for IPv6: https://www.rfc-editor.org/rfc/rfc8201.html
# 3.14 WLAN- und Funkverbindungsfehler analysieren Eine WLAN-Verbindung besteht nicht nur aus „verbunden“ oder „nicht verbunden“. Zwischen Client und Anwendung liegen Funkübertragung, Authentifizierung, Zuordnung zu einem Access Point, VLAN-Zuweisung, IP-Konfiguration, Routing, DNS und der eigentliche Netzwerkdienst. Die zentralen Fragen dieser Seite lauten: > Kann der Client das gewünschte WLAN zuverlässig empfangen, sich korrekt authentifizieren und anschließend über das zugewiesene Netzwerk störungsfrei kommunizieren? ---
1. Sicherheits- und Aktionskennzeichnungen | Kennzeichnung | Bedeutung | |---|---| | `[RO]` | Rein lesender Befehl, der normalerweise keine Konfiguration verändert | | `[TEST]` | Aktiver Test, der Funk- oder Netzwerkverkehr erzeugt | | `[PRIV]` | Administrator- oder Root-Rechte können erforderlich sein | | `[FILE]` | Der Befehl schreibt Ausgaben in eine Datei | | `[SENS]` | Die Ausgabe kann sensible Informationen enthalten | | `[CHANGE]` | Der Befehl verändert eine Konfiguration | | `[DISRUPT]` | Der Befehl kann eine Verbindung oder Funkversorgung beeinträchtigen | WLAN-Diagnosen können SSIDs, BSSIDs, MAC-Adressen, Standorte, Benutzernamen, interne Netze und Authentifizierungsinformationen enthalten. Kennwörter und private Schlüssel dürfen niemals exportiert oder dokumentiert werden.
---
2. WLAN-Fehler in Schichten aufteilen | Ebene | Zentrale Frage | |---|---| | Hardware | Ist der WLAN-Adapter vorhanden und betriebsbereit? | | Funk | Ist das gewünschte WLAN mit ausreichender Qualität empfangbar? | | 802.11-Verbindung | Kann sich der Client mit dem Access Point verbinden? | | Authentifizierung | Werden Kennwort, Zertifikat oder 802.1X-Anmeldung akzeptiert? | | Netzwerkzuweisung | Erhält der Client das richtige VLAN und die richtige IP-Konfiguration? | | Routing | Ist das Standardgateway erreichbar? | | DNS | Funktioniert die Namensauflösung? | | Internetzugang | Ist ein externer Zugriff möglich? | | Anwendung | Funktioniert der tatsächlich benötigte Dienst? | | Stabilität | Bleibt die Verbindung bei Bewegung und Last erhalten? | **Grundregel:** ```text Mit WLAN verbunden ≠ gültige IP-Konfiguration ≠ Internetzugang ≠ Anwendung funktioniert ```
---
3. Wichtige WLAN-Begriffe unterscheiden | Begriff | Bedeutung | |---|---| | SSID | Sichtbarer beziehungsweise konfigurierter WLAN-Netzwerkname | | BSSID | Kennung einer konkreten Funkzelle, üblicherweise eine MAC-Adresse | | Access Point | Stellt die WLAN-Funkzelle bereit | | Band | Frequenzbereich, beispielsweise 2,4 GHz, 5 GHz oder 6 GHz | | Kanal | Genutzter Teil des Frequenzbereichs | | Kanalbreite | Beispielsweise 20, 40, 80 oder 160 MHz | | RSSI | Empfangssignalstärke, häufig in dBm angegeben | | Noise | Gemessener beziehungsweise geschätzter Rauschpegel | | SNR | Abstand zwischen Nutzsignal und Rauschen | | PHY-Rate | Ausgehandelte Bruttodatenrate der Funkverbindung | | Durchsatz | Tatsächlich nutzbare Datenübertragungsrate | | Roaming | Wechsel eines Clients zwischen Funkzellen | | Band Steering | Access Point versucht, Clients in ein geeignetes Frequenzband zu lenken | | Airtime | Anteil der Funkzeit, den Geräte für Übertragungen verwenden | | DFS | Dynamische Kanalauswahl zum Schutz bestimmter Radarsysteme | | Hidden SSID | SSID wird nicht regulär in Beacon-Frames angekündigt | | 802.1X | Portbasierte Authentifizierung, häufig in Unternehmens-WLANs | | Captive Portal | Webbasierte Freischaltung, häufig in Gastnetzen | Mehrere Access Points können dieselbe SSID anbieten, aber jeweils eine eigene BSSID verwenden.
---
4. Störungsumfang zuerst bestimmen Vor technischen Änderungen ist zu klären: - Ist nur ein Client betroffen? - Sind mehrere Clients am gleichen Standort betroffen? - Ist nur eine SSID betroffen? - Ist nur ein Access Point beziehungsweise eine BSSID betroffen? - Tritt der Fehler nur in einem bestimmten Raum auf? - Sind 2,4 GHz, 5 GHz oder 6 GHz unterschiedlich betroffen? - Funktioniert die Verbindung in unmittelbarer Nähe zum Access Point? - Tritt der Fehler nur während hoher Auslastung auf? - Tritt er nur beim Roaming auf? - Funktioniert Ethernet am selben Standort? - Funktioniert das WLAN, aber nicht der Internetzugang? - Erhalten andere Clients eine gültige DHCP-Konfiguration? - Tritt der Fehler seit einer Treiber-, Firmware- oder Richtlinienänderung auf? - Sind ältere oder nur neuere WLAN-Geräte betroffen? - Betrifft der Fehler nur ein Benutzerkonto? **Sinnvolle Vergleichsmatrix:** | Vergleich | Erkenntnis | |---|---| | Gleiches Gerät, anderer Standort | Funkzelle oder Standortproblem | | Gleiches Gerät, andere SSID | SSID-, Authentifizierungs- oder VLAN-Problem | | Anderes Gerät, gleiche Position | Client- oder allgemeines Funkproblem | | WLAN gegenüber Ethernet | Funkebene gegenüber allgemeinem Netzwerkproblem | | Betroffener gegenüber funktionierendem Client | Konfigurationsunterschiede | | Nähe zum AP gegenüber Randbereich | Signal-, Störungs- oder Roamingproblem |
---
5. Signalstärke in dBm richtig interpretieren WLAN-Signalstärken werden häufig als negative dBm-Werte angegeben. ```text -45 dBm ist stärker als -75 dBm ``` Eine näher an null liegende Zahl bedeutet ein stärkeres Signal. | RSSI-Beispiel | Grobe praktische Einordnung | |---:|---| | `-30 dBm` | Extrem stark, meist in unmittelbarer Nähe | | `-40 bis -50 dBm` | Sehr stark | | `-50 bis -60 dBm` | Häufig gut für anspruchsvolle Anwendungen | | `-60 bis -67 dBm` | Häufig noch brauchbar bis gut | | `-67 bis -70 dBm` | Je nach Anwendung und Umgebung grenzwertig | | `-70 bis -80 dBm` | Schwach, geringere Datenraten und Wiederholungen wahrscheinlich | | unter `-80 dBm` | Häufig instabil oder nicht mehr sinnvoll nutzbar | Diese Werte sind keine universellen Garantien. Antennen, Clienthardware, Kanalbreite, Störungen, Anwendung und Messverfahren beeinflussen das Ergebnis. **Signal-Rausch-Abstand näherungsweise:** ```text SNR = Signalpegel − Rauschpegel ``` Beispiel: ```text Signal: -60 dBm Rauschen: -90 dBm SNR = 30 dB ``` Ein starkes Signal kann trotzdem schlecht nutzbar sein, wenn das Rauschen oder die Kanalbelegung ebenfalls hoch ist.
---
6. PHY-Rate und tatsächlichen Durchsatz unterscheiden Die angezeigte Verbindungsrate ist eine ausgehandelte Bruttodatenrate und nicht der tatsächlich nutzbare Anwendungsdurchsatz. Abzüge entstehen unter anderem durch: - WLAN-Protokoll-Overhead, - Management- und Kontrollframes, - Verschlüsselung, - gemeinsam genutzte Funkzeit, - Wiederholungen, - Störungen, - Halbduplexbetrieb, - Entfernung, - Kanalbreite, - Anzahl der Spatial Streams, - Leistungsfähigkeit des Clients, - Auslastung des Access Points, - TCP- und Anwendungs-Overhead. **Deshalb gilt:** ```text PHY-Rate 866 Mbit/s ≠ 866 Mbit/s nutzbarer Datendurchsatz ``` Ein Internet-Speedtest misst zusätzlich Internetanschluss, WAN, Testserver und Providerpfad. Zur reinen WLAN-Beurteilung ist ein lokaler Testserver im kabelgebundenen LAN besser geeignet.
---
7. Windows: WLAN-Schnittstelle und Verbindung prüfen **WLAN-Schnittstellen und aktuelle Verbindung:** ```cmd [RO][SENS] netsh wlan show interfaces ``` Typische Angaben: ```text Name Beschreibung GUID Physische Adresse Status SSID BSSID Netzwerktyp Funktyp Authentifizierung Verschlüsselung Kanal Empfangsrate Übertragungsrate Signal Profil ``` **Alle relevanten WLAN-Informationen:** ```cmd [RO][SENS] netsh wlan show all ``` **Windows-Netzwerkadapter:** ```powershell [RO] Get-NetAdapter | Format-Table Name, InterfaceDescription, Status, LinkSpeed, MacAddress ``` **IP-Konfiguration:** ```powershell [RO][SENS] Get-NetIPConfiguration ``` **Adapterstatistik:** ```powershell [RO] Get-NetAdapterStatistics | Format-Table Name, ReceivedBytes, SentBytes, ReceivedDiscardedPackets, OutboundDiscardedPackets, ReceivedPacketErrors, OutboundPacketErrors ``` Paketfehler und verworfene Pakete müssen über einen Zeitraum beziehungsweise im Vergleich zu einem funktionierenden Zustand bewertet werden.
---
8. Windows: sichtbare Netze, BSSIDs und Kanäle prüfen **Sichtbare WLAN-Netze:** ```cmd [RO][SENS] netsh wlan show networks ``` **Sichtbare Netze einschließlich BSSIDs:** ```cmd [RO][SENS] netsh wlan show networks mode=bssid ``` Damit lassen sich unter anderem vergleichen: - SSID, - BSSID, - Signal, - Funktyp, - Kanal, - mehrere Access Points derselben SSID, - Authentifizierungsverfahren, - Verschlüsselungsverfahren. **Wichtige Fragen:** - Ist die gewünschte SSID sichtbar? - Sind mehrere BSSIDs derselben SSID vorhanden? - Mit welcher BSSID ist der Client verbunden? - Ist diese BSSID am Standort sinnvoll? - Verwendet der Client das erwartete Frequenzband? - Befinden sich viele starke Nachbarn auf demselben Kanal? - Wechselt die BSSID während des Fehlers? Ein einfacher Scan ist nur eine Momentaufnahme und erkennt nicht jede Störung oder Auslastung.
---
9. Windows: Treiber und Fähigkeiten prüfen **WLAN-Treiberinformationen:** ```cmd [RO][SENS] netsh wlan show drivers ``` Mögliche Angaben: - Hersteller, - Anbieter, - Datum, - Version, - unterstützte Funktypen, - unterstützte Authentifizierungs- und Verschlüsselungsverfahren, - Treibermodell, - unterstützte WLAN-Funktionen. **Wireless Capabilities:** ```cmd [RO][SENS] netsh wlan show wirelesscapabilities ``` **PowerShell-Treiberinformationen:** ```powershell [RO][SENS] Get-CimInstance Win32_PnPSignedDriver | Where-Object DeviceClass -eq "NET" | Select-Object DeviceName, DriverProviderName, DriverVersion, DriverDate ``` Treiberstände sollten mit der offiziellen Freigabe des Geräte- oder Adapterherstellers verglichen werden. Ein neuerer generischer Treiber ist nicht automatisch besser als der vom Systemhersteller freigegebene Treiber.
---
10. Windows: gespeicherte WLAN-Profile prüfen **Gespeicherte Profile:** ```cmd [RO][SENS] netsh wlan show profiles ``` **Bestimmtes Profil anzeigen:** ```cmd [RO][SENS] netsh wlan show profile name="SSID-ODER-PROFILNAME" ``` Zu kontrollieren sind: - Profilname, - SSID, - Verbindung automatisch oder manuell, - Authentifizierungsverfahren, - Verschlüsselungsverfahren, - Richtlinienquelle, - zufällige Hardwareadresse, - unternehmensweite oder benutzerbezogene Bereitstellung. **Nicht verwenden:** ```text key=clear ``` Dadurch könnte ein gespeicherter WLAN-Schlüssel im Klartext ausgegeben werden. Das ist für eine normale Fehleranalyse nicht erforderlich und darf nicht in Dokumentationen verwendet werden.
---
11. Windows-WLAN-Bericht erstellen **WLAN-Bericht erzeugen:** ```cmd [RO][PRIV][FILE][SENS] netsh wlan show wlanreport ``` Windows zeigt nach der Erstellung den konkreten Speicherort des Berichts an. Dieser Pfad sollte aus der Ausgabe übernommen und nicht angenommen werden. Der Bericht kann unter anderem enthalten: - WLAN-Sitzungen, - Verbindungs- und Trennereignisse, - Adapterinformationen, - Treiberdaten, - Netzwerkprofile, - Fehlerursachen, - Zeitverlauf, - Ereignisse aus relevanten Windows-Protokollen. Der Bericht enthält sensible Netzwerkdaten und muss entsprechend geschützt werden. **WLAN-Ereignisprotokoll prüfen:** ```powershell [RO][PRIV][SENS] Get-WinEvent ` -LogName "Microsoft-Windows-WLAN-AutoConfig/Operational" ` -MaxEvents 100 ``` **Zeitlich begrenzen:** ```powershell [RO][PRIV][SENS] Get-WinEvent ` -FilterHashtable @{ LogName = "Microsoft-Windows-WLAN-AutoConfig/Operational" StartTime = (Get-Date).AddMinutes(-30) } ```
---
12. Linux: WLAN-Schnittstellen und Verbindungsstatus prüfen **Netzwerkgeräte:** ```bash [RO] ip -br link ``` **NetworkManager-Gerätestatus:** ```bash [RO] nmcli device status ``` **Aktive Verbindungen:** ```bash [RO][SENS] nmcli connection show --active ``` **WLAN-Schnittstellen mit iw:** ```bash [RO] iw dev ``` **Aktuelle Verbindung einer bestimmten Schnittstelle:** ```bash [RO][SENS] iw dev wlan0 link ``` `wlan0` muss durch den tatsächlich ermittelten Schnittstellennamen ersetzt werden. Typische Angaben von `iw dev wlan0 link`: ```text BSSID SSID Frequenz RX-Daten TX-Daten Signal RX-Bitrate TX-Bitrate ``` **Stationsinformationen:** ```bash [RO][SENS] iw dev wlan0 station dump ``` Abhängig von Treiber und Betriebsmodus können zusätzliche Werte wie Signal, Bitrate, Wiederholungen und übertragene Daten angezeigt werden.
---
13. Linux: sichtbare Netze und Funkumgebung prüfen **WLAN-Scan mit NetworkManager:** ```bash [TEST][SENS] nmcli device wifi list ``` **Scan für eine bestimmte Schnittstelle:** ```bash [TEST][SENS] nmcli device wifi list ifname wlan0 ``` **Ausgewählte Felder anzeigen:** ```bash [TEST][SENS] nmcli -f IN-USE,SSID,BSSID,MODE,CHAN,FREQ,RATE,SIGNAL,SECURITY \ device wifi list ``` **Regulierungsdomäne prüfen:** ```bash [RO] iw reg get ``` **WLAN-Fähigkeiten des Adapters:** ```bash [RO][SENS] iw list ``` `iw list` kann eine sehr umfangreiche Ausgabe erzeugen. Relevant sind unter anderem: - unterstützte Bänder, - Frequenzen, - Kanalbreiten, - Schnittstellenmodi, - Verschlüsselungsfähigkeiten, - räumliche Streams, - regulatorische Einschränkungen. Die Regulierungsdomäne darf nicht willkürlich verändert werden. Zulässige Kanäle und Sendeleistungen sind landesabhängig reguliert.
---
14. Linux: NetworkManager-Protokolle auswerten **Aktuelle NetworkManager-Protokolle:** ```bash [RO][PRIV][SENS] sudo journalctl -u NetworkManager --since "-30 minutes" ``` **WLAN-bezogene Kernelmeldungen:** ```bash [RO][PRIV][SENS] sudo journalctl -k --since "-30 minutes" | grep -Ei 'wlan|wifi|wireless|80211|firmware' ``` **Treiberzuordnung der Netzwerkschnittstellen:** ```bash [RO][SENS] lspci -k | grep -A 4 -Ei 'network|wireless' ``` Bei USB-WLAN-Adaptern: ```bash [RO][SENS] lsusb ``` Zu suchen sind unter anderem: - Firmware konnte nicht geladen werden, - Authentifizierung fehlgeschlagen, - Verbindung wurde getrennt, - DHCP fehlgeschlagen, - Access Point nicht erreichbar, - regulatorische Einschränkung, - Treiberabsturz, - Energiesparzustand, - Roamingereignis.
---
15. macOS: WLAN-Schnittstelle und Verbindung prüfen **Hardwareports und Gerätenamen anzeigen:** ```bash [RO] networksetup -listallhardwareports ``` Dadurch wird ermittelt, welche Schnittstelle zum WLAN gehört, beispielsweise `en0` oder `en1`. Der Name darf nicht ohne Prüfung vorausgesetzt werden. **Aktuell verbundenes WLAN:** ```bash [RO][SENS] networksetup -getairportnetwork en0 ``` `en0` muss durch die tatsächlich ermittelte WLAN-Schnittstelle ersetzt werden. **Ausführliche WLAN- und Hardwareinformationen:** ```bash [RO][SENS] system_profiler SPAirPortDataType ``` **IP-Konfiguration:** ```bash [RO][SENS] ifconfig en0 ``` **Netzwerkdienstkonfiguration:** ```bash [RO][SENS] networksetup -getinfo "Wi-Fi" ``` `Wi-Fi` muss durch den tatsächlichen Namen des Netzwerkdienstes ersetzt werden.
---
16. macOS: aktuelle WLAN-Diagnoseinformationen prüfen Auf aktuellen macOS-Versionen kann `wdutil` WLAN-Diagnoseinformationen bereitstellen. **Verfügbarkeit und Hilfe prüfen:** ```bash [RO] command -v wdutil ``` ```bash [RO] wdutil help ``` **Aktuelle Diagnoseinformationen, sofern von der installierten Version unterstützt:** ```bash [RO][PRIV][SENS] sudo wdutil info ``` Die verfügbaren Unterbefehle und Ausgaben können sich zwischen macOS-Versionen unterscheiden. Deshalb muss zuerst die lokale Hilfe geprüft werden. Mögliche Informationen sind: - SSID, - BSSID, - Kanal, - Signal, - Rauschpegel, - Übertragungsrate, - Sicherheitsverfahren, - Schnittstelle. Ältere Anleitungen verwenden häufig das interne `airport`-Werkzeug. Dessen Verfügbarkeit und Verhalten ist auf aktuellen macOS-Versionen nicht zuverlässig vorauszusetzen; deshalb wird es hier nicht als Standardbefehl verwendet.
---
17. macOS Wireless Diagnostics verwenden Apple stellt die grafische Anwendung „Diagnose für drahtlose Umgebungen“ beziehungsweise „Wireless Diagnostics“ bereit. **Aufruf:** 1. Mit dem problematischen WLAN verbinden, soweit möglich. 2. Wahltaste beziehungsweise `Option` gedrückt halten. 3. Auf das WLAN-Symbol in der Menüleiste klicken. 4. „Diagnose für drahtlose Umgebungen öffnen“ auswählen. 5. Den Anweisungen folgen. Apple gibt an, dass die Diagnose selbst die Netzwerkeinstellungen nicht verändert. Die Diagnose kann ein komprimiertes Archiv erzeugen. Apple dokumentiert dafür: ```text /var/tmp ``` Der Dateiname beginnt mit: ```text WirelessDiagnostics ``` und endet mit: ```text .tar.gz ``` Das Archiv kann umfangreiche und sensible System- und Netzwerkdaten enthalten und darf nur geschützt weitergegeben werden.
---
18. Frequenzbänder praktisch unterscheiden | Eigenschaft | 2,4 GHz | 5 GHz | 6 GHz | |---|---|---|---| | Reichweite | Häufig größer | Häufig geringer als 2,4 GHz | Häufig stärker durch Entfernung und Hindernisse beeinflusst | | Kanalkapazität | Begrenzter | Mehr verfügbare Kanalressourcen | Große zusätzliche Frequenzressourcen | | Störquellen | Viele WLAN- und Nicht-WLAN-Geräte | Häufig weniger Nicht-WLAN-Störungen | Abhängig von regionaler Freigabe und Nutzung | | Wanddurchdringung | Häufig günstiger | Häufig geringer | Häufig geringer | | Geräteunterstützung | Sehr weit verbreitet | Weit verbreitet | Nur geeignete neuere Geräte | | Kanalbreiten | Häufig 20 oder 40 MHz | Häufig 20 bis 160 MHz | Abhängig von Standard und Gerät auch sehr breite Kanäle | Die tatsächlich nutzbaren Frequenzen und Kanalbreiten hängen von Land, Gerät, Treiber, Access Point und WLAN-Standard ab. **Typischer Zielkonflikt:** ```text Breitere Kanäle → potenziell höhere Datenrate → benötigen mehr Frequenzspektrum → höhere Wahrscheinlichkeit von Überlappungen oder Störungen ```
---
19. Kanalbelegung und Störungen beurteilen Ein WLAN-Kanal ist ein gemeinsam genutztes Medium. Alle Geräte auf demselben oder überlappenden Kanal teilen sich die verfügbare Funkzeit. Mögliche Störquellen: - benachbarte WLANs, - Bluetooth, - Mikrowellengeräte, - Funkkameras, - drahtlose Audio- oder Videoübertragung, - USB-3-Geräte und schlecht abgeschirmte Kabel im 2,4-GHz-Umfeld, - Radarerkennung auf DFS-Kanälen, - defekte oder stark sendende Geräte, - sehr breite Kanalbelegung, - versteckte Stationen. **Co-Channel-Interference:** Mehrere WLANs verwenden denselben Kanal und müssen sich die Funkzeit teilen. **Adjacent-Channel-Interference:** Überlappende Kanäle beeinflussen sich, ohne sauber koordiniert zu werden. Im 2,4-GHz-Band werden bei 20-MHz-Kanalbreite häufig überlappungsarme Planungen verwendet. Welche Kanäle zulässig und sinnvoll sind, hängt von der regionalen Regulierung und dem vorhandenen Kanalplan ab. Ein Scan zeigt andere WLANs, aber nicht zuverlässig alle Nicht-WLAN-Störquellen. Dafür kann ein geeigneter Spektrumanalysator erforderlich sein.
---
20. DFS-Ereignisse berücksichtigen Bestimmte 5-GHz-Kanäle unterliegen Dynamic Frequency Selection. Erkennt ein Access Point ein relevantes Radarsignal, kann er den Kanal wechseln oder die Aussendung vorübergehend einstellen. **Mögliche Symptome:** - WLAN verschwindet kurzfristig, - Clients werden gleichzeitig getrennt, - Access Point wechselt den Kanal, - nur bestimmte 5-GHz-Kanäle sind betroffen, - Verbindung kehrt nach einer Wartezeit zurück, - Ereignis tritt standortabhängig auf. Zu prüfen sind: - Access-Point-Ereignisprotokolle, - Controllerereignisse, - Kanalverlauf, - DFS- beziehungsweise Radarereignisse, - automatischer Kanalwechsel, - Clientunterstützung des neuen Kanals. DFS darf nicht pauschal als Fehler betrachtet werden. Es handelt sich um eine regulatorisch vorgesehene Schutzfunktion.
---
21. Authentifizierung und Verschlüsselung prüfen Mögliche WLAN-Sicherheitsverfahren: - WPA2-Personal, - WPA3-Personal, - WPA2-Enterprise, - WPA3-Enterprise, - Übergangsmodi, - 802.1X/EAP, - Enhanced Open beziehungsweise OWE, - offene Gastnetze mit Captive Portal. Zu kontrollieren sind: - unterstützt der Client das Verfahren, - stimmt das Kennwort, - wird ein altes Profil verwendet, - ist WPA3 erforderlich oder optional, - ist Protected Management Frames erforderlich, - funktioniert die 802.1X-Authentifizierung, - ist das Serverzertifikat vertrauenswürdig, - stimmt der Servername im Zertifikat, - ist das Benutzer- oder Gerätezertifikat gültig, - ist das Benutzerkonto gesperrt, - ist das Gerät durch Richtlinie zugelassen, - ist die Systemzeit korrekt. **Systemzeit:** | Betriebssystem | Befehl | |---|---| | Windows | `[RO] Get-Date -Format o` | | Linux | `[RO] date --iso-8601=seconds` | | macOS | `[RO] date "+%Y-%m-%dT%H:%M:%S%z"` | Bei Zertifikats- und Kerberos-basierten Verfahren kann eine falsche Systemzeit die Anmeldung verhindern.
---
22. 802.1X- und Enterprise-WLAN eingrenzen Ein Enterprise-WLAN kann mehrere Komponenten enthalten: ```text WLAN-Client ↓ Access Point ↓ WLAN-Controller ↓ RADIUS-Server ↓ Identitätsdienst ↓ VLAN- und Zugriffsrichtlinie ``` Zu dokumentieren sind: - Benutzer- oder Geräteauthentifizierung, - EAP-Verfahren, - Zertifikatsaussteller, - Identität beziehungsweise anonyme Identität, - RADIUS-Antwort, - zugewiesenes VLAN, - angewendete Rolle, - Access-Control-List, - Zeitpunkt, - Access Point und BSSID. **Typische Fehler:** | Beobachtung | Mögliche Ursache | |---|---| | Kennwortabfrage wiederholt sich | Zugangsdaten, EAP oder Zertifikatsprüfung | | Zertifikatswarnung | Vertrauenskette oder Serveridentität | | Verbindung hergestellt, falsches Netz | Dynamische VLAN-Zuweisung oder Richtlinie | | Nur Gerätetunnel vor Anmeldung fehlt | Computerzertifikat oder Geräteauthentifizierung | | Benutzer funktioniert auf anderem Gerät | Gerätezertifikat, Profil oder Gerätekonformität | | Alle Benutzer an einem AP betroffen | AP-, Controller- oder Netzwerkpfad zum RADIUS | Client-, Controller- und RADIUS-Protokolle müssen zeitlich miteinander verglichen werden.
---
23. Nach der WLAN-Verbindung DHCP prüfen **Windows:** ```powershell [RO][SENS] Get-NetIPConfiguration ``` ```cmd [RO][SENS] ipconfig /all ``` **Linux:** ```bash [RO][SENS] ip -br address ``` ```bash [RO] ip route show ``` **macOS:** ```bash [RO][SENS] networksetup -getinfo "Wi-Fi" ``` ```bash [RO][SENS] ifconfig en0 ``` Zu kontrollieren sind: - gültige IP-Adresse, - Präfix beziehungsweise Subnetzmaske, - Standardgateway, - DHCP-Server, - DNS-Server, - Lease-Zeit, - richtige VLAN-Zuweisung, - IPv4- und IPv6-Konfiguration. **Typisches Fehlerbild:** ```text WLAN-Authentifizierung erfolgreich ↓ Client wird dem falschen VLAN zugeordnet ↓ DHCP-Server nicht erreichbar oder falscher Adressbereich ↓ Kein nutzbarer Netzwerkzugang ``` Eine IPv4-Adresse aus `169.254.0.0/16` weist häufig darauf hin, dass keine reguläre IPv4-DHCP-Zuweisung erfolgt ist.
---
24. Gateway, DNS und Internet getrennt testen **Stufe 1 – eigene IP-Konfiguration prüfen** ```text IP-Adresse Subnetzmaske beziehungsweise Präfix Standardgateway DNS-Server ``` **Stufe 2 – Standardgateway testen** Windows: ```powershell [TEST] Test-Connection GATEWAY_IP -Count 4 ``` Linux und macOS: ```bash [TEST] ping -c 4 GATEWAY_IP ``` **Stufe 3 – externe IP-Adresse testen:** Windows: ```powershell [TEST] Test-NetConnection 1.1.1.1 -Port 443 ``` Linux und macOS: ```bash [TEST] nc -vz -w 5 1.1.1.1 443 ``` **Stufe 4 – DNS-Auflösung testen** Windows: ```powershell [TEST] Resolve-DnsName example.com ``` Linux und macOS: ```bash [TEST] dig example.com ``` **Stufe 5 – Anwendung testen** ```bash [TEST] curl -I https://example.com/ ``` Öffentliche Testziele dürfen nur verwendet werden, wenn dies durch die betrieblichen Richtlinien erlaubt ist.
---
25. Captive Portal erkennen Gast-, Hotel- und öffentliche WLANs verlangen häufig eine browserbasierte Freischaltung. **Typische Symptome:** - WLAN ist verbunden, - IP-Adresse und Gateway sind vorhanden, - Internetzugriff funktioniert nicht, - Browser wird auf eine Anmeldeseite umgeleitet, - HTTPS-Seiten zeigen Fehler, - VPN-Verbindung kann nicht aufgebaut werden, - DNS-Antworten werden verändert. Zu prüfen sind: - wurde die Nutzungsseite vollständig bestätigt, - ist die Sitzung abgelaufen, - wurde das Gerät anhand seiner MAC-Adresse registriert, - verwendet der Client eine zufällige MAC-Adresse, - blockiert ein VPN oder Proxy die Portalerkennung, - ist die Systemzeit korrekt, - wurde die maximal zulässige Gerätezahl erreicht? Zertifikatswarnungen auf HTTPS-Seiten dürfen nicht einfach bestätigt werden. Für die Portalanmeldung sollte die vom Betreiber vorgesehene sichere Methode verwendet werden.
---
26. Zufällige MAC-Adressen berücksichtigen Moderne Betriebssysteme können pro WLAN eine private beziehungsweise zufällige MAC-Adresse verwenden. Das kann folgende Auswirkungen haben: - DHCP vergibt eine neue Adresse, - Captive Portal erkennt ein neues Gerät, - MAC-basierte Freigabe greift nicht, - NAC behandelt das Gerät als unbekannt, - Gerät erscheint mehrfach im Controller, - statische DHCP-Reservierung passt nicht, - Inventarisierung wird erschwert. **Windows-Status anzeigen:** ```cmd [RO][SENS] netsh wlan show randomization ``` **Windows-Schnittstellenadresse:** ```powershell [RO] Get-NetAdapter | Format-Table Name, MacAddress, Status ``` **Linux:** ```bash [RO] ip link show ``` **macOS:** ```bash [RO] ifconfig en0 ``` Die aktuelle Schnittstellenadresse allein zeigt nicht zwingend, ob und nach welchem Verfahren sie für ein bestimmtes WLAN erzeugt wurde. Die Einstellung sollte zusätzlich in der WLAN-Konfiguration des Betriebssystems geprüft werden. Private MAC-Adressen dürfen nicht pauschal deaktiviert werden. Ihre Nutzung ist eine Datenschutz- und Netzwerkdesignentscheidung.
---
27. Roamingprobleme analysieren Beim Roaming entscheidet der Client normalerweise selbst, wann er zu einer anderen Funkzelle wechselt. Access Points und Controller können diese Entscheidung unterstützen oder beeinflussen. **Typische Symptome:** - Verbindung bricht beim Wechsel zwischen Räumen ab, - Sprach- oder Videokonferenz stockt beim Laufen, - Client bleibt an einem weit entfernten Access Point hängen, - BSSID wechselt häufig hin und her, - Problem tritt nur bei bestimmten Clientmodellen auf, - Anmeldung wird bei jedem AP-Wechsel wiederholt, - IP-Adresse ändert sich beim Roaming. Zu dokumentieren sind: - SSID, - alte BSSID, - neue BSSID, - Kanal und Band, - Signal vor dem Wechsel, - Signal nach dem Wechsel, - Zeitpunkt und Dauer der Unterbrechung, - zugewiesenes VLAN, - IP-Adresse vor und nach dem Wechsel, - unterstützte Roamingfunktionen, - Clienttreiber und Firmware. **Wichtige Standards und Funktionen:** | Funktion | Aufgabe | |---|---| | 802.11k | Informationen über benachbarte Funkzellen | | 802.11v | Unterstützung bei Netzwerkauswahl und Übergängen | | 802.11r | Beschleunigte Übergänge zwischen Access Points | | PMK-Caching | Wiederverwendung bestimmter Authentifizierungsinformationen | Unterstützung und Verhalten hängen von Client, Access Point, Sicherheitsverfahren und Konfiguration ab.
---
28. Sticky Clients und Ping-Pong-Roaming erkennen **Sticky Client:** ```text Client bleibt mit schwacher BSSID verbunden obwohl eine nähere BSSID verfügbar ist ``` Mögliche Ursachen: - Roamingentscheidung des Clients, - Treibereinstellung, - Sendeleistung der Access Points, - ungünstige Zellüberlappung, - fehlende beziehungsweise inkompatible Roamingunterstützung, - zu niedrige Datenraten weiterhin erlaubt. **Ping-Pong-Roaming:** ```text Client wechselt wiederholt zwischen zwei BSSIDs ``` Mögliche Ursachen: - ähnliche Signalstärke, - schwankende Funkbedingungen, - ungeeignete Schwellenwerte, - übermäßige Zellüberlappung, - Band-Steering-Konflikte, - Clienttreiber. Ein erzwungenes Trennen des Clients kann kurzfristig helfen, beweist aber keine nachhaltige Fehlerbehebung.
---
29. Energiesparfunktionen berücksichtigen WLAN-Adapter und Betriebssysteme können die Funkhardware zum Energiesparen in reduzierte Betriebszustände versetzen. **Typische Symptome:** - Verbindung bricht im Akkubetrieb ab, - nach Standby kein Netzwerkzugang, - hoher erster Paketverlust nach Inaktivität, - Verbindung ist nach Deaktivieren und Aktivieren des Adapters wieder vorhanden, - Problem tritt nur bei bestimmten Energiesparprofilen auf. **Windows-Energiezustände:** ```powershell [RO] powercfg /getactivescheme ``` **Windows-WLAN-Bericht:** ```cmd [RO][PRIV][FILE][SENS] netsh wlan show wlanreport ``` **Linux:** ```bash [RO] iw dev wlan0 get power_save ``` Nicht jeder Treiber unterstützt dieselbe Abfrage. **macOS:** ```bash [RO] pmset -g ``` Energiesparfunktionen sollten nicht dauerhaft deaktiviert werden, bevor Treiber, Firmware und das konkrete Fehlerbild geprüft wurden.
---
30. Paketverlust und Latenz lokal messen Zuerst wird das lokale Standardgateway getestet. Dadurch bleiben Internetprovider und externe Netze zunächst außerhalb der Messung. **Windows:** ```powershell [TEST] Test-Connection GATEWAY_IP -Count 50 ``` Alternativ: ```cmd [TEST] ping -n 50 GATEWAY_IP ``` **Linux und macOS:** ```bash [TEST] ping -c 50 GATEWAY_IP ``` Zu bewerten sind: - Paketverlust, - minimale Latenz, - durchschnittliche Latenz, - maximale Latenz, - starke Schwankungen, - zeitlicher Zusammenhang mit Bewegung oder Last. **Wichtig:** Access Points oder Gateways können ICMP niedriger priorisieren. Ein Ping-Test ist deshalb ein Hinweis, aber keine vollständige Qualitätsmessung.
---
31. Durchsatz im lokalen Netz mit iperf3 testen Ein lokaler kabelgebundener `iperf3`-Server hilft, WLAN und Internetanschluss voneinander zu trennen. **Auf dem autorisierten kabelgebundenen Testserver:** ```bash [TEST] iperf3 -s ``` **Auf dem WLAN-Client:** ```bash [TEST] iperf3 -c SERVER_IP ``` **Gegenrichtung testen:** ```bash [TEST] iperf3 -c SERVER_IP -R ``` **Bestimmte Testdauer:** ```bash [TEST] iperf3 -c SERVER_IP -t 30 ``` **UDP-Test mit begrenzter Zielrate:** ```bash [TEST] iperf3 -c SERVER_IP -u -b 20M -t 30 ``` UDP-Tests erzeugen gezielt Last und müssen mit einer angemessenen Bandbreite begonnen werden. Zu dokumentieren sind: - Standort des Clients, - SSID und BSSID, - Frequenzband, - Kanal, - Signal, - PHY-Rate, - TCP-Durchsatz in beide Richtungen, - UDP-Verlust und Jitter, - Anzahl paralleler Clients, - Uhrzeit.
---
32. Internet-Speedtest nicht mit WLAN-Messung verwechseln Ein Internet-Speedtest umfasst: ```text WLAN + lokales LAN + Router + Firewall + Internetanschluss + Provider + Routing zum Testserver + Testserver ``` Ein schlechtes Ergebnis kann daher auch bei einem fehlerfreien WLAN entstehen. **Empfohlene Reihenfolge:** 1. WLAN-Signal und Verbindungsparameter prüfen. 2. Lokales Gateway testen. 3. Lokalen kabelgebundenen `iperf3`-Server testen. 4. Erst danach Internetdurchsatz messen. 5. WLAN- und Ethernetmessung zum selben Ziel vergleichen. 6. Messung zu mehreren Zeitpunkten wiederholen. Die Aussage „WLAN liefert nur 50 Mbit/s“ ist ohne lokalen Vergleich nicht ausreichend belegt.
---
33. Airtime und hohe Clientdichte berücksichtigen WLAN ist ein geteiltes Medium. Auch langsam sendende Clients verbrauchen Funkzeit. Mögliche Ursachen hoher Airtime-Auslastung: - viele aktive Clients, - langsame oder weit entfernte Clients, - viele Wiederholungen, - niedrige Basisdatenraten, - Broadcast- und Multicastverkehr, - breite Kanäle mit Störungen, - Legacy-Geräte, - hohe Datenübertragungen, - mehrere SSIDs mit Management-Overhead, - schlecht platzierte Access Points. **Typische Symptome:** - starkes Signal, aber geringer Durchsatz, - hohe Latenz unter Last, - Problem nur zu bestimmten Uhrzeiten, - alle Clients einer Funkzelle betroffen, - andere Funkzellen funktionieren, - viele Wiederholungen und wechselnde Datenraten. Für eine zuverlässige Bewertung werden Controllerstatistiken oder geeignete WLAN-Analysewerkzeuge benötigt.
---
34. Access Point, Switch und VLAN gemeinsam prüfen Ein Access Point benötigt selbst eine funktionierende kabelgebundene Infrastruktur. Zu prüfen sind: - AP-Stromversorgung beziehungsweise PoE, - Ethernet-Link, - Linkgeschwindigkeit, - Switchportfehler, - VLAN-Trunk, - native beziehungsweise untagged VLAN-Zuweisung, - Management-VLAN, - SSID-zu-VLAN-Zuordnung, - DHCP-Relay, - Controllererreichbarkeit, - AP-Firmware, - Uplink-Auslastung. **Typisches Fehlerbild:** ```text Client verbindet sich erfolgreich mit SSID ↓ Access Point ordnet Client falschem VLAN zu ↓ Client erhält keine oder falsche IP-Konfiguration ``` **Switchportzähler beachten:** - CRC-Fehler, - Drops, - Duplexprobleme, - Link-Flaps, - PoE-Unterbrechungen, - Port-Security-Ereignisse, - Spanning-Tree-Ereignisse. Ein scheinbares Funkproblem kann tatsächlich auf dem kabelgebundenen AP-Uplink entstehen.
---
35. Mesh- und Repeater-Probleme erkennen Bei Mesh-Systemen und Repeatern wird Verkehr zusätzlich über einen drahtlosen oder kabelgebundenen Backhaul übertragen. ```text Client ↓ WLAN Mesh-Knoten oder Repeater ↓ Backhaul Haupt-Access-Point ↓ LAN Ziel ``` Zu prüfen sind: - Qualität des Clientlinks, - Qualität des Backhauls, - kabelgebundener oder drahtloser Backhaul, - verwendetes Frequenzband, - mehrere Funkübertragungen desselben Datenpakets, - Position des Repeaters, - Roaming zwischen Hauptgerät und Repeater, - Kanalplanung, - Uplink-Auslastung, - Firmwarestand. Ein Repeater mit starkem Signal zum Client kann trotzdem eine schlechte Gesamtverbindung liefern, wenn sein eigener Uplink schwach ist.
---
36. Versteckte SSIDs und Netzwerkprofile beurteilen Eine versteckte SSID verbessert die Verschlüsselung nicht. Clients müssen möglicherweise aktiv nach dem bekannten Netz suchen. Mögliche Nachteile: - erschwerte Diagnose, - zusätzliche Probe Requests, - Verbindungsprobleme bei fehlerhaftem Profil, - Datenschutzprobleme durch aktive Suche, - nicht einheitliches Verhalten verschiedener Clients. Zu prüfen sind: - SSID exakt geschrieben, - Sicherheitsverfahren korrekt, - Netzwerkprofil aktuell, - automatische Verbindung vorgesehen, - Richtlinienprofil vorhanden, - Access Point sendet die erwartete Konfiguration. Das Löschen und Neuerstellen eines Profils ist eine Änderung. Vorher sollten Profilquelle, Unternehmensrichtlinie und Zugangsdaten geklärt werden.
---
37. Keine vorschnellen WLAN-Änderungen durchführen Nicht unkontrolliert: - WLAN-Profil löschen, - Kennwort im Klartext exportieren, - Access Point neu starten, - Kanal oder Kanalbreite beliebig ändern, - Regulierungsdomäne verändern, - Sendeleistung maximieren, - WPA3 oder 802.1X deaktivieren, - Zertifikatsprüfung umgehen, - private MAC-Adresse pauschal deaktivieren, - Treiber ungeprüft ersetzen, - Controllerkonfiguration ändern, - Roamingfunktionen abschalten, - Funknetz während der Geschäftszeit neu planen. **Sicherer Ablauf:** 1. Istzustand und Standort dokumentieren. 2. SSID, BSSID, Kanal, Band und Signal erfassen. 3. Fehler reproduzieren. 4. Client und Vergleichsgerät prüfen. 5. Authentifizierung und VLAN-Zuweisung kontrollieren. 6. DHCP, Gateway und DNS testen. 7. Lokalen Durchsatz messen. 8. Client-, AP-, Controller- und RADIUS-Protokolle vergleichen. 9. Ursache nachweisen. 10. Änderung genehmigen lassen. 11. Auswirkung auf andere Funkzellen und Clients berücksichtigen. 12. Nachprüfung am ursprünglichen Fehlerort durchführen.
---
38. Systematischer Diagnoseablauf | Schritt | Prüfung | Leitfrage | |---:|---|---| | 1 | Störungsumfang bestimmen | Client, Standort, BSSID, SSID oder gesamtes WLAN? | | 2 | Hardwarestatus prüfen | Wird der WLAN-Adapter korrekt erkannt? | | 3 | Treiber und Fähigkeiten prüfen | Unterstützt der Client Band und Sicherheitsverfahren? | | 4 | Funkumgebung erfassen | Ist die SSID sichtbar und wie stark ist das Signal? | | 5 | BSSID und Kanal dokumentieren | Mit welcher Funkzelle ist der Client verbunden? | | 6 | Authentifizierung prüfen | Wird Personal- oder Enterprise-Anmeldung akzeptiert? | | 7 | VLAN-Zuweisung prüfen | Landet der Client im vorgesehenen Netz? | | 8 | IP-Konfiguration prüfen | Sind Adresse, Gateway und DNS korrekt? | | 9 | Gateway testen | Funktioniert der lokale Netzwerkpfad? | | 10 | DNS testen | Werden Namen korrekt aufgelöst? | | 11 | Anwendung testen | Funktioniert der tatsächlich benötigte Dienst? | | 12 | Paketverlust messen | Ist die Funkverbindung stabil? | | 13 | Lokalen Durchsatz messen | Welche Leistung liefert nur das WLAN? | | 14 | Roaming prüfen | Tritt der Fehler beim BSSID-Wechsel auf? | | 15 | Kanal und Auslastung prüfen | Ist die Funkzelle gestört oder überlastet? | | 16 | AP-Uplink prüfen | Funktioniert die kabelgebundene Infrastruktur? | | 17 | Protokolle vergleichen | Welche Komponente lehnt ab oder trennt? | | 18 | Minimale Änderung planen | Welche konkrete Korrektur stellt den Sollzustand her? | | 19 | Nachprüfung | Funktioniert es am ursprünglichen Standort unter Last? | | 20 | Dokumentation | Sind Ursache, Messwerte und Änderung festgehalten? |
---
39. Kompakte Befehlstabelle | Aufgabe | Windows | Linux | macOS | |---|---|---|---| | WLAN-Verbindungsstatus | `[RO][SENS] netsh wlan show interfaces` | `[RO][SENS] iw dev wlan0 link` | `[RO][SENS] networksetup -getairportnetwork en0` | | Netzwerkschnittstellen | `[RO] Get-NetAdapter` | `[RO] ip -br link` | `[RO] networksetup -listallhardwareports` | | Sichtbare WLANs | `[RO][SENS] netsh wlan show networks mode=bssid` | `[TEST][SENS] nmcli device wifi list` | Wireless Diagnostics beziehungsweise `[RO][PRIV][SENS] sudo wdutil info`, falls unterstützt | | WLAN-Treiber | `[RO][SENS] netsh wlan show drivers` | `[RO][SENS] lspci -k` beziehungsweise `[RO][SENS] lsusb` | `[RO][SENS] system_profiler SPAirPortDataType` | | WLAN-Fähigkeiten | `[RO][SENS] netsh wlan show wirelesscapabilities` | `[RO][SENS] iw list` | `[RO][SENS] system_profiler SPAirPortDataType` | | Gespeicherte Profile | `[RO][SENS] netsh wlan show profiles` | `[RO][SENS] nmcli connection show` | Über WLAN-Einstellungen beziehungsweise MDM prüfen | | IP-Konfiguration | `[RO][SENS] Get-NetIPConfiguration` | `[RO][SENS] ip -br address` | `[RO][SENS] networksetup -getinfo "Wi-Fi"` | | Standardroute | `[RO] Get-NetRoute -DestinationPrefix "0.0.0.0/0"` | `[RO] ip route show default` | `[RO] route -n get default` | | DNS-Konfiguration | `[RO][SENS] Get-DnsClientServerAddress` | `[RO][SENS] resolvectl status` | `[RO][SENS] scutil --dns` | | Adapterstatistik | `[RO] Get-NetAdapterStatistics` | `[RO][SENS] iw dev wlan0 station dump` | Abhängig von macOS-Version: `wdutil` prüfen | | WLAN-Protokoll | `[RO][PRIV][SENS] Get-WinEvent -LogName "Microsoft-Windows-WLAN-AutoConfig/Operational"` | `[RO][PRIV][SENS] sudo journalctl -u NetworkManager` | Wireless Diagnostics | | WLAN-Bericht | `[RO][PRIV][FILE][SENS] netsh wlan show wlanreport` | Protokolle und Befehlsausgaben getrennt sichern | Wireless Diagnostics erzeugt Diagnosearchiv | | Gatewaytest | `[TEST] Test-Connection GATEWAY_IP -Count 20` | `[TEST] ping -c 20 GATEWAY_IP` | `[TEST] ping -c 20 GATEWAY_IP` | | Lokaler Durchsatz | `[TEST] iperf3 -c SERVER_IP` | `[TEST] iperf3 -c SERVER_IP` | `[TEST] iperf3 -c SERVER_IP` | `wlan0`, `en0`, `Wi-Fi`, `GATEWAY_IP` und `SERVER_IP` müssen durch die tatsächlich ermittelten Werte ersetzt werden.
---
40. Dokumentationsvorlage für WLAN-Fehler ```text Störung: Zeitpunkt: Zeitzone: Standort: Raum beziehungsweise Bereich: Benutzer: Client: Betriebssystem: WLAN-Adapter: Treiberversion: SSID: BSSID: Access Point: Frequenzband: Frequenz: Kanal: Kanalbreite: WLAN-Standard: Signal beziehungsweise RSSI: Rauschpegel: SNR: TX-PHY-Rate: RX-PHY-Rate: Sicherheitsverfahren: Authentifizierung erfolgreich: 802.1X-Verfahren: RADIUS-Ergebnis: Zugewiesenes VLAN: Client-IP-Adresse: Präfix: Standardgateway: DHCP-Server: DNS-Server: IPv6-Konfiguration: Gatewaytest: Paketverlust: Latenz: DNS-Test: Anwendungstest: Lokaler iperf3-Test: Internettest: Captive Portal: Private MAC-Adresse: Alte BSSID vor Roaming: Neue BSSID nach Roaming: Unterbrechungsdauer: Roamingzeitpunkt: Vergleichsgerät: Vergleich an anderem Standort: Vergleich über Ethernet: Andere Clients betroffen: Andere SSIDs betroffen: Access-Point-Protokoll: Controllerprotokoll: RADIUS-Protokoll: Switchportstatus: PoE-Status: Uplinkfehler: DFS-Ereignis: Kanalauslastung: Festgestellte Ursache: Genehmigte Änderung: Rückfallplan: Ergebnis der Nachprüfung: ```
---
41. Kontrollfragen nach der Diagnose - Ist nur ein Client, Standort, Access Point oder die gesamte SSID betroffen? - Wird der WLAN-Adapter fehlerfrei erkannt? - Unterstützt der Client das verwendete Band und Sicherheitsverfahren? - Ist die gewünschte SSID sichtbar? - Mit welcher BSSID ist der Client verbunden? - Stimmen Frequenzband, Kanal und Kanalbreite? - Wie hoch sind Signal, Rauschen und SNR? - Ist die angezeigte PHY-Rate plausibel? - Wird die Authentifizierung erfolgreich abgeschlossen? - Ist bei Enterprise-WLAN das Zertifikat gültig? - Wird das vorgesehene VLAN zugewiesen? - Erhält der Client eine gültige IP-Konfiguration? - Ist das Standardgateway erreichbar? - Funktioniert DNS? - Funktioniert die Anwendung über IP-Adresse und Hostname? - Tritt Paketverlust bereits zum lokalen Gateway auf? - Wurde der lokale Durchsatz unabhängig vom Internet gemessen? - Tritt der Fehler nur bei hoher Auslastung auf? - Tritt er beim Wechsel der BSSID auf? - Bleibt der Client an einer weit entfernten BSSID hängen? - Wurden DFS- und Kanalwechselereignisse geprüft? - Ist der kabelgebundene Uplink des Access Points fehlerfrei? - Wurden Client-, AP-, Controller- und RADIUS-Protokolle zeitlich verglichen? - Wurde die Ursache vor einer Kanal-, Profil- oder Sicherheitsänderung nachgewiesen? - Wurde nach der Änderung am ursprünglichen Fehlerort erneut gemessen?
---
42. Quellen und weiterführende Dokumentation - Microsoft Learn – `netsh wlan`: https://learn.microsoft.com/windows-server/administration/windows-commands/netsh-wlan - Microsoft Support – WLAN-Bericht unter Windows analysieren: https://support.microsoft.com/windows/analyze-the-wireless-network-report-76da0daa-1db2-6049-d154-7bb679eb03ed - Microsoft Learn – WLAN-AutoConfig-Dienst: https://learn.microsoft.com/windows-server/networking/technologies/extensible-authentication-protocol/network-access - Linux Wireless Documentation – `iw`: https://wireless.docs.kernel.org/en/latest/en/users/documentation/iw.html - NetworkManager – `nmcli`: https://networkmanager.dev/docs/api/latest/nmcli.html - NetworkManager – WLAN-Einstellungen: https://networkmanager.dev/docs/api/latest/settings-802-11-wireless.html - Apple – Diagnose für drahtlose Umgebungen verwenden: https://support.apple.com/de-de/guide/mac-help/mchlf4de377f/mac - Apple – Wenn der Mac keine WLAN-Internetverbindung herstellt: https://support.apple.com/de-de/101588 - Apple – `networksetup` in Remote Desktop: https://support.apple.com/de-de/guide/remote-desktop/apdd0c5a2d5/mac - Wi-Fi Alliance – Discover Wi-Fi: https://www.wi-fi.org/discover-wi-fi - IEEE 802.11 Working Group: https://www.ieee802.org/11/ - RFC 5416 – CAPWAP Protocol Binding for IEEE 802.11: https://www.rfc-editor.org/rfc/rfc5416.html - iPerf3 – Offizielle Dokumentation: https://software.es.net/iperf/
# 3.15 Paketverlust, Latenz, Jitter und Bandbreite analysieren Netzwerkleistung besteht aus mehreren voneinander unabhängigen Messgrößen. Eine Verbindung kann einen hohen Durchsatz erreichen und trotzdem für Sprache, Remotezugriff oder Echtzeitanwendungen ungeeignet sein. Umgekehrt kann eine Verbindung mit begrenzter Bandbreite sehr stabil und reaktionsschnell arbeiten. Die zentralen Fragen dieser Seite lauten: > An welchem Abschnitt des Datenpfads verschlechtert sich die Verbindung, welche Messgröße ist betroffen und tritt das Problem dauerhaft oder nur unter Last auf? ---
1. Sicherheits- und Aktionskennzeichnungen | Kennzeichnung | Bedeutung | |---|---| | `[RO]` | Rein lesender Befehl, der normalerweise keine Konfiguration verändert | | `[TEST]` | Aktiver Test, der Netzwerkverkehr erzeugt | | `[PRIV]` | Administrator- oder Root-Rechte können erforderlich sein | | `[FILE]` | Der Befehl schreibt Ausgaben in eine Datei | | `[SENS]` | Die Ausgabe kann sensible Informationen enthalten | | `[CHANGE]` | Der Befehl verändert eine Konfiguration | | `[DISRUPT]` | Der Befehl kann eine Verbindung oder einen Dienst beeinträchtigen | Bandbreiten- und Lasttests dürfen nur gegen ausdrücklich freigegebene Systeme durchgeführt werden. Sie können Leitungen, Firewalls, Server und andere Benutzer erheblich belasten.
---
2. Die wichtigsten Leistungsbegriffe unterscheiden | Begriff | Bedeutung | |---|---| | Latenz | Zeit, die eine Übertragung von einem Punkt zu einem anderen benötigt | | Round-Trip Time – RTT | Zeit für Hin- und Rückweg | | Jitter | Schwankung der Paketlaufzeit | | Paketverlust | Anteil gesendeter Pakete, die das Ziel beziehungsweise die Messstelle nicht erreichen | | Bandbreite | Theoretische oder konfigurierte Übertragungskapazität | | Durchsatz | Tatsächlich übertragene Datenmenge pro Zeit | | Goodput | Für die Anwendung nutzbare Datenmenge ohne Protokoll- und Wiederholungsdaten | | Retransmission | Erneute Übertragung verlorener oder nicht bestätigter TCP-Daten | | Congestion | Überlastung eines Netzwerkpfads oder einer Warteschlange | | Bufferbloat | Stark steigende Latenz durch übermäßig gefüllte Warteschlangen | | Burst Loss | Mehrere Paketverluste in kurzer Folge | | Out-of-Order | Pakete treffen in anderer Reihenfolge ein | | Duplication | Pakete treffen mehrfach ein | | Queueing Delay | Verzögerung durch Warteschlangen | | Serialization Delay | Zeit, um ein Paket auf einen Link zu übertragen | | Processing Delay | Verarbeitungszeit in einem Netzwerkgerät | | Propagation Delay | Physikalische Signallaufzeit über das Medium |
---
3. Bit, Byte und Übertragungsraten richtig umrechnen ```text 1 Byte = 8 Bit ``` | Einheit | Bedeutung | |---|---:| | `1 kbit/s` | üblicherweise 1.000 Bit pro Sekunde | | `1 Mbit/s` | üblicherweise 1.000.000 Bit pro Sekunde | | `1 Gbit/s` | üblicherweise 1.000.000.000 Bit pro Sekunde | | `1 MB/s` | 8 Mbit/s | | `100 MB/s` | 800 Mbit/s | | `125 MB/s` | 1.000 Mbit/s beziehungsweise 1 Gbit/s | Dateigrößen können binär oder dezimal angegeben werden. Zusätzlich reduzieren Protokoll-Overhead, Verschlüsselung, Wiederholungen und Dateisystemverarbeitung den nutzbaren Durchsatz. **Beispiel:** ```text 1-Gbit/s-Ethernet ≠ 125 MB/s garantierte Nutzdatenrate ```
---
4. Messziel und Datenpfad vollständig beschreiben Vor der Messung ist der genaue Pfad zu dokumentieren: ```text Client ↓ WLAN oder Ethernet ↓ Access Point oder Switch ↓ Router beziehungsweise Firewall ↓ VPN, WAN oder Internet ↓ Zielnetz ↓ Server ↓ Anwendung und Datenträger ``` Benötigte Angaben: ```text Quelle: Quell-IP: Quellschnittstelle: Ziel: Ziel-IP: Transportprotokoll: Zielport: IPv4 oder IPv6: VPN beteiligt: Proxy beteiligt: NAT beteiligt: Testzeitpunkt: Gegenrichtung: Erwartete Leistung: Beobachtete Leistung: ``` Ohne definierten Messpfad ist die Aussage „Das Netzwerk ist langsam“ nicht technisch verwertbar.
---
5. Die Verbindung abschnittsweise messen | Messabschnitt | Typisches Ziel | |---|---| | Client zur lokalen Schnittstelle | Adapter und Betriebssystem | | Client zum Standardgateway | lokales LAN beziehungsweise WLAN | | Client zu lokalem Server | internes Netzwerk | | Client zu anderem VLAN | Routing und interne Firewall | | Client zum VPN-Gateway | Internet- oder WAN-Basisverbindung | | Client durch VPN zum internen Server | Tunnel, VPN-Routing und Zielnetz | | Client zum Internetziel | Provider- und Internetpfad | | Reverse Proxy zum Backend | Servernetz und Backend | | Server zum Datenspeicher | Speicher- oder Anwendungsengpass | **Grundregel:** > Mit der nächstgelegenen sinnvollen Messstelle beginnen und den Pfad schrittweise erweitern.
---
6. Einzelmessung und Langzeitmessung unterscheiden Eine einzelne Messung kann zufällig in einem guten oder schlechten Moment stattfinden. Für eine belastbare Diagnose dokumentieren: - Anzahl der Messwerte, - Messdauer, - Messintervall, - Minimum, - Maximum, - Durchschnitt, - Median, - relevante Perzentile, - Paketverlust, - Zeitpunkt auffälliger Spitzen, - gleichzeitige Netzlast, - Benutzerzahl, - Testmethode. **Durchschnittswerte können kurze Ausfälle verdecken:** ```text 99 Messungen: 10 ms 1 Messung: 2.000 ms Durchschnitt: 29,9 ms ``` Der Durchschnitt wirkt noch relativ niedrig, obwohl eine einzelne Verzögerung von zwei Sekunden für Echtzeitanwendungen deutlich spürbar sein kann.
---
7. ICMP-Ping sinnvoll einsetzen Ping misst die Round-Trip Time von ICMP Echo Request und Echo Reply. **Windows:** ```cmd [TEST] ping -n 20 ZIEL_IP ``` **Windows PowerShell:** ```powershell [TEST] Test-Connection ZIEL_IP -Count 20 ``` **Linux:** ```bash [TEST] ping -c 20 ZIEL_IP ``` **macOS:** ```bash [TEST] ping -c 20 ZIEL_IP ``` Zu dokumentieren sind: - gesendete Pakete, - empfangene Pakete, - Verlust in Prozent, - minimale RTT, - durchschnittliche RTT, - maximale RTT, - starke Schwankungen. **Wichtig:** Ein Ziel kann ICMP blockieren oder niedriger priorisieren, während Anwendungsverkehr weiterhin funktioniert.
---
8. Ping-Ergebnisse korrekt interpretieren | Beobachtung | Mögliche Bedeutung | |---|---| | Gleichmäßig niedrige RTT | Pfad ist für diese Messung stabil | | Dauerhaft hohe RTT | Entfernung, langsamer Link, Tunnel oder Überlastung | | Einzelne starke Spitzen | Queueing, Funkstörung, Last oder Verarbeitungsspitze | | Regelmäßige Spitzen | periodischer Datenverkehr, Scan, Backup oder Energiesparfunktion | | Vereinzelter Verlust | Störung, Überlastung oder ICMP-Priorisierung | | Verlust in Bursts | Link-Flap, Funkproblem, Queue Drop oder Pfadwechsel | | Kein Ping, Anwendung funktioniert | ICMP wird möglicherweise gefiltert | | Ping zur IP funktioniert, zum Namen nicht | Namensauflösung prüfen | | Gatewayping schlecht | Problem wahrscheinlich bereits im lokalen Zugangsnetz | | Gatewayping gut, externes Ziel schlecht | Problem liegt wahrscheinlich hinter dem Gateway | Ein Ping beweist nicht die Leistungsfähigkeit von TCP, UDP oder der Anwendung.
---
9. Lokales Gateway zuerst messen **Standardgateway ermitteln:** Windows: ```powershell [RO] Get-NetRoute -DestinationPrefix "0.0.0.0/0" | Sort-Object RouteMetric | Format-Table InterfaceAlias, NextHop, RouteMetric ``` Linux: ```bash [RO] ip route show default ``` macOS: ```bash [RO] route -n get default ``` **Gateway über längeren Zeitraum testen:** Windows: ```cmd [TEST] ping -n 100 GATEWAY_IP ``` Linux und macOS: ```bash [TEST] ping -c 100 GATEWAY_IP ``` Wenn bereits zum lokalen Gateway Paketverlust oder starke Latenzschwankungen auftreten, sollten zuerst folgende Komponenten geprüft werden: - WLAN-Funkverbindung, - Ethernetkabel, - Switchport, - Netzwerkadapter, - Treiber, - Duplex und Linkgeschwindigkeit, - lokaler Router, - Clientauslastung.
---
10. Mehrere Messziele parallel vergleichen Für die Eingrenzung werden mehrere Ziele betrachtet: ```text Ziel 1: lokales Gateway Ziel 2: interner Server Ziel 3: WAN-Gegenstelle Ziel 4: Anwendungsserver ``` **Interpretationsbeispiel:** | Gateway | Interner Server | Externes Ziel | Mögliche Eingrenzung | |---|---|---|---| | gut | gut | schlecht | WAN, Provider oder externer Pfad | | gut | schlecht | gut | internes Routing, VLAN oder Serverpfad | | schlecht | schlecht | schlecht | lokales Zugangsnetz | | gut | gut | gut | möglicherweise anwendungsspezifisches Problem | | gut | nur VPN-Ziel schlecht | gut | VPN oder entferntes Netz | Parallele Messungen müssen mit sinnvollen Intervallen erfolgen, damit die Diagnose nicht selbst unnötige Last erzeugt.
---
11. TCP-Erreichbarkeit und TCP-Latenz prüfen Wenn ICMP blockiert wird, kann ein Test zum tatsächlichen TCP-Port sinnvoller sein. **Windows:** ```powershell [TEST] Test-NetConnection server.example.internal ` -Port 443 ` -InformationLevel Detailed ``` **Linux und macOS:** ```bash [TEST] nc -vz -w 5 server.example.internal 443 ``` Diese Befehle zeigen hauptsächlich, ob ein TCP-Verbindungsaufbau möglich ist. Sie liefern noch keine vollständige Leistungsmessung. **Windows mit PsPing, sofern autorisiert installiert:** ```cmd [TEST] psping -n 20 server.example.internal:443 ``` PsPing kann TCP-Verbindungszeiten messen und ist besonders nützlich, wenn ICMP nicht beantwortet wird.
---
12. Anwendungsantwortzeiten mit curl zerlegen **Zeitanteile einer HTTP- beziehungsweise HTTPS-Anfrage:** ```bash [TEST][SENS] curl -sS -o /dev/null \ -w 'DNS: %{time_namelookup}\nConnect: %{time_connect}\nTLS: %{time_appconnect}\nStartTransfer: %{time_starttransfer}\nTotal: %{time_total}\nHTTP: %{http_code}\n' \ https://service.example.net/ ``` | curl-Wert | Bedeutung | |---|---| | `time_namelookup` | Zeit bis zum Abschluss der Namensauflösung | | `time_connect` | Zeit bis zum TCP-Verbindungsaufbau | | `time_appconnect` | Zeit bis zum Abschluss des TLS-Handshakes | | `time_starttransfer` | Zeit bis zum ersten Antwortbyte | | `time_total` | Gesamtdauer | | `http_code` | HTTP-Statuscode | **Typische Eingrenzung:** | Auffälliger Wert | Mögliche Ursache | |---|---| | DNS-Zeit hoch | DNS-Server, Suche oder Netzwerkpfad | | Connect-Zeit hoch | Latenz, Paketverlust, Firewall oder Serverlistener | | TLS-Zeit hoch | TLS-Handshake, Zertifikatsprüfung oder CPU | | StartTransfer hoch | Server, Datenbank oder Backend | | Total hoch, StartTransfer normal | große Antwort, begrenzte Bandbreite oder langsamer Client |
---
13. Netzwerkpfad mit traceroute und tracert prüfen **Windows ohne Namensauflösung:** ```cmd [TEST] tracert -d ZIEL_IP ``` **Linux:** ```bash [TEST] traceroute -n ZIEL_IP ``` Falls `traceroute` nicht installiert ist: ```bash [TEST] tracepath -n ZIEL_IP ``` **macOS:** ```bash [TEST] traceroute -n ZIEL_IP ``` Zu kontrollieren sind: - Anzahl der Hops, - Änderung des Pfads, - sprunghafter Latenzanstieg, - Zeitüberschreitungen, - unterschiedliche IPv4- und IPv6-Pfade, - asymmetrische oder lastverteilte Pfade. Ein Sternchen bei einem Zwischenrouter beweist keinen Paketverlust des weitergeleiteten Nutzverkehrs. Der Router kann Antworten auf Diagnosepakete begrenzen oder vollständig unterdrücken.
---
14. IPv4 und IPv6 getrennt messen Ein Hostname kann sowohl IPv4- als auch IPv6-Adressen besitzen. Die Pfade und Leistungswerte können deutlich voneinander abweichen. **Windows:** ```cmd [TEST] ping -4 -n 20 HOSTNAME [TEST] ping -6 -n 20 HOSTNAME ``` ```cmd [TEST] tracert -4 -d HOSTNAME [TEST] tracert -6 -d HOSTNAME ``` **Linux:** ```bash [TEST] ping -4 -c 20 HOSTNAME [TEST] ping -6 -c 20 HOSTNAME ``` **macOS:** ```bash [TEST] ping -c 20 IPV4_ADRESSE [TEST] ping6 -c 20 IPV6_ADRESSE ``` **HTTP getrennt testen:** ```bash [TEST] curl -4 -I https://service.example.net/ [TEST] curl -6 -I https://service.example.net/ ``` Ein gutes IPv4-Ergebnis beweist nicht, dass der IPv6-Pfad ebenfalls funktioniert.
---
15. Windows pathping verwenden `pathping` kombiniert Pfadermittlung mit wiederholten Messungen zu Zwischenstationen. **Ohne Namensauflösung:** ```cmd [TEST] pathping /n ZIEL_IP ``` **IPv4:** ```cmd [TEST] pathping /n /4 ZIEL_IP ``` **IPv6:** ```cmd [TEST] pathping /n /6 ZIEL_IP ``` Die Messung kann mehrere Minuten dauern. **Wichtige Interpretation:** Wenn ein Zwischenhop hohen Verlust zeigt, spätere Hops und das Ziel aber keinen entsprechenden Verlust zeigen, priorisiert oder begrenzt der Zwischenrouter wahrscheinlich nur seine eigenen ICMP-Antworten. Ein echter Weiterleitungsverlust wird typischerweise ab einer Stelle auch an nachfolgenden Hops beziehungsweise am Ziel sichtbar.
---
16. MTR unter Linux und macOS verwenden `mtr` kombiniert fortlaufende Pfad- und Latenzmessungen. Es ist nicht auf jedem System standardmäßig installiert. **Prüfen, ob MTR vorhanden ist:** ```bash [RO] command -v mtr ``` **Interaktive Messung ohne Namensauflösung:** ```bash [TEST] mtr -n ZIEL_IP ``` **Berichtsmodus mit 100 Messzyklen:** ```bash [TEST] mtr -n -r -c 100 ZIEL_IP ``` **TCP-basierter Test zu Port 443, sofern von der installierten Version unterstützt:** ```bash [TEST][PRIV] sudo mtr -n -r -c 100 -T -P 443 ZIEL_IP ``` Vor Verwendung erweiterter Optionen lokale Hilfe prüfen: ```bash [RO] mtr --help ``` Auch bei MTR gilt: Verlust an einem Zwischenhop allein ist kein Beweis für weitergeleiteten Paketverlust.
---
17. Paketverlust mathematisch einordnen ```text Paketverlust in Prozent = (verlorene Pakete ÷ gesendete Pakete) × 100 ``` Beispiel: ```text Gesendet: 1.000 Empfangen: 990 Verloren: 10 Paketverlust = 1 % ``` Die Auswirkungen hängen von Anwendung und Verteilung des Verlusts ab. | Verlustmuster | Mögliche Wirkung | |---|---| | Einzelne gleichmäßig verteilte Verluste | TCP-Wiederholungen, kurze Audiofehler | | Mehrere Verluste in Folge | deutliche Unterbrechung oder Timeout | | Verlust nur unter Last | überfüllte Queue oder überlasteter Link | | Verlust nur in eine Richtung | asymmetrisches Problem | | Verlust nur großer Pakete | MTU- oder Fragmentierungsproblem | | ICMP-Verlust ohne Anwendungsverlust | mögliche ICMP-Priorisierung | Burst Loss ist für Echtzeitanwendungen häufig problematischer als derselbe prozentuale Verlust gleichmäßig verteilt.
---
18. Jitter messen und beurteilen Jitter beschreibt die Schwankung von Paketlaufzeiten. Es gibt unterschiedliche Berechnungsmethoden; Werte verschiedener Werkzeuge sind daher nicht immer direkt vergleichbar. **Typische Symptome hohen Jitters:** - abgehackte Sprache, - schwankende Videoqualität, - Ruckeln bei Remote-Desktop, - ungleichmäßige Echtzeitdaten, - vergrößerte Wiedergabepuffer, - kurze Aussetzer trotz geringem Durchschnittsping. `ping` zeigt Schwankungen der RTT, ist aber kein vollständiger Ersatz für eine anwendungsnahe Jittermessung. Für UDP kann `iperf3` Jitter und Datagrammverlust ausgeben: ```bash [TEST] iperf3 -c SERVER_IP -u -b 10M -t 30 ``` Mit niedriger, kontrollierter Zielrate beginnen. Eine zu hohe Testbandbreite erzeugt selbst Verlust und Jitter.
---
19. iperf3-Testumgebung vorbereiten Für eine kontrollierte Messung werden benötigt: ```text iperf3-Client iperf3-Server freigegebener Testpfad bekannte Schnittstellen ausreichende Serverleistung definierte Testdauer ``` **Server starten:** ```bash [TEST] iperf3 -s ``` Standardmäßig verwendet iperf3 Port `5201`. Der Port kann verändert werden. **Clienttest:** ```bash [TEST] iperf3 -c SERVER_IP ``` **Anderer Port:** Server: ```bash [TEST] iperf3 -s -p 5202 ``` Client: ```bash [TEST] iperf3 -c SERVER_IP -p 5202 ``` Firewallregeln müssen zum gewählten Transport und Port passen. Bei UDP-Tests verwendet iperf3 zusätzlich eine TCP-Steuerverbindung. Die genaue Port- und Firewallkonfiguration ist deshalb vorab zu prüfen.
---
20. TCP-Durchsatz mit iperf3 messen **Standardtest vom Client zum Server:** ```bash [TEST] iperf3 -c SERVER_IP ``` **30 Sekunden testen:** ```bash [TEST] iperf3 -c SERVER_IP -t 30 ``` **Gegenrichtung – Server sendet zum Client:** ```bash [TEST] iperf3 -c SERVER_IP -R -t 30 ``` **Beide Richtungen gleichzeitig, sofern unterstützt:** ```bash [TEST] iperf3 -c SERVER_IP --bidir -t 30 ``` **Mehrere parallele TCP-Datenströme:** ```bash [TEST] iperf3 -c SERVER_IP -P 4 -t 30 ``` Parallele Datenströme können einen Pfad stärker auslasten und höhere Messwerte erzielen. Sie können aber Probleme eines einzelnen Datenstroms verdecken und erhebliche Last erzeugen. **Empfohlene Reihenfolge:** 1. Ein TCP-Datenstrom zum Server. 2. Ein TCP-Datenstrom in Gegenrichtung. 3. Bei Bedarf mehrere Datenströme. 4. Erst danach gleichzeitiger bidirektionaler Test.
---
21. UDP mit iperf3 kontrolliert messen **UDP-Test mit 10 Mbit/s Zielrate:** ```bash [TEST] iperf3 -c SERVER_IP -u -b 10M -t 30 ``` **Gegenrichtung:** ```bash [TEST] iperf3 -c SERVER_IP -u -b 10M -t 30 -R ``` **Relevante Ergebnisse:** - gesendete Bitrate, - empfangene Bitrate, - Jitter, - verlorene Datagramme, - Verlustquote, - Out-of-Order-Pakete, falls ausgegeben. **Teststrategie:** ```text niedrige Rate → Ergebnis prüfen → Rate schrittweise erhöhen → Beginn von Verlust und Jitter dokumentieren ``` Nicht sofort mit der maximal erwarteten Linkgeschwindigkeit beginnen. Ein UDP-Test besitzt keine TCP-Staukontrolle und kann andere Verbindungen stark beeinträchtigen.
---
22. iperf3-Ergebnisse als JSON speichern **JSON-Ausgabe anzeigen:** ```bash [TEST][SENS] iperf3 -c SERVER_IP -J ``` **In Datei speichern:** ```bash [TEST][FILE][SENS] iperf3 -c SERVER_IP -t 30 -J > iperf3-test.json ``` **UDP-Ergebnis speichern:** ```bash [TEST][FILE][SENS] iperf3 -c SERVER_IP \ -u -b 10M -t 30 -J > iperf3-udp-test.json ``` Vor einer Weitergabe prüfen, ob die Datei interne IP-Adressen, Hostnamen oder andere sensible Angaben enthält.
---
23. iperf3-Ergebnisse richtig interpretieren | Beobachtung | Mögliche Bedeutung | |---|---| | Hinrichtung gut, Rückrichtung schlecht | asymmetrischer Pfad, QoS, Empfangs- oder Sendeseite | | Ein Stream schlecht, mehrere gut | RTT, TCP-Fenster, Verlust oder CPU pro Stream | | TCP gut, UDP bei niedriger Rate schlecht | Queue, Policing, Funk- oder UDP-spezifischer Pfad | | UDP erst ab bestimmter Rate mit Verlust | Kapazitäts- beziehungsweise Queuegrenze | | Werte schwanken stark | Funk, Last, Pfadwechsel oder konkurrierender Verkehr | | Server- und Clientwerte unterscheiden sich | Verlust beziehungsweise unvollständige Übertragung | | Hohe Retransmissions | Paketverlust, Überlastung oder fehlerhafter Link | | Durchsatz exakt an einer Rate begrenzt | Policer, Shaper, Vertrag oder Schnittstellenlimit | | CPU nahe 100 Prozent | Endsystem kann der Engpass sein | | Datenträger langsam, iperf3 gut | Speicher oder Anwendung statt Netzwerk | Ein iperf3-Test misst Arbeitsspeicher-zu-Arbeitsspeicher-Netzwerkleistung und nicht automatisch Datei-, Datenbank- oder Anwendungsleistung.
---
24. TCP-Wiederholungen und Zustände prüfen **Windows-TCP-Statistik:** ```cmd [RO] netstat -s -p tcp ``` **Windows-Verbindungen:** ```powershell [RO] Get-NetTCPConnection | Format-Table LocalAddress, LocalPort, RemoteAddress, RemotePort, State ``` **Linux-TCP-Statistik:** ```bash [RO] nstat ``` Falls `nstat` nicht vorhanden ist: ```bash [RO] netstat -s ``` **Linux-Socketdiagnose:** ```bash [RO][SENS] ss -ti ``` **macOS-TCP-Statistik:** ```bash [RO] netstat -s -p tcp ``` Zähler sind kumulativ und müssen über einen definierten Messzeitraum verglichen werden. Ein hoher Gesamtwert allein beweist kein aktuelles Problem.
---
25. Schnittstellenzähler und physische Fehler prüfen **Windows:** ```powershell [RO] Get-NetAdapterStatistics | Format-Table Name, ReceivedBytes, SentBytes, ReceivedDiscardedPackets, OutboundDiscardedPackets, ReceivedPacketErrors, OutboundPacketErrors ``` **Linux:** ```bash [RO] ip -s link ``` **Linux – erweiterte Treiberstatistiken:** ```bash [RO][PRIV][SENS] sudo ethtool -S INTERFACE ``` **macOS:** ```bash [RO] netstat -ib ``` ```bash [RO] ifconfig ``` Zu prüfen sind: - RX- und TX-Fehler, - Drops, - verworfene Pakete, - CRC- beziehungsweise Framefehler, - Overruns, - Carrierfehler, - Link-Flaps, - steigende Fehlerzähler unter Last. Entscheidend ist, ob Zähler während des reproduzierten Fehlers ansteigen.
---
26. Linkgeschwindigkeit und Duplex prüfen **Windows:** ```powershell [RO] Get-NetAdapter | Format-Table Name, Status, LinkSpeed, MediaConnectionState ``` **Linux:** ```bash [RO] ip link show INTERFACE ``` ```bash [RO][PRIV] sudo ethtool INTERFACE ``` **macOS:** ```bash [RO] ifconfig INTERFACE ``` Abhängig vom Adapter können zusätzliche Informationen über `networksetup` oder `system_profiler` verfügbar sein. Zu prüfen sind: - erwartete Linkgeschwindigkeit, - Full Duplex oder Half Duplex, - Autonegotiation, - Linkstatus, - unerwartete Begrenzung auf 100 Mbit/s, - wiederholte Neuverhandlung, - Kabel- oder Portfehler. Ein Link mit 1 Gbit/s Anzeige beweist nicht, dass er fehlerfrei oder vollständig auslastbar ist.
---
27. Bufferbloat erkennen Bufferbloat liegt vor, wenn Warteschlangen unter Last stark anwachsen und dadurch die Latenz deutlich steigt. **Typisches Verhalten:** ```text Ping ohne Last: 10 ms Ping unter Last: 300 ms Paketverlust: möglicherweise gering Durchsatz: hoch ``` Trotz hohen Durchsatzes reagieren Sprache, Spiele, Remote-Desktop und interaktive Anwendungen schlecht. **Testablauf:** 1. Kontinuierlichen Ping zum geeigneten Ziel starten. 2. Basislatenz ohne Last dokumentieren. 3. Kontrollierten iperf3-Test starten. 4. Latenz während Downloadrichtung beobachten. 5. Latenz während Uploadrichtung beobachten. 6. Test stoppen. 7. Erholung der Latenz dokumentieren. **Beispiel:** Terminal 1: ```bash [TEST] ping ZIEL_IP ``` Terminal 2: ```bash [TEST] iperf3 -c SERVER_IP -t 30 ``` Anschließend: ```bash [TEST] iperf3 -c SERVER_IP -R -t 30 ``` Eine Optimierung kann Queue Management oder Traffic Shaping erfordern. Solche Änderungen müssen am tatsächlichen Engpass und nicht willkürlich am Client erfolgen.
---
28. QoS, Shaping und Policing berücksichtigen | Funktion | Wirkung | |---|---| | Classification | Verkehr wird einer Klasse zugeordnet | | Marking | Pakete erhalten beispielsweise eine DSCP-Markierung | | Queuing | Pakete werden in Warteschlangen eingeordnet | | Scheduling | Reihenfolge der Übertragung wird bestimmt | | Shaping | Datenrate wird durch Puffern geglättet | | Policing | Überschreitender Verkehr wird verworfen oder neu markiert | | Rate Limit | Datenrate wird begrenzt | | Priorisierung | Bestimmte Klassen werden bevorzugt behandelt | **Typische Symptome einer Richtlinie:** - exakt begrenzter Durchsatz, - nur bestimmte Anwendungen betroffen, - UDP und TCP verhalten sich unterschiedlich, - nur eine Richtung ist begrenzt, - Unterschied zwischen internen und externen Zielen, - Verhalten ändert sich zu bestimmten Uhrzeiten, - DSCP-Markierungen werden verändert oder entfernt. QoS ist kein Ersatz für ausreichende Kapazität. Eine Priorisierung kann wichtige Anwendungen schützen, erzeugt aber keine zusätzliche Bandbreite.
---
29. Server und Client als Engpass ausschließen Während des Netzwerktests sind auf beiden Endsystemen zu prüfen: - CPU-Auslastung, - Arbeitsspeicher, - Interruptlast, - Netzwerktreiber, - Energiesparzustand, - Verschlüsselungsleistung, - virtuelle CPU, - Hypervisor-Auslastung, - Containerlimits, - Datenträger, falls Anwendungstest, - Sicherheitssoftware. **Windows:** ```powershell [RO] Get-Counter '\Processor(_Total)\% Processor Time' ``` ```powershell [RO] Get-Process | Sort-Object CPU -Descending | Select-Object -First 10 ``` **Linux:** ```bash [RO] uptime ``` ```bash [RO] top ``` **macOS:** ```bash [RO] top -l 1 ``` Ein Durchsatztest kann durch die Rechenleistung eines virtuellen oder kleinen Systems begrenzt werden, obwohl das Netzwerk höhere Kapazität besitzt.
---
30. Dateiübertragung nicht als alleinigen Netzwerktest verwenden Eine Dateiübertragung misst gleichzeitig: ```text Quelldatenträger + Dateisystem + Serverdienst + Protokoll + Netzwerk + Sicherheitsprüfung + Zieldatenträger ``` Mögliche nicht netzwerkbezogene Engpässe: - langsame HDD, - ausgelastetes RAID, - Virenscanner, - Dateiverschlüsselung, - Deduplizierung, - Kompression, - SMB-Signierung oder Verschlüsselung, - kleine Dateien und Metadatenoperationen, - Datenbankzugriffe, - CPU-Auslastung, - Cachezustand. **Empfohlene Trennung:** ```text iperf3 gut Dateikopie langsam → Speicher, Dateidienst oder Anwendung weiter prüfen ```
---
31. MTU und große Pakete prüfen **Windows mit Don't-Fragment-Bit:** ```cmd [TEST] ping -4 -f -l 1400 ZIEL_IP ``` **Linux:** ```bash [TEST] ping -4 -M do -s 1400 ZIEL_IP ``` **macOS:** ```bash [TEST] ping -D -s 1400 ZIEL_IP ``` **MTU anzeigen:** | Betriebssystem | Befehl | |---|---| | Windows | `[RO] Get-NetIPInterface` | | Linux | `[RO] ip link show` | | macOS | `[RO] ifconfig` | Die Ping-Nutzdatenlänge ist nicht mit der gesamten IP-Paketgröße identisch. Header müssen zusätzlich berücksichtigt werden. **Typische MTU-Symptome:** - kleine Anfragen funktionieren, - große Übertragungen hängen, - VPN-Verbindungen betroffen, - TLS-Handshake unvollständig, - bestimmte Websites laden nur teilweise, - IPv6 meldet Packet Too Big.
---
32. Paketmitschnitt zur Leistungsanalyse verwenden **Linux:** ```bash [TEST][PRIV][FILE][SENS] sudo tcpdump -i INTERFACE -nn \ 'host ZIEL_IP' \ -w performance-test.pcap ``` **macOS:** ```bash [TEST][PRIV][FILE][SENS] sudo tcpdump -i INTERFACE -nn \ 'host ZIEL_IP' \ -w performance-test.pcap ``` **Windows mit Dumpcap – Schnittstellen ermitteln:** ```powershell [RO] dumpcap -D ``` **Mitschnitt:** ```powershell [TEST][PRIV][FILE][SENS] dumpcap -i 1 ` -f "host ZIEL_IP" ` -w performance-test.pcapng ``` Paketmitschnitte können vertrauliche Nutzdaten und Metadaten enthalten. Aufzeichnungsdauer und Filter sollten auf den benötigten Umfang begrenzt werden.
---
33. Wireshark-Filter für Leistungsprobleme | Aufgabe | Anzeigefilter | |---|---| | Verkehr zu einer IPv4-Adresse | `ip.addr == 192.0.2.20` | | Verkehr zu einer IPv6-Adresse | `ipv6.addr == 2001:db8::20` | | TCP-Wiederholungen | `tcp.analysis.retransmission` | | Schnelle Wiederholungen | `tcp.analysis.fast_retransmission` | | Vermutete verlorene Segmente | `tcp.analysis.lost_segment` | | Doppelte ACKs | `tcp.analysis.duplicate_ack` | | Out-of-Order | `tcp.analysis.out_of_order` | | Zero Window | `tcp.analysis.zero_window` | | Window Full | `tcp.analysis.window_full` | | TCP-Reset | `tcp.flags.reset == 1` | | ICMP | `icmp` | | ICMPv6 | `icmpv6` | | DNS-Antwortzeit | `dns.time` | | TCP-Verbindungsaufbau | `tcp.connection.syn || tcp.connection.synack` | Wireshark-Analyseflags sind Schlussfolgerungen aus dem vorhandenen Mitschnitt. Fehlende Pakete am Messpunkt können falsche oder irreführende Markierungen erzeugen.
---
34. Einseitige und doppelseitige Mitschnitte unterscheiden **Einseitiger Mitschnitt:** ```text zeigt nur Pakete am lokalen Messpunkt ``` **Doppelseitiger Mitschnitt:** ```text Clientmitschnitt + Servermitschnitt + synchronisierte Zeit ``` Dadurch lässt sich erkennen: - ob ein Paket den Client verlässt, - wann es den Server erreicht, - ob der Server antwortet, - wann die Antwort den Client erreicht, - in welcher Richtung Verlust auftritt, - wo zusätzliche Verzögerung entsteht, - ob ein Netzwerkgerät Pakete verändert. Für exakte Laufzeitvergleiche müssen die Uhren der Messsysteme ausreichend synchronisiert sein.
---
35. Zwischenhop-Verlust nicht falsch interpretieren Beispiel: ```text Hop 1: 0 % Verlust Hop 2: 60 % Verlust Hop 3: 0 % Verlust Ziel: 0 % Verlust ``` Hop 2 leitet den Verkehr offensichtlich weiter, antwortet aber nur eingeschränkt auf Diagnosepakete. **Wahrscheinlicher tatsächlicher Weiterleitungsverlust:** ```text Hop 1: 0 % Verlust Hop 2: 20 % Verlust Hop 3: 20 % Verlust Hop 4: 20 % Verlust Ziel: 20 % Verlust ``` Auch dieses Muster muss mit weiteren Messungen bestätigt werden, da Pfadwechsel, Load Balancing und asymmetrische Routen Ergebnisse beeinflussen können.
---
36. Typische Fehlerbilder systematisch eingrenzen **Fall A – Latenz bereits zum Gateway hoch** Prüfen: - WLAN-Signal und Kanal, - Kabel, - Switchport, - Duplex, - Adaptertreiber, - lokalen Router, - Clientlast. --- **Fall B – Gateway gut, Internet schlecht** Prüfen: - WAN-Auslastung, - Provider, - Routerqueue, - VPN, - Proxy, - externen Pfad, - IPv4 gegenüber IPv6. --- **Fall C – Durchsatz gut, Echtzeitanwendung schlecht** Prüfen: - Jitter, - Burst Loss, - Bufferbloat, - QoS, - UDP-Pfad, - Anwendungsserver. --- **Fall D – Download gut, Upload schlecht** Prüfen: - Upstreamkapazität, - Shaping, - Policing, - WLAN-Senderichtung, - asymmetrischen Pfad, - fehlerhafte TX-Zähler. --- **Fall E – Kleine Übertragungen funktionieren, große nicht** Prüfen: - MTU, - Path-MTU-Discovery, - ICMP-Blockierung, - Fragmentierung, - VPN-Overhead. --- **Fall F – iperf3 gut, Dateikopie langsam** Prüfen: - Datenträger, - Dateisystem, - SMB oder NFS, - Virenscanner, - Verschlüsselung, - Serverlast. --- **Fall G – Nur zu Stoßzeiten schlecht** Prüfen: - Linkauslastung, - Airtime, - Backup, - Synchronisation, - WAN-Kapazität, - Queue Drops, - Serverlast. --- **Fall H – Nur ein TCP-Datenstrom langsam** Prüfen: - RTT, - Paketverlust, - TCP-Fenster, - Empfangspuffer, - Congestion Control, - CPU eines einzelnen Prozesses.
---
37. Keine unkontrollierten Lasttests durchführen Nicht vorschnell: - maximale UDP-Rate senden, - viele parallele Datenströme starten, - Tests während kritischer Geschäftsprozesse durchführen, - produktive Server ohne Freigabe als iperf3-Ziel verwenden, - QoS oder Shaping deaktivieren, - Interfacezähler zurücksetzen, - MTU beliebig ändern, - Firewalls für Tests abschalten, - öffentliche Speedtest-Dienste mit sensiblen Systemen automatisiert belasten, - Messergebnisse verschiedener Pfade direkt vergleichen. **Sicherer Testablauf:** 1. Testumfang genehmigen lassen. 2. Quelle, Ziel und Pfad dokumentieren. 3. Niedrige Last verwenden. 4. Messdauer begrenzen. 5. Überwachung parallel aktivieren. 6. Last schrittweise erhöhen. 7. Test bei negativen Auswirkungen sofort beenden. 8. Hin- und Rückrichtung getrennt messen. 9. Ergebnis samt Uhrzeit dokumentieren. 10. Testdienste anschließend kontrolliert beenden.
---
38. Systematischer Diagnoseablauf | Schritt | Prüfung | Leitfrage | |---:|---|---| | 1 | Problem konkretisieren | Latenz, Jitter, Verlust oder Durchsatz? | | 2 | Quelle und Ziel dokumentieren | Welcher Datenpfad ist betroffen? | | 3 | Schnittstellenstatus prüfen | Stimmen Link, Geschwindigkeit und Fehlerzähler? | | 4 | Lokales Gateway messen | Beginnt das Problem bereits im Zugangsnetz? | | 5 | Internen Server messen | Ist das lokale LAN betroffen? | | 6 | Externen Pfad messen | Beginnt das Problem hinter dem Router? | | 7 | IPv4 und IPv6 vergleichen | Ist nur eine Adressfamilie betroffen? | | 8 | Pfad ermitteln | Welche Hops werden tatsächlich verwendet? | | 9 | Hin- und Rückrichtung messen | Ist das Problem asymmetrisch? | | 10 | TCP-Durchsatz messen | Welche Nutzrate erreicht ein Datenstrom? | | 11 | UDP kontrolliert messen | Wie entwickeln sich Jitter und Verlust? | | 12 | Latenz unter Last prüfen | Liegt Bufferbloat vor? | | 13 | Schnittstellenzähler vergleichen | Steigen Fehler oder Drops während des Tests? | | 14 | Endsystemlast prüfen | Begrenzen CPU oder Anwendung das Ergebnis? | | 15 | MTU prüfen | Scheitern nur größere Pakete? | | 16 | Paketmitschnitt erstellen | Sind Wiederholungen oder Zeitlücken sichtbar? | | 17 | Vergleichssystem messen | Ist das Ergebnis client- oder pfadspezifisch? | | 18 | Ursache nachweisen | Welche Messwerte belegen die Fehlerstelle? | | 19 | Minimale Änderung planen | Welche Korrektur behebt den Engpass? | | 20 | Nachprüfung durchführen | Verbessern sich alle relevanten Messgrößen? |
---
39. Kompakte Befehlstabelle | Aufgabe | Windows | Linux | macOS | |---|---|---|---| | Ping mit 20 Paketen | `[TEST] ping -n 20 ZIEL_IP` | `[TEST] ping -c 20 ZIEL_IP` | `[TEST] ping -c 20 ZIEL_IP` | | Standardgateway | `[RO] Get-NetRoute -DestinationPrefix "0.0.0.0/0"` | `[RO] ip route show default` | `[RO] route -n get default` | | Route zum Ziel | `[RO] Find-NetRoute -RemoteIPAddress ZIEL_IP` | `[RO] ip route get ZIEL_IP` | `[RO] route -n get ZIEL_IP` | | Pfad ohne DNS | `[TEST] tracert -d ZIEL_IP` | `[TEST] traceroute -n ZIEL_IP` | `[TEST] traceroute -n ZIEL_IP` | | Pfad und Verlust | `[TEST] pathping /n ZIEL_IP` | Falls installiert: `[TEST] mtr -n -r -c 100 ZIEL_IP` | Falls installiert: `[TEST] mtr -n -r -c 100 ZIEL_IP` | | TCP-Porttest | `[TEST] Test-NetConnection HOST -Port PORT` | `[TEST] nc -vz -w 5 HOST PORT` | `[TEST] nc -vz -w 5 HOST PORT` | | TCP-Durchsatz | `[TEST] iperf3 -c SERVER_IP` | `[TEST] iperf3 -c SERVER_IP` | `[TEST] iperf3 -c SERVER_IP` | | Gegenrichtung | `[TEST] iperf3 -c SERVER_IP -R` | `[TEST] iperf3 -c SERVER_IP -R` | `[TEST] iperf3 -c SERVER_IP -R` | | UDP-Test | `[TEST] iperf3 -c SERVER_IP -u -b 10M` | `[TEST] iperf3 -c SERVER_IP -u -b 10M` | `[TEST] iperf3 -c SERVER_IP -u -b 10M` | | Schnittstellenzähler | `[RO] Get-NetAdapterStatistics` | `[RO] ip -s link` | `[RO] netstat -ib` | | Linkinformationen | `[RO] Get-NetAdapter` | `[RO][PRIV] sudo ethtool INTERFACE` | `[RO] ifconfig INTERFACE` | | TCP-Statistik | `[RO] netstat -s -p tcp` | `[RO] nstat` oder `[RO] netstat -s` | `[RO] netstat -s -p tcp` | | MTU | `[RO] Get-NetIPInterface` | `[RO] ip link show` | `[RO] ifconfig` | | DF-Test | `[TEST] ping -4 -f -l 1400 ZIEL_IP` | `[TEST] ping -4 -M do -s 1400 ZIEL_IP` | `[TEST] ping -D -s 1400 ZIEL_IP` | | HTTP-Zeiten | `[TEST][SENS] curl.exe -w ... URL` | `[TEST][SENS] curl -w ... URL` | `[TEST][SENS] curl -w ... URL` | `ZIEL_IP`, `HOST`, `PORT`, `SERVER_IP`, `INTERFACE` und `URL` müssen durch die Werte des konkreten Störungsfalls ersetzt werden.
---
40. Dokumentationsvorlage für Leistungsprobleme ```text Störung: Zeitpunkt: Zeitzone: Standort: Benutzer: Client: Betriebssystem: Quellschnittstelle: Quell-IP: Linkgeschwindigkeit: Duplex: WLAN-SSID: WLAN-BSSID: WLAN-Signal: VPN beteiligt: Proxy beteiligt: Zielhostname: Ziel-IP: Zielport: Transportprotokoll: IPv4 oder IPv6: Erwarteter Datenpfad: Gemessener Datenpfad: Gateway-RRT Minimum: Gateway-RRT Durchschnitt: Gateway-RRT Maximum: Gateway-Paketverlust: Ziel-RTT Minimum: Ziel-RTT Durchschnitt: Ziel-RTT Maximum: Ziel-Paketverlust: Jitter: Burst Loss: iperf3 TCP Client zu Server: iperf3 TCP Server zu Client: iperf3 parallele Streams: iperf3 UDP Zielrate: iperf3 UDP empfangene Rate: iperf3 UDP Jitter: iperf3 UDP Verlust: Latenz ohne Last: Latenz unter Uploadlast: Latenz unter Downloadlast: RX-Fehler vorher: RX-Fehler nachher: TX-Fehler vorher: TX-Fehler nachher: Drops vorher: Drops nachher: TCP-Retransmissions: Client-CPU: Server-CPU: Server-Datenträger: Testdauer: Anzahl der Messungen: Vergleichssystem: Vergleichszeitpunkt: MTU: Größte erfolgreiche DF-Nutzlast: Paketmitschnitt: Festgestellte Ursache: Genehmigte Änderung: Rückfallplan: Ergebnis der Nachprüfung: ```
---
41. Kontrollfragen nach der Diagnose - Wurde das Problem als Latenz-, Jitter-, Verlust- oder Durchsatzproblem konkretisiert? - Sind Quelle, Ziel, Richtung und Datenpfad dokumentiert? - Wurde zuerst das lokale Gateway gemessen? - Wurden internes und externes Ziel getrennt geprüft? - Wurden IPv4 und IPv6 getrennt verglichen? - Wurde Hin- und Rückrichtung gemessen? - Wurden Einzelspitzen und nicht nur Durchschnittswerte betrachtet? - Wurde ein längerer Messzeitraum verwendet? - Wurde Zwischenhop-Verlust korrekt interpretiert? - Wurde TCP mit einem und mehreren Datenströmen verglichen? - Wurde UDP mit einer kontrollierten Zielrate getestet? - Wurden Jitter und Burst Loss erfasst? - Wurde die Latenz unter Last geprüft? - Steigen Schnittstellenfehler während des Tests? - Stimmen Linkgeschwindigkeit und Duplex? - Wurden Client- und Serverauslastung kontrolliert? - Wurde iperf3 von Datei- oder Anwendungsleistung getrennt? - Wurde die MTU geprüft? - Wurden Paketmitschnitte an beiden Enden erwogen? - War der Testumfang genehmigt und kontrolliert? - Wurde nach der Änderung mit derselben Methode erneut gemessen?
---
42. Quellen und weiterführende Dokumentation - Microsoft Learn – `ping`: https://learn.microsoft.com/windows-server/administration/windows-commands/ping - Microsoft Learn – `tracert`: https://learn.microsoft.com/windows-server/administration/windows-commands/tracert - Microsoft Learn – `pathping`: https://learn.microsoft.com/de-de/windows-server/administration/windows-commands/pathping - Microsoft Sysinternals – PsPing: https://learn.microsoft.com/de-de/sysinternals/downloads/psping - ESnet – iperf3-Dokumentation: https://software.es.net/iperf/ - ESnet – iperf3-Aufruf und Optionen: https://software.es.net/iperf/invoking.html - Linux-Handbuch – `ping`: https://man7.org/linux/man-pages/man8/ping.8.html - Linux-Handbuch – `tracepath`: https://man7.org/linux/man-pages/man8/tracepath.8.html - MTR – Offizielle Dokumentation: https://mtr.readthedocs.io/ - Wireshark – TCP Display Filter Reference: https://www.wireshark.org/docs/dfref/t/tcp.html - Wireshark – Benutzerhandbuch: https://www.wireshark.org/docs/wsug_html_chunked/ - RFC 3393 – IP Packet Delay Variation Metric: https://www.rfc-editor.org/rfc/rfc3393.html - RFC 2680 – One-way Packet Loss Metric: https://www.rfc-editor.org/rfc/rfc2680.html - RFC 6349 – Framework for TCP Throughput Testing: https://www.rfc-editor.org/rfc/rfc6349.html - RFC 8201 – Path MTU Discovery for IPv6: https://www.rfc-editor.org/rfc/rfc8201.html
# 3.16 Paketmitschnitt mit Wireshark, tcpdump, Dumpcap und Pktmon Ein Paketmitschnitt zeigt, welche Netzwerkpakete an einem bestimmten Messpunkt tatsächlich sichtbar sind. Damit lassen sich Vermutungen durch überprüfbare Beobachtungen ersetzen. Ein Mitschnitt beantwortet jedoch nur Fragen über den gewählten Messpunkt. Ein dort fehlendes Paket kann bereits vorher verloren gegangen sein, während ein sichtbares Paket hinter dem Messpunkt weiterhin verworfen werden kann. Die zentralen Fragen dieser Seite lauten: > Welcher Datenfluss muss untersucht werden, an welchem Punkt muss dafür aufgezeichnet werden und welches Paketmuster würde die jeweilige Hypothese bestätigen oder widerlegen? ---
1. Sicherheits- und Aktionskennzeichnungen | Kennzeichnung | Bedeutung | |---|---| | `[RO]` | Rein lesender Befehl, der normalerweise keine Konfiguration verändert | | `[TEST]` | Aktive Diagnose beziehungsweise Paketaufzeichnung | | `[PRIV]` | Administrator- oder Root-Rechte können erforderlich sein | | `[FILE]` | Der Befehl schreibt Ausgaben in eine Datei | | `[SENS]` | Die Ausgabe kann sensible Informationen enthalten | | `[CHANGE]` | Der Befehl verändert eine Konfiguration | | `[DISRUPT]` | Der Befehl kann eine Verbindung oder einen Dienst beeinträchtigen | Paketmitschnitte können enthalten: - interne und öffentliche IP-Adressen, - MAC-Adressen, - Hostnamen, - DNS-Anfragen, - unverschlüsselte Nutzdaten, - Cookies, - Sitzungstoken, - Benutzernamen, - E-Mail-Inhalte, - Dateiübertragungen, - API-Daten, - Authentifizierungsinformationen, - Netzwerk- und Sicherheitsarchitektur. Paketaufzeichnungen dürfen nur im genehmigten Umfang erstellt, gespeichert und weitergegeben werden.
---
2. Paketmitschnitt und Protokollierung unterscheiden | Datenquelle | Inhalt | |---|---| | Paketmitschnitt | Tatsächlich sichtbare Netzwerkframes beziehungsweise Pakete | | Betriebssystemprotokoll | Interpretation und Ereignisse des Betriebssystems | | Firewallprotokoll | Regelentscheidung wie Allow, Drop oder Reject | | Anwendungsprotokoll | Verarbeitung innerhalb der Anwendung | | Proxyprotokoll | Client-, Ziel-, Backend- und HTTP-Informationen | | Switchzähler | Fehler, Drops, Auslastung und Portstatus | | Controllerprotokoll | WLAN-, VPN- oder Infrastrukturereignisse | | Flow-Daten | Zusammengefasste Informationen über Netzwerkflüsse | | SNMP-Messwert | Zähler und Status eines Netzwerkgeräts | Ein Paketmitschnitt zeigt nicht automatisch: - welche Firewallregel entschieden hat, - warum eine Anwendung einen Fehler erzeugt hat, - ob ein Paket vor dem Messpunkt verworfen wurde, - ob ein verschlüsselter Inhalt fachlich korrekt ist, - ob ein Benutzer die richtige Berechtigung besitzt. Die beste Diagnose kombiniert Paketmitschnitt, Systemprotokoll und Anwendungsergebnis.
---
3. Datenfluss vor der Aufzeichnung definieren Vor dem Start müssen mindestens diese Angaben bekannt sein: ```text Clienthostname: Client-IP-Adresse: Serverhostname: Server-IP-Adresse: Transportprotokoll: Clientport: Serverport: Anwendungsprotokoll: IPv4 oder IPv6: Startzeitpunkt: Fehlerauslöser: Erwartetes Paketmuster: ``` **Beispiel:** ```text Client: 192.0.2.25 Server: 192.0.2.53 Transport: TCP Serverport: 443 Anwendung: HTTPS Fehler: Verbindung läuft in einen Timeout ``` Passender enger Filter: ```text host 192.0.2.25 and host 192.0.2.53 and tcp port 443 ``` Ein enger Filter reduziert Datenmenge und Datenschutzrisiko. Er kann jedoch wichtige Begleitprotokolle wie DNS, ARP, ICMP oder ICMPv6 ausblenden.
---
4. Den richtigen Messpunkt auswählen ```text Client ↓ Access Point oder Switch ↓ Router beziehungsweise Firewall ↓ VPN oder WAN ↓ Servernetz ↓ Server ↓ Anwendung ``` Mögliche Messpunkte: - direkt auf dem Client, - direkt auf dem Server, - auf dem Reverse Proxy, - auf dem VPN-Gateway, - auf der Firewall, - auf dem Router, - über einen Switch-Mirror-Port, - über einen Network TAP, - im Container, - auf dem Containerhost, - in der virtuellen Maschine, - auf dem Hypervisor. **Leitfrage:** > Welche Netzwerkkomponente baut die betroffene Verbindung tatsächlich auf? Bei einem Reverse Proxy ist der Administrator-PC nicht der richtige Messpunkt für die Verbindung zwischen Proxy und Backend.
---
5. Einseitigen und doppelseitigen Mitschnitt unterscheiden **Einseitiger Mitschnitt:** ```text Clientmitschnitt ``` Er zeigt nur, was am Client sichtbar ist. **Doppelseitiger Mitschnitt:** ```text Clientmitschnitt + Servermitschnitt + synchronisierte Zeit ``` Damit lässt sich feststellen: - ob ein Paket den Client verlässt, - ob es den Server erreicht, - ob der Server antwortet, - ob die Antwort den Client erreicht, - in welcher Richtung Verlust entsteht, - wo zusätzliche Verzögerung auftritt, - ob NAT oder Proxy Adressen verändert, - ob ein Netzwerkgerät Pakete zurücksetzt. Bei komplexen Problemen ist ein gleichzeitiger Mitschnitt an beiden Endpunkten wesentlich aussagekräftiger.
---
6. Zeit und Zeitzone synchronisieren Für den Vergleich mehrerer Mitschnitte und Protokolle müssen Zeit und Zeitzone bekannt sein. | Betriebssystem | Lokale Zeit | |---|---| | Windows | `[RO] Get-Date -Format o` | | Linux | `[RO] date --iso-8601=seconds` | | macOS | `[RO] date "+%Y-%m-%dT%H:%M:%S%z"` | **UTC-Zeit:** Windows: ```powershell [RO] (Get-Date).ToUniversalTime().ToString("o") ``` Linux und macOS: ```bash [RO] date -u "+%Y-%m-%dT%H:%M:%SZ" ``` Zu dokumentieren sind: - Beginn der Aufzeichnung, - Zeitpunkt der Fehlerauslösung, - Ende der Aufzeichnung, - Zeitzone, - Zeitabweichung zwischen Messsystemen. Eine Zeitabweichung von wenigen Sekunden kann die Zuordnung kurzer Verbindungsversuche erheblich erschweren.
---
7. Aufzeichnungsschnittstelle eindeutig bestimmen **Windows mit Dumpcap:** ```powershell [RO] dumpcap -D ``` **Windows-Netzwerkadapter:** ```powershell [RO] Get-NetAdapter -IncludeHidden | Format-Table Name, InterfaceDescription, Status, MacAddress ``` **Linux:** ```bash [RO] ip -br link ``` ```bash [RO] tcpdump -D ``` **macOS:** ```bash [RO] networksetup -listallhardwareports ``` ```bash [RO] ifconfig ``` ```bash [RO] tcpdump -D ``` Zu prüfen sind: - physische Schnittstelle, - WLAN oder Ethernet, - VPN-Tunnel, - Bridge, - VLAN-Interface, - Container-Bridge, - Loopback, - virtuelle Maschine, - aktive Route zum Ziel. **Route zum Ziel:** | Betriebssystem | Befehl | |---|---| | Windows | `[RO] Find-NetRoute -RemoteIPAddress ZIEL_IP` | | Linux | `[RO] ip route get ZIEL_IP` | | macOS | `[RO] route -n get ZIEL_IP` |
---
8. Besonderheiten der Schnittstelle any unter Linux Mit `any` kann tcpdump gleichzeitig auf mehreren Linux-Schnittstellen aufzeichnen: ```bash [TEST][PRIV][FILE][SENS] sudo tcpdump -i any -nn \ -w capture.pcap ``` Vorteile: - hilfreich bei unbekanntem Pfad, - zeigt Verkehr auf mehreren Schnittstellen, - geeignet für Router-, Proxy- und Containerhosts. Einschränkungen: - Link-Layer-Darstellung kann sich von einer konkreten Ethernetaufzeichnung unterscheiden, - derselbe Datenfluss kann an mehreren Stellen erscheinen, - Adressen können vor und nach NAT sichtbar sein, - Reihenfolge und Interpretation werden komplexer, - nicht jede hardwarenahe Information ist verfügbar. Für eine präzise Layer-2-Analyse sollte möglichst die konkrete Schnittstelle gewählt werden.
---
9. Promiscuous Mode und WLAN Monitor Mode unterscheiden **Promiscuous Mode:** Eine Ethernet-Schnittstelle nimmt zusätzlich Frames an, die nicht direkt an ihre eigene MAC-Adresse adressiert sind. In einem geswitchten Netzwerk werden dadurch jedoch nicht automatisch alle Frames anderer Switchports sichtbar. **WLAN Monitor Mode:** Ein geeigneter WLAN-Adapter erfasst 802.11-Funkframes auf einem bestimmten Kanal beziehungsweise Frequenzbereich. | Modus | Typische Verwendung | |---|---| | Normaler WLAN-Clientmodus | Verkehr des eigenen Clients untersuchen | | Promiscuous Mode | Zusätzliche sichtbare Ethernetframes erfassen | | Monitor Mode | WLAN-Management-, Kontroll- und Datenframes untersuchen | | Switch Port Mirroring | Verkehr ausgewählter Switchports oder VLANs spiegeln | | Network TAP | Physischer Messpunkt in einer Verbindung | Monitor Mode kann die normale WLAN-Verbindung unterbrechen und wird nicht von jeder Hardware, jedem Treiber oder Betriebssystem unterstützt.
---
10. Grenzen eines Mitschnitts im geswitchten Netzwerk Ein Client an einem Switchport sieht normalerweise: - eigenen Unicastverkehr, - Broadcastverkehr im eigenen Broadcastbereich, - relevanten Multicastverkehr, - bestimmte Kontrollprotokolle. Er sieht normalerweise nicht automatisch: - Unicastverkehr zwischen zwei anderen Switchports, - Verkehr in anderen VLANs, - Pakete hinter einer Firewall, - Verkehr eines anderen virtuellen Switches. Für fremden Unicastverkehr sind abhängig von Infrastruktur und Berechtigung erforderlich: - SPAN beziehungsweise Port Mirroring, - Remote SPAN, - Network TAP, - Aufzeichnung direkt auf dem Zielsystem, - Aufzeichnung auf Router oder Firewall. Ein falsch konfigurierter Mirror-Port kann Pakete verlieren, wenn die gespiegelte Datenmenge seine Kapazität überschreitet.
---
11. Capture Filter und Display Filter unterscheiden | Filterart | Zeitpunkt | Wirkung | |---|---|---| | Capture Filter | während der Aufzeichnung | Nur passende Pakete werden gespeichert | | Display Filter | nach beziehungsweise während der Anzeige | Alle gespeicherten Pakete bleiben erhalten, nur die Ansicht wird gefiltert | **Capture Filter:** ```text host 192.0.2.20 and tcp port 443 ``` **Wireshark Display Filter:** ```text ip.addr == 192.0.2.20 && tcp.port == 443 ``` Die Syntax ist nicht austauschbar. **Grundentscheidung:** - enger Capture Filter bei Datenschutz- oder Speicheranforderungen, - breiterer Capture Filter bei unklarer Ursache, - Display Filter für schrittweise Auswertung.
---
12. Wichtige Capture Filter | Aufgabe | Capture Filter | |---|---| | Einzelner Host | `host 192.0.2.20` | | Quelle | `src host 192.0.2.20` | | Ziel | `dst host 192.0.2.20` | | Zwei Hosts | `host 192.0.2.20 and host 192.0.2.53` | | Gesamtes IPv4-Netz | `net 192.0.2.0/24` | | TCP | `tcp` | | UDP | `udp` | | ICMP | `icmp` | | ICMPv6 | `icmp6` | | TCP-Port 443 | `tcp port 443` | | UDP-Port 53 | `udp port 53` | | Quellport | `src port 443` | | Zielport | `dst port 443` | | DNS über TCP oder UDP | `port 53` | | DHCPv4 | `udp port 67 or udp port 68` | | DHCPv6 | `udp port 546 or udp port 547` | | ARP | `arp` | | Host und Port | `host 192.0.2.20 and tcp port 443` | | Zwei Ports | `tcp port 80 or tcp port 443` | | Verkehr ohne SSH | `not tcp port 22` | Capture Filter verwenden die Syntax der Paketfilterbibliothek. Vor produktiven Aufzeichnungen sollte die lokale Unterstützung geprüft werden.
---
13. Wichtige Wireshark Display Filter | Aufgabe | Display Filter | |---|---| | IPv4-Adresse | `ip.addr == 192.0.2.20` | | IPv6-Adresse | `ipv6.addr == 2001:db8::20` | | Zwei IPv4-Systeme | `ip.addr == 192.0.2.20 && ip.addr == 192.0.2.53` | | TCP-Port | `tcp.port == 443` | | UDP-Port | `udp.port == 53` | | DNS | `dns` | | DHCPv4 | `dhcp` | | DHCPv6 | `dhcpv6` | | ARP | `arp` | | ICMP | `icmp` | | ICMPv6 | `icmpv6` | | HTTP-Anfragen | `http.request` | | HTTP-Antworten | `http.response` | | HTTP-Status 502 | `http.response.code == 502` | | TLS-Handshake | `tls.handshake` | | TCP-SYN | `tcp.flags.syn == 1` | | Erstes SYN ohne ACK | `tcp.flags.syn == 1 && tcp.flags.ack == 0` | | TCP-Reset | `tcp.flags.reset == 1` | | TCP-FIN | `tcp.flags.fin == 1` | | Wiederholungen | `tcp.analysis.retransmission` | | Doppelte ACKs | `tcp.analysis.duplicate_ack` | | Out-of-Order | `tcp.analysis.out_of_order` | | Zero Window | `tcp.analysis.zero_window` | | Vermutetes verlorenes Segment | `tcp.analysis.lost_segment` |
---
14. Linux mit tcpdump aufzeichnen **Alle Pakete einer Schnittstelle:** ```bash [TEST][PRIV][FILE][SENS] sudo tcpdump -i eth0 -nn \ -w capture.pcap ``` **Nur definierter Client und TCP-Port 443:** ```bash [TEST][PRIV][FILE][SENS] sudo tcpdump -i eth0 -nn \ 'host 192.0.2.25 and tcp port 443' \ -w https-test.pcap ``` **DNS-Verkehr:** ```bash [TEST][PRIV][FILE][SENS] sudo tcpdump -i eth0 -nn \ 'port 53' \ -w dns-test.pcap ``` **DHCPv4:** ```bash [TEST][PRIV][FILE][SENS] sudo tcpdump -i eth0 -nn \ 'udp port 67 or udp port 68' \ -w dhcp-test.pcap ``` **Ohne Datei, direkt lesbar:** ```bash [TEST][PRIV][SENS] sudo tcpdump -i eth0 -nn \ 'host 192.0.2.25 and tcp port 443' ``` `-nn` verhindert die Auflösung von Hostnamen und Dienstnamen. Dadurch wird die Ausgabe schneller und eindeutiger.
---
15. macOS mit tcpdump aufzeichnen Zuerst die tatsächliche Schnittstelle ermitteln: ```bash [RO] networksetup -listallhardwareports ``` **Beispiel für Ethernet oder WLAN auf en0:** ```bash [TEST][PRIV][FILE][SENS] sudo tcpdump -i en0 -nn \ 'host 192.0.2.25 and tcp port 443' \ -w https-test.pcap ``` **DNS-Verkehr:** ```bash [TEST][PRIV][FILE][SENS] sudo tcpdump -i en0 -nn \ 'port 53' \ -w dns-test.pcap ``` **VPN-Tunnel untersuchen:** ```bash [RO] ifconfig ``` Anschließend die tatsächlich ermittelte Tunnelschnittstelle verwenden: ```bash [TEST][PRIV][FILE][SENS] sudo tcpdump -i TUNNEL_INTERFACE -nn \ 'host INTERNES_ZIEL' \ -w vpn-inner.pcap ``` Schnittstellennamen wie `en0` oder `utun0` dürfen nicht ohne vorherige Prüfung vorausgesetzt werden.
---
16. Windows mit Dumpcap aufzeichnen Dumpcap ist Bestandteil einer Wireshark-Installation und kann ohne grafische Oberfläche aufzeichnen. **Schnittstellen anzeigen:** ```powershell [RO] dumpcap -D ``` **Auf Schnittstelle 1 aufzeichnen:** ```powershell [TEST][PRIV][FILE][SENS] dumpcap -i 1 ` -w capture.pcapng ``` **Mit Capture Filter:** ```powershell [TEST][PRIV][FILE][SENS] dumpcap -i 1 ` -f "host 192.0.2.25 and tcp port 443" ` -w https-test.pcapng ``` **Aufzeichnung nach 60 Sekunden beenden:** ```powershell [TEST][PRIV][FILE][SENS] dumpcap -i 1 ` -a duration:60 ` -w capture-60s.pcapng ``` Die Schnittstellennummer `1` ist nur ein Beispiel und muss vorher mit `dumpcap -D` ermittelt werden.
---
17. Windows mit Pktmon aufzeichnen Pktmon ist ein in Windows integriertes Diagnosewerkzeug. Es kann Pakete an mehreren Stellen innerhalb des Windows-Netzwerkstacks erfassen und verworfene Pakete erkennen. Vor Verwendung lokale Syntax prüfen: ```cmd [RO] pktmon help ``` **Aktuellen Status anzeigen:** ```cmd [RO][PRIV] pktmon status ``` **Netzwerkkomponenten anzeigen:** ```cmd [RO][PRIV][SENS] pktmon list ``` **Aufzeichnung in eine ETL-Datei starten:** ```cmd [TEST][PRIV][FILE][SENS] pktmon start --capture --pkt-size 0 --file-name pktmon.etl ``` **Fehler reproduzieren und Aufzeichnung beenden:** ```cmd [TEST][PRIV][FILE][SENS] pktmon stop ``` **ETL nach PCAPNG konvertieren:** ```cmd [RO][FILE][SENS] pktmon etl2pcap pktmon.etl --out pktmon.pcapng ``` Pktmon-Optionen können sich zwischen unterstützten Windows-Versionen unterscheiden. Vor einer produktiven Aufzeichnung müssen die lokale Hilfe und der geplante Umfang geprüft werden.
---
18. Pktmon-Drop-Erkennung richtig behandeln Pktmon kann zusätzlich Informationen über innerhalb des Windows-Netzwerkstacks verworfene Pakete erfassen. **Pktmon-Zähler anzeigen:** ```cmd [RO][PRIV][SENS] pktmon counters ``` **Nur als verworfen markierte Pakete konvertieren:** ```cmd [RO][FILE][SENS] pktmon etl2pcap pktmon.etl ^ --drop-only ^ --out pktmon-drops.pcapng ``` Microsoft weist darauf hin, dass bei der PCAPNG-Konvertierung bestimmte Pktmon-Metadaten verloren gehen können. PCAPNG unterscheidet danach nicht automatisch zwischen regulär weitergeleiteten und verworfenen Paketen. Deshalb sollten bei Bedarf getrennte Dateien erzeugt werden: ```text vollständige Aufzeichnung + separate Drop-Aufzeichnung + ursprüngliche ETL-Datei ``` Die ursprüngliche ETL-Datei muss geschützt aufbewahrt werden, wenn die zusätzlichen Pktmon-Informationen für die Diagnose benötigt werden.
---
19. Ringspeicher mit Dumpcap verwenden Eine unbegrenzte Aufzeichnung kann den Datenträger füllen. Dumpcap unterstützt Ringspeicher mit mehreren Dateien. **Datei alle fünf Minuten wechseln und maximal zwölf Dateien behalten:** ```powershell [TEST][PRIV][FILE][SENS] dumpcap -i 1 ` -b duration:300 ` -b files:12 ` -w ringbuffer.pcapng ``` **Zusätzlich Capture Filter verwenden:** ```powershell [TEST][PRIV][FILE][SENS] dumpcap -i 1 ` -f "host 192.0.2.25" ` -b duration:300 ` -b files:12 ` -w ringbuffer.pcapng ``` Damit werden ungefähr die letzten 60 Minuten in zwölf Fünf-Minuten-Dateien gehalten. Dateiverarbeitung und Wechselverhalten müssen mit der installierten Dumpcap-Version geprüft werden.
---
20. Größenbegrenzten Ringspeicher mit tcpdump verwenden **Datei nach ungefähr 100 Millionen Byte wechseln und maximal zehn Dateien verwenden:** ```bash [TEST][PRIV][FILE][SENS] sudo tcpdump -i eth0 -nn \ -C 100 \ -W 10 \ -w capture.pcap ``` **Mit Filter:** ```bash [TEST][PRIV][FILE][SENS] sudo tcpdump -i eth0 -nn \ 'host 192.0.2.25' \ -C 100 \ -W 10 \ -w capture.pcap ``` Die genaue Dateibenennung und Rotation hängt von der installierten tcpdump-Version ab. Vor einer Langzeitaufzeichnung lokale Hilfe prüfen: ```bash [RO] tcpdump --help ``` oder: ```bash [RO] man tcpdump ```
---
21. Capture-Länge und vollständige Pakete berücksichtigen Die Capture-Länge bestimmt, wie viele Byte eines Pakets gespeichert werden. **tcpdump – vollständige Pakete anfordern:** ```bash [TEST][PRIV][FILE][SENS] sudo tcpdump -i eth0 -nn \ -s 0 \ -w capture.pcap ``` Bei aktuellen tcpdump-Versionen bedeutet `-s 0`, dass die vom Werkzeug unterstützte maximale Paketlänge erfasst wird. **Abwägung:** | Kurze Capture-Länge | Vollständige Pakete | |---|---| | weniger Speicherbedarf | höhere Datenmenge | | geringeres Datenschutzrisiko | mehr Protokolldetails | | Nutzdaten möglicherweise abgeschnitten | Nutzdaten möglicherweise vollständig enthalten | | Headeranalyse häufig möglich | Anwendungsanalyse eher möglich | Für eine reine Headeranalyse sollte geprüft werden, ob eine begrenzte Capture-Länge ausreicht.
---
22. tcpdump-Datei nachträglich lesen **PCAP-Datei ohne Namensauflösung anzeigen:** ```bash [RO][SENS] tcpdump -nn -r capture.pcap ``` **Nur TCP-Port 443 aus einer vorhandenen Datei anzeigen:** ```bash [RO][SENS] tcpdump -nn -r capture.pcap \ 'tcp port 443' ``` **Zeitstempel ausführlicher anzeigen:** ```bash [RO][SENS] tcpdump -tttt -nn -r capture.pcap ``` Das nachträgliche Filter verändert die Originaldatei nicht.
---
23. TShark für automatisierte Auswertung verwenden TShark ist die Kommandozeilenversion der Wireshark-Protokollanalyse. **Schnittstellen anzeigen:** ```bash [RO] tshark -D ``` **Vorhandene Datei lesen:** ```bash [RO][SENS] tshark -r capture.pcapng ``` **Display Filter anwenden:** ```bash [RO][SENS] tshark -r capture.pcapng \ -Y 'tcp.port == 443' ``` **DNS-Anfragen ausgeben:** ```bash [RO][SENS] tshark -r capture.pcapng \ -Y 'dns.flags.response == 0' \ -T fields \ -e frame.time \ -e ip.src \ -e dns.qry.name ``` **TCP-Wiederholungen ausgeben:** ```bash [RO][SENS] tshark -r capture.pcapng \ -Y 'tcp.analysis.retransmission' ``` **HTTP-Statuscodes:** ```bash [RO][SENS] tshark -r capture.pcapng \ -Y 'http.response' \ -T fields \ -e frame.time \ -e ip.src \ -e ip.dst \ -e http.response.code ```
---
24. Capture Filter und Display Filter bei TShark verwenden **Capture Filter während der Aufzeichnung:** ```bash [TEST][PRIV][FILE][SENS] tshark -i INTERFACE \ -f 'host 192.0.2.25 and tcp port 443' \ -w capture.pcapng ``` **Display Filter auf vorhandener Datei:** ```bash [RO][SENS] tshark -r capture.pcapng \ -Y 'ip.addr == 192.0.2.25 && tcp.port == 443' ``` Zuordnung: ```text -f = Capture Filter -Y = Display Filter ``` Ein Display Filter kann nicht als Capture Filter übernommen werden, wenn er eine Wireshark-spezifische Syntax verwendet.
---
25. Dateien mit capinfos untersuchen `capinfos` gehört zur Wireshark-Werkzeugsammlung. **Grundinformationen:** ```bash [RO][SENS] capinfos capture.pcapng ``` Mögliche Angaben: - Dateiformat, - Anzahl der Pakete, - Datenmenge, - Startzeit, - Endzeit, - Aufzeichnungsdauer, - durchschnittliche Paketrate, - Datenrate, - Schnittstelleninformationen. **Mehrere Dateien vergleichen:** ```bash [RO][SENS] capinfos client.pcapng server.pcapng ``` Damit lassen sich unter anderem Zeitbereiche und Größen vor einer Zusammenführung kontrollieren.
---
26. Mitschnitte mit mergecap zusammenführen `mergecap` führt mehrere Capture-Dateien in eine neue Datei zusammen. ```bash [RO][FILE][SENS] mergecap \ -w combined.pcapng \ client.pcapng \ server.pcapng ``` Vorher müssen geprüft werden: - Zeitstempel, - Zeitzone, - Uhrabweichung, - unterschiedliche Schnittstellen, - mögliche Paketduplikate, - unterschiedliche Messpunkte, - NAT- oder Proxyübersetzung. Eine zusammengeführte Datei kann dasselbe Paket mehrfach enthalten, wenn es an mehreren Messpunkten erfasst wurde.
---
27. Mitschnitte mit editcap begrenzen `editcap` kann Capture-Dateien bearbeiten, aufteilen oder zeitlich begrenzen. **Lokale Hilfe:** ```bash [RO] editcap --help ``` **Erste 1.000 Pakete in neue Datei schreiben:** ```bash [RO][FILE][SENS] editcap -r capture.pcapng \ capture-first-1000.pcapng \ 1-1000 ``` **Datei in Paketeinheiten aufteilen:** ```bash [RO][FILE][SENS] editcap -c 10000 \ capture.pcapng \ capture-part.pcapng ``` Vor dem Bearbeiten muss die Originaldatei unverändert aufbewahrt werden. Eine verkleinerte Datei kann für die Weitergabe sinnvoll sein, entfernt aber nicht automatisch alle sensiblen Inhalte.
---
28. Paketnamen und Frame-Nummern richtig verwenden In Wireshark sind wichtige Spalten: | Spalte | Bedeutung | |---|---| | No. | Frame-Nummer innerhalb der geöffneten Datei | | Time | Zeitstempel beziehungsweise relative Zeit | | Source | Quelladresse | | Destination | Zieladresse | | Protocol | erkannter Protokolldissektor | | Length | Frame- beziehungsweise Paketlänge | | Info | zusammengefasste Protokollinformation | **Wichtig:** Frame-Nummern gelten nur innerhalb der konkreten Datei. Nach Filterung, Zusammenführung oder Bearbeitung können sich Nummern ändern. Für eine belastbare Dokumentation zusätzlich angeben: - Dateiname, - Zeitstempel, - Quell- und Zieladresse, - Protokoll, - relevante Sequenz- oder Transaktionskennung.
---
29. Wireshark Follow Stream verwenden Wireshark kann zusammengehörige Datenströme darstellen: - Follow TCP Stream, - Follow UDP Stream, - Follow TLS Stream, - Follow HTTP Stream, - weitere protokollspezifische Streams. Damit lassen sich beispielsweise betrachten: - Anfragen und Antworten, - Reihenfolge der Daten, - Klartextprotokolle, - Verbindungsabbrüche, - HTTP-Fehler, - Protokolldialoge. **Sicherheitswarnung:** Follow Stream kann vollständige unverschlüsselte Anwendungsdaten und Zugangsinformationen anzeigen. Inhalte dürfen nicht ungeprüft kopiert oder weitergegeben werden.
---
30. TCP-Handshake analysieren **Erfolgreicher Verbindungsaufbau:** ```text Client → Server: SYN Server → Client: SYN, ACK Client → Server: ACK ``` **Wireshark-Filter:** ```text tcp.flags.syn == 1 ``` **Nur erste SYN-Pakete:** ```text tcp.flags.syn == 1 && tcp.flags.ack == 0 ``` | Paketmuster | Typische Interpretation | |---|---| | SYN, SYN-ACK, ACK | TCP-Verbindung aufgebaut | | Wiederholte SYN ohne Antwort | Drop, Verlust, falscher Rückweg oder Ziel nicht erreichbar | | SYN gefolgt von RST/ACK | Ziel erreichbar, Port geschlossen oder aktiv abgelehnt | | SYN-ACK erreicht Client, ACK fehlt | Clientseite oder Rückweg des ACK prüfen | | Handshake erfolgreich, danach RST | Anwendung, Proxy oder Sicherheitskomponente beendet Verbindung | | Handshake erfolgreich, keine Nutzdaten | Anwendung wartet oder Protokollablauf fehlerhaft |
---
31. TCP-Verbindungsabbau analysieren Ein regulärer TCP-Abbau verwendet FIN- und ACK-Segmente. Ein RST beendet eine Verbindung unmittelbar. **Filter:** ```text tcp.flags.fin == 1 || tcp.flags.reset == 1 ``` | Beobachtung | Mögliche Bedeutung | |---|---| | FIN/ACK-Austausch | geordneter Verbindungsabbau | | RST vom Client | Clientanwendung oder lokales System bricht ab | | RST vom Server | Serveranwendung oder Serverstack bricht ab | | RST von unbekannter Zwischenadresse | Firewall, Proxy oder anderes Zwischensystem möglich | | FIN nach Anwendungserfolg | häufig normal | | RST direkt nach TLS-Start | TLS-, Richtlinien- oder Protokollproblem möglich | Die Quelladresse eines RST allein beweist nicht immer seine tatsächliche Herkunft, da Sicherheitsgeräte Pakete im Namen eines Endpunkts erzeugen können.
---
32. TCP-Wiederholungen vorsichtig interpretieren **Filter:** ```text tcp.analysis.retransmission ``` Weitere Filter: ```text tcp.analysis.fast_retransmission tcp.analysis.spurious_retransmission tcp.analysis.duplicate_ack tcp.analysis.out_of_order tcp.analysis.lost_segment ``` Mögliche Ursachen: - tatsächlicher Paketverlust, - Paketverlust nur am Capture-Messpunkt, - asymmetrisches Routing, - NIC-Offloading, - Start der Aufzeichnung mitten in der Verbindung, - Pakete in anderer Reihenfolge, - überlasteter Messrechner, - Mirror-Port verwirft Pakete. Wireshark-Analyseflags sind Interpretationen. Sie müssen mit Sequenznummern, ACKs und möglichst einem Mitschnitt der Gegenstelle überprüft werden.
---
33. NIC-Offloading und ungewöhnliche Paketgrößen berücksichtigen Netzwerkadapter und Betriebssysteme können Verarbeitung auslagern: - TCP Segmentation Offload, - Large Send Offload, - Generic Segmentation Offload, - Generic Receive Offload, - Checksum Offload. Dadurch können lokale Mitschnitte zeigen: - scheinbar falsche Prüfsummen, - Pakete größer als die physische MTU, - zusammengefasste Segmente, - Segmentierung erst nach dem Capture-Punkt. **Typischer Hinweis:** ```text Checksum incorrect ``` direkt auf dem sendenden Host bedeutet nicht automatisch, dass das Paket mit falscher Prüfsumme auf dem Netzwerk übertragen wurde. Die Netzwerkkarte kann die Prüfsumme erst nach dem lokalen Capture-Punkt berechnen. Ein Mitschnitt auf der Gegenstelle oder einem externen TAP zeigt eher den tatsächlich übertragenen Zustand.
---
34. ARP und IPv6 Neighbor Discovery analysieren **ARP-Filter:** ```text arp ``` **Typischer IPv4-Ablauf:** ```text Who has 192.0.2.1? 192.0.2.1 is at 00:11:22:33:44:55 ``` Zu prüfen sind: - Anfrage sichtbar, - Antwort sichtbar, - richtige MAC-Adresse, - mehrere Antworten, - häufige Wiederholungen, - Gratuitous ARP, - Adresskonflikt. **IPv6 Neighbor Discovery:** ```text icmpv6 ``` Zu prüfen sind unter anderem: - Neighbor Solicitation, - Neighbor Advertisement, - Router Solicitation, - Router Advertisement, - Duplicate Address Detection, - Packet Too Big. ICMPv6 darf nicht pauschal als unwichtiger Diagnoseverkehr betrachtet werden.
---
35. DHCPv4-Ablauf analysieren **Capture Filter:** ```text udp port 67 or udp port 68 ``` **Display Filter:** ```text dhcp ``` Typischer Ablauf: ```text DHCP Discover DHCP Offer DHCP Request DHCP ACK ``` Bekannt als: ```text DORA ``` | Fehlendes Paket | Mögliche Eingrenzung | |---|---| | Kein Discover sichtbar | Client oder falsche Schnittstelle prüfen | | Discover, kein Offer | DHCP-Server, Relay, VLAN oder Filter prüfen | | Offer sichtbar, Client fordert nicht an | Client, Auswahl oder fehlerhaftes Angebot | | Request, kein ACK | Server, Adresspool, Richtlinie oder Relay | | DHCP NAK | Adresse oder Netzzuordnung wird abgelehnt | | Mehrere unterschiedliche Offers | mehrere DHCP-Server vorhanden |
---
36. DNS-Ablauf analysieren **Capture Filter:** ```text port 53 ``` **Display Filter:** ```text dns ``` **Nur DNS-Anfragen:** ```text dns.flags.response == 0 ``` **Nur DNS-Antworten:** ```text dns.flags.response == 1 ``` **Bestimmter Name:** ```text dns.qry.name == "service.example.internal" ``` Zu prüfen sind: - richtige Zieladresse des DNS-Servers, - Anfrage über UDP oder TCP, - Antwortzeit, - Antwortcode, - zurückgegebene A- und AAAA-Adressen, - CNAME-Kette, - Wiederholungen, - Wechsel zu TCP, - unterschiedliche Antworten verschiedener Resolver. **Typische Antwortcodes:** | Code | Bedeutung | |---|---| | `NOERROR` | Anfrage wurde ohne DNS-Fehler verarbeitet | | `NXDOMAIN` | Name existiert laut Antwort nicht | | `SERVFAIL` | Resolver konnte Anfrage nicht erfolgreich bearbeiten | | `REFUSED` | Server verweigert die Anfrage |
---
37. TLS-Handshake analysieren **Filter:** ```text tls.handshake ``` Typischer Ablauf kann enthalten: ```text Client Hello Server Hello Certificate Schlüsselaustausch Finished Application Data ``` Zu prüfen sind: - verwendeter Servername über SNI, - angebotene TLS-Versionen, - ausgewählte TLS-Version, - Cipher Suites, - präsentierte Zertifikate, - TLS-Alerts, - Zeitpunkt des Abbruchs, - erfolgreiche Application Data nach dem Handshake. **TLS-Alerts:** ```text tls.alert_message ``` Verschlüsselte Anwendungsdaten können ohne zulässige Sitzungsschlüssel nicht inhaltlich analysiert werden. Private Server-Schlüssel sind bei modernen Verfahren nicht automatisch ausreichend, um aufgezeichnete Sitzungen nachträglich zu entschlüsseln.
---
38. HTTP- und Proxyfehler analysieren **HTTP-Anfragen:** ```text http.request ``` **HTTP-Antworten:** ```text http.response ``` **Statuscode:** ```text http.response.code ``` **Proxy-CONNECT:** ```text http.request.method == "CONNECT" ``` Zu prüfen sind: - Hostheader, - Methode, - angefragter Pfad, - Statuscode, - Weiterleitungen, - Proxy-Authentifizierung, - Antwortzeit, - Verbindungsabbruch, - Reverse-Proxy-Header. Bei HTTPS sind HTTP-Inhalte normalerweise verschlüsselt. Sichtbar bleiben abhängig vom Verfahren unter anderem IP-Adressen, Ports, TLS-Handshake und teilweise Servername.
---
39. ICMP- und ICMPv6-Fehler auswerten **Filter:** ```text icmp || icmpv6 ``` Mögliche Meldungen: - Destination Unreachable, - Port Unreachable, - Network Unreachable, - Host Unreachable, - Administratively Prohibited, - Time Exceeded, - Fragmentation Needed, - Packet Too Big, - Redirect. Diese Meldungen enthalten häufig Teile des ursprünglichen Pakets. Dadurch kann festgestellt werden, welche Verbindung die Fehlermeldung ausgelöst hat. ICMP-Fehlermeldungen sind wichtige Bestandteile der Netzwerkfunktion und nicht nur Ping-Antworten.
---
40. NAT-, Proxy- und Containerpfade vergleichen **Vor NAT:** ```text 192.168.10.25:53144 → 198.51.100.20:443 ``` **Nach SNAT:** ```text 203.0.113.10:62001 → 198.51.100.20:443 ``` **Vor DNAT:** ```text 198.51.100.25:54000 → 203.0.113.10:8443 ``` **Nach DNAT:** ```text 198.51.100.25:54000 → 192.168.10.50:443 ``` Für die Zuordnung werden benötigt: - Zeitstempel, - Protokoll, - ursprüngliche Quelladresse, - übersetzte Quelladresse, - ursprüngliche Zieladresse, - übersetzte Zieladresse, - Ports, - TCP-Sequenznummern, - NAT- beziehungsweise Conntrack-Eintrag. Auf Containerhosts kann derselbe Datenfluss an Host-, Bridge- und Containerinterface mehrfach erscheinen.
---
41. Virtuelle Maschinen und Container richtig erfassen Mögliche Messpunkte: ```text physischer Host virtueller Switch VM-Schnittstelle Container-Bridge Container-Netzwerk-Namespace Anwendungscontainer ``` Zu prüfen sind: - Wird NAT verwendet? - Verwendet die VM Bridge- oder Host-Only-Networking? - Ist der Containerport veröffentlicht? - Baut ein Reverse Proxy die Backendverbindung auf? - Existieren mehrere virtuelle Bridges? - Sieht der Host den Verkehr vor oder nach NAT? - Wird Hardware-Offloading eingesetzt? - Greift eine Hypervisor- oder Cloud-Firewall? Ein Mitschnitt auf dem Administrator-PC beantwortet keine Frage über eine interne Container-zu-Container-Verbindung.
---
42. Verschlüsselung und ihre Analysegrenzen Verschlüsselte Protokolle schützen die Nutzdaten: - HTTPS beziehungsweise TLS, - SSH, - VPN, - SMB-Verschlüsselung, - IPsec, - WireGuard, - verschlüsselte Datenbankverbindungen. Ohne zulässige Entschlüsselungsinformationen sind häufig trotzdem sichtbar: - Quell- und Zieladressen, - Ports, - Paketgrößen, - Zeitstempel, - Verbindungsaufbau, - Verbindungsabbau, - Wiederholungen, - TLS-Versionen, - Zertifikate im Handshake, - bestimmte Servernamen, - Datenmengen, - Antwortpausen. **Nicht durchführen:** - private Schlüssel exportieren, - TLS-Prüfung umgehen, - fremde Sitzungen entschlüsseln, - produktive Geheimnisse in Wireshark hinterlegen, - Schlüsselprotokolldateien ungeschützt speichern.
---
43. Fehler bei der Aufzeichnung selbst erkennen Ein Capture-System kann Pakete verlieren. Mögliche Ursachen: - zu hohe Paketrate, - langsamer Datenträger, - kleine Capture-Puffer, - überlastete CPU, - zu breite Aufzeichnung, - Mirror-Port überlastet, - mehrere gespiegelte Vollduplexlinks auf zu kleinem Zielport, - virtuelle Capture-Schicht, - Treiberproblem, - USB-Netzwerkadapter, - Remote-Capture-Verbindung. Wireshark, Dumpcap oder tcpdump können Informationen über vom Capture-Prozess verworfene Pakete ausgeben. **Wichtig:** ```text Im Mitschnitt fehlend ≠ sicher im Netzwerk verloren ``` Das Paket kann lediglich vom Messsystem nicht gespeichert worden sein.
---
44. Aussagekräftige Dateinamen verwenden Empfohlenes Schema: ```text DATUM_UHRZEIT_MESSPUNKT_QUELLE_ZIEL_PROTOKOLL.pcapng ``` Beispiel: ```text 2026-07-31_143500_client01_web01_https.pcapng ``` Keine sensiblen Benutzernamen oder vollständigen personenbezogenen Angaben in Dateinamen verwenden. Zusätzlich eine Textnotiz anlegen: ```text Dateiname: Messpunkt: Schnittstelle: Capture Filter: Startzeit: Fehlerzeit: Endzeit: Client: Server: Testhandlung: Zeitzone: Bearbeiter: ```
---
45. Sichere Aufbewahrung und Weitergabe Vor einer Weitergabe: 1. Originaldatei geschützt aufbewahren. 2. Nur relevanten Zeitbereich extrahieren. 3. Nur benötigte Pakete übernehmen. 4. Nutzdaten auf sensible Inhalte prüfen. 5. DNS-Namen, Adressen und Identitäten bewerten. 6. Unternehmensrichtlinien beachten. 7. Empfänger und Übertragungsweg festlegen. 8. Aufbewahrungsfrist dokumentieren. 9. Nicht mehr benötigte Kopien kontrolliert löschen. Eine PCAP-Datei ist kein harmloser Screenshot. Sie kann vollständige Kommunikationsinhalte enthalten.
---
46. Systematischer Ablauf einer Paketaufzeichnung | Schritt | Aufgabe | Leitfrage | |---:|---|---| | 1 | Fehlerhypothese formulieren | Welches Paketmuster wird erwartet? | | 2 | Datenfluss dokumentieren | Welche Quelle kommuniziert mit welchem Ziel? | | 3 | Messpunkt auswählen | Wo muss das Paket sichtbar sein? | | 4 | Schnittstelle bestimmen | Über welches Interface führt die Route? | | 5 | Zeit synchronisieren | Können mehrere Datenquellen verglichen werden? | | 6 | Datenschutzumfang festlegen | Welche Daten dürfen aufgezeichnet werden? | | 7 | Capture Filter wählen | Welche Pakete werden wirklich benötigt? | | 8 | Speicherbegrenzung planen | Dauer, Größe oder Ringspeicher? | | 9 | Aufzeichnung starten | Läuft sie auf der richtigen Schnittstelle? | | 10 | Fehler einmal reproduzieren | Ist der Zeitpunkt exakt dokumentiert? | | 11 | Aufzeichnung beenden | Wurde unnötige weitere Erfassung vermieden? | | 12 | Capture-Verluste prüfen | Hat das Messsystem Pakete verworfen? | | 13 | Display Filter anwenden | Welcher einzelne Datenfluss ist relevant? | | 14 | Protokollablauf untersuchen | Wo weicht Ist vom Soll ab? | | 15 | Gegenstelle vergleichen | Ist Verlust oder Verzögerung lokalisierbar? | | 16 | Systemprotokolle abgleichen | Warum wurde das Paket abgelehnt? | | 17 | Ergebnis dokumentieren | Welche Frames belegen die Ursache? | | 18 | Daten sichern oder bereinigen | Welche Aufbewahrung ist erforderlich? |
---
47. Kompakte Befehlstabelle | Aufgabe | Windows | Linux | macOS | |---|---|---|---| | Schnittstellen anzeigen | `[RO] dumpcap -D` | `[RO] tcpdump -D` | `[RO] tcpdump -D` | | Route zum Ziel | `[RO] Find-NetRoute -RemoteIPAddress IP` | `[RO] ip route get IP` | `[RO] route -n get IP` | | Gesamte Aufzeichnung | `[TEST][PRIV][FILE][SENS] dumpcap -i NUMMER -w capture.pcapng` | `[TEST][PRIV][FILE][SENS] sudo tcpdump -i INTERFACE -nn -w capture.pcap` | `[TEST][PRIV][FILE][SENS] sudo tcpdump -i INTERFACE -nn -w capture.pcap` | | Hostfilter | `[TEST][PRIV][FILE][SENS] dumpcap -i NUMMER -f "host IP" -w host.pcapng` | `[TEST][PRIV][FILE][SENS] sudo tcpdump -i INTERFACE -nn 'host IP' -w host.pcap` | `[TEST][PRIV][FILE][SENS] sudo tcpdump -i INTERFACE -nn 'host IP' -w host.pcap` | | Portfilter | `[TEST][PRIV][FILE][SENS] dumpcap -i NUMMER -f "tcp port 443" -w https.pcapng` | `[TEST][PRIV][FILE][SENS] sudo tcpdump -i INTERFACE -nn 'tcp port 443' -w https.pcap` | `[TEST][PRIV][FILE][SENS] sudo tcpdump -i INTERFACE -nn 'tcp port 443' -w https.pcap` | | 60 Sekunden | `[TEST][PRIV][FILE][SENS] dumpcap -i NUMMER -a duration:60 -w test.pcapng` | `[TEST][PRIV][FILE][SENS] timeout 60 sudo tcpdump -i INTERFACE -nn -w test.pcap` – Verfügbarkeit von `timeout` prüfen | Beendigung kontrolliert per Tastatur oder Werkzeugoption planen | | Ringspeicher | `[TEST][PRIV][FILE][SENS] dumpcap -i NUMMER -b duration:300 -b files:12 -w ring.pcapng` | `[TEST][PRIV][FILE][SENS] sudo tcpdump -i INTERFACE -nn -C 100 -W 10 -w ring.pcap` | `[TEST][PRIV][FILE][SENS] sudo tcpdump -i INTERFACE -nn -C 100 -W 10 -w ring.pcap` | | PCAP lesen | `[RO][SENS] tshark -r capture.pcapng` | `[RO][SENS] tcpdump -nn -r capture.pcap` | `[RO][SENS] tcpdump -nn -r capture.pcap` | | Display Filter | `[RO][SENS] tshark -r capture.pcapng -Y "tcp.port == 443"` | `[RO][SENS] tshark -r capture.pcap -Y "tcp.port == 443"` | `[RO][SENS] tshark -r capture.pcap -Y "tcp.port == 443"` | | Dateiinformationen | `[RO][SENS] capinfos capture.pcapng` | `[RO][SENS] capinfos capture.pcap` | `[RO][SENS] capinfos capture.pcap` | | Windows-Inbox-Capture | `[TEST][PRIV][FILE][SENS] pktmon start --capture --pkt-size 0 --file-name pktmon.etl` | Nicht zutreffend | Nicht zutreffend | | Pktmon beenden | `[TEST][PRIV][FILE][SENS] pktmon stop` | Nicht zutreffend | Nicht zutreffend | | Pktmon konvertieren | `[RO][FILE][SENS] pktmon etl2pcap pktmon.etl --out pktmon.pcapng` | Nicht zutreffend | Nicht zutreffend | `NUMMER`, `INTERFACE` und `IP` müssen durch die zuvor ermittelten Werte ersetzt werden.
---
48. Dokumentationsvorlage für Paketmitschnitte ```text Störung: Hypothese: Erwartetes Paketmuster: Zeitpunkt: Zeitzone: Clienthostname: Client-IP: Client-MAC: Serverhostname: Server-IP: Serverport: Transportprotokoll: Anwendungsprotokoll: IPv4 oder IPv6: Messpunkt 1: Messsystem 1: Schnittstelle 1: Capture Filter 1: Dateiname 1: Startzeit 1: Endzeit 1: Verworfene Capture-Pakete 1: Messpunkt 2: Messsystem 2: Schnittstelle 2: Capture Filter 2: Dateiname 2: Startzeit 2: Endzeit 2: Verworfene Capture-Pakete 2: Fehler ausgelöst um: Auslösende Handlung: Beobachtete Fehlermeldung: Relevanter Datenstrom: Relevante Frame-Nummern: Relevante Zeitstempel: TCP-Handshake: DNS-Ablauf: TLS-Handshake: HTTP-Status: ICMP-Fehler: Wiederholungen: Verbindungsabbau: Paket verlässt Client: Paket erreicht Server: Server antwortet: Antwort erreicht Client: Festgestellte Verluststelle: Zusätzliche Systemprotokolle: Festgestellte Ursache: Datenschutzprüfung: Originaldatei geschützt gespeichert: Reduzierte Weitergabedatei: Aufbewahrungsfrist: Ergebnis der Nachprüfung: ```
---
49. Kontrollfragen nach der Analyse - Wurde vorab eine konkrete Hypothese formuliert? - Sind Quelle, Ziel, Protokoll und Port bekannt? - Wurde die richtige Schnittstelle gewählt? - Führt die Route tatsächlich über diese Schnittstelle? - Ist der Messpunkt für die untersuchte Verbindung geeignet? - Wurde zwischen Capture Filter und Display Filter unterschieden? - Wurde der Aufzeichnungsumfang begrenzt? - Wurde der Fehlerzeitpunkt exakt dokumentiert? - Sind die Uhren der Messsysteme synchronisiert? - Hat der Capture-Prozess selbst Pakete verworfen? - Wurden NIC-Offloading-Effekte berücksichtigt? - Wurde Zwischenhop- beziehungsweise Mirror-Port-Verlust berücksichtigt? - Wurde ein Mitschnitt der Gegenstelle erstellt? - Wurden IPv4 und IPv6 unterschieden? - Wurden DNS, ARP und ICMP als Begleitprotokolle berücksichtigt? - Wurde ein fehlendes Paket nicht vorschnell als Netzwerkverlust bewertet? - Wurde ein Wireshark-Analyseflag als Interpretation und nicht als Beweis behandelt? - Wurden System-, Firewall- und Anwendungsprotokolle abgeglichen? - Enthält die Datei sensible Daten? - Wurde nur der erforderliche Ausschnitt weitergegeben? - Wurde die Originaldatei unverändert geschützt? - Belegen konkrete Pakete beziehungsweise Zeitstempel die festgestellte Ursache?
---
50. Quellen und weiterführende Dokumentation - Wireshark – Benutzerhandbuch: https://www.wireshark.org/docs/wsug_html_chunked/ - Wireshark – Capture Filters: https://wiki.wireshark.org/CaptureFilters - Wireshark – Display Filters: https://www.wireshark.org/docs/wsug_html_chunked/ChWorkBuildDisplayFilterSection.html - Wireshark – Display Filter Reference: https://www.wireshark.org/docs/dfref/ - Wireshark – Kommandozeilen-Handbücher: https://www.wireshark.org/docs/man-pages/ - Wireshark – Dumpcap-Handbuch: https://www.wireshark.org/docs/man-pages/dumpcap.html - Wireshark – TShark-Handbuch: https://www.wireshark.org/docs/man-pages/tshark.html - Wireshark – Capinfos-Handbuch: https://www.wireshark.org/docs/man-pages/capinfos.html - Wireshark – Mergecap-Handbuch: https://www.wireshark.org/docs/man-pages/mergecap.html - Wireshark – Editcap-Handbuch: https://www.wireshark.org/docs/man-pages/editcap.html - tcpdump – Projektseite und Dokumentation: https://www.tcpdump.org/ - libpcap – Capture-Filter-Syntax: https://www.tcpdump.org/manpages/pcap-filter.7.html - Microsoft Learn – Packet Monitor Pktmon: https://learn.microsoft.com/windows-server/administration/windows-commands/pktmon - Microsoft Learn – Pktmon-Übersicht: https://learn.microsoft.com/windows-server/networking/technologies/pktmon/pktmon - Microsoft Learn – Pktmon ETL nach PCAPNG konvertieren: https://learn.microsoft.com/windows-server/administration/windows-commands/pktmon-etl2pcap - RFC 9293 – Transmission Control Protocol: https://www.rfc-editor.org/rfc/rfc9293.html - RFC 8200 – Internet Protocol Version 6: https://www.rfc-editor.org/rfc/rfc8200.html
# 3.17 Befehlsübersicht – Netzwerkdiagnose unter Windows, Linux und macOS Diese Seite dient als schnelle Befehlsreferenz für die systematische Netzwerkdiagnose. Die ausführliche Interpretation, Fehlerbilder und Sicherheitsregeln stehen auf den vorherigen Seiten dieses Kapitels. ---
1. Kennzeichnungen | Kennzeichnung | Bedeutung | |---|---| | `[RO]` | Rein lesender Befehl | | `[TEST]` | Aktiver Test, der Netzwerkverkehr erzeugt | | `[PRIV]` | Administrator- oder Root-Rechte können erforderlich sein | | `[FILE]` | Ausgabe wird in eine Datei geschrieben | | `[SENS]` | Ausgabe kann sensible Informationen enthalten | | `[CHANGE]` | Befehl verändert eine Konfiguration | | `[DISRUPT]` | Befehl kann Verbindungen oder Dienste beeinträchtigen | **Platzhalter:** | Platzhalter | Ersetzen durch | |---|---| | `INTERFACE` | Tatsächlicher Schnittstellenname | | `HOST` | Hostname des Zielsystems | | `IP` | IP-Adresse | | `PORT` | TCP- oder UDP-Port | | `DNS_SERVER` | IP-Adresse des DNS-Servers | | `CONTAINER` | Tatsächlicher Containername | | `ZONE` | Tatsächliche firewalld-Zone | | `DIENST` | Tatsächlicher Dienstname | | `DATEI` | Gewünschter Dateiname beziehungsweise Pfad | Befehle mit Platzhaltern dürfen nicht unverändert ausgeführt werden.
---
2. Empfohlene Kurzreihenfolge | Schritt | Prüfung | Leitfrage | |---:|---|---| | 1 | Schnittstellenstatus | Ist der Adapter aktiv und verbunden? | | 2 | IP-Konfiguration | Stimmen Adresse, Präfix, Gateway und DNS? | | 3 | Loopback | Funktioniert der lokale TCP/IP-Stack? | | 4 | Eigene Adresse | Ist die lokale Schnittstelle erreichbar? | | 5 | Gateway | Funktioniert das lokale Netz? | | 6 | Entfernte IP | Funktionieren Routing und Rückweg? | | 7 | DNS | Wird der richtige Name aufgelöst? | | 8 | Route | Welcher Pfad und welche Schnittstelle werden verwendet? | | 9 | Port | Ist der benötigte Transportdienst erreichbar? | | 10 | Anwendung | Antwortet das tatsächliche Protokoll? | | 11 | Firewall, NAT, VPN oder Proxy | Wo wird der Datenfluss beeinflusst? | | 12 | Paketmitschnitt | Welches Paketmuster belegt die Ursache? |
---
3. Betriebssystem, Hostname, Zeit und Benutzer | Aufgabe | Windows | Linux | macOS | |---|---|---|---| | Betriebssystem | `[RO] Get-ComputerInfo` | `[RO] cat /etc/os-release` | `[RO] sw_vers` | | Kernel beziehungsweise Systemversion | `[RO] systeminfo` | `[RO] uname -a` | `[RO] uname -a` | | Hostname | `[RO] hostname` | `[RO] hostnamectl` | `[RO] scutil --get ComputerName` | | Aktueller Benutzer | `[RO] whoami` | `[RO] id` | `[RO] id` | | Lokale Zeit | `[RO] Get-Date -Format o` | `[RO] date --iso-8601=seconds` | `[RO] date "+%Y-%m-%dT%H:%M:%S%z"` | | UTC-Zeit | `[RO] (Get-Date).ToUniversalTime().ToString("o")` | `[RO] date -u "+%Y-%m-%dT%H:%M:%SZ"` | `[RO] date -u "+%Y-%m-%dT%H:%M:%SZ"` | | Zeitzone | `[RO] Get-TimeZone` | `[RO] timedatectl status` | `[RO][PRIV] sudo systemsetup -gettimezone` | | Zeitstatus | `[RO] w32tm /query /status` | `[RO] timedatectl status` | `[RO][PRIV] sudo systemsetup -getusingnetworktime` |
---
4. Netzwerkadapter und Schnittstellen | Aufgabe | Windows | Linux | macOS | |---|---|---|---| | Adapterübersicht | `[RO] Get-NetAdapter` | `[RO] ip -br link` | `[RO] ifconfig` | | Versteckte Adapter | `[RO] Get-NetAdapter -IncludeHidden` | Nicht direkt vergleichbar | `[RO] ifconfig -a` | | Aktive Adapter | `[RO] Get-NetAdapter \| Where-Object Status -eq "Up"` | `[RO] ip link show up` | `[RO] ifconfig -u` | | MAC-Adressen | `[RO] Get-NetAdapter \| Format-Table Name,MacAddress` | `[RO] ip link show` | `[RO] ifconfig` | | Linkgeschwindigkeit | `[RO] Get-NetAdapter \| Format-Table Name,Status,LinkSpeed` | `[RO][PRIV] sudo ethtool INTERFACE` | `[RO] ifconfig INTERFACE` | | Adapterstatistik | `[RO] Get-NetAdapterStatistics` | `[RO] ip -s link` | `[RO] netstat -ib` | | Treiberinformationen | `[RO][SENS] Get-CimInstance Win32_PnPSignedDriver \| Where-Object DeviceClass -eq "NET"` | `[RO][SENS] lspci -k` | `[RO][SENS] system_profiler SPNetworkDataType` | | USB-Netzwerkadapter | Geräte-Manager beziehungsweise PnP-Geräte prüfen | `[RO][SENS] lsusb` | `[RO][SENS] system_profiler SPUSBDataType` | | Schnittstellenzuordnung | `[RO] Get-NetIPInterface` | `[RO] ip address show` | `[RO] networksetup -listallhardwareports` | **Windows kompakt:** ```powershell [RO] Get-NetAdapter | Format-Table Name, InterfaceDescription, Status, LinkSpeed, MacAddress ``` **Linux kompakt:** ```bash [RO] ip -br link [RO] ip -br address ``` **macOS – Hardwareport und Gerätename zuordnen:** ```bash [RO] networksetup -listallhardwareports ```
---
5. IPv4- und IPv6-Konfiguration | Aufgabe | Windows | Linux | macOS | |---|---|---|---| | Gesamte IP-Konfiguration | `[RO][SENS] Get-NetIPConfiguration -All` | `[RO][SENS] ip address show` | `[RO][SENS] ifconfig` | | Klassische Ausgabe | `[RO][SENS] ipconfig /all` | Nicht zutreffend | Nicht zutreffend | | Kompakte Adressen | `[RO][SENS] Get-NetIPAddress` | `[RO][SENS] ip -br address` | `[RO][SENS] ifconfig` | | Nur IPv4 | `[RO] Get-NetIPAddress -AddressFamily IPv4` | `[RO] ip -4 address show` | `[RO] ifconfig` | | Nur IPv6 | `[RO] Get-NetIPAddress -AddressFamily IPv6` | `[RO] ip -6 address show` | `[RO] ifconfig` | | Schnittstellen-MTU | `[RO] Get-NetIPInterface` | `[RO] ip link show` | `[RO] ifconfig` | | Netzwerkdienstinformationen | Nicht direkt vergleichbar | NetworkManager: `[RO] nmcli device show` | `[RO][SENS] networksetup -getinfo "Wi-Fi"` | **Windows nach Schnittstelle sortiert:** ```powershell [RO][SENS] Get-NetIPAddress | Sort-Object InterfaceAlias, AddressFamily | Format-Table InterfaceAlias, AddressFamily, IPAddress, PrefixLength, AddressState ```
---
6. DHCP prüfen | Aufgabe | Windows | Linux | macOS | |---|---|---|---| | DHCP-Konfiguration | `[RO][SENS] ipconfig /all` | `[RO][SENS] nmcli device show` | `[RO][SENS] ipconfig getpacket INTERFACE` | | IPv4-Adresse | `[RO] Get-NetIPAddress -AddressFamily IPv4` | `[RO] ip -4 address show` | `[RO] ipconfig getifaddr INTERFACE` | | DHCP-Paketmitschnitt | Dumpcap: `udp port 67 or udp port 68` | tcpdump: `udp port 67 or udp port 68` | tcpdump: `udp port 67 or udp port 68` | | DHCPv6-Mitschnitt | Dumpcap: `udp port 546 or udp port 547` | tcpdump: `udp port 546 or udp port 547` | tcpdump: `udp port 546 or udp port 547` | **Windows – Lease erneuern:** ```cmd [CHANGE][DISRUPT] ipconfig /renew ``` **Windows – Lease freigeben und neu beziehen:** ```cmd [CHANGE][DISRUPT] ipconfig /release [CHANGE][DISRUPT] ipconfig /renew ``` **macOS – DHCP für einen Netzwerkdienst erneuern:** ```bash [CHANGE][DISRUPT][PRIV] sudo ipconfig set INTERFACE DHCP ``` Unter Linux hängt das sichere Erneuern vom verwendeten Netzwerkmanager ab. Zuerst prüfen: ```bash [RO] nmcli device status [RO] systemctl is-active NetworkManager [RO] systemctl is-active systemd-networkd ``` DHCP-Erneuerungen können bestehende Verbindungen unterbrechen und dürfen nicht unkontrolliert auf Remote-Systemen ausgeführt werden.
---
7. ARP und IPv6 Neighbor Discovery | Aufgabe | Windows | Linux | macOS | |---|---|---|---| | IPv4-Nachbarn | `[RO][SENS] Get-NetNeighbor -AddressFamily IPv4` | `[RO][SENS] ip -4 neigh show` | `[RO][SENS] arp -an` | | IPv6-Nachbarn | `[RO][SENS] Get-NetNeighbor -AddressFamily IPv6` | `[RO][SENS] ip -6 neigh show` | `[RO][SENS] ndp -an` | | Klassische ARP-Tabelle | `[RO][SENS] arp -a` | `[RO][SENS] ip neigh show` | `[RO][SENS] arp -a` | | Bestimmte Adresse | `[RO] Get-NetNeighbor -IPAddress IP` | `[RO] ip neigh show IP` | `[RO] arp -n IP` | | ARP-Mitschnitt | Capture Filter `arp` | `[TEST][PRIV][SENS] sudo tcpdump -i INTERFACE -nn arp` | `[TEST][PRIV][SENS] sudo tcpdump -i INTERFACE -nn arp` | | NDP-Mitschnitt | Capture Filter `icmp6` | `[TEST][PRIV][SENS] sudo tcpdump -i INTERFACE -nn icmp6` | `[TEST][PRIV][SENS] sudo tcpdump -i INTERFACE -nn icmp6` | Nachbartabellen dürfen nicht unkontrolliert geleert werden. Dadurch können bestehende Verbindungen kurzfristig beeinflusst werden.
---
8. VLAN und Layer 2 | Aufgabe | Windows | Linux | macOS | |---|---|---|---| | Adapter und MAC | `[RO] Get-NetAdapter` | `[RO] ip link show` | `[RO] ifconfig` | | VLAN-Schnittstellen | Abhängig vom Adaptertreiber und Hyper-V | `[RO] ip -d link show type vlan` | `[RO] networksetup -listVLANs` | | Bridge | `[RO] Get-NetAdapterBinding` beziehungsweise Hyper-V prüfen | `[RO] bridge link show` | `[RO] ifconfig bridge0` | | Linkstatistik | `[RO] Get-NetAdapterStatistics` | `[RO] ip -s link` | `[RO] netstat -ib` | | Ethernetdetails | Adaptereigenschaften und Switch prüfen | `[RO][PRIV] sudo ethtool INTERFACE` | `[RO] ifconfig INTERFACE` | | LLDP-Nachbarn | Abhängig von installiertem Werkzeug | Falls installiert: `[RO] lldpcli show neighbors` | Abhängig von installiertem Werkzeug | VLAN-Zuordnung wird häufig auf Switch, Access Point, Hypervisor oder Controller festgelegt und ist am Client nicht vollständig sichtbar.
---
9. Routing und Standardgateway | Aufgabe | Windows | Linux | macOS | |---|---|---|---| | Routingtabelle | `[RO] Get-NetRoute` | `[RO] ip route show` | `[RO] netstat -rn` | | IPv4-Routen | `[RO] route print -4` | `[RO] ip -4 route show` | `[RO] netstat -rn -f inet` | | IPv6-Routen | `[RO] route print -6` | `[RO] ip -6 route show` | `[RO] netstat -rn -f inet6` | | IPv4-Standardroute | `[RO] Get-NetRoute -DestinationPrefix "0.0.0.0/0"` | `[RO] ip route show default` | `[RO] route -n get default` | | IPv6-Standardroute | `[RO] Get-NetRoute -DestinationPrefix "::/0"` | `[RO] ip -6 route show default` | `[RO] route -n get -inet6 default` | | Route zu einem Ziel | `[RO] Find-NetRoute -RemoteIPAddress IP` | `[RO] ip route get IP` | `[RO] route -n get IP` | | Policy Routing | Abhängig von Windows-Richtlinien | `[RO] ip rule show` | `[RO] netstat -rn` | | Alle Linux-Tabellen | Nicht zutreffend | `[RO][SENS] ip route show table all` | Nicht zutreffend | **Windows übersichtlich:** ```powershell [RO] Get-NetRoute | Sort-Object AddressFamily, DestinationPrefix, RouteMetric | Format-Table AddressFamily, DestinationPrefix, NextHop, InterfaceAlias, RouteMetric ```
---
10. Ping und grundlegende Erreichbarkeit | Aufgabe | Windows | Linux | macOS | |---|---|---|---| | IPv4-Ping | `[TEST] ping -4 -n 4 IP` | `[TEST] ping -4 -c 4 IP` | `[TEST] ping -c 4 IPV4` | | IPv6-Ping | `[TEST] ping -6 -n 4 IP` | `[TEST] ping -6 -c 4 IP` | `[TEST] ping6 -c 4 IPV6` | | 20 Messungen | `[TEST] ping -n 20 IP` | `[TEST] ping -c 20 IP` | `[TEST] ping -c 20 IP` | | Fortlaufender Ping | `[TEST] ping -t IP` | `[TEST] ping IP` | `[TEST] ping IP` | | PowerShell-Test | `[TEST] Test-Connection IP -Count 4` | Nicht zutreffend | Nicht zutreffend | | Größere Nutzlast | `[TEST] ping -n 4 -l 1400 IP` | `[TEST] ping -c 4 -s 1400 IP` | `[TEST] ping -c 4 -s 1400 IP` | | Don't Fragment | `[TEST] ping -4 -f -l 1400 IP` | `[TEST] ping -4 -M do -s 1400 IP` | `[TEST] ping -D -s 1400 IP` | **Empfohlene Reihenfolge:** ```text Loopback → eigene Adresse → Standardgateway → internes Ziel → externes Ziel → Hostname ```
---
11. Netzwerkpfad untersuchen | Aufgabe | Windows | Linux | macOS | |---|---|---|---| | Pfad mit DNS | `[TEST] tracert HOST` | `[TEST] traceroute HOST` | `[TEST] traceroute HOST` | | Pfad ohne DNS | `[TEST] tracert -d IP` | `[TEST] traceroute -n IP` | `[TEST] traceroute -n IP` | | IPv4-Pfad | `[TEST] tracert -4 -d HOST` | `[TEST] traceroute -4 -n HOST` | `[TEST] traceroute -4 -n HOST` | | IPv6-Pfad | `[TEST] tracert -6 -d HOST` | `[TEST] traceroute -6 -n HOST` | `[TEST] traceroute -6 -n HOST` | | Pfad und Verlust | `[TEST] pathping /n IP` | Falls installiert: `[TEST] mtr -n -r -c 100 IP` | Falls installiert: `[TEST] mtr -n -r -c 100 IP` | | Path-MTU-Hinweis | Nicht direkt vergleichbar | `[TEST] tracepath -n IP` | MTU mit Ping und Route prüfen | Zwischenhops können ICMP-Antworten begrenzen. Verlust an einem einzelnen Zwischenhop ist kein Beweis für weitergeleiteten Paketverlust, wenn nachfolgende Hops und das Ziel keinen entsprechenden Verlust zeigen.
---
12. DNS-Konfiguration prüfen | Aufgabe | Windows | Linux | macOS | |---|---|---|---| | DNS-Server | `[RO][SENS] Get-DnsClientServerAddress` | `[RO][SENS] resolvectl status` | `[RO][SENS] scutil --dns` | | DNS-Suffixe | `[RO] Get-DnsClient` | `[RO] resolvectl status` | `[RO][SENS] scutil --dns` | | Klassische Konfiguration | `[RO][SENS] ipconfig /all` | `[RO][SENS] cat /etc/resolv.conf` | `[RO][SENS] scutil --dns` | | Hosts-Datei | `[RO][SENS] Get-Content "$env:SystemRoot\System32\drivers\etc\hosts"` | `[RO][SENS] cat /etc/hosts` | `[RO][SENS] cat /etc/hosts` | | DNS-Cache | `[RO][SENS] Get-DnsClientCache` | Resolverabhängig | `[RO][SENS] dscacheutil -cachedump -entries Host` – Ausgabe abhängig von macOS-Version | `/etc/resolv.conf` kann unter Linux automatisch erzeugt sein und bildet bei lokalen Stub-Resolvern nicht zwingend die vollständige Resolverlogik ab.
---
13. DNS-Abfragen durchführen | Aufgabe | Windows | Linux | macOS | |---|---|---|---| | Standardabfrage | `[TEST] Resolve-DnsName HOST` | `[TEST] dig HOST` | `[TEST] dig HOST` | | A-Record | `[TEST] Resolve-DnsName HOST -Type A` | `[TEST] dig HOST A` | `[TEST] dig HOST A` | | AAAA-Record | `[TEST] Resolve-DnsName HOST -Type AAAA` | `[TEST] dig HOST AAAA` | `[TEST] dig HOST AAAA` | | PTR-Record | `[TEST] Resolve-DnsName IP -Type PTR` | `[TEST] dig -x IP` | `[TEST] dig -x IP` | | Bestimmter DNS-Server | `[TEST] Resolve-DnsName HOST -Server DNS_SERVER` | `[TEST] dig @DNS_SERVER HOST` | `[TEST] dig @DNS_SERVER HOST` | | DNS über TCP | `[TEST] Resolve-DnsName HOST -Server DNS_SERVER -TcpOnly` | `[TEST] dig +tcp @DNS_SERVER HOST` | `[TEST] dig +tcp @DNS_SERVER HOST` | | Kurze Ausgabe | `[TEST] (Resolve-DnsName HOST -Type A).IPAddress` | `[TEST] dig +short HOST` | `[TEST] dig +short HOST` | | Vollständige Ablaufverfolgung | Nicht direkt vergleichbar | `[TEST] dig +trace HOST` | `[TEST] dig +trace HOST` | | Klassischer Test | `[TEST] nslookup HOST DNS_SERVER` | `[TEST] nslookup HOST DNS_SERVER` | `[TEST] nslookup HOST DNS_SERVER` | `dig +trace` fragt mehrere DNS-Server ab und darf nur verwendet werden, wenn direkte externe DNS-Abfragen erlaubt sind.
---
14. DNS-Cache kontrolliert leeren Diese Befehle verändern den lokalen Cache und können die Reproduzierbarkeit beeinflussen. | Betriebssystem | Befehl | |---|---| | Windows | `[CHANGE] ipconfig /flushdns` | | Linux mit systemd-resolved | `[CHANGE][PRIV] sudo resolvectl flush-caches` | | macOS | `[CHANGE][PRIV] sudo dscacheutil -flushcache` | Unter Linux hängt der Befehl vom tatsächlich verwendeten Resolver ab. Vorher prüfen: ```bash [RO] systemctl is-active systemd-resolved ``` Das Leeren eines DNS-Caches behebt keine fehlerhafte DNS-Zone, falsche Delegierung oder falsche Serverkonfiguration.
---
15. TCP-Listener, UDP-Endpunkte und Verbindungen | Aufgabe | Windows | Linux | macOS | |---|---|---|---| | TCP-Verbindungen | `[RO] Get-NetTCPConnection` | `[RO] ss -tan` | `[RO] netstat -anv -p tcp` | | TCP-Listener | `[RO] Get-NetTCPConnection -State Listen` | `[RO] ss -ltn` | `[RO] lsof -nP -iTCP -sTCP:LISTEN` | | UDP-Endpunkte | `[RO] Get-NetUDPEndpoint` | `[RO] ss -lun` | `[RO] lsof -nP -iUDP` | | Listener mit Prozess | Prozess-ID über `OwningProcess` | `[RO][PRIV] sudo ss -ltnp` | `[RO][PRIV] sudo lsof -nP -iTCP -sTCP:LISTEN` | | Bestehende TCP-Verbindungen | `[RO] Get-NetTCPConnection -State Established` | `[RO] ss -tn state established` | `[RO] netstat -anv -p tcp` | | Klassische Übersicht | `[RO] netstat -ano` | `[RO] ss -tuln` | `[RO] netstat -anv` | | TCP-Statistik | `[RO] netstat -s -p tcp` | `[RO] nstat` beziehungsweise `[RO] netstat -s` | `[RO] netstat -s -p tcp` | **Bestimmten TCP-Port prüfen:** Windows: ```powershell [RO] Get-NetTCPConnection -State Listen -LocalPort PORT ` -ErrorAction SilentlyContinue ``` Linux: ```bash [RO] ss -ltn 'sport = :PORT' ``` macOS: ```bash [RO] lsof -nP -iTCP:PORT -sTCP:LISTEN ```
---
16. Prozess zu einem Port ermitteln **Windows:** ```powershell [RO] Get-NetTCPConnection -State Listen -LocalPort PORT | Select-Object LocalAddress, LocalPort, State, OwningProcess ``` Anschließend: ```powershell [RO] Get-Process -Id PID ``` Alternativ: ```cmd [RO] netstat -ano [RO] tasklist /FI "PID eq PID" ``` **Linux:** ```bash [RO][PRIV] sudo ss -ltnp 'sport = :PORT' ``` ```bash [RO][PRIV] sudo lsof -nP -iTCP:PORT -sTCP:LISTEN ``` **macOS:** ```bash [RO][PRIV] sudo lsof -nP -iTCP:PORT -sTCP:LISTEN ``` ```bash [RO] ps -p PID -o pid,ppid,user,command ```
---
17. TCP- und UDP-Porttests | Aufgabe | Windows | Linux | macOS | |---|---|---|---| | TCP-Port | `[TEST] Test-NetConnection HOST -Port PORT` | `[TEST] nc -vz -w 5 HOST PORT` | `[TEST] nc -vz -w 5 HOST PORT` | | Detaillierter TCP-Test | `[TEST] Test-NetConnection HOST -Port PORT -InformationLevel Detailed` | `[TEST] nc -vz -w 5 HOST PORT` | `[TEST] nc -vz -w 5 HOST PORT` | | Nmap TCP Connect | `[TEST] nmap -sT -p PORT HOST` | `[TEST] nmap -sT -p PORT HOST` | `[TEST] nmap -sT -p PORT HOST` | | Nmap UDP | Administrator-Konsole: `[TEST][PRIV] nmap -sU -p PORT HOST` | `[TEST][PRIV] sudo nmap -sU -p PORT HOST` | `[TEST][PRIV] sudo nmap -sU -p PORT HOST` | | Netcat UDP | Falls Netcat installiert: `[TEST] nc -vzu HOST PORT` | `[TEST] nc -vzu -w 3 HOST PORT` | `[TEST] nc -vzu -w 3 HOST PORT` | UDP-Tests sind ohne gültige Anfrage des Anwendungsprotokolls häufig nicht eindeutig. `Test-NetConnection -Port` ist ein TCP-Test. Nmap und Portscans dürfen nur gegen ausdrücklich freigegebene Systeme verwendet werden.
---
18. HTTP, HTTPS und TLS prüfen | Aufgabe | Windows | Linux | macOS | |---|---|---|---| | HTTP-Header | `[TEST] curl.exe -I http://HOST/` | `[TEST] curl -I http://HOST/` | `[TEST] curl -I http://HOST/` | | HTTPS-Header | `[TEST] curl.exe -I https://HOST/` | `[TEST] curl -I https://HOST/` | `[TEST] curl -I https://HOST/` | | Ausführlicher Test | `[TEST][SENS] curl.exe -v https://HOST/` | `[TEST][SENS] curl -v https://HOST/` | `[TEST][SENS] curl -v https://HOST/` | | Nur IPv4 | `[TEST] curl.exe -4 -I https://HOST/` | `[TEST] curl -4 -I https://HOST/` | `[TEST] curl -4 -I https://HOST/` | | Nur IPv6 | `[TEST] curl.exe -6 -I https://HOST/` | `[TEST] curl -6 -I https://HOST/` | `[TEST] curl -6 -I https://HOST/` | | TLS-Handshake | Falls OpenSSL installiert: `[TEST][SENS] openssl s_client -connect HOST:443 -servername HOST` | `[TEST][SENS] openssl s_client -connect HOST:443 -servername HOST` | `[TEST][SENS] openssl s_client -connect HOST:443 -servername HOST` | **HTTP-Zeitanteile:** ```bash [TEST][SENS] curl -sS -o /dev/null \ -w 'DNS: %{time_namelookup}\nConnect: %{time_connect}\nTLS: %{time_appconnect}\nStartTransfer: %{time_starttransfer}\nTotal: %{time_total}\nHTTP: %{http_code}\n' \ https://HOST/ ``` `curl -k` deaktiviert die Zertifikatsprüfung und darf nicht als dauerhafte Lösung verwendet werden.
---
19. Windows-Firewall prüfen | Aufgabe | Befehl | |---|---| | Aktives Netzwerkprofil | `[RO] Get-NetConnectionProfile` | | Firewallprofile | `[RO] Get-NetFirewallProfile` | | Ausführliche Profile | `[RO] Get-NetFirewallProfile \| Format-List *` | | Aktivierte Regeln | `[RO][SENS] Get-NetFirewallRule -Enabled True` | | Blockierungsregeln | `[RO][SENS] Get-NetFirewallRule -Enabled True -Action Block` | | Eingehende Erlaubnisregeln | `[RO][SENS] Get-NetFirewallRule -Enabled True -Direction Inbound -Action Allow` | | Portfilter | `[RO][SENS] Get-NetFirewallPortFilter` | | Adressfilter einer Regel | `[RO][SENS] Get-NetFirewallRule -DisplayName "REGEL" \| Get-NetFirewallAddressFilter` | | Programmfilter | `[RO][SENS] Get-NetFirewallRule -DisplayName "REGEL" \| Get-NetFirewallApplicationFilter` | | Aktiver Richtlinienspeicher | `[RO][SENS] Get-NetFirewallRule -PolicyStore ActiveStore` | | Klassische Übersicht | `[RO] netsh advfirewall show allprofiles` | **Regeln für TCP-Port 443 suchen:** ```powershell [RO][SENS] Get-NetFirewallPortFilter -Protocol TCP | Where-Object LocalPort -eq "443" | Get-NetFirewallRule | Format-Table DisplayName, Enabled, Direction, Action, Profile ```
---
20. Linux-Firewall prüfen | System | Aufgabe | Befehl | |---|---|---| | firewalld | Status | `[RO] firewall-cmd --state` | | firewalld | Aktive Zonen | `[RO] firewall-cmd --get-active-zones` | | firewalld | Zone einer Schnittstelle | `[RO] firewall-cmd --get-zone-of-interface=INTERFACE` | | firewalld | Zonenkonfiguration | `[RO][SENS] firewall-cmd --zone=ZONE --list-all` | | firewalld | TCP-Port prüfen | `[RO] firewall-cmd --zone=ZONE --query-port=443/tcp` | | firewalld | Dienste | `[RO] firewall-cmd --zone=ZONE --list-services` | | firewalld | Permanente Konfiguration | `[RO][SENS] firewall-cmd --permanent --zone=ZONE --list-all` | | nftables | Regelwerk | `[RO][PRIV][SENS] sudo nft list ruleset` | | nftables | Regeln mit Handles | `[RO][PRIV][SENS] sudo nft -a list ruleset` | | iptables | IPv4-Regeln | `[RO][PRIV][SENS] sudo iptables -L -n -v --line-numbers` | | iptables | IPv6-Regeln | `[RO][PRIV][SENS] sudo ip6tables -L -n -v --line-numbers` | | ufw | Status | `[RO][PRIV][SENS] sudo ufw status verbose` | | ufw | Nummerierte Regeln | `[RO][PRIV][SENS] sudo ufw status numbered` | Runtime- und permanente firewalld-Konfiguration müssen getrennt verglichen werden.
---
21. macOS-Firewall und pf prüfen | Aufgabe | Befehl | |---|---| | Anwendungsfirewallstatus | `[RO] /usr/libexec/ApplicationFirewall/socketfilterfw --getglobalstate` | | Alle eingehenden Verbindungen blockieren | `[RO] /usr/libexec/ApplicationFirewall/socketfilterfw --getblockall` | | Stealth-Modus | `[RO] /usr/libexec/ApplicationFirewall/socketfilterfw --getstealthmode` | | Konfigurierte Anwendungen | `[RO][PRIV][SENS] sudo /usr/libexec/ApplicationFirewall/socketfilterfw --listapps` | | pf-Status | `[RO][PRIV] sudo pfctl -s info` | | pf-Regeln | `[RO][PRIV][SENS] sudo pfctl -s rules` | | pf-NAT | `[RO][PRIV][SENS] sudo pfctl -s nat` | | pf-Zustände | `[RO][PRIV][SENS] sudo pfctl -s states` | | Regeln mit Zählern | `[RO][PRIV][SENS] sudo pfctl -vvs rules` | Die macOS-Anwendungsfirewall und `pf` sind getrennte Filterebenen.
---
22. NAT und Portweiterleitung | Aufgabe | Windows | Linux | macOS | |---|---|---|---| | Windows-NAT | `[RO][PRIV][SENS] Get-NetNat` | Nicht zutreffend | Nicht zutreffend | | Statische Zuordnungen | `[RO][PRIV][SENS] Get-NetNatStaticMapping` | Nicht zutreffend | Nicht zutreffend | | NAT-Sitzungen | `[RO][PRIV][SENS] Get-NetNatSession` | Conntrack verwenden | pf-Zustände verwenden | | nftables-NAT | Nicht zutreffend | `[RO][PRIV][SENS] sudo nft -a list ruleset` | Nicht zutreffend | | iptables-NAT | Nicht zutreffend | `[RO][PRIV][SENS] sudo iptables -t nat -L -n -v --line-numbers` | Nicht zutreffend | | pf-NAT | Nicht zutreffend | Nicht standardmäßig allgemein vorhanden | `[RO][PRIV][SENS] sudo pfctl -vvs nat` | | IPv4-Forwarding | Rollenabhängig | `[RO] sysctl net.ipv4.ip_forward` | `[RO] sysctl net.inet.ip.forwarding` | | Conntrack | Windows-NAT-Sitzungen | `[RO][PRIV][SENS] sudo conntrack -L` | `[RO][PRIV][SENS] sudo pfctl -s states` | **Öffentlich sichtbare IPv4-Adresse:** Windows: ```powershell [TEST][SENS] Invoke-RestMethod -Uri "https://api.ipify.org" ``` Linux und macOS: ```bash [TEST][SENS] curl -4 https://api.ipify.org ``` Dabei wird die öffentliche Quelladresse an einen externen Dienst übermittelt.
---
23. Proxy prüfen | Aufgabe | Windows | Linux | macOS | |---|---|---|---| | Proxyvariablen | `[RO][SENS] Get-ChildItem Env: \| Where-Object Name -Match 'proxy'` | `[RO][SENS] env \| grep -i proxy` | `[RO][SENS] env \| grep -i proxy` | | WinHTTP-Proxy | `[RO][SENS] netsh winhttp show proxy` | Nicht zutreffend | Nicht zutreffend | | Erweiterter WinHTTP-Proxy | `[RO][SENS] netsh winhttp show advproxy` | Nicht zutreffend | Nicht zutreffend | | Benutzerproxy | Registry `Internet Settings` prüfen | Desktop- und anwendungsabhängig | `[RO][SENS] scutil --proxy` | | HTTP-Proxy | Anwendungsspezifisch | Umgebungs- oder Anwendungskonfiguration | `[RO][SENS] networksetup -getwebproxy "Wi-Fi"` | | HTTPS-Proxy | Anwendungsspezifisch | Umgebungs- oder Anwendungskonfiguration | `[RO][SENS] networksetup -getsecurewebproxy "Wi-Fi"` | | PAC-URL | Registry beziehungsweise WinHTTP | Desktop- und anwendungsabhängig | `[RO][SENS] networksetup -getautoproxyurl "Wi-Fi"` | | Proxy-Ausnahmen | Registry beziehungsweise WinHTTP | `NO_PROXY` prüfen | `[RO][SENS] networksetup -getproxybypassdomains "Wi-Fi"` | **Windows-Benutzereinstellungen:** ```powershell [RO][SENS] Get-ItemProperty ` "HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings" | Select-Object ProxyEnable, ProxyServer, ProxyOverride, AutoConfigURL, AutoDetect ``` **Expliziter Proxytest:** ```bash [TEST][SENS] curl -v \ --proxy http://PROXY:PORT \ https://HOST/ ``` **Proxy ausdrücklich umgehen:** ```bash [TEST][SENS] curl -v --noproxy "*" https://HOST/ ``` Ein Proxy-Bypass darf nur ausgeführt werden, wenn die Sicherheitsrichtlinie dies erlaubt.
---
24. VPN prüfen | Aufgabe | Windows | Linux | macOS | |---|---|---|---| | VPN-Profile | `[RO][SENS] Get-VpnConnection` | `[RO][SENS] nmcli connection show` | `[RO][SENS] scutil --nc list` | | Geräteweite Profile | `[RO][PRIV][SENS] Get-VpnConnection -AllUserConnection` | Clientabhängig | MDM- und clientabhängig | | Aktive RAS-Verbindung | `[RO] rasdial` | `[RO][SENS] nmcli connection show --active` | `[RO][SENS] scutil --nc status "VPN-NAME"` | | Virtuelle Schnittstellen | `[RO] Get-NetAdapter -IncludeHidden` | `[RO] ip -br link` | `[RO] ifconfig` | | VPN-Routen | `[RO] Get-NetRoute` | `[RO] ip route show` | `[RO] netstat -rn` | | DNS über VPN | `[RO][SENS] Get-DnsClientServerAddress` | `[RO][SENS] resolvectl status` | `[RO][SENS] scutil --dns` | | WireGuard | Falls installiert: `[RO][PRIV][SENS] wg show` | `[RO][PRIV][SENS] sudo wg show` | Falls installiert: `[RO][PRIV][SENS] sudo wg show` | | RAS-Protokoll | `[RO][PRIV][SENS] Get-WinEvent -LogName "Microsoft-Windows-RasClient/Operational"` | Clientabhängig | Clientabhängig | | NetworkManager-Protokoll | Nicht zutreffend | `[RO][PRIV][SENS] sudo journalctl -u NetworkManager --since "-30 minutes"` | Nicht zutreffend | **Windows – Split Tunneling prüfen:** ```powershell [RO][SENS] Get-VpnConnection | Select-Object Name, ConnectionStatus, SplitTunneling, TunnelType, ServerAddress ```
---
25. WLAN prüfen | Aufgabe | Windows | Linux | macOS | |---|---|---|---| | Aktuelle Verbindung | `[RO][SENS] netsh wlan show interfaces` | `[RO][SENS] iw dev INTERFACE link` | `[RO][SENS] networksetup -getairportnetwork INTERFACE` | | Sichtbare Netze | `[RO][SENS] netsh wlan show networks mode=bssid` | `[TEST][SENS] nmcli device wifi list` | Wireless Diagnostics beziehungsweise `wdutil`, falls unterstützt | | WLAN-Schnittstellen | `[RO] Get-NetAdapter` | `[RO] iw dev` | `[RO] networksetup -listallhardwareports` | | Treiber | `[RO][SENS] netsh wlan show drivers` | `[RO][SENS] lspci -k` beziehungsweise `lsusb` | `[RO][SENS] system_profiler SPAirPortDataType` | | Fähigkeiten | `[RO][SENS] netsh wlan show wirelesscapabilities` | `[RO][SENS] iw list` | `[RO][SENS] system_profiler SPAirPortDataType` | | Gespeicherte Profile | `[RO][SENS] netsh wlan show profiles` | `[RO][SENS] nmcli connection show` | WLAN-Einstellungen beziehungsweise MDM | | Stationsstatistik | Informationen unter `show interfaces` | `[RO][SENS] iw dev INTERFACE station dump` | Falls unterstützt: `[RO][PRIV][SENS] sudo wdutil info` | | Regulierungsdomäne | Treiber- und Regionseinstellungen | `[RO] iw reg get` | Systemverwaltet | | WLAN-Protokoll | WLAN-AutoConfig-Ereignisse | NetworkManager und Kernel | Wireless Diagnostics | | WLAN-Bericht | `[RO][PRIV][FILE][SENS] netsh wlan show wlanreport` | Protokolle getrennt sichern | Wireless Diagnostics erzeugt ein Diagnosearchiv | **Windows-Ereignisse:** ```powershell [RO][PRIV][SENS] Get-WinEvent ` -LogName "Microsoft-Windows-WLAN-AutoConfig/Operational" ` -MaxEvents 100 ```
---
26. Leistung, Paketverlust und Bandbreite | Aufgabe | Windows | Linux | macOS | |---|---|---|---| | 100 Pingtests | `[TEST] ping -n 100 IP` | `[TEST] ping -c 100 IP` | `[TEST] ping -c 100 IP` | | Pfad und Verlust | `[TEST] pathping /n IP` | Falls installiert: `[TEST] mtr -n -r -c 100 IP` | Falls installiert: `[TEST] mtr -n -r -c 100 IP` | | TCP-Durchsatz | `[TEST] iperf3 -c SERVER_IP` | `[TEST] iperf3 -c SERVER_IP` | `[TEST] iperf3 -c SERVER_IP` | | Gegenrichtung | `[TEST] iperf3 -c SERVER_IP -R` | `[TEST] iperf3 -c SERVER_IP -R` | `[TEST] iperf3 -c SERVER_IP -R` | | 30 Sekunden | `[TEST] iperf3 -c SERVER_IP -t 30` | `[TEST] iperf3 -c SERVER_IP -t 30` | `[TEST] iperf3 -c SERVER_IP -t 30` | | Parallele Streams | `[TEST] iperf3 -c SERVER_IP -P 4` | `[TEST] iperf3 -c SERVER_IP -P 4` | `[TEST] iperf3 -c SERVER_IP -P 4` | | UDP 10 Mbit/s | `[TEST] iperf3 -c SERVER_IP -u -b 10M -t 30` | `[TEST] iperf3 -c SERVER_IP -u -b 10M -t 30` | `[TEST] iperf3 -c SERVER_IP -u -b 10M -t 30` | | JSON-Ausgabe | `[TEST][FILE][SENS] iperf3 -c SERVER_IP -J > test.json` | `[TEST][FILE][SENS] iperf3 -c SERVER_IP -J > test.json` | `[TEST][FILE][SENS] iperf3 -c SERVER_IP -J > test.json` | | Schnittstellenfehler | `[RO] Get-NetAdapterStatistics` | `[RO] ip -s link` | `[RO] netstat -ib` | Lasttests dürfen nur auf freigegebenen Systemen und mit kontrollierter Datenrate durchgeführt werden.
---
27. Docker- und Containernetzwerke | Aufgabe | Befehl | |---|---| | Laufende Container und Ports | `[RO] docker ps --format 'table {{.Names}}\t{{.Ports}}'` | | Portzuordnung | `[RO] docker port CONTAINER` | | Netzwerke | `[RO] docker network ls` | | Netzwerkdetails | `[RO][SENS] docker network inspect NETZWERK` | | Containerdetails | `[RO][SENS] docker inspect CONTAINER` | | Containerprotokoll | `[RO][SENS] docker logs --tail 100 CONTAINER` | | Containerprozesse | `[RO] docker top CONTAINER` | | Container-IP-Konfiguration | Über `docker inspect` und Netzwerkdefinition prüfen | | Veröffentlichte Hostports | `[RO] docker ps --format 'table {{.Names}}\t{{.Ports}}'` | **Typische Portzuordnung:** ```text 0.0.0.0:8080->80/tcp ``` **Nur Loopback:** ```text 127.0.0.1:8080->80/tcp ``` `EXPOSE` im Dockerfile veröffentlicht einen Port nicht automatisch auf dem Host.
---
28. Prozesse und Dienste prüfen | Aufgabe | Windows | Linux | macOS | |---|---|---|---| | Prozesse | `[RO] Get-Process` | `[RO] ps aux` | `[RO] ps aux` | | Prozess per PID | `[RO] Get-Process -Id PID` | `[RO] ps -fp PID` | `[RO] ps -p PID -o pid,ppid,user,command` | | Dienste | `[RO] Get-Service` | `[RO] systemctl --type=service` | `[RO] launchctl list` | | Bestimmter Dienst | `[RO] Get-Service -Name DIENST` | `[RO] systemctl status DIENST` | Dienstabhängig | | Aktuelle Logs | Ereignisprotokoll beziehungsweise Anwendung | `[RO][PRIV][SENS] sudo journalctl -u DIENST --since "-30 minutes"` | Unified Logging beziehungsweise Anwendung | | CPU-Prozesse | `[RO] Get-Process \| Sort-Object CPU -Descending` | `[RO] top` | `[RO] top -l 1` | **Linux-Dienstkonfiguration:** ```bash [RO][PRIV][SENS] sudo systemctl cat DIENST ``` **Linux-Dienstumgebung:** ```bash [RO][PRIV][SENS] sudo systemctl show DIENST \ --property=Environment \ --property=EnvironmentFiles ```
---
29. Paketmitschnitt – Schnittstellen und Basisbefehle | Aufgabe | Windows | Linux | macOS | |---|---|---|---| | Capture-Schnittstellen | `[RO] dumpcap -D` | `[RO] tcpdump -D` | `[RO] tcpdump -D` | | Vollständige Aufzeichnung | `[TEST][PRIV][FILE][SENS] dumpcap -i NUMMER -w capture.pcapng` | `[TEST][PRIV][FILE][SENS] sudo tcpdump -i INTERFACE -nn -w capture.pcap` | `[TEST][PRIV][FILE][SENS] sudo tcpdump -i INTERFACE -nn -w capture.pcap` | | Bestimmter Host | Dumpcap mit `-f "host IP"` | tcpdump mit `'host IP'` | tcpdump mit `'host IP'` | | TCP-Port 443 | Dumpcap mit `-f "tcp port 443"` | tcpdump mit `'tcp port 443'` | tcpdump mit `'tcp port 443'` | | DNS | Dumpcap mit `-f "port 53"` | tcpdump mit `'port 53'` | tcpdump mit `'port 53'` | | DHCPv4 | Dumpcap mit `-f "udp port 67 or udp port 68"` | tcpdump mit entsprechendem Filter | tcpdump mit entsprechendem Filter | | PCAP lesen | `[RO][SENS] tshark -r capture.pcapng` | `[RO][SENS] tcpdump -nn -r capture.pcap` | `[RO][SENS] tcpdump -nn -r capture.pcap` | | Dateiinformationen | `[RO][SENS] capinfos capture.pcapng` | `[RO][SENS] capinfos capture.pcap` | `[RO][SENS] capinfos capture.pcap` | **Windows – 60 Sekunden:** ```powershell [TEST][PRIV][FILE][SENS] dumpcap -i NUMMER ` -a duration:60 ` -w capture.pcapng ``` **Linux oder macOS – bestimmter Datenfluss:** ```bash [TEST][PRIV][FILE][SENS] sudo tcpdump -i INTERFACE -nn \ 'host CLIENT_IP and host SERVER_IP and tcp port PORT' \ -w capture.pcap ```
---
30. Paketmitschnitt – Ringspeicher **Dumpcap – alle fünf Minuten wechseln, zwölf Dateien:** ```powershell [TEST][PRIV][FILE][SENS] dumpcap -i NUMMER ` -b duration:300 ` -b files:12 ` -w ringbuffer.pcapng ``` **tcpdump – größenbasiert, maximal zehn Dateien:** ```bash [TEST][PRIV][FILE][SENS] sudo tcpdump -i INTERFACE -nn \ -C 100 \ -W 10 \ -w ringbuffer.pcap ``` Vor einer Langzeitaufzeichnung prüfen: - verfügbaren Speicherplatz, - Datenschutz, - Dateiberechtigungen, - Rotationsverhalten der installierten Version, - erwartete Datenrate, - Aufbewahrungsdauer.
---
31. Windows Pktmon | Aufgabe | Befehl | |---|---| | Hilfe | `[RO] pktmon help` | | Status | `[RO][PRIV] pktmon status` | | Komponenten | `[RO][PRIV][SENS] pktmon list` | | Aufzeichnung starten | `[TEST][PRIV][FILE][SENS] pktmon start --capture --pkt-size 0 --file-name pktmon.etl` | | Aufzeichnung beenden | `[TEST][PRIV][FILE][SENS] pktmon stop` | | Zähler | `[RO][PRIV][SENS] pktmon counters` | | Nach PCAPNG konvertieren | `[RO][FILE][SENS] pktmon etl2pcap pktmon.etl --out pktmon.pcapng` | | Nur Drops konvertieren | `[RO][FILE][SENS] pktmon etl2pcap pktmon.etl --drop-only --out pktmon-drops.pcapng` | Pktmon kann Pakete an mehreren Stellen des Windows-Netzwerkstacks erfassen. Die ursprüngliche ETL-Datei enthält Informationen, die bei der PCAPNG-Konvertierung teilweise verloren gehen können.
---
32. Wichtige Wireshark Display Filter | Aufgabe | Display Filter | |---|---| | IPv4-Adresse | `ip.addr == 192.0.2.20` | | IPv6-Adresse | `ipv6.addr == 2001:db8::20` | | Zwei Systeme | `ip.addr == 192.0.2.20 && ip.addr == 192.0.2.53` | | TCP-Port | `tcp.port == 443` | | UDP-Port | `udp.port == 53` | | ARP | `arp` | | IPv6 Neighbor Discovery | `icmpv6` | | DHCPv4 | `dhcp` | | DHCPv6 | `dhcpv6` | | DNS | `dns` | | DNS-Anfrage | `dns.flags.response == 0` | | DNS-Antwort | `dns.flags.response == 1` | | HTTP-Anfrage | `http.request` | | HTTP-Antwort | `http.response` | | TLS-Handshake | `tls.handshake` | | TCP-SYN | `tcp.flags.syn == 1` | | Erstes SYN | `tcp.flags.syn == 1 && tcp.flags.ack == 0` | | TCP-Reset | `tcp.flags.reset == 1` | | TCP-FIN | `tcp.flags.fin == 1` | | Wiederholung | `tcp.analysis.retransmission` | | Doppelte ACKs | `tcp.analysis.duplicate_ack` | | Out-of-Order | `tcp.analysis.out_of_order` | | Zero Window | `tcp.analysis.zero_window` | | ICMP | `icmp` | | ICMPv6 | `icmpv6` | | IKE | `isakmp` | | IPsec NAT-T | `udp.port == 4500` | | ESP | `esp` |
---
33. TShark-Auswertung **Datei mit Display Filter lesen:** ```bash [RO][SENS] tshark -r capture.pcapng \ -Y 'tcp.port == 443' ``` **DNS-Anfragen:** ```bash [RO][SENS] tshark -r capture.pcapng \ -Y 'dns.flags.response == 0' \ -T fields \ -e frame.time \ -e ip.src \ -e dns.qry.name ``` **HTTP-Statuscodes:** ```bash [RO][SENS] tshark -r capture.pcapng \ -Y 'http.response' \ -T fields \ -e frame.time \ -e ip.src \ -e ip.dst \ -e http.response.code ``` **TCP-Wiederholungen:** ```bash [RO][SENS] tshark -r capture.pcapng \ -Y 'tcp.analysis.retransmission' ``` **Mitschnitte zusammenführen:** ```bash [RO][FILE][SENS] mergecap \ -w combined.pcapng \ client.pcapng \ server.pcapng ```
---
34. Typische Symptom-zu-Befehl-Zuordnung | Symptom | Erste sinnvolle Prüfungen | |---|---| | Kein Netzwerk | Adapterstatus, IP-Konfiguration, Gateway | | Adresse `169.254.x.x` | DHCP, VLAN, DHCP-Paketmitschnitt | | Gateway nicht erreichbar | ARP/NDP, Subnetz, WLAN, Kabel, Switchport | | IP funktioniert, Hostname nicht | DNS-Server, `Resolve-DnsName`, `dig` | | Host antwortet, Dienst nicht | Listener, Porttest, Firewall | | `Connection refused` | Listener und Prozess prüfen | | Timeout | Route, Firewall, Rückweg und Paketmitschnitt | | Nur ein Client betroffen | Clientkonfiguration mit Vergleichssystem vergleichen | | Nur ein VLAN betroffen | VLAN, Gateway, DHCP-Relay und ACL | | Nur extern nicht erreichbar | NAT, Firewall, öffentliche Adresse und CGNAT | | Nur intern über öffentlichen Namen fehlerhaft | Hairpin NAT oder Split DNS | | Browser funktioniert, Dienst nicht | WinHTTP, Proxyvariablen und Benutzerkontext | | VPN verbunden, internes Ziel nicht erreichbar | Tunneladresse, Route, DNS und Netzüberlappung | | WLAN verbunden, kein Internet | DHCP, Gateway, DNS und Captive Portal | | Verbindung langsam | Gatewayping, Fehlerzähler, iperf3 und Auslastung | | Kleine Pakete funktionieren, große nicht | MTU, ICMP und Path-MTU-Discovery | | Sporadische Abbrüche | Langzeitmessung, Logs, Link-Flaps und Paketmitschnitt | | TCP funktioniert, UDP nicht | UDP-spezifischen Diensttest, Firewall und Mitschnitt | | IPv4 funktioniert, IPv6 nicht | IPv6-Adresse, Route, DNS-AAAA und ICMPv6 | | Container lokal erreichbar, extern nicht | Port Publishing, Bind-Adresse, Host-Firewall und NAT |
---
35. Kompakter Diagnoseblock pro Betriebssystem **Windows – rein lesender Basisblock:** ```powershell [RO] Get-Date -Format o [RO] hostname [RO] Get-NetAdapter [RO][SENS] Get-NetIPConfiguration -All [RO] Get-NetRoute [RO][SENS] Get-DnsClientServerAddress [RO][SENS] Get-NetNeighbor [RO] Get-NetTCPConnection [RO] Get-NetUDPEndpoint [RO] Get-NetAdapterStatistics [RO] Get-NetConnectionProfile [RO] Get-NetFirewallProfile ``` **Linux – rein lesender Basisblock:** ```bash [RO] date --iso-8601=seconds [RO] hostnamectl [RO] ip -br link [RO][SENS] ip -br address [RO] ip route show [RO] ip -6 route show [RO][SENS] ip neigh show [RO][SENS] resolvectl status [RO] ss -tuln [RO] ip -s link ``` Falls `resolvectl` nicht vorhanden ist: ```bash [RO][SENS] cat /etc/resolv.conf ``` **macOS – rein lesender Basisblock:** ```bash [RO] date "+%Y-%m-%dT%H:%M:%S%z" [RO] sw_vers [RO] scutil --get ComputerName [RO] networksetup -listallhardwareports [RO][SENS] ifconfig [RO] netstat -rn [RO][SENS] arp -an [RO][SENS] ndp -an [RO][SENS] scutil --dns [RO] netstat -anv [RO] netstat -ib ``` Die Kennzeichnungen `[RO]` und `[SENS]` sind Dokumentationsmarkierungen und werden beim tatsächlichen Kopieren eines Befehls nicht mit eingegeben.
---
36. Dokumentationsvorlage für eine Netzwerkdiagnose ```text Störung: Zeitpunkt: Zeitzone: Benutzer: Standort: Client: Betriebssystem: Schnittstelle: MAC-Adresse: Linkstatus: Linkgeschwindigkeit: WLAN-SSID: WLAN-BSSID: VLAN: IPv4-Adresse: IPv4-Präfix: IPv4-Gateway: IPv6-Adresse: IPv6-Präfix: IPv6-Gateway: DHCP-Server: DNS-Server: DNS-Suffixe: Zielhostname: Aufgelöste Zieladresse: Transportprotokoll: Zielport: Anwendung: Loopbacktest: Gatewaytest: Interner IP-Test: Externer IP-Test: DNS-Test: Routenergebnis: Porttest: Anwendungstest: Listener vorhanden: Zugehöriger Prozess: Firewallstatus: Passende Firewallregel: NAT beteiligt: Proxy beteiligt: VPN beteiligt: Container beteiligt: Paketverlust: Latenz: Jitter: TCP-Durchsatz: UDP-Verlust: Schnittstellenfehler: Paketmitschnitt: Messpunkt: Capture Filter: Relevante Frames: Systemprotokolle: Festgestellte Ursache: Genehmigte Änderung: Rückfallplan: Ergebnis der Nachprüfung: ```
---
37. Abschließende Kontrollfragen - Wurde die richtige Schnittstelle geprüft? - Sind IPv4 und IPv6 getrennt betrachtet worden? - Stimmen Adresse, Präfix, Gateway und DNS? - Ist das Ziel über IP-Adresse erreichbar? - Wird der Hostname korrekt aufgelöst? - Führt die Route über die erwartete Schnittstelle? - Ist der benötigte Port geöffnet? - Lauscht der richtige Prozess? - Funktioniert das eigentliche Anwendungsprotokoll? - Wurde TCP nicht mit UDP verwechselt? - Wurden Firewall, NAT, Proxy und VPN berücksichtigt? - Wurde bei Containern zwischen Host- und Containerport unterschieden? - Wurde ein Timeout nicht automatisch als Firewallfehler bewertet? - Wurde Paketverlust an Zwischenhops korrekt interpretiert? - Wurden Hin- und Rückrichtung geprüft? - Wurde die Messung mit einem funktionierenden System verglichen? - Wurde vor einer Änderung der Istzustand dokumentiert? - Wurde nach der Änderung mit derselben Methode erneut geprüft? - Enthalten Ausgaben oder Paketmitschnitte sensible Daten? - Ist die festgestellte Ursache durch konkrete Messwerte belegt?
---
38. Quellen und Befehlsreferenzen - Microsoft Learn – Windows-Netzwerk-Cmdlets: https://learn.microsoft.com/powershell/module/nettcpip/ - Microsoft Learn – Windows-Firewall-Cmdlets: https://learn.microsoft.com/powershell/module/netsecurity/ - Microsoft Learn – `netsh wlan`: https://learn.microsoft.com/windows-server/administration/windows-commands/netsh-wlan - Microsoft Learn – `ping`: https://learn.microsoft.com/windows-server/administration/windows-commands/ping - Microsoft Learn – `tracert`: https://learn.microsoft.com/windows-server/administration/windows-commands/tracert - Microsoft Learn – `pathping`: https://learn.microsoft.com/windows-server/administration/windows-commands/pathping - Microsoft Learn – Pktmon: https://learn.microsoft.com/windows-server/administration/windows-commands/pktmon - Linux-Handbuch – iproute2: https://man7.org/linux/man-pages/man8/ip.8.html - Linux-Handbuch – `ss`: https://man7.org/linux/man-pages/man8/ss.8.html - NetworkManager – `nmcli`: https://networkmanager.dev/docs/api/latest/nmcli.html - firewalld – Dokumentation: https://firewalld.org/documentation/ - Netfilter – nftables: https://netfilter.org/projects/nftables/manpage.html - Apple – `networksetup`: Auf dem Mac lokal mit `man networksetup` - Apple – Netzwerk- und WLAN-Diagnose: https://support.apple.com/de-de/guide/mac-help/mchlf4de377f/mac - Wireshark – Benutzerhandbuch: https://www.wireshark.org/docs/wsug_html_chunked/ - Wireshark – Befehlsreferenzen: https://www.wireshark.org/docs/man-pages/ - curl – Handbuch: https://curl.se/docs/manpage.html - ESnet – iperf3: https://software.es.net/iperf/ - WireGuard – Dokumentation: https://www.wireguard.com/quickstart/ - OpenVPN – Referenzhandbuch: https://openvpn.net/community-resources/reference-manual-for-openvpn-2-6/ - Docker – Networking: https://docs.docker.com/engine/network/
# 4. Server- und Dienstfehler systematisch analysieren # 4.0 Server- und Dienstfehler systematisch analysieren Server- und Dienstfehler liegen vor, wenn ein benötigter Dienst nicht startet, unerwartet beendet wird, nicht erreichbar ist oder zwar Verbindungen annimmt, aber fehlerhafte Ergebnisse liefert. Dieses Kapitel behandelt die systematische Analyse von Diensten und Serveranwendungen unter Windows, Linux und macOS. Dazu gehören unter anderem Webserver, Datenbanken, Datei- und Druckdienste, Anwendungsserver sowie Hintergrunddienste. > **Grundsatz:** > Ein erreichbarer Server ist nicht automatisch ein funktionierender Server. Netzwerkverbindung, Port, Dienstprozess und Anwendungsfunktion müssen getrennt geprüft werden. --- **Ziele dieses Kapitels** Nach Abschluss dieses Kapitels sollst du: - den betroffenen Dienst eindeutig identifizieren können, - zwischen Netzwerk-, Port-, Dienst- und Anwendungsfehlern unterscheiden können, - Dienststatus und Startart überprüfen können, - Prozesse, Abhängigkeiten und verwendete Ports ermitteln können, - Protokolle verschiedener Betriebssysteme auswerten können, - Konfigurationsfehler erkennen können, - Berechtigungs-, Ressourcen- und Zertifikatsprobleme untersuchen können, - Dienste kontrolliert testen und neu starten können, - wiederkehrende Dienstabbrüche analysieren können, - Diagnoseergebnisse nachvollziehbar dokumentieren können. --- **Sicherheits- und Risikokennzeichnungen** | Kennzeichnung | Bedeutung | |---|---| | `[RO]` | Rein lesender Befehl; verändert normalerweise nichts | | `[TEST]` | Führt eine aktive Prüfung oder Verbindungsanfrage aus | | `[PRIV]` | Erfordert möglicherweise Administrator- oder Rootrechte | | `[FILE]` | Liest eine Datei oder schreibt eine Ausgabe in eine Datei | | `[SENS]` | Ausgabe kann sensible Informationen enthalten | | `[CHANGE]` | Verändert Einstellungen, Zustände oder Konfigurationen | | `[DISRUPT]` | Kann einen Dienst oder laufenden Betrieb unterbrechen | > Befehle mit `[CHANGE]` oder `[DISRUPT]` dürfen erst nach Prüfung der Auswirkungen und möglichst innerhalb eines abgestimmten Wartungsfensters ausgeführt werden. ---
1. Diagnosemodell für Server- und Dienstfehler Ein Dienst wird schrittweise von außen nach innen geprüft: | Ebene | Leitfrage | Typische Prüfung | |---|---|---| | 1. Benutzer | Was funktioniert aus Sicht des Benutzers nicht? | Fehlermeldung und Zeitpunkt aufnehmen | | 2. Client | Ist nur ein Gerät oder Benutzer betroffen? | Vergleich mit anderem Client | | 3. Namensauflösung | Wird der richtige Servername aufgelöst? | DNS-Abfrage durchführen | | 4. Netzwerk | Ist der Server erreichbar? | Route und Erreichbarkeit prüfen | | 5. Transport | Ist der benötigte TCP- oder UDP-Port erreichbar? | Porttest durchführen | | 6. Betriebssystem | Läuft das Betriebssystem stabil? | Ressourcen und Ereignisse prüfen | | 7. Dienst | Läuft der benötigte Dienst? | Dienststatus und Prozess prüfen | | 8. Abhängigkeiten | Funktionieren abhängige Dienste und Systeme? | Datenbank, DNS, Speicher oder Authentifizierung prüfen | | 9. Konfiguration | Ist der Dienst korrekt konfiguriert? | Konfigurationsdateien und Startparameter prüfen | | 10. Anwendung | Liefert der Dienst fachlich korrekte Ergebnisse? | Anwendungsspezifischen Funktionstest durchführen | **Wichtig:** `ping` prüft nicht, ob ein Anwendungsdienst funktioniert. Ein Server kann ICMP-Anfragen beantworten, obwohl beispielsweise der Web-, Datenbank- oder Dateidienst ausgefallen ist.
---
2. Vier grundlegende Dienstzustände unterscheiden | Zustand | Beschreibung | Typische Ursache | |---|---|---| | Server nicht erreichbar | Bereits die Netzwerkverbindung scheitert | Routing, VLAN, Firewall, Stromversorgung oder Netzwerkkarte | | Port nicht erreichbar | Server ist erreichbar, aber der Dienstport nicht | Dienst gestoppt, falscher Port oder Firewall | | Port erreichbar, Anwendung fehlerhaft | Verbindung wird aufgebaut, die Anfrage schlägt jedoch fehl | Konfiguration, Berechtigung, Datenbank oder Anwendung | | Dienst funktioniert teilweise | Nur bestimmte Benutzer oder Funktionen sind betroffen | Rechte, Mandant, Backend, Datenbestand oder Lastproblem | Diese Zustände dürfen nicht miteinander verwechselt werden. Die Fehlersuche beginnt immer bei der niedrigsten noch nicht nachgewiesenen Funktionsebene.
---
3. Schnellprüfung unter Windows, Linux und macOS Die folgenden Befehle liefern eine erste Übersicht. `` und `` müssen durch die tatsächlichen Werte ersetzt werden. | Aufgabe | Windows | Linux | macOS | |---|---|---|---| | Rechnername | `[RO] hostname` | `[RO] hostnamectl` | `[RO] scutil --get ComputerName` | | Systemlaufzeit | `[RO] (Get-CimInstance Win32_OperatingSystem).LastBootUpTime` | `[RO] uptime` | `[RO] uptime` | | Dienststatus | `[RO] Get-Service -Name ""` | `[RO] systemctl status --no-pager` | `[RO] launchctl print system/` | | Alle laufenden Dienste | `[RO] Get-Service \| Where-Object Status -eq "Running"` | `[RO] systemctl list-units --type=service --state=running` | `[RO] launchctl list` | | Prozess suchen | `[RO] Get-Process -Name "" -ErrorAction SilentlyContinue` | `[RO] pgrep -a ` | `[RO] pgrep -alf ` | | TCP-Listener anzeigen | `[RO] Get-NetTCPConnection -State Listen` | `[RO][PRIV] sudo ss -lntp` | `[RO][PRIV] sudo lsof -nP -iTCP -sTCP:LISTEN` | | Bestimmten Port prüfen | `[RO] Get-NetTCPConnection -LocalPort -ErrorAction SilentlyContinue` | `[RO][PRIV] sudo ss -lntp "sport = :"` | `[RO][PRIV] sudo lsof -nP -iTCP: -sTCP:LISTEN` | | Remote-TCP-Port testen | `[TEST] Test-NetConnection -Port ` | `[TEST] nc -vz ` | `[TEST] nc -vz ` | | CPU und Arbeitsspeicher | `[RO] Get-Process \| Sort-Object CPU -Descending \| Select-Object -First 10` | `[RO] top` | `[RO] top -o cpu` | | Freien Speicherplatz prüfen | `[RO] Get-Volume` | `[RO] df -hT` | `[RO] df -h` | > `launchctl print system/` benötigt das Dienstlabel und nicht zwingend den sichtbaren Namen einer Anwendung. Benutzerbezogene LaunchAgents befinden sich außerdem nicht in der Systemdomäne.
---
4. Reihenfolge der praktischen Fehlersuche 1. Störung und betroffene Funktion genau beschreiben. 2. Zeitpunkt und Dauer der Störung erfassen. 3. Prüfen, welche Benutzer, Clients und Standorte betroffen sind. 4. Letzte Änderungen und bekannte Wartungsarbeiten ermitteln. 5. Servername und Zielsystem eindeutig bestimmen. 6. DNS-Auflösung und Netzwerkpfad überprüfen. 7. Erreichbarkeit des benötigten Ports testen. 8. Dienststatus, Prozess und Startart kontrollieren. 9. Kontrollieren, auf welcher Adresse und welchem Port der Dienst lauscht. 10. Abhängige Dienste und externe Systeme überprüfen. 11. System- und Anwendungsprotokolle für den Störungszeitraum auswerten. 12. CPU, Arbeitsspeicher, Datenträger und offene Dateien prüfen. 13. Konfiguration, Berechtigungen und Zertifikate kontrollieren. 14. Einen gezielten Funktionstest durchführen. 15. Erst danach eine geeignete Maßnahme planen. 16. Nach der Maßnahme Funktion und Nebenwirkungen überprüfen. 17. Ursache, Maßnahme und Ergebnis dokumentieren.
---
5. Kapitelübersicht | Seite | Thema | Inhalt | |---|---|---| | **4.0** | Server- und Dienstfehler systematisch analysieren | Kapitelübersicht und Diagnosemodell | | **4.1** | Störung und betroffenen Dienst eingrenzen | Benutzer, Clients, Standorte und Zeiträume | | **4.2** | Dienststatus und Startart prüfen | Windows-Dienste, systemd und launchd | | **4.3** | Prozesse und Prozesszustände analysieren | PID, Elternprozess, Laufzeit und Ressourcen | | **4.4** | Listener, Ports und Bindungsadressen prüfen | TCP, UDP, IPv4, IPv6 und Loopback | | **4.5** | Dienstabhängigkeiten untersuchen | Abhängige Dienste, Backends und Startreihenfolge | | **4.6** | System- und Dienstprotokolle auswerten | Ereignisanzeige, Journal und Unified Logging | | **4.7** | Dienststartfehler analysieren | Exitcodes, Zeitüberschreitungen und Abstürze | | **4.8** | Konfigurationsfehler untersuchen | Syntax, Pfade, Parameter und Umgebungsvariablen | | **4.9** | Benutzer-, Dienstkonto- und Berechtigungsfehler | Konten, Dateirechte und Zugriffstoken | | **4.10** | Ressourcenengpässe erkennen | CPU, RAM, Datenträger und Dateideskriptoren | | **4.11** | Speicherplatz- und Dateisystemfehler | Volumes, Inodes, Quotas und schreibgeschützte Dateisysteme | | **4.12** | Zertifikats- und TLS-Probleme | Gültigkeit, Vertrauenskette, Name und Protokoll | | **4.13** | Webserver und HTTP-Dienste analysieren | HTTP-Statuscodes, Header, Logs und virtuelle Hosts | | **4.14** | Datenbankverbindungen analysieren | Port, Anmeldung, Berechtigungen und Verbindungspools | | **4.15** | Datei- und Freigabedienste analysieren | SMB, NFS, Berechtigungen und Sperren | | **4.16** | Druckdienste und Warteschlangen analysieren | Spooler, Druckaufträge, Treiber und Erreichbarkeit | | **4.17** | Wiederkehrende Dienstabbrüche untersuchen | Crash-Loops, Neustartregeln und Ursachenanalyse | | **4.18** | Dienste kontrolliert neu starten | Risikoanalyse, Abhängigkeiten und Funktionstest | | **4.19** | Befehlsübersicht – Server- und Dienstdiagnose | Vergleichstabelle für Windows, Linux und macOS |
---
6. Entscheidungsweg bei einem nicht erreichbaren Dienst | Prüfschritt | Ergebnis | Nächste Aktion | |---|---|---| | Wird der richtige Servername verwendet? | Nein | Zielsystem und Dokumentation korrigieren | | Wird der Name korrekt aufgelöst? | Nein | DNS-Konfiguration untersuchen | | Ist der Server über das Netzwerk erreichbar? | Nein | Netzwerkpfad, VLAN, Routing und Firewall prüfen | | Ist der benötigte Port erreichbar? | Nein | Listener, Dienststatus und Paketfilter prüfen | | Läuft der Dienstprozess? | Nein | Startfehler und Protokolle untersuchen | | Lauscht der Prozess auf dem erwarteten Port? | Nein | Bindungsadresse und Konfiguration prüfen | | Antwortet das Anwendungsprotokoll? | Nein | Dienstprotokoll, TLS und Abhängigkeiten prüfen | | Funktioniert die Anmeldung? | Nein | Konto, Kennwort, Berechtigungen und Identitätsdienst prüfen | | Funktioniert die gewünschte Aktion? | Nein | Anwendung, Backend und Datenbestand untersuchen | | Funktioniert alles wieder? | Ja | Ursache und Lösung dokumentieren |
---
7. Wichtige Informationen vor einem Dienstneustart Vor einem Neustart müssen mindestens folgende Fragen beantwortet werden: - Welche Benutzer und Anwendungen verwenden den Dienst? - Gibt es laufende Transaktionen oder Dateioperationen? - Hängen weitere Dienste von diesem Dienst ab? - Wird der Dienst automatisch wieder gestartet? - Existiert ein Cluster, Loadbalancer oder Failover-System? - Gehen durch den Neustart Diagnoseinformationen verloren? - Wurden die relevanten Protokolle bereits gesichert? - Ist der Neustart betrieblich freigegeben? - Wie wird die Funktion anschließend getestet? - Gibt es eine Rückfallmöglichkeit? > Ein Neustart kann die Verfügbarkeit kurzfristig wiederherstellen, beseitigt aber nicht automatisch die eigentliche Fehlerursache. Vorher sollten Zustand, Zeitstempel, Fehlermeldungen und relevante Protokolle erfasst werden.
---
8. Mindestdokumentation eines Dienstfehlers | Information | Beispiel | |---|---| | Betroffener Dienst | Intranet-Webanwendung | | Server | `srv-web01.example.local` | | Betriebssystem | Windows Server beziehungsweise Linux-Distribution und Version | | Beginn der Störung | Datum und genaue Uhrzeit mit Zeitzone | | Betroffene Benutzer | Alle Benutzer am Standort Berlin | | Fehlerbild | HTTP-Verbindung wird aufgebaut, Antwortcode 503 | | Dienststatus | Dienst läuft beziehungsweise ist beendet | | Prozess | Prozessname und PID | | Port und Bindungsadresse | TCP 443 auf einer bestimmten IP-Adresse | | Relevante Protokollmeldung | Ereignis-ID, Exitcode oder Fehlermeldung | | Letzte Änderung | Aktualisierung oder Konfigurationsänderung | | Durchgeführte Prüfungen | DNS-, Port-, Dienst- und Funktionstest | | Maßnahme | Konfiguration korrigiert und Dienst kontrolliert neu gestartet | | Funktionstest | Anmeldung und Beispielabfrage erfolgreich | | Ursache | Technische Grundursache | | Vorbeugung | Monitoring, Dokumentation oder Konfigurationsprüfung |
--- **Merksatz** > **Erreichbarkeit beweist nur den Netzwerkweg. Ein offener Port beweist nur einen Listener. Erst ein erfolgreicher Anwendungstest beweist die Funktion des Dienstes.** --- **Weiterführende Quellen** - [Microsoft Learn – sc.exe query](https://learn.microsoft.com/de-de/windows-server/administration/windows-commands/sc-query) - [Microsoft Learn – Get-Service](https://learn.microsoft.com/powershell/module/microsoft.powershell.management/get-service) - [systemd – systemctl](https://www.freedesktop.org/software/systemd/man/latest/systemctl.html) - [systemd – journalctl](https://www.freedesktop.org/software/systemd/man/latest/journalctl.html) - [Apple – Einführung in die App „Konsole“](https://support.apple.com/de-de/guide/console/welcome/mac) - [Apple – Handbuchseite zu launchctl](https://keith.github.io/xcode-man-pages/launchctl.1.html) # 4.1 Störung und betroffenen Dienst eingrenzen Bevor Prozesse, Ports oder Protokolldateien untersucht werden, muss eindeutig feststehen, **welche Funktion tatsächlich gestört ist**. Eine Meldung wie „Der Server funktioniert nicht“ reicht für eine gezielte Fehleranalyse nicht aus. > **Grundsatz:** > Zuerst das Fehlerbild und den Störungsumfang bestimmen. Erst danach mit technischen Prüfungen beginnen. --- **Ziele dieser Seite** Nach dieser Seite sollst du: - eine ungenaue Störungsmeldung in ein überprüfbares Fehlerbild überführen können, - den betroffenen Server und Dienst identifizieren können, - den Störungsumfang systematisch eingrenzen können, - zwischen Client-, Benutzer-, Netzwerk-, Dienst- und Anwendungsfehlern unterscheiden können, - relevante Zeitangaben und Änderungen erfassen können, - einen geeigneten Vergleichstest auswählen können, - den Ausgangszustand vor Änderungen dokumentieren können. ---
1. Ruhig und hypothesenoffen beginnen Bei einer Störung entsteht schnell der Wunsch, sofort einen Dienst neu zu starten oder eine bekannte Lösung auszuprobieren. Dadurch können jedoch wichtige Diagnoseinformationen verloren gehen. Eine sinnvolle Haltung lautet: 1. Störungsmeldung nicht ungeprüft als Ursache übernehmen. 2. Beobachtungen von Vermutungen trennen. 3. Noch keine technische Ursache festlegen. 4. Zuerst den Umfang der Störung bestimmen. 5. Mit einfachen und möglichst lesenden Prüfungen beginnen. 6. Pro Arbeitsschritt nur eine wesentliche Veränderung durchführen. 7. Vor und nach jeder Maßnahme vergleichen. 8. Ergebnisse und Zeitpunkte dokumentieren. | Aussage | Einordnung | |---|---| | „Das Intranet ist nicht erreichbar.“ | Beobachtung beziehungsweise Fehlerbild | | „Der Webserver ist abgestürzt.“ | Noch unbestätigte Hypothese | | „TCP-Port 443 antwortet nicht.“ | Technisches Prüfergebnis | | „Der Webdienst befindet sich im Zustand `Stopped`.“ | Technisches Prüfergebnis | | „Der Dienst wurde durch fehlenden Speicher beendet.“ | Mögliche Ursache, die durch Protokolle belegt werden muss | > **Wichtig:** Eine Fehlermeldung beschreibt häufig nur die Stelle, an der ein Fehler sichtbar wird – nicht die eigentliche Ursache.
---
2. Aus einer Störungsmeldung ein konkretes Fehlerbild erstellen Eine gute Fehlerbeschreibung beantwortet mindestens folgende Fragen: | Frage | Beispiel | |---|---| | Was funktioniert nicht? | Anmeldung an der internen Webanwendung | | Welche konkrete Aktion schlägt fehl? | Absenden des Anmeldeformulars | | Welche Fehlermeldung erscheint? | HTTP-Statuscode 503 | | Seit wann besteht das Problem? | Seit 31.07.2026 um 09:15 Uhr | | Tritt der Fehler dauerhaft oder zeitweise auf? | Bei jedem Anmeldeversuch | | Wer ist betroffen? | Alle Benutzer am Standort Berlin | | Welche Clients sind betroffen? | Windows-, Linux- und macOS-Clients | | Welche Funktion arbeitet weiterhin? | Startseite der Anwendung ist erreichbar | | Wurde eine alternative Verbindung getestet? | Zugriff über einen zweiten Client ebenfalls fehlerhaft | | Was wurde zuletzt verändert? | Aktualisierung der Anwendung am Vorabend | **Unzureichende Beschreibung:** > „Der Server geht nicht.“ **Verwertbare Beschreibung:** > „Seit 09:15 Uhr erhalten alle geprüften Benutzer beim Anmelden an `https://intranet.example.local` den HTTP-Statuscode 503. Die Namensauflösung funktioniert und die Startseite ist erreichbar. Der Fehler tritt von mehreren Clients und Benutzerkonten aus auf.“
---
3. Störungsumfang mit einer Eingrenzungsmatrix bestimmen | Prüfdimension | Mögliche Eingrenzung | |---|---| | Benutzer | Ein Benutzer, Benutzergruppe oder alle Benutzer | | Endgerät | Ein Client, Gerätetyp oder alle Clients | | Betriebssystem | Nur Windows, Linux, macOS oder alle Systeme | | Standort | Ein Raum, Gebäude, Standort oder alle Standorte | | Netzwerk | LAN, WLAN, VPN, Gastnetz oder alle Zugangswege | | Anwendung | Eine Funktion, ein Modul oder vollständige Anwendung | | Dienst | Ein Dienst, mehrere Dienste oder gesamter Server | | Zeitpunkt | Dauerhaft, sporadisch, zu bestimmten Uhrzeiten | | Daten | Einzelne Datei, Datensatz, Freigabe oder alle Daten | | Berechtigung | Einzelnes Konto, Rolle, Gruppe oder alle Konten | | Protokoll | HTTP, HTTPS, SMB, SSH, RDP oder Datenbankverbindung | | Backend | Datenbank, Verzeichnisdienst, Speicher oder externe API | **Beispiele für Schlussfolgerungen:** | Beobachtung | Wahrscheinlicher Untersuchungsbereich | |---|---| | Nur ein Benutzer ist betroffen | Konto, Profil, Berechtigung oder benutzerspezifische Daten | | Nur ein Client ist betroffen | Clientkonfiguration, Cache, Zertifikat oder lokale Firewall | | Alle Benutzer eines Standortes sind betroffen | Standortnetz, WAN, DNS, Routing oder Firewall | | Alle Benutzer sind betroffen | Zentraler Dienst, Server, Backend oder globale Änderung | | Nur ein Anwendungsmodul ist betroffen | Modulkonfiguration, Backend oder Berechtigung | | Zugriff per IP-Adresse funktioniert, per Name nicht | DNS oder Namenskonfiguration | | TCP-Port ist offen, Anwendung antwortet fehlerhaft | Anwendung, Backend, TLS oder Berechtigung | | Fehler tritt nur unter hoher Last auf | Ressourcen, Grenzwerte, Verbindungspool oder Zeitüberschreitung | Diese Zuordnungen sind **Arbeitshypothesen** und noch kein endgültiger Ursachenbeweis.
---
4. Betroffenen Server und Dienst eindeutig identifizieren Vor der technischen Prüfung müssen folgende Angaben geklärt werden: | Information | Beispiel | |---|---| | Angezeigter Dienstname | Interne Webanwendung | | Technischer Dienstname | `intranet-api` | | Prozessname | `intranet-api.exe` beziehungsweise `intranet-api` | | Servername | `srv-app01.example.local` | | IP-Adresse | `192.0.2.20` | | Protokoll | HTTPS | | Zielport | TCP 443 | | Pfad oder URL | `https://intranet.example.local/login` | | Backend | `srv-db01.example.local` | | Verantwortliches System | Webserver, Anwendungsdienst oder Datenbank | | Produktivstatus | Produktiv-, Test- oder Entwicklungssystem | > Der sichtbare Name einer Anwendung, der Betriebssystem-Dienstname und der Prozessname können unterschiedlich sein. **Beispiel einer Dienstkette:** ```text Client → DNS → Firewall oder Loadbalancer → Webserver → Anwendungsdienst → Datenbank → Verzeichnisdienst oder externe API ``` Die Störung kann an jeder Übergabestelle dieser Kette entstehen.
---
5. Basisinformationen des untersuchten Servers erfassen Die folgenden Befehle verändern den Systemzustand normalerweise nicht. | Aufgabe | Windows PowerShell | Linux | macOS | |---|---|---|---| | Rechnername | `[RO] hostname` | `[RO] hostname` | `[RO] hostname` | | Vollständiger DNS-Name | `[RO] [System.Net.Dns]::GetHostEntry($env:COMPUTERNAME).HostName` | `[RO] hostname --fqdn` | `[RO] hostname -f` | | Betriebssysteminformationen | `[RO] Get-ComputerInfo \| Select-Object WindowsProductName,WindowsVersion,OsBuildNumber` | `[RO][FILE] cat /etc/os-release` | `[RO] sw_vers` | | Systemarchitektur | `[RO] $env:PROCESSOR_ARCHITECTURE` | `[RO] uname -m` | `[RO] uname -m` | | Kernel beziehungsweise Systemversion | `[RO] systeminfo` | `[RO] uname -a` | `[RO] uname -a` | | Letzter Systemstart | `[RO] (Get-CimInstance Win32_OperatingSystem).LastBootUpTime` | `[RO] uptime -s` | `[RO] sysctl -n kern.boottime` | | Aktuelle Laufzeit | `[RO] (Get-Date) - (Get-CimInstance Win32_OperatingSystem).LastBootUpTime` | `[RO] uptime` | `[RO] uptime` | | Aktuelle Uhrzeit | `[RO] Get-Date -Format o` | `[RO] date --iso-8601=seconds` | `[RO] date "+%Y-%m-%dT%H:%M:%S%z"` | | Zeitzone | `[RO] Get-TimeZone` | `[RO] timedatectl status` | `[RO][PRIV] sudo systemsetup -gettimezone` | | Angemeldete Benutzer | `[RO] quser` | `[RO] who` | `[RO] who` | **Hinweise:** - `hostname --fqdn` liefert nur dann ein sinnvolles Ergebnis, wenn Hostname und Namensauflösung korrekt konfiguriert sind. - `hostname -f` kann unter macOS abhängig von der lokalen Namenskonfiguration fehlschlagen oder einen unerwarteten Namen liefern. - `systeminfo` erzeugt eine umfangreiche Ausgabe. Für eine Dokumentation können relevante Zeilen gezielt ausgewählt werden. - Zeitstempel müssen zusammen mit der Zeitzone dokumentiert werden, damit Client-, Server- und Netzwerkprotokolle richtig verglichen werden können.
---
6. Dienstnamen und Prozesse zunächst nur lesend suchen Die Platzhalter ``, `` und `` müssen ersetzt werden. | Aufgabe | Windows PowerShell | Linux | macOS | |---|---|---|---| | Dienst nach Namen suchen | `[RO] Get-Service -Name "**" -ErrorAction SilentlyContinue` | `[RO] systemctl list-unit-files --type=service \| grep -i -- ""` | `[RO] launchctl list \| grep -i -- ""` | | Dienst nach Anzeigenamen suchen | `[RO] Get-Service -DisplayName "**" -ErrorAction SilentlyContinue` | Nicht getrennt vorhanden | Nicht getrennt vorhanden | | Status eines Dienstes | `[RO] Get-Service -Name ""` | `[RO] systemctl status "" --no-pager` | `[RO] launchctl print "system/"` | | Prozess nach Namen suchen | `[RO] Get-Process -Name "" -ErrorAction SilentlyContinue` | `[RO] pgrep -a ""` | `[RO] pgrep -alf ""` | | Prozesse ausführlich anzeigen | `[RO] Get-CimInstance Win32_Process \| Select-Object ProcessId,ParentProcessId,Name,CommandLine` | `[RO] ps -eo user,pid,ppid,lstart,stat,cmd` | `[RO] ps -axo user,pid,ppid,lstart,state,command` | **Besonderheiten:** - Windows unterscheidet zwischen internem Dienstnamen und sichtbarem Anzeigenamen. - Bei systemd gehört die Endung `.service` zum vollständigen Unit-Namen, kann bei eindeutigen Namen aber häufig weggelassen werden. - `launchctl list` zeigt nicht automatisch alle Konfigurationsdetails eines Dienstes. - `launchctl print system/` erwartet das tatsächliche launchd-Label. - Ein laufender Prozess beweist noch nicht, dass der Dienst auf dem erwarteten Port lauscht oder fachlich korrekt arbeitet. > Auf dieser frühen Diagnosestufe sollte ein Dienst noch nicht neu gestartet werden. Zuerst müssen Status, Prozess, Port und relevante Protokolle erfasst werden.
---
7. Geeignete Vergleichstests durchführen Ein Vergleichstest verändert jeweils nur **eine Prüfdimension**. Dadurch lässt sich erkennen, welche Eigenschaft mit dem Fehler zusammenhängt. | Ausgangssituation | Sinnvoller Vergleich | |---|---| | Ein Benutzer meldet einen Fehler | Anderes Benutzerkonto am gleichen Client | | Ein Client ist betroffen | Gleicher Benutzer an einem anderen Client | | WLAN-Zugriff scheitert | Gleicher Client über LAN oder VPN | | Zugriff per Servername scheitert | DNS-Ergebnis prüfen und mit dokumentierter Zieladresse vergleichen | | Eine URL funktioniert nicht | Andere Funktion desselben Dienstes testen | | Ein Standort ist betroffen | Zugriff von einem anderen Standort testen | | Zugriff über Loadbalancer scheitert | Backend nur über den vorgesehenen administrativen Testweg prüfen | | Anwendung meldet einen Fehler | Porttest und protokollspezifischen Funktionstest getrennt durchführen | | Produktivsystem ist betroffen | Verhalten im freigegebenen Testsystem vergleichen | | Fehler tritt zeitabhängig auf | Ergebnisse mit Last, Sicherung oder geplanten Aufgaben vergleichen | **Regel für einen aussagekräftigen Vergleich:** ```text Gleicher Benutzer + anderer Client oder anderer Benutzer + gleicher Client oder gleicher Client + anderer Netzwerkweg ``` Werden mehrere Eigenschaften gleichzeitig verändert, ist das Ergebnis häufig nicht eindeutig. > Der direkte Zugriff auf ein Backend kann Sicherheitsregeln, Authentifizierung, TLS-Prüfungen oder den Loadbalancer umgehen. Er darf nur über einen freigegebenen administrativen Testweg erfolgen.
---
8. Ersten Client-zu-Dienst-Test dokumentieren Bevor auf dem Server weitergesucht wird, sollte der Fehler möglichst reproduziert und genau protokolliert werden. | Prüfpunkte | Zu dokumentierende Information | |---|---| | Ausgangsgerät | Hostname, Betriebssystem und Netzwerkverbindung | | Benutzerkontext | Betroffenes Konto oder Rolle, ohne Kennwort | | Ziel | Servername, URL, Freigabe oder Anwendung | | Zeitpunkt | Datum, Uhrzeit und Zeitzone | | Aktion | Exakter Arbeitsschritt, der den Fehler auslöst | | Ergebnis | Vollständige Fehlermeldung oder Statuscode | | Dauer | Sofortiger Fehler oder Zeitüberschreitung | | Wiederholbarkeit | Immer, sporadisch oder nur einmal | | Vergleichstest | Zweiter Client, Benutzer oder Netzwerkweg | | Beweismittel | Screenshot, Ereignis-ID, Logauszug oder Befehlsausgabe | **Beispiel:** ```text Zeitpunkt: 2026-07-31T09:15:42+02:00 Client: client-017 Betriebssystem: Windows 11 Benutzerrolle: Standardbenutzer Ziel: https://intranet.example.local/login Aktion: Anmeldeformular abgesendet Ergebnis: HTTP 503 Dauer: Antwort nach ungefähr 2 Sekunden Wiederholbar: Ja Vergleich: Gleicher Fehler auf einem zweiten Client ``` Sensible Inhalte wie Kennwörter, Sitzungscookies, Zugriffstoken, private Schlüssel oder vollständige personenbezogene Daten dürfen nicht in die Dokumentation übernommen werden.
---
9. Letzte Änderungen und zeitliche Zusammenhänge erfassen Viele Dienstfehler entstehen nach einer technischen oder organisatorischen Änderung. Ein zeitlicher Zusammenhang ist jedoch noch kein Beweis für die Ursache. Zu prüfen sind insbesondere: - Betriebssystem- und Anwendungsupdates, - Änderungen an Konfigurationsdateien, - Zertifikatswechsel, - Kennwortänderungen von Dienstkonten, - Änderungen an Gruppen oder Berechtigungen, - Firewall- und Proxyänderungen, - DNS- oder Loadbalanceränderungen, - Datenbankmigrationen, - Speicher- und Volumeänderungen, - Container- oder Image-Updates, - Neustarts und Stromausfälle, - Sicherungs- und Wartungsaufgaben, - Änderungen an externen APIs, - abgelaufene Lizenzen oder Zertifikate, - neu eingerichtete Überwachungs- oder Sicherheitssoftware. | Frage | Zweck | |---|---| | Was wurde geändert? | Technische Änderung bestimmen | | Wann wurde es geändert? | Zeitliche Übereinstimmung prüfen | | Auf welchem System? | Betroffene Komponente bestimmen | | Wer oder welcher Prozess führte die Änderung aus? | Rückfragen und Audit ermöglichen | | Wurde die Änderung getestet? | Fehlende Prüfungen erkennen | | Gibt es einen Rückfallplan? | Wiederherstellung bewerten | | Besteht der Fehler auch ohne diese Änderung? | Kausalität weiter untersuchen | > Die Aussage „Seit dem Update besteht der Fehler“ ist eine wichtige Spur. Erst ein reproduzierbarer Zusammenhang oder ein passender Protokolleintrag macht daraus einen belastbaren Ursachenhinweis.
---
10. Wann die Eingrenzung abgeschlossen ist Die erste Eingrenzung ist ausreichend, wenn folgende Punkte beantwortet sind: - Welche konkrete Funktion ist gestört? - Welcher Server oder Dienst stellt diese Funktion bereit? - Welche Benutzer, Geräte und Standorte sind betroffen? - Welche Bereiche sind ausdrücklich nicht betroffen? - Seit wann besteht die Störung? - Ist der Fehler reproduzierbar? - Welche Fehlermeldung oder welcher Statuscode erscheint? - Welche Vergleichstests wurden durchgeführt? - Welche Änderungen gingen der Störung voraus? - Welche technische Ebene wird als Nächstes geprüft? - Wurde der Ausgangszustand dokumentiert? **Beispiel einer abgeschlossenen Eingrenzung:** > Alle geprüften Benutzer können die Startseite des Intranets über HTTPS aufrufen. Beim Absenden des Anmeldeformulars antwortet die Anwendung jedoch mit HTTP 503. Der Fehler tritt von Windows-, Linux- und macOS-Clients sowie an zwei Standorten auf. DNS-Auflösung und Netzwerkzugriff funktionieren. Als Nächstes werden deshalb Dienststatus, Prozess und Backend-Abhängigkeiten auf dem Anwendungsserver geprüft.
---
11. Typische Fehler bei der ersten Eingrenzung | Fehler | Folge | Bessere Vorgehensweise | |---|---|---| | Sofortiger Neustart | Flüchtige Diagnoseinformationen gehen verloren | Zustand und Protokolle zuerst sichern | | Fehlermeldung als Ursache behandeln | Untersuchung beginnt an der falschen Stelle | Beobachtung und Ursache trennen | | Nur einen Benutzer befragen | Störungsumfang bleibt unbekannt | Vergleich mit weiteren Benutzern durchführen | | Nur `ping` verwenden | Dienstfunktion bleibt ungeprüft | Port- und Anwendungstest ergänzen | | Mehrere Änderungen gleichzeitig | Wirkung einzelner Maßnahmen bleibt unklar | Änderungen einzeln durchführen | | Servername nicht verifizieren | Falsches System wird untersucht | Ziel, IP-Adresse und Umgebung abgleichen | | Test- und Produktivsystem verwechseln | Falsche Ergebnisse oder Betriebsrisiko | Umgebung eindeutig dokumentieren | | Keine Zeitstempel erfassen | Protokolle lassen sich schlecht zuordnen | Datum, Uhrzeit und Zeitzone notieren | | Nur Erfolg oder Fehler notieren | Diagnose ist nicht nachvollziehbar | Befehl, Ausgabe und Kontext dokumentieren | | Geheimnisse in Tickets kopieren | Sicherheitsrisiko | Kennwörter, Token und Cookies entfernen |
---
12. Kompakte Checkliste für den Einsatz ```text [ ] Konkrete gestörte Funktion erfasst [ ] Vollständige Fehlermeldung erfasst [ ] Datum, Uhrzeit und Zeitzone notiert [ ] Betroffene Benutzer bestimmt [ ] Betroffene Clients und Betriebssysteme bestimmt [ ] Betroffene Standorte und Netzwerkwege bestimmt [ ] Funktionierende Bereiche dokumentiert [ ] Fehler reproduziert [ ] Vergleichstest durchgeführt [ ] Servername und Umgebung verifiziert [ ] Dienstname, Prozess, Protokoll und Port zugeordnet [ ] Abhängige Systeme aufgenommen [ ] Letzte Änderungen erfragt [ ] Ausgangszustand vor Änderungen dokumentiert [ ] Keine Kennwörter, Token oder vertraulichen Daten gespeichert [ ] Nächster technischer Prüfschritt festgelegt ```
--- **Ergebnis dieser Diagnosestufe** Am Ende dieser Seite steht noch nicht zwingend die Ursache fest. Es muss jedoch klar sein: ```text Was ist gestört? Wer oder was ist betroffen? Seit wann besteht die Störung? Welcher Dienst stellt die Funktion bereit? Auf welchem System läuft er? Wie lässt sich der Fehler reproduzieren? Welche technische Ebene wird als Nächstes geprüft? ``` Die nächste Diagnosestufe ist die Überprüfung von **Dienststatus und Startart**. --- **Weiterführende Quellen** - [Microsoft Learn – Get-Service](https://learn.microsoft.com/powershell/module/microsoft.powershell.management/get-service) - [Microsoft Learn – Get-CimInstance](https://learn.microsoft.com/powershell/module/cimcmdlets/get-ciminstance) - [Microsoft Learn – Windows-Dienstprogramme und Befehle](https://learn.microsoft.com/windows-server/administration/windows-commands/windows-commands) - [systemd – systemctl](https://www.freedesktop.org/software/systemd/man/latest/systemctl.html) - [systemd – systemd.unit](https://www.freedesktop.org/software/systemd/man/latest/systemd.unit.html) - [Apple – launchctl-Handbuchseite](https://keith.github.io/xcode-man-pages/launchctl.1.html) - [Apple – Aktivitätsanzeige – Benutzerhandbuch](https://support.apple.com/de-de/guide/activity-monitor/welcome/mac) # 4.2 Dienststatus und Startart prüfen Nachdem der betroffene Dienst eindeutig bestimmt wurde, wird geprüft, ob er: - im Betriebssystem registriert beziehungsweise geladen ist, - aktuell ausgeführt wird, - beendet oder fehlgeschlagen ist, - beim Systemstart oder bei Bedarf gestartet werden soll, - deaktiviert wurde, - unter dem vorgesehenen Benutzerkonto läuft, - nach einem Fehler automatisch neu gestartet wird. > **Grundsatz:** > Zuerst den vorhandenen Zustand vollständig erfassen. Einen Dienst erst danach und nur bei betrieblicher Freigabe starten, stoppen oder neu starten. --- **Ziele dieser Seite** Nach dieser Seite sollst du: - Dienstname und Anzeigename unterscheiden können, - den aktuellen Dienststatus ermitteln können, - die konfigurierte Startart überprüfen können, - Startart und aktuellen Laufzustand getrennt bewerten können, - Dienstkonto, Prozess-ID und Exitcode ermitteln können, - Windows-Dienste, systemd-Units und launchd-Jobs unterscheiden können, - deaktivierte oder maskierte Dienste erkennen können, - einen wiederholt abstürzenden Dienst identifizieren können, - Statusinformationen vor einer Änderung dokumentieren können. --- **Sicherheitskennzeichnungen** | Kennzeichnung | Bedeutung | |---|---| | `[RO]` | Rein lesende Abfrage | | `[TEST]` | Aktiver Test ohne beabsichtigte dauerhafte Konfigurationsänderung | | `[PRIV]` | Erfordert möglicherweise erhöhte Rechte | | `[FILE]` | Greift lesend oder schreibend auf eine Datei zu | | `[SENS]` | Ausgabe kann sensible Informationen enthalten | | `[CHANGE]` | Verändert den Dienstzustand oder die Konfiguration | | `[DISRUPT]` | Kann laufende Verbindungen oder Arbeitsvorgänge unterbrechen | ---
1. Startart und Dienststatus nicht verwechseln Die **Startart** beschreibt, wann beziehungsweise wodurch ein Dienst gestartet werden soll. Der **Dienststatus** beschreibt seinen aktuellen Zustand. | Startart beziehungsweise Aktivierung | Aktueller Zustand | Mögliche Bewertung | |---|---|---| | Automatisch aktiviert | Läuft | Normaler Zustand | | Automatisch aktiviert | Beendet | Startfehler, Absturz oder bewusster Stopp möglich | | Manuell beziehungsweise bedarfsgesteuert | Beendet | Kann ein normaler Zustand sein | | Manuell beziehungsweise bedarfsgesteuert | Läuft | Dienst wurde angefordert oder manuell gestartet | | Deaktiviert | Beendet | Erwarteter Zustand | | Deaktiviert | Läuft | Zustandsänderung möglicherweise noch nicht wirksam oder Sonderfall | | Aktiviert | Wiederholt startend und stoppend | Absturzschleife oder fehlerhafte Startbedingung möglich | > Ein beendeter Dienst ist nicht automatisch fehlerhaft. Bedarfsgesteuerte Dienste laufen häufig nur, wenn sie tatsächlich benötigt werden.
---
2. Dienstverwaltung der Betriebssysteme vergleichen | Betriebssystem | Dienstverwaltung | Konfigurationseinheit | Typische Statusabfrage | |---|---|---|---| | Windows | Service Control Manager | Windows-Dienst | `Get-Service` oder `sc.exe query` | | Linux mit systemd | systemd | Unit, meistens `.service` | `systemctl status` | | macOS | launchd | Daemon, Agent oder XPC-Service | `launchctl print` | **Wichtige Unterschiede:** - Windows verwendet unter anderem die Startarten automatisch, manuell und deaktiviert. - systemd unterscheidet den aktuellen Laufzustand von der Aktivierung für den Systemstart. - Eine systemd-Unit kann zusätzlich `masked` sein. Dann kann sie nicht normal gestartet werden. - macOS verwendet häufig bedarfsgesteuerte Dienste. - Ein launchd-Job muss deshalb nicht dauerhaft als Prozess laufen. - launchd unterscheidet verschiedene Ausführungsbereiche, sogenannte Domains. - Ein fehlender Prozess bedeutet bei einem bedarfsgesteuerten launchd-Dienst nicht automatisch einen Fehler.
---
3. Dienststatus unter Windows prüfen `` muss durch den internen Dienstnamen ersetzt werden. **Status eines bestimmten Dienstes:** ```powershell [RO] Get-Service -Name "" ``` **Ausgewählte Statusinformationen anzeigen:** ```powershell [RO] Get-Service -Name "" | Select-Object Name, DisplayName, Status, ServiceType ``` **Mit einem Teil des Dienstnamens suchen:** ```powershell [RO] Get-Service -Name "**" -ErrorAction SilentlyContinue ``` **Mit einem Teil des Anzeigenamens suchen:** ```powershell [RO] Get-Service -DisplayName "**" -ErrorAction SilentlyContinue ``` **Alle beendeten Dienste anzeigen:** ```powershell [RO] Get-Service | Where-Object Status -eq "Stopped" | Sort-Object DisplayName ``` **Alle laufenden Dienste anzeigen:** ```powershell [RO] Get-Service | Where-Object Status -eq "Running" | Sort-Object DisplayName ``` **Dienststatus mit `sc.exe` abfragen:** ```powershell [RO] sc.exe query "" ``` **Erweiterte Statusabfrage einschließlich Prozess-ID:** ```powershell [RO] sc.exe queryex "" ``` Typische Zustände sind: | Zustand | Bedeutung | |---|---| | `Running` beziehungsweise `RUNNING` | Dienst wird ausgeführt | | `Stopped` beziehungsweise `STOPPED` | Dienst wird nicht ausgeführt | | `StartPending` beziehungsweise `START_PENDING` | Startvorgang läuft | | `StopPending` beziehungsweise `STOP_PENDING` | Beendigung läuft | | `PausePending` | Pausierung wird vorbereitet | | `Paused` | Dienst ist pausiert | | `ContinuePending` | Fortsetzung wird vorbereitet | > Bleibt ein Dienst ungewöhnlich lange in `StartPending` oder `StopPending`, müssen Prozess, Abhängigkeiten und Ereignisprotokolle untersucht werden. Ein erzwungener Abbruch ist nicht der erste Diagnoseschritt.
---
4. Startart und Dienstkonto unter Windows prüfen `Get-Service` zeigt den Laufzustand, aber nicht alle Konfigurationsinformationen. Dafür kann die CIM-Klasse `Win32_Service` verwendet werden. **Vollständige Basiskonfiguration eines Dienstes:** ```powershell [RO][SENS] Get-CimInstance Win32_Service -Filter "Name=''" | Select-Object Name, DisplayName, State, Status, StartMode, StartName, ProcessId, ExitCode, ServiceSpecificExitCode, PathName ``` **Nur Startart und Dienstkonto anzeigen:** ```powershell [RO] Get-CimInstance Win32_Service -Filter "Name=''" | Select-Object Name, State, StartMode, StartName ``` **Konfiguration mit `sc.exe` prüfen:** ```powershell [RO][SENS] sc.exe qc "" ``` Typische Werte für `StartMode`: | Wert | Bedeutung | |---|---| | `Auto` | Automatischer Start | | `Manual` | Manueller beziehungsweise bedarfsgesteuerter Start | | `Disabled` | Dienst ist deaktiviert | | `Boot` | Start durch den Systemlader, normalerweise bei Treibern | | `System` | Start während der Kernelinitialisierung, normalerweise bei Treibern | **Typische Angaben von `sc.exe qc`:** | Angabe | Bedeutung | |---|---| | `SERVICE_NAME` | Interner Dienstname | | `TYPE` | Art des Dienstes oder Treibers | | `START_TYPE` | Konfigurierte Startart | | `ERROR_CONTROL` | Verhalten bei Startfehlern während des Systemstarts | | `BINARY_PATH_NAME` | Programmdatei und Startparameter | | `DEPENDENCIES` | Konfigurierte Abhängigkeiten | | `SERVICE_START_NAME` | Verwendetes Dienstkonto | > `[SENS]`: Programmpfade und Startparameter können interne Verzeichnisstrukturen, Servernamen oder andere schützenswerte Konfigurationsangaben enthalten.
---
5. Verzögerten automatischen Start unter Windows prüfen Die Startart `Auto` allein zeigt nicht immer, ob der automatische Start verzögert erfolgt. **Dienstkonfiguration über CIM prüfen:** ```powershell [RO] Get-CimInstance Win32_Service -Filter "Name=''" | Select-Object Name, State, StartMode, DelayedAutoStart ``` Interpretation: | `StartMode` | `DelayedAutoStart` | Bedeutung | |---|---:|---| | `Auto` | `False` | Normaler automatischer Start | | `Auto` | `True` | Verzögerter automatischer Start | | `Manual` | `False` | Manueller oder bedarfsgesteuerter Start | | `Disabled` | `False` | Dienst ist deaktiviert | Falls `DelayedAutoStart` auf dem untersuchten System nicht ausgegeben wird, kann der Wert gezielt in der Dienstkonfiguration der Registrierung geprüft werden: ```powershell [RO] Get-ItemProperty ` -Path "HKLM:\SYSTEM\CurrentControlSet\Services\" ` -Name DelayedAutoStart ` -ErrorAction SilentlyContinue ``` Dabei gilt üblicherweise: | Wert | Bedeutung | |---:|---| | `1` | Verzögerter automatischer Start aktiviert | | `0` oder nicht vorhanden | Kein verzögerter Start daraus ableitbar | > Die Registrierung darf an dieser Stelle nur gelesen werden. Eine Änderung der Startart gehört in ein freigegebenes Änderungsverfahren.
---
6. Dienststatus unter Linux mit systemd prüfen `` muss durch den tatsächlichen Unit-Namen ersetzt werden, beispielsweise `nginx.service`. **Ausführlichen Status anzeigen:** ```bash [RO] systemctl status "" --no-pager ``` **Aktuellen Laufzustand abfragen:** ```bash [RO] systemctl is-active "" ``` **Prüfen, ob die Unit für einen automatischen Start aktiviert ist:** ```bash [RO] systemctl is-enabled "" ``` **Prüfen, ob die Unit fehlgeschlagen ist:** ```bash [RO] systemctl is-failed "" ``` **Wichtige Eigenschaften kompakt anzeigen:** ```bash [RO] systemctl show "" \ --property=Id,Names,LoadState,ActiveState,SubState,UnitFileState,MainPID,ExecMainCode,ExecMainStatus,Result ``` **Alle fehlgeschlagenen Units anzeigen:** ```bash [RO] systemctl --failed --no-pager ``` **Laufende Dienste anzeigen:** ```bash [RO] systemctl list-units \ --type=service \ --state=running \ --no-pager ``` **Installierte Service-Unit-Dateien und Aktivierungszustände anzeigen:** ```bash [RO] systemctl list-unit-files --type=service --no-pager ``` > `systemctl status` zeigt zusätzlich einige aktuelle Protokollzeilen. Für eine vollständige Protokollanalyse wird später gezielt `journalctl` verwendet.
---
7. systemd-Zustände richtig interpretieren systemd verwendet mehrere voneinander unabhängige Zustandsangaben. **Ladezustand:** | `LoadState` | Bedeutung | |---|---| | `loaded` | Unit-Datei wurde erfolgreich geladen | | `not-found` | Keine passende Unit-Datei gefunden | | `error` | Fehler beim Laden | | `masked` | Unit wurde maskiert und kann nicht normal gestartet werden | **Aktivzustand:** | `ActiveState` | Bedeutung | |---|---| | `active` | Unit ist aktiv | | `inactive` | Unit ist nicht aktiv | | `activating` | Aktivierung läuft | | `deactivating` | Deaktivierung läuft | | `failed` | Aktivierung oder Ausführung ist fehlgeschlagen | | `reloading` | Konfiguration wird neu geladen | **Typische Aktivierungszustände:** | `systemctl is-enabled` | Bedeutung | |---|---| | `enabled` | Für einen vorgesehenen automatischen Start aktiviert | | `enabled-runtime` | Nur bis zum nächsten Neustart aktiviert | | `disabled` | Nicht für automatischen Start aktiviert | | `static` | Keine eigene Aktivierung über einen Installationsabschnitt; kann abhängig gestartet werden | | `indirect` | Indirekte Aktivierung über eine andere Unit vorgesehen | | `masked` | Start vollständig blockiert | | `masked-runtime` | Bis zum nächsten Neustart maskiert | | `generated` | Unit wurde dynamisch erzeugt | | `transient` | Temporäre Unit | | `not-found` | Unit wurde nicht gefunden | **Wichtige Kombinationen:** | Laufzustand | Aktivierungszustand | Bewertung | |---|---|---| | `active` | `enabled` | Läuft und ist dauerhaft aktiviert | | `inactive` | `enabled` | Sollte möglicherweise laufen; Start- und Protokollprüfung erforderlich | | `active` | `disabled` | Wurde manuell, abhängig oder auf anderem Weg gestartet | | `inactive` | `static` | Kann bei bedarfsgesteuerten oder abhängigen Units normal sein | | `failed` | beliebig | Fehlerursache und Protokolle untersuchen | | `inactive` | `masked` | Start ist absichtlich blockiert | > `disabled` bedeutet nicht automatisch „defekt“. Es bedeutet zunächst nur, dass die Unit nicht über ihre normalen Installationsverknüpfungen für den automatischen Start aktiviert ist.
---
8. systemd-Unit-Datei und Startbefehl prüfen **Wirksame Unit-Datei einschließlich Ergänzungen anzeigen:** ```bash [RO][FILE][SENS] systemctl cat "" ``` **Pfad der geladenen Unit-Datei anzeigen:** ```bash [RO] systemctl show "" --property=FragmentPath ``` **Ergänzende Drop-in-Konfigurationen anzeigen:** ```bash [RO] systemctl show "" --property=DropInPaths ``` **Startbefehl und Dienstkonto anzeigen:** ```bash [RO][SENS] systemctl show "" \ --property=User,Group,ExecStart,WorkingDirectory,EnvironmentFiles ``` **Abhängigkeiten anzeigen:** ```bash [RO] systemctl list-dependencies "" --no-pager ``` **Prüfen, wodurch die Unit für den Systemstart eingebunden ist:** ```bash [RO] systemctl is-enabled "" ``` Die Ausgabe von `systemctl cat` kann enthalten: - ursprüngliche Unit-Datei, - lokale Überschreibungen, - Drop-in-Dateien, - Start- und Stopbefehle, - Dienstkonto, - Neustartregeln, - Abhängigkeiten, - Umgebungsdateien. > `[SENS]`: Unit-Dateien können interne Pfade, Serveradressen oder Umgebungsdateien referenzieren. Die Inhalte von geheimen Umgebungsdateien dürfen nicht ungeprüft in Tickets oder Dokumentationen kopiert werden.
---
9. Dienststatus unter macOS mit launchd prüfen macOS unterscheidet unter anderem folgende Domains: | Domain | Bedeutung | Beispiel | |---|---|---| | `system` | Systemweite Dienste | `system/com.example.service` | | `user/` | Dienste eines Benutzerkontextes | `user/501/com.example.service` | | `gui/` | Dienste einer grafischen Anmeldesitzung | `gui/501/com.example.agent` | **Benutzer-ID des aktuell angemeldeten Terminalbenutzers anzeigen:** ```bash [RO] id -u ``` **Systemweiten Dienst prüfen:** ```bash [RO] launchctl print "system/
---
10. Deaktivierte launchd-Dienste unter macOS prüfen **Deaktivierungsüberschreibungen im Systembereich anzeigen:** ```bash [RO] launchctl print-disabled system ``` **Deaktivierungsüberschreibungen im GUI-Bereich anzeigen:** ```bash [RO] launchctl print-disabled "gui/$(id -u)" ``` Ein Eintrag mit `true` bedeutet, dass der Dienst in dieser Domain deaktiviert wurde. Ein Eintrag mit `false` bedeutet, dass eine Aktivierungsüberschreibung vorhanden sein kann. **Wichtig:** - Nicht jeder Dienst erscheint in `print-disabled`. - Ein fehlender Eintrag bedeutet nicht automatisch, dass der Dienst aktiviert ist. - Die effektive Startentscheidung kann zusätzlich von der plist-Konfiguration und Startbedingungen abhängen. - Aktivierungsüberschreibungen werden außerhalb der eigentlichen plist-Datei verwaltet. - Ein launchd-Job kann aktiviert, aber momentan ohne laufenden Prozess sein. - Bedarfsgesteuerte Dienste werden möglicherweise erst beim Eintreten einer Startbedingung ausgeführt.
---
11. launchd-Konfiguration unter macOS prüfen Typische Speicherorte sind: | Pfad | Bedeutung | |---|---| | `/System/Library/LaunchDaemons` | Von macOS bereitgestellte systemweite Dienste | | `/Library/LaunchDaemons` | Zusätzlich installierte systemweite Dienste | | `/System/Library/LaunchAgents` | Von macOS bereitgestellte Benutzer-Agenten | | `/Library/LaunchAgents` | Zusätzlich installierte Benutzer-Agenten | | `~/Library/LaunchAgents` | Agenten des jeweiligen Benutzers | > Dateien unter `/System/Library` gehören zum Betriebssystem und dürfen nicht manuell verändert werden. **Konfigurationsdatei eines bekannten Drittanbieterdienstes lesbar anzeigen:** ```bash [RO][FILE][SENS] plutil -p "/Library/LaunchDaemons/
---
12. Letzten Exitstatus und wiederholte Starts erkennen | Betriebssystem | Prüfung | |---|---| | Windows | Dienststatus, Prozess-ID, Exitcode und Ereignisprotokolle | | Linux | `Result`, `ExecMainCode`, `ExecMainStatus`, Neustartzähler und Journal | | macOS | `state`, `pid`, `last exit code` und Unified Logging | **Windows:** ```powershell [RO] Get-CimInstance Win32_Service -Filter "Name=''" | Select-Object Name, State, ProcessId, ExitCode, ServiceSpecificExitCode ``` **Linux:** ```bash [RO] systemctl show "" \ --property=ActiveState,SubState,Result,MainPID,ExecMainCode,ExecMainStatus,NRestarts ``` **macOS:** ```bash [RO] launchctl print "system/
---
13. Status vor einer Änderung dokumentieren Vor einem Start, Stopp oder Neustart sollten mindestens folgende Informationen gesichert werden: | Information | Zweck | |---|---| | Datum, Uhrzeit und Zeitzone | Zuordnung zu Protokolleinträgen | | Dienstname und Anzeigename | Eindeutige Identifikation | | Aktueller Status | Ausgangszustand | | Konfigurierte Startart | Sollverhalten | | Prozess-ID | Zuordnung zum Prozess | | Dienstkonto | Berechtigungsprüfung | | Programmpfad und Argumente | Konfigurationsprüfung | | Exitcode | Hinweis auf Beendigungsursache | | Abhängigkeiten | Auswirkungsanalyse | | Neustartregeln | Erkennung automatischer Wiederanläufe | | Letzte Protokollmeldungen | Erhaltung flüchtiger Diagnoseinformationen | | Aktive Verbindungen | Bewertung möglicher Unterbrechungen | **Kompakte Dokumentationsvorlage:** ```text Zeitpunkt: Server: Betriebssystem: Dienstname: Anzeigename beziehungsweise Label: Dienststatus: Startart beziehungsweise Aktivierung: Prozess-ID: Dienstkonto: Programmpfad: Letzter Exitcode: Neustartzähler: Abhängigkeiten: Relevante Protokollmeldung: Bewertung: Nächster Prüfschritt: ```
---
14. Dienstzustand verändern – nur nach Freigabe Die folgenden Befehle sind **keine reinen Diagnosebefehle**. Sie verändern den Zustand und können Benutzer, Verbindungen oder Datenverarbeitung beeinträchtigen. | Aufgabe | Windows PowerShell | Linux mit systemd | macOS mit launchd | |---|---|---|---| | Dienst starten | `[CHANGE][PRIV] Start-Service -Name ""` | `[CHANGE][PRIV] sudo systemctl start ""` | `[CHANGE][PRIV] sudo launchctl kickstart "system/
---
15. Typische Fehlinterpretationen | Fehlinterpretation | Tatsächliche Bedeutung | |---|---| | „Der Dienst ist beendet, also ist er defekt.“ | Ein manueller oder bedarfsgesteuerter Dienst kann regulär beendet sein | | „Der Dienst ist aktiviert, also läuft er.“ | Aktivierung und aktueller Laufzustand sind getrennte Eigenschaften | | „Der Prozess läuft, also funktioniert der Dienst.“ | Port, Protokoll und Anwendungsfunktion können trotzdem fehlerhaft sein | | „systemd zeigt `static`, also ist die Unit deaktiviert.“ | Die Unit kann durch Abhängigkeiten oder andere Auslöser gestartet werden | | „systemd zeigt `disabled`, also kann die Unit nicht gestartet werden.“ | Ein deaktivierter Dienst kann weiterhin manuell gestartet werden | | „systemd zeigt `masked`, das ist dasselbe wie `disabled`.“ | Eine maskierte Unit ist zusätzlich gegen normalen Start blockiert | | „launchd zeigt keine PID, also ist der Dienst defekt.“ | Ein bedarfsgesteuerter Job kann momentan ohne Prozess sein | | „Exitcode 0 beweist vollständige Funktion.“ | Er zeigt nur eine erfolgreiche Beendigung nach Definition des Programms | | „Ein Neustart hat das Problem gelöst.“ | Er kann nur das sichtbare Fehlerbild vorübergehend beseitigt haben | | „Automatischer Neustart ist immer erwünscht.“ | Er kann Abstürze verdecken oder eine Neustartschleife erzeugen |
---
16. Checkliste zur Status- und Startartprüfung ```text [ ] Internen Dienstnamen beziehungsweise launchd-Label ermittelt [ ] Anzeigenamen und technischen Namen unterschieden [ ] Richtigen Server und richtige Umgebung bestätigt [ ] Aktuellen Dienststatus erfasst [ ] Startart beziehungsweise Aktivierungszustand geprüft [ ] Bedarfsgesteuerten Betrieb berücksichtigt [ ] Deaktivierung oder Maskierung geprüft [ ] Prozess-ID erfasst [ ] Dienstkonto beziehungsweise Ausführungskontext geprüft [ ] Programmpfad und Startargumente geprüft [ ] Exitcode und dienstspezifischen Exitcode erfasst [ ] Neustartzähler beziehungsweise wiederholte Starts geprüft [ ] Abhängigkeiten aufgenommen [ ] Ausgangszustand vor Änderungen dokumentiert [ ] Noch keine ungeprüfte Zustandsänderung durchgeführt [ ] Nächsten Diagnoseschritt festgelegt ```
--- **Bewertung des Ergebnisses** | Ergebnis | Nächster Schritt | |---|---| | Dienst ist nicht registriert oder nicht auffindbar | Installation, Produktdokumentation und Zielsystem prüfen | | Dienst ist deaktiviert oder maskiert | Grund der Deaktivierung und Änderungsverlauf klären | | Dienst ist beendet, sollte aber laufen | Startfehler, Exitcode und Protokolle untersuchen | | Dienst hängt im Übergangszustand | Prozess, Abhängigkeiten und Protokolle prüfen | | Dienst startet und beendet sich wieder | Exitcode, Neustartregeln und Anwendungsprotokolle prüfen | | Dienst läuft stabil | Prozess, Listener, Port und Anwendungsfunktion prüfen | | Dienst läuft unter falschem Konto | Konfiguration und benötigte Berechtigungen untersuchen | | Startart entspricht nicht dem Sollzustand | Sollkonfiguration und letzte Änderungen prüfen | | Zustand ist unklar | Keine Änderung durchführen; weitere Beweise sammeln | --- **Merksatz** > **„Aktiviert“ beschreibt die Startkonfiguration. „Läuft“ beschreibt den aktuellen Zustand. „Funktioniert“ muss durch einen eigenen Anwendungstest bewiesen werden.** --- **Weiterführende Quellen** - [Microsoft Learn – Get-Service](https://learn.microsoft.com/powershell/module/microsoft.powershell.management/get-service) - [Microsoft Learn – Get-CimInstance](https://learn.microsoft.com/powershell/module/cimcmdlets/get-ciminstance) - [Microsoft Learn – Win32_Service](https://learn.microsoft.com/windows/win32/cimwin32prov/win32-service) - [Microsoft Learn – sc.exe query](https://learn.microsoft.com/de-de/windows-server/administration/windows-commands/sc-query) - [Microsoft Learn – sc.exe qc](https://learn.microsoft.com/windows-server/administration/windows-commands/sc-qc) - [systemd – systemctl](https://www.freedesktop.org/software/systemd/man/latest/systemctl.html) - [systemd – systemd.service](https://www.freedesktop.org/software/systemd/man/latest/systemd.service.html) - [systemd – systemd.unit](https://www.freedesktop.org/software/systemd/man/latest/systemd.unit.html) - [Apple – launchctl-Handbuchseite](https://keith.github.io/xcode-man-pages/launchctl.1.html) - [Apple – launchd.plist-Handbuchseite](https://keith.github.io/xcode-man-pages/launchd.plist.5.html) # 4.3 Prozesse und Prozesszustände analysieren Ein Betriebssystemdienst wird letztlich durch einen oder mehrere Prozesse ausgeführt. Auch wenn die Dienstverwaltung den Zustand „läuft“ meldet, kann der zugehörige Prozess blockiert sein, ungewöhnlich viele Ressourcen verbrauchen oder fortlaufend beendet und neu gestartet werden. > **Grundsatz:** > Ein vorhandener Prozess beweist nur, dass eine Prozessinstanz existiert. Er beweist nicht, dass der Dienst Anfragen korrekt verarbeitet. --- **Ziele dieser Seite** Nach dieser Seite sollst du: - einen Dienst seinem Prozess zuordnen können, - PID und Elternprozess bestimmen können, - Benutzerkonto, Startzeit und Befehlszeile prüfen können, - CPU- und Speicherverbrauch richtig bewerten können, - Prozesszustände unter Windows, Linux und macOS einordnen können, - Zombies und blockierte Prozesse erkennen können, - Prozessneustarts und wechselnde PIDs feststellen können, - Threads, Handles und geöffnete Dateien prüfen können, - Diagnoseinformationen vor einer Prozessbeendigung sichern können. ---
1. Dienst, Prozess, Thread und PID unterscheiden | Begriff | Bedeutung | |---|---| | Dienst | Vom Betriebssystem verwaltete Hintergrundfunktion | | Prozess | Laufende Instanz eines Programms | | PID | Eindeutige Prozess-ID innerhalb des aktuell laufenden Systems | | PPID | PID des Elternprozesses | | Thread | Ausführungsstrang innerhalb eines Prozesses | | Handle | Windows-Verweis auf eine verwendete Systemressource | | Dateideskriptor | Unix-Verweis auf Datei, Socket, Pipe oder andere Ressource | | Elternprozess | Prozess, der einen anderen Prozess erzeugt hat | | Kindprozess | Von einem anderen Prozess erzeugter Prozess | | Prozessbaum | Hierarchische Darstellung von Eltern- und Kindprozessen | Ein Dienst kann: - genau einen Prozess verwenden, - mehrere Prozesse starten, - Kindprozesse erzeugen, - mehrere Dienste in einem gemeinsamen Prozess ausführen, - bedarfsgesteuert ohne dauerhaften Prozess arbeiten, - nach einem Absturz automatisch eine neue PID erhalten. > Eine PID ist nicht dauerhaft. Nach dem Ende eines Prozesses kann dieselbe Nummer später einem anderen Prozess zugewiesen werden.
---
2. Prozesse unter Windows suchen und anzeigen Die Platzhalter `` und `` müssen ersetzt werden. **Prozess nach Namen suchen:** ```powershell [RO] Get-Process -Name "" -ErrorAction SilentlyContinue ``` Die Dateiendung `.exe` wird bei `Get-Process -Name` normalerweise nicht angegeben. **Prozess über die PID suchen:** ```powershell [RO] Get-Process -Id -ErrorAction SilentlyContinue ``` **Ausgewählte Prozessinformationen anzeigen:** ```powershell [RO] Get-Process -Id | Select-Object Id, ProcessName, StartTime, CPU, WorkingSet64, PrivateMemorySize64, VirtualMemorySize64, HandleCount, Responding ``` **Alle Prozesse nach CPU-Zeit sortieren:** ```powershell [RO] Get-Process | Sort-Object CPU -Descending | Select-Object -First 15 Id, ProcessName, CPU, WorkingSet64 ``` **Alle Prozesse nach belegtem Arbeitsspeicher sortieren:** ```powershell [RO] Get-Process | Sort-Object WorkingSet64 -Descending | Select-Object -First 15 Id, ProcessName, WorkingSet64, CPU ``` **Klassische Prozessübersicht:** ```powershell [RO] tasklist ``` **Bestimmten Prozess mit `tasklist` suchen:** ```powershell [RO] tasklist /FI "PID eq " ``` > Eigenschaften wie `StartTime` oder `Path` können bei geschützten Prozessen oder ohne ausreichende Rechte einen Zugriffsfehler verursachen.
---
3. Dienst einem Windows-Prozess zuordnen **Dienstname, Status und PID ermitteln:** ```powershell [RO] Get-CimInstance Win32_Service -Filter "Name=''" | Select-Object Name, DisplayName, State, StartName, ProcessId ``` **Alle laufenden Dienste mit ihrer PID anzeigen:** ```powershell [RO] Get-CimInstance Win32_Service | Where-Object State -eq "Running" | Select-Object Name, DisplayName, ProcessId, StartName | Sort-Object ProcessId ``` **Alle Dienste innerhalb einer bestimmten PID suchen:** ```powershell [RO] Get-CimInstance Win32_Service -Filter "ProcessId=" | Select-Object Name, DisplayName, State, StartName ``` **Erweiterte Dienstabfrage mit `sc.exe`:** ```powershell [RO] sc.exe queryex "" ``` **Dienstinformationen mit Prozessinformationen verbinden:** ```powershell [RO][SENS] $service = Get-CimInstance Win32_Service -Filter "Name=''" Get-CimInstance Win32_Process -Filter "ProcessId=$($service.ProcessId)" | Select-Object ProcessId, ParentProcessId, Name, ExecutablePath, CommandLine ``` > Mehrere Windows-Dienste können sich einen gemeinsamen Hostprozess teilen. Das ist beispielsweise bei bestimmten `svchost.exe`-Instanzen üblich. Deshalb darf nicht allein anhand des Prozessnamens entschieden werden, welcher Dienst betroffen ist.
---
4. Windows-Prozessdetails mit CIM prüfen **Prozessname, Elternprozess, Pfad und Befehlszeile anzeigen:** ```powershell [RO][SENS] Get-CimInstance Win32_Process -Filter "ProcessId=" | Select-Object ProcessId, ParentProcessId, Name, ExecutablePath, CommandLine, CreationDate ``` **Elternprozess ermitteln:** ```powershell [RO] $process = Get-CimInstance Win32_Process -Filter "ProcessId=" Get-CimInstance Win32_Process -Filter "ProcessId=$($process.ParentProcessId)" | Select-Object ProcessId, ParentProcessId, Name, CreationDate ``` **Direkte Kindprozesse anzeigen:** ```powershell [RO][SENS] Get-CimInstance Win32_Process -Filter "ParentProcessId=" | Select-Object ProcessId, ParentProcessId, Name, CommandLine ``` **Anzahl der Threads und Handles prüfen:** ```powershell [RO] Get-Process -Id | Select-Object Id, ProcessName, HandleCount, @{Name="ThreadCount";Expression={$_.Threads.Count}} ``` **Ausführungskonto des Prozesses abfragen:** ```powershell [RO][PRIV] Invoke-CimMethod ` -InputObject (Get-CimInstance Win32_Process -Filter "ProcessId=") ` -MethodName GetOwner ``` > `[SENS]`: Befehlszeilen können interne Pfade, Benutzernamen, Serveradressen oder unsicher übergebene Zugangsdaten enthalten. Die Ausgabe darf nicht ungeprüft weitergegeben werden.
---
5. Prozesse unter Linux suchen und anzeigen **Prozess nach Namen suchen:** ```bash [RO] pgrep -a "" ``` **Exakte Übereinstimmung des Prozessnamens verwenden:** ```bash [RO] pgrep -x -a "" ``` **Vollständige Befehlszeile durchsuchen:** ```bash [RO][SENS] pgrep -f -a "" ``` **Bestimmte PID untersuchen:** ```bash [RO][SENS] ps -p \ -o user,pid,ppid,lstart,etime,stat,%cpu,%mem,rss,vsz,cmd ``` **Alle Prozesse ausführlich anzeigen:** ```bash [RO][SENS] ps -eo user,pid,ppid,lstart,etime,stat,%cpu,%mem,rss,vsz,cmd ``` **Nach CPU-Auslastung sortieren:** ```bash [RO] ps -eo pid,ppid,user,stat,%cpu,%mem,etime,comm \ --sort=-%cpu | head -n 16 ``` **Nach residentem Speicher sortieren:** ```bash [RO] ps -eo pid,ppid,user,stat,%cpu,%mem,rss,etime,comm \ --sort=-rss | head -n 16 ``` **Interaktive Prozessübersicht:** ```bash [RO] top ``` Falls installiert: ```bash [RO] htop ``` > `htop` gehört nicht auf jeder Linux-Distribution zur Standardinstallation.
---
6. Linux-Prozessdetails über das proc-Dateisystem prüfen Linux stellt Prozessinformationen normalerweise unter `/proc/` bereit. **Ausführbare Datei bestimmen:** ```bash [RO][PRIV] sudo readlink -f "/proc//exe" ``` **Arbeitsverzeichnis anzeigen:** ```bash [RO][PRIV] sudo readlink -f "/proc//cwd" ``` **Prozessstatus anzeigen:** ```bash [RO][FILE][SENS] cat "/proc//status" ``` **Befehlszeile lesbar darstellen:** ```bash [RO][FILE][SENS] tr '\0' ' ' < "/proc//cmdline" ``` **Umgebungsvariablen anzeigen:** ```bash [RO][FILE][SENS][PRIV] sudo tr '\0' '\n' < "/proc//environ" ``` **Grenzwerte des Prozesses anzeigen:** ```bash [RO][FILE] cat "/proc//limits" ``` **Eingehängte Ressourcen des Prozesses anzeigen:** ```bash [RO][FILE][SENS] cat "/proc//mountinfo" ``` **Anzahl geöffneter Dateideskriptoren ermitteln:** ```bash [RO][PRIV] sudo find "/proc//fd" -mindepth 1 -maxdepth 1 -printf '.' | wc -c ``` > `/proc//environ` kann Kennwörter, Token oder andere geheime Werte enthalten. Diese Abfrage darf nur bei berechtigtem Diagnosebedarf erfolgen. Die Ausgabe gehört nicht ungefiltert in ein Ticket.
---
7. systemd-Dienst einem Linux-Prozess zuordnen **Hauptprozess eines Dienstes anzeigen:** ```bash [RO] systemctl show "" \ --property=MainPID,ControlPID,ExecMainPID,ExecMainStartTimestamp ``` **Prozessbaum der Unit im Status anzeigen:** ```bash [RO] systemctl status "" --no-pager ``` **Prozesse innerhalb der Unit beziehungsweise Control Group anzeigen:** ```bash [RO] systemd-cgls --unit "" ``` **Ressourcennutzung von Control Groups beobachten:** ```bash [RO] systemd-cgtop ``` **Hauptprozess anschließend mit `ps` untersuchen:** ```bash [RO][SENS] ps -p \ -o user,pid,ppid,lstart,etime,stat,%cpu,%mem,rss,vsz,cmd ``` **Wichtig:** - `MainPID=0` kann bedeuten, dass aktuell kein Hauptprozess vorhanden ist. - Eine Unit kann mehrere Prozesse enthalten. - Ein Kindprozess kann weiterlaufen, obwohl der ursprüngliche Startprozess bereits beendet wurde. - Bei `Type=oneshot` kann eine erfolgreiche Unit aktiv sein, obwohl kein dauerhafter Prozess läuft. - Der systemd-Status der gesamten Unit ist aussagekräftiger als die isolierte Betrachtung nur einer PID.
---
8. Prozesse unter macOS suchen und anzeigen **Prozess nach Namen oder Befehlszeile suchen:** ```bash [RO][SENS] pgrep -alf "" ``` **Exakten Prozessnamen suchen:** ```bash [RO] pgrep -x "" ``` **Bestimmte PID ausführlich anzeigen:** ```bash [RO][SENS] ps -p \ -o user,pid,ppid,lstart,etime,state,%cpu,%mem,rss,vsz,command ``` **Alle Prozesse ausführlich anzeigen:** ```bash [RO][SENS] ps -axo user,pid,ppid,lstart,etime,state,%cpu,%mem,rss,vsz,command ``` **Prozesse nach aktueller CPU-Nutzung sortiert anzeigen:** ```bash [RO] ps -Arcwwxo pid,ppid,user,state,%cpu,%mem,rss,etime,command ``` **Prozesse nach Speicherverbrauch sortiert anzeigen:** ```bash [RO] ps -Amcwwxo pid,ppid,user,state,%cpu,%mem,rss,etime,command ``` **Interaktive Prozessübersicht nach CPU-Nutzung:** ```bash [RO] top -o cpu ``` **Drei Messungen für eine bestimmte PID ausgeben:** ```bash [RO] top -l 3 -pid \ -stats pid,command,cpu,mem,threads,state,time ``` > Bei `top -l` ist die erste CPU-Messung möglicherweise noch nicht aussagekräftig, weil für eine belastbare Prozentberechnung ein zeitlicher Vergleich benötigt wird.
---
9. launchd-Dienst einem macOS-Prozess zuordnen **Systemweiten launchd-Dienst prüfen:** ```bash [RO] launchctl print "system/
---
10. Wichtige Prozessfelder verstehen | Feld | Bedeutung | Diagnosewert | |---|---|---| | `PID` | Prozess-ID | Identifiziert die aktuelle Instanz | | `PPID` | Elternprozess-ID | Zeigt den erzeugenden Prozess | | `USER` | Ausführungskonto | Wichtig für Berechtigungen | | `START` beziehungsweise `LSTART` | Startzeit | Hilft beim Erkennen von Neustarts | | `ETIME` | Vergangene Zeit seit Prozessstart | Zeigt kurze oder lange Laufzeit | | `STAT` beziehungsweise `STATE` | Prozesszustand | Erkennt Schlafen, Warten, Stopp oder Zombie | | `%CPU` | CPU-Nutzung | Hinweis auf Last oder Endlosschleife | | `%MEM` | Anteil am physischen Speicher | Grober Speichervergleich | | `RSS` | Aktuell residenter physischer Speicher | Praktischer Speicherindikator | | `VSZ` | Virtueller Adressraum | Nicht mit tatsächlich belegtem RAM gleichsetzen | | `TIME` | Verbrauchte CPU-Zeit | Kumulierte Prozessorzeit | | `CMD` beziehungsweise `COMMAND` | Programm und Argumente | Identifikation und Konfigurationsprüfung | | `THREADS` | Anzahl der Threads | Hinweis auf Threadwachstum | | `HandleCount` | Offene Windows-Handles | Hinweis auf Ressourcenleck | | `FD` | Dateideskriptor | Geöffnete Ressource unter Unix-Systemen | > Hoher virtueller Speicher bedeutet nicht automatisch, dass entsprechend viel physischer Arbeitsspeicher belegt ist.
---
11. Linux-Prozesszustände interpretieren Der erste Buchstabe in der Spalte `STAT` beschreibt den grundlegenden Zustand. | Zustand | Bedeutung | Bewertung | |---|---|---| | `R` | Laufend oder ausführungsbereit | Bei dauerhafter hoher CPU-Nutzung untersuchen | | `S` | Unterbrechbarer Schlafzustand | Häufig normal; Prozess wartet auf ein Ereignis | | `D` | Nicht unterbrechbarer Wartezustand | Häufig Warten auf Ein-/Ausgabe; dauerhaft auffällig | | `T` | Gestoppt oder durch Debugger angehalten | Ursache des Stopps prüfen | | `t` | Während Ablaufverfolgung gestoppt | Debugger oder Tracing prüfen | | `Z` | Zombie | Prozess ist beendet, Elternprozess hat Status noch nicht abgeholt | | `I` | Leerlaufender Kernel-Thread | Normaler Kernelzustand | | `X` | Beendeter Prozess | Normalerweise nur sehr kurz sichtbar | Weitere Zeichen können zusätzliche Eigenschaften angeben: | Zeichen | Bedeutung | |---|---| | `<` | Höhere Priorität | | `N` | Niedrigere Priorität | | `L` | Speicherseiten sind gesperrt | | `s` | Prozess ist Sitzungsleiter | | `l` | Mehrere Threads | | `+` | Vordergrund-Prozessgruppe | **Wichtige Bewertung:** - `S` ist bei Serverdiensten sehr häufig und normalerweise unauffällig. - `R` ist nur zusammen mit Messdauer und CPU-Verbrauch zu bewerten. - Ein kurzzeitiger `D`-Zustand kann normal sein. - Ein dauerhaft im Zustand `D` verbleibender Prozess kann auf Datenträger-, Netzwerkdateisystem- oder Kernelprobleme hinweisen. - Ein `Z`-Prozess verbraucht kaum Arbeitsspeicher, belegt aber weiterhin einen Eintrag in der Prozesstabelle. - Ein Zombie wird durch den fehlerhaften oder nicht reagierenden Elternprozess bereinigt, nicht durch das Beenden des bereits beendeten Kindprozesses.
---
12. macOS-Prozesszustände interpretieren macOS verwendet ebenfalls Zustandszeichen, deren genaue Kombination mehrere Eigenschaften enthalten kann. | Zustand | Grundbedeutung | |---|---| | `R` | Laufend oder ausführungsbereit | | `S` | Schlafend für weniger als ungefähr 20 Sekunden | | `I` | Länger inaktiv beziehungsweise schlafend | | `D` | Warten auf Datenträger- oder andere nicht unterbrechbare Ein-/Ausgabe | | `T` | Angehalten | | `Z` | Zombie | | `U` | Nicht unterbrechbarer Wartezustand | | `H` | Angehaltene Ausführung | | `L` | Prozess besitzt gesperrte Speicherseiten | Abhängig von der Ausgabe können zusätzliche Zeichen erscheinen. Deshalb sollte bei Unklarheiten die lokale Handbuchseite herangezogen werden: ```bash [RO] man ps ``` > Prozesszustände dürfen nicht isoliert bewertet werden. Entscheidend ist, ob ein Zustand über einen längeren Messzeitraum bestehen bleibt und gleichzeitig eine Funktionsstörung vorliegt.
---
13. CPU-Verbrauch richtig untersuchen Eine einzelne Momentaufnahme reicht häufig nicht aus. CPU-Nutzung sollte über mehrere Messpunkte beobachtet werden. | Beobachtung | Mögliche Erklärung | |---|---| | Kurzer CPU-Ausschlag | Reguläre Verarbeitung einer Anfrage | | Dauerhaft hohe CPU-Nutzung | Hohe Last, Schleife, Kompression, Verschlüsselung oder fehlerhafte Verarbeitung | | Niedrige CPU-Nutzung trotz Störung | Warten auf Netzwerk, Datenträger, Sperre oder Backend | | Hohe gesamte CPU-Last, Dienst selbst unauffällig | Konkurrenz durch andere Prozesse | | Ein Prozess über 100 Prozent unter Unix | Nutzung mehrerer CPU-Kerne möglich | | Steigende kumulierte CPU-Zeit | Prozess verbraucht weiterhin Prozessorzeit | **Windows – zwei Messpunkte vergleichen:** ```powershell [RO] Get-Process -Id | Select-Object Id, ProcessName, CPU, StartTime ``` Die Eigenschaft `CPU` enthält die bisher vom Prozess verbrauchte Prozessorzeit in Sekunden und nicht die momentane prozentuale Auslastung. **Linux – Prozess beobachten:** ```bash [RO] top -p ``` **macOS – mehrere Messpunkte erfassen:** ```bash [RO] top -l 5 -s 2 -pid \ -stats pid,command,cpu,mem,threads,state,time ``` > Ein Prozess mit niedriger CPU-Nutzung kann trotzdem blockiert sein. Warten auf Ein-/Ausgabe benötigt häufig kaum Prozessorzeit.
---
14. Speicherverbrauch richtig untersuchen | Messwert | Bedeutung | |---|---| | Working Set | Derzeit im physischen Speicher befindliche Speicherseiten unter Windows | | Private Memory | Speicher, der dem Prozess privat zugeordnet ist | | RSS | Residenter physischer Speicher unter Unix-Systemen | | VSZ | Gesamter virtueller Adressraum | | Swap | Auf Auslagerungsspeicher verschobene Daten | | Page Fault | Zugriff auf eine nicht aktuell im Working Set befindliche Speicherseite | **Windows:** ```powershell [RO] Get-Process -Id | Select-Object Id, ProcessName, WorkingSet64, PrivateMemorySize64, VirtualMemorySize64, PagedMemorySize64 ``` **Linux:** ```bash [RO] ps -p -o pid,etime,%mem,rss,vsz,stat,comm ``` **macOS:** ```bash [RO] ps -p -o pid,etime,%mem,rss,vsz,state,command ``` **Hinweise auf ein mögliches Speicherleck:** - Speicherverbrauch steigt über längere Zeit kontinuierlich, - der Verbrauch sinkt nach abgeschlossenen Aufgaben nicht wieder, - Auslagerungsaktivität nimmt zu, - der Prozess wird wegen Speichermangels beendet, - die Dienstfunktion wird mit zunehmender Laufzeit langsamer, - ein Neustart reduziert den Speicherverbrauch nur vorübergehend. > Ein Speicherleck lässt sich nicht durch einen einzelnen hohen Messwert beweisen. Dafür ist eine Zeitreihe unter vergleichbarer Last erforderlich.
---
15. Threads, Handles und Dateideskriptoren prüfen Ein Prozess kann funktionsunfähig werden, obwohl er weiterhin läuft. Ursachen können erschöpfte Handles, Dateideskriptoren oder ungewöhnlich viele Threads sein. | Ressource | Windows | Linux | macOS | |---|---|---|---| | Threads | `Get-Process` | `ps -L` | `ps -M` | | Handles | `HandleCount` | Nicht gleichbedeutend | Nicht gleichbedeutend | | Dateideskriptoren | Über spezialisierte Werkzeuge | `/proc//fd` oder `lsof` | `lsof` | | Geöffnete Dateien | Sysinternals-Werkzeuge oder Prozesswerkzeuge | `lsof -p` | `lsof -p` | **Windows – Thread- und Handleanzahl:** ```powershell [RO] Get-Process -Id | Select-Object Id, ProcessName, HandleCount, @{Name="ThreadCount";Expression={$_.Threads.Count}} ``` **Linux – Threads anzeigen:** ```bash [RO] ps -L -p -o pid,tid,psr,stat,%cpu,comm ``` **Linux – geöffnete Ressourcen anzeigen:** ```bash [RO][SENS][PRIV] sudo lsof -nP -p ``` **macOS – Threads anzeigen:** ```bash [RO] ps -M -p ``` **macOS – geöffnete Ressourcen anzeigen:** ```bash [RO][SENS][PRIV] sudo lsof -nP -p ``` Verdächtig ist nicht allein eine hohe Anzahl, sondern insbesondere: - kontinuierliches Wachstum, - Erreichen eines konfigurierten Grenzwertes, - Meldungen wie „too many open files“, - fehlgeschlagene neue Verbindungen, - steigende Threadzahl ohne entsprechende Last, - Handles oder Dateien werden nach Aufgaben nicht freigegeben.
---
16. Wechselnde PIDs und Neustartschleifen erkennen Eine neue PID kann bedeuten, dass ein Prozess neu gestartet wurde. **Windows – wiederholte Dienstabfrage:** ```powershell [RO] Get-CimInstance Win32_Service -Filter "Name=''" | Select-Object Name, State, ProcessId, ExitCode ``` **Linux – Neustartzähler und Hauptprozess:** ```bash [RO] systemctl show "" \ --property=MainPID,NRestarts,ActiveEnterTimestamp,ExecMainStartTimestamp,Result ``` **macOS – Anzahl der Starts und aktuelle PID:** ```bash [RO] launchctl print "system/
---
17. Nicht reagierenden Prozess richtig bewerten Ein Prozess kann: - CPU-intensiv arbeiten, - auf Datenträgerzugriff warten, - auf eine Netzwerkantwort warten, - auf eine Datenbanksperre warten, - auf einen anderen Thread warten, - durch einen Deadlock blockiert sein, - auf Benutzereingabe warten, - zwar reagieren, aber extrem langsam sein. **Windows-Eigenschaft `Responding`:** ```powershell [RO] Get-Process -Id | Select-Object Id, ProcessName, Responding ``` Diese Eigenschaft ist hauptsächlich bei Prozessen mit grafischer Benutzeroberfläche hilfreich. Sie ist kein zuverlässiger allgemeiner Funktionstest für Serverdienste. **Bessere Bewertung eines Serverprozesses:** 1. Bleibt die PID stabil? 2. Verändert sich die CPU-Zeit? 3. Lauscht der Prozess auf dem erwarteten Port? 4. Nimmt er neue Verbindungen an? 5. Reagiert das Anwendungsprotokoll? 6. Gibt es blockierte Ein-/Ausgabe? 7. Steigt die Anzahl offener Verbindungen oder Dateien? 8. Zeigen Protokolle Zeitüberschreitungen oder Sperren? 9. Funktionieren abhängige Systeme? 10. Reagiert der Prozess auf einen kontrollierten Diagnosetest? > „Läuft“ und „reagiert“ sind unterschiedliche Zustände.
---
18. Prozess beenden – nur als kontrollierte Maßnahme Die folgenden Befehle verändern den Systemzustand und können Datenverlust oder Dienstunterbrechungen verursachen. | Aufgabe | Windows | Linux | macOS | |---|---|---|---| | Reguläre Beendigung anfordern | `[CHANGE][DISRUPT] Stop-Process -Id ` | `[CHANGE][DISRUPT] kill -TERM ` | `[CHANGE][DISRUPT] kill -TERM ` | | Beendigung erzwingen | `[CHANGE][DISRUPT][PRIV] Stop-Process -Id -Force` | `[CHANGE][DISRUPT][PRIV] sudo kill -KILL ` | `[CHANGE][DISRUPT][PRIV] sudo kill -KILL ` | Vorher prüfen: ```text [ ] PID unmittelbar vor der Maßnahme erneut verifiziert [ ] Prozessname und Dienstzuordnung bestätigt [ ] Aktive Benutzer und Verbindungen geprüft [ ] Laufende Schreibvorgänge und Transaktionen berücksichtigt [ ] Prozess- und Dienstprotokolle gesichert [ ] Abhängige Dienste geprüft [ ] Cluster- oder Failover-Verhalten berücksichtigt [ ] Automatische Neustartregel geprüft [ ] Betriebliche Freigabe vorhanden [ ] Funktionstest nach der Maßnahme vorbereitet ``` **Wichtige Unterschiede:** - `SIGTERM` gibt einem Unix-Prozess die Möglichkeit, kontrolliert zu beenden. - `SIGKILL` kann nicht vom Prozess behandelt oder abgefangen werden. - `Stop-Process -Force` erzwingt die Beendigung unter Windows. - Wird nur der Prozess beendet, kann die Dienstverwaltung ihn automatisch erneut starten. - Bei verwalteten Diensten sollte grundsätzlich die jeweilige Dienstverwaltung verwendet werden. - Eine erzwungene Beendigung ist kein Ersatz für eine Ursachenanalyse. > Niemals eine alte, zuvor notierte PID ungeprüft verwenden. Die PID könnte inzwischen einem anderen Prozess gehören.
---
19. Typische Fehlinterpretationen | Fehlinterpretation | Richtige Bewertung | |---|---| | „Die PID existiert, also funktioniert der Dienst.“ | Nur die Prozessinstanz wurde nachgewiesen | | „Der Prozess verwendet wenig CPU, also ist er gesund.“ | Er kann auf Ein-/Ausgabe oder eine Sperre warten | | „Hohe CPU-Nutzung ist immer ein Fehler.“ | Sie kann durch reguläre Last entstehen | | „Hoher virtueller Speicher ist vollständig belegter RAM.“ | Virtueller Adressraum und residenter Speicher unterscheiden sich | | „Ein Zombie verbraucht sehr viel Arbeitsspeicher.“ | Er belegt hauptsächlich einen Prozesslisteneintrag | | „Der Zombie muss mit `kill` beendet werden.“ | Der Prozess ist bereits beendet; der Elternprozess muss seinen Status abholen | | „Eine neue PID ist unproblematisch.“ | Sie kann einen Absturz und automatischen Neustart anzeigen | | „Der Prozessname identifiziert den Dienst eindeutig.“ | Mehrere Dienste können denselben Prozessnamen verwenden | | „`Responding=True` beweist die Serverfunktion.“ | Es ist kein vollständiger Anwendungstest | | „SIGKILL ist schneller und deshalb besser.“ | Es verhindert eine kontrollierte Bereinigung und erhöht das Risiko |
---
20. Checkliste zur Prozessanalyse ```text [ ] Dienst dem richtigen Prozess zugeordnet [ ] PID unmittelbar aktuell ermittelt [ ] Prozessname geprüft [ ] Elternprozess und Kindprozesse geprüft [ ] Ausführungskonto geprüft [ ] Programmpfad und Befehlszeile geprüft [ ] Startzeit und bisherige Laufzeit geprüft [ ] Prozesszustand geprüft [ ] CPU über mehrere Messpunkte beobachtet [ ] Speicherverbrauch über einen Zeitraum bewertet [ ] Threadanzahl geprüft [ ] Handles beziehungsweise Dateideskriptoren geprüft [ ] Geöffnete Dateien und Sockets bei Bedarf geprüft [ ] Wechselnde PID ausgeschlossen oder dokumentiert [ ] Automatische Neustarts geprüft [ ] Exitcode und Protokolle gesichert [ ] Noch keine ungeprüfte Prozessbeendigung durchgeführt [ ] Nächsten Diagnoseschritt festgelegt ```
--- **Bewertung des Ergebnisses** | Ergebnis | Nächster Schritt | |---|---| | Kein Prozess vorhanden, Dienst sollte laufen | Dienststartfehler und Protokolle prüfen | | Prozess wird fortlaufend neu gestartet | Exitcode, Neustartregel und Startprotokoll untersuchen | | Prozess läuft stabil | Listener, Ports und Anwendungsfunktion prüfen | | Prozess verwendet dauerhaft viel CPU | Threads, Anfragen, Schleifen und Last untersuchen | | Speicherverbrauch steigt kontinuierlich | Zeitreihe, Grenzwerte und mögliche Speicherlecks untersuchen | | Prozess verbleibt in einem Wartezustand | Datenträger, Netzwerk, Sperren und Backends prüfen | | Zombieprozesse sammeln sich | Elternprozess und dessen Fehlerbehandlung untersuchen | | Handle- oder Dateideskriptoranzahl steigt | Ressourcenleck und Grenzwerte untersuchen | | Falsches Ausführungskonto | Dienstkonfiguration und Berechtigungen prüfen | | Unerwarteter Elternprozess | Startweg, Überwachung, Wrapper oder Sicherheitsvorfall untersuchen | --- **Merksatz** > **Der Dienststatus zeigt die Sicht der Dienstverwaltung. Die Prozessanalyse zeigt, was die ausführende Instanz tatsächlich tut – oder worauf sie wartet.** --- **Weiterführende Quellen** - [Microsoft Learn – Get-Process](https://learn.microsoft.com/powershell/module/microsoft.powershell.management/get-process) - [Microsoft Learn – Win32_Process](https://learn.microsoft.com/windows/win32/cimwin32prov/win32-process) - [Microsoft Learn – Win32_Service](https://learn.microsoft.com/windows/win32/cimwin32prov/win32-service) - [Microsoft Learn – tasklist](https://learn.microsoft.com/windows-server/administration/windows-commands/tasklist) - [Linux-Handbuch – ps](https://man7.org/linux/man-pages/man1/ps.1.html) - [Linux-Handbuch – proc](https://man7.org/linux/man-pages/man5/proc.5.html) - [Linux-Handbuch – pgrep](https://man7.org/linux/man-pages/man1/pgrep.1.html) - [systemd – systemctl](https://www.freedesktop.org/software/systemd/man/latest/systemctl.html) - [systemd – systemd-cgls](https://www.freedesktop.org/software/systemd/man/latest/systemd-cgls.html) - [Apple – ps-Handbuchseite](https://keith.github.io/xcode-man-pages/ps.1.html) - [Apple – pgrep-Handbuchseite](https://keith.github.io/xcode-man-pages/pkill.1.html) - [Apple – top-Handbuchseite](https://keith.github.io/xcode-man-pages/top.1.html) - [Apple – Aktivitätsanzeige – Benutzerhandbuch](https://support.apple.com/de-de/guide/activity-monitor/welcome/mac) # 4.4 Listener, Ports und Bindungsadressen prüfen **4.4 Listener, Ports und Bindungsadressen prüfen** Ein laufender Dienstprozess ist nur dann über das Netzwerk erreichbar, wenn er einen passenden Socket geöffnet und an die erwartete lokale Adresse sowie den vorgesehenen Port gebunden hat. > **Grundsatz:** > Dienststatus, Prozess, Listener und erfolgreiche Anwendungsantwort sind vier getrennte Nachweise. --- **Ziele dieser Seite** Nach dieser Seite sollst du: - TCP-Listener und UDP-Endpunkte anzeigen können, - einen Port dem verantwortlichen Prozess zuordnen können, - Bindungsadressen richtig interpretieren können, - zwischen Loopback-, Einzeladress- und Wildcard-Bindung unterscheiden können, - IPv4- und IPv6-Listener getrennt prüfen können, - lokale und entfernte Porttests durchführen können, - Portkonflikte erkennen können, - TCP-Verbindungszustände einordnen können, - zwischen „Port geschlossen“, „gefiltert“ und „Anwendung fehlerhaft“ unterscheiden können, - Listener prüfen, ohne unnötig die Dienstkonfiguration zu verändern. ---
1. Socket, Listener, Port und Verbindung unterscheiden | Begriff | Bedeutung | |---|---| | Socket | Betriebssystemobjekt für eine Kommunikationsverbindung oder einen Endpunkt | | Lokale Adresse | IP-Adresse der lokalen Netzwerkschnittstelle | | Lokaler Port | Portnummer auf dem untersuchten System | | Remoteadresse | IP-Adresse der Gegenstelle | | Remoteport | Portnummer der Gegenstelle | | TCP-Listener | Passiver TCP-Socket, der neue Verbindungen annehmen kann | | UDP-Endpunkt | Gebundener UDP-Socket; UDP besitzt keinen TCP-ähnlichen `LISTEN`-Zustand | | Bindung | Zuordnung eines Sockets zu lokaler Adresse und Port | | Wildcard-Bindung | Bindung an alle passenden lokalen Adressen | | Loopback-Bindung | Zugriff nur über die lokale Loopback-Schnittstelle | | Established | Vollständig aufgebaute TCP-Verbindung | **Beispiel einer TCP-Verbindung:** ```text Client: 192.0.2.50:53124 Server: 192.0.2.20:443 ``` Dabei ist `53124` normalerweise ein temporärer Clientport und `443` der bekannte Serverport.
---
2. Erwarteten Netzwerkendpunkt vor der Prüfung festlegen Vor der Listenerprüfung müssen folgende Sollwerte bekannt sein: | Eigenschaft | Beispiel | |---|---| | Protokoll | TCP | | Port | 443 | | IP-Version | IPv4 und IPv6 | | Erwartete Bindungsadresse | `192.0.2.20` | | Erwarteter Prozess | Webserverprozess | | Erwarteter Dienst | Interner Webdienst | | Erlaubte Quellnetze | Unternehmens-LAN und VPN | | Verschlüsselung | TLS | | Anwendungsprotokoll | HTTPS | | Zugriffspfad | Direkt, über Proxy oder Loadbalancer | **Unzureichende Prüffrage:** > „Ist Port 443 offen?“ **Bessere Prüffragen:** - Lauscht der erwartete Prozess auf TCP-Port 443? - Lauscht er auf der richtigen IPv4- oder IPv6-Adresse? - Ist der Port lokal erreichbar? - Ist er von einem vorgesehenen Clientnetz erreichbar? - Antwortet dort tatsächlich das erwartete Anwendungsprotokoll? - Wird der Zugriff durch einen Proxy oder Loadbalancer vermittelt?
---
3. Bindungsadressen richtig interpretieren | Bindungsadresse | Typische Bedeutung | |---|---| | `127.0.0.1` | Nur lokale IPv4-Verbindungen | | `::1` | Nur lokale IPv6-Verbindungen | | `0.0.0.0` | Alle lokalen IPv4-Adressen | | `::` beziehungsweise `[::]` | IPv6-Wildcard; mögliche IPv4-Mitbenutzung ist system- und socketabhängig | | Bestimmte IPv4-Adresse | Nur diese lokale IPv4-Adresse | | Bestimmte IPv6-Adresse | Nur diese lokale IPv6-Adresse | **Beispiel:** Ein Server besitzt folgende Adressen: ```text 127.0.0.1 192.0.2.20 198.51.100.20 ``` Der Dienst bindet sich an: ```text 127.0.0.1:8080 ``` Dann ist der Dienst normalerweise nicht direkt über `192.0.2.20:8080` oder `198.51.100.20:8080` erreichbar. Bindet er sich an: ```text 0.0.0.0:8080 ``` nimmt er grundsätzlich auf allen lokalen IPv4-Adressen Verbindungen an. Firewall- und Routingregeln gelten zusätzlich. > Eine Wildcard-Bindung bedeutet nicht, dass der Port aus jedem Netzwerk erreichbar ist. Paketfilter, Routing, NAT, Sicherheitsgruppen und vorgeschaltete Systeme können den Zugriff weiterhin verhindern.
---
4. TCP-Listener unter Windows anzeigen **Alle TCP-Listener anzeigen:** ```powershell [RO] Get-NetTCPConnection -State Listen | Sort-Object LocalPort, LocalAddress ``` **Wichtige Felder auswählen:** ```powershell [RO] Get-NetTCPConnection -State Listen | Select-Object LocalAddress, LocalPort, State, OwningProcess | Sort-Object LocalPort, LocalAddress ``` **Bestimmten TCP-Port prüfen:** ```powershell [RO] Get-NetTCPConnection ` -State Listen ` -LocalPort ` -ErrorAction SilentlyContinue ``` **Bestimmte lokale Adresse und Port prüfen:** ```powershell [RO] Get-NetTCPConnection ` -State Listen ` -LocalAddress "" ` -LocalPort ` -ErrorAction SilentlyContinue ``` **Klassische Alternative:** ```powershell [RO] netstat -ano -p tcp ``` **Nur TCP-Listener mit `netstat`:** ```powershell [RO] netstat -ano -p tcp | Select-String "LISTENING" ``` > `Get-NetTCPConnection` liefert strukturierte PowerShell-Objekte und ist deshalb für gezielte Filterungen besser geeignet als das Verarbeiten formatierter `netstat`-Ausgaben.
---
5. UDP-Endpunkte unter Windows anzeigen UDP besitzt keinen Verbindungszustand `Listen`. Stattdessen werden gebundene UDP-Endpunkte angezeigt. **Alle UDP-Endpunkte anzeigen:** ```powershell [RO] Get-NetUDPEndpoint | Select-Object LocalAddress, LocalPort, OwningProcess | Sort-Object LocalPort, LocalAddress ``` **Bestimmten UDP-Port prüfen:** ```powershell [RO] Get-NetUDPEndpoint ` -LocalPort ` -ErrorAction SilentlyContinue ``` **Klassische Alternative:** ```powershell [RO] netstat -ano -p udp ``` **Wichtig:** - Das Vorhandensein eines UDP-Endpunkts zeigt nur eine lokale Bindung. - UDP verwendet keinen TCP-Handshake. - Ein UDP-Porttest kann deshalb nicht so eindeutig wie ein TCP-Verbindungstest bewertet werden. - Eine fehlende UDP-Antwort kann normal sein, wenn die Testanfrage nicht dem erwarteten Anwendungsprotokoll entspricht.
---
6. Windows-Port dem verantwortlichen Prozess zuordnen **TCP-Port und Prozess-ID ermitteln:** ```powershell [RO] Get-NetTCPConnection ` -State Listen ` -LocalPort ` -ErrorAction SilentlyContinue | Select-Object LocalAddress, LocalPort, OwningProcess ``` **Zugehörigen Prozess anzeigen:** ```powershell [RO] $connection = Get-NetTCPConnection ` -State Listen ` -LocalPort ` -ErrorAction SilentlyContinue $connection | ForEach-Object { Get-Process -Id $_.OwningProcess -ErrorAction SilentlyContinue } | Select-Object Id, ProcessName, StartTime ``` **Prozess und Dienst über eine gefundene PID zuordnen:** ```powershell [RO] Get-CimInstance Win32_Service -Filter "ProcessId=" | Select-Object Name, DisplayName, State, StartName ``` **Alle TCP-Listener zusammen mit Prozessnamen anzeigen:** ```powershell [RO] Get-NetTCPConnection -State Listen | ForEach-Object { $process = Get-Process -Id $_.OwningProcess -ErrorAction SilentlyContinue [PSCustomObject]@{ LocalAddress = $_.LocalAddress LocalPort = $_.LocalPort PID = $_.OwningProcess ProcessName = $process.ProcessName } } | Sort-Object LocalPort, LocalAddress ``` > Mehrere Listener können dieselbe PID verwenden. Ebenso kann ein Prozess auf mehreren Adressen und Ports lauschen.
---
7. Listener unter Linux mit ss anzeigen `ss` ist auf modernen Linux-Systemen das bevorzugte Werkzeug für Socketinformationen. **Alle lauschenden TCP-Sockets numerisch anzeigen:** ```bash [RO] ss -lnt ``` **TCP-Listener einschließlich Prozessinformationen anzeigen:** ```bash [RO][PRIV] sudo ss -lntp ``` **Gebundene UDP-Sockets anzeigen:** ```bash [RO] ss -lnu ``` **UDP-Sockets einschließlich Prozessinformationen anzeigen:** ```bash [RO][PRIV] sudo ss -lnup ``` **TCP- und UDP-Sockets gemeinsam anzeigen:** ```bash [RO][PRIV] sudo ss -lntup ``` Bedeutung wichtiger Optionen: | Option | Bedeutung | |---|---| | `-l` | Nur lauschende beziehungsweise unverbundene Server-Sockets | | `-n` | Adressen und Ports numerisch ausgeben | | `-t` | TCP-Sockets | | `-u` | UDP-Sockets | | `-p` | Zugehörige Prozesse anzeigen | | `-4` | Nur IPv4 | | `-6` | Nur IPv6 | **Nur IPv4-TCP-Listener:** ```bash [RO] ss -4 -lnt ``` **Nur IPv6-TCP-Listener:** ```bash [RO] ss -6 -lnt ``` > Ohne ausreichende Berechtigungen können Prozessname und PID in der Ausgabe fehlen.
---
8. Bestimmten Port oder Prozess unter Linux prüfen **Bestimmten TCP-Listener prüfen:** ```bash [RO][PRIV] sudo ss -lntp "sport = :" ``` **Bestimmten UDP-Port prüfen:** ```bash [RO][PRIV] sudo ss -lnup "sport = :" ``` **Offene Netzwerkressourcen einer PID anzeigen:** ```bash [RO][SENS][PRIV] sudo lsof -nP -a -p -i ``` **TCP-Listener einer PID anzeigen:** ```bash [RO][SENS][PRIV] sudo lsof \ -nP \ -a \ -p \ -iTCP \ -sTCP:LISTEN ``` **Bestimmten TCP-Port mit `lsof` prüfen:** ```bash [RO][PRIV] sudo lsof -nP -iTCP: -sTCP:LISTEN ``` **Bestimmten UDP-Port mit `lsof` prüfen:** ```bash [RO][PRIV] sudo lsof -nP -iUDP: ``` > `lsof` ist nicht auf jeder minimalen Linux-Installation vorhanden. In diesem Fall kann zunächst `ss` verwendet werden.
---
9. Listener unter macOS anzeigen **Alle TCP-Listener anzeigen:** ```bash [RO][PRIV] sudo lsof -nP -iTCP -sTCP:LISTEN ``` **Bestimmten TCP-Port prüfen:** ```bash [RO][PRIV] sudo lsof -nP -iTCP: -sTCP:LISTEN ``` **Gebundene UDP-Sockets anzeigen:** ```bash [RO][PRIV] sudo lsof -nP -iUDP ``` **Bestimmten UDP-Port prüfen:** ```bash [RO][PRIV] sudo lsof -nP -iUDP: ``` **Netzwerksockets einer bestimmten PID anzeigen:** ```bash [RO][SENS][PRIV] sudo lsof -nP -a -p -i ``` **TCP-Verbindungen und Listener mit `netstat` anzeigen:** ```bash [RO] netstat -anv -p tcp ``` **UDP-Sockets mit `netstat` anzeigen:** ```bash [RO] netstat -anv -p udp ``` > Unter macOS ist `lsof` für die Zuordnung von Netzwerkendpunkten zu Prozessen meist übersichtlicher als `netstat`.
---
10. Ausgabe von ss, lsof und netstat lesen Beispiel eines TCP-Listeners: ```text LISTEN 0 128 0.0.0.0:443 0.0.0.0:* ``` Interpretation: | Feld | Bedeutung | |---|---| | `LISTEN` | Socket nimmt neue TCP-Verbindungen an | | `0.0.0.0:443` | Bindung an TCP-Port 443 auf allen lokalen IPv4-Adressen | | `0.0.0.0:*` | Noch keine bestimmte entfernte Gegenstelle | | `0` | Je nach Werkzeug aktueller Warteschlangenwert | | `128` | Je nach Werkzeug Warteschlangen- oder Grenzwert | Beispiel einer aufgebauten Verbindung: ```text 192.0.2.20:443 192.0.2.50:53124 ESTABLISHED ``` Interpretation: ```text Lokaler Serverendpunkt: 192.0.2.20:443 Entfernter Client: 192.0.2.50:53124 Zustand: Verbindung aufgebaut ``` > Bei der Auswertung muss zuerst bestimmt werden, welches System Client und welches System Server ist. Ein hoher temporärer Port gehört häufig zum Client.
---
11. IPv4 und IPv6 getrennt prüfen Ein Dienst kann: - nur auf IPv4 lauschen, - nur auf IPv6 lauschen, - getrennte IPv4- und IPv6-Sockets verwenden, - einen IPv6-Wildcard-Socket verwenden, - abhängig vom Betriebssystem IPv4-Verbindungen über einen IPv6-Socket annehmen. **Windows – IPv4-Listener eines Ports:** ```powershell [RO] Get-NetTCPConnection -State Listen -LocalPort | Where-Object LocalAddress -NotLike "*:*" ``` **Windows – IPv6-Listener eines Ports:** ```powershell [RO] Get-NetTCPConnection -State Listen -LocalPort | Where-Object LocalAddress -Like "*:*" ``` **Linux – IPv4 prüfen:** ```bash [RO][PRIV] sudo ss -4 -lntp "sport = :" ``` **Linux – IPv6 prüfen:** ```bash [RO][PRIV] sudo ss -6 -lntp "sport = :" ``` **macOS – IPv4 prüfen:** ```bash [RO][PRIV] sudo lsof -nP -i4TCP: -sTCP:LISTEN ``` **macOS – IPv6 prüfen:** ```bash [RO][PRIV] sudo lsof -nP -i6TCP: -sTCP:LISTEN ``` > Aus einer Bindung an `[::]:` darf nicht ungeprüft geschlossen werden, dass IPv4 ebenfalls funktioniert. IPv4 und IPv6 müssen praktisch getrennt getestet werden.
---
12. Lokalen TCP-Porttest durchführen Ein lokaler Test hilft zu unterscheiden, ob der Dienst grundsätzlich Verbindungen annimmt oder ob nur der externe Zugriff fehlschlägt. **Windows – IPv4-Loopback testen:** ```powershell [TEST] Test-NetConnection 127.0.0.1 -Port ``` **Windows – konkrete Serveradresse testen:** ```powershell [TEST] Test-NetConnection -Port ``` **Linux – IPv4-Loopback testen:** ```bash [TEST] nc -vz -w 3 127.0.0.1 ``` **Linux – konkrete Serveradresse testen:** ```bash [TEST] nc -vz -w 3 ``` **macOS – IPv4-Loopback testen:** ```bash [TEST] nc -vz -w 3 127.0.0.1 ``` **macOS – konkrete Serveradresse testen:** ```bash [TEST] nc -vz -w 3 ``` **IPv6-Loopback unter Linux oder macOS testen:** ```bash [TEST] nc -6 -vz -w 3 ::1 ``` **Interpretation:** | Loopback | Server-IP | Mögliche Bewertung | |---|---|---| | Erfolgreich | Erfolgreich | Lokaler Listener grundsätzlich erreichbar | | Erfolgreich | Fehlgeschlagen | Falsche Bindung oder lokaler Paketfilter möglich | | Fehlgeschlagen | Erfolgreich | Dienst lauscht möglicherweise nur auf einer konkreten Adresse | | Fehlgeschlagen | Fehlgeschlagen | Kein Listener, falscher Port oder Paketfilter | | Erfolgreich | Extern fehlgeschlagen | Externe Firewall, Routing oder Netzpfad untersuchen | > Ein erfolgreicher TCP-Porttest beweist nur, dass ein TCP-Verbindungsaufbau möglich war. Er beweist nicht, dass die Anwendung fachlich korrekt antwortet.
---
13. TCP-Port von einem entfernten Client testen Der Test sollte aus dem tatsächlich betroffenen Netzwerk oder von einem vergleichbaren Client erfolgen. | Betriebssystem | Befehl | |---|---| | Windows | `[TEST] Test-NetConnection -Port ` | | Linux | `[TEST] nc -vz -w 3 ` | | macOS | `[TEST] nc -vz -w 3 ` | **Windows mit ausführlicher Ausgabe:** ```powershell [TEST] Test-NetConnection -Port -InformationLevel Detailed ``` Wichtige Ausgabe: ```text ComputerName RemoteAddress RemotePort InterfaceAlias SourceAddress TcpTestSucceeded ``` **Prüffragen:** - Wurde der erwartete Servername verwendet? - Wurde der Name zur erwarteten IP-Adresse aufgelöst? - Verwendet der Test die erwartete Quelladresse? - Erfolgt der Test über das vorgesehene Netzwerkinterface? - Ist der Port nur aus bestimmten Netzen erreichbar? - Wird IPv4 oder IPv6 verwendet? - Besteht zwischen Client und Server ein Proxy, VPN oder Loadbalancer?
---
14. UDP-Porttests vorsichtig bewerten **Linux oder macOS:** ```bash [TEST] nc -vzu -w 3 ``` Ein solcher Test kann jedoch häufig nicht zuverlässig bestätigen, dass: - ein UDP-Dienst tatsächlich antwortet, - die Anwendung die Testdaten verstanden hat, - eine Firewall die Pakete verworfen hat, - die Rückantwort den Client erreicht, - der Dienst fachlich funktioniert. **Bessere UDP-Prüfung:** | Dienst | Geeigneter protokollspezifischer Test | |---|---| | DNS | `dig` oder `nslookup` | | NTP | `ntpq`, `chronyc` oder geeigneter NTP-Client | | DHCP | Kontrollierter DHCP-Test im vorgesehenen Netz | | SNMP | `snmpget` mit autorisierten Zugangsdaten | | TFTP | Kontrollierter TFTP-Clienttest | | Syslog | Testnachricht und serverseitige Protokollkontrolle | > Bei UDP ist ein protokollspezifischer Funktionstest wesentlich aussagekräftiger als ein allgemeiner Portscan.
---
15. Lokal erreichbar, von außen nicht erreichbar Wenn ein lokaler Porttest erfolgreich ist, ein entfernter Test aber fehlschlägt, kommen unter anderem folgende Ursachen infrage: - Dienst bindet nur an Loopback, - Dienst bindet an die falsche Netzwerkschnittstelle, - lokale Hostfirewall blockiert externe Quellen, - Netzwerkfirewall blockiert den Zielport, - Routing zum Server oder zurück zum Client fehlt, - falsches VLAN wird verwendet, - Zugriff erfolgt über falsche IP-Adresse, - IPv4 und IPv6 werden verwechselt, - NAT- oder Portweiterleitung ist fehlerhaft, - Sicherheitsgruppe oder Cloud-Firewall blockiert, - Reverse Proxy oder Loadbalancer leitet nicht weiter, - VPN-Richtlinie erlaubt das Zielnetz nicht, - Dienst akzeptiert nur bestimmte Quelladressen. **Diagnosereihenfolge:** ```text 1. Listener und Bindungsadresse prüfen 2. Lokalen Test über Loopback durchführen 3. Lokalen Test über die Server-IP durchführen 4. Test aus demselben Subnetz durchführen 5. Test aus dem betroffenen Clientnetz durchführen 6. Hostfirewall prüfen 7. Netzwerkpfad und Zwischenfirewalls prüfen 8. Paketmitschnitt auf Client und Server erwägen ```
---
16. Portkonflikte erkennen Ein Portkonflikt entsteht, wenn ein Prozess eine Adresse-Port-Kombination verwenden möchte, die bereits unvereinbar belegt ist. Typische Fehlermeldungen: ```text Address already in use Only one usage of each socket address is normally permitted Failed to bind Bind failed EADDRINUSE Port is already allocated ``` **Windows:** ```powershell [RO] Get-NetTCPConnection -State Listen -LocalPort | Select-Object LocalAddress, LocalPort, OwningProcess ``` ```powershell [RO] Get-NetUDPEndpoint -LocalPort | Select-Object LocalAddress, LocalPort, OwningProcess ``` **Linux:** ```bash [RO][PRIV] sudo ss -lntup "sport = :" ``` **macOS – TCP:** ```bash [RO][PRIV] sudo lsof -nP -iTCP: -sTCP:LISTEN ``` **macOS – UDP:** ```bash [RO][PRIV] sudo lsof -nP -iUDP: ``` **Prüffragen bei einem Konflikt:** - Welcher Prozess besitzt den Port? - Gehört der Prozess zum erwarteten Dienst? - Verwendet er eine Wildcard- oder Einzeladressbindung? - Wurde eine zweite Dienstinstanz gestartet? - Wurde der Port nach einer Aktualisierung verändert? - Läuft ein alter Prozess weiter? - Wird der Port durch einen Container oder Proxy veröffentlicht? - Unterstützt die Anwendung mehrere Prozesse mit gemeinsamem Listener? - Ist die Mehrfachbindung durch Socketoptionen ausdrücklich vorgesehen? > Einen unbekannten Prozess nicht allein deshalb beenden, weil er den gewünschten Port verwendet. Zuerst müssen Prozess, Dienst und betriebliche Funktion eindeutig zugeordnet werden.
---
17. Wichtige TCP-Zustände einordnen | Zustand | Bedeutung | Mögliche Diagnose | |---|---|---| | `LISTEN` | Server wartet auf neue Verbindungen | Listener vorhanden | | `SYN_SENT` | Lokales System versucht eine Verbindung aufzubauen | Rückantwort fehlt oder Ziel nicht erreichbar | | `SYN_RECEIVED` | Verbindungsanfrage empfangen, Handshake noch nicht abgeschlossen | Clientantwort fehlt oder Warteschlange belastet | | `ESTABLISHED` | TCP-Verbindung vollständig aufgebaut | Transportverbindung vorhanden | | `FIN_WAIT_1` | Lokales System hat Beendigung eingeleitet | Normal während Verbindungsabbau | | `FIN_WAIT_2` | Bestätigung erhalten, Abschluss der Gegenseite fehlt | Bei großer dauerhafter Anzahl untersuchen | | `CLOSE_WAIT` | Gegenseite hat beendet, lokale Anwendung noch nicht | Große dauerhafte Anzahl kann auf Anwendungsfehler hinweisen | | `LAST_ACK` | Lokale Anwendung beendet, letzte Bestätigung steht aus | Normal kurzzeitig | | `TIME_WAIT` | Verbindung wird nach Beendigung vorübergehend vorgehalten | Häufig normal | | `CLOSED` | Socket ist nicht aktiv | Keine Verbindung | | `CLOSING` | Beide Seiten beenden nahezu gleichzeitig | Normal kurzzeitig | > Einzelne Verbindungen in `TIME_WAIT` oder `CLOSE_WAIT` sind noch kein Fehler. Auffällig sind große oder kontinuierlich wachsende Bestände über einen längeren Zeitraum.
---
18. Aufgebaute Verbindungen eines Dienstes prüfen **Windows – Verbindungen einer PID:** ```powershell [RO] Get-NetTCPConnection -OwningProcess | Select-Object LocalAddress, LocalPort, RemoteAddress, RemotePort, State ``` **Linux – alle TCP-Verbindungen einer PID über lsof:** ```bash [RO][SENS][PRIV] sudo lsof -nP -a -p -iTCP ``` **macOS – alle TCP-Verbindungen einer PID:** ```bash [RO][SENS][PRIV] sudo lsof -nP -a -p -iTCP ``` Damit können unter anderem folgende Fragen beantwortet werden: - Nimmt der Dienst Clientverbindungen an? - Baut der Dienst Verbindungen zu einer Datenbank auf? - Verbindet er sich mit einem Verzeichnisdienst? - Greift er auf einen Proxy oder eine externe API zu? - Bleiben ungewöhnlich viele Verbindungen in `CLOSE_WAIT`? - Verwendet der Prozess den erwarteten Zielport? - Baut er Verbindungen zu einer unerwarteten Adresse auf? > Remoteadressen, interne Servernamen und Verbindungsziele können sensible Infrastrukturinformationen darstellen.
---
19. Container und vorgeschaltete Dienste berücksichtigen Bei containerisierten oder weitergeleiteten Anwendungen können mehrere Portebenen vorhanden sein. ```text Client → Hostadresse: veröffentlichter Port → Firewall oder Proxy → Containeradresse: interner Port → Anwendungsprozess ``` **Beispiel:** ```text Host: 192.0.2.20:8443 Container: 172.18.0.5:443 Anwendung: 0.0.0.0:443 im Container ``` Prüfungen müssen deshalb unterscheiden zwischen: - Listener auf dem Host, - veröffentlichtem Containerport, - internem Containerport, - Listener innerhalb des Containers, - Reverse-Proxy-Listener, - Backend-Verbindung des Proxys, - Host- und Containerfirewall, - Container-Netzwerk und DNS. **Typische Fehler:** - Port wurde nicht veröffentlicht, - Hostport und Containerport wurden vertauscht, - Anwendung lauscht im Container nur auf `127.0.0.1`, - Reverse Proxy verwendet falschen Backendport, - zwei Container beanspruchen denselben Hostport, - Container wurde neu erstellt und erhielt eine andere interne Adresse, - Anwendung startet später als der vorgeschaltete Proxy, - Dienst lauscht nur auf IPv6 oder nur auf IPv4. > Die allgemeine Socketprüfung bleibt gleich, muss aber in jedem relevanten Netzwerk-Namespace beziehungsweise auf jeder Weiterleitungsstufe wiederholt werden.
---
20. Typische Fehlerbilder systematisch bewerten | Beobachtung | Mögliche Ursache | Nächster Schritt | |---|---|---| | Dienst läuft, aber kein Listener vorhanden | Start unvollständig, falsche Konfiguration oder interner Fehler | Dienstprotokoll und Startparameter prüfen | | Falscher Prozess besitzt den Port | Portkonflikt oder falsche Dienstinstanz | Prozess und Änderungshistorie untersuchen | | Listener nur auf `127.0.0.1` | Dienst nur für lokale Nutzung konfiguriert | Sollkonfiguration und Proxy-Aufbau prüfen | | Listener nur auf einer Server-IP | Bindung an falsche oder alte Adresse | Netzwerkkonfiguration und Dienstkonfiguration prüfen | | Listener nur auf IPv4 | IPv6-Clients erreichen den Dienst nicht | Sollzustand und IPv6-Konfiguration prüfen | | Listener nur auf IPv6 | IPv4-Zugriff möglicherweise nicht verfügbar | IPv4 getrennt testen | | Lokaler Test erfolgreich, entfernter Test fehlerhaft | Firewall, Routing oder falsche Bindung | Netzwerkpfad schrittweise prüfen | | TCP-Verbindung erfolgreich, Anwendung fehlerhaft | Protokoll-, TLS-, Backend- oder Berechtigungsproblem | Anwendungsspezifischen Test durchführen | | Viele `CLOSE_WAIT`-Verbindungen | Anwendung schließt Sockets möglicherweise nicht | Prozess- und Anwendungscode beziehungsweise Herstellerhinweise prüfen | | Viele `SYN_RECEIVED`-Verbindungen | Handshakes bleiben unvollständig | Last, Netzwerk, Filter und mögliche Angriffe prüfen | | UDP-Endpunkt vorhanden, Test ohne Antwort | Test möglicherweise nicht protokollgerecht | Protokollspezifischen Test verwenden | | Port wechselt nach jedem Start | Dynamische Portkonfiguration oder fehlerhafte Vorgabe | Effektive Konfiguration prüfen |
---
21. Typische Fehlinterpretationen | Fehlinterpretation | Richtige Bewertung | |---|---| | „Der Dienst läuft, also ist der Port offen.“ | Der Prozess muss tatsächlich einen Socket gebunden haben | | „Port offen bedeutet Anwendung funktioniert.“ | Nur der Transportverbindungsaufbau wurde bestätigt | | „`0.0.0.0` bedeutet Zugriff aus dem gesamten Internet.“ | Es bedeutet alle lokalen IPv4-Adressen; Netzwerkfilter gelten weiterhin | | „`127.0.0.1` ist die Server-IP für Clients.“ | Loopback ist nur auf dem jeweiligen System erreichbar | | „UDP hat ebenfalls einen `LISTEN`-Zustand.“ | UDP verwendet keinen TCP-ähnlichen Listenerzustand | | „Ein fehlgeschlagener UDP-Test beweist einen geschlossenen Port.“ | Ohne Protokollantwort ist das Ergebnis oft nicht eindeutig | | „`[::]` beweist gleichzeitig IPv4-Erreichbarkeit.“ | IPv4 muss separat getestet werden | | „Jeder hohe Clientport ist ein unbekannter Serverdienst.“ | Temporäre Clientports sind normal | | „Viele `TIME_WAIT`-Einträge bedeuten automatisch einen Fehler.“ | Der Zustand ist Bestandteil des normalen TCP-Abbaus | | „Ein Portkonflikt darf durch sofortiges Beenden gelöst werden.“ | Der besitzende Prozess muss zuerst eindeutig identifiziert werden |
---
22. Checkliste zur Listener- und Portprüfung ```text [ ] Erwartetes Protokoll bestimmt [ ] Erwarteten Port bestimmt [ ] Erwartete Bindungsadresse bestimmt [ ] IPv4 und IPv6 berücksichtigt [ ] Dienststatus geprüft [ ] Prozess und aktuelle PID geprüft [ ] TCP-Listener beziehungsweise UDP-Endpunkt gesucht [ ] Port dem richtigen Prozess zugeordnet [ ] Loopback-Bindung ausgeschlossen oder als vorgesehen bestätigt [ ] Wildcard- oder Einzeladressbindung bewertet [ ] Lokalen Test über Loopback durchgeführt [ ] Lokalen Test über die Serveradresse durchgeführt [ ] Test aus dem betroffenen Clientnetz durchgeführt [ ] Aufgelöste Zieladresse kontrolliert [ ] TCP-Verbindungszustände geprüft [ ] Portkonflikt ausgeschlossen [ ] Proxy-, Loadbalancer- oder Containerstufe berücksichtigt [ ] UDP nur mit geeignetem Protokolltest bewertet [ ] Noch keine ungeprüfte Prozessbeendigung durchgeführt [ ] Nächsten Diagnoseschritt dokumentiert ```
--- **Bewertung des Ergebnisses** | Ergebnis | Nächster Schritt | |---|---| | Kein Listener vorhanden | Dienststart, Konfiguration und Protokolle untersuchen | | Falscher Prozess besitzt den Port | Portkonflikt und Prozessursprung untersuchen | | Listener verwendet falschen Port | Effektive Dienstkonfiguration prüfen | | Listener bindet an falsche Adresse | Netzwerkschnittstellen und Bindungskonfiguration prüfen | | Nur Loopback ist gebunden | Vorgesehenen Proxy oder externe Bindung prüfen | | Lokaler Test funktioniert | Externen Netzwerkpfad prüfen | | Entfernter TCP-Test scheitert | Firewall, Routing, NAT und Zwischenkomponenten prüfen | | TCP-Test funktioniert | TLS und Anwendungsprotokoll prüfen | | Viele problematische TCP-Zustände | Anwendung, Last und Gegenstellen untersuchen | | UDP-Ergebnis ist unklar | Protokollspezifischen Funktionstest durchführen | --- **Merksatz** > **Ein laufender Prozess ohne Listener ist nicht erreichbar. Ein Listener ohne erfolgreichen Porttest ist nicht nachgewiesen erreichbar. Ein erfolgreicher Porttest ohne Anwendungstest beweist noch keine funktionierende Anwendung.** --- **Weiterführende Quellen** - [Microsoft Learn – Get-NetTCPConnection](https://learn.microsoft.com/powershell/module/nettcpip/get-nettcpconnection) - [Microsoft Learn – Get-NetUDPEndpoint](https://learn.microsoft.com/powershell/module/nettcpip/get-netudpendpoint) - [Microsoft Learn – Test-NetConnection](https://learn.microsoft.com/powershell/module/nettcpip/test-netconnection) - [Microsoft Learn – netstat](https://learn.microsoft.com/windows-server/administration/windows-commands/netstat) - [Linux-Handbuch – ss](https://man7.org/linux/man-pages/man8/ss.8.html) - [Linux-Handbuch – socket](https://man7.org/linux/man-pages/man7/socket.7.html) - [Linux-Handbuch – tcp](https://man7.org/linux/man-pages/man7/tcp.7.html) - [Linux-Handbuch – udp](https://man7.org/linux/man-pages/man7/udp.7.html) - [Apple – lsof-Handbuchseite](https://keith.github.io/xcode-man-pages/lsof.8.html) - [Apple – netstat-Handbuchseite](https://keith.github.io/xcode-man-pages/netstat.1.html) - [Apple – TCP-Handbuchseite](https://keith.github.io/xcode-man-pages/tcp.4.html) - [Apple – listen-Handbuchseite](https://keith.github.io/xcode-man-pages/listen.2.html) # 4.5 Dienstabhängigkeiten untersuchen* Ein Dienst kann korrekt gestartet sein und trotzdem nicht funktionieren, wenn eine benötigte Abhängigkeit fehlt oder fehlerhaft arbeitet. Solche Abhängigkeiten können vom Betriebssystem ausdrücklich konfiguriert oder nur innerhalb der Anwendung hinterlegt sein. > **Grundsatz:** > Ein abhängiger Dienst kann nur so zuverlässig funktionieren wie die gesamte Kette seiner benötigten Komponenten. --- **Ziele dieser Seite** Nach dieser Seite sollst du: - formale und versteckte Dienstabhängigkeiten unterscheiden können, - erforderliche und optionale Abhängigkeiten erkennen können, - Startreihenfolge und echte Abhängigkeit auseinanderhalten können, - vorwärts und rückwärts gerichtete Abhängigkeiten ermitteln können, - DNS-, Netzwerk-, Speicher-, Datenbank- und Authentifizierungsabhängigkeiten prüfen können, - Fehler entlang einer Dienstkette eingrenzen können, - gemeinsame Abhängigkeiten bei mehreren gestörten Diensten erkennen können, - Auswirkungen eines Dienstneustarts auf abhängige Systeme bewerten können. ---
1. Formale und funktionale Abhängigkeiten unterscheiden | Art | Beschreibung | Beispiel | |---|---|---| | Formale Dienstabhängigkeit | In der Betriebssystem-Dienstverwaltung eingetragen | Webdienst benötigt einen lokalen Datenbankdienst | | Startreihenfolge | Legt fest, was vorher oder nachher gestartet wird | Anwendung startet nach dem Netzwerkziel | | Netzwerkabhängigkeit | Externes System muss über das Netzwerk erreichbar sein | Anwendung verbindet sich mit Datenbankserver | | Namensauflösung | Dienst benötigt funktionierendes DNS | Backend wird über Hostnamen angesprochen | | Speicherabhängigkeit | Lokales oder entferntes Dateisystem muss verfügbar sein | Anwendung benötigt SMB- oder NFS-Freigabe | | Authentifizierungsabhängigkeit | Identitätsdienst wird benötigt | Anmeldung über Active Directory oder LDAP | | Zertifikatsabhängigkeit | Vertrauenskette und Gültigkeit müssen stimmen | TLS-Verbindung zu einer API | | Zeitabhängigkeit | Systemuhren müssen ausreichend synchron sein | Kerberos oder Zertifikatsprüfung | | Ressourcenabhängigkeit | CPU, RAM, Speicherplatz oder Dateideskriptoren werden benötigt | Datenbank kann keine Dateien mehr schreiben | | Anwendungsabhängigkeit | Andere Anwendung oder API muss funktionieren | Warenwirtschaft greift auf Zahlungsdienst zu | | Konfigurationsabhängigkeit | Datei, Variable oder Secret muss vorhanden sein | Datenbank-URL aus Umgebungsvariable | | Infrastrukturabhängigkeit | Plattformkomponente stellt Laufzeit bereit | Container-Runtime, Hypervisor oder Cluster | > Betriebssystemwerkzeuge zeigen normalerweise nur die formal registrierten Abhängigkeiten. Externe Datenbanken, DNS-Server, APIs oder Netzwerkspeicher erscheinen dort häufig nicht.
---
2. Eine Dienstkette darstellen Eine Anwendung kann beispielsweise folgende Kette besitzen: ```text Benutzer → Client → DNS → Netzwerk und Firewall → Loadbalancer → Reverse Proxy → Webserver → Anwendungsdienst → Datenbank → Verzeichnisdienst → Netzwerkspeicher → externe API ``` Für jede Verbindung sollten folgende Informationen erfasst werden: | Eigenschaft | Beispiel | |---|---| | Quellsystem | Anwendungsserver | | Zielsystem | Datenbankserver | | Zielname | `srv-db01.example.local` | | Zielport | TCP 5432 | | Protokoll | PostgreSQL | | Authentifizierung | Dienstkonto | | Verschlüsselung | TLS | | Zeitüberschreitung | 10 Sekunden | | Kritikalität | Erforderlich | | Verhalten bei Ausfall | Anmeldung nicht möglich | | Überwachung | TCP- und Datenbankabfrage | | Verantwortlichkeit | Datenbankbetrieb | **Praktische Dokumentationsform:** | Quelle | Abhängigkeit | Ziel | Port/Protokoll | Kritisch | Nachweis | |---|---|---|---|---:|---| | Webserver | Namensauflösung | DNS-Server | UDP/TCP 53 | Ja | DNS-Abfrage | | Webserver | Anwendung | App-Server | TCP 8443 | Ja | HTTPS-Test | | App-Server | Datenbank | DB-Server | TCP 5432 | Ja | Datenbankabfrage | | App-Server | Anmeldung | LDAP-Server | TCP 636 | Ja | LDAPS-Test | | App-Server | Dateispeicher | Fileserver | SMB 445 | Nein | Freigabetest |
---
3. Erforderliche und optionale Abhängigkeiten unterscheiden | Abhängigkeitstyp | Verhalten bei Ausfall | |---|---| | Zwingend erforderlich | Dienst kann nicht starten oder Hauptfunktion fällt aus | | Optional | Nur Zusatzfunktion fällt aus | | Bedingt erforderlich | Nur bestimmte Benutzer oder Vorgänge sind betroffen | | Redundant | Andere Instanz kann übernehmen | | Zwischengespeichert | Funktioniert vorübergehend mit vorhandenen Cache-Daten | | Asynchron | Anfragen werden zunächst in eine Warteschlange geschrieben | | Startabhängig | Nur während des Starts erforderlich | | Laufzeitabhängig | Während des gesamten Betriebs erforderlich | | Verwaltungsabhängig | Nur für Administration oder Monitoring erforderlich | **Beispiele:** - Eine Webanwendung kann ihre Startseite ohne Datenbank ausliefern, aber keine Benutzer anmelden. - Ein Maildienst kann Nachrichten zwischenspeichern, obwohl das Zielsystem vorübergehend nicht erreichbar ist. - Ein Cluster kann beim Ausfall einer Instanz weiterarbeiten. - Ein Dienst kann starten, obwohl ein optionales Monitoring-Backend fehlt. - Eine Anwendung kann nach dem Start weiterarbeiten, obwohl der Konfigurationsdienst später ausfällt. > Der Ausfall einer Abhängigkeit führt nicht immer zum vollständigen Dienststillstand. Teilfunktionen und verzögerte Fehler müssen deshalb ausdrücklich geprüft werden.
---
4. Windows-Dienstabhängigkeiten mit PowerShell prüfen `` muss durch den internen Dienstnamen ersetzt werden. **Dienst und erforderliche Systemdienste anzeigen:** ```powershell [RO] Get-Service -Name "" -RequiredServices ``` **Nur die erforderlichen Dienste übersichtlich anzeigen:** ```powershell [RO] (Get-Service -Name "").ServicesDependedOn | Select-Object Name, DisplayName, Status ``` **Dienste anzeigen, die vom untersuchten Dienst abhängen:** ```powershell [RO] Get-Service -Name "" -DependentServices ``` **Abhängige Dienste übersichtlich anzeigen:** ```powershell [RO] (Get-Service -Name "").DependentServices | Select-Object Name, DisplayName, Status ``` **Dienst und beide Abhängigkeitsrichtungen erfassen:** ```powershell [RO] $service = Get-Service -Name "" $service | Select-Object Name, DisplayName, Status "Benötigte Dienste:" $service.ServicesDependedOn | Select-Object Name, DisplayName, Status "Abhängige Dienste:" $service.DependentServices | Select-Object Name, DisplayName, Status ``` **Wichtig:** - `ServicesDependedOn` zeigt Dienste, die der untersuchte Dienst benötigt. - `DependentServices` zeigt Dienste, die den untersuchten Dienst benötigen. - Beide Richtungen sind vor einem Stopp oder Neustart relevant. - Nicht jede funktionale Anwendungsabhängigkeit ist beim Service Control Manager registriert.
---
5. Windows-Dienstabhängigkeiten mit sc.exe prüfen **Konfiguration einschließlich eingetragener Abhängigkeiten anzeigen:** ```powershell [RO][SENS] sc.exe qc "" ``` Relevant ist insbesondere der Abschnitt: ```text DEPENDENCIES ``` **Direkt abhängige Dienste anzeigen:** ```powershell [RO] sc.exe enumdepend "" ``` **Erweiterte Dienstinformationen anzeigen:** ```powershell [RO] sc.exe queryex "" ``` **Interpretation:** | Abfrage | Richtung | |---|---| | `sc.exe qc` → `DEPENDENCIES` | Welche Dienste benötigt der untersuchte Dienst? | | `sc.exe enumdepend` | Welche Dienste hängen vom untersuchten Dienst ab? | > `sc.exe qc` kann Programmpfade, Dienstkonten und interne Konfigurationsinformationen anzeigen. Die Ausgabe sollte deshalb als potenziell sensibel behandelt werden.
---
6. Zustand aller formalen Windows-Abhängigkeiten prüfen **Benötigte Dienste samt Startart und Konto untersuchen:** ```powershell [RO] $requiredServices = (Get-Service -Name "").ServicesDependedOn foreach ($requiredService in $requiredServices) { Get-CimInstance Win32_Service ` -Filter "Name='$($requiredService.Name)'" | Select-Object Name, DisplayName, State, StartMode, StartName, ProcessId, ExitCode } ``` **Mögliche Auffälligkeiten:** - erforderlicher Dienst ist beendet, - erforderlicher Dienst ist deaktiviert, - Dienst hängt in `StartPending`, - Dienst läuft unter einem falschen Konto, - Dienstprozess besitzt keine PID, - Exitcode ist ungleich null, - benötigter Dienst wird wiederholt neu gestartet, - Abhängigkeitsdefinition enthält einen nicht mehr vorhandenen Dienst. > Ein laufender erforderlicher Dienst kann trotzdem funktional gestört sein. Nach dem Status müssen Listener, Protokoll und tatsächliche Funktion geprüft werden.
---
7. Abhängigkeiten unter Linux mit systemd anzeigen **Direkte und indirekte Abhängigkeiten anzeigen:** ```bash [RO] systemctl list-dependencies "" --no-pager ``` **Nur unmittelbare Abhängigkeiten anzeigen:** ```bash [RO] systemctl list-dependencies \ --plain \ --no-pager \ "" ``` **Rückwärts gerichtete Abhängigkeiten anzeigen:** ```bash [RO] systemctl list-dependencies \ --reverse \ --no-pager \ "" ``` **Abhängigkeiten und Reihenfolgenbeziehungen strukturiert anzeigen:** ```bash [RO] systemctl show "" \ --property=Requires,Wants,Requisite,BindsTo,PartOf,After,Before,Conflicts ``` **Wirksame Unit-Konfiguration anzeigen:** ```bash [RO][FILE][SENS] systemctl cat "" ``` **Status abhängiger Units prüfen:** ```bash [RO] systemctl --failed --no-pager ``` > `systemctl list-dependencies` zeigt systemd-Units. Eine in der Anwendung konfigurierte Datenbank oder API wird nur dann sichtbar, wenn dafür ausdrücklich eine systemd-Beziehung definiert wurde.
---
8. systemd-Beziehungen richtig interpretieren | Direktive | Grundbedeutung | |---|---| | `Requires=` | Starke Anforderungsbeziehung zu einer anderen Unit | | `Wants=` | Schwächere Anforderungsbeziehung | | `Requisite=` | Andere Unit muss bereits aktiv sein; sie wird dadurch nicht automatisch gestartet | | `BindsTo=` | Engere Bindung an den Aktivzustand einer anderen Unit | | `PartOf=` | Bestimmte Stop- und Neustartaktionen werden weitergegeben | | `After=` | Diese Unit wird nach der genannten Unit gestartet | | `Before=` | Diese Unit wird vor der genannten Unit gestartet | | `Conflicts=` | Units sollen nicht gleichzeitig aktiv sein | | `OnFailure=` | Andere Unit wird bei einem Fehlschlag aktiviert | **Besonders wichtig:** ```text Requires= ist nicht dasselbe wie After= Wants= ist nicht dasselbe wie After= After= legt Reihenfolge fest, aber keine zwingende Anforderung Before= legt Reihenfolge fest, aber keine zwingende Anforderung ``` **Beispiel:** ```ini [Unit] Requires=postgresql.service After=network-online.target postgresql.service ``` Mögliche Interpretation: - Der Dienst besitzt eine starke Anforderung an `postgresql.service`. - Er soll nach `postgresql.service` gestartet werden. - Er soll außerdem nach `network-online.target` gestartet werden. - Das Erreichen von `network-online.target` beweist nicht, dass eine bestimmte entfernte Datenbank tatsächlich erreichbar ist. > Für eine zuverlässige Bewertung müssen Anforderungs- und Reihenfolgedirektiven gemeinsam betrachtet werden.
---
9. Abhängigkeitsbaum unter systemd in beide Richtungen lesen **Vorwärts gerichtete Frage:** > Was benötigt dieser Dienst? ```bash [RO] systemctl list-dependencies "" --no-pager ``` **Rückwärts gerichtete Frage:** > Welche Units benötigen diesen Dienst? ```bash [RO] systemctl list-dependencies \ --reverse \ --no-pager \ "" ``` **Nur Abhängigkeiten vor einem Neustart prüfen:** ```bash [RO] systemctl show "" \ --property=RequiredBy,WantedBy,ConsistsOf,PartOf ``` **Bewertung vor einer Maßnahme:** | Feststellung | Bedeutung | |---|---| | Viele rückwärtige Abhängigkeiten | Neustart kann mehrere Dienste beeinflussen | | `PartOf=` vorhanden | Neustart- oder Stoppaktionen können gekoppelt sein | | `BindsTo=` vorhanden | Ausfall kann abhängige Unit ebenfalls deaktivieren | | Gemeinsame Datenbankabhängigkeit | Datenbankfehler kann mehrere Anwendungen betreffen | | Gemeinsames Netzwerkmount | Speicherfehler kann mehrere Dienste blockieren | | Gemeinsames Target | Nicht jede aufgeführte Unit ist zwingend funktional abhängig |
---
10. Abhängigkeiten unter macOS mit launchd untersuchen launchd besitzt laut Apple kein allgemeines ausdrückliches Abhängigkeitsmodell wie systemd. Dienstinteraktionen sollen möglichst über bedarfsgesteuerte IPC-Mechanismen gelöst werden. Deshalb müssen mehrere Informationsquellen kombiniert werden. **Systemweiten Dienst anzeigen:** ```bash [RO] launchctl print "system/
---
11. Versteckte Anwendungsabhängigkeiten finden Funktionale Abhängigkeiten können an folgenden Stellen dokumentiert oder konfiguriert sein: - Herstellerdokumentation, - Architekturdiagramm, - Betriebshandbuch, - Konfigurationsdatei, - Umgebungsvariable, - Dienststartparameter, - Containerdefinition, - Reverse-Proxy-Konfiguration, - DNS-Eintrag, - Zertifikatskonfiguration, - Mount-Konfiguration, - Secret- oder Credential-Verwaltung, - Anwendungsprotokoll, - Überwachungssystem, - Quellcode oder Deploymentbeschreibung. **Typische Konfigurationsbegriffe:** ```text host hostname server endpoint url uri database db_host connection_string ldap smtp proxy upstream backend api mount share certificate key timeout retry ``` > Konfigurationsdateien und Umgebungsvariablen können Geheimnisse enthalten. Nicht wahllos nach Inhalten suchen oder vollständige Dateien in Tickets kopieren.
---
12. Aktive Netzwerkabhängigkeiten eines Prozesses erkennen Bereits aufgebaute Verbindungen können Hinweise auf verwendete Backends liefern. **Windows:** ```powershell [RO][SENS] Get-NetTCPConnection -OwningProcess | Select-Object LocalAddress, LocalPort, RemoteAddress, RemotePort, State ``` **Linux:** ```bash [RO][SENS][PRIV] sudo lsof -nP -a -p -i ``` **macOS:** ```bash [RO][SENS][PRIV] sudo lsof -nP -a -p -i ``` **Damit können Hinweise gefunden werden auf:** - Datenbankserver, - Authentifizierungsserver, - SMTP-Server, - Proxys, - externe APIs, - Clusterknoten, - Objekt- oder Netzwerkspeicher, - Monitoring- und Protokollserver. **Einschränkungen:** - Nur aktuell geöffnete Verbindungen sind sichtbar. - Kurzlebige Verbindungen können zwischen zwei Abfragen fehlen. - Ein Ziel kann über einen Proxy vermittelt werden. - IP-Adressen allein beweisen nicht die fachliche Funktion des Zielsystems. - UDP-Kommunikation ist schwieriger zu bewerten. - Eine aktuell fehlende Verbindung kann bei Leerlauf normal sein.
---
13. DNS-Abhängigkeit prüfen Wenn ein Dienst ein Backend über einen Namen anspricht, muss genau dieser Name aus dem Kontext des Dienstservers geprüft werden. | Aufgabe | Windows | Linux | macOS | |---|---|---|---| | A- und AAAA-Auflösung | `[TEST] Resolve-DnsName ""` | `[TEST] getent ahosts ""` | `[TEST] dscacheutil -q host -a name ""` | | DNS gezielt abfragen | `[TEST] Resolve-DnsName "" -Server ` | `[TEST] dig @ "" A` | `[TEST] dig @ "" A` | | IPv6-Adresse abfragen | `[TEST] Resolve-DnsName "" -Type AAAA` | `[TEST] dig "" AAAA` | `[TEST] dig "" AAAA` | **Zu prüfen:** - Wird der richtige Name verwendet? - Wird die erwartete IP-Adresse geliefert? - Existieren unerwartete alte Adressen? - Gibt es unterschiedliche Ergebnisse auf Client und Server? - Wird ein Suchsuffix benötigt? - Verwendet die Anwendung einen vollständig qualifizierten Namen? - Bevorzugt die Anwendung IPv6? - Ist der DNS-Server aus dem Dienstkontext erreichbar? - Wurde ein DNS-Eintrag kürzlich geändert? > Eine erfolgreiche DNS-Abfrage beweist nur die Namensauflösung. Der zurückgegebene Zielserver muss anschließend über das erforderliche Protokoll geprüft werden.
---
14. TCP-Abhängigkeit eines Backends prüfen **Windows:** ```powershell [TEST] Test-NetConnection "" -Port ``` **Linux:** ```bash [TEST] nc -vz -w 3 "" ``` **macOS:** ```bash [TEST] nc -vz -w 3 "" ``` **Mögliche Ergebnisse:** | Ergebnis | Bedeutung | |---|---| | Namensauflösung fehlerhaft | DNS-Abhängigkeit gestört | | Verbindung abgelehnt | Ziel erreichbar, aber kein passender Listener oder aktive Ablehnung | | Zeitüberschreitung | Filterung, Routingproblem oder nicht reagierendes Ziel möglich | | TCP-Verbindung erfolgreich | Transportweg bis zum Port funktioniert | | Anwendung antwortet trotzdem fehlerhaft | Protokoll, TLS, Anmeldung oder Backendfunktion prüfen | > Der Test muss vom tatsächlichen Anwendungsserver oder aus einem technisch gleichwertigen Netzwerkpfad erfolgen. Ein erfolgreicher Test vom Administrator-Client beweist nicht, dass der Dienstserver denselben Zugriff besitzt.
---
15. HTTP- oder API-Abhängigkeit prüfen **Nur Antwortheader eines HTTP- oder HTTPS-Endpunkts anfordern:** | Betriebssystem | Befehl | |---|---| | Windows | `[TEST][SENS] curl.exe -I --connect-timeout 5 "https:///"` | | Linux | `[TEST][SENS] curl -I --connect-timeout 5 "https:///"` | | macOS | `[TEST][SENS] curl -I --connect-timeout 5 "https:///"` | **Ausführliche TLS- und Verbindungsdiagnose:** | Betriebssystem | Befehl | |---|---| | Windows | `[TEST][SENS] curl.exe -v --connect-timeout 5 "https:///"` | | Linux | `[TEST][SENS] curl -v --connect-timeout 5 "https:///"` | | macOS | `[TEST][SENS] curl -v --connect-timeout 5 "https:///"` | **Zu prüfen:** - Wird die erwartete IP-Adresse verwendet? - Ist der TCP-Verbindungsaufbau erfolgreich? - Funktioniert der TLS-Handshake? - Passt der Zertifikatsname? - Welcher HTTP-Statuscode wird geliefert? - Antwortet der erwartete Server? - Erfolgt eine unerwartete Weiterleitung? - Ist eine Authentifizierung erforderlich? - Wie lange dauert die Antwort? > `-v` kann Header und andere sensible Informationen anzeigen. Zugangstoken oder Sitzungscookies dürfen nicht in die Befehlszeile oder Dokumentation übernommen werden.
---
16. Speicher- und Dateisystemabhängigkeiten prüfen | Aufgabe | Windows | Linux | macOS | |---|---|---|---| | Eingebundene Datenträger | `[RO] Get-Volume` | `[RO] findmnt` | `[RO] mount` | | Freier Speicherplatz | `[RO] Get-Volume` | `[RO] df -hT` | `[RO] df -h` | | Bestimmten Pfad prüfen | `[RO] Test-Path ""` | `[RO] findmnt --target ""` | `[RO] df -h ""` | | Pfadinformationen | `[RO][FILE] Get-Item ""` | `[RO][FILE] stat ""` | `[RO][FILE] stat ""` | | Schreibrechte des aktuellen Kontos | `[RO][FILE] Get-Acl ""` | `[RO][FILE] namei -l ""` | `[RO][FILE] ls -lde ""` | **Zu prüfen:** - Ist das Dateisystem eingehängt? - Zeigt der Pfad auf das erwartete Ziel? - Ist ausreichend Speicherplatz vorhanden? - Sind unter Linux noch Inodes verfügbar? - Ist das Dateisystem schreibgeschützt? - Besitzt das Dienstkonto die erforderlichen Rechte? - Ist ein Netzwerkmount nur scheinbar vorhanden, aber nicht erreichbar? - Bestehen Dateisperren? - Hat sich der Mountpfad geändert? - Ist das Volume nach einem Neustart automatisch eingebunden worden? > Schreibtests verändern das Dateisystem und dürfen nur gezielt, mit freigegebenem Testpfad und anschließendem Aufräumen durchgeführt werden.
---
17. Zeit- und Synchronisationsabhängigkeit prüfen Falsche Systemzeit kann unter anderem folgende Funktionen beeinträchtigen: - Kerberos-Authentifizierung, - Zertifikatsprüfung, - signierte Tokens, - Protokollkorrelation, - zeitgesteuerte Aufgaben, - Datenbankreplikation, - Clusterentscheidungen, - Ablaufzeiten und Cache-Gültigkeit. | Aufgabe | Windows | Linux | macOS | |---|---|---|---| | Lokale Zeit | `[RO] Get-Date -Format o` | `[RO] date --iso-8601=seconds` | `[RO] date "+%Y-%m-%dT%H:%M:%S%z"` | | UTC-Zeit | `[RO] (Get-Date).ToUniversalTime().ToString("o")` | `[RO] date -u "+%Y-%m-%dT%H:%M:%SZ"` | `[RO] date -u "+%Y-%m-%dT%H:%M:%SZ"` | | Zeitzone | `[RO] Get-TimeZone` | `[RO] timedatectl status` | `[RO][PRIV] sudo systemsetup -gettimezone` | | Zeitstatus | `[RO] w32tm /query /status` | `[RO] timedatectl status` | `[RO] systemsetup -getusingnetworktime` | **Prüfung:** - Stimmen Datum und Uhrzeit? - Ist die richtige Zeitzone eingestellt? - Ist die Zeitquelle erreichbar? - Sind Client, Dienstserver und Backend ausreichend synchron? - Stimmen Protokollzeitstempel tatsächlich überein? - Verwendet eine Anwendung UTC, während eine andere lokale Zeit protokolliert?
---
18. Authentifizierungsabhängigkeit prüfen Typische abhängige Identitätsdienste: - Active Directory, - LDAP oder LDAPS, - Kerberos, - RADIUS, - lokale Benutzerverwaltung, - OAuth- oder OpenID-Connect-Anbieter, - SAML-Identitätsanbieter, - Zertifikats- oder Smartcard-Infrastruktur. **Vor einer Anmeldeprüfung kontrollieren:** 1. Wird der Identitätsserver korrekt aufgelöst? 2. Ist der erforderliche Port erreichbar? 3. Ist die Systemzeit synchron? 4. Ist das Dienstkonto aktiv? 5. Ist das Kennwort beziehungsweise Secret gültig? 6. Ist das Konto gesperrt? 7. Besitzt das Konto die erforderlichen Rechte? 8. Ist das Serverzertifikat gültig? 9. Funktioniert nur die Anmeldung nicht oder auch die gesamte Anwendung? 10. Sind alle Benutzer oder nur einzelne Konten betroffen? > Kennwörter, Tokens und private Schlüssel dürfen niemals in Diagnoseausgaben, Tickets oder BookStack-Beispiele kopiert werden.
---
19. Gemeinsame Abhängigkeit als Ursache erkennen Wenn mehrere Dienste gleichzeitig ausfallen, sollte nach einer gemeinsamen Komponente gesucht werden. | Beobachtung | Mögliche gemeinsame Abhängigkeit | |---|---| | Mehrere Anwendungen können Benutzer nicht anmelden | Verzeichnisdienst, DNS oder Zeitquelle | | Mehrere Webseiten liefern Backendfehler | Datenbank, Reverse Proxy oder Speicher | | Mehrere Dienste können keine Dateien schreiben | Volume, Dateisystem oder Berechtigung | | Nur externe APIs schlagen fehl | Proxy, Internetzugang, DNS oder Zertifikatskette | | Alle Dienste eines Hosts sind langsam | CPU, RAM, Datenträger oder Virtualisierungsplattform | | Mehrere Container starten nicht | Container-Runtime, Netzwerk oder Storage | | Anwendungen an einem Standort sind betroffen | WAN, VPN, DNS oder Firewall | | Fehler beginnt exakt gleichzeitig | Gemeinsame Änderung oder Infrastrukturkomponente | **Vorgehen:** ```text 1. Betroffene Dienste auflisten 2. Zeitpunkt jedes Ausfalls vergleichen 3. Gemeinsame DNS-, Netzwerk- und Speicherpfade bestimmen 4. Gemeinsame Datenbanken und Identitätsdienste bestimmen 5. Gemeinsame Änderungen ermitteln 6. Gemeinsame Abhängigkeit direkt prüfen 7. Nach Wiederherstellung alle abhängigen Funktionen testen ```
---
20. Startreihenfolge nicht mit Betriebsbereitschaft verwechseln Ein Dienst kann laut Betriebssystem gestartet worden sein, obwohl seine Funktion noch nicht vollständig bereitsteht. **Beispiel:** ```text 00:00 Datenbankprozess startet 00:02 Dienstverwaltung meldet „läuft“ 00:05 Datenbank führt Wiederherstellung aus 00:40 Datenbank nimmt Anmeldungen an ``` Startet die Anwendung bereits bei Sekunde 3, kann ihre Verbindung fehlschlagen, obwohl der Datenbankdienst formal läuft. Mögliche Lösungen innerhalb eines geplanten Änderungsverfahrens: - geeignete Bereitschaftsprüfung, - Wiederholungsversuche mit Begrenzung, - zunehmende Wartezeiten zwischen Versuchen, - sinnvoller Verbindungstimeout, - korrekte systemd-Abhängigkeit, - orchestrierte Healthchecks, - Start erst nach erfolgreichem Backendtest, - Warteschlange für vorübergehend nicht verarbeitbare Aufgaben. > Eine feste Wartezeit ist häufig weniger zuverlässig als eine echte Bereitschaftsprüfung.
---
21. Auswirkungen vor einem Neustart einer Abhängigkeit prüfen Vor dem Neustart eines gemeinsam verwendeten Dienstes müssen die abhängigen Verbraucher bestimmt werden. **Windows:** ```powershell [RO] (Get-Service -Name "").DependentServices | Select-Object Name, DisplayName, Status ``` **Linux:** ```bash [RO] systemctl list-dependencies \ --reverse \ --no-pager \ "" ``` **macOS:** Da launchd kein allgemeines ausdrückliches Abhängigkeitsmodell besitzt, müssen zusätzlich geprüft werden: - Herstellerdokumentation, - aktive Netzwerkverbindungen, - Konfigurationsdateien, - Architekturübersicht, - Monitoring, - Anwendungsprotokolle, - bekannte Verbraucher des Dienstes. **Freigabecheck:** ```text [ ] Alle bekannten Verbraucher identifiziert [ ] Aktive Sitzungen und Transaktionen geprüft [ ] Cluster- oder Failover-Verhalten geprüft [ ] Wiederverbindungsverhalten der Clients bekannt [ ] Neustartreihenfolge festgelegt [ ] Wartungsfenster beziehungsweise Freigabe vorhanden [ ] Diagnoseinformationen vorab gesichert [ ] Funktionstests für alle wichtigen Verbraucher vorbereitet [ ] Rückfallmöglichkeit festgelegt ```
---
22. Abhängigkeitsfehler schrittweise eingrenzen **Empfohlene Reihenfolge:** 1. Hauptfunktion und Fehlermeldung bestimmen. 2. Formale Dienstabhängigkeiten erfassen. 3. Architektur und funktionale Abhängigkeiten ergänzen. 4. Kritische und optionale Abhängigkeiten kennzeichnen. 5. Namen der Zielsysteme prüfen. 6. DNS-Auflösung prüfen. 7. Netzwerkport vom tatsächlichen Dienstserver prüfen. 8. TLS- und Zertifikatsprüfung durchführen. 9. Protokollspezifischen Funktionstest durchführen. 10. Authentifizierung mit einem freigegebenen Testkonto prüfen. 11. Speicher- und Ressourcenabhängigkeiten prüfen. 12. Zeitstempel der beteiligten Systeme vergleichen. 13. Protokolle auf Quelle und Ziel korrelieren. 14. Gemeinsame Abhängigkeiten anderer gestörter Dienste prüfen. 15. Erst nach gesicherter Ursache eine Änderung planen. **Prüfkette:** ```text Name korrekt? ↓ DNS korrekt? ↓ Route vorhanden? ↓ Port erreichbar? ↓ TLS gültig? ↓ Protokoll antwortet? ↓ Authentifizierung erfolgreich? ↓ Berechtigung ausreichend? ↓ Fachliche Anfrage erfolgreich? ```
---
23. Typische Fehlinterpretationen | Fehlinterpretation | Richtige Bewertung | |---|---| | „Alle Abhängigkeiten stehen in der Dienstverwaltung.“ | Viele funktionale Abhängigkeiten sind nur in der Anwendung konfiguriert | | „Der erforderliche Dienst läuft, also funktioniert er.“ | Seine fachliche Funktion muss separat geprüft werden | | „`After=` bedeutet, dass der andere systemd-Dienst zwingend benötigt wird.“ | `After=` legt nur eine Reihenfolge fest | | „`Requires=` bedeutet automatisch die richtige Startreihenfolge.“ | Dafür kann zusätzlich `After=` oder `Before=` erforderlich sein | | „Ein erfolgreicher Porttest beweist die Backendfunktion.“ | Nur der Transportweg wurde bestätigt | | „DNS liefert eine Adresse, also ist das richtige Backend erreicht.“ | Adresse, Zertifikat und Anwendungsantwort müssen geprüft werden | | „Alle Benutzer sind betroffen, also liegt es am Hauptdienst.“ | Eine gemeinsame Abhängigkeit kann ausgefallen sein | | „Ein Neustart der Hauptanwendung repariert die Abhängigkeit.“ | Er kann nur neue Verbindungsversuche auslösen | | „Startreihenfolge beweist Betriebsbereitschaft.“ | Ein Prozess kann laufen, während die Initialisierung noch andauert | | „Ein optionales Backend kann ignoriert werden.“ | Es kann für einzelne wichtige Funktionen zwingend sein |
---
24. Checkliste zur Abhängigkeitsanalyse ```text [ ] Hauptdienst eindeutig bestimmt [ ] Formale Betriebssystem-Abhängigkeiten erfasst [ ] Vorwärts gerichtete Abhängigkeiten geprüft [ ] Rückwärts gerichtete Abhängigkeiten geprüft [ ] Startreihenfolge getrennt von Anforderung bewertet [ ] Kritische und optionale Abhängigkeiten unterschieden [ ] Externe Datenbanken erfasst [ ] DNS- und Zeitabhängigkeiten erfasst [ ] Authentifizierungsdienste erfasst [ ] Speicher- und Dateisystemabhängigkeiten erfasst [ ] Proxys, Loadbalancer und APIs erfasst [ ] Container-, Cluster- oder Cloud-Abhängigkeiten berücksichtigt [ ] DNS-Auflösung vom Dienstserver geprüft [ ] Zielport vom Dienstserver geprüft [ ] TLS und Zertifikatsname geprüft [ ] Protokollspezifischer Funktionstest durchgeführt [ ] Gemeinsame Abhängigkeiten anderer Störungen geprüft [ ] Protokollzeitstempel korreliert [ ] Auswirkungen eines Neustarts bewertet [ ] Keine Geheimnisse dokumentiert [ ] Nächsten Diagnoseschritt festgelegt ```
--- **Bewertung des Ergebnisses** | Ergebnis | Nächster Schritt | |---|---| | Formale Abhängigkeit ist beendet | Status, Startfehler und Protokolle dieser Abhängigkeit prüfen | | Abhängigkeit ist deaktiviert oder maskiert | Sollzustand und Änderungshistorie klären | | DNS-Auflösung schlägt fehl | DNS-Konfiguration und verwendeten Namen prüfen | | Port der Abhängigkeit ist nicht erreichbar | Listener, Firewall und Netzwerkpfad prüfen | | Port ist erreichbar, Protokolltest scheitert | TLS, Authentifizierung und Anwendung prüfen | | Speicherpfad fehlt | Mount, Volume, Netzwerk und Berechtigungen prüfen | | Nur Anmeldung schlägt fehl | Identitätsdienst, Zeit und Dienstkonto prüfen | | Mehrere Dienste sind gleichzeitig betroffen | Gemeinsame Abhängigkeit priorisiert untersuchen | | Backend ist erst spät betriebsbereit | Healthcheck, Wiederholungslogik und Startablauf prüfen | | Alle Abhängigkeiten funktionieren | Hauptdienstkonfiguration und Dienstprotokolle untersuchen | --- **Merksatz** > **Die sichtbare Anwendung ist oft nur das letzte Glied einer langen Dienstkette. Die Ursache liegt häufig in einer gemeinsam genutzten, zunächst unsichtbaren Abhängigkeit.** --- **Weiterführende Quellen** - [Microsoft Learn – Get-Service](https://learn.microsoft.com/powershell/module/microsoft.powershell.management/get-service) - [Microsoft Learn – ServiceController.ServicesDependedOn](https://learn.microsoft.com/dotnet/api/system.serviceprocess.servicecontroller.servicesdependedon) - [Microsoft Learn – ServiceController.DependentServices](https://learn.microsoft.com/dotnet/api/system.serviceprocess.servicecontroller.dependentservices) - [Microsoft Learn – sc.exe qc](https://learn.microsoft.com/windows-server/administration/windows-commands/sc-qc) - [Microsoft Learn – sc.exe enumdepend](https://learn.microsoft.com/windows-server/administration/windows-commands/sc-enumdepend) - [systemd – systemctl](https://www.freedesktop.org/software/systemd/man/latest/systemctl.html) - [systemd – systemd.unit](https://www.freedesktop.org/software/systemd/man/latest/systemd.unit.html) - [systemd – systemd.service](https://www.freedesktop.org/software/systemd/man/latest/systemd.service.html) - [Apple – launchctl-Handbuchseite](https://keith.github.io/xcode-man-pages/launchctl.1.html) - [Apple – launchd.plist-Handbuchseite](https://keith.github.io/xcode-man-pages/launchd.plist.5.html) - [Microsoft Learn – Test-NetConnection](https://learn.microsoft.com/powershell/module/nettcpip/test-netconnection) - [curl – offizielle Dokumentation](https://curl.se/docs/manpage.html) # 4.6 System- und Dienstprotokolle auswerten System- und Dienstprotokolle dokumentieren Ereignisse, die während des Starts, Betriebs und Beendens eines Dienstes auftreten. Sie können Hinweise auf Konfigurationsfehler, fehlende Berechtigungen, nicht erreichbare Abhängigkeiten, Ressourcenmangel oder Programmabstürze liefern. > **Grundsatz:** > Protokolle werden nicht wahllos nach dem Wort „Fehler“ durchsucht. Zuerst werden Zeitraum, betroffener Dienst, Server und auslösende Aktion festgelegt. --- **Ziele dieser Seite** Nach dieser Seite sollst du: - ein geeignetes Zeitfenster für die Protokollanalyse bestimmen können, - Windows-Ereignisprotokolle, systemd-Journal und macOS Unified Logging auswerten können, - nach Dienst, Quelle, Prozess, Ereignis-ID und Priorität filtern können, - System- und Anwendungsprotokolle zeitlich miteinander verbinden können, - Ursachen von Folgefehlern unterscheiden können, - Live-Protokolle kontrolliert beobachten können, - relevante Protokolle sichern können, - sensible Inhalte vor einer Weitergabe erkennen können, - Grenzen und Aufbewahrungsregeln von Protokollen berücksichtigen können. ---
1. Beobachtung, Protokollhinweis und Ursache unterscheiden | Ebene | Beispiel | |---|---| | Benutzerbeobachtung | Anmeldung schlägt um 09:15 Uhr fehl | | Anwendungsprotokoll | Datenbankverbindung um 09:15:02 Uhr fehlgeschlagen | | Systemprotokoll | Netzwerkschnittstelle um 09:14:58 Uhr getrennt | | Backendprotokoll | Keine Anfrage vom Anwendungsserver eingegangen | | Ursache | Netzwerkschnittstelle verlor aufgrund eines Treiberfehlers die Verbindung | | Folgefehler | Anwendung meldete anschließend einen Datenbankfehler | Eine Protokollmeldung kann sein: - direkte Ursache, - Folge einer anderen Störung, - Warnung ohne Bezug zum aktuellen Problem, - erwarteter Betriebszustand, - Wiederholungsversuch, - Ergebnis einer automatischen Wiederherstellung, - Meldung eines vorgeschalteten oder abhängigen Systems. > Der erste sichtbare Fehler in einer Anwendung ist nicht zwingend das zeitlich erste technische Ereignis.
---
2. Vor der Suche ein genaues Zeitfenster festlegen Folgende Zeitangaben müssen möglichst genau bestimmt werden: | Information | Beispiel | |---|---| | Beginn des Fehlers | `2026-07-31T09:15:00+02:00` | | Ende beziehungsweise letzter Fehler | `2026-07-31T09:22:00+02:00` | | Zeitzone | Europe/Berlin, UTC+02:00 | | Auslösende Aktion | Anmeldung abgesendet | | Clientzeit | 09:15:00 | | Serverzeit | 09:15:02 | | Backendzeit | 07:15:02 UTC | | Vergleichszeitpunkt | Letzte erfolgreiche Anmeldung um 09:13 Uhr | **Empfohlener Suchbereich:** ```text Einige Minuten vor dem ersten sichtbaren Fehler bis einige Minuten nach dem letzten beobachteten Fehler ``` **Prüffragen:** - Verwenden alle Systeme dieselbe Zeitzone? - Protokolliert eine Anwendung in UTC? - Sind die Systemuhren synchronisiert? - Ist der Clientzeitstempel nur auf Sekunden genau? - Gab es unmittelbar vorher einen Neustart oder eine Änderung? - Ist das Problem dauerhaft oder nur kurzzeitig aufgetreten?
---
3. Protokollanalyse mit einer klaren Hypothese beginnen **Ungeeignete Suche:** > „Ich suche in allen Protokollen nach Fehlern.“ **Geeignete Suche:** > „Ich untersuche zwischen 09:10 und 09:20 Uhr die Ereignisse des Anwendungsdienstes, des Service Control Managers und der Datenbankverbindung.“ Eine gute Protokollsuche verwendet möglichst mehrere Filter: - Zeitfenster, - Server, - Dienstname, - Prozessname, - Prozess-ID, - Ereignisquelle, - Ereignis-ID, - Priorität, - Transaktions- oder Korrelations-ID, - Benutzer oder Sitzung, - Zielserver, - Fehlercode. **Empfohlene Reihenfolge:** ```text 1. Zeitpunkt festlegen 2. Hauptdienst filtern 3. Erste relevante Fehlermeldung bestimmen 4. Einige Ereignisse davor lesen 5. Abhängige Systeme prüfen 6. Fehlercode in offizieller Dokumentation nachschlagen 7. Ereignisse zeitlich zusammenführen 8. Hypothese mit einem gezielten Test überprüfen ```
---
4. Protokollquellen der Betriebssysteme vergleichen | Bereich | Windows | Linux mit systemd | macOS | |---|---|---|---| | Zentrale Oberfläche | Ereignisanzeige | `journalctl` | Konsole | | Zentrales Befehlswerkzeug | `Get-WinEvent` | `journalctl` | `log` | | Systemereignisse | Protokoll `System` | System-Journal | Unified Logging | | Anwendungsereignisse | Protokoll `Application` oder eigenes Protokoll | Journal oder Anwendungsdatei | Unified Logging oder Anwendungsdatei | | Dienstverwaltung | Service Control Manager | systemd | launchd | | Kernelmeldungen | Protokoll `System` | `journalctl -k` | `log show` und Diagnoseberichte | | Absturzberichte | Windows Error Reporting | Coredump- oder Anwendungsmechanismus | Diagnoseberichte | | Dateibasierte Logs | Anwendungsspezifisch | Häufig unter `/var/log` oder Produktpfad | Anwendungsspezifisch | > Nicht jede Anwendung schreibt in das zentrale Betriebssystemprotokoll. Herstellerdokumentation und effektive Dienstkonfiguration müssen zusätzlich geprüft werden.
---
5. Verfügbare Windows-Ereignisprotokolle ermitteln **Alle registrierten Protokolle auflisten:** ```powershell [RO] Get-WinEvent -ListLog * ``` **Nur aktivierte Protokolle anzeigen:** ```powershell [RO] Get-WinEvent -ListLog * | Where-Object IsEnabled | Select-Object LogName, RecordCount, FileSize, MaximumSizeInBytes | Sort-Object LogName ``` **Bestimmtes Protokoll untersuchen:** ```powershell [RO] Get-WinEvent -ListLog "System" ``` **Registrierte Ereignisanbieter suchen:** ```powershell [RO] Get-WinEvent -ListProvider "**" ``` **Typische Windows-Protokolle:** | Protokoll | Typischer Inhalt | |---|---| | `System` | Dienste, Treiber, Netzwerk und Betriebssystem | | `Application` | Anwendungen und Laufzeitumgebungen | | `Security` | Sicherheitsereignisse und Überwachung | | `Setup` | Installation und Systemeinrichtung | | `ForwardedEvents` | Weitergeleitete Ereignisse | | Anwendungs- und Dienstprotokolle | Komponenten- oder produktspezifische Ereignisse | > Der Zugriff auf das Sicherheitsprotokoll und bestimmte administrative Protokolle erfordert erhöhte Berechtigungen.
---
6. Letzte Windows-Ereignisse anzeigen **Letzte 50 Systemereignisse anzeigen:** ```powershell [RO] Get-WinEvent -LogName "System" -MaxEvents 50 | Select-Object TimeCreated, Id, LevelDisplayName, ProviderName, Message ``` **Letzte 50 Anwendungsereignisse anzeigen:** ```powershell [RO] Get-WinEvent -LogName "Application" -MaxEvents 50 | Select-Object TimeCreated, Id, LevelDisplayName, ProviderName, Message ``` **Neueste Ereignisse zuerst tabellarisch anzeigen:** ```powershell [RO] Get-WinEvent -LogName "System" -MaxEvents 100 | Format-Table TimeCreated, Id, LevelDisplayName, ProviderName, Message -Wrap ``` > `Format-Table` sollte hauptsächlich für die Anzeige verwendet werden. Für Export oder Weiterverarbeitung bleiben die ursprünglichen Ereignisobjekte geeigneter.
---
7. Windows-Ereignisse nach Zeitfenster filtern **Ereignisse der letzten Stunde:** ```powershell [RO] $startTime = (Get-Date).AddHours(-1) Get-WinEvent -FilterHashtable @{ LogName = "System" StartTime = $startTime } | Select-Object TimeCreated, Id, LevelDisplayName, ProviderName, Message ``` **Festes Zeitfenster verwenden:** ```powershell [RO] $startTime = Get-Date "2026-07-31 09:10:00" $endTime = Get-Date "2026-07-31 09:20:00" Get-WinEvent -FilterHashtable @{ LogName = "System" StartTime = $startTime EndTime = $endTime } | Select-Object TimeCreated, Id, LevelDisplayName, ProviderName, Message ``` **System- und Anwendungsprotokoll gemeinsam durchsuchen:** ```powershell [RO] Get-WinEvent -FilterHashtable @{ LogName = "System", "Application" StartTime = $startTime EndTime = $endTime } | Sort-Object TimeCreated | Select-Object TimeCreated, LogName, Id, LevelDisplayName, ProviderName, Message ``` > Die Uhrzeitangaben werden im Kontext des ausführenden Systems interpretiert. Zeitzone und Uhrzeitsynchronisation müssen deshalb vor der Korrelation geklärt sein.
---
8. Windows-Ereignisse nach Quelle, ID und Schweregrad filtern **Nach Ereignisanbieter filtern:** ```powershell [RO] Get-WinEvent -FilterHashtable @{ LogName = "System" ProviderName = "Service Control Manager" StartTime = (Get-Date).AddHours(-2) } ``` **Nach bestimmten Ereignis-IDs filtern:** ```powershell [RO] Get-WinEvent -FilterHashtable @{ LogName = "System" ProviderName = "Service Control Manager" Id = 7000, 7001, 7031, 7034 StartTime = (Get-Date).AddHours(-24) } | Select-Object TimeCreated, Id, LevelDisplayName, Message ``` **Nur kritische Ereignisse und Fehler anzeigen:** ```powershell [RO] Get-WinEvent -FilterHashtable @{ LogName = "System" Level = 1, 2 StartTime = (Get-Date).AddHours(-2) } ``` Übliche Windows-Ereignisebenen: | Zahlenwert | Ebene | |---:|---| | `1` | Kritisch | | `2` | Fehler | | `3` | Warnung | | `4` | Information | | `5` | Ausführlich | > Ereignis-IDs sind nur zusammen mit Anbieter und Protokoll eindeutig zu bewerten. Dieselbe ID kann bei unterschiedlichen Anbietern eine andere Bedeutung besitzen.
---
9. Typische Windows-Dienstereignisse einordnen Häufig relevante Ereignisse des Service Control Managers sind: | Ereignis-ID | Typische Bedeutung | |---:|---| | `7000` | Dienst konnte nicht gestartet werden | | `7001` | Abhängiger Dienst oder Abhängigkeitsgruppe konnte nicht gestartet werden | | `7009` | Zeitüberschreitung beim Warten auf eine Dienstverbindung | | `7011` | Zeitüberschreitung bei einer Diensttransaktion | | `7023` | Dienst wurde mit einem Fehler beendet | | `7024` | Dienst wurde mit einem dienstspezifischen Fehler beendet | | `7031` | Dienst wurde unerwartet beendet; Wiederherstellungsaktion kann folgen | | `7034` | Dienst wurde unerwartet beendet | | `7035` | Steuerbefehl wurde an einen Dienst gesendet | | `7036` | Dienst wechselte in einen anderen Zustand | | `7040` | Startart wurde geändert | | `7045` | Ein Dienst wurde im System installiert | **Wichtig:** - Die konkrete Nachricht muss immer mitgelesen werden. - Die Bedeutung muss bei Bedarf anhand der Microsoft-Dokumentation und des betroffenen Produkts geprüft werden. - Ein Service-Control-Manager-Ereignis kann nur die Auswirkung eines internen Anwendungsfehlers melden. - Für die eigentliche Ursache muss häufig zusätzlich das Anwendungsprotokoll untersucht werden.
---
10. Windows-Ereignisse nach Nachrichtentext durchsuchen **Nach einem Dienstnamen innerhalb eines begrenzten Zeitraums suchen:** ```powershell [RO][SENS] Get-WinEvent -FilterHashtable @{ LogName = "System", "Application" StartTime = (Get-Date).AddHours(-2) } | Where-Object Message -Match "" | Select-Object TimeCreated, LogName, Id, LevelDisplayName, ProviderName, Message ``` **Nach einem Fehlercode suchen:** ```powershell [RO][SENS] Get-WinEvent -FilterHashtable @{ LogName = "System", "Application" StartTime = (Get-Date).AddHours(-24) } | Where-Object Message -Match "" ``` > Textfilter mit `Where-Object` werden erst nach dem Lesen der Ereignisse angewendet und können bei großen Protokollen langsam sein. Zeitfenster, Protokoll und Anbieter sollten deshalb bereits serverseitig mit `FilterHashtable` eingeschränkt werden.
---
11. Windows-Ereignisse mit wevtutil prüfen und sichern **Informationen zu einem Protokoll anzeigen:** ```powershell [RO] wevtutil get-log "System" ``` Kurzform: ```powershell [RO] wevtutil gl "System" ``` **Die letzten Ereignisse eines Protokolls abfragen:** ```powershell [RO] wevtutil query-events "System" /count:20 /reverse-direction:true /format:text ``` Kurzform: ```powershell [RO] wevtutil qe "System" /c:20 /rd:true /f:text ``` **Ein vollständiges Ereignisprotokoll exportieren:** ```powershell [RO][FILE][SENS][PRIV] wevtutil export-log ` "System" ` ".evtx" ``` Kurzform: ```powershell [RO][FILE][SENS][PRIV] wevtutil epl "System" ".evtx" ``` > Eine EVTX-Datei kann Benutzernamen, Rechnernamen, interne Pfade, IP-Adressen und sicherheitsrelevante Ereignisse enthalten. Sie darf nur kontrolliert weitergegeben werden.
---
12. Linux-Journal eines Dienstes anzeigen **Gesamtes Journal einer systemd-Unit anzeigen:** ```bash [RO][SENS][PRIV] sudo journalctl -u "" --no-pager ``` **Neueste Einträge zuerst anzeigen:** ```bash [RO][SENS][PRIV] sudo journalctl \ -u "" \ --reverse \ --no-pager ``` **Letzte 100 Einträge anzeigen:** ```bash [RO][SENS][PRIV] sudo journalctl \ -u "" \ -n 100 \ --no-pager ``` **Nur Ereignisse des aktuellen Systemstarts:** ```bash [RO][SENS][PRIV] sudo journalctl \ -b \ -u "" \ --no-pager ``` **Ereignisse des vorherigen Systemstarts:** ```bash [RO][SENS][PRIV] sudo journalctl \ -b -1 \ -u "" \ --no-pager ``` > Ob Ereignisse früherer Systemstarts verfügbar sind, hängt von der Journal-Konfiguration und Aufbewahrung ab.
---
13. Linux-Journal nach Zeitfenster filtern **Ereignisse seit einer festen Uhrzeit:** ```bash [RO][SENS][PRIV] sudo journalctl \ -u "" \ --since "2026-07-31 09:10:00" \ --no-pager ``` **Festes Start- und Endzeitfenster:** ```bash [RO][SENS][PRIV] sudo journalctl \ -u "" \ --since "2026-07-31 09:10:00" \ --until "2026-07-31 09:20:00" \ --no-pager ``` **Relative Zeitangabe:** ```bash [RO][SENS][PRIV] sudo journalctl \ -u "" \ --since "1 hour ago" \ --no-pager ``` **Alle Ereignisse des heutigen Tages:** ```bash [RO][SENS][PRIV] sudo journalctl --since today --no-pager ``` **Zeitstempel mit ISO-Datum ausgeben:** ```bash [RO][SENS][PRIV] sudo journalctl \ -u "" \ --since "1 hour ago" \ --output=short-iso \ --no-pager ```
---
14. Linux-Journal nach Priorität filtern Übliche syslog-Prioritäten: | Wert | Name | Bedeutung | |---:|---|---| | `0` | `emerg` | System unbenutzbar | | `1` | `alert` | Sofortige Maßnahme erforderlich | | `2` | `crit` | Kritischer Zustand | | `3` | `err` | Fehler | | `4` | `warning` | Warnung | | `5` | `notice` | Bedeutender normaler Zustand | | `6` | `info` | Information | | `7` | `debug` | Debugmeldung | **Fehler und schwerwiegendere Meldungen eines Dienstes:** ```bash [RO][SENS][PRIV] sudo journalctl \ -u "" \ -p err \ --since "1 hour ago" \ --no-pager ``` **Warnungen und schwerwiegendere Meldungen:** ```bash [RO][SENS][PRIV] sudo journalctl \ -u "" \ -p warning \ --since "1 hour ago" \ --no-pager ``` **Nur einen bestimmten Prioritätsbereich verwenden:** ```bash [RO][SENS][PRIV] sudo journalctl \ -u "" \ -p warning..err \ --since "1 hour ago" \ --no-pager ``` > Nicht jede Anwendung verwendet Prioritäten korrekt. Eine relevante Fehlermeldung kann deshalb als `info` oder ohne geeignete Priorität protokolliert worden sein.
---
15. Linux-Journal nach Prozess oder Kennung filtern **Nach Prozess-ID filtern:** ```bash [RO][SENS][PRIV] sudo journalctl _PID= --no-pager ``` **Nach ausführbarer Datei filtern:** ```bash [RO][SENS][PRIV] sudo journalctl \ _EXE="" \ --no-pager ``` **Nach syslog-Kennung filtern:** ```bash [RO][SENS][PRIV] sudo journalctl \ -t "" \ --no-pager ``` **Felder eines Ereignisses ausführlich anzeigen:** ```bash [RO][SENS][PRIV] sudo journalctl \ -u "" \ -n 20 \ -o verbose \ --no-pager ``` Mögliche strukturierte Felder: ```text _SYSTEMD_UNIT _PID _UID _GID _EXE _COMM _HOSTNAME SYSLOG_IDENTIFIER PRIORITY MESSAGE ``` > PID-Filter sind nur für die Lebensdauer der jeweiligen Prozessinstanz geeignet. Nach einem Neustart besitzt der Dienst möglicherweise eine neue PID.
---
16. Linux-Kernel- und Bootmeldungen prüfen **Kernelmeldungen des aktuellen Systemstarts:** ```bash [RO][SENS][PRIV] sudo journalctl -k -b --no-pager ``` **Kernelwarnungen und schwerwiegendere Meldungen:** ```bash [RO][SENS][PRIV] sudo journalctl \ -k \ -b \ -p warning \ --no-pager ``` **Alle Meldungen des aktuellen Systemstarts:** ```bash [RO][SENS][PRIV] sudo journalctl -b --no-pager ``` **Verfügbare Systemstarts anzeigen:** ```bash [RO] journalctl --list-boots ``` **Relevante Kernelhinweise können sein:** - Datenträger- und Dateisystemfehler, - Netzwerkadapterfehler, - Speichermangel, - Prozessbeendigung durch den Out-of-Memory-Mechanismus, - Treiberprobleme, - schreibgeschützte Dateisysteme, - blockierte Aufgaben, - Hardwarefehler.
---
17. Linux-Journal live beobachten **Neue Ereignisse eines Dienstes live anzeigen:** ```bash [TEST][SENS][PRIV] sudo journalctl \ -f \ -u "" ``` **Mit bestehenden letzten Zeilen beginnen:** ```bash [TEST][SENS][PRIV] sudo journalctl \ -n 50 \ -f \ -u "" ``` **Nur Warnungen und schwerwiegendere Meldungen verfolgen:** ```bash [TEST][SENS][PRIV] sudo journalctl \ -f \ -u "" \ -p warning ``` **Vorgehen beim kontrollierten Live-Test:** ```text 1. Live-Ansicht starten 2. Genauen Startzeitpunkt notieren 3. Eine einzelne Testaktion ausführen 4. Neue Ereignisse beobachten 5. Testaktion und Ereignisse zeitlich zuordnen 6. Live-Ansicht mit Strg+C beenden 7. Relevante Meldungen dokumentieren ``` > Live-Logging kann große Mengen ausgeben. Der Filter sollte vor dem Test möglichst eng gesetzt werden.
---
18. Linux-Journalgröße und Aufbewahrung prüfen **Belegten Speicherplatz des Journals anzeigen:** ```bash [RO] journalctl --disk-usage ``` **Verfügbare Systemstarts anzeigen:** ```bash [RO] journalctl --list-boots ``` **Journal-Konfiguration lesen:** ```bash [RO][FILE] systemd-analyze cat-config systemd/journald.conf ``` Wichtige Konfigurationsbereiche können sein: ```text Storage SystemMaxUse RuntimeMaxUse MaxRetentionSec MaxFileSec RateLimitIntervalSec RateLimitBurst ``` **Mögliche Gründe für fehlende alte Einträge:** - Journal wird nur flüchtig gespeichert, - Größenbegrenzung wurde erreicht, - Aufbewahrungszeit ist abgelaufen, - System wurde neu gestartet, - Protokollrotation hat alte Daten entfernt, - Rate-Limiting hat Meldungen unterdrückt, - Anwendung schrieb in eine andere Datei, - Dienst startete in einem Container mit eigener Protokollierung. > Aufbewahrungseinstellungen dürfen nicht während einer Störung ungeprüft verändert werden. Zuerst muss der aktuelle Zustand dokumentiert werden.
---
19. Textbasierte Linux-Anwendungsprotokolle prüfen Der tatsächliche Protokollpfad muss aus Herstellerdokumentation oder effektiver Konfiguration ermittelt werden. **Letzte Zeilen einer bekannten Protokolldatei:** ```bash [RO][FILE][SENS][PRIV] sudo tail -n 100 "" ``` **Neue Einträge live verfolgen:** ```bash [TEST][FILE][SENS][PRIV] sudo tail -F "" ``` **Nach einem festen Text suchen:** ```bash [RO][FILE][SENS][PRIV] sudo grep \ -n \ -i \ -- "" \ "" ``` **Komprimierte rotierte Protokolle durchsuchen:** ```bash [RO][FILE][SENS][PRIV] sudo zgrep \ -n \ -i \ -- "" \ ".gz" ``` **Datei kontrolliert mit Pager öffnen:** ```bash [RO][FILE][SENS][PRIV] sudo less "" ``` Nützliche Tasten in `less`: | Taste | Funktion | |---|---| | `/Text` | Vorwärts suchen | | `?Text` | Rückwärts suchen | | `n` | Nächster Treffer | | `N` | Vorheriger Treffer | | `G` | Dateiende | | `g` | Dateianfang | | `q` | Beenden | > Keine angenommenen Standardpfade verwenden. Container, Pakete und Hersteller können unterschiedliche Protokollziele konfigurieren.
---
20. macOS Unified Logging nach Zeitraum auswerten **Meldungen der letzten Stunde anzeigen:** ```bash [RO][SENS][PRIV] sudo log show \ --last 1h \ --style compact \ --no-pager ``` **Meldungen seit dem letzten Systemstart:** ```bash [RO][SENS][PRIV] sudo log show \ --last boot \ --style compact \ --no-pager ``` **Festes Zeitfenster verwenden:** ```bash [RO][SENS][PRIV] sudo log show \ --start "2026-07-31 09:10:00" \ --end "2026-07-31 09:20:00" \ --style compact \ --no-pager ``` **Lokale Zeitzone ausdrücklich verwenden:** ```bash [RO][SENS][PRIV] sudo log show \ --last 1h \ --timezone local \ --style compact \ --no-pager ``` > Standardmäßig zeigt `log show` nicht zwingend alle Info- und Debugmeldungen. Diese Ebenen werden bei Bedarf ausdrücklich aktiviert.
---
21. macOS-Protokolle nach Prozess filtern **Nach Prozessnamen filtern:** ```bash [RO][SENS][PRIV] sudo log show \ --last 1h \ --predicate 'process == ""' \ --style compact \ --no-pager ``` **Nach Prozess-ID filtern:** ```bash [RO][SENS][PRIV] sudo log show \ --last 1h \ --predicate 'processIdentifier == ' \ --style compact \ --no-pager ``` **Info-Meldungen einschließen:** ```bash [RO][SENS][PRIV] sudo log show \ --last 1h \ --info \ --predicate 'process == ""' \ --style compact \ --no-pager ``` **Info- und Debugmeldungen einschließen:** ```bash [RO][SENS][PRIV] sudo log show \ --last 1h \ --info \ --debug \ --predicate 'process == ""' \ --style compact \ --no-pager ``` > Die Erhöhung des sichtbaren Umfangs kann sehr große Ausgaben erzeugen. Zuerst sollte mit engem Zeitfenster und Prozessfilter gearbeitet werden.
---
22. macOS-Protokolle nach Subsystem und Schweregrad filtern **Nach bekanntem Subsystem filtern:** ```bash [RO][SENS][PRIV] sudo log show \ --last 1h \ --predicate 'subsystem == ""' \ --style compact \ --no-pager ``` **Fehler und Faults eines Prozesses anzeigen:** ```bash [RO][SENS][PRIV] sudo log show \ --last 1h \ --predicate 'process == "" AND (messageType == error OR messageType == fault)' \ --style compact \ --no-pager ``` **Nach Text innerhalb der Meldung suchen:** ```bash [RO][SENS][PRIV] sudo log show \ --last 1h \ --predicate 'eventMessage CONTAINS[c] ""' \ --style compact \ --no-pager ``` Wichtige Filterfelder: | Feld | Bedeutung | |---|---| | `process` | Name des erzeugenden Prozesses | | `processIdentifier` | PID | | `subsystem` | Logisches Subsystem | | `category` | Kategorie innerhalb des Subsystems | | `messageType` | Meldungstyp | | `eventMessage` | Meldungstext | | `sender` | Bibliothek oder ausführende Komponente | | `processImagePath` | Programmpfad |
---
23. macOS-Protokolle live beobachten **Meldungen eines Prozesses live verfolgen:** ```bash [TEST][SENS][PRIV] sudo log stream \ --predicate 'process == ""' \ --style compact ``` **Fehler und Faults live verfolgen:** ```bash [TEST][SENS][PRIV] sudo log stream \ --predicate 'process == "" AND (messageType == error OR messageType == fault)' \ --style compact ``` **Live-Ausgabe zeitlich begrenzen:** ```bash [TEST][SENS][PRIV] sudo log stream \ --timeout 5m \ --predicate 'process == ""' \ --style compact ``` **Info-Ebene einbeziehen:** ```bash [TEST][SENS][PRIV] sudo log stream \ --level info \ --predicate 'process == ""' \ --style compact ``` > Der Befehl wird ohne Zeitbegrenzung mit `Strg+C` beendet. Eine zeitliche Begrenzung verhindert versehentlich lange laufende Mitschnitte.
---
24. macOS-Protokollarchiv sichern **Protokolle der letzten Stunde in ein Logarchiv sammeln:** ```bash [RO][FILE][SENS][PRIV] sudo log collect \ --last 1h \ --output ".logarchive" ``` **Protokolle ab einem festen Zeitpunkt sammeln:** ```bash [RO][FILE][SENS][PRIV] sudo log collect \ --start "2026-07-31 09:10:00" \ --output ".logarchive" ``` Ein `.logarchive` kann später mit der App „Konsole“ oder mit `log show` ausgewertet werden. **Archiv über die Kommandozeile lesen:** ```bash [RO][FILE][SENS] log show \ --archive ".logarchive" \ --style compact \ --no-pager ``` > Ein vollständiges macOS-Logarchiv kann umfangreiche und sensible Systeminformationen enthalten. Vor einer externen Weitergabe müssen Zweck, Empfänger und Datenschutz geprüft werden.
---
25. Anwendungsprotokolle unter Windows und macOS berücksichtigen Nicht jede Anwendung verwendet ausschließlich das zentrale Systemprotokoll. Mögliche Protokollziele: - Windows-Anwendungsprotokoll, - eigenes Windows-Ereignisprotokoll, - macOS Unified Logging, - Textdatei, - JSON-Datei, - Datenbank, - Container-Standardausgabe, - zentraler Syslog-Server, - SIEM- oder Monitoringplattform, - herstellerspezifisches Diagnosepaket. **Protokollpfad korrekt ermitteln über:** 1. Herstellerdokumentation, 2. wirksame Dienstkonfiguration, 3. Startparameter, 4. Umgebungsvariablen, 5. Dienstkonto, 6. Containerdefinition, 7. Protokollierungs- oder Loggingabschnitt der Anwendung. > Keine Verzeichnisse oder Dateinamen als gegeben annehmen. Der wirksame Pfad kann durch Installation, Paketierung oder lokale Konfiguration verändert worden sein.
---
26. Containerprotokolle berücksichtigen Bei containerisierten Diensten können Protokolle an mehreren Stellen entstehen: ```text Hostbetriebssystem → Container-Runtime → Container → Prozess im Container → Anwendung → externes zentrales Logging ``` Mögliche Protokollquellen: - Runtime-Ereignisse auf dem Host, - Standardausgabe und Standardfehler des Containers, - an ein Volume gebundene Anwendungsprotokolle, - Reverse-Proxy-Protokolle, - Datenbankprotokolle, - Orchestrator-Ereignisse, - Healthcheck-Ausgaben. **Prüffragen:** - Wurde der Container neu erstellt? - Ist die Container-ID gewechselt? - Wurden alte Containerprotokolle entfernt? - Schreibt die Anwendung in die Standardausgabe oder in eine Datei? - Ist das Logverzeichnis dauerhaft eingebunden? - Gibt es Größenbegrenzung und Rotation? - Werden Protokolle an einen zentralen Dienst weitergeleitet? - Enthält die Ausgabe Secrets oder personenbezogene Daten? > Die konkrete Runtime wird in dieser Seite nicht vorausgesetzt. Die passenden Befehle müssen anhand der tatsächlich eingesetzten Containerplattform ausgewählt werden.
---
27. Protokolle mehrerer Systeme zeitlich korrelieren Beispiel: | Zeit | System | Ereignis | |---|---|---| | 09:14:58 | Datenbankserver | Datenträger meldet Schreibfehler | | 09:15:00 | Datenbankserver | Datenbank beendet Schreibtransaktion mit Fehler | | 09:15:02 | Anwendungsserver | Datenbankverbindung wird zurückgesetzt | | 09:15:03 | Webserver | Backend antwortet nicht | | 09:15:04 | Client | HTTP 503 wird angezeigt | **Wahrscheinliche Ereigniskette:** ```text Datenträgerfehler → Datenbankfehler → Verbindung des Anwendungsservers bricht ab → Webserver erhält keine gültige Backendantwort → Benutzer sieht HTTP 503 ``` **Vorgehen:** 1. Alle Zeitstempel in dieselbe Zeitzone überführen. 2. Erstes technisches Ereignis bestimmen. 3. Vorhergehende Warnungen berücksichtigen. 4. Fehler auf Quell- und Zielsystem vergleichen. 5. Verbindungs- oder Korrelations-IDs verwenden. 6. Ursache und Folge in einer Zeitleiste dokumentieren. 7. Hypothese mit technischen Tests bestätigen.
---
28. Fehlercodes richtig auswerten Ein Fehlercode sollte zusammen mit folgendem Kontext dokumentiert werden: ```text Betriebssystem: Produkt: Komponente: Version: Protokoll: Ereignisanbieter: Ereignis-ID: Fehlercode: Vollständige Meldung: Zeitpunkt: Auslösende Aktion: ``` **Regeln:** - Code vollständig übernehmen, - hexadezimale und dezimale Schreibweise nicht verwechseln, - Anbieter und Produktversion notieren, - nur offizielle Herstellerdokumentation als gesicherte Bedeutung behandeln, - nicht denselben Code aus einem anderen Produkt übertragen, - innere oder verschachtelte Fehlermeldungen mit erfassen, - Ursache erst nach Prüfung festlegen. > Eine Suchmaschinenfundstelle ohne passenden Hersteller-, Versions- und Komponentenkontext ist kein ausreichender Ursachenbeweis.
---
29. Fehlende Protokolle richtig bewerten Keine gefundene Meldung bedeutet nicht automatisch, dass kein Fehler auftrat. Mögliche Gründe: - falsches Zeitfenster, - falsche Zeitzone, - falscher Server, - falsches Protokoll, - falscher Prozessname, - Dienst wurde mit neuer PID gestartet, - Protokollierung ist deaktiviert, - Aufbewahrung ist abgelaufen, - Logrotation hat die Datei verschoben, - Rate-Limiting unterdrückte Meldungen, - Anwendung schreibt in eine andere Datei, - Meldung wurde nur auf dem Backend erzeugt, - Debugebene war nicht aktiviert, - Container wurde entfernt, - Dienst stürzte vor Initialisierung der Protokollierung ab, - Berechtigung zum Lesen fehlt. > Das Fehlen einer Meldung ist nur dann aussagekräftig, wenn bekannt ist, dass genau dieses Ereignis an dieser Stelle protokolliert werden müsste.
---
30. Sensible Inhalte in Protokollen erkennen Protokolle können enthalten: - Benutzernamen, - E-Mail-Adressen, - IP-Adressen, - interne Servernamen, - Dateipfade, - Dokumentnamen, - Datenbankabfragen, - URL-Parameter, - Sitzungscookies, - Zugriffstoken, - API-Schlüssel, - Authorization-Header, - personenbezogene Daten, - interne Geschäfts- und Systeminformationen. **Vor Weitergabe prüfen:** ```text [ ] Zweck der Weitergabe geklärt [ ] Empfänger berechtigt [ ] Zeitraum auf das Notwendige begrenzt [ ] Nicht relevante Ereignisse entfernt [ ] Kennwörter und Token entfernt [ ] Cookies und Authorization-Header entfernt [ ] Personenbezogene Daten geschützt [ ] Interne Infrastrukturinformationen bewertet [ ] Originaldatei beweissicher aufbewahrt [ ] Bearbeitete Kopie als solche gekennzeichnet ``` > Das Original darf bei einer Beweissicherung nicht unkontrolliert verändert werden. Für Weitergaben wird eine gesonderte bereinigte Kopie erstellt.
---
31. Relevante Protokollstellen dokumentieren **Dokumentationsvorlage:** ```text Störung: Server: Dienst: Betriebssystem: Zeitzone: Untersuchter Zeitraum: Protokollquelle: Ereignisanbieter beziehungsweise Prozess: Ereignis-ID: Fehlercode: Zeitstempel: Vollständige relevante Meldung: Unmittelbar vorhergehendes Ereignis: Unmittelbar folgendes Ereignis: Betroffene Abhängigkeit: Interpretation: Beleg für die Interpretation: Nächster Prüfschritt: ``` **Gute Dokumentation:** > Um 09:15:02 Uhr protokollierte der Anwendungsdienst eine zurückgesetzte Datenbankverbindung. Zwei Sekunden zuvor meldete der Datenbankserver einen Schreibfehler. Die zeitliche Reihenfolge spricht für einen Zusammenhang, der durch Datenträger- und Datenbankprüfung bestätigt werden muss. **Unzureichende Dokumentation:** > In den Logs stand etwas mit Datenbank.
---
32. Typische Fehler bei der Protokollanalyse | Fehler | Folge | Bessere Vorgehensweise | |---|---|---| | Gesamtes Protokoll ohne Zeitfilter lesen | Relevante Ereignisse gehen in Datenmenge unter | Enges Zeitfenster verwenden | | Nur Fehlerstufe anzeigen | Relevante Warnungen oder Infos fehlen | Kontext vor und nach dem Fehler lesen | | Nur Hauptserver prüfen | Backendursache bleibt verborgen | Abhängige Systeme einbeziehen | | Neueste Meldung als Ursache behandeln | Folgefehler wird verwechselt | Zeitlich erstes relevantes Ereignis suchen | | Ereignis-ID ohne Anbieter bewerten | Falsche Bedeutung möglich | Anbieter, Protokoll und Version notieren | | Zeitzonen ignorieren | Ereigniskette wird falsch sortiert | Zeitstempel normalisieren | | Debuglogging dauerhaft aktivieren | Datenmenge und Datenschutzrisiko steigen | Nur kontrolliert und zeitlich begrenzt | | Protokoll während Störung löschen | Beweise gehen verloren | Nur lesen und sichern | | Vollständiges Archiv ungeprüft versenden | Sensible Daten werden offengelegt | Bereinigte Kopie erstellen | | Einzelne Meldung ohne Funktionstest bewerten | Hypothese bleibt unbestätigt | Gezielten Test durchführen |
---
33. Checkliste zur Protokollanalyse ```text [ ] Störung und auslösende Aktion eindeutig beschrieben [ ] Server und Dienst bestätigt [ ] Beginn und Ende des Fehlers bestimmt [ ] Zeitzonen aller beteiligten Systeme geprüft [ ] Zeitfenster einige Minuten erweitert [ ] Betriebssystemprotokoll geprüft [ ] Dienst- beziehungsweise Anwendungsprotokoll geprüft [ ] Ereignisanbieter oder Prozess gefiltert [ ] Ereignis-ID und Fehlercode erfasst [ ] Meldungen unmittelbar vor dem Fehler gelesen [ ] Meldungen unmittelbar nach dem Fehler gelesen [ ] Abhängige Systeme geprüft [ ] Ursache und Folge getrennt [ ] Prozessneustart und PID-Wechsel berücksichtigt [ ] Protokollaufbewahrung und Rotation geprüft [ ] Fehlende Meldungen nicht vorschnell bewertet [ ] Relevante Protokolle gesichert [ ] Sensible Inhalte vor Weitergabe entfernt [ ] Hypothese durch einen technischen Test geprüft [ ] Ergebnis und nächster Schritt dokumentiert ```
--- **Bewertung des Ergebnisses** | Ergebnis | Nächster Schritt | |---|---| | Dienst konnte nicht gestartet werden | Exitcode, Konto, Pfad und Konfiguration prüfen | | Dienst wurde unerwartet beendet | Absturzbericht, Ressourcen und Wiederherstellungsaktion prüfen | | Abhängigkeit ist nicht erreichbar | DNS-, Netzwerk-, Port- und Backendprüfung durchführen | | Zugriff wurde verweigert | Dienstkonto, Datei- und Systemberechtigungen prüfen | | Speicher- oder Datenträgerfehler vorhanden | Ressourcen und Dateisystem untersuchen | | TLS- oder Zertifikatsfehler vorhanden | Zertifikat, Name, Zeit und Vertrauenskette prüfen | | Protokoll zeigt Zeitüberschreitung | Zielsystem, Last, Netzwerk und Timeoutursache prüfen | | Mehrere Systeme zeigen dieselbe Ereigniskette | Gemeinsame Ursache priorisiert untersuchen | | Keine Meldung gefunden | Zeitfenster, Quelle, Aufbewahrung und Logziel prüfen | | Protokoll liefert nur einen Folgefehler | Zeitlich frühere Komponente untersuchen | --- **Merksatz** > **Ein Protokolleintrag ist ein Beweis für eine aufgezeichnete Beobachtung. Erst Zeitfolge, Systemzusammenhang und ein bestätigender Test machen daraus einen belastbaren Ursachenhinweis.** --- **Weiterführende Quellen** - [Microsoft Learn – Get-WinEvent](https://learn.microsoft.com/powershell/module/microsoft.powershell.diagnostics/get-winevent) - [Microsoft Learn – Erstellen effizienter Ereignisabfragen mit FilterHashtable](https://learn.microsoft.com/powershell/scripting/samples/creating-get-winevent-queries-with-filterhashtable) - [Microsoft Learn – wevtutil](https://learn.microsoft.com/windows-server/administration/windows-commands/wevtutil) - [Microsoft Learn – Windows-Ereignisanzeige](https://learn.microsoft.com/shows/inside/event-viewer) - [systemd – journalctl](https://www.freedesktop.org/software/systemd/man/latest/journalctl.html) - [systemd – journald.conf](https://www.freedesktop.org/software/systemd/man/latest/journald.conf.html) - [systemd – systemd-journald.service](https://www.freedesktop.org/software/systemd/man/latest/systemd-journald.service.html) - [Apple – log-Handbuchseite](https://keith.github.io/xcode-man-pages/log.1.html) - [Apple – Protokollmeldungen in der Konsole anzeigen](https://support.apple.com/de-de/guide/console/cnsl1012/mac) - [Apple – Protokollmeldungen und Aktivitäten suchen](https://support.apple.com/de-de/guide/console/cnslbf30b61a/mac) # 4.7 Dienststartfehler analysieren Ein Dienststartfehler liegt vor, wenn ein Dienst nicht gestartet werden kann, im Startvorgang hängen bleibt oder unmittelbar nach dem Start wieder beendet wird. > **Grundsatz:** > Nicht mehrfach auf „Starten“ klicken. Zuerst Status, Exitcode, Protokolle und Startkonfiguration sichern, damit die ursprüngliche Fehlerursache nicht durch Folgeereignisse verdeckt wird. --- **Ziele dieser Seite** Nach dieser Seite sollst du: - verschiedene Arten von Dienststartfehlern unterscheiden können, - Exitcodes und Beendigungsursachen erfassen können, - Programmpfad und Startparameter prüfen können, - Fehler des Dienstkontos und der Berechtigungen erkennen können, - fehlende Abhängigkeiten und Ressourcen identifizieren können, - Zeitüberschreitungen und sofortige Prozessabbrüche unterscheiden können, - Startbegrenzungen und Neustartschleifen erkennen können, - Windows-, systemd- und launchd-Startfehler analysieren können, - einen kontrollierten Startversuch vorbereiten und auswerten können. ---
1. Arten von Dienststartfehlern unterscheiden | Fehlerbild | Beschreibung | Mögliche Ursache | |---|---|---| | Dienst nicht gefunden | Dienstverwaltung kennt den Namen nicht | Falscher Name, Dienst nicht installiert oder andere Umgebung | | Dienst deaktiviert | Start wird durch Konfiguration verhindert | Bewusste Deaktivierung oder fehlerhafte Änderung | | Dienst maskiert | systemd blockiert den Start vollständig | Administrativer Schutz oder fehlerhafte Maskierung | | Programmdatei fehlt | Angegebene ausführbare Datei ist nicht vorhanden | Unvollständiges Update, Löschung oder falscher Pfad | | Zugriff verweigert | Dienst darf Programm, Datei oder Ressource nicht verwenden | Konto- oder Berechtigungsfehler | | Abhängigkeit fehlt | Benötigter Dienst oder Backend ist nicht verfügbar | Dienst-, DNS-, Netzwerk- oder Speicherfehler | | Start dauert zu lange | Dienst meldet nicht rechtzeitig Betriebsbereitschaft | Blockierte Initialisierung oder langsames Backend | | Prozess beendet sich sofort | Programm startet und bricht unmittelbar ab | Konfiguration, Portkonflikt oder fehlende Ressource | | Prozess stürzt ab | Unbehandelte Ausnahme oder schwerer Laufzeitfehler | Softwarefehler, Bibliothek oder inkompatible Version | | Neustartschleife | Dienst wird automatisch fortlaufend neu gestartet | Wiederherstellungsregel und unveränderte Fehlerursache | | Startgrenze erreicht | Dienstverwaltung unterbindet weitere Versuche | Zu viele Fehlstarts innerhalb kurzer Zeit | | Dienst läuft, ist aber nicht bereit | Prozess existiert, Initialisierung ist unvollständig | Backend, Migration, Cache oder Healthcheck |
---
2. Mindestinformationen vor einem neuen Startversuch sichern ```text [ ] Datum, Uhrzeit und Zeitzone [ ] Server und Betriebssystem [ ] Interner Dienstname beziehungsweise launchd-Label [ ] Aktueller Dienststatus [ ] Startart beziehungsweise Aktivierungszustand [ ] Prozess-ID, falls vorhanden [ ] Letzter Exitcode [ ] Dienstspezifischer Exitcode [ ] Programmpfad und Startparameter [ ] Dienstkonto [ ] Formale Abhängigkeiten [ ] Wiederherstellungs- und Neustartregeln [ ] Relevante Systemprotokolle [ ] Relevante Anwendungsprotokolle [ ] Letzte Konfigurations- oder Softwareänderung ``` > Erst nach dieser Sicherung sollte ein weiterer kontrollierter Startversuch durchgeführt werden.
---
3. Allgemeiner Diagnoseweg bei Startfehlern ```text Dienst vorhanden? ↓ Aktiviert und nicht blockiert? ↓ Programmpfad vorhanden? ↓ Startkonfiguration syntaktisch gültig? ↓ Dienstkonto gültig? ↓ Datei- und Verzeichnisrechte ausreichend? ↓ Abhängigkeiten verfügbar? ↓ Port und andere Ressourcen verfügbar? ↓ Prozess startet? ↓ Prozess bleibt aktiv? ↓ Dienst meldet Betriebsbereitschaft? ↓ Anwendungstest erfolgreich? ``` **Empfohlene Reihenfolge:** 1. Exakten Dienstnamen bestätigen. 2. Aktuellen Status erfassen. 3. Exitcode und Protokolle sichern. 4. Startart und Blockierungen prüfen. 5. Programmpfad und Argumente kontrollieren. 6. Dienstkonto und Berechtigungen prüfen. 7. Abhängigkeiten testen. 8. Portkonflikte und Ressourcen prüfen. 9. Konfiguration mit Herstellerwerkzeug validieren. 10. Einen einzelnen kontrollierten Startversuch durchführen. 11. Protokolle während dieses Versuchs beobachten. 12. Ergebnis dokumentieren und erneut bewerten.
---
4. Windows-Dienststatus und Exitcodes erfassen **Grundlegenden Dienststatus anzeigen:** ```powershell [RO] Get-Service -Name "" ``` **Erweiterte Dienstinformationen anzeigen:** ```powershell [RO] Get-CimInstance Win32_Service -Filter "Name=''" | Select-Object Name, DisplayName, State, Status, StartMode, StartName, ProcessId, ExitCode, ServiceSpecificExitCode ``` **Status mit `sc.exe` prüfen:** ```powershell [RO] sc.exe queryex "" ``` Wichtige Angaben: | Angabe | Bedeutung | |---|---| | `STATE` | Aktueller Dienstzustand | | `WIN32_EXIT_CODE` | Windows- beziehungsweise Dienstausgangscode | | `SERVICE_EXIT_CODE` | Dienstspezifischer Ausgangscode | | `CHECKPOINT` | Fortschrittswert bei längeren Zustandswechseln | | `WAIT_HINT` | Vom Dienst geschätzte Wartezeit | | `PID` | Aktuelle Prozess-ID, sofern vorhanden | > Ein Exitcode `0` ist nur dann aussagekräftig, wenn der Dienst regulär beendet wurde. Ein Dienst kann trotzdem seine vorgesehene Funktion nicht bereitgestellt haben.
---
5. Windows-Startkonfiguration prüfen **Konfiguration des Dienstes anzeigen:** ```powershell [RO][SENS] sc.exe qc "" ``` **Konfiguration über CIM anzeigen:** ```powershell [RO][SENS] Get-CimInstance Win32_Service -Filter "Name=''" | Select-Object Name, StartMode, StartName, PathName, ServiceType, DesktopInteract ``` Zu prüfen sind: | Feld | Prüffrage | |---|---| | `BINARY_PATH_NAME` beziehungsweise `PathName` | Ist der Programmpfad korrekt? | | Startparameter | Sind Argumente vollständig und korrekt maskiert? | | `SERVICE_START_NAME` beziehungsweise `StartName` | Wird das vorgesehene Dienstkonto verwendet? | | `START_TYPE` beziehungsweise `StartMode` | Ist der Dienst deaktiviert? | | `DEPENDENCIES` | Sind alle formalen Abhängigkeiten vorhanden? | | `TYPE` beziehungsweise `ServiceType` | Passt die Dienstart zur Anwendung? | **Wichtig bei Programmpfaden:** - Programmpfad und Argumente dürfen nicht verwechselt werden. - Leerzeichen im Pfad erfordern korrekte Anführungszeichen. - Relative Pfade können im Dienstkontext anders aufgelöst werden. - Ein Netzlaufwerksbuchstabe aus einer Benutzersitzung steht einem Dienst normalerweise nicht automatisch zur Verfügung. - Das Dienstkonto muss auf Programm, Arbeitsverzeichnis und Konfiguration zugreifen können.
---
6. Windows-Programmpfad kontrolliert prüfen Da `PathName` auch Argumente enthalten kann, darf die gesamte Zeichenfolge nicht ungeprüft an `Test-Path` übergeben werden. **Konfigurierte Zeichenfolge zunächst nur anzeigen:** ```powershell [RO][SENS] Get-CimInstance Win32_Service -Filter "Name=''" | Select-Object Name, PathName ``` Anschließend wird der tatsächliche ausführbare Pfad aus der Ausgabe ermittelt und separat geprüft: ```powershell [RO][FILE] Test-Path -LiteralPath "" ``` **Dateiinformationen anzeigen:** ```powershell [RO][FILE][SENS] Get-Item -LiteralPath "" | Select-Object FullName, Length, CreationTime, LastWriteTime, VersionInfo ``` **Berechtigungen anzeigen:** ```powershell [RO][FILE][SENS] Get-Acl -LiteralPath "" | Format-List ``` Zusätzlich prüfen: - Ist die Datei tatsächlich vorhanden? - Wurde sie kürzlich ersetzt oder verschoben? - Passt die Architektur zum Betriebssystem? - Sind benötigte Bibliotheken vorhanden? - Blockiert Sicherheitssoftware die Ausführung? - Liegt die Datei auf einem beim Start noch nicht verfügbaren Datenträger? - Ist der Pfad lokal oder von einer Netzwerkressource abhängig?
---
7. Windows-Dienstkonto und Anmelderechte prüfen **Dienstkonto anzeigen:** ```powershell [RO] Get-CimInstance Win32_Service -Filter "Name=''" | Select-Object Name, StartName, State, StartMode ``` Mögliche Kontotypen: - `LocalSystem`, - `NT AUTHORITY\LocalService`, - `NT AUTHORITY\NetworkService`, - virtuelles Dienstkonto, - verwaltetes Dienstkonto, - lokales Benutzerkonto, - Domänenkonto. **Zu prüfen:** - Existiert das Konto? - Ist es aktiviert oder gesperrt? - Ist ein hinterlegtes Kennwort abgelaufen oder geändert worden? - Besitzt es das Recht „Anmelden als Dienst“? - Darf es die Programmdatei lesen und ausführen? - Darf es Konfigurations- und Datenverzeichnisse verwenden? - Darf es Zertifikate und private Schlüssel verwenden? - Darf es auf Netzwerkressourcen zugreifen? - Wurde das Konto kürzlich geändert? - Funktioniert ein verwaltetes Dienstkonto ordnungsgemäß? > Ein manueller Programmstart als Administrator beweist nicht, dass das Programm unter dem tatsächlichen Dienstkonto funktioniert.
---
8. Typische Windows-Startfehler einordnen | Fehler | Typische Bedeutung | Prüfrichtung | |---|---|---| | Fehler 2 | Angegebene Datei wurde nicht gefunden | Programmpfad, Bibliothek oder Konfigurationspfad | | Fehler 5 | Zugriff verweigert | Konto, Rechte oder Sicherheitssoftware | | Fehler 1068 | Abhängigkeitsdienst oder Abhängigkeitsgruppe konnte nicht gestartet werden | Formale Abhängigkeiten | | Fehler 1069 | Anmeldung des Dienstkontos fehlgeschlagen | Konto, Kennwort und Anmelderecht | | Fehler 1053 | Dienst antwortete nicht rechtzeitig auf Start- oder Steuerungsanforderung | Initialisierung, Timeout, Programmfehler | | Fehler 1067 | Prozess wurde unerwartet beendet | Anwendungsprotokoll, Konfiguration oder Absturz | | Fehler 1079 | Konto stimmt nicht mit anderen Diensten im gemeinsamen Prozess überein | Dienstkonto und gemeinsam verwendeter Prozess | | Fehler 193 | Keine gültige Win32-Anwendung | Architektur, Dateityp oder fehlerhafte Programmdatei | > Die vollständige Fehlermeldung, das betroffene Produkt und die Windows-Version müssen immer mit dokumentiert werden. Die Tabelle ist eine Eingrenzungshilfe, kein Ersatz für die konkrete Herstellerdiagnose.
---
9. Windows-Ereignisse eines Startversuchs auswerten **Service-Control-Manager-Ereignisse der letzten Stunde:** ```powershell [RO][SENS] Get-WinEvent -FilterHashtable @{ LogName = "System" ProviderName = "Service Control Manager" StartTime = (Get-Date).AddHours(-1) } | Select-Object TimeCreated, Id, LevelDisplayName, Message ``` **Typische startbezogene Ereignisse filtern:** ```powershell [RO][SENS] Get-WinEvent -FilterHashtable @{ LogName = "System" ProviderName = "Service Control Manager" Id = 7000, 7001, 7009, 7011, 7023, 7024, 7031, 7034 StartTime = (Get-Date).AddHours(-24) } | Select-Object TimeCreated, Id, LevelDisplayName, Message ``` **System- und Anwendungsereignisse im festen Zeitfenster verbinden:** ```powershell [RO][SENS] $startTime = Get-Date "2026-07-31 09:10:00" $endTime = Get-Date "2026-07-31 09:20:00" Get-WinEvent -FilterHashtable @{ LogName = "System", "Application" StartTime = $startTime EndTime = $endTime } | Sort-Object TimeCreated | Select-Object TimeCreated, LogName, ProviderName, Id, LevelDisplayName, Message ```
---
10. Windows-Wiederherstellungsaktionen prüfen Ein Dienst kann nach einem Fehlstart oder Absturz automatisch neu gestartet werden. **Konfigurierte Fehleraktionen anzeigen:** ```powershell [RO] sc.exe qfailure "" ``` **Zusätzlichen Fehleraktionsstatus anzeigen:** ```powershell [RO] sc.exe qfailureflag "" ``` Mögliche Aktionen: - keine Aktion, - Dienst neu starten, - Programm ausführen, - Computer neu starten. **Prüffragen:** - Wird der Dienst automatisch neu gestartet? - Nach welcher Wartezeit? - Wie viele Versuche erfolgen? - Wann wird der Fehlerzähler zurückgesetzt? - Wird auch bei einem normalen Prozessende eine Fehleraktion ausgelöst? - Verändert die Wiederherstellung die sichtbare PID? - Verdeckt die Automatik einen wiederkehrenden Startfehler? > Wiederherstellungsregeln dürfen nicht ungeprüft verändert werden. Sie können die Verfügbarkeit und das Verhalten bei Abstürzen erheblich beeinflussen.
---
11. systemd-Status und Startursache unter Linux prüfen **Ausführlichen Status anzeigen:** ```bash [RO][SENS][PRIV] sudo systemctl status "" --no-pager ``` **Wichtige Zustände strukturiert anzeigen:** ```bash [RO] systemctl show "" \ --property=LoadState,ActiveState,SubState,UnitFileState,Result,MainPID,ExecMainCode,ExecMainStatus,StatusErrno,NRestarts ``` **Prüfen, ob die Unit aktiviert ist:** ```bash [RO] systemctl is-enabled "" ``` **Prüfen, ob sie fehlgeschlagen ist:** ```bash [RO] systemctl is-failed "" ``` **Alle fehlgeschlagenen Units anzeigen:** ```bash [RO] systemctl --failed --no-pager ``` **Wichtige Angaben:** | Eigenschaft | Bedeutung | |---|---| | `LoadState` | Wurde die Unit korrekt geladen? | | `ActiveState` | Übergeordneter Aktivzustand | | `SubState` | Detaillierter Unterzustand | | `Result` | Ergebnis des letzten Start- oder Laufvorgangs | | `MainPID` | PID des Hauptprozesses | | `ExecMainCode` | Art der Prozessbeendigung | | `ExecMainStatus` | Exitcode oder Signalnummer | | `StatusErrno` | Gemeldeter Fehlerwert, sofern vorhanden | | `NRestarts` | Anzahl automatischer Neustarts |
---
12. systemd-Ergebniswerte interpretieren Mögliche `Result`-Werte können unter anderem sein: | Ergebnis | Typische Bedeutung | |---|---| | `success` | Vorgang wurde aus Sicht von systemd erfolgreich beendet | | `exit-code` | Prozess beendete sich mit nicht als erfolgreich bewertetem Exitcode | | `signal` | Prozess wurde durch ein Signal beendet | | `core-dump` | Prozess wurde durch Signal beendet und erzeugte einen Core Dump | | `timeout` | Start-, Stopp- oder Laufzeitgrenze wurde überschritten | | `watchdog` | Watchdog-Reaktion blieb aus | | `start-limit-hit` | Zu viele Startversuche in kurzer Zeit | | `resources` | Benötigte Systemressource konnte nicht bereitgestellt werden | | `protocol` | Dienst erfüllte das erwartete Startprotokoll nicht | | `dependency` | Eine benötigte Unit schlug fehl | | `exec-condition` | Eine konfigurierte Startbedingung verhinderte den Start | **Beendigungsart:** | `ExecMainCode` | Grundbedeutung | |---|---| | `exited` | Prozess beendete sich über einen Exitcode | | `killed` | Prozess wurde durch ein Signal beendet | | `dumped` | Prozess wurde durch Signal beendet und erzeugte möglicherweise einen Dump | > Die konkrete Bedeutung von `ExecMainStatus` hängt davon ab, ob der Prozess regulär beendet oder durch ein Signal beendet wurde. Zusätzlich muss die Dokumentation des Programms geprüft werden.
---
13. systemd-Unit und wirksame Startparameter prüfen **Wirksame Unit einschließlich Drop-ins anzeigen:** ```bash [RO][FILE][SENS] systemctl cat "" ``` **Wichtige Startparameter strukturiert anzeigen:** ```bash [RO][SENS] systemctl show "" \ --property=Type,User,Group,ExecStart,ExecStartPre,ExecStartPost,WorkingDirectory,EnvironmentFiles,FragmentPath,DropInPaths ``` **Unit-Datei formal prüfen:** ```bash [RO][FILE] systemd-analyze verify "" ``` Zu prüfen sind: - `Type=`, - `ExecStart=`, - `ExecStartPre=`, - `ExecStartPost=`, - `User=` und `Group=`, - `WorkingDirectory=`, - `EnvironmentFile=`, - `PIDFile=`, - `RuntimeDirectory=`, - `StateDirectory=`, - `TimeoutStartSec=`, - `Restart=`, - `RestartSec=`, - `StartLimitIntervalSec=`, - `StartLimitBurst=`. > `systemd-analyze verify` benötigt den tatsächlichen Pfad einer Unit-Datei. Der Pfad sollte mit `systemctl show --property=FragmentPath` ermittelt werden.
---
14. Linux-Programmpfad und Berechtigungen prüfen **Konfigurierten Startbefehl anzeigen:** ```bash [RO][SENS] systemctl show "" --property=ExecStart ``` **Datei des bekannten Programmpfads prüfen:** ```bash [RO][FILE] stat "" ``` **Dateityp und Architektur prüfen:** ```bash [RO][FILE] file "" ``` **Berechtigungen aller Pfadbestandteile anzeigen:** ```bash [RO][FILE] namei -l "" ``` **Dynamische Bibliotheksabhängigkeiten eines geeigneten dynamischen ELF-Programms anzeigen:** ```bash [RO][FILE][SENS] ldd "" ``` **Wichtiger Sicherheitshinweis:** `ldd` sollte nicht ungeprüft auf nicht vertrauenswürdige ausführbare Dateien angewendet werden. Abhängig von System und Binärdatei kann die Auswertung Sicherheitsrisiken besitzen. Alternativ kann bei ELF-Dateien zunächst statisch geprüft werden: ```bash [RO][FILE] readelf -d "" ``` Zu prüfen: - Datei vorhanden, - ausführbar, - richtige Architektur, - korrekter Interpreter, - benötigte Bibliotheken vorhanden, - Dienstkonto kann alle Pfadbestandteile durchlaufen, - Arbeitsverzeichnis vorhanden, - Dateisystem nicht schreibgeschützt, - Sicherheitsmechanismen wie SELinux oder AppArmor berücksichtigt.
---
15. Linux-Dienstkonto und Dienstkontext prüfen **Konfiguriertes Konto anzeigen:** ```bash [RO] systemctl show "" --property=User,Group,DynamicUser ``` **Benutzerkonto prüfen:** ```bash [RO] getent passwd "" ``` **Gruppenmitgliedschaften anzeigen:** ```bash [RO] id "" ``` **Arbeitsverzeichnis prüfen:** ```bash [RO] systemctl show "" --property=WorkingDirectory ``` **Referenzierte Umgebungsdateien anzeigen:** ```bash [RO][SENS] systemctl show "" --property=EnvironmentFiles ``` Zu prüfen: - Existiert der Dienstbenutzer? - Existiert die konfigurierte Gruppe? - Sind Dateirechte ausreichend? - Ist ein dynamischer Benutzer vorgesehen? - Existiert das Arbeitsverzeichnis? - Kann das Konto Konfigurations- und Datendateien lesen? - Kann es in erforderliche Verzeichnisse schreiben? - Kann es privilegierte Ports oder Geräte verwenden? - Blockieren SELinux, AppArmor oder systemd-Sandboxing den Zugriff? - Sind Secrets für den Dienstkontext verfügbar? > Das Starten des Programms als `root` ist kein gültiger Nachweis für die Funktion unter dem tatsächlichen Dienstkonto.
---
16. systemd-Protokolle eines Startfehlers auswerten **Protokolle des aktuellen Systemstarts:** ```bash [RO][SENS][PRIV] sudo journalctl \ -b \ -u "" \ --no-pager ``` **Letzte 100 Einträge:** ```bash [RO][SENS][PRIV] sudo journalctl \ -u "" \ -n 100 \ --output=short-iso \ --no-pager ``` **Fehler und schwerwiegendere Meldungen:** ```bash [RO][SENS][PRIV] sudo journalctl \ -u "" \ -p err \ --since "1 hour ago" \ --no-pager ``` **Dienst- und Systemmeldungen im selben Zeitfenster:** ```bash [RO][SENS][PRIV] sudo journalctl \ --since "2026-07-31 09:10:00" \ --until "2026-07-31 09:20:00" \ --output=short-iso \ --no-pager ``` **Kernelmeldungen berücksichtigen:** ```bash [RO][SENS][PRIV] sudo journalctl \ -k \ -b \ -p warning \ --no-pager ```
---
17. systemd-Neustartschleife und Startbegrenzung erkennen **Neustartregeln anzeigen:** ```bash [RO] systemctl show "" \ --property=Restart,RestartUSec,NRestarts ``` **Startbegrenzung anzeigen:** ```bash [RO] systemctl show "" \ --property=StartLimitIntervalUSec,StartLimitBurst,Result ``` Anzeichen: - `NRestarts` steigt, - PID wechselt fortlaufend, - Prozesslaufzeit bleibt sehr kurz, - `Result=start-limit-hit`, - Journal zeigt wiederholte identische Startfehler, - Dienst ist zwischen den Versuchen kurz erreichbar, - Healthcheck schlägt fortlaufend fehl. **Fehlerstatus erst nach der Beweissicherung zurücksetzen:** ```bash [CHANGE][PRIV] sudo systemctl reset-failed "" ``` `reset-failed`: - startet den Dienst nicht, - löscht aber den gespeicherten Fehlerzustand, - setzt bestimmte Zähler für Startbegrenzungen zurück, - verändert damit Diagnosezustand. > Dieser Befehl darf deshalb erst nach Dokumentation von `Result`, `NRestarts`, Status und Journal verwendet werden.
---
18. systemd-Diensttypen als mögliche Fehlerursache prüfen | `Type=` | Erwartetes Verhalten | |---|---| | `simple` | Gestarteter Prozess gilt unmittelbar als Hauptprozess | | `exec` | Start gilt nach erfolgreichem Ausführen des Programms als erfolgt | | `forking` | Programm erzeugt Hintergrundprozess; häufig mit PID-Datei | | `oneshot` | Prozess führt Aufgabe aus und beendet sich wieder | | `notify` | Dienst meldet systemd ausdrücklich Betriebsbereitschaft | | `dbus` | Bereitschaft hängt von einem D-Bus-Namen ab | | `idle` | Ausführung wird verzögert, bis andere Jobs abgearbeitet sind | Mögliche Fehlkonfigurationen: - `forking` verwendet falsche oder fehlende PID-Datei, - `notify`-Dienst sendet keine Bereitschaftsmeldung, - `oneshot` wird fälschlich als dauerhaft laufender Prozess erwartet, - Programm forkt, obwohl `Type=simple` ungeeignet konfiguriert wurde, - Wrapperprozess beendet sich und systemd überwacht nicht den erwarteten Prozess, - Startbefehl blockiert und erreicht den vorgesehenen Zustand nicht. > Der korrekte Diensttyp muss anhand der Programmdokumentation und des tatsächlichen Prozessverhaltens bestimmt werden.
---
19. launchd-Status und letzten Exitstatus unter macOS prüfen **Systemweiten Dienst prüfen:** ```bash [RO] launchctl print "system/
---
20. launchd-Konfiguration unter macOS prüfen **Bekannte systemweite plist anzeigen:** ```bash [RO][FILE][SENS] plutil -p "/Library/LaunchDaemons/
---
21. macOS-Programmpfad und Berechtigungen prüfen **Programmdatei prüfen:** ```bash [RO][FILE] stat "" ``` **Dateityp und Architektur anzeigen:** ```bash [RO][FILE] file "" ``` **Berechtigungen und erweiterte Zugriffslisten anzeigen:** ```bash [RO][FILE][SENS] ls -lde "" ``` **Code-Signatur anzeigen und prüfen:** ```bash [RO][FILE][SENS] codesign \ --verify \ --deep \ --strict \ --verbose=2 \ "" ``` **Gatekeeper-Bewertung für einen geeigneten Anwendungstyp prüfen:** ```bash [RO][FILE][SENS] spctl \ --assess \ --type execute \ --verbose=4 \ "" ``` **Hinweise:** - `codesign` prüft die Signatur, beweist aber nicht die vollständige Dienstfunktion. - `spctl` ist nicht für jede Art von Binärdatei gleich aussagekräftig. - Datenschutz- und Sicherheitsmechanismen können den Zugriff eines Daemons einschränken. - Ein erfolgreicher Start im Terminal beweist nicht die Funktion innerhalb der launchd-Domain.
---
22. macOS-Protokolle eines Startfehlers auswerten **Nach Prozess suchen:** ```bash [RO][SENS][PRIV] sudo log show \ --last 1h \ --predicate 'process == ""' \ --style compact \ --no-pager ``` **Nach launchd- und Prozessmeldungen suchen:** ```bash [RO][SENS][PRIV] sudo log show \ --last 1h \ --predicate 'process == "launchd" OR process == ""' \ --style compact \ --no-pager ``` **Fehler und Faults anzeigen:** ```bash [RO][SENS][PRIV] sudo log show \ --last 1h \ --predicate '(process == "launchd" OR process == "") AND (messageType == error OR messageType == fault)' \ --style compact \ --no-pager ``` **Live-Beobachtung während eines kontrollierten Startversuchs:** ```bash [TEST][SENS][PRIV] sudo log stream \ --timeout 5m \ --predicate 'process == "launchd" OR process == ""' \ --style compact ```
---
23. launchctl-Fehlercode unter macOS übersetzen Wenn ein `launchctl`-Befehl einen numerischen Fehlercode liefert, kann dieser mit `launchctl error` lesbarer dargestellt werden. **Automatische Einordnung versuchen:** ```bash [RO] launchctl error ``` **POSIX-Fehlerbereich angeben:** ```bash [RO] launchctl error posix ``` **Mach-Fehlerbereich angeben:** ```bash [RO] launchctl error mach ``` **Bootstrap-Fehlerbereich angeben:** ```bash [RO] launchctl error bootstrap ``` > Die übersetzte Meldung beschreibt den technischen Fehlerbereich. Die konkrete Ursache muss weiterhin anhand von plist, Programmpfad, Berechtigungen und Protokollen bestimmt werden.
---
24. Kontrollierten Startversuch durchführen Ein Startversuch verändert den Dienstzustand und kann Folgeprozesse, Netzwerkverbindungen oder automatische Wiederherstellungsaktionen auslösen. | Betriebssystem | Startbefehl | |---|---| | Windows | `[CHANGE][PRIV] Start-Service -Name ""` | | Linux | `[CHANGE][PRIV] sudo systemctl start ""` | | macOS systemweit | `[CHANGE][PRIV] sudo launchctl kickstart "system/
---
25. Manuellen Programmstart nur kontrolliert verwenden Ein direkter Programmstart kann zusätzliche Fehlermeldungen auf der Konsole sichtbar machen. Er ist aber nicht automatisch sicher oder mit dem Dienststart gleichwertig. Vorher prüfen: - erlaubt der Hersteller einen Konsolen- oder Vordergrundmodus? - ist der Dienstprozess wirklich beendet? - würde eine zweite Instanz denselben Port oder dieselben Dateien verwenden? - werden beim Start Datenbanken oder Dateien verändert? - welches Benutzerkonto muss verwendet werden? - welche Umgebungsvariablen setzt die Dienstverwaltung? - welches Arbeitsverzeichnis wird erwartet? - welche Limits und Sicherheitsrichtlinien gelten? - existiert ein ausdrücklich dokumentierter Diagnoseparameter? **Der manuelle Start kann sich unterscheiden durch:** | Eigenschaft | Dienststart | Manueller Start | |---|---|---| | Benutzerkonto | Dienstkonto | Aktueller Terminalbenutzer | | Arbeitsverzeichnis | Konfiguriert oder systemabhängig | Aktuelles Verzeichnis | | Umgebungsvariablen | Dienstspezifisch | Shell- beziehungsweise Benutzervariablen | | Berechtigungen | Dienstkontext | Benutzer- oder Administratorkontext | | Netzwerkressourcen | Dienstabhängig | Benutzersitzung | | Sicherheitsrichtlinien | Dienstmanager und Sandbox | Terminalkontext | | Standardausgabe | Journal, Datei oder Ereignisprotokoll | Terminal | > Deshalb wird kein generischer Direktstartbefehl verwendet. Der korrekte Diagnosemodus muss aus der offiziellen Dokumentation der jeweiligen Anwendung stammen.
---
26. Häufige technische Ursachen eines sofortigen Abbruchs - Syntaxfehler in der Konfiguration, - fehlende Konfigurationsdatei, - falscher Programmpfad, - fehlende Bibliothek oder Laufzeitumgebung, - falsche Prozessorarchitektur, - Port bereits belegt, - ungültiges Zertifikat oder fehlender privater Schlüssel, - Dienstkonto besitzt keine Leserechte, - Datenverzeichnis ist nicht beschreibbar, - Volume oder Netzfreigabe fehlt, - Datenbank nicht erreichbar, - DNS-Auflösung fehlerhaft, - Umgebungsvariable fehlt, - Secret oder Kennwort ungültig, - Lizenz fehlt oder ist abgelaufen, - Datenmigration ist fehlgeschlagen, - PID-Datei kann nicht erstellt werden, - Sperrdatei einer alten Instanz ist vorhanden, - Sicherheitssoftware blockiert die Ausführung, - Speicher oder Dateideskriptoren sind erschöpft.
---
27. Zeitüberschreitung beim Dienststart analysieren Ein Timeout bedeutet zunächst, dass ein erwarteter Zustand nicht innerhalb der vorgesehenen Zeit erreicht wurde. Mögliche Ursachen: - DNS-Abfrage dauert zu lange, - Datenbank ist nicht bereit, - Netzwerkspeicher antwortet nicht, - Anwendung führt eine lange Migration durch, - Dienst wartet auf eine gesperrte Datei, - Portbindung blockiert, - Dienst meldet seine Bereitschaft nicht korrekt, - Diensttyp passt nicht zum Programmverhalten, - Hardware oder Datenträger ist langsam, - Entschlüsselung oder Zertifikatsprüfung hängt, - Dienst wartet auf interaktive Eingabe, - Endlosschleife während der Initialisierung. **Prüfung:** ```text 1. Startzeit genau feststellen 2. Letzte Meldung vor dem Timeout ermitteln 3. Prozesszustand während des Wartens prüfen 4. CPU- und I/O-Verhalten beobachten 5. Netzwerkverbindungen des Prozesses prüfen 6. Abhängigkeiten direkt testen 7. Herstellerdokumentation zur Initialisierung prüfen 8. Timeout nicht erhöhen, bevor die Warteursache bekannt ist ``` > Eine Vergrößerung des Timeouts kann einen langsamen, aber legitimen Start ermöglichen. Sie kann jedoch ebenso einen eigentlichen Fehler nur länger verbergen.
---
28. Portkonflikt als Startursache prüfen **Windows:** ```powershell [RO] Get-NetTCPConnection ` -State Listen ` -LocalPort ` -ErrorAction SilentlyContinue | Select-Object LocalAddress, LocalPort, OwningProcess ``` **Linux:** ```bash [RO][PRIV] sudo ss -lntp "sport = :" ``` **macOS:** ```bash [RO][PRIV] sudo lsof \ -nP \ -iTCP: \ -sTCP:LISTEN ``` Wenn der Port belegt ist: 1. PID feststellen. 2. Prozessname bestimmen. 3. Dienstzuordnung prüfen. 4. Bindungsadresse kontrollieren. 5. Prüfen, ob eine alte Instanz läuft. 6. Container- oder Proxybelegung berücksichtigen. 7. Keinen Prozess ungeprüft beenden. 8. Sollkonfiguration und letzte Änderungen prüfen.
---
29. Ressourcenmangel als Startursache prüfen | Aufgabe | Windows | Linux | macOS | |---|---|---|---| | Freier Speicherplatz | `[RO] Get-Volume` | `[RO] df -hT` | `[RO] df -h` | | Arbeitsspeicher | `[RO] Get-CimInstance Win32_OperatingSystem \| Select-Object TotalVisibleMemorySize,FreePhysicalMemory` | `[RO] free -h` | `[RO] vm_stat` | | Prozessübersicht | `[RO] Get-Process \| Sort-Object WorkingSet64 -Descending` | `[RO] top` | `[RO] top -o mem` | | Dateisystemzustand | `[RO] Get-Volume` | `[RO] findmnt` | `[RO] mount` | | Offene Dateien des Prozesses | Betriebssystemspezifische Prozesswerkzeuge | `[RO][PRIV] sudo lsof -p ` | `[RO][PRIV] sudo lsof -p ` | Mögliche Startfehler: - Datenträger vollständig belegt, - keine freien Inodes unter Linux, - Arbeitsspeicher erschöpft, - Auslagerung überlastet, - Dateisystem schreibgeschützt, - maximales Prozesslimit erreicht, - Dateideskriptorlimit erreicht, - temporäres Verzeichnis nicht verfügbar, - Laufzeitverzeichnis kann nicht erstellt werden.
---
30. Letzte Änderungen priorisiert untersuchen Besonders relevant sind Änderungen an: - Programmversion, - Dienstdatei oder plist, - Windows-Dienstkonfiguration, - systemd-Unit oder Drop-in, - Dienstkonto oder Kennwort, - Dateiberechtigungen, - Zertifikaten, - Port und Bindungsadresse, - Firewall, - Datenbankversion oder Schema, - Bibliotheken und Laufzeitumgebung, - Umgebungsvariablen, - Secrets, - Mounts und Volumes, - Containern oder Images, - Sicherheitssoftware, - Betriebssystemupdates. **Zeitlicher Vergleich:** ```text Letzter erfolgreicher Start → Änderung → erster fehlgeschlagener Start ``` > Ein zeitlicher Zusammenhang ist ein starker Hinweis, aber noch kein Beweis. Die betroffene Konfiguration oder Komponente muss technisch geprüft werden.
---
31. Typische Fehlinterpretationen | Fehlinterpretation | Richtige Bewertung | |---|---| | „Der Startknopf zeigt einen Fehler, also ist Windows beziehungsweise systemd defekt.“ | Die Dienstverwaltung meldet häufig nur den Fehler des gestarteten Programms | | „Exitcode 0 bedeutet, der Dienst funktioniert.“ | Nur die gemeldete Beendigung wurde als erfolgreich bewertet | | „Der Prozess war kurz sichtbar, also startete der Dienst erfolgreich.“ | Er kann während der Initialisierung abgebrochen sein | | „Manueller Start als Administrator funktioniert, also stimmen die Dienstrechte.“ | Der Dienst verwendet einen anderen Kontext | | „Mehr Startversuche erhöhen die Chance auf Erfolg.“ | Sie können Protokolle überlagern und Startbegrenzungen auslösen | | „Timeout erhöhen löst den Fehler.“ | Die eigentliche Warteursache bleibt möglicherweise bestehen | | „Die Konfigurationsdatei ist syntaktisch gültig, also ist sie fachlich korrekt.“ | Pfade, Konten und Backends können weiterhin falsch sein | | „Der Port ist frei, also muss der Dienst starten.“ | Viele weitere Startvoraussetzungen bleiben ungeprüft | | „Ein Neustartzähler beweist einen Softwarefehler.“ | Auch fehlende Abhängigkeiten oder Rechte können Wiederholungen auslösen | | „Fehlerstatus zurücksetzen repariert den Dienst.“ | Nur gespeicherter Zustand und Zähler werden zurückgesetzt |
---
32. Checkliste zur Analyse eines Dienststartfehlers ```text [ ] Exakten Dienstnamen beziehungsweise Label bestätigt [ ] Richtigen Server und richtige Umgebung bestätigt [ ] Aktuellen Status gesichert [ ] Exitcode und dienstspezifischen Exitcode erfasst [ ] Relevante Protokolle vor neuem Startversuch gesichert [ ] Startart und Deaktivierung geprüft [ ] systemd-Maskierung beziehungsweise launchd-Override geprüft [ ] Programmpfad und Startparameter geprüft [ ] Programmdatei vorhanden [ ] Dateityp und Architektur geprüft [ ] Dienstkonto und Gruppe geprüft [ ] Datei- und Verzeichnisrechte geprüft [ ] Arbeitsverzeichnis geprüft [ ] Umgebungs- und Konfigurationsdateien ermittelt [ ] Formale Abhängigkeiten geprüft [ ] Externe Backends geprüft [ ] Portkonflikt ausgeschlossen [ ] Speicherplatz und Arbeitsspeicher geprüft [ ] Neustartregeln und Startbegrenzungen geprüft [ ] Letzte Änderungen erfasst [ ] Genau einen kontrollierten Startversuch durchgeführt [ ] Prozess, PID und Laufzeit danach geprüft [ ] Listener und Anwendungsfunktion geprüft [ ] Ursache, Maßnahme und Ergebnis dokumentiert ```
--- **Bewertung des Ergebnisses** | Ergebnis | Nächster Schritt | |---|---| | Dienst nicht vorhanden | Installation, Dienstname und Zielsystem prüfen | | Dienst deaktiviert oder maskiert | Grund und Sollzustand vor Änderung klären | | Programmdatei fehlt | Installation, Update und Dateisystem untersuchen | | Zugriff verweigert | Dienstkonto, Rechte und Sicherheitsrichtlinien prüfen | | Abhängigkeit schlägt fehl | Betroffene Abhängigkeit separat analysieren | | Port ist belegt | Besitzenden Prozess und Konfiguration untersuchen | | Konfiguration ist ungültig | Fehlerstelle mit Herstellerwerkzeug bestimmen | | Prozess beendet sich mit Exitcode | Produktspezifische Bedeutung des Codes prüfen | | Prozess wird durch Signal beendet | Signalursache, Ressourcen und Absturzdiagnose prüfen | | Start läuft in Timeout | Letzte Initialisierungsphase und Abhängigkeiten untersuchen | | Startgrenze wurde erreicht | Fehlerzustand sichern und Grund der Fehlstarts beheben | | Dienst startet und bleibt aktiv | Listener und Anwendungstest durchführen | --- **Merksatz** > **Ein Dienststartfehler ist selten mit einem weiteren Startversuch erklärt. Entscheidend ist die erste Phase, in der Sollzustand und tatsächlicher Startablauf voneinander abweichen.** --- **Weiterführende Quellen** - [Microsoft Learn – Win32_Service](https://learn.microsoft.com/windows/win32/cimwin32prov/win32-service) - [Microsoft Learn – sc.exe query](https://learn.microsoft.com/de-de/windows-server/administration/windows-commands/sc-query) - [Microsoft Learn – sc.exe qc](https://learn.microsoft.com/windows-server/administration/windows-commands/sc-qc) - [Microsoft Learn – sc.exe qfailure](https://learn.microsoft.com/windows-server/administration/windows-commands/sc-qfailure) - [Microsoft Learn – Get-WinEvent](https://learn.microsoft.com/powershell/module/microsoft.powershell.diagnostics/get-winevent) - [systemd – systemctl](https://www.freedesktop.org/software/systemd/man/latest/systemctl.html) - [systemd – systemd.service](https://www.freedesktop.org/software/systemd/man/latest/systemd.service.html) - [systemd – systemd.exec](https://www.freedesktop.org/software/systemd/man/latest/systemd.exec.html) - [systemd – systemd-analyze](https://www.freedesktop.org/software/systemd/man/latest/systemd-analyze.html) - [systemd – journalctl](https://www.freedesktop.org/software/systemd/man/latest/journalctl.html) - [Apple – launchctl-Handbuchseite](https://keith.github.io/xcode-man-pages/launchctl.1.html) - [Apple – launchd.plist-Handbuchseite](https://keith.github.io/xcode-man-pages/launchd.plist.5.html) - [Apple – plutil-Handbuchseite](https://keith.github.io/xcode-man-pages/plutil.1.html) - [Apple – log-Handbuchseite](https://keith.github.io/xcode-man-pages/log.1.html) # 4.8 Konfigurationsfehler untersuchen Ein Dienst kann installiert, gestartet und über den vorgesehenen Port erreichbar sein, aber aufgrund einer fehlerhaften oder veralteten Konfiguration trotzdem nicht richtig funktionieren. > **Grundsatz:** > Nicht irgendeine Konfigurationsdatei prüfen, sondern zuerst feststellen, welche Konfiguration der laufende Dienst tatsächlich verwendet. --- **Ziele dieser Seite** Nach dieser Seite sollst du: - Konfigurationsquelle und wirksame Konfiguration unterscheiden können, - Syntax- und Inhaltsfehler getrennt untersuchen können, - Konfigurationshierarchien und Überschreibungen erkennen können, - Dateipfade, Eigentümer und Berechtigungen prüfen können, - Umgebungsvariablen und Startparameter berücksichtigen können, - Konfigurationsstände sicher vergleichen können, - Hashwerte und Änderungszeitpunkte erfassen können, - versionsabhängige Konfigurationsfehler erkennen können, - Änderungen kontrolliert vorbereiten und rückgängig machen können, - Geheimnisse in Konfigurationsdateien schützen können. ---
1. Arten von Konfigurationsfehlern unterscheiden | Fehlerart | Beispiel | |---|---| | Syntaxfehler | Fehlende Klammer oder ungültiges Trennzeichen | | Tippfehler | Falscher Schlüsselname oder Hostname | | Datentypfehler | Text statt Zahl oder `true` statt erwarteter Zeichenfolge | | Wertebereichsfehler | Port außerhalb des gültigen Bereichs | | Fehlender Pflichtwert | Datenbankadresse nicht angegeben | | Falscher Dateipfad | Zertifikat oder Datenverzeichnis nicht gefunden | | Falsche Berechtigung | Dienstkonto kann Datei nicht lesen | | Falsche Eigentümerschaft | Datei gehört nicht dem vorgesehenen Konto | | Überschreibung | Lokales Drop-in ersetzt den erwarteten Wert | | Versionskonflikt | Option wird von neuer Version nicht mehr unterstützt | | Formatfehler | JSON, XML, YAML oder plist ist formal ungültig | | Kodierungsfehler | Falsche Zeichenkodierung oder Byte Order Mark | | Zeilenendefehler | Windows-Zeilenenden stören ein Unix-Werkzeug | | Umgebungsfehler | Variable ist im Terminal, aber nicht im Dienstkontext vorhanden | | Geheimnisfehler | Kennwort, Token oder Schlüssel fehlt beziehungsweise ist abgelaufen | | Zielsystemfehler | Konfiguration zeigt auf Test- statt Produktivsystem | | Reihenfolgefehler | Spätere Datei überschreibt eine frühere Einstellung | | Neustart fehlt | Datei wurde geändert, Dienst verwendet aber noch alten Zustand | | Reload ungeeignet | Dienst unterstützt kein dynamisches Neuladen | | Konfiguration nicht eingebunden | Bearbeitete Datei wird vom Dienst gar nicht geladen |
---
2. Konfigurationsquelle und wirksame Konfiguration unterscheiden Eine Anwendung kann Einstellungen aus mehreren Quellen beziehen: ```text Programmstandardwerte → Hauptkonfigurationsdatei → eingebundene Zusatzdateien → lokale Überschreibungen → Umgebungsvariablen → Startparameter → zentrale Konfigurationsverwaltung → zur Laufzeit gespeicherte Einstellungen ``` Später ausgewertete Quellen können frühere Werte überschreiben. Die genaue Priorität ist produktspezifisch. | Begriff | Bedeutung | |---|---| | Standardwert | Vom Programm verwendeter Wert ohne eigene Konfiguration | | Quelldatei | Datei, in der eine Einstellung gespeichert ist | | Include | Zusätzlich geladene Konfigurationsdatei | | Drop-in | Ergänzende oder überschreibende Konfiguration | | Startparameter | Beim Programmstart übergebener Wert | | Umgebungsvariable | Einstellung aus dem Prozesskontext | | Wirksame Konfiguration | Tatsächlich vom Dienst verwendeter Gesamtzustand | | Laufzeitkonfiguration | Nach dem Start möglicherweise intern veränderter Zustand | > Eine korrekt aussehende Hauptdatei beweist nicht, dass ihr Wert tatsächlich wirksam ist.
---
3. Vor jeder Prüfung den Konfigurationspfad belegen Der Konfigurationspfad sollte aus mindestens einer belastbaren Quelle stammen: 1. offizielle Herstellerdokumentation, 2. Dienststartparameter, 3. systemd-Unit beziehungsweise launchd-plist, 4. Windows-Dienstkonfiguration, 5. Anwendungsausgabe zur wirksamen Konfiguration, 6. Installations- oder Deploymentdokumentation, 7. Containerdefinition, 8. Protokollmeldung beim Dienststart. **Nicht ausreichend:** - vermuteter Standardpfad, - Dateiname einer anderen Installation, - alte Internetanleitung, - Konfiguration aus einer anderen Produktversion, - gleichnamige Datei im Benutzerverzeichnis. **Zu dokumentieren:** ```text Dienst: Produkt und Version: Konfigurationsquelle: Tatsächlicher Pfad: Weitere Includes: Umgebungsdateien: Startparameter: Konfigurationspriorität: Zeitpunkt der Prüfung: ```
---
4. Konfigurationsquelle unter Windows ermitteln **Dienstpfad und Startparameter anzeigen:** ```powershell [RO][SENS] Get-CimInstance Win32_Service -Filter "Name=''" | Select-Object Name, StartName, PathName ``` **Alternative mit sc.exe:** ```powershell [RO][SENS] sc.exe qc "" ``` Anschließend sind zu prüfen: - enthält `PathName` einen Konfigurationsparameter? - wird ein Arbeitsverzeichnis vorausgesetzt? - verweist der Dienst auf einen Wrapper oder Launcher? - liest der Wrapper eine weitere Konfiguration? - wird eine Java-, .NET- oder Skript-Laufzeit aufgerufen? - stammen Einstellungen aus der Registrierung? - verwendet die Anwendung ein eigenes Windows-Ereignisprotokoll? - existieren lokale und globale Konfigurationsdateien? > Programmpfad und Argumente werden in `PathName` gemeinsam dargestellt. Sie müssen bei der Auswertung sorgfältig getrennt werden.
---
5. Konfigurationsquelle unter Linux mit systemd ermitteln **Wirksame Unit und Drop-ins anzeigen:** ```bash [RO][FILE][SENS] systemctl cat "" ``` **Wichtige Pfade und Startparameter anzeigen:** ```bash [RO][SENS] systemctl show "" \ --property=FragmentPath,DropInPaths,ExecStart,WorkingDirectory,EnvironmentFiles ``` **Umgebungswerte anzeigen:** ```bash [RO][SENS] systemctl show "" --property=Environment ``` **Systemweite Konfigurationsdateien eines systemd-Bestandteils zusammenführen:** ```bash [RO][FILE] systemd-analyze cat-config "" ``` `systemd-analyze cat-config` ist für unterstützte Konfigurationshierarchien von systemd-Komponenten gedacht. Es ist kein universeller Parser für beliebige Anwendungen. **Zu prüfen:** - welche Unit-Datei wurde geladen? - existieren lokale Drop-ins? - wird eine Umgebungsdatei verwendet? - überschreibt `ExecStart` einen Paketstandard? - wird ein Wrapper oder Startskript verwendet? - enthält der Dienst einen Konfigurationsparameter? - wird die Konfiguration über mehrere Dateien zusammengesetzt?
---
6. Konfigurationsquelle unter macOS ermitteln **Systemweiten launchd-Job anzeigen:** ```bash [RO] launchctl print "system/
---
7. Dateiexistenz und Metadaten vergleichen | Aufgabe | Windows | Linux | macOS | |---|---|---|---| | Existenz prüfen | `[RO][FILE] Test-Path -LiteralPath ""` | `[RO][FILE] test -f ""` | `[RO][FILE] test -f ""` | | Metadaten anzeigen | `[RO][FILE] Get-Item -LiteralPath ""` | `[RO][FILE] stat ""` | `[RO][FILE] stat ""` | | Dateityp prüfen | `[RO][FILE] Get-Item -LiteralPath "" \| Select-Object FullName,Length,Extension` | `[RO][FILE] file ""` | `[RO][FILE] file ""` | | Eigentümer und Rechte | `[RO][FILE][SENS] Get-Acl -LiteralPath ""` | `[RO][FILE] stat -c '%U %G %A %a %n' ""` | `[RO][FILE] stat -f '%Su %Sg %Sp %N' ""` | | Symbolischen Link anzeigen | `[RO][FILE] Get-Item -LiteralPath "" \| Select-Object FullName,LinkType,Target` | `[RO][FILE] readlink ""` | `[RO][FILE] readlink ""` | **Zu prüfen:** - existiert die Datei? - ist es wirklich eine reguläre Datei? - handelt es sich um einen symbolischen Link? - zeigt der Link auf das erwartete Ziel? - stimmen Eigentümer und Gruppe? - ist die Datei leer oder ungewöhnlich klein? - wurde sie zum Störungszeitpunkt verändert? - liegt sie auf dem erwarteten Dateisystem? - kann das Dienstkonto alle übergeordneten Verzeichnisse durchlaufen? > Ein Änderungszeitpunkt beweist nur, dass sich Dateimetadaten oder Dateiinhalt geändert haben. Er beweist nicht, wer die fachliche Änderung vorgenommen hat.
---
8. Berechtigungen aller Pfadbestandteile prüfen Ein Dienst benötigt nicht nur Rechte auf die Datei selbst. Er muss auch die übergeordneten Verzeichnisse erreichen können. **Windows – Datei und übergeordnetes Verzeichnis:** ```powershell [RO][FILE][SENS] Get-Acl -LiteralPath "" | Format-List ``` ```powershell [RO][FILE][SENS] Get-Acl -LiteralPath "" | Format-List ``` **Linux – vollständigen Pfad zerlegen:** ```bash [RO][FILE] namei -l "" ``` **Linux – ACL anzeigen:** ```bash [RO][FILE][SENS] getfacl "" ``` `getfacl` ist nicht auf jeder Minimalinstallation vorhanden. **macOS – Datei und erweiterte ACL anzeigen:** ```bash [RO][FILE][SENS] ls -lde "" ``` **macOS – alle Pfadbestandteile prüfen:** ```bash [RO][FILE] ls -lde "" "" ``` Mögliche Fehler: - Datei ist lesbar, aber Verzeichnis nicht durchsuchbar, - Dienstkonto darf Konfiguration lesen, aber keine temporäre Datei erzeugen, - Konfiguration verweist auf ein nicht zugängliches Zertifikat, - ACL widerspricht den einfachen Dateirechten, - Eigentümer wurde bei einer Wiederherstellung verändert, - Datei liegt auf einem schreibgeschützten Volume.
---
9. Hashwert einer Konfiguration erfassen Ein kryptografischer Hashwert hilft festzustellen, ob zwei Dateien denselben Inhalt besitzen. Er zeigt nicht, welcher Inhalt fachlich richtig ist. | Betriebssystem | SHA-256-Befehl | |---|---| | Windows | `[RO][FILE] Get-FileHash -Algorithm SHA256 -LiteralPath ""` | | Linux | `[RO][FILE] sha256sum ""` | | macOS | `[RO][FILE] shasum -a 256 ""` | **Mögliche Verwendung:** - Produktiv- und Referenzdatei vergleichen, - Zustand vor einer Änderung dokumentieren, - prüfen, ob Deployment wirklich neue Datei ausgeliefert hat, - Konfigurationsdrift erkennen, - gesicherte Kopie eindeutig zuordnen. **Wichtig:** - unterschiedliche Hashwerte beweisen einen Inhaltsunterschied, - gleiche Hashwerte beweisen mit sehr hoher Sicherheit gleichen Dateiinhalt, - Dateiname, Eigentümer und Berechtigungen werden nicht inhaltlich verglichen, - Hashwerte geheimer Dateien dürfen je nach Sicherheitsvorgabe ebenfalls geschützt werden.
---
10. Zwei Konfigurationsstände vergleichen **Windows – zeilenweiser Vergleich:** ```powershell [RO][FILE][SENS] Compare-Object ` (Get-Content -LiteralPath "") ` (Get-Content -LiteralPath "") ``` Bedeutung der Seitenindikatoren: | Indikator | Bedeutung | |---|---| | `<=` | Zeile befindet sich nur in der Referenz | | `=>` | Zeile befindet sich nur in der aktuellen Datei | **Linux:** ```bash [RO][FILE][SENS] diff -u "" "" ``` **macOS:** ```bash [RO][FILE][SENS] diff -u "" "" ``` **Hinweise:** - `diff` liefert bei Unterschieden üblicherweise einen Rückgabecode ungleich null, obwohl das Werkzeug technisch korrekt gearbeitet hat. - Unterschiedliche Reihenfolge kann als Änderung erscheinen. - Kommentare und Leerzeichen können Unterschiede erzeugen, ohne die Funktion zu verändern. - Bei strukturierten Formaten sollte zusätzlich die semantische Wirkung geprüft werden. - Referenzdatei und aktuelle Datei müssen zur gleichen Produktversion passen. - Secrets dürfen nicht ungefiltert in die Vergleichsausgabe gelangen.
---
11. JSON-Konfiguration prüfen **Windows PowerShell:** ```powershell [RO][FILE][SENS] Test-Json ` -Json (Get-Content -LiteralPath ".json" -Raw) ``` **JSON einlesen und strukturiert anzeigen:** ```powershell [RO][FILE][SENS] Get-Content -LiteralPath ".json" -Raw | ConvertFrom-Json ``` **Linux mit installiertem jq:** ```bash [RO][FILE][SENS] jq empty ".json" ``` **macOS mit plutil:** ```bash [RO][FILE] plutil -lint ".json" ``` **JSON lesbar ausgeben, ohne Quelldatei zu verändern:** ```bash [RO][FILE][SENS] plutil \ -convert json \ -o - \ -- ".json" ``` **Zu beachten:** - syntaktisch gültiges JSON kann fachlich falsche Werte enthalten, - doppelte Schlüssel können von Parsern unterschiedlich behandelt werden, - Kommentare sind im eigentlichen JSON-Standard nicht vorgesehen, - Datentypen wie Zahl, Zeichenfolge und Boolean müssen stimmen, - Produktschema und Pflichtfelder müssen zusätzlich geprüft werden.
---
12. XML- und plist-Konfiguration prüfen **Beliebiges XML unter Windows PowerShell einlesen:** ```powershell [RO][FILE][SENS] [xml]( Get-Content -LiteralPath ".xml" -Raw ) ``` Ein Parserfehler weist auf ungültiges XML hin. Ein erfolgreiches Einlesen beweist noch keine Gültigkeit gegenüber einem Produktschema. **Linux mit installiertem xmllint:** ```bash [RO][FILE] xmllint --noout ".xml" ``` **macOS – plist-Syntax prüfen:** ```bash [RO][FILE] plutil -lint ".plist" ``` **macOS – plist lesbar anzeigen:** ```bash [RO][FILE][SENS] plutil -p ".plist" ``` **macOS – Typ eines bekannten plist-Schlüssels prüfen:** ```bash [RO][FILE] plutil \ -type "" \ ".plist" ``` **Zu unterscheiden:** | Prüfung | Aussage | |---|---| | XML syntaktisch lesbar | Grundlegende XML-Struktur ist gültig | | plist mit `plutil -lint` gültig | Property-List-Format ist syntaktisch gültig | | Schema gültig | Felder und Struktur entsprechen einem definierten Schema | | Fachlich gültig | Werte funktionieren für das konkrete Produkt | | Wirksam | Anwendung verwendet diese Werte tatsächlich |
---
13. YAML-, INI- und proprietäre Formate prüfen Für YAML, INI und herstellerspezifische Formate gibt es kein einzelnes betriebssystemübergreifendes Standardwerkzeug, das gleichzeitig Syntax und fachliche Gültigkeit zuverlässig prüft. **Geeignete Reihenfolge:** 1. offizielles Validierungswerkzeug des Produkts verwenden, 2. produktspezifischen Testmodus verwenden, 3. unterstütztes Schema verwenden, 4. Parser nur aus einer vertrauenswürdigen Quelle verwenden, 5. Ausgabe mit der verwendeten Produktversion dokumentieren. **Typische YAML-Fehler:** - falsche Einrückung, - Tabulator statt Leerzeichen, - unbeabsichtigte Typumwandlung, - falsch gesetzte Anführungszeichen, - ungültige Liste oder Zuordnung, - doppelte Schlüssel, - nicht aufgelöste Referenz, - mehrere Dokumente in einer Datei. **Typische INI-Fehler:** - falscher Abschnitt, - doppelter Schlüssel, - unerwartete Groß- und Kleinschreibung, - falsches Trennzeichen, - ungültige Escape-Sequenz, - Wert im falschen Abschnitt, - Kommentarzeichen wird als Wert interpretiert. > Keine beliebigen Online-Validatoren für produktive Konfigurationen verwenden. Dateien können interne Adressen, Konten, Tokens oder andere Geheimnisse enthalten.
---
14. systemd-Unit-Dateien und Überschreibungen prüfen **Wirksame Unit anzeigen:** ```bash [RO][FILE][SENS] systemctl cat "" ``` **Unit formal prüfen:** ```bash [RO][FILE] systemd-analyze verify "" ``` **Lokale Abweichungen von ausgelieferten Unit-Dateien anzeigen:** ```bash [RO][FILE][SENS] systemd-delta ``` **Nur Abweichungen für systemd-Systemkonfigurationen anzeigen:** ```bash [RO][FILE][SENS] systemd-delta --type=overridden,extended ``` Mögliche Kategorien von `systemd-delta`: | Kategorie | Bedeutung | |---|---| | `overridden` | Ursprüngliche Datei wurde vollständig überschrieben | | `extended` | Drop-in ergänzt oder verändert Einstellungen | | `masked` | Unit ist maskiert | | `equivalent` | Dateien sind inhaltlich gleichwertig | | `redirected` | Datei verweist auf ein anderes Ziel | **Besonders prüfen:** - wurde `ExecStart` in einem Drop-in ersetzt? - blieb eine alte Überschreibung nach einem Update bestehen? - verweist `EnvironmentFile` auf eine alte Datei? - wurde eine Hersteller-Unit unter `/usr` direkt verändert? - enthält ein Drop-in eine leere Zuweisung, die einen früheren Wert zurücksetzt? - wurde eine Unit versehentlich maskiert?
---
15. launchd-plist unter macOS prüfen **Syntax prüfen:** ```bash [RO][FILE] plutil -lint "/Library/LaunchDaemons/
---
16. Umgebungsvariablen als Fehlerquelle untersuchen Eine Variable kann in der interaktiven Shell vorhanden sein, aber im Dienstkontext fehlen. Typische verwendete Variablen: ```text PATH HOME TEMP TMP LANG LC_ALL HTTP_PROXY HTTPS_PROXY NO_PROXY DATABASE_URL CONFIG_PATH CERT_PATH ``` **Windows – Umgebungsvariablen der aktuellen Sitzung:** ```powershell [RO][SENS] Get-ChildItem Env: ``` **Windows – maschinenweite Variable lesen:** ```powershell [RO][SENS] [Environment]::GetEnvironmentVariable( "", "Machine" ) ``` **Linux – für systemd konfigurierte Dienstvariablen anzeigen:** ```bash [RO][SENS] systemctl show "" \ --property=Environment,EnvironmentFiles ``` **macOS – launchd-Job und plist prüfen:** ```bash [RO][SENS] launchctl print "system/
---
17. Relative Pfade und Arbeitsverzeichnis prüfen Folgende Konfiguration kann problematisch sein: ```text config/application.conf certificates/server.crt logs/application.log ./data ``` Relative Pfade werden vom Arbeitsverzeichnis des Prozesses aus aufgelöst. Dieses kann beim Dienststart anders sein als beim manuellen Start. **Windows – Dienstpfad anzeigen:** ```powershell [RO][SENS] Get-CimInstance Win32_Service -Filter "Name=''" | Select-Object Name, PathName ``` **Linux – Arbeitsverzeichnis anzeigen:** ```bash [RO] systemctl show "" --property=WorkingDirectory ``` **macOS – plist prüfen:** ```bash [RO][FILE][SENS] plutil -p "/Library/LaunchDaemons/
---
18. Zeichenkodierung und Zeilenenden prüfen **Windows – Anfangsbytes einer Datei anzeigen:** ```powershell [RO][FILE] Format-Hex -LiteralPath "" | Select-Object -First 5 ``` **Linux – Dateityp und mögliche Kodierungshinweise:** ```bash [RO][FILE] file "" ``` **macOS:** ```bash [RO][FILE] file "" ``` Typische Probleme: - UTF-8 mit oder ohne Byte Order Mark, - UTF-16 statt UTF-8, - ungültige Bytefolge, - Windows-Zeilenende `CRLF`, - Unix-Zeilenende `LF`, - unsichtbares Steuerzeichen, - nicht brechendes Leerzeichen, - Tabulator in YAML, - typografische statt gerader Anführungszeichen, - falsche Normalisierung von Unicode-Zeichen. **Unsichtbare Zeichen unter Linux oder macOS darstellen:** ```bash [RO][FILE][SENS] sed -n 'l' "" ``` > Eine Konvertierung verändert die Datei und darf erst nach Sicherung, Freigabe und Kenntnis des erwarteten Formats durchgeführt werden.
---
19. Include-Dateien und Konfigurationshierarchie prüfen Eine Hauptdatei kann weitere Dateien laden: ```text Hauptdatei → conf.d/*.conf → lokale Überschreibung → geheime Umgebungsdatei → automatisch generierte Datei ``` **Zu prüfen:** - welche Include-Anweisungen existieren? - in welcher Reihenfolge werden Dateien geladen? - werden Platzhalter oder Wildcards verwendet? - existiert eine alte Sicherungsdatei mit passender Endung im Include-Verzeichnis? - wird eine automatisch generierte Datei manuell überschrieben? - gibt es environment-, mandanten- oder hostabhängige Dateien? - wird eine Datei aufgrund falscher Endung ignoriert? - verweist ein Include auf einen nicht vorhandenen Pfad? - wird dieselbe Einstellung mehrfach definiert? - gewinnt der erste oder der letzte Wert? > Die Lade- und Überschreibungsreihenfolge muss aus der Dokumentation des konkreten Produkts entnommen werden.
---
20. Versionskompatibilität der Konfiguration prüfen Nach einem Update können Einstellungen: - umbenannt, - entfernt, - als veraltet markiert, - in einen anderen Abschnitt verschoben, - mit verändertem Datentyp erwartet, - mit neuem Standardwert versehen, - sicherheitsbedingt deaktiviert, - durch ein neues Format ersetzt worden sein. **Zu dokumentieren:** ```text Vorherige Produktversion: Aktuelle Produktversion: Version der Konfigurationsvorlage: Datum der letzten Konfigurationsänderung: Migrationshinweise gelesen: Veraltete Optionen: Neue Pflichtwerte: Geänderte Standardwerte: ``` **Prüfquellen:** 1. offizielle Versionshinweise, 2. Upgrade- oder Migrationsanleitung, 3. Beispielkonfiguration derselben Version, 4. produktspezifischer Konfigurationstest, 5. Startprotokoll mit Warnungen zu veralteten Optionen. > Eine Beispieldatei aus einer neueren oder älteren Version darf nicht ungeprüft als Referenz verwendet werden.
---
21. Secrets und Zugangsdaten sicher behandeln Konfigurationsdateien können enthalten: - Kennwörter, - API-Schlüssel, - Datenbank-Verbindungszeichenfolgen, - private Schlüssel, - Zugriffstoken, - Sitzungsschlüssel, - LDAP-Bindekennwörter, - Cloud-Zugangsdaten, - interne URLs mit eingebetteten Zugangsdaten. **Regeln:** ```text [ ] Keine vollständige Geheimdatei in ein Ticket kopieren [ ] Keine Secrets in Terminalbefehle mit Protokollierung einsetzen [ ] Keine produktive Konfiguration in Online-Validatoren hochladen [ ] Keine privaten Schlüssel mit Vergleichsausgaben veröffentlichen [ ] Nur bereinigte Kopien weitergeben [ ] Originaldatei geschützt aufbewahren [ ] Dateirechte vor und nach einer Maßnahme prüfen [ ] Kompromittierte Geheimnisse nicht nur zurückändern, sondern rotieren ``` **Unsichere Darstellung:** ```text DATABASE_URL=postgres://admin:Kennwort@db-server/database ``` **Bereinigte Darstellung:** ```text DATABASE_URL=postgres://:@/ ```
---
22. Containerkonfiguration berücksichtigen Bei Containern können Einstellungen stammen aus: - Image-Standardwerten, - Umgebungsvariablen, - Compose- oder Orchestrator-Definition, - Secrets, - Config-Objekten, - eingebundenen Dateien, - persistenten Volumes, - Startbefehl oder Entrypoint, - Reverse-Proxy-Konfiguration. **Prüffragen:** - welche Image-Version wird tatsächlich ausgeführt? - wurde der Container nach einer Änderung neu erstellt? - ist die richtige Datei in den Container eingebunden? - wurde eine Datei oder ein ganzes Verzeichnis gemountet? - verdeckt ein Mount eine im Image vorhandene Datei? - verwendet der Container die erwarteten Umgebungsvariablen? - enthält der Startbefehl eine Überschreibung? - wurde ein Secret aktualisiert? - ist die Konfiguration persistent? - unterscheidet sich die Hostdatei von der Datei im Container? - verwendet die Anwendung intern einen anderen Pfad? > Eine Änderung an einer Hostdatei ist nur wirksam, wenn genau diese Datei in den Container eingebunden und von der Anwendung verwendet wird.
---
23. Konfiguration vor einer Änderung beweissicher erfassen Mindestens erfassen: | Information | Zweck | |---|---| | Vollständiger Pfad | Eindeutige Dateiidentifikation | | Dateigröße | Plausibilitätsprüfung | | Änderungszeit | Zeitlicher Zusammenhang | | Eigentümer und Rechte | Zugriffskontrolle | | SHA-256-Hash | Inhaltsidentifikation | | Produktversion | Kompatibilitätsprüfung | | Dienststartparameter | Nachweis der Verwendung | | Include-Dateien | Vollständige Konfigurationskette | | Wirksame Werte | Tatsächlicher Zustand | | Geheimnisstatus | Schutzbedarf | | Sicherungspfad | Rückfallmöglichkeit | **Dokumentationsvorlage:** ```text Dienst: Produktversion: Konfigurationsdatei: Weitere Konfigurationsquellen: Eigentümer: Berechtigungen: Änderungszeit: SHA-256: Wirksame Konfiguration geprüft: Syntaxprüfung: Herstellervalidierung: Auffälliger Wert: Letzte bekannte funktionierende Version: Geplante Änderung: Rückfallmöglichkeit: ```
---
24. Kontrollierter Änderungsablauf Eine Konfigurationsänderung besteht nicht nur aus dem Bearbeiten einer Datei. ```text 1. Ursache und Sollwert bestimmen 2. Produktversion und Dokumentation prüfen 3. Originalzustand dokumentieren 4. Geschützte Sicherung erstellen 5. Genau eine fachliche Änderung durchführen 6. Syntax validieren 7. Produktspezifischen Konfigurationstest ausführen 8. Unterschied zur Ausgangsversion prüfen 9. Eigentümer und Berechtigungen kontrollieren 10. Reload oder Neustart nach Dokumentation planen 11. Protokolle während der Aktivierung beobachten 12. Technischen und fachlichen Funktionstest durchführen 13. Nebenwirkungen prüfen 14. Bei Fehlschlag kontrolliert zurückrollen 15. Ursache, Änderung und Ergebnis dokumentieren ``` **Risiken:** - eine Sicherung im aktiven Include-Verzeichnis wird mitgeladen, - Editor verändert Eigentümer oder Berechtigungen, - temporäre Datei erhält falsche Zugriffsrechte, - Reload wird unterstützt, übernimmt aber nicht alle Werte, - Neustart unterbricht aktive Transaktionen, - alte Konfiguration passt nicht mehr zur aktualisierten Software, - Rückrollen der Datei reicht nach einer Datenmigration nicht aus.
---
25. Reload, Neustart und Neuerstellung unterscheiden | Maßnahme | Wirkung | |---|---| | Reload | Dienst liest unterstützte Konfigurationsbereiche neu ein | | Neustart | Prozess wird beendet und neu gestartet | | Systemneustart | Gesamtes Betriebssystem startet neu | | Containerneustart | Gleiche Containerinstanz wird erneut gestartet | | Containerneuerstellung | Container wird aus Definition und Image neu erzeugt | | Redeployment | Anwendung und Konfiguration werden erneut bereitgestellt | **Prüffragen:** - unterstützt der Dienst einen Reload? - welche Einstellungen werden beim Reload übernommen? - benötigt die Änderung einen vollständigen Neustart? - wird die Datei nur beim Installieren eingelesen? - wird Konfiguration in eine Datenbank importiert? - wird der Container bei einer Neuerstellung mit identischen Parametern erzeugt? - bleiben Volumes und Secrets erhalten? - gehen Diagnoseinformationen beim Neustart verloren? > Nicht jeder Dienst übernimmt jede Einstellung durch einen Reload. Die unterstützte Aktivierungsmethode muss aus der Produktdokumentation stammen.
---
26. Typische Fehlinterpretationen | Fehlinterpretation | Richtige Bewertung | |---|---| | „Die Datei ist syntaktisch gültig, also funktioniert die Konfiguration.“ | Werte, Pfade und Abhängigkeiten können trotzdem falsch sein | | „Ich habe die Standarddatei geprüft.“ | Der Dienst kann eine andere Datei verwenden | | „Die Datei wurde geändert, also nutzt der Prozess den neuen Wert.“ | Reload oder Neustart kann fehlen | | „Der Wert steht nur einmal in der Hauptdatei.“ | Include, Variable oder Startparameter kann ihn überschreiben | | „Manueller Start funktioniert.“ | Die Shell kann andere Variablen und Rechte besitzen | | „Gleicher Dateiname bedeutet gleiche Konfiguration.“ | Inhalt muss mit Hash oder Vergleich geprüft werden | | „Der neueste Änderungszeitpunkt zeigt den Verursacher.“ | Er zeigt nur eine Dateiänderung | | „Die Beispielkonfiguration ist immer korrekt.“ | Sie muss zur eingesetzten Version passen | | „Eine Sicherungsdatei im Konfigurationsordner ist ungefährlich.“ | Wildcard-Includes können sie mitladen | | „Zurückkopieren der Datei stellt alles wieder her.“ | Daten-, Schema- oder Laufzeitänderungen können bestehen bleiben |
---
27. Checkliste zur Konfigurationsanalyse ```text [ ] Richtigen Dienst und richtige Produktversion bestätigt [ ] Tatsächliche Konfigurationsquelle ermittelt [ ] Startparameter geprüft [ ] Umgebungsvariablen berücksichtigt [ ] Hauptdatei und Includes erfasst [ ] Überschreibungsreihenfolge geklärt [ ] Wirksame Konfiguration ermittelt [ ] Datei vorhanden und nicht leer [ ] Symbolische Links geprüft [ ] Eigentümer und Berechtigungen geprüft [ ] Arbeitsverzeichnis berücksichtigt [ ] Syntax mit geeignetem Werkzeug geprüft [ ] Produktspezifische Validierung durchgeführt [ ] Pflichtwerte und Datentypen geprüft [ ] Pfade und Zielsysteme geprüft [ ] Port- und Protokollwerte geprüft [ ] Versionskompatibilität geprüft [ ] Referenzdatei gehört zur gleichen Version [ ] Hash und Änderungszeit dokumentiert [ ] Unterschiede zur funktionierenden Version geprüft [ ] Secrets geschützt [ ] Ausgangszustand gesichert [ ] Genau eine Änderung geplant [ ] Aktivierungsmethode geklärt [ ] Rückfallmöglichkeit vorbereitet [ ] Funktionstest festgelegt ```
--- **Bewertung des Ergebnisses** | Ergebnis | Nächster Schritt | |---|---| | Falsche Datei wurde geprüft | Tatsächliche Konfigurationsquelle untersuchen | | Syntax ungültig | Fehlerstelle sichern und nach Produktschema korrigieren | | Syntax gültig, Wert aber falsch | Sollwert und Abhängigkeit prüfen | | Datei wird überschrieben | Konfigurationspriorität und übergeordnete Quelle prüfen | | Dienst verwendet alte Werte | Unterstützten Reload oder Neustart planen | | Pfad existiert nicht | Deployment, Mount und Dateisystem prüfen | | Dienstkonto kann Datei nicht lesen | Berechtigung und Eigentümer untersuchen | | Option ist veraltet | Migrationsdokumentation der eingesetzten Version prüfen | | Umgebungsvariable fehlt | Tatsächlichen Dienstkontext prüfen | | Konfigurationen unterscheiden sich | Änderung fachlich bewerten und Ursache bestimmen | | Konfiguration ist korrekt und wirksam | Berechtigungen, Ressourcen und Anwendung untersuchen | --- **Merksatz** > **Nicht die Datei, die ein Administrator bearbeitet, ist entscheidend, sondern die Konfiguration, die der Dienst im tatsächlichen Laufzeitkontext wirksam verwendet.** --- **Weiterführende Quellen** - [Microsoft Learn – Get-CimInstance](https://learn.microsoft.com/powershell/module/cimcmdlets/get-ciminstance) - [Microsoft Learn – Get-FileHash](https://learn.microsoft.com/powershell/module/microsoft.powershell.utility/get-filehash) - [Microsoft Learn – Compare-Object](https://learn.microsoft.com/powershell/module/microsoft.powershell.utility/compare-object) - [Microsoft Learn – Test-Json](https://learn.microsoft.com/powershell/module/microsoft.powershell.utility/test-json) - [Microsoft Learn – Get-Acl](https://learn.microsoft.com/powershell/module/microsoft.powershell.security/get-acl) - [systemd – systemctl](https://www.freedesktop.org/software/systemd/man/latest/systemctl.html) - [systemd – systemd-analyze](https://www.freedesktop.org/software/systemd/man/latest/systemd-analyze.html) - [systemd – systemd-delta](https://www.freedesktop.org/software/systemd/man/latest/systemd-delta.html) - [systemd – systemd.unit](https://www.freedesktop.org/software/systemd/man/latest/systemd.unit.html) - [Apple – plutil-Handbuchseite](https://keith.github.io/xcode-man-pages/plutil.1.html) - [Apple – defaults-Handbuchseite](https://keith.github.io/xcode-man-pages/defaults.1.html) - [Apple – launchctl-Handbuchseite](https://keith.github.io/xcode-man-pages/launchctl.1.html) - [Apple – launchd.plist-Handbuchseite](https://keith.github.io/xcode-man-pages/launchd.plist.5.html) # 4.9 Benutzer-, Dienstkonto- und Berechtigungsfehler Jeder Dienst arbeitet in einem bestimmten Sicherheitskontext. Dieser entscheidet, auf welche Dateien, Verzeichnisse, Netzwerkressourcen, Zertifikate, Ports und Betriebssystemfunktionen der Dienst zugreifen darf. > **Grundsatz:** > Ein erfolgreicher Zugriff als Administrator beweist nicht, dass das tatsächliche Dienstkonto denselben Zugriff besitzt. --- **Ziele dieser Seite** Nach dieser Seite sollst du: - das verwendete Dienstkonto bestimmen können, - Benutzer, Gruppen und Sicherheitskennungen prüfen können, - Dateirechte und ACLs auswerten können, - lokale und entfernte Berechtigungen unterscheiden können, - fehlende Anmelderechte und gesperrte Konten erkennen können, - den Zugriff im tatsächlichen Dienstkontext testen können, - SELinux-, AppArmor- und macOS-Datenschutzbeschränkungen berücksichtigen können, - Berechtigungsprobleme beheben, ohne unnötig weitreichende Rechte zu vergeben. ---
1. Sicherheitskontext eines Dienstes verstehen Der Sicherheitskontext kann unter anderem enthalten: - Benutzerkonto, - primäre Gruppe, - zusätzliche Gruppen, - Sicherheitskennung beziehungsweise UID, - Zugriffstoken, - Benutzerrechte und Privilegien, - Dateisystem-ACLs, - Netzwerkidentität, - Integritäts- und Sicherheitsstufe, - SELinux- oder AppArmor-Kontext, - systemd-Sandboxing, - macOS-Datenschutzfreigaben, - Containerbenutzer und Capabilities. Bei jedem Zugriff bewertet das System mehrere Faktoren: ```text Dienstkonto + Gruppenmitgliedschaften + lokale Rechte + ACLs des Zielobjekts + übergeordnete Verzeichnisrechte + Sicherheitsrichtlinien + Dienst- oder Containerbeschränkungen = effektiver Zugriff ```
---
2. Authentifizierung und Autorisierung unterscheiden | Begriff | Leitfrage | Beispiel | |---|---|---| | Authentifizierung | Wer ist der Dienst? | Anmeldung als Dienstkonto | | Autorisierung | Was darf dieses Konto? | Leserechte auf Konfigurationsdatei | | Identifikation | Welches Konto wird verwendet? | UID, SID oder Benutzername | | Gruppenmitgliedschaft | Welche Rollen besitzt das Konto? | Mitglied der Datenbankgruppe | | Privileg | Welche Systemoperation ist erlaubt? | Binden an privilegierten Port | | ACL | Welche Rechte gelten auf einem Objekt? | Schreiben in Datenverzeichnis | | Sicherheitsrichtlinie | Welche zusätzliche Kontrolle greift? | SELinux oder macOS TCC | **Typische Trennung:** ```text Anmeldung fehlgeschlagen → Authentifizierungsproblem Anmeldung erfolgreich, Zugriff verweigert → Autorisierungsproblem ```
---
3. Typische Fehlerbilder eines Dienstkontos | Fehlerbild | Mögliche Ursache | |---|---| | Dienst startet nicht | Konto ungültig oder Anmelderecht fehlt | | Zugriff verweigert | Datei-, ACL- oder Sicherheitsrichtlinienfehler | | Lokaler Zugriff funktioniert, Netzwerkzugriff nicht | Andere Netzwerkidentität oder fehlende Remote-Berechtigung | | Manueller Start funktioniert | Administrator besitzt mehr Rechte als Dienstkonto | | Dienst funktioniert bis zum Kennwortwechsel | Hinterlegtes Dienstkennwort ist veraltet | | Nur eine Datei ist nicht zugänglich | Abweichender Eigentümer oder ACL | | Schreiben scheitert, Lesen funktioniert | Schreibrecht auf Datei oder Verzeichnis fehlt | | Datei kann gelesen, aber nicht ersetzt werden | Änderungsrecht auf Verzeichnis fehlt | | Programm ist ausführbar, startet aber nicht | Bibliothek, Arbeitsverzeichnis oder Sicherheitsrichtlinie blockiert | | Zugriff funktioniert nach Anmeldung, aber nicht beim Boot | Benutzersitzung oder Netzlaufwerk fehlt | | macOS-Dienst erhält trotz POSIX-Rechten keinen Zugriff | Datenschutzkontrolle oder Sandbox blockiert | | Linux-Dienst erhält trotz Modus `777` keinen Zugriff | SELinux, AppArmor, Mountoption oder systemd-Sandboxing |
---
4. Dienstkonto unter Windows bestimmen **Dienstkonto und Status anzeigen:** ```powershell [RO] Get-CimInstance Win32_Service -Filter "Name=''" | Select-Object Name, DisplayName, State, StartMode, StartName, ProcessId ``` **Alternative mit sc.exe:** ```powershell [RO][SENS] sc.exe qc "" ``` Relevant ist: ```text SERVICE_START_NAME ``` Typische Windows-Dienstkonten: | Konto | Grundlegende Einordnung | |---|---| | `LocalSystem` | Sehr weitreichende lokale Rechte | | `LocalService` | Begrenzte lokale Rechte | | `NetworkService` | Begrenzte lokale Rechte, Netzwerkzugriff typischerweise als Computerkonto | | Virtuelles Dienstkonto | Dienstbezogene lokale Identität | | Lokales Benutzerkonto | Gilt primär auf dem lokalen System | | Domänenkonto | Kann abhängig von Berechtigungen auf Domänenressourcen zugreifen | | Gruppenverwaltetes Dienstkonto | Durch Active Directory verwaltetes Dienstkonto | > Das Konto sollte nur die für den Dienst benötigten Rechte besitzen. Die Vergabe von Administratorrechten ist keine geeignete Standardlösung für ein Berechtigungsproblem.
---
5. Aktuellen Windows-Benutzerkontext anzeigen Diese Befehle zeigen den Kontext der aktuellen Sitzung – nicht automatisch den Kontext des Dienstes. **Benutzername anzeigen:** ```powershell [RO] whoami ``` **Benutzer und SID anzeigen:** ```powershell [RO] whoami /user ``` **Gruppen anzeigen:** ```powershell [RO][SENS] whoami /groups ``` **Privilegien anzeigen:** ```powershell [RO][SENS] whoami /priv ``` **Gesamten aktuellen Sicherheitskontext anzeigen:** ```powershell [RO][SENS] whoami /all ``` > Die Ausgabe ist als Vergleich hilfreich. Sie darf aber nicht auf das Dienstkonto übertragen werden, wenn der Befehl in einer Administrator- oder Benutzersitzung ausgeführt wurde.
---
6. Lokales Windows-Konto und Gruppen prüfen **Lokales Konto suchen:** ```powershell [RO] Get-LocalUser -Name "" -ErrorAction SilentlyContinue ``` **Status eines lokalen Kontos anzeigen:** ```powershell [RO][SENS] Get-LocalUser -Name "" | Select-Object Name, Enabled, LastLogon, PasswordExpires, PasswordRequired, UserMayChangePassword ``` **Mitgliedschaften einer lokalen Gruppe anzeigen:** ```powershell [RO][SENS] Get-LocalGroupMember -Group "" ``` **Alle lokalen Gruppen anzeigen:** ```powershell [RO] Get-LocalGroup ``` **Einschränkungen:** - `Get-LocalUser` prüft keine Domänenkonten. - Domänenkonten benötigen Active-Directory-Werkzeuge oder eine Abfrage durch zuständige Administratoren. - Gruppenmitgliedschaften können verschachtelt sein. - Änderungen an Gruppenmitgliedschaften werden nicht in jedem laufenden Zugriffstoken sofort wirksam. - Ein Dienstneustart kann erforderlich sein, damit ein neues Zugriffstoken erzeugt wird.
---
7. Windows-Dateirechte mit Get-Acl prüfen **ACL einer Datei anzeigen:** ```powershell [RO][FILE][SENS] Get-Acl -LiteralPath "" | Format-List ``` **Zugriffsregeln übersichtlich anzeigen:** ```powershell [RO][FILE][SENS] (Get-Acl -LiteralPath "").Access | Select-Object IdentityReference, FileSystemRights, AccessControlType, IsInherited, InheritanceFlags, PropagationFlags ``` **ACL eines Verzeichnisses anzeigen:** ```powershell [RO][FILE][SENS] (Get-Acl -LiteralPath "").Access | Select-Object IdentityReference, FileSystemRights, AccessControlType, IsInherited ``` Wichtige Felder: | Feld | Bedeutung | |---|---| | `IdentityReference` | Konto oder Gruppe | | `FileSystemRights` | Zugewiesene Rechte | | `Allow` | Erlaubende Regel | | `Deny` | Verweigernde Regel | | `IsInherited` | Regel wurde von übergeordnetem Objekt geerbt | | `Owner` | Eigentümer des Objekts | > Eine explizite Verweigerung kann eine erlaubende Berechtigung überstimmen. Die effektive Bewertung hängt jedoch von der vollständigen ACL und dem Zugriffstoken ab.
---
8. Windows-Dateirechte mit icacls prüfen **ACL einer Datei oder eines Verzeichnisses anzeigen:** ```powershell [RO][FILE][SENS] icacls "" ``` **ACLs unterhalb eines Verzeichnisses anzeigen:** ```powershell [RO][FILE][SENS] icacls "" /T /C ``` `/T` durchsucht Unterverzeichnisse rekursiv und kann bei großen Verzeichnisbäumen eine sehr umfangreiche Ausgabe erzeugen. Typische Rechtekürzel: | Kürzel | Bedeutung | |---|---| | `F` | Vollzugriff | | `M` | Ändern | | `RX` | Lesen und Ausführen | | `R` | Lesen | | `W` | Schreiben | | `D` | Löschen | | `N` | Kein Zugriff | | `I` | Geerbte Regel | Typische Vererbungskennzeichnungen: | Kürzel | Bedeutung | |---|---| | `OI` | Vererbung an Dateien | | `CI` | Vererbung an Unterverzeichnisse | | `IO` | Regel gilt nur durch Vererbung | | `NP` | Keine weitere Vererbung | > Auf dieser Diagnoseseite wird `icacls` nur lesend verwendet. Parameter wie `/grant`, `/deny`, `/remove` oder `/reset` verändern Berechtigungen.
---
9. Effektive Windows-Rechte mit AccessChk untersuchen `AccessChk` ist ein zusätzliches Microsoft-Sysinternals-Werkzeug und nicht Bestandteil jeder Windows-Installation. **Grundlegende Prüfung eines Kontos auf einen bekannten Pfad:** ```powershell [RO][FILE][SENS] accesschk.exe ` -nobanner ` -v ` "" ` "" ``` **Prüfung eines Verzeichnisses:** ```powershell [RO][FILE][SENS] accesschk.exe ` -nobanner ` -d ` -v ` "" ` "" ``` Vor Verwendung prüfen: - stammt das Werkzeug direkt von Microsoft Sysinternals? - ist seine Verwendung im Unternehmen erlaubt? - wird die passende Werkzeugversion verwendet? - wird tatsächlich das Dienstkonto geprüft? - enthält die Ausgabe sensible ACL- und Kontoinformationen? > Wenn AccessChk nicht vorhanden oder nicht freigegeben ist, wird es nicht ungeprüft heruntergeladen oder auf einem Produktivserver installiert.
---
10. Erforderliche Windows-Dienstprivilegien prüfen **Vom Dienst angeforderte Privilegien anzeigen:** ```powershell [RO] sc.exe qprivs "" ``` **Wiederherstellungs- und Dienstkonfiguration ergänzend prüfen:** ```powershell [RO] sc.exe qfailure "" ``` ```powershell [RO][SENS] sc.exe qc "" ``` **Wichtig:** - `sc.exe qprivs` zeigt für den Dienst konfigurierte erforderliche Privilegien. - Es beweist nicht allein, dass das Konto alle notwendigen Objektberechtigungen besitzt. - Benutzerrechte wie „Anmelden als Dienst“ werden durch lokale oder domänenbasierte Sicherheitsrichtlinien vergeben. - Domänenrichtlinien können lokale Einstellungen überschreiben. - Fehlende Rechte erscheinen häufig im System- oder Sicherheitsprotokoll.
---
11. Windows-Anmeldefehler des Dienstkontos untersuchen Typische Ursachen: - falsches Kennwort, - Kennwort abgelaufen, - Konto deaktiviert, - Konto gesperrt, - „Anmelden als Dienst“ fehlt, - „Anmelden als Dienst verweigern“ greift, - Domänencontroller nicht erreichbar, - Zeitabweichung verhindert Authentifizierung, - verwaltetes Dienstkonto nicht korrekt eingerichtet, - Dienst verwendet altes hinterlegtes Kennwort. **Service-Control-Manager-Ereignisse prüfen:** ```powershell [RO][SENS] Get-WinEvent -FilterHashtable @{ LogName = "System" ProviderName = "Service Control Manager" StartTime = (Get-Date).AddHours(-2) } | Select-Object TimeCreated, Id, LevelDisplayName, Message ``` **Sicherheitsereignisse erfordern entsprechende Berechtigungen:** ```powershell [RO][SENS][PRIV] Get-WinEvent -FilterHashtable @{ LogName = "Security" StartTime = (Get-Date).AddHours(-2) } | Select-Object TimeCreated, Id, ProviderName, Message ``` > Das Sicherheitsprotokoll kann sehr viele sensible Informationen enthalten. Es sollte mit passenden Ereignis-IDs, Zeitfenstern und zuständigen Sicherheitsadministratoren ausgewertet werden.
---
12. Windows-Netzwerkidentität des Dienstkontos berücksichtigen Der lokale Kontoname ist nicht zwingend die Identität, die ein entfernter Server sieht. | Dienstkonto | Mögliche Netzwerkidentität | |---|---| | Lokales Benutzerkonto | Auf entferntem System nicht automatisch bekannt | | `LocalService` | Netzwerkzugriff typischerweise anonym beziehungsweise sehr begrenzt | | `NetworkService` | Zugriff im Domänenumfeld typischerweise als Computerkonto | | `LocalSystem` | Zugriff im Domänenumfeld typischerweise als Computerkonto | | Domänenkonto | Eigenes Domänenkonto | | gMSA | Verwaltete Domänenidentität | **Prüffragen:** - Welche Identität sieht der Fileserver oder Datenbankserver? - besitzt das Computerkonto Zugriff? - besitzt nur der angemeldete Administrator Zugriff? - wird Kerberos oder NTLM verwendet? - stimmt der verwendete Servername mit dem erwarteten Dienstprinzipal überein? - wird ein Laufwerksbuchstabe statt eines UNC-Pfads verwendet? - ist das Dienstkonto auf der Zielressource berechtigt? - existiert eine lokale und eine Freigabeberechtigung? > Bei einer Windows-Freigabe müssen sowohl die Freigabeberechtigung als auch die NTFS-Berechtigung den benötigten Zugriff erlauben.
---
13. Dienstkonto unter Linux bestimmen **systemd-Dienstkonto anzeigen:** ```bash [RO] systemctl show "" \ --property=User,Group,DynamicUser,SupplementaryGroups ``` **Wirksame Unit prüfen:** ```bash [RO][FILE][SENS] systemctl cat "" ``` **Benutzerkonto auflösen:** ```bash [RO] getent passwd "" ``` **Gruppenkonto auflösen:** ```bash [RO] getent group "" ``` **UID, primäre und zusätzliche Gruppen anzeigen:** ```bash [RO] id "" ``` **Wichtig:** - eine leere `User=`-Eigenschaft bedeutet bei einem Systemdienst normalerweise, dass keine abweichende Benutzeridentität konfiguriert wurde, - `DynamicUser=yes` erzeugt eine dynamisch verwaltete Identität, - zusätzliche Gruppen können über `SupplementaryGroups=` gesetzt werden, - ein Container kann innerhalb seines Namespaces andere UID-Zuordnungen verwenden.
---
14. POSIX-Dateirechte unter Linux verstehen Beispiel: ```text -rwxr-x--- 1 appuser appgroup 4096 Jul 31 09:00 application ``` Interpretation: | Bereich | Bedeutung | |---|---| | `-` | Reguläre Datei | | `rwx` | Eigentümer darf lesen, schreiben und ausführen | | `r-x` | Gruppe darf lesen und ausführen | | `---` | Andere besitzen keine Rechte | | `appuser` | Eigentümer | | `appgroup` | Gruppe | Rechte: | Recht | Datei | Verzeichnis | |---|---|---| | `r` | Dateiinhalt lesen | Verzeichnisinhalt auflisten | | `w` | Dateiinhalt verändern | Einträge anlegen oder entfernen | | `x` | Datei ausführen | Verzeichnis durchlaufen und Objekte erreichen | > Schreibrecht auf einer Datei und Schreibrecht auf dem übergeordneten Verzeichnis sind unterschiedliche Berechtigungen. Das Ersetzen oder Löschen einer Datei hängt häufig vom Verzeichnisrecht ab.
---
15. Linux-Dateirechte und Pfadbestandteile prüfen **Dateirechte anzeigen:** ```bash [RO][FILE] ls -ld "" ``` **Numerische und symbolische Rechte anzeigen:** ```bash [RO][FILE] stat -c '%U %G %A %a %n' "" ``` **Alle Bestandteile eines Pfads prüfen:** ```bash [RO][FILE] namei -l "" ``` **Verzeichnis und Zieldatei gemeinsam prüfen:** ```bash [RO][FILE] ls -ld "" "" ``` **Prüffragen:** - darf das Dienstkonto jedes übergeordnete Verzeichnis durchlaufen? - darf es die Datei lesen? - darf es das Verzeichnis beschreiben? - stimmen Eigentümer und Gruppe? - greift das Gruppenrecht wirklich, weil das Konto Mitglied ist? - ist das Dateisystem schreibgeschützt? - verhindern Mountoptionen die Ausführung? - handelt es sich um einen symbolischen Link?
---
16. Linux-ACLs prüfen **ACL einer Datei anzeigen:** ```bash [RO][FILE][SENS] getfacl "" ``` **ACL eines Verzeichnisses anzeigen:** ```bash [RO][FILE][SENS] getfacl "" ``` Mögliche Ausgabe: ```text user::rw- user:appuser:r-- group::r-- mask::r-- other::--- ``` Wichtige Elemente: | Eintrag | Bedeutung | |---|---| | `user::` | Rechte des Eigentümers | | `user:name:` | Rechte eines bestimmten Benutzers | | `group::` | Rechte der Eigentümergruppe | | `group:name:` | Rechte einer bestimmten Gruppe | | `mask::` | Maximale wirksame Rechte benannter Benutzer und Gruppen | | `other::` | Rechte aller übrigen Benutzer | | `default:` | Standard-ACL für neu erstellte Unterobjekte | > Die ACL-Maske kann weitergehende angezeigte Einzelrechte begrenzen. Deshalb müssen sowohl Eintrag als auch `mask` bewertet werden.
---
17. Linux-Zugriff im tatsächlichen Benutzerkontext testen Die folgenden Tests lesen oder verändern die Zieldatei nicht. Sie prüfen nur, ob der angegebene Zugriff laut Betriebssystem möglich ist. **Leserecht prüfen:** ```bash [TEST][PRIV] sudo -u "" \ test -r "" ``` **Schreibrecht prüfen:** ```bash [TEST][PRIV] sudo -u "" \ test -w "" ``` **Ausführungsrecht prüfen:** ```bash [TEST][PRIV] sudo -u "" \ test -x "" ``` **Verzeichniszugriff prüfen:** ```bash [TEST][PRIV] sudo -u "" \ test -x "" ``` **Rückgabecode unmittelbar anzeigen:** ```bash [TEST][PRIV] sudo -u "" \ test -r "" echo $? ``` | Rückgabecode | Bedeutung | |---:|---| | `0` | Bedingung erfüllt | | ungleich `0` | Bedingung nicht erfüllt oder Prüfung nicht möglich | **Einschränkung:** Ein erfolgreicher `test -r`- oder `test -w`-Befehl beweist nicht, dass SELinux, AppArmor, Anwendungssandboxing oder produktspezifische Regeln jeden späteren Zugriff erlauben.
---
18. Linux-Sonderrechte und Mountoptionen berücksichtigen **Mountoptionen des Zielpfads anzeigen:** ```bash [RO][FILE] findmnt --target "" ``` Mögliche relevante Optionen: | Option | Bedeutung | |---|---| | `ro` | Dateisystem ist schreibgeschützt | | `rw` | Dateisystem ist beschreibbar | | `noexec` | Direkte Ausführung von Dateien auf diesem Dateisystem wird verhindert | | `nosuid` | Setuid- und Setgid-Wirkung wird eingeschränkt | | `nodev` | Gerätedateien werden nicht interpretiert | **Dateirechte einschließlich Sonderbits anzeigen:** ```bash [RO][FILE] stat -c '%A %a %U %G %n' "" ``` Mögliche Sonderbits: - Setuid, - Setgid, - Sticky Bit. > Sonderrechte dürfen nicht als schnelle Problembehebung gesetzt werden. Eine falsche Verwendung kann erhebliche Sicherheitsrisiken erzeugen.
---
19. SELinux als zusätzliche Zugriffskontrolle prüfen Diese Befehle sind nur auf Systemen mit installiertem SELinux-Werkzeug relevant. **SELinux-Status anzeigen:** ```bash [RO] getenforce ``` Mögliche Ergebnisse: | Zustand | Bedeutung | |---|---| | `Enforcing` | Richtlinien werden durchgesetzt | | `Permissive` | Verstöße werden protokolliert, aber nicht blockiert | | `Disabled` | SELinux ist deaktiviert | **SELinux-Kontext einer Datei anzeigen:** ```bash [RO][FILE][SENS] ls -lZ "" ``` **Prozesskontext anzeigen:** ```bash [RO][SENS] ps -eZ | grep -- "" ``` **Aktuelle AVC-Verweigerungen suchen:** ```bash [RO][SENS][PRIV] sudo ausearch -m AVC -ts recent ``` **Wichtig:** - klassische Dateirechte können korrekt sein, während SELinux blockiert, - ein falscher Dateikontext kann nach manuellem Kopieren entstehen, - SELinux sollte nicht pauschal deaktiviert werden, - eine Richtlinienänderung muss auf den tatsächlich benötigten Zugriff begrenzt sein, - automatisch erzeugte Freigaberegeln müssen fachlich und sicherheitstechnisch geprüft werden.
---
20. AppArmor als zusätzliche Zugriffskontrolle prüfen Diese Befehle gelten nur, wenn AppArmor installiert und aktiv ist. **AppArmor-Status anzeigen:** ```bash [RO][PRIV] sudo aa-status ``` **Kernel- und Systemmeldungen nach Verweigerungen durchsuchen:** ```bash [RO][SENS][PRIV] sudo journalctl \ -k \ --since "1 hour ago" | grep -i -- "apparmor" ``` **Mögliche Zustände:** | Zustand | Bedeutung | |---|---| | Enforce | Profilregeln werden durchgesetzt | | Complain | Verstöße werden protokolliert, aber normalerweise nicht blockiert | | Unconfined | Prozess wird nicht durch ein AppArmor-Profil eingeschränkt | > AppArmor darf nicht pauschal deaktiviert werden. Zuerst müssen Profil, verweigerter Pfad und tatsächlich erforderlicher Zugriff bestimmt werden.
---
21. systemd-Sandboxing und Capabilities prüfen Auch ohne SELinux oder AppArmor kann systemd einen Dienst zusätzlich einschränken. **Sicherheitsrelevante Eigenschaften anzeigen:** ```bash [RO][SENS] systemctl show "" \ --property=NoNewPrivileges,ProtectSystem,ProtectHome,PrivateTmp,PrivateDevices,ReadOnlyPaths,ReadWritePaths,InaccessiblePaths,CapabilityBoundingSet,AmbientCapabilities ``` Mögliche Einschränkungen: | Eigenschaft | Mögliche Wirkung | |---|---| | `ProtectSystem=` | Teile des Dateisystems werden schreibgeschützt | | `ProtectHome=` | Zugriff auf Benutzerverzeichnisse wird eingeschränkt | | `PrivateTmp=` | Dienst erhält eigenes temporäres Verzeichnis | | `PrivateDevices=` | Zugriff auf Geräte wird eingeschränkt | | `ReadOnlyPaths=` | Bestimmte Pfade werden schreibgeschützt | | `ReadWritePaths=` | Ausgewählte Pfade werden beschreibbar gemacht | | `InaccessiblePaths=` | Pfade werden unzugänglich | | `NoNewPrivileges=` | Erwerb neuer Privilegien wird verhindert | | `CapabilityBoundingSet=` | Verfügbare Linux-Capabilities werden begrenzt | > Ein erfolgreicher Zugriff aus einer normalen Shell beweist nicht, dass derselbe Pfad innerhalb der systemd-Sandbox verfügbar ist.
---
22. Dienstkonto unter macOS bestimmen **Systemweiten launchd-Job anzeigen:** ```bash [RO] launchctl print "system/
---
23. Benutzer und Gruppen unter macOS prüfen **UID, GID und Gruppen eines Kontos anzeigen:** ```bash [RO] id "" ``` **Lokales Benutzerkonto über Directory Service anzeigen:** ```bash [RO][SENS] dscl . -read "/Users/" ``` **Bestimmte lokale Gruppe anzeigen:** ```bash [RO][SENS] dscl . -read "/Groups/" ``` **Gruppenmitgliedschaft prüfen:** ```bash [RO] dsmemberutil checkmembership \ -U "" \ -G "" ``` **Hinweise:** - `dscl .` bezieht sich auf den lokalen Verzeichnisknoten, - Netzwerk- oder Verzeichnisdienstkonten können weitere Werkzeuge erfordern, - Gruppenmitgliedschaften können aus mehreren Verzeichnisquellen stammen, - der aktuelle Prozess kann noch ein älteres Gruppen- und Berechtigungstoken verwenden.
---
24. POSIX-Rechte und ACLs unter macOS prüfen **Rechte, Eigentümer und ACL anzeigen:** ```bash [RO][FILE][SENS] ls -lde "" ``` **Erweiterte Attribute zusätzlich anzeigen:** ```bash [RO][FILE][SENS] ls -lde@ "" ``` **Dateiflags anzeigen:** ```bash [RO][FILE][SENS] ls -ldeO "" ``` **Metadaten strukturiert anzeigen:** ```bash [RO][FILE] stat -f '%Su %Sg %Sp %N' "" ``` Mögliche zusätzliche Einflussfaktoren: - POSIX-Rechte, - ACL-Einträge, - erweiterte Attribute, - Dateiflags, - schreibgeschütztes Volume, - Datenschutzkontrollen, - Sandbox, - System Integrity Protection. > Ein `+` in der Ausgabe von `ls -l` weist auf ACL-Einträge hin. Ein `@` weist auf erweiterte Attribute hin.
---
25. Zugriff unter macOS im Benutzerkontext testen **Leserecht prüfen:** ```bash [TEST][PRIV] sudo -u "" \ test -r "" ``` **Schreibrecht prüfen:** ```bash [TEST][PRIV] sudo -u "" \ test -w "" ``` **Ausführungsrecht prüfen:** ```bash [TEST][PRIV] sudo -u "" \ test -x "" ``` **Rückgabecode anzeigen:** ```bash [TEST][PRIV] sudo -u "" \ test -r "" echo $? ``` > Dieser Test bildet nicht automatisch den vollständigen launchd-, Sandbox- oder Datenschutzkontext eines Dienstes nach.
---
26. macOS-Datenschutzkontrollen berücksichtigen macOS schützt unter anderem Zugriffe auf: - Schreibtisch, - Dokumente, - Downloads, - iCloud Drive, - Netzwerkvolumes, - Wechselmedien, - Daten anderer Anwendungen, - Kontakte und Kalender, - Kamera und Mikrofon, - Automation, - Bedienungshilfen, - vollständigen Festplattenzugriff. Ein Zugriff kann trotz korrekter POSIX-Rechte und ACLs verweigert werden. **Protokolle nach dem Prozess durchsuchen:** ```bash [RO][SENS][PRIV] sudo log show \ --last 1h \ --predicate 'process == ""' \ --style compact \ --no-pager ``` **Nach möglichen Zugriffsverweigerungen suchen:** ```bash [RO][SENS][PRIV] sudo log show \ --last 1h \ --predicate 'process == "" AND (messageType == error OR messageType == fault)' \ --style compact \ --no-pager ``` **Wichtig:** - Datenschutzfreigaben werden über Systemeinstellungen oder Unternehmensverwaltung vergeben, - Full Disk Access ist eine weitreichende Berechtigung, - Freigaben dürfen nur vertrauenswürdigen und tatsächlich benötigten Programmen erteilt werden, - die Datenschutzdatenbank darf nicht manuell manipuliert werden, - ein Terminaltest kann andere Datenschutzrechte als der eigentliche Dienst besitzen.
---
27. macOS System Integrity Protection und Dateiflags berücksichtigen **SIP-Status anzeigen:** ```bash [RO] csrutil status ``` System Integrity Protection schützt bestimmte Systembereiche auch vor weitreichenden Benutzerkonten. **Dateiflags prüfen:** ```bash [RO][FILE] ls -ldeO "" ``` Mögliche Einflussfaktoren: - geschützter Systempfad, - unveränderliches Dateiflag, - schreibgeschütztes Systemvolume, - signierter Systembestandteil, - Sandbox- oder Datenschutzregel. > SIP darf nicht als allgemeine Fehlerbehebung deaktiviert werden. Zuerst muss geklärt werden, warum eine Anwendung auf einen geschützten Systembereich zugreifen möchte.
---
28. Netzwerkfreigaben und entfernte Ressourcen prüfen Bei einer entfernten Ressource existieren mindestens zwei Berechtigungsebenen: ```text Lokaler Dienstkontext → Netzwerkidentität → Authentifizierung am Ziel → Freigabe- oder Dienstberechtigung → Dateisystem- oder Objektberechtigung ``` **Prüffragen:** - welche Identität wird am Zielsystem verwendet? - existiert das Konto dort? - ist das Konto gesperrt oder abgelaufen? - besitzt es Freigabe- und Dateisystemrechte? - ist Kerberos, NTLM, LDAP oder Zertifikatsauthentifizierung vorgesehen? - funktioniert nur interaktiver Zugriff? - wird ein benutzerbezogener Mount verwendet? - ist das Ziel beim Systemstart bereits verfügbar? - ist das verwendete Secret aktuell? - protokolliert das Zielsystem den abgelehnten Zugriff? > Die Berechtigungsprüfung muss auch auf dem Zielsystem erfolgen. Der Quellserver kann häufig nur feststellen, dass der Zugriff abgelehnt wurde.
---
29. Containerbenutzer und Hostrechte berücksichtigen Ein Containerprozess kann innerhalb und außerhalb des Containers unterschiedliche Identitätsdarstellungen besitzen. Zu prüfen sind: - UID und GID im Container, - UID- und GID-Zuordnung auf dem Host, - Eigentümer des eingebundenen Volumes, - Rootless- oder Rootful-Betrieb, - User-Namespace, - Container-Capabilities, - schreibgeschützte Mounts, - SELinux-Label des Volumes, - Secrets und Config-Mounts, - Netzwerkidentität des Dienstes. Typisches Fehlerbild: ```text Datei auf dem Host gehört UID 1000 Containerprozess läuft als UID 1001 Volume ist nur für UID 1000 beschreibbar Anwendung meldet „Permission denied“ ``` > Ein Wechsel des Containers auf Benutzer `root` ist keine geeignete Standardlösung. Zuerst müssen vorgesehene UID, GID und Volume-Berechtigungen aus der Image- beziehungsweise Herstellerdokumentation ermittelt werden.
---
30. Leserecht, Schreibrecht und Änderungsrecht praktisch unterscheiden | Gewünschte Aktion | Typischer benötigter Zugriff | |---|---| | Dateiinhalt lesen | Leserecht auf Datei und Durchlaufrecht auf Verzeichnisse | | Dateiinhalt verändern | Schreibrecht auf Datei | | Neue Datei anlegen | Schreib- und Durchlaufrecht auf Verzeichnis | | Datei ersetzen | Rechte auf Datei und beziehungsweise oder Verzeichnis, abhängig vom Verfahren | | Datei löschen | Lösch- beziehungsweise Verzeichnisrecht | | Programm ausführen | Ausführungsrecht und Zugriff auf Bibliotheken | | Verzeichnis auflisten | Leserecht auf Verzeichnis | | Pfad durchlaufen | Ausführungsrecht auf Verzeichnis | | Logdatei erzeugen | Schreibrecht auf Zielverzeichnis | | Socketdatei erstellen | Schreibrecht auf Laufzeitverzeichnis | > Viele Anwendungen speichern eine Konfiguration, indem sie eine neue Datei erzeugen und anschließend die alte Datei ersetzen. Dafür kann Schreibrecht auf der ursprünglichen Datei allein unzureichend sein.
---
31. Berechtigungsproblem sicher reproduzieren Ein geeigneter Test verändert möglichst wenig und verwendet das tatsächliche Konto. **Testablauf:** ```text 1. Dienstkonto bestimmen 2. Zielobjekt und benötigte Aktion bestimmen 3. Aktuelle Rechte und ACLs sichern 4. Sicherheitsrichtlinien prüfen 5. Lesenden Zugriff im Dienstkontext testen 6. Protokolle auf Quelle und Ziel beobachten 7. Nur bei Bedarf einen freigegebenen Schreibtest verwenden 8. Ergebnis und Rückgabecode dokumentieren 9. Testdateien vollständig entfernen 10. Keine Rechte auf Verdacht erweitern ``` **Ungeeigneter Test:** ```text Als Administrator Datei öffnen ``` **Besserer Test:** ```text Mit tatsächlicher Dienstidentität exakt den benötigten Zugriff prüfen ```
---
32. Warum chmod 777 oder Vollzugriff keine geeignete Diagnose ist Eine pauschale Rechteerweiterung: - verschleiert die ursprünglich fehlende Einzelberechtigung, - kann vertrauliche Daten offenlegen, - erhöht das Risiko einer Manipulation, - kann Sicherheitsrichtlinien verletzen, - behebt SELinux, AppArmor oder TCC möglicherweise trotzdem nicht, - kann nach Updates oder Wiederherstellungen bestehen bleiben, - erschwert die spätere Rücknahme, - widerspricht dem Prinzip der minimalen Rechte. **Besseres Vorgehen:** 1. benötigte Aktion bestimmen, 2. tatsächliches Dienstkonto bestimmen, 3. aktuell fehlende Einzelberechtigung bestimmen, 4. vorgesehene Herstellerberechtigung prüfen, 5. kleinste ausreichende Änderung planen, 6. Änderung dokumentieren, 7. Funktion testen, 8. überflüssige Rechte ausschließen.
---
33. Gruppenmitgliedschaft richtig bewerten Eine neue Gruppenmitgliedschaft ist nicht immer sofort in jedem Prozess wirksam. Mögliche Gründe: - laufender Prozess besitzt ein altes Zugriffstoken, - Benutzer muss sich neu anmelden, - Dienst muss kontrolliert neu gestartet werden, - Gruppenmitgliedschaft wird zwischengespeichert, - verschachtelte Gruppe wird verzögert ausgewertet, - Domänencontroller sind noch nicht repliziert, - Container besitzt eigene Benutzer- und Gruppendatenbank. **Prüfung:** ```text Konto Mitglied der Gruppe? ↓ Gruppe auf Zielobjekt berechtigt? ↓ ACL-Maske oder Deny-Regel berücksichtigt? ↓ Aktuelles Zugriffstoken enthält die Gruppe? ↓ Dienstprozess nach Änderung neu authentifiziert? ``` > Ein Neustart darf erst nach Erfassung des Ausgangszustands und Prüfung der Auswirkungen erfolgen.
---
34. Typische Fehlinterpretationen | Fehlinterpretation | Richtige Bewertung | |---|---| | „Administrator kann zugreifen, also stimmen die Rechte.“ | Dienstkonto besitzt einen anderen Sicherheitskontext | | „Die Datei hat Leserecht, also kann der Dienst sie öffnen.“ | Übergeordnete Verzeichnisse und Sicherheitsrichtlinien zählen ebenfalls | | „Der Benutzer steht in der ACL, also ist der Zugriff erlaubt.“ | Deny-Regeln, Gruppen und ACL-Masken können das Ergebnis verändern | | „Linux-Modus 777 erlaubt immer alles.“ | SELinux, AppArmor, Mountoptionen und Sandbox können weiter blockieren | | „Root darf auf jeden macOS-Pfad zugreifen.“ | SIP und Datenschutzkontrollen können zusätzliche Grenzen setzen | | „Lokales Dienstkonto verwendet denselben Namen am Fileserver.“ | Die Netzwerkidentität kann eine andere sein | | „Gruppenänderung ist sofort wirksam.“ | Laufender Prozess kann ein altes Token besitzen | | „Schreibrecht auf Datei erlaubt das Ersetzen der Datei.“ | Dafür können Rechte auf dem Verzeichnis erforderlich sein | | „Full Disk Access ist die einfachste Lösung.“ | Es ist eine sehr weitreichende Sicherheitsfreigabe | | „Der Dienst benötigt Administratorrechte.“ | Meist muss nur eine konkrete Ressource passend berechtigt werden |
---
35. Checkliste zur Berechtigungsanalyse ```text [ ] Tatsächliches Dienstkonto bestimmt [ ] Benutzerkonto existiert und ist aktiviert [ ] Kontosperre und Kennwortstatus geprüft [ ] Primäre und zusätzliche Gruppen erfasst [ ] UID, GID beziehungsweise SID dokumentiert [ ] Dienstanmelderecht geprüft [ ] Verweigernde Richtlinien berücksichtigt [ ] Zieldatei und benötigte Aktion bestimmt [ ] Rechte aller Pfadbestandteile geprüft [ ] Eigentümer und Gruppe geprüft [ ] ACLs und Vererbung geprüft [ ] ACL-Maske beziehungsweise Deny-Regeln berücksichtigt [ ] Dateisystem-Mountoptionen geprüft [ ] Zugriff im tatsächlichen Konto getestet [ ] Lokalen und entfernten Zugriff getrennt geprüft [ ] Netzwerkidentität des Dienstes bestimmt [ ] Zielsystemprotokoll geprüft [ ] SELinux beziehungsweise AppArmor berücksichtigt [ ] systemd-Sandboxing berücksichtigt [ ] macOS-Datenschutz und SIP berücksichtigt [ ] Container-UID und Volume-Rechte berücksichtigt [ ] Keine pauschale Rechteerweiterung durchgeführt [ ] Kleinste notwendige Änderung bestimmt [ ] Ausgangsberechtigungen vor Änderung gesichert [ ] Funktion und Sicherheit nach Änderung geprüft ```
--- **Bewertung des Ergebnisses** | Ergebnis | Nächster Schritt | |---|---| | Dienstkonto ungültig oder gesperrt | Kontostatus und Verwaltungsprozess prüfen | | Dienstanmeldung schlägt fehl | Kennwort, Anmelderecht und Richtlinien prüfen | | Datei kann nicht gelesen werden | Pfad-, Datei- und ACL-Rechte prüfen | | Datei lesbar, aber nicht schreibbar | Datei- und Verzeichnisrechte getrennt prüfen | | Lokaler Zugriff funktioniert, Remotezugriff nicht | Netzwerkidentität und Zielberechtigung prüfen | | Klassische Rechte stimmen, Zugriff bleibt verweigert | SELinux, AppArmor, Sandbox oder macOS-Datenschutz prüfen | | Gruppenrecht fehlt im laufenden Prozess | Token- beziehungsweise Prozessneuerstellung planen | | Container kann Volume nicht beschreiben | UID-, GID-, Mount- und Sicherheitslabel prüfen | | Zugriff funktioniert nur als Administrator | Fehlende Einzelberechtigung des Dienstkontos bestimmen | | Alle Berechtigungen stimmen | Ressourcen, Konfiguration und Anwendungslogik untersuchen | --- **Merksatz** > **Berechtigungen werden nicht danach bewertet, was ein Administrator darf, sondern danach, was das tatsächliche Dienstkonto im echten Laufzeit- und Zielsystemkontext darf.** --- **Weiterführende Quellen** - [Microsoft Learn – Service User Accounts](https://learn.microsoft.com/windows/win32/services/service-user-accounts) - [Microsoft Learn – About Service Logon Accounts](https://learn.microsoft.com/windows/win32/ad/about-service-logon-accounts) - [Microsoft Learn – whoami](https://learn.microsoft.com/windows-server/administration/windows-commands/whoami) - [Microsoft Learn – Get-Acl](https://learn.microsoft.com/powershell/module/microsoft.powershell.security/get-acl) - [Microsoft Learn – icacls](https://learn.microsoft.com/windows-server/administration/windows-commands/icacls) - [Microsoft Sysinternals – AccessChk](https://learn.microsoft.com/sysinternals/downloads/accesschk) - [Microsoft Learn – sc.exe qprivs](https://learn.microsoft.com/windows-server/administration/windows-commands/sc-qprivs) - [Linux-Handbuch – credentials](https://man7.org/linux/man-pages/man7/credentials.7.html) - [Linux-Handbuch – path_resolution](https://man7.org/linux/man-pages/man7/path_resolution.7.html) - [Linux-Handbuch – acl](https://man7.org/linux/man-pages/man5/acl.5.html) - [Linux-Handbuch – getfacl](https://man7.org/linux/man-pages/man1/getfacl.1.html) - [systemd – systemd.exec](https://www.freedesktop.org/software/systemd/man/latest/systemd.exec.html) - [Apple Platform Security – Zugriff von Apps auf Dateien](https://support.apple.com/de-de/guide/security/secddd1d86a6/web) - [Apple Support – Einstellungen für Datenschutz und Sicherheit](https://support.apple.com/de-de/guide/mac-help/mchl211c911f/mac) - [Apple Support – Dateiberechtigungen und umask](https://support.apple.com/de-de/101914) - [Apple – launchd.plist-Handbuchseite](https://keith.github.io/xcode-man-pages/launchd.plist.5.html) # 4.10 Ressourcenengpässe erkennen Ein Dienst kann korrekt konfiguriert sein und trotzdem langsam, instabil oder nicht erreichbar werden, wenn ihm oder dem Gesamtsystem benötigte Ressourcen fehlen. > **Grundsatz:** > Ein einzelner hoher Messwert beweist noch keinen Engpass. Entscheidend sind Messdauer, Vergleichswerte, Auslastungsursache und der zeitliche Zusammenhang mit der Störung. --- **Ziele dieser Seite** Nach dieser Seite sollst du: - CPU-, Arbeitsspeicher- und I/O-Engpässe erkennen können, - Lastspitzen von dauerhaftem Ressourcenmangel unterscheiden können, - System- und Prozesswerte getrennt untersuchen können, - physischen, virtuellen und residenten Speicher unterscheiden können, - Paging und Swapping richtig bewerten können, - Datenträgerlatenz und Warteschlangen berücksichtigen können, - Handle-, Thread-, Prozess- und Dateideskriptorgrenzen prüfen können, - Ressourcenwerte über mehrere Messpunkte beobachten können, - Betriebssystemprotokolle nach Ressourcenfehlern durchsuchen können, - Ergebnisse mit dem Zeitpunkt einer Dienststörung verbinden können. ---
1. Welche Ressourcen können einen Dienst begrenzen? | Ressource | Typisches Fehlerbild | |---|---| | CPU | Hohe Antwortzeiten, Zeitüberschreitungen, verzögerte Verarbeitung | | Arbeitsspeicher | Paging, Prozessabbrüche, fehlgeschlagene Allokationen | | Swap beziehungsweise Auslagerungsdatei | Hohe Latenz durch Speicherauslagerung | | Datenträger-I/O | Lange Wartezeiten, blockierte Prozesse, langsame Datenbank | | Speicherplatz | Schreiben, Starten oder Protokollieren schlägt fehl | | Inodes | Linux kann trotz freiem Speicherplatz keine Dateien anlegen | | Dateideskriptoren | Neue Dateien oder Sockets können nicht geöffnet werden | | Windows-Handles | Zugriff auf Dateien, Registry, Events oder Prozesse schlägt fehl | | Threads | Neue Aufgaben oder Verbindungen können nicht verarbeitet werden | | Prozesslimit | Neue Prozesse können nicht erzeugt werden | | Netzwerkbandbreite | Langsame Übertragung und Warteschlangen | | Verbindungspool | Neue Datenbank- oder HTTP-Verbindungen warten | | Portbereich | Neue ausgehende TCP-Verbindungen schlagen fehl | | GPU oder Beschleuniger | Spezialisierte Berechnung kann nicht ausgeführt werden | | Quota | Benutzer oder Dienst darf keine weiteren Daten speichern | | Containerlimit | Dienst erreicht CPU-, RAM- oder Prozessgrenze des Containers |
---
2. Auslastung und Engpass unterscheiden | Zustand | Beschreibung | |---|---| | Auslastung | Eine Ressource wird verwendet | | Hohe Auslastung | Ressource wird stark verwendet, Dienst funktioniert aber noch | | Sättigung | Neue Arbeit muss warten | | Engpass | Ressourcenbegrenzung beeinträchtigt die benötigte Funktion | | Überlast | Eingehende Arbeit übersteigt dauerhaft die Verarbeitungskapazität | | Ressourcenleck | Verbrauch steigt, obwohl abgeschlossene Arbeit Ressourcen freigeben sollte | | Grenzwertfehler | Konfiguriertes Limit wird vor der technischen Kapazität erreicht | **Beispiel:** ```text CPU-Auslastung: 95 % Antwortzeit: normal Warteschlange: niedrig Fehler: keine ``` Das ist hohe Auslastung, aber noch kein bewiesener Engpass. ```text CPU-Auslastung: 95 % Antwortzeit: stark erhöht Warteschlange: wächst Timeouts: vorhanden ``` Hier besteht ein belastbarer Hinweis auf CPU-Sättigung.
---
3. Immer über mehrere Messpunkte prüfen Eine Momentaufnahme kann zufällig während einer kurzen Lastspitze entstehen. **Empfohlene Messstruktur:** ```text Zeitpunkt CPU gesamt CPU des Dienstprozesses verfügbarer Arbeitsspeicher Swap- beziehungsweise Paging-Aktivität Datenträger-I/O und Wartezeit Anzahl aktiver Anfragen Anwendungsantwortzeit Fehlerrate ``` **Sinnvolle Vergleichszeiträume:** - unmittelbar vor der Störung, - während der Störung, - unmittelbar danach, - normaler Vergleichszeitraum, - gleiche Uhrzeit an einem störungsfreien Tag, - Zustand vor und nach einer Maßnahme. > Ein Messwerkzeug erzeugt selbst Last. Abtastrate, Anzahl der Messwerte und Detailgrad müssen zum System passen.
---
4. Schnellübersicht für Windows, Linux und macOS | Aufgabe | Windows | Linux | macOS | |---|---|---|---| | Systemlaufzeit | `[RO] (Get-Date) - (Get-CimInstance Win32_OperatingSystem).LastBootUpTime` | `[RO] uptime` | `[RO] uptime` | | Logische Prozessoren | `[RO] (Get-CimInstance Win32_ComputerSystem).NumberOfLogicalProcessors` | `[RO] nproc` | `[RO] sysctl -n hw.logicalcpu` | | Prozessübersicht | `[RO] Get-Process` | `[RO] top` | `[RO] top` | | Speicherübersicht | `[RO] Get-CimInstance Win32_OperatingSystem` | `[RO] free -h` | `[RO] memory_pressure` | | Swap | `[RO] Get-CimInstance Win32_PageFileUsage` | `[RO] swapon --show` | `[RO] sysctl vm.swapusage` | | Datenträgerübersicht | `[RO] Get-Volume` | `[RO] iostat` | `[RO] iostat` | | Prozesslimits | Betriebssystemspezifisch | `[RO][FILE] cat /proc//limits` | `[RO] launchctl limit` | | Systemprotokolle | `[RO] Get-WinEvent` | `[RO][PRIV] sudo journalctl` | `[RO][PRIV] sudo log show` |
---
5. CPU-Grunddaten unter Windows prüfen **Anzahl logischer Prozessoren anzeigen:** ```powershell [RO] Get-CimInstance Win32_ComputerSystem | Select-Object NumberOfProcessors, NumberOfLogicalProcessors ``` **Gesamte CPU-Auslastung als Momentaufnahme:** ```powershell [RO] Get-CimInstance ` Win32_PerfFormattedData_PerfOS_Processor ` -Filter "Name='_Total'" | Select-Object Name, PercentProcessorTime, PercentUserTime, PercentPrivilegedTime, PercentIdleTime ``` **Mehrere Messpunkte mit Get-Counter erfassen:** ```powershell [RO] Get-Counter ` -Counter '\Processor(_Total)\% Processor Time' ` -SampleInterval 2 ` -MaxSamples 5 ``` > Die Namen klassischer Windows-Leistungsindikatoren können auf lokalisierten Windows-Systemen übersetzt sein. Falls ein Counterpfad nicht gefunden wird, müssen die auf diesem System vorhandenen Zählersätze ermittelt werden. **Verfügbare Zählersätze suchen:** ```powershell [RO] Get-Counter -ListSet * | Select-Object CounterSetName | Sort-Object CounterSetName ```
---
6. CPU-verbrauchende Windows-Prozesse ermitteln **Prozesse nach kumulierter CPU-Zeit sortieren:** ```powershell [RO] Get-Process | Sort-Object CPU -Descending | Select-Object -First 15 Id, ProcessName, CPU, StartTime ``` Die Eigenschaft `CPU` enthält die gesamte bisher verbrauchte Prozessorzeit des Prozesses in Sekunden. Sie ist kein momentaner Prozentwert. **Momentane Prozessauslastung über formatierte Leistungsdaten:** ```powershell [RO] Get-CimInstance Win32_PerfFormattedData_PerfProc_Process | Where-Object Name -NotIn "_Total", "Idle" | Sort-Object PercentProcessorTime -Descending | Select-Object -First 15 Name, IDProcess, PercentProcessorTime, ThreadCount, WorkingSetPrivate ``` **Bestimmte PID untersuchen:** ```powershell [RO] Get-Process -Id | Select-Object Id, ProcessName, StartTime, CPU, Threads, HandleCount ``` > Die Prozess-CPU-Ausgabe kann bei mehreren logischen Prozessoren anders skaliert wirken als die gesamte Systemauslastung. Werte müssen im Kontext des verwendeten Messwerkzeugs interpretiert werden.
---
7. Arbeitsspeicher unter Windows prüfen **Gesamten und freien physischen Speicher anzeigen:** ```powershell [RO] Get-CimInstance Win32_OperatingSystem | Select-Object @{ Name="TotalRAM_GiB" Expression={[math]::Round($_.TotalVisibleMemorySize / 1MB, 2)} }, @{ Name="FreeRAM_GiB" Expression={[math]::Round($_.FreePhysicalMemory / 1MB, 2)} }, @{ Name="FreeVirtualMemory_GiB" Expression={[math]::Round($_.FreeVirtualMemory / 1MB, 2)} } ``` Die CIM-Werte werden hier von KiB in GiB umgerechnet. **Speicherindikatoren als Momentaufnahme:** ```powershell [RO] Get-CimInstance Win32_PerfFormattedData_PerfOS_Memory | Select-Object AvailableMBytes, PercentCommittedBytesInUse, PagesPerSec, PageReadsPerSec, PageWritesPerSec, PoolPagedBytes, PoolNonpagedBytes ``` **Mehrere Messpunkte des verfügbaren Speichers:** ```powershell [RO] Get-Counter ` -Counter '\Memory\Available MBytes' ` -SampleInterval 2 ` -MaxSamples 5 ``` > Ein niedriger Wert bei „freiem“ Speicher ist nicht automatisch ein Fehler, weil Betriebssysteme ungenutzten Speicher als Cache verwenden. Verfügbarer Speicher, Paging-Aktivität und Anwendungsfunktion müssen gemeinsam betrachtet werden.
---
8. Speicherverbrauch von Windows-Prozessen prüfen **Nach Working Set sortieren:** ```powershell [RO] Get-Process | Sort-Object WorkingSet64 -Descending | Select-Object -First 15 Id, ProcessName, @{ Name="WorkingSet_MiB" Expression={[math]::Round($_.WorkingSet64 / 1MB, 2)} }, @{ Name="PrivateMemory_MiB" Expression={[math]::Round($_.PrivateMemorySize64 / 1MB, 2)} } ``` **Bestimmten Prozess untersuchen:** ```powershell [RO] Get-Process -Id | Select-Object Id, ProcessName, WorkingSet64, PrivateMemorySize64, VirtualMemorySize64, PagedMemorySize64, PeakWorkingSet64 ``` | Wert | Bedeutung | |---|---| | `WorkingSet64` | Derzeit im physischen Speicher befindliche Seiten | | `PrivateMemorySize64` | Privat zugeordneter Speicher | | `VirtualMemorySize64` | Virtueller Adressraum | | `PagedMemorySize64` | Auslagerungsfähiger Speicher | | `PeakWorkingSet64` | Bisheriger Höchstwert des Working Sets | > Virtueller Speicher darf nicht direkt mit physisch belegtem RAM gleichgesetzt werden.
---
9. Windows-Auslagerungsdatei prüfen **Nutzung der Auslagerungsdatei anzeigen:** ```powershell [RO] Get-CimInstance Win32_PageFileUsage | Select-Object Name, AllocatedBaseSize, CurrentUsage, PeakUsage ``` Die Größen werden üblicherweise in MiB angegeben. **Konfiguration der Auslagerungsdatei anzeigen:** ```powershell [RO] Get-CimInstance Win32_PageFileSetting | Select-Object Name, InitialSize, MaximumSize ``` Mögliche Hinweise auf Speicherdruck: - `PercentCommittedBytesInUse` bleibt sehr hoch, - verfügbarer Speicher bleibt niedrig, - Page Reads steigen dauerhaft, - Anwendungen melden fehlenden virtuellen Speicher, - Prozesse werden beendet, - Antwortzeiten verschlechtern sich parallel zur Paging-Aktivität. > Das Vorhandensein einer verwendeten Auslagerungsdatei ist nicht automatisch ein Fehler. Entscheidend ist eine dauerhaft hohe Paging-Aktivität zusammen mit Leistungsproblemen.
---
10. Windows-Datenträger-I/O prüfen **Formatierte Datenträgerleistungsdaten anzeigen:** ```powershell [RO] Get-CimInstance Win32_PerfFormattedData_PerfDisk_PhysicalDisk | Where-Object Name -ne "_Total" | Select-Object Name, DiskReadsPerSec, DiskWritesPerSec, DiskReadBytesPerSec, DiskWriteBytesPerSec, AvgDiskQueueLength, CurrentDiskQueueLength, PercentDiskTime ``` **Mehrere Messpunkte mit Get-Counter:** ```powershell [RO] Get-Counter ` -Counter '\PhysicalDisk(*)\Avg. Disk sec/Read', '\PhysicalDisk(*)\Avg. Disk sec/Write', '\PhysicalDisk(*)\Current Disk Queue Length' ` -SampleInterval 2 ` -MaxSamples 5 ``` Auch hier können lokalisierte Leistungsindikatornamen abweichen. **Zu prüfen:** - steigt die Warteschlange dauerhaft? - sind Lese- oder Schreiblatenzen erhöht? - ist nur ein Datenträger betroffen? - korreliert die I/O-Last mit dem Dienstfehler? - erzeugt Sicherung, Virenscan oder Update gleichzeitig Last? - ist das Volume lokal, virtuell oder netzwerkbasiert? - meldet das System zusätzlich Datenträgerfehler?
---
11. Windows-Handles und Threads prüfen **Gesamtanzahl von Prozessen, Threads und Handles:** ```powershell [RO] Get-CimInstance Win32_PerfFormattedData_PerfOS_System | Select-Object Processes, Threads ``` ```powershell [RO] Get-CimInstance Win32_PerfFormattedData_PerfOS_Objects | Select-Object Processes, Threads, Events, Mutexes, Sections, Semaphores ``` **Prozesse nach Handleanzahl sortieren:** ```powershell [RO] Get-Process | Sort-Object HandleCount -Descending | Select-Object -First 15 Id, ProcessName, HandleCount, @{ Name="ThreadCount" Expression={$_.Threads.Count} } ``` **Bestimmten Prozess prüfen:** ```powershell [RO] Get-Process -Id | Select-Object Id, ProcessName, HandleCount, @{ Name="ThreadCount" Expression={$_.Threads.Count} } ``` Ein mögliches Ressourcenleck zeigt sich eher durch kontinuierliches Wachstum als durch einen einzelnen hohen Wert.
---
12. Windows-Protokolle nach Ressourcenfehlern durchsuchen **Systemereignisse der letzten zwei Stunden:** ```powershell [RO][SENS] Get-WinEvent -FilterHashtable @{ LogName = "System" StartTime = (Get-Date).AddHours(-2) Level = 1, 2, 3 } | Select-Object TimeCreated, ProviderName, Id, LevelDisplayName, Message ``` **System- und Anwendungsereignisse gemeinsam:** ```powershell [RO][SENS] Get-WinEvent -FilterHashtable @{ LogName = "System", "Application" StartTime = (Get-Date).AddHours(-2) } | Where-Object Message -Match "memory|resource|disk|paging|quota|handle|thread" | Sort-Object TimeCreated | Select-Object TimeCreated, LogName, ProviderName, Id, Message ``` > Textfilter hängen von Sprache und Formulierung der Ereignismeldung ab. Anbieter, Ereignis-ID und Zeitfenster sind zuverlässigere zusätzliche Filter.
---
13. CPU und Load Average unter Linux prüfen **Systemlaufzeit und Load Average anzeigen:** ```bash [RO] uptime ``` **Nur Load Average anzeigen:** ```bash [RO][FILE] cat /proc/loadavg ``` **Anzahl verfügbarer Verarbeitungseinheiten anzeigen:** ```bash [RO] nproc ``` **Interaktive Prozessübersicht:** ```bash [RO] top ``` **Nach CPU-Verbrauch sortieren:** ```bash [RO] ps -eo pid,ppid,user,stat,%cpu,%mem,etime,comm \ --sort=-%cpu | head -n 16 ``` **Falls sysstat installiert ist – CPU je Prozessor messen:** ```bash [RO] mpstat -P ALL 2 5 ``` > `mpstat`, `pidstat` und `iostat` gehören häufig zum Paket `sysstat`, sind aber nicht auf jeder Installation vorhanden.
---
14. Linux Load Average richtig interpretieren Die drei Load-Average-Werte beziehen sich üblicherweise auf ungefähr: ```text 1 Minute 5 Minuten 15 Minuten ``` Load Average ist nicht dasselbe wie CPU-Prozent. Unter Linux werden dabei auch bestimmte Prozesse in nicht unterbrechbarem Wartezustand berücksichtigt. **Grobe Einordnung:** ```text Load Average geteilt durch Anzahl verfügbarer CPUs ``` Dies ist nur eine Orientierung. | Beobachtung | Mögliche Interpretation | |---|---| | Hoher Load und hohe CPU-Nutzung | CPU-Sättigung möglich | | Hoher Load und niedrige CPU-Nutzung | I/O-Wartezustände möglich | | Kurzzeitig hoher 1-Minuten-Wert | Lastspitze | | Hohe 1-, 5- und 15-Minuten-Werte | Länger andauernde Belastung | | Load steigt, Warteschlange wächst | System verarbeitet Arbeit nicht schnell genug | > Ein Load-Wert von `4` ist auf einem System mit zwei CPUs anders zu bewerten als auf einem System mit 32 CPUs.
---
15. Linux-CPU über mehrere Messpunkte prüfen **Systemweite Messreihe mit vmstat:** ```bash [RO] vmstat 2 5 ``` Wichtige Spalten: | Spalte | Bedeutung | |---|---| | `r` | Ausführungsbereite Prozesse | | `b` | Prozesse in blockiertem Zustand | | `us` | CPU-Zeit im Benutzerbereich | | `sy` | CPU-Zeit im Kernelbereich | | `id` | Leerlauf | | `wa` | I/O-Wartezeit | | `st` | Durch Hypervisor entnommene CPU-Zeit | | `si` | Swap-In | | `so` | Swap-Out | > Die erste Zeile von `vmstat` kann Durchschnittswerte seit dem Systemstart darstellen. Für eine aktuelle Bewertung sind die folgenden Intervallzeilen wichtiger. **Bestimmten Prozess mit installiertem pidstat beobachten:** ```bash [RO] pidstat -p 2 5 ``` **Alle Prozesse mit hoher CPU-Aktivität beobachten:** ```bash [RO] pidstat -u 2 5 ```
---
16. Arbeitsspeicher unter Linux prüfen **Lesbare Speicherübersicht:** ```bash [RO] free -h ``` **Kernel-Speicherinformationen:** ```bash [RO][FILE] cat /proc/meminfo ``` Wichtige Werte: | Wert | Bedeutung | |---|---| | `MemTotal` | Gesamter physischer Speicher | | `MemFree` | Vollständig ungenutzter Speicher | | `MemAvailable` | Schätzung des für neue Anwendungen verfügbaren Speichers | | `Buffers` | Pufferspeicher | | `Cached` | Dateicache | | `SwapTotal` | Gesamter Swap | | `SwapFree` | Freier Swap | | `Dirty` | Noch nicht auf Datenträger geschriebene Seiten | | `Slab` | Kernel-Datenstrukturen | > Für die praktische Bewertung ist `MemAvailable` meist aussagekräftiger als `MemFree`, weil Linux freien RAM bewusst als Cache nutzt.
---
17. Linux-Prozesse nach Speicherverbrauch untersuchen **Nach residentem Speicher sortieren:** ```bash [RO] ps -eo pid,ppid,user,stat,%cpu,%mem,rss,vsz,etime,comm \ --sort=-rss | head -n 16 ``` **Bestimmten Prozess anzeigen:** ```bash [RO][SENS] ps -p \ -o user,pid,ppid,stat,%cpu,%mem,rss,vsz,etime,cmd ``` **Detaillierte Prozessspeicherwerte:** ```bash [RO][FILE][SENS] cat "/proc//status" ``` Relevant sind unter anderem: ```text VmPeak VmSize VmHWM VmRSS RssAnon RssFile VmSwap Threads ``` | Wert | Bedeutung | |---|---| | `VmSize` | Virtueller Adressraum | | `VmRSS` | Residenter physischer Speicher | | `VmHWM` | Bisheriger Höchstwert des residenten Speichers | | `VmSwap` | Für den Prozess ausgelagerter Speicher | | `Threads` | Threadanzahl |
---
18. Swap und Paging unter Linux prüfen **Aktive Swap-Bereiche anzeigen:** ```bash [RO] swapon --show ``` **Gesamtnutzung anzeigen:** ```bash [RO] free -h ``` **Swap-Aktivität über mehrere Messpunkte:** ```bash [RO] vmstat 2 5 ``` Relevant: | Spalte | Bedeutung | |---|---| | `si` | Von Swap eingelesene Daten | | `so` | In Swap geschriebene Daten | **Bewertung:** - verwendeter Swap allein beweist keinen aktuellen Engpass, - dauerhaft hohe Werte bei `si` und `so` weisen auf aktiven Speicherdruck hin, - gleichzeitige hohe I/O-Wartezeit kann die Anwendung stark verlangsamen, - einzelne Prozesse können einen großen Teil des Speichers belegen, - ein Container kann sein eigenes Speicherlimit erreichen, obwohl der Host noch freien RAM besitzt.
---
19. Linux-Datenträger-I/O prüfen **Grundlegende Datenträgerstatistik:** ```bash [RO] iostat ``` **Falls sysstat installiert ist – erweiterte Messreihe:** ```bash [RO] iostat -xz 2 5 ``` Wichtige Felder können je nach Version enthalten: | Feld | Bedeutung | |---|---| | `r/s` | Lesevorgänge pro Sekunde | | `w/s` | Schreibvorgänge pro Sekunde | | `rkB/s` | Gelesene KiB pro Sekunde | | `wkB/s` | Geschriebene KiB pro Sekunde | | `await` | Durchschnittliche Wartezeit | | `aqu-sz` | Durchschnittliche Warteschlangenlänge | | `%util` | Anteil der Zeit mit aktiven I/O-Anfragen | **Prozessbezogene I/O-Aktivität mit pidstat:** ```bash [RO] pidstat -d 2 5 ``` > `%util` und Warteschlangenwerte müssen zur Datenträgerart und Speicherarchitektur passend bewertet werden. RAID, SSD, SAN und virtuelle Datenträger verhalten sich unterschiedlich.
---
20. Linux Pressure Stall Information prüfen Auf unterstützten Linux-Kernels stehen Druckinformationen unter `/proc/pressure` bereit. **CPU-Druck:** ```bash [RO][FILE] cat /proc/pressure/cpu ``` **Speicherdruck:** ```bash [RO][FILE] cat /proc/pressure/memory ``` **I/O-Druck:** ```bash [RO][FILE] cat /proc/pressure/io ``` Mögliche Zeilen: ```text some full ``` | Wert | Bedeutung | |---|---| | `some` | Mindestens eine Aufgabe wurde durch Ressourcenmangel verzögert | | `full` | Alle nicht im Leerlauf befindlichen Aufgaben waren gleichzeitig verzögert | | `avg10` | Durchschnitt der letzten 10 Sekunden | | `avg60` | Durchschnitt der letzten 60 Sekunden | | `avg300` | Durchschnitt der letzten 300 Sekunden | | `total` | Kumulierte Verzögerungszeit in Mikrosekunden | > Fehlen die Dateien, unterstützt oder aktiviert das System diese Schnittstelle möglicherweise nicht.
---
21. Linux-Dateideskriptor- und Prozessgrenzen prüfen **Grenzwerte eines laufenden Prozesses:** ```bash [RO][FILE] cat "/proc//limits" ``` Besonders relevant: ```text Max open files Max processes Max locked memory Max address space Max core file size ``` **Anzahl geöffneter Dateideskriptoren:** ```bash [RO][PRIV] sudo find "/proc//fd" \ -mindepth 1 \ -maxdepth 1 \ -printf '.' | wc -c ``` **systemd-Grenzwerte anzeigen:** ```bash [RO] systemctl show "" \ --property=LimitNOFILE,LimitNPROC,TasksCurrent,TasksMax,MemoryCurrent,MemoryMax,CPUQuotaPerSecUSec ``` **Aktuelle Shell-Grenzen anzeigen:** ```bash [RO] ulimit -a ``` > `ulimit -a` zeigt die Grenzen der aktuellen Shell und nicht automatisch die Grenzen eines bereits laufenden Dienstes.
---
22. Linux-Protokolle nach Ressourcenfehlern durchsuchen **Warnungen und Fehler des aktuellen Systemstarts:** ```bash [RO][SENS][PRIV] sudo journalctl \ -b \ -p warning \ --no-pager ``` **Kernelmeldungen nach Speicherproblemen durchsuchen:** ```bash [RO][SENS][PRIV] sudo journalctl \ -k \ -b \ --no-pager | grep -i -E -- "out of memory|oom|killed process|memory cgroup" ``` **Nach I/O- und Dateisystemproblemen suchen:** ```bash [RO][SENS][PRIV] sudo journalctl \ -k \ -b \ --no-pager | grep -i -E -- "i/o error|filesystem|read-only|blocked for more than" ``` **Dienstprotokoll im Störungszeitraum:** ```bash [RO][SENS][PRIV] sudo journalctl \ -u "" \ --since "2026-07-31 09:10:00" \ --until "2026-07-31 09:20:00" \ --no-pager ```
---
23. CPU und Load Average unter macOS prüfen **Systemlaufzeit und Load Average:** ```bash [RO] uptime ``` **Logische und physische CPUs:** ```bash [RO] sysctl -n hw.logicalcpu ``` ```bash [RO] sysctl -n hw.physicalcpu ``` **Interaktive Übersicht nach CPU-Nutzung:** ```bash [RO] top -o cpu ``` **Fünf Messungen im Abstand von zwei Sekunden:** ```bash [RO] top \ -l 5 \ -s 2 \ -o cpu \ -stats pid,command,cpu,mem,threads,state,time ``` **Bestimmten Prozess beobachten:** ```bash [RO] top \ -l 5 \ -s 2 \ -pid \ -stats pid,command,cpu,mem,threads,state,time ``` > Bei `top -l` kann die erste CPU-Messung ungeeignet sein, weil zur Prozentberechnung noch kein vollständiges vorheriges Intervall vorliegt.
---
24. Speicher unter macOS prüfen **Speicherdruck anzeigen:** ```bash [RO] memory_pressure ``` **Virtuelle Speicherstatistik:** ```bash [RO] vm_stat ``` **Gesamten physischen Speicher anzeigen:** ```bash [RO] sysctl -n hw.memsize ``` **Swap-Nutzung anzeigen:** ```bash [RO] sysctl vm.swapusage ``` **Prozesse nach Speicherverbrauch sortieren:** ```bash [RO] ps -Amcwwxo pid,ppid,user,state,%cpu,%mem,rss,vsz,etime,command ``` **Bestimmten Prozess anzeigen:** ```bash [RO][SENS] ps -p \ -o user,pid,ppid,state,%cpu,%mem,rss,vsz,etime,command ``` > macOS verwaltet Arbeitsspeicher unter anderem durch Cache, Kompression und Swap. „Freier Speicher“ allein ist deshalb weniger aussagekräftig als Speicherdruck, Swap-Aktivität und Anwendungsreaktion.
---
25. vm_stat unter macOS interpretieren `vm_stat` zeigt Speicherwerte in Seiten an. Die Seitengröße wird in der ersten Ausgabezeile genannt. Wichtige Werte können sein: | Wert | Bedeutung | |---|---| | `Pages free` | Freie Seiten | | `Pages active` | Aktiv verwendete Seiten | | `Pages inactive` | Inaktive, möglicherweise wiederverwendbare Seiten | | `Pages speculative` | Spekulativ geladene Seiten | | `Pages wired down` | Nicht auslagerbarer Speicher | | `Pages occupied by compressor` | Durch Speicherkompression belegte Seiten | | `Pageins` | Vom Datenträger eingelesene Seiten | | `Pageouts` | Auf Datenträger ausgelagerte Seiten | | `Swapins` | Aus Swap eingelesene Seiten | | `Swapouts` | In Swap geschriebene Seiten | > Viele Werte sind kumuliert seit dem Systemstart. Für aktuelle Aktivität müssen Messungen über einen definierten Zeitraum verglichen werden.
---
26. Datenträger-I/O unter macOS prüfen **Datenträgerübersicht:** ```bash [RO] iostat ``` **Fünf Messungen im Abstand von zwei Sekunden:** ```bash [RO] iostat -w 2 -c 5 ``` **CPU- und Datenträgerstatistik ausführlicher anzeigen:** ```bash [RO] iostat -d -c 5 -w 2 ``` **Prozessbezogene Beobachtung mit top:** ```bash [RO] top \ -l 5 \ -s 2 \ -o cpu \ -stats pid,command,cpu,mem,purg,cmprs,pageins,faults ``` Zu prüfen: - steigt Datenträgeraktivität während der Störung? - tritt gleichzeitig Speicherdruck auf? - verursacht ein anderer Prozess hohe I/O-Last? - ist das Ziel ein internes, externes oder Netzwerkvolume? - gibt es Dateisystem- oder Hardwaremeldungen? - wird gleichzeitig gesichert, indiziert oder aktualisiert?
---
27. Prozess- und Dateigrenzen unter macOS prüfen **Grenzwerte von launchd anzeigen:** ```bash [RO] launchctl limit ``` **Grenzwerte der aktuellen Shell anzeigen:** ```bash [RO] ulimit -a ``` **Offene Ressourcen eines Prozesses anzeigen:** ```bash [RO][SENS][PRIV] sudo lsof -nP -p ``` **Anzahl der ausgegebenen offenen Ressourcen grob zählen:** ```bash [RO][SENS][PRIV] sudo lsof -nP -p | wc -l ``` Die Kopfzeile von `lsof` wird dabei mitgezählt. **Threadanzahl anzeigen:** ```bash [RO] ps -M -p ``` > Die Grenzwerte einer Shell sind nicht automatisch mit denen eines launchd-Dienstes identisch. Für den Dienst müssen launchd-Konfiguration, Prozesskontext und tatsächlicher Verbrauch berücksichtigt werden.
---
28. macOS-Protokolle nach Ressourcenproblemen prüfen **Fehler und Faults der letzten Stunde:** ```bash [RO][SENS][PRIV] sudo log show \ --last 1h \ --predicate 'messageType == error OR messageType == fault' \ --style compact \ --no-pager ``` **Dienstprozess filtern:** ```bash [RO][SENS][PRIV] sudo log show \ --last 1h \ --predicate 'process == ""' \ --style compact \ --no-pager ``` **Nach ressourcenbezogenen Meldungstexten suchen:** ```bash [RO][SENS][PRIV] sudo log show \ --last 1h \ --predicate 'eventMessage CONTAINS[c] "memory" OR eventMessage CONTAINS[c] "resource" OR eventMessage CONTAINS[c] "disk"' \ --style compact \ --no-pager ``` > Textfilter sind nur eine Ergänzung. Prozess, Zeitfenster, Subsystem und konkrete Fehlermeldung müssen ebenfalls berücksichtigt werden.
---
29. CPU-Engpass systematisch erkennen **Belastbare Hinweise:** - CPU-Auslastung bleibt über längere Zeit hoch, - ausführungsbereite Prozesse warten, - Antwortzeiten steigen gleichzeitig, - Anwendungswarteschlange wächst, - Timeouts treten auf, - ein bestimmter Prozess oder Thread verursacht den Großteil der Last, - virtueller Host meldet hohe CPU-Steal- oder Ready-Zeit, - CPU-Limit eines Containers wird erreicht. **Mögliche Ursachen:** - regulär hohe Benutzerlast, - Endlosschleife, - fehlerhafte Abfrage, - Kompression oder Verschlüsselung, - Virenscan, - Sicherung, - Softwareupdate, - zu viele Prozesse oder Threads, - zu niedriges Containerlimit, - fehlende Hardwarebeschleunigung. **Nicht ausreichend als Beweis:** ```text Ein einzelner Messwert von 100 % ```
---
30. Arbeitsspeicherengpass systematisch erkennen **Belastbare Hinweise:** - verfügbarer Speicher bleibt dauerhaft niedrig, - Paging oder Swapping ist kontinuierlich aktiv, - Speicherdruck steigt, - Antwortzeiten steigen parallel, - Prozesse werden durch Speichermangel beendet, - Anwendung meldet Allokationsfehler, - Prozessspeicher wächst kontinuierlich, - Container erreicht `MemoryMax` oder sein Plattformlimit, - Cache kann nicht ausreichend zurückgewonnen werden. **Mögliche Ursachen:** - Speicherleck, - zu großer Cache, - unerwartet viele Sitzungen, - zu große Datenmenge, - mehrere speicherintensive Dienste, - zu kleines VM- oder Containerlimit, - fehlerhafte Heap-Konfiguration, - fehlende Begrenzung von Workerprozessen. > Ein Dienstneustart kann den Speicherverbrauch kurzfristig reduzieren, beweist aber nicht, dass die Ursache beseitigt wurde.
---
31. I/O-Engpass systematisch erkennen **Belastbare Hinweise:** - I/O-Wartezeiten steigen, - Warteschlange bleibt gefüllt, - Prozesse verbleiben im Wartezustand, - Datenbankabfragen werden langsam, - Schreibvorgänge blockieren, - gleichzeitig erscheinen I/O- oder Dateisystemfehler, - Netzwerkstorage zeigt hohe Latenz, - Sicherung oder Indizierung erzeugt konkurrierende Last. **Mögliche Ursachen:** - langsamer oder fehlerhafter Datenträger, - RAID-Rebuild, - defekter Datenträger, - überlastetes SAN oder NAS, - hoher Speicherdruck und Paging, - ungeeignete Datenbankabfrage, - fehlender Cache, - Sicherung oder Virenscan, - zu viele parallele Schreibvorgänge, - Volume- oder IOPS-Limit einer Cloudplattform. > Hoher Datendurchsatz kann normal sein. Ein Engpass zeigt sich durch Wartezeit, Warteschlange und beeinträchtigte Anwendung.
---
32. Ressourcenleck erkennen Ein Ressourcenleck wird durch eine Zeitreihe sichtbar. Mögliche Lecks: - Arbeitsspeicher, - Handles, - Dateideskriptoren, - Threads, - Netzwerkverbindungen, - temporäre Dateien, - Datenbankverbindungen, - Warteschlangeneinträge. **Typisches Muster:** ```text Dienststart niedriger Verbrauch nach 1 Stunde höherer Verbrauch nach 6 Stunden weiter gestiegen nach 24 Stunden Grenzwert erreicht nach Dienstneustart wieder niedriger Verbrauch ``` **Nachweisstrategie:** 1. gleiche Messgröße verwenden, 2. regelmäßige Zeitpunkte erfassen, 3. Last und Benutzerzahl mit dokumentieren, 4. Prozessneustarts berücksichtigen, 5. Grenzwert und Fehlereintritt bestimmen, 6. Herstellerdiagnose oder Profiler kontrolliert einsetzen. > Wachstum kann durch einen vorgesehenen Cache entstehen. Ein Leck ist erst wahrscheinlich, wenn Ressourcen trotz abgeschlossener Arbeit nicht angemessen freigegeben werden und der Verbrauch problematisch weiter steigt.
---
33. Virtualisierung und Containerlimits berücksichtigen Ein Gastbetriebssystem kann normale Hostwerte anzeigen, obwohl die Virtualisierungsplattform Ressourcen begrenzt. Zu prüfen: - zugewiesene virtuelle CPUs, - CPU-Limit oder CPU-Anteile, - CPU-Steal- beziehungsweise Ready-Zeit, - zugesicherter und maximaler RAM, - Memory Ballooning, - Host-Swapping, - IOPS- und Durchsatzlimits, - Container-CPU-Quota, - Container-Speicherlimit, - Prozess- beziehungsweise PID-Limit, - gemeinsam verwendete Hostressourcen, - konkurrierende virtuelle Maschinen oder Container. **Typische Fehlinterpretation:** > „Der Host hat noch freien RAM, deshalb kann der Container keinen Speichermangel haben.“ Ein Container kann sein eigenes Limit erreichen, obwohl der Host noch freie Ressourcen besitzt.
---
34. Engpass anhand einer Vergleichsmatrix eingrenzen | CPU | RAM | I/O-Wartezeit | Mögliche Richtung | |---:|---:|---:|---| | Hoch | Normal | Niedrig | CPU-intensive Verarbeitung | | Niedrig | Knapp | Hoch | Paging oder Speicherdruck | | Niedrig | Normal | Hoch | Datenträger- oder Netzwerkstorage | | Hoch | Knapp | Hoch | Gesamtsystem überlastet | | Niedrig | Normal | Niedrig | Externes Backend, Sperre oder Anwendung | | Normal | Verbrauch steigt | Zunehmend | Mögliches Speicherleck | | Normal | Normal | Normal | Anwendungs-, Netzwerk- oder Konfigurationsfehler | Diese Matrix ist eine Eingrenzungshilfe und kein automatischer Ursachenbeweis.
---
35. Typische Fehlinterpretationen | Fehlinterpretation | Richtige Bewertung | |---|---| | „100 Prozent CPU bedeutet immer einen Fehler.“ | Kurze oder produktive Vollauslastung kann normal sein | | „Freier RAM ist niedrig, also fehlt Speicher.“ | Cache und verfügbarer Speicher müssen berücksichtigt werden | | „Swap wird verwendet, also ist das System überlastet.“ | Aktuelle Swap-Aktivität und Speicherdruck sind entscheidend | | „Hoher Datendurchsatz bedeutet I/O-Engpass.“ | Wartezeit und Warteschlange sind entscheidender | | „Load Average entspricht CPU-Prozent.“ | Load berücksichtigt unter Linux weitere Wartezustände | | „Die erste vmstat-Zeile zeigt die aktuelle Last.“ | Sie kann Durchschnittswerte seit dem Start enthalten | | „Get-Process CPU ist der aktuelle Prozentwert.“ | Es ist kumulierte CPU-Zeit | | „Virtueller Speicher ist vollständig belegter RAM.“ | Virtueller Adressraum und residenter Speicher unterscheiden sich | | „Ein Neustart behebt das Ressourcenproblem.“ | Er kann Zähler und Verbrauch nur vorübergehend zurücksetzen | | „Der Host hat Ressourcen, also hat der Container sie ebenfalls.“ | Container und VM können eigene Limits besitzen |
---
36. Dokumentationsvorlage für Ressourcenengpässe ```text Störung: Server: Dienst: Prozess und PID: Betriebssystem: Virtualisiert beziehungsweise containerisiert: Messzeitraum: Abtastintervall: CPU gesamt: CPU des Prozesses: Load Average: Verfügbarer Arbeitsspeicher: Speicher des Prozesses: Swap- beziehungsweise Paging-Aktivität: Datenträgerlatenz: Datenträgerwarteschlange: Dateideskriptor- beziehungsweise Handleanzahl: Threadanzahl: Konfigurierte Limits: Anwendungsantwortzeit: Fehlerrate: Gleichzeitige Benutzer oder Aufgaben: Relevante Protokollmeldung: Vergleichswert: Bewertung: Nächster Prüfschritt: ```
---
37. Checkliste zur Ressourcenanalyse ```text [ ] Störungszeitraum genau bestimmt [ ] System- und Prozesswerte getrennt erfasst [ ] Mehrere Messpunkte aufgenommen [ ] Normalen Vergleichszeitraum bestimmt [ ] Anzahl logischer CPUs berücksichtigt [ ] CPU-Auslastung und Warteschlange geprüft [ ] Load Average richtig eingeordnet [ ] Verfügbaren Arbeitsspeicher geprüft [ ] Prozessspeicher geprüft [ ] Paging beziehungsweise Swapping geprüft [ ] Speicherdruck berücksichtigt [ ] Datenträgerdurchsatz geprüft [ ] I/O-Wartezeit und Warteschlange geprüft [ ] Speicherplatz und Dateisystem grob geprüft [ ] Handle- beziehungsweise Dateideskriptoranzahl geprüft [ ] Thread- und Prozessgrenzen geprüft [ ] Ressourcenlecks über Zeitreihe geprüft [ ] Betriebssystemprotokolle geprüft [ ] Anwendungsprotokolle geprüft [ ] VM- und Containerlimits berücksichtigt [ ] Gleichzeitige Sicherungen und Updates berücksichtigt [ ] Messwerte mit Antwortzeit und Fehlerrate korreliert [ ] Noch keine ungeprüfte Limitänderung durchgeführt [ ] Ursache und nächster Schritt dokumentiert ```
--- **Bewertung des Ergebnisses** | Ergebnis | Nächster Schritt | |---|---| | CPU dauerhaft gesättigt | Verursachenden Prozess, Threads und Arbeitslast untersuchen | | Hoher Load bei niedriger CPU | I/O-Wartezustände und blockierte Prozesse prüfen | | Speicherdruck und aktives Swapping | Prozessspeicher, Limits und mögliches Leck untersuchen | | Prozessverbrauch steigt kontinuierlich | Zeitreihe und Herstellerdiagnose erstellen | | Datenträgerlatenz erhöht | Datenträger, Dateisystem, Storage und konkurrierende Last prüfen | | Dateideskriptor- oder Handlegrenze erreicht | Leck, Grenzwert und benötigte Kapazität untersuchen | | Containerlimit erreicht | Sollressourcen und Plattformkonfiguration prüfen | | Host überlastet | Andere VMs, Container und Hostprozesse berücksichtigen | | Ressourcenwerte normal | Abhängigkeiten, Sperren, Netzwerk und Anwendung untersuchen | | Speicherplatz oder Dateisystem auffällig | Mit Seite 4.11 detailliert weiterprüfen | --- **Merksatz** > **Ein Ressourcenengpass wird nicht durch einen hohen Wert bewiesen, sondern durch dauerhaftes Warten, erreichte Grenzen und eine gleichzeitig beeinträchtigte Dienstfunktion.** --- **Weiterführende Quellen** - [Microsoft Learn – Get-Counter](https://learn.microsoft.com/powershell/module/microsoft.powershell.diagnostics/get-counter) - [Microsoft Learn – Get-Process](https://learn.microsoft.com/powershell/module/microsoft.powershell.management/get-process) - [Microsoft Learn – Get-CimInstance](https://learn.microsoft.com/powershell/module/cimcmdlets/get-ciminstance) - [Microsoft Learn – Win32_Process](https://learn.microsoft.com/windows/win32/cimwin32prov/win32-process) - [Microsoft Learn – Windows-Leistungsüberwachung](https://learn.microsoft.com/windows-server/administration/windows-commands/typeperf) - [Linux-Handbuch – proc_loadavg](https://man7.org/linux/man-pages/man5/proc_loadavg.5.html) - [Linux-Handbuch – proc_meminfo](https://man7.org/linux/man-pages/man5/proc_meminfo.5.html) - [Linux-Handbuch – proc_pid_limits](https://man7.org/linux/man-pages/man5/proc_pid_limits.5.html) - [Linux-Handbuch – proc_pressure](https://man7.org/linux/man-pages/man5/proc_pressure.5.html) - [systemd – systemd.resource-control](https://www.freedesktop.org/software/systemd/man/latest/systemd.resource-control.html) - [Apple – top-Handbuchseite](https://keith.github.io/xcode-man-pages/top.1.html) - [Apple – vm_stat-Handbuchseite](https://keith.github.io/xcode-man-pages/vm_stat.1.html) - [Apple – iostat-Handbuchseite](https://keith.github.io/xcode-man-pages/iostat.8.html) - [Apple – launchctl-Handbuchseite](https://keith.github.io/xcode-man-pages/launchctl.1.html) # 4.11 Speicherplatz- und Dateisystemfehler Speicherplatzprobleme gehören zu den häufigsten Ursachen für Dienststörungen. Dabei muss ein Datenträger nicht vollständig belegt sein: Auch ausgeschöpfte Benutzerquoten, fehlende Inodes, schreibgeschützte Dateisysteme, Snapshots, nicht eingehängte Volumes oder Ein-/Ausgabefehler können Schreibvorgänge verhindern. Typische Auswirkungen sind: - Dienste starten nicht mehr. - Datenbanken können keine Transaktionen schreiben. - Protokoll-, temporäre oder PID-Dateien können nicht erstellt werden. - Updates und Installationen schlagen fehl. - Benutzerprofile werden nicht geladen oder gespeichert. - Anwendungen melden irreführende Zugriffs- oder Datenbankfehler. - Ein Dateisystem wird nach einem Fehler nur noch schreibgeschützt eingebunden. - Dateien wurden gelöscht, belegen aber weiterhin Speicherplatz. - Der Server besitzt freien Speicherplatz, aber eine Quote ist ausgeschöpft. > **Wichtig:** Freier Speicherplatz allein reicht nicht als Prüfung. Untersucht werden müssen Kapazität, Inodes, Quoten, Einhängezustand, Schreibbarkeit, Dateisystemzustand und die zugrunde liegende Speicherhardware. **Kennzeichnung der Befehle** | Kennzeichnung | Bedeutung | |---|---| | `[RO]` | Nur lesender Befehl | | `[TEST]` | Führt eine aktive Prüfung aus | | `[PRIV]` | Erhöhte Berechtigungen erforderlich | | `[FILE]` | Liest Dateien oder Verzeichnisse ein | | `[SENS]` | Ausgabe kann sensible Informationen enthalten | | `[CHANGE]` | Verändert Daten oder Systemzustand | | `[DISRUPT]` | Kann den Betrieb unterbrechen | ---
1. Fehlerbild und betroffenen Speicherpfad bestimmen Zuerst muss festgestellt werden, welcher konkrete Pfad nicht mehr funktioniert. Die Meldung „Datenträger voll“ sagt noch nicht, welches Volume, Dateisystem oder Speichersystem betroffen ist. Zu klären sind: - Welcher Dienst oder Benutzer ist betroffen? - Welche Datei sollte gelesen oder geschrieben werden? - Unter welchem Pfad liegt diese Datei? - Welches Volume beziehungsweise Dateisystem enthält den Pfad? - Handelt es sich um lokalen Speicher oder ein Netzlaufwerk? - Ist der Pfad ein Mountpoint, symbolischer Link oder eine Freigabe? - Ist nur ein Benutzer betroffen oder das gesamte System? - Trat der Fehler nach einem Neustart, Update oder Speicherausbau auf? **Typische Fehlermeldungen** | Fehlermeldung | Mögliche Ursache | |---|---| | `No space left on device` | Speicherplatz oder Inodes ausgeschöpft | | `Disk full` | Datenträger, Quote oder Speicherpool voll | | `Read-only file system` | Dateisystem schreibgeschützt eingebunden | | `Input/output error` | Dateisystem-, Datenträger- oder Controllerfehler | | `Access denied` | Berechtigung, Quote oder schreibgeschützter Pfad | | `File system is corrupt` | Inkonsistente Dateisystemstrukturen | | `The volume is dirty` | Dateisystem wurde nicht sauber getrennt oder weist Fehler auf | | Datei oder Verzeichnis fehlt | Volume möglicherweise nicht eingehängt | | Schreiben funktioniert nur als Administrator | Quote, Berechtigung oder reservierter Speicherbereich | | Freier Speicher wird nach dem Löschen nicht größer | Datei noch geöffnet, Snapshot oder Papierkorb | **Prüffragen** - Ist die Fehlermeldung im Original verfügbar? - Welcher exakte Pfad wird in der Meldung genannt? - Kann eine vorhandene Datei gelesen werden? - Kann im Zielverzeichnis eine neue Datei erstellt werden? - Funktioniert das Schreiben mit einem anderen Benutzer? - Ist das erwartete Volume tatsächlich eingehängt? - Stimmen Zeitpunkt und Umfang des Speicherverbrauchs mit einer Änderung überein? > Ein Schreibtest darf nur in einem dafür vorgesehenen Verzeichnis durchgeführt werden. In Anwendungs-, Datenbank- oder Systemverzeichnissen dürfen nicht unkontrolliert Testdateien angelegt werden.
2. Speicherschichten systematisch eingrenzen Zwischen einer Anwendung und dem physischen Datenträger können mehrere Speicherschichten liegen: 1. Anwendung oder Dienst 2. Datei und Verzeichnis 3. Dateisystem 4. Partition oder Volume 5. LVM-, Storage-Spaces- oder APFS-Container 6. Virtueller Datenträger 7. RAID, SAN, NAS oder Hypervisor-Datastore 8. Controller und physischer Datenträger Ein Fehler kann auf jeder dieser Ebenen auftreten. | Beobachtung | Wahrscheinliche Ebene | |---|---| | Nur eine Anwendung kann nicht schreiben | Anwendung, Pfad, Berechtigung oder Quote | | Alle Anwendungen auf einem Volume sind betroffen | Dateisystem oder Volume | | Volume fehlt nach einem Neustart | Mount-, Geräte- oder Konfigurationsfehler | | Mehrere virtuelle Maschinen sind betroffen | Hypervisor, Datastore, SAN oder NAS | | Betriebssystem meldet Ein-/Ausgabefehler | Datenträger, Controller oder Speicherverbindung | | Gastbetriebssystem zeigt freien Platz, Datastore ist voll | Virtualisierungs- oder Thin-Provisioning-Ebene | | Netzfreigabe ist betroffen, lokaler Speicher funktioniert | Netzwerkdateisystem oder Speicherserver | **Besonderheit bei Thin Provisioning** Bei dynamisch bereitgestelltem Speicher können unterschiedliche Ansichten entstehen: - Das Gastbetriebssystem sieht freien Platz. - Der zugrunde liegende Datastore oder Speicherpool ist jedoch voll. - Eine virtuelle Festplatte besitzt eine große logische Größe, belegt physisch aber weniger. - Snapshots können den realen Verbrauch stark erhöhen. Deshalb müssen bei virtuellen Servern sowohl das Betriebssystem als auch Hypervisor und Speicherplattform kontrolliert werden.
3. Speicherbelegung unter Windows prüfen **Volumes und freien Speicher anzeigen** ```powershell [RO] Get-Volume | Select-Object DriveLetter, FileSystemLabel, FileSystem, HealthStatus, OperationalStatus, SizeRemaining, Size ``` **Belegung in Prozent berechnen** ```powershell [RO] Get-Volume | Where-Object { $_.Size -gt 0 } | Select-Object DriveLetter, FileSystemLabel, @{Name='Belegt_GB';Expression={[math]::Round(($_.Size-$_.SizeRemaining)/1GB,2)}}, @{Name='Frei_GB';Expression={[math]::Round($_.SizeRemaining/1GB,2)}}, @{Name='Belegt_Prozent';Expression={[math]::Round((($_.Size-$_.SizeRemaining)/$_.Size)*100,1)}} ``` **Datenträger anzeigen** ```powershell [RO] Get-Disk | Select-Object Number, FriendlyName, PartitionStyle, OperationalStatus, HealthStatus, Size ``` **Partitionen anzeigen** ```powershell [RO] Get-Partition | Select-Object DiskNumber, PartitionNumber, DriveLetter, Type, Size, OperationalStatus ``` **Informationen zu einem bestimmten Volume** ```powershell [RO] Get-Volume -DriveLetter ``` Beispiel: ```powershell [RO] Get-Volume -DriveLetter C ``` **NTFS-Dirty-Bit abfragen** ```cmd [RO][PRIV] fsutil dirty query : ``` Beispiel: ```cmd [RO][PRIV] fsutil dirty query C: ``` **NTFS-Quoten abfragen** ```cmd [RO][PRIV][SENS] fsutil quota query : ``` Beispiel: ```cmd [RO][PRIV][SENS] fsutil quota query D: ``` **Große Dateien in einem bekannten Verzeichnis suchen** ```powershell [TEST][FILE][SENS] Get-ChildItem -LiteralPath "" -File -Recurse -ErrorAction SilentlyContinue | Sort-Object Length -Descending | Select-Object -First 20 FullName, @{Name='Groesse_GB';Expression={[math]::Round($_.Length/1GB,2)}} ``` > Eine rekursive Suche kann auf großen Verzeichnissen, Dateiservern oder langsamen Datenträgern erhebliche Last und lange Laufzeiten verursachen. Die Suche sollte auf den betroffenen Pfad begrenzt werden. **Typische Windows-Ursachen** - Windows-Update-Dateien - Speicherabbilder und Dump-Dateien - Stark wachsende Anwendungsprotokolle - Datenbank- und Transaktionsprotokolle - Benutzerprofile und Benutzerverzeichnisse - Papierkorb - Schattenkopien - Temporäre Dateien - Nicht mehr verwendete virtuelle Festplatten - Sicherungsdateien auf dem Produktivvolume - Ausgeschöpfte NTFS-Quoten
4. Speicherbelegung unter Linux prüfen **Kapazität und Dateisystemtyp anzeigen** ```bash [RO] df -hT ``` **Belegung für einen bestimmten Pfad anzeigen** ```bash [RO] df -hT "" ``` **Inode-Belegung anzeigen** ```bash [RO] df -i ``` **Blockgeräte und Dateisysteme anzeigen** ```bash [RO] lsblk -f ``` **Eingehängte Dateisysteme übersichtlich anzeigen** ```bash [RO] findmnt ``` **Zugehöriges Dateisystem eines Pfades ermitteln** ```bash [RO] findmnt --target "" ``` **Mount-Optionen eines Pfades anzeigen** ```bash [RO] findmnt -no TARGET,SOURCE,FSTYPE,OPTIONS --target "" ``` **Größe eines bestimmten Verzeichnisses ermitteln** ```bash [TEST][FILE] du -sh "" ``` **Direkte Unterverzeichnisse nach Größe sortieren** ```bash [TEST][FILE][PRIV][SENS] sudo du -xhd1 "" | sort -h ``` Bedeutung von `-x`: - Die Auswertung bleibt innerhalb desselben Dateisystems. - Andere eingehängte Dateisysteme werden nicht mitgezählt. - Dadurch wird vermieden, versehentlich Netzlaufwerke oder weitere Volumes zu durchsuchen. **Benutzerquote anzeigen, sofern Quoten eingerichtet sind** ```bash [RO][SENS] quota -s ``` **Quota-Bericht für Dateisysteme anzeigen** ```bash [RO][PRIV][SENS] sudo repquota -a ``` > Die Programme `quota` und `repquota` sind nicht auf jedem Linux-System standardmäßig installiert. Zudem müssen Quoten auf dem betreffenden Dateisystem eingerichtet sein. **Typische Linux-Ursachen** - Stark wachsende Dateien unter `/var/log` - Container-Images und Container-Logs - Paket- und Update-Caches - Temporäre Dateien - Datenbankdateien - Core-Dumps - Alte Kernel oder Pakete - Nicht rotierte Protokolldateien - Gelöschte, aber weiterhin geöffnete Dateien - Ausgeschöpfte Inodes - Snapshots von LVM, Btrfs oder ZFS - Ein unerwartet nicht eingehängtes Datenvolume > `du` liest Verzeichnisstrukturen ein und kann auf großen Dateisystemen viel Ein-/Ausgabelast erzeugen. Auf Produktivsystemen sollte die Untersuchung auf kleine und verdächtige Pfade begrenzt werden.
5. Speicherbelegung unter macOS prüfen **Belegung der Dateisysteme anzeigen** ```bash [RO] df -h ``` **Belegung für einen bestimmten Pfad anzeigen** ```bash [RO] df -h "" ``` **Datenträger und Volumes anzeigen** ```bash [RO] diskutil list ``` **Informationen über ein Volume oder Gerät anzeigen** ```bash [RO] diskutil info "" ``` Beispiele: ```bash [RO] diskutil info / ``` ```bash [RO] diskutil info disk3 ``` **APFS-Container und Volumes anzeigen** ```bash [RO] diskutil apfs list ``` **Lokale Time-Machine-Snapshots anzeigen** ```bash [RO] tmutil listlocalsnapshots / ``` **Größe eines Verzeichnisses ermitteln** ```bash [TEST][FILE] du -sh "" ``` **Direkte Unterverzeichnisse nach Größe sortieren** ```bash [TEST][FILE][PRIV][SENS] sudo du -xhd 1 "" | sort -h ``` **Besonderheit bei APFS** Mehrere APFS-Volumes können sich den freien Speicherplatz eines gemeinsamen Containers teilen. Deshalb darf die Belegung einzelner APFS-Volumes nicht wie bei vollständig getrennten Partitionen addiert werden. Zusätzlich können für APFS-Volumes eingerichtet sein: - Eine reservierte Mindestgröße - Eine maximale Quote - Gemeinsam verwendbarer Containerspeicher - Snapshots - Verschlüsselte und gegebenenfalls gesperrte Volumes **Typische macOS-Ursachen** - Lokale Time-Machine-Snapshots - Große Benutzerbibliotheken - Caches und Protokolldateien - iPhone- oder iPad-Sicherungen - Virtuelle Maschinen - Entwicklerwerkzeuge und Simulatoren - APFS-Container ohne ausreichend freien Gesamtspeicher - Volume-Quoten - Nicht eingehängte oder gesperrte verschlüsselte Volumes
6. Inode-Erschöpfung unter Linux erkennen Linux-Dateisysteme verwenden Inodes zur Verwaltung von Dateien und Verzeichnissen. Ein Dateisystem kann noch freien Speicherplatz besitzen und trotzdem keine neuen Dateien mehr anlegen, wenn keine freien Inodes verfügbar sind. **Inode-Belegung prüfen** ```bash [RO] df -i ``` Beispielhafte Interpretation: | Speicherplatz | Inodes | Bedeutung | |---|---|---| | 100 % belegt | Frei | Kapazitätsproblem | | Frei | 100 % belegt | Zu viele Dateien beziehungsweise Inode-Problem | | 100 % belegt | 100 % belegt | Kapazität und Inodes ausgeschöpft | | Frei | Frei | Andere Ursache untersuchen | **Typische Verursacher einer Inode-Erschöpfung** - Millionen kleiner Sitzungsdateien - Mail-Warteschlangen - Cache-Verzeichnisse - Temporäre Dateien - Fehlkonfigurierte Anwendungen - Container-Layer - Sehr viele kleine Protokolldateien - Nicht bereinigte Upload- oder Spool-Verzeichnisse **Anzahl der Einträge unter einem begrenzten Pfad ermitteln** ```bash [TEST][FILE][SENS] find "" -xdev -printf '.' | wc -c ``` > Das Durchsuchen sehr großer Verzeichnisbäume kann erhebliche Last verursachen. Der Befehl sollte nicht unkontrolliert auf dem gesamten Root-Dateisystem ausgeführt werden. Auf Windows mit NTFS und macOS mit APFS wird eine klassische Inode-Erschöpfung normalerweise nicht auf dieselbe Weise diagnostiziert. Dort stehen Kapazität, Quoten, Dateisystemmetadaten und Containergrenzen im Vordergrund.
7. Gelöschte, aber noch geöffnete Dateien untersuchen Unter Linux und macOS kann ein Prozess eine Datei weiterhin geöffnet halten, nachdem sie aus dem Verzeichnis gelöscht wurde. Der Dateiname ist dann nicht mehr sichtbar, die Datenblöcke bleiben aber belegt, bis der Prozess die Datei schließt. Das kommt häufig bei Protokolldateien vor: 1. Eine große Protokolldatei wird gelöscht. 2. Der Dienst schreibt weiterhin in den offenen Dateideskriptor. 3. `du` findet die Datei nicht mehr. 4. `df` zeigt weiterhin den belegten Speicher. 5. Erst nach dem Schließen der Datei wird der Platz freigegeben. **Linux und macOS** ```bash [RO][PRIV][SENS] sudo lsof +L1 ``` Wichtige Spalten: | Spalte | Bedeutung | |---|---| | `COMMAND` | Prozessname | | `PID` | Prozess-ID | | `USER` | Prozessbenutzer | | `FD` | Dateideskriptor | | `SIZE/OFF` | Größe beziehungsweise Dateiposition | | `NAME` | Dateiname, häufig mit Hinweis auf Löschung | **Sinnvolle Reaktion** - Zugehörigen Dienst identifizieren. - Prüfen, ob eine reguläre Protokollrotation vorgesehen ist. - Dienst nicht unkontrolliert beenden. - Einen möglichen Neustart im Wartungsfenster planen. - Ursache der fehlerhaften Rotation korrigieren. > Einen Prozess nur zum Freigeben von Speicher zu beenden, kann einen Dienstausfall oder Datenverlust verursachen. Zuerst müssen Dienst, Kritikalität und Abhängigkeiten geprüft werden. Unter Windows werden geöffnete Dateien anders behandelt. Eine regulär geöffnete Datei kann dort häufig nicht ohne Weiteres gelöscht werden. Zur Analyse können beispielsweise Ressourcenmonitor, Process Explorer oder anwendungsspezifische Werkzeuge verwendet werden.
8. Schreibgeschützte und falsch eingehängte Dateisysteme erkennen Ein Dateisystem kann vorhanden und lesbar sein, Schreibzugriffe aber verweigern. Linux kann ein fehlerhaftes Dateisystem abhängig von Konfiguration und Fehlertyp schreibgeschützt erneut einhängen. **Linux: Mount-Optionen eines Pfades prüfen** ```bash [RO] findmnt -no TARGET,SOURCE,FSTYPE,OPTIONS --target "" ``` In der Ausgabe bedeuten: | Option | Bedeutung | |---|---| | `rw` | Lesen und Schreiben | | `ro` | Nur Lesen | | `noexec` | Ausführung von Programmen nicht erlaubt | | `nosuid` | SUID- und SGID-Bits werden nicht berücksichtigt | | `nodev` | Gerätedateien werden nicht interpretiert | **Linux: Kernelmeldungen prüfen** ```bash [RO][PRIV][SENS] sudo journalctl -k -b -p warning --no-pager ``` Gezielt nach speicherbezogenen Meldungen suchen: ```bash [RO][PRIV][SENS] sudo journalctl -k -b --no-pager | grep -Ei 'I/O error|filesystem|read-only|corrupt|ext4|xfs|btrfs|nvme|ata|scsi' ``` **macOS: Eingehängte Dateisysteme anzeigen** ```bash [RO] mount ``` **macOS: Volume-Informationen anzeigen** ```bash [RO] diskutil info "" ``` **Windows: Volumezustand anzeigen** ```powershell [RO] Get-Volume | Select-Object DriveLetter, FileSystemLabel, HealthStatus, OperationalStatus ``` **Wichtige Unterscheidung** Ein Schreibfehler kann verursacht werden durch: - Fehlende Dateiberechtigung - Ausgeschöpfte Quote - Volles Dateisystem - Schreibgeschütztes Dateisystem - Schreibgeschütztes Speichermedium - Gesperrtes oder verschlüsseltes Volume - Fehlendes Netzlaufwerk - Dateisystem- oder Hardwarefehler Ein Berechtigungsfehler sollte deshalb nicht automatisch durch das Erteilen weitreichender Rechte „behoben“ werden.
9. Snapshots, Schattenkopien und gemeinsam genutzten Speicher prüfen Snapshots können Speicherplatz belegen, obwohl die sichtbaren Dateien wenig Platz benötigen. Beim Ändern oder Löschen von Dateien müssen ältere Datenblöcke möglicherweise für den Snapshot erhalten bleiben. **Windows: Schattenkopien anzeigen** ```cmd [RO][PRIV] vssadmin list shadows ``` **Windows: Schattenkopiespeicher anzeigen** ```cmd [RO][PRIV] vssadmin list shadowstorage ``` **macOS: lokale Time-Machine-Snapshots anzeigen** ```bash [RO] tmutil listlocalsnapshots / ``` **macOS: APFS-Struktur anzeigen** ```bash [RO] diskutil apfs list ``` **Linux** Abhängig von der Speichertechnik kommen unterschiedliche Werkzeuge zum Einsatz: | Technik | Typische Prüfung | |---|---| | LVM | `[RO][PRIV] sudo lvs` | | Btrfs | `[RO][PRIV] sudo btrfs filesystem usage ""` | | ZFS | `[RO] zfs list` | | ZFS-Snapshots | `[RO] zfs list -t snapshot` | > Diese Werkzeuge stehen nur zur Verfügung, wenn die jeweilige Speichertechnik installiert und verwendet wird. Snapshots dürfen nicht allein aufgrund ihres Alters gelöscht werden. Vorher ist zu prüfen: - Wer oder welches System hat den Snapshot erstellt? - Wird er von einer Sicherungslösung benötigt? - Gibt es gesetzliche oder betriebliche Aufbewahrungsfristen? - Kann eine Replikation oder Wiederherstellung davon abhängen? - Welcher Speicherplatz würde tatsächlich freigegeben? - Existiert eine funktionierende Sicherung?
10. Dateisystemzustand unter Windows prüfen **Onlineprüfung mit CHKDSK** ```cmd [TEST][PRIV] chkdsk : /scan ``` Beispiel: ```cmd [TEST][PRIV] chkdsk C: /scan ``` **Onlineprüfung mit PowerShell** ```powershell [TEST][PRIV] Repair-Volume -DriveLetter -Scan ``` Beispiel: ```powershell [TEST][PRIV] Repair-Volume -DriveLetter D -Scan ``` **NTFS-Selbstreparaturstatus abfragen** ```cmd [RO][PRIV] fsutil repair query : ``` **Systemprotokoll nach Speichermeldungen durchsuchen** ```powershell [RO][SENS] Get-WinEvent -FilterHashtable @{ LogName = 'System' StartTime = (Get-Date).AddHours(-24) } | Where-Object { $_.ProviderName -match 'Disk|Ntfs|volmgr|volsnap|storport' } | Select-Object TimeCreated, LevelDisplayName, ProviderName, Id, Message ``` Die tatsächlich verwendeten Anbieter können je nach Windows-Version, Treiber und Speicherhardware abweichen. **Reparaturbefehle nur geplant einsetzen** ```cmd [CHANGE][DISRUPT][PRIV] chkdsk : /f ``` ```powershell [CHANGE][DISRUPT][PRIV] Repair-Volume -DriveLetter -OfflineScanAndFix ``` Diese Befehle können: - Ein Volume sperren oder aushängen - Einen Neustart erforderlich machen - Dienste unterbrechen - Beschädigte Dateisystemstrukturen verändern - Bei schwerwiegenden Schäden Dateien oder Dateifragmente verlieren Vor einer Reparatur müssen Sicherung, Wartungsfenster, betroffene Dienste und Wiederherstellungsweg geklärt sein.
11. Dateisystemzustand unter Linux prüfen Zuerst muss der Dateisystemtyp bestimmt werden: ```bash [RO] findmnt -no SOURCE,FSTYPE,TARGET --target "" ``` oder: ```bash [RO] lsblk -f ``` **Kernelmeldungen untersuchen** ```bash [RO][PRIV][SENS] sudo journalctl -k -b -p warning --no-pager ``` **Anzeigen, welchen Prüfbefehl fsck verwenden würde** ```bash [RO][PRIV] sudo fsck -N "" ``` Beispiel: ```bash [RO][PRIV] sudo fsck -N /dev/sdb1 ``` `-N` zeigt an, welche Aktion vorgesehen wäre, ohne die Dateisystemprüfung auszuführen. **Wichtige Sicherheitsregel** Eine tatsächliche Dateisystemreparatur darf nicht unkontrolliert auf einem eingehängten Produktivdateisystem durchgeführt werden. ```bash [CHANGE][DISRUPT][PRIV] sudo fsck "" ``` Vorher müssen mindestens geklärt sein: - Welcher Dateisystemtyp wird verwendet? - Ist das Dateisystem ausgehängt? - Existiert eine aktuelle Sicherung? - Ist ein Wartungsfenster vorhanden? - Handelt es sich um das Root-Dateisystem? - Muss ein Rettungs- oder Wiederherstellungssystem verwendet werden? - Gibt es herstellerspezifische Werkzeuge? > Bei XFS, Btrfs, ZFS und anderen Dateisystemen gelten eigene Prüf- und Reparaturverfahren. Ein generisches `fsck` ist nicht für jedes Dateisystem die richtige Reparaturmethode.
12. Dateisystemzustand unter macOS prüfen **Volume überprüfen** ```bash [TEST][PRIV] sudo diskutil verifyVolume "" ``` Beispiel: ```bash [TEST][PRIV] sudo diskutil verifyVolume / ``` **Physisches Gerät und Volume-Struktur anzeigen** ```bash [RO] diskutil list ``` ```bash [RO] diskutil info "" ``` **Reparatur eines Volumes** ```bash [CHANGE][DISRUPT][PRIV] sudo diskutil repairVolume "" ``` Eine Reparatur des Startvolumes sollte nicht unkontrolliert im laufenden Produktivbetrieb erfolgen. Apple empfiehlt für die Prüfung und Reparatur des Startdatenträgers die macOS-Wiederherstellung und das Festplattendienstprogramm. Vorher sind erforderlich: - Aktuelle Sicherung - Prüfung des betroffenen Volumes - Geplantes Wartungsfenster - Möglichkeit zum Start in die macOS-Wiederherstellung - Wiederherstellungs- oder Austauschplan für den Datenträger Das Festplattendienstprogramm kann nicht alle Hardware- oder Dateisystemprobleme erkennen beziehungsweise reparieren. Wiederkehrende Fehler können auf einen ausfallenden Datenträger hinweisen.
13. Datenträger- und Ein-/Ausgabefehler erkennen Ein volles Dateisystem und ein defekter Datenträger sind unterschiedliche Fehlerklassen. Meldungen wie `I/O error`, Zeitüberschreitungen, Zurücksetzungen eines Controllers oder wiederholte Dateisystembeschädigungen weisen auf eine tiefere Speicherstörung hin. **Windows** ```powershell [RO] Get-Disk | Select-Object Number, FriendlyName, OperationalStatus, HealthStatus, Size ``` ```powershell [RO][SENS] Get-WinEvent -FilterHashtable @{ LogName = 'System' StartTime = (Get-Date).AddHours(-24) } | Where-Object { $_.ProviderName -match 'Disk|Ntfs|storport|stornvme|volmgr' } | Select-Object TimeCreated, LevelDisplayName, ProviderName, Id, Message ``` **Linux** ```bash [RO][PRIV][SENS] sudo journalctl -k -b --no-pager | grep -Ei 'I/O error|timeout|reset|corrupt|nvme|ata|scsi|blk_update' ``` Falls `smartmontools` installiert ist und das Gerät SMART-Daten bereitstellt: ```bash [RO][PRIV][SENS] sudo smartctl -a "" ``` **macOS** ```bash [RO] diskutil info "" ``` Je nach Datenträger und Anschluss kann ein SMART-Status angezeigt werden. Externe USB-Gehäuse und Speicheradapter geben SMART-Daten nicht immer an das Betriebssystem weiter. **Hinweise auf einen möglichen Hardwarefehler** - Wiederkehrende Ein-/Ausgabefehler - Zunehmende Lesefehler - Controller- oder Bus-Zeitüberschreitungen - Datenträger verschwindet zeitweise - Dateisystem wird wiederholt schreibgeschützt - Reparaturen werden nach kurzer Zeit erneut erforderlich - RAID meldet einen herabgesetzten Zustand - Herstellerdiagnose meldet Warnungen - Ungewöhnlich hohe Latenzen bei geringer Last > Bei Verdacht auf einen ausfallenden Datenträger hat die Sicherung beziehungsweise kontrollierte Datenrettung Vorrang vor wiederholten Reparaturversuchen.
14. Abweichung zwischen df, du und sichtbaren Dateien erklären Unter Linux und macOS können verschiedene Werkzeuge unterschiedliche Werte anzeigen. | Werkzeug | Misst hauptsächlich | |---|---| | `df` | Belegte und freie Blöcke des Dateisystems | | `du` | Über Verzeichniseinträge erreichbare Dateien | | `lsof +L1` | Gelöschte, aber weiterhin geöffnete Dateien | | Snapshot-Werkzeug | Durch Snapshots erhaltene Daten | | Quota-Werkzeug | Benutzer- oder Gruppenverbrauch | | Storage-Plattform | Physische oder bereitgestellte Speicherkapazität | **Mögliche Ursachen für unterschiedliche Werte** - Gelöschte, aber geöffnete Dateien - Snapshots - Reservierte Dateisystemblöcke - Sparse-Dateien - Mountpoints, unter denen Dateien verborgen liegen - Berechtigungsfehler bei `du` - Netzlaufwerke oder weitere Dateisysteme - Kompression oder Deduplizierung - Thin Provisioning - Dateisystemmetadaten **Verdeckte Dateien unter einem Mountpoint** Wenn Dateien in einem Verzeichnis liegen und anschließend ein anderes Dateisystem auf dieses Verzeichnis eingehängt wird, sind die ursprünglichen Dateien weiterhin vorhanden, aber im normalen Verzeichnisbaum nicht sichtbar. Zur Untersuchung muss der Mountpoint kontrolliert und das darunterliegende Dateisystem in einem geplanten Wartungsfenster separat betrachtet werden. Ein Produktivvolume darf nicht allein zu Diagnosezwecken unkontrolliert ausgehängt werden.
15. Typische Fehlinterpretationen vermeiden | Fehlinterpretation | Richtige Bewertung | |---|---| | „Es sind noch 5 GB frei, also ist alles in Ordnung.“ | Freier Platz muss relativ zu Wachstum, Anwendung und Dateisystemgröße bewertet werden. | | „Die Datei wurde gelöscht, also ist der Platz frei.“ | Ein Prozess oder Snapshot kann die Daten weiterhin festhalten. | | „Das Volume ist erreichbar, also ist es beschreibbar.“ | Mount-Optionen, Quoten und Berechtigungen prüfen. | | „No space left bedeutet immer, dass die Festplatte voll ist.“ | Unter Linux können auch Inodes erschöpft sein. | | „CHKDSK oder fsck kann gefahrlos ausgeführt werden.“ | Reparaturen verändern Strukturen und können den Betrieb unterbrechen. | | „SMART ist unauffällig, also ist der Datenträger fehlerfrei.“ | Nicht alle Fehler werden erkannt oder weitergereicht. | | „Der Gastserver zeigt freien Platz, also ist der Speicher verfügbar.“ | Datastore oder Storage-Pool kann trotzdem voll sein. | | „Alle großen Dateien können gelöscht werden.“ | Eigentümer, Zweck, Sicherung und Aufbewahrung müssen geklärt werden. | | „Mehr Rechte lösen den Schreibfehler.“ | Ursache kann Quote, Read-only-Zustand oder Dateisystemfehler sein. | | „Eine Reparatur ersetzt die Datensicherung.“ | Reparatur und Sicherung verfolgen unterschiedliche Ziele. |
16. Sichere Reihenfolge der Fehleranalyse 1. Originale Fehlermeldung und betroffenen Pfad dokumentieren. 2. Zugehöriges Volume beziehungsweise Dateisystem bestimmen. 3. Freien Speicherplatz und prozentuale Belegung prüfen. 4. Unter Linux zusätzlich die Inode-Belegung prüfen. 5. Benutzer- und Dateisystemquoten kontrollieren. 6. Mount-, Volume- und Schreibzustand untersuchen. 7. Wachstum nach Verzeichnis, Anwendung und Zeitpunkt eingrenzen. 8. Snapshots und Schattenkopien berücksichtigen. 9. Nach gelöschten, aber geöffneten Dateien suchen. 10. System- und Kernelprotokolle auf Ein-/Ausgabefehler prüfen. 11. Speicherhardware, RAID, Hypervisor oder SAN/NAS einbeziehen. 12. Erst danach über Bereinigung, Erweiterung oder Reparatur entscheiden. 13. Änderungen nur nach Sicherung, Freigabe und dokumentiertem Rückweg durchführen. 14. Nach der Maßnahme Dienstfunktion und freien Speicher erneut prüfen. **Grundsatz für Bereinigungen** Vor dem Löschen einer Datei müssen folgende Fragen beantwortet sein: - Wem gehört die Datei? - Welche Anwendung verwendet sie? - Gibt es eine Aufbewahrungsfrist? - Existiert eine Sicherung? - Wird sie von einem Snapshot oder einer Replikation benötigt? - Kann die Anwendung sie selbst bereinigen? - Muss stattdessen die Protokollrotation korrigiert werden? - Welche Auswirkung hat das Löschen auf Wiederherstellung und Nachvollziehbarkeit?
17. Schnelle Befehlsübersicht | Aufgabe | Windows | Linux | macOS | |---|---|---|---| | Volume-Belegung | `[RO] Get-Volume` | `[RO] df -hT` | `[RO] df -h` | | Datenträger anzeigen | `[RO] Get-Disk` | `[RO] lsblk -f` | `[RO] diskutil list` | | Partitionen anzeigen | `[RO] Get-Partition` | `[RO] lsblk` | `[RO] diskutil list` | | Dateisystem eines Pfades | Volume anhand Laufwerksbuchstaben prüfen | `[RO] findmnt --target ""` | `[RO] df -h ""` | | Mount-Optionen | Nicht direkt vergleichbar | `[RO] findmnt -no TARGET,SOURCE,FSTYPE,OPTIONS --target ""` | `[RO] mount` | | Verzeichnisgröße | `[TEST][FILE] Get-ChildItem ...` | `[TEST][FILE] du -sh ""` | `[TEST][FILE] du -sh ""` | | Inode-Belegung | Nicht vergleichbar | `[RO] df -i` | Nicht üblicherweise erforderlich | | Benutzerquote | `[RO][PRIV] fsutil quota query :` | `[RO] quota -s` | APFS-Quote mit `diskutil apfs list` prüfen | | Dirty-Bit | `[RO][PRIV] fsutil dirty query :` | Nicht direkt vergleichbar | Nicht direkt vergleichbar | | Gelöschte offene Dateien | Spezielle Prozesswerkzeuge | `[RO][PRIV] sudo lsof +L1` | `[RO][PRIV] sudo lsof +L1` | | Snapshots | `[RO][PRIV] vssadmin list shadows` | Abhängig von LVM, Btrfs oder ZFS | `[RO] tmutil listlocalsnapshots /` | | Dateisystemprüfung | `[TEST][PRIV] chkdsk : /scan` | Dateisystemspezifisch; nicht auf gemountetem Produktivsystem | `[TEST][PRIV] sudo diskutil verifyVolume ""` | | Systemmeldungen | `[RO] Get-WinEvent` | `[RO][PRIV] sudo journalctl -k` | Systemprotokoll und `diskutil` | | Hardwarezustand | `[RO] Get-Disk` | `[RO][PRIV] sudo smartctl -a ""` | `[RO] diskutil info ""` |
18. Entscheidungsmatrix | Befund | Wahrscheinliche Ursache | Nächster Schritt | |---|---|---| | Volume nahezu 100 % belegt | Kapazitätsproblem | Größte Verbraucher und Wachstum ermitteln | | Speicher frei, Inodes 100 % | Zu viele Dateien | Verursachendes Verzeichnis und Anwendung ermitteln | | Speicher frei, Benutzer kann nicht schreiben | Quote oder Berechtigung | Quote, Besitz und ACL prüfen | | `df` hoch, `du` deutlich niedriger | Offene gelöschte Datei oder Snapshot | `lsof +L1` und Snapshots prüfen | | Volume nur lesbar | Dateisystem- oder Hardwarefehler | Protokolle sichern und Wartung planen | | Volume nach Neustart nicht vorhanden | Mount-, Geräte- oder Konfigurationsfehler | Geräteerkennung und Mount-Konfiguration prüfen | | Wiederkehrende I/O-Fehler | Hardware, Controller oder Speicherpfad | Sicherung und Storage-Eskalation | | Gast hat Platz, Datastore ist voll | Thin Provisioning oder Snapshot-Wachstum | Hypervisor und Speicherplattform prüfen | | Speicher wird schnell erneut voll | Ursache nicht behoben | Wachstum messen und Rotation beziehungsweise Retention korrigieren | | Reparatur findet wiederholt Fehler | Datenträger- oder tiefer Dateisystemschaden | Daten sichern und Austausch bewerten |
19. Dokumentationsvorlage ```text Ticket: Datum und Uhrzeit: Bearbeiter: Betroffenes System: Betroffener Dienst: Betroffener Benutzer: Betroffener Pfad: Volume beziehungsweise Dateisystem: Dateisystemtyp: Lokaler, virtueller oder externer Speicher: Originale Fehlermeldung: Gesamtkapazität: Freier Speicher: Belegung in Prozent: Inode-Belegung: Quota-Status: Mount- beziehungsweise Volume-Status: Schreibgeschützt: Snapshots vorhanden: Gelöschte offene Dateien: Auffällige große Verzeichnisse oder Dateien: Betriebssystemmeldungen: Dateisystemmeldungen: Hardware- oder Controllerfehler: RAID-, SAN-, NAS- oder Datastore-Status: Vermutete Ursache: Durchgeführte Tests: Durchgeführte Änderungen: Sicherung geprüft: Wartungsfenster: Rückfallplan: Ergebnis: Funktionsprüfung: Verbleibender freier Speicher: Weiterführende Maßnahmen: ```
--- **Merksatz** > „Datenträger voll“ ist keine vollständige Diagnose. Ein Systemintegrator prüft Kapazität, Inodes, Quoten, Mountzustand, Snapshots, offene Dateien, Dateisystem und Speicherhardware getrennt – und repariert erst nach Sicherung und klarer Ursachenanalyse. **Quellen und weiterführende Dokumentation** - [Microsoft Learn – Get-Volume](https://learn.microsoft.com/powershell/module/storage/get-volume) - [Microsoft Learn – Get-Partition](https://learn.microsoft.com/powershell/module/storage/get-partition) - [Microsoft Learn – Repair-Volume](https://learn.microsoft.com/powershell/module/storage/repair-volume) - [Microsoft Learn – chkdsk](https://learn.microsoft.com/windows-server/administration/windows-commands/chkdsk) - [Microsoft Learn – fsutil quota](https://learn.microsoft.com/windows-server/administration/windows-commands/fsutil-quota) - [Microsoft Learn – fsutil repair](https://learn.microsoft.com/windows-server/administration/windows-commands/fsutil-repair) - [Linux-Handbuch – df](https://man7.org/linux/man-pages/man1/df.1.html) - [Linux-Handbuch – findmnt](https://man7.org/linux/man-pages/man8/findmnt.8.html) - [Linux-Handbuch – lsblk](https://man7.org/linux/man-pages/man8/lsblk.8.html) - [Linux-Handbuch – mount](https://man7.org/linux/man-pages/man8/mount.8.html) - [Linux-Handbuch – fsck](https://man7.org/linux/man-pages/man8/fsck.8.html) - [Linux-Handbuch – lsof](https://man7.org/linux/man-pages/man8/lsof.8.html) - [Apple – Speichermedium mit dem Festplattendienstprogramm reparieren](https://support.apple.com/de-de/guide/disk-utility/-dskutl1040/mac) - [Apple – APFS-Volumes hinzufügen, löschen oder vergrößern](https://support.apple.com/en-asia/guide/disk-utility/dskua9e6a110/mac) - [Apple-Handbuch – diskutil](https://keith.github.io/xcode-man-pages/diskutil.8.html) # 4.12 Zeit-, Zeitzonen- und Synchronisationsfehler Eine falsche Systemzeit kann Fehler verursachen, die zunächst wie Netzwerk-, Zertifikats-, Anmelde- oder Anwendungsprobleme wirken. Besonders in Active-Directory-Umgebungen, verteilten Systemen, Datenbanken, Clustern und virtualisierten Umgebungen ist eine zuverlässige Zeitsynchronisation entscheidend. Typische Auswirkungen sind: - Domänenanmeldungen schlagen fehl. - Kerberos-Tickets werden abgelehnt. - Zertifikate erscheinen noch nicht oder nicht mehr gültig. - HTTPS- und TLS-Verbindungen schlagen fehl. - Protokolle verschiedener Systeme lassen sich nicht zeitlich zuordnen. - Datenbanken speichern Ereignisse in falscher Reihenfolge. - Geplante Aufgaben starten zu früh, zu spät oder gar nicht. - Sicherungen und Synchronisationsaufgaben verhalten sich unerwartet. - Einmalpasswörter und zeitbasierte Mehrfaktor-Authentifizierung schlagen fehl. - Cluster, Replikationen oder verteilte Anwendungen melden Inkonsistenzen. - Dateien besitzen scheinbar zukünftige oder unlogische Zeitstempel. - Nach einem Neustart springt die Uhrzeit erneut auf einen falschen Wert. > **Wichtig:** Datum, Uhrzeit, Zeitzone und Zeitsynchronisation sind unterschiedliche Prüfbereiche. Eine korrekt aussehende Uhrzeit bedeutet nicht automatisch, dass das System korrekt synchronisiert ist. **Kennzeichnung der Befehle** | Kennzeichnung | Bedeutung | |---|---| | `[RO]` | Nur lesender Befehl | | `[TEST]` | Führt eine aktive Prüfung aus | | `[PRIV]` | Erhöhte Berechtigungen erforderlich | | `[SENS]` | Ausgabe kann sensible Informationen enthalten | | `[CHANGE]` | Verändert Konfiguration oder Systemzustand | | `[DISRUPT]` | Kann laufende Dienste oder Anwendungen beeinflussen | ---
1. Warum eine korrekte Systemzeit wichtig ist Viele IT-Systeme verwenden Zeitstempel nicht nur zur Anzeige, sondern als Bestandteil ihrer Sicherheits- und Ablaufsteuerung. | System oder Funktion | Bedeutung der Systemzeit | |---|---| | Active Directory | Kerberos verwendet Zeitstempel zum Schutz vor wiederholten Anmeldeversuchen | | TLS und Zertifikate | Gültigkeitsbeginn und Gültigkeitsende werden gegen die Systemzeit geprüft | | Protokollierung | Ereignisse verschiedener Systeme müssen zeitlich vergleichbar sein | | Datenbanken | Transaktionen, Replikation und Datensätze besitzen Zeitstempel | | Sicherungen | Zeitpläne und inkrementelle Sicherungen hängen von Zeitinformationen ab | | MFA und TOTP | Einmalpasswörter werden aus Zeitintervallen berechnet | | E-Mail | Nachrichten und Signaturen enthalten Zeitstempel | | Monitoring | Messwerte müssen in der richtigen Reihenfolge gespeichert werden | | Cluster | Knoten müssen Ereignisse zeitlich konsistent bewerten | | Dateisynchronisation | Änderungszeiten beeinflussen die Entscheidung, welche Datei neuer ist | | Lizenzsysteme | Lizenzen können an Zeiträume gebunden sein | | Aufgabenplanung | Startzeitpunkte hängen von lokaler Zeit und Zeitzone ab | Eine Zeitabweichung kann daher gleichzeitig mehrere scheinbar unabhängige Dienste beeinträchtigen.
2. Fehlerbild strukturiert aufnehmen Zuerst muss festgestellt werden, welche Zeitinformation tatsächlich falsch ist. **Zu prüfende Fragen** - Sind Datum und Uhrzeit falsch? - Ist nur die Zeitzone falsch? - Beträgt die Abweichung genau eine oder mehrere volle Stunden? - Wächst die Abweichung kontinuierlich? - Springt die Zeit nach einem Neustart zurück? - Ist nur eine virtuelle Maschine betroffen? - Sind mehrere Geräte am gleichen Standort betroffen? - Ist die UTC-Zeit korrekt, aber die lokale Anzeige falsch? - Ist der eingetragene Zeitserver erreichbar? - Wird die erwartete Zeitquelle tatsächlich verwendet? - Trat das Problem nach einem Snapshot, einer Migration oder einem Standby auf? - Ist das System Mitglied einer Active-Directory-Domäne? - Verwaltet eine Gruppenrichtlinie oder Geräteverwaltung die Zeiteinstellungen? - Wurde die Zeit manuell verändert? **Abweichungsmuster und erste Hinweise** | Beobachtung | Mögliche Ursache | |---|---| | Abweichung um genau eine Stunde | Falsche Zeitzone oder Sommerzeitregel | | Abweichung um mehrere volle Stunden | Falsche Zeitzone | | Abweichung wächst langsam | Ungenaue lokale Uhr oder fehlende Synchronisation | | Zeit springt nach einem Neustart zurück | Hardwareuhr, Firmware, Host oder leere CMOS-Batterie | | Nur virtuelle Maschinen betroffen | Hypervisor-Zeitquelle oder Snapshot | | Alle Domänenmitglieder betroffen | Fehler in der AD-Zeithierarchie | | Nur ein Domänenmitglied betroffen | Lokaler Zeitdienst, Netzwerk oder Richtlinie | | Uhrzeit stimmt, TLS schlägt trotzdem fehl | UTC, Datum und Zertifikatszeitraum kontrollieren | | Protokolle wirken zeitversetzt | UTC- und Lokalzeitdarstellung vergleichen | | Zeitserver ist per Ping erreichbar, Synchronisation scheitert | NTP, Firewall oder Serverantwort prüfen | > Eine Abweichung um eine volle Stunde deutet meistens eher auf die Zeitzone als auf eine fehlerhafte NTP-Synchronisation hin.
3. Datum, Uhrzeit und Zeitzone vergleichen Die Werte sollten möglichst gleichzeitig auf dem betroffenen System und einem vertrauenswürdigen Vergleichssystem erfasst werden. | Aufgabe | Windows | Linux | macOS | |---|---|---|---| | Lokale Zeit | `[RO] Get-Date -Format o` | `[RO] date --iso-8601=seconds` | `[RO] date "+%Y-%m-%dT%H:%M:%S%z"` | | UTC-Zeit | `[RO] (Get-Date).ToUniversalTime().ToString("o")` | `[RO] date -u "+%Y-%m-%dT%H:%M:%SZ"` | `[RO] date -u "+%Y-%m-%dT%H:%M:%SZ"` | | Zeitzone | `[RO] Get-TimeZone` | `[RO] timedatectl status` | `[RO][PRIV] sudo systemsetup -gettimezone` | | Zeitzonendatei | Nicht zutreffend | `[RO] readlink -f /etc/localtime` | Nicht zutreffend | | Hardwareuhr | Nicht direkt erforderlich | `[RO][PRIV] sudo hwclock --show` | Nicht regulär erforderlich | **Warum UTC und lokale Zeit getrennt geprüft werden** - UTC ist die gemeinsame Zeitbasis. - Die lokale Zeit entsteht aus UTC, Zeitzone und Sommerzeitregel. - Zwei Systeme können dieselbe UTC-Zeit, aber unterschiedliche lokale Zeiten anzeigen. - Protokolle können entweder UTC oder lokale Zeit verwenden. - Server werden häufig in UTC betrieben, während Benutzeroberflächen lokale Zeit anzeigen. **Beispiel** Wenn UTC korrekt ist, die lokale Zeit aber um eine Stunde abweicht, liegt die Ursache wahrscheinlich in der Zeitzone oder Sommerzeitregel und nicht in der eigentlichen Zeitsynchronisation.
4. Windows-Zeitdienst untersuchen Windows verwendet den Dienst `W32Time` zur Zeitsynchronisation. **Status des Zeitdienstes prüfen** ```powershell [RO] Get-Service -Name W32Time ``` Ausführlicher: ```powershell [RO] Get-CimInstance Win32_Service -Filter "Name='W32Time'" | Select-Object Name, State, StartMode, StartName, ExitCode ``` **Aktuelle Zeitquelle anzeigen** ```cmd [RO] w32tm /query /source ``` **Synchronisationsstatus anzeigen** ```cmd [RO] w32tm /query /status ``` **Ausführlichen Status anzeigen** ```cmd [RO] w32tm /query /status /verbose ``` **Konfiguration anzeigen** ```cmd [RO][SENS] w32tm /query /configuration ``` **Konfigurierte Zeitpartner anzeigen** ```cmd [RO][SENS] w32tm /query /peers ``` **Zeitzone anzeigen** ```powershell [RO] Get-TimeZone ``` oder: ```cmd [RO] tzutil /g ``` **Mögliche Ausgaben bei der Zeitquelle** | Ausgabe | Bedeutung | |---|---| | Name eines Domänencontrollers | Synchronisation über die AD-Zeithierarchie | | Name eines NTP-Servers | Direkte Synchronisation mit diesem Server | | `Local CMOS Clock` | Lokale Hardwareuhr wird verwendet | | `VM IC Time Synchronization Provider` | Zeit wird über den Hypervisor bereitgestellt | | `Free-running System Clock` | Keine geeignete externe Synchronisation | > `Local CMOS Clock` oder `Free-running System Clock` ist bei einem normalen Domänenmitglied meist ein Hinweis darauf, dass die erwartete Domänenzeitquelle nicht verwendet wird. Bei isolierten Systemen kann die Bewertung anders ausfallen.
5. Windows-Zeitabweichung aktiv messen Mit `w32tm /stripchart` kann die Abweichung zu einem Zeitserver gemessen werden, ohne die lokale Uhr zu verändern. ```cmd [TEST] w32tm /stripchart /computer: /samples:5 /dataonly ``` Beispiel: ```cmd [TEST] w32tm /stripchart /computer:dc01.example.local /samples:5 /dataonly ``` Fortlaufende Messung: ```cmd [TEST] w32tm /stripchart /computer: /dataonly ``` Die fortlaufende Ausgabe wird mit `Strg` + `C` beendet. **Wichtige Interpretation** | Ergebnis | Bedeutung | |---|---| | Kleine, stabile Abweichung | Synchronisation wahrscheinlich funktionsfähig | | Große, stabile Abweichung | Falsche Quelle oder noch nicht korrigierte Uhr | | Abweichung wächst | Lokale Uhr driftet oder wird nicht nachgeregelt | | Keine Antwort | Name, Netzwerk, Firewall oder NTP-Dienst prüfen | | Zeitüberschreitung | NTP-Antwort erreicht den Client nicht | > Der Test bestätigt nicht automatisch, dass Windows diese Gegenstelle als aktive Zeitquelle verwendet. Die aktive Quelle muss zusätzlich mit `w32tm /query /source` geprüft werden.
6. Active-Directory-Zeithierarchie verstehen Domänenmitglieder sollten grundsätzlich der Active-Directory-Zeithierarchie folgen. Vereinfachter Aufbau: ```text Externe zuverlässige Zeitquelle │ ▼ PDC-Emulator der Gesamtstruktur-Stammdomäne │ ▼ Weitere Domänencontroller │ ▼ Mitgliedsserver und Clients ``` **PDC-Emulator ermitteln** ```cmd [RO][SENS] netdom query fsmo ``` Alternativ mit PowerShell: ```powershell [RO][SENS] Get-ADDomain | Select-Object DNSRoot, PDCEmulator ``` Dafür muss das ActiveDirectory-PowerShell-Modul verfügbar sein. **Domänencontroller anzeigen** ```cmd [RO][SENS] nltest /dclist: ``` **Verwendeten Domänencontroller anzeigen** ```cmd [RO][SENS] nltest /dsgetdc: ``` **Zeitstatus eines entfernten Windows-Systems abfragen** ```cmd [RO][SENS] w32tm /query /computer: /status ``` Dafür sind ausreichende Berechtigungen und eine erreichbare Remoteverwaltung erforderlich. **Wichtige Regeln** - Normale Domänenmitglieder sollten nicht unabhängig auf beliebige öffentliche NTP-Server zeigen. - Der PDC-Emulator der Stammdomäne benötigt eine zuverlässige übergeordnete Zeitquelle. - Gruppenrichtlinien können lokale Einstellungen überschreiben. - Auf virtuellen Domänencontrollern dürfen Hypervisor- und Domänenzeitsynchronisation nicht unkontrolliert gegeneinander arbeiten. - Eine manuelle Uhrzeitkorrektur behebt keine fehlerhafte Zeithierarchie.
7. Windows-Ereignisprotokolle auswerten **Zeitdienst-Ereignisse im Systemprotokoll anzeigen** ```powershell [RO][SENS] Get-WinEvent -FilterHashtable @{ LogName = 'System' ProviderName = 'Microsoft-Windows-Time-Service' StartTime = (Get-Date).AddHours(-24) } | Select-Object TimeCreated, LevelDisplayName, Id, Message ``` **Operational-Protokoll des Zeitdienstes prüfen** ```powershell [RO][SENS] Get-WinEvent -LogName ` 'Microsoft-Windows-Time-Service/Operational' ` -ErrorAction SilentlyContinue | Select-Object -First 100 TimeCreated, LevelDisplayName, Id, Message ``` **Dienststatus und letzte Meldungen gemeinsam bewerten** ```powershell [RO] Get-Service W32Time ``` ```cmd [RO] w32tm /query /source ``` ```cmd [RO] w32tm /query /status ``` **Typische Hinweise in Ereignissen** - Keine Zeitdaten verfügbar - Zeitquelle nicht erreichbar - Zeitquelle wurde gewechselt - Synchronisation wurde beendet - Uhrzeitabweichung ist zu groß - Zeitdienst wurde gestartet oder beendet - NTP-Anbieter konnte keine gültigen Daten abrufen > Einzelne ältere Warnungen beweisen keine aktuelle Störung. Zeitstempel, Wiederholungsrate und aktueller Synchronisationsstatus müssen gemeinsam bewertet werden.
8. Linux mit systemd-timesyncd untersuchen Viele Linux-Distributionen verwenden `systemd-timesyncd`. Andere Systeme verwenden stattdessen chrony, ntpd oder eine herstellerspezifische Lösung. **Gesamtstatus anzeigen** ```bash [RO] timedatectl status ``` Wichtige Felder: | Feld | Bedeutung | |---|---| | `Local time` | Lokale Uhrzeit | | `Universal time` | UTC-Zeit | | `RTC time` | Hardwareuhr | | `Time zone` | Aktive Zeitzone | | `System clock synchronized` | Synchronisationszustand | | `NTP service` | Status eines erkannten NTP-Dienstes | | `RTC in local TZ` | Gibt an, ob die Hardwareuhr Lokalzeit verwendet | **Status der Zeitsynchronisation anzeigen** ```bash [RO] timedatectl timesync-status ``` **Alle verfügbaren Synchronisationsinformationen anzeigen** ```bash [RO] timedatectl show-timesync --all ``` **Dienststatus prüfen** ```bash [RO] systemctl status systemd-timesyncd --no-pager ``` **Protokolle anzeigen** ```bash [RO][PRIV][SENS] sudo journalctl -u systemd-timesyncd \ --since "-24 hours" --no-pager ``` **Konfiguration anzeigen** ```bash [RO][FILE] systemd-analyze cat-config systemd/timesyncd.conf ``` > `timedatectl timesync-status` und `show-timesync` funktionieren nur, wenn `systemd-timesyncd` verwendet und von der eingesetzten systemd-Version unterstützt wird. Bei chrony oder ntpd müssen deren eigene Werkzeuge verwendet werden.
9. Linux mit chrony untersuchen Chrony wird häufig auf Linux-Servern, virtuellen Maschinen und Systemen mit unregelmäßiger Netzwerkverbindung verwendet. **Synchronisationsstatus anzeigen** ```bash [RO] chronyc tracking ``` Wichtige Werte: | Wert | Bedeutung | |---|---| | `Reference ID` | Aktuell verwendete Referenz | | `Stratum` | Entfernung zur ursprünglichen Referenzuhr | | `Ref time` | Zeitpunkt der letzten verwendeten Messung | | `System time` | Abweichung der Systemuhr | | `Last offset` | Zuletzt gemessene Abweichung | | `RMS offset` | Langfristige Abweichung | | `Leap status` | Synchronisations- beziehungsweise Schaltsekundenstatus | **Zeitquellen anzeigen** ```bash [RO] chronyc sources -v ``` **Messwerte der Quellen anzeigen** ```bash [RO] chronyc sourcestats -v ``` **Chrony-Aktivität prüfen** ```bash [RO] chronyc activity ``` **Dienststatus anzeigen** ```bash [RO] systemctl status chronyd --no-pager ``` Je nach Distribution kann der Dienst auch `chrony` heißen: ```bash [RO] systemctl status chrony --no-pager ``` **Protokolle anzeigen** ```bash [RO][PRIV][SENS] sudo journalctl -u chronyd \ --since "-24 hours" --no-pager ``` oder: ```bash [RO][PRIV][SENS] sudo journalctl -u chrony \ --since "-24 hours" --no-pager ``` **Kennzeichen in `chronyc sources -v`** | Zeichen | Bedeutung | |---|---| | `^*` | Aktuell ausgewählte NTP-Quelle | | `^+` | Geeignete zusätzliche Quelle | | `^-` | Geeignete, aber nicht verwendete Quelle | | `^?` | Quelle nicht erreichbar oder noch nicht ausreichend bewertet | | `^x` | Quelle wird als fehlerhaft bewertet | | `^~` | Quelle weist zu große Schwankungen auf | > Ein erreichbarer Server ist nicht automatisch eine geeignete Zeitquelle. Chrony bewertet unter anderem Abweichung, Stabilität und Messqualität.
10. Linux mit klassischem ntpd untersuchen Auf älteren oder speziell konfigurierten Systemen kann weiterhin `ntpd` verwendet werden. **Dienststatus prüfen** ```bash [RO] systemctl status ntp --no-pager ``` oder abhängig von der Distribution: ```bash [RO] systemctl status ntpd --no-pager ``` **Zeitpartner anzeigen** ```bash [RO] ntpq -pn ``` Typische Markierungen: | Zeichen | Bedeutung | |---|---| | `*` | Aktuell ausgewählte Zeitquelle | | `+` | Geeignete zusätzliche Quelle | | `-` | Von der Auswahl verworfene Quelle | | `x` | Als falsch bewertete Quelle | | Leerzeichen | Quelle wurde noch nicht ausgewählt | **Protokolle anzeigen** ```bash [RO][PRIV][SENS] sudo journalctl -u ntp \ --since "-24 hours" --no-pager ``` oder: ```bash [RO][PRIV][SENS] sudo journalctl -u ntpd \ --since "-24 hours" --no-pager ``` > Es sollte zuerst ermittelt werden, welcher Zeitdienst tatsächlich aktiv ist. Mehrere parallel aktive Zeitdienste können sich gegenseitig beeinflussen.
11. Aktiven Zeitdienst unter Linux bestimmen **Erkannten NTP-Dienst anzeigen** ```bash [RO] timedatectl status ``` **Typische Dienste prüfen** ```bash [RO] systemctl is-active systemd-timesyncd ``` ```bash [RO] systemctl is-active chronyd ``` ```bash [RO] systemctl is-active chrony ``` ```bash [RO] systemctl is-active ntpd ``` ```bash [RO] systemctl is-active ntp ``` **Laufende Prozesse suchen** ```bash [RO] ps -ef | grep -E '[c]hronyd|[n]tpd|[s]ystemd-timesyncd' ``` **Typische Problemkonstellationen** - Mehrere Zeitdienste sind gleichzeitig aktiv. - Ein alter Zeitdienst wurde nach einer Migration nicht entfernt. - Der Dienst läuft, besitzt aber keine verwendbare Quelle. - Die Distribution verwaltet die Konfiguration über ein anderes Werkzeug. - Eine virtuelle Maschine erhält zusätzlich Zeit vom Hypervisor. - Eine Konfigurationsmanagement-Lösung überschreibt lokale Änderungen.
12. Zeitstatus unter macOS untersuchen **Lokale Zeit anzeigen** ```bash [RO] date "+%Y-%m-%dT%H:%M:%S%z" ``` **UTC-Zeit anzeigen** ```bash [RO] date -u "+%Y-%m-%dT%H:%M:%SZ" ``` **Zeitzone anzeigen** ```bash [RO][PRIV] sudo systemsetup -gettimezone ``` **Prüfen, ob Netzwerkzeit aktiviert ist** ```bash [RO][PRIV] sudo systemsetup -getusingnetworktime ``` **Eingetragenen Netzwerkzeitserver anzeigen** ```bash [RO][PRIV][SENS] sudo systemsetup -getnetworktimeserver ``` **Aktive Systemeinstellungen anzeigen** ```bash [RO] systemsetup -help ``` `systemsetup` benötigt für viele Abfragen Administratorrechte. **NTP-Server aktiv abfragen** ```bash [TEST] sntp -d ``` Beispiel: ```bash [TEST] sntp -d time.apple.com ``` Dieser Test fragt eine Zeitquelle ab, ändert aber nicht automatisch die lokale Systemzeit. **Zeitbezogene Protokolle der letzten Stunde durchsuchen** ```bash [RO][PRIV][SENS] sudo log show --last 1h \ --predicate 'process == "timed" OR process == "sntp"' \ --style compact ``` Die vorhandenen Prozessnamen und Protokolle können sich zwischen macOS-Versionen unterscheiden. **Grafische Kontrolle** ```text Apple-Menü → Systemeinstellungen → Allgemein → Datum & Uhrzeit ``` Dort werden unter anderem geprüft: - Datum und Uhrzeit automatisch einstellen - Eingetragener Netzwerkzeitserver - Zeitzone automatisch anhand des Standorts einstellen - Aktive Zeitzone - Standortdienste für die automatische Zeitzone
13. Erreichbarkeit des Zeitservers prüfen NTP verwendet normalerweise UDP-Port 123. Ein erfolgreicher Ping beweist nicht, dass NTP funktioniert. **Namensauflösung prüfen** Windows: ```powershell [RO] Resolve-DnsName "" ``` Linux: ```bash [RO] getent ahosts "" ``` macOS: ```bash [RO] dscacheutil -q host -a name "" ``` **Windows: NTP-Antwort und Zeitabweichung testen** ```cmd [TEST] w32tm /stripchart /computer: /samples:5 /dataonly ``` **Linux mit chrony** ```bash [RO] chronyc sources -v ``` **macOS** ```bash [TEST] sntp -d ``` **Netzwerkaufzeichnung unter Linux** ```bash [TEST][PRIV][SENS] sudo tcpdump -ni any udp port 123 ``` **Netzwerkaufzeichnung unter macOS** ```bash [TEST][PRIV][SENS] sudo tcpdump -ni any udp port 123 ``` Dabei ist zu prüfen: 1. Verlässt eine Anfrage das System? 2. Wird sie an die erwartete IP-Adresse gesendet? 3. Kommt eine Antwort zurück? 4. Verwendet das System tatsächlich diese Gegenstelle? 5. Blockiert eine lokale oder zentrale Firewall UDP 123? 6. Überschreibt ein VPN die Route oder DNS-Auflösung? > Ein einfacher TCP-Porttest ist für NTP ungeeignet, weil NTP normalerweise UDP und nicht TCP verwendet.
14. Zeitzone und Sommerzeit untersuchen Eine korrekte Synchronisation liefert eine gemeinsame Zeitbasis. Die lokale Darstellung hängt zusätzlich von der Zeitzone ab. **Windows** ```powershell [RO] Get-TimeZone ``` ```cmd [RO] tzutil /g ``` Verfügbare Zeitzonen anzeigen: ```powershell [RO] Get-TimeZone -ListAvailable ``` **Linux** ```bash [RO] timedatectl status ``` ```bash [RO] readlink -f /etc/localtime ``` Verfügbare Zeitzonen anzeigen: ```bash [RO] timedatectl list-timezones ``` **macOS** ```bash [RO][PRIV] sudo systemsetup -gettimezone ``` **Typische Zeitzonenfehler** - Ein System verwendet UTC statt `Europe/Berlin`. - Ein Standortwechsel wurde nicht berücksichtigt. - Veraltete Zeitzonendaten enthalten falsche Sommerzeitregeln. - Ein Container besitzt eine andere Zeitzone als der Host. - Eine Anwendung verwendet eine eigene Zeitzonenkonfiguration. - Die Datenbank speichert UTC, die Anwendung interpretiert sie als Lokalzeit. - Ein Protokoll zeigt UTC ohne deutliche Kennzeichnung. - Die Hardwareuhr wird unter Linux als lokale Zeit interpretiert. **Wichtige Unterscheidung** | Situation | Bewertung | |---|---| | UTC falsch | Synchronisations- oder Uhrenproblem | | UTC richtig, Lokalzeit falsch | Zeitzonenproblem | | Betriebssystemzeit richtig, Anwendung falsch | Anwendungskonfiguration prüfen | | Anzeige richtig, Logzeit abweichend | Prüfen, ob das Protokoll UTC verwendet |
15. Virtuelle Maschinen und Hypervisor berücksichtigen Virtuelle Maschinen können ihre Zeit aus mehreren Quellen erhalten: - Virtuelle Hardwareuhr - Hypervisor oder Gasterweiterungen - Betriebssystem-Zeitdienst - Active-Directory-Zeithierarchie - Externer NTP-Server Wenn mehrere Quellen gleichzeitig eingreifen, kann die Uhr springen oder ständig korrigiert werden. **Typische Ursachen** - Host besitzt selbst eine falsche Uhrzeit. - VM wird nach längerer Pause fortgesetzt. - Snapshot stellt einen älteren Zustand wieder her. - Live-Migration verändert die Zeitbasis. - Hypervisor-Zeitsynchronisation und NTP arbeiten gegeneinander. - Ein virtueller Domänencontroller verwendet die falsche Quelle. - Gasterweiterungen sind veraltet oder falsch konfiguriert. - Die VM war längere Zeit ohne CPU-Zeit oder Netzwerkverbindung. **Prüfreihenfolge** 1. Zeitquelle innerhalb der VM ermitteln. 2. Zeitstatus des Hypervisors prüfen. 3. Gasterweiterungen und Integrationsdienste kontrollieren. 4. Domänenrolle der VM berücksichtigen. 5. Snapshot- oder Migrationsereignisse zeitlich vergleichen. 6. Prüfen, ob mehrere Zeitquellen gleichzeitig aktiv sind. 7. Herstellerempfehlung des verwendeten Hypervisors beachten. **Windows-VM** ```cmd [RO] w32tm /query /source ``` Die Ausgabe: ```text VM IC Time Synchronization Provider ``` weist bei Hyper-V auf eine Zeitbereitstellung über die Integrationskomponenten hin. > Bei Domänencontrollern muss besonders sorgfältig geplant werden, welche Zeitquelle maßgeblich ist. Eine unkontrollierte Änderung kann die gesamte Domänenzeithierarchie beeinflussen.
16. Container und Zeitzonenfehler untersuchen Container verwenden normalerweise die Kernel-Uhr des Hosts. Die angezeigte lokale Zeit kann dennoch durch Zeitzonendateien, Umgebungsvariablen oder das Container-Image abweichen. **Zeit auf dem Host prüfen** ```bash [RO] date --iso-8601=seconds ``` **Zeit in einem Docker-Container prüfen** ```bash [RO] docker exec "" date --iso-8601=seconds ``` **UTC-Zeit im Container prüfen** ```bash [RO] docker exec "" date -u "+%Y-%m-%dT%H:%M:%SZ" ``` **Zeitzonenumgebung prüfen** ```bash [RO][SENS] docker inspect "" \ --format '{{range .Config.Env}}{{println .}}{{end}}' ``` In der Ausgabe kann nach einer Variable wie `TZ` gesucht werden. **Typische Ursachen** - Hostzeit ist falsch. - Im Container fehlt die Zeitzonendatenbank. - Die Variable `TZ` ist falsch gesetzt. - `/etc/localtime` enthält eine andere Zeitzone. - Anwendung verwendet unabhängig vom Betriebssystem UTC. - Host und Container zeigen dieselbe UTC-Zeit, aber unterschiedliche Lokalzeit. - Protokolltreiber fügt Zeitstempel in UTC hinzu. > Die Systemzeit eines Containers sollte nicht durch zusätzliche Berechtigungen oder manuelle Änderungen korrigiert werden. Zuerst müssen Hostzeit, Zeitzone und Anwendungskonfiguration geprüft werden.
17. Hardwareuhr und Firmware berücksichtigen Die Hardwareuhr, auch RTC genannt, hält die Zeit während des ausgeschalteten Zustands. Beim Start übernimmt das Betriebssystem einen Ausgangswert und synchronisiert ihn anschließend. **Linux** ```bash [RO][PRIV] sudo hwclock --show ``` Vergleich mit der Systemzeit: ```bash [RO] date --iso-8601=seconds ``` **Mögliche Ursachen für eine falsche Startzeit** - Leere oder schwache CMOS-Batterie - Falsche Uhrzeit im BIOS oder UEFI - Hardwareuhr wird unterschiedlich als UTC oder Lokalzeit interpretiert - Dual-Boot-Systeme verwenden verschiedene RTC-Konventionen - Virtuelle Hardwareuhr liefert einen falschen Wert - NTP-Synchronisation erfolgt nach dem Start nicht - System besitzt beim Start keine Netzwerkverbindung **Typisches Fehlerbild einer schwachen CMOS-Batterie** - Uhrzeit ist nach vollständigem Ausschalten wieder falsch. - Firmware-Einstellungen gehen verloren. - Datum springt auf einen älteren Standardwert. - Nach erfolgreicher Netzwerksynchronisation stimmt die Uhr bis zum nächsten Ausschalten. Bei virtuellen Maschinen existiert keine normale austauschbare CMOS-Batterie. Dort müssen Hypervisor, virtuelle Hardwareuhr und Hostzeit geprüft werden.
18. Zeitabhängige Sicherheitsfehler erkennen **Kerberos** Kerberos verwendet Zeitstempel, um wiederholte Verwendung abgefangener Authentifizierungsdaten zu erschweren. Eine zu große Abweichung zwischen Client, Domänencontroller und Server kann Anmeldungen verhindern. Typische Meldungen: - Zeitunterschied zwischen Client und Server - Kerberos-Ticket noch nicht gültig - Kerberos-Ticket abgelaufen - Domänenanmeldung nicht möglich **TLS und Zertifikate** Zertifikate besitzen unter anderem: - Gültigkeitsbeginn - Gültigkeitsende Bei falscher Systemzeit kann ein gültiges Zertifikat erscheinen als: - Noch nicht gültig - Abgelaufen - Außerhalb des Gültigkeitszeitraums **Zeitbasierte Einmalpasswörter** TOTP-Verfahren berechnen Codes aus: - Gemeinsamen Geheimnis - Aktuellem Zeitintervall Wenn Smartphone, Server oder Authentifizierungsdienst zeitlich abweichen, werden korrekte Codes abgelehnt. **Prüfregel** Bei gleichzeitigen Fehlern in Anmeldung, Zertifikaten und MFA sollte die Systemzeit sehr früh in der Diagnose geprüft werden.
19. Sichere Korrekturmaßnahmen Vor jeder Änderung muss die Ursache bestimmt werden. Ein manuelles Stellen der Uhr kann Protokolle, Datenbanken, Cluster und laufende Anwendungen beeinflussen. **Windows: erneute Synchronisation anfordern** ```cmd [CHANGE][PRIV] w32tm /resync ``` Mit erneuter Erkennung der Zeitquelle: ```cmd [CHANGE][PRIV] w32tm /resync /rediscover ``` **Linux mit systemd-timesyncd** Zeitdienst nur nach bestätigter Ursache neu starten: ```bash [CHANGE][PRIV] sudo systemctl restart systemd-timesyncd ``` **Linux mit chrony** Dienst nur nach bestätigter Ursache neu starten: ```bash [CHANGE][PRIV] sudo systemctl restart chronyd ``` Abhängig von der Distribution: ```bash [CHANGE][PRIV] sudo systemctl restart chrony ``` **Große Zeitkorrekturen** Große Zeitsprünge können: - Datenbanktransaktionen beeinflussen - Protokolle unbrauchbar machen - Sitzungen und Tickets ungültig machen - Cluster irritieren - Aufgaben doppelt oder gar nicht ausführen - Monitoringdaten in die falsche Reihenfolge bringen - Anwendungen mit zeitabhängigen Sperren beeinträchtigen Vor einer großen Korrektur sind deshalb zu prüfen: - Größe und Richtung der Abweichung - Rolle des Systems - Laufende Datenbanken und Cluster - Domänenfunktion - Virtualisierung - Wartungsfenster - Sicherung und Rückfallplan - Herstellerdokumentation der betroffenen Anwendung > Die Zeit niemals absichtlich zurückstellen, ohne die Auswirkungen auf Datenbanken, Protokolle und verteilte Systeme zu bewerten.
20. Typische Fehlinterpretationen vermeiden | Fehlinterpretation | Richtige Bewertung | |---|---| | „Die Uhr in der Taskleiste stimmt.“ | Quelle, Synchronisationsstatus, UTC und Zeitzone zusätzlich prüfen. | | „Ping zum Zeitserver funktioniert.“ | Ping prüft nicht die NTP-Kommunikation über UDP 123. | | „Der Zeitdienst läuft, also synchronisiert er.“ | Ein aktiver Dienst kann ohne brauchbare Quelle laufen. | | „Eine Stunde Abweichung ist ein NTP-Fehler.“ | Häufig ist die Zeitzone oder Sommerzeitregel falsch. | | „Alle Systeme müssen dieselbe lokale Uhrzeit anzeigen.“ | Systeme in verschiedenen Zeitzonen können dieselbe UTC-Zeit verwenden. | | „Die Uhr kann gefahrlos manuell gestellt werden.“ | Zeitsprünge können Anwendungen und Protokolle beeinflussen. | | „Jeder Domänenclient sollte einen öffentlichen NTP-Server verwenden.“ | Domänenmitglieder sollten normalerweise der AD-Zeithierarchie folgen. | | „Der Hypervisor regelt die Zeit vollständig.“ | Gastzeitdienst und Hypervisor können gleichzeitig eingreifen. | | „Container besitzen eine vollständig eigene Uhr.“ | Container verwenden normalerweise die Kernel-Uhr des Hosts. | | „Ein Neustart behebt die Zeit dauerhaft.“ | Eine fehlerhafte Quelle oder Konfiguration bleibt bestehen. |
21. Sichere Reihenfolge der Fehleranalyse 1. Fehlerzeitpunkt und originale Fehlermeldung dokumentieren. 2. Lokale Zeit und UTC-Zeit erfassen. 3. Zeitzone kontrollieren. 4. Abweichung mit einem vertrauenswürdigen Vergleichssystem bestimmen. 5. Aktiven Zeitdienst identifizieren. 6. Tatsächlich verwendete Zeitquelle ermitteln. 7. Synchronisationsstatus und letzte erfolgreiche Messung prüfen. 8. Namensauflösung der Zeitquelle testen. 9. NTP-Antwort beziehungsweise Zeitabweichung aktiv prüfen. 10. Firewall, Routing und UDP 123 untersuchen. 11. Ereignis- beziehungsweise Systemprotokolle auswerten. 12. Domänen-, Virtualisierungs- oder Containerstruktur berücksichtigen. 13. Erst danach eine erneute Synchronisation oder Konfigurationsänderung durchführen. 14. Nach der Maßnahme Quelle, Status und Abweichung erneut kontrollieren. 15. Ursache und Korrektur dokumentieren.
22. Schnelle Befehlsübersicht | Aufgabe | Windows | Linux | macOS | |---|---|---|---| | Lokale Zeit | `[RO] Get-Date -Format o` | `[RO] date --iso-8601=seconds` | `[RO] date "+%Y-%m-%dT%H:%M:%S%z"` | | UTC-Zeit | `[RO] (Get-Date).ToUniversalTime().ToString("o")` | `[RO] date -u "+%Y-%m-%dT%H:%M:%SZ"` | `[RO] date -u "+%Y-%m-%dT%H:%M:%SZ"` | | Zeitzone | `[RO] Get-TimeZone` | `[RO] timedatectl status` | `[RO][PRIV] sudo systemsetup -gettimezone` | | Zeitdienst | `[RO] Get-Service W32Time` | `[RO] systemctl status ` | Systemdienst wird durch macOS verwaltet | | Zeitquelle | `[RO] w32tm /query /source` | `[RO] timedatectl timesync-status` oder `[RO] chronyc tracking` | `[RO][PRIV] sudo systemsetup -getnetworktimeserver` | | Synchronisationsstatus | `[RO] w32tm /query /status` | `[RO] timedatectl status` oder `[RO] chronyc tracking` | `[RO][PRIV] sudo systemsetup -getusingnetworktime` | | Zeitpartner | `[RO] w32tm /query /peers` | `[RO] chronyc sources -v` oder `[RO] ntpq -pn` | Eingetragener Netzwerkzeitserver | | Abweichung testen | `[TEST] w32tm /stripchart ...` | Quellenstatus des verwendeten Dienstes | `[TEST] sntp -d ` | | Protokolle | `[RO] Get-WinEvent ...` | `[RO][PRIV] sudo journalctl -u ` | `[RO][PRIV] sudo log show ...` | | Hardwareuhr | Nicht üblicherweise separat | `[RO][PRIV] sudo hwclock --show` | Nicht regulär erforderlich | | Synchronisation anfordern | `[CHANGE][PRIV] w32tm /resync` | Abhängig vom eingesetzten Dienst | Durch macOS beziehungsweise Systemeinstellungen | | NTP-Verkehr erfassen | Paketaufzeichnung erforderlich | `[TEST][PRIV] sudo tcpdump -ni any udp port 123` | `[TEST][PRIV] sudo tcpdump -ni any udp port 123` |
23. Entscheidungsmatrix | Befund | Wahrscheinliche Ursache | Nächster Schritt | |---|---|---| | UTC korrekt, Lokalzeit falsch | Zeitzone oder Sommerzeit | Zeitzonenkonfiguration prüfen | | UTC und Lokalzeit falsch | Zeitquelle oder Synchronisation | Dienst und Quelle untersuchen | | Zeitdienst läuft, keine Quelle | Netzwerk, DNS, Firewall oder Konfiguration | Erreichbarkeit und Zeitpartner prüfen | | Quelle ist lokale Hardwareuhr | Keine externe Synchronisation | Erwartete Zeitarchitektur prüfen | | Nur Domänenanmeldungen betroffen | Kerberos-Zeitabweichung möglich | Client, Server und DC vergleichen | | TLS und MFA gleichzeitig fehlerhaft | Systemzeit wahrscheinlich falsch | Datum, UTC und Quelle sofort prüfen | | Zeit springt nach Neustart zurück | RTC, Firmware, Host oder CMOS-Batterie | Startzeit und Hardware prüfen | | Nur eine VM betroffen | Hypervisor- oder Gastkonfiguration | Beide Zeitquellen vergleichen | | Alle Domänensysteme betroffen | Fehler in der AD-Zeithierarchie | PDC-Emulator und übergeordnete Quelle prüfen | | Abweichung wächst kontinuierlich | Uhrdrift oder keine Nachregelung | Messwerte und Dienstprotokolle untersuchen | | Exakt eine Stunde Abweichung | Zeitzone oder Sommerzeit | Zeitzone statt NTP-Konfiguration prüfen | | Host korrekt, Container falsch | Container-Zeitzone oder Anwendung | `TZ`, Zeitzonendateien und Anwendung prüfen |
24. Dokumentationsvorlage ```text Ticket: Datum und Uhrzeit der Analyse: Bearbeiter: Betroffenes System: Betriebssystem: Systemrolle: Physisch, virtuell oder Container: Domänenmitglied: Betroffene Anwendung oder Funktion: Originale Fehlermeldung: Lokale Zeit: UTC-Zeit: Zeitzone: Vergleichssystem: Gemessene Abweichung: Aktiver Zeitdienst: Dienststatus: Aktive Zeitquelle: Konfigurierte Zeitpartner: Letzte erfolgreiche Synchronisation: Stratum beziehungsweise Hierarchie: NTP-Antwort erhalten: UDP 123 erreichbar: DNS-Auflösung: Zeitbezogene Protokollmeldungen: Hypervisor-Zeitquelle: Snapshot oder Migration: Hardwareuhr: Gruppenrichtlinie oder Geräteverwaltung: Vermutete Ursache: Durchgeführte Tests: Durchgeführte Änderung: Auswirkung der Änderung: Rückfallplan: Zeitquelle nach der Maßnahme: Abweichung nach der Maßnahme: Synchronisationsstatus nach der Maßnahme: Funktionsprüfung: Weiterführende Maßnahmen: ```
--- **Merksatz** > Bei Zeitfehlern werden immer vier Dinge getrennt geprüft: aktuelle UTC-Zeit, lokale Zeitzone, verwendete Zeitquelle und tatsächlicher Synchronisationsstatus. Die Uhr wird erst verändert, wenn Ursache und Auswirkungen geklärt sind. **Quellen und weiterführende Dokumentation** - [Microsoft Learn – Windows Time Service Tools and Settings](https://learn.microsoft.com/windows-server/networking/windows-time-service/windows-time-service-tools-and-settings) - [Microsoft Learn – Funktionsweise des Windows-Zeitdiensts](https://learn.microsoft.com/windows-server/networking/windows-time-service/how-the-windows-time-service-works) - [Microsoft Learn – Windows Server Time Accuracy Improvements](https://learn.microsoft.com/windows-server/networking/windows-time-service/windows-server-2016-improvements) - [Microsoft Learn – Windows Time Service Technical Reference](https://learn.microsoft.com/windows-server/networking/windows-time-service/windows-time-service-tech-ref) - [systemd – timedatectl](https://www.freedesktop.org/software/systemd/man/latest/timedatectl.html) - [systemd – systemd-timesyncd](https://www.freedesktop.org/software/systemd/man/latest/systemd-timesyncd.service.html) - [chrony – Dokumentation](https://chrony-project.org/documentation.html) - [chrony – chronyc](https://chrony-project.org/doc/4.8/chronyc.html) - [Linux-Handbuch – hwclock](https://man7.org/linux/man-pages/man8/hwclock.8.html) - [Apple – Datum und Uhrzeit auf dem Mac automatisch einstellen](https://support.apple.com/de-de/guide/mac-help/mchlp2996/mac) - [Apple – Einstellungen für Datum und Uhrzeit](https://support.apple.com/de-de/guide/mac-help/mchlp1124/mac) - [Apple – Fehlerhafte Uhrzeit oder Zeitzone korrigieren](https://support.apple.com/en-us/101619) # 4.13 Update-, Patch- und Paketverwaltungsfehler Updates können in verschiedenen Phasen scheitern: bei der Erkennung, beim Herunterladen, bei der Signaturprüfung, während der Installation, beim Neustart oder erst nach der Aktivierung der neuen Komponenten. Dabei muss zwischen Betriebssystemupdates, Sicherheitsupdates, Treibern, Firmware, Anwendungspaketen und verwalteten Unternehmensupdates unterschieden werden. Typische Auswirkungen sind: - Updates werden nicht gefunden oder angeboten. - Der Download bleibt bei einem bestimmten Prozentwert stehen. - Pakete können wegen Abhängigkeitsfehlern nicht installiert werden. - Signaturen oder Zertifikate werden abgelehnt. - Ein Neustart wird wiederholt angefordert. - Ein Update wird nach dem Neustart zurückgerollt. - Dienste starten nach dem Update nicht mehr. - Paketdatenbanken oder Updatekomponenten sind beschädigt. - Ein WSUS-, Repository-, Proxy- oder MDM-Server ist nicht erreichbar. - Der Datenträger besitzt nicht genügend freien Speicherplatz. - Ein anderes Installationsprogramm blockiert die Paketverwaltung. - Das System verwendet eine nicht mehr unterstützte Version. - Ein Update ist für die verwendete Architektur oder Version ungeeignet. > **Wichtig:** Die Meldung „Update fehlgeschlagen“ bezeichnet nur das Ergebnis. Für die Diagnose müssen Updatequelle, Fehlerphase, Fehlercode, Systemzustand und Protokolle getrennt untersucht werden. **Kennzeichnung der Befehle** | Kennzeichnung | Bedeutung | |---|---| | `[RO]` | Nur lesender Befehl | | `[TEST]` | Führt eine aktive Prüfung aus | | `[PRIV]` | Erhöhte Berechtigungen erforderlich | | `[FILE]` | Liest Dateien oder Verzeichnisse | | `[SENS]` | Ausgabe kann sensible Informationen enthalten | | `[CHANGE]` | Verändert Cache, Konfiguration oder Systemzustand | | `[DISRUPT]` | Kann Dienste unterbrechen oder einen Neustart erfordern | ---
1. Updatefehler strukturiert aufnehmen Vor einer Reparatur müssen die genaue Updateart und die Fehlerphase bestimmt werden. **Zu erfassende Informationen** - Welches Betriebssystem und welche Version werden verwendet? - Welches konkrete Update oder Paket schlägt fehl? - Welche Paket-, KB-, Build- oder Versionsnummer ist betroffen? - Wird das Update direkt vom Hersteller oder intern bereitgestellt? - Tritt der Fehler bei Erkennung, Download, Prüfung, Installation oder Neustart auf? - Wird ein numerischer oder hexadezimaler Fehlercode angezeigt? - Sind alle Systeme oder nur einzelne Geräte betroffen? - Wurde das System kürzlich geklont, wiederhergestellt oder migriert? - Ist ein Neustart ausstehend? - Besteht ausreichend freier Speicherplatz? - Stimmen Datum und Uhrzeit? - Wird ein Proxy, VPN, WSUS, MDM oder internes Repository verwendet? - Wurden Sicherheitssoftware oder Firewallregeln verändert? - Ist die Betriebssystemversion noch unterstützt? - Funktionierte die Aktualisierung zuvor? - Welche Änderungen erfolgten unmittelbar vor dem Fehler? **Fehlerphasen** | Phase | Typische Ursachen | |---|---| | Erkennung | Updatequelle, Richtlinie, MDM, Repository oder nicht unterstützte Version | | Download | Netzwerk, DNS, Proxy, Firewall, CDN oder Speicherplatz | | Signaturprüfung | Falsche Zeit, Zertifikat, Schlüsselbund oder beschädigter Download | | Vorbereitung | Speicherplatz, Abhängigkeiten, Paketdatenbank oder Systemdateien | | Installation | Gesperrte Dateien, laufende Dienste, Abhängigkeiten oder Berechtigungen | | Neustart | Pending-Reboot-Zustand, Bootfehler, Treiber oder Firmware | | Aktivierung | Dienststart, Konfigurationsmigration oder inkompatible Anwendung | | Rollback | Installationsfehler, Bootproblem oder nicht erfüllte Voraussetzung | **Dokumentationsregel** Der originale Fehlercode muss vollständig übernommen werden. Beschreibungen wie „irgendein Updatefehler“ reichen für eine gezielte Analyse nicht aus.
2. Vorbedingungen auf allen Betriebssystemen prüfen Viele Updatefehler entstehen nicht in der Paketverwaltung selbst. | Prüfbereich | Warum er wichtig ist | |---|---| | Freier Speicherplatz | Updates benötigen Platz für Download, Entpacken, Installation und Rückfall | | Datum und Uhrzeit | Signaturen, Zertifikate und TLS-Verbindungen sind zeitabhängig | | DNS | Update- und Repositoryserver müssen aufgelöst werden | | Internet beziehungsweise internes Netzwerk | Updatequelle muss erreichbar sein | | Proxy | Systemdienste verwenden möglicherweise andere Proxyeinstellungen als Benutzer | | Neustartstatus | Eine ältere Installation kann noch nicht abgeschlossen sein | | Systemversion | Nicht mehr unterstützte Versionen erhalten möglicherweise keine Updates | | Architektur | Paket muss zu x64, ARM64 oder einer anderen Architektur passen | | Paketquelle | Repository, WSUS oder MDM muss gültige Metadaten bereitstellen | | Signaturen | Paket und Metadaten müssen vertrauenswürdig sein | | Berechtigungen | Installation benötigt normalerweise administrative Rechte | | Sicherung | Fehlerhafte Updates können einen Rollback erforderlich machen | **Schnellprüfung des Speicherplatzes** Windows: ```powershell [RO] Get-Volume | Select-Object DriveLetter, FileSystemLabel, HealthStatus, SizeRemaining, Size ``` Linux: ```bash [RO] df -hT ``` macOS: ```bash [RO] df -h ``` **Zeit prüfen** Windows: ```powershell [RO] Get-Date -Format o ``` Linux: ```bash [RO] timedatectl status ``` macOS: ```bash [RO] date "+%Y-%m-%dT%H:%M:%S%z" ```
3. Betriebssystemversion und Architektur ermitteln Ein Update kann nur installiert werden, wenn Version, Build, Edition und Architektur unterstützt werden. **Windows** ```powershell [RO] Get-ComputerInfo | Select-Object WindowsProductName, WindowsEditionId, WindowsVersion, OsBuildNumber, OsArchitecture ``` Kompakter: ```powershell [RO] Get-CimInstance Win32_OperatingSystem | Select-Object Caption, Version, BuildNumber, OSArchitecture ``` **Linux** ```bash [RO][FILE] cat /etc/os-release ``` ```bash [RO] uname -r ``` ```bash [RO] uname -m ``` **macOS** ```bash [RO] sw_vers ``` ```bash [RO] uname -m ``` **Typische Architekturbezeichnungen** | Bezeichnung | Bedeutung | |---|---| | `x86_64` beziehungsweise `AMD64` | 64-Bit-x86 | | `aarch64` beziehungsweise `ARM64` | 64-Bit-ARM | | `i386` oder `i686` | 32-Bit-x86 | | `arm64` unter macOS | Apple Silicon | | `x86_64` unter macOS | Intel-Mac oder gegebenenfalls übersetzter Prozess | > Die Prozessorarchitektur des Hosts, die Architektur des Betriebssystems und die Architektur eines einzelnen Programms können unterschiedlich sein.
4. Windows-Updatequelle und Richtlinien prüfen Windows-Geräte können Updates aus unterschiedlichen Quellen beziehen: - Windows Update - Microsoft Update - Windows Server Update Services, kurz WSUS - Microsoft Intune oder andere Geräteverwaltung - Windows Update for Business - Lokale oder zentrale Richtlinien - Manuell bereitgestellte Updatepakete **Windows-Update-Richtlinien anzeigen** ```powershell [RO][SENS] Get-ItemProperty ` -Path 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate' ` -ErrorAction SilentlyContinue ``` **Richtlinien für automatische Updates anzeigen** ```powershell [RO][SENS] Get-ItemProperty ` -Path 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU' ` -ErrorAction SilentlyContinue ``` **Angewendete Gruppenrichtlinien dokumentieren** ```cmd [RO][SENS] gpresult /scope computer /r ``` Ausführlichen HTML-Bericht erstellen: ```cmd [RO][FILE][SENS] gpresult /scope computer /h "\gpresult-computer.html" ``` **Relevante Hinweise** | Beobachtung | Mögliche Bedeutung | |---|---| | Interner Update-Server eingetragen | Gerät verwendet wahrscheinlich WSUS | | WSUS-Server nicht erreichbar | Erkennung und Download können scheitern | | Keine sichtbare lokale Richtlinie | Einstellung kann über MDM oder andere Verwaltung kommen | | Einstellung springt zurück | Zentrale Richtlinie überschreibt lokale Änderung | | Update wird anderen Geräten angeboten | Zielgruppen-, Freigabe- oder Kompatibilitätsunterschied möglich | | Gerät erhält nur bestimmte Updatearten | Richtlinie oder Updatekanal begrenzt das Angebot | > Registrywerte dürfen nicht allein aufgrund einer Internetanleitung gelöscht oder verändert werden. Zuerst muss festgestellt werden, ob sie zentral verwaltet werden.
5. Windows-Update-Dienste untersuchen **Relevante Dienste anzeigen** ```powershell [RO] Get-Service -Name wuauserv, bits, cryptsvc, trustedinstaller | Select-Object Name, DisplayName, Status, StartType ``` Bedeutung: | Dienst | Aufgabe | |---|---| | `wuauserv` | Windows Update | | `BITS` | Hintergrundübertragung von Dateien | | `CryptSvc` | Kryptografische Dienste und Signaturprüfungen | | `TrustedInstaller` | Windows Modules Installer | **Ausführliche Dienstinformationen** ```powershell [RO] Get-CimInstance Win32_Service | Where-Object { $_.Name -in 'wuauserv','BITS','CryptSvc','TrustedInstaller' } | Select-Object Name, State, StartMode, StartName, ExitCode ``` **Abhängigkeiten eines Dienstes anzeigen** ```powershell [RO] Get-Service -Name wuauserv -RequiredServices ``` **Wichtige Bewertung** - Ein beendeter Dienst ist nicht automatisch fehlerhaft. - Einige Dienste werden bedarfsgesteuert gestartet. - Der Starttyp `Manual` kann vorgesehen sein. - Zentral verwaltete Systeme können abweichende Konfigurationen verwenden. - Ein Dienstneustart behebt nicht die Ursache einer defekten Richtlinie oder Updatequelle.
6. Installierte Windows-Updates und Verlauf prüfen **Ausgewählte installierte Updates anzeigen** ```powershell [RO] Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object HotFixID, Description, InstalledOn, InstalledBy ``` > `Get-HotFix` zeigt nicht jede denkbare Update-, Treiber-, App- oder Servicing-Komponente an. Die Ausgabe darf deshalb nicht als vollständiges Inventar aller installierten Aktualisierungen interpretiert werden. **Installierte Windows-Pakete mit DISM anzeigen** ```cmd [RO][PRIV] DISM.exe /Online /Get-Packages /Format:Table ``` **Nach einem bestimmten KB-Paket suchen** ```powershell [RO] Get-HotFix -Id -ErrorAction SilentlyContinue ``` Beispiel: ```powershell [RO] Get-HotFix -Id KB5030000 -ErrorAction SilentlyContinue ``` Die KB-Nummer im Beispiel ist durch die tatsächlich zu prüfende Nummer zu ersetzen. **Installationszeit und Paketstatus mit DISM prüfen** ```cmd [RO][PRIV] DISM.exe /Online /Get-PackageInfo /PackageName: ``` Den exakten Paketnamen erhält man zuvor über: ```cmd [RO][PRIV] DISM.exe /Online /Get-Packages /Format:Table ```
7. Windows-Updateprotokolle auswerten Moderne Windows-Versionen speichern Windows-Update-Ereignisse überwiegend als ETL-Daten. `Get-WindowsUpdateLog` erzeugt daraus eine lesbare Protokolldatei. **Lesbares WindowsUpdate-Protokoll erzeugen** ```powershell [RO][FILE][SENS] Get-WindowsUpdateLog -LogPath "\WindowsUpdate.log" ``` > Der Befehl sammelt und konvertiert vorhandene Protokolldaten. Die erzeugte Datei kann Servernamen, URLs, Geräteinformationen und Fehlerdetails enthalten. **Windows-Update-Ereignisse anzeigen** ```powershell [RO][SENS] Get-WinEvent -LogName ` 'Microsoft-Windows-WindowsUpdateClient/Operational' | Select-Object -First 100 TimeCreated, LevelDisplayName, Id, Message ``` **Nur Warnungen und Fehler der letzten 24 Stunden** ```powershell [RO][SENS] Get-WinEvent -FilterHashtable @{ LogName = 'Microsoft-Windows-WindowsUpdateClient/Operational' StartTime = (Get-Date).AddHours(-24) } | Where-Object { $_.LevelDisplayName -in 'Warning','Error','Warnung','Fehler' } | Select-Object TimeCreated, LevelDisplayName, Id, Message ``` **Servicing-Protokolle** ```text [RO][FILE][SENS] %WINDIR%\Logs\CBS\CBS.log ``` ```text [RO][FILE][SENS] %WINDIR%\Logs\DISM\dism.log ``` **Setup- und Upgradeprotokolle können unter anderem hier liegen** ```text [RO][FILE][SENS] %WINDIR%\Panther ``` ```text [RO][FILE][SENS] %WINDIR%\Logs\MoSetup ``` Die tatsächlich vorhandenen Dateien hängen von Updateart, Betriebssystemversion und Fehlerphase ab. **Bei der Protokollanalyse suchen nach** - Fehlercode - KB-Nummer - Paketname - Zeitpunkt des Installationsversuchs - Downloadfehler - Signaturfehler - Paketabhängigkeit - ausstehendem Neustart - beschädigten Komponenten - Rollback-Ursache
8. Ausstehenden Windows-Neustart erkennen Ein ausstehender Neustart kann weitere Updates, Rolleninstallationen oder Paketänderungen blockieren. **Component-Based-Servicing prüfen** ```powershell [RO] Test-Path ` 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\RebootPending' ``` **Windows-Update-Neustartstatus prüfen** ```powershell [RO] Test-Path ` 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update\RebootRequired' ``` **Ausstehende Dateiumbenennungen prüfen** ```powershell [RO][SENS] Get-ItemProperty ` -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager' ` -Name PendingFileRenameOperations ` -ErrorAction SilentlyContinue ``` **Bewertung** - Nicht jeder vorhandene Indikator bedeutet denselben Neustartgrund. - Ein Neustart muss mit den Protokollen und dem Änderungsverlauf abgeglichen werden. - Produktivserver dürfen nicht unkontrolliert neu gestartet werden. - Vor dem Neustart müssen Dienste, Benutzer, Clusterstatus und Wartungsfenster geprüft werden.
9. Windows-Komponentenspeicher prüfen Beschädigungen im Windows-Komponentenspeicher können Updates und Rolleninstallationen verhindern. **Schnelle Prüfung** ```cmd [TEST][PRIV] DISM.exe /Online /Cleanup-Image /CheckHealth ``` `/CheckHealth` prüft, ob bereits eine Beschädigung markiert wurde. Es führt keinen vollständigen Scan aus. **Ausführlichere Prüfung** ```cmd [TEST][PRIV] DISM.exe /Online /Cleanup-Image /ScanHealth ``` **Systemdateien prüfen** ```cmd [TEST][PRIV] sfc /verifyonly ``` **Reparatur des Komponentenspeichers** ```cmd [CHANGE][PRIV] DISM.exe /Online /Cleanup-Image /RestoreHealth ``` **Systemdateien prüfen und reparieren** ```cmd [CHANGE][PRIV] sfc /scannow ``` **Wichtige Hinweise** - `RestoreHealth` kann Dateien von Windows Update beziehen. - In abgeschotteten Umgebungen kann eine passende Reparaturquelle erforderlich sein. - Eine Reparaturquelle muss zur Betriebssystemversion und zum Wartungsstand passen. - DISM und SFC können längere Zeit benötigen. - Ein Abbruch sollte nicht allein wegen eines länger unveränderten Prozentwerts erfolgen. - Protokolle befinden sich unter anderem in `CBS.log` und `dism.log`. > DISM und SFC sind keine pauschalen ersten Schritte für jeden Updatefehler. Zuerst müssen Fehlercode, Quelle, Speicherplatz und Updatephase geprüft werden.
10. Windows-Proxy und Netzwerkpfad prüfen Windows-Systemdienste können andere Proxyeinstellungen verwenden als ein angemeldeter Benutzer. **WinHTTP-Proxy anzeigen** ```cmd [RO] netsh winhttp show proxy ``` **DNS-Auflösung prüfen** ```powershell [RO] Resolve-DnsName "" ``` **HTTPS-Erreichbarkeit eines konkret bekannten Servers prüfen** ```powershell [TEST] Test-NetConnection ` -ComputerName "" ` -Port 443 ``` Bei einem internen WSUS-Server muss der tatsächlich konfigurierte Port verwendet werden. **Route anzeigen** ```powershell [RO] Test-NetConnection ` -ComputerName "" ` -TraceRoute ``` **Typische Ursachen** - Proxy verlangt eine interaktive Anmeldung. - WinHTTP-Proxy ist veraltet. - PAC-Datei funktioniert nur im Benutzerkontext. - Firewall blockiert Updateendpunkte. - TLS-Inspection verändert Zertifikate. - DNS liefert eine falsche oder interne Adresse. - VPN verändert Route oder Namensauflösung. - WSUS ist erreichbar, aber dessen Datenbank oder Anwendungspool ist gestört. > Öffentliche Updateplattformen verwenden mehrere dynamische Endpunkte. Es sollten keine unbestätigten Einzeladressen dauerhaft freigeschaltet werden; maßgeblich ist die aktuelle Herstellerdokumentation.
11. Debian- und Ubuntu-Paketverwaltung prüfen Debian und Ubuntu verwenden üblicherweise APT und dpkg. **Betriebssystemversion prüfen** ```bash [RO][FILE] cat /etc/os-release ``` **Konfigurierte Paketquellen anzeigen** ```bash [RO][FILE][SENS] grep -RhsE '^[[:space:]]*deb ' \ /etc/apt/sources.list /etc/apt/sources.list.d 2>/dev/null ``` Neuere APT-Quellen können zusätzlich im Deb822-Format mit der Endung `.sources` gespeichert sein: ```bash [RO][FILE][SENS] grep -RhsE \ '^[[:space:]]*(Types|URIs|Suites|Components|Signed-By):' \ /etc/apt/sources.list.d 2>/dev/null ``` **Paketstatus auf Inkonsistenzen prüfen** ```bash [RO][PRIV] sudo dpkg --audit ``` Alternativ: ```bash [RO][PRIV] sudo dpkg -C ``` **Paketabhängigkeiten prüfen** ```bash [TEST][PRIV] sudo apt-get check ``` **Installierte und verfügbare Version eines Pakets anzeigen** ```bash [RO] apt-cache policy "" ``` **Zurückgehaltene Pakete anzeigen** ```bash [RO] apt-mark showhold ``` **Paketarchitektur anzeigen** ```bash [RO] dpkg --print-architecture ``` Zusätzlich konfigurierte Architekturen: ```bash [RO] dpkg --print-foreign-architectures ``` **Letzte dpkg-Aktionen anzeigen** ```bash [RO][FILE][SENS] tail -n 100 /var/log/dpkg.log ``` **APT-Verlauf anzeigen, sofern vorhanden** ```bash [RO][FILE][SENS] ls -l /var/log/apt ``` ```bash [RO][FILE][SENS] tail -n 100 /var/log/apt/history.log ```
12. APT-Aktualisierung und Fehlerausgabe kontrolliert prüfen Das Aktualisieren der Paketlisten ist bereits eine Veränderung des lokalen Paketcache. ```bash [CHANGE][PRIV] sudo apt update ``` Dabei sind besonders folgende Meldungen zu beachten: | Meldung | Mögliche Ursache | |---|---| | `Temporary failure resolving` | DNS-Problem | | `Connection timed out` | Netzwerk, Proxy, Firewall oder Repository | | `404 Not Found` | Falscher Distributionsname oder veraltete Quelle | | `NO_PUBKEY` | Fehlender oder falsch eingebundener Signaturschlüssel | | `Release file is not valid yet` | Systemzeit möglicherweise falsch | | `does not have a Release file` | Quelle unterstützt die Distribution nicht | | `Hash Sum mismatch` | Spiegelserver, Proxycache oder inkonsistente Metadaten | | `Could not get lock` | Andere Paketverwaltung ist aktiv | | `Unmet dependencies` | Abhängigkeitskonflikt | | `held broken packages` | Zurückgehaltene oder nicht auflösbare Pakete | | `No space left on device` | Speicherplatz oder Inodes ausgeschöpft | **Simulation einer Installation** ```bash [TEST] apt-get --simulate install "" ``` Die Simulation verändert keine Pakete, bildet aber nicht jede Nebenwirkung eines tatsächlichen Installationsskripts ab. **Paketinformationen anzeigen** ```bash [RO] apt-cache show "" ``` **Abhängigkeiten anzeigen** ```bash [RO] apt-cache depends "" ``` **Reverse-Abhängigkeiten anzeigen** ```bash [RO] apt-cache rdepends "" ```
13. Paketmanager-Sperren unter Linux untersuchen Eine Sperrdatei darf nicht allein aufgrund ihrer Existenz gelöscht werden. Zuerst muss geprüft werden, ob ein Paketmanager tatsächlich arbeitet. **APT- und dpkg-Prozesse anzeigen** ```bash [RO][SENS] ps -ef | grep -E '[a]pt|[d]pkg|[u]nattended-upgrade' ``` **Prozesse mit geöffneten APT- oder dpkg-Sperren anzeigen** ```bash [RO][PRIV][SENS] sudo lsof \ /var/lib/dpkg/lock \ /var/lib/dpkg/lock-frontend \ /var/lib/apt/lists/lock \ /var/cache/apt/archives/lock 2>/dev/null ``` **Automatische Updates prüfen** ```bash [RO] systemctl status apt-daily.service --no-pager ``` ```bash [RO] systemctl status apt-daily-upgrade.service --no-pager ``` **Protokolle automatischer Updates** ```bash [RO][PRIV][SENS] sudo journalctl \ -u apt-daily.service \ -u apt-daily-upgrade.service \ --since "-24 hours" --no-pager ``` > Das Löschen einer Sperrdatei oder Beenden eines Paketmanagers während einer Installation kann die Paketdatenbank beschädigen. Erst muss geklärt werden, ob der Prozess noch arbeitet, wartet oder abgestürzt ist.
14. Unvollständige dpkg-Transaktionen behandeln Ein abgebrochener Installationsprozess kann Pakete in einem nicht fertig konfigurierten Zustand hinterlassen. **Zustand zunächst prüfen** ```bash [RO][PRIV] sudo dpkg --audit ``` **Paketstatus eines bestimmten Pakets anzeigen** ```bash [RO] dpkg-query -W \ -f='${Package}\t${Status}\t${Version}\n' "" ``` **Noch nicht konfigurierte Pakete konfigurieren** ```bash [CHANGE][PRIV] sudo dpkg --configure -a ``` **Abhängigkeiten reparieren** ```bash [CHANGE][PRIV] sudo apt-get --fix-broken install ``` Diese Befehle können: - Paketkonfigurationen ausführen - Dienste starten oder neu starten - Konfigurationsdateien verändern - zusätzliche Pakete installieren - Pakete entfernen - Administratorfragen anzeigen Vorher sollten geprüft werden: - Sicherung oder Snapshot - freier Speicherplatz - aktueller Paketstatus - betroffene Produktivdienste - vorgeschlagene Paketänderungen - Wartungsfenster > Bei `apt-get --fix-broken install` muss die vorgeschlagene Paketliste vor der Bestätigung vollständig gelesen werden.
15. DNF- und RPM-Systeme untersuchen Fedora, Red Hat Enterprise Linux und verwandte Distributionen verwenden häufig DNF und RPM. **Betriebssystemversion** ```bash [RO][FILE] cat /etc/os-release ``` **Aktive Repositories anzeigen** ```bash [RO][SENS] dnf repolist ``` **Alle bekannten Repositories anzeigen** ```bash [RO][SENS] dnf repolist --all ``` **Paketdatenbank und Abhängigkeiten prüfen** ```bash [TEST][PRIV] sudo dnf check ``` **Verfügbare Aktualisierungen prüfen** ```bash [TEST][PRIV] sudo dnf check-update ``` > `dnf check-update` kann mit Rückgabecode `100` enden, wenn Updates verfügbar sind. Dieser Rückgabecode bedeutet dann nicht automatisch einen Fehler. **Paketinformationen anzeigen** ```bash [RO] dnf info "" ``` **Installierte Paketversion anzeigen** ```bash [RO] rpm -q "" ``` **Paketarchitektur anzeigen** ```bash [RO] rpm -q --queryformat \ '%{NAME}\t%{VERSION}-%{RELEASE}\t%{ARCH}\n' "" ``` **Transaktionsverlauf anzeigen** ```bash [RO][SENS] dnf history ``` **Details einer Transaktion** ```bash [RO][SENS] dnf history info ``` **Installierte Dateien gegen RPM-Metadaten prüfen** ```bash [TEST][PRIV][FILE][SENS] sudo rpm -Va ``` `rpm -Va` kann lange laufen und meldet auch absichtlich veränderte Konfigurationsdateien. Abweichungen sind nicht automatisch Beschädigungen.
16. Zypper- und RPM-Systeme untersuchen SUSE Linux Enterprise und openSUSE verwenden typischerweise Zypper. **Repositories anzeigen** ```bash [RO][SENS] zypper repos ``` Ausführlicher: ```bash [RO][SENS] zypper repos --details ``` **Verfügbare Patches anzeigen** ```bash [TEST][PRIV] sudo zypper list-patches ``` **Abhängigkeiten prüfen** ```bash [TEST][PRIV] sudo zypper verify ``` **Paketinformationen anzeigen** ```bash [RO] zypper info "" ``` **Installierte Version prüfen** ```bash [RO] rpm -q "" ``` **Zypper-Protokoll lesen** ```bash [RO][FILE][SENS] tail -n 100 /var/log/zypper.log ```
17. macOS-Softwareupdates untersuchen **macOS-Version und Build anzeigen** ```bash [RO] sw_vers ``` **Verfügbare Apple-Softwareupdates suchen** ```bash [TEST] softwareupdate --list ``` Der Befehl kontaktiert die konfigurierte Updateinfrastruktur und kann einige Zeit benötigen. **Verlauf installierter Apple-Updates anzeigen** ```bash [RO] softwareupdate --history ``` Ausführlicher Verlauf: ```bash [RO] softwareupdate --history --all ``` **Hilfe der installierten softwareupdate-Version anzeigen** ```bash [RO] softwareupdate --help ``` > Die verfügbaren Optionen von `softwareupdate` können sich zwischen macOS-Versionen unterscheiden. Deshalb sollte die lokale Hilfe geprüft werden, bevor Installationsoptionen verwendet werden. **Freien Speicherplatz prüfen** ```bash [RO] df -h / ``` **Datum und Uhrzeit prüfen** ```bash [RO] date "+%Y-%m-%dT%H:%M:%S%z" ``` **Netzwerkzeitstatus prüfen** ```bash [RO][PRIV] sudo systemsetup -getusingnetworktime ``` **Eingetragenen Zeitserver anzeigen** ```bash [RO][PRIV][SENS] sudo systemsetup -getnetworktimeserver ``` **MDM-Registrierungsstatus anzeigen** ```bash [RO][PRIV][SENS] sudo profiles status -type enrollment ``` Ein verwalteter Mac kann Updates aufgrund von MDM-Vorgaben: - verzögert angeboten bekommen - zu einem Termin erzwungen installieren - nur über bestimmte Updatekanäle erhalten - mit anderen Neustartbedingungen installieren - nicht manuell verändern dürfen
18. macOS-Updateprotokolle auswerten **Softwareupdate-Protokolle der letzten Stunde** ```bash [RO][PRIV][SENS] sudo log show --last 1h \ --predicate 'process == "softwareupdated"' \ --style compact ``` **Mehrere typische Updateprozesse berücksichtigen** ```bash [RO][PRIV][SENS] sudo log show --last 2h \ --predicate 'process == "softwareupdated" OR process == "softwareupdate"' \ --style compact ``` **Nur Fehler und schwerwiegende Meldungen** ```bash [RO][PRIV][SENS] sudo log show --last 2h \ --predicate '(process == "softwareupdated" OR process == "softwareupdate") AND messageType >= error' \ --style compact ``` Die von macOS verwendeten Prozesse und Protokollfelder können sich zwischen Versionen unterscheiden. Wenn die Abfrage keine Ergebnisse liefert, bedeutet dies nicht automatisch, dass kein Updateversuch stattgefunden hat. **Typische Ursachen** - Zu wenig Speicherplatz - Nicht unterstütztes Mac-Modell - Falsche Systemzeit - Netzwerk- oder CDN-Problem - MDM-Aufschub - Fehlende Benutzerbestätigung - FileVault- oder Bootstrap-Token-Anforderung in verwalteten Umgebungen - Beschädigter Download - Nicht abgeschlossener vorheriger Updateversuch - Firmware- oder Wiederherstellungsfehler - Update wird für den verwendeten Kanal noch nicht angeboten
19. Repository-, Signatur- und Zertifikatsfehler unterscheiden Softwarepakete und Repositorymetadaten werden normalerweise kryptografisch geprüft. **Typische Fehlerursachen** | Ursache | Wirkung | |---|---| | Falsche Systemzeit | Zertifikat oder signierte Metadaten erscheinen ungültig | | Abgelaufener Signaturschlüssel | Repository wird nicht akzeptiert | | Falscher Schlüssel | Signatur kann nicht verifiziert werden | | Manipulierender Proxy | TLS- oder Zertifikatsprüfung schlägt fehl | | Unvollständiger Download | Prüfsumme stimmt nicht | | Veraltete Repositorydefinition | Release-Datei oder Paketpfad fehlt | | Nicht unterstützte Distribution | Repository stellt keine passenden Metadaten bereit | | Falsche Architektur | Paket kann nicht installiert werden | | Internes Zertifikat fehlt | Unternehmensrepository wird nicht vertraut | | Spiegelserver nicht synchron | Metadaten und Paketdateien passen vorübergehend nicht zusammen | **Sicherheitsregel** Signatur- und Zertifikatsprüfungen dürfen nicht dauerhaft deaktiviert werden, um eine Installation „zum Laufen zu bringen“. Stattdessen müssen geprüft werden: 1. Systemzeit 2. Repositoryadresse 3. Distributionsversion 4. Paketarchitektur 5. erwarteter Signaturschlüssel 6. Zertifikatskette 7. Proxy- oder TLS-Inspection 8. Integrität des Downloads 9. offizielle Installationsanleitung des Herstellers
20. Abhängigkeiten und Versionskonflikte analysieren Paketmanager installieren selten nur eine einzelne Datei. Pakete besitzen Abhängigkeiten, Konflikte und Versionsanforderungen. **Typische Beziehungen** | Beziehung | Bedeutung | |---|---| | Abhängigkeit | Zusätzlich benötigtes Paket | | Versionsabhängigkeit | Nur bestimmte Versionen sind zulässig | | Konflikt | Pakete dürfen nicht gleichzeitig installiert sein | | Ersatz | Ein Paket ersetzt ein anderes | | Empfehlung | Zusätzliches Paket wird empfohlen | | Architekturabhängigkeit | Paket benötigt eine bestimmte Plattform | | Modulschnittstelle | Anwendung benötigt eine kompatible Bibliotheksversion | **APT-Abhängigkeiten anzeigen** ```bash [RO] apt-cache depends "" ``` **APT-Reverse-Abhängigkeiten** ```bash [RO] apt-cache rdepends "" ``` **RPM-Abhängigkeiten anzeigen** ```bash [RO] rpm -qR "" ``` **Paket ermitteln, das eine Fähigkeit bereitstellt** DNF: ```bash [RO] dnf provides "" ``` APT: ```bash [RO] apt-file search "" ``` `apt-file` ist nicht standardmäßig auf jedem System installiert und benötigt einen eigenen Suchindex. **Diagnosefragen** - Ist das benötigte Repository aktiviert? - Ist ein Paket bewusst festgehalten worden? - Wurden Fremdquellen gemischt? - Wird ein Paket aus einer anderen Distributionsversion verwendet? - Verlangt die Anwendung eine ältere Bibliothek? - Wurde ein Teilupdate durchgeführt? - Passt die Architektur? - Ist ein Herstellerrepository noch unterstützt?
21. Paketcache und heruntergeladene Dateien richtig bewerten Beschädigte oder unvollständige Downloads können wiederholte Fehler verursachen. Das pauschale Löschen aller Updatecaches ist dennoch kein sinnvoller erster Diagnoseschritt. **Vor einer Cachebereinigung prüfen** - Ist der Fehler reproduzierbar? - Ist die Prüfsumme falsch? - Betrifft der Fehler immer dieselbe Datei? - Liegt ein Proxycache zwischen Client und Repository? - Ist genügend Speicherplatz vorhanden? - Gibt es noch einen aktiven Paketmanager? - Werden Dateien für einen Rollback benötigt? - Kann der Download aus einer vertrauenswürdigen Quelle erneut erfolgen? **APT-Downloadcache anzeigen** ```bash [RO][FILE] du -sh /var/cache/apt/archives ``` **DNF-Cachebelegung anzeigen** ```bash [RO][FILE][PRIV] sudo du -sh /var/cache/dnf ``` **Windows-Update-Downloadbereich** ```text [RO][FILE][PRIV] %WINDIR%\SoftwareDistribution\Download ``` > Der Ordner `SoftwareDistribution` darf nicht unkontrolliert umbenannt oder gelöscht werden. Ein Reset der Windows-Updatekomponenten verändert den Updatezustand und erschwert möglicherweise die ursprüngliche Ursachenanalyse.
22. Automatische Updates und Wartungsfenster prüfen Automatische Aktualisierungen können parallel zu manuellen Arbeiten laufen oder durch Wartungsregeln eingeschränkt sein. **Windows** Zu prüfen sind: - Gruppenrichtlinien - Windows Update for Business - WSUS-Zielgruppen - aktive Nutzungszeit - Neustartrichtlinien - Intune-Update-Ringe - geplante Wartungsfenster **Debian und Ubuntu** ```bash [RO] systemctl status apt-daily.timer --no-pager ``` ```bash [RO] systemctl status apt-daily-upgrade.timer --no-pager ``` ```bash [RO][FILE] systemctl list-timers --all | grep -E 'apt|upgrade' ``` **DNF-Systeme** ```bash [RO] systemctl list-timers --all | grep -E 'dnf|upgrade' ``` Je nach Distribution und Konfiguration kann beispielsweise `dnf-automatic` verwendet werden. **macOS** Zu prüfen sind: - Einstellungen für automatische Updates - MDM-Aufschübe - erzwungene Installationstermine - erforderliche Benutzeraktion - Neustartbedingungen - verfügbare Bootstrap- oder Secure Tokens > Automatische Updateprozesse dürfen nicht beendet werden, ohne ihren aktuellen Transaktionszustand zu prüfen.
23. Updatefehler nach dem Neustart analysieren Ein Update kann zunächst erfolgreich erscheinen und erst beim Neustart scheitern. **Typische Symptome** - Endlose Neustartschleife - „Änderungen werden rückgängig gemacht“ - Dienst startet nicht - Treiber wird nicht geladen - Netzwerkverbindung fehlt - Anwendung ist inkompatibel - Kernel startet nicht - Dateisystem muss geprüft werden - Firmwareaktualisierung schlägt fehl - Verschlüsseltes Systemvolume wird nicht entsperrt **Prüfreihenfolge** 1. Exakte Meldung und Zeitpunkt dokumentieren. 2. Prüfen, ob ein automatischer Rollback erfolgt ist. 3. Update- und Bootprotokolle sichern. 4. Zuletzt installierte Pakete ermitteln. 5. Dienst- und Treiberstatus kontrollieren. 6. Freien Speicherplatz prüfen. 7. Abhängige Systeme und Clusterstatus berücksichtigen. 8. Herstellerhinweise zum konkreten Update prüfen. 9. Rücknahme nur nach Bewertung der Sicherheitsauswirkung durchführen. 10. Vor erneuter Installation die ursprüngliche Ursache beheben. **Linux: vorherigen Boot untersuchen** ```bash [RO][PRIV][SENS] sudo journalctl -b -1 -p warning --no-pager ``` **Windows: letzte Systemfehler** ```powershell [RO][SENS] Get-WinEvent -FilterHashtable @{ LogName = 'System' StartTime = (Get-Date).AddHours(-24) } | Where-Object { $_.LevelDisplayName -in 'Warning','Error','Warnung','Fehler' } | Select-Object TimeCreated, ProviderName, Id, LevelDisplayName, Message ```
24. Updates in Clustern und hochverfügbaren Systemen Bei Clustern, Replikationssystemen und redundanten Diensten reicht die Betrachtung eines einzelnen Servers nicht aus. **Vor einem Update prüfen** - Ist der Cluster gesund? - Funktioniert die Replikation? - Ist ausreichend Redundanz vorhanden? - Welcher Knoten besitzt aktuell die produktiven Rollen? - Können Rollen kontrolliert verschoben werden? - Ist Quorum beziehungsweise Witness erreichbar? - Sind alle Knoten kompatibel? - Unterstützt der Hersteller gemischte Patchstände? - Existiert ein getesteter Rückfallplan? - Ist das Monitoring aktiv? - Wurde eine Sicherung geprüft? **Gefahren** - Mehrere Knoten werden gleichzeitig neu gestartet. - Ein bereits gestörter Knoten wird als Ausweichknoten eingeplant. - Datenbankschema und Anwendungsversion passen nicht zusammen. - Quorum geht verloren. - Load Balancer leitet weiterhin auf einen gewarteten Knoten. - Replikation wird durch Versionsunterschiede unterbrochen. - Ein automatisches Update umgeht das Wartungsfenster. > Ein Snapshot eines einzelnen Clusterknotens ist kein vollständiger Rückfallplan für einen verteilten Dienst.
25. Sichere Reihenfolge der Updatefehleranalyse 1. Betroffenes Update, Paket oder KB eindeutig bestimmen. 2. Originalen Fehlercode und Fehlerzeitpunkt dokumentieren. 3. Betriebssystemversion, Build und Architektur prüfen. 4. Updatephase bestimmen. 5. Freien Speicherplatz und Inodes kontrollieren. 6. Datum, Uhrzeit und Zeitzone prüfen. 7. Ausstehenden Neustart berücksichtigen. 8. Updatequelle, Repository, WSUS oder MDM ermitteln. 9. DNS, Proxy, Firewall und Erreichbarkeit prüfen. 10. Paketmanager- beziehungsweise Updatedienste untersuchen. 11. Protokolle zum Fehlerzeitpunkt auswerten. 12. Paketabhängigkeiten und Signaturen prüfen. 13. Aktive Installations- oder Sperrprozesse identifizieren. 14. Systemdateien beziehungsweise Paketdatenbank kontrollieren. 15. Erst danach Cachebereinigung oder Reparaturmaßnahmen planen. 16. Änderung im Wartungsfenster durchführen. 17. Neustartbedarf kontrolliert umsetzen. 18. Update-, Dienst- und Anwendungsfunktion verifizieren. 19. Ergebnis und verbleibende Risiken dokumentieren.
26. Typische Fehlinterpretationen vermeiden | Fehlinterpretation | Richtige Bewertung | |---|---| | „Der Download hängt bei 0 Prozent.“ | Verbindung, Metadatenprüfung oder Vorbereitung kann bereits laufen. | | „Der Update-Dienst ist beendet.“ | Bedarfsgesteuerter Dienst kann regulär beendet sein. | | „Ping funktioniert, also ist Windows Update erreichbar.“ | DNS, HTTPS, Proxy, CDN und Authentifizierung sind zusätzlich relevant. | | „Ein Neustart ist immer harmlos.“ | Produktivdienste, Cluster und Benutzer müssen berücksichtigt werden. | | „Cache löschen behebt jeden Updatefehler.“ | Es entfernt Symptome und erschwert möglicherweise die Diagnose. | | „Signaturprüfung kann vorübergehend deaktiviert werden.“ | Dadurch wird eine wichtige Sicherheitskontrolle umgangen. | | „Get-HotFix zeigt alle installierten Updates.“ | Es erfasst nicht jede Update- und Paketart. | | „Rückgabecode 100 von dnf ist ein Fehler.“ | Bei `dnf check-update` kann er verfügbare Updates anzeigen. | | „Eine Sperrdatei kann einfach gelöscht werden.“ | Eine aktive Pakettransaktion könnte beschädigt werden. | | „Update fehlgeschlagen bedeutet fehlerhaftes Update.“ | Ursache kann lokal in Speicher, Netzwerk, Zeit oder Paketstatus liegen. | | „Snapshot entspricht einer Sicherung.“ | Snapshot und unabhängige Sicherung erfüllen unterschiedliche Aufgaben. | | „Update erfolgreich bedeutet Dienst funktionsfähig.“ | Nachkontrolle von Diensten und Anwendungen bleibt erforderlich. |
27. Schnelle Befehlsübersicht | Aufgabe | Windows | Debian/Ubuntu | RHEL/Fedora | macOS | |---|---|---|---|---| | Betriebssystemversion | `[RO] Get-ComputerInfo` | `[RO] cat /etc/os-release` | `[RO] cat /etc/os-release` | `[RO] sw_vers` | | Architektur | `[RO] Get-CimInstance Win32_OperatingSystem` | `[RO] dpkg --print-architecture` | `[RO] uname -m` | `[RO] uname -m` | | Freier Speicher | `[RO] Get-Volume` | `[RO] df -hT` | `[RO] df -hT` | `[RO] df -h` | | Updatequelle | Richtlinien und WSUS prüfen | APT-Quelldateien prüfen | `[RO] dnf repolist` | MDM und Updateeinstellungen | | Updatedienste | `[RO] Get-Service wuauserv,bits,cryptsvc,trustedinstaller` | APT-Timer und Prozesse | DNF-Timer und Prozesse | macOS-Systemdienst | | Updatehistorie | `Get-HotFix` und DISM | APT- und dpkg-Protokolle | `[RO] dnf history` | `[RO] softwareupdate --history` | | Verfügbare Updates | Windows-Updateverwaltung | `[CHANGE][PRIV] sudo apt update` | `[TEST][PRIV] sudo dnf check-update` | `[TEST] softwareupdate --list` | | Paketstatus prüfen | DISM | `[RO][PRIV] sudo dpkg --audit` | `[TEST][PRIV] sudo dnf check` | Updateprotokoll prüfen | | Abhängigkeiten prüfen | CBS- und DISM-Protokoll | `[TEST][PRIV] sudo apt-get check` | `[TEST][PRIV] sudo dnf check` | Nicht direkt vergleichbar | | Paketversion | DISM oder `Get-HotFix` | `[RO] apt-cache policy ""` | `[RO] rpm -q ""` | Anwendungsspezifisch | | Ausstehender Neustart | Registryindikatoren prüfen | `/var/run/reboot-required` kann distributionsabhängig existieren | Paket- und Kernelstatus prüfen | Update- und MDM-Status prüfen | | Protokolle | `Get-WindowsUpdateLog`, CBS, Ereignisanzeige | `/var/log/apt`, `/var/log/dpkg.log`, Journal | `dnf history`, Journal | `[RO][PRIV] log show ...` | | Systemintegrität | `[TEST][PRIV] DISM /ScanHealth` | Paketdatenbank prüfen | `[TEST][PRIV] rpm -Va` | Festplatten- und Updateprotokolle | | Proxy | `[RO] netsh winhttp show proxy` | APT- und Umgebungsvariablen prüfen | DNF- und Umgebungsvariablen prüfen | Netzwerk- und MDM-Konfiguration |
28. Entscheidungsmatrix | Befund | Wahrscheinliche Ursache | Nächster Schritt | |---|---|---| | Update wird nicht angeboten | Richtlinie, Kanal, Kompatibilität oder Supportstatus | Quelle und Voraussetzungen prüfen | | Download startet nicht | DNS, Proxy, Firewall oder Repository | Netzwerkpfad untersuchen | | Download wiederholt beschädigt | Proxycache, Spiegelserver oder Datenträger | Prüfsumme, Quelle und Speicher prüfen | | Signatur ungültig | Zeit, Schlüssel oder Zertifikatskette | Zeit und Vertrauenskette prüfen | | Nicht genügend Speicher | System- oder temporäres Volume voll | Speicherverbrauch analysieren | | Paketmanager ist gesperrt | Andere Transaktion aktiv | Prozess und Protokolle prüfen | | Paketabhängigkeit nicht erfüllbar | Fehlendes Repository oder Versionskonflikt | Abhängigkeitsbaum untersuchen | | Neustart wird wiederholt verlangt | Ausstehende Operation nicht abgeschlossen | Pending-Reboot-Status und Protokolle prüfen | | Update rollt zurück | Installations-, Treiber- oder Bootfehler | Setup- und Systemprotokolle auswerten | | Mehrere Geräte betroffen | Zentrale Quelle, Richtlinie oder Herstellerproblem | Gemeinsamen Nenner ermitteln | | Nur ein Gerät betroffen | Lokaler Cache, Zustand oder Konfiguration | Mit funktionierendem Vergleichssystem abgleichen | | Update erfolgreich, Dienst ausgefallen | Inkompatibilität oder Konfigurationsmigration | Dienstprotokolle und Herstellerhinweise prüfen | | Betriebssystem nicht mehr unterstützt | Keine reguläre Updateversorgung | Geplantes Upgrade beziehungsweise Migration | | DNF endet mit Code 100 | Updates verfügbar | Nicht als Paketmanagerfehler behandeln |
29. Dokumentationsvorlage ```text Ticket: Datum und Uhrzeit: Bearbeiter: Betroffenes System: Betriebssystem: Version und Build: Architektur: Systemrolle: Physisch oder virtuell: Cluster- oder Domänenmitglied: Updateart: KB-, Paket- oder Versionsnummer: Updatequelle: WSUS, Repository oder MDM: Fehlerphase: Originaler Fehlercode: Originale Fehlermeldung: Zeitpunkt des Fehlers: Freier Speicher: Inode-Belegung: Datum und Uhrzeit: Ausstehender Neustart: Updatedienst: Paketmanager: Aktive Installationsprozesse: Sperrstatus: DNS-Auflösung: Proxy: Erreichbarkeit der Updatequelle: Signatur- oder Zertifikatsfehler: Repositorystatus: Abhängigkeitsfehler: Relevante Protokolle: Letzte erfolgreiche Aktualisierung: Letzte Änderungen: Vergleich mit funktionierendem System: Vermutete Ursache: Durchgeführte Tests: Sicherung geprüft: Wartungsfenster: Durchgeführte Änderung: Neustart durchgeführt: Rückfallplan: Installationsstatus nach der Maßnahme: Dienststatus: Anwendungsprüfung: Monitoring unauffällig: Weiterführende Maßnahmen: ```
--- **Merksatz** > Bei Updatefehlern wird nicht sofort der Cache gelöscht oder das Paket erneut installiert. Zuerst werden Updatequelle, Fehlerphase, Fehlercode, Speicherplatz, Zeit, Netzwerk, Paketstatus und Protokolle geprüft. **Quellen und weiterführende Dokumentation** - [Microsoft Learn – Windows-Updateprobleme behandeln](https://learn.microsoft.com/troubleshoot/windows-client/deployment/troubleshoot-windows-update-issues) - [Microsoft Learn – Windows-Update-Beschädigungen und Installationsfehler beheben](https://learn.microsoft.com/de-de/troubleshoot/windows-server/installing-updates-features-roles/fix-windows-update-errors) - [Microsoft Learn – Get-WindowsUpdateLog](https://learn.microsoft.com/powershell/module/windowsupdate/get-windowsupdatelog) - [Microsoft Learn – DISM-Befehlszeilenoptionen](https://learn.microsoft.com/windows-hardware/manufacture/desktop/dism-reference--deployment-image-servicing-and-management) - [Microsoft Learn – Windows Update for Business](https://learn.microsoft.com/windows/deployment/update/waas-manage-updates-wufb) - [Debian-Handbuch – APT](https://www.debian.org/doc/manuals/debian-handbook/apt.en.html) - [Ubuntu Server – Paketverwaltung](https://documentation.ubuntu.com/server/how-to/software/package-management/) - [Ubuntu Manpages – apt-get](https://manpages.ubuntu.com/manpages/noble/en/man8/apt-get.8.html) - [DNF-Dokumentation – Command Reference](https://dnf.readthedocs.io/en/latest/command_ref.html) - [Red Hat – DNF-Paketverwaltung](https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/managing_software_with_the_dnf_tool/) - [openSUSE – Zypper-Dokumentation](https://doc.opensuse.org/documentation/leap/reference/html/book-opensuse-reference/cha-sw-cl.html) - [Apple – Softwareupdate-Prozess überprüfen](https://support.apple.com/de-de/guide/deployment/dep02c211f3e/web) - [Apple – Softwareupdates mit der Geräteverwaltung anwenden](https://support.apple.com/de-de/guide/deployment/depafd2fad80/web) - [Apple-Handbuch – softwareupdate](https://keith.github.io/xcode-man-pages/softwareupdate.8.html) # 4.14 Virtualisierungs- und Containerfehler Bei virtualisierten Systemen befindet sich die Ursache einer Störung nicht zwangsläufig innerhalb des betroffenen Servers oder Containers. Der Fehler kann im Gastbetriebssystem, Hypervisor, Hostbetriebssystem, virtuellen Netzwerk, Storage, Managementsystem oder in einer Abhängigkeit außerhalb der Virtualisierungsplattform liegen. Typische Auswirkungen sind: - Eine virtuelle Maschine startet nicht. - Eine VM läuft, ist aber nicht erreichbar. - Ein Container beendet sich unmittelbar nach dem Start. - Ein Container befindet sich in einer Neustartschleife. - Die Anwendung ist nicht über den veröffentlichten Port erreichbar. - Ein virtueller Datenträger ist voll oder nicht verfügbar. - Snapshots wachsen unkontrolliert. - Der Host besitzt zu wenig RAM, CPU oder Speicherplatz. - Eine VM ist nach einer Migration oder Snapshot-Wiederherstellung inkonsistent. - Virtuelle Netzwerkkarten sind mit dem falschen Netzwerk verbunden. - Container können DNS-Namen oder andere Container nicht erreichen. - Volume-Daten fehlen nach der Neuerstellung eines Containers. - Das verwendete Image passt nicht zur Prozessorarchitektur. - Integrationsdienste oder Gasterweiterungen sind fehlerhaft. - Host und Gast verwenden konkurrierende Zeitquellen. > **Wichtig:** Eine laufende VM, ein laufender Container oder ein Status `Up` beweist nur, dass der jeweilige Prozess gestartet wurde. Damit ist noch nicht bestätigt, dass Betriebssystem, Anwendung, Netzwerk, Storage und Abhängigkeiten funktionieren. **Kennzeichnung der Befehle** | Kennzeichnung | Bedeutung | |---|---| | `[RO]` | Nur lesender Befehl | | `[TEST]` | Führt eine aktive Prüfung aus | | `[PRIV]` | Erhöhte Berechtigungen erforderlich | | `[FILE]` | Liest Dateien, Images, Volumes oder Verzeichnisse | | `[SENS]` | Ausgabe kann sensible Informationen enthalten | | `[CHANGE]` | Verändert Konfiguration oder Systemzustand | | `[DISRUPT]` | Kann den Betrieb unterbrechen | ---
1. Fehlerbereich zuerst eindeutig bestimmen Virtualisierungsfehler müssen schichtweise eingegrenzt werden. ```text Anwendung │ Gastbetriebssystem oder Container │ Virtuelle Netzwerkkarte und virtueller Datenträger │ Hypervisor beziehungsweise Container-Engine │ Hostbetriebssystem │ Physisches Netzwerk und Storage │ Hardware ``` **Erste Prüffragen** - Ist nur eine Anwendung betroffen? - Ist das gesamte Gastbetriebssystem betroffen? - Sind mehrere VMs oder Container betroffen? - Befinden sich die betroffenen Systeme auf demselben Host? - Nutzen sie denselben virtuellen Switch? - Nutzen sie dasselbe Storage-System? - Trat der Fehler nach Migration, Neustart, Snapshot oder Update auf? - Ist die Managementoberfläche erreichbar? - Wird die VM beziehungsweise der Container als laufend angezeigt? - Ist ein Konsolenzugriff möglich? - Funktioniert die Kommunikation innerhalb des Gasts? - Sind Hostressourcen ausgeschöpft? - Wurde eine Konfiguration, ein Image oder ein Compose-Projekt verändert? **Erste Einordnung** | Beobachtung | Wahrscheinlicher Fehlerbereich | |---|---| | Nur ein Dienst in einer VM gestört | Anwendung oder Gastbetriebssystem | | Gesamte VM nicht erreichbar, Konsole funktioniert | Gastnetzwerk oder virtueller Switch | | Gesamte VM reagiert auch über Konsole nicht | Gast, Ressourcen oder virtueller Datenträger | | Mehrere VMs auf einem Host betroffen | Host, Hypervisor, Netzwerk oder Storage | | VMs auf mehreren Hosts betroffen | Gemeinsames Netzwerk, Cluster oder Storage | | Nur ein Container beendet sich | Anwendung, Image oder Containerkonfiguration | | Alle Container reagieren nicht | Container-Engine, Host oder gemeinsame Ressource | | Container läuft, veröffentlichter Port fehlt | Portfreigabe oder Netzwerkkonfiguration | | Daten fehlen nach Neuerstellung | Volume oder Bind-Mount nicht korrekt eingebunden |
2. VM, Container, Image und Host unterscheiden | Begriff | Bedeutung | |---|---| | Host | Physisches oder virtuelles System, das VMs oder Container ausführt | | Hypervisor | Virtualisierungsschicht für virtuelle Maschinen | | Virtuelle Maschine | Virtuelles Computersystem mit eigenem Betriebssystemkernel | | Gastbetriebssystem | Betriebssystem innerhalb einer VM | | Container-Engine | Verwaltet Images, Container, Netzwerke und Volumes | | Image | Unveränderliche Vorlage für einen Container | | Container | Laufende oder beendete Instanz eines Images | | Volume | Von der Containerlebensdauer getrennter persistenter Speicher | | Bind-Mount | Verzeichnis oder Datei des Hosts wird in den Container eingebunden | | Snapshot beziehungsweise Checkpoint | Zustandsaufnahme einer VM oder eines Datenträgers | | Virtueller Switch | Softwarebasierte Netzwerkverbindung für VMs | | Portveröffentlichung | Zuordnung eines Hostports zu einem Containerport | **Wichtige Unterschiede** - Ein VM-Snapshot ist keine unabhängige Datensicherung. - Ein Container-Image enthält normalerweise keine später erzeugten Nutzdaten. - Das Löschen eines Containers muss ein korrekt eingebundenes Volume nicht löschen. - Daten im beschreibbaren Container-Layer können beim Entfernen des Containers verloren gehen. - Ein `EXPOSE`-Eintrag im Image veröffentlicht keinen Hostport. - Ein laufender Container ist nicht automatisch eine funktionsfähige Anwendung. - Container teilen den Kernel des Hosts; VMs besitzen einen eigenen Gastkernel.
3. Hostzustand vor der Gastanalyse prüfen Bevor eine VM oder ein Container verändert wird, muss der Hostzustand kontrolliert werden. | Prüfbereich | Typische Auswirkung | |---|---| | CPU-Auslastung | VMs und Container reagieren langsam | | RAM-Auslastung | OOM-Ereignisse, Swapping oder VM-Startfehler | | Speicherplatz | Images, Snapshots und virtuelle Datenträger können nicht wachsen | | Inodes unter Linux | Containerdateien können nicht erstellt werden | | Storage-Latenz | VMs frieren ein oder Datenbanken werden langsam | | Netzwerk | Mehrere Gäste verlieren gleichzeitig die Verbindung | | Zeit | Authentifizierung, Zertifikate und Cluster können fehlschlagen | | Hypervisordienst | VMs können nicht verwaltet oder gestartet werden | | Container-Engine | Containerstatus und Netzwerke sind nicht verfügbar | **Windows-Host** ```powershell [RO] Get-CimInstance Win32_OperatingSystem | Select-Object Caption, Version, BuildNumber, FreePhysicalMemory, TotalVisibleMemorySize ``` ```powershell [RO] Get-Volume | Select-Object DriveLetter, FileSystemLabel, HealthStatus, SizeRemaining, Size ``` ```powershell [RO] Get-Counter ` '\Processor(_Total)\% Processor Time', '\Memory\Available MBytes' ``` **Linux-Host** ```bash [RO] uptime ``` ```bash [RO] free -h ``` ```bash [RO] df -hT ``` ```bash [RO] df -i ``` ```bash [RO] lsblk -f ``` ```bash [RO] vmstat 1 5 ``` **macOS-Host** ```bash [RO] uptime ``` ```bash [RO] vm_stat ``` ```bash [RO] df -h ``` ```bash [RO] diskutil list ```
4. Hyper-V-Host und virtuelle Maschinen prüfen Die Hyper-V-PowerShell-Befehle sind nur verfügbar, wenn die Hyper-V-Verwaltungstools installiert sind. **Hyper-V-Hostinformationen anzeigen** ```powershell [RO][PRIV] Get-VMHost | Select-Object Name, LogicalProcessorCount, MemoryCapacity, VirtualMachinePath, VirtualHardDiskPath ``` **Alle virtuellen Maschinen anzeigen** ```powershell [RO][PRIV] Get-VM | Select-Object Name, State, Status, CPUUsage, MemoryAssigned, Uptime, Version ``` **Bestimmte VM anzeigen** ```powershell [RO][PRIV] Get-VM -Name "" | Format-List * ``` Die vollständige Ausgabe kann sehr umfangreich sein. **Nur nicht normal laufende VMs anzeigen** ```powershell [RO][PRIV] Get-VM | Where-Object { $_.State -ne 'Running' -or $_.Status -ne 'Operating normally' } | Select-Object Name, State, Status ``` **Wichtige VM-Zustände** | Zustand | Bedeutung | |---|---| | `Running` | VM ist eingeschaltet | | `Off` | VM ist ausgeschaltet | | `Paused` | Ausführung wurde angehalten | | `Saved` | VM-Zustand wurde gespeichert | | `Starting` | VM wird gestartet | | `Stopping` | VM wird beendet | | `Saving` | Zustand wird gespeichert | | `Critical` im Status | Hyper-V meldet einen kritischen Zustand | > Ein Zustand `Running` sagt nichts darüber aus, ob das Gastbetriebssystem vollständig gestartet oder ein Dienst erreichbar ist.
5. Hyper-V-Arbeitsspeicher und CPU prüfen **VM-Arbeitsspeicher anzeigen** ```powershell [RO][PRIV] Get-VMMemory -VMName "" | Select-Object VMName, DynamicMemoryEnabled, Startup, Minimum, Maximum, Buffer, Priority ``` **Speicherzuweisung aller VMs anzeigen** ```powershell [RO][PRIV] Get-VM | Select-Object Name, State, @{Name='MemoryAssigned_GB';Expression={ [math]::Round($_.MemoryAssigned / 1GB, 2) }}, CPUUsage, Uptime ``` **Prozessorausweisung einer VM anzeigen** ```powershell [RO][PRIV] Get-VMProcessor -VMName "" | Select-Object VMName, Count, Reserve, Maximum, RelativeWeight, CompatibilityForMigrationEnabled ``` **Typische Ressourcenprobleme** - Der Host besitzt nicht genügend verfügbaren RAM zum Starten einer VM. - Zu viele virtuelle CPUs wurden vergeben. - Dynamischer Arbeitsspeicher erreicht sein Maximum. - Gastbetriebssystem oder Anwendung benötigt mehr Startspeicher. - Host führt gleichzeitig speicherintensive Sicherungs- oder Scanvorgänge aus. - Mehrere VMs konkurrieren um dieselben physischen Ressourcen. - NUMA- oder CPU-Kompatibilitätsanforderungen verhindern eine Migration. - Ein Gast verbraucht RAM, ohne ihn an den Host zurückzugeben. **Zusätzlich innerhalb der VM prüfen** Windows-Gast: ```powershell [RO] Get-Counter ` '\Processor(_Total)\% Processor Time', '\Memory\Available MBytes' ``` Linux-Gast: ```bash [RO] free -h ``` ```bash [RO] vmstat 1 5 ```
6. Hyper-V-Netzwerk untersuchen **Virtuelle Switches anzeigen** ```powershell [RO][PRIV] Get-VMSwitch | Select-Object Name, SwitchType, NetAdapterInterfaceDescription ``` **Virtuelle Netzwerkadapter einer VM anzeigen** ```powershell [RO][PRIV] Get-VMNetworkAdapter -VMName "" | Select-Object VMName, Name, SwitchName, Status, MacAddress, IPAddresses ``` **Alle VM-Netzwerkadapter anzeigen** ```powershell [RO][PRIV] Get-VMNetworkAdapter -All | Select-Object VMName, Name, SwitchName, Status, MacAddress, IPAddresses ``` **VLAN-Konfiguration anzeigen** ```powershell [RO][PRIV] Get-VMNetworkAdapterVlan -VMName "" ``` **Erweiterte Adapterfunktionen anzeigen** ```powershell [RO][PRIV] Get-VMNetworkAdapterAdvancedFeature ` -VMName "" ``` **Typische Ursachen** - VM ist mit dem falschen virtuellen Switch verbunden. - Switch wurde gelöscht oder umbenannt. - VLAN-ID stimmt nicht. - Physischer Hostadapter ist getrennt. - MAC-Adresse wird durch Port-Security blockiert. - Statische IP-Adresse im Gast ist falsch. - DHCP ist im virtuellen Netzwerk nicht erreichbar. - Eine Hostfirewall blockiert Management- oder Gastverkehr. - Virtueller Switch besitzt den falschen Typ. **Hyper-V-Switchtypen** | Typ | Verbindung | |---|---| | External | Verbindung zum physischen Netzwerk | | Internal | Kommunikation zwischen Host und VMs | | Private | Kommunikation nur zwischen VMs desselben Hosts |
7. Hyper-V-Datenträger und Checkpoints prüfen **Virtuelle Festplatten einer VM anzeigen** ```powershell [RO][PRIV] Get-VMHardDiskDrive -VMName "" | Select-Object VMName, ControllerType, ControllerNumber, ControllerLocation, Path ``` **Informationen über eine bekannte VHD- oder VHDX-Datei** ```powershell [RO][PRIV][SENS] Get-VHD -Path "" | Select-Object Path, VhdFormat, VhdType, FileSize, Size, MinimumSize, ParentPath, Attached ``` **Checkpoints einer VM anzeigen** ```powershell [RO][PRIV] Get-VMSnapshot -VMName "" | Select-Object VMName, Name, SnapshotType, CreationTime, ParentSnapshotName ``` **Checkpoints aller VMs anzeigen** ```powershell [RO][PRIV] Get-VM | Get-VMSnapshot | Select-Object VMName, Name, SnapshotType, CreationTime ``` **Speicherpfade und freien Speicher vergleichen** ```powershell [RO] Get-Volume | Select-Object DriveLetter, FileSystemLabel, HealthStatus, SizeRemaining, Size ``` **Typische Ursachen** - VHDX-Datei fehlt oder wurde verschoben. - Berechtigungen auf dem Speicherpfad fehlen. - Ein differenzierender Datenträger findet seinen Parent nicht. - Snapshot- beziehungsweise AVHDX-Dateien wachsen stark. - Das Hostvolume ist voll. - Ein Cluster Shared Volume ist nicht verfügbar. - SAN-, NAS- oder SMB-Speicher ist nicht erreichbar. - VHDX ist bereits anderweitig eingebunden. - Dateisystem oder physischer Datenträger meldet Fehler. > AVHDX-Dateien und Snapshotketten dürfen nicht manuell im Dateisystem gelöscht oder umbenannt werden. Dadurch kann die virtuelle Festplattenkette unbrauchbar werden.
8. Hyper-V-Integrationsdienste und Ereignisprotokolle prüfen **Integrationsdienste einer VM anzeigen** ```powershell [RO][PRIV] Get-VMIntegrationService -VMName "" | Select-Object Name, Enabled, PrimaryStatusDescription, SecondaryStatusDescription ``` **Hyper-V-VMMS-Ereignisse** ```powershell [RO][SENS] Get-WinEvent -LogName ` 'Microsoft-Windows-Hyper-V-VMMS-Admin' ` -ErrorAction SilentlyContinue | Select-Object -First 100 TimeCreated, LevelDisplayName, Id, Message ``` **Hyper-V-Worker-Ereignisse** ```powershell [RO][SENS] Get-WinEvent -LogName ` 'Microsoft-Windows-Hyper-V-Worker-Admin' ` -ErrorAction SilentlyContinue | Select-Object -First 100 TimeCreated, LevelDisplayName, Id, Message ``` **Nur Ereignisse der letzten 24 Stunden** ```powershell [RO][SENS] Get-WinEvent -FilterHashtable @{ LogName = 'Microsoft-Windows-Hyper-V-VMMS-Admin' StartTime = (Get-Date).AddHours(-24) } -ErrorAction SilentlyContinue | Select-Object TimeCreated, LevelDisplayName, Id, Message ``` **Typische Meldungsbereiche** - Startfehler - Arbeitsspeicher konnte nicht reserviert werden - Virtuelle Festplatte nicht gefunden - Zugriff auf Speicherpfad verweigert - Virtueller Switch nicht vorhanden - Checkpoint konnte nicht erstellt oder zusammengeführt werden - Migration fehlgeschlagen - Konfigurationsversion nicht unterstützt - Integrationsdienst nicht verfügbar
9. KVM und libvirt unter Linux prüfen **Alle libvirt-VMs anzeigen** ```bash [RO][PRIV] sudo virsh list --all ``` **Status einer VM** ```bash [RO][PRIV] sudo virsh domstate "" ``` **Ausführliche VM-Informationen** ```bash [RO][PRIV][SENS] sudo virsh dominfo "" ``` **Virtuelle Netzwerkadapter** ```bash [RO][PRIV][SENS] sudo virsh domiflist "" ``` **Virtuelle Datenträger** ```bash [RO][PRIV][SENS] sudo virsh domblklist "" --details ``` **VM-Ressourcenstatistik** ```bash [TEST][PRIV][SENS] sudo virsh domstats "" ``` **Snapshots anzeigen** ```bash [RO][PRIV] sudo virsh snapshot-list "" ``` **Virtuelle Netzwerke anzeigen** ```bash [RO][PRIV] sudo virsh net-list --all ``` **Storage-Pools anzeigen** ```bash [RO][PRIV] sudo virsh pool-list --all ``` **Storage-Volumes eines Pools anzeigen** ```bash [RO][PRIV][SENS] sudo virsh vol-list "" ``` > `virsh` kann je nach Verbindung auf eine lokale oder entfernte libvirt-Instanz zugreifen. Vor Änderungen muss geprüft werden, welche Verbindung und welcher Host tatsächlich verwendet werden.
10. KVM-, QEMU- und libvirt-Dienste untersuchen Je nach Distribution und libvirt-Version können unterschiedliche Dienste verwendet werden. **Klassischer libvirt-Dienst** ```bash [RO] systemctl status libvirtd --no-pager ``` **Modularer QEMU-Dienst** ```bash [RO] systemctl status virtqemud --no-pager ``` **Laufende QEMU-Prozesse anzeigen** ```bash [RO][SENS] ps -ef | grep '[q]emu-system' ``` **libvirt-Protokolle** ```bash [RO][PRIV][SENS] sudo journalctl -u libvirtd \ --since "-24 hours" --no-pager ``` **virtqemud-Protokolle** ```bash [RO][PRIV][SENS] sudo journalctl -u virtqemud \ --since "-24 hours" --no-pager ``` **Kernelunterstützung prüfen** ```bash [RO] lsmod | grep -E '^kvm|kvm_' ``` **CPU-Virtualisierungsmerkmale anzeigen** ```bash [RO] lscpu | grep -E 'Virtualization|Hypervisor|Architecture' ``` **KVM-Gerät prüfen** ```bash [RO][FILE] ls -l /dev/kvm ``` **Typische Ursachen** - Virtualisierung ist in BIOS beziehungsweise UEFI deaktiviert. - `/dev/kvm` fehlt oder besitzt falsche Berechtigungen. - libvirt-Dienst ist nicht aktiv. - VM-Konfiguration verweist auf fehlende Datenträger. - Storage-Pool ist nicht aktiv. - Virtuelles Netzwerk ist nicht aktiv. - AppArmor oder SELinux blockiert den Zugriff. - QEMU-Version unterstützt eine Geräteoption nicht. - CPU-Modell ist nach einer Migration nicht kompatibel. - Host besitzt nicht genügend RAM.
11. VMware und andere Hypervisoren systematisch eingrenzen Die genauen Befehle hängen von Produkt, Version und Managementplattform ab. Ohne bestätigte Plattform sollten keine produktspezifischen Befehle übernommen werden. **Zu prüfende Bereiche** - Hostverbindungsstatus - VM-Energiezustand - Hostressourcen - Datastore-Kapazität - Snapshotstatus - Virtuelle Switches und Portgruppen - VLAN-Zuordnung - Virtuelle Netzwerkkarten - Virtuelle Datenträger - VMware Tools beziehungsweise Gasterweiterungen - HA- und Clusterstatus - vMotion- beziehungsweise Migrationsereignisse - Alarme und Aufgabenverlauf - Lizenz- und Zertifikatsstatus - Managementserver-Verbindung **Typische Fehler** | Beobachtung | Mögliche Ursache | |---|---| | VM ist „orphaned“ oder „inaccessible“ | Konfigurationsdatei oder Datastore nicht erreichbar | | Snapshot kann nicht erstellt werden | Datastore voll oder Snapshotkette fehlerhaft | | Migration scheitert | CPU, Netzwerk, Storage oder Kompatibilität | | VM-Netzwerk fehlt | Portgruppe oder virtueller Switch falsch | | Konsole funktioniert, Netzwerk nicht | Gastnetzwerk, VLAN oder Portgruppe | | Mehrere Hosts nicht verwaltbar | Managementserver, Zertifikat oder Netzwerk | | HA startet VM nicht | Clusterkapazität, Admission Control oder Storage | | Tools-Status veraltet | Gasterweiterungen fehlen oder sind inkompatibel | > Änderungen an Datastore-Dateien dürfen nur mit dokumentierten Herstellerverfahren durchgeführt werden.
12. Docker-Client und Docker-Daemon unterscheiden Docker besteht mindestens aus: - Docker-Client - Docker-Daemon beziehungsweise Engine - Container Runtime - Images - Container - Netzwerke - Volumes Der Client kann installiert sein, obwohl der Daemon nicht erreichbar ist. **Client- und Serverversion anzeigen** ```bash [RO] docker version ``` Wenn nur der Clientbereich erscheint und der Serverbereich einen Fehler meldet, kann der Docker-Daemon nicht erreicht werden. **Ausführliche Docker-Informationen** ```bash [RO][SENS] docker info ``` Die Ausgabe kann enthalten: - Hostname - Betriebssystem - Kernelversion - Storage-Treiber - Anzahl der Container und Images - Netzwerk-Plugins - Registryinformationen - Sicherheitsoptionen - Docker-Root-Verzeichnis - Proxyinformationen **Docker-Kontext anzeigen** ```bash [RO][SENS] docker context show ``` **Alle Docker-Kontexte anzeigen** ```bash [RO][SENS] docker context ls ``` > Ein falscher Docker-Kontext kann dazu führen, dass Befehle gegen einen anderen Host oder Docker Desktop statt gegen die erwartete Engine ausgeführt werden.
13. Docker-Dienst unter Linux prüfen **Docker-Dienststatus** ```bash [RO] systemctl status docker --no-pager ``` **Container-Runtime prüfen** ```bash [RO] systemctl status containerd --no-pager ``` **Docker-Protokolle der letzten 24 Stunden** ```bash [RO][PRIV][SENS] sudo journalctl -u docker \ --since "-24 hours" --no-pager ``` **containerd-Protokolle** ```bash [RO][PRIV][SENS] sudo journalctl -u containerd \ --since "-24 hours" --no-pager ``` **Docker-Socket prüfen** ```bash [RO][FILE] ls -l /var/run/docker.sock ``` **Typische Fehlermeldungen** | Meldung | Mögliche Ursache | |---|---| | `Cannot connect to the Docker daemon` | Daemon gestoppt, falscher Socket oder falscher Kontext | | `permission denied` am Socket | Benutzer besitzt keine erforderliche Berechtigung | | `no space left on device` | Speicherplatz oder Inodes ausgeschöpft | | `address already in use` | Hostport bereits belegt | | `network not found` | Konfiguriertes Docker-Netzwerk fehlt | | `volume not found` | Extern erwartetes Volume fehlt | | `manifest unknown` | Image oder Tag existiert nicht | | `no matching manifest` | Architektur oder Plattform wird nicht angeboten | | `pull access denied` | Registry, Anmeldung oder Berechtigung | | `toomanyrequests` | Registry-Limit erreicht |
14. Containerstatus und Exit-Code prüfen **Laufende Container anzeigen** ```bash [RO][SENS] docker ps ``` **Alle Container einschließlich beendeter Container** ```bash [RO][SENS] docker ps -a ``` **Kompakte Zustandsübersicht** ```bash [RO][SENS] docker ps -a \ --format 'table {{.Names}}\t{{.Image}}\t{{.Status}}\t{{.Ports}}' ``` **Zustand eines Containers detailliert anzeigen** ```bash [RO][SENS] docker inspect "" \ --format '{{json .State}}' ``` **Wichtige Zustandsinformationen gezielt anzeigen** ```bash [RO][SENS] docker inspect "" \ --format 'Status={{.State.Status}} ExitCode={{.State.ExitCode}} OOMKilled={{.State.OOMKilled}} Error={{.State.Error}} StartedAt={{.State.StartedAt}} FinishedAt={{.State.FinishedAt}}' ``` **Neustartzähler anzeigen** ```bash [RO] docker inspect "" \ --format 'RestartCount={{.RestartCount}}' ``` **Typische Exit-Codes** | Exit-Code | Typische Bedeutung | |---|---| | `0` | Prozess wurde erfolgreich beendet | | `1` | Allgemeiner Anwendungsfehler | | `2` | Häufig falsche Argumente oder Anwendungsfehler | | `125` | Docker konnte den Container nicht starten | | `126` | Befehl gefunden, aber nicht ausführbar | | `127` | Befehl nicht gefunden | | `137` | Prozess erhielt häufig `SIGKILL`; OOM oder erzwungenes Beenden möglich | | `139` | Segmentation Fault möglich | | `143` | Prozess erhielt normalerweise `SIGTERM` | > Ein Exit-Code beschreibt zunächst nur das Ende des Hauptprozesses. Die genaue Ursache muss mit Containerprotokoll, Docker-Ereignissen und Hostmeldungen bestätigt werden.
15. Containerprotokolle sicher auswerten **Letzte 100 Protokollzeilen** ```bash [RO][SENS] docker logs --tail 100 "" ``` **Protokolle mit Zeitstempeln** ```bash [RO][SENS] docker logs --timestamps --tail 100 "" ``` **Protokolle seit einem bestimmten Zeitraum** ```bash [RO][SENS] docker logs --since 1h "" ``` **Protokolle fortlaufend beobachten** ```bash [TEST][SENS] docker logs --follow --tail 100 "" ``` Die fortlaufende Ausgabe wird mit `Strg` + `C` beendet. Dadurch wird normalerweise nicht der Container beendet, sondern nur die lokale Anzeige. **Wichtige Einschränkungen** - `docker logs` funktioniert abhängig vom verwendeten Logging-Treiber. - Anwendungen können zusätzlich in Dateien, Datenbanken oder externe Systeme protokollieren. - Protokolle können Passwörter, Tokens, URLs, Benutzernamen oder personenbezogene Daten enthalten. - Unbegrenzte Logabfragen können sehr große Datenmengen ausgeben. - Fehlende Ausgabe bedeutet nicht automatisch, dass kein Fehler vorhanden ist. - Ein Container kann bereits vor Initialisierung der Anwendungsprotokollierung beendet werden.
16. Healthcheck und Anwendungszustand prüfen Ein Docker-Healthcheck bewertet einen im Image oder Container definierten Test. **Healthcheckstatus anzeigen** ```bash [RO][SENS] docker inspect "" \ --format '{{json .State.Health}}' ``` **Kompakte Anzeige** ```bash [RO][SENS] docker inspect "" \ --format 'Status={{.State.Status}} Health={{if .State.Health}}{{.State.Health.Status}}{{else}}nicht definiert{{end}}' ``` **Healthcheck-Konfiguration anzeigen** ```bash [RO][SENS] docker inspect "" \ --format '{{json .Config.Healthcheck}}' ``` **Mögliche Health-Zustände** | Zustand | Bedeutung | |---|---| | `starting` | Startphase oder noch nicht genügend Prüfungen | | `healthy` | Definierter Test war erfolgreich | | `unhealthy` | Definierter Test ist wiederholt fehlgeschlagen | | Nicht vorhanden | Kein Docker-Healthcheck definiert | **Wichtige Bewertung** - `healthy` bestätigt nur den definierten Test. - Ein zu einfacher Test kann echte Fehler übersehen. - Ein zu strenger Test kann einen funktionierenden Dienst als fehlerhaft markieren. - Der Test kann von Werkzeugen abhängen, die im Image fehlen. - Ein Healthcheck kann intern funktionieren, obwohl der Dienst extern nicht erreichbar ist. - Ein Container kann `Up` sein und trotzdem `unhealthy`.
17. Containerressourcen und OOM-Fehler untersuchen **Aktuelle Ressourcennutzung einmalig anzeigen** ```bash [TEST][SENS] docker stats --no-stream ``` **Nur einen Container anzeigen** ```bash [TEST][SENS] docker stats --no-stream "" ``` **Konfigurierte Ressourcenlimits anzeigen** ```bash [RO][SENS] docker inspect "" \ --format 'Memory={{.HostConfig.Memory}} MemorySwap={{.HostConfig.MemorySwap}} NanoCPUs={{.HostConfig.NanoCpus}} PidsLimit={{.HostConfig.PidsLimit}}' ``` **Prüfen, ob der Container wegen Speichermangel beendet wurde** ```bash [RO] docker inspect "" \ --format 'OOMKilled={{.State.OOMKilled}} ExitCode={{.State.ExitCode}}' ``` **Linux-Kernelmeldungen zu OOM** ```bash [RO][PRIV][SENS] sudo journalctl -k -b --no-pager | grep -Ei 'out of memory|oom-kill|killed process' ``` **Typische Ursachen** - Container besitzt ein zu niedriges Speicherlimit. - Host besitzt keinen freien Arbeitsspeicher. - Anwendung besitzt ein Speicherleck. - Java-, Node.js- oder Datenbankkonfiguration ignoriert die Containergrenze. - Zu viele Prozesse erreichen das PID-Limit. - Hohe I/O-Wartezeit wird als CPU- oder Anwendungsproblem fehlinterpretiert. - Ein Container konkurriert ohne Limits mit anderen Workloads. > Ein höheres Speicherlimit behebt kein Speicherleck. Zuerst müssen Verbrauch, Wachstum und Anwendungsprotokolle untersucht werden.
18. Docker-Prozesse und Hauptprozess prüfen **Prozesse im Container anzeigen** ```bash [RO][SENS] docker top "" ``` **Konfigurierten Startbefehl anzeigen** ```bash [RO][SENS] docker inspect "" \ --format 'Entrypoint={{json .Config.Entrypoint}} Cmd={{json .Config.Cmd}}' ``` **Arbeitsverzeichnis und Benutzer anzeigen** ```bash [RO][SENS] docker inspect "" \ --format 'User={{.Config.User}} WorkingDir={{.Config.WorkingDir}}' ``` **Typische Ursachen eines sofortigen Containerendes** - Hauptprozess beendet sich regulär. - Startbefehl oder Entrypoint ist falsch. - Binärdatei oder Skript fehlt. - Datei besitzt keine Ausführungsberechtigung. - Konfigurationsdatei fehlt. - Umgebungsvariable ist nicht gesetzt. - Abhängiger Dienst ist noch nicht erreichbar. - Datenbankmigration schlägt fehl. - Architektur des Images passt nicht zum Host. - Anwendung läuft als falscher Benutzer. - Gemountete Datei verdeckt eine Datei aus dem Image. > Ein Container bleibt nur so lange aktiv, wie sein Hauptprozess läuft. Das erfolgreiche Erstellen des Containers bedeutet nicht, dass dieser Prozess dauerhaft läuft.
19. Docker-Portveröffentlichungen und Listener prüfen **Portzuordnungen aller Container** ```bash [RO][SENS] docker ps \ --format 'table {{.Names}}\t{{.Ports}}' ``` **Portzuordnung eines Containers** ```bash [RO][SENS] docker port "" ``` **Detaillierte Portkonfiguration** ```bash [RO][SENS] docker inspect "" \ --format '{{json .NetworkSettings.Ports}}' ``` **Listener auf dem Linux-Host** ```bash [RO][PRIV][SENS] sudo ss -lntup ``` **Listener auf Windows** ```powershell [RO][PRIV][SENS] Get-NetTCPConnection -State Listen | Sort-Object LocalPort | Select-Object LocalAddress, LocalPort, OwningProcess ``` **Listener auf macOS** ```bash [RO][PRIV][SENS] sudo lsof -nP -iTCP -sTCP:LISTEN ``` **Wichtige Unterscheidung** ```text Client │ ▼ Host-IP:Hostport │ Portveröffentlichung ▼ Container-IP:Containerport │ ▼ Anwendungslistener ``` Ein Fehler kann an jeder Stelle liegen. **Typische Ursachen** - Kein Hostport wurde veröffentlicht. - Falscher Containerport wurde eingetragen. - Anwendung lauscht auf einem anderen Port. - Anwendung bindet nur an `127.0.0.1` im Container. - Hostport wird bereits verwendet. - Hostfirewall blockiert den Port. - Reverse Proxy zeigt auf den falschen Hostnamen oder Port. - Anwendung startet erst nach längerer Initialisierung. - IPv4- und IPv6-Bindung werden verwechselt.
20. Docker-Netzwerke und DNS untersuchen **Docker-Netzwerke anzeigen** ```bash [RO][SENS] docker network ls ``` **Netzwerkdetails anzeigen** ```bash [RO][SENS] docker network inspect "" ``` Die Ausgabe kann Container-IP-Adressen, Netzwerknamen und weitere interne Informationen enthalten. **Netzwerke eines Containers anzeigen** ```bash [RO][SENS] docker inspect "" \ --format '{{json .NetworkSettings.Networks}}' ``` **DNS-Konfiguration im Container anzeigen** ```bash [RO][SENS] docker exec "" cat /etc/resolv.conf ``` Der Befehl funktioniert nur, wenn der Container läuft und `cat` im Image vorhanden ist. **Namensauflösung im Container testen** ```bash [TEST][SENS] docker exec "" \ getent hosts "" ``` `getent` ist nicht in jedem Container-Image vorhanden. **TCP-Verbindung aus einem Container testen** ```bash [TEST][SENS] docker exec "" \ curl -v --connect-timeout 5 "http://:/" ``` `curl` ist nicht in jedem Image installiert. Fehlende Diagnosewerkzeuge dürfen nicht unkontrolliert in einen Produktivcontainer installiert werden. **Typische Ursachen** - Container befinden sich in unterschiedlichen Netzwerken. - Falscher DNS-Name wird verwendet. - Dienstname stimmt nicht mit Compose-Konfiguration überein. - Anwendung nutzt `localhost` für einen anderen Container. - Netzwerk wurde nach Containererstellung geändert. - DNS-Server des Hosts ist nicht erreichbar. - Überschneidende IP-Netze verursachen falsche Routen. - VPN kollidiert mit dem Docker-Adressbereich. - Firewall oder Forwardingregel blockiert den Verkehr. > `localhost` innerhalb eines Containers bezeichnet normalerweise den Container selbst und nicht den Docker-Host oder einen anderen Container.
21. Docker-Volumes und Bind-Mounts untersuchen **Volumes anzeigen** ```bash [RO][SENS] docker volume ls ``` **Volumeinformationen anzeigen** ```bash [RO][SENS] docker volume inspect "" ``` **Mounts eines Containers anzeigen** ```bash [RO][SENS] docker inspect "" \ --format '{{json .Mounts}}' ``` **Kompakte Mountübersicht** ```bash [RO][SENS] docker inspect "" \ --format '{{range .Mounts}}{{println .Type .Source "->" .Destination "RW=" .RW}}{{end}}' ``` **Speicherverbrauch der Docker-Objekte** ```bash [TEST][SENS] docker system df ``` Ausführlich: ```bash [TEST][SENS] docker system df -v ``` **Typische Ursachen fehlender Daten** - Falsches Volume wurde eingebunden. - Volume wurde unter einem neuen Projektnamen erstellt. - Bind-Mount verweist auf einen falschen Hostpfad. - Ein leerer Hostpfad verdeckt vorhandene Image-Daten. - Anwendung schreibt außerhalb des vorgesehenen Mountpoints. - Container läuft als Benutzer ohne Schreibberechtigung. - Volume wurde versehentlich entfernt. - NFS-, SMB- oder Netzwerkspeicher ist nicht verfügbar. - SELinux verhindert den Zugriff. - Datenträger des Docker-Hosts ist voll. - Bei Docker Desktop wurde die Dateifreigabe oder virtuelle Storage-Schicht gestört. > `docker volume prune` und `docker system prune` dürfen nicht als allgemeine Fehlerbehebung ausgeführt werden. Sie können nicht verwendete, aber weiterhin benötigte Daten oder Images entfernen.
22. Docker-Images und Architektur prüfen **Lokale Images anzeigen** ```bash [RO][SENS] docker image ls ``` **Imageinformationen anzeigen** ```bash [RO][SENS] docker image inspect ":" ``` **Architektur eines lokalen Images** ```bash [RO] docker image inspect ":" \ --format 'OS={{.Os}} Architecture={{.Architecture}}' ``` **Hostarchitektur** Linux: ```bash [RO] uname -m ``` macOS: ```bash [RO] uname -m ``` Windows: ```powershell [RO] Get-CimInstance Win32_OperatingSystem | Select-Object OSArchitecture ``` **Typische Fehlermeldungen** | Meldung | Mögliche Ursache | |---|---| | `no matching manifest` | Image unterstützt die Hostplattform nicht | | `exec format error` | Binärdatei besitzt falsche Architektur oder fehlerhaften Interpreter | | `manifest unknown` | Tag oder Image existiert nicht | | `pull access denied` | Privates Image oder falscher Name | | `unauthorized` | Registryanmeldung oder Berechtigung fehlt | | `certificate signed by unknown authority` | Registryzertifikat wird nicht vertraut | | `unexpected EOF` | Download oder Netzwerkverbindung abgebrochen | **Multi-Architektur-Images** Ein Image-Tag kann verschiedene plattformspezifische Manifestvarianten enthalten. Deshalb muss geprüft werden, ob genau die benötigte Kombination aus Betriebssystem und Architektur angeboten wird.
23. Umgebungsvariablen und Geheimnisse prüfen **Konfigurierte Containerumgebung anzeigen** ```bash [RO][SENS] docker inspect "" \ --format '{{range .Config.Env}}{{println .}}{{end}}' ``` > Diese Ausgabe kann Passwörter, Tokens, API-Schlüssel und Datenbankzugänge enthalten. Sie darf nicht unredigiert in Tickets, Dokumentationen oder externe Systeme kopiert werden. **Nur Namen der Umgebungsvariablen anzeigen** ```bash [RO][SENS] docker inspect "" \ --format '{{range .Config.Env}}{{println .}}{{end}}' | sed 's/=.*$/=/' ``` **Typische Fehler** - Pflichtvariable fehlt. - Variablenname ist falsch geschrieben. - Wert enthält unbeabsichtigte Leerzeichen. - Sonderzeichen wurden durch Shell oder Compose interpretiert. - Datenbankhostname zeigt auf `localhost`. - Portnummer ist falsch. - Geheimnis wurde rotiert, Container aber nicht neu erstellt. - `.env`-Datei wurde aus einem anderen Verzeichnis geladen. - Compose-Projekt verwendet eine andere Konfigurationsdatei. - Variable ist im Image festgelegt und wird unerwartet überschrieben. **Sicherheitsregel** Geheimnisse sollten nicht dauerhaft als Klartext in: - Screenshots - Tickets - BookStack-Seiten - Chatverläufen - öffentlichen Repositories - ungeschützten Diagnoseberichten gespeichert werden.
24. Docker-Compose-Projekte untersuchen Je nach Installation wird das aktuelle Plugin mit `docker compose` verwendet. Ältere Systeme können noch das separate Werkzeug `docker-compose` besitzen. **Projektstatus anzeigen** ```bash [RO][SENS] docker compose ps -a ``` **Compose-Prozesse anzeigen** ```bash [RO][SENS] docker compose top ``` **Letzte Protokollzeilen aller Dienste** ```bash [RO][SENS] docker compose logs --tail 100 ``` **Protokoll eines Dienstes** ```bash [RO][SENS] docker compose logs --tail 100 "" ``` **Zusammengeführte Konfiguration prüfen** ```bash [RO][SENS] docker compose config ``` > `docker compose config` kann aufgelöste Umgebungsvariablen und sensible Werte enthalten. Die Ausgabe muss vor Weitergabe redigiert werden. **Dienste der Konfiguration anzeigen** ```bash [RO] docker compose config --services ``` **Images der Konfiguration anzeigen** ```bash [RO][SENS] docker compose config --images ``` **Typische Compose-Fehler** - Befehl wird im falschen Verzeichnis ausgeführt. - Falsche Compose-Datei wird verwendet. - Projektname hat sich geändert. - Externes Netzwerk oder Volume fehlt. - `.env`-Datei fehlt. - Variable wurde nicht ersetzt. - Abhängiger Dienst ist gestartet, aber noch nicht betriebsbereit. - Port ist bereits belegt. - Bind-Mount-Pfad existiert auf dem Host nicht. - Image-Tag zeigt inzwischen auf eine andere Version. - Mehrere Compose-Dateien überschreiben sich unerwartet.
25. Docker-Ereignisse und Neustartschleifen untersuchen **Ereignisse der letzten Stunde** ```bash [RO][SENS] docker events --since 1h ``` Der Befehl wartet nach Ausgabe vorhandener Ereignisse auf neue Ereignisse und wird mit `Strg` + `C` beendet. **Ereignisse eines Containers** ```bash [RO][SENS] docker events \ --since 1h \ --filter container="" ``` **Nur bestimmte Ereignistypen** ```bash [RO][SENS] docker events \ --since 1h \ --filter container="" \ --filter event=die ``` **Neustartrichtlinie anzeigen** ```bash [RO] docker inspect "" \ --format '{{json .HostConfig.RestartPolicy}}' ``` **Typische Neustartrichtlinien** | Richtlinie | Verhalten | |---|---| | `no` | Kein automatischer Neustart | | `always` | Container wird grundsätzlich neu gestartet | | `unless-stopped` | Neustart, außer er wurde ausdrücklich beendet | | `on-failure` | Neustart bei fehlerhaftem Exit-Code | Eine Neustartrichtlinie kann die eigentliche Störung verdecken. Der Container erscheint wiederholt kurz als laufend, obwohl der Hauptprozess ständig abstürzt. **Prüfreihenfolge bei Neustartschleifen** 1. Neustartzähler erfassen. 2. Exit-Code und OOM-Status prüfen. 3. Protokolle mit Zeitstempeln lesen. 4. Startbefehl und Umgebungsvariablen kontrollieren. 5. Mounts und Berechtigungen prüfen. 6. Abhängige Dienste untersuchen. 7. Hostereignisse und Speicherzustand prüfen. 8. Erst danach über Änderungen an der Neustartrichtlinie entscheiden.
26. Docker Desktop unter Windows und macOS eingrenzen Docker Desktop führt Linux-Container normalerweise innerhalb einer verwalteten Virtualisierungsumgebung aus. Dadurch existieren zusätzliche Schichten: ```text Docker-Client │ Docker Desktop │ Verwaltete Linux-VM beziehungsweise Virtualisierungsschicht │ Docker Engine │ Container ``` **Plattformübergreifende Prüfungen** ```bash [RO] docker version ``` ```bash [RO][SENS] docker info ``` ```bash [RO][SENS] docker context ls ``` ```bash [RO][SENS] docker ps -a ``` ```bash [TEST][SENS] docker system df ``` **Zusätzlich unter Windows prüfen** - Läuft Docker Desktop? - Wird der erwartete Docker-Kontext verwendet? - Funktioniert WSL 2, falls dieses Backend verwendet wird? - Besitzt die virtuelle Docker-Festplatte freien Speicher? - Sind Unternehmensrichtlinien oder Sicherheitssoftware beteiligt? **WSL-Status anzeigen** ```powershell [RO] wsl --status ``` **WSL-Distributionen anzeigen** ```powershell [RO][SENS] wsl --list --verbose ``` **Zusätzlich unter macOS prüfen** - Läuft Docker Desktop? - Ist genügend freier Speicher auf dem Mac vorhanden? - Wird der erwartete Kontext verwendet? - Passt das Image zu `arm64` oder `amd64`? - Sind Bind-Mount-Pfade verfügbar? - Blockiert eine Sicherheits- oder Netzwerksoftware die Verbindung? - Ist die virtuelle Docker-Disk ausgelastet? > Das Beenden oder Zurücksetzen von Docker Desktop kann alle laufenden Container unterbrechen. Ein Factory Reset kann lokale Images, Container, Netzwerke und andere Daten entfernen und darf nicht als allgemeine Diagnosemaßnahme verwendet werden.
27. Podman-Container unter Linux untersuchen Podman besitzt viele Docker-ähnliche Befehle, verwendet aber kein identisches Betriebsmodell. Rootless- und Rootful-Container besitzen getrennte Ansichten. **Container anzeigen** ```bash [RO][SENS] podman ps -a ``` **Podman-Systeminformationen** ```bash [RO][SENS] podman info ``` **Containerdetails** ```bash [RO][SENS] podman inspect "" ``` **Protokolle** ```bash [RO][SENS] podman logs --tail 100 "" ``` **Ressourcennutzung** ```bash [TEST][SENS] podman stats --no-stream ``` **Netzwerke** ```bash [RO][SENS] podman network ls ``` **Volumes** ```bash [RO][SENS] podman volume ls ``` **Speicherverbrauch** ```bash [TEST][SENS] podman system df ``` **Wichtige Besonderheit** Ein Container, der als normaler Benutzer erstellt wurde, erscheint normalerweise nicht automatisch in der Root-Ansicht: ```bash [RO][SENS] podman ps -a ``` und: ```bash [RO][PRIV][SENS] sudo podman ps -a ``` können deshalb unterschiedliche Container anzeigen.
28. Snapshots, Checkpoints und Sicherungen richtig bewerten Snapshots und Checkpoints speichern abhängig von der Plattform: - Datenträgeränderungen - VM-Konfiguration - gegebenenfalls Arbeitsspeicherzustand - Abhängigkeiten zu Parent-Dateien Sie sind für kurzfristige Rückfallpunkte geeignet, ersetzen aber keine unabhängige Sicherung. **Risiken lang bestehender Snapshots** - Stark wachsender Speicherverbrauch - Zusätzliche I/O-Latenz - Lange Zusammenführung - Komplexe Snapshotketten - Ausfall bei fehlender Parent-Datei - Datastore oder Hostvolume läuft voll - Anwendungskonsistenz ist nicht garantiert - Sicherungssoftware wird beeinträchtigt **Vor einer Snapshotaktion prüfen** - Wer hat den Snapshot erstellt? - Warum wurde er erstellt? - Wie alt ist er? - Wie groß ist er? - Wird er von einer Sicherung verwendet? - Ist eine Zusammenführung aktiv? - Ist genügend Speicher für die Zusammenführung vorhanden? - Ist die Anwendung im Snapshot konsistent? - Existiert eine unabhängige Sicherung? > Snapshotdateien niemals manuell löschen. Erstellung, Zusammenführung und Entfernung müssen über das vorgesehene Managementwerkzeug erfolgen.
29. Zeitfehler in virtuellen Systemen untersuchen Eine VM kann Zeit aus mehreren Quellen erhalten: - Hypervisor - virtuelle Hardwareuhr - Gastbetriebssystem-Zeitdienst - Active Directory - externer NTP-Server **Windows-Gast** ```cmd [RO] w32tm /query /source ``` ```cmd [RO] w32tm /query /status ``` **Linux-Gast** ```bash [RO] timedatectl status ``` ```bash [RO] chronyc tracking ``` falls chrony verwendet wird. **Typische Ursachen** - Hypervisor und NTP korrigieren gleichzeitig. - Hostzeit ist falsch. - VM wurde aus einem alten Snapshot gestartet. - VM war lange pausiert. - Migration verursachte einen Zeitsprung. - Virtueller Domänencontroller verwendet eine falsche Quelle. - Gasterweiterungen setzen die Zeit zurück. Bei Authentifizierungs-, Zertifikats- und Protokollproblemen sollte die Zeit frühzeitig geprüft werden.
30. Kritische Änderungen und gefährliche Schnelllösungen Folgende Maßnahmen dürfen nicht unkontrolliert durchgeführt werden: | Maßnahme | Risiko | |---|---| | VM hart ausschalten | Datenverlust und Dateisystemfehler | | Container mit `kill` beenden | Anwendung erhält keine reguläre Beendigungszeit | | Docker Factory Reset | Verlust lokaler Docker-Daten | | `docker system prune` | Entfernt nicht verwendete Docker-Objekte | | `docker volume prune` | Kann persistente Daten entfernen | | Snapshotdateien manuell löschen | Virtuelle Datenträgerkette kann unbrauchbar werden | | VHDX oder QCOW2 während des Betriebs kopieren | Kopie kann inkonsistent sein | | VM auf Snapshot zurücksetzen | Neuere Daten und Zustände gehen verloren | | Hypervisordienst neu starten | Mehrere VMs können betroffen sein | | Netzwerkbrücke oder Switch neu erstellen | Alle verbundenen Gäste können getrennt werden | | Storage aushängen | VMs und Container verlieren Datenträgerzugriff | | Rechte auf Docker-Socket weit öffnen | Praktisch administrative Kontrolle über den Host | | Secrets unredigiert exportieren | Zugangsdaten werden offengelegt | **Vor einer Änderung erforderlich** - Exakter Zielhost - Exakte VM beziehungsweise exakter Container - Aktueller Zustand - Abhängige Dienste - Sicherung - Wartungsfenster - Rückfallplan - Verantwortliche Freigabe - Funktionsprüfung nach der Änderung
31. Sichere Reihenfolge der Fehleranalyse 1. Betroffene Anwendung, VM oder Container eindeutig bestimmen. 2. Umfang der Störung feststellen. 3. Host, Hypervisor und Managementzugang prüfen. 4. Hostressourcen und Speicherplatz kontrollieren. 5. VM- beziehungsweise Containerstatus und Startzeit erfassen. 6. Exit-Code, Healthcheck und Ereignisse prüfen. 7. Protokolle zum Fehlerzeitpunkt auswerten. 8. Virtuelles Netzwerk und Portzuordnung untersuchen. 9. Virtuelle Datenträger, Volumes und Mounts kontrollieren. 10. Abhängige Dienste und Namensauflösung prüfen. 11. Ressourcenlimits und OOM-Ereignisse untersuchen. 12. Image-, Versions- und Architekturkompatibilität prüfen. 13. Snapshot-, Migrations- und Änderungsverlauf berücksichtigen. 14. Sicherung und Rückfallplan verifizieren. 15. Erst danach eine Änderung oder einen kontrollierten Neustart durchführen. 16. Anwendung aus interner und externer Sicht testen. 17. Host, VM, Container und Monitoring erneut kontrollieren. 18. Ursache und Maßnahme dokumentieren.
32. Schnelle Befehlsübersicht | Aufgabe | Hyper-V | KVM/libvirt | Docker auf Windows, Linux und macOS | |---|---|---|---| | Hostinformationen | `[RO][PRIV] Get-VMHost` | Hostbefehle wie `free`, `df`, `uptime` | `[RO][SENS] docker info` | | Alle Gäste | `[RO][PRIV] Get-VM` | `[RO][PRIV] sudo virsh list --all` | `[RO][SENS] docker ps -a` | | Gaststatus | `[RO][PRIV] Get-VM -Name ""` | `[RO][PRIV] sudo virsh domstate ""` | `[RO] docker inspect "" --format '{{json .State}}'` | | Ressourcen | VM-, Host- und Performance-Counter | `[TEST][PRIV] sudo virsh domstats ""` | `[TEST] docker stats --no-stream` | | Netzwerke | `[RO][PRIV] Get-VMSwitch` | `[RO][PRIV] sudo virsh net-list --all` | `[RO] docker network ls` | | Gastnetzadapter | `[RO][PRIV] Get-VMNetworkAdapter -VMName ""` | `[RO][PRIV] sudo virsh domiflist ""` | `[RO] docker inspect "" --format '{{json .NetworkSettings.Networks}}'` | | Datenträger | `[RO][PRIV] Get-VMHardDiskDrive -VMName ""` | `[RO][PRIV] sudo virsh domblklist "" --details` | `[RO] docker inspect "" --format '{{json .Mounts}}'` | | Snapshots | `[RO][PRIV] Get-VMSnapshot -VMName ""` | `[RO][PRIV] sudo virsh snapshot-list ""` | Nicht direkt vergleichbar | | Protokolle | Hyper-V-Ereignisprotokolle | Journal und VM-Protokolle | `[RO][SENS] docker logs --tail 100 ""` | | Ereignisse | Windows-Ereignisanzeige | Journal | `[RO][SENS] docker events --since 1h` | | Ports | Gast und virtuellen Switch prüfen | Gast und Bridge prüfen | `[RO] docker port ""` | | Volumes | VHD/VHDX und Hostvolume | Storage-Pools und Volumes | `[RO] docker volume ls` | | Speicherverbrauch | Hostvolume und VHDX-Größe | `df`, Pools und Images | `[TEST] docker system df -v` | | Architektur | Host- und Gastarchitektur | `[RO] uname -m` | `docker image inspect ... --format '{{.Architecture}}'` | | Healthcheck | Gast- beziehungsweise anwendungsspezifisch | Gast- beziehungsweise anwendungsspezifisch | `docker inspect ... --format '{{json .State.Health}}'` |
33. Entscheidungsmatrix | Befund | Wahrscheinliche Ursache | Nächster Schritt | |---|---|---| | VM läuft, Konsole funktioniert, Netzwerk nicht | Gastnetzwerk, Switch oder VLAN | Virtuelle und interne Netzwerkkonfiguration prüfen | | VM startet nicht, Host-RAM knapp | Ressourcenproblem | Host- und VM-Speicherzuweisung prüfen | | Mehrere VMs frieren ein | Host oder gemeinsames Storage | Hostlast und Storage-Latenz prüfen | | Snapshot wächst stark | Viele Schreibänderungen oder alter Snapshot | Zweck, Größe und Zusammenführung planen | | Container endet mit Code 127 | Startbefehl nicht gefunden | Entrypoint, Cmd und Image prüfen | | Container endet mit Code 137 | OOM oder erzwungenes Beenden möglich | OOM-Status und Hostprotokolle prüfen | | Container läuft, Anwendung nicht erreichbar | Listener, Port oder Healthcheck | Containerlistener und Portzuordnung prüfen | | Port kann nicht gebunden werden | Hostport bereits belegt | Hostlistener und Compose-Konfiguration prüfen | | Container findet Datenbank nicht | DNS, Netzwerk oder Hostname | Gemeinsames Netzwerk und Dienstnamen prüfen | | Daten nach Neuerstellung weg | Fehlendes oder falsches Volume | Mountkonfiguration und vorhandene Volumes prüfen | | Image startet auf ARM nicht | Plattform nicht unterstützt | Imagearchitektur und Manifest prüfen | | Docker-Client findet Daemon nicht | Dienst, Socket oder Kontext | `docker version`, Dienst und Kontext prüfen | | Nur Root sieht Podman-Container | Rootful- und Rootless-Ansicht | Richtigen Benutzerkontext verwenden | | Host hat Platz, Docker meldet voll | Docker-Disk, Inodes oder Storage-Layer | `docker system df`, `df` und Inodes prüfen | | Nach Snapshot stimmen Anmeldungen nicht | Zeitabweichung | Gastzeit und Zeitquelle prüfen |
34. Dokumentationsvorlage ```text Ticket: Datum und Uhrzeit: Bearbeiter: Betroffene Plattform: Hypervisor oder Container-Engine: Version: Host: Hostbetriebssystem: Physischer oder virtueller Host: Cluster: Managementsystem: Betroffene VM oder Container: VM- beziehungsweise Container-ID: Image und Tag: Gastbetriebssystem: Architektur: Aktueller Zustand: Startzeit: Uptime: Exit-Code: Healthcheck: Neustartzähler: Umfang der Störung: Originale Fehlermeldung: Fehlerzeitpunkt: Letzte funktionierende Nutzung: Letzte Änderung: Update, Snapshot oder Migration: Host-CPU: Host-RAM: Hostspeicher: Inode-Belegung: Storage-Zustand: Virtueller Datenträger: Snapshots oder Checkpoints: Virtueller Switch oder Netzwerk: VLAN: IP-Adresse: DNS: Portveröffentlichung: Hostlistener: Containerlistener: Firewall: Volumes und Mounts: Berechtigungen: Umgebungsvariablen geprüft: Sensible Werte redigiert: Abhängige Dienste: Zeitquelle: Relevante Hostprotokolle: Hypervisorprotokolle: Gastprotokolle: Containerprotokolle: OOM-Ereignisse: Vermutete Ursache: Durchgeführte Tests: Sicherung geprüft: Wartungsfenster: Durchgeführte Änderung: Rückfallplan: Status nach der Maßnahme: Interne Funktionsprüfung: Externe Funktionsprüfung: Monitoring: Weiterführende Maßnahmen: ```
--- **Merksatz** > Bei Virtualisierungs- und Containerfehlern wird immer von außen nach innen geprüft: Host, Virtualisierungsschicht, Netzwerk und Storage, Gast beziehungsweise Container und erst danach die Anwendung. Ein Status `Running` oder `Up` ist noch kein Funktionsnachweis. **Quellen und weiterführende Dokumentation** - [Microsoft Learn – Hyper-V mit PowerShell verwalten](https://learn.microsoft.com/windows-server/virtualization/hyper-v/powershell) - [Microsoft Learn – Hyper-V-PowerShell-Referenz](https://learn.microsoft.com/powershell/module/hyper-v/) - [Microsoft Learn – Hyper-V-Ereignisprotokolle](https://learn.microsoft.com/windows-server/virtualization/hyper-v/best-practices-analyzer/) - [libvirt – virsh-Dokumentation](https://www.libvirt.org/manpages/virsh.html) - [libvirt – Architektur](https://libvirt.org/architecture.html) - [QEMU – System Emulation](https://www.qemu.org/docs/master/system/index.html) - [Docker Docs – Diagnose des Docker-Daemons](https://docs.docker.com/engine/daemon/troubleshoot/) - [Docker Docs – docker inspect](https://docs.docker.com/reference/cli/docker/inspect/) - [Docker Docs – docker logs](https://docs.docker.com/reference/cli/docker/container/logs/) - [Docker Docs – docker stats](https://docs.docker.com/reference/cli/docker/container/stats/) - [Docker Docs – docker events](https://docs.docker.com/reference/cli/docker/system/events/) - [Docker Docs – Docker-Netzwerke](https://docs.docker.com/engine/network/) - [Docker Docs – Docker-Volumes](https://docs.docker.com/engine/storage/volumes/) - [Docker Docs – Compose-Dateireferenz](https://docs.docker.com/reference/compose-file/) - [Docker Docs – Multi-Platform-Images](https://docs.docker.com/build/building/multi-platform/) - [Docker Docs – Docker Desktop Troubleshoot](https://docs.docker.com/desktop/troubleshoot-and-support/troubleshoot/) - [Podman-Dokumentation](https://docs.podman.io/en/latest/) # 5. Werkzeuge der Fehleranalyse # 5.1 Windows – Integrierte Werkzeuge zur Fehleranalyse Windows stellt zahlreiche grafische Werkzeuge, Befehlszeilenprogramme und PowerShell-Cmdlets zur systematischen Fehleranalyse bereit. Damit lassen sich unter anderem Ereignisprotokolle, Prozesse, Dienste, Ressourcen, Datenträger, Netzwerkverbindungen, Systemdateien und Abstürze untersuchen. Die Werkzeuge liefern jedoch zunächst nur Befunde. Einzelne Warnungen, hohe Messwerte oder Ereignis-IDs beweisen noch keine Ursache. Ergebnisse müssen immer mit Fehlerzeitpunkt, Symptomen, Änderungen und weiteren Datenquellen abgeglichen werden. --- **Kennzeichnung der Befehle** | Kennzeichnung | Bedeutung | |---|---| | `[RO]` | Nur lesender Befehl | | `[TEST]` | Führt einen aktiven Test aus | | `[CHANGE]` | Kann den Systemzustand verändern | | `[PRIV]` | Erfordert möglicherweise administrative Rechte | | `[SENS]` | Ausgabe kann sensible Informationen enthalten | | `[RESTART]` | Neustart oder Unterbrechung möglich | > Befehle mit `[CHANGE]`, `[RESTART]` oder `[SENS]` müssen vor ihrer Verwendung besonders sorgfältig geprüft werden. ---
1. Diagnosewerkzeuge gezielt auswählen | Fragestellung | Geeignetes Werkzeug | |---|---| | Was geschah zum Fehlerzeitpunkt? | Ereignisanzeige, `Get-WinEvent` | | Welcher Prozess belastet das System? | Task-Manager, Ressourcenmonitor, `Get-Process` | | Welcher Dienst läuft nicht? | Diensteverwaltung, `Get-Service`, `sc.exe` | | Welches Programm öffnet einen Port? | Ressourcenmonitor, `Get-NetTCPConnection`, `netstat` | | Funktioniert die Namensauflösung? | `Resolve-DnsName`, `nslookup` | | Ist ein TCP-Port erreichbar? | `Test-NetConnection` | | Welche Route nimmt ein Paket? | `tracert`, `pathping` | | Ist ein Datenträger voll? | Explorer, Datenträgerverwaltung, `Get-Volume` | | Sind Windows-Systemdateien beschädigt? | SFC und DISM | | Warum wurde Windows neu gestartet? | Ereignisanzeige, `Get-WinEvent` | | Welche Treiber und Geräte sind vorhanden? | Geräte-Manager, `Get-PnpDevice`, `driverquery` | | Wie entwickelt sich die Leistung über Zeit? | Leistungsüberwachung, Datenkollektorsätze | | Welche Änderungen gingen der Störung voraus? | Zuverlässigkeitsverlauf, Updateverlauf, Ereignisprotokolle | | Warum ist Windows abgestürzt? | Speicherabbild, WinDbg, Ereignisprotokolle | **Grundregel** 1. Symptom und Zeitpunkt festhalten. 2. Umfang der Störung bestimmen. 3. Ereignisprotokolle zum betreffenden Zeitraum prüfen. 4. Ressourcen und betroffene Komponenten untersuchen. 5. Abhängigkeiten kontrollieren. 6. Erst danach Änderungen durchführen. 7. Ergebnis und Rückfallmöglichkeit dokumentieren.
2. Windows-Version und Systeminformationen erfassen **Windows-Versionsdialog öffnen** ```cmd [RO] winver ``` **Systeminformationen anzeigen** ```cmd [RO][SENS] systeminfo ``` Die Ausgabe kann unter anderem Computername, Betriebssystemversion, Installationsdatum, Arbeitsspeicher, Domänenzugehörigkeit und installierte Hotfixes enthalten. **Windows-Version mit PowerShell** ```powershell [RO] Get-ComputerInfo | Select-Object WindowsProductName, WindowsVersion, OsBuildNumber, OsArchitecture ``` **Betriebssystem über CIM abfragen** ```powershell [RO] Get-CimInstance Win32_OperatingSystem | Select-Object Caption, Version, BuildNumber, OSArchitecture, LastBootUpTime ``` **Computer- und Hardwareinformationen** ```powershell [RO][SENS] Get-ComputerInfo ``` **Systeminformationen grafisch öffnen** ```cmd [RO] msinfo32 ``` `msinfo32` enthält eine umfassende Übersicht über Hardware, Komponenten, Treiber, Ressourcen und die Softwareumgebung. > Systeminformationen können Computername, Benutzerbezug, Netzwerkdaten und installierte Software offenlegen. Exporte müssen vor einer Weitergabe geprüft werden.
3. Ereignisanzeige verwenden **Ereignisanzeige öffnen** ```cmd [RO] eventvwr.msc ``` **Wichtige Windows-Protokolle** | Protokoll | Typische Inhalte | |---|---| | Anwendung | Ereignisse von Programmen und Anwendungsdiensten | | Sicherheit | Anmeldungen, Zugriffsprüfungen und Sicherheitsereignisse | | Setup | Installation und Einrichtung von Windows-Komponenten | | System | Treiber, Dienste, Hardware und Betriebssystemkomponenten | | Weitergeleitete Ereignisse | Von anderen Computern empfangene Ereignisse | Unter **Anwendungs- und Dienstprotokolle** befinden sich zusätzliche komponentenspezifische Protokolle, beispielsweise für PowerShell, Windows Defender, DNS, Gruppenrichtlinien oder Remotedesktopdienste. **Ereignisstufen** | Stufe | Bedeutung | |---|---| | Kritisch | Schwerwiegendes Ereignis, häufig mit Ausfall oder unerwartetem Neustart | | Fehler | Eine Funktion oder Operation ist fehlgeschlagen | | Warnung | Mögliches Problem oder auffälliger Zustand | | Information | Regulärer Vorgang oder Statusmeldung | | Ausführlich | Besonders detaillierte Diagnoseinformation | **Wichtige Bewertungsregeln** - Nicht jeder Fehler im Protokoll verursacht die untersuchte Störung. - Eine hohe Zahl von Warnungen bedeutet nicht automatisch ein schwerwiegendes Problem. - Ereignis-ID und Quelle müssen gemeinsam betrachtet werden. - Derselbe Ereigniscode kann bei unterschiedlichen Quellen etwas anderes bedeuten. - Der Zeitstempel muss zur tatsächlichen Störung passen. - Folgefehler dürfen nicht mit der ursprünglichen Ursache verwechselt werden. - Ereignisse vor dem sichtbaren Fehler sind häufig besonders wichtig. - Ein unerwarteter Neustart kann ältere Protokolle oder flüchtige Zustände verändern. **Benutzerdefinierte Ansicht erstellen** 1. **Ereignisanzeige** öffnen. 2. **Benutzerdefinierte Ansichten** auswählen. 3. **Benutzerdefinierte Ansicht erstellen** öffnen. 4. Zeitraum und Ereignisstufen festlegen. 5. Benötigte Protokolle oder Quellen auswählen. 6. Filter speichern und Ergebnisse chronologisch untersuchen. > Das bloße Löschen eines Ereignisprotokolls behebt keine Ursache und vernichtet möglicherweise wichtige Diagnoseinformationen.
4. Windows-Ereignisse mit PowerShell untersuchen **Verfügbare klassische Protokolle anzeigen** ```powershell [RO] Get-WinEvent -ListLog * | Select-Object LogName, RecordCount, IsEnabled ``` **Letzte 50 Systemereignisse** ```powershell [RO][SENS] Get-WinEvent -LogName System -MaxEvents 50 ``` **Fehler und kritische Ereignisse der letzten 24 Stunden** ```powershell [RO][SENS] Get-WinEvent -FilterHashtable @{ LogName = 'System' Level = 1, 2 StartTime = (Get-Date).AddHours(-24) } | Select-Object TimeCreated, Id, ProviderName, LevelDisplayName, Message ``` **Ereignisse einer bestimmten Quelle** ```powershell [RO][SENS] Get-WinEvent -FilterHashtable @{ LogName = 'System' ProviderName = 'Service Control Manager' StartTime = (Get-Date).AddDays(-1) } | Select-Object TimeCreated, Id, LevelDisplayName, Message ``` **Bestimmte Ereignis-ID suchen** ```powershell [RO][SENS] Get-WinEvent -FilterHashtable @{ LogName = 'System' Id = 6008 StartTime = (Get-Date).AddDays(-7) } ``` **Ergebnisse exportieren** ```powershell [RO][SENS] Get-WinEvent -LogName System -MaxEvents 500 | Export-Csv -Path ".\systemereignisse.csv" -NoTypeInformation -Encoding UTF8 ``` > Exportierte Ereignisse können Benutzernamen, Computerbezeichnungen, Pfade, IP-Adressen und Anwendungsdaten enthalten. **Vorteil von `FilterHashtable`** Die Filterung erfolgt bereits beim Abruf. Das ist bei großen Ereignisprotokollen meist effizienter, als zunächst alle Ereignisse einzulesen und sie anschließend mit `Where-Object` zu filtern.
5. Häufig relevante Windows-Ereignisse einordnen | Ereignis-ID | Typische Quelle | Grundsätzliche Bedeutung | |---|---|---| | `41` | Kernel-Power | Windows wurde ohne reguläres Herunterfahren neu gestartet | | `1074` | User32 | Ein Prozess oder Benutzer leitete Herunterfahren oder Neustart ein | | `6005` | EventLog | Ereignisprotokolldienst wurde gestartet | | `6006` | EventLog | Ereignisprotokolldienst wurde regulär beendet | | `6008` | EventLog | Vorheriges Herunterfahren war unerwartet | | `7031` | Service Control Manager | Ein Dienst wurde unerwartet beendet | | `7034` | Service Control Manager | Ein Dienst wurde unerwartet beendet | | `7040` | Service Control Manager | Starttyp eines Dienstes wurde geändert | | `7045` | Service Control Manager | Ein Dienst wurde im System installiert | > Die Ereignis-ID allein ist kein vollständiger Befund. Quelle, Meldung, Zeitpunkt, betroffene Komponente und benachbarte Ereignisse müssen zusätzlich ausgewertet werden. Ein Ereignis `Kernel-Power 41` bestätigt beispielsweise, dass Windows zuvor nicht ordnungsgemäß heruntergefahren wurde. Es beweist jedoch nicht, ob Stromverlust, Hardwarefehler, Absturz, erzwungenes Ausschalten oder eine andere Ursache verantwortlich war.
6. Zuverlässigkeitsverlauf auswerten **Zuverlässigkeitsüberwachung öffnen** ```cmd [RO] perfmon /rel ``` Der Zuverlässigkeitsverlauf stellt wichtige Ereignisse nach Tagen geordnet dar. Dazu können gehören: - Anwendungsabstürze - Windows-Fehler - fehlgeschlagene Updates - Treiberinstallationen - Softwareinstallationen - erfolgreiche Updates - Hardwarefehler **Sinnvolle Vorgehensweise** 1. Tag und Uhrzeit der Störung auswählen. 2. Kritische Ereignisse untersuchen. 3. Gleichzeitig installierte Updates oder Anwendungen beachten. 4. Technische Details öffnen. 5. Befund mit Ereignisanzeige und Anwendungsprotokollen vergleichen. > Der Stabilitätsindex ist eine verdichtete Kennzahl. Er beweist nicht, welche Komponente die Ursache einer Störung ist.
7. Task-Manager zur ersten Eingrenzung verwenden **Task-Manager öffnen** ```cmd [RO] taskmgr ``` **Wichtige Bereiche** | Registerkarte | Verwendung | |---|---| | Prozesse | Momentane CPU-, RAM-, Datenträger-, Netzwerk- und GPU-Nutzung | | Leistung | Gesamtauslastung und zeitliche Kurzansicht | | App-Verlauf | Ressourcennutzung unterstützter Apps | | Autostart-Apps | Programme beim Benutzerstart | | Benutzer | Ressourcen nach angemeldeten Benutzern | | Details | Prozesse mit PID, Status, Benutzer und weiteren Spalten | | Dienste | Dienststatus und zugehörige Informationen | **Bei hoher Auslastung prüfen** - Ist die Auslastung dauerhaft oder nur kurzfristig? - Welcher Prozess verursacht sie? - Gehört der Prozess zu einer Anwendung oder einem Windows-Dienst? - Steigt der Speicherverbrauch fortlaufend? - Liegt die Datenträgeraktivität bei hoher Antwortzeit? - Wird ein Prozess mehrfach ausgeführt? - Ist die Auslastung Folge eines Updates, Scans oder Backups? - Stimmt der Fehlerzeitpunkt mit der Auslastung überein? > Das sofortige Beenden eines unbekannten Prozesses kann Datenverlust verursachen oder Systemfunktionen unterbrechen.
8. Prozesse mit PowerShell untersuchen **Prozesse anzeigen** ```powershell [RO][SENS] Get-Process ``` **Prozesse nach CPU-Zeit sortieren** ```powershell [RO][SENS] Get-Process | Sort-Object CPU -Descending | Select-Object -First 15 Name, Id, CPU, WorkingSet64 ``` `CPU` enthält die bisher verbrauchte Prozessorzeit und nicht unmittelbar die aktuelle prozentuale CPU-Auslastung. **Prozesse nach Arbeitsspeicher sortieren** ```powershell [RO][SENS] Get-Process | Sort-Object WorkingSet64 -Descending | Select-Object -First 15 Name, Id, @{Name='RAM_MiB';Expression={[math]::Round($_.WorkingSet64 / 1MB, 1)}} ``` **Bestimmten Prozess anzeigen** ```powershell [RO][SENS] Get-Process -Id ``` **Prozessdetails über CIM** ```powershell [RO][SENS] Get-CimInstance Win32_Process -Filter "ProcessId=" | Select-Object ProcessId, ParentProcessId, Name, ExecutablePath, CommandLine ``` Die Befehlszeile kann Pfade, Benutzerdaten, Servernamen oder sogar ungeschützt übergebene Zugangsdaten enthalten. **Prozess kontrolliert beenden** ```powershell [CHANGE] Stop-Process -Id ``` **Erzwungenes Beenden** ```powershell [CHANGE] Stop-Process -Id -Force ``` > `-Force` darf nicht als allgemeine Fehlerbehebung verwendet werden. Nicht gespeicherte Daten können verloren gehen und abhängige Komponenten können ausfallen.
9. Ressourcenmonitor verwenden **Ressourcenmonitor öffnen** ```cmd [RO] resmon ``` Der Ressourcenmonitor zeigt detaillierte Informationen zu: - CPU - Arbeitsspeicher - Datenträgeraktivität - Netzwerkaktivität - TCP-Verbindungen - lauschenden Ports - Prozessen und zugehörigen Dateien **Typische Anwendungsfälle** - Prozess mit hoher Datenträgeraktivität bestimmen - Datei mit vielen Zugriffen ermitteln - Prozess hinter einer TCP-Verbindung identifizieren - lauschenden Port einer Anwendung feststellen - Hard Faults und Speichernutzung untersuchen - Abhängigkeiten eines angehaltenen Prozesses betrachten > Ein Hard Fault ist nicht automatisch ein Hardwarefehler. Er bezeichnet in diesem Zusammenhang einen Speicherzugriff, bei dem benötigte Daten nicht im physischen Arbeitsspeicher vorlagen und aus einer anderen Speicherquelle geladen werden mussten.
10. Leistungsüberwachung und Performance Counter **Leistungsüberwachung öffnen** ```cmd [RO] perfmon ``` Die Leistungsüberwachung kann Messwerte in Echtzeit anzeigen oder über Datenkollektorsätze längerfristig erfassen. **Verfügbare Leistungsindikatoren mit PowerShell anzeigen** ```powershell [RO] Get-Counter -ListSet * ``` **Einzelne Messung durchführen** ```powershell [TEST] Get-Counter '\Processor(_Total)\% Processor Time' ``` **Mehrere Messwerte erfassen** ```powershell [TEST] Get-Counter ` '\Processor(_Total)\% Processor Time', '\Memory\Available MBytes', '\PhysicalDisk(_Total)\Avg. Disk sec/Transfer' ` -SampleInterval 2 ` -MaxSamples 10 ``` **Wichtige Kategorien** | Kategorie | Beispiele | |---|---| | Processor | Gesamtauslastung und Prozessorzeit | | Memory | verfügbarer Speicher und Paging | | PhysicalDisk | Warteschlangen, Übertragungen und Latenz | | Network Interface | übertragene und verworfene Daten | | Process | Werte einzelner Prozesse | | System | Prozesse, Threads und Systemaktivität | **Bewertungsregeln** - Einzelmessungen bilden nur einen kurzen Zeitpunkt ab. - Grenzwerte hängen von Arbeitslast, Hardware und Anwendung ab. - Durchschnittswerte können kurze Lastspitzen verdecken. - Eine hohe Warteschlange beweist ohne Latenz- und Durchsatzwerte noch keinen Datenträgerdefekt. - Prozessinstanzen können sich bei einem Neustart oder mehreren gleichnamigen Prozessen ändern. - Messung und Fehler müssen zeitlich zusammenpassen.
11. Dienste untersuchen **Diensteverwaltung öffnen** ```cmd [RO] services.msc ``` **Alle Dienste mit PowerShell anzeigen** ```powershell [RO] Get-Service ``` **Beendete Dienste anzeigen** ```powershell [RO] Get-Service | Where-Object Status -eq 'Stopped' ``` Ein beendeter Dienst ist nicht automatisch fehlerhaft. Viele Dienste werden nur bei Bedarf gestartet. **Bestimmten Dienst prüfen** ```powershell [RO] Get-Service -Name "" ``` **Ausführlichere Dienstinformationen** ```powershell [RO][SENS] Get-CimInstance Win32_Service -Filter "Name=''" | Select-Object Name, DisplayName, State, StartMode, StartName, PathName, ProcessId ``` **Dienstkonfiguration mit `sc.exe`** ```cmd [RO] sc.exe qc "" ``` **Dienstabhängigkeiten** ```powershell [RO] Get-Service -Name "" -RequiredServices ``` **Abhängige Dienste** ```powershell [RO] Get-Service -Name "" -DependentServices ``` **Dienst starten** ```powershell [CHANGE][PRIV] Start-Service -Name "" ``` **Dienst neu starten** ```powershell [CHANGE][PRIV][RESTART] Restart-Service -Name "" ``` > Vor einem Dienstneustart müssen abhängige Anwendungen, aktive Benutzer, Transaktionen und Auswirkungen auf andere Systeme geprüft werden.
12. Netzwerkgrundlagen erfassen **Vollständige IP-Konfiguration** ```cmd [RO][SENS] ipconfig /all ``` **PowerShell-Netzwerkkonfiguration** ```powershell [RO][SENS] Get-NetIPConfiguration ``` **IP-Adressen anzeigen** ```powershell [RO][SENS] Get-NetIPAddress ``` **Netzwerkadapter anzeigen** ```powershell [RO] Get-NetAdapter | Select-Object Name, InterfaceDescription, Status, LinkSpeed, MacAddress ``` **Routingtabelle anzeigen** ```cmd [RO][SENS] route print ``` Alternativ: ```powershell [RO][SENS] Get-NetRoute | Sort-Object InterfaceIndex, DestinationPrefix ``` **DNS-Server anzeigen** ```powershell [RO][SENS] Get-DnsClientServerAddress ``` **Wichtige Prüfwerte** - erwartete IPv4- oder IPv6-Adresse - Präfix beziehungsweise Subnetzmaske - Standardgateway - DNS-Server - DHCP-Status - Adapterstatus - Verbindungsgeschwindigkeit - unerwartete virtuelle Adapter - VPN- oder Hypervisor-Routen - APIPA-Adresse aus `169.254.0.0/16` > Eine APIPA-Adresse kann darauf hinweisen, dass keine erwartete IPv4-Konfiguration per DHCP bezogen wurde. Sie beweist jedoch nicht allein, warum der DHCP-Vorgang scheiterte.
13. Erreichbarkeit und Netzwerkpfad testen **Lokalen TCP/IP-Stack testen** ```cmd [TEST] ping 127.0.0.1 ``` **Standardgateway testen** ```cmd [TEST] ping ``` **Ziel testen** ```cmd [TEST] ping ``` **Route zum Ziel verfolgen** ```cmd [TEST][SENS] tracert ``` **Verlust und Laufzeit entlang des Pfades untersuchen** ```cmd [TEST][SENS] pathping ``` **TCP-Port mit PowerShell testen** ```powershell [TEST][SENS] Test-NetConnection -ComputerName "" -Port ``` Beispiel: ```powershell [TEST][SENS] Test-NetConnection -ComputerName "server.example" -Port 443 ``` **Erweiterte Verbindungsinformationen** ```powershell [TEST][SENS] Test-NetConnection -ComputerName "" -DiagnoseRouting -InformationLevel Detailed ``` **Bewertungsregeln** - Ein fehlgeschlagener Ping beweist nicht, dass das Ziel ausgefallen ist. - ICMP kann gefiltert werden, während ein Anwendungsport erreichbar bleibt. - Ein erfolgreicher Ping beweist nicht, dass die Anwendung funktioniert. - Ein erfolgreicher TCP-Test bestätigt die Verbindung zum getesteten Port, aber nicht automatisch eine korrekte Anwendungssitzung. - Zeitüberschreitungen bei `tracert` können durch gefilterte Antworten entstehen. - Paketverlust an einem Zwischenknoten ist nur dann aussagekräftig, wenn er sich bis zum Ziel fortsetzt.
14. DNS-Auflösung untersuchen **DNS-Abfrage mit PowerShell** ```powershell [TEST][SENS] Resolve-DnsName "" ``` **Bestimmten DNS-Server abfragen** ```powershell [TEST][SENS] Resolve-DnsName "" -Server "" ``` **Klassische DNS-Abfrage** ```cmd [TEST][SENS] nslookup ``` **DNS-Clientcache anzeigen** ```powershell [RO][SENS] Get-DnsClientCache ``` Alternativ: ```cmd [RO][SENS] ipconfig /displaydns ``` **DNS-Clientcache leeren** ```powershell [CHANGE][PRIV] Clear-DnsClientCache ``` Alternativ: ```cmd [CHANGE][PRIV] ipconfig /flushdns ``` **Typische Fehlerquellen** - falscher DNS-Server - falscher oder abgelaufener DNS-Eintrag - Suchsuffix fehlt - Split-DNS liefert abhängig vom Standort andere Antworten - VPN überschreibt DNS-Einstellungen - lokaler Cache enthält einen alten Eintrag - Hosts-Datei überschreibt DNS - Firewall blockiert DNS-Abfragen - IPv4- und IPv6-Antworten führen zu unterschiedlichen Pfaden > Das Leeren des DNS-Caches sollte nur erfolgen, wenn ein veralteter lokaler Cache als Ursache infrage kommt. Es behebt keine falschen Einträge auf dem DNS-Server.
15. Ports und Verbindungen untersuchen **TCP-Verbindungen anzeigen** ```powershell [RO][SENS] Get-NetTCPConnection ``` **Lauschende TCP-Ports** ```powershell [RO][SENS] Get-NetTCPConnection -State Listen | Sort-Object LocalPort | Select-Object LocalAddress, LocalPort, OwningProcess ``` **Zugehörigen Prozess bestimmen** ```powershell [RO][SENS] Get-Process -Id ``` **Klassische Portübersicht** ```cmd [RO][SENS] netstat -ano ``` **Lauschende Ports** ```cmd [RO][SENS] netstat -ano | findstr LISTENING ``` **Ausführbare Programme einbeziehen** ```cmd [RO][PRIV][SENS] netstat -abno ``` **UDP-Endpunkte** ```powershell [RO][SENS] Get-NetUDPEndpoint | Sort-Object LocalPort ``` **Wichtige Zustände** | Zustand | Bedeutung | |---|---| | `Listen` | Prozess wartet auf eingehende TCP-Verbindungen | | `Established` | TCP-Verbindung besteht | | `TimeWait` | Verbindung wurde beendet und bleibt vorübergehend gespeichert | | `SynSent` | Verbindungsaufbau wurde begonnen, Antwort steht noch aus | | `CloseWait` | Gegenstelle hat beendet; lokaler Prozess muss noch schließen | > Ein offener Hostport beweist noch nicht, dass die Anwendung fachlich korrekt arbeitet. Zusätzlich müssen Protokoll, Antwort und gegebenenfalls Authentifizierung getestet werden.
16. Windows-Firewall untersuchen **Firewallprofile anzeigen** ```powershell [RO] Get-NetFirewallProfile | Select-Object Name, Enabled, DefaultInboundAction, DefaultOutboundAction ``` **Aktivierte Firewallregeln anzeigen** ```powershell [RO][SENS] Get-NetFirewallRule -Enabled True | Select-Object DisplayName, Direction, Action, Profile ``` **Regeln anhand eines Namens suchen** ```powershell [RO][SENS] Get-NetFirewallRule | Where-Object DisplayName -Like '**' ``` **Firewallverwaltung öffnen** ```cmd [RO] wf.msc ``` **Typische Prüfpunkte** - aktives Netzwerkprofil - Eingangs- oder Ausgangsrichtung - erlaubende und blockierende Regeln - lokaler Port und Remoteport - lokales und entferntes Adressnetz - zugeordnetes Programm oder Dienst - Domänen-, privates oder öffentliches Profil - zentral durch Gruppenrichtlinie verwaltete Regeln > Die Firewall darf nicht pauschal deaktiviert werden, um ein Verbindungsproblem zu testen. Stattdessen muss die konkrete Verbindung mit passender Protokollierung und eng begrenzten Regeln untersucht werden.
17. Datenträger, Volumes und Speicherplatz prüfen **Volumes anzeigen** ```powershell [RO] Get-Volume | Select-Object DriveLetter, FileSystemLabel, FileSystem, HealthStatus, SizeRemaining, Size ``` **Datenträger anzeigen** ```powershell [RO] Get-Disk ``` **Partitionen anzeigen** ```powershell [RO] Get-Partition ``` **Freien Speicher übersichtlich berechnen** ```powershell [RO] Get-Volume | Where-Object DriveLetter | Select-Object DriveLetter, FileSystemLabel, @{Name='Frei_GiB';Expression={[math]::Round($_.SizeRemaining / 1GB, 2)}}, @{Name='Gesamt_GiB';Expression={[math]::Round($_.Size / 1GB, 2)}} ``` **Datenträgerverwaltung öffnen** ```cmd [RO] diskmgmt.msc ``` **Dateisystem online prüfen** ```cmd [TEST][PRIV] chkdsk C: /scan ``` **Wichtige Unterscheidungen** - Freier Speicherplatz ist nicht dasselbe wie Datenträgerzustand. - Ein Zustand `Healthy` schließt nicht jede Hardwarestörung aus. - Ein voller Datenträger kann Updates, Protokollierung, Datenbanken und Benutzeranmeldungen beeinträchtigen. - Eine hohe Datenträgerauslastung bedeutet nicht automatisch, dass das Laufwerk defekt ist. - Dateisystemfehler, Hardwarefehler, Controllerprobleme und Anwendungs-I/O müssen getrennt untersucht werden. > Reparaturoptionen wie `chkdsk /f` oder `/r` können lange Laufzeiten, exklusive Datenträgerzugriffe oder einen Neustart erfordern. Sie dürfen nicht ohne Sicherung und Wartungsplanung eingesetzt werden.
18. Arbeitsspeicher untersuchen **Grundlegende Speicherinformationen** ```powershell [RO] Get-CimInstance Win32_OperatingSystem | Select-Object @{ Name='Gesamt_GiB' Expression={[math]::Round($_.TotalVisibleMemorySize / 1MB, 2)} }, @{ Name='Frei_GiB' Expression={[math]::Round($_.FreePhysicalMemory / 1MB, 2)} } ``` **Installierte Speichermodule** ```powershell [RO][SENS] Get-CimInstance Win32_PhysicalMemory | Select-Object BankLabel, DeviceLocator, Capacity, Speed, Manufacturer, PartNumber ``` **Windows-Speicherdiagnose öffnen** ```cmd [TEST][RESTART] mdsched.exe ``` Die Speicherdiagnose bietet normalerweise einen Test beim nächsten Neustart oder einen sofortigen Neustart mit anschließender Prüfung an. > Ein Speicherdiagnosetest unter Last oder ein einzelner erfolgreicher Durchlauf schließt sporadische Hardwarefehler nicht zwingend aus.
19. Geräte und Treiber prüfen **Geräte-Manager öffnen** ```cmd [RO] devmgmt.msc ``` **Vorhandene Plug-and-Play-Geräte** ```powershell [RO][SENS] Get-PnpDevice ``` **Geräte mit Fehlerstatus** ```powershell [RO][SENS] Get-PnpDevice | Where-Object Status -ne 'OK' ``` **Installierte Treiber** ```cmd [RO][SENS] driverquery /v ``` **Signierte Treiber mit PowerShell** ```powershell [RO][SENS] Get-CimInstance Win32_PnPSignedDriver | Select-Object DeviceName, DriverVersion, DriverDate, Manufacturer, InfName ``` **Typische Prüfpunkte** - Gerätestatus und Fehlercode - Treiberversion und Treiberdatum - kürzlich erfolgte Treiberänderung - unbekannte oder deaktivierte Geräte - Hardware-ID - Herstellerfreigabe für die Windows-Version - Zusammenhang zwischen Treiberinstallation und Fehlerzeitpunkt > Ein neuerer Treiber ist nicht automatisch geeigneter. Entscheidend sind Hardwaremodell, Betriebssystemversion und Freigabe durch Hersteller oder Geräteanbieter.
20. Autostart, Aufgaben und Systemstart untersuchen **Autostartprogramme über CIM anzeigen** ```powershell [RO][SENS] Get-CimInstance Win32_StartupCommand | Select-Object Name, Command, Location, User ``` **Aufgabenplanung öffnen** ```cmd [RO] taskschd.msc ``` **Geplante Aufgaben anzeigen** ```powershell [RO][SENS] Get-ScheduledTask | Select-Object TaskPath, TaskName, State ``` **Aufgaben mit letztem Ergebnis** ```powershell [RO][SENS] Get-ScheduledTask | ForEach-Object { $info = $_ | Get-ScheduledTaskInfo [PSCustomObject]@{ TaskPath = $_.TaskPath TaskName = $_.TaskName State = $_.State LastRunTime = $info.LastRunTime LastTaskResult = $info.LastTaskResult NextRunTime = $info.NextRunTime } } ``` **Systemkonfiguration öffnen** ```cmd [RO] msconfig ``` > Autostarteinträge und geplante Aufgaben dürfen nicht wahllos deaktiviert werden. Sie können zu Sicherheitssoftware, Backups, Updates, Treibern oder geschäftskritischen Anwendungen gehören.
21. Windows-Updates prüfen **Installierte Hotfixes anzeigen** ```powershell [RO] Get-HotFix | Sort-Object InstalledOn -Descending ``` **Updateverlauf in den Einstellungen** ```text Einstellungen → Windows Update → Updateverlauf ``` **Windows-Update-Ereignisse abrufen** ```powershell [RO][SENS] Get-WinEvent -LogName ` 'Microsoft-Windows-WindowsUpdateClient/Operational' ` -MaxEvents 100 | Select-Object TimeCreated, Id, LevelDisplayName, Message ``` **Typische Prüfpunkte** - Zeitpunkt der Installation - KB-Nummer - erfolgreicher oder fehlgeschlagener Abschluss - erforderlicher Neustart - Treiberupdate - bekannte Abhängigkeit zur betroffenen Anwendung - wiederholt fehlgeschlagene Installation - ausreichend freier Speicher - Richtlinien oder Updateverwaltung im Unternehmen > Ein zeitlicher Zusammenhang zwischen Update und Fehler ist ein wichtiger Hinweis, aber noch kein Ursachennachweis. Vor einer Deinstallation müssen bekannte Probleme, Sicherheitsfolgen und Herstellerangaben geprüft werden.
22. Windows-Systemdateien mit SFC prüfen Der System File Checker überprüft geschützte Windows-Systemdateien und kann beschädigte Dateien ersetzen. **Systemdateien prüfen und reparieren** ```cmd [CHANGE][PRIV] sfc /scannow ``` **Nur eine bestimmte Datei prüfen** ```cmd [TEST][PRIV] sfc /verifyfile="" ``` **Nur prüfen, ohne Reparatur** ```cmd [TEST][PRIV] sfc /verifyonly ``` **Mögliche Ergebnisse** - Keine Integritätsverletzungen gefunden - Beschädigte Dateien gefunden und erfolgreich repariert - Beschädigte Dateien gefunden, aber nicht alle repariert - Prüfung konnte nicht ausgeführt werden **SFC-Einträge aus dem CBS-Protokoll filtern** ```cmd [RO][PRIV][SENS] findstr /c:"[SR]" %windir%\Logs\CBS\CBS.log ``` > SFC ist kein universelles Reparaturprogramm. Es untersucht geschützte Windows-Systemdateien, nicht automatisch Anwendungsdateien, Benutzerdaten, Hardware oder sämtliche Konfigurationen.
23. Windows-Komponentenspeicher mit DISM prüfen DISM kann den Zustand des Windows-Abbilds beziehungsweise Komponentenspeichers untersuchen und reparieren. **Schnelle Statusprüfung** ```cmd [RO][PRIV] DISM /Online /Cleanup-Image /CheckHealth ``` **Ausführliche Prüfung** ```cmd [TEST][PRIV] DISM /Online /Cleanup-Image /ScanHealth ``` **Windows-Abbild reparieren** ```cmd [CHANGE][PRIV] DISM /Online /Cleanup-Image /RestoreHealth ``` **Bedeutung der Parameter** | Parameter | Bedeutung | |---|---| | `/Online` | Aktuell laufendes Windows wird bearbeitet | | `/Cleanup-Image` | Wartungsfunktion für das Windows-Abbild | | `/CheckHealth` | Prüft, ob eine Beschädigung bereits erkannt wurde | | `/ScanHealth` | Führt eine ausführlichere Prüfung durch | | `/RestoreHealth` | Versucht erkannte Beschädigungen zu reparieren | **Wichtige Hinweise** - `/RestoreHealth` verändert den Systemzustand. - Der Vorgang kann längere Zeit dauern. - Eine Reparaturquelle kann erforderlich sein. - Die Quelle muss zum installierten Windows passen. - Fehler müssen anhand des DISM-Protokolls ausgewertet werden. - Nach erfolgreicher Reparatur kann eine erneute SFC-Prüfung sinnvoll sein. **DISM-Protokoll** ```text C:\Windows\Logs\DISM\dism.log ``` **CBS-Protokoll** ```text C:\Windows\Logs\CBS\CBS.log ``` > DISM und SFC dürfen nicht reflexartig bei jedem Windows-Problem ausgeführt werden. Zuerst sollte ein Zusammenhang mit beschädigten Windows-Komponenten oder Systemdateien begründet werden.
24. Gruppenrichtlinien und Richtlinienanwendung prüfen **Angewendete Richtlinien anzeigen** ```cmd [RO][SENS] gpresult /r ``` **Ausführlichen HTML-Bericht erzeugen** ```cmd [RO][SENS] gpresult /h ".\gpresult.html" ``` **Resultant Set of Policy öffnen** ```cmd [RO][SENS] rsop.msc ``` **Gruppenrichtlinien-Ereignisse** ```powershell [RO][SENS] Get-WinEvent -LogName ` 'Microsoft-Windows-GroupPolicy/Operational' ` -MaxEvents 100 | Select-Object TimeCreated, Id, LevelDisplayName, Message ``` **Gruppenrichtlinien aktualisieren** ```cmd [CHANGE][PRIV] gpupdate /force ``` > `gpupdate /force` kann Richtlinien erneut anwenden, Anmelde- oder Neustartanforderungen auslösen und den Arbeitszustand beeinflussen. Der Befehl ist kein Ersatz für die Analyse einer fehlerhaften Richtlinie.
25. Anmeldungen und Benutzerkontext untersuchen **Aktuellen Benutzer anzeigen** ```cmd [RO] whoami ``` **Gruppen und Sicherheitskennungen anzeigen** ```cmd [RO][SENS] whoami /groups ``` **Aktuelle Berechtigungen anzeigen** ```cmd [RO][SENS] whoami /priv ``` **Angemeldete Sitzungen** ```cmd [RO][SENS] query user ``` **Lokale Benutzer anzeigen** ```powershell [RO][SENS] Get-LocalUser ``` **Lokale Gruppenmitgliedschaften** ```powershell [RO][SENS] Get-LocalGroupMember -Group "" ``` **Kerberos-Tickets anzeigen** ```cmd [RO][SENS] klist ``` **Typische Ursachen kontextabhängiger Fehler** - anderer Benutzer - fehlende Gruppenmitgliedschaft - nicht aktualisiertes Zugriffstoken - lokale statt Domänenanmeldung - abgelaufenes oder fehlendes Kerberos-Ticket - Dienst läuft unter anderem Konto - unterschiedliche Umgebungsvariablen - abweichendes Benutzerprofil - erhöhte und nicht erhöhte Sitzung besitzen unterschiedliche Rechte > Ein erfolgreicher Test als Administrator beweist nicht, dass die Funktion für den vorgesehenen Benutzer korrekt berechtigt ist.
26. Remotedienste und Freigaben prüfen **SMB-Freigaben anzeigen** ```powershell [RO][SENS] Get-SmbShare ``` **Bestehende SMB-Verbindungen** ```powershell [RO][SENS] Get-SmbConnection ``` **Erreichbarkeit von SMB testen** ```powershell [TEST][SENS] Test-NetConnection -ComputerName "" -Port 445 ``` **Remotedesktopport testen** ```powershell [TEST][SENS] Test-NetConnection -ComputerName "" -Port 3389 ``` **WinRM-Konfiguration anzeigen** ```cmd [RO][SENS] winrm get winrm/config ``` **WinRM-Verbindung testen** ```powershell [TEST][SENS] Test-WSMan -ComputerName "" ``` **Wichtige Unterscheidung** Eine erfolgreiche TCP-Verbindung bestätigt nur, dass der getestete Port erreichbar ist. Sie bestätigt nicht automatisch: - erfolgreiche Authentifizierung - korrekte Freigabeberechtigung - NTFS-Berechtigung - funktionierende Remotedesktopsitzung - gültiges Zertifikat - erfolgreiche Anwendungskommunikation
27. Abstürze und Speicherabbilder untersuchen Windows kann bei System- oder Anwendungsabstürzen Speicherabbilder erzeugen. **Typische Speicherorte** ```text C:\Windows\MEMORY.DMP C:\Windows\Minidump\ %LOCALAPPDATA%\CrashDumps\ ``` Die tatsächliche Konfiguration und der Speicherort können abweichen. **Start- und Wiederherstellungseinstellungen öffnen** ```cmd [RO] sysdm.cpl ``` Danach: ```text Erweitert → Starten und Wiederherstellen → Einstellungen ``` **Typische Abbildarten** | Typ | Inhalt | |---|---| | Kleines Speicherabbild | Begrenzte Informationen zum Absturz | | Kernelspeicherabbild | Kernelbezogene Speicherbereiche | | Automatisches Speicherabbild | Von Windows verwaltete Auswahl | | Vollständiges Speicherabbild | Umfassender Inhalt des physischen Speichers | | Aktives Speicherabbild | Für aktive Kernel- und Systembereiche optimiert | **Wichtige Sicherheitsregel** Speicherabbilder können enthalten: - Benutzerdaten - Dateiinhalte - Prozessspeicher - Schlüsselmaterial - Tokens - Passwörter oder andere Geheimnisse - Netzwerk- und Sitzungsinformationen > Speicherabbilder müssen wie sensible Diagnosedaten behandelt und dürfen nicht ungeprüft weitergegeben werden. Zur detaillierten Analyse kann Microsoft WinDbg eingesetzt werden. WinDbg wird auf einer späteren Seite zusammen mit weiteren spezialisierten Werkzeugen behandelt.
28. Abgesicherter Modus und sauberer Systemstart Der abgesicherte Modus startet Windows mit einer eingeschränkten Auswahl von Treibern und Diensten. Damit kann geprüft werden, ob ein Fehler durch zusätzliche Software, Treiber oder Autostartkomponenten beeinflusst wird. Ein sauberer Systemstart deaktiviert gezielt nicht benötigte Dienste und Autostartprogramme, um Konflikte einzugrenzen. **Systemkonfiguration öffnen** ```cmd [CHANGE][RESTART] msconfig ``` **Wichtige Risiken** - Sicherheits- oder Verwaltungssoftware kann vorübergehend deaktiviert werden. - Geschäftsanwendungen oder Hintergrunddienste können ausfallen. - Änderungen müssen dokumentiert und anschließend zurückgenommen werden. - Abgesicherter Modus und sauberer Start sind Diagnosezustände, keine dauerhafte Lösung. - In verwalteten Umgebungen kann eine Freigabe erforderlich sein. **Geeignete Fragestellung** ```text Tritt der Fehler auch mit einer minimalen Auswahl von Treibern, Diensten und Autostartprogrammen auf? ``` Ein ausbleibender Fehler grenzt die Ursache ein, identifiziert aber noch nicht automatisch die verantwortliche Komponente.
29. Fernzugriff und Datensammlung sicher durchführen Vor einer Ferndiagnose müssen geklärt werden: - korrekter Zielcomputer - berechtigte Person - Wartungs- oder Diagnosefenster - Auswirkungen auf aktive Benutzer - erlaubte Werkzeuge - Speicherort der Diagnosedaten - Schutz sensibler Informationen - Rückfallplan für Änderungen **Computername prüfen** ```powershell [RO] $env:COMPUTERNAME ``` **Benutzerkontext prüfen** ```powershell [RO] whoami ``` **PowerShell-Remotesitzung testen** ```powershell [TEST][SENS] Test-WSMan -ComputerName "" ``` **Befehl remote ausführen** ```powershell [RO][SENS] Invoke-Command -ComputerName "" -ScriptBlock { Get-CimInstance Win32_OperatingSystem | Select-Object Caption, Version, LastBootUpTime } ``` > Remoteausgaben, Transkripte und Diagnosearchive können sensible Daten enthalten. Sie müssen zweckgebunden gespeichert, geschützt und nach den geltenden Vorgaben gelöscht werden.
30. Gefährliche Schnelllösungen vermeiden | Maßnahme | Risiko | |---|---| | Unbekannten Prozess sofort beenden | Datenverlust oder Dienstausfall | | Dienst ohne Prüfung neu starten | Unterbrechung abhängiger Anwendungen | | Windows-Firewall vollständig deaktivieren | Schutzwirkung entfällt | | Ereignisprotokolle löschen | Diagnosenachweise gehen verloren | | Registrywerte auf Verdacht ändern | System oder Anwendung wird beschädigt | | Treiber ungeprüft aktualisieren | Inkompatibilität oder Startfehler | | Update sofort deinstallieren | Sicherheitslücke oder Folgefehler | | `chkdsk /f` ungeplant ausführen | Neustart und lange Ausfallzeit | | DISM oder SFC als Universallösung verwenden | Ursache bleibt ungeklärt | | Autostart und Dienste wahllos deaktivieren | Sicherheits- und Geschäftsfunktionen fallen aus | | Speicherabbild unredigiert weitergeben | Geheimnisse und Benutzerdaten werden offengelegt | | Computer hart ausschalten | Daten- und Dateisystemschäden | | Systemwiederherstellung ungeprüft starten | Neuere Änderungen können verloren gehen | | „PC zurücksetzen“ verwenden | Anwendungen, Einstellungen oder Daten gehen verloren | **Vor einer Änderung prüfen** 1. Ist die Ursache ausreichend eingegrenzt? 2. Welche Systeme und Benutzer sind betroffen? 3. Existiert eine aktuelle Sicherung? 4. Ist die Maßnahme reversibel? 5. Welche Abhängigkeiten bestehen? 6. Ist ein Neustart erforderlich? 7. Gibt es ein Wartungsfenster? 8. Wie wird die Funktion anschließend getestet? 9. Wie wird die Änderung dokumentiert?
31. Sichere Reihenfolge einer Windows-Fehleranalyse 1. Betroffenen Computer und Benutzer eindeutig bestimmen. 2. Originale Fehlermeldung und Fehlerzeitpunkt erfassen. 3. Umfang und Reproduzierbarkeit prüfen. 4. Windows-Version, Build und letzte Startzeit erfassen. 5. Änderungen, Updates und Installationen vor dem Fehler feststellen. 6. Ereignisanzeige und Zuverlässigkeitsverlauf zum Fehlerzeitpunkt prüfen. 7. Prozesse, Dienste und aktuelle Ressourcenbelastung untersuchen. 8. Freien Speicherplatz und Datenträgerzustand kontrollieren. 9. Netzwerk, DNS, Route und benötigte Ports getrennt testen. 10. Benutzerkontext, Berechtigungen und Richtlinien berücksichtigen. 11. Treiber, Geräte und Abhängigkeiten prüfen. 12. Erkenntnisse aus mehreren Datenquellen abgleichen. 13. Sicherung und Rückfallplan kontrollieren. 14. Kleinste geeignete Änderung durchführen. 15. Interne und externe Funktionsprüfung ausführen. 16. Ereignisse und Ressourcen nach der Maßnahme erneut prüfen. 17. Ursache, Maßnahme und Ergebnis dokumentieren.
32. Schnelle Befehlsübersicht | Aufgabe | Befehl | |---|---| | Windows-Version | `[RO] winver` | | Systeminformationen | `[RO][SENS] systeminfo` | | Ereignisanzeige | `[RO] eventvwr.msc` | | Systemereignisse | `[RO][SENS] Get-WinEvent -LogName System -MaxEvents 50` | | Zuverlässigkeitsverlauf | `[RO] perfmon /rel` | | Task-Manager | `[RO] taskmgr` | | Ressourcenmonitor | `[RO] resmon` | | Leistungsüberwachung | `[RO] perfmon` | | Prozesse | `[RO][SENS] Get-Process` | | Dienste | `[RO] Get-Service` | | Dienstkonfiguration | `[RO] sc.exe qc ""` | | IP-Konfiguration | `[RO][SENS] ipconfig /all` | | Adapter | `[RO] Get-NetAdapter` | | Routingtabelle | `[RO][SENS] route print` | | Erreichbarkeit | `[TEST] ping ` | | Route | `[TEST][SENS] tracert ` | | TCP-Port | `[TEST][SENS] Test-NetConnection "" -Port ` | | DNS | `[TEST][SENS] Resolve-DnsName ""` | | TCP-Verbindungen | `[RO][SENS] Get-NetTCPConnection` | | Ports und PID | `[RO][SENS] netstat -ano` | | Firewallprofile | `[RO] Get-NetFirewallProfile` | | Volumes | `[RO] Get-Volume` | | Datenträger | `[RO] Get-Disk` | | Geräte | `[RO][SENS] Get-PnpDevice` | | Treiber | `[RO][SENS] driverquery /v` | | Geplante Aufgaben | `[RO][SENS] Get-ScheduledTask` | | Gruppenrichtlinien | `[RO][SENS] gpresult /r` | | Benutzerkontext | `[RO] whoami` | | Systemdateien | `[CHANGE][PRIV] sfc /scannow` | | Abbildprüfung | `[TEST][PRIV] DISM /Online /Cleanup-Image /ScanHealth` | | Abbildreparatur | `[CHANGE][PRIV] DISM /Online /Cleanup-Image /RestoreHealth` |
33. Dokumentationsvorlage ```text Ticket: Datum und Uhrzeit: Bearbeiter: Computername: Windows-Edition: Windows-Version: Build: Architektur: Letzter Systemstart: Benutzerkontext: Domäne oder Arbeitsgruppe: Originale Fehlermeldung: Fehlerzeitpunkt: Erstmals aufgetreten: Reproduzierbar: Betroffene Benutzer: Betroffene Anwendung oder Funktion: Umfang der Störung: Letzte funktionierende Nutzung: Letzte Änderung: Installierte Updates: Treiberänderung: Softwareinstallation: Richtlinienänderung: Relevante Ereignisquellen: Ereignis-IDs: Zuverlässigkeitsverlauf: Betroffene Prozesse: Betroffene Dienste: CPU: Arbeitsspeicher: Datenträger: Freier Speicher: IP-Konfiguration: DNS: Standardgateway: Getestetes Ziel: Getesteter Port: Testergebnis: Firewallprofil: Firewallregel: Gerätestatus: Treiberversion: Systemdateiprüfung: DISM-Status: Absturzabbild: Sensible Daten redigiert: Vermutete Ursache: Durchgeführte Tests: Sicherung geprüft: Geplante Änderung: Erwartete Auswirkung: Rückfallplan: Neustart erforderlich: Ergebnis nach der Maßnahme: Interne Funktionsprüfung: Externe Funktionsprüfung: Monitoring: Weiterführende Maßnahmen: ```
--- **Merksatz** > Windows stellt viele Diagnosewerkzeuge bereit, doch kein einzelnes Werkzeug liefert automatisch die Ursache. Eine belastbare Fehleranalyse verbindet Zeitpunkt, Ereignisse, Prozesse, Dienste, Ressourcen, Netzwerk, Änderungen und Benutzerkontext zu einem nachvollziehbaren Gesamtbild. **Quellen und weiterführende Dokumentation** - [Microsoft Learn – Windows-Problembehandlungsdokumentation](https://learn.microsoft.com/troubleshoot/windows/) - [Microsoft Learn – Get-WinEvent](https://learn.microsoft.com/powershell/module/microsoft.powershell.diagnostics/get-winevent) - [Microsoft Learn – Get-Process](https://learn.microsoft.com/powershell/module/microsoft.powershell.management/get-process) - [Microsoft Learn – Get-Service](https://learn.microsoft.com/powershell/module/microsoft.powershell.management/get-service) - [Microsoft Learn – Get-Counter](https://learn.microsoft.com/powershell/module/microsoft.powershell.diagnostics/get-counter) - [Microsoft Learn – Get-NetIPConfiguration](https://learn.microsoft.com/powershell/module/nettcpip/get-netipconfiguration) - [Microsoft Learn – Test-NetConnection](https://learn.microsoft.com/powershell/module/nettcpip/test-netconnection) - [Microsoft Learn – Resolve-DnsName](https://learn.microsoft.com/powershell/module/dnsclient/resolve-dnsname) - [Microsoft Learn – Get-NetTCPConnection](https://learn.microsoft.com/powershell/module/nettcpip/get-nettcpconnection) - [Microsoft Learn – Get-NetFirewallProfile](https://learn.microsoft.com/powershell/module/netsecurity/get-netfirewallprofile) - [Microsoft Learn – Get-Volume](https://learn.microsoft.com/powershell/module/storage/get-volume) - [Microsoft Learn – Get-PnpDevice](https://learn.microsoft.com/powershell/module/pnpdevice/get-pnpdevice) - [Microsoft Learn – System File Checker](https://learn.microsoft.com/windows-server/administration/windows-commands/sfc) - [Microsoft Learn – Windows-Abbild mit DISM reparieren](https://learn.microsoft.com/windows-hardware/manufacture/desktop/repair-a-windows-image) - [Microsoft Learn – Chkdsk](https://learn.microsoft.com/windows-server/administration/windows-commands/chkdsk) - [Microsoft Learn – GPResult](https://learn.microsoft.com/windows-server/administration/windows-commands/gpresult) - [Microsoft Learn – Windows-Debuggingwerkzeuge](https://learn.microsoft.com/windows-hardware/drivers/debugger/) # 5.2 Microsoft Sysinternals – Erweiterte Werkzeuge zur Fehleranalyse Microsoft Sysinternals ist eine Sammlung spezialisierter Diagnose-, Analyse- und Verwaltungswerkzeuge. Die Programme ermöglichen einen wesentlich tieferen Einblick in Prozesse, Autostarts, Dateizugriffe, Registryzugriffe, Netzwerkverbindungen, Arbeitsspeicher, Berechtigungen, Active Directory und Systemereignisse als viele integrierte Windows-Werkzeuge. Sysinternals-Werkzeuge können unter anderem helfen bei: - nicht nachvollziehbaren Programmabstürzen - blockierten Dateien und Verzeichnissen - ungewöhnlich hoher CPU-, RAM- oder Datenträgerauslastung - fehlgeschlagenen Datei- oder Registryzugriffen - unbekannten Autostarteinträgen - verdächtigen Prozessen und Netzwerkverbindungen - DLL- und Abhängigkeitsproblemen - Berechtigungsfehlern - Speicherlecks - sporadischen Programmabstürzen - Active-Directory-Problemen - detaillierter Sicherheitsüberwachung > Sysinternals-Werkzeuge liefern technische Beobachtungen und Messdaten. Ein auffälliger Eintrag ist noch kein Beweis für Malware, einen Defekt oder die eigentliche Ursache einer Störung. --- **Kennzeichnung der Befehle** | Kennzeichnung | Bedeutung | |---|---| | `[RO]` | Nur lesender beziehungsweise beobachtender Einsatz | | `[TEST]` | Führt einen aktiven Test oder eine Aufzeichnung durch | | `[CHANGE]` | Verändert Prozesse, Dateien, Konfigurationen oder Systemzustand | | `[PRIV]` | Erhöhte Berechtigungen können erforderlich sein | | `[RESTART]` | Kann einen Neustart oder eine Unterbrechung verursachen | | `[REMOTE]` | Greift auf einen anderen Computer zu | | `[SENS]` | Ausgabe kann sensible Informationen enthalten | | `[DANGER]` | Hohes Risiko für Ausfall, Datenverlust oder Sicherheitsprobleme | Die Kennzeichnungen sind Hinweise für den administrativen Einsatz. Ob eine Freigabe erforderlich ist, hängt zusätzlich von der jeweiligen Organisation, dem betroffenen System und den geltenden Sicherheitsvorgaben ab. ---
1. Was ist Microsoft Sysinternals? Die Sysinternals-Werkzeuge wurden ursprünglich von Mark Russinovich und Bryce Cogswell entwickelt. Microsoft übernahm Sysinternals im Jahr 2006 und stellt die Werkzeuge weiterhin bereit. Die Sammlung besteht überwiegend aus kleinen, spezialisierten Programmen. Viele davon müssen nicht klassisch installiert werden und können nach dem Entpacken direkt gestartet werden. **Wichtige Werkzeuggruppen** | Bereich | Beispiele | |---|---| | Prozesse | Process Explorer, ProcDump, PsList, PsKill | | Systemaktivität | Process Monitor, Sysmon, DebugView | | Autostart | Autoruns, Autorunsc | | Netzwerk | TCPView, Tcpvcon, PsPing | | Arbeitsspeicher | RAMMap, VMMap | | Dateien und Objekte | Handle, ListDLLs, Streams, PendMoves | | Sicherheit und Rechte | Sigcheck, AccessChk, AccessEnum, ShareEnum | | Active Directory | AD Explorer, AD Insight, AD Restore | | Datenträger | Disk2vhd, DiskMon, Disk Usage, NTFSInfo | | Remotewerkzeuge | PsExec, PsService, PsInfo, PsLoggedOn | | Kernelanalyse | LiveKd, WinObj | | Systeminformation | Coreinfo, BgInfo, LogonSessions | **Abgrenzung** Sysinternals ist: - keine automatische Reparatursuite - kein Ersatz für ein Antiviren- oder EDR-System - kein Ersatz für ein zentrales Monitoring - kein vollständiger Debugger - kein Beweiswerkzeug, das aus einer einzelnen Auffälligkeit automatisch die Ursache bestimmt Die Werkzeuge ergänzen Ereignisanzeige, Task-Manager, Ressourcenmonitor, Leistungsüberwachung, PowerShell und spezialisierte Debuggingprogramme.
2. Sysinternals sicher beziehen Sysinternals-Werkzeuge sollten ausschließlich aus vertrauenswürdigen Microsoft-Quellen bezogen werden. **Offizielle Möglichkeiten** 1. Einzelwerkzeuge über Microsoft Learn herunterladen 2. vollständige Sysinternals Suite herunterladen 3. Sysinternals Suite aus dem Microsoft Store installieren 4. Werkzeuge über Sysinternals Live ausführen **Sysinternals Suite** Die Suite enthält einen großen Teil der Diagnosewerkzeuge in einem gemeinsamen Archiv. Für bestimmte Plattformen stellt Microsoft unterschiedliche Pakete bereit, darunter x64 und ARM64. **Microsoft Store** Bei der Store-Version werden grafische Programme im Startmenü eingetragen. Die Befehlszeilenprogramme können über App-Ausführungsaliase aufgerufen werden. **Sysinternals Live** Ein Werkzeug kann direkt von Sysinternals Live gestartet werden: ```cmd [TEST][SENS] \\live.sysinternals.com\tools\procexp.exe ``` Beispiel für Process Monitor: ```cmd [TEST][SENS] \\live.sysinternals.com\tools\procmon.exe ``` Dabei müssen Netzwerkzugriff, Proxy, Firewall, Namensauflösung und die Sicherheitsrichtlinien der Organisation berücksichtigt werden. > In kontrollierten Unternehmensumgebungen sollte nicht ungeprüft eine ausführbare Datei direkt aus dem Internet gestartet werden. Besser ist häufig ein freigegebenes, geprüftes und versioniertes internes Werkzeugverzeichnis.
3. Integrität und Signatur prüfen Vor dem Einsatz sollte geprüft werden: - stammt die Datei von Microsoft? - ist die digitale Signatur gültig? - stimmt die erwartete Architektur? - wurde die Datei aus einem freigegebenen Speicherort bezogen? - ist die Werkzeugversion dokumentiert? - wurde die Datei durch die Sicherheitssoftware geprüft? **Digitale Signatur mit PowerShell kontrollieren** ```powershell [RO] Get-AuthenticodeSignature ".\procexp.exe" | Select-Object Status, StatusMessage, SignerCertificate ``` **Dateihash berechnen** ```powershell [RO] Get-FileHash ".\procexp.exe" -Algorithm SHA256 ``` Der Hash kann zur internen Dokumentation und zum Vergleich identischer Werkzeugstände verwendet werden. Ein Hash beweist allein jedoch nicht, dass eine Datei vertrauenswürdig ist. **Sysinternals Sigcheck verwenden** ```cmd [RO] sigcheck.exe -a -h -i ".\procexp.exe" ``` Typische Informationen können sein: - Dateiversion - Herausgeber - digitale Signatur - Zertifikatskette - Zeitstempel - kryptografischer Hash - Dateibeschreibung - Produktname > Eine gültige Signatur bestätigt die signierte Herkunft und Dateiintegrität innerhalb der Signaturprüfung. Sie beweist nicht automatisch, dass jede ausgeführte Funktion im konkreten Einsatz sicher oder erwünscht ist.
4. Allgemeine Einsatzregeln Vor dem Start eines Sysinternals-Werkzeugs sollte feststehen: 1. Welcher Fehler wird untersucht? 2. Welcher Computer ist betroffen? 3. Welcher Benutzerkontext ist betroffen? 4. Wann tritt der Fehler auf? 5. Welches Werkzeug kann die benötigte Beobachtung liefern? 6. Welche Daten können bei der Aufzeichnung entstehen? 7. Ist eine erhöhte Ausführung erforderlich? 8. Wie groß kann die Protokolldatei werden? 9. Wo wird sie geschützt gespeichert? 10. Wann wird die Aufzeichnung beendet? 11. Wie werden sensible Daten redigiert? 12. Welche Änderung muss anschließend zurückgenommen werden? **Grundregeln** - zuerst beobachten, dann verändern - Filter vor längeren Aufzeichnungen vorbereiten - Zeitpunkt und Reproduktionsschritte dokumentieren - keine Prozesse oder Handles auf Verdacht beenden - keine unbekannten Autostarts ungeprüft löschen - keine Diagnosedateien öffentlich hochladen - keine Remoteausführung ohne Freigabe - nur den erforderlichen Berechtigungskontext verwenden - Werkzeugversion und Befehlszeile dokumentieren - nach jeder Änderung die betroffene Funktion erneut prüfen
5. Process Explorer – Prozesse und Abhängigkeiten analysieren Process Explorer zeigt Prozesse hierarchisch an und liefert detaillierte Informationen zu: - Prozessname und PID - übergeordnetem Prozess - Benutzerkonto - CPU- und Speicherauslastung - Handles - geladenen DLLs - Speicherabbildern - Threads - TCP/IP-Aktivität - Dateipfad - Befehlszeile - digitaler Signatur - Integritätsstufe - Sicherheitskontext - Prozessstartzeit **Starten** ```cmd [RO][SENS] procexp.exe ``` Für vollständige Informationen über Systemprozesse können erhöhte Rechte erforderlich sein: ```cmd [RO][PRIV][SENS] procexp.exe ``` **Wichtige Funktionen** | Funktion | Verwendung | |---|---| | Process Tree | Eltern-Kind-Beziehungen von Prozessen erkennen | | Lower Pane – Handles | Geöffnete Dateien, Registryschlüssel und andere Objekte untersuchen | | Lower Pane – DLLs | Geladene DLLs und speicherabgebildete Dateien anzeigen | | Find Handle or DLL | Prozess zu einer Datei, einem Objekt oder einer DLL finden | | Properties | Threads, Netzwerk, Sicherheit, Umgebung und Startparameter untersuchen | | Verify Image Signatures | Signaturen ausführbarer Dateien prüfen | | Save | Prozessübersicht für die Dokumentation speichern | | Create Dump | Speicherabbild eines Prozesses erzeugen | | Kill Process Tree | Prozess und untergeordnete Prozesse beenden | **Typische Anwendungsfälle** - Welcher Prozess hält eine Datei geöffnet? - Welche Anwendung hat einen Unterprozess gestartet? - Unter welchem Konto läuft ein Prozess? - Welche DLL wurde aus einem unerwarteten Pfad geladen? - Welcher Thread erzeugt hohe CPU-Last? - Stimmen Dateiname, Pfad und Herausgeber zusammen? - Ist ein Prozess mehrfach vorhanden? - Läuft ein Prozess mit erhöhten Rechten? **Prozessfarben** Process Explorer kann unterschiedliche Prozesstypen farblich kennzeichnen. Die genaue Bedeutung hängt von der konfigurierten Farbauswahl ab und sollte über die Programmeinstellungen kontrolliert werden. > Eine Farbe oder ein nicht verifizierter Signaturstatus ist kein automatischer Malware-Nachweis.
6. Blockierte Dateien mit Process Explorer finden Wenn eine Datei nicht gelöscht, verschoben oder ersetzt werden kann, kann ein geöffneter Handle dafür verantwortlich sein. **Vorgehensweise** 1. Process Explorer starten. 2. `Find` öffnen. 3. `Find Handle or DLL` auswählen. 4. eindeutigen Teil des Datei- oder Verzeichnisnamens eingeben. 5. Treffer und zugehörigen Prozess prüfen. 6. Anwendung möglichst regulär schließen. 7. Dateioperation erneut testen. **Nicht als erste Maßnahme verwenden** - Prozess sofort beenden - Handle direkt schließen - Dienst ungeprüft stoppen - Systemprozess beenden - Datei mit Gewalt löschen Das direkte Schließen eines Handles kann den Zustand der Anwendung beschädigen, Datenverlust verursachen oder zu einem späteren Absturz führen. > Die sichere Lösung besteht normalerweise darin, die verursachende Anwendung oder den zugehörigen Dienst kontrolliert zu beenden.
7. Handle – offene Dateien und Objekte per Befehlszeile `Handle` zeigt offene Handles von Prozessen an. Damit kann unter anderem ermittelt werden, welcher Prozess eine bestimmte Datei oder ein Verzeichnis verwendet. **Nach einem Dateinamen suchen** ```cmd [RO][PRIV][SENS] handle.exe "" ``` **Beispiel** ```cmd [RO][PRIV][SENS] handle.exe "datenbank.db" ``` **Handles eines bestimmten Prozesses anzeigen** ```cmd [RO][PRIV][SENS] handle.exe -p ``` **Ausgabe ohne Banner** ```cmd [RO][PRIV][SENS] handle.exe -nobanner "" ``` **Handle schließen** ```cmd [CHANGE][PRIV][DANGER] handle.exe -c -p ``` > Das erzwungene Schließen eines Handles kann Daten beschädigen oder einen Prozess destabilisieren. Diese Funktion darf nur verwendet werden, wenn Objekt, Prozess, Abhängigkeiten und Auswirkungen eindeutig bekannt sind.
8. Process Monitor – Datei-, Registry- und Prozessaktivität erfassen Process Monitor, kurz Procmon, zeichnet in Echtzeit unter anderem folgende Aktivitäten auf: - Dateisystemzugriffe - Registryzugriffe - Prozessstarts und Prozessbeendigungen - Threadaktivitäten - Laden von DLLs und Images - Profilierungsereignisse - Prozess-, Benutzer- und Sitzungsinformationen - zugehörige Aufrufstapel **Starten** ```cmd [TEST][PRIV][SENS] procmon.exe ``` Process Monitor beginnt normalerweise unmittelbar mit der Aufzeichnung. Deshalb sollte die Aufzeichnung zunächst angehalten und gezielt vorbereitet werden. **Empfohlene Grundreihenfolge** 1. Process Monitor starten. 2. Aufzeichnung anhalten. 3. bestehende Ereignisse leeren. 4. passende Filter festlegen. 5. Aufzeichnung starten. 6. Fehler möglichst genau reproduzieren. 7. Aufzeichnung sofort wieder anhalten. 8. relevante Ereignisse untersuchen. 9. Aufzeichnung im nativen PML-Format sichern. 10. sensible Inhalte vor einer Weitergabe prüfen. **Typische Filter** | Feld | Bedingung | Beispiel | |---|---|---| | Process Name | is | `anwendung.exe` | | PID | is | konkrete Prozess-ID | | Path | contains | Verzeichnis oder Registrypfad | | Operation | is | `CreateFile` | | Operation | is | `RegOpenKey` | | Result | is | `ACCESS DENIED` | | Result | is | `NAME NOT FOUND` | | User | is | betroffenes Benutzerkonto | | Duration | greater than | auffällig langsame Operationen | > Process Monitor zeichnet sehr viele normale und erwartete Vorgänge auf. Einzelne Meldungen wie `NAME NOT FOUND`, `PATH NOT FOUND` oder `ACCESS DENIED` sind nicht automatisch Fehlerursachen.
9. Process-Monitor-Ergebnisse richtig interpretieren **Häufige Ergebnisse** | Ergebnis | Grundbedeutung | |---|---| | `SUCCESS` | Operation wurde erfolgreich abgeschlossen | | `NAME NOT FOUND` | Angefragter Name wurde nicht gefunden | | `PATH NOT FOUND` | Ein Bestandteil des Pfades wurde nicht gefunden | | `ACCESS DENIED` | Zugriff wurde im verwendeten Kontext verweigert | | `SHARING VIOLATION` | Zugriff kollidiert mit einer bestehenden Freigabe oder geöffneten Datei | | `BUFFER OVERFLOW` | Puffer war für die erste Abfrage zu klein; kann Teil eines normalen Abfragemusters sein | | `NO MORE FILES` | Verzeichnisabfrage hat keine weiteren Ergebnisse | | `REPARSE` | Verarbeitung über einen Reparse Point | | `END OF FILE` | Dateiende erreicht | | `FILE LOCKED WITH ONLY READERS` | Sperrzustand der Datei | **Bewertungsfragen** - Gehört das Ereignis zum betroffenen Prozess? - Liegt es unmittelbar vor dem sichtbaren Fehler? - Wird nach einem fehlgeschlagenen Zugriff ein anderer Pfad erfolgreich verwendet? - Wiederholt sich das Ereignis ungewöhnlich häufig? - Ist der Pfad laut Anwendung tatsächlich erforderlich? - Welcher Benutzer führt den Zugriff aus? - Welche Berechtigungen gelten für das Objekt? - Handelt es sich um eine optionale Suche der Anwendung? - Gibt es einen zugehörigen Stack oder Folgefehler? - Tritt das Verhalten auf einem funktionierenden Vergleichssystem ebenfalls auf? **Wichtiger Grundsatz** Viele Programme suchen nacheinander an mehreren Stellen nach Dateien oder Registrywerten. Mehrere fehlgeschlagene Suchvorgänge können deshalb völlig normal sein, wenn anschließend ein erfolgreicher Treffer erfolgt.
10. Process Monitor per Befehlszeile einsetzen Process Monitor unterstützt Befehlszeilenoptionen für reproduzierbare Aufzeichnungen. **Lizenzdialog vorab akzeptieren** ```cmd [CHANGE] procmon.exe /AcceptEula ``` **Aufzeichnung mit Sicherungsdatei starten** ```cmd [TEST][PRIV][SENS] procmon.exe /AcceptEula /Quiet /BackingFile "C:\Diagnose\trace.pml" ``` **Laufende Process-Monitor-Instanz beenden** ```cmd [CHANGE][PRIV] procmon.exe /Terminate ``` **Gespeicherte PML-Datei als CSV exportieren** ```cmd [RO][SENS] procmon.exe /OpenLog "C:\Diagnose\trace.pml" /SaveAs "C:\Diagnose\trace.csv" ``` **Bootaufzeichnung** Process Monitor besitzt eine Boot-Logging-Funktion, mit der Aktivitäten während des Systemstarts erfasst werden können. Diese muss über die Programmoberfläche oder passend geplante Optionen kontrolliert aktiviert und anschließend wieder beendet werden. > Bootaufzeichnungen können sehr groß werden und sensible Systeminformationen enthalten. Sie dürfen nicht unbegrenzt aktiviert bleiben.
11. Autoruns – Autostarts vollständig untersuchen Autoruns zeigt deutlich mehr Autostartorte als die einfache Autostartansicht des Task-Managers. Dazu können gehören: - Anmeldeautostarts - Dienste - Treiber - geplante Aufgaben - Explorer-Erweiterungen - Winlogon-Komponenten - Boot-Execute-Einträge - Codecs - AppInit-DLLs - Image Hijacks - Office-Erweiterungen - Winsock-Komponenten - bekannte Registry-Autostartorte - Startordner verschiedener Benutzer **Starten** ```cmd [RO][PRIV][SENS] autoruns.exe ``` **Wichtige Funktionen** | Funktion | Zweck | |---|---| | Hide Microsoft Entries | Microsoft-Einträge ausblenden | | Hide Windows Entries | Windows-Einträge ausblenden | | Verify Code Signatures | digitale Signaturen prüfen | | Check VirusTotal | Hash beziehungsweise Datei über VirusTotal prüfen | | Jump to Entry | Registry- oder Dateisystemeintrag öffnen | | Jump to Image | zugehörige Datei öffnen | | Process Explorer | laufenden Prozess in Process Explorer öffnen | | Compare | aktuellen Zustand mit gespeicherter Ausgabe vergleichen | | User | Autostarts anderer Benutzer auswählen | **Sicheres Deaktivieren** Ein Kontrollkästchen kann deaktiviert werden, um einen Autostart vorübergehend abzuschalten. Das ist in der Regel besser reversibel als das sofortige Löschen des Eintrags. ```text Eintrag deaktivieren → System oder Anwendung kontrolliert testen → Ergebnis dokumentieren → Eintrag bei ausbleibender Wirkung wieder aktivieren ``` > Ein unbekannter oder nicht signierter Autostarteintrag ist nicht automatisch schädlich. Vor einer Änderung müssen Pfad, Herausgeber, Signatur, Zweck, Abhängigkeiten und betroffene Anwendung geprüft werden.
12. Autorunsc – Autostarts per Befehlszeile erfassen `Autorunsc` ist die Befehlszeilenversion von Autoruns und eignet sich für dokumentierbare Bestandsaufnahmen. **Grundlegende Ausgabe** ```cmd [RO][PRIV][SENS] autorunsc.exe -a * -c -h -s ``` Dabei können abhängig von der Werkzeugversion und den gewählten Optionen unter anderem Autostartkategorie, Pfad, Signatur und Hash ausgegeben werden. **CSV-Datei erzeugen** ```cmd [RO][PRIV][SENS] autorunsc.exe -a * -c -h -s > "C:\Diagnose\autoruns.csv" ``` **Nur Microsoft-Einträge ausblenden** ```cmd [RO][PRIV][SENS] autorunsc.exe -a * -m -c -h -s ``` **Vor einer produktiven Erfassung prüfen** ```cmd [RO] autorunsc.exe /? ``` > Die verfügbaren Parameter können sich mit Werkzeugversionen verändern. Vor automatisierter Verwendung muss die Hilfe der tatsächlich eingesetzten Version geprüft werden.
13. VirusTotal-Integration datenschutzgerecht verwenden Mehrere Sysinternals-Werkzeuge können Hashwerte oder Dateien mit VirusTotal abgleichen. Dabei muss unterschieden werden zwischen: - Übermittlung eines Hashwertes - Abfrage eines bereits bekannten Ergebnisses - Hochladen einer unbekannten Datei - automatischer Übermittlung unbekannter Dateien **Mögliche Risiken** - interne Dateinamen werden offengelegt - proprietäre Anwendungen werden hochgeladen - Konfigurationsdateien enthalten Geschäftsgeheimnisse - Dateien enthalten personenbezogene Daten - Skripte enthalten Servernamen oder Zugangsdaten - Upload verstößt gegen Unternehmensrichtlinien > Die Übermittlung einer internen Datei an einen externen Analysedienst darf nicht automatisch erfolgen. Vorher müssen Datenschutz, Geheimhaltung, Eigentumsrechte und Sicherheitsvorgaben geprüft werden. Ein VirusTotal-Ergebnis ist außerdem kein alleiniger Beweis: - einzelne Erkennung kann ein Fehlalarm sein - keine Erkennung schließt Schadsoftware nicht aus - Bewertung kann sich später ändern - signierte Dateien können trotzdem missbraucht werden
14. TCPView – Netzwerkverbindungen Prozessen zuordnen TCPView zeigt aktive TCP- und UDP-Endpunkte mit den zugehörigen Prozessen an. **Starten** ```cmd [RO][PRIV][SENS] tcpview.exe ``` **Typische Informationen** - Prozessname - PID - Protokoll - lokale Adresse - lokaler Port - entfernte Adresse - Remoteport - TCP-Zustand - gesendete und empfangene Daten - Erstellungszeitpunkt einer Verbindung **Typische Anwendungsfälle** - Welcher Prozess verbindet sich mit einem Server? - Welcher Prozess lauscht auf einem Port? - Warum existieren unerwartet viele Verbindungen? - Welche Remoteadresse verwendet eine Anwendung? - Ist der erwartete Dienstport geöffnet? - Welche Verbindung wird beim Start einer Anwendung aufgebaut? **Befehlszeilenversion** ```cmd [RO][PRIV][SENS] tcpvcon.exe -a -c ``` Vor der Verwendung sollte die lokale Hilfe geprüft werden: ```cmd [RO] tcpvcon.exe /? ``` > Eine Verbindung zu einer unbekannten IP-Adresse ist kein automatischer Sicherheitsvorfall. Content-Delivery-Netzwerke, Cloudplattformen, Telemetrie, Updates, Proxys und gemeinsam genutzte Infrastrukturen können die Zuordnung erschweren.
15. RAMMap – physischen Arbeitsspeicher analysieren RAMMap zeigt, wie Windows den physischen Arbeitsspeicher verwendet. **Starten** ```cmd [RO][PRIV][SENS] rammap.exe ``` **Wichtige Ansichten** | Ansicht | Inhalt | |---|---| | Use Counts | Speicher nach Verwendungsart | | Processes | Speicherzuordnung nach Prozessen | | Priority Summary | Speicher nach Prioritätsklassen | | Physical Pages | einzelne physische Speicherseiten | | Physical Ranges | physische Speicherbereiche | | File Summary | im Speicher gehaltene Dateidaten | | File Details | einzelne Dateiseiten | | Page Table | Speicher für Seitentabellen | **Wichtige Speicherbegriffe** | Begriff | Bedeutung | |---|---| | Active | aktuell verwendete Speicherseiten | | Standby | zwischengespeicherte Seiten, die bei Bedarf wiederverwendet werden können | | Modified | veränderte Seiten, die vor Wiederverwendung geschrieben werden müssen | | Free | unmittelbar freier Speicher | | Zeroed | gelöschte und zur Wiederverwendung vorbereitete Seiten | | Driver Locked | durch Treiber gesperrte Speicherseiten | | Metafile | Dateisystem-Metadaten im Cache | **Bewertungsregeln** - Wenig vollständig freier RAM ist nicht automatisch problematisch. - Windows nutzt freien Speicher gezielt als Cache. - Ein großer Standby-Bereich kann normal sein. - Hohe Commit-Nutzung muss zusammen mit Commit-Limit und Auslagerungsdatei bewertet werden. - Ein ungewöhnlich großer nicht ausgelagerter Pool kann auf einen Treiberfehler hindeuten. - Ein einzelner Snapshot beweist noch kein Speicherleck. RAMMap enthält Funktionen zum Leeren bestimmter Speicherlisten. Diese verändern den Speicherzustand und können die Leistung vorübergehend verschlechtern. > Speicherlisten dürfen nicht routinemäßig geleert werden, nur um eine niedrigere RAM-Anzeige zu erzeugen. Dadurch wird die Ursache eines Speicherproblems nicht behoben.
16. VMMap – virtuellen Speicher eines Prozesses untersuchen VMMap analysiert den virtuellen und physischen Speicher eines einzelnen Prozesses. **Starten** ```cmd [RO][PRIV][SENS] vmmap.exe ``` Anschließend wird ein laufender Prozess ausgewählt oder eine Anwendung durch VMMap gestartet. **Untersuchte Speicherarten** - Image - Heap - Stack - Private Data - Shareable - Mapped File - Page Table - Managed Heap - reservierter Adressraum - zugesicherter Speicher - Working Set **Typische Anwendungsfälle** - wächst der private Speicher fortlaufend? - welcher Heap wächst? - besitzt der Prozess ungewöhnlich viele Speicherabbildungen? - wird viel Adressraum nur reserviert? - wie unterscheiden sich zwei Zustände desselben Prozesses? - entsteht der Speicherverbrauch im nativen oder verwalteten Bereich? **Sinnvolle Vorgehensweise bei vermutetem Speicherleck** 1. Anwendung in einem definierten Ausgangszustand starten. 2. ersten VMMap-Snapshot erfassen. 3. reproduzierbare Aktion mehrfach ausführen. 4. zweiten Snapshot erfassen. 5. Snapshots vergleichen. 6. wachsende Speichertypen identifizieren. 7. Ergebnis mit Prozessmetriken, Dumps und Anwendungsprotokollen abgleichen. > Ein wachsender Working Set allein beweist kein Speicherleck. Caches und noch erreichbare, später freigegebene Daten können ebenfalls wachsen.
17. ProcDump – Speicherabbilder bei bestimmten Ereignissen erzeugen ProcDump kann Speicherabbilder eines Prozesses erzeugen, wenn festgelegte Bedingungen eintreten. Mögliche Auslöser sind unter anderem: - unbehandelte Ausnahme - Prozessabsturz - hohe CPU-Auslastung - niedrige CPU-Auslastung - nicht reagierendes Fenster - bestimmter Leistungsindikator - manuell angeforderter Dump - Prozessstart **Hilfe der installierten Version anzeigen** ```cmd [RO] procdump.exe -? ``` **Manuelles vollständiges Speicherabbild eines Prozesses** ```cmd [TEST][PRIV][SENS] procdump.exe -ma "C:\Diagnose" ``` **Auf Prozessnamen warten und vollständigen Dump bei Ausnahme erzeugen** ```cmd [TEST][PRIV][SENS] procdump.exe -ma -e -w "" "C:\Diagnose" ``` **Dump bei nicht reagierendem Fenster** ```cmd [TEST][PRIV][SENS] procdump.exe -ma -h "" "C:\Diagnose" ``` **Überwachung beenden** Die betreffende ProcDump-Instanz muss kontrolliert beendet werden, wenn die Diagnose abgeschlossen ist. **Wichtige Planungsfragen** - Wie viele Dumps dürfen entstehen? - Wie groß kann jeder Dump werden? - Ist ausreichend Speicherplatz vorhanden? - Tritt der Fehler in einem sensiblen Prozess auf? - Wer darf die Dumps lesen? - Wie lange werden sie gespeichert? - Welcher Debugger wird zur Analyse verwendet? > Vollständige Prozessabbilder können Passwörter, Tokens, Schlüssel, Dokumentinhalte, Datenbanksätze und andere Geheimnisse enthalten. Sie müssen wie hochsensible Daten geschützt werden.
18. Sysmon – sicherheitsrelevante Systemereignisse protokollieren System Monitor, kurz Sysmon, ist ein Windows-Systemdienst mit Gerätetreiber. Nach der Installation protokolliert er ausgewählte Systemaktivitäten in das Windows-Ereignisprotokoll. Sysmon kann abhängig von Version und Konfiguration unter anderem erfassen: - Prozessstarts - Prozessbeendigungen - Netzwerkverbindungen - Erstellung von Dateien - Änderung von Dateierstellungszeiten - Laden von Treibern - Laden von Images und DLLs - Zugriffe auf Prozesse - Registryereignisse - Named Pipes - DNS-Abfragen - WMI-Aktivitäten - Zwischenablageänderungen - Dateilöschungen - ausführbare Dateien in bestimmten Ereignissen - Änderungen an Sysmon selbst **Wichtiger Speicherort** ```text Anwendungs- und Dienstprotokolle → Microsoft → Windows → Sysmon → Operational ``` **Sysmon mit Konfiguration installieren** ```cmd [CHANGE][PRIV] sysmon.exe -accepteula -i "C:\Konfiguration\sysmon-config.xml" ``` **Konfiguration aktualisieren** ```cmd [CHANGE][PRIV] sysmon.exe -c "C:\Konfiguration\sysmon-config.xml" ``` **Aktuelle Konfiguration anzeigen** ```cmd [RO][PRIV][SENS] sysmon.exe -c ``` **Sysmon deinstallieren** ```cmd [CHANGE][PRIV] sysmon.exe -u ``` > Sysmon besitzt keine automatische Alarmierungs- oder Bewertungslogik. Die Ereignisse müssen durch geeignete Regeln, ein SIEM, ein EDR-System oder eine kontrollierte manuelle Analyse ausgewertet werden.
19. Sysmon-Konfiguration fachgerecht planen Eine Sysmon-Konfiguration bestimmt, welche Ereignisse einbezogen oder ausgeschlossen werden. **Ziele einer guten Konfiguration** - relevante Sicherheitsereignisse erfassen - unnötige Ereignismengen begrenzen - wichtige Systemprogramme nicht pauschal ausblenden - Regeln dokumentieren - Konfigurationsänderungen versionieren - Speicherbedarf und Ereignisrate überwachen - Auswertung durch SIEM oder Monitoring berücksichtigen **Risiken einer ungeprüften Konfiguration** - zu viele Ereignisse überlasten Sammlung und Auswertung - zu breite Ausschlüsse erzeugen blinde Flecken - sensible Befehlszeilen werden zentral gespeichert - DNS-Abfragen offenbaren Benutzeraktivitäten - Dateipfade enthalten personenbezogene Daten - Regeländerungen beeinflussen Erkennungsmechanismen - unterschiedliche Systeme benötigen unterschiedliche Filter **Beispiel einer minimalen XML-Grundstruktur** ```xml ``` Die erforderliche Schemaversion und die unterstützten Ereignisse müssen mit der tatsächlich verwendeten Sysmon-Version geprüft werden. **Konfigurationsschema anzeigen** ```cmd [RO] sysmon.exe -s ``` > Eine fremde Sysmon-Konfiguration sollte nicht ungeprüft in einer produktiven Umgebung übernommen werden. Sie muss an Systeme, Anwendungen, Datenschutz, Ereignissammlung und Erkennungsziele angepasst werden.
20. Sigcheck – Signaturen, Versionen und Hashwerte untersuchen Sigcheck zeigt Datei- und Signaturinformationen an. **Einzelne Datei untersuchen** ```cmd [RO][SENS] sigcheck.exe -a -h -i "" ``` **Verzeichnis rekursiv untersuchen** ```cmd [RO][SENS] sigcheck.exe -s -a -h "" ``` **Nicht signierte Dateien suchen** ```cmd [RO][SENS] sigcheck.exe -u -e "" ``` **CSV-Ausgabe** ```cmd [RO][SENS] sigcheck.exe -c -h "" ``` **Typische Prüfungen** - Herausgeber stimmt mit erwarteter Software überein - Signaturstatus ist gültig - Dateipfad ist plausibel - Produkt- und Dateiversion passen zusammen - Hash stimmt mit einer bekannten Referenz überein - Datei wurde nicht aus einem temporären oder Benutzerverzeichnis nachgeladen > Auch legitime Programme können unsignierte Komponenten besitzen. Umgekehrt kann eine gültig signierte Datei für unerwünschte Zwecke missbraucht oder mit einem kompromittierten Zertifikat signiert worden sein.
21. ListDLLs – geladene DLLs anzeigen ListDLLs zeigt geladene DLLs und deren Pfade an. **Alle geladenen DLLs anzeigen** ```cmd [RO][PRIV][SENS] listdlls.exe ``` **DLLs eines bestimmten Prozesses** ```cmd [RO][PRIV][SENS] listdlls.exe ``` Alternativ kann nach einem Prozessnamen gefiltert werden: ```cmd [RO][PRIV][SENS] listdlls.exe "" ``` **Nach einer bestimmten DLL suchen** ```cmd [RO][PRIV][SENS] listdlls.exe -d "" ``` **Typische Auffälligkeiten** - DLL aus einem unerwarteten Benutzerverzeichnis - mehrere Versionen derselben Komponente - DLL aus einem temporären Verzeichnis - fehlende oder ungültige Signatur - Prozess lädt nicht die erwartete Bibliothek - unerwartete Drittanbieter-Erweiterung > Der Dateiname allein ist nicht ausreichend. Pfad, Version, Signatur, Hash, Ladegrund und Anwendungskontext müssen gemeinsam bewertet werden.
22. Strings – lesbare Zeichenfolgen in Dateien suchen Strings extrahiert lesbare ANSI- und Unicode-Zeichenfolgen aus Binärdateien. **Datei untersuchen** ```cmd [RO][SENS] strings.exe "" ``` **Mindestlänge festlegen** ```cmd [RO][SENS] strings.exe -n 8 "" ``` **Ausgabe nach einem Begriff filtern** ```cmd [RO][SENS] strings.exe -n 8 "" | findstr /i "" ``` **Mögliche Anwendungsfälle** - eingebettete URLs finden - Fehlermeldungen erkennen - Dateipfade finden - Produkt- oder Debuginformationen erkennen - verdächtige Befehlszeilen entdecken - Hinweise auf eingebettete Konfigurationen erhalten **Einschränkungen** - komprimierte oder verschlüsselte Inhalte werden nicht automatisch verständlich - gefundene Zeichenfolge muss nicht ausgeführt oder verwendet werden - zufällige Bytefolgen können wie Text aussehen - Ausgabe kann Zugangsdaten oder andere Geheimnisse enthalten > Strings ist ein Hinweiswerkzeug und kein vollständiges Verfahren zur Malwareanalyse oder zum Reverse Engineering.
23. Streams – alternative NTFS-Datenströme untersuchen NTFS-Dateien können neben dem normalen Dateiinhalt alternative Datenströme besitzen. Windows verwendet solche Datenströme unter anderem für Herkunftsinformationen heruntergeladener Dateien. **Datenströme anzeigen** ```cmd [RO][SENS] streams.exe "" ``` **Verzeichnis rekursiv untersuchen** ```cmd [RO][SENS] streams.exe -s "" ``` **Alternative Datenströme löschen** ```cmd [CHANGE][DANGER] streams.exe -d "" ``` > Das pauschale Löschen alternativer Datenströme kann Sicherheitskennzeichnungen wie Herkunftsinformationen entfernen und dadurch Schutzfunktionen beeinflussen. Vorher müssen Inhalt, Zweck und Auswirkungen geprüft werden. PowerShell kann Datenströme ebenfalls anzeigen: ```powershell [RO][SENS] Get-Item "" -Stream * ```
24. AccessChk – effektive Zugriffsrechte untersuchen AccessChk zeigt Zugriffsrechte auf verschiedene Windows-Objekte an. Dazu gehören unter anderem: - Dateien - Verzeichnisse - Registryschlüssel - Dienste - Prozesse - Kernelobjekte - Freigaben - benannte Pipes **Hilfe anzeigen** ```cmd [RO] accesschk.exe /? ``` **Verzeichnisrechte untersuchen** ```cmd [RO][PRIV][SENS] accesschk.exe -d "" ``` **Rechte eines bestimmten Kontos prüfen** ```cmd [RO][PRIV][SENS] accesschk.exe -d "" "" ``` **Dienstrechte untersuchen** ```cmd [RO][PRIV][SENS] accesschk.exe -c "" ``` **Typische Anwendungsfälle** - besitzt ein Benutzer tatsächlich Schreibzugriff? - darf eine Gruppe einen Dienst konfigurieren? - existieren übermäßig weitreichende Rechte? - unterscheidet sich der Benutzerkontext vom Administratorkontext? - ist ein sensibles Verzeichnis für normale Benutzer beschreibbar? > AccessChk-Ausgaben müssen zusammen mit Vererbung, Gruppenmitgliedschaften, Integritätsstufe, Privilegien, Freigaberechten und dem tatsächlichen Benutzerkontext bewertet werden.
25. AccessEnum und ShareEnum **AccessEnum** AccessEnum stellt Berechtigungen für Dateien, Verzeichnisse und Registrybereiche übersichtlich dar. Es kann helfen, Abweichungen innerhalb größerer Strukturen zu finden. ```cmd [RO][PRIV][SENS] accessenum.exe ``` Typische Verwendung: - Verzeichnis oder Registrybereich auswählen - Berechtigungen erfassen - auffällige Abweichungen untersuchen - Zustand speichern - späteren Zustand vergleichen **ShareEnum** ShareEnum untersucht SMB-Freigaben und deren Sicherheitseinstellungen innerhalb erreichbarer Netzwerkbereiche. ```cmd [RO][PRIV][REMOTE][SENS] shareenum.exe ``` **Zu prüfen sind unter anderem** - unerwartete Freigaben - zu breite Freigabeberechtigungen - administrative Freigaben - erreichbare Systeme - Kombination aus Freigabe- und NTFS-Rechten - nicht mehr benötigte Freigaben > ShareEnum darf nur in ausdrücklich freigegebenen Netzwerkbereichen verwendet werden. Eine technische Erreichbarkeit ist keine Berechtigung zum Scannen.
26. PsTools – lokale und entfernte Administration PsTools ist eine Sammlung von Befehlszeilenwerkzeugen für lokale und entfernte Windows-Systeme. **Wichtige Werkzeuge** | Werkzeug | Hauptfunktion | |---|---| | PsExec | Prozess lokal oder remote starten | | PsInfo | Systeminformationen abrufen | | PsList | Prozesse und Threads anzeigen | | PsKill | Prozesse beenden | | PsService | Dienste anzeigen oder steuern | | PsLoggedOn | angemeldete Benutzer untersuchen | | PsLogList | Ereignisprotokolle ausgeben | | PsFile | remote geöffnete Dateien anzeigen | | PsPing | Netzwerklatenz und Durchsatz testen | | PsShutdown | Computer herunterfahren oder neu starten | | PsSuspend | Prozesse anhalten oder fortsetzen | | PsGetSid | SID eines Computers oder Kontos anzeigen | **Systeminformationen lokal abrufen** ```cmd [RO][SENS] psinfo.exe ``` **Systeminformationen remote abrufen** ```cmd [RO][REMOTE][SENS] psinfo.exe \\ ``` **Prozesse remote anzeigen** ```cmd [RO][REMOTE][SENS] pslist.exe \\ ``` **Angemeldete Benutzer untersuchen** ```cmd [RO][REMOTE][SENS] psloggedon.exe \\ ``` > PsTools können administrative Remoteaktionen ausführen. Authentifizierung, Firewall, administrative Freigaben, Sicherheitsrichtlinien, Protokollierung und Auswirkungen auf das Zielsystem müssen vorher geklärt werden.
27. PsExec sicher einsetzen PsExec kann Prozesse lokal oder auf entfernten Windows-Systemen starten. **Remote-Befehlszeile starten** ```cmd [CHANGE][PRIV][REMOTE][SENS] psexec.exe \\ cmd.exe ``` **Befehl remote ausführen** ```cmd [CHANGE][PRIV][REMOTE][SENS] psexec.exe \\ ipconfig /all ``` **Prozess als lokales Systemkonto starten** ```cmd [CHANGE][PRIV][DANGER] psexec.exe -s -i cmd.exe ``` Der letzte Befehl erzeugt einen besonders privilegierten Kontext und darf nur für klar begründete administrative Diagnosen verwendet werden. **Sicherheitsregeln** - keine Passwörter offen in der Befehlszeile übergeben - nur eindeutig bestimmten Zielcomputer verwenden - aktiven Benutzer und Auswirkungen prüfen - keine interaktive Sitzung unbeaufsichtigt lassen - erzeugte Dienste und Prozesse kontrollieren - Remotezugriff protokollieren - keine dauerhafte Umgehung regulärer Verwaltungswege - Befehle zunächst lokal oder in einer Testumgebung prüfen > Anmeldeinformationen in einer Befehlszeile können in Prozesslisten, Protokollen, Shellverläufen oder Diagnoseaufzeichnungen sichtbar werden.
28. PsPing – Netzwerkverbindungen und Leistung testen PsPing erweitert einfache Ping-Tests um TCP-Verbindungs-, Latenz- und Durchsatzmessungen. **ICMP-Test** ```cmd [TEST][SENS] psping.exe ``` **TCP-Port testen** ```cmd [TEST][SENS] psping.exe : ``` Beispiel: ```cmd [TEST][SENS] psping.exe server.example:443 ``` **Längere Messung** ```cmd [TEST][SENS] psping.exe -n 20 server.example:443 ``` Für Bandbreitenmessungen ist eine passende PsPing-Instanz als Empfänger erforderlich. Die genauen Parameter müssen anhand der Hilfe der eingesetzten Version gewählt werden: ```cmd [RO] psping.exe /? ``` **Bewertungsregeln** - TCP-Erreichbarkeit bestätigt nicht die korrekte Anwendung. - Durchsatztests erzeugen zusätzliche Netzlast. - Messergebnisse hängen von Gegenstelle, Route und Systemlast ab. - kurze Tests können sporadische Störungen übersehen. - Sicherheitssoftware kann Testverbindungen blockieren. - Tests gegen fremde Systeme benötigen eine Freigabe.
29. AD Explorer – Active Directory untersuchen AD Explorer ist ein grafischer Viewer und Editor für Active Directory. Das Werkzeug kann: - AD-Objekte durchsuchen - Attribute anzeigen - Objekteigenschaften untersuchen - Suchabfragen speichern - Snapshots einer AD-Datenbank erstellen - zwei Snapshots vergleichen - zugehörige Sicherheitsinformationen anzeigen **Starten** ```cmd [RO][PRIV][REMOTE][SENS] adexplorer.exe ``` **Typische Anwendungsfälle** - Attribut eines Benutzers oder Computers prüfen - Gruppenmitgliedschaften nachvollziehen - Distinguished Name kontrollieren - Replikations- oder Änderungsstände vergleichen - Objekte anhand bestimmter Attribute suchen - Zustand vor und nach einer administrativen Änderung vergleichen **Risiken** AD Explorer kann nicht nur lesen, sondern bei ausreichenden Rechten auch Objekte verändern. Ein versehentliches Ändern oder Löschen kann Domänendienste und Anwendungen beeinträchtigen. > Für reine Diagnosezwecke sollte nach Möglichkeit ein Konto mit nur den notwendigen Leserechten verwendet werden. Snapshots können enthalten: - Benutzernamen - Gruppenstrukturen - Computernamen - E-Mail-Adressen - organisatorische Strukturen - sicherheitsrelevante Attribute - interne Server- und Domäneninformationen Sie müssen entsprechend geschützt werden.
30. AD Insight und AD Restore **AD Insight** AD Insight überwacht LDAP-Clientaufrufe eines Prozesses und kann helfen, Active-Directory-Kommunikation einer Anwendung zu untersuchen. Typische Fragen: - Welche LDAP-Abfrage führt die Anwendung aus? - Welcher Domänencontroller wird angesprochen? - Welche Attribute werden angefordert? - Welche LDAP-Fehler treten auf? - Wiederholt eine Anwendung unnötig viele Abfragen? ```cmd [TEST][PRIV][SENS] adinsight.exe ``` Die Aufzeichnung kann sehr viele interne Verzeichnisinformationen enthalten. **AD Restore** AD Restore kann gelöschte Active-Directory-Objekte untersuchen und in unterstützten Fällen wiederherstellen. ```cmd [RO][PRIV][SENS] adrestore.exe ``` Eine tatsächliche Wiederherstellung verändert Active Directory: ```text [CHANGE][PRIV][DANGER] ``` > AD Restore darf nicht ohne Kenntnis von AD-Papierkorb, Tombstone-Zustand, Replikation, Objektabhängigkeiten, Wiederherstellungsziel und organisatorischer Freigabe eingesetzt werden.
31. Coreinfo – CPU- und Virtualisierungsfunktionen prüfen Coreinfo zeigt die Zuordnung logischer Prozessoren sowie unterstützte Prozessor- und Virtualisierungsfunktionen an. **Starten** ```cmd [RO] coreinfo.exe ``` **Virtualisierungsbezogene Informationen** ```cmd [RO] coreinfo.exe -v ``` **Typische Anwendungsfälle** - unterstützt die CPU benötigte Virtualisierungsfunktionen? - sind Funktionen durch Firmware oder Hypervisor beeinflusst? - wie sind logische Prozessoren, Kerne und NUMA-Knoten zugeordnet? - stehen benötigte Befehlssatzerweiterungen zur Verfügung? - unterscheidet sich ein System von einem funktionierenden Vergleichssystem? > Die Anzeige einer CPU-Funktion beweist nicht automatisch, dass sie von Firmware, Betriebssystem, Hypervisor und Anwendung vollständig nutzbar ist.
32. BgInfo – Systeminformationen auf dem Desktop anzeigen BgInfo kann technische Systeminformationen in den Desktophintergrund einblenden. Mögliche Angaben: - Computername - IP-Adresse - Betriebssystemversion - Domäne - Benutzer - letzter Startzeitpunkt - Prozessor - Arbeitsspeicher - freier Speicherplatz - benutzerdefinierte Werte **Starten** ```cmd [RO][SENS] bginfo.exe ``` BgInfo eignet sich beispielsweise für: - Schulungs- und Testsysteme - Serverkonsolen - virtuelle Maschinen - schnelle Identifikation eines Zielsystems - kontrollierte Supportumgebungen **Datenschutz beachten** Auf gemeinsam betrachteten Desktops dürfen keine unnötigen sensiblen Angaben angezeigt werden. Dazu gehören beispielsweise: - öffentliche IP-Adressen - interne Domänenstrukturen - personenbezogene Benutzerdaten - geheime Systemkennungen - vertrauliche Inventarnummern > BgInfo ist eine Anzeigehilfe und kein Werkzeug zur laufenden Zustandsüberwachung.
33. Disk2vhd – Datenträgerabbild als virtuelle Festplatte Disk2vhd erstellt virtuelle Festplattendateien aus Volumes eines laufenden Windows-Systems. Dafür kann der Volumeschattenkopie-Dienst verwendet werden, um einen konsistenteren Zeitpunkt abzubilden. **Starten** ```cmd [TEST][PRIV][SENS] disk2vhd.exe ``` **Mögliche Anwendungsfälle** - Testkopie eines Systems erstellen - System für eine kontrollierte Analyse virtualisieren - physisches System in eine virtuelle Testumgebung überführen - Zustand eines Systems vor umfangreicher Analyse sichern **Wichtige Grenzen** - eine VHD- oder VHDX-Datei ist nicht automatisch ein vollständiges Backupkonzept - laufende Anwendungen können zusätzliche Konsistenzanforderungen besitzen - Datenbanken benötigen möglicherweise anwendungsspezifische Sicherung - verschlüsselte Volumes müssen gesondert berücksichtigt werden - Aktivierung und Lizenzierung können sich in einer VM verändern - virtuelle Kopie darf nicht unkontrolliert parallel im produktiven Netzwerk starten - gespeicherte Anmeldeinformationen bleiben möglicherweise enthalten - die Datei kann nahezu alle Daten des Quellsystems enthalten > Eine virtualisierte Kopie eines Produktivsystems muss isoliert gestartet werden, damit keine doppelten Computerkonten, IP-Adressen, Dienste oder automatischen Aufgaben das Produktivnetz beeinflussen.
34. LiveKd – laufenden Kernel mit Debugger untersuchen LiveKd ermöglicht die Untersuchung eines laufenden Windows-Systems mit Microsoft-Kerneldebuggern, ohne die klassische Remote-Debuggingverbindung zu einem zweiten Computer aufzubauen. **Starten** ```cmd [TEST][PRIV][SENS] livekd.exe ``` Je nach Konfiguration wird ein kompatibler Microsoft-Debugger benötigt. **Mögliche Anwendungsfälle** - Kernelstrukturen untersuchen - Treiberzustände betrachten - Kernelstacks analysieren - Speicher- und Objektinformationen prüfen - Livezustand mit Debuggerbefehlen untersuchen **Grenzen** - das System verändert sich während der Untersuchung weiter - Daten können zwischen Abfragen inkonsistent werden - falsche Interpretation von Kernelstrukturen ist möglich - Symbole müssen zur Systemversion passen - Debuggerzugriff kann hochsensible Informationen offenlegen > LiveKd ist ein spezialisiertes Werkzeug für fortgeschrittene Windows- und Treiberanalyse. Es sollte nicht ohne Debuggingkenntnisse auf produktiven Systemen eingesetzt werden.
35. WinObj – Windows-Objektmanager untersuchen WinObj zeigt den Namensraum des Windows-Objektmanagers. Darin können unter anderem sichtbar sein: - Geräteobjekte - symbolische Links - Sessions - Treiberobjekte - Named Pipes - BaseNamedObjects - Dateisystemobjekte - Kernelobjekte **Starten** ```cmd [RO][PRIV][SENS] winobj.exe ``` **Typische Anwendungsfälle** - symbolische Objektverknüpfungen untersuchen - Gerätedateien und Treiberobjekte nachvollziehen - benannte Synchronisationsobjekte finden - Unterschiede zwischen Sitzungen erkennen - interne Objektpfade einer Anwendung prüfen > WinObj zeigt interne Windows-Objekte. Die bloße Existenz eines unbekannten Objekts ist kein Beweis für einen Fehler oder eine Kompromittierung.
36. PendMoves und MoveFile – Dateioperationen beim Neustart Wenn Dateien während des laufenden Betriebs nicht ersetzt oder gelöscht werden können, kann Windows Operationen für den nächsten Systemstart vormerken. **Ausstehende Operationen anzeigen** ```cmd [RO][PRIV][SENS] pendmoves.exe ``` **Datei beim nächsten Neustart verschieben** ```cmd [CHANGE][PRIV][RESTART] movefile.exe "" "" ``` **Datei beim nächsten Neustart löschen** ```cmd [CHANGE][PRIV][RESTART][DANGER] movefile.exe "" "" ``` **Risiken** - falsche Systemdatei wird entfernt - Anwendung startet nach Neustart nicht mehr - Treiber oder Dienst fällt aus - Abhängigkeiten werden erst nach Neustart sichtbar - Rücknahme ist nach dem Start möglicherweise schwierig > Vor dem Vormerken einer Löschung müssen Datei, Hersteller, Signatur, Anwendung, Wiederherstellungsweg und Auswirkungen eindeutig geklärt sein.
37. SDelete – sicher überschreiben SDelete kann Dateien oder freien Speicherplatz überschreiben, um die Wiederherstellung gelöschter Daten zu erschweren. **Hilfe anzeigen** ```cmd [RO] sdelete.exe /? ``` **Datei sicher löschen** ```cmd [CHANGE][PRIV][DANGER] sdelete.exe "" ``` **Freien Speicherplatz bearbeiten** ```cmd [CHANGE][PRIV][DANGER] sdelete.exe -c ``` **Wichtige Einschränkungen** - SSDs besitzen Wear-Leveling und interne Speicherverwaltung - Speichercontroller können Daten umorganisieren - virtuelle Datenträger besitzen zusätzliche Speicherschichten - Snapshots und Backups bleiben unberührt - Cloud- und SAN-Speicher abstrahieren die physische Ablage - falscher Zielpfad kann nicht einfach rückgängig gemacht werden > SDelete ist keine allgemeine Fehlerbehebungsmaßnahme. Vor dem Einsatz müssen Datenträgertyp, Sicherungen, Snapshots, Aufbewahrungspflichten und Löschkonzept geprüft werden.
38. NotMyFault nur in isolierten Testsystemen verwenden NotMyFault kann absichtlich: - Systemabstürze auslösen - Systeme aufhängen - Kernel-Speicherlecks erzeugen - Treiberfehler simulieren - hohe Last erzeugen Das Werkzeug dient beispielsweise zum Testen von: - Speicherabbildkonfiguration - Überwachungssystemen - Wiederanlaufverhalten - Absturzanalysen - Laborübungen ```cmd [DANGER][PRIV][RESTART] notmyfault.exe ``` > NotMyFault darf niemals auf einem produktiven System, einem gemeinsam genutzten Schulungssystem oder einem nicht vollständig isolierten Testsystem ausprobiert werden. Es verursacht absichtlich schwerwiegende Störungen. Vor einem Test müssen mindestens vorhanden sein: - isolierte virtuelle Maschine - aktueller Snapshot oder definierter Wiederherstellungsweg - keine produktiven Daten - kein Zugang zum Produktivnetz - dokumentiertes Testszenario - Kontrolle über Neustart und Speicherabbilder - ausreichend Speicherplatz - ausdrückliche Freigabe
39. Geeignetes Werkzeug nach Fehlerbild auswählen | Fehlerbild | Geeignete Werkzeuge | |---|---| | Datei lässt sich nicht löschen | Process Explorer, Handle | | Anwendung startet nicht | Process Monitor, Autoruns, Ereignisanzeige | | Anwendung findet Datei nicht | Process Monitor | | Zugriff verweigert | Process Monitor, AccessChk, AccessEnum | | hohe CPU-Auslastung | Process Explorer, ProcDump, Leistungsüberwachung | | wachsender RAM-Verbrauch | Process Explorer, VMMap, RAMMap, ProcDump | | unbekannter Autostart | Autoruns, Sigcheck, Process Explorer | | unbekannte Netzwerkverbindung | TCPView, Process Explorer, Sigcheck | | sporadischer Absturz | ProcDump, Ereignisanzeige, WinDbg | | unbekannte DLL | Process Explorer, ListDLLs, Sigcheck | | verdächtige Datei | Sigcheck, Strings, Streams | | Active-Directory-Abfrage fehlerhaft | AD Explorer, AD Insight | | Remoteprozess untersuchen | PsList, PsInfo, PsLoggedOn | | TCP-Latenz oder Durchsatz | PsPing | | Kernel- oder Treiberproblem | LiveKd, WinDbg, Process Monitor | | Startproblem durch Zusatzsoftware | Autoruns, Process Monitor Boot Logging | | Speicheraufteilung unklar | RAMMap | | Prozessspeicher im Detail | VMMap | | ausstehende Dateilöschung | PendMoves | | CPU-Funktion oder Virtualisierung | Coreinfo | | Systemkopie für Laboranalyse | Disk2vhd |
40. Typischer Ablauf einer Sysinternals-Analyse 1. Originale Fehlermeldung erfassen. 2. Fehlerzeitpunkt dokumentieren. 3. betroffenen Computer und Benutzer bestätigen. 4. Reproduzierbarkeit prüfen. 5. integrierte Windows-Protokolle untersuchen. 6. kleinstes passende Sysinternals-Werkzeug auswählen. 7. Werkzeugquelle, Version und Signatur kontrollieren. 8. Berechtigungsbedarf prüfen. 9. mögliche sensible Daten berücksichtigen. 10. Aufzeichnung vorbereiten. 11. Filter möglichst eng festlegen. 12. Ausgangszustand dokumentieren. 13. Aufzeichnung starten. 14. Fehler einmal reproduzieren. 15. Aufzeichnung unmittelbar beenden. 16. Ereignisse zeitlich eingrenzen. 17. Prozess, Pfad, Benutzer, Operation und Ergebnis vergleichen. 18. normale Such- und Fehlversuche von relevanten Fehlern unterscheiden. 19. Befund mit Ereignisanzeige und Anwendungsprotokollen abgleichen. 20. Hypothese formulieren. 21. möglichst kleinen und reversiblen Test planen. 22. Sicherung und Rückfallplan prüfen. 23. Änderung durchführen. 24. Funktion erneut testen. 25. Diagnosewerkzeuge und temporäre Überwachung beenden. 26. Daten geschützt speichern oder ordnungsgemäß löschen. 27. Ursache, Maßnahme und Ergebnis dokumentieren.
41. Beispiel – Anwendung meldet „Datei nicht gefunden“ **Ausgangslage** Eine Anwendung meldet beim Start, eine Konfigurationsdatei sei nicht vorhanden. Die Datei ist im erwarteten Verzeichnis sichtbar. **Vorgehensweise** 1. tatsächlichen Anwendungsprozess bestimmen. 2. Process Monitor starten. 3. Aufzeichnung anhalten und leeren. 4. Filter auf den Prozessnamen setzen. 5. optional nach einem Teil des Dateinamens filtern. 6. Aufzeichnung starten. 7. Fehler reproduzieren. 8. Aufzeichnung beenden. 9. Operationen wie `CreateFile` untersuchen. 10. tatsächlich abgefragten Pfad prüfen. 11. Benutzerkontext kontrollieren. 12. Ergebnisse vor und nach dem Fehler vergleichen. **Mögliche Befunde** - Anwendung sucht in einem anderen Verzeichnis. - Umgebungsvariable führt zu einem falschen Pfad. - Dateiname oder Erweiterung weicht ab. - Zugriff wird verweigert und als „nicht gefunden“ dargestellt. - Anwendung läuft unter einem Dienstkonto. - Datei wird zuerst gefunden, aber eine abhängige Datei fehlt. - Registrywert enthält einen veralteten Pfad. - 32-Bit- und 64-Bit-Dateisystemumleitung beeinflusst den Zugriff. **Geeignete Ergänzungen** - Process Explorer für Benutzer und Befehlszeile - AccessChk für Berechtigungen - Sigcheck für die Anwendungsdatei - Ereignisanzeige für Folgefehler
42. Beispiel – Anwendung verbraucht immer mehr Arbeitsspeicher **Vorgehensweise** 1. Ausgangswert im Task-Manager oder mit PowerShell erfassen. 2. Process Explorer zur Beobachtung verwenden. 3. Private Bytes, Working Set und Commit unterscheiden. 4. VMMap-Snapshot im Ausgangszustand speichern. 5. reproduzierbare Benutzeraktion mehrfach ausführen. 6. zweiten VMMap-Snapshot erstellen. 7. wachsende Speicherart bestimmen. 8. bei Bedarf ProcDump kontrolliert konfigurieren. 9. Speicherabbild mit geeignetem Debugger untersuchen. 10. Anwendungsversion und bekannte Fehler des Herstellers prüfen. **Nicht ausreichend als Beweis** - RAM-Anzeige steigt einmalig - Working Set sinkt nicht sofort - freier Speicher wird kleiner - RAMMap zeigt großen Standby-Cache - Prozess besitzt viele Speicherabbildungen **Stärkerer Hinweis auf ein Leck** Ein bestimmter Speicherbereich wächst bei wiederholbarer identischer Aktion fortlaufend, wird nicht wieder freigegeben und korreliert mit der Störung.
43. Beispiel – langsamer Anwendungsstart **Geeignete Werkzeuge** - Process Monitor - Process Explorer - Autoruns - Ereignisanzeige - Leistungsüberwachung - ProcDump bei Hängern **Vorgehensweise** 1. Startzeit reproduzierbar messen. 2. Process Monitor vorbereiten. 3. nur den Startvorgang aufzeichnen. 4. Ereignisse nach Dauer untersuchen. 5. wiederholte Datei- oder Registryzugriffe identifizieren. 6. Netzwerkpfade und Namensauflösung beachten. 7. untergeordnete Prozesse im Process Tree prüfen. 8. Signaturen und Pfade geladener Komponenten kontrollieren. 9. Ergebnis mit einem funktionierenden System vergleichen. **Mögliche Ursachen** - nicht erreichbarer Netzwerkpfad - langsame DNS-Auflösung - wiederholte Zertifikatsprüfung - blockierende Sicherheitssoftware - fehlende Datei mit wiederholten Suchversuchen - langsame Benutzerprofilkomponente - fehlerhafte Shell-Erweiterung - veraltete Autostartkomponente - stark ausgelasteter Datenträger - Drittanbieter-DLL - nicht erreichbarer Lizenzserver
44. Gefährliche Fehlinterpretationen vermeiden | Beobachtung | Nicht automatisch bewiesen | |---|---| | Prozess ist nicht signiert | Prozess ist Schadsoftware | | VirusTotal zeigt einen Treffer | Datei ist eindeutig schädlich | | VirusTotal zeigt keinen Treffer | Datei ist sicher | | Process Monitor zeigt `ACCESS DENIED` | Dieser Zugriff verursacht den Fehler | | Process Monitor zeigt `NAME NOT FOUND` | Die Datei fehlt fehlerhaft | | hohe Zahl offener Handles | Handle-Leck | | viele TCP-Verbindungen | Angriff oder Schadsoftware | | unbekannte Remote-IP | unberechtigter Datenverkehr | | hoher Standby-Speicher | Arbeitsspeichermangel | | Prozess besitzt hohen Working Set | Speicherleck | | DLL liegt im Benutzerprofil | DLL ist bösartig | | Autostarteintrag ist unbekannt | Eintrag darf gelöscht werden | | Sysmon erzeugt kein Ereignis | Aktivität fand nicht statt | | Prozess läuft als SYSTEM | Prozess ist legitim | | Datei besitzt Microsoft im Namen | Datei stammt von Microsoft |
45. Diagnosedaten sicher speichern und weitergeben Sysinternals-Ausgaben können enthalten: - Benutzernamen - Computer- und Domänennamen - IP-Adressen - Dateipfade - Befehlszeilen - Prozessumgebungen - Registrywerte - geöffnete Dokumente - Netzwerkziele - Sicherheitskennungen - Anmeldesitzungen - E-Mail-Adressen - Tokens und Zugangsdaten - Datei- und Speicherinhalte - Active-Directory-Strukturen **Vor der Weitergabe** 1. Empfänger und Zweck bestimmen. 2. erforderlichen Datenumfang begrenzen. 3. Datei auf Geheimnisse prüfen. 4. personenbezogene Daten redigieren. 5. verschlüsselten Übertragungsweg verwenden. 6. Zugriffsrechte beschränken. 7. Aufbewahrungsdauer festlegen. 8. Löschung dokumentieren. 9. öffentliche Uploadplattformen vermeiden. 10. Speicherabbilder besonders schützen. **Besonders sensible Dateitypen** | Dateityp | Risiko | |---|---| | PML-Aufzeichnung | Pfade, Registry, Prozesse, Benutzer und Aktivitäten | | Prozessdump | vollständige Speicherinhalte des Prozesses | | Kernel-Dump | umfangreiche System- und Speicherinformationen | | AD-Explorer-Snapshot | Verzeichnisstruktur und Objektattribute | | Autoruns-Export | Softwarebestand, Pfade und Autostarts | | TCPView-Export | Netzwerkziele und Prozesszuordnung | | Sysmon-Protokoll | Befehlszeilen, Hashwerte, DNS- und Netzwerkaktivität |
46. Schnelle Werkzeugübersicht | Aufgabe | Werkzeug | |---|---| | Prozesshierarchie anzeigen | Process Explorer | | offene Datei finden | Process Explorer, Handle | | geladene DLLs prüfen | Process Explorer, ListDLLs | | Datei- und Registryzugriffe verfolgen | Process Monitor | | Bootaktivität aufzeichnen | Process Monitor | | Autostarts untersuchen | Autoruns | | Autostarts exportieren | Autorunsc | | Netzwerkverbindungen zuordnen | TCPView | | physische RAM-Nutzung analysieren | RAMMap | | Prozessspeicher analysieren | VMMap | | Prozessdump erstellen | ProcDump | | dauerhafte Sicherheitsereignisse erfassen | Sysmon | | Signatur und Hash prüfen | Sigcheck | | lesbare Binärdateiinhalte finden | Strings | | alternative NTFS-Datenströme anzeigen | Streams | | Berechtigungen untersuchen | AccessChk | | Berechtigungsabweichungen suchen | AccessEnum | | Freigaben untersuchen | ShareEnum | | Remoteprozesse starten | PsExec | | Remoteprozesse anzeigen | PsList | | Systeminformationen remote abrufen | PsInfo | | angemeldete Benutzer prüfen | PsLoggedOn | | Netzwerklatenz testen | PsPing | | Active Directory durchsuchen | AD Explorer | | LDAP-Aufrufe verfolgen | AD Insight | | gelöschte AD-Objekte untersuchen | AD Restore | | CPU-Funktionen anzeigen | Coreinfo | | Systemdaten auf Desktop anzeigen | BgInfo | | virtuelle Systemkopie erstellen | Disk2vhd | | laufenden Kernel untersuchen | LiveKd | | Objektmanager anzeigen | WinObj | | ausstehende Dateioperationen anzeigen | PendMoves | | Dateioperation für Neustart planen | MoveFile | | Daten sicher überschreiben | SDelete | | Absturz absichtlich erzeugen | NotMyFault – nur isoliertes Labor |
47. Dokumentationsvorlage ```text Ticket: Datum und Uhrzeit: Bearbeiter: Computername: Windows-Version: Build: Architektur: Benutzerkontext: Betroffener Prozess: PID: Prozesspfad: Befehlszeile: Prozessherausgeber: Signaturstatus: Originale Fehlermeldung: Fehlerzeitpunkt: Reproduzierbar: Reproduktionsschritte: Letzte funktionierende Nutzung: Letzte Änderung: Verwendetes Sysinternals-Werkzeug: Werkzeugversion: Bezugsquelle: Hash des Werkzeugs: Erhöht ausgeführt: Startzeit der Aufzeichnung: Endzeit der Aufzeichnung: Verwendete Filter: Verwendete Befehlszeile: Speicherort der Diagnosedaten: Relevanter Prozess: Übergeordneter Prozess: Benutzer: Operation: Objekt oder Pfad: Ergebnis: Zeitlicher Zusammenhang: Vergleichssystem geprüft: Normales Verhalten ausgeschlossen: Autostarteintrag: Signatur: Hash: VirusTotal verwendet: Datei hochgeladen: Freigabe für externen Dienst vorhanden: Lokale Adresse: Lokaler Port: Remoteadresse: Remoteport: Verbindungsstatus: Zugehöriger Prozess: RAM-Ausgangswert: RAM-Endwert: Working Set: Private Bytes: Commit: Wachsende Speicherart: Dump erzeugt: Dump-Typ: Dump-Größe: Dump geschützt gespeichert: Sysmon-Konfiguration: Sysmon-Ereignis-ID: Ereignisquelle: SIEM-Abfrage: Vermutete Ursache: Zusätzliche Datenquelle: Geplante Änderung: Sicherung geprüft: Rückfallplan: Änderung durchgeführt: Neustart erforderlich: Ergebnis nach Änderung: Fehler erneut getestet: Monitoring kontrolliert: Temporäre Aufzeichnung beendet: Diagnosedaten redigiert: Aufbewahrungsfrist: Abschluss: ```
--- **Merksatz** > Sysinternals macht interne Windows-Abläufe sichtbar, bestimmt aber nicht automatisch deren Bedeutung. Erst die Verbindung aus Fehlerzeitpunkt, Prozess, Benutzerkontext, Pfad, Operation, Ergebnis, Systemzustand und Vergleichsdaten ermöglicht eine belastbare Ursachenanalyse. **Quellen und weiterführende Dokumentation** - [Microsoft Learn – Sysinternals](https://learn.microsoft.com/sysinternals/) - [Microsoft Learn – Sysinternals Utilities](https://learn.microsoft.com/sysinternals/downloads/) - [Microsoft Learn – Sysinternals Suite](https://learn.microsoft.com/sysinternals/downloads/sysinternals-suite) - [Microsoft Learn – Sysinternals Live](https://learn.microsoft.com/sysinternals/) - [Microsoft Learn – Sysinternals Suite im Microsoft Store](https://learn.microsoft.com/sysinternals/downloads/microsoft-store) - [Microsoft Learn – Process Explorer](https://learn.microsoft.com/sysinternals/downloads/process-explorer) - [Microsoft Learn – Process Monitor](https://learn.microsoft.com/sysinternals/downloads/procmon) - [Microsoft Learn – Autoruns](https://learn.microsoft.com/sysinternals/downloads/autoruns) - [Microsoft Learn – Handle](https://learn.microsoft.com/sysinternals/downloads/handle) - [Microsoft Learn – TCPView](https://learn.microsoft.com/sysinternals/downloads/tcpview) - [Microsoft Learn – RAMMap](https://learn.microsoft.com/sysinternals/downloads/rammap) - [Microsoft Learn – VMMap](https://learn.microsoft.com/sysinternals/downloads/vmmap) - [Microsoft Learn – ProcDump](https://learn.microsoft.com/sysinternals/downloads/procdump) - [Microsoft Learn – Sysmon](https://learn.microsoft.com/sysinternals/downloads/sysmon) - [Microsoft Learn – Sigcheck](https://learn.microsoft.com/sysinternals/downloads/sigcheck) - [Microsoft Learn – ListDLLs](https://learn.microsoft.com/sysinternals/downloads/listdlls) - [Microsoft Learn – Strings](https://learn.microsoft.com/sysinternals/downloads/strings) - [Microsoft Learn – Streams](https://learn.microsoft.com/sysinternals/downloads/streams) - [Microsoft Learn – AccessChk](https://learn.microsoft.com/sysinternals/downloads/accesschk) - [Microsoft Learn – AccessEnum](https://learn.microsoft.com/sysinternals/downloads/accessenum) - [Microsoft Learn – ShareEnum](https://learn.microsoft.com/sysinternals/downloads/shareenum) - [Microsoft Learn – PsTools](https://learn.microsoft.com/sysinternals/downloads/pstools) - [Microsoft Learn – PsExec](https://learn.microsoft.com/sysinternals/downloads/psexec) - [Microsoft Learn – PsPing](https://learn.microsoft.com/sysinternals/downloads/psping) - [Microsoft Learn – AD Explorer](https://learn.microsoft.com/sysinternals/downloads/adexplorer) - [Microsoft Learn – AD Insight](https://learn.microsoft.com/sysinternals/downloads/adinsight) - [Microsoft Learn – Coreinfo](https://learn.microsoft.com/sysinternals/downloads/coreinfo) - [Microsoft Learn – BgInfo](https://learn.microsoft.com/sysinternals/downloads/bginfo) - [Microsoft Learn – Disk2vhd](https://learn.microsoft.com/sysinternals/downloads/disk2vhd) - [Microsoft Learn – LiveKd](https://learn.microsoft.com/sysinternals/downloads/livekd) - [Microsoft Learn – WinObj](https://learn.microsoft.com/sysinternals/downloads/winobj) - [Microsoft Learn – PendMoves und MoveFile](https://learn.microsoft.com/sysinternals/downloads/pendmoves) - [Microsoft Learn – SDelete](https://learn.microsoft.com/sysinternals/downloads/sdelete) - [Microsoft Learn – NotMyFault](https://learn.microsoft.com/sysinternals/downloads/notmyfault) - [Microsoft Learn – Troubleshooting with the Windows Sysinternals Tools](https://learn.microsoft.com/sysinternals/resources/troubleshooting-book) # 5.3 Windows Server, Active Directory und Gruppenrichtlinien Windows-Server-Infrastrukturen bestehen häufig aus mehreren voneinander abhängigen Diensten. Eine Störung bei Anmeldung, Gruppenrichtlinien, Namensauflösung oder Dateizugriff kann deshalb ihre eigentliche Ursache in einem anderen Teilbereich haben. Typische Abhängigkeiten sind: - Active Directory Domain Services - DNS - Kerberos - Netlogon - Zeitsynchronisation - AD-Replikation - SYSVOL-Replikation - Gruppenrichtlinien - DHCP - DFS und DFS-Replikation - Zertifikatsdienste - Netzwerkverbindungen und Firewalls - Failovercluster - Serverrollen und deren Datenbanken Ein erfolgreicher Ping beweist weder eine funktionierende Domänenanmeldung noch eine fehlerfreie AD-Replikation. Ebenso beweist eine erfolgreiche Anmeldung nicht, dass alle Gruppenrichtlinien, DNS-Zonen oder Verzeichnisänderungen korrekt repliziert wurden. --- **Kennzeichnung der Befehle** | Kennzeichnung | Bedeutung | |---|---| | `[RO]` | grundsätzlich nur lesende Diagnose | | `[TEST]` | erzeugt Testzugriffe oder zusätzliche Protokolle | | `[CHANGE]` | verändert Konfiguration, Cache oder Systemzustand | | `[PRIV]` | erhöhte oder administrative Rechte erforderlich beziehungsweise sinnvoll | | `[REMOTE]` | greift auf einen anderen Computer oder Dienst zu | | `[SENS]` | Ausgabe kann interne oder personenbezogene Informationen enthalten | | `[LOG]` | kann umfangreiche zusätzliche Protokolldaten erzeugen | | `[DANGER]` | fehlerhafte Verwendung kann größere Störungen verursachen | | `[RESTART]` | kann einen Neustart oder eine Dienstunterbrechung erfordern | Die Kennzeichnungen sind Sicherheitshinweise dieser Dokumentation und nicht Bestandteil der eigentlichen Befehle. ---
1. Abhängigkeiten einer Windows-Domäne verstehen Eine typische Domänenanmeldung umfasst mehrere Schritte: 1. Der Client ermittelt über DNS einen geeigneten Domain Controller. 2. Der DC-Locator berücksichtigt Domäne, Standort und verfügbare Dienste. 3. Client und Domain Controller prüfen ihre Vertrauensbeziehung. 4. Kerberos oder NTLM authentifiziert den Benutzer. 5. Active Directory liefert Benutzer-, Computer- und Gruppeninformationen. 6. SYSVOL stellt Gruppenrichtliniendateien und Anmeldeskripte bereit. 7. Der Gruppenrichtliniendienst ermittelt und verarbeitet passende GPOs. 8. Weitere Dienste stellen Profile, Laufwerke, Drucker oder Anwendungen bereit. Daraus ergibt sich eine wichtige Diagnose-Reihenfolge: 1. lokaler Netzwerkzustand 2. IP-Konfiguration 3. DNS-Clientkonfiguration 4. DNS-Auflösung der Domänendienste 5. Erreichbarkeit eines geeigneten Domain Controllers 6. Uhrzeit und Zeitzone 7. Secure Channel 8. Kerberos-Tickets und SPNs 9. AD-Replikation 10. SYSVOL und DFS-Replikation 11. Gruppenrichtlinienverarbeitung 12. abhängige Serverrollen > In Active Directory ist DNS Bestandteil der Dienstermittlung. Ein Client, der ausschließlich einen öffentlichen DNS-Server verwendet, kann zwar Internetnamen auflösen, aber normalerweise die internen Domänendienste nicht korrekt ermitteln.
2. Diagnosekontext und Ausgangslage dokumentieren Vor der ersten Änderung müssen mindestens folgende Angaben erfasst werden: - betroffener Benutzer - betroffener Computer - Domänenname - Active-Directory-Standort - verwendeter Domain Controller - Zeitpunkt des Fehlers - originale Fehlermeldung - betroffene Anwendung oder Ressource - einmalige oder wiederkehrende Störung - Anzahl betroffener Systeme - letzte bekannte funktionierende Nutzung - letzte administrative Änderung - kürzlich installierte Updates - Netzwerksegment und VPN-Zustand - Anmeldung lokal, zwischengespeichert oder gegen einen Domain Controller - administrative oder normale Benutzersitzung **Grundinformationen auf einem Client** ```cmd [RO][SENS] hostname [RO][SENS] whoami [RO][SENS] whoami /upn [RO][SENS] whoami /user [RO][SENS] whoami /groups [RO][SENS] systeminfo [RO][SENS] ipconfig /all ``` **Domäneninformationen mit PowerShell** ```powershell [RO][SENS] Get-CimInstance Win32_ComputerSystem | Select-Object Name, Domain, PartOfDomain ``` **Anmelde- und Logonserver-Variablen** ```cmd [RO][SENS] set LOGONSERVER [RO][SENS] set USERDNSDOMAIN [RO][SENS] set USERDOMAIN ``` > Die Variable `LOGONSERVER` ist ein nützlicher Hinweis, aber keine vollständige Aussage darüber, welcher Domain Controller bei allen späteren LDAP-, Kerberos-, DNS- oder GPO-Vorgängen verwendet wird.
3. Ereignisprotokolle gezielt untersuchen Wichtige Protokolle befinden sich in der Ereignisanzeige unter: ```text Ereignisanzeige ├── Windows-Protokolle │ ├── Anwendung │ ├── Sicherheit │ └── System └── Anwendungs- und Dienstprotokolle └── Microsoft └── Windows ``` Relevante Protokollbereiche können sein: - ActiveDirectory_DomainService - DNS-Server - Directory Service - DFS Replication - GroupPolicy - Kerberos - KDC - Netlogon - Time-Service - DHCP-Server - FailoverClustering - ServerManager - CertificateServicesClient - TerminalServices - SMBClient und SMBServer **GroupPolicy-Betriebsprotokoll** ```text Anwendungs- und Dienstprotokolle └── Microsoft └── Windows └── GroupPolicy └── Operational ``` **Ereignisse per PowerShell abrufen** ```powershell [RO][PRIV][SENS] Get-WinEvent -LogName System -MaxEvents 100 ``` ```powershell [RO][PRIV][SENS] Get-WinEvent -LogName "Microsoft-Windows-GroupPolicy/Operational" -MaxEvents 100 ``` **Nach Zeitraum und Ebene filtern** ```powershell [RO][PRIV][SENS] Get-WinEvent -FilterHashtable @{ LogName = "System" StartTime = (Get-Date).AddHours(-2) Level = 2,3 } ``` **Verfügbare Protokolle suchen** ```powershell [RO][SENS] Get-WinEvent -ListLog * | Where-Object LogName -match "GroupPolicy|DNS|DFS|Kerberos|Netlogon|Failover" ``` > Ereignis-IDs dürfen nicht isoliert interpretiert werden. Quelle, Windows-Version, Ereignistext, Fehlercode, Zeitpunkt und begleitende Ereignisse müssen gemeinsam ausgewertet werden.
4. Domain Controller mit DCDiag prüfen `dcdiag` führt verschiedene Tests für Domain Controller aus. Abhängig von den Parametern werden unter anderem Erreichbarkeit, DNS, Replikation, Dienste, Rolleninhaber und Verzeichnispartitionen geprüft. **Grundprüfung des lokalen Domain Controllers** ```cmd [TEST][PRIV][SENS] dcdiag ``` **Ausführliche Ausgabe** ```cmd [TEST][PRIV][SENS] dcdiag /v ``` **Bestimmten Domain Controller prüfen** ```cmd [TEST][PRIV][REMOTE][SENS] dcdiag /s: ``` **Alle Domain Controller des Unternehmensbereichs prüfen** ```cmd [TEST][PRIV][REMOTE][SENS] dcdiag /e ``` **DNS-Tests ausführen** ```cmd [TEST][PRIV][REMOTE][SENS] dcdiag /test:DNS /e /v ``` **Bestimmten Test ausführen** ```cmd [TEST][PRIV][SENS] dcdiag /test: ``` **Ausgabe in Dateien schreiben** ```cmd [TEST][PRIV][SENS] dcdiag /v /f:"" ``` **Wichtige Bewertungsfragen** - Welcher konkrete Test ist fehlgeschlagen? - Welcher Domain Controller wurde geprüft? - Welcher Partner oder Dienst war beteiligt? - Handelt es sich um einen aktuellen oder historischen Fehler? - Ist DNS korrekt konfiguriert? - Sind notwendige Dienste gestartet? - Funktioniert die Replikation aller Verzeichnispartitionen? - Sind die FSMO-Rolleninhaber erreichbar? - Ist SYSVOL freigegeben? - Tritt der Fehler auf allen DCs oder nur auf einem DC auf? > `dcdiag` liefert mehrere unabhängige Testergebnisse. Eine einzelne Warnung beweist nicht automatisch einen Gesamtausfall des Domain Controllers.
5. AD-Replikation mit Repadmin untersuchen Active Directory ist ein Multi-Master-Verzeichnis. Änderungen werden zwischen Domain Controllern repliziert. Fehler können dazu führen, dass Benutzer, Gruppen, Kennwörter, Computerobjekte oder DNS-Daten auf verschiedenen DCs unterschiedliche Stände besitzen. **Gesamtübersicht** ```cmd [RO][PRIV][REMOTE][SENS] repadmin /replsummary ``` Die Ausgabe zeigt unter anderem: - Quell- und Ziel-DCs - Anzahl fehlgeschlagener Replikationen - Fehlerquote - größte Replikationsverzögerung - Fehlercode **Eingehende Replikationspartner anzeigen** ```cmd [RO][PRIV][REMOTE][SENS] repadmin /showrepl ``` **Bestimmten Domain Controller untersuchen** ```cmd [RO][PRIV][REMOTE][SENS] repadmin /showrepl ``` **Alle Domain Controller ausführlich untersuchen** ```cmd [RO][PRIV][REMOTE][SENS] repadmin /showrepl * /csv ``` **Replikationswarteschlange anzeigen** ```cmd [RO][PRIV][SENS] repadmin /queue ``` **Replikationsmetadaten eines Objekts untersuchen** ```cmd [RO][PRIV][REMOTE][SENS] repadmin /showobjmeta "" ``` **Replikation anstoßen** ```cmd [CHANGE][PRIV][REMOTE] repadmin /syncall /AdeP ``` Dieser Befehl darf nicht als erster Diagnoseschritt verwendet werden. Er verändert zwar keine AD-Objektinhalte direkt, löst aber Replikationsvorgänge aus und kann Netzwerk- sowie Systemlast erzeugen. **Typische Fehlerbereiche** | Fehler oder Beobachtung | Möglicher Prüfbereich | |---|---| | RPC-Server nicht verfügbar | DNS, Firewall, RPC, Routing, Dienste | | Zugriff verweigert | Secure Channel, Kerberos, Berechtigungen, Zeit | | Zielprinzipalname falsch | SPN, Computerkontokennwort, DNS, Kerberos | | DNS-Nachschlagefehler | DNS-Client, Zonen, SRV-Records, Registrierung | | große Replikationsverzögerung | Standortverbindungen, Zeitplan, Erreichbarkeit | | nur eine Partition betroffen | Namenskontext und zuständiger Replikationspfad | | nur ein DC betroffen | lokaler Dienst, DNS, Datenbank oder Netzwerkpfad | > Eine manuell erfolgreich ausgelöste Replikation beweist nicht, dass Topologie, Zeitplan und automatische Replikation dauerhaft funktionieren.
6. Domain Controller über den DC-Locator ermitteln Der DC-Locator ermittelt anhand von DNS-Daten, Domäne, Standort und Anforderungen einen geeigneten Domain Controller. **Domain Controller ermitteln** ```cmd [TEST][SENS] nltest /dsgetdc: ``` Beispiel: ```cmd [TEST][SENS] nltest /dsgetdc:example.internal ``` **Ermittlung neu durchführen** ```cmd [CHANGE][SENS] nltest /dsgetdc: /force ``` **Domain Controller auflisten** ```cmd [RO][SENS] nltest /dclist: ``` **Standort des Computers anzeigen** ```cmd [RO][SENS] nltest /dsgetsite ``` **Standortabdeckung eines DCs untersuchen** ```cmd [RO][SENS] nltest /dsgetsite ``` **DNS-SRV-Einträge prüfen** ```cmd [TEST][SENS] nslookup -type=SRV _ldap._tcp.dc._msdcs. ``` ```cmd [TEST][SENS] nslookup -type=SRV _kerberos._tcp. ``` Zu prüfen sind: - werden mehrere erwartete Domain Controller geliefert? - stimmen Namen und IP-Adressen? - wird ein DC des erwarteten Standorts bevorzugt? - existieren veraltete Einträge? - sind LDAP- und Kerberos-SRV-Records vorhanden? - verwendet der Client ausschließlich interne DNS-Server? - erreicht der Client die ausgegebenen Server? > Das direkte Eintragen eines Domain Controllers in die Hosts-Datei ersetzt die DNS-basierte Dienstermittlung nicht und kann die eigentliche Ursache verdecken.
7. Secure Channel prüfen Domänenmitglieder besitzen ein Computerkonto mit einem Kennwort. Der Secure Channel verwendet diese Vertrauensbeziehung für die Kommunikation mit der Domäne. **Secure Channel mit NLTest prüfen** ```cmd [TEST][PRIV][REMOTE][SENS] nltest /sc_verify: ``` **Vertraute Domäne abfragen** ```cmd [RO][PRIV][SENS] nltest /sc_query: ``` **PowerShell-Prüfung auf einem Domänenmitglied** ```powershell [TEST][PRIV][REMOTE] Test-ComputerSecureChannel -Verbose ``` `Test-ComputerSecureChannel` ist für Domänenmitglieder vorgesehen. Die Interpretation auf Domain Controllern unterscheidet sich, weil DCs eigene Replikations- und Vertrauensmechanismen verwenden. **Reparatur mit PowerShell** ```powershell [CHANGE][PRIV][REMOTE][DANGER] Test-ComputerSecureChannel -Repair -Credential "\" ``` Vor einer Reparatur müssen geprüft werden: - DNS-Konfiguration - Erreichbarkeit eines Domain Controllers - Uhrzeit - Computerkonto im Active Directory - mögliche doppelte Computernamen - Wiederherstellung eines alten VM-Snapshots - kürzlich erfolgte Domänenwiederaufnahme - verwendete administrative Anmeldeinformationen - Auswirkungen auf Dienste und geplante Aufgaben > Ein Computer sollte nicht vorschnell aus der Domäne entfernt und wieder aufgenommen werden. Dadurch können Computerkonto, Zertifikate, lokale Profile, verschlüsselte Daten, Dienstkonten und Verwaltungszuordnungen beeinflusst werden.
8. DNS-Clientkonfiguration der Domänenmitglieder prüfen **Vollständige IP-Konfiguration** ```cmd [RO][SENS] ipconfig /all ``` **PowerShell-Übersicht** ```powershell [RO][SENS] Get-DnsClientServerAddress ``` ```powershell [RO][SENS] Get-NetIPConfiguration ``` Zu prüfen sind: - verwendete DNS-Server - Reihenfolge der DNS-Server - DNS-Suffix - verbindungsspezifisches DNS-Suffix - Registrierung der Adresse - mehrere aktive Netzwerkadapter - VPN-Adapter - virtuelle Adapter - fehlerhafte statische Einstellungen - DHCP-Optionen - Erreichbarkeit der eingetragenen DNS-Server **DNS-Clientcache anzeigen** ```cmd [RO][SENS] ipconfig /displaydns ``` **DNS-Clientcache leeren** ```cmd [CHANGE] ipconfig /flushdns ``` Das Leeren des Caches kann einen neuen Auflösungsversuch erzwingen, beseitigt aber keine fehlerhafte Zone, falsche Delegierung oder falsche DNS-Clientkonfiguration. **DNS-Namen prüfen** ```powershell [TEST][SENS] Resolve-DnsName "" ``` ```powershell [TEST][SENS] Resolve-DnsName "" -Type A ``` ```powershell [TEST][SENS] Resolve-DnsName "_ldap._tcp.dc._msdcs." -Type SRV ``` > Ein Domänenclient sollte nicht ohne geplante interne DNS-Weiterleitung öffentliche DNS-Resolver zusätzlich zu internen AD-DNS-Servern verwenden. Windows behandelt mehrere eingetragene DNS-Server nicht als einfache interne-und-externe Suchreihenfolge.
9. DNS-Server und AD-integrierte Zonen untersuchen Wichtige Prüfbereiche im DNS-Manager: - Forward-Lookupzonen - Reverse-Lookupzonen - AD-integrierte Zonen - Replikationsbereich der Zone - dynamische Updates - sichere dynamische Updates - Weiterleitungen - bedingte Weiterleitungen - Stammhinweise - veraltete Hosteinträge - SRV-Einträge - Delegierungen - Alterung und Aufräumvorgänge - DNSSEC, falls verwendet **DNS-Serverzonen mit PowerShell anzeigen** ```powershell [RO][PRIV][SENS] Get-DnsServerZone ``` **Ressourceneinträge einer Zone anzeigen** ```powershell [RO][PRIV][SENS] Get-DnsServerResourceRecord -ZoneName "" ``` **DNS-Servereinstellungen anzeigen** ```powershell [RO][PRIV][SENS] Get-DnsServer ``` **Weiterleitungen anzeigen** ```powershell [RO][PRIV][SENS] Get-DnsServerForwarder ``` **DNS-Diagnose mit DCDiag** ```cmd [TEST][PRIV][SENS] dcdiag /test:DNS /v ``` **DNS-Registrierung eines Domänenmitglieds anfordern** ```cmd [CHANGE] ipconfig /registerdns ``` Auf einem Domain Controller kann außerdem eine erneute Registrierung domänenbezogener Einträge erforderlich sein. Dienstneustarts dürfen jedoch erst nach Prüfung der Auswirkungen erfolgen. **DNS-Debugprotokollierung** Die DNS-Debugprotokollierung kann sehr viele Daten und interne Abfragen erfassen. Sie sollte: 1. nur mit einem konkreten Fehlerbild aktiviert werden, 2. nach Client, Protokoll oder Pakettyp begrenzt werden, 3. nur so lange wie erforderlich laufen, 4. hinsichtlich Speicherplatz überwacht werden, 5. anschließend wieder deaktiviert werden. ```text [CHANGE][PRIV][LOG][SENS] ``` > DNS-Debuglogs können interne Hostnamen, abgefragte Dienste, Clientadressen und Benutzeraktivitäten offenlegen.
10. Netlogon-Protokollierung kontrolliert verwenden Netlogon ist unter anderem an Domänenanmeldung, DC-Locator und Secure-Channel-Vorgängen beteiligt. Eine erweiterte Netlogon-Protokollierung darf nur zeitlich begrenzt aktiviert werden. **Aktuellen Netlogon-Zustand prüfen** ```cmd [RO][PRIV] sc query netlogon ``` **Netlogon-Diagnoseprotokollierung aktivieren** ```cmd [CHANGE][PRIV][LOG][SENS] nltest /dbflag:0x2080ffff ``` **Protokollierung wieder auf den Standardzustand zurücksetzen** ```cmd [CHANGE][PRIV] nltest /dbflag:0x0 ``` Das Protokoll befindet sich typischerweise unter: ```text %windir%\debug\netlogon.log ``` Vor und während der Aufzeichnung müssen geprüft werden: - freier Speicherplatz - Aufzeichnungsdauer - konkreter Fehlerzeitpunkt - betroffener Benutzer und Computer - Schutz der Protokolldatei - anschließende Deaktivierung > Der Debug-Schalter darf nicht unkontrolliert dauerhaft aktiviert bleiben. Die Datei kann umfangreich werden und interne Domäneninformationen enthalten.
11. Kerberos-Tickets mit Klist untersuchen Kerberos verwendet Tickets zur Authentifizierung. Dabei sind unter anderem Client, Key Distribution Center, Zielservice, SPN, Uhrzeit und DNS beteiligt. **Tickets des aktuellen Anmeldekontexts anzeigen** ```cmd [RO][SENS] klist ``` **Ticket Granting Tickets anzeigen** ```cmd [RO][SENS] klist tgt ``` **Kerberos-Sitzungen anzeigen** ```cmd [RO][SENS] klist sessions ``` **Tickets löschen** ```cmd [CHANGE][SENS] klist purge ``` Das Löschen der Tickets beeinflusst den aktuellen Authentifizierungskontext. Anwendungen müssen danach möglicherweise neue Tickets anfordern. **Ticket für einen Dienst anfordern** ```cmd [TEST][REMOTE][SENS] klist get ``` **Typische Prüfungen** - wurde ein TGT ausgestellt? - welcher KDC hat das Ticket ausgestellt? - für welchen SPN wurde ein Serviceticket ausgestellt? - ist das Ticket abgelaufen? - stimmen Client- und Servernamen? - wurde auf NTLM zurückgefallen? - tritt der Fehler nur mit Aliasnamen auf? - funktioniert der Zugriff mit FQDN, aber nicht mit Kurzname? - befindet sich ein altes Ticket im Cache? - stimmt die Uhrzeit? > `klist purge` ist keine Ursachenbehebung. Wenn DNS, SPN, Zeit oder Kontokonfiguration fehlerhaft sind, tritt das Problem nach Ausstellung neuer Tickets erneut auf.
12. Service Principal Names mit SetSPN prüfen Ein SPN identifiziert eine Dienstinstanz für Kerberos. Er muss dem richtigen AD-Konto eindeutig zugeordnet sein. **SPNs eines Kontos anzeigen** ```cmd [RO][PRIV][SENS] setspn -L "" ``` **Bestimmten SPN suchen** ```cmd [RO][PRIV][SENS] setspn -Q "" ``` **Forestweit nach doppelten SPNs suchen** ```cmd [RO][PRIV][REMOTE][SENS] setspn -X ``` **SPN mit Duplikatprüfung registrieren** ```cmd [CHANGE][PRIV][DANGER] setspn -S "" "" ``` **SPN entfernen** ```cmd [CHANGE][PRIV][DANGER] setspn -D "" "" ``` Vor jeder Änderung müssen geprüft werden: - vollständiger SPN - Dienstklasse - Hostname und FQDN - Port, falls Teil des SPN - tatsächlich verwendetes Dienstkonto - bestehende Zuordnung - Cluster-, Alias- oder Load-Balancer-Namen - Auswirkungen auf andere Dienstinstanzen - Replikationsstatus Typische Kerberos-Probleme entstehen durch: - fehlenden SPN - doppelten SPN - SPN auf falschem Konto - Dienst läuft unter anderem Konto als erwartet - DNS-Alias ohne passende SPN-Konfiguration - altes Computerkonto - nicht replizierte SPN-Änderung - falschen Zielnamen der Anwendung > SPNs dürfen nicht durch Ausprobieren auf verschiedene Konten geschrieben werden. Eine falsche Zuordnung kann die Kerberos-Authentifizierung mehrerer Systeme beeinträchtigen.
13. Zeitsynchronisation mit W32Time prüfen Kerberos benötigt ausreichend übereinstimmende Zeitangaben. In einer AD-Domäne folgt die Zeithierarchie grundsätzlich der Domänenhierarchie. Der PDC-Emulator der Gesamtstruktur-Stammdomäne besitzt dabei eine besondere Rolle. **Status anzeigen** ```cmd [RO][SENS] w32tm /query /status ``` **Zeitquelle anzeigen** ```cmd [RO][SENS] w32tm /query /source ``` **Konfiguration anzeigen** ```cmd [RO][SENS] w32tm /query /configuration ``` **Peers anzeigen** ```cmd [RO][SENS] w32tm /query /peers ``` **Domänenhierarchie überwachen** ```cmd [TEST][REMOTE][SENS] w32tm /monitor ``` **Abweichung zu einem Computer messen** ```cmd [TEST][REMOTE][SENS] w32tm /stripchart /computer: /dataonly /samples:10 ``` **Neue Synchronisation anfordern** ```cmd [CHANGE][PRIV][REMOTE] w32tm /resync ``` Zu prüfen sind: - verwendete Zeitquelle - letzte erfolgreiche Synchronisation - aktuelle Zeitabweichung - Zeitzone - PDC-Emulator - Virtualisierung und Hypervisor-Zeitquelle - NTP-Erreichbarkeit - Firewall - kürzlich wiederhergestellte VM - manuelle Zeitkonfiguration - Dienstzustand **FSMO-Rollen anzeigen** ```cmd [RO][PRIV][SENS] netdom query fsmo ``` > Die manuelle Konfiguration externer Zeitserver auf allen Domänenmitgliedern kann die vorgesehene AD-Zeithierarchie umgehen. Änderungen müssen passend zur Rolle des Systems geplant werden.
14. Gruppenrichtlinienergebnis mit GPResult untersuchen `gpresult` zeigt die Resultant Set of Policy, also die ermittelten Gruppenrichtlinienergebnisse für Computer und Benutzer. **Zusammenfassung** ```cmd [RO][SENS] gpresult /r ``` **Ausführliche Ausgabe** ```cmd [RO][SENS] gpresult /v ``` **Maximal ausführliche Textausgabe** ```cmd [RO][SENS] gpresult /z ``` **HTML-Bericht erzeugen** ```cmd [RO][SENS] gpresult /h ".html" ``` **Nur Computerrichtlinien anzeigen** ```cmd [RO][PRIV][SENS] gpresult /scope computer /r ``` **Nur Benutzerrichtlinien anzeigen** ```cmd [RO][SENS] gpresult /scope user /r ``` **Bericht für einen anderen Benutzer** ```cmd [RO][PRIV][SENS] gpresult /user "\" /h ".html" ``` Wichtige Auswertungsbereiche: - angewendete GPOs - abgelehnte GPOs - Ablehnungsgrund - Sicherheitsgruppen - Benutzer- und Computer-OU - langsame oder schnelle Netzwerkverbindung - WMI-Filter - Vererbungsinformationen - Loopback-Verarbeitung - Richtlinienrevision - letzter Verarbeitungszeitpunkt - verwendeter Domain Controller > Eine GPO kann in der Gruppenrichtlinienverwaltung vorhanden und mit einer OU verknüpft sein, ohne auf das untersuchte Objekt angewendet zu werden.
15. Gruppenrichtlinienabruf mit GPUpdate testen **Normale Aktualisierung** ```cmd [CHANGE][REMOTE] gpupdate ``` **Alle Richtlinieneinstellungen erneut verarbeiten** ```cmd [CHANGE][REMOTE] gpupdate /force ``` **Zeitlimit festlegen** ```cmd [CHANGE][REMOTE] gpupdate /wait: ``` **Abmeldung zulassen, falls erforderlich** ```cmd [CHANGE][REMOTE] gpupdate /logoff ``` **Neustart zulassen, falls erforderlich** ```cmd [CHANGE][REMOTE][RESTART] gpupdate /boot ``` `gpupdate /force` sollte nicht reflexartig auf vielen Systemen gleichzeitig ausgeführt werden. Es kann: - zusätzliche DC- und Netzwerkbelastung erzeugen - Skripte erneut ausführen - Softwareinstallation anstoßen - Abmeldung oder Neustart erforderlich machen - bestehende Sitzungen beeinflussen - Drucker- und Laufwerkszuordnungen erneut verarbeiten **Empfohlener Testablauf** 1. `gpresult` vor der Aktualisierung speichern. 2. Fehlerzeitpunkt dokumentieren. 3. Ereignisprotokoll prüfen. 4. `gpupdate` auf einem kontrollierten Testsystem ausführen. 5. Meldungen vollständig dokumentieren. 6. erforderliche Abmeldung oder Neustart berücksichtigen. 7. `gpresult` erneut erzeugen. 8. vorherigen und nachfolgenden Zustand vergleichen.
16. Warum eine GPO nicht angewendet wird Mögliche Ursachen: - Benutzer oder Computer befindet sich in der falschen OU. - GPO ist mit einer anderen OU verknüpft. - Verknüpfung ist deaktiviert. - Benutzer- oder Computerteil der GPO ist deaktiviert. - Sicherheitsfilter schließt das Objekt aus. - notwendige Rechte `Lesen` oder `Gruppenrichtlinie übernehmen` fehlen. - WMI-Filter liefert `False` oder kann nicht ausgewertet werden. - Vererbung wurde blockiert. - eine erzwungene GPO beeinflusst die Vererbungsreihenfolge. - eine Richtlinie mit höherer Priorität überschreibt die Einstellung. - Loopback-Verarbeitung verändert die Benutzerrichtlinien. - Client erreicht keinen Domain Controller. - DNS oder Secure Channel ist fehlerhaft. - SYSVOL ist nicht erreichbar. - AD- und SYSVOL-Replikation besitzen unterschiedliche Stände. - Client Side Extension benötigt synchrone Verarbeitung. - Richtlinie wird erst nach Abmeldung oder Neustart wirksam. - Fast Startup beeinflusst den erwarteten Startvorgang. - Anwendung liest die Einstellung nur beim Start. - Einstellung gilt nicht für die verwendete Windows-Version oder Edition. - ADMX-Vorlage und tatsächlich unterstützte Einstellung passen nicht zusammen. **Prüfreihenfolge** 1. Objekt und OU bestätigen. 2. GPO-Verknüpfung bestätigen. 3. GPO-Status prüfen. 4. Sicherheitsfilter prüfen. 5. Delegierung prüfen. 6. WMI-Filter prüfen. 7. Vererbung und Reihenfolge prüfen. 8. `gpresult` auswerten. 9. GroupPolicy-Betriebsprotokoll auswerten. 10. DNS, DC-Locator und SYSVOL testen. 11. AD- und DFS-R-Replikation prüfen. 12. erforderliche Abmeldung oder Neustart testen.
17. GPO-Verarbeitung fachgerecht dokumentieren Für jede untersuchte Gruppenrichtlinie sollten folgende Angaben erfasst werden: ```text Aufgabe: Betroffener Benutzer: Betroffener Computer: Domäne: Standort: Verwendeter Domain Controller: Name der GPO: GPO-ID: GPO-Status: Benutzer- oder Computerkonfiguration: Verknüpfte OU: Verknüpfungsreihenfolge: Verknüpfung aktiviert: Erzwungen: Vererbung blockiert: Sicherheitsfilter: Delegierung: WMI-Filter: Loopback-Modus: Pfad der Richtlinieneinstellung: Konfigurierte Einstellung: Erwarteter Wert: Tatsächlicher Wert: GPResult vor dem Test: GPUpdate-Ergebnis: Abmeldung erforderlich: Neustart erforderlich: GPResult nach dem Test: GroupPolicy-Ereignisse: SYSVOL erreichbar: AD-Replikation geprüft: DFS-R-Replikation geprüft: Ursache: Änderung: Rückfallplan: Testergebnis: ```
18. SYSVOL und NETLOGON prüfen SYSVOL enthält unter anderem Gruppenrichtliniendateien und Skripte. Active Directory speichert den Verzeichnisanteil einer GPO, während SYSVOL den Dateianteil enthält. Beide Teile müssen konsistent und repliziert sein. **Freigaben eines Domain Controllers anzeigen** ```cmd [RO][REMOTE][SENS] net view \\ ``` Erwartete Domänencontroller-Freigaben sind normalerweise: - `SYSVOL` - `NETLOGON` **SYSVOL öffnen** ```cmd [TEST][REMOTE][SENS] dir \\\SYSVOL ``` **NETLOGON öffnen** ```cmd [TEST][REMOTE][SENS] dir \\\NETLOGON ``` **Bestimmte Richtlinie prüfen** ```cmd [RO][REMOTE][SENS] dir "\\\SYSVOL\\Policies\{}" ``` Zu vergleichen sind: - Existenz des GPO-Verzeichnisses - GPO-GUID - Inhalt auf mehreren Domain Controllern - Zeitstempel - `GPT.INI` - Skripte - Registry-Policy-Dateien - Zugriffsrechte - DFS-R-Ereignisse > Dateien in SYSVOL dürfen nicht als normale Konfigurationsmethode manuell auf mehreren Domain Controllern bearbeitet oder kopiert werden. Dadurch können AD- und Dateianteil einer GPO inkonsistent werden.
19. DFS-Replikation von SYSVOL untersuchen Moderne Windows-Domänen verwenden DFS Replication für SYSVOL. Wichtige Datenquellen sind: - Ereignisprotokoll `DFS Replication` - DFS-Verwaltung - `dfsrdiag` - PowerShell - AD-Replikationszustand - Zustand der SYSVOL- und NETLOGON-Freigaben **DFS-R-Zustand abfragen** ```cmd [RO][PRIV][SENS] dfsrdiag ReplicationState ``` **Konfiguration neu aus Active Directory einlesen** ```cmd [CHANGE][PRIV] dfsrdiag PollAD ``` **DFS-R-Ereignisse abrufen** ```powershell [RO][PRIV][SENS] Get-WinEvent -LogName "DFS Replication" -MaxEvents 200 ``` Typische Prüfbereiche: - Replikationsgruppe - replizierter Ordner - eingehender und ausgehender Partner - Rückstand - pausierte Replikation - Datenbankzustand - nicht ordnungsgemäß heruntergefahrener Server - Kommunikationsfehler - AD-Konfiguration noch nicht eingelesen - Speicherplatz - USN- oder Datenbankprobleme > Eine DFS-R-Wiederherstellung oder autoritative SYSVOL-Synchronisierung ist eine eingriffsintensive Maßnahme. Sie darf erst nach gesicherter Diagnose, aktueller Sicherung und dokumentiertem Wiederherstellungsplan durchgeführt werden.
20. DHCP-Server untersuchen DHCP-Probleme können dazu führen, dass Clients: - keine Adresse erhalten - eine APIPA-Adresse verwenden - falsches Gateway erhalten - falsche DNS-Server verwenden - falsches DNS-Suffix erhalten - ihre Lease nicht verlängern können - aus einem falschen Bereich versorgt werden - aufgrund ausgeschöpfter Bereiche keine Adresse erhalten **DHCP-Konfiguration auf dem Client** ```cmd [RO][SENS] ipconfig /all ``` **Lease freigeben** ```cmd [CHANGE] ipconfig /release ``` **Lease erneuern** ```cmd [CHANGE][REMOTE] ipconfig /renew ``` Diese Befehle unterbrechen die aktuelle IP-Konnektivität und sollten nicht unüberlegt über eine entfernte Verwaltungssitzung ausgeführt werden. **DHCP-Server anzeigen** ```powershell [RO][PRIV][SENS] Get-DhcpServerInDC ``` **IPv4-Bereiche anzeigen** ```powershell [RO][PRIV][REMOTE][SENS] Get-DhcpServerv4Scope -ComputerName "" ``` **Leases anzeigen** ```powershell [RO][PRIV][REMOTE][SENS] Get-DhcpServerv4Lease -ComputerName "" -ScopeId "" ``` **Bereichsstatistik anzeigen** ```powershell [RO][PRIV][REMOTE][SENS] Get-DhcpServerv4ScopeStatistics -ComputerName "" ``` **Serveroptionen anzeigen** ```powershell [RO][PRIV][REMOTE][SENS] Get-DhcpServerv4OptionValue -ComputerName "" ``` Zu prüfen sind: - DHCP-Autorisierung in Active Directory - Dienstzustand - Bereich aktiviert - verfügbarer Adressvorrat - Ausschlussbereiche - Reservierungen - Lease-Dauer - Option 003 – Router - Option 006 – DNS-Server - Option 015 – DNS-Domänenname - Relay-Agent oder IP Helper - DHCP-Failover - Konflikterkennung - mehrere unerwartete DHCP-Server - Auditprotokolle > DHCP-Debug- und Auditlogs können MAC-Adressen, Hostnamen, IP-Adressen und zeitliche Gerätenutzung enthalten und müssen entsprechend geschützt werden.
21. DFS-Namespace und DFS-Replikation unterscheiden DFS besteht aus unterschiedlichen Funktionen: | Komponente | Aufgabe | |---|---| | DFS Namespace | stellt einen einheitlichen logischen Pfad bereit | | DFS Replication | repliziert Ordnerinhalte zwischen Servern | Ein erreichbarer Namespace beweist nicht, dass alle Replikationspartner denselben Datenstand besitzen. Umgekehrt beweist ein gesunder DFS-R-Status nicht, dass Namespace-Ziele, Berechtigungen und Verweise korrekt funktionieren. **Namespacepfad testen** ```cmd [TEST][REMOTE][SENS] dir "\\\" ``` **DFS-Ziele und Verweise untersuchen** ```cmd [RO][SENS] dfsutil /pktinfo ``` **Zwischengespeicherte Verweise leeren** ```cmd [CHANGE] dfsutil /pktflush ``` **Typische Prüfbereiche** - DNS-Auflösung - Namespace-Server - Ordnerziele - Zielstatus - Standortkosten - Referral-Reihenfolge - SMB-Erreichbarkeit - Freigabeberechtigungen - NTFS-Berechtigungen - DFS-R-Rückstand - Dateisperren - Konflikt- und gelöschte Ordner - Staging-Speicher
22. Failovercluster untersuchen Ein Failovercluster besteht aus mehreren voneinander abhängigen Komponenten: - Clusterknoten - Clusterdienst - Quorum - Witness - Cluster-Netzwerke - Speicher - Cluster Shared Volumes - Ressourcen - Rollen - Abhängigkeiten - DNS - Active-Directory-Computerobjekte - Anwendungen **Cluster anzeigen** ```powershell [RO][PRIV][REMOTE][SENS] Get-Cluster ``` **Knoten anzeigen** ```powershell [RO][PRIV][REMOTE][SENS] Get-ClusterNode ``` **Clustergruppen anzeigen** ```powershell [RO][PRIV][REMOTE][SENS] Get-ClusterGroup ``` **Ressourcen anzeigen** ```powershell [RO][PRIV][REMOTE][SENS] Get-ClusterResource ``` **Quorum anzeigen** ```powershell [RO][PRIV][REMOTE][SENS] Get-ClusterQuorum ``` **Clusterprotokoll erzeugen** ```powershell [TEST][PRIV][REMOTE][LOG][SENS] Get-ClusterLog -UseLocalTime -Destination "" ``` **Cluster validieren** ```powershell [TEST][PRIV][REMOTE][LOG][SENS] Test-Cluster ``` Die vollständige Validierung kann Netzwerk-, Speicher- und Systemtests durchführen. Umfang und Auswirkungen müssen vor dem Start geprüft werden. **Typische Diagnosefragen** - Welche Ressource ist zuerst ausgefallen? - Welche abhängigen Ressourcen folgten? - Welcher Knoten war Besitzer? - War Quorum vorhanden? - War der Witness erreichbar? - trat ein Netzwerk- oder Speicherfehler auf? - konnte das Clustercomputerobjekt DNS-Daten aktualisieren? - stimmen Ereigniszeit und Clusterlog überein? - war der Failover geplant oder ungeplant? - funktioniert die Anwendung nach dem Ressourcenstart tatsächlich? > Das manuelle Verschieben oder Neustarten einer Clusterrolle ist eine Änderung am produktiven Dienst und keine rein lesende Diagnose.
23. Server Manager und Windows Admin Center richtig einordnen **Server Manager** Server Manager kann unter anderem anzeigen: - Serverrollen - Features - verwaltete Server - Dienstzustände - Ereignisse - Leistungswarnungen - Best-Practices-Ergebnisse - Rolleninstallationen **Windows Admin Center** Windows Admin Center kann abhängig von Version und Erweiterungen unter anderem verwalten: - Server - Cluster - virtuelle Maschinen - Zertifikate - Ereignisse - Dienste - Speicher - Netzwerke - Updates - Firewall - Registry - PowerShell **Grenzen** - eine grüne Übersicht ersetzt keine Detailprüfung - Daten können verzögert aktualisiert werden - Remoteverwaltung hängt von WinRM, Berechtigungen und Firewall ab - eine fehlgeschlagene Verwaltungsverbindung beweist keinen Ausfall des Zielservers - Aktionen können produktive Änderungen auslösen - Erweiterungen können zusätzliche Berechtigungen benötigen > Verwaltungsoberflächen fassen Zustände zusammen. Für belastbare Diagnosen müssen häufig Ereignisprotokolle, PowerShell-Ausgaben, Dienstprotokolle und Netzwerkdaten ergänzt werden.
24. Leistungsüberwachung auf Windows Server Leistungsprobleme dürfen nicht allein anhand einer einzelnen CPU- oder RAM-Anzeige bewertet werden. Wichtige Bereiche: - Prozessor - Arbeitsspeicher - Datenträger - Netzwerk - Prozess - System - Serverdienst - DNS - AD DS - DFS-R - Hyper-V - SQL Server oder weitere Anwendungsrollen **Leistungsindikatoren anzeigen** ```powershell [RO][SENS] Get-Counter -ListSet * ``` **Beispielhafte Systemindikatoren** ```powershell [TEST][SENS] Get-Counter ` "\Processor(_Total)\% Processor Time", "\Memory\Available MBytes", "\PhysicalDisk(_Total)\Avg. Disk sec/Transfer", "\System\Processor Queue Length" ``` **Wichtige Regeln** - über einen repräsentativen Zeitraum messen - Normalzustand als Vergleichswert besitzen - Durchschnitt, Maximum und Verteilung unterscheiden - Rolle des Servers berücksichtigen - virtuelle und physische Ebene unterscheiden - Wartungsfenster und Sicherungen berücksichtigen - Ursache und Folge nicht verwechseln - Zeitstempel mit Benutzerfehlern korrelieren > Ein einzelner hoher Messwert beweist noch keinen Engpass. Entscheidend sind Dauer, Wiederholbarkeit, Warteschlangen, Antwortzeiten und Auswirkungen auf den Dienst.
25. Typische Fehlerbilder und geeignete Werkzeuge | Fehlerbild | Geeignete Prüfungen | |---|---| | Benutzer kann sich nicht anmelden | DNS, DC-Locator, Zeit, Secure Channel, Kerberos, Netlogon, Ereignisse | | Anmeldung funktioniert nur manchmal | mehrere DCs vergleichen, Replikation, DNS, Standorte, Zeit | | neues Kennwort funktioniert nicht überall | `repadmin`, verwendeten DC feststellen, PDC-Erreichbarkeit | | neuer Benutzer ist auf einem Server unbekannt | AD-Replikation, verwendeten DC, DNS | | Computer meldet fehlende Vertrauensstellung | Secure Channel, Computerkonto, DNS, Zeit | | GPO wird nicht angewendet | `gpresult`, GroupPolicy-Log, OU, Filter, SYSVOL, Replikation | | GPO besitzt auf verschiedenen Clients andere Werte | verwendeten DC, AD- und SYSVOL-Replikation, Filter | | Netzlaufwerk fehlt | GPO, DNS, DFS, SMB, Berechtigungen, Benutzerkontext | | Domain Controller wird nicht gefunden | DNS-Client, SRV-Records, DC-Locator, Firewall | | Kerberos funktioniert nur mit bestimmtem Namen | DNS, SPN, Alias, Dienstkonto | | Zugriff fällt auf NTLM zurück | Kerberos-Ticket, SPN, Zielname, DNS | | Uhrzeit springt zurück | W32Time, Domänenhierarchie, Hypervisor-Zeitquelle | | DHCP-Client erhält APIPA | DHCP-Server, Relay, VLAN, Bereich, Firewall | | falscher DNS-Server per DHCP | Bereichs- und Serveroptionen prüfen | | SYSVOL fehlt | DFS-R, Netlogon, DC-Zustand, Ereignisse | | Dateien in DFS unterscheiden sich | DFS-R-Zustand, Rückstand, Konflikte, Dateisperren | | Clusterrolle startet nicht | Ressourcenabhängigkeiten, Clusterlog, Systemlog, DNS, Speicher | | Server Manager zeigt Server als offline | WinRM, Firewall, DNS, Berechtigungen, Zielzustand |
26. Empfohlener Gesamtablauf bei Domänenproblemen 1. originale Fehlermeldung erfassen. 2. Benutzer, Computer und Zeitpunkt bestätigen. 3. Umfang der Störung bestimmen. 4. letzte Änderung dokumentieren. 5. lokale Netzwerkverbindung prüfen. 6. `ipconfig /all` erfassen. 7. konfigurierte DNS-Server prüfen. 8. Domänennamen und SRV-Einträge auflösen. 9. Domain Controller mit `nltest /dsgetdc` ermitteln. 10. verwendeten Standort prüfen. 11. Domain Controller gezielt erreichen. 12. Uhrzeit und Zeitquelle vergleichen. 13. Secure Channel prüfen. 14. Kerberos-Tickets untersuchen. 15. bei Dienstproblemen SPNs prüfen. 16. System- und Anwendungsprotokolle auswerten. 17. auf Domain Controllern `dcdiag` ausführen. 18. AD-Replikation mit `repadmin` prüfen. 19. bei GPO-Problemen `gpresult` sichern. 20. GroupPolicy-Betriebsprotokoll untersuchen. 21. SYSVOL auf mehreren DCs vergleichen. 22. DFS-R-Ereignisse prüfen. 23. Hypothese aus mehreren Befunden formulieren. 24. kleinste reversible Maßnahme planen. 25. Sicherung und Rückfallplan prüfen. 26. Änderung kontrolliert durchführen. 27. Funktion mit demselben Testszenario erneut prüfen. 28. Replikation und Monitoring nachkontrollieren. 29. temporäre Debugprotokollierung deaktivieren. 30. Ursache, Maßnahme und Ergebnis dokumentieren.
27. Beispiel – Gruppenrichtlinie wird auf CLIENT1 nicht angewendet **Ausgangslage** Eine auf `DC1` erstellte und mit einer OU verknüpfte GPO soll auf `CLIENT1` angewendet werden. Die konfigurierte Einstellung ist auf dem Client nicht wirksam. **Vorgehensweise** 1. Benutzer- und Computername auf `CLIENT1` bestätigen. 2. prüfen, ob die Einstellung eine Benutzer- oder Computerrichtlinie ist. 3. tatsächliche OU des Zielobjekts kontrollieren. 4. GPO-Verknüpfung in der Gruppenrichtlinienverwaltung prüfen. 5. GPO-Status und Verknüpfungsstatus prüfen. 6. Sicherheitsfilter und Delegierung kontrollieren. 7. WMI-Filter prüfen. 8. `gpresult` vor einer Änderung erzeugen: ```cmd [RO][SENS] gpresult /h "%TEMP%\gpresult-vorher.html" ``` 9. verwendeten Domain Controller und DNS-Zustand prüfen: ```cmd [RO][SENS] set LOGONSERVER [TEST][SENS] nltest /dsgetdc: [RO][SENS] ipconfig /all ``` 10. GroupPolicy-Betriebsprotokoll untersuchen. 11. SYSVOL auf dem verwendeten DC prüfen. 12. AD- und DFS-R-Replikation zwischen `DC1` und weiteren DCs prüfen. 13. kontrollierte Aktualisierung durchführen: ```cmd [CHANGE][REMOTE] gpupdate /force ``` 14. erforderliche Abmeldung oder Neustart durchführen. 15. neuen Bericht erzeugen: ```cmd [RO][SENS] gpresult /h "%TEMP%\gpresult-nachher.html" ``` 16. beide Berichte vergleichen. **Mögliche Befunde** - `CLIENT1` befindet sich in der falschen OU. - GPO enthält eine Benutzereinstellung, wurde aber nur für das Computerkonto erwartet. - Sicherheitsfilter schließt den Benutzer oder Computer aus. - GPO wird durch eine höher priorisierte Einstellung überschrieben. - WMI-Filter trifft nicht zu. - Client verwendet einen anderen DC mit älterem Replikationsstand. - SYSVOL enthält auf einem DC nicht den aktuellen Dateianteil. - Richtlinie benötigt Neustart oder Abmeldung. - Einstellung wird von der Clientedition nicht unterstützt. - Loopback-Verarbeitung verändert das Ergebnis.
28. Beispiel – Benutzer kann sich nur an manchen Computern anmelden **Mögliche Ursachen** - unterschiedliche Domain Controller liefern unterschiedliche AD-Stände - Kennwortänderung ist noch nicht vollständig repliziert - ein Standort verweist auf einen gestörten DC - DNS liefert veraltete oder falsche Einträge - ein Computer besitzt einen fehlerhaften Secure Channel - Zeitabweichung verhindert Kerberos - lokale Benutzerrechte unterscheiden sich - GPO verweigert eine Anmeldeart - Benutzerprofil oder Anmeldeskript schlägt fehl - Netzwerk ist beim Start noch nicht verfügbar **Prüfungen auf funktionierendem und betroffenem Computer** ```cmd [RO][SENS] ipconfig /all [TEST][SENS] nltest /dsgetdc: [RO][SENS] nltest /dsgetsite [TEST][PRIV][SENS] nltest /sc_verify: [RO][SENS] w32tm /query /status [RO][SENS] w32tm /query /source [RO][SENS] klist [RO][SENS] gpresult /r ``` Anschließend müssen die Ergebnisse miteinander verglichen werden: - DNS-Server - Domain Controller - Standort - Uhrzeit - Ticketstatus - GPOs - Gruppenmitgliedschaften - Ereignisprotokolle - Secure Channel
29. Beispiel – Active-Directory-Änderung erscheint nicht auf DC2 **Ausgangslage** Ein auf `DC1` angelegtes oder geändertes Objekt ist auf `DC2` nicht sichtbar. **Vorgehensweise** 1. Objekt und Änderungszeitpunkt dokumentieren. 2. sicherstellen, dass tatsächlich unterschiedliche DCs abgefragt werden. 3. AD-Replikationsübersicht erstellen: ```cmd [RO][PRIV][SENS] repadmin /replsummary ``` 4. eingehende Partner von `DC2` untersuchen: ```cmd [RO][PRIV][SENS] repadmin /showrepl DC2 ``` 5. betroffenen Namenskontext bestimmen. 6. DNS-Auflösung zwischen `DC1` und `DC2` prüfen. 7. RPC- und Firewall-Erreichbarkeit berücksichtigen. 8. Uhrzeit vergleichen. 9. Ereignisprotokoll `Directory Service` untersuchen. 10. Replikationsmetadaten des Objekts vergleichen: ```cmd [RO][PRIV][SENS] repadmin /showobjmeta DC1 "" ``` ```cmd [RO][PRIV][SENS] repadmin /showobjmeta DC2 "" ``` 11. erst nach Ursachenprüfung eine kontrollierte Replikation auslösen. 12. anschließend automatische Replikation weiter beobachten. > Das manuelle Kopieren, erneute Anlegen oder Löschen des Objekts kann Konflikte erzeugen und die ursprüngliche Replikationsursache verdecken.
30. Gefährliche Fehlinterpretationen vermeiden | Beobachtung | Nicht automatisch bewiesen | |---|---| | Ping zum DC funktioniert | LDAP, Kerberos, SMB und RPC funktionieren | | Domänenname wird aufgelöst | alle benötigten SRV-Records sind korrekt | | Anmeldung funktioniert | Anmeldung erfolgte aktuell gegen einen DC | | `LOGONSERVER` zeigt DC1 | jeder Domänendienst verwendet DC1 | | `gpupdate` war erfolgreich | gewünschte GPO wurde angewendet | | GPO ist verknüpft | Zielobjekt darf sie anwenden | | GPO erscheint in `gpresult` | jede einzelne Einstellung wurde erfolgreich verarbeitet | | Benutzer ist Gruppenmitglied | aktuelles Token enthält die neue Mitgliedschaft | | `klist` zeigt Tickets | Ticket gehört zum richtigen Dienst und SPN | | SPN existiert | SPN ist dem richtigen Konto eindeutig zugeordnet | | Uhrzeit sieht gleich aus | Zeitquelle und tatsächliche Abweichung sind korrekt | | `repadmin /replsummary` zeigt wenig Fehler | alle Partitionen und Objekte sind aktuell | | SYSVOL ist erreichbar | SYSVOL besitzt auf allen DCs denselben Stand | | DHCP-Lease existiert | Optionen, VLAN und DNS-Daten sind korrekt | | Clusterressource ist online | Anwendung ist fachlich funktionsfähig | | Ereignis-ID ist bekannt | Ursache ist ohne Ereignistext eindeutig |
31. Sicherheits- und Datenschutzanforderungen Diagnosedaten können enthalten: - Benutzernamen - Gruppenmitgliedschaften - Computernamen - Domänennamen - interne DNS-Zonen - IP- und MAC-Adressen - Distinguished Names - Gruppenrichtlinien - Anmeldeserver - Sicherheitskennungen - Kerberos-Ticketinformationen - Dienstkonten - SPNs - Freigaben - interne Dateipfade - Cluster- und Servernamen - DHCP-Leases - Ereignisprotokolle - Netzwerkstruktur - administrative Konten Vor der Weitergabe müssen: 1. Zweck und Empfänger bestimmt werden. 2. benötigte Daten begrenzt werden. 3. Kennwörter, Schlüssel und Tokens ausgeschlossen werden. 4. personenbezogene Angaben redigiert werden. 5. Dateien verschlüsselt übertragen werden. 6. Zugriffsrechte beschränkt werden. 7. Aufbewahrungsfristen festgelegt werden. 8. temporäre Debuglogs wieder deaktiviert werden. 9. nicht mehr benötigte Diagnosedaten sicher gelöscht werden. 10. externe Analysedienste organisatorisch freigegeben sein. > Kennwörter dürfen nicht in Befehlszeilen, Dokumentationen, Screenshots oder Protokolldateien eingetragen werden.
32. Dokumentationsvorlage ```text Ticket: Datum und Uhrzeit: Bearbeiter: Betroffener Benutzer: Betroffener Computer: Windows-Version: Serverrolle: Domäne: Active-Directory-Standort: IP-Adresse: DNS-Server: Gateway: VPN: Verwendeter Domain Controller: LOGONSERVER: Originale Fehlermeldung: Fehlerzeitpunkt: Reproduzierbar: Betroffene Systeme: Letzte funktionierende Nutzung: Letzte Änderung: DC-Locator-Ergebnis: Secure-Channel-Ergebnis: Zeitquelle: Zeitabweichung: Kerberos-Tickets: Verwendeter KDC: Untersuchter SPN: SPN-Zuordnung: Doppelte SPNs: DCDiag-Ergebnis: Fehlgeschlagener Test: Repadmin-Replikationsübersicht: Betroffener Quell-DC: Betroffener Ziel-DC: Betroffener Namenskontext: Letzte erfolgreiche Replikation: Replikationsfehlercode: Replikationsmetadaten geprüft: DNS-Zone: DNS-Record: SRV-Records: Dynamische Registrierung: DNS-Ereignisse: DNS-Debuglog verwendet: Netlogon-Debuglog verwendet: Debuglogging wieder deaktiviert: GPO: GPO-ID: Benutzer- oder Computerrichtlinie: Verknüpfte OU: Sicherheitsfilter: Delegierung: WMI-Filter: Vererbungsreihenfolge: Loopback-Modus: GPResult vorher: GPUpdate-Ergebnis: GPResult nachher: GroupPolicy-Ereignisse: Abmeldung erforderlich: Neustart erforderlich: SYSVOL erreichbar: NETLOGON erreichbar: GPO-Dateianteil vorhanden: DFS-R-Status: DFS-R-Ereignisse: Replikationsrückstand: DHCP-Server: DHCP-Bereich: Lease: Bereichsauslastung: Router-Option: DNS-Option: DNS-Suffix: DHCP-Relay: DHCP-Failover: Cluster: Clusterknoten: Clusterrolle: Fehlgeschlagene Ressource: Abhängige Ressourcen: Quorum: Witness: Clusterlog: Failover-Zeitpunkt: Vermutete Ursache: Belege: Geplante Maßnahme: Sicherung: Rückfallplan: Änderung: Ergebnis: Wiederholungstest: Monitoring: Abschluss: ```
--- **Merksatz** > Bei Fehlern in Windows-Domänen muss die Abhängigkeitskette vollständig betrachtet werden: Netzwerk ermöglicht die Verbindung, DNS findet den Dienst, Zeit und Secure Channel schaffen die Vertrauensbasis, Kerberos authentifiziert, Active Directory liefert die Objekte, Replikation verteilt den Zustand und SYSVOL stellt die Gruppenrichtliniendateien bereit. **Quellen und weiterführende Dokumentation** - [Microsoft Learn – DCDiag](https://learn.microsoft.com/windows-server/administration/windows-commands/dcdiag) - [Microsoft Learn – Repadmin](https://learn.microsoft.com/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/cc770963(v=ws.11)) - [Microsoft Learn – Problembehandlung der Active-Directory-Replikation](https://learn.microsoft.com/windows-server/identity/ad-ds/manage/troubleshoot/troubleshooting-active-directory-replication-problems) - [Microsoft Learn – Häufige Active-Directory-Replikationsfehler](https://learn.microsoft.com/troubleshoot/windows-server/active-directory/common-active-directory-replication-errors) - [Microsoft Learn – NLTest](https://learn.microsoft.com/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/cc731935(v=ws.11)) - [Microsoft Learn – Test-ComputerSecureChannel](https://learn.microsoft.com/powershell/module/microsoft.powershell.management/test-computersecurechannel) - [Microsoft Learn – Active Directory Domain Services und DNS](https://learn.microsoft.com/windows-server/identity/ad-ds/plan/dns-and-ad-ds) - [Microsoft Learn – Resolve-DnsName](https://learn.microsoft.com/powershell/module/dnsclient/resolve-dnsname) - [Microsoft Learn – DNS-Server-PowerShell](https://learn.microsoft.com/powershell/module/dnsserver/) - [Microsoft Learn – Kerberos-Problembehandlung](https://learn.microsoft.com/troubleshoot/windows-server/windows-security/kerberos-authentication-troubleshooting-guidance) - [Microsoft Learn – Klist](https://learn.microsoft.com/windows-server/administration/windows-commands/klist) - [Microsoft Learn – SetSPN](https://learn.microsoft.com/windows-server/administration/windows-commands/setspn) - [Microsoft Learn – W32tm](https://learn.microsoft.com/windows-server/networking/windows-time-service/windows-time-service-tools-and-settings) - [Microsoft Learn – Funktionsweise des Windows-Zeitdienstes](https://learn.microsoft.com/windows-server/networking/windows-time-service/how-the-windows-time-service-works) - [Microsoft Learn – GPResult](https://learn.microsoft.com/windows-server/administration/windows-commands/gpresult) - [Microsoft Learn – GPUpdate](https://learn.microsoft.com/windows-server/administration/windows-commands/gpupdate) - [Microsoft Learn – Gruppenrichtlinien-Problembehandlung](https://learn.microsoft.com/troubleshoot/windows-server/group-policy/group-policy-overview) - [Microsoft Learn – Group Policy Operational Log](https://learn.microsoft.com/previous-versions/windows/it-pro/windows-7/ff182331(v=ws.10)) - [Microsoft Learn – DHCP-Server-PowerShell](https://learn.microsoft.com/powershell/module/dhcpserver/) - [Microsoft Learn – DHCP-Problembehandlung](https://learn.microsoft.com/troubleshoot/windows-server/networking/troubleshoot-dhcp-guidance) - [Microsoft Learn – DFS Namespaces und DFS Replication](https://learn.microsoft.com/windows-server/storage/dfs-namespaces/dfs-overview) - [Microsoft Learn – Problembehandlung bei DFS Replication](https://learn.microsoft.com/troubleshoot/windows-server/networking/dfsr-overview) - [Microsoft Learn – Failover Clustering](https://learn.microsoft.com/windows-server/failover-clustering/failover-clustering-overview) - [Microsoft Learn – Failovercluster erstellen und validieren](https://learn.microsoft.com/windows-server/failover-clustering/create-failover-cluster) - [Microsoft Learn – Get-ClusterLog](https://learn.microsoft.com/powershell/module/failoverclusters/get-clusterlog) - [Microsoft Learn – Windows Admin Center](https://learn.microsoft.com/windows-server/manage/windows-admin-center/overview) - [Microsoft Learn – Get-Counter](https://learn.microsoft.com/powershell/module/microsoft.powershell.diagnostics/get-counter) - [Microsoft Learn – Netzwerkports für Windows-Dienste](https://learn.microsoft.com/troubleshoot/windows-server/networking/service-overview-and-network-port-requirements) # 5.4 Linux – Werkzeuge zur Fehleranalyse Linux-Systeme stellen zahlreiche integrierte Werkzeuge für die Fehleranalyse bereit. Die konkrete Verfügbarkeit und Ausgabe hängt unter anderem ab von: - Distribution und Version - Kernel-Version - Init-System - installierten Paketen - Netzwerkverwaltung - Dateisystem - Virtualisierung oder Containerisierung - Berechtigungen - Sicherheitsmechanismen wie SELinux oder AppArmor Auf modernen Serverdistributionen wird häufig `systemd` eingesetzt. Andere Systeme können jedoch alternative Init- und Protokollierungssysteme verwenden. --- **Kennzeichnung der Befehle** | Kennzeichnung | Bedeutung | |---|---| | `[RO]` | grundsätzlich lesende Abfrage | | `[TEST]` | aktiver Test, der Netzwerk- oder Systemlast erzeugen kann | | `[CHANGE]` | verändert den Systemzustand | | `[PRIV]` | benötigt häufig Root-Rechte oder `sudo` | | `[REMOTE]` | kommuniziert mit einem anderen System oder Dienst | | `[LOG]` | erzeugt möglicherweise umfangreiche Protokolldaten | | `[SENS]` | Ausgabe kann interne oder personenbezogene Informationen enthalten | | `[DANGER]` | kann bei falscher Anwendung Dienste, Daten oder das gesamte System gefährden | | `[RESTART]` | kann einen Dienst- oder Systemneustart auslösen | > Die Kennzeichnungen sind Sicherheitshinweise und kein Bestandteil des eigentlichen Befehls. ---
1. Diagnose vor der Änderung Eine Linux-Fehleranalyse sollte nicht mit einem Neustart, einer Paketaktualisierung oder dem Löschen von Dateien beginnen. Zuerst muss der fehlerhafte Zustand gesichert werden. **Grundfragen** - Was funktioniert nicht? - Wie lautet die vollständige Fehlermeldung? - Seit wann besteht der Fehler? - Ist er reproduzierbar? - Welche Benutzer, Dienste oder Systeme sind betroffen? - Was wurde zuletzt geändert? - Ist nur eine Anwendung oder das gesamte System betroffen? - Tritt der Fehler lokal und remote auf? - Besteht ein zeitlicher Zusammenhang mit Updates, Neustarts oder Sicherungen? - Gibt es ausreichend Speicherplatz, Inodes und Arbeitsspeicher? - Läuft das System auf Hardware, in einer VM oder in einem Container? **Grundlegende Systeminformationen** ```bash [RO][SENS] hostnamectl [RO] uname -a [RO] cat /etc/os-release [RO] uptime [RO][SENS] who [RO][SENS] last -x ``` `last -x` kann unter anderem Anmeldungen, Neustarts und Herunterfahrvorgänge anzeigen. Die verfügbaren Daten hängen von der Protokollierung und Rotation der zugrunde liegenden Dateien ab.
2. Hilfe und Dokumentation direkt auf dem System verwenden Vor der Verwendung unbekannter Optionen sollte die lokal installierte Dokumentation geprüft werden. ```bash [RO] man [RO] info [RO] --help [RO] apropos "" [RO] man -k "" [RO] type [RO] command -V ``` **Warum die lokale Dokumentation wichtig ist** - Sie passt normalerweise zur installierten Programmversion. - Optionen können sich zwischen Versionen unterscheiden. - Distributionen können Programme anders konfigurieren. - Nicht jeder im Internet gefundene Befehl ist auf dem Zielsystem vorhanden. - Gleichnamige Programme können aus unterschiedlichen Paketen stammen. > Befehle aus fremden Anleitungen dürfen nicht ungeprüft mit Root-Rechten ausgeführt werden.
3. Systemzustand und Auslastung überblicken ```bash [RO] uptime [RO] top [RO] free -h [RO] vmstat 1 10 [RO] cat /proc/loadavg [RO] nproc [RO] lscpu ``` Falls installiert: ```bash [RO] htop [RO] mpstat -P ALL 1 10 [RO] pidstat 1 10 ``` **Load Average richtig einordnen** Die drei Load-Average-Werte beziehen sich üblicherweise auf ungefähr 1, 5 und 15 Minuten. Sie erfassen nicht ausschließlich CPU-Auslastung, sondern unter Linux auch Tasks, die nicht unterbrechbar warten, beispielsweise auf bestimmte I/O-Vorgänge. Die Bewertung muss deshalb berücksichtigen: - Anzahl der logischen CPUs - CPU-Auslastung - I/O-Wartezeiten - Prozesszustände - Dauer der Belastung - Normalzustand des Systems - virtuelle CPU-Zuteilung - mögliche Drosselung > Ein hoher Load-Wert beweist allein weder eine CPU-Überlastung noch einen bestimmten Hardwarefehler.
4. Prozesse untersuchen ```bash [RO][SENS] ps aux [RO][SENS] ps -ef [RO][SENS] ps -eo pid,ppid,user,stat,%cpu,%mem,etime,cmd [RO][SENS] pstree -ap [RO] pgrep -a "" [RO][PRIV][SENS] lsof -p ``` **Prozesszustände** | Zustand | Grundbedeutung | |---|---| | `R` | läuft oder ist ausführbar | | `S` | unterbrechbarer Schlafzustand | | `D` | nicht unterbrechbarer Schlafzustand, häufig im Zusammenhang mit I/O | | `T` | angehalten oder verfolgt | | `Z` | Zombieprozess | Ein Zombieprozess hat seine Ausführung beendet, wurde aber vom Elternprozess noch nicht vollständig abgeholt. Das Beenden des Zombies selbst löst die Ursache normalerweise nicht; der Elternprozess muss untersucht werden. **Signale kontrolliert verwenden** ```bash [CHANGE] kill -TERM [CHANGE] kill -HUP [CHANGE][DANGER] kill -KILL ``` - `SIGTERM` fordert einen kontrollierten Abbruch an. - `SIGHUP` kann abhängig vom Programm eine Konfiguration neu einlesen oder eine andere Bedeutung besitzen. - `SIGKILL` beendet einen Prozess ohne eigene Aufräumlogik des Prozesses. > `kill -9` sollte nicht als Standardmaßnahme verwendet werden. Offene Transaktionen, temporäre Dateien oder gemeinsam genutzte Ressourcen können in einem problematischen Zustand verbleiben.
5. Systemd-Dienste prüfen ```bash [RO] systemctl status [RO] systemctl is-active [RO] systemctl is-enabled [RO] systemctl is-failed [RO] systemctl list-units --type=service --state=failed [RO] systemctl list-dependencies [RO] systemctl show [RO] systemctl cat ``` **Wichtige Unterscheidung** | Zustand | Aussage | |---|---| | `active` | Unit ist entsprechend ihrem Typ aktiv | | `inactive` | Unit ist derzeit nicht aktiv | | `failed` | Start oder Ausführung ist fehlgeschlagen | | `enabled` | Unit soll über ihre Installationsverknüpfungen automatisch eingebunden werden | | `disabled` | entsprechende automatische Einbindung ist nicht aktiviert | | `masked` | Aktivierung und Start sind durch eine Verknüpfung auf `/dev/null` blockiert | `active` beweist nicht automatisch, dass die Anwendung fachlich funktioniert. Ein Webserver kann beispielsweise laufen, während eine abhängige Datenbank oder eine bestimmte Website nicht erreichbar ist. **Ändernde Aktionen** ```bash [CHANGE][PRIV] sudo systemctl start [CHANGE][PRIV] sudo systemctl stop [CHANGE][PRIV][RESTART] sudo systemctl restart [CHANGE][PRIV] sudo systemctl reload [CHANGE][PRIV] sudo systemctl reset-failed ``` `reload` funktioniert nur, wenn die Unit beziehungsweise das Programm dies unterstützt. `reset-failed` löscht den registrierten Fehlerzustand, behebt aber nicht dessen Ursache.
6. Änderungen an Systemd-Units richtig behandeln **Effektive Unit-Konfiguration anzeigen** ```bash [RO] systemctl cat ``` **Abhängigkeiten untersuchen** ```bash [RO] systemctl list-dependencies [RO] systemctl list-dependencies --reverse ``` **Lokale Überschreibung bearbeiten** ```bash [CHANGE][PRIV] sudo systemctl edit ``` **Unit-Dateien neu einlesen** ```bash [CHANGE][PRIV] sudo systemctl daemon-reload ``` `daemon-reload` liest Unit-Dateien und die systemd-Abhängigkeitsstruktur neu ein. Es startet den betroffenen Dienst nicht automatisch neu. Vor einer Änderung müssen gesichert werden: - Originalkonfiguration - Inhalt bestehender Drop-ins - Paketzugehörigkeit - Abhängigkeiten - Startbenutzer - Umgebungsvariablen - benötigte Dateien und Verzeichnisse - Rückfallplan - erwartete Auswirkungen eines Neustarts > Paketverwaltete Unit-Dateien unter `/usr/lib/systemd/system` oder `/lib/systemd/system` sollten nicht direkt als dauerhafte Anpassungsmethode bearbeitet werden. Lokale Drop-ins verhindern, dass Paketaktualisierungen die Anpassung einfach überschreiben.
7. Journal mit Journalctl auswerten ```bash [RO][SENS] journalctl [RO][SENS] journalctl -b [RO][SENS] journalctl -b -1 [RO][SENS] journalctl -p warning [RO][SENS] journalctl -u [RO][SENS] journalctl -u -b [RO][SENS] journalctl --since "2026-08-01 14:00:00" [RO][SENS] journalctl --since "30 minutes ago" [RO][SENS] journalctl -k [RO][SENS] journalctl -f ``` **Zusätzliche Filter** ```bash [RO][SENS] journalctl _PID= [RO][SENS] journalctl _UID= [RO][SENS] journalctl _COMM= [RO][SENS] journalctl -o verbose ``` **Speicherbelegung des Journals** ```bash [RO] journalctl --disk-usage ``` Zu beachten sind: - richtiger Bootvorgang - Zeitzone und Zeitstempel - erste Fehlermeldung statt nur Folgefehler - Dienstname und Prozess-ID - Logrotation - persistente oder flüchtige Speicherung - Berechtigungen - mögliche Geheimnisse oder personenbezogene Daten > `journalctl -f` zeigt neu eintreffende Einträge. Es ersetzt nicht die Untersuchung älterer Ereignisse vor dem sichtbaren Fehler.
8. Klassische Protokolldateien untersuchen Abhängig von der Distribution und Konfiguration können relevante Dateien beispielsweise unter `/var/log` liegen. ```bash [RO][PRIV][SENS] sudo ls -lah /var/log [RO][PRIV][SENS] sudo tail -n 200 [RO][PRIV][SENS] sudo tail -f [RO][PRIV][SENS] sudo less [RO][PRIV][SENS] sudo grep -iE "error|fail|warning" ``` Mögliche Protokolle sind unter anderem: - `/var/log/syslog` - `/var/log/messages` - `/var/log/auth.log` - `/var/log/secure` - `/var/log/kern.log` - anwendungsspezifische Unterverzeichnisse Diese Pfade sind nicht auf jeder Distribution vorhanden. Ein System kann Ereignisse ausschließlich oder zusätzlich im systemd-Journal speichern. **Rotierte Protokolle** ```bash [RO][PRIV][SENS] sudo zless .gz [RO][PRIV][SENS] sudo zgrep -i "" .gz ``` > Protokolldateien dürfen nicht gelöscht oder geleert werden, bevor Ursache, Aufbewahrungspflichten und Auswirkungen auf laufende Prozesse geklärt sind.
9. Kernelmeldungen und Hardwareereignisse prüfen ```bash [RO][PRIV][SENS] sudo dmesg [RO][PRIV][SENS] sudo dmesg --ctime [RO][PRIV][SENS] sudo dmesg --level=err,warn [RO][PRIV][SENS] sudo journalctl -k -b [RO][PRIV][SENS] sudo journalctl -k -b -1 ``` Typische Suchbegriffe: ```bash [RO][PRIV][SENS] sudo dmesg --ctime | grep -iE "error|fail|timeout|reset|oom|I/O" ``` Zu untersuchen sind beispielsweise: - I/O-Fehler - Geräte-Resets - Dateisystemfehler - Treiberprobleme - Link-Änderungen - Out-of-Memory-Ereignisse - Kernel-Warnungen - Machine-Check-Ereignisse - USB-Verbindungsabbrüche - blockierte Tasks > Der Kernel-Ringpuffer ist begrenzt. Ältere Meldungen können überschrieben worden sein. Außerdem dürfen Zeitangaben aus `dmesg` nicht ungeprüft mit Zeitstempeln anderer Protokolle gleichgesetzt werden.
10. Arbeitsspeicher und OOM-Killer untersuchen ```bash [RO] free -h [RO] cat /proc/meminfo [RO][SENS] ps -eo pid,user,%mem,rss,vsz,cmd --sort=-rss [RO] vmstat 1 10 [RO][PRIV][SENS] sudo journalctl -k | grep -iE "out of memory|oom|killed process" ``` Wichtige Bereiche: - verfügbarer Speicher - Page Cache - Swap-Nutzung - Major Page Faults - Prozess-RSS - cgroup- oder Containergrenzen - Speicherwachstum über die Zeit - OOM-Auswahl des Kernels - NUMA-Zuordnung - reservierter Speicher einer VM Linux verwendet freien Arbeitsspeicher sinnvoll als Cache. Ein geringer Wert in der Spalte `free` bedeutet daher nicht automatisch Speichermangel. Für die erste Bewertung ist bei `free` insbesondere `available` relevant. **Swap-Nutzung anzeigen** ```bash [RO] swapon --show [RO] cat /proc/swaps ``` > Das Leeren von Caches oder Deaktivieren von Swap ist keine allgemeine Speicherreparatur und kann zusätzliche Last oder einen Systemausfall verursachen.
11. Datenträger, Partitionen und Einhängepunkte prüfen ```bash [RO][SENS] lsblk -f [RO][SENS] findmnt [RO] df -hT [RO] df -i [RO][PRIV][SENS] sudo fdisk -l [RO][PRIV][SENS] sudo blkid ``` **Warum `df -h` und `df -i` benötigt werden** Ein Dateisystem kann trotz freier Datenblöcke keine neuen Dateien mehr anlegen, wenn keine freien Inodes verfügbar sind. **Große Verzeichnisse ermitteln** ```bash [RO][PRIV][SENS] sudo du -xhd1 | sort -h ``` **Gelöschte, aber noch geöffnete Dateien suchen** ```bash [RO][PRIV][SENS] sudo lsof +L1 ``` Wenn ein Prozess eine gelöschte Datei noch geöffnet hält, kann der belegte Speicherplatz bis zum Schließen des Dateideskriptors weiterhin belegt bleiben. > `du` und `df` messen unterschiedliche Sachverhalte. Abweichungen beweisen nicht automatisch einen Dateisystemfehler.
12. Datenträger-I/O und Gerätezustand analysieren Falls die erforderlichen Werkzeuge installiert sind: ```bash [RO] iostat -xz 1 10 [RO][PRIV] sudo smartctl -a /dev/ [RO][PRIV] sudo nvme smart-log /dev/ ``` Zu prüfen sind: - Latenz - Warteschlangen - Auslastung - Durchsatz - I/O-Fehler - Geräte-Resets - Medienfehler - Temperatur - verbleibende Reserve - RAID- oder Storage-Layer - virtuelle Datenträger - parallele Sicherungen SMART-Werte müssen geräte- und herstellerspezifisch interpretiert werden. Ein bestandener allgemeiner SMART-Status schließt einen Defekt nicht sicher aus. > Selbsttests, Reparaturbefehle und Schreibtests können Last erzeugen oder ein vorgeschädigtes Medium zusätzlich beanspruchen. Vorher müssen Sicherungsstand und Auswirkungen geklärt werden.
13. Dateisystemfehler sicher behandeln **Dateisystemtyp und Einhängezustand prüfen** ```bash [RO][SENS] findmnt [RO][SENS] lsblk -f [RO] mount [RO][PRIV][SENS] sudo journalctl -k | grep -iE "filesystem|ext4|xfs|btrfs|I/O error" ``` Eine Dateisystemprüfung muss zum tatsächlichen Dateisystem passen. Werkzeuge für ext-Dateisysteme, XFS und Btrfs sind nicht beliebig austauschbar. ```bash [TEST][PRIV][DANGER] sudo fsck ``` > `fsck` darf nicht unüberlegt auf einem schreibend eingehängten Dateisystem ausgeführt werden. Vor einer Reparatur müssen Dateisystemtyp, Geräteziel, Einhängezustand, Sicherung und Wiederherstellungsplan eindeutig geklärt sein. Bei Root-Dateisystemen kann eine Prüfung im Rettungsmodus, über ein Wartungssystem oder beim Start erforderlich sein.
14. Netzwerkadapter und Adressen untersuchen ```bash [RO][SENS] ip -br link [RO][SENS] ip -br address [RO][SENS] ip address show [RO][SENS] ip -s link [RO][SENS] ip route show [RO][SENS] ip rule show [RO][SENS] ip neigh show ``` Zu prüfen sind: - administrativer und physischer Link-Zustand - MAC-Adresse - IPv4- und IPv6-Adressen - Präfixlängen - Standardroute - Routingtabellen - Policy Routing - Interfacefehler und Drops - Nachbartabelle - VLANs, Bonds und Bridges - virtuelle Interfaces - Network Namespace > Die früher verbreiteten Werkzeuge `ifconfig`, `route` und `netstat` werden auf vielen modernen Linux-Systemen durch Werkzeuge aus `iproute2`, insbesondere `ip` und `ss`, ersetzt.
15. Erreichbarkeit und Pfad testen ```bash [TEST][REMOTE] ping -c 4 [TEST][REMOTE] ping -6 -c 4 [TEST][REMOTE][SENS] tracepath [TEST][REMOTE][SENS] traceroute [TEST][REMOTE][SENS] mtr ``` Ein erfolgreicher Ping beweist nur, dass die verwendete ICMP-Kommunikation in dieser Richtung und zu diesem Zeitpunkt funktioniert hat. Er beweist nicht, dass: - ein bestimmter TCP- oder UDP-Port erreichbar ist - DNS korrekt arbeitet - die Anwendung antwortet - TLS funktioniert - Authentifizierung erfolgreich ist - der Rückweg für alle Verbindungen identisch ist Ein fehlgeschlagener Ping beweist umgekehrt keinen vollständigen Ausfall, da ICMP gefiltert oder begrenzt werden kann.
16. DNS-Auflösung untersuchen ```bash [RO][SENS] cat /etc/resolv.conf [RO][SENS] getent hosts [TEST][REMOTE][SENS] dig [TEST][REMOTE][SENS] dig A [TEST][REMOTE][SENS] dig AAAA [TEST][REMOTE][SENS] dig -x [TEST][REMOTE][SENS] dig @ [TEST][REMOTE][SENS] resolvectl query [RO][SENS] resolvectl status ``` `getent hosts` berücksichtigt die konfigurierte Namensdienstauflösung des Systems und kann daher für die tatsächliche Anwendungssicht aussagekräftiger sein als eine isolierte DNS-Abfrage. Zu prüfen sind: - Inhalt von `/etc/nsswitch.conf` - konfigurierte Resolver - Suchdomänen - Split DNS - lokale Hosts-Datei - Cache - VPN-Konfiguration - systemd-resolved - NetworkManager - A- und AAAA-Einträge - Reverse Lookup - DNSSEC-Fehler - unterschiedliche Antworten verschiedener Server > `/etc/resolv.conf` kann eine automatisch erzeugte Datei oder ein symbolischer Link sein. Manuelle Änderungen können überschrieben werden und sind nicht zwingend die richtige dauerhafte Konfigurationsmethode.
17. Ports, Sockets und Verbindungen prüfen ```bash [RO][PRIV][SENS] sudo ss -lntup [RO][SENS] ss -tan [RO][SENS] ss -s [RO][PRIV][SENS] sudo lsof -i [TEST][REMOTE] nc -vz [TEST][REMOTE][SENS] curl -v ``` Zu prüfen sind: - lauscht der Dienst überhaupt? - an welcher Adresse lauscht er? - IPv4, IPv6 oder beides? - stimmt der Port? - welcher Prozess besitzt den Socket? - ist nur `127.0.0.1` beziehungsweise `::1` gebunden? - erreicht der Client den Port? - kommt eine Anwendungsantwort zurück? - scheitert TLS oder Authentifizierung? - existieren viele halboffene oder wartende Verbindungen? > Ein offener TCP-Port beweist nur, dass eine Verbindung angenommen werden kann. Die fachliche Funktion der Anwendung muss separat getestet werden.
18. Netzwerkverkehr mit Tcpdump erfassen ```bash [TEST][PRIV][REMOTE][LOG][SENS] sudo tcpdump -i [TEST][PRIV][REMOTE][LOG][SENS] sudo tcpdump -i host [TEST][PRIV][REMOTE][LOG][SENS] sudo tcpdump -i port [TEST][PRIV][REMOTE][LOG][SENS] sudo tcpdump -i -nn -s 0 -w .pcap ``` Vor einer Aufzeichnung müssen festgelegt werden: - richtiges Interface - geeigneter Filter - Aufzeichnungsdauer - Speicherort - maximaler Speicherbedarf - Zeitpunkt des Fehlers - Datenschutz - sichere Übertragung - Löschfrist Eine Paketaufzeichnung kann enthalten: - IP-Adressen - DNS-Anfragen - Hostnamen - unverschlüsselte Anwendungsdaten - Sitzungsinformationen - interne Netzwerkstrukturen - Kommunikationsbeziehungen > Ohne Begrenzung kann eine Aufzeichnung sehr groß werden. Bei produktiven Systemen sollten rotierende Dateien, zeitliche Begrenzung und möglichst enge Capture-Filter verwendet werden.
19. Firewall und Paketfilter prüfen Je nach System können unterschiedliche Frameworks oder Verwaltungswerkzeuge eingesetzt werden. ```bash [RO][PRIV][SENS] sudo nft list ruleset [RO][PRIV][SENS] sudo iptables -S [RO][PRIV][SENS] sudo iptables -t nat -S [RO][PRIV][SENS] sudo firewall-cmd --list-all [RO][PRIV][SENS] sudo ufw status verbose ``` Zu prüfen sind: - tatsächlich aktives Firewall-Backend - Eingangs-, Ausgangs- und Weiterleitungsregeln - Standardrichtlinien - Regelreihenfolge - Interfaces und Zonen - Quell- und Zielnetze - Ports und Protokolle - NAT - Connection Tracking - IPv4 und IPv6 - Container- oder Virtualisierungsregeln - persistente gegenüber aktuell geladenen Regeln > Mehrere Werkzeuge können auf dasselbe oder auf unterschiedliche Backends zugreifen. Eine leere `iptables`-Ausgabe beweist daher nicht automatisch, dass keine Filterregeln aktiv sind.
20. NetworkManager untersuchen ```bash [RO][SENS] nmcli general status [RO][SENS] nmcli device status [RO][SENS] nmcli connection show [RO][SENS] nmcli device show [RO][SENS] nmcli connection show "" [RO][PRIV][SENS] journalctl -u NetworkManager -b ``` Zu prüfen sind: - verwaltete und nicht verwaltete Interfaces - aktive Verbindung - Verbindungsprofil - DHCP-Daten - DNS-Konfiguration - Route und Metrik - Autoconnect - VLAN, Bond oder Bridge - Zeitpunkt eines Linkwechsels - Konflikte mit anderen Netzwerkverwaltungen > Änderungen mit `nmcli` können eine SSH-Verbindung sofort unterbrechen. Vor Remoteänderungen sind Konsolenzugang und Rückfallplan erforderlich.
21. Benutzer, Gruppen und Berechtigungen prüfen ```bash [RO][SENS] id [RO][SENS] groups [RO][SENS] getent passwd [RO][SENS] getent group [RO][SENS] namei -l [RO][SENS] stat [RO][SENS] ls -ld [RO][SENS] getfacl ``` Bei einem Pfadproblem müssen alle übergeordneten Verzeichnisse berücksichtigt werden. Für das Durchlaufen eines Verzeichnisses ist das Ausführungsrecht am Verzeichnis entscheidend. Zu unterscheiden sind: - Eigentümer - Gruppe - klassische Modusbits - ACLs - umask - effektive Benutzer- und Gruppen-ID - ergänzende Gruppen - Mount-Optionen - SELinux oder AppArmor - Container- und Namespace-Zuordnung - NFS- oder SMB-Berechtigungen > `chmod 777` ist keine fachgerechte Standardlösung. Es kann Daten ungewollt für alle lokalen Benutzer veränderbar machen und verdeckt die eigentliche Ursache.
22. SELinux und AppArmor berücksichtigen **SELinux** ```bash [RO] getenforce [RO] sestatus [RO][PRIV][SENS] sudo ausearch -m AVC,USER_AVC -ts recent [RO][PRIV][SENS] sudo journalctl | grep -i "avc:" ``` **AppArmor** ```bash [RO] aa-status [RO][PRIV][SENS] sudo journalctl -k | grep -i apparmor ``` Ein Unix-Dateirecht kann korrekt erscheinen, während eine Mandatory-Access-Control-Richtlinie den Zugriff trotzdem verhindert. > SELinux dauerhaft zu deaktivieren oder ein AppArmor-Profil ungeprüft abzuschalten ist keine geeignete Ursachenanalyse. Zuerst müssen die konkrete Ablehnung, der betroffene Kontext und die erwartete Richtlinie festgestellt werden.
23. Geöffnete Dateien und Systemaufrufe untersuchen ```bash [RO][PRIV][SENS] sudo lsof -p [RO][PRIV][SENS] sudo lsof [RO][PRIV][SENS] sudo lsof -i : [TEST][PRIV][LOG][SENS] sudo strace -p [TEST][PRIV][LOG][SENS] sudo strace -f -o ``` `strace` kann sichtbar machen, ob ein Prozess beispielsweise an folgenden Vorgängen scheitert: - Datei öffnen - Namensauflösung - Socket-Verbindung - Berechtigungsprüfung - Lesen oder Schreiben - Warten auf ein Ereignis - Start eines Kindprozesses Die Ausgabe kann sehr umfangreich sein und sensible Daten enthalten. Außerdem kann Tracing das Zeitverhalten eines Prozesses beeinflussen. > Ein produktiver Prozess sollte nur mit geklärter Auswirkung verfolgt werden. Geheimnisse, Pfade und Nutzdaten können in der Ausgabe erscheinen.
24. Paketbestand und beschädigte Installationen prüfen **Debian- und Ubuntu-basierte Systeme** ```bash [RO][SENS] dpkg -l [RO] dpkg -S [RO] apt-cache policy [RO][PRIV] sudo dpkg --verify ``` **RPM-basierte Systeme** ```bash [RO][SENS] rpm -qa [RO] rpm -qf [RO] rpm -V [RO] dnf info ``` Zu prüfen sind: - installierte Version - Paketquelle - Abhängigkeiten - geänderte Paketdateien - unvollständige Transaktion - zurückgehaltene Pakete - gemischte Repositorys - Architektur - Zeitpunkt des Updates - erforderlicher Dienst- oder Systemneustart > Eine Paketverifikation zeigt Abweichungen, bewertet aber nicht automatisch, ob diese absichtlich, harmlos oder fehlerursächlich sind.
25. Bootvorgang untersuchen ```bash [RO] systemd-analyze [RO] systemd-analyze blame [RO] systemd-analyze critical-chain [RO][SENS] journalctl -b [RO][SENS] journalctl -b -1 [RO] systemctl --failed [RO][PRIV][SENS] sudo dmesg --ctime ``` Bei Startproblemen sind zu prüfen: - Bootloader - Kernelparameter - initramfs - Root-Dateisystem - `/etc/fstab` - Geräte-UUIDs - Mount-Zeitlimits - systemd-Abhängigkeiten - Netzwerkabhängigkeiten - verschlüsselte Datenträger - ausgefallene Dienste - vorheriger Bootvorgang `systemd-analyze blame` zeigt die Initialisierungszeit einzelner Units, beweist aber nicht allein, dass die oben angezeigte Unit den gesamten Start entsprechend verzögert hat. Parallelisierung und Abhängigkeiten müssen berücksichtigt werden.
26. Zeit und Zeitsynchronisation prüfen ```bash [RO] date [RO] timedatectl [RO] timedatectl timesync-status [RO][SENS] chronyc tracking [RO][SENS] chronyc sources -v ``` Die verfügbaren Befehle hängen vom eingesetzten Zeitdienst ab. Zu prüfen sind: - Systemzeit - Zeitzone - Hardwareuhr - aktive Synchronisation - verwendete Zeitquelle - Offset - Erreichbarkeit der Zeitserver - Virtualisierungszeitquelle - Zeitänderungen in den Protokollen - Zertifikatsgültigkeit - Kerberos- oder Verzeichnisdienstabhängigkeiten > Eine falsche Systemzeit kann Protokollkorrelation, TLS, Authentifizierung, Datenbanken und geplante Aufgaben beeinträchtigen.
27. Geplante Aufgaben untersuchen ```bash [RO][SENS] crontab -l [RO][PRIV][SENS] sudo crontab -l [RO][PRIV][SENS] sudo ls -la /etc/cron.* [RO] systemctl list-timers --all [RO] systemctl status .timer [RO][SENS] journalctl -u .timer [RO][SENS] journalctl -u .service ``` Typische Fehlerursachen: - anderer Benutzerkontext - eingeschränkte Umgebungsvariablen - anderer `PATH` - relative Pfade - fehlende Ausführungsrechte - nicht vorhandenes Arbeitsverzeichnis - gesperrte Dateien - Zeitzone - überlappende Ausführungen - fehlgeschlagene Weiterleitung der Ausgabe - Timer oder Dienst deaktiviert > Ein Skript, das in einer interaktiven Shell funktioniert, muss unter Cron oder einem systemd-Timer nicht mit derselben Umgebung ausgeführt werden.
28. Container und Virtualisierung berücksichtigen ```bash [RO] systemd-detect-virt [RO][SENS] cat /proc/1/cgroup [RO][SENS] lsns [RO][SENS] docker ps [RO][SENS] podman ps [RO][SENS] docker inspect [RO][SENS] docker logs ``` Bei Containerproblemen müssen Host und Container getrennt untersucht werden: - Prozess im Container - Containerzustand - Restart Policy - Exit-Code - Healthcheck - Logs - Portveröffentlichung - Container-Netzwerk - DNS - Volumes und Bind Mounts - Benutzer-ID - cgroup-Grenzen - Host-Firewall - Host-Speicherplatz - Host-Kernel > Ein laufender Container beweist nicht, dass der darin betriebene Dienst erreichbar oder funktionsfähig ist. Ein Container verwendet grundsätzlich den Kernel des Hosts und ist keine vollständige virtuelle Maschine.
29. Bash-Skripte kontrolliert debuggen **Syntax prüfen** ```bash [RO] bash -n ``` **Ablauf mit Trace ausführen** ```bash [TEST][LOG][SENS] bash -x ``` In einem Skript kann die Trace-Ausgabe abschnittsweise aktiviert werden: ```bash set -x set +x ``` Zu prüfen sind: - Shebang - Shell-Kompatibilität - Variablen - Quoting - Leerzeichen in Pfaden - Rückgabecodes - Pipelines - relative Pfade - Benutzerkontext - Umgebungsvariablen - Dateirechte - parallele Ausführung > `set -x` kann Kennwörter, Tokens, Argumente und andere Geheimnisse in Protokolle schreiben. Es darf nicht unkontrolliert in produktiven Skripten aktiviert werden.
30. Typische Fehlerbilder und geeignete Werkzeuge | Fehlerbild | Geeignete Prüfungen | |---|---| | Dienst startet nicht | `systemctl status`, `journalctl -u`, Unit-Konfiguration, Abhängigkeiten, Rechte | | Server reagiert langsam | `uptime`, `top`, `vmstat`, `iostat`, `free`, Prozess- und I/O-Analyse | | Datenträger voll | `df -hT`, `df -i`, `du`, `lsof +L1`, Journalgröße | | Prozess wird beendet | Kerneljournal, OOM-Meldungen, cgroup-Grenzen, Dienstkonfiguration | | Port nicht erreichbar | `ss`, Dienst-Bindung, Firewall, Route, `nc`, `tcpdump` | | Hostname wird falsch aufgelöst | `getent`, `dig`, `resolvectl`, `nsswitch.conf`, Hosts-Datei | | Netzwerk fällt sporadisch aus | Linkstatistik, NetworkManager-Journal, Route, `mtr`, `tcpdump` | | Datei kann nicht geöffnet werden | `namei`, `stat`, `getfacl`, SELinux/AppArmor, `lsof`, `strace` | | System bootet langsam | `systemd-analyze`, vorheriges Journal, Mounts, Abhängigkeiten | | Root-Dateisystem nur lesbar | Kernelmeldungen, I/O-Fehler, Dateisystemzustand, Storage | | Cronjob läuft nicht | Benutzerkontext, Umgebung, absolute Pfade, Cronlogs, Exit-Code | | Container startet ständig neu | Containerstatus, Exit-Code, Logs, Healthcheck, Volumes, Ressourcen | | Anwendung funktioniert lokal, aber nicht remote | Bind-Adresse, Firewall, Routing, NAT, DNS, TLS | | Zeitstempel sind unplausibel | `timedatectl`, Zeitdienst, Zeitzone, VM-Zeitquelle | | Änderungen verschwinden nach Neustart | persistente Konfiguration, generierte Dateien, NetworkManager, systemd-Drop-ins |
31. Empfohlener Gesamtablauf bei Linux-Problemen 1. vollständige Fehlermeldung erfassen. 2. Benutzer, Host, Dienst und Zeitpunkt dokumentieren. 3. Umfang und Reproduzierbarkeit bestimmen. 4. letzte Änderung feststellen. 5. Distribution, Version, Kernel und Laufzeitumgebung erfassen. 6. Systemzeit und Uptime prüfen. 7. CPU, Load, Arbeitsspeicher und I/O überblicken. 8. Speicherplatz und Inodes prüfen. 9. betroffenen Prozess oder Dienst bestimmen. 10. Dienststatus und Abhängigkeiten prüfen. 11. Journal im passenden Zeitfenster auswerten. 12. Kernelmeldungen kontrollieren. 13. Konfiguration und Berechtigungen prüfen. 14. SELinux oder AppArmor berücksichtigen. 15. bei Netzwerkproblemen Adapter, Adressen und Routen prüfen. 16. DNS-Auflösung über den tatsächlich verwendeten Resolver testen. 17. Ports und Bind-Adressen prüfen. 18. Firewall und Paketpfad untersuchen. 19. bei Bedarf eng gefilterte Paketaufzeichnung erstellen. 20. Hypothese aus mehreren Befunden formulieren. 21. kleinste reversible Maßnahme planen. 22. Sicherung und Rückfallplan prüfen. 23. Änderung kontrolliert durchführen. 24. denselben Fehlerfall erneut testen. 25. Dienste, Logs und Monitoring nachkontrollieren. 26. temporäres Debugging deaktivieren. 27. Ursache, Maßnahme und Ergebnis dokumentieren.
32. Gefährliche Fehlinterpretationen vermeiden | Beobachtung | Nicht automatisch bewiesen | |---|---| | Prozess erscheint in `ps` | Anwendung funktioniert | | Dienst ist `active` | Dienst ist fachlich erreichbar | | Port steht auf `LISTEN` | Remotezugriff funktioniert | | Ping funktioniert | TCP, UDP, DNS und Anwendung funktionieren | | DNS liefert eine Adresse | Adresse ist aktuell und der Dienst erreichbar | | `free` zeigt wenig freien RAM | akuter Speichermangel | | Load Average ist hoch | ausschließlich CPU-Überlastung | | `df` zeigt freien Platz | genügend freie Inodes vorhanden | | `du` ist kleiner als `df` | Dateisystem ist beschädigt | | SMART meldet `PASSED` | Datenträger ist fehlerfrei | | Firewallregel existiert | sie trifft in der gewünschten Richtung zu | | Dateirechte sind korrekt | SELinux, AppArmor oder ACLs erlauben den Zugriff | | Neustart behebt das Symptom | Ursache ist behoben | | Paketdatei wurde verändert | Veränderung verursacht den Fehler | | Container läuft | Anwendung im Container ist gesund | | keine Fehlermeldung sichtbar | Vorgang war erfolgreich |
33. Sicherheits- und Datenschutzanforderungen Linux-Diagnosedaten können enthalten: - Benutzernamen und Gruppen - Hostnamen - interne IP-Adressen - MAC-Adressen - DNS-Namen - Prozessargumente - Dateipfade - Umgebungsvariablen - Netzwerkverbindungen - Paketmitschnitte - SSH-Zugriffe - Authentifizierungsereignisse - Containerkonfigurationen - Volume-Pfade - Tokens und Zugangsdaten - interne Anwendungsdaten Vor einer Weitergabe müssen: 1. Zweck und Empfänger bestimmt werden. 2. nur erforderliche Daten erfasst werden. 3. Kennwörter, Schlüssel, Cookies und Tokens entfernt werden. 4. personenbezogene Angaben redigiert werden. 5. Paketmitschnitte besonders geschützt werden. 6. Dateien verschlüsselt übertragen werden. 7. Zugriffsrechte und Aufbewahrungsdauer festgelegt werden. 8. temporäres Debugging deaktiviert werden. 9. nicht mehr benötigte Diagnosedaten sicher gelöscht werden. 10. externe Analysedienste organisatorisch freigegeben sein. > Shell-History, Prozesslisten und Trace-Ausgaben können Geheimnisse enthalten, wenn diese als Befehlsargumente übergeben wurden.
34. Dokumentationsvorlage ```text Ticket: Datum und Uhrzeit: Bearbeiter: Hostname: Distribution: Version: Kernel: Architektur: Physisch, VM oder Container: Zeitzone: Uptime: Betroffener Benutzer: Betroffener Dienst: Betroffener Prozess: PID: Originale Fehlermeldung: Fehlerzeitpunkt: Reproduzierbar: Betroffene Systeme: Letzte funktionierende Nutzung: Letzte Änderung: CPU-Auslastung: Load Average: Arbeitsspeicher: Swap: OOM-Ereignis: Datenträgerauslastung: Freier Speicher: Freie Inodes: I/O-Wartezeit: Dateisystem: Mount-Optionen: Kernelmeldungen: Dienststatus: Unit-Datei: Drop-ins: Abhängigkeiten: Startbenutzer: Exit-Code: Journal-Zeitraum: Erste relevante Fehlermeldung: Interface: IP-Adresse: Präfix: Gateway: Route: DNS-Server: DNS-Ergebnis: Lauschadresse: Port: Firewall: Paketaufzeichnung: Dateipfad: Eigentümer: Gruppe: Modus: ACL: SELinux: AppArmor: Geöffnete Dateien: Strace verwendet: Paket: Installierte Version: Paketquelle: Verifikation: Letztes Update: Vermutete Ursache: Belege: Geplante Maßnahme: Sicherung: Rückfallplan: Durchgeführte Änderung: Testergebnis: Monitoring: Abschluss: ```
--- **Merksatz** > Bei der Linux-Fehleranalyse wird zuerst der Zustand gesichert und anschließend die Abhängigkeitskette geprüft: Hardware und Kernel stellen die Grundlage bereit, Dateisystem und Netzwerk ermöglichen den Zugriff, Benutzerrechte und Sicherheitsrichtlinien kontrollieren die Berechtigung, Dienste stellen die Funktion bereit und Protokolle verbinden Fehler, Zeitpunkt und Ursache. **Quellen und weiterführende Dokumentation** - [freedesktop.org – systemctl](https://www.freedesktop.org/software/systemd/man/latest/systemctl.html) - [freedesktop.org – journalctl](https://www.freedesktop.org/software/systemd/man/latest/journalctl.html) - [freedesktop.org – systemd-journald](https://www.freedesktop.org/software/systemd/man/latest/systemd-journald.service.html) - [freedesktop.org – systemd.service](https://www.freedesktop.org/software/systemd/man/latest/systemd.service.html) - [freedesktop.org – systemd.unit](https://www.freedesktop.org/software/systemd/man/latest/systemd.unit.html) - [freedesktop.org – systemd-analyze](https://www.freedesktop.org/software/systemd/man/latest/systemd-analyze.html) - [Linux man-pages – Übersicht](https://man7.org/linux/man-pages/dir_all_alphabetic.html) - [Linux man-pages – proc](https://man7.org/linux/man-pages/man5/proc.5.html) - [Linux man-pages – ps](https://man7.org/linux/man-pages/man1/ps.1.html) - [Linux man-pages – kill](https://man7.org/linux/man-pages/man1/kill.1.html) - [Linux man-pages – ip](https://man7.org/linux/man-pages/man8/ip.8.html) - [Linux man-pages – ss](https://man7.org/linux/man-pages/man8/ss.8.html) - [Linux man-pages – mount](https://man7.org/linux/man-pages/man8/mount.8.html) - [Linux man-pages – namespaces](https://man7.org/linux/man-pages/man7/namespaces.7.html) - [Linux Kernel Documentation – Administrator’s Guide](https://docs.kernel.org/admin-guide/index.html) - [Linux Kernel Documentation – Kernel Parameters](https://docs.kernel.org/admin-guide/kernel-parameters.html) - [Linux Kernel Documentation – Kdump](https://docs.kernel.org/admin-guide/kdump/kdump.html) - [Linux Kernel Documentation – Magic SysRq](https://docs.kernel.org/admin-guide/sysrq.html) - [Red Hat – Network Troubleshooting and Performance Tuning](https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/html/network_troubleshooting_and_performance_tuning/) - [Red Hat – NetworkManager Debugging](https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/html/network_troubleshooting_and_performance_tuning/introduction-to-networkmanager-debugging) # 5.5 macOS – Werkzeuge zur Fehleranalyse **Kurz erklärt** macOS stellt grafische Diagnoseprogramme und zahlreiche Unix-Werkzeuge im Terminal bereit. Damit lassen sich unter anderem folgende Bereiche untersuchen: - Hardware und Betriebssystem, - Prozesse und Ressourcenauslastung, - Arbeitsspeicher, - Datenträger und APFS, - Netzwerk und DNS, - Dienste und Hintergrundprozesse, - System- und Anwendungsprotokolle, - Energieverwaltung, - Berechtigungen und Datenschutz, - Systemerweiterungen, - Startprobleme, - interne Hardwarefehler. Viele Terminalbefehle ähneln Linux-Befehlen. macOS verwendet jedoch eigene Komponenten und Verwaltungsmechanismen, beispielsweise: - APFS, - `launchd`, - Unified Logging, - System Integrity Protection, - Transparency, Consent, and Control, - Gatekeeper, - Apple-Systemerweiterungen, - macOS-Wiederherstellung. > Ein Symptom ist noch keine Ursache. Auch unter macOS müssen zuerst Zustand, Zeitpunkt, Umfang und betroffene Komponente bestimmt werden, bevor Einstellungen verändert, Dateien gelöscht oder Dienste neu gestartet werden. --- **1. Sichere Arbeitsweise** Vor einer Veränderung sollten möglichst viele Informationen im fehlerhaften Zustand gesichert werden. **Empfohlene Reihenfolge** 1. Störung und erwartetes Verhalten beschreiben. 2. Zeitpunkt und letzte Änderungen feststellen. 3. betroffene Benutzer, Geräte und Anwendungen bestimmen. 4. Systemversion und Hardwaremodell erfassen. 5. Prozess-, Ressourcen- und Netzwerkzustand dokumentieren. 6. relevante Protokolle sichern. 7. eine prüfbare Hypothese formulieren. 8. eine möglichst kleine und reversible Prüfung durchführen. 9. Ergebnis und Nebenwirkungen dokumentieren. 10. erst danach eine dauerhafte Lösung umsetzen. **Vor Veränderungen prüfen** - Ist ein aktuelles Backup vorhanden? - Werden durch den Befehl Daten verändert oder gelöscht? - Muss eine Anwendung vorher beendet werden? - Wird ein produktiver Dienst unterbrochen? - werden flüchtige Diagnoseinformationen vernichtet? - ist ein Neustart tatsächlich erforderlich? - bestehen Datenschutz- oder Geheimhaltungsanforderungen? - ist die Maßnahme mit MDM-, Sicherheits- oder Unternehmensrichtlinien vereinbar? **Wichtige Schutzmechanismen** | Mechanismus | Bedeutung für die Fehleranalyse | |---|---| | Benutzerrechte | Viele Informationen sind nur für den aktuellen Benutzer sichtbar. | | `sudo` | Führt einen Befehl mit erhöhten Rechten aus, hebt aber nicht automatisch alle macOS-Schutzmechanismen auf. | | TCC | Kontrolliert unter anderem den Zugriff auf Dateien, Kamera, Mikrofon, Bildschirmaufnahme und Bedienungshilfen. | | Festplattenvollzugriff | Kann für Terminal oder Diagnoseprogramme erforderlich sein, um geschützte Daten einzusehen. | | SIP | Schützt kritische Systembereiche und Systemprozesse vor Veränderungen. | | Gatekeeper | Bewertet heruntergeladene Programme und deren Signatur beziehungsweise Beglaubigung. | | FileVault | verschlüsselt das Startvolume und beeinflusst Zugriff und Wiederherstellung. | | MDM | Kann Einstellungen, Profile, Erweiterungen und Sicherheitsrichtlinien zentral vorgeben. | > `sudo` und Festplattenvollzugriff sind nicht dasselbe. Ein als Administrator ausgeführter Prozess kann weiterhin durch TCC oder SIP eingeschränkt werden. --- **2. Schnelle Systemübersicht** Vor einer tieferen Analyse sollten Betriebssystem, Hardware, Laufzeit und Zeitpunkt erfasst werden. **macOS-Version anzeigen** ```bash sw_vers ``` Typische Ausgabe: ```text ProductName: macOS ProductVersion: 14.7.4 BuildVersion: 23H420 ``` Nur die Versionsnummer: ```bash sw_vers -productVersion ``` Nur die Buildnummer: ```bash sw_vers -buildVersion ``` **Kernel und Architektur anzeigen** ```bash uname -a ``` ```bash uname -m ``` Typische Architekturen: | Ausgabe | Bedeutung | |---|---| | `arm64` | Prozess läuft nativ auf einem Mac mit Apple-Chip | | `x86_64` | Intel-Prozess oder unter bestimmten Bedingungen ein durch Rosetta übersetzter Prozess | **Hardware- und Systembericht** ```bash system_profiler SPHardwareDataType SPSoftwareDataType ``` Kompaktere Darstellung: ```bash system_profiler SPHardwareDataType SPSoftwareDataType -detailLevel mini ``` Alle verfügbaren Datentypen anzeigen: ```bash system_profiler -listDataTypes ``` Bestimmte Bereiche gezielt untersuchen: ```bash system_profiler SPNetworkDataType ``` ```bash system_profiler SPUSBDataType ``` ```bash system_profiler SPThunderboltDataType ``` ```bash system_profiler SPBluetoothDataType ``` ```bash system_profiler SPStorageDataType ``` ```bash system_profiler SPPowerDataType ``` ```bash system_profiler SPDisplaysDataType ``` > Ein vollständiger Aufruf von `system_profiler` kann umfangreich sein und längere Zeit benötigen. Für eine gezielte Fehleranalyse sollten nur die relevanten Datentypen abgefragt werden. **Laufzeit und Last** ```bash uptime ``` **Aktuelles Datum und Zeitzone** ```bash date ``` ```bash systemsetup -gettimezone ``` `systemsetup` benötigt für viele Abfragen Administratorrechte: ```bash sudo systemsetup -gettimezone ``` **Computername und Hostnamen** ```bash scutil --get ComputerName ``` ```bash scutil --get LocalHostName ``` ```bash scutil --get HostName ``` Wenn kein expliziter HostName gesetzt wurde, kann der letzte Befehl eine Fehlermeldung ausgeben. Das beweist allein keine Störung. --- **3. „Über diesen Mac“ und Systeminformationen** Die grafische App **Systeminformationen** zeigt Hardware-, Netzwerk- und Softwareinformationen an. **Öffnen** - Apple-Menü → **Über diesen Mac** → **Weitere Infos** → **Systembericht** - oder über Spotlight nach **Systeminformationen** suchen - oder im Terminal: ```bash open -a "System Information" ``` **Geeignete Diagnosebereiche** - Hardwareübersicht, - Stromversorgung, - Speicher, - Grafik und Displays, - USB, - Thunderbolt beziehungsweise USB4, - Bluetooth, - Netzwerk, - WLAN, - installierte Programme, - Systemerweiterungen, - Drucker, - Speichergeräte. **Typische Fragestellungen** - Wird ein USB-Gerät überhaupt erkannt? - Ist ein externer Datenträger auf Hardwareebene sichtbar? - Welcher Netzwerkadapter gehört zu welchem BSD-Gerätenamen? - Wird ein Display erkannt? - Welche System- oder Netzwerkerweiterungen sind installiert? - Welche Akkudaten und Ladezyklen werden gemeldet? > Wenn ein Gerät in den Systeminformationen erscheint, ist zunächst nur seine Erkennung bestätigt. Daraus folgt noch nicht, dass Treiber, Berechtigungen, Anwendung und vollständige Funktion korrekt sind. --- **4. Aktivitätsanzeige** Die **Aktivitätsanzeige** ist das zentrale grafische Werkzeug zur Untersuchung laufender Prozesse und der Ressourcennutzung. **Öffnen** ```bash open -a "Activity Monitor" ``` Je nach Spracheinstellung wird die App als **Aktivitätsanzeige** dargestellt. **Wichtige Bereiche** | Bereich | wichtige Informationen | |---|---| | CPU | CPU-Anteil, CPU-Zeit, Threads, nicht reagierende Prozesse | | Speicher | Speicherverbrauch, Speicherdruck, komprimierter Speicher, Swap | | Energie | Energiebedarf einzelner Anwendungen | | Festplatte | gelesene und geschriebene Daten | | Netzwerk | empfangene und gesendete Daten und Pakete | **Darstellung richtig auswählen** Über **Darstellung** kann festgelegt werden, welche Prozesse angezeigt werden: - alle Prozesse, - alle Prozesse hierarchisch, - eigene Prozesse, - Systemprozesse, - aktive Prozesse, - Prozesse mit Fenstern. Ein Prozess kann ansonsten übersehen werden, obwohl er weiterhin ausgeführt wird. **Speicherdruck interpretieren** | Zustand | Einordnung | |---|---| | Grün | Speicher kann derzeit effizient bereitgestellt werden. | | Gelb | Speicherressourcen stehen unter zunehmendem Druck. | | Rot | Der verfügbare Speicher reicht für die aktuelle Last nicht angemessen aus. | Nicht allein der Wert „freier Speicher“ ist entscheidend. macOS verwendet freien Arbeitsspeicher bewusst als Cache. Aussagekräftiger sind: - Speicherdruck, - Swap-Nutzung, - Komprimierung, - Entwicklung über einen längeren Zeitraum, - Zusammenhang mit dem Auftreten der Störung. **Prozess beenden** Die Aktivitätsanzeige bietet: - **Beenden** – fordert einen geordneten Abbruch an, - **Sofort beenden** – beendet den Prozess unmittelbar. Vor dem Beenden prüfen: - Sind ungespeicherte Daten vorhanden? - Handelt es sich um einen Systemprozess? - startet `launchd` den Prozess automatisch neu? - ist der Prozess Ursache oder nur von einer anderen Störung betroffen? > Ein Prozess mit hoher CPU-Auslastung ist nicht automatisch fehlerhaft. Entscheidend sind Arbeitslast, Dauer, Benutzerwirkung und erwartetes Verhalten. --- **5. Prozesse im Terminal untersuchen** **Prozessliste** ```bash ps aux ``` Nach einem Prozess suchen: ```bash ps aux | grep -i "prozessname" ``` Damit der Suchbefehl selbst nicht als Treffer erscheint: ```bash pgrep -afil "prozessname" ``` **Prozesse hierarchisch anzeigen** ```bash ps -axo pid,ppid,user,%cpu,%mem,state,start,time,command ``` **Momentaufnahme der Ressourcennutzung** ```bash top -l 1 ``` Nach CPU-Auslastung sortieren: ```bash top -l 1 -o cpu ``` Nach Speicherverbrauch sortieren: ```bash top -l 1 -o mem ``` Nur einen bestimmten Prozess beobachten: ```bash top -pid 1234 ``` `1234` muss durch die tatsächliche Prozess-ID ersetzt werden. **Signal zum geordneten Beenden senden** ```bash kill 1234 ``` **Erzwungenes Beenden** ```bash kill -9 1234 ``` `SIGKILL` sollte nur verwendet werden, wenn ein geordneter Abbruch nicht funktioniert. Der Prozess kann dann keine Aufräumarbeiten mehr ausführen oder Daten geordnet speichern. **Prozess untersuchen** ```bash sample 1234 10 ``` Der Befehl erstellt für zehn Sekunden Stichproben der ausgeführten Funktionen. Das kann bei hoher CPU-Auslastung oder blockierten Prozessen helfen. **Geöffnete Dateien und Verbindungen** ```bash lsof -p 1234 ``` Alle offenen Dateien mit einem bestimmten Pfad suchen: ```bash lsof "/Pfad/zur/Datei" ``` Prozess ermitteln, der einen TCP-Port verwendet: ```bash lsof -nP -iTCP:8080 ``` Nur TCP-Listener anzeigen: ```bash lsof -nP -iTCP -sTCP:LISTEN ``` **Bewertung** | Beobachtung | mögliche Hypothese | |---|---| | dauerhaft hohe CPU-Last | Endlosschleife, rechenintensive Aufgabe, fehlerhafte Erweiterung | | steigender Speicherverbrauch | Speicherleck, ungewöhnliche Datenmenge, Cache-Verhalten | | Prozess reagiert nicht | blockierte Ein-/Ausgabe, Deadlock, abhängiger Dienst | | Prozess startet nach Beenden erneut | Verwaltung durch `launchd`, Login-Objekt oder MDM | | Port ist bereits belegt | konkurrierender Dienst oder zweite Programminstanz | | Datei bleibt geöffnet | Prozess verhindert Aushängen, Verschieben oder Löschen | Diese Beobachtungen sind Hinweise, aber noch keine bestätigten Ursachen. --- **6. Arbeitsspeicher untersuchen** **Speicherstatistik** ```bash vm_stat ``` Die Werte werden überwiegend in Speicherseiten ausgegeben. Die Seitengröße steht in der ersten Ausgabezeile und darf nicht pauschal als immer identisch angenommen werden. **Speicherdruck prüfen** ```bash memory_pressure ``` **Swap-Nutzung** ```bash sysctl vm.swapusage ``` **Wichtige Zusammenhänge** - Hohe Speichernutzung allein beweist keinen Engpass. - Dateicaches dürfen einen großen Teil des Speichers verwenden. - Komprimierter Speicher ist Teil der normalen Speicherverwaltung. - Dauerhaft hoher Speicherdruck und starke Swap-Aktivität können auf einen Engpass hinweisen. - Ein einzelner Messwert reicht nicht zur Beurteilung einer zeitabhängigen Störung. **Geeignete Beweiskette** 1. Zeitpunkt der Verlangsamung bestimmen. 2. Speicherdruck in der Aktivitätsanzeige prüfen. 3. Swap- und Komprimierungswerte erfassen. 4. Prozesse nach Speicherverbrauch sortieren. 5. Entwicklung über einen längeren Zeitraum beobachten. 6. Anwendungs- und Systemprotokolle zum gleichen Zeitpunkt auswerten. --- **7. CPU- und Systemlast untersuchen** **CPU-Übersicht** ```bash top -l 1 -o cpu ``` **Lastmittelwerte** ```bash uptime ``` Die drei Load-Average-Werte beziehen sich auf unterschiedliche Zeiträume. Sie dürfen nicht direkt wie Prozentwerte interpretiert werden. **Prozessbezogene Stichprobe** ```bash sample 1234 10 ``` **Systemweite Diagnose bei Hängern** ```bash sudo spindump ``` `spindump` sammelt umfangreiche Informationen über Prozesszustände und Aufrufstapel. Die Erfassung kann kurzfristig zusätzliche Last erzeugen und sensible Informationen enthalten. **Mögliche Ursachen hoher CPU-Auslastung** - legitime Medienverarbeitung, - Indizierung durch Spotlight, - Synchronisation, - Update- oder Installationsvorgang, - Browserprozess, - fehlerhafte Anwendung, - Erweiterung oder Plug-in, - wiederholt abstürzender und neu gestarteter Dienst, - Hintergrundanalyse nach einem Systemupdate. > Erst prüfen, welche Arbeit der Prozess ausführt und ob die Last nach Abschluss der Aufgabe wieder sinkt. --- **8. Datenträger, APFS und Speicherplatz** **Dateisystembelegung** ```bash df -h ``` Nur das Startvolume: ```bash df -h / ``` **Verzeichnisgrößen** ```bash du -sh ~/Downloads ``` Unterverzeichnisse vergleichen: ```bash du -sh ~/Library/* 2>/dev/null ``` Fehlende Berechtigungen oder TCC-Schutz können dazu führen, dass nicht alle Verzeichnisse gelesen werden. **Datenträgerstruktur** ```bash diskutil list ``` **Informationen zum Startvolume** ```bash diskutil info / ``` **APFS-Struktur** ```bash diskutil apfs list ``` **Volume schreibgeschützt prüfen** ```bash diskutil verifyVolume / ``` Das Prüfen kann Zeit und Ein-/Ausgabeleistung beanspruchen. Für produktive Systeme sollte die Auswirkung vorher bewertet werden. **Festplattendienstprogramm öffnen** ```bash open -a "Disk Utility" ``` In der App sollte für eine vollständige Darstellung gewählt werden: **Darstellung → Alle Geräte einblenden** Dadurch werden die Ebenen sichtbar: 1. physisches Speichergerät, 2. Partition beziehungsweise APFS-Container, 3. APFS-Volume, 4. gegebenenfalls APFS-Volumegruppe. **Erste Hilfe** Apple empfiehlt, bei einer Prüfung mit dem letzten Volume eines Speichergeräts zu beginnen und anschließend nacheinander weitere Volumes, Container und zuletzt das physische Speichergerät zu prüfen. **Wichtige Grenzen** - „Erste Hilfe“ ersetzt kein Backup. - Ein physisch ausfallendes Speichergerät lässt sich nicht durch eine Dateisystemreparatur heilen. - Reparaturversuche können ein bereits instabiles Gerät zusätzlich belasten. - Bei ungewöhnlichen Geräuschen, E/A-Fehlern oder Ausfallwarnungen sollten zuerst wichtige Daten gesichert werden. - Löschen, Partitionieren und Wiederherstellen sind keine Diagnosebefehle und können Daten vernichten. **Datenträgeraktivität beobachten** ```bash iostat -w 1 ``` Abbruch mit: ```text Control + C ``` **Dateisystemzugriffe live beobachten** ```bash sudo fs_usage ``` Nach einem Prozess filtern: ```bash sudo fs_usage -w -f filesystem | grep -i "prozessname" ``` `fs_usage` kann sehr viele Daten erzeugen und zusätzliche Last verursachen. **Typische Fehlerbilder** | Symptom | zu prüfen | |---|---| | Startvolume fast voll | `df`, große Benutzerdateien, lokale Snapshots, Caches, Protokolle | | Volume wird nicht aktiviert | `diskutil list`, `diskutil info`, Dateisystemzustand | | externes Laufwerk fehlt | Systeminformationen, Kabel, Stromversorgung, USB-/Thunderbolt-Erkennung | | langsame Dateizugriffe | `iostat`, `fs_usage`, Synchronisation, Verschlüsselung, Datenträgerzustand | | Dateien können nicht gelöscht werden | Berechtigungen, Flags, erweiterte Attribute, geöffnete Dateien | | Volume ist schreibgeschützt | Dateisystemfehler, Bereitstellungsoptionen, Medium, Berechtigungen | --- **9. Dateien, Berechtigungen und Attribute** macOS verwendet neben klassischen Unix-Rechten weitere Eigenschaften: - Access Control Lists, - Dateiflags, - erweiterte Attribute, - TCC-Berechtigungen, - SIP-Schutz, - Sandbox-Regeln. **Datei ausführlich anzeigen** ```bash ls -leO@ "/Pfad/zur/Datei" ``` Bedeutung: | Option | Anzeige | |---|---| | `-l` | ausführliche Dateiinformationen | | `-e` | Access Control Lists | | `-O` | Dateiflags | | `-@` | erweiterte Attribute | **Dateimetadaten** ```bash stat "/Pfad/zur/Datei" ``` **Erweiterte Attribute** ```bash xattr -l "/Pfad/zur/Datei" ``` Rekursiv anzeigen: ```bash xattr -lr "/Pfad/zum/Ordner" ``` **Besitz und Rechte** ```bash ls -ld "/Pfad/zum/Ordner" ``` **Geöffnete Datei ermitteln** ```bash lsof "/Pfad/zur/Datei" ``` **Typische Ursachen für „Operation not permitted“** - fehlender Festplattenvollzugriff, - verweigerte TCC-Berechtigung, - SIP-geschützter Bereich, - Anwendungssandbox, - fehlende Unix-Rechte, - ACL-Regel, - Dateiflag, - MDM-Richtlinie. > Eine Berechtigungsfehlermeldung sollte nicht sofort mit `chmod 777`, rekursivem `chown` oder dem Entfernen aller Attribute beantwortet werden. Zuerst muss geklärt werden, welcher Schutzmechanismus den Zugriff verhindert. --- **10. Unified Logging und die App „Konsole“** macOS verwendet ein zentrales Protokollsystem, das strukturierte Meldungen, Aktivitäten und Signposts verarbeiten kann. **Konsole öffnen** ```bash open -a Console ``` Die App kann unter anderem anzeigen: - Live-Protokollmeldungen, - Absturzberichte, - Diagnoseberichte, - Spin-Berichte, - Systemberichte, - Protokolle verbundener Geräte. **Wichtige Filterkriterien** - Zeitpunkt, - Prozess, - Subsystem, - Kategorie, - Meldungstext, - Schweregrad, - betroffener Benutzer, - Ereignisse unmittelbar vor und nach der Störung. **Aktuelle Protokolle anzeigen** ```bash log show --last 1h --style compact ``` Nur Meldungen eines Prozesses: ```bash log show --last 1h --style compact --predicate 'process == "Safari"' ``` Nach einem Textbestandteil suchen: ```bash log show --last 1h --style compact --predicate 'eventMessage CONTAINS[c] "error"' ``` Live-Meldungen verfolgen: ```bash log stream --style compact ``` Live nach Prozess filtern: ```bash log stream --style compact --predicate 'process == "Safari"' ``` Nach Subsystem filtern: ```bash log show --last 1h --style compact --predicate 'subsystem == "com.apple.network"' ``` Ob ein bestimmtes Subsystem tatsächlich verwendet wird, muss anhand vorhandener Ereignisse geprüft werden. **Zeitfenster gezielt festlegen** ```bash log show --start "2026-08-01 14:00:00" --end "2026-08-01 14:30:00" --style compact ``` **Logarchiv sammeln** ```bash sudo log collect --last 1h --output ~/Desktop/SystemLogs.logarchive ``` Vor dem Weitergeben eines Logarchivs prüfen, ob es enthält: - Benutzernamen, - Dateipfade, - Netzwerkadressen, - Gerätenamen, - Anwendungsdaten, - interne Servernamen, - andere vertrauliche Informationen. **Fehlinterpretationen vermeiden** | Beobachtung | korrekte Einordnung | |---|---| | Meldung enthält „error“ | Kann relevant sein, beweist aber nicht automatisch die Ursache. | | keine sichtbare Fehlermeldung | Protokollierung kann eingeschränkt, verzögert, privat oder in einem anderen Subsystem erfolgt sein. | | viele Meldungen eines Prozesses | Hohe Meldungszahl ist nicht automatisch ein Fehler. | | Meldung liegt zeitlich nach dem Symptom | Sie kann Folge statt Ursache sein. | | wiederkehrende Warnung | Bedeutung muss mit Funktion, Zeitpunkt und Auswirkung abgeglichen werden. | > Protokolle sollten nicht ausschließlich nach den Wörtern „error“ oder „failed“ durchsucht werden. Entscheidend sind zeitlicher Zusammenhang, betroffene Komponente und technische Bedeutung. --- **11. Absturz- und Diagnoseberichte** Typische benutzerbezogene Diagnoseberichte befinden sich unter: ```text ~/Library/Logs/DiagnosticReports/ ``` Systemweite Berichte können sich unter folgendem Pfad befinden: ```text /Library/Logs/DiagnosticReports/ ``` Inhalte anzeigen: ```bash ls -lt ~/Library/Logs/DiagnosticReports/ ``` Nach einem Programmnamen suchen: ```bash find ~/Library/Logs/DiagnosticReports -type f -iname "*Programmname*" ``` **Typische Berichtstypen** | Bericht | mögliche Bedeutung | |---|---| | Crash Report | Prozess wurde durch einen Fehler oder ein Signal beendet | | Hang Report | Anwendung reagierte über einen bestimmten Zeitraum nicht | | Spin Report | Prozess war aktiv, konnte aber nicht angemessen fortfahren | | Panic Report | schwerwiegender Kernel- oder Hardwarekontext | | Jetsam-/Ressourcenbericht | Prozessbeendigung oder Einschränkung aufgrund von Ressourcenbedingungen | **Bei der Auswertung prüfen** - Prozessname und Version, - macOS-Version und Build, - Architektur, - Zeitpunkt, - Ausnahmeart, - beendender Thread, - geladene Bibliotheken, - wiederkehrende Drittanbieterkomponenten, - Auftreten nach Update oder Konfigurationsänderung. Ein Funktionsname im abstürzenden Thread beweist nicht automatisch, dass genau diese Komponente die eigentliche Ursache ist. --- **12. Netzwerkadapter und Netzwerkkonfiguration** **Alle Schnittstellen** ```bash ifconfig ``` Nur aktive Schnittstellen: ```bash ifconfig -u ``` **Hardwareports und BSD-Gerätenamen zuordnen** ```bash networksetup -listallhardwareports ``` Beispiel: ```text Hardware Port: Wi-Fi Device: en0 Ethernet Address: aa:bb:cc:dd:ee:ff ``` Der Gerätename darf nicht pauschal als `en0` angenommen werden. Er muss auf dem jeweiligen Mac geprüft werden. **Alle Netzwerkdienste** ```bash networksetup -listallnetworkservices ``` Ein Stern vor einem Netzwerkdienst bedeutet, dass dieser deaktiviert ist. **Konfiguration eines Dienstes** ```bash networksetup -getinfo "Wi-Fi" ``` **IP-Adresse einer Schnittstelle** ```bash ipconfig getifaddr en0 ``` `en0` muss durch die tatsächlich ermittelte Schnittstelle ersetzt werden. **DHCP-Informationen** ```bash ipconfig getpacket en0 ``` **Standardroute** ```bash route -n get default ``` **Routingtabelle** ```bash netstat -rn ``` **Aktueller DNS-Zustand** ```bash scutil --dns ``` Die Ausgabe zeigt die tatsächlich von macOS verwalteten Resolver und ist für die Diagnose häufig aussagekräftiger als das alleinige Betrachten einer einzelnen DNS-Adresse in den Systemeinstellungen. **Proxykonfiguration** ```bash scutil --proxy ``` **Netzwerkzustand beobachten** ```bash scutil --nwi ``` **Typische Prüfreihenfolge** 1. Wird der Adapter erkannt? 2. Ist die Schnittstelle aktiv? 3. besitzt sie eine erwartete IP-Konfiguration? 4. existiert eine passende Route? 5. ist das lokale Gateway erreichbar? 6. funktioniert die Namensauflösung? 7. ist der Zielport erreichbar? 8. funktioniert das Anwendungsprotokoll? 9. beeinflussen VPN, Proxy, Filter oder Firewall die Verbindung? --- **13. Erreichbarkeit, DNS und Ports prüfen** **IP-Erreichbarkeit** ```bash ping -c 4 192.168.1.1 ``` **Namensauflösung und Erreichbarkeit** ```bash ping -c 4 example.com ``` Ein fehlgeschlagener Ping beweist nicht automatisch, dass ein Host oder Dienst nicht erreichbar ist. ICMP kann gefiltert werden. **Route untersuchen** ```bash traceroute example.com ``` **DNS-Abfrage** ```bash dig example.com ``` Bestimmten DNS-Server abfragen: ```bash dig @192.168.1.1 example.com ``` **macOS-Systemauflösung prüfen** ```bash dscacheutil -q host -a name example.com ``` **Zielport testen** ```bash nc -vz example.com 443 ``` UDP-Prüfungen mit `nc` liefern aufgrund der verbindungslosen Arbeitsweise von UDP nicht dieselbe Bestätigung wie ein erfolgreicher TCP-Verbindungsaufbau. **HTTP- und TLS-Verbindung** ```bash curl -v https://example.com/ ``` Nur Header abrufen: ```bash curl -I https://example.com/ ``` Zeitwerte erfassen: ```bash curl -o /dev/null -sS \ -w 'DNS: %{time_namelookup}\nTCP: %{time_connect}\nTLS: %{time_appconnect}\nGesamt: %{time_total}\n' \ https://example.com/ ``` **Lokale Listener** ```bash lsof -nP -iTCP -sTCP:LISTEN ``` **Verbindungen eines Prozesses** ```bash lsof -nP -a -p 1234 -i ``` > Eine erfolgreiche TCP-Verbindung bestätigt nur, dass der Verbindungsaufbau zu diesem Ziel und Port möglich war. Sie bestätigt noch keine korrekte Anmeldung, Anwendungsfunktion oder Datenverarbeitung. --- **14. Paketmitschnitt unter macOS** macOS enthält `tcpdump`. **Verfügbare Schnittstellen** ```bash sudo tcpdump -D ``` **Verkehr einer Schnittstelle beobachten** ```bash sudo tcpdump -i en0 ``` **Ohne Namensauflösung** ```bash sudo tcpdump -nn -i en0 ``` **Nur Verkehr eines Hosts** ```bash sudo tcpdump -nn -i en0 host 192.168.1.50 ``` **Nur einen Port** ```bash sudo tcpdump -nn -i en0 port 443 ``` **In eine Datei schreiben** ```bash sudo tcpdump -nn -i en0 -w ~/Desktop/mitschnitt.pcap ``` **Begrenzte Anzahl Pakete** ```bash sudo tcpdump -nn -i en0 -c 500 -w ~/Desktop/mitschnitt.pcap ``` **Vor dem Mitschnitt festlegen** - richtige Schnittstelle, - geeigneter Capture-Filter, - notwendige Dauer, - maximale Paketanzahl oder Dateigröße, - Zielpfad, - Datenschutz, - sichere Aufbewahrung, - Löschung nach Abschluss der Analyse. Paketmitschnitte können enthalten: - IP-Adressen, - Hostnamen, - DNS-Abfragen, - Kommunikationsbeziehungen, - unverschlüsselte Inhalte, - Authentifizierungsinformationen, - personenbezogene oder vertrauliche Daten. --- **15. WLAN-Diagnose** **Verbindungsinformationen anzeigen** Bei gedrückter **Option-Taste** auf das WLAN-Symbol in der Menüleiste klicken. Je nach macOS-Version werden unter anderem angezeigt: - IP-Adresse, - Routeradresse, - Kanal, - Frequenzband, - Sicherheitsstandard, - verwendetes 802.11-Protokoll, - weitere Verbindungsdaten. **Diagnose für drahtlose Umgebungen** 1. Mit dem problematischen WLAN verbinden. 2. Option-Taste gedrückt halten. 3. WLAN-Menü öffnen. 4. **Diagnose für drahtlose Umgebungen öffnen** wählen. Apple weist darauf hin, dass die Diagnoseanalyse selbst keine Änderungen an den Netzwerkeinstellungen vornimmt. **Mögliche Diagnosebereiche** - Signalqualität, - Störquellen, - Kanalbelegung, - Verbindungsabbrüche, - Authentifizierung, - Verbindung zum Router, - Internetzugriff. **Wichtige Abgrenzung** | Beobachtung | Einordnung | |---|---| | WLAN ist verbunden | bestätigt nicht automatisch Internetzugriff | | starke Signalstärke | bestätigt nicht automatisch geringe Störung oder hohen Durchsatz | | Internet funktioniert | bestätigt nicht automatisch lokale DNS-, VPN- oder Anwendungsfunktion | | anderes Gerät funktioniert | grenzt ein, schließt aber benutzer- oder gerätespezifische Ursachen nicht aus | | Ethernet funktioniert | spricht für einen WLAN-bezogenen Unterschied, beweist aber noch keine bestimmte WLAN-Ursache | --- **16. Dienste und `launchd`** macOS verwendet `launchd` zur Verwaltung vieler System- und Benutzerdienste. **Benutzerdomäne anzeigen** ```bash launchctl print gui/$(id -u) ``` **Systemdomäne anzeigen** ```bash sudo launchctl print system ``` **Bestimmten Benutzerdienst untersuchen** ```bash launchctl print gui/$(id -u)/com.beispiel.dienst ``` **Bestimmten Systemdienst untersuchen** ```bash sudo launchctl print system/com.beispiel.dienst ``` Der genaue Dienstbezeichner muss vorher ermittelt werden. **Typische Speicherorte** ```text ~/Library/LaunchAgents/ /Library/LaunchAgents/ /Library/LaunchDaemons/ /System/Library/LaunchAgents/ /System/Library/LaunchDaemons/ ``` Bedeutung: | Ort | typischer Zweck | |---|---| | `~/Library/LaunchAgents` | benutzerspezifische Agenten | | `/Library/LaunchAgents` | zusätzliche Agenten für Benutzer | | `/Library/LaunchDaemons` | zusätzliche systemweite Daemons | | `/System/Library/...` | von macOS bereitgestellte und geschützte Dienste | **Eigenschaftslistendatei prüfen** ```bash plutil -lint "/Pfad/zur/Datei.plist" ``` Inhalt lesbar ausgeben: ```bash plutil -p "/Pfad/zur/Datei.plist" ``` **Typische Fehlerursachen** - fehlerhafte PLIST-Syntax, - falscher `Label`-Wert, - nicht vorhandener Programmpfad, - ungeeignete Dateirechte, - falscher Besitzer, - fehlende Arbeitsverzeichnisse, - nicht verfügbare Umgebungsvariablen, - TCC- oder Sandbox-Einschränkungen, - wiederholter Absturz, - widersprüchliche Agenten, - veraltetes Login-Objekt. > Dienste sollten nicht allein aufgrund ihres unbekannten Namens deaktiviert oder gelöscht werden. Zuerst müssen Hersteller, Pfad, Signatur, Zweck und Abhängigkeiten bestimmt werden. --- **17. Login-Objekte und Hintergrundelemente** Grafische Verwaltung: **Systemeinstellungen → Allgemein → Anmeldeobjekte und Erweiterungen** Dort können je nach macOS-Version unter anderem sichtbar sein: - beim Anmelden geöffnete Programme, - im Hintergrund erlaubte Programme, - Erweiterungen, - Netzwerk- oder Sicherheitskomponenten. **Typische Diagnose** 1. Namen und Hersteller dokumentieren. 2. Installationspfad und Signatur prüfen. 3. Zeitpunkt der Installation feststellen. 4. Abhängigkeit von benötigten Anwendungen prüfen. 5. Element testweise kontrolliert deaktivieren. 6. Verhalten nach erneuter Anmeldung oder Neustart vergleichen. 7. Änderung anschließend zurücknehmen oder dokumentiert beibehalten. Der sichere Modus kann helfen festzustellen, ob eine Störung mit beim Start geladenen Softwarebestandteilen zusammenhängt. Er benennt jedoch nicht automatisch die konkrete Ursache. --- **18. Codesignatur und Gatekeeper prüfen** **Signatur anzeigen** ```bash codesign -dv --verbose=4 "/Applications/Beispiel.app" ``` Die Detailausgabe erfolgt bei `codesign` häufig über den Fehlerausgabekanal, obwohl kein Fehler vorliegt. **Signatur verifizieren** ```bash codesign --verify --deep --strict --verbose=2 "/Applications/Beispiel.app" ``` **Gatekeeper-Bewertung** ```bash spctl --assess --type execute --verbose=4 "/Applications/Beispiel.app" ``` **Quarantäneattribut anzeigen** ```bash xattr -l "/Applications/Beispiel.app" ``` **Paketinformationen** ```bash pkgutil --pkg-info "Paketkennung" ``` Installierte Paketkennungen durchsuchen: ```bash pkgutil --pkgs | grep -i "hersteller" ``` **Wichtige Einordnung** - Eine gültige Signatur beweist Integrität gegenüber der signierten Version, aber nicht automatisch Fehlerfreiheit. - Eine Gatekeeper-Ablehnung kann mit Signatur, Beglaubigung, Quarantäne oder Richtlinien zusammenhängen. - Das Quarantäneattribut sollte nicht pauschal rekursiv entfernt werden. - Das Deaktivieren von Gatekeeper oder SIP ist keine reguläre Fehlerbehebungsmethode. - Unternehmensgeräte können zusätzliche MDM- und Sicherheitsrichtlinien besitzen. --- **19. System- und Netzwerkerweiterungen** Moderne macOS-Versionen verwenden für viele Funktionen Systemerweiterungen statt klassischer Kernel Extensions. **Systemerweiterungen anzeigen** ```bash systemextensionsctl list ``` **Geladene Kernelkomponenten untersuchen** ```bash kmutil showloaded ``` Je nach Systemversion, Architektur und Berechtigung kann die Ausgabe eingeschränkt sein. **Typische beteiligte Anwendungen** - VPN-Clients, - Endpoint-Security, - Inhaltsfilter, - Netzwerkschutz, - Treiber, - Audioanwendungen, - Virtualisierungssoftware, - Dateisynchronisation. **Bei Problemen prüfen** - ist die Erweiterung aktiviert? - wurde sie vom Benutzer oder durch MDM genehmigt? - passt die Version zur installierten macOS-Version? - ist nach Installation ein Neustart erforderlich? - existieren alte Komponenten eines früheren Produkts? - wird Netzwerkverkehr durch einen Content Filter beeinflusst? - tritt die Störung nach Deaktivierung kontrolliert nicht mehr auf? Eine Sicherheits- oder Netzwerkerweiterung darf auf Unternehmenssystemen nicht ohne Freigabe deaktiviert werden. --- **20. Energieverwaltung und Ruhezustand** **Aktuelle Energieeinstellungen** ```bash pmset -g ``` **Akkuzustand** ```bash pmset -g batt ``` **Aktive Ruhezustandsverhinderungen** ```bash pmset -g assertions ``` **Geplante Energieereignisse** ```bash pmset -g sched ``` **Power-Management-Protokoll** ```bash pmset -g log ``` Die Ausgabe kann sehr umfangreich sein und sollte zeitlich gefiltert werden. **Hardwareinformationen zur Stromversorgung** ```bash system_profiler SPPowerDataType ``` **Typische Fragestellungen** - Welcher Prozess verhindert den Ruhezustand? - erkennt macOS das Netzteil? - wird der Akku geladen? - bestehen ungewöhnlich viele Ladezyklen? - tritt der Verbrauch nur bei einer bestimmten Anwendung auf? - wacht der Mac wiederholt unerwartet auf? - bestehen angeschlossene Geräte oder Netzwerkaktivitäten, die den Ruhezustand beeinflussen? > Eine hohe Akkunutzung ist nicht automatisch ein Akkudefekt. Zuerst müssen Energieverbrauch, Arbeitslast, Display, Funkverbindungen, Hintergrundprozesse und angeschlossene Geräte geprüft werden. --- **21. Spotlight untersuchen** Spotlight-Indizierung kann zeitweise CPU-, Datenträger- und Energieauslastung verursachen. **Status eines Volumes** ```bash mdutil -s / ``` **Metadaten einer Datei** ```bash mdls "/Pfad/zur/Datei" ``` **Spotlight-Suche im Terminal** ```bash mdfind "Suchbegriff" ``` **Typische Hinweise auf Spotlight-Aktivität** - Prozesse wie `mds`, `mds_stores` oder `mdworker`, - erhöhte Datenträgeraktivität, - Auftreten nach Update, Migration oder Anschluss eines Datenträgers, - unvollständige Suchergebnisse während der Indizierung. Die Indizierung sollte nicht ohne bestätigte Ursache dauerhaft deaktiviert werden. Zuerst ist zu prüfen, ob es sich um eine vorübergehende und erwartete Aktivität handelt. --- **22. Zeit und Synchronisation** Eine falsche Systemzeit kann unter anderem verursachen: - TLS- und Zertifikatsfehler, - Anmeldeprobleme, - Kerberos-Fehler, - unpassende Protokollzeitpunkte, - Probleme mit MDM oder Cloudservices, - fehlerhafte Zeitstempel. **Zeit anzeigen** ```bash date ``` **Konfiguration des Zeitservers** ```bash sudo systemsetup -getnetworktimeserver ``` **Netzwerkzeitstatus** ```bash sudo systemsetup -getusingnetworktime ``` **Zeitzone** ```bash sudo systemsetup -gettimezone ``` Bei der Protokollauswertung müssen lokale Zeit, UTC, Zeitzone und Sommerzeit berücksichtigt werden. --- **23. MDM und Konfigurationsprofile** **Registrierungsstatus** ```bash profiles status -type enrollment ``` **Konfigurationsprofile anzeigen** ```bash sudo profiles show -type configuration ``` Verfügbarkeit, Umfang und erforderliche Rechte können von der macOS-Version und Geräteverwaltung abhängen. **Profile können beeinflussen** - WLAN, - VPN, - Zertifikate, - Proxys, - Datenschutzfreigaben, - Systemerweiterungen, - Sicherheitsrichtlinien, - Softwareupdates, - Passwörter, - FileVault, - Anmeldeobjekte. > Eine Einstellung kann in der grafischen Oberfläche unveränderbar erscheinen, weil sie durch ein Profil oder MDM vorgegeben wird. Das ist nicht automatisch ein Bedienungs- oder Dateirechtefehler. --- **24. Sicherer Modus** Der sichere Modus kann helfen zu bestimmen, ob eine Störung mit Software zusammenhängt, die während des regulären Starts geladen wird. **Mac mit Apple-Chip** 1. Mac vollständig ausschalten. 2. Ein-/Ausschalter gedrückt halten, bis die Startoptionen erscheinen. 3. Startvolume auswählen. 4. Umschalttaste gedrückt halten. 5. **Im gesicherten Modus fortfahren** wählen. **Intel-basierter Mac** 1. Mac einschalten oder neu starten. 2. sofort die Umschalttaste gedrückt halten. 3. Taste beim Anmeldefenster loslassen. 4. anmelden; gegebenenfalls ist eine zweite Anmeldung erforderlich. **Diagnostische Aussage** | Ergebnis | Einordnung | |---|---| | Fehler tritt im sicheren Modus nicht auf | Hinweis auf einen Unterschied bei geladenen Komponenten, Caches oder Startobjekten | | Fehler tritt weiterhin auf | Drittanbieter-Startkomponenten werden weniger wahrscheinlich, aber nicht vollständig ausgeschlossen | | System startet nur im sicheren Modus | Startobjekte, Erweiterungen, Dateisystem oder Softwarekonflikte gezielt prüfen | > Der sichere Modus ist ein Eingrenzungstest. Er identifiziert nicht automatisch die fehlerhafte Komponente. --- **25. Apple Diagnose** Apple Diagnose prüft bestimmte interne Hardwarekomponenten des Mac. Apple weist ausdrücklich darauf hin, dass damit nicht geprüft werden: - externe Hardwarekomponenten, - macOS-Probleme, - Konflikte mit Anwendungen, - Konflikte mit Erweiterungen. **Vorbereitung** 1. Mac ausschalten. 2. nicht benötigte externe Geräte trennen. 3. Tastatur, Maus, Display, Ethernet und Stromversorgung dürfen angeschlossen bleiben. 4. Mac auf eine feste und gut belüftete Fläche stellen. 5. Internetverbindung bereithalten, falls erforderlich. **Mac mit Apple-Chip** 1. Ein-/Ausschalter gedrückt halten, bis die Startoptionen erscheinen. 2. Ein-/Ausschalter loslassen. 3. `Command-D` gedrückt halten, um Apple Diagnose zu starten. **Intel-basierter Mac** 1. Mac einschalten. 2. sofort die Taste `D` gedrückt halten. 3. Taste loslassen, wenn ein Fortschrittsbalken oder die Sprachauswahl erscheint. **Ergebnis dokumentieren** - Referenzcode, - genaue Fehlermeldung, - Datum und Uhrzeit, - angeschlossene Geräte, - macOS-Version, - reproduzierbares Symptom. > Ein Ergebnis „keine Probleme gefunden“ schließt nicht alle Hardwarefehler aus. Sporadische, temperaturabhängige oder externe Fehler können unentdeckt bleiben. --- **26. macOS-Wiederherstellung** Die macOS-Wiederherstellung stellt eine vom normalen System getrennte Umgebung bereit. **Typische Funktionen** - Festplattendienstprogramm, - macOS neu installieren, - Startvolume auswählen, - Wiederherstellungsprotokoll anzeigen, - Terminal öffnen, - Safari beziehungsweise Onlinehilfe, - Diagnosedatei erstellen, - Backup wiederherstellen. **Mac mit Apple-Chip starten** 1. Mac vollständig ausschalten. 2. Ein-/Ausschalter gedrückt halten, bis die Startoptionen erscheinen. 3. **Optionen** wählen. 4. **Fortfahren** wählen. **Intel-basierter Mac starten** Beim Einschalten sofort eine passende Tastenkombination gedrückt halten: | Kombination | Zweck | |---|---| | `Command-R` | integrierte macOS-Wiederherstellung | | `Option-Command-R` | Internet-Wiederherstellung mit einer kompatiblen aktuellen macOS-Version | | `Shift-Option-Command-R` | je nach Mac ursprüngliche oder nächstverfügbare Version über Internet-Wiederherstellung | Die tatsächlich angebotene Version kann vom Mac-Modell und der Verfügbarkeit abhängen. **Wiederherstellungsprotokoll** In der Wiederherstellung: **Fenster → Wiederherstellungsprotokoll** Das Protokoll kann gefiltert und in einer Datei gesichert werden. **Diagnostischer Nutzen** - Startvolume außerhalb des laufenden Systems prüfen, - unterscheiden, ob ein Fehler nur im installierten System auftritt, - Dateisystem untersuchen, - Wiederherstellungsprotokolle sichern, - Startprobleme analysieren. > Eine Neuinstallation sollte nicht der erste Diagnoseschritt sein. Sie kann den fehlerhaften Zustand verändern und beseitigt keine externen Hardware-, Netzwerk-, Benutzerprofil- oder Konfigurationsursachen. --- **27. USB-, Thunderbolt- und externe Geräte** **USB-Geräte** ```bash system_profiler SPUSBDataType ``` **Thunderbolt- beziehungsweise USB4-Geräte** ```bash system_profiler SPThunderboltDataType ``` **Speichergeräte** ```bash diskutil list ``` **Offene Verbindungen während des Einsteckens beobachten** ```bash log stream --style compact ``` Anschließend kann nach passenden Prozessen, Subsystemen oder Meldungstexten gefiltert werden. **Kreuztests** - anderer Anschluss, - anderes Kabel, - ohne Hub oder Dock, - anderes Netzteil, - anderes Benutzerkonto, - anderer Mac, - Gerät direkt statt über Adapter, - bekannte funktionierende Gegenprobe. **Eingrenzung** | Beobachtung | mögliche Ebene | |---|---| | Gerät fehlt in Systeminformationen | Kabel, Anschluss, Stromversorgung, Hardware | | Gerät erscheint, aber nicht in der Anwendung | Anwendung, Berechtigung, Treiber, Modus | | Datenträger erscheint in `diskutil`, aber nicht im Finder | Volume, Aktivierung, Finder-Einstellung, Dateisystem | | Gerät funktioniert direkt, aber nicht am Hub | Hub, Stromversorgung, Kabel, Kompatibilität | | Gerät funktioniert nur an einem Benutzerkonto | benutzerspezifische Einstellung oder Berechtigung | --- **28. Bluetooth untersuchen** **Systembericht** ```bash system_profiler SPBluetoothDataType ``` **Zu prüfen** - wird der Bluetooth-Controller erkannt? - wird das Gerät erkannt? - ist das Gerät verbunden oder nur gekoppelt? - besteht eine Verbindung zu einem anderen Host? - ist der Akku des Geräts ausreichend geladen? - tritt die Störung bei mehreren Geräten auf? - beeinflussen USB-3-Geräte oder Funkstörungen die Verbindung? - existieren herstellerspezifische Anwendungen oder Erweiterungen? Das Löschen sämtlicher Kopplungen oder Einstellungsdateien ist keine geeignete Erstmaßnahme. Zuerst sollten Zustand und Umfang dokumentiert werden. --- **29. Druckerdiagnose** **Konfigurierte Drucker** ```bash lpstat -p -d ``` **Druckerstatus** ```bash lpstat -t ``` **Druckaufträge** ```bash lpstat -o ``` **CUPS-Weboberfläche** Auf aktuellen Systemen kann die Weboberfläche deaktiviert sein. Ihr Status und die organisatorischen Sicherheitsvorgaben müssen vor einer Aktivierung geprüft werden. **Typische Prüfreihenfolge** 1. Wird der Drucker lokal beziehungsweise im Netzwerk erreicht? 2. ist die richtige Warteschlange ausgewählt? 3. hängt ein Auftrag in der Warteschlange? 4. stimmt Treiber beziehungsweise verwendetes Druckprotokoll? 5. funktioniert Namensauflösung? 6. ist der Drucker über IPP, AirPrint oder einen Printserver eingebunden? 7. bestehen Authentifizierungs- oder Berechtigungsfehler? 8. tritt der Fehler bei anderen Benutzern auf? --- **30. Systemdiagnose sammeln** macOS kann ein umfangreiches Diagnosetaket erzeugen: ```bash sudo sysdiagnose ``` Der Vorgang kann mehrere Minuten dauern. Speicherort und Abschlussmeldung müssen der Terminalausgabe entnommen werden. Ein `sysdiagnose` kann unter anderem enthalten: - Systemzustand, - Prozessinformationen, - Protokolle, - Netzwerkzustand, - Speicherinformationen, - Energieinformationen, - Konfigurationsdaten, - Absturz- und Diagnoseberichte. **Vor dem Einsatz beachten** - hoher Umfang, - möglicher zusätzlicher Ressourcenverbrauch, - sensible oder personenbezogene Informationen, - sichere Speicherung, - verschlüsselte Übertragung, - begrenzter Empfängerkreis, - definierte Aufbewahrungsdauer, - kontrollierte Löschung nach Abschluss. `sysdiagnose` ist kein Ersatz für eine gezielte Hypothese. Es ist besonders sinnvoll, wenn: - der Fehler schwer reproduzierbar ist, - mehrere Komponenten beteiligt sein könnten, - Apple oder ein Hersteller umfangreiche Diagnosedaten anfordert, - der aktuelle Systemzustand vor einer Veränderung gesichert werden muss. --- **31. Werkzeugwahl nach Symptom** | Symptom | erste geeignete Werkzeuge | |---|---| | Mac ist allgemein langsam | Aktivitätsanzeige, `top`, `vm_stat`, `memory_pressure`, `iostat`, Speicherplatzprüfung | | Anwendung reagiert nicht | Aktivitätsanzeige, `sample`, Konsole, Diagnoseberichte | | Anwendung stürzt ab | Konsole, DiagnosticReports, `codesign`, Versions- und Erweiterungsprüfung | | kein Internetzugriff | `networksetup`, `ifconfig`, `route`, `scutil --dns`, `ping`, `dig`, `nc`, `curl` | | WLAN instabil | Option-WLAN-Menü, Diagnose für drahtlose Umgebungen, Kreuztest mit Ethernet | | Port nicht erreichbar | `nc`, `lsof`, `curl`, `tcpdump` | | Datenträger fehlt | Systeminformationen, `diskutil list`, Festplattendienstprogramm | | Volume fast voll | `df`, `du`, Festplattendienstprogramm | | Datei kann nicht geöffnet werden | `ls -leO@`, `xattr`, `stat`, TCC-, Signatur- und Eigentümerprüfung | | Hintergrunddienst startet nicht | `launchctl print`, `plutil`, Unified Log | | hoher Energieverbrauch | Aktivitätsanzeige, `pmset`, `system_profiler SPPowerDataType` | | USB-Gerät funktioniert nicht | Systeminformationen, USB-/Thunderbolt-Bericht, Kabel- und Direktanschlusstest | | Startproblem | sicherer Modus, Apple Diagnose, macOS-Wiederherstellung, Festplattendienstprogramm | | Problem nur bei einem Benutzer | neues Testkonto, benutzerspezifische Agenten, Einstellungen und TCC | | Problem nach Softwareinstallation | Login-Objekte, Systemerweiterungen, `pkgutil`, `codesign`, Protokolle | --- **32. Praxisbeispiel: Eine Anwendung startet nicht** **Symptom** Eine Anwendung beendet sich unmittelbar nach dem Start. **Sichere Untersuchung** 1. genaue Anwendungsversion erfassen, 2. macOS-Version und Build erfassen, 3. Zeitpunkt des Startversuchs notieren, 4. prüfen, ob andere Benutzer betroffen sind, 5. Anwendung aus dem Terminal oder Finder starten, 6. Live-Protokollierung auf den Prozess filtern, 7. Absturzbericht sichern, 8. Signatur und Gatekeeper-Bewertung prüfen, 9. geladene Erweiterungen und Plug-ins berücksichtigen, 10. erst danach Konfigurationen verändern. **Beispielbefehle** ```bash sw_vers ``` ```bash codesign --verify --deep --strict --verbose=2 "/Applications/Beispiel.app" ``` ```bash spctl --assess --type execute --verbose=4 "/Applications/Beispiel.app" ``` ```bash log stream --style compact --predicate 'process == "Beispiel"' ``` ```bash ls -lt ~/Library/Logs/DiagnosticReports/ ``` **Mögliche Hypothesen** - beschädigte oder unvollständige Anwendung, - inkompatible Version, - ungültige Signatur, - fehlende Berechtigung, - inkompatibles Plug-in, - beschädigte benutzerspezifische Konfiguration, - nicht erreichbarer abhängiger Dienst, - Architektur- oder Rosetta-Konflikt. Das sofortige Löschen aller Einstellungsdateien würde den Beweiszustand verändern und kann benutzerspezifische Daten vernichten. --- **33. Praxisbeispiel: Netzwerk funktioniert im Browser nicht** **Symptom** Webseiten werden nicht geladen. **Schrittweise Eingrenzung** ```bash networksetup -listallhardwareports ``` ```bash ifconfig ``` ```bash route -n get default ``` ```bash ping -c 4 192.168.1.1 ``` ```bash scutil --dns ``` ```bash dig example.com ``` ```bash nc -vz example.com 443 ``` ```bash curl -v https://example.com/ ``` ```bash scutil --proxy ``` **Bewertung** | Ergebnis | nächste Eingrenzung | |---|---| | keine IP-Adresse | Link, WLAN, DHCP | | IP vorhanden, keine Standardroute | Netzwerkkonfiguration, DHCP, VPN | | Gateway nicht erreichbar | lokales Netz, VLAN, WLAN, Router | | IP-Ziel erreichbar, DNS fehlschlägt | Resolver, DNS-Server, VPN, Filter | | DNS funktioniert, Port 443 fehlschlägt | Firewall, Route, Proxy, Zielservice | | `curl` funktioniert, Browser nicht | Browserprofil, Erweiterung, Proxy, Zertifikat, TCC | | Problem nur mit VPN | VPN-Route, DNS, Netzwerkerweiterung, Richtlinie | --- **34. Praxisbeispiel: Mac ist plötzlich sehr langsam** **Zuerst sichern** ```bash date ``` ```bash uptime ``` ```bash top -l 1 -o cpu ``` ```bash memory_pressure ``` ```bash sysctl vm.swapusage ``` ```bash df -h / ``` ```bash iostat -w 1 ``` **Danach prüfen** - begann die Störung nach Anmeldung, Update oder Anschluss eines Geräts? - ist ein einzelner Prozess auffällig? - ist der Speicherdruck erhöht? - besteht starke Swap- oder Datenträgeraktivität? - ist das Startvolume fast voll? - läuft Spotlight-Indizierung? - findet eine Cloud- oder Backup-Synchronisation statt? - existieren wiederholte Abstürze oder Neustarts von Diensten? - tritt die Störung in einem anderen Benutzerkonto auf? - tritt sie im sicheren Modus auf? > Das Beenden des Prozesses mit der höchsten CPU-Auslastung ist keine vollständige Ursachenanalyse. Der Prozess kann eine notwendige Folgearbeit ausführen oder nur auf eine andere Störung reagieren. --- **35. Typische Fehlinterpretationen** | Aussage | fachliche Einordnung | |---|---| | „Der Arbeitsspeicher ist fast vollständig belegt.“ | macOS nutzt Speicher bewusst für Anwendungen und Caches. Speicherdruck und Swap sind aussagekräftiger. | | „`sudo` müsste auf alles zugreifen können.“ | TCC und SIP können den Zugriff trotz Root-Rechten begrenzen. | | „Der Prozess hat die höchste CPU-Auslastung und ist daher defekt.“ | Hohe Auslastung kann zur erwarteten Arbeit gehören. | | „Apple Diagnose meldet keinen Fehler, also ist die Hardware sicher fehlerfrei.“ | Nicht alle Hardwarefehler und keine externen Komponenten werden vollständig geprüft. | | „WLAN ist verbunden, deshalb muss Internet funktionieren.“ | WLAN-Verbindung, IP-Konfiguration, Routing, DNS und Internetdienst sind unterschiedliche Ebenen. | | „Erste Hilfe repariert auch eine defekte SSD.“ | Das Werkzeug prüft beziehungsweise repariert Dateisystemstrukturen, nicht verschlissene Hardware. | | „Im Protokoll steht `error`; das ist die Ursache.“ | Die Meldung kann erwartet, unabhängig oder eine Folge des eigentlichen Fehlers sein. | | „Eine gültige Codesignatur beweist, dass die Anwendung funktioniert.“ | Sie bestätigt nicht die fehlerfreie Funktion oder Kompatibilität. | | „Der sichere Modus behebt die Ursache.“ | Er dient vor allem als Vergleichs- und Eingrenzungstest. | | „Das Gerät erscheint im Systembericht und funktioniert deshalb vollständig.“ | Erkennung, Treiber, Berechtigung und Anwendungsfunktion müssen getrennt geprüft werden. | | „Ein Neustart hat geholfen, also ist die Ursache beseitigt.“ | Der Neustart kann nur flüchtigen Zustand zurückgesetzt haben. | | „`ping` schlägt fehl, daher ist der Server offline.“ | ICMP kann blockiert sein, obwohl der eigentliche Dienst erreichbar ist. | | „Das Löschen aller Einstellungen ist die schnellste Lösung.“ | Dadurch können Beweise und Benutzerdaten verloren gehen, ohne die Ursache zu bestätigen. | --- **36. Checkliste macOS-Fehleranalyse** - [ ] Störung und erwartetes Verhalten sind exakt beschrieben. - [ ] Zeitpunkt und letzte Änderungen sind bekannt. - [ ] macOS-Version und Build wurden erfasst. - [ ] Mac-Modell und Prozessorarchitektur wurden erfasst. - [ ] betroffene Benutzer und Anwendungen sind bekannt. - [ ] Umfang und Auswirkung wurden bestimmt. - [ ] wichtige flüchtige Informationen wurden gesichert. - [ ] Prozess- und Ressourcenzustand wurden geprüft. - [ ] Speicherplatz und Datenträgerzustand wurden geprüft. - [ ] relevante Netzwerkebenen wurden getrennt getestet. - [ ] Unified Logs wurden zeitlich passend ausgewertet. - [ ] Absturz- oder Diagnoseberichte wurden gesichert. - [ ] TCC, SIP, Gatekeeper und MDM wurden berücksichtigt. - [ ] Dienste und Startobjekte wurden nicht unkontrolliert entfernt. - [ ] Befehle mit `sudo` wurden vor der Ausführung verstanden. - [ ] Paketmitschnitte und Diagnosedateien werden geschützt. - [ ] Apple-Chip und Intel-Verfahren wurden unterschieden. - [ ] sicherer Modus wurde nur als Eingrenzungstest bewertet. - [ ] Apple Diagnose wurde nicht als vollständiger Softwaretest interpretiert. - [ ] Änderungen wurden einzeln und reversibel durchgeführt. - [ ] Funktion wurde nach der Maßnahme überprüft. - [ ] Ursache und nicht nur das Symptom wurde bestätigt. - [ ] Ergebnisse und Rückfallmöglichkeiten wurden dokumentiert. --- **37. Schnellreferenz** | Aufgabe | Werkzeug oder Befehl | |---|---| | macOS-Version | `sw_vers` | | Architektur | `uname -m` | | Hardwareübersicht | `system_profiler SPHardwareDataType` | | Prozessliste | `ps aux` | | Prozess suchen | `pgrep -afil "Name"` | | CPU-Auslastung | `top -l 1 -o cpu` | | Speicherdruck | `memory_pressure` | | Speicherseiten | `vm_stat` | | Swap | `sysctl vm.swapusage` | | Datenträgerstruktur | `diskutil list` | | APFS-Struktur | `diskutil apfs list` | | Dateisystembelegung | `df -h` | | Verzeichnisgröße | `du -sh Pfad` | | offene Dateien | `lsof` | | Listener | `lsof -nP -iTCP -sTCP:LISTEN` | | Netzwerkadapter | `networksetup -listallhardwareports` | | Schnittstellen | `ifconfig` | | Standardroute | `route -n get default` | | Routingtabelle | `netstat -rn` | | DNS-Zustand | `scutil --dns` | | Proxy-Zustand | `scutil --proxy` | | DNS-Abfrage | `dig example.com` | | Porttest | `nc -vz host port` | | HTTP-/TLS-Test | `curl -v URL` | | Paketmitschnitt | `sudo tcpdump -nn -i Schnittstelle` | | Protokollhistorie | `log show` | | Live-Protokoll | `log stream` | | Dienst untersuchen | `launchctl print` | | PLIST prüfen | `plutil -lint Datei.plist` | | Dateirechte und Attribute | `ls -leO@ Pfad` | | Signatur prüfen | `codesign --verify` | | Gatekeeper prüfen | `spctl --assess` | | Systemerweiterungen | `systemextensionsctl list` | | Energiezustand | `pmset -g` | | Ruhezustandsblocker | `pmset -g assertions` | | MDM-Status | `profiles status -type enrollment` | | umfangreiche Diagnose | `sudo sysdiagnose` | --- **Merksatz** > macOS-Fehleranalyse bedeutet nicht, wahllos Einstellungen zurückzusetzen oder Schutzmechanismen zu umgehen. Zuerst werden Systemzustand, Prozesse, Ressourcen, Protokolle, Netzwerk, Datenträger und Berechtigungen getrennt untersucht. Danach wird eine konkrete Hypothese mit einer kleinen, kontrollierten und möglichst reversiblen Maßnahme geprüft. --- **Quellen und weiterführende Dokumentation** - [Apple – Aktivitätsanzeige: Benutzerhandbuch](https://support.apple.com/de-de/guide/activity-monitor/welcome/mac) - [Apple – Mac-Prozesse in der Aktivitätsanzeige anzeigen](https://support.apple.com/de-de/guide/activity-monitor/actmntr1001/mac) - [Apple – Speichernutzung in der Aktivitätsanzeige](https://support.apple.com/de-de/guide/activity-monitor/actmntr1004/mac) - [Apple – CPU-Aktivität in der Aktivitätsanzeige](https://support.apple.com/de-de/guide/activity-monitor/actmntr43452/mac) - [Apple – Festplattenaktivität in der Aktivitätsanzeige](https://support.apple.com/de-de/guide/activity-monitor/actmntr1005/mac) - [Apple – Netzwerkaktivität in der Aktivitätsanzeige](https://support.apple.com/de-de/guide/activity-monitor/actmntr1006/mac) - [Apple – Diagnose für drahtlose Umgebungen](https://support.apple.com/de-de/guide/mac-help/mchlf4de377f/mac) - [Apple – Details zur WLAN-Verbindung anzeigen](https://support.apple.com/de-de/guide/mac-help/mchlfad426fa/mac) - [Apple – Festplattendienstprogramm: Benutzerhandbuch](https://support.apple.com/de-de/guide/disk-utility/welcome/mac) - [Apple – Speichermedium mit „Erste Hilfe“ reparieren](https://support.apple.com/de-de/guide/disk-utility/dskutl1040/mac) - [Apple – Alle Geräte im Festplattendienstprogramm einblenden](https://support.apple.com/de-de/guide/disk-utility/dskud6b39edb/mac) - [Apple – Detailinformationen zu Datenträgern anzeigen](https://support.apple.com/de-de/guide/disk-utility/dskutl1005/mac) - [Apple – Mac im sicheren Modus starten](https://support.apple.com/de-de/guide/mac-help/mh21245/mac) - [Apple – Probleme mit Apple Diagnose untersuchen](https://support.apple.com/de-de/guide/mac-help/mh35727/mac) - [Apple – macOS-Wiederherstellung auf einem Mac mit Apple-Chip](https://support.apple.com/de-de/guide/mac-help/mchl82829c17/mac) - [Apple – macOS-Wiederherstellung auf einem Intel-basierten Mac](https://support.apple.com/de-de/guide/mac-help/mchl338cf9a8/mac) - [Apple – Tastenkombinationen beim Startvorgang](https://support.apple.com/de-de/102603) - [Apple Platform Security – Startmodi eines Mac mit Apple-Chip](https://support.apple.com/de-de/guide/security/sec10869885b/web) # 5.6 Netzwerkgeräte – Werkzeuge zur Fehleranalyse Netzwerkgeräte wie Switches, Router, Firewalls, WLAN-Access-Points, Controller, Load Balancer und VPN-Gateways verfügen meist über eigene Diagnosefunktionen. Dazu gehören: - Kommandozeilenbefehle, - Weboberflächen, - Ereignisprotokolle, - Schnittstellenstatistiken, - Routing- und Switchingtabellen, - Paketmitschnitte, - SNMP-Messwerte, - Telemetriedaten, - zentrale Netzwerkmanagementsysteme, - herstellerspezifische Supportdateien. > Die genaue Syntax hängt von Hersteller, Produktfamilie, Betriebssystem und Softwareversion ab. Ein Befehl darf deshalb nicht ungeprüft auf ein anderes Gerät übertragen werden. --- **1. Grundregeln für die Untersuchung** Vor jedem Zugriff müssen geklärt werden: - betroffenes Gerät, - Hersteller und Modell, - Betriebssystem und Version, - Rolle des Geräts, - Managementadresse, - vorgesehener Zugriffsweg, - benötigte Berechtigungen, - Wartungs- und Änderungsvorgaben, - vorhandene Redundanz, - Auswirkungen eines möglichen Ausfalls. **Zuerst nur lesend untersuchen** Geeignet sind zunächst: - Statusbefehle, - Protokollabfragen, - Zählerstände, - Routingtabellen, - Nachbartabellen, - Konfigurationsansichten, - Paketmitschnitte mit begrenztem Umfang. Zu vermeiden sind ohne bestätigte Ursache und Freigabe: - Neustarts, - Zurücksetzen von Schnittstellen, - Löschen von Tabellen, - Leeren von Sitzungen, - Änderungen an VLANs oder Routen, - Deaktivieren von Sicherheitsregeln, - Zurücksetzen von Zählern, - Firmwareupdates, - Werkseinstellungen, - dauerhafte Debug-Ausgaben. > Eine reine Statusabfrage ist nicht auf jedem Gerät vollständig risikofrei. Umfangreiche Support- oder Diagnosebefehle können CPU, Arbeitsspeicher, Konsole oder Managementverbindung belasten. --- **2. Systematisch von unten nach oben prüfen** | Ebene | typische Fragestellung | |---|---| | Stromversorgung | Ist das Gerät eingeschaltet und ausreichend versorgt? | | Hardware | Sind Module, Netzteile, Lüfter und Temperatursensoren fehlerfrei? | | physische Verbindung | Besteht Link? Stimmen Medium, Kabel, Transceiver und Geschwindigkeit? | | Sicherungsschicht | Stimmen VLAN, Trunk, STP, LACP und MAC-Lernen? | | Netzwerkschicht | Stimmen IP-Adresse, Präfix, ARP/ND und Routing? | | Transport | Ist der benötigte TCP- oder UDP-Port erreichbar? | | Sicherheit | Blockieren ACL, Firewall, NAC oder VPN-Richtlinien? | | Anwendung | Funktionieren DNS, DHCP, RADIUS, NTP oder andere Dienste? | | Management | Erreichen Monitoring, Syslog, SNMP und zentrale Verwaltung das Gerät? | Ein Fehler sollte möglichst auf die kleinste betroffene Ebene eingegrenzt werden. --- **3. Zustand vor Veränderungen sichern** Vor einer Änderung sollten mindestens dokumentiert werden: - Datum und Uhrzeit, - Gerätename, - Seriennummer, - Modell, - Softwareversion, - Laufzeit seit dem letzten Neustart, - aktuelle Konfiguration, - gespeicherte Konfiguration, - Schnittstellenstatus, - Routingtabelle, - Nachbartabellen, - Protokolle, - CPU- und Speicherauslastung, - Redundanzstatus, - betroffene Benutzer oder Standorte, - zuletzt vorgenommene Änderungen. **Typische Beweissicherung** ```text Gerät: Standort: Hersteller und Modell: Betriebssystem und Version: Managementadresse: Zeitpunkt: Symptom: betroffene Schnittstelle: betroffenes VLAN beziehungsweise VRF: Quelladresse: Zieladresse: Zielport und Protokoll: letzte Änderung: gesicherte Ausgaben: durchgeführte Tests: Ergebnis: ``` --- **4. Managementzugriff prüfen** Typische Zugriffswege sind: - lokale Konsole, - serielle Konsole, - dedizierter Managementport, - SSH, - HTTPS, - Out-of-Band-Management, - zentrale Managementplattform, - API, - NETCONF oder RESTCONF. **Sicherheitsregeln** - Telnet nur verwenden, wenn es in einer isolierten Altumgebung ausdrücklich vorgeschrieben ist. - SSH und HTTPS bevorzugen. - Administrationszugriffe protokollieren. - Nur persönliche oder nachvollziehbar zugeordnete Konten verwenden. - Keine Kennwörter in Tickets, Protokollen oder Bildschirmfotos veröffentlichen. - Managementzugriff möglichst über ein getrenntes Managementnetz führen. - Änderungen nach dem Vier-Augen- oder Freigabeverfahren des Unternehmens durchführen. **Bei fehlendem Zugriff unterscheiden** | Beobachtung | mögliche Ursache | |---|---| | Gerät antwortet nicht auf Ping | ICMP gefiltert, falsche Route, Gerät ausgefallen oder Managementadresse falsch | | Ping funktioniert, SSH nicht | Dienst deaktiviert, ACL, falscher Port, Überlastung oder Authentifizierungsproblem | | SSH-Verbindung startet, Anmeldung schlägt fehl | lokales Konto, RADIUS, TACACS+, Zertifikat oder Berechtigung | | Zugriff nur über Konsole möglich | Managementnetz, Routing, VRF, ACL oder Managementdienst | | zentrale Verwaltung zeigt Gerät offline | Managementpfad, Zertifikat, Zeit, DNS, Tunnel oder Controllerverbindung | | Zugriff funktioniert nur von einem Netz | Routing, Firewall, Management-ACL oder VRF | --- **5. Geräteidentität und Softwarestand** Zu erfassen sind: - Gerätename, - Modell, - Seriennummer, - Hardwaremodule, - Betriebssystem, - Softwareversion, - Bootimage, - Lizenzstatus, - Laufzeit, - Grund des letzten Neustarts, - unterstützte und eingesetzte Transceiver. **Cisco IOS beziehungsweise IOS XE** ```text show version ``` ```text show inventory ``` ```text show license summary ``` **Juniper Junos** ```text show version ``` ```text show chassis hardware ``` ```text show system uptime ``` **Aruba AOS-CX** ```text show version ``` ```text show system ``` ```text show inventory ``` Die verfügbaren Befehle können je nach Plattform und Version abweichen. --- **6. CPU, Arbeitsspeicher und Systemzustand** Hohe Auslastung kann dazu führen, dass: - Routingprotokolle Nachbarschaften verlieren, - Managementzugriffe verzögert werden, - Pakete verworfen werden, - Protokolle unvollständig erscheinen, - Kontrollprozesse neu starten, - Überwachungsabfragen fehlschlagen. **Cisco IOS beziehungsweise IOS XE** ```text show processes cpu ``` ```text show processes memory ``` ```text show platform resources ``` **Juniper Junos** ```text show chassis routing-engine ``` ```text show system processes extensive ``` ```text show system memory ``` **Aruba AOS-CX** ```text show system resource-utilization ``` ```text top cpu ``` ```text top memory ``` **Bei Auffälligkeiten prüfen** - Ist die Auslastung dauerhaft oder nur kurzfristig erhöht? - Welcher Prozess ist betroffen? - Begann die Auslastung nach einer Änderung? - Bestehen ungewöhnlich viele Verbindungen oder Routingupdates? - Läuft eine umfangreiche Protokollierung oder Diagnose? - Findet ein Angriff oder Netzwerkscan statt? - Besteht ein Layer-2-Loop? - Sind Tabellen oder Sitzungsspeicher ausgelastet? - Werden Pakete in Software statt in Hardware verarbeitet? > Ein Prozess mit hoher CPU-Auslastung ist nicht automatisch die Ursache. Er kann auf einen Broadcast-Sturm, eine Routinginstabilität oder eine andere Störung reagieren. --- **7. Hardware, Temperatur und Stromversorgung** Zu prüfen sind: - Netzteile, - Lüfter, - Temperatur, - Spannungswerte, - Module, - Linecards, - Stack-Mitglieder, - Chassiszustand, - PoE-Budget, - Hardwarefehler, - Redundanz. **Cisco IOS beziehungsweise IOS XE** ```text show environment ``` ```text show platform ``` ```text show power ``` ```text show power inline ``` Nicht jeder Befehl ist auf jeder Cisco-Plattform vorhanden. **Juniper Junos** ```text show chassis environment ``` ```text show chassis alarms ``` ```text show system alarms ``` ```text show poe controller ``` **Aruba AOS-CX** ```text show environment ``` ```text show system power-supply ``` ```text show system fans ``` ```text show poe brief ``` **Typische Warnsignale** - fehlendes Netzteil, - ausgefallener Lüfter, - erhöhte Temperatur, - überlastetes PoE-Budget, - nicht erkanntes Modul, - Hardwarealarm, - wiederholter Modulneustart, - unterschiedliche Firmwarestände innerhalb eines Stacks. --- **8. Schnittstellenstatus untersuchen** Für jede betroffene Schnittstelle sind mindestens zu prüfen: - administrativer Zustand, - operativer Zustand, - Geschwindigkeit, - Duplexmodus, - MTU, - Medium, - VLAN-Zuordnung, - Beschreibung, - Ein- und Ausgangsrate, - Fehlerzähler, - Drops, - Linkwechsel, - Transceiverwerte. **Cisco IOS beziehungsweise IOS XE** Übersicht: ```text show interfaces status ``` IP-bezogene Übersicht: ```text show ip interface brief ``` Details einer Schnittstelle: ```text show interfaces GigabitEthernet1/0/1 ``` Beschreibungen: ```text show interfaces description ``` Fehlerübersicht auf unterstützten Switches: ```text show interfaces counters errors ``` **Juniper Junos** Übersicht: ```text show interfaces terse ``` Details: ```text show interfaces ge-0/0/1 extensive ``` Beschreibung und Status: ```text show interfaces descriptions ``` **Aruba AOS-CX** ```text show interface brief ``` ```text show interface 1/1/1 ``` ```text show interface 1/1/1 statistics ``` **Status fachlich einordnen** | Zustand | mögliche Bedeutung | |---|---| | administrativ deaktiviert | Schnittstelle wurde durch Konfiguration abgeschaltet | | physisch down | kein Link, Kabel-, Transceiver-, Gegenstellen- oder Stromproblem | | physisch up, Protokoll down | Problem oberhalb der reinen Signalerkennung | | häufige Linkwechsel | Kabel, Stecker, Transceiver, Stromversorgung oder Autonegotiation | | viele Eingangsfehler | Medium, Signal, Überlastung oder fehlerhafte Hardware | | viele Ausgangsdrops | Ausgangswarteschlange überlastet oder Zielverbindung langsamer | | Zähler steigen nicht | möglicherweise falsche Schnittstelle oder kein Verkehr | | Link up | bestätigt nur die Verbindung auf der entsprechenden Ebene | --- **9. Fehlerzähler bewerten** Typische Zähler sind: - CRC-Fehler, - Framefehler, - Alignment Errors, - Runts, - Giants, - Input Errors, - Output Errors, - Discards, - Queue Drops, - Collisions, - Late Collisions, - Overruns, - Carrier Transitions, - Pause Frames. **Mögliche Einordnung** | Zähler | mögliche Ursache | |---|---| | CRC-Fehler | Kabel, Steckverbindung, Transceiver, elektromagnetische Störung oder Gegenstelle | | Late Collisions | Duplexproblem oder ungeeignete gemeinsame Medienumgebung | | Input Drops | Eingangspuffer oder Verarbeitung überlastet | | Output Drops | Ausgangsschnittstelle oder Warteschlange überlastet | | Giants | zu große Frames, MTU-Abweichung oder fehlerhafte Frames | | Runts | beschädigte oder zu kurze Ethernetframes | | viele Linkwechsel | instabile physische Verbindung oder Energieversorgung | **Für eine korrekte Bewertung** 1. aktuellen Zählerstand dokumentieren, 2. Laufzeit des Geräts berücksichtigen, 3. Datenverkehr beobachten, 4. Veränderung des Zählers messen, 5. Gegenstelle prüfen, 6. Kabel beziehungsweise Transceiver kontrolliert gegenprüfen, 7. Fehler nicht allein anhand eines historischen Gesamtwerts bewerten. > Ein hoher Zählerstand kann über Monate entstanden sein. Entscheidend ist häufig, ob der Wert während des aktuellen Fehlers weiter steigt. --- **10. Geschwindigkeit, Duplex und Autonegotiation** Typische Probleme entstehen durch: - eine Seite automatisch und die andere fest konfiguriert, - unterschiedliche feste Geschwindigkeiten, - ungeeignete Transceiver, - nicht unterstützte Kabel, - Energiesparfunktionen, - fehlerhafte Autonegotiation, - unterschiedliche FEC-Einstellungen bei schnellen Verbindungen. Zu vergleichen sind immer beide Seiten der Verbindung. **Prüffragen** - Welche Geschwindigkeit wurde tatsächlich ausgehandelt? - Welcher Duplexmodus ist aktiv? - Ist Autonegotiation auf beiden Seiten gleich behandelt? - Werden Fehlerzähler größer? - Passt der Transceiver zum Port und zur Gegenstelle? - Stimmen Wellenlänge, Fasertyp und Reichweite? - Ist bei höheren Geschwindigkeiten die benötigte Forward Error Correction aktiv? --- **11. Transceiver und Glasfaserdiagnose** Diagnoseinformationen können enthalten: - Hersteller, - Teilenummer, - Seriennummer, - Wellenlänge, - Temperatur, - Spannung, - Sendeleistung, - Empfangsleistung, - Alarmgrenzen. **Cisco – abhängig von Plattform und Software** ```text show interfaces transceiver detail ``` **Juniper Junos** ```text show interfaces diagnostics optics ``` Bestimmte Schnittstelle: ```text show interfaces diagnostics optics ge-0/0/1 ``` **Aruba AOS-CX** ```text show interface transceiver ``` Die genaue Syntax muss in der Dokumentation der verwendeten Plattform geprüft werden. **Wichtige Einordnung** - Zu geringe Empfangsleistung kann auf Dämpfung, Verschmutzung, falsche Faser oder defekte Komponenten hinweisen. - Zu hohe Empfangsleistung kann einen Empfänger ebenfalls außerhalb des zulässigen Bereichs betreiben. - Ein angezeigter optischer Wert muss mit den Grenzwerten des konkreten Transceivers verglichen werden. - Ein Link kann trotz ungünstiger Werte zunächst funktionieren und später instabil werden. - Glasfaserstecker dürfen nur mit geeigneten Werkzeugen gereinigt und untersucht werden. --- **12. VLAN-Zuordnung prüfen** Typische Ursachen sind: - falsches Access-VLAN, - fehlendes VLAN, - VLAN nicht auf dem Trunk erlaubt, - unterschiedliche native VLANs, - falsche Voice-VLAN-Konfiguration, - VLAN auf einem Zwischen-Switch nicht vorhanden, - falsche Portrolle. **Cisco IOS beziehungsweise IOS XE** ```text show vlan brief ``` ```text show interfaces trunk ``` ```text show interfaces GigabitEthernet1/0/1 switchport ``` **Juniper Junos – abhängig vom Switching-Modell** ```text show vlans ``` ```text show ethernet-switching interfaces ``` **Aruba AOS-CX** ```text show vlan ``` ```text show vlan port 1/1/1 ``` ```text show interface 1/1/1 ``` **Prüfreihenfolge** 1. Endgeräteport identifizieren. 2. Portmodus bestimmen. 3. Access- oder untagged VLAN prüfen. 4. Trunk beziehungsweise tagged VLANs prüfen. 5. Zwischenverbindungen untersuchen. 6. VLAN auf jedem beteiligten Gerät prüfen. 7. Layer-3-Gateway des VLANs kontrollieren. 8. DHCP, ARP und Sicherheitsrichtlinien prüfen. --- **13. MAC-Adresstabelle untersuchen** Die MAC-Adresstabelle zeigt, an welcher Schnittstelle ein Switch eine MAC-Adresse gelernt hat. **Cisco IOS beziehungsweise IOS XE** ```text show mac address-table ``` Bestimmte Adresse: ```text show mac address-table address aaaa.bbbb.cccc ``` Bestimmte Schnittstelle: ```text show mac address-table interface GigabitEthernet1/0/1 ``` **Juniper Junos** ```text show ethernet-switching table ``` **Aruba AOS-CX** ```text show mac-address-table ``` **Mögliche Beobachtungen** | Beobachtung | Einordnung | |---|---| | MAC-Adresse fehlt | kein Verkehr, falsches VLAN, Port down oder Gerät nicht verbunden | | MAC-Adresse am erwarteten Port | Layer-2-Lernen funktioniert zumindest in dieser Richtung | | MAC-Adresse an unerwartetem Port | Verkabelung, Schleife, virtuelle Umgebung oder Topologie prüfen | | MAC-Adresse wechselt zwischen Ports | Schleife, redundante Fehlkonfiguration oder tatsächlich bewegtes Gerät | | sehr viele MAC-Adressen an einem Endgeräteport | unerwarteter Switch, Hypervisor, Access Point oder Sicherheitsproblem | | Tabelle nahezu ausgelastet | ungewöhnlich viele Geräte, Angriff oder Dimensionierungsproblem | > Eine gelernte MAC-Adresse bestätigt nicht, dass IP-Konfiguration, Routing, DNS oder die Anwendung funktionieren. --- **14. Spanning Tree untersuchen** Spanning Tree verhindert Layer-2-Schleifen in redundanten Ethernetnetzen. Zu prüfen sind: - Root Bridge, - Root Port, - Portrollen, - Portzustände, - Topology Changes, - blockierte beziehungsweise verworfene Ports, - verwendete STP-Variante, - unerwartete Root-Wahl, - Schutzmechanismen. **Cisco IOS beziehungsweise IOS XE** ```text show spanning-tree ``` Bestimmtes VLAN: ```text show spanning-tree vlan 10 ``` Details: ```text show spanning-tree detail ``` **Juniper Junos** ```text show spanning-tree bridge ``` ```text show spanning-tree interface ``` **Aruba AOS-CX** ```text show spanning-tree ``` ```text show spanning-tree detail ``` **Hinweise auf eine Layer-2-Schleife** - sehr hohe Broadcast- oder Multicastlast, - stark erhöhte CPU-Auslastung, - MAC-Adressen wechseln zwischen Ports, - Managementzugriff ist instabil, - viele Topology Changes, - Paketverlust im gesamten VLAN, - mehrere Ports zeigen außergewöhnlich hohe Datenraten. > Ein durch STP blockierter Port ist nicht automatisch fehlerhaft. Das Blockieren kann die beabsichtigte schleifenfreie Topologie herstellen. --- **15. Link Aggregation und LACP** Bei gebündelten Verbindungen müssen geprüft werden: - Mitgliedsschnittstellen, - physischer Linkstatus, - LACP-Zustand, - aktive und passive Seite, - Aggregationskennung, - Geschwindigkeit, - VLAN-Konfiguration, - Hashverfahren, - Mindestanzahl benötigter Mitglieder, - Konfiguration der Gegenstelle. **Cisco IOS beziehungsweise IOS XE** ```text show etherchannel summary ``` ```text show lacp neighbor ``` ```text show interfaces port-channel 1 ``` **Juniper Junos** ```text show interfaces ae0 extensive ``` ```text show lacp interfaces ``` **Aruba AOS-CX** ```text show lacp interfaces ``` ```text show interface lag 1 ``` **Typische Fehler** - Port ist nicht im Bündel aktiv, - unterschiedliche LACP-Modi, - ungleiche Geschwindigkeiten, - verschiedene VLAN-Listen, - Verbindung zu unterschiedlichen logischen Gegenstellen ohne passende Multi-Chassis-Technik, - fehlerhaftes Mitglied beeinträchtigt einen Teil des Datenverkehrs, - Hashverteilung belastet einzelne Mitglieder stärker. --- **16. LLDP und CDP zur Topologieprüfung** Nachbarerkennungsprotokolle helfen dabei, die tatsächlich angeschlossene Gegenstelle zu bestimmen. **Cisco Discovery Protocol** ```text show cdp neighbors ``` Details: ```text show cdp neighbors detail ``` **Link Layer Discovery Protocol auf Cisco** ```text show lldp neighbors ``` ```text show lldp neighbors detail ``` **Juniper Junos** ```text show lldp neighbors ``` ```text show lldp neighbors detail ``` **Aruba AOS-CX** ```text show lldp neighbor-info ``` **Zu beachten** - CDP ist proprietär und nicht auf allen Herstellern verfügbar. - LLDP ist herstellerübergreifend, kann aber deaktiviert sein. - Fehlende Nachbarinformationen beweisen nicht, dass keine physische Verbindung besteht. - Nachbardaten können Gerätenamen, Managementadressen und Topologieinformationen enthalten und müssen geschützt werden. --- **17. ARP und IPv6 Neighbor Discovery** ARP ordnet IPv4-Adressen MAC-Adressen zu. IPv6 verwendet Neighbor Discovery. **Cisco IOS beziehungsweise IOS XE** ```text show ip arp ``` ```text show ipv6 neighbors ``` **Juniper Junos** ```text show arp ``` ```text show ipv6 neighbors ``` **Aruba AOS-CX** ```text show arp ``` ```text show ipv6 neighbors ``` **Typische Beobachtungen** | Beobachtung | mögliche Ursache | |---|---| | kein Eintrag | Ziel nicht lokal, keine Antwort, falsches VLAN oder falsches Präfix | | Eintrag unvollständig | ARP- beziehungsweise Neighbor-Anfrage bleibt unbeantwortet | | wechselnde MAC-Adresse | doppelte IP-Adresse, Cluster, Proxy ARP oder Fehlkonfiguration | | MAC-Adresse stimmt nicht mit erwartetem Gerät überein | doppelte Adresse, falsche Dokumentation oder Manipulation | | Eintrag vorhanden, Kommunikation scheitert | Problem kann oberhalb der Nachbarauflösung liegen | Das manuelle Löschen von ARP- oder Neighbor-Einträgen verändert den Zustand und sollte erst nach Dokumentation und mit konkreter Hypothese erfolgen. --- **18. IP-Adressen und Routingtabelle** Zu prüfen sind: - IP-Adresse, - Präfixlänge, - direkt verbundene Netze, - Standardroute, - spezifische Routen, - nächste Hops, - Routingprotokoll, - administrative Distanz beziehungsweise Präferenz, - Metrik, - VRF oder Routinginstanz, - Rückweg. **Cisco IOS beziehungsweise IOS XE** ```text show ip interface brief ``` ```text show ip route ``` Bestimmtes Ziel: ```text show ip route 192.0.2.10 ``` IPv6: ```text show ipv6 route ``` VRF-Übersicht: ```text show vrf ``` **Juniper Junos** ```text show interfaces terse ``` ```text show route ``` Bestimmtes Ziel: ```text show route 192.0.2.10 ``` Routinginstanzen: ```text show route instance ``` **Aruba AOS-CX** ```text show ip interface brief ``` ```text show ip route ``` ```text show vrf ``` **Routingprüfung** 1. Quellnetz bestimmen. 2. Zieladresse exakt bestimmen. 3. verwendete VRF beziehungsweise Routinginstanz feststellen. 4. Route zum Ziel prüfen. 5. nächsten Hop prüfen. 6. Erreichbarkeit des nächsten Hops prüfen. 7. Rückroute untersuchen. 8. Policy-Based Routing berücksichtigen. 9. NAT, Firewall und VPN berücksichtigen. 10. bei dynamischem Routing den Protokollzustand prüfen. > Eine vorhandene Hinroute bestätigt keine funktionierende Rückroute. Asymmetrische Wege können insbesondere bei Firewalls und zustandsbehafteten Systemen Probleme verursachen. --- **19. Ping richtig verwenden** Ping verwendet ICMP Echo Request und Echo Reply. Damit können unter anderem untersucht werden: - grundsätzliche IP-Erreichbarkeit, - Paketverlust, - Laufzeit, - Erreichbarkeit aus einer bestimmten Quelle, - MTU-Probleme mit geeigneten Optionen. **Cisco IOS beziehungsweise IOS XE** ```text ping 192.0.2.10 ``` Erweiterter Dialog: ```text ping ``` **Juniper Junos** ```text ping 192.0.2.10 ``` Bestimmte Quelladresse: ```text ping 192.0.2.10 source 192.0.2.1 ``` **Aruba AOS-CX** ```text ping 192.0.2.10 ``` Die Optionen für Quelladresse, VRF, Paketgröße und Anzahl sind versionsabhängig. **Sinnvolle Zielreihenfolge** 1. eigene Schnittstellenadresse, 2. direkt verbundener nächster Hop, 3. Gateway, 4. entferntes IP-Ziel, 5. Ziel über Namen. **Grenzen** - ICMP kann gefiltert werden. - Eine Firewall kann Ping anders behandeln als Anwendungsverkehr. - Ein erfolgreicher Ping prüft keinen TCP-Port. - Ein erfolgreicher Ping bestätigt keine Anmeldung oder Anwendung. - Ein Ping ohne festgelegte Quelladresse kann einen anderen Pfad verwenden als der betroffene Datenverkehr. --- **20. Traceroute richtig verwenden** Traceroute hilft dabei, den Pfad beziehungsweise die antwortenden Zwischenstationen zu untersuchen. **Cisco IOS beziehungsweise IOS XE** ```text traceroute 192.0.2.10 ``` **Juniper Junos** ```text traceroute 192.0.2.10 ``` **Aruba AOS-CX** ```text traceroute 192.0.2.10 ``` **Einordnung** - Sternchen bedeuten nicht automatisch, dass der gesamte folgende Pfad unterbrochen ist. - Router können Ablaufmeldungen filtern oder begrenzen. - Lastverteilung kann verschiedene Pfade zeigen. - Hin- und Rückweg können unterschiedlich sein. - Tunnel und MPLS können physische Zwischenwege verbergen. - Ein Abbruch an einem Hop beweist nicht, dass genau dieses Gerät die Ursache ist. --- **21. Dynamische Routingprotokolle** Bei OSPF, BGP und anderen Protokollen sind drei Ebenen getrennt zu prüfen: 1. besteht die Nachbarschaft? 2. werden erwartete Routen ausgetauscht? 3. wird die gewünschte Route tatsächlich für die Weiterleitung verwendet? **Cisco – OSPF** ```text show ip ospf neighbor ``` ```text show ip ospf interface ``` ```text show ip route ospf ``` **Cisco – BGP** ```text show ip bgp summary ``` ```text show ip bgp ``` ```text show ip route bgp ``` **Juniper – OSPF** ```text show ospf neighbor ``` ```text show ospf interface ``` ```text show route protocol ospf ``` **Juniper – BGP** ```text show bgp summary ``` ```text show route protocol bgp ``` **Aruba AOS-CX – je nach Plattform und Funktionsumfang** ```text show ip ospf neighbors ``` ```text show bgp all summary ``` **Typische Ursachen** - Schnittstelle down, - falsche IP-Adresse oder Präfixlänge, - unterschiedliche Area, - Authentifizierungsfehler, - unterschiedliche Timer, - MTU-Abweichung, - fehlende Route zur Nachbaradresse, - falsche Autonomous-System-Nummer, - Filterrichtlinie, - maximale Präfixanzahl, - fehlende Freigabe durch ACL oder Firewall, - instabile Verbindung, - unterschiedliche VRF. > Eine bestehende Routingnachbarschaft bestätigt nicht, dass alle benötigten Präfixe korrekt angenommen, ausgewählt und weitergeleitet werden. --- **22. ACL- und Firewallregeln prüfen** Bei Zugriffslisten und Firewalls müssen geprüft werden: - Quelle, - Ziel, - Protokoll, - Quellport, - Zielport, - Eingangszone, - Ausgangszone, - Richtung, - Regelreihenfolge, - Zähler, - NAT, - Sitzungstabelle, - Benutzer- oder Anwendungsidentität, - Zeitplan, - Protokollierung. **Cisco IOS beziehungsweise IOS XE** ```text show access-lists ``` ```text show ip access-lists ``` Zuordnung zu Schnittstellen: ```text show ip interface ``` **Juniper SRX** ```text show security policies ``` ```text show security policies hit-count ``` ```text show security flow session ``` ```text show security nat source rule all ``` **Wichtige Einordnung** - Ein Regelzähler kann historischen Verkehr enthalten. - Ein Zähler von null kann bedeuten, dass der Datenverkehr eine frühere Regel trifft. - Zustandsbehaftete Firewalls benötigen häufig einen passenden Rückweg. - NAT kann dazu führen, dass Protokolle eine andere Adresse zeigen. - Eine erlaubende Regel bestätigt nicht, dass Routing, NAT oder Zielservice funktionieren. - Ein Paket kann vor oder nach einer untersuchten Regel verworfen werden. --- **23. DHCP untersuchen** Zu prüfen sind: - erhält der Client überhaupt eine DHCP-Antwort? - befindet sich Client und Server im selben Netz? - ist DHCP-Relay erforderlich? - stimmt die Relay-Zieladresse? - ist der Adressbereich erschöpft? - besteht eine Sicherheitsfunktion wie DHCP Snooping? - stimmen Gateway, DNS und Lease-Zeit? - erreicht die Antwort den Client zurück? **Cisco IOS beziehungsweise IOS XE** DHCP-Relay auf einer Schnittstelle erkennen: ```text show running-config interface Vlan10 ``` DHCP Snooping: ```text show ip dhcp snooping ``` DHCP-Bindings bei lokalem DHCP-Server: ```text show ip dhcp binding ``` **Juniper Junos** Die Befehle hängen davon ab, ob das Gerät als DHCP-Server, Relay oder Sicherheitsgerät arbeitet. Beispiele: ```text show dhcp server binding ``` ```text show dhcp relay binding ``` Diese Befehle sind nicht auf jeder Junos-Plattform in derselben Form verfügbar. **Typische Fehlerkette** ```text Client Discover → Switch und VLAN → DHCP Relay → Routing beziehungsweise Firewall → DHCP Server → Offer und Acknowledgement → Rückweg zum Client ``` --- **24. DNS, NTP, RADIUS und TACACS+** Netzwerkgeräte sind häufig von Infrastrukturdiensten abhängig. **DNS-Probleme können verursachen** - fehlgeschlagene Hostnamensauflösung, - nicht erreichbare Controller, - fehlgeschlagene Zertifikatsprüfung, - Probleme mit Cloudmanagement, - verzögerte Kommandoeingaben bei ungeeigneter Namensauflösung. **NTP-Probleme können verursachen** - falsche Protokollzeitpunkte, - Zertifikatsfehler, - Authentifizierungsprobleme, - unbrauchbare Ereigniskorrelation, - Probleme mit zeitabhängigen Sicherheitsmechanismen. **RADIUS- oder TACACS+-Probleme können verursachen** - fehlgeschlagene Administratoranmeldung, - fehlende Autorisierung einzelner Befehle, - fehlgeschlagene Netzwerkzugangskontrolle, - Abhängigkeit von einem nicht erreichbaren Server. **Cisco IOS beziehungsweise IOS XE** ```text show clock ``` ```text show ntp associations ``` ```text show ntp status ``` ```text show aaa servers ``` Die verfügbaren AAA-Befehle unterscheiden sich nach Plattform und Version. **Juniper Junos** ```text show system uptime ``` ```text show ntp associations ``` ```text show system users ``` **Prüfen** - stimmt die Uhrzeit? - stimmt die Zeitzone? - ist der Zeitserver erreichbar? - wird die erwartete Quelladresse verwendet? - erreicht der Dienst die richtige VRF? - blockiert eine ACL den Verkehr? - ist ein lokales Notfallkonto gemäß Unternehmensvorgabe vorhanden? --- **25. Protokolle auswerten** Netzwerkgeräte können Protokolle speichern oder an einen zentralen Syslog-Server senden. Zu erfassen sind: - genauer Zeitpunkt, - Zeitzone, - Meldungsquelle, - Schweregrad, - Prozess oder Subsystem, - betroffene Schnittstelle, - Meldung vor und nach dem Ereignis, - wiederkehrende Muster, - Zusammenhang mit Konfigurationsänderungen. **Cisco IOS beziehungsweise IOS XE** ```text show logging ``` **Juniper Junos** ```text show log messages ``` Letzte Einträge: ```text show log messages | last 50 ``` **Aruba AOS-CX** ```text show logging ``` **Typische Meldungen** - Link up oder down, - STP-Änderung, - Routingnachbarschaft verloren, - Authentifizierungsfehler, - Hardwarealarm, - Temperaturwarnung, - Konfigurationsänderung, - Prozessneustart, - Ressourcengrenze, - Firewallblockierung, - VPN-Neuverhandlung. > Eine einzelne Fehlermeldung beweist nicht automatisch die Ursache. Sie muss zeitlich und technisch mit dem beobachteten Symptom verbunden werden. --- **26. Syslog-Schweregrade** Die verbreitete Syslog-Einteilung umfasst: | Wert | Bezeichnung | Bedeutung | |---:|---|---| | 0 | Emergency | System nicht verwendbar | | 1 | Alert | sofortige Maßnahme erforderlich | | 2 | Critical | kritischer Zustand | | 3 | Error | Fehlerzustand | | 4 | Warning | Warnung | | 5 | Notice | bedeutender normaler Zustand | | 6 | Informational | Informationsmeldung | | 7 | Debug | ausführliche Diagnosemeldung | Die tatsächliche Nutzung der Stufen hängt vom Hersteller und der jeweiligen Komponente ab. **Zu beachten** - Zu niedrige Schwelle kann wichtige Meldungen auslassen. - Zu ausführliche Protokollierung kann sehr große Datenmengen erzeugen. - Debug-Protokolle können sensible Informationen enthalten. - Zentrale Protokolle benötigen korrekte Zeitstempel. - UDP-Syslog bestätigt keine zuverlässige Zustellung. - Transport, Verschlüsselung und Aufbewahrung müssen den Sicherheitsvorgaben entsprechen. --- **27. SNMP und Telemetrie** SNMP und Streaming-Telemetrie können langfristige Messwerte liefern. Typische Werte sind: - Schnittstellenstatus, - Datenraten, - Fehlerzähler, - Paketverluste, - CPU-Auslastung, - Speichernutzung, - Temperatur, - Netzteilzustand, - Routingnachbarschaften, - Verfügbarkeit. **SNMP-Versionen** | Version | Einordnung | |---|---| | SNMPv1 | veraltet, keine moderne Absicherung | | SNMPv2c | Community-basierte Absicherung, keine angemessene Vertraulichkeit | | SNMPv3 | unterstützt Benutzer-, Authentifizierungs- und Verschlüsselungsmechanismen | SNMPv3 sollte bevorzugt werden, sofern die Umgebung es unterstützt. **Diagnostischer Nutzen** - Beginn einer Störung zeitlich bestimmen, - kurzfristige und langfristige Werte vergleichen, - Lastspitzen erkennen, - wachsende Fehlerzähler sehen, - wiederkehrende Ausfälle untersuchen, - Geräte miteinander vergleichen. **Grenzen** - Abfrageintervalle können kurze Ereignisse übersehen. - Ein Mittelwert kann Spitzen verbergen. - Zähler können nach Neustarts zurückgesetzt werden. - 32-Bit-Zähler können bei schnellen Verbindungen überlaufen. - fehlerhafte Zeitsynchronisation erschwert die Korrelation. - Monitoringausfall bedeutet nicht automatisch Geräteausfall. --- **28. Paketmitschnitt auf Netzwerkgeräten** Viele Router, Firewalls und Switches unterstützen lokale oder gespiegelte Paketmitschnitte. Mögliche Verfahren: - integrierter Paketmitschnitt, - Port Mirroring, - SPAN, - Remote SPAN, - ERSPAN, - Firewall Packet Capture, - Controller-basierter Mitschnitt, - externer Netzwerk-TAP. **Vorher festlegen** - betroffene Schnittstelle, - Richtung, - VLAN, - Quelladresse, - Zieladresse, - Protokoll, - Zielport, - maximale Paketanzahl, - maximale Dateigröße, - Dauer, - Speicherort, - Datenschutz, - Löschzeitpunkt. **Wichtige Einschränkungen** - Ein Mitschnitt auf einem überlasteten Gerät kann unvollständig sein. - Hardwareweiterleitung kann dazu führen, dass nicht jeder Verkehr an der CPU sichtbar ist. - Ein SPAN-Ziel kann bei Überlastung Pakete verlieren. - Der Mitschnittpunkt bestimmt, ob VLAN-Tags, NAT-Adressen oder entschlüsselter Verkehr sichtbar sind. - Eine Firewall kann Pakete an einer Schnittstelle empfangen und später durch eine Regel verwerfen. - Verschlüsselter Datenverkehr zeigt ohne zulässige Entschlüsselung keine Anwendungsinhalte. Paketmitschnitte können enthalten: - IP-Adressen, - MAC-Adressen, - Hostnamen, - DNS-Abfragen, - Anmeldedaten bei unverschlüsselten Protokollen, - Sitzungskennungen, - personenbezogene Daten, - vertrauliche Anwendungsinhalte. --- **29. Debug-Befehle** Debug-Befehle erzeugen detaillierte Laufzeitinformationen. Sie können: - sehr viele Meldungen erzeugen, - CPU und Speicher belasten, - die Konsole überfluten, - Sitzungen unterbrechen, - sensible Inhalte protokollieren, - bei produktiven Geräten einen Ausfall verschärfen. **Vor einem Debug** 1. konkrete Hypothese formulieren, 2. Herstellerdokumentation prüfen, 3. Auswirkungen für die Plattform prüfen, 4. Wartungsfreigabe einholen, 5. Filter festlegen, 6. Zeitdauer begrenzen, 7. Beendigung des Debugs vorbereiten, 8. alternative Beobachtungsmöglichkeit prüfen. **Cisco IOS beziehungsweise IOS XE** Aktive Debugs anzeigen: ```text show debugging ``` Debug-Ausgaben vollständig beenden: ```text undebug all ``` Der Befehl `debug all` darf auf produktiven Geräten nicht als allgemeine Diagnosemaßnahme verwendet werden. > Ein Debug sollte nur gezielt, zeitlich begrenzt und unter Beobachtung durchgeführt werden. --- **30. Konfiguration vergleichen** Zu unterscheiden sind: - aktuell laufende Konfiguration, - für den nächsten Start gespeicherte Konfiguration, - zentral verwaltete Konfiguration, - automatisch erzeugte Konfiguration, - Konfigurationsvorlage, - tatsächlicher operativer Zustand. **Cisco IOS beziehungsweise IOS XE** ```text show running-config ``` ```text show startup-config ``` Letzte Konfigurationsänderung: ```text show archive log config all ``` Der Archivierungsbefehl liefert nur dann passende Daten, wenn die entsprechende Funktion unterstützt und eingerichtet ist. **Juniper Junos** ```text show configuration ``` Vergleich mit vorheriger Konfiguration: ```text show system commit ``` ```text show system rollback compare 1 ``` **Aruba AOS-CX** ```text show running-config ``` ```text show startup-config ``` **Beim Vergleich beachten** - automatisch erzeugte Zeilen, - unterschiedliche Reihenfolge ohne Funktionsänderung, - verschlüsselte oder maskierte Geheimnisse, - dynamisch gelernte Zustände, - Änderungen durch Controller oder Automatisierung, - nicht gespeicherte Änderungen, - gerätespezifische Standardwerte. > Eine Konfiguration darf nicht ungeprüft vollständig in ein Ticket oder öffentliches Dokument kopiert werden. Sie kann Kennwörter, Schlüssel, Community-Strings, Adressen und interne Topologieinformationen enthalten. --- **31. Hochverfügbarkeit und Stacks** Bei redundanten Geräten sind zusätzlich zu prüfen: - aktives und passives Mitglied, - Synchronisationsstatus, - letzte Rollenänderung, - Split-Brain-Schutz, - Heartbeat- oder Keepalive-Verbindung, - Versionsgleichheit, - Konfigurationsgleichheit, - Sitzungssynchronisation, - Uplinkzustand beider Geräte, - Stack-Ring, - Stack-Mitglieder, - Redundanz der Stromversorgung. **Mögliche Fehlerbilder** | Beobachtung | mögliche Ursache | |---|---| | beide Geräte halten sich für aktiv | Split Brain oder unterbrochene Kontrollverbindung | | passives Gerät nicht bereit | Versions-, Konfigurations- oder Hardwareproblem | | Failover funktioniert, Sitzungen brechen ab | fehlende oder unvollständige Sitzungssynchronisation | | nur Ports eines Stack-Mitglieds betroffen | Mitglied, Stack-Verbindung oder Stromversorgung | | wiederholte Rollenwechsel | instabile Verbindung, Ressourcenproblem oder fehlerhafte Zustandsprüfung | | Redundanz angezeigt, aber gemeinsamer Uplink fehlt | logische Redundanz ohne vollständige Pfadredundanz | Ein manuell ausgelöstes Failover ist eine produktive Änderung und benötigt eine Risikoprüfung. --- **32. WLAN-Access-Points und Controller** Bei WLAN-Problemen müssen Funk-, Netzwerk- und Authentifizierungsebene getrennt werden. Zu prüfen sind: - wird der Access Point mit Strom versorgt? - erhält er eine IP-Adresse? - erreicht er Controller oder Cloudplattform? - wird die erwartete Konfiguration übernommen? - sendet die gewünschte SSID? - stimmen VLAN und Trunk? - funktioniert Authentifizierung? - erhält der Client eine IP-Adresse? - bestehen Störungen oder hohe Kanalauslastung? - wechselt der Client zwischen Access Points? - funktionieren DNS und Gateway? **Typische WLAN-Werte** - RSSI, - SNR, - Kanal, - Kanalbreite, - Frequenzband, - Sendeleistung, - Retries, - Kanalnutzung, - Clientanzahl, - Datenrate, - Roamingereignisse, - Authentifizierungsstatus. **Fehlinterpretationen vermeiden** | Beobachtung | Einordnung | |---|---| | starke Signalstärke | bestätigt nicht automatisch gute Signalqualität oder geringen Störpegel | | Client ist verbunden | bestätigt nicht automatisch DHCP, Routing oder Internetzugriff | | SSID ist sichtbar | bestätigt nicht automatisch erfolgreiche Authentifizierung | | Access Point ist online | bestätigt nicht automatisch störungsfreien Funkbetrieb | | hohe theoretische Datenrate | entspricht nicht automatisch dem tatsächlichen Durchsatz | | viele Access Points | können bei ungeeigneter Planung zusätzliche Störungen verursachen | --- **33. VPN untersuchen** Bei einem VPN müssen getrennt geprüft werden: 1. physische und IP-Erreichbarkeit, 2. Namensauflösung, 3. IKE- beziehungsweise Kontrollverbindung, 4. Authentifizierung, 5. Tunnelaufbau, 6. Verschlüsselungsparameter, 7. Routen, 8. Sicherheitsrichtlinien, 9. NAT-Ausnahmen, 10. Datenzähler, 11. Rückweg, 12. MTU und Fragmentierung. **Typische Fehler** - falsche Peer-Adresse, - Zertifikat abgelaufen, - falsche Systemzeit, - unterschiedliche Verschlüsselungsverfahren, - unterschiedliche Netzdefinitionen, - fehlende Route, - NAT vor dem Tunnel, - Firewall blockiert IKE oder ESP, - Tunnel steht, aber keine Sicherheitsrichtlinie erlaubt den Verkehr, - überlappende Adressbereiche, - asymmetrischer Rückweg, - MTU-Problem. > Ein angezeigter VPN-Status „up“ bestätigt nicht automatisch, dass Nutzdaten in beide Richtungen übertragen werden. --- **34. NAT untersuchen** Bei NAT sind zu erfassen: - ursprüngliche Quelladresse, - ursprüngliche Zieladresse, - übersetzte Quelladresse, - übersetzte Zieladresse, - Quellport, - Zielport, - zugehörige Regel, - Richtung, - Zone, - Sitzung, - Rückweg. **Typische Probleme** - falsche Regelreihenfolge, - fehlende NAT-Ausnahme für VPN, - Adresspool erschöpft, - Portübersetzung erschöpft, - unerwartetes doppeltes NAT, - Rückroute zur übersetzten Adresse fehlt, - Anwendung überträgt eingebettete Adressen, - Protokolle zeigen nur eine Seite der Übersetzung. Eine erfolgreiche NAT-Übersetzung bestätigt noch nicht, dass der Zielservice antwortet. --- **35. Support- und Diagnosepakete** Viele Hersteller bieten einen Sammelbefehl oder eine Supportdatei an. Beispiele: **Cisco – plattformabhängig** ```text show tech-support ``` **Juniper Junos** ```text request support information ``` **Aruba AOS-CX** ```text show tech ``` Diese Ausgaben können sehr umfangreich sein und das Gerät belasten. Sie können enthalten: - vollständige oder teilweise Konfiguration, - IP-Adressen, - Seriennummern, - Benutzernamen, - Routinginformationen, - Nachbarn, - Protokolle, - Zertifikatsinformationen, - Sitzungstabellen, - interne Topologie, - Sicherheitsrichtlinien. **Vor der Erstellung** - Speicherplatz prüfen, - Belastung abschätzen, - Freigabe einholen, - sicheren Speicherort bestimmen, - Übertragungsweg festlegen, - Empfängerkreis begrenzen, - Aufbewahrungsdauer definieren, - vertrauliche Inhalte prüfen. --- **36. Typische Prüfreihenfolge bei einem ausgefallenen Switchport** 1. betroffenes Endgerät und Port bestimmen, 2. Linkstatus prüfen, 3. Portbeschreibung kontrollieren, 4. Fehlerzähler dokumentieren, 5. Geschwindigkeit und Duplex prüfen, 6. VLAN-Zuordnung prüfen, 7. MAC-Adresstabelle prüfen, 8. STP-Zustand prüfen, 9. Port-Security oder NAC prüfen, 10. PoE-Zustand prüfen, 11. Nachbarinformationen prüfen, 12. Gegenstelle untersuchen, 13. Kabel oder Transceiver kontrolliert gegenprüfen, 14. nach jeder Maßnahme erneut testen. **Beispiel Cisco IOS beziehungsweise IOS XE** ```text show interfaces status ``` ```text show interfaces GigabitEthernet1/0/1 ``` ```text show interfaces GigabitEthernet1/0/1 switchport ``` ```text show mac address-table interface GigabitEthernet1/0/1 ``` ```text show spanning-tree interface GigabitEthernet1/0/1 detail ``` ```text show power inline GigabitEthernet1/0/1 ``` --- **37. Praxisbeispiel: Client erreicht das Gateway nicht** **Symptom** Ein Client besitzt eine IP-Adresse, kann aber sein Standardgateway nicht erreichen. **Prüfung** 1. IP-Adresse und Präfix des Clients kontrollieren. 2. Standardgateway kontrollieren. 3. physische Verbindung prüfen. 4. Access-VLAN des Ports prüfen. 5. VLAN auf den Trunks verfolgen. 6. MAC-Adresse des Clients suchen. 7. ARP-Eintrag auf Client und Gateway prüfen. 8. Gateway-Schnittstelle beziehungsweise SVI prüfen. 9. STP-Zustand prüfen. 10. Port-Security, NAC und ACL prüfen. 11. Paketmitschnitt nur bei verbleibender Unklarheit verwenden. **Mögliche Ursachen** - falsche Clientadresse, - falsches Präfix, - falsches Gateway, - falsches Access-VLAN, - VLAN fehlt auf einem Trunk, - Gateway-Schnittstelle down, - doppelte IP-Adresse, - ARP-Problem, - Port-Security, - NAC-Quarantäne, - Layer-2-Schleife, - fehlerhafte physische Verbindung. --- **38. Praxisbeispiel: VLAN funktioniert an einem Switch, am nächsten nicht** **Prüfung** 1. VLAN auf beiden Switches anzeigen. 2. Access-Port des Clients prüfen. 3. Uplink und Trunk bestimmen. 4. erlaubte VLANs auf beiden Seiten vergleichen. 5. native beziehungsweise untagged VLANs vergleichen. 6. STP-Zustand für das VLAN prüfen. 7. MAC-Adresse entlang des Pfads verfolgen. 8. LACP-Zustand bei gebündeltem Uplink prüfen. 9. Zwischen-Switches einbeziehen. 10. erst danach Konfiguration ändern. **Mögliche Ursachen** - VLAN auf einem Gerät nicht angelegt, - VLAN nicht auf dem Trunk erlaubt, - unterschiedliche Portmodi, - falsches untagged beziehungsweise native VLAN, - STP blockiert den erwarteten Pfad, - fehlerhaftes LACP-Mitglied, - falsche physische Verbindung, - VLAN-Zuordnung durch Controller oder Vorlage überschrieben. --- **39. Praxisbeispiel: Standortverbindung ist langsam** **Zuerst messen** - betroffene Standorte, - betroffene Anwendungen, - Beginn und Dauer, - Paketverlust, - Laufzeit, - Durchsatz, - Schnittstellenauslastung, - Fehlerzähler, - Drops, - QoS-Warteschlangen, - VPN-Zähler, - CPU-Auslastung, - MTU. **Mögliche Ursachen** - ausgelastete WAN-Verbindung, - Output Drops, - physische Fehler, - Duplexproblem, - ungeeignete QoS-Regel, - Backup- oder Synchronisationsverkehr, - Paketverlust im Providerpfad, - VPN-Neuverschlüsselung, - MTU- oder Fragmentierungsproblem, - Anwendung oder Server statt Netzwerk, - asymmetrischer Pfad. > Ein hoher Ping-Wert allein beweist keine geringe verfügbare Bandbreite. Laufzeit, Paketverlust, Jitter und Durchsatz sind unterschiedliche Messgrößen. --- **40. Praxisbeispiel: Gerät ist im Monitoring offline** **Prüfreihenfolge** 1. ist nur das Monitoring oder auch die Nutzfunktion betroffen? 2. ist die Managementadresse erreichbar? 3. stimmt die Route zum Managementnetz? 4. funktioniert der verwendete SNMP-, HTTPS- oder Telemetrieport? 5. stimmt die Management-VRF? 6. sind ACL und Firewallregeln unverändert? 7. sind Zugangsdaten oder Zertifikate abgelaufen? 8. stimmt die Gerätezeit? 9. ist der Monitoringdienst selbst funktionsfähig? 10. antwortet das Gerät über einen anderen Managementweg? **Mögliche Einordnung** | Ergebnis | mögliche Ursache | |---|---| | Nutzdaten funktionieren, Monitoring nicht | Managementpfad, SNMP, Zertifikat oder Monitoringserver | | Ping funktioniert, SNMP nicht | SNMP-Konfiguration, ACL, Zugangsdaten oder Dienst | | mehrere Geräte gleichzeitig offline | Monitoringserver, gemeinsamer Managementpfad oder zentrale Firewall | | nur ein Standort offline | WAN-, VPN- oder Standortproblem | | Gerät nur über Konsole erreichbar | Managementnetz, Routing, ACL oder Überlastung | --- **41. Häufige Fehlinterpretationen** | Aussage | fachliche Einordnung | |---|---| | „Der Port ist up, also ist die Verbindung in Ordnung.“ | Linkstatus bestätigt nicht VLAN, Routing, Fehlerfreiheit oder Anwendung. | | „Ping funktioniert, daher ist der Dienst erreichbar.“ | Ping prüft keinen Anwendungsport und keine Anmeldung. | | „Die Route ist vorhanden, also muss der Verkehr funktionieren.“ | Rückroute, Firewall, NAT und operative Weiterleitung müssen ebenfalls stimmen. | | „Der Traceroute endet an einem Router, also ist dieser defekt.“ | Zwischenstationen können Antworten filtern oder begrenzen. | | „STP blockiert einen Port, deshalb liegt ein Fehler vor.“ | Das Blockieren kann die beabsichtigte Schleifenvermeidung sein. | | „Der Fehlerzähler ist hoch, daher besteht der Fehler noch.“ | Entscheidend ist, ob der Zähler während der Störung weiter steigt. | | „Die MAC-Adresse wurde gelernt, also funktioniert der Client.“ | Nur das Layer-2-Lernen wurde nachgewiesen. | | „Das VPN ist up, also fließen Daten.“ | Routen, Richtlinien, NAT und Rückweg können weiterhin fehlerhaft sein. | | „Das Gerät ist im Monitoring offline, also ist es ausgefallen.“ | Nur der Management- oder Monitoringpfad kann gestört sein. | | „Ein Neustart behebt das Problem.“ | Er kann nur flüchtigen Zustand entfernen und Beweise vernichten. | | „`show tech` ist nur eine harmlose Abfrage.“ | Umfangreiche Ausgaben können Ressourcen beanspruchen und vertrauliche Daten enthalten. | | „Debug zeigt viele Fehler, also ist die Ursache gefunden.“ | Debug-Meldungen müssen mit Zeitpunkt, Datenpfad und Symptom abgeglichen werden. | --- **42. Checkliste Netzwerkgeräte-Fehleranalyse** - [ ] betroffenes Gerät und dessen Rolle sind bekannt. - [ ] Hersteller, Modell und Softwareversion wurden erfasst. - [ ] Zeitpunkt und letzte Änderungen wurden dokumentiert. - [ ] laufende und gespeicherte Konfiguration wurden unterschieden. - [ ] Managementzugriff wurde ohne unsichere Protokolle geprüft. - [ ] CPU, Arbeitsspeicher und Hardwarezustand wurden kontrolliert. - [ ] Schnittstellenstatus und Fehlerzähler wurden dokumentiert. - [ ] Geschwindigkeit, Duplex und Medium wurden auf beiden Seiten geprüft. - [ ] VLANs und Trunks wurden entlang des gesamten Pfads untersucht. - [ ] MAC-, ARP- und IPv6-Nachbartabellen wurden geprüft. - [ ] STP und LACP wurden berücksichtigt. - [ ] Hin- und Rückroute wurden geprüft. - [ ] richtige VRF beziehungsweise Routinginstanz wurde verwendet. - [ ] Ping wurde bei Bedarf mit passender Quelladresse durchgeführt. - [ ] Traceroute-Ergebnisse wurden nicht vorschnell interpretiert. - [ ] ACL, Firewall, NAT und Sitzungstabellen wurden berücksichtigt. - [ ] DNS, DHCP, NTP und Authentifizierungsdienste wurden getrennt geprüft. - [ ] Protokolle wurden zeitlich mit dem Symptom abgeglichen. - [ ] Zeitzone und Zeitsynchronisation wurden berücksichtigt. - [ ] Monitoringwerte wurden mit aktuellen Gerätedaten verglichen. - [ ] Debugging wurde nur gezielt und zeitlich begrenzt verwendet. - [ ] Paketmitschnitte wurden begrenzt und geschützt. - [ ] Supportdateien wurden auf vertrauliche Inhalte geprüft. - [ ] Änderungen wurden einzeln und möglichst reversibel durchgeführt. - [ ] Funktion und Nebenwirkungen wurden nach jeder Änderung geprüft. - [ ] Ursache, Maßnahme und Ergebnis wurden dokumentiert. --- **43. Schnellreferenz** | Aufgabe | Cisco IOS/IOS XE | Juniper Junos | Aruba AOS-CX | |---|---|---|---| | Version | `show version` | `show version` | `show version` | | Hardware | `show inventory` | `show chassis hardware` | `show inventory` | | Systemzustand | `show platform resources` | `show chassis routing-engine` | `show system resource-utilization` | | Schnittstellenübersicht | `show ip interface brief` | `show interfaces terse` | `show ip interface brief` | | Schnittstellendetails | `show interfaces …` | `show interfaces … extensive` | `show interface …` | | VLANs | `show vlan brief` | `show vlans` | `show vlan` | | Trunks | `show interfaces trunk` | `show ethernet-switching interfaces` | Port- und VLAN-Status prüfen | | MAC-Tabelle | `show mac address-table` | `show ethernet-switching table` | `show mac-address-table` | | Spanning Tree | `show spanning-tree` | `show spanning-tree bridge` | `show spanning-tree` | | LACP | `show lacp neighbor` | `show lacp interfaces` | `show lacp interfaces` | | LLDP | `show lldp neighbors` | `show lldp neighbors` | `show lldp neighbor-info` | | ARP | `show ip arp` | `show arp` | `show arp` | | Routingtabelle | `show ip route` | `show route` | `show ip route` | | OSPF-Nachbarn | `show ip ospf neighbor` | `show ospf neighbor` | `show ip ospf neighbors` | | BGP-Übersicht | `show ip bgp summary` | `show bgp summary` | `show bgp all summary` | | Protokolle | `show logging` | `show log messages` | `show logging` | | NTP | `show ntp associations` | `show ntp associations` | versionsabhängig | | Ping | `ping Ziel` | `ping Ziel` | `ping Ziel` | | Traceroute | `traceroute Ziel` | `traceroute Ziel` | `traceroute Ziel` | | Supportausgabe | `show tech-support` | `request support information` | `show tech` | > Diese Tabelle ist eine Orientierung. Vor der Verwendung muss die Befehlsreferenz der konkreten Plattform und Softwareversion geprüft werden. --- **Merksatz** > Netzwerkgeräte werden nicht durch wahllose Neustarts, Tabellenlöschungen oder dauerhafte Debug-Ausgaben untersucht. Zuerst werden Hardware, Schnittstellen, VLANs, Nachbartabellen, Routing, Sicherheitsregeln, Protokolle und Abhängigkeiten getrennt geprüft. Danach wird eine konkrete Hypothese mit einer kleinen, kontrollierten und möglichst reversiblen Maßnahme getestet. --- **Quellen und weiterführende Dokumentation** - [Cisco – Ping- und Traceroute-Befehle verstehen](https://www.cisco.com/c/en/us/support/docs/ios-nx-os-software/ios-software-releases-121-mainline/12778-ping-traceroute.html) - [Cisco – Extended Ping und Extended Traceroute](https://www.cisco.com/c/en/us/support/docs/ip/routing-information-protocol-rip/13730-ext-ping-trace.html) - [Cisco – Switch-Port- und Schnittstellenprobleme untersuchen](https://www.cisco.com/c/en/us/support/docs/switches/catalyst-6500-series-switches/12027-53.html) - [Cisco – Troubleshooting Tools](https://www.cisco.com/en/US/docs/internetworking/troubleshooting/guide/tr1902.html) - [Juniper – `show interfaces terse`](https://www.juniper.net/documentation/us/en/software/junos/cli-reference/topics/ref/command/show-interfaces-terse.html) - [Juniper – Netzwerkprobleme untersuchen](https://www.juniper.net/documentation/us/en/software/junos/bgp/topics/topic-map/troubleshooting-network-issues.html) - [Juniper – Junos OS CLI User Guide](https://www.juniper.net/documentation/us/en/software/junos/cli/cli.pdf) - [HPE Aruba Networking – AOS-CX 10.15 CLI Guide für 6300/6400](https://www.arubanetworks.com/techdocs/AOS-CX/10.15/PDF/cli_6300-6400.pdf) - [HPE Aruba Networking – AOS-CX `show tech`](https://www.arubanetworks.com/techdocs/AOS-CX/10.15/HTML/fundamentals_8400/Content/SysHW_cmds/sho-tec.htm) - [IETF RFC 5424 – The Syslog Protocol](https://www.rfc-editor.org/rfc/rfc5424) - [IETF RFC 3411 – SNMP Management Frameworks](https://www.rfc-editor.org/rfc/rfc3411) - [IETF RFC 3414 – SNMPv3 User-based Security Model](https://www.rfc-editor.org/rfc/rfc3414) - [IETF RFC 5905 – Network Time Protocol Version 4](https://www.rfc-editor.org/rfc/rfc5905) # 5.7 Physische Messgeräte – Werkzeuge zur Fehleranalyse Softwarewerkzeuge zeigen, wie Betriebssysteme, Netzwerkgeräte und Anwendungen einen Fehler wahrnehmen. Physische Messgeräte untersuchen dagegen Kabel, Steckverbindungen, elektrische Signale, optische Signale, Funkstörungen und die tatsächliche Stromversorgung. Sie werden benötigt, wenn beispielsweise: - eine Verbindung trotz korrekter Konfiguration instabil bleibt, - ein Port keinen Link aufbaut, - Fehlerzähler kontinuierlich steigen, - Power over Ethernet nicht zuverlässig funktioniert, - eine Glasfaserverbindung zu hohe Dämpfung aufweist, - eine Netzwerkdose nicht eindeutig zugeordnet werden kann, - ein WLAN durch nicht sichtbare Funkquellen gestört wird, - ein Server über das normale Netzwerk nicht mehr erreichbar ist, - ein Kabel- oder Hardwarefehler von einem Konfigurationsfehler getrennt werden muss. > Ein Messgerät liefert Messwerte und Beobachtungen. Die Ursache ergibt sich erst aus der Verbindung zwischen Symptom, Messpunkt, Referenzwert, Vergleichsmessung und technischer Dokumentation. --- **1. Sicherheits- und Freigaberegeln** Vor jeder physischen Messung müssen geklärt werden: - Darf die Verbindung unterbrochen werden? - Handelt es sich um eine produktive Verbindung? - Besteht eine redundante Verbindung? - Kann das Abziehen eines Kabels einen Failover auslösen? - Wird über das Kabel gleichzeitig Strom übertragen? - Handelt es sich um Kupfer, Glasfaser oder eine andere Leitung? - Ist das Messgerät für den Anschluss und den Messbereich geeignet? - Muss persönliche Schutzausrüstung verwendet werden? - Sind elektrische Arbeiten einer Elektrofachkraft vorbehalten? - Können durch die Messung vertrauliche Daten erfasst werden? - Muss der ursprüngliche Zustand fotografiert oder dokumentiert werden? - Ist eine Änderung oder Wartungsfreigabe erforderlich? **Grundregeln** - Kabel und Module vor dem Entfernen eindeutig kennzeichnen. - Vorher- und Nachher-Zustand dokumentieren. - Nur geeignete und unbeschädigte Messleitungen verwenden. - Messgeräte nicht ungeprüft an unbekannte Spannungsquellen anschließen. - Glasfaserstecker nicht mit bloßem Auge betrachten. - Aktive Glasfaser kann unsichtbare Laserstrahlung führen. - Optische Anschlüsse vor dem Verbinden inspizieren und erforderlichenfalls fachgerecht reinigen. - Multimeter nur durch dafür qualifizierte Personen und im zulässigen Einsatzbereich verwenden. - Produktive Leitungen nicht ohne Prüfung mit einem Tongenerator, Kabeltester oder Loopback-Stecker verbinden. - Messergebnisse zusammen mit Zeitpunkt, Messpunkt, Geräteeinstellung und Grenzwert dokumentieren. --- **2. Sichtprüfung vor dem Einsatz eines Messgeräts** Eine systematische Sichtprüfung kann bereits viele Fehler erkennen. Zu prüfen sind: - geknickte oder gequetschte Kabel, - beschädigte Isolierung, - zu enge Biegeradien, - Zugbelastung, - beschädigte Rastnasen, - lockere Steckverbindungen, - verschmutzte Anschlüsse, - verbogene Kontakte, - ungeeignete Kupplungen oder Adapter, - Korrosion, - Feuchtigkeit, - übermäßige Wärme, - beschädigte Patchfelder, - unvollständige Auflegung, - falsche Beschriftung, - falsch eingesetzte Transceiver, - unterschiedliche Fasertypen, - ungeeignete Patchkabel, - blockierte Lüftungsöffnungen, - ausgefallene Lüfter, - Warnanzeigen an Netzteilen oder Geräten. **LED-Anzeigen einordnen** | Anzeige | mögliche Bedeutung | |---|---| | keine Link-LED | kein Signal, Gegenstelle aus, falsches Medium, Kabel- oder Portfehler | | Link vorhanden, keine Aktivität | keine Datenübertragung oder nur momentan kein Verkehr | | ständig hohe Aktivität | starke Auslastung, Schleife, Broadcastlast oder normaler hoher Verkehr | | orange beziehungsweise gelbe LED | herstellerabhängig: Geschwindigkeit, Warnung, Blockierung oder Fehler | | wechselnde Farben | herstellerabhängiger Status oder ausgehandelte Geschwindigkeit | | PoE-Fehleranzeige | Leistungsbudget, Klassifizierung, Kurzschluss oder inkompatibles Gerät | > LED-Farben und Blinkmuster sind nicht herstellerübergreifend standardisiert. Ihre Bedeutung muss in der Dokumentation des konkreten Geräts geprüft werden. --- **3. Ersatzkabel bekannter Qualität** Ein geprüftes Ersatzkabel ist eines der wichtigsten Diagnosemittel. Es eignet sich für den kontrollierten Vergleich von: - Patchkabeln, - USB-Kabeln, - Konsolenkabeln, - Stromkabeln, - Glasfaser-Patchkabeln, - DAC-Kabeln, - Adapterkabeln. Das Ersatzkabel muss: - zum Anschluss passen, - für die benötigte Geschwindigkeit geeignet sein, - die erforderliche Kategorie oder Spezifikation erfüllen, - die richtige Belegung besitzen, - bei Glasfaser den richtigen Fasertyp und Steckertyp verwenden, - bei USB Datenübertragung und nicht nur Laden unterstützen, - selbst geprüft und eindeutig gekennzeichnet sein. **Vorgehensweise** 1. Ausgangszustand dokumentieren. 2. betroffene Verbindung eindeutig bestimmen. 3. nur das verdächtige Kabel austauschen. 4. alle übrigen Komponenten unverändert lassen. 5. Funktion erneut prüfen. 6. ursprüngliches Kabel bei Bedarf separat testen. 7. Ergebnis dokumentieren. **Einordnung** | Ergebnis | mögliche Schlussfolgerung | |---|---| | Fehler verschwindet mit Ersatzkabel | ursprüngliches Kabel oder dessen Steckkontakt ist verdächtig | | Fehler bleibt unverändert | Ursache liegt möglicherweise an Port, Gerät, Konfiguration oder weiterem Leitungsweg | | Fehler tritt nur bei Bewegung auf | Kabelbruch, Steckkontakt oder Zugbelastung möglich | | niedrigere Geschwindigkeit funktioniert | Signalqualität, Kabelkategorie, Adernpaar oder Transceiver möglich | | Ersatzkabel funktioniert nur an anderem Port | Port- oder Konfigurationsproblem möglich | > Ein funktionierendes Ersatzkabel beweist nicht automatisch, dass die gesamte feste Gebäudeverkabelung fehlerfrei ist. --- **4. Einfacher Kupfer-Kabeltester** Ein einfacher Kabeltester prüft vor allem die elektrische Verbindung und die Aderzuordnung eines Kupferkabels. Typische Prüfungen sind: - Durchgang, - Unterbrechung, - Kurzschluss, - vertauschte Adern, - gekreuzte Adern, - Split Pair, - Schirmverbindung, - Länge oder ungefähre Fehlerentfernung bei höherwertigen Geräten. **Typische Fehlerbilder** | Messergebnis | Bedeutung | |---|---| | Open | mindestens eine Ader ist unterbrochen | | Short | unerwünschte elektrische Verbindung zwischen Adern | | Reversed | Adern eines Paares sind vertauscht | | Crossed | Adern beziehungsweise Paare sind falsch zugeordnet | | Split Pair | Pinbelegung kann logisch richtig erscheinen, aber die Adern stammen aus falschen verdrillten Paaren | | Shield Open | Schirmverbindung ist unterbrochen | | Length Error | gemessene Länge oder Fehlerentfernung ist unplausibel | **Grenzen eines einfachen Kabeltesters** Ein bestandener Wiremap-Test bestätigt nicht automatisch: - die geforderte Kabelkategorie, - ausreichende Signalqualität, - geringe Dämpfung, - ausreichende Nebensprechdämpfung, - fehlerfreien Betrieb bei hoher Datenrate, - zuverlässige PoE-Übertragung unter Last, - korrekte Qualität aller Steck- und Anschlussstellen. Ein Kabel kann bei 100 Mbit/s funktionieren und bei 1, 2,5, 5 oder 10 Gbit/s fehlschlagen. --- **5. Verification, Qualification und Certification** Bei Kupferverkabelung müssen drei Prüfklassen unterschieden werden. | Prüfklasse | Zweck | typische Aussage | |---|---|---| | Verification | Verdrahtung und grundlegende physische Fehler prüfen | Adern korrekt verbunden oder Fehler vorhanden | | Qualification | Eignung für bestimmte Netzwerktechnik untersuchen | Verbindung unterstützt wahrscheinlich eine bestimmte Ethernet-Anwendung | | Certification | Verkabelung gegen definierte Norm- und Kategoriegrenzen messen | Permanent Link oder Channel besteht beziehungsweise besteht nicht | **Verification** Geeignet für: - schnelle Fehlersuche, - Wiremap, - Kabellänge, - Kurzschluss, - Unterbrechung, - Split Pair, - Zuordnung einer Leitung. **Qualification** Kann zusätzlich untersuchen: - mögliche Netzwerkgeschwindigkeit, - Signalqualität, - Paketübertragung, - Linkfähigkeit, - teilweise PoE-Eigenschaften. **Certification** Ein Kabelzertifizierer misst abhängig von Norm, Adapter und Messaufbau unter anderem: - Wiremap, - Länge, - Einfügedämpfung, - Laufzeit, - Laufzeitunterschied, - Gleichstromwiderstand, - Widerstandsunsymmetrie, - Near-End Crosstalk, - Power Sum NEXT, - Return Loss, - Attenuation-to-Crosstalk Ratio, - Alien Crosstalk bei entsprechenden Prüfungen. > Ein einfacher Kabeltester ersetzt keinen normgerechten Kabelzertifizierer. --- **6. Kabelzertifizierer** Ein Kabelzertifizierer wird verwendet, wenn nachgewiesen werden muss, ob eine installierte Verkabelung eine bestimmte Kategorie, Klasse oder Anwendung erfüllt. Vor der Messung müssen festgelegt werden: - Kupfer- oder Glasfasermessung, - Verkabelungsstandard, - Kabelkategorie, - Permanent Link oder Channel, - verwendete Adapter, - erwartete NVP, - geschirmte oder ungeschirmte Verkabelung, - Grenzwert, - Anschlussbezeichnung, - Messrichtung, - Kalibrierungsstatus des Geräts. **Permanent Link und Channel** | Messaufbau | umfasst typischerweise | |---|---| | Permanent Link | fest installierte Verkabelung zwischen den Anschlussstellen | | Channel | gesamte Übertragungsstrecke einschließlich Patchkabeln und Steckverbindungen | Die Messergebnisse verschiedener Aufbauten dürfen nicht ohne Berücksichtigung der verwendeten Adapter und Grenzwerte miteinander verglichen werden. **Bei einem fehlgeschlagenen Test dokumentieren** - betroffene Leitung, - verwendeter Standard, - Messaufbau, - fehlgeschlagener Einzelwert, - Grenzwert, - Abstand zum Grenzwert, - Fehlerentfernung, - Messrichtung, - verwendete Adapter, - Datum der letzten Kalibrierung, - gespeicherten Messbericht. **Typische Ursachen eines nicht bestandenen Zertifizierungstests** - schlechte Auflegung, - zu weit aufgedrehte Adernpaare, - ungeeignete Anschlussmodule, - beschädigtes Kabel, - zu große Kabellänge, - ungeeignete Patchkabel, - schlechte Schirmung oder Erdung, - falsche Messadapter, - falscher Messstandard, - Störungen durch benachbarte Leitungen, - ungeeignete Kombination verschiedener Komponenten. --- **7. TDR für Kupferleitungen** Ein Time Domain Reflectometer sendet einen Impuls in eine Leitung und wertet Reflexionen aus. Dadurch können Änderungen der elektrischen Eigenschaften entlang eines Kabels lokalisiert werden. Ein TDR kann je nach Gerät Hinweise liefern auf: - Leitungsende, - Unterbrechung, - Kurzschluss, - Beschädigung, - schlechte Verbindung, - Impedanzänderung, - Abzweigung, - ungefähre Entfernung zur Fehlerstelle. **Vereinfachtes Prinzip** ```text Messgerät → elektrischer Impuls → Ausbreitung im Kabel → Reflexion an einer Störstelle → Berechnung der Entfernung aus der Laufzeit ``` Die Entfernungsberechnung hängt von der Ausbreitungsgeschwindigkeit des Kabels ab. Häufig wird dafür der NVP-Wert verwendet. **NVP** NVP steht für Nominal Velocity of Propagation und beschreibt die Signalausbreitung im Verhältnis zur Lichtgeschwindigkeit. Ein falscher NVP-Wert führt zu einer falschen Entfernungsangabe. **Einordnung typischer Reflexionen** | Beobachtung | mögliche Ursache | |---|---| | starke Reflexion am Leitungsende | offenes Ende oder Abschluss | | starke Reflexion vor erwartetem Ende | Unterbrechung oder beschädigte Verbindung | | Reflexion mit entgegengesetzter Charakteristik | Kurzschluss oder starke Impedanzänderung | | mehrere Reflexionen | mehrere Steckstellen, Abzweigungen oder Beschädigungen | | unplausible Entfernung | falscher NVP, falscher Kabeltyp oder komplexer Leitungsweg | > Ein TDR lokalisiert eine elektrische Auffälligkeit. Es zeigt nicht automatisch, welches Bauteil dort tatsächlich beschädigt ist. --- **8. Tongenerator und Leitungssucher** Ein Tongenerator speist ein Suchsignal in eine Leitung ein. Ein Leitungssucher beziehungsweise eine induktive Prüfsonde hilft, dieses Signal an Kabeln, Patchfeldern oder Anschlussdosen zu erkennen. Geeignet für: - unbekannte Kabelwege, - nicht dokumentierte Anschlussdosen, - Zuordnung zwischen Dose und Patchfeld, - Identifikation einzelner Leitungen in einem Bündel, - grundlegende Durchgangsprüfung bei geeigneten Geräten. **Sichere Vorgehensweise** 1. Leitung eindeutig bestimmen. 2. prüfen, ob sie aktiv ist oder Spannung führt. 3. Gerätespezifikation beachten. 4. Tongenerator passend anschließen. 5. Signal am vermuteten Leitungsweg verfolgen. 6. mehrere mögliche Leitungen vergleichen. 7. Leitung anschließend eindeutig beschriften. 8. Dokumentation aktualisieren. **Grenzen** - Nebensprechen kann das Signal auf benachbarte Kabel übertragen. - ein starkes Signal beweist nicht immer die exakte Leitung. - abgeschirmte Kabel können die Ortung beeinflussen. - aktive Netzwerkverbindungen benötigen dafür geeignete Geräte. - unbekannte elektrische Leitungen dürfen nicht ungeprüft angeschlossen werden. - der Tongenerator bestätigt keine Ethernet-Leistungsfähigkeit. --- **9. Port- und Leitungslokalisierung über Link Blink** Einige Netzwerkprüfgeräte können den Link am Switchport gezielt auf- und abbauen oder ein Blinkmuster erzeugen. Damit kann ein Administrator einen physischen Port identifizieren, ohne ausschließlich den Leitungsweg mit einem Tongenerator zu verfolgen. **Zu beachten** - Das Blinkmuster muss von einer zweiten Person oder Kamera am Switch beobachtet werden. - Ein produktiver Link kann dabei kurzzeitig unterbrochen werden. - Bei Link Aggregation, redundanten Pfaden oder Telefonen mit nachgeschaltetem PC können Nebenwirkungen entstehen. - Link Blink beweist lediglich die Zuordnung zum Port, nicht die Fehlerfreiheit des Kabels. - Switchport-Beschreibung, MAC-Tabelle und LLDP sollten zusätzlich geprüft werden. --- **10. Loopback-Stecker** Ein Loopback-Stecker führt Sende- und Empfangssignale an einer Schnittstelle kontrolliert zurück. Mögliche Varianten existieren unter anderem für: - Ethernet, - serielle Schnittstellen, - Glasfaser, - USB, - herstellerspezifische Diagnoseanschlüsse. **Mögliche Einsatzzwecke** - Schnittstelle lokal prüfen, - Sende- und Empfangspfad testen, - Diagnosefunktion eines Geräts ausführen, - Port von Kabelweg und Gegenstelle trennen, - Transceiver oder Adapter untersuchen. **Risiken** - Ein ungeeigneter Loopback-Stecker kann eine Schnittstelle beschädigen. - Eine Netzwerkschleife kann entstehen. - Spanning Tree kann reagieren. - ein Port kann durch Schutzmechanismen deaktiviert werden. - reflektierter Verkehr kann CPU- oder Netzlast erzeugen. - optische Loopbacks müssen zum Fasertyp, Anschluss und Leistungsbereich passen. > Loopback-Stecker dürfen nur nach Herstelleranleitung und mit eindeutiger Zuordnung verwendet werden. --- **11. Vergleichshardware** Vergleichshardware hilft dabei, einen Fehler auf Gerät, Adapter, Kabel, Port oder Konfiguration einzugrenzen. Geeignet sind beispielsweise: - geprüfter USB-Netzwerkadapter, - geprüfter USB-Hub, - geprüfter SFP- oder SFP+-Transceiver, - geprüfter Medienkonverter, - geprüfter PoE-Injektor, - geprüfter Access Point, - geprüfter Switch, - geprüfter Laptop, - geprüftes Netzteil, - geprüfter Konsolenadapter. **Kontrollierter Vergleich** 1. nur eine Komponente verändern, 2. kompatible Vergleichshardware verwenden, 3. Versions- und Treiberunterschiede dokumentieren, 4. identische Verbindung erneut testen, 5. Ergebnis mit dem Ausgangszustand vergleichen, 6. ursprüngliche Komponente separat untersuchen. **Fehlinterpretationen vermeiden** | Ergebnis | Einordnung | |---|---| | anderer Adapter funktioniert | ursprünglicher Adapter, Treiber oder dessen Kompatibilität ist verdächtig | | anderer Laptop funktioniert | Fehler kann am ersten Client liegen, muss aber nicht ausschließlich Hardware sein | | anderer Port funktioniert | ursprünglicher Port oder dessen Konfiguration ist verdächtig | | anderer Transceiver funktioniert | ursprünglicher Transceiver oder dessen Kompatibilität ist verdächtig | | Ersatznetzteil funktioniert | ursprüngliches Netzteil oder dessen Leistungsabgabe ist verdächtig | --- **12. PoE-Tester** Ein PoE-Tester untersucht Power over Ethernet zwischen Power Sourcing Equipment und Powered Device. **Begriffe** | Begriff | Bedeutung | |---|---| | PSE | stellt PoE-Leistung bereit, beispielsweise Switch oder Injektor | | PD | empfängt PoE-Leistung, beispielsweise Access Point, Kamera oder Telefon | | Endspan | PoE wird direkt durch den Switch bereitgestellt | | Midspan | PoE wird durch einen zwischengeschalteten Injektor bereitgestellt | | PoE-Klasse | handelt beziehungsweise beschreibt den Leistungsbedarf | | PoE-Budget | insgesamt verfügbare Leistung eines Switches | Je nach Messgerät können untersucht werden: - ob PoE vorhanden ist, - verwendetes Adernpaar, - Spannung, - Klasse, - angeforderte Leistung, - verfügbare Leistung, - Leistungsabgabe unter Last, - Erkennung des PSE, - Ethernet-Link, - Switch- und VLAN-Informationen. **Typische PoE-Probleme** - PoE auf dem Port deaktiviert, - Gesamtbudget des Switches erschöpft, - falsche oder nicht unterstützte PoE-Klasse, - hohe Leitungswiderstände, - Widerstandsunsymmetrie, - beschädigte Adernpaare, - schlechte Auflegung, - zu lange oder ungeeignete Verkabelung, - inkompatibler passiver PoE-Injektor, - nur bestimmte Ports unterstützen PoE, - Gerät benötigt mehr Leistung als verfügbar, - Leistung bricht erst unter Last zusammen, - Port wurde durch Schutzmechanismus abgeschaltet. **PoE-Prüfreihenfolge** 1. Leistungsanforderung des Endgeräts bestimmen. 2. unterstützten PoE-Standard des Switches prüfen. 3. PoE-Konfiguration und Gesamtbudget kontrollieren. 4. Messung direkt am Switchport durchführen. 5. Messung an der entfernten Netzwerkdose durchführen. 6. Spannungs- und Leistungsunterschied vergleichen. 7. Kabel auf Wiremap und Widerstandsprobleme prüfen. 8. Endgerät mit geprüftem Kabel und geeignetem PSE testen. 9. Ereignisprotokolle und Portstatus untersuchen. > Eine Leerlaufspannung bestätigt nicht, dass unter realer Last ausreichend Leistung zur Verfügung steht. --- **13. Passive PoE-Verbindungen** Passives PoE verwendet möglicherweise dauerhaft anliegende Spannung ohne standardisierte Aushandlung. Risiken sind: - Beschädigung nicht geeigneter Geräte, - falsche Spannung, - falsche Polarität, - falsche Pinbelegung, - Verwechslung mit standardisiertem IEEE-PoE, - fehlende Schutzmechanismen. Vor dem Anschließen müssen geprüft werden: - Herstellerdokumentation, - Spannung, - Polarität, - Pinbelegung, - maximaler Strom, - Kompatibilität des Endgeräts, - Eignung des Messgeräts. > Passives PoE darf nicht allein anhand eines identischen RJ45-Steckers als kompatibel betrachtet werden. --- **14. Multimeter** Ein Multimeter kann abhängig von Gerät, Messleitungen und Qualifikation unter anderem messen: - Spannung, - Strom, - Widerstand, - Durchgang, - teilweise Frequenz, - teilweise Kapazität. Mögliche IT-nahe Einsatzbereiche sind: - Prüfung eines geeigneten Kleinspannungsnetzteils, - Kontrolle dokumentierter Gleichspannungen, - Durchgangsprüfung an spannungsfreien Leitungen, - Untersuchung einer vorgesehenen Erdungs- oder Schirmverbindung, - Vergleich einer gemessenen Ausgangsspannung mit der Herstellerangabe. **Gefahren** - falscher Messbereich, - Messleitung in falscher Buchse, - Strommessung parallel zur Spannungsquelle, - Messung an Netzspannung ohne Qualifikation, - ungeeignete Messkategorie, - beschädigte Messleitungen, - Kurzschluss durch Prüfspitzen, - Messung an unbekannten Stromkreisen, - unzulässige Öffnung von Geräten oder Netzteilen. **Verbindliche Begrenzung** Multimeter dürfen nur durch dafür qualifizierte Personen, mit geeignetem Messgerät und innerhalb des zulässigen Einsatzbereichs verwendet werden. > Ein IT-Administrator sollte keine Arbeiten an Netzspannung, Stromverteilungen oder geöffneten Netzteilen durchführen, wenn dafür die elektrotechnische Qualifikation und Freigabe fehlen. --- **15. Netzteil- und Stromversorgungsprüfung** Viele scheinbare Netzwerk- oder Gerätefehler entstehen durch die Stromversorgung. Zu prüfen sind: - sitzt der Netzstecker vollständig? - ist die Steckdosenleiste eingeschaltet? - zeigt die USV einen Alarm? - ist das richtige Netzteil angeschlossen? - stimmen Ausgangsspannung, Strombelastbarkeit und Polarität? - ist das Netzteil ungewöhnlich warm? - treten Neustarts nur unter Last auf? - funktionieren redundante Netzteile? - sind beide Netzteile tatsächlich an getrennte Strompfade angeschlossen? - bestehen Ereignisse zu Unterspannung oder Stromverlust? - ist der PoE-Port ausreichend dimensioniert? - sind Sicherungen oder Schutzschalter ausgelöst? **Typische Fehlerbilder** | Beobachtung | mögliche Ursache | |---|---| | Gerät startet wiederholt neu | instabiles Netzteil, Überlast, Temperatur oder Hardwarefehler | | Gerät funktioniert ohne Zusatzmodule | Netzteil zu schwach oder defektes Modul | | redundante Netzteile angezeigt, aber nur ein Stromkreis | keine vollständige Stromredundanz | | Fehler nur bei hoher Last | Spannungseinbruch, Leistungsgrenze oder Kühlungsproblem | | USV meldet Batteriebetrieb | Stromversorgung vor der USV oder Netzqualität prüfen | | Gerät bleibt nach Stromausfall aus | Startverhalten, Netzteil, USV oder Hardwarezustand | --- **16. Glasfaser-Grundlagen für die Messung** Vor einer Glasfasermessung müssen bekannt sein: - Singlemode oder Multimode, - Faserkategorie, - Wellenlänge, - Steckertyp, - Schliffart, - Sendeleistung, - zulässiger Empfangsbereich, - Linkbudget, - Anzahl der Steckverbindungen, - Anzahl der Spleiße, - Streckenlänge, - erwartete Dämpfung, - verwendete Transceiver. **Häufige Steckertypen** - LC, - SC, - ST, - MPO beziehungsweise MTP. **Wichtige Unterscheidungen** - Singlemode und Multimode dürfen nicht beliebig kombiniert werden. - UPC- und APC-Schliffe dürfen nicht direkt miteinander verbunden werden. - unterschiedliche Wellenlängen führen zu unterschiedlichen Messwerten. - optische Pegel werden häufig in dBm angegeben. - Verlust beziehungsweise Dämpfung wird häufig in dB angegeben. **dBm und dB** | Einheit | Bedeutung | |---|---| | dBm | absoluter optischer Leistungspegel bezogen auf 1 mW | | dB | Verhältnis beziehungsweise Verlust zwischen zwei Pegeln | > Ein Wert von `-10 dBm` ist kein Verlust von `-10 dB`. Absoluter Pegel und Streckendämpfung müssen getrennt behandelt werden. --- **17. Glasfaser inspizieren und reinigen** Verschmutzte Steckerendflächen gehören zu den häufigsten Ursachen optischer Probleme. Mögliche Verunreinigungen sind: - Staub, - Hautfett, - Reinigungsrückstände, - Abrieb, - Feuchtigkeit, - Schmutz aus Schutzkappen. **Grundregel** ```text inspizieren → bei Bedarf reinigen → erneut inspizieren → erst danach verbinden ``` Benötigte Werkzeuge können sein: - geeignetes Glasfaser-Inspektionsmikroskop, - Videosonde, - passende Adapterspitzen, - fusselfreie Reinigungstücher, - geeignete Reinigungsflüssigkeit, - One-Click-Reiniger, - Reinigungswerkzeuge für MPO/MTP, - saubere Schutzkappen. **Wichtige Regeln** - niemals in eine aktive Glasfaser blicken, - vor der Inspektion Aktivität beziehungsweise Laserquelle sicher berücksichtigen, - keine ungeeigneten Haushaltsreiniger verwenden, - Stecker nicht mit Kleidung oder Fingern reinigen, - gereinigte Endflächen nicht berühren, - auch werksseitig konfektionierte Stecker vor dem Verbinden prüfen, - Adapter und Messleitungen ebenfalls kontrollieren, - verschmutzte Schutzkappen nicht wiederverwenden. > Eine verschmutzte Endfläche kann nicht nur die Messung verfälschen, sondern beim Verbinden auch die Gegenseite verschmutzen oder beschädigen. --- **18. Visual Fault Locator** Ein Visual Fault Locator speist sichtbares rotes Licht in eine Glasfaser ein. Er kann helfen bei: - Identifikation einer Faser, - Polaritätsprüfung, - Erkennung grober Unterbrechungen, - Auffinden starker Biegungen, - Erkennung schlechter Steckverbindungen, - Untersuchung kurzer Leitungsabschnitte. **Grenzen** - nicht jede Beschädigung wird sichtbar, - lange Strecken können das sichtbare Licht stark dämpfen, - Kabelummantelung kann austretendes Licht verdecken, - ein sichtbarer Lichtaustritt lokalisiert nicht automatisch die genaue Fehlerursache, - ein VFL ersetzt keine Dämpfungsmessung, - ein VFL ersetzt kein OTDR, - Laserklassifizierung und Sicherheitsregeln müssen beachtet werden. --- **19. Optischer Leistungsmesser** Ein optischer Leistungsmesser misst den empfangenen optischen Pegel. Vor der Messung müssen bekannt sein: - Wellenlänge, - zulässiger Empfangsbereich, - verwendeter Anschlussadapter, - erwarteter Sendepegel, - Empfindlichkeit und Übersteuerungsgrenze des Empfängers, - Referenzwert, - Fasertyp. **Mögliche Ergebnisse** | Messwert | Einordnung | |---|---| | innerhalb des zulässigen Bereichs | Pegel ist grundsätzlich geeignet | | unterhalb der Empfindlichkeitsgrenze | Signal zu schwach | | oberhalb der Übersteuerungsgrenze | Signal zu stark | | stark schwankender Pegel | instabile Quelle, Stecker, Faser oder Bewegung | | kein Pegel | falsche Faser, Sender aus, Unterbrechung oder falsche Wellenlänge | | Pegel ausreichend, Link bleibt down | Ursache kann Transceiver, Protokoll, Geschwindigkeit oder Gegenstelle sein | **Typische Ursachen für zu geringe Leistung** - verschmutzte Endfläche, - beschädigtes Patchkabel, - zu viele Steckverbindungen, - ungeeigneter Spleiß, - Makro- oder Mikrobiegung, - falsche Faser, - falscher Transceiver, - zu große Streckenlänge, - schwache Sendeleistung, - ungeeignete Wellenlänge. --- **20. Optical Loss Test Set** Ein Optical Loss Test Set besteht typischerweise aus Lichtquelle und Leistungsmesser. Es bestimmt die Einfügedämpfung einer Glasfaserstrecke. **Vereinfachtes Verfahren** ```text Referenzmessung → Messleitungen und Lichtquelle referenzieren → zu prüfende Strecke einfügen → empfangenen Pegel messen → Verlust bestimmen → mit Grenzwert vergleichen ``` Vorher festzulegen sind: - Fasertyp, - Wellenlänge, - Referenzmethode, - Anzahl der Test-Referenzkabel, - Steckertyp, - Messrichtung, - Grenzwert, - erwartete Linkdämpfung. **Fehlerquellen bei der Messung** - verschmutzte Referenzkabel, - beschädigte Messadapter, - falsche Referenzmethode, - Bewegung der Testleitungen, - falsche Wellenlänge, - unterschiedliche Steckerschliffe, - nicht stabilisierte Lichtquelle, - falscher Nullabgleich, - vertauschte Polarität, - unterschiedliche Messaufbauten. > Eine Messung ist nur dann vergleichbar, wenn Referenzmethode, Wellenlänge, Messleitungen und Grenzwerte dokumentiert wurden. --- **21. OTDR für Glasfaser** Ein Optical Time Domain Reflectometer sendet optische Impulse in eine Faser und wertet das zurückgestreute beziehungsweise reflektierte Licht über die Zeit aus. Ein OTDR kann je nach Gerät darstellen: - Faserlänge, - Steckverbindungen, - Spleiße, - Reflexionsereignisse, - nicht reflektierende Ereignisse, - Dämpfung einzelner Abschnitte, - Gesamtdämpfung, - Unterbrechung, - ungefähre Entfernung zur Fehlerstelle. **Vereinfachte Darstellung** ```text OTDR → optischer Impuls → Rückstreuung entlang der Faser → Reflexionen an Ereignissen → Ereignistabelle und Kurve ``` **Launch- und Receive-Faser** Eine Vorlauffaser kann erforderlich sein, um: - den ersten Anschluss außerhalb der Totzone zu messen, - den Eingangsstecker zu beurteilen, - einen realistischen Leitungsanfang darzustellen. Eine Nachlauffaser kann erforderlich sein, um: - den letzten Anschluss zu beurteilen, - das Ende der Strecke korrekt auszuwerten. **Wichtige OTDR-Einstellungen** - Wellenlänge, - Messbereich, - Pulsbreite, - Messdauer, - Brechungsindex, - Rückstreukoeffizient, - Ereignisschwelle, - Fasertyp. **Einfluss der Pulsbreite** | Einstellung | Vorteil | Nachteil | |---|---|---| | kurze Pulsbreite | bessere Auflösung nahe beieinanderliegender Ereignisse | geringere Reichweite und schwächeres Signal | | lange Pulsbreite | größere Reichweite und besserer Dynamikbereich | größere Totzonen und geringere Ereignisauflösung | **Grenzen** - nahe Ereignisse können in einer Totzone liegen, - Reflexionen können Geisterereignisse erzeugen, - falsche Einstellungen führen zu falscher Entfernung oder Dämpfung, - bidirektionale Messungen können für belastbare Bewertung erforderlich sein, - ein OTDR ersetzt nicht automatisch eine normgerechte Einfügedämpfungsmessung, - Bedienung und Kurveninterpretation erfordern Fachkenntnisse. --- **22. SFP- und Transceiver-Diagnose** Viele Transceiver unterstützen Digital Optical Monitoring beziehungsweise Digital Diagnostic Monitoring. Mögliche Werte sind: - Temperatur, - Versorgungsspannung, - Sendeleistung, - Empfangsleistung, - Laser-Bias-Strom, - Warn- und Alarmgrenzen. **Beispielhafte Einordnung** | Beobachtung | mögliche Ursache | |---|---| | Empfangsleistung zu niedrig | Dämpfung, Verschmutzung, falsche Faser oder schwacher Sender | | Empfangsleistung zu hoch | ungeeigneter Transceiver oder fehlendes Dämpfungsglied | | Sendeleistung außerhalb der Grenze | Transceiverfehler oder Temperaturproblem | | hohe Temperatur | unzureichende Kühlung, hoher Umgebungswert oder Modulproblem | | Werte nur auf einer Seite auffällig | Richtung der Faserstrecke gezielt untersuchen | | keine Diagnosedaten | Modul unterstützt DDM nicht oder Gerät liest es nicht aus | **Zusätzlich prüfen** - unterstützter Transceivertyp, - Herstellerkompatibilität, - Geschwindigkeit, - Wellenlänge, - Singlemode oder Multimode, - Duplex- oder BiDi-Verfahren, - Faserpolarität, - Steckertyp, - Gegenstellenmodul, - Fehlerzähler, - Forward Error Correction, - verwendete Breakout-Konfiguration. > Optische Diagnosedaten des Transceivers sind hilfreich, ersetzen aber keine unabhängige Messung bei unklaren oder widersprüchlichen Ergebnissen. --- **23. WLAN-Spektrumanalysator** Ein WLAN-Scanner zeigt hauptsächlich WLAN-Netze und deren Protokollinformationen. Ein Spektrumanalysator untersucht dagegen die Hochfrequenzenergie im verwendeten Frequenzbereich und kann auch nicht WLAN-basierte Störquellen sichtbar machen. **Mögliche Untersuchungen** - Kanalbelegung, - Kanalnutzung, - Störpegel, - dauerhafte oder periodische Signale, - Interferenzen, - überlappende Kanäle, - nicht WLAN-basierte Sender, - zeitlicher Verlauf, - Nutzung der Frequenzbänder 2,4 GHz, 5 GHz oder 6 GHz abhängig vom Gerät. **Mögliche Störquellen** - andere WLAN-Netze, - Bluetooth, - Funkkameras, - drahtlose Videoübertragung, - Mikrowellengeräte, - fehlerhafte elektrische Geräte, - bestimmte Sensoren, - Radarerkennung im 5-GHz-Bereich, - breitbandige Störsender. **Messparameter** - Frequenz, - Kanal, - Signalstärke, - Rauschpegel, - Kanalnutzung, - Duty Cycle, - zeitliches Auftreten, - Signalbreite, - räumliche Veränderung. **Vorgehensweise** 1. betroffenen Ort bestimmen. 2. Zeitpunkt und Symptom dokumentieren. 3. Messung am betroffenen Clientstandort durchführen. 4. Vergleichsmessung an einem funktionierenden Standort durchführen. 5. zeitlichen Verlauf beobachten. 6. Störquelle durch räumliche Messungen eingrenzen. 7. WLAN-Konfiguration und Spektrummessung gemeinsam auswerten. 8. Änderung kontrolliert testen. 9. erneut messen. > Eine hohe WLAN-Signalstärke bestätigt keine geringe Interferenz und keine gute Signalqualität. --- **24. WLAN-Site-Survey-Werkzeuge** Ein Site Survey untersucht die räumliche WLAN-Versorgung. Mögliche Ergebnisse sind: - Signalstärke, - Signal-Rausch-Abstand, - Kanalnutzung, - Access-Point-Zuordnung, - Datenrate, - Überlappung, - Roamingbereiche, - Störquellen, - erwartete Abdeckung, - tatsächliche Abdeckung. **Arten** | Art | Beschreibung | |---|---| | Predictive Survey | rechnerische Planung anhand von Gebäude- und Materialdaten | | Passive Survey | Empfang und Auswertung vorhandener Funksignale | | Active Survey | aktive Verbindung und Messung von Netzwerkleistung | | Spectrum Survey | Untersuchung der Funkenergie einschließlich nicht WLAN-basierter Quellen | **Zu beachten** - Grundriss und Maßstab müssen stimmen. - Wandmaterialien beeinflussen das Ergebnis. - Möbel, Personen und Türen verändern Funkbedingungen. - Messgerät und Antennenausrichtung beeinflussen Messwerte. - verschiedene Clienttypen besitzen unterschiedliche Funkfähigkeiten. - eine leere Umgebung kann andere Ergebnisse liefern als der spätere Produktivbetrieb. - Messungen müssen für relevante Frequenzbänder getrennt betrachtet werden. --- **25. Temperaturmessung und Wärmebildkamera** Temperaturprobleme können zu instabilen Geräten, Leistungseinbrüchen und vorzeitigem Hardwareausfall führen. Mögliche Werkzeuge sind: - interne Temperatursensoren, - Kontaktthermometer, - Infrarotthermometer, - Wärmebildkamera, - Umgebungssensoren, - Sensoren im Rack oder Rechenzentrum. **Zu prüfen sind** - Lufteinlass- und Auslasstemperatur, - blockierte Lüftungswege, - ausgefallene Lüfter, - falsche Luftstromrichtung, - Hotspots, - ungewöhnlich warme Netzteile, - überhitzte Transceiver, - Rackposition, - Umgebungstemperatur, - Staubbelastung, - Veränderungen unter Last. **Grenzen von Infrarotmessungen** - reflektierende Oberflächen können Messwerte verfälschen, - Emissionsgrad beeinflusst das Ergebnis, - Entfernung und Messfleckgröße müssen berücksichtigt werden, - eine Oberflächentemperatur entspricht nicht automatisch der internen Bauteiltemperatur, - Vergleichswerte sollten unter ähnlichen Bedingungen erhoben werden. --- **26. Serielle Konsole** Eine serielle Konsole ermöglicht lokalen Zugriff, wenn das normale Managementnetz nicht funktioniert. Mögliche Anschlüsse sind: - RJ45-Konsole, - USB-Konsole, - USB-C-Konsole, - RS-232, - herstellerspezifische Konsolenschnittstelle. Benötigt werden gegebenenfalls: - passendes Konsolenkabel, - USB-Seriell-Adapter, - geeigneter Treiber, - Terminalprogramm, - korrekte Übertragungsparameter. **Typische Parameter** ```text Geschwindigkeit: 9600 oder herstellerspezifisch Datenbits: 8 Parität: keine Stoppbits: 1 Flusssteuerung: keine ``` Die konkreten Werte müssen der Herstellerdokumentation entnommen werden. **Mögliche Diagnoseinformationen** - Bootmeldungen, - Hardwarefehler, - Dateisystemfehler, - fehlgeschlagene Module, - Konfigurationsprobleme, - Management-IP, - Recovery-Menü, - Firmwarestatus. **Sicherheitsregeln** - Konsolenzugriff ist privilegierter Zugriff. - Konsolenkabel und Terminalserver müssen geschützt werden. - Bootmeldungen können vertrauliche Informationen enthalten. - Kennwortwiederherstellung kann Konfiguration oder Verfügbarkeit beeinflussen. - Recovery-Verfahren dürfen nur mit Freigabe durchgeführt werden. --- **27. Out-of-Band-Management** Out-of-Band-Management verwendet einen vom normalen Datenpfad getrennten Managementweg. Beispiele sind: - Konsolenserver, - dediziertes Managementnetz, - Mobilfunkverbindung für Notfallzugriff, - HPE iLO, - Dell iDRAC, - IPMI-basierte Managementcontroller, - Cisco CIMC, - KVM over IP. **Mögliche Funktionen** - Hardwarezustand anzeigen, - Sensoren und Ereignisprotokolle prüfen, - Remote-Konsole öffnen, - Startvorgang beobachten, - Gerät kontrolliert ein- oder ausschalten, - virtuelle Medien bereitstellen, - Firmware verwalten, - ausgefallenes Betriebssystem unabhängig untersuchen. **Sicherheitsanforderungen** - getrenntes Managementnetz, - Zugriff nur für berechtigte Administratoren, - Mehrfaktor-Authentifizierung, sofern unterstützt, - aktuelle Firmware, - keine direkte öffentliche Erreichbarkeit, - sichere Protokolle, - zentrale Protokollierung, - individuelle Konten, - eingeschränkte Firewallregeln, - Notfallzugriff dokumentieren und testen, - Standardkennwörter entfernen, - Zertifikate prüfen. > Out-of-Band-Management ist kein gewöhnliches Messgerät, aber ein unabhängiger Diagnoseweg zur physischen Hardware und zum Startvorgang. --- **28. In-Band und Out-of-Band unterscheiden** | Merkmal | In-Band-Management | Out-of-Band-Management | |---|---|---| | Datenpfad | nutzt reguläres Netzwerk | nutzt separaten Managementweg | | Abhängigkeit vom Betriebssystem | häufig vorhanden | häufig geringer oder keine | | Zugriff bei Routingfehler | möglicherweise nicht möglich | bei funktionsfähigem OOB-Pfad weiterhin möglich | | Zugriff während des Bootens | meist eingeschränkt | häufig möglich | | Risiko | Ausfall des Produktivnetzes blockiert Zugriff | separater Weg muss besonders geschützt werden | | Beispiele | SSH, HTTPS, SNMP | Konsole, iLO, iDRAC, CIMC, IPMI, Konsolenserver | Eine physisch vorhandene Managementbuchse bestätigt nicht automatisch, dass ein vollständig unabhängiger Out-of-Band-Pfad aufgebaut wurde. --- **29. Messgerät selbst überprüfen** Auch ein Messgerät kann fehlerhaft sein. Vor wichtigen Messungen prüfen: - Akkustand, - Netzteil, - Firmwarestand, - Selbsttest, - Kalibrierungsdatum, - Messadapter, - Messleitungen, - Steckverbinder, - Referenzkabel, - richtige Geräteeinstellung, - richtige Wellenlänge, - richtiger Kabeltyp, - richtiger Grenzwert, - Datum und Uhrzeit, - Speicherplatz, - gespeicherte Kunden- oder Projektdaten. **Kontrollmessung** Eine Kontrollmessung an einer bekannten, funktionierenden Referenz hilft dabei, Fehler des Messaufbaus zu erkennen. > Wenn ein unerwartetes Ergebnis große Folgen hätte, sollte es mit einer zweiten Messung, einem anderen Messaufbau oder einem unabhängigen Messgerät bestätigt werden. --- **30. Kalibrierung und Rückführbarkeit** Bei Zertifizierungs- und Abnahmemessungen ist die Kalibrierung besonders wichtig. Zu dokumentieren sind: - Hersteller und Modell, - Seriennummer, - Firmwareversion, - Kalibrierungsdatum, - nächster Kalibrierungstermin, - verwendete Adapter, - verwendete Referenzleitungen, - Prüfstandard, - Messperson, - Datum und Uhrzeit, - Messort. Eine abgelaufene Kalibrierung bedeutet nicht zwangsläufig, dass jeder Messwert falsch ist. Sie kann jedoch die Nachweisbarkeit und Verwendbarkeit der Messergebnisse beeinträchtigen. --- **31. Messergebnisse dokumentieren** Eine Messung sollte mindestens folgende Angaben enthalten: | Feld | Inhalt | |---|---| | Ticket oder Vorgang | eindeutige Referenz | | Datum und Uhrzeit | Zeitpunkt der Messung | | Messperson | verantwortliche Person | | Standort | Gebäude, Raum, Rack oder Anschluss | | Verbindung | Start- und Endpunkt | | Gerät | Hersteller, Modell und Seriennummer | | Messgerät | Hersteller, Modell und Seriennummer | | Kalibrierung | gültig bis beziehungsweise Status | | Messaufbau | Permanent Link, Channel, direkt am Port oder anderer Aufbau | | Einstellung | Standard, Wellenlänge, NVP, Pulsbreite oder Messbereich | | Ausgangszustand | ursprüngliches Symptom | | Messwert | tatsächliches Ergebnis | | Grenzwert | erwarteter beziehungsweise zulässiger Wert | | Maßnahme | kontrollierte Änderung | | Nachmessung | Ergebnis nach der Maßnahme | | Anhänge | Fotos, Kurven, Berichte oder Exportdateien | **Beispiel** ```text Verbindung: Patchfeld A-17 → Datendose B-204 Symptom: Link fällt mehrmals pro Stunde auf 100 Mbit/s zurück Messgerät: Kabelzertifizierer, Seriennummer dokumentiert Messaufbau: Permanent Link Grenzwert: Cat 6A Ergebnis: nicht bestanden Auffälligkeit: NEXT am nahen Anschluss Fehlerentfernung: innerhalb des Anschlussbereichs Maßnahme: Anschluss neu aufgelegt Nachmessung: bestanden Funktionstest: stabiler 1-Gbit/s-Link, Fehlerzähler steigen nicht weiter ``` --- **32. Messwerte richtig vergleichen** Vergleichsmessungen sind nur sinnvoll, wenn die Bedingungen vergleichbar sind. Zu berücksichtigen sind: - identischer Messpunkt, - identisches Messgerät, - identische Adapter, - identische Geräteeinstellung, - identische Wellenlänge, - identischer Kabeltyp, - gleiche Messrichtung, - ähnliche Temperatur, - gleicher Betriebszustand, - gleiche Last, - gleicher Zeitraum, - gleiche Referenzmethode. **Ungültige Vergleiche** - dBm und dB direkt gleichsetzen, - OTDR-Dämpfung ohne Kontext mit OLTS-Messung vergleichen, - Permanent-Link-Messung mit Channel-Messung gleichsetzen, - PoE-Leerlaufwert mit Leistung unter Last gleichsetzen, - WLAN-Messungen an verschiedenen Standorten ohne Positionsangabe vergleichen, - Messwerte verschiedener Wellenlängen gleichsetzen, - Kabellängen mit falschem NVP vergleichen. --- **33. Kontrollierte Prüfreihenfolge bei Kupferproblemen** 1. Symptom und betroffene Verbindung bestimmen. 2. Portstatus und Fehlerzähler dokumentieren. 3. sichtbare Schäden prüfen. 4. Steckverbindungen kontrollieren. 5. geprüftes Patchkabel verwenden. 6. Gegenstelle mit Vergleichshardware testen. 7. Wiremap und Kabellänge prüfen. 8. Fehlerentfernung mit TDR untersuchen. 9. bei Leistungsanforderungen qualifizieren oder zertifizieren. 10. PoE gegebenenfalls unter Last messen. 11. Anschlussstellen und Patchfeld untersuchen. 12. nach jeder Maßnahme erneut messen. 13. Konfiguration und physische Messung gemeinsam bewerten. 14. Ursache und Ergebnis dokumentieren. --- **34. Kontrollierte Prüfreihenfolge bei Glasfaserproblemen** 1. Fasertyp, Wellenlänge und Transceiver bestimmen. 2. Portstatus und optische Diagnosedaten dokumentieren. 3. richtige Polarität prüfen. 4. Endflächen sicher inspizieren. 5. bei Bedarf reinigen und erneut inspizieren. 6. geprüftes Patchkabel einsetzen. 7. sichtbare Fehlersuche nur mit geeignetem VFL durchführen. 8. optischen Empfangspegel messen. 9. Streckendämpfung mit geeigneter Lichtquelle und Leistungsmesser bestimmen. 10. Ereignisse und Fehlerentfernung bei Bedarf mit OTDR untersuchen. 11. Messung gegebenenfalls in Gegenrichtung wiederholen. 12. Ergebnis mit Linkbudget und Grenzwerten vergleichen. 13. nach jeder Maßnahme erneut messen. 14. Messkurven und Berichte sichern. --- **35. Praxisbeispiel: Link fällt auf 100 Mbit/s zurück** **Symptom** Ein Gigabit-Endgerät verbindet sich nur mit 100 Mbit/s oder wechselt wiederholt zwischen Geschwindigkeiten. **Prüfung** 1. unterstützte Geschwindigkeiten beider Geräte prüfen. 2. Auto-Negotiation auf beiden Seiten kontrollieren. 3. Portstatus und Fehlerzähler dokumentieren. 4. geprüftes Patchkabel einsetzen. 5. alle vier Adernpaare mit Kabeltester prüfen. 6. feste Gebäudeverkabelung untersuchen. 7. Split Pair, Unterbrechung oder schlechte Auflegung prüfen. 8. Verbindung bei Bedarf qualifizieren oder zertifizieren. 9. Vergleichsport und Vergleichsadapter verwenden. 10. nach der Maßnahme Linkgeschwindigkeit und Fehlerzähler erneut prüfen. **Mögliche Ursachen** - ein Adernpaar unterbrochen, - schlechte Auflegung, - ungeeignetes Patchkabel, - beschädigte Dose, - fehlerhafter Port, - defekter Netzwerkadapter, - falsche Konfiguration, - unzureichende Signalqualität. --- **36. Praxisbeispiel: PoE-Gerät startet wiederholt neu** **Symptom** Ein Access Point oder eine Kamera startet unter Last neu. **Prüfung** 1. PoE-Anforderung des Geräts bestimmen. 2. unterstützten Standard und Port des Switches prüfen. 3. verfügbares Gesamtbudget kontrollieren. 4. Switchprotokolle untersuchen. 5. Leistung direkt am Switchport prüfen. 6. Leistung an der entfernten Dose unter Last prüfen. 7. Kabelweg und Widerstandsunsymmetrie untersuchen. 8. geprüftes kurzes Kabel verwenden. 9. geeigneten Vergleichsport oder PSE einsetzen. 10. Temperatur und Firmware berücksichtigen. **Mögliche Ursachen** - Leistungsbudget erschöpft, - falsche PoE-Klasse, - hoher Spannungsabfall, - beschädigtes Adernpaar, - schlechte Auflegung, - ungeeigneter Injektor, - defektes Endgerät, - Überhitzung, - fehlerhafte Switchkonfiguration. --- **37. Praxisbeispiel: Glasfaserlink bleibt down** **Prüfung** 1. Transceivertypen auf beiden Seiten vergleichen. 2. Geschwindigkeit und Wellenlänge prüfen. 3. Singlemode beziehungsweise Multimode prüfen. 4. Faserpolarität kontrollieren. 5. Transceiver vollständig einsetzen. 6. optische Diagnosedaten auslesen. 7. Endflächen inspizieren und fachgerecht reinigen. 8. geprüftes Patchkabel verwenden. 9. optischen Pegel messen. 10. Strecke mit OLTS beziehungsweise OTDR untersuchen. 11. Transceiver kontrolliert austauschen. 12. Port- und Gerätekonfiguration prüfen. **Mögliche Ursachen** - vertauschte Sende- und Empfangsfaser, - falscher Transceiver, - inkompatible Wellenlänge, - verschmutzte Endfläche, - beschädigtes Patchkabel, - zu hohe Dämpfung, - Unterbrechung, - Port administrativ deaktiviert, - unterschiedliche Geschwindigkeit, - fehlerhafter Transceiver. --- **38. Praxisbeispiel: WLAN ist nur in einem Raum instabil** **Prüfung** 1. betroffene Clients und Zeiten bestimmen. 2. Signalstärke und SNR messen. 3. Kanal und Kanalnutzung prüfen. 4. Spektrum am betroffenen Ort untersuchen. 5. Vergleichsmessung außerhalb des Raums durchführen. 6. zeitabhängige Störquelle suchen. 7. Wandmaterialien und Raumaufteilung berücksichtigen. 8. Client mit Vergleichshardware testen. 9. Access-Point-Position und Sendeleistung prüfen. 10. Änderung nur einzeln durchführen und erneut messen. **Mögliche Ursachen** - nicht WLAN-basierte Störquelle, - starke Kanalüberlagerung, - ungünstige Abschirmung, - Metallflächen, - fehlerhafter Clientadapter, - zu hohe oder zu niedrige Sendeleistung, - ungeeignete Kanalbreite, - Roamingproblem, - hohe Kanalnutzung. --- **39. Praxisbeispiel: Server ist über das Netzwerk nicht erreichbar** **Prüfung** 1. Stromversorgung und Statusanzeigen prüfen. 2. Switchport und Kabel untersuchen. 3. Out-of-Band-Management testen. 4. Hardwareereignisse und Sensoren prüfen. 5. Remote-Konsole öffnen. 6. Bootstatus beobachten. 7. Betriebssystem- und Netzwerkzustand prüfen. 8. bei Bedarf geprüftes Kabel und Vergleichsport verwenden. 9. Netzteil- und Temperaturzustand untersuchen. 10. Neustart nur nach Freigabe und Beweissicherung durchführen. **Mögliche Ergebnisse** | Ergebnis | Einordnung | |---|---| | Out-of-Band erreichbar, Betriebssystem nicht | Betriebssystem, Treiber, Netzwerkdienst oder Konfiguration | | weder In-Band noch Out-of-Band erreichbar | Stromversorgung, Managementpfad oder Hardware | | Remote-Konsole zeigt Startfehler | Bootmedium, Dateisystem, Firmware oder Hardware | | Hardwarestatus zeigt Alarm | betroffene Komponente gezielt untersuchen | | anderer Switchport funktioniert | ursprünglicher Port oder dessen Konfiguration | | geprüftes Kabel funktioniert | ursprüngliche Verkabelung verdächtig | --- **40. Häufige Fehlinterpretationen** | Aussage | fachliche Einordnung | |---|---| | „Der Kabeltester zeigt alle Adern, also ist das Kabel für 10 Gbit/s geeignet.“ | Ein einfacher Wiremap-Test zertifiziert keine Übertragungsleistung. | | „Mit dem Ersatzkabel funktioniert es, also ist sicher nur das Kabel defekt.“ | Auch ein Steckkontakt oder eine veränderte mechanische Belastung kann beteiligt sein. | | „PoE-Spannung ist vorhanden, also reicht die Leistung aus.“ | Entscheidend ist die verfügbare Leistung unter Last. | | „Der optische Pegel ist sichtbar, also ist die Faser in Ordnung.“ | Pegel, Dämpfung, Reflexionen, Polarität und Protokoll müssen getrennt geprüft werden. | | „Das OTDR zeigt einen Fehler bei 20 Metern, also ist dort sicher das Kabel gebrochen.“ | Die Anzeige beschreibt ein optisches Ereignis; Messparameter und Leitungsweg müssen berücksichtigt werden. | | „Starke WLAN-Signalstärke bedeutet eine gute Verbindung.“ | Interferenz, SNR, Kanalnutzung und Retries können die Verbindung trotzdem beeinträchtigen. | | „Die Temperatur fühlt sich normal an.“ | subjektive Wahrnehmung ersetzt keine Messung und keine Herstellergrenze. | | „Der Managementport ist erreichbar, also ist der Server vollständig in Ordnung.“ | Out-of-Band-Zugriff bestätigt nicht den Zustand des Betriebssystems oder der Anwendung. | | „Ein Multimeter ist ungefährlich, weil nur Kleinspannung gemessen wird.“ | falsche Bedienung und unbekannte Stromkreise können weiterhin Schäden verursachen. | | „Ein einmal bestandener Test beweist dauerhaft fehlerfreie Verkabelung.“ | Kabel, Stecker und Umgebungsbedingungen können sich später verändern. | --- **41. Checkliste physische Messgeräte** - [ ] betroffene Verbindung und deren Funktion sind bekannt. - [ ] Wartungs- oder Änderungsfreigabe wurde geprüft. - [ ] Ausgangszustand wurde dokumentiert. - [ ] Kabel und Anschlüsse wurden eindeutig beschriftet. - [ ] Sichtprüfung wurde durchgeführt. - [ ] geeignetes Messgerät wurde ausgewählt. - [ ] Messgerät und Adapter sind unbeschädigt. - [ ] Kalibrierungsstatus wurde geprüft. - [ ] richtige Messleitungen wurden verwendet. - [ ] richtige Geräteeinstellung wurde gewählt. - [ ] Referenzwert und Grenzwert sind bekannt. - [ ] geprüftes Ersatzkabel ist verfügbar. - [ ] immer nur eine Komponente wurde verändert. - [ ] Kupfermessung unterscheidet Verification, Qualification und Certification. - [ ] TDR-Messung verwendet einen passenden NVP-Wert. - [ ] PoE wurde bei Bedarf unter Last geprüft. - [ ] passive PoE-Verbindungen wurden nicht ungeprüft angeschlossen. - [ ] Multimeter wurde nur durch qualifizierte Personen eingesetzt. - [ ] Glasfasertyp und Wellenlänge wurden bestimmt. - [ ] aktive Glasfaser wurde sicher behandelt. - [ ] Glasfaser wurde inspiziert, gereinigt und erneut inspiziert. - [ ] optischer Pegel und Streckendämpfung wurden unterschieden. - [ ] OTDR-Einstellungen und Totzonen wurden berücksichtigt. - [ ] Launch- und Receive-Faser wurden bei Bedarf verwendet. - [ ] WLAN-Scanner und Spektrumanalysator wurden unterschieden. - [ ] Vergleichsmessung wurde unter vergleichbaren Bedingungen durchgeführt. - [ ] Out-of-Band-Zugriff wurde sicher verwendet. - [ ] Messwerte, Einstellungen und Messpunkte wurden dokumentiert. - [ ] Nachmessung nach der Maßnahme wurde durchgeführt. - [ ] Funktion und mögliche Nebenwirkungen wurden geprüft. - [ ] Messberichte wurden sicher gespeichert. --- **42. Schnellreferenz** | Werkzeug | Hauptzweck | bestätigt nicht automatisch | |---|---|---| | geprüftes Ersatzkabel | verdächtiges Kabel kontrolliert vergleichen | Fehlerfreiheit der festen Verkabelung | | einfacher Kabeltester | Wiremap, Unterbrechung und Kurzschluss prüfen | Einhaltung einer Kabelkategorie | | Kabelqualifizierer | Eignung für Netzwerkanwendung untersuchen | normgerechte Zertifizierung | | Kabelzertifizierer | Verkabelung gegen definierte Grenzwerte messen | fehlerfreie Switch- oder Endgeräte | | TDR | Entfernung zu elektrischer Auffälligkeit bestimmen | genaue mechanische Ursache | | Tongenerator | Leitung suchen und zuordnen | Ethernet-Leistungsfähigkeit | | Loopback-Stecker | lokalen Sende- und Empfangspfad prüfen | gesamten Ende-zu-Ende-Pfad | | PoE-Tester | PoE-Erkennung und Leistung untersuchen | stabile Leistung ohne Lastmessung | | Multimeter | geeignete elektrische Größen messen | sichere Bedienung ohne Qualifikation | | Glasfaser-Inspektionssonde | Endflächen untersuchen | optische Dämpfung | | Visual Fault Locator | grobe Fehler und Faserzuordnung prüfen | normgerechte Streckenqualität | | optischer Leistungsmesser | absoluten Empfangspegel messen | genaue Position einer Fehlerstelle | | OLTS | Einfügedämpfung der Strecke messen | genaue Lage einzelner Ereignisse | | OTDR | Ereignisse und Entfernungen entlang der Faser analysieren | vollständigen Ersatz für OLTS | | Spektrumanalysator | Funkenergie und Störquellen untersuchen | erfolgreiche WLAN-Anmeldung | | Wärmebildkamera | Temperaturverteilung sichtbar machen | interne Bauteiltemperatur ohne Einordnung | | Konsolenkabel | lokalen Gerätezugriff ermöglichen | funktionierendes Netzwerk | | Out-of-Band-Management | unabhängigen Hardware- und Konsolenzugriff bereitstellen | funktionierendes Betriebssystem | --- **Merksatz** > Physische Fehleranalyse beginnt mit Sichtprüfung, Dokumentation und einem kontrollierten Vergleich. Danach wird das passende Messgerät eingesetzt: Kabeltester für Verdrahtung, Zertifizierer für Übertragungsgrenzen, TDR und OTDR für Fehlerentfernungen, Leistungsmesser für optische Pegel, PoE-Tester für Stromversorgung unter realen Bedingungen und Spektrumanalysator für Funkstörungen. Ein einzelner Messwert ersetzt niemals die technische Einordnung und die abschließende Funktionsprüfung. --- **Quellen und weiterführende Dokumentation** - [Fluke Networks – Verification, Qualification und Certification unterscheiden](https://www.flukenetworks.com/blog/cabling-chronicles/verification-qualification-certification-which-do-i-need.html) - [Fluke Networks – Kupfer-Kabelzertifizierung mit der DSX CableAnalyzer-Serie](https://www.flukenetworks.com/datacom-cabling/Versiv/dsx-cableanalyzer-series) - [Fluke Networks – Versiv Cable Certifier](https://www.flukenetworks.com/products/cabling-certification/cabling-certification-versiv) - [Fluke Networks – Grundlagen der Netzwerk- und Kabelprüfung](https://www.flukenetworks.com/blog/cabling-chronicles/network-and-cable-testing.html) - [Fluke Networks – Glasfaser-Messgeräte und Fehlersuche](https://www.flukenetworks.com/expertise/learn-about/fiber-testing) - [Fluke Networks – Optische Leistungsmesser und Fehlerlokalisierung](https://www.flukenetworks.com/products/installation-and-test/fiber-optic-power-meters-and-fault-locators) - [Fluke Networks – OLTS und OTDR als vollständige Prüfstrategie](https://www.flukenetworks.com/edocs/olts-otdr-complete-testing-strategy) - [Fluke Networks – OptiFiber Pro OTDR](https://www.flukenetworks.com/datacom-cabling/fiber-testing/optifiber-pro-otdr) - [Fluke Networks – Glasfaser inspizieren und reinigen](https://www.flukenetworks.com/edocs/wp-fiber-cleaning-and-inspection-white-paper) - [Fluke Networks – Grundregel für Glasfaser: inspizieren, reinigen und erneut inspizieren](https://www.flukenetworks.com/blog/cabling-chronicles/golden-rule-fiber-inspection-keeps-times.html) - [NetAlly – Funktionsweise von Netzwerk-Kabeltestern](https://www.netally.com/general/how-do-network-cable-testers-work/) - [NetAlly – Häufige PoE-Probleme erkennen](https://www.netally.com/wired-solutions/how-to-find-common-poe-problems/) - [NetAlly – PoE-Prüfung mit einem tragbaren Netzwerkprüfgerät](https://www.netally.com/tech-tips/how-to-do-an-easy-poe-test-under-10-seconds/) - [NetAlly – Kabel-, Netzwerk-, WLAN- und Spektrumanalyse](https://www.netally.com/products/) - [Cisco – Out-of-Band-Management: Best Practices](https://www.cisco.com/c/en/us/solutions/collateral/service-provider/out-of-band-best-practices-wp.html) - [Cisco – Integrated Management Controller für UCS-C-Series-Server](https://www.cisco.com/c/en/us/td/docs/unified_computing/ucs/c/sw/gui/config/guide/1-0_1x/b_Cisco_UCS_C-Series_Servers_Integrated_Management_Controller_Configuration_Guide_1-0_1x/Cisco_UCS_C-Series_Servers_Integrated_Management_Controller_Configuration_Guide_1-0_1x_chapter1.html) # 6. Netzwerk- und Verbindungsfehler # 6.1 Client ohne Netzwerkverbindung – systematische Ende-zu-Ende-Analyse Ein Client meldet „Kein Internet“, erreicht keine internen Systeme oder kann einzelne Netzwerkdienste nicht verwenden. Diese Beschreibung benennt zunächst nur das sichtbare Symptom. Sie beweist weder einen Kabeldefekt noch einen Ausfall des Routers oder Internetzugangs. Die Ursache kann an unterschiedlichen Stellen liegen: - physische Verbindung, - WLAN-Verbindung, - Netzwerkadapter, - VLAN-Zuordnung, - IP-Konfiguration, - DHCP, - ARP beziehungsweise IPv6 Neighbor Discovery, - Standardgateway, - Routing, - DNS, - Firewall, - Proxy, - VPN, - Authentifizierung, - Zielsystem, - Anwendung, - Internetzugang. Die Fehleranalyse muss deshalb vom betroffenen Client schrittweise bis zum Ziel erfolgen. --- **1. Lernziele** Nach dieser Seite kannst du: - eine ungenaue Störungsmeldung in ein prüfbares Fehlerbild übersetzen, - den betroffenen Umfang bestimmen, - physische Verbindung und logische Erreichbarkeit unterscheiden, - IPv4- und IPv6-Konfigurationen bewerten, - DHCP-, Gateway-, Routing- und DNS-Probleme auseinanderhalten, - lokale und entfernte Fehler voneinander abgrenzen, - geeignete Vergleichstests durchführen, - typische Fehlinterpretationen vermeiden, - Maßnahmen kontrolliert ausführen, - Ursache, Lösung und Nachprüfung dokumentieren. --- **2. Ausgangssituation** Ein Benutzer meldet: > „Mein Computer hat kein Netzwerk.“ Diese Aussage lässt entscheidende Fragen offen: - Ist Ethernet oder WLAN betroffen? - Besteht überhaupt eine Verbindung zum lokalen Netzwerk? - Funktioniert nur das Internet nicht? - Sind interne Systeme erreichbar? - Ist nur eine Anwendung betroffen? - Funktionieren Ziele über IP-Adresse, aber nicht über Namen? - Sind weitere Benutzer oder Geräte betroffen? - Trat das Problem plötzlich oder nach einer Änderung auf? - Ist der Fehler dauerhaft oder nur zeitweise vorhanden? - Funktioniert eine andere Netzwerkverbindung? - Ist ein VPN aktiv? - Wird ein Proxy verwendet? - betrifft das Problem IPv4, IPv6 oder beide Protokolle? Vor technischen Eingriffen muss aus der allgemeinen Meldung ein eindeutig prüfbares Symptom entstehen. --- **3. Fehlerbild präzisieren** Geeignete Fragen sind: - Welche konkrete Anwendung funktioniert nicht? - Welche Adresse oder welcher Dienst soll erreicht werden? - Welche Fehlermeldung wird angezeigt? - Seit wann besteht der Fehler? - Funktionierte die Verbindung zuvor? - Was wurde unmittelbar vorher verändert? - Sind interne und externe Ziele gleichermaßen betroffen? - Funktioniert der Zugriff über eine IP-Adresse? - Funktioniert der Zugriff über einen DNS-Namen? - Sind andere Geräte am selben Standort betroffen? - Funktioniert der Client über ein anderes Netzwerk? - Tritt der Fehler mit einem anderen Benutzerkonto ebenfalls auf? - Besteht der Fehler nur bei aktivem VPN? - Ist ein bestimmtes WLAN, Kabel, Dock oder VLAN beteiligt? **Beispiel für ein präzisiertes Fehlerbild** ```text Client: Notebook NB-204 Verbindung: Ethernet über USB-C-Dockingstation Standort: Gebäude B, Raum 204 Beginn: heute nach dem Wechsel des Arbeitsplatzes Lokale Linkanzeige: aktiv IPv4-Adresse: 169.254.37.18/16 Standardgateway: nicht vorhanden Interne und externe Ziele: nicht erreichbar Weitere Clients an derselben Datendose: ebenfalls ohne DHCP-Adresse WLAN-Verbindung des Notebooks: funktioniert ``` Damit ist die Untersuchung wesentlich stärker eingegrenzt als durch die ursprüngliche Aussage „Kein Netzwerk“. --- **4. Zuerst den Umfang bestimmen** | Beobachtung | wahrscheinlicher Untersuchungsbereich | |---|---| | nur eine Anwendung betroffen | Anwendung, Dienst, Port, Proxy, Zertifikat oder Berechtigung | | nur ein Ziel betroffen | Zielsystem, Zielnetz, DNS-Eintrag oder Route | | nur ein Client betroffen | Client, Adapter, Kabel, Port oder lokale Konfiguration | | mehrere Clients an einem Switch betroffen | Switch, Uplink, VLAN, Stromversorgung oder zentrale Dienste | | nur ein VLAN betroffen | VLAN-Konfiguration, Trunk, Gateway, DHCP-Relay oder ACL | | nur WLAN betroffen | Access Point, Authentifizierung, Funkversorgung oder WLAN-Konfiguration | | interne Ziele erreichbar, Internet nicht | Gateway, Firewall, NAT, Proxy oder Provider | | Internet erreichbar, interne Ziele nicht | internes Routing, VPN, DNS, Firewall oder Berechtigung | | IP-Adressen funktionieren, Namen nicht | DNS-Konfiguration oder Namensauflösung | | Namen werden aufgelöst, Verbindung scheitert | Routing, Firewall, Dienst, Port oder Anwendung | | nur ein Standort betroffen | Standortanbindung, lokales Gateway, WAN oder Standort-Firewall | | alle Systeme betroffen | zentrale Netzwerkkomponente, DNS, DHCP, Firewall, WAN oder Stromversorgung | > Der Umfang ist einer der wichtigsten Hinweise auf die Fehlerdomäne. Ein lokaler Eingriff am Client ist nicht sinnvoll, wenn gleichzeitig ein vollständiges VLAN oder ein ganzer Standort betroffen ist. --- **5. Ausgangszustand sichern** Vor Änderungen sollten mindestens dokumentiert werden: - Datum und Uhrzeit, - betroffener Client, - Benutzerkontext, soweit erforderlich, - Standort, - Anschlussart, - Dockingstation oder Adapter, - Switchport, sofern bekannt, - SSID bei WLAN, - IP-Adressen, - Präfix beziehungsweise Subnetzmaske, - Standardgateway, - DNS-Server, - DHCP-Status, - Routingtabelle, - Proxy- und VPN-Status, - genaue Fehlermeldung, - erreichbare und nicht erreichbare Ziele, - bereits ausgeführte Maßnahmen, - letzte bekannte funktionierende Nutzung, - vorausgegangene Änderungen. **Windows** ```powershell Get-Date Get-NetAdapter Get-NetIPConfiguration Get-NetIPAddress Get-NetRoute Get-DnsClientServerAddress ipconfig /all route print ``` **Linux** ```bash date ip link ip address ip route resolvectl status nmcli device status ``` **macOS** ```bash date networksetup -listallhardwareports ifconfig route -n get default scutil --dns ``` Je nach Betriebssystem, Version und Netzwerkkonfiguration können einzelne Befehle oder Ausgaben abweichen. --- **6. Prüfreihenfolge** ```text Fehlerbild präzisieren → Umfang bestimmen → Ausgangszustand dokumentieren → physische Verbindung prüfen → Netzwerkadapter prüfen → IP-Konfiguration bewerten → lokales Protokoll prüfen → Standardgateway testen → Routing untersuchen → DNS getrennt testen → Zielport und Dienst prüfen → Firewall, Proxy und VPN berücksichtigen → kontrollierten Vergleichstest durchführen → Maßnahme umsetzen → erneut messen → Funktion und Nebenwirkungen prüfen → Ursache und Lösung dokumentieren ``` Diese Reihenfolge ist kein starres Schema. Sie verhindert jedoch, dass ohne ausreichende Eingrenzung gleichzeitig Kabel, Einstellungen, Treiber und Netzwerkkomponenten verändert werden. --- **7. Physische Verbindung prüfen** Bei Ethernet sind zu prüfen: - sitzt das Kabel an beiden Seiten vollständig? - zeigt der Netzwerkadapter einen Link? - zeigt der Switchport einen Link? - ist das Kabel sichtbar beschädigt? - wird eine Dockingstation oder ein USB-Netzwerkadapter verwendet? - wird der richtige Anschluss verwendet? - ist der Switchport aktiviert? - stimmt die ausgehandelte Geschwindigkeit? - steigen Fehler- oder Verwerfungszähler? - befindet sich der Anschluss im erwarteten VLAN? - liefert die Dockingstation zuverlässig Strom? - funktioniert ein geprüftes Vergleichskabel? - funktioniert ein bekanntermaßen geeigneter Vergleichsport? **Windows** ```powershell Get-NetAdapter Get-NetAdapterStatistics ``` **Linux** ```bash ip -s link ethtool ``` **macOS** ```bash ifconfig networksetup -getMedia ``` `` muss durch den tatsächlichen Schnittstellennamen ersetzt werden. **Mögliche Beobachtungen** | Beobachtung | mögliche Einordnung | |---|---| | kein Link auf beiden Seiten | Kabel, Port, Adapter, Stromversorgung oder deaktivierte Schnittstelle | | Link nur mit 100 Mbit/s statt 1 Gbit/s | Adernpaar, Auflegung, Kabelqualität oder Aushandlung | | Link wechselt wiederholt | Kontaktproblem, Kabel, Adapter, Dock, Port oder Stromversorgung | | hohe CRC- beziehungsweise FCS-Fehler | physische Signalstörung, Kabel, Stecker oder Port | | viele Drops ohne physische Fehler | Überlastung, Puffer, QoS oder Systemressourcen | | anderer Switchport funktioniert | ursprünglicher Port oder dessen Konfiguration | | anderes Kabel funktioniert | ursprüngliches Kabel oder veränderter Steckkontakt verdächtig | | direkte Verbindung funktioniert, Dock nicht | Dock, USB-Verbindung, Treiber oder Stromversorgung | > Dass der Link aktiv ist, bestätigt nur eine Verbindung auf der Bitübertragungsschicht. Eine richtige IP-Konfiguration, VLAN-Zuordnung oder Ende-zu-Ende-Erreichbarkeit ist damit nicht bewiesen. --- **8. WLAN-Verbindung prüfen** Bei WLAN sind zusätzlich zu prüfen: - ist WLAN aktiviert? - befindet sich das Gerät im Flugmodus? - ist die richtige SSID ausgewählt? - wurde die Authentifizierung erfolgreich abgeschlossen? - besitzt das Gerät eine IP-Konfiguration? - ist das Signal ausreichend? - ist der Signal-Rausch-Abstand ausreichend? - besteht eine Captive-Portal-Anmeldung? - ist das Gerät im richtigen VLAN? - greift eine Geräte- oder Benutzerzulassung? - besteht eine auffällige Kanalnutzung? - funktioniert derselbe Client an einem anderen Standort? - funktioniert ein Vergleichsclient am betroffenen Standort? - wird zwischen verschiedenen Access Points oder Frequenzbändern gewechselt? **Windows** ```powershell netsh wlan show interfaces netsh wlan show networks mode=bssid ``` **Linux mit NetworkManager** ```bash nmcli device status nmcli device wifi list nmcli connection show --active ``` **macOS** ```bash networksetup -getairportnetwork en0 system_profiler SPAirPortDataType ``` Der tatsächliche Schnittstellenname kann abweichen. **Wichtige Unterscheidung** ```text mit SSID verbunden ≠ erfolgreich authentifiziert ≠ richtige VLAN-Zuordnung ≠ gültige IP-Konfiguration ≠ erreichbares Standardgateway ≠ funktionsfähiger DNS-Dienst ≠ erreichbares Internet ``` --- **9. Zustand des Netzwerkadapters prüfen** Ein Netzwerkadapter kann vorhanden, aber nicht funktionsfähig sein. Zu prüfen sind: - Schnittstelle aktiviert oder deaktiviert, - administrativer Zustand, - operativer Zustand, - Treiberstatus, - Firmwarestatus, - Hardwareerkennung, - MAC-Adresse, - Geschwindigkeit und Duplex, - Energieverwaltung, - virtuelle Netzwerkadapter, - VPN-Adapter, - Bridging, - Teaming oder Bonding, - auffällige Fehlerzähler, - wiederholte Trennung und Neuverbindung. **Windows** ```powershell Get-NetAdapter Get-NetAdapterAdvancedProperty Get-NetAdapterPowerManagement Get-PnpDevice -Class Net ``` **Linux** ```bash ip link ip -s link lspci -k lsusb ethtool ``` **macOS** ```bash networksetup -listallhardwareports ifconfig system_profiler SPNetworkDataType ``` > Ein Treiberupdate oder eine Neuinstallation sollte nicht die erste Maßnahme sein, solange der aktuelle Zustand noch nicht ausreichend dokumentiert und eingegrenzt wurde. --- **10. IPv4-Konfiguration bewerten** Eine vollständige IPv4-Konfiguration umfasst normalerweise: - IPv4-Adresse, - Subnetzmaske beziehungsweise Präfixlänge, - Standardgateway, - DNS-Server, - gegebenenfalls DHCP-Server, - Lease-Zeiten, - verbindungsspezifisches DNS-Suffix, - zusätzliche statische Routen. **Beispiel** ```text IPv4-Adresse: 192.168.10.24 Präfix: /24 Standardgateway: 192.168.10.1 DNS-Server: 192.168.10.10 und 192.168.10.11 DHCP-Server: 192.168.10.5 ``` Bei `/24` gehören beispielsweise `192.168.10.24` und `192.168.10.1` zum selben IPv4-Subnetz. **Typische Auffälligkeiten** | Beobachtung | mögliche Ursache | |---|---| | keine IPv4-Adresse | Adapter, DHCP, VLAN oder Konfiguration | | Adresse aus `169.254.0.0/16` | keine nutzbare DHCP-Antwort oder bewusst verwendete Link-Local-Adresse | | Adresse `0.0.0.0` | Initialisierung oder Adresszuweisung fehlgeschlagen | | falsches Subnetz | statische Fehlkonfiguration oder falscher DHCP-Bereich | | kein Standardgateway | DHCP-Option fehlt oder statische Konfiguration unvollständig | | falscher DNS-Server | DHCP-Option, VPN, manuelle Konfiguration oder Richtlinie | | doppelte IP-Adresse | Adresskonflikt | | sehr kurze Lease-Zeit | DHCP-Konfiguration oder Sondernetz | | mehrere Gateways | mehrdeutiges Routing oder mehrere aktive Adapter | | gültige Adresse, Gateway nicht erreichbar | VLAN, Layer 2, Gateway, ARP oder Firewall | | Gateway erreichbar, entfernte IP nicht | Routing, Firewall, NAT oder Zielpfad | --- **11. Automatische private IPv4-Adresse richtig einordnen** Erhält ein Windows-Client keine geeignete DHCP-Konfiguration, kann er automatisch eine Adresse aus `169.254.0.0/16` verwenden. Dieser Bereich ist für IPv4 Link-Local-Adressen vorgesehen. Eine solche Adresse bedeutet nicht automatisch: - dass der DHCP-Server ausgeschaltet ist, - dass das Netzwerkkabel defekt ist, - dass der Switch ausgefallen ist, - dass der Client überhaupt keine Verbindung besitzt. Mögliche Ursachen sind: - DHCP-Server nicht erreichbar, - DHCP-Dienst ausgefallen, - falsches VLAN, - fehlerhafter DHCP-Relay-Agent, - erschöpfter DHCP-Adressbereich, - DHCP-Antwort durch Sicherheitsfunktion blockiert, - fehlerhafte Portkonfiguration, - beschädigte Verbindung, - Clientfehler, - verzögerte Adressvergabe. **Zu prüfen sind** ```text physischer Link → VLAN-Zuordnung → DHCP-Anforderung → DHCP-Weiterleitung → DHCP-Server → verfügbarer Adressbereich → DHCP-Angebot → Clientannahme ``` --- **12. DHCP systematisch untersuchen** Der vereinfachte IPv4-DHCP-Ablauf wird häufig als DORA bezeichnet: ```text DHCPDISCOVER → DHCPOFFER → DHCPREQUEST → DHCPACK ``` Je nach Zustand und Erneuerung eines Leases können andere DHCP-Nachrichten auftreten. **Windows** ```powershell ipconfig /all ipconfig /release ipconfig /renew ``` **Linux mit NetworkManager** ```bash nmcli device show nmcli connection show --active ``` **macOS** ```bash ipconfig getpacket networksetup -getinfo ``` Eine Lease-Erneuerung verändert den Zustand und sollte nur kontrolliert ausgeführt werden. **Mögliche Fehlerstellen** | Phase | mögliche Ursache | |---|---| | Discover verlässt Client nicht | Schnittstelle, Clientdienst, lokale Firewall oder Treiber | | Discover erreicht Server nicht | VLAN, Switch, DHCP Snooping, Relay oder Routing | | Server sendet kein Offer | Dienst, Bereich, Reservierung, Richtlinie oder Adressmangel | | Offer erreicht Client nicht | Relay, VLAN, Sicherheitsfunktion oder Rückweg | | Client sendet keinen Request | Clientzustand oder ungeeignetes Angebot | | Server sendet kein ACK | Konflikt, Richtlinie, Bereich oder Serverfehler | | ACK erreicht Client nicht | Netzwerkpfad oder Sicherheitsfunktion | | Adresse vorhanden, Optionen fehlen | DHCP-Optionen oder Gültigkeitsbereich fehlerhaft | **Bei DHCP zusätzlich prüfen** - ist der richtige DHCP-Bereich aktiv? - sind freie Adressen vorhanden? - bestehen Ausschlüsse oder Reservierungen? - stimmt die Subnetzmaske? - wird das richtige Gateway verteilt? - werden geeignete DNS-Server verteilt? - stimmt der DHCP-Relay-Eintrag? - ist DHCP Snooping korrekt konfiguriert? - existiert ein nicht autorisierter DHCP-Server? - erscheinen Fehler oder Konflikte im DHCP-Protokoll? --- **13. IPv6 nicht übersehen** Ein Client kann gleichzeitig IPv4 und IPv6 verwenden. Daher können Fehler nur eines Protokollstapels zu scheinbar widersprüchlichen Ergebnissen führen. Zu prüfen sind: - Link-Local-Adresse, - globale oder lokale IPv6-Adresse, - Präfixlänge, - Standardroute, - Router Advertisement, - DNS-Server, - DHCPv6, sofern eingesetzt, - Duplicate Address Detection, - Neighbor Discovery, - Übergangs- oder Tunnelmechanismen, - IPv6-Firewallregeln. **Windows** ```powershell Get-NetIPAddress -AddressFamily IPv6 Get-NetRoute -AddressFamily IPv6 ipconfig /all ``` **Linux** ```bash ip -6 address ip -6 route ip -6 neighbor ``` **macOS** ```bash ifconfig netstat -rn -f inet6 ``` **Wichtige Einordnung** - Eine Adresse aus `fe80::/10` ist eine IPv6-Link-Local-Adresse. - Link-Local-Adressen gelten nur auf dem jeweiligen Link. - Bei der Verwendung einer Link-Local-Adresse kann eine Schnittstellenangabe erforderlich sein. - Ein funktionierendes IPv6 kann einen defekten IPv4-Pfad teilweise verdecken. - Ein fehlerhafter IPv6-Pfad kann Verzögerungen erzeugen, obwohl IPv4 funktioniert. - IPv6 sollte nicht allein zur Fehlerumgehung pauschal deaktiviert werden. --- **14. Lokalen Protokollstapel prüfen** Vor externen Zielen kann zunächst der lokale TCP/IP-Stapel geprüft werden. **IPv4** ```text 127.0.0.1 ``` **IPv6** ```text ::1 ``` **Windows** ```powershell ping 127.0.0.1 ping ::1 ``` **Linux und macOS** ```bash ping 127.0.0.1 ping6 ::1 ``` Abhängig vom Betriebssystem kann der IPv6-Befehl auch über `ping -6` erfolgen. Ein erfolgreicher Loopback-Test bestätigt Teile des lokalen Protokollstapels. Er bestätigt nicht: - den Netzwerkadapter, - das Kabel, - die WLAN-Verbindung, - die VLAN-Zuordnung, - das Standardgateway, - den DNS-Dienst, - die Erreichbarkeit anderer Systeme. --- **15. Eigene Adresse prüfen** Danach kann die eigene zugewiesene Adresse geprüft werden. ```text Loopback-Adresse → eigene IP-Adresse → Nachbar im selben Netz → Standardgateway → entferntes Ziel per IP → DNS-Server → Ziel per DNS-Namen → konkreter Dienst und Port ``` Auch ein erfolgreicher Ping auf die eigene Adresse bestätigt nicht automatisch, dass Pakete den physischen Netzwerkadapter tatsächlich verlassen. --- **16. ARP und Neighbor Discovery untersuchen** Für IPv4 wird ARP verwendet, um IPv4-Adressen auf MAC-Adressen im lokalen Netz abzubilden. IPv6 verwendet Neighbor Discovery über ICMPv6. **Windows** ```powershell arp -a Get-NetNeighbor ``` **Linux** ```bash ip neighbor ``` **macOS** ```bash arp -a ndp -a ``` **Mögliche Zustände** | Beobachtung | mögliche Einordnung | |---|---| | Gateway besitzt gültigen Nachbareintrag | lokale Auflösung war grundsätzlich möglich | | Eintrag bleibt unvollständig | Gegenstelle antwortet nicht oder Layer-2-Pfad fehlerhaft | | MAC-Adresse ändert sich unerwartet | Redundanz, Gatewaywechsel, Fehlkonfiguration oder Sicherheitsproblem | | falsche MAC-Adresse | doppelter Adressgebrauch, ARP-Spoofing oder falsche Netzstruktur | | viele unvollständige Einträge | Layer-2-, VLAN- oder Erreichbarkeitsproblem | | Nachbareintrag vorhanden, Ping scheitert | ICMP kann blockiert sein oder Gegenstelle antwortet nicht | Ein vorhandener ARP- oder Neighbor-Eintrag beweist nicht die vollständige Erreichbarkeit eines Dienstes. --- **17. Standardgateway prüfen** Das Standardgateway leitet Daten zu Zielen außerhalb des lokalen Netzes weiter. Zu prüfen sind: - ist ein Gateway eingetragen? - gehört das Gateway zum direkt erreichbaren Netz? - ist eine passende Standardroute vorhanden? - wird die richtige Schnittstelle verwendet? - stimmt die Metrik beziehungsweise Priorität? - ist das Gateway über ARP oder Neighbor Discovery erreichbar? - antwortet es auf zulässige Tests? - betrifft das Problem nur ein VLAN? - ist die Gateway-Schnittstelle aktiv? - bestehen redundante Gateways? - funktionieren Hin- und Rückweg? **Windows** ```powershell Get-NetRoute -DestinationPrefix "0.0.0.0/0" Get-NetRoute -AddressFamily IPv6 route print ``` **Linux** ```bash ip route ip -6 route ``` **macOS** ```bash route -n get default netstat -rn ``` > Ein Gateway muss nicht auf ICMP-Echo-Anfragen antworten. Ein fehlgeschlagener Ping allein beweist deshalb keinen Gateway-Ausfall. --- **18. Lokales und entferntes Ziel unterscheiden** Ob ein Ziel lokal oder entfernt ist, ergibt sich aus: - eigener IP-Adresse, - Präfix beziehungsweise Subnetzmaske, - Zieladresse, - Routingtabelle. **Beispiel** ```text Client: 192.168.10.24/24 Ziel A: 192.168.10.80 Ziel B: 192.168.20.80 ``` `Ziel A` liegt im selben `/24`-Netz und wird normalerweise direkt über die lokale Verbindung erreicht. `Ziel B` liegt in einem anderen Netz und benötigt eine passende Route, häufig über das Standardgateway. Eine falsche Subnetzmaske kann dazu führen, dass der Client ein entferntes Ziel fälschlich als lokal behandelt oder ein lokales Ziel unnötig an ein Gateway sendet. --- **19. Routingtabelle auswerten** Die Routingentscheidung berücksichtigt unter anderem: - Zielpräfix, - Präfixlänge, - Gateway, - Schnittstelle, - Metrik, - Richtlinien, - VPN-Routen, - statische Routen, - mehrere aktive Netzwerkadapter. Grundsätzlich gewinnt die spezifischste passende Route, also die Route mit dem längsten passenden Präfix. **Beispiel** ```text 0.0.0.0/0 über 192.168.10.1 10.0.0.0/8 über VPN 10.20.30.0/24 über 192.168.10.254 ``` Für ein Ziel in `10.20.30.0/24` ist die `/24`-Route spezifischer als die `/8`-Route und die Standardroute. **Typische Routingfehler** - keine Standardroute, - falsches Gateway, - falsche Präfixlänge, - unerwünschte VPN-Route, - gleiche Netze auf beiden Seiten eines VPN, - mehrere Standardrouten, - ungeeignete Metrik, - fehlende Rückroute, - asymmetrisches Routing, - veraltete statische Route, - falsche Schnittstellenbindung. --- **20. Erreichbarkeit schrittweise testen** Eine sinnvolle Testfolge lautet: ```text 1. Loopback 2. eigene Adresse 3. Gegenstelle im selben Subnetz 4. Standardgateway 5. entferntes internes Ziel per IP 6. externer Dienst per IP 7. DNS-Server 8. Name eines internen Ziels 9. Name eines externen Ziels 10. konkreter TCP- oder UDP-Dienst ``` Die Ziele müssen bewusst ausgewählt werden. Eine beliebige öffentliche IP-Adresse oder Website ist nicht automatisch ein geeigneter Referenzpunkt. **Beispielhafte Dokumentation** | Test | Ergebnis | Einordnung | |---|---|---| | Loopback erreichbar | erfolgreich | lokaler Protokollstapel grundsätzlich aktiv | | eigene Adresse erreichbar | erfolgreich | lokale Adressbindung vorhanden | | Gateway nicht erreichbar | fehlgeschlagen | Layer 2, VLAN, Gateway oder ICMP-Regel untersuchen | | internes Ziel per IP erreichbar | erfolgreich | grundlegendes Routing vorhanden | | interner Name nicht auflösbar | fehlgeschlagen | DNS gezielt untersuchen | | Name wird aufgelöst, Port 443 nicht erreichbar | fehlgeschlagen | Dienst, Firewall, Route oder Zielsystem | | Port 443 erreichbar, Browser scheitert | fehlgeschlagen | TLS, Proxy, Anwendung oder Authentifizierung | --- **21. Ping richtig interpretieren** `ping` verwendet ICMP-Echo-Anfragen und kann Hinweise auf Erreichbarkeit und Laufzeit geben. Ein erfolgreicher Ping kann bestätigen: - das Ziel beziehungsweise eine antwortende Komponente ist erreichbar, - ein Hin- und Rückweg für diese ICMP-Pakete besteht, - die verwendete Zieladresse war grundsätzlich erreichbar. Ein erfolgreicher Ping bestätigt nicht: - dass DNS funktioniert, - dass ein bestimmter TCP- oder UDP-Port erreichbar ist, - dass die Anwendung funktioniert, - dass keine Paketverluste bei anderer Last auftreten, - dass der gesamte Pfad fehlerfrei ist, - dass die Antwort tatsächlich vom erwarteten Anwendungsdienst stammt. Ein fehlgeschlagener Ping beweist nicht automatisch: - dass das Ziel ausgefallen ist, - dass keine Route besteht, - dass eine Firewall vollständig blockiert, - dass das Netzwerk unterbrochen ist. ICMP kann gefiltert, begrenzt oder vom Ziel nicht beantwortet werden. --- **22. Pfad mit Traceroute untersuchen** **Windows** ```powershell tracert Test-NetConnection -TraceRoute ``` **Linux** ```bash traceroute tracepath ``` **macOS** ```bash traceroute ``` Traceroute-Werkzeuge senden Pakete mit schrittweise erhöhtem Hop Limit beziehungsweise TTL-Wert. Zwischenrouter können daraufhin ICMP-Meldungen zurückgeben. **Grenzen** - Router müssen nicht antworten. - Ein Sternchen beweist keinen Ausfall. - Hin- und Rückweg können unterschiedlich sein. - Firewalls können die verwendeten Probe-Pakete filtern. - Load Balancing kann unterschiedliche Pfade anzeigen. - Der letzte sichtbare Hop ist nicht automatisch die Fehlerstelle. - Hohe Antwortzeit eines Zwischenrouters beweist keine Weiterleitungsverzögerung. - Unterschiedliche Implementierungen verwenden unterschiedliche Protokolle. > Entscheidend ist nicht nur, welcher Hop antwortet, sondern ob nachfolgende Hops und der eigentliche Zieldienst erreichbar sind. --- **23. DNS getrennt von der Netzwerkverbindung prüfen** Wenn ein Ziel per IP-Adresse erreichbar ist, aber nicht über seinen Namen, liegt der Untersuchungsbereich häufig bei der Namensauflösung. Zu prüfen sind: - konfigurierte DNS-Server, - Erreichbarkeit der DNS-Server, - Suchdomänen, - DNS-Suffix, - Record-Typ, - Name und Schreibweise, - DNS-Cache, - Split-DNS, - VPN-DNS, - Weiterleitungen, - Rekursion, - lokale Hosts-Datei, - DNSSEC, sofern relevant, - Ablaufzeit und Replikation, - Filter- oder Sicherheitsdienst. **Windows** ```powershell Resolve-DnsName nslookup Get-DnsClientServerAddress Get-DnsClientCache ``` **Linux** ```bash resolvectl query resolvectl status dig ``` **macOS** ```bash scutil --dns dig nslookup ``` **Gezielte Abfrage eines bestimmten DNS-Servers** ```bash dig @ ``` **Mögliche Ergebnisse** | Ergebnis | mögliche Einordnung | |---|---| | Name wird korrekt aufgelöst | DNS-Auflösung grundsätzlich erfolgreich | | `NXDOMAIN` | Name existiert aus Sicht des antwortenden DNS-Systems nicht | | Zeitüberschreitung | DNS-Server, Netzwerkpfad oder Firewall | | falsche Adresse | veralteter oder fehlerhafter Eintrag, Cache oder Split-DNS | | interner Name nur ohne VPN auflösbar | DNS-Zuweisung oder VPN-Routing untersuchen | | externer Name funktioniert, interner nicht | interne Zone, Suchdomäne oder Split-DNS | | ein DNS-Server antwortet, der andere nicht | Serverzustand, Pfad oder Konfiguration | | AAAA vorhanden, IPv6-Pfad fehlerhaft | IPv6 und Anwendungsauswahl untersuchen | > `nslookup`, `dig`, `Resolve-DnsName` und die Namensauflösung einer Anwendung können unterschiedliche Auflösungswege oder Bibliotheken verwenden. Ergebnisse müssen im Kontext des Betriebssystems und der Anwendung bewertet werden. --- **24. Port und Dienst statt nur Host testen** Ein erreichbarer Host bestätigt nicht, dass der benötigte Dienst erreichbar ist. **Windows** ```powershell Test-NetConnection -Port 443 ``` **Linux und macOS** ```bash nc -vz 443 ``` **HTTP beziehungsweise HTTPS** ```bash curl -I https:// curl -v https:// ``` **TLS-Verbindung** ```bash openssl s_client -connect :443 -servername ``` Die Werkzeuge müssen auf dem jeweiligen System vorhanden sein. Vertrauliche Header, Tokens, Cookies und Zertifikatsdaten dürfen nicht ungeprüft in Tickets oder öffentliche Dokumentationen übernommen werden. **Mögliche Ergebnisse** | Ergebnis | mögliche Einordnung | |---|---| | Verbindung hergestellt | TCP-Verbindung zum Port grundsätzlich möglich | | Verbindung abgelehnt | Ziel erreichbar, aber Dienst nicht aktiv oder Port geschlossen | | Zeitüberschreitung | Filterung, Routing, Zielzustand oder Rückweg | | TLS-Fehler | Zertifikat, Protokollversion, SNI, Uhrzeit oder Inspektion | | HTTP `401` oder `403` | Dienst erreichbar, Authentifizierung oder Berechtigung erforderlich | | HTTP `404` | Webdienst erreichbar, angeforderte Ressource nicht gefunden | | HTTP `500` | serverseitiger Anwendungsfehler | | Umleitungsschleife | Proxy-, Anwendung-, TLS- oder URL-Konfiguration | --- **25. Lokale Firewall prüfen** Eine lokale Firewall kann eingehenden oder ausgehenden Verkehr abhängig von folgenden Merkmalen filtern: - Quell- und Zieladresse, - Protokoll, - Port, - Netzwerkprofil, - Schnittstelle, - Anwendung, - Benutzer, - Dienst, - Richtung, - Sicherheitsrichtlinie. **Windows** ```powershell Get-NetFirewallProfile Get-NetFirewallRule -Enabled True ``` **Linux** Je nach System können unter anderem verwendet werden: ```bash nft list ruleset iptables -S ufw status verbose firewall-cmd --state ``` **macOS** ```bash /usr/libexec/ApplicationFirewall/socketfilterfw --getglobalstate pfctl -s info ``` Zum Auslesen einzelner Firewallinformationen können erhöhte Rechte erforderlich sein. > Eine Firewall sollte nicht pauschal und dauerhaft deaktiviert werden. Besser ist ein zeitlich begrenzter, dokumentierter Test mit Freigabe oder die gezielte Auswertung von Protokollen und Regeln. --- **26. Netzwerk-Firewalls und ACLs berücksichtigen** Zwischen Client und Ziel können mehrere Filterinstanzen liegen: - Switch-ACL, - Router-ACL, - VLAN-Firewall, - Host-Firewall, - Standort-Firewall, - Cloud-Firewall, - Security Group, - Web Application Firewall, - Proxy, - VPN-Gateway, - Netzwerkzugangskontrolle. Zu prüfen sind: - Quelle, - Ziel, - Protokoll, - Quellport, - Zielport, - Richtung, - Zeitstempel, - zustandsbehaftete Sitzung, - NAT-Übersetzung, - passende Regel, - Regelreihenfolge, - Protokolleintrag, - Rückweg. Eine scheinbar passende Freigaberegel kann wirkungslos sein, wenn: - eine frühere Regel den Verkehr blockiert, - die falsche Zone verwendet wird, - die tatsächliche Quelladresse durch NAT verändert wurde, - die Anwendung einen zusätzlichen Port benötigt, - der Rückweg fehlt, - IPv6 anders behandelt wird als IPv4. --- **27. Proxy-Konfiguration untersuchen** Ein Proxy kann nur bestimmte Anwendungen oder Protokolle beeinflussen. Deshalb kann beispielsweise `ping` funktionieren, während der Browser keine Website öffnet. Zu prüfen sind: - manueller Proxy, - automatisch erkannter Proxy, - PAC-Datei, - systemweiter Proxy, - anwendungseigener Proxy, - Authentifizierung, - Ausnahmeliste, - HTTPS-Inspektion, - Erreichbarkeit des Proxyservers, - Namensauflösung des Proxys, - Zertifikatsvertrauen, - Umgebungsvariablen. **Windows** ```powershell netsh winhttp show proxy Get-ItemProperty "HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings" ``` **Linux und macOS** ```bash env | grep -i proxy ``` **macOS zusätzlich** ```bash scutil --proxy ``` Sensible Inhalte aus PAC-Dateien, Proxyadressen oder Zugangsdaten dürfen nicht ungeschützt dokumentiert werden. --- **28. VPN als eigene Fehlerdomäne behandeln** Ein VPN verändert möglicherweise: - Routingtabelle, - Standardroute, - DNS-Server, - Suchdomänen, - MTU, - Firewallregeln, - Proxykonfiguration, - Quelladresse, - erreichbare Netze. **Vergleichstests** ```text ohne VPN → mit VPN → internes Ziel → externes Ziel → Ziel per IP → Ziel per Namen → Routingtabelle vorher und nachher → DNS-Konfiguration vorher und nachher ``` **Typische VPN-Probleme** - überlappende lokale und entfernte Netze, - fehlende Route, - falsches Split Tunneling, - gesamter Verkehr unerwartet durch den Tunnel, - interner DNS-Server nicht erreichbar, - MTU- oder Fragmentierungsproblem, - abgelaufenes Zertifikat, - fehlgeschlagene Authentifizierung, - lokale Firewallregel, - instabile Internetverbindung, - fehlerhafter VPN-Adapter. --- **29. MTU- und Fragmentierungsprobleme** Ein Pfad kann kleine Pakete übertragen, während größere Übertragungen scheitern oder hängen bleiben. Mögliche Symptome sind: - Ping mit kleinen Paketen funktioniert, - Webseiten laden nur teilweise, - Dateiübertragungen bleiben stehen, - VPN-Verbindungen sind instabil, - TLS-Verbindungen brechen ab, - einzelne Anwendungen funktionieren, andere nicht. Mögliche Ursachen: - ungeeignete MTU, - VPN-Overhead, - PPPoE-Overhead, - blockierte ICMP-Meldungen für Path MTU Discovery, - Tunnel oder Kapselung, - fehlerhafte Fragmentierungsbehandlung. **Windows – Beispieltest** ```powershell ping -f -l ``` **Linux – Beispieltest** ```bash ping -M do -s ``` Die geeignete Nutzlastgröße hängt vom Protokoll, Betriebssystem und Pfad ab. Ein einzelner Testwert darf nicht ohne Einordnung als allgemeingültige MTU übernommen werden. --- **30. Mehrere aktive Netzwerkadapter** Ein Client kann gleichzeitig verbunden sein über: - Ethernet, - WLAN, - Mobilfunk, - VPN, - virtuelle Maschine, - Container-Bridge, - USB-Netzwerkadapter, - Dockingstation, - Host-only-Netz, - virtuelle Switches. Dadurch können entstehen: - mehrere Standardrouten, - unerwartete Metriken, - falscher DNS-Server, - asymmetrisches Routing, - Namensauflösung über die falsche Schnittstelle, - falsche Quelladresse, - nicht erreichbare lokale Netze, - VPN-Konflikte. **Kontrollierter Test** 1. aktuelle Adapter und Routen dokumentieren. 2. tatsächlich verwendete Route zum Ziel bestimmen. 3. nicht benötigte Verbindung nur mit Freigabe vorübergehend trennen. 4. Test wiederholen. 5. ursprünglichen Zustand wiederherstellen. 6. Ursache dauerhaft in der Adapter-, Routing- oder VPN-Konfiguration beheben. --- **31. Vergleichstests richtig verwenden** Ein guter Vergleichstest verändert nur eine relevante Komponente. Mögliche Vergleichskomponenten sind: - geprüftes Netzwerkkabel, - anderer Switchport, - andere Datendose, - anderer Netzwerkadapter, - andere Dockingstation, - anderer Client, - anderer Benutzer, - anderes VLAN, - anderes WLAN, - anderes Ziel, - Verbindung ohne VPN, - Verbindung ohne Proxy, - direkte Verbindung statt Dockingstation. **Beispiel** ```text Ursprünglich: Client A + Dock A + Kabel A + Dose A → Fehler Vergleich 1: Client A + Dock A + geprüftes Kabel B + Dose A → Fehler Vergleich 2: Client A + Dock B + geprüftes Kabel B + Dose A → funktioniert ``` Damit wird Dock A zum Hauptverdacht. Vor dem endgültigen Austausch sollte das Ergebnis reproduziert und die übrige Konfiguration verglichen werden. > Wenn bei einem Test gleichzeitig Kabel, Port, Dock und Benutzer gewechselt werden, lässt sich aus dem Erfolg keine einzelne Ursache ableiten. --- **32. Paketaufzeichnung gezielt einsetzen** Wenn Statusanzeigen und Standardtests keine ausreichende Erklärung liefern, kann eine Paketaufzeichnung zeigen, welche Kommunikation tatsächlich stattfindet. Geeignete Werkzeuge sind beispielsweise: - Wireshark, - `tcpdump`, - `tshark`, - Windows-Paketaufzeichnungswerkzeuge, - Port Mirroring beziehungsweise SPAN, - Capture-Funktionen auf Firewalls, Routern oder Access Points. **Mögliche Fragestellungen** - verlässt eine DHCP-Anfrage den Client? - antwortet ein DHCP-Server? - wird eine ARP-Anfrage beantwortet? - erfolgt eine DNS-Anfrage? - welcher DNS-Server antwortet? - wird ein TCP-SYN gesendet? - kommt ein SYN-ACK oder RST zurück? - findet eine TLS-Aushandlung statt? - treten Wiederholungen oder Zeitüberschreitungen auf? - wird ICMP zur Fehleranzeige zurückgesendet? - kommuniziert die Anwendung mit dem erwarteten Ziel? **Beispielhafte Filter** ```text arp dhcp dns icmp icmpv6 tcp.port == 443 ip.addr == 192.0.2.10 ``` **Datenschutz und Sicherheit** Paketaufzeichnungen können enthalten: - IP-Adressen, - Hostnamen, - Benutzernamen, - Sitzungsdaten, - DNS-Anfragen, - unverschlüsselte Inhalte, - Authentifizierungsinformationen, - interne Systemstrukturen. Aufzeichnungen dürfen nur mit Berechtigung erstellt, auf das erforderliche Zeitfenster begrenzt, sicher gespeichert und kontrolliert weitergegeben werden. --- **33. Typische TCP-Beobachtungen** **Erfolgreicher Verbindungsaufbau** ```text Client → Server: SYN Server → Client: SYN, ACK Client → Server: ACK ``` **Port geschlossen** ```text Client → Server: SYN Server → Client: RST, ACK ``` **Keine sichtbare Antwort** ```text Client → Server: SYN Client → Server: erneutes SYN Client → Server: weiteres SYN ``` Mögliche Ursachen für eine ausbleibende Antwort sind: - Filterung, - Ziel nicht erreichbar, - Rückroute fehlt, - Server antwortet nicht, - Paket erreicht das Ziel nicht, - Antwort erreicht den Client nicht. Eine Paketaufzeichnung an nur einer Stelle zeigt nicht automatisch, an welcher Stelle des gesamten Pfades das Paket verloren geht. --- **34. Ereignisprotokolle gemeinsam auswerten** Relevante Quellen können sein: - Client-Ereignisprotokolle, - NetworkManager- oder Systemprotokolle, - DHCP-Serverprotokolle, - DNS-Protokolle, - Switch- und Routerprotokolle, - Firewallprotokolle, - VPN-Protokolle, - Proxyprotokolle, - Access-Point- und Controllerprotokolle, - Authentifizierungsserver, - Zielserverprotokolle, - Monitoringdaten. Alle Ereignisse sollten anhand eines möglichst genauen Zeitstempels zusammengeführt werden. **Zeitbezug** ```text 14:31:02 Client verliert Link 14:31:04 Switchport meldet Down 14:31:09 Switchport meldet Up 14:31:11 DHCP Discover 14:31:11 DHCP Offer 14:31:12 DHCP Request 14:31:12 DHCP ACK 14:31:14 DNS-Anfrage erfolgreich ``` Diese zeitliche Korrelation liefert stärkere Hinweise als voneinander getrennte Einzelmeldungen. --- **35. Praxisfall A: Client erhält eine Adresse aus 169.254.0.0/16** **Symptom** - Link ist aktiv. - Client besitzt `169.254.37.18/16`. - Standardgateway fehlt. - interne und externe Ziele sind nicht erreichbar. **Prüfung** 1. Adapterstatus dokumentieren. 2. Switchport und VLAN bestimmen. 3. anderes Gerät am selben Anschluss testen. 4. DHCP-Lease und DHCP-Clientprotokoll prüfen. 5. DHCP-Ablauf aufzeichnen. 6. Switch-Sicherheitsfunktionen prüfen. 7. DHCP-Relay kontrollieren. 8. DHCP-Bereich und freie Adressen prüfen. 9. Änderung einzeln durchführen. 10. neue Adressvergabe und Erreichbarkeit kontrollieren. **Mögliche Ursache** Der Switchport wurde nach einem Arbeitsplatzwechsel dem falschen VLAN zugeordnet. Der DHCP-Broadcast erreicht dadurch nicht den DHCP-Relay des vorgesehenen Clientnetzes. **Nachprüfung** - richtige IPv4-Adresse erhalten, - Gateway vorhanden, - geeignete DNS-Server vorhanden, - internes Ziel erreichbar, - externer Dienst erreichbar, - erneute Adressvergabe erfolgreich, - Portkonfiguration dokumentiert. --- **36. Praxisfall B: IP-Ziele funktionieren, DNS-Namen nicht** **Symptom** - Standardgateway erreichbar. - internes Ziel über IP-Adresse erreichbar. - Name `intranet.example.internal` wird nicht aufgelöst. **Prüfung** 1. konfigurierte DNS-Server dokumentieren. 2. DNS-Server per IP testen. 3. Namen über jeden DNS-Server einzeln abfragen. 4. DNS-Suffix und Suchdomäne prüfen. 5. VPN- und Split-DNS-Konfiguration vergleichen. 6. DNS-Zone und Resource Record prüfen. 7. Cache nur bei begründetem Verdacht kontrolliert leeren. 8. Auflösung und Anwendung erneut testen. **Mögliche Ursache** Nach dem Aufbau des VPN wird weiterhin ein öffentlicher DNS-Server verwendet. Dieser kennt die interne Zone nicht. **Nachprüfung** - interner Name wird korrekt aufgelöst, - erwartete IP-Adresse wird geliefert, - Anwendung erreicht das Ziel, - öffentliche Namensauflösung funktioniert weiterhin, - Verhalten nach erneuter VPN-Verbindung bleibt korrekt. --- **37. Praxisfall C: Website antwortet nicht, Ping funktioniert** **Symptom** - Zielname wird korrekt aufgelöst. - Ping zum Ziel ist erfolgreich. - HTTPS-Verbindung scheitert. **Prüfung** 1. aufgelöste Zieladresse dokumentieren. 2. TCP-Port 443 testen. 3. Pfad zum Ziel untersuchen. 4. lokale und zentrale Firewallprotokolle prüfen. 5. Proxykonfiguration prüfen. 6. TLS-Verbindung untersuchen. 7. Dienstzustand am Ziel prüfen. 8. Vergleich von internem und externem Zugriff durchführen. **Mögliche Ergebnisse** | Ergebnis | Einordnung | |---|---| | TCP-Port 443 abgelehnt | Host erreichbar, Dienst nicht aktiv oder Port geschlossen | | TCP-Verbindung läuft in Timeout | Firewall, Routing oder Rückweg | | TLS-Zertifikat abgelaufen | Transport funktioniert, TLS-Vertrauen scheitert | | Proxy meldet Zugriff verweigert | Proxyregel oder Berechtigung | | HTTP `503` | Webdienst oder nachgelagerter Dienst nicht verfügbar | | direkter Zugriff funktioniert, Proxyzugriff nicht | Proxykonfiguration oder Proxyzustand | --- **38. Praxisfall D: Nur über die Dockingstation kein Netzwerk** **Symptom** - WLAN funktioniert. - integrierter Netzwerkanschluss beziehungsweise anderer Adapter funktioniert. - Ethernet über die Dockingstation fällt wiederholt aus. **Prüfung** 1. Dockmodell und Anschlussart dokumentieren. 2. Linkstatus und Fehlerzähler prüfen. 3. Stromversorgung des Docks kontrollieren. 4. geprüftes Kabel verwenden. 5. anderen USB-C- beziehungsweise Thunderbolt-Anschluss testen. 6. Vergleichsdock verwenden. 7. Treiber- und Firmwarestand nach Herstellerangabe prüfen. 8. Energiesparverhalten untersuchen. 9. Ereignisprotokolle zum Zeitpunkt der Trennung auswerten. 10. Langzeittest nach der Maßnahme durchführen. **Mögliche Ursachen** - instabile Stromversorgung, - Dock-Firmware, - Treiber, - USB-Verbindung, - defekter Netzwerkcontroller, - ungeeignetes Kabel, - Energiesparzustand, - thermisches Problem. --- **39. Praxisfall E: Interne Systeme funktionieren nur ohne VPN** **Symptom** - ohne VPN sind lokale Systeme erreichbar. - nach dem VPN-Aufbau sind bestimmte lokale Netze nicht erreichbar. - Internetzugriff funktioniert weiterhin. **Prüfung** 1. Routingtabelle vor VPN-Verbindung sichern. 2. Routingtabelle nach VPN-Verbindung sichern. 3. DNS-Konfiguration vergleichen. 4. Zielnetz und lokales Clientnetz vergleichen. 5. überlappende Präfixe suchen. 6. verwendete Route zum Ziel bestimmen. 7. Split-Tunneling-Richtlinie prüfen. 8. VPN-Firewall- und Zugriffsrichtlinien prüfen. 9. kontrollierten Test mit geeignetem nicht überlappendem Netz durchführen. 10. dauerhafte Netz- oder VPN-Konfiguration korrigieren. **Mögliche Ursache** Das lokale Netz und ein entferntes Unternehmensnetz verwenden dasselbe IPv4-Präfix. Der Client kann nicht eindeutig bestimmen, ob das Ziel lokal oder über den VPN-Tunnel erreichbar ist. --- **40. Ungeeignete Sofortmaßnahmen** Folgende Maßnahmen können Spuren vernichten, neue Fehler erzeugen oder den ursprünglichen Zustand unklar machen: - Client sofort neu starten, - Switchport ohne Dokumentation umkonfigurieren, - Netzwerkadapter zurücksetzen, - alle gespeicherten WLAN-Profile löschen, - DHCP-Adresse mehrfach ungeprüft erneuern, - DNS-Cache ohne vorherige Prüfung leeren, - Firewall vollständig deaktivieren, - IPv6 pauschal abschalten, - VPN-Client neu installieren, - Netzwerkstack zurücksetzen, - Treiber ungeprüft ersetzen, - mehrere Kabel und Ports gleichzeitig wechseln, - statische Adresse als dauerhafte Umgehung eintragen, - Router oder Switch ohne Freigabe neu starten. Solche Maßnahmen sind nicht grundsätzlich verboten. Sie müssen jedoch begründet, freigegeben, dokumentiert und anschließend vollständig überprüft werden. --- **41. Häufige Fehlinterpretationen** | Aussage | fachliche Einordnung | |---|---| | „Der Link leuchtet, also funktioniert das Netzwerk.“ | Ein Link bestätigt keine gültige IP-Konfiguration oder Ende-zu-Ende-Verbindung. | | „Der Client hat eine IP-Adresse, also funktioniert DHCP.“ | Die Adresse kann statisch, veraltet, link-local oder aus dem falschen Netz sein. | | „Das Gateway antwortet nicht auf Ping, also ist es ausgefallen.“ | ICMP-Echo kann gefiltert oder deaktiviert sein. | | „Ping funktioniert, also liegt es an der Anwendung.“ | Der benötigte Dienst, Port, DNS, Proxy oder TLS kann weiterhin fehlerhaft sein. | | „Eine Website funktioniert, also funktioniert DNS.“ | Die Adresse kann aus einem Cache stammen oder die Anwendung kann einen anderen Resolver verwenden. | | „Eine Adresse aus 169.254.0.0/16 beweist einen defekten DHCP-Server.“ | VLAN, Relay, Switchport, Client oder Sicherheitsfunktionen können ursächlich sein. | | „Traceroute endet an Router X, also ist Router X defekt.“ | Router können Antworten filtern, obwohl sie Daten weiterhin übertragen. | | „Ohne Firewall funktioniert es, also muss sie dauerhaft deaktiviert bleiben.“ | Die konkrete Regel oder Zuordnung muss ermittelt und gezielt korrigiert werden. | | „Ein anderes Kabel funktioniert, also ist ausschließlich das ursprüngliche Kabel defekt.“ | Auch Kontakte, Position oder mechanische Belastung wurden verändert. | | „Nach dem Neustart funktioniert es, also ist der Fehler behoben.“ | Ein Neustart kann Symptome beseitigen, ohne die Ursache zu erklären. | | „IPv4 funktioniert, also ist die gesamte Netzwerkverbindung in Ordnung.“ | Anwendungen können IPv6 bevorzugen oder beide Protokolle verwenden. | | „Der Fehler liegt sicher beim Provider.“ | Lokale Verbindung, DNS, Routing, Firewall und Zielsystem müssen getrennt geprüft werden. | --- **42. Vollständige Prüfreihenfolge** 1. genaue Anwendung, Zieladresse und Fehlermeldung bestimmen. 2. Zeitpunkt und letzte bekannte Funktion dokumentieren. 3. betroffene Benutzer, Clients, Netze und Standorte bestimmen. 4. Ethernet, WLAN, VPN und Proxy unterscheiden. 5. Ausgangskonfiguration sichern. 6. physische Verbindung beziehungsweise WLAN-Zustand prüfen. 7. Netzwerkadapter und Fehlerzähler untersuchen. 8. IPv4- und IPv6-Konfiguration bewerten. 9. DHCP-Zustand prüfen. 10. lokale Routingtabelle auswerten. 11. ARP beziehungsweise Neighbor Discovery kontrollieren. 12. Standardgateway und lokales Netz untersuchen. 13. entferntes Ziel gezielt per IP-Adresse testen. 14. DNS-Auflösung separat prüfen. 15. konkreten Zielport und Dienst testen. 16. Pfad bei Bedarf mit Traceroute untersuchen. 17. lokale Firewall, zentrale Firewall und ACLs berücksichtigen. 18. Proxy- und VPN-Konfiguration vergleichen. 19. System-, Netzwerk- und Serverprotokolle zeitlich korrelieren. 20. bei Bedarf eine autorisierte Paketaufzeichnung erstellen. 21. kontrollierten Vergleichstest mit nur einer Änderung durchführen. 22. Hypothese anhand der Ergebnisse bestätigen oder verwerfen. 23. freigegebene Korrektur umsetzen. 24. ursprünglichen Test wiederholen. 25. verwandte Funktionen und mögliche Nebenwirkungen prüfen. 26. Ursache, Maßnahme und Nachweis dokumentieren. --- **43. Dokumentationsbeispiel** ```text Ticket: INC-20481 Zeitpunkt: 01.08.2026, 09:18 Uhr Client: NB-204 Standort: Gebäude B, Raum 204 Anschluss: Dockingstation über Ethernet Symptom: keine internen oder externen Ziele erreichbar Ausgangszustand: - physischer Link aktiv - IPv4-Adresse 169.254.37.18/16 - kein Standardgateway - kein verwendbarer DNS-Server - WLAN deaktiviert - anderer Client an derselben Dose ebenfalls ohne DHCP-Adresse Hypothese: Der Switchport befindet sich nach dem Arbeitsplatzwechsel im falschen VLAN. Prüfung: - Portbezeichnung mit Dokumentation verglichen - tatsächliche VLAN-Zuordnung am Switch geprüft - DHCP-Verkehr im zugewiesenen VLAN kontrolliert - Port war dem Drucker-VLAN statt dem Client-VLAN zugeordnet Ursache: Fehlerhafte VLAN-Zuordnung des Switchports nach einer Portänderung. Maßnahme: Switchport nach Freigabe dem vorgesehenen Client-VLAN zugeordnet. Nachprüfung: - DHCP-Adresse aus dem vorgesehenen Clientnetz erhalten - Standardgateway und DNS-Server korrekt - internes Ziel per IP erreichbar - interne DNS-Auflösung erfolgreich - HTTPS-Anwendung erreichbar - erneute DHCP-Adressvergabe erfolgreich - Switchport und Dokumentation stimmen überein Nebenwirkungen: Keine Auffälligkeiten an benachbarten Ports oder im vorgesehenen VLAN festgestellt. ``` --- **44. Checkliste Client ohne Netzwerkverbindung** - [ ] konkrete Fehlermeldung wurde erfasst. - [ ] betroffene Anwendung und Zieladresse sind bekannt. - [ ] Beginn und letzte bekannte Funktion wurden dokumentiert. - [ ] vorausgegangene Änderungen wurden erfragt. - [ ] Umfang der Störung wurde bestimmt. - [ ] Ethernet, WLAN, VPN und Proxy wurden unterschieden. - [ ] Ausgangszustand wurde vor Änderungen gesichert. - [ ] physischer Link beziehungsweise WLAN-Status wurde geprüft. - [ ] Netzwerkadapter und Treiberstatus wurden kontrolliert. - [ ] Fehler- und Verwerfungszähler wurden geprüft. - [ ] IPv4-Adresse und Präfix wurden bewertet. - [ ] IPv6-Konfiguration wurde berücksichtigt. - [ ] Standardgateway wurde geprüft. - [ ] DNS-Server wurden dokumentiert. - [ ] DHCP-Status und Lease wurden untersucht. - [ ] ARP beziehungsweise Neighbor Discovery wurde geprüft. - [ ] Routingtabelle wurde ausgewertet. - [ ] lokales und entferntes Ziel wurden unterschieden. - [ ] Ziel wurde kontrolliert per IP-Adresse getestet. - [ ] DNS-Auflösung wurde separat getestet. - [ ] benötigter Port und Dienst wurden geprüft. - [ ] Ping-Ergebnisse wurden nicht überbewertet. - [ ] Traceroute-Ergebnisse wurden fachlich eingeordnet. - [ ] lokale Firewall wurde berücksichtigt. - [ ] zentrale Firewall und ACLs wurden berücksichtigt. - [ ] Proxykonfiguration wurde geprüft. - [ ] VPN-Routen und VPN-DNS wurden geprüft. - [ ] mehrere aktive Adapter wurden berücksichtigt. - [ ] kontrollierter Vergleichstest veränderte nur eine Komponente. - [ ] Paketaufzeichnung erfolgte nur mit Berechtigung. - [ ] Protokolle wurden anhand der Zeitstempel korreliert. - [ ] Ursache wurde von Symptom und Vermutung getrennt. - [ ] Änderung wurde freigegeben und dokumentiert. - [ ] ursprünglicher Test wurde nach der Maßnahme wiederholt. - [ ] verwandte Funktionen und Nebenwirkungen wurden geprüft. - [ ] Ursache, Maßnahme und Ergebnis wurden dokumentiert. --- **45. Schnellreferenz** | Prüfschritt | geeignete Information | typische Auffälligkeit | |---|---|---| | Umfang | betroffene Clients, Dienste und Standorte | mehrere Geräte oder nur eine Anwendung | | Verbindung | Link, SSID, Authentifizierung | Link down oder falsches WLAN | | Adapter | Zustand, Treiber, Fehlerzähler | deaktiviert, instabil oder hohe Fehler | | IPv4 | Adresse, Präfix, Gateway | `169.254.0.0/16`, falsches Netz oder kein Gateway | | IPv6 | Adresse, Route, Neighbor | nur Link-Local oder fehlende Standardroute | | DHCP | Server, Lease, Optionen | kein Offer, falsche Optionen oder erschöpfter Bereich | | Layer 2 | ARP, Neighbor, VLAN | unvollständiger Eintrag oder falsches VLAN | | Routing | Route, Gateway, Metrik | falsche oder fehlende Route | | DNS | Server, Antwort, Record | Timeout, `NXDOMAIN` oder falsche Adresse | | Transport | Zielport und TCP-Zustand | Timeout, RST oder TLS-Fehler | | Firewall | Regel und Protokoll | Blockierung der tatsächlichen Quelle oder Zone | | Proxy | PAC, Authentifizierung, Ausnahme | Browser betroffen, andere Tests erfolgreich | | VPN | Routen, DNS und MTU | Netzüberlappung oder falsches Split Tunneling | | Zielsystem | Dienst und Protokoll | Port geschlossen oder Anwendung fehlerhaft | | Nachprüfung | ursprünglicher Test | Symptom beseitigt und keine Nebenwirkungen | --- **Merksatz** > „Kein Netzwerk“ ist keine Ursache, sondern eine ungenaue Symptombeschreibung. Eine belastbare Analyse bestimmt zuerst den Umfang und prüft anschließend kontrolliert Verbindung, Adapter, IP-Konfiguration, DHCP, lokales Netz, Gateway, Routing, DNS, Zielport und Anwendung. Jeder erfolgreiche Test bestätigt nur den tatsächlich geprüften Teil des Kommunikationswegs. --- **Quellen und weiterführende Dokumentation** - [Microsoft Learn – Get-NetIPConfiguration](https://learn.microsoft.com/powershell/module/nettcpip/get-netipconfiguration) - [Microsoft Learn – Get-NetAdapter](https://learn.microsoft.com/powershell/module/netadapter/get-netadapter) - [Microsoft Learn – Get-NetRoute](https://learn.microsoft.com/powershell/module/nettcpip/get-netroute) - [Microsoft Learn – Resolve-DnsName](https://learn.microsoft.com/powershell/module/dnsclient/resolve-dnsname) - [Microsoft Learn – Test-NetConnection](https://learn.microsoft.com/powershell/module/nettcpip/test-netconnection) - [Microsoft Learn – Windows-Befehle für TCP/IP-Diagnose](https://learn.microsoft.com/windows-server/administration/windows-commands/windows-commands) - [Red Hat – NetworkManager mit nmcli verwalten](https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/configuring_and_managing_networking/) - [Apple – networksetup Manual Page](https://ss64.com/mac/networksetup.html) - [Wireshark – Benutzerhandbuch](https://www.wireshark.org/docs/wsug_html_chunked/) - [Wireshark – Display Filter Reference](https://www.wireshark.org/docs/dfref/) - [RFC 2131 – Dynamic Host Configuration Protocol](https://www.rfc-editor.org/rfc/rfc2131) - [RFC 3927 – Dynamic Configuration of IPv4 Link-Local Addresses](https://www.rfc-editor.org/rfc/rfc3927) - [RFC 8200 – Internet Protocol, Version 6](https://www.rfc-editor.org/rfc/rfc8200) - [RFC 4861 – Neighbor Discovery for IPv6](https://www.rfc-editor.org/rfc/rfc4861) - [RFC 826 – Address Resolution Protocol](https://www.rfc-editor.org/rfc/rfc826) - [RFC 1034 – Domain Names: Concepts and Facilities](https://www.rfc-editor.org/rfc/rfc1034) - [RFC 1035 – Domain Names: Implementation and Specification](https://www.rfc-editor.org/rfc/rfc1035) # 6.2 Mehrere Clients oder ganzer Standort ohne Netzwerk Wenn mehrere Clients, eine Abteilung, ein Stockwerk, ein Gebäude oder ein kompletter Standort gleichzeitig keine Netzwerkverbindung besitzen, ist ein unabhängiger Fehler an jedem einzelnen Endgerät unwahrscheinlich. Der gemeinsame Ausfallbereich rückt in den Mittelpunkt. Mögliche gemeinsame Komponenten sind: - Access Switch, - Switch-Uplink, - VLAN, - WLAN-SSID, - Access Point oder WLAN-Controller, - Standardgateway, - DHCP-Dienst, - DNS-Dienst, - Firewall, - Router, - WAN-Verbindung, - VPN-Tunnel, - Internetanschluss, - Stromversorgung, - zentrale Authentifizierung, - Netzwerkzugangskontrolle, - Providerverbindung, - gemeinsame Konfigurationsänderung. Das Ziel der Fehleranalyse besteht darin, den kleinsten gemeinsamen Ausfallbereich zu bestimmen und anschließend die darin enthaltenen Komponenten kontrolliert zu prüfen. > Je mehr Systeme gleichzeitig betroffen sind, desto wichtiger ist die Frage, welche technische Komponente oder Abhängigkeit sie gemeinsam verwenden. --- **1. Mehrere betroffene Clients verändern die Fehlerhypothese** Bei einem einzelnen betroffenen Client sind lokale Ursachen besonders wahrscheinlich: - Netzwerkkabel, - Netzwerkadapter, - Dockingstation, - lokale IP-Konfiguration, - lokaler Treiber, - lokale Firewall, - Betriebssystem, - Benutzerprofil. Bei mehreren gleichzeitig betroffenen Clients werden gemeinsame Ursachen wahrscheinlicher: - gemeinsamer Switch, - gemeinsamer Uplink, - gemeinsames VLAN, - gemeinsames Gateway, - gemeinsamer DHCP-Server, - gemeinsamer DNS-Server, - gemeinsamer WLAN-Bereich, - gemeinsame Firewall, - gemeinsame Standortanbindung, - gemeinsame Änderung. Lokale Clienttests bleiben wichtig. Sie dienen nun jedoch vor allem dazu, den gemeinsamen Fehlerumfang zu bestätigen und Unterschiede zwischen funktionierenden und nicht funktionierenden Bereichen zu erkennen. --- **2. Störungsumfang exakt bestimmen** Die Aussage „Der Standort hat kein Netzwerk“ ist zunächst nur eine ungenaue Symptombeschreibung. Zu klären sind: - Wie viele Benutzer melden den Fehler? - Wie viele Clients wurden tatsächlich geprüft? - Sind alle Geräte oder nur einzelne Gerätetypen betroffen? - Betrifft der Fehler Ethernet, WLAN oder beide? - Sind Drucker, Telefone, Kameras und andere Netzwerkgeräte betroffen? - Betrifft der Fehler nur einen Raum? - Betrifft er eine Etage? - Betrifft er ein Gebäude? - Betrifft er ein VLAN? - Betrifft er eine bestimmte SSID? - Betrifft er einen kompletten Standort? - Sind weitere Standorte betroffen? - Funktionieren interne Ziele? - Funktioniert das Internet? - Funktioniert die Namensauflösung? - Sind nur einzelne Anwendungen ausgefallen? - Können bestehende Verbindungen weiterarbeiten? - Scheitern nur neue Verbindungen? - Ist der Ausfall vollständig oder treten Paketverluste und Unterbrechungen auf? Eine belastbare Aussage lautet beispielsweise: ```text Seit etwa 09:17 Uhr können alle bisher geprüften kabelgebundenen Clients der dritten Etage weder das Standardgateway noch interne Dienste erreichen. WLAN-Clients derselben Etage funktionieren. Andere Etagen sind nicht betroffen. ``` Diese Beschreibung grenzt den Fehler erheblich stärker ein als „Netzwerk ausgefallen“. --- **3. Betroffenheitsmatrix erstellen** Eine einfache Matrix hilft, Gemeinsamkeiten zu erkennen. | Bereich | Ethernet | WLAN | interne Dienste | Internet | DNS | |---|---:|---:|---:|---:|---:| | Etage 1 | funktioniert | funktioniert | funktioniert | funktioniert | funktioniert | | Etage 2 | funktioniert | funktioniert | funktioniert | funktioniert | funktioniert | | Etage 3 | ausgefallen | funktioniert | ausgefallen | ausgefallen | nicht sinnvoll prüfbar | | Etage 4 | funktioniert | funktioniert | funktioniert | funktioniert | funktioniert | Aus diesem Beispiel ergibt sich: - kein standortweiter Ausfall, - kein allgemeiner Internet- oder DNS-Ausfall, - kein vollständiger Ausfall des zentralen Gateways, - wahrscheinlicher Fehler im kabelgebundenen Zugangsnetz der dritten Etage, - möglicher Access-Switch-, Uplink-, VLAN- oder Stromversorgungsfehler. Eine solche Matrix sollte nicht nur auf Benutzerangaben beruhen. Repräsentative Tests müssen die Angaben bestätigen. --- **4. Zeitpunkt und zeitlichen Verlauf ermitteln** Zu dokumentieren sind: - erster bekannter Fehlerzeitpunkt, - letzte bekannte fehlerfreie Nutzung, - gleichzeitiger oder schrittweiser Ausfall, - dauerhafter oder sporadischer Fehler, - Zeitpunkt automatischer Monitoringmeldungen, - Zeitpunkt letzter Änderungen, - Zeitpunkt von Strom-, Klima- oder Providerereignissen, - Wiederkehr in bestimmten Zeitabständen, - Abhängigkeit von Last oder Benutzeranzahl. **Mögliche zeitliche Muster** | Beobachtung | mögliche Einordnung | |---|---| | alle Clients fallen gleichzeitig aus | gemeinsame zentrale Komponente oder Verbindung | | Clients fallen nacheinander aus | DHCP-Leases, instabiler Switch, Schleife, Überlastung oder Stromproblem | | nur morgens bei Arbeitsbeginn | DHCP-Bereich, Authentifizierung, WLAN-Kapazität oder Lastproblem | | kurze Ausfälle in regelmäßigen Abständen | Redundanzumschaltung, instabiler Link, Routingprozess oder geplante Aufgabe | | Fehler direkt nach Änderung | Änderung als starke Hypothese untersuchen | | Fehler bei hoher Netzlast | Überlastung, Broadcast-Sturm, fehlerhafter Link oder Kapazitätsgrenze | | Fehler nach Stromunterbrechung | Gerät, Netzteil, USV, Startreihenfolge oder nicht gespeicherte Konfiguration | Zeitliche Nähe beweist noch keine Ursache. Sie legt jedoch eine gezielte Prüfreihenfolge nahe. --- **5. Letzte Änderungen prüfen** Vor einer Änderung am Netzwerk ist zu prüfen, ob kurz vor Beginn der Störung etwas verändert wurde. Mögliche Änderungen sind: - Switch-Konfiguration, - VLAN-Zuordnung, - Trunk-Konfiguration, - Spanning-Tree-Konfiguration, - Link Aggregation, - Routing, - Firewallregeln, - NAT, - DHCP-Bereich, - DHCP-Relay, - DNS-Konfiguration, - WLAN-Controller, - Access-Point-Firmware, - Netzwerkzugangskontrolle, - Zertifikate, - Provideranschluss, - Verkabelung, - Patchfeld, - Stromversorgung, - Server- oder Netzwerkupdate, - Wartungsarbeiten, - Umzug von Geräten, - Anschluss eines neuen Switches, - Anschluss eines nicht autorisierten Geräts. Zu jeder Änderung gehören: - genauer Zeitpunkt, - verantwortliche Person oder System, - betroffene Komponenten, - erwartete Wirkung, - dokumentierter Ausgangszustand, - mögliche Rückfallmaßnahme, - tatsächliche Protokolleinträge. > Ein zeitlicher Zusammenhang macht eine Änderung verdächtig, ersetzt aber nicht den technischen Nachweis. --- **6. Priorität und Auswirkung bewerten** Ein Ausfall mehrerer Clients kann ein Major Incident sein, muss es aber nicht automatisch sein. Zu bewerten sind: - Anzahl betroffener Benutzer, - betroffene Geschäftsprozesse, - betroffene Standorte, - verfügbare Ausweichmöglichkeiten, - Sicherheitsauswirkungen, - Produktionsstillstand, - Ausfall kritischer Dienste, - vertragliche Verpflichtungen, - erwartete Dauer, - Gefahr einer Ausweitung, - Abhängigkeit externer Kunden oder Partner. **Beispielhafte Einordnung** | Situation | mögliche Auswirkung | |---|---| | ein Besprechungsraum ohne Netzwerk | lokal begrenzt | | gesamtes Stockwerk ohne Netzwerk | erhebliche Benutzerbeeinträchtigung | | Produktionsnetz ausgefallen | geschäftskritisch | | Standort ohne WAN, lokale Systeme funktionieren | standortübergreifende Dienste betroffen | | DNS unternehmensweit ausgefallen | sehr großer scheinbarer Netzwerkausfall | | redundanter Uplink ausgefallen, Verkehr läuft weiter | noch kein Benutzerausfall, aber Redundanz verloren | Die Priorität richtet sich nach Auswirkung und Dringlichkeit, nicht allein nach der Anzahl eingehender Tickets. --- **7. Kommunikation während einer größeren Störung** Bei einer größeren Störung müssen technische Analyse und Kommunikation parallel organisiert werden. Sinnvolle Aufgabenverteilung: - technische Koordination, - Prüfung des Zugangsnetzes, - Prüfung zentraler Dienste, - Prüfung von Firewall, WAN und Provider, - Dokumentation der Ereignisse, - Kommunikation mit Benutzern und Verantwortlichen, - Koordination externer Dienstleister. Eine Statusmeldung sollte enthalten: ```text Bekannter Umfang: Kabelgebundene Clients in Gebäude B sind betroffen. WLAN und andere Gebäude funktionieren. Beginn: Etwa 09:17 Uhr. Aktueller Stand: Der gemeinsame Uplink des Access-Bereichs wird geprüft. Nächste Aktualisierung: 10:00 Uhr oder bei einer wesentlichen Änderung. ``` Nicht bestätigt werden sollten Aussagen wie: - „Der Provider ist schuld.“ - „Die Firewall ist abgestürzt.“ - „Das Problem ist gleich behoben.“ - „Es gehen keine Daten verloren.“ Solche Aussagen dürfen erst erfolgen, wenn belastbare Nachweise vorliegen. --- **8. Repräsentative Testpunkte auswählen** Nicht jeder einzelne Client muss vollständig untersucht werden. Es werden gezielt Testpunkte ausgewählt. Geeignete Auswahl: - ein betroffener Client aus jedem gemeldeten Bereich, - ein funktionierender Client aus einem benachbarten Bereich, - ein kabelgebundener und ein drahtloser Client, - ein Client im gleichen VLAN, - ein Client in einem anderen VLAN, - ein infrastrukturelles Gerät im betroffenen Bereich, - ein Test direkt am Access Switch, - ein Test hinter dem vermuteten Uplink, - ein Test am zentralen Standort. **Beispiel** ```text Client A: Etage 3, Switch 3A, VLAN 120 → betroffen Client B: Etage 3, Switch 3B, VLAN 120 → betroffen Client C: Etage 3, WLAN, VLAN 220 → funktioniert Client D: Etage 2, VLAN 120 → funktioniert ``` Damit liegt der Verdacht nicht automatisch beim gesamten VLAN 120. Wahrscheinlicher ist zunächst eine Komponente, die nur die kabelgebundene Versorgung der dritten Etage betrifft. --- **9. Gemeinsame Abhängigkeiten abbilden** Für die betroffenen Clients sollte der Kommunikationsweg vereinfacht dargestellt werden. ```text Clients → Access Switch → Uplink → Distribution Switch → VLAN-Gateway → Firewall oder Router → WAN beziehungsweise Internet → Zielsystem ``` Für WLAN kann der Weg abweichen: ```text WLAN-Client → Access Point → Access Switch → WLAN-Controller oder lokales Switching → VLAN-Gateway → Firewall oder Router → Zielsystem ``` Für jeden Abschnitt wird geprüft: - Nutzen alle betroffenen Clients diese Komponente? - Nutzen funktionierende Clients dieselbe Komponente? - Ist die Komponente erreichbar? - Sind Fehler oder Zustandsänderungen protokolliert? - Besteht eine redundante Verbindung? - Arbeitet die Redundanz tatsächlich? - Wurde die Konfiguration verändert? --- **10. Ausfallbereich durch funktionierende Grenzen bestimmen** Nicht nur fehlgeschlagene Tests sind wichtig. Funktionierende Bereiche bilden Grenzen des Fehlers. **Beispiel** ```text Clients an Switch A → ausgefallen Clients an Switch B → funktionieren beide verwenden dasselbe Gateway beide verwenden dieselben DNS-Server beide verwenden dieselbe Firewall ``` Dadurch werden Gateway, DNS und Firewall als alleinige gemeinsame Ursache weniger wahrscheinlich. Der Untersuchungsbereich verschiebt sich zu: - Switch A, - dessen Uplink, - dessen VLAN-Weiterleitung, - dessen Stromversorgung, - dessen lokale Verkabelung. Ein funktionierender Bereich schließt eine Komponente allerdings nur dann sinnvoll aus, wenn tatsächlich dieselbe Instanz, derselbe Pfad und dieselbe Konfiguration verwendet werden. --- **11. Stromversorgung und Umgebungsbedingungen prüfen** Ein Netzwerkausfall kann durch einen Strom- oder Umgebungsfehler verursacht werden. Zu prüfen sind: - besitzt der Netzwerkschrank Strom? - ist die USV aktiv? - bestehen USV-Alarme? - sind Sicherungen ausgelöst? - funktionieren Netzteile und redundante Netzteile? - sind Power Distribution Units aktiv? - ist der Switch vollständig gestartet? - bestehen Temperaturalarme? - funktioniert die Kühlung? - wurden Geräte versehentlich ausgeschaltet? - sind PoE-Verbraucher ausgefallen? - wurde das Strombudget überschritten? - gibt es auffälligen Geruch, Hitze oder Geräusche? Bei ausgefallener PoE-Versorgung können gleichzeitig betroffen sein: - Access Points, - IP-Telefone, - Kameras, - Zutrittskomponenten, - Sensoren. Ein aktiver Switch kann weiterhin ein PoE-Problem besitzen. Deshalb müssen Datenverkehr und Stromversorgung getrennt bewertet werden. --- **12. Physische Infrastruktur prüfen** Bei mehreren betroffenen Clients sind besonders gemeinsame physische Komponenten zu untersuchen: - Access Switch, - Switch-Uplink, - Glasfaserstrecke, - Kupfer-Uplink, - Patchkabel, - Patchfeld, - Transceiver, - Medienkonverter, - Stack-Kabel, - Modul oder Line Card, - Gebäudeverkabelung. Mögliche Hinweise: - Uplink ohne Link, - Link wechselt zwischen Up und Down, - hohe Anzahl CRC-Fehler, - Eingabefehler, - Verwerfungen, - fehlerhafte Transceiverwerte, - nur eine Richtung funktioniert, - ungewöhnlich niedrige ausgehandelte Geschwindigkeit, - Port befindet sich im Fehlerzustand, - Switch-Mitglied fehlt aus einem Stack, - Line Card ist ausgefallen. **Typische Zähler** | Zähler oder Zustand | mögliche Bedeutung | |---|---| | CRC-Fehler | physische Übertragungsfehler, Kabel, Stecker oder Transceiver | | Input Errors | unterschiedliche Empfangsfehler | | Output Drops | Warteschlange oder Überlastung | | Link Flaps | instabile Verbindung oder Komponente | | administratively down | Schnittstelle wurde deaktiviert | | err-disabled | Schutzfunktion oder erkannter Fehler | | keine optische Empfangsleistung | Glasfaser, Transceiver oder Gegenstelle | | viele Interface-Resets | instabiler Port, Treiber oder Hardware | Zähler müssen zusammen mit Laufzeit, Verkehrsmenge und Änderungsrate bewertet werden. Ein historischer Fehlerzähler beweist keinen aktuellen Defekt. --- **13. Access Switch prüfen** Zu einem betroffenen Access Switch sollten mindestens folgende Informationen erhoben werden: - Erreichbarkeit des Managements, - Betriebszeit, - letzter Neustart, - CPU-Auslastung, - Speicherauslastung, - Temperatur, - Netzteilstatus, - Stack-Status, - Uplink-Status, - Fehlerzähler, - VLAN-Zustand, - Spanning-Tree-Zustand, - MAC-Adresstabelle, - Port-Sicherheitszustände, - PoE-Status, - Systemprotokolle, - aktuelle Konfiguration, - letzte Konfigurationsänderung. Mögliche Befehle hängen von Hersteller und Betriebssystem ab. Bei Cisco-IOS-ähnlichen Systemen können beispielsweise relevant sein: ```text show interfaces status show interfaces counters errors show interfaces show logging show vlan brief show interfaces trunk show spanning-tree show etherchannel summary show mac address-table show power inline show environment show switch show version ``` Diese Befehle sind Beispiele. Syntax und Verfügbarkeit müssen anhand der Dokumentation des eingesetzten Geräts geprüft werden. --- **14. Uplink und Trunk untersuchen** Ein Access Switch kann erreichbar sein, während Nutzdaten wegen eines fehlerhaften Uplinks oder Trunks nicht korrekt übertragen werden. Zu prüfen sind: - physischer Linkstatus, - Geschwindigkeit und Duplex, - erlaubte VLANs, - native beziehungsweise untagged VLAN-Zuordnung, - Trunk-Modus, - VLAN-Pruning, - Gegenstellenkonfiguration, - Fehlerzähler, - Spanning-Tree-Zustand, - Link Aggregation, - Port-Sicherheitsmechanismen, - MTU, - einseitige Konfigurationsänderung. **Typische Fehler** - benötigtes VLAN nicht auf dem Trunk erlaubt, - VLAN nur auf einer Seite konfiguriert, - falsches untagged VLAN, - Uplink als Access-Port konfiguriert, - Trunk nach Änderung nicht vollständig übernommen, - Port durch Spanning Tree blockiert, - Mitglied einer Link Aggregation fehlerhaft, - Transceiver oder Faser gestört, - Uplink physisch aktiv, aber Datenverkehr verworfen. > Ein aktiver Link bestätigt weder eine korrekte Trunk-Konfiguration noch die Weiterleitung aller benötigten VLANs. --- **15. VLAN-Zuordnung prüfen** Wenn nur bestimmte Benutzergruppen oder Netzsegmente betroffen sind, ist die VLAN-Konfiguration ein zentraler Prüfpunkt. Zu prüfen sind: - existiert das VLAN auf allen notwendigen Switches? - sind Access-Ports dem richtigen VLAN zugeordnet? - wird das VLAN über alle erforderlichen Trunks transportiert? - besitzt das VLAN ein aktives Gateway? - ist DHCP beziehungsweise DHCP-Relay für dieses VLAN erreichbar? - blockieren Sicherheitsfunktionen den Verkehr? - stimmen Voice- und Data-VLAN? - bestehen dynamische VLAN-Zuweisungen? - verwendet die Netzwerkzugangskontrolle das erwartete VLAN? - wurde das VLAN umbenannt, gelöscht oder neu nummeriert? **Mögliche Beobachtungen** | Beobachtung | mögliche Einordnung | |---|---| | nur ein VLAN betroffen | VLAN-Pfad, Gateway, DHCP oder Richtlinie | | mehrere VLANs desselben Switches betroffen | Switch oder gemeinsamer Uplink | | VLAN funktioniert auf anderen Switches | lokaler Trunk oder Access Switch | | Clients erhalten Adresse aus falschem Netz | falsche VLAN-Zuordnung oder unerwarteter DHCP-Server | | statisch konfigurierte Clients funktionieren, DHCP-Clients nicht | DHCP-Pfad oder DHCP-Dienst | | Gateway im VLAN nicht per ARP erreichbar | Layer-2-Pfad, Gateway oder VLAN-Zuordnung | --- **16. Spanning Tree und Netzwerkschleifen** Spanning Tree verhindert Layer-2-Schleifen in redundanten Ethernet-Netzen. Fehlerhafte Verkabelung oder Konfiguration kann dennoch zu einer Schleife oder instabilen Topologie führen. Mögliche Symptome: - sehr hohe Broadcast-Last, - stark schwankende MAC-Adresstabellen, - MAC-Adressen erscheinen abwechselnd an verschiedenen Ports, - hohe CPU-Auslastung auf Switches, - Paketverluste, - langsame oder vollständig ausfallende Verbindungen, - häufige Topology Changes, - Managementzugriff nur sporadisch möglich, - mehrere Bereiche gleichzeitig betroffen, - Ausfall nach Anschluss eines kleinen Switches oder neuen Kabels. Zu prüfen sind: - Root Bridge, - blockierende und weiterleitende Ports, - letzte Topology Changes, - Anzahl der Topology Changes, - unerwartete Root-Bridge-Änderung, - BPDU Guard, - Root Guard, - Loop Guard, - PortFast beziehungsweise Edge-Port-Konfiguration, - neu angeschlossene Switches, - doppelte Verkabelung. > Bei Verdacht auf eine Schleife dürfen nicht wahllos Verbindungen getrennt werden. Zuerst müssen Topologie, betroffene Ports und aktuelle Zustände soweit möglich dokumentiert werden. --- **17. Link Aggregation und LACP prüfen** Mehrere physische Verbindungen können zu einer logischen Verbindung zusammengefasst sein. Zu prüfen sind: - sind alle erwarteten Mitglieder aktiv? - befinden sich beide Seiten in derselben Aggregation? - stimmen LACP-Modus und Parameter? - verwenden alle Mitglieder identische VLAN- und Trunk-Einstellungen? - bestehen einzelne suspendierte oder nicht gebündelte Ports? - ist die Hash-Verteilung auffällig? - funktionieren bestimmte Verbindungen nur über ein einzelnes fehlerhaftes Mitglied? - ist bei einem Gerätetausch eine alte Konfiguration verblieben? Mögliche Symptome: - nur einige Verbindungen funktionieren, - bestimmte Quell-Ziel-Kombinationen scheitern, - Paketverluste treten abhängig vom Verkehrsfluss auf, - Durchsatz ist deutlich reduziert, - Redundanz ist verloren, - MAC-Adressen wechseln unerwartet, - ein Mitglied leitet außerhalb des Bündels weiter. --- **18. Gateway und First-Hop-Redundanz prüfen** Das Gateway eines VLANs kann physisch oder logisch ausgefallen sein. Zu prüfen sind: - ist die Gateway-Schnittstelle aktiv? - ist die virtuelle Gateway-Adresse vorhanden? - antwortet das Gateway auf ARP beziehungsweise Neighbor Discovery? - besitzen Clients den richtigen Gateway-Eintrag? - ist die Gateway-MAC-Adresse plausibel? - ist die Routingfunktion aktiv? - besteht die verbundene Route? - funktionieren andere VLANs auf demselben Gerät? - bestehen CPU-, Speicher- oder Hardwareprobleme? - funktioniert ein redundantes Gatewaypaar? - stimmen aktive und passive Rollen? - trat ein Rollenwechsel auf? - besteht ein Split-Brain- oder Dual-Active-Zustand? - wird der Rückweg korrekt geroutet? Bei Redundanzprotokollen wie HSRP oder VRRP muss nicht nur der Gerätezustand, sondern auch die tatsächliche Erreichbarkeit der virtuellen Adresse geprüft werden. Eine als aktiv gemeldete Redundanzrolle beweist nicht automatisch, dass: - die Datenebene funktioniert, - alle VLANs übertragen werden, - die Upstream-Verbindung erreichbar ist, - der Rückweg vorhanden ist. --- **19. DHCP bei mehreren betroffenen Clients prüfen** Wenn viele Clients keine verwendbare IP-Konfiguration erhalten, kann eine gemeinsame DHCP-Störung vorliegen. Mögliche Symptome: - Adressen aus `169.254.0.0/16`, - kein Standardgateway, - fehlende DNS-Server, - alte Leases funktionieren noch, - neue Clients erhalten keine Adresse, - Clients erhalten Adressen aus dem falschen Netz, - Fehler beginnt bei hoher Benutzeranzahl, - nur ein bestimmtes VLAN ist betroffen. Zu prüfen sind: - läuft der DHCP-Dienst? - ist der DHCP-Server erreichbar? - ist der richtige Bereich aktiv? - sind freie Adressen vorhanden? - stimmen Subnetzmaske, Gateway und DNS-Optionen? - funktioniert DHCP-Relay? - ist die Relay-Adresse korrekt? - wird DHCP durch ACLs oder Firewalls blockiert? - besteht DHCP Snooping? - sind vertrauenswürdige Ports korrekt festgelegt? - antwortet ein unerwünschter DHCP-Server? - funktionieren redundante DHCP-Server? - stimmt der Failover-Zustand? - erreichen Discover-Pakete den Server? - erreicht das Offer den Client? **DHCP-Ablauf** ```text Client → DHCP Discover Server → DHCP Offer Client → DHCP Request Server → DHCP Acknowledgement ``` **Mögliche Beobachtungen** | Beobachtung | mögliche Einordnung | |---|---| | kein Discover sichtbar | Client, Access-Port, VLAN oder Aufzeichnungsstelle | | Discover im VLAN, aber nicht am Server | Relay, Routing, ACL oder VLAN-Pfad | | Discover erreicht Server, kein Offer | Dienst, Bereich, Richtlinie oder Adressmangel | | Offer verlässt Server, erreicht Client nicht | Rückweg, Relay, Snooping oder Layer 2 | | falscher Server antwortet | Rogue DHCP oder falscher gemeinsamer Layer-2-Bereich | | alte Clients funktionieren, neue nicht | erschöpfter Bereich oder gestörter Vergabeprozess | --- **20. DNS-Ausfall nicht mit vollständigem Netzwerkausfall verwechseln** Ein zentraler DNS-Ausfall kann bei vielen Benutzern den Eindruck erzeugen, das Netzwerk sei vollständig ausgefallen. Typische Beobachtungen: - Ziele sind per IP-Adresse erreichbar, - Namen können nicht aufgelöst werden, - bereits bestehende Sitzungen funktionieren teilweise weiter, - Anwendungen mit zwischengespeicherten Adressen funktionieren, - Anmeldungen und Active-Directory-Funktionen scheitern, - interne und externe Namen verhalten sich unterschiedlich. Zu prüfen sind: - Erreichbarkeit der DNS-Server per IP, - DNS-Dienstzustand, - Abfrage eines bekannten internen Namens, - Abfrage eines bekannten externen Namens, - Antwort jedes konfigurierten DNS-Servers, - Rekursion, - Weiterleitungen, - Zonen, - Replikation, - DNSSEC, sofern eingesetzt, - Firewallregeln für UDP und TCP Port 53, - ausgegebene DHCP-DNS-Optionen, - Split-DNS, - Standort- oder VPN-spezifische DNS-Server. **Windows** ```powershell Resolve-DnsName Resolve-DnsName -Server Get-DnsClientServerAddress ``` **Linux und macOS** ```bash dig dig @ ``` > Ein DNS-Fehler betrifft die Namensauflösung. Er beweist keinen Ausfall der zugrunde liegenden IP-Verbindung. --- **21. Netzwerkzugangskontrolle und Authentifizierung** In Unternehmensnetzen kann der Netzwerkzugang von einer Authentifizierung oder Autorisierung abhängen. Mögliche Komponenten: - IEEE 802.1X, - RADIUS, - Network Access Control, - Zertifikatsdienste, - Geräteidentifikation, - dynamische VLAN-Zuweisung, - Quarantäne-VLAN, - MAC Authentication Bypass, - Port-Security. Mögliche Symptome: - viele Ports wechseln gleichzeitig in einen nicht autorisierten Zustand, - Clients erhalten ein Quarantäne-VLAN, - kabelgebundene und drahtlose Anmeldungen scheitern, - neue Verbindungen scheitern, bestehende funktionieren, - Fehler beginnt nach Ablauf eines Zertifikats, - RADIUS-Server ist nicht erreichbar, - Uhrzeitabweichungen verhindern die Zertifikatsprüfung, - eine Richtlinienänderung betrifft ganze Gerätegruppen. Zu prüfen sind: - Status des Authentifizierungsdienstes, - Erreichbarkeit der RADIUS-Server, - Zertifikatsgültigkeit, - Systemzeit, - Richtlinienänderungen, - Switch- und Controllerprotokolle, - Ablehnungsgrund, - zugewiesenes VLAN, - Failover auf einen zweiten Authentifizierungsserver. --- **22. WLAN als eigene Fehlerdomäne untersuchen** Wenn mehrere WLAN-Clients betroffen sind, müssen Funk-, Zugangs- und zentrale WLAN-Komponenten getrennt geprüft werden. Zu prüfen sind: - ist die SSID sichtbar? - können Clients sich verbinden? - funktioniert die Authentifizierung? - erhalten sie eine IP-Adresse? - betrifft es einen Access Point oder mehrere? - betrifft es ein Frequenzband? - betrifft es eine SSID? - betrifft es einen Standort? - sind Access Points beim Controller registriert? - besitzen Access Points Strom und Uplink? - ist das vorgesehene VLAN verfügbar? - funktioniert DHCP? - besteht ausreichende Funkabdeckung? - gibt es starke Störungen? - ist die Clientanzahl ungewöhnlich hoch? - funktionieren Roaming und Controller-Kommunikation? - wurde Firmware oder Konfiguration geändert? **Abgrenzung** | Beobachtung | mögliche Einordnung | |---|---| | SSID nicht sichtbar | Access Point, Funkmodul, Controller oder SSID-Konfiguration | | SSID sichtbar, Anmeldung scheitert | Authentifizierung, Zertifikat, RADIUS oder Kennwort | | Anmeldung erfolgreich, keine IP-Adresse | VLAN, DHCP oder Tunnel | | IP-Adresse vorhanden, Gateway nicht erreichbar | VLAN-Pfad, Gateway oder Client-Isolation | | nur ein Access Point betroffen | AP, Uplink, PoE oder lokale Funkumgebung | | alle APs eines Standorts betroffen | Controllerpfad, Standort-Uplink, DHCP oder gemeinsame Konfiguration | | nur ein Frequenzband betroffen | Funkkonfiguration, Radarereignis oder Hardware | --- **23. Firewall, ACL und zentrale Sicherheitskomponenten** Ein gemeinsamer Filterfehler kann viele Clients oder ganze Netze betreffen. Zu prüfen sind: - tatsächliche Quellnetze, - Zielnetze, - Protokolle und Ports, - verwendete Sicherheitszone, - Regelreihenfolge, - Regeländerungen, - NAT, - Sitzungszustände, - Hochverfügbarkeitsstatus, - Routing auf der Firewall, - Schnittstellenstatus, - Ressourcenverbrauch, - Lizenz- oder Zertifikatsstatus, - Protokolle zum Fehlerzeitpunkt, - IPv4- und IPv6-Regeln, - Rückweg. **Mögliche Symptome** | Beobachtung | mögliche Einordnung | |---|---| | interne Kommunikation funktioniert, Internet nicht | Firewall, NAT, WAN oder Provider | | nur ein VLAN erreicht das Internet nicht | Zone, Regel, NAT oder Route | | neue Verbindungen scheitern, bestehende funktionieren | Sitzungsgrenze, Zustandsübergang oder Regeländerung | | nur HTTPS scheitert | Filter, Proxy, TLS-Inspektion oder Zertifikat | | aktive Firewall meldet fehlerfreien Zustand, Verkehr fällt aus | Datenebene, Route, Schnittstelle oder Clusterzustand | | nach Failover tritt Fehler auf | unsynchronisierte Zustände, Route, NAT oder Konfiguration | Eine Firewall sollte während einer größeren Störung nicht pauschal deaktiviert werden. Regeln und Protokolle müssen gezielt untersucht werden. --- **24. Routing und Rückweg prüfen** Wenn mehrere Netze betroffen sind, ist die Routingstruktur zu untersuchen. Zu prüfen sind: - verbundene Netze, - statische Routen, - dynamische Routingnachbarschaften, - Standardroute, - spezifische Zielrouten, - Routenauswahl, - Metrik beziehungsweise administrative Distanz, - Policy-based Routing, - VRF, - Route Redistribution, - zusammengefasste Routen, - Rückroute, - asymmetrisches Routing, - kürzlich zurückgezogene Präfixe. **Mögliche Beobachtungen** - Gateway ist erreichbar, entfernte Netze nicht. - Einige Zielnetze funktionieren, andere nicht. - Verkehr verlässt den Standort, Antworten kommen nicht zurück. - Nach einem Failover wird ein falscher Pfad gewählt. - Eine spezifische Route fehlt, während die Standardroute besteht. - Ein Standortpräfix wird nicht mehr angekündigt. - Dieselben Adressbereiche werden an mehreren Stellen verwendet. > Ein erfolgreicher Hinweg reicht nicht aus. Ende-zu-Ende-Kommunikation benötigt grundsätzlich auch einen funktionsfähigen Rückweg. --- **25. WAN- und Standortverbindung prüfen** Wenn lokale Kommunikation funktioniert, aber zentrale Systeme oder andere Standorte nicht erreichbar sind, liegt der Untersuchungsbereich häufig bei der Standortanbindung. Mögliche Verbindungen: - MPLS, - SD-WAN, - Site-to-Site-VPN, - Standleitung, - Metro Ethernet, - Internet-VPN, - Mobilfunk-Fallback, - direkte Cloud-Verbindung. Zu prüfen sind: - physischer WAN-Link, - Providerübergabe, - WAN-IP-Konfiguration, - Tunnelzustand, - Routingnachbarschaften, - Latenz, - Paketverlust, - Jitter, - MTU, - Verschlüsselungsstatus, - Zertifikate, - aktive und passive Leitungen, - automatische Umschaltung, - tatsächlicher Datenpfad, - Providerstörungsmeldungen. **Abgrenzung** ```text lokales Gateway erreichbar → lokaler Server erreichbar → zentraler Server nicht erreichbar → Internet erreichbar ``` Dies spricht eher für: - ausgefallenen Standorttunnel, - fehlende Route, - zentrale Firewallregel, - Rückwegproblem, - Ausfall des zentralen Ziels. Es spricht nicht für einen vollständigen lokalen Netzwerkausfall. --- **26. Internet- oder Providerstörung prüfen** Ein Provider sollte erst dann als Ursache benannt werden, wenn der lokale Verantwortungsbereich ausreichend geprüft wurde. Vor einer Eskalation sollten dokumentiert sein: - Kundennummer oder Anschlusskennung, - betroffener Standort, - Beginn der Störung, - Art des Anschlusses, - Status des Providerübergabegeräts, - physischer Link, - WAN-Adresse, - Erreichbarkeit des nächsten Provider-Hops, sofern testbar, - Paketverlust und Laufzeit, - Verhalten einer Ersatzverbindung, - lokale Router- und Firewallzustände, - bereits durchgeführte Tests, - relevante Protokolle. Ein fehlgeschlagener Ping auf einen Providerrouter beweist keinen Ausfall, da ICMP gefiltert sein kann. Eine erfolgreiche Mobilfunk- oder Ersatzverbindung zeigt, dass die Anwendung und das Ziel grundsätzlich funktionieren können. Sie beweist aber nicht allein, an welcher Stelle der ursprüngliche Anschluss fehlerhaft ist. --- **27. Redundanz und Failover nicht voraussetzen** Vorhandene Redundanz bedeutet nicht automatisch, dass ein Ausfall ohne Unterbrechung abgefangen wird. Zu prüfen sind: - ist die Ersatzkomponente tatsächlich betriebsbereit? - wird ihr Zustand überwacht? - sind Konfigurationen synchron? - existieren gültige Routen? - funktioniert die Umschaltung? - wird die Datenebene geprüft oder nur der Linkstatus? - bestehen gültige Lizenzen und Zertifikate? - reicht die Kapazität der Ersatzverbindung? - wurde das Failover regelmäßig getestet? - funktioniert auch die Rückschaltung? **Mögliche Fehlerbilder** - primäre Verbindung ausgefallen, sekundäre Verbindung übernimmt nicht, - sekundäre Verbindung wird aktiv, besitzt aber keine Route, - Firewallcluster wechselt die Rolle, Upstream-Switch verwendet weiterhin den alten Pfad, - Mobilfunk-Fallback ist aktiv, aber dessen Datenvolumen oder Richtlinie verhindert den Verkehr, - beide redundanten Geräte hängen an derselben ausgefallenen Stromversorgung, - beide Leitungen verwenden denselben physischen Gebäudeeintritt. > Redundanz schützt nur vor Fehlern, die im Entwurf berücksichtigt wurden und deren Umschaltung technisch funktioniert. --- **28. Broadcast-Sturm und Überlastung** Ein größeres Netz kann durch ungewöhnlich hohe Last stark beeinträchtigt werden. Mögliche Ursachen: - Layer-2-Schleife, - fehlerhaftes Gerät, - Broadcast-Sturm, - Multicast-Flut, - übermäßige unbekannte Unicasts, - Schadsoftware, - fehlerhafte Netzwerkkarte, - Backup- oder Replikationsverkehr, - Denial-of-Service, - überlasteter Uplink, - ausgeschöpfte Firewall-Sitzungstabelle. Mögliche Hinweise: - hohe Switch-CPU, - stark erhöhte Broadcast-Zähler, - Managementzugriff instabil, - hohe Portauslastung, - Output Drops, - Paketverlust über viele Clients, - zunehmende Latenz, - MAC-Adresstabelle verändert sich fortlaufend, - Problem verschwindet nach Isolation eines bestimmten Bereichs. Die verursachende Quelle sollte anhand von: - Interface-Zählern, - Flussdaten, - Switch-Protokollen, - MAC-Adresstabellen, - Port Mirroring, - Paketaufzeichnung, - Monitoringverlauf eingegrenzt werden. --- **29. Monitoringdaten auswerten** Monitoring kann zeigen, ob der Fehler lokal, zentral oder schrittweise entstanden ist. Relevante Messwerte: - Geräteerreichbarkeit, - Interface-Status, - Link Flaps, - Bandbreite, - Paketverlust, - Latenz, - CPU, - Speicher, - Temperatur, - Netzteilstatus, - PoE-Verbrauch, - Routingnachbarschaften, - VPN-Tunnel, - DHCP-Auslastung, - DNS-Antwortzeiten, - Firewall-Sitzungen, - Anzahl verbundener WLAN-Clients, - Access-Point-Zustände. **Beispielhafte Ereignisfolge** ```text 09:16:58 Uplink Gi1/0/48 meldet Down 09:16:59 Access Switch wird vom Monitoring nicht mehr erreicht 09:17:03 42 Clients werden als nicht erreichbar gemeldet 09:17:05 Access Points verlieren Controllerverbindung 09:17:21 Uplink meldet kurzzeitig Up 09:17:24 Uplink meldet erneut Down ``` Diese Reihenfolge spricht stärker für einen instabilen gemeinsamen Uplink als für unabhängige Fehler an 42 Clients. Monitoring kann jedoch Lücken besitzen: - Messintervall zu groß, - Überwachung nur per ICMP, - Monitoringpfad selbst betroffen, - Gerät antwortet auf Management, leitet aber keine Nutzdaten, - Messung erfolgt von nur einem Standort. --- **30. Protokolle zeitlich korrelieren** Bei einem größeren Ausfall sollten Protokolle verschiedener Systeme anhand derselben Zeitachse verglichen werden. Relevante Quellen: - Access Switch, - Distribution- und Core-Switch, - Router, - Firewall, - WLAN-Controller, - Access Points, - DHCP-Server, - DNS-Server, - RADIUS-Server, - VPN-Gateway, - Providergerät, - USV, - Virtualisierungsplattform, - Monitoring, - ausgewählte Clients. Voraussetzung für eine sinnvolle Korrelation ist eine möglichst genaue Zeitsynchronisation. **Beispiel** ```text 09:17:02 Distribution Switch: LACP-Mitglied verloren 09:17:03 Access Switch: Uplink-Protokoll wechselt Zustand 09:17:04 Spanning Tree: Topologieänderung 09:17:07 Monitoring: Access Switch nicht erreichbar 09:17:10 DHCP: Anfragen aus VLAN 120 bleiben aus ``` Diese Kombination ist aussagekräftiger als ein einzelner Clientfehler. --- **31. Paketaufzeichnung an geeigneten Punkten** Eine Paketaufzeichnung kann zeigen, bis zu welcher Stelle Verkehr gelangt. Mögliche Aufzeichnungspunkte: - betroffener Client, - funktionierender Vergleichsclient, - Access-Port, - Switch-Uplink, - VLAN-Gateway, - DHCP-Server, - DNS-Server, - Firewall, - Zielserver, - WAN-Schnittstelle. Mögliche Fragestellungen: - sendet der Client ARP-Anfragen? - erreicht ARP das Gateway? - antwortet das Gateway? - verlassen DHCP-Discover-Pakete das VLAN? - erreicht das DHCP-Offer den Uplink? - werden DNS-Anfragen gesendet? - antwortet der DNS-Server? - erreicht ein TCP-SYN die Firewall? - verlässt es die WAN-Schnittstelle? - kommt eine Antwort zurück? - treten Wiederholungen auf? - werden ICMP-Fehlermeldungen zurückgesendet? **Beispielhafte Wireshark-Filter** ```text arp dhcp dns icmp icmpv6 stp eth.addr == ip.addr == tcp.port == 443 ``` Eine Aufzeichnung an nur einem Punkt zeigt nicht automatisch, an welchem Abschnitt eines längeren Pfades ein Paket verloren geht. Bei komplexen Fehlern können zeitlich abgestimmte Aufzeichnungen an mehreren Stellen erforderlich sein. Paketaufzeichnungen dürfen nur mit Berechtigung erstellt und müssen geschützt gespeichert werden. --- **32. Änderungen kontrolliert zurücknehmen** Wenn eine konkrete Änderung als Ursache bestätigt oder sehr stark eingegrenzt wurde, kann eine Rücknahme sinnvoll sein. Vor dem Rollback sind zu klären: - ist der vorherige Zustand dokumentiert? - ist die alte Konfiguration weiterhin gültig? - wurden seitdem weitere abhängige Änderungen durchgeführt? - bestehen Sicherheitsrisiken durch die Rücknahme? - ist ein Wartungs- oder Freigabeprozess erforderlich? - kann die Rücknahme weitere Bereiche beeinträchtigen? - existiert eine aktuelle Sicherung? - wie wird der Erfolg geprüft? - wie wird bei Misserfolg weiter vorgegangen? Ein Rollback ist keine beliebige Rückkehr zu einer alten Konfiguration. Es ist eine geplante Änderung mit eigener Risiko- und Nachprüfung. --- **33. Ungeeignete Sofortmaßnahmen** Bei einem größeren Ausfall können unkoordinierte Eingriffe den Fehler ausweiten oder wichtige Spuren vernichten. Problematisch sind insbesondere: - alle Switches neu starten, - Firewall neu starten, - Router neu starten, - mehrere Uplinks gleichzeitig trennen, - Spanning Tree deaktivieren, - alle Ports administrativ aktivieren, - VLANs neu anlegen, ohne den Ausgangszustand zu sichern, - Firewall vollständig deaktivieren, - DHCP-Bereiche ungeprüft vergrößern, - Switch-Konfiguration durch eine alte Sicherung überschreiben, - Firmware während der Störung aktualisieren, - Provider ohne lokale Prüfung als Ursache festlegen, - mehrere Teams unabhängig Änderungen durchführen lassen, - Geräte austauschen, bevor Verkabelung und Konfiguration dokumentiert wurden. Solche Maßnahmen können im Einzelfall notwendig sein. Sie benötigen jedoch: - technische Begründung, - Freigabe, - Koordination, - dokumentierten Ausgangszustand, - Rückfallmöglichkeit, - vollständige Nachprüfung. --- **34. Praxisfall A: Gesamte Etage ohne kabelgebundenes Netzwerk** **Symptom** - alle geprüften Ethernet-Clients der dritten Etage sind betroffen, - WLAN funktioniert, - andere Etagen funktionieren, - Clients erhalten keine DHCP-Adresse, - Access Switch ist über eine separate Managementverbindung erreichbar. **Prüfung** 1. betroffene Access-Ports und VLANs dokumentieren. 2. Uplinkstatus des Etagen-Switches prüfen. 3. Trunk-Konfiguration beider Seiten vergleichen. 4. erlaubte VLANs kontrollieren. 5. Spanning-Tree-Zustand prüfen. 6. Fehlerzähler des Uplinks auswerten. 7. MAC-Adresstabelle kontrollieren. 8. DHCP-Verkehr am Client-VLAN untersuchen. 9. letzte Konfigurationsänderungen prüfen. 10. nach einer freigegebenen Korrektur alle betroffenen VLANs testen. **Mögliche Ursache** Bei einer Änderung wurde das Client-VLAN aus der Liste der auf dem Uplink erlaubten VLANs entfernt. Das Management-VLAN blieb verfügbar, weshalb der Switch weiterhin administrierbar war. **Nachprüfung** - Clients erhalten Adressen aus dem richtigen Bereich, - Gateway ist erreichbar, - interne DNS-Auflösung funktioniert, - zentrale Anwendungen sind erreichbar, - Internetzugriff funktioniert, - weitere VLANs des Switches funktionieren, - Trunk-Konfiguration beider Seiten ist dokumentiert. --- **35. Praxisfall B: Ganzer Standort erreicht zentrale Systeme nicht** **Symptom** - lokale Drucker und lokale Server funktionieren, - das lokale Gateway ist erreichbar, - zentrale Anwendungen sind nicht erreichbar, - andere Standorte funktionieren, - öffentlicher Internetzugriff funktioniert. **Prüfung** 1. lokale Kommunikation bestätigen. 2. zentrale Ziele per IP testen. 3. Standorttunnel prüfen. 4. Routingtabelle kontrollieren. 5. Ankündigung des Standortpräfixes prüfen. 6. Rückroute am zentralen Standort untersuchen. 7. Firewallprotokolle auswerten. 8. Tunnel- und Routingereignisse zeitlich vergleichen. 9. redundante Verbindung prüfen. 10. ursprünglichen Anwendungszugriff nach der Korrektur wiederholen. **Mögliche Ursache** Nach einer Änderung wurde das lokale Standortpräfix nicht mehr über den VPN-Tunnel angekündigt. Der Hinweg zu zentralen Systemen war teilweise vorhanden, die Antworten besaßen jedoch keine passende Rückroute. **Nachprüfung** - zentrale IP-Ziele erreichbar, - zentrale DNS-Namen auflösbar, - benötigte Anwendungsports erreichbar, - Hin- und Rückroute vorhanden, - erneuter Tunnelaufbau erfolgreich, - Internetverkehr weiterhin funktionsfähig. --- **36. Praxisfall C: Neue Clients erhalten kein Netzwerk** **Symptom** - bereits aktive Clients funktionieren, - neu gestartete oder neu angeschlossene Clients erhalten keine Adresse, - mehrere Bereiche desselben VLANs sind betroffen, - statisch konfigurierte Infrastrukturgeräte bleiben erreichbar. **Prüfung** 1. Adressbereich und freie Leases kontrollieren. 2. DHCP-Dienstzustand prüfen. 3. DHCP-Failoverstatus prüfen. 4. Discover-, Offer-, Request- und ACK-Ablauf aufzeichnen. 5. DHCP-Relay prüfen. 6. DHCP-Snooping-Zustand kontrollieren. 7. Lease-Dauer und Anzahl aktiver Geräte auswerten. 8. unerwünschte DHCP-Server ausschließen. 9. freigegebene Korrektur durchführen. 10. mehrere neue Adressvergaben testen. **Mögliche Ursache** Der DHCP-Bereich besitzt keine freien Adressen mehr. Bestehende Clients können ihre noch gültigen Adressen weiterverwenden, während neue Clients keine Lease erhalten. **Nachprüfung** - neue Clients erhalten gültige Adressen, - Gateway- und DNS-Optionen stimmen, - Lease-Erneuerung funktioniert, - Failoverzustand ist fehlerfrei, - Adressauslastung wird überwacht, - Ursache der unerwartet hohen Belegung ist dokumentiert. --- **37. Praxisfall D: Viele Benutzer melden „kein Internet“** **Symptom** - Gateway ist erreichbar, - öffentliche IP-Ziele sind erreichbar, - Websites können über Namen nicht geöffnet werden, - interne Anwendungen mit bereits bekannten Adressen funktionieren teilweise. **Prüfung** 1. IP-Verbindung getrennt von DNS testen. 2. jeden konfigurierten DNS-Server einzeln abfragen. 3. DNS-Dienstzustand prüfen. 4. Firewallregeln für DNS kontrollieren. 5. Weiterleitungen und Rekursion prüfen. 6. DHCP-DNS-Optionen auswerten. 7. Serverprotokolle zum Fehlerzeitpunkt prüfen. 8. internen und externen Namen testen. 9. DNS-Korrektur durchführen. 10. ursprüngliche Anwendungen erneut prüfen. **Mögliche Ursache** Der primäre und sekundäre DNS-Dienst waren auf derselben ausgefallenen Virtualisierungsplattform betrieben. Die Clients besaßen weiterhin eine funktionierende IP-Verbindung, konnten jedoch keine Namen auflösen. **Nachprüfung** - interne Namen werden korrekt aufgelöst, - externe Namen werden korrekt aufgelöst, - jeder vorgesehene DNS-Server antwortet, - Webanwendungen funktionieren, - Active-Directory-abhängige Dienste funktionieren, - tatsächliche Unabhängigkeit der DNS-Redundanz wird bewertet. --- **38. Praxisfall E: Standort fällt trotz redundanter WAN-Leitung aus** **Symptom** - primäre Leitung ist ausgefallen, - sekundäre Leitung wird als aktiv angezeigt, - zentrale Anwendungen und Internet sind trotzdem nicht erreichbar, - lokale Kommunikation funktioniert. **Prüfung** 1. physischen Zustand beider Leitungen prüfen. 2. aktive Standardroute kontrollieren. 3. Tunnelzustand der Ersatzleitung prüfen. 4. NAT und Firewallregeln prüfen. 5. Routingankündigungen kontrollieren. 6. DNS-Erreichbarkeit über den Ersatzpfad testen. 7. MTU und Paketgröße berücksichtigen. 8. Providerübergaben beider Leitungen vergleichen. 9. Datenverkehr auf der Ersatzschnittstelle aufzeichnen. 10. vollständigen Failover- und Rückschalttest planen. **Mögliche Ursache** Die Ersatzleitung war physisch aktiv, besaß jedoch wegen einer fehlenden Standardroute keinen verwendbaren Datenpfad. **Nachprüfung** - Internet und zentrale Dienste über Ersatzleitung erreichbar, - Tunnel aktiv, - DNS erreichbar, - benötigte NAT- und Firewallregeln wirksam, - automatisches Failover reproduzierbar, - Rückschaltung kontrolliert, - Monitoring erkennt nicht nur den Link-, sondern auch den Dienstzustand. --- **39. Häufige Fehlinterpretationen** | Aussage | fachliche Einordnung | |---|---| | „Viele Benutzer sind betroffen, also ist der Provider ausgefallen.“ | Auch Switch, VLAN, Gateway, DHCP, DNS, Firewall oder Standortanbindung können gemeinsam verantwortlich sein. | | „Der Switch ist erreichbar, also funktioniert er.“ | Management- und Nutzdatenpfad können getrennt sein. | | „Alle Ports zeigen Link, also ist das Netzwerk in Ordnung.“ | VLAN, Trunk, Gateway, DHCP und Routing können trotzdem fehlerhaft sein. | | „WLAN funktioniert, also kann der Switch nicht betroffen sein.“ | WLAN kann einen anderen Access Switch, ein anderes VLAN oder einen anderen Datenpfad verwenden. | | „Nur ein VLAN ist ausgefallen, also ist das Gateway defekt.“ | Auch Trunk, Relay, ACL oder VLAN-Zuordnung können betroffen sein. | | „Alte Clients funktionieren, also funktioniert DHCP.“ | Alte Clients können noch gültige Leases verwenden. | | „Die redundante Leitung ist aktiv, also funktioniert das Failover.“ | Linkstatus bestätigt keinen vollständigen Datenpfad. | | „Die Firewall zeigt Grün, also blockiert sie nichts.“ | Regeln, NAT, Routing oder Datenebene können trotzdem fehlerhaft sein. | | „Nach einem Neustart funktioniert alles, also ist die Ursache behoben.“ | Der Neustart kann Zustand und Spuren verändert haben, ohne die Ursache zu erklären. | | „Eine hohe CPU-Auslastung beweist einen Angriff.“ | Schleifen, Fehler, Monitoring, legitime Last und Kontrollprotokolle sind ebenfalls möglich. | | „Der letzte sichtbare Traceroute-Hop ist defekt.“ | Router können Antworten filtern und Verkehr trotzdem weiterleiten. | | „Zwei Netzteile bedeuten vollständige Redundanz.“ | Beide können an derselben Stromquelle oder USV angeschlossen sein. | --- **40. Vollständige Prüfreihenfolge** 1. konkrete Symptome und betroffene Anwendungen erfassen. 2. Anzahl und Verteilung der betroffenen Clients bestimmen. 3. Ethernet, WLAN, Telefonie und andere Gerätetypen unterscheiden. 4. funktionierende Vergleichsbereiche bestimmen. 5. Beginn, Verlauf und letzte bekannte Funktion dokumentieren. 6. letzte Änderungen und Wartungsarbeiten prüfen. 7. geschäftliche Auswirkung und Priorität bewerten. 8. Zuständigkeiten und Kommunikation koordinieren. 9. repräsentative betroffene und funktionierende Testpunkte auswählen. 10. gemeinsame technische Abhängigkeiten abbilden. 11. Stromversorgung, USV und Umgebung prüfen. 12. Access Switch und physische Uplinks untersuchen. 13. Fehlerzähler und Link Flaps auswerten. 14. Trunk- und VLAN-Konfiguration prüfen. 15. Spanning Tree und mögliche Schleifen untersuchen. 16. Link Aggregation und LACP prüfen. 17. Gateway und First-Hop-Redundanz kontrollieren. 18. DHCP-Dienst, Bereiche und Relay untersuchen. 19. DNS getrennt von der IP-Verbindung prüfen. 20. Netzwerkzugangskontrolle und Authentifizierung berücksichtigen. 21. bei WLAN-Störungen Access Points und Controller prüfen. 22. Firewall, ACL, NAT und Sicherheitszonen untersuchen. 23. Routing einschließlich Rückweg prüfen. 24. WAN, VPN und Providerübergabe kontrollieren. 25. tatsächliche Funktion redundanter Pfade prüfen. 26. Monitoringdaten und Protokolle zeitlich korrelieren. 27. bei Bedarf autorisierte Paketaufzeichnungen erstellen. 28. eine konkrete Hypothese formulieren. 29. Änderung oder Rollback freigeben lassen. 30. immer nur eine kontrollierbare Änderung durchführen. 31. ursprüngliches Symptom erneut testen. 32. weitere VLANs, Standorte und Dienste auf Nebenwirkungen prüfen. 33. Redundanz und erneuten Verbindungsaufbau testen. 34. Ursache, Maßnahme, Ergebnis und verbleibendes Risiko dokumentieren. 35. notwendige Präventionsmaßnahmen festlegen. --- **41. Dokumentationsbeispiel** ```text Ticket: INC-20614 Beginn: 01.08.2026, etwa 09:17 Uhr Standort: Gebäude B Umfang: kabelgebundene Clients der dritten Etage Nicht betroffen: WLAN, andere Etagen, zentrale Server Symptom: Betroffene Clients erhalten keine DHCP-Adresse und können das Standardgateway nicht erreichen. Ausgangszustand: - Access Switch erreichbar - Clientports physisch aktiv - WLAN derselben Etage funktioniert - andere Etagen im gleichen Client-VLAN funktionieren - Uplink des Access Switches aktiv - Client-VLAN nicht in der Liste der erlaubten Uplink-VLANs - Management-VLAN weiterhin erlaubt Hypothese: Das Client-VLAN wird am Uplink des Etagen-Switches nicht mehr transportiert. Prüfung: - Trunk-Konfiguration beider Uplink-Seiten verglichen - Konfigurationsänderung um 09:14 Uhr festgestellt - Client-VLAN fehlte nur auf der Seite des Access Switches - DHCP-Discover war am Clientport, aber nicht am Distribution Switch sichtbar Ursache: Unvollständige Liste erlaubter VLANs nach einer Uplink-Änderung. Maßnahme: Client-VLAN nach Freigabe wieder auf dem Uplink zugelassen. Nachprüfung: - mehrere Clients erhalten gültige DHCP-Adressen - Standardgateway erreichbar - interne DNS-Auflösung erfolgreich - zentrale Anwendungen erreichbar - Internetzugriff funktioniert - WLAN weiterhin funktionsfähig - weitere VLANs des Access Switches geprüft - Konfiguration gespeichert und dokumentiert Prävention: - Konfigurationsprüfung für Trunk-Änderungen ergänzen - VLAN-Erreichbarkeit in das Monitoring aufnehmen - Peer-Review für Änderungen an produktiven Uplinks einführen ``` --- **42. Checkliste für mehrere Clients oder einen Standort ohne Netzwerk** - [ ] genaue Anzahl und Verteilung der betroffenen Clients wurden bestimmt. - [ ] Benutzerangaben wurden durch repräsentative Tests bestätigt. - [ ] Ethernet und WLAN wurden getrennt geprüft. - [ ] funktionierende Vergleichsbereiche wurden dokumentiert. - [ ] interne Dienste, Internet und DNS wurden getrennt bewertet. - [ ] Beginn und zeitlicher Verlauf wurden erfasst. - [ ] letzte Änderungen wurden geprüft. - [ ] geschäftliche Auswirkung und Priorität wurden bewertet. - [ ] technische und kommunikative Zuständigkeiten wurden festgelegt. - [ ] gemeinsame Komponenten der betroffenen Clients wurden bestimmt. - [ ] Stromversorgung und USV wurden geprüft. - [ ] Access Switches wurden auf Zustand und Erreichbarkeit geprüft. - [ ] Uplink-Status und Fehlerzähler wurden kontrolliert. - [ ] Trunk-Konfiguration wurde auf beiden Seiten verglichen. - [ ] benötigte VLANs wurden über den vollständigen Pfad geprüft. - [ ] Spanning-Tree-Zustand und Topology Changes wurden untersucht. - [ ] Link Aggregation und LACP wurden berücksichtigt. - [ ] Gateway und Gateway-Redundanz wurden geprüft. - [ ] DHCP-Dienst, Bereich und Relay wurden untersucht. - [ ] DNS wurde getrennt von der IP-Verbindung getestet. - [ ] Netzwerkzugangskontrolle und RADIUS wurden berücksichtigt. - [ ] WLAN-Controller und Access Points wurden bei Bedarf geprüft. - [ ] Firewallregeln, NAT und ACLs wurden kontrolliert. - [ ] Hin- und Rückrouting wurden geprüft. - [ ] WAN- und VPN-Zustand wurden untersucht. - [ ] Provider wurde erst nach lokaler Eingrenzung einbezogen. - [ ] redundante Pfade wurden tatsächlich getestet. - [ ] Monitoringdaten wurden ausgewertet. - [ ] Protokolle verschiedener Komponenten wurden zeitlich korreliert. - [ ] Paketaufzeichnungen erfolgten nur mit Berechtigung. - [ ] eine konkrete technische Hypothese wurde formuliert. - [ ] Ausgangskonfiguration wurde vor Änderungen gesichert. - [ ] Änderung oder Rollback wurde freigegeben. - [ ] es wurde nur eine kontrollierbare Änderung gleichzeitig durchgeführt. - [ ] ursprüngliches Symptom wurde erneut getestet. - [ ] weitere Dienste und Bereiche wurden auf Nebenwirkungen geprüft. - [ ] Ursache, Maßnahme und Nachweis wurden dokumentiert. - [ ] Präventionsmaßnahmen wurden festgelegt. --- **43. Schnellreferenz** | Fehlerumfang | wahrscheinlicher gemeinsamer Untersuchungsbereich | |---|---| | einzelne Clients an einem Switch | Access-Ports, VLAN, Switch oder Uplink | | komplette Etage | Etagen-Switch, Uplink, Strom oder VLAN-Pfad | | ein VLAN an mehreren Switches | Gateway, DHCP, VLAN-Trunks, ACL oder Routing | | nur neue Clients | DHCP, Authentifizierung oder Adressbereich | | nur WLAN-Clients | Access Points, Controller, SSID, RADIUS, VLAN oder DHCP | | Ethernet und WLAN eines Standorts | Gateway, Firewall, WAN, zentrale Dienste oder Strom | | lokale Systeme funktionieren, zentrale nicht | WAN, VPN, Routing, Firewall oder Rückweg | | IP-Ziele funktionieren, Namen nicht | DNS | | interne Ziele funktionieren, Internet nicht | Firewall, NAT, WAN oder Provider | | alle Standorte betroffen | zentrale Firewall, DNS, Rechenzentrum, Cloud oder zentraler Routingbereich | | sporadische Ausfälle vieler Clients | Schleife, instabiler Uplink, Überlastung oder Redundanzproblem | | bestehende Sitzungen funktionieren, neue nicht | DHCP, DNS, Authentifizierung, Firewallzustand oder Kapazitätsgrenze | --- **Merksatz** > Bei mehreren gleichzeitig betroffenen Clients wird nicht jedes Endgerät einzeln als unabhängiger Fehlerfall behandelt. Entscheidend ist der kleinste gemeinsame Ausfallbereich. Funktionierende Vergleichsbereiche, gemeinsame Abhängigkeiten, Zeitstempel und gezielte Tests führen von der allgemeinen Meldung „Standort ohne Netzwerk“ zu einer überprüfbaren Ursache. --- **Quellen und weiterführende Dokumentation** - [Microsoft Learn – DHCP troubleshooting guidance for Windows Server](https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/troubleshoot-dhcp-guidance) - [Microsoft Learn – Guidance for troubleshooting DNS](https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/troubleshoot-dns-guidance) - [Microsoft Learn – Troubleshooting DNS servers](https://learn.microsoft.com/en-us/windows-server/networking/dns/troubleshoot/troubleshoot-dns-server) - [Cisco – Troubleshoot DHCP in Enterprise Networks](https://www.cisco.com/c/en/us/support/docs/ip/dynamic-address-allocation-resolution/27470-100.html) - [Cisco – Troubleshoot DHCP in a Layer 2 Only VLAN – Wired](https://www.cisco.com/c/en/us/support/docs/cloud-systems-management/catalyst-center/224570-troubleshoot-dhcp-in-layer-2-only-vlan.html) - [Cisco – High Availability Campus Recovery Analysis](https://www.cisco.com/en/US/docs/solutions/Enterprise/Campus/HA_recovery_DG/campusRecovery.html) - [Red Hat – Network troubleshooting and performance tuning](https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/html/network_troubleshooting_and_performance_tuning/) - [Red Hat – Introduction to NetworkManager debugging](https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/8/html/configuring_and_managing_networking/introduction-to-networkmanager-debugging_configuring-and-managing-networking) - [Red Hat – Mirroring a network interface](https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/8/html/configuring_and_managing_networking/proc_mirroring-a-network-interface-by-using-nmcli_configuring-and-managing-networking) - [Wireshark – Benutzerhandbuch](https://www.wireshark.org/docs/wsug_html_chunked/) - [Wireshark – Display Filter Reference](https://www.wireshark.org/docs/dfref/) - [RFC 2131 – Dynamic Host Configuration Protocol](https://www.rfc-editor.org/rfc/rfc2131) - [RFC 826 – Address Resolution Protocol](https://www.rfc-editor.org/rfc/rfc826) - [RFC 1034 – Domain Names: Concepts and Facilities](https://www.rfc-editor.org/rfc/rfc1034) - [RFC 1035 – Domain Names: Implementation and Specification](https://www.rfc-editor.org/rfc/rfc1035) - [RFC 5798 – Virtual Router Redundancy Protocol Version 3](https://www.rfc-editor.org/rfc/rfc5798) - [IEEE 802.1 Working Group](https://1.ieee802.org/) # 6.3 IP-Adresse erreichbar, Name nicht – DNS- und Namensauflösungsfehler Wenn ein Ziel über seine IP-Adresse erreichbar ist, der Zugriff über den Namen jedoch scheitert, funktioniert die grundlegende IP-Kommunikation wahrscheinlich. Der Fehler liegt dann häufig bei der Namensauflösung, ihrer Konfiguration oder einem davon abhängigen Dienst. Typische Meldungen sind: - „Die Website ist nicht erreichbar.“ - „Der Server wurde nicht gefunden.“ - „Der Netzwerkname wurde nicht gefunden.“ - „Der Hostname kann nicht aufgelöst werden.“ - „Mit der IP-Adresse funktioniert es.“ - „Internet geht, aber interne Anwendungen nicht.“ - „Einige Namen funktionieren, andere nicht.“ Die Aussage „IP geht, Name geht nicht“ grenzt den Fehlerbereich ein. Sie beweist aber noch nicht, dass ausschließlich der DNS-Server defekt ist. --- **1. Technischer Zusammenhang** Anwendungen verwenden häufig Namen statt IP-Adressen. ```text Benutzer oder Anwendung ↓ fragt nach server.example.test ↓ Namensauflösung ↓ liefert eine IP-Adresse ↓ Verbindung zur IP-Adresse ``` Beispiel: ```text intranet.example.test → 192.0.2.40 ``` Kann der Client `192.0.2.40` erreichen, den Namen `intranet.example.test` jedoch nicht auflösen, müssen insbesondere folgende Bereiche untersucht werden: - DNS-Konfiguration des Clients, - Erreichbarkeit des DNS-Servers, - DNS-Dienst, - zuständige Zone, - benötigter Resource Record, - Weiterleitung oder Rekursion, - Suchsuffix, - lokale Namensquellen, - Cache, - Firewallregeln für DNS, - DNSSEC, - Split-DNS, - VPN- oder standortspezifische DNS-Konfiguration. --- **2. Fehlerbild zuerst bestätigen** Die Benutzeraussage muss durch konkrete Tests bestätigt werden. Zu dokumentieren sind: - exakter Name, - vollständiger Name oder Kurzname, - bekannte Ziel-IP-Adresse, - betroffene Anwendung, - Fehlermeldung, - Zeitpunkt, - betroffener Client, - verwendete Netzwerkverbindung, - verwendeter DNS-Server, - interne oder externe Namensauflösung, - Vergleich mit einem funktionierenden Client. Beispiel: ```text Name: fileserver.example.test IP-Adresse: 192.0.2.40 IP-Adresse erreichbar: ja Name auflösbar: nein DNS-Server: 192.0.2.10 Betroffener Client: PC-023 Vergleichsclient: PC-024 funktioniert ``` Ein Test mit einer IP-Adresse muss denselben Zielsystem- und Netzwerkpfad sinnvoll prüfen. Der Aufruf irgendeiner erreichbaren IP-Adresse ist kein ausreichender Vergleich. --- **3. IP-Erreichbarkeit und Namensauflösung getrennt prüfen** Zuerst wird geprüft, ob das Ziel grundsätzlich per IP erreichbar ist. **Windows** ```powershell ping Test-NetConnection Test-NetConnection -Port ``` **Linux und macOS** ```bash ping traceroute nc -vz ``` Danach wird derselbe Dienst über den Namen getestet. **Windows** ```powershell ping Resolve-DnsName Test-NetConnection -Port ``` **Linux und macOS** ```bash ping dig host nslookup ``` **Mögliche Einordnung** | Ergebnis | mögliche Einordnung | |---|---| | IP und Name funktionieren | Fehler liegt möglicherweise bei Anwendung, Port, Authentifizierung oder zeitweiligem Zustand | | IP funktioniert, Name wird nicht aufgelöst | Namensauflösung untersuchen | | Name wird korrekt aufgelöst, Verbindung scheitert | Zieladresse, Port, Firewall, Routing oder Anwendung untersuchen | | IP und Name scheitern | grundlegende IP-Verbindung, Routing, Firewall oder Zielsystem untersuchen | | Name liefert eine falsche IP-Adresse | DNS-Daten, Cache, Hosts-Datei oder Split-DNS untersuchen | | nur der Kurzname scheitert | DNS-Suffix oder Suchliste untersuchen | | vollständiger Name und Kurzname scheitern | DNS-Server, Zone, Record oder Transport untersuchen | > Eine erfolgreiche Namensauflösung beweist nicht, dass der Zielservice erreichbar ist. Sie bestätigt zunächst nur, dass eine Antwort für den Namen geliefert wurde. --- **4. Vollständigen Namen verwenden** Bei der Fehlersuche sollte zwischen Kurzname und Fully Qualified Domain Name unterschieden werden. Beispiel: ```text Kurzname: fileserver Vollständiger Name: fileserver.example.test ``` Funktioniert der vollständige Name, der Kurzname jedoch nicht, sind häufig folgende Bereiche betroffen: - DNS-Suffix fehlt, - falsches DNS-Suffix, - falsche Suchreihenfolge, - VPN stellt keine benötigte Suchdomäne bereit, - DHCP verteilt eine falsche Domänenoption, - Kurzname wird über eine andere Auflösungsmethode gesucht, - mehrere gleichnamige Geräte existieren in verschiedenen Domänen. **Windows** ```powershell ipconfig /all Get-DnsClientGlobalSetting Get-DnsClient ``` **Linux** ```bash cat /etc/resolv.conf resolvectl status ``` **macOS** ```bash scutil --dns ``` Zu prüfen sind: - primäres DNS-Suffix, - verbindungsspezifisches DNS-Suffix, - DNS-Suffixsuchliste, - Reihenfolge der Suchdomänen, - aktive Netzwerkschnittstelle, - vom DHCP-Server gelieferte Einstellungen, - vom VPN-Client ergänzte Einstellungen. --- **5. Konfigurierte DNS-Server prüfen** Ein Client muss die vorgesehenen DNS-Server verwenden. **Windows** ```powershell ipconfig /all Get-DnsClientServerAddress ``` **Linux** ```bash resolvectl status cat /etc/resolv.conf nmcli device show ``` **macOS** ```bash scutil --dns networksetup -getdnsservers ``` Zu prüfen sind: - richtige DNS-Serveradressen, - Reihenfolge der DNS-Server, - IPv4- und IPv6-Konfiguration, - statische oder dynamische Konfiguration, - DNS-Angaben aus DHCP, - DNS-Einstellungen des VPN-Clients, - lokale Resolver, - Sicherheitssoftware oder DNS-Filter, - unerwünschte öffentliche DNS-Server. In einer Active-Directory-Umgebung dürfen Clients für interne AD-Namen normalerweise nicht ausschließlich beliebige öffentliche DNS-Resolver verwenden. Ein öffentlicher Resolver kennt die internen DNS-Zonen nicht. --- **6. Jeden DNS-Server einzeln abfragen** Sind mehrere DNS-Server eingetragen, muss jeder Server gezielt getestet werden. **Windows** ```powershell Resolve-DnsName -Server Resolve-DnsName -Server ``` Alternativ: ```powershell nslookup nslookup ``` **Linux und macOS** ```bash dig @ dig @ ``` **Beispielhafte Auswertung** | DNS-Server 1 | DNS-Server 2 | mögliche Einordnung | |---|---|---| | richtige Antwort | richtige Antwort | DNS-Server grundsätzlich konsistent | | richtige Antwort | keine Antwort | zweiter Server, Netzwerkpfad oder Firewall | | richtige Antwort | falsche Antwort | abweichende Zone, Replikation oder veraltete Daten | | keine Antwort | keine Antwort | Erreichbarkeit, Dienst, Firewall oder Clientkonfiguration | | `NXDOMAIN` | richtige Antwort | inkonsistente Zonen oder verschiedene DNS-Sichten | | unterschiedliche IP-Adressen | möglicherweise Split-DNS, Replikationsfehler oder abweichende Records | > Ein Client wechselt nicht in jedem Fall zum nächsten DNS-Server, nur weil der erste Server eine fachlich falsche Antwort liefert. Eine erhaltene negative oder falsche Antwort ist etwas anderes als ein nicht antwortender Server. --- **7. Bedeutung häufiger DNS-Ergebnisse** DNS-Abfragen können unterschiedliche Rückmeldungen liefern. | Ergebnis | Bedeutung | möglicher Untersuchungsbereich | |---|---|---| | `NOERROR` mit Antwort | Name wurde beantwortet | zurückgegebene Daten auf Richtigkeit prüfen | | `NOERROR` ohne passende Antwort | Name oder Typ besitzt möglicherweise keinen entsprechenden Record | Record-Typ, Zone oder Alias prüfen | | `NXDOMAIN` | angefragter Name existiert aus Sicht des antwortenden Servers nicht | Schreibweise, Zone, Record, Cache oder falscher DNS-Server | | `SERVFAIL` | Server konnte die Anfrage nicht erfolgreich bearbeiten | DNSSEC, Delegation, Upstream-Server oder Serverfehler | | `REFUSED` | Server verweigert die Anfrage | Richtlinie, Rekursion, ACL oder nicht erlaubter Client | | Zeitüberschreitung | keine rechtzeitige DNS-Antwort | Erreichbarkeit, Port 53, Überlastung oder Dienst | | falsche IP-Adresse | Antwort vorhanden, aber ungeeignet | Record, Cache, Hosts-Datei, Split-DNS oder Replikation | | `CNAME` ohne erreichbares Endziel | Alias vorhanden, Zielname problematisch | CNAME-Kette und Zielzone untersuchen | Die Meldung `NXDOMAIN` bedeutet nicht automatisch, dass der gesamte DNS-Dienst ausgefallen ist. Der Server hat geantwortet, kennt den angefragten Namen jedoch nicht. --- **8. Record-Typ gezielt prüfen** DNS enthält verschiedene Resource Records. | Typ | Aufgabe | |---|---| | `A` | Name zu IPv4-Adresse | | `AAAA` | Name zu IPv6-Adresse | | `CNAME` | Alias auf einen anderen Namen | | `PTR` | IP-Adresse zu Name bei Rückwärtsauflösung | | `MX` | zuständiger Mailserver | | `NS` | autoritativer Nameserver einer Zone | | `SOA` | Verwaltungsinformationen einer Zone | | `SRV` | Dienst und zuständiger Server | | `TXT` | Textinformationen, Prüf- und Richtliniendaten | **Windows** ```powershell Resolve-DnsName -Type A Resolve-DnsName -Type AAAA Resolve-DnsName -Type CNAME Resolve-DnsName -Type NS Resolve-DnsName -Type SOA Resolve-DnsName -Type SRV ``` **Linux und macOS** ```bash dig A dig AAAA dig CNAME dig NS dig SOA dig SRV ``` Wenn eine Anwendung einen bestimmten Record-Typ benötigt, reicht die erfolgreiche Abfrage eines anderen Typs nicht aus. Beispielsweise können Active-Directory-Dienste von SRV-Records abhängig sein. Ein vorhandener A-Record des Domain Controllers beweist nicht, dass alle benötigten SRV-Records korrekt vorhanden sind. --- **9. DNS-Transport und Port 53 prüfen** DNS verwendet grundsätzlich: - UDP Port 53, - TCP Port 53. UDP wird häufig für normale Abfragen verwendet. TCP kann unter anderem bei größeren, abgeschnittenen oder bestimmten serverseitigen Übertragungen erforderlich sein. Zu prüfen sind: - Client erreicht DNS-Server per IP, - UDP Port 53 ist erlaubt, - TCP Port 53 ist erlaubt, - lokale Firewall blockiert nicht, - Netzwerk-Firewall blockiert nicht, - VPN erlaubt DNS-Verkehr, - DNS-Server lauscht auf der vorgesehenen Adresse, - Antwortpakete erreichen den Client, - NAT oder Sicherheitsfilter verändern den Verkehr nicht. **Windows** ```powershell Test-NetConnection -Port 53 ``` Dieser Test prüft TCP Port 53. Er ersetzt keine Prüfung von UDP-DNS. **Linux und macOS** ```bash dig @ dig +tcp @ ``` **Mögliche Beobachtungen** | Beobachtung | mögliche Einordnung | |---|---| | UDP-Abfrage funktioniert, TCP-Abfrage scheitert | Firewall oder Dienstkonfiguration für TCP 53 | | kleine Antworten funktionieren, größere nicht | TCP-Fallback, Fragmentierung, EDNS oder MTU | | Anfrage verlässt Client, keine Antwort sichtbar | DNS-Server, Rückweg oder Filter | | Antwort erreicht Netzwerkschnittstelle, Anwendung erhält sie nicht | lokale Firewall, Resolver oder Sicherheitssoftware | | DNS-Server ist per IP erreichbar, Port 53 antwortet nicht | Dienst, Firewall oder falsche Zieladresse | --- **10. Lokalen DNS-Cache prüfen** Clients und Resolver speichern DNS-Antworten für eine bestimmte Zeit. Auch negative Antworten können zwischengespeichert werden. Mögliche Symptome: - ein Client erhält eine alte Adresse, - andere Clients funktionieren bereits, - nach einer DNS-Änderung bleibt der Fehler bestehen, - der Name funktioniert nach Ablauf einer gewissen Zeit, - eine direkte Abfrage beim DNS-Server ist korrekt, die Anwendung verwendet aber weiterhin eine alte Antwort. **Windows** ```powershell ipconfig /displaydns Clear-DnsClientCache ``` Alternativ: ```powershell ipconfig /flushdns ``` **Linux mit systemd-resolved** ```bash resolvectl statistics sudo resolvectl flush-caches ``` **macOS** Die verwendeten Cache-Mechanismen können von der macOS-Version und dem aktiven Resolver abhängen. Vor einer Cache-Bereinigung sollte deshalb zuerst geprüft werden, ob eine direkte DNS-Abfrage bereits die korrekte Antwort liefert. > Das Leeren des Cache ist eine Prüf- oder Korrekturmaßnahme für zwischengespeicherte Daten. Es behebt keine fehlenden Records, falschen Zonen oder nicht erreichbaren DNS-Server. --- **11. Hosts-Datei berücksichtigen** Vor oder neben DNS können lokale Namensquellen eine Rolle spielen. Eine fehlerhafte Hosts-Datei kann DNS-Ergebnisse überlagern. **Windows** ```text C:\Windows\System32\drivers\etc\hosts ``` **Linux und macOS** ```text /etc/hosts ``` Zu prüfen sind: - Eintrag für den betroffenen Namen, - veraltete IP-Adresse, - Schreibfehler, - doppelte Einträge, - Einträge durch Softwareverteilung, - Manipulation durch Schadsoftware, - abweichender Eintrag nur auf einzelnen Clients. Die Hosts-Datei sollte nicht ungeprüft als dauerhafte Ersatzlösung für einen fehlerhaften DNS-Eintrag verwendet werden. Dadurch würde die zentrale Ursache verborgen und eine schwer wartbare Sonderkonfiguration geschaffen. --- **12. Zuständige Zone und autoritative Server prüfen** Für einen internen Namen muss die zuständige DNS-Zone vorhanden und auf den vorgesehenen Servern verfügbar sein. Zu prüfen sind: - existiert die Zone? - ist sie geladen? - enthält sie den benötigten Record? - ist der Record aktiviert und korrekt geschrieben? - zeigt der Record auf die richtige Adresse? - besitzt die Zone korrekte NS-Einträge? - ist die Delegation korrekt? - stimmen primäre und sekundäre Kopien überein? - funktioniert die Replikation? - ist die Seriennummer plausibel? - bestehen abgelaufene oder veraltete Zonendaten? - ist eine bedingte Weiterleitung erforderlich? - antwortet der abgefragte Server autoritativ? **Windows-DNS-Server** ```powershell Get-DnsServerZone Get-DnsServerResourceRecord -ZoneName Get-DnsServerForwarder ``` **Allgemeine Abfragen** ```bash dig NS dig SOA dig +trace ``` `dig +trace` zeigt eine schrittweise Auflösung über die DNS-Hierarchie. Für rein interne Zonen ist dieser Test nicht in derselben Weise geeignet wie für öffentlich delegierte Zonen. --- **13. Rekursion und Weiterleitungen prüfen** Ein interner DNS-Server kennt nicht automatisch alle externen Namen. Er verwendet je nach Konfiguration: - Rekursion, - Root Hints, - allgemeine Forwarder, - Conditional Forwarder, - Stub-Zonen, - interne Delegationen. Mögliche Fehlerbilder: - interne Namen funktionieren, externe nicht, - externe Namen funktionieren, eine Partnerdomäne nicht, - nur Namen einer bestimmten internen Zone scheitern, - Abfragen an den internen DNS-Server liefern `SERVFAIL`, - direkte Abfragen an einen öffentlichen Resolver funktionieren, - ein Forwarder ist nicht erreichbar, - eine bedingte Weiterleitung zeigt auf veraltete Server. **Abgrenzung** | Ergebnis | möglicher Bereich | |---|---| | interne und externe Namen scheitern | Client, DNS-Server, Dienst oder Transport | | interne Namen funktionieren, externe nicht | Rekursion, Forwarder, Root Hints oder Firewall | | externe Namen funktionieren, interne nicht | interne Zone, falscher DNS-Server oder Split-DNS | | nur eine Partnerdomäne scheitert | Conditional Forwarder, Delegation oder Partner-DNS | | nur einzelne Records fehlen | Zone, Replikation oder Record-Verwaltung | --- **14. Split-DNS berücksichtigen** Bei Split-DNS kann derselbe Name abhängig vom verwendeten DNS-Server oder Standort unterschiedliche Antworten liefern. Beispiel: ```text intern: portal.example.test → 192.0.2.50 extern: portal.example.test → 198.51.100.50 ``` Zu prüfen sind: - befindet sich der Client intern, extern oder im VPN? - welcher DNS-Server beantwortet die Anfrage? - wird die interne oder externe Zone verwendet? - ist die interne Adresse aus dem aktuellen Netz erreichbar? - wird über das VPN der richtige DNS-Server bereitgestellt? - verwendet der Browser oder die Anwendung einen eigenen DNS-Dienst? - existieren widersprüchliche Records? Ein korrekt funktionierender öffentlicher DNS-Eintrag beweist nicht, dass der interne Eintrag korrekt ist. --- **15. VPN und mehrere Netzwerkschnittstellen** VPN-Verbindungen können DNS-Einstellungen gezielt verändern. Mögliche Fehlerbilder: - interne Namen funktionieren nur mit aktivem VPN, - externe Namen funktionieren, interne nicht, - nach dem Trennen des VPN bleibt eine ungeeignete DNS-Konfiguration aktiv, - der Client fragt den DNS-Server der falschen Schnittstelle, - Split-Tunneling und Split-DNS passen nicht zusammen, - lokale und entfernte Netze verwenden dieselbe Domäne, - mehrere aktive Adapter besitzen widersprüchliche DNS-Suffixe. Zu prüfen sind: - DNS-Server jeder Schnittstelle, - Schnittstellenmetrik, - DNS-Suffixe, - vom VPN übermittelte Suchdomänen, - Routen zum internen DNS-Server, - Erreichbarkeit des DNS-Servers durch den Tunnel, - Richtlinien des VPN-Clients, - Zustand nach erneutem Verbindungsaufbau. **Windows** ```powershell Get-NetIPConfiguration Get-DnsClient Get-DnsClientServerAddress Get-NetRoute ``` **Linux** ```bash ip address ip route resolvectl status ``` **macOS** ```bash ifconfig netstat -rn scutil --dns ``` --- **16. IPv4 und IPv6 getrennt betrachten** Ein Name kann sowohl einen A- als auch einen AAAA-Record besitzen. Mögliche Fehlerbilder: - A-Record ist korrekt, AAAA-Record ist falsch, - Client bevorzugt IPv6, der IPv6-Pfad funktioniert jedoch nicht, - Anwendung erhält nur eine IPv6-Adresse, - DNS funktioniert, aber die zurückgegebene Adressfamilie ist nicht erreichbar, - IPv6-DNS-Server ist eingetragen, aber nicht erreichbar. Zu prüfen sind: ```powershell Resolve-DnsName -Type A Resolve-DnsName -Type AAAA ``` ```bash dig A dig AAAA ping -4 ping -6 ``` Das pauschale Deaktivieren von IPv6 ist keine fachgerechte Standardlösung. Zuerst muss bestätigt werden, ob tatsächlich ein fehlerhafter AAAA-Record, IPv6-DNS-Server oder IPv6-Datenpfad vorliegt. --- **17. DNSSEC prüfen** DNSSEC ermöglicht die Prüfung signierter DNS-Daten. Fehler bei Signaturen oder Vertrauenskette können zu `SERVFAIL` führen. Mögliche Ursachen: - abgelaufene Signatur, - fehlerhafter DS-Record, - nicht passende Schlüssel, - unvollständige Vertrauenskette, - falsche Systemzeit, - fehlerhafte Zone nach Schlüsselwechsel, - validierender Resolver verwirft die Antwort. **Linux und macOS mit dig** ```bash dig +dnssec dig +trace ``` Bei DNSSEC-Problemen sollten geprüft werden: - exakter Antwortcode, - gesetzte DNSSEC-Flags, - Systemzeit, - Signaturgültigkeit, - Delegation, - Verhalten eines validierenden und eines nicht validierenden Resolvers. DNSSEC darf nicht pauschal deaktiviert werden, ohne den Fehler einzugrenzen und die Sicherheitsauswirkung zu bewerten. --- **18. Browser und verschlüsseltes DNS** Ein Browser oder eine Sicherheitsanwendung kann einen eigenen DNS-Auflösungsweg verwenden, beispielsweise DNS over HTTPS. Mögliche Beobachtungen: - `Resolve-DnsName` oder `dig` liefert eine richtige Antwort, - nur ein bestimmter Browser verwendet eine falsche oder keine Antwort, - Browser und Betriebssystem zeigen unterschiedliche Ergebnisse, - interne Namen funktionieren in einer Anwendung, im Browser jedoch nicht, - DNS-Filter oder Proxy beeinflusst nur Webverkehr. Zu prüfen sind: - verwendet die Anwendung den Systemresolver? - ist verschlüsseltes DNS aktiviert? - welcher Resolver wird dabei verwendet? - kann dieser Resolver interne Zonen kennen? - besteht ein Proxy? - besitzt die Anwendung einen eigenen Cache? - greift eine Sicherheitsrichtlinie ein? Ein funktionierender Kommandozeilentest beweist daher nicht in jedem Fall, dass die betroffene Anwendung denselben Resolver und dieselben DNS-Daten verwendet. --- **19. mDNS, LLMNR und NetBIOS nicht mit DNS verwechseln** Kurznamen und lokale Gerätenamen können abhängig vom Betriebssystem auch über andere Verfahren aufgelöst werden. Mögliche Verfahren: - DNS, - lokale Hosts-Datei, - Multicast DNS, - Link-Local Multicast Name Resolution, - NetBIOS Name Service, - anwendungseigene Verzeichnisse. Wenn ein Kurzname funktioniert, ist damit nicht automatisch bewiesen, dass DNS funktioniert. Der Name könnte über ein anderes Verfahren aufgelöst worden sein. Für eine eindeutige DNS-Prüfung sollten gezielte Werkzeuge verwendet werden: ```powershell Resolve-DnsName -Server ``` ```bash dig @ ``` --- **20. Reverse DNS getrennt prüfen** Die Rückwärtsauflösung ordnet einer IP-Adresse einen Namen zu. Dafür werden PTR-Records verwendet. Beispiel: ```text 192.0.2.40 → fileserver.example.test ``` **Windows** ```powershell Resolve-DnsName -Type PTR ``` **Linux und macOS** ```bash dig -x ``` Eine fehlende Rückwärtsauflösung verhindert nicht grundsätzlich jede Verbindung zur IP-Adresse. Bestimmte Anwendungen, Protokollierungen, Authentifizierungsverfahren oder Sicherheitsprüfungen können jedoch von einem korrekten PTR-Record abhängen. Vorwärts- und Rückwärtsauflösung sind deshalb getrennt zu prüfen. --- **21. Active Directory und DNS** Active Directory ist stark von DNS abhängig. DNS-Fehler können unter anderem beeinträchtigen: - Domänenanmeldung, - Auffinden von Domain Controllern, - Gruppenrichtlinien, - Kerberos, - LDAP, - Replikation, - Datei- und Druckdienste, - Zertifikatsdienste, - Verwaltungswerkzeuge. Benötigt werden unter anderem SRV-Records. Beispielhafte Prüfung: ```powershell Resolve-DnsName _ldap._tcp.dc._msdcs. -Type SRV Resolve-DnsName _kerberos._tcp. -Type SRV ``` Zu prüfen sind: - verwendet der Client ausschließlich vorgesehene interne DNS-Server? - sind SRV-Records vorhanden? - sind die eingetragenen Domain Controller erreichbar? - stimmen Systemzeit und Domänenzugehörigkeit? - sind DNS-Zonen zwischen Domain Controllern repliziert? - existieren alte Records nicht mehr vorhandener Systeme? - funktioniert die dynamische DNS-Registrierung? --- **22. Dynamische DNS-Registrierung** Clients und Server können ihre Records dynamisch registrieren. Mögliche Fehlerbilder: - neuer Client besitzt noch keinen Record, - Record zeigt auf eine alte Adresse, - DHCP aktualisiert DNS nicht, - Client darf den Record nicht aktualisieren, - alter Record wurde nicht entfernt, - Gerät besitzt mehrere Schnittstellen und registriert eine ungeeignete Adresse, - Replikation verteilt den aktualisierten Record nicht. **Windows-Client** ```powershell ipconfig /registerdns ``` Vor der Verwendung ist zu prüfen: - soll der Client den Record selbst registrieren? - übernimmt DHCP die Registrierung? - besitzt der Client eine gültige DNS-Konfiguration? - ist die Zone für dynamische Updates eingerichtet? - bestehen ausreichende Berechtigungen? - existiert bereits ein Record mit abweichendem Besitzer? `ipconfig /registerdns` ist keine Lösung für einen falsch eingerichteten DNS-Server oder eine fehlende Zone. --- **23. Zeitabhängige und sporadische Fehler** Sporadische Namensauflösungsfehler können entstehen durch: - inkonsistente DNS-Server, - fehlerhafte Replikation, - abwechselnd richtige und falsche Antworten, - instabile Netzwerkverbindung, - Paketverlust, - überlasteten DNS-Server, - ablaufende oder erneuerte Cache-Einträge, - DNS-Round-Robin, - einen fehlerhaften Server hinter einem Load Balancer, - unterschiedliche VPN-Zustände, - zeitweise nicht erreichbare Forwarder. Sinnvoll sind wiederholte, zeitgestempelte Abfragen. **PowerShell** ```powershell 1..10 | ForEach-Object { Get-Date Resolve-DnsName -Server Start-Sleep -Seconds 2 } ``` **Bash** ```bash for i in {1..10}; do date dig @ sleep 2 done ``` Zu vergleichen sind: - Antwortcode, - Antwortadresse, - antwortender Server, - TTL, - Laufzeit, - Häufigkeit von Zeitüberschreitungen. --- **24. Paketaufzeichnung für DNS** Eine Paketaufzeichnung kann zeigen: - ob der Client eine Anfrage sendet, - welchen DNS-Server er verwendet, - welcher Name und Record-Typ angefragt wird, - ob die Anfrage UDP oder TCP verwendet, - ob eine Antwort zurückkommt, - welcher Antwortcode geliefert wird, - ob Wiederholungen auftreten, - ob verschiedene DNS-Server angesprochen werden, - ob die Antwort abgeschnitten ist, - ob der Client die Antwort verwirft. **Wireshark-Filter** ```text dns udp.port == 53 tcp.port == 53 dns.qry.name == "" ip.addr == ``` **Typische Beobachtungen** | Paketaufzeichnung | mögliche Einordnung | |---|---| | keine DNS-Anfrage | Anwendungscache, Hosts-Datei, anderer Resolver oder Anwendung sendet nicht | | Anfrage an falschen Server | Client-, DHCP-, VPN- oder Schnittstellenkonfiguration | | Anfrage, keine Antwort | Server, Transport, Firewall oder Rückweg | | Antwort `NXDOMAIN` | Server kennt den Namen nicht | | Antwort `SERVFAIL` | serverseitige Auflösung, DNSSEC oder Delegation | | richtige Antwort, Anwendung scheitert | Cache, Anwendung, Zielservice oder Datenpfad | | wiederholte Anfragen an mehrere Server | Antwortausfall oder Zeitüberschreitung | | UDP-Antwort abgeschnitten, TCP scheitert | TCP Port 53, Firewall oder MTU | Paketaufzeichnungen dürfen nur mit entsprechender Berechtigung erstellt und müssen geschützt gespeichert werden. --- **25. Praxisfall A: Nur ein Client kann einen internen Namen nicht auflösen** **Symptom** - Server ist per IP erreichbar, - vollständiger interner Name funktioniert auf anderen Clients, - nur ein Client ist betroffen, - externe Namen funktionieren. **Prüfung** 1. DNS-Server des betroffenen Clients prüfen. 2. mit funktionierendem Client vergleichen. 3. vollständigen Namen gezielt abfragen. 4. jeden eingetragenen DNS-Server einzeln testen. 5. DNS-Cache prüfen. 6. Hosts-Datei kontrollieren. 7. VPN- und Schnittstellenkonfiguration prüfen. 8. Paketaufzeichnung bei Bedarf durchführen. **Mögliche Ursache** Der Client verwendet aufgrund einer statischen Alt-Konfiguration einen öffentlichen DNS-Server. Dieser kann die interne Zone nicht auflösen. **Nachprüfung** - interner DNS-Server ist eingetragen, - vollständiger Name wird korrekt aufgelöst, - Kurzname funktioniert mit richtigem Suffix, - externe Namen funktionieren weiterhin, - ursprüngliche Anwendung ist erreichbar. --- **26. Praxisfall B: Interne Namen funktionieren, externe Namen nicht** **Symptom** - interne Servernamen werden korrekt aufgelöst, - externe Namen liefern `SERVFAIL` oder Zeitüberschreitungen, - Internetziele sind per IP erreichbar, - mehrere Clients sind betroffen. **Prüfung** 1. DNS-Server direkt abfragen. 2. interne und externe Namen vergleichen. 3. allgemeine Forwarder prüfen. 4. Erreichbarkeit der Forwarder untersuchen. 5. Rekursion und Root Hints kontrollieren. 6. Firewallregeln für UDP und TCP Port 53 prüfen. 7. Serverprotokolle auswerten. 8. DNSSEC-Fehler ausschließen. **Mögliche Ursache** Der interne DNS-Server kann interne Zonen selbst beantworten. Der konfigurierte Forwarder für externe Namen ist jedoch nicht mehr erreichbar. **Nachprüfung** - interne Namen funktionieren, - externe Namen funktionieren, - mehrere externe Domänen wurden geprüft, - UDP- und TCP-Abfragen sind möglich, - redundante Weiterleitung wurde bewertet, - Monitoring erkennt externe Auflösungsfehler. --- **27. Praxisfall C: Vollständiger Name funktioniert, Kurzname nicht** **Symptom** ```text fileserver.example.test → funktioniert fileserver → funktioniert nicht ``` **Prüfung** 1. DNS-Suffixsuchliste anzeigen. 2. verbindungsspezifisches Suffix prüfen. 3. DHCP-Optionen kontrollieren. 4. VPN-Konfiguration untersuchen. 5. mit funktionierendem Client vergleichen. 6. tatsächlich angefragte Namen in einer Paketaufzeichnung prüfen. **Mögliche Ursache** Nach einer DHCP-Änderung wird das interne DNS-Suffix nicht mehr an neue Clients verteilt. **Nachprüfung** - vollständiger Name funktioniert, - Kurzname wird um das richtige Suffix ergänzt, - neue DHCP-Lease enthält die vorgesehene Konfiguration, - andere Namensräume funktionieren weiterhin. --- **28. Praxisfall D: Einige Clients erhalten eine falsche IP-Adresse** **Symptom** - derselbe Name liefert unterschiedliche Adressen, - ein Teil der Clients erreicht den Dienst, - andere Clients verbinden sich mit einem alten Server, - beide DNS-Server antworten. **Prüfung** 1. beide DNS-Server einzeln abfragen. 2. Records und TTL vergleichen. 3. Zone und Replikationszustand prüfen. 4. Cache auf Clients und Resolvern berücksichtigen. 5. Hosts-Dateien ausschließen. 6. Split-DNS-Konfiguration prüfen. 7. Anwendung nach Korrektur erneut testen. **Mögliche Ursache** Ein DNS-Server besitzt aufgrund einer Replikationsstörung noch einen alten A-Record. **Nachprüfung** - alle vorgesehenen DNS-Server liefern dieselbe korrekte Antwort, - Replikation funktioniert, - alte Records sind entfernt, - Clients erreichen den vorgesehenen Dienst, - Ursache der Replikationsstörung ist dokumentiert. --- **29. Praxisfall E: DNS-Abfrage funktioniert, Browser nicht** **Symptom** - Systemwerkzeug liefert die richtige Adresse, - nur ein Browser kann den internen Namen nicht öffnen, - andere Anwendungen funktionieren, - der Browser verwendet verschlüsseltes DNS. **Prüfung** 1. Ergebnis des Systemresolvers dokumentieren. 2. Browser-DNS-Konfiguration prüfen. 3. verwendeten verschlüsselten Resolver bestimmen. 4. Browsercache berücksichtigen. 5. Proxy- und Sicherheitsrichtlinien kontrollieren. 6. vollständigen Namen im Browser testen. **Mögliche Ursache** Der Browser sendet DNS-over-HTTPS-Abfragen an einen öffentlichen Resolver, der die interne Zone nicht kennt. **Nachprüfung** - Browser verwendet die vorgesehene Unternehmensrichtlinie, - interne Namen werden aufgelöst, - externe Namen funktionieren, - System- und Browserauflösung liefern konsistente Ergebnisse. --- **30. Ungeeignete Sofortmaßnahmen** Problematisch sind insbesondere: - DNS-Server ungeprüft neu starten, - öffentliche DNS-Server dauerhaft auf internen Clients eintragen, - DNSSEC pauschal deaktivieren, - IPv6 pauschal deaktivieren, - Firewall für Port 53 vollständig öffnen, - fehlende Records durch lokale Hosts-Einträge auf vielen Clients ersetzen, - komplette Zonen neu erstellen, - Replikation ohne Sicherung zurücksetzen, - Caches löschen, ohne vorher den Ausgangszustand zu dokumentieren, - mehrere DNS-Server gleichzeitig verändern, - produktive Records ohne Prüfung löschen, - den DNS-Server als Ursache festlegen, obwohl der Name korrekt aufgelöst wird. Vor Änderungen sind zu sichern beziehungsweise zu dokumentieren: - aktuelle Clientkonfiguration, - verwendete DNS-Server, - Abfrageergebnisse, - zuständige Zone, - vorhandene Records, - TTL, - Replikationszustand, - Weiterleitungen, - Zeitpunkt und Umfang der Störung. --- **31. Vollständige Prüfreihenfolge** 1. exakten betroffenen Namen erfassen. 2. Kurzname und vollständigen Namen unterscheiden. 3. bekannte Ziel-IP-Adresse dokumentieren. 4. Ziel per IP-Adresse und benötigtem Port prüfen. 5. denselben Dienst über den Namen testen. 6. Fehlermeldung und Zeitpunkt dokumentieren. 7. betroffene und funktionierende Clients vergleichen. 8. konfigurierte DNS-Server feststellen. 9. jeden DNS-Server einzeln abfragen. 10. Antwortcode und zurückgegebene Records bewerten. 11. A- und AAAA-Records getrennt prüfen. 12. DNS-Suffix und Suchliste kontrollieren. 13. lokale Hosts-Datei prüfen. 14. Cache nur nach Dokumentation berücksichtigen. 15. Erreichbarkeit des DNS-Servers prüfen. 16. UDP und TCP Port 53 berücksichtigen. 17. zuständige Zone und Record untersuchen. 18. autoritative Server und Delegation prüfen. 19. Replikation zwischen DNS-Servern kontrollieren. 20. Rekursion, Forwarder oder Conditional Forwarder untersuchen. 21. Split-DNS und aktuellen Standort berücksichtigen. 22. VPN und mehrere Schnittstellen prüfen. 23. anwendungseigene Resolver oder verschlüsseltes DNS berücksichtigen. 24. bei Bedarf eine autorisierte Paketaufzeichnung erstellen. 25. konkrete Hypothese formulieren. 26. genau eine kontrollierbare Änderung durchführen. 27. DNS-Abfrage erneut testen. 28. ursprüngliche Anwendung erneut testen. 29. interne und externe Namen prüfen. 30. zweiten DNS-Server und Vergleichsclient prüfen. 31. Ursache, Maßnahme und Ergebnis dokumentieren. 32. Monitoring oder Präventionsmaßnahme festlegen. --- **32. Dokumentationsbeispiel** ```text Ticket: INC-20631 Beginn: 02.08.2026, etwa 10:35 Uhr Umfang: neu verbundene VPN-Clients Betroffen: interne Servernamen Nicht betroffen: externe DNS-Namen und direkte IP-Verbindungen Symptom: Der Server fileserver.example.test ist über 192.0.2.40 erreichbar. Der Name kann auf betroffenen VPN-Clients nicht aufgelöst werden. Ausgangszustand: - VPN-Tunnel aktiv - Route zum internen Server vorhanden - Server per IP und TCP Port 445 erreichbar - externe Namen werden aufgelöst - betroffene Clients verwenden einen öffentlichen DNS-Server - interne DNS-Server werden vom VPN nicht bereitgestellt - funktionierende interne Clients verwenden 192.0.2.10 und 192.0.2.11 Hypothese: Die VPN-Konfiguration übermittelt nicht die für interne Zonen zuständigen DNS-Server. Prüfung: - Resolve-DnsName über Standardkonfiguration liefert NXDOMAIN - direkte Abfrage an 192.0.2.10 liefert 192.0.2.40 - interne DNS-Server sind durch den Tunnel erreichbar - VPN-Profil besitzt keine DNS-Serverzuweisung - Änderung des VPN-Profils zum Fehlerzeitpunkt festgestellt Ursache: Bei einer Änderung des VPN-Profils wurden die internen DNS-Server und die interne Suchdomäne nicht übernommen. Maßnahme: Interne DNS-Server und Suchdomäne nach Freigabe wieder in das VPN-Profil aufgenommen. Nachprüfung: - vollständiger interner Name wird korrekt aufgelöst - Kurzname funktioniert über die vorgesehene Suchdomäne - Dateidienst ist über den Namen erreichbar - externe Namensauflösung funktioniert - erneuter VPN-Verbindungsaufbau erfolgreich - zweiter DNS-Server geprüft - mehrere VPN-Clients erfolgreich getestet Prävention: - DNS-Funktion in den VPN-Abnahmetest aufnehmen - interne und externe Testnamen überwachen - Änderungen an VPN-Profilen durch Peer-Review prüfen ``` --- **33. Checkliste „Name geht nicht, IP geht“** - [ ] der exakte betroffene Name wurde dokumentiert. - [ ] Kurzname und vollständiger Name wurden getrennt getestet. - [ ] die bekannte Ziel-IP-Adresse wurde geprüft. - [ ] der benötigte Zielport wurde berücksichtigt. - [ ] die Fehlermeldung wurde dokumentiert. - [ ] ein funktionierender Vergleichsclient wurde geprüft. - [ ] die verwendeten DNS-Server wurden festgestellt. - [ ] jeder DNS-Server wurde einzeln abgefragt. - [ ] Antwortcodes wurden ausgewertet. - [ ] A- und AAAA-Records wurden getrennt geprüft. - [ ] CNAME-Ketten wurden bei Bedarf verfolgt. - [ ] DNS-Suffix und Suchliste wurden kontrolliert. - [ ] DHCP- und VPN-DNS-Einstellungen wurden berücksichtigt. - [ ] die Hosts-Datei wurde geprüft. - [ ] der DNS-Cache wurde vor einer Bereinigung bewertet. - [ ] die Erreichbarkeit des DNS-Servers wurde geprüft. - [ ] UDP und TCP Port 53 wurden berücksichtigt. - [ ] die zuständige Zone wurde bestimmt. - [ ] der benötigte Resource Record wurde geprüft. - [ ] autoritative Server wurden ermittelt. - [ ] Delegation und Replikation wurden berücksichtigt. - [ ] Rekursion und Weiterleitungen wurden geprüft. - [ ] Split-DNS wurde berücksichtigt. - [ ] IPv4 und IPv6 wurden getrennt betrachtet. - [ ] DNSSEC wurde bei `SERVFAIL` berücksichtigt. - [ ] anwendungseigene oder verschlüsselte DNS-Auflösung wurde geprüft. - [ ] eine Paketaufzeichnung erfolgte nur mit Berechtigung. - [ ] vor Änderungen wurde der Ausgangszustand dokumentiert. - [ ] nur eine kontrollierbare Änderung wurde durchgeführt. - [ ] die DNS-Abfrage wurde nach der Änderung wiederholt. - [ ] die ursprüngliche Anwendung wurde erneut getestet. - [ ] weitere interne und externe Namen wurden geprüft. - [ ] Ursache, Maßnahme und Nachweis wurden dokumentiert. --- **34. Schnellreferenz** | Fehlerbild | wahrscheinlicher Untersuchungsbereich | |---|---| | IP funktioniert, vollständiger Name nicht | DNS-Server, Zone, Record oder DNS-Transport | | vollständiger Name funktioniert, Kurzname nicht | DNS-Suffix oder Suchliste | | interne Namen funktionieren, externe nicht | Forwarder, Rekursion, Root Hints oder Firewall | | externe Namen funktionieren, interne nicht | falscher DNS-Server, interne Zone oder Split-DNS | | nur ein Client betroffen | Clientkonfiguration, Cache, Hosts-Datei oder Anwendung | | alle Clients betroffen | zentraler DNS-Dienst, Zone, Netzwerkpfad oder Firewall | | nur VPN-Clients betroffen | VPN-DNS, Suchdomäne, Route oder Split-DNS | | ein DNS-Server liefert falsche Daten | Zone, Replikation oder veralteter Record | | `NXDOMAIN` | Name aus Sicht des antwortenden Servers nicht vorhanden | | `SERVFAIL` | Serververarbeitung, Delegation, Forwarder oder DNSSEC | | Zeitüberschreitung | Erreichbarkeit, Port 53, Überlastung oder Rückweg | | richtige IP wird geliefert, Dienst scheitert | kein reiner DNS-Fehler; Port, Firewall, Anwendung oder Zielsystem | | A funktioniert, AAAA führt zum Fehler | IPv6-Record oder IPv6-Datenpfad | | Kommandozeile funktioniert, Browser nicht | Browsercache, Proxy oder verschlüsseltes DNS | | wechselnde Antworten | mehrere DNS-Server, Round-Robin, Split-DNS oder Replikation | | Reverse Lookup scheitert | PTR-Record oder Reverse-Lookup-Zone | --- **Merksatz** > Wenn die IP-Adresse funktioniert, der Name aber nicht, wird die Namensauflösung gezielt und schichtweise geprüft: verwendeter DNS-Server, vollständiger Name, Antwortcode, Record, Zone, Weiterleitung und tatsächlicher Resolver. Eine erreichbare IP-Adresse grenzt den Fehler ein, beweist aber weder einen DNS-Server-Ausfall noch die Funktionsfähigkeit des angesprochenen Dienstes. --- **Quellen und weiterführende Dokumentation** - [Microsoft Learn – Guidance for troubleshooting DNS](https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/troubleshoot-dns-guidance) - [Microsoft Learn – Troubleshooting DNS clients](https://learn.microsoft.com/en-us/windows-server/networking/dns/troubleshoot/troubleshoot-dns-client) - [Microsoft Learn – Troubleshoot DNS client name resolution issues](https://learn.microsoft.com/en-us/troubleshoot/windows-client/networking/troubleshoot-dns-client-resolution-issues) - [Microsoft Learn – Troubleshooting DNS servers](https://learn.microsoft.com/en-us/windows-server/networking/dns/troubleshoot/troubleshoot-dns-server) - [Microsoft Learn – DNS forwarder-related resolution failures](https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/troubleshoot-dns-forwarders-related-failures) - [Microsoft Learn – Best practices for DNS client settings](https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/best-practices-for-dns-client-settings) - [RFC 1034 – Domain Names: Concepts and Facilities](https://www.rfc-editor.org/rfc/rfc1034) - [RFC 1035 – Domain Names: Implementation and Specification](https://www.rfc-editor.org/rfc/rfc1035) - [RFC 2181 – Clarifications to the DNS Specification](https://www.rfc-editor.org/rfc/rfc2181) - [RFC 9499 – DNS Terminology](https://www.rfc-editor.org/rfc/rfc9499) - [Wireshark – Display Filter Reference: DNS](https://www.wireshark.org/docs/dfref/d/dns.html) # 6.4 Host erreichbar, Dienst nicht – Ports, Firewall und Anwendungen systematisch prüfen Ein Zielsystem kann per IP-Adresse erreichbar sein, während der benötigte Dienst trotzdem nicht funktioniert. Typische Beispiele: - Ping auf den Server funktioniert, die Website öffnet sich jedoch nicht. - Der Servername wird korrekt aufgelöst, eine SSH-Verbindung scheitert aber. - Eine Dateifreigabe ist nicht erreichbar, obwohl der Server antwortet. - Die Anwendung meldet eine Zeitüberschreitung. - Ein TCP-Port ist erreichbar, die Anwendung liefert dennoch einen Fehler. - Der Dienst funktioniert lokal auf dem Server, aber nicht von anderen Geräten. - Einige Clients erreichen den Dienst, andere nicht. - Eine Verbindung funktioniert intern, über VPN oder Internet jedoch nicht. Die Erreichbarkeit eines Hosts und die Erreichbarkeit eines Dienstes sind getrennte Prüfungen. ```text Host erreichbar ↓ Zielport erreichbar ↓ TCP- oder UDP-Kommunikation funktioniert ↓ Dienst nimmt Anfragen an ↓ Anwendungsprotokoll funktioniert ↓ Authentifizierung und Berechtigung funktionieren ``` Ein erfolgreicher Ping bestätigt deshalb weder einen offenen Port noch einen funktionsfähigen Dienst. --- **1. Fehlerbild exakt erfassen** Vor der technischen Prüfung müssen die betroffene Verbindung und der erwartete Dienst eindeutig bestimmt werden. Zu dokumentieren sind: - Quellgerät, - Quell-IP-Adresse, - Zielname, - Ziel-IP-Adresse, - Zielport, - Transportprotokoll TCP oder UDP, - verwendete Anwendung, - Zeitpunkt des Fehlers, - genaue Fehlermeldung, - betroffene Benutzer oder Standorte, - funktionierende Vergleichsverbindungen, - letzte bekannte Funktionsfähigkeit, - kürzlich vorgenommene Änderungen. Beispiel: ```text Quelle: Client-17, 192.0.2.117 Ziel: appserver.example.test, 192.0.2.50 Dienst: HTTPS Transport: TCP Zielport: 443 Fehler: Verbindung nach etwa 20 Sekunden abgebrochen Betroffen: Clients im VLAN 30 Nicht betroffen: Clients im VLAN 20 ``` Die Aussage „Der Server geht nicht“ reicht nicht aus. Benötigt wird eine genaue Beschreibung der betroffenen Kommunikationsbeziehung. --- **2. Host-Erreichbarkeit und Dienst-Erreichbarkeit unterscheiden** Ein Ping verwendet ICMP. Anwendungsdienste verwenden dagegen meistens TCP oder UDP. Beispiel: ```text ping appserver.example.test ``` Ein erfolgreicher Ping kann bestätigen: - Namensauflösung liefert eine Adresse, - ICMP-Anfrage erreicht das Ziel, - ICMP-Antwort gelangt zurück. Er beweist nicht: - dass TCP Port 443 geöffnet ist, - dass eine Firewall den Anwendungsverkehr erlaubt, - dass der Webserver läuft, - dass TLS funktioniert, - dass die Anwendung eine gültige Antwort liefert, - dass der Benutzer zugriffsberechtigt ist. Umgekehrt kann ein Dienst funktionieren, obwohl Ping scheitert. ICMP kann gezielt blockiert sein, während der benötigte TCP- oder UDP-Port erlaubt bleibt. --- **3. Den tatsächlich benötigten Port bestimmen** Vor einem Porttest muss bekannt sein, welchen Zielport und welches Transportprotokoll die Anwendung verwendet. Beispiele: | Dienst | Transport | typischer Port | |---|---:|---:| | HTTP | TCP | 80 | | HTTPS | TCP | 443 | | SSH | TCP | 22 | | RDP | TCP und UDP | 3389 | | SMB | TCP | 445 | | DNS | UDP und TCP | 53 | | SMTP | TCP | 25 | | IMAP mit TLS | TCP | 993 | | PostgreSQL | TCP | 5432 | | MySQL | TCP | 3306 | | LDAP | TCP und teilweise UDP | 389 | | LDAPS | TCP | 636 | | NTP | UDP | 123 | | DHCP | UDP | 67 und 68 | Diese Ports sind typische Standardwerte. Anwendungen können abweichend konfiguriert sein. Zu prüfen sind daher: - Herstellerdokumentation, - Serverkonfiguration, - Reverse-Proxy-Konfiguration, - Container-Portzuordnung, - Load-Balancer-Konfiguration, - Firewallregeln, - tatsächlich geöffnete Sockets, - eventuell verwendete dynamische Ports. Ein Test des falschen Ports liefert keine verwertbare Aussage über den benötigten Dienst. --- **4. Zieladresse und Zielport gemeinsam prüfen** Ein Port gehört immer zu einer konkreten IP-Adresse und einem Transportprotokoll. ```text 192.0.2.50:443/TCP ``` Bei mehreren IP-Adressen muss geprüft werden, welche Adresse die Anwendung tatsächlich verwendet. Mögliche Fehler: - DNS liefert eine alte Adresse, - IPv6 wird gegenüber IPv4 bevorzugt, - der Dienst lauscht nur auf einer bestimmten Schnittstelle, - ein Load Balancer verwendet eine andere Adresse, - NAT leitet auf ein falsches Ziel weiter, - ein Client verwendet einen Proxy, - die Anwendung greift auf einen anderen Hostnamen zurück. Vor der Bewertung eines Porttests sollten deshalb Zielname und aufgelöste Adressen dokumentiert werden. **Windows** ```powershell Resolve-DnsName ``` **Linux und macOS** ```bash dig ``` --- **5. TCP-Port vom Client aus testen** **Windows** ```powershell Test-NetConnection -Port ``` Kurzform: ```powershell tnc -Port ``` Beispiel: ```powershell Test-NetConnection appserver.example.test -Port 443 ``` Wichtig ist insbesondere: ```text TcpTestSucceeded : True ``` oder: ```text TcpTestSucceeded : False ``` **PowerShell 7** ```powershell Test-Connection -TcpPort ``` **Linux und macOS** ```bash nc -vz ``` Beispiel: ```bash nc -vz appserver.example.test 443 ``` Alternativ kann bei bestimmten Diensten ein protokollspezifischer Test sinnvoller sein: ```bash curl -v http://:/ curl -vk https://:/ ``` > Ein erfolgreicher TCP-Porttest bestätigt zunächst nur, dass eine TCP-Verbindung aufgebaut werden konnte. Er beweist nicht, dass die Anwendung fachlich korrekt arbeitet. --- **6. TCP-Ergebnisse richtig einordnen** | Beobachtung | technische Bedeutung | möglicher Untersuchungsbereich | |---|---|---| | Verbindung erfolgreich | TCP-Verbindungsaufbau abgeschlossen | Anwendung, Protokoll, TLS, Authentifizierung oder Inhalt prüfen | | sofort abgelehnt | Ziel oder Zwischenkomponente sendet aktiv eine Ablehnung | kein Listener, falscher Port, Firewall mit Reject oder Dienst beendet | | Zeitüberschreitung | keine verwertbare Antwort innerhalb der Wartezeit | Firewall-Drop, Routing, Rückweg, NAT, Zielsystem oder Paketverlust | | Verbindung wird sofort zurückgesetzt | TCP-RST beendet die Verbindung | Dienst, Proxy, Firewall, Protokollfehler oder Anwendung | | Verbindung beginnt und bleibt hängen | TCP besteht, Anwendung antwortet nicht vollständig | Dienst, Backend, Überlastung, TLS, MTU oder Abhängigkeit | | Verbindung funktioniert nur per IP | Namensauflösung, Zertifikat, virtueller Host oder Proxy | | Verbindung funktioniert nur per Name | Anwendung benötigt Hostnamen, SNI oder virtuellen Host | | Port ist offen, Anwendung meldet Fehler | kein reiner Portfehler | Protokoll, Anwendung, Backend, Authentifizierung oder Berechtigung | Eine Zeitüberschreitung beweist nicht automatisch, dass eine Firewall die Verbindung blockiert. Auch ein fehlender Rückweg, ein falsches NAT-Ziel oder ein nicht reagierendes System kann dasselbe Verhalten verursachen. --- **7. TCP-Verbindungsaufbau verstehen** Der normale TCP-Verbindungsaufbau verwendet drei Schritte: ```text Client → Server: SYN Server → Client: SYN, ACK Client → Server: ACK ``` Danach kann die Anwendungsübertragung beginnen. Mögliche Abweichungen: | Paketfolge | mögliche Einordnung | |---|---| | SYN, SYN/ACK, ACK | TCP-Verbindung wurde aufgebaut | | wiederholte SYN-Pakete ohne Antwort | Paketverlust, Firewall-Drop, Routing, Ziel oder Rückweg | | SYN, danach RST/ACK | Port geschlossen oder Verbindung aktiv abgelehnt | | SYN, SYN/ACK, danach kein ACK | Rückweg zum Client, Client-Firewall oder asymmetrischer Pfad | | vollständiger Handshake, danach RST | Anwendung, Proxy oder Protokoll beendet die Verbindung | | vollständiger Handshake, keine Nutzdatenantwort | Dienst hängt, Backend wartet oder Anwendungsproblem | | wiederholte Übertragungen | Paketverlust, Überlastung, MTU oder instabiler Datenpfad | Diese Unterscheidung ist mit einer Paketaufzeichnung möglich. --- **8. UDP-Dienste getrennt betrachten** UDP besitzt keinen TCP-Handshake. Deshalb lässt sich ein UDP-Port nicht genauso zuverlässig wie ein TCP-Port mit einem einfachen Verbindungsversuch bewerten. Beispiel: ```bash nc -vzu ``` Ein solcher Test kann Pakete senden. Eine Erfolgsmeldung beweist jedoch nicht zwingend, dass: - der UDP-Dienst läuft, - das Paket den Server erreicht, - der Dienst die Anfrage verarbeitet, - eine Antwort zurückkommt, - die Anwendung das richtige Protokoll gesendet hat. Für UDP sollte möglichst ein protokollspezifisches Werkzeug verwendet werden. Beispiele: **DNS** ```bash dig @ ``` **NTP** ```bash ntpdate -q ``` Je nach System können andere Werkzeuge erforderlich sein. Mögliche UDP-Ergebnisse: | Beobachtung | mögliche Einordnung | |---|---| | gültige Anwendungsantwort | Hin- und Rückweg sowie Dienst grundsätzlich funktionsfähig | | ICMP Port Unreachable | am Zielport lauscht wahrscheinlich kein UDP-Dienst | | keine Antwort | Dienst antwortet nicht, Firewall, Paketverlust, falsche Anfrage oder Protokollverhalten | | Antwort nur bei kleinen Anfragen | Fragmentierung, MTU, EDNS oder Filter | | lokal funktioniert, entfernt nicht | Bind-Adresse, Firewall, Routing oder Zugriffsliste | Keine UDP-Antwort ist deshalb weniger eindeutig als eine erfolgreiche oder abgelehnte TCP-Verbindung. --- **9. Auf dem Server prüfen, ob der Dienst lauscht** Ein Dienst muss einen Socket auf der vorgesehenen Adresse und dem vorgesehenen Port geöffnet haben. **Windows** ```powershell Get-NetTCPConnection -State Listen Get-NetTCPConnection -LocalPort Get-NetUDPEndpoint -LocalPort ``` Alternativ: ```powershell netstat -ano netstat -ano | findstr : ``` Die zugehörige Prozess-ID kann geprüft werden mit: ```powershell Get-Process -Id ``` oder: ```cmd tasklist /FI "PID eq " ``` **Linux** ```bash ss -lntp ss -lntp 'sport = :' ss -lnup ``` Alternativ: ```bash sudo lsof -nP -iTCP: -sTCP:LISTEN sudo lsof -nP -iUDP: ``` **macOS** ```bash sudo lsof -nP -iTCP: -sTCP:LISTEN sudo lsof -nP -iUDP: ``` Zu prüfen sind: - ist ein Listener vorhanden? - ist es der erwartete Prozess? - verwendet er TCP oder UDP? - lauscht er auf dem erwarteten Port? - lauscht er auf der richtigen IP-Adresse? - verwendet er IPv4, IPv6 oder beides? - läuft möglicherweise ein anderer Prozess auf dem Port? - wurde die Konfiguration nach einer Änderung neu geladen? --- **10. Bind-Adresse richtig bewerten** Ein Dienst kann auf unterschiedlichen Adressen lauschen. Beispiele: ```text 127.0.0.1:8080 0.0.0.0:8080 192.0.2.50:8080 [::1]:8080 [::]:8080 ``` Typische Bedeutung: | Bind-Adresse | Bedeutung | |---|---| | `127.0.0.1` | nur lokales IPv4-Loopback | | `0.0.0.0` | grundsätzlich alle IPv4-Schnittstellen | | konkrete IPv4-Adresse | nur diese IPv4-Adresse | | `::1` | nur lokales IPv6-Loopback | | `::` | grundsätzlich IPv6 und abhängig vom System eventuell zusätzlich IPv4 | Ein Dienst, der ausschließlich auf `127.0.0.1` lauscht, kann lokal funktionieren und von entfernten Clients trotzdem nicht erreichbar sein. Nach Änderungen an Netzwerkschnittstellen oder IP-Adressen kann ein Dienst weiterhin an eine nicht mehr vorhandene oder falsche Adresse gebunden sein. --- **11. Dienststatus und Protokolle prüfen** Ein vorhandener Prozess bedeutet nicht automatisch, dass der Dienst betriebsbereit ist. **Windows** ```powershell Get-Service Get-Service -Name ``` **Linux mit systemd** ```bash systemctl status journalctl -u ``` **macOS** Je nach Installationsart können `launchctl`, anwendungseigene Werkzeuge oder Protokolldateien verwendet werden. Zu prüfen sind: - Dienststatus, - Startzeitpunkt, - wiederholte Neustarts, - Konfigurationsfehler, - fehlende Zertifikate, - belegter Port, - fehlende Berechtigungen, - nicht erreichbare Datenbank, - nicht erreichbarer Verzeichnisdienst, - Speicher- oder Datenträgerprobleme, - abgelaufene Lizenzen, - erschöpfte Verbindungen, - interne Warteschlangen, - Fehler unmittelbar zum Störungszeitpunkt. Ein Dienst kann als „running“ angezeigt werden und dennoch keine funktionsfähigen Anfragen bearbeiten. --- **12. Dienst lokal auf dem Server testen** Der lokale Test trennt die Anwendung vom entfernten Netzwerkpfad. Beispiele: ```bash curl -v http://127.0.0.1:/ curl -vk https://127.0.0.1:/ ``` Oder: ```bash nc -vz 127.0.0.1 nc -vz ``` Sinnvolle Vergleichstests: 1. Verbindung über `localhost`, 2. Verbindung über Loopback-Adresse, 3. Verbindung über die Server-IP, 4. Verbindung über den vollständigen Namen, 5. Verbindung von einem Client im selben Netz, 6. Verbindung aus dem betroffenen Netz. | Ergebnis | mögliche Einordnung | |---|---| | lokal und entfernt scheitern | Dienst, Listener oder lokale Konfiguration | | Loopback funktioniert, Server-IP lokal nicht | Bind-Adresse oder lokale Firewall | | lokal funktioniert, entfernt nicht | Firewall, Routing, ACL, NAT oder Netzwerkpfad | | IP funktioniert, Name nicht | DNS, virtueller Host, SNI oder Zertifikat | | Porttest funktioniert, Protokolltest nicht | Anwendung oder Protokoll | | ein Netz funktioniert, anderes nicht | Firewallregel, Routing, Segmentierung oder Rückweg | --- **13. Lokale Firewall des Servers prüfen** Auch wenn der Dienst lauscht, kann die lokale Firewall eingehende Verbindungen blockieren. Zu prüfen sind: - richtige Richtung der Regel, - richtiges Transportprotokoll, - richtiger lokaler Port, - richtige Quellnetze, - richtiges Netzwerkprofil, - richtige Anwendung oder Dienstzuordnung, - IPv4 und IPv6, - aktive Firewallzone, - Priorität und Reihenfolge der Regeln, - protokollierte Ablehnungen, - zentrale Richtlinien. **Windows** ```powershell Get-NetFirewallProfile Get-NetFirewallRule -Enabled True Get-NetFirewallPortFilter Get-NetFirewallAddressFilter ``` Eine genauere Zuordnung kann über gemeinsame Filter- und Regelobjekte erforderlich sein. **Linux mit firewalld** ```bash sudo firewall-cmd --get-active-zones sudo firewall-cmd --list-all ``` **Linux mit nftables** ```bash sudo nft list ruleset ``` **Linux mit iptables** ```bash sudo iptables -L -n -v sudo ip6tables -L -n -v ``` Firewallregeln sollten nicht pauschal deaktiviert werden. Eine kontrollierte, auf Quelle, Ziel, Port und Protokoll begrenzte Prüfung ist vorzuziehen. --- **14. Client-Firewall und Ausgangsregeln** Nicht nur der Server kann Verbindungen blockieren. Auch auf dem Client können ausgehende Regeln, Sicherheitssoftware oder Endpoint-Richtlinien wirken. Mögliche Ursachen: - ausgehender Zielport gesperrt, - Anwendung darf keine Verbindung herstellen, - Netzwerkprofil wurde geändert, - Sicherheitssoftware blockiert den Prozess, - TLS-Inspection greift ein, - lokale Proxyrichtlinie erzwingt einen anderen Pfad, - Host-Firewall verwirft Rückpakete, - EDR-System beendet die Verbindung. Wenn andere Anwendungen denselben Zielport erreichen, die betroffene Anwendung aber nicht, sollte zusätzlich eine prozessbezogene Einschränkung untersucht werden. --- **15. Netzwerk-Firewalls und ACLs** Zwischen Client und Server können mehrere Kontrollstellen liegen: ```text Client ↓ Client-Firewall ↓ VLAN- oder Router-ACL ↓ zentrale Firewall ↓ VPN-Gateway oder NAT ↓ Server-Firewall ↓ Dienst ``` Zu prüfen sind: - Quell-IP-Adresse, - Ziel-IP-Adresse, - Zielport, - Transportprotokoll, - Sicherheitszone, - Regelreihenfolge, - Zeitplan der Regel, - Benutzer- oder Anwendungsabhängigkeit, - NAT vor oder nach der Regelprüfung, - Sitzungsstatus, - Trefferzähler, - Protokolleinträge, - Rückweg. Eine Regel für TCP Port 443 erlaubt nicht automatisch UDP Port 443. Ebenso erlaubt eine Regel für IPv4 nicht zwingend IPv6-Verkehr. --- **16. Stateful Firewall und Rückverkehr** Stateful Firewalls verfolgen den Zustand einer Verbindung. Bei einer erlaubten ausgehenden TCP-Verbindung wird der passende Rückverkehr normalerweise über den Verbindungszustand zugeordnet. Fehler können entstehen durch: - asymmetrisches Routing, - Rückpakete passieren eine andere Firewall, - Firewallzustand ist abgelaufen, - NAT-Zuordnung fehlt, - Clusterknoten teilen Zustände nicht korrekt, - Quelladresse wird unerwartet geändert, - Verbindung bleibt länger inaktiv als der Session-Timeout, - Rückverkehr entspricht nicht der gespeicherten Sitzung. Typisches Symptom: ```text Client sendet SYN. Server antwortet mit SYN/ACK. Client erhält die Antwort nicht. ``` In diesem Fall ist der Dienst erreichbar, aber der Rückweg oder eine zustandsabhängige Verarbeitung ist gestört. --- **17. Routing und Rückweg prüfen** Ein erreichbarer Host über ICMP bedeutet nicht, dass jeder Anwendungsverkehr denselben Pfad nimmt oder gleich behandelt wird. **Windows** ```powershell tracert Test-NetConnection -TraceRoute Get-NetRoute ``` **Linux** ```bash traceroute tracepath ip route ip route get ``` **macOS** ```bash traceroute netstat -rn route -n get ``` Zu prüfen sind: - Route vom Client zum Server, - Rückroute vom Server zum Client, - Quell-IP-Auswahl, - mehrere Standardgateways, - Policy-Based Routing, - VPN-Routen, - überlappende Netze, - asymmetrische Wege, - segmentabhängige Firewallregeln. Die Rückroute muss vom Server oder seinem Gateway zum tatsächlichen Quellnetz führen. --- **18. NAT und Portweiterleitung** Bei Verbindungen über Netzgrenzen kann NAT die Ziel- oder Quelladresse verändern. Beispiel: ```text öffentliche Adresse: 198.51.100.20:443 NAT-Ziel: 192.0.2.50:8443 ``` Zu prüfen sind: - richtige öffentliche Zieladresse, - richtiger externer Port, - richtiges internes Ziel, - richtiger interner Port, - TCP oder UDP, - Quell-NAT, - Rückroute, - Firewallregel passend zur NAT-Verarbeitung, - konkurrierende Portweiterleitung, - Hairpin-NAT bei Zugriff von intern, - Ablauf der NAT-Sitzung. Ein lokal erreichbarer Dienst beweist nicht, dass die Portweiterleitung korrekt ist. --- **19. Container und virtuelle Maschinen** Bei containerisierten oder virtualisierten Diensten existieren zusätzliche Netzwerkschichten. Mögliche Fehler: - Container läuft, Port wurde aber nicht veröffentlicht, - Host-Port zeigt auf den falschen Container-Port, - Dienst lauscht im Container nur auf Loopback, - Container-Netzwerk fehlt, - Firewall auf dem Host blockiert, - Reverse Proxy erreicht den Container nicht, - falscher DNS-Name im internen Netzwerk, - virtuelle Maschine besitzt eine andere IP-Adresse, - Sicherheitsgruppe erlaubt den Port nicht, - Dienst wurde auf einen anderen Host verschoben. **Docker** ```bash docker ps docker port docker inspect ``` Beispiel einer Portzuordnung: ```text 0.0.0.0:8443 → Container:443/TCP ``` Ein Test auf Host-Port 443 wäre in diesem Beispiel ungeeignet, wenn der Dienst ausschließlich über Host-Port 8443 veröffentlicht wurde. --- **20. Reverse Proxy und Load Balancer** Zwischen Client und Anwendung können Reverse Proxy oder Load Balancer liegen. ```text Client ↓ Reverse Proxy oder Load Balancer ↓ Backend-Anwendung ``` Mögliche Fehlerbilder: - Frontend-Port ist erreichbar, Backend jedoch nicht, - falscher Hostname wird weitergeleitet, - Health Check schlägt fehl, - Backend-Port wurde geändert, - Zertifikat passt nicht, - virtuelle Hostkonfiguration fehlt, - Proxy-Zeitüberschreitung ist zu kurz, - ein einzelner Backend-Server ist fehlerhaft, - Sitzungspersistenz führt zu einem defekten Knoten, - Proxy liefert `502`, `503` oder `504`. Typische HTTP-Ergebnisse: | Ergebnis | mögliche Einordnung | |---|---| | `200` | Anfrage grundsätzlich erfolgreich | | `301` oder `302` | Weiterleitung prüfen | | `400` | Anfrage oder Hostheader ungeeignet | | `401` | Authentifizierung erforderlich oder fehlgeschlagen | | `403` | Zugriff durch Anwendung oder Richtlinie verweigert | | `404` | Pfad, virtueller Host oder Routingregel | | `502` | Proxy erhält keine gültige Backend-Antwort | | `503` | Dienst oder Backend nicht verfügbar | | `504` | Zeitüberschreitung zum Backend | Ein erreichbarer Proxy-Port beweist nicht, dass das Backend funktioniert. --- **21. TLS und Zertifikate prüfen** Bei verschlüsselten Diensten folgt nach dem TCP-Verbindungsaufbau der TLS-Handshake. Mögliche Fehler: - Zertifikat abgelaufen, - Zertifikatsname passt nicht zum Hostnamen, - Zertifikatskette unvollständig, - unbekannte Zertifizierungsstelle, - Client- und Serverprotokolle nicht kompatibel, - keine gemeinsame Cipher Suite, - Server Name Indication fehlt oder ist falsch, - Clientzertifikat erforderlich, - TLS-Inspection verändert die Verbindung, - Systemzeit ist falsch. **curl** ```bash curl -vk https://:/ ``` **OpenSSL** ```bash openssl s_client -connect : -servername ``` Dabei können geprüft werden: - ausgehandeltes TLS-Protokoll, - präsentierte Zertifikatskette, - Zertifikatsname, - Gültigkeitszeitraum, - Serverantwort, - Abbruchstelle. Die Option `-k` bei `curl` überspringt die Zertifikatsprüfung und darf nur zur Eingrenzung verwendet werden. Sie ist keine dauerhafte Lösung für Zertifikatsfehler. --- **22. Hostname, SNI und virtuelle Hosts** Mehrere Webanwendungen können dieselbe IP-Adresse und denselben Port verwenden. Der richtige Dienst wird dann anhand des Hostnamens ausgewählt. Beispiel: ```text portal.example.test → 192.0.2.50 wiki.example.test → 192.0.2.50 ``` Ein Test ausschließlich gegen die IP-Adresse kann deshalb: - die falsche Website liefern, - einen Zertifikatsfehler erzeugen, - die Standardseite des Proxys anzeigen, - mit einem HTTP-Fehler enden, - den falschen virtuellen Host verwenden. Geeigneter Test: ```bash curl -vk https://portal.example.test/ ``` Soll eine bestimmte IP-Adresse mit dem korrekten Hostnamen getestet werden: ```bash curl -vk --resolve portal.example.test:443:192.0.2.50 https://portal.example.test/ ``` Damit werden DNS, Ziel-IP, Hostheader und SNI kontrolliert voneinander getrennt. --- **23. Anwendung und Abhängigkeiten prüfen** Ein Dienst kann den Port öffnen, aber intern von weiteren Komponenten abhängig sein. Beispiele: - Datenbank, - Verzeichnisdienst, - DNS, - Dateispeicher, - Nachrichtenwarteschlange, - API, - Lizenzserver, - externer Identitätsanbieter, - Zertifikatsdienst, - weiterer Microservice. Mögliche Symptome: - TCP-Verbindung wird aufgebaut, - Loginseite erscheint, - Anmeldung scheitert, - Anfrage endet mit `500`, - Antwort dauert sehr lange, - nur bestimmte Funktionen sind betroffen, - Health Check meldet Fehler, - Dienst startet, wird aber nicht „ready“. Die Prüfung muss deshalb vom Frontend bis zu den tatsächlich benötigten Abhängigkeiten fortgesetzt werden. --- **24. Authentifizierung und Berechtigung abgrenzen** Eine erfolgreiche Netzwerkverbindung beweist nicht, dass der Benutzer oder Client den Dienst verwenden darf. Zu unterscheiden sind: - Zielport nicht erreichbar, - TLS-Verbindung fehlerhaft, - Benutzer nicht authentifiziert, - falsche Anmeldedaten, - Konto gesperrt, - fehlende Gruppenmitgliedschaft, - Zugriff durch Anwendung verweigert, - Zugriff durch Netzwerkregel verweigert, - Kerberos- oder Zertifikatsfehler, - Mandanten- oder Rollenproblem. Beispiele: ```text Connection timed out ``` weist eher auf Transport oder fehlende Antwort hin. ```text 401 Unauthorized ``` zeigt dagegen, dass eine HTTP-Antwort des Dienstes empfangen wurde und die Untersuchung auf Anwendungsebene fortgesetzt werden muss. --- **25. IPv4 und IPv6 getrennt prüfen** Ein Dienst kann für IPv4 und IPv6 unterschiedlich erreichbar sein. **Windows** ```powershell Resolve-DnsName -Type A Resolve-DnsName -Type AAAA Test-NetConnection -Port Test-NetConnection -Port ``` **Linux und macOS** ```bash curl -4 -v https:/// curl -6 -v https:/// nc -4 -vz nc -6 -vz ``` Mögliche Ursachen: - Dienst lauscht nur auf IPv4, - Dienst lauscht nur auf IPv6, - AAAA-Record zeigt auf eine falsche Adresse, - IPv6-Firewallregel fehlt, - IPv6-Rückroute fehlt, - Client bevorzugt einen nicht funktionsfähigen IPv6-Pfad. IPv6 sollte nicht pauschal deaktiviert werden. Zuerst ist nachzuweisen, welche Adressfamilie den Fehler verursacht. --- **26. MTU, Fragmentierung und große Datenmengen** Ein TCP-Handshake kann funktionieren, während größere Datenübertragungen scheitern. Mögliche Symptome: - Porttest erfolgreich, - kleine Anfragen funktionieren, - TLS-Handshake bleibt hängen, - Dateiübertragung bricht ab, - bestimmte Webseiten laden nur teilweise, - Verbindung über VPN scheitert bei größeren Paketen, - wiederholte TCP-Übertragungen treten auf. Mögliche Ursachen: - ungeeignete MTU, - blockierte ICMP-Meldungen für Path MTU Discovery, - Fragmentierung, - Tunnel-Overhead, - fehlerhafte MSS-Anpassung, - Paketverlust, - Sicherheitskomponente verwirft größere Pakete. **Linux** ```bash tracepath ``` **Windows** ```powershell ping -f -l ``` Der verwendbare Wert hängt von Protokoll-Headern und Datenpfad ab. Ein einzelner Pingwert darf deshalb nicht ungeprüft als endgültige MTU übernommen werden. --- **27. Proxys und anwendungsspezifische Netzwerkwege** Eine Anwendung kann einen anderen Netzwerkpfad verwenden als ein einfacher Porttest. Mögliche Unterschiede: - HTTP-Proxy, - SOCKS-Proxy, - automatische Proxykonfiguration, - VPN-Tunnel, - DNS over HTTPS, - anwendungseigener Resolver, - Service Mesh, - TLS-Inspection, - Cloud-Gateway, - Zero-Trust-Zugriff. Zu prüfen sind: - verwendet die Anwendung einen Proxy? - umgeht das Testwerkzeug den Proxy? - wird der Zielname durch den Proxy aufgelöst? - ist der Proxy selbst erreichbar? - erlaubt der Proxy den Zielport? - existiert eine Ausnahmeliste? - wird die Verbindung durch Benutzer- oder Gerätestatus gesteuert? Ein erfolgreicher direkter Test beweist nicht, dass der von der Anwendung verwendete Proxyweg funktioniert. --- **28. Sporadische und lastabhängige Fehler** Nicht jeder Dienstfehler besteht dauerhaft. Mögliche Ursachen: - Verbindungsgrenze erreicht, - Quellports erschöpft, - überlasteter Server, - Load Balancer verteilt auf einen defekten Knoten, - Firewall-Sitzungstabelle ausgelastet, - Paketverlust, - Dienst startet wiederholt neu, - Datenbankverbindungen erschöpft, - Timeouts zwischen Proxy und Backend, - DNS liefert wechselnde Ziele, - automatische Skalierung reagiert zu langsam. **Windows** ```powershell Get-NetTCPConnection Get-Counter '\TCPv4\Connections Established' ``` **Linux** ```bash ss -s ss -ant ``` Wiederholte Tests sollten mit Zeitstempel durchgeführt werden. **PowerShell** ```powershell 1..10 | ForEach-Object { Get-Date Test-NetConnection -Port Start-Sleep -Seconds 2 } ``` **Bash** ```bash for i in {1..10}; do date nc -vz sleep 2 done ``` Zu vergleichen sind: - Erfolg oder Fehler, - Antwortzeit, - Zieladresse, - betroffener Backend-Server, - Zeitpunkt, - gleichzeitige Last, - Firewall- und Anwendungsprotokolle. --- **29. Paketaufzeichnung einsetzen** Eine Paketaufzeichnung kann zeigen: - ob der Client ein SYN sendet, - ob das Ziel mit SYN/ACK oder RST antwortet, - ob Pakete erneut übertragen werden, - ob die Verbindung nach dem Handshake abbricht, - ob TLS beginnt, - ob eine Anwendungsantwort zurückkommt, - ob ICMP-Fehlermeldungen auftreten, - ob IPv4 oder IPv6 verwendet wird, - ob die tatsächliche Zieladresse stimmt, - ob Hin- und Rückweg vollständig sind. **Wireshark-Filter** ```text ip.addr == tcp.port == udp.port == tcp.flags.syn == 1 tcp.flags.reset == 1 tcp.analysis.retransmission icmp icmpv6 tls http ``` Für eine einzelne TCP-Verbindung kann nach Auswahl eines Pakets zusätzlich der zugehörige TCP-Stream gefiltert werden. **Typische Beobachtungen** | Paketaufzeichnung | mögliche Einordnung | |---|---| | kein Verbindungsversuch sichtbar | Anwendung, Proxy, Cache oder falsche Schnittstelle | | SYN verlässt Client, keine Antwort | Firewall-Drop, Routing, Ziel oder Rückweg | | SYN wird mit RST beantwortet | kein Listener oder aktive Ablehnung | | SYN/ACK erreicht Client, Client antwortet nicht | Client-Firewall, lokaler Stack oder falscher Zustand | | TCP-Handshake vollständig, danach TLS-Fehler | Zertifikat, SNI, Protokoll oder Cipher | | TCP-Handshake vollständig, HTTP `401` | Authentifizierung | | TCP-Handshake vollständig, HTTP `403` | Berechtigung oder Richtlinie | | TCP-Handshake vollständig, HTTP `502` | Proxy- oder Backend-Problem | | viele Wiederholungen | Paketverlust, Überlastung, MTU oder Datenpfad | | Verbindung wird durch RST beendet | Anwendung, Firewall, Proxy oder Betriebssystem | Paketaufzeichnungen dürfen nur mit entsprechender Berechtigung erstellt und müssen geschützt gespeichert werden. --- **30. Vergleichstests systematisch verwenden** Vergleichstests helfen, die fehlerhafte Grenze einzugrenzen. Sinnvolle Vergleiche: | Vergleich | mögliche Erkenntnis | |---|---| | betroffener und funktionierender Client | Clientkonfiguration oder Netzsegment | | Zielname und Ziel-IP | DNS, SNI oder virtueller Host | | IPv4 und IPv6 | Adressfamilie oder Datenpfad | | lokaler und entfernter Zugriff | Dienst oder Netzwerk | | gleiches VLAN und anderes VLAN | Routing, ACL oder Firewall | | internes Netz und VPN | VPN-Regel, Route oder DNS | | Frontend und Backend direkt | Proxy oder Load Balancer | | erster und zweiter Server | einzelnes Zielsystem oder zentraler Pfad | | kleiner und großer Datentransfer | MTU, Paketverlust oder Überlastung | | TCP-Porttest und Protokolltest | Transport oder Anwendung | Dabei sollte jeweils nur eine Variable verändert werden. --- **31. Praxisfall A: Ping funktioniert, HTTPS-Port nicht** **Symptom** - Server antwortet auf Ping, - Name wird korrekt aufgelöst, - TCP Port 443 läuft in eine Zeitüberschreitung, - andere Server im selben Netz sind erreichbar. **Prüfung** 1. Zieladresse dokumentieren. 2. TCP Port 443 vom Client testen. 3. Listener auf dem Server prüfen. 4. lokalen HTTPS-Test auf dem Server durchführen. 5. Server-Firewall kontrollieren. 6. Netzwerk-Firewall und Trefferprotokolle prüfen. 7. Paketaufzeichnung auf Client und Server vergleichen. **Mögliche Ursache** Der Webserver läuft und lauscht auf Port 443. Nach einer Netzsegmentierung fehlt jedoch die Freigabe vom neuen Client-VLAN zum Server. **Nachprüfung** - TCP Port 443 ist aus dem vorgesehenen VLAN erreichbar, - HTTPS liefert eine gültige Antwort, - nicht vorgesehene Quellnetze bleiben gesperrt, - Firewallregel ist dokumentiert, - ursprüngliche Anwendung funktioniert. --- **32. Praxisfall B: Dienst funktioniert lokal, aber nicht entfernt** **Symptom** - lokaler Aufruf über `localhost` funktioniert, - entfernter Porttest wird abgelehnt, - der Prozess läuft, - auf dem Server ist kein allgemeiner Listener sichtbar. **Prüfung** 1. Listener und Bind-Adresse feststellen. 2. Loopback und Server-IP lokal vergleichen. 3. Dienstkonfiguration prüfen. 4. nach einer Änderung den Dienst kontrolliert neu laden. 5. lokale Firewall berücksichtigen. 6. entfernten Test wiederholen. **Mögliche Ursache** Der Dienst lauscht ausschließlich auf `127.0.0.1`. **Nachprüfung** - Dienst lauscht auf der vorgesehenen Serveradresse, - lokaler Zugriff funktioniert, - entfernter Zugriff aus erlaubten Netzen funktioniert, - Firewall begrenzt den Zugriff weiterhin, - keine unnötige öffentliche Freigabe wurde geschaffen. --- **33. Praxisfall C: Port 443 ist offen, Website liefert 502** **Symptom** - TCP Port 443 ist erreichbar, - TLS-Verbindung wird aufgebaut, - Reverse Proxy antwortet mit `502 Bad Gateway`, - Backend-Anwendung ist nicht direkt erreichbar. **Prüfung** 1. Proxy-Antwort dokumentieren. 2. Proxy-Protokolle prüfen. 3. Backend-Ziel und Backend-Port feststellen. 4. Verbindung vom Proxy zum Backend testen. 5. Listener der Backend-Anwendung prüfen. 6. Container- oder Dienststatus kontrollieren. 7. Namensauflösung innerhalb des Proxy-Netzes prüfen. **Mögliche Ursache** Nach einer Änderung verwendet die Backend-Anwendung einen neuen Port. Die Proxy-Konfiguration zeigt weiterhin auf den alten Port. **Nachprüfung** - Proxy erreicht das richtige Backend, - Backend-Health-Check ist erfolgreich, - HTTPS-Aufruf liefert die erwartete Anwendung, - weitere virtuelle Hosts funktionieren, - Konfigurationsänderung ist dokumentiert. --- **34. Praxisfall D: Einige Clients erreichen den Dienst, andere nicht** **Symptom** - Clients im VLAN 20 können eine Anwendung öffnen, - Clients im VLAN 30 erhalten eine Zeitüberschreitung, - beide Gruppen lösen denselben Namen zur selben IP-Adresse auf, - der Dienst funktioniert lokal. **Prüfung** 1. Quell-IP-Adressen beider Clients erfassen. 2. Route und Gateway vergleichen. 3. Porttest aus beiden Netzen durchführen. 4. Firewallregeln und Trefferzähler prüfen. 5. Server-Firewall auf Quellnetzbegrenzungen untersuchen. 6. Paketaufzeichnung am Server durchführen. **Mögliche Ursache** Die Server-Firewall erlaubt Port 8443 nur aus dem alten VLAN 20. **Nachprüfung** - vorgesehene Clients aus VLAN 30 erreichen den Dienst, - VLAN 20 funktioniert weiterhin, - andere Netze bleiben gesperrt, - Quellnetze in der Regel sind korrekt dokumentiert. --- **35. Praxisfall E: TCP-Verbindung funktioniert, Anmeldung scheitert** **Symptom** - Zielname wird korrekt aufgelöst, - TCP-Port ist erreichbar, - TLS funktioniert, - Anwendung zeigt eine Anmeldeseite, - Benutzer erhält `401 Unauthorized`. **Prüfung** 1. erfolgreichen Transport dokumentieren. 2. Anwendungsprotokoll und Statuscode auswerten. 3. Benutzerkonto und Authentifizierungsquelle prüfen. 4. Uhrzeit, Zertifikate und gegebenenfalls Kerberos berücksichtigen. 5. funktionierendes Vergleichskonto verwenden. 6. Anwendungs- und Authentifizierungsprotokolle prüfen. **Mögliche Ursache** Der Benutzer ist nicht mehr Mitglied der für die Anwendung berechtigten Gruppe. **Nachprüfung** - Benutzer kann sich nach genehmigter Berechtigungskorrektur anmelden, - TCP- und TLS-Verbindung bleiben unverändert, - Zugriff ist auf vorgesehene Benutzer begrenzt, - Ursache und Berechtigungsänderung sind dokumentiert. --- **36. Ungeeignete Sofortmaßnahmen** Problematisch sind insbesondere: - Firewall vollständig deaktivieren, - beliebige Ports pauschal freigeben, - einen Dienst ungeprüft neu starten, - Server neu starten, ohne den Zustand zu dokumentieren, - Anwendung als Ursache festlegen, nur weil Ping funktioniert, - Netzwerk als Ursache festlegen, obwohl der Dienst keinen Listener besitzt, - Zertifikatsprüfung dauerhaft deaktivieren, - IPv6 pauschal abschalten, - NAT-Regeln ohne Sicherung verändern, - mehrere Firewalls gleichzeitig ändern, - Sicherheitssoftware ungeprüft entfernen, - Container neu erstellen, ohne Volumes und Konfiguration zu prüfen, - produktive Paketaufzeichnungen ungeschützt speichern, - Testzugänge oder temporäre Freigaben dauerhaft bestehen lassen. Vor Änderungen sollten dokumentiert werden: - Quell- und Zieladresse, - Zielport und Transportprotokoll, - DNS-Ergebnis, - Porttestergebnis, - Listener, - Dienststatus, - Firewallregeln, - NAT-Regeln, - Routen, - Protokolle, - Paketbeobachtungen, - Zeitpunkt und Umfang der Störung. --- **37. Vollständige Prüfreihenfolge** 1. betroffene Anwendung und genaue Fehlermeldung erfassen. 2. Quelle, Zielname und Ziel-IP-Adresse dokumentieren. 3. benötigten Zielport bestimmen. 4. TCP oder UDP unterscheiden. 5. Namensauflösung prüfen. 6. Host-Erreichbarkeit nur als Teilprüfung verwenden. 7. Zielport vom betroffenen Client testen. 8. Ergebnis als Erfolg, Ablehnung, Reset oder Zeitüberschreitung einordnen. 9. funktionierenden Vergleichsclient prüfen. 10. IPv4 und IPv6 getrennt betrachten. 11. auf dem Server den Listener prüfen. 12. Prozess zum Listener bestimmen. 13. Bind-Adresse kontrollieren. 14. Dienststatus und Protokolle auswerten. 15. Dienst über Loopback lokal testen. 16. Dienst über die Server-IP lokal testen. 17. protokollspezifischen Test durchführen. 18. lokale Server-Firewall prüfen. 19. Client-Firewall und Sicherheitssoftware berücksichtigen. 20. Netzwerk-Firewalls und ACLs prüfen. 21. Route vom Client zum Server untersuchen. 22. Rückweg vom Server zum Client prüfen. 23. NAT und Portweiterleitungen berücksichtigen. 24. VPN- und Segmentierungsregeln prüfen. 25. Container-, VM- oder Host-Portzuordnungen prüfen. 26. Reverse Proxy oder Load Balancer untersuchen. 27. Backend-Verbindungen testen. 28. TLS, Zertifikat, SNI und Hostnamen prüfen. 29. Anwendung, Authentifizierung und Berechtigung abgrenzen. 30. bei sporadischen Fehlern wiederholte Tests durchführen. 31. bei Bedarf autorisierte Paketaufzeichnung erstellen. 32. konkrete Hypothese formulieren. 33. genau eine kontrollierbare Änderung durchführen. 34. Listener und Dienststatus erneut prüfen. 35. Porttest wiederholen. 36. protokollspezifischen Test wiederholen. 37. ursprüngliche Anwendung erneut testen. 38. funktionierende und nicht vorgesehene Netze kontrollieren. 39. temporäre Freigaben entfernen. 40. Ursache, Maßnahme und Ergebnis dokumentieren. 41. Monitoring oder Präventionsmaßnahme festlegen. --- **38. Dokumentationsbeispiel** ```text Ticket: INC-20644 Beginn: 02.08.2026, etwa 14:20 Uhr Umfang: Clients im VLAN 30 Betroffen: HTTPS-Anwendung auf appserver.example.test Nicht betroffen: Clients im VLAN 20 Verbindung: Quelle: 192.0.2.117 Ziel: appserver.example.test Ziel-IP: 192.0.2.50 Transport: TCP Zielport: 443 Symptom: Der Server antwortet auf ICMP. Die Namensauflösung liefert die korrekte IP-Adresse. Der HTTPS-Aufruf läuft aus VLAN 30 in eine Zeitüberschreitung. Ausgangszustand: - DNS-Auflösung korrekt - ICMP-Antwort vorhanden - TCP Port 443 aus VLAN 30 nicht erreichbar - TCP Port 443 aus VLAN 20 erreichbar - Webserver lauscht auf 0.0.0.0:443 - lokaler HTTPS-Test auf dem Server erfolgreich - Server-Firewall erlaubt beide internen Netze - zentrale Firewall protokolliert verworfene SYN-Pakete aus VLAN 30 Hypothese: Bei der Einrichtung des neuen VLANs wurde die Freigabe zu TCP Port 443 auf dem Anwendungsserver nicht ergänzt. Prüfung: - Quell-IP und Ziel-IP bestätigt - Route zum Server vorhanden - Listener und Dienststatus korrekt - funktionierenden Client aus VLAN 20 verglichen - Firewallregel enthält nur das Quellnetz von VLAN 20 - keine SYN-Pakete aus VLAN 30 erreichen den Server Ursache: Die zentrale Firewallregel erlaubte den HTTPS-Zugriff nur aus VLAN 20. Maßnahme: Das freigegebene Quellobjekt wurde nach Genehmigung um das vorgesehene Clientnetz aus VLAN 30 ergänzt. Ziel und Port blieben unverändert. Nachprüfung: - TCP Port 443 aus VLAN 30 erreichbar - TLS-Handshake erfolgreich - Anwendung liefert HTTP 200 - Anmeldung funktioniert - VLAN 20 funktioniert weiterhin - Zugriff aus nicht freigegebenen Netzen bleibt blockiert - Firewallprotokoll und Trefferzähler geprüft Prävention: - Firewallfreigaben in die VLAN-Abnahme aufnehmen - automatisierten HTTPS-Health-Check aus beiden Clientnetzen einrichten - Änderungen an Netzsegmenten mit einer Kommunikationsmatrix prüfen ``` --- **39. Checkliste „Host erreichbar, Dienst nicht“** - [ ] die betroffene Anwendung wurde eindeutig benannt. - [ ] die genaue Fehlermeldung wurde dokumentiert. - [ ] Quellgerät und Quell-IP-Adresse wurden erfasst. - [ ] Zielname und Ziel-IP-Adresse wurden erfasst. - [ ] der benötigte Zielport wurde bestätigt. - [ ] TCP und UDP wurden unterschieden. - [ ] die Namensauflösung wurde geprüft. - [ ] Ping wurde nicht mit einem Diensttest gleichgesetzt. - [ ] der Zielport wurde vom betroffenen Client getestet. - [ ] Erfolg, Ablehnung, Reset oder Zeitüberschreitung wurden unterschieden. - [ ] ein funktionierender Vergleichsclient wurde geprüft. - [ ] IPv4 und IPv6 wurden getrennt betrachtet. - [ ] ein Listener auf dem Server wurde nachgewiesen. - [ ] der zugehörige Prozess wurde bestimmt. - [ ] die Bind-Adresse wurde kontrolliert. - [ ] der Dienststatus wurde geprüft. - [ ] Dienstprotokolle wurden ausgewertet. - [ ] der Dienst wurde lokal über Loopback getestet. - [ ] der Dienst wurde lokal über die Server-IP getestet. - [ ] ein protokollspezifischer Test wurde durchgeführt. - [ ] die lokale Server-Firewall wurde geprüft. - [ ] die Client-Firewall wurde berücksichtigt. - [ ] Netzwerk-Firewalls und ACLs wurden geprüft. - [ ] Firewallregeln wurden auf Quelle, Ziel, Port und Protokoll geprüft. - [ ] Hin- und Rückroute wurden berücksichtigt. - [ ] asymmetrisches Routing wurde bei Bedarf geprüft. - [ ] NAT und Portweiterleitungen wurden berücksichtigt. - [ ] VPN- und Segmentierungsregeln wurden geprüft. - [ ] Container- oder VM-Portzuordnungen wurden berücksichtigt. - [ ] Reverse Proxy oder Load Balancer wurde geprüft. - [ ] die Verbindung zum Backend wurde getestet. - [ ] TLS und Zertifikate wurden berücksichtigt. - [ ] Hostname, SNI und virtuelle Hosts wurden berücksichtigt. - [ ] Anwendung, Authentifizierung und Berechtigung wurden abgegrenzt. - [ ] MTU und Paketverlust wurden bei passenden Symptomen berücksichtigt. - [ ] anwendungsspezifische Proxys wurden geprüft. - [ ] bei sporadischen Fehlern wurden zeitgestempelte Tests durchgeführt. - [ ] eine Paketaufzeichnung erfolgte nur mit Berechtigung. - [ ] der Ausgangszustand wurde vor Änderungen dokumentiert. - [ ] es wurde nur eine kontrollierbare Änderung durchgeführt. - [ ] der Porttest wurde nach der Änderung wiederholt. - [ ] das Anwendungsprotokoll wurde erneut getestet. - [ ] die ursprüngliche Anwendung wurde erneut geprüft. - [ ] unzulässige Quellnetze bleiben weiterhin gesperrt. - [ ] temporäre Testfreigaben wurden entfernt. - [ ] Ursache, Maßnahme und Nachweis wurden dokumentiert. --- **40. Schnellreferenz** | Fehlerbild | wahrscheinlicher Untersuchungsbereich | |---|---| | Ping funktioniert, TCP-Port nicht | Listener, Firewall, Routing, NAT oder Rückweg | | TCP-Verbindung wird sofort abgelehnt | kein Listener, falscher Port oder aktive Ablehnung | | TCP-Verbindung läuft in Zeitüberschreitung | Firewall-Drop, Routing, NAT, Rückweg oder Ziel | | Port funktioniert lokal, entfernt nicht | Bind-Adresse, Firewall, ACL oder Netzwerkpfad | | Loopback funktioniert, Server-IP lokal nicht | Bind-Adresse oder lokale Firewall | | Port ist offen, Anwendung antwortet nicht | Dienst, Protokoll, Backend oder Überlastung | | TCP funktioniert, TLS scheitert | Zertifikat, SNI, Protokoll oder Cipher | | HTTPS liefert `401` | Authentifizierung | | HTTPS liefert `403` | Berechtigung oder Richtlinie | | HTTPS liefert `502` | Proxy erreicht Backend nicht korrekt | | HTTPS liefert `503` | Dienst oder Backend nicht verfügbar | | HTTPS liefert `504` | Zeitüberschreitung zwischen Proxy und Backend | | nur ein Client betroffen | Client-Firewall, Proxy, Route oder lokale Anwendung | | nur ein Netz betroffen | ACL, Firewall, Routing oder Quellnetzregel | | nur VPN-Clients betroffen | VPN-Route, VPN-Firewall, MTU oder DNS | | intern erreichbar, extern nicht | NAT, Portweiterleitung, externe Firewall oder Provider | | extern erreichbar, intern nicht | Hairpin-NAT, Split-DNS oder interne Firewall | | IP funktioniert, Hostname nicht | DNS, SNI, virtueller Host oder Zertifikat | | IPv4 funktioniert, IPv6 nicht | IPv6-Listener, Firewall, Route oder AAAA-Record | | kleine Anfragen funktionieren, große nicht | MTU, Fragmentierung, Paketverlust oder Timeout | | Verbindung scheitert sporadisch | Last, Porterschöpfung, defektes Backend oder Paketverlust | | UDP-Test bleibt ohne Antwort | Dienst, Firewall, falsche Anfrage oder normales Protokollverhalten | | SYN ohne Antwort | Drop, Routing, Ziel oder Rückweg | | SYN gefolgt von RST | Port geschlossen oder aktive Ablehnung | | Handshake vollständig, danach RST | Anwendung, Proxy, Firewall oder Protokoll | | Handshake vollständig, keine Antwort | Dienst hängt, Backend wartet oder Überlastung | --- **Merksatz** > Ein erreichbarer Host ist nicht automatisch ein erreichbarer Dienst. Geprüft werden müssen die vollständige Kommunikationsbeziehung aus Quelle, Zieladresse, Transportprotokoll und Zielport sowie anschließend Listener, Firewall, Rückweg und Anwendung. Ein erfolgreicher Porttest beweist den TCP-Verbindungsaufbau, aber noch nicht die Funktionsfähigkeit des Anwendungsprotokolls. --- **Quellen und weiterführende Dokumentation** - [Microsoft Learn – Guidance for troubleshooting TCP/IP communication](https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/troubleshoot-tcp-ip-communication-guidance) - [Microsoft Learn – Troubleshoot TCP/IP connectivity](https://learn.microsoft.com/en-us/troubleshoot/windows-client/networking/tcp-ip-connectivity-issues-troubleshooting) - [Microsoft Learn – Test-NetConnection](https://learn.microsoft.com/en-us/powershell/module/nettcpip/test-netconnection) - [Microsoft Learn – Test-Connection](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.management/test-connection) - [Microsoft Learn – Get-NetTCPConnection](https://learn.microsoft.com/en-us/powershell/module/nettcpip/get-nettcpconnection) - [Microsoft Learn – Get-NetUDPEndpoint](https://learn.microsoft.com/en-us/powershell/module/nettcpip/get-netudpendpoint) - [Microsoft Learn – Windows Defender Firewall with Advanced Security administration](https://learn.microsoft.com/en-us/windows/security/operating-system-security/network-security/windows-firewall/) - [RFC 9293 – Transmission Control Protocol](https://www.rfc-editor.org/rfc/rfc9293) - [RFC 768 – User Datagram Protocol](https://www.rfc-editor.org/rfc/rfc768) - [RFC 792 – Internet Control Message Protocol](https://www.rfc-editor.org/rfc/rfc792) - [RFC 8201 – Path MTU Discovery for IPv6](https://www.rfc-editor.org/rfc/rfc8201) - [Wireshark – Display Filter Reference: TCP](https://www.wireshark.org/docs/dfref/t/tcp.html) - [Wireshark – Display Filter Reference: UDP](https://www.wireshark.org/docs/dfref/u/udp.html) - [Wireshark User’s Guide – Building display filter expressions](https://www.wireshark.org/docs/wsug_html_chunked/ChWorkBuildDisplayFilterSection.html) # 6.5 Netzwerk ist langsam – Latenz, Paketverlust und Durchsatz systematisch analysieren Ein Netzwerk gilt nicht allein deshalb als langsam, weil eine Anwendung verzögert reagiert. Wahrgenommene Langsamkeit kann durch das Netzwerk selbst, den Client, den Server, den Datenträger, eine Anwendung, DNS, einen Proxy, ein VPN, WLAN, Paketverlust oder eine ausgelastete Zwischenkomponente entstehen. Typische Aussagen wie: ```text Das Internet ist langsam. Der Server reagiert träge. Der Download dauert zu lange. Die Verbindung hängt immer wieder. Das WLAN ist schlecht. ``` sind zunächst nur Symptombeschreibungen. Für eine belastbare Fehleranalyse muss bestimmt werden: - was genau langsam ist, - zwischen welchen Endpunkten gemessen wird, - ob Latenz, Paketverlust, Jitter oder Durchsatz betroffen sind, - ob der Fehler dauerhaft oder sporadisch auftritt, - ob nur ein Client, ein Netzsegment oder alle Benutzer betroffen sind, - ob das Netzwerk oder eine darüberliegende Anwendung begrenzt. --- **1. Die wichtigsten Messgrößen unterscheiden** | Messgröße | Bedeutung | Typische Auswirkung | |---|---|---| | Latenz | Zeit für die Übertragung zwischen zwei Endpunkten | verzögerte Reaktion, langsamer Sitzungsaufbau | | Round-Trip Time | Zeit für Hin- und Rückweg | messbar beispielsweise mit Ping oder TCP-Tests | | Paketverlust | Pakete erreichen das Ziel nicht | Wiederholungen, Einbrüche bei TCP, Audio- und Videostörungen | | Jitter | Schwankung der Laufzeit | Probleme bei Sprache, Video und Echtzeitanwendungen | | Durchsatz | tatsächlich übertragene Datenmenge pro Zeit | langsame Dateiübertragung oder Downloads | | Bandbreite | theoretisch oder vertraglich verfügbare Kapazität | stellt nur die mögliche Obergrenze dar | | Auslastung | aktuell genutzter Anteil einer Verbindung oder Ressource | Warteschlangen, Verzögerungen und Drops | | Retransmission | erneute TCP-Übertragung verlorener oder nicht bestätigter Segmente | geringerer Durchsatz und zusätzliche Verzögerung | | Queue | wartende Pakete oder Anfragen | steigende Latenz bei hoher Last | | Fehlerrate | fehlerhafte Frames, Pakete oder Übertragungen | Paketverlust, Neuübertragungen und Verbindungsabbrüche | Ein Link mit `1 Gbit/s` garantiert keinen Anwendungsdurchsatz von `1 Gbit/s`. Protokoll-Overhead, Latenz, TCP-Verhalten, Datenträgerleistung, Verschlüsselung, Gegenstelle und weitere gleichzeitig übertragene Daten reduzieren den praktisch erreichbaren Wert. --- **2. Langsamkeit exakt beschreiben** Vor jeder technischen Änderung sind folgende Fragen zu beantworten: - Welche Anwendung oder Übertragung ist langsam? - Wie lange dauert der Vorgang normalerweise? - Wie lange dauert er während der Störung? - Seit wann besteht das Problem? - Funktionierte es zuvor nachweislich schneller? - Ist der Fehler dauerhaft, periodisch oder zufällig? - Sind Download, Upload oder beide Richtungen betroffen? - Sind kleine Anfragen oder erst große Übertragungen betroffen? - Tritt die Verzögerung vor dem Verbindungsaufbau oder während der Datenübertragung auf? - Ist nur ein Benutzer betroffen? - Sind mehrere Clients im selben VLAN, WLAN oder Standort betroffen? - Funktioniert ein Vergleichsclient normal? - Ist die Verbindung per Kabel und WLAN gleichermaßen langsam? - Sind interne Ziele, externe Ziele oder beide betroffen? - Ist nur ein bestimmter Server oder sind mehrere Ziele betroffen? - Wird ein VPN, Proxy, Load Balancer oder Sicherheitsgateway verwendet? - Gab es unmittelbar zuvor Änderungen, Updates oder Wartungsarbeiten? - Treten gleichzeitig CPU-, RAM-, Datenträger- oder Anwendungsprobleme auf? Eine geeignete Ausgangsbeschreibung lautet beispielsweise: ```text Seit 02.08.2026 gegen 09:20 Uhr erreichen Clients im WLAN VLAN 30 beim Kopieren einer 2-GB-Testdatei zum internen Dateiserver nur noch etwa 8 bis 15 Mbit/s. Über kabelgebundene Clients im VLAN 20 werden zum selben Server etwa 700 Mbit/s erreicht. Kleine Webanfragen und DNS-Auflösungen funktionieren. Betroffen sind mehrere WLAN-Clients. ``` Diese Beschreibung ist wesentlich aussagekräftiger als: ```text Das Netzwerk ist langsam. ``` --- **3. Latenz, Durchsatz und Anwendungsdauer nicht gleichsetzen** Ein Dienst kann sich langsam anfühlen, obwohl der Netzwerkdurchsatz ausreichend ist. Beispiele: - eine DNS-Abfrage läuft in einen Timeout, - ein TLS-Handshake benötigt mehrere Versuche, - der Server wartet auf eine Datenbank, - der Datenträger des Servers ist ausgelastet, - eine Anwendung führt viele aufeinanderfolgende Anfragen aus, - ein Proxy untersucht den Datenverkehr, - eine Datei wird serverseitig auf Schadsoftware geprüft, - eine Anwendung arbeitet nur mit einer einzelnen TCP-Verbindung, - ein Benutzerprofil oder eine Gruppenrichtlinie verarbeitet viele Dateien, - der Client besitzt eine hohe CPU- oder Datenträgerauslastung. Umgekehrt kann eine Anwendung zunächst normal reagieren, während größere Übertragungen wegen Paketverlust, MTU-Problemen oder eines ausgelasteten Links einbrechen. Deshalb sind mindestens zwei Prüfarten notwendig: 1. kontrollierte Netzwerkmessung, 2. Test der tatsächlich betroffenen Anwendung. --- **4. Umfang der Störung durch Vergleichstests eingrenzen** | Vergleich | mögliche Erkenntnis | |---|---| | betroffener gegen funktionierenden Client | lokales Problem oder gemeinsamer Infrastrukturfehler | | WLAN gegen Kabel | Funkstrecke, Access Point oder WLAN-Konfiguration | | internes gegen externes Ziel | LAN, WAN, Provider oder Internetpfad | | Ziel im selben VLAN gegen anderes VLAN | lokales Segment oder gerouteter Pfad | | ein Server gegen mehrere Server | Zielsystem oder allgemeiner Netzwerkpfad | | IP-Adresse gegen Hostname | DNS oder Namensauflösung | | ohne VPN gegen mit VPN | Tunnel, MTU, Gateway oder VPN-Routing | | ohne Proxy gegen vorgesehener Proxyweg | Proxy oder Sicherheitsprüfung | | Download gegen Upload | richtungsabhängiger Engpass | | einzelne gegen mehrere TCP-Verbindungen | TCP, Latenz, Lastverteilung oder Serverbegrenzung | | kleine gegen große Übertragung | MTU, Paketverlust, Datenträger oder Durchsatz | | aktuelle Messung gegen historische Baseline | tatsächliche Abweichung vom Normalzustand | Bei einem Vergleich sollte möglichst nur eine Variable verändert werden. --- **5. Lokale Clientressourcen ausschließen** Ein langsamer Client kann ein Netzwerkproblem vortäuschen. Zu prüfen sind: - CPU-Auslastung, - Arbeitsspeicher und Paging, - Datenträgerauslastung und Datenträgerlatenz, - laufende Updates, - Backups und Synchronisationsprogramme, - Virenscanner oder EDR-Prüfungen, - Browser-Erweiterungen, - VPN-Client, - Proxysoftware, - Netzwerkfiltertreiber, - fehlerhafter Netzwerkkartentreiber, - Energiesparmodus, - thermische Begrenzung, - sehr viele parallele Verbindungen, - lokale Anwendung oder lokaler Cache. **Windows** ```powershell Get-Process | Sort-Object CPU -Descending Get-Counter '\Processor(_Total)\% Processor Time' Get-Counter '\Memory\Available MBytes' Get-Counter '\PhysicalDisk(_Total)\Avg. Disk sec/Transfer' Get-NetAdapter Get-NetAdapterStatistics ``` **Linux** ```bash top vmstat 1 free -h iostat -xz 1 ip -s link ``` **macOS** ```bash top vm_stat iostat -w 1 netstat -ib ``` Hohe CPU-, RAM- oder Datenträgerauslastung beweist noch nicht, dass sie die Netzwerkstörung verursacht. Entscheidend ist die zeitliche Übereinstimmung mit der langsamen Übertragung. --- **6. Verbindungstyp und ausgehandelten Link prüfen** Bei Ethernet sind insbesondere zu prüfen: - Interface aktiv, - ausgehandelte Geschwindigkeit, - Duplexmodus, - automatische Aushandlung, - Kabel und Steckverbindungen, - Switchport, - Dockingstation oder USB-Adapter, - Treiber und Firmware, - Fehlerzähler, - Port-Security, - VLAN-Zuweisung, - Energiesparfunktionen. Ein Client, der statt mit `1 Gbit/s` nur mit `100 Mbit/s` verbunden ist, kann beispielsweise durch ein ungeeignetes oder beschädigtes Kabel, eine fehlerhafte Adernpaarverbindung, einen Adapter oder den Switchport begrenzt sein. **Windows** ```powershell Get-NetAdapter | Select-Object Name, InterfaceDescription, Status, LinkSpeed, MacAddress ``` Weitere Eigenschaften: ```powershell Get-NetAdapterAdvancedProperty -Name "" Get-NetAdapterStatistics -Name "" ``` **Linux** ```bash ip link show ip -s link show sudo ethtool sudo ethtool -S ``` **macOS** ```bash ifconfig networksetup -getMedia netstat -ib ``` Auf der Switchseite sind je nach Hersteller insbesondere zu prüfen: - administrativer und operativer Portstatus, - Geschwindigkeit und Duplex, - CRC- oder FCS-Fehler, - Input Errors und Output Errors, - Drops und Discards, - Link-Flaps, - Pause Frames, - Queue Drops, - Portauslastung, - STP-Zustand, - LACP- oder Port-Channel-Zustand. Geschwindigkeit, Duplex, Jumbo Frames und Offload-Einstellungen dürfen nicht wahllos verändert werden. Unterschiedliche Einstellungen an beiden Linkpartnern können neue Fehler verursachen. --- **7. Schnittstellenzähler richtig auswerten** Ein einzelner Zählerstand zeigt nicht, wann ein Fehler aufgetreten ist. Zähler müssen vor und während eines kontrollierten Tests verglichen werden. Beispiel: ```text Zeitpunkt A: CRC-Fehler: 12 Drops: 41 Zeitpunkt B nach Test: CRC-Fehler: 438 Drops: 41 ``` Die steigende Zahl der CRC-Fehler weist auf ein Problem der physischen Übertragung oder des Links hin. Mögliche Ursachen sind: - beschädigtes Kabel, - ungeeignete Verkabelung, - defekter Stecker, - fehlerhafter Switchport, - defekter Netzwerkadapter, - elektromagnetische Störung, - Transceiver- oder Glasfaserproblem. Steigende Drops bei gleichbleibenden CRC-Werten sprechen eher für: - überfüllte Warteschlange, - zu hohe Auslastung, - Microbursts, - unzureichende Puffer, - QoS- oder Policing-Regel, - überlastete CPU einer Netzwerkkomponente. Hersteller verwenden unterschiedliche Zählerbezeichnungen. Die genaue Bedeutung muss anhand der Dokumentation des eingesetzten Geräts geprüft werden. --- **8. Latenz zunächst kontrolliert messen** **Windows** ```powershell ping ping -t Test-Connection -Count 20 Test-NetConnection ``` **Linux** ```bash ping -c 20 ``` **macOS** ```bash ping -c 20 ``` Sinnvolle Ziele für getrennte Messungen: 1. eigenes Standardgateway, 2. Ziel im eigenen VLAN, 3. Ziel in einem anderen internen VLAN, 4. interner Server, 5. VPN-Gateway, 6. externes Ziel, 7. tatsächlich betroffener Anwendungsserver. Beispielhafte Eingrenzung: | Messung | Ergebnis | mögliche Einordnung | |---|---|---| | Gateway bereits langsam | lokaler Link, WLAN, Client oder erstes Netzsegment | | Gateway normal, interner Server langsam | Routing, Firewall, Servernetz oder Server | | interne Ziele normal, externe Ziele langsam | WAN, Provider, VPN, Proxy oder externer Pfad | | nur ein Ziel langsam | Zielserver, Zielnetz oder spezifischer Pfad | | nur unter Last langsam | Queue, Auslastung, Bufferbloat oder Ressourcenengpass | ICMP kann durch Firewalls, Router oder Zielsysteme begrenzt oder niedriger priorisiert werden. Ein verlorenes oder verspätetes Ping-Paket beweist deshalb allein noch keinen Verlust des tatsächlichen Anwendungsverkehrs. --- **9. Paketverlust korrekt untersuchen** Paketverlust kann auftreten: - zwischen Client und Switch, - auf einer WLAN-Funkstrecke, - auf einem überlasteten Uplink, - in einer Firewall, - an einem Router, - in einem VPN-Tunnel, - auf dem WAN- oder Providerpfad, - auf dem Serverinterface, - innerhalb eines virtualisierten Netzwerks. **Windows** ```powershell ping -n 100 pathping ``` **Linux** ```bash ping -c 100 mtr ``` **macOS** ```bash ping -c 100 traceroute ``` Bei `pathping`, `mtr` und ähnlichen Werkzeugen darf ein scheinbarer Verlust an einem Zwischenhop nicht automatisch als Fehler dieses Routers bewertet werden. Ein Router kann Antworten auf Diagnosepakete begrenzen, während er Transitverkehr weiterhin normal weiterleitet. Bedeutsamer ist ein Verlust, wenn: - er ab einem Hop beginnt und an allen folgenden Hops bestehen bleibt, - er gleichzeitig in Ende-zu-Ende-Messungen auftritt, - Interfacezähler oder Paketaufzeichnungen ihn bestätigen, - der tatsächliche Anwendungsverkehr Wiederholungen oder Abbrüche zeigt. --- **10. Pfad und Richtungsunterschiede untersuchen** **Windows** ```powershell tracert Test-NetConnection -TraceRoute Get-NetRoute ``` **Linux** ```bash traceroute tracepath ip route ip route get ``` **macOS** ```bash traceroute netstat -rn route -n get ``` Zu prüfen sind: - Hinweg vom Client zum Ziel, - Rückweg vom Ziel zum Client, - unerwartete Umwege, - VPN-Routen, - Policy-Based Routing, - asymmetrisches Routing, - geänderte Gateways, - überlappende Netze, - unterschiedliche IPv4- und IPv6-Pfade, - Load Balancer oder mehrere Zieladressen. Ein klassischer Traceroute zeigt normalerweise nur den beobachteten Hinweg. Der Rückweg kann anders verlaufen und muss gegebenenfalls von der Gegenstelle aus untersucht werden. --- **11. Durchsatz mit einer kontrollierten Gegenstelle messen** Für eine kontrollierte Ende-zu-Ende-Messung kann `iperf3` verwendet werden. Dabei werden Client und Server benötigt. **Server starten** ```bash iperf3 -s ``` **Clienttest** ```bash iperf3 -c ``` **Gegenrichtung testen** ```bash iperf3 -c -R ``` **Längerer Test** ```bash iperf3 -c -t 30 ``` **Mehrere parallele Datenströme** ```bash iperf3 -c -P 4 ``` **UDP-Test mit kontrollierter Zielrate** ```bash iperf3 -c -u -b -t 30 ``` Dabei sind zu dokumentieren: - Client und Server, - beide IP-Adressen, - Netzpfad, - Datum und Uhrzeit, - TCP oder UDP, - Testdauer, - Anzahl paralleler Datenströme, - Hin- oder Rückrichtung, - gemessener Durchsatz, - gemeldete Wiederholungen, - bei UDP zusätzlich Verlust und Jitter, - gleichzeitige Auslastung anderer Verbindungen. Wichtige Einschränkungen: - Das Ergebnis gilt nur für den Pfad zwischen den beiden Testendpunkten. - Der `iperf3`-Server muss autorisiert und kontrolliert betrieben werden. - Ein Test kann produktive Links stark auslasten. - UDP-Tests können bei ungeeigneter Zielrate erhebliche Paketverluste verursachen. - Mehrere parallele Verbindungen können einen höheren Gesamtdurchsatz erreichen als eine einzelne Verbindung. - Ein erfolgreicher `iperf3`-Test beweist nicht, dass DNS, TLS, Proxy oder Anwendung funktionieren. - Das iperf3-Projekt unterstützt offiziell Linux, FreeBSD und macOS; Windows-Builds stammen häufig aus anderen Quellen und sind nicht Teil der offiziellen Plattformunterstützung des Projekts. Tests in produktiven Netzen müssen zeitlich, räumlich und in ihrer Bandbreite begrenzt werden. --- **12. Dateitransfer nicht ungeprüft als Netzwerkbenchmark verwenden** Eine Dateiübertragung misst nicht ausschließlich das Netzwerk. Das Ergebnis kann begrenzt werden durch: - Quelldatenträger, - Zieldatenträger, - Dateisystem, - SMB, NFS, SFTP oder HTTPS, - Verschlüsselung, - Kompression, - Virenscanner, - viele kleine Dateien, - Server-CPU, - Client-CPU, - Berechtigungsprüfung, - Protokollsignierung, - Backup oder Snapshot, - Cache. Sinnvolle Vergleichstests: - große einzelne Datei gegen viele kleine Dateien, - Speicher-zu-Speicher-Test gegen Datenträgerübertragung, - kontrollierter Netzwerkdurchsatz gegen Anwendungsübertragung, - derselbe Client zu einem anderen Server, - ein anderer Client zum selben Server, - Lesen gegen Schreiben. Wenn `iperf3` einen normalen Netzwerkdurchsatz zeigt, die Dateiübertragung aber langsam bleibt, verschiebt sich die Untersuchung auf Protokoll, Datenträger, Server und Anwendung. --- **13. WLAN getrennt vom kabelgebundenen Netz prüfen** WLAN ist ein gemeinsam genutztes Funkmedium. Die angezeigte WLAN-Verbindungsrate entspricht nicht dem tatsächlich erreichbaren Nutzdurchsatz. Zu prüfen sind: - Signalstärke, - Signal-Rausch-Verhältnis, - verwendetes Frequenzband, - Kanal, - Kanalbreite, - Kanalauslastung, - Störungen, - Anzahl gleichzeitig aktiver Clients, - Airtime-Auslastung, - Wiederholungsrate, - Datenrate, - Roaming, - Access-Point-Auslastung, - Uplink des Access Points, - PoE-Versorgung, - Treiber und Firmware, - Entfernung und Hindernisse, - Hidden-Node-Probleme, - Band Steering, - Mindestdatenraten, - WLAN-Sicherheitsverfahren. **Windows** ```cmd netsh wlan show interfaces netsh wlan show drivers netsh wlan show wlanreport ``` **Linux** ```bash iw dev iw dev link nmcli device wifi list ``` **macOS** Auf macOS können die WLAN-Diagnose, die Systeminformationen sowie je nach Systemversion verfügbare Diagnosewerkzeuge verwendet werden. Die genaue Bedienung kann sich zwischen macOS-Versionen ändern. Wichtige Vergleichstests: 1. betroffener Client am aktuellen Standort, 2. derselbe Client näher am Access Point, 3. derselbe Client per Ethernet, 4. anderer Client am selben Standort, 5. anderer Access Point oder anderes Frequenzband, 6. Messung bei geringer und hoher Auslastung. Wenn der kabelgebundene Test normal und der WLAN-Test langsam ist, liegt die Ursache nicht automatisch am Access Point. Auch Clienttreiber, Funkumgebung, Kanalplanung, Airtime und Roaming müssen geprüft werden. --- **14. Auslastung, Warteschlangen und Bufferbloat** Ein Link kann unter geringer Last gute Latenzwerte und unter hoher Last starke Verzögerungen zeigen. Beispiel: ```text ohne Übertragung: Round-Trip Time zum Gateway: 2 ms während eines Uploads: Round-Trip Time zum Gateway: 180 ms ``` Mögliche Ursachen: - ausgelasteter Uplink, - zu große Warteschlangen, - fehlende oder ungeeignete QoS-Regeln, - Upload begrenzt Rückverkehr und Bestätigungen, - Firewall oder Router erreicht Leistungsgrenze, - VPN-Gateway ist ausgelastet, - WLAN-Airtime ist erschöpft, - Microbursts füllen einen Puffer, - Policer verwirft Pakete. Zu vergleichen sind: - Latenz ohne Last, - Latenz während Download, - Latenz während Upload, - Paketverlust, - Interfaceauslastung, - Queue Drops, - CPU der Netzwerkkomponente, - Anzahl aktiver Verbindungen. Eine hohe nominale Bandbreite verhindert solche Probleme nicht automatisch. Entscheidend sind Engpass, Warteschlangen und Lastverteilung entlang des vollständigen Pfades. --- **15. Duplex-, Speed- und Aushandlungsfehler** Ein Duplexproblem kann folgende Symptome verursachen: - geringer Durchsatz, - stark schwankende Übertragungsrate, - Framefehler, - Kollisionen oder späte Kollisionen bei älteren Ethernet-Szenarien, - viele Wiederholungen, - gute Werte ohne Last und schlechte Werte unter Last. Zu prüfen sind beide Linkpartner: ```text Clientinterface ↔ Switchport Serverinterface ↔ Switchport Switch-Uplink ↔ Gegenstelle Firewallinterface ↔ Switchport ``` Die Konfiguration muss zusammenpassen. Einseitiges Erzwingen von Geschwindigkeit oder Duplex kann einen Mismatch erzeugen. Bei modernen Gigabit-Ethernet-Verbindungen wird normalerweise automatische Aushandlung verwendet. Abweichungen dürfen nur entsprechend der Hardware- und Herstelleranforderungen konfiguriert werden. --- **16. MTU und Fragmentierung prüfen** MTU-Probleme können auftreten, obwohl Ping und kleine Anfragen funktionieren. Typische Symptome: - kleine Webseiten funktionieren, - größere Antworten bleiben hängen, - Dateiübertragungen brechen ab, - VPN-Verbindungen sind langsam, - TLS-Handshakes scheitern oder verzögern sich, - bestimmte Ziele funktionieren, andere nicht, - viele TCP-Wiederholungen, - Anwendungen warten bis zu einem Timeout. **Windows** ```powershell ping -f -l ``` **Linux** ```bash tracepath ping -M do -s ``` Die Nutzdatenlänge eines Pingpakets ist nicht mit der vollständigen IP-Paketgröße gleichzusetzen. IP- und ICMP-Header müssen berücksichtigt werden. Zu prüfen sind: - MTU des Clients, - MTU des Servers, - VLAN- und Tunnel-Overhead, - VPN, - PPPoE, - VXLAN oder andere Kapselung, - Jumbo Frames, - Path MTU Discovery, - blockierte ICMP-Fehlermeldungen, - MSS-Anpassung. Jumbo Frames dürfen nur verwendet werden, wenn der vollständige vorgesehene Pfad sie unterstützt. Eine Änderung ausschließlich an einem Endgerät ist keine geeignete Lösung. --- **17. TCP-Wiederholungen und Empfangsfenster untersuchen** TCP passt seine Übertragung an den Zustand des Datenpfades an. Paketverlust, hohe Laufzeit oder ein begrenztes Empfangsfenster können den Durchsatz stark reduzieren. Mögliche Beobachtungen: - Retransmissions, - Duplicate Acknowledgements, - Out-of-Order-Segmente, - Zero Window, - Window Full, - lange Abstände zwischen Anfrage und Antwort, - wiederholter Verbindungsaufbau, - Reset, - stark unterschiedlicher Durchsatz je Richtung. **Wireshark-Filter** ```text tcp.analysis.retransmission tcp.analysis.fast_retransmission tcp.analysis.spurious_retransmission tcp.analysis.duplicate_ack tcp.analysis.out_of_order tcp.analysis.lost_segment tcp.analysis.window_full tcp.analysis.zero_window tcp.analysis.zero_window_probe tcp.flags.reset == 1 ``` Mögliche Einordnung: | Beobachtung | mögliche Ursache | |---|---| | viele Retransmissions | Paketverlust, Überlastung, physischer Fehler oder Datenpfad | | Duplicate ACKs | fehlende oder verspätete Segmente | | Out-of-Order | unterschiedliche Pfade, Reordering oder Aufzeichnungsartefakt | | Zero Window | Empfänger verarbeitet Daten nicht schnell genug | | Window Full | ausgeschöpftes angekündigtes Empfangsfenster | | wiederholte RST-Pakete | Anwendung, Firewall, Proxy oder Betriebssystem | | lange Zeit bis zum ersten Datenpaket | Anwendung, DNS, TLS, Proxy oder Server | | schnelle Pakete, aber lange Anwendungspausen | Anwendung oder Backend statt Transport | Wireshark-Kennzeichnungen beruhen auf der im Mitschnitt sichtbaren Paketreihenfolge. Ein unvollständiger Mitschnitt, Paketverlust bei der Aufzeichnung oder NIC-Offloading kann die Interpretation beeinflussen. --- **18. Paketaufzeichnung an mehreren Punkten** Wenn die Ursache nicht eindeutig ist, kann eine autorisierte Paketaufzeichnung an mehreren Stellen helfen. Geeignete Punkte: - betroffener Client, - funktionierender Vergleichsclient, - Server, - vor und hinter einer Firewall, - Switch Mirror Port, - VPN-Endpunkt, - Reverse Proxy, - Load Balancer. Zu prüfen sind: - Zeit bis zur DNS-Antwort, - Zeit bis zum TCP-Verbindungsaufbau, - Zeit bis zum TLS-Handshake, - Zeit bis zur ersten Anwendungsantwort, - Paketverlust, - Wiederholungen, - Fenstergrößen, - Reset-Pakete, - ICMP-Fehlermeldungen, - verwendete IP-Adresse, - IPv4 oder IPv6, - tatsächlicher Datenpfad. Ein Mitschnitt nur auf dem Client zeigt nicht sicher, an welcher Zwischenstelle ein Paket verloren ging. Vergleichsmitschnitte an Client und Server können zeigen: ```text Paket verlässt den Client, erreicht aber den Server nicht. ``` oder: ```text Server sendet die Antwort, Client empfängt sie nicht. ``` Paketaufzeichnungen dürfen nur mit entsprechender Berechtigung erstellt und müssen geschützt gespeichert werden. --- **19. IPv4 und IPv6 getrennt vergleichen** Ein Client kann IPv6 bevorzugen, obwohl der IPv6-Pfad langsam oder fehlerhaft ist. **Windows** ```powershell Resolve-DnsName -Type A Resolve-DnsName -Type AAAA Test-Connection Test-Connection ``` **Linux und macOS** ```bash ping -4 ping -6 curl -4 -v https:/// curl -6 -v https:/// ``` Mögliche Ursachen: - unterschiedliche Routen, - falscher AAAA-Record, - IPv6-Firewallregel, - fehlerhafte IPv6-Rückroute, - Tunnel für eine Adressfamilie, - unterschiedliche Proxys oder Gateways, - Dienst antwortet nur über eine Adressfamilie zuverlässig. IPv6 sollte nicht pauschal deaktiviert werden. Zuerst ist nachzuweisen, welche Adressfamilie betroffen ist. --- **20. DNS, Proxy, TLS und Anwendungslatenz abgrenzen** **DNS-Zeit prüfen** ```bash dig ``` Mit `curl` können einzelne Zeitabschnitte gemessen werden: ```bash curl -sS -o /dev/null \ -w 'DNS: %{time_namelookup}\nTCP: %{time_connect}\nTLS: %{time_appconnect}\nErstes Byte: %{time_starttransfer}\nGesamt: %{time_total}\n' \ https:/// ``` Bedeutung: | Wert | untersuchter Bereich | |---|---| | `time_namelookup` | Namensauflösung | | `time_connect` | Zeit bis zum TCP-Verbindungsaufbau | | `time_appconnect` | Zeit bis zum Abschluss von TLS | | `time_starttransfer` | Zeit bis zum ersten empfangenen Byte | | `time_total` | gesamte Übertragungsdauer | Mögliche Einordnung: - DNS langsam, TCP normal: Resolver oder DNS-Pfad, - TCP-Verbindungsaufbau langsam: Netzwerkpfad, Paketverlust oder Ziel, - TLS langsam: Zertifikatsprüfung, TLS-Inspection oder Server, - erstes Byte langsam: Anwendung, Proxy, Backend oder Datenbank, - erstes Byte schnell, Übertragung langsam: Durchsatz, Paketverlust oder Serverausgabe. Ein einzelner Messwert reicht nicht aus. Messungen sollten wiederholt und mit einem funktionierenden Vergleich verglichen werden. --- **21. VPN und Tunnel berücksichtigen** VPN-Verbindungen erzeugen zusätzliche Netzwerkschichten. Mögliche Ursachen: - Tunnel-Overhead, - ungeeignete MTU, - fehlende MSS-Anpassung, - VPN-Gateway ausgelastet, - Verschlüsselung begrenzt CPU, - Full Tunnel leitet unnötigen Datenverkehr um, - Split-Tunnel-Regel fehlt, - DNS wird über einen entfernten Standort geleitet, - asymmetrisches Routing, - Paketverlust auf dem Transportpfad, - wechselnder Zugang zwischen WLAN und Mobilfunk, - Sicherheitsprüfung im VPN-Gateway. Sinnvolle Vergleichstests: 1. ohne VPN zu einem zulässigen Vergleichsziel, 2. mit VPN zum selben zulässigen Ziel, 3. internes Ziel über VPN, 4. externes Ziel bei Full Tunnel, 5. IPv4 und IPv6, 6. Download und Upload, 7. Latenz zum VPN-Gateway und zum Endziel. Ein langsamer Test über VPN beweist nicht automatisch, dass das VPN-Gateway die Ursache ist. Auch der lokale Internetzugang und der Pfad zum Gateway müssen geprüft werden. --- **22. Firewalls, Proxys und Sicherheitskomponenten** Sicherheitskomponenten können den Datenverkehr nicht nur erlauben oder blockieren, sondern auch verarbeiten. Mögliche Einflussfaktoren: - TLS-Inspection, - Virenprüfung, - Intrusion Prevention, - URL-Filter, - Data Loss Prevention, - Proxy-Caching, - Bandbreitenbegrenzung, - QoS- oder Policing-Regel, - hohe Sitzungsanzahl, - ausgelastete CPU, - voller Arbeitsspeicher, - überlastete Protokollierung, - Cluster-Failover, - fehlerhafte Lastverteilung. Zu prüfen sind: - Interfaceauslastung, - CPU und Arbeitsspeicher, - Sitzungstabelle, - Paket- und Fehlerzähler, - Queue Drops, - aktive Sicherheitsprofile, - Protokolle zum Störungszeitpunkt, - HA-Zustand, - Lizenz- oder Kapazitätsgrenzen, - Unterschiede zwischen untersuchten Anwendungen. Sicherheitsfunktionen dürfen nicht pauschal deaktiviert werden. Tests müssen genehmigt, zeitlich begrenzt und auf eine konkrete Kommunikationsbeziehung beschränkt sein. --- **23. Server und Anwendung als Engpass prüfen** Auch bei fehlerfreiem Netzwerk kann der Zielserver den Durchsatz begrenzen. Zu prüfen sind: - CPU pro Prozess und Thread, - Arbeitsspeicher, - Paging oder Swapping, - Datenträgerlatenz, - I/O-Wait, - Queue Depth, - Netzwerkinterface, - offene Verbindungen, - Connection Pools, - Datenbanklocks, - Anwendungswarteschlangen, - parallele Backups, - Virenscanner, - Snapshots, - Hypervisorauslastung, - Storage-Netzwerk, - Load Balancer, - Backend-Abhängigkeiten. Typisches Muster: ```text iperf3 zum Server: normal Dateiübertragung: langsam Server-Datenträger: dauerhaft ausgelastet ``` In diesem Fall ist ein Netzwerkengpass nicht nachgewiesen. Die Untersuchung muss auf Datenträger, Protokoll und Server fortgesetzt werden. --- **24. Virtualisierung und Container** Zusätzliche Ursachen bei virtuellen Systemen: - virtuelle Netzwerkkarte begrenzt, - vSwitch oder Bridge ausgelastet, - falsches VLAN Tagging, - Host-Uplink überlastet, - NIC Teaming oder Bonding fehlerhaft, - CPU-Steal oder CPU Ready, - Host Memory Pressure, - Storage-Latenz, - Sicherheitsgruppe oder virtuelle Firewall, - Overlay-Netzwerk, - Container-NAT, - Service Mesh, - Reverse Proxy, - Host-Portzuordnung, - fehlerhafte MTU innerhalb des Overlays. Die Prüfung sollte folgende Ebenen unterscheiden: ```text Anwendung ↓ Container oder virtuelle Maschine ↓ virtuelles Interface ↓ virtueller Switch oder Bridge ↓ Hostinterface ↓ physischer Switch ↓ weiterer Netzwerkpfad ``` Ein unauffälliger Zähler innerhalb der virtuellen Maschine schließt Fehler auf dem Host-Uplink nicht aus. --- **25. Sporadische Langsamkeit erfassen** Bei sporadischen Fehlern reichen manuelle Einzeltests häufig nicht aus. **PowerShell** ```powershell 1..30 | ForEach-Object { $time = Get-Date -Format "yyyy-MM-dd HH:mm:ss" $result = Test-Connection -Count 1 -ErrorAction SilentlyContinue [PSCustomObject]@{ Time = $time Status = if ($result) { "Erfolg" } else { "Fehler" } RTTms = if ($result) { $result.Latency } else { $null } } Start-Sleep -Seconds 10 } ``` Abhängig von der verwendeten PowerShell-Version können Eigenschaften des zurückgegebenen Objekts abweichen und müssen vor einer automatisierten Auswertung geprüft werden. **Bash** ```bash for i in {1..30}; do date '+%Y-%m-%d %H:%M:%S' ping -c 1 sleep 10 done ``` Zusätzlich zu erfassen sind: - Interfacezähler, - Link-Flaps, - Switchportstatus, - WLAN-Roaming, - Kanal- und Airtime-Auslastung, - CPU und RAM, - Datenträgerlatenz, - Firewall-Sitzungsanzahl, - geplante Backups, - Updates, - Scans, - Cronjobs oder Timer, - Providerereignisse, - Temperatur und Stromversorgung. Alle Systeme müssen möglichst einheitlich synchronisierte Zeit verwenden, damit Ereignisse auf einer gemeinsamen Zeitleiste verglichen werden können. --- **26. Praxisfall A: Nur ein Client ist langsam** **Symptom** - ein Client überträgt mit etwa 90 Mbit/s, - andere Clients am selben Switch erreichen wesentlich höhere Werte, - Server und Anwendung sind für andere Benutzer normal, - der betroffene Client zeigt eine Linkgeschwindigkeit von `100 Mbit/s`. **Prüfung** 1. Linkgeschwindigkeit dokumentieren. 2. Netzwerkkartenstatistik prüfen. 3. Kabel und Switchport kontrollieren. 4. Client mit bekannt funktionierendem Kabel testen. 5. denselben Switchport mit einem Vergleichsclient testen. 6. Treiber und Adapter prüfen. 7. kontrollierten Durchsatztest wiederholen. **Mögliche Ursache** Das Netzwerkkabel besitzt eine fehlerhafte Adernpaarverbindung. Deshalb wird nur Fast Ethernet statt Gigabit Ethernet ausgehandelt. **Nachprüfung** - Link wird mit der vorgesehenen Geschwindigkeit ausgehandelt, - Fehlerzähler steigen nicht, - kontrollierter Durchsatz entspricht wieder der Baseline, - die ursprüngliche Anwendung funktioniert, - Kabel und Ursache sind dokumentiert. --- **27. Praxisfall B: WLAN langsam, Ethernet normal** **Symptom** - mehrere WLAN-Clients sind langsam, - kabelgebundene Clients funktionieren, - Latenz zum Gateway steigt unter Last stark, - Access Point und Clients verwenden denselben stark belegten Kanal. **Prüfung** 1. WLAN- und Ethernettest vergleichen. 2. Signal, Kanal und Kanalauslastung erfassen. 3. Airtime und Wiederholungsrate am Access Point prüfen. 4. benachbarte Funknetze berücksichtigen. 5. Uplink und CPU des Access Points prüfen. 6. kontrollierte Messung bei geringer Last durchführen. 7. Kanalplanung entsprechend der vorhandenen Funkumgebung prüfen. **Mögliche Ursache** Der verwendete Kanal ist stark ausgelastet. Mehrere Access Points und fremde WLANs konkurrieren um dieselbe Airtime. **Nachprüfung** - vorgesehene Kanalplanung ist umgesetzt, - Wiederholungsrate ist gesunken, - Latenz bleibt auch unter kontrollierter Last stabiler, - Durchsatz hat sich nachweisbar verbessert, - benachbarte Funkzellen funktionieren weiterhin, - Änderung und Messergebnisse sind dokumentiert. --- **28. Praxisfall C: Download schnell, Upload langsam** **Symptom** - Downloads erreichen die erwartete Größenordnung, - Uploads brechen stark ein, - bei Uploadlast steigt die Latenz, - andere Anwendungen reagieren währenddessen verzögert. **Prüfung** 1. Download und Upload getrennt messen. 2. Gegenrichtung mit kontrollierter Messung prüfen. 3. WAN-Auslastung und Queue beobachten. 4. Firewall- und Router-CPU prüfen. 5. Drops und Policing-Zähler kontrollieren. 6. Providerprofil und vereinbarte Uploadrate prüfen. 7. VPN- und QoS-Regeln berücksichtigen. **Mögliche Ursache** Der verfügbare Upstream wird vollständig ausgelastet. Eine ungeeignete Warteschlangensteuerung verursacht zusätzliche Latenz. **Nachprüfung** - Upload bleibt innerhalb der vorgesehenen Kapazität, - interaktive Anwendungen bleiben unter Last nutzbar, - Queue Drops und Latenz wurden erneut gemessen, - vorgesehene Priorisierung funktioniert, - nicht autorisierte Bandbreitenerweiterungen wurden nicht vorgenommen. --- **29. Praxisfall D: Netzwerk normal, Anwendung langsam** **Symptom** - Latenz und Paketverlust sind unauffällig, - kontrollierter Durchsatz ist normal, - nur eine Webanwendung antwortet langsam, - Zeit bis zum ersten Byte ist stark erhöht. **Prüfung** 1. DNS-, TCP-, TLS- und Antwortzeiten getrennt messen. 2. Anwendung mit anderem Client vergleichen. 3. Reverse-Proxy-Protokolle prüfen. 4. Backend-Verbindung testen. 5. Anwendungs- und Datenbankprotokolle auswerten. 6. Serverressourcen kontrollieren. 7. zeitgleiche Jobs oder Locks prüfen. **Mögliche Ursache** Eine Datenbankabfrage wartet auf eine Sperre. Das Netzwerk transportiert die Pakete normal, die Anwendung erzeugt die Antwort jedoch verspätet. **Nachprüfung** - Zeit bis zum ersten Byte hat sich normalisiert, - Netzwerkwerte bleiben unverändert, - Datenbank- und Anwendungszustand sind fehlerfrei, - ursprünglicher Geschäftsprozess funktioniert, - Ursache und Maßnahme sind dokumentiert. --- **30. Praxisfall E: Über VPN funktionieren kleine Anfragen, große Übertragungen brechen ein** **Symptom** - Anmeldung am VPN funktioniert, - Ping und kleine Webanfragen funktionieren, - größere Dateiübertragungen hängen oder werden sehr langsam, - ohne VPN tritt das Problem nicht auf. **Prüfung** 1. Pfad und Tunnelart dokumentieren. 2. MTU auf Client, Tunnel und Zielpfad prüfen. 3. Paketaufzeichnung auf Wiederholungen untersuchen. 4. ICMP-Fehlermeldungen berücksichtigen. 5. MSS-Anpassung am Tunnel prüfen. 6. Upload und Download getrennt testen. 7. VPN-Gatewayauslastung kontrollieren. **Mögliche Ursache** Durch den Tunnel-Overhead ist die effektive MTU geringer. Notwendige Rückmeldungen für Path MTU Discovery werden auf dem Pfad verworfen. **Nachprüfung** - kleine und große Übertragungen funktionieren, - TCP-Wiederholungen sind zurückgegangen, - vorgesehene MTU- beziehungsweise MSS-Konfiguration ist dokumentiert, - andere VPN-Verbindungen wurden kontrolliert, - keine pauschale Deaktivierung von Sicherheitsfunktionen erfolgte. --- **31. Ungeeignete Sofortmaßnahmen** Problematisch sind insbesondere: - Netzwerkgeräte ohne Dokumentation neu starten, - Kabel, Switchports und Konfiguration gleichzeitig verändern, - Geschwindigkeit oder Duplex nur auf einer Seite erzwingen, - Jumbo Frames versuchsweise aktivieren, - IPv6 pauschal deaktivieren, - Firewalls oder Sicherheitsprüfung vollständig abschalten, - QoS-Regeln ohne Messung verändern, - produktive Links mit unkontrollierten Lasttests auslasten, - UDP-Tests mit beliebiger hoher Zielrate durchführen, - Provider verantwortlich machen, ohne den lokalen Pfad geprüft zu haben, - einen einzelnen Pingverlust als eindeutigen Beweis verwenden, - jeden Verlust an einem Traceroute-Hop als Fehler dieses Routers interpretieren, - eine Dateiübertragung als reinen Netzwerkbenchmark behandeln, - Paketaufzeichnungen ungeschützt speichern, - Netzwerkkartentreiber ungeprüft ersetzen, - Offload- und Empfangseinstellungen wahllos deaktivieren, - Server neu starten, ohne Ressourcen und Protokolle zu sichern. Vor Änderungen sollten mindestens dokumentiert werden: - Symptom, - betroffene Benutzer und Systeme, - Quelle und Ziel, - Verbindungstyp, - Linkgeschwindigkeit, - DNS-Ergebnis, - Latenz, - Paketverlust, - Durchsatz, - Interfacezähler, - Route, - Serverressourcen, - Zeitpunkt, - Vergleichssystem, - aktuelle Konfiguration. --- **32. Vollständige Prüfreihenfolge** 1. genaue langsame Funktion benennen. 2. Soll- und Istwert dokumentieren. 3. Zeitpunkt, Dauer und Häufigkeit erfassen. 4. betroffene Benutzer, Clients und Standorte bestimmen. 5. Quelle, Ziel und Datenrichtung dokumentieren. 6. funktionierenden Vergleichsclient bestimmen. 7. WLAN und Ethernet unterscheiden. 8. internes und externes Ziel vergleichen. 9. Clientressourcen prüfen. 10. Interface- und Linkstatus prüfen. 11. ausgehandelte Geschwindigkeit und Duplex kontrollieren. 12. Kabel, Adapter und Switchport berücksichtigen. 13. Interfacezähler vor dem Test erfassen. 14. Latenz zum Gateway messen. 15. Latenz zu internen und externen Zielen vergleichen. 16. Paketverlust Ende zu Ende untersuchen. 17. Pfad und Route prüfen. 18. IPv4 und IPv6 getrennt vergleichen. 19. Interfacezähler nach dem Test erneut erfassen. 20. Download und Upload getrennt messen. 21. kontrollierten Durchsatztest verwenden. 22. einzelne und parallele TCP-Verbindungen vergleichen. 23. Datenträger und Anwendung vom Netzwerk abgrenzen. 24. WLAN-Signal, Kanal, Airtime und Wiederholungen prüfen. 25. Uplinks, Port-Channels und Queue Drops kontrollieren. 26. Firewall, VPN, Proxy und Sicherheitsprüfung berücksichtigen. 27. Server-CPU, RAM und Datenträgerlatenz prüfen. 28. Virtualisierung, vSwitch und Host-Uplink untersuchen. 29. MTU, Tunnel und Fragmentierung bei passenden Symptomen prüfen. 30. TCP-Wiederholungen und Fensterverhalten analysieren. 31. bei Bedarf autorisierte Paketaufzeichnung erstellen. 32. Beobachtungen auf einer gemeinsamen Zeitleiste korrelieren. 33. konkrete Hypothese formulieren. 34. genau eine kontrollierbare Änderung durchführen. 35. Latenz erneut messen. 36. Paketverlust erneut prüfen. 37. Durchsatz erneut messen. 38. ursprüngliche Anwendung erneut testen. 39. funktionierende Vergleichssysteme kontrollieren. 40. temporäre Tests und Freigaben entfernen. 41. Ursache, Maßnahme und Nachweis dokumentieren. 42. Monitoring oder Präventionsmaßnahme festlegen. --- **33. Dokumentationsbeispiel** ```text Ticket: INC-20718 Beginn: 02.08.2026, etwa 09:20 Uhr Umfang: mehrere WLAN-Clients im VLAN 30 Nicht betroffen: kabelgebundene Clients im VLAN 20 Ziel: interner Dateiserver fileserver.example.test Symptom: Dateiübertragungen über WLAN erreichen nur etwa 8 bis 15 Mbit/s. Kabelgebundene Vergleichsclients erreichen zum selben Server etwa 700 Mbit/s. Kleine Webanfragen und DNS-Auflösungen funktionieren. Ausgangszustand: - DNS-Auflösung korrekt - Server per TCP erreichbar - Dateiserver für Ethernet-Clients normal - Serverressourcen unauffällig - Access-Point-Uplink mit 1 Gbit/s aktiv - keine steigenden CRC-Fehler am Uplink - hohe Kanalauslastung im verwendeten Frequenzbereich - erhöhte WLAN-Wiederholungsrate - Latenz zum Gateway steigt unter Last deutlich Hypothese: Die Funkzelle besitzt zu wenig freie Airtime. Der Datenverkehr wird wiederholt übertragen und wartet auf den Zugriff auf das Funkmedium. Prüfung: - Ethernet und WLAN mit demselben Ziel verglichen - mehrere WLAN-Clients getestet - Signalstärke und Kanal erfasst - Uplink und Server als Engpass ausgeschlossen - kontrollierter Durchsatztest in beide Richtungen durchgeführt - Access-Point-Statistiken zum Störungszeitpunkt ausgewertet Ursache: Starke Kanalbelegung und überlappende Funkzellen führten zu einer hohen Wiederholungsrate und geringer nutzbarer Airtime. Maßnahme: Die Kanalplanung der betroffenen Funkzellen wurde nach einer Funkumgebungsanalyse kontrolliert angepasst. Nachprüfung: - Latenz zum Gateway unter Last verbessert - Wiederholungsrate gesunken - kontrollierter WLAN-Durchsatz deutlich erhöht - ursprüngliche Dateiübertragung funktioniert - Ethernet-Clients weiterhin fehlerfrei - benachbarte Funkzellen kontrolliert Prävention: - Kanalauslastung und Wiederholungsrate überwachen - WLAN-Baseline pro Standort dokumentieren - Funkumgebung nach größeren Änderungen erneut prüfen ``` --- **34. Checkliste „Netzwerk ist langsam“** - [ ] die langsame Funktion wurde eindeutig benannt. - [ ] Soll- und Istzustand wurden dokumentiert. - [ ] Beginn, Dauer und Häufigkeit wurden erfasst. - [ ] betroffene Clients, Benutzer und Standorte wurden bestimmt. - [ ] Quelle, Ziel und Datenrichtung wurden dokumentiert. - [ ] ein funktionierender Vergleichsclient wurde verwendet. - [ ] WLAN und Ethernet wurden getrennt betrachtet. - [ ] interne und externe Ziele wurden verglichen. - [ ] Download und Upload wurden getrennt geprüft. - [ ] Client-CPU, RAM und Datenträger wurden berücksichtigt. - [ ] Interface- und Linkstatus wurden geprüft. - [ ] ausgehandelte Geschwindigkeit und Duplex wurden kontrolliert. - [ ] Kabel, Adapter, Dockingstation und Switchport wurden berücksichtigt. - [ ] Interfacezähler wurden vor und nach einem Test verglichen. - [ ] Latenz zum Gateway wurde gemessen. - [ ] Latenz zu weiteren Zielen wurde verglichen. - [ ] Paketverlust wurde Ende zu Ende geprüft. - [ ] Diagnoseantworten von Zwischenhops wurden nicht ungeprüft bewertet. - [ ] Route und Rückweg wurden berücksichtigt. - [ ] IPv4 und IPv6 wurden getrennt verglichen. - [ ] ein kontrollierter Durchsatztest wurde durchgeführt. - [ ] Gegenrichtung wurde geprüft. - [ ] einzelne und mehrere TCP-Verbindungen wurden bei Bedarf verglichen. - [ ] Dateisystem und Datenträger wurden vom Netzwerk abgegrenzt. - [ ] WLAN-Signal, Kanal und Airtime wurden geprüft. - [ ] Switch-Uplinks und Port-Channels wurden berücksichtigt. - [ ] Queue Drops und Auslastung wurden geprüft. - [ ] Firewall, Proxy, VPN und Sicherheitsprüfung wurden berücksichtigt. - [ ] Serverressourcen wurden geprüft. - [ ] Virtualisierung und Host-Uplink wurden berücksichtigt. - [ ] MTU und Tunnel-Overhead wurden bei passenden Symptomen geprüft. - [ ] TCP-Wiederholungen wurden bei Bedarf analysiert. - [ ] DNS-, TCP-, TLS- und Anwendungszeiten wurden abgegrenzt. - [ ] sporadische Fehler wurden zeitgestempelt erfasst. - [ ] Paketaufzeichnungen erfolgten nur mit Berechtigung. - [ ] eine konkrete Hypothese wurde formuliert. - [ ] nur eine kontrollierbare Änderung wurde vorgenommen. - [ ] Latenz, Verlust und Durchsatz wurden nach der Änderung erneut gemessen. - [ ] die ursprüngliche Anwendung wurde erneut getestet. - [ ] Vergleichssysteme funktionieren weiterhin. - [ ] temporäre Testkonfigurationen wurden entfernt. - [ ] Ursache, Maßnahme und Nachweis wurden dokumentiert. --- **35. Schnellreferenz** | Fehlerbild | wahrscheinlicher Untersuchungsbereich | |---|---| | nur ein Client langsam | Client, Kabel, Adapter, Treiber oder Switchport | | alle Clients eines Switches langsam | Uplink, Switch, VLAN oder gemeinsame Gegenstelle | | nur WLAN langsam | Funkumgebung, Airtime, Kanal, AP oder Client | | Ethernet und WLAN langsam | Gateway, Uplink, Firewall, WAN, Server oder Anwendung | | nur ein Server langsam | Zielserver, Servernetz, Datenträger oder Anwendung | | alle externen Ziele langsam | WAN, Provider, Firewall, Proxy oder VPN | | nur Upload langsam | Upstream, Queue, Policing, Provider oder VPN | | nur Download langsam | Downstream, Server, TCP, Proxy oder Client | | Latenz steigt nur unter Last | Queue, Auslastung, Bufferbloat oder Drops | | Ping normal, Dateiübertragung langsam | Durchsatz, Datenträger, Protokoll oder Anwendung | | Durchsatztest normal, Anwendung langsam | DNS, TLS, Proxy, Backend, Datenbank oder Server | | Link nur mit 100 Mbit/s | Kabel, Adapter, Switchport oder Aushandlung | | steigende CRC-/FCS-Fehler | physischer Link, Kabel, Transceiver oder Port | | steigende Drops ohne CRC-Fehler | Queue, Überlastung, Policing oder Puffer | | viele TCP-Retransmissions | Paketverlust, Überlastung oder Datenpfad | | TCP Zero Window | Empfänger verarbeitet Daten zu langsam | | kleine Pakete funktionieren, große nicht | MTU, Tunnel oder Fragmentierung | | nur über VPN langsam | Tunnel, MTU, Gateway, Verschlüsselung oder Route | | nur IPv6 langsam | IPv6-Pfad, Firewall, Route oder Zieladresse | | nur IPv4 langsam | IPv4-Pfad, NAT, Firewall oder Route | | nur zu bestimmten Zeiten langsam | Last, Backup, Scan, Job, Provider oder Funkumgebung | | ein TCP-Stream langsam, mehrere schneller | Latenz, Fenster, Verlust oder Serverbegrenzung | | WLAN-Signal gut, Durchsatz schlecht | Kanalauslastung, Airtime, Störung oder Wiederholungen | | erstes Byte langsam | Anwendung, Proxy, Backend oder Datenbank | | erstes Byte schnell, Download langsam | Durchsatz, Verlust, Serverausgabe oder Client | | lokale Ziele schnell, Internet langsam | WAN, Provider, NAT, Firewall oder Proxy | | Gateway bereits langsam | lokaler Link, WLAN, Client oder erstes Netzsegment | --- **Merksatz** > „Langsam“ ist keine eindeutige Fehlerursache. Eine belastbare Analyse trennt Latenz, Paketverlust, Jitter und Durchsatz, vergleicht funktionierende und betroffene Pfade und prüft anschließend Client, Link, WLAN, Switch, Firewall, WAN, Server und Anwendung. Erst reproduzierbare Messwerte vor und nach einer kontrollierten Änderung belegen eine Verbesserung. --- **Quellen und weiterführende Dokumentation** - [Microsoft Learn – Guidance for troubleshooting TCP/IP performance](https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/troubleshoot-tcp-ip-performance-guidance) - [Microsoft Learn – Overview of TCP/IP performance](https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/overview-of-tcpip-performance) - [Microsoft Learn – TCP/IP performance known issues](https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/tcpip-performance-known-issues) - [Microsoft Learn – Network Adapter Performance Tuning in Windows Server](https://learn.microsoft.com/en-us/windows-server/networking/technologies/network-subsystem/net-sub-performance-tuning-nics) - [Microsoft Learn – Test-Connection](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.management/test-connection) - [Microsoft Learn – Test-NetConnection](https://learn.microsoft.com/en-us/powershell/module/nettcpip/test-netconnection) - [Microsoft Learn – Get-NetAdapterStatistics](https://learn.microsoft.com/en-us/powershell/module/netadapter/get-netadapterstatistics) - [ESnet – iperf3 documentation](https://software.es.net/iperf/) - [ESnet – Invoking iperf3](https://software.es.net/iperf/invoking.html) - [ESnet – iperf3 FAQ and supported platforms](https://software.es.net/iperf/faq.html) - [Wireshark User’s Guide – TCP Analysis](https://www.wireshark.org/docs/wsug_html_chunked/ChAdvTCPAnalysis.html) - [Wireshark – Display Filter Reference: TCP](https://www.wireshark.org/docs/dfref/t/tcp.html) - [Wireshark – TShark Manual](https://www.wireshark.org/docs/man-pages/tshark.html) - [RFC 6349 – Framework for TCP Throughput Testing](https://www.rfc-editor.org/rfc/rfc6349) - [RFC 9293 – Transmission Control Protocol](https://www.rfc-editor.org/rfc/rfc9293) - [RFC 8201 – Path MTU Discovery for IPv6](https://www.rfc-editor.org/rfc/rfc8201) - [RFC 1191 – Path MTU Discovery](https://www.rfc-editor.org/rfc/rfc1191) # 6.6 Fehler tritt nur manchmal auf – sporadische Störungen systematisch erfassen und korrelieren Sporadische Fehler gehören zu den schwierigsten Störungen in der IT-Fehleranalyse. Zum Zeitpunkt der Untersuchung funktioniert das betroffene System häufig wieder normal. Einzelne manuelle Tests liefern dann keine auffälligen Ergebnisse. Typische Aussagen sind: - „Das passiert nur manchmal.“ - „Nach einigen Minuten geht es wieder.“ - „Heute Morgen war alles langsam.“ - „Die Verbindung bricht unregelmäßig ab.“ - „Nach einem Neustart funktioniert es wieder.“ - „Der Fehler tritt nur bei bestimmten Benutzern auf.“ - „In den Protokollen ist nichts zu sehen.“ - „Es passiert meistens nachts oder unter hoher Last.“ Eine belastbare Untersuchung benötigt deshalb: 1. einen möglichst genauen Fehlerzeitpunkt, 2. eine reproduzierbare Beschreibung des Symptoms, 3. kontinuierliche oder ereignisgesteuerte Messungen, 4. ausreichend lange aufbewahrte Protokolle, 5. synchronisierte Systemzeiten, 6. Messdaten vor, während und nach dem Fehler, 7. eine gemeinsame Zeitleiste aller beteiligten Systeme. Ein unauffälliger Einzeltest beweist lediglich, dass der Fehler während dieses Tests nicht beobachtet wurde. --- **1. Was ist ein sporadischer Fehler?** Ein sporadischer Fehler tritt nicht dauerhaft und häufig nicht zuverlässig reproduzierbar auf. Mögliche Erscheinungsformen: - zufällig wirkende Verbindungsabbrüche, - zeitweise sehr hohe Latenz, - gelegentliche Anmeldefehler, - nur einzelne fehlgeschlagene DNS-Anfragen, - kurzzeitige Serverausfälle, - unregelmäßige WLAN-Unterbrechungen, - vereinzelte Zeitüberschreitungen, - Dienste reagieren vorübergehend nicht, - Dateien können manchmal nicht geöffnet werden, - eine Anwendung verliert gelegentlich ihre Sitzung, - ein Switchport wechselt kurzzeitig den Linkstatus, - ein DHCP-Lease wird gelegentlich nicht erneuert, - Zertifikats- oder Tokenfehler treten nur zu bestimmten Zeiten auf. Sporadisch bedeutet nicht automatisch zufällig. Häufig besitzt der Fehler ein Muster, das erst durch ausreichend lange Beobachtung sichtbar wird. --- **2. Typische Ursachen** Mögliche Ursachen sind: - kurzzeitige Link-Unterbrechung, - beschädigtes Kabel oder loser Steckverbinder, - instabile Stromversorgung, - Überhitzung, - WLAN-Interferenz, - Roaming zwischen Access Points, - ausgelasteter Uplink, - Microbursts, - kurzfristig volle Warteschlangen, - DHCP-Lease-Erneuerung, - ablaufender DNS-Cache oder DNS-TTL, - Token- oder Sitzungsablauf, - Idle-Timeout, - VPN-Rekeying, - Zertifikatsablauf oder fehlerhafte Zertifikatsprüfung, - geplantes Backup, - Virenscan, - Snapshot, - Replikation, - Datenbankwartung, - Softwareverteilung, - Update oder Neustart, - Ressourcenerschöpfung, - Speicherleck, - kurzzeitig hohe CPU- oder Datenträgerlast, - begrenzter Connection Pool, - Port- oder Socket-Erschöpfung, - Paketverlust, - Firewall- oder Proxy-Timeout, - Load-Balancer-Health-Check, - Cluster-Failover, - Providerstörung, - Fehler in einem externen Dienst. --- **3. Auswirkungen bestimmen** Vor der technischen Untersuchung muss der Umfang eingegrenzt werden. Zu klären ist: - ein Benutzer oder mehrere Benutzer, - ein Client oder mehrere Clients, - ein Standort oder mehrere Standorte, - WLAN oder Ethernet, - ein VLAN oder mehrere VLANs, - ein Server oder mehrere Server, - eine Anwendung oder mehrere Anwendungen, - interne oder externe Ziele, - IPv4 oder IPv6, - mit oder ohne VPN, - nur Upload oder nur Download, - nur ein bestimmter Geschäftsprozess, - nur eine bestimmte Uhrzeit, - nur unter Last, - nur nach längerer Inaktivität, - nur nach Anmeldung, Aufwachen oder Netzwerkwechsel. Eine Beobachtung wie „Das Netzwerk war kurz weg“ ist noch keine ausreichende Fehlerbeschreibung. --- **4. Fehlerzeitpunkt exakt erfassen** Der wichtigste Ausgangspunkt ist ein möglichst genauer Zeitstempel. Ungeeignet: ```text Der Fehler war heute Morgen. ``` Besser: ```text 02.08.2026 zwischen 09:14:20 und 09:15:05 Uhr ``` Noch besser: ```text 02.08.2026, 09:14:37 Uhr: Beim Öffnen von \\fileserver.example.test\projekte erschien nach etwa 30 Sekunden die Meldung „Der Netzwerkname wurde nicht gefunden“. 09:15:05 Uhr: Ein erneuter Versuch war erfolgreich. ``` Zusätzlich zu dokumentieren: - Zeitzone, - Benutzer, - Clientname, - Client-IP, - MAC-Adresse, - Standort, - Verbindungstyp, - Access Point oder Switchport, - Zielname, - Ziel-IP, - Anwendung, - verwendeter Port, - genaue Meldung, - Dauer, - Aktion unmittelbar vor dem Fehler, - Zustand nach dem Fehler. Screenshots sollten nach Möglichkeit die Uhrzeit enthalten. Andernfalls muss der Zeitpunkt separat dokumentiert werden. --- **5. Systemzeiten kontrollieren** Daten verschiedener Systeme können nur sinnvoll korreliert werden, wenn ihre Uhren ausreichend genau synchronisiert sind. Zu prüfen sind: - Uhrzeit, - Datum, - Zeitzone, - konfigurierte Zeitquelle, - Synchronisationsstatus, - Abweichung zur Referenz, - Zeitpunkt der letzten Synchronisation, - Erreichbarkeit der Zeitquelle, - Zeitstatus virtueller Maschinen, - Zeitquelle von Netzwerkgeräten, - Zeitquelle von Containern und Hosts. **Windows** ```powershell Get-Date Get-TimeZone w32tm /query /status w32tm /query /source w32tm /query /configuration ``` **Linux** ```bash date --iso-8601=seconds timedatectl status timedatectl timesync-status ``` **macOS** ```bash date systemsetup -gettimezone systemsetup -getusingnetworktime systemsetup -getnetworktimeserver ``` Ein Zeitunterschied von mehreren Minuten kann dazu führen, dass zusammengehörige Ereignisse in Client-, Server-, Firewall- und Netzwerkprotokollen nicht erkannt werden. Die Uhrzeit darf nicht unkontrolliert verändert werden. In Domänen, Clustern, Datenbanken und authentifizierten Umgebungen können Zeitsprünge zusätzliche Fehler verursachen. --- **6. Fehlermeldung vollständig sichern** Zu erfassen sind: - vollständiger Meldungstext, - Fehlercode, - Event-ID, - HTTP-Statuscode, - Anwendungscode, - Quell- und Zielsystem, - betroffene Datei oder Ressource, - Zeitpunkt, - vorherige Benutzeraktion, - Dauer bis zur Meldung, - Verhalten bei Wiederholung. Beispiel: ```text Ungeeignet: „VPN ging nicht.“ Geeignet: „Am 02.08.2026 um 11:42:18 Uhr brach die bestehende VPN-Verbindung nach ungefähr 27 Minuten Laufzeit ab. Der Client meldete Fehlercode 809. Der lokale Internetzugang funktionierte währenddessen weiter. Die erneute VPN-Verbindung war um 11:43:02 Uhr erfolgreich.“ ``` Die originale Meldung darf nicht nur sinngemäß wiedergegeben werden. --- **7. Muster suchen** Sporadische Fehler sollten nach wiederkehrenden Merkmalen untersucht werden. | Muster | möglicher Untersuchungsbereich | |---|---| | immer zur gleichen Uhrzeit | Backup, Scan, Update, Wartungsjob oder Provider | | nach längerer Inaktivität | Idle-Timeout, Energiesparmodus oder Sitzung | | nach Ablauf einer festen Dauer | Lease, Token, Session, NAT, Firewall oder VPN-Rekeying | | nur unter Last | Ressourcen, Queue, Uplink, Storage oder Connection Pool | | nur montags oder nach dem Wochenende | Lease, Kennwort, Zertifikat, Patch oder Neustart | | nur bei einem Benutzer | Benutzerprofil, Berechtigung, Token oder Endgerät | | nur bei einem Client | Hardware, Treiber, Kabel, WLAN oder lokale Software | | nur an einem Standort | WAN, WLAN, Switch, Strom oder Provider | | nur bei WLAN | Interferenz, Roaming, Airtime oder Access Point | | nur bei VPN | Tunnel, Gateway, MTU, Rekeying oder Route | | nach Aufwachen des Clients | Treiber, DHCP, DNS, VPN oder Energiesparmodus | | nach Konfigurationsänderung | fehlerhafte Änderung oder Abhängigkeit | | alle 30 oder 60 Minuten | geplanter Timer, Lease, Token, Job oder Polling | | bei hoher Raumtemperatur | Kühlung, Transceiver, Netzteil oder Hardware | | bei Regen oder Wind | Außenleitung, Funkstrecke, Strom oder Providerpfad | Eine zeitliche Übereinstimmung ist zunächst nur eine Korrelation und noch kein Beweis für die Ursache. --- **8. Kontinuierliche Erreichbarkeitsmessung unter Windows** Ein einfacher protokollierter Test kann prüfen, ob ein Ziel zum Störungszeitpunkt erreichbar war. ```powershell $Target = "" $LogFile = ".\availability.csv" "Time,Target,Status,LatencyMs" | Set-Content -Path $LogFile while ($true) { $Time = Get-Date -Format "yyyy-MM-ddTHH:mm:ss.fffK" $Result = Test-Connection -TargetName $Target -Count 1 -ErrorAction SilentlyContinue if ($Result) { "$Time,$Target,Success,$($Result.Latency)" | Add-Content -Path $LogFile } else { "$Time,$Target,Failure," | Add-Content -Path $LogFile } Start-Sleep -Seconds 5 } ``` Vor dem Einsatz ist zu prüfen, welche Eigenschaften `Test-Connection` in der verwendeten PowerShell-Version zurückgibt. Beenden: ```text [CTRL] + [C] ``` Die Messung zeigt nur die ICMP-Erreichbarkeit des gewählten Ziels. Sie beweist nicht, dass DNS, TCP, TLS oder die Anwendung funktioniert haben. --- **9. Kontinuierliche Erreichbarkeitsmessung unter Linux und macOS** ```bash target="" logfile="./availability.log" while true; do printf '%s ' "$(date '+%Y-%m-%dT%H:%M:%S%z')" >> "$logfile" if ping -c 1 -W 2 "$target" >> "$logfile" 2>&1; then printf 'STATUS=SUCCESS\n' >> "$logfile" else printf 'STATUS=FAILURE\n' >> "$logfile" fi sleep 5 done ``` Je nach Betriebssystem unterscheiden sich die Optionen und die Einheit des Ping-Timeouts. Der konkrete Befehl muss auf dem Zielsystem geprüft werden. Beenden: ```text [CTRL] + [C] ``` Sinnvolle parallele Ziele: 1. Loopback-Adresse, 2. eigene IP-Adresse, 3. Standardgateway, 4. interner Server, 5. DNS-Server, 6. VPN-Gateway, 7. externes Vergleichsziel, 8. tatsächlich betroffener Dienst. Dadurch kann erkannt werden, ab welchem Teil des Pfades der Fehler sichtbar wird. --- **10. Dienst statt nur Ping überwachen** Wenn die Anwendung einen bestimmten TCP-Port benötigt, sollte zusätzlich dieser Port getestet werden. **Windows** ```powershell $Target = "" $Port = $LogFile = ".\tcp-check.csv" "Time,Target,Port,Success" | Set-Content -Path $LogFile while ($true) { $Time = Get-Date -Format "yyyy-MM-ddTHH:mm:ss.fffK" $Result = Test-NetConnection -ComputerName $Target -Port $Port ` -InformationLevel Quiet "$Time,$Target,$Port,$Result" | Add-Content -Path $LogFile Start-Sleep -Seconds 10 } ``` **Linux und macOS** ```bash while true; do timestamp="$(date '+%Y-%m-%dT%H:%M:%S%z')" if nc -z -w 3 ; then printf '%s TARGET=%s PORT=%s STATUS=SUCCESS\n' \ "$timestamp" "" "" else printf '%s TARGET=%s PORT=%s STATUS=FAILURE\n' \ "$timestamp" "" "" fi sleep 10 done >> tcp-check.log 2>&1 ``` Ein erfolgreicher TCP-Verbindungsaufbau beweist noch nicht, dass Anmeldung, Datenbank, Backend oder vollständiger Geschäftsprozess funktionieren. --- **11. DNS kontinuierlich prüfen** Sporadische Namensauflösungsfehler können durch einen einzelnen Ping auf eine IP-Adresse übersehen werden. **Windows** ```powershell $Name = "" $LogFile = ".\dns-check.log" while ($true) { $Time = Get-Date -Format "yyyy-MM-ddTHH:mm:ss.fffK" "===== $Time =====" | Add-Content -Path $LogFile Resolve-DnsName -Name $Name -ErrorAction Continue | Out-String | Add-Content -Path $LogFile Start-Sleep -Seconds 30 } ``` **Linux und macOS** ```bash while true; do printf '===== %s =====\n' "$(date '+%Y-%m-%dT%H:%M:%S%z')" dig sleep 30 done >> dns-check.log 2>&1 ``` Zu vergleichen sind: - Antwortzeit, - verwendeter DNS-Server, - Antwortcode, - A-Record, - AAAA-Record, - CNAME, - TTL, - wechselnde Zieladressen, - Antwort bei Erfolg und Fehler. Ein absichtlich wechselnder DNS-Eintrag, beispielsweise bei einem Load Balancer, darf nicht automatisch als Fehler bewertet werden. --- **12. HTTP- und Anwendungszeiten aufzeichnen** Für HTTP- oder HTTPS-Dienste kann `curl` einzelne Zeitabschnitte protokollieren. ```bash while true; do timestamp="$(date '+%Y-%m-%dT%H:%M:%S%z')" result="$(curl -sS -o /dev/null \ --connect-timeout 10 \ --max-time 30 \ -w 'code=%{http_code} remote=%{remote_ip} dns=%{time_namelookup} tcp=%{time_connect} tls=%{time_appconnect} first_byte=%{time_starttransfer} total=%{time_total}' \ https:/// 2>&1)" printf '%s %s\n' "$timestamp" "$result" sleep 30 done >> http-check.log ``` Mögliche Einordnung: | Beobachtung | möglicher Bereich | |---|---| | DNS-Zeit erhöht | Resolver oder DNS-Pfad | | TCP-Aufbau erhöht | Netzwerkpfad, Paketverlust oder Ziel | | TLS-Zeit erhöht | Zertifikatsprüfung, Inspection oder Server | | erstes Byte verspätet | Anwendung, Proxy, Backend oder Datenbank | | Gesamtzeit erhöht | Übertragung, Durchsatz, Server oder Client | | wechselnde Ziel-IP mit Fehler nur bei einer IP | Load Balancer oder einzelner Backend-Pfad | | HTTP-Fehlercode | Anwendung, Proxy, Authentifizierung oder Backend | Die Abfrage muss auf einen ungefährlichen und autorisierten Endpunkt begrenzt werden. --- **13. Interfacezustand und Fehlerzähler regelmäßig erfassen** Sporadische Linkfehler sind häufig nur als kurzzeitiger Statuswechsel oder steigender Fehlerzähler sichtbar. **Windows** ```powershell $LogFile = ".\adapter-statistics.csv" while ($true) { $Time = Get-Date -Format "yyyy-MM-ddTHH:mm:ss.fffK" Get-NetAdapterStatistics | Select-Object @{ Name = "Time" Expression = { $Time } }, Name, ReceivedBytes, SentBytes, ReceivedUnicastPackets, SentUnicastPackets, ReceivedDiscardedPackets, OutboundDiscardedPackets, ReceivedPacketErrors, OutboundPacketErrors | Export-Csv -Path $LogFile -Append -NoTypeInformation Start-Sleep -Seconds 30 } ``` **Linux** ```bash while true; do printf '===== %s =====\n' "$(date '+%Y-%m-%dT%H:%M:%S%z')" ip -s link show dev ethtool ethtool -S sleep 30 done >> interface-check.log 2>&1 ``` **macOS** ```bash while true; do printf '===== %s =====\n' "$(date '+%Y-%m-%dT%H:%M:%S%z')" ifconfig netstat -ib sleep 30 done >> interface-check.log 2>&1 ``` Zu beobachten sind insbesondere: - Link up/down, - ausgehandelte Geschwindigkeit, - Duplex, - CRC- oder FCS-Fehler, - Eingabe- und Ausgabefehler, - verworfene Pakete, - Queue Drops, - Carrier-Fehler, - Link-Flaps, - neu ausgehandelte Verbindung, - steigende Fehlerdifferenz zwischen zwei Messzeitpunkten. Absolute Zählerstände reichen nicht aus. Entscheidend ist, ob und wann die Zähler während des Fehlers gestiegen sind. --- **14. Switchport und Access Point überwachen** Auf der Netzwerkkomponente sollten mindestens geprüft werden: - Portstatus, - letzter Statuswechsel, - Anzahl Link-Flaps, - Speed und Duplex, - CRC-/FCS-Fehler, - Input Errors, - Output Errors, - Discards, - Queue Drops, - Broadcast- und Multicast-Anteil, - PoE-Status, - Temperatur, - Transceiverwerte, - VLAN-Zugehörigkeit, - Spanning-Tree-Ereignisse, - Port-Channel-Status, - MAC-Adresswechsel, - WLAN-An- und Abmeldungen, - Roaming-Ereignisse, - Deauthentication, - Signalstärke, - Wiederholungsrate, - Kanal- und Airtime-Auslastung. Die Befehle und Zählerbezeichnungen unterscheiden sich je nach Hersteller und Modell. Ihre genaue Bedeutung muss anhand der jeweiligen Herstellerdokumentation geprüft werden. --- **15. Ereignisprotokolle unter Windows zeitlich eingrenzen** Beispiel für Systemereignisse eines bestimmten Zeitraums: ```powershell $Start = Get-Date "2026-08-02 09:10:00" $End = Get-Date "2026-08-02 09:20:00" Get-WinEvent -FilterHashtable @{ LogName = "System" StartTime = $Start EndTime = $End } | Select-Object TimeCreated, Id, LevelDisplayName, ProviderName, Message | Sort-Object TimeCreated ``` Mehrere Protokolle können getrennt untersucht werden: ```powershell $Logs = @( "System", "Application", "Microsoft-Windows-DNS-Client/Operational", "Microsoft-Windows-WLAN-AutoConfig/Operational" ) foreach ($Log in $Logs) { Get-WinEvent -FilterHashtable @{ LogName = $Log StartTime = $Start EndTime = $End } -ErrorAction SilentlyContinue | Select-Object @{ Name = "Log" Expression = { $Log } }, TimeCreated, Id, ProviderName, LevelDisplayName, Message } ``` Nicht jedes Protokoll ist auf jedem System vorhanden oder aktiviert. Zusätzliche Protokollierung sollte kontrolliert und mit Blick auf Speicherbedarf, Datenschutz und Systemlast aktiviert werden. --- **16. Protokolle unter Linux zeitlich eingrenzen** ```bash journalctl \ --since "2026-08-02 09:10:00" \ --until "2026-08-02 09:20:00" ``` Nur Meldungen eines Dienstes: ```bash journalctl \ -u .service \ --since "2026-08-02 09:10:00" \ --until "2026-08-02 09:20:00" ``` Kernelmeldungen: ```bash journalctl \ -k \ --since "2026-08-02 09:10:00" \ --until "2026-08-02 09:20:00" ``` Neue Meldungen fortlaufend beobachten: ```bash journalctl -f ``` Zu berücksichtigen sind: - Zeitzone, - persistente oder flüchtige Speicherung, - Aufbewahrungsdauer, - Rotation, - Rate Limiting, - ausreichender Datenträgerspeicher, - Berechtigungen, - zentrale Weiterleitung. Ein fehlender Eintrag beweist nicht automatisch, dass kein Fehler aufgetreten ist. Das Ereignis kann außerhalb der Aufbewahrungszeit liegen, in einem anderen Protokoll stehen oder nicht protokolliert worden sein. --- **17. Protokolle unter macOS zeitlich eingrenzen** ```bash log show \ --start "2026-08-02 09:10:00" \ --end "2026-08-02 09:20:00" \ --style syslog ``` Nach Prozess filtern: ```bash log show \ --start "2026-08-02 09:10:00" \ --end "2026-08-02 09:20:00" \ --predicate 'process == ""' \ --style syslog ``` Fortlaufende Beobachtung: ```bash log stream --style syslog ``` Die genaue Syntax und die verfügbaren Protokolldaten können sich zwischen macOS-Versionen unterscheiden. --- **18. Ringpuffer-Paketmitschnitt mit Dumpcap** Ein Ringpuffer bewahrt nur die letzten Aufzeichnungsdateien auf. Wenn der Fehler auftritt, muss die Aufzeichnung zeitnah gestoppt werden, bevor die relevanten Daten überschrieben werden. Interfaces anzeigen: ```bash dumpcap -D ``` Beispiel: ```bash dumpcap \ -i \ -w intermittent.pcapng \ -b duration:300 \ -b files:12 ``` Dieses Beispiel: - wechselt alle 300 Sekunden die Datei, - hält maximal 12 Dateien, - überschreibt anschließend die ältesten Dateien, - bewahrt damit ungefähr die letzten 60 Minuten auf. Alternative Begrenzung nach Dateigröße: ```bash dumpcap \ -i \ -w intermittent.pcapng \ -b filesize:100000 \ -b files:10 ``` Hierbei ist `filesize` in Kilobyte angegeben. Optionaler Capture-Filter: ```bash dumpcap \ -i \ -f "host and port " \ -w intermittent.pcapng \ -b duration:300 \ -b files:12 ``` Capture-Filter und Wireshark-Anzeigefilter besitzen unterschiedliche Syntax. Ein zu enger Filter kann die für die Ursachenanalyse benötigten Pakete ausschließen. --- **19. Ringpuffer-Paketmitschnitt mit tcpdump** ```bash tcpdump \ -i \ -s 0 \ -G 300 \ -W 12 \ -w 'intermittent-%Y%m%d-%H%M%S.pcap' ``` Möglicher Filter: ```bash tcpdump \ -i \ -s 0 \ -G 300 \ -W 12 \ -w 'intermittent-%Y%m%d-%H%M%S.pcap' \ 'host and port ' ``` Die Kombination und genaue Wirkung der Rotationsoptionen kann von der installierten `tcpdump`-Version abhängen und muss vor dem produktiven Einsatz mit der lokalen Handbuchseite geprüft werden: ```bash man tcpdump ``` Paketaufzeichnungen können personenbezogene Daten, Anmeldedaten, Sitzungsinformationen und vertrauliche Inhalte enthalten. Sie dürfen nur mit entsprechender Berechtigung erstellt, geschützt gespeichert und nach Abschluss kontrolliert gelöscht werden. --- **20. Windows-Paketmitschnitt mit Pktmon** Filter anzeigen: ```powershell pktmon filter list ``` Vorhandene Filter entfernen: ```powershell pktmon filter remove ``` Beispiel für eine begrenzte zirkuläre Aufzeichnung: ```powershell pktmon start ` --capture ` --comp nics ` --pkt-size 0 ` --file-name C:\Temp\intermittent.etl ` --file-size 512 ` --log-mode circular ``` Aufzeichnung stoppen: ```powershell pktmon stop ``` In PCAPNG umwandeln: ```powershell pktmon etl2pcap ` C:\Temp\intermittent.etl ` --out C:\Temp\intermittent.pcapng ``` Im zirkulären Modus werden bei Erreichen der festgelegten Größe ältere Ereignisse überschrieben. Die Aufzeichnung muss daher nach Auftreten des Fehlers zeitnah gestoppt werden. Die verfügbaren Optionen unterscheiden sich zwischen Windows-Versionen. Vor dem Einsatz ist die lokale Hilfe zu prüfen: ```powershell pktmon start help pktmon etl2pcap help ``` --- **21. Monitoringauflösung passend wählen** Ein Monitoringintervall von fünf Minuten kann einen Fehler übersehen, der nur 20 Sekunden dauert. Beispiel: ```text 09:10:00 Messung erfolgreich 09:12:15 Fehler beginnt 09:12:40 Fehler endet 09:15:00 Messung erfolgreich ``` Das Monitoring zeigt keinen Ausfall, obwohl der Dienst 25 Sekunden nicht verfügbar war. Mögliche Maßnahmen: - kürzeres Prüfintervall, - aktiver Diensttest statt nur Ping, - mehrere Messpunkte, - zeitlich begrenzte höhere Auflösung, - Event- oder Trap-Auswertung, - Aufzeichnung von Minimal-, Maximal- und Durchschnittswerten, - Perzentile statt ausschließlich Mittelwerte, - Statuswechsel sofort protokollieren, - Fehlerzähler als Differenz erfassen, - Rohdaten ausreichend lange aufbewahren. Eine höhere Auflösung erzeugt mehr Last, Daten und Warnmeldungen. Sie sollte gezielt für die betroffene Komponente und einen begrenzten Zeitraum verwendet werden. --- **22. Welche Messwerte langfristig hilfreich sind** **Client** - CPU, - RAM, - Datenträgerlatenz, - Netzwerkstatus, - Linkgeschwindigkeit, - WLAN-Signal, - verwendeter Access Point, - DHCP-Lease, - DNS-Server, - VPN-Status, - Ereignisprotokolle. **Switch und Router** - Interface up/down, - Fehler und Discards, - Auslastung, - Queue Drops, - Port-Channel-Status, - Routingnachbarn, - CPU, - RAM, - Temperatur, - Stromversorgung. **Firewall und VPN** - Sitzungsanzahl, - NAT-Auslastung, - CPU, - RAM, - Paketverlust, - Drops, - Tunnelstatus, - Rekeying, - Failover, - Sicherheitsereignisse. **Server** - CPU pro Prozess, - RAM, - Paging oder Swapping, - Datenträgerlatenz, - I/O-Wait, - Netzwerkfehler, - offene Verbindungen, - Queue, - Anwendungsthreads, - Connection Pools, - Datenbanklocks, - Dienstneustarts. **WLAN** - Signalstärke, - Signal-Rausch-Verhältnis, - Kanal, - Airtime, - Wiederholungsrate, - Roaming, - Deauthentication, - Access-Point-Auslastung, - Uplinkstatus. --- **23. Ablaufzeiten und regelmäßige Erneuerungen prüfen** Sporadische Fehler können entstehen, wenn ein regelmäßig erneuerter Zustand abläuft. Zu prüfen sind: - DHCP-Lease, - DNS-TTL, - ARP- und Neighbor-Cache, - Kerberos-Ticket, - OAuth- oder Anwendungstoken, - Websitzung, - Cookie, - Firewall-Session, - NAT-Zuordnung, - Load-Balancer-Persistenz, - VPN-SA und Rekeying, - Zertifikatsgültigkeit, - CRL- oder OCSP-Erreichbarkeit, - Kennwortablauf, - Maschinenkennwort, - Connection Pool, - Idle-Timeout, - Keepalive, - Lease eines verteilten Locks. Beispiel: ```text Fehlerabstand: ungefähr 60 Minuten Sitzungs-Timeout: 60 Minuten ``` Diese Übereinstimmung begründet eine Hypothese, beweist sie aber noch nicht. Der tatsächliche Ablauf und die anschließende Erneuerung müssen in Protokollen oder Paketdaten bestätigt werden. --- **24. Geplante Jobs und Wartungsarbeiten korrelieren** Zu untersuchen sind: - Backuppläne, - Snapshots, - Virenscans, - Patchmanagement, - Softwareverteilung, - Datenbankwartung, - Logrotation, - Replikation, - Synchronisation, - Indexierung, - Cronjobs, - systemd-Timer, - Windows-Aufgabenplanung, - Cloud-Automationen, - Container-Restarts, - Zertifikatserneuerung, - DHCP- oder DNS-Bereinigung, - Reportingjobs, - geplante Providerarbeiten. **Windows** ```powershell Get-ScheduledTask | Select-Object TaskPath, TaskName, State ``` Letzte und nächste Ausführung: ```powershell Get-ScheduledTask | Get-ScheduledTaskInfo | Select-Object TaskName, LastRunTime, LastTaskResult, NextRunTime ``` **Linux** ```bash systemctl list-timers --all ``` Zusätzlich können je nach System Cron-Konfigurationen und deren Protokolle relevant sein. Nur autorisierte Konfigurationen dürfen eingesehen werden. Aufgaben sollten nicht allein wegen einer zeitlichen Überschneidung deaktiviert werden. --- **25. Temperatur, Strom und physische Umgebung berücksichtigen** Kurzzeitige Ausfälle können durch physische Bedingungen verursacht werden. Zu prüfen sind: - Gerätetemperatur, - Lüfterstatus, - Netzteilstatus, - PoE-Leistung, - USV-Ereignisse, - Spannungsschwankungen, - transceiverbezogene Warnungen, - Tür- oder Racktemperatur, - Kabelbewegung, - Feuchtigkeit, - Außenleitung, - Bauarbeiten, - Funkstörungen, - Neustarts nach Stromverlust. Typisches Muster: ```text Hohe Last → Temperatur steigt → Schnittstelle oder Gerät fällt kurzzeitig aus → automatische Wiederherstellung → Untersuchung erfolgt später bei normaler Temperatur ``` Ein Neustart kann Temperatur-, Speicher- und Fehlerzustände zurücksetzen und dadurch wichtige Beweise beseitigen. --- **26. Änderungen und Deployments berücksichtigen** Zu dokumentieren sind: - Zeitpunkt der Änderung, - betroffene Systeme, - vorherige Version, - neue Version, - geänderte Konfiguration, - verantwortlicher Change, - Rollbackmöglichkeit, - erste beobachtete Störung, - weitere abhängige Systeme. Mögliche Änderungen: - Treiberupdate, - Firmwareupdate, - Betriebssystemupdate, - Firewallregel, - Routingänderung, - DNS-Änderung, - Zertifikatswechsel, - Anwendungsversion, - Datenbankschema, - Proxykonfiguration, - Load-Balancer-Pool, - VLAN-Änderung, - WLAN-Kanalplanung, - Container-Image, - Ressourcenlimit. „Seit dem Update“ ist eine wichtige Beobachtung, aber noch kein technischer Nachweis. Die fehlerhafte Version oder Einstellung muss durch Vergleich, Protokoll oder kontrollierten Rollback bestätigt werden. --- **27. Daten auf einer gemeinsamen Zeitleiste korrelieren** Beispiel: | Uhrzeit | Client | Switch | Firewall | Server | |---|---|---|---|---| | 09:14:31 | Anwendung startet Anfrage | Port aktiv | Sitzung angelegt | Anfrage empfangen | | 09:14:34 | wartet auf Antwort | Output Drops steigen | Weiterleitung erfolgt | Datenträgerlatenz steigt | | 09:14:37 | Timeout | Port weiterhin aktiv | Sitzung beendet | Anwendung antwortet verspätet | | 09:15:02 | erneuter Versuch | Zähler stabil | neue Sitzung | Antwort normal | Erst durch die gemeinsame Zeitleiste wird sichtbar, dass der Clienttimeout mit der erhöhten Datenträgerlatenz zusammenfällt. Zu korrelieren sind: - Benutzeraktion, - Clientprotokoll, - DNS-Antwort, - Paketmitschnitt, - Switchport, - Access Point, - Firewall, - VPN-Gateway, - Load Balancer, - Reverse Proxy, - Serverbetriebssystem, - Anwendung, - Datenbank, - Storage, - Hypervisor, - Providerereignis. Zeitangaben müssen auf dieselbe Zeitzone oder eine eindeutig dokumentierte Referenz umgerechnet werden. --- **28. Ereignisgesteuerte Datensicherung** Wenn der Benutzer den Fehler bemerkt, sollte ein festgelegtes Verfahren ausgelöst werden. Beispiel: ```text 1. genaue Uhrzeit notieren; 2. Screenshot erstellen; 3. betroffene Aktion nicht mehrfach unkontrolliert wiederholen; 4. Diagnosemarkierung oder Ticket auslösen; 5. laufenden Ringpuffer zeitnah stoppen; 6. Clientzustand sichern; 7. relevante Server- und Netzwerkprotokolle exportieren; 8. Monitoringdaten für den Zeitraum schützen; 9. Vergleichssystem prüfen; 10. Dateien eindeutig beschriften. ``` Beispiel für eine Markierungsdatei unter PowerShell: ```powershell $Time = Get-Date -Format "yyyy-MM-ddTHH-mm-ss.fffK" "Fehler durch Benutzer beobachtet: $Time" | Set-Content ".\incident-marker-$Time.txt" ``` Beispiel unter Bash: ```bash timestamp="$(date '+%Y-%m-%dT%H-%M-%S%z')" printf 'Fehler durch Benutzer beobachtet: %s\n' "$timestamp" \ > "incident-marker-$timestamp.txt" ``` Der Marker liefert keine Ursache, erleichtert aber das Auffinden des relevanten Zeitraums. --- **29. Praxisfall A: Verbindung bricht ungefähr jede Stunde ab** **Symptom** - eine Webanwendung trennt den Benutzer unregelmäßig, - der Fehler tritt meistens nach längerer Nutzung auf, - Netzwerk und Server bleiben erreichbar, - eine erneute Anmeldung funktioniert sofort. **Prüfung** 1. genaue Sitzungsdauer erfassen. 2. Browser-, Proxy- und Anwendungsprotokolle vergleichen. 3. Token- und Sitzungsablauf kontrollieren. 4. Firewall- und Load-Balancer-Timeout berücksichtigen. 5. Zeitpunkt der letzten Benutzeraktivität dokumentieren. 6. Ablauf und Erneuerung im Netzwerk- oder Anwendungsprotokoll prüfen. 7. funktionierenden Benutzer oder Client vergleichen. **Mögliche Ursache** Die Anwendung erneuert ein ablaufendes Token nicht korrekt. Nach Ablauf wird die nächste Anfrage abgelehnt. **Nachprüfung** - Sitzung bleibt über den bisherigen Fehlerzeitpunkt hinaus aktiv, - Token wird ordnungsgemäß erneuert, - keine zusätzlichen Anmeldefehler entstehen, - Firewall und Netzwerk bleiben unverändert unauffällig, - Ursache und Korrektur sind dokumentiert. --- **30. Praxisfall B: Switchport fällt kurzzeitig aus** **Symptom** - ein Client verliert gelegentlich für einige Sekunden die Verbindung, - anschließend funktioniert die Verbindung automatisch wieder, - spätere Pingtests sind unauffällig, - andere Clients sind nicht betroffen. **Prüfung** 1. Client- und Switchzeit synchronisieren. 2. Linkstatus kontinuierlich protokollieren. 3. Switchportereignisse auswerten. 4. Fehlerzähler vor und nach dem Ereignis vergleichen. 5. Kabel und Steckverbindungen kontrollieren. 6. Energiespar- und Treibereinstellungen berücksichtigen. 7. kontrollierten Kabel- oder Portvergleich durchführen. **Mögliche Ursache** Eine beschädigte Steckverbindung verursacht kurzzeitige Link-Flaps. **Nachprüfung** - keine weiteren Link-Flaps, - Fehlerzähler steigen nicht, - Verbindung bleibt unter kontrollierter Last stabil, - Vergleich über einen ausreichend langen Zeitraum, - getauschte Komponente und Messergebnisse dokumentiert. --- **31. Praxisfall C: Dienst jeden Morgen kurz langsam** **Symptom** - die Anwendung ist täglich zwischen 08:00 und 08:10 Uhr langsam, - Netzwerkdurchsatz und Paketverlust sind unauffällig, - Zeit bis zum ersten Byte steigt, - danach normalisiert sich der Dienst. **Prüfung** 1. Anwendungszeiten kontinuierlich erfassen. 2. Serverressourcen im betroffenen Zeitraum prüfen. 3. geplante Aufgaben und Backuppläne vergleichen. 4. Datenträgerlatenz und Datenbanklocks untersuchen. 5. Proxy- und Anwendungsprotokolle korrelieren. 6. Zustand außerhalb des Zeitfensters vergleichen. 7. Job nicht ungeprüft deaktivieren. **Mögliche Ursache** Ein täglicher Datenbankjob erzeugt hohe Datenträgerlast und konkurriert mit den Anwendungsabfragen. **Nachprüfung** - Job wird in einem vorgesehenen Wartungsfenster ausgeführt oder kontrolliert angepasst, - Datenträgerlatenz bleibt während der Nutzungszeit normal, - Zeit bis zum ersten Byte ist stabil, - ursprünglicher Geschäftsprozess funktioniert, - Backup- oder Wartungsziel bleibt erfüllt. --- **32. Praxisfall D: WLAN-Unterbrechung nur beim Standortwechsel** **Symptom** - Verbindung funktioniert an festen Standorten, - beim Wechsel zwischen zwei Gebäudebereichen entstehen kurze Unterbrechungen, - der Client verbindet sich anschließend automatisch erneut, - Ethernet ist nicht betroffen. **Prüfung** 1. genauen Weg und Zeitpunkt dokumentieren. 2. verwendeten Access Point vor und nach dem Fehler erfassen. 3. Roaming- und Deauthentication-Ereignisse prüfen. 4. Signalstärke und Überlappung untersuchen. 5. Authentifizierungsdauer berücksichtigen. 6. Kanal- und Airtime-Auslastung prüfen. 7. Vergleich mit anderem Client durchführen. **Mögliche Ursache** Der Client hält zu lange an einem schwächer werdenden Access Point fest und wechselt verspätet zur benachbarten Funkzelle. **Nachprüfung** - Roaming erfolgt innerhalb des vorgesehenen Bereichs, - Unterbrechungszeit ist reduziert, - andere Clients und Funkzellen funktionieren weiterhin, - Änderungen entsprechen der WLAN-Planung, - Messwerte vor und nach der Änderung sind dokumentiert. --- **33. Ungeeignete Sofortmaßnahmen** Problematisch sind insbesondere: - Systeme sofort neu starten, - mehrere Komponenten gleichzeitig verändern, - Protokolle erst lange nach dem Fehler prüfen, - Benutzerzeitangaben ungeprüft übernehmen, - einen erfolgreichen Ping als Gegenbeweis verwenden, - Monitoringmittelwerte ohne Rohdaten bewerten, - Protokollierung unbegrenzt aktivieren, - Mitschnitte ohne Größenbegrenzung erstellen, - Capture-Filter zu eng setzen, - alte Ringpufferdateien versehentlich überschreiben, - Firewalls oder Sicherheitsfunktionen pauschal deaktivieren, - geplante Jobs allein wegen zeitlicher Überschneidung abschalten, - Treiber oder Firmware ohne Vergleich austauschen, - Uhren während der Untersuchung manuell verändern, - vertrauliche Protokolle ungeschützt speichern, - einen zeitlichen Zusammenhang sofort als Ursache darstellen, - nur den betroffenen Client untersuchen, - nur Netzwerkdaten betrachten und Server oder Anwendung ignorieren. --- **34. Vollständige Prüfreihenfolge** 1. Symptom eindeutig beschreiben. 2. genaue Fehlermeldung sichern. 3. Beginn und Ende dokumentieren. 4. Zeitzone erfassen. 5. Benutzer, Client und Standort bestimmen. 6. Quelle, Ziel, Port und Anwendung dokumentieren. 7. betroffene und nicht betroffene Systeme bestimmen. 8. Häufigkeit und bisherige Zeitpunkte sammeln. 9. Muster nach Uhrzeit, Dauer und Last suchen. 10. Systemzeiten aller Beteiligten kontrollieren. 11. Vergleichssystem festlegen. 12. geeignete Messintervalle bestimmen. 13. Gateway und Ziel kontinuierlich prüfen. 14. betroffenen TCP-Dienst überwachen. 15. DNS-Antworten protokollieren. 16. Anwendungszeiten erfassen. 17. Interfacezustand und Fehlerzähler aufzeichnen. 18. Switchport oder Access Point überwachen. 19. Serverressourcen protokollieren. 20. relevante Ereignisprotokolle sichern. 21. zentrale Protokollierung und Aufbewahrung prüfen. 22. bei Bedarf autorisierten Ringpuffer-Mitschnitt starten. 23. Speicherbedarf und Datenschutz berücksichtigen. 24. Verfahren zum Markieren des Fehlerzeitpunkts festlegen. 25. bei Auftreten des Fehlers Ringpuffer sichern. 26. Daten vor, während und nach dem Ereignis vergleichen. 27. DHCP-, DNS-, Token-, Sitzungs- und Idle-Zeiten prüfen. 28. geplante Jobs, Backups, Scans und Updates korrelieren. 29. Temperatur, Stromversorgung und physische Umgebung berücksichtigen. 30. Provider- und Wartungsereignisse prüfen. 31. Änderungen und Deployments berücksichtigen. 32. gemeinsame Zeitleiste erstellen. 33. konkrete Hypothese formulieren. 34. genau eine kontrollierbare Änderung durchführen. 35. dieselben Messungen weiterlaufen lassen. 36. ausreichend lange Nachbeobachtung durchführen. 37. ursprüngliche Funktion erneut prüfen. 38. Vergleichssysteme kontrollieren. 39. temporäre Diagnosekonfiguration entfernen. 40. Ursache, Maßnahme und Nachweis dokumentieren. 41. dauerhaftes Monitoring oder Prävention festlegen. --- **35. Dokumentationsbeispiel** ```text Ticket: INC-20804 Zeitraum der Untersuchung: 02.08.2026 bis 05.08.2026 Betroffen: Client-WS-17, Ethernet, Switch SW-F2-03, Port 18 Nicht betroffen: weitere Clients desselben VLANs Ziel: fileserver.example.test, TCP 445 Symptom: Der Client verliert ein- bis dreimal täglich für ungefähr 5 bis 15 Sekunden den Zugriff auf den Dateiserver. Anschließend funktioniert der Zugriff ohne Benutzeraktion wieder. Erfasste Fehlerzeitpunkte: - 02.08.2026, 10:17:42 bis 10:17:51 Uhr - 03.08.2026, 14:32:08 bis 14:32:19 Uhr - 05.08.2026, 09:06:14 bis 09:06:23 Uhr Messungen: - kontinuierlicher Ping zu Gateway und Dateiserver - TCP-Prüfung auf Port 445 - Interfacezähler des Clients - Switchportstatus und Fehlerzähler - Windows-Systemereignisse - begrenzter Ringpuffer-Paketmitschnitt - Serverressourcen und SMB-Protokolle Beobachtung: Zum jeweiligen Fehlerzeitpunkt meldete der Switch einen kurzen Linkverlust an Port 18. Gleichzeitig wechselte das Clientinterface in den Zustand „Disconnected“. Gateway und Server waren für andere Clients erreichbar. Am Switchport stiegen zusätzlich die physischen Fehlerzähler. Hypothese: Die physische Verbindung zwischen Client und Switch ist instabil. Kontrollierte Änderung: Das Patchkabel wurde durch ein geprüftes Kabel ersetzt. Client, Switchport, Treiber und Serverkonfiguration blieben unverändert. Nachprüfung: - sieben Tage kontinuierliche Beobachtung - keine weiteren Link-Flaps - keine steigenden physischen Fehlerzähler - Gateway und Dateiserver durchgehend erreichbar - ursprünglicher Dateizugriff funktioniert - andere Systeme unverändert fehlerfrei Ursache: Beschädigtes Patchkabel mit sporadischer Unterbrechung. Prävention: - Switchport-Flaps zentral überwachen - steigende physische Fehlerzähler alarmieren - Fehlerzeitpunkte im Ticket immer sekundengenau dokumentieren ``` --- **36. Checkliste „Fehler tritt nur manchmal auf“** - [ ] das genaue Symptom wurde beschrieben. - [ ] der originale Meldungstext wurde gesichert. - [ ] Fehlercode oder Event-ID wurde dokumentiert. - [ ] Beginn und Ende des Fehlers wurden erfasst. - [ ] die Zeitzone wurde dokumentiert. - [ ] Benutzer, Client und Standort sind bekannt. - [ ] Quelle, Ziel, Port und Anwendung sind bekannt. - [ ] betroffene und nicht betroffene Systeme wurden bestimmt. - [ ] Häufigkeit und bisherige Zeitpunkte wurden gesammelt. - [ ] zeitliche oder belastungsabhängige Muster wurden gesucht. - [ ] Systemzeiten der beteiligten Systeme wurden geprüft. - [ ] ein funktionierendes Vergleichssystem wurde festgelegt. - [ ] Messintervalle sind kürzer als die vermutete Fehlerdauer. - [ ] Gateway und Ziel werden kontinuierlich geprüft. - [ ] der tatsächliche Dienst wird zusätzlich zu Ping geprüft. - [ ] DNS wird bei passenden Symptomen protokolliert. - [ ] Anwendungszeiten werden bei passenden Symptomen erfasst. - [ ] Interfacezustand und Fehlerzähler werden aufgezeichnet. - [ ] Switchport oder Access Point werden berücksichtigt. - [ ] Serverressourcen werden erfasst. - [ ] relevante Ereignisprotokolle sind ausreichend lange verfügbar. - [ ] Monitoringauflösung wurde kontrolliert erhöht. - [ ] Ringpuffer besitzt eine Größen- oder Zeitbegrenzung. - [ ] Paketaufzeichnung erfolgt nur mit Berechtigung. - [ ] Verfahren zum Markieren des Fehlerzeitpunkts ist festgelegt. - [ ] Daten vor, während und nach dem Fehler wurden gesichert. - [ ] DHCP-Lease und DNS-TTL wurden berücksichtigt. - [ ] Token-, Session- und Idle-Timeouts wurden berücksichtigt. - [ ] VPN-Rekeying und Firewall-Sitzungen wurden berücksichtigt. - [ ] geplante Jobs, Backups, Scans und Updates wurden geprüft. - [ ] Temperatur und Stromversorgung wurden berücksichtigt. - [ ] Änderungen und Deployments wurden geprüft. - [ ] Daten mehrerer Systeme wurden auf einer Zeitleiste korreliert. - [ ] Korrelation und nachgewiesene Ursache wurden getrennt bewertet. - [ ] eine konkrete Hypothese wurde formuliert. - [ ] nur eine kontrollierbare Änderung wurde vorgenommen. - [ ] die Nachbeobachtung war ausreichend lang. - [ ] ursprüngliche Funktion und Vergleichssysteme wurden geprüft. - [ ] temporäre Diagnosekonfigurationen wurden entfernt. - [ ] Ursache, Maßnahme und Nachweis wurden dokumentiert. - [ ] Monitoring oder Prävention wurde festgelegt. --- **37. Schnellreferenz** | Beobachtung | wahrscheinlicher Untersuchungsbereich | |---|---| | Fehler immer zur gleichen Uhrzeit | Job, Backup, Scan, Update oder Provider | | Fehler nach fester Laufzeit | Lease, Token, Session, NAT, Firewall oder VPN | | Fehler nach Inaktivität | Idle-Timeout, Energiesparen oder Sitzung | | nur ein Client betroffen | Client, Kabel, Treiber, Port oder Benutzerprofil | | alle Clients eines Standorts betroffen | Uplink, WAN, Firewall, Strom oder Provider | | nur WLAN betroffen | Funkumgebung, Roaming, Airtime oder Access Point | | nur beim Standortwechsel | Roaming, Authentifizierung oder Funkabdeckung | | nur unter Last | CPU, RAM, Storage, Queue, Uplink oder Pool | | nur nachts | Backup, Snapshot, Wartung, Scan oder Replikation | | Linkstatus wechselt kurz | Kabel, Port, Netzwerkkarte, Strom oder Treiber | | Fehlerzähler steigen | physischer Link, Queue, Überlastung oder Hardware | | Netzwerk normal, Anwendung hängt | Anwendung, Backend, Datenbank oder Storage | | nur einzelne Ziel-IP fehlerhaft | Load Balancer, Backend oder Zielpfad | | nur nach Aufwachen | Treiber, DHCP, DNS, VPN oder Energiesparmodus | | nur über VPN | Tunnel, Rekeying, MTU, Gateway oder Route | | Fehler verschwindet nach Neustart | Ressourcen, Speicherleck, Zustand oder Dienst | | Monitoring zeigt nichts | Intervall zu groß, falscher Test oder fehlende Rohdaten | | Logs zeigen nichts | falsches Protokoll, Rotation, Zeitabweichung oder fehlende Erfassung | | Paketmitschnitt enthält Ereignis nicht | Filter, falsches Interface oder Überschreibung | | zeitlicher Zusammenhang mit Job | mögliche Korrelation, Ursache noch zu beweisen | | Problem tritt bei Temperaturanstieg auf | Kühlung, Netzteil, Transceiver oder Hardware | | regelmäßige DNS-Fehler | Resolver, TTL, Cache, Netzwerkpfad oder DNS-Server | | regelmäßige Abmeldung | Token, Sitzung, Cookie, Proxy oder Load Balancer | | kurze Ausfälle ohne Linkverlust | Dienst, Routing, Firewall, Queue oder Server | | andere Clients funktionieren | gemeinsamer Server nicht automatisch ausgeschlossen, aber Clientpfad priorisieren | --- **Merksatz** > Sporadische Fehler werden selten durch einen einzelnen nachträglichen Test gefunden. Entscheidend sind sekundengenaue Zeitstempel, kontinuierliche Messungen, begrenzte Ringpuffer, ausreichend lange Protokollaufbewahrung und eine gemeinsame Zeitleiste von Client, Netzwerk, Server und Anwendung. Erst wenn Messdaten den Fehler vor, während und nach einer kontrollierten Änderung zeigen, ist die Ursache belastbar nachgewiesen. --- **Quellen und weiterführende Dokumentation** - [Microsoft Learn – Get-WinEvent](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.diagnostics/get-winevent) - [Microsoft Learn – Test-Connection](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.management/test-connection) - [Microsoft Learn – Test-NetConnection](https://learn.microsoft.com/en-us/powershell/module/nettcpip/test-netconnection) - [Microsoft Learn – Get-NetAdapterStatistics](https://learn.microsoft.com/en-us/powershell/module/netadapter/get-netadapterstatistics) - [Microsoft Learn – Resolve-DnsName](https://learn.microsoft.com/en-us/powershell/module/dnsclient/resolve-dnsname) - [Microsoft Learn – Windows Time Service Tools and Settings](https://learn.microsoft.com/en-us/windows-server/networking/windows-time-service/windows-time-service-tools-and-settings) - [Microsoft Learn – Packet Monitor](https://learn.microsoft.com/en-us/windows-server/networking/technologies/pktmon/pktmon) - [Microsoft Learn – pktmon start](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/pktmon-start) - [Microsoft Learn – pktmon etl2pcap](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/pktmon-etl2pcap) - [Microsoft Learn – Windows Event Forwarding](https://learn.microsoft.com/en-us/windows/security/operating-system-security/device-management/use-windows-event-forwarding-to-assist-in-intrusion-detection) - [Wireshark – Dumpcap Manual](https://www.wireshark.org/docs/man-pages/dumpcap.html) - [Wireshark User’s Guide – Capturing with Dumpcap](https://www.wireshark.org/docs/wsug_html_chunked/AppToolsdumpcap.html) - [Wireshark User’s Guide – Capturing with tcpdump](https://www.wireshark.org/docs/wsug_html_chunked/AppToolstcpdump.html) - [tcpdump Manual Page](https://man7.org/linux/man-pages/man1/tcpdump.1.html) - [systemd – journalctl](https://www.freedesktop.org/software/systemd/man/latest/journalctl.html) - [systemd – timedatectl](https://www.freedesktop.org/software/systemd/man/latest/timedatectl.html) - [curl – Write-out Variables](https://curl.se/docs/manpage.html#-w) - [RFC 5905 – Network Time Protocol Version 4](https://www.rfc-editor.org/rfc/rfc5905) - [RFC 2131 – Dynamic Host Configuration Protocol](https://www.rfc-editor.org/rfc/rfc2131) - [RFC 9293 – Transmission Control Protocol](https://www.rfc-editor.org/rfc/rfc9293) # 6.7 Anmeldung an der Domäne geht nicht Wenn sich ein Benutzer nicht an einer Active-Directory-Domäne anmelden kann, liegt die Ursache nicht automatisch an einem falschen Kennwort. Eine Domänenanmeldung benötigt mehrere funktionierende Komponenten: 1. der Client besitzt eine gültige Netzwerkkonfiguration, 2. der Client verwendet die vorgesehenen internen DNS-Server, 3. die Active-Directory-Domäne kann über DNS gefunden werden, 4. ein geeigneter Domain Controller ist erreichbar, 5. Client und Domain Controller besitzen ausreichend übereinstimmende Systemzeiten, 6. das Benutzerkonto ist vorhanden und verwendbar, 7. das Computerkonto und der sichere Kanal zur Domäne funktionieren, 8. Kerberos oder gegebenenfalls NTLM kann die Anmeldung verarbeiten, 9. Gruppenrichtlinien und Benutzerprofile verhindern die Anmeldung nicht, 10. die Domain Controller replizieren die benötigten Informationen ordnungsgemäß. Die sichtbare Meldung am Client beschreibt häufig nur das Ergebnis. Die eigentliche Ursache kann bei DNS, Uhrzeit, Netzwerk, Benutzerkonto, Computerkonto, Domain Controller, Replikation oder Richtlinien liegen. --- **1. Typische Fehlermeldungen** Mögliche Meldungen sind: ```text Der Benutzername oder das Kennwort ist falsch. ``` ```text Es sind momentan keine Anmeldeserver zum Verarbeiten der Anmeldeanforderung verfügbar. ``` ```text Die Sicherheitsdatenbank auf dem Server enthält kein Computerkonto für diese Arbeitsstationsvertrauensstellung. ``` ```text Die Vertrauensstellung zwischen dieser Arbeitsstation und der primären Domäne konnte nicht hergestellt werden. ``` ```text Die angegebene Domäne ist nicht vorhanden, oder es konnte keine Verbindung hergestellt werden. ``` ```text Das referenzierte Konto ist momentan gesperrt und kann nicht für die Anmeldung verwendet werden. ``` ```text Die Anmeldung ist aufgrund einer Kontoeinschränkung nicht möglich. ``` ```text Die Anmeldemethode, die Sie verwenden möchten, ist nicht zulässig. ``` ```text Ihr Konto wurde deaktiviert. Wenden Sie sich an den Systemadministrator. ``` ```text Das Kennwort des Benutzers muss vor der Anmeldung geändert werden. ``` ```text Wir können Sie mit diesen Anmeldeinformationen nicht anmelden, weil Ihre Domäne nicht verfügbar ist. ``` Der genaue deutsche Wortlaut kann sich je nach Windows-Version unterscheiden. Deshalb sollten zusätzlich Fehlercode, Ereignis-ID, Uhrzeit und die englische Originalmeldung dokumentiert werden, wenn sie in einem Protokoll vorhanden ist. --- **2. Auswirkungen** Mögliche Auswirkungen: - ein einzelner Benutzer kann sich nicht anmelden, - alle Benutzer eines Clients sind betroffen, - mehrere Clients eines Standorts sind betroffen, - neue Benutzer können sich nicht anmelden, - bisher angemeldete Benutzer können sich nur mit zwischengespeicherten Anmeldedaten anmelden, - Gruppenrichtlinien werden nicht verarbeitet, - Netzlaufwerke und Drucker werden nicht verbunden, - Kerberos-Authentifizierung funktioniert nicht, - Dienste mit Domänenkonten starten nicht, - ein Computer verliert seine Vertrauensstellung, - Kennwortänderungen werden nicht überall erkannt, - Anmeldungen funktionieren abhängig vom erreichten Domain Controller, - Remoteanmeldungen funktionieren, lokale Konsolenanmeldungen jedoch nicht oder umgekehrt. --- **3. Sicherheits- und Betriebswarnung** Bei der Untersuchung dürfen Benutzerkonten, Computerkonten, Domain Controller und Vertrauensstellungen nicht unkontrolliert verändert werden. Insbesondere sollten nicht vorschnell: - Benutzerkennwörter zurückgesetzt, - Konten entsperrt, ohne die Sperrquelle zu untersuchen, - Computerkonten gelöscht, - Clients aus der Domäne entfernt, - Domain Controller neu gestartet, - DNS-Einträge manuell gelöscht, - Kerberos-Tickets produktiver Sitzungen entfernt, - Gruppenrichtlinien deaktiviert, - Sicherheitsrichtlinien abgeschwächt, - Replikationen erzwungen, - Zeiteinstellungen manuell verändert, - lokale Administratorzugänge neu angelegt, - Protokolle gelöscht werden. Das Entfernen eines Computers aus der Domäne und das anschließende erneute Hinzufügen ist keine Ursachenanalyse. Dadurch können Beweise verloren gehen und zusätzliche Probleme mit Profilen, Zertifikaten, Gruppenrichtlinien, BitLocker, Softwareverteilung oder Verwaltungsdiensten entstehen. Korrekturmaßnahmen sind nur mit entsprechender Berechtigung und nach Sicherung der Diagnosedaten durchzuführen. --- **4. Zuerst den Umfang bestimmen** Die wichtigste erste Frage lautet: > Ist nur ein Benutzer, nur ein Client oder ein größerer Teil der Domäne betroffen? | Beobachtung | zuerst zu untersuchender Bereich | |---|---| | ein Benutzer kann sich an keinem Client anmelden | Benutzerkonto, Kennwort, Sperre, Ablauf, Anmelderechte | | ein Benutzer kann sich nur an einem Client nicht anmelden | Client, lokales Profil, Anmeldeformat, Richtlinie, gespeicherte Daten | | kein Domänenbenutzer kann sich an einem Client anmelden | DNS, Netzwerk, Uhrzeit, sicherer Kanal, Computerkonto | | mehrere Clients eines Standorts sind betroffen | DNS, DHCP, VLAN, Standort-Uplink, Firewall, erreichbarer Domain Controller | | alle Benutzer der Domäne sind betroffen | Domain Controller, DNS, Replikation, Zeitdienst, zentrale Infrastruktur | | Anmeldung funktioniert offline, aber nicht im Firmennetz | erreichter Domain Controller, Kontostatus, Kennwort, DNS oder sicherer Kanal | | Anmeldung funktioniert im Firmennetz, aber nicht über VPN | VPN-Verbindungszeitpunkt, DNS, Routing, Firewall, Gerätezertifikat | | alte Anmeldedaten funktionieren offline | zwischengespeicherte Domänenanmeldung | | neues Kennwort funktioniert nur an manchen Clients | Replikation, erreichter Domain Controller, gespeicherte Anmeldedaten | | lokale Anmeldung funktioniert, Domänenanmeldung nicht | Domänenpfad, Benutzerkonto, DNS, Domain Controller oder Vertrauensstellung | | Anmeldung funktioniert mit einem anderen Domänenbenutzer | Benutzerkonto oder benutzerspezifische Richtlinie priorisieren | | Anmeldung funktioniert nach Neustart gelegentlich wieder | Netzwerkstart, DNS, Dienstreihenfolge, sicherer Kanal oder erreichter DC | Ein einzelner erfolgreicher Anmeldeversuch mit einem anderen Benutzer beweist nicht, dass die gesamte Domäneninfrastruktur fehlerfrei ist. Der andere Benutzer könnte zwischengespeicherte Anmeldedaten verwenden oder einen anderen Authentifizierungspfad besitzen. --- **5. Mindestinformationen erfassen** Vor einer Änderung sollten mindestens dokumentiert werden: ```text Ticket: Datum und genaue Uhrzeit: Zeitzone: Benutzerkonto: Clientname: Client-IP: Standort: Verbindung: Ethernet / WLAN / VPN Domäne: verwendetes Anmeldeformat: genauer Meldungstext: Fehlercode: Anmeldung lokal oder remote: erstmalige oder wiederkehrende Anmeldung: anderer Benutzer am selben Client getestet: derselbe Benutzer an anderem Client getestet: lokale Anmeldung möglich: Netzwerk vor der Anmeldung verfügbar: zuletzt erfolgreiche Anmeldung: kürzlich geändertes Kennwort: zuletzt installierte Updates oder Änderungen: ``` Kennwörter dürfen nicht in das Ticket oder Diagnoseprotokoll geschrieben werden. --- **6. Lokales Konto und Domänenkonto unterscheiden** Die Eingabe auf dem Anmeldebildschirm kann unterschiedliche Kontotypen ansprechen. **Domänenkonto als UPN** ```text benutzer@ad.example.test ``` **Domänenkonto im älteren Format** ```text EXAMPLE\benutzer ``` **Lokales Konto** ```text .\benutzer ``` oder: ```text CLIENT01\benutzer ``` `.\benutzer` bezeichnet ein lokales Konto des aktuellen Computers. Es ist keine Domänenanmeldung. Eine Anmeldung kann fehlschlagen, weil: - versehentlich das lokale Konto ausgewählt wurde, - eine falsche Domäne vorangestellt wurde, - der UPN-Suffix nicht zum Benutzerkonto passt, - ein gleichnamiges lokales Konto existiert, - der zuletzt verwendete Anmeldekontext übernommen wurde, - die Tastaturbelegung auf dem Anmeldebildschirm abweicht. Vor tieferer Diagnose sollte deshalb feststehen, welches Konto Windows tatsächlich authentifizieren soll. --- **7. Gesicherte Anmeldung und zwischengespeicherte Anmeldedaten** Windows kann erfolgreiche Domänenanmeldungen zwischenspeichern. Dadurch kann sich ein Benutzer möglicherweise an einem Notebook anmelden, obwohl momentan kein Domain Controller erreichbar ist. Das bedeutet: ```text Anmeldung erfolgreich ≠ Domain Controller war erreichbar ``` Bei einer zwischengespeicherten Anmeldung können anschließend trotzdem ausfallen: - Gruppenrichtlinien, - Netzlaufwerke, - Domänendrucker, - Kerberos-Tickets, - Zugriff auf interne Anwendungen, - Kennwortänderungen, - Anmeldung mit einem erstmals verwendeten Konto. Typische Hinweise auf eine zwischengespeicherte Anmeldung: - Anmeldung funktioniert ohne Netzwerk, - ein bereits bekannter Benutzer kann sich anmelden, - ein neuer Benutzer kann sich am selben Gerät nicht anmelden, - das neue Kennwort funktioniert nicht, das vorherige jedoch schon, - Domänenressourcen sind nach der Anmeldung nicht erreichbar, - Gruppenrichtlinien werden nicht aktualisiert. Die Anzahl zwischengespeicherter Anmeldungen wird durch Sicherheitsrichtlinien bestimmt. Diese Einstellung sollte nicht allein zur Fehlerbehebung verändert werden. --- **8. Netzwerkstatus vor der Anmeldung berücksichtigen** Eine Domänenanmeldung kann erfolgen, bevor WLAN, VPN oder 802.1X vollständig verfügbar ist. Zu prüfen sind: - ist das Netzwerkkabel angeschlossen, - ist der Switchport aktiv, - ist WLAN bereits am Anmeldebildschirm verbunden, - benötigt das WLAN zuerst eine Benutzeranmeldung, - verwendet der Client Maschinen- oder Benutzerzertifikate, - ist ein Pre-Logon-VPN erforderlich, - startet das VPN erst nach der Windows-Anmeldung, - erhält der Client rechtzeitig eine DHCP-Adresse, - wird ein falsches VLAN zugewiesen, - blockiert Network Access Control den Client, - benötigt der Netzwerkadapter nach dem Start ungewöhnlich lange, - wird durch Fast Startup ein fehlerhafter Netzwerkzustand übernommen. Nach der Anmeldung kann der aktuelle Zustand geprüft werden: ```powershell Get-NetAdapter ``` ```powershell Get-NetIPConfiguration ``` ```cmd ipconfig /all ``` Wichtige Angaben: - IPv4-Adresse, - IPv6-Adresse, - Subnetzmaske oder Präfix, - Standardgateway, - DHCP-Server, - DNS-Server, - DNS-Suffix, - Lease-Zeitpunkt, - Adapterstatus, - Name der Verbindung. Eine Adresse aus `169.254.0.0/16` weist bei IPv4 typischerweise darauf hin, dass keine reguläre DHCP-Konfiguration bezogen wurde. Sie beweist jedoch noch nicht, ob DHCP-Server, Relay, VLAN, Port oder Client die Ursache ist. --- **9. Erreichbarkeit schrittweise prüfen** Nach einer lokalen oder zwischengespeicherten Anmeldung kann der Netzwerkpfad untersucht werden. **Eigene Netzwerkkonfiguration** ```cmd ipconfig /all ``` **Standardgateway** ```powershell Test-Connection -TargetName -Count 4 ``` **Interner DNS-Server** ```powershell Test-Connection -TargetName -Count 4 ``` **Domain Controller** ```powershell Test-Connection -TargetName -Count 4 ``` **Relevante TCP-Verbindungen** ```powershell Test-NetConnection -ComputerName -Port 53 Test-NetConnection -ComputerName -Port 88 Test-NetConnection -ComputerName -Port 389 Test-NetConnection -ComputerName -Port 445 ``` Ein erfolgreicher Ping beweist nicht, dass DNS, Kerberos, LDAP, SMB, RPC oder die Anmeldung funktioniert. Umgekehrt kann Ping durch eine Firewall blockiert sein, obwohl die benötigten Dienste erreichbar sind. Active Directory verwendet mehrere Protokolle und dynamische RPC-Ports. Vier erfolgreiche Porttests ersetzen deshalb keine vollständige Prüfung des Domänenpfades. --- **10. DNS-Konfiguration des Clients prüfen** Active Directory ist in hohem Maß von DNS abhängig. Ein Domänenclient muss die DNS-Server verwenden, welche die Active-Directory-DNS-Zone und die zugehörigen Dienstressourceneinträge auflösen können. Prüfen: ```powershell Get-DnsClientServerAddress ``` ```powershell Get-DnsClientGlobalSetting ``` ```powershell Get-DnsClient ``` Alternativ: ```cmd ipconfig /all ``` Verdächtig sind insbesondere: - ausschließlich ein öffentlicher DNS-Server, - DNS-Server des Internetrouters statt des vorgesehenen AD-DNS, - falsche DNS-Server durch statische Konfiguration, - falsche DNS-Server durch VPN oder DHCP, - unerwarteter DNS-Suffix, - veraltete DNS-Adressen, - nicht erreichbarer bevorzugter DNS-Server, - Split-DNS mit fehlenden internen Einträgen, - unterschiedliche Antworten verschiedener DNS-Server. Öffentliche Resolver können Internetnamen auflösen, kennen aber normalerweise nicht die internen SRV-Einträge der Active-Directory-Domäne. Eine funktionierende Auflösung von `www.example.com` beweist daher nicht, dass Active Directory über DNS gefunden werden kann. --- **11. DNS-Auflösung der Domäne prüfen** **Domänenname auflösen** ```powershell Resolve-DnsName -Name ``` **Domain-Controller-Dienst suchen** ```powershell Resolve-DnsName ` -Name "_ldap._tcp.dc._msdcs." ` -Type SRV ``` **Kerberos-Dienst suchen** ```powershell Resolve-DnsName ` -Name "_kerberos._tcp." ` -Type SRV ``` **Global Catalog suchen** ```powershell Resolve-DnsName ` -Name "_ldap._tcp.gc._msdcs." ` -Type SRV ``` Mit `nslookup`: ```cmd nslookup -type=SRV _ldap._tcp.dc._msdcs. ``` ```cmd nslookup -type=SRV _kerberos._tcp. ``` Erwartet werden SRV-Antworten mit geeigneten Domain Controllern. Anschließend müssen auch deren Hostnamen auflösbar sein: ```powershell Resolve-DnsName -Name ``` Eine vorhandene SRV-Antwort reicht nicht aus, wenn: - der zurückgegebene Domain Controller nicht erreichbar ist, - sein Hostname auf eine falsche IP-Adresse zeigt, - ein veralteter Domain Controller eingetragen ist, - Firewall oder Routing die benötigten Dienste blockieren, - der Client einem falschen AD-Standort zugeordnet wird. --- **12. DNS-Cache kontrolliert untersuchen** Cache anzeigen: ```cmd ipconfig /displaydns ``` PowerShell: ```powershell Get-DnsClientCache ``` Der Cache kann Hinweise auf bereits verwendete Einträge liefern. Erst nach Sicherung der relevanten Informationen kann für einen kontrollierten Vergleich der Clientcache geleert werden: ```cmd ipconfig /flushdns ``` Das Leeren des DNS-Caches ist eine Zustandsänderung. Wenn der Fehler nur sporadisch auftritt, kann dadurch ein wichtiger Hinweis auf einen falschen oder veralteten Eintrag verloren gehen. Eine erfolgreiche Anmeldung nach dem Leeren beweist noch nicht, welcher DNS-Eintrag fehlerhaft war. Dafür müssen Antworten vor und nach der Änderung verglichen werden. --- **13. Domain Controller Locator prüfen** Windows verwendet den Domain Controller Locator, um einen geeigneten Domain Controller zu finden. **Domain Controller suchen** ```cmd nltest /dsgetdc: ``` **Erzwungene erneute Suche** ```cmd nltest /dsgetdc: /force ``` **Domain Controller eines AD-Standorts suchen** ```cmd nltest /dsgetdc: /site: ``` **Clientstandort anzeigen** ```cmd nltest /dsgetsite ``` **Liste der Domain Controller** ```cmd nltest /dclist: ``` Die Ausgabe von `nltest /dsgetdc` kann unter anderem zeigen: - gefundenen Domain Controller, - Adresse, - Domänen-GUID, - AD-Standort, - Eigenschaften wie LDAP, KDC, DNS oder Global Catalog. Fehler wie: ```text ERROR_NO_SUCH_DOMAIN ``` oder: ```text DsGetDcName failed: Status = 1355 ``` weisen darauf hin, dass kein geeigneter Domain Controller gefunden wurde. Die Ursache kann unter anderem bei DNS, Netzwerk, Firewall, AD-Standort, Dienstregistrierung oder Domain Controller liegen. --- **14. Verwendeten Anmeldeserver feststellen** Nach einer erfolgreichen Domänenanmeldung: ```cmd echo %LOGONSERVER% ``` PowerShell: ```powershell $env:LOGONSERVER ``` Zusätzlich: ```cmd whoami ``` ```cmd whoami /user ``` ```cmd whoami /groups ``` Der Wert von `LOGONSERVER` ist hilfreich, darf aber nicht als vollständiger Nachweis für jeden späteren Authentifizierungsvorgang betrachtet werden. Unterschiedliche Dienste können andere Domain Controller oder Kerberos-Dienstpfade verwenden. Wenn die Anmeldung nur bei einem bestimmten Domain Controller fehlschlägt, sind besonders zu prüfen: - Replikation, - DNS-Registrierung, - Erreichbarkeit, - Uhrzeit, - SYSVOL und NETLOGON, - Kerberos, - Kontostand auf diesem DC, - AD-Standortzuordnung. --- **15. Systemzeit und Zeitzone prüfen** Kerberos ist auf ausreichend übereinstimmende Zeit angewiesen. Eine zu große Zeitabweichung kann die Authentifizierung verhindern. **Clientstatus** ```cmd w32tm /query /status ``` **Konfiguration** ```cmd w32tm /query /configuration ``` **Zeitquelle** ```cmd w32tm /query /source ``` **Vergleich mit einem Domain Controller** ```cmd w32tm /stripchart /computer: /dataonly /samples:10 ``` **Windows-Time-Service** ```powershell Get-Service -Name W32Time ``` Zusätzlich dokumentieren: ```powershell Get-Date ``` ```powershell Get-TimeZone ``` Zu prüfen sind: - Datum, - Uhrzeit, - Zeitzone, - Zeitquelle, - letzte erfolgreiche Synchronisierung, - Erreichbarkeit der Zeitquelle, - Zeithierarchie der Domäne, - Zustand des Windows-Zeitdienstes, - Zeit des Hypervisors bei virtuellen Maschinen. Die Uhr darf während der Diagnose nicht unkontrolliert manuell verändert werden. Vor einer Korrektur sollten Status und Abweichung dokumentiert werden. --- **16. Benutzerkonto prüfen** Mit installiertem Active-Directory-PowerShell-Modul und ausreichender Berechtigung: ```powershell Get-ADUser -Identity ` -Properties Enabled, LockedOut, PasswordExpired, PasswordLastSet, AccountExpirationDate, UserPrincipalName, SamAccountName, LastLogonDate, LogonWorkstations ``` Gezielt formatieren: ```powershell Get-ADUser -Identity ` -Properties Enabled, LockedOut, PasswordExpired, PasswordLastSet, AccountExpirationDate, UserPrincipalName, LogonWorkstations | Select-Object SamAccountName, UserPrincipalName, Enabled, LockedOut, PasswordExpired, PasswordLastSet, AccountExpirationDate, LogonWorkstations ``` Zu prüfen sind: - Konto vorhanden, - Konto aktiviert, - Konto gesperrt, - Konto abgelaufen, - Kennwort abgelaufen, - Kennwortänderung erforderlich, - korrekter Benutzerprinzipalname, - korrekter Anmeldename, - erlaubte Arbeitsstationen, - erlaubte Anmeldezeiten, - Smartcard- oder Zertifikatsanforderungen, - Mitgliedschaften in relevanten Gruppen, - wirksame Richtlinien und Anmelderechte. `LastLogonDate` ist nicht für jede sekundengenaue Untersuchung geeignet. Je nach benötigter Genauigkeit müssen die entsprechenden Attribute und Ereignisprotokolle auf den relevanten Domain Controllern ausgewertet werden. --- **17. Kontosperre untersuchen** Ein Konto kann durch wiederholte fehlerhafte Anmeldeversuche gesperrt werden. Mögliche Quellen: - Benutzer gibt mehrfach ein falsches Kennwort ein, - Smartphone verwendet ein altes Kennwort, - gespeicherte Anmeldeinformationen, - getrennte RDP-Sitzung, - Windows-Dienst mit Benutzerkonto, - geplante Aufgabe, - Netzlaufwerk, - Drucker, - VPN-Client, - WLAN-Authentifizierung, - Outlook oder andere Anwendung, - Skript, - Anwendungspool, - zweiter Computer, - Gerät außerhalb des Firmennetzes, - Angriffsversuch. Kontostatus: ```powershell Get-ADUser -Identity -Properties LockedOut | Select-Object SamAccountName, LockedOut ``` Sperrereignisse auf einem Domain Controller: ```powershell Get-WinEvent -FilterHashtable @{ LogName = "Security" Id = 4740 } | Select-Object TimeCreated, Id, Message ``` Ereignis-ID `4740` zeigt eine Kontosperre. Das Ereignis kann Informationen über den aufrufenden Computer enthalten. Nur das Entsperren des Kontos behebt eine wiederkehrende Sperrquelle nicht. Vor dem Entsperren sollten Zeitpunkt, Domain Controller, aufrufender Computer und vorausgehende Authentifizierungsfehler dokumentiert werden. --- **18. Kennwortänderung und Replikation berücksichtigen** Nach einer Kennwortänderung können Probleme entstehen, wenn: - ein Client noch das alte Kennwort verwendet, - gespeicherte Anmeldedaten nicht aktualisiert wurden, - ein Gerät dauerhaft alte Zugangsdaten sendet, - Domain Controller nicht ordnungsgemäß replizieren, - ein Standort nur einen fehlerhaften Domain Controller erreicht, - ein Dienstkontokennwort geändert wurde, die Dienstkonfiguration jedoch nicht, - das Benutzerkonto gesperrt wurde, - der Benutzer offline arbeitet und zwischengespeicherte Anmeldedaten verwendet. Zu erfassen: ```text Zeitpunkt der Kennwortänderung: System, an dem das Kennwort geändert wurde: vermutlich beteiligter Domain Controller: erstes Auftreten des Fehlers: funktioniert altes Kennwort offline: funktioniert neues Kennwort online: funktioniert Anmeldung an anderem Client: funktioniert Anmeldung an anderem Standort: ``` Kennwörter dürfen nicht testweise an mehreren Stellen verteilt oder protokolliert werden. --- **19. Computerkonto prüfen** Ein Domänencomputer besitzt in Active Directory ein eigenes Computerkonto. Mit dem Active-Directory-PowerShell-Modul: ```powershell Get-ADComputer -Identity ` -Properties Enabled, PasswordLastSet, LastLogonDate, DistinguishedName, DNSHostName ``` Formatierte Ausgabe: ```powershell Get-ADComputer -Identity ` -Properties Enabled, PasswordLastSet, LastLogonDate, DistinguishedName, DNSHostName | Select-Object Name, DNSHostName, Enabled, PasswordLastSet, LastLogonDate, DistinguishedName ``` Zu prüfen sind: - Computerkonto vorhanden, - Computerkonto aktiviert, - korrekter Name, - keine unerwarteten doppelten oder alten Objekte, - erwartete Organisationseinheit, - plausibler Zeitpunkt des Maschinenkennworts, - Client wurde nicht aus einem alten Snapshot wiederhergestellt, - Client wurde nicht geklont, ohne korrekt vorbereitet zu werden, - Computerkonto wurde nicht gelöscht und neu erstellt, - Clientname wurde nicht unsachgemäß geändert. `PasswordLastSet` allein beweist nicht, dass der sichere Kanal funktioniert. Es ist nur ein Hinweis innerhalb der Gesamtanalyse. --- **20. Sicheren Kanal prüfen** Der sichere Kanal verbindet einen Domänenmitgliedscomputer mit der Domäne. **PowerShell auf einem Mitgliedscomputer** ```powershell Test-ComputerSecureChannel -Verbose ``` Mit ausdrücklich angegebener Domäne: ```powershell Test-ComputerSecureChannel ` -Server ` -Verbose ``` **NLTEST** ```cmd nltest /sc_query: ``` Zusätzliche Informationen: ```cmd nltest /sc_verify: ``` Je nach Systemrolle und verwendetem Werkzeug unterscheiden sich Bedeutung und Verhalten einzelner Prüfungen. `Test-ComputerSecureChannel` ist für Domänenmitgliedscomputer vorgesehen und sollte nicht als allgemeiner Zustandstest eines Domain Controllers verwendet werden. Ein fehlerhafter sicherer Kanal kann Meldungen verursachen wie: ```text Die Vertrauensstellung zwischen dieser Arbeitsstation und der primären Domäne konnte nicht hergestellt werden. ``` Mögliche Ursachen: - Maschinenkennwort stimmt zwischen Client und AD nicht überein, - Client wurde auf einen alten Snapshot zurückgesetzt, - Computerkonto wurde gelöscht oder neu angelegt, - replizierte Kontodaten sind inkonsistent, - Client wurde fehlerhaft geklont, - lange getrenntes oder zurückgesetztes System, - Wiederherstellung aus einem ungeeigneten Image, - DNS oder Netzwerk verhindert die Kontaktaufnahme. --- **21. Sicheren Kanal nur kontrolliert reparieren** Die folgenden Befehle verändern den Zustand und gehören nicht zur rein lesenden Diagnose. **PowerShell** ```powershell Test-ComputerSecureChannel ` -Repair ` -Credential (Get-Credential) ` -Verbose ``` Alternative: ```powershell Reset-ComputerMachinePassword ` -Server ` -Credential (Get-Credential) ``` Eine Reparatur sollte nur erfolgen, wenn: 1. DNS und Netzwerk geprüft wurden, 2. die Uhrzeit korrekt ist, 3. das richtige Computerkonto identifiziert wurde, 4. der Fehler des sicheren Kanals bestätigt wurde, 5. erforderliche Berechtigungen vorhanden sind, 6. Auswirkungen und Rückfallmöglichkeit bekannt sind, 7. Diagnoseinformationen vorher gesichert wurden. Nach der Reparatur müssen mindestens geprüft werden: - sicherer Kanal, - Neustartanforderung, - Domänenanmeldung, - Gruppenrichtlinien, - Kerberos-Tickets, - Zugriff auf Domänenressourcen, - Verwaltungs- und Sicherheitssoftware, - Ereignisprotokolle. Das Entfernen und erneute Hinzufügen zur Domäne sollte erst nach nachvollziehbarer Diagnose und gemäß dem betrieblichen Verfahren erfolgen. --- **22. Kerberos-Tickets prüfen** Aktuelle Tickets des angemeldeten Sicherheitskontexts: ```cmd klist ``` Kerberos-Ticket-Granting-Tickets anzeigen: ```cmd klist tgt ``` Weitere Sitzungsinformationen: ```cmd klist sessions ``` Verfügbarer Domain Controller: ```cmd klist query_bind ``` Je nach Windows-Version und Sicherheitskontext können die verfügbaren Unterbefehle und sichtbaren Tickets variieren. Die lokale Hilfe ist zu prüfen: ```cmd klist ? ``` Zu untersuchen sind: - ist ein TGT vorhanden, - welcher KDC wurde verwendet, - stimmen Client- und Domänenname, - sind Tickets abgelaufen, - treten Kerberos-Fehler in den Ereignisprotokollen auf, - funktioniert DNS für den KDC, - stimmt die Uhrzeit, - ist der verwendete Dienstprinzipalname korrekt, - wird unerwartet NTLM statt Kerberos verwendet. Tickets kontrolliert entfernen: ```cmd klist purge ``` `klist purge` verändert den Anmeldezustand der aktuellen Sitzung. Vorher sollten die vorhandenen Tickets dokumentiert werden. Eine erfolgreiche Funktion nach dem Purge beweist ohne Vergleich der vorherigen Tickets nicht automatisch die Ursache. --- **23. NTLM und Kerberos unterscheiden** Eine Windows-Domäne kann je nach Vorgang Kerberos oder NTLM verwenden. Vereinfacht: | Bereich | typischer Hinweis | |---|---| | Kerberos-Vorauthentifizierung fehlgeschlagen | Ereignis 4771 | | Kerberos-TGT angefordert | Ereignis 4768 | | Kerberos-Dienstticket angefordert | Ereignis 4769 | | NTLM-Anmeldeinformationen geprüft | Ereignis 4776 | | Anmeldung auf Zielsystem fehlgeschlagen | Ereignis 4625 | | Konto gesperrt | Ereignis 4740 | Ein Ereignis muss immer zusammen mit Zeitpunkt, Benutzer, Clientadresse, Anmeldetyp, Statuscode, Substatus und beteiligtem System bewertet werden. --- **24. Ereignis 4625 auswerten** Ereignis-ID `4625` bedeutet, dass eine Kontoanmeldung fehlgeschlagen ist. Es entsteht auf dem System, auf dem der Anmeldeversuch verarbeitet wurde. Zeitlich begrenzte Abfrage: ```powershell $Start = Get-Date "2026-08-02 09:10:00" $End = Get-Date "2026-08-02 09:20:00" Get-WinEvent -FilterHashtable @{ LogName = "Security" Id = 4625 StartTime = $Start EndTime = $End } | Select-Object TimeCreated, Id, Message ``` Wichtige Felder können sein: - Kontoname, - Kontodomäne, - Anmelde-ID, - Anmeldetyp, - Fehlergrund, - Status, - Substatus, - Arbeitsstationsname, - Quellnetzwerkadresse, - Quellport, - Authentifizierungspaket, - beteiligter Prozess. Häufige Anmeldetypen: | Anmeldetyp | Bedeutung | |---:|---| | 2 | interaktive Anmeldung an der Konsole | | 3 | Netzwerkanmeldung | | 4 | Batch, beispielsweise geplante Aufgabe | | 5 | Dienst | | 7 | Entsperren | | 8 | NetworkCleartext | | 9 | NewCredentials | | 10 | RemoteInteractive, beispielsweise RDP | | 11 | CachedInteractive | Anmeldetyp `11` weist auf eine interaktive Anmeldung mit zwischengespeicherten Domäneninformationen hin. Er bedeutet nicht, dass während der Anmeldung ein Domain Controller erreicht wurde. Status- und Substatuswerte müssen anhand der Microsoft-Dokumentation und des konkreten Ereignisses interpretiert werden. --- **25. Relevante Authentifizierungsereignisse** Auf Client, Mitgliedsserver und Domain Controllern können unter anderem relevant sein: | Ereignis-ID | allgemeine Bedeutung | |---:|---| | 4624 | erfolgreiche Anmeldung | | 4625 | fehlgeschlagene Anmeldung | | 4648 | Anmeldung mit ausdrücklich angegebenen Anmeldeinformationen | | 4672 | besondere Rechte wurden einer neuen Anmeldung zugewiesen | | 4722 | Benutzerkonto aktiviert | | 4725 | Benutzerkonto deaktiviert | | 4726 | Benutzerkonto gelöscht | | 4738 | Benutzerkonto geändert | | 4740 | Benutzerkonto gesperrt | | 4767 | Benutzerkonto entsperrt | | 4768 | Kerberos-TGT angefordert | | 4769 | Kerberos-Dienstticket angefordert | | 4770 | Kerberos-Dienstticket erneuert | | 4771 | Kerberos-Vorauthentifizierung fehlgeschlagen | | 4776 | Anmeldeinformationen wurden über NTLM geprüft | | 5719 | kein Domain Controller für eine sichere Sitzung verfügbar | | 5722 | Authentifizierung der Sitzung beziehungsweise des Computerkontos fehlgeschlagen | | 5805 | Sitzung eines Computers konnte nicht authentifiziert werden | Nicht jedes Ereignis ist standardmäßig aktiviert oder auf jedem System vorhanden. Ereignisse können auf unterschiedlichen beteiligten Computern entstehen. --- **26. Mehrere Ereignisse zeitlich abfragen** ```powershell $Start = Get-Date "2026-08-02 09:10:00" $End = Get-Date "2026-08-02 09:20:00" $Ids = 4624, 4625, 4648, 4740, 4768, 4769, 4771, 4776 Get-WinEvent -FilterHashtable @{ LogName = "Security" Id = $Ids StartTime = $Start EndTime = $End } | Select-Object TimeCreated, Id, ProviderName, LevelDisplayName, Message | Sort-Object TimeCreated ``` Systemereignisse: ```powershell Get-WinEvent -FilterHashtable @{ LogName = "System" Id = 5719, 5722, 5805 StartTime = $Start EndTime = $End } | Select-Object TimeCreated, Id, ProviderName, LevelDisplayName, Message | Sort-Object TimeCreated ``` Für große Protokolle sollte bereits serverseitig mit `FilterHashtable` nach Zeitraum und Ereignis-ID gefiltert werden. --- **27. Ereignisprotokolle auf dem Client prüfen** Relevante Protokolle können sein: ```text Windows-Protokolle → System Windows-Protokolle → Sicherheit Windows-Protokolle → Anwendung Anwendungs- und Dienstprotokolle → Microsoft → Windows → GroupPolicy → Operational Anwendungs- und Dienstprotokolle → Microsoft → Windows → User Profile Service → Operational Anwendungs- und Dienstprotokolle → Microsoft → Windows → DNS Client Events Anwendungs- und Dienstprotokolle → Microsoft → Windows → WLAN-AutoConfig → Operational ``` Vorhandene Protokolle auflisten: ```powershell Get-WinEvent -ListLog * | Where-Object { $_.LogName -match "GroupPolicy|User Profile|DNS|WLAN|Kerberos|Netlogon" } | Select-Object LogName, IsEnabled, RecordCount ``` Nicht jedes Protokoll ist auf jedem System aktiviert. Zusätzliche Protokollierung darf nur kontrolliert unter Berücksichtigung von Speicherbedarf, Datenschutz und Betriebsrichtlinien aktiviert werden. --- **28. Netlogon-Diagnose berücksichtigen** Der Netlogon-Dienst ist unter anderem an Domain-Controller-Ermittlung und sicherem Kanal beteiligt. Dienststatus: ```powershell Get-Service -Name Netlogon ``` Ausführliche Dienstinformationen: ```cmd sc.exe query netlogon ``` Netlogon kann ein Diagnoseprotokoll unter folgendem Pfad verwenden: ```text %windir%\debug\netlogon.log ``` Erweiterte Netlogon-Protokollierung verändert den Diagnosezustand und kann umfangreiche oder sensible Informationen erzeugen. Sie sollte nur gezielt, zeitlich begrenzt und entsprechend der offiziellen Microsoft-Anleitung aktiviert werden. Nach Abschluss muss eine zusätzlich aktivierte Diagnoseprotokollierung wieder auf den vorgesehenen Zustand zurückgesetzt werden. --- **29. Gruppenrichtlinien prüfen** Eine Anmeldung kann technisch erfolgreich sein, während Gruppenrichtlinien, Skripte oder Ressourcenverbindungen fehlschlagen. Aktuelle Richtlinien aktualisieren: ```cmd gpupdate /force ``` Dieser Befehl ist eine aktive Zustandsänderung und sollte erst nach Sicherung der relevanten Ereignisse verwendet werden. Resultierende Richtlinien anzeigen: ```cmd gpresult /r ``` Ausführlicher HTML-Bericht: ```cmd gpresult /h C:\Temp\gpresult.html ``` Relevante Fragen: - erreicht der Client SYSVOL und NETLOGON, - werden Benutzer- und Computerrichtlinien angewendet, - blockiert ein Anmelderecht die interaktive Anmeldung, - ist „Lokal anmelden zulassen“ passend konfiguriert, - greift „Lokal anmelden verweigern“, - greift „Anmelden über Remotedesktopdienste zulassen“, - verhindert eine Software Restriction Policy oder AppLocker einen Bestandteil, - hängt ein Anmelde- oder Startskript, - ist ein Netzlaufwerk oder Druckerziel nicht erreichbar, - wartet die Anmeldung auf das Netzwerk, - wurden Richtlinien kürzlich geändert. Ein lang laufendes Anmeldeskript kann wie eine fehlgeschlagene Anmeldung erscheinen, obwohl die Authentifizierung bereits abgeschlossen wurde. --- **30. SYSVOL und NETLOGON prüfen** Freigaben eines Domain Controllers anzeigen: ```cmd net view \\ ``` SYSVOL testen: ```cmd dir \\\SYSVOL ``` NETLOGON testen: ```cmd dir \\\NETLOGON ``` Wenn diese Pfade nicht erreichbar sind, sind unter anderem zu prüfen: - DNS-Auflösung, - SMB-Erreichbarkeit, - Firewall, - Domain-Controller-Dienstzustand, - SYSVOL-Bereitstellung, - DFS-Replikation, - Netzwerkpfad, - Berechtigungen, - sicherer Kanal. Ein erfolgreicher Verzeichniszugriff beweist nicht, dass alle Gruppenrichtlinien oder die AD-Replikation fehlerfrei sind. --- **31. Benutzerprofilfehler von Authentifizierungsfehlern trennen** Der Benutzer kann erfolgreich authentifiziert worden sein, obwohl Windows das Profil nicht laden kann. Typische Hinweise: ```text Die Anmeldung des Dienstes "Benutzerprofildienst" ist fehlgeschlagen. ``` ```text Das Benutzerprofil kann nicht geladen werden. ``` ```text Sie wurden mit einem temporären Profil angemeldet. ``` Dann sind besonders zu prüfen: - Ereignisse des User Profile Service, - freier Speicherplatz, - Erreichbarkeit eines servergespeicherten Profils, - Berechtigungen, - beschädigtes lokales Profil, - Profilcontainer, - FSLogix bei entsprechender Umgebung, - Antiviren- oder Sicherheitssoftware, - Datenträgerfehler, - Registry-Profilzuordnung, - gleichzeitige Sitzung oder gesperrte Profildatei. Ein Profilproblem darf nicht automatisch als fehlerhaftes Benutzerkonto oder fehlerhafte Domänenauthentifizierung behandelt werden. --- **32. RDP-Anmeldung gesondert untersuchen** Wenn nur die Remotedesktopanmeldung fehlschlägt, zusätzlich prüfen: - RDP-Dienst erreichbar, - TCP-Port erreichbar, - Network Level Authentication, - Benutzer besitzt RDP-Anmelderecht, - Benutzer ist nicht durch eine Richtlinie ausgeschlossen, - Zielsystem kann den Domain Controller erreichen, - Zielsystemzeit stimmt, - Zertifikat oder TLS-Verbindung funktioniert, - CredSSP- oder Sicherheitsrichtlinien sind kompatibel, - keine bereits bestehende oder beschränkte Sitzung, - Anmeldetyp `10` in Ereignis 4625, - Quelladresse und Zielsystem im Ereignis. Porttest: ```powershell Test-NetConnection -ComputerName -Port 3389 ``` Ein erfolgreicher Porttest beweist nur, dass eine TCP-Verbindung hergestellt werden konnte. Er beweist nicht, dass NLA, Authentifizierung, Anmelderechte oder Profilladen funktionieren. --- **33. Anmeldung über VPN untersuchen** Bei entfernten Clients ist entscheidend, wann das VPN verfügbar wird. Mögliche Fälle: 1. Benutzer meldet sich mit zwischengespeicherten Daten an und startet danach das VPN. 2. Ein gerätebasiertes VPN ist bereits vor der Anmeldung aktiv. 3. Ein Pre-Logon-VPN wird am Anmeldebildschirm gestartet. 4. Das VPN benötigt Benutzeranmeldedaten, die erst nach der Windows-Anmeldung verfügbar sind. 5. Das VPN verteilt falsche DNS-Server oder Routen. 6. Der VPN-Tunnel erreicht nicht alle benötigten Domain Controller. 7. MTU-, Firewall- oder Fragmentierungsprobleme stören einzelne Protokolle. 8. Gerätezertifikat oder Maschinenkonto ist fehlerhaft. Nach Aufbau des VPN prüfen: ```cmd ipconfig /all ``` ```powershell Get-DnsClientServerAddress ``` ```powershell Get-NetRoute ``` ```cmd nltest /dsgetdc: ``` ```cmd w32tm /query /status ``` Die erfolgreiche Anmeldung am Notebook vor dem VPN beweist nur, dass zwischengespeicherte Anmeldedaten verwendbar waren. --- **34. Domain Controller diagnostizieren** Auf einem Domain Controller und mit entsprechender Berechtigung: ```cmd dcdiag ``` Ausführliche Ausgabe in eine Datei: ```cmd dcdiag /v > C:\Temp\dcdiag.txt ``` DNS-Prüfung: ```cmd dcdiag /test:dns /v ``` Bestimmten Domain Controller testen: ```cmd dcdiag /s: /v ``` Unternehmensweite Prüfung: ```cmd dcdiag /e /v ``` Die unternehmensweite Prüfung kann umfangreich sein und sollte kontrolliert eingesetzt werden. Zu untersuchen sind unter anderem: - DNS, - Erreichbarkeit, - Netlogon, - Advertising, - Dienste, - Replikation, - SYSVOL, - Rollen und Verzeichniszustand. Nicht jede Warnung in `dcdiag` erklärt automatisch die konkrete Anmeldestörung. Der Zeitpunkt und der betroffene Authentifizierungspfad müssen weiterhin korreliert werden. --- **35. Active-Directory-Replikation prüfen** Zusammenfassung: ```cmd repadmin /replsummary ``` Eingehende Replikationspartner: ```cmd repadmin /showrepl ``` Alle Domain Controller detailliert: ```cmd repadmin /showrepl * /csv ``` Replikationswarteschlange: ```cmd repadmin /queue ``` Zu prüfen sind: - fehlgeschlagene Replikationen, - Zeitpunkt der letzten erfolgreichen Replikation, - Fehlercode, - betroffene Partition, - nur ein Standort oder ein Domain Controller betroffen, - DNS- oder RPC-Fehler, - Zeitabweichung, - Authentifizierungsfehler, - Netzwerkunterbrechung. Eine erzwungene Replikation ist eine aktive Änderung und sollte nicht als erster Diagnoseschritt verwendet werden. Wenn ein Benutzer sein Kennwort geändert hat und die Anmeldung abhängig vom erreichten Domain Controller funktioniert, ist eine Replikationsstörung eine mögliche Hypothese. Sie muss durch Replikationsdaten und den tatsächlich verwendeten Domain Controller bestätigt werden. --- **36. AD-Standorte und Subnetze berücksichtigen** Der Domain Controller Locator berücksichtigt Active-Directory-Standorte. Clientstandort: ```cmd nltest /dsgetsite ``` Gefundener Domain Controller: ```cmd nltest /dsgetdc: ``` Mögliche Fehler: - Clientsubnetz fehlt in Active Directory Sites and Services, - Subnetz ist dem falschen Standort zugeordnet, - lokaler Domain Controller ist nicht erreichbar, - Client verwendet einen entfernten Domain Controller, - DNS liefert veraltete oder ungeeignete Einträge, - Standort-Uplink blockiert benötigte Protokolle, - Anmeldung wird durch hohe Latenz oder Paketverlust verzögert, - nur der Domain Controller eines Standorts besitzt veraltete Daten. Ein entfernter Domain Controller ist nicht automatisch fehlerhaft. Die Standortzuordnung ist jedoch wichtig für Performance, Verfügbarkeit und Fehlereingrenzung. --- **37. Firewall und benötigte Dienste berücksichtigen** Active Directory verwendet mehrere Dienste, beispielsweise: - DNS, - Kerberos, - LDAP, - LDAPS bei entsprechender Konfiguration, - SMB, - RPC Endpoint Mapper, - dynamische RPC-Ports, - Global Catalog, - Kerberos-Kennwortänderung, - Zeitdienst. Einzelne typische Ports: | Dienst | Protokoll/Port | |---|---| | DNS | TCP/UDP 53 | | Kerberos | TCP/UDP 88 | | RPC Endpoint Mapper | TCP 135 | | NetBIOS Name Service | UDP 137 | | NetBIOS Datagram | UDP 138 | | NetBIOS Session | TCP 139 | | LDAP | TCP/UDP 389 | | SMB | TCP 445 | | Kerberos-Kennwortänderung | TCP/UDP 464 | | LDAPS | TCP 636 | | Global Catalog | TCP 3268 | | Global Catalog über TLS | TCP 3269 | | Windows-Zeitdienst | UDP 123 | | dynamisches RPC | versionsabhängiger TCP-Portbereich | Diese Tabelle ist keine vollständige Firewallfreigabe. Die tatsächlich benötigten Verbindungen hängen von Windows-Version, Topologie, Richtung und Funktion ab. Firewalls dürfen nicht pauschal deaktiviert werden. Stattdessen sind verworfene Verbindungen, Quell- und Zieladressen, Ports, Richtung und Zeitpunkt zu untersuchen. --- **38. Paketmitschnitt nur gezielt einsetzen** Wenn DNS, DC Locator, Kerberos oder LDAP weiterhin unklar bleiben, kann ein autorisierter Paketmitschnitt helfen. Mögliche Protokolle: ```text dns kerberos ldap tcp.port == 445 tcp.port == 135 ``` Möglicher Wireshark-Anzeigefilter: ```text dns || kerberos || ldap || tcp.port == 445 || tcp.port == 135 ``` Zu beobachten sind: - DNS-SRV-Abfragen, - zurückgegebene Domain Controller, - fehlgeschlagene Namensauflösung, - Kerberos-AS-REQ und AS-REP, - Kerberos-Fehler, - LDAP-Verbindungsaufbau, - TCP-Retransmissions, - Verbindungszurücksetzungen, - ICMP-Fehler, - stark verzögerte Antworten, - angesprochener Domain Controller, - wechselnde Domain Controller. Paketmitschnitte können Kontonamen, interne Strukturen, Tickets und andere vertrauliche Daten enthalten. Sie dürfen nur autorisiert, begrenzt, geschützt und kontrolliert ausgewertet werden. --- **39. Praxisfall A: Nur ein Benutzer kann sich nicht anmelden** **Symptom** - andere Benutzer können sich am selben Client anmelden, - der Benutzer kann sich auch an einem zweiten Client nicht anmelden, - Meldung weist auf gesperrtes Konto hin. **Prüfung** 1. genaue Uhrzeit dokumentieren, 2. Benutzerkonto und Sperrstatus prüfen, 3. Ereignis `4740` auf den Domain Controllern suchen, 4. aufrufenden Computer ermitteln, 5. vorausgehende Ereignisse `4771`, `4776` oder `4625` korrelieren, 6. gespeicherte Anmeldedaten, Dienste, Aufgaben, VPN und Mobilgeräte prüfen, 7. erst danach Konto kontrolliert entsperren, 8. Ereignisse weiter überwachen. **Mögliche Ursache** Ein geplanter Task auf einem alten Client verwendet weiterhin das vorherige Benutzerkennwort und sperrt das Konto wiederholt. **Nachprüfung** - Aufgabe verwendet ein vorgesehenes Dienstkonto oder aktualisierte sichere Konfiguration, - keine weiteren fehlerhaften Anmeldeversuche, - keine neue Kontosperre, - Benutzer kann sich anmelden, - Sperrquelle und Maßnahme sind dokumentiert. --- **40. Praxisfall B: Kein Benutzer kann sich an einem Client anmelden** **Symptom** - lokale Anmeldung funktioniert, - Domänenanmeldungen schlagen fehl, - andere Clients funktionieren, - `nltest /dsgetdc:` findet keinen Domain Controller. **Prüfung** 1. IP-Konfiguration erfassen, 2. DNS-Server prüfen, 3. SRV-Einträge abfragen, 4. Domain Controller auflösen, 5. Netzwerkpfad prüfen, 6. Systemzeit kontrollieren, 7. sicheren Kanal erst nach Wiederherstellung des Netzwerkpfades testen. **Mögliche Ursache** Der Client verwendet durch eine statische Fehlkonfiguration einen öffentlichen DNS-Server und kann die internen Active-Directory-SRV-Einträge nicht auflösen. **Nachprüfung** - Client erhält die vorgesehenen DNS-Server, - SRV-Abfragen funktionieren, - Domain Controller Locator findet einen geeigneten DC, - sicherer Kanal ist intakt, - Domänenanmeldung und Gruppenrichtlinien funktionieren, - Konfigurationsursache ist dokumentiert. --- **41. Praxisfall C: Vertrauensstellung ist fehlgeschlagen** **Symptom** - lokale Anmeldung funktioniert, - Domänenanmeldung meldet eine fehlerhafte Vertrauensstellung, - DNS und Domain Controller sind erreichbar, - der Client wurde kürzlich aus einem älteren Snapshot wiederhergestellt. **Prüfung** 1. Client- und Computerkonto eindeutig identifizieren, 2. DNS und Uhrzeit prüfen, 3. Computerkonto untersuchen, 4. sicheren Kanal testen, 5. Snapshot-Zeitpunkt und Maschinenkennwort berücksichtigen, 6. Diagnoseereignisse sichern, 7. sicheren Kanal nach Freigabe kontrolliert reparieren. **Mögliche Ursache** Der Snapshot enthält ein älteres Maschinenkennwort als das Computerkonto in Active Directory. **Nachprüfung** - sicherer Kanal funktioniert, - Domänenanmeldung ist möglich, - Gruppenrichtlinien werden verarbeitet, - Kerberos-Tickets werden ausgegeben, - Clientverwaltung funktioniert, - Wiederherstellungsverfahren für Domänencomputer wird angepasst. --- **42. Praxisfall D: Anmeldung funktioniert nur an einem Standort nicht** **Symptom** - Benutzer können sich am Hauptstandort anmelden, - an einer Außenstelle schlagen neue Anmeldungen fehl, - bereits bekannte Benutzer kommen teilweise über zwischengespeicherte Daten hinein, - ein lokaler Domain Controller wird über DNS gefunden. **Prüfung** 1. betroffenen AD-Standort und Subnetz prüfen, 2. gefundenen Domain Controller dokumentieren, 3. DNS- und Dienstereichbarkeit testen, 4. `dcdiag` auf dem lokalen DC auswerten, 5. `repadmin /replsummary` und `/showrepl` prüfen, 6. Uhrzeit vergleichen, 7. Kontostand auf beteiligten Domain Controllern vergleichen, 8. Standort-Uplink und Firewall berücksichtigen. **Mögliche Ursache** Der lokale Domain Controller repliziert Benutzer- und Kennwortänderungen wegen einer gestörten Standortverbindung nicht ordnungsgemäß. **Nachprüfung** - Replikation ist fehlerfrei, - Kennwortänderungen stehen an den vorgesehenen Domain Controllern zur Verfügung, - neue Benutzer können sich anmelden, - keine zwischengespeicherte Anmeldung wird fälschlich als Onlineanmeldung bewertet, - Standortverbindung wird überwacht. --- **43. Praxisfall E: Anmeldung dauert mehrere Minuten** **Symptom** - Anmeldeinformationen werden akzeptiert, - der Bildschirm bleibt lange bei „Willkommen“ oder „Benutzereinstellungen werden angewendet“, - Benutzerprofil wird schließlich geladen, - andere Standorte sind schneller. **Prüfung** 1. Authentifizierungszeit und Profil-Ladezeit trennen, 2. Ereignisse von GroupPolicy und User Profile Service prüfen, 3. `gpresult` auswerten, 4. SYSVOL und NETLOGON testen, 5. Anmelde- und Startskripte untersuchen, 6. Netzlaufwerke und Druckerverbindungen prüfen, 7. DNS und verwendeten Domain Controller erfassen, 8. Serverprofil oder Profilcontainer untersuchen, 9. Zeitlinie von Anmeldung, Richtlinien und Profilladen erstellen. **Mögliche Ursache** Ein Anmeldeskript wartet auf einen nicht erreichbaren Dateiserver, bis ein Timeout abläuft. **Nachprüfung** - Skriptziel ist erreichbar oder kontrolliert entfernt, - Anmeldung erfolgt innerhalb des vorgesehenen Zeitraums, - alle benötigten Richtlinien werden angewendet, - Netzlaufwerke und andere Geschäftsprozesse funktionieren, - Messwerte vor und nach der Änderung sind dokumentiert. --- **44. Ungeeignete Sofortmaßnahmen** Problematisch sind insbesondere: - Benutzerkennwort sofort zurücksetzen, - Konto nur entsperren und die Sperrquelle ignorieren, - Computerkonto löschen, - Client sofort aus der Domäne entfernen, - Domain Controller neu starten, - DNS-Cache leeren, bevor Einträge dokumentiert wurden, - Kerberos-Tickets löschen, bevor sie geprüft wurden, - Firewall vollständig deaktivieren, - Gruppenrichtlinien pauschal abschalten, - Systemzeit manuell verändern, - mehrere Domain Controller gleichzeitig verändern, - Replikation ungeprüft erzwingen, - DNS-Einträge manuell neu anlegen, ohne die Registrierungsursache zu prüfen, - Benutzerprofil löschen, obwohl die Authentifizierung fehlschlägt, - lokale Administratorrechte unnötig vergeben, - Kennwörter in Tickets oder Skripten speichern, - nur Ping verwenden, - nur den Client untersuchen, - eine zwischengespeicherte Anmeldung als erfolgreiche DC-Anmeldung bewerten, - einen erfolgreichen Test mit anderem Benutzer als Beweis für fehlerfreies AD ansehen. --- **45. Vollständige Prüfreihenfolge** 1. genauen Meldungstext sichern. 2. Datum, Uhrzeit und Zeitzone erfassen. 3. Benutzer, Client und Standort bestimmen. 4. lokales Konto und Domänenkonto unterscheiden. 5. verwendetes Anmeldeformat dokumentieren. 6. prüfen, ob eine zwischengespeicherte Anmeldung möglich war. 7. feststellen, ob ein Benutzer, ein Client oder mehrere Systeme betroffen sind. 8. Vergleich mit anderem Benutzer am selben Client durchführen. 9. Vergleich mit demselben Benutzer an einem anderen Client durchführen. 10. Netzwerkstatus vor der Anmeldung berücksichtigen. 11. IP-Konfiguration erfassen. 12. Gateway und internen DNS-Server prüfen. 13. konfigurierte DNS-Server und Suffixe kontrollieren. 14. Active-Directory-SRV-Einträge auflösen. 15. Hostnamen der Domain Controller auflösen. 16. Domain Controller Locator prüfen. 17. AD-Standort des Clients bestimmen. 18. verwendeten Domain Controller dokumentieren. 19. Uhrzeit, Zeitzone und Zeitquelle prüfen. 20. Benutzerkonto auf Aktivierung, Sperre und Ablauf prüfen. 21. Anmeldezeiten und erlaubte Arbeitsstationen berücksichtigen. 22. Kennwortänderung und gespeicherte Anmeldedaten prüfen. 23. Ereignisse `4625`, `4740`, `4771` und `4776` korrelieren. 24. bei RDP den Anmeldetyp und das Zielsystem berücksichtigen. 25. Computerkonto prüfen. 26. sicheren Kanal diagnostizieren. 27. Kerberos-Tickets und KDC prüfen. 28. SYSVOL und NETLOGON testen. 29. Gruppenrichtlinien und Anmeldeskripte untersuchen. 30. Profilfehler von Authentifizierungsfehlern trennen. 31. bei VPN den Pre-Logon-Netzwerkzustand prüfen. 32. Domain Controller mit `dcdiag` untersuchen. 33. Replikation mit `repadmin` prüfen. 34. Firewall-, Routing- und Standortpfad berücksichtigen. 35. Daten aller beteiligten Systeme auf einer Zeitleiste zusammenführen. 36. konkrete Hypothese formulieren. 37. genau eine kontrollierbare Änderung durchführen. 38. dieselben Prüfungen erneut ausführen. 39. Domänenanmeldung testen. 40. Gruppenrichtlinien und Domänenressourcen prüfen. 41. Vergleichsbenutzer und Vergleichsclient testen. 42. Ereignisprotokolle auf neue Fehler prüfen. 43. temporäre Diagnosekonfiguration entfernen. 44. Ursache, Änderung und Nachweis dokumentieren. 45. Monitoring oder Präventionsmaßnahme festlegen. --- **46. Dokumentationsbeispiel** ```text Ticket: INC-20831 Zeitraum: 02.08.2026, 08:14 bis 10:42 Uhr Benutzer: test.user Client: WS-BER-042 Domäne: ad.example.test Standort: Berlin Verbindung: Ethernet Symptom: Kein Domänenbenutzer kann sich an WS-BER-042 anmelden. Lokale Anmeldung ist möglich. Andere Clients desselben Standorts sind nicht betroffen. Meldung: „Es sind momentan keine Anmeldeserver zum Verarbeiten der Anmeldeanforderung verfügbar.“ Vergleich: - anderer Domänenbenutzer am selben Client: fehlgeschlagen - betroffener Benutzer an anderem Client: erfolgreich - lokales Administratorkonto: erfolgreich Messungen: - Client besitzt gültige IPv4-Adresse und erreicht das Standardgateway - interner DNS-Server ist erreichbar - in der statischen Adapterkonfiguration ist jedoch ein öffentlicher DNS-Server eingetragen - Abfrage von _ldap._tcp.dc._msdcs.ad.example.test schlägt fehl - nltest /dsgetdc:ad.example.test liefert Fehler 1355 - Clientzeit ist korrekt - Computerkonto ist vorhanden und aktiviert Hypothese: Der Client kann aufgrund der falschen DNS-Konfiguration keine Active-Directory-Domain-Controller finden. Kontrollierte Änderung: Die statische DNS-Konfiguration wurde entsprechend der freigegebenen Netzwerkdokumentation auf die vorgesehenen internen DNS-Server korrigiert. Andere Einstellungen blieben unverändert. Nachprüfung: - SRV-Abfrage liefert die vorgesehenen Domain Controller - nltest findet einen Domain Controller des korrekten Standorts - sicherer Kanal ist intakt - Domänenanmeldung funktioniert - Gruppenrichtlinien werden verarbeitet - SYSVOL und NETLOGON sind erreichbar - keine neuen Netlogon- oder Anmeldefehler - Vergleichsbenutzer funktioniert ebenfalls Ursache: Falsch statisch eingetragener öffentlicher DNS-Server am Domänenclient. Prävention: - DNS-Konfiguration von Domänenclients zentral überwachen - statische Clientkonfigurationen vermeiden, wenn DHCP vorgesehen ist - Prüfung der AD-SRV-Auflösung in die Clientdiagnose aufnehmen ``` --- **47. Checkliste „Anmeldung an der Domäne geht nicht“** - [ ] der genaue Meldungstext wurde gesichert. - [ ] Fehlercode und Ereignis-ID wurden dokumentiert. - [ ] Datum, Uhrzeit und Zeitzone sind bekannt. - [ ] Benutzer, Client, Standort und Verbindungsart sind bekannt. - [ ] lokales Konto und Domänenkonto wurden unterschieden. - [ ] das verwendete Anmeldeformat wurde geprüft. - [ ] Tastaturbelegung und versehentliche Eingabefehler wurden berücksichtigt. - [ ] der Umfang der Störung wurde bestimmt. - [ ] ein anderer Benutzer wurde am selben Client geprüft. - [ ] derselbe Benutzer wurde an einem anderen Client geprüft. - [ ] eine mögliche zwischengespeicherte Anmeldung wurde erkannt. - [ ] der Netzwerkstatus vor der Anmeldung wurde berücksichtigt. - [ ] IP-Adresse, Gateway, DHCP und DNS wurden dokumentiert. - [ ] der Client verwendet die vorgesehenen internen DNS-Server. - [ ] DNS-Suffixe wurden geprüft. - [ ] die AD-Domäne ist auflösbar. - [ ] LDAP-SRV-Einträge sind auflösbar. - [ ] Kerberos-SRV-Einträge sind auflösbar. - [ ] die zurückgegebenen Domain Controller sind auflösbar und erreichbar. - [ ] Domain Controller Locator wurde geprüft. - [ ] der AD-Standort des Clients wurde bestimmt. - [ ] der tatsächlich verwendete Domain Controller wurde dokumentiert. - [ ] Datum, Uhrzeit, Zeitzone und Zeitquelle wurden geprüft. - [ ] Benutzerkonto ist vorhanden und aktiviert. - [ ] Benutzerkonto ist nicht gesperrt. - [ ] Konto und Kennwort sind nicht abgelaufen. - [ ] erlaubte Anmeldezeiten und Arbeitsstationen wurden berücksichtigt. - [ ] Ereignis `4740` wurde bei Kontosperren untersucht. - [ ] alte gespeicherte Kennwörter wurden als mögliche Sperrquelle berücksichtigt. - [ ] Kennwortänderung und AD-Replikation wurden berücksichtigt. - [ ] Computerkonto ist vorhanden und aktiviert. - [ ] sicherer Kanal wurde diagnostiziert. - [ ] Snapshot-, Klon- oder Wiederherstellungsereignisse wurden berücksichtigt. - [ ] Kerberos-Tickets wurden vor einer Veränderung geprüft. - [ ] Ereignisse `4625`, `4768`, `4769`, `4771` und `4776` wurden passend untersucht. - [ ] Anmeldetyp, Status und Substatus wurden ausgewertet. - [ ] SYSVOL und NETLOGON wurden geprüft. - [ ] Gruppenrichtlinien wurden berücksichtigt. - [ ] Anmeldeskripte und Ressourcenzuordnungen wurden geprüft. - [ ] Profilfehler wurden von Authentifizierungsfehlern getrennt. - [ ] bei RDP wurden NLA und Anmelderechte geprüft. - [ ] bei VPN wurde die Verfügbarkeit vor der Anmeldung berücksichtigt. - [ ] Domain Controller wurden bei Bedarf mit `dcdiag` geprüft. - [ ] Replikation wurde bei Bedarf mit `repadmin` geprüft. - [ ] Firewall und benötigte AD-Dienste wurden berücksichtigt. - [ ] Daten wurden auf einer gemeinsamen Zeitleiste korreliert. - [ ] keine Kennwörter wurden protokolliert. - [ ] nur eine kontrollierbare Änderung wurde durchgeführt. - [ ] Domänenanmeldung wurde nach der Änderung erneut geprüft. - [ ] Gruppenrichtlinien und Domänenressourcen funktionieren. - [ ] Vergleichsbenutzer und Vergleichsclient funktionieren. - [ ] temporäre Diagnosekonfiguration wurde entfernt. - [ ] Ursache, Maßnahme und Nachweis wurden dokumentiert. - [ ] eine Präventions- oder Monitoringmaßnahme wurde festgelegt. --- **48. Schnellreferenz** | Beobachtung | wahrscheinlicher Untersuchungsbereich | |---|---| | ein Benutzer überall betroffen | Konto, Kennwort, Sperre, Ablauf oder Anmelderechte | | alle Benutzer an einem Client betroffen | DNS, Netzwerk, Uhrzeit, Computerkonto oder sicherer Kanal | | mehrere Clients eines Standorts betroffen | Standort-DNS, VLAN, Uplink, Firewall oder lokaler DC | | lokale Anmeldung funktioniert | lokales System grundsätzlich zugänglich; Domänenpfad weiter prüfen | | alter Benutzer funktioniert offline | wahrscheinlich zwischengespeicherte Anmeldung | | neuer Benutzer funktioniert offline nicht | keine zwischengespeicherten Anmeldedaten vorhanden | | altes Kennwort funktioniert offline | Cache; keine Bestätigung des aktuellen Domänenkennworts | | öffentliches DNS funktioniert, AD nicht | interne AD-DNS-Zone oder SRV-Auflösung | | Fehler 1355 bei `nltest` | Domain Controller konnte nicht gefunden werden | | Uhrzeit stark abweichend | Kerberos und Zeitdienst | | Konto gesperrt | Sperrquelle über 4740 und vorausgehende Fehler suchen | | Sperre kehrt sofort zurück | Gerät, Dienst, Aufgabe, VPN oder gespeicherte Daten | | Vertrauensstellung fehlgeschlagen | Computerkonto oder sicherer Kanal | | Fehler nach Snapshot-Rückkehr | Maschinenkennwort oder Computerzustand | | Anmeldung abhängig vom DC | Replikation, DC-Zustand, DNS oder Standort | | Anmeldung funktioniert, Profil lädt nicht | User Profile Service, Speicher oder Profilpfad | | Anmeldung bleibt bei „Willkommen“ hängen | Gruppenrichtlinie, Skript, Profil oder Ressource | | RDP allein betroffen | NLA, RDP-Rechte, Zielsystem oder Anmeldetyp 10 | | VPN allein betroffen | Pre-Logon-Verbindung, DNS, Routing, Zertifikat oder Tunnel | | SYSVOL nicht erreichbar | DNS, SMB, DC, DFS-Replikation oder Firewall | | `Test-ComputerSecureChannel` negativ | sicheren Kanal und Voraussetzungen gezielt untersuchen | | Ping erfolgreich, Anmeldung fehlschlägt | DNS, Kerberos, LDAP, SMB, RPC, Konto oder Richtlinie | | anderes Konto funktioniert | benutzerspezifischen Bereich priorisieren | | derselbe Benutzer funktioniert an anderem Client | Client oder clientspezifische Richtlinie priorisieren | | keine Ereignisse gefunden | falsches System, falscher Zeitraum, Auditierung oder Rotation | | Anmeldung nach DNS-Korrektur möglich | DNS-Ursache durch Vorher-Nachher-Daten bestätigen | | Anmeldung nach Neustart möglich | Zustand geändert; Ursache noch nicht bewiesen | --- **Merksatz** > Eine Domänenanmeldung ist kein einzelner Vorgang, sondern eine Kette aus Netzwerk, DNS, Domain Controller Locator, Zeit, Benutzerkonto, Computerkonto, sicherem Kanal und Authentifizierungsprotokoll. Die Diagnose beginnt deshalb mit dem genauen Umfang und dem originalen Fehlerzeitpunkt. Erst danach werden Client, DNS, Domain Controller und Ereignisprotokolle auf einer gemeinsamen Zeitleiste geprüft. --- **Quellen und weiterführende Dokumentation** - [Microsoft Learn – Troubleshoot domain controller location issues](https://learn.microsoft.com/en-us/troubleshoot/windows-server/windows-security/troubleshoot-domain-controller-location-issues) - [Microsoft Learn – Locating domain controllers in Windows and Windows Server](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/dc-locator) - [Microsoft Learn – Domain controller is not functioning correctly](https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/domain-controller-not-functioning-correctly) - [Microsoft Learn – Active Directory domain join troubleshooting guidance](https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/active-directory-domain-join-troubleshooting-guidance) - [Microsoft Learn – Event ID 5719, error 1311 or error 1355](https://learn.microsoft.com/en-us/troubleshoot/windows-server/windows-security/troubleshoot-kerberos-domain-not-found-event-id-5719) - [Microsoft Learn – Diagnose Active Directory replication failures](https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/diagnose-replication-failures) - [Microsoft Learn – Best practices for DNS client settings](https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/best-practices-for-dns-client-settings) - [Microsoft Learn – Advanced Audit Policy Configuration settings](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/advanced-audit-policy-configuration) - [Microsoft Learn – Appendix L: Events to Monitor](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/plan/appendix-l--events-to-monitor) - [Microsoft Learn – Event 4740: A user account was locked out](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-4740) - [Microsoft Learn – nltest](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/cc731935%28v%3Dws.11%29) - [Microsoft Learn – Test-ComputerSecureChannel](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.management/test-computersecurechannel) - [Microsoft Learn – Reset-ComputerMachinePassword](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.management/reset-computermachinepassword) - [Microsoft Learn – Get-ADUser](https://learn.microsoft.com/en-us/powershell/module/activedirectory/get-aduser) - [Microsoft Learn – Get-ADComputer](https://learn.microsoft.com/en-us/powershell/module/activedirectory/get-adcomputer) - [Microsoft Learn – Resolve-DnsName](https://learn.microsoft.com/en-us/powershell/module/dnsclient/resolve-dnsname) - [Microsoft Learn – Test-NetConnection](https://learn.microsoft.com/en-us/powershell/module/nettcpip/test-netconnection) - [Microsoft Learn – dcdiag](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/dcdiag) - [Microsoft Learn – repadmin](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/cc770963%28v%3Dws.11%29) - [Microsoft Learn – klist](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/klist) - [Microsoft Learn – w32tm](https://learn.microsoft.com/en-us/windows-server/networking/windows-time-service/windows-time-service-tools-and-settings) - [Microsoft Learn – gpresult](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/gpresult) - [Microsoft Learn – Get-WinEvent](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.diagnostics/get-winevent) # 7. Schnelle Entscheidungsbäume # 7.1 Ein Client hat kein Netzwerk Wenn nur ein einzelner Client keine Netzwerkverbindung besitzt, sollte die Fehlersuche schnell feststellen, auf welcher Ebene die Verbindung unterbrochen ist: 1. Netzwerkadapter, 2. physische oder drahtlose Verbindung, 3. IP-Konfiguration, 4. lokales Netzwerk, 5. Routing, 6. DNS, 7. Zielsystem oder Anwendung. Dieser Entscheidungsbaum dient der schnellen Eingrenzung. Die ausführliche Ende-zu-Ende-Analyse befindet sich auf der Seite **6.1 Client ohne Netzwerkverbindung – systematische Ende-zu-Ende-Analyse**. --- **1. Störungsumfang bestimmen** Zuerst prüfen: - ist wirklich nur ein Client betroffen, - funktionieren andere Clients am selben Switch oder Access Point, - betrifft der Fehler Ethernet, WLAN oder beide Verbindungsarten, - sind interne Ziele, das Internet oder nur einzelne Dienste nicht erreichbar, - begann die Störung nach einer Änderung, - funktioniert der Client an einem anderen Anschluss oder in einem anderen WLAN? | Beobachtung | Nächster Untersuchungsbereich | |---|---| | nur ein Client betroffen | Client, Anschluss, Kabel, WLAN oder lokale Konfiguration | | mehrere Clients betroffen | Switch, Access Point, VLAN, DHCP, Gateway oder Standortverbindung | | nur eine Anwendung betroffen | Anwendung, Proxy, Dienst, Port oder Zertifikat | | IP-Ziele erreichbar, Namen nicht | DNS | | interne Ziele erreichbar, Internet nicht | Gateway, Firewall, Proxy oder Internetübergang | | Internet erreichbar, interne Ziele nicht | Routing, VPN, interne DNS-Zone oder Zugriffskontrolle | | Ethernet betroffen, WLAN funktioniert | Kabel, Switchport, Ethernetadapter oder VLAN | | WLAN betroffen, Ethernet funktioniert | WLAN-Profil, Authentifizierung, Signal oder Access Point | | beide Verbindungsarten betroffen | Clientkonfiguration, VPN, Firewall, Routing oder Betriebssystem | Wenn mehrere Clients betroffen sind, zum Entscheidungsbaum für Standort- oder Bereichsstörungen wechseln. --- **2. Besteht eine Verbindung zum Netzwerkmedium?** **Ethernet** Prüfen: - ist das Netzwerkkabel vollständig eingesteckt, - leuchten oder blinken die Link-LEDs, - ist der Adapter aktiviert, - erkennt Windows eine Verbindung, - funktioniert ein geprüftes Ersatzkabel, - funktioniert derselbe Anschluss mit einem Vergleichsgerät, - funktioniert der Client an einem anderen freigegebenen Switchport? Adapterstatus anzeigen: ```powershell Get-NetAdapter ``` Nur physische Adapter anzeigen: ```powershell Get-NetAdapter -Physical ``` Ausführliche Adapterinformationen: ```powershell Get-NetAdapter | Format-List Name, InterfaceDescription, Status, LinkSpeed, MacAddress ``` **Entscheidung** - Status `Up` → mit der IP-Konfiguration fortfahren. - Status `Disconnected` → Kabel, Dose, Patchfeld, Switchport und Adapter prüfen. - Status `Disabled` → klären, warum der Adapter deaktiviert ist. - Adapter fehlt vollständig → Geräteerkennung, Treiber, Hardware oder BIOS/UEFI prüfen. - Link besteht nur mit einem anderen Kabel → ursprüngliches Kabel austauschen. - Link besteht nur an einem anderen Port → ursprünglichen Anschluss und dessen Konfiguration untersuchen. Ein leuchtendes Link-Signal bestätigt nur die physische Verbindung. Es beweist nicht, dass VLAN, DHCP, Routing, DNS oder Anwendungen funktionieren. --- **WLAN** WLAN-Schnittstelle und Verbindungszustand anzeigen: ```cmd netsh wlan show interfaces ``` Sichtbare WLAN-Netze anzeigen: ```cmd netsh wlan show networks ``` Gespeicherte WLAN-Profile anzeigen: ```cmd netsh wlan show profiles ``` Prüfen: - ist WLAN eingeschaltet, - ist der Flugmodus ausgeschaltet, - wird die vorgesehene SSID angezeigt, - ist der Client tatsächlich mit dieser SSID verbunden, - stimmt die BSSID beziehungsweise der verbundene Access Point, - ist die Signalqualität ausreichend, - wurde die WLAN-Authentifizierung erfolgreich abgeschlossen, - verwendet der Client das vorgesehene Benutzer- oder Computerzertifikat, - greift eine zentrale WLAN-Richtlinie, - wurde der Client in das richtige VLAN eingeordnet? **Entscheidung** - SSID nicht sichtbar → Reichweite, Access Point, Funkband, Kanal, Treiber oder Richtlinie prüfen. - SSID sichtbar, Verbindung scheitert → Profil, Schlüssel, 802.1X, Zertifikat oder RADIUS untersuchen. - WLAN verbunden, aber keine gültige IP-Konfiguration → DHCP oder VLAN prüfen. - Verbindung besteht mit falscher SSID → mit dem vorgesehenen Netz verbinden. - sehr schwaches oder stark schwankendes Signal → Abstand, Störungen, Funkabdeckung und Roaming prüfen. Ein angezeigter WLAN-Status „Verbunden“ bestätigt noch keine funktionierende IP-Verbindung. --- **3. Besitzt der Client eine gültige IP-Konfiguration?** Vollständige Konfiguration erfassen: ```cmd ipconfig /all ``` Alternativ mit PowerShell: ```powershell Get-NetIPConfiguration ``` Zu dokumentieren sind: - verwendeter Netzwerkadapter, - IPv4- und gegebenenfalls IPv6-Adresse, - Subnetzmaske beziehungsweise Präfixlänge, - Standardgateway, - DHCP aktiviert oder deaktiviert, - DHCP-Server, - Lease-Zeiten, - DNS-Server, - DNS-Suffix, - Medienstatus, - eventuell vorhandene virtuelle Adapter. **Entscheidungsbaum zur IPv4-Adresse** ```text Besitzt der aktive Adapter eine IPv4-Adresse? | +-- Nein | | | +-- DHCP vorgesehen? | | | +-- Ja -> DHCP-Client, VLAN, Switchport, Access Point, | | DHCP-Server und DHCP-Relay prüfen | | | +-- Nein -> statische Konfiguration mit Netzwerkplan vergleichen | +-- Ja | +-- Adresse beginnt mit 169.254? | | | +-- Ja -> keine verwendbare DHCP-Konfiguration erhalten | DHCP-Pfad untersuchen | +-- Adresse 0.0.0.0 oder unvollständig? | | | +-- Ja -> Adapter-, DHCP- oder Konfigurationsfehler | +-- Adresse aus erwartetem Subnetz? | +-- Nein -> falsches VLAN, falscher DHCP-Bereich, | statische Fehlkonfiguration oder fremdes Netz | +-- Ja -> Gateway und lokale Erreichbarkeit prüfen ``` Eine Adresse aus `169.254.0.0/16` ist eine automatisch vergebene Link-Local-Adresse. Sie zeigt typischerweise, dass der Client keine verwendbare IPv4-Konfiguration per DHCP erhalten hat. Sie beweist allein jedoch noch nicht, ob DHCP-Server, Relay, VLAN, Kabel, WLAN oder der lokale Client die Ursache ist. --- **4. DHCP-Pfad prüfen** Wenn DHCP vorgesehen ist, zunächst den bestehenden Zustand dokumentieren. DHCP-Clientdienst prüfen: ```powershell Get-Service -Name Dhcp ``` Adapterkonfiguration prüfen: ```powershell Get-NetIPInterface ``` Mögliche Ursachen: - keine physische Verbindung, - falsches VLAN, - Switchport falsch konfiguriert, - WLAN-Authentifizierung nicht vollständig, - DHCP-Server nicht erreichbar, - DHCP-Relay fehlt oder ist falsch konfiguriert, - DHCP-Bereich ausgeschöpft, - DHCP-Richtlinie oder Filter lehnt den Client ab, - UDP 67 oder 68 wird blockiert, - DHCP-Clientdienst funktioniert nicht, - fremder DHCP-Server liefert eine falsche Konfiguration, - Network Access Control weist ein Quarantäne-VLAN zu. Erst nach Erfassung der ursprünglichen Konfiguration kann eine neue Anforderung kontrolliert ausgelöst werden: ```cmd ipconfig /release ``` ```cmd ipconfig /renew ``` `ipconfig /release` und `ipconfig /renew` verändern den aktuellen Netzwerkzustand. Sie sollten nicht vor der Dokumentation der vorhandenen Adresse, Lease-Daten und Fehlersituation ausgeführt werden. **Ergebnis bewerten** - gültige Adresse wird vergeben → Lease-Daten und Erreichbarkeit weiterprüfen. - Zeitüberschreitung → DHCP-Anfrage oder Antwort erreicht ihr Ziel möglicherweise nicht. - falsches Subnetz wird vergeben → DHCP-Bereich, Relay, VLAN oder fremden DHCP-Server prüfen. - Adresse wird vergeben, Gateway fehlt → DHCP-Optionen oder Richtlinie prüfen. - Adresse wird vergeben, DNS-Server fehlen oder sind falsch → DHCP-DNS-Optionen prüfen. Bei weiterhin unklaren DHCP-Problemen kann ein autorisierter Paketmitschnitt zeigen, ob der DORA-Ablauf vollständig ist: 1. DHCP Discover, 2. DHCP Offer, 3. DHCP Request, 4. DHCP Acknowledge. --- **5. Lokalen TCP/IP-Stack prüfen** Loopback-Adresse testen: ```cmd ping 127.0.0.1 ``` Eigene IPv4-Adresse testen: ```cmd ping ``` **Entscheidung** - Loopback-Test schlägt fehl → lokalen TCP/IP-Stack oder Sicherheitssoftware untersuchen. - Loopback funktioniert, eigene Adresse nicht → Adapterbindung, IP-Konfiguration oder lokale Filter prüfen. - beide Tests funktionieren → Verbindung zum lokalen Netz untersuchen. Ein erfolgreicher Loopback-Test bestätigt nur die lokale TCP/IP-Verarbeitung. Er beweist keine Verbindung zum Switch, WLAN, Gateway oder Internet. --- **6. Standardgateway vorhanden und erreichbar?** Gateway aus der Konfiguration übernehmen: ```cmd ipconfig ``` Routingtabelle anzeigen: ```cmd route print ``` Alternativ: ```powershell Get-NetRoute ``` Gateway testen: ```cmd ping ``` Zusätzliche Verbindungsinformationen: ```powershell Test-NetConnection -ComputerName -InformationLevel Detailed ``` Nachbartabelle anzeigen: ```cmd arp -a ``` Oder mit PowerShell: ```powershell Get-NetNeighbor ``` **Entscheidungsbaum** ```text Ist ein Standardgateway eingetragen? | +-- Nein | | | +-- Nur lokales Subnetz erforderlich? | | | | | +-- Ja -> lokale Ziele weiterprüfen | | +-- Nein -> DHCP-Option oder statische Konfiguration korrigieren | | +-- Ja | +-- Gateway im passenden lokalen Subnetz? | +-- Nein -> IP-Adresse, Maske und Gateway sind inkonsistent | +-- Ja | +-- Gateway erreichbar? | +-- Ja -> Routing außerhalb des lokalen Netzes prüfen | +-- Nein -> VLAN, Switchport, WLAN, ARP, lokale Firewall oder Gateway untersuchen ``` Wenn der Gateway-Ping scheitert, kann das Gateway ICMP blockieren. Deshalb zusätzlich prüfen: - erscheint das Gateway in der ARP- beziehungsweise Nachbartabelle, - erreichen Vergleichsclients das Gateway, - funktioniert der Zugriff auf ein anderes System im selben Subnetz, - zeigen Switch und Access Point den Client im erwarteten VLAN, - bestehen Port-Security-, NAC- oder MAC-Filterregeln? Ein fehlgeschlagener Ping allein beweist nicht, dass das Gateway ausgefallen ist. --- **7. Ist ein anderes Ziel im lokalen Subnetz erreichbar?** Vergleichsziel im gleichen Subnetz testen: ```cmd ping ``` Gezielten Dienst prüfen: ```powershell Test-NetConnection -ComputerName -Port ``` **Entscheidung** - lokales Ziel erreichbar, Gateway nicht → Gateway, ICMP-Filterung oder Gateway-Adresse prüfen. - weder lokales Ziel noch Gateway erreichbar → Layer 2, VLAN, Subnetzmaske, ARP, Port-Security oder Clientadapter prüfen. - lokale Ziele funktionieren → Verbindung über das Gateway untersuchen. - nur ein bestimmtes lokales Ziel scheitert → Zielsystem, Dienst, Firewall oder Berechtigung prüfen. --- **8. Funktioniert die Verbindung zu einer externen IP-Adresse?** Ein freigegebenes bekanntes IP-Ziel verwenden: ```cmd ping ``` Pfad untersuchen: ```cmd tracert ``` PowerShell-Diagnose: ```powershell Test-NetConnection -ComputerName -InformationLevel Detailed ``` **Entscheidung** - Gateway erreichbar, externe IP nicht → Routing, Firewall, NAT, VPN oder Internetübergang prüfen. - externe IP erreichbar → grundlegendes IP-Routing funktioniert; DNS prüfen. - `tracert` endet am ersten Hop → Gateway oder nachgelagertes Routing untersuchen. - `tracert` zeigt einzelne Zeitüberschreitungen → nicht automatisch Paketverlust annehmen; Router können ICMP-Antworten begrenzen. - Vergleichsclient erreicht dasselbe Ziel → clientspezifische Route, Firewall, VPN- oder Proxykonfiguration untersuchen. Ein erfolgreicher Ping zu einer externen Adresse beweist nicht, dass DNS oder der benötigte Anwendungsdienst funktioniert. --- **9. Funktioniert die Namensauflösung?** Konfigurierte DNS-Server prüfen: ```cmd ipconfig /all ``` Namensauflösung testen: ```cmd nslookup ``` Mit PowerShell: ```powershell Resolve-DnsName ``` Erreichbarkeit eines DNS-Servers prüfen: ```powershell Test-NetConnection -ComputerName -Port 53 ``` TCP-Port 53 allein genügt nicht für eine vollständige DNS-Prüfung, da DNS abhängig von Anfrage und Umgebung sowohl UDP als auch TCP verwenden kann. **Entscheidungsbaum** ```text Ist eine bekannte IP-Adresse erreichbar? | +-- Nein -> noch kein reines DNS-Problem; | Netzwerkpfad und Routing weiterprüfen | +-- Ja | +-- Kann ein Name aufgelöst werden? | +-- Ja -> Zielanwendung oder Zielport prüfen | +-- Nein | +-- DNS-Server eingetragen? | | | +-- Nein -> DHCP- oder statische DNS-Konfiguration prüfen | +-- DNS-Server erreichbar? | | | +-- Nein -> Routing, VLAN, VPN oder Firewall prüfen | +-- DNS-Server antwortet, liefert aber keinen passenden Eintrag? | +-- DNS-Zone, Eintrag, Weiterleitung, Suchsuffix und verwendeten Namen prüfen ``` DNS-Cache anzeigen: ```cmd ipconfig /displaydns ``` Der DNS-Cache sollte vor einer Löschung dokumentiert werden. Eine sofortige Leerung kann diagnostisch wichtige Einträge und Unterschiede beseitigen. Erst nach der Beweissicherung und wenn dies zur Hypothese passt: ```cmd ipconfig /flushdns ``` --- **10. Funktioniert nur die Anwendung nicht?** Wenn IP-Verbindung und Namensauflösung funktionieren, den tatsächlich benötigten Dienst prüfen. Porttest: ```powershell Test-NetConnection -ComputerName -Port ``` Beispiele: ```powershell Test-NetConnection -ComputerName -Port 443 ``` ```powershell Test-NetConnection -ComputerName -Port 445 ``` ```powershell Test-NetConnection -ComputerName -Port 3389 ``` Zusätzlich prüfen: - läuft der Dienst auf dem Zielsystem, - lauscht er auf dem erwarteten Port, - blockiert eine lokale oder zentrale Firewall, - ist ein Proxy erforderlich, - verwendet die Anwendung einen falschen Proxy, - beeinflusst ein VPN den Datenverkehr, - ist das Zertifikat gültig, - stimmen Systemzeit und Zertifikatszeitraum, - ist nur ein Benutzerkonto betroffen, - benötigt die Anwendung zusätzliche Ports oder Dienste, - funktioniert der Zugriff im Vergleichsclient? Proxykonfiguration anzeigen: ```cmd netsh winhttp show proxy ``` Benutzerbezogene Proxy- und Anwendungseinstellungen können davon abweichen. Eine erfolgreiche TCP-Verbindung beweist außerdem nicht, dass TLS, Authentifizierung oder die Anwendung selbst funktionieren. --- **11. Beeinflusst ein VPN oder virtueller Adapter die Verbindung?** Adapter anzeigen: ```powershell Get-NetAdapter ``` IP-Konfiguration anzeigen: ```powershell Get-NetIPConfiguration ``` Routingtabelle prüfen: ```cmd route print ``` DNS-Server je Schnittstelle anzeigen: ```powershell Get-DnsClientServerAddress ``` Zu prüfen sind: - aktiver VPN-Tunnel, - nicht vollständig beendete VPN-Verbindung, - falsche Standardroute, - Split-Tunneling-Konfiguration, - falsche Routenmetrik, - DNS-Server des VPN, - virtuelle Hyper-V-, Docker-, WSL- oder Virtualisierungsadapter, - Security- oder Filtertreiber, - mehrere gleichzeitig aktive Netzwerkadapter, - veraltete statische Routen. **Vergleichstest** Wenn betrieblich zulässig, den Zustand dokumentieren und anschließend prüfen, ob das Problem nur mit aktivem VPN auftritt. - funktioniert die Verbindung ohne VPN → VPN-Routen, DNS, Filter oder Richtlinien untersuchen. - funktioniert sie ausschließlich mit VPN → lokales Routing, lokales DNS oder Zugriffsvorgaben prüfen. - betrifft der Fehler nur interne Ziele → interne Routen und interne DNS-Auflösung prüfen. - betrifft der Fehler nach Trennung weiterhin alle Ziele → verbliebene Routen, Filtertreiber oder Adapterzustände prüfen. VPN- oder Sicherheitssoftware darf nicht pauschal deinstalliert oder dauerhaft deaktiviert werden. --- **12. Lokale Firewall und Sicherheitssoftware berücksichtigen** Firewallprofile anzeigen: ```powershell Get-NetFirewallProfile ``` Aktive Verbindungen und lauschende Ports: ```powershell Get-NetTCPConnection ``` Zu prüfen sind: - aktuelles Netzwerkprofil, - ausgehende Blockierregeln, - Endpoint-Security- oder EDR-Richtlinien, - Webfilter, - lokale Paketfilter, - kürzlich erfolgte Richtlinienänderungen, - Quarantäne- oder Isolationszustand, - fehlgeschlagene Gerätekonformität, - Network Access Control. Die Firewall oder Sicherheitssoftware darf nicht pauschal deaktiviert werden. Stattdessen sind Protokolle, verworfene Verbindungen, Zieladresse, Zielport, Richtung und Zeitpunkt auszuwerten. --- **13. Vergleichstests durchführen** Geeignete Vergleichstests: | Test | Aussage | |---|---| | anderer Client am selben Anschluss funktioniert | ursprünglichen Client priorisieren | | anderer Client am selben Anschluss funktioniert ebenfalls nicht | Anschluss, VLAN oder Netzwerkpfad priorisieren | | betroffener Client funktioniert an anderem Anschluss | ursprünglichen Anschluss oder dessen Konfiguration prüfen | | betroffener Client funktioniert über WLAN | Ethernetpfad priorisieren | | betroffener Client funktioniert über Ethernet | WLANpfad priorisieren | | gleiche IP-Konfiguration wie Vergleichsclient, aber keine Verbindung | Adapter, Route, Firewall, VPN oder Adresskonflikt prüfen | | nur ein Benutzer betroffen | Benutzerprofil, Proxy, Zertifikat oder Richtlinie prüfen | | alle Benutzer am Client betroffen | Computer-, Adapter- oder Systemkonfiguration priorisieren | Beim Anschlusswechsel ist darauf zu achten, dass der Vergleichsport zum selben vorgesehenen Netz und VLAN gehört. Sonst entsteht kein aussagekräftiger Vergleich. --- **14. Möglichen IP-Adresskonflikt prüfen** Hinweise auf einen Adresskonflikt: - Windows meldet einen IP-Adresskonflikt, - Verbindung funktioniert wechselnd, - ARP-Zuordnung ändert sich, - ein anderes Gerät antwortet auf die Adresse, - eine statisch konfigurierte Adresse liegt im DHCP-Bereich, - nach einem Gerätewechsel tritt der Fehler auf. Nachbartabelle prüfen: ```cmd arp -a ``` Eigene MAC-Adresse erfassen: ```powershell Get-NetAdapter | Format-Table Name, MacAddress, Status ``` Prüfen: - gehört die zur eigenen IP sichtbare MAC-Adresse tatsächlich zum Client, - ist die Adresse doppelt vergeben, - liegt eine statische Adresse im dynamischen DHCP-Bereich, - existiert eine falsche DHCP-Reservierung, - wurde ein Gerät geklont, - verwendet eine virtuelle Maschine dieselbe Adresse? Die ARP-Tabelle sollte vor dem Löschen dokumentiert werden. --- **15. Ereignisprotokolle prüfen** Relevante Protokolle können sich befinden unter: ```text Ereignisanzeige └─ Anwendungs- und Dienstprotokolle └─ Microsoft └─ Windows ├─ DHCP-Client ├─ DNS-Client ├─ NetworkProfile ├─ NlaSvc ├─ TCPIP └─ WLAN-AutoConfig ``` PowerShell-Beispiel für Systemereignisse: ```powershell Get-WinEvent -LogName System -MaxEvents 200 | Where-Object { $_.ProviderName -match 'Tcpip|Dhcp|DNS|WLAN|NlaSvc' } | Select-Object TimeCreated, ProviderName, Id, LevelDisplayName, Message ``` Zu korrelieren sind: - Beginn der Störung, - Linkverlust, - DHCP-Fehler, - Adresskonflikte, - DNS-Fehler, - WLAN-Trennung, - Treiberneustart, - VPN-Verbindung, - Richtlinienänderung, - Energiesparereignis, - Systemstart oder Ruhezustand. Ein einzelnes älteres Ereignis beweist nicht die Ursache der aktuellen Störung. Zeitpunkt, Adapter und Fehlerbild müssen zusammenpassen. --- **16. Treiber und Hardware erst nach der Netzwerkanalyse prüfen** Treiber- oder Hardwareprobleme sind besonders wahrscheinlich, wenn: - der Adapter nicht erkannt wird, - der Link ständig auf- und abgebaut wird, - Ereignisse einen Treiberfehler melden, - der Fehler nach einem Treiber- oder Betriebssystemupdate begann, - der Adapter auch in einem anderen Netz nicht funktioniert, - ein USB-Netzwerkadapter ständig getrennt wird, - andere Geräte am selben Anschluss funktionieren, - ein geprüfter Ersatzadapter funktioniert. Vor Änderungen dokumentieren: - Adaptermodell, - Treiberversion, - Treiberdatum, - Hardware-ID, - Ereignisse, - vorhandene IP-Konfiguration, - Zeitpunkt der letzten Änderung. Adapterinformationen: ```powershell Get-NetAdapter | Format-List Name, InterfaceDescription, DriverInformation, Status, LinkSpeed ``` Ein Treiber sollte nicht allein deshalb neu installiert werden, weil keine Netzwerkverbindung besteht. Zuerst muss geklärt werden, ob der Fehler tatsächlich am Clientadapter liegt. --- **17. Paketmitschnitt nur bei weiterhin unklarer Ursache** Ein autorisierter Paketmitschnitt kann prüfen, ob der Client Pakete sendet und Antworten erhält. Typische Filter: ```text arp ``` ```text dhcp ``` ```text dns ``` ```text icmp ``` Kombinierter Wireshark-Anzeigefilter: ```text arp || dhcp || dns || icmp ``` Zu beobachten sind: - ARP-Anfragen und Antworten, - DHCP Discover, Offer, Request und Acknowledge, - DNS-Anfragen und Antworten, - ICMP-Fehler, - TCP-Verbindungsaufbau, - Retransmissions, - Verbindungszurücksetzungen, - angesprochene Gateways und DNS-Server. Paketmitschnitte können interne Adressen, Namen, Benutzerinformationen und andere vertrauliche Daten enthalten. Sie dürfen nur autorisiert, zeitlich begrenzt und geschützt erstellt werden. --- **18. Schneller Hauptentscheidungsbaum** ```text START: Ein Client hat kein Netzwerk | +-- Sind weitere Clients betroffen? | | | +-- Ja -> Bereichs-, Switch-, WLAN-, VLAN-, DHCP- oder Gatewayfehler | | untersuchen; anderen Entscheidungsbaum verwenden | | | +-- Nein -> am einzelnen Client fortfahren | +-- Ist der aktive Netzwerkadapter vorhanden und aktiviert? | | | +-- Nein -> Adapter, Treiber, Hardware und Gerätestatus prüfen | | | +-- Ja | +-- Besteht Ethernet-Link oder WLAN-Verbindung? | | | +-- Nein -> Kabel, Dose, Port, SSID, Signal oder Authentifizierung | | prüfen | | | +-- Ja | +-- Besitzt der Client eine gültige IP-Adresse? | | | +-- Nein oder 169.254.x.x | | -> DHCP, VLAN, Relay, Port oder statische Konfiguration | | prüfen | | | +-- Ja | +-- Ist ein korrektes Standardgateway vorhanden? | | | +-- Nein -> DHCP-Option oder statische Konfiguration prüfen | | | +-- Ja | +-- Ist das Gateway erreichbar? | | | +-- Nein -> Subnetzmaske, ARP, VLAN, Switchport, WLAN, | | NAC oder lokales Netz prüfen | | | +-- Ja | +-- Ist eine freigegebene externe IP-Adresse erreichbar? | | | +-- Nein -> Routing, Firewall, VPN, NAT oder Internetübergang | | prüfen | | | +-- Ja | +-- Kann der Zielname aufgelöst werden? | | | +-- Nein -> DNS-Server, DNS-Erreichbarkeit, Suffix und Eintrag | | prüfen | | | +-- Ja | +-- Ist der benötigte Zielport erreichbar? | +-- Nein -> Zielservice, Firewall, Proxy oder Routing prüfen | +-- Ja -> Anwendung, TLS, Authentifizierung oder Berechtigung prüfen ``` --- **19. Beispiel für eine schnelle Diagnose** **Symptom** Ein Arbeitsplatz-PC meldet „Kein Internet“. Andere Clients im Büro funktionieren. **Prüfung** ```powershell Get-NetAdapter ``` Ergebnis: ```text Name Status LinkSpeed Ethernet Up 1 Gbps ``` IP-Konfiguration: ```cmd ipconfig /all ``` Ergebnis: ```text IPv4-Adresse: 169.254.38.17 Subnetzmaske: 255.255.0.0 Standardgateway: DHCP aktiviert: Ja ``` **Bewertung** - Netzwerkadapter ist aktiv. - Physischer Link besteht. - Der Client hat jedoch keine verwendbare DHCP-Konfiguration erhalten. - Es liegt noch kein nachgewiesener Internet- oder DNS-Fehler vor. - Der DHCP-Pfad muss geprüft werden. **Vergleichstest** Ein anderes Gerät wird kontrolliert am selben Anschluss geprüft und erhält ebenfalls keine DHCP-Adresse. **Nächster Untersuchungsbereich** - Switchport, - VLAN-Zuordnung, - Patchung, - DHCP-Relay, - DHCP-Erreichbarkeit. **Festgestellte Ursache** Der Switchport wurde versehentlich einem nicht vorgesehenen VLAN zugeordnet. **Nachprüfung** - vorgesehene VLAN-Zuordnung wiederhergestellt, - Client erhält gültige Adresse, Subnetzmaske, Gateway und DNS-Server, - Gateway erreichbar, - interne und externe Ziele erreichbar, - DNS-Auflösung funktioniert, - benötigte Anwendungen funktionieren, - zweiter Client am Anschluss ebenfalls erfolgreich, - Ursache und Änderung dokumentiert. --- **20. Ungeeignete Sofortmaßnahmen** Nicht als erste Maßnahme verwenden: - Client sofort neu starten, - Router oder Switch pauschal neu starten, - Netzwerkadapter mehrfach deaktivieren und aktivieren, - TCP/IP-Konfiguration ungeprüft zurücksetzen, - DNS-Cache vor der Dokumentation löschen, - DHCP-Lease vor der Erfassung freigeben, - statische IP-Adresse „zum Test“ frei erfinden, - öffentliche DNS-Server an einem Unternehmensclient eintragen, - Firewall oder Endpoint-Security vollständig deaktivieren, - VPN-Software ungeprüft deinstallieren, - Netzwerkprofil löschen, - WLAN-Profil sofort entfernen, - Netzwerktreiber sofort deinstallieren, - Switchport ungeprüft in ein anderes VLAN verschieben, - mehrere Änderungen gleichzeitig durchführen, - einen erfolgreichen Ping mit vollständiger Netzwerkfunktion gleichsetzen. Solche Maßnahmen verändern den Zustand, beseitigen Beweise oder erzeugen zusätzliche Fehler. --- **21. Vollständige Schnellprüfreihenfolge** 1. genaue Fehlermeldung und Uhrzeit erfassen. 2. feststellen, ob nur ein Client betroffen ist. 3. Ethernet, WLAN, VPN und betroffene Ziele unterscheiden. 4. Vergleichsclient prüfen. 5. Adapterstatus erfassen. 6. physischen Link oder WLAN-Verbindung prüfen. 7. `ipconfig /all` dokumentieren. 8. IP-Adresse und Subnetz prüfen. 9. bei `169.254.x.x` den DHCP-Pfad untersuchen. 10. Standardgateway prüfen. 11. Routingtabelle erfassen. 12. eigenes TCP/IP über Loopback testen. 13. lokales Vergleichsziel testen. 14. Gateway testen. 15. externe IP-Verbindung testen. 16. Pfad bei Bedarf mit `tracert` untersuchen. 17. DNS-Server und Namensauflösung prüfen. 18. benötigten Zielport testen. 19. Proxy, VPN und virtuelle Adapter berücksichtigen. 20. Firewall- und Sicherheitsprotokolle prüfen. 21. Ereignisse mit dem Fehlerzeitpunkt korrelieren. 22. genau eine Hypothese formulieren. 23. genau eine kontrollierte Änderung durchführen. 24. dieselben Tests erneut ausführen. 25. interne und externe Ziele prüfen. 26. Namensauflösung prüfen. 27. benötigte Anwendungen testen. 28. Vergleichsclient oder Vergleichsanschluss erneut testen. 29. temporäre Diagnosekonfiguration entfernen. 30. Ursache, Maßnahme und Nachweis dokumentieren. --- **22. Checkliste „Ein Client hat kein Netzwerk“** - [ ] genaue Fehlermeldung wurde dokumentiert. - [ ] Beginn und Uhrzeit der Störung sind bekannt. - [ ] es wurde geprüft, ob weitere Clients betroffen sind. - [ ] Ethernet, WLAN und VPN wurden unterschieden. - [ ] interne, externe und einzelne Anwendungsziele wurden unterschieden. - [ ] ein Vergleichsclient wurde geprüft. - [ ] der aktive Netzwerkadapter ist bekannt. - [ ] Adapterstatus und Linkgeschwindigkeit wurden dokumentiert. - [ ] Kabel, Dose oder WLAN-Verbindung wurden geprüft. - [ ] die vollständige IP-Konfiguration wurde gesichert. - [ ] IP-Adresse und Subnetzmaske sind plausibel. - [ ] eine mögliche `169.254.x.x`-Adresse wurde erkannt. - [ ] DHCP- oder statische Konfiguration wurde eindeutig bestimmt. - [ ] DHCP-Server und Lease-Daten wurden dokumentiert. - [ ] Standardgateway ist vorhanden und plausibel. - [ ] DNS-Server sind vorhanden und vorgesehen. - [ ] DNS-Suffix wurde berücksichtigt. - [ ] Loopback-Test wurde durchgeführt. - [ ] lokales Vergleichsziel wurde geprüft. - [ ] Standardgateway wurde geprüft. - [ ] externe IP-Verbindung wurde geprüft. - [ ] Routingtabelle wurde untersucht. - [ ] ARP- beziehungsweise Nachbartabelle wurde berücksichtigt. - [ ] Namensauflösung wurde getrennt von IP-Erreichbarkeit geprüft. - [ ] benötigter Zielport wurde getestet. - [ ] Proxykonfiguration wurde bei Bedarf geprüft. - [ ] VPN und virtuelle Adapter wurden berücksichtigt. - [ ] lokale Firewall und Sicherheitssoftware wurden nicht pauschal deaktiviert. - [ ] ein IP-Adresskonflikt wurde berücksichtigt. - [ ] Ereignisprotokolle wurden mit dem Fehlerzeitpunkt korreliert. - [ ] Treiberänderungen wurden erst nach der Netzwerkanalyse erwogen. - [ ] vor aktiven Änderungen wurden Diagnoseinformationen gesichert. - [ ] nur eine kontrollierbare Änderung wurde durchgeführt. - [ ] die gleichen Tests wurden nach der Änderung wiederholt. - [ ] interne und externe Ziele funktionieren. - [ ] DNS-Auflösung funktioniert. - [ ] benötigte Anwendungen funktionieren. - [ ] Ursache, Änderung und Nachweis wurden dokumentiert. --- **23. Schnellreferenz** | Ergebnis | Nächster Schritt | |---|---| | Adapter fehlt | Hardware, Treiber oder Geräteerkennung prüfen | | Adapter deaktiviert | Ursache der Deaktivierung klären | | Ethernet `Disconnected` | Kabel, Dose, Patchung und Switchport prüfen | | WLAN nicht verbunden | SSID, Signal, Profil und Authentifizierung prüfen | | Adresse `169.254.x.x` | DHCP-Pfad und VLAN untersuchen | | falsches Subnetz | VLAN, DHCP-Bereich oder statische Adresse prüfen | | kein Gateway | DHCP-Option oder statische Konfiguration prüfen | | Gateway nicht erreichbar | Layer 2, ARP, VLAN, Subnetzmaske oder NAC prüfen | | Gateway erreichbar, externe IP nicht | Routing, Firewall, VPN oder Internetübergang prüfen | | externe IP erreichbar, Name nicht | DNS prüfen | | Name auflösbar, Port nicht erreichbar | Dienst, Firewall oder Zielsystem prüfen | | Port erreichbar, Anwendung scheitert | TLS, Authentifizierung, Proxy oder Anwendung prüfen | | nur mit VPN gestört | VPN-Routen, DNS und Filter prüfen | | nur ein Benutzer betroffen | Benutzerprofil, Proxy, Zertifikat oder Richtlinie prüfen | | anderer Client am Port ebenfalls gestört | Port, VLAN oder Netzwerkpfad prüfen | | Client funktioniert an anderem Port | ursprünglichen Anschluss prüfen | | Problem nach Neustart verschwunden | Ursache weiterhin nicht bewiesen; Ereignisse auswerten | | Verbindung nach mehreren Änderungen funktioniert | keine eindeutige Ursachenbestätigung möglich | --- **Merksatz** > Beginne nicht mit dem Internet, sondern am betroffenen Client: Adapter, Link, IP-Adresse, Gateway, externe IP, DNS und Zielport. Jeder erfolgreiche Test bestätigt nur die bis dahin geprüfte Ebene – nicht die gesamte Netzwerkverbindung. --- **Quellen und weiterführende Dokumentation** - [Microsoft Learn – ipconfig](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/ipconfig) - [Microsoft Learn – ping](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/ping) - [Microsoft Learn – tracert](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/tracert) - [Microsoft Learn – pathping](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/pathping) - [Microsoft Learn – arp](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/arp) - [Microsoft Learn – route](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/route_ws2008) - [Microsoft Learn – nslookup](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/nslookup) - [Microsoft Learn – Get-NetAdapter](https://learn.microsoft.com/en-us/powershell/module/netadapter/get-netadapter) - [Microsoft Learn – Get-NetIPConfiguration](https://learn.microsoft.com/en-us/powershell/module/nettcpip/get-netipconfiguration) - [Microsoft Learn – Get-NetRoute](https://learn.microsoft.com/en-us/powershell/module/nettcpip/get-netroute) - [Microsoft Learn – Get-NetNeighbor](https://learn.microsoft.com/en-us/powershell/module/nettcpip/get-netneighbor) - [Microsoft Learn – Test-NetConnection](https://learn.microsoft.com/en-us/powershell/module/nettcpip/test-netconnection) - [Microsoft Learn – Resolve-DnsName](https://learn.microsoft.com/en-us/powershell/module/dnsclient/resolve-dnsname) - [Microsoft Learn – Get-DnsClientServerAddress](https://learn.microsoft.com/en-us/powershell/module/dnsclient/get-dnsclientserveraddress) - [Microsoft Learn – netsh wlan](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/netsh-wlan) - [Microsoft Learn – DHCP troubleshooting guidance](https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/troubleshoot-dhcp-guidance) - [Microsoft Learn – DHCP overview](https://learn.microsoft.com/en-us/windows-server/networking/technologies/dhcp/dhcp-top) - [Microsoft Learn – Get-WinEvent](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.diagnostics/get-winevent) # 7.2 Mehrere Clients haben kein Netzwerk Sind mehrere Clients gleichzeitig betroffen, liegt die Ursache meist nicht an jedem einzelnen Endgerät. Gemeinsam genutzte Komponenten und Dienste müssen deshalb zuerst untersucht werden: - Switch oder Switch-Uplink, - Access Point oder WLAN-Controller, - VLAN, - DHCP, - Standardgateway, - Routing, - DNS, - Firewall, - Standortverbindung, - zentrale Stromversorgung. Dieser Entscheidungsbaum dient der schnellen Eingrenzung. Die ausführliche Analyse befindet sich auf der Seite **6.2 Mehrere Clients oder ganzer Standort ohne Netzwerk**. --- **1. Betroffenen Bereich bestimmen** Zuerst feststellen, welche Gemeinsamkeit die betroffenen Clients besitzen. | Betroffene Systeme | Wahrscheinlicher gemeinsamer Bereich | |---|---| | Clients an einer Netzwerkdose | Dose, Kabel, Patchung oder einzelner Switchport | | Clients an einem Switch | Switch, Uplink, Stromversorgung oder Switchkonfiguration | | Clients in einem VLAN | VLAN, DHCP-Bereich, Gateway, ACL oder Routing | | Clients an einem Access Point | Access Point, Uplink, Stromversorgung oder Funkzelle | | Clients einer SSID | WLAN-Konfiguration, Authentifizierung, RADIUS oder VLAN-Zuweisung | | Clients eines Stockwerks | Etagenverteiler, Access-Switch oder Uplink | | Clients eines Gebäudes | Gebäudeverteiler, Firewall, Gateway oder WAN-Verbindung | | nur kabelgebundene Clients | Switching, Patchung, VLAN oder Ethernet-Uplink | | nur WLAN-Clients | Access Points, Controller, SSID, RADIUS oder Funknetz | | alle Clients eines Standorts | Core-Switch, Firewall, Router, WAN, DHCP, DNS oder Stromversorgung | | nur interne Dienste betroffen | internes Routing, VPN, Firewall, DNS oder Servernetz | | nur Internet betroffen | Internetrouter, Firewall, NAT, Proxy oder Provider | | nur Namen funktionieren nicht | DNS-Dienst oder DNS-Erreichbarkeit | | nur eine Anwendung betroffen | Zielsystem, Dienst, Port, Proxy oder Zertifikat | --- **2. Schneller Hauptentscheidungsbaum** ```text START: Mehrere Clients haben kein Netzwerk | +-- Sind wirklich mehrere Clients betroffen? | | | +-- Nein -> Entscheidungsbaum 7.1 verwenden | | | +-- Ja | +-- Haben die betroffenen Clients eine erkennbare Gemeinsamkeit? | | | +-- gleicher Switch | | -> Switchstatus, Ports, Uplink und Stromversorgung prüfen | | | +-- gleiches VLAN | | -> VLAN, Gateway, DHCP, ACL und Routing prüfen | | | +-- gleicher Access Point oder gleiche SSID | | -> AP, Controller, Authentifizierung und VLAN-Zuweisung prüfen | | | +-- gleicher Standort | -> Core, Firewall, Router, WAN und zentrale Dienste prüfen | +-- Besteht bei den Clients ein physischer Link oder eine WLAN-Verbindung? | | | +-- Nein -> gemeinsame Netzwerkkomponente, Uplink oder Stromversorgung | | untersuchen | | | +-- Ja | +-- Erhalten die Clients gültige IP-Adressen? | | | +-- Nein oder 169.254.x.x | | -> DHCP, Relay, VLAN, Trunk oder DHCP-Bereich prüfen | | | +-- Ja | +-- Ist das lokale Standardgateway erreichbar? | | | +-- Nein -> VLAN, Switch-Uplink, Gateway, ARP, STP oder Firewall prüfen | | | +-- Ja | +-- Ist eine externe IP-Adresse erreichbar? | | | +-- Nein -> Routing, Firewall, NAT, WAN oder Provider prüfen | | | +-- Ja | +-- Funktioniert die Namensauflösung? | | | +-- Nein -> DNS-Server, DNS-Erreichbarkeit und DNS-Dienst prüfen | | | +-- Ja | +-- Ist nur ein bestimmter Dienst nicht erreichbar? | +-- Ja -> Zielsystem, Port, Firewall, Proxy oder Anwendung prüfen | +-- Nein -> genaue Gemeinsamkeit der betroffenen Verbindungen ermitteln ``` --- **3. Störungsumfang mit Vergleichstests eingrenzen** Geeignete Vergleichsclients auswählen: - funktionierender Client am selben Switch, - funktionierender Client in einem anderen VLAN, - funktionierender Client an einem anderen Access Point, - funktionierender Client in einem anderen Stockwerk, - funktionierender Client an einem anderen Standort, - kabelgebundener Client als Vergleich zu WLAN, - WLAN-Client als Vergleich zu Ethernet. Auf jedem Vergleichsclient möglichst dieselben Prüfungen durchführen: ```cmd ipconfig /all ``` ```cmd ping ``` ```cmd ping ``` ```cmd nslookup ``` ```powershell Test-NetConnection -ComputerName -Port ``` **Bewertung** | Ergebnis | Eingrenzung | |---|---| | alle Clients an einem Switch betroffen | Switch oder Uplink priorisieren | | mehrere Switches im selben VLAN betroffen | VLAN, Gateway oder zentrale Dienste priorisieren | | nur ein VLAN betroffen | VLAN-spezifische Konfiguration prüfen | | alle VLANs betroffen | Core, Firewall, Router oder gemeinsame Uplinks prüfen | | nur WLAN betroffen | WLAN-Infrastruktur priorisieren | | Ethernet und WLAN betroffen | gemeinsame Dienste oder zentrale Infrastruktur prüfen | | externe IP funktioniert, Namen nicht | DNS priorisieren | | Gateway erreichbar, externe Ziele nicht | Routing, Firewall, NAT oder WAN priorisieren | | nur ein Ziel nicht erreichbar | Zielsystem oder Zielpfad priorisieren | Die Tests müssen unter möglichst gleichen Bedingungen erfolgen. Unterschiedliche VLANs, Berechtigungen oder Netzwerkwege können sonst zu falschen Schlussfolgerungen führen. --- **4. Besteht noch eine Verbindung zum Netzwerk?** Auf mehreren betroffenen Clients den Adapterstatus prüfen: ```powershell Get-NetAdapter ``` Vollständige IP-Konfiguration anzeigen: ```cmd ipconfig /all ``` **Entscheidung** - mehrere Ethernetclients zeigen `Disconnected` → gemeinsamen Switch, Uplink oder Stromausfall prüfen. - mehrere WLAN-Clients sind getrennt → Access Point, Controller, SSID oder Authentifizierung prüfen. - Link besteht, aber keine gültige IP-Adresse → DHCP- oder VLAN-Pfad prüfen. - Link und IP-Konfiguration bestehen → Gateway und Routing prüfen. - nur einzelne Ports sind ohne Link → Portgruppe, Patchfeld oder Modul untersuchen. - alle Ports eines Switches sind ohne Link → Switchstatus und Stromversorgung prüfen. Ein vorhandener Link beweist nur die physische Verbindung zwischen Client und nächster Netzwerkkomponente. --- **5. Switch und Uplink prüfen** Bei einem räumlich begrenzten Ausfall prüfen: - ist der Switch eingeschaltet, - sind ungewöhnlich viele Ports ohne Link, - funktioniert die Stromversorgung, - meldet die unterbrechungsfreie Stromversorgung einen Fehler, - ist der Uplink aktiv, - ist ein redundanter Uplink blockiert oder ausgefallen, - bestehen ungewöhnlich viele Port-Flaps, - wurde ein Port durch eine Schutzfunktion deaktiviert, - bestehen Fehler an einem Interface, - wurde die VLAN- oder Trunk-Konfiguration geändert, - gibt es Hinweise auf eine Netzwerkschleife, - läuft Spanning Tree stabil, - ist die CPU- oder Speicherauslastung auffällig, - ist die MAC-Adresstabelle plausibel? Die genauen Befehle hängen vom Hersteller und Betriebssystem des Switches ab. Typische Informationen sind: - Portstatus, - Uplinkstatus, - Interfacefehler, - verworfene Frames, - VLAN-Zuordnung, - Trunk-VLANs, - MAC-Adresstabelle, - Spanning-Tree-Zustand, - Port-Security- oder Errdisable-Ereignisse, - Systemprotokoll, - letzte Konfigurationsänderung. **Entscheidungsbaum** ```text Sind die betroffenen Clients an demselben Switch angeschlossen? | +-- Nein | -> gemeinsame übergeordnete Komponente suchen | +-- Ja | +-- Ist der Switch erreichbar und betriebsbereit? | +-- Nein | -> Stromversorgung, Managementzugriff und Hardware prüfen | +-- Ja | +-- Ist der Uplink aktiv? | +-- Nein | -> Kabel, Transceiver, Gegenstelle und Portstatus prüfen | +-- Ja | +-- Werden die erforderlichen VLANs transportiert? | +-- Nein -> Trunk- und VLAN-Konfiguration prüfen | +-- Ja -> Gateway, DHCP und Routing prüfen ``` Ein Switch darf nicht als erste Maßnahme neu gestartet werden. Dadurch gehen möglicherweise Protokolle, Tabellen und der ursprüngliche Fehlerzustand verloren. --- **6. Prüfen, ob nur ein VLAN betroffen ist** Hinweise auf einen VLAN-Fehler: - alle betroffenen Clients befinden sich im selben IP-Subnetz, - andere VLANs am selben Switch funktionieren, - Clients erhalten Adressen aus einem falschen Subnetz, - Clients erhalten überhaupt keine DHCP-Adresse, - das Gateway dieses VLANs ist nicht erreichbar, - die Störung begann nach einer Switch- oder Firewalländerung, - ein neuer Switch oder Access Point wurde eingebunden, - kabelgebundene und drahtlose Clients desselben VLANs sind betroffen. Zu prüfen sind: - Access-VLAN der Clientports, - VLAN-Zuweisung der SSID, - erlaubte VLANs auf Trunks, - native beziehungsweise ungetaggte VLAN-Konfiguration, - VLAN-Existenz auf beteiligten Switches, - Spanning-Tree-Zustand des VLANs, - Gateway-Schnittstelle oder SVI, - DHCP-Bereich und DHCP-Relay, - VLAN-spezifische ACLs oder Firewallregeln, - Routing zwischen den VLANs. **Entscheidung** - nur Clients eines Ports im falschen VLAN → Access-Port-Konfiguration prüfen. - mehrere Ports eines Switches betroffen → Portprofil oder Switchkonfiguration prüfen. - VLAN funktioniert auf einem Switch, auf einem anderen nicht → Trunk und VLAN-Weiterleitung prüfen. - VLAN funktioniert nirgends → Gateway, SVI, DHCP und zentrale Konfiguration prüfen. - Clients erhalten Adressen eines anderen VLANs → Port-, Trunk-, SSID- oder DHCP-Konfiguration prüfen. --- **7. DHCP-Störung erkennen** Auf mehreren betroffenen Clients prüfen: ```cmd ipconfig /all ``` Typische Hinweise auf einen gemeinsamen DHCP-Fehler: - mehrere Clients besitzen Adressen aus `169.254.0.0/16`, - das Standardgateway fehlt, - DNS-Server fehlen, - Clients erhalten Adressen aus einem falschen Subnetz, - bestehende Clients funktionieren noch, neue Clients jedoch nicht, - Clients mit gültigem Lease funktionieren bis zur Lease-Erneuerung, - nur ein bestimmtes Subnetz erhält keine Adressen. **Schneller DHCP-Entscheidungsbaum** ```text Erhalten mehrere Clients keine gültige Adresse? | +-- Nein | -> Gateway, Routing, DNS oder Anwendung prüfen | +-- Ja | +-- Sind alle DHCP-Subnetze betroffen? | +-- Ja | -> DHCP-Dienst, Server, Failover und zentrale Erreichbarkeit prüfen | +-- Nein | +-- Nur ein DHCP-Bereich betroffen? | +-- Ja | -> Bereich, freie Leases, Optionen und Ausschlüsse prüfen | +-- Nein -> VLAN, Trunk und DHCP-Relay prüfen ``` Auf einem autorisierten Windows-DHCP-Server können unter anderem folgende Prüfungen verwendet werden: ```powershell Get-Service -Name DHCPServer ``` ```powershell Get-DhcpServerv4Scope ``` ```powershell Get-DhcpServerv4ScopeStatistics ``` ```powershell Get-DhcpServerv4Binding ``` ```powershell Get-DhcpServerv4Failover ``` Zu prüfen sind: - läuft der DHCP-Dienst, - ist der DHCP-Server autorisiert, - ist der betreffende Bereich aktiv, - sind noch freie Adressen vorhanden, - stimmen Subnetzmaske, Gateway und DNS-Optionen, - funktioniert ein konfiguriertes DHCP-Failover, - erreicht die Anfrage den DHCP-Server, - antwortet der Server, - funktioniert das DHCP-Relay, - wird UDP 67 oder 68 blockiert, - existiert ein nicht autorisierter DHCP-Server? Ein autorisierter Paketmitschnitt kann zeigen, an welcher Stelle der DORA-Ablauf endet: 1. DHCP Discover, 2. DHCP Offer, 3. DHCP Request, 4. DHCP Acknowledge. --- **8. Bestehende und neue Clients vergleichen** Dieser Vergleich ist bei DHCP-Störungen besonders aussagekräftig. | Beobachtung | Mögliche Erklärung | |---|---| | bestehende Clients funktionieren, neue nicht | DHCP-Bereich ausgeschöpft oder DHCP-Dienst gestört | | Clients funktionieren bis zum Ablauf des Leases | Lease-Erneuerung oder DHCP-Erreichbarkeit gestört | | Clients mit statischer IP funktionieren | DHCP-Pfad priorisieren | | statische und dynamische Clients funktionieren nicht | Gateway, VLAN, Switch oder Routing priorisieren | | nur Clients eines Subnetzes betroffen | DHCP-Bereich, Relay oder VLAN prüfen | | Clients erhalten unterschiedliche falsche Adressen | fremden DHCP-Server oder falsche VLAN-Zuweisung prüfen | Eine frei gewählte statische IP-Adresse sollte nicht unkontrolliert vergeben werden. Sie kann einen Adresskonflikt verursachen und den ursprünglichen Fehler verdecken. --- **9. Standardgateway prüfen** Auf mehreren Clients das konfigurierte Gateway feststellen: ```cmd ipconfig ``` Gateway testen: ```cmd ping ``` Routingtabelle anzeigen: ```cmd route print ``` Alternativ: ```powershell Get-NetRoute ``` Nachbartabelle prüfen: ```powershell Get-NetNeighbor ``` **Entscheidung** - kein Client erreicht das Gateway → Gateway, VLAN, Switchpfad oder Firewall prüfen. - nur ein VLAN erreicht sein Gateway nicht → Gateway-Schnittstelle, SVI oder VLAN-Zuordnung prüfen. - Gateway erscheint nicht in der Nachbartabelle → Layer-2-Pfad und ARP untersuchen. - Gateway erscheint mit MAC-Adresse, antwortet aber nicht auf Ping → ICMP kann blockiert sein; weitere Dienste testen. - ein Vergleichs-VLAN erreicht sein Gateway → globale Gateway-Hardware ist nicht automatisch vollständig bestätigt; VLAN-spezifische Konfiguration prüfen. - mehrere Gateways sind gleichzeitig ausgefallen → redundante Gatewaylösung, Core-Switch oder zentrale Firewall prüfen. Ein fehlgeschlagener Ping allein beweist keinen Ausfall des Gateways. --- **10. Routing, Firewall und Internetübergang prüfen** Wenn das Gateway erreichbar ist, eine freigegebene externe IP-Adresse testen: ```cmd ping ``` Pfad anzeigen: ```cmd tracert ``` PowerShell-Test: ```powershell Test-NetConnection -ComputerName -InformationLevel Detailed ``` **Entscheidungsbaum** ```text Ist das lokale Gateway erreichbar? | +-- Nein | -> lokales VLAN, Switching und Gateway prüfen | +-- Ja | +-- Ist eine externe IP-Adresse erreichbar? | +-- Ja | -> DNS und Zielanwendung prüfen | +-- Nein | +-- Sind interne geroutete Netze erreichbar? | +-- Ja | -> Firewall, NAT, WAN oder Provider prüfen | +-- Nein -> internes Routing, Core oder Firewall prüfen ``` Zu prüfen sind: - Standardroute, - dynamische oder statische Routen, - Firewallzustand, - NAT-Regeln, - WAN-Schnittstelle, - Providerverbindung, - VPN- oder Standorttunnel, - Hochverfügbarkeitsstatus, - Routingnachbarschaften, - kürzlich geänderte ACLs oder Firewallregeln. --- **11. DNS als gemeinsame Ursache erkennen** Wenn IP-Adressen erreichbar sind, Namen jedoch auf mehreren Clients nicht funktionieren: ```cmd nslookup ``` ```powershell Resolve-DnsName ``` Konfigurierte DNS-Server anzeigen: ```powershell Get-DnsClientServerAddress ``` DNS-Port prüfen: ```powershell Test-NetConnection -ComputerName -Port 53 ``` Ein erfolgreicher TCP-Test auf Port 53 ist kein vollständiger DNS-Funktionstest, da DNS abhängig von Anfrage und Umgebung UDP oder TCP verwenden kann. **Entscheidung** - alle Clients verwenden denselben nicht erreichbaren DNS-Server → DNS-Server oder Netzwerkpfad prüfen. - nur ein VLAN erreicht den DNS-Server nicht → Routing, ACL oder Firewall prüfen. - DNS-Server antwortet, löst aber interne Namen nicht auf → Zone, Einträge oder Replikation prüfen. - interne Namen funktionieren, externe nicht → Weiterleitung oder externe DNS-Erreichbarkeit prüfen. - externe Namen funktionieren, interne nicht → interne DNS-Zone, Suchsuffix oder verwendeten DNS-Server prüfen. - Clients verwenden falsche DNS-Server → DHCP-Optionen oder statische Konfiguration prüfen. DNS-Caches sollten nicht gleichzeitig auf allen Clients gelöscht werden. Zuerst muss geprüft werden, ob tatsächlich ein veralteter Cache-Eintrag vorliegt. --- **12. WLAN-Ausfall mehrerer Clients** Sind mehrere WLAN-Clients betroffen, zunächst unterscheiden: ```text Sind alle WLAN-Clients betroffen? | +-- Nein | | | +-- nur ein Access Point | | -> AP, Uplink, Stromversorgung und Funkzelle prüfen | | | +-- nur eine SSID | -> SSID, Authentifizierung, RADIUS und VLAN prüfen | +-- Ja | +-- Ethernet funktioniert? | +-- Ja | -> WLAN-Controller, zentrale AP-Verwaltung, | RADIUS oder WLAN-Infrastruktur prüfen | +-- Nein -> gemeinsame Switching-, Routing- oder Dienstestörung prüfen ``` Zusätzlich prüfen: - sind die Access Points erreichbar, - erhalten sie Strom über PoE, - ist der PoE-Budget-Grenzwert des Switches erreicht, - besteht die Verbindung zum WLAN-Controller, - wird die SSID ausgestrahlt, - funktioniert RADIUS oder 802.1X, - sind Zertifikate gültig, - stimmt die Systemzeit, - werden Clients dem vorgesehenen VLAN zugeordnet, - funktioniert DHCP in diesem VLAN, - besteht eine ungewöhnlich hohe Funkbelastung, - trat der Fehler nach einer Konfigurationsänderung auf? Wenn Clients mit dem WLAN verbunden sind, aber keine IP-Adresse erhalten, liegt nicht automatisch ein Funkproblem vor. Dann sind insbesondere VLAN und DHCP zu prüfen. --- **13. Redundanz- und Hochverfügbarkeitsfehler berücksichtigen** Eine vorhandene Redundanz garantiert nicht, dass die Umschaltung funktioniert hat. Zu prüfen sind: - Status beider Firewalls oder Router, - aktive und passive Rolle, - Zustand des Synchronisationslinks, - gemeinsames virtuelles Gateway, - Status redundanter Switch-Uplinks, - Link Aggregation oder EtherChannel, - Spanning-Tree-Zustand, - DHCP-Failover, - DNS-Redundanz, - redundante WAN-Verbindungen, - Standort-VPN-Tunnel, - Zeitpunkt eines Failovers. Mögliche Fehlerbilder: - beide Systeme glauben, aktiv zu sein, - kein System übernimmt die aktive Rolle, - Zustände wurden nicht synchronisiert, - virtuelle IP-Adresse ist nicht erreichbar, - ein Teil der VLANs wurde nicht übernommen, - Routing oder NAT fehlt nach der Umschaltung, - ein redundanter Link ist physisch aktiv, transportiert aber nicht alle VLANs. --- **14. Änderungen und Zeitpunkte korrelieren** Vor Maßnahmen prüfen: - wann begann die Störung, - wurden Switch-, Firewall- oder Routerregeln geändert, - wurde ein VLAN hinzugefügt oder entfernt, - gab es ein Firmware- oder Betriebssystemupdate, - wurde ein Access Point oder Switch ausgetauscht, - wurde die Patchung verändert, - gab es einen Stromausfall, - wurde ein Zertifikat erneuert, - wurde eine DHCP- oder DNS-Konfiguration geändert, - fand ein Failover statt, - meldet der Provider eine Störung? Die zeitliche Nähe einer Änderung ist ein Hinweis, aber noch kein Beweis. Die vermutete Ursache muss durch passende Messwerte, Protokolle oder einen kontrollierten Rückbau bestätigt werden. --- **15. Beispiel für eine schnelle Diagnose** **Symptom** Alle Clients eines Stockwerks melden seit 10:15 Uhr keine Netzwerkverbindung. Andere Stockwerke funktionieren. **Erste Eingrenzung** - Ethernet und WLAN des Stockwerks sind betroffen. - Alle betroffenen Access Points und Netzwerkdosen führen über denselben Etagen-Switch. - Clients anderer Etagen erreichen interne Systeme und das Internet. **Clientprüfung** ```cmd ipconfig /all ``` Ergebnis auf mehreren Clients: ```text IPv4-Adresse: 169.254.x.x Standardgateway: DHCP aktiviert: Ja ``` **Bewertung** - die Störung betrifft nicht nur einen Client, - mehrere Clients erhalten keine DHCP-Konfiguration, - Ethernet und WLAN besitzen dieselbe gemeinsame Infrastruktur, - der Etagen-Switch oder dessen Uplink ist zu priorisieren. **Infrastrukturprüfung** - Etagen-Switch ist eingeschaltet, - Clientports besitzen Link, - Uplink-Port ist jedoch ohne Verbindung, - Gegenstelle zeigt ebenfalls keinen Link. **Festgestellte Ursache** Ein defekter Transceiver hat den Uplink des Etagen-Switches unterbrochen. **Kontrollierte Maßnahme** Der defekte Transceiver wurde nach Freigabe durch ein geprüftes Ersatzgerät ersetzt. **Nachprüfung** - Uplink ist stabil aktiv, - erforderliche VLANs werden transportiert, - Clients erhalten gültige DHCP-Adressen, - Gateways sind erreichbar, - interne Systeme sind erreichbar, - externe IP-Verbindung funktioniert, - DNS-Auflösung funktioniert, - Ethernet- und WLAN-Clients wurden getestet, - Schnittstellenfehler und Protokolle wurden erneut geprüft, - Ursache und Austausch wurden dokumentiert. --- **16. Ungeeignete Sofortmaßnahmen** Nicht als erste Maßnahme verwenden: - alle betroffenen Clients neu starten, - Switch oder Router ohne Diagnose neu starten, - Firewall ungeprüft deaktivieren, - VLAN-Zuordnungen versuchsweise ändern, - Switchports wahllos deaktivieren und aktivieren, - DHCP-Leases auf allen Clients freigeben, - allen Clients statische Adressen geben, - öffentliche DNS-Server eintragen, - Spanning Tree deaktivieren, - redundante Links ungeprüft umstecken, - Firewallregeln vollständig zurücksetzen, - mehrere Infrastrukturänderungen gleichzeitig durchführen, - funktionierende Konfigurationen überschreiben, - Werkseinstellungen laden. Solche Maßnahmen können den Fehler vergrößern, Diagnoseinformationen vernichten oder weitere Netzwerkbereiche beeinträchtigen. --- **17. Vollständige Schnellprüfreihenfolge** 1. genaue Fehlermeldung und Beginn erfassen. 2. Anzahl und Standort der betroffenen Clients bestimmen. 3. funktionierende Vergleichsclients suchen. 4. gemeinsame Switches, VLANs, Access Points oder Dienste ermitteln. 5. Ethernet und WLAN getrennt vergleichen. 6. Adapter- und Linkstatus mehrerer Clients prüfen. 7. IP-Konfiguration mehrerer Clients vergleichen. 8. auf `169.254.x.x`, falsche Subnetze oder fehlende Gateways achten. 9. DHCP-Dienst, Bereich und Relay prüfen. 10. Gateway jedes betroffenen VLANs testen. 11. lokales Vergleichsziel testen. 12. externe IP-Adresse testen. 13. DNS-Auflösung getrennt prüfen. 14. benötigten Zielport prüfen. 15. Switchstatus und Uplinks untersuchen. 16. VLAN- und Trunk-Konfiguration prüfen. 17. Spanning Tree und Portschutz berücksichtigen. 18. Firewall, NAT und Routing prüfen. 19. WAN- und Standortverbindungen prüfen. 20. Redundanz- und Failoverstatus prüfen. 21. Ereignisse mit dem Fehlerbeginn korrelieren. 22. letzte Änderungen ermitteln. 23. eine gemeinsame Ursache als Hypothese formulieren. 24. genau eine kontrollierte Maßnahme durchführen. 25. dieselben Tests nach der Änderung wiederholen. 26. alle zuvor betroffenen Bereiche testen. 27. Überwachung und Protokolle kontrollieren. 28. temporäre Diagnoseänderungen entfernen. 29. Ursache, Maßnahme und Nachweis dokumentieren. --- **18. Checkliste „Mehrere Clients haben kein Netzwerk“** - [ ] Beginn und genaue Auswirkung der Störung sind dokumentiert. - [ ] die betroffenen Clients und Standorte sind bekannt. - [ ] funktionierende Vergleichsclients wurden geprüft. - [ ] gemeinsame Switches, VLANs oder Access Points wurden ermittelt. - [ ] Ethernet und WLAN wurden getrennt betrachtet. - [ ] interne und externe Ziele wurden unterschieden. - [ ] Linkstatus mehrerer Clients wurde geprüft. - [ ] IP-Konfigurationen wurden miteinander verglichen. - [ ] DHCP-Ausfall oder falscher DHCP-Bereich wurde berücksichtigt. - [ ] freie DHCP-Leases wurden geprüft. - [ ] DHCP-Relay wurde bei Bedarf geprüft. - [ ] Standardgateways wurden getestet. - [ ] lokale Vergleichsziele wurden getestet. - [ ] externe IP-Ziele wurden getestet. - [ ] DNS wurde getrennt von der IP-Erreichbarkeit geprüft. - [ ] betroffene Zielports wurden geprüft. - [ ] Switchstatus und Stromversorgung wurden kontrolliert. - [ ] Switch-Uplinks wurden geprüft. - [ ] Interfacefehler und Port-Flaps wurden berücksichtigt. - [ ] VLAN- und Trunk-Konfigurationen wurden geprüft. - [ ] Spanning-Tree-Zustand wurde berücksichtigt. - [ ] Port-Security oder Errdisable wurde geprüft. - [ ] Firewallregeln und ACLs wurden berücksichtigt. - [ ] Routing und Standardroute wurden geprüft. - [ ] NAT und Internetübergang wurden geprüft. - [ ] WAN- oder Standortverbindungen wurden geprüft. - [ ] WLAN-Controller, RADIUS und PoE wurden bei Bedarf geprüft. - [ ] Hochverfügbarkeits- und Failoverstatus wurde kontrolliert. - [ ] letzte Änderungen wurden mit dem Fehlerbeginn verglichen. - [ ] vor Eingriffen wurden Protokolle und Zustände gesichert. - [ ] nur eine kontrollierte Änderung wurde durchgeführt. - [ ] dieselben Tests wurden anschließend wiederholt. - [ ] alle betroffenen Clientgruppen funktionieren wieder. - [ ] die Infrastrukturüberwachung zeigt einen stabilen Zustand. - [ ] Ursache, Maßnahme und Nachweis wurden dokumentiert. --- **19. Schnellreferenz** | Ergebnis | Nächster Schritt | |---|---| | nur ein Client betroffen | Entscheidungsbaum 7.1 verwenden | | alle Clients eines Switches betroffen | Switch, Stromversorgung und Uplink prüfen | | nur ein VLAN betroffen | VLAN, Gateway, DHCP, ACL und Trunk prüfen | | nur ein Access Point betroffen | AP, PoE, Uplink und Funkzelle prüfen | | nur eine SSID betroffen | SSID, RADIUS, Zertifikate und VLAN-Zuweisung prüfen | | alle WLAN-Clients betroffen | Controller, RADIUS oder zentrale WLAN-Infrastruktur prüfen | | Ethernet und WLAN betroffen | gemeinsame Switching-, Routing- oder Dienstekomponente prüfen | | mehrere Clients mit `169.254.x.x` | DHCP-Pfad prüfen | | bestehende Clients funktionieren, neue nicht | DHCP-Bereich oder DHCP-Dienst prüfen | | falsches Subnetz wird vergeben | VLAN, DHCP-Relay oder fremden DHCP-Server prüfen | | Gateway eines VLANs nicht erreichbar | SVI, VLAN, Trunk oder Firewall prüfen | | Gateway erreichbar, externe IP nicht | Routing, NAT, Firewall oder WAN prüfen | | externe IP erreichbar, Name nicht | DNS prüfen | | nur ein Dienst betroffen | Zielsystem, Port, Firewall oder Proxy prüfen | | gesamter Standort betroffen | Core, Firewall, Router, WAN oder Stromversorgung prüfen | | Ausfall nach Änderung | Änderung mit Protokollen und Vergleichstest überprüfen | | Fehler nach Neustart verschwunden | Ursache nicht bewiesen; Protokolle weiter auswerten | --- **Merksatz** > Je mehr Clients gleichzeitig betroffen sind, desto wichtiger ist ihre gemeinsame Abhängigkeit. Suche zuerst nach dem gemeinsamen Switch, VLAN, Access Point, Gateway oder zentralen Dienst – nicht nach identischen Einzeldefekten an allen Endgeräten. --- **Quellen und weiterführende Dokumentation** - [Microsoft Learn – DHCP troubleshooting guidance](https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/troubleshoot-dhcp-guidance) - [Microsoft Learn – Troubleshoot problems on the DHCP server](https://learn.microsoft.com/en-us/windows-server/troubleshoot/troubleshoot-problems-on-dhcp-server) - [Microsoft Learn – Troubleshoot problems on the DHCP client](https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/troubleshoot-problems-dhcp-client) - [Microsoft Learn – Get-DhcpServerv4Scope](https://learn.microsoft.com/en-us/powershell/module/dhcpserver/get-dhcpserverv4scope) - [Microsoft Learn – Get-DhcpServerv4ScopeStatistics](https://learn.microsoft.com/en-us/powershell/module/dhcpserver/get-dhcpserverv4scopestatistics) - [Microsoft Learn – Get-DhcpServerv4Binding](https://learn.microsoft.com/en-us/powershell/module/dhcpserver/get-dhcpserverv4binding) - [Microsoft Learn – Get-DhcpServerv4Failover](https://learn.microsoft.com/en-us/powershell/module/dhcpserver/get-dhcpserverv4failover) - [Microsoft Learn – ipconfig](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/ipconfig) - [Microsoft Learn – ping](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/ping) - [Microsoft Learn – tracert](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/tracert) - [Microsoft Learn – Get-NetAdapter](https://learn.microsoft.com/en-us/powershell/module/netadapter/get-netadapter) - [Microsoft Learn – Get-NetRoute](https://learn.microsoft.com/en-us/powershell/module/nettcpip/get-netroute) - [Microsoft Learn – Get-NetNeighbor](https://learn.microsoft.com/en-us/powershell/module/nettcpip/get-netneighbor) - [Microsoft Learn – Test-NetConnection](https://learn.microsoft.com/en-us/powershell/module/nettcpip/test-netconnection) - [Microsoft Learn – Resolve-DnsName](https://learn.microsoft.com/en-us/powershell/module/dnsclient/resolve-dnsname) - [Cisco – Troubleshoot STP problems and related design considerations](https://www.cisco.com/c/en/us/support/docs/lan-switching/spanning-tree-protocol/10556-16.html) - [Cisco – Spanning Tree Protocol documentation](https://www.cisco.com/c/en/us/tech/lan-switching/spanning-tree-protocol/index.html) # 7.3 „Name geht nicht, IP geht“ Ist ein Ziel über seine IP-Adresse erreichbar, aber nicht über seinen Namen, liegt der Fehler wahrscheinlich im Bereich der Namensauflösung. Beispiel: ```cmd ping 192.0.2.25 ``` funktioniert, aber: ```cmd ping server01.example.local ``` scheitert. Damit ist jedoch noch nicht automatisch bewiesen, dass ausschließlich der DNS-Server fehlerhaft ist. Auch folgende Ursachen sind möglich: - falscher DNS-Server am Client, - falscher oder unvollständiger Zielname, - fehlendes DNS-Suffix, - falscher DNS-Eintrag, - veralteter positiver oder negativer Cacheeintrag, - unterschiedliche Antworten mehrerer DNS-Server, - fehlende Zonenreplikation, - fehlerhafter Forwarder oder Conditional Forwarder, - defekte Delegation, - blockiertes UDP oder TCP auf Port 53, - falsche `hosts`-Datei, - VPN- oder NRPT-Regel, - Split-DNS, - DNS over HTTPS, - nur fehlerhafter A- oder AAAA-Eintrag. Dieser Entscheidungsbaum dient der schnellen Eingrenzung. Die ausführliche DNS-Analyse befindet sich im Netzwerk- und Verbindungsfehler-Kapitel. --- **1. Zuerst die Ausgangslage bestätigen** Zunächst prüfen, ob die Verbindung zur Ziel-IP tatsächlich funktioniert. ```powershell Test-NetConnection -ComputerName -InformationLevel Detailed ``` Für einen konkreten Dienst: ```powershell Test-NetConnection -ComputerName -Port ``` Danach denselben Test mit dem Namen durchführen: ```powershell Test-NetConnection -ComputerName -Port ``` **Bewertung** | Ergebnis | Bedeutung | |---|---| | IP und Name funktionieren | DNS-Fehler aktuell nicht reproduzierbar | | IP funktioniert, Name wird nicht aufgelöst | DNS-Pfad untersuchen | | Name wird aufgelöst, aber Verbindung scheitert | Dienst, Port, Firewall, Routing oder falsche Zieladresse prüfen | | IP und Name scheitern | nicht nur DNS untersuchen; Netzwerkpfad oder Zielsystem prüfen | | Kurzname scheitert, FQDN funktioniert | DNS-Suffix oder Suchliste prüfen | | FQDN scheitert ebenfalls | DNS-Server, Zone, Eintrag oder Weiterleitung prüfen | | Name liefert falsche IP-Adresse | Record, Cache, Replikation oder Split-DNS prüfen | | nur einzelne Anwendungen scheitern | Anwendungscache, Proxy, DoH oder anwendungseigene Namensauflösung prüfen | Ein erfolgreicher Ping auf die IP-Adresse bestätigt nicht, dass der benötigte Dienst erreichbar ist. Deshalb sollte nach Möglichkeit derselbe Zielport einmal über die IP-Adresse und einmal über den Namen getestet werden. --- **2. Schneller Hauptentscheidungsbaum** ```text START: Name geht nicht, IP geht | +-- Ist die Ziel-IP über den benötigten Port erreichbar? | | | +-- Nein -> Dienst, Firewall, Routing oder Zielsystem prüfen | | | +-- Ja | +-- Wurde der richtige Zielname verwendet? | | | +-- Unklar -> Schreibweise, Domäne und erwarteten FQDN prüfen | | | +-- Ja | +-- Funktioniert der vollständige FQDN? | | | +-- Ja, aber Kurzname nicht | | -> DNS-Suffix und Suchliste prüfen | | | +-- Nein | +-- Sind die vorgesehenen DNS-Server eingetragen und erreichbar? | | | +-- Nein -> DHCP, Adapter, VPN, Routing oder Firewall prüfen | | | +-- Ja | +-- Antworten alle eingetragenen DNS-Server gleich? | | | +-- Nein -> Zone, Record, Replikation oder Serverzustand prüfen | | | +-- Ja | +-- Liefert die Abfrage einen passenden A- oder AAAA-Eintrag? | | | +-- Nein -> Zone, Record, Forwarder oder Delegation prüfen | | | +-- Ja | +-- Ist die zurückgegebene IP-Adresse korrekt und erreichbar? | | | +-- Nein -> falschen oder veralteten Record beziehungsweise Cache prüfen | | | +-- Ja | +-- Funktioniert die Anwendung trotzdem nicht? | +-- Ja -> Anwendungscache, Proxy, TLS, VPN, NRPT, | DoH oder Hosts-Datei prüfen | +-- Nein -> DNS-Auflösung funktioniert ``` --- **3. Den verwendeten Namen genau dokumentieren** Vor weiteren Tests erfassen: - eingegebener Zielname, - erwarteter vollständiger DNS-Name, - Groß- und Kleinschreibung bei nachgelagerten Anwendungen, - verwendete Anwendung, - genaue Fehlermeldung, - Zeitpunkt der Abfrage, - erwartete IP-Adresse, - tatsächlich gelieferte IP-Adresse, - interne oder externe Domäne, - Verbindung mit oder ohne VPN. Beispiele: ```text server01 server01.example.local portal.example.com files.example.local ``` Ein Kurzname wie `server01` ist nicht dasselbe wie der vollständige Name: ```text server01.example.local ``` Der Kurzname kann nur funktionieren, wenn der Client ihn mithilfe eines DNS-Suffixes zu einem vollständigen Namen ergänzt oder ein anderes vorgesehenes Namensauflösungsverfahren verwendet. --- **4. DNS-Konfiguration des Clients prüfen** Vollständige Netzwerkkonfiguration anzeigen: ```cmd ipconfig /all ``` Gezielt die konfigurierten DNS-Server anzeigen: ```powershell Get-DnsClientServerAddress ``` Nur IPv4-DNS-Server: ```powershell Get-DnsClientServerAddress -AddressFamily IPv4 ``` DNS-Clientkonfiguration der Adapter anzeigen: ```powershell Get-DnsClient ``` Globale DNS-Einstellungen und Suffixsuchliste anzeigen: ```powershell Get-DnsClientGlobalSetting ``` Zu prüfen sind: - welcher Adapter aktiv verwendet wird, - welche DNS-Server am aktiven Adapter eingetragen sind, - ob die DNS-Server per DHCP oder statisch gesetzt wurden, - ob ein VPN-Adapter eigene DNS-Server einträgt, - ob virtuelle Adapter beteiligt sind, - ob öffentliche DNS-Server an einem Domänenclient eingetragen sind, - ob IPv4 und IPv6 unterschiedliche DNS-Server verwenden, - ob ein verbindungsspezifisches DNS-Suffix vorhanden ist, - ob die DNS-Suffixsuchliste korrekt ist. **Typische Fehlerbilder** | Beobachtung | Mögliche Ursache | |---|---| | DNS-Serverfeld ist leer | fehlerhafte DHCP-Option oder statische Konfiguration | | falscher interner DNS-Server | DHCP-, Adapter- oder VPN-Konfiguration | | öffentlicher DNS-Server am Domänenclient | interne Namen können nicht aufgelöst werden | | alter DNS-Server eingetragen | veraltete statische Konfiguration | | VPN-DNS nur bei bestehender Verbindung erreichbar | VPN-Verbindung oder Routing fehlt | | mehrere Adapter besitzen unterschiedliche DNS-Server | falscher Adapter oder unerwarteter DNS-Pfad | | IPv6-DNS verweist auf einen anderen Server | unterschiedliche Antwortwege möglich | | nur ein Client betroffen | lokale Konfiguration, Cache, `hosts`, VPN oder Richtlinie prüfen | | mehrere Clients betroffen | DHCP-Option, DNS-Dienst, Zone, Replikation oder Netzwerkpfad prüfen | Die DNS-Server eines Unternehmensclients dürfen nicht versuchsweise durch öffentliche DNS-Server ersetzt werden. Dadurch können interne Namen, Active Directory und unternehmensinterne Dienste zusätzlich gestört werden. --- **5. DNS-Server auf Erreichbarkeit prüfen** Zuerst die IP-Erreichbarkeit des vorgesehenen DNS-Servers prüfen: ```cmd ping ``` Ein fehlgeschlagener Ping beweist keinen Ausfall, da ICMP blockiert sein kann. TCP-Port 53 prüfen: ```powershell Test-NetConnection -ComputerName -Port 53 ``` **Wichtig** Dieser Befehl testet nur TCP-Port 53. Klassische DNS-Abfragen verwenden häufig zunächst UDP-Port 53. Größere Antworten, Zonentransfers und bestimmte weitere Fälle können TCP verwenden. Ein erfolgreicher TCP-Test bestätigt deshalb nicht vollständig: - dass UDP 53 funktioniert, - dass der DNS-Dienst korrekte Antworten liefert, - dass die richtige Zone vorhanden ist, - dass der gewünschte Record existiert. Die eigentliche DNS-Funktion muss mit einer DNS-Abfrage geprüft werden. --- **6. Den Namen gezielt abfragen** Standardabfrage mit dem aktuell verwendeten DNS-Pfad: ```powershell Resolve-DnsName ``` Beispiel: ```powershell Resolve-DnsName server01.example.local ``` Gezielt einen bestimmten DNS-Server abfragen: ```powershell Resolve-DnsName -Server ``` Alternativ: ```cmd nslookup ``` Bestimmten DNS-Server abfragen: ```cmd nslookup ``` **Zu dokumentieren sind:** - abgefragter Name, - verwendeter DNS-Server, - Rückgabecode, - zurückgegebene IP-Adresse, - Record-Typ, - autoritative oder nicht autoritative Antwort, - TTL, - Unterschiede zwischen mehreren DNS-Servern. `nslookup` und `Resolve-DnsName` sind wichtige Diagnosetests. Sie bilden jedoch nicht in jedem Fall exakt denselben Auflösungsweg ab, den eine konkrete Anwendung verwendet. Anwendungen können beispielsweise eigene Caches, Browser-DoH, Proxyauflösung oder andere Bibliotheken benutzen. --- **7. Jeden konfigurierten DNS-Server einzeln testen** Sind mehrere DNS-Server eingetragen, muss jeder einzeln abgefragt werden. Beispiel: ```powershell Resolve-DnsName server01.example.local -Server 192.0.2.10 ``` ```powershell Resolve-DnsName server01.example.local -Server 192.0.2.11 ``` **Bewertung** | DNS-Server 1 | DNS-Server 2 | Mögliche Ursache | |---|---|---| | richtige Antwort | richtige Antwort | Serverantworten sind konsistent | | richtige Antwort | keine Antwort | zweiter Server, Dienst oder Netzwerkpfad gestört | | richtige Antwort | falsche IP | Replikations-, Zonen- oder Recordproblem | | Record vorhanden | `NXDOMAIN` | Zone oder Record fehlt auf einem Server | | beide keine Antwort | gemeinsame Erreichbarkeit, Firewall oder Dienst prüfen | | beide `NXDOMAIN` | Name, Zone, Delegation oder Forwarder prüfen | | unterschiedliche TTL | kann durch unterschiedliche Cachezustände entstehen | | unterschiedliche Record-Sätze | Replikation, Split-DNS oder Lastverteilung prüfen | Wenn nur einer von mehreren DNS-Servern fehlerhaft antwortet, kann das Problem scheinbar zufällig auftreten. Abhängig vom verwendeten Server funktioniert die Namensauflösung dann zeitweise oder nur auf bestimmten Clients. --- **8. FQDN und Kurzname vergleichen** Vollständigen Namen testen: ```powershell Resolve-DnsName server01.example.local ``` Kurznamen testen: ```powershell Resolve-DnsName server01 ``` **Entscheidung** ```text Funktioniert der FQDN? | +-- Nein | -> DNS-Server, Zone, Record, Weiterleitung oder Delegation prüfen | +-- Ja | +-- Funktioniert auch der Kurzname? | +-- Ja -> Suffixauflösung funktioniert | +-- Nein -> DNS-Suffix und Suchliste prüfen ``` DNS-Clientinformationen anzeigen: ```powershell Get-DnsClient ``` Globale Suffixsuchliste anzeigen: ```powershell Get-DnsClientGlobalSetting ``` In `ipconfig /all` insbesondere prüfen: ```text Primäres DNS-Suffix Verbindungsspezifisches DNS-Suffix DNS-Suffixsuchliste ``` **Mögliche Ursachen bei „FQDN geht, Kurzname geht nicht“** - kein DNS-Suffix vorhanden, - falsches verbindungsspezifisches Suffix, - falsche globale Suchliste, - VPN ändert die Suffixsuchliste, - DHCP-Option liefert ein falsches Suffix, - Gruppenrichtlinie setzt eine falsche Suchliste, - Anwendung ergänzt keinen DNS-Suffix, - Kurzname ist mehrdeutig. Für Diagnose und Dokumentation ist der FQDN grundsätzlich aussagekräftiger als ein Kurzname. --- **9. A- und AAAA-Einträge getrennt prüfen** IPv4-Eintrag abfragen: ```powershell Resolve-DnsName -Type A ``` IPv6-Eintrag abfragen: ```powershell Resolve-DnsName -Type AAAA ``` Mit `nslookup`: ```cmd nslookup -type=A ``` ```cmd nslookup -type=AAAA ``` **Bewertung** | Ergebnis | Mögliche Ursache | |---|---| | richtiger A-Eintrag, kein AAAA-Eintrag | nur IPv4 vorgesehen; nicht automatisch ein Fehler | | richtiger AAAA-Eintrag, kein A-Eintrag | nur IPv6 vorgesehen; Umgebung prüfen | | A-Eintrag zeigt auf alte IP | veralteter Record oder Cache | | AAAA-Eintrag zeigt auf nicht erreichbares Ziel | veralteter IPv6-Record oder fehlerhafter IPv6-Pfad | | mehrere A- oder AAAA-Einträge | Lastverteilung oder mehrere Zielsysteme möglich | | nur eine der gelieferten Adressen funktioniert | einzelnen Record und Zielpfad prüfen | | CNAME verweist auf nicht auflösbaren Namen | Ziel des CNAME prüfen | | `NXDOMAIN` | Name oder Zone existiert laut befragtem Server nicht | | `SERVFAIL` | Server konnte die Anfrage nicht korrekt verarbeiten | Wenn ein Name mehrere Adressen liefert, müssen alle zurückgegebenen Ziele berücksichtigt werden. Ein einzelner funktionierender Record beweist nicht, dass jeder mögliche Verbindungsversuch erfolgreich ist. --- **10. Zurückgegebene IP-Adresse überprüfen** Nach erfolgreicher Auflösung prüfen, ob die Antwort dem erwarteten Ziel entspricht. ```powershell Resolve-DnsName ``` Danach den benötigten Port an der gelieferten Adresse testen: ```powershell Test-NetConnection -ComputerName -Port ``` Zu klären sind: - gehört die IP-Adresse zum vorgesehenen Server, - ist die Adresse noch aktuell, - existieren mehrere A- oder AAAA-Einträge, - verweist ein CNAME auf das richtige Ziel, - stammt die Antwort aus einer internen oder externen Zone, - liefert das VPN eine andere Antwort, - verwendet der Client möglicherweise einen alten Cacheeintrag? **Wichtig** „Der Name wird aufgelöst“ bedeutet nur, dass eine DNS-Antwort vorliegt. Die Antwort kann trotzdem falsch, veraltet oder für den aktuellen Netzwerkstandort ungeeignet sein. --- **11. DNS-Clientcache untersuchen** Cacheeinträge anzeigen: ```cmd ipconfig /displaydns ``` Alternativ: ```powershell Get-DnsClientCache ``` Gezielt nach einem Namen suchen: ```powershell Get-DnsClientCache | Where-Object Entry -Like "**" ``` Zu prüfen sind: - gespeicherter Name, - Record-Typ, - gespeicherte Adresse, - verbleibende TTL, - negativer Cacheeintrag, - Unterschied zur direkten Abfrage des DNS-Servers. **Vergleich** ```powershell Resolve-DnsName ``` und anschließend gezielt: ```powershell Resolve-DnsName -Server ``` Unterscheiden sich Cache und direkte Serverantwort, kann ein veralteter Cacheeintrag vorliegen. Cache erst nach der Dokumentation leeren: ```powershell Clear-DnsClientCache ``` Alternativ: ```cmd ipconfig /flushdns ``` Danach denselben Test erneut durchführen: ```powershell Resolve-DnsName ``` **Negativer Cache** Auch eine zuvor fehlgeschlagene Namensauflösung kann zwischengespeichert werden. Wurde der DNS-Eintrag erst danach angelegt, kann der Client bis zum Ablauf des negativen Cacheeintrags weiterhin melden, dass der Name nicht existiert. Das Leeren des Caches ist nur dann ein aussagekräftiger Test, wenn vorher und nachher dieselbe Abfrage dokumentiert wird. --- **12. `hosts`-Datei prüfen** Unter Windows befindet sich die Datei hier: ```text C:\Windows\System32\drivers\etc\hosts ``` Inhalt mit PowerShell anzeigen: ```powershell Get-Content "$env:SystemRoot\System32\drivers\etc\hosts" ``` Relevante aktive Zeilen anzeigen: ```powershell Get-Content "$env:SystemRoot\System32\drivers\etc\hosts" | Where-Object { $_ -notmatch '^\s*#' -and $_ -notmatch '^\s*$' } ``` Mögliche Fehler: - Name verweist auf eine alte IP-Adresse, - Tippfehler im Hostnamen, - Testeintrag wurde nicht entfernt, - Sicherheitssoftware hat einen Eintrag ergänzt, - Anwendung erreicht dadurch ein anderes Ziel, - ein lokaler Eintrag verdeckt die erwartete DNS-Antwort. Beispiel eines problematischen Eintrags: ```text 192.0.2.40 server01.example.local ``` Wenn der Server inzwischen die Adresse `192.0.2.50` verwendet, kann der Client trotz korrektem DNS-Eintrag weiterhin das alte Ziel verwenden. Ein Eintrag darf erst nach Sicherung und Freigabe kontrolliert geändert oder entfernt werden. Nicht jede Anwendung verwendet zwingend den identischen Windows-Auflösungsweg. --- **13. Zone und Resource Record auf dem DNS-Server prüfen** Auf einem autorisierten Windows-DNS-Server können die vorhandenen Zonen angezeigt werden: ```powershell Get-DnsServerZone ``` Bestimmte Zone prüfen: ```powershell Get-DnsServerZone -Name "" ``` Resource Record suchen: ```powershell Get-DnsServerResourceRecord -ZoneName "" -Name "" ``` A- und AAAA-Records der Zone anzeigen: ```powershell Get-DnsServerResourceRecord -ZoneName "" -RRType A ``` ```powershell Get-DnsServerResourceRecord -ZoneName "" -RRType AAAA ``` Zu prüfen sind: - existiert die richtige Zone, - ist die Zone geladen, - ist der Record vorhanden, - stimmt der Record-Typ, - stimmt die gespeicherte IP-Adresse, - existiert ein alter zusätzlicher Record, - verweist ein CNAME auf einen gültigen Zielnamen, - ist der Record statisch oder dynamisch registriert, - stimmt der Zeitstempel, - ist die TTL plausibel, - befindet sich der Record auf allen zuständigen DNS-Servern, - wird möglicherweise eine gleichnamige, aber falsche Zone verwendet? **Beispiel** Der Client fragt ab: ```text server01.example.local ``` Dafür müssen mindestens folgende Bestandteile stimmen: ```text Zone: example.local Name: server01 Typ: A oder AAAA Wert: vorgesehene IP-Adresse ``` Ein korrekt aussehender Record auf einem DNS-Server genügt nicht, wenn Clients auch andere DNS-Server verwenden. --- **14. TTL und veraltete Antworten berücksichtigen** Die TTL bestimmt, wie lange ein Resolver einen DNS-Record zwischenspeichern darf. TTL mit PowerShell prüfen: ```powershell Resolve-DnsName ``` Ausführlich mit `nslookup`: ```cmd nslookup -debug ``` Mögliche Situation: 1. ein Record zeigte auf eine alte IP-Adresse, 2. der Record wurde auf dem DNS-Server korrigiert, 3. ein Client oder zwischengeschalteter Resolver besitzt noch die alte Antwort, 4. der Client verwendet diese bis zum Ablauf der TTL weiter. Zu berücksichtigen sind: - lokaler Clientcache, - Cache des DNS-Servers, - Forwarder-Cache, - Anwendungscache, - Browsercache, - Proxy- oder Sicherheitsgateway, - negative Cacheeinträge. Eine kurze TTL löst keine falsche Zonen- oder Replikationskonfiguration. Eine lange TTL ist ebenfalls nicht automatisch fehlerhaft, verlängert aber die mögliche Nutzungsdauer eines veralteten Cacheeintrags. --- **15. Zonenreplikation prüfen** Bei Active-Directory-integrierten Zonen prüfen: - Replikationsbereich der Zone, - Zustand der Active-Directory-Replikation, - Vorhandensein des Records auf allen zuständigen DNS-Servern, - Zeitpunkt der letzten Änderung, - Erreichbarkeit der Replikationspartner, - Ereignisprotokolle von DNS und Active Directory. Zone auf mehreren Servern gezielt vergleichen: ```powershell Get-DnsServerResourceRecord ` -ComputerName ` -ZoneName "" ` -Name "" ``` ```powershell Get-DnsServerResourceRecord ` -ComputerName ` -ZoneName "" ` -Name "" ``` **Hinweise auf ein Replikationsproblem** - ein DNS-Server liefert die neue IP-Adresse, - ein anderer DNS-Server liefert die alte IP-Adresse, - ein Server besitzt den Record, ein anderer meldet `NXDOMAIN`, - Fehler tritt nur an einem Standort auf, - Fehler tritt abhängig vom verwendeten DNS-Server auf, - eine kürzlich angelegte Zone oder ein Record fehlt auf einzelnen Servern. Die Zone oder der Record sollte nicht einfach auf jedem Server manuell nachgebaut werden. Zuerst muss geklärt werden, warum die vorgesehene Replikation nicht funktioniert. --- **16. Forwarder und Conditional Forwarder prüfen** Forwarder auf einem Windows-DNS-Server anzeigen: ```powershell Get-DnsServerForwarder ``` Conditional Forwarder anzeigen: ```powershell Get-DnsServerZone | Where-Object ZoneType -EQ "Forwarder" ``` Details einer Weiterleitungszone prüfen: ```powershell Get-DnsServerConditionalForwarderZone -Name "" ``` Zu prüfen sind: - wird die betroffene Domäne lokal autoritativ beantwortet, - existiert ein Conditional Forwarder für die Domäne, - zeigen dessen Zieladressen auf die richtigen DNS-Server, - sind diese Server erreichbar, - antworten sie auf die betreffende Anfrage, - funktioniert UDP und TCP 53, - besteht der erforderliche VPN- oder Standortpfad, - ist die Weiterleitungszone korrekt repliziert, - greift unbeabsichtigt eine lokale Zone statt des Forwarders? Gezielte Prüfung des Zielservers: ```powershell Resolve-DnsName -Server ``` **Entscheidung** ```text Betrifft der Fehler nur Namen einer bestimmten Domäne? | +-- Nein | -> allgemeinen DNS-Dienst und Clientpfad prüfen | +-- Ja | +-- Ist der lokale DNS-Server für die Zone autoritativ? | +-- Ja -> Zone, Record und Replikation prüfen | +-- Nein | +-- Existiert ein Conditional Forwarder oder eine Delegation? | +-- Nein -> vorgesehene Namensarchitektur prüfen | +-- Ja -> Zielserver, Erreichbarkeit und Antwort prüfen ``` --- **17. Delegation prüfen** Bei einer delegierten untergeordneten Zone müssen die übergeordnete Zone und die zuständigen Nameserver korrekt auf die untergeordnete Zone verweisen. Nameserver abfragen: ```powershell Resolve-DnsName -Type NS ``` SOA-Eintrag prüfen: ```powershell Resolve-DnsName -Type SOA ``` Zu prüfen sind: - existiert die Delegation in der übergeordneten Zone, - sind die richtigen NS-Records eingetragen, - lassen sich die Nameservernamen auflösen, - stimmen benötigte Glue Records, - sind die delegierten DNS-Server erreichbar, - hosten diese Server die untergeordnete Zone, - liefern sie den erwarteten Record? **Typisches Fehlerbild** ```text host.abteilung.example.local ``` Die Zone: ```text abteilung.example.local ``` wurde auf separate DNS-Server delegiert. Die übergeordnete Zone kennt jedoch einen alten Nameserver. Dadurch funktioniert die übrige Domäne, während nur Namen unterhalb der delegierten Zone scheitern. --- **18. UDP und TCP auf Port 53 unterscheiden** DNS verwendet sowohl UDP als auch TCP. Typische Gründe für TCP-Nutzung: - Antwort ist für UDP zu groß, - DNSSEC vergrößert die Antwort, - Zonentransfer, - Server fordert Wiederholung über TCP, - bestimmte Netzwerk- oder Serverkonfigurationen. Nur TCP testen: ```powershell Test-NetConnection -ComputerName -Port 53 ``` Eine tatsächliche DNS-Abfrage ausführen: ```powershell Resolve-DnsName -Server ``` Abfrage ausdrücklich über TCP erzwingen: ```powershell Resolve-DnsName -Server -TcpOnly ``` **Bewertung** | Normale Abfrage | Abfrage mit `-TcpOnly` | Mögliche Eingrenzung | |---|---|---| | funktioniert | funktioniert | UDP und TCP wahrscheinlich nutzbar | | scheitert | funktioniert | UDP 53 oder UDP-Antwortpfad untersuchen | | funktioniert | scheitert | TCP 53 untersuchen | | beide scheitern | DNS-Dienst, Erreichbarkeit, Firewall oder Name prüfen | | kleine Antworten funktionieren, große nicht | Fragmentierung, MTU, EDNS oder TCP-Fallback prüfen | Firewallregeln dürfen nicht pauschal deaktiviert werden. Stattdessen sind erlaubte und blockierte DNS-Verbindungen gezielt anhand von Quelle, Ziel, Protokoll und Port zu prüfen. --- **19. Split-DNS berücksichtigen** Bei Split-DNS liefert derselbe Name abhängig vom verwendeten DNS-System unterschiedliche Antworten. Beispiel: ```text portal.example.com ``` Intern: ```text 10.10.20.25 ``` Extern: ```text 198.51.100.25 ``` Vergleichsabfragen: ```powershell Resolve-DnsName portal.example.com -Server ``` ```powershell Resolve-DnsName portal.example.com -Server ``` Zu prüfen sind: - ist der Client intern oder extern, - besteht eine VPN-Verbindung, - verwendet der Client den internen DNS-Server, - existiert eine interne Zone mit demselben Namen, - enthält die interne Zone den benötigten Record, - liefert ein öffentlicher Resolver absichtlich eine andere Adresse, - ist die interne Zieladresse vom aktuellen Standort erreichbar? **Typisches Fehlerbild** Die interne Zone `example.com` existiert, enthält aber keinen Record für `portal`. Der interne DNS-Server fragt deshalb möglicherweise nicht extern weiter, sondern beantwortet die Anfrage aus seiner eigenen autoritativen Zone mit einem negativen Ergebnis. --- **20. VPN, NRPT und DNS-Routing prüfen** VPN-Clients können abhängig von ihrer Konfiguration: - eigene DNS-Server erhalten, - nur bestimmte DNS-Domänen über das VPN auflösen, - eine DNS-Suffixsuchliste erhalten, - Split-Tunneling verwenden, - die Name Resolution Policy Table verwenden, - interne und externe Anfragen unterschiedlich behandeln. DNS-Konfiguration vor und nach der VPN-Verbindung vergleichen: ```powershell Get-DnsClientServerAddress ``` ```powershell Get-DnsClientGlobalSetting ``` NRPT-Regeln anzeigen: ```powershell Get-DnsClientNrptPolicy ``` Zusätzlich, abhängig von der Windows-Version: ```powershell Get-DnsClientNrptRule ``` Zu prüfen sind: - tritt der Fehler nur mit VPN auf, - tritt der Fehler nur ohne VPN auf, - ist der interne DNS-Server über den Tunnel erreichbar, - wird das interne Präfix über das VPN geroutet, - greift die vorgesehene NRPT-Regel, - verwendet die betroffene Domäne den richtigen DNS-Server, - überschreibt der VPN-Client die Suffixsuchliste, - besteht eine Überschneidung interner und lokaler Netze? **Vergleich** | Zustand | Ergebnis | Eingrenzung | |---|---|---| | ohne VPN fehlerhaft, mit VPN erfolgreich | interner DNS nur über VPN vorgesehen | | ohne VPN erfolgreich, mit VPN fehlerhaft | VPN-DNS, NRPT oder Tunnelrouting prüfen | | nur interne Namen fehlerhaft | internen DNS-Pfad und Suffix prüfen | | interne und externe Namen fehlerhaft | VPN-DNS-Konfiguration oder allgemeine Erreichbarkeit prüfen | | FQDN funktioniert, Kurzname nicht | Suffixänderung durch VPN prüfen | --- **21. DNS over HTTPS berücksichtigen** Bei DNS over HTTPS, kurz DoH, werden DNS-Abfragen verschlüsselt über HTTPS übertragen. Dadurch kann eine Anwendung oder der Windows-DNS-Client einen anderen DNS-Pfad verwenden als bei klassischem DNS über Port 53. Windows-Konfiguration unterstützter DoH-Server anzeigen: ```powershell Get-DnsClientDohServerAddress ``` Zu prüfen sind: - ist DoH auf dem Client aktiviert, - welcher DoH-Server wird verwendet, - verwendet der Browser einen eigenen sicheren DNS-Dienst, - umgeht die Anwendung den internen DNS-Server, - kann der DoH-Server interne Namen überhaupt auflösen, - blockiert eine Unternehmensrichtlinie nicht vorgesehene DoH-Verbindungen, - funktioniert die Namensauflösung im Betriebssystem, aber nicht im Browser, - funktioniert sie im Browser, aber nicht in anderen Anwendungen? **Typische Hinweise** | Beobachtung | Mögliche Ursache | |---|---| | `Resolve-DnsName` funktioniert, Browser nicht | Browsercache, Browser-DoH, Proxy oder Anwendung prüfen | | Browser funktioniert, andere Anwendungen nicht | Browser verwendet möglicherweise eigenen Resolver oder DoH | | interne Namen nur im Browser fehlerhaft | Browser-DoH umgeht möglicherweise internen DNS | | klassischer DNS-Port 53 blockiert, DoH funktioniert | unterschiedliche DNS-Pfade | | Fehler nur nach Aktivierung von sicherem DNS | DoH-Konfiguration oder verwendeten Resolver prüfen | DoH sollte nicht ungeprüft deaktiviert oder umkonfiguriert werden. Zuerst ist festzustellen, welcher Auflösungsweg tatsächlich vorgesehen ist. --- **22. DNS-Servercache berücksichtigen** Auch ein DNS-Server kann veraltete positive oder negative Antworten zwischenspeichern. Cacheeinträge eines autorisierten Windows-DNS-Servers anzeigen: ```powershell Show-DnsServerCache ``` Gezielt sollte geprüft werden: - enthält der Server eine alte IP-Adresse, - wurde zuvor eine negative Antwort gespeichert, - liefert der autoritative Server inzwischen eine andere Antwort, - verwenden mehrere DNS-Server unterschiedliche Cachezustände, - funktioniert eine direkte Abfrage des autoritativen Servers? Beispiel: ```powershell Resolve-DnsName -Server ``` ```powershell Resolve-DnsName -Server ``` Der Servercache darf nicht als erste Maßnahme vollständig geleert werden. Vorher müssen betroffene Einträge, TTL, Serverantworten und Zeitpunkt dokumentiert werden. --- **23. CNAME-Ketten vollständig prüfen** CNAME-Abfrage: ```powershell Resolve-DnsName -Type CNAME ``` Normale Abfrage: ```powershell Resolve-DnsName ``` Beispiel: ```text portal.example.local CNAME -> webfarm.example.local A -> 192.0.2.80 ``` Zu prüfen sind: - existiert der CNAME, - ist dessen Zielname korrekt geschrieben, - lässt sich der Zielname auflösen, - verweist die Kette auf eine gültige Adresse, - besteht eine Schleife, - liegt das Ziel in einer anderen Zone, - funktioniert die Weiterleitung zu dieser Zone, - existieren widersprüchliche Records? Ein vorhandener CNAME genügt nicht. Die gesamte Kette bis zum abschließenden A- oder AAAA-Record muss funktionieren. --- **24. DNS-Antwortcodes richtig bewerten** | Antwort | Bedeutung | Nächster Schritt | |---|---|---| | `NOERROR` mit Antwort | Abfrage wurde erfolgreich beantwortet | Record und Adresse prüfen | | `NOERROR` ohne gesuchten Record | Name kann existieren, aber der angefragte Typ fehlt | Record-Typ und Zonendaten prüfen | | `NXDOMAIN` | der abgefragte Name existiert laut antwortendem Server nicht | Schreibweise, Zone, Record, Cache und Replikation prüfen | | `SERVFAIL` | Server konnte die Anfrage nicht erfolgreich verarbeiten | DNSSEC, Weiterleitung, Delegation, Serverprotokolle oder Erreichbarkeit prüfen | | `REFUSED` | Server lehnt die Anfrage ab | Richtlinie, Rekursion, ACL oder Serverrolle prüfen | | Zeitüberschreitung | keine rechtzeitige Antwort | Dienst, Netzwerkpfad, Firewall, UDP/TCP oder Auslastung prüfen | Ein `NXDOMAIN` ist eine DNS-Antwort und nicht dasselbe wie eine Zeitüberschreitung. Bei `NXDOMAIN` hat ein DNS-Server geantwortet, konnte den Namen jedoch in seinem Auflösungspfad nicht als vorhanden bestätigen. --- **25. Anwendungen getrennt vom DNS-System testen** Wenn Befehlszeilentests funktionieren, die Anwendung jedoch weiterhin scheitert, prüfen: - Anwendung vollständig neu gestartet, - anwendungseigener DNS-Cache, - Browsercache, - Proxykonfiguration, - Browser-DoH, - fest konfigurierte Zieladresse, - Zertifikat stimmt nicht zum Namen, - Anwendung verwendet einen Alias oder anderen Hostnamen, - Load-Balancer oder Reverse Proxy, - Verbindung über IPv4 oder IPv6, - lokale Sicherheitssoftware, - PAC-Datei oder Webproxy, - Container, VM oder WSL mit eigener DNS-Konfiguration. **Vergleichstests** ```powershell Resolve-DnsName ``` ```powershell Test-NetConnection -ComputerName -Port ``` ```powershell Test-NetConnection -ComputerName -Port ``` Wenn diese Tests erfolgreich sind, muss der konkrete Auflösungs- und Verbindungsweg der Anwendung untersucht werden. --- **26. Beispiel für eine schnelle Diagnose** **Symptom** Ein Benutzer kann den internen Fileserver über seine IP-Adresse erreichen: ```text \\192.0.2.25\Freigabe ``` Der Zugriff über den Namen scheitert: ```text \\fileserver.example.local\Freigabe ``` **IP-Prüfung** ```powershell Test-NetConnection -ComputerName 192.0.2.25 -Port 445 ``` Ergebnis: ```text TcpTestSucceeded : True ``` **Namensprüfung** ```powershell Resolve-DnsName fileserver.example.local ``` Ergebnis: ```text Name : fileserver.example.local Type : A IPAddress : 192.0.2.20 ``` **Bewertung** - SMB-Port 445 ist an der tatsächlichen Serveradresse erreichbar. - Der Name wird aufgelöst. - Die gelieferte Adresse ist jedoch veraltet. - Es liegt kein allgemeiner Netzwerkausfall vor. - DNS-Record, Cache und Replikation müssen geprüft werden. **Vergleich der DNS-Server** ```powershell Resolve-DnsName fileserver.example.local -Server 192.0.2.10 ``` Ergebnis: ```text IPAddress : 192.0.2.25 ``` ```powershell Resolve-DnsName fileserver.example.local -Server 192.0.2.11 ``` Ergebnis: ```text IPAddress : 192.0.2.20 ``` **Festgestellte Ursache** Der aktualisierte A-Record wurde aufgrund einer gestörten Active-Directory-Replikation noch nicht auf den zweiten DNS-Server übertragen. **Kontrollierte Maßnahme** - Replikationsfehler untersucht und behoben, - Replikation des DNS-Records bestätigt, - beide DNS-Server liefern anschließend dieselbe Adresse, - alter Clientcache erst nach der Dokumentation geleert. **Nachprüfung** ```powershell Resolve-DnsName fileserver.example.local -Server 192.0.2.10 ``` ```powershell Resolve-DnsName fileserver.example.local -Server 192.0.2.11 ``` Beide Server liefern: ```text IPAddress : 192.0.2.25 ``` Zusätzlich: ```powershell Test-NetConnection -ComputerName fileserver.example.local -Port 445 ``` Ergebnis: ```text TcpTestSucceeded : True ``` Die Freigabe funktioniert anschließend wieder über den vorgesehenen Namen. --- **27. Ungeeignete Sofortmaßnahmen** Nicht als erste Maßnahme verwenden: - öffentliche DNS-Server am Unternehmensclient eintragen, - DNS-Server wahllos austauschen, - DNS-Cache vor der Dokumentation löschen, - DNS-Servercache vollständig leeren, - `hosts`-Datei ungeprüft bearbeiten, - einen neuen DNS-Record zusätzlich anlegen, ohne vorhandene Records zu prüfen, - mehrere widersprüchliche A-Records erstellen, - DNS-Zone auf jedem Server manuell nachbauen, - DNS-Dienst oder Domain Controller sofort neu starten, - VPN-Client ungeprüft deinstallieren, - NRPT-Regeln ungeprüft löschen, - DoH pauschal deaktivieren, - IPv6 vollständig deaktivieren, - Firewall vollständig abschalten, - TTL ohne Ursachenanalyse stark verkürzen, - mehrere DNS-Änderungen gleichzeitig durchführen, - ausschließlich mit `ping` testen, - erfolgreiche IP-Erreichbarkeit mit vollständiger Anwendungsfunktion gleichsetzen. Solche Maßnahmen können den ursprünglichen Zustand verändern, Beweise beseitigen oder zusätzliche Fehler in Active Directory, VPN und internen Anwendungen verursachen. --- **28. Vollständige Schnellprüfreihenfolge** 1. genaue Fehlermeldung und Uhrzeit erfassen. 2. verwendeten Namen exakt dokumentieren. 3. erwartete Ziel-IP und Zielport feststellen. 4. Zielport über die IP-Adresse prüfen. 5. Zielport über den Namen prüfen. 6. FQDN und Kurzname getrennt testen. 7. aktive Netzwerkadapter ermitteln. 8. konfigurierte DNS-Server dokumentieren. 9. DNS-Suffix und Suchliste prüfen. 10. VPN und virtuelle Adapter berücksichtigen. 11. jeden eingetragenen DNS-Server einzeln abfragen. 12. Antworten und TTL miteinander vergleichen. 13. A- und AAAA-Records getrennt prüfen. 14. CNAME-Kette untersuchen. 15. zurückgegebene IP-Adressen einzeln testen. 16. Clientcache anzeigen und dokumentieren. 17. negative Cacheeinträge berücksichtigen. 18. `hosts`-Datei kontrollieren. 19. Zone und Resource Record auf dem DNS-Server prüfen. 20. Record auf allen zuständigen DNS-Servern vergleichen. 21. Zonen- oder AD-Replikation untersuchen. 22. Forwarder und Conditional Forwarder prüfen. 23. Delegation und Nameserver prüfen. 24. UDP und TCP 53 unterscheiden. 25. Split-DNS berücksichtigen. 26. VPN-Routing, DNS-Zuweisung und NRPT prüfen. 27. DoH und anwendungseigene Resolver berücksichtigen. 28. genau eine Hypothese formulieren. 29. genau eine kontrollierte Maßnahme durchführen. 30. dieselben Abfragen erneut ausführen. 31. jeden vorgesehenen DNS-Server erneut testen. 32. den benötigten Dienst über den Namen prüfen. 33. Vergleichsclient oder Vergleichsstandort testen. 34. temporäre Diagnoseänderungen entfernen. 35. Ursache, Maßnahme und Nachweis dokumentieren. --- **29. Checkliste „Name geht nicht, IP geht“** - [ ] genaue Fehlermeldung wurde dokumentiert. - [ ] Zeitpunkt der fehlerhaften Abfrage ist bekannt. - [ ] verwendeter Zielname wurde exakt übernommen. - [ ] erwarteter FQDN ist bekannt. - [ ] erwartete Ziel-IP ist bekannt. - [ ] benötigter Zielport wurde bestimmt. - [ ] Zielport ist über die IP-Adresse erreichbar. - [ ] Zielport wurde auch über den Namen getestet. - [ ] FQDN und Kurzname wurden getrennt geprüft. - [ ] aktive Netzwerkadapter wurden ermittelt. - [ ] konfigurierte DNS-Server wurden dokumentiert. - [ ] DHCP- oder statische DNS-Konfiguration wurde unterschieden. - [ ] DNS-Suffix wurde geprüft. - [ ] DNS-Suffixsuchliste wurde geprüft. - [ ] VPN-Adapter wurden berücksichtigt. - [ ] virtuelle Adapter wurden berücksichtigt. - [ ] jeder DNS-Server wurde einzeln abgefragt. - [ ] Antworten mehrerer DNS-Server wurden verglichen. - [ ] A-Record wurde geprüft. - [ ] AAAA-Record wurde geprüft. - [ ] CNAME-Kette wurde geprüft. - [ ] zurückgegebene IP-Adressen wurden auf Plausibilität geprüft. - [ ] alle gelieferten Zieladressen wurden berücksichtigt. - [ ] TTL wurde dokumentiert. - [ ] Clientcache wurde vor dem Leeren untersucht. - [ ] negativer Cache wurde berücksichtigt. - [ ] `hosts`-Datei wurde geprüft. - [ ] zuständige DNS-Zone wurde ermittelt. - [ ] Resource Record wurde serverseitig geprüft. - [ ] mehrere zuständige DNS-Server wurden verglichen. - [ ] Zonenreplikation wurde berücksichtigt. - [ ] Active-Directory-Replikation wurde bei Bedarf geprüft. - [ ] Forwarder wurden geprüft. - [ ] Conditional Forwarder wurden geprüft. - [ ] Delegationen wurden berücksichtigt. - [ ] UDP und TCP 53 wurden unterschieden. - [ ] Split-DNS wurde berücksichtigt. - [ ] VPN-DNS und NRPT wurden berücksichtigt. - [ ] DNS over HTTPS wurde berücksichtigt. - [ ] anwendungseigene DNS-Auflösung wurde berücksichtigt. - [ ] vor Änderungen wurden Antworten und Cachezustände gesichert. - [ ] nur eine kontrollierbare Änderung wurde durchgeführt. - [ ] dieselben Abfragen wurden anschließend wiederholt. - [ ] alle vorgesehenen DNS-Server liefern konsistente Antworten. - [ ] der benötigte Dienst funktioniert wieder über den Namen. - [ ] Ursache, Maßnahme und Nachweis wurden dokumentiert. --- **30. Schnellreferenz** | Ergebnis | Nächster Schritt | |---|---| | IP und Zielport funktionieren, Name nicht | DNS-Pfad untersuchen | | IP funktioniert, Zielport nicht | Dienst oder Firewall prüfen | | FQDN funktioniert, Kurzname nicht | DNS-Suffix und Suchliste prüfen | | kein DNS-Server eingetragen | DHCP- oder Adapterkonfiguration prüfen | | falscher DNS-Server eingetragen | vorgesehene Clientkonfiguration prüfen | | DNS-Server nicht erreichbar | Routing, VPN, Firewall oder Server prüfen | | ein DNS-Server antwortet, ein anderer nicht | zweiten Server oder Netzwerkpfad prüfen | | DNS-Server liefern unterschiedliche IPs | Record, Replikation oder Split-DNS prüfen | | A korrekt, AAAA falsch | IPv6-Record und IPv6-Pfad prüfen | | AAAA korrekt, A falsch | IPv4-Record und IPv4-Pfad prüfen | | Name liefert alte IP | Record, TTL und Cache prüfen | | direkte Serverabfrage korrekt, Clientantwort falsch | Clientcache, `hosts` oder Resolverpfad prüfen | | `NXDOMAIN` | Name, Zone, Record, Replikation oder Weiterleitung prüfen | | `SERVFAIL` | Server, DNSSEC, Forwarder oder Delegation prüfen | | FQDN in bestimmter Domäne scheitert | Conditional Forwarder oder Delegation prüfen | | nur intern fehlerhaft | interne Zone, Split-DNS oder internen Resolver prüfen | | nur extern fehlerhaft | Forwarder, Rekursion oder externen DNS-Pfad prüfen | | nur mit VPN fehlerhaft | VPN-DNS, NRPT, Suffix oder Routing prüfen | | nur ohne VPN fehlerhaft | interner DNS möglicherweise nur über VPN erreichbar | | PowerShell funktioniert, Browser nicht | Browsercache, DoH, Proxy oder Anwendung prüfen | | normale Abfrage scheitert, `-TcpOnly` funktioniert | UDP 53 oder UDP-Antwortpfad prüfen | | TCP-Abfrage scheitert | TCP 53, Firewall oder DNS-Dienst prüfen | | CNAME vorhanden, Ziel nicht auflösbar | vollständige CNAME-Kette prüfen | | Fehler nur auf einem Client | Cache, `hosts`, Adapter, VPN oder DoH prüfen | | Fehler auf mehreren Clients | DNS-Dienst, DHCP-Option, Zone oder Replikation prüfen | --- **Merksatz** > Wenn die IP-Adresse funktioniert, der Name aber nicht, wird von unten nach oben geprüft: richtiger Name, FQDN, Client-DNS, einzelner DNS-Server, A und AAAA, Cache, Zone, Record, Replikation und Weiterleitung. Eine DNS-Antwort ist erst dann brauchbar, wenn sie vom vorgesehenen Server kommt und auf das richtige erreichbare Ziel verweist. --- **Quellen und weiterführende Dokumentation** - [Microsoft Learn – DNS Client PowerShell module](https://learn.microsoft.com/en-us/powershell/module/dnsclient/) - [Microsoft Learn – Resolve-DnsName](https://learn.microsoft.com/en-us/powershell/module/dnsclient/resolve-dnsname) - [Microsoft Learn – Get-DnsClientServerAddress](https://learn.microsoft.com/en-us/powershell/module/dnsclient/get-dnsclientserveraddress) - [Microsoft Learn – Get-DnsClient](https://learn.microsoft.com/en-us/powershell/module/dnsclient/get-dnsclient) - [Microsoft Learn – Get-DnsClientGlobalSetting](https://learn.microsoft.com/en-us/powershell/module/dnsclient/get-dnsclientglobalsetting) - [Microsoft Learn – Get-DnsClientCache](https://learn.microsoft.com/en-us/powershell/module/dnsclient/get-dnsclientcache) - [Microsoft Learn – Clear-DnsClientCache](https://learn.microsoft.com/en-us/powershell/module/dnsclient/clear-dnsclientcache) - [Microsoft Learn – Get-DnsClientDohServerAddress](https://learn.microsoft.com/en-us/powershell/module/dnsclient/get-dnsclientdohserveraddress) - [Microsoft Learn – Secure DNS Client over HTTPS](https://learn.microsoft.com/en-us/windows-server/networking/dns/doh-client-support) - [Microsoft Learn – nslookup](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/nslookup) - [Microsoft Learn – ipconfig](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/ipconfig) - [Microsoft Learn – Test-NetConnection](https://learn.microsoft.com/en-us/powershell/module/nettcpip/test-netconnection) - [Microsoft Learn – DNS zones](https://learn.microsoft.com/en-us/windows-server/networking/dns/zone-types) - [Microsoft Learn – Manage DNS zones](https://learn.microsoft.com/en-us/windows-server/networking/dns/manage-dns-zones) - [Microsoft Learn – DNS forwarding](https://learn.microsoft.com/en-us/windows-server/networking/dns/forwarding) - [Microsoft Learn – Get-DnsServerZone](https://learn.microsoft.com/en-us/powershell/module/dnsserver/get-dnsserverzone) - [Microsoft Learn – Get-DnsServerResourceRecord](https://learn.microsoft.com/en-us/powershell/module/dnsserver/get-dnsserverresourcerecord) - [Microsoft Learn – Get-DnsServerForwarder](https://learn.microsoft.com/en-us/powershell/module/dnsserver/get-dnsserverforwarder) - [Microsoft Learn – Get-DnsServerConditionalForwarderZone](https://learn.microsoft.com/en-us/powershell/module/dnsserver/get-dnsserverconditionalforwarderzone) - [Microsoft Learn – Best practices for DNS client settings](https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/best-practices-for-dns-client-settings) # 7.4 VLAN- und Switching-Fehleranalyse Ein Client besitzt eine gültige IP-Konfiguration, kann aber bestimmte Geräte, Server oder Netze nicht erreichen. Andere Clients am gleichen Standort funktionieren möglicherweise problemlos. In solchen Fällen kann die Ursache auf der Sicherungsschicht liegen: - falsches Access-VLAN, - VLAN auf einem Switch nicht vorhanden, - VLAN auf einem Trunk nicht zugelassen, - Native-VLAN-Mismatch, - fehlerhafte Portkonfiguration, - blockierter Port durch Spanning Tree, - gestörter EtherChannel, - falsche MAC-Adresszuordnung, - Port-Security-Verletzung, - Schleife oder MAC-Flapping, - physischer Fehler an Port oder Verkabelung. Die Diagnose muss vom betroffenen Endgerät über jeden beteiligten Switch bis zum Gateway beziehungsweise Zielsystem erfolgen. > Ein Symptom ist noch keine Ursache. Ein erreichbarer Switch beweist nicht, dass das betroffene VLAN auf dem vollständigen Datenpfad korrekt transportiert wird. --- **1. Typische Fehlerbilder** | Beobachtung | Mögliche Ursache | |---|---| | nur ein Client ist betroffen | Access-Port, Kabel, Netzwerkkarte, VLAN-Zuordnung oder Port-Security | | alle Clients an einem Switch sind betroffen | Uplink, Trunk, EtherChannel, STP oder Switchausfall | | nur ein VLAN ist betroffen | VLAN fehlt, Trunk-Liste, SVI, Gateway oder STP-Instanz | | Clients im gleichen VLAN kommunizieren nicht | falsches VLAN, Port-Isolation, Private VLAN, ACL oder lokale Firewall | | lokale Geräte sind erreichbar, Gateway nicht | Uplink, Trunk, SVI oder Gateway | | Gateway erreichbar, andere VLANs nicht | Routing, ACL oder Firewall statt reines Layer-2-Problem | | Fehler tritt nur an einem Standort auf | lokaler Switch, Trunk, Standort-Uplink oder VLAN-Bereitstellung | | Fehler tritt nur an einem Port auf | Portkonfiguration, Kabel, Port-Security oder Hardware | | Verbindung funktioniert nach Umstecken | unterschiedliche VLAN- oder Portkonfiguration | | Verbindung fällt wiederholt kurz aus | Link-Flapping, STP-Änderungen, EtherChannel oder Hardware | | IP-Telefon funktioniert, angeschlossener PC nicht | Voice-VLAN korrekt, Data-VLAN oder Trunk zum Telefon fehlerhaft | | DHCP funktioniert nicht, statische IP teilweise schon | DHCP-Relay, DHCP-Serverpfad oder falsches VLAN | | MAC-Adresse erscheint ständig an anderen Ports | Schleife, falsch verbundene Switches oder MAC-Flapping | --- **2. Sollzustand vor der Diagnose feststellen** Vor der Fehlersuche muss bekannt sein, wie der Port und der Datenpfad vorgesehen sind. Zu dokumentieren sind: - betroffener Client, - MAC-Adresse des Clients, - Switchname, - physischer Switchport, - vorgesehenes Access-VLAN, - gegebenenfalls Voice-VLAN, - IP-Subnetz des VLANs, - vorgesehene Gateway-Adresse, - beteiligte Uplinks, - beteiligte Trunks, - erlaubte VLANs auf jedem Trunk, - Native VLAN, - zuständiges SVI oder Router-Subinterface, - mögliche EtherChannels, - verwendete Spanning-Tree-Variante, - Zeitpunkt und Umfang der Störung. Beispiel: ```text Client: client01 MAC-Adresse: 00:11:22:33:44:55 Switch: access-sw01 Port: GigabitEthernet1/0/12 Access-VLAN: 20 IP-Netz: 192.0.2.0/24 Gateway: 192.0.2.1 Uplink: GigabitEthernet1/0/48 Trunk-VLANs: 10,20,30 Distribution-Switch: dist-sw01 SVI: Vlan20 ``` Ohne diesen Sollzustand lässt sich eine vorhandene Konfiguration nicht zuverlässig als richtig oder falsch bewerten. --- **3. Umfang der Störung bestimmen** Zuerst prüfen: - ist nur ein Client betroffen, - sind mehrere Clients am gleichen Portpfad betroffen, - betrifft der Fehler alle Ports eines Switches, - betrifft der Fehler nur ein VLAN, - betrifft er mehrere VLANs, - betrifft er nur einen Switch, - betrifft er mehrere Switches, - funktioniert die Kommunikation innerhalb des VLANs, - funktioniert die Kommunikation zum Gateway, - funktioniert die Kommunikation zwischen VLANs, - begann die Störung nach einer Änderung? **Vergleichstests** | Vergleich | Aussage | |---|---| | anderer Client am gleichen Port | grenzt Client und Port gegeneinander ab | | gleicher Client an bekannt funktionierendem Port | prüft Client gegen Switchport | | anderer Client im gleichen VLAN | prüft Umfang innerhalb des VLANs | | Client in anderem VLAN am gleichen Switch | grenzt VLAN gegen allgemeinen Switchfehler ab | | gleiches VLAN an anderem Switch | grenzt lokalen Switch oder Uplink ein | | Gateway desselben VLANs | prüft den Layer-2-Pfad bis zum Gateway | | Ziel im gleichen Subnetz | prüft lokale Layer-2-Kommunikation | | Ziel in anderem Subnetz | bezieht zusätzlich Routing und Firewall ein | Ein Gerät darf nur kontrolliert umgesteckt werden. Vorher müssen ursprünglicher Port, VLAN-Zuordnung und Konfiguration dokumentiert werden. --- **4. Clientkonfiguration prüfen** Unter Windows: ```cmd ipconfig /all ``` ```powershell Get-NetAdapter ``` ```powershell Get-NetIPConfiguration ``` ```powershell Get-NetIPAddress ``` ```powershell Get-NetRoute -AddressFamily IPv4 ``` Unter Linux: ```bash ip link show ``` ```bash ip address show ``` ```bash ip route show ``` Unter macOS: ```bash ifconfig ``` ```bash route -n get default ``` Zu prüfen sind: - ist der richtige Adapter aktiv, - besitzt der Client eine Adresse aus dem vorgesehenen Subnetz, - stimmt die Präfixlänge, - stimmt das Standardgateway, - stammt die Adresse aus dem erwarteten DHCP-Bereich, - existieren zusätzliche aktive Adapter, - verwendet der Client selbst VLAN-Tagging, - ist eine Bridge oder virtuelle Netzwerkkarte aktiv, - läuft eine VM oder ein Container mit eigener Netzwerkkonfiguration? Eine gültig aussehende IP-Adresse beweist nicht, dass der Client am richtigen VLAN angeschlossen ist. In verschiedenen VLANs können ähnliche oder versehentlich überlappende Adressbereiche vorkommen. --- **5. Physische Verbindung und Portstatus prüfen** Am Client prüfen: ```powershell Get-NetAdapter | Format-Table Name, InterfaceDescription, Status, LinkSpeed, MacAddress ``` Auf einem Cisco-IOS-/IOS-XE-Switch beispielsweise: ```text show interfaces status ``` Gezielten Port prüfen: ```text show interfaces GigabitEthernet1/0/12 ``` Kurze Fehlerübersicht: ```text show interfaces counters errors ``` Zu prüfen sind: - Portstatus, - ausgehandeltes Tempo, - Duplexmodus, - Ein- und Ausgangsfehler, - CRC-Fehler, - Drops, - Link-Flapping, - Zeitpunkt der letzten Statusänderung, - administrativ deaktivierter Port, - Fehlerzustand wie `err-disabled`. **Typische Bewertungen** | Status oder Zähler | Mögliche Ursache | |---|---| | `notconnect` | kein Link, Kabel, Client oder Gegenstelle | | `disabled` | Port administrativ deaktiviert | | `err-disabled` | Schutzfunktion oder erkannter Fehler | | viele CRC-Fehler | Kabel, Stecker, Transceiver, Duplex oder physische Störung | | viele Input Errors | physischer Fehler, Überlastung oder fehlerhafte Frames | | viele Output Drops | Überlastung oder Warteschlange | | Geschwindigkeit unerwartet niedrig | Kabel, Aushandlung oder Gegenstelle | | Link wechselt ständig | Kabel, Netzwerkkarte, Transceiver, Energieversorgung oder Port | Zähler sollten zuerst dokumentiert und danach über einen festgelegten Zeitraum erneut abgelesen werden. Ein hoher historischer Wert allein beweist keinen aktuell fortbestehenden Fehler. --- **6. Nachbarschaft und tatsächlichen Port ermitteln** Cisco Discovery Protocol: ```text show cdp neighbors ``` Details: ```text show cdp neighbors detail ``` Link Layer Discovery Protocol: ```text show lldp neighbors ``` Details: ```text show lldp neighbors detail ``` Zu prüfen sind: - welches Gerät tatsächlich angeschlossen ist, - welcher lokale Port verwendet wird, - welcher Gegenstellenport gemeldet wird, - ob statt eines Clients ein weiterer Switch angeschlossen ist, - ob ein IP-Telefon zwischen Client und Switch liegt, - ob die dokumentierte Verkabelung mit der erkannten Topologie übereinstimmt. CDP oder LLDP kann deaktiviert sein. Ein fehlender Nachbar beweist deshalb nicht, dass keine Verbindung besteht. --- **7. VLAN-Zuordnung des Access-Ports prüfen** VLAN-Übersicht: ```text show vlan brief ``` Portbezogene Switchportinformationen: ```text show interfaces GigabitEthernet1/0/12 switchport ``` Relevante Portkonfiguration: ```text show running-config interface GigabitEthernet1/0/12 ``` Zu prüfen sind: - administrativer Portmodus, - tatsächlich verwendeter Portmodus, - Access-VLAN, - Voice-VLAN, - Native VLAN bei einem Trunk, - erlaubte VLANs, - dynamische oder fest konfigurierte Aushandlung, - zusätzliche Sicherheits- oder Authentifizierungsfunktionen. Beispiel eines vorgesehenen Access-Ports: ```text interface GigabitEthernet1/0/12 switchport mode access switchport access vlan 20 ``` **Mögliche Fehler** ```text switchport access vlan 10 ``` obwohl der Client VLAN 20 verwenden soll. Oder der Port arbeitet unerwartet als Trunk: ```text switchport mode trunk ``` Eine Konfigurationszeile allein reicht nicht zur Bewertung. Administrative und operative Zustände müssen miteinander verglichen werden. --- **8. Existenz und Status des VLANs prüfen** ```text show vlan brief ``` Gezielt: ```text show vlan id 20 ``` Zu prüfen sind: - existiert VLAN 20, - ist es aktiv, - besitzt es den erwarteten Namen, - sind die vorgesehenen Access-Ports zugeordnet, - existiert das VLAN auf jedem beteiligten Switch, - wurde es möglicherweise gelöscht oder umnummeriert, - ist eine VLAN-Verwaltung wie VTP beteiligt? **Wichtig** Ein Access-Port kann auf ein VLAN verweisen, das auf dem Switch nicht ordnungsgemäß vorhanden oder aktiv ist. Ebenso beweist die Existenz des VLANs auf einem Access-Switch nicht, dass es auf allen weiteren Switches des Pfades verfügbar ist. VLANs dürfen nicht vorschnell neu angelegt werden. Zuerst muss geklärt werden, ob das VLAN absichtlich entfernt wurde oder über ein vorgesehenes Verwaltungsverfahren bereitgestellt werden soll. --- **9. MAC-Adresse des Clients ermitteln** Unter Windows: ```powershell Get-NetAdapter | Format-Table Name, MacAddress, Status ``` Unter Linux: ```bash ip link show ``` Unter macOS: ```bash ifconfig ``` Die MAC-Adresse muss dem tatsächlich verwendeten physischen Adapter zugeordnet werden. WLAN-, Ethernet-, Docking-, VPN- und virtuelle Adapter besitzen unterschiedliche MAC-Adressen. Beispiel: ```text 00-11-22-33-44-55 ``` Auf Cisco-Switches wird sie normalerweise ohne Trennzeichen oder mit Punktgruppen gesucht: ```text 0011.2233.4455 ``` --- **10. MAC-Adress-Tabelle prüfen** Gesamte Tabelle: ```text show mac address-table ``` Bestimmte MAC-Adresse suchen: ```text show mac address-table address 0011.2233.4455 ``` MAC-Adressen eines VLANs: ```text show mac address-table vlan 20 ``` MAC-Adressen eines Ports: ```text show mac address-table interface GigabitEthernet1/0/12 ``` Zu prüfen sind: - wird die Client-MAC gelernt, - wird sie im richtigen VLAN gelernt, - erscheint sie am erwarteten Port, - erscheint sie auf einem Uplink statt am lokalen Clientport, - wechselt sie zwischen mehreren Ports, - fehlt sie vollständig, - ist der Eintrag dynamisch oder statisch? **Bewertung** | Beobachtung | Mögliche Ursache | |---|---| | MAC am richtigen Access-Port und VLAN | lokaler Layer-2-Eingang grundsätzlich erkannt | | MAC im falschen VLAN | falsche Access-, Voice- oder Tagging-Konfiguration | | MAC auf falschem Port | falsche Dokumentation, Verkabelung oder Schleife | | MAC nur am Uplink | Client befindet sich hinter einem anderen Gerät | | MAC fehlt | Client sendet nicht, falscher Port, Linkproblem oder Filterung | | MAC wechselt zwischen Ports | Schleife, doppelte Verbindung oder MAC-Flapping | | sehr viele MAC-Adressen am Clientport | möglicherweise weiterer Switch oder Bridge angeschlossen | Die MAC-Adresse muss auf jedem Switch entlang des Pfades verfolgt werden. Auf einem Access-Switch sollte sie am Clientport erscheinen, auf nachgelagerten Switches am jeweiligen Uplink in Richtung des Clients. --- **11. Layer-2-Pfad anhand der MAC-Adresse verfolgen** Beispiel: ```text Client | | Gi1/0/12, VLAN 20 | Access-Switch | | Gi1/0/48, Trunk | Distribution-Switch | | Port-Channel1, Trunk | Gateway-SVI Vlan20 ``` Prüfung auf dem Access-Switch: ```text show mac address-table address 0011.2233.4455 ``` Erwartung: ```text VLAN 20 -> GigabitEthernet1/0/12 ``` Prüfung auf dem Distribution-Switch: ```text show mac address-table address 0011.2233.4455 ``` Erwartung: ```text VLAN 20 -> GigabitEthernet1/0/48 ``` oder: ```text VLAN 20 -> Port-channel1 ``` Verschwindet die MAC-Adresse an einem Übergang, sind insbesondere zu prüfen: - VLAN auf dem nächsten Switch vorhanden, - VLAN am Trunk zugelassen, - Trunk tatsächlich aktiv, - STP-Status des VLANs, - EtherChannel-Zustand, - Native-VLAN-Konfiguration, - physische Verbindung. --- **12. Trunkstatus prüfen** Trunkübersicht: ```text show interfaces trunk ``` Gezielten Port prüfen: ```text show interfaces GigabitEthernet1/0/48 switchport ``` Konfiguration anzeigen: ```text show running-config interface GigabitEthernet1/0/48 ``` Zu prüfen sind: - ist der Port operativ ein Trunk, - wird IEEE 802.1Q verwendet, - welches Native VLAN ist konfiguriert, - welche VLANs sind administrativ zugelassen, - welche VLANs sind aktiv, - welche VLANs werden tatsächlich weitergeleitet, - welche VLANs sind durch Spanning Tree nicht blockiert? Beispiel: ```text interface GigabitEthernet1/0/48 switchport mode trunk switchport trunk native vlan 999 switchport trunk allowed vlan 10,20,30 ``` Wenn VLAN 20 benötigt wird, muss es auf jedem Trunk des vollständigen Pfades zugelassen und aktiv sein. --- **13. Allowed-VLAN-Liste auf jedem Trunk vergleichen** ```text show interfaces trunk ``` Beispiel eines Fehlers: ```text Access-Switch: Allowed VLANs: 10,20,30 ``` ```text Distribution-Switch: Allowed VLANs: 10,30 ``` VLAN 20 ist nur auf einer Seite zugelassen. Geräte in VLAN 10 und VLAN 30 funktionieren, während VLAN 20 den Trunk nicht vollständig passieren kann. **Typische Ursachen** - VLAN bei einer Änderung aus der Liste entfernt, - VLAN nur auf einer Trunkseite ergänzt, - falscher Uplink bearbeitet, - VLAN-Liste versehentlich vollständig ersetzt, - EtherChannel-Mitglieder besitzen unterschiedliche Konfigurationen, - VLAN existiert auf einem Switch nicht. Eine Allowed-VLAN-Liste darf nicht pauschal auf „alle VLANs“ erweitert werden. Dadurch können Segmentierung, Sicherheit und vorgesehene Netzgrenzen verändert werden. --- **14. Native VLAN prüfen** Auf beiden Seiten des Trunks: ```text show interfaces trunk ``` ```text show interfaces switchport ``` Beispiel eines Mismatch: ```text Switch A: Native VLAN 999 Switch B: Native VLAN 1 ``` Mögliche Auswirkungen: - ungetaggter Verkehr landet auf beiden Seiten in unterschiedlichen VLANs, - Spanning Tree meldet eine PVID-Inkonsistenz, - ein Port oder VLAN wird durch Schutzmechanismen blockiert, - Verwaltungs- oder Steuerverkehr erreicht ein falsches VLAN, - Sicherheitsrisiken durch unbeabsichtigte VLAN-Zuordnung. Native VLANs müssen entsprechend der vorgesehenen Architektur auf beiden Seiten übereinstimmen. Ein Mismatch darf nicht dadurch „gelöst“ werden, dass wahllos VLAN 1 verwendet wird. --- **15. Access-Port und Trunk nicht verwechseln** **Access-Port** - transportiert normalerweise den Datenverkehr genau eines Data-VLANs, - Endgerät sendet üblicherweise ungetaggte Ethernet-Frames, - Switch ordnet eingehende Frames dem Access-VLAN zu. **Trunk-Port** - transportiert mehrere VLANs, - VLAN-Zuordnung erfolgt normalerweise über IEEE 802.1Q-Tags, - Native-VLAN-Verkehr kann abhängig von der Konfiguration ungetaggt sein. **Typische Fehlkonfigurationen** | Seite A | Seite B | Mögliche Folge | |---|---|---| | Access VLAN 20 | Access VLAN 20 | korrekt für eine einfache Verbindung im selben VLAN | | Trunk | Trunk | korrekt, wenn VLANs und Native VLAN übereinstimmen | | Access | Trunk | VLAN-Mismatch und unerwartete Zuordnung | | Access VLAN 10 | Access VLAN 20 | ungetaggter Verkehr wird verschiedenen VLANs zugeordnet | | Trunk mit VLAN 20 | Trunk ohne VLAN 20 | VLAN 20 kann den Pfad nicht vollständig nutzen | | Trunk Native 999 | Trunk Native 1 | Native-VLAN-Mismatch | --- **16. Clientseitiges VLAN-Tagging berücksichtigen** Ein normaler Arbeitsplatzclient sendet an einem Access-Port gewöhnlich keine VLAN-Tags. VLAN-Tagging am Client kann jedoch vorkommen bei: - Servern mit mehreren VLANs, - Hypervisoren, - virtuellen Switches, - Containernetzwerken, - Firewalls, - Access Points, - IP-Telefonen, - Netzwerktestgeräten, - speziellen Netzwerkkartentreibern. Zu prüfen sind: - ist am Client eine VLAN-ID konfiguriert, - erwartet der Switch einen Access-Port oder Trunk, - stimmt die VLAN-ID des Clients mit der Switchkonfiguration überein, - entfernt der Netzwerkkartentreiber VLAN-Tags, - existiert ein Hypervisor-vSwitch mit eigener VLAN-Zuordnung, - wird das Tag bereits an einer anderen Ebene hinzugefügt? Beispiel eines Fehlers: ```text Server-NIC taggt VLAN 20 Switchport ist Access-Port in VLAN 20 ``` Abhängig von Gerät und Konfiguration kann der getaggte Frame verworfen oder unerwartet verarbeitet werden. --- **17. Voice-VLAN und IP-Telefone prüfen** Beispiel: ```text interface GigabitEthernet1/0/12 switchport mode access switchport access vlan 20 switchport voice vlan 30 ``` Dabei kann gelten: ```text PC-Daten: VLAN 20 Telefonverkehr: VLAN 30 ``` Zu prüfen sind: - funktioniert nur Telefonie oder nur der PC, - ist das Data-VLAN korrekt, - ist das Voice-VLAN korrekt, - erkennt das Telefon die VLAN-Information, - ist der PC-Port des Telefons aktiv, - wird das Telefon per LLDP-MED oder CDP konfiguriert, - sind beide VLANs auf dem Uplink zugelassen, - existieren DHCP und Gateway in beiden VLANs? Dass das Telefon funktioniert, beweist nicht, dass auch das Data-VLAN korrekt eingerichtet ist. --- **18. ARP beziehungsweise Neighbor Cache prüfen** Unter Windows: ```powershell Get-NetNeighbor ``` ```cmd arp -a ``` Unter Linux: ```bash ip neighbor show ``` Unter macOS: ```bash arp -a ``` Zu prüfen sind: - besitzt der Client einen Eintrag für das Gateway, - ist der Eintrag erreichbar oder unvollständig, - stimmt die MAC-Adresse des Gateways, - ändert sich die Gateway-MAC unerwartet, - antworten Geräte im gleichen Subnetz auf ARP? **Bewertung** | Beobachtung | Mögliche Eingrenzung | |---|---| | Gateway-Eintrag ist erreichbar | Layer-2-Kommunikation zum Gateway grundsätzlich möglich | | Gateway bleibt `Incomplete` | ARP-Anfrage oder Antwort erreicht das Ziel nicht | | falsche Gateway-MAC | falsches Gerät, doppelte IP, Fehlkonfiguration oder Angriff | | lokales Ziel im gleichen VLAN nicht auflösbar | Layer-2-Pfad, Zielgerät oder lokale Firewall prüfen | | Gateway erreichbar, anderes Subnetz nicht | Routing, ACL oder Firewall untersuchen | ARP darf erst nach Dokumentation kontrolliert geleert werden. Ein Cache-Reset beseitigt sonst möglicherweise relevante Hinweise. --- **19. Gateway-SVI prüfen** Auf einem Layer-3-Switch beispielsweise: ```text show ip interface brief ``` Gezielt: ```text show interfaces Vlan20 ``` Konfiguration: ```text show running-config interface Vlan20 ``` ARP-Tabelle: ```text show ip arp ``` Zu prüfen sind: - existiert das SVI, - besitzt es die vorgesehene IP-Adresse, - ist es administrativ aktiv, - ist der Protokollstatus aktiv, - ist das zugehörige VLAN vorhanden und aktiv, - existiert mindestens ein erforderlicher aktiver Layer-2-Pfad, - wird die Client-MAC beziehungsweise IP gelernt, - ist ein Redundanzprotokoll beteiligt? **Typisches Fehlerbild** ```text Vlan20 is administratively up, line protocol is down ``` Mögliche Ursache: - VLAN 20 existiert nicht aktiv, - kein zugehöriger Layer-2-Port ist aktiv, - VLAN wird nicht über einen funktionierenden Trunk transportiert, - plattformspezifische Voraussetzungen sind nicht erfüllt. Ein erreichbares SVI in einem anderen VLAN beweist nicht, dass das SVI des betroffenen VLANs funktioniert. --- **20. Kommunikation innerhalb und außerhalb des VLANs trennen** Vom Client aus nacheinander prüfen: 1. eigene IP-Konfiguration, 2. Ziel im gleichen VLAN, 3. Standardgateway, 4. Ziel in einem anderen internen VLAN, 5. externes Ziel. Windows: ```powershell Test-NetConnection -ComputerName ``` ```powershell Test-NetConnection -ComputerName ``` ```powershell Test-NetConnection -ComputerName -Port ``` **Bewertung** | Gleiches VLAN | Gateway | Anderes VLAN | Eingrenzung | |---|---|---|---| | fehlerhaft | fehlerhaft | fehlerhaft | Access-VLAN, Layer-2-Pfad oder Client prüfen | | erfolgreich | fehlerhaft | fehlerhaft | Gateway-SVI, Trunk oder Gateway prüfen | | erfolgreich | erfolgreich | fehlerhaft | Routing, ACL oder Firewall prüfen | | erfolgreich | erfolgreich | erfolgreich | konkrete Anwendung oder Zielport prüfen | Ping kann durch eine Firewall blockiert werden. Für die Prüfung eines Dienstes ist zusätzlich der tatsächlich benötigte TCP- oder UDP-Port zu berücksichtigen. --- **21. Spanning-Tree-Zustand prüfen** Übersicht: ```text show spanning-tree ``` Bestimmtes VLAN: ```text show spanning-tree vlan 20 ``` Bestimmten Port: ```text show spanning-tree interface GigabitEthernet1/0/48 detail ``` Zu prüfen sind: - Root Bridge, - Root Port, - Designated Ports, - blockierende beziehungsweise verwerfende Ports, - Kosten und Prioritäten, - Topology Changes, - letzte Statusänderungen, - inkonsistente Ports, - unterschiedliche STP-Modi, - unerwartete Root Bridge. Ein durch Spanning Tree blockierter redundanter Port ist nicht automatisch fehlerhaft. Die Blockierung kann notwendig sein, um eine Layer-2-Schleife zu verhindern. Problematisch ist beispielsweise: - der einzige vorgesehene Pfad wird blockiert, - Root Bridge befindet sich unerwartet an einem Access-Switch, - Ports wechseln wiederholt ihren Zustand, - VLANs verwenden unbeabsichtigt unterschiedliche Pfade, - PVID- oder Type-Inconsistency wird gemeldet. --- **22. Spanning-Tree-Änderungen und Schleifen untersuchen** ```text show spanning-tree detail ``` Zusätzlich Systemprotokoll prüfen: ```text show logging ``` Hinweise auf mögliche Schleifen: - sehr viele Topology Changes, - MAC-Adresse wechselt zwischen Ports, - Broadcast- oder Multicast-Auslastung steigt stark, - Switchmanagement reagiert langsam, - mehrere Ports zeigen ungewöhnlich hohe Auslastung, - Netzwerk fällt periodisch aus, - STP-Root oder Root Port wechselt wiederholt. Die physische Schleife darf nicht durch dauerhaftes Deaktivieren von Spanning Tree „behoben“ werden. Dadurch kann die Störung massiv verschärft werden. --- **23. MAC-Flapping prüfen** Protokolle untersuchen: ```text show logging ``` MAC-Adresse gezielt suchen: ```text show mac address-table address ``` Wiederholt prüfen, ob der Port wechselt. Beispiel: ```text VLAN 20, MAC 0011.2233.4455: Gi1/0/47 -> Gi1/0/48 -> Gi1/0/47 ``` Mögliche Ursachen: - Layer-2-Schleife, - zwei aktive Verbindungen desselben Endgeräts ohne korrektes Teaming, - falsch aufgebauter EtherChannel, - nicht verwalteter Switch, - Bridge auf einem Client, - Hypervisor- oder Clusterkonfiguration, - absichtlich bewegte virtuelle MAC-Adresse, - Redundanzprotokoll. Ein MAC-Wechsel ist nicht immer ein Fehler. Bei Clustern oder Redundanzmechanismen kann eine virtuelle MAC kontrolliert den Port wechseln. Häufigkeit, Zeitpunkt und vorgesehene Architektur müssen berücksichtigt werden. --- **24. EtherChannel beziehungsweise Port-Channel prüfen** Übersicht: ```text show etherchannel summary ``` Port-Channel prüfen: ```text show interfaces Port-channel1 ``` Trunkstatus: ```text show interfaces trunk ``` Konfiguration der Mitglieder vergleichen: ```text show running-config interface GigabitEthernet1/0/47 ``` ```text show running-config interface GigabitEthernet1/0/48 ``` Zu prüfen sind: - gehören alle vorgesehenen Ports zum Channel, - sind die Ports tatsächlich gebündelt, - verwenden beide Seiten dasselbe Verfahren, - stimmen Access- oder Trunkmodus überein, - stimmen Native VLAN und Allowed-VLAN-Liste überein, - stimmen Geschwindigkeit und Duplex, - ist der Port-Channel durch STP freigegeben, - sind einzelne Mitglieder suspendiert oder eigenständig aktiv? **Typische Fehler** - ein Link ist nicht im Bundle, - LACP ist nur auf einer Seite passend konfiguriert, - Mitglieder besitzen unterschiedliche VLAN-Listen, - physische Ports werden einzeln statt über den Port-Channel konfiguriert, - ein paralleler Link bildet unbeabsichtigt eine Schleife. --- **25. Port-Security prüfen** Auf Cisco-Switches beispielsweise: ```text show port-security ``` Gezielter Port: ```text show port-security interface GigabitEthernet1/0/12 ``` Portstatus: ```text show interfaces status err-disabled ``` Zu prüfen sind: - ist Port-Security aktiviert, - wie viele MAC-Adressen sind erlaubt, - welche MAC-Adressen wurden gelernt, - liegt eine Verletzung vor, - welche Reaktion wurde ausgelöst, - wurde der Port deaktiviert, - wurde ein anderes Endgerät oder Dock angeschlossen? **Typisches Fehlerbild** Ein Arbeitsplatz wird von einem PC auf eine Dockingstation umgestellt. Dadurch erscheint eine neue MAC-Adresse. Wenn nur eine bestimmte MAC zugelassen ist, kann der Port den Verkehr verwerfen oder in einen Fehlerzustand wechseln. Port-Security darf nicht pauschal deaktiviert werden. Zuerst sind vorgesehene Sicherheitsrichtlinie, erlaubte Geräte und tatsächlich erkannte MAC-Adressen zu prüfen. --- **26. Weitere Schutzfunktionen berücksichtigen** Abhängig von der Umgebung können unter anderem beteiligt sein: - 802.1X, - MAC Authentication Bypass, - Dynamic VLAN Assignment, - DHCP Snooping, - Dynamic ARP Inspection, - IP Source Guard, - BPDU Guard, - Root Guard, - Loop Guard, - Storm Control, - Private VLANs, - Port-Isolation, - Access Control Lists, - Network Access Control. Mögliche Prüfungen auf Cisco-Geräten: ```text show authentication sessions ``` ```text show dot1x all ``` ```text show ip dhcp snooping ``` ```text show ip arp inspection ``` ```text show interfaces status err-disabled ``` ```text show logging ``` Die tatsächlich verfügbaren Befehle hängen von Plattform und Softwareversion ab. **Typische Fehlerbilder** | Beobachtung | Mögliche Funktion | |---|---| | Port erhält nach Anmeldung anderes VLAN | 802.1X oder dynamische VLAN-Zuweisung | | DHCP-Antworten werden verworfen | DHCP Snooping | | ARP-Pakete werden verworfen | Dynamic ARP Inspection | | Port nach Anschluss eines Switches deaktiviert | BPDU Guard | | Datenverkehr oberhalb eines Grenzwerts verworfen | Storm Control | | Clients im gleichen VLAN sehen sich nicht | Port-Isolation oder Private VLAN | | nur autorisierte MAC funktioniert | Port-Security oder NAC | --- **27. `err-disabled`-Ursache untersuchen** ```text show interfaces status err-disabled ``` ```text show errdisable recovery ``` ```text show logging ``` Je nach Plattform können Ursachen sein: - BPDU Guard, - Port-Security, - Link-Flapping, - EtherChannel-Fehlkonfiguration, - UDLD, - Loopback-Erkennung, - DHCP-Ratenbegrenzung, - Sicherheitsverletzung. Der Port darf nicht einfach wieder aktiviert werden, ohne die Ursache zu beseitigen. Andernfalls tritt der Fehler erneut auf oder eine Schleife wird wieder in Betrieb genommen. Kontrollierte Wiederaktivierung erst nach Ursachenklärung: ```text interface shutdown no shutdown ``` Dieser Eingriff verändert den Zustand und unterbricht die Verbindung. Er darf nur autorisiert und nach Sicherung der Diagnoseinformationen erfolgen. --- **28. Paketmitschnitt für VLAN-Tags verwenden** Ein Paketmitschnitt kann zeigen: - ob Frames VLAN-Tags besitzen, - welche VLAN-ID verwendet wird, - ob ARP-Anfragen gesendet werden, - ob ARP-Antworten zurückkommen, - ob DHCP Discover und Offer sichtbar sind, - ob nur eine Richtung des Verkehrs vorhanden ist, - ob LLDP- oder STP-Informationen auftreten. Wireshark-Anzeigefilter für VLAN-Verkehr: ```text vlan ``` Bestimmte VLAN-ID: ```text vlan.id == 20 ``` ARP: ```text arp ``` DHCP: ```text dhcp ``` LLDP: ```text lldp ``` STP: ```text stp ``` **Wichtig** Ein Endgerät an einem normalen Access-Port sieht üblicherweise keine IEEE-802.1Q-Tags für sein Access-VLAN. Der Switch fügt die VLAN-Zuordnung intern hinzu beziehungsweise entfernt das Tag am Access-Port. Für eine aussagekräftige Analyse auf einem Switch kann ein kontrolliert konfigurierter Mirror- oder SPAN-Port erforderlich sein. Mitschnitte dürfen nur autorisiert erfolgen und können vertrauliche Daten, Adressen, Namen und Anmeldeinformationen enthalten. Netzwerkkarten und Treiber können VLAN-Tags vor der Übergabe an die Aufzeichnungssoftware verarbeiten. Das Fehlen eines sichtbaren Tags beweist daher nicht in jedem Mitschnitt, dass auf dem beobachteten Netzwerkpfad kein Tag verwendet wurde. --- **29. Beispiel für eine systematische Diagnose** **Symptom** Ein Client erhält keine Verbindung zu internen Diensten. Andere Clients am gleichen Switch funktionieren. **Sollzustand** ```text Clientport: GigabitEthernet1/0/12 Access-VLAN: 20 Gateway: 192.0.2.1 Uplink: GigabitEthernet1/0/48 ``` **Clientprüfung** ```cmd ipconfig /all ``` Ergebnis: ```text IPv4-Adresse: 192.0.2.45 Gateway: 192.0.2.1 ``` **Portprüfung** ```text show interfaces GigabitEthernet1/0/12 switchport ``` Ergebnis: ```text Operational Mode: static access Access Mode VLAN: 20 ``` **MAC-Prüfung** ```text show mac address-table address 0011.2233.4455 ``` Ergebnis: ```text VLAN 20 0011.2233.4455 DYNAMIC Gi1/0/12 ``` Der Client wird am richtigen lokalen Port und im richtigen VLAN gelernt. **Trunkprüfung** ```text show interfaces trunk ``` Ergebnis am Access-Switch: ```text Port Gi1/0/48 Allowed VLANs: 10,20,30 ``` Ergebnis am Distribution-Switch: ```text Port Gi1/0/48 Allowed VLANs: 10,30 ``` **Festgestellte Ursache** VLAN 20 war auf der Distribution-Seite des Trunks nicht zugelassen. Dadurch wurde die Client-MAC am Access-Switch gelernt, der Datenverkehr erreichte jedoch nicht das Gateway. **Kontrollierte Maßnahme** Nach Prüfung des Sollzustands und Sicherung der Konfiguration wurde VLAN 20 auf der fehlenden Trunkseite ergänzt. **Nachprüfung** Auf beiden Switches: ```text show interfaces trunk ``` Ergebnis: ```text Allowed VLANs: 10,20,30 ``` MAC-Adresse auf dem Distribution-Switch: ```text show mac address-table address 0011.2233.4455 ``` Ergebnis: ```text VLAN 20 0011.2233.4455 DYNAMIC Gi1/0/48 ``` Clienttest: ```powershell Test-NetConnection -ComputerName 192.0.2.1 ``` Der Client erreicht anschließend das Gateway und die vorgesehenen Dienste. --- **30. Beispiel „Port sieht korrekt aus, Client ist trotzdem im falschen VLAN“** **Symptom** Der Client ist an Port `GigabitEthernet1/0/12` dokumentiert. Die Prüfung dieses Ports zeigt das richtige VLAN. Der Client erhält trotzdem eine Adresse aus einem anderen Subnetz. **Prüfung der MAC-Adresse** ```text show mac address-table address 0011.2233.4455 ``` Ergebnis: ```text VLAN 30 0011.2233.4455 DYNAMIC Gi1/0/18 ``` **Festgestellte Ursache** Der Client war physisch an Port `GigabitEthernet1/0/18` angeschlossen. Die Dokumentation war veraltet. Port 18 gehörte zu VLAN 30. **Lehre** Nicht nur den dokumentierten Port prüfen. Der tatsächliche Port muss anhand von MAC-Adresse, LLDP/CDP, Verkabelung oder Portstatus bestätigt werden. --- **31. Ungeeignete Sofortmaßnahmen** Nicht als erste Maßnahme verwenden: - Switch ohne Diagnose neu starten, - Portkonfiguration vollständig löschen, - VLAN vorschnell neu anlegen, - alle VLANs auf jedem Trunk erlauben, - Native VLAN wahllos auf VLAN 1 setzen, - Spanning Tree deaktivieren, - blockierte STP-Ports ungeprüft freigeben, - EtherChannel auflösen, - Port-Security pauschal deaktivieren, - 802.1X oder NAC umgehen, - BPDU Guard deaktivieren, - DHCP Snooping oder ARP Inspection deaktivieren, - MAC-Tabelle vor der Dokumentation vollständig löschen, - alle Schnittstellen gleichzeitig zurücksetzen, - redundante Links abziehen, ohne die Topologie zu prüfen, - Firewall oder ACL als vermeintlichen VLAN-Test deaktivieren, - mehrere Konfigurationsänderungen gleichzeitig durchführen, - ausschließlich mit `ping` testen, - einen erreichbaren Switch mit einem funktionierenden VLAN-Pfad gleichsetzen. Solche Maßnahmen können Diagnoseinformationen beseitigen, Sicherheitsgrenzen verändern oder eine Layer-2-Schleife verursachen. --- **32. Vollständige Schnellprüfreihenfolge** 1. genaue Störung, Zeitpunkt und Auswirkung dokumentieren. 2. feststellen, ob ein oder mehrere Clients betroffen sind. 3. vorgesehenes VLAN, Subnetz und Gateway ermitteln. 4. tatsächliche Client-MAC-Adresse feststellen. 5. tatsächlichen Switch und Port ermitteln. 6. physischen Linkstatus prüfen. 7. Fehlerzähler dokumentieren. 8. Portmodus prüfen. 9. Access- und Voice-VLAN prüfen. 10. Existenz und Status des VLANs prüfen. 11. Client-MAC in der MAC-Tabelle suchen. 12. MAC-Adresse über alle beteiligten Switches verfolgen. 13. jeden Uplink und Trunk ermitteln. 14. operativen Trunkstatus prüfen. 15. Allowed-VLAN-Listen auf beiden Seiten vergleichen. 16. Native VLAN auf beiden Seiten vergleichen. 17. VLAN-Existenz auf jedem Switch prüfen. 18. Spanning-Tree-Zustand für das betroffene VLAN prüfen. 19. blockierte oder inkonsistente Ports untersuchen. 20. Topology Changes und MAC-Flapping prüfen. 21. EtherChannel und seine Mitglieder prüfen. 22. Port-Security und `err-disabled` prüfen. 23. 802.1X, NAC und dynamische VLAN-Zuweisung berücksichtigen. 24. DHCP Snooping, ARP Inspection und IP Source Guard prüfen. 25. Gateway-SVI und dessen Status prüfen. 26. ARP- beziehungsweise Neighbor-Einträge untersuchen. 27. Kommunikation im gleichen VLAN testen. 28. Gateway separat testen. 29. Inter-VLAN-Kommunikation separat testen. 30. bei Bedarf autorisierten Paketmitschnitt durchführen. 31. genau eine Hypothese formulieren. 32. genau eine kontrollierte Maßnahme durchführen. 33. Port-, VLAN-, Trunk-, STP- und MAC-Zustand erneut prüfen. 34. Clientverbindung und benötigten Dienst erneut testen. 35. Ursache, Änderung und Nachweis dokumentieren. --- **33. Checkliste VLAN und Switching** - [ ] genaue Fehlermeldung wurde dokumentiert. - [ ] Zeitpunkt der Störung ist bekannt. - [ ] Umfang der Störung wurde bestimmt. - [ ] vorgesehenes Client-VLAN ist bekannt. - [ ] vorgesehenes IP-Subnetz ist bekannt. - [ ] vorgesehenes Gateway ist bekannt. - [ ] tatsächliche Client-MAC-Adresse wurde ermittelt. - [ ] tatsächlicher Switch wurde ermittelt. - [ ] tatsächlicher Switchport wurde ermittelt. - [ ] physischer Linkstatus wurde geprüft. - [ ] Geschwindigkeit und Duplex wurden geprüft. - [ ] Fehlerzähler wurden dokumentiert. - [ ] Link-Flapping wurde berücksichtigt. - [ ] administrativer Portmodus wurde geprüft. - [ ] operativer Portmodus wurde geprüft. - [ ] Access-VLAN wurde geprüft. - [ ] Voice-VLAN wurde bei Bedarf geprüft. - [ ] clientseitiges VLAN-Tagging wurde berücksichtigt. - [ ] VLAN existiert auf dem Access-Switch. - [ ] VLAN ist aktiv. - [ ] Client-MAC wird gelernt. - [ ] MAC erscheint im richtigen VLAN. - [ ] MAC erscheint am erwarteten Port. - [ ] MAC wurde über den vollständigen Switchpfad verfolgt. - [ ] alle beteiligten Uplinks wurden ermittelt. - [ ] Trunkstatus wurde auf beiden Seiten geprüft. - [ ] Allowed-VLAN-Listen wurden verglichen. - [ ] Native VLAN wurde auf beiden Seiten geprüft. - [ ] VLAN existiert auf jedem beteiligten Switch. - [ ] Spanning Tree wurde für das betroffene VLAN geprüft. - [ ] Root Bridge und Root Port wurden geprüft. - [ ] blockierte Ports wurden bewertet. - [ ] STP-Inkonsistenzen wurden berücksichtigt. - [ ] Topology Changes wurden geprüft. - [ ] MAC-Flapping wurde berücksichtigt. - [ ] EtherChannel wurde geprüft. - [ ] Konfiguration der Channel-Mitglieder wurde verglichen. - [ ] Port-Security wurde geprüft. - [ ] `err-disabled` wurde geprüft. - [ ] 802.1X und NAC wurden berücksichtigt. - [ ] DHCP Snooping wurde berücksichtigt. - [ ] Dynamic ARP Inspection wurde berücksichtigt. - [ ] Gateway-SVI wurde geprüft. - [ ] ARP- beziehungsweise Neighbor Cache wurde geprüft. - [ ] Ziel im gleichen VLAN wurde getestet. - [ ] Gateway wurde getestet. - [ ] Ziel in einem anderen VLAN wurde getestet. - [ ] Layer-2- und Layer-3-Fehler wurden getrennt. - [ ] vor Änderungen wurde der Ausgangszustand gesichert. - [ ] nur eine kontrollierte Änderung wurde durchgeführt. - [ ] ursprüngliche Prüfungen wurden anschließend wiederholt. - [ ] temporäre Diagnoseänderungen wurden entfernt. - [ ] Ursache, Maßnahme und Nachweis wurden dokumentiert. --- **34. Schnellreferenz** | Ergebnis | Nächster Schritt | |---|---| | Port ist `notconnect` | Kabel, Client, Transceiver und Gegenstelle prüfen | | Port ist `err-disabled` | genaue Schutz- oder Fehlerursache ermitteln | | viele neue CRC-Fehler | physischen Pfad und Aushandlung prüfen | | Client erhält falsches Subnetz | Access-VLAN, dynamische VLAN-Zuweisung und DHCP prüfen | | MAC fehlt vollständig | tatsächlichen Port, Clientübertragung und Link prüfen | | MAC erscheint im falschen VLAN | Access-, Voice- oder Client-Tagging prüfen | | MAC erscheint am falschen Port | Verkabelung, Dokumentation oder Schleife prüfen | | MAC wechselt zwischen Ports | Schleife, Teaming, Cluster oder EtherChannel prüfen | | VLAN fehlt auf einem Switch | vorgesehene VLAN-Bereitstellung prüfen | | VLAN fehlt in Allowed-Liste | Trunkkonfiguration auf beiden Seiten vergleichen | | Native VLAN unterscheidet sich | Mismatch kontrolliert korrigieren | | Trunk nur auf einer Seite aktiv | Portmodus und Aushandlung prüfen | | nur ein VLAN über Trunk gestört | VLAN-Existenz, Allowed-Liste und STP prüfen | | alle VLANs über Uplink gestört | Link, Trunk, EtherChannel und Hardware prüfen | | STP blockiert redundanten Port | prüfen, ob Blockierung vorgesehen ist | | STP meldet PVID-Inkonsistenz | Native VLAN und Portmodi vergleichen | | viele Topology Changes | Schleife, instabilen Link oder Root-Wechsel suchen | | gleicher VLAN-Verkehr funktioniert | Layer-2-Pfad grundsätzlich vorhanden | | Gateway nicht per ARP erreichbar | VLAN-Pfad, Trunk und SVI prüfen | | Gateway erreichbar, andere VLANs nicht | Routing, ACL oder Firewall prüfen | | Telefon funktioniert, PC nicht | Data-VLAN und PC-Port des Telefons prüfen | | PC funktioniert, Telefon nicht | Voice-VLAN, LLDP/CDP und Voice-DHCP prüfen | | nur ein EtherChannel-Mitglied aktiv | LACP und Mitgliedskonfiguration vergleichen | | Paketmitschnitt zeigt falsche VLAN-ID | Taggingquelle und Portmodus prüfen | | Paketmitschnitt zeigt am Access-Port kein Tag | kann bei einem Access-Port normal sein | --- **Merksatz** > Bei VLAN- und Switching-Fehlern wird der Datenpfad nicht erraten, sondern anhand von Portstatus, VLAN-Zuordnung, MAC-Adresse, Trunk, Spanning Tree und Gateway Schritt für Schritt verfolgt. Ein VLAN funktioniert erst dann, wenn es auf jedem beteiligten Switch vorhanden, auf jedem Trunk zugelassen und über einen freigegebenen Layer-2-Pfad bis zum vorgesehenen Gateway transportiert wird. --- **Quellen und weiterführende Dokumentation** - [Cisco – Configure VLANs on Catalyst Switches](https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst9600/software/release/17-14/configuration_guide/vlan/b_1714_vlan_9600_cg/configuring_vlans.html) - [Cisco – Configuring VLAN Trunks](https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst9400/software/release/17-14/configuration_guide/vlan/b_1714_vlan_9400_cg/configuring_vlan_trunks.html) - [Cisco – Configure and Troubleshoot Inter-VLAN Routing](https://www.cisco.com/c/en/us/support/docs/lan-switching/inter-vlan-routing/41260-189.html) - [Cisco – Troubleshoot LAN Switching Environments](https://www.cisco.com/c/en/us/support/docs/lan-switching/ethernet/12006-chapter22.html) - [Cisco – Troubleshoot Spanning Tree Issues](https://www.cisco.com/c/en/us/support/docs/lan-switching/spanning-tree-protocol/28943-170.html) - [Cisco – Troubleshoot Spanning Tree PVID and Type Inconsistencies](https://www.cisco.com/c/en/us/support/docs/lan-switching/spanning-tree-protocol/24063-pvid-inconsistency-24063.html) - [Cisco – Troubleshoot MAC Flaps and Loops](https://www.cisco.com/c/en/us/support/docs/lan-switching/spanning-tree-protocol-stp-8021d/221722-troubleshoot-mac-flaps-loop-on-cisco-cat.html) - [Cisco – Understand Rapid Spanning Tree Protocol](https://www.cisco.com/c/en/us/support/docs/lan-switching/spanning-tree-protocol/24062-146.html) - [Cisco – IOS LAN Switching Command Reference](https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/lanswitch/command/lsw-cr-book/lsw-s2.html) - [Microsoft Learn – Get-NetAdapter](https://learn.microsoft.com/en-us/powershell/module/netadapter/get-netadapter) - [Microsoft Learn – Get-NetIPConfiguration](https://learn.microsoft.com/en-us/powershell/module/nettcpip/get-netipconfiguration) - [Microsoft Learn – Get-NetIPAddress](https://learn.microsoft.com/en-us/powershell/module/nettcpip/get-netipaddress) - [Microsoft Learn – Get-NetNeighbor](https://learn.microsoft.com/en-us/powershell/module/nettcpip/get-netneighbor) - [Microsoft Learn – Test-NetConnection](https://learn.microsoft.com/en-us/powershell/module/nettcpip/test-netconnection) - [Wireshark – IEEE 802.1Q VLAN Display Filter Reference](https://www.wireshark.org/docs/dfref/v/vlan.html) - [Wireshark – VLAN Capture Setup](https://wiki.wireshark.org/CaptureSetup/VLAN) - [Wireshark – PCAP Filter Reference](https://www.wireshark.org/docs/man-pages/pcap-filter.html) # 7.5 Netzwerk ist langsam Ein langsames Netzwerk liegt vor, wenn benötigte Daten oder Anwendungen zwar grundsätzlich erreichbar sind, die tatsächliche Leistung jedoch deutlich unter dem vorgesehenen oder bisher üblichen Niveau liegt. „Langsam“ ist zunächst nur eine subjektive Wahrnehmung. Für eine belastbare Diagnose muss das Verhalten durch Messwerte wie Antwortzeit, Paketverlust, Jitter, Durchsatz, Fehlerzähler oder Serverauslastung beschrieben werden. --- **Kurzbeschreibung** Die Ursache kann auf unterschiedlichen Ebenen liegen: - Client oder Netzwerkkarte, - Kabel, Switchport oder Transceiver, - WLAN-Verbindung, - überlasteter Uplink, - Routingpfad, - Firewall, VPN oder Proxy, - WAN- beziehungsweise Internetanbindung, - fehlerhafte MTU, - TCP-Wiederholungen, - Server, Anwendung oder Datenspeicher, - allgemeine Überlastung zu bestimmten Zeiten. Ein erfolgreicher Ping beweist lediglich eine grundsätzliche IP-Erreichbarkeit. Er beweist weder einen ausreichenden Datendurchsatz noch eine fehlerfreie Anwendung oder einen leistungsfähigen Server. --- **Typische Symptome** - Webseiten oder Anwendungen öffnen sich verzögert. - Dateiübertragungen erreichen nur einen geringen Durchsatz. - Netzlaufwerke reagieren langsam. - Remote-Sitzungen stocken. - Sprache oder Video weisen Aussetzer auf. - Downloads sind schnell, Uploads jedoch langsam. - Kleine Dateien funktionieren, große Übertragungen brechen ein. - Nur WLAN-Clients sind betroffen. - Nur ein bestimmter Client ist betroffen. - Mehrere Benutzer sind gleichzeitig betroffen. - Nur ein Server oder Dienst reagiert langsam. - Die Störung tritt nur während bestimmter Uhrzeiten auf. - Die Verbindung beginnt schnell und wird anschließend langsamer. - Ping funktioniert, die Anwendung benötigt trotzdem lange. - Über VPN ist die Verbindung langsamer als im lokalen Netzwerk. - Die Leistung schwankt stark. --- **Mögliche Auswirkungen** - verlängerte Arbeitsabläufe, - Abbrüche bei Dateiübertragungen, - schlechte Sprach- und Videoqualität, - Zeitüberschreitungen in Anwendungen, - verzögerte Datenbankabfragen, - Probleme bei Backups und Synchronisationen, - unvollständige Softwareverteilung, - sinkende Produktivität, - erhöhte Belastung durch wiederholte Übertragungen, - Ausfall zeitkritischer Dienste. --- **Sicherheits- und Betriebswarnung** Leistungsprüfungen können selbst erhebliche Netzlast verursachen. Insbesondere `iperf3`, große Dateiübertragungen, parallele Verbindungen und UDP-Tests dürfen nur kontrolliert und autorisiert eingesetzt werden. Vor Veränderungen müssen dokumentiert werden: - Ausgangszustand, - Messzeitpunkt, - betroffene Systeme, - aktuelle Konfiguration, - aktuelle Fehlerzähler, - bestehende Auslastung, - verwendeter Testpfad, - erwarteter Sollwert. Nicht mehrere Einstellungen gleichzeitig verändern. Sonst lässt sich nicht mehr eindeutig feststellen, welche Änderung das Ergebnis beeinflusst hat. --- **1. Die Aussage „langsam“ messbar machen** Zuerst muss das genaue Verhalten beschrieben werden. Zu klären sind: - Welche Anwendung oder Übertragung ist langsam? - Seit wann besteht die Störung? - Ist sie dauerhaft oder zeitabhängig? - Welche Leistung wird erwartet? - Welche Leistung wird tatsächlich erreicht? - Betrifft es Upload, Download oder beide Richtungen? - Sind kleine und große Dateien gleichermaßen betroffen? - Tritt die Störung lokal, über VPN oder über das Internet auf? - Besteht das Problem über Ethernet, WLAN oder beide Zugangsarten? - Funktionierte der gleiche Vorgang früher schneller? - Existieren ältere Messwerte als Vergleich? **Ungeeignete Beschreibung** ```text Das Netzwerk ist langsam. ``` **Geeignete Beschreibung** ```text Dateiübertragungen vom Client 192.0.2.45 zum Server 192.0.2.80 erreichen seit 14:00 Uhr nur noch etwa 35 Mbit/s. Bisheriger Vergleichswert: ungefähr 850 Mbit/s Clientanschluss: 1 Gbit/s Ethernet Andere Clients: nicht betroffen Ping zum Server: durchschnittlich 1 ms ``` Erst die zweite Beschreibung ermöglicht eine gezielte Eingrenzung. --- **2. Umfang der Störung bestimmen** | Beobachtung | Wahrscheinlicher Prüfbereich | |---|---| | nur ein Client betroffen | Client, Netzwerkkarte, Kabel, Switchport oder lokale Software | | alle Clients eines Switches betroffen | Uplink, Switch, VLAN, Spanning Tree oder Überlastung | | nur WLAN-Clients betroffen | Funkversorgung, Kanalbelegung, SNR, Access Point oder WLAN-Uplink | | alle Clients eines Standorts betroffen | Standort-Uplink, Firewall, Router oder WAN | | nur ein Zielserver betroffen | Server, Anwendung, Storage oder Serveranschluss | | nur externe Ziele betroffen | Internetanschluss, WAN, Firewall, Proxy oder Provider | | nur VPN-Verkehr betroffen | VPN-Gateway, Verschlüsselungsleistung, MTU oder Tunnelpfad | | nur zu bestimmten Uhrzeiten | Backup, Synchronisation, Scan, Update oder planmäßige Last | | nur Upload langsam | asymmetrische Auslastung, Rückweg, Duplex, Provider oder Traffic Shaping | | nur große Übertragungen langsam | Paketverlust, TCP, MTU, Storage oder Überlastung | Zum Vergleich möglichst denselben Vorgang durchführen: - auf einem zweiten Client, - am gleichen Switch, - an einem anderen Switch, - über Ethernet statt WLAN, - innerhalb desselben VLANs, - zu einem anderen Server, - ohne VPN, sofern der vorgesehene Test dies erlaubt. Dabei darf keine Sicherheitskontrolle umgangen werden. --- **3. Sollleistung richtig bestimmen** Die angezeigte Verbindungsgeschwindigkeit ist nicht mit dem nutzbaren Anwendungsdurchsatz gleichzusetzen. ```text Linkgeschwindigkeit ≠ tatsächlicher Datendurchsatz ``` Bei einer Ethernet-Verbindung mit `1 Gbit/s` ist der nutzbare Durchsatz aufgrund von Protokoll- und Verwaltungsdaten geringer. Zusätzlich können beteiligt sein: - Ethernet-Header, - IP-Header, - TCP- oder UDP-Header, - Verschlüsselung, - Anwendungsoverhead, - Dateisystem, - Storage, - Latenz, - Paketverlust, - konkurrierender Datenverkehr. Auch Einheiten müssen unterschieden werden: ```text 1 Byte = 8 Bit ``` Beispiel: ```text 100 MB/s × 8 = 800 Mbit/s ``` Eine Anwendung, die `100 MB/s` anzeigt, überträgt somit ungefähr `800 Mbit/s`, bevor zusätzlicher Protokolloverhead berücksichtigt wird. --- **4. Client und verwendeten Netzwerkadapter prüfen** Unter Windows: ```powershell Get-NetAdapter | Format-Table Name, InterfaceDescription, Status, LinkSpeed, MacAddress ``` Ausführliche IP-Konfiguration: ```powershell Get-NetIPConfiguration ``` Aktive IP-Adressen: ```powershell Get-NetIPAddress ``` Unter Linux: ```bash ip link show ``` ```bash ip address show ``` Unter macOS: ```bash ifconfig ``` Zu prüfen sind: - richtiger Netzwerkadapter aktiv, - erwartete Linkgeschwindigkeit, - zusätzlicher WLAN- oder Ethernet-Adapter, - VPN-Adapter, - virtuelle Netzwerkkarten, - Dockingstation, - USB-Netzwerkadapter, - Bridge, - Hypervisor oder Containernetzwerk, - Energiesparzustand, - aktueller Netzwerkkartentreiber. Ein Client kann gleichzeitig mehrere aktive Adapter besitzen. Der tatsächlich verwendete Pfad muss anhand von Routingtabelle, Quelladresse und Schnittstelle bestätigt werden. Unter Windows: ```powershell Get-NetRoute -AddressFamily IPv4 | Sort-Object RouteMetric | Format-Table DestinationPrefix, NextHop, InterfaceAlias, RouteMetric ``` --- **5. Linkgeschwindigkeit und Duplex prüfen** Unter Windows: ```powershell Get-NetAdapter | Format-Table Name, Status, LinkSpeed ``` Auf Cisco-IOS-/IOS-XE-Switches beispielsweise: ```text show interfaces status ``` Gezielter Port: ```text show interfaces GigabitEthernet1/0/12 ``` Zu prüfen sind: - ausgehandelte Geschwindigkeit, - Duplexmodus, - administrative Einstellungen, - operativer Zustand, - Übereinstimmung beider Seiten, - unerwarteter Rückfall auf `100 Mbit/s`, - Halbduplex statt Vollduplex, - Link-Flapping. **Typisches Fehlerbild** ```text Erwartet: 1 Gbit/s Full Duplex Tatsächlich: 100 Mbit/s ``` Mögliche Ursachen: - beschädigtes oder ungeeignetes Kabel, - fehlerhafte Ader oder Steckverbindung, - problematische Dockingstation, - defekter Switchport, - Transceiverproblem, - manuell erzwungene Geschwindigkeit, - fehlerhafte Aushandlung, - Netzwerkkartentreiber. Bei einem Duplex-Mismatch können extrem niedrige Leistung, Verbindungsunterbrechungen und Fehlerzähler auftreten. Geschwindigkeit und Duplex dürfen nicht nur auf einer Seite verändert werden. Beide Seiten müssen kompatibel konfiguriert sein. Normalerweise wird die automatische Aushandlung verwendet, sofern Geräte- und Betriebsvorgaben nichts anderes verlangen. --- **6. Fehler- und Verwerfungszähler prüfen** Unter Windows: ```powershell Get-NetAdapterStatistics ``` Alle verfügbaren Werte eines Adapters: ```powershell Get-NetAdapterStatistics -Name "Ethernet" | Format-List * ``` Unter Linux: ```bash ip -s link show ``` Alternativ, sofern vorhanden: ```bash ethtool -S ``` Auf Cisco-Switches: ```text show interfaces GigabitEthernet1/0/12 ``` Kurze Fehlerübersicht: ```text show interfaces counters errors ``` Zu prüfen sind: - CRC- beziehungsweise FCS-Fehler, - Input Errors, - Output Errors, - Discards, - Drops, - Runts, - Giants, - Frame Errors, - Kollisionen, - Late Collisions, - Interface Resets, - Queue Drops. **Bewertung** | Zähler | Mögliche Ursache | |---|---| | zunehmende CRC-/FCS-Fehler | Kabel, Stecker, Transceiver oder physische Störung | | Late Collisions | möglicher Duplex-Mismatch | | Input Discards | Überlastung, Puffer oder Filterung | | Output Drops | Ausgangswarteschlange oder überlasteter Folgelink | | Interface Resets | instabiler Link, Treiber oder Hardware | | Runts oder Giants | fehlerhafte Frames, MTU oder physische Störung | | keine Fehler, aber geringe Leistung | Auslastung, TCP, Server, Storage oder Anwendung prüfen | Zähler zuerst dokumentieren und später erneut ablesen. ```text Ausgangswert: 12 CRC-Fehler Nach 10 Minuten: 12 CRC-Fehler ``` Der Wert ist historisch vorhanden, steigt während des Tests jedoch nicht. ```text Ausgangswert: 12 CRC-Fehler Nach 10 Minuten: 4.850 CRC-Fehler ``` Der Fehler besteht weiterhin und muss untersucht werden. --- **7. Latenz, Schwankung und Paketverlust messen** Windows: ```cmd ping -n 20 ``` Mit festgelegter Paketgröße: ```cmd ping -n 20 -l 1400 ``` Linux: ```bash ping -c 20 ``` macOS: ```bash ping -c 20 ``` Zu dokumentieren sind: - Minimum, - Maximum, - Durchschnitt, - Paketverlust, - starke Abweichungen einzelner Antworten, - Unterschiede zu einem Referenzwert. **Beispiel** ```text Minimum: 1 ms Maximum: 85 ms Durchschnitt: 4 ms Paketverlust: 0 % ``` Der Durchschnitt wirkt niedrig, einzelne starke Ausschläge können für Sprache, Video oder interaktive Anwendungen dennoch relevant sein. **Wichtig** Ein Ping verwendet ICMP. Netzwerkgeräte können ICMP: - blockieren, - begrenzen, - verzögert beantworten, - niedriger priorisieren. Paketverlust oder hohe Antwortzeiten an einem einzelnen Zwischenrouter beweisen daher noch keine Störung des weitergeleiteten Nutzverkehrs. --- **8. Stufenweise unterschiedliche Ziele testen** Die Messung sollte vom nahen zum entfernten Ziel erfolgen: 1. eigenes TCP/IP-System, 2. Standardgateway, 3. Ziel im gleichen VLAN, 4. Ziel in einem anderen internen VLAN, 5. interner Server, 6. externes Ziel. Beispiel: ```cmd ping -n 20 ``` ```cmd ping -n 20 ``` ```cmd ping -n 20 ``` **Bewertung** | Gateway | Lokaler Server | Entferntes Ziel | Eingrenzung | |---|---|---|---| | langsam | langsam | langsam | Client, Zugang, Switchport oder lokales Netz | | schnell | langsam | langsam | interner Pfad ab Gateway oder Servernetz | | schnell | schnell | langsam | WAN, Internet, VPN oder entfernter Standort | | überall schnell | Anwendung langsam | Anwendung oder Server genauer prüfen | Verglichen werden müssen Messungen vom selben Client und möglichst zum selben Zeitpunkt. --- **9. Netzwerkpfad ermitteln** Unter Windows: ```cmd tracert -d ``` ```cmd pathping -n ``` PowerShell: ```powershell Test-NetConnection -ComputerName -TraceRoute ``` Unter Linux: ```bash traceroute -n ``` Alternativ, sofern vorhanden: ```bash mtr -n ``` Unter macOS: ```bash traceroute -n ``` `pathping` kombiniert eine Pfadermittlung mit wiederholten ICMP-Messungen. Die Ausführung benötigt einige Zeit. Zu prüfen sind: - unerwartete Route, - zusätzlicher VPN- oder Proxy-Pfad, - ungewöhnlich viele Hops, - Wechsel des Pfades, - erhöhte Latenz ab einem bestimmten Segment, - Unterschiede zwischen funktionierendem und betroffenem Client. **Vorsicht bei der Bewertung** Wenn ein Zwischenrouter ICMP nicht beantwortet, nachfolgende Ziele aber normal erreichbar sind, ist der Zwischenrouter nicht automatisch ausgefallen. Für die Eingrenzung ist entscheidend, ob sich die Verschlechterung bis zum Ziel fortsetzt. --- **10. Tatsächlichen Durchsatz mit `iperf3` messen** `iperf3` misst die erreichbare Netzwerkleistung zwischen einem Server und einem Client. Dadurch lässt sich der reine Netzwerkpfad besser von Dateiablage, Anwendung und Datenträger trennen. Auf einem autorisierten Testsystem: ```bash iperf3 -s ``` Auf dem Client: ```bash iperf3 -c ``` Längere Messung: ```bash iperf3 -c -t 30 ``` Umgekehrte Richtung: ```bash iperf3 -c -R ``` Mehrere parallele Datenströme: ```bash iperf3 -c -P 4 ``` Bidirektionaler Test, sofern von der verwendeten Version unterstützt: ```bash iperf3 -c --bidir ``` UDP-Test nur mit kontrollierter Bandbreite: ```bash iperf3 -c -u -b 100M -t 20 ``` **Wichtige Werte** - gemessener Durchsatz, - Retransmissions bei TCP, - Paketverlust bei UDP, - Jitter bei UDP, - Unterschied zwischen Sende- und Empfangsrichtung, - Schwankungen zwischen den Messintervallen. **Bewertung** | Ergebnis | Eingrenzung | |---|---| | `iperf3` schnell, Dateiübertragung langsam | Serverdienst, Protokoll oder Storage prüfen | | `iperf3` ebenfalls langsam | Netzwerkpfad, Client oder Gegenstelle prüfen | | normale Richtung schnell, `-R` langsam | richtungsabhängige Störung untersuchen | | ein Datenstrom langsam, mehrere schnell | Latenz, TCP-Fenster oder einzelne Flussbegrenzung prüfen | | UDP zeigt Verlust oder hohen Jitter | Überlastung, WLAN oder Warteschlangen untersuchen | Mehrere parallele Datenströme können Engpässe verdecken oder zusätzliche Last erzeugen. Sie ersetzen nicht den normalen Einzelstromtest. Die ESnet-Dokumentation unterstützt `iperf3` offiziell hauptsächlich unter Linux, FreeBSD und macOS. Unter Windows verwendete Builds können von Drittanbietern stammen und müssen gesondert bewertet werden. --- **11. Messung innerhalb einzelner Segmente durchführen** Der End-to-End-Pfad sollte in Abschnitte unterteilt werden. ```text Client | Access-Switch | Distribution-Switch | Firewall oder Router | WAN oder Internet | Zielserver ``` Mögliche Vergleichsmessungen: ```text Client -> lokaler Testserver Client -> Server im anderen VLAN Client -> Server hinter der Firewall Client -> Server am entfernten Standort ``` **Beispiel** | Testpfad | Ergebnis | |---|---:| | Client → lokaler Server | 940 Mbit/s | | Client → anderes VLAN | 925 Mbit/s | | Client → Server hinter Firewall | 180 Mbit/s | | Client → entfernter Standort | 175 Mbit/s | Die deutliche Abweichung beginnt im Beispiel am Pfad über die Firewall. Dort sind anschließend Schnittstellen, CPU, Sicherheitsinspektion, VPN und Bandbreitenbegrenzungen zu untersuchen. --- **12. Switchports und Uplinks vergleichen** Auf Cisco-Switches beispielsweise: ```text show interfaces status ``` ```text show interfaces counters errors ``` ```text show interfaces GigabitEthernet1/0/12 ``` Uplink prüfen: ```text show interfaces GigabitEthernet1/0/48 ``` Zu prüfen sind: - Eingangs- und Ausgangsrate, - Fehlerzähler, - Drops, - Queue Drops, - Linkgeschwindigkeit, - Duplex, - Auslastung, - Zeitpunkt der letzten Statusänderung, - Uplink mit geringerer Geschwindigkeit als erwartet, - überbuchter gemeinsamer Uplink. **Beispiel** ```text 48 Clients mit jeweils 1-Gbit/s-Port teilen sich einen einzelnen 1-Gbit/s-Uplink. ``` Nicht alle Clients übertragen dauerhaft mit voller Geschwindigkeit. Bei gleichzeitiger hoher Nutzung kann der Uplink jedoch zum Engpass werden. Ein schneller Access-Port garantiert deshalb keine entsprechend schnelle End-to-End-Verbindung. --- **13. Auslastung und Warteschlangen prüfen** Ein ausgelasteter Link kann folgende Auswirkungen haben: - steigende Latenz, - Jitter, - Paketverlust, - Output Drops, - TCP-Wiederholungen, - schwankenden Durchsatz, - schlechte Sprach- und Videoqualität. Zu prüfen sind: - aktuelle Auslastung, - Durchschnitt und Spitzenwerte, - Ein- und Ausgangsrichtung, - Queue Drops, - Quality-of-Service-Klassen, - Traffic Shaping, - Policing, - Backups oder Synchronisationen, - große Softwareverteilungen, - Cloud-Uploads, - Kamerastreams, - replizierende Server. Eine niedrige Durchschnittsauslastung schließt kurzzeitige Überlastung nicht aus. Sekunden- oder Minutenmittelwerte können kurze Spitzen verdecken. --- **14. Ethernet und WLAN getrennt vergleichen** Wenn ein betroffener Client WLAN verwendet, sollte – sofern vorgesehen und möglich – eine Vergleichsmessung über Ethernet durchgeführt werden. | Ethernet | WLAN | Eingrenzung | |---|---|---| | schnell | langsam | Funkstrecke, Access Point oder WLAN-Konfiguration | | langsam | langsam | gemeinsamer Pfad, Client, Server oder Anwendung | | nur ein WLAN-Client langsam | andere WLAN-Clients schnell | Client, Treiber, Frequenzband oder Standort | | alle Clients eines Access Points langsam | andere APs schnell | Access Point, Funkkanal oder AP-Uplink | Die reine WLAN-Verbindungsrate ist nicht der tatsächlich nutzbare Durchsatz. WLAN verwendet ein gemeinsam genutztes Funkmedium und enthält zusätzlichen Verwaltungsaufwand. --- **15. WLAN-Signal und Signal-Rausch-Abstand prüfen** Unter Windows: ```cmd netsh wlan show interfaces ``` Unter macOS können abhängig von Version und verfügbaren Werkzeugen die WLAN-Diagnose oder Systeminformationen verwendet werden. Zu prüfen sind: - Signalstärke, - Signal-Rausch-Abstand beziehungsweise SNR, - verwendetes Frequenzband, - Kanal, - Kanalbreite, - ausgehandelte Sende- und Empfangsrate, - Anzahl der Wiederholungen, - Entfernung zum Access Point, - Hindernisse, - Roaming, - unerwarteter Access Point. **Wichtig** Ein starkes Signal allein beweist keine gute WLAN-Leistung. Auch bei guter Signalstärke können folgende Probleme bestehen: - hoher Störpegel, - hohe Kanalauslastung, - Gleichkanalstörungen, - überlappende Kanäle, - viele gleichzeitig aktive Clients, - langsame Clients mit hohem Airtime-Verbrauch, - externe Störquellen, - problematisches Roaming, - überlasteter Access-Point-Uplink. --- **16. WLAN-Kanalauslastung und Airtime prüfen** WLAN-Clients teilen sich die verfügbare Sendezeit eines Funkkanals. Ein einzelner langsamer oder weit entfernter Client kann für die gleiche Datenmenge mehr Airtime benötigen als ein Client mit hoher Datenrate. Zu prüfen sind: - Channel Utilization, - Anzahl verbundener Clients, - Retry-Rate, - Datenraten, - Airtime-Nutzung, - Co-Channel Interference, - Adjacent-Channel Interference, - Störpegel, - Kanalbreite, - Lastverteilung zwischen Access Points, - Nutzung von 2,4 GHz, 5 GHz oder 6 GHz, - auffällige Roaming-Ereignisse. Ein breiterer Kanal erhöht nicht automatisch die Leistung. In einer dicht belegten Umgebung kann eine größere Kanalbreite zusätzliche Überschneidungen und Störungen verursachen. --- **17. Firewall, Router, VPN und Proxy prüfen** Wenn die Leistung erst beim Überschreiten eines bestimmten Netzsegments einbricht, sind beteiligte Netzwerkdienste zu untersuchen. Zu prüfen sind: - CPU- und Speicherauslastung, - Schnittstellenauslastung, - Paketverluste, - Session-Anzahl, - NAT-Tabellen, - VPN-Verschlüsselungsleistung, - Deep Packet Inspection, - Intrusion Prevention, - Malware-Scan, - TLS-Inspection, - Webfilter, - Proxy-Cache, - Traffic Shaping, - Bandbreitenlimits, - Quality of Service, - Lizenz- oder Plattformgrenzen. **Vergleich** ```text Interner Test ohne Firewallpfad: 930 Mbit/s Test über Firewall: 210 Mbit/s ``` Dieses Ergebnis weist auf den zusätzlichen Pfad als Prüfbereich hin, beweist aber noch nicht, welche einzelne Funktion die Begrenzung verursacht. Sicherheitsfunktionen dürfen nicht unkontrolliert deaktiviert werden. Stattdessen sind vorhandene Statistiken, Protokolle, Regelzähler und Herstellerdiagnosen zu verwenden. --- **18. VPN-Leistung untersuchen** Bei langsamen VPN-Verbindungen zusätzlich prüfen: - Leistung ohne Tunnel im gleichen Ausgangsnetz, - Round-Trip-Time zum VPN-Gateway, - Auslastung des VPN-Gateways, - verwendetes VPN-Protokoll, - Verschlüsselungsleistung, - Paketverlust auf dem äußeren Transportpfad, - MTU und Tunnel-Overhead, - Split-Tunneling oder Full-Tunneling, - konkurrierender Verkehr am Client, - Uploadgeschwindigkeit des Clientanschlusses, - Rückweg zum Client. Ein Full-Tunnel kann auch allgemeinen Internetverkehr durch das Unternehmensnetz führen. Dadurch können VPN-Gateway und Standortanbindung zusätzlich belastet werden. --- **19. MTU und Fragmentierung prüfen** Eine fehlerhafte MTU kann dazu führen, dass kleine Pakete funktionieren, während größere Übertragungen langsam sind oder abbrechen. Windows-Test mit gesetztem „Don’t Fragment“-Bit: ```cmd ping -f -l 1472 ``` Bei IPv4 entsprechen `1472 Byte` Nutzdaten zusammen mit `20 Byte` IPv4-Header und `8 Byte` ICMP-Header insgesamt `1500 Byte`. Wenn das Paket zu groß ist, die Größe schrittweise reduzieren: ```cmd ping -f -l 1400 ``` Linux: ```bash ping -M do -s 1472 ``` Zu prüfen sind: - MTU des Clients, - MTU der beteiligten Tunnel, - VPN-Overhead, - PPPoE-Overhead, - ICMP-Meldungen zur notwendigen Fragmentierung, - Path MTU Discovery, - MSS-Anpassung, - große Pakete gegenüber kleinen Paketen. **Wichtig** Ein erfolgreicher Ping mit kleinen Paketen schließt ein MTU-Problem nicht aus. Die maximal nutzbare Größe darf nicht aus einem einzelnen Test verallgemeinert werden. IPv4, IPv6, Tunnel und verwendete Protokolle besitzen unterschiedliche Header und Anforderungen. --- **20. TCP-Wiederholungen und Empfangsfenster analysieren** Paketverlust führt bei TCP normalerweise zu erneuten Übertragungen. Dadurch sinkt der nutzbare Durchsatz, obwohl die Verbindung nicht vollständig ausfällt. Wireshark-Anzeigefilter: ```text tcp.analysis.retransmission ``` Weitere mögliche Wiederholungen: ```text tcp.analysis.fast_retransmission ``` ```text tcp.analysis.spurious_retransmission ``` Verloren vermutete Segmente: ```text tcp.analysis.lost_segment ``` Empfangsfenster vollständig belegt: ```text tcp.analysis.window_full ``` Empfänger meldet ein Empfangsfenster von null: ```text tcp.analysis.zero_window ``` Alle TCP-Analysehinweise: ```text tcp.analysis.flags ``` Zu prüfen sind: - Häufigkeit der Wiederholungen, - Richtung der Wiederholungen, - zeitlicher Zusammenhang mit Leistungseinbrüchen, - TCP Zero Window, - TCP Window Full, - Out-of-Order-Segmente, - Round-Trip-Time, - Verbindungsabbrüche, - Resets. **Bewertung** | Beobachtung | Mögliche Ursache | |---|---| | viele Retransmissions | Paketverlust, Überlastung, WLAN oder fehlerhafter Pfad | | Zero Window vom Server | Server oder Anwendung verarbeitet Daten nicht schnell genug | | Zero Window vom Client | Client oder Anwendung nimmt Daten nicht schnell genug ab | | Window Full | Sender erreicht das angekündigte Empfangsfenster | | viele Out-of-Order-Pakete | parallele Pfade, Paketverlust oder Mitschnittposition | | TCP Reset | Anwendung, Firewall oder Gegenstelle beendet Verbindung | Wireshark-Analysekennzeichnungen beruhen auf dem beobachteten Mitschnitt. Fehlende Pakete können auch durch die Mitschnittposition, Capture Drops oder Offloading entstehen. --- **21. Paketmitschnitt kontrolliert durchführen** Ein Paketmitschnitt kann zeigen: - TCP-Verbindungsaufbau, - Antwortzeiten, - Wiederholungen, - Zero Window, - Resets, - DNS-Verzögerungen, - ICMP-Fehlermeldungen, - Fragmentierung, - lange Pausen zwischen Anfrage und Antwort. Beispielhafte Wireshark-Filter: ```text ip.addr == && ip.addr == ``` Nur TCP-Verkehr zwischen zwei Systemen: ```text tcp && ip.addr == && ip.addr == ``` TCP-Analysehinweise: ```text tcp.analysis.flags ``` ICMP-Fehlermeldungen: ```text icmp ``` DNS: ```text dns ``` HTTP-Antwortzeiten müssen im Kontext der Anwendung bewertet werden. Bei verschlüsseltem HTTPS-Verkehr sind Anwendungsinhalte ohne vorgesehene Entschlüsselungsmöglichkeiten nicht sichtbar. Mitschnitte dürfen nur autorisiert erfolgen. Sie können vertrauliche Inhalte, Adressen, Namen, Sitzungsinformationen oder Anmeldedaten enthalten. --- **22. Netzwerk und Anwendung voneinander trennen** Ein schneller Netzwerktest beweist nicht, dass die Anwendung schnell arbeitet. Mögliche zusätzliche Verzögerungen: - langsame DNS-Auflösung, - verzögerter TLS-Verbindungsaufbau, - langsame Authentifizierung, - langsame Datenbankabfrage, - überlasteter Webserver, - blockierter Anwendungsthread, - externer API-Aufruf, - Virenscanner, - Dateisperren, - langsamer Datenträger, - hohe CPU- oder Speicherauslastung. **Vergleich** ```text Ping zum Server: 1 ms iperf3 zum Server: 930 Mbit/s Dateiübertragung: 35 MB/s Anwendung reagiert: nach 8 Sekunden ``` Das Netzwerk erreicht in diesem Beispiel grundsätzlich einen hohen Durchsatz. Deshalb müssen anschließend Dateiablage, Serverressourcen und Anwendung untersucht werden. --- **23. Serverressourcen prüfen** Unter Windows beispielsweise: ```powershell Get-Counter '\Processor(_Total)\% Processor Time' ``` ```powershell Get-Counter '\Memory\Available MBytes' ``` Netzwerkadapterstatistik: ```powershell Get-NetAdapterStatistics ``` Aktuelle TCP-Verbindungen: ```powershell Get-NetTCPConnection ``` Unter Linux: ```bash top ``` ```bash free -h ``` ```bash vmstat 1 ``` ```bash iostat -xz 1 ``` ```bash ss -s ``` Zu prüfen sind: - CPU-Auslastung, - Speicherdruck, - Swap-Nutzung, - Datenträgerlatenz, - Warteschlangen des Storage, - Netzwerkauslastung, - Anzahl der Verbindungen, - Anwendungslimits, - Datenbankauslastung, - Backup- oder Scanprozesse, - Virtualisierungshost, - gemeinsam verwendete Ressourcen. Eine niedrige CPU-Auslastung schließt einen Serverengpass nicht aus. Eine Anwendung kann durch einen einzelnen Thread, Storage, Sperren, Datenbankabfragen oder externe Abhängigkeiten begrenzt sein. --- **24. Storage-Leistung von Netzwerkleistung unterscheiden** Dateiübertragungen werden mindestens durch folgende Komponenten begrenzt: ```text Clientdatenträger ↓ Clientnetzwerk ↓ Netzwerkpfad ↓ Servernetzwerk ↓ Serverdatenträger ``` Der langsamste beteiligte Abschnitt bestimmt die erreichbare Gesamtleistung. **Vergleichsmöglichkeiten** - `iperf3` für den Netzwerkpfad, - lokale Lese- und Schreibtests nach Betriebsvorgaben, - Dateiübertragung aus dem Arbeitsspeicher, - Vergleich mit einem anderen Datenträger, - Server-Monitoring für Storage-Latenz und Warteschlangen. Ein schneller `iperf3`-Test und eine langsame Dateiübertragung sprechen dafür, dass nicht allein der Netzwerkpfad begrenzt. Unkontrollierte Datenträger-Benchmarks dürfen auf Produktivsystemen nicht durchgeführt werden. Sie können erhebliche Last erzeugen und verfügbare Speicherkapazität beeinflussen. --- **25. Zeitabhängige Last untersuchen** Wenn die Störung nur zu bestimmten Zeiten auftritt, prüfen: - Backups, - Replikationen, - Cloud-Synchronisation, - Softwareverteilung, - Virenscans, - Datenbankwartung, - Patchmanagement, - Videoüberwachung, - geplante Exporte, - Benutzeranmeldungen am Arbeitsbeginn, - große Downloads oder Uploads, - Storage-Snapshots, - WAN-Auslastung, - Provider- oder Standortauslastung. Erforderlich ist eine zeitliche Korrelation: ```text 14:00 Uhr: Backup startet 14:02 Uhr: Uplink erreicht 98 % Auslastung 14:03 Uhr: Output Drops steigen 14:04 Uhr: Benutzer melden langsame Dateiübertragungen 15:00 Uhr: Backup endet 15:02 Uhr: Durchsatz normalisiert sich ``` Eine zeitliche Übereinstimmung ist ein starker Hinweis, aber noch kein vollständiger Ursachennachweis. Die beteiligten Messwerte müssen gemeinsam bewertet werden. --- **26. Baseline und Vergleichswerte verwenden** Eine Baseline beschreibt den normalen Zustand eines Systems. Sinnvolle Vergleichswerte: - Ping-Latenz, - Jitter, - Paketverlust, - `iperf3`-Durchsatz, - Linkauslastung, - Fehlerzähler, - WLAN-SNR, - WLAN-Kanalauslastung, - CPU-Auslastung, - Storage-Latenz, - Anwendungsantwortzeit, - Anzahl aktiver Sitzungen. **Beispiel** | Messwert | Normalzustand | Störungszeit | |---|---:|---:| | RTT zum Server | 1–2 ms | 25–180 ms | | Paketverlust | 0 % | 3 % | | TCP-Durchsatz | 920 Mbit/s | 85 Mbit/s | | Uplink-Auslastung | 20–40 % | 98 % | | Output Drops | 0/s | 2.500/s | Ohne Vergleichswert ist schwer zu beurteilen, ob ein Messwert tatsächlich ungewöhnlich ist. --- **27. Beispiel für eine systematische Diagnose** **Symptom** Mehrere Benutzer melden langsame Zugriffe auf einen Dateiserver. **Sollzustand** ```text Clientanschlüsse: 1 Gbit/s Switch-Uplink: 10 Gbit/s Serveranschluss: 10 Gbit/s Normaler TCP-Test: ungefähr 900 Mbit/s je Client ``` **Clienttest** ```cmd ping 192.0.2.80 -n 20 ``` Ergebnis: ```text Durchschnitt: 2 ms Paketverlust: 0 % ``` **Durchsatztest** ```bash iperf3 -c 192.0.2.80 -t 30 ``` Ergebnis: ```text Durchschnittlicher Durchsatz: 92 Mbit/s Retransmissions: erhöht ``` **Clientport** ```text show interfaces GigabitEthernet1/0/12 ``` Ergebnis: ```text Full-duplex, 1000 Mb/s Keine zunehmenden CRC-Fehler ``` **Uplinkprüfung** ```text show interfaces TenGigabitEthernet1/1/1 ``` Ergebnis: ```text Auslastung: 99 % Output Drops steigen ``` **Zeitlicher Vergleich** ```text Auslastungsbeginn: 14:00 Uhr Backupbeginn: 14:00 Uhr Benutzermeldungen: ab 14:05 Uhr ``` **Festgestellte Ursache** Ein neu eingerichteter Backupauftrag belegte während der Geschäftszeit nahezu die gesamte verfügbare Uplinkkapazität. Dadurch entstanden Warteschlangen, Drops und TCP-Wiederholungen. **Kontrollierte Maßnahme** Der Backupzeitplan und die vorgesehene Bandbreitensteuerung wurden nach betrieblicher Freigabe angepasst. **Rollback** Falls die Änderung unerwartete Auswirkungen verursacht: - ursprünglichen Zeitplan wiederherstellen, - ursprüngliche Bandbreitenrichtlinie wiederherstellen, - Konfiguration erneut prüfen, - Änderung dokumentieren. **Verifikation** ```bash iperf3 -c 192.0.2.80 -t 30 ``` Ergebnis: ```text Durchschnittlicher Durchsatz: 928 Mbit/s Retransmissions: keine auffällige Zunahme ``` Zusätzlich: - Uplink unterhalb der vorgesehenen Auslastungsgrenze, - keine neuen Output Drops, - Dateiübertragung wieder im normalen Bereich, - Anwendungen reagieren normal, - Benutzer bestätigen die Wiederherstellung. --- **28. Beispiel „Netzwerk schnell, Server langsam“** **Symptom** Der Zugriff auf eine Datenbankanwendung benötigt mehrere Sekunden. **Netzwerkprüfung** ```text Ping: 1 ms Paketverlust: 0 % iperf3: 935 Mbit/s Interfacefehler: keine Zunahme ``` **Serverprüfung** ```text Storage-Latenz: stark erhöht Datenträgerwarteschlange: stark erhöht Start eines Sicherungsauftrags: gleicher Zeitpunkt wie Störung ``` **Festgestellte Ursache** Der Netzwerkpfad funktionierte normal. Die Anwendung wartete auf den stark ausgelasteten Serverdatenträger. **Lehre** Eine langsame Netzwerkanwendung ist nicht automatisch ein langsames Netzwerk. Netzwerk, Anwendung und Serverressourcen müssen getrennt gemessen werden. --- **29. Ungeeignete Sofortmaßnahmen** Nicht als erste Maßnahme verwenden: - Switch oder Router ohne Diagnose neu starten, - Geschwindigkeit oder Duplex nur auf einer Seite erzwingen, - WLAN-Kanäle wahllos verändern, - Access Points unkontrolliert neu starten, - Firewall- oder Sicherheitsprüfung deaktivieren, - VPN umgehen, - Quality of Service vollständig entfernen, - alle Traffic-Limits pauschal aufheben, - MTU ohne Messung verändern, - TCP-Einstellungen ohne Baseline ändern, - Netzwerkkartentreiber ungeprüft ersetzen, - Fehlerzähler vor der Dokumentation löschen, - produktive Links mit unkontrolliertem `iperf3` auslasten, - UDP-Tests ohne Bandbreitenlimit starten, - ausschließlich einen öffentlichen Speedtest verwenden, - aus einem einzelnen Ping auf die Gesamtleistung schließen, - mehrere Änderungen gleichzeitig durchführen. Solche Maßnahmen können Diagnoseinformationen beseitigen, Sicherheitsgrenzen verändern oder zusätzliche Störungen erzeugen. --- **30. Vollständige Schnellprüfreihenfolge** 1. genaue Anwendung und Benutzeraktion ermitteln. 2. erwartete und tatsächliche Leistung dokumentieren. 3. Beginn, Dauer und zeitliches Muster bestimmen. 4. feststellen, ob ein oder mehrere Benutzer betroffen sind. 5. WLAN und Ethernet getrennt betrachten. 6. lokales und entferntes Ziel vergleichen. 7. Upload und Download getrennt prüfen. 8. tatsächlich verwendeten Netzwerkadapter feststellen. 9. Linkgeschwindigkeit und Duplex prüfen. 10. Fehler- und Verwerfungszähler dokumentieren. 11. Gateway, lokales Ziel und entferntes Ziel anpingen. 12. Latenz, Schwankung und Paketverlust vergleichen. 13. tatsächlichen Netzwerkpfad ermitteln. 14. Durchsatz mit einem autorisierten Testsystem messen. 15. beide Übertragungsrichtungen prüfen. 16. Netzwerkpfad in einzelne Segmente unterteilen. 17. Access-Port, Uplink und Serverport prüfen. 18. Auslastung und Warteschlangen untersuchen. 19. WLAN-Signal, SNR, Kanal und Airtime prüfen. 20. Firewall, Router, Proxy und VPN untersuchen. 21. MTU und mögliche Fragmentierungsprobleme prüfen. 22. TCP-Wiederholungen und Empfangsfenster untersuchen. 23. Anwendung und Netzwerk getrennt testen. 24. CPU, Arbeitsspeicher und Storage des Servers prüfen. 25. geplante Backups, Scans und Synchronisationen berücksichtigen. 26. Messwerte mit einer Baseline vergleichen. 27. genau eine Hypothese formulieren. 28. genau eine kontrollierte Änderung durchführen. 29. ursprüngliche Messungen wiederholen. 30. Nebenwirkungen und Sicherheitsfunktionen prüfen. 31. temporäre Diagnoseänderungen entfernen. 32. Ursache, Maßnahme, Rollback und Nachweis dokumentieren. --- **31. Checkliste „Netzwerk ist langsam“** - [ ] subjektive Aussage wurde in Messwerte übersetzt. - [ ] erwarteter Sollwert ist bekannt. - [ ] tatsächlicher Istwert wurde dokumentiert. - [ ] Beginn und zeitliches Muster sind bekannt. - [ ] Anzahl betroffener Benutzer wurde bestimmt. - [ ] betroffene Anwendungen wurden bestimmt. - [ ] Upload und Download wurden getrennt geprüft. - [ ] WLAN und Ethernet wurden verglichen. - [ ] lokales und entferntes Ziel wurden verglichen. - [ ] verwendeter Netzwerkadapter wurde bestätigt. - [ ] zusätzliche Adapter und VPN-Verbindungen wurden berücksichtigt. - [ ] Linkgeschwindigkeit wurde geprüft. - [ ] Duplexmodus wurde geprüft. - [ ] Clientfehlerzähler wurden dokumentiert. - [ ] Switchportfehler wurden dokumentiert. - [ ] CRC-/FCS-Fehler wurden geprüft. - [ ] Discards und Drops wurden geprüft. - [ ] Gateway-Latenz wurde gemessen. - [ ] Latenz zum Ziel wurde gemessen. - [ ] Paketverlust wurde gemessen. - [ ] Schwankungen beziehungsweise Jitter wurden berücksichtigt. - [ ] Netzwerkpfad wurde ermittelt. - [ ] Durchsatz wurde kontrolliert gemessen. - [ ] beide Übertragungsrichtungen wurden geprüft. - [ ] einzelne Netzwerksegmente wurden verglichen. - [ ] Access-Port wurde geprüft. - [ ] Uplink wurde geprüft. - [ ] Serverport wurde geprüft. - [ ] Auslastung und Warteschlangen wurden geprüft. - [ ] WLAN-Signal und SNR wurden geprüft. - [ ] WLAN-Kanalauslastung wurde geprüft. - [ ] WLAN-Airtime und Retry-Rate wurden berücksichtigt. - [ ] Firewall und Router wurden geprüft. - [ ] VPN und Proxy wurden berücksichtigt. - [ ] Traffic Shaping und Policing wurden geprüft. - [ ] Quality of Service wurde berücksichtigt. - [ ] MTU und Fragmentierung wurden geprüft. - [ ] TCP-Retransmissions wurden berücksichtigt. - [ ] TCP Window Full und Zero Window wurden berücksichtigt. - [ ] Server-CPU wurde geprüft. - [ ] Serverarbeitsspeicher wurde geprüft. - [ ] Storage-Latenz wurde geprüft. - [ ] Anwendung wurde getrennt vom Netzwerk getestet. - [ ] zeitabhängige Prozesse wurden untersucht. - [ ] Baseline oder Vergleichsmessung wurde verwendet. - [ ] vor Änderungen wurde der Ausgangszustand gesichert. - [ ] nur eine kontrollierte Änderung wurde durchgeführt. - [ ] Rollback wurde festgelegt. - [ ] ursprüngliche Messungen wurden wiederholt. - [ ] temporäre Diagnoseänderungen wurden entfernt. - [ ] Ursache, Maßnahme und Nachweis wurden dokumentiert. --- **32. Schnellreferenz** | Ergebnis | Nächster Schritt | |---|---| | nur ein Client langsam | Client, Kabel, Treiber und Switchport prüfen | | alle Clients langsam | gemeinsamen Uplink, Firewall, WAN oder Server prüfen | | Ethernet schnell, WLAN langsam | Funkstrecke, SNR, Kanal und Airtime prüfen | | Gateway bereits langsam | lokalen Zugang und Clientpfad prüfen | | Gateway schnell, entferntes Ziel langsam | Routing-, WAN-, VPN- oder Internetpfad prüfen | | Link nur mit 100 Mbit/s aktiv | Kabel, Aushandlung, Dock und Port prüfen | | zunehmende CRC-Fehler | physischen Übertragungsweg prüfen | | Output Drops steigen | nachgelagerten Engpass oder Warteschlange prüfen | | hohe Latenz ohne Paketverlust | Auslastung, Warteschlangen oder entfernten Pfad prüfen | | Paketverlust steigt unter Last | Überlastung, WLAN oder physische Fehler prüfen | | `iperf3` schnell, Datei langsam | Anwendung, Dateidienst und Storage prüfen | | `iperf3` ebenfalls langsam | Netzwerkpfad, Client und Gegenstelle prüfen | | nur eine Richtung langsam | richtungsabhängige Auslastung und Rückweg prüfen | | viele TCP-Retransmissions | Verlustursache entlang des Pfades suchen | | TCP Zero Window vom Server | Server oder Anwendung verarbeitet Daten zu langsam | | kleine Pakete funktionieren, große nicht | MTU und Fragmentierung prüfen | | nur VPN langsam | Tunnelpfad, MTU und VPN-Gateway prüfen | | nur zu bestimmten Zeiten langsam | geplante Last und historische Messwerte vergleichen | | Server-Storage stark ausgelastet | Server- und Speicherproblem statt Netzwerkfehler prüfen | | öffentlicher Speedtest langsam | Ergebnis durch internen Referenztest eingrenzen | | Zwischenhop antwortet nicht | prüfen, ob nachfolgende Hops und Ziel betroffen sind | | WLAN-Signal stark, Leistung schlecht | SNR, Störungen, Airtime und Kanalauslastung prüfen | --- **Merksatz** > Ein langsames Netzwerk wird nicht durch Gefühl diagnostiziert. Zuerst werden Umfang, Richtung, Latenz, Paketverlust und Durchsatz gemessen. Danach wird der Pfad segmentweise untersucht und eindeutig zwischen Client, WLAN, Netzwerk, Firewall, VPN, Server, Storage und Anwendung getrennt. --- **Quellen und weiterführende Dokumentation** - [Microsoft Learn – Get-NetAdapterStatistics](https://learn.microsoft.com/en-us/powershell/module/netadapter/get-netadapterstatistics) - [Microsoft Learn – Test-NetConnection](https://learn.microsoft.com/en-us/powershell/module/nettcpip/test-netconnection) - [Microsoft Learn – ping](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/ping) - [Microsoft Learn – tracert](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/tracert) - [Microsoft Learn – pathping](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/pathping) - [ESnet – iperf3 Documentation](https://software.es.net/iperf/) - [ESnet – Invoking iperf3](https://software.es.net/iperf/invoking.html) - [ESnet – iperf3 FAQ](https://software.es.net/iperf/faq.html) - [Cisco – Troubleshoot Switch Port and Interface Problems](https://www.cisco.com/c/en/us/support/docs/switches/catalyst-6500-series-switches/12027-53.html) - [Cisco – Troubleshoot Interface CRC Errors](https://www.cisco.com/c/en/us/support/docs/routers/asr-9000-series-aggregation-services-routers/225385-troubleshoot-interface-crc-errors-on.html) - [Cisco – RF Health and Wireless Troubleshooting](https://developer.cisco.com/docs/wireless-troubleshooting-tools/wlcca-rf-health/) - [Cisco – RF Analysis Tools](https://developer.cisco.com/docs/wireless-troubleshooting-tools/rf-analysis/) - [Wireshark – TCP Analysis](https://www.wireshark.org/docs/wsug_html_chunked/ChAdvTCPAnalysis.html) - [Wireshark – TCP Display Filter Reference](https://www.wireshark.org/docs/dfref/t/tcp.html) - [Wireshark – User’s Guide](https://www.wireshark.org/docs/wsug_html/) # 7.6 Fehler tritt nur manchmal auf Sporadische Fehler treten unregelmäßig auf und sind bei einer direkten Prüfung häufig nicht mehr vorhanden. Beispiele sind kurze Verbindungsabbrüche, gelegentliche Anmeldefehler, zeitweise langsame Anwendungen oder Dienste, die sich scheinbar ohne Eingriff wieder stabilisieren. Die besondere Schwierigkeit besteht darin, dass der Systemzustand während der Störung meistens nicht direkt beobachtet wird. Deshalb müssen Diagnoseinformationen bereits vor dem nächsten Auftreten gesammelt werden. ```text Sporadischer Fehler ↓ genauen Zeitpunkt erfassen ↓ Messwerte und Protokolle sichern ↓ wiederkehrendes Muster erkennen ↓ gemeinsame Ursache eingrenzen ``` --- **1. Typische Symptome** - Netzwerkverbindung fällt für wenige Sekunden aus. - Anwendung reagiert gelegentlich nicht. - Benutzer kann sich manchmal nicht anmelden. - Server ist nur zu bestimmten Zeiten langsam. - VPN-Verbindung wird unregelmäßig getrennt. - WLAN-Verbindung verliert kurzzeitig den Access Point. - DNS-Auflösung schlägt vereinzelt fehl. - Dateiübertragung bricht gelegentlich ab. - Dienst startet nach einem Fehler automatisch neu. - Druckauftrag funktioniert erst beim zweiten Versuch. - Datenbankverbindung läuft in einen Timeout. - Fehler verschwindet nach erneutem Laden der Anwendung. - Problem tritt nur an einzelnen Tagen oder Uhrzeiten auf. - Überwachung zeigt kurze Spitzen, obwohl der Durchschnitt normal ist. --- **2. Mögliche Auswirkungen** - Arbeitsunterbrechungen, - verlorene oder doppelt ausgeführte Vorgänge, - beschädigte Dateiübertragungen, - getrennte Sitzungen, - fehlgeschlagene Sicherungen, - unvollständige Synchronisation, - verzögerte Geschäftsprozesse, - schwer nachvollziehbare Benutzerbeschwerden, - steigender Supportaufwand, - falsche Ursachenzuordnung, - unerkannt zunehmende Hardwarefehler, - Sicherheits- oder Verfügbarkeitsrisiken. Ein sporadischer Fehler ist nicht automatisch harmlos. Kurze Unterbrechungen können besonders bei Datenbanken, Transaktionen, Authentifizierungen, Telefonie, VPN-Verbindungen und Schreibvorgängen erhebliche Auswirkungen haben. --- **3. Sicherheits- und Betriebshinweis** Dauerüberwachung, Protokollierung und Paketmitschnitte dürfen nur autorisiert durchgeführt werden. Dabei können verarbeitet werden: - IP-Adressen, - Benutzernamen, - Gerätenamen, - DNS-Abfragen, - Kommunikationsbeziehungen, - Sitzungsinformationen, - Anmeldedaten, - Anwendungsinhalte, - personenbezogene Daten, - vertrauliche Unternehmensdaten. Vor einer erweiterten Protokollierung sind deshalb zu klären: - betriebliche Freigabe, - erforderlicher Umfang, - Speicherort, - Zugriffsschutz, - Aufbewahrungsdauer, - Datenschutz, - anschließende Löschung, - mögliche Systembelastung. Protokollierung darf nicht unbegrenzt und ohne festgelegten Zweck aktiviert bleiben. --- **4. Fehler nicht vorschnell als „nicht reproduzierbar“ schließen** Wenn ein Fehler bei der Prüfung nicht mehr vorhanden ist, bedeutet dies nur: ```text Der Fehler ist im aktuellen Moment nicht sichtbar. ``` Es bedeutet nicht: ```text Der Fehler hat nicht stattgefunden. ``` Ein sporadischer Fehler kann zwischen zwei Prüfungen auftreten und wieder verschwinden. Deshalb müssen folgende Informationen gesammelt werden: - exakter Zeitpunkt, - Dauer, - betroffener Benutzer, - betroffenes Gerät, - verwendete Anwendung, - ausgeführte Aktion, - Zielsystem, - angezeigte Fehlermeldung, - Netzwerkverbindung, - Standort, - Häufigkeit, - mögliche Auslöser, - Zustand vor und nach dem Fehler. --- **5. Exakten Zeitpunkt erfassen** Die wichtigste Angabe ist ein möglichst genauer Zeitstempel. Ungeeignet: ```text Der Fehler war heute Nachmittag. ``` Besser: ```text 02.08.2026, ungefähr 14:17 Uhr ``` Optimal: ```text 02.08.2026, 14:17:32 bis 14:17:47 Uhr ``` Zusätzlich dokumentieren: ```text Benutzer: Max Mustermann Client: NB-023 IP-Adresse: 192.0.2.45 Anwendung: ERP-Client Zielserver: ERP-SRV-01 Aktion: Auftrag speichern Fehlermeldung: Verbindung zum Server unterbrochen Beginn: 14:17:32 Uhr Ende: 14:17:47 Uhr ``` Je genauer der Zeitpunkt bekannt ist, desto gezielter können Ereignisprotokolle, Monitoringdaten und Paketmitschnitte ausgewertet werden. --- **6. Zeitsynchronisation prüfen** Protokolle verschiedener Systeme lassen sich nur zuverlässig vergleichen, wenn deren Uhren korrekt synchronisiert sind. Zu prüfen sind: - aktuelle Uhrzeit, - Zeitzone, - NTP-Quelle, - Synchronisationsstatus, - Zeitabweichung, - Sommer- oder Winterzeit, - UTC gegenüber lokaler Zeit, - Zeitstempel von Netzwerkgeräten, - Zeitstempel von Containern und virtuellen Maschinen. Unter Windows: ```cmd w32tm /query /status ``` Konfigurierte Zeitquelle: ```cmd w32tm /query /source ``` Unter Linux: ```bash timedatectl status ``` Bei chrony, sofern eingesetzt: ```bash chronyc tracking ``` ```bash chronyc sources ``` **Beispiel** ```text Client: 14:17:32 Uhr Server: 14:15:21 Uhr Firewall: 12:17:30 UTC ``` Ohne Berücksichtigung von Zeitabweichung und Zeitzone könnten zusammengehörige Ereignisse fälschlich als getrennte Vorfälle bewertet werden. Die Systemzeit darf nicht unkontrolliert auf Produktivsystemen geändert werden. Zeitänderungen können Protokolle, Zertifikate, Authentifizierung, Datenbanken und verteilte Systeme beeinflussen. --- **7. Häufigkeit und Muster bestimmen** Zu klären ist, ob der Fehler: - mehrmals täglich, - einmal täglich, - an bestimmten Wochentagen, - nach einer bestimmten Laufzeit, - nach einer Anmeldung, - nach dem Standby, - nach einem Neustart, - während hoher Last, - nach einem Netzwerkwechsel, - bei Ablauf einer Sitzung, - bei einem Backup, - während eines Updates, - bei Temperaturänderungen, - nur an einem Standort, - nur im WLAN, - nur über VPN auftritt. **Beispielhafte Fehlerliste** | Datum | Uhrzeit | Dauer | Benutzer | System | Beobachtung | |---|---:|---:|---|---|---| | 30.07.2026 | 14:17 | 15 s | Max Mustermann | NB-023 | ERP-Verbindung getrennt | | 31.07.2026 | 14:16 | 18 s | Max Mustermann | NB-023 | ERP-Verbindung getrennt | | 01.08.2026 | 14:18 | 12 s | mehrere | verschiedene | Dateiserver kurz nicht erreichbar | | 02.08.2026 | 14:17 | 15 s | mehrere | verschiedene | ERP und Dateiserver betroffen | Das wiederkehrende Zeitfenster deutet auf einen geplanten oder regelmäßig ausgelösten Prozess hin. --- **8. Umfang des Fehlers bestimmen** Folgende Fragen helfen bei der Eingrenzung: 1. Ist nur ein Benutzer betroffen? 2. Sind mehrere Benutzer betroffen? 3. Sind alle Benutzer eines Standorts betroffen? 4. Ist nur eine Anwendung betroffen? 5. Sind mehrere Dienste gleichzeitig betroffen? 6. Ist nur ein Client betroffen? 7. Sind alle Geräte an einem Switch betroffen? 8. Sind ausschließlich WLAN-Clients betroffen? 9. Sind nur VPN-Verbindungen betroffen? 10. Ist nur eine Übertragungsrichtung betroffen? 11. Ist nur ein bestimmter Server betroffen? 12. Sind interne und externe Ziele betroffen? **Bewertung** | Beobachtung | Möglicher Prüfbereich | |---|---| | nur ein Benutzer | Benutzerprofil, Sitzung oder Berechtigung | | nur ein Client | Client, Treiber, Kabel, WLAN oder lokale Software | | mehrere Clients am gleichen Switch | Switch, Uplink oder Stromversorgung | | alle WLAN-Clients eines Access Points | Access Point, Funkkanal oder AP-Uplink | | mehrere Dienste auf einem Server | Server, Betriebssystem oder gemeinsame Ressource | | mehrere Systeme gleichzeitig | Netzwerk, DNS, Authentifizierung, Storage oder Infrastruktur | | nur VPN-Benutzer | Internetzugang, Tunnel, Gateway, MTU oder Sitzungszeit | | alle Standorte gleichzeitig | zentrales System, Provider oder übergreifender Dienst | --- **9. Fehler automatisiert erfassen** Ein sporadischer Fehler sollte möglichst durch wiederholte Messungen sichtbar gemacht werden. Geeignete Messwerte sind beispielsweise: - Erreichbarkeit, - Antwortzeit, - Paketverlust, - DNS-Auflösung, - TCP-Port-Erreichbarkeit, - HTTP-Status, - Anwendungsantwortzeit, - CPU-Auslastung, - Arbeitsspeicher, - Storage-Latenz, - Interfacezustand, - Fehlerzähler, - Dienststatus, - Anzahl der Sitzungen, - Temperatur, - Spannungs- oder Stromereignisse. Die Messung muss einen Zeitstempel enthalten. **Grundprinzip** ```text Zeitstempel + Messwert + Ziel + Ergebnis ``` Beispiel: ```text 2026-08-02 14:17:30 | ERP-SRV-01 | Ping 1 ms | TCP 443 erreichbar 2026-08-02 14:17:35 | ERP-SRV-01 | Zeitüberschreitung 2026-08-02 14:17:40 | ERP-SRV-01 | Zeitüberschreitung 2026-08-02 14:17:45 | ERP-SRV-01 | Ping 2 ms | TCP 443 erreichbar ``` --- **10. Kontinuierliche Erreichbarkeit unter Windows prüfen** Ein dauerhafter Ping kann kurzfristige Unterbrechungen sichtbar machen: ```cmd ping -t ``` Der Test wird mit `Strg + C` beendet. Aussagekräftiger ist eine protokollierte PowerShell-Messung mit Zeitstempel: ```powershell while ($true) { $timestamp = Get-Date -Format "yyyy-MM-dd HH:mm:ss" $result = Test-Connection -ComputerName "" -Count 1 -Quiet "$timestamp | | Erreichbar: $result" | Out-File -FilePath ".\erreichbarkeit.log" -Append Start-Sleep -Seconds 5 } ``` TCP-Port wiederholt prüfen: ```powershell while ($true) { $timestamp = Get-Date -Format "yyyy-MM-dd HH:mm:ss" $result = Test-NetConnection -ComputerName "" -Port 443 "$timestamp | TCP 443: $($result.TcpTestSucceeded)" | Out-File -FilePath ".\tcp-443.log" -Append Start-Sleep -Seconds 5 } ``` **Wichtig** - Testintervall an die erwartete Fehlerdauer anpassen. - Speicherbedarf begrenzen. - Logdateien regelmäßig kontrollieren. - Messung nach Abschluss wieder beenden. - Ein erfolgreicher Ping beweist nicht, dass die Anwendung funktioniert. - Ein fehlgeschlagener Ping beweist nicht automatisch einen vollständigen Ausfall, da ICMP blockiert oder begrenzt werden kann. --- **11. Kontinuierliche Erreichbarkeit unter Linux oder macOS prüfen** Linux: ```bash ping ``` macOS: ```bash ping ``` Mit Zeitstempeln unter Linux, sofern `ping` diese Option unterstützt: ```bash ping -D ``` Alternativ kann eine kontrollierte Schleife verwendet werden: ```bash while true; do timestamp=$(date '+%Y-%m-%d %H:%M:%S') if ping -c 1 -W 2 >/dev/null 2>&1; then echo "$timestamp | | erreichbar" else echo "$timestamp | | nicht erreichbar" fi sleep 5 done ``` Da sich Optionen von `ping` zwischen Linux und macOS unterscheiden können, müssen die Parameter des verwendeten Systems geprüft werden: ```bash man ping ``` --- **12. Mehrere Messpunkte gleichzeitig verwenden** Eine einzelne Zielmessung zeigt nicht, an welcher Stelle der Fehler auftritt. Deshalb sollten mehrere Punkte parallel überwacht werden. ```text Client | Standardgateway | interner Server | externer Dienst ``` Beispiel: ```text 14:17:35 | Gateway erreichbar 14:17:35 | interner Server nicht erreichbar 14:17:35 | externer Dienst nicht erreichbar ``` Mögliche Eingrenzung: ```text Clientzugang funktioniert. Die Störung beginnt hinter dem Gateway oder auf einem gemeinsamen Folgepfad. ``` Anderes Beispiel: ```text 14:17:35 | Gateway nicht erreichbar 14:17:35 | interner Server nicht erreichbar 14:17:35 | externer Dienst nicht erreichbar ``` Mögliche Eingrenzung: ```text Client, lokaler Zugang, WLAN, Switchport oder lokales Netzwerk prüfen. ``` **Vergleichstabelle** | Gateway | Interner Server | Externes Ziel | Eingrenzung | |---|---|---|---| | nicht erreichbar | nicht erreichbar | nicht erreichbar | Client oder lokaler Zugang | | erreichbar | nicht erreichbar | erreichbar | interner Pfad oder Server | | erreichbar | erreichbar | nicht erreichbar | Internet-, Provider- oder externer Pfad | | überall erreichbar | Anwendung fehlerhaft | Anwendung, Dienst oder Sitzung | | mehrere Ziele gleichzeitig langsam | gemeinsamer Netzwerkpfad oder Infrastruktur | --- **13. Windows-Ereignisprotokolle zeitlich filtern** Ereignisse eines bestimmten Zeitraums anzeigen: ```powershell Get-WinEvent -FilterHashtable @{ LogName = "System" StartTime = [datetime]"2026-08-02 14:15:00" EndTime = [datetime]"2026-08-02 14:20:00" } | Select-Object TimeCreated, ProviderName, Id, LevelDisplayName, Message ``` Anwendungsprotokoll: ```powershell Get-WinEvent -FilterHashtable @{ LogName = "Application" StartTime = [datetime]"2026-08-02 14:15:00" EndTime = [datetime]"2026-08-02 14:20:00" } | Select-Object TimeCreated, ProviderName, Id, LevelDisplayName, Message ``` Fehler und Warnungen aus dem Systemprotokoll: ```powershell Get-WinEvent -FilterHashtable @{ LogName = "System" Level = 2, 3 StartTime = (Get-Date).AddHours(-4) } | Select-Object TimeCreated, ProviderName, Id, LevelDisplayName, Message ``` Zu prüfen sind unter anderem: - Treiberfehler, - Netzwerkunterbrechungen, - Dienstabbrüche, - unerwartete Neustarts, - Datenträgerfehler, - DNS-Fehler, - Authentifizierungsfehler, - Zeitabweichungen, - Ressourcenknappheit, - Anwendungsabstürze, - automatische Wiederherstellungen. Ein zeitgleiches Ereignis ist zunächst eine Korrelation. Erst weitere Messungen zeigen, ob es tatsächlich die Ursache des Fehlers ist. --- **14. Linux-Protokolle zeitlich filtern** Systemprotokoll eines genauen Zeitfensters: ```bash journalctl \ --since "2026-08-02 14:15:00" \ --until "2026-08-02 14:20:00" ``` Nur Meldungen eines bestimmten Dienstes: ```bash journalctl \ -u \ --since "2026-08-02 14:15:00" \ --until "2026-08-02 14:20:00" ``` Kernelmeldungen: ```bash journalctl \ -k \ --since "2026-08-02 14:15:00" \ --until "2026-08-02 14:20:00" ``` Nur Warnungen und schwerwiegendere Meldungen: ```bash journalctl -p warning \ --since "2026-08-02 14:15:00" \ --until "2026-08-02 14:20:00" ``` Live verfolgen: ```bash journalctl -f ``` Zu prüfen sind: - Dienstneustarts, - Kernelmeldungen, - Link-Up- und Link-Down-Ereignisse, - DHCP-Ereignisse, - DNS-Fehler, - Speicherfehler, - Out-of-Memory-Ereignisse, - Datenträger- und Dateisystemfehler, - Authentifizierungsfehler, - Containerneustarts, - Prozessabbrüche. Ob ältere Meldungen verfügbar sind, hängt von der Konfiguration und Aufbewahrung des Journals ab. --- **15. Protokolle zentral zusammenführen** Wenn mehrere Systeme beteiligt sind, reichen lokale Protokolle häufig nicht aus. Mögliche Quellen: - Client, - Server, - Switch, - Router, - Firewall, - Access Point, - VPN-Gateway, - DNS-Server, - DHCP-Server, - Verzeichnisdienst, - Hypervisor, - Containerplattform, - Anwendung, - Datenbank, - Storage, - Monitoring, - Cloud- oder Providerdienst. Vorteile einer zentralen Protokollierung: - gemeinsame Suche, - einheitliche Aufbewahrung, - Vergleich mehrerer Systeme, - Alarmierung, - Erkennung wiederkehrender Muster, - Ereigniszeitleisten, - langfristige Auswertung. Dabei müssen Zeitsynchronisation, Zugriffsschutz, Speicherbedarf und Datenschutz berücksichtigt werden. --- **16. Auflösung des Monitorings erhöhen** Ein Fünf-Minuten-Mittelwert kann einen Fehler von zehn Sekunden vollständig verdecken. **Beispiel** ```text Messintervall: 5 Minuten Störung: 10 Sekunden Linklast: während der Störung 100 % Mittelwert: nur 8 % ``` Der Mittelwert wirkt unauffällig, obwohl kurzzeitig eine vollständige Überlastung bestand. Zu prüfen sind: - Messintervall, - Aggregation, - Durchschnitt gegenüber Maximum, - kurzfristige Spitzen, - Anzahl der Messwerte, - Aufbewahrungsstufen, - Alarmverzögerung, - Alarmrücksetzung, - fehlende Messwerte. Mögliche Anpassung: ```text Vorher: Messung alle 5 Minuten Temporär: Messung alle 10 Sekunden ``` Eine höhere Auflösung erzeugt mehr Last und benötigt mehr Speicher. Sie sollte kontrolliert, zeitlich begrenzt und auf die erforderlichen Messwerte beschränkt werden. --- **17. Ringpuffer-Paketmitschnitt verwenden** Wenn ein Netzwerkfehler nur selten auftritt, kann ein begrenzter Ringpuffer-Mitschnitt die Pakete vor und während des Fehlers erhalten. Verfügbare Schnittstellen anzeigen: ```bash dumpcap -D ``` Beispiel für einen Ringpuffer: ```bash dumpcap \ -i 1 \ -b duration:300 \ -b files:12 \ -w sporadischer-fehler.pcapng ``` Bedeutung: ```text -i 1 Schnittstelle 1 -b duration:300 alle 300 Sekunden neue Datei -b files:12 höchstens 12 Ringpufferdateien -w Ausgabedatei ``` Damit werden ungefähr die letzten 60 Minuten vorgehalten: ```text 12 Dateien × 5 Minuten = 60 Minuten ``` Mitschnitt auf einen bestimmten Host begrenzen: ```bash dumpcap \ -i 1 \ -f "host 192.0.2.45" \ -b duration:300 \ -b files:12 \ -w sporadischer-fehler.pcapng ``` **Wichtig** - richtige Netzwerkschnittstelle auswählen, - Sichtbarkeit des relevanten Verkehrs prüfen, - Speicherbedarf begrenzen, - Capture-Filter möglichst eng setzen, - Systembelastung beobachten, - Zeitpunkt des Fehlers sofort dokumentieren, - betroffene Dateien vor dem Überschreiben sichern, - Mitschnitt nach der Diagnose beenden, - Dateien geschützt speichern und anschließend geregelt löschen. Ein Paketmitschnitt auf dem Client sieht nicht automatisch den gesamten Netzwerkverkehr. Für andere Segmente kann ein autorisierter Mirror- beziehungsweise SPAN-Port erforderlich sein. --- **18. Interface-Flapping untersuchen** Interface-Flapping bedeutet, dass eine Netzwerkschnittstelle wiederholt zwischen aktiv und inaktiv wechselt. Typisches Muster: ```text 14:17:31 Interface down 14:17:34 Interface up 14:18:02 Interface down 14:18:05 Interface up ``` Unter Windows: ```powershell Get-NetAdapter | Format-Table Name, Status, LinkSpeed, InterfaceDescription ``` Statistiken: ```powershell Get-NetAdapterStatistics ``` Unter Linux: ```bash ip link show ``` ```bash ip -s link show ``` Kernelmeldungen zum Netzwerk: ```bash journalctl -k | grep -Ei "link.*(up|down)|carrier|network" ``` Auf Cisco-IOS-/IOS-XE-Switches beispielsweise: ```text show logging ``` ```text show interfaces status ``` ```text show interfaces ``` Zu prüfen sind: - Link-Up- und Link-Down-Zeitpunkte, - Anzahl der Statuswechsel, - CRC- oder FCS-Fehler, - Interface Resets, - Kabel, - Stecker, - Switchport, - Transceiver, - Dockingstation, - Netzwerkkartentreiber, - Energiesparzustand, - Power over Ethernet, - Port-Security, - Spanning Tree, - Aushandlung von Geschwindigkeit und Duplex. Ein Link-Flap kann sehr kurz sein und zwischen zwei manuellen Prüfungen vollständig verschwinden. Protokolle und historische Zähler sind deshalb besonders wichtig. --- **19. Fehlerzähler als Verlauf beobachten** Ein einzelner Zählerstand zeigt nicht, wann ein Fehler entstanden ist. Deshalb müssen Ausgangswert und späterer Wert verglichen werden. **Beispiel ohne aktuelle Zunahme** ```text 14:00 Uhr: 25 CRC-Fehler 15:00 Uhr: 25 CRC-Fehler ``` Der Zähler enthält historische Fehler, steigt im Beobachtungszeitraum jedoch nicht. **Beispiel mit sporadischer Zunahme** ```text 14:00 Uhr: 25 CRC-Fehler 14:16 Uhr: 25 CRC-Fehler 14:18 Uhr: 4.260 CRC-Fehler 14:20 Uhr: 4.260 CRC-Fehler ``` Die Fehler entstehen in einem kurzen Zeitfenster und korrelieren möglicherweise mit der gemeldeten Störung. Zu beobachten sind: - CRC-/FCS-Fehler, - Input Errors, - Output Errors, - Discards, - Drops, - Interface Resets, - Kollisionen, - Retransmissions, - WLAN-Retries, - Queue Drops, - verlorene Pakete, - Linkstatuswechsel. Fehlerzähler sollten erst nach der Dokumentation und nur nach betrieblicher Freigabe zurückgesetzt werden. --- **20. DHCP-Lease und Adresskonflikte prüfen** Ein Fehler kann beim Erneuern einer DHCP-Lease oder durch eine doppelt verwendete IP-Adresse auftreten. Unter Windows: ```cmd ipconfig /all ``` Zu prüfen sind: - DHCP aktiviert, - Lease erhalten, - Lease läuft ab, - DHCP-Server, - aktuelle IPv4- und IPv6-Adresse, - Standardgateway, - DNS-Server, - unerwartete Adressänderung, - APIPA-Adresse, - doppelte IP-Adresse. Unter Linux, abhängig vom verwendeten Netzwerkdienst: ```bash journalctl | grep -Ei "dhcp|lease" ``` Mögliche Hinweise: ```text Fehler tritt regelmäßig bei Lease-Erneuerung auf. Client erhält kurzzeitig keine gültige Adresse. Zwei Geräte verwenden dieselbe statische IP-Adresse. DHCP-Server sind nicht einheitlich konfiguriert. ``` Eine zeitliche Übereinstimmung zwischen Lease-Erneuerung und Fehler ist ein Hinweis, aber noch kein Beweis für die Ursache. --- **21. DNS-TTL und DNS-Auflösung prüfen** Ein sporadischer Fehler kann auftreten, wenn zwischengespeicherte DNS-Einträge ablaufen und anschließend eine fehlerhafte oder langsame Auflösung erfolgt. Unter Windows: ```powershell Resolve-DnsName ``` DNS-Cache anzeigen: ```cmd ipconfig /displaydns ``` Unter Linux oder macOS, sofern `dig` vorhanden ist: ```bash dig ``` Wiederholte Abfrage: ```bash dig +noall +answer ``` Zu prüfen sind: - Antwortzeit, - zurückgegebene IP-Adressen, - TTL, - mehrere DNS-Server, - unterschiedliche Antworten, - fehlgeschlagene Abfragen, - kurze TTL, - veraltete Einträge, - fehlerhafte Weiterleitung, - DNSSEC-Fehler, - Suchdomänen, - Split-DNS, - Wechsel zwischen funktionierenden und fehlerhaften Zieladressen. **Beispiel** ```text DNS-Antwort 1: 192.0.2.80 – Dienst funktioniert DNS-Antwort 2: 192.0.2.81 – Dienst nicht erreichbar ``` In diesem Fall kann der Fehler nur bei Auswahl einer bestimmten Zieladresse auftreten. DNS-Caches dürfen nicht pauschal gelöscht werden, bevor der aktuelle Zustand dokumentiert wurde. Dadurch könnten wichtige Diagnoseinformationen verloren gehen. --- **22. Sitzungen, Token und Timeouts berücksichtigen** Viele sporadische Fehler treten nach einer bestimmten Zeitspanne auf. Mögliche Zeitgrenzen: - Sitzungs-Timeout, - Idle-Timeout, - Access-Token-Ablauf, - Refresh-Token-Ablauf, - Kerberos-Ticketlaufzeit, - VPN-Sitzungslaufzeit, - Firewall-Session-Timeout, - Proxy-Timeout, - Load-Balancer-Timeout, - Datenbankverbindungs-Timeout, - DHCP-Lease, - DNS-TTL, - Zertifikatsablauf, - API-Ratenlimit, - Sperrzeit einer Anwendung. **Beispiel** ```text Anmeldung: 08:00 Uhr Fehler: 16:00 Uhr Zeit bis zum Fehler: 8 Stunden ``` Tritt der Fehler regelmäßig nach fast derselben Sitzungsdauer auf, sind zeitbasierte Gültigkeiten und Timeouts zu prüfen. Zu dokumentieren sind: - Zeitpunkt der Anmeldung, - Zeitpunkt der letzten Aktivität, - Zeitpunkt der Tokenausstellung, - Ablaufzeit, - Zeitpunkt des Fehlers, - erfolgreiche oder fehlgeschlagene Erneuerung, - Verhalten nach erneuter Anmeldung. Ein erneutes Anmelden kann den Fehler vorübergehend beseitigen, beweist aber noch nicht, welche Komponente die Sitzung beendet hat. --- **23. Zertifikats- und Gültigkeitszeiträume prüfen** Zertifikatsprobleme können nur einzelne Systeme, Dienste oder Verbindungswege betreffen. Mit OpenSSL, sofern verfügbar: ```bash openssl s_client \ -connect :443 \ -servername ``` Nur Zertifikatsdaten ausgeben: ```bash openssl s_client \ -connect :443 \ -servername \ /dev/null | openssl x509 -noout -subject -issuer -dates ``` Zu prüfen sind: - Beginn der Gültigkeit, - Ablaufdatum, - vollständige Zertifikatskette, - Hostname, - Zwischenzertifikate, - Systemzeit, - unterschiedliche Zertifikate an mehreren Servern, - Load-Balancer-Knoten, - Proxy- oder TLS-Inspection, - automatische Zertifikatserneuerung. **Beispiel** ```text Load-Balancer-Knoten 1: gültiges Zertifikat Load-Balancer-Knoten 2: abgelaufenes Zertifikat ``` Der Fehler erscheint dadurch möglicherweise nur bei Verbindungen, die auf den zweiten Knoten verteilt werden. --- **24. Geplante Aufgaben und Timer prüfen** Regelmäßig auftretende Fehler können mit zeitgesteuerten Prozessen zusammenhängen. Unter Windows: ```powershell Get-ScheduledTask | Select-Object TaskName, TaskPath, State ``` Weitere Informationen: ```powershell Get-ScheduledTask | Get-ScheduledTaskInfo | Select-Object TaskName, LastRunTime, LastTaskResult, NextRunTime ``` Unter Linux mit systemd: ```bash systemctl list-timers --all ``` Cron-Einträge müssen entsprechend der verwendeten Distribution und betrieblichen Berechtigung geprüft werden. Mögliche zeitgesteuerte Auslöser: - Backups, - Datenbankwartung, - Logrotation, - Virenscans, - Softwareverteilung, - Patchmanagement, - Replikation, - Cloud-Synchronisation, - Storage-Snapshots, - Zertifikatserneuerung, - Berichterstellung, - Dateiimporte, - Exporte, - Neustarts, - Container-Updates, - automatische Skalierung, - Indexierung. --- **25. Backups, Scans und Updates zeitlich vergleichen** **Beispiel** ```text 02:00:00 Backup startet 02:00:12 Storage-Latenz steigt 02:00:18 Datenbankantwortzeit steigt 02:00:25 Anwendung meldet Timeout 02:20:00 Backup endet 02:20:15 Storage-Latenz normalisiert sich ``` Diese Ereignisse bilden eine plausible Kette: ```text Backup ↓ hohe Storage-Last ↓ langsame Datenbank ↓ Anwendungs-Timeout ``` Die zeitliche Korrelation ist stark, muss aber durch Messwerte bestätigt werden. Zu vergleichen sind: - Start- und Endzeit, - CPU-Auslastung, - Arbeitsspeicher, - Storage-Latenz, - Netzwerkauslastung, - Warteschlangen, - Anwendungsantwortzeit, - Anzahl der Fehler, - Verhalten ohne den geplanten Prozess. Produktive Sicherungen oder Sicherheitsprüfungen dürfen nicht ohne Freigabe deaktiviert werden. Eine kontrollierte Zeitplanänderung ist häufig sicherer als das vollständige Abschalten. --- **26. Temperatur und Stromversorgung berücksichtigen** Sporadische Hardwarefehler können durch Umwelt- oder Strombedingungen ausgelöst werden. Zu prüfen sind: - CPU- und Gerätetemperatur, - Lüfterdrehzahl, - Überhitzungswarnungen, - Netzteilstatus, - redundante Netzteile, - USV-Ereignisse, - Spannungsschwankungen, - PoE-Leistungsbudget, - Stromausfälle, - fehlerhafte Steckverbindungen, - Temperatur im Serverschrank, - Tageszeit und Umgebungstemperatur. Typisches Muster: ```text Temperatur steigt ↓ Gerät reduziert Leistung oder schaltet Komponente ab ↓ Dienst oder Verbindung fällt kurzzeitig aus ↓ Temperatur sinkt ↓ System funktioniert wieder ``` Hardwaregrenzwerte und Diagnosebefehle sind hersteller- und modellspezifisch und müssen anhand der offiziellen Gerätedokumentation geprüft werden. --- **27. WLAN-Störungen untersuchen** Kurzzeitige WLAN-Probleme können durch wechselnde Funkbedingungen entstehen. Zu prüfen sind: - Signalstärke, - Signal-Rausch-Abstand, - Kanalauslastung, - Retry-Rate, - Roaming, - Kanalwechsel, - Radarerkennung bei DFS-Kanälen, - Access-Point-Neustarts, - Anzahl aktiver Clients, - Airtime, - fremde WLAN-Netze, - Bluetooth- oder andere Funkquellen, - Mikrowellengeräte, - bauliche Hindernisse, - bewegliche Störquellen, - fehlerhafter AP-Uplink, - PoE-Unterbrechungen. Unter Windows: ```cmd netsh wlan show interfaces ``` Bericht zur WLAN-Nutzung: ```cmd netsh wlan show wlanreport ``` Der erzeugte Bericht enthält Informationen zu WLAN-Sitzungen und Verbindungsereignissen. Speicherort und Zugriff müssen auf dem jeweiligen System geprüft werden. **Vergleich** | Ethernet | WLAN | Eingrenzung | |---|---|---| | stabil | sporadische Ausfälle | Funkstrecke, Roaming oder Access Point | | beide gleichzeitig gestört | gemeinsamer Pfad oder Zielsystem | | nur ein WLAN-Client betroffen | Client, Treiber, Standort oder Frequenzband | | alle Clients eines AP betroffen | Access Point, Funkkanal, PoE oder Uplink | --- **28. Provider- und WAN-Störungen berücksichtigen** Wenn nur externe oder standortübergreifende Verbindungen betroffen sind, müssen auch WAN- und Providerpfade untersucht werden. Zu prüfen sind: - Verlust zum Provider-Gateway, - Latenzsprünge, - Leitungsstatus, - Modem- oder Routerprotokolle, - WAN-Interface-Fehler, - Neuverbindungen, - öffentliche IP-Adresswechsel, - PPPoE-Sitzungen, - Mobilfunkqualität, - Providerwartungen, - BGP- oder Routingänderungen, - VPN-Neuaufbau, - Auslastung der Standortanbindung, - beide Übertragungsrichtungen. Ein einzelner öffentlicher Speedtest reicht nicht aus. Benötigt werden wiederholte und möglichst vergleichbare Messungen zu internen und externen Referenzzielen. --- **29. Mehrere Systeme auf einer gemeinsamen Zeitleiste korrelieren** Die wichtigste Methode bei sporadischen Fehlern ist eine gemeinsame Ereigniszeitleiste. **Beispiel** | Zeit | Client | Switch | Firewall | Server | Anwendung | |---:|---|---|---|---|---| | 14:17:30 | normal | normal | normal | normal | normal | | 14:17:32 | Verbindung hängt | Uplink-Drops steigen | Sitzungen normal | Anfragen warten | Timeout beginnt | | 14:17:35 | Ziel nicht erreichbar | Uplink 100 % | Paketverluste | keine neuen Anfragen | Fehlermeldung | | 14:17:42 | Verbindung wieder da | Drops sinken | normal | Anfragen treffen ein | Wiederherstellung | | 14:18:00 | normal | normal | normal | normal | normal | Die gemeinsame Zeitleiste zeigt, welche Veränderung zuerst auftrat. ```text Uplink-Auslastung und Drops ↓ Paketverlust ↓ Server nicht erreichbar ↓ Anwendungs-Timeout ``` Ein Anwendungsfehler am Ende der Kette ist in diesem Beispiel nicht automatisch die ursprüngliche Ursache. --- **30. Reihenfolge von Ursache und Folge beachten** Gleichzeitig protokollierte Fehler können unterschiedliche Rollen besitzen. **Beispiel** ```text 14:17:32 Switchport verliert Link 14:17:33 Client verliert Netzwerk 14:17:34 DNS-Abfrage schlägt fehl 14:17:35 Anwendung meldet Serverfehler ``` Mögliche Reihenfolge: ```text Switchportproblem ↓ Netzwerkverlust ↓ DNS-Fehler ↓ Anwendungsfehler ``` Der DNS-Fehler und der Anwendungsfehler sind hier wahrscheinlich Folgen des vorherigen Linkverlusts. Deshalb ist zu fragen: - Welches Ereignis trat zuerst auf? - Welche Systeme sind voneinander abhängig? - Welches Ereignis erklärt die nachfolgenden Fehler? - Welcher Messwert änderte sich bereits vor der Benutzermeldung? - Welche Meldung beschreibt nur eine Folge? --- **31. Kontrollierte Reproduktion versuchen** Wenn ein Muster erkannt wurde, kann eine kontrollierte Reproduktion möglich sein. Beispiele: - gleiche Aktion wiederholen, - gleiche Sitzungsdauer abwarten, - denselben Netzwerkpfad verwenden, - Last unter kontrollierten Bedingungen erzeugen, - Test vor und während eines geplanten Prozesses durchführen, - betroffenes und funktionierendes Gerät vergleichen, - unterschiedliche Serverknoten gezielt prüfen, - WLAN und Ethernet vergleichen. Dabei gelten folgende Regeln: 1. nur autorisierte Tests durchführen, 2. Ausgangszustand dokumentieren, 3. erwartete Beobachtung festlegen, 4. nur einen Einflussfaktor verändern, 5. Messwerte während des Tests erfassen, 6. Test bei unerwarteten Auswirkungen abbrechen, 7. ursprünglichen Zustand wiederherstellen, 8. Ergebnis dokumentieren. Ein produktiver Fehler darf nicht absichtlich durch riskante Last, Stromunterbrechung, Sicherheitsdeaktivierung oder unkontrollierte Netzwerkänderung provoziert werden. --- **32. Hypothese messbar formulieren** Ungeeignet: ```text Vielleicht ist das Netzwerk schuld. ``` Besser: ```text Wenn der Fehler auftritt, verliert der Client vermutlich kurzzeitig die Verbindung zum Standardgateway. ``` Prüfung: ```text Client → Gateway kontinuierlich messen Client → Server kontinuierlich messen Client- und Switchportprotokolle vergleichen ``` Noch genauer: ```text Wenn NB-023 den Fehler erneut zeigt, muss innerhalb desselben Zeitfensters entweder ein Link-Down-Ereignis am Client oder am Switchport Gi1/0/12 sichtbar sein. ``` Eine gute Hypothese enthält: - erwartetes Ereignis, - betroffene Komponente, - Messwert, - Zeitfenster, - mögliche Widerlegung. --- **33. Genau eine kontrollierte Änderung durchführen** Nach ausreichender Eingrenzung wird nur eine Änderung vorgenommen. Mögliche kontrollierte Änderungen: - defektes Kabel ersetzen, - betroffenen Switchport wechseln, - vorgesehenen Treiber aktualisieren, - fehlerhaften Serverknoten aus dem Load Balancer nehmen, - geplanten Prozess nach Freigabe verschieben, - Sitzungs-Timeout abgestimmt korrigieren, - fehlerhafte DNS-Antwort korrigieren, - defekten Access Point ersetzen, - vorgesehene Bandbreitensteuerung anpassen, - fehlerhafte Stromversorgung austauschen. Nicht mehrere Änderungen gleichzeitig durchführen. Ungeeignet: ```text Kabel, Switchport, Treiber und DNS gleichzeitig ändern ``` Danach wäre nicht mehr feststellbar, welche Änderung wirksam war. --- **34. Rollback festlegen** Vor der Änderung dokumentieren: - ursprüngliche Konfiguration, - ursprüngliche Version, - ursprünglicher Zeitplan, - ursprünglicher Port, - ursprüngliche Verkabelung, - Sicherung vorhandener Einstellungen, - verantwortliche Person, - erlaubtes Änderungsfenster, - Abbruchkriterium, - Rückweg. **Beispiel** ```text Änderung: Backupstart von 14:00 Uhr auf 22:00 Uhr verschieben. Rollback: Ursprünglichen Startzeitpunkt 14:00 Uhr wiederherstellen. Abbruchkriterium: Sicherung startet nicht oder überschneidet sich mit einem anderen Auftrag. ``` --- **35. Verifikation über ausreichend lange Zeit durchführen** Bei einem sporadischen Fehler reicht ein einzelner erfolgreicher Test nicht aus. **Beispiel** ```text Fehler trat bisher ungefähr einmal täglich auf. Nach der Änderung war das System 15 Minuten stabil. ``` Dieses Ergebnis ist noch kein ausreichender Nachweis. Besser: ```text Beobachtungszeitraum vor Änderung: 7 Tage Fehlerhäufigkeit vorher: 1 bis 3 Ereignisse pro Tag Beobachtungszeitraum nach Änderung: 7 Tage Fehlerhäufigkeit nachher: 0 Ereignisse ``` Zusätzlich prüfen: - ursprüngliche Symptome, - technische Messwerte, - Protokolle, - Fehlerzähler, - Nebenwirkungen, - Sicherheitsfunktionen, - abhängige Systeme, - Benutzerbestätigung. --- **36. Beispiel für eine systematische Diagnose** **Symptom** Mehrere Benutzer melden an Werktagen gegen 14:17 Uhr kurze Verbindungsabbrüche zu verschiedenen internen Diensten. **Erste Beobachtung** ```text Dauer: 10 bis 20 Sekunden Betroffene Clients: mehrere Betroffene Dienste: ERP, Dateiserver und Intranet Gateway: während der Störung erreichbar Interne Server: während der Störung teilweise nicht erreichbar ``` **Kontinuierliche Messung** ```text 14:17:30 Gateway: 1 ms 14:17:30 Dateiserver: 2 ms 14:17:35 Gateway: 1 ms 14:17:35 Dateiserver: Zeitüberschreitung 14:17:40 Gateway: 1 ms 14:17:40 Dateiserver: Zeitüberschreitung 14:17:45 Gateway: 1 ms 14:17:45 Dateiserver: 2 ms ``` **Switch-Monitoring** ```text 14:17:33 Server-Uplink erreicht 100 % Auslastung 14:17:34 Output Drops steigen 14:17:44 Auslastung sinkt 14:17:45 Output Drops steigen nicht weiter ``` **Zeitgesteuerte Aufgaben** ```text 14:17:30 Replikationsauftrag startet 14:17:45 Replikationsauftrag beendet ``` **Hypothese** Der Replikationsauftrag überlastet kurzzeitig den gemeinsamen Server-Uplink. Die entstehenden Warteschlangen und Drops verursachen Paketverlust und Anwendungsabbrüche. **Kontrollierte Maßnahme** Nach betrieblicher Freigabe wird der Replikationsauftrag in ein geeignetes Zeitfenster verschoben und mit der vorgesehenen Bandbreitensteuerung versehen. **Rollback** ```text Ursprünglichen Zeitplan und ursprüngliche Bandbreitenrichtlinie wiederherstellen. ``` **Verifikation** ```text Beobachtungszeitraum: 7 Tage Unterbrechungen: keine Output Drops: keine neue Zunahme Anwendungsfehler: keine Replikation: weiterhin erfolgreich ``` **Festgestellte Ursache** Ein regelmäßig gestarteter Replikationsauftrag erzeugte eine kurzzeitige Überlastung des gemeinsamen Uplinks. --- **37. Beispiel „Fehler nach acht Stunden“** **Symptom** Ein Benutzer wird fast täglich am Nachmittag aus einer Anwendung abgemeldet. **Zeitvergleich** ```text Anmeldung: 08:05 Uhr Fehler: 16:05 Uhr Sitzungsdauer: 8 Stunden ``` Weitere Tage: ```text Anmeldung 07:58 Uhr → Fehler 15:58 Uhr Anmeldung 08:12 Uhr → Fehler 16:12 Uhr Anmeldung 08:03 Uhr → Fehler 16:03 Uhr ``` Das Problem tritt nicht zu einer festen Uhrzeit, sondern nach einer festen Sitzungsdauer auf. **Prüfbereich** - Access-Token, - Sitzungs-Timeout, - Refresh-Token, - Load Balancer, - Proxy, - Anwendungssitzung, - Authentifizierungsdienst. **Festgestellte Ursache** Die Anwendung erneuerte ein nach acht Stunden ablaufendes Token nicht korrekt. **Lehre** ```text Feste Uhrzeit und feste Laufzeit müssen unterschieden werden. ``` --- **38. Beispiel „sporadischer Fehler durch einen Serverknoten“** **Symptom** Eine Webanwendung funktioniert meistens, zeigt aber gelegentlich einen TLS- oder Serverfehler. **Aufbau** ```text Client | Load Balancer | +-- Webserver 1 +-- Webserver 2 +-- Webserver 3 ``` **Beobachtung** | Zielknoten | Ergebnis | |---|---| | Webserver 1 | funktioniert | | Webserver 2 | funktioniert | | Webserver 3 | Fehler | | Zugriff über Load Balancer | nur gelegentlich Fehler | **Festgestellte Ursache** Nur Webserver 3 besitzt eine fehlerhafte Konfiguration. Der Fehler tritt deshalb nur auf, wenn der Load Balancer eine Anfrage diesem Knoten zuweist. **Lehre** Bei verteilten Systemen müssen alle Knoten einzeln verglichen werden. --- **39. Ungeeignete Sofortmaßnahmen** Nicht als erste Maßnahme verwenden: - System ohne Protokollsicherung neu starten, - Fehler als „nicht reproduzierbar“ schließen, - alle Protokolle pauschal löschen, - Fehlerzähler vor der Dokumentation zurücksetzen, - DNS-Cache vor der Bestandsaufnahme leeren, - mehrere Komponenten gleichzeitig ersetzen, - Monitoring unbegrenzt hochauflösend aktivieren, - unbegrenzten Paketmitschnitt starten, - Sicherheitsfunktionen deaktivieren, - VPN oder Authentifizierung umgehen, - Backups ohne Freigabe abschalten, - Sitzungszeiten pauschal erhöhen, - automatische Updates vollständig deaktivieren, - WLAN-Kanäle wahllos verändern, - Produktivsysteme unkontrolliert belasten, - aus einem einzelnen Ereignis eine Ursache ableiten, - nur auf die Aussage „jetzt funktioniert es“ vertrauen. Solche Maßnahmen können Beweise vernichten, neue Störungen verursachen oder Sicherheits- und Betriebsvorgaben verletzen. --- **40. Vollständige Prüfreihenfolge** 1. genaue Fehlermeldung und Benutzeraktion erfassen. 2. exakten Zeitpunkt und Dauer dokumentieren. 3. betroffenen Benutzer, Client und Standort bestimmen. 4. betroffene Anwendung und Zielsysteme erfassen. 5. prüfen, ob ein oder mehrere Benutzer betroffen sind. 6. feste Uhrzeit von fester Laufzeit unterscheiden. 7. Häufigkeit und wiederkehrendes Muster bestimmen. 8. Zeitsynchronisation aller beteiligten Systeme prüfen. 9. Monitoring- und Protokollaufbewahrung prüfen. 10. kontinuierliche Messung mit Zeitstempeln einrichten. 11. Gateway, internes Ziel und externes Ziel vergleichen. 12. TCP-Port und Anwendungsantwort getrennt prüfen. 13. Windows- oder Linux-Protokolle zeitlich filtern. 14. Client-, Netzwerk- und Serverprotokolle vergleichen. 15. Monitoringauflösung kontrolliert erhöhen. 16. Schnittstellenstatus und Link-Flaps beobachten. 17. Fehler- und Verwerfungszähler als Verlauf erfassen. 18. WLAN-Ereignisse, Roaming und Retry-Rate prüfen. 19. DHCP-Lease und mögliche Adresskonflikte untersuchen. 20. DNS-Auflösung, TTL und unterschiedliche Antworten prüfen. 21. Sitzungslaufzeiten, Token und Timeouts vergleichen. 22. Zertifikatslaufzeiten und Serverknoten prüfen. 23. geplante Aufgaben, Timer und Cronjobs untersuchen. 24. Backups, Scans, Updates und Replikationen vergleichen. 25. CPU, Arbeitsspeicher, Storage und Netzwerk überwachen. 26. Temperatur, Stromversorgung und PoE berücksichtigen. 27. WAN-, Provider- und VPN-Ereignisse prüfen. 28. bei Bedarf autorisierten Ringpuffer-Mitschnitt einrichten. 29. alle Ereignisse auf einer gemeinsamen Zeitleiste darstellen. 30. zuerst auftretendes Ereignis von Folgefehlern unterscheiden. 31. genau eine messbare Hypothese formulieren. 32. kontrollierte Reproduktion planen. 33. Ausgangszustand und Rollback dokumentieren. 34. genau eine freigegebene Änderung durchführen. 35. ursprüngliche Messungen wiederholen. 36. ausreichend langen Beobachtungszeitraum einhalten. 37. Nebenwirkungen und Sicherheitsfunktionen kontrollieren. 38. temporäre Diagnosemaßnahmen entfernen. 39. Ursache, Maßnahme, Rollback und Nachweis dokumentieren. --- **41. Checkliste „Fehler tritt nur manchmal auf“** - [ ] genaue Fehlermeldung wurde dokumentiert. - [ ] Benutzeraktion wurde beschrieben. - [ ] exakter Zeitpunkt wurde erfasst. - [ ] Dauer des Fehlers wurde erfasst. - [ ] betroffener Benutzer wurde bestimmt. - [ ] betroffener Client wurde bestimmt. - [ ] Standort und Netzwerkverbindung wurden erfasst. - [ ] Anwendung und Zielsystem wurden bestimmt. - [ ] Anzahl der betroffenen Benutzer wurde geprüft. - [ ] feste Uhrzeit und feste Laufzeit wurden unterschieden. - [ ] Häufigkeit wurde dokumentiert. - [ ] wiederkehrendes Muster wurde gesucht. - [ ] Zeitzonen wurden berücksichtigt. - [ ] Zeitsynchronisation wurde geprüft. - [ ] kontinuierliche Messung wurde eingerichtet. - [ ] Messungen enthalten Zeitstempel. - [ ] Gateway wurde überwacht. - [ ] internes Ziel wurde überwacht. - [ ] externes Ziel wurde berücksichtigt. - [ ] TCP-Port wurde getrennt geprüft. - [ ] Anwendungsantwort wurde getrennt geprüft. - [ ] Windows-Ereignisprotokolle wurden geprüft. - [ ] Linux-Systemprotokolle wurden geprüft. - [ ] Anwendungsprotokolle wurden geprüft. - [ ] Netzwerkgeräteprotokolle wurden geprüft. - [ ] Protokollaufbewahrung wurde geprüft. - [ ] Monitoringauflösung wurde geprüft. - [ ] kurzfristige Spitzen wurden berücksichtigt. - [ ] Interface-Flapping wurde geprüft. - [ ] Fehlerzähler wurden als Verlauf dokumentiert. - [ ] CRC-/FCS-Fehler wurden berücksichtigt. - [ ] Drops und Discards wurden berücksichtigt. - [ ] DHCP-Lease wurde geprüft. - [ ] IP-Adresskonflikte wurden berücksichtigt. - [ ] DNS-Auflösung wurde wiederholt geprüft. - [ ] DNS-TTL wurde berücksichtigt. - [ ] unterschiedliche DNS-Antworten wurden verglichen. - [ ] Sitzungs- und Idle-Timeouts wurden geprüft. - [ ] Tokenlaufzeiten wurden geprüft. - [ ] Zertifikatslaufzeiten wurden geprüft. - [ ] alle Serverknoten wurden verglichen. - [ ] geplante Aufgaben wurden geprüft. - [ ] Backups und Replikationen wurden berücksichtigt. - [ ] Virenscans und Updates wurden berücksichtigt. - [ ] CPU- und Speicherauslastung wurden beobachtet. - [ ] Storage-Latenz wurde beobachtet. - [ ] WLAN-Roaming und Funkstörungen wurden berücksichtigt. - [ ] Provider-, WAN- und VPN-Ereignisse wurden geprüft. - [ ] Temperatur und Stromversorgung wurden berücksichtigt. - [ ] erforderlicher Paketmitschnitt wurde autorisiert. - [ ] Ringpuffer und Speichergrenze wurden festgelegt. - [ ] gemeinsame Ereigniszeitleiste wurde erstellt. - [ ] Ursache und Folge wurden unterschieden. - [ ] genau eine Hypothese wurde formuliert. - [ ] Ausgangszustand wurde dokumentiert. - [ ] Rollback wurde festgelegt. - [ ] nur eine kontrollierte Änderung wurde durchgeführt. - [ ] ausreichend lange Verifikation wurde durchgeführt. - [ ] Nebenwirkungen wurden geprüft. - [ ] temporäre Diagnosemaßnahmen wurden entfernt. - [ ] Ursache, Maßnahme und Nachweis wurden dokumentiert. --- **42. Schnellreferenz** | Beobachtung | Nächster Prüfbereich | |---|---| | Fehler immer zur gleichen Uhrzeit | geplante Aufgaben, Backups, Scans oder Updates | | Fehler immer nach gleicher Laufzeit | Sitzung, Token, Lease, Timeout oder Zertifikat | | nur ein Client betroffen | Client, Treiber, Kabel, WLAN oder lokale Software | | mehrere Clients gleichzeitig betroffen | gemeinsame Infrastruktur oder zentraler Dienst | | Gateway ebenfalls nicht erreichbar | Clientzugang, WLAN, Switchport oder lokales Netz | | Gateway erreichbar, Server nicht | interner Folgepfad, Servernetz oder Server | | nur Anwendung fehlerhaft | Dienst, Sitzung, Datenbank oder Anwendung | | nur ein Serverknoten fehlerhaft | Konfiguration dieses Knotens | | Link-Up-/Link-Down-Ereignisse | Kabel, Port, Transceiver, Treiber oder Stromversorgung | | CRC-Fehler steigen kurzzeitig | physischer Übertragungsweg | | Output Drops steigen kurzzeitig | Auslastung oder nachgelagerter Engpass | | Fehler während Backup | Netzwerk-, CPU- oder Storage-Auslastung vergleichen | | Fehler beim DNS-TTL-Ablauf | DNS-Server, Cache und Zieladressen vergleichen | | Fehler bei DHCP-Erneuerung | DHCP-Server, Lease und Adresskonflikte | | Fehler nur im WLAN | Funkstrecke, Roaming, Kanal, Airtime oder Access Point | | Fehler nur über VPN | Tunnel, Gateway, Timeout, MTU oder Internetpfad | | Fehler bei hoher Temperatur | Kühlung, Lüfter oder Hardware | | Monitoring zeigt nichts | Messintervall und Aggregation prüfen | | Neustart beseitigt Fehler vorübergehend | Zustand vor dem Neustart vollständig erfassen | | Ereignisse verschiedener Systeme passen nicht | Uhrzeit, Zeitzone und NTP prüfen | | Fehler nicht direkt reproduzierbar | kontinuierliche Messung und Ringpuffer einsetzen | --- **Merksatz** > Bei einem sporadischen Fehler ist der genaue Zeitpunkt der wichtigste Ausgangspunkt. Messungen und Protokolle müssen bereits vor dem nächsten Auftreten bereitstehen. Erst durch Zeitstempel, wiederkehrende Muster und eine gemeinsame Ereigniszeitleiste lassen sich Ursache und Folge zuverlässig voneinander unterscheiden. --- **Quellen und weiterführende Dokumentation** - [Microsoft Learn – Get-WinEvent](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.diagnostics/get-winevent) - [Microsoft Learn – Test-Connection](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.management/test-connection) - [Microsoft Learn – Test-NetConnection](https://learn.microsoft.com/en-us/powershell/module/nettcpip/test-netconnection) - [Microsoft Learn – Get-NetAdapterStatistics](https://learn.microsoft.com/en-us/powershell/module/netadapter/get-netadapterstatistics) - [Microsoft Learn – Resolve-DnsName](https://learn.microsoft.com/en-us/powershell/module/dnsclient/resolve-dnsname) - [Microsoft Learn – w32tm](https://learn.microsoft.com/en-us/windows-server/networking/windows-time-service/windows-time-service-tools-and-settings) - [Microsoft Learn – netsh wlan](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/netsh-wlan) - [Microsoft Learn – Get-ScheduledTask](https://learn.microsoft.com/en-us/powershell/module/scheduledtasks/get-scheduledtask) - [systemd – journalctl](https://www.freedesktop.org/software/systemd/man/latest/journalctl.html) - [systemd – systemctl](https://www.freedesktop.org/software/systemd/man/latest/systemctl.html) - [Wireshark – dumpcap Manual Page](https://www.wireshark.org/docs/man-pages/dumpcap.html) - [Wireshark – Capture Setup](https://www.wireshark.org/docs/wsug_html_chunked/ChCapCaptureOptions.html) - [Wireshark – User’s Guide](https://www.wireshark.org/docs/wsug_html/) - [Cisco – Troubleshoot Port Flaps on Catalyst 9000 Series Switches](https://www.cisco.com/c/en/us/support/docs/switches/catalyst-9500-series-switches/218397-troubleshoot-port-flaps-on-catalyst-9000.html) - [Cisco – Troubleshoot Link Flap Issues on Nexus 9000](https://www.cisco.com/c/en/us/support/docs/switches/nexus-9000-series-switches/221572-troubleshoot-link-flap-issue-on-nexus-90.html) # 7.7 Netzwerk oder Anwendung ist langsam **1. Ziel dieser Seite** Die Meldung „Das Netzwerk ist langsam“ beschreibt zunächst nur die Wahrnehmung des Benutzers. Die tatsächliche Ursache kann unter anderem im Client, im Netzwerk, auf dem Server, im Storage, in der Datenbank oder in der Anwendung liegen. Diese Seite zeigt, wie ein Leistungsproblem systematisch eingegrenzt wird. Ziel ist die Unterscheidung zwischen: - langsamem Client, - langsamem Netzwerk, - hoher Latenz, - Paketverlust, - geringer verfügbarer Bandbreite, - ausgelastetem WLAN, - langsamem VPN, - überlastetem Server, - hoher Storage-Latenz, - blockierter Datenbank, - langsamem DNS, - fehlerhaftem Serverknoten, - Anwendungs- oder Schnittstellenproblem. --- **2. „Langsam“ messbar beschreiben** Ungeeignet: ```text Das Netzwerk ist langsam. ``` Besser: ```text Das Öffnen einer 20-MB-Datei vom Dateiserver dauert seit 09:30 Uhr ungefähr 45 Sekunden. Normalerweise dauert es weniger als 5 Sekunden. Betroffen sind drei Benutzer im zweiten Obergeschoss. Internetseiten und das Standardgateway reagieren normal. ``` Zu erfassen sind: - genaue Benutzeraktion, - betroffene Anwendung, - betroffene Datei oder Funktion, - Startzeitpunkt, - Dauer, - Häufigkeit, - betroffene Benutzer, - betroffene Clients, - Standort, - LAN, WLAN oder VPN, - internes oder externes Ziel, - erwartete Dauer, - tatsächlich gemessene Dauer, - Fehlermeldungen, - durchgeführte Änderungen. **Beispiel** | Merkmal | Beobachtung | |---|---| | Aktion | Öffnen einer Datei vom Dateiserver | | Dateigröße | 20 MB | | Normalzustand | 3 bis 5 Sekunden | | aktueller Zustand | 40 bis 50 Sekunden | | Beginn | seit ungefähr 09:30 Uhr | | Betroffene | drei Benutzer | | Standort | zweites Obergeschoss | | Verbindung | WLAN | | Internet | normal | | Gateway | normal erreichbar | | Dateiserver | hohe Antwortzeit | Erst durch einen solchen Vergleich wird aus einer subjektiven Meldung ein messbares Problem. --- **3. Wichtige Leistungsbegriffe unterscheiden** | Begriff | Bedeutung | |---|---| | Latenz | Zeit, die ein Datenpaket oder eine Anfrage bis zur Antwort benötigt | | Paketverlust | Anteil der Pakete, die ihr Ziel nicht erreichen | | Bandbreite | theoretisch oder technisch verfügbare Übertragungskapazität | | Durchsatz | tatsächlich übertragene Datenmenge pro Zeiteinheit | | Jitter | Schwankung der Laufzeit aufeinanderfolgender Pakete | | Antwortzeit | gesamte Dauer einer Anfrage aus Benutzersicht | | IOPS | Anzahl der Ein- und Ausgabeoperationen eines Speichers pro Sekunde | | Storage-Latenz | Wartezeit einer Speicheroperation | | CPU-Auslastung | Anteil der aktuell verwendeten Prozessorleistung | | Arbeitsspeicherauslastung | Belegung des physischen Arbeitsspeichers | | Warteschlange | Anforderungen, die auf Verarbeitung oder Übertragung warten | | Retransmission | erneute Übertragung verlorener oder nicht bestätigter TCP-Daten | | Applikationslatenz | Zeit, welche die Anwendung für die Verarbeitung benötigt | Eine schnelle Netzwerkverbindung garantiert keinen hohen Anwendungsdurchsatz. **Beispiel** ```text Verbindungsgeschwindigkeit: 1 Gbit/s tatsächlicher Dateidurchsatz: 8 Mbit/s ``` Die angezeigte Verbindungsgeschwindigkeit beschreibt nur die ausgehandelte Verbindung. Sie beweist nicht, dass die gesamte Strecke oder das Zielsystem diese Datenrate bereitstellen kann. --- **4. Mögliche Ursachenbereiche** ```text Benutzeraktion ↓ Client ↓ lokale Verbindung ↓ Switch, WLAN oder VPN ↓ Routing, Firewall oder WAN ↓ Server ↓ Anwendung ↓ Datenbank oder Storage ``` Eine Verzögerung kann an jeder Stelle dieser Kette entstehen. **Client** - hohe CPU-Auslastung, - unzureichender Arbeitsspeicher, - langsamer Datenträger, - Hintergrundprogramme, - Virenscanner, - fehlerhafter Netzwerktreiber, - Energiesparmodus, - Browsererweiterungen, - lokaler DNS-Cache, - defekte Netzwerkkarte. **Netzwerk** - Paketverlust, - hohe Latenz, - Interface-Fehler, - Duplex- oder Geschwindigkeitsproblem, - ausgelasteter Uplink, - Queue Drops, - fehlerhaftes Kabel, - überlastetes WLAN, - Roaming, - VPN-Überlastung, - MTU-Problem, - fehlerhaftes Routing, - langsame Namensauflösung. **Server** - hohe CPU-Auslastung, - zu wenig Arbeitsspeicher, - Paging oder Swapping, - hohe Storage-Latenz, - volle Datenträger, - überlastete Netzwerkschnittstelle, - zu viele gleichzeitige Sitzungen, - blockierte Prozesse, - Virenscan, - Backup, - Snapshot, - überlasteter Hypervisor. **Anwendung und Datenbank** - langsame Datenbankabfrage, - fehlender Datenbankindex, - Datenbanksperre, - erschöpfter Verbindungspool, - langsame API, - externer Dienst, - fehlerhafter Serverknoten, - Anwendungsfehler, - ungeeignete Zeitüberschreitung, - große oder ineffiziente Abfrage, - überlastete Hintergrundverarbeitung. --- **5. Zuerst den Umfang bestimmen** Zu klären ist: 1. Ist nur ein Benutzer betroffen? 2. Sind mehrere Benutzer betroffen? 3. Ist nur ein Standort betroffen? 4. Sind nur WLAN-Benutzer betroffen? 5. Sind auch kabelgebundene Clients betroffen? 6. Ist nur eine Anwendung langsam? 7. Sind mehrere Dienste desselben Servers betroffen? 8. Sind interne und externe Ziele betroffen? 9. Tritt das Problem zu einer bestimmten Uhrzeit auf? 10. Tritt es nur bei einer bestimmten Datenmenge auf? **Schnelle Eingrenzung** | Beobachtung | Wahrscheinlicher Prüfbereich | |---|---| | nur ein Client betroffen | Client, Treiber, Kabel, WLAN oder lokale Software | | mehrere Clients gleichzeitig betroffen | gemeinsame Infrastruktur oder zentraler Dienst | | nur ein Standort betroffen | Standortanbindung, Switch, WLAN oder WAN | | nur WLAN betroffen | Funkstrecke, Access Point, Kanal oder Roaming | | LAN und WLAN betroffen | gemeinsamer Netzwerkpfad, Server oder Anwendung | | nur eine Anwendung betroffen | Anwendung, Datenbank, API oder Sitzung | | mehrere Dienste eines Servers betroffen | Server, Betriebssystem, Storage oder Hypervisor | | alle internen Dienste langsam | Netzwerk, DNS, Firewall oder zentrale Infrastruktur | | nur Internet langsam | WAN, Provider, Proxy oder externe Ziele | | nur große Dateien langsam | Durchsatz, Paketverlust, Storage oder Übertragungsweg | | kleine Anfragen bereits langsam | Latenz, DNS, Anwendung oder Datenbank | --- **6. Vergleich mit einer funktionierenden Referenz** Ein Vergleichssystem sollte möglichst ähnlich sein: - gleicher Standort, - gleiches Netzwerk, - gleiche Anwendung, - gleiche Berechtigung, - gleiche Datenmenge, - gleicher Server, - ähnliche Hardware, - möglichst gleicher Zeitpunkt. **Beispiel** | Prüfung | betroffener Client | Vergleichsclient | |---|---:|---:| | Gateway-Latenz | 2 ms | 2 ms | | Server-Latenz | 3 ms | 3 ms | | Dateiübertragung | 4 MB/s | 85 MB/s | | CPU-Auslastung | 15 % | 20 % | | Datenträgerauslastung | 100 % | 8 % | In diesem Beispiel ist der Netzwerkpfad zunächst unauffällig. Die lokale Datenträgerauslastung des betroffenen Clients ist dagegen auffällig. --- **7. Baseline festlegen** Ein Messwert ist nur aussagekräftig, wenn bekannt ist, welcher Wert normalerweise erreicht wird. **Beispiel** ```text Normale Antwortzeit: 200 bis 400 ms Aktuelle Antwortzeit: 4 bis 8 Sekunden Normale Dateiübertragung: 80 bis 95 MB/s Aktuelle Übertragung: 5 bis 12 MB/s Normale Storage-Latenz: 2 bis 8 ms Aktuelle Storage-Latenz: 80 bis 250 ms ``` Mögliche Baselines: - Antwortzeit einer Anwendung, - Laufzeit einer Datenbankabfrage, - Ping-Latenz, - Paketverlust, - DNS-Antwortzeit, - Dateidurchsatz, - CPU-Auslastung, - Speicherauslastung, - Storage-Latenz, - Anzahl gleichzeitiger Sitzungen, - Fehlerrate, - Warteschlangenlänge. Messungen sollten möglichst unter vergleichbaren Bedingungen erfolgen. --- **8. Lokalen Client prüfen** Unter Windows: ```powershell Get-Process | Sort-Object CPU -Descending | Select-Object -First 10 Name, CPU, WorkingSet ``` Netzwerkadapter anzeigen: ```powershell Get-NetAdapter | Format-Table Name, Status, LinkSpeed, InterfaceDescription ``` Adapterstatistiken: ```powershell Get-NetAdapterStatistics ``` Aktuelle IP-Konfiguration: ```cmd ipconfig /all ``` Unter Linux: ```bash top ``` Alternativ, sofern installiert: ```bash htop ``` Arbeitsspeicher: ```bash free -h ``` Datenträgerbelegung: ```bash df -h ``` Netzwerkschnittstellen: ```bash ip link show ``` Statistiken: ```bash ip -s link show ``` Zu prüfen sind: - CPU-Spitzen, - Speicherdruck, - Paging oder Swapping, - Datenträgerauslastung, - Hintergrundprozesse, - Synchronisationsprogramme, - Virenscanner, - Softwareupdates, - Treiberstatus, - ausgehandelte Verbindungsgeschwindigkeit, - Interface-Fehler, - Energiesparzustände. Ein ausgelasteter Client kann eine langsame Anwendung verursachen, obwohl Netzwerk und Server ordnungsgemäß arbeiten. --- **9. Latenz und Paketverlust messen** Unter Windows: ```cmd ping -t ``` Beispiel: ```cmd ping -t 192.0.2.10 ``` Unter Linux oder macOS: ```bash ping ``` Es sollten mehrere Ziele verglichen werden: ```text Client → Standardgateway Client → interner Server Client → externes Referenzziel ``` **Auswertung** | Gateway | interner Server | externes Ziel | Mögliche Eingrenzung | |---|---|---|---| | langsam | langsam | langsam | Clientzugang oder lokales Netzwerk | | normal | langsam | normal | interner Pfad oder Servernetz | | normal | normal | langsam | WAN, Provider oder externer Pfad | | normal | normal | normal | Anwendung, Port, Serverprozess oder Datenbank | | Paketverlust | Paketverlust | Paketverlust | lokale Verbindung oder gemeinsamer Uplink | Ping prüft ICMP-Erreichbarkeit. Eine normale Ping-Antwort beweist nicht, dass die Anwendung schnell arbeitet. --- **10. Netzwerkpfad untersuchen** Unter Windows: ```cmd tracert ``` Unter Linux: ```bash traceroute ``` Unter macOS: ```bash traceroute ``` Falls vorhanden, kann eine fortlaufende Pfadanalyse durchgeführt werden: ```bash mtr ``` Zu prüfen sind: - auffällige Latenzsprünge, - wechselnde Pfade, - Paketverlust, - Routingänderungen, - Unterschiede zwischen betroffenen und funktionierenden Clients. Ein Router muss ICMP-Antworten nicht mit derselben Priorität wie weitergeleiteten Verkehr behandeln. Ein auffälliger Zwischenknoten allein beweist deshalb noch keinen Fehler. Entscheidend ist, ob die Beeinträchtigung auch an nachfolgenden Zielen sichtbar bleibt. --- **11. TCP-Port getrennt prüfen** Unter Windows: ```powershell Test-NetConnection -Port ``` Beispiel: ```powershell Test-NetConnection fileserver.example.local -Port 445 ``` Weitere Beispiele: ```powershell Test-NetConnection webserver.example.local -Port 443 ``` ```powershell Test-NetConnection dbserver.example.local -Port 1433 ``` Unter Linux oder macOS, sofern Netcat vorhanden ist: ```bash nc -vz ``` Beispiel: ```bash nc -vz webserver.example.local 443 ``` Damit wird geprüft, ob der TCP-Verbindungsaufbau möglich ist. Die tatsächliche Antwortzeit der Anwendung wird dadurch noch nicht vollständig gemessen. --- **12. Anwendungsantwort mit curl messen** Gesamte Antwortzeit: ```bash curl \ -o /dev/null \ -s \ -w "DNS: %{time_namelookup}\nTCP: %{time_connect}\nTLS: %{time_appconnect}\nErstes Byte: %{time_starttransfer}\nGesamt: %{time_total}\n" \ https://example.com/ ``` Beispielausgabe: ```text DNS: 0.012 TCP: 0.028 TLS: 0.071 Erstes Byte: 3.842 Gesamt: 3.901 ``` Interpretation: - DNS langsam: Namensauflösung untersuchen, - TCP langsam: Netzwerkpfad oder Zielsystem prüfen, - TLS langsam: Zertifikatsprüfung, Proxy oder Serverlast prüfen, - erstes Byte langsam: Anwendung, Server oder Datenbank prüfen, - Download nach dem ersten Byte langsam: Durchsatz oder Datenmenge prüfen. **Vergleich** ```text DNS: 0,012 Sekunden TCP: 0,028 Sekunden TLS: 0,071 Sekunden Erstes Byte: 3,842 Sekunden ``` Das Netzwerk baut die Verbindung schnell auf. Die lange Wartezeit bis zum ersten Byte weist eher auf die Verarbeitung im Zielsystem hin. --- **13. DNS-Antwortzeit prüfen** Unter Windows: ```powershell Measure-Command { Resolve-DnsName } ``` Einzelne DNS-Abfrage: ```powershell Resolve-DnsName ``` Unter Linux oder macOS, sofern `dig` vorhanden ist: ```bash dig ``` Kurze Ausgabe: ```bash dig +stats ``` Zu prüfen sind: - Antwortzeit, - verwendeter DNS-Server, - unterschiedliche Antworten, - Zeitüberschreitungen, - fehlerhafte Weiterleitung, - IPv4- und IPv6-Verhalten, - Suchdomänen, - Split-DNS, - mehrere Zieladressen. **Beispiel** ```text Aufruf über IP-Adresse: 0,4 Sekunden Aufruf über Hostnamen: 5,2 Sekunden ``` Dieser Unterschied weist auf die Namensauflösung hin. Er beweist noch nicht, welcher DNS-Server oder welche DNS-Konfiguration die Verzögerung verursacht. --- **14. Durchsatz messen** Für eine kontrollierte Netzwerkmessung kann `iperf3` verwendet werden. Dafür wird auf einem autorisierten Zielsystem ein `iperf3`-Server benötigt. Server: ```bash iperf3 -s ``` Client: ```bash iperf3 -c ``` Messung in Gegenrichtung: ```bash iperf3 -c -R ``` Mehrere parallele Verbindungen: ```bash iperf3 -c -P 4 ``` UDP-Tests dürfen nur kontrolliert und mit begrenzter Bandbreite durchgeführt werden: ```bash iperf3 -c -u -b 10M ``` Zu vergleichen sind: - Senderichtung, - Empfangsrichtung, - LAN, - WLAN, - VPN, - betroffener Client, - Referenzclient, - verschiedene Zeitpunkte. **Wichtig** Ein unkontrollierter Durchsatztest kann produktive Verbindungen beeinträchtigen. Zielsystem, Testdauer und erzeugte Last müssen abgestimmt sein. --- **15. Dateitransfer richtig bewerten** Ein Dateitransfer misst nicht ausschließlich das Netzwerk. Beteiligt sind: ```text Quelldatenträger ↓ Quellsystem ↓ Netzwerk ↓ Zielsystem ↓ Zieldatenträger ``` Mögliche Begrenzungen: - langsamer Quelldatenträger, - langsamer Zieldatenträger, - Virenscanner, - Dateisystem, - Verschlüsselung, - SMB- oder NFS-Konfiguration, - viele kleine Dateien, - Kompression, - CPU-Auslastung, - Netzwerkdurchsatz, - Storage-Latenz. **Beispiel** ```text Eine Datei mit 10 GB: 80 MB/s 100.000 sehr kleine Dateien: 8 MB/s ``` Viele kleine Dateien erzeugen wesentlich mehr Verwaltungs- und Speicheroperationen. Die niedrigere Übertragungsrate beweist deshalb nicht automatisch ein Netzwerkproblem. --- **16. Interface-Fehler und Drops prüfen** Unter Windows: ```powershell Get-NetAdapterStatistics ``` Unter Linux: ```bash ip -s link show ``` Auf einem verwalteten Switch müssen die herstellerspezifischen Diagnosebefehle verwendet werden. Zu beobachten sind: - CRC-/FCS-Fehler, - Input Errors, - Output Errors, - Discards, - Queue Drops, - Interface Resets, - Kollisionen, - Link-Flaps, - Geschwindigkeits- und Duplexaushandlung. Zähler müssen als Verlauf betrachtet werden. **Beispiel** ```text 09:00 Uhr: 15 CRC-Fehler 09:30 Uhr: 15 CRC-Fehler 10:00 Uhr: 15 CRC-Fehler ``` Der Zähler steigt nicht. Die Fehler können aus einem früheren Zeitraum stammen. ```text 09:00 Uhr: 15 CRC-Fehler 09:30 Uhr: 280 CRC-Fehler 10:00 Uhr: 4.500 CRC-Fehler ``` Der Zähler nimmt aktuell zu und weist auf ein Problem des physischen Übertragungswegs hin. --- **17. Duplex und Verbindungsgeschwindigkeit prüfen** Mögliche Symptome: - geringer Durchsatz, - hohe Anzahl von Fehlern, - Kollisionen, - stark unterschiedliche Sende- und Empfangsleistung, - Verbindung handelt nur 100 Mbit/s statt 1 Gbit/s aus. Zu prüfen sind: - Clientadapter, - Switchport, - Kabelkategorie, - Stecker, - Dockingstation, - Medienkonverter, - Transceiver, - automatische Aushandlung. Geschwindigkeit und Duplex dürfen nicht wahllos fest eingestellt werden. Beide Seiten müssen zusammenpassen und die Änderung muss dokumentiert sowie freigegeben sein. --- **18. WLAN-Leistung untersuchen** Bei WLAN-Verbindungen sind zusätzlich zu betrachten: - Signalstärke, - Signal-Rausch-Abstand, - Kanalauslastung, - Retry-Rate, - verwendetes Frequenzband, - Kanalbreite, - Anzahl aktiver Clients, - Airtime, - Roaming, - Access-Point-Auslastung, - DFS-Kanalwechsel, - Störquellen, - AP-Uplink, - PoE-Versorgung. Unter Windows: ```cmd netsh wlan show interfaces ``` WLAN-Bericht: ```cmd netsh wlan show wlanreport ``` Wichtiger Vergleich: | Test | LAN | WLAN | Eingrenzung | |---|---|---|---| | Anwendung | schnell | langsam | WLAN oder Access Point | | Anwendung | langsam | langsam | gemeinsamer Pfad, Server oder Anwendung | | nur ein WLAN-Client langsam | – | betroffen | Client, Treiber, Standort oder Funkband | | alle Clients eines AP langsam | – | betroffen | Access Point, Kanal, Uplink oder PoE | Ein hoher angezeigter WLAN-Verbindungswert entspricht nicht automatisch dem tatsächlichen Nutzdurchsatz. --- **19. VPN-Verbindung untersuchen** Mögliche Ursachen: - hohe Internetlatenz, - Paketverlust, - überlastetes VPN-Gateway, - Verschlüsselungslast, - ungeeignete MTU, - getunnelter Internetverkehr, - langsamer DNS-Server, - geografische Entfernung, - WLAN-Probleme des Benutzers, - Bandbreitenbegrenzung, - Neuaufbau des Tunnels. Zu vergleichen sind: ```text ohne VPN → internes Testziel, sofern autorisiert erreichbar mit VPN → internes Testziel mit VPN → Standardgateway des lokalen Netzes mit VPN → VPN-Gateway ``` Außerdem sollte geprüft werden: - betrifft es alle VPN-Benutzer, - betrifft es nur einen Internetanbieter, - tritt es nur zu bestimmten Zeiten auf, - ist nur eine Anwendung betroffen, - sind Senden und Empfangen unterschiedlich langsam, - steigt die CPU-Auslastung des VPN-Gateways, - treten Tunnelabbrüche oder Neuverbindungen auf. VPN- oder Sicherheitsfunktionen dürfen nicht zur Diagnose umgangen werden. --- **20. Serverressourcen prüfen** Wichtige Messwerte: - CPU-Auslastung, - CPU-Warteschlange, - Arbeitsspeicher, - Paging oder Swapping, - Datenträgerauslastung, - Storage-Latenz, - freie Speicherkapazität, - Netzwerkauslastung, - aktive Sitzungen, - Prozessanzahl, - Container- oder VM-Grenzen, - Hypervisor-Auslastung. Unter Linux: ```bash uptime ``` ```bash free -h ``` ```bash df -h ``` ```bash top ``` Falls installiert: ```bash vmstat 1 ``` ```bash iostat -xz 1 ``` Unter Windows können Task-Manager, Ressourcenmonitor, Leistungsüberwachung und PowerShell verwendet werden. Beispiel für Prozesse mit hoher CPU-Zeit: ```powershell Get-Process | Sort-Object CPU -Descending | Select-Object -First 10 Name, CPU, WorkingSet ``` Ein einzelner aktueller Messwert reicht bei sporadischen Problemen nicht aus. Die Werte müssen während der tatsächlichen Verzögerung aufgezeichnet werden. --- **21. CPU-Auslastung richtig interpretieren** Eine hohe CPU-Auslastung kann auf einen Engpass hinweisen, muss aber im Zusammenhang betrachtet werden. Zu prüfen sind: - Gesamtauslastung, - Auslastung einzelner Kerne, - Prozess mit hoher CPU-Nutzung, - Laufzeit der hohen Last, - Warteschlangen, - virtuelle CPU-Zuteilung, - CPU-Limits von Containern, - Steal Time bei virtuellen Systemen, - thermische Drosselung. **Beispiel** ```text Gesamtauslastung: 35 % Anwendungsprozess: ein Prozesskern dauerhaft bei 100 % ``` Eine nicht ausreichend parallelisierte Anwendung kann bereits durch einen vollständig ausgelasteten Kern begrenzt werden, obwohl die Gesamtauslastung unauffällig wirkt. --- **22. Arbeitsspeicher und Paging prüfen** Hohe Speicherbelegung allein beweist keinen Fehler. Betriebssysteme nutzen freien Arbeitsspeicher häufig als Cache. Wichtiger sind: - verfügbarer Arbeitsspeicher, - Paging oder Swapping, - Speicherdruck, - Speicherwachstum eines Prozesses, - Out-of-Memory-Ereignisse, - Container- oder VM-Limits, - wiederholte Prozessabbrüche. **Typische Wirkung** ```text Arbeitsspeicher reicht nicht aus ↓ Auslagerung auf Datenträger ↓ Storage-Latenz steigt ↓ Anwendung reagiert langsam ``` Deshalb müssen Arbeitsspeicher- und Storage-Messwerte gemeinsam betrachtet werden. --- **23. Storage-Latenz untersuchen** Eine hohe Datenträgerauslastung bedeutet nicht automatisch einen hohen Datendurchsatz. Viele kleine oder zufällige Operationen können einen Datenträger vollständig auslasten. Zu prüfen sind: - Lese- und Schreiblatenz, - Warteschlangentiefe, - IOPS, - Durchsatz, - freie Kapazität, - Dateisystem, - RAID-Zustand, - Controllerzustand, - Cache, - SAN- oder NAS-Verbindung, - Snapshots, - Replikation, - Backup, - Virenscan, - Thin Provisioning, - Storage-Überbelegung. **Beispiel** ```text Netzwerkauslastung: 12 % CPU-Auslastung: 30 % Storage-Latenz: 180 ms Anwendungsantwort: 8 s ``` Die niedrige Netzwerkauslastung spricht gegen einen reinen Bandbreitenengpass. Die hohe Storage-Latenz ist dagegen auffällig. Hersteller- und betriebssystemspezifische Grenzwerte müssen anhand der jeweiligen Dokumentation und des normalen Betriebszustands bewertet werden. --- **24. Datenbank als Ursache untersuchen** Mögliche Ursachen: - langsame Abfrage, - fehlender Index, - Datenbanksperre, - Deadlock, - zu viele gleichzeitige Verbindungen, - erschöpfter Verbindungspool, - hohe Storage-Latenz, - Statistik- oder Wartungsproblem, - große Ergebnismenge, - ungeeigneter Ausführungsplan, - Replikationsverzögerung. Zu vergleichen sind: - Dauer der Benutzeranfrage, - Dauer der zugehörigen Datenbankabfrage, - Wartezeiten, - Sperren, - Anzahl aktiver Verbindungen, - CPU- und Storage-Auslastung, - Zeitpunkt von Wartungsaufgaben, - Verhalten vergleichbarer Abfragen. **Beispiel** ```text TCP-Verbindung zum Webserver: 20 ms Antwort des Webservers: 6 s Datenbankabfrage: 5,7 s ``` Das Netzwerk ist in diesem Beispiel nicht der größte Zeitanteil. Die Datenbankabfrage bestimmt nahezu die gesamte Antwortzeit. Produktive Abfragen dürfen nicht unkontrolliert wiederholt oder verändert werden. Datenbankdiagnosen müssen mit den vorgesehenen Werkzeugen und Berechtigungen erfolgen. --- **25. Anwendungs- und API-Abhängigkeiten prüfen** Eine Anwendung kann von mehreren Diensten abhängig sein: ```text Client ↓ Webanwendung ↓ Authentifizierungsdienst ↓ API ↓ Datenbank ↓ Storage ``` Zu prüfen sind: - Antwortzeit jeder Abhängigkeit, - externe APIs, - Authentifizierungsdienst, - Verzeichnisdienst, - DNS, - Proxy, - Nachrichtenwarteschlange, - Datenbank, - Storage, - Cache, - Rate Limits, - Zeitüberschreitungen. **Beispiel** ```text Anwendung selbst: 100 ms externe API: 4.800 ms Gesamtantwort: 5.100 ms ``` Aus Benutzersicht ist die Anwendung langsam. Die eigentliche Verzögerung entsteht jedoch bei einer externen API. --- **26. Load Balancer und mehrere Serverknoten prüfen** Bei verteilten Anwendungen kann nur ein einzelner Knoten langsam sein. **Beispiel** | Zielknoten | Antwortzeit | |---|---:| | Webserver 1 | 250 ms | | Webserver 2 | 230 ms | | Webserver 3 | 8.400 ms | | Zugriff über Load Balancer | wechselnd zwischen schnell und langsam | Mögliche Ursachen des einzelnen Knotens: - andere Konfiguration, - fehlerhafte Softwareversion, - hohe CPU-Auslastung, - langsames Storage, - fehlerhaftes Zertifikat, - fehlende Verbindung zur Datenbank, - defekter Cache, - Hintergrundprozess, - ungleiche Lastverteilung. Alle Knoten müssen einzeln verglichen werden. Ein gelegentlich langsamer Zugriff über den Load Balancer kann entstehen, wenn nur ein Teil der Anfragen an den fehlerhaften Knoten gelangt. --- **27. Zeitgesteuerte Last berücksichtigen** Leistungsprobleme können regelmäßig mit anderen Prozessen zusammenfallen: - Backup, - Snapshot, - Replikation, - Virenscan, - Softwareverteilung, - Update, - Datenimport, - Export, - Berichterstellung, - Indexierung, - Datenbankwartung, - Logrotation, - Cloud-Synchronisation. **Beispiel** ```text 02:00:00 Backup startet 02:00:12 Storage-Latenz steigt 02:00:18 Datenbankabfragen werden langsamer 02:00:25 Anwendung überschreitet Zeitlimit 02:20:00 Backup endet 02:20:15 Storage-Latenz normalisiert sich ``` Eine gemeinsame Zeitleiste zeigt die mögliche Abhängigkeit. Der zeitliche Zusammenhang ist ein Hinweis. Die Ursache muss durch Messwerte und gegebenenfalls eine kontrollierte Änderung bestätigt werden. --- **28. Paketmitschnitt gezielt einsetzen** Ein Paketmitschnitt kann unter anderem zeigen: - TCP-Retransmissions, - Verbindungsabbrüche, - verzögerte Bestätigungen, - DNS-Zeitüberschreitungen, - lange Pausen zwischen Anfrage und Antwort, - wiederholte Verbindungsaufbauten, - TCP-Zero-Window-Ereignisse, - TLS-Verbindungsaufbau, - unterschiedliche Serverziele. Beispiel mit `dumpcap`: ```bash dumpcap \ -i 1 \ -f "host 192.0.2.45" \ -b duration:300 \ -b files:12 \ -w langsame-anwendung.pcapng ``` Dabei gelten folgende Regeln: - Mitschnitt autorisieren lassen, - richtige Schnittstelle auswählen, - Capture-Filter begrenzen, - Speicherbedarf begrenzen, - Datenschutz berücksichtigen, - Zeitpunkt des Problems dokumentieren, - Mitschnitt nach der Diagnose beenden, - Dateien geschützt speichern, - Dateien anschließend geregelt löschen. Ein Mitschnitt auf dem Client zeigt nicht automatisch alle Pakete anderer Systeme oder Netzwerksegmente. --- **29. TCP-Retransmissions bewerten** TCP überträgt verlorene Daten erneut. Viele erneute Übertragungen können den Durchsatz erheblich reduzieren. Mögliche Ursachen: - Paketverlust, - fehlerhaftes Kabel, - WLAN-Störungen, - überlastete Warteschlangen, - WAN-Probleme, - fehlerhafter Netzwerkadapter, - MTU-Problem, - überlastetes Zielsystem. **Vereinfachtes Beispiel** ```text Datenpaket wird gesendet ↓ Paket geht verloren ↓ Bestätigung bleibt aus ↓ TCP wartet ↓ Daten werden erneut übertragen ``` Die Bandbreite kann technisch hoch sein, während der tatsächlich nutzbare Durchsatz durch Paketverlust stark sinkt. --- **30. Ursache und Wartezeit trennen** Eine langsame Anwendung kann in verschiedene Zeitanteile zerlegt werden. **Beispiel** | Verarbeitungsschritt | Dauer | |---|---:| | DNS-Auflösung | 20 ms | | TCP-Verbindungsaufbau | 25 ms | | TLS-Verbindungsaufbau | 70 ms | | Webserververarbeitung | 180 ms | | Datenbankabfrage | 4.800 ms | | Übertragung der Antwort | 90 ms | | Gesamtdauer | 5.185 ms | Die Datenbankabfrage beansprucht den größten Teil der Gesamtdauer. Dadurch kann die Diagnose auf den Bereich mit dem größten Zeitanteil konzentriert werden. --- **31. Mehrere Systeme auf einer Zeitleiste vergleichen** | Zeit | Client | Netzwerk | Server | Storage | Anwendung | |---:|---|---|---|---|---| | 09:59:50 | normal | normal | normal | 4 ms | 300 ms | | 10:00:00 | Anfrage startet | normal | CPU 40 % | 8 ms | 400 ms | | 10:00:05 | wartet | normal | CPU 45 % | 170 ms | 5 s | | 10:00:10 | wartet | normal | CPU 48 % | 240 ms | 10 s | | 10:00:15 | Antwort | normal | CPU 42 % | 12 ms | normal | In diesem Beispiel steigen die Netzwerklatenz und CPU-Auslastung nicht auffällig. Die Storage-Latenz steigt dagegen zeitgleich mit der langsamen Anwendung. --- **32. Hypothese messbar formulieren** Ungeeignet: ```text Der Server ist wahrscheinlich überlastet. ``` Besser: ```text Wenn die Anwendung erneut länger als fünf Sekunden benötigt, steigt vermutlich gleichzeitig die Storage-Latenz des Datenbankservers auf mehr als 100 ms. ``` Prüfung: ```text Anwendungsantwortzeit messen Storage-Latenz aufzeichnen Datenbankwartezeiten erfassen Zeitstempel vergleichen ``` Eine gute Hypothese enthält: - konkrete Komponente, - erwarteten Messwert, - erwartete Veränderung, - Zeitfenster, - Möglichkeit der Widerlegung. --- **33. Kontrollierte Änderung durchführen** Erst nach ausreichender Eingrenzung wird genau eine Änderung vorgenommen. Mögliche Änderungen: - defektes Kabel ersetzen, - vorgesehenen Treiber aktualisieren, - fehlerhaften Switchport wechseln, - ungeeignete Sicherungszeit verschieben, - fehlerhaften Serverknoten aus der Verteilung nehmen, - abgestimmte Bandbreitensteuerung einrichten, - Datenbankabfrage optimieren, - fehlenden Index nach Prüfung ergänzen, - Ressourcenlimit korrigieren, - defekten Datenträger oder Access Point ersetzen. Ungeeignet: ```text Treiber aktualisieren, Kabel ersetzen, DNS ändern und Server neu starten. ``` Wenn mehrere Änderungen gleichzeitig durchgeführt werden, kann die wirksame Maßnahme nicht mehr eindeutig bestimmt werden. --- **34. Rollback festlegen** Vor jeder Änderung dokumentieren: - ursprüngliche Konfiguration, - ursprüngliche Version, - Ausgangsmesswerte, - verantwortliche Person, - Änderungsfenster, - erwartete Wirkung, - Abbruchkriterium, - Rückweg. **Beispiel** ```text Änderung: Fehlerhaften Webserver 3 kontrolliert aus dem Load Balancer nehmen. Erwartung: Die wechselnden Antwortzeiten verschwinden. Rollback: Webserver 3 mit der ursprünglichen Gewichtung wieder aufnehmen. Abbruchkriterium: Verbleibende Knoten überschreiten die zulässige Auslastung. ``` --- **35. Verifikation** Nach der Änderung müssen dieselben Messungen wie vorher wiederholt werden. Zu prüfen sind: - ursprüngliche Benutzeraktion, - Antwortzeit, - Latenz, - Paketverlust, - Durchsatz, - Fehlerzähler, - CPU-Auslastung, - Arbeitsspeicher, - Storage-Latenz, - Datenbankwartezeit, - Protokolle, - Nebenwirkungen, - Verhalten abhängiger Systeme. **Beispiel** ```text Vorher: Antwortzeit: 6 bis 12 Sekunden Storage-Latenz: 120 bis 260 ms Fehlerhäufigkeit: 20 bis 30 Ereignisse pro Stunde Nachher: Antwortzeit: 250 bis 400 ms Storage-Latenz: 3 bis 8 ms Fehlerhäufigkeit: 0 Ereignisse in 48 Stunden ``` Ein einzelner erfolgreicher Test reicht nicht aus, wenn das Problem vorher nur gelegentlich auftrat. --- **36. Beispiel „Netzwerk angeblich langsam“** **Symptom** Mehrere Benutzer melden, dass das Öffnen von Kundendatensätzen am Vormittag mehrere Sekunden dauert. **Erste Messungen** ```text Gateway-Latenz: 1 ms Webserver-Latenz: 2 ms Paketverlust: 0 % TCP-Verbindungsaufbau: 20 ms Zeit bis zum ersten Byte: 7 s ``` **Servermessungen** ```text CPU-Auslastung: 35 % Arbeitsspeicher: unauffällig Netzwerkauslastung: 10 % Storage-Latenz: 6 ms ``` **Datenbankmessung** ```text Abfragedauer: 6,7 s Warteursache: Datenbanksperre ``` **Festgestellte Ursache** Ein zeitgleich laufender Import hielt eine Datenbanksperre. Netzwerk und Webserver waren nicht die Ursache. **Kontrollierte Maßnahme** Der Importprozess wurde nach Prüfung so angepasst, dass die Sperre kürzer gehalten wird. **Verifikation** ```text Antwortzeit: 300 bis 450 ms Paketverlust: weiterhin 0 % Datenbanksperren: keine auffällige Wartezeit Import: weiterhin erfolgreich ``` --- **37. Beispiel „Dateiserver ist langsam“** **Symptom** Ein Benutzer erreicht beim Kopieren großer Dateien nur ungefähr 8 MB/s. **Vergleich** | Messung | betroffener Client | Referenzclient | |---|---:|---:| | Verbindung | 1 Gbit/s | 1 Gbit/s | | Ping zum Server | 2 ms | 2 ms | | `iperf3` | 920 Mbit/s | 925 Mbit/s | | Dateiübertragung | 8 MB/s | 90 MB/s | | lokale Datenträgerauslastung | 100 % | 15 % | **Festgestellte Ursache** Der lokale Zieldatenträger des betroffenen Clients war der Engpass. Die Netzwerkverbindung erreichte im kontrollierten Durchsatztest einen normalen Wert. **Lehre** ```text Ein langsamer Dateitransfer ist nicht automatisch ein langsames Netzwerk. ``` --- **38. Beispiel „WLAN ist langsam“** **Symptom** Benutzer in einem Besprechungsraum melden am Nachmittag langsame Anwendungen und Videokonferenzen. **Vergleich** ```text LAN: normal WLAN außerhalb des Raums: normal WLAN im Besprechungsraum: langsam ``` **Messwerte** ```text Signalstärke: ausreichend Kanalauslastung: sehr hoch Retry-Rate: stark erhöht aktive Clients: 42 AP-Uplink: unauffällig ``` **Festgestellte Ursache** Der Funkkanal war stark ausgelastet. Viele erneute Übertragungen reduzierten den tatsächlichen Durchsatz. **Kontrollierte Maßnahme** Die Funkplanung wurde anhand der vorgesehenen WLAN-Managementfunktionen angepasst. **Verifikation** ```text Retry-Rate: deutlich reduziert Anwendungsantwortzeit: normal Videokonferenzen: stabil ``` --- **39. Ungeeignete Sofortmaßnahmen** Nicht als erste Maßnahme verwenden: - Server ohne vorherige Messung neu starten, - Netzwerkgerät wahllos neu starten, - DNS-Cache vor der Bestandsaufnahme löschen, - alle Netzwerkadapter zurücksetzen, - mehrere Kabel und Ports gleichzeitig wechseln, - Sicherheitssoftware ohne Freigabe deaktivieren, - VPN umgehen, - Firewallregeln pauschal ändern, - WLAN-Kanäle wahllos wechseln, - unbegrenzten Paketmitschnitt starten, - produktives Netzwerk unkontrolliert auslasten, - Datenbankabfragen ungeprüft verändern, - Serverressourcen ohne Messwerte erhöhen, - Zeitüberschreitungen pauschal verlängern, - aus einem einzelnen Ping eine Ursache ableiten, - hohe Bandbreite mit hoher Anwendungsleistung gleichsetzen. Solche Maßnahmen können Beweise vernichten, neue Fehler verursachen oder die eigentliche Ursache verdecken. --- **40. Vollständige Prüfreihenfolge** 1. genaue Benutzeraktion erfassen. 2. erwartete und tatsächliche Dauer dokumentieren. 3. Startzeitpunkt, Häufigkeit und Dauer bestimmen. 4. betroffene Benutzer, Clients und Standorte erfassen. 5. LAN, WLAN und VPN unterscheiden. 6. einzelne Anwendung und allgemeines Systemverhalten vergleichen. 7. betroffenen Client mit Referenzclient vergleichen. 8. normalen Leistungsbereich als Baseline bestimmen. 9. lokale CPU-, Speicher- und Datenträgerauslastung prüfen. 10. Verbindungsgeschwindigkeit und Adapterstatus prüfen. 11. Gateway, internes Ziel und externes Ziel messen. 12. Latenz und Paketverlust getrennt betrachten. 13. Netzwerkpfad untersuchen. 14. TCP-Port prüfen. 15. DNS-Antwortzeit messen. 16. Anwendungsantwort in einzelne Zeitanteile zerlegen. 17. kontrollierten Durchsatztest durchführen. 18. Interface-Fehler, Drops und Retransmissions prüfen. 19. WLAN-Auslastung und Retry-Rate berücksichtigen. 20. VPN-Pfad und VPN-Gateway prüfen. 21. Server-CPU und Arbeitsspeicher überwachen. 22. Paging, Swapping und Ressourcenlimits prüfen. 23. Storage-Latenz und Warteschlangen untersuchen. 24. Datenbankabfragen, Sperren und Verbindungen prüfen. 25. APIs und externe Abhängigkeiten untersuchen. 26. alle Serverknoten einzeln vergleichen. 27. geplante Aufgaben und Hintergrundprozesse prüfen. 28. Messwerte auf einer gemeinsamen Zeitleiste darstellen. 29. größten Zeitanteil bestimmen. 30. Ursache und Folge unterscheiden. 31. genau eine messbare Hypothese formulieren. 32. Ausgangszustand und Rollback dokumentieren. 33. genau eine freigegebene Änderung durchführen. 34. ursprüngliche Messung wiederholen. 35. ausreichend lange Verifikation durchführen. 36. Nebenwirkungen kontrollieren. 37. temporäre Diagnosemaßnahmen entfernen. 38. Ursache, Maßnahme und Nachweis dokumentieren. --- **41. Checkliste „Netzwerk oder Anwendung ist langsam“** - [ ] genaue Benutzeraktion wurde dokumentiert. - [ ] erwartete Dauer wurde erfasst. - [ ] tatsächliche Dauer wurde gemessen. - [ ] Zeitpunkt und Häufigkeit wurden dokumentiert. - [ ] betroffene Benutzer wurden bestimmt. - [ ] betroffene Clients wurden bestimmt. - [ ] betroffene Standorte wurden bestimmt. - [ ] LAN, WLAN und VPN wurden unterschieden. - [ ] interner und externer Zugriff wurden verglichen. - [ ] betroffener Client wurde mit einer Referenz verglichen. - [ ] Baseline wurde bestimmt. - [ ] lokale CPU-Auslastung wurde geprüft. - [ ] lokaler Arbeitsspeicher wurde geprüft. - [ ] lokaler Datenträger wurde geprüft. - [ ] Hintergrundprozesse wurden geprüft. - [ ] Verbindungsgeschwindigkeit wurde geprüft. - [ ] Adapterstatistiken wurden geprüft. - [ ] Gateway-Latenz wurde gemessen. - [ ] Server-Latenz wurde gemessen. - [ ] Paketverlust wurde geprüft. - [ ] Netzwerkpfad wurde untersucht. - [ ] TCP-Port wurde geprüft. - [ ] DNS-Antwortzeit wurde gemessen. - [ ] Zeit bis zum ersten Byte wurde gemessen. - [ ] tatsächlicher Durchsatz wurde geprüft. - [ ] beide Übertragungsrichtungen wurden berücksichtigt. - [ ] Interface-Fehler wurden geprüft. - [ ] Drops und Discards wurden geprüft. - [ ] TCP-Retransmissions wurden berücksichtigt. - [ ] WLAN-Kanalauslastung wurde geprüft. - [ ] WLAN-Retry-Rate wurde geprüft. - [ ] VPN-Verbindung wurde berücksichtigt. - [ ] Server-CPU wurde überwacht. - [ ] Serverarbeitsspeicher wurde überwacht. - [ ] Paging oder Swapping wurde geprüft. - [ ] Storage-Latenz wurde gemessen. - [ ] Datenträgerwarteschlangen wurden berücksichtigt. - [ ] Datenbankabfragen wurden geprüft. - [ ] Datenbanksperren wurden berücksichtigt. - [ ] APIs und externe Abhängigkeiten wurden geprüft. - [ ] alle Serverknoten wurden verglichen. - [ ] Backups und Snapshots wurden berücksichtigt. - [ ] Virenscans und Updates wurden berücksichtigt. - [ ] gemeinsame Zeitleiste wurde erstellt. - [ ] größter Zeitanteil wurde bestimmt. - [ ] Ursache und Folge wurden unterschieden. - [ ] messbare Hypothese wurde formuliert. - [ ] Ausgangszustand wurde dokumentiert. - [ ] Rollback wurde festgelegt. - [ ] nur eine kontrollierte Änderung wurde durchgeführt. - [ ] Messungen wurden anschließend wiederholt. - [ ] ausreichend lange Verifikation wurde durchgeführt. - [ ] Nebenwirkungen wurden geprüft. - [ ] Ursache und Nachweis wurden dokumentiert. --- **42. Schnellreferenz** | Beobachtung | Nächster Prüfbereich | |---|---| | nur ein Client langsam | Client, Treiber, Datenträger oder lokale Software | | alle Clients langsam | gemeinsame Infrastruktur, Server oder Anwendung | | Gateway bereits langsam | lokaler Zugang, WLAN, Kabel oder Switch | | Gateway normal, Server langsam | interner Pfad, Servernetz oder Server | | Ping normal, Anwendung langsam | Anwendung, Datenbank, API oder Storage | | DNS langsam | DNS-Server, Weiterleitung oder Namensauflösung | | TCP-Aufbau langsam | Netzwerkpfad, Firewall oder Zielsystem | | erstes Byte langsam | Server, Anwendung oder Datenbank | | Download nach erstem Byte langsam | Durchsatz, Paketverlust oder Datenmenge | | `iperf3` schnell, Dateiübertragung langsam | Datenträger, Dateisystem, Virenscanner oder Protokoll | | CRC-/FCS-Fehler steigen | Kabel, Stecker, Port oder Transceiver | | Output Drops steigen | Auslastung oder nachgelagerter Engpass | | nur WLAN langsam | Funkkanal, Retry-Rate, Roaming oder Access Point | | nur VPN langsam | Internetpfad, VPN-Gateway, MTU oder Verschlüsselung | | nur ein Serverknoten langsam | Konfiguration oder Ressource dieses Knotens | | CPU dauerhaft hoch | Prozess, Last oder unzureichende Rechenleistung | | CPU unauffällig, Storage-Latenz hoch | Storage, Backup, Snapshot oder Datenträger | | Speicherdruck und Paging | Arbeitsspeicher, Prozess oder Ressourcenlimit | | Anwendung während Backup langsam | Storage-, Netzwerk- und CPU-Auslastung vergleichen | | Fehler nur bei großen Datenmengen | Durchsatz, Paketverlust, Storage oder Zeitlimit | | Fehler nur bei vielen kleinen Dateien | IOPS, Dateisystem und Virenscanner | | Monitoring zeigt nichts | Messintervall, Maximum und kurzfristige Spitzen prüfen | --- **Merksatz** > „Langsam“ ist zunächst nur ein Symptom. Erst durch den Vergleich von Latenz, Paketverlust, Durchsatz, Anwendungsantwortzeit, Serverressourcen, Storage und Datenbankwartezeiten lässt sich bestimmen, an welcher Stelle die tatsächliche Verzögerung entsteht. --- **Quellen und weiterführende Dokumentation** - [Microsoft Learn – Test-Connection](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.management/test-connection) - [Microsoft Learn – Test-NetConnection](https://learn.microsoft.com/en-us/powershell/module/nettcpip/test-netconnection) - [Microsoft Learn – Get-NetAdapter](https://learn.microsoft.com/en-us/powershell/module/netadapter/get-netadapter) - [Microsoft Learn – Get-NetAdapterStatistics](https://learn.microsoft.com/en-us/powershell/module/netadapter/get-netadapterstatistics) - [Microsoft Learn – Resolve-DnsName](https://learn.microsoft.com/en-us/powershell/module/dnsclient/resolve-dnsname) - [Microsoft Learn – netsh wlan](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/netsh-wlan) - [Microsoft Learn – Windows Performance Monitor](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/perfmon) - [curl – Write-Out Variables](https://curl.se/docs/manpage.html#-w) - [iperf3 – Documentation](https://software.es.net/iperf/) - [Wireshark – User’s Guide](https://www.wireshark.org/docs/wsug_html/) - [Wireshark – TCP Analysis](https://www.wireshark.org/docs/wsug_html_chunked/ChAdvTCPAnalysis.html) - [Wireshark – dumpcap Manual Page](https://www.wireshark.org/docs/man-pages/dumpcap.html) - [systemd – journalctl](https://www.freedesktop.org/software/systemd/man/latest/journalctl.html) # 7.8 Server ist langsam **Ziel dieser Seite** Diese Seite beschreibt die systematische Fehleranalyse, wenn ein Server oder ein darauf bereitgestellter Dienst ungewöhnlich langsam reagiert. Dabei muss zwischen verschiedenen Ursachen unterschieden werden: - CPU-Auslastung, - Arbeitsspeichermangel, - Paging oder Swapping, - langsamer Datenträger, - hohe Datenträgerlatenz, - Netzwerkprobleme, - überlastete Anwendung, - Datenbanksperren, - Hintergrundjobs, - Hypervisor-Engpässe, - externe Abhängigkeiten. > „Der Server ist langsam“ ist lediglich eine Symptombeschreibung. Erst durch Messwerte lässt sich bestimmen, welche Ressource oder Abhängigkeit den Engpass verursacht. --- **1. Problem exakt beschreiben** Vor der technischen Analyse müssen Soll- und Istzustand dokumentiert werden. | Angabe | Beispiel | |---|---| | betroffener Server | `SRV-APP01` | | betroffener Dienst | interne Webanwendung | | Symptom | Seitenaufbau dauert 15 Sekunden | | Normalzustand | unter 2 Sekunden | | Beginn | 02.08.2026, etwa 09:15 Uhr | | Umfang | alle Benutzer | | Häufigkeit | zeitweise | | letzter funktionierender Zustand | vor dem nächtlichen Backup | | letzte Änderung | Anwendungsupdate | | Vergleichssystem | `SRV-APP02` reagiert normal | Zu klären ist: - Ist der gesamte Server langsam oder nur eine Anwendung? - Sind alle Benutzer betroffen? - Tritt das Problem lokal und über das Netzwerk auf? - Sind nur bestimmte Funktionen betroffen? - Besteht das Problem dauerhaft oder nur zu bestimmten Zeiten? - Trat das Problem nach einer Änderung auf? - Sind weitere Server betroffen? - Gibt es ein funktionierendes Vergleichssystem? - Wie wird die Verzögerung gemessen? - Welche Antwortzeit gilt als normal? Die Aussage „der Server ist langsam“ reicht für eine gezielte Fehleranalyse nicht aus. --- **2. Server-, Anwendungs- und Netzwerkproblem unterscheiden** Ein langsamer Dienst beweist nicht automatisch, dass der Server selbst überlastet ist. ```text Client ↓ DNS ↓ Netzwerk ↓ Firewall oder Proxy ↓ Webserver ↓ Anwendung ↓ Datenbank ↓ Storage ``` Jede dieser Komponenten kann die beobachtete Verzögerung verursachen. | Beobachtung | Wahrscheinlicher Prüfbereich | |---|---| | lokale Bedienung ebenfalls langsam | Serverressourcen oder Betriebssystem | | nur entfernte Zugriffe langsam | Netzwerk, VPN, Firewall oder Proxy | | nur eine Anwendung langsam | Anwendung, Datenbank oder Abhängigkeit | | alle Dienste langsam | CPU, RAM, Storage, Hypervisor oder Netzwerk | | nur bestimmte Abfragen langsam | Datenbank, Sperren oder fehlende Indizes | | nur zu festen Uhrzeiten langsam | Backup, Scan, Wartung oder geplanter Job | | nur eine VM betroffen | VM-Konfiguration oder Gastbetriebssystem | | mehrere VMs auf demselben Host betroffen | Hypervisor oder gemeinsames Storage | | Ping normal, Anwendung langsam | Dienst, TLS, Authentifizierung oder Backend | | Ping langsam oder instabil | Netzwerkpfad oder Serverüberlastung | | Zugriff per IP schnell, per Name langsam | DNS-Auflösung | | Anmeldung langsam, Dienste danach normal | Authentifizierung, GPO, Profil oder DNS | --- **3. Auswirkungen und Priorität bestimmen** Vor der tieferen Analyse muss die betriebliche Auswirkung bewertet werden. Zu klären ist: - Ist ein geschäftskritischer Dienst betroffen? - Können Benutzer noch eingeschränkt arbeiten? - Sind Datenverlust oder Folgefehler möglich? - Betrifft das Problem einen oder mehrere Standorte? - Verschlechtert sich der Zustand weiter? - Gibt es ein funktionierendes Ersatzsystem? - Besteht eine vereinbarte Reaktions- oder Wiederherstellungszeit? Beispiel: | Kriterium | Bewertung | |---|---| | Auswirkung | alle Mitarbeiter können nur verzögert arbeiten | | Dringlichkeit | hoch | | Priorität | hoch | | Ersatzlösung | zweiter Anwendungsserver vorhanden | | Datenverlust | derzeit nicht erkennbar | | Eskalation | Anwendungs- und Infrastrukturteam informieren | Eine hohe Auslastung ist nicht automatisch ein kritischer Vorfall. Entscheidend ist, ob der vereinbarte Dienst beeinträchtigt wird. --- **4. Ausgangszustand sichern** Vor einem Neustart oder einer Konfigurationsänderung sollten flüchtige Informationen gesichert werden: - genaue Uhrzeit mit Zeitzone, - CPU-Auslastung, - CPU-Auslastung pro Prozess, - Arbeitsspeicherbelegung, - Paging- oder Swap-Aktivität, - Datenträgerauslastung, - Datenträgerlatenz, - Warteschlangen, - Netzwerkfehler, - aktive Verbindungen, - Prozess- und Dienststatus, - Eventlogs oder Journal, - Anwendungslogs, - Datenbankstatus, - Hypervisorwerte, - laufende Jobs, - letzte Änderungen. Ein Neustart kann das Symptom vorübergehend beseitigen, vernichtet aber möglicherweise den für die Ursachenanalyse benötigten Zustand. Vor einer Maßnahme sollte daher mindestens dokumentiert werden: ```text Zeitpunkt: betroffener Dienst: gemessene Antwortzeit: CPU: RAM: Datenträger: Netzwerk: auffälliger Prozess: auffälliges Ereignis: laufender Hintergrundjob: letzte Änderung: ``` --- **5. Sichere Schnellprüfung** Die erste Prüfung sollte möglichst nur lesend erfolgen. 1. Zeitpunkt und Umfang der Störung bestimmen. 2. CPU, RAM, Datenträger und Netzwerk gleichzeitig betrachten. 3. Prozesse mit ungewöhnlicher Ressourcennutzung ermitteln. 4. Backups, Virenscans, Snapshots und Wartungsjobs prüfen. 5. Betriebssystem-, Anwendungs- und Hypervisorlogs zeitlich vergleichen. 6. Antwortzeit vom Client und direkt auf dem Server messen. 7. Mit einem funktionierenden Vergleichssystem vergleichen. 8. Erst danach eine kontrollierte Maßnahme auswählen. Windows: ```powershell Get-Date Get-Process | Sort-Object CPU -Descending | Select-Object -First 10 Name, Id, CPU, WorkingSet64 ``` Linux: ```bash date uptime top ``` Diese Momentaufnahmen reichen noch nicht für eine vollständige Bewertung. Kurze Spitzen oder zeitweise auftretende Fehler können dabei unentdeckt bleiben. --- **6. CPU-Auslastung untersuchen** Eine hohe CPU-Auslastung kann durch einen einzelnen Prozess, mehrere konkurrierende Prozesse oder eine zu geringe bereitgestellte Rechenleistung verursacht werden. Zu prüfen sind: - gesamte CPU-Auslastung, - Auslastung einzelner Kerne, - Auslastung pro Prozess und Thread, - Dauer der Auslastung, - System- und Benutzerzeit, - Interrupts, - virtuelle CPU-Bereitstellung, - CPU-Wartezeiten des Hypervisors, - CPU-Limits oder Drosselung. Windows: ```powershell Get-Counter '\Processor(_Total)\% Processor Time' ``` Prozesse nach gesamter CPU-Zeit sortieren: ```powershell Get-Process | Sort-Object CPU -Descending | Select-Object -First 15 Name, Id, CPU, Threads ``` Aktuelle Prozessorauslastung über CIM: ```powershell Get-CimInstance Win32_Processor | Select-Object Name, LoadPercentage ``` Linux: ```bash top ``` Mit installiertem Paket `sysstat`: ```bash pidstat 1 ``` Auslastung pro logischer CPU: ```bash mpstat -P ALL 1 ``` | Befund | Mögliche Bedeutung | |---|---| | ein Prozess belegt dauerhaft einen Kern | Single-Thread-Engpass oder Endlosschleife | | alle Kerne dauerhaft stark ausgelastet | CPU-Sättigung | | hohe Systemzeit | Kernel, Treiber, Netzwerk oder I/O prüfen | | viele Interrupts | Netzwerk- oder Hardwareproblem möglich | | CPU im Gast niedrig, Anwendung trotzdem langsam | Storage, Netzwerk, Sperren oder Hypervisor prüfen | | mehrere VMs gleichzeitig langsam | Hostüberlastung oder CPU-Scheduling prüfen | | kurze regelmäßige Spitzen | geplanter Job, Scan oder Monitoring | | Prozess-CPU steigt ständig | fehlerhafte Anwendung oder unpassende Last | Eine Gesamtauslastung von beispielsweise 25 Prozent schließt einen CPU-Engpass nicht aus. Auf einem System mit vier logischen Prozessoren kann ein einzelner vollständig ausgelasteter Thread ungefähr 25 Prozent Gesamtauslastung verursachen. --- **7. Arbeitsspeicher untersuchen** Ein hoher belegter Arbeitsspeicher ist nicht automatisch ein Fehler. Betriebssysteme verwenden verfügbaren Speicher beispielsweise für Caches. Entscheidend sind: - verfügbarer Arbeitsspeicher, - Auslagerungsaktivität, - Speicherdruck, - Arbeitsspeicher pro Prozess, - Page Faults, - Kernel- oder Pool-Speicher, - zeitliche Entwicklung, - Speicherlimits einer VM oder eines Containers. Windows: ```powershell Get-CimInstance Win32_OperatingSystem | Select-Object TotalVisibleMemorySize, FreePhysicalMemory ``` Prozesse nach Arbeitsspeicher sortieren: ```powershell Get-Process | Sort-Object WorkingSet64 -Descending | Select-Object -First 15 Name, Id, WorkingSet64, PagedMemorySize64 ``` Leistungsindikatoren abfragen: ```powershell Get-Counter ` '\Memory\Available MBytes', '\Memory\Pages/sec' ``` Linux: ```bash free -h ``` Ausführlichere Anzeige: ```bash vmstat 1 ``` Prozesse nach Speichernutzung sortieren: ```bash ps aux --sort=-%mem | head ``` | Befund | Mögliche Bedeutung | |---|---| | wenig freier Speicher, aber keine Auslagerung | nicht zwingend problematisch | | dauerhaft starke Paging- oder Swap-Aktivität | Arbeitsspeicherengpass | | ein Prozess wächst kontinuierlich | mögliches Speicherleck | | Anwendung erreicht festgelegtes Limit | Container-, VM- oder Prozesslimit prüfen | | Server wird nach längerer Laufzeit langsamer | Speicherleck oder zunehmender Cache möglich | | OOM-Ereignis unter Linux | Speicher war erschöpft | | hoher Commit-Wert unter Windows | zugesicherter virtueller Speicher prüfen | Nur den belegten Arbeitsspeicher zu betrachten, reicht nicht aus. Besonders Paging, Swap und die zeitliche Entwicklung sind entscheidend. --- **8. Datenträger und Storage untersuchen** Ein langsamer Datenträger kann den gesamten Server ausbremsen, obwohl CPU und Arbeitsspeicher unauffällig erscheinen. Zu prüfen sind: - Datenträgerlatenz, - Lese- und Schreibraten, - Warteschlangenlänge, - IOPS, - freier Speicherplatz, - Dateisystemfehler, - RAID-Zustand, - SAN- oder NAS-Verbindung, - Snapshot-Aktivität, - Backup-Aktivität, - Storage-Überbelegung, - Zustand physischer Datenträger. Windows-Leistungsindikatoren: ```powershell Get-Counter ` '\PhysicalDisk(_Total)\Avg. Disk sec/Read', '\PhysicalDisk(_Total)\Avg. Disk sec/Write', '\PhysicalDisk(_Total)\Current Disk Queue Length', '\PhysicalDisk(_Total)\Disk Reads/sec', '\PhysicalDisk(_Total)\Disk Writes/sec' ``` Freien Speicherplatz prüfen: ```powershell Get-Volume | Select-Object DriveLetter, FileSystemLabel, FileSystem, Size, SizeRemaining ``` Linux: ```bash df -h ``` Blockgeräte anzeigen: ```bash lsblk ``` I/O-Auslastung mit installiertem `sysstat`: ```bash iostat -xz 1 ``` Prozesse mit I/O-Aktivität: ```bash pidstat -d 1 ``` | Befund | Mögliche Bedeutung | |---|---| | hohe Latenz bei geringer Datenrate | langsames oder blockiertes Storage | | Warteschlange wächst dauerhaft | Datenträger kann Anfragen nicht schnell genug verarbeiten | | freier Speicherplatz nahezu erschöpft | Dateisystem, Datenbank oder Anwendung beeinträchtigt | | mehrere VMs gleichzeitig betroffen | gemeinsames Storage prüfen | | Problem während eines Backups | konkurrierende I/O-Last | | hohe I/O-Wartezeit unter Linux | Prozesse warten auf Storage | | RAID degradiert | Leistung und Ausfallsicherheit reduziert | | Snapshot wächst stark | zusätzliche Storage-Belastung möglich | Allgemeine Grenzwerte dürfen nur als Orientierung verwendet werden. Ob eine Latenz problematisch ist, hängt vom Speichermedium, der Anwendung und den vereinbarten Leistungswerten ab. --- **9. Netzwerk untersuchen** Ein Netzwerkproblem kann aus Benutzersicht wie ein langsamer Server wirken. Zu prüfen sind: - Paketverlust, - Latenz, - Schwankungen der Latenz, - DNS-Auflösung, - Duplex- oder Geschwindigkeitsfehler, - Interfacefehler, - Überlastung, - VPN, - Firewall, - Proxy, - Load Balancer, - Routing, - MTU-Probleme, - viele oder erschöpfte Verbindungen. Windows: ```powershell Test-Connection SRV-APP01 -Count 10 ``` TCP-Port prüfen: ```powershell Test-NetConnection SRV-APP01 -Port 443 ``` Netzwerkadapter anzeigen: ```powershell Get-NetAdapter | Select-Object Name, Status, LinkSpeed, MacAddress ``` Adapterstatistiken: ```powershell Get-NetAdapterStatistics ``` Aktive TCP-Verbindungen: ```powershell Get-NetTCPConnection | Group-Object State | Sort-Object Count -Descending ``` Linux: ```bash ping -c 10 srv-app01 ``` Route untersuchen: ```bash traceroute srv-app01 ``` Socketübersicht: ```bash ss -s ``` Interfaceinformationen: ```bash ip -s link ``` DNS-Auflösung prüfen: ```bash dig srv-app01.example.local ``` | Befund | Mögliche Bedeutung | |---|---| | Paketverlust | Überlastung, fehlerhafter Link oder Routingproblem | | schwankende Latenz | Überlastung oder instabiler Netzwerkpfad | | Zugriff per IP schnell, per Name langsam | DNS prüfen | | nur VPN-Benutzer betroffen | VPN-Gateway, Tunnel oder Internetverbindung | | Fehlerzähler steigen | Kabel, Port, Treiber oder Netzwerkkarte | | Anwendung lokal schnell, entfernt langsam | Netzwerkpfad, Proxy oder Firewall | | nur große Übertragungen problematisch | MTU, Bandbreite oder Paketverlust prüfen | | viele Verbindungen im Wartezustand | Anwendung, Netzwerk oder Porterschöpfung | Ein erfolgreicher Ping beweist nur eingeschränkt die Funktionsfähigkeit. Er prüft nicht automatisch den eigentlichen Anwendungsport oder die Antwortzeit des Dienstes. --- **10. DNS untersuchen** Langsame oder fehlerhafte Namensauflösung kann viele Serverdienste beeinträchtigen. Typische Auswirkungen: - langsame Anmeldung, - verzögerte Verbindungen, - Authentifizierungsprobleme, - lange Wartezeiten beim Zugriff auf andere Server, - langsame Datenbankverbindungen, - Verzögerungen bei Reverse-Lookups. Windows: ```powershell Resolve-DnsName SRV-DB01 ``` Konfigurierte DNS-Server: ```powershell Get-DnsClientServerAddress ``` DNS-Zwischenspeicher: ```powershell Get-DnsClientCache ``` Linux: ```bash resolvectl status ``` Namensauflösung messen: ```bash time getent hosts srv-db01.example.local ``` Mit `dig`: ```bash dig srv-db01.example.local ``` Zu prüfen sind: - korrekte DNS-Server, - Antwortzeit, - Forward- und Reverse-Auflösung, - fehlerhafte oder veraltete Einträge, - Suchdomänen, - Erreichbarkeit der DNS-Server, - unnötige Abfragen an externe DNS-Server. --- **11. Prozesse und Dienste untersuchen** Nicht jede hohe Ressourcennutzung ist die Ursache. Der auffällige Prozess kann selbst nur auf eine andere Komponente warten. Windows-Dienste: ```powershell Get-Service | Where-Object Status -eq 'Running' ``` Automatisch startende, aber nicht laufende Dienste: ```powershell Get-CimInstance Win32_Service | Where-Object { $_.StartMode -eq 'Auto' -and $_.State -ne 'Running' } | Select-Object Name, DisplayName, State, StartMode ``` Linux-Dienste: ```bash systemctl --failed ``` Status eines Dienstes: ```bash systemctl status nginx ``` Zu prüfen sind: - ungewöhnlich hohe CPU- oder Speichernutzung, - häufige Dienstneustarts, - Prozesse im Warte- oder Blockierungszustand, - sehr viele Threads, - sehr viele offene Dateien, - abgestürzte Unterprozesse, - lange Warteschlangen, - Ressourcenlimits, - fehlerhafte Abhängigkeiten. Ein Dienstneustart sollte erst erfolgen, nachdem relevante Messwerte und Protokolle gesichert wurden. --- **12. Anwendung untersuchen** Wenn nur eine Anwendung langsam ist, muss deren interner Ablauf betrachtet werden. Mögliche Ursachen: - fehlerhafte Konfiguration, - zu wenige Worker oder Threads, - zu kleine Verbindungspools, - blockierte Warteschlangen, - langsame Datenbankabfragen, - nicht erreichbare externe Dienste, - Authentifizierungsprobleme, - Cachefehler, - unzureichende Ressourcenlimits, - fehlerhaftes Update, - wachsendes Log- oder temporäres Verzeichnis. Zu prüfen sind: - Antwortzeit einzelner Funktionen, - Anwendungslogs, - Fehler- und Zeitüberschreitungen, - Anzahl aktiver Sitzungen, - Thread- oder Worker-Auslastung, - Warteschlangenlänge, - Cachetreffer, - Verbindungspools, - interne Gesundheitsprüfungen, - Abhängigkeiten. Beispielhafte Abgrenzung: ```text Startseite schnell Suchfunktion langsam ↓ Suchfunktion getrennt untersuchen ↓ Anwendungslog und Datenbankabfrage vergleichen ``` Nicht sofort den gesamten Server neu starten, wenn nur ein einzelner Anwendungsbereich betroffen ist. --- **13. Datenbank untersuchen** Datenbanken können trotz geringer CPU-Auslastung langsam reagieren. Mögliche Ursachen: - blockierende Transaktionen, - Deadlocks, - fehlende oder ungeeignete Indizes, - langsame Abfragen, - überlastetes Storage, - zu wenig Arbeitsspeicher, - zu viele Verbindungen, - fehlerhafte Ausführungspläne, - veraltete Statistiken, - lange offene Transaktionen, - Replikationsprobleme. Zu prüfen sind: - Abfragelaufzeiten, - aktive Verbindungen, - blockierte Sitzungen, - Locks und Deadlocks, - langsame Abfrageprotokolle, - Cache- und Speichernutzung, - Storage-Latenz, - Replikationsverzögerung, - Anzahl wartender Transaktionen. Beispielhafte Ursache-Wirkungs-Kette: ```text lange Datenbankabfrage ↓ Anwendungs-Worker wartet ↓ Verbindungspool wird belegt ↓ weitere Benutzer müssen warten ↓ Anwendung erscheint vollständig langsam ``` Änderungen an Indizes, Abfragen oder Datenbankparametern sollten nur nach Sicherung und Abstimmung mit der verantwortlichen Stelle erfolgen. --- **14. Hintergrundjobs prüfen** Regelmäßig auftretende Leistungseinbrüche sprechen häufig für geplante Prozesse. Typische Verursacher: - Datensicherung, - Virenscan, - Patchinstallation, - Datenbankwartung, - Protokollrotation, - Indexerstellung, - Synchronisation, - Replikation, - Berichtserstellung, - Snapshot, - Datenimport oder Datenexport. Windows – geplante Aufgaben: ```powershell Get-ScheduledTask | Where-Object State -eq 'Running' ``` Linux – systemd-Timer: ```bash systemctl list-timers ``` Cron-Konfiguration prüfen: ```bash crontab -l ``` Zu vergleichen sind: - Startzeit des Jobs, - Beginn der Verlangsamung, - CPU-Auslastung, - I/O-Auslastung, - Netzwerkverkehr, - Ende des Jobs, - Rückkehr zum Normalzustand. Eine zeitliche Übereinstimmung ist ein Hinweis, aber noch kein vollständiger Ursachennachweis. --- **15. Protokolle zeitlich vergleichen** Protokolle müssen mit dem dokumentierten Störungszeitpunkt abgeglichen werden. Windows-Systemereignisse: ```powershell Get-WinEvent -FilterHashtable @{ LogName = 'System' StartTime = (Get-Date).AddHours(-2) } | Select-Object TimeCreated, Id, LevelDisplayName, ProviderName, Message ``` Windows-Anwendungsereignisse: ```powershell Get-WinEvent -FilterHashtable @{ LogName = 'Application' StartTime = (Get-Date).AddHours(-2) } | Select-Object TimeCreated, Id, LevelDisplayName, ProviderName, Message ``` Linux: ```bash journalctl --since "2 hours ago" ``` Fehler mit hoher Priorität: ```bash journalctl -p err --since "2 hours ago" ``` Kernelmeldungen: ```bash journalctl -k --since "2 hours ago" ``` Zu suchen sind: - Datenträgerfehler, - Netzwerkfehler, - Treiberprobleme, - Dienstabbrüche, - Zeitüberschreitungen, - Speicherfehler, - OOM-Ereignisse, - Authentifizierungsfehler, - Datenbankfehler, - wiederholte Neustarts, - Hardwarewarnungen. Ein einzelner protokollierter Fehler beweist nicht automatisch die Ursache. Zeitliche Übereinstimmung, technische Wirkung und Reproduzierbarkeit müssen zusammenpassen. --- **16. Virtuelle Maschinen untersuchen** Bei einer virtuellen Maschine müssen Gast und Hypervisor getrennt betrachtet werden. Im Gast zu prüfen: - vCPU-Auslastung, - Arbeitsspeicher, - Paging oder Swapping, - virtuelle Datenträger, - Netzwerkschnittstelle, - Betriebssystemlogs, - installierte Integrationstreiber. Auf dem Hypervisor zu prüfen: - CPU-Auslastung des Hosts, - CPU-Wartezeit, - Speicherüberbelegung, - Ballooning oder Swapping, - Storage-Latenz, - Netzwerküberlastung, - Limits und Reservierungen, - Snapshots, - Zustand anderer VMs. Typische Konstellation: ```text VM zeigt geringe CPU-Auslastung ↓ Anwendung ist trotzdem langsam ↓ Hypervisor prüfen ↓ VM erhält CPU-Zeit verzögert ``` Mehr virtuelle CPUs verbessern die Leistung nicht automatisch. Zu viele vCPUs können das Scheduling erschweren und die Wartezeit erhöhen. --- **17. Container untersuchen** Bei Containern müssen zusätzlich Limits und der Hostzustand berücksichtigt werden. Zu prüfen sind: - CPU-Limit, - Arbeitsspeicherlimit, - Neustartzähler, - Containerlogs, - Dateisystem, - Storage-Treiber, - Netzwerk, - Zustand des Containerhosts, - gemeinsam genutzte Ressourcen. Docker: ```bash docker stats ``` Laufende Container: ```bash docker ps ``` Containerzustand: ```bash docker inspect CONTAINERNAME ``` Protokollausgabe: ```bash docker logs --since 2h CONTAINERNAME ``` Ressourcenlimits anzeigen: ```bash docker inspect CONTAINERNAME \ --format 'Memory={{.HostConfig.Memory}} NanoCPUs={{.HostConfig.NanoCpus}}' ``` Ein Container kann langsam sein, obwohl der Host noch freie Ressourcen besitzt, wenn für den Container selbst ein niedriges Limit festgelegt wurde. --- **18. Externe Abhängigkeiten prüfen** Eine Anwendung kann auf andere Systeme warten, obwohl der eigene Server unauffällig ist. Mögliche Abhängigkeiten: - Datenbankserver, - DNS-Server, - Active Directory, - Dateiserver, - API, - Cloud-Dienst, - Authentifizierungsdienst, - Mailserver, - Proxy, - Lizenzserver, - Netzwerkspeicher. Zu prüfen sind: - Erreichbarkeit, - Namensauflösung, - Portverbindung, - Antwortzeit, - Zertifikate, - Authentifizierung, - Zeitüberschreitungen, - Rate Limits, - Statusmeldungen des Dienstanbieters. Beispiel: ```text Webserver reagiert lokal schnell ↓ Anmeldung dauert 20 Sekunden ↓ Anwendung wartet auf Verzeichnisdienst ↓ DNS- oder LDAP-Verbindung untersuchen ``` --- **19. Hardwarezustand prüfen** Bei physischen Servern müssen auch Hardwareprobleme berücksichtigt werden. Mögliche Ursachen: - überhitzte CPU, - thermische Drosselung, - fehlerhafter Arbeitsspeicher, - degradierter RAID-Verbund, - defekter Datenträger, - fehlerhafte Netzwerkkarte, - instabiles Netzteil, - Firmware- oder Treiberproblem. Zu prüfen sind: - Hardwaremanagement wie iLO, iDRAC oder vergleichbare Systeme, - Temperaturwerte, - Lüfterstatus, - RAID-Controller, - SMART-Werte, - Hardwareereignisse, - Firmwarestand, - Treiberstand, - Herstellerdiagnose. Linux – vorhandene Hardwarewarnungen: ```bash dmesg --level=err,warn ``` SMART-Werte dürfen nur mit passenden Werkzeugen und unter Berücksichtigung des verwendeten Controllers geprüft werden. --- **20. Letzte Änderungen untersuchen** Leistungsprobleme treten häufig nach einer Veränderung auf. Mögliche Änderungen: - Betriebssystemupdate, - Anwendungsupdate, - Treiberupdate, - neue Sicherheitssoftware, - geänderte Richtlinie, - zusätzliche Benutzer, - Datenwachstum, - neue VM, - geändertes Backupfenster, - neue Datenbankabfrage, - geänderte Ressourcenlimits, - Netzwerkanpassung. Zu dokumentieren sind: | Änderung | Zeitpunkt | Verantwortlich | Mögliche Auswirkung | |---|---|---|---| | Anwendungsupdate | 08:30 Uhr | Anwendungsteam | neue Abfrage oder Fehler | | Backupzeit geändert | 09:00 Uhr | Betriebsteam | höhere Storage-Last | | neue VM gestartet | 09:10 Uhr | Virtualisierungsteam | Hostressourcen | | GPO geändert | Vortag | Administration | Dienst- oder Sicherheitseinstellung | Die zeitliche Nähe einer Änderung zum Fehler ist ein wichtiges Indiz, aber kein alleiniger Beweis. --- **21. Baseline und Vergleichswerte verwenden** Ohne Vergleichswerte lässt sich schwer beurteilen, ob ein Messwert ungewöhnlich ist. Eine Baseline kann enthalten: - typische CPU-Auslastung, - typischer Arbeitsspeicherbedarf, - normale Datenträgerlatenz, - normale Netzwerklatenz, - typische Benutzeranzahl, - typische Antwortzeit, - übliche Anzahl von Verbindungen, - normale Auslastung zu bestimmten Tageszeiten. Beispiel: | Messwert | Normalzustand | Störungszeitpunkt | |---|---:|---:| | Antwortzeit | 1,5 s | 15 s | | CPU | 35 % | 42 % | | verfügbarer RAM | 8 GB | 7,5 GB | | Storage-Latenz | 4 ms | 85 ms | | aktive Benutzer | 120 | 125 | In diesem Beispiel spricht der Vergleich stärker für ein Storage-Problem als für CPU-, RAM- oder Benutzerlast. --- **22. Korrelation und Ursache unterscheiden** Zwei gleichzeitig auftretende Ereignisse müssen nicht ursächlich zusammenhängen. Beispiel: ```text CPU-Auslastung steigt Anwendung wird langsam ``` Mögliche Interpretationen: 1. Die hohe CPU-Auslastung verursacht die Verzögerung. 2. Die langsame externe Abhängigkeit führt zu zusätzlichen Wiederholungen und erhöht dadurch die CPU-Auslastung. 3. Ein dritter Prozess verursacht gleichzeitig beide Effekte. 4. Die CPU-Auslastung ist normal und nicht relevant. Ein Ursachennachweis wird stärker, wenn: - der Zeitpunkt übereinstimmt, - die technische Wirkung plausibel ist, - das Verhalten reproduzierbar ist, - eine gezielte Maßnahme den Messwert und das Symptom verändert, - alternative Ursachen ausgeschlossen wurden. --- **23. Kontrollierte Maßnahmen durchführen** Nach der Analyse sollte genau eine passende Maßnahme durchgeführt werden. Mögliche Maßnahmen: - störenden Hintergrundjob pausieren, - fehlerhaften Prozess kontrolliert neu starten, - Anwendung auf einen zweiten Knoten umleiten, - Ressourcenlimit korrigieren, - fehlerhafte Änderung zurücknehmen, - freien Speicherplatz schaffen, - Storage- oder Netzwerkproblem eskalieren, - Datenbankblockierung durch die zuständige Stelle auflösen. Vor jeder Maßnahme: - Ausgangszustand sichern, - Auswirkung bestimmen, - Freigabe prüfen, - Rückweg festlegen, - betroffene Benutzer informieren, - Messkriterien bestimmen. Danach: - dieselben Messwerte erneut erfassen, - Antwortzeit erneut messen, - Protokolle prüfen, - Nebenwirkungen ausschließen, - Ergebnis dokumentieren. --- **24. Warum ein Neustart nicht die erste Maßnahme sein sollte** Ein Neustart kann: - blockierte Prozesse beenden, - Arbeitsspeicher freigeben, - Warteschlangen zurücksetzen, - Verbindungen neu aufbauen, - ein Symptom vorübergehend beseitigen. Er kann aber auch: - wichtige Fehlerzustände vernichten, - Protokollzusammenhänge erschweren, - eine eigentliche Ursache verbergen, - ungeplante Ausfallzeit verursachen, - Daten oder Transaktionen gefährden, - das Problem später erneut auftreten lassen. Ein Neustart ist daher keine vollständige Ursachenanalyse. Falls ein Neustart erforderlich ist, sollten vorher mindestens folgende Informationen gesichert werden: - Prozessliste, - Ressourcenauslastung, - aktive Verbindungen, - relevante Protokolle, - laufende Aufgaben, - Zeitpunkt und Symptom, - Wiederanlaufplan, - Rückfalloption. --- **25. Nachkontrolle** Nach einer Maßnahme muss nicht nur die Ressourcenauslastung, sondern auch die eigentliche Funktion geprüft werden. Zu kontrollieren sind: - Antwortzeit des betroffenen Dienstes, - CPU-Auslastung, - Arbeitsspeicher, - Paging oder Swap, - Datenträgerlatenz, - Netzwerkfehler, - Dienststatus, - Anwendungslogs, - Datenbankstatus, - Benutzerfunktion, - Zustand abhängiger Systeme. Beispiel: ```text Vorher: Antwortzeit 15 Sekunden Storage-Latenz 85 ms Maßnahme: konkurrierenden Backupjob beendet Nachher: Antwortzeit 1,7 Sekunden Storage-Latenz 5 ms ``` Erst der Vergleich vor und nach der Maßnahme zeigt, ob die vermutete Ursache tatsächlich zum Problem beigetragen hat. --- **26. Dokumentation** Die Abschlussdokumentation sollte enthalten: - betroffener Server, - betroffener Dienst, - Beginn und Ende, - Sollzustand, - Istzustand, - betroffene Benutzer, - gemessene Werte, - relevante Protokolle, - identifizierte Ursache, - durchgeführte Maßnahme, - Rückweg, - Ergebnis der Nachkontrolle, - Nebenwirkungen, - vorbeugende Maßnahme, - verantwortliche Stelle. Beispiel: ```text Symptom: Webanwendung benötigte statt 1–2 Sekunden etwa 15 Sekunden. Ursache: Der gleichzeitig laufende Backupjob verursachte eine hohe Latenz auf dem gemeinsam genutzten Storage. Maßnahme: Backupjob kontrolliert beendet und Zeitplan angepasst. Ergebnis: Antwortzeit wieder unter 2 Sekunden. Storage-Latenz wieder im üblichen Bereich. Vorbeugung: Monitoring für Storage-Latenz eingerichtet und Backupfenster geändert. ``` --- **27. Entscheidungsbaum** ```text Server oder Dienst langsam ↓ Ist der gesamte Server betroffen? ├── Ja │ ↓ │ CPU, RAM, Storage, Netzwerk und Hypervisor prüfen │ └── Nein ↓ Nur eine Anwendung betroffen? ├── Ja │ ↓ │ Anwendung, Datenbank und Abhängigkeiten prüfen │ └── Nein ↓ Gemeinsame Komponente der betroffenen Dienste suchen ``` Erweiterte Eingrenzung: ```text Problem nur aus der Ferne? ├── Ja → Netzwerk, DNS, VPN, Firewall oder Proxy └── Nein ↓ Problem nur zu festen Zeiten? ├── Ja → Backup, Scan, Wartung oder geplanter Job └── Nein ↓ Mehrere VMs auf einem Host betroffen? ├── Ja → Hypervisor und gemeinsames Storage └── Nein → Gastbetriebssystem und Anwendung ``` --- **28. Häufige Fehlerbilder** | Fehlerbild | Wahrscheinlicher Prüfbereich | |---|---| | Server reagiert nach Neustart wieder schnell | Speicherleck, blockierter Prozess oder wartende Ressource | | Problem kehrt regelmäßig zurück | Ursache wurde nicht behoben oder geplanter Job | | CPU dauerhaft hoch | Prozess, Thread, Malware, Scan oder zu geringe Leistung | | CPU niedrig, Server trotzdem langsam | Storage, Netzwerk, Locks oder externe Abhängigkeit | | RAM nahezu vollständig belegt | Paging und Speicherdruck prüfen | | Swap-Nutzung steigt dauerhaft | Arbeitsspeicherengpass | | Datenträger dauerhaft ausgelastet | Backup, Datenbank, Scan oder langsames Storage | | nur Datenbankfunktionen langsam | Abfragen, Locks, Indizes oder Storage | | nur Anmeldung langsam | DNS, Verzeichnisdienst, GPO oder Benutzerprofil | | nur Webzugriff langsam | Webserver, TLS, Proxy, Anwendung oder Datenbank | | nur bestimmte Uhrzeit betroffen | geplanter Job oder Lastspitze | | mehrere VMs betroffen | Host, Netzwerk oder gemeinsames Storage | | nur eine VM betroffen | Gastbetriebssystem, Limits oder VM-Konfiguration | | Zugriff per IP schnell | DNS-Auflösung prüfen | | lokal schnell, entfernt langsam | Netzwerkpfad prüfen | | Anwendung wartet auf Timeout | externe Abhängigkeit untersuchen | | Leistung nimmt über Tage ab | Speicherleck, Datenwachstum oder Warteschlange | --- **29. Typische Prüfungsfragen** **Warum ist die Aussage „der Server ist langsam“ für die Fehleranalyse nicht ausreichend?**
Antwort anzeigen Die Aussage beschreibt nur ein allgemeines Symptom. Es fehlen unter anderem der betroffene Dienst, die gemessene Antwortzeit, der Normalzustand, der Zeitpunkt, der Umfang und mögliche Änderungen.
**Warum beweist eine hohe CPU-Auslastung noch nicht die Fehlerursache?**
Antwort anzeigen Die Auslastung kann für die vorhandene Arbeitslast normal sein oder erst als Folge eines anderen Problems entstehen. Für einen Ursachennachweis müssen zeitlicher Zusammenhang, technische Wirkung und das Ergebnis einer kontrollierten Maßnahme geprüft werden.
**Warum kann ein Server trotz niedriger CPU-Auslastung langsam sein?**
Antwort anzeigen Prozesse können auf Storage, Netzwerk, Datenbanksperren, externe Dienste oder andere Ressourcen warten. Während dieser Wartezeit wird nur wenig CPU-Leistung benötigt.
**Warum ist vollständig belegter Arbeitsspeicher nicht automatisch ein Fehler?**
Antwort anzeigen Betriebssysteme verwenden freien Arbeitsspeicher unter anderem für Caches. Entscheidend sind Speicherdruck, Paging beziehungsweise Swapping und die zeitliche Entwicklung.
**Warum sollten vor einem Neustart Messwerte gesichert werden?**
Antwort anzeigen Ein Neustart beendet Prozesse, leert Warteschlangen und verändert den Systemzustand. Dadurch können wichtige Hinweise auf die eigentliche Ursache verloren gehen.
**Was bedeutet eine hohe Datenträgerlatenz?**
Antwort anzeigen Lese- oder Schreibanforderungen benötigen ungewöhnlich lange. Anwendungen können dadurch warten, obwohl CPU und Arbeitsspeicher unauffällig sind.
**Warum reicht ein erfolgreicher Ping nicht als Nachweis für einen funktionierenden Dienst?**
Antwort anzeigen Ping prüft ICMP-Erreichbarkeit. Der eigentliche Anwendungsport, die Authentifizierung, die Verarbeitung im Dienst und dessen Backend werden dadurch nicht geprüft.
**Warum müssen bei einer VM auch Hypervisorwerte geprüft werden?**
Antwort anzeigen Der Gast kann nur die ihm bereitgestellten Ressourcen sehen. Wartezeiten, Überbelegung oder Storage-Probleme auf dem Host sind im Gast möglicherweise nicht eindeutig erkennbar.
**Warum sollte nach einer Maßnahme erneut gemessen werden?**
Antwort anzeigen Nur der Vergleich von Sollwert, Ausgangswert und neuem Messwert zeigt, ob die Maßnahme das eigentliche Problem behoben hat.
--- **30. Prüfungsfallen** - „Server langsam“ nicht genauer eingrenzen. - einen einzelnen hohen Messwert sofort als Ursache bewerten. - nur CPU und Arbeitsspeicher prüfen. - Datenträgerlatenz nicht berücksichtigen. - belegten Arbeitsspeicher automatisch mit Speichermangel gleichsetzen. - Ping als vollständigen Diensttest ansehen. - DNS nicht prüfen. - Anwendung und Server nicht voneinander trennen. - externe Abhängigkeiten übersehen. - nur den Gast und nicht den Hypervisor untersuchen. - Containerlimits nicht berücksichtigen. - Hintergrundjobs nicht mit dem Störungszeitpunkt vergleichen. - Protokolle ohne genaue Uhrzeit untersuchen. - mehrere Maßnahmen gleichzeitig durchführen. - sofort neu starten. - Zustand vor der Maßnahme nicht sichern. - nach der Maßnahme nicht erneut messen. - technische Messwerte prüfen, aber die Benutzerfunktion nicht testen. - zeitliche Korrelation automatisch als Ursache bewerten. - das funktionierende Vergleichssystem nicht nutzen. - keine vorbeugende Maßnahme dokumentieren. --- **31. Checkliste „Server ist langsam“** - [ ] betroffener Server wurde eindeutig bestimmt. - [ ] betroffener Dienst wurde bestimmt. - [ ] Sollzustand wurde dokumentiert. - [ ] Istzustand wurde gemessen. - [ ] Beginn und Häufigkeit wurden dokumentiert. - [ ] betroffene Benutzer und Standorte wurden bestimmt. - [ ] lokaler und entfernter Zugriff wurden verglichen. - [ ] funktionierendes Vergleichssystem wurde geprüft. - [ ] letzte Änderungen wurden ermittelt. - [ ] Ausgangszustand wurde gesichert. - [ ] CPU-Gesamtauslastung wurde geprüft. - [ ] einzelne CPU-Kerne wurden berücksichtigt. - [ ] CPU-Auslastung pro Prozess wurde geprüft. - [ ] Arbeitsspeicher wurde geprüft. - [ ] Paging oder Swapping wurde geprüft. - [ ] Prozesse mit hoher Speichernutzung wurden ermittelt. - [ ] freier Speicherplatz wurde geprüft. - [ ] Datenträgerlatenz wurde geprüft. - [ ] Datenträgerwarteschlange wurde geprüft. - [ ] RAID- oder Storage-Zustand wurde berücksichtigt. - [ ] Netzwerkverbindung wurde geprüft. - [ ] Paketverlust und Latenz wurden geprüft. - [ ] Netzwerkfehlerzähler wurden geprüft. - [ ] DNS-Auflösung wurde geprüft. - [ ] Anwendungsport wurde geprüft. - [ ] aktive Verbindungen wurden geprüft. - [ ] Dienste und Prozesse wurden geprüft. - [ ] Anwendungslogs wurden geprüft. - [ ] Betriebssystemlogs wurden geprüft. - [ ] Datenbankzustand wurde geprüft. - [ ] Datenbanksperren wurden berücksichtigt. - [ ] externe Abhängigkeiten wurden geprüft. - [ ] Backups und Wartungsjobs wurden geprüft. - [ ] Virenscans wurden berücksichtigt. - [ ] Hypervisorwerte wurden geprüft. - [ ] VM- oder Containerlimits wurden geprüft. - [ ] Hardwarezustand wurde berücksichtigt. - [ ] Messwerte wurden zeitlich korreliert. - [ ] genau eine kontrollierte Maßnahme wurde durchgeführt. - [ ] Rückweg wurde festgelegt. - [ ] dieselben Messwerte wurden anschließend erneut erfasst. - [ ] fachliche Funktion wurde praktisch getestet. - [ ] Nebenwirkungen wurden ausgeschlossen. - [ ] Ursache, Maßnahme und Ergebnis wurden dokumentiert. - [ ] vorbeugende Maßnahme wurde festgelegt. --- **32. Schnellreferenz** | Beobachtung | Nächster Prüfbereich | |---|---| | gesamte Maschine langsam | CPU, RAM, Storage, Hypervisor | | nur eine Anwendung langsam | Anwendung, Datenbank, Abhängigkeiten | | CPU dauerhaft hoch | Prozess- und Threadauslastung | | nur ein Kern ausgelastet | Single-Thread-Engpass | | CPU niedrig, Antwortzeit hoch | Storage, Netzwerk, Locks | | starke Paging-Aktivität | Arbeitsspeicher | | hohe I/O-Wartezeit | Datenträger oder Storage | | wenig freier Speicherplatz | Dateisystem und Datenwachstum | | lokale Nutzung schnell | Netzwerk, DNS, Proxy oder Firewall | | Zugriff per IP schnell | DNS | | Paketverlust vorhanden | Netzwerkpfad | | nur bestimmte Uhrzeit betroffen | geplante Aufgaben | | Problem während Backup | Storage- und Netzwerkbelastung | | mehrere VMs betroffen | Hypervisor und gemeinsames Storage | | nur eine VM betroffen | Gast, Limits und virtuelle Hardware | | Container wird gedrosselt | CPU- und Speicherlimit | | bestimmte Datenbankabfrage langsam | Locks, Indizes und Ausführungsplan | | Anmeldung langsam | DNS, AD, GPO oder Profil | | Anwendung wartet auf Timeout | externe Abhängigkeit | | nach Neustart vorübergehend schnell | Speicherleck, Warteschlange oder blockierter Prozess | | Hardwarewarnung vorhanden | Herstellerdiagnose und Austauschplanung | --- **Merksatz** > Ein langsamer Server wird nicht durch Vermutungen, sondern durch Eingrenzung und Messwerte untersucht. Entscheidend ist, ob CPU, Arbeitsspeicher, Storage, Netzwerk, Anwendung, Datenbank, Hypervisor oder eine externe Abhängigkeit den tatsächlichen Engpass verursacht. Vor einer Änderung wird der Ausgangszustand gesichert, anschließend wird genau eine kontrollierte Maßnahme durchgeführt und ihre Wirkung erneut gemessen. --- **Quellen und weiterführende Dokumentation** - [Microsoft Learn – Windows Performance Monitor](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/perfmon) - [Microsoft Learn – Get-Counter](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.diagnostics/get-counter) - [Microsoft Learn – Get-Process](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.management/get-process) - [Microsoft Learn – Get-WinEvent](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.diagnostics/get-winevent) - [Microsoft Learn – Test-NetConnection](https://learn.microsoft.com/en-us/powershell/module/nettcpip/test-netconnection) - [Microsoft Learn – Resolve-DnsName](https://learn.microsoft.com/en-us/powershell/module/dnsclient/resolve-dnsname) - [Microsoft Learn – Get-NetAdapterStatistics](https://learn.microsoft.com/en-us/powershell/module/netadapter/get-netadapterstatistics) - [Red Hat – Viewing system processes](https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/managing_monitoring_and_updating_the_kernel/viewing-system-processes_managing-monitoring-and-updating-the-kernel) - [Red Hat – Monitoring performance with Performance Co-Pilot](https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/monitoring_and_managing_system_status_and_performance/monitoring-performance-with-performance-co-pilot_monitoring-and-managing-system-status-and-performance) - [Docker Docs – Runtime metrics](https://docs.docker.com/engine/containers/runmetrics/) - [Docker Docs – Resource constraints](https://docs.docker.com/engine/containers/resource_constraints/) # 7.9 Ping funktioniert, Anwendung nicht Ein Server antwortet auf einen Ping, die eigentliche Anwendung ist jedoch nicht erreichbar oder funktioniert nicht vollständig. Dieses Fehlerbild entsteht häufig, weil ein erfolgreicher Ping fälschlicherweise als Nachweis für die Funktionsfähigkeit des gesamten Dienstes interpretiert wird. Ping prüft jedoch nur einen begrenzten Teil der Kommunikationskette. --- **7.9.1 Typisches Fehlerbild** Mögliche Meldungen und Beobachtungen: - Der Server antwortet auf `ping`, aber die Webseite öffnet sich nicht. - Die IP-Adresse ist erreichbar, aber die Anwendung meldet einen Timeout. - Der TCP-Port ist erreichbar, aber die Anmeldung schlägt fehl. - Der Dienst funktioniert lokal auf dem Server, jedoch nicht von einem Client. - Die Anwendung funktioniert ohne VPN, aber nicht über den VPN-Tunnel. - Einige Benutzer können zugreifen, andere nicht. - IPv4 funktioniert, IPv6 jedoch nicht. - Der Reverse Proxy antwortet, erreicht aber das Backend nicht. - Die Anwendung zeigt `502 Bad Gateway` oder `503 Service Unavailable`. - Die Startseite funktioniert, ein bestimmter Geschäftsprozess jedoch nicht. - Ein Healthcheck ist erfolgreich, während Benutzerfunktionen fehlschlagen. Die Diagnose muss deshalb über ICMP hinausgehen und den tatsächlichen Anwendungsweg prüfen. --- **7.9.2 Diagnoseziel** Ziel ist es, eindeutig festzustellen: - welches Ziel die Anwendung tatsächlich verwendet; - welche IP-Adresse verwendet wird; - ob IPv4 oder IPv6 verwendet wird; - welches Transportprotokoll erforderlich ist; - welcher Port angesprochen wird; - ob der Zielport erreichbar ist; - ob auf dem Server ein passender Prozess lauscht; - ob der Dienst an der richtigen Adresse gebunden ist; - ob TLS und Zertifikatsprüfung funktionieren; - ob ein Proxy, Reverse Proxy oder Load Balancer beteiligt ist; - ob Authentifizierung und Autorisierung funktionieren; - ob alle Backendabhängigkeiten verfügbar sind; - an welcher Stelle die vollständige Kommunikationskette unterbrochen wird. Ein möglicher Fehlerbereich darf erst dann als Ursache gelten, wenn er durch ein reproduzierbares Prüfergebnis, ein Protokoll oder einen Paketmitschnitt bestätigt wurde. --- **7.9.3 Kommunikationskette der Anwendung** Eine typische Anwendungsverbindung kann mehrere voneinander unabhängige Prüfebenen enthalten: 1. Anwendungskonfiguration 2. Namensauflösung 3. Auswahl von IPv4 oder IPv6 4. lokales Routing 5. VPN oder Proxy 6. Clientfirewall 7. Netzwerkfirewall oder ACL 8. NAT oder Portweiterleitung 9. Load Balancer oder Reverse Proxy 10. TCP- oder UDP-Kommunikation 11. TLS-Handshake 12. Anwendungsprotokoll 13. Authentifizierung 14. Autorisierung 15. Backenddienste 16. vollständiger Benutzerablauf Ein Fehler auf einer späteren Ebene kann auftreten, obwohl alle vorherigen Ebenen funktionieren. Beispiele: - Ping funktioniert, aber TCP 443 wird blockiert. - TCP 443 funktioniert, aber der TLS-Handshake schlägt fehl. - TLS funktioniert, aber der HTTP-Pfad ist falsch. - HTTP funktioniert, aber die Anmeldung wird verweigert. - Die Anmeldung funktioniert, aber die Datenbank ist nicht erreichbar. - Der Healthcheck funktioniert, aber der eigentliche Geschäftsprozess schlägt fehl. --- **7.9.4 Was Ping tatsächlich prüft** Ping verwendet normalerweise ICMP-Echo-Anfragen und ICMP-Echo-Antworten. Ein erfolgreicher Ping bestätigt für den konkreten Testzeitpunkt grundsätzlich: - der verwendete Zielname konnte für diesen Aufruf aufgelöst werden, sofern ein Name angegeben wurde; - eine Zieladresse wurde ausgewählt; - der Client konnte ein ICMP-Echo-Paket absenden; - das Paket erreichte ein antwortendes System; - eine ICMP-Echo-Antwort erreichte den Client; - der ICMP-Hin- und Rückweg funktionierte für diese Paketgröße und diesen Zeitpunkt. Ping kann zusätzlich Hinweise liefern auf: - Antwortzeit; - Paketverlust; - wechselnde Antwortzeiten; - ausgewählte IPv4- oder IPv6-Adresse; - grobe Erreichbarkeit eines Systems. Das antwortende System muss jedoch nicht zwingend der erwartete Anwendungsserver sein. Bei virtuellen IP-Adressen, Load Balancern, Firewalls oder falsch aufgelösten Namen kann ein anderes System antworten. --- **7.9.5 Was Ping nicht beweist** Ein erfolgreicher Ping beweist nicht: - dass ein bestimmter TCP-Port geöffnet ist; - dass ein UDP-Dienst funktioniert; - dass der erwartete Prozess läuft; - dass der Dienst an der richtigen Adresse lauscht; - dass TLS funktioniert; - dass das Zertifikat gültig ist; - dass der richtige virtuelle Host ausgewählt wird; - dass ein Reverse Proxy das Backend erreicht; - dass ein Load Balancer ein gesundes Backend besitzt; - dass ein Proxy die Verbindung zulässt; - dass eine Anmeldung möglich ist; - dass der Benutzer ausreichend berechtigt ist; - dass Datenbank, API oder Verzeichnisdienst verfügbar sind; - dass größere Pakete oder Datenübertragungen funktionieren; - dass die eigentliche Anwendung dieselbe IP-Adresse wie Ping verwendet; - dass der vollständige Benutzerablauf funktioniert. Ebenso beweist ein fehlgeschlagener Ping nicht automatisch, dass der Server oder die Anwendung ausgefallen ist. ICMP kann absichtlich blockiert, begrenzt oder niedriger priorisiert werden, während der eigentliche Anwendungsdienst weiterhin erreichbar ist. --- **7.9.6 Fehlerumfang bestimmen** Vor technischen Änderungen muss der Umfang des Fehlers festgestellt werden. Zu prüfen sind: - Ist nur ein Benutzer betroffen? - Ist nur ein Client betroffen? - Ist nur ein Betriebssystem betroffen? - Ist nur ein Standort oder VLAN betroffen? - Tritt der Fehler nur über VPN auf? - Tritt der Fehler nur bei WLAN oder nur bei LAN auf? - Sind alle Benutzer betroffen? - Funktioniert die Anwendung intern, aber nicht extern? - Funktioniert sie über IPv4, aber nicht über IPv6? - Betrifft der Fehler nur einen bestimmten Funktionsbereich? - Tritt der Fehler dauerhaft oder nur zeitweise auf? - Seit welchem Zeitpunkt besteht der Fehler? - Welche Änderung erfolgte unmittelbar davor? Geeignete Vergleichstests: | Vergleich | Mögliche Eingrenzung | |---|---| | gleicher Benutzer an anderem Client | clientbezogener Fehler | | anderer Benutzer am gleichen Client | benutzerbezogener Fehler | | gleicher Client in anderem Netz | Netzwerkpfad oder standortbezogene Regel | | Zugriff mit und ohne VPN | VPN-Route, DNS, Proxy, Firewall oder MTU | | IPv4 und IPv6 getrennt | adressfamilienbezogener Fehler | | direkter Anwendungstest und Zugriff über Proxy | Proxy- oder Reverse-Proxy-Fehler | | lokaler Test auf dem Server und entfernter Test | Dienstfehler oder externer Netzwerkpfad | | einfacher Endpunkt und vollständiger Benutzerablauf | Backend- oder Anwendungsfehler | Kreuztests dürfen nur kontrolliert durchgeführt werden. Produktive Zugangsdaten oder vertrauliche Daten dürfen nicht ungeschützt in Diagnoseausgaben übernommen werden. --- **7.9.7 Ausgangszustand sichern** Vor einem Neustart oder einer Konfigurationsänderung sollten mindestens folgende Informationen gesichert werden: - genaue Fehlermeldung; - Screenshot oder vollständiger Fehlertext; - Zeitpunkt einschließlich Zeitzone; - betroffener Benutzer; - betroffener Client; - verwendetes Netzwerk; - verwendeter Servername; - verwendete Zieladresse; - Port und Protokoll; - URL oder Ressourcenpfad; - Proxy- und VPN-Zustand; - relevante Clientprotokolle; - relevante Serverprotokolle; - Reverse-Proxy- oder Load-Balancer-Protokolle; - Dienststatus; - Listener und Bindungsadresse; - letzte Änderungen; - Vergleich mit einem funktionierenden Client. Ein vorschneller Neustart kann flüchtige Hinweise beseitigen, beispielsweise: - bestehende Verbindungen; - Fehlerzustände; - temporäre Protokolle; - Speicherauslastung; - Portbelegung; - Prozesszustand; - Warteschlangen; - reproduzierbare Zeitüberschreitungen. Änderungen dürfen erst nach Sicherung des Ausgangszustands erfolgen. --- **7.9.8 Tatsächliches Ziel der Anwendung bestimmen** Vor jedem Port- oder Protokolltest muss geklärt werden, welches Ziel die Anwendung wirklich anspricht. Zu erfassen sind: ```text Anwendung: Benutzerfunktion: Servername: Vollständiger DNS-Name: Verwendete IP-Adresse: IPv4 oder IPv6: Transportprotokoll: Port: Anwendungsprotokoll: URL oder Ressourcenpfad: Proxy: VPN: Load Balancer oder Reverse Proxy: Fehlerzeitpunkt: ``` Die Anwendungskonfiguration kann vom vermuteten Standard abweichen. Mögliche Einflussquellen: - explizit eingetragener Servername; - vollständige URL; - abweichender Port; - Hosts-Datei; - DNS-Suffix; - Suchdomäne; - Service-Discovery; - Umgebungsvariable; - Proxykonfiguration; - PAC-Datei; - Reverse Proxy; - Load Balancer; - lokale Anwendungskonfiguration; - gespeicherte Sitzung oder zwischengespeicherte Adresse; - IPv4- oder IPv6-Verwendung; - mandanten-, standort- oder benutzerabhängige Konfiguration; - Umleitungen innerhalb der Anwendung. Besonders wichtig: - Ein Ping auf den Servernamen kann eine andere Adresse verwenden als die Anwendung. - Ein Proxy kann die eigentliche Verbindung stellvertretend aufbauen. - Ein Load Balancer kann mehrere Backendserver verwenden. - Ein Browser kann einen anderen Resolver oder einen eigenen Proxyweg verwenden. - Eine Anwendung kann eine alte Adresse zwischengespeichert haben. - Ein direkter Aufruf per IP-Adresse verändert bei HTTPS möglicherweise SNI, Hostname und Zertifikatsprüfung. Die im Fehlerzeitpunkt verwendete Zieladresse sollte aus der Anwendung, einem Verbindungsprotokoll oder einem Paketmitschnitt bestätigt werden. --- **7.9.9 Namensauflösung prüfen** Windows: ```powershell Resolve-DnsName -Name -Type A Resolve-DnsName -Name -Type AAAA ``` Linux: ```bash getent ahosts dig A dig AAAA ``` macOS: ```bash dscacheutil -q host -a name dig A dig AAAA ``` Zu vergleichen sind: - die von der Anwendung verwendete Adresse; - die von `ping` angezeigte Adresse; - die von `curl -v` verwendete Adresse; - A- und AAAA-Antworten; - die Antworten verschiedener DNS-Server; - interne und öffentliche DNS-Antworten; - das Verhalten mit und ohne VPN. Ein erfolgreicher Ping auf einen Namen beweist nur, dass für diesen Ping-Aufruf eine Namensauflösung möglich war. Die Antwort kann aus DNS, einer Hosts-Datei oder einem anderen lokalen Namensauflösungsverfahren stammen. DNS-Caches sollten nicht als erste Maßnahme gelöscht werden. Zuerst muss dokumentiert werden, welche Adresse aktuell verwendet wird und warum sie falsch sein könnte. --- **7.9.10 TCP-Port gezielt prüfen** Windows: ```powershell Test-NetConnection ` -ComputerName ` -Port ` -InformationLevel Detailed ``` Wichtige Felder: ```text ComputerName RemoteAddress RemotePort InterfaceAlias SourceAddress TcpTestSucceeded ``` Linux und macOS: ```bash nc -vz ``` Ein erfolgreicher TCP-Test beweist: - der verwendete Name wurde aufgelöst; - der Client konnte die verwendete Adresse erreichen; - der TCP-Verbindungsaufbau zum angegebenen Port wurde abgeschlossen. Er beweist nicht: - dass auf dem Port der erwartete Dienst läuft; - dass TLS funktioniert; - dass die Anwendung eine gültige Antwort liefert; - dass eine Anmeldung möglich ist; - dass der vollständige Geschäftsprozess funktioniert. --- **7.9.11 TCP-Fehler richtig interpretieren** | Ergebnis | Bedeutung | Nächster Nachweis | |---|---|---| | `TcpTestSucceeded : True` | TCP-Verbindungsaufbau war möglich | Anwendungsprotokoll und TLS prüfen | | `Connection refused` | Ziel oder zwischengeschaltetes System hat die Verbindung aktiv abgelehnt | Listener, Port und Serverprotokoll prüfen | | Verbindungs-Timeout | Keine rechtzeitige TCP-Antwort | Firewall, Rückweg, Routing, Überlastung oder falsche Adresse untersuchen | | Name nicht gefunden | Zielname konnte nicht aufgelöst werden | Namensauflösung prüfen | | Verbindung wird sofort getrennt | Dienst lehnt Sitzung ab oder falsches Protokoll wird verwendet | Dienst- und Anwendungsprotokoll prüfen | | Verbindung beginnt, bleibt dann hängen | Anwendung, TLS, Backend, Paketverlust oder Pfad-MTU möglich | Protokolle und Paketverlauf untersuchen | Ein Timeout beweist nicht automatisch eine Firewallblockierung. Auch ein falscher Rückweg, ein überlasteter Dienst, ein fehlerhafter Load Balancer oder eine falsche IP-Adresse können zu einem Timeout führen. --- **7.9.12 Anwendungsprotokoll statt nur Port prüfen** Der Test muss zum tatsächlichen Dienst passen. | Dienst | Geeigneter Funktionstest | |---|---| | HTTP oder HTTPS | `curl -v` mit vollständiger URL | | SSH | `ssh -vvv @` | | DNS | `Resolve-DnsName` oder `dig` gegen den vorgesehenen DNS-Server | | SMB | Zugriff auf die konkrete Freigabe testen | | RDP | kontrollierter Verbindungsversuch mit dem RDP-Client | | Datenbank | nativen Datenbankclient mit einer sicheren Leseabfrage verwenden | | API | vorgesehenen Endpunkt, Methode, Header und Authentifizierung prüfen | | herstellerspezifischer Dienst | Diagnoseclient oder dokumentierten Protokolltest des Herstellers verwenden | Ein erfolgreicher Test auf TCP 3389 beweist beispielsweise nur, dass der Port erreichbar ist. Er beweist noch keine funktionierende RDP-Anmeldung oder Sitzung. `curl` ist für HTTP-, HTTPS- und weitere von curl unterstützte Protokolle geeignet. Ein beliebiger TCP-Dienst darf nicht automatisch mit einer HTTP-Anfrage getestet werden. --- **7.9.13 HTTP und HTTPS prüfen** ```bash curl -v --connect-timeout 5 \ "https://:/" ``` Die Ausgabe wird schrittweise ausgewertet: 1. Welche IP-Adresse wird verwendet? 2. Wird eine TCP-Verbindung aufgebaut? 3. Beginnt der TLS-Handshake? 4. Welches Zertifikat wird präsentiert? 5. Wird die Zertifikatsprüfung erfolgreich abgeschlossen? 6. Welche HTTP-Anfrage wird gesendet? 7. Welcher HTTP-Statuscode wird empfangen? 8. Erfolgt eine Umleitung? 9. Antwortet ein Reverse Proxy oder der erwartete Anwendungsserver? 10. Wird eine Anwendungsfehlermeldung zurückgegeben? Wichtige HTTP-Ergebnisse: | Status | Einordnung | |---|---| | `2xx` | Anfrage wurde auf HTTP-Ebene erfolgreich verarbeitet | | `3xx` | Umleitung; Ziel im `Location`-Header prüfen | | `401` | Anwendung erreicht, Authentifizierung erforderlich oder fehlgeschlagen | | `403` | Anwendung erreicht, Zugriff wird verweigert | | `404` | Dienst antwortet, angeforderter Pfad oder virtuelle Zuordnung fehlt | | `407` | Proxy verlangt eine Authentifizierung | | `5xx` | Server, Gateway oder Backend meldet einen Fehler | Auch eine gültige HTTP-Fehlerantwort beweist, dass bereits mehrere Prüfebenen erfolgreich durchlaufen wurden. Sie beweist jedoch nicht, dass die benötigte Benutzerfunktion arbeitet. --- **7.9.14 Bestimmte IP-Adresse mit richtigem Hostnamen testen** Bei HTTPS sollte nicht einfach die IP-Adresse in die URL eingesetzt werden. Dadurch können sich SNI, Host-Header und Zertifikatsprüfung verändern. Mit curl kann ein Servername kontrolliert einer bestimmten Adresse zugeordnet werden: ```bash curl -v \ --resolve :: \ "https://:/" ``` Damit bleiben der Servername in der URL, der HTTP-Host und die TLS-SNI-Angabe erhalten, während die Verbindung gezielt zur angegebenen IP-Adresse aufgebaut wird. Dieser Test ist hilfreich bei: - mehreren A- oder AAAA-Adressen; - Load Balancern; - geplanten DNS-Änderungen; - einem einzelnen verdächtigen Backend; - dem Vergleich alter und neuer Zieladressen. Das Ergebnis gilt nur für die getestete Kombination aus Name, Adresse, Port und Pfad. --- **7.9.15 TLS kurz prüfen** Für HTTPS oder andere TLS-Dienste: ```bash openssl s_client \ -connect : \ -servername \ -verify_hostname \ -verify_return_error ``` Zu prüfen sind: - wird überhaupt eine TCP-Verbindung aufgebaut? - beginnt der TLS-Handshake? - wird der richtige Servername per SNI verwendet? - stimmt der Zertifikatsname mit dem Servernamen überein? - ist die Zertifikatskette vollständig? - vertraut der verwendete Client der ausstellenden Zertifizierungsstelle? - sind Zertifikat und Zwischenzertifikate gültig? - wird eine gemeinsame TLS-Version beziehungsweise Cipher Suite gefunden? - verlangt der Server ein Clientzertifikat? Die Vertrauensstellung von OpenSSL kann sich vom Zertifikatsspeicher der eigentlichen Anwendung unterscheiden. Ein erfolgreicher OpenSSL-Test beweist deshalb nicht automatisch, dass jeder Client dem Zertifikat vertraut. Zertifikatsprüfungen dürfen nicht dauerhaft mit Optionen wie `-k` oder `--insecure` umgangen werden. Die ausführliche TLS-Diagnose erfolgt auf Seite 7.14. --- **7.9.16 Proxy und anwendungsspezifischen Verbindungsweg prüfen** Eine Anwendung kann einen Proxy verwenden, obwohl ein direkter Porttest erfolgreich ist. Umgekehrt kann ein direkter Test scheitern, während der Zugriff ausschließlich über einen Proxy vorgesehen ist. Windows – WinHTTP-Konfiguration: ```powershell netsh winhttp show proxy ``` Umgebungsvariablen in PowerShell: ```powershell Get-ChildItem Env: | Where-Object Name -Match '^(HTTP|HTTPS|NO)_PROXY$' ``` Linux: ```bash env | grep -iE '^(http|https|no)_proxy=' ``` macOS: ```bash scutil --proxy env | grep -iE '^(http|https|no)_proxy=' ``` Zusätzlich zu prüfen: - eigene Proxyeinstellung der Anwendung; - Browser- oder Benutzerproxy; - PAC-Datei; - Proxy-Bypassliste; - Proxy-Authentifizierung; - Abweichung zwischen WinHTTP und benutzerbezogenen Einstellungen; - unterschiedliche Regeln für interne und externe Namen; - VPN-abhängige Proxykonfiguration. `netsh winhttp show proxy` zeigt nur die WinHTTP-Konfiguration. Daraus darf nicht automatisch auf die Konfiguration jedes Browsers oder jeder Anwendung geschlossen werden. --- **7.9.17 Listener auf dem Server prüfen** Wenn der TCP-Port von außen nicht erreichbar ist, muss geprüft werden, ob der Dienst auf dem Server tatsächlich lauscht. Windows: ```powershell Get-NetTCPConnection ` -LocalPort ` -State Listen | Select-Object LocalAddress, LocalPort, State, OwningProcess ``` Zugehörigen Prozess prüfen: ```powershell Get-Process -Id ``` Linux: ```bash sudo ss -lntp ``` macOS: ```bash sudo lsof -nP \ -iTCP: \ -sTCP:LISTEN ``` Zu prüfen sind: - richtiger Port; - erwarteter Prozess; - lokale Bindungsadresse; - IPv4- oder IPv6-Bindung; - Dienststatus; - mehrere konkurrierende Prozesse; - unerwartete Portänderung. Typische Bindungsbefunde: | Bindungsadresse | Bedeutung | |---|---| | `127.0.0.1` | nur lokale IPv4-Verbindungen | | `::1` | nur lokale IPv6-Verbindungen | | konkrete Serveradresse | nur über diese Adresse beziehungsweise Schnittstelle | | `0.0.0.0` | alle lokalen IPv4-Adressen | | `[::]` | alle lokalen IPv6-Adressen; zusätzliches IPv4-Verhalten ist systemabhängig | Ein Dienst, der ausschließlich auf `127.0.0.1` lauscht, kann lokal funktionieren und trotzdem von entfernten Clients nicht erreichbar sein. --- **7.9.18 Lokalen und entfernten Zugriff vergleichen** Auf dem Server kann zunächst ein lokaler Anwendungstest durchgeführt werden: ```bash curl -v \ "http://127.0.0.1:/" ``` Bei einem namensabhängigen HTTPS-Dienst: ```bash curl -v \ --resolve ::127.0.0.1 \ "https://:/" ``` Der lokale Test muss an die tatsächliche Listeneradresse angepasst werden. Ein Dienst, der nur an eine bestimmte Serveradresse gebunden ist, muss über diese Adresse geprüft werden. | Lokaler Test | Entfernter Test | Wahrscheinlicher Bereich | |---|---|---| | schlägt fehl | schlägt fehl | Dienst, Listener, Konfiguration oder Backend | | funktioniert | TCP-Port schlägt fehl | Listenerbindung, Hostfirewall oder Netzwerkpfad | | funktioniert | TCP-Port funktioniert, Protokoll schlägt fehl | TLS, Reverse Proxy, virtueller Host oder Anwendung | | funktioniert | `curl` vom Client funktioniert | Problem im eigentlichen Client oder Benutzerkontext | | funktioniert nur über Loopback | entfernt nicht erreichbar | falsche Listenerbindung wahrscheinlich | | funktioniert über eine Serveradresse | über andere Adresse nicht | Schnittstelle, Routing, DNS oder Firewallregel | Ein lokaler Erfolg beweist nicht, dass die vollständige externe Zugriffskette funktioniert. --- **7.9.19 Firewall, ACL, NAT und Load Balancer prüfen** ICMP und Anwendungsverkehr können durch unterschiedliche Regeln behandelt werden. Zu prüfen sind: - lokale Firewall auf dem Client; - Hostfirewall auf dem Server; - Netzwerkfirewall zwischen den Systemen; - VLAN- oder Segment-ACL; - VPN-Regel; - NAT- oder Portweiterleitung; - Security Group oder Cloud-Firewall; - Load-Balancer-Listener; - Load-Balancer-Healthcheck; - Reverse-Proxy-Route; - Quellnetz- oder benutzerabhängige Regel; - Rückweg vom Server zum Client. Mögliche Konstellationen: - ICMP ist erlaubt, TCP 443 wird verworfen. - TCP 443 erreicht den Load Balancer, aber kein Backend ist gesund. - Der Reverse Proxy besitzt keinen passenden virtuellen Host. - Eine NAT-Regel leitet auf den falschen internen Port weiter. - Eine Firewall erlaubt nur bestimmte Quellnetze. - Der Hinweg funktioniert, der Rückweg verwendet eine falsche Route. - Ein Hostname verweist noch auf eine alte virtuelle IP-Adresse. Firewalls dürfen nicht pauschal deaktiviert werden. Stattdessen müssen Protokoll, Quelladresse, Zieladresse, Port, Richtung und Treffer der konkreten Regel geprüft werden. --- **7.9.20 Authentifizierung und Autorisierung abgrenzen** Wenn eine Anwendung eine Anmeldemaske, einen HTTP-Statuscode oder eine konkrete Berechtigungsfehlermeldung zurückgibt, wurde die Anwendungsebene bereits erreicht. Zu unterscheiden sind: - **Authentifizierung:** Ist die angegebene Identität gültig? - **Autorisierung:** Darf diese Identität die gewünschte Ressource verwenden? - **Anwendungszustand:** Ist Konto, Mandant oder Lizenz in der Anwendung aktiv? - **Verzeichnisdienst:** Kann die Anwendung LDAP, Active Directory oder einen Identitätsanbieter erreichen? - **Sitzung:** Sind Cookie, Token oder Ticket gültig? - **Zeit:** Sind Client, Server und Identitätsdienst ausreichend synchronisiert? Geeignete Kreuztests: | Test | Erkenntnis | |---|---| | anderer Benutzer am selben Client | benutzerbezogener Fehler möglich | | gleicher Benutzer an anderem Client | clientbezogener Fehler möglich | | kontrolliertes Testkonto | Konto- oder Rechteproblem eingrenzen | | anonymer oder öffentlicher Endpunkt | Netzwerk und Anwendung ohne Benutzeranmeldung prüfen | | lokales Anwendungskonto | Abhängigkeit vom Verzeichnisdienst untersuchen | Kontosperren und produktive Benutzerkonten müssen berücksichtigt werden. Die Domänenanmeldung wird ausführlich auf Seite 7.10 behandelt. --- **7.9.21 Anwendungsabhängigkeiten untersuchen** Ein erreichbarer Frontend-Port bedeutet nicht, dass alle Backenddienste funktionieren. Mögliche Abhängigkeiten: - Datenbank; - Verzeichnisdienst; - DNS; - API; - Dateifreigabe; - Objektspeicher; - Nachrichtenwarteschlange; - Cache; - Lizenzserver; - Identitätsanbieter; - externer Cloud-Dienst; - anderer Container oder interner Dienst. Typische Befunde: - Reverse Proxy antwortet mit `502 Bad Gateway`. - Anwendung antwortet mit `503 Service Unavailable`. - Anmeldung bleibt hängen, weil der Identitätsdienst nicht erreichbar ist. - Startseite funktioniert, Datenabfrage schlägt jedoch fehl. - Healthcheck ist erfolgreich, Geschäftsprozess scheitert. - Dienst nimmt TCP-Verbindungen an, besitzt aber keine freien Worker. - Datenträger oder Dateisystem ist voll. - Container ist erreichbar, aber eine interne Abhängigkeit fehlt. Anwendungs-, Proxy- und Backendprotokolle müssen anhand des gleichen Fehlerzeitpunkts korreliert werden. Container-Neustartschleifen werden auf Seite 7.12 und volle Datenträger auf Seite 7.13 ausführlich behandelt. --- **7.9.22 UDP-Dienste korrekt prüfen** UDP besitzt keinen TCP-ähnlichen Verbindungsaufbau. Ein allgemeiner UDP-Porttest kann daher nicht sicher beweisen, dass der Dienst funktioniert. Für UDP muss eine gültige Anfrage des tatsächlichen Anwendungsprotokolls gesendet und die Antwort geprüft werden. DNS-Test unter Windows: ```powershell Resolve-DnsName ` -Name ` -Server ``` DNS-Test unter Linux oder macOS: ```bash dig @ A ``` Ein fehlender UDP-Fehler beweist nicht, dass: - der Port geöffnet ist; - der Dienst läuft; - die Anfrage den Server erreicht hat; - der Server eine gültige Antwort senden kann; - der Rückweg funktioniert. Bei UDP-Diensten sind Anwendungsprotokoll, Serverprotokoll und gegebenenfalls ein kontrollierter Paketmitschnitt besonders wichtig. --- **7.9.23 IPv4 und IPv6 getrennt prüfen** Ein Name kann gleichzeitig A- und AAAA-Einträge besitzen. Ping und Anwendung können unterschiedliche Adressfamilien auswählen. Mit curl getrennt testen: ```bash curl -4 -v \ "https://:/" curl -6 -v \ "https://:/" ``` Zu prüfen sind: - besitzt der Name A- und AAAA-Einträge? - welche Adresse verwendet die fehlerhafte Anwendung? - ist der Dienst an IPv4 und IPv6 gebunden? - besitzen beide Protokolle einen funktionierenden Rückweg? - gelten für IPv4 und IPv6 unterschiedliche Firewallregeln? - funktioniert der Proxy oder Load Balancer mit beiden Adressfamilien? - wird eine veraltete oder nicht erreichbare IPv6-Adresse veröffentlicht? Wenn ausschließlich IPv6 fehlschlägt, muss der IPv6-Pfad oder der AAAA-Eintrag korrigiert werden. IPv6 sollte nicht ohne Ursachenanalyse dauerhaft deaktiviert werden. --- **7.9.24 Paketgröße und Übertragungsverhalten berücksichtigen** Ein kleiner ICMP-Ping kann funktionieren, während größere Anwendungsdaten hängen bleiben. Mögliche Ursachen: - fehlerhafte Path-MTU-Ermittlung; - blockierte erforderliche ICMP-Fehlermeldungen; - Fragmentierungsproblem; - Paketverlust; - fehlerhafter VPN-Tunnel; - Überlastung; - asymmetrischer Pfad; - fehlerhafte Netzwerkhardware. Typische Hinweise: - TCP-Verbindung wird aufgebaut, aber TLS bleibt während des Handshakes hängen. - Kleine Webseiten funktionieren, Downloads brechen ab. - Anwendung funktioniert ohne VPN, aber nicht über den Tunnel. - Wiederholte TCP-Übertragungen sind im Paketmitschnitt sichtbar. - Fehler tritt erst ab einer bestimmten Datenmenge auf. Ein erfolgreicher Standard-Ping darf deshalb nicht als vollständiger Nachweis eines fehlerfreien Datenpfads verwendet werden. --- **7.9.25 Paketmitschnitt kontrolliert einsetzen** Linux oder macOS: ```bash sudo tcpdump -ni \ host and port ``` Alternativ kann Wireshark mit einem passenden Erfassungsfilter verwendet werden. Typische Beobachtungen: | Beobachtung | Einordnung | |---|---| | wiederholte SYN-Pakete ohne Antwort | keine TCP-Antwort; Pfad, Regel oder Ziel prüfen | | SYN wird mit RST beantwortet | Port geschlossen oder Verbindung aktiv abgelehnt | | SYN, SYN-ACK und ACK sichtbar | TCP-Verbindung wurde aufgebaut | | TCP-Verbindung wird danach sofort geschlossen | Dienst oder Protokoll lehnt Verbindung ab | | TLS ClientHello ohne passende Fortsetzung | TLS-Pfad, Server oder Inspektion prüfen | | TLS-Alert | konkrete TLS-Ursache auswerten | | viele Wiederholungen | Paketverlust, Überlastung oder fehlerhafter Pfad möglich | | Antwort verlässt den Server, erreicht Client aber nicht | Rückweg oder zwischengeschaltete Regel prüfen | Ein Paketmitschnitt beweist nur, was an der jeweiligen Erfassungsstelle sichtbar ist. Bei komplexen Pfaden können Mitschnitte auf Client, Server und einem zwischengeschalteten System erforderlich sein. Paketmitschnitte dürfen nur mit entsprechender Berechtigung erstellt und müssen datenschutzgerecht gespeichert werden. --- **7.9.26 Systematischer Diagnoseablauf** 1. **Fehler aufnehmen** Anwendung, Benutzer, Client, Zeitpunkt, Meldung und ursprüngliche Benutzerfunktion dokumentieren. 2. **Umfang bestimmen** Einen Benutzer, einen Client, ein Netz oder alle Benutzer unterscheiden. 3. **Exaktes Ziel bestimmen** Servername, Adresse, Port, Protokoll, Pfad und Verbindungsweg erfassen. 4. **Namensauflösung prüfen** A- und AAAA-Antworten sowie tatsächlich verwendete Adresse vergleichen. 5. **Ping korrekt bewerten** Nur ICMP-Erreichbarkeit als bestätigt betrachten. 6. **Transportprotokoll bestimmen** TCP und UDP unterscheiden. 7. **TCP-Port oder UDP-Anwendung prüfen** Einen zum tatsächlichen Protokoll passenden Test verwenden. 8. **Listener kontrollieren** Port, Prozess und Bindungsadresse auf dem Server prüfen. 9. **Lokalen Anwendungstest durchführen** Dienst auf dem Server über den vorgesehenen Namen, Port und Pfad testen. 10. **Externen Anwendungstest durchführen** Denselben Dienst vom betroffenen Client aus prüfen. 11. **TLS untersuchen** SNI, Zertifikat, Vertrauenskette und Protokollkompatibilität prüfen. 12. **Proxy und VPN berücksichtigen** Tatsächlichen Verbindungsweg der Anwendung nachvollziehen. 13. **Anwendungsantwort auswerten** Statuscode, Protokollmeldung, Umleitung oder Authentifizierungsfehler bestimmen. 14. **Abhängigkeiten prüfen** Datenbank, Identitätsdienst, API, Speicher oder andere Backends untersuchen. 15. **Protokolle korrelieren** Client-, Server-, Proxy- und Anwendungsprotokolle auf denselben Zeitraum begrenzen. 16. **Bei Bedarf Paketverlauf erfassen** SYN, RST, TLS-Alert, Wiederholungen und Rückweg untersuchen. 17. **Hypothese formulieren** Erwartetes Prüfergebnis und möglichen Gegenbeweis festlegen. 18. **Eine kontrollierte Änderung durchführen** Risiko, Rückweg und Erfolgskriterium dokumentieren. 19. **Vollständige Funktion prüfen** Nicht nur Ping oder Port, sondern den ursprünglichen Benutzerablauf testen. 20. **Nachkontrolle durchführen** Protokolle, Überwachung und andere Benutzerfunktionen prüfen. --- **7.9.27 Befundmatrix** | Befund | Mögliche Erklärung | Nächster Nachweis | |---|---|---| | Ping auf IP funktioniert, Name nicht | Namensauflösungsproblem | A-, AAAA-, Hosts- und Resolverdaten prüfen | | Ping auf Name verwendet falsche Adresse | veralteter oder falscher Namenseintrag | autoritative und clientseitige Antwort vergleichen | | Ping funktioniert, TCP-Port hat Timeout | Portverkehr wird verworfen oder Antwort fehlt | Firewall, Routing und Paketverlauf prüfen | | Ping funktioniert, TCP-Port wird abgelehnt | kein Listener oder aktive Ablehnung | Listener und Prozess auf dem Server prüfen | | TCP-Port funktioniert, Verbindung wird sofort geschlossen | falsches Protokoll oder Dienst lehnt Sitzung ab | Dienstprotokoll und Serverlogs prüfen | | TCP funktioniert, TLS schlägt fehl | Zertifikat, SNI, TLS-Version oder Inspektion | `curl -v` oder `openssl s_client` auswerten | | TLS funktioniert, HTTP 401 | Authentifizierung erforderlich oder fehlerhaft | Benutzer-, Token- oder Identitätsanbieter prüfen | | TLS funktioniert, HTTP 403 | fehlende Autorisierung oder Richtlinie | Rollen und Zugriffsrichtlinie prüfen | | HTTP 404 | falscher Pfad oder virtuelle Zuordnung | URL, Host-Header und Proxyroute prüfen | | HTTP 407 | Proxy-Authentifizierung erforderlich | Proxyweg und Benutzerkontext prüfen | | HTTP 502 | Gateway erreicht Backend nicht korrekt | Reverse-Proxy- und Backendprotokolle prüfen | | HTTP 503 | Dienst vorübergehend nicht verfügbar | Healthcheck, Kapazität und Abhängigkeiten prüfen | | lokal funktioniert, entfernt nicht | Bindung, Hostfirewall oder Netzwerkpfad | Listeneradresse und Regeln vergleichen | | `curl` funktioniert, Anwendung nicht | anwendungsspezifische Konfiguration | Proxy, Cache, Zertifikatsspeicher und Benutzerkontext prüfen | | nur ein Client betroffen | lokaler Clientfehler | anderen Client und gleichen Benutzer testen | | nur ein Benutzer betroffen | Konto, Profil, Rechte oder Sitzung | anderes Konto am gleichen Client testen | | nur über VPN betroffen | Route, DNS, MTU oder VPN-Regel | mit und ohne VPN vergleichen | | nur IPv6 betroffen | AAAA-, IPv6-Routing- oder Firewallfehler | `curl -4` und `curl -6` vergleichen | | kleine Anfragen funktionieren | MTU, Paketverlust oder Kapazität möglich | Paketverlauf und größere Übertragung prüfen | | Port erreichbar, Geschäftsprozess scheitert | Backend oder Anwendungslogik fehlerhaft | vollständigen Ablauf und Abhängigkeiten prüfen | --- **7.9.28 Mögliche Ursachen und erforderliche Nachweise** | Mögliche Ursache | Erforderlicher Nachweis | |---|---| | falscher Port | Anwendungskonfiguration und tatsächlicher Listener zeigen unterschiedliche Ports | | Dienst gestoppt | kein Listener vorhanden und Dienststatus beziehungsweise Logs bestätigen den Ausfall | | falsche Listenerbindung | Dienst lauscht nur auf Loopback oder einer anderen Adresse | | Hostfirewall blockiert Port | konkrete Regel oder Protokoll zeigt den verworfenen Verbindungsversuch | | Netzwerkfirewall oder ACL | Trefferprotokoll oder beidseitiger Paketmitschnitt bestätigt die Unterbrechung | | falscher DNS-Eintrag | Anwendung verwendet eine nachweislich falsche oder veraltete Adresse | | fehlerhafter IPv6-Pfad | IPv6-Test scheitert reproduzierbar, IPv4-Test funktioniert | | Proxyfehler | Anwendung verwendet einen fehlerhaften Proxyweg, während direkter Test anders reagiert | | Reverse-Proxy-Fehler | Proxy antwortet, passende Route oder gesundes Backend fehlt | | Load-Balancer-Fehler | virtuelle Adresse ist erreichbar, aber Healthcheck oder Backendzustand ist fehlerhaft | | TLS-Fehler | TLS-Ausgabe zeigt Zertifikats-, SNI- oder Protokollproblem | | fehlende Authentifizierung | Anwendung antwortet mit konkretem Anmelde- oder Tokenfehler | | fehlende Autorisierung | Anmeldung funktioniert, Ressourcenzugriff wird nachvollziehbar verweigert | | ausgefallene Backendabhängigkeit | Frontend antwortet, Serverlogs belegen den Fehler der Abhängigkeit | | Ressourcenengpass | Fehler korreliert mit CPU, Speicher, Worker-, Verbindungs- oder Datenträgerengpass | | Path-MTU- oder Paketverlustproblem | Verbindung beginnt, größere Übertragung scheitert und Paketverlauf bestätigt Wiederholungen oder Größenproblem | | clientseitiger Anwendungsfehler | gleicher Benutzer und Dienst funktionieren mit einem anderen Client | | benutzerbezogener Fehler | anderer Benutzer arbeitet am gleichen Client erfolgreich | --- **7.9.29 Kontrollierte Maßnahmen, Risiko und Rückweg** | Maßnahme | Risiko | Rückweg | |---|---|---| | falschen Servernamen oder Port korrigieren | Verbindung erreicht anderes Ziel | ursprüngliche Konfiguration wiederherstellen | | gestoppten Dienst kontrolliert starten | Dienst kann erneut fehlschlagen oder Last erzeugen | Dienstzustand und Starttyp dokumentieren | | Listenerbindung korrigieren | Dienst wird auf zusätzlichen Netzen erreichbar | vorherige Bindung wiederherstellen | | minimale Firewallfreigabe ergänzen | zusätzliche Erreichbarkeit | konkrete Regel entfernen oder deaktivieren | | falschen DNS-Eintrag korrigieren | Clients wechseln auf neues Ziel | vorherigen Wert und TTL dokumentieren | | Reverse-Proxy-Route korrigieren | andere Anwendungen können betroffen sein | vorherige Proxykonfiguration zurückspielen | | fehlerhaftes Backend aus dem Load Balancer nehmen | geringere Kapazität | Backend nach erfolgreicher Prüfung wieder aufnehmen | | Proxykonfiguration korrigieren | anderer Netzwerkpfad wird verwendet | ursprüngliche Proxywerte wiederherstellen | | Zertifikatskette korrigieren | TLS-Dienst muss eventuell neu geladen werden | vorherige Zertifikatskonfiguration sichern | | Anwendungscache kontrolliert leeren | Sitzungs- oder Anmeldedaten können verloren gehen | Benutzer informieren und Ausgangszustand dokumentieren | | Backenddienst wiederherstellen | abhängige Anwendungen können beeinflusst werden | dienstspezifischen Wiederherstellungsplan verwenden | | Ressource freigeben oder Kapazität erhöhen | Lastverteilung kann sich ändern | vorherige Kapazitäts- oder Ressourcenwerte sichern | Pro Maßnahme sollte möglichst nur eine relevante Variable verändert werden. --- **7.9.30 Verifikation** Nach einer Maßnahme müssen mindestens folgende Prüfungen erfolgen: - Servername wird in die erwartete Adresse aufgelöst; - richtige IPv4- oder IPv6-Adresse wird verwendet; - vorgesehener TCP- oder UDP-Dienst ist erreichbar; - richtiger Prozess lauscht auf dem vorgesehenen Port; - TLS-Handshake und Zertifikatsprüfung funktionieren; - Anwendung liefert die erwartete Protokollantwort; - Anmeldung funktioniert; - benötigte Ressource kann geöffnet werden; - vollständiger ursprünglicher Benutzerablauf funktioniert; - Frontend und Backend arbeiten zusammen; - Test funktioniert aus dem betroffenen Netz; - bei größerem Umfang funktionieren mehrere repräsentative Clients; - keine neuen Fehler erscheinen in Client-, Server- oder Proxyprotokollen; - temporäre Freigaben oder Diagnoseänderungen wurden zurückgenommen; - Firewall und Zertifikatsprüfung sind weiterhin aktiv; - Überwachung prüft nicht nur Ping, sondern auch die Anwendungsfunktion; - keine andere Anwendung wurde durch die Änderung beeinträchtigt. Ein erfolgreicher Ping oder Porttest allein ist keine ausreichende Verifikation. --- **7.9.31 Präventionsmaßnahmen** - Anwendungserreichbarkeit zusätzlich zu ICMP überwachen; - TCP-Port, TLS und einen geeigneten Anwendungsendpunkt prüfen; - kritische Geschäftsprozesse mit synthetischen Funktionstests überwachen; - Servername, Port, Protokoll und Abhängigkeiten dokumentieren; - DNS-Änderungen mit TTL und Rückweg planen; - Zertifikatsablauf und vollständige Zertifikatskette überwachen; - Proxy-, VPN- und Firewallregeln dokumentieren; - Load-Balancer-Healthchecks an die tatsächliche Dienstfunktion anpassen; - Listenerbindungen und Portzuordnungen dokumentieren; - IPv4 und IPv6 getrennt überwachen; - Kapazitätsgrenzen für Worker, Verbindungen, CPU, Speicher und Datenträger überwachen; - Frontend- und Backendprotokolle zeitlich synchronisieren; - Änderungen an DNS, Firewall, Proxy und Anwendung nachvollziehbar protokollieren; - Wiederherstellungs- und Rückfallverfahren testen; - Monitoring nicht auf „Host ist pingbar“ beschränken. --- **7.9.32 Typische Fehler bei der Diagnose** - Einen erfolgreichen Ping mit einer funktionierenden Anwendung gleichsetzen. - Einen Ping als Test eines TCP- oder UDP-Ports interpretieren. - Einen anderen Port als den tatsächlich konfigurierten Port testen. - Die IP-Adresse statt des vorgesehenen HTTPS-Namens aufrufen. - SNI, Host-Header und Zertifikatsnamen ignorieren. - `curl` für einen nicht unterstützten oder nicht HTTP-basierten Dienst verwenden. - Einen allgemeinen UDP-Test als sicheren Funktionsnachweis betrachten. - Einen Timeout automatisch als Firewallfehler einstufen. - `Connection refused` und Timeout gleichsetzen. - Nur einen lokalen Test auf dem Server durchführen. - Nur prüfen, ob der Prozess läuft, statt den Listener zu kontrollieren. - Nur prüfen, ob der Port offen ist, statt das Anwendungsprotokoll zu testen. - Eine HTTP-Antwort automatisch als vollständigen Anwendungserfolg werten. - Einen Healthcheck mit dem eigentlichen Geschäftsprozess gleichsetzen. - Proxy, VPN, Load Balancer oder Reverse Proxy ignorieren. - IPv4 und IPv6 nicht getrennt prüfen. - Firewalls vollständig deaktivieren. - Zertifikatsprüfungen dauerhaft umgehen. - Vor der Protokollsicherung Dienste oder Server neu starten. - Zugangsdaten, Token oder vollständige Debugausgaben ungeschützt weitergeben. - Nach einer Änderung nur erneut pingen und die ursprüngliche Benutzerfunktion nicht testen. --- **7.9.33 Typische Prüfungsfragen** **Warum beweist ein erfolgreicher Ping keine funktionierende Anwendung?** Ping prüft ICMP-Echo-Kommunikation. Die Anwendung kann einen anderen Transportweg, einen bestimmten TCP- oder UDP-Port, TLS, Authentifizierung und weitere Backenddienste benötigen. **Welcher Test sollte nach einem erfolgreichen Ping durchgeführt werden?** Zuerst müssen Zielname, Protokoll und Port der Anwendung bestimmt werden. Anschließend wird der konkrete TCP-Port oder das tatsächliche UDP-Anwendungsprotokoll geprüft. **Was bedeutet „Connection refused“?** Die TCP-Verbindung wurde aktiv abgelehnt. Häufig fehlt ein Listener auf dem Zielport oder eine Komponente lehnt die Verbindung gezielt ab. Der genaue Absender der Ablehnung muss bei Bedarf mit Protokollen oder einem Paketmitschnitt bestimmt werden. **Was bedeutet ein TCP-Timeout?** Der Verbindungsaufbau wurde nicht rechtzeitig abgeschlossen. Mögliche Ursachen sind eine verwerfende Firewallregel, ein falscher Netzwerkpfad, ein fehlender Rückweg, Überlastung oder eine falsche Zieladresse. **Warum sollte ein HTTPS-Dienst nicht nur über seine IP-Adresse getestet werden?** Virtuelle Hosts, TLS-SNI und Zertifikatsprüfung verwenden den Servernamen. Ein Aufruf über die IP-Adresse kann deshalb einen anderen Dienst oder ein anderes Zertifikat erreichen. **Was beweist ein erfolgreicher TCP-Porttest?** Er beweist, dass zum Testzeitpunkt eine TCP-Verbindung zur geprüften Adresse und zum geprüften Port aufgebaut werden konnte. Die Funktion des Anwendungsprotokolls ist damit noch nicht bewiesen. **Was bedeutet ein HTTP-Statuscode 401 oder 403 für die Netzwerkdiagnose?** Die Anwendung wurde erreicht und hat auf HTTP-Ebene geantwortet. Der Fehler liegt anschließend wahrscheinlich bei Authentifizierung, Autorisierung oder einer Anwendungsrichtlinie. **Warum ist ein allgemeiner UDP-Porttest nicht eindeutig?** UDP besitzt keinen verbindlichen Verbindungsaufbau. Ohne gültige Anwendungsanfrage und auswertbare Antwort lässt sich die Dienstfunktion nicht sicher bestätigen. **Was bedeutet es, wenn die Anwendung lokal auf dem Server funktioniert, vom Client aber nicht?** Der Dienst selbst arbeitet grundsätzlich. Danach müssen Listenerbindung, Hostfirewall, Netzwerkpfad, Proxy, Load Balancer und externe Namensauflösung geprüft werden. **Warum kann `curl` funktionieren, obwohl die eigentliche Anwendung fehlschlägt?** Die Anwendung kann einen anderen Proxy, Zertifikatsspeicher, DNS-Cache, Benutzerkontext, Authentifizierungsmechanismus oder zusätzliche Protokollfunktionen verwenden. **Warum reicht ein erfolgreicher Healthcheck nicht immer aus?** Ein Healthcheck kann nur einen einfachen Endpunkt prüfen. Datenbankzugriff, Anmeldung oder der eigentliche Geschäftsprozess können trotzdem fehlschlagen. --- **7.9.34 Checkliste** - [ ] ursprüngliche Benutzerfunktion dokumentiert - [ ] genaue Fehlermeldung und Fehlerzeitpunkt erfasst - [ ] betroffene Benutzer und Clients bestimmt - [ ] vollständiger Servername erfasst - [ ] verwendete Zieladresse bestätigt - [ ] TCP oder UDP bestimmt - [ ] richtiger Port bestimmt - [ ] Protokoll und URL-Pfad bestimmt - [ ] Ping nur als ICMP-Test bewertet - [ ] A- und AAAA-Auflösung geprüft - [ ] tatsächlich verwendete Adresse kontrolliert - [ ] TCP-Port oder UDP-Anwendung geprüft - [ ] Listener und zugehöriger Prozess geprüft - [ ] Bindungsadresse kontrolliert - [ ] lokaler Anwendungstest durchgeführt - [ ] entfernter Anwendungstest durchgeführt - [ ] TLS und Zertifikat geprüft - [ ] Proxy- und VPN-Weg geprüft - [ ] Firewall, ACL und Rückweg berücksichtigt - [ ] Load Balancer oder Reverse Proxy geprüft - [ ] Anwendungsantwort und Statuscode ausgewertet - [ ] Authentifizierung und Autorisierung unterschieden - [ ] Backendabhängigkeiten geprüft - [ ] IPv4 und IPv6 getrennt getestet - [ ] Client-, Server- und Proxyprotokolle korreliert - [ ] Paketmitschnitt nur bei Bedarf und berechtigt erstellt - [ ] Hypothese und Gegenbeweis formuliert - [ ] Risiko und Rückweg vor Änderung dokumentiert - [ ] nur eine kontrollierte Änderung durchgeführt - [ ] vollständiger Benutzerablauf verifiziert - [ ] temporäre Diagnoseänderungen zurückgenommen - [ ] Ergebnis und Präventionsmaßnahme dokumentiert --- **7.9.35 Schnellreferenz** | Aufgabe | Windows | Linux | macOS | |---|---|---|---| | Ping | `ping ` | `ping -c 4 ` | `ping -c 4 ` | | Namensauflösung | `Resolve-DnsName ` | `getent ahosts ` | `dscacheutil -q host -a name ` | | A-Eintrag | `Resolve-DnsName -Type A` | `dig A` | `dig A` | | AAAA-Eintrag | `Resolve-DnsName -Type AAAA` | `dig AAAA` | `dig AAAA` | | TCP-Port | `Test-NetConnection -Port ` | `nc -vz ` | `nc -vz ` | | HTTP oder HTTPS | `curl.exe -v ` | `curl -v ` | `curl -v ` | | IPv4 mit curl | `curl.exe -4 -v ` | `curl -4 -v ` | `curl -4 -v ` | | IPv6 mit curl | `curl.exe -6 -v ` | `curl -6 -v ` | `curl -6 -v ` | | bestimmte Ziel-IP | `curl.exe --resolve :: ` | `curl --resolve :: ` | `curl --resolve :: ` | | Listener | `Get-NetTCPConnection -State Listen` | `sudo ss -lntp` | `sudo lsof -nP -iTCP -sTCP:LISTEN` | | WinHTTP-Proxy | `netsh winhttp show proxy` | nicht zutreffend | nicht zutreffend | | Systemproxy | Anwendungseinstellungen prüfen | Anwendung und Umgebungsvariablen prüfen | `scutil --proxy` | | TLS | `openssl s_client` bei installierter OpenSSL-Version | `openssl s_client` | `openssl s_client` | | Paketmitschnitt | Wireshark oder freigegebenes Windows-Werkzeug | `tcpdump` oder Wireshark | `tcpdump` oder Wireshark | --- **7.9.36 Quellen** **Standards und RFCs** - [RFC 792 – Internet Control Message Protocol](https://datatracker.ietf.org/doc/html/rfc792) - [RFC 9293 – Transmission Control Protocol](https://www.rfc-editor.org/rfc/rfc9293) - [RFC 9110 – HTTP Semantics](https://datatracker.ietf.org/doc/html/rfc9110) - [RFC 8446 – The Transport Layer Security Protocol Version 1.3](https://datatracker.ietf.org/doc/html/rfc8446) - [RFC 1191 – Path MTU Discovery für IPv4](https://datatracker.ietf.org/doc/html/rfc1191) - [RFC 8201 – Path MTU Discovery für IPv6](https://datatracker.ietf.org/doc/html/rfc8201) - [IANA – HTTP Status Code Registry](https://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml) **Offizielle Hersteller- und Projektdokumentation** - [Microsoft Learn – Test-NetConnection](https://learn.microsoft.com/en-us/powershell/module/nettcpip/test-netconnection) - [Microsoft Learn – Resolve-DnsName](https://learn.microsoft.com/en-us/powershell/module/dnsclient/resolve-dnsname) - [Microsoft Learn – Get-NetTCPConnection](https://learn.microsoft.com/en-us/powershell/module/nettcpip/get-nettcpconnection) - [Microsoft Learn – netsh winhttp](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/netsh-winhttp) - [curl – offizielle Befehlsreferenz](https://curl.se/docs/manpage.html) - [Everything curl – Verbose output](https://everything.curl.dev/usingcurl/verbose.html) - [OpenSSL – openssl s_client](https://docs.openssl.org/3.6/man1/openssl-s_client/) - [OpenBSD – nc(1)](https://man.openbsd.org/nc) **Lokale Befehlsreferenzen** Die genaue Syntax kann von Betriebssystem und installierter Version abhängen. Maßgeblich ist die lokale Befehlsreferenz: ```bash man ping man nc man curl man ss man lsof man tcpdump man dscacheutil man scutil ``` Für diese Seite wurden keine Community-Berichte, Hersteller-Social-Media-Aussagen oder eigenen Laborergebnisse als Nachweis verwendet. # 7.10 Anmeldung an der Domäne funktioniert nicht **7.10.1 Ausgangssituation** Ein Benutzer kann sich an einem Windows-Computer nicht mit seinem Domänenkonto anmelden. Mögliche Meldungen sind beispielsweise: ```text Der Benutzername oder das Kennwort ist falsch. ``` ```text Es sind momentan keine Anmeldeserver zum Verarbeiten der Anmeldeanforderung verfügbar. ``` ```text Die Vertrauensstellung zwischen dieser Arbeitsstation und der primären Domäne konnte nicht hergestellt werden. ``` ```text Wir können Sie mit diesen Anmeldeinformationen nicht anmelden, weil Ihre Domäne nicht verfügbar ist. ``` ```text Der Sicherheitsdatenbank auf dem Server ist kein Computerkonto für diese Arbeitsstationsvertrauensstellung zugeordnet. ``` ```text Der Benutzerprofildienst konnte die Anmeldung nicht durchführen. ``` Diese Meldungen beschreiben unterschiedliche Fehlerbereiche. Eine fehlgeschlagene Domänenanmeldung darf deshalb nicht automatisch auf ein falsches Kennwort reduziert werden. --- **7.10.2 Ziel der Diagnose** Die Diagnose soll eindeutig bestimmen, ob der Fehler verursacht wird durch: - eine falsche Anmeldeidentität; - falsche oder veraltete Anmeldeinformationen; - ein gesperrtes, deaktiviertes oder abgelaufenes Benutzerkonto; - eine fehlende Netzwerk- oder VPN-Verbindung; - eine fehlerhafte DNS-Konfiguration; - eine fehlgeschlagene Domänencontroller-Ermittlung; - einen nicht erreichbaren Domänencontroller; - eine zu große Zeitabweichung; - einen Kerberos- oder NTLM-Fehler; - einen beschädigten sicheren Kanal des Computers; - eine fehlerhafte Active-Directory-Replikation; - eine Anmelde-, Sicherheits- oder Zugriffsrichtlinie; - eine Smartcard-, Zertifikats- oder Windows-Hello-Abhängigkeit; - den Benutzerprofildienst, eine Gruppenrichtlinie oder ein Anmeldeskript; - eine RDP-, NLA- oder Remotedesktop-Besonderheit; - eine standort-, RODC- oder vertrauensstellungsabhängige Konfiguration. Erst nach dem Nachweis der Ursache wird eine kontrollierte Maßnahme durchgeführt. --- **7.10.3 Geltungsbereich und Abgrenzung** Diese Seite behandelt hauptsächlich die Anmeldung eines Domänenbenutzers an einem Computer, der Mitglied einer lokalen Active-Directory-Domäne mit Active Directory Domain Services ist. Davon zu unterscheiden sind: | Konto- oder Geräteart | Kennzeichnung beziehungsweise Beispiel | |---|---| | lokales Konto | `.\MaxMustermann` oder `\MaxMustermann` | | Active-Directory-Domänenkonto | `\MaxMustermann` | | Active-Directory-UPN | `max.mustermann@` | | Microsoft-Entra-Konto | häufig ebenfalls UPN-Format, aber cloudbasierte Identität | | Microsoft-Konto | persönliche Microsoft-Identität | | Smartcard-Anmeldung | zertifikatsbasierte Anmeldung | | Windows Hello for Business | schlüssel- oder zertifikatsbasierte Anmeldung | | Remotedesktop-Anmeldung | Anmeldung erfolgt am entfernten Zielsystem | | Dienst- oder Aufgabenanmeldung | nicht interaktiver Anmeldetyp | Ein Benutzername im Format `benutzer@domäne` beweist allein nicht, ob ein lokales Active Directory, Microsoft Entra ID oder ein anderer Identitätsanbieter verwendet wird. Microsoft-Entra-Anmeldefehler, MFA und Conditional Access benötigen teilweise andere Diagnoseverfahren. Sie dürfen nicht mit einer klassischen AD-Domänenanmeldung gleichgesetzt werden. --- **7.10.4 Technischer Anmeldeweg** Eine normale Online-Domänenanmeldung benötigt mehrere funktionierende Ebenen: 1. Der Benutzer wählt den richtigen Anmeldeanbieter. 2. Windows ordnet den eingegebenen Namen dem vorgesehenen Konto zu. 3. Der Computer besitzt eine geeignete Netzwerkverbindung. 4. Der Client verwendet die vorgesehenen DNS-Server. 5. DNS liefert die erforderlichen Domänen- und Dienstinformationen. 6. DC Locator ermittelt einen geeigneten Domänencontroller. 7. Die benötigten Netzwerkprotokolle erreichen den Domänencontroller. 8. Client und Domänencontroller besitzen ausreichend synchronisierte Uhrzeiten. 9. Der Computer besitzt eine gültige Vertrauensbeziehung zur Domäne. 10. Kerberos, NTLM oder das vorgesehene zertifikatsbasierte Verfahren beginnt. 11. Der Domänencontroller prüft das Benutzerkonto und die Anmeldeinformationen. 12. Kontorichtlinien und Anmelderechte werden ausgewertet. 13. Windows erzeugt die Anmeldesitzung und das Zugriffstoken. 14. Benutzerprofil, Gruppenrichtlinien und Anmeldeskripte werden verarbeitet. 15. Der Desktop beziehungsweise die vorgesehene Sitzung wird bereitgestellt. Der sichtbare Fehler kann an jeder dieser Ebenen entstehen. --- **7.10.5 Zuerst die genaue Fehlerphase bestimmen** | Fehlerphase | Typische Beobachtung | Wahrscheinlicher Bereich | |---|---|---| | vor Eingabe der Anmeldedaten | Netzwerk- oder Anmeldeoption fehlt | Client, Treiber, VPN oder Anmeldeanbieter | | unmittelbar nach Eingabe | Kennwort- oder Kontofehler | Identität, Kennwort, Sperre oder Kontorichtlinie | | längere Wartezeit vor Fehlermeldung | kein DC, DNS, Netzwerk oder Timeout | Infrastruktur und Erreichbarkeit | | Meldung über Vertrauensstellung | Computerkonto oder sicherer Kanal | Computervertrauen | | Anmeldung funktioniert offline, aber nicht online | Cache oder unterschiedlicher DC-Zustand | DNS, DC, Kennwort oder Replikation | | Anmeldung wird akzeptiert, Desktop erscheint nicht | Profil, Richtlinie, Skript oder Ressource | Phase nach der Authentifizierung | | temporäres Profil wird geladen | Benutzerprofilproblem | Profilpfad, Datenträger oder Profildienst | | nur RDP schlägt fehl | RDP, NLA, Anmelderecht oder Zielsystem | entfernter Computer | | PIN schlägt fehl, Kennwort funktioniert | Windows Hello oder PIN-Anbieter | Hello-Schlüssel, TPM oder Richtlinie | | Smartcard schlägt fehl, Kennwort funktioniert | Zertifikat oder PKI | Smartcard, Zertifikatskette, KDC-Zertifikat oder Sperrprüfung | Eine erfolgreiche Kennwortprüfung bedeutet noch nicht, dass Benutzerprofil, Gruppenrichtlinien und Desktop erfolgreich geladen werden. --- **7.10.6 Beweise vor Änderungen sichern** Vor einem Neustart, einer Kennwortzurücksetzung, dem Entsperren eines Kontos oder einer Reparatur des sicheren Kanals sollten mindestens folgende Informationen gesichert werden: - exakter Wortlaut der Fehlermeldung; - Datum und Uhrzeit des Versuchs; - betroffener Benutzer; - betroffener Computer; - Anmeldeart: lokal, Konsole, RDP, VPN, Smartcard, PIN oder Kennwort; - eingegebenes Namensformat; - aktueller Standort und Netzwerkweg; - Verbindung mit oder ohne VPN; - letzter erfolgreicher Anmeldezeitpunkt; - Umfang des Fehlers; - kürzlich erfolgte Kennwort-, Computer-, DNS-, VPN- oder Richtlinienänderungen; - verwendeter oder erwarteter Domänencontroller; - relevante Ereignisse auf Client und Domänencontroller. Kennwörter, PINs, private Schlüssel, Wiederherstellungsschlüssel und vollständige Anmeldetoken dürfen nicht dokumentiert oder weitergegeben werden. Wiederholte unkontrollierte Anmeldeversuche müssen vermieden werden, weil dadurch das Konto gesperrt werden kann. --- **7.10.7 Umfang des Fehlers bestimmen** Geeignete Kreuztests: | Vergleich | Erkenntnis | |---|---| | gleicher Benutzer an anderem Domänencomputer | benutzer- oder computerbezogenen Fehler unterscheiden | | anderer Domänenbenutzer am gleichen Computer | Benutzerkonto und Computerzustand unterscheiden | | gleiches Konto mit und ohne VPN | VPN-, DNS- oder Routingabhängigkeit erkennen | | gleiches Konto an Konsole und per RDP | lokale und entfernte Anmeldung unterscheiden | | Kennwort statt PIN | Windows-Hello-Fehler abgrenzen | | Kennwort statt Smartcard | Zertifikats- oder Smartcardfehler abgrenzen | | lokales Administratorkonto | Zugriff für die Clientdiagnose ermöglichen | | Test gegen anderen Standort oder anderen DC | standort- oder DC-bezogenen Fehler erkennen | Auswertung: | Ergebnis | Wahrscheinlicher Bereich | |---|---| | nur ein Benutzer betroffen | Benutzerkonto, Kennwort, Sperre oder Benutzerprofil | | alle Benutzer an einem Computer betroffen | Client, DNS, Netzwerk, Zeit oder sicherer Kanal | | viele Computer betroffen | DNS, DC, Netzwerk, Zeitdienst, Replikation oder zentrale Richtlinie | | nur ein Standort betroffen | Standortnetz, VPN, DNS, Firewall oder Standortzuordnung | | nur ein Domänencontroller betroffen | DC-Dienst, DNS-Registrierung, Replikation oder Zeit | | nur neue Kennwörter betroffen | Kennwortcache, Replikation oder gespeicherte alte Anmeldedaten | | Authentifizierung funktioniert, Desktop nicht | Profil, Gruppenrichtlinie, Skript oder Ressource | Ein Testkonto darf nur nach den organisatorischen Sicherheitsvorgaben verwendet werden. --- **7.10.8 Richtige Identität und Anmeldeoption prüfen** Am Anmeldebildschirm muss geprüft werden: - welcher Benutzer angezeigt wird; - welche Domäne oder welcher Computername unter dem Benutzer steht; - ob „Anderer Benutzer“ gewählt wurde; - ob Kennwort, PIN, Smartcard oder ein anderer Anmeldeanbieter aktiv ist; - ob das richtige Tastaturlayout verwendet wird; - ob Feststelltaste oder Num-Taste den eingegebenen Wert verändert; - ob ein alter Benutzername automatisch vorausgefüllt wurde; - ob ein lokales Konto statt des Domänenkontos gewählt wurde; - ob ein UPN oder der `DOMÄNE\Benutzer`-Name erforderlich ist. Beispiele: ```text \MaxMustermann ``` ```text max.mustermann@ ``` ```text .\MaxMustermann ``` Bedeutung: - `\MaxMustermann` erzwingt die Zuordnung zur angegebenen AD-Domäne. - `max.mustermann@` verwendet den Benutzerprinzipalnamen. - `.\MaxMustermann` bezeichnet ein lokales Konto des Computers. NETBIOS-Domänenname und DNS-Domänenname müssen nicht identisch sein. Ein lokaler Anmeldeerfolg beweist weder eine funktionierende Domänenverbindung noch ein gültiges Domänenkonto. --- **7.10.9 Bestehende Sitzung und Identität prüfen** Wenn noch eine bestehende Sitzung verfügbar ist: ```cmd whoami whoami /user whoami /fqdn whoami /groups ``` In PowerShell: ```powershell $env:USERDOMAIN $env:USERDNSDOMAIN $env:LOGONSERVER ``` Wichtige Einschränkungen: - `whoami` beschreibt die bereits bestehende Sitzung. - `$env:LOGONSERVER` zeigt den Anmeldeserver dieser Sitzung, nicht zwingend den DC, den ein neuer Versuch verwenden würde. - Eine alte Sitzung kann weiter funktionieren, obwohl eine neue Anmeldung fehlschlägt. - Eine Anmeldung aus dem lokalen Cache kann ohne aktuelle DC-Authentifizierung entstanden sein. - Gruppenmitgliedschaften im bestehenden Zugriffstoken können veraltet sein. --- **7.10.10 Domänenmitgliedschaft des Computers prüfen** Mit einem autorisierten lokalen Konto oder einer noch verfügbaren Administrationssitzung: ```powershell Get-CimInstance Win32_ComputerSystem | Select-Object Name, PartOfDomain, Domain, Workgroup ``` Erwartet wird: ```text PartOfDomain : True Domain : ``` Zusätzlich: ```cmd systeminfo ``` Relevante Felder sind: ```text Domäne Anmeldeserver ``` Zu prüfen sind: - ist der Computer tatsächlich Domänenmitglied? - gehört er zur erwarteten Domäne? - wurde er versehentlich in eine Arbeitsgruppe verschoben? - wurde ein altes Systemabbild oder ein VM-Snapshot wiederhergestellt? - existiert ein anderer Computer mit demselben Namen? - wurde das Computerkonto gelöscht, zurückgesetzt oder neu angelegt? - wurde das Gerät geklont, ohne die Identität ordnungsgemäß vorzubereiten? `PartOfDomain : True` beweist nur die lokale Mitgliedschaftskonfiguration. Es beweist nicht, dass der sichere Kanal aktuell funktioniert. --- **7.10.11 Online-Anmeldung und zwischengespeicherte Domänenanmeldung unterscheiden** Windows kann Informationen früherer Domänenanmeldungen lokal zwischenspeichern. Dadurch kann sich ein Benutzer unter bestimmten Voraussetzungen anmelden, obwohl kein Domänencontroller erreichbar ist. Eine zwischengespeicherte Anmeldung beweist nicht: - dass ein Domänencontroller erreichbar war; - dass das Konto aktuell aktiviert ist; - dass das Konto aktuell nicht gesperrt ist; - dass das aktuelle Domänenkennwort verwendet wurde; - dass Kerberos-Tickets ausgestellt wurden; - dass Netzwerkressourcen erreichbar sind; - dass Gruppenmitgliedschaften aktuell sind. Wurde das Kennwort an einem anderen Computer geändert, kann ein offline verwendeter Client weiterhin den früher zwischengespeicherten Kennwortnachweis erwarten. Erst eine erfolgreiche Online-Anmeldung kann den lokalen Anmeldecache aktualisieren. Die Anzahl zwischengespeicherter eindeutiger Benutzer wird durch die Sicherheitsrichtlinie bestimmt: ```text Computerkonfiguration └── Windows-Einstellungen └── Sicherheitseinstellungen └── Lokale Richtlinien └── Sicherheitsoptionen └── Interaktive Anmeldung: Anzahl zwischenzuspeichernder vorheriger Anmeldungen ``` Der genaue Wert ist eine Sicherheitsentscheidung der Organisation. Er darf nicht nur zur Fehlerumgehung verändert werden. Typische Unterscheidung: | Verhalten | Einordnung | |---|---| | Anmeldung ohne Netzwerk funktioniert | Cache-Anmeldung möglich | | Anmeldung mit Netzwerk schlägt fehl | Online-Authentifizierung oder anderer DC-Zustand fehlerhaft | | altes Kennwort funktioniert offline | lokaler Cache kann noch den alten Nachweis enthalten | | neues Kennwort funktioniert online | DC kennt das neue Kennwort | | neues Kennwort funktioniert an einem Gerät, an anderem nicht | Cache, DC-Auswahl oder Replikation prüfen | | noch nie auf diesem Computer angemeldeter Benutzer kann offline nicht anmelden | kein passender lokaler Anmeldecache vorhanden | --- **7.10.12 Netzwerkzustand des Clients prüfen** ```powershell Get-NetAdapter | Select-Object Name, Status, LinkSpeed, MacAddress ``` ```powershell Get-NetIPConfiguration ``` ```cmd ipconfig /all ``` Zu dokumentieren sind: - aktive Schnittstelle; - IPv4- und IPv6-Adresse; - Präfix beziehungsweise Subnetzmaske; - Standardgateway; - DNS-Server; - DHCP-Status; - DNS-Suffix; - VPN-Adapter; - mehrere gleichzeitig aktive Verbindungen; - APIPA-Adresse aus `169.254.0.0/16`; - unerwartete öffentliche oder private DNS-Server. Ein Ping zum Gateway oder zu einem DC ist nur ein Teilnachweis. Die Domänenanmeldung benötigt DNS, DC Locator und mehrere Anwendungsprotokolle. Bei einer Anmeldung außerhalb des Unternehmensnetzes ist zu prüfen, ob eine Anmeldung vor dem Windows-Desktop überhaupt eine VPN-Verbindung herstellen kann. Ein VPN, das erst nach der Benutzeranmeldung startet, kann keine erstmalige Online-Domänenanmeldung ermöglichen. --- **7.10.13 DNS-Konfiguration prüfen** Active Directory ist auf DNS-basierte Diensterkennung angewiesen. Der Client sollte die für die AD-Domäne vorgesehenen DNS-Server verwenden. DNS-Server anzeigen: ```powershell Get-DnsClientServerAddress | Select-Object InterfaceAlias, AddressFamily, ServerAddresses ``` Domänenname prüfen: ```powershell Resolve-DnsName -Name -Type A ``` Domänencontroller-Dienst prüfen: ```powershell Resolve-DnsName ` -Name _ldap._tcp.dc._msdcs. ` -Type SRV ``` Kerberos-Dienst prüfen: ```powershell Resolve-DnsName ` -Name _kerberos._tcp. ` -Type SRV ``` Einen bestimmten DNS-Server verwenden: ```powershell Resolve-DnsName ` -Name _ldap._tcp.dc._msdcs. ` -Type SRV ` -Server ``` Zu prüfen sind: - antwortet der vorgesehene interne DNS-Server? - existieren die benötigten SRV-Einträge? - verweisen die SRV-Einträge auf vorhandene Domänencontroller? - lassen sich die zurückgegebenen DC-Namen in gültige Adressen auflösen? - werden alte oder außer Betrieb genommene DCs geliefert? - erhält der Client über VPN andere DNS-Server? - verwendet eine zweite Netzwerkschnittstelle ungeeignete DNS-Server? - stimmt das DNS-Suffix? - sind IPv4- und IPv6-Antworten erreichbar? - unterscheiden sich die Antworten verschiedener DNS-Server? Öffentliche Resolver kennen die internen Active-Directory-Dienstinformationen normalerweise nicht. Ein zusätzlich eingetragener öffentlicher DNS-Server ist kein zuverlässiger Ersatz für den vorgesehenen AD-DNS-Server. DNS-Caches sollten nicht sofort gelöscht werden. Zuerst müssen aktuelle Antworten, DNS-Server und die verwendete Zieladresse dokumentiert werden. --- **7.10.14 Domänencontroller-Ermittlung prüfen** Windows verwendet DC Locator und den Netlogon-Dienst, um über DNS-SRV-Einträge einen geeigneten Domänencontroller zu finden. ```cmd nltest /dsgetdc: ``` Erneute DNS-basierte Ermittlung ohne den bisherigen DC-Cache: ```cmd nltest /dsgetdc: /force ``` Nur einen beschreibbaren DC anfordern: ```cmd nltest /dsgetdc: /writable /force ``` Lokalen AD-Standort anzeigen: ```cmd nltest /dsgetsite ``` Bekannte Domänencontroller auflisten: ```cmd nltest /dclist: ``` In der Ausgabe von `nltest /dsgetdc` sind unter anderem wichtig: ```text DC Address Domain Name Forest Name Dc Site Name Our Site Name Flags ``` Auswertung: | Ergebnis | Bedeutung | |---|---| | geeigneter DC wird gefunden | DC Locator war für diesen Versuch erfolgreich | | `ERROR_NO_SUCH_DOMAIN` | Domäne oder DC konnte nicht gefunden werden | | falscher Standort | Subnetz- oder Standortzuordnung prüfen | | alter DC wird geliefert | DNS-Registrierung und AD-Metadaten prüfen | | nur ein entfernter DC wird gefunden | lokaler DC, Standort oder DNS möglicherweise fehlerhaft | | DC wird gefunden, Anmeldung scheitert trotzdem | Erreichbarkeit, Zeit, Konto, sicherer Kanal und Protokoll prüfen | Ein erfolgreiches `nltest /dsgetdc` beweist nicht, dass alle für die Anmeldung benötigten Protokolle funktionieren. --- **7.10.15 Erreichbarkeit der benötigten Dienste prüfen** Grundlegende TCP-Tests: ```powershell Test-NetConnection -ComputerName -Port 53 Test-NetConnection -ComputerName -Port 88 Test-NetConnection -ComputerName -Port 135 Test-NetConnection -ComputerName -Port 389 Test-NetConnection -ComputerName -Port 445 ``` Je nach Funktion zusätzlich: ```powershell Test-NetConnection -ComputerName -Port 464 Test-NetConnection -ComputerName -Port 3268 Test-NetConnection -ComputerName -Port 636 Test-NetConnection -ComputerName -Port 3269 ``` Wichtige AD-Protokolle: | Dienst | Protokoll und Port | Bedeutung | |---|---|---| | DNS | TCP/UDP 53 | Namens- und Dienstauflösung | | Kerberos | TCP/UDP 88 | Kerberos-Authentifizierung | | Windows-Zeit | UDP 123 | Zeitsynchronisation | | RPC Endpoint Mapper | TCP 135 | RPC-Endpunktermittlung | | LDAP | TCP 389 | Verzeichniszugriff | | DC Locator | UDP 389 | DC-Ermittlung | | SMB | TCP 445 | Netlogon, SYSVOL und Gruppenrichtlinien | | Kerberos-Kennwortdienst | TCP/UDP 464 | Kennwortänderungen | | Global Catalog | TCP 3268 | gesamtstrukturweite Abfragen | | LDAPS | TCP 636 | LDAP über TLS, sofern verwendet | | Global Catalog über TLS | TCP 3269 | GC über TLS, sofern verwendet | | dynamische RPC-Ports | üblicherweise TCP 49152–65535 bei modernen Windows-Versionen | ausgehandelte RPC-Verbindungen | Wichtige Einschränkungen: - `Test-NetConnection` prüft hier nur TCP. - Ein erfolgreicher Test auf TCP 53 beweist keine funktionierende DNS-Kommunikation über UDP. - Ein erfolgreicher Test auf TCP 88 beweist keine vollständige Kerberos-Authentifizierung. - Ein erfolgreicher Test auf TCP 135 beweist nicht, dass der anschließend ausgehandelte dynamische RPC-Port erreichbar ist. - Nicht jede Umgebung benötigt bei jedem Anmeldevorgang alle aufgeführten optionalen Ports. - Ein allgemeiner UDP-Porttest liefert keinen eindeutigen Funktionsnachweis. - Die Freigabe einzelner Ports ohne Kenntnis des vollständigen AD-Verbindungswegs kann unvollständig sein. Firewalls dürfen nicht pauschal deaktiviert werden. Die konkrete Regel muss anhand von Quelle, Ziel, Protokoll, Port, Richtung und Zeitstempel geprüft werden. --- **7.10.16 Zeit und Zeitsynchronisation prüfen** Kerberos benötigt ausreichend synchronisierte Uhrzeiten. Die standardmäßige maximale Kerberos-Zeitabweichung beträgt in vielen AD-Umgebungen fünf Minuten, kann aber durch Richtlinien verändert werden. Clientstatus: ```cmd w32tm /query /status w32tm /query /source w32tm /query /configuration ``` Zeitabweichung zu einem DC beobachten: ```cmd w32tm /stripchart /computer: /dataonly /samples:5 ``` Zusätzlich zu prüfen: ```powershell Get-Service W32Time ``` Zu vergleichen sind: - Datum; - Uhrzeit; - Zeitzone; - Zeitquelle; - letzter erfolgreicher Synchronisierungszeitpunkt; - Zeitabweichung zum verwendeten DC; - Zustand des Windows-Zeitdienstes; - Hypervisor- oder VM-Zeitsynchronisation; - Zeitquellen der Domänencontroller; - PDC-Emulator und externe Zeitquelle. Eine richtige Bildschirmanzeige allein beweist keine korrekte Zeitkonfiguration. Zeitzone, UTC-Zeit, Zeitquelle und tatsächliche Abweichung müssen getrennt betrachtet werden. Eine Resynchronisation ist eine Änderung und sollte erst nach Dokumentation der bisherigen Quelle und Abweichung erfolgen: ```cmd w32tm /resync /rediscover ``` Danach müssen Quelle, Status und Abweichung erneut geprüft werden. --- **7.10.17 Benutzerkonto prüfen** Mit dem ActiveDirectory-PowerShell-Modul und ausreichender Leseberechtigung: ```powershell Get-ADUser ` -Identity "" ` -Properties Enabled, LockedOut, PasswordExpired, AccountExpirationDate, PasswordLastSet, LastBadPasswordAttempt, BadLogonCount, LogonWorkstations | Select-Object SamAccountName, UserPrincipalName, Enabled, LockedOut, PasswordExpired, AccountExpirationDate, PasswordLastSet, LastBadPasswordAttempt, BadLogonCount, LogonWorkstations ``` Ergebnisbezogene Kennwortrichtlinie prüfen: ```powershell Get-ADUserResultantPasswordPolicy ` -Identity "" ``` Gezielte Suchbefehle: ```powershell Search-ADAccount -LockedOut -UsersOnly Search-ADAccount -AccountDisabled -UsersOnly Search-ADAccount -AccountExpired -UsersOnly Search-ADAccount -PasswordExpired -UsersOnly ``` Alternativ mit integrierten Werkzeugen: ```cmd net user /domain ``` Zu prüfen sind: - existiert das Konto? - wird der richtige UPN verwendet? - ist das Konto aktiviert? - ist das Konto gesperrt? - ist das Konto abgelaufen? - ist das Kennwort abgelaufen? - wurde das Kennwort kürzlich geändert oder zurückgesetzt? - darf sich das Konto nur an bestimmten Arbeitsstationen anmelden? - gelten eingeschränkte Anmeldezeiten? - gilt eine fein abgestufte Kennwortrichtlinie? - besitzt das Konto besondere Authentifizierungsanforderungen? - stammt der angezeigte Zustand vom gleichen DC, der den Fehler verarbeitet hat? `BadLogonCount`, `LastBadPasswordAttempt` und ähnliche Werte können DC-abhängig sein. Sie dürfen nicht ohne Berücksichtigung des abgefragten Domänencontrollers und der Replikation interpretiert werden. Ein Konto sollte nicht vorsorglich entsperrt oder dessen Kennwort zurückgesetzt werden, bevor die Quelle fehlerhafter Anmeldeversuche untersucht wurde. Gespeicherte alte Kennwörter in Diensten, Aufgaben, Mobilgeräten oder Anwendungen können das Konto sofort erneut sperren. --- **7.10.18 Kennwortfehler systematisch abgrenzen** Mögliche Ursachen trotz scheinbar richtiger Eingabe: - falscher Benutzer oder falsche Domäne; - falsches Tastaturlayout; - Feststelltaste oder Num-Taste; - Kennwort wurde kürzlich geändert; - alter zwischengespeicherter Anmeldenachweis; - Kennwortänderung wurde noch nicht vollständig repliziert; - gespeicherte alte Anmeldeinformationen; - Konto wurde gesperrt; - Kennwort ist abgelaufen; - Benutzer muss das Kennwort bei der nächsten Anmeldung ändern; - Kennwortänderungsdienst oder DC ist nicht erreichbar; - Smartcard- oder Windows-Hello-Anbieter wurde statt Kennwort gewählt. Ein administratives Zurücksetzen des Kennworts kann Auswirkungen auf verschlüsselte benutzerbezogene Daten, gespeicherte Anmeldeinformationen und Zertifikatsschlüssel besitzen. Es muss nach dem vorgesehenen Identitäts- und Wiederherstellungsverfahren erfolgen. --- **7.10.19 Sicheren Kanal des Computers prüfen** Domänencomputer und Domäne besitzen eine Vertrauensbeziehung auf Grundlage des Computerkontos und eines Computerkennworts. Stimmen der lokale und der in Active Directory gespeicherte Zustand nicht mehr überein, kann der sichere Kanal fehlschlagen. Typische Meldung: ```text Die Vertrauensstellung zwischen dieser Arbeitsstation und der primären Domäne konnte nicht hergestellt werden. ``` Nur prüfen: ```powershell``` Test-ComputerSecureChannel -Verbose ``` Erwartetes Ergebnis: ```text True ``` Ein bestimmter DC kann für den Test angegeben werden: ```powershell Test-ComputerSecureChannel ` -Server "" ` -Verbose ``` Status des zuletzt verwendeten Netlogon-Kanals anzeigen: ```cmd nltest /sc_query: ``` Wichtige Einschränkungen: - `Test-ComputerSecureChannel` ist für Domänenmitgliedscomputer geeignet. - Auf Domänencontrollern kann das Cmdlet falsch-negative Ergebnisse liefern. - `nltest /sc_query` meldet den Zustand der letzten Verwendung und ist kein vollständiger neuer Funktionstest. - `nltest /sc_verify` ist kein rein lesender Test: Wenn der Kanal nicht funktioniert, kann der Befehl den Kanal entfernen und neu aufbauen. - `nltest /sc_reset`, `nltest /sc_change_pwd`, `Reset-ComputerMachinePassword` und `Test-ComputerSecureChannel -Repair` verändern den Zustand. - Eine Reparatur darf erst nach Prüfung von DNS, Netzwerk, Zeit, DC-Zustand und Computerkonto erfolgen. Mögliche Ursachen eines defekten sicheren Kanals: - Wiederherstellung eines alten VM-Snapshots; - Zurückspielen eines veralteten Systemabbilds; - doppelter Computername; - gelöschtes oder zurückgesetztes Computerkonto; - Neuinstallation mit wiederverwendetem Computernamen; - nicht ordnungsgemäß geklonter Rechner; - nicht übereinstimmendes Computerkennwort; - AD-Replikationsfehler; - längere Netzwerk- oder DC-Probleme; - fehlerhafte Automatisierung bei der Gerätebereitstellung. Ein defekter sicherer Kanal ist ein konkreter Befund. Der Computer sollte nicht vorsorglich aus der Domäne entfernt werden. --- **7.10.20 Kerberos und NTLM unterscheiden** Windows verwendet häufig das Aushandlungspaket `Negotiate`. Dieses wählt nach Möglichkeit Kerberos und kann unter bestimmten Bedingungen NTLM verwenden. Kerberos benötigt unter anderem: - funktionierende DNS-Auflösung; - erreichbaren KDC auf dem Domänencontroller; - ausreichend synchronisierte Zeit; - ein gültiges Benutzerkonto; - passende kryptografische Schlüssel; - bei Dienstzugriffen einen korrekten Service Principal Name; - bei Smartcard-Anmeldung geeignete Zertifikate und Vertrauensketten. NTLM benötigt ebenfalls einen erreichbaren zuständigen Authentifizierungsserver und darf nicht als automatische oder dauerhafte Lösung für Kerberos-Probleme betrachtet werden. Ein erfolgreicher NTLM-Versuch beweist nicht, dass Kerberos funktioniert. Ein Fehlschlag bei Kerberos darf nicht ungeprüft durch Lockerung der Sicherheitsrichtlinien oder dauerhafte Aktivierung veralteter Verfahren umgangen werden. --- **7.10.21 Kerberos-Tickets prüfen** In einer bestehenden Domänensitzung: ```cmd klist ``` TGT anzeigen: ```cmd klist tgt ``` Alle Tickets der aktuellen Sitzung anzeigen: ```cmd klist tickets ``` Zu prüfen sind: - ist ein Ticket Granting Ticket vorhanden? - für welche Kerberos-Realm wurde es ausgestellt? - welcher KDC hat das Ticket ausgestellt? - sind Start- und Ablaufzeit plausibel? - sind Diensttickets für die erwarteten Dienste vorhanden? - wird statt Kerberos möglicherweise NTLM verwendet? - stimmt der Servername mit dem erwarteten Dienstnamen überein? `klist purge` löscht Kerberos-Tickets der angegebenen Anmeldesitzung und ist daher keine rein lesende Diagnose: ```cmd klist purge ``` Mögliche Auswirkungen: - bestehende Zugriffe müssen neu authentifiziert werden; - Netzlaufwerke oder Anwendungen können vorübergehend Verbindungen verlieren; - die eigentliche Ursache kann durch das Löschen alter Nachweise verdeckt werden; - der Befehl betrifft nur die ausgewählte Anmeldesitzung. Tickets sollten deshalb zuerst dokumentiert und nur im Rahmen eines kontrollierten Tests gelöscht werden. Eine fehlgeschlagene interaktive Anmeldung besitzt möglicherweise noch keine normale Benutzersitzung, in der `klist` ausgeführt werden kann. In diesem Fall sind die Ereignisse auf dem Domänencontroller besonders wichtig. --- **7.10.22 Relevante Ereignisprotokolle** Ereignisse müssen anhand des gleichen Benutzer-, Computer- und Fehlerzeitpunkts korreliert werden. Auf dem betroffenen Client: - **Windows-Protokolle → System** - **Windows-Protokolle → Sicherheit** - **Anwendungs- und Dienstprotokolle → Microsoft → Windows → GroupPolicy → Operational** - **Anwendungs- und Dienstprotokolle → Microsoft → Windows → User Profile Service → Operational** - Netlogon-, DNS-Client-, LSA-, Kerberos-, W32Time- und Gruppenrichtlinienereignisse Auf dem beteiligten Domänencontroller: - **Windows-Protokolle → Sicherheit** - **Windows-Protokolle → System** - **Verzeichnisdienst** - **DNS-Server** - **DFS-Replikation** - Kerberos-, Netlogon-, KDC-, LSA- und Replikationsereignisse Beispiel für Clientereignisse der letzten zwei Stunden: ```powershell Get-WinEvent -FilterHashtable @{ LogName = 'System' StartTime = (Get-Date).AddHours(-2) } | Where-Object { $_.ProviderName -match 'NETLOGON|W32Time|DNS|Lsa' } | Select-Object TimeCreated, ProviderName, Id, LevelDisplayName, Message ``` Fehlgeschlagene Anmeldungen auf einem System: ```powershell Get-WinEvent -FilterHashtable @{ LogName = 'Security' Id = 4625 StartTime = (Get-Date).AddHours(-2) } | Select-Object TimeCreated, Id, Message ``` Relevante Ereignisse: | Ereignis-ID | Typische Bedeutung | Typischer Ort | |---|---|---| | `4624` | erfolgreiche Anmeldung | System, auf dem die Anmeldung erfolgte | | `4625` | fehlgeschlagene Anmeldung | System, auf dem die Anmeldung versucht wurde | | `4740` | Benutzerkonto wurde gesperrt | zuständiges System beziehungsweise DC | | `4767` | Benutzerkonto wurde entsperrt | Domänencontroller | | `4768` | Kerberos-TGT wurde angefordert | Domänencontroller | | `4769` | Kerberos-Dienstticket wurde angefordert | Domänencontroller | | `4771` | Kerberos-Vorauthentifizierung fehlgeschlagen | Domänencontroller | | `4776` | NTLM-Anmeldeinformationen wurden geprüft | für Domänenkonten auf dem zuständigen DC | | `3210` | Netlogon konnte Computer nicht beim DC authentifizieren | Mitgliedscomputer | | `5719` | kein Domänencontroller für sichere Sitzung verfügbar | Mitgliedscomputer | | `1053` oder `1055` | Gruppenrichtlinienverarbeitung mit Domänen- oder DC-Problem | Mitgliedscomputer | Die Ereignisse erscheinen nur, wenn die entsprechenden Überwachungsrichtlinien und Protokollkanäle aktiviert sind. Das Fehlen eines Ereignisses beweist deshalb nicht, dass kein Versuch stattgefunden hat. --- **7.10.23 Ereignis 4625 auswerten** Bei Ereignis `4625` sind besonders wichtig: ```text Account Name Account Domain Failure Reason Status Sub Status Logon Type Logon Process Authentication Package Workstation Name Source Network Address Caller Process Name ``` Wichtige Anmeldetypen: | Logon Type | Bedeutung | |---:|---| | `2` | interaktive lokale Anmeldung | | `3` | Netzwerkanmeldung | | `4` | Batch beziehungsweise geplante Aufgabe | | `5` | Dienstanmeldung | | `7` | Entsperren | | `10` | Remotedesktop beziehungsweise RemoteInteractive | | `11` | zwischengespeicherte interaktive Anmeldung | Häufige Status- oder Substatuswerte: | Code | Bedeutung | Nächster Nachweis | |---|---|---| | `0xC000005E` | keine Anmeldeserver verfügbar | DNS, DC Locator, Netzwerk und DC-Zustand prüfen | | `0xC0000064` | Benutzerkonto nicht gefunden | Benutzername, Domäne und Kontobestand prüfen | | `0xC000006A` | falsches Kennwort | Eingabe, Kennwortänderung und gespeicherte Kennwörter prüfen | | `0xC000006D` | allgemeiner Fehler bei Benutzername oder Authentifizierungsdaten | Status, Substatus und Authentifizierungspaket korrelieren | | `0xC000006F` | Anmeldung außerhalb erlaubter Zeiten | Anmeldezeiten prüfen | | `0xC0000070` | Anmeldung von nicht erlaubter Arbeitsstation | Arbeitsstationsbeschränkung prüfen | | `0xC0000071` | Kennwort abgelaufen | Kennwortstatus und Änderungsweg prüfen | | `0xC0000072` | Konto deaktiviert | Kontostatus und Änderungshistorie prüfen | | `0xC000015B` | erforderlicher Anmeldetyp nicht gewährt | Benutzerrechte und Richtlinien prüfen | | `0xC0000192` | Netlogon-Dienst ist nicht gestartet | Dienstzustand und Systemereignisse prüfen | | `0xC0000193` | Konto abgelaufen | Ablaufdatum des Kontos prüfen | | `0xC0000234` | Konto gesperrt | Ereignis 4740 und Quelle der Fehlversuche untersuchen | | `0xC0000413` | Authentifizierungsfirewall verhindert Anmeldung | Authentifizierungsrichtlinie und zulässige Systeme prüfen | Status und Substatus müssen gemeinsam ausgewertet werden. Der sichtbare Meldungstext am Anmeldebildschirm kann absichtlich weniger genau sein als das Sicherheitsereignis. --- **7.10.24 Kerberos-Ereignisse auswerten** Ereignis `4768` zeigt die Anforderung eines Kerberos-TGT. Ereignis `4771` zeigt eine fehlgeschlagene Kerberos-Vorauthentifizierung. Häufige Kerberos-Fehlercodes: | Code | Kerberos-Bezeichnung | Einordnung | |---|---|---| | `0x6` | `KDC_ERR_C_PRINCIPAL_UNKNOWN` | Benutzerprinzipal nicht in Kerberos-Datenbank gefunden | | `0x7` | `KDC_ERR_S_PRINCIPAL_UNKNOWN` | angeforderter Dienstprinzipal nicht gefunden | | `0x8` | `KDC_ERR_PRINCIPAL_NOT_UNIQUE` | Prinzipal nicht eindeutig | | `0xC` | `KDC_ERR_POLICY` | KDC-Richtlinie lehnt Anfrage ab | | `0xE` | `KDC_ERR_ETYPE_NOSUPP` | keine gemeinsame unterstützte Verschlüsselungsart | | `0x10` | `KDC_ERR_PADATA_TYPE_NOSUPP` | Vorauthentifizierungstyp nicht unterstützt; bei Smartcard auch Zertifikatsproblem möglich | | `0x12` | `KDC_ERR_CLIENT_REVOKED` | Anmeldeinformationen des Clients wurden widerrufen | | `0x17` | `KDC_ERR_KEY_EXPIRED` | Kennwort abgelaufen | | `0x18` | `KDC_ERR_PREAUTH_FAILED` | Vorauthentifizierung ungültig; häufig falsches Kennwort | | `0x19` | `KDC_ERR_PREAUTH_REQUIRED` | zusätzliche Vorauthentifizierung erforderlich; nicht automatisch ein Fehler | | `0x1D` | `KDC_ERR_SVC_UNAVAILABLE` | Kerberos-Dienst nicht verfügbar | | `0x20` | `KRB_AP_ERR_TKT_EXPIRED` | Ticket abgelaufen | | `0x25` | `KRB_AP_ERR_SKEW` | Zeitabweichung zu groß | | `0x34` | `KRB_ERR_RESPONSE_TOO_BIG` | Antwort zu groß für UDP; erneuter Versuch über TCP erforderlich | Ein einzelner Kerberos-Fehlercode muss mit Benutzer, Clientadresse, DC, Zeitstempel und nachfolgendem Erfolg oder Fehlschlag korreliert werden. Der Code `0x19` kann Teil eines normalen Kerberos-Ablaufs sein und darf nicht allein als Störung gewertet werden. --- **7.10.25 Kontosperren bis zur Quelle verfolgen** Bei einer Sperre muss nicht nur das Konto entsperrt, sondern die Quelle der wiederholten falschen Kennwörter bestimmt werden. Zu untersuchen sind: - Ereignis `4740`; - aufrufender Computer; - Ereignisse `4771` bei Kerberos; - Ereignisse `4776` bei NTLM; - Ereignisse `4625` auf Quell- und Zielsystemen; - gespeicherte Windows-Anmeldeinformationen; - verbundene Netzlaufwerke; - geplante Aufgaben; - Windows-Dienste; - Anwendungen mit gespeichertem Kennwort; - Mobilgeräte und Mailprogramme; - VPN-Clients; - alte RDP-Sitzungen; - Skripte; - weitere Computer des Benutzers. Eine Kontosperre kann durch einen Hintergrundprozess entstehen, obwohl der Benutzer sein aktuelles Kennwort am Anmeldebildschirm richtig eingibt. --- **7.10.26 Active-Directory-Replikation prüfen** Wenn Anmeldungen abhängig vom verwendeten Domänencontroller unterschiedlich reagieren, müssen Replikation und DC-Zustand geprüft werden. Auf einem autorisierten Administrationssystem oder Domänencontroller: ```cmd repadmin /replsummary ``` ```cmd repadmin /showrepl ``` Gesamtstrukturweite Übersicht: ```cmd repadmin /showrepl * /csv ``` Grundlegender DC-Test: ```cmd dcdiag /v ``` DNS-Test für einen bestimmten DC: ```cmd dcdiag /test:DNS /v /s: ``` Zu prüfen sind: - letzte erfolgreiche Replikation; - Anzahl und Dauer der Fehler; - betroffene Verzeichnispartition; - Quell- und Ziel-DC; - DNS-Fehler; - RPC-Fehler; - Zugriffs- oder Vertrauensfehler; - Zeitabweichung; - Replikation von Benutzer- und Computerkontoänderungen; - Erreichbarkeit des PDC-Emulators; - SYSVOL- und DFSR-Zustand. Mögliche Symptome eines Replikationsfehlers: - neues Kennwort funktioniert nur über bestimmte DCs; - Konto erscheint auf einem DC gesperrt und auf einem anderen nicht; - neues Benutzer- oder Computerkonto ist nicht überall vorhanden; - reparierter sicherer Kanal schlägt über einen anderen DC erneut fehl; - Gruppenmitgliedschaften unterscheiden sich; - Anmeldung funktioniert standortabhängig. Eine erzwungene Replikation ist keine erste Diagnosemaßnahme. Zuerst müssen Richtung, Fehlercode, Ursache und Replikationspartner bestimmt werden. --- **7.10.27 Standort, VPN und RODC berücksichtigen** AD-Standorte beeinflussen die Auswahl eines Domänencontrollers. Clientstandort anzeigen: ```cmd nltest /dsgetsite ``` Zu prüfen sind: - ist das Clientsubnetz in Active Directory Sites and Services eingetragen? - ist es dem richtigen Standort zugeordnet? - besitzt dieser Standort einen erreichbaren DC? - antwortet ein entfernter DC schneller als der lokale DC? - verteilt das VPN das richtige AD-Subnetz und die richtigen DNS-Server? - sind die notwendigen Netze über den Tunnel erreichbar? - existieren unterschiedliche Regeln vor und nach der Benutzeranmeldung? - verwendet der Standort einen Read-Only Domain Controller? - darf der RODC die Anmeldeinformationen dieses Benutzers zwischenspeichern? - ist ein beschreibbarer DC erreichbar, wenn Kennwortänderung oder Kontosperrenbehandlung erforderlich ist? Ein RODC kann nur solche Anmeldungen lokal verarbeiten, für die die erforderlichen Anmeldeinformationen entsprechend der Kennwortreplikationsrichtlinie verfügbar sind oder ein beschreibbarer DC erreicht werden kann. --- **7.10.28 RDP- und NLA-Anmeldungen abgrenzen** Bei Remotedesktop erfolgt die Anmeldung am entfernten Computer. Entscheidend sind daher DNS, Netzwerk, Zeit, Domänenverbindung, sicherer Kanal und Anmelderechte des Zielsystems. Zu prüfen sind: - wird der richtige Zielcomputer angesprochen? - verwendet der RDP-Client gespeicherte alte Anmeldeinformationen? - ist das richtige Namensformat angegeben? - ist Network Level Authentication aktiv? - kann das Zielsystem einen DC erreichen? - ist der sichere Kanal des Zielsystems gültig? - besitzt der Benutzer das Recht zur Anmeldung über Remotedesktopdienste? - wird dieses Recht durch eine Verweigerungsrichtlinie überschrieben? - ist der Benutzer Mitglied der vorgesehenen lokalen oder domänenweiten Gruppe? - existiert bereits eine eingeschränkte oder getrennte Sitzung? - liegt Ereignis `4625` mit Logon Type `10` vor? Ein erfolgreicher Domänenlogin am lokalen Notebook beweist nicht, dass der entfernte Server die Domäne erreichen oder den Benutzer anmelden kann. NLA sollte nicht dauerhaft deaktiviert werden, nur um einen Authentifizierungsfehler zu umgehen. --- **7.10.29 Smartcard und Windows Hello for Business abgrenzen** Wenn Kennwortanmeldung funktioniert, aber Smartcard oder Windows Hello fehlschlägt, ist die normale Kennwortprüfung wahrscheinlich nicht die Hauptursache. Bei Smartcard-Anmeldung zu prüfen: - Smartcard und Lesegerät; - Benutzerzertifikat; - Gültigkeitszeitraum; - UPN beziehungsweise Identitätszuordnung; - Zertifikatskette; - Sperrstatus und Erreichbarkeit der CRL- oder OCSP-Dienste; - KDC-Zertifikat des Domänencontrollers; - geeignete Zertifikatvorlage; - unterstützte Kryptografie; - Zeit; - Ereignis `4771` und PKINIT-Fehlercodes. Bei Windows Hello for Business zu prüfen: - wurde PIN oder Kennwort gewählt? - ist das Gerät ordnungsgemäß registriert? - ist der Hello-Schlüssel vorhanden? - ist das TPM verfügbar? - stimmt der Vertrauensmodus der Organisation? - wurden Richtlinien oder Zertifikate verändert? - ist eine Onlineverbindung für den jeweiligen Vorgang erforderlich? Eine PIN ist nicht das Domänenkennwort. Ein PIN-Fehler beweist deshalb nicht, dass das AD-Kennwort falsch ist. --- **7.10.30 Authentifizierung, Sitzung und Benutzerprofil unterscheiden** Nach erfolgreicher Authentifizierung können weitere Fehler auftreten: - Benutzerprofildienst kann das Profil nicht laden; - Profilpfad ist nicht erreichbar; - servergespeichertes Profil ist beschädigt; - lokaler Profildatenträger ist voll; - Berechtigungen des Profilordners sind fehlerhaft; - Gruppenrichtlinienverarbeitung hängt; - Anmeldeskript wartet auf eine nicht erreichbare Ressource; - Ordnerumleitung schlägt fehl; - Netzlaufwerk oder Druckerzuordnung hat ein Timeout; - Sicherheitssoftware blockiert den Sitzungsaufbau; - Windows lädt ein temporäres Profil. Typische Unterscheidung: | Beobachtung | Einordnung | |---|---| | Ereignis 4624 vorhanden, danach Profilfehler | Authentifizierung war wahrscheinlich erfolgreich | | Desktop erscheint nach langer Wartezeit | Gruppenrichtlinie, Skript oder Ressource prüfen | | temporäres Profil | Benutzerprofil und Datenträger prüfen | | nur ein Benutzerprofil betroffen | lokales oder servergespeichertes Profil möglich | | Anmeldung anderer Benutzer funktioniert | allgemeine DC-Erreichbarkeit wahrscheinlich vorhanden | | Anmeldung im abgesicherten Diagnosekontext funktioniert | nachgelagerte Erweiterung, Richtlinie oder Dienst möglich | Gruppenrichtlinienstatus in einer bestehenden Sitzung: ```cmd gpresult /r ``` Computerrichtlinien: ```cmd gpresult /r /scope computer ``` Benutzerrichtlinien: ```cmd gpresult /r /scope user ``` `gpupdate /force` ist keine reine Diagnose. Der Befehl kann neue Richtlinien anwenden und den Ausgangszustand verändern. --- **7.10.31 Systematischer Diagnoseablauf** 1. **Fehlermeldung aufnehmen** Exakten Wortlaut, Benutzer, Computer, Uhrzeit und Anmeldeart dokumentieren. 2. **Anmeldephase bestimmen** Identität, Authentifizierung, Sitzung oder Profil unterscheiden. 3. **Umfang bestimmen** Einen Benutzer, einen Computer, einen Standort oder die gesamte Domäne unterscheiden. 4. **Anmeldeanbieter kontrollieren** Kennwort, PIN, Smartcard, lokales Konto und Domänenkonto unterscheiden. 5. **Namensformat prüfen** UPN und `DOMÄNE\Benutzer` kontrolliert vergleichen. 6. **Domänenmitgliedschaft prüfen** Lokale Mitgliedschaft und erwartete Domäne bestätigen. 7. **Online- und Cache-Anmeldung unterscheiden** Feststellen, ob ein DC tatsächlich beteiligt war. 8. **Netzwerkzustand prüfen** Schnittstelle, Adresse, Gateway, VPN und DNS-Server dokumentieren. 9. **DNS-SRV-Einträge prüfen** LDAP- und Kerberos-Diensteinträge auflösen. 10. **Domänencontroller ermitteln** `nltest /dsgetdc` und Standortinformationen auswerten. 11. **DC-Erreichbarkeit prüfen** DNS, Kerberos, LDAP, SMB, RPC und benötigte Zusatzdienste untersuchen. 12. **Zeit prüfen** Zeitquelle, Status und Abweichung zum DC bestimmen. 13. **Benutzerkonto prüfen** Existenz, UPN, Aktivierung, Sperre, Ablauf und Kennwortstatus auswerten. 14. **Sicheren Kanal prüfen** Ausschließlich mit lesenden Tests beginnen. 15. **Authentifizierungsverfahren bestimmen** Kerberos, NTLM, Smartcard oder Windows Hello unterscheiden. 16. **Ereignisse korrelieren** Client- und DC-Ereignisse auf denselben Versuch begrenzen. 17. **Fehlercode auswerten** Status, Substatus, Kerberos-Code und Anmeldetyp bestimmen. 18. **Replikation prüfen** Besonders bei DC- oder Standortabhängigkeit. 19. **Nachgelagerte Anmeldung prüfen** Profil, Gruppenrichtlinie, Skript und Ressourcen untersuchen. 20. **Hypothese formulieren** Erwarteten Befund und möglichen Gegenbeweis festlegen. 21. **Eine kontrollierte Maßnahme durchführen** Risiko, Berechtigung, Rückweg und Erfolgskriterium dokumentieren. 22. **Online-Domänenanmeldung verifizieren** Nicht nur Cache- oder lokale Anmeldung testen. 23. **Vollständige Benutzerfunktion prüfen** Desktop, Gruppenrichtlinien und benötigte Ressourcen kontrollieren. 24. **Nachkontrolle durchführen** Ereignisse, Replikation und weitere Benutzer beziehungsweise Systeme prüfen. --- **7.10.32 Befundmatrix** | Befund | Mögliche Erklärung | Nächster Nachweis | |---|---|---| | lokales Konto funktioniert, Domänenkonto nicht | Domänenweg oder Domänenkonto fehlerhaft | DNS, DC Locator, Konto und sicheren Kanal prüfen | | anderer Benutzer funktioniert am gleichen Computer | benutzerbezogener Fehler | Kontostatus, Kennwort und Profil prüfen | | gleicher Benutzer funktioniert an anderem Computer | clientbezogener Fehler | DNS, Zeit, sicherer Kanal und Profil prüfen | | Anmeldung funktioniert nur offline | Cache-Anmeldung | Onlineweg zum DC prüfen | | altes Kennwort funktioniert offline | alter lokaler Anmeldecache | Onlineanmeldung mit aktuellem Kennwort prüfen | | `nltest /dsgetdc` findet keinen DC | DNS, Netzwerk oder Netlogon | SRV-Einträge, DNS-Server und Dienst prüfen | | DC wird gefunden, Ports schlagen fehl | Firewall, Routing oder DC-Dienst | Regeln und beidseitige Protokolle prüfen | | Ereignis `0xC000005E` | keine Anmeldeserver verfügbar | DNS, DC Locator und Netzwerk prüfen | | Ereignis `0xC0000064` | Benutzer nicht gefunden | Identität und Kontobestand prüfen | | Ereignis `0xC000006A` | falsches Kennwort | Kennwort, Cache und gespeicherte Daten prüfen | | Ereignis `0xC0000234` | Konto gesperrt | Ereignis 4740 und Sperrquelle prüfen | | Kerberos `0x18` | Vorauthentifizierung fehlgeschlagen | Kennwort und zugehörigen Versuch prüfen | | Kerberos `0x25` | Zeitabweichung zu groß | Zeitquelle und Abweichung prüfen | | sicherer Kanal liefert `False` | Computervertrauen fehlerhaft | DNS, Zeit, Computerkonto und Replikation prüfen | | Vertrauensfehler nur bei einem Computer | Computerkennwort oder Computerkonto | sicheren Kanal kontrolliert reparieren | | Anmeldung funktioniert abhängig vom DC | Replikations- oder DC-Fehler | DC-Ereignisse und `repadmin` auswerten | | Kennwort funktioniert, PIN nicht | Windows-Hello-Problem | Hello-, TPM- und Richtlinienzustand prüfen | | Kennwort funktioniert, Smartcard nicht | PKI- oder Zertifikatsproblem | Zertifikate, KDC und Sperrprüfung untersuchen | | Ereignis 4624 vorhanden, Desktop fehlt | Authentifizierung erfolgreich, Folgephase fehlerhaft | Profil, GPO und Skripte prüfen | | nur RDP schlägt fehl | RDP-Recht, NLA oder Zielsystem | Logon Type 10 und Zielsystem prüfen | | Konto wird sofort erneut gesperrt | gespeichertes altes Kennwort | Quellcomputer und Hintergrundprozesse ermitteln | --- **7.10.33 Ursachen und erforderliche Nachweise** | Mögliche Ursache | Erforderlicher Nachweis | |---|---| | falsches Namensformat | Anmeldung richtet sich nachweislich an falsche Domäne oder lokales Konto | | falsches Kennwort | Ereigniscode und kontrollierter Identitätsabgleich bestätigen die Ursache | | Konto gesperrt | AD-Kontostatus und Ereignis gesper `4740` bestätigen die Sperre | | Konto deaktiviert | `Enabled : False` oder entsprechendes Änderungsereignis | | Konto abgelaufen | Ablaufdatum liegt in der Vergangenheit | | Kennwort abgelaufen | `PasswordExpired` oder Kerberos-Code `0x17` | | falscher DNS-Server | Client verwendet nicht den vorgesehenen AD-DNS-Server | | fehlender SRV-Eintrag | autorisierte DNS-Abfrage liefert den benötigten Eintrag nicht | | falscher DC-Eintrag | SRV- oder A/AAAA-Eintrag verweist auf falschen oder alten DC | | DC nicht erreichbar | protokollspezifischer Test und Netzwerkprotokoll bestätigen Unterbrechung | | falscher AD-Standort | `nltest /dsgetsite` und Subnetzkonfiguration stimmen nicht überein | | VPN vor Anmeldung fehlt | Onlineweg zum DC ist am Anmeldebildschirm nicht vorhanden | | Zeitabweichung | `w32tm` oder Kerberos-Code `0x25` bestätigt die Abweichung | | defekter sicherer Kanal | `Test-ComputerSecureChannel` meldet reproduzierbar `False` | | Computerkonto fehlt | AD-Abfrage bestätigt fehlendes oder falsches Computerkonto | | doppelter Computername | zwei Systeme verwenden nachweislich dieselbe Computeridentität | | AD-Replikationsfehler | `repadmin` oder DC-Protokolle zeigen fehlgeschlagene Replikation | | Kerberos-Verschlüsselungsproblem | Kerberos-Code und Kontokonfiguration bestätigen fehlende gemeinsame Verschlüsselungsart | | Smartcard-Zertifikatsproblem | Zertifikatsprüfung oder PKINIT-Ereignis bestätigt Ursache | | fehlendes Anmelderecht | Ereignis `0xC000015B` und wirksame Richtlinie stimmen überein | | Profilfehler | erfolgreiche Authentifizierung und Profildienstereignis liegen nacheinander vor | | Gruppenrichtlinienfehler | GroupPolicy-Protokoll zeigt konkrete fehlgeschlagene Richtlinienverarbeitung | | gespeichertes altes Kennwort | Ereignisse zeigen wiederholte Fehlversuche von bestimmtem Gerät oder Prozess | --- **7.10.34 Kontrollierte Maßnahmen, Risiko und Rückweg** | Maßnahme | Risiko | Rückweg beziehungsweise Kontrolle | |---|---|---| | richtigen Benutzer oder richtige Domäne auswählen | gering | ursprüngliche Eingabe dokumentieren | | Tastaturlayout korrigieren | Fehleingabe bleibt möglich | kontrollierte Testeingabe ohne Kennwortprotokollierung | | Netzwerk oder Voranmelde-VPN wiederherstellen | anderer Netzwerkweg wird aktiv | vorherigen Netzwerkzustand dokumentieren | | DNS-Konfiguration korrigieren | andere Namensauflösung kann beeinflusst werden | bisherige DNS-Werte sichern | | falschen SRV- oder Hosteintrag korrigieren | viele Clients können betroffen sein | bisherigen Wert und TTL dokumentieren | | Windows-Zeit kontrolliert synchronisieren | Zeitsprung kann Dienste beeinflussen | alte Quelle und Abweichung sichern | | Konto nach Ursachenprüfung entsperren | erneute sofortige Sperre möglich | Sperrquelle vorher ermitteln | | Kennwort nach Identitätsprüfung zurücksetzen | gespeicherte Daten oder Schlüssel können betroffen sein | vorgesehenes Identitätsverfahren verwenden | | sicheren Kanal reparieren | Computervertrauen wird verändert | verwendeten DC und Ausgangsbefund dokumentieren | | Computerkennwort zurücksetzen | Vertrauensbeziehung kann bei Fehler weiter ausfallen | lokale Administrationsmöglichkeit sicherstellen | | Computer neu in Domäne aufnehmen | Neustarts, Profilzuordnung und Verwaltungszustand können betroffen sein | nur als letzte Maßnahme mit Wiederaufnahmeplan | | AD-Replikationsfehler beheben | domänenweite Auswirkungen möglich | DC-spezifischen Änderungsplan verwenden | | GPO korrigieren | viele Benutzer oder Computer betroffen | Version, Sicherung und Zielbereich dokumentieren | | beschädigtes Profil reparieren | Benutzerdaten können verloren gehen | Profil und Daten nach Vorgabe sichern | | gespeicherte alte Anmeldeinformation aktualisieren | Anwendung oder Dienst kann ausfallen | betroffene Abhängigkeit vorher bestimmen | Pro Diagnoseversuch sollte möglichst nur eine relevante Variable verändert werden. --- **7.10.35 Sicheren Kanal kontrolliert reparieren** Eine Reparatur ist nur gerechtfertigt, wenn: - die Domänenmitgliedschaft bestätigt ist; - DNS korrekt funktioniert; - ein geeigneter DC erreichbar ist; - die Zeit ausreichend synchronisiert ist; - das Computerkonto vorhanden ist; - Replikationsprobleme berücksichtigt wurden; - ein autorisiertes lokales Administratorkonto verfügbar ist; - Risiko und Rückweg dokumentiert wurden. Reparatur mit PowerShell: ```powershell $Credential = Get-Credential "\" Test-ComputerSecureChannel ` -Repair ` -Server "" ` -Credential $Credential ` -Verbose ``` Alternativ kann das lokale Computerkennwort kontrolliert zurückgesetzt werden: ```powershell $Credential = Get-Credential "\" Reset-ComputerMachinePassword ` -Server "" ` -Credential $Credential ``` Danach: ```powershell Test-ComputerSecureChannel ` -Server "" ` -Verbose ``` Anschließend sind je nach Verfahren ein Neustart und eine erneute Online-Domänenanmeldung erforderlich. Wichtig: - Zugangsdaten dürfen nicht direkt in Klartext in einen Befehl geschrieben werden. - `nltest /sc_verify`, `nltest /sc_reset` und `nltest /sc_change_pwd` können den Vertrauenszustand verändern. - Auf Domänencontrollern gelten andere Reparaturverfahren. - Das Entfernen und erneute Hinzufügen zur Domäne ist eine letzte Maßnahme. - Eine Domänenneuanmeldung ohne Ursachenanalyse kann das Symptom nur vorübergehend beseitigen. - Bei wiederkehrenden Vertrauensfehlern müssen Snapshot-Verfahren, Klonprozesse, doppelte Computernamen, Replikation und Computerkennwortänderungen untersucht werden. --- **7.10.36 Verifikation** Nach einer Maßnahme müssen mindestens folgende Punkte geprüft werden: - Computer ist weiterhin Mitglied der richtigen Domäne; - Client verwendet die vorgesehenen DNS-Server; - LDAP- und Kerberos-SRV-Einträge werden korrekt aufgelöst; - DC Locator findet einen geeigneten Domänencontroller; - Client ist dem richtigen AD-Standort zugeordnet; - erforderliche AD-Dienste sind erreichbar; - Zeitquelle und Zeitabweichung sind plausibel; - sicherer Kanal liefert ein erfolgreiches Ergebnis; - Benutzerkonto ist aktiviert und nicht gesperrt; - Anmeldung verwendet den richtigen Benutzer und die richtige Domäne; - Anmeldung erfolgt online gegen einen Domänencontroller; - ein Kerberos-TGT kann ausgestellt werden, sofern Kerberos vorgesehen ist; - keine neuen Fehler `4625`, `4771`, `4776`, `3210` oder `5719` entstehen; - Benutzerprofil wird vollständig geladen; - Gruppenrichtlinien werden verarbeitet; - Anmeldeskripte werden abgeschlossen; - benötigte Netzressourcen funktionieren; - RDP funktioniert, wenn es zum ursprünglichen Fehler gehörte; - mehrere repräsentative Benutzer oder Clients funktionieren, wenn der Fehler größeren Umfang hatte; - temporäre Diagnoseänderungen wurden zurückgenommen; - Sicherheitsfunktionen wie NLA, Firewall und Zertifikatsprüfung bleiben aktiv; - Ursache, Maßnahme und Prävention wurden dokumentiert. Eine erfolgreiche lokale oder zwischengespeicherte Anmeldung ist keine ausreichende Verifikation einer reparierten Domänenanmeldung. --- **7.10.37 Präventionsmaßnahmen** - redundante und überwachte Domänencontroller bereitstellen; - DNS-Dienste und AD-SRV-Einträge überwachen; - Clients ausschließlich mit vorgesehenen AD-DNS-Servern konfigurieren; - AD-Standorte und Subnetze vollständig dokumentieren; - VPN mit geeigneter DNS- und Routingkonfiguration bereitstellen; - bei Bedarf einen sicheren Voranmelde-VPN-Weg vorsehen; - Windows-Zeithierarchie überwachen; - PDC-Emulator und externe Zeitquelle dokumentieren; - AD-Replikation kontinuierlich überwachen; - Domänencontrollerereignisse zentral sammeln; - Kontosperren mit Quellcomputer auswerten; - Kennwortänderungen und gespeicherte Anmeldeinformationen berücksichtigen; - Computerobjekte nicht unkontrolliert löschen oder zurücksetzen; - VM-Snapshot- und Wiederherstellungsverfahren mit AD-Vertrauensbeziehungen abstimmen; - Computer nur über standardisierte Verfahren klonen; - doppelte Computernamen verhindern; - sicheren Kanal überwachen, ohne automatische unkontrollierte Reparaturen auszuführen; - lokale Notfalladministration nach Sicherheitsvorgabe gewährleisten; - Gruppenrichtlinien vor breiter Verteilung testen; - Profil-, SYSVOL- und DFSR-Zustand überwachen; - Zertifikatsablauf und Sperrprüfungsdienste bei Smartcard-Anmeldung überwachen; - Windows-Hello-Bereitstellung und Vertrauensmodell dokumentieren; - Sicherheitsprotokolle ausreichend groß dimensionieren; - Uhrzeiten aller Systeme zentral korrelierbar halten; - Runbooks für DNS-, DC-, Replikations- und Vertrauensfehler testen. --- **7.10.38 Typische Fehler bei der Diagnose** - Die Meldung sofort als falsches Kennwort interpretieren. - Lokales Konto und Domänenkonto verwechseln. - UPN, DNS-Domäne und NETBIOS-Domäne gleichsetzen. - PIN und Domänenkennwort gleichsetzen. - Eine Cache-Anmeldung als erfolgreiche Online-Domänenanmeldung werten. - Nur den Domänennamen anpingen. - Einen erfolgreichen Ping als Nachweis der AD-Anmeldung betrachten. - Öffentliche DNS-Server auf einem Domänenclient eintragen. - DNS-Caches löschen, bevor die falsche Antwort dokumentiert wurde. - Nur TCP 389 prüfen und die übrigen AD-Abhängigkeiten ignorieren. - Einen erfolgreichen Test auf TCP 135 als vollständigen RPC-Nachweis betrachten. - UDP mit einem allgemeinen Porttest als sicher funktionsfähig einstufen. - Zeit nur optisch ablesen und die tatsächliche Abweichung nicht messen. - Ein Konto wiederholt testen und dadurch sperren. - Ein gesperrtes Konto entsperren, ohne die Sperrquelle zu ermitteln. - Das Kennwort vorsorglich zurücksetzen. - Gespeicherte alte Kennwörter in Diensten oder Aufgaben ignorieren. - `nltest /sc_verify` als rein lesenden Test verwenden. - Den sicheren Kanal reparieren, bevor DNS und Netzwerk funktionieren. - `Test-ComputerSecureChannel` auf einem DC wie auf einem Mitgliedscomputer interpretieren. - Den Computer sofort aus der Domäne entfernen. - AD-Replikation durch eine erzwungene Synchronisation „reparieren“, ohne den Fehler auszuwerten. - Nur einen Domänencontroller untersuchen. - Den verwendeten DC und Standort nicht dokumentieren. - Ereignis `4625` ohne Status, Substatus und Logon Type interpretieren. - Kerberos-Code `0x19` automatisch als Störung einstufen. - Kerberos-Tickets löschen, bevor sie dokumentiert wurden. - RDP-Fehler nur auf dem lokalen Client untersuchen. - NLA, Firewall oder Zertifikatsprüfung dauerhaft deaktivieren. - Profilfehler mit fehlgeschlagener Kennwortprüfung verwechseln. - Vor der Protokollsicherung neu starten. - Kennwörter oder vollständige Sicherheitsprotokolle ungeschützt weitergeben. - Nach der Maßnahme nur eine lokale oder zwischengespeicherte Anmeldung testen. --- **7.10.39 Typische Prüfungsfragen** **Warum kann eine Domänenanmeldung trotz richtiger Anmeldedaten fehlschlagen?** Die Anmeldung benötigt neben gültigen Anmeldedaten unter anderem Netzwerk, DNS, einen erreichbaren Domänencontroller, ausreichende Zeitsynchronisation, ein gültiges Benutzerkonto und eine funktionierende Computervertrauensstellung. **Warum ist DNS für eine Active-Directory-Anmeldung erforderlich?** Der Client ermittelt Domänencontroller und Kerberos-Dienste über DNS-SRV-Einträge. Eine einfache Auflösung des Domänennamens reicht dafür nicht aus. **Was bedeutet die Meldung, dass keine Anmeldeserver verfügbar sind?** Der Client konnte keinen geeigneten Domänencontroller für die Anmeldeanforderung verwenden. Danach müssen DNS, DC Locator, Netzwerk, benötigte Dienste und der Zustand der Domänencontroller geprüft werden. **Was ist eine zwischengespeicherte Domänenanmeldung?** Windows verwendet lokal gespeicherte Informationen einer früheren erfolgreichen Domänenanmeldung, wenn kein Domänencontroller erreichbar ist. Dabei findet keine vollständige aktuelle Onlineprüfung des Domänenkontos statt. **Was beweist eine erfolgreiche Cache-Anmeldung nicht?** Sie beweist weder die Erreichbarkeit eines Domänencontrollers noch den aktuellen Konto-, Kennwort-, Gruppen- oder Sperrstatus. **Warum kann nach einer Kennwortänderung offline noch das alte Kennwort funktionieren?** Der lokale Computer kann noch den Nachweis der früheren erfolgreichen Domänenanmeldung gespeichert haben. Der Cache wird erst durch eine geeignete erfolgreiche Online-Anmeldung aktualisiert. **Welche Bedeutung besitzt die Uhrzeit bei Kerberos?** Kerberos verwendet Zeitstempel zum Schutz gegen Wiederholungsangriffe. Eine zu große Zeitabweichung zwischen Client und Domänencontroller kann die Authentifizierung verhindern. **Was bedeutet ein Kerberos-Fehler `0x18`?** Die Kerberos-Vorauthentifizierungsinformationen waren ungültig. Häufig wurde ein falsches Kennwort verwendet. Der konkrete Versuch muss mit Benutzer, Client und Zeitpunkt korreliert werden. **Was bedeutet Ereignis `4625`?** Auf dem protokollierenden System ist eine Anmeldung fehlgeschlagen. Status, Substatus, Anmeldetyp, Konto, Quelladresse und Authentifizierungspaket müssen gemeinsam ausgewertet werden. **Was bedeutet Ereignis `4740`?** Ein Benutzerkonto wurde gesperrt. Das Ereignis sollte verwendet werden, um Zeitpunkt und auslösenden Computer beziehungsweise Anmeldeweg zu bestimmen. **Was ist der sichere Kanal eines Domänencomputers?** Es ist die durch das Computerkonto und sein Kennwort abgesicherte Vertrauensbeziehung zwischen Domänenmitglied und Domäne. **Wie wird der sichere Kanal zunächst geprüft?** Auf einem Mitgliedscomputer mit: ```powershell Test-ComputerSecureChannel -Verbose ``` Der Test sollte zuerst ohne `-Repair` ausgeführt werden. **Warum ist `nltest /sc_verify` kein rein lesender Test?** Wenn der sichere Kanal nicht funktioniert, kann der Befehl den bestehenden Kanal entfernen und neu aufbauen. **Warum sollte ein Computer nicht sofort aus der Domäne entfernt werden?** DNS-, Netzwerk-, Zeit- oder Replikationsfehler können die eigentliche Ursache sein. Eine erneute Domänenaufnahme verändert den Systemzustand, benötigt Neustarts und kann weitere Verwaltungs- oder Profilprobleme verursachen. **Warum kann die Anmeldung über einen DC funktionieren und über einen anderen fehlschlagen?** Benutzer-, Kennwort- oder Computerkontoänderungen können wegen eines Replikationsfehlers nicht auf allen Domänencontrollern den gleichen Stand besitzen. **Warum kann die Kennwortanmeldung funktionieren, während die PIN fehlschlägt?** Die Windows-Hello-PIN verwendet einen gerätegebundenen Schlüssel und ist nicht identisch mit dem Domänenkennwort. **Warum kann Ereignis `4624` vorhanden sein, obwohl der Benutzer keinen Desktop erhält?** Die Authentifizierung und Sitzungserstellung können erfolgreich gewesen sein, während Benutzerprofil, Gruppenrichtlinie, Anmeldeskript oder eine benötigte Ressource anschließend fehlschlagen. --- **7.10.40 Checkliste** - [ ] exakte Fehlermeldung dokumentiert - [ ] Benutzer, Computer und Fehlerzeitpunkt erfasst - [ ] lokale, RDP-, VPN-, Smartcard-, PIN- oder Kennwortanmeldung bestimmt - [ ] Fehlerphase bestimmt - [ ] Umfang des Fehlers bestimmt - [ ] richtiger Anmeldeanbieter gewählt - [ ] lokales Konto und Domänenkonto unterschieden - [ ] UPN und `DOMÄNE\Benutzer` geprüft - [ ] Tastaturlayout kontrolliert - [ ] Domänenmitgliedschaft bestätigt - [ ] Online- und Cache-Anmeldung unterschieden - [ ] aktive Netzwerkschnittstelle geprüft - [ ] IP-Adresse, Gateway und VPN geprüft - [ ] verwendete DNS-Server dokumentiert - [ ] LDAP-SRV-Eintrag geprüft - [ ] Kerberos-SRV-Eintrag geprüft - [ ] zurückgegebene DC-Namen aufgelöst - [ ] DC Locator ausgeführt - [ ] AD-Standort geprüft - [ ] geeigneter beschreibbarer DC bei Bedarf ermittelt - [ ] DNS-Funktion gegen vorgesehenen Server geprüft - [ ] Kerberos-Erreichbarkeit geprüft - [ ] LDAP-Erreichbarkeit geprüft - [ ] SMB-Erreichbarkeit geprüft - [ ] RPC und dynamische Ports berücksichtigt - [ ] UDP-Dienste nicht nur durch allgemeinen Porttest bewertet - [ ] Windows-Zeitstatus geprüft - [ ] Zeitquelle geprüft - [ ] Abweichung zum DC gemessen - [ ] Benutzerkonto gefunden - [ ] UPN kontrolliert - [ ] Kontoaktivierung geprüft - [ ] Kontosperre geprüft - [ ] Kontoablauf geprüft - [ ] Kennwortablauf geprüft - [ ] Anmeldezeiten und Arbeitsstationsbeschränkungen berücksichtigt - [ ] Sperrquelle vor Entsperrung untersucht - [ ] Computerkonto geprüft - [ ] sicheren Kanal zunächst nur lesend geprüft - [ ] Kerberos und NTLM unterschieden - [ ] Kerberos-Tickets vor Änderungen dokumentiert - [ ] Clientereignisse ausgewertet - [ ] DC-Ereignisse ausgewertet - [ ] Ereignis `4625` mit Status und Substatus geprüft - [ ] Logon Type ausgewertet - [ ] Kerberos-Ereignisse geprüft - [ ] Ereignis `4740` bei Sperre geprüft - [ ] AD-Replikation bei DC-Abhängigkeit geprüft - [ ] RODC und Kennwortreplikationsrichtlinie berücksichtigt - [ ] RDP und NLA bei Remoteanmeldung berücksichtigt - [ ] Smartcard oder Windows Hello abgegrenzt - [ ] Profil, Gruppenrichtlinie und Anmeldeskript geprüft - [ ] Hypothese und Gegenbeweis formuliert - [ ] Risiko und Rückweg dokumentiert - [ ] nur eine kontrollierte Maßnahme durchgeführt - [ ] Online-Domänenanmeldung verifiziert - [ ] vollständiges Benutzerprofil geladen - [ ] benötigte Netzwerkressourcen geprüft - [ ] keine neuen relevanten Ereignisfehler vorhanden - [ ] temporäre Diagnoseänderungen zurückgenommen - [ ] Ursache und Präventionsmaßnahme dokumentiert --- **7.10.41 Schnellreferenz** | Aufgabe | Befehl | |---|---| | aktuelle Identität | `whoami` | | Benutzer-SID | `whoami /user` | | vollständige Domänenidentität | `whoami /fqdn` | | Gruppen der Sitzung | `whoami /groups` | | Domänenmitgliedschaft | `Get-CimInstance Win32_ComputerSystem` | | Netzwerkkonfiguration | `ipconfig /all` | | DNS-Server | `Get-DnsClientServerAddress` | | LDAP-SRV-Eintrag | `Resolve-DnsName _ldap._tcp.dc._msdcs. -Type SRV` | | Kerberos-SRV-Eintrag | `Resolve-DnsName _kerberos._tcp. -Type SRV` | | DC ermitteln | `nltest /dsgetdc:` | | DC neu ermitteln | `nltest /dsgetdc: /force` | | AD-Standort | `nltest /dsgetsite` | | DC-Liste | `nltest /dclist:` | | DNS-TCP-Test | `Test-NetConnection -Port 53` | | Kerberos-TCP-Test | `Test-NetConnection -Port 88` | | LDAP-TCP-Test | `Test-NetConnection -Port 389` | | SMB-TCP-Test | `Test-NetConnection -Port 445` | | RPC Endpoint Mapper | `Test-NetConnection -Port 135` | | Zeitstatus | `w32tm /query /status` | | Zeitquelle | `w32tm /query /source` | | Zeitvergleich | `w32tm /stripchart /computer: /dataonly /samples:5` | | Benutzerkonto | `Get-ADUser -Properties *` | | gesperrte Konten | `Search-ADAccount -LockedOut -UsersOnly` | | sicherer Kanal, nur Test | `Test-ComputerSecureChannel -Verbose` | | letzter Netlogon-Kanalstatus | `nltest /sc_query:` | | Kerberos-Tickets | `klist tickets` | | Kerberos-TGT | `klist tgt` | | Anmeldefehler | `Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625}` | | DC-Gesundheit | `dcdiag /v` | | DC-DNS-Test | `dcdiag /test:DNS /v` | | Replikationsübersicht | `repadmin /replsummary` | | Replikationsdetails | `repadmin /showrepl` | | Gruppenrichtlinienergebnis | `gpresult /r` | Ändernde Befehle, die nicht als erste Diagnose verwendet werden dürfen: ```text Test-ComputerSecureChannel -Repair Reset-ComputerMachinePassword nltest /sc_verify nltest /sc_reset nltest /sc_change_pwd klist purge w32tm /resync gpupdate /force ``` --- **7.10.42 Quellen** **Offizielle Microsoft-Dokumentation** - [Microsoft Learn – Locating Active Directory domain controllers in Windows and Windows Server](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/dc-locator) - [Microsoft Learn – Troubleshoot domain controller location issues](https://learn.microsoft.com/en-us/troubleshoot/windows-server/windows-security/troubleshoot-domain-controller-location-issues) - [Microsoft Learn – Service overview and network port requirements for Windows](https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/service-overview-and-network-port-requirements) - [Microsoft Learn – Configure a firewall for Active Directory domains and trusts](https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/config-firewall-for-ad-domains-and-trusts) - [Microsoft Learn – Resolve-DnsName](https://learn.microsoft.com/en-us/powershell/module/dnsclient/resolve-dnsname) - [Microsoft Learn – Test-NetConnection](https://learn.microsoft.com/en-us/powershell/module/nettcpip/test-netconnection) - [Microsoft Learn – Nltest](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/cc731935%28v%3Dws.11%29) - [Microsoft Learn – Test-ComputerSecureChannel](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.management/test-computersecurechannel) - [Microsoft Learn – Reset-ComputerMachinePassword](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.management/reset-computermachinepassword) - [Microsoft Learn – Broken trust relationship between a domain-joined device and its domain](https://learn.microsoft.com/en-us/troubleshoot/windows-server/windows-security/broken-trust-relationship-domain-joined-device-its-domain-secure-channel-issues) - [Microsoft Learn – Data collection for troubleshooting secure channel issues](https://learn.microsoft.com/en-us/troubleshoot/windows-server/windows-security/data-collection-for-troubleshooting-secure-channel-issues) - [Microsoft Learn – Secure Channel Problems Detected](https://learn.microsoft.com/en-us/troubleshoot/windows-server/windows-security/secure-channel-problems-detected) - [Microsoft Learn – How the Windows Time Service works](https://learn.microsoft.com/en-us/windows-server/networking/windows-time-service/how-the-windows-time-service-works) - [Microsoft Learn – Maximum tolerance for computer clock synchronization](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/security-policy-settings/maximum-tolerance-for-computer-clock-synchronization) - [Microsoft Learn – Interactive logon: Number of previous logons to cache](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/security-policy-settings/interactive-logon-number-of-previous-logons-to-cache-in-case-domain-controller-is-not-available) - [Microsoft Learn – Cached and Stored Credentials Technical Overview](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/hh994565%28v%3Dws.11%29) - [Microsoft Learn – Klist](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/klist) - [Microsoft Learn – Kerberos authentication troubleshooting guidance](https://learn.microsoft.com/en-us/troubleshoot/windows-server/windows-security/kerberos-authentication-troubleshooting-guidance) - [Microsoft Learn – Get-ADUser](https://learn.microsoft.com/en-us/powershell/module/activedirectory/get-aduser) - [Microsoft Learn – Search-ADAccount](https://learn.microsoft.com/en-us/powershell/module/activedirectory/search-adaccount) - [Microsoft Learn – Get-WinEvent](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.diagnostics/get-winevent) - [Microsoft Learn – Ereignis 4625: An account failed to log on](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-4625) - [Microsoft Learn – Ereignis 4740: A user account was locked out](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-4740) - [Microsoft Learn – Ereignis 4768: A Kerberos authentication ticket was requested](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-4768) - [Microsoft Learn – Ereignis 4769: A Kerberos service ticket was requested](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-4769) - [Microsoft Learn – Ereignis 4771: Kerberos pre-authentication failed](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-4771) - [Microsoft Learn – Ereignis 4776: The computer attempted to validate the credentials for an account](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-4776) - [Microsoft Learn – Dcdiag](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/dcdiag) - [Microsoft Learn – Diagnose Active Directory replication failures](https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/diagnose-replication-failures) - [Microsoft Learn – Verify DNS functionality to support directory replication](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/troubleshoot/verify-dns-functionality-to-support-directory-replication) - [Microsoft Learn – Advanced audit policy configuration settings](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/advanced-audit-policy-configuration) **Standards** - [RFC 4120 – The Kerberos Network Authentication Service](https://datatracker.ietf.org/doc/html/rfc4120) - [RFC 2782 – A DNS RR for specifying the location of services](https://datatracker.ietf.org/doc/html/rfc2782) Für diese Seite wurden keine Community-Berichte, Hersteller-Social-Media-Aussagen oder eigenen Laborergebnisse als Nachweis verwendet. # 7.11 DNS-Leistung und fehlerhafte Reverse-Lookups > **Kurz erklärt** > > Eine DNS-Abfrage kann grundsätzlich funktionieren und trotzdem langsam sein. Ebenso beweist ein fehlender Reverse-Lookup nicht automatisch, dass die normale Namensauflösung gestört ist. > > Für eine saubere Diagnose müssen Abfragerichtung, verwendeter DNS-Server, Antwortcode, Antwortzeit, Cachezustand, Rekursion, Weiterleitung, Transportweg und Zonenverantwortung getrennt untersucht werden. --- **7.11.1 Ziel der Diagnose** Bei DNS-Leistungsproblemen müssen folgende Fragen beantwortet werden: - Ist nur eine Anwendung oder das gesamte System betroffen? - Betrifft der Fehler Vorwärts- oder Rückwärtsauflösungen? - Wird tatsächlich der vorgesehene DNS-Server verwendet? - Antwortet der DNS-Server gar nicht, langsam oder mit einem Fehlercode? - Ist der DNS-Server für die abgefragte Zone autoritativ? - Stammt die Antwort aus einem Client-, Anwendungs- oder Servercache? - Entsteht die Verzögerung lokal, im Netzwerk oder bei einem nachgelagerten DNS-Server? - Existiert die benötigte Reverse-Lookup-Zone? - Ist der PTR-Eintrag vorhanden und korrekt? - Stimmen Vorwärts- und Rückwärtsauflösung überein? - Betrifft der Fehler nur einen DNS-Server oder alle vorgesehenen DNS-Server? - Liegt eine fehlerhafte Delegation, Weiterleitung oder dynamische Aktualisierung vor? - Verwendet die Anwendung klassisches DNS, DoH, DoT oder einen eigenen Resolver? Ziel ist nicht nur eine erfolgreiche Einzelabfrage, sondern eine reproduzierbare und ausreichend schnelle Namensauflösung über den vorgesehenen DNS-Pfad. --- **7.11.2 Typische Störungsbilder** - Anwendungen starten oder verbinden sich mit deutlicher Verzögerung. - Verbindungen über IP-Adresse funktionieren schneller als über den Hostnamen. - Eine Anwendung wartet vor der eigentlichen Anmeldung mehrere Sekunden. - Protokolle zeigen nur IP-Adressen statt Hostnamen. - `nslookup` zeigt als DNS-Server `Unknown` oder `UnKnown`. - Vorwärtsauflösung funktioniert, Rückwärtsauflösung jedoch nicht. - Eine IP-Adresse liefert einen falschen oder veralteten Hostnamen. - Derselbe Name liefert abhängig vom DNS-Server unterschiedliche Antworten. - Die erste Abfrage ist langsam, weitere Abfragen sind schnell. - Abfragen interner Namen funktionieren nur im Firmennetz oder VPN. - Externe Namen sind langsam, interne Namen dagegen schnell. - Nur Abfragen bestimmter Zonen sind betroffen. - Kleine DNS-Antworten funktionieren, größere Antworten schlagen fehl. - Abfragen über UDP schlagen fehl, über TCP funktionieren sie. - Abfragen enden mit `NXDOMAIN`, `SERVFAIL`, `REFUSED` oder einem Timeout. - Mailserver lehnen Verbindungen wegen fehlendem oder unpassendem Reverse-DNS ab. - Überwachungssysteme erzeugen falsche Zuordnungen zwischen IP-Adresse und Hostname. - Nach einer IP-Adressänderung bleibt der alte PTR-Eintrag bestehen. - Neue Geräte erhalten einen A-Eintrag, aber keinen PTR-Eintrag. - Browser und Betriebssystem liefern für denselben Namen unterschiedliche Ergebnisse. - DNS funktioniert ohne VPN, aber nicht über den VPN-Tunnel. - `nslookup` funktioniert, eine Anwendung mit NRPT-Auswertung jedoch nicht – oder umgekehrt. --- **7.11.3 Vorwärts- und Rückwärtsauflösung unterscheiden** | Abfragerichtung | Eingabe | Gesuchter Datensatz | Ergebnis | |---|---|---|---| | Vorwärtsauflösung IPv4 | Hostname | `A` | IPv4-Adresse | | Vorwärtsauflösung IPv6 | Hostname | `AAAA` | IPv6-Adresse | | Rückwärtsauflösung IPv4 | IPv4-Adresse | `PTR` unter `in-addr.arpa` | Hostname | | Rückwärtsauflösung IPv6 | IPv6-Adresse | `PTR` unter `ip6.arpa` | Hostname | Beispiel: ```text host25.example.test → 192.0.2.25 ``` Dies ist eine Vorwärtsauflösung über einen A-Eintrag. ```text 192.0.2.25 → host25.example.test ``` Dies ist eine Rückwärtsauflösung über einen PTR-Eintrag. A-, AAAA- und PTR-Einträge sind getrennte DNS-Datensätze in unterschiedlichen Zonen. Ein vorhandener A- oder AAAA-Eintrag erzeugt deshalb nicht automatisch einen PTR-Eintrag, sofern kein entsprechend konfigurierter Aktualisierungsprozess vorhanden ist. --- **7.11.4 Aufbau einer IPv4-Rückwärtsauflösung** Für IPv4 werden die Oktette der Adresse umgekehrt und mit `in-addr.arpa` ergänzt. Beispiel: ```text 192.0.2.25 ``` Daraus entsteht der Abfragename: ```text 25.2.0.192.in-addr.arpa. ``` Der zugehörige PTR-Eintrag kann auf folgenden Namen zeigen: ```text host25.example.test. ``` Für das Netz `192.0.2.0/24` lautet die typische Reverse-Lookup-Zone: ```text 2.0.192.in-addr.arpa ``` Der Knoten für die Adresse `192.0.2.25` lautet innerhalb dieser Zone: ```text 25 ``` Bei Adressbereichen, die nicht an einer Oktettgrenze delegiert werden, kann eine klassenlose Delegation nach RFC 2317 erforderlich sein. Der Zonenaufbau darf dann nicht allein aus der Subnetzmaske abgeleitet werden, sondern muss mit der tatsächlichen Delegation des Adressbereichs übereinstimmen. --- **7.11.5 Aufbau einer IPv6-Rückwärtsauflösung** IPv6-Rückwärtsauflösungen verwenden die Zone `ip6.arpa`. Dabei wird: 1. die IPv6-Adresse vollständig ausgeschrieben; 2. jede Hexadezimalstelle einzeln betrachtet; 3. die Reihenfolge aller Hexadezimalstellen umgekehrt; 4. zwischen jeder Stelle ein Punkt eingefügt; 5. `ip6.arpa` angehängt. Die Delegation erfolgt auf Basis einzelner Hexadezimalstellen, sogenannter Nibbles. Eine IPv6-Reverse-Zone muss deshalb anhand des tatsächlich delegierten IPv6-Präfixes erstellt werden. IPv6-Reverse-Namen dürfen nicht durch einfaches Umkehren der durch Doppelpunkte getrennten Adressblöcke gebildet werden. --- **7.11.6 Bedeutung eines fehlenden Reverse-Lookups** Ein fehlender PTR-Eintrag bedeutet zunächst nur, dass für die IP-Adresse kein entsprechender Name über Reverse-DNS ermittelt werden konnte. Das beweist nicht automatisch: - dass die Vorwärtsauflösung fehlerhaft ist; - dass der Host nicht erreichbar ist; - dass der Hostname nicht existiert; - dass der DNS-Server vollständig ausgefallen ist; - dass Active Directory nicht funktioniert; - dass die IP-Adresse ungültig ist. Reverse-Lookups werden unter anderem verwendet von: - Diagnosewerkzeugen; - Protokollierungs- und Überwachungssystemen; - Mailservern; - Sicherheitsprodukten; - Inventarisierungsprogrammen; - Netzwerkdiensten mit Hostnamenprüfung; - Anwendungen, die eingehende IP-Adressen in Namen auflösen; - Administratoren bei der Auswertung von Verbindungen. Eine Anwendung kann bei einem fehlenden PTR-Eintrag ohne Verzögerung weiterarbeiten. Eine deutliche Verzögerung entsteht eher dann, wenn die Reverse-Abfrage nicht eindeutig negativ beantwortet wird, sondern in Timeouts, fehlerhaften Delegationen oder nicht erreichbaren DNS-Servern endet. --- **7.11.7 `nslookup` zeigt den DNS-Server als „Unknown“** Eine typische Ausgabe kann folgendermaßen aussehen: ```text Server: UnKnown Address: 192.0.2.53 ``` Das bedeutet häufig, dass für die IP-Adresse des verwendeten DNS-Servers kein auflösbarer PTR-Eintrag vorhanden ist. Diese Meldung beweist nicht, dass der DNS-Server keine anderen Anfragen beantworten kann. Zur Abgrenzung müssen kontrollierte Abfragen durchgeführt werden: ```cmd nslookup host25.example.test 192.0.2.53 ``` ```cmd nslookup 192.0.2.25 192.0.2.53 ``` PTR des DNS-Servers selbst prüfen: ```cmd nslookup 192.0.2.53 192.0.2.53 ``` Wenn die erste Abfrage erfolgreich ist, funktioniert die getestete Vorwärtsauflösung trotz der Anzeige `Unknown`. Der fehlende PTR-Eintrag des DNS-Servers bleibt dennoch ein zu prüfender Konfigurationsbefund. --- **7.11.8 DNS-Antworten richtig einordnen** | Ergebnis | Bedeutung | Einordnung | |---|---|---| | `NOERROR` mit Antwort | Abfrage wurde erfolgreich beantwortet | Datensatz und Inhalt prüfen | | `NOERROR` ohne gesuchten Datensatz | Name kann existieren, der angefragte Datensatztyp fehlt | häufig als `NODATA` bezeichnet | | `NXDOMAIN` | abgefragter DNS-Name existiert laut DNS-Antwort nicht | Zone, Name und negative Zwischenspeicherung prüfen | | `SERVFAIL` | Server konnte keine verwertbare Antwort erzeugen | Weiterleitung, Delegation, DNSSEC und Serverprotokolle prüfen | | `REFUSED` | Server lehnt die Abfrage aufgrund seiner Konfiguration oder Richtlinie ab | Rekursion, ACL, Richtlinie und Abfragequelle prüfen | | `FORMERR` | DNS-Nachricht konnte nicht korrekt verarbeitet werden | Client, Server, Netzwerkgerät und Paketformat prüfen | | Timeout | innerhalb der Wartezeit kam keine verwertbare Antwort | Netzwerk, Transport, Serverlast und nachgelagerte Server prüfen | | Antwort mit `TC` | UDP-Antwort wurde abgeschnitten | erneuter Versuch über TCP erforderlich | | falsche Adresse oder falscher PTR | DNS antwortet, aber mit unerwarteten Daten | Zone, Replikation, Cache und Datensatz prüfen | Ein Timeout ist kein DNS-Antwortcode. Er bedeutet, dass der Client innerhalb seiner Wartezeit keine verwendbare DNS-Antwort erhalten hat. --- **7.11.9 Ausgangszustand dokumentieren** Vor Änderungen sind mindestens folgende Informationen zu erfassen: - betroffener Client; - betroffene Anwendung; - Datum und genaue Uhrzeit; - Quell-IP-Adresse; - verwendete Netzwerkschnittstelle; - VPN-Zustand; - konfigurierte DNS-Server; - DNS-Suffixe und Suchliste; - abgefragter Name beziehungsweise abgefragte IP-Adresse; - Abfragetyp; - verwendeter DNS-Server; - vollständige Antwort; - Antwortcode; - Antwortzeit; - autoritative oder rekursive Antwort; - Verhalten bei Wiederholung; - Verhalten über einen alternativen DNS-Server; - Verhalten bei direkter IP-Verbindung; - vorhandene Client- und Servercaches; - vorhandene PTR-, A-, AAAA-, CNAME- oder SRV-Einträge; - letzte DNS-, DHCP- oder IP-Adressänderung; - verwendeter DNS-Transport. DNS-Caches dürfen nicht gelöscht werden, bevor der ursprüngliche Cachezustand und die fehlerhafte Antwort dokumentiert wurden. --- **7.11.10 Verwendete DNS-Konfiguration prüfen** **Windows** ```cmd ipconfig /all ``` ```powershell Get-DnsClientServerAddress ``` ```powershell Get-DnsClient ``` **Linux** ```bash cat /etc/resolv.conf ``` Bei Systemen mit `systemd-resolved` zusätzlich: ```bash resolvectl status ``` **macOS** ```bash scutil --dns ``` Zu prüfen sind: - welche DNS-Server tatsächlich eingetragen sind; - welche Schnittstelle die DNS-Server bereitstellt; - ob VPN oder Sicherheitssoftware eigene Resolver einbindet; - ob interne DNS-Suffixe vorhanden sind; - ob eine Suchliste zusätzliche Abfragen erzeugt; - ob IPv4- und IPv6-Resolver unterschiedlich konfiguriert sind; - ob Split-DNS oder eine namensbasierte Weiterleitung aktiv ist; - ob öffentliche DNS-Server für interne Unternehmensnamen verwendet werden; - ob die Reihenfolge der DNS-Server dem vorgesehenen Design entspricht. Die Datei `/etc/resolv.conf` kann bei dynamisch verwalteten Linux-Systemen nur auf einen lokalen Stub-Resolver verweisen. Bei `systemd-resolved` muss deshalb zusätzlich dessen tatsächliche Schnittstellenkonfiguration geprüft werden. --- **7.11.11 Lokale Namensquellen und Resolverpfad berücksichtigen** Eine Anwendung muss nicht zwingend direkt den konfigurierten DNS-Server abfragen. Je nach Betriebssystem und Anwendung können vorher oder zusätzlich verwendet werden: - lokale Hosts-Datei; - DNS-Clientcache; - anwendungseigener DNS-Cache; - Browsercache; - lokaler Stub-Resolver; - VPN-Resolver; - Name Resolution Policy Table unter Windows; - mDNS; - LLMNR; - NetBIOS-Namensauflösung; - Proxy; - DNS over HTTPS; - DNS over TLS; - Container- oder Cluster-DNS; - Sicherheits- beziehungsweise Filtersoftware. Hosts-Dateien: | Betriebssystem | Pfad | |---|---| | Windows | `C:\Windows\System32\drivers\etc\hosts` | | Linux | `/etc/hosts` | | macOS | `/etc/hosts` | Eine erfolgreiche Anwendungssuche beweist nicht, dass DNS verwendet wurde. Umgekehrt beweist eine erfolgreiche direkte DNS-Abfrage nicht, dass die Anwendung denselben Resolverpfad benutzt. --- **7.11.12 Split-DNS, VPN und NRPT prüfen** Bei Split-DNS kann derselbe Name abhängig vom verwendeten Netzwerk oder DNS-Server unterschiedliche Antworten liefern. Beispiel: ```text app.example.test → interne IP über Unternehmens-DNS app.example.test → öffentliche IP über öffentlichen DNS ``` Unter Windows können VPN-Profile über die Name Resolution Policy Table festlegen, welche Namensräume an bestimmte DNS-Server gesendet werden. Wirksame NRPT-Richtlinien anzeigen: ```powershell Get-DnsClientNrptPolicy ``` Konfigurierte NRPT-Regeln anzeigen: ```powershell Get-DnsClientNrptRule ``` Zu prüfen sind: - welcher Namensraum von einer Regel erfasst wird; - welcher DNS-Server für diesen Namensraum vorgesehen ist; - ob die Regel nur bei aktivem VPN gilt; - ob eine allgemeinere Regel eine spezifische Regel beeinflusst; - ob interne und öffentliche Zone denselben Namen unterschiedlich beantworten; - ob der VPN-Tunnel die benötigten DNS-Server erreicht; - ob eine Anwendung die Windows-DNS-API verwendet. `nslookup` verwendet für solche Tests nicht zwingend denselben Windows-Resolverpfad wie Anwendungen, die die Windows-DNS-API und NRPT nutzen. Für die Prüfung von NRPT sollte deshalb zusätzlich `Resolve-DnsName` verwendet werden. --- **7.11.13 Verschlüsseltes DNS mit DoH und DoT abgrenzen** DNS over HTTPS und DNS over TLS verändern den Transportweg der DNS-Abfrage. Dadurch können klassische Tests über UDP- oder TCP-Port `53` erfolgreich sein, obwohl der verschlüsselte DNS-Pfad fehlschlägt – oder umgekehrt. Windows-DNS-Clientzustand anzeigen: ```cmd netsh dnsclient show state ``` Globale Einstellungen anzeigen: ```cmd netsh dnsclient show global ``` Konfigurierte verschlüsselte DNS-Server anzeigen: ```cmd netsh dnsclient show encryption ``` Zu prüfen sind: - verwendet das Betriebssystem DoH oder DoT? - verwendet nur der Browser einen eigenen DoH-Resolver? - stimmt die URI beziehungsweise der TLS-Hostname? - ist das Zertifikat gültig und vertrauenswürdig? - stimmt der Zertifikatsname mit dem DNS-Endpunkt überein? - ist der verschlüsselte Port erreichbar? - ist ein Fallback auf unverschlüsseltes DNS erlaubt? - umgeht die Anwendung den Unternehmens-DNS-Server? - kann der verschlüsselte Resolver interne Zonen auflösen? - unterscheiden sich Antworten zwischen klassischem und verschlüsseltem DNS? Für die DNS-Serverrolle unterstützt Microsoft DoH ab Windows Server 2025 mit dem in der Microsoft-Bereitstellungsdokumentation genannten Sicherheitsupdate KB5094125 vom Juni 2026 oder einem späteren Update. Serverkonfiguration auf einem unterstützten System anzeigen: ```powershell Get-DnsServerEncryptionProtocol ``` DoH schützt den Transport zwischen DoH-Client und DNS-Server. Nachgelagerte Abfragen an Forwarder oder autoritative DNS-Server, Zonentransfers und dynamische Updates werden dadurch nicht automatisch verschlüsselt. DoH und DNSSEC erfüllen unterschiedliche Aufgaben: - DoH verschlüsselt den Transportweg. - DNSSEC schützt die Authentizität und Integrität signierter DNS-Daten. --- **7.11.14 Vorwärtsauflösung gezielt testen** **Windows PowerShell** ```powershell Resolve-DnsName ` -Name "host25.example.test" ` -Type A ` -Server "192.0.2.53" ` -DnsOnly ``` AAAA-Eintrag: ```powershell Resolve-DnsName ` -Name "host25.example.test" ` -Type AAAA ` -Server "192.0.2.53" ` -DnsOnly ``` **Windows Eingabeaufforderung** ```cmd nslookup host25.example.test 192.0.2.53 ``` **Linux und macOS** ```bash dig @192.0.2.53 host25.example.test A ``` ```bash dig @192.0.2.53 host25.example.test AAAA ``` Entscheidend ist, den DNS-Server ausdrücklich anzugeben. Andernfalls können unterschiedliche Resolver, VPN-Regeln oder Cachezustände zu nicht vergleichbaren Ergebnissen führen. --- **7.11.15 Rückwärtsauflösung gezielt testen** **Windows PowerShell** ```powershell Resolve-DnsName ` -Name "192.0.2.25" ` -Type PTR ` -Server "192.0.2.53" ` -DnsOnly ``` **Windows Eingabeaufforderung** ```cmd nslookup 192.0.2.25 192.0.2.53 ``` **Linux und macOS** ```bash dig @192.0.2.53 -x 192.0.2.25 ``` Kompakte Ausgabe mit Antwort und Statistik: ```bash dig @192.0.2.53 -x 192.0.2.25 +noall +answer +comments +stats ``` Direkte Abfrage des vollständigen Reverse-Namens: ```bash dig @192.0.2.53 25.2.0.192.in-addr.arpa PTR ``` Zu dokumentieren sind: - Status beziehungsweise Antwortcode; - PTR-Zielname; - TTL; - autoritative Kennzeichnung; - antwortender DNS-Server; - Antwortzeit; - Verhalten bei wiederholter Abfrage. --- **7.11.16 A-, AAAA-, CNAME-, PTR- und SRV-Probleme abgrenzen** | Datensatz | Aufgabe | Typischer Fehler | |---|---|---| | `A` | Name zu IPv4-Adresse | falsche oder veraltete IPv4-Adresse | | `AAAA` | Name zu IPv6-Adresse | falsche oder nicht erreichbare IPv6-Adresse | | `CNAME` | Alias zu anderem DNS-Namen | fehlerhaftes Ziel oder lange Alias-Kette | | `PTR` | IP-Adresse zu Name | fehlender, falscher oder veralteter Reverse-Eintrag | | `SRV` | Dienst zu Zielhost und Port | falsches Ziel, falscher Port oder fehlender Zielhost | CNAME prüfen: ```powershell Resolve-DnsName ` -Name "alias.example.test" ` -Type CNAME ` -Server "192.0.2.53" ` -DnsOnly ``` SRV prüfen: ```powershell Resolve-DnsName ` -Name "_service._tcp.example.test" ` -Type SRV ` -Server "192.0.2.53" ` -DnsOnly ``` Mit `dig`: ```bash dig @192.0.2.53 alias.example.test CNAME ``` ```bash dig @192.0.2.53 _service._tcp.example.test SRV ``` Bei CNAME- und SRV-Datensätzen muss zusätzlich geprüft werden, ob der zurückgegebene Zielname über A oder AAAA auflösbar und anschließend über den angegebenen Dienstport erreichbar ist. Ein erfolgreicher SRV-Lookup beweist nicht, dass der veröffentlichte Dienst erreichbar ist. --- **7.11.17 Antwortzeit reproduzierbar messen** Ein einzelner Messwert reicht nicht aus. Mindestens folgende Fälle müssen getrennt betrachtet werden: - erste Abfrage; - unmittelbar wiederholte Abfrage; - Abfrage eines sicher vorhandenen Namens; - Abfrage eines nicht vorhandenen Namens; - Vorwärtsauflösung; - Rückwärtsauflösung; - interner Name; - externer Name; - primärer DNS-Server; - alternativer DNS-Server; - UDP; - TCP; - mit und ohne VPN. **Linux und macOS** `dig` zeigt die DNS-Abfragezeit als `Query time` an: ```bash dig @192.0.2.53 host25.example.test A +stats ``` TCP erzwingen: ```bash dig @192.0.2.53 host25.example.test A +tcp +stats ``` **Windows PowerShell** ```powershell Measure-Command { Resolve-DnsName ` -Name "host25.example.test" ` -Type A ` -Server "192.0.2.53" ` -DnsOnly } ``` TCP erzwingen: ```powershell Resolve-DnsName ` -Name "host25.example.test" ` -Type A ` -Server "192.0.2.53" ` -DnsOnly ` -TcpOnly ``` `Measure-Command` misst den gesamten PowerShell-Befehlsablauf und nicht ausschließlich die reine DNS-Übertragungszeit. Die Werte eignen sich deshalb vor allem zum kontrollierten Vergleich unter denselben Bedingungen. --- **7.11.18 Kalte und zwischengespeicherte Abfragen unterscheiden** Eine erste rekursive Abfrage kann langsamer sein, weil der DNS-Server weitere Server kontaktieren muss. Eine Wiederholung kann aus einem Cache beantwortet werden. | Beobachtung | Mögliche Einordnung | |---|---| | erste Abfrage langsam, Wiederholung schnell | Server-, Client- oder Anwendungscache wirkt | | jede Abfrage langsam | Netzwerk, Serverlast, Weiterleitung oder autoritativen Pfad prüfen | | nur nicht vorhandene Namen langsam | negative Antworten, fehlerhafte Delegation oder Timeoutpfad prüfen | | nur externe Namen langsam | Rekursion, Forwarder oder Internetpfad prüfen | | nur interne Namen langsam | interne Zone, Delegation, AD-Replikation oder Standort prüfen | | nur Reverse-Lookups langsam | Reverse-Zone, Delegation und PTR-Pfad prüfen | | autoritativer Server schnell, rekursiver Server langsam | Rekursion, Cache oder Forwarder prüfen | | UDP langsam oder fehlerhaft, TCP erfolgreich | Firewall, Fragmentierung, EDNS oder Netzwerkpfad prüfen | Ein schneller Cachetreffer beweist nicht, dass der vollständige rekursive beziehungsweise autoritative Pfad funktioniert. --- **7.11.19 Windows-DNS-Clientcache prüfen** Cacheinhalt anzeigen: ```cmd ipconfig /displaydns ``` Alternativ: ```powershell Get-DnsClientCache ``` Zu prüfen sind: - wurde der betroffene Name bereits zwischengespeichert? - ist die Antwort positiv oder negativ? - ist ein veralteter Wert vorhanden? - stimmt der Datensatztyp? - ist die verbleibende TTL plausibel? - wurde die Antwort durch einen früheren VPN- oder Netzwerkzustand erzeugt? Cache löschen: ```powershell Clear-DnsClientCache ``` Alternativ: ```cmd ipconfig /flushdns ``` Das Löschen des Clientcaches verändert den Ausgangszustand. Es darf erst nach Dokumentation und nur als kontrollierter Vergleich erfolgen. --- **7.11.20 TTL und negative Zwischenspeicherung berücksichtigen** Die TTL bestimmt, wie lange ein Datensatz zwischengespeichert werden darf. Eine sehr niedrige TTL kann: - die Anzahl der DNS-Abfragen erhöhen; - rekursive DNS-Server stärker belasten; - die Abhängigkeit von Netzwerk und autoritativen Servern erhöhen. Eine sehr hohe TTL kann: - veraltete Antworten länger wirksam halten; - geplante Änderungen verzögern; - eine Fehlerkorrektur erst nach Ablauf des Caches sichtbar machen. Auch negative Antworten werden zwischengespeichert. Deshalb kann ein Name nach dem nachträglichen Anlegen des Datensatzes zunächst weiterhin als nicht vorhanden erscheinen. Zu prüfen sind: - TTL des A-, AAAA-, CNAME-, SRV- oder PTR-Eintrags; - SOA-Daten der betroffenen Zone; - negative Cachezeit; - Clientcache; - rekursiver Servercache; - anwendungseigener Cache. Caches dürfen nicht routinemäßig geleert werden, um eine falsche TTL- oder Zonenplanung dauerhaft zu umgehen. --- **7.11.21 DNS über UDP und TCP abgrenzen** Klassische DNS-Abfragen verwenden häufig UDP-Port `53`. TCP-Port `53` wird unter anderem benötigt: - wenn eine UDP-Antwort abgeschnitten wurde; - bei größeren DNS-Antworten; - bei bestimmten DNSSEC-Antworten; - für Zonentransfers; - wenn der Client TCP ausdrücklich verwendet. Windows-TCP-Test: ```powershell Test-NetConnection "192.0.2.53" -Port 53 ``` Dieser Befehl prüft ausschließlich TCP. Er beweist nicht, dass UDP-Port `53` funktioniert. Ein echter UDP-DNS-Test erfolgt durch eine normale DNS-Abfrage: ```powershell Resolve-DnsName ` -Name "host25.example.test" ` -Type A ` -Server "192.0.2.53" ` -DnsOnly ``` Vergleich über TCP: ```powershell Resolve-DnsName ` -Name "host25.example.test" ` -Type A ` -Server "192.0.2.53" ` -DnsOnly ` -TcpOnly ``` Wenn UDP-Abfragen scheitern und TCP-Abfragen funktionieren, sind unter anderem Firewallregeln, Paketverlust, Fragmentierung, EDNS-Verarbeitung, MTU und zwischengeschaltete Netzwerkgeräte zu prüfen. --- **7.11.22 EDNS, MTU, Fragmentierung und DNSSEC prüfen** EDNS ermöglicht unter anderem größere DNS-Antworten über UDP. Auf Netzwerkpfaden mit ungeeigneter MTU oder fehlerhafter Fragmentbehandlung können deshalb kleine Abfragen funktionieren, während größere Antworten ausfallen. Typische Hinweise: - einfache A-Abfrage funktioniert; - DNSKEY-, TXT- oder umfangreiche AAAA-Antwort schlägt fehl; - UDP-Abfrage endet im Timeout; - dieselbe Abfrage funktioniert über TCP; - Problem tritt nur über VPN, Tunnel oder bestimmte Firewalls auf; - `SERVFAIL` tritt nur bei DNSSEC-signierten Zonen auf. DNSSEC-Daten anfordern: ```powershell Resolve-DnsName ` -Name "example.com" ` -Type A ` -Server "192.0.2.53" ` -DnsOnly ` -DnssecOk ``` Mit `dig`: ```bash dig @192.0.2.53 example.com A +dnssec ``` Vergleich über TCP: ```bash dig @192.0.2.53 example.com A +dnssec +tcp ``` EDNS testweise unterdrücken: ```bash dig @192.0.2.53 example.com A +noedns ``` Zu beachten ist: - `+dnssec` beziehungsweise `-DnssecOk` fordert DNSSEC-bezogene Daten an; - das Vorhandensein solcher Daten beweist nicht allein eine erfolgreiche Validierung; - ein `SERVFAIL` kann durch eine fehlerhafte DNSSEC-Vertrauenskette entstehen; - ein erfolgreicher TCP-Test bei fehlerhaftem UDP-Verhalten weist auf den Transportpfad, nicht automatisch auf falsche Zonendaten hin; - EDNS darf nicht dauerhaft deaktiviert werden, nur um einen fehlerhaften Netzwerkpfad zu umgehen. --- **7.11.23 Autoritative Antwort, Rekursion und Weiterleitung unterscheiden** Ein DNS-Server kann eine Antwort liefern: - aus einer lokal gehosteten autoritativen Zone; - aus seinem Cache; - über einen allgemeinen Forwarder; - über einen bedingten Forwarder; - über iterative Rekursion; - über eine Stubzone; - über eine richtliniengesteuerte Rekursionskonfiguration. Für eine saubere Diagnose sind mindestens drei Ebenen zu vergleichen: 1. Abfrage über den vom Client verwendeten DNS-Server; 2. Abfrage über einen alternativen vorgesehenen DNS-Server; 3. Abfrage über den autoritativen DNS-Server der betroffenen Zone. Wenn der autoritative Server schnell und korrekt antwortet, der rekursive Server jedoch langsam ist, liegt die Ursache wahrscheinlich bei Rekursion, Cache, Weiterleitung oder Delegationspfad. --- **7.11.24 Delegation der Reverse-Zone prüfen** Für eine Rückwärtsauflösung muss die DNS-Hierarchie auf den zuständigen autoritativen Server verweisen. **Linux und macOS** ```bash dig -x 192.0.2.25 +trace ``` Zuständige Nameserver der Reverse-Zone prüfen: ```bash dig 2.0.192.in-addr.arpa NS ``` Zu prüfen sind: - existiert die übergeordnete Reverse-Zone? - wurde der richtige Adressbereich delegiert? - stimmen die NS-Einträge? - lassen sich die Nameservernamen auflösen? - sind die autoritativen Server erreichbar? - antworten alle autoritativen Server gleich? - existiert bei klassenlosen IPv4-Netzen eine korrekte RFC-2317-Delegation? - stimmt die IPv6-Nibble-Delegation mit dem zugeteilten Präfix überein? - verweist eine alte Delegation noch auf außer Betrieb genommene Server? Eine lokal erstellte Reverse-Zone ersetzt bei öffentlichen Adressen nicht die Delegation durch den Eigentümer beziehungsweise Provider des IP-Adressbereichs. --- **7.11.25 Private und öffentliche Reverse-Zonen unterscheiden** **Private IP-Adressen** Für interne private Netze kann die Organisation die Reverse-Zonen auf ihren internen DNS-Servern verwalten. Zu prüfen sind: - internes Adresskonzept; - zuständige DNS-Server; - AD-Integrations- und Replikationsbereich; - DHCP-Aktualisierung; - sichere dynamische Updates; - Aging und Scavenging. **Öffentliche IP-Adressen** Der PTR-Eintrag einer öffentlichen IP-Adresse wird normalerweise durch den Betreiber verwaltet, dem der entsprechende Adressbereich delegiert wurde. Ein PTR-Eintrag für eine öffentliche IP-Adresse kann daher nicht allein dadurch veröffentlicht werden, dass in der normalen Forward-Zone der eigenen Domain ein Datensatz angelegt wird. Zu klären sind: - welcher Provider den IP-Adressbereich kontrolliert; - ob der Provider eine Reverse-DNS-Verwaltung anbietet; - welcher Ziel-FQDN eingetragen werden soll; - ob der Zielname vorwärts wieder auf die öffentliche IP-Adresse zeigt; - ob mehrere öffentliche IP-Adressen oder NAT berücksichtigt werden müssen. --- **7.11.26 Vorwärts- und Rückwärtskonsistenz prüfen** Beispiel für einen konsistenten Zustand: ```text host25.example.test. A 192.0.2.25 ``` ```text 25.2.0.192.in-addr.arpa. PTR host25.example.test. ``` Anschließend wird der PTR-Zielname wieder vorwärts aufgelöst: ```text host25.example.test. A 192.0.2.25 ``` Prüfschritte: 1. IP-Adresse rückwärts auflösen. 2. PTR-Zielnamen dokumentieren. 3. PTR-Zielnamen über A und AAAA auflösen. 4. Prüfen, ob die ursprüngliche IP-Adresse in den Ergebnissen enthalten ist. 5. Alle beteiligten autoritativen DNS-Server vergleichen. Mögliche Befunde: | Befund | Einordnung | |---|---| | kein PTR vorhanden | Reverse-Eintrag fehlt oder Zone ist nicht erreichbar | | PTR zeigt auf alten Hostnamen | veralteter Datensatz | | PTR-Zielname existiert nicht | unvollständige DNS-Konfiguration | | PTR-Zielname zeigt auf andere IP | Vorwärts- und Rückwärtsdaten stimmen nicht überein | | mehrere PTR-Einträge | technisch möglich, kann Anwendungen jedoch unterschiedlich beeinflussen | | mehrere A- oder AAAA-Adressen | kann bei Clustern, Load Balancing oder Mehrfachanbindung vorgesehen sein | | verschiedene DNS-Server liefern verschiedene PTR-Werte | Replikation, Zonentransfer oder uneinheitliche Konfiguration prüfen | Eine Vorwärts-Rückwärts-Konsistenz ist nicht für jede DNS-Anwendung zwingend vorgeschrieben. Bestimmte Mail-, Sicherheits- oder Identitätsprüfungen können sie jedoch voraussetzen. --- **7.11.27 Windows-DNS-Serverdienst und Zonen prüfen** Auf dem DNS-Server: ```powershell Get-Service -Name DNS ``` Zonen anzeigen: ```powershell Get-DnsServerZone ``` Nur Reverse-Lookup-Zonen: ```powershell Get-DnsServerZone | Where-Object { $_.IsReverseLookupZone } ``` Zustand einer bestimmten Zone: ```powershell Get-DnsServerZone ` -Name "2.0.192.in-addr.arpa" ``` Zu prüfen sind: - läuft der DNS-Serverdienst? - ist die Zone geladen? - ist die Zone primär, sekundär, Stub- oder AD-integriert? - ist die Zone angehalten? - ist sie für dynamische Updates vorgesehen? - auf welche Server wird sie repliziert? - existieren mehrere widersprüchliche Zonen für denselben Namensraum? - liegt eine veraltete sekundäre Zone vor? - ist die Zone nur auf einem Teil der DNS-Server vorhanden? Ein laufender DNS-Dienst beweist nicht, dass eine bestimmte Zone korrekt geladen oder erreichbar ist. --- **7.11.28 PTR-Datensätze auf dem Windows-DNS-Server prüfen** Alle PTR-Einträge einer Zone: ```powershell Get-DnsServerResourceRecord ` -ZoneName "2.0.192.in-addr.arpa" ` -RRType PTR ``` Bestimmten Eintrag prüfen: ```powershell Get-DnsServerResourceRecord ` -ZoneName "2.0.192.in-addr.arpa" ` -Name "25" ` -RRType PTR ``` Von einem bestimmten DNS-Server lesen: ```powershell Get-DnsServerResourceRecord ` -ComputerName "dns01.example.test" ` -ZoneName "2.0.192.in-addr.arpa" ` -Name "25" ` -RRType PTR ``` Zu vergleichen sind: - Knotenname; - PTR-Zielname; - TTL; - Zeitstempel; - statischer oder dynamischer Datensatz; - Ergebnis auf weiteren DNS-Servern; - zugehöriger A- oder AAAA-Eintrag; - aktuelle IP-Zuweisung. Ein fehlender beziehungsweise als statisch dargestellter Zeitstempel kann auf einen statisch angelegten Datensatz hinweisen. Solche Datensätze werden nicht wie dynamisch gealterte Datensätze behandelt. --- **7.11.29 Rekursion, Forwarder und Cache des Windows-DNS-Servers prüfen** Allgemeine Forwarder: ```powershell Get-DnsServerForwarder ``` Rekursionseinstellungen: ```powershell Get-DnsServerRecursion ``` Root Hints: ```powershell Get-DnsServerRootHint ``` Cacheeinstellungen: ```powershell Get-DnsServerCache ``` Zu prüfen sind: - sind die Forwarder erreichbar? - antworten alle Forwarder zuverlässig? - ist ihre Reihenfolge beziehungsweise Verfügbarkeit plausibel? - ist Rekursion aktiviert, wenn sie benötigt wird? - existiert ein bedingter Forwarder für die betroffene Zone? - verweist der bedingte Forwarder auf aktuelle Server? - sind Root Hints vorgesehen und verwendbar? - sind Cachegrenzen und negative Cachezeit plausibel? - bestehen DNS-Richtlinien oder Rekursionsbereiche? - unterscheiden sich die Einstellungen zwischen DNS-Servern? Nicht erreichbare Forwarder können Verzögerungen verursachen, bevor ein weiterer Forwarder oder ein alternativer Auflösungspfad verwendet wird. --- **7.11.30 DNS-Serverstatistiken auswerten** Aggregierte Statistiken: ```powershell Get-DnsServerStatistics ``` Statistiken einer bestimmten Zone: ```powershell Get-DnsServerStatistics ` -ZoneName "2.0.192.in-addr.arpa" ``` Die genaue Struktur der Ausgabe hängt von der Windows-Server-Version ab. Zu untersuchen sind unter anderem: - empfangene Abfragen; - gesendete Antworten; - Rekursionsvorgänge; - Timeouts; - Serverfehler; - Formatfehler; - abgelehnte Abfragen; - Cacheverhalten; - dynamische Updates; - Paket- und Speicherstatistiken. Statistiken dürfen nicht ohne vorherige Sicherung des Ausgangswerts zurückgesetzt werden. Das Cmdlet kann bei zonenbezogener Verwendung mit `-Clear` Zähler verändern. Diese Option ist deshalb keine rein lesende Diagnosemaßnahme. --- **7.11.31 Leistungsindikatoren überwachen** Verfügbare DNS-Leistungsindikatoren anzeigen: ```powershell Get-Counter -ListSet DNS ``` Beispiel für empfangene DNS-Abfragen und gesendete Antworten: ```powershell Get-Counter ` '\DNS\Total Query Received/sec', '\DNS\Total Response Sent/sec' ` -SampleInterval 2 ` -MaxSamples 10 ``` DNS-Prozess überwachen: ```powershell Get-Counter ` '\Process(dns)\% Processor Time', '\Process(dns)\Working Set' ` -SampleInterval 2 ` -MaxSamples 10 ``` Die Namen der Leistungsindikatoren können auf lokalisierten Windows-Systemen abweichen. Deshalb sollte zuerst `Get-Counter -ListSet DNS` verwendet werden. Zu korrelieren sind: - Abfragen pro Sekunde; - Antworten pro Sekunde; - CPU-Auslastung des DNS-Prozesses; - Arbeitsspeicher; - Netzwerkauslastung; - Timeouts und Fehler; - rekursive Abfragen; - Antwortzeit aus Clientsicht; - Zeitpunkt der Störung. Eine hohe Anzahl von Abfragen ist allein kein Fehler. Entscheidend sind Baseline, Hardware, Abfrageart, Cachetreffer, Rekursion, Fehlerquote und Antwortzeit. --- **7.11.32 Protokollierung kontrolliert einsetzen** Windows DNS Server stellt unter anderem folgende Ereignisprotokolle bereit: ```text Applications and Services Logs └─ Microsoft └─ Windows └─ DNS-Server ├─ Audit └─ Analytical ``` Das Audit-Protokoll erfasst administrative und sicherheitsrelevante DNS-Vorgänge. Das analytische Protokoll kann detaillierte Abfrageinformationen liefern, ist jedoch standardmäßig nicht aktiviert. Zu beachten ist: - analytische Protokollierung nur gezielt aktivieren; - Start- und Endzeit dokumentieren; - ausreichenden Speicherplatz sicherstellen; - Datenschutz und Schutz der DNS-Abfragedaten berücksichtigen; - Protokollierung nach der Diagnose wieder zurücksetzen; - Serverleistung während der Aufzeichnung überwachen; - keine vollständigen internen DNS-Protokolle ungeschützt weitergeben. Microsoft weist darauf hin, dass analytische DNS-Protokollierung bei sehr hohen Abfrageraten messbare Leistungseinflüsse verursachen kann. Deshalb muss sie mit den Leistungswerten des Servers korreliert werden. --- **7.11.33 Netzwerkaufzeichnung gezielt verwenden** Wenn DNS-Abfragen weiterhin unklar bleiben, kann eine zeitlich und inhaltlich begrenzte Netzwerkaufzeichnung erforderlich sein. Zu prüfen sind: - Quell- und Ziel-IP-Adresse; - verwendeter Port; - UDP oder TCP; - DNS-Transaktions-ID; - Abfragetyp; - Antwortcode; - Wiederholungen; - abgeschnittene UDP-Antworten; - anschließender TCP-Versuch; - Paketverlust; - ICMP-Fehlermeldungen; - Verzögerung zwischen Abfrage und Antwort; - Wechsel zu einem weiteren DNS-Server; - EDNS- und DNSSEC-bezogene Größenprobleme; - TLS-Verbindungsaufbau bei DoH oder DoT. DNS-Pakete können interne Hostnamen, Dienstnamen und andere schützenswerte Informationen enthalten. Aufzeichnungen müssen deshalb nach Sicherheits- und Datenschutzvorgaben behandelt werden. --- **7.11.34 Dynamische DNS-Aktualisierung prüfen** Windows-Clients können ihre DNS-Namen dynamisch registrieren: ```powershell Register-DnsClient ``` Alternativ: ```cmd ipconfig /registerdns ``` Diese Befehle lösen eine dynamische Aktualisierung aus und verändern damit möglicherweise den DNS-Zustand. Vorher sind vorhandene Datensätze, Zeitstempel und Ereignisse zu dokumentieren. Zu prüfen sind: - existiert die Forward-Lookup-Zone? - existiert die passende Reverse-Lookup-Zone? - sind dynamische Updates für beide Zonen erlaubt? - werden ausschließlich sichere dynamische Updates verwendet? - soll der Client oder der DHCP-Server den PTR-Eintrag registrieren? - besitzt das aktualisierende Konto die erforderlichen Rechte? - gehört ein vorhandener Datensatz einem anderen Aktualisierungskonto? - existiert ein veralteter statischer Eintrag? - wird die Schnittstelle für DNS-Registrierung verwendet? - stimmen Verbindungssuffix und Zonenname? - sind mehrere aktive Schnittstellen beteiligt? - erscheinen Aktualisierungsfehler in den DNS-, DHCP- oder Clientprotokollen? Das wiederholte Ausführen von `Register-DnsClient` behebt keine fehlende Reverse-Zone, falsche Berechtigungen oder fehlerhafte DHCP-DNS-Einstellungen. --- **7.11.35 DHCP und PTR-Registrierung prüfen** Bei dynamisch vergebenen IP-Adressen kann der DHCP-Server DNS-Einträge im Auftrag des Clients aktualisieren. Zu untersuchen sind: - DHCP-Bereich und aktuelle Lease; - zugeteilte IP-Adresse; - Clientname und FQDN; - DNS-Optionen des DHCP-Bereichs; - Einstellung zur Aktualisierung von A- und PTR-Einträgen; - Verhalten bei Lease-Ablauf und Adressfreigabe; - verwendete DHCP-DNS-Anmeldeinformationen; - Berechtigungen und Eigentümer vorhandener DNS-Datensätze; - mehrere DHCP-Server; - Failover-Konfiguration; - AD-Replikation der DNS-Zone; - DHCP-Serverereignisse zum Zeitpunkt der Aktualisierung. Mögliche Fehlerbilder: - A-Eintrag wird erstellt, PTR-Eintrag jedoch nicht; - neuer PTR-Eintrag wird angelegt, alter PTR bleibt bestehen; - PTR zeigt auf den Namen eines früheren Lease-Nehmers; - ein DHCP-Server kann den Datensatz aktualisieren, ein anderer nicht; - statischer Datensatz verhindert die erwartete Aktualisierung; - die Reverse-Zone existiert nur auf einem Teil der DNS-Server. --- **7.11.36 Aging und Scavenging berücksichtigen** Aging und Scavenging können veraltete dynamische DNS-Datensätze entfernen. Die Funktion beinhaltet Löschvorgänge und muss deshalb kontrolliert geplant werden. Zu prüfen sind: - ist Aging für die Zone aktiviert? - ist Scavenging auf einem geeigneten DNS-Server aktiviert? - wie lang sind No-Refresh- und Refresh-Intervall? - wie lang ist der Scavenging-Zyklus? - besitzt der Datensatz einen dynamischen Zeitstempel? - ist der Datensatz statisch? - wurde die Zone neu erstellt oder die Funktion nachträglich aktiviert? - stimmt die Konfiguration zwischen Forward- und Reverse-Zone? - können aktive Geräte ihre Datensätze rechtzeitig aktualisieren? - passen DHCP-Leasezeit und DNS-Alterungskonzept zusammen? - wurde ein Datensatz bereits als veraltet eingestuft? Scavenging sollte nicht spontan aktiviert oder manuell erzwungen werden, nur weil einzelne PTR-Einträge veraltet sind. Eine falsche Konfiguration kann gültige DNS-Datensätze löschen. --- **7.11.37 Active-Directory-integrierte DNS-Zonen prüfen** Bei AD-integrierten Zonen können unterschiedliche Antworten auf Replikationsprobleme hinweisen. DNS-Test für einen Domänencontroller: ```cmd dcdiag /test:DNS /v /s: ``` Replikationsübersicht: ```cmd repadmin /replsummary ``` Replikationsdetails: ```cmd repadmin /showrepl ``` Zu prüfen sind: - Replikationsbereich der Zone; - vorhandene Verzeichnispartition; - letzte erfolgreiche Replikation; - betroffene Quell- und Ziel-Domänencontroller; - DNS- und RPC-Fehler; - unterschiedliche Datensatzstände; - nur auf einzelnen DCs vorhandene PTR-Einträge; - verzögerte Löschung veralteter Einträge; - Zustand von AD DS und DNS-Serverdienst. Eine erzwungene Replikation ist keine erste Diagnosemaßnahme. Zuerst müssen Richtung, Partner, Fehlercode und Ursache bestimmt werden. --- **7.11.38 Systematischer Diagnoseablauf** 1. **Störungsbild dokumentieren** Client, Anwendung, Name oder IP-Adresse, Uhrzeit und genaue Verzögerung erfassen. 2. **Abfragerichtung bestimmen** Vorwärtsauflösung, Rückwärtsauflösung oder beide unterscheiden. 3. **Umfang bestimmen** Einzelner Client, Anwendung, Standort, Zone oder alle Systeme unterscheiden. 4. **Resolverpfad erfassen** DNS-Server, VPN, Suchsuffixe, Hosts-Datei, NRPT, DoH, DoT und lokale Resolver prüfen. 5. **Abfrage reproduzieren** Den vorgesehenen DNS-Server ausdrücklich angeben. 6. **Antwortcode dokumentieren** `NOERROR`, `NXDOMAIN`, `SERVFAIL`, `REFUSED` oder Timeout unterscheiden. 7. **Antwortzeit messen** Erste und wiederholte Abfrage getrennt messen. 8. **Vorwärts- und Reverse-Abfrage vergleichen** A beziehungsweise AAAA und PTR unabhängig testen. 9. **Alternativen DNS-Server testen** Unterschiedliche Serverantworten dokumentieren. 10. **UDP und TCP vergleichen** Transportabhängige Fehler abgrenzen. 11. **DoH oder DoT abgrenzen** Verschlüsselten und klassischen DNS-Pfad getrennt prüfen. 12. **Autoritativen Server bestimmen** Delegation und zuständige Zone prüfen. 13. **Direkte autoritative Abfrage durchführen** Rekursion und Forwarder vom Zonenzustand trennen. 14. **PTR-Datensatz prüfen** Zielname, TTL, Zeitstempel und Eigentümer auswerten. 15. **Vorwärts-Rückwärts-Konsistenz prüfen** PTR-Zielnamen erneut über A und AAAA auflösen. 16. **Weitere Datensatztypen prüfen** CNAME- oder SRV-Abhängigkeiten berücksichtigen. 17. **Cachezustand prüfen** Client-, Server- und Anwendungscache unterscheiden. 18. **Forwarder und Rekursion prüfen** Besonders bei langsamen externen oder bedingt weitergeleiteten Zonen. 19. **EDNS, MTU und DNSSEC prüfen** Wenn kleine Antworten funktionieren und größere Antworten ausfallen. 20. **Serverleistung prüfen** Abfragerate, CPU, Speicher, Fehler und Timeouts korrelieren. 21. **Dynamische Aktualisierung prüfen** Client, DHCP, Berechtigungen und Zonenrichtlinie untersuchen. 22. **Aging und Scavenging prüfen** Veraltete oder unerwartet gelöschte Datensätze abgrenzen. 23. **AD-Replikation prüfen** Wenn DNS-Server unterschiedliche Antworten liefern. 24. **Hypothese formulieren** Erwarteten Befund und möglichen Gegenbeweis festlegen. 25. **Eine kontrollierte Maßnahme durchführen** Risiko, Rückweg und Erfolgskriterium dokumentieren. 26. **Erneut unter denselben Bedingungen messen** Antwort, Code und Zeit mit dem Ausgangswert vergleichen. 27. **Gesamten DNS-Pfad verifizieren** Client, rekursiven Server, autoritativen Server und Anwendung prüfen. 28. **Präventionsmaßnahme dokumentieren** Ursache und dauerhafte Verbesserung festhalten. --- **7.11.39 Befundmatrix** | Befund | Mögliche Erklärung | Nächster Nachweis | |---|---|---| | `nslookup` zeigt `Unknown`, andere Abfragen funktionieren | PTR des DNS-Servers fehlt | DNS-Server-IP rückwärts abfragen | | Vorwärtsauflösung funktioniert, Reverse nicht | PTR oder Reverse-Zone fehlt | PTR-Abfrage und Zonenprüfung | | Reverse-Abfrage endet sofort mit `NXDOMAIN` | Name oder Zone meldet Nichtvorhandensein | Autorität und SOA der Antwort prüfen | | Reverse-Abfrage läuft in Timeout | Server, Delegation oder Netzwerkpfad antwortet nicht | autoritative Server und Paketpfad prüfen | | PTR zeigt auf alten Hostnamen | veralteter statischer oder dynamischer Eintrag | Lease, Zeitstempel und Datensatzeigentümer prüfen | | PTR-Zielname besitzt keinen A-/AAAA-Eintrag | unvollständige DNS-Konfiguration | Zielnamen vorwärts auflösen | | PTR-Zielname zeigt auf andere IP | Vorwärts-Rückwärts-Abweichung | vorgesehene Mehrfachadressierung prüfen | | erste Abfrage langsam, zweite schnell | Cacheeffekt | kalte und warme Messung vergleichen | | jede externe Abfrage langsam | Forwarder oder Rekursion | direkte Abfragen gegen Forwarder und Autorität | | nur interne Zone langsam | interne Delegation oder AD-DNS | autoritative interne Server vergleichen | | nur ein DNS-Server liefert falsche Antwort | lokaler Cache, Zone oder Replikation | Server direkt vergleichen | | UDP fehlerhaft, TCP erfolgreich | Firewall, EDNS, Fragmentierung oder MTU | Transportvergleich und Netzwerkaufzeichnung | | `SERVFAIL` nur bei signierter Zone | DNSSEC-Validierung oder Delegation | Validierungskette und Serverereignisse prüfen | | `REFUSED` | Rekursion oder Richtlinie verweigert Abfrage | Serverrichtlinie und Quellnetz prüfen | | A-Eintrag vorhanden, PTR fehlt | Reverse-Zone oder Updatepfad fehlt | DHCP-, Client- und Zonenupdate prüfen | | PTR wird nach IP-Wechsel nicht entfernt | Aging, Scavenging oder DHCP-Bereinigung | Leaseablauf, Zeitstempel und Zonenalterung | | unterschiedliche Antworten je DC | AD-Replikation oder uneinheitliche Zone | `repadmin`, `dcdiag` und direkte Abfragen | | Auflösung über IP schnell, über Namen langsam | DNS oder nachgelagerte Namensprüfung | direkte DNS-Zeit und Anwendungspfad vergleichen | | öffentliche IP besitzt keinen PTR | Provider hat keinen Reverse-Eintrag gesetzt | Betreiber des IP-Präfixes ermitteln | | neuer Datensatz bleibt zunächst unsichtbar | positiver oder negativer Cache | TTL und Cacheebenen prüfen | | `nslookup` und Anwendung liefern verschiedene Ergebnisse | NRPT, DoH oder anwendungseigener Resolver | tatsächlichen Resolverpfad bestimmen | | nur große Antworten schlagen fehl | EDNS-, MTU- oder Fragmentierungsproblem | UDP/TCP und Antwortgrößen vergleichen | | SRV wird gefunden, Dienst funktioniert nicht | Zielhost, Port oder Dienst fehlerhaft | SRV-Ziel und Dienstport prüfen | | CNAME wird aufgelöst, Zielname jedoch nicht | fehlerhaftes Aliasziel | CNAME-Kette vollständig prüfen | | klassisches DNS funktioniert, DoH nicht | Zertifikat, HTTPS-Port oder DoH-Endpunkt | DoH-Zustand und TLS-Verbindung prüfen | --- **7.11.40 Ursachen und erforderliche Nachweise** | Mögliche Ursache | Erforderlicher Nachweis | |---|---| | falscher DNS-Server | Clientkonfiguration und direkte Abfragen bestätigen abweichenden Resolver | | falsches DNS-Suffix | Resolverkonfiguration zeigt unerwartete Suchdomäne | | Hosts-Datei überschreibt DNS | lokaler Eintrag liefert abweichende Zuordnung | | anwendungseigener DNS-Cache | Anwendung liefert trotz korrektem Systemtest alten Wert | | NRPT-Fehler | wirksame Richtlinie leitet den Namensraum an falschen Resolver | | fehlerhafter Split-DNS-Pfad | interne und externe Resolver liefern unbeabsichtigt verschiedene Antworten | | DoH- oder DoT-Fehler | verschlüsselter Pfad scheitert bei funktionierendem klassischem DNS | | fehlende Reverse-Zone | zuständiger DNS-Server besitzt oder erreicht die Zone nicht | | fehlender PTR-Eintrag | autoritative PTR-Abfrage liefert keinen Datensatz | | falscher PTR-Eintrag | autoritative Antwort enthält unerwarteten Zielnamen | | fehlerhafte Delegation | übergeordnete Zone verweist auf falsche oder nicht erreichbare Server | | fehlerhafte RFC-2317-Konfiguration | CNAME- und Zonendelegation des Teilnetzes sind unvollständig | | fehlerhafte IPv6-Reverse-Zone | Nibble-Zone stimmt nicht mit dem delegierten Präfix überein | | nicht erreichbarer Forwarder | direkte Abfrage zum Forwarder scheitert reproduzierbar | | langsamer autoritativer Server | direkte autoritative Abfrage zeigt erhöhte Antwortzeit | | UDP-Blockierung | UDP-DNS scheitert, TCP-DNS funktioniert | | TCP-Blockierung | abgeschnittene UDP-Antwort kann nicht über TCP wiederholt werden | | Paketverlust | Aufzeichnung zeigt Wiederholungen oder fehlende Antworten | | MTU- oder Fragmentierungsproblem | große UDP-Antworten scheitern, TCP funktioniert | | DNS-Serverüberlastung | erhöhte Antwortzeit korreliert mit Abfragerate und Ressourcenlast | | ungeeignete TTL | Datensatz- und Cachewerte bestätigen zu kurze oder zu lange Speicherung | | negativer Cache | zuvor negative Antwort bleibt bis zum Ablauf wirksam | | falscher CNAME | Alias verweist auf fehlenden oder falschen Zielnamen | | falscher SRV-Eintrag | Dienstziel, Port, Priorität oder Gewicht sind unzutreffend | | DHCP aktualisiert PTR nicht | DHCP-Ereignis oder Konfiguration bestätigt fehlgeschlagene Aktualisierung | | fehlende Updateberechtigung | DNS- oder DHCP-Protokoll zeigt Zugriffsfehler | | veralteter statischer PTR | statischer Datensatz enthält alten Namen | | fehlerhaftes Scavenging | Konfiguration oder Ereignisse bestätigen unerwartete Löschung | | AD-Replikationsproblem | DNS-Server liefern unterschiedliche autoritative Daten und `repadmin` meldet Fehler | | DNSSEC-Validierungsfehler | `SERVFAIL` und Validierungsdaten bestätigen fehlerhafte Vertrauenskette | | öffentlicher PTR nicht delegiert | Provider beziehungsweise Präfixbetreiber bestätigt fehlende Reverse-Konfiguration | --- **7.11.41 Kontrollierte Maßnahmen, Risiko und Rückweg** | Maßnahme | Risiko | Rückweg beziehungsweise Kontrolle | |---|---|---| | vorgesehenen DNS-Server konfigurieren | andere Namensräume können beeinflusst werden | bisherige DNS-Werte dokumentieren | | falsches DNS-Suffix korrigieren | Suchverhalten verändert sich | ursprüngliche Suffixliste sichern | | fehlerhaften Hosts-Eintrag entfernen | Anwendung verliert lokale Sonderzuordnung | Datei und ursprünglichen Eintrag sichern | | NRPT-Regel korrigieren | VPN-Namensauflösung kann ausfallen | bisherige Regel und Zielserver sichern | | DoH- oder DoT-Konfiguration korrigieren | Transport und Fallbackverhalten ändern sich | bisherigen Verschlüsselungszustand dokumentieren | | fehlende Reverse-Zone anlegen | falscher Adressbereich kann überschrieben werden | Netz-ID und Zuständigkeit vorher bestätigen | | PTR-Eintrag anlegen | falscher Name wird veröffentlicht | IP, FQDN und Forward-Eintrag vorher prüfen | | veralteten PTR korrigieren | bestehende Abhängigkeiten können betroffen sein | alten Wert und Eigentümer dokumentieren | | Forwarder korrigieren | externe und interne Auflösung kann beeinflusst werden | bisherige Forwarderliste sichern | | Delegation korrigieren | gesamter Reverse-Bereich kann betroffen sein | bisherige NS- und CNAME-Daten sichern | | dynamische Updates korrigieren | viele Clients können Datensätze verändern | Zonenrichtlinie und Berechtigungen dokumentieren | | Clientregistrierung auslösen | mehrere A- oder PTR-Einträge können entstehen | vorhandene Einträge vorher erfassen | | Clientcache kontrolliert löschen | ursprünglicher Cachebefund geht verloren | Cacheinhalt vorher dokumentieren | | DNS-Servercache löschen | viele Abfragen müssen erneut rekursiv aufgelöst werden | nur gezielt und mit Lastkontrolle | | TTL ändern | Cacheverhalten vieler Resolver ändert sich | bisherigen Wert und Änderungszeit sichern | | Aging oder Scavenging anpassen | gültige Datensätze können gelöscht werden | Zonenexport und Änderungsplan vorsehen | | AD-Replikationsfehler beheben | mehrere DNS- und AD-Daten können betroffen sein | DC-spezifischen Wiederherstellungsplan verwenden | | analytische Protokollierung aktivieren | Leistung und Datenschutz können betroffen sein | Zeitfenster, Speicherlimit und Abschaltung festlegen | Pro Diagnoseversuch sollte möglichst nur eine relevante Variable verändert werden. --- **7.11.42 Beispiel: Reverse-Zone und PTR-Eintrag anlegen** Die folgenden Befehle sind verändernde Administrationsmaßnahmen und dürfen erst nach Prüfung von Netzbereich, Zonenverantwortung, Replikationsbereich und bestehender Konfiguration ausgeführt werden. AD-integrierte IPv4-Reverse-Zone für das Dokumentationsnetz `192.0.2.0/24`: ```powershell Add-DnsServerPrimaryZone ` -NetworkID "192.0.2.0/24" ` -ReplicationScope "Forest" ``` PTR-Eintrag für `192.0.2.25`: ```powershell Add-DnsServerResourceRecordPtr ` -Name "25" ` -ZoneName "2.0.192.in-addr.arpa" ` -PtrDomainName "host25.example.test." ``` Danach kontrollieren: ```powershell Get-DnsServerResourceRecord ` -ZoneName "2.0.192.in-addr.arpa" ` -Name "25" ` -RRType PTR ``` ```powershell Resolve-DnsName ` -Name "192.0.2.25" ` -Type PTR ` -Server "192.0.2.53" ` -DnsOnly ``` Zusätzlich muss der PTR-Zielname vorwärts geprüft werden: ```powershell Resolve-DnsName ` -Name "host25.example.test" ` -Type A ` -Server "192.0.2.53" ` -DnsOnly ``` Die Beispieladressen und Namen dienen ausschließlich der Dokumentation und müssen durch die tatsächlich autorisierten Werte ersetzt werden. --- **7.11.43 Verifikation** Nach einer Maßnahme sind mindestens folgende Punkte zu prüfen: - Client verwendet die vorgesehenen DNS-Server; - richtige Netzwerkschnittstelle und VPN-Regel sind aktiv; - DNS-Suffixe und Suchliste sind korrekt; - NRPT-Regeln wirken wie vorgesehen; - verwendeter DNS-Transport ist bestimmt; - Vorwärtsauflösung liefert den erwarteten A- beziehungsweise AAAA-Eintrag; - Rückwärtsauflösung liefert den erwarteten PTR-Eintrag; - PTR-Zielname lässt sich vorwärts auflösen; - ursprüngliche IP-Adresse ist in der Vorwärtsantwort enthalten, sofern vorgesehen; - CNAME- und SRV-Ziele sind auflösbar; - alle autoritativen DNS-Server liefern denselben Datensatz; - rekursive DNS-Server liefern konsistente Antworten; - erste und wiederholte Antwortzeit sind plausibel; - UDP- und TCP-Auflösung funktionieren; - DoH oder DoT funktioniert, sofern vorgesehen; - negative Cacheeinträge sind abgelaufen oder kontrolliert entfernt; - Forwarder und bedingte Forwarder antworten; - Reverse-Zone ist korrekt delegiert; - AD-integrierte Zone repliziert fehlerfrei; - dynamische Aktualisierung funktioniert, sofern vorgesehen; - DHCP erzeugt oder entfernt PTR-Einträge korrekt; - Aging und Scavenging löschen keine aktiven Datensätze; - DNSSEC-validierte Zonen verursachen keine neuen Fehler; - keine neuen DNS-, DHCP- oder Replikationsfehler entstehen; - betroffene Anwendung verwendet die korrigierte Auflösung; - temporäre Diagnoseprotokollierung wurde zurückgenommen; - Ursache, Maßnahme und Prävention wurden dokumentiert. Eine einzelne erfolgreiche Cacheabfrage ist keine ausreichende Verifikation des vollständigen DNS-Pfads. --- **7.11.44 Präventionsmaßnahmen** - Forward- und Reverse-Zonen gemeinsam planen; - Zuständigkeiten für private und öffentliche Reverse-Zonen dokumentieren; - PTR-Einträge für wichtige Server und Infrastrukturkomponenten pflegen; - DNS-Server selbst mit korrekten PTR-Einträgen versehen; - Vorwärts- und Rückwärtskonsistenz regelmäßig prüfen; - DNS-Server redundant bereitstellen; - autoritative und rekursive Rollen dokumentieren; - Forwarder und bedingte Forwarder überwachen; - Reverse-Delegationen regelmäßig kontrollieren; - klassenlose IPv4-Delegationen eindeutig dokumentieren; - IPv6-Reverse-Zonen anhand der delegierten Präfixe planen; - DNS-Antwortzeiten und Fehlerquoten als Baseline erfassen; - Abfrageraten, CPU, Speicher und Netzwerk überwachen; - UDP- und TCP-Port `53` in Firewallkonzepten berücksichtigen; - DoH-, DoT-, DNSSEC- und EDNS-Verhalten bei Netzwerkänderungen testen; - MTU und Fragmentierung auf VPN- und Tunnelpfaden berücksichtigen; - TTL-Werte an Änderungs- und Lastanforderungen anpassen; - negative Cachezeiten berücksichtigen; - DHCP- und DNS-Aktualisierungsverantwortung eindeutig festlegen; - abgesicherte Aktualisierungsverfahren verwenden; - Aging und Scavenging zuerst in kontrolliertem Umfang testen; - AD-Replikation überwachen; - Zonenänderungen protokollieren; - veraltete statische Einträge regelmäßig prüfen; - VPN-, Split-DNS-, NRPT- und DoH-Konfigurationen dokumentieren; - Anwendungen mit eigenem DNS-Verhalten erfassen; - Runbooks für langsame DNS-Abfragen und fehlerhafte PTR-Einträge testen. --- **7.11.45 Typische Fehler bei der Diagnose** - `Unknown` in `nslookup` sofort als vollständigen DNS-Ausfall bewerten. - Vorwärts- und Rückwärtsauflösung gleichsetzen. - Einen vorhandenen A-Eintrag als Beweis für einen PTR-Eintrag betrachten. - Einen fehlenden PTR-Eintrag automatisch als Verbindungsursache einstufen. - Die Antwortzeit nicht messen. - Nur eine einzelne Abfrage durchführen. - Cachetreffer und vollständige Rekursion nicht unterscheiden. - Den verwendeten DNS-Server nicht ausdrücklich angeben. - Anwendungsergebnis und direkte DNS-Abfrage gleichsetzen. - Hosts-Datei, VPN, NRPT, DoH oder Anwendungscache ignorieren. - `nslookup` als vollständigen Test einer NRPT-Regel verwenden. - `Test-NetConnection -Port 53` als UDP-DNS-Test verwenden. - Nur UDP oder nur TCP prüfen. - `NXDOMAIN`, `SERVFAIL` und Timeout gleich behandeln. - Eine negative Antwort mit einer ausgebliebenen Antwort verwechseln. - DNS-Caches vor der Dokumentation löschen. - Den DNS-Servercache routinemäßig leeren. - Forwarder ändern, ohne die ursprüngliche Konfiguration zu sichern. - Nur einen autoritativen DNS-Server prüfen. - Die Reverse-Delegation nicht untersuchen. - Bei öffentlichen IP-Adressen selbst eine nicht delegierte Reverse-Zone veröffentlichen wollen. - IPv4-Oktette falsch anordnen. - IPv6-Blöcke statt einzelner Nibbles umkehren. - RFC-2317-Delegationen bei kleineren IPv4-Netzen ignorieren. - PTR-Zielnamen nicht wieder vorwärts auflösen. - Mehrere PTR- oder A-Einträge ohne Kenntnis des Systemdesigns löschen. - CNAME-Ziele nicht bis zum endgültigen A- oder AAAA-Eintrag verfolgen. - Einen erfolgreichen SRV-Lookup mit einem erreichbaren Dienst gleichsetzen. - Große DNS-Antworten und Fragmentierung nicht berücksichtigen. - DNSSEC bei `SERVFAIL` nicht prüfen. - DoH und DNSSEC gleichsetzen. - Dynamische Registrierung wiederholt auslösen, ohne Berechtigungen zu prüfen. - Scavenging spontan aktivieren. - Veraltete statische Einträge mit dynamischen Einträgen gleichsetzen. - AD-Replikationsprobleme durch manuelle Datensatzänderungen verdecken. - Analytische DNS-Protokollierung unbegrenzt eingeschaltet lassen. - DNS-Protokolle mit internen Namen ungeschützt weitergeben. - Nach der Änderung nur den Cache und nicht den vollständigen DNS-Pfad testen. --- **7.11.46 Checkliste** - [ ] betroffenes System und Anwendung dokumentiert - [ ] genauer Fehlerzeitpunkt erfasst - [ ] Vorwärts- oder Rückwärtsauflösung bestimmt - [ ] Umfang der Störung bestimmt - [ ] verwendete Netzwerkschnittstelle geprüft - [ ] VPN-Zustand dokumentiert - [ ] konfigurierte DNS-Server erfasst - [ ] DNS-Suffixe und Suchliste geprüft - [ ] Hosts-Datei berücksichtigt - [ ] NRPT geprüft - [ ] Split-DNS berücksichtigt - [ ] DoH, DoT und Anwendungscache berücksichtigt - [ ] betroffener Name oder IP-Adresse dokumentiert - [ ] Abfragetyp bestimmt - [ ] DNS-Server bei Test ausdrücklich angegeben - [ ] vollständige Antwort dokumentiert - [ ] Antwortcode ausgewertet - [ ] Timeout von DNS-Fehlercode unterschieden - [ ] erste Antwortzeit gemessen - [ ] wiederholte Antwortzeit gemessen - [ ] positiver Cache geprüft - [ ] negativer Cache geprüft - [ ] TTL dokumentiert - [ ] Vorwärtsauflösung getestet - [ ] IPv4-Rückwärtsauflösung getestet - [ ] IPv6-Rückwärtsauflösung bei Bedarf getestet - [ ] PTR-Zielname dokumentiert - [ ] PTR-Zielname vorwärts aufgelöst - [ ] Vorwärts-Rückwärts-Konsistenz geprüft - [ ] CNAME-Kette bei Bedarf geprüft - [ ] SRV-Ziel und Dienstport bei Bedarf geprüft - [ ] primärer DNS-Server getestet - [ ] alternativer DNS-Server getestet - [ ] autoritativer DNS-Server bestimmt - [ ] direkte autoritative Abfrage durchgeführt - [ ] Reverse-Delegation geprüft - [ ] RFC-2317-Konfiguration bei Teilnetzen berücksichtigt - [ ] öffentliche oder private IP-Adresse unterschieden - [ ] UDP-DNS getestet - [ ] TCP-DNS getestet - [ ] größere DNS-Antwort getestet - [ ] EDNS und MTU berücksichtigt - [ ] DNSSEC bei `SERVFAIL` berücksichtigt - [ ] verschlüsselter DNS-Pfad bei Bedarf getestet - [ ] Forwarder geprüft - [ ] bedingte Forwarder geprüft - [ ] Rekursion geprüft - [ ] DNS-Serverdienst geprüft - [ ] Reverse-Zone auf dem Server geprüft - [ ] PTR-Datensatz direkt geprüft - [ ] Zeitstempel und statischer Zustand geprüft - [ ] Serverstatistiken ausgewertet - [ ] Abfragerate und Serverlast korreliert - [ ] DNS-Ereignisse ausgewertet - [ ] dynamische Aktualisierung geprüft - [ ] DHCP-Aktualisierung geprüft - [ ] Berechtigungen und Datensatzeigentümer geprüft - [ ] Aging und Scavenging geprüft - [ ] AD-Replikation bei unterschiedlichen Antworten geprüft - [ ] Hypothese und Gegenbeweis formuliert - [ ] Risiko und Rückweg dokumentiert - [ ] nur eine kontrollierte Maßnahme durchgeführt - [ ] Antwortcode nach der Maßnahme geprüft - [ ] Antwortzeit nach der Maßnahme geprüft - [ ] vollständiger DNS-Pfad verifiziert - [ ] Anwendung erneut getestet - [ ] temporäre Diagnoseänderungen zurückgenommen - [ ] Ursache und Präventionsmaßnahme dokumentiert --- **7.11.47 Schnellreferenz** | Aufgabe | Befehl | |---|---| | Windows-Netzwerk- und DNS-Konfiguration | `ipconfig /all` | | Windows-DNS-Serveradressen | `Get-DnsClientServerAddress` | | Windows-DNS-Clientzustand | `Get-DnsClient` | | Linux-Resolverzustand | `resolvectl status` | | macOS-Resolverzustand | `scutil --dns` | | wirksame NRPT-Richtlinie | `Get-DnsClientNrptPolicy` | | konfigurierte NRPT-Regeln | `Get-DnsClientNrptRule` | | DoH-/DoT-Clientzustand | `netsh dnsclient show state` | | verschlüsselte DNS-Server | `netsh dnsclient show encryption` | | Vorwärtsauflösung IPv4 | `Resolve-DnsName -Type A -Server -DnsOnly` | | Vorwärtsauflösung IPv6 | `Resolve-DnsName -Type AAAA -Server -DnsOnly` | | Rückwärtsauflösung | `Resolve-DnsName -Type PTR -Server -DnsOnly` | | Rückwärtsauflösung mit `dig` | `dig @ -x ` | | CNAME prüfen | `Resolve-DnsName -Type CNAME -Server -DnsOnly` | | SRV prüfen | `Resolve-DnsName -Type SRV -Server -DnsOnly` | | TCP-DNS-Abfrage | `Resolve-DnsName -Server -TcpOnly -DnsOnly` | | TCP-Port 53 prüfen | `Test-NetConnection -Port 53` | | DNSSEC-Daten anfordern | `Resolve-DnsName -Server -DnssecOk` | | Clientcache anzeigen | `Get-DnsClientCache` | | Clientcache löschen | `Clear-DnsClientCache` | | DNS-Serverdienst | `Get-Service DNS` | | DNS-Zonen | `Get-DnsServerZone` | | PTR-Einträge | `Get-DnsServerResourceRecord -ZoneName -RRType PTR` | | Forwarder | `Get-DnsServerForwarder` | | Rekursion | `Get-DnsServerRecursion` | | Cacheeinstellungen | `Get-DnsServerCache` | | Serverstatistiken | `Get-DnsServerStatistics` | | Leistungsindikatoren | `Get-Counter -ListSet DNS` | | DoH-Serverkonfiguration | `Get-DnsServerEncryptionProtocol` | | Clientregistrierung | `Register-DnsClient` | | AD-DNS-Test | `dcdiag /test:DNS /v` | | AD-Replikation | `repadmin /replsummary` | Ändernde Befehle, die nicht als erste Diagnose verwendet werden dürfen: ```text Clear-DnsClientCache Clear-DnsServerCache Register-DnsClient ipconfig /flushdns ipconfig /registerdns Add-DnsServerPrimaryZone Add-DnsServerResourceRecordPtr Set-DnsServerForwarder Set-DnsServerRecursion Set-DnsServerCache Set-DnsServerZoneAging Start-DnsServerScavenging Set-DnsServerEncryptionProtocol Remove-DnsServerResourceRecord ``` --- **7.11.48 Quellen** **Offizielle Microsoft-Dokumentation** - [Microsoft Learn – Guidance for troubleshooting DNS](https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/troubleshoot-dns-guidance) - [Microsoft Learn – Troubleshoot DNS servers](https://learn.microsoft.com/en-us/windows-server/networking/dns/troubleshoot/troubleshoot-dns-server) - [Microsoft Learn – Troubleshoot DNS client name resolution issues](https://learn.microsoft.com/en-us/troubleshoot/windows-client/networking/troubleshoot-dns-client-resolution-issues) - [Microsoft Learn – DNS queries and lookups](https://learn.microsoft.com/en-us/windows-server/networking/dns/queries-lookups) - [Microsoft Learn – DNS architecture](https://learn.microsoft.com/en-us/windows-server/networking/dns/dns-architecture) - [Microsoft Learn – Manage DNS zones](https://learn.microsoft.com/en-us/windows-server/networking/dns/manage-dns-zones) - [Microsoft Learn – Manage DNS resource records](https://learn.microsoft.com/en-us/windows-server/networking/dns/manage-resource-records) - [Microsoft Learn – Dynamic DNS Update in Windows and Windows Server](https://learn.microsoft.com/en-us/windows-server/networking/dns/dynamic-update) - [Microsoft Learn – DNS scavenging setup](https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/dns-scavenging-setup) - [Microsoft Learn – Troubleshoot DNS scavenging issues](https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/troubleshoot-dns-scavenging-issues) - [Microsoft Learn – Forwarders and conditional forwarders resolution timeouts](https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/forwarders-resolution-timeouts) - [Microsoft Learn – Enable DNS logging and diagnostics](https://learn.microsoft.com/en-us/windows-server/networking/dns/dns-logging-and-diagnostics) - [Microsoft Learn – DNS encryption using DNS over HTTPS](https://learn.microsoft.com/en-us/windows-server/networking/dns/dns-encryption-dns-over-https) - [Microsoft Learn – Enable DNS over HTTPS in DNS Server](https://learn.microsoft.com/en-us/windows-server/networking/dns/enable-dns-over-https-server) - [Microsoft Learn – Troubleshoot DNS over HTTPS in DNS Server](https://learn.microsoft.com/en-us/windows-server/networking/dns/troubleshoot-dns-over-https-server) - [Microsoft Learn – Secure DNS Client over HTTPS](https://learn.microsoft.com/en-us/windows-server/networking/dns/doh-client-support) - [Microsoft Learn – netsh dnsclient](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/netsh-dnsclient) - [Microsoft Learn – Resolve-DnsName](https://learn.microsoft.com/en-us/powershell/module/dnsclient/resolve-dnsname) - [Microsoft Learn – DnsClient PowerShell module](https://learn.microsoft.com/en-us/powershell/module/dnsclient/) - [Microsoft Learn – Clear-DnsClientCache](https://learn.microsoft.com/en-us/powershell/module/dnsclient/clear-dnsclientcache) - [Microsoft Learn – Register-DnsClient](https://learn.microsoft.com/en-us/powershell/module/dnsclient/register-dnsclient) - [Microsoft Learn – Get-DnsServerZone](https://learn.microsoft.com/en-us/powershell/module/dnsserver/get-dnsserverzone) - [Microsoft Learn – Get-DnsServerResourceRecord](https://learn.microsoft.com/en-us/powershell/module/dnsserver/get-dnsserverresourcerecord) - [Microsoft Learn – Add-DnsServerPrimaryZone](https://learn.microsoft.com/en-us/powershell/module/dnsserver/add-dnsserverprimaryzone) - [Microsoft Learn – Add-DnsServerResourceRecordPtr](https://learn.microsoft.com/en-us/powershell/module/dnsserver/add-dnsserverresourcerecordptr) - [Microsoft Learn – Get-DnsServerStatistics](https://learn.microsoft.com/en-us/powershell/module/dnsserver/get-dnsserverstatistics) - [Microsoft Learn – Get-DnsServerCache](https://learn.microsoft.com/en-us/powershell/module/dnsserver/get-dnsservercache) - [Microsoft Learn – Clear-DnsServerCache](https://learn.microsoft.com/en-us/powershell/module/dnsserver/clear-dnsservercache) - [Microsoft Learn – Set-DnsServerEncryptionProtocol](https://learn.microsoft.com/en-us/powershell/module/dnsserver/set-dnsserverencryptionprotocol) - [Microsoft Learn – DnsServer PowerShell module](https://learn.microsoft.com/en-us/powershell/module/dnsserver/) - [Microsoft Learn – Verify that SRV DNS records have been created](https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/verify-srv-dns-records-have-been-created) - [Microsoft Learn – Dcdiag](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/dcdiag) - [Microsoft Learn – Diagnose Active Directory replication failures](https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/diagnose-replication-failures) **Standards** - [RFC 1034 – Domain Names: Concepts and Facilities](https://datatracker.ietf.org/doc/html/rfc1034) - [RFC 1035 – Domain Names: Implementation and Specification](https://datatracker.ietf.org/doc/html/rfc1035) - [RFC 2308 – Negative Caching of DNS Queries](https://datatracker.ietf.org/doc/html/rfc2308) - [RFC 2317 – Classless IN-ADDR.ARPA Delegation](https://datatracker.ietf.org/doc/html/rfc2317) - [RFC 3596 – DNS Extensions to Support IPv6](https://datatracker.ietf.org/doc/html/rfc3596) - [RFC 7858 – Specification for DNS over Transport Layer Security](https://datatracker.ietf.org/doc/html/rfc7858) - [RFC 8484 – DNS Queries over HTTPS](https://datatracker.ietf.org/doc/html/rfc8484) - [RFC 8499 – DNS Terminology](https://datatracker.ietf.org/doc/html/rfc8499) Für diese Seite wurden keine Community-Berichte, Hersteller-Social-Media-Aussagen oder eigenen Laborergebnisse als Nachweis verwendet. # 7.12 Systematischer DNS-Diagnoseablauf > **Kurz erklärt** > > DNS-Störungen dürfen nicht durch wahlloses Leeren von Caches, Ändern von DNS-Servern oder Neuerstellen von Einträgen diagnostiziert werden. > > Der sichere Ablauf beginnt beim exakten Fehlerbild und verfolgt die Namensauflösung schrittweise vom Client über den verwendeten Resolver, den Transportweg und rekursive DNS-Server bis zum autoritativen Server und den tatsächlichen Zonendaten. --- **7.12.1 Ziel des Diagnoseablaufs** Der Diagnoseablauf soll eindeutig bestimmen: - welcher Name oder welche IP-Adresse betroffen ist; - welcher Datensatztyp benötigt wird; - welcher Client und welche Anwendung betroffen sind; - welcher Resolverweg tatsächlich verwendet wird; - welcher DNS-Server die Anfrage erhält; - ob eine Antwort eintrifft; - welcher Antwortcode zurückgegeben wird; - ob die Antwort korrekt und aktuell ist; - ob die Antwort aus einem Cache oder einer autoritativen Zone stammt; - an welcher Stelle eine Verzögerung oder ein Fehler entsteht; - welche einzelne Maßnahme die nachgewiesene Ursache behebt; - wie die vollständige Funktion anschließend verifiziert wird. DNS-Diagnose bedeutet nicht nur, irgendeine erfolgreiche Antwort zu erhalten. Die Antwort muss vom vorgesehenen DNS-Pfad stammen, fachlich korrekt sein und innerhalb einer angemessenen Zeit eintreffen. --- **7.12.2 Grundregeln** 1. Zuerst beobachten und dokumentieren. 2. Den exakten Namen und Datensatztyp verwenden. 3. Clientverhalten und direkte DNS-Abfrage unterscheiden. 4. Den tatsächlich verwendeten DNS-Server bestimmen. 5. Antwortcode und Antwortinhalt getrennt bewerten. 6. Positive, negative und ausgebliebene Antworten unterscheiden. 7. Cache-, rekursive und autoritative Antworten trennen. 8. UDP, TCP, DoH und DoT nicht gleichsetzen. 9. Pro Versuch nur eine relevante Variable verändern. 10. Vor jeder Änderung Risiko und Rückweg dokumentieren. 11. Nach der Maßnahme denselben Test wiederholen. 12. Erst nach technischer Verifikation den Vorgang abschließen. Folgende Maßnahmen sind keine geeigneten ersten Diagnoseschritte: - DNS-Cache sofort löschen; - öffentlichen DNS-Server eintragen; - DNS-Dienst neu starten; - Zone neu erstellen; - DNS-Einträge vorsorglich löschen; - Forwarder verändern; - Scavenging aktivieren; - Client erneut in die Domäne aufnehmen; - Firewall oder DNSSEC deaktivieren; - VPN-, NRPT- oder DoH-Richtlinien entfernen. --- **7.12.3 Fehleraufnahme** Vor dem ersten Test sind mindestens folgende Angaben zu erfassen: | Angabe | Beispiel | |---|---| | Zeitpunkt | `2026-08-02 14:35:20` | | Client | `client25.example.test` | | Benutzer beziehungsweise Dienst | betroffene Sitzung oder Dienstkonto | | Anwendung | Browser, RDP, Mail, Dateifreigabe, AD-Anmeldung | | eingegebener Name | `app.example.test` | | erwarteter FQDN | `app.example.test.` | | erwarteter Datensatztyp | A, AAAA, CNAME, PTR, SRV, MX oder TXT | | erwartetes Ergebnis | vorgesehene IP-Adresse oder Zielname | | tatsächliches Ergebnis | Fehlertext oder falsche Antwort | | verwendetes Netzwerk | LAN, WLAN, VPN oder Mobilfunk | | Quell-IP-Adresse | aktive Clientadresse | | konfigurierte DNS-Server | Reihenfolge und Schnittstelle | | Fehlerumfang | einzelner Client, Standort, Zone oder alle Systeme | | letzte Änderung | DNS, DHCP, VPN, Firewall, Server, Zertifikat oder Netzwerk | Kennwörter, Zugangsdaten und unnötige personenbezogene Daten dürfen nicht in die Fehlerdokumentation übernommen werden. --- **7.12.4 Störung einordnen** | Fehlerklasse | Typisches Symptom | |---|---| | vollständiger Ausfall | keine DNS-Abfrage funktioniert | | namensbezogener Fehler | nur ein bestimmter Name schlägt fehl | | zonenbezogener Fehler | alle Namen einer Zone schlagen fehl | | datensatzbezogener Fehler | A funktioniert, SRV oder PTR jedoch nicht | | resolverbezogener Fehler | nur ein bestimmter DNS-Server liefert Fehler | | clientbezogener Fehler | derselbe Name funktioniert an anderen Clients | | anwendungsbezogener Fehler | direkte DNS-Abfrage funktioniert, Anwendung nicht | | standortbezogener Fehler | Fehler tritt nur in einem Netz oder VPN auf | | zeitabhängiger Fehler | Fehler tritt nur zeitweise auf | | leistungsbezogener Fehler | Antwort ist korrekt, aber zu langsam | | datenbezogener Fehler | DNS liefert eine falsche oder veraltete Antwort | | transportbezogener Fehler | UDP, TCP, DoH oder DoT verhalten sich unterschiedlich | | validierungsbezogener Fehler | DNSSEC führt zu `SERVFAIL` oder Validierungsfehler | | reversebezogener Fehler | IP-Adresse lässt sich nicht korrekt in einen Namen auflösen | Diese Einordnung bestimmt, welche Vergleichstests aussagekräftig sind. --- **7.12.5 Geeignete Testdaten festlegen** Für reproduzierbare Tests müssen folgende Werte feststehen: - exakter FQDN; - gewünschter Datensatztyp; - erwarteter Wert; - vorgesehener DNS-Server; - autoritativer DNS-Server; - Vergleichsname, der sicher funktioniert; - Vergleichsname, der sicher nicht existiert; - vorgesehene Antwortzeit oder vorhandene Baseline. Ein kurzer Name wie: ```text server01 ``` ist für eine eindeutige DNS-Diagnose ungeeignet, solange nicht feststeht, welches DNS-Suffix ergänzt wird. Besser: ```text server01.example.test. ``` Der abschließende Punkt kennzeichnet einen vollständig qualifizierten absoluten DNS-Namen. Viele Werkzeuge funktionieren auch ohne diesen Punkt, können dann jedoch abhängig von Suchsuffixen zusätzliche Namen prüfen. --- **7.12.6 DNS-Auflösung als Kette betrachten** Eine Namensauflösung kann folgende Stationen durchlaufen: | Station | Aufgabe | |---|---| | Anwendung | fordert eine Namensauflösung an oder verwendet eigenen Resolver | | lokale Namensquelle | Hosts-Datei oder anwendungseigener Cache | | Betriebssystemresolver | wertet Cache, Suffixe, Richtlinien und DNS-Server aus | | lokaler Stub-Resolver | nimmt Anfragen lokal entgegen und leitet sie weiter | | VPN-, Container- oder Sicherheitsresolver | beeinflusst den Abfrageweg | | rekursiver DNS-Server | beschafft die vollständige Antwort für den Client | | Forwarder | übernimmt weitergeleitete Anfragen | | DNS-Hierarchie | verweist schrittweise auf zuständige Server | | autoritativer DNS-Server | liefert die maßgeblichen Zonendaten | | Cache auf dem Rückweg | speichert positive oder negative Antworten | Die Diagnose folgt dieser Kette vom Client in Richtung autoritativer Datenquelle. --- **7.12.7 Umfang der Störung bestimmen** Kontrollierte Vergleiche: | Vergleich | Aussage | |---|---| | gleicher Name, anderer Client | clientbezogenen Fehler prüfen | | gleicher Client, anderer Name | namens- oder zonenbezogenen Fehler prüfen | | gleicher Name, anderer DNS-Server | resolverbezogenen Fehler prüfen | | gleiche Abfrage, direkt gegen autoritativen Server | Rekursion und Autorität trennen | | gleiche Abfrage mit und ohne VPN | VPN-, NRPT- oder Split-DNS-Fehler prüfen | | gleiche Abfrage über UDP und TCP | Transportfehler prüfen | | direkte DNS-Abfrage und Anwendung | DNS- und Anwendungsfehler trennen | | Vorwärts- und Rückwärtsauflösung | A/AAAA und PTR getrennt prüfen | | erste und wiederholte Abfrage | Cachewirkung prüfen | | interner und externer Name | interne Zone und Rekursion trennen | Erst nach diesen Vergleichen sollte eine konkrete Ursache angenommen werden. --- **7.12.8 Clientidentität und Netzwerkzustand prüfen** **Windows** ```powershell Get-NetIPConfiguration ``` ```cmd ipconfig /all ``` **Linux** ```bash ip address ``` ```bash ip route ``` **macOS** ```bash ifconfig ``` ```bash route -n get default ``` Zu prüfen sind: - aktive Schnittstelle; - IPv4- und IPv6-Adresse; - Subnetz beziehungsweise Präfix; - Standardgateway; - DNS-Server; - DHCP- oder statische Konfiguration; - Verbindungssuffix; - VPN-Schnittstelle; - unerwartete zusätzliche Schnittstellen; - Container-, Hypervisor- oder Sicherheitsadapter. Eine vorhandene IP-Adresse beweist nicht, dass der vorgesehene DNS-Server erreichbar ist. --- **7.12.9 DNS-Server und Resolverkonfiguration ermitteln** **Windows** ```powershell Get-DnsClientServerAddress ``` ```powershell Get-DnsClient ``` **Linux** ```bash cat /etc/resolv.conf ``` Bei `systemd-resolved`: ```bash resolvectl status ``` **macOS** ```bash scutil --dns ``` Zu prüfen sind: - DNS-Server pro Schnittstelle; - Reihenfolge der DNS-Server; - DNS-Suffixe; - Suchliste; - VPN-spezifische Resolver; - IPv4- und IPv6-DNS-Server; - lokale Stub-Adressen; - namensraumabhängige Resolver. `/etc/resolv.conf` kann lediglich auf einen lokalen Stub-Resolver verweisen. In diesem Fall müssen die tatsächlichen Upstream-DNS-Server über den zuständigen Resolverdienst ermittelt werden. --- **7.12.10 Interne Clients und öffentliche DNS-Server** Domänenmitglieder und interne Clients müssen für interne Namensräume die vorgesehenen internen DNS-Server verwenden. Das Eintragen eines öffentlichen DNS-Servers wie eines Resolverdienstes im Internet kann: - interne Zonen unauflösbar machen; - Active-Directory-SRV-Einträge verbergen; - Split-DNS umgehen; - interne Namen an externe Resolver übertragen; - Anmeldungen, Gruppenrichtlinien und Dienstsuche beeinträchtigen; - zu wechselnden Ergebnissen führen. Ein öffentlicher DNS-Server darf deshalb nicht als pauschale Reparatur für einen internen DNS-Fehler eingetragen werden. --- **7.12.11 Hosts-Datei und lokale Namensquellen prüfen** Hosts-Dateien: | Betriebssystem | Pfad | |---|---| | Windows | `C:\Windows\System32\drivers\etc\hosts` | | Linux | `/etc/hosts` | | macOS | `/etc/hosts` | Zu prüfen sind: - existiert ein Eintrag für den betroffenen Namen? - stimmt die eingetragene IP-Adresse? - existieren doppelte oder auskommentierte Varianten? - verwendet die Anwendung einen eigenen lokalen Namensspeicher? - stammt die erfolgreiche Auflösung überhaupt aus DNS? Eine direkte Abfrage mit ausdrücklich angegebenem DNS-Server kann erfolgreich sein, während eine Anwendung wegen eines falschen lokalen Eintrags eine andere Adresse verwendet. --- **7.12.12 Kurznamen und DNS-Suffixe prüfen** Wenn ein Benutzer nur folgenden Namen verwendet: ```text server01 ``` kann der Resolver abhängig von seiner Suchliste nacheinander verschiedene Namen bilden: ```text server01.example.test server01.branch.example.test server01.other.example.test ``` Windows-Konfiguration prüfen: ```powershell Get-DnsClient ``` Linux mit `systemd-resolved`: ```bash resolvectl status ``` macOS: ```bash scutil --dns ``` Mögliche Fehler: - falsches Verbindungssuffix; - fehlende Suchdomäne; - zu lange Suchliste; - unerwartete Reihenfolge; - unterschiedliche Suffixe zwischen LAN und VPN; - ein Kurzname trifft unbeabsichtigt auf eine andere Zone; - Suchanfragen erzeugen zusätzliche Verzögerungen. Für die technische Diagnose sollte zuerst der vollständige FQDN verwendet werden. --- **7.12.13 Tatsächlichen Windows-Resolverpfad bestimmen** Unter Windows können NRPT, VPN-Richtlinien und verschlüsseltes DNS den Abfrageweg verändern. Wirksame NRPT-Richtlinien: ```powershell Get-DnsClientNrptPolicy ``` Konfigurierte NRPT-Regeln: ```powershell Get-DnsClientNrptRule ``` DNS-Clientzustand: ```cmd netsh dnsclient show state ``` Globale verschlüsselte DNS-Einstellungen: ```cmd netsh dnsclient show global ``` Konfigurierte DoH- oder DoT-Endpunkte: ```cmd netsh dnsclient show encryption ``` Wichtig: - `Resolve-DnsName` kann den Windows-Resolverpfad einschließlich NRPT verwenden. - `nslookup` verwendet einen eigenen Abfrageweg und eignet sich nicht allein zur Prüfung der NRPT. - Browser oder andere Anwendungen können eigene DoH-Resolver verwenden. - Eine direkte Abfrage mit `-Server` prüft den angegebenen DNS-Server, aber nicht zwingend die gesamte normale Resolverauswahl der Anwendung. Deshalb müssen Systemauflösung und direkte Serverabfrage getrennt getestet werden. --- **7.12.14 Anwendung und DNS voneinander abgrenzen** Folgende Ergebnisse sind getrennt zu prüfen: 1. Kann die Ziel-IP-Adresse direkt erreicht werden? 2. Liefert eine direkte DNS-Abfrage die erwartete Adresse? 3. Liefert der normale Betriebssystemresolver dieselbe Adresse? 4. Verwendet die Anwendung dieselbe Adresse? 5. Ist der eigentliche Dienst auf der Zieladresse erreichbar? Beispiel: ```powershell Resolve-DnsName "app.example.test" ``` Direkte Abfrage gegen einen bestimmten DNS-Server: ```powershell Resolve-DnsName ` -Name "app.example.test" ` -Type A ` -Server "192.0.2.53" ` -DnsOnly ``` Wenn DNS die richtige IP-Adresse liefert, die Anwendung aber weiterhin fehlschlägt, müssen unter anderem Anwendungscache, Proxy, TLS-Zertifikat, Dienstport und Anwendungsrichtlinien geprüft werden. Ein erfolgreicher DNS-Test beweist nicht, dass der Zielservice funktioniert. --- **7.12.15 Direkte DNS-Abfragen durchführen** **Windows PowerShell** ```powershell Resolve-DnsName ` -Name "app.example.test" ` -Type A ` -Server "192.0.2.53" ` -DnsOnly ``` **Windows Eingabeaufforderung** ```cmd nslookup app.example.test 192.0.2.53 ``` **Linux und macOS** ```bash dig @192.0.2.53 app.example.test A ``` Bei jedem Test sind zu dokumentieren: - Abfragename; - Datensatztyp; - verwendeter DNS-Server; - Antwortcode; - Antwortinhalt; - TTL; - Antwortzeit; - Flags; - autoritative oder rekursive Antwort; - zusätzliche CNAME-Ziele. --- **7.12.16 Datensatztypen gezielt prüfen** | Aufgabe | Datensatz | |---|---| | IPv4-Adresse ermitteln | A | | IPv6-Adresse ermitteln | AAAA | | Alias verfolgen | CNAME | | Mailserver ermitteln | MX | | Dienst und Port ermitteln | SRV | | IP-Adresse rückwärts auflösen | PTR | | Zonenautorität prüfen | SOA | | autoritative Server ermitteln | NS | | Richtlinien- oder Verifikationstext prüfen | TXT | | DNSSEC-Schlüssel prüfen | DNSKEY | | Delegationssignatur prüfen | DS | Beispiele: ```powershell Resolve-DnsName "app.example.test" -Type A ``` ```powershell Resolve-DnsName "alias.example.test" -Type CNAME ``` ```powershell Resolve-DnsName "_service._tcp.example.test" -Type SRV ``` ```powershell Resolve-DnsName "example.test" -Type SOA ``` ```powershell Resolve-DnsName "example.test" -Type NS ``` Bei CNAME, MX und SRV muss zusätzlich geprüft werden, ob der zurückgegebene Zielname über A oder AAAA auflösbar ist. --- **7.12.17 DNS-Antwortcodes auswerten** | Ergebnis | Bedeutung | Nächster Schritt | |---|---|---| | `NOERROR` mit Antwort | Abfrage erfolgreich | Inhalt, TTL und Quelle prüfen | | `NOERROR` ohne gesuchten Datensatz | Name kann existieren, Datensatztyp fehlt | anderen Datensatztyp und SOA prüfen | | `NXDOMAIN` | abgefragter Name existiert laut Antwort nicht | Name, Zone, Autorität und negativen Cache prüfen | | `SERVFAIL` | Server konnte keine verwertbare Antwort erzeugen | Delegation, DNSSEC, Forwarder und Serverprotokolle prüfen | | `REFUSED` | Server verweigert die Abfrage | ACL, Rekursion, Richtlinie und Quellnetz prüfen | | `FORMERR` | DNS-Nachricht wurde als fehlerhaft bewertet | Client, Server und Netzwerkgerät prüfen | | `NOTIMP` | angeforderte Funktion wird nicht unterstützt | Abfragefunktion und Serverfähigkeit prüfen | | Timeout | keine verwertbare Antwort innerhalb der Wartezeit | Netzwerk, Transport und Serververfügbarkeit prüfen | | `TC` gesetzt | UDP-Antwort wurde abgeschnitten | erneuten Versuch über TCP prüfen | Wichtige Unterscheidungen: - `NODATA` ist kein eigener RCODE, sondern beschreibt typischerweise `NOERROR` ohne den angefragten Datensatz. - Timeout ist keine DNS-Antwort. - `SERVFAIL` beweist nicht, dass der Name nicht existiert. - `NXDOMAIN` und ein fehlender einzelner Datensatztyp sind nicht dasselbe. - Extended DNS Errors können zusätzliche Hinweise liefern, werden aber nicht von jedem Resolver oder Diagnosewerkzeug angezeigt. --- **7.12.18 Antwortflags berücksichtigen** Typische DNS-Flags: | Flag | Bedeutung | |---|---| | `AA` | Antwort ist für die beantwortete Zone autoritativ | | `RD` | Client hat Rekursion angefordert | | `RA` | Server bietet Rekursion an | | `TC` | Antwort wurde abgeschnitten | | `AD` | Resolver kennzeichnet Daten als DNSSEC-validiert | | `CD` | Client fordert an, Validierungsfehler nicht als Sperre zu verwenden | Ein gesetztes `AD`-Flag muss im Zusammenhang mit dem verwendeten validierenden Resolver bewertet werden. Das bloße Anfordern von DNSSEC-Daten beweist keine erfolgreiche Validierung. --- **7.12.19 Antwortzeit messen** **Windows** ```powershell Measure-Command { Resolve-DnsName ` -Name "app.example.test" ` -Type A ` -Server "192.0.2.53" ` -DnsOnly } ``` **Linux und macOS** ```bash dig @192.0.2.53 app.example.test A +stats ``` Zu vergleichen sind: - erste Abfrage; - unmittelbar wiederholte Abfrage; - vorhandener Name; - nicht vorhandener Name; - interner Name; - externer Name; - primärer DNS-Server; - alternativer DNS-Server; - rekursiver DNS-Server; - autoritativer DNS-Server; - UDP; - TCP; - mit und ohne VPN. `Measure-Command` enthält auch den PowerShell-Befehlsaufwand. Es eignet sich deshalb vor allem für Vergleiche unter denselben Bedingungen. --- **7.12.20 Cachezustand prüfen** **Windows-Clientcache** ```powershell Get-DnsClientCache ``` Alternativ: ```cmd ipconfig /displaydns ``` **Linux mit systemd-resolved** ```bash resolvectl statistics ``` **Windows-DNS-Servercacheeinstellungen** ```powershell Get-DnsServerCache ``` `Get-DnsServerCache` zeigt Cacheeinstellungen des Windows-DNS-Servers und nicht einfach eine vollständige Liste aller zwischengespeicherten Antworten. Zu prüfen sind: - positiver oder negativer Cacheeintrag; - Datensatztyp; - gespeicherter Wert; - verbleibende TTL; - Herkunft des Eintrags; - Verhalten nach Ablauf der TTL; - Unterschiede zwischen Anwendung, Client und DNS-Server. Cachelöschung verändert Beweisdaten und darf erst nach der Dokumentation als kontrollierter Vergleich erfolgen. --- **7.12.21 Positive und negative Zwischenspeicherung unterscheiden** Positive Antworten können A-, AAAA-, CNAME-, PTR- oder andere Datensätze zwischenspeichern. Negative Zwischenspeicherung kann unter anderem betreffen: - nicht vorhandenen Namen; - vorhandenen Namen ohne angefragten Datensatztyp; - vorübergehende Auflösungsfehler, abhängig vom Resolververhalten. Mögliche Folge: 1. Ein Name wird abgefragt und liefert `NXDOMAIN`. 2. Der fehlende Datensatz wird anschließend angelegt. 3. Der Client oder rekursive Resolver liefert zunächst weiterhin die gespeicherte negative Antwort. 4. Erst nach Ablauf oder kontrollierter Löschung des Cacheeintrags wird der neue Datensatz sichtbar. Deshalb müssen SOA-Daten, negative TTL und alle beteiligten Cacheebenen berücksichtigt werden. --- **7.12.22 DNS-Server vergleichen** Eine identische Abfrage muss gezielt an jeden vorgesehenen DNS-Server gesendet werden. **Windows** ```powershell Resolve-DnsName ` -Name "app.example.test" ` -Type A ` -Server "192.0.2.53" ` -DnsOnly ``` ```powershell Resolve-DnsName ` -Name "app.example.test" ` -Type A ` -Server "192.0.2.54" ` -DnsOnly ``` **Linux und macOS** ```bash dig @192.0.2.53 app.example.test A ``` ```bash dig @192.0.2.54 app.example.test A ``` Zu vergleichen sind: - Antwortcode; - Datensatzwert; - TTL; - CNAME-Kette; - Antwortzeit; - Autoritätsflag; - SOA- und NS-Daten; - DNSSEC-Verhalten. Unterschiedliche Antworten können auf Cache-, Zonen-, Replikations-, Zonentransfer- oder Konfigurationsprobleme hinweisen. --- **7.12.23 UDP und TCP prüfen** Klassische DNS-Abfragen verwenden häufig UDP-Port `53`. TCP-Port `53` wird unter anderem benötigt: - bei abgeschnittenen UDP-Antworten; - bei größeren Antworten; - bei bestimmten DNSSEC-Antworten; - bei Zonentransfers; - wenn TCP ausdrücklich angefordert wird. TCP-Erreichbarkeit unter Windows: ```powershell Test-NetConnection "192.0.2.53" -Port 53 ``` Dieser Befehl prüft nur TCP. Normale DNS-Abfrage: ```powershell Resolve-DnsName ` -Name "app.example.test" ` -Server "192.0.2.53" ` -DnsOnly ``` TCP erzwingen: ```powershell Resolve-DnsName ` -Name "app.example.test" ` -Server "192.0.2.53" ` -DnsOnly ` -TcpOnly ``` Mit `dig`: ```bash dig @192.0.2.53 app.example.test A ``` ```bash dig @192.0.2.53 app.example.test A +tcp ``` Wenn UDP fehlschlägt und TCP funktioniert, sind Firewall, Paketverlust, EDNS, MTU und Fragmentierung zu prüfen. --- **7.12.24 EDNS, MTU und Fragmentierung prüfen** Hinweise auf ein Größen- oder Transportproblem: - einfache A-Abfrage funktioniert; - größere TXT-, DNSKEY- oder DNSSEC-Antwort schlägt fehl; - Fehler tritt nur über VPN oder Tunnel auf; - UDP endet im Timeout; - dieselbe Abfrage funktioniert über TCP; - Netzwerkaufzeichnung zeigt fragmentierte oder verlorene Pakete. Vergleich: ```bash dig @192.0.2.53 example.com A +dnssec ``` ```bash dig @192.0.2.53 example.com A +dnssec +tcp ``` Test ohne EDNS: ```bash dig @192.0.2.53 example.com A +noedns ``` Das testweise Unterdrücken von EDNS dient nur der Eingrenzung. EDNS darf nicht dauerhaft deaktiviert werden, um einen fehlerhaften Netzwerkpfad zu verdecken. --- **7.12.25 Verschlüsseltes DNS prüfen** DNS over HTTPS und DNS over TLS verändern den Transportweg. Zu prüfen sind: - verwendetes Protokoll; - Resolveradresse; - DoH-URI beziehungsweise DoT-Hostname; - TCP-Port; - TLS-Zertifikat; - Zertifikatsname; - Vertrauenskette; - Fallback auf klassisches DNS; - Firewall- und Proxyweg; - Anwendung mit eigenem DoH-Resolver; - Erreichbarkeit interner Zonen. Windows-Zustand: ```cmd netsh dnsclient show state ``` ```cmd netsh dnsclient show encryption ``` Bei verschlüsseltem DNS kann eine klassische Paketaufzeichnung den DNS-Inhalt nicht ohne zusätzliche, autorisierte Entschlüsselungsinformationen anzeigen. Ein erfolgreicher Test gegen UDP- oder TCP-Port `53` beweist nicht, dass ein DoH- oder DoT-Endpunkt funktioniert. --- **7.12.26 Rekursiven und autoritativen DNS-Server unterscheiden** Ein rekursiver DNS-Server beschafft die Antwort im Auftrag des Clients. Ein autoritativer DNS-Server verwaltet die maßgeblichen Daten einer Zone. Diagnosevergleich: 1. Client fragt vorgesehenen rekursiven DNS-Server. 2. Rekursiver Server liefert Fehler oder langsame Antwort. 3. Autoritativer DNS-Server wird direkt abgefragt. 4. Ergebnisse werden verglichen. Wenn der autoritative Server korrekt und schnell antwortet, liegt die Ursache wahrscheinlich bei: - Rekursion; - Forwarder; - Cache; - DNSSEC-Validierung; - Netzwerkpfad; - Richtlinie des rekursiven Servers. Wenn bereits der autoritative Server falsche Daten liefert, sind Zone, Datensatz, Delegation und Replikation zu prüfen. --- **7.12.27 SOA-, NS- und Delegationsdaten prüfen** SOA prüfen: ```powershell Resolve-DnsName ` -Name "example.test" ` -Type SOA ` -Server "192.0.2.53" ` -DnsOnly ``` NS prüfen: ```powershell Resolve-DnsName ` -Name "example.test" ` -Type NS ` -Server "192.0.2.53" ` -DnsOnly ``` Mit `dig`: ```bash dig @192.0.2.53 example.test SOA ``` ```bash dig @192.0.2.53 example.test NS ``` Öffentliche Delegationskette verfolgen: ```bash dig app.example.test A +trace ``` Zu prüfen sind: - richtige Zonengrenze; - zuständige autoritative Server; - Erreichbarkeit aller autoritativen Server; - korrekte NS-Einträge; - erforderliche Glue Records; - SOA-Seriennummer; - widersprüchliche Antworten; - veraltete Delegation; - fehlende oder falsche Child-Zone. `dig +trace` folgt der öffentlichen DNS-Hierarchie. Interne Split-DNS-Zonen, bedingte Forwarder und private Namensräume müssen über den internen DNS-Pfad geprüft werden. --- **7.12.28 Forwarder, bedingte Forwarder und Rekursion prüfen** Auf einem Windows-DNS-Server: ```powershell Get-DnsServerForwarder ``` ```powershell Get-DnsServerRecursion ``` ```powershell Get-DnsServerRootHint ``` Zonen und bedingte Weiterleitungen: ```powershell Get-DnsServerZone ``` Zu prüfen sind: - Erreichbarkeit aller Forwarder; - Antwortzeit jedes Forwarders; - bedingter Forwarder für den betroffenen Namensraum; - aktuelle Zieladressen; - Replikationsbereich eines AD-integrierten bedingten Forwarders; - aktivierte oder deaktivierte Rekursion; - Root-Hint-Verwendung; - DNS-Richtlinien und Rekursionsbereiche; - Timeout- und Fallbackverhalten. Ein nicht erreichbarer erster Forwarder kann Verzögerungen verursachen, bevor ein weiterer Auflösungspfad verwendet wird. --- **7.12.29 Reverse-Lookups prüfen** **Windows** ```powershell Resolve-DnsName ` -Name "192.0.2.25" ` -Type PTR ` -Server "192.0.2.53" ` -DnsOnly ``` **Linux und macOS** ```bash dig @192.0.2.53 -x 192.0.2.25 ``` Danach muss der PTR-Zielname wieder vorwärts geprüft werden: ```powershell Resolve-DnsName ` -Name "host25.example.test" ` -Type A ` -Server "192.0.2.53" ` -DnsOnly ``` Zu prüfen sind: - Reverse-Zone; - Delegation; - PTR-Eintrag; - Zielname; - TTL; - Vorwärts-Rückwärts-Konsistenz; - veraltete Einträge; - öffentliche oder private Zuständigkeit; - dynamische Aktualisierung. Ein fehlender PTR-Eintrag beweist keinen vollständigen DNS-Ausfall. --- **7.12.30 DNSSEC systematisch abgrenzen** DNSSEC-Daten anfordern: ```powershell Resolve-DnsName ` -Name "example.com" ` -Type A ` -Server "192.0.2.53" ` -DnsOnly ` -DnssecOk ``` Mit `dig`: ```bash dig @192.0.2.53 example.com A +dnssec ``` Zu prüfen sind: - tritt `SERVFAIL` nur bei signierten Zonen auf? - funktioniert die Abfrage über einen nicht validierenden Vergleichspfad? - existieren DS- und DNSKEY-Datensätze? - sind Signaturen gültig? - stimmt die Systemzeit? - ist der Trust Anchor vorhanden? - verlangt die NRPT DNSSEC-Validierung? - zeigt der Resolver einen Extended DNS Error an? - besteht ein Größen- oder Transportproblem? `-DnssecOk` und `+dnssec` fordern DNSSEC-bezogene Daten an. Diese Optionen beweisen allein keine erfolgreiche Validierung. `nslookup` ist nicht für eine vollständige DNSSEC-Diagnose geeignet. --- **7.12.31 Windows-DNS-Serverzustand prüfen** Dienststatus: ```powershell Get-Service -Name DNS ``` Zonen: ```powershell Get-DnsServerZone ``` Bestimmte Zone: ```powershell Get-DnsServerZone ` -Name "example.test" ``` Datensätze: ```powershell Get-DnsServerResourceRecord ` -ZoneName "example.test" ``` Serverstatistiken: ```powershell Get-DnsServerStatistics ``` Verfügbare Leistungsindikatoren: ```powershell Get-Counter -ListSet DNS ``` Zu prüfen sind: - Dienststatus; - geladene und angehaltene Zonen; - primäre, sekundäre, Stub- oder AD-integrierte Zone; - Replikationsbereich; - dynamische Updates; - Zonentransfer; - Serverfehler; - Rekursionsfehler; - Abfragerate; - CPU, Speicher und Netzwerk; - Unterschiede zwischen DNS-Servern. Ein laufender DNS-Dienst beweist nicht, dass eine bestimmte Zone korrekt geladen oder repliziert wurde. --- **7.12.32 Active-Directory-DNS prüfen** LDAP-SRV-Einträge: ```powershell Resolve-DnsName ` -Name "_ldap._tcp.dc._msdcs." ` -Type SRV ``` Kerberos-SRV-Einträge: ```powershell Resolve-DnsName ` -Name "_kerberos._tcp." ` -Type SRV ``` DNS-Test eines Domänencontrollers: ```cmd dcdiag /test:DNS /v /s: ``` Replikationsübersicht: ```cmd repadmin /replsummary ``` Replikationsdetails: ```cmd repadmin /showrepl ``` Zu prüfen sind: - verwendet der Client ausschließlich vorgesehene AD-DNS-Server? - existieren die benötigten SRV-Einträge? - sind die SRV-Zielhosts über A oder AAAA auflösbar? - sind die veröffentlichten Dienste erreichbar? - existiert die Zone auf allen vorgesehenen DNS-Servern? - funktioniert AD-Replikation? - stimmen Standort- und Subnetzzuordnung? - liefern verschiedene DCs unterschiedliche Antworten? Eine manuelle Neuerstellung von SRV-Einträgen ist keine erste Maßnahme. Zuerst müssen Registrierung, Netlogon, Zone, Berechtigungen und Replikation geprüft werden. --- **7.12.33 Dynamische Updates und DHCP prüfen** Vor einer erneuten Registrierung sind vorhandene Datensätze, Zeitstempel und Ereignisse zu dokumentieren. Verändernde Clientregistrierung: ```powershell Register-DnsClient ``` Alternativ: ```cmd ipconfig /registerdns ``` Zu prüfen sind: - Existenz der Forward- und Reverse-Zone; - erlaubte Aktualisierungsart; - sichere dynamische Updates; - Client- oder DHCP-Verantwortung; - DHCP-Lease; - DNS-Optionen des DHCP-Bereichs; - Aktualisierung von A- und PTR-Einträgen; - Datensatzeigentümer; - Berechtigungen; - statische Altbestände; - DHCP-Failover; - DNS- und DHCP-Ereignisse. Das wiederholte Registrieren behebt keine fehlende Zone, falsche Berechtigung oder fehlerhafte DHCP-DNS-Konfiguration. --- **7.12.34 Aging und Scavenging prüfen** Zu prüfen sind: - Aging-Einstellung der Zone; - Scavenging-Einstellung des Servers; - No-Refresh-Intervall; - Refresh-Intervall; - Scavenging-Zyklus; - Zeitstempel des Datensatzes; - statischer oder dynamischer Eintrag; - DHCP-Leasezeit; - Zeitpunkt der letzten Aktualisierung; - unerwartet gelöschte Datensätze. Scavenging beinhaltet Löschvorgänge und darf nicht spontan aktiviert oder erzwungen werden, um einzelne veraltete Einträge zu beseitigen. --- **7.12.35 Ereignisse und Protokolle auswerten** Vorhandene DNS-Protokolle unter Windows anzeigen: ```powershell Get-WinEvent -ListLog "*DNS*" ``` Mögliche Bereiche: - DNS-Client-Protokolle; - DNS-Server-Audit-Protokoll; - DNS-Server-Analytical-Protokoll; - Systemprotokoll; - DHCP-Serverprotokoll; - Verzeichnisdienstprotokoll; - anwendungsspezifische Protokolle. Zu korrelieren sind: - genauer Zeitpunkt; - Clientadresse; - Abfragename; - Datensatztyp; - Antwortcode; - verwendeter Server; - dynamische Aktualisierung; - Zonenladen; - Replikation; - DNSSEC; - DoH; - Dienststart oder Dienstfehler. Analytische DNS-Protokollierung muss gezielt und zeitlich begrenzt aktiviert werden. Sie kann bei hohen Abfrageraten die Leistung beeinflussen und enthält schützenswerte interne Namensinformationen. --- **7.12.36 Netzwerkaufzeichnung gezielt einsetzen** Eine Netzwerkaufzeichnung ist sinnvoll, wenn unklar bleibt: - ob die Abfrage den Client verlässt; - welcher DNS-Server angesprochen wird; - ob eine Antwort zurückkommt; - ob Wiederholungen stattfinden; - ob UDP oder TCP verwendet wird; - ob die UDP-Antwort abgeschnitten ist; - ob anschließend TCP verwendet wird; - ob Fragmentierung oder Paketverlust auftritt; - wie lang die Antwort tatsächlich benötigt; - ob der Client zu einem anderen DNS-Server wechselt. Bei DoH und DoT ist der DNS-Inhalt verschlüsselt. Sichtbar bleiben unter anderem Zieladresse, Port, TLS-Verbindung und Zeitverhalten, nicht jedoch ohne Weiteres der eigentliche DNS-Nachrichteninhalt. Aufzeichnungen müssen auf die betroffenen Systeme, Namen und Zeiträume begrenzt sowie geschützt gespeichert werden. --- **7.12.37 Hypothese und Gegenbeweis formulieren** Beispiel: ```text Hypothese: Der erste konfigurierte DNS-Forwarder ist nicht erreichbar und verursacht die Verzögerung. Erwarteter Befund: Direkte Abfragen gegen den ersten Forwarder laufen in einen Timeout. Direkte Abfragen gegen den zweiten Forwarder funktionieren sofort. Gegenbeweis: Der erste Forwarder antwortet unter denselben Bedingungen schnell und korrekt. ``` Eine belastbare Hypothese enthält: - vermutete Ursache; - erwarteten messbaren Befund; - möglichen Gegenbeweis; - Testmethode; - Erfolgskriterium; - Risiko des Tests. Erst danach sollte eine Änderung vorgenommen werden. --- **7.12.38 Kontrollierte Maßnahmen** | Maßnahme | Voraussetzung | Risiko | |---|---|---| | DNS-Serveradresse korrigieren | falscher Resolver nachgewiesen | andere Namensräume können beeinflusst werden | | Suffix oder NRPT-Regel korrigieren | falscher Abfrageweg nachgewiesen | VPN- und Split-DNS-Verhalten ändert sich | | DNS-Datensatz korrigieren | autoritative Daten sind nachweislich falsch | Anwendungen können auf neues Ziel wechseln | | PTR-Eintrag korrigieren | falscher Reverse-Eintrag bestätigt | Protokoll- oder Sicherheitszuordnung ändert sich | | Forwarder korrigieren | nicht erreichbarer oder falscher Forwarder bestätigt | externe oder interne Rekursion betroffen | | Delegation korrigieren | falsche NS- oder Glue-Daten bestätigt | gesamte Zone kann betroffen sein | | dynamische Updates korrigieren | Updatefehler und Berechtigung nachgewiesen | viele Clients können Einträge verändern | | Cache kontrolliert löschen | falscher Cacheeintrag dokumentiert | Beweisdaten gehen verloren | | DNSSEC-Konfiguration korrigieren | Validierungsfehler nachgewiesen | Vertrauenskette und Sicherheit betroffen | | Aging oder Scavenging anpassen | Fehlkonfiguration nachgewiesen | gültige Datensätze können gelöscht werden | | Replikationsfehler beheben | AD-Replikationsfehler bestätigt | mehrere Verzeichnisdaten betroffen | Vor der Maßnahme sind zu dokumentieren: - Ausgangszustand; - betroffene Systeme und Zonen; - Berechtigung; - Risiko; - Rückweg; - Erfolgskriterium; - vorgesehenes Testverfahren. --- **7.12.39 Vollständiger Diagnoseablauf** 1. **Exakte Fehlermeldung aufnehmen** Wortlaut, Anwendung, Benutzer, Client und Uhrzeit dokumentieren. 2. **Betroffenen Namen bestimmen** Kurzname, FQDN oder IP-Adresse unterscheiden. 3. **Erwarteten Datensatztyp bestimmen** A, AAAA, CNAME, PTR, SRV, MX, TXT, NS oder SOA festlegen. 4. **Erwartetes Ergebnis dokumentieren** Vorgesehene IP-Adresse, Zielname oder Dienstinformation festhalten. 5. **Umfang bestimmen** Einzelnen Client, Standort, DNS-Server, Namen, Zone oder alle Systeme unterscheiden. 6. **Anwendung und DNS abgrenzen** Direkte IP-Verbindung, Systemresolver und Anwendung getrennt prüfen. 7. **Netzwerkzustand erfassen** Schnittstelle, Adresse, Gateway, VPN und Routing dokumentieren. 8. **Konfigurierte DNS-Server erfassen** DNS-Server pro Schnittstelle und Reihenfolge bestimmen. 9. **Suffixe und lokale Namensquellen prüfen** Suchliste, Hosts-Datei und Anwendungscache berücksichtigen. 10. **Resolverrichtlinien prüfen** NRPT, Split-DNS, Container-DNS und Sicherheitsresolver berücksichtigen. 11. **Verschlüsselten DNS-Pfad bestimmen** Klassisches DNS, DoH und DoT unterscheiden. 12. **Normale Systemauflösung testen** Prüfen, welches Ergebnis die Anwendung grundsätzlich erhalten kann. 13. **Direkte Abfrage durchführen** Vorgesehenen DNS-Server und Datensatztyp ausdrücklich angeben. 14. **Antwortcode auswerten** `NOERROR`, `NXDOMAIN`, `SERVFAIL`, `REFUSED` oder Timeout unterscheiden. 15. **Antwortinhalt auswerten** Wert, TTL, CNAME-Kette und Flags prüfen. 16. **Antwortzeit messen** Erste und wiederholte Abfrage vergleichen. 17. **Alternativen DNS-Server prüfen** Unterschiede zwischen vorgesehenen Resolvern dokumentieren. 18. **Cachezustand prüfen** Positive und negative Einträge auf allen relevanten Ebenen berücksichtigen. 19. **UDP und TCP vergleichen** Transportabhängige Fehler bestimmen. 20. **EDNS, MTU und Fragmentierung prüfen** Besonders bei großen Antworten oder VPN-Verbindungen. 21. **Rekursiven und autoritativen Server unterscheiden** Abfrageweg in einzelne Ebenen zerlegen. 22. **SOA, NS und Delegation prüfen** Zuständigkeit und Zonengrenze bestätigen. 23. **Autoritative Server direkt vergleichen** Datensatz, TTL, Seriennummer und Antwortcode auswerten. 24. **Forwarder und Rekursion prüfen** Erreichbarkeit, Richtlinien und Timeoutpfad untersuchen. 25. **DNSSEC prüfen** Signaturen, DS, DNSKEY, Trust Anchor und Validierungsfehler berücksichtigen. 26. **Reverse-Lookup prüfen** PTR, Reverse-Zone, Delegation und Vorwärtskonsistenz auswerten. 27. **DNS-Serverzustand prüfen** Dienst, Zonen, Statistiken, Last und Ereignisse untersuchen. 28. **AD-DNS und Replikation prüfen** Wenn AD-integrierte Zonen oder SRV-Einträge beteiligt sind. 29. **Dynamische Updates und DHCP prüfen** Registrierung, Eigentümer, Berechtigungen und Leasezustand auswerten. 30. **Aging und Scavenging prüfen** Bei veralteten oder unerwartet fehlenden Einträgen. 31. **Protokolle korrelieren** Client, DNS-Server, DHCP und Anwendung auf denselben Versuch begrenzen. 32. **Bei Bedarf Netzwerkaufzeichnung durchführen** Nur zeitlich und technisch begrenzt. 33. **Hypothese und Gegenbeweis formulieren** Ursache vor der Änderung messbar beschreiben. 34. **Eine kontrollierte Maßnahme ausführen** Risiko, Rückweg und Erfolgskriterium beachten. 35. **Identischen Test wiederholen** Antwortcode, Wert und Zeit mit dem Ausgangszustand vergleichen. 36. **Alternativen Pfad erneut prüfen** Weitere Clients, Resolver oder autoritative Server kontrollieren. 37. **Anwendung verifizieren** Nicht nur das Diagnosewerkzeug testen. 38. **Temporäre Änderungen zurücknehmen** Logging, Testregeln und Ausnahmen entfernen. 39. **Ursache dokumentieren** Technischen Nachweis und betroffenen Pfad festhalten. 40. **Prävention festlegen** Monitoring, Standardisierung oder Konfigurationsverbesserung umsetzen. --- **7.12.40 Befundmatrix** | Befund | Mögliche Einordnung | Nächster Nachweis | |---|---|---| | IP-Verbindung funktioniert, Name nicht | DNS oder lokaler Resolverpfad | direkte A-/AAAA-Abfrage | | direkter DNS-Test funktioniert, Anwendung nicht | Anwendungscache, Proxy oder eigener Resolver | Anwendungsresolver und Zieladresse prüfen | | nur Kurzname schlägt fehl | Suffix- oder Suchlistenproblem | FQDN und Suffixkonfiguration vergleichen | | nur ein Client betroffen | lokale Konfiguration, Cache oder Hosts-Datei | anderen Client und direkte Serverabfrage vergleichen | | nur ein DNS-Server betroffen | Zone, Cache, Dienst oder Replikation | DNS-Server direkt vergleichen | | ganze Zone liefert `NXDOMAIN` | falscher Resolver oder fehlende Delegation | SOA, NS und autoritative Server prüfen | | `NOERROR`, aber keine A-Antwort | Name vorhanden, Datensatztyp fehlt | CNAME, AAAA und SOA prüfen | | `SERVFAIL` | Rekursion, DNSSEC oder Serverfehler | autoritative Abfrage und Protokolle | | `REFUSED` | Richtlinie, ACL oder deaktivierte Rekursion | Serverkonfiguration und Quellnetz prüfen | | Timeout | fehlende Antwort | Transport, Netzwerk und Serverlast prüfen | | UDP schlägt fehl, TCP funktioniert | Firewall, MTU, Fragmentierung oder EDNS | Netzwerkaufzeichnung und große Antwort prüfen | | erste Abfrage langsam, zweite schnell | Cacheeffekt | kalte und warme Abfrage vergleichen | | externe Namen langsam | Forwarder oder Rekursion | Forwarder direkt prüfen | | interne Namen langsam | interne Delegation, Forwarder oder AD-DNS | interne autoritative Server prüfen | | mit VPN falsche Antwort | NRPT oder Split-DNS | Resolver vor und nach VPN vergleichen | | Browser und System liefern verschiedene Antworten | Browser-DoH oder Anwendungscache | Browserresolver und Systemresolver vergleichen | | PTR fehlt, A funktioniert | Reverse-Zone oder PTR fehlt | Reverse-Delegation prüfen | | unterschiedliche Antworten je DC | AD-Replikation | `repadmin` und direkte DNS-Abfragen | | nur große Antworten scheitern | EDNS-, MTU- oder Fragmentierungsproblem | UDP/TCP-Vergleich | | nur signierte Zonen scheitern | DNSSEC-Validierungsfehler | DS-, DNSKEY- und EDE-Auswertung | | neuer Datensatz bleibt unsichtbar | positiver oder negativer Cache | TTL und Cacheebenen prüfen | | SRV vorhanden, Dienst nicht erreichbar | Zielhost, Port oder Dienst fehlerhaft | SRV-Ziel und Dienstport prüfen | --- **7.12.41 Typische Diagnosefehler** - Fehlermeldung nicht vollständig dokumentieren. - Kurzname und FQDN verwechseln. - Den benötigten Datensatztyp nicht bestimmen. - `ping` als vollständigen DNS-Test verwenden. - Einen erfolgreichen Ping als Nachweis des Dienstes betrachten. - Nur `nslookup` verwenden. - NRPT mit `nslookup` prüfen. - Anwendung und direkten DNS-Test gleichsetzen. - Den tatsächlich verwendeten DNS-Server nicht bestimmen. - Öffentlichen DNS-Server auf einem Domänenclient eintragen. - Cache vor der Beweissicherung löschen. - `NXDOMAIN`, `NODATA`, `SERVFAIL` und Timeout gleich behandeln. - Nur den Antwortcode, aber nicht den Antwortinhalt prüfen. - Nur den Antwortwert, aber nicht TTL und Quelle prüfen. - Rekursiven und autoritativen DNS-Server verwechseln. - Nur einen DNS-Server testen. - UDP und TCP nicht getrennt prüfen. - TCP-Port `53` als UDP-Nachweis verwenden. - EDNS, MTU und Fragmentierung ignorieren. - DoH oder DoT über einen klassischen DNS-Test als funktionsfähig bewerten. - DNSSEC allein mit `nslookup` prüfen. - `+dnssec` als vollständigen Validierungsnachweis interpretieren. - Öffentliche `+trace`-Abfrage für eine interne Split-DNS-Zone verwenden. - CNAME-, MX- oder SRV-Zielnamen nicht weiter auflösen. - Erfolgreichen SRV-Lookup mit erreichbarem Dienst gleichsetzen. - PTR-Fehler als vollständigen DNS-Ausfall bewerten. - Forwarder verändern, ohne ihr Verhalten direkt zu testen. - DNS-Dienst vorsorglich neu starten. - Zone vorsorglich neu erstellen. - Einträge löschen, ohne Eigentümer, TTL und Replikation zu prüfen. - Scavenging unkontrolliert aktivieren. - AD-Replikationsfehler durch manuelle DNS-Änderungen verdecken. - Pro Diagnoseversuch mehrere Variablen verändern. - Nur das Diagnosewerkzeug, aber nicht die Anwendung verifizieren. - Temporäre Logging- oder Firewalländerungen aktiv lassen. --- **7.12.42 Verifikation** Nach einer Maßnahme müssen mindestens folgende Punkte geprüft werden: - Client besitzt eine gültige Netzwerkkonfiguration; - vorgesehene DNS-Server sind eingetragen; - richtige Schnittstelle und VPN-Regel werden verwendet; - Suffixe und Suchliste sind korrekt; - Hosts-Datei enthält keinen widersprüchlichen Eintrag; - NRPT und Split-DNS funktionieren wie vorgesehen; - DoH oder DoT funktioniert, sofern vorgesehen; - exakter FQDN wird korrekt aufgelöst; - benötigter Datensatztyp ist vorhanden; - Antwortcode ist korrekt; - Antwortwert entspricht dem Sollzustand; - TTL ist plausibel; - rekursive und autoritative Antworten sind konsistent; - alle vorgesehenen DNS-Server liefern den richtigen Wert; - UDP und TCP funktionieren; - DNSSEC-Validierung funktioniert, sofern vorgesehen; - Vorwärts- und Rückwärtsauflösung stimmen überein, sofern erforderlich; - SRV-, MX- und CNAME-Ziele sind vollständig auflösbar; - AD-SRV-Einträge sind vorhanden; - AD-Replikation ist fehlerfrei; - dynamische Aktualisierung funktioniert, sofern vorgesehen; - keine neuen DNS-, DHCP- oder Replikationsfehler entstehen; - Antwortzeit entspricht der Baseline; - ursprüngliche Anwendung funktioniert; - weitere repräsentative Clients funktionieren; - temporäre Diagnoseänderungen wurden zurückgenommen; - Ursache, Maßnahme und Prävention wurden dokumentiert. Eine einzelne erfolgreiche Cacheabfrage ist keine ausreichende Verifikation. --- **7.12.43 Dokumentationsvorlage** ```text Störung: Zeitpunkt: Betroffener Client: Betroffene Anwendung: Abfragename: Datensatztyp: Erwartetes Ergebnis: Tatsächliches Ergebnis: Verwendeter Resolver: Resolverpfad: Vergleichstests: Nachgewiesene Ursache: Gegenbeweis ausgeschlossen durch: Durchgeführte Maßnahme: Risiko und Rückweg: Verifikation: Präventionsmaßnahme: ``` --- **7.12.44 Checkliste** - [ ] exakte Fehlermeldung dokumentiert - [ ] Datum und Uhrzeit erfasst - [ ] betroffenen Client erfasst - [ ] betroffene Anwendung erfasst - [ ] Kurzname, FQDN und IP-Adresse unterschieden - [ ] benötigten Datensatztyp bestimmt - [ ] erwartetes Ergebnis dokumentiert - [ ] Fehlerumfang bestimmt - [ ] aktive Netzwerkschnittstelle geprüft - [ ] IP-Adresse und Gateway geprüft - [ ] VPN-Zustand dokumentiert - [ ] konfigurierte DNS-Server erfasst - [ ] DNS-Serverreihenfolge geprüft - [ ] DNS-Suffixe und Suchliste geprüft - [ ] Hosts-Datei geprüft - [ ] Anwendungscache berücksichtigt - [ ] NRPT geprüft - [ ] Split-DNS berücksichtigt - [ ] DoH oder DoT berücksichtigt - [ ] normalen Systemresolver getestet - [ ] direkte DNS-Abfrage durchgeführt - [ ] DNS-Server ausdrücklich angegeben - [ ] Antwortcode dokumentiert - [ ] Antwortinhalt dokumentiert - [ ] TTL dokumentiert - [ ] Antwortflags berücksichtigt - [ ] Antwortzeit gemessen - [ ] erste und wiederholte Abfrage verglichen - [ ] positiven Cache geprüft - [ ] negativen Cache geprüft - [ ] alternativen DNS-Server getestet - [ ] UDP getestet - [ ] TCP getestet - [ ] EDNS und MTU berücksichtigt - [ ] rekursiven Server bestimmt - [ ] autoritativen Server bestimmt - [ ] SOA geprüft - [ ] NS-Einträge geprüft - [ ] Delegation geprüft - [ ] autoritative Server direkt verglichen - [ ] Forwarder geprüft - [ ] bedingte Forwarder geprüft - [ ] Rekursion geprüft - [ ] A- und AAAA-Einträge geprüft - [ ] CNAME-Kette geprüft - [ ] SRV- oder MX-Ziele bei Bedarf geprüft - [ ] Reverse-Lookup geprüft - [ ] DNSSEC bei Bedarf geprüft - [ ] DNS-Serverdienst geprüft - [ ] Zonenstatus geprüft - [ ] Serverstatistiken geprüft - [ ] Serverlast geprüft - [ ] DNS-Ereignisse ausgewertet - [ ] AD-SRV-Einträge bei Bedarf geprüft - [ ] AD-Replikation bei Bedarf geprüft - [ ] dynamische Updates bei Bedarf geprüft - [ ] DHCP-DNS-Aktualisierung bei Bedarf geprüft - [ ] Aging und Scavenging bei Bedarf geprüft - [ ] Hypothese formuliert - [ ] Gegenbeweis festgelegt - [ ] Risiko und Rückweg dokumentiert - [ ] nur eine kontrollierte Maßnahme durchgeführt - [ ] identischen Test wiederholt - [ ] ursprüngliche Anwendung getestet - [ ] weitere repräsentative Systeme geprüft - [ ] temporäre Änderungen zurückgenommen - [ ] Ursache und Prävention dokumentiert --- **7.12.45 Schnellreferenz** | Aufgabe | Befehl | |---|---| | Windows-Netzwerkkonfiguration | `Get-NetIPConfiguration` | | vollständige Windows-IP-Konfiguration | `ipconfig /all` | | Windows-DNS-Serveradressen | `Get-DnsClientServerAddress` | | Windows-DNS-Clientkonfiguration | `Get-DnsClient` | | Linux-Resolverzustand | `resolvectl status` | | macOS-Resolverzustand | `scutil --dns` | | wirksame NRPT-Richtlinie | `Get-DnsClientNrptPolicy` | | konfigurierte NRPT-Regeln | `Get-DnsClientNrptRule` | | verschlüsselter DNS-Clientzustand | `netsh dnsclient show state` | | verschlüsselte DNS-Endpunkte | `netsh dnsclient show encryption` | | Systemauflösung unter Windows | `Resolve-DnsName ` | | direkte A-Abfrage | `Resolve-DnsName -Type A -Server -DnsOnly` | | direkte AAAA-Abfrage | `Resolve-DnsName -Type AAAA -Server -DnsOnly` | | CNAME prüfen | `Resolve-DnsName -Type CNAME -Server -DnsOnly` | | SRV prüfen | `Resolve-DnsName -Type SRV -Server -DnsOnly` | | PTR prüfen | `Resolve-DnsName -Type PTR -Server -DnsOnly` | | SOA prüfen | `Resolve-DnsName -Type SOA -Server -DnsOnly` | | NS prüfen | `Resolve-DnsName -Type NS -Server -DnsOnly` | | direkte Abfrage mit `dig` | `dig @ ` | | Reverse-Abfrage mit `dig` | `dig @ -x ` | | öffentliche Delegation verfolgen | `dig +trace` | | TCP-DNS unter Windows | `Resolve-DnsName -Server -DnsOnly -TcpOnly` | | TCP-DNS mit `dig` | `dig @ +tcp` | | DNSSEC-Daten anfordern | `dig @ +dnssec` | | Windows-Clientcache | `Get-DnsClientCache` | | Windows-DNS-Dienst | `Get-Service DNS` | | Windows-DNS-Zonen | `Get-DnsServerZone` | | Windows-DNS-Datensätze | `Get-DnsServerResourceRecord -ZoneName ` | | Windows-DNS-Forwarder | `Get-DnsServerForwarder` | | Windows-DNS-Rekursion | `Get-DnsServerRecursion` | | Windows-DNS-Statistiken | `Get-DnsServerStatistics` | | DNS-Leistungsindikatoren | `Get-Counter -ListSet DNS` | | vorhandene Windows-DNS-Protokolle | `Get-WinEvent -ListLog "*DNS*"` | | AD-DNS-Test | `dcdiag /test:DNS /v /s:` | | AD-Replikationsübersicht | `repadmin /replsummary` | | AD-Replikationsdetails | `repadmin /showrepl` | Ändernde Befehle, die nicht als erste Diagnose verwendet werden dürfen: ```text Clear-DnsClientCache Clear-DnsServerCache Register-DnsClient ipconfig /flushdns ipconfig /registerdns Set-DnsClientServerAddress Set-DnsServerForwarder Set-DnsServerRecursion Set-DnsServerCache Set-DnsServerZoneAging Start-DnsServerScavenging Add-DnsServerPrimaryZone Add-DnsServerResourceRecord Remove-DnsServerResourceRecord Restart-Service DNS ``` --- **7.12.46 Quellen** **Offizielle Microsoft-Dokumentation** - [Microsoft Learn – Guidance for troubleshooting DNS](https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/troubleshoot-dns-guidance) - [Microsoft Learn – Troubleshooting DNS clients](https://learn.microsoft.com/en-us/windows-server/networking/dns/troubleshoot/troubleshoot-dns-client) - [Microsoft Learn – Troubleshooting DNS servers](https://learn.microsoft.com/en-us/windows-server/networking/dns/troubleshoot/troubleshoot-dns-server) - [Microsoft Learn – Troubleshoot DNS client name resolution issues](https://learn.microsoft.com/en-us/troubleshoot/windows-client/networking/troubleshoot-dns-client-resolution-issues) - [Microsoft Learn – Troubleshoot DNS name resolution on the Internet](https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/troubleshoot-dns-name-resolution) - [Microsoft Learn – DNS queries and lookups](https://learn.microsoft.com/en-us/windows-server/networking/dns/queries-lookups) - [Microsoft Learn – DNS architecture](https://learn.microsoft.com/en-us/windows-server/networking/dns/dns-architecture) - [Microsoft Learn – Resolve-DnsName](https://learn.microsoft.com/en-us/powershell/module/dnsclient/resolve-dnsname) - [Microsoft Learn – DnsClient PowerShell module](https://learn.microsoft.com/en-us/powershell/module/dnsclient/) - [Microsoft Learn – DnsServer PowerShell module](https://learn.microsoft.com/en-us/powershell/module/dnsserver/) - [Microsoft Learn – Test-NetConnection](https://learn.microsoft.com/en-us/powershell/module/nettcpip/test-netconnection) - [Microsoft Learn – Best practices for DNS client settings](https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/best-practices-for-dns-client-settings) - [Microsoft Learn – Forwarders and conditional forwarders resolution timeouts](https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/forwarders-resolution-timeouts) - [Microsoft Learn – Dynamic DNS Update in Windows and Windows Server](https://learn.microsoft.com/en-us/windows-server/networking/dns/dynamic-update) - [Microsoft Learn – DNS scavenging setup](https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/dns-scavenging-setup) - [Microsoft Learn – Enable DNS logging and diagnostics](https://learn.microsoft.com/en-us/windows-server/networking/dns/dns-logging-and-diagnostics) - [Microsoft Learn – Validate and secure DNS responses using DNSSEC](https://learn.microsoft.com/en-us/windows-server/networking/dns/validate-dnssec-responses) - [Microsoft Learn – Secure DNS Client over HTTPS](https://learn.microsoft.com/en-us/windows-server/networking/dns/doh-client-support) - [Microsoft Learn – DNS encryption using DNS over HTTPS](https://learn.microsoft.com/en-us/windows-server/networking/dns/dns-encryption-dns-over-https) - [Microsoft Learn – netsh dnsclient](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/netsh-dnsclient) - [Microsoft Learn – Dcdiag](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/dcdiag) - [Microsoft Learn – Verify DNS functionality to support directory replication](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/troubleshoot/verify-dns-functionality-to-support-directory-replication) **Offizielle Projektdokumentation** - [ISC BIND 9 – dig manual page](https://bind9.readthedocs.io/en/latest/manpages.html) - [ISC BIND 9 – Troubleshooting](https://bind9.readthedocs.io/en/v9.18.28/chapter9.html) - [systemd – resolvectl](https://www.freedesktop.org/software/systemd/man/resolvectl.html) - [systemd – systemd-resolved](https://www.freedesktop.org/software/systemd/man/systemd-resolved.service.html) **Standards** - [RFC 1034 – Domain Names: Concepts and Facilities](https://datatracker.ietf.org/doc/html/rfc1034) - [RFC 1035 – Domain Names: Implementation and Specification](https://datatracker.ietf.org/doc/html/rfc1035) - [RFC 2308 – Negative Caching of DNS Queries](https://datatracker.ietf.org/doc/html/rfc2308) - [RFC 4033 – DNS Security Introduction and Requirements](https://datatracker.ietf.org/doc/html/rfc4033) - [RFC 4035 – Protocol Modifications for DNS Security Extensions](https://datatracker.ietf.org/doc/html/rfc4035) - [RFC 6891 – Extension Mechanisms for DNS](https://datatracker.ietf.org/doc/html/rfc6891) - [RFC 7766 – DNS Transport over TCP](https://datatracker.ietf.org/doc/html/rfc7766) - [RFC 7858 – DNS over Transport Layer Security](https://datatracker.ietf.org/doc/html/rfc7858) - [RFC 8484 – DNS Queries over HTTPS](https://datatracker.ietf.org/doc/html/rfc8484) - [RFC 8499 – DNS Terminology](https://datatracker.ietf.org/doc/html/rfc8499) - [RFC 8914 – Extended DNS Errors](https://datatracker.ietf.org/doc/html/rfc8914) - [RFC 9520 – Negative Caching of DNS Resolution Failures](https://datatracker.ietf.org/doc/html/rfc9520) Für diese Seite wurden keine Community-Berichte, Hersteller-Social-Media-Aussagen oder eigenen Laborergebnisse als Nachweis verwendet. # 7.13 Datenträger oder Dateisystem ist voll **7.13.1 Ziel dieser Seite** Diese Seite beschreibt die systematische Diagnose, wenn ein System, Datenträger, Volume, Dateisystem, Speicherpool, Container oder eine Anwendung keinen weiteren Speicherplatz verwenden kann. Ziele der Diagnose: - den tatsächlich betroffenen Pfad bestimmen; - logische und physische Speicherebenen unterscheiden; - belegte Datenblöcke, Inodes und Quotas getrennt prüfen; - plötzliches und kontinuierliches Wachstum unterscheiden; - versteckte Speicherverbraucher erkennen; - eine kurzfristige Entlastung kontrolliert durchführen; - die eigentliche Ursache nachweisen; - einen erneuten Kapazitätsengpass verhindern. Ein gemeldetes „Dateisystem voll“ bedeutet nicht zwangsläufig, dass die physische Festplatte vollständig belegt ist. --- **7.13.2 Sicherheitskennzeichnungen** | Kennzeichnung | Bedeutung | |---|---| | **LESEND** | erfasst ausschließlich Zustände und Messwerte | | **LASTERZEUGEND** | kann CPU, Arbeitsspeicher oder Datenträger-I/O deutlich belasten | | **ÄNDERND** | verändert Konfigurationen oder Systemzustände | | **LÖSCHEND** | entfernt Daten und kann Informationen unwiederbringlich zerstören | | **AUSFALLRISIKO** | kann Dienste, Dateisysteme oder ganze Systeme unterbrechen | Grundregeln: - Zuerst den exakten Zustand und den Zeitpunkt dokumentieren. - Keine Dateien aufgrund ihres Namens löschen. - Aktive Datenbanken, Container-Volumes und Anwendungsdateien nicht manuell bereinigen. - Protokolle vor dem Löschen auswerten und bei Bedarf sichern. - Snapshots nicht ohne Kenntnis ihrer Abhängigkeiten entfernen. - Dateisystemprüfungen nicht ungeprüft auf produktiv eingebundenen Dateisystemen ausführen. - Speicherpools und Thin-Provisioning-Metadaten besonders vorsichtig behandeln. - Vor jeder Änderung müssen Risiko, Freigabe, Rückweg und Erfolgskriterium feststehen. --- **7.13.3 Mögliche Fehlerklassen** | Fehlerklasse | Beschreibung | Typischer Nachweis | |---|---|---| | Datenblöcke voll | nutzbare Speicherkapazität ist erschöpft | `df`, `Get-Volume`, `diskutil info` | | Inodes erschöpft | zu viele Dateien, obwohl noch Datenblöcke frei sind | `df -i` | | Benutzer- oder Gruppenquota erreicht | einzelner Benutzer oder Dienst darf nichts mehr speichern | `quota`, FSRM, Dateisystemquota | | Projekt- oder Verzeichnisquota erreicht | bestimmter Pfad besitzt ein eigenes Limit | XFS-Projektquota, FSRM | | Anwendungsquota erreicht | Anwendung begrenzt Speicher unabhängig vom Dateisystem | Anwendungskonfiguration und Protokolle | | Snapshot-Speicher voll | Snapshots oder Shadow Copies belegen den freien Bereich | VSS-, APFS-, Btrfs- oder ZFS-Auswertung | | Thin Pool voll | zugrunde liegender Thin-Provisioning-Pool besitzt keinen freien Platz | LVM-, SAN- oder Hypervisoranzeige | | Thin-Pool-Metadaten voll | Verwaltungsbereich des Thin Pools ist erschöpft | `lvs` mit `metadata_percent` | | Container-Layer voll | beschreibbare Container-Schicht oder Containerhost ist voll | Docker- oder Runtime-Auswertung | | Kubernetes-Ephemeralspeicher voll | Node oder Pod überschreitet Ephemeral-Storage-Grenzen | `DiskPressure`, Eviction-Ereignisse | | Dateisystem schreibgeschützt | Dateisystem wurde wegen Fehlern nur lesbar eingebunden | Mountoptionen, Kernel- und Systemprotokolle | | Physischer Datenträgerfehler | Schreibvorgänge scheitern durch Hardware- oder I/O-Fehler | SMART, Ereignisse, Kernelmeldungen | | Gelöschte Datei noch geöffnet | Verzeichniseintrag ist gelöscht, Prozess hält Datei weiterhin geöffnet | `lsof +L1` | | Reservierter Speicher | freier Bereich steht normalen Benutzern nicht zur Verfügung | Dateisystem- und Reservierungsdaten | | Versteckte Daten unter Mountpoint | Dateien liegen unterhalb eines später darüber eingebundenen Dateisystems | Mountstruktur und Wartungsprüfung | | Kapazität des Backends voll | lokaler Client zeigt nur einen vorgelagerten NAS-, SAN- oder Cloudspeicher | Backend-, Pool- und Quotaauswertung | --- **7.13.4 Typische Symptome und Fehlermeldungen** Mögliche Symptome: - Dateien können nicht mehr gespeichert werden. - Anwendungen starten nicht oder stürzen ab. - Datenbanken wechseln in einen Fehlerzustand. - Updates und Paketinstallationen schlagen fehl. - Benutzerprofile können nicht geladen werden. - Protokolle werden nicht mehr geschrieben. - Backupjobs brechen ab. - Temporäre Dateien können nicht angelegt werden. - Container starten wiederholt neu. - Kubernetes-Pods werden wegen `DiskPressure` beendet. - Ein Dateisystem wird plötzlich schreibgeschützt. - Ein Volume wird mit `100 %` Belegung angezeigt. - Ein Benutzer kann nicht schreiben, andere Benutzer jedoch schon. - Eine Freigabe meldet „voll“, obwohl der Server noch freien Gesamtspeicher besitzt. Typische Meldungen: ```text No space left on device ENOSPC Disk full There is not enough space on the disk Not enough disk space Quota exceeded EDQUOT Read-only file system EROFS I/O error DiskPressure Evicted ephemeral-storage Thin pool is full Metadata space exhausted ``` `No space left on device` kann sowohl auf erschöpfte Datenblöcke als auch auf erschöpfte Inodes oder interne Dateisystemreserven hinweisen. `Quota exceeded` betrifft dagegen gewöhnlich ein festgelegtes Speicherlimit und nicht zwingend das gesamte Dateisystem. --- **7.13.5 Sofortmaßnahmen ohne unkontrolliertes Löschen** 1. Exakte Fehlermeldung und Uhrzeit erfassen. 2. Betroffenen Host, Dienst, Benutzer, Container und Pfad bestimmen. 3. Kritikalität und Auswirkung bewerten. 4. Aktuelle Kapazität, Inodes, Quotas und Speicherpools dokumentieren. 5. Schreibintensive Prozesse und aktuelle Wachstumsrate identifizieren. 6. Bei akutem Wachstum eine kontrollierte Drosselung oder Beendigung des verursachenden Dienstes prüfen. 7. Keine unnötigen Neustarts durchführen. 8. Keine Protokolle, Datenbanken oder Container-Volumes spontan löschen. 9. Nur eindeutig entbehrliche und freigegebene Daten kontrolliert entfernen. 10. Nach jeder Maßnahme denselben Speichertest wiederholen. Ein Neustart kann die Situation verschärfen, wenn ein Dienst beim Start temporären Speicher benötigt oder eine Datenbank wegen fehlenden Speicherplatzes keine Wiederherstellung durchführen kann. --- **7.13.6 Speicherpfad vollständig abbilden** Der sichtbare Pfad kann mehrere Speicherebenen durchlaufen: ```text Anwendung → Anwendungspfad → Container oder virtuelle Maschine → Mountpoint oder Laufwerksbuchstabe → Dateisystem → Partition oder logisches Volume → Thin Pool, RAID oder Storage Pool → physischer Datenträger, NAS oder SAN ``` Jede Ebene kann ein eigenes Limit besitzen. Beispiel: ```text Anwendung schreibt nach /var/lib/app → Docker-Bind-Mount → /srv/containers/app → ext4-Dateisystem → LVM Logical Volume → LVM Thin Pool → RAID-Verbund → physische SSDs ``` Freier Speicher auf einer Ebene beweist nicht, dass alle anderen Ebenen ebenfalls freien Speicher besitzen. --- **7.13.7 Grundfragen der Diagnose** Zu klären sind: - Welcher genaue Pfad kann nicht beschrieben werden? - Welches Dateisystem enthält diesen Pfad? - Ist das gesamte Dateisystem oder nur ein Benutzer betroffen? - Sind Datenblöcke, Inodes oder eine Quota erschöpft? - Ist das Dateisystem beschreibbar eingebunden? - Welche Daten sind zuletzt gewachsen? - Trat das Wachstum plötzlich oder kontinuierlich auf? - Existieren Snapshots, Shadow Copies oder Container-Layer? - Gibt es einen Thin-Provisioning-Pool? - Liegt das eigentliche Speichersystem auf einem NAS oder SAN? - Sind gelöschte Dateien weiterhin geöffnet? - Sind Protokolle, Caches, Dumps, Backups oder temporäre Dateien beteiligt? - Liegt zusätzlich ein Hardware- oder Dateisystemfehler vor? - Welche Mindestkapazität benötigt der betroffene Dienst zur Wiederaufnahme? --- **7.13.8 Windows – Volumeauslastung erfassen** **LESEND** ```powershell Get-Volume | Select-Object ` DriveLetter, FileSystemLabel, FileSystem, HealthStatus, OperationalStatus, @{ Name = "SizeGiB" Expression = { [math]::Round($_.Size / 1GB, 2) } }, @{ Name = "FreeGiB" Expression = { [math]::Round($_.SizeRemaining / 1GB, 2) } }, @{ Name = "FreePercent" Expression = { if ($_.Size -gt 0) { [math]::Round( 100 * $_.SizeRemaining / $_.Size, 1 ) } } } ``` Dateisystemlaufwerke der aktuellen PowerShell-Sitzung: ```powershell Get-PSDrive ` -PSProvider FileSystem ``` Lokale logische Laufwerke: ```powershell Get-CimInstance ` -ClassName Win32_LogicalDisk ` -Filter "DriveType=3" | Select-Object ` DeviceID, VolumeName, FileSystem, Size, FreeSpace ``` `Get-PSDrive` kann auch eingebundene Dateisystemlaufwerke anzeigen. Bei Netzwerkfreigaben können Quotas oder serverseitige Einschränkungen dazu führen, dass die gemeldete Verfügbarkeit nicht der gesamten Backendkapazität entspricht. --- **7.13.9 Windows – Datenträger, Partition und Volume zuordnen** **LESEND** ```powershell Get-Disk | Select-Object ` Number, FriendlyName, PartitionStyle, OperationalStatus, HealthStatus, Size ``` ```powershell Get-Partition | Select-Object ` DiskNumber, PartitionNumber, DriveLetter, Type, Size ``` ```powershell Get-Partition | Get-Volume | Select-Object ` DriveLetter, FileSystemLabel, FileSystem, Size, SizeRemaining ``` Von Speicherverwaltungsanbietern gemeldete physische Datenträger: ```powershell Get-PhysicalDisk | Select-Object ` FriendlyName, MediaType, OperationalStatus, HealthStatus, Size ``` Zu beachten: - `Get-Disk` bildet nicht jede mögliche Storage-Architektur vollständig ab. - Hardware-RAID-Controller können nur ein virtuelles Laufwerk anzeigen. - SAN-LUNs erscheinen als Datenträger, obwohl die physische Kapazität extern verwaltet wird. - Storage Spaces, Cluster Shared Volumes und herstellerspezifische Pools müssen zusätzlich in ihrer jeweiligen Verwaltung geprüft werden. --- **7.13.10 Windows – große Verzeichnisse und Dateien eingrenzen** Eine rekursive Suche kann auf großen Dateisystemen erhebliche I/O-Last verursachen. Der Suchpfad muss deshalb möglichst eng begrenzt werden. **LESEND, LASTERZEUGEND** Größe der direkten Unterverzeichnisse eines bekannten Pfades: ```powershell $ScanRoot = "C:\Data" Get-ChildItem ` -LiteralPath $ScanRoot ` -Directory ` -Force ` -ErrorAction SilentlyContinue | ForEach-Object { $Measurement = Get-ChildItem ` -LiteralPath $_.FullName ` -File ` -Force ` -Recurse ` -ErrorAction SilentlyContinue | Measure-Object ` -Property Length ` -Sum [pscustomobject]@{ Path = $_.FullName SizeGiB = [math]::Round( $Measurement.Sum / 1GB, 2 ) } } | Sort-Object ` -Property SizeGiB ` -Descending ``` Größte Dateien unter einem begrenzten Pfad: ```powershell Get-ChildItem ` -LiteralPath "C:\Data" ` -File ` -Force ` -Recurse ` -ErrorAction SilentlyContinue | Sort-Object ` -Property Length ` -Descending | Select-Object ` -First 20 ` FullName, Length, LastWriteTime ``` Einschränkungen: - fehlende Berechtigungen können Ergebnisse unvollständig machen; - rekursive Suchen können produktive Datenträger belasten; - Dateisystemmetadaten, Snapshots und geöffnete gelöschte Dateien erscheinen nicht zwingend in der Summe; - Hardlinks und Deduplizierung können die Auswertung beeinflussen; - ein vollständiger Lauf über ein großes Servervolume darf nicht unkontrolliert gestartet werden. --- **7.13.11 Windows – versteckte und reservierte Speicherverbraucher prüfen** **VSS und Shadow Copies** **LESEND** ```cmd vssadmin list shadowstorage ``` ```cmd vssadmin list shadows ``` Zu prüfen sind: - verwendeter Shadow-Copy-Speicher; - maximal erlaubter Speicher; - betroffene Quell- und Speicher-Volumes; - ungewöhnlich viele Snapshots; - fehlgeschlagene Bereinigungen; - Backupsoftware mit VSS-Nutzung. Shadow Copies dürfen nicht spontan gelöscht oder verkleinert werden. Sie können für Wiederherstellungen, offene Backups oder andere Dienste benötigt werden. **Windows-Komponentenspeicher analysieren** **LESEND, LASTERZEUGEND** ```cmd Dism.exe /Online /Cleanup-Image /AnalyzeComponentStore ``` Die im Explorer angezeigte Größe von `WinSxS` darf nicht durch manuelles Löschen von Dateien korrigiert werden. Hardlinks können die scheinbare Verzeichnisgröße beeinflussen. **Systemdateien und weitere Bereiche** Zu prüfen sind: - Papierkorb; - temporäre Benutzer- und Systemdateien; - Windows-Update-Dateien; - Speicherabbilder; - Ruhezustandsdatei; - Auslagerungsdatei; - VSS-Speicher; - Anwendungsprotokolle; - Installationspakete; - Datenbank- und Transaktionsprotokolle; - Benutzerprofile; - Synchronisationsordner; - lokale Cloudkopien; - Backup- und Exportverzeichnisse. Diese Dateien dürfen nicht allein aufgrund ihrer Größe entfernt werden. --- **7.13.12 Windows – Quotas prüfen** **NTFS-Quota** **LESEND, administrative Berechtigung erforderlich** ```cmd fsutil quota query C: ``` **File Server Resource Manager** ```powershell Get-FsrmQuota | Select-Object ` Path, Size, Usage, SoftLimit, Status, Template ``` Das FSRM-Modul ist nur vorhanden, wenn die entsprechende Windows-Server-Rolle beziehungsweise Verwaltungsfunktion installiert ist. Zu unterscheiden sind: - physisch freier Speicher des Volumes; - NTFS-Benutzerquota; - FSRM-Verzeichnisquota; - Freigabe- oder Anwendungsquota; - Cloud- oder Storage-Backendlimit. Wenn nur ein Benutzer oder ein bestimmtes Verzeichnis betroffen ist, muss zuerst die wirksame Quota geprüft werden. --- **7.13.13 Windows – Storageereignisse auswerten** **LESEND** ```powershell Get-WinEvent ` -FilterHashtable @{ LogName = "System" StartTime = (Get-Date).AddHours(-6) } | Where-Object { $_.ProviderName -in @( "disk", "Ntfs", "ReFS", "volsnap", "storport" ) } | Select-Object ` TimeCreated, ProviderName, Id, LevelDisplayName, Message ``` Zu korrelieren sind: - Zeitpunkt des ersten Speicherfehlers; - Volume oder Gerätename; - Dateisystemfehler; - I/O-Timeouts; - zurückgesetzte Storageverbindungen; - Shadow-Copy-Fehler; - unerwartet entfernte Datenträger; - RAID-, SAN- oder Multipath-Ereignisse; - Anwendungs- und Datenbankfehler zum selben Zeitpunkt. Ein Volume kann gleichzeitig nahezu voll und technisch fehlerhaft sein. Die Freigabe von Speicher behebt dann nicht zwangsläufig die eigentliche Ursache. --- **7.13.14 Linux – Dateisystembelegung erfassen** **LESEND** ```bash df -hT ``` Wichtige Felder: | Feld | Bedeutung | |---|---| | Filesystem | zugrunde liegendes Gerät oder logischer Speicher | | Type | Dateisystemtyp | | Size | Gesamtkapazität | | Used | belegter Speicher | | Avail | verfügbarer Speicher | | Use% | prozentuale Auslastung | | Mounted on | Mountpoint | Bestimmten Pfad prüfen: ```bash df -hT /var/lib/app ``` Exakte Blockwerte: ```bash df -B1 /var/lib/app ``` `df` wertet das Dateisystem aus, in dem der angegebene Pfad liegt. Das ist zuverlässiger, als den Mountpoint nur anhand einer angenommenen Verzeichnisstruktur zu erraten. --- **7.13.15 Linux – Inodes prüfen** **LESEND** ```bash df -i ``` Bestimmten Pfad prüfen: ```bash df -i /var/lib/app ``` Eine mögliche Einordnung: | Blockbelegung | Inodebelegung | Einordnung | |---|---|---| | hoch | normal | große Dateien oder große Datenmengen | | normal | hoch | sehr viele kleine Dateien | | hoch | hoch | Kombination aus Datenmenge und Dateianzahl | | normal | normal | Quota, Reservierung, anderer Mountpoint oder anderer Fehler | Bei erschöpften Inodes können keine neuen Dateien angelegt werden, obwohl noch Datenblöcke frei sind. Typische Verursacher: - Cachedateien; - Sitzungsdateien; - Mailqueues; - kleine temporäre Dateien; - extrahierte Paketbestände; - Container-Layer; - Build-Artefakte; - nicht rotierte Protokolle mit sehr vielen Einzeldateien; - Monitoring- oder Metrikdateien; - Anwendungen mit fehlerhafter Dateibereinigung. --- **7.13.16 Linux – Mounts und Speichergeräte zuordnen** **LESEND** ```bash findmnt ``` Gezielte Ausgabe: ```bash findmnt \ -o TARGET,SOURCE,FSTYPE,OPTIONS ``` Bestimmten Pfad zuordnen: ```bash findmnt \ --target /var/lib/app ``` Blockgeräte: ```bash lsblk \ -o NAME,TYPE,FSTYPE,SIZE,FSAVAIL,FSUSE%,MOUNTPOINTS ``` Zu prüfen sind: - tatsächlicher Mountpoint; - zugrunde liegendes Gerät; - Dateisystemtyp; - Read-only-Option `ro`; - Bind-Mount; - Overlay-Dateisystem; - LVM; - verschlüsseltes Volume; - Netzwerkdateisystem; - Container-Mount; - unerwartet nicht eingebundenes Ziel. Wenn ein vorgesehenes Dateisystem nicht eingebunden ist, kann eine Anwendung unbemerkt in das darunterliegende Root-Dateisystem schreiben. --- **7.13.17 Linux – große Verzeichnisse und Dateien finden** Die Suche sollte auf das betroffene Dateisystem begrenzt werden. **LESEND, LASTERZEUGEND** Direkte Unterverzeichnisse: ```bash du \ -x \ -h \ --max-depth=1 \ /var | sort -h ``` Zusammenfassung eines bestimmten Pfades: ```bash du \ -x \ -s \ -h \ /var/lib/app ``` Größte Dateien mit GNU `find`: ```bash find \ /var/lib/app \ -xdev \ -type f \ -printf '%s\t%p\n' | sort -nr | head -n 20 ``` Wichtige Optionen: | Option | Bedeutung | |---|---| | `-x` bei `du` | bleibt im selben Dateisystem | | `-xdev` bei `find` | überschreitet keine Dateisystemgrenze | | `--max-depth=1` | wertet nur die direkte Verzeichnisebene aus | | `-type f` | beschränkt die Suche auf reguläre Dateien | Die Option `-printf` ist eine GNU-`find`-Funktion und steht nicht auf jedem Unix-System zur Verfügung. --- **7.13.18 Unterschied zwischen `df` und `du` untersuchen** `df` und `du` messen unterschiedliche Dinge: - `df` fragt die Belegung des gesamten Dateisystems ab. - `du` summiert erreichbare Dateien und Verzeichnisse. Wenn `df` eine hohe Belegung zeigt, `du` aber deutlich weniger Daten findet, sind insbesondere zu prüfen: - gelöschte, weiterhin geöffnete Dateien; - fehlende Berechtigungen bei der `du`-Auswertung; - Snapshots; - Dateisystemmetadaten; - reservierte Blöcke; - Daten unterhalb eines Mountpoints; - Copy-on-Write- und Reflink-Daten; - Deduplizierung; - Container-Overlay-Layer; - unterschiedliche Dateisystemgrenzen; - Sparse Files; - Quotadaten; - beschädigte Dateisystemmetadaten. Sparse Files vergleichen: ```bash du -h /pfad/datei ``` ```bash du \ -h \ --apparent-size \ /pfad/datei ``` Die scheinbare Dateigröße kann größer als der tatsächlich belegte Speicher sein. --- **7.13.19 Gelöschte, aber weiterhin geöffnete Dateien prüfen** Unter Unix-ähnlichen Systemen wird der belegte Speicher einer gelöschten Datei erst freigegeben, wenn kein Prozess mehr einen offenen Dateideskriptor auf sie hält. **LESEND** ```bash sudo lsof +L1 ``` Zu prüfen sind: - Prozessname; - Prozess-ID; - Dateisystem; - Dateigröße; - gelöschter Dateipfad; - Dienstabhängigkeiten; - Möglichkeit eines kontrollierten Reloads oder Neustarts. Ein Neustart des gesamten Systems ist nicht die erste Maßnahme. Wenn die Ursache bestätigt ist, sollte der betroffene Dienst kontrolliert neu geladen oder neu gestartet werden. Dabei sind Auswirkung und Wiederanlaufbedingungen zu prüfen. --- **7.13.20 Linux – Journald und Protokollwachstum prüfen** Aktuelle Journalbelegung: **LESEND** ```bash journalctl --disk-usage ``` Journaldateien und Protokollverzeichnisse: ```bash du \ -x \ -h \ --max-depth=1 \ /var/log | sort -h ``` Logrotate-Konfiguration im Debugmodus prüfen: ```bash sudo logrotate \ -d \ /etc/logrotate.conf ``` `logrotate -d` führt keine Rotation aus, zeigt aber die geplante Verarbeitung. Zu prüfen sind: - ungewöhnlich hohe Fehlerrate; - wiederholte identische Meldungen; - deaktivierte oder fehlerhafte Rotation; - Anwendungen mit eigener Logverwaltung; - Debug- oder Trace-Level; - fehlende Aufbewahrungsgrenze; - gelöschte, noch geöffnete Protokolldateien; - Komprimierungsfehler; - falsche Dateiberechtigungen; - voller Zielpfad der Rotation. Das Löschen eines Protokolls behebt nicht den Prozess, der es unkontrolliert erzeugt. --- **7.13.21 Linux – Benutzer-, Gruppen- und Projektquotas prüfen** Quota des aktuellen Benutzers: **LESEND** ```bash quota -s ``` Quotaübersicht vorhandener quota-fähiger Dateisysteme: ```bash sudo repquota -a ``` XFS-Quotaauswertung: ```bash sudo xfs_quota \ -x \ -c 'report -h' \ /mountpoint ``` Zu unterscheiden sind: - Soft Limit; - Hard Limit; - Grace Period; - Blockquota; - Inodequota; - Benutzerquota; - Gruppenquota; - XFS-Projektquota. Eine noch laufende Grace Period kann erklären, warum Schreiben zunächst möglich war und später ohne sichtbare Änderung der Gesamtkapazität fehlschlägt. --- **7.13.22 LVM und Thin Provisioning prüfen** **LESEND** ```bash sudo pvs ``` ```bash sudo vgs ``` ```bash sudo lvs \ -a \ -o lv_name,vg_name,lv_size,pool_lv,origin,data_percent,metadata_percent ``` Besonders kritisch sind: - `data_percent` nahe der Poolkapazität; - `metadata_percent` nahe der Metadatenkapazität; - erschöpfter freier Bereich der Volume Group; - viele oder stark gewachsene Snapshots; - ein Logical Volume, das kleiner als der zugrunde liegende Pool ist; - ein vergrößertes Blockgerät, dessen Partition, Logical Volume oder Dateisystem nicht mitgewachsen ist. Ein Thin Pool kann voll sein, obwohl ein Gastbetriebssystem oder Logical Volume scheinbar noch freien logischen Speicher anzeigt. Das Erweitern eines Speichers muss in der richtigen Reihenfolge erfolgen: ```text Backend oder physischer Datenträger → Partition oder PV → Volume Group oder Pool → Logical Volume → Dateisystem → Anwendung ``` Nicht jede Ebene ist in jeder Architektur vorhanden. --- **7.13.23 Btrfs und ZFS prüfen** **Btrfs** **LESEND** ```bash sudo btrfs filesystem usage -T /mountpoint ``` ```bash sudo btrfs subvolume list /mountpoint ``` Zu prüfen sind: - Datenbelegung; - Metadatenbelegung; - Systembereich; - Global Reserve; - RAID- oder Redundanzprofil; - fehlende Geräte; - Snapshots und Subvolumes; - geschätzter freier Speicher. Bei Btrfs können Daten- und Metadatenbereiche unterschiedlich ausgelastet sein. Eine einfache `df`-Ausgabe reicht deshalb nicht immer für die vollständige Einordnung. **ZFS** ```bash zpool list ``` ```bash zfs list -o space ``` Snapshots: ```bash zfs list \ -t snapshot \ -o name,used,refer,creation ``` Zu prüfen sind: - Poolkapazität; - Dataset-Quota; - Reservation und Refreservation; - Snapshotbelegung; - Kinder-Datasets; - tatsächlich verfügbarer Speicher; - Poolzustand. Snapshots und Copy-on-Write-Daten können Speicher belegen, obwohl aktuelle Dateien bereits gelöscht wurden. --- **7.13.24 macOS – Speicherzustand prüfen** **LESEND** ```bash df -h ``` Bestimmten Pfad prüfen: ```bash df -h /System/Volumes/Data ``` Datenträger und Partitionen: ```bash diskutil list ``` Informationen zum Startvolume: ```bash diskutil info / ``` APFS-Struktur: ```bash diskutil apfs list ``` APFS-Snapshots: ```bash diskutil apfs listSnapshots / ``` Lokale Time-Machine-Snapshots: ```bash tmutil listlocalsnapshots / ``` Große Verzeichnisse unterhalb des Datenvolumes: **LESEND, LASTERZEUGEND** ```bash sudo du \ -x \ -h \ -d 1 \ /System/Volumes/Data \ 2>/dev/null | sort -h ``` Gelöschte, noch geöffnete Dateien: ```bash sudo lsof +L1 ``` Bei APFS teilen sich mehrere Volumes den freien Speicher eines gemeinsamen Containers. Daher müssen Volume, Container, Quotas, Reservierungen und Snapshots gemeinsam betrachtet werden. Die macOS-Anzeige „verfügbar“ kann zusätzlich löschbaren Speicher enthalten. Dieser ist nicht mit unmittelbar freiem Speicher in jeder konkreten Betriebssituation gleichzusetzen. --- **7.13.25 Docker – Speicherverbrauch prüfen** Docker-Root-Verzeichnis: **LESEND** ```bash docker info \ --format '{{.DockerRootDir}}' ``` Docker-Speicherübersicht: ```bash docker system df ``` Detaillierte Übersicht: ```bash docker system df -v ``` Containergrößen: ```bash docker ps \ -a \ --size ``` Volumes: ```bash docker volume ls ``` Logpfade der Container: ```bash docker ps -aq | xargs -r docker inspect \ --format '{{.Name}} {{.LogPath}}' ``` Mounts eines bestimmten Containers: ```bash docker inspect \ --format '{{json .Mounts}}' \ ``` Zu prüfen sind: - Docker-Root-Dateisystem; - beschreibbare Container-Layer; - Images; - gestoppte Container; - Build-Cache; - benannte und anonyme Volumes; - Bind-Mounts; - Containerprotokolle; - Anwendungscaches; - Datenbanken in Volumes; - fehlende Logrotation. Nicht zulässig als spontane Diagnosemaßnahme: ```text docker system prune -a --volumes ``` Dieser Befehl kann gestoppte Container, ungenutzte Images, Netzwerke, Build-Cache und anonyme Volumes entfernen. Vor einer Bereinigung müssen alle betroffenen Objekte einzeln geprüft werden. Das manuelle Löschen innerhalb von `/var/lib/docker` kann die Docker-Metadaten und Containerdaten beschädigen. --- **7.13.26 Kubernetes – Ephemeral Storage und DiskPressure prüfen** Nodezustand: **LESEND** ```bash kubectl get nodes ``` Bestimmten Node untersuchen: ```bash kubectl describe node ``` Zu prüfen sind insbesondere: ```text DiskPressure NodeHasDiskPressure ephemeral-storage imagefs.available imagefs.inodesFree nodefs.available nodefs.inodesFree ``` Ereignisse: ```bash kubectl get events \ --all-namespaces \ --sort-by=.metadata.creationTimestamp ``` Betroffenen Pod untersuchen: ```bash kubectl describe pod \ \ -n ``` Persistente Volumes: ```bash kubectl get pvc \ --all-namespaces ``` Die angezeigte PVC-Kapazität ist nicht automatisch der aktuell freie Speicher innerhalb des eingebundenen Dateisystems. Lokaler Ephemeral Storage kann unter anderem umfassen: - beschreibbare Container-Layer; - `emptyDir`-Volumes; - Node- und Containerprotokolle; - Image-Speicher; - temporäre Anwendungsdaten. Bei Node-Druck kann der Kubelet Pods beenden, um Ressourcen zurückzugewinnen. Das Löschen einzelner Pods behebt die Ursache nicht, wenn Logs, Images oder Anwendungen sofort erneut denselben Speicherverbrauch erzeugen. --- **7.13.27 Anwendungen und Dienste als Verursacher prüfen** Häufige Speicherverbraucher: | Bereich | Mögliche Ursache | |---|---| | Protokolle | fehlende Rotation, Debugmodus, Fehlerschleife | | Datenbank | Transaktionslog, WAL, Temp-Bereich, Replikationsverzug | | Backup | fehlende Retention, doppelte Sicherungen, abgebrochene Jobs | | Container | unbeschränkte Logs, alte Images, beschreibbare Layer | | Monitoring | hochauflösende Metriken, zu lange Aufbewahrung | | Mail | Queue, Anhänge, Quarantäne | | Druck | blockierte Spooldateien | | Anwendung | Cache, Sitzungen, Uploads, Exporte | | Betriebssystem | Updates, Dumps, temporäre Dateien | | Entwicklung | Build-Artefakte, Paketcache, Testdaten | | Virtualisierung | Snapshots, virtuelle Festplatten, Replikation | | Dateidienst | Benutzerdateien, Papierkorb, Versionierung | | Security | EDR-Quarantäne, Scanprotokolle, Forensikdaten | Zu prüfen sind: - Besitzer der Daten; - Erstellungs- und Änderungszeit; - Wachstum pro Stunde oder Tag; - vorgesehene Retention; - aktive Prozesse; - Abhängigkeit zu laufenden Diensten; - Backupstatus; - Replikationsstatus; - Wiederherstellungsbedarf; - Datenschutz und Aufbewahrungspflichten. --- **7.13.28 Netzwerkfreigaben, NAS und SAN prüfen** Bei SMB, NFS, iSCSI, Fibre Channel oder Cloudspeicher müssen Client und Backend getrennt geprüft werden. Zu erfassen sind: - eingebundener Pfad; - verwendetes Protokoll; - Server oder Storageziel; - Share- oder Exportname; - LUN; - Dateisystem; - Storage Pool; - Volume; - Snapshotbestand; - Benutzer- oder Verzeichnisquota; - Thin-Provisioning-Kapazität; - Replikations- und Reservebereiche; - tatsächlich freier physischer Speicher. Mögliche Sonderfälle: - nur eine Freigabequota ist erreicht; - ein einzelner Benutzer hat sein Limit erreicht; - das NAS-Volume ist voll, der Storage Pool aber nicht; - der Pool ist voll, obwohl das Volume noch logischen Speicher meldet; - Snapshots verhindern die Freigabe gelöschter Daten; - eine Thin-LUN ist logisch größer als der physisch verfügbare Pool; - das Dateisystem wurde wegen Backendfehlern schreibgeschützt; - ein nicht eingebundenes Netzwerkziel führte zu lokalen Schreibvorgängen. Herstellerspezifische Lösch-, Snapshot- und Poolbefehle dürfen erst nach Prüfung der jeweiligen Dokumentation verwendet werden. --- **7.13.29 Schreibgeschütztes Dateisystem und Hardwarefehler abgrenzen** Linux-Mountstatus: **LESEND** ```bash findmnt \ -o TARGET,SOURCE,FSTYPE,OPTIONS ``` Aktuelle Kernelmeldungen: ```bash sudo dmesg \ --ctime | grep -Ei \ 'error|i/o|filesystem|read-only|corrupt|nvme|ata|scsi|ext4|xfs|btrfs' ``` Systemprotokolle: ```bash journalctl \ -k \ --since "-2 hours" ``` Falls `smartctl` installiert und für das Gerät geeignet ist: ```bash sudo smartctl \ -a \ /dev/ ``` macOS-Verifikation: ```bash diskutil verifyVolume / ``` Ein Dateisystem kann wegen erkannter Fehler auf `read-only` wechseln. In diesem Fall ist das Löschen von Dateien weder möglich noch die richtige Erstmaßnahme. Offline-Dateisystemprüfungen wie `fsck` dürfen nicht ungeprüft auf einem produktiv eingebundenen Dateisystem ausgeführt werden. Wenn ein Datenträger einen bevorstehenden Ausfall meldet, haben Datensicherung, kontrollierte Außerbetriebnahme und Austausch Vorrang vor einer reinen Speicherbereinigung. --- **7.13.30 Hypothese und Gegenbeweis formulieren** Beispiel: ```text Hypothese: Das Root-Dateisystem ist voll, weil ein Dienst ein Protokoll ohne funktionierende Rotation erzeugt. Erwarteter Befund: df zeigt eine hohe Blockbelegung. Das Protokollverzeichnis enthält eine stark gewachsene Datei. Die Änderungszeit und die Dienstmeldungen passen zum Fehlerzeitpunkt. Gegenbeweis: Das Protokoll ist klein oder wächst nicht. Die Belegung bleibt auch nach kontrolliertem Stoppen des Dienstes unverändert. Testmethode: Dateisystembelegung, Verzeichnisgröße, Änderungszeit, offene Dateien und Dienstprotokolle vergleichen. Erfolgskriterium: Der verursachende Schreibpfad ist eindeutig nachgewiesen. ``` Eine belastbare Hypothese enthält: - vermutete Ursache; - betroffene Speicherebene; - erwarteten Messwert; - möglichen Gegenbeweis; - sichere Testmethode; - Risiko; - Erfolgskriterium. --- **7.13.31 Kontrollierte Maßnahmen** | Maßnahme | Voraussetzung | Risiko | |---|---|---| | unnötige temporäre Daten entfernen | Eigentümer und Entbehrlichkeit bestätigt | benötigte Sitzungs- oder Arbeitsdaten können verloren gehen | | Protokollrotation korrigieren | Logwachstum nachgewiesen | laufender Dienst kann Logdatei weiter offen halten | | Journald begrenzen | Journal als Ursache bestätigt | ältere Diagnoseinformationen gehen verloren | | Anwendungscache bereinigen | Cache ist dokumentiert wiederherstellbar | Lastspitze beim Neuaufbau | | Backupretention korrigieren | abgelaufene Sicherungen eindeutig bestimmt | Wiederherstellungspunkte gehen verloren | | Containerobjekte bereinigen | jedes Objekt auf Nutzung geprüft | Daten oder Rollbackimages können fehlen | | Quota anpassen | Quota als Ursache und Kapazität vorhanden | unkontrolliertes weiteres Wachstum | | Volume erweitern | Backendkapazität und korrekte Ebenen bestätigt | Partitions- oder Dateisystemschaden bei Fehlern | | Thin Pool erweitern | Poolgrenze nachgewiesen | falsche Erweiterungsebene bleibt wirkungslos | | Snapshot entfernen | Abhängigkeiten und Retention geprüft | Wiederherstellungspunkt geht verloren | | Dienst kontrolliert neu starten | gelöschte offene Datei nachgewiesen | Dienstunterbrechung | | fehlerhaften Schreibprozess stoppen | akutes Wachstum bestätigt | Anwendungs- oder Datenverlust | | Storage austauschen | Hardwarefehler bestätigt | Betriebsunterbrechung und Migrationsrisiko | Vor der Maßnahme sind zu dokumentieren: - Ausgangszustand; - betroffener Pfad; - aktuelle Belegung; - erwartete Freigabe; - Datenverantwortlicher; - Backupstatus; - Freigabe; - Risiko; - Rückweg; - Erfolgskriterium. --- **7.13.32 Beispiele für verändernde Bereinigungen** Die folgenden Befehle sind keine Erstdiagnose und dürfen nur nach Prüfung und Freigabe verwendet werden. **Systemd-Journal kontrolliert begrenzen** **LÖSCHEND** ```bash sudo journalctl \ --rotate \ --vacuum-size= ``` Dabei werden archivierte Journaldateien bis zur angegebenen Zielgröße bereinigt. Relevante Protokolle müssen vorher ausgewertet oder gesichert werden. **Windows-Komponentenspeicher bereinigen** **ÄNDERND** ```cmd Dism.exe /Online /Cleanup-Image /StartComponentCleanup ``` Dieser Befehl darf nur nach der vorherigen Analyse mit `/AnalyzeComponentStore` und unter Berücksichtigung laufender Wartungs- oder Updatevorgänge verwendet werden. **Docker-Bereinigung** Vor jedem Prune-Befehl müssen mindestens folgende Ausgaben geprüft werden: ```bash docker system df -v ``` ```bash docker ps -a ``` ```bash docker image ls ``` ```bash docker volume ls ``` Prune-Befehle sind löschend. Insbesondere `--volumes` darf nicht verwendet werden, ohne jedes betroffene Volume und dessen Datenverantwortung geprüft zu haben. --- **7.13.33 Maßnahmen, die nicht spontan ausgeführt werden dürfen** ```text rm -rf auf unbekannten Verzeichnissen Löschen unter /var/lib/docker docker system prune -a --volumes Löschen aktiver Datenbankdateien Löschen von WAL- oder Transaktionslogs Löschen aller Snapshots vssadmin delete shadows unkontrolliertes Verkleinern des VSS-Speichers manuelles Löschen aus WinSxS Leeren produktiver Protokolle ohne Sicherung fsck auf einem schreibend eingebundenen Dateisystem Ändern reservierter ext4-Blöcke ohne Kapazitätsplanung Vergrößern einer Partition ohne Backup und Ebenenprüfung Entfernen von Kubernetes-PVCs Löschen unbekannter Container-Volumes Deaktivieren von Quotas ohne Ursachenanalyse Neustart des gesamten Hosts als erste Maßnahme ``` Eine Datei mit der Endung `.log`, `.tmp`, `.bak` oder `.old` ist nicht automatisch entbehrlich. --- **7.13.34 Vollständiger Diagnoseablauf** 1. **Fehlermeldung vollständig aufnehmen** Wortlaut, Anwendung, Benutzer und Zeitpunkt dokumentieren. 2. **Betroffenen Pfad bestimmen** Exakten Datei-, Volume-, Mount- oder Containerpfad erfassen. 3. **Auswirkung bestimmen** Einzelne Anwendung, Benutzer, Host oder Standort unterscheiden. 4. **Schreibtest nicht unkontrolliert wiederholen** Zusätzliche Schreibvorgänge können die Lage verschärfen. 5. **Speicherebene bestimmen** Anwendung, Container, Dateisystem, Volume, Pool und Backend zuordnen. 6. **Gesamtkapazität und freien Speicher erfassen** Werte in Prozent und absoluten Größen dokumentieren. 7. **Inodes prüfen** Besonders bei vielen kleinen Dateien. 8. **Quotas prüfen** Benutzer-, Gruppen-, Projekt-, Verzeichnis- und Anwendungsquotas unterscheiden. 9. **Schreibschutz prüfen** Read-only-Mount oder Dateisystemfehler ausschließen. 10. **Speicherpool prüfen** RAID, LVM, Thin Pool, Storage Spaces, NAS oder SAN berücksichtigen. 11. **Snapshots prüfen** VSS, APFS, Btrfs, ZFS, Hypervisor und Storage-Snapshots erfassen. 12. **Wachstumsrate bestimmen** Aktuelle Werte mit Monitoring oder früheren Messungen vergleichen. 13. **Große Verzeichnisse eingrenzen** Suche auf das betroffene Dateisystem beschränken. 14. **Große Dateien bestimmen** Besitzer, Zweck und Änderungszeit dokumentieren. 15. **Viele kleine Dateien berücksichtigen** Inodeverbrauch und Dateianzahl untersuchen. 16. **Gelöschte offene Dateien prüfen** Besonders nach manueller Loglöschung. 17. **Protokolle und Rotation prüfen** Fehlerschleifen, Debugmodus und Retention untersuchen. 18. **Datenbanken prüfen** Daten-, Transaktions-, WAL- und Temp-Bereiche unterscheiden. 19. **Backupdaten prüfen** Retention, abgebrochene Jobs und doppelte Sicherungen untersuchen. 20. **Containerdaten prüfen** Images, Layer, Volumes, Bind-Mounts und Logs unterscheiden. 21. **Kubernetes-Ephemeralspeicher prüfen** Nodefs, Imagefs, Inodes, Limits und Evictions auswerten. 22. **Betriebssystembereiche prüfen** Updates, Dumps, Cache, temporäre Dateien und Papierkorb untersuchen. 23. **Hardware- und I/O-Fehler prüfen** Ereignisse, Kernelmeldungen und Storagezustand korrelieren. 24. **Hypothese und Gegenbeweis formulieren** Ursache vor jeder Änderung messbar beschreiben. 25. **Akutes Wachstum kontrollieren** Verursachenden Schreibprozess nur mit Freigabe drosseln oder stoppen. 26. **Minimale sichere Entlastung planen** Nur bestätigte, entbehrliche Daten auswählen. 27. **Eine Maßnahme durchführen** Nicht mehrere Variablen gleichzeitig verändern. 28. **Freien Speicher erneut messen** Absoluten Wert und Prozentwert dokumentieren. 29. **Ursprünglichen Schreibvorgang testen** Anwendung und nicht nur Diagnosewerkzeug prüfen. 30. **Weitere Ebenen verifizieren** Pool, Volume, Dateisystem und Anwendung erneut kontrollieren. 31. **Wachstum weiter beobachten** Prüfen, ob der Speicher sofort wieder abnimmt. 32. **Dauerhafte Ursache beheben** Rotation, Retention, Quota, Kapazität oder Anwendung korrigieren. 33. **Monitoring verbessern** Prozentwert, freien Absolutwert, Inodes und Wachstumsrate überwachen. 34. **Vorgang dokumentieren** Ursache, Maßnahme, Risiko, Ergebnis und Prävention festhalten. --- **7.13.35 Befundmatrix** | Befund | Mögliche Einordnung | Nächster Nachweis | |---|---|---| | `df` zeigt 100 %, `du` ebenfalls sehr hoch | sichtbare Dateien belegen das Dateisystem | größte Verzeichnisse bestimmen | | `df` zeigt 100 %, `du` deutlich weniger | offene gelöschte Dateien, Snapshots oder Metadaten | `lsof +L1` und Snapshotprüfung | | Blöcke frei, Inodes 100 % | zu viele Dateien | Verzeichnisse mit vielen kleinen Dateien bestimmen | | nur ein Benutzer betroffen | Benutzerquota | Quota des Benutzers prüfen | | nur ein Verzeichnis betroffen | FSRM-, Projekt- oder Anwendungsquota | wirksames Verzeichnislimit prüfen | | Dateisystem ist `read-only` | Dateisystem- oder Storagefehler | Kernel- und Ereignisprotokolle | | Root-Dateisystem voll | Logs, Cache, Container oder fehlender Mount | `/var`, `/tmp`, Docker und Mounts prüfen | | nach Loglöschung keine Freigabe | Datei wird noch geöffnet gehalten | `lsof +L1` | | Dockerhost voll | Images, Layer, Volumes oder Logs | `docker system df -v` | | Container meldet voll, Host nicht | Container-Layer, Volume oder Quota | Mounts und beschreibbaren Layer prüfen | | Kubernetes-Node zeigt `DiskPressure` | Nodefs, Imagefs oder Inodes knapp | Nodebeschreibung und Ereignisse | | PVC vorhanden, Anwendung meldet voll | Dateisystem innerhalb des PVC oder Storagequota | Volume im Pod und Backend prüfen | | Logical Volume hat Platz, Thin Pool ist voll | Thin Provisioning erschöpft | `lvs` mit Daten- und Metadatenprozent | | Dateien wurden gelöscht, Snapshotgröße steigt | Copy-on-Write hält alte Blöcke | Snapshotbelegung prüfen | | Windows-Volume voll, Verzeichnissumme kleiner | VSS, Systemdateien oder unzugängliche Bereiche | VSS und Systembereiche prüfen | | macOS zeigt widersprüchliche Werte | APFS-Container, Snapshots oder löschbarer Speicher | APFS-Container und Snapshots prüfen | | NAS-Freigabe voll, NAS-Pool hat Platz | Share-, Benutzer- oder Volumequota | Backendquota prüfen | | Speicher wächst sehr schnell | Fehlerschleife oder unkontrollierter Job | Änderungszeit und aktive Prozesse | | nach Bereinigung sofort wieder voll | Ursache weiterhin aktiv | Wachstumsquelle erneut messen | | I/O-Fehler zusätzlich zu wenig Speicher | Hardware- oder Pfadfehler | Storagezustand und Ereignisse | --- **7.13.36 Typische Diagnosefehler** - Nur den prozentualen Wert betrachten. - Den absolut freien Speicher nicht dokumentieren. - Inodes nicht prüfen. - Quotas nicht berücksichtigen. - Anwendungspfad und tatsächliches Dateisystem verwechseln. - Ein nicht eingebundenes Ziel übersehen. - `df` und `du` als identische Messungen behandeln. - Fehlende Berechtigungen bei rekursiven Suchen ignorieren. - Gelöschte offene Dateien übersehen. - Snapshots und Shadow Copies ignorieren. - Thin Provisioning nur im Gastbetriebssystem prüfen. - Container-Layer und Volume verwechseln. - PVC-Größe mit freiem Speicher gleichsetzen. - Protokolldatei löschen, ohne den schreibenden Prozess zu prüfen. - Aktive Datenbankprotokolle manuell löschen. - Docker-Volumes pauschal bereinigen. - Alle Snapshots vorsorglich entfernen. - Storagepool und Dateisystem gleichzeitig verändern. - Mehrere Bereinigungen gleichzeitig ausführen. - Keine Messung vor und nach der Maßnahme durchführen. - Einen Neustart als Speicherbereinigung verwenden. - Schreibschutz als reinen Kapazitätsfehler behandeln. - Hardwarefehler nach einer kurzfristigen Speicherfreigabe ignorieren. - Nur Platz freigeben, aber die Wachstumsursache nicht beheben. - Keine zukünftige Kapazitäts- und Retentionsplanung festlegen. --- **7.13.37 Verifikation** Nach der Maßnahme müssen mindestens folgende Punkte geprüft werden: - betroffener Pfad liegt auf dem erwarteten Dateisystem; - Dateisystem ist schreibbar; - ausreichender absoluter Speicher ist verfügbar; - prozentuale Auslastung liegt im vorgesehenen Bereich; - Inodes sind verfügbar; - wirksame Quotas sind korrekt; - Thin Pool besitzt freie Daten- und Metadatenkapazität; - Storage Pool und Backend besitzen Reserve; - Snapshots entsprechen der vorgesehenen Retention; - keine gelöschten großen Dateien werden weiterhin offengehalten; - Logrotation funktioniert; - Anwendung erzeugt keine unkontrollierte Datenmenge mehr; - Container startet ohne Neustartschleife; - Kubernetes-Node zeigt keinen `DiskPressure`; - Datenbank schreibt fehlerfrei; - Backup- und Replikationsdienste funktionieren; - keine neuen Dateisystem- oder I/O-Fehler erscheinen; - ursprünglicher Schreibvorgang funktioniert; - Wachstumsrate bleibt nach der Maßnahme kontrolliert; - Monitoring löst korrekt aus; - temporäre Änderungen wurden zurückgenommen; - Ursache und Prävention wurden dokumentiert. Ein einzelner erfolgreicher Schreibtest reicht nicht aus, wenn der Speicher weiterhin unkontrolliert wächst. --- **7.13.38 Prävention und Monitoring** Zu überwachen sind: - prozentuale Dateisystembelegung; - absolut freier Speicher; - Inodebelegung; - Wachstum pro Stunde und Tag; - Quotaauslastung; - Snapshotbelegung; - Thin-Pool-Datenbereich; - Thin-Pool-Metadatenbereich; - Container- und Imagebelegung; - Kubernetes `nodefs` und `imagefs`; - Backuprepository; - Datenbank- und Transaktionslogs; - Protokollverzeichnisse; - Storagepoolkapazität; - Hardware- und I/O-Fehler. Ein sinnvoller Alarm berücksichtigt nicht nur einen festen Prozentwert. Beispiel: ```text Warnung: Auslastung über organisationsspezifischem Grenzwert UND weniger als definierter absoluter Freispeicher Kritisch: Kapazität reicht bei aktueller Wachstumsrate nicht bis zum nächsten geplanten Eingriff ``` Zusätzliche Präventionsmaßnahmen: - Kapazitätsprognosen erstellen; - Retention verbindlich dokumentieren; - Logrotation regelmäßig testen; - Quotas mit Warnschwellen verwenden; - Snapshotlebenszyklen überwachen; - Thin Provisioning nicht überbuchen, ohne das Backend zu überwachen; - Containerlogs begrenzen; - Ephemeral-Storage-Requests und -Limits planen; - Backuprepository und Produktionsdaten getrennt überwachen; - Restore- und Bereinigungsvorgänge testen; - Eigentümer für speicherintensive Pfade festlegen. --- **7.13.39 Dokumentationsvorlage** ```text Störung: Zeitpunkt: Betroffenes System: Betroffene Anwendung: Betroffener Pfad: Speicherebenen: Dateisystem: Gesamtkapazität: Freier Speicher vor der Maßnahme: Inodebelegung: Wirksame Quota: Snapshotbelegung: Thin-Pool-Auslastung: Wachstumsrate: Größte Verbraucher: Gelöschte offene Dateien: Storage- und Hardwarezustand: Nachgewiesene Ursache: Gegenbeweis ausgeschlossen durch: Durchgeführte Maßnahme: Risiko und Rückweg: Freier Speicher nach der Maßnahme: Verifikation: Prävention: ``` --- **7.13.40 Checkliste** - [ ] exakte Fehlermeldung dokumentiert - [ ] Datum und Uhrzeit erfasst - [ ] betroffenen Host erfasst - [ ] betroffene Anwendung erfasst - [ ] betroffenen Benutzer erfasst - [ ] exakten Schreibpfad bestimmt - [ ] Dateisystem des Pfades bestimmt - [ ] Mountpoint oder Laufwerksbuchstabe bestätigt - [ ] Gesamtkapazität dokumentiert - [ ] absolut freien Speicher dokumentiert - [ ] prozentuale Auslastung dokumentiert - [ ] Inodes geprüft - [ ] Benutzerquota geprüft - [ ] Gruppenquota geprüft - [ ] Projekt- oder Verzeichnisquota geprüft - [ ] Anwendungsquota geprüft - [ ] Schreibschutz geprüft - [ ] Mountoptionen geprüft - [ ] Partition oder Logical Volume geprüft - [ ] Volume Group oder Speicherpool geprüft - [ ] Thin-Pool-Datenbereich geprüft - [ ] Thin-Pool-Metadatenbereich geprüft - [ ] RAID-, NAS- oder SAN-Kapazität geprüft - [ ] Snapshots geprüft - [ ] Shadow Copies geprüft - [ ] größte Verzeichnisse bestimmt - [ ] größte Dateien bestimmt - [ ] Änderungszeiten geprüft - [ ] Datenbesitzer bestimmt - [ ] Wachstumsrate bestimmt - [ ] viele kleine Dateien berücksichtigt - [ ] `df` und `du` verglichen - [ ] gelöschte offene Dateien geprüft - [ ] Protokollwachstum geprüft - [ ] Logrotation geprüft - [ ] Datenbanklogs geprüft - [ ] Backupretention geprüft - [ ] Container-Layer geprüft - [ ] Container-Volumes geprüft - [ ] Containerlogs geprüft - [ ] Kubernetes `DiskPressure` geprüft - [ ] Ephemeral Storage geprüft - [ ] PVC und Backend getrennt geprüft - [ ] System- und Kernelprotokolle geprüft - [ ] Hardware- und I/O-Fehler geprüft - [ ] Hypothese formuliert - [ ] Gegenbeweis festgelegt - [ ] Risiko und Rückweg dokumentiert - [ ] Datenverantwortlicher einbezogen - [ ] nur eine kontrollierte Maßnahme durchgeführt - [ ] freien Speicher erneut gemessen - [ ] Inodes erneut geprüft - [ ] Quota erneut geprüft - [ ] ursprünglichen Schreibvorgang getestet - [ ] ursprüngliche Anwendung getestet - [ ] Wachstumsrate nachkontrolliert - [ ] Monitoring geprüft - [ ] temporäre Änderungen zurückgenommen - [ ] Ursache dokumentiert - [ ] Präventionsmaßnahme festgelegt --- **7.13.41 Schnellreferenz** | Aufgabe | Befehl | |---|---| | Windows-Volumes | `Get-Volume` | | PowerShell-Dateisystemlaufwerke | `Get-PSDrive -PSProvider FileSystem` | | Windows-Datenträger | `Get-Disk` | | Windows-Partitionen | `Get-Partition` | | physische Windows-Speicherobjekte | `Get-PhysicalDisk` | | NTFS-Quota | `fsutil quota query C:` | | FSRM-Quotas | `Get-FsrmQuota` | | VSS-Speicher | `vssadmin list shadowstorage` | | Shadow Copies | `vssadmin list shadows` | | Windows-Komponentenspeicher | `Dism.exe /Online /Cleanup-Image /AnalyzeComponentStore` | | Linux-Dateisystembelegung | `df -hT` | | Linux-Pfad prüfen | `df -hT ` | | Linux-Inodes | `df -i` | | Mounts | `findmnt` | | Mount eines Pfades | `findmnt --target ` | | Blockgeräte | `lsblk -o NAME,TYPE,FSTYPE,SIZE,FSAVAIL,FSUSE%,MOUNTPOINTS` | | Verzeichnisgrößen | `du -x -h --max-depth=1 ` | | gelöschte offene Dateien | `lsof +L1` | | Journalbelegung | `journalctl --disk-usage` | | Benutzerquota | `quota -s` | | Quotaübersicht | `repquota -a` | | XFS-Quota | `xfs_quota -x -c 'report -h' ` | | LVM Physical Volumes | `pvs` | | LVM Volume Groups | `vgs` | | LVM und Thin Pools | `lvs -a -o lv_name,vg_name,lv_size,pool_lv,origin,data_percent,metadata_percent` | | Btrfs-Auslastung | `btrfs filesystem usage -T ` | | ZFS-Poolauslastung | `zpool list` | | ZFS-Datasetbelegung | `zfs list -o space` | | macOS-Dateisystembelegung | `df -h` | | macOS-Datenträger | `diskutil list` | | APFS-Struktur | `diskutil apfs list` | | APFS-Snapshots | `diskutil apfs listSnapshots /` | | lokale Time-Machine-Snapshots | `tmutil listlocalsnapshots /` | | Docker-Speicherübersicht | `docker system df -v` | | Docker-Containergrößen | `docker ps -a --size` | | Kubernetes-Nodes | `kubectl get nodes` | | Kubernetes-Nodezustand | `kubectl describe node ` | | Kubernetes-PVCs | `kubectl get pvc --all-namespaces` | --- **7.13.42 Quellen** **Offizielle Microsoft-Dokumentation** - [Microsoft Learn – Get-Volume](https://learn.microsoft.com/en-us/powershell/module/storage/get-volume) - [Microsoft Learn – Get-Disk](https://learn.microsoft.com/en-us/powershell/module/storage/get-disk) - [Microsoft Learn – Get-PhysicalDisk](https://learn.microsoft.com/en-us/powershell/module/storage/get-physicaldisk) - [Microsoft Learn – Get-PSDrive](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.management/get-psdrive) - [Microsoft Learn – Get-FsrmQuota](https://learn.microsoft.com/en-us/powershell/module/fileserverresourcemanager/get-fsrmquota) - [Microsoft Learn – FileServerResourceManager PowerShell module](https://learn.microsoft.com/en-us/powershell/module/fileserverresourcemanager/) - [Microsoft Learn – Vssadmin list shadowstorage](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/cc788045%28v%3Dws.11%29) - [Microsoft Learn – Determine the actual size of the WinSxS folder](https://learn.microsoft.com/en-us/windows-hardware/manufacture/desktop/determine-the-actual-size-of-the-winsxs-folder) - [Microsoft Learn – Clean up the WinSxS folder](https://learn.microsoft.com/en-us/windows-hardware/manufacture/desktop/clean-up-the-winsxs-folder) - [Microsoft Learn – Configure Storage Sense](https://learn.microsoft.com/en-us/windows/configuration/storage/storage-sense) **Offizielle Linux- und Projektdokumentation** - [GNU Coreutils – df invocation](https://www.gnu.org/software/coreutils/manual/html_node/df-invocation.html) - [GNU Coreutils – du invocation](https://www.gnu.org/software/coreutils/manual/html_node/du-invocation.html) - [systemd – journalctl](https://www.freedesktop.org/software/systemd/man/journalctl.html) - [systemd – journald.conf](https://www.freedesktop.org/software/systemd/man/journald.conf.html) - [Linux Kernel – ext4 documentation](https://docs.kernel.org/admin-guide/ext4.html) - [Red Hat – Disk Quotas](https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/7/html/storage_administration_guide/ch-disk-quotas) - [Red Hat – Limiting XFS storage usage with quotas](https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/8/html/managing_file_systems/assembly_limiting-storage-space-usage-on-xfs-with-quotas_managing-file-systems) - [Btrfs – btrfs-filesystem documentation](https://btrfs.readthedocs.io/en/latest/btrfs-filesystem.html) - [OpenZFS – zfs-list documentation](https://openzfs.github.io/openzfs-docs/man/master/8/zfs-list.8.html) **Offizielle Docker-Dokumentation** - [Docker Docs – docker system df](https://docs.docker.com/reference/cli/docker/system/df/) - [Docker Docs – Prune unused Docker objects](https://docs.docker.com/engine/manage-resources/pruning/) - [Docker Docs – docker system prune](https://docs.docker.com/reference/cli/docker/system/prune/) - [Docker Docs – docker volume prune](https://docs.docker.com/reference/cli/docker/volume/prune/) **Offizielle Kubernetes-Dokumentation** - [Kubernetes – Local ephemeral storage](https://kubernetes.io/docs/concepts/storage/ephemeral-storage/) - [Kubernetes – Node-pressure eviction](https://kubernetes.io/docs/concepts/scheduling-eviction/node-pressure-eviction/) - [Kubernetes – Ephemeral volumes](https://kubernetes.io/docs/concepts/storage/ephemeral-volumes/) **Offizielle Apple-Dokumentation** - [Apple – Get detailed information about a disk](https://support.apple.com/guide/disk-utility/get-detailed-information-about-a-disk-dskutl1005/mac) - [Apple – Add, delete or erase APFS volumes](https://support.apple.com/guide/disk-utility/add-delete-or-erase-apfs-volumes-dskua9e6a110/mac) - [Apple – View APFS snapshots](https://support.apple.com/guide/disk-utility/view-apfs-snapshots-dskuf82354dc/mac) - [Apple – Repair a storage device](https://support.apple.com/guide/disk-utility/repair-a-storage-device-dskutl1040/mac) Für diese Seite wurden keine Community-Berichte, Hersteller-Social-Media-Aussagen oder eigenen Laborergebnisse als Nachweis verwendet. # 7.14 TLS- oder HTTPS-Verbindung schlägt fehl **7.14.1 Ziel dieser Seite** Diese Seite beschreibt die systematische Diagnose, wenn eine TLS- oder HTTPS-Verbindung nicht aufgebaut werden kann, eine Zertifikatswarnung erscheint oder eine Anwendung erst nach dem TLS-Handshake fehlschlägt. Ziele der Diagnose: - DNS-, Netzwerk-, TCP-, TLS- und HTTP-Fehler voneinander trennen; - den tatsächlich verwendeten Zielhost und Port bestimmen; - Zertifikatsname, Gültigkeit, Vertrauenskette und Sperrstatus prüfen; - TLS-Versionen, Cipher Suites, SNI und ALPN untersuchen; - Serverauthentifizierung und gegenseitige TLS-Authentifizierung unterscheiden; - Proxy, TLS-Inspection, Reverse Proxy und Load Balancer berücksichtigen; - client-, server- und anwendungsspezifische Truststores vergleichen; - eine kontrollierte Maßnahme mit anschließender Verifikation durchführen. Eine erfolgreiche TCP-Verbindung zu Port `443` beweist noch nicht, dass TLS oder HTTPS funktioniert. --- **7.14.2 Sicherheitskennzeichnungen** | Kennzeichnung | Bedeutung | |---|---| | **LESEND** | erfasst ausschließlich Zustände und Messwerte | | **NETZAKTIV** | baut eine Verbindung auf oder ruft externe Ressourcen ab | | **SENSITIV** | kann Zertifikate, Header, interne Namen oder Sicherheitsinformationen anzeigen | | **ÄNDERND** | verändert Konfigurationen, Truststores oder Dienste | | **AUSFALLRISIKO** | kann bestehende TLS-Verbindungen oder Dienste unterbrechen | Grundregeln: - Private Schlüssel niemals in Tickets, Chats oder Diagnoseausgaben kopieren. - Private Schlüssel nicht per E-Mail oder ungeschützt übertragen. - `curl -k` beziehungsweise `--insecure` nicht als dauerhafte Lösung verwenden. - Zertifikatsprüfung nicht deaktivieren, um einen Fehler zu verdecken. - Keine veralteten TLS-Versionen dauerhaft aktivieren. - Keine CA-Zertifikate ungeprüft als vertrauenswürdig importieren. - Bestehende Zertifikatsbindungen vor Änderungen dokumentieren. - Bei Zertifikatswechseln immer Rückweg und Schlüsselzuordnung prüfen. - Diagnoseausgaben vor Weitergabe auf Tokens, Cookies, Header und interne Namen prüfen. - Netzwerkaufzeichnungen und TLS-Schlüsselprotokolle besonders schützen. --- **7.14.3 Vollständiger HTTPS-Verbindungspfad** ```text Anwendung → Proxykonfiguration → DNS-Auflösung → IPv4- oder IPv6-Zieladresse → Routing und Firewall → TCP-Verbindung → TLS ClientHello → SNI und ALPN → TLS ServerHello → Serverzertifikat und Zertifikatskette → Zertifikatsprüfung → optionales Clientzertifikat → verschlüsselte HTTP-Anfrage → Reverse Proxy oder Load Balancer → Backend → HTTP-Antwort ``` Jede Ebene kann einen eigenen Fehler verursachen. Eine Browsermeldung über HTTPS beweist nicht automatisch, dass das Zertifikat die Ursache ist. Der Fehler kann bereits bei DNS, TCP, Proxy, TLS-Version, SNI oder im Backend entstehen. --- **7.14.4 Fehlerklassen unterscheiden** | Fehlerklasse | Typischer Befund | |---|---| | DNS-Fehler | Zielname wird nicht oder falsch aufgelöst | | Routing- oder Firewallfehler | Zieladresse oder Port ist nicht erreichbar | | TCP-Fehler | Timeout, Verbindungsablehnung oder TCP Reset | | Proxyfehler | falscher Proxy, Authentifizierung oder blockierter CONNECT-Tunnel | | TLS-Protokollfehler | Client und Server finden keine gemeinsame TLS-Version | | Cipher-Fehler | keine gemeinsame Cipher Suite oder Signaturalgorithmus | | Zertifikatsnamenfehler | FQDN stimmt nicht mit dem SAN überein | | Gültigkeitsfehler | Zertifikat ist abgelaufen oder noch nicht gültig | | Vertrauensfehler | Root-CA wird nicht vertraut | | Kettenfehler | Intermediate-CA fehlt oder Kette kann nicht aufgebaut werden | | Sperrprüfungsfehler | CRL- oder OCSP-Prüfung schlägt fehl | | SNI-Fehler | Server liefert das Zertifikat eines falschen virtuellen Hosts | | ALPN-Fehler | HTTP/1.1, HTTP/2 oder anderes Anwendungsprotokoll wird falsch ausgehandelt | | mTLS-Fehler | Clientzertifikat fehlt, ist falsch oder wird nicht akzeptiert | | TLS-Inspection-Fehler | Proxy ersetzt das Serverzertifikat durch ein eigenes Zertifikat | | Serverkonfigurationsfehler | Zertifikat, Schlüssel, Bindung oder Listener ist fehlerhaft | | Reverse-Proxy-Fehler | Frontend-TLS funktioniert, Backend-TLS schlägt fehl | | HTTP-Fehler | TLS funktioniert, Server liefert aber einen HTTP-Fehlercode | | Anwendungsfehler | Browser funktioniert, bestimmte Anwendung jedoch nicht | | Truststore-Abweichung | Betriebssystem, Browser, Java oder Container vertraut unterschiedlichen CAs | --- **7.14.5 Typische Symptome und Fehlermeldungen** Mögliche Meldungen: ```text Certificate verify failed Unable to get local issuer certificate Unable to verify the first certificate Self-signed certificate Certificate has expired Certificate is not yet valid Hostname mismatch Unknown CA Bad certificate Certificate required Handshake failure Protocol version No shared cipher TLS alert Connection reset by peer Connection refused Operation timed out ERR_SSL_PROTOCOL_ERROR ERR_CERT_AUTHORITY_INVALID ERR_CERT_DATE_INVALID SEC_ERROR_UNKNOWN_ISSUER SSL_ERROR_NO_CYPHER_OVERLAP PKIX path building failed unable to find valid certification path The underlying connection was closed Could not establish trust relationship 502 Bad Gateway 503 Service Unavailable 504 Gateway Timeout ``` Die genaue Meldung, Anwendung, Uhrzeit und Clientplattform müssen dokumentiert werden. --- **7.14.6 Mindestinformationen erfassen** Vor der Diagnose sind festzuhalten: - vollständige URL; - verwendeter FQDN; - Port; - Client-IP-Adresse; - Ziel-IP-Adresse; - Zeitpunkt; - betroffene Anwendung; - Betriebssystem und Version; - Browser- oder Anwendungsversion; - Proxy- und VPN-Zustand; - erwarteter Zertifikatsaussteller; - erwarteter Reverse Proxy oder Load Balancer; - funktioniert HTTP ohne TLS? - funktioniert die Verbindung von anderen Clients? - funktioniert sie aus anderen Netzen? - trat der Fehler nach einer Änderung auf? - wurde kürzlich ein Zertifikat erneuert? - ist mTLS vorgesehen? - handelt es sich um öffentliches oder internes PKI-Vertrauen? Private Schlüssel, Passwörter, Sitzungscookies, API-Keys und Zugriffstokens gehören nicht in die Dokumentation. --- **7.14.7 TCP-, TLS- und HTTP-Fehler trennen** | Testebene | Erfolgsnachweis | |---|---| | DNS | vorgesehene A- oder AAAA-Adresse wird geliefert | | Netzwerk | Route zum vorgesehenen Ziel besteht | | TCP | Drei-Wege-Handshake mit Zielport funktioniert | | TLS | Handshake wird mit gemeinsamer Version und Cipher abgeschlossen | | Zertifikatsprüfung | Name, Gültigkeit, Kette und Vertrauen sind korrekt | | HTTP | gültige HTTP-Antwort wird empfangen | | Anwendung | ursprüngliche Funktion arbeitet vollständig | Mögliche Einordnung: ```text TCP schlägt fehl → noch kein TLS-Problem nachgewiesen TCP funktioniert, TLS schlägt fehl → TLS-Version, Cipher, SNI, Zertifikat oder mTLS prüfen TLS funktioniert, HTTP 502 erscheint → Reverse Proxy oder Backend prüfen HTTP 200 erscheint, Anwendung funktioniert nicht → Anwendungslogik, API, Cookie, Authentifizierung oder Inhalt prüfen ``` --- **7.14.8 DNS und Zieladresse prüfen** **Windows** ```powershell Resolve-DnsName ` -Name "app.example.test" ` -Type A ``` ```powershell Resolve-DnsName ` -Name "app.example.test" ` -Type AAAA ``` **Linux und macOS** ```bash dig app.example.test A ``` ```bash dig app.example.test AAAA ``` Zu prüfen sind: - richtige IPv4-Adresse; - richtige IPv6-Adresse; - internes oder öffentliches DNS; - Split-DNS; - VPN-DNS; - CNAME-Kette; - mehrere Zieladressen; - veralteter Cache; - CDN- oder Load-Balancer-Ziel; - Hosts-Datei; - DNS-Suffixe; - Anwendung mit eigenem Resolver. Wenn mehrere IP-Adressen vorhanden sind, müssen die tatsächlich verwendete Adresse und das Verhalten der einzelnen Ziele verglichen werden. --- **7.14.9 IPv4 und IPv6 getrennt testen** **NETZAKTIV** ```bash curl \ -4 \ -v \ https://app.example.test/ ``` ```bash curl \ -6 \ -v \ https://app.example.test/ ``` Möglicher Befund: - IPv4 funktioniert, IPv6 schlägt fehl; - einzelne IPv4-Adresse liefert ein falsches Zertifikat; - nur ein Load-Balancer-Node ist fehlerhaft; - IPv6 führt zu einem anderen Reverse Proxy; - DNS liefert eine veraltete Adresse. Ein scheinbarer TLS-Fehler kann durch einen fehlerhaften IPv6-Pfad oder ein falsch konfiguriertes Zielsystem verursacht werden. --- **7.14.10 TCP-Port prüfen** **Windows** ```powershell Test-NetConnection ` -ComputerName "app.example.test" ` -Port 443 ``` Wichtige Felder: ```text RemoteAddress RemotePort InterfaceAlias SourceAddress TcpTestSucceeded ``` **Linux und macOS** ```bash nc \ -vz \ app.example.test \ 443 ``` Alternativ kann bereits `curl -v` oder `openssl s_client` zum Aufbau der TCP-Verbindung verwendet werden. Mögliche Ergebnisse: | Ergebnis | Einordnung | |---|---| | Timeout | Firewall, Routing, Proxy oder nicht antwortender Server | | Connection refused | Ziel erreichbar, aber kein Listener oder aktive Ablehnung | | TCP Reset | Firewall, Load Balancer oder Dienst beendet Verbindung | | TCP erfolgreich | erst jetzt TLS-Handshake untersuchen | Ein erfolgreicher Ping beweist keine Erreichbarkeit von TCP-Port `443`. --- **7.14.11 Systemzeit und Zeitzone prüfen** Zertifikate besitzen einen Gültigkeitszeitraum: ```text Not Before Not After ``` Eine falsche Systemzeit kann ein gültiges Zertifikat als abgelaufen oder noch nicht gültig erscheinen lassen. **Windows** ```powershell Get-Date ``` ```cmd w32tm /query /status ``` ```cmd w32tm /query /source ``` **Linux** ```bash date ``` ```bash date -u ``` ```bash timedatectl status ``` **macOS** ```bash date ``` ```bash date -u ``` ```bash systemsetup -gettimezone ``` Zu prüfen sind: - Datum; - Uhrzeit; - Zeitzone; - UTC-Abweichung; - NTP-Quelle; - Synchronisationsstatus; - virtuelle Maschine mit fehlerhafter Hostzeitsynchronisation; - Containerzeit; - Domänenzeit; - kürzlich geänderte Uhr. --- **7.14.12 HTTPS mit `curl` prüfen** **NETZAKTIV, SENSITIV** ```bash curl \ --connect-timeout 10 \ --max-time 30 \ -v \ https://app.example.test/ ``` Die verbose Ausgabe kann zeigen: - verwendete Zieladresse; - Proxyverwendung; - TLS-Version; - Cipher Suite; - Zertifikatsbetreff; - Zertifikatsaussteller; - ALPN-Ergebnis; - HTTP-Anfrage; - HTTP-Statuscode; - Redirect; - Verbindungsabbruch. Verbose Ausgaben können sensible HTTP-Header enthalten und müssen vor Weitergabe geprüft werden. Nur die HTTP-Header anzeigen: ```bash curl \ -sS \ -D - \ -o /dev/null \ https://app.example.test/ ``` Einige Anwendungen unterstützen keine `HEAD`-Anfrage. Deshalb ist eine normale `GET`-Anfrage mit verworfener Antwort häufig aussagekräftiger als `curl -I`. --- **7.14.13 Zertifikatsprüfung testweise abgrenzen** **NUR ZUR DIAGNOSE, NICHT ALS LÖSUNG** ```bash curl \ -v \ -k \ https://app.example.test/ ``` Einordnung: | Normaler Test | Test mit `-k` | Einordnung | |---|---|---| | schlägt fehl | funktioniert | Zertifikatsvalidierung wahrscheinlich betroffen | | schlägt fehl | schlägt ebenfalls fehl | nicht nur Zertifikatsvertrauen betroffen | | funktioniert | funktioniert | kein aktueller Validierungsfehler | | funktioniert nur auf einem Client | anderer Client schlägt fehl | Truststore oder Anwendung unterscheidet sich | `-k` deaktiviert die Überprüfung des Serverzertifikats. Es behebt weder DNS-, TCP-, TLS-Version-, Cipher-, SNI-, ALPN- noch mTLS-Probleme zuverlässig. Die Option darf nicht in produktiven Skripten, Anwendungen oder dauerhaften Konfigurationen verbleiben. --- **7.14.14 Bestimmte IP-Adresse mit richtigem Hostnamen testen** Ein direkter Aufruf über eine IP-Adresse verändert häufig: - den geprüften Zertifikatsnamen; - SNI; - HTTP-Hostheader; - Auswahl des virtuellen Hosts. Deshalb sollte `curl --resolve` verwendet werden: ```bash curl \ -v \ --resolve \ app.example.test:443:192.0.2.25 \ https://app.example.test/ ``` Damit bleiben erhalten: - URL-Hostname; - SNI; - Zertifikatsnamenprüfung; - HTTP-Hostheader. Nur die Ziel-IP-Adresse wird für den Test festgelegt. Dies ist besonders nützlich bei: - mehreren Load-Balancer-Nodes; - DNS-Umstellungen; - fehlerhaftem Caching; - Blue-Green-Deployments; - alten und neuen Reverse Proxys; - einzelnen fehlerhaften Backendpfaden. --- **7.14.15 TLS-Handshake mit OpenSSL prüfen** **NETZAKTIV, SENSITIV** ```bash openssl s_client \ -connect app.example.test:443 \ -servername app.example.test \ -showcerts \ -verify_return_error \ -verify_hostname app.example.test \ ``` Zu prüfen sind: - tatsächlich verwendete Java-Version; - `java.home`; - Truststorepfad; - Truststoreformat; - Truststorepasswort; - Root- und Intermediate-CA; - Zertifikatsalias; - Gültigkeitszeitraum; - Anwendung mit eigenem Truststore; - Container besitzt anderen Java-Truststore; - JVM-Startparameter; - alte JVM ohne aktuelle CA-Liste. Ein Import in den Betriebssystem-Truststore behebt keinen Java-Fehler, wenn die Anwendung ausschließlich ihren eigenen Truststore verwendet. --- **7.14.35 Container separat prüfen** Der Host und ein Container können unterschiedliche besitzen: - DNS-Konfigurationen; - Proxyvariablen; - Systemzeiten; - CA-Bundles; - OpenSSL-Versionen; - TLS-Bibliotheken; - Java-Truststores; - IPv4- oder IPv6-Pfade; - Zertifikatsdateien. Containerkonfiguration: ```bash docker inspect \ ``` Proxyvariablen: ```bash docker exec \ \ env ``` Zeit im Container: ```bash docker exec \ \ date -u ``` Falls `curl` im Image vorhanden ist: ```bash docker exec \ \ curl \ -v \ https://app.example.test/ ``` Vergleich: ```text Test auf dem Host gegen Test im Container ``` Wenn nur der Container fehlschlägt, sind insbesondere CA-Bundle, Proxy, DNS, Netzwerknamespace und Anwendungslaufzeit zu prüfen. Produktive Images dürfen nicht spontan durch Installation zusätzlicher Diagnosepakete verändert werden. Falls Werkzeuge fehlen, ist ein freigegebener Diagnosecontainer oder ein reproduzierbares Testimage zu verwenden. --- **7.14.36 Serverzertifikat und privaten Schlüssel zuordnen** Zertifikat und privater Schlüssel müssen dasselbe Schlüsselpaar bilden. Öffentlichen Schlüssel des Zertifikats hashen: **LESEND** ```bash openssl x509 \ -in server.pem \ -pubkey \ -noout | openssl pkey \ -pubin \ -outform DER | openssl sha256 ``` Öffentlichen Anteil des privaten Schlüssels hashen: **SENSITIV – Zugriff auf privaten Schlüssel erforderlich** ```bash openssl pkey \ -in server.key \ -pubout \ -outform DER | openssl sha256 ``` Die beiden Hashwerte müssen übereinstimmen. Dieser Test gibt nicht den privaten Schlüssel aus. Der Zugriff auf die Schlüsseldatei bleibt dennoch sicherheitskritisch. Zu prüfen sind zusätzlich: - Dateipfad; - Dateiberechtigungen; - Dateibesitzer; - Verschlüsselung des Schlüssels; - Kennwortzugriff; - Dienstkonto; - Hardware Security Module; - Secret- oder Vault-Bereitstellung; - Zertifikatsbindung; - tatsächlich geladene Datei. --- **7.14.37 Nginx prüfen** Konfigurationssyntax: **LESEND** ```bash sudo nginx -t ``` Dienststatus: ```bash systemctl \ status nginx \ --no-pager ``` Protokolle: ```bash journalctl \ -u nginx \ --since "-2 hours" ``` Zu prüfen sind: - `listen 443 ssl`; - richtiger virtueller Host; - `server_name`; - Zertifikatspfad; - Schlüsselpfad; - vollständige Zertifikatskette; - Dateiberechtigungen; - SNI; - TLS-Protokolle; - Cipher-Konfiguration; - Clientzertifikatsanforderung; - OCSP-Konfiguration; - Reverse-Proxy-Backend; - Backend-SNI; - Backend-Zertifikatsprüfung; - kontrollierter Reload nach Änderung. Bei einer kombinierten Zertifikatsdatei steht gewöhnlich zuerst das Serverzertifikat, gefolgt von den erforderlichen Intermediate-Zertifikaten. --- **7.14.38 Apache HTTP Server prüfen** Konfigurationssyntax: **LESEND** ```bash sudo apachectl configtest ``` Alternativ, abhängig von der Installation: ```bash sudo httpd -t ``` Dienststatus: ```bash systemctl \ status apache2 \ --no-pager ``` oder: ```bash systemctl \ status httpd \ --no-pager ``` Zu prüfen sind: - SSL-Modul; - virtueller Host; - Port und Listener; - `ServerName`; - Zertifikatsdatei; - Schlüsseldatei; - Zertifikatskette; - Dateiberechtigungen; - TLS-Versionen; - Cipher; - Clientzertifikate; - Proxy zum Backend; - Protokolle; - kontrollierter Reload. Der genaue Dienstname und die Konfigurationspfade hängen von Distribution und Installation ab und dürfen nicht angenommen werden. --- **7.14.39 IIS-Bindungen prüfen** Falls das WebAdministration-Modul vorhanden ist: ```powershell Import-Module WebAdministration ``` HTTPS-Bindungen: ```powershell Get-WebBinding ` -Protocol https ``` SSL-Bindungen: ```powershell Get-ChildItem ` -Path IIS:\SslBindings ``` Zu prüfen sind: - IP-Adresse; - Port; - Hostname; - SNI-Einstellung; - Zertifikat-Thumbprint; - Zertifikatsspeicher; - privater Schlüssel; - Berechtigung des Dienstkontos; - abgelaufenes Zertifikat; - falsche Bindung; - mehrere Sites auf demselben Listener; - zentrale Zertifikatsspeicherung; - Clientzertifikatsanforderung. Ein gültiges Zertifikat im Windows-Zertifikatsspeicher beweist nicht, dass es an die richtige IIS-Site gebunden ist. --- **7.14.40 Reverse Proxy und Load Balancer getrennt prüfen** Mögliche TLS-Abschnitte: ```text Client → TLS zum Load Balancer → TLS zum Reverse Proxy → TLS zum Backend ``` Oder: ```text Client → TLS-Terminierung am Load Balancer → unverschlüsseltes HTTP zum Backend ``` Für jeden Abschnitt getrennt erfassen: - Zielhostname; - Ziel-IP-Adresse; - Port; - SNI; - Zertifikatsname; - ausstellende CA; - Truststore; - TLS-Version; - Cipher; - Clientzertifikat; - Healthcheck; - Timeout; - Backendstatus. Typische Fehler: - Frontendzertifikat korrekt, Backendzertifikat abgelaufen; - Load Balancer sendet falsches SNI; - Backendzertifikat gilt nicht für den internen Namen; - Proxy vertraut der internen CA nicht; - Healthcheck verwendet HTTP statt HTTPS; - Healthcheck verwendet IP-Adresse statt FQDN; - Backend erwartet mTLS; - nur ein Load-Balancer-Node besitzt das neue Zertifikat; - Zertifikatsverteilung ist unvollständig; - Proxy prüft Backendzertifikat nicht oder mit falschem Namen. Ein erfolgreicher externer TLS-Test prüft nicht automatisch die Verbindung vom Reverse Proxy zum Backend. --- **7.14.41 HTTP-Ebene nach erfolgreichem TLS prüfen** Wenn der TLS-Handshake erfolgreich ist, muss der HTTP-Statuscode ausgewertet werden. | Status | Mögliche Einordnung | |---|---| | `200` | Anfrage grundsätzlich erfolgreich | | `301` oder `302` | Redirectziel prüfen | | `400` | fehlerhafte Anfrage oder Hostheader | | `401` | Authentifizierung erforderlich oder fehlgeschlagen | | `403` | Zugriff verweigert | | `404` | Pfad oder virtueller Host falsch | | `405` | HTTP-Methode nicht erlaubt | | `408` | Request Timeout | | `421` | Anfrage beim falschen Ursprung oder falscher Verbindung | | `429` | Rate Limit | | `500` | Anwendungs- oder Serverfehler | | `502` | Proxy erreicht Backend nicht korrekt | | `503` | Dienst oder Backend nicht verfügbar | | `504` | Backend antwortet nicht rechtzeitig | Redirects verfolgen: ```bash curl \ -v \ -L \ https://app.example.test/ ``` Zu prüfen sind: - Redirect auf anderen Hostnamen; - Redirect auf abgelaufenes Zertifikat; - Wechsel zwischen internem und öffentlichem Namen; - HTTP-zu-HTTPS-Schleife; - falscher Port; - falsches Schema; - Proxyheader; - Hostheader; - Backendstatus; - Anwendungspfad. Ein HTTP-Fehlercode beweist, dass mindestens eine TLS-Verbindung bereits erfolgreich aufgebaut wurde. --- **7.14.42 Netzwerkaufzeichnung einsetzen** Eine Netzwerkaufzeichnung ist sinnvoll, wenn unklar bleibt: - ob TCP aufgebaut wird; - wer die Verbindung beendet; - ob ein Reset erscheint; - welches Ziel angesprochen wird; - ob Retransmissions auftreten; - ob ein TLS ClientHello gesendet wird; - welche TLS-Versionen angeboten werden; - ob SNI übermittelt wird; - ob ein TLS Alert erscheint; - ob der Server antwortet; - ob mehrere Verbindungsversuche erfolgen; - ob ein Proxy beteiligt ist. Bei TLS 1.3 sind größere Teile des Handshakes verschlüsselt als bei älteren Versionen. Mit Encrypted ClientHello kann auch der bisher sichtbare Servername geschützt werden. Für die Entschlüsselung moderner TLS-Sitzungen werden in der Regel autorisiert erfasste Sitzungsschlüssel benötigt. Ein Server-Private-Key allein reicht insbesondere bei modernen Schlüsselaustauschverfahren nicht zur nachträglichen Entschlüsselung. TLS-Schlüsselprotokolle und entschlüsselte Aufzeichnungen enthalten hochsensible Daten und müssen besonders geschützt, zeitlich begrenzt und anschließend sicher entfernt werden. --- **7.14.43 Hypothese und Gegenbeweis formulieren** Beispiel: ```text Hypothese: Der Reverse Proxy sendet beim Verbindungsaufbau zum Backend keinen passenden SNI-Namen und erhält deshalb das Default-Zertifikat eines anderen virtuellen Hosts. Erwarteter Befund: Der OpenSSL-Test gegen die Backend-IP liefert ohne SNI ein anderes Zertifikat als mit dem vorgesehenen SNI-Namen. Gegenbeweis: Mit und ohne SNI wird dasselbe korrekte Zertifikat geliefert und die Backendverbindung funktioniert. Testmethode: OpenSSL-Verbindungen mit identischer Ziel-IP und unterschiedlicher SNI-Übermittlung vergleichen. Erfolgskriterium: Das abweichende Zertifikat und der fehlerhafte Proxy-SNI-Pfad sind reproduzierbar nachgewiesen. ``` Eine belastbare Hypothese enthält: - betroffene Verbindungsebene; - vermutete Ursache; - erwarteten messbaren Befund; - Gegenbeweis; - Testmethode; - Risiko; - Erfolgskriterium. --- **7.14.44 Kontrollierte Maßnahmen** | Maßnahme | Voraussetzung | Risiko | |---|---|---| | Zertifikat erneuern | Ablauf oder falsche Gültigkeit bestätigt | falsche Bindung oder unvollständige Verteilung | | vollständige Kette konfigurieren | fehlendes Intermediate bestätigt | falsche Reihenfolge oder falsche CA | | Zertifikatsbindung korrigieren | falscher Listener oder virtueller Host bestätigt | andere Site kann betroffen sein | | SNI korrigieren | falsche Zertifikatsauswahl nachgewiesen | weitere virtuelle Hosts betroffen | | Backend-SNI korrigieren | Proxy sendet falschen Namen | Backendrouting ändert sich | | Truststore ergänzen | vorgesehene CA eindeutig bestätigt | zusätzliche CA erhält Vertrauensstatus | | Systemzeit korrigieren | Zeitabweichung bestätigt | Kerberos, Tokens und Logs betroffen | | TLS-Policy korrigieren | fehlende gemeinsame sichere Version bestätigt | ältere Clients können ausfallen | | Cipher-Policy korrigieren | fehlende sichere Schnittmenge bestätigt | Kompatibilität und Sicherheit betroffen | | Clientzertifikat erneuern | mTLS-Zertifikat fehlerhaft | Identitätszuordnung kann ausfallen | | Proxyregel korrigieren | falscher Proxyweg bestätigt | weitere Anwendungen betroffen | | TLS-Inspection-Ausnahme | Inspection als Ursache bestätigt und freigegeben | Sicherheitskontrolle wird verändert | | Reverse-Proxy-Backend korrigieren | Backend-TLS-Fehler bestätigt | Dienstunterbrechung möglich | | Dienst kontrolliert neu laden | neue Konfiguration geprüft | kurze Unterbrechung oder Ladefehler | | Load-Balancer-Nodes synchronisieren | abweichende Zertifikate bestätigt | mehrere produktive Nodes betroffen | Vor der Maßnahme sind zu dokumentieren: - Ausgangszustand; - aktives Zertifikat; - SHA-256-Fingerprint; - Zertifikatsbindung; - Servername; - SNI; - TLS-Version; - Cipher; - Truststore; - Proxyweg; - Risiko; - Rückweg; - Erfolgskriterium. --- **7.14.45 Nicht zulässige Schnelllösungen** ```text Zertifikatsprüfung dauerhaft deaktivieren curl -k in produktive Skripte übernehmen verify=false in Anwendungen eintragen NODE_TLS_REJECT_UNAUTHORIZED=0 setzen Java-Hostnameprüfung deaktivieren beliebige Root-CA importieren selbst signiertes Zertifikat ungeprüft vertrauen private Schlüssel weitergeben private Schlüssel in Containerimages einbauen alte TLS-Versionen pauschal aktivieren unsichere Cipher dauerhaft aktivieren Sperrprüfung ohne Risikoanalyse abschalten Truststore vollständig ersetzen alle Zertifikate aus Stores löschen Schannel-Registrywerte nach ungeprüfter Anleitung ändern Reverse Proxy ohne Konfigurationstest neu starten Zertifikat nur auf einem Load-Balancer-Node austauschen TLS-Inspection heimlich umgehen ``` Eine funktionierende Verbindung ohne Zertifikatsprüfung ist kein Nachweis einer sicheren oder korrekten Lösung. --- **7.14.46 Vollständiger Diagnoseablauf** 1. **Exakte Fehlermeldung aufnehmen** Wortlaut, Anwendung, Client und Uhrzeit dokumentieren. 2. **Vollständige URL bestimmen** Schema, FQDN, Port und Pfad erfassen. 3. **Fehlerumfang bestimmen** Einzelnen Client, Anwendung, Standort oder alle Benutzer unterscheiden. 4. **Letzte Änderungen erfassen** Zertifikatswechsel, Update, Proxy-, DNS- oder Firewalländerung prüfen. 5. **Systemzeit prüfen** Datum, UTC, Zeitzone und Synchronisation bestätigen. 6. **DNS-Auflösung prüfen** A, AAAA und CNAME auswerten. 7. **Tatsächliche Zieladresse bestimmen** IPv4, IPv6, Load Balancer oder Proxy identifizieren. 8. **TCP-Port prüfen** Timeout, Ablehnung und erfolgreichen Handshake unterscheiden. 9. **Proxyweg bestimmen** Direktverbindung, expliziten Proxy, PAC oder TLS-Inspection unterscheiden. 10. **Normalen HTTPS-Test durchführen** Zertifikatsprüfung nicht deaktivieren. 11. **TLS und HTTP trennen** Handshakefehler und HTTP-Statuscode unterscheiden. 12. **OpenSSL-Handshake durchführen** SNI und Hostnamenprüfung ausdrücklich angeben. 13. **TLS-Version dokumentieren** Ausgehandelte Version erfassen. 14. **Cipher dokumentieren** Ausgehandelte Cipher Suite erfassen. 15. **ALPN dokumentieren** HTTP/1.1, HTTP/2 oder anderes Protokoll bestimmen. 16. **Serverzertifikat dokumentieren** Subject, Issuer, Seriennummer und Fingerprint erfassen. 17. **SAN prüfen** Aufgerufenen FQDN mit Zertifikat vergleichen. 18. **Gültigkeitszeitraum prüfen** Server- und Intermediate-Zertifikate berücksichtigen. 19. **Zertifikatskette prüfen** Fehlende oder falsche Intermediate-CA bestimmen. 20. **Root-Vertrauen prüfen** Tatsächlichen Truststore der Anwendung untersuchen. 21. **Sperrprüfung prüfen** CRL, OCSP, AIA und Netzwerkzugriff berücksichtigen. 22. **SNI prüfen** Test mit und ohne vorgesehenen Servernamen vergleichen. 23. **Einzelne Zieladressen prüfen** Load-Balancer-Nodes mit `--resolve` vergleichen. 24. **IPv4 und IPv6 vergleichen** Unterschiedliche Pfade und Zertifikate bestimmen. 25. **mTLS prüfen** Clientzertifikat, Schlüssel, Kette und Serververtrauen untersuchen. 26. **TLS-Inspection prüfen** Zertifikatsaussteller und Fingerprint zwischen Netzen vergleichen. 27. **Anwendungsspezifischen Truststore prüfen** Betriebssystem, Browser, Java und Container unterscheiden. 28. **Serverbindung prüfen** Listener, virtuellen Host, Zertifikat und Schlüssel zuordnen. 29. **Zertifikat und Schlüssel vergleichen** Öffentliche Schlüssel sicher hashen. 30. **Reverse Proxy und Backend trennen** Frontend- und Backend-TLS einzeln testen. 31. **Serverprotokolle auswerten** Handshake, Zertifikat, mTLS und Backendfehler korrelieren. 32. **Bei Bedarf Netzwerkaufzeichnung durchführen** Nur autorisiert, begrenzt und datenschutzkonform. 33. **Hypothese und Gegenbeweis formulieren** Ursache vor der Änderung messbar festlegen. 34. **Eine kontrollierte Maßnahme durchführen** Risiko, Rückweg und Freigabe beachten. 35. **Konfiguration vor Reload prüfen** Beispielsweise `nginx -t` oder `apachectl configtest`. 36. **Identischen TLS-Test wiederholen** Version, Cipher, Zertifikat und Verify-Ergebnis vergleichen. 37. **HTTP-Antwort prüfen** Statuscode, Redirect und Header auswerten. 38. **Ursprüngliche Anwendung testen** Nicht nur `curl` oder OpenSSL verifizieren. 39. **Weitere Clients und Netze prüfen** Repräsentative Systeme vergleichen. 40. **Temporäre Diagnoseänderungen zurücknehmen** Logging, Capture, Testzertifikate und Ausnahmen entfernen. 41. **Ursache dokumentieren** Fehlerhafte Ebene und technischer Nachweis festhalten. 42. **Prävention festlegen** Monitoring, automatische Erneuerung und Konfigurationstest verbessern. --- **7.14.47 Befundmatrix** | Befund | Mögliche Einordnung | Nächster Nachweis | |---|---|---| | DNS schlägt fehl | Namensauflösung | direkte A- und AAAA-Abfrage | | TCP-Port `443` nicht erreichbar | Routing, Firewall oder Listener | Netzwerkpfad und Serverseite | | TCP funktioniert, kein ServerHello | TLS-Policy, Proxy oder Server | Handshake und Serverlogs | | `curl -k` funktioniert, normaler Test nicht | Zertifikatsvalidierung | Name, Kette, Zeit und Vertrauen | | Hostname mismatch | falsches Zertifikat oder falscher Name | SAN und SNI prüfen | | Zertifikat abgelaufen | Erneuerung oder falscher Node | alle Zieladressen vergleichen | | Zertifikat noch nicht gültig | Systemzeit oder falsches Zertifikat | Zeit und Gültigkeitsbeginn | | unbekannte CA | Root fehlt oder TLS-Inspection | Issuer und Truststore | | lokale CA im Browser vertraut, Java nicht | separater Java-Truststore | `keytool -list` | | Kette unvollständig | Intermediate fehlt | `-showcerts` und `openssl verify` | | nur ein Client betroffen | lokaler Truststore, Zeit oder Proxy | anderen Client vergleichen | | nur ein Load-Balancer-Node betroffen | Zertifikatsverteilung unvollständig | `curl --resolve` | | ohne SNI falsches Zertifikat | namensbasierter virtueller Host | Test mit korrektem SNI | | mit SNI ebenfalls falsches Zertifikat | falsche Bindung oder Serverregel | Listenerkonfiguration | | TLS 1.2 funktioniert, TLS 1.3 nicht | TLS-1.3-Pfad oder Intermediär | Proxy und Serverpolicy | | TLS 1.3 funktioniert, alter Client nicht | veralteter Client | Clientbibliothek und TLS-Version | | keine gemeinsame Cipher | Policy- oder Algorithmuskonflikt | Client- und Serverlisten vergleichen | | Browser funktioniert, Dienst nicht | Proxy, Store oder Systemkonto | Dienstkontext prüfen | | Host funktioniert, Container nicht | CA-Bundle, Proxy oder DNS | Test im Container | | Frontend-TLS funktioniert, HTTP 502 | Backend nicht erreichbar oder Backend-TLS | Proxy- und Backendlogs | | HTTP 504 | Backendtimeout | Backendpfad und Antwortzeit | | Clientzertifikat erforderlich | mTLS | Zertifikat und Schlüssel prüfen | | `unknown ca` am Server bei mTLS | Server vertraut Client-CA nicht | Server-Truststore | | nur hinter Security-Proxy fehlerhaft | TLS-Inspection | Zertifikatsaussteller vergleichen | | OCSP- oder CRL-Fehler | Sperrprüfungsziel nicht erreichbar | AIA/CDP und Proxy prüfen | | neuer Fingerprint nur auf manchen Nodes | unsynchronisierte Zertifikate | alle Nodes einzeln prüfen | | HTTP 200, Anwendung fehlerhaft | oberhalb von TLS | Anwendung, Authentifizierung und Inhalt | --- **7.14.48 Typische Diagnosefehler** - HTTPS sofort als reines Zertifikatsproblem behandeln. - DNS und TCP nicht zuerst prüfen. - Ping als Port- oder TLS-Nachweis verwenden. - Direkten IP-Aufruf als vollständigen HTTPS-Test verwenden. - SNI beim OpenSSL-Test vergessen. - Hostnamenprüfung nicht ausdrücklich durchführen. - Nur das Serverzertifikat, aber nicht die Kette prüfen. - Nur das Ablaufdatum des Leaf-Zertifikats prüfen. - Intermediate- und Root-Zertifikat verwechseln. - Root-CA unnötig mit der Serverkette ausliefern. - Subject prüfen, aber SAN ignorieren. - Wildcard-Zertifikat zu weit auslegen. - Systemzeit nicht prüfen. - `curl -k` als Lösung verwenden. - Browser und Anwendung denselben Truststore unterstellen. - Benutzer- und Computerzertifikatsspeicher verwechseln. - Java-Truststore ignorieren. - Container-CA-Bundle ignorieren. - Proxykontext des Dienstkontos nicht prüfen. - TLS-Inspection nicht berücksichtigen. - IPv4 und IPv6 nicht getrennt testen. - Nur einen Load-Balancer-Node prüfen. - Frontend- und Backend-TLS verwechseln. - mTLS nicht von normalem TLS unterscheiden. - Clientzertifikat ohne privaten Schlüssel verwenden. - Zertifikat und privaten Schlüssel nicht zuordnen. - Zertifikatsdatei ersetzen, aber Dienst nicht kontrolliert neu laden. - Dienst neu starten, ohne vorher die Konfiguration zu testen. - TLS-Version und Cipher Suite gleichsetzen. - HTTP-Statuscode als TLS-Fehler behandeln. - Sperrprüfung ohne Ursachenanalyse deaktivieren. - Private Schlüssel in Diagnoseausgaben aufnehmen. - Verbose Ausgaben mit Tokens oder Cookies ungeschützt weitergeben. - Mehrere TLS-Einstellungen gleichzeitig verändern. - Nur das Diagnosewerkzeug, aber nicht die Anwendung verifizieren. --- **7.14.49 Verifikation** Nach einer Maßnahme müssen mindestens folgende Punkte geprüft werden: - DNS liefert die vorgesehenen Adressen; - IPv4 und IPv6 funktionieren wie vorgesehen; - TCP-Port ist erreichbar; - richtiger Proxyweg wird verwendet; - TLS-Handshake wird abgeschlossen; - vorgesehene TLS-Version wird ausgehandelt; - sichere gemeinsame Cipher Suite wird verwendet; - SNI enthält den richtigen Namen; - ALPN liefert das vorgesehene Protokoll; - Serverzertifikat besitzt den richtigen SAN; - Zertifikat ist aktuell gültig; - vollständige Zertifikatskette wird geliefert; - Client vertraut der vorgesehenen Root-CA; - Sperrprüfung funktioniert; - bei mTLS wird das richtige Clientzertifikat verwendet; - privater Schlüssel ist vorhanden und geschützt; - Zertifikat und Schlüssel gehören zusammen; - alle Load-Balancer-Nodes liefern dasselbe Zertifikat; - Reverse Proxy vertraut dem Backend; - Backend-SNI ist korrekt; - keine neuen Schannel-, CAPI2- oder Serverfehler entstehen; - HTTP-Antwortcode entspricht dem Sollzustand; - Redirects führen zum vorgesehenen Host; - ursprüngliche Anwendung funktioniert; - repräsentative Clients funktionieren; - Container und Dienste funktionieren in ihrem tatsächlichen Kontext; - temporäre Ausnahmen wurden entfernt; - Fingerprint, Ablaufdatum und Erneuerungsweg wurden dokumentiert. Ein erfolgreicher Test mit deaktivierter Zertifikatsprüfung ist keine gültige Verifikation. --- **7.14.50 Prävention und Monitoring** Zu überwachen sind: - Ablaufdatum des Serverzertifikats; - Ablaufdatum der Intermediate-CA; - Ablaufdatum der Root-CA; - Zertifikatsname und SAN; - SHA-256-Fingerprint; - vollständige Zertifikatskette; - Erreichbarkeit des HTTPS-Endpunkts; - TLS-Handshake; - TLS-Version; - Zertifikatsaussteller; - OCSP- und CRL-Erreichbarkeit; - automatische Zertifikatserneuerung; - Verteilung auf alle Nodes; - Reload des betroffenen Dienstes; - Frontend- und Backend-TLS; - mTLS-Clientzertifikate; - Proxy- und Inspection-Zertifikate; - Systemzeit; - Konfigurationssyntax; - HTTP-Statuscode und Antwortzeit. Empfohlener Zertifikatsprozess: ```text Erneuerung anfordern → Zertifikat und Kette validieren → Zertifikat und Schlüssel zuordnen → Testsystem oder einzelnen Node aktualisieren → Konfiguration prüfen → Dienst kontrolliert neu laden → externen TLS-Test durchführen → alle Nodes aktualisieren → Monitoring und Fingerprint prüfen → altes Zertifikat kontrolliert entfernen ``` Die Erneuerung gilt erst als erfolgreich, wenn der produktive Listener das neue Zertifikat tatsächlich ausliefert. --- **7.14.51 Dokumentationsvorlage** ```text Störung: Zeitpunkt: Betroffener Client: Betroffene Anwendung: URL: FQDN: Port: Aufgelöste Adressen: Verwendete Zieladresse: Proxyweg: TCP-Ergebnis: TLS-Version: Cipher Suite: SNI: <übermittelter Name> ALPN: Zertifikat-Subject: Subject Alternative Names: Issuer: Seriennummer: SHA-256-Fingerprint: Gültigkeit: Zertifikatskette: Truststore: Sperrprüfung: mTLS: Reverse-Proxy-Pfad: HTTP-Ergebnis: Nachgewiesene Ursache: Gegenbeweis ausgeschlossen durch: Durchgeführte Maßnahme: Risiko und Rückweg: Verifikation: Prävention: ``` --- **7.14.52 Checkliste** - [ ] exakte Fehlermeldung dokumentiert - [ ] Datum und Uhrzeit erfasst - [ ] vollständige URL erfasst - [ ] FQDN erfasst - [ ] Port erfasst - [ ] betroffene Anwendung erfasst - [ ] Clientbetriebssystem erfasst - [ ] Systemzeit geprüft - [ ] Zeitzone geprüft - [ ] DNS-A-Eintrag geprüft - [ ] DNS-AAAA-Eintrag geprüft - [ ] CNAME-Kette geprüft - [ ] tatsächliche Zieladresse bestimmt - [ ] IPv4 getestet - [ ] IPv6 getestet - [ ] TCP-Port geprüft - [ ] Timeout und Ablehnung unterschieden - [ ] Proxykonfiguration geprüft - [ ] PAC-Datei berücksichtigt - [ ] `NO_PROXY` berücksichtigt - [ ] TLS-Inspection berücksichtigt - [ ] normalen HTTPS-Test durchgeführt - [ ] Zertifikatsprüfung nicht dauerhaft deaktiviert - [ ] OpenSSL-Handshake durchgeführt - [ ] SNI ausdrücklich angegeben - [ ] Hostnamenprüfung durchgeführt - [ ] TLS-Version dokumentiert - [ ] Cipher Suite dokumentiert - [ ] ALPN dokumentiert - [ ] Serverzertifikat erfasst - [ ] Subject geprüft - [ ] SAN geprüft - [ ] Wildcard-Gültigkeit geprüft - [ ] Issuer geprüft - [ ] Seriennummer dokumentiert - [ ] SHA-256-Fingerprint dokumentiert - [ ] Gültigkeitsbeginn geprüft - [ ] Ablaufdatum geprüft - [ ] Serverzertifikatskette geprüft - [ ] Intermediate-CA geprüft - [ ] Root-CA geprüft - [ ] tatsächlichen Truststore bestimmt - [ ] CRL geprüft - [ ] OCSP geprüft - [ ] AIA-Erreichbarkeit geprüft - [ ] Sperrprüfungsrichtlinie berücksichtigt - [ ] einzelne Load-Balancer-Nodes verglichen - [ ] Test mit `curl --resolve` durchgeführt - [ ] mTLS-Anforderung geprüft - [ ] Clientzertifikat geprüft - [ ] Client-CA-Vertrauen geprüft - [ ] privater Schlüssel vorhanden - [ ] Zertifikat und Schlüssel zugeordnet - [ ] Windows-Schannel-Ereignisse geprüft - [ ] CAPI2 bei Bedarf geprüft - [ ] Windows-Zertifikatsspeicher geprüft - [ ] Linux- oder macOS-Truststore geprüft - [ ] Java-Truststore bei Bedarf geprüft - [ ] Container-Truststore bei Bedarf geprüft - [ ] Reverse-Proxy-Frontend geprüft - [ ] Reverse-Proxy-Backend geprüft - [ ] Backend-SNI geprüft - [ ] Webserverkonfiguration getestet - [ ] Serverprotokolle ausgewertet - [ ] HTTP-Statuscode dokumentiert - [ ] Redirects geprüft - [ ] Hypothese formuliert - [ ] Gegenbeweis festgelegt - [ ] Risiko und Rückweg dokumentiert - [ ] nur eine kontrollierte Maßnahme durchgeführt - [ ] identischen TLS-Test wiederholt - [ ] ursprüngliche Anwendung getestet - [ ] weitere Clients geprüft - [ ] alle Load-Balancer-Nodes geprüft - [ ] temporäre Ausnahmen entfernt - [ ] sensible Diagnoseinformationen geschützt - [ ] Ursache dokumentiert - [ ] Präventionsmaßnahme festgelegt --- **7.14.53 Schnellreferenz** | Aufgabe | Befehl | |---|---| | Windows-DNS | `Resolve-DnsName app.example.test` | | Linux/macOS-DNS | `dig app.example.test A` | | Windows-TCP-Test | `Test-NetConnection app.example.test -Port 443` | | HTTPS-Diagnose | `curl -v https://app.example.test/` | | IPv4-Test | `curl -4 -v https://app.example.test/` | | IPv6-Test | `curl -6 -v https://app.example.test/` | | bestimmte IP mit richtigem Hostnamen | `curl -v --resolve app.example.test:443:192.0.2.25 https://app.example.test/` | | TLS-Handshake | `openssl s_client -connect app.example.test:443 -servername app.example.test curl -v https://app.example.test/` | | Nginx-Konfigurationstest | `nginx -t` | | Apache-Konfigurationstest | `apachectl configtest` | | IIS-HTTPS-Bindungen | `Get-WebBinding -Protocol https` | --- **7.14.54 Quellen** **Offizielle Microsoft-Dokumentation** - [Microsoft Learn – Overview of TLS and Schannel SSP](https://learn.microsoft.com/en-us/windows-server/security/tls/what-s-new-in-tls-ssl-schannel-ssp-overview) - [Microsoft Learn – TLS registry settings](https://learn.microsoft.com/en-us/windows-server/security/tls/tls-registry-settings) - [Microsoft Learn – Troubleshooting SSL-related IIS server-certificate issues](https://learn.microsoft.com/en-us/troubleshoot/developer/webapps/iis/www-authentication-authorization/troubleshooting-ssl-related-issues-server-certificate) - [Microsoft Learn – Certificate Provider](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.security/about/about_certificate_provider) - [Microsoft Learn – Certutil](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/certutil) - [Microsoft Learn – Valid root CA certificates are untrusted](https://learn.microsoft.com/en-us/troubleshoot/windows-server/certificates-and-public-key-infrastructure-pki/valid-root-ca-certificates-untrusted) - [Microsoft Learn – Diagnostic logging for PKI and SSL certificate issues](https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/diagnostic-logging-troubleshoot-workplace-join-issues) **Offizielle OpenSSL-Dokumentation** - [OpenSSL – s_client](https://docs.openssl.org/3.5/man1/openssl-s_client/) - [OpenSSL – x509](https://docs.openssl.org/3.5/man1/openssl-x509/) - [OpenSSL – verify](https://docs.openssl.org/3.5/man1/openssl-verify/) - [OpenSSL – Certificate verification options](https://docs.openssl.org/3.5/man1/openssl-verification-options/) - [OpenSSL – Command overview](https://docs.openssl.org/3.5/man1/) **Offizielle curl-Dokumentation** - [curl – Command-line manual](https://curl.se/docs/manpage.html) - [curl – TLS certificate verification](https://curl.se/docs/sslcerts.html) - [curl – SSL ciphers](https://curl.se/docs/ssl-ciphers.html) - [curl – Tutorial](https://curl.se/docs/tutorial.html) - [curl – HTTP scripting](https://curl.se/docs/httpscripting.html) **Offizielle Webserver-Dokumentation** - [Nginx – Configuring HTTPS servers](https://nginx.org/en/docs/http/configuring_https_servers.html) - [Nginx – HTTP SSL module](https://nginx.org/en/docs/http/ngx_http_ssl_module.html) - [Nginx – HTTP proxy module](https://nginx.org/en/docs/http/ngx_http_proxy_module.html) - [Apache HTTP Server – Configuration files and configtest](https://httpd.apache.org/docs/2.4/configuring.html) - [Apache HTTP Server – apachectl](https://httpd.apache.org/docs/current/programs/apachectl.html) **Offizielle Java-Dokumentation** - [Oracle – keytool](https://docs.oracle.com/en/java/javase/21/docs/specs/man/keytool.html) - [Oracle – JSSE Reference Guide](https://docs.oracle.com/javase/8/docs/technotes/guides/security/jsse/JSSERefGuide.html) **Offizielle Wireshark-Dokumentation** - [Wireshark – User’s Guide](https://www.wireshark.org/docs/wsug_html/) - [Wireshark – TShark manual](https://www.wireshark.org/docs/man-pages/tshark.html) - [Wireshark – Exporting TLS session keys](https://www.wireshark.org/docs/wsug_html_chunked/ChIOExportSection.html) **Standards** - [RFC 5280 – Internet X.509 Public Key Infrastructure Certificate and CRL Profile](https://www.rfc-editor.org/rfc/rfc5280) - [RFC 6066 – TLS Extensions: Server Name Indication](https://www.rfc-editor.org/rfc/rfc6066) - [RFC 7301 – TLS Application-Layer Protocol Negotiation](https://www.rfc-editor.org/rfc/rfc7301) - [RFC 8446 – TLS 1.3](https://www.rfc-editor.org/rfc/rfc8446) - [RFC 9110 – HTTP Semantics](https://www.rfc-editor.org/rfc/rfc9110) - [RFC 9113 – HTTP/2](https://www.rfc-editor.org/rfc/rfc9113) - [RFC 9325 – Recommendations for Secure Use of TLS and DTLS](https://www.rfc-editor.org/rfc/rfc9325) - [RFC 9525 – Service Identity in TLS](https://www.rfc-editor.org/rfc/rfc9525) Für diese Seite wurden keine Community-Berichte, Hersteller-Social-Media-Aussagen oder eigenen Laborergebnisse als Nachweis verwendet. # 7.15 Backupjob ist fehlgeschlagen **7.15.1 Ziel dieser Seite** Diese Seite beschreibt die systematische Diagnose, wenn ein Backupjob: - nicht gestartet wurde; - abgebrochen ist; - nur teilweise erfolgreich war; - kein verwendbares Recovery Point erzeugt hat; - ein inkonsistentes Backup erstellt hat; - das Zielrepository nicht erreichen konnte; - wegen Snapshot-, VSS-, Netzwerk-, Kapazitäts- oder Berechtigungsfehlern gescheitert ist; - als erfolgreich angezeigt wird, dessen Daten aber nicht wiederhergestellt werden können. Ziele der Diagnose: - den betroffenen Job und Sicherungszeitraum bestimmen; - Scheduler-, Quell-, Snapshot-, Transport- und Zielfehler unterscheiden; - Voll-, inkrementelle und differenzielle Sicherungsketten prüfen; - Repository, Retention, Verschlüsselung und Unveränderbarkeit berücksichtigen; - anwendungskonsistente Backups sicherstellen; - die Wiederherstellbarkeit durch einen kontrollierten Restore-Test nachweisen; - RPO und RTO bewerten; - erneute Backupfehler verhindern. Ein Backupjob gilt nicht allein deshalb als erfolgreich, weil ein Prozess mit Exit-Code `0` beendet wurde oder eine Sicherungsdatei vorhanden ist. --- **7.15.2 Sicherheitskennzeichnungen** | Kennzeichnung | Bedeutung | |---|---| | **LESEND** | erfasst ausschließlich Zustände und Messwerte | | **NETZAKTIV** | greift auf Quell- oder Zielsysteme zu | | **LASTERZEUGEND** | kann Netzwerk, CPU, Arbeitsspeicher oder Storage stark belasten | | **ÄNDERND** | verändert Job-, Repository- oder Sicherungszustände | | **LÖSCHEND** | entfernt Recovery Points oder Repositorydaten | | **SENSITIV** | kann Zugangsdaten, Schlüssel oder geschützte Daten betreffen | | **AUSFALLRISIKO** | kann Sicherungen, Wiederherstellungen oder Produktivdienste unterbrechen | Grundregeln: - Fehlgeschlagene Jobs, Protokolle und Statusdaten zuerst dokumentieren. - VSS-Writer unmittelbar nach dem Fehler prüfen, bevor Dienste neu gestartet werden. - Keine Recovery Points löschen, um kurzfristig Speicher freizugeben. - Repositorys nicht ungeprüft entsperren. - Retention oder Pruning nicht spontan verändern. - Keine privaten Schlüssel, Repositorypasswörter oder Tokens in Diagnoseausgaben aufnehmen. - Eine beschädigte Sicherungskette nicht durch manuelle Dateiänderungen „reparieren“. - Produktive Datenbanken nicht durch unkoordinierte Dateikopien sichern. - Restore-Tests nur in einem isolierten Ziel durchführen. - Bei Ransomwareverdacht die Sicherungsumgebung nicht unkontrolliert verändern. --- **7.15.3 Ein Backup ist erst durch Wiederherstellung nachgewiesen** Ein technisch vollständiger Backupablauf besteht aus mehreren Nachweisen: ```text Job wurde geplant → Job wurde tatsächlich gestartet → Quelle wurde vollständig erfasst → konsistenter Sicherungszeitpunkt wurde erzeugt → Daten wurden übertragen → Daten wurden im Repository gespeichert → Metadaten und Katalog wurden geschrieben → Recovery Point wurde registriert → Integritätsprüfung war erfolgreich → Wiederherstellung wurde getestet → wiederhergestellte Anwendung funktioniert ``` Nicht ausreichend sind allein: - „Job erfolgreich“; - vorhandene Backupdatei; - belegter Speicher im Repository; - vorhandener Snapshot; - erfolgreiche Datenübertragung; - gültige Prüfsumme einer einzelnen Datei; - erfolgreiches Einlesen des Katalogs. --- **7.15.4 Wichtige Begriffe** | Begriff | Bedeutung | |---|---| | Vollbackup | enthält den vollständigen ausgewählten Datenbestand | | inkrementelles Backup | enthält Änderungen seit der letzten relevanten Sicherung | | differenzielles Backup | enthält Änderungen seit dem letzten Vollbackup | | synthetisches Vollbackup | wird im Repository aus vorhandenen Sicherungsdaten erzeugt | | Snapshot | zeitpunktbezogener Zustand eines Volumes oder Dateisystems | | crash-konsistent | entspricht ungefähr dem Zustand nach einem unerwarteten Ausfall | | anwendungskonsistent | Anwendung und Datenbank wurden für den Sicherungspunkt koordiniert | | Recovery Point | für die Wiederherstellung registrierter Sicherungsstand | | Repository | logischer Speicherbereich für Backups und Metadaten | | Retention | Aufbewahrungsregel für Recovery Points | | Immutability | zeitlich begrenzter Schutz vor Änderung oder Löschung | | Air Gap | logische oder physische Trennung der Sicherung vom Produktivsystem | | RPO | maximal tolerierbarer Datenverlust in Zeit | | RTO | maximal tolerierbare Wiederherstellungsdauer | | Backupfenster | vorgesehener Zeitraum für die Sicherung | | Restore-Test | kontrollierter Nachweis der Wiederherstellbarkeit | Ein Storage-Snapshot auf demselben System ist allein kein vollständiger Schutz vor Ausfall, Fehlbedienung, Diebstahl oder Ransomware. --- **7.15.5 Phasen eines Backupjobs** | Phase | Mögliche Fehler | |---|---| | Planung | falscher Zeitplan, deaktivierter Job, verpasster Start | | Vorbereitung | Konfiguration, Lizenz, Agent oder Dienst fehlerhaft | | Authentifizierung | Kennwort, Token, Zertifikat oder Schlüssel abgelaufen | | Quellenprüfung | Pfad, Volume, VM, Datenbank oder Container fehlt | | Snapshot | VSS-, LVM-, CSI-, Hypervisor- oder Storagefehler | | Anwendungskonsistenz | Writer, Datenbank oder Quiescing schlägt fehl | | Lesen | Berechtigung, Sperre, I/O-Fehler oder beschädigte Datei | | Transport | DNS, Routing, VPN, Firewall, TLS oder Timeout | | Schreiben | Repository voll, Quota, Schreibschutz oder Berechtigung | | Deduplizierung | Index-, Cache- oder Metadatenfehler | | Katalogisierung | Recovery Point wird nicht registriert | | Verifikation | Prüfsumme oder Strukturprüfung schlägt fehl | | Retention | alte Recovery Points werden nicht korrekt verarbeitet | | Replikation | sekundäre oder externe Kopie wird nicht erstellt | | Abschluss | Jobstatus, Benachrichtigung oder Monitoring ist falsch | Der erste sichtbare Fehler ist nicht immer die ursprüngliche Ursache. Ein später Repositoryfehler kann beispielsweise durch einen vorher fehlgeschlagenen Snapshot ausgelöst worden sein. --- **7.15.6 Fehlerklassen unterscheiden** | Fehlerklasse | Typischer Befund | |---|---| | Job nicht gestartet | kein Lauf, kein Log oder nur Schedulerfehler | | Job deaktiviert | Zeitplan vorhanden, Ausführung aber abgeschaltet | | falscher Dienstkontext | manueller Start funktioniert, geplanter Lauf nicht | | Agent nicht erreichbar | Backupserver erreicht Client oder Proxy nicht | | Quellpfad fehlt | Volume, Freigabe, Mount oder PVC nicht vorhanden | | Zugriff verweigert | Dienstkonto darf Quelle oder Ziel nicht lesen beziehungsweise schreiben | | Snapshot fehlgeschlagen | VSS-, Hypervisor-, CSI- oder Storagefehler | | Anwendung nicht konsistent | Datenbank-Writer oder Quiescing fehlerhaft | | Repository voll | zu wenig Speicher, Quota oder Thin Pool voll | | Repository nicht erreichbar | DNS-, Netzwerk-, TLS- oder Mountfehler | | Repository gesperrt | paralleler Job oder verwaister Lock | | Sicherungskette beschädigt | erforderliches Voll- oder Inkrementbackup fehlt | | Retention fehlerhaft | alte Daten bleiben bestehen oder benötigte Punkte werden entfernt | | Verschlüsselung fehlerhaft | Schlüssel, Passwort oder KMS nicht verfügbar | | Prüfsummenfehler | Daten oder Repository beschädigt | | Timeout | Job überschreitet Backupfenster oder Netzwerkgrenze | | Teilbackup | einige Quellen oder Dateien wurden übersprungen | | Katalogfehler | Daten vorhanden, Recovery Point jedoch nicht nutzbar | | Replikation fehlgeschlagen | Primärbackup vorhanden, Zweitkopie fehlt | | Immutability-Konflikt | gewünschte Änderung oder Retention wird blockiert | | Lizenz- oder Kapazitätslimit | geschützte Systeme oder Datenmenge überschreiten Produktlimit | | Sicherheitsvorfall | Repository, Zugangsdaten oder Backupserver wurden manipuliert | --- **7.15.7 Typische Symptome und Fehlermeldungen** ```text Backup failed Job failed Partial success Completed with warnings Missed schedule Access denied Authentication failed Permission denied Repository unavailable Repository is full Quota exceeded No space left on device Snapshot creation failed VSS writer failed VSS_E_WRITERERROR Unable to create snapshot Volume not found Source path not found Connection timed out Connection reset TLS certificate verify failed Repository locked Stale lock Checksum mismatch Hash mismatch Corrupt backup Index damaged Catalog update failed Retention failed Prune failed Unable to decrypt Encryption key not found Object lock prevents deletion Backup window exceeded Incremental chain is broken Recovery point unavailable Restore validation failed ``` Die exakte Meldung einschließlich Fehlercode, Jobphase und Uhrzeit muss übernommen werden. --- **7.15.8 Sofortmaßnahmen** 1. Fehlermeldung vollständig dokumentieren. 2. Job-ID, Jobname und Sicherungsprodukt erfassen. 3. Start- und Endzeit bestimmen. 4. Letzten erfolgreichen Recovery Point feststellen. 5. Betroffene Quellen und Ziele bestimmen. 6. RPO-Verletzung berechnen. 7. Aktuelle Logs und Ereignisse sichern. 8. Snapshot- oder VSS-Zustand prüfen. 9. Repository nicht bereinigen oder entsperren. 10. Prüfen, ob noch ein Job aktiv ist. 11. Kapazität und Quota erfassen. 12. Bei Sicherheitsverdacht Backupserver und Repository schützen. 13. Ursache nachweisen, bevor der Job erneut gestartet wird. 14. Nach der Korrektur einen kontrollierten neuen Lauf durchführen. 15. Wiederherstellbarkeit des neuen Recovery Points testen. Wiederholte Neustarts eines Backupjobs können: - zusätzliche Snapshots erzeugen; - Repositorylocks verursachen; - Backupfenster überschreiten; - Bandbreite und Storage belasten; - fehlerhafte inkrementelle Ketten verlängern; - verwertbare Beweise überschreiben. --- **7.15.9 RPO und aktuelle Schutzlücke bestimmen** Beispiel: ```text Letzter erfolgreicher Recovery Point: 01.08.2026 22:00 Uhr Aktueller Zeitpunkt: 02.08.2026 10:00 Uhr Aktuelle Schutzlücke: 12 Stunden Vorgesehenes RPO: 4 Stunden Ergebnis: RPO ist bereits verletzt. ``` Zu dokumentieren sind: - letzter erfolgreicher Job; - letzter erfolgreich verifizierter Recovery Point; - letzter extern replizierter Recovery Point; - letzter Restore-Test; - aktueller Zeitpunkt; - Änderungsrate der Produktivdaten; - maximal tolerierbarer Datenverlust; - Priorität des betroffenen Systems. Ein erfolgreicher Job nach der Störung beseitigt nicht rückwirkend die bereits entstandene RPO-Verletzung. --- **7.15.10 Job und Scheduler unter Windows prüfen** Geplanten Task anzeigen: **LESEND** ```powershell Get-ScheduledTask ` -TaskName "" ``` Laufzeitinformationen: ```powershell Get-ScheduledTask ` -TaskName "" | Get-ScheduledTaskInfo ``` Wichtige Felder: ```text State LastRunTime LastTaskResult NextRunTime NumberOfMissedRuns ``` Detaillierte Abfrage mit `schtasks`: ```cmd schtasks /query /tn "" /v /fo LIST /hresult ``` Zu prüfen sind: - Task aktiviert; - richtiger Trigger; - letzte Laufzeit; - nächster Lauf; - verpasste Läufe; - letzter Rückgabecode; - ausführendes Konto; - „Unabhängig von der Benutzeranmeldung ausführen“; - „Mit höchsten Privilegien ausführen“; - Recht „Anmelden als Stapelverarbeitungsauftrag“; - Arbeitsverzeichnis; - Argumente; - Netzwerkverfügbarkeit; - Ablauf des Kennworts; - geändertes Dienstkonto; - Laufzeitbegrenzung; - parallele Ausführung; - Verhalten nach verpasstem Start. Ein gemapptes Netzlaufwerk der interaktiven Benutzersitzung steht einem geplanten Task nicht automatisch zur Verfügung. Für geplante Jobs sollte der tatsächlich erreichbare UNC-Pfad verwendet werden. --- **7.15.11 Windows-Task-Scheduler-Ereignisse prüfen** Vorhandene Ereignisse: ```powershell Get-WinEvent ` -LogName "Microsoft-Windows-TaskScheduler/Operational" ` -MaxEvents 100 | Select-Object ` TimeCreated, Id, LevelDisplayName, Message ``` Das Operational-Protokoll kann deaktiviert sein. Eine Aktivierung ist eine Konfigurationsänderung und muss dokumentiert werden. Zu korrelieren sind: - Triggerzeit; - Start der Aktion; - Prozess-ID; - Rückgabecode; - Abbruch; - Zeitüberschreitung; - Berechtigungsfehler; - fehlender Benutzerkontext; - mehrfacher Jobstart; - Beendigung durch Task Scheduler. --- **7.15.12 Systemd-Timer unter Linux prüfen** Timerübersicht: **LESEND** ```bash systemctl list-timers --all ``` Bestimmten Timer prüfen: ```bash systemctl \ status backup.timer \ --no-pager ``` Zugehörigen Dienst prüfen: ```bash systemctl \ status backup.service \ --no-pager ``` Letzten Exit-Code erfassen: ```bash systemctl show \ backup.service \ -p Result \ -p ExecMainCode \ -p ExecMainStatus \ -p ActiveEnterTimestamp \ -p ActiveExitTimestamp ``` Protokolle: ```bash journalctl \ -u backup.timer \ -u backup.service \ --since "-24 hours" ``` Zu prüfen sind: - Timer aktiviert; - Timer tatsächlich geladen; - letzter und nächster Lauf; - `OnCalendar`; - `Persistent`; - zufällige Verzögerung; - zugehörige Service-Unit; - Exit-Code; - Timeout; - Benutzerkontext; - Umgebungsvariablen; - Arbeitsverzeichnis; - Netzwerkabhängigkeiten; - Secretbereitstellung; - paralleler Lauf; - System war zum geplanten Zeitpunkt ausgeschaltet. --- **7.15.13 Cronjobs prüfen** Cronjobs des aktuellen Benutzers: ```bash crontab -l ``` Cronjobs von `root`: ```bash sudo crontab -l ``` Systemweite Konfigurationen können abhängig von der Distribution unter anderem liegen in: ```text /etc/crontab /etc/cron.d/ /etc/cron.hourly/ /etc/cron.daily/ /etc/cron.weekly/ /etc/cron.monthly/ ``` Zu prüfen sind: - richtiger Benutzer; - korrekte Zeitangabe; - Zeitzone; - vollständige Programmpfade; - reduzierte `PATH`-Variable; - Arbeitsverzeichnis; - Shell; - Standardausgabe und Fehlerausgabe; - Zugangsdaten; - gemountete Dateisysteme; - parallele Prozesse; - Exit-Code; - Job wurde durch einen anderen Lauf blockiert; - Server war ausgeschaltet. Ein Skript, das in einer interaktiven Shell funktioniert, muss nicht unter Cron funktionieren. --- **7.15.14 Quelle und Sicherungsumfang prüfen** Zu erfassen sind: - vorgesehene Quellen; - tatsächlich eingeschlossene Quellen; - Ausschlüsse; - Dateisystemgrenzen; - Mountpoints; - Volumes; - virtuelle Maschinen; - Container-Volumes; - Datenbanken; - Systemzustand; - Anwendungsdaten; - Konfigurationen; - Secrets; - Zertifikate; - Berechtigungen und ACLs. Linux-Mounts: ```bash findmnt ``` ```bash lsblk \ -o NAME,TYPE,FSTYPE,SIZE,FSAVAIL,FSUSE%,MOUNTPOINTS ``` Windows-Volumes: ```powershell Get-Volume ``` Datei- oder Verzeichnisexistenz: ```powershell Test-Path ` -LiteralPath "" ``` Mögliche Fehler: - Mount fehlt und leeres Verzeichnis wird gesichert; - Laufwerksbuchstabe hat sich geändert; - neue Partition wurde nicht in den Job aufgenommen; - Ausschlussregel ist zu breit; - symbolischer Link wird nicht verfolgt; - Dateisystemgrenze wird nicht überschritten; - Containerdaten liegen in einem anderen Volume; - neuer Datenbankpfad fehlt; - verschlüsseltes Volume ist nicht entsperrt; - Quelldateien werden durch eine Anwendung gesperrt; - Dienstkonto darf neue Verzeichnisse nicht lesen. Ein erfolgreicher Job kann trotzdem unvollständig sein, wenn der Sicherungsumfang falsch definiert ist. --- **7.15.15 Kapazität, Inodes und Quotas prüfen** **Windows** ```powershell Get-Volume | Select-Object ` DriveLetter, FileSystemLabel, FileSystem, Size, SizeRemaining, HealthStatus ``` **Linux** ```bash df -hT ``` ```bash df -i ``` **macOS** ```bash df -h ``` Zu prüfen sind: - freier Speicher auf der Quelle; - temporärer Snapshotbereich; - Cache- und Stagingbereich; - Repositorykapazität; - Dateisystem-Inodes; - Benutzer- oder Verzeichnisquota; - Object-Storage-Quota; - Cloudkontingent; - Thin Pool; - Deduplizierungsmetadaten; - Katalogdatenbank; - Logvolume; - sekundäres Replikationsziel. Ein Backup kann trotz freiem Repository fehlschlagen, wenn der lokale Snapshot-, Cache-, Katalog- oder Temp-Bereich voll ist. --- **7.15.16 Windows Server Backup prüfen** Status eines laufenden Backups: **LESEND** ```cmd wbadmin get status ``` Vorhandene Backupversionen: ```cmd wbadmin get versions ``` Verfügbare Datenträger: ```cmd wbadmin get disks ``` Vorhandene Windows-Server-Backup-Dienste: ```powershell Get-Service ` -Name wbengine,VSS,swprv ` -ErrorAction SilentlyContinue ``` Backup- und VSS-Ereignisse: ```powershell Get-WinEvent ` -FilterHashtable @{ LogName = "Application" StartTime = (Get-Date).AddHours(-12) } | Where-Object { $_.ProviderName -in @( "Microsoft-Windows-Backup", "VSS" ) } | Select-Object ` TimeCreated, ProviderName, Id, LevelDisplayName, Message ``` Zu prüfen sind: - vorhandene Recovery Points; - Jobstatus; - Sicherungsziel; - Quellvolumes; - System-State-Komponenten; - VSS-Fehler; - Zielkapazität; - Zugriff auf Netzwerkziel; - Berechtigungen; - Datenträgerstatus; - Katalog; - Ausschlüsse; - parallele Sicherungssoftware. `wbadmin start backup` startet einen neuen Sicherungsvorgang und ist kein rein diagnostischer Befehl. --- **7.15.17 VSS systematisch prüfen** VSS-Writer unmittelbar nach dem Fehler prüfen: **LESEND** ```cmd vssadmin list writers ``` VSS-Provider: ```cmd vssadmin list providers ``` Shadow-Copy-Speicher: ```cmd vssadmin list shadowstorage ``` Vorhandene Shadow Copies: ```cmd vssadmin list shadows ``` Ein gesunder Writer zeigt gewöhnlich: ```text State: Stable Last error: No error ``` Zu prüfen sind: - Name des fehlgeschlagenen Writers; - Writer-ID; - Writer-Instanz-ID; - Writerzustand; - letzter Fehler; - betroffene Anwendung; - VSS-Provider; - Shadow-Copy-Speicher; - freier Speicher; - parallele Backupsoftware; - Zeitüberschreitung; - Systemlast; - Anwendung mit eigenem Writer; - Datenbank- oder Hypervisorintegration. Ein einzelner fehlerhafter Writer kann den gesamten anwendungskonsistenten Backupjob stoppen. Der pauschale Neustart aller VSS-Dienste ist keine erste Diagnosemaßnahme. Zuerst muss der betroffene Writer dokumentiert und dem zugehörigen Dienst oder Produkt zugeordnet werden. --- **7.15.18 Snapshot und Anwendungskonsistenz unterscheiden** Mögliche Sicherungsarten: | Sicherungsart | Eigenschaften | |---|---| | Dateikopie im laufenden Betrieb | kann bei aktiven Datenbanken inkonsistent sein | | crash-konsistenter Snapshot | entspricht ungefähr einem ungeplanten Ausfall | | anwendungskonsistenter Snapshot | Anwendung bestätigt konsistenten Zustand | | logisches Datenbankbackup | exportiert Daten über Datenbankwerkzeuge | | physisches Datenbankbackup | sichert Datenbankdateien mit vorgesehenem Verfahren | | Hypervisor-Snapshot | sichert VM-Zustand, ersetzt aber nicht automatisch ein Backup | | Storage-Snapshot | liegt häufig auf demselben Storage und benötigt zusätzliche Kopie | Zu prüfen sind: - Anwendung unterstützt Snapshotkoordination; - Writer oder Hook wurde ausgeführt; - Datenbank wurde gequiesced; - Transaktionslogs sind enthalten; - WAL-, Redo- oder Binärlogs sind verfügbar; - Snapshot wurde korrekt aufgelöst; - Hypervisor-Snapshot wurde konsolidiert; - Storage-Snapshot wurde repliziert; - mehrere Volumes wurden gleichzeitig konsistent erfasst; - Restoreverfahren ist dokumentiert. --- **7.15.19 Netzwerkpfad zum Repository prüfen** Zu bestimmen sind: - Repositoryhostname; - Ziel-IP-Adresse; - Port; - Protokoll; - Proxy; - VPN; - Routing; - Firewall; - DNS; - TLS; - Netzwerkfreigabe; - Objektstorage-Endpunkt; - Backup-Gateway oder Proxyserver. **Windows** ```powershell Resolve-DnsName ` -Name "" ``` ```powershell Test-NetConnection ` -ComputerName "" ` -Port ``` SMB-Verbindungen: ```powershell Get-SmbConnection ``` **Linux und macOS** ```bash getent hosts ``` ```bash findmnt ``` HTTPS-Endpunkt: ```bash curl \ -v \ https:/// ``` TLS-Test: ```bash openssl s_client \ -connect : \ -servername \ ``` Wichtige Regeln: - `forget` verändert Snapshotreferenzen; - `prune` entfernt nicht mehr referenzierte Daten; - `prune` kann lange dauern; - während Wartungsvorgängen kann das Repository gesperrt sein; - ein Lock darf nicht automatisch mit `unlock` entfernt werden; - nach Pruning ist eine Integritätsprüfung sinnvoll; - beschädigte Snapshots dürfen nicht ohne vorherige Sicherung und Ursachenanalyse repariert werden. --- **7.15.26 Rsync-Job prüfen** Version: ```bash rsync --version ``` Trockenlauf: **LESEND, NETZAKTIV, möglicherweise LASTERZEUGEND** ```bash rsync \ --dry-run \ --itemize-changes \ \ ``` Unmittelbar nach dem Job den Exit-Code ausgeben: ```bash printf '%s\n' "$?" ``` Wichtige Rsync-Exit-Codes: | Exit-Code | Bedeutung | |---:|---| | `0` | erfolgreich | | `1` | Syntax- oder Verwendungsfehler | | `2` | Protokollinkompatibilität | | `3` | Fehler bei Auswahl von Ein- oder Ausgabedateien | | `5` | Client-Server-Protokoll konnte nicht gestartet werden | | `10` | Socket-I/O-Fehler | | `11` | Datei-I/O-Fehler | | `12` | Fehler im Rsync-Protokolldatenstrom | | `23` | teilweise Übertragung wegen Fehler | | `24` | teilweise Übertragung, weil Quelldateien verschwanden | | `30` | Timeout bei Datenübertragung | | `35` | Timeout beim Warten auf Daemonverbindung | Zu prüfen sind: - vollständige Quelle und Ziel; - SSH- oder Daemonverbindung; - Berechtigungen; - Eigentümer und Gruppen; - ACLs; - erweiterte Attribute; - Hardlinks; - Sparse Files; - symbolische Links; - Dateisystemgrenzen; - Ausschlüsse; - teilweise Übertragungen; - gelöschte Quelldateien; - Protokollausgabe; - Exit-Code; - verwendete Optionen. `rsync --delete` kann Daten am Ziel löschen. Eine Synchronisation mit `--delete` ist allein kein versioniertes Backup. --- **7.15.27 macOS und Time Machine prüfen** Time-Machine-Status: **LESEND** ```bash tmutil status ``` Konfigurierte Ziele: ```bash tmutil destinationinfo ``` Letztes Backup: ```bash tmutil latestbackup ``` Vorhandene Backups: ```bash tmutil listbackups ``` Aktuelle Time-Machine-Protokolle: ```bash log show \ --predicate 'process == "backupd"' \ --last 6h \ --style compact ``` Speicherzustand: ```bash df -h ``` Backupvolume: ```bash diskutil info "" ``` Zu prüfen sind: - Backupziel angeschlossen; - Netzwerkziel erreichbar; - Volume eingebunden; - freier Speicher auf Quelle und Ziel; - Verschlüsselungskennwort verfügbar; - VPN oder Sicherheitssoftware beeinflusst Verbindung; - Backupvolume unterstützt; - lokale Snapshots; - beschädigtes Backup; - häufig geänderte große Dateien; - Synchronisationsdienst blockiert Dateien; - Mac ist entsperrt; - Stromversorgung; - Ruhezustand; - aktuelle macOS-Version. Netzwerkbasierte Time-Machine-Backups können über das Time-Machine-Menü mit gedrückter Wahltaste und **„Backups überprüfen“** verifiziert werden. Das Löschen oder Neuformatieren des Backupziels ist keine erste Diagnosemaßnahme. --- **7.15.28 Docker-Backups prüfen** Containerübersicht: ```bash docker ps -a ``` Volumes: ```bash docker volume ls ``` Bestimmtes Volume: ```bash docker volume inspect \ ``` Containermounts: ```bash docker inspect \ --format '{{json .Mounts}}' \ ``` Zu unterscheiden sind: - Containerimage; - beschreibbarer Container-Layer; - benanntes Volume; - anonymes Volume; - Bind-Mount; - externe Datenbank; - Docker-Compose-Konfiguration; - Secrets; - Umgebungsvariablen; - Zertifikate; - Netzwerk- und Proxykonfiguration. Wichtige Regeln: - `docker export` sichert keine eingebundenen Volumes. - `docker commit` sichert keine Daten in eingebundenen Volumes. - Daten in Volumes müssen separat gesichert werden. - Eine Kopie eines aktiven Datenbankvolumes ist nicht automatisch anwendungskonsistent. - Compose-Datei, Umgebungsvariablen und Secrets müssen getrennt und sicher berücksichtigt werden. - Direktes Manipulieren der Daten unter dem Docker-Datenverzeichnis ist nicht unterstützt und kann Daten beschädigen. - Vor dem Backup einer Datenbank muss deren vorgesehenes Sicherungsverfahren verwendet werden. Ein erfolgreicher Export des Containers beweist nicht, dass die persistenten Anwendungsdaten enthalten sind. --- **7.15.29 Kubernetes-Backupjobs prüfen** CronJobs: ```bash kubectl get cronjobs \ --all-namespaces ``` Jobs: ```bash kubectl get jobs \ --all-namespaces ``` Bestimmten Job untersuchen: ```bash kubectl describe job \ \ -n ``` Podlogs: ```bash kubectl logs \ job/ \ -n ``` Ereignisse: ```bash kubectl get events \ --all-namespaces \ --sort-by=.metadata.creationTimestamp ``` PVCs: ```bash kubectl get pvc \ --all-namespaces ``` VolumeSnapshots: ```bash kubectl get volumesnapshot \ --all-namespaces ``` VolumeSnapshotContents: ```bash kubectl get volumesnapshotcontent ``` Zu prüfen sind: - CronJob ausgesetzt; - letzter Zeitplan; - fehlgeschlagene Jobs; - Pod-Exit-Code; - BackoffLimit; - aktive Deadline; - ServiceAccount; - RBAC; - Secret; - Repositoryzugriff; - PVC-Mount; - CSI-Treiber; - VolumeSnapshotClass; - `readyToUse`; - Snapshotfehler; - Node-Druck; - Ephemeral Storage; - Netzwerkpolicy; - externe Datenbank; - S3- oder Object-Storage-Zugang; - Aufbewahrung alter Jobs. Ein Kubernetes-Backup muss je nach Wiederherstellungsziel berücksichtigen: - Kubernetes-Objekte; - Namespaces; - Deployments und StatefulSets; - Services und Ingress; - ConfigMaps; - Secrets; - CRDs und benutzerdefinierte Ressourcen; - Persistent Volumes; - externe Datenbanken; - Images und Registryabhängigkeiten; - Clusterkonfiguration; - gegebenenfalls etcd. Ein CSI-VolumeSnapshot ist nicht automatisch anwendungskonsistent und nicht automatisch außerhalb des ursprünglichen Storagebackends geschützt. --- **7.15.30 Datenbanken korrekt sichern** Aktive Datenbanken dürfen nicht wie gewöhnliche statische Dateien behandelt werden. Zu unterscheiden sind: - logisches Backup; - physisches Backup; - anwendungskonsistenter Snapshot; - Transaktionslogs; - Point-in-Time Recovery; - Replikation; - dateibasierte Offlinekopie. Zu prüfen sind: - Datenbankverbindung; - Backupbenutzer; - Berechtigung; - Lock- und Transaktionszustand; - verfügbare WAL-, Redo- oder Binärlogs; - Logarchivierung; - Backupmodus; - Datenbankversion; - Verschlüsselung; - Komprimierung; - freier Speicher; - Konsistenzprüfung; - Restoreversion; - Abhängigkeit zu vorherigen Backups. --- **7.15.31 PostgreSQL-Backups prüfen** PostgreSQL unterstützt unterschiedliche Verfahren: - `pg_dump` für logische Sicherungen; - `pg_dumpall` für clusterweite logische Objekte; - `pg_basebackup` für physische Basissicherungen; - WAL-Archivierung für Point-in-Time Recovery; - `pg_verifybackup` zur Prüfung eines von `pg_basebackup` erzeugten Backups. Basissicherung prüfen: **LESEND, LASTERZEUGEND** ```bash pg_verifybackup \ ``` Zu prüfen sind: - Backupmanifest; - erforderliche WAL-Dateien; - Replikationsberechtigung; - `pg_hba.conf`; - erreichbarer PostgreSQL-Port; - `max_wal_senders`; - Archivierungsbefehl; - WAL-Ziel; - freier Speicher; - Backup vom Primary oder Standby; - Version der Werkzeuge; - inkrementelle Abhängigkeiten; - Point-in-Time-Recovery-Konfiguration. `pg_verifybackup` prüft die Struktur und Integrität einer geeigneten Basissicherung, ersetzt aber keinen vollständigen Wiederherstellungstest. --- **7.15.32 NAS-, SAN- und Storage-Snapshots prüfen** Zu erfassen sind: - Storage Pool; - Volume; - LUN; - Dateisystem; - Snapshot; - Replikation; - Zielsystem; - Retention; - Thin Provisioning; - Quota; - Kompression; - Deduplizierung; - Immutable Snapshot; - Offsitekopie. Mögliche Fehler: - Pool voll; - Volume voll; - Snapshotreserve voll; - Thin Pool voll; - Metadatenbereich voll; - Snapshotlimit erreicht; - Replikationsziel nicht erreichbar; - Zertifikat abgelaufen; - Storagekonto gesperrt; - LUN nicht sichtbar; - Multipathfehler; - Snapshotabhängigkeit; - Storagejob überschneidet sich mit Backupjob; - Snapshot wurde erstellt, aber nicht extern kopiert; - Quiescing der Anwendung fehlte. Ein Snapshot auf demselben NAS oder SAN schützt nicht vor dem vollständigen Ausfall oder der Kompromittierung dieses Systems. --- **7.15.33 Cloud- und Object-Storage-Ziele prüfen** Zu prüfen sind: - Bucket oder Container; - Region; - Endpunkt; - DNS; - TLS-Zertifikat; - Proxy; - API-Token; - Zugriffsschlüssel; - Rolle; - Schreibberechtigung; - List-, Read- und Delete-Rechte; - Object Lock; - Retention; - Legal Hold; - Quota; - Kosten- oder Kontolimit; - Rate Limit; - Request Timeout; - Multipart Upload; - unvollständige Uploads; - KMS-Schlüssel; - Verschlüsselung; - Uhrzeit des Clients; - Providerstatus. Ein Konto kann Schreibrechte besitzen, aber wegen fehlender List-, Read- oder Delete-Rechte bei Verifikation oder Retention scheitern. --- **7.15.34 Leistung, Backupfenster und Timeouts prüfen** Zu messen sind: - gelesene Datenmenge; - geschriebene Datenmenge; - Änderungsrate; - Deduplizierungsrate; - Kompressionsrate; - Durchsatz; - Latenz; - Paketverlust; - CPU-Auslastung; - Arbeitsspeicher; - I/O-Wait; - Repositorylatenz; - Snapshotdauer; - Gesamtdauer; - verbleibendes Backupfenster. Mögliche Ursachen: - Produktivlast; - parallele Backupjobs; - Virenscanner; - Storage-Scrub; - Rebuild; - Snapshotkonsolidierung; - WAN-Limit; - hohe Latenz; - Paketverlust; - MTU-Problem; - viele kleine Dateien; - nicht erreichbarer erster Zielserver; - zu kleiner Cache; - langsame Deduplizierungsdatenbank; - Wartungsjob im Repository; - Cloud-API-Drosselung; - neue große Datenmenge; - geänderte Komprimierung oder Verschlüsselung. Ein Job, der das Backupfenster überschreitet, kann vom Scheduler oder Produkt beendet werden, obwohl Quelle und Ziel grundsätzlich funktionieren. --- **7.15.35 Ransomware- und Manipulationsverdacht** Warnsignale: - mehrere Backupjobs gleichzeitig fehlerhaft; - Backupkonto unerwartet gesperrt; - Recovery Points fehlen; - Retention wurde verändert; - Immutability wurde deaktiviert; - Repository enthält ungewöhnliche Löschvorgänge; - ungewöhnlich viele Dateien wurden geändert; - Datenmenge oder Deduplizierungsrate verändert sich stark; - Backups enthalten bereits verschlüsselte Produktivdaten; - Backupserver zeigt unbekannte Anmeldungen; - Logs oder Auditdaten fehlen; - Verschlüsselungsschlüssel wurden verändert; - Repository ist plötzlich nicht erreichbar; - ungewöhnliche API-Aufrufe; - Sekundärkopie oder Offlinekopie fehlt ebenfalls. Bei begründetem Verdacht: 1. Incident-Response-Prozess aktivieren. 2. Beweise sichern. 3. Repository vor weiteren Veränderungen schützen. 4. Immutability und Offlinekopien prüfen. 5. Backupzugangsdaten als möglicherweise kompromittiert behandeln. 6. Keine normalen Retention- oder Pruningvorgänge starten. 7. Wiederherstellungspunkt vor dem vermuteten Vorfall bestimmen. 8. Restore ausschließlich in isolierter Umgebung testen. 9. Produktivwiederherstellung erst nach Freigabe durchführen. --- **7.15.36 Hypothese und Gegenbeweis formulieren** Beispiel: ```text Hypothese: Der geplante Backupjob verwendet ein Dienstkonto, dessen Kennwort geändert wurde. Deshalb kann der Task nicht im unbeaufsichtigten Kontext starten. Erwarteter Befund: Der Task Scheduler zeigt einen Anmelde- oder Authentifizierungsfehler. Der manuelle Start unter einem anderen Konto funktioniert. Es existiert kein neues Backuplog des eigentlichen Jobs. Gegenbeweis: Der Task startet nachweislich unter dem vorgesehenen Konto und erreicht die erste Phase des Backupjobs. Testmethode: Taskstatus, Task-Scheduler-Ereignisse, ausführendes Konto und Zeitpunkt des letzten Kennwortwechsels vergleichen. Erfolgskriterium: Schedulerfehler und Dienstkontoänderung sind zeitlich und technisch eindeutig zugeordnet. ``` Eine belastbare Hypothese enthält: - betroffene Jobphase; - vermutete Ursache; - erwarteten Befund; - Gegenbeweis; - Testmethode; - Risiko; - Erfolgskriterium. --- **7.15.37 Kontrollierte Maßnahmen** | Maßnahme | Voraussetzung | Risiko | |---|---|---| | Zeitplan korrigieren | falscher oder deaktivierter Trigger bestätigt | doppelter oder unerwarteter Lauf | | Dienstkonto korrigieren | Konto- oder Anmeldefehler bestätigt | Zugriff auf Quelle und Ziel verändert sich | | Zugangsdaten erneuern | abgelaufenes Secret bestätigt | falsches Secret unterbricht weitere Jobs | | Quellpfad korrigieren | falscher Pfad bestätigt | falsche Daten könnten gesichert werden | | Ausschlussregel korrigieren | fehlende Daten nachgewiesen | Backupmenge steigt | | VSS-Writer-Ursache beheben | fehlerhafter Writer dokumentiert | Anwendungsdienst kann unterbrochen werden | | Snapshotbereich erweitern | Kapazitätsfehler bestätigt | Storagebelegung steigt | | Repositorykapazität erweitern | Repository voll bestätigt | falsche Ebene bleibt wirkungslos | | Netzwerkregel korrigieren | blockierter Pfad bestätigt | Sicherheitsgrenze verändert sich | | TLS-Zertifikat erneuern | Zertifikatsfehler bestätigt | falsche Kette oder Bindung | | verwaisten Lock entfernen | kein aktiver Prozess zweifelsfrei bestätigt | Repositorybeschädigung bei Fehlentscheidung | | Retention korrigieren | fehlerhafte Richtlinie bestätigt | Recovery Points können verloren gehen | | Pruning ausführen | Retention geprüft und Wartungsfenster vorhanden | hohe Last und Repositorylock | | beschädigte Kette neu aufbauen | Kettenschaden bestätigt | zusätzlicher Speicher und längeres Fenster | | Vollbackup starten | inkrementelle Basis unbrauchbar | hohe Last und lange Laufzeit | | Agent aktualisieren | Kompatibilitätsfehler bestätigt | Neustart oder Versionskonflikt | | Anwendungshook korrigieren | Konsistenzfehler bestätigt | Anwendung kann beeinflusst werden | | Backup erneut starten | Ursache behoben und Kapazität vorhanden | erneute Last und Snapshotbildung | Vor jeder Maßnahme sind zu dokumentieren: - Job-ID; - letzter erfolgreicher Recovery Point; - aktuelle Schutzlücke; - Repositoryzustand; - laufende Prozesse; - erwartete Datenmenge; - Risiko; - Freigabe; - Rückweg; - Erfolgskriterium. --- **7.15.38 Maßnahmen, die nicht spontan ausgeführt werden dürfen** ```text Recovery Points manuell aus dem Repository löschen Repositoryverzeichnisse umbenennen Repositorylock ungeprüft entfernen Retention pauschal verkürzen Immutability deaktivieren Object Lock umgehen Pruning während eines aktiven Backups starten alle Snapshots löschen VSS-Dienste vor der Beweissicherung neu starten Datenbankdateien im laufenden Betrieb kopieren inkrementelle Kettenglieder einzeln löschen Backupkatalog ohne Herstellervorgabe neu erstellen Repositorydaten manuell verändern Verschlüsselungsschlüssel ersetzen verlorenes Repositorykennwort „zurücksetzen“ Backupziel neu formatieren Docker-Volume ungeprüft als einfache Dateikopie sichern Kubernetes-PVC löschen und neu erstellen Restore direkt über Produktivdaten ausführen beschädigtes Backup als einzigen Recovery Point behalten ``` --- **7.15.39 Vollständiger Diagnoseablauf** 1. **Fehlermeldung vollständig aufnehmen** Wortlaut, Fehlercode, Job-ID und Zeitpunkt dokumentieren. 2. **Job und Sicherungsprodukt bestimmen** Plan, Richtlinie, Agent und Server erfassen. 3. **Auswirkung bestimmen** Einzelne Quelle, Jobgruppe, Repository oder gesamte Umgebung unterscheiden. 4. **Letzten erfolgreichen Recovery Point bestimmen** Nicht nur letzten erfolgreichen Prozesslauf prüfen. 5. **RPO-Verletzung berechnen** Aktuelle Schutzlücke mit Sollwert vergleichen. 6. **Jobphase bestimmen** Planung, Snapshot, Lesen, Transport, Schreiben oder Abschluss unterscheiden. 7. **Scheduler prüfen** Trigger, Konto, letzte Ausführung und Exit-Code erfassen. 8. **Backupdienste und Agenten prüfen** Status und Version dokumentieren. 9. **Logs sichern** Job-, Betriebssystem-, Anwendungs- und Repositorylogs korrelieren. 10. **Quelle vollständig bestimmen** Pfade, Volumes, VMs, Container und Datenbanken erfassen. 11. **Ausschlüsse prüfen** Neue oder versehentlich ausgeschlossene Daten erkennen. 12. **Quellberechtigungen prüfen** Tatsächlichen Dienstkontext verwenden. 13. **Quellkapazität prüfen** Freien Speicher, Inodes und Temp-Bereich untersuchen. 14. **Snapshotzustand prüfen** VSS, Hypervisor, CSI oder Storage-Snapshot unterscheiden. 15. **Anwendungskonsistenz prüfen** Writer, Hook oder Datenbankverfahren auswerten. 16. **Ziel und Repository bestimmen** Host, Pfad, Port, Protokoll und Backend erfassen. 17. **Netzwerkpfad prüfen** DNS, Routing, Firewall, VPN, Proxy und TLS untersuchen. 18. **Zielberechtigungen prüfen** Schreiben, Lesen, Listen und gegebenenfalls Löschen unterscheiden. 19. **Repositorykapazität prüfen** Speicher, Quota, Thin Pool, Katalog und Cache berücksichtigen. 20. **Repositorylock prüfen** Aktive und verwaiste Locks unterscheiden. 21. **Parallele Jobs prüfen** Backup, Restore, Replication, Retention und Pruning erfassen. 22. **Sicherungskette prüfen** Vollbackup und erforderliche Folgebackups zuordnen. 23. **Retention und Immutability prüfen** Aufbewahrung, Object Lock und Legal Hold berücksichtigen. 24. **Verschlüsselung prüfen** Schlüssel, Kennwort, KMS und Zertifikate erfassen. 25. **Integrität prüfen** Herstellervorgesehene Repositoryprüfung verwenden. 26. **Performance prüfen** Dauer, Durchsatz, Latenz, Last und Backupfenster vergleichen. 27. **Sicherheitsverdacht bewerten** Manipulation, ungewöhnliche Änderungen und fehlende Recovery Points prüfen. 28. **Hypothese und Gegenbeweis formulieren** Ursache vor der Änderung messbar festlegen. 29. **Eine kontrollierte Maßnahme durchführen** Risiko, Rückweg und Freigabe beachten. 30. **Job kontrolliert neu starten** Doppelstarts und parallele Wartung ausschließen. 31. **Jobphasen überwachen** Snapshot, Übertragung und Abschluss beobachten. 32. **Exit-Code und Warnungen auswerten** Teilerfolg nicht als Vollerfolg behandeln. 33. **Neuen Recovery Point bestätigen** Zeit, Umfang und Repository registrieren. 34. **Integritätsprüfung durchführen** Katalog und Datenblöcke prüfen. 35. **Isolierten Restore-Test durchführen** Repräsentative Daten oder Anwendung wiederherstellen. 36. **Wiederhergestellte Daten validieren** Inhalt, Metadaten, Rechte und Anwendung prüfen. 37. **RPO und RTO bewerten** Tatsächliche Werte dokumentieren. 38. **Sekundärkopie prüfen** Offsite-, Offline- oder immutable Kopie bestätigen. 39. **Temporäre Änderungen zurücknehmen** Debuglogging, Testfreigaben und Ausnahmen entfernen. 40. **Ursache dokumentieren** Technischen Nachweis festhalten. 41. **Prävention festlegen** Monitoring, Kapazität, Retention oder Jobdesign verbessern. --- **7.15.40 Befundmatrix** | Befund | Mögliche Einordnung | Nächster Nachweis | |---|---|---| | kein Joblog vorhanden | Scheduler oder Prozessstart fehlerhaft | Scheduler-Ereignisse | | Job startet manuell, geplant aber nicht | Dienstkonto, Umgebung oder Rechte | Ausführungskontext vergleichen | | Task meldet Erfolg, kein Recovery Point | Skript wertet Exit-Code falsch aus | Unterprozess und Repository prüfen | | Quelle fehlt | Mount, Volume oder Pfad nicht verfügbar | Mount- und Volumezustand | | nur neue Verzeichnisse fehlen | Ausschluss oder Berechtigung | Jobumfang und ACLs | | VSS-Writer fehlgeschlagen | Anwendungskonsistenz fehlerhaft | `vssadmin list writers` | | Snapshot erstellt, Job scheitert später | Transport, Repository oder Katalog | nächste Jobphase | | Repository voll | Kapazität, Quota oder Retention | Belegung aller Repositoryebenen | | Repository hat Platz, Cache ist voll | lokaler Stagingbereich erschöpft | Quellhost und Proxy prüfen | | nur geplanter Netzwerkjob scheitert | gemapptes Laufwerk fehlt | UNC-Pfad und Dienstkonto | | Zugriff verweigert | Berechtigung oder geändertes Konto | Quell- und Zielrechte | | Authentifizierung fehlgeschlagen | Kennwort, Token oder Zertifikat | Ablauf und Dienstkontext | | Repository locked | aktiver oder verwaister Prozess | Prozesse und Jobhistorie | | Inkrementbackup fehlt | Kette unterbrochen | Vollbackup und Folgepunkte | | Retention schlägt fehl | Immutability oder fehlendes Löschrecht | Richtlinie und Object Lock | | Pruning läuft sehr lange | Repositorygröße oder Wartungsüberschneidung | Prozess und I/O-Last | | Rsync Exit-Code `23` | teilweise Übertragung | vollständige Fehlerausgabe | | Rsync Exit-Code `24` | Quelldateien verschwanden | aktive Anwendung und Dateityp | | Dockerexport erfolgreich, Daten fehlen | Volume nicht enthalten | Mounts und Volumes | | Kubernetes-Snapshot nicht `readyToUse` | CSI- oder Storagefehler | Snapshotereignisse | | Datenbankbackup vorhanden, Restore scheitert | Inkonsistenz oder fehlende Logs | Datenbankverifikation | | Backup erfolgreich, Replikation fehlgeschlagen | Zweitkopie fehlt | Replikationsjob und Ziel | | Backupdauer plötzlich erhöht | Datenwachstum, Last oder Netzwerk | Baselinevergleich | | viele Dateien wurden neu gesichert | Verschlüsselung, Zeitstempel oder Anwendung | Änderungsursache | | Prüfsummenfehler | Repository- oder Storagebeschädigung | Integritätsprüfung und Hardware | | ältere Recovery Points fehlen unerwartet | Retentionfehler oder Manipulation | Audit- und Repositorylogs | | Restore funktioniert, Anwendung nicht | Abhängigkeiten oder Konsistenz fehlen | vollständiger Anwendungstest | --- **7.15.41 Typische Diagnosefehler** - Nur die letzte Fehlermeldung betrachten. - Jobstatus „Warning“ als Erfolg behandeln. - Exit-Code eines Unterprozesses nicht übernehmen. - Letzten Job mit letztem Recovery Point gleichsetzen. - RPO-Verletzung nicht berechnen. - Scheduler und Backupsoftware nicht getrennt prüfen. - Manuellen und geplanten Benutzerkontext gleichsetzen. - Gemappte Laufwerke in unbeaufsichtigten Jobs verwenden. - Fehlende Mounts übersehen. - Nur Repositorykapazität prüfen. - Quell-, Cache-, Snapshot- und Katalogspeicher ignorieren. - Inodes nicht prüfen. - VSS-Writer erst nach einem Neustart kontrollieren. - Alle VSS-Dienste pauschal neu starten. - Snapshot mit vollständigem Backup gleichsetzen. - Crash-Konsistenz mit Anwendungskonsistenz verwechseln. - Aktive Datenbankdateien unkoordiniert kopieren. - Dockerexport als Volumebackup betrachten. - Kubernetes-Objekte oder externe Datenbanken vergessen. - PVC-Größe mit freiem Speicher gleichsetzen. - Inkrementelle Abhängigkeiten ignorieren. - Recovery Points manuell aus dem Repository löschen. - Repositorylock automatisch entfernen. - Retention unter Zeitdruck verkürzen. - Immutability als Fehler statt Schutzfunktion behandeln. - Prüfsummenprüfung mit Restore-Test gleichsetzen. - Verschlüsselungsschlüssel nicht in den Wiederherstellungsplan aufnehmen. - Backup und Replikation gleichsetzen. - Nur lokale Kopie prüfen. - Keine isolierte Wiederherstellung testen. - Nur einzelne Datei, aber nicht Anwendung testen. - Wiederherstellungsdauer nicht messen. - Backupfehler bei möglichem Ransomwarevorfall normal behandeln. - Temporäres Debuglogging aktiv lassen. - Ursache nach erfolgreichem Wiederholungslauf nicht dokumentieren. --- **7.15.42 Verifikation und Restore-Test** Nach der Maßnahme müssen mindestens folgende Punkte geprüft werden: - Scheduler ist aktiviert; - nächster Lauf ist korrekt; - Dienstkonto ist gültig; - Job startet im unbeaufsichtigten Kontext; - alle vorgesehenen Quellen sind enthalten; - Ausschlüsse entsprechen dem Sollzustand; - Snapshot wurde erfolgreich erstellt; - Anwendungskonsistenz wurde bestätigt; - Daten wurden vollständig übertragen; - Repository besitzt ausreichend Kapazität; - Recovery Point wurde registriert; - Job enthält keine unbeachteten Warnungen; - Sicherungskette ist vollständig; - Integritätsprüfung ist erfolgreich; - Verschlüsselungsschlüssel ist verfügbar; - sekundäre Kopie wurde erstellt; - Immutability ist aktiv, sofern vorgesehen; - repräsentative Dateien lassen sich wiederherstellen; - Dateiinhalte stimmen; - Dateigrößen stimmen; - Zeitstempel stimmen, sofern erforderlich; - Eigentümer und Berechtigungen stimmen; - ACLs und erweiterte Attribute stimmen; - Datenbank lässt sich öffnen; - Anwendung startet mit den wiederhergestellten Daten; - Abhängigkeiten und Konfigurationen sind vorhanden; - tatsächliches RPO wurde bestimmt; - tatsächliches RTO wurde gemessen; - Restore-Dokumentation ist vollständig; - temporäre Testdaten wurden kontrolliert entfernt. Ein Restore-Test sollte nicht die produktiven Originaldaten überschreiben. --- **7.15.43 Stufen eines Restore-Tests** | Stufe | Nachweis | |---|---| | Katalogtest | Recovery Point wird angezeigt | | Lesetest | Sicherungsdaten können gelesen werden | | Integritätstest | Prüfsummen und Repositorystruktur stimmen | | Datei-Restore | ausgewählte Dateien werden isoliert wiederhergestellt | | Metadatenprüfung | Rechte, Eigentümer und Zeitstempel stimmen | | Datenbank-Restore | Datenbank wird konsistent wiederhergestellt | | Anwendungs-Restore | Anwendung startet und arbeitet | | System-Restore | VM, Host oder Dienst wird vollständig wiederhergestellt | | DR-Test | definierte Notfallumgebung wird innerhalb des RTO aufgebaut | Je kritischer das System ist, desto höher muss die regelmäßig getestete Restore-Stufe sein. --- **7.15.44 Prävention und Monitoring** Zu überwachen sind: - letzter Jobstart; - letzter erfolgreicher Job; - letzter Recovery Point; - letzter verifizierter Recovery Point; - letzter externer Recovery Point; - letzter Restore-Test; - Alter des Restore-Tests; - Jobdauer; - übertragene Datenmenge; - Änderungsrate; - Durchsatz; - Warnungen; - Teilfehler; - Repositorykapazität; - Snapshotkapazität; - Cachekapazität; - Inodes; - Quotas; - Repositorylocks; - Retention; - Pruning; - Immutability; - Replikation; - Verschlüsselungsschlüssel; - Zertifikats- und Tokenablauf; - RPO; - RTO. Ein geeignetes Monitoring alarmiert nicht nur bei `Failed`, sondern auch bei: - Job wurde nicht gestartet; - kein neuer Recovery Point; - Job erfolgreich, aber Datenmenge ungewöhnlich klein; - Jobdauer ungewöhnlich kurz; - Jobdauer ungewöhnlich lang; - nur Teilbackup; - letzte Verifikation zu alt; - letzter Restore-Test zu alt; - sekundäre Kopie fehlt; - Immutability nicht aktiv; - Repository wächst unerwartet; - Retention wurde verändert. --- **7.15.45 Empfohlene Schutzstruktur** Eine robuste Sicherungsstrategie berücksichtigt mehrere Fehlerdomänen: ```text Produktivdaten → primäres Backuprepository → getrennte Zweitkopie → unveränderbare oder offline Kopie → regelmäßig getestete Wiederherstellung ``` Zu vermeiden ist: ```text Produktivdaten und einzige Sicherung auf demselben Host, demselben Storage Pool oder mit denselben kompromittierbaren Zugangsdaten ``` Backups sollten entsprechend Schutzbedarf: - verschlüsselt; - getrennt; - unveränderbar; - überwacht; - regelmäßig geprüft; - regelmäßig wiederhergestellt; - gegen unberechtigte Löschung geschützt sein. --- **7.15.46 Dokumentationsvorlage** ```text Störung: Zeitpunkt: Sicherungsprodukt: Jobname: Job-ID: Betroffene Quelle: Sicherungsziel: Geplanter Start: Tatsächlicher Start: Endzeit: Jobphase: Exit-Code: Letzter erfolgreicher Recovery Point: Letzter verifizierter Recovery Point: Aktuelle Schutzlücke: Vorgesehenes RPO: Vorgesehenes RTO: Schedulerzustand: Dienstkonto: Quellzustand: Snapshotzustand: Anwendungskonsistenz: Netzwerkpfad: Repositoryzustand: Sicherungskette: Retention und Immutability: Verschlüsselung: Nachgewiesene Ursache: Gegenbeweis ausgeschlossen durch: Durchgeführte Maßnahme: Risiko und Rückweg: Neuer Recovery Point: Integritätsprüfung: Restore-Test: Tatsächliches RPO: Tatsächliches RTO: Prävention: ``` --- **7.15.47 Checkliste** - [ ] exakte Fehlermeldung dokumentiert - [ ] Fehlercode dokumentiert - [ ] Jobname erfasst - [ ] Job-ID erfasst - [ ] Sicherungsprodukt und Version erfasst - [ ] Start- und Endzeit erfasst - [ ] betroffene Jobphase bestimmt - [ ] letzten erfolgreichen Job bestimmt - [ ] letzten Recovery Point bestimmt - [ ] letzten verifizierten Recovery Point bestimmt - [ ] aktuelle Schutzlücke berechnet - [ ] RPO bewertet - [ ] RTO berücksichtigt - [ ] Scheduler geprüft - [ ] Trigger geprüft - [ ] verpasste Läufe geprüft - [ ] Dienstkonto geprüft - [ ] Kennwortablauf geprüft - [ ] Tokenablauf geprüft - [ ] Zertifikatsablauf geprüft - [ ] Recht zur geplanten Anmeldung geprüft - [ ] Arbeitsverzeichnis geprüft - [ ] Umgebungsvariablen geprüft - [ ] Exit-Code geprüft - [ ] Standardausgabe geprüft - [ ] Fehlerausgabe geprüft - [ ] Backupdienste geprüft - [ ] Agentstatus geprüft - [ ] Agentversion geprüft - [ ] vollständige Quelle erfasst - [ ] Quellpfade geprüft - [ ] Volumes geprüft - [ ] Mountpoints geprüft - [ ] Ausschlüsse geprüft - [ ] Quellberechtigungen geprüft - [ ] freien Speicher der Quelle geprüft - [ ] Inodes geprüft - [ ] Cache- und Temp-Bereich geprüft - [ ] Snapshotbereich geprüft - [ ] VSS-Writer geprüft - [ ] VSS-Provider geprüft - [ ] Anwendungskonsistenz geprüft - [ ] Hypervisor-Snapshot geprüft - [ ] Storage-Snapshot geprüft - [ ] Repositoryhostname bestimmt - [ ] DNS geprüft - [ ] Ziel-IP bestimmt - [ ] Port geprüft - [ ] Firewall geprüft - [ ] VPN geprüft - [ ] Proxy geprüft - [ ] TLS geprüft - [ ] Repositorypfad geprüft - [ ] Zielberechtigungen geprüft - [ ] Repositorykapazität geprüft - [ ] Repositoryquota geprüft - [ ] Thin Pool geprüft - [ ] Repositorylock geprüft - [ ] parallele Jobs geprüft - [ ] Restorevorgänge geprüft - [ ] Retentionjob geprüft - [ ] Pruning geprüft - [ ] Replikation geprüft - [ ] Vollbackup bestimmt - [ ] inkrementelle Kette geprüft - [ ] differenzielle Abhängigkeit geprüft - [ ] Katalog geprüft - [ ] Repositoryindex geprüft - [ ] Prüfsummen geprüft - [ ] Verschlüsselungsschlüssel geprüft - [ ] KMS-Erreichbarkeit geprüft - [ ] Immutability geprüft - [ ] Object Lock geprüft - [ ] sekundäre Kopie geprüft - [ ] Offsitekopie geprüft - [ ] Offlinekopie geprüft - [ ] Docker-Volumes bei Bedarf geprüft - [ ] Kubernetes-Objekte bei Bedarf geprüft - [ ] PVCs bei Bedarf geprüft - [ ] VolumeSnapshots bei Bedarf geprüft - [ ] Datenbankverfahren geprüft - [ ] Transaktionslogs geprüft - [ ] WAL-, Redo- oder Binärlogs geprüft - [ ] Jobdauer mit Baseline verglichen - [ ] Datenmenge mit Baseline verglichen - [ ] Durchsatz geprüft - [ ] Backupfenster geprüft - [ ] Sicherheitsverdacht bewertet - [ ] Hypothese formuliert - [ ] Gegenbeweis festgelegt - [ ] Risiko und Rückweg dokumentiert - [ ] nur eine kontrollierte Maßnahme durchgeführt - [ ] neuen Job überwacht - [ ] neuen Recovery Point bestätigt - [ ] Integritätsprüfung durchgeführt - [ ] isolierten Restore-Test durchgeführt - [ ] Dateiinhalte geprüft - [ ] Metadaten und Berechtigungen geprüft - [ ] Datenbank geöffnet - [ ] Anwendung getestet - [ ] tatsächliches RPO dokumentiert - [ ] tatsächliches RTO gemessen - [ ] temporäre Änderungen zurückgenommen - [ ] Ursache dokumentiert - [ ] Präventionsmaßnahme festgelegt --- **7.15.48 Schnellreferenz** | Aufgabe | Befehl | |---|---| | Windows-Task | `Get-ScheduledTask -TaskName ""` | | Windows-Task-Laufzeit | `Get-ScheduledTask -TaskName "" \| Get-ScheduledTaskInfo` | | detaillierte Taskabfrage | `schtasks /query /tn "" /v /fo LIST /hresult` | | Windows-Backupstatus | `wbadmin get status` | | Windows-Backupversionen | `wbadmin get versions` | | Windows-Backupdatenträger | `wbadmin get disks` | | VSS-Writer | `vssadmin list writers` | | VSS-Provider | `vssadmin list providers` | | VSS-Speicher | `vssadmin list shadowstorage` | | Windows-Volumes | `Get-Volume` | | Systemd-Timer | `systemctl list-timers --all` | | Backup-Service | `systemctl status backup.service` | | Backup-Service-Logs | `journalctl -u backup.service --since "-24 hours"` | | Benutzer-Cronjobs | `crontab -l` | | Root-Cronjobs | `sudo crontab -l` | | Linux-Speicher | `df -hT` | | Linux-Inodes | `df -i` | | Linux-Mounts | `findmnt` | | Rsync-Trockenlauf | `rsync --dry-run --itemize-changes ` | | Restic-Snapshots | `restic snapshots` | | Restic-Statistik | `restic stats` | | Restic-Locks | `restic list locks` | | Restic-Prüfung | `restic check` | | Time-Machine-Status | `tmutil status` | | Time-Machine-Ziel | `tmutil destinationinfo` | | letztes Time-Machine-Backup | `tmutil latestbackup` | | Docker-Volumes | `docker volume ls` | | Docker-Volume untersuchen | `docker volume inspect ` | | Kubernetes-CronJobs | `kubectl get cronjobs --all-namespaces` | | Kubernetes-Jobs | `kubectl get jobs --all-namespaces` | | Kubernetes-PVCs | `kubectl get pvc --all-namespaces` | | Kubernetes-Snapshots | `kubectl get volumesnapshot --all-namespaces` | | PostgreSQL-Basissicherung prüfen | `pg_verifybackup ` | --- **7.15.49 Quellen** **Offizielle Microsoft-Dokumentation** - [Microsoft Learn – Windows Server Backup Command Reference](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/windows-server-backup-command-reference) - [Microsoft Learn – wbadmin start backup](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/wbadmin-start-backup) - [Microsoft Learn – Volume Shadow Copy Service](https://learn.microsoft.com/en-us/windows-server/storage/file-server/volume-shadow-copy-service) - [Microsoft Learn – Backup fails because of a VSS Writer](https://learn.microsoft.com/en-us/troubleshoot/windows-server/backup-and-storage/backup-fails-vss-writer) - [Microsoft Learn – No VSS writers are listed](https://learn.microsoft.com/en-us/troubleshoot/windows-server/backup-and-storage/no-vss-writers-listed-run-vssadmin-list-writers) - [Microsoft Learn – Get-ScheduledTaskInfo](https://learn.microsoft.com/en-us/powershell/module/scheduledtasks/get-scheduledtaskinfo) - [Microsoft Learn – schtasks](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/schtasks) - [Microsoft Learn – schtasks query](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/schtasks-query) **Offizielle Linux- und Projektdokumentation** - [systemd – systemctl](https://www.freedesktop.org/software/systemd/man/latest/systemctl.html) - [systemd – systemd.timer](https://www.freedesktop.org/software/systemd/man/latest/systemd.timer.html) - [systemd – journalctl](https://www.freedesktop.org/software/systemd/man/latest/journalctl.html) - [Rsync – Official man page](https://download.samba.org/pub/rsync/rsync.1) - [Restic – Backing up](https://restic.readthedocs.io/en/stable/040_backup.html) - [Restic – Restoring](https://restic.readthedocs.io/en/stable/050_restore.html) - [Restic – Removing backup snapshots](https://restic.readthedocs.io/en/stable/060_forget.html) - [Restic – Working with repositories](https://restic.readthedocs.io/en/stable/045_working_with_repos.html) - [Restic – Troubleshooting](https://restic.readthedocs.io/en/stable/077_troubleshooting.html) **Offizielle Docker-Dokumentation** - [Docker Docs – Volumes](https://docs.docker.com/engine/storage/volumes/) - [Docker Docs – Storage](https://docs.docker.com/engine/storage/) - [Docker Docs – docker container export](https://docs.docker.com/reference/cli/docker/container/export/) - [Docker Docs – Back up and restore Docker Desktop data](https://docs.docker.com/desktop/settings-and-maintenance/backup-and-restore/) **Offizielle Kubernetes-Dokumentation** - [Kubernetes – Volume Snapshots](https://kubernetes.io/docs/concepts/storage/volume-snapshots/) - [Kubernetes – Persistent Volumes](https://kubernetes.io/docs/concepts/storage/persistent-volumes/) - [Kubernetes – Operating etcd clusters](https://kubernetes.io/docs/tasks/administer-cluster/configure-upgrade-etcd/) **Offizielle PostgreSQL-Dokumentation** - [PostgreSQL – Backup and Restore](https://www.postgresql.org/docs/current/backup.html) - [PostgreSQL – pg_basebackup](https://www.postgresql.org/docs/current/app-pgbasebackup.html) - [PostgreSQL – pg_verifybackup](https://www.postgresql.org/docs/current/app-pgverifybackup.html) - [PostgreSQL – Continuous Archiving and Point-in-Time Recovery](https://www.postgresql.org/docs/current/continuous-archiving.html) **Offizielle Apple-Dokumentation** - [Apple – Back up your Mac with Time Machine](https://support.apple.com/en-us/104984) - [Apple – Time Machine troubleshooting](https://support.apple.com/guide/mac-help/time-machine-troubleshooting-mh15653/mac) - [Apple – If a Time Machine backup fails](https://support.apple.com/guide/mac-help/if-a-time-machine-backup-fails-mchlb955003d/mac) - [Apple – Verify your backup disk](https://support.apple.com/guide/mac-help/verify-your-backup-disk-mh26840/mac) - [Apple – Restore items backed up with Time Machine](https://support.apple.com/guide/mac-help/restore-files-mh11422/mac) **Offizielle Sicherheitsempfehlungen** - [BSI – Datensicherungskonzept CON.3](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/IT-GS-Kompendium_Einzel_PDFs_2023/03_CON_Konzepte_und_Vorgehensweisen/CON_3_Datensicherungskonzept_Edition_2023.pdf) - [BSI – Top 10 Ransomware-Maßnahmen](https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Cyber-Sicherheitslage/Analysen-und-Prognosen/Ransomware-Angriffe/Top-10-Ransomware-Massnahmen/top-10-ransomware-massnahmen.html) - [CISA – StopRansomware Guide](https://www.cisa.gov/stopransomware/ransomware-guide) Für diese Seite wurden keine Community-Berichte, Hersteller-Social-Media-Aussagen oder eigenen Laborergebnisse als Nachweis verwendet. # 8. Betriebssystem- und Serveranalyse # 8.1 Windows-Prozesse und Dienste gezielt untersuchen **Kurzbeschreibung** Wenn ein Windows-System langsam reagiert, eine Anwendung nicht startet, ein Dienst ausfällt oder ein Prozess ungewöhnliche Ressourcen verbraucht, muss der verursachende Prozess einschließlich seiner Abhängigkeiten untersucht werden. Windows-Bordmittel und die Microsoft-Sysinternals-Werkzeuge ermöglichen unter anderem die Analyse von: - Prozessen und untergeordneten Prozessen, - Diensten, - Threads, - CPU- und Arbeitsspeichernutzung, - geöffneten Dateien und Handles, - geladenen DLLs, - Registry-Zugriffen, - Dateisystemzugriffen, - Netzwerkverbindungen, - Autostarteinträgen, - Programmabstürzen, - nicht mehr reagierenden Anwendungen. Ein auffälliger Prozess ist nicht automatisch die eigentliche Ursache. Er kann selbst auf eine Datei, eine Sperre, einen Treiber, eine Datenbank, das Netzwerk oder einen anderen Dienst warten. --- **1. Typische Symptome** - Anwendung startet nicht. - Anwendung reagiert nicht mehr. - Dienst beendet sich unerwartet. - Dienst bleibt im Zustand „Wird gestartet“ oder „Wird beendet“. - CPU-Auslastung ist dauerhaft hoch. - Arbeitsspeicherverbrauch wächst kontinuierlich. - Datenträger wird durch einen Prozess stark ausgelastet. - Datei kann nicht gelöscht, verschoben oder überschrieben werden. - Anwendung meldet „Zugriff verweigert“. - Prozess öffnet ungewöhnlich viele Dateien oder Registry-Schlüssel. - Netzwerkverbindung wird von einem unbekannten Prozess hergestellt. - Programm funktioniert nur mit Administratorrechten. - Fehler tritt nur nach der Anmeldung oder nach einem Neustart auf. - Systemstart oder Benutzeranmeldung dauert ungewöhnlich lange. - Anwendung stürzt ohne eindeutige Fehlermeldung ab. - Ereignisanzeige enthält Anwendungs-, Dienst- oder Treiberfehler. - Prozesse werden mehrfach oder unerwartet gestartet. - Anwendung funktioniert nach einem Prozessneustart nur vorübergehend. --- **2. Mögliche Auswirkungen** - einzelne Anwendung nicht verfügbar, - Hintergrunddienst ausgefallen, - mehrere Benutzer betroffen, - Serverdienst nicht erreichbar, - Leistungsprobleme des gesamten Systems, - blockierte Dateien oder Verzeichnisse, - Datenverlust durch einen Programmabsturz, - fehlgeschlagene Sicherung oder Synchronisation, - fehlerhafte Anmeldung oder Benutzerprofilinitialisierung, - Sicherheitsrisiko durch unbekannten Prozess, - Produktionsausfall bei geschäftskritischen Diensten. --- **3. Sicherheits- und Betriebswarnung** Sysinternals-Werkzeuge können tiefgehende Informationen über Prozesse, Benutzer, Dateien und Netzwerkverbindungen anzeigen. Diagnoseergebnisse können enthalten: - Benutzernamen, - interne Pfade, - Servernamen, - IP-Adressen, - Befehlszeilenargumente, - Zugriffstoken, - geladene Module, - Registry-Inhalte, - personenbezogene Daten. Besondere Vorsicht gilt bei: - Beenden eines Prozesses, - Stoppen oder Neustarten eines Dienstes, - Schließen eines Handles, - Deaktivieren eines Autostarteintrags, - Erstellen eines vollständigen Speicherabbilds, - länger laufender Process-Monitor-Aufzeichnung, - Aktivieren zusätzlicher Debugprotokollierung. Ein vollständiges Speicherabbild kann sensible Daten wie Kennwörter, Tokens, Schlüssel oder Anwendungsdaten enthalten. Dump-, ETL- und PML-Dateien müssen deshalb geschützt gespeichert und nach Abschluss der Analyse kontrolliert gelöscht werden. Werkzeuge sollten nur aus der offiziellen Microsoft-Quelle bezogen werden. Vor dem Einsatz auf einem Produktivsystem sind Auswirkung, benötigter Speicherplatz und mögliche Leistungseinflüsse zu prüfen. --- **4. Werkzeugauswahl** | Fragestellung | Geeignetes Werkzeug | |---|---| | Welcher Prozess benötigt CPU oder RAM? | Task-Manager, Ressourcenmonitor, PowerShell, Process Explorer | | Welcher Dienst gehört zu einem Prozess? | Task-Manager, `tasklist /svc`, Process Explorer | | Welcher Prozess hat eine Datei geöffnet? | Ressourcenmonitor, Handle, Process Explorer | | Welche DLLs hat ein Prozess geladen? | Process Explorer, ListDLLs | | Warum erhält eine Anwendung „Zugriff verweigert“? | Process Monitor, AccessChk | | Welcher Prozess stellt eine Netzwerkverbindung her? | TCPView, `Get-NetTCPConnection` | | Was wird beim Systemstart automatisch geladen? | Autoruns | | Warum stürzt eine Anwendung ab? | Ereignisanzeige, Zuverlässigkeitsverlauf, ProcDump, WinDbg | | Warum reagiert ein Prozess nicht mehr? | Process Explorer, ProcDump, Wait-Chain-Analyse | | Welcher Prozess erzeugt Registry- oder Dateisystemzugriffe? | Process Monitor | | Warum ist das System zeitweise langsam? | Leistungsüberwachung, WPR und WPA | | Wie hängen Prozesse zusammen? | Process Explorer | | Welche Prozesse sind signiert? | Process Explorer, Sigcheck | | Welche Berechtigung besitzt ein Benutzer oder Dienst? | AccessChk, `whoami` | --- **5. Benötigte Informationen** Vor der Diagnose sollten mindestens folgende Informationen vorliegen: ```text Computer: Betriebssystem und Build: betroffene Anwendung: betroffener Dienst: Prozessname: Prozess-ID: Benutzerkonto des Prozesses: Beginn des Problems: exakte Fehlermeldung: Fehlercode oder Event-ID: reproduzierbar: letzter funktionierender Zeitpunkt: letzte Änderung: betroffene Benutzer: Auswirkung: bereits durchgeführte Maßnahmen: ``` Zusätzlich hilfreich: - Installations- oder Updatezeitpunkt, - Anwendungsversion, - Dienstkonto, - erwartete Netzwerkziele, - erwartete Dateien und Registry-Pfade, - funktionierendes Vergleichssystem, - Baseline der normalen Ressourcennutzung. --- **6. Ausgangszustand sichern** Vor einem Neustart oder dem Beenden eines Prozesses sollten flüchtige Informationen dokumentiert werden. ```powershell Get-Date Get-ComputerInfo | Select-Object WindowsProductName, WindowsVersion, OsBuildNumber, OsLastBootUpTime ``` Laufende Prozesse sichern: ```powershell Get-Process | Sort-Object ProcessName | Select-Object ProcessName, Id, CPU, WorkingSet64, Handles, Threads ``` Laufende Dienste sichern: ```powershell Get-Service | Where-Object Status -eq 'Running' | Sort-Object Name ``` Aktive TCP-Verbindungen sichern: ```powershell Get-NetTCPConnection | Select-Object LocalAddress, LocalPort, RemoteAddress, RemotePort, State, OwningProcess ``` Ereignisse der letzten zwei Stunden: ```powershell Get-WinEvent -FilterHashtable @{ LogName = 'System', 'Application' StartTime = (Get-Date).AddHours(-2) } | Select-Object TimeCreated, LogName, Id, LevelDisplayName, ProviderName, Message ``` Die Ausgabe kann bei Bedarf kontrolliert in Dateien exportiert werden. Dabei sind Datenschutz und Speicherort zu beachten. --- **7. Sichere Schnellprüfung** 1. Exakte Fehlermeldung und Uhrzeit dokumentieren. 2. Prozess- und Dienststatus prüfen. 3. CPU, Arbeitsspeicher, Handles und Threads vergleichen. 4. System- und Anwendungsereignisse zum Fehlerzeitpunkt untersuchen. 5. Mit Process Explorer Prozessbaum und Eigenschaften prüfen. 6. Mit Process Monitor nur den betroffenen Prozess aufzeichnen. 7. Netzwerkverbindungen mit TCPView oder PowerShell prüfen. 8. Erst nach gesicherter Diagnose eine kontrollierte Maßnahme durchführen. --- **8. Prozesse mit PowerShell untersuchen** Alle Prozesse anzeigen: ```powershell Get-Process ``` Prozesse nach CPU-Gesamtzeit sortieren: ```powershell Get-Process | Sort-Object CPU -Descending | Select-Object -First 15 ProcessName, Id, CPU, WorkingSet64, Handles, Threads ``` Prozesse nach Arbeitsspeicher sortieren: ```powershell Get-Process | Sort-Object WorkingSet64 -Descending | Select-Object -First 15 ProcessName, Id, WorkingSet64, PagedMemorySize64, VirtualMemorySize64 ``` Prozesse mit vielen Handles: ```powershell Get-Process | Sort-Object Handles -Descending | Select-Object -First 15 ProcessName, Id, Handles ``` Bestimmten Prozess untersuchen: ```powershell Get-Process -Id | Format-List * ``` Prozess mit CIM einschließlich Befehlszeile und Elternprozess: ```powershell Get-CimInstance Win32_Process | Where-Object ProcessId -eq | Select-Object Name, ProcessId, ParentProcessId, ExecutablePath, CommandLine, CreationDate ``` Der Wert `CPU` bei `Get-Process` ist die seit dem Prozessstart verbrauchte Prozessorzeit und keine momentane prozentuale CPU-Auslastung. --- **9. Prozess-ID und Dienst zuordnen** Eine Prozess-ID kann sich nach jedem Neustart des Prozesses ändern. Bei der Dokumentation müssen deshalb PID, Zeitpunkt und Prozessstart zusammen betrachtet werden. Windows-Befehl: ```cmd tasklist /svc ``` Bestimmte PID suchen: ```cmd tasklist /svc /fi "PID eq " ``` Dienste einschließlich Prozess-ID: ```powershell Get-CimInstance Win32_Service | Select-Object Name, DisplayName, State, StartMode, ProcessId, StartName ``` Dienst zu einer PID suchen: ```powershell Get-CimInstance Win32_Service | Where-Object ProcessId -eq | Select-Object Name, DisplayName, State, StartMode, StartName ``` Mehrere Windows-Dienste können innerhalb desselben `svchost.exe`-Prozesses ausgeführt werden. Der Prozessname allein reicht deshalb nicht zur eindeutigen Zuordnung. --- **10. Dienste untersuchen** Alle Dienste: ```powershell Get-Service | Sort-Object Status, Name ``` Automatisch startende, aber nicht laufende Dienste: ```powershell Get-CimInstance Win32_Service | Where-Object { $_.StartMode -eq 'Auto' -and $_.State -ne 'Running' } | Select-Object Name, DisplayName, State, StartMode, StartName, ExitCode ``` Bestimmten Dienst prüfen: ```powershell Get-Service -Name ``` Ausführliche Dienstkonfiguration: ```cmd sc.exe qc ``` Aktuellen Dienststatus: ```cmd sc.exe queryex ``` Abhängigkeiten anzeigen: ```powershell Get-Service -Name -DependentServices Get-Service -Name -RequiredServices ``` Zu prüfen sind: - Starttyp, - aktueller Status, - Dienstkonto, - ausführbare Datei, - Abhängigkeiten, - Rücksetzungs- und Wiederherstellungsoptionen, - Exit-Code, - wiederholte Neustarts, - Zeitüberschreitungen beim Start, - benötigte Dateien und Netzwerkziele. Ein Dienst darf nicht allein deshalb gestartet werden, weil sein Starttyp auf „Automatisch“ steht. Verzögert gestartete Dienste, Triggerstart, Clustersteuerung oder bewusst deaktivierte Komponenten müssen berücksichtigt werden. --- **11. Ereignisanzeige untersuchen** Wichtige Protokollbereiche: - Windows-Protokolle → Anwendung - Windows-Protokolle → System - Windows-Protokolle → Sicherheit - Anwendungs- und Dienstprotokolle - Microsoft → Windows → Windows Error Reporting - Microsoft → Windows → Diagnostics-Performance - herstellerspezifische Anwendungsprotokolle Fehler und Warnungen der letzten zwei Stunden: ```powershell Get-WinEvent -FilterHashtable @{ LogName = 'System', 'Application' Level = 2, 3 StartTime = (Get-Date).AddHours(-2) } | Select-Object TimeCreated, LogName, Id, ProviderName, LevelDisplayName, Message ``` Ereignisse eines bestimmten Anbieters: ```powershell Get-WinEvent -FilterHashtable @{ LogName = 'Application' ProviderName = '' StartTime = (Get-Date).AddHours(-2) } ``` Ereignisse eines bestimmten Zeitraums: ```powershell $Start = Get-Date '2026-08-02 09:00:00' $Ende = Get-Date '2026-08-02 10:00:00' Get-WinEvent -FilterHashtable @{ LogName = 'System', 'Application' StartTime = $Start EndTime = $Ende } ``` Wichtige Grundregel: > Zuerst nach Zeitpunkt, betroffener Komponente und technischer Wirkung filtern. Nicht jeder Fehler oder jede Warnung in der Ereignisanzeige gehört zur untersuchten Störung. --- **12. Dienstfehler im Systemprotokoll** Der Service Control Manager protokolliert Start-, Stopp- und Dienstfehler im Systemprotokoll. Beispielhafte Abfrage: ```powershell Get-WinEvent -FilterHashtable @{ LogName = 'System' ProviderName = 'Service Control Manager' StartTime = (Get-Date).AddHours(-4) } | Select-Object TimeCreated, Id, LevelDisplayName, Message ``` Häufig relevante Ereignisarten betreffen: - unerwartet beendete Dienste, - fehlgeschlagene Dienststarts, - Zeitüberschreitungen, - ungültige Dienstkonten, - fehlende Dateien, - fehlerhafte Abhängigkeiten. Event-IDs dürfen nicht ohne Prüfung von Provider, Windows-Version und vollständigem Ereignistext interpretiert werden. --- **13. Process Explorer verwenden** Process Explorer zeigt Prozesse hierarchisch in einem Prozessbaum an. Wichtige Informationen: - Eltern- und Kindprozesse, - Benutzerkonto, - Integritätsstufe, - Befehlszeile, - ausführbare Datei, - digitale Signatur, - Prozessstart, - CPU-Auslastung, - private Bytes, - Working Set, - Threads, - Handles, - geladene DLLs, - TCP/IP-Aktivität, - Sicherheits-Token. Empfohlene Vorgehensweise: 1. Process Explorer als Administrator starten, wenn erhöhte Prozesse untersucht werden müssen. 2. `View → Show Process Tree` verwenden. 3. Unter `View → Select Columns` benötigte Spalten aktivieren. 4. Betroffenen Prozess markieren. 5. Eigenschaften des Prozesses öffnen. 6. Image, Performance, Threads, TCP/IP und Security prüfen. 7. Prozesspfad und digitale Signatur kontrollieren. 8. Eltern- und Kindprozesse dokumentieren. 9. Auffällige Threads oder Handles untersuchen. 10. Prozess erst nach Sicherung der Ergebnisse verändern. Hilfreiche Markierungen im Prozessbaum können auf unterschiedliche Prozessarten oder Lebenszyklen hinweisen. Die Farbdarstellung ist konfigurierbar und darf nicht ohne Prüfung der eingestellten Farblegende interpretiert werden. --- **14. Threads untersuchen** Ein Prozess kann insgesamt unauffällig erscheinen, obwohl ein einzelner Thread dauerhaft einen CPU-Kern beansprucht. In Process Explorer: 1. Prozess öffnen. 2. Registerkarte `Threads` auswählen. 3. Threads nach CPU-Auslastung sortieren. 4. Thread-ID und Startadresse dokumentieren. 5. bei verfügbaren Symbolen den Stack untersuchen. 6. geladenes Modul oder zugehörige DLL bestimmen. Mögliche Befunde: | Befund | Mögliche Bedeutung | |---|---| | ein Thread dauerhaft stark ausgelastet | Endlosschleife oder Single-Thread-Engpass | | viele Threads entstehen fortlaufend | Thread-Leak oder fehlerhafte Parallelisierung | | Thread wartet lange | Datei, Netzwerk, Lock oder externe Komponente | | Startadresse gehört zu Drittanbieter-DLL | Anwendung oder Erweiterung untersuchen | | Startadresse gehört zu Sicherheitssoftware | Scan oder Filtertreiber als mögliche Beteiligung prüfen | | Prozess hat ungewöhnlich viele Threads | Worker-Konfiguration, Deadlock oder fehlerhafte Anwendung | Das Beenden eines einzelnen Threads kann den Prozess beschädigen und ist keine sichere Standardmaßnahme. --- **15. Nicht reagierende Anwendungen und Wait Chains** Eine Anwendung kann als „Keine Rückmeldung“ erscheinen, wenn ihr Oberflächenthread nicht rechtzeitig auf Windows-Nachrichten reagiert. Mögliche Ursachen: - lang laufende Berechnung, - blockierte Dateioperation, - Netzwerk-Timeout, - Datenbankabfrage, - gegenseitige Sperre, - blockierter untergeordneter Prozess, - nicht reagierende Erweiterung, - Treiberproblem. Im Ressourcenmonitor kann über die CPU-Ansicht bei einem Prozess die Warteschlange beziehungsweise Wait Chain analysiert werden. Ein möglicher Deadlock liegt vor, wenn mehrere Threads oder Prozesse gegenseitig auf Ressourcen warten. Die Wait-Chain-Analyse liefert einen Hinweis, aber nicht immer einen vollständigen Ursachennachweis. Vor dem Beenden eines wartenden Prozesses sollten Dump, Ereignisse und Anwendungslogs gesichert werden. --- **16. Geöffnete Dateien und Handles untersuchen** Eine Datei kann nicht gelöscht oder umbenannt werden, wenn ein Prozess ein passendes Handle geöffnet hält. Process Explorer: 1. `Find → Find Handle or DLL` öffnen. 2. Teil des Datei- oder Verzeichnisnamens eingeben. 3. gefundenen Prozess und Handle-Typ prüfen. 4. Anwendung möglichst regulär schließen. 5. erst danach einen kontrollierten Prozess- oder Dienstneustart erwägen. Handle als Kommandozeilenwerkzeug: ```cmd handle.exe "" ``` Nach PID filtern: ```cmd handle.exe -p ``` Das direkte Schließen eines Handles kann: - Datenverlust verursachen, - eine Anwendung zum Absturz bringen, - einen inkonsistenten Zustand erzeugen, - eine Transaktion oder Sperrlogik beschädigen. Ein Handle sollte deshalb nicht als erste Maßnahme erzwungen geschlossen werden. --- **17. Geladene DLLs untersuchen** Process Explorer kann im unteren Fensterbereich Handles oder geladene DLLs anzeigen. Umschalten: ```text View → Lower Pane View → DLLs ``` Zu prüfen sind: - vollständiger DLL-Pfad, - Hersteller, - digitale Signatur, - Version, - Ladezeitpunkt, - unerwartete Verzeichnisse, - unterschiedliche Versionen derselben Bibliothek, - nicht signierte Erweiterungen. ListDLLs: ```cmd listdlls.exe ``` Nach einer bestimmten DLL suchen: ```cmd listdlls.exe -d ``` Eine unbekannte oder nicht signierte DLL ist nicht automatisch Schadsoftware. Sie muss anhand von Pfad, Hersteller, Signatur, Hash, Installationszusammenhang und Sicherheitsprüfung bewertet werden. --- **18. Process Monitor verwenden** Process Monitor zeichnet in Echtzeit unter anderem folgende Ereignisse auf: - Dateisystemzugriffe, - Registry-Zugriffe, - Prozess- und Threadaktivität, - Laden von DLLs, - bestimmte Profilierungsereignisse. Da sehr viele Ereignisse entstehen können, muss die Aufzeichnung gefiltert und zeitlich begrenzt werden. Empfohlener Ablauf: 1. Process Monitor starten. 2. Aufzeichnung zunächst anhalten. 3. vorhandene Ereignisse leeren. 4. Filter für den betroffenen Prozess setzen. 5. nur benötigte Ereignisklassen aktivieren. 6. Aufzeichnung starten. 7. Fehler genau einmal reproduzieren. 8. Aufzeichnung sofort anhalten. 9. Ereignisse rund um den Fehlerzeitpunkt untersuchen. 10. Aufzeichnung geschützt speichern oder nach Abschluss löschen. Beispielhafte Filter: ```text Process Name is then Include ``` oder: ```text PID is then Include ``` Zusätzliche Filter können beispielsweise betreffen: ```text Result is ACCESS DENIED Result is NAME NOT FOUND Result is PATH NOT FOUND Operation is CreateFile Operation is RegOpenKey ``` --- **19. Process-Monitor-Ergebnisse bewerten** Häufige Ergebnisse: | Ergebnis | Bedeutung | |---|---| | `SUCCESS` | Operation wurde erfolgreich ausgeführt | | `NAME NOT FOUND` | Objekt mit diesem Namen wurde nicht gefunden | | `PATH NOT FOUND` | Teil des Pfades wurde nicht gefunden | | `ACCESS DENIED` | Zugriff wurde durch Berechtigung oder Sicherheitsmechanismus verweigert | | `SHARING VIOLATION` | Objekt wird in nicht kompatibler Weise verwendet | | `BUFFER OVERFLOW` | häufig normaler Teil einer Größenabfrage | | `NO MORE FILES` | Verzeichnisaufzählung ist beendet | | `REPARSE` | Pfad wurde über einen Reparse Point weitergeleitet | Nicht jeder rote oder fehlgeschlagene Eintrag ist ein Fehler. Anwendungen prüfen häufig mehrere mögliche Pfade, Registry-Schlüssel oder Dateinamen, bevor sie den tatsächlich vorhandenen Eintrag verwenden. Ein relevanter Befund entsteht erst, wenn: - der Zeitpunkt mit dem Symptom übereinstimmt, - das Objekt für die Funktion benötigt wird, - keine erfolgreiche Ausweichoperation folgt, - das Ergebnis technisch zum Fehler passt, - der Fehler reproduzierbar ist. --- **20. „Zugriff verweigert“ untersuchen** Mögliche Ursachen: - fehlende NTFS-Berechtigung, - fehlende Freigabeberechtigung, - fehlendes Benutzerrecht, - niedrige Integritätsstufe, - UAC, - Dienstkonto ohne erforderliche Rechte, - Datei durch Sicherheitssoftware blockiert, - Controlled Folder Access, - Zugriff auf geschützten Registry-Bereich, - Netzwerkzugriff unter einem anderen Konto, - Anwendung verwendet einen falschen Pfad. Aktuelle Identität: ```cmd whoami ``` Gruppen und Sicherheitskennungen: ```cmd whoami /groups ``` Privilegien: ```cmd whoami /priv ``` Effektive NTFS-Berechtigungen sollten mit den Windows-Sicherheitseinstellungen oder einem kontrollierten Werkzeug geprüft werden. AccessChk-Beispiel: ```cmd accesschk.exe -nobanner -v "" "" ``` Die genaue Syntax ist vor dem produktiven Einsatz anhand der aktuellen Microsoft-Dokumentation zu prüfen. Die dauerhafte Ausführung einer Anwendung als Administrator ist keine fachgerechte Standardlösung. Stattdessen muss die konkret fehlende Berechtigung identifiziert und nach dem Minimalprinzip vergeben werden. --- **21. Netzwerkverbindungen einem Prozess zuordnen** PowerShell: ```powershell Get-NetTCPConnection | Sort-Object State, RemoteAddress | Select-Object LocalAddress, LocalPort, RemoteAddress, RemotePort, State, OwningProcess ``` Verbindungen eines bestimmten Prozesses: ```powershell Get-NetTCPConnection | Where-Object OwningProcess -eq ``` Prozess zuordnen: ```powershell Get-Process -Id ``` TCPView zeigt: - lokale Adresse, - lokalen Port, - entfernte Adresse, - entfernten Port, - Verbindungsstatus, - zugehörigen Prozess, - Prozess-ID. Zu prüfen sind: - erwartetes Ziel, - erwarteter Port, - wiederholte Verbindungsversuche, - viele Verbindungen im selben Zustand, - Verbindung zu nicht erwarteten Systemen, - Verbindung nur über IPv4 oder IPv6, - kurzzeitig entstehende Verbindungen, - Portkonflikte. Eine unbekannte Verbindung ist nicht automatisch bösartig. DNS, CDN, Update-, Telemetrie-, Lizenz- und Cloud-Dienste können externe Ziele verwenden. Der Zusammenhang muss geprüft werden. --- **22. Listener und Portkonflikte untersuchen** Lauschende TCP-Ports: ```powershell Get-NetTCPConnection -State Listen | Sort-Object LocalPort | Select-Object LocalAddress, LocalPort, OwningProcess ``` Prozess zu einem Port suchen: ```powershell Get-NetTCPConnection -LocalPort | Select-Object LocalAddress, LocalPort, State, OwningProcess ``` Mit klassischem Windows-Befehl: ```cmd netstat -ano ``` Mögliche Befunde: | Befund | Mögliche Bedeutung | |---|---| | erwarteter Port fehlt | Dienst läuft nicht oder bindet nicht | | Port nur an `127.0.0.1` gebunden | nur lokaler Zugriff möglich | | Port an unerwartete Adresse gebunden | Konfiguration prüfen | | andere PID verwendet den Port | Portkonflikt | | viele Verbindungen in `SYN_SENT` | Ziel oder Netzwerk antwortet nicht | | viele Verbindungen in `TIME_WAIT` | hohe Verbindungsrate oder fehlendes Connection-Reuse | | viele Verbindungen in `CLOSE_WAIT` | Anwendung schließt empfangene Verbindungen nicht korrekt | | Listener vorhanden, Zugriff scheitert | Firewall, TLS, Anwendung oder Rückweg prüfen | --- **23. Autostarts mit Autoruns untersuchen** Autoruns zeigt deutlich mehr Autostartorte als der Task-Manager. Zu den möglichen Kategorien gehören: - Benutzeranmeldung, - Dienste, - Treiber, - geplante Aufgaben, - Explorer-Erweiterungen, - Browserkomponenten, - Winlogon-Komponenten, - AppInit- und Image-Hijack-Einträge, - Codecs, - Office-Erweiterungen. Empfohlene Vorgehensweise: 1. Autoruns als Administrator starten. 2. vollständige Erfassung abwarten. 3. Microsoft-Einträge bei Bedarf ausblenden, ohne sie zu löschen. 4. nach nicht vorhandenen Dateien suchen. 5. Publisher und Signatur prüfen. 6. Eintrag, Pfad und Kategorie dokumentieren. 7. verdächtigen Eintrag zunächst deaktivieren statt löschen. 8. Neustart- oder Anmeldetest kontrolliert durchführen. 9. bei ausbleibender Wirkung Eintrag wieder aktivieren. Ein nicht signierter Autostarteintrag ist nicht automatisch Schadsoftware. Herkunft, Pfad, Hash, Installationszeitpunkt und Sicherheitsmeldungen müssen gemeinsam bewertet werden. --- **24. Digitale Signaturen mit Sigcheck prüfen** Beispiel: ```cmd sigcheck.exe -nobanner -a -h "" ``` Mögliche Prüfpunkte: - digitale Signatur vorhanden, - Signatur gültig, - Herausgeber erwartet, - Zeitstempel vorhanden, - Dateiversion, - Produktname, - kryptografischer Hash, - Pfad der Datei. Eine gültige Signatur beweist, dass die Datei seit der Signierung nicht unbemerkt verändert wurde und zu welchem Zertifikat sie gehört. Sie beweist nicht automatisch, dass die Software erwünscht, fehlerfrei oder für den konkreten Einsatzzweck sicher ist. Online-Prüfungen oder Uploads zu externen Diensten dürfen nur unter Beachtung von Datenschutz, Geheimhaltung und Unternehmensrichtlinien durchgeführt werden. --- **25. Abstürze und Hänger mit ProcDump erfassen** ProcDump kann Speicherabbilder unter bestimmten Bedingungen erzeugen, beispielsweise bei: - Prozessabsturz, - unbehandelter Ausnahme, - hoher CPU-Auslastung, - nicht reagierendem Fenster, - bestimmten Leistungsindikatoren. Manuelles vollständiges Speicherabbild: ```cmd procdump.exe -accepteula -ma "" ``` Dump bei unbehandelter Ausnahme: ```cmd procdump.exe -accepteula -e -ma "" ``` Dump bei nicht reagierendem Fenster: ```cmd procdump.exe -accepteula -h -ma "" ``` Vor dem Einsatz muss geprüft werden: - ausreichend freier Speicherplatz, - geschütztes Zielverzeichnis, - mögliche Größe des Dumps, - Datenschutz, - Auswirkung auf den Prozess, - erforderliche Freigabe, - geeignetes Analysewerkzeug, - sichere Übermittlung an Hersteller oder Entwicklung. Ein Dump ist noch keine Fehlerdiagnose. Er muss mit Symbolen und geeigneten Debugwerkzeugen analysiert werden. --- **26. Windows Performance Recorder und Analyzer** Für komplexe oder nur zeitweise auftretende Leistungsprobleme können Windows Performance Recorder und Windows Performance Analyzer eingesetzt werden. WPR erfasst ETW-Ereignisse. WPA stellt die erfassten Daten als Tabellen und Diagramme dar. Typische Analysebereiche: - CPU-Nutzung, - CPU-Nutzung nach Prozess und Thread, - Datenträger-I/O, - Datei-I/O, - DPC und ISR, - Kontextwechsel, - Prozesslebenszyklus, - Start- und Anmeldeleistung, - Netzwerkaktivität, - Arbeitsspeicherverhalten. Grundsätzlicher Ablauf: 1. geeignetes WPR-Profil auswählen. 2. Speicherplatz und Aufzeichnungsmodus prüfen. 3. Aufzeichnung starten. 4. Problem reproduzieren. 5. Aufzeichnung unmittelbar danach stoppen. 6. ETL-Datei geschützt speichern. 7. Datei mit WPA öffnen. 8. Zeitraum des Fehlers markieren. 9. Prozess, Thread und Ressource korrelieren. 10. Aufzeichnung nach Abschluss kontrolliert archivieren oder löschen. Eine ETW-Aufzeichnung kann groß werden und das System zusätzlich belasten. Profil, Dauer und Detailgrad müssen deshalb begrenzt werden. --- **27. Prozesse sicher beenden oder neu starten** Ein Prozess darf erst beendet werden, wenn geklärt wurde: - welche Anwendung oder welcher Dienst betroffen ist, - ob Daten gespeichert wurden, - ob Transaktionen laufen, - ob andere Dienste den Prozess verwenden, - ob der Prozess automatisch neu startet, - ob ein Cluster oder Watchdog zuständig ist, - ob ein Dump benötigt wird, - welche Benutzer betroffen sind, - wie der Rückweg aussieht. Kontrolliertes Beenden ohne Erzwingen: ```powershell Stop-Process -Id -WhatIf ``` `-WhatIf` zeigt nur die geplante Aktion. Erst nach Prüfung: ```powershell Stop-Process -Id ``` Erzwungenes Beenden: ```powershell Stop-Process -Id -Force ``` `-Force` erhöht das Risiko von Datenverlust oder inkonsistenten Zuständen und sollte nur bei begründetem Bedarf verwendet werden. Bei Diensten ist ein kontrollierter Dienstneustart in der Regel besser als das direkte Beenden des zugehörigen Prozesses: ```powershell Restart-Service -Name -WhatIf ``` Danach: ```powershell Restart-Service -Name ``` --- **28. Befundmatrix** | Befund | Bedeutung | Nächster Test | |---|---|---| | Prozess beansprucht dauerhaft einen Kern | einzelner Thread möglicherweise ausgelastet | Threads und Stack in Process Explorer prüfen | | Working Set hoch, aber stabil | möglicherweise normaler Cache | Private Bytes und zeitliche Entwicklung prüfen | | Private Bytes wachsen dauerhaft | mögliches Speicherleck | Verlauf erfassen und Dump erstellen | | Handle-Anzahl wächst dauerhaft | mögliches Handle-Leak | Handle-Typen und geöffnete Objekte prüfen | | Thread-Anzahl wächst dauerhaft | mögliches Thread-Leak | Threaderzeugung und Anwendung untersuchen | | viele `ACCESS DENIED` unmittelbar vor Fehler | Berechtigungsproblem möglich | Identität und effektive Rechte prüfen | | `NAME NOT FOUND`, danach `SUCCESS` | normale Suchlogik möglich | erfolgreichen Zielpfad bestimmen | | `PATH NOT FOUND` ohne erfolgreichen Ersatz | fehlender Pfad oder fehlerhafte Konfiguration | Anwendungskonfiguration prüfen | | Datei ist gesperrt | Prozess hält Handle offen | Handle-Suche durchführen | | Dienst beendet sich wiederholt | Anwendung, Abhängigkeit oder Dienstkonto | Ereignisse und Anwendungslog prüfen | | Dienst bleibt bei „Wird gestartet“ | Initialisierung oder Abhängigkeit hängt | Wait Chain, Netzwerk und Logs prüfen | | Port wird von anderer PID verwendet | Portkonflikt | Prozess und Konfiguration identifizieren | | viele Verbindungen in `CLOSE_WAIT` | Anwendung schließt Verbindungen nicht | Anwendung und Verbindungspool prüfen | | unbekannte DLL geladen | Erweiterung oder mögliche Manipulation | Pfad, Signatur, Hash und Herkunft prüfen | | Fehler nur nach Anmeldung | Autostart oder Benutzerkonfiguration | Autoruns und Benutzerprofil prüfen | | Fehler nur nach Update | Versions- oder Kompatibilitätsproblem | Änderungsverlauf und Herstellerhinweise | | Prozess stürzt ohne sichtbare Meldung ab | Ausnahme oder externe Beendigung | Ereignisse, WER und ProcDump | | Problem nur unter Dienstkonto | Berechtigung oder Benutzerumgebung | Identität, Rechte und Pfade vergleichen | | Anwendung funktioniert nur erhöht | fehlende Berechtigung oder falscher Speicherort | Process Monitor und AccessChk | | mehrere Prozesse gleichzeitig auffällig | gemeinsame Abhängigkeit | Storage, Netzwerk, Sicherheitssoftware | | nach Neustart vorübergehend behoben | Zustand zurückgesetzt, Ursache unbekannt | Langzeitmessung und Dump-Trigger | --- **29. Typische Ursachen und passende Maßnahmen** **Ursache: fehlerhafter oder blockierter Prozess** Nachweis: - Prozess reagiert nicht, - Wait Chain zeigt Blockierung, - Dump oder Log bestätigt den Fehler. Mögliche Maßnahme: - Diagnosezustand sichern, - Anwendung kontrolliert schließen, - betroffenen Dienst oder Prozess neu starten, - Herstelleranalyse durchführen. Rollback: - nicht anwendbar, wenn nur der Prozess neu gestartet wurde; - gegebenenfalls auf vorherige Anwendungsversion zurückwechseln. Verifikation: - ursprüngliche Funktion testen, - Ressourcen und Logs kontrollieren, - Wiederauftreten überwachen. --- **Ursache: fehlende Berechtigung** Nachweis: - Process Monitor zeigt relevanten Zugriff mit `ACCESS DENIED`, - Benutzer- oder Dienstkonto besitzt das benötigte Recht nicht. Mögliche Maßnahme: - genau erforderliche Berechtigung nach dem Minimalprinzip ergänzen, - Dienstkonto oder Pfadkonfiguration korrigieren. Rollback: - hinzugefügte Berechtigung dokumentiert entfernen. Verifikation: - Anwendung unter dem vorgesehenen Konto testen, - keine unnötigen Rechte vergeben. --- **Ursache: fehlende Datei oder fehlerhafter Pfad** Nachweis: - Process Monitor zeigt relevanten Zugriff mit `NAME NOT FOUND` oder `PATH NOT FOUND`, - kein erfolgreicher alternativer Zugriff folgt. Mögliche Maßnahme: - Anwendung reparieren, - Konfigurationspfad korrigieren, - Datei aus vertrauenswürdiger Quelle wiederherstellen. Rollback: - ursprüngliche Konfiguration sichern und wiederherstellen können. Verifikation: - Datei wird erfolgreich geöffnet, - Anwendung funktioniert, - keine neuen Fehler entstehen. --- **Ursache: fehlerhafte Erweiterung oder DLL** Nachweis: - Problem tritt nur mit bestimmter Erweiterung auf, - Process Explorer oder Dump verweist auf das Modul, - Deaktivierung im Test beseitigt den Fehler. Mögliche Maßnahme: - Erweiterung aktualisieren, - kompatible Version installieren, - Erweiterung kontrolliert deaktivieren. Rollback: - vorherige Version oder Konfiguration wiederherstellen. Verifikation: - Anwendung mehrfach starten und Funktion testen. --- **Ursache: fehlerhafter Autostarteintrag** Nachweis: - Problem beginnt bei Anmeldung oder Systemstart, - Autoruns zeigt zugehörigen Eintrag, - kontrollierte Deaktivierung beseitigt das Symptom. Mögliche Maßnahme: - fehlerhafte Software reparieren oder aktualisieren, - nicht benötigten Eintrag deaktivieren. Rollback: - Eintrag in Autoruns wieder aktivieren. Verifikation: - Neustart und erneute Anmeldung testen. --- **Ursache: Portkonflikt** Nachweis: - erwarteter Port gehört einer anderen PID, - Dienstprotokoll meldet fehlgeschlagene Bindung. Mögliche Maßnahme: - doppelte Anwendung beenden, - Portkonfiguration kontrolliert ändern, - Startreihenfolge korrigieren. Rollback: - vorherige Portkonfiguration wiederherstellen. Verifikation: - Listener prüfen, - tatsächlichen Anwendungsport testen. --- **Ursache: Ressourcen- oder Handle-Leak** Nachweis: - Speicher-, Handle- oder Threadanzahl wächst über längere Zeit, - Wachstum korreliert mit dem Symptom, - Dump oder Herstelleranalyse bestätigt die Ursache. Mögliche Maßnahme: - Anwendung aktualisieren, - Konfiguration korrigieren, - bis zur dauerhaften Fehlerbehebung kontrolliertes Wartungsfenster planen. Rollback: - vorherige Anwendungsversion wiederherstellen, sofern freigegeben. Verifikation: - Langzeitmessung wiederholen, - Baseline mit neuem Verlauf vergleichen. --- **30. Nachkontrolle** Nach einer Maßnahme sind dieselben Kriterien erneut zu prüfen: - Prozess läuft erwartungsgemäß. - Dienststatus ist korrekt. - Anwendung reagiert. - CPU-Auslastung ist plausibel. - Arbeitsspeicher wächst nicht unkontrolliert. - Handles und Threads bleiben stabil. - benötigte Dateien können geöffnet werden. - erforderliche Ports sind gebunden. - Netzwerkverbindungen erreichen die vorgesehenen Ziele. - keine neuen Fehler erscheinen in den Protokollen. - Benutzerfunktion wurde praktisch getestet. - abhängige Dienste funktionieren. - temporäre Filter, Traces und Debugfunktionen wurden beendet. - Dump-, PML- und ETL-Dateien wurden geschützt gespeichert oder gelöscht. - deaktivierte Autostarts wurden abschließend bewertet. - Monitoring zeigt wieder den Normalzustand. --- **31. Dokumentation** Beispiel: ```text Symptom: Der Dienst „Beispieldienst“ wurde nach dem Start innerhalb weniger Sekunden wieder beendet. Zeitpunkt: 02.08.2026, 09:42 Uhr MESZ Nachweis: Das Anwendungsprotokoll zeigte den Fehler zum gleichen Zeitpunkt. Process Monitor zeigte unmittelbar davor einen relevanten Zugriff auf C:\ProgramData\Beispiel\config.json mit ACCESS DENIED. Ursache: Das verwendete Dienstkonto besaß nach einer Änderung keine Leseberechtigung mehr für die Konfigurationsdatei. Maßnahme: Die erforderliche Leseberechtigung wurde ausschließlich für das vorgesehene Dienstkonto wiederhergestellt. Rollback: Dokumentierte Berechtigungsänderung kann entfernt werden. Verifikation: Dienst startet erfolgreich. Anwendungsport ist erreichbar. Keine neuen Fehler im Ereignisprotokoll. Funktionstest erfolgreich. Prävention: Berechtigungen des Anwendungsverzeichnisses werden künftig vor und nach Änderungen automatisiert verglichen. ``` --- **32. Entscheidungsbaum** ```text Windows-Anwendung oder Dienst funktioniert nicht ↓ Läuft der erwartete Prozess? ├── Nein │ ↓ │ Dienststatus, Ereignisse, Autostart, │ Datei, Dienstkonto und Abhängigkeiten prüfen │ └── Ja ↓ Reagiert der Prozess? ├── Nein │ ↓ │ Wait Chain, Threads, Dump und Abhängigkeiten prüfen │ └── Ja ↓ Sind Ressourcen auffällig? ├── Ja │ ↓ │ CPU, RAM, Handles, Threads und I/O untersuchen │ └── Nein ↓ Fehler bei Datei oder Registry? ├── Ja │ ↓ │ Process Monitor, Pfade und Berechtigungen prüfen │ └── Nein ↓ Netzwerk oder externer Dienst beteiligt? ├── Ja │ ↓ │ TCPView, Port, DNS und Zielsystem prüfen │ └── Nein ↓ Anwendungslog, Erweiterungen, DLLs und Dump untersuchen ``` --- **33. Typische Prüfungsfragen** **Warum ist ein Prozess mit hoher CPU-Auslastung nicht automatisch die Fehlerursache?**
Antwort anzeigen Die CPU-Auslastung kann für die ausgeführte Aufgabe normal sein oder als Folge eines anderen Problems entstehen. Zeitpunkt, Threadaktivität, Anwendungssymptom und weitere Abhängigkeiten müssen gemeinsam untersucht werden.
**Worin unterscheiden sich Task-Manager und Process Explorer?**
Antwort anzeigen Der Task-Manager bietet eine grundlegende Übersicht über Prozesse, Leistung, Benutzer und Autostarts. Process Explorer zeigt zusätzlich unter anderem Prozesshierarchie, Befehlszeilen, Signaturen, Handles, DLLs, Threads, Sicherheitsinformationen und detaillierte Prozesseigenschaften.
**Wofür wird Process Monitor verwendet?**
Antwort anzeigen Process Monitor zeichnet Datei-, Registry-, Prozess-, Thread- und DLL-Aktivitäten auf. Damit können beispielsweise fehlende Dateien, fehlerhafte Pfade und verweigerte Zugriffe untersucht werden.
**Warum ist `NAME NOT FOUND` in Process Monitor nicht automatisch ein Fehler?**
Antwort anzeigen Anwendungen prüfen häufig mehrere mögliche Namen oder Pfade. Wenn anschließend ein alternativer Zugriff erfolgreich ist, kann der fehlgeschlagene Versuch zum normalen Programmablauf gehören.
**Warum sollte ein blockierendes Handle nicht sofort geschlossen werden?**
Antwort anzeigen Das erzwungene Schließen kann Datenverlust, Programmabstürze oder inkonsistente Anwendungszustände verursachen. Zuerst muss die zugehörige Anwendung identifiziert und möglichst regulär beendet werden.
**Warum kann ein vollständiges Speicherabbild sicherheitsrelevant sein?**
Antwort anzeigen Der Prozessspeicher kann Kennwörter, Tokens, Schlüssel, personenbezogene Daten und vertrauliche Anwendungsinhalte enthalten. Dumps müssen daher wie sensible Daten behandelt werden.
**Warum darf ein Programm nicht dauerhaft nur als Administrator ausgeführt werden, um „Zugriff verweigert“ zu umgehen?**
Antwort anzeigen Dadurch erhält das Programm weitreichendere Rechte als erforderlich. Stattdessen muss die konkret fehlende Berechtigung identifiziert und nach dem Minimalprinzip vergeben werden.
**Wofür wird Autoruns eingesetzt?**
Antwort anzeigen Autoruns zeigt zahlreiche automatische Startpunkte von Windows, beispielsweise Anmeldeeinträge, Dienste, Treiber, geplante Aufgaben und Erweiterungen. Es hilft bei Problemen, die nach dem Start oder der Anmeldung auftreten.
**Was ist der Unterschied zwischen WPR und WPA?**
Antwort anzeigen Windows Performance Recorder zeichnet ETW-Ereignisse auf. Windows Performance Analyzer öffnet und analysiert die erzeugten ETL-Dateien mithilfe von Tabellen und Diagrammen.
**Warum sollte vor dem Neustart eines Prozesses ein Dump erstellt werden?**
Antwort anzeigen Der Neustart beseitigt den aktuellen Prozesszustand. Ein Dump kann Informationen über Threads, Aufrufstapel, Speicher und Sperren erhalten, die für die Ursachenanalyse benötigt werden.
--- **34. Prüfungsfallen** - hohe CPU-Auslastung sofort als Ursache bewerten. - Prozessname mit Dienstname gleichsetzen. - PID ohne Zeitpunkt dokumentieren. - gesamte CPU-Zeit mit momentaner CPU-Auslastung verwechseln. - nur den Task-Manager verwenden. - Prozesshierarchie nicht beachten. - unbekannten Prozess sofort als Schadsoftware einstufen. - nicht signierte Datei automatisch als schädlich bewerten. - digitale Signatur als vollständigen Sicherheitsnachweis ansehen. - Process Monitor ohne Filter lange laufen lassen. - jeden roten Process-Monitor-Eintrag als Fehler interpretieren. - `NAME NOT FOUND` automatisch als Ursache bewerten. - ein Handle ohne Risikoprüfung schließen. - einen Prozess ohne Dump oder Protokollsicherung beenden. - Dienstprozess direkt beenden, obwohl ein kontrollierter Dienstneustart möglich ist. - Anwendung dauerhaft als Administrator starten. - Autostarteintrag sofort löschen statt kontrolliert deaktivieren. - Dump-Dateien ungeschützt speichern. - unbekannte interne Dateien ungeprüft zu einem externen Dienst hochladen. - Port prüfen, aber zugehörige PID nicht ermitteln. - Listener mit tatsächlicher Anwendungsfunktion verwechseln. - Prozess untersuchen, aber externe Abhängigkeiten übersehen. - mehrere Änderungen gleichzeitig durchführen. - nach einer Maßnahme keine Vergleichsmessung durchführen. - temporäre Traces oder Debugfunktionen aktiv lassen. --- **35. Checkliste** - [ ] exakte Fehlermeldung wurde dokumentiert. - [ ] Fehlerzeitpunkt und Zeitzone wurden erfasst. - [ ] betroffene Anwendung wurde bestimmt. - [ ] Prozessname und PID wurden bestimmt. - [ ] Prozessstartzeit wurde berücksichtigt. - [ ] Eltern- und Kindprozesse wurden geprüft. - [ ] Benutzer- oder Dienstkonto wurde bestimmt. - [ ] Prozess- und Dienststatus wurden geprüft. - [ ] Dienstabhängigkeiten wurden geprüft. - [ ] CPU-Auslastung wurde geprüft. - [ ] einzelne Threads wurden berücksichtigt. - [ ] Arbeitsspeicher wurde geprüft. - [ ] Private Bytes und Working Set wurden unterschieden. - [ ] Handle-Anzahl wurde geprüft. - [ ] Thread-Anzahl wurde geprüft. - [ ] Datenträgeraktivität wurde geprüft. - [ ] Ereignisanzeige wurde zeitlich gefiltert. - [ ] Anwendungsprotokoll wurde geprüft. - [ ] Systemprotokoll wurde geprüft. - [ ] vollständiger Ereignistext wurde gelesen. - [ ] Prozesspfad wurde geprüft. - [ ] Befehlszeile wurde geprüft. - [ ] digitale Signatur wurde geprüft. - [ ] geladene DLLs wurden bei Bedarf geprüft. - [ ] offene Handles wurden bei Bedarf geprüft. - [ ] Process Monitor wurde gefiltert eingesetzt. - [ ] fehlgeschlagene Zugriffe wurden technisch bewertet. - [ ] Benutzer- und Dienstberechtigungen wurden geprüft. - [ ] Netzwerkverbindungen wurden der PID zugeordnet. - [ ] Listener und Portkonflikte wurden geprüft. - [ ] Autostarts wurden bei passendem Fehlerbild geprüft. - [ ] letzte Änderungen wurden berücksichtigt. - [ ] funktionierendes Vergleichssystem wurde genutzt. - [ ] vor einem Neustart wurden flüchtige Daten gesichert. - [ ] Dump-Erstellung wurde bei Absturz oder Hänger geprüft. - [ ] Schutzbedarf von Dump-, PML- und ETL-Dateien wurde beachtet. - [ ] genau eine kontrollierte Maßnahme wurde durchgeführt. - [ ] Rückweg wurde festgelegt. - [ ] Benutzerfunktion wurde nach der Maßnahme getestet. - [ ] Prozesse, Dienste und Protokolle wurden erneut geprüft. - [ ] temporäre Diagnosefunktionen wurden beendet. - [ ] Ursache, Maßnahme und Ergebnis wurden dokumentiert. - [ ] vorbeugende Maßnahme wurde festgelegt. --- **36. Schnellreferenz** | Beobachtung | Nächstes Werkzeug | |---|---| | Prozess verbraucht viel CPU | Process Explorer, Leistungsüberwachung | | nur ein Kern ausgelastet | Process Explorer → Threads | | Arbeitsspeicher wächst | PowerShell, Process Explorer, ProcDump | | Handles wachsen | Process Explorer, Handle | | Datei ist gesperrt | Process Explorer oder Handle | | DLL-Konflikt vermutet | Process Explorer oder ListDLLs | | Zugriff verweigert | Process Monitor, AccessChk | | Datei oder Pfad fehlt | Process Monitor | | Dienst startet nicht | Ereignisanzeige, `sc.exe`, PowerShell | | Dienst hängt beim Start | Ereignisanzeige, Wait Chain, ProcDump | | Prozess reagiert nicht | Ressourcenmonitor, Process Explorer, ProcDump | | Anwendung stürzt ab | Ereignisanzeige, WER, ProcDump | | unbekannte Netzwerkverbindung | TCPView | | erwarteter Port fehlt | `Get-NetTCPConnection`, TCPView | | Port ist bereits belegt | `Get-NetTCPConnection`, `netstat -ano` | | Fehler nach Anmeldung | Autoruns | | langsamer Systemstart | Autoruns, WPR und WPA | | unbekannte Datei | Sigcheck | | zeitweises Leistungsproblem | WPR und WPA | | Problem nur unter Dienstkonto | `whoami`, AccessChk, Process Monitor | | Anwendung funktioniert nur erhöht | Process Monitor und Berechtigungsprüfung | --- **Merksatz** > Windows-Prozesse und Dienste werden nicht allein anhand ihres Namens oder eines einzelnen Messwerts bewertet. Entscheidend sind Prozesshierarchie, Benutzerkonto, Threads, Speicher, Handles, Dateien, Registry-Zugriffe, Netzwerkverbindungen, Ereignisse und externe Abhängigkeiten. Vor dem Beenden oder Neustarten wird der flüchtige Zustand gesichert. Anschließend wird genau eine kontrollierte Maßnahme durchgeführt und ihre Wirkung erneut geprüft. --- **Quellen und weiterführende Dokumentation** **Offizielle Microsoft-Dokumentation** - [Microsoft Learn – Sysinternals](https://learn.microsoft.com/en-us/sysinternals/) - [Microsoft Learn – Sysinternals Utilities](https://learn.microsoft.com/en-us/sysinternals/downloads/) - [Microsoft Learn – Sysinternals Suite](https://learn.microsoft.com/en-us/sysinternals/downloads/sysinternals-suite) - [Microsoft Learn – Process Explorer](https://learn.microsoft.com/en-us/sysinternals/downloads/process-explorer) - [Microsoft Learn – Process Monitor](https://learn.microsoft.com/en-us/sysinternals/downloads/procmon) - [Microsoft Learn – Autoruns](https://learn.microsoft.com/en-us/sysinternals/downloads/autoruns) - [Microsoft Learn – TCPView](https://learn.microsoft.com/en-us/sysinternals/downloads/tcpview) - [Microsoft Learn – Handle](https://learn.microsoft.com/en-us/sysinternals/downloads/handle) - [Microsoft Learn – ListDLLs](https://learn.microsoft.com/en-us/sysinternals/downloads/listdlls) - [Microsoft Learn – AccessChk](https://learn.microsoft.com/en-us/sysinternals/downloads/accesschk) - [Microsoft Learn – Sigcheck](https://learn.microsoft.com/en-us/sysinternals/downloads/sigcheck) - [Microsoft Learn – ProcDump](https://learn.microsoft.com/en-us/sysinternals/downloads/procdump) - [Microsoft Learn – Get-Process](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.management/get-process) - [Microsoft Learn – Get-Service](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.management/get-service) - [Microsoft Learn – Get-WinEvent](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.diagnostics/get-winevent) - [Microsoft Learn – Get-NetTCPConnection](https://learn.microsoft.com/en-us/powershell/module/nettcpip/get-nettcpconnection) - [Microsoft Learn – Stop-Process](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.management/stop-process) - [Microsoft Learn – Restart-Service](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.management/restart-service) - [Microsoft Learn – Windows Performance Recorder](https://learn.microsoft.com/en-us/windows-hardware/test/wpt/windows-performance-recorder) - [Microsoft Learn – Windows Performance Analyzer](https://learn.microsoft.com/en-us/windows-hardware/test/wpt/windows-performance-analyzer) - [Microsoft Learn – Prozesse und Threads mit WPR und WPA untersuchen](https://learn.microsoft.com/en-us/troubleshoot/windows-server/support-tools/support-tools-xperf-wpa-wpr) # 8.2 Active Directory, Gruppenrichtlinien und Kerberos analysieren Active Directory Domain Services bilden in vielen Windows-Netzwerken die Grundlage für: - Benutzer- und Computeranmeldung, - zentrale Authentifizierung, - Gruppen und Berechtigungen, - Gruppenrichtlinien, - DNS-basierte Diensterkennung, - Kerberos-Tickets, - Vertrauensstellungen, - Zertifikatdienste, - Datei-, Druck- und Anwendungszugriffe. Eine scheinbar einfache Meldung wie „Anmeldung nicht möglich“, „Zugriff verweigert“ oder „Gruppenrichtlinie wird nicht angewendet“ kann deshalb unterschiedliche Ursachen haben: - falsche DNS-Konfiguration, - nicht erreichbarer Domänencontroller, - fehlerhafte Zeitsynchronisation, - gestörter Secure Channel, - Replikationsfehler, - falsche Gruppenmitgliedschaft, - fehlerhafte GPO-Verknüpfung, - Sicherheitsfilterung, - WMI-Filter, - Kerberos- oder SPN-Fehler, - nicht repliziertes Kennwort, - gesperrtes oder deaktiviertes Konto, - beschädigtes Computer- oder Benutzerprofil, - fehlende Netzwerkports, - fehlerhafte Vertrauensstellung. Die Komponenten müssen gemeinsam und in einer festen Reihenfolge untersucht werden. --- **1. Lernziele** Nach dieser Seite kannst du: - Active-Directory-Fehler systematisch eingrenzen, - Client-, Server- und Domänencontrollerprobleme unterscheiden, - den verwendeten Domänencontroller bestimmen, - DNS- und SRV-Einträge prüfen, - Zeitsynchronisation untersuchen, - den Secure Channel eines Clients bewerten, - AD-Replikationsfehler erkennen, - Gruppenrichtlinienergebnisse auswerten, - Kerberos-Tickets und SPNs prüfen, - typische Ereignisprotokolle zuordnen, - zwischen Symptom, Ursache und Nebenbefund unterscheiden, - Änderungen kontrolliert und mit Rückweg durchführen. --- **2. Vereinfachte Abhängigkeitskette** ```text Benutzer oder Computer ↓ IP-Konnektivität ↓ DNS-Auflösung und SRV-Einträge ↓ Erreichbarer Domänencontroller ↓ Zeitsynchronisation ↓ Secure Channel und Computerkonto ↓ Kerberos oder NTLM ↓ Active-Directory-Replikation ↓ Gruppenmitgliedschaften und Berechtigungen ↓ Gruppenrichtlinien und Anwendungszugriff ``` Ein Fehler weiter oben kann zahlreiche Folgefehler auslösen. Beispiele: - Falsches DNS kann verhindern, dass ein Domänencontroller gefunden wird. - Eine zu große Zeitabweichung kann Kerberos-Authentifizierung verhindern. - Eine fehlerhafte AD-Replikation kann dazu führen, dass ein neues Kennwort nur an einem Domänencontroller bekannt ist. - Eine fehlerhafte SYSVOL-Replikation kann dazu führen, dass eine GPO zwar im Verzeichnis vorhanden ist, ihre Dateien aber nicht überall verfügbar sind. - Ein doppelter SPN kann verhindern, dass für einen Dienst ein gültiges Kerberos-Ticket ausgestellt wird. --- **3. Sicherheits- und Betriebsregeln** Vor Änderungen müssen mindestens folgende Informationen gesichert werden: - genauer Fehlertext, - Fehlercode, - Zeitpunkt und Zeitzone, - betroffener Benutzer, - betroffener Computer, - verwendeter Domänencontroller, - betroffener Dienst oder Server, - letzte Änderungen, - aktuelle DNS-Konfiguration, - Zeitquelle und Zeitabweichung, - Gruppenrichtlinienergebnis, - Replikationsstatus, - relevante Ereignisse. Nicht als erste Maßnahme durchführen: - Computer aus der Domäne entfernen und wieder aufnehmen, - Computerkonto löschen, - Benutzerkonto neu erstellen, - GPO löschen oder vollständig deaktivieren, - AD-Replikation ungeprüft erzwingen, - Kerberos-Konfiguration in der Registry ändern, - Domänencontroller neu starten, - DNS-Einträge wahllos löschen, - SPNs ohne vorherige Prüfung verändern, - große Berechtigungsgruppen hinzufügen, - alle Gruppenrichtlinien gleichzeitig zurücksetzen. Solche Maßnahmen verändern oder vernichten den Zustand, der für die Ursachenanalyse benötigt wird. --- **4. Fehlerbild exakt erfassen** Wichtige Fragen: - Scheitert die lokale oder die Domänenanmeldung? - Ist nur ein Benutzer betroffen? - Ist nur ein Computer betroffen? - Sind mehrere Computer einer OU oder eines Standorts betroffen? - Funktioniert der Zugriff über IP-Adresse, aber nicht über Namen? - Funktioniert die Anmeldung mit zwischengespeicherten Anmeldedaten? - Tritt der Fehler nur bei einem bestimmten Domänencontroller auf? - Betrifft das Problem Benutzer- oder Computerrichtlinien? - Ist nur ein bestimmter Dienst betroffen? - Funktioniert NTLM, während Kerberos scheitert? - Trat der Fehler nach Kennwortänderung, Wiederherstellung, Snapshot, Migration oder GPO-Änderung auf? - Ist der Fehler dauerhaft oder nur zeitweise vorhanden? - Funktioniert ein vergleichbarer Benutzer oder Computer? Ein Client, ein Benutzer und eine konkrete Zielressource sollten als kontrollierter Testfall verwendet werden. --- **5. Grundinformationen auf dem Client erfassen** Identität: ```cmd whoami ``` Benutzer-Domäne: ```cmd echo %USERDOMAIN% ``` Anmeldeserver: ```cmd echo %LOGONSERVER% ``` Vollständige Benutzerinformationen: ```cmd whoami /all ``` Computername: ```cmd hostname ``` Domänenzugehörigkeit: ```powershell Get-CimInstance Win32_ComputerSystem | Select-Object Name, Domain, PartOfDomain, UserName ``` IP-Konfiguration: ```cmd ipconfig /all ``` Dabei sind besonders zu prüfen: - IPv4- und IPv6-Adresse, - Subnetzmaske beziehungsweise Präfix, - Standardgateway, - DNS-Server, - DNS-Suffix, - DHCP-Status, - Verbindungssuffix, - mehrere aktive Netzwerkadapter, - VPN-, virtuelle oder alte Adapter. Domänenmitglieder sollten grundsätzlich die für die AD-Domäne zuständigen internen DNS-Server verwenden. Ein öffentlicher DNS-Server kennt die internen AD-SRV-Einträge normalerweise nicht. --- **6. Verwendeten Domänencontroller bestimmen** Anmeldeserver: ```cmd echo %LOGONSERVER% ``` Domänencontroller für die Domäne suchen: ```cmd nltest /dsgetdc: ``` Beispiel: ```cmd nltest /dsgetdc:ad.example.local ``` Domänencontroller auflisten: ```cmd nltest /dclist: ``` Aktuellen DC über PowerShell bestimmen: ```powershell Get-ADDomainController -Discover ``` Alle bekannten Domänencontroller: ```powershell Get-ADDomainController -Filter * | Select-Object HostName, Site, IPv4Address, IsGlobalCatalog, OperationMasterRoles ``` Die PowerShell-Befehle des Active-Directory-Moduls erfordern die entsprechenden RSAT-Komponenten oder die Ausführung auf einem geeigneten Verwaltungsserver. Zu dokumentieren sind: - Name des verwendeten Domänencontrollers, - Standort beziehungsweise AD-Site, - IP-Adresse, - Global-Catalog-Status, - Erreichbarkeit, - Zeitpunkt des Tests. --- **7. DNS als erste technische Abhängigkeit prüfen** Hostauflösung: ```cmd nslookup ``` Vollqualifizierten Namen prüfen: ```cmd nslookup . ``` Domänencontroller über LDAP-SRV-Einträge suchen: ```cmd nslookup -type=SRV _ldap._tcp.dc._msdcs. ``` Kerberos-Dienste suchen: ```cmd nslookup -type=SRV _kerberos._tcp. ``` Global Catalog suchen: ```cmd nslookup -type=SRV _gc._tcp. ``` Standortspezifische Domänencontroller: ```cmd nslookup -type=SRV _ldap._tcp.._sites.dc._msdcs. ``` PowerShell: ```powershell Resolve-DnsName -Type SRV ` _ldap._tcp.dc._msdcs. ``` Zu prüfen sind: - existieren die erwarteten SRV-Einträge, - zeigen die Einträge auf vorhandene Domänencontroller, - lassen sich deren Hostnamen auflösen, - stimmen die IP-Adressen, - antwortet der vorgesehene interne DNS-Server, - werden alte oder stillgelegte Domänencontroller zurückgegeben, - liefert ein anderer DNS-Server abweichende Ergebnisse, - ist das DNS-Suffix korrekt, - bestehen doppelte A- oder AAAA-Einträge. Ein erfolgreicher Ping auf eine IP-Adresse beweist keine funktionierende AD-DNS-Struktur. --- **8. Erreichbarkeit benötigter Dienste prüfen** Grundlegende Verbindung: ```powershell Test-NetConnection ``` DNS: ```powershell Test-NetConnection -Port 53 ``` Kerberos: ```powershell Test-NetConnection -Port 88 ``` LDAP: ```powershell Test-NetConnection -Port 389 ``` SMB für SYSVOL und NETLOGON: ```powershell Test-NetConnection -Port 445 ``` RPC Endpoint Mapper: ```powershell Test-NetConnection -Port 135 ``` Global Catalog: ```powershell Test-NetConnection -Port 3268 ``` LDAPS, sofern verwendet: ```powershell Test-NetConnection -Port 636 ``` Global Catalog über TLS, sofern verwendet: ```powershell Test-NetConnection -Port 3269 ``` Wichtige Dienste und Ports können unter anderem sein: | Funktion | Typischer Port | |---|---:| | DNS | TCP/UDP 53 | | Kerberos | TCP/UDP 88 | | RPC Endpoint Mapper | TCP 135 | | LDAP | TCP/UDP 389 | | SMB | TCP 445 | | Kerberos-Kennwortänderung | TCP/UDP 464 | | LDAPS | TCP 636 | | Global Catalog | TCP 3268 | | Global Catalog über TLS | TCP 3269 | | dynamisches RPC | konfigurationsabhängiger TCP-Portbereich | Ein erfolgreich getesteter TCP-Port beweist nur, dass eine Verbindung zu diesem Port hergestellt werden konnte. Er beweist nicht, dass Authentifizierung, LDAP-Abfrage, Replikation oder Gruppenrichtlinienverarbeitung funktionieren. --- **9. SYSVOL und NETLOGON prüfen** Freigaben des Domänencontrollers: ```cmd net view \\ ``` SYSVOL öffnen: ```cmd dir \\\SYSVOL ``` NETLOGON öffnen: ```cmd dir \\\NETLOGON ``` Direkter Domänenpfad: ```cmd dir \\\SYSVOL ``` Zu prüfen sind: - Freigaben vorhanden, - Namensauflösung funktioniert, - Zugriff unter dem vorgesehenen Benutzer möglich, - benötigte GPO-Verzeichnisse vorhanden, - Skripte und Vorlagen erreichbar, - unterschiedliche Domänencontroller liefern denselben erwarteten Inhalt. Eine GPO besteht aus zwei zusammengehörigen Teilen: | Bestandteil | Speicherort | |---|---| | Group Policy Container | Active Directory | | Group Policy Template | SYSVOL | Sind die beiden Teile oder ihre Versionsstände nicht konsistent, kann die Gruppenrichtlinienverarbeitung fehlschlagen. --- **10. Zeitsynchronisation prüfen** Aktueller Status: ```cmd w32tm /query /status ``` Zeitquelle: ```cmd w32tm /query /source ``` Konfiguration: ```cmd w32tm /query /configuration ``` Domänenhierarchie überwachen: ```cmd w32tm /monitor ``` Vergleich mit einem bestimmten Domänencontroller: ```cmd w32tm /stripchart /computer: /samples:10 /dataonly ``` Windows-Zeitdienst: ```powershell Get-Service W32Time ``` Zu prüfen sind: - aktuelle Zeit, - Zeitzone, - Zeitquelle, - Zeitabweichung, - Dienststatus, - Domänenhierarchie, - Erreichbarkeit der Zeitquelle, - Virtualisierung und Host-Zeitsynchronisation, - PDC-Emulator als maßgebliche Domänenzeitquelle. Kerberos reagiert empfindlich auf Zeitabweichungen. Der konkrete Fehler muss jedoch anhand von Ereignissen, Ticketstatus und Zeitmessung nachgewiesen werden. Eine manuelle Änderung der Uhrzeit beseitigt nicht automatisch die Ursache einer falschen Zeitquelle. --- **11. Secure Channel des Computers prüfen** Der Secure Channel ist die geschützte Beziehung zwischen einem Domänenmitglied und der Domäne. Prüfung mit PowerShell: ```powershell Test-ComputerSecureChannel -Verbose ``` Prüfung mit NLTEST: ```cmd nltest /sc_verify: ``` Verwendeten sicheren Kanal anzeigen: ```cmd nltest /sc_query: ``` Mögliche Symptome eines gestörten Secure Channels: - „Die Vertrauensstellung zwischen dieser Arbeitsstation und der primären Domäne ist fehlgeschlagen“, - Anmeldung funktioniert nur mit zwischengespeicherten Daten, - Gruppenrichtlinien schlagen fehl, - Zugriff auf Domänenressourcen scheitert, - Computerkonto-Kennwort stimmt zwischen Client und AD nicht überein. Mögliche Ursachen: - Rücksetzen auf einen alten VM-Snapshot, - geklontes System mit fehlerhafter Identität, - wiederhergestelltes Computerkonto, - Replikationsfehler, - doppelt verwendeter Computername, - beschädigtes Computerkonto, - lange getrenntes oder falsch wiederhergestelltes System. Eine Reparatur des Secure Channels ist eine Änderung und darf erst nach Sicherung der Diagnoseergebnisse erfolgen. Mögliche kontrollierte Reparatur auf einem Domänenmitglied: ```powershell Test-ComputerSecureChannel -Repair ` -Credential \ ``` Vorher müssen geprüft werden: - DNS funktioniert, - Domänencontroller ist erreichbar, - Zeit stimmt, - Computerkonto ist vorhanden und eindeutig, - keine Replikationsstörung liegt vor, - Berechtigung zur Reparatur ist vorhanden, - Rückweg und Wartungsfenster sind festgelegt. `Test-ComputerSecureChannel` ist vor allem für Domänenmitglieder vorgesehen. Bei Domänencontrollern müssen DC-spezifische Diagnose- und Reparaturverfahren verwendet werden. --- **12. Benutzer- und Computerkonto prüfen** Benutzerkonto: ```powershell Get-ADUser -Identity -Properties * | Select-Object SamAccountName, UserPrincipalName, Enabled, LockedOut, PasswordExpired, PasswordLastSet, LastBadPasswordAttempt, BadLogonCount, AccountExpirationDate ``` Computerkonto: ```powershell Get-ADComputer -Identity -Properties * | Select-Object Name, Enabled, DNSHostName, PasswordLastSet, LastLogonDate, DistinguishedName ``` Gruppenmitgliedschaften: ```powershell Get-ADPrincipalGroupMembership | Select-Object Name, GroupScope, GroupCategory ``` Aktuelles Benutzer-Token: ```cmd whoami /groups ``` Zu unterscheiden sind: - im Active Directory gespeicherte Gruppenmitgliedschaften, - Gruppen im aktuellen Anmeldetoken, - verschachtelte Gruppen, - lokale Gruppen, - universelle, globale und domänenlokale Gruppen, - Änderungen nach der letzten Anmeldung. Eine neu hinzugefügte Gruppenmitgliedschaft ist nicht automatisch im bereits bestehenden Benutzer-Token enthalten. Ab- und erneute Anmeldung kann erforderlich sein. Bei bestimmten Dienstkonten kann ein Dienstneustart notwendig sein. --- **13. Kontosperrung untersuchen** Zu prüfen sind: - ist das Konto tatsächlich gesperrt, - auf welchem Domänencontroller wurde die Sperrung registriert, - welcher Client oder Dienst sendet falsche Anmeldedaten, - existieren gespeicherte Anmeldedaten, - läuft ein Dienst oder eine geplante Aufgabe mit altem Kennwort, - verwendet ein Smartphone, VPN oder Netzlaufwerk alte Zugangsdaten, - tritt die Sperrung unmittelbar nach dem Entsperren erneut auf. Benutzerstatus: ```powershell Get-ADUser ` -Properties LockedOut, LastBadPasswordAttempt, BadLogonCount, PasswordLastSet ``` Gesperrte Konten suchen: ```powershell Search-ADAccount -LockedOut -UsersOnly ``` Relevante Sicherheitsereignisse können unter anderem betreffen: - fehlgeschlagene Anmeldung, - Kontosperrung, - Kerberos-Vorauthentifizierungsfehler, - Ticketanforderungen, - Anmeldungen mit expliziten Anmeldedaten. Ein Konto lediglich wiederholt zu entsperren beseitigt die Quelle der falschen Anmeldedaten nicht. --- **14. Domänencontroller grundsätzlich prüfen** Ausführliche Diagnose: ```cmd dcdiag /v ``` Ausgabe in Datei: ```cmd dcdiag /v /c /d /e > C:\Temp\dcdiag.txt ``` DNS-Test: ```cmd dcdiag /test:dns /v ``` Replikationstest: ```cmd dcdiag /test:replications /v ``` SYSVOL-Test: ```cmd dcdiag /test:sysvolcheck /v ``` Werbungsstatus des Domänencontrollers: ```cmd dcdiag /test:advertising /v ``` NETLOGON-Freigabe: ```cmd dcdiag /test:netlogons /v ``` Zu prüfen sind: - welcher Test fehlschlägt, - welcher Domänencontroller betroffen ist, - genauer Fehlercode, - Zeitpunkt, - DNS-Abhängigkeit, - Replikationspartner, - Verzeichnispartition, - Warnung oder tatsächlicher Fehler. Nicht jede Warnung in einer umfangreichen `dcdiag`-Ausgabe erklärt das untersuchte Symptom. Der Befund muss zeitlich und technisch zum Fehler passen. --- **15. AD-Replikation prüfen** Gesamtübersicht: ```cmd repadmin /replsummary ``` Eingehende Replikation eines DCs: ```cmd repadmin /showrepl ``` Gesamtstrukturweite Anzeige: ```cmd repadmin /showrepl * /csv ``` PowerShell-Auswertung: ```powershell repadmin /showrepl * /csv | ConvertFrom-Csv | Out-GridView ``` Replikationsfehler über PowerShell: ```powershell Get-ADReplicationFailure ` -Target * ` -Scope Forest ``` Status der Replikationspartner: ```powershell Get-ADReplicationPartnerMetadata ` -Target * ` -Scope Forest | Select-Object Server, Partner, Partition, LastReplicationAttempt, LastReplicationSuccess, LastReplicationResult ``` Replikationswarteschlange: ```cmd repadmin /queue ``` Zu dokumentieren sind: - Quell- und Ziel-DC, - Verzeichnispartition, - letzte erfolgreiche Replikation, - letzter Replikationsversuch, - Anzahl aufeinanderfolgender Fehler, - Fehlercode, - Fehlertext, - betroffene Standorte, - Richtung des Fehlers. --- **16. Replikationsfehler richtig bewerten** AD-Replikation hängt unter anderem ab von: - DNS, - Netzwerkverbindungen, - RPC, - Authentifizierung, - Autorisierung, - Zeit, - Replikationstopologie, - Verzeichnisdatenbank, - Zustand der Domänencontroller. | Befund | Mögliche Ursache | |---|---| | Fehler 1722 | RPC-Server nicht verfügbar, DNS, Firewall oder Dienstproblem | | Fehler 5 | Zugriff verweigert, Authentifizierung oder Berechtigung | | Zielprinzipalname ist falsch | Kerberos-, SPN- oder Computerkonto-Problem | | letzter Erfolg lange her | dauerhafte oder standortbezogene Störung | | nur eine Partition betroffen | partitions- oder DNS-bezogenes Problem | | nur ein Partner betroffen | Verbindung, DNS oder Zustand dieses Partners | | Änderungen fehlen nur auf einem DC | eingehende Replikation dieses DCs prüfen | | verschiedene Kennwörter funktionieren je nach DC | Kennwortreplikation oder allgemeine Replikation prüfen | | GPO fehlt nur auf einem DC | AD- und SYSVOL-Replikation gemeinsam prüfen | Eine erzwungene Synchronisation ist keine erste Diagnosemaßnahme. Sie kann zusätzliche Last erzeugen und verdeckt möglicherweise die Richtung oder den ursprünglichen Zustand des Fehlers. --- **17. FSMO-Rollen prüfen** ```cmd netdom query fsmo ``` PowerShell: ```powershell Get-ADForest | Select-Object SchemaMaster, DomainNamingMaster Get-ADDomain | Select-Object PDCEmulator, RIDMaster, InfrastructureMaster ``` Die Rollen sind: | Rolle | Ebene | Wichtige Funktion | |---|---|---| | Schema-Master | Gesamtstruktur | Schemaänderungen | | Domänennamen-Master | Gesamtstruktur | Domänen und Partitionen | | RID-Master | Domäne | RID-Pools für Sicherheitskennungen | | PDC-Emulator | Domäne | Zeit, Kennwortpriorität und weitere Funktionen | | Infrastruktur-Master | Domäne | domänenübergreifende Objektbezüge | Der Ausfall eines FSMO-Rolleninhabers erklärt nicht automatisch jede Anmeldestörung. Die betroffene Funktion und die Ausfalldauer müssen berücksichtigt werden. --- **18. Gruppenrichtlinien-Grundlagen** Die normale Verarbeitungsreihenfolge lautet: ```text Lokal → Site → Domäne → OU → untergeordnete OU ``` Diese Reihenfolge wird häufig mit `LSDOU` bezeichnet. Grundsätzlich gilt: - Gruppenrichtlinien werden kumulativ verarbeitet. - Näher am Benutzer- oder Computerobjekt verknüpfte Einstellungen können frühere Einstellungen überschreiben. - Die genaue Wirkung hängt von Verknüpfungsreihenfolge, Vererbung, Erzwingen, Sicherheitsfilterung und Richtlinientyp ab. - Computer- und Benutzerkonfiguration werden getrennt verarbeitet. - Nicht jede Erweiterung wird bei jeder Hintergrundaktualisierung vollständig verarbeitet. - Loopbackverarbeitung kann die Benutzerkonfiguration abhängig vom Computerstandort verändern. Mögliche Ursachen für eine nicht angewendete GPO: - GPO nicht an der richtigen Site, Domäne oder OU verknüpft, - Link deaktiviert, - GPO vollständig oder teilweise deaktiviert, - Objekt befindet sich in der falschen OU, - Sicherheitsfilterung schließt Benutzer oder Computer aus, - fehlende Leseberechtigung, - WMI-Filter liefert `False`, - Vererbung blockiert, - andere GPO besitzt höhere Priorität, - Einstellung gilt nur für Benutzer oder nur für Computer, - langsame Netzwerkverbindung, - erforderliche synchrone Verarbeitung noch nicht erfolgt, - Neustart oder erneute Anmeldung fehlt, - SYSVOL nicht erreichbar, - AD- oder SYSVOL-Replikation gestört, - Client Side Extension schlägt fehl. --- **19. Gruppenrichtlinienergebnis erfassen** Kurzübersicht: ```cmd gpresult /r ``` Computerrichtlinien mit erhöhten Rechten: ```cmd gpresult /scope computer /r ``` Benutzerrichtlinien: ```cmd gpresult /scope user /r ``` Ausführlicher HTML-Bericht: ```cmd gpresult /h C:\Temp\gpresult.html ``` Bericht für einen bestimmten Benutzer: ```cmd gpresult /user \ /h C:\Temp\gpresult-benutzer.html ``` Ausführliche Textausgabe: ```cmd gpresult /z ``` Resultant Set of Policy: ```cmd rsop.msc ``` Im Bericht sind besonders zu prüfen: - angewendete GPOs, - abgelehnte GPOs, - Ablehnungsgrund, - Sicherheitsgruppen, - verwendeter Domänencontroller, - WMI-Filter, - Benutzer- und Computerbereich, - Loopbackmodus, - langsame Verbindung, - Verarbeitungszeit, - Fehler einzelner Erweiterungen. `gpresult` muss im passenden Benutzer- und Berechtigungskontext ausgeführt werden. Ein Bericht aus einem anderen Konto kann ein anderes Ergebnis zeigen. --- **20. Gruppenrichtlinien kontrolliert aktualisieren** Standardaktualisierung: ```cmd gpupdate ``` Erneute Verarbeitung aller Einstellungen: ```cmd gpupdate /force ``` Nur Computerrichtlinien: ```cmd gpupdate /target:computer /force ``` Nur Benutzerrichtlinien: ```cmd gpupdate /target:user /force ``` Eine erzwungene Aktualisierung kann: - zusätzliche Netz- und Serverlast verursachen, - erneut alle Richtlinienerweiterungen anstoßen, - Ab- oder Anmeldung verlangen, - einen Neustart verlangen, - laufende Benutzersitzungen beeinflussen. `gpupdate /force` ist ein Test beziehungsweise Auslöser, aber noch keine Ursachenanalyse. Danach müssen Ergebnisbericht und Ereignisprotokolle geprüft werden. --- **21. Gruppenrichtlinien-Ereignisse prüfen** Wichtiger Protokollpfad: ```text Ereignisanzeige → Anwendungs- und Dienstprotokolle → Microsoft → Windows → GroupPolicy → Operational ``` PowerShell: ```powershell Get-WinEvent -FilterHashtable @{ LogName = 'Microsoft-Windows-GroupPolicy/Operational' StartTime = (Get-Date).AddHours(-2) } | Select-Object TimeCreated, Id, LevelDisplayName, Message ``` Zusätzlich prüfen: - Systemprotokoll, - Anwendungsprotokoll, - DNS Client Events, - NETLOGON, - Kerberos, - Benutzerprofildienst, - einzelne Client Side Extensions. Nicht nur die Event-ID verwenden. Provider, vollständiger Text, Zeitpunkt, Benutzer, Computer und Verarbeitungsschritt müssen gemeinsam bewertet werden. --- **22. GPO-Verknüpfung und Filterung prüfen** In der Gruppenrichtlinienverwaltung sind zu kontrollieren: - richtige GPO, - richtige Verknüpfung, - richtige OU, - Link aktiviert, - GPO-Status, - Verknüpfungsreihenfolge, - Vererbung, - erzwungene Links, - Sicherheitsfilterung, - Delegierung, - WMI-Filter, - Benutzer- oder Computerteil, - GPO-Version, - Replikationsstatus. Sicherheitsfilterung benötigt grundsätzlich die passenden Berechtigungen zum Lesen und Anwenden der Gruppenrichtlinie. Typische Fehlinterpretation: > Ein Benutzer ist Mitglied einer Gruppe, die „Gruppenrichtlinie übernehmen“ besitzt. Im aktuellen Anmeldetoken fehlt diese neue Gruppenmitgliedschaft jedoch noch. Deshalb müssen AD-Mitgliedschaft und aktuelles Token getrennt geprüft werden. --- **23. Loopbackverarbeitung verstehen** Loopbackverarbeitung wird für Computer verwendet, bei denen die Benutzerumgebung vom verwendeten Computer abhängen soll, beispielsweise: - Schulungsräume, - Kiosksysteme, - Terminalserver, - gemeinsam verwendete Arbeitsplätze. Modi: | Modus | Wirkung | |---|---| | Zusammenführen | Benutzerrichtlinien des Benutzerobjekts werden verarbeitet, danach kommen die für den Computer ermittelten Benutzerrichtlinien hinzu | | Ersetzen | Benutzerrichtlinien des Benutzerobjekts werden durch die für den Computer ermittelten Benutzerrichtlinien ersetzt | Wenn Benutzereinstellungen nur auf bestimmten Computern unerwartet sind, muss Loopback geprüft werden. --- **24. Kerberos-Grundprinzip** Vereinfacht: ```text Benutzeranmeldung ↓ Authentication Service Request ↓ Ticket Granting Ticket ↓ Ticket Granting Service Request ↓ Dienstticket für einen SPN ↓ Zugriff auf den Zieldienst ``` Wichtige Begriffe: | Begriff | Bedeutung | |---|---| | KDC | Key Distribution Center auf einem Domänencontroller | | TGT | Ticket Granting Ticket | | Dienstticket | Ticket für einen konkreten Dienst | | SPN | eindeutiger Dienstbezeichner eines Kontos | | Realm | Kerberos-Sicherheitsbereich, in AD meist zur Domäne zugeordnet | | PAC | enthält unter anderem Autorisierungsinformationen | | Delegierung | Weitergabe von Anmeldeinformationen unter definierten Bedingungen | Kerberos benötigt insbesondere: - funktionierende DNS-Auflösung, - erreichbaren KDC, - korrekte Zeit, - gültige Konten, - korrekte Kennwörter, - eindeutige SPNs, - einen zum Zielnamen passenden Dienstprinzipal. --- **25. Kerberos-Tickets prüfen** Tickets des aktuellen Anmeldekontexts: ```cmd klist ``` TGT anzeigen: ```cmd klist tgt ``` Zwischengespeicherte Tickets auflisten: ```cmd klist tickets ``` KDCs anzeigen: ```cmd klist query_bind ``` Zu prüfen sind: - Clientname, - Servername beziehungsweise SPN, - Kerberos-Realm, - Tickettyp, - Start- und Ablaufzeit, - Erneuerungszeit, - Verschlüsselungstyp, - Flags, - verwendeter KDC. Das Löschen des Ticketcaches verändert den Diagnosezustand: ```cmd klist purge ``` `klist purge` sollte erst eingesetzt werden, wenn: - vorhandene Tickets dokumentiert wurden, - klar ist, welcher Sicherheitskontext betroffen ist, - erneute Authentifizierung möglich ist, - keine kritische Sitzung unterbrochen wird, - der Test gezielt ein neues Ticket anfordern soll. Nach dem Löschen kann ein erneuter Zugriff auf die Zielressource ein neues Ticket auslösen. --- **26. Service Principal Names prüfen** SPNs eines Kontos anzeigen: ```cmd setspn -L ``` Bestimmten SPN suchen: ```cmd setspn -Q / ``` Beispiel: ```cmd setspn -Q HTTP\webserver.ad.example.local ``` Doppelte SPNs domänen- beziehungsweise gesamtstrukturweit suchen: ```cmd setspn -X ``` Mögliche SPN-Probleme: - SPN fehlt, - SPN ist dem falschen Konto zugeordnet, - SPN ist doppelt vorhanden, - Client verwendet Alias statt registriertem Hostnamen, - Dienstkonto wurde geändert, - Server wurde umbenannt, - Dienst läuft unter anderem Konto als erwartet, - alter SPN blieb nach Migration erhalten. SPNs dürfen nicht ohne vorherige Suche, Dokumentation und Prüfung verändert werden. Ein falsches Entfernen kann andere Dienste oder Benutzer beeinträchtigen. --- **27. Kerberos und NTLM unterscheiden** Anmeldesitzungen: ```cmd klist sessions ``` Tickets: ```cmd klist ``` Für bestimmte Verbindungen können zusätzlich Ereignisprotokolle, Dienstprotokolle oder geeignete Netzwerkaufzeichnungen erforderlich sein. Mögliche Hinweise auf NTLM statt Kerberos: - kein passendes Dienstticket vorhanden, - Zugriff erfolgt über IP-Adresse, - SPN für den verwendeten Namen fehlt, - Ziel befindet sich außerhalb der Kerberos-Vertrauensbeziehung, - Anwendung fordert ausdrücklich NTLM, - DNS- oder Namensproblem, - Kerberos-Anforderung schlägt fehl und ein Fallback ist möglich. Ein funktionierender Zugriff beweist deshalb nicht automatisch, dass Kerberos verwendet wurde. --- **28. Zugriff über IP-Adresse und Hostname vergleichen** Beispiel: ```text \\192.0.2.10\Freigabe \\server01\Freigabe \\server01.ad.example.local\Freigabe ``` Unterschiedliche Ergebnisse können auf Folgendes hinweisen: - DNS-Problem, - Alias-Problem, - SPN-Problem, - Kerberos funktioniert nur für einen bestimmten Namen, - Zertifikat passt nicht zum verwendeten Namen, - Anwendung verwendet unterschiedliche Sicherheitszonen, - IPv4 und IPv6 führen zu unterschiedlichen Zielen. Der Zugriff per IP-Adresse ist kein allgemeiner Ersatz für korrekte Namensauflösung. Bei Kerberos ist der verwendete Zielname für die SPN-Zuordnung entscheidend. --- **29. Kerberos-Ereignisse untersuchen** Relevante Protokolle können sein: - Sicherheitsprotokoll auf Client, Server und DC, - Systemprotokoll, - Kerberos-Key-Distribution-Center-Protokoll, - NETLOGON-Protokoll, - dienstspezifische Protokolle. PowerShell-Beispiel für aktuelle Sicherheitsereignisse: ```powershell Get-WinEvent -FilterHashtable @{ LogName = 'Security' StartTime = (Get-Date).AddHours(-2) } | Where-Object { $_.Id -in 4768, 4769, 4771, 4776 } | Select-Object TimeCreated, Id, Message ``` Typische Ereigniskategorien: | Kategorie | Mögliche Bedeutung | |---|---| | TGT wurde angefordert | Benutzer- oder Computerauthentifizierung | | Dienstticket wurde angefordert | Zugriff auf einen bestimmten SPN | | Kerberos-Vorauthentifizierung fehlgeschlagen | Kennwort, Zeit, Kontostatus oder anderer Authentifizierungsfehler | | Anmeldeinformationen wurden validiert | häufig NTLM-bezogene Prüfung | | Kontosperrung | wiederholte fehlerhafte Authentifizierung | Event-IDs müssen mit dem vollständigen Ereignistext und dem jeweiligen System ausgewertet werden. --- **30. Typische Fehlerbilder** | Symptom | Mögliche Ursache | Nächster Test | |---|---|---| | Domäne kann nicht gefunden werden | DNS oder DC-Erreichbarkeit | `ipconfig /all`, SRV-Abfrage, `nltest /dsgetdc` | | Anmeldung funktioniert offline, aber nicht im Firmennetz | DC-, DNS-, Zeit- oder Secure-Channel-Problem | DC-Suche, Zeit und Secure Channel | | Vertrauensstellung fehlgeschlagen | Computerkennwort oder Computerkonto inkonsistent | `Test-ComputerSecureChannel`, Replikation | | neues Kennwort funktioniert nur manchmal | unterschiedliche DC-Daten | verwendeten DC und Replikation prüfen | | Benutzer bleibt trotz Entsperrung gesperrt | gespeicherte alte Anmeldedaten | Sperrquelle und Sicherheitsereignisse | | GPO wird nicht angezeigt | falsche OU, Filterung oder Link | `gpresult`, GPMC | | GPO wird angezeigt, Einstellung fehlt | Überschreibung oder Erweiterungsfehler | Detailbericht und GroupPolicy-Protokoll | | Computerrichtlinie fehlt | Computerobjekt, Neustart oder Computerbereich | `gpresult /scope computer` | | Benutzerrichtlinie fehlt | Benutzerobjekt, Token oder Benutzerbereich | `gpresult /scope user` | | GPO funktioniert nur an einem Standort nicht | Site, DC, Replikation oder Netzwerk | DC-Zuordnung und Replikation | | SYSVOL nicht erreichbar | DNS, SMB, DC oder DFSR | Port 445, Freigabe und DC-Protokolle | | Kerberos-Ticket fehlt | SPN, DNS, KDC oder Anwendung | `klist`, `setspn -Q` | | Kerberos scheitert nur über Alias | fehlender SPN für Alias | verwendeten Namen und SPN prüfen | | Zugriff funktioniert per IP, nicht per Name | DNS, SPN oder Zertifikat | Namen einzeln prüfen | | Zugriff funktioniert per Name, nicht per IP | Kerberos- oder Anwendungsanforderung | Ticket und Zielkonfiguration | | Dienst funktioniert nur mit NTLM | SPN oder Delegierung | Dienstkonto und SPNs | | Replikation meldet RPC-Fehler | DNS, Firewall, RPC oder Partner offline | Namensauflösung und Ports | | Benutzer hat neue Gruppe, aber keinen Zugriff | altes Anmeldetoken | `whoami /groups`, erneute Anmeldung | | Fehler nur auf einem Client | lokaler DNS-, Cache-, Konto- oder Profilfehler | Vergleichsclient und lokale Konfiguration | | Fehler auf vielen Clients | zentrale AD-, DNS-, GPO- oder Netzwerkstörung | DCs, Replikation und Änderungen | | Fehler nach VM-Snapshot | Secure Channel oder Zeit zurückgesetzt | Zeit, Computerkonto und Secure Channel | --- **31. Vorgehensweise bei einer nicht angewendeten GPO** 1. Betroffenen Benutzer und Computer bestimmen. 2. Prüfen, ob Benutzer- und Computerobjekt in den erwarteten OUs liegen. 3. Verwendeten Domänencontroller dokumentieren. 4. DNS- und DC-Erreichbarkeit prüfen. 5. SYSVOL-Zugriff prüfen. 6. `gpresult` als HTML-Bericht erstellen. 7. angewendete und abgelehnte GPOs prüfen. 8. Sicherheitsfilterung und WMI-Filter prüfen. 9. Verknüpfung, Reihenfolge und Vererbung prüfen. 10. Loopbackverarbeitung berücksichtigen. 11. GroupPolicy-Operational-Protokoll auswerten. 12. AD- und SYSVOL-Replikation prüfen. 13. genau eine kontrollierte Korrektur durchführen. 14. Richtlinien erneut verarbeiten. 15. Ergebnisbericht und Benutzerfunktion erneut prüfen. --- **32. Vorgehensweise bei einer fehlgeschlagenen Anmeldung** 1. Exakte Meldung und Zeitpunkt erfassen. 2. Lokale und Domänenanmeldung unterscheiden. 3. Netzwerkverbindung prüfen. 4. DNS-Server und DNS-Suffix prüfen. 5. Domänencontroller über SRV-Einträge suchen. 6. verwendeten DC bestimmen. 7. Zeit und Zeitquelle prüfen. 8. Benutzerkonto auf Sperre, Ablauf und Deaktivierung prüfen. 9. Secure Channel des Clients prüfen. 10. Replikationsstatus der DCs prüfen. 11. Sicherheits- und Kerberos-Ereignisse auswerten. 12. gespeicherte Anmeldedaten, Dienste und Aufgaben berücksichtigen. 13. genau eine Maßnahme durchführen. 14. Anmeldung und Ressourcenabruf erneut testen. --- **33. Vorgehensweise bei Kerberos-Problemen** 1. verwendeten Zielnamen dokumentieren. 2. DNS-Auflösung dieses Namens prüfen. 3. Zeit von Client, Server und DC vergleichen. 4. KDC beziehungsweise DC-Erreichbarkeit prüfen. 5. vorhandene Tickets mit `klist` dokumentieren. 6. nach passendem Dienstticket suchen. 7. erwarteten SPN bestimmen. 8. SPN mit `setspn -Q` suchen. 9. Dienstkonto und tatsächlichen Dienstprozess vergleichen. 10. doppelte SPNs prüfen. 11. Sicherheits- und Kerberos-Ereignisse korrelieren. 12. Vertrauensstellung und Delegierung berücksichtigen. 13. Ticketcache nur kontrolliert leeren. 14. Zugriff erneut auslösen. 15. neues Ticket und Funktion prüfen. --- **34. Maßnahmen und Rückwege** **Ursache: falscher DNS-Server am Client** Nachweis: - Client verwendet einen nicht zuständigen DNS-Server, - AD-SRV-Einträge werden nicht korrekt aufgelöst, - interner DNS-Server liefert die erwarteten Einträge. Maßnahme: - DNS-Konfiguration kontrolliert auf die vorgesehenen internen DNS-Server korrigieren. Rollback: - ursprüngliche Adapter- oder DHCP-Konfiguration dokumentiert wiederherstellen. Verifikation: - SRV-Abfrage, - DC-Suche, - Anmeldung, - GPO-Verarbeitung, - Anwendungszugriff. --- **Ursache: fehlerhafter Secure Channel** Nachweis: - Secure-Channel-Prüfung schlägt fehl, - Computerkonto ist vorhanden, - DNS, Zeit und DC-Erreichbarkeit funktionieren, - Replikation ist ausreichend gesund. Maßnahme: - Secure Channel mit berechtigtem Konto kontrolliert reparieren. Rollback: - vorab dokumentierte Computer- und Domänenkonfiguration verwenden; - bei Fehlschlag nach freigegebenem Wiederherstellungsverfahren vorgehen. Verifikation: - Secure Channel erneut prüfen, - Neustart oder Anmeldung testen, - Gruppenrichtlinien und Ressourcen testen. --- **Ursache: GPO durch Sicherheitsfilterung ausgeschlossen** Nachweis: - `gpresult` nennt die GPO als abgelehnt, - Benutzer oder Computer besitzt nicht die erforderlichen Berechtigungen. Maßnahme: - Sicherheitsfilterung nach dem Minimalprinzip korrigieren. Rollback: - ursprüngliche ACL beziehungsweise Gruppenmitgliedschaft wiederherstellen. Verifikation: - neues Token berücksichtigen, - GPO aktualisieren, - `gpresult` erneut erzeugen, - konkrete Einstellung prüfen. --- **Ursache: doppelter SPN** Nachweis: - `setspn -Q` oder `setspn -X` zeigt den SPN mehrfach, - Kerberos-Ereignisse passen zum Fehler, - Dienstkonto und Zielname wurden bestätigt. Maßnahme: - falsche SPN-Zuordnung nach Freigabe entfernen und korrekte eindeutige Zuordnung sicherstellen. Rollback: - vorherige SPN-Zuordnungen vollständig dokumentieren. Verifikation: - neue Tickets anfordern, - Dienstticket prüfen, - Zugriff mit vorgesehenem Namen testen. --- **Ursache: AD-Replikationsfehler** Nachweis: - `repadmin` oder PowerShell zeigt konkrete Fehler, - betroffene Objekte oder Kennwörter unterscheiden sich zwischen DCs, - Fehlercode und Abhängigkeit wurden bestimmt. Maßnahme: - zugrunde liegendes DNS-, Netzwerk-, RPC-, Zeit-, Authentifizierungs- oder DC-Problem beheben. Rollback: - abhängig von der konkreten Änderung; - keine erzwungene Replikations- oder Metadatenbereinigung ohne Wiederherstellungsplan. Verifikation: - `repadmin /replsummary`, - `repadmin /showrepl`, - Objektvergleich, - Anmeldung und GPO-Verarbeitung. --- **35. Nachkontrolle** Nach jeder Maßnahme sind mindestens folgende Punkte erneut zu prüfen: - Client verwendet die vorgesehenen DNS-Server. - AD-SRV-Einträge werden korrekt aufgelöst. - vorgesehene Domänencontroller sind erreichbar. - Zeit und Zeitquelle sind plausibel. - Secure Channel funktioniert. - Benutzer- und Computerkonto sind aktiv. - Replikation zeigt keine zum Fehler gehörenden Störungen. - SYSVOL und NETLOGON sind erreichbar. - benötigte Gruppenmitgliedschaften sind im aktuellen Token enthalten. - erwartete GPOs werden angewendet. - abgelehnte GPOs sind fachlich erklärbar. - Gruppenrichtlinienprotokoll zeigt keine neuen relevanten Fehler. - erforderliches Kerberos-Ticket wird ausgestellt. - SPN ist eindeutig und dem richtigen Konto zugeordnet. - Benutzerfunktion wurde praktisch getestet. - keine unnötigen Berechtigungen wurden vergeben. - temporäre Diagnose- oder Protokollierungsfunktionen wurden beendet. - Ursache, Maßnahme, Rückweg und Ergebnis wurden dokumentiert. --- **36. Dokumentationsbeispiel** ```text Symptom: Die Laufwerkszuordnung aus der Gruppenrichtlinie wurde auf einem Client nicht erstellt. Zeitpunkt: 02.08.2026, 10:18 Uhr MESZ Betroffener Benutzer: max.mustermann Betroffener Computer: CLIENT-17 Verwendeter Domänencontroller: DC02.ad.example.local Nachweis: DNS-Auflösung, Zeit und SYSVOL-Zugriff waren erfolgreich. Der gpresult-Bericht zeigte die GPO als abgelehnt. Als Ablehnungsgrund wurde die Sicherheitsfilterung angegeben. Die erforderliche Benutzergruppe war im Active Directory eingetragen, fehlte aber im aktuellen Anmeldetoken. Ursache: Die Gruppenmitgliedschaft wurde erst nach Beginn der bestehenden Benutzersitzung hinzugefügt. Maßnahme: Der Benutzer meldete sich kontrolliert ab und erneut an. An der GPO und ihren Berechtigungen wurde nichts verändert. Rollback: Nicht erforderlich, da keine Konfiguration geändert wurde. Verifikation: whoami /groups zeigt die vorgesehene Gruppe. gpresult zeigt die angewendete GPO. Das Laufwerk wurde verbunden. Keine neuen Fehler im GroupPolicy-Protokoll. Prävention: Bei Änderungen an Gruppenmitgliedschaften wird künftig berücksichtigt, dass bestehende Anmeldetoken nicht automatisch vollständig erneuert werden. ``` --- **37. Entscheidungsbaum** ```text Domänenanmeldung, GPO oder Ressourcenzugriff gestört ↓ Stimmen IP-Konfiguration und interne DNS-Server? ├── Nein │ ↓ │ Netzwerk- und DNS-Konfiguration korrigieren │ └── Ja ↓ Werden AD-SRV-Einträge und DCs gefunden? ├── Nein │ ↓ │ DNS-Zone, SRV-Einträge und DC-Dienste prüfen │ └── Ja ↓ Sind DC und benötigte Ports erreichbar? ├── Nein │ ↓ │ Routing, Firewall, Standort und Dienste prüfen │ └── Ja ↓ Stimmen Zeit und Secure Channel? ├── Nein │ ↓ │ Zeitquelle oder Vertrauensbeziehung untersuchen │ └── Ja ↓ Ist die AD-Replikation fehlerfrei? ├── Nein │ ↓ │ Replikationsfehler nach Code und Richtung analysieren │ └── Ja ↓ Betrifft der Fehler Gruppenrichtlinien? ├── Ja │ ↓ │ gpresult, SYSVOL, Filter, OU und Ereignisse prüfen │ └── Nein ↓ Betrifft der Fehler Kerberos oder einen Dienst? ├── Ja │ ↓ │ Tickets, SPNs, Zielname und Dienstkonto prüfen │ └── Nein ↓ Konto, Gruppen, Berechtigungen und Anwendung untersuchen ``` --- **38. Typische Prüfungsfragen** **Warum ist DNS für Active Directory besonders wichtig?**
Antwort anzeigen Active Directory verwendet DNS und insbesondere SRV-Einträge, damit Clients Domänencontroller, Kerberos-Dienste und Global Catalogs finden. Eine reine Auflösung externer Internetnamen reicht für eine funktionierende Domänenumgebung nicht aus.
**Warum kann ein neues Kennwort an einem Client funktionieren und an einem anderen nicht?**
Antwort anzeigen Die Clients können unterschiedliche Domänencontroller verwenden. Bei einer Replikationsstörung ist das neue Kennwort möglicherweise noch nicht auf allen benötigten Domänencontrollern verfügbar.
**Wozu dient `gpresult`?**
Antwort anzeigen `gpresult` zeigt die resultierenden Gruppenrichtlinien für einen Benutzer oder Computer. Es kann angewendete und abgelehnte GPOs, Sicherheitsgruppen, Filter und weitere Verarbeitungsinformationen darstellen.
**Warum ist `gpupdate /force` noch keine Fehlerbehebung?**
Antwort anzeigen Der Befehl löst eine erneute Verarbeitung der Gruppenrichtlinien aus. Er erklärt jedoch nicht, warum eine GPO zuvor nicht angewendet wurde. Dafür müssen Ergebnisbericht, Ereignisse, Filterung, Verknüpfung und Abhängigkeiten geprüft werden.
**Warum kann eine neue Gruppenmitgliedschaft trotz korrektem AD-Eintrag noch wirkungslos sein?**
Antwort anzeigen Das aktuelle Anmeldetoken wurde möglicherweise vor der Gruppenänderung erzeugt. Die neue Mitgliedschaft ist dann noch nicht im Token enthalten und wird häufig erst nach erneuter Anmeldung wirksam.
**Welche drei grundlegenden Abhängigkeiten benötigt Kerberos besonders?**
Antwort anzeigen Kerberos benötigt insbesondere funktionierende DNS-Auflösung, ausreichend genaue Zeitsynchronisation und korrekte beziehungsweise eindeutige Dienstidentitäten in Form von SPNs.
**Was ist ein SPN?**
Antwort anzeigen Ein Service Principal Name identifiziert eine konkrete Dienstinstanz und ist einem Active-Directory-Konto zugeordnet. Der KDC verwendet ihn, um ein Dienstticket für den richtigen Dienst auszustellen.
**Warum kann ein doppelter SPN die Kerberos-Authentifizierung verhindern?**
Antwort anzeigen Der KDC kann den Dienst nicht eindeutig einem Konto zuordnen. Dadurch kann kein korrektes Dienstticket für die erwartete Dienstidentität ausgestellt werden.
**Warum sollte ein Computer nicht sofort aus der Domäne entfernt werden?**
Antwort anzeigen Dadurch wird der für die Diagnose wichtige Zustand verändert. Außerdem kann die Maßnahme zusätzliche Probleme mit Computerkonto, Profilen, Berechtigungen, Zertifikaten und verwalteter Konfiguration erzeugen.
**Worin unterscheiden sich AD- und SYSVOL-Replikation bei einer GPO?**
Antwort anzeigen Der Group Policy Container mit den Verzeichnisinformationen liegt im Active Directory. Das Group Policy Template mit den dateibasierten Richtlinieninhalten liegt in SYSVOL. Beide Bestandteile müssen verfügbar und konsistent sein.
--- **39. Prüfungsfallen** - öffentlichen DNS-Server auf einem Domänenmitglied eintragen. - erfolgreichen Ping als Nachweis für funktionierendes Active Directory bewerten. - nur den A-Eintrag, aber keine SRV-Einträge prüfen. - IP-Erreichbarkeit mit funktionierender Authentifizierung gleichsetzen. - Zeitabweichung übersehen. - Domänencontroller und DNS-Server ungeprüft neu starten. - Computer sofort aus der Domäne entfernen. - Computerkonto ohne Sicherung löschen. - Secure Channel reparieren, obwohl DNS oder Replikation gestört ist. - Gruppenmitgliedschaft im AD mit dem aktuellen Token gleichsetzen. - Benutzer wegen fehlender Berechtigung in eine weitreichende Administratorgruppe aufnehmen. - `gpupdate /force` als alleinige Fehleranalyse verwenden. - Benutzer- und Computerrichtlinien verwechseln. - falschen Benutzerkontext für `gpresult` verwenden. - OU des Benutzers prüfen, obwohl eine Computerrichtlinie betroffen ist. - Sicherheitsfilterung, WMI-Filter oder Loopback übersehen. - GPO löschen, statt Verknüpfung und Filterung zu untersuchen. - SYSVOL-Zugriff nicht prüfen. - AD-Replikation prüfen, aber SYSVOL-Replikation übersehen. - Replikation ungeprüft erzwingen. - einzelne `dcdiag`-Warnung ohne Zusammenhang als Ursache bewerten. - Event-ID ohne Provider und vollständigen Text interpretieren. - Kerberos und NTLM nicht unterscheiden. - Zugriff per IP-Adresse als dauerhafte Lösung verwenden. - Ticketcache vor der Dokumentation löschen. - SPN ohne vorherige Suche verändern. - gültigen SPN dem falschen Dienstkonto zuordnen. - doppelten SPN ungeprüft entfernen. - mehrere Änderungen gleichzeitig durchführen. - nach einer Maßnahme weder Ticket noch GPO-Ergebnis erneut prüfen. - keine praktische Benutzerfunktion testen. --- **40. Checkliste** - [ ] exakter Fehlertext wurde dokumentiert. - [ ] Fehlerzeitpunkt und Zeitzone wurden erfasst. - [ ] betroffener Benutzer wurde bestimmt. - [ ] betroffener Computer wurde bestimmt. - [ ] betroffener Zielserver oder Dienst wurde bestimmt. - [ ] lokale und Domänenanmeldung wurden unterschieden. - [ ] IP-Konfiguration wurde geprüft. - [ ] vorgesehene interne DNS-Server werden verwendet. - [ ] DNS-Suffix wurde geprüft. - [ ] AD-SRV-Einträge wurden geprüft. - [ ] verwendeter Domänencontroller wurde bestimmt. - [ ] Standort beziehungsweise AD-Site wurde berücksichtigt. - [ ] DC-Erreichbarkeit wurde geprüft. - [ ] benötigte Ports wurden geprüft. - [ ] SYSVOL wurde geprüft. - [ ] NETLOGON wurde geprüft. - [ ] Zeit und Zeitzone wurden geprüft. - [ ] Zeitquelle wurde geprüft. - [ ] Secure Channel wurde geprüft. - [ ] Benutzerkonto wurde auf Sperre und Ablauf geprüft. - [ ] Computerkonto wurde geprüft. - [ ] AD-Gruppenmitgliedschaften wurden geprüft. - [ ] aktuelles Benutzertoken wurde geprüft. - [ ] AD-Replikation wurde geprüft. - [ ] letzter erfolgreicher Replikationszeitpunkt wurde dokumentiert. - [ ] Replikationsrichtung wurde berücksichtigt. - [ ] `dcdiag` wurde bei DC-Problemen ausgewertet. - [ ] FSMO-Rollen wurden bei passendem Fehlerbild geprüft. - [ ] Benutzer- und Computerrichtlinien wurden unterschieden. - [ ] `gpresult` wurde im richtigen Kontext erzeugt. - [ ] angewendete und abgelehnte GPOs wurden geprüft. - [ ] OU und GPO-Verknüpfung wurden geprüft. - [ ] Sicherheitsfilterung wurde geprüft. - [ ] WMI-Filter wurde geprüft. - [ ] Vererbung und Erzwingen wurden geprüft. - [ ] Loopbackverarbeitung wurde berücksichtigt. - [ ] GroupPolicy-Operational-Protokoll wurde geprüft. - [ ] vorhandene Kerberos-Tickets wurden dokumentiert. - [ ] verwendeter Zielname wurde dokumentiert. - [ ] benötigter SPN wurde bestimmt. - [ ] SPN-Zuordnung wurde geprüft. - [ ] doppelte SPNs wurden bei Bedarf gesucht. - [ ] Kerberos- und Sicherheitsereignisse wurden zeitlich korreliert. - [ ] letzte Änderungen wurden berücksichtigt. - [ ] funktionierender Vergleichsclient wurde verwendet. - [ ] genau eine kontrollierte Maßnahme wurde durchgeführt. - [ ] Rückweg wurde festgelegt. - [ ] Anmeldung wurde erneut getestet. - [ ] GPO-Ergebnis wurde erneut geprüft. - [ ] Kerberos-Ticket wurde erneut geprüft. - [ ] konkrete Benutzerfunktion wurde getestet. - [ ] Ursache, Maßnahme und Ergebnis wurden dokumentiert. - [ ] vorbeugende Maßnahme wurde festgelegt. --- **41. Schnellreferenz** | Beobachtung | Nächstes Werkzeug | |---|---| | Domäne wird nicht gefunden | `ipconfig /all`, `nslookup`, `nltest /dsgetdc` | | falscher DNS-Server | Adapter-, DHCP- und DNS-Konfiguration | | DC wird nicht gefunden | SRV-Abfragen und `nltest` | | Anmeldung nur offline möglich | DC-Erreichbarkeit, Zeit, Secure Channel | | Vertrauensstellung fehlgeschlagen | `Test-ComputerSecureChannel`, `nltest` | | neues Kennwort funktioniert nicht überall | `repadmin`, verwendeten DC bestimmen | | Replikationsfehler | `repadmin /replsummary`, `repadmin /showrepl` | | DC-Zustand unklar | `dcdiag /v` | | DNS auf DC fehlerhaft | `dcdiag /test:dns /v` | | GPO fehlt | `gpresult`, GPMC | | GPO abgelehnt | `gpresult /h`, Sicherheitsfilterung | | GPO-Einstellung fehlt | Detailbericht und GroupPolicy-Protokoll | | SYSVOL nicht erreichbar | DNS, SMB-Port und Freigaben | | Gruppenänderung wirkt nicht | `whoami /groups`, erneute Anmeldung | | Konto wird wiederholt gesperrt | Sicherheitsprotokoll und gespeicherte Anmeldedaten | | Kerberos-Ticket fehlt | `klist`, DNS, Zeit | | Dienstticket fehlt | `klist`, `setspn -Q` | | doppelter SPN vermutet | `setspn -X` | | Fehler nur über Alias | DNS- und SPN-Zuordnung | | Zugriff nur über IP möglich | DNS, Zielname, SPN und Kerberos | | Fehler nur an einem Standort | AD-Site, DC-Auswahl und Replikation | | Fehler nur auf einem Client | lokale DNS-, Konto-, Token- oder Profilprüfung | --- **Merksatz** > Active-Directory-Fehler werden von unten nach oben analysiert: Netzwerk, DNS, Domänencontroller, Zeit, Secure Channel, Replikation, Konten, Gruppenrichtlinien und Kerberos. Erst wenn die Abhängigkeiten nachweislich funktionieren, wird die betroffene Richtlinie, Berechtigung oder Anwendung verändert. Jede Änderung benötigt einen Rückweg und eine erneute Funktionsprüfung. --- **Quellen und weiterführende Dokumentation** **Offizielle Microsoft-Dokumentation** - [Microsoft Learn – AD DS Troubleshooting](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/ad-ds-troubleshooting) - [Microsoft Learn – Troubleshooting Active Directory Replication Problems](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/troubleshoot/troubleshooting-active-directory-replication-problems) - [Microsoft Learn – Diagnose Active Directory Replication Failures](https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/diagnose-replication-failures) - [Microsoft Learn – Active Directory Replication Error 1722](https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/replication-error-1722-rpc-server-unavailable) - [Microsoft Learn – Active Directory Replication Error 5](https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/replications-fail-with-error-5) - [Microsoft Learn – Group Policy Processing](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/group-policy/group-policy-processing) - [Microsoft Learn – Applying Group Policy Troubleshooting Guidance](https://learn.microsoft.com/en-us/troubleshoot/windows-server/group-policy/applying-group-policy-troubleshooting-guidance) - [Microsoft Learn – Kerberos Authentication Troubleshooting Guidance](https://learn.microsoft.com/en-us/troubleshoot/windows-server/windows-security/kerberos-authentication-troubleshooting-guidance) - [Microsoft Learn – Domain Controller Is Not Functioning Correctly](https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/domain-controller-not-functioning-correctly) - [Microsoft Learn – Repadmin](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/cc770963(v=ws.11)) - [Microsoft Learn – Dcdiag](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/dcdiag) - [Microsoft Learn – Gpresult](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/gpresult) - [Microsoft Learn – Gpupdate](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/gpupdate) - [Microsoft Learn – Klist](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/klist) - [Microsoft Learn – Setspn](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/setspn) - [Microsoft Learn – W32tm](https://learn.microsoft.com/en-us/windows-server/networking/windows-time-service/windows-time-service-tools-and-settings) - [Microsoft Learn – Test-ComputerSecureChannel](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.management/test-computersecurechannel) - [Microsoft Learn – Get-ADReplicationFailure](https://learn.microsoft.com/en-us/powershell/module/activedirectory/get-adreplicationfailure) - [Microsoft Learn – Get-ADReplicationPartnerMetadata](https://learn.microsoft.com/en-us/powershell/module/activedirectory/get-adreplicationpartnermetadata) # 8.3 Datei-, Freigabe-, Rechte- und Druckdienste analysieren Datei- und Druckdienstfehler entstehen häufig nicht durch eine einzelne Komponente. Namensauflösung, Netzwerk, Authentifizierung, Freigabeberechtigungen, Dateisystemrechte, Gruppenmitgliedschaften, SMB-Einstellungen, DFS, Speicherplatz und Druckwarteschlangen wirken zusammen. Grundregel: > Zuerst feststellen, ob bereits die Verbindung, die Authentifizierung, die Freigabe, die Datei oder erst die konkrete Aktion fehlschlägt. --- **1. Diagnosekette bei Dateizugriffen** ```text Client ↓ DNS-Auflösung ↓ Netzwerk und TCP 445 ↓ SMB-Dienst ↓ Authentifizierung ↓ Freigabeberechtigung ↓ NTFS-Berechtigung ↓ Datei, Ordner, Sperre oder Anwendung ↓ Datenträger und Backend ``` Jede Stufe muss getrennt geprüft werden. | Prüfschritt | Typische Frage | |---|---| | Namensauflösung | Zeigt der Servername auf die richtige IP-Adresse? | | Netzwerk | Ist der Server über den vorgesehenen Pfad erreichbar? | | SMB-Port | Ist TCP 445 erreichbar? | | SMB-Dienst | Nimmt der Server SMB-Verbindungen an? | | Authentifizierung | Mit welchem Konto erfolgt der Zugriff? | | Freigaberecht | Darf das Konto die Freigabe verwenden? | | NTFS-Recht | Darf das Konto den Ordner oder die Datei verwenden? | | Objektzustand | Existiert die Datei und ist sie verfügbar? | | Sperre | Wird die Datei von einem Prozess blockiert? | | Speicher | Sind Datenträger, Quota und Backend funktionsfähig? | --- **2. Fehler exakt aufnehmen** Zu dokumentieren sind: - vollständiger UNC-Pfad; - Servername und Freigabename; - betroffener Benutzer; - betroffener Client; - genaue Aktion; - vollständiger Fehlertext; - Fehlercode; - Zeitpunkt mit Zeitzone; - verwendete Netzwerkverbindung; - funktioniert der Zugriff über IP-Adresse, Kurzname oder FQDN; - funktioniert eine andere Freigabe auf demselben Server; - funktioniert dieselbe Freigabe für einen anderen Benutzer; - funktioniert derselbe Benutzer an einem anderen Client; - trat der Fehler nach einer Rechte-, Gruppen-, GPO-, DNS- oder Serveränderung auf. Beispiele für unterschiedliche Aktionen: - Freigabe auflisten; - Ordner öffnen; - Datei lesen; - Datei erstellen; - Datei ändern; - Datei löschen; - Datei umbenennen; - Unterordner erstellen; - Berechtigungen ändern; - Eigentümer übernehmen. Ein Benutzer kann einen Ordner möglicherweise öffnen, aber keine Datei erstellen oder löschen. Deshalb genügt die Aussage „Zugriff funktioniert nicht“ nicht. --- **3. UNC-Pfad und Ziel bestimmen** Typischer UNC-Pfad: ```text \\fileserver01\Daten ``` Mit FQDN: ```text \\fileserver01.ad.example.local\Daten ``` Über DFS: ```text \\ad.example.local\Daten\Abteilung ``` Zu unterscheiden sind: - tatsächlicher Dateiserver; - DNS-Name oder Alias; - DFS-Namespace; - Freigabename; - lokaler Pfad auf dem Server; - verbundenes Netzlaufwerk; - eventuell verwendeter Cluster- oder Failovername. Ein Netzlaufwerk wie `H:` verdeckt den tatsächlichen UNC-Pfad. Dieser kann beispielsweise mit folgendem Befehl geprüft werden: ```cmd net use ``` PowerShell: ```powershell Get-SmbMapping ``` --- **4. DNS-Auflösung prüfen** ```powershell Resolve-DnsName fileserver01 ``` ```powershell Resolve-DnsName fileserver01.ad.example.local ``` ```cmd nslookup fileserver01 ``` Zusätzlich prüfen: ```cmd ping fileserver01 ``` Der Ping dient hier hauptsächlich dazu, den aufgelösten Namen und die Zieladresse zu sehen. Er beweist nicht, dass SMB funktioniert. Zu vergleichen sind: - Kurzname; - FQDN; - IP-Adresse; - erwartete Serveradresse; - IPv4- und IPv6-Ergebnis; - DNS-Alias; - DFS-Namespace-Name. Unterschiedliche Ergebnisse können auf Folgendes hinweisen: - falscher oder veralteter DNS-Eintrag; - falsches DNS-Suffix; - DNS-Cache; - `hosts`-Datei; - alter Serveralias; - DFS verweist auf ein anderes Ziel; - IPv4 und IPv6 führen über unterschiedliche Pfade; - Kerberos-SPN passt nicht zum verwendeten Namen. --- **5. SMB-Port prüfen** Windows: ```powershell Test-NetConnection fileserver01 -Port 445 ``` Ausführlicher: ```powershell Test-NetConnection fileserver01 ` -Port 445 ` -InformationLevel Detailed ``` Linux: ```bash nc -vz fileserver01 445 ``` Ein erfolgreicher Test auf TCP 445 zeigt: - der Name wurde aufgelöst; - eine Route zum Ziel ist vorhanden; - der TCP-Verbindungsaufbau war möglich; - auf dem Ziel oder einem vorgeschalteten System wurde die Verbindung angenommen. Er beweist noch nicht: - erfolgreiche SMB-Authentifizierung; - Zugriff auf eine bestimmte Freigabe; - ausreichende Berechtigungen; - Verfügbarkeit einer bestimmten Datei; - Funktionsfähigkeit des Storage-Backends. --- **6. SMB-Clientverbindungen prüfen** Aktuelle SMB-Verbindungen: ```powershell Get-SmbConnection ``` Ausgewählte Informationen: ```powershell Get-SmbConnection | Select-Object ServerName, ShareName, UserName, Credential, Dialect, NumOpens ``` SMB-Zuordnungen: ```powershell Get-SmbMapping ``` Klassische Anzeige: ```cmd net use ``` Dabei sind besonders zu prüfen: - Servername; - Freigabename; - verwendetes Benutzerkonto; - Verbindungsstatus; - SMB-Dialekt; - bereits bestehende Verbindungen zum selben Server; - Verbindung über Alias, Kurzname oder FQDN. --- **7. Konflikt durch unterschiedliche Anmeldedaten** Windows verwendet für Verbindungen zu einem Server nicht beliebig viele verschiedene Anmeldeinformationen innerhalb desselben Benutzerkontexts. Typisches Fehlerbild: ```text Mehrfache Verbindungen zu einem Server oder einer freigegebenen Ressource von demselben Benutzer unter Verwendung mehrerer Benutzernamen sind nicht zulässig. ``` Bestehende Verbindungen anzeigen: ```cmd net use ``` Gespeicherte Anmeldeinformationen anzeigen: ```cmd cmdkey /list ``` Mögliche Ursachen: - alte Verbindung zum selben Server; - Verbindung über einen anderen Freigabenamen; - gespeicherte falsche Anmeldedaten; - Dienst oder Skript verwendet ein anderes Konto; - Server wird einmal über Kurzname und einmal über Alias angesprochen; - Laufwerkszuordnung wurde bereits mit anderen Anmeldedaten hergestellt. Verbindungen dürfen nicht pauschal gelöscht werden, ohne ihre Verwendung zu prüfen. Ein Trennen kann geöffnete Dateien oder Anwendungen unterbrechen. Gezieltes Trennen einer Zuordnung: ```cmd net use Z: /delete ``` Gezieltes Trennen eines UNC-Ziels: ```cmd net use \\fileserver01\Daten /delete ``` --- **8. Freigaben auf dem Server prüfen** Vorhandene SMB-Freigaben: ```powershell Get-SmbShare ``` Bestimmte Freigabe: ```powershell Get-SmbShare -Name Daten ``` Wichtige Eigenschaften: ```powershell Get-SmbShare -Name Daten | Select-Object Name, Path, Description, ScopeName, FolderEnumerationMode, EncryptData, ConcurrentUserLimit ``` Klassische Anzeige: ```cmd net share ``` Zu prüfen sind: - Freigabe existiert; - Freigabename ist korrekt; - lokaler Zielpfad existiert; - Datenträger oder Mountpoint ist verfügbar; - Freigabe zeigt nicht auf einen alten Pfad; - Freigabe ist im richtigen Server- oder Cluster-Scope vorhanden; - erforderliche SMB-Einstellungen sind aktiv; - versteckte Freigabe mit `$` wurde korrekt angegeben. Administrative Freigaben wie `C$` benötigen normalerweise administrative Berechtigungen und sind kein geeigneter allgemeiner Funktionstest für normale Benutzer. --- **9. Freigabeberechtigungen prüfen** ```powershell Get-SmbShareAccess -Name Daten ``` Beispielausgabe: ```text Name AccountName AccessControlType AccessRight ---- ----------- ----------------- ----------- Daten AD\GG-Dateidienst-Lesen Allow Read Daten AD\GG-Dateidienst-Ändern Allow Change ``` Wichtige Freigaberechte: | Freigaberecht | Grundsätzliche Wirkung | |---|---| | Lesen | Inhalte anzeigen und Dateien lesen | | Ändern | zusätzlich erstellen, ändern und löschen | | Vollzugriff | zusätzlich Freigabeberechtigungen verwalten | Die genaue wirksame Berechtigung ergibt sich nicht allein aus dieser Tabelle. Verweigerungen, Gruppenmitgliedschaften und NTFS-Berechtigungen müssen zusätzlich berücksichtigt werden. --- **10. NTFS-Berechtigungen prüfen** PowerShell: ```powershell Get-Acl 'D:\Freigaben\Daten' | Format-List ``` Einzelne Zugriffsregeln: ```powershell (Get-Acl 'D:\Freigaben\Daten').Access | Select-Object IdentityReference, FileSystemRights, AccessControlType, IsInherited, InheritanceFlags, PropagationFlags ``` Kommandozeile: ```cmd icacls D:\Freigaben\Daten ``` Rekursives Auslesen kann bei großen Verzeichnisstrukturen sehr umfangreich und belastend sein. Es sollte nur gezielt eingesetzt werden. Zu prüfen sind: - Benutzer- und Gruppeneinträge; - Zulassen oder Verweigern; - Vererbung; - nur für diesen Ordner geltende Rechte; - Rechte für Unterordner und Dateien; - Eigentümer; - explizite Einträge; - geerbte Einträge; - unterbrochene Vererbung; - abweichende Rechte auf dem betroffenen Unterordner oder der Datei. --- **11. Freigabe- und NTFS-Rechte gemeinsam bewerten** Bei einem SMB-Zugriff wirken grundsätzlich beide Ebenen: ```text wirksames Freigaberecht + wirksames NTFS-Recht ↓ restriktivere wirksame Kombination ``` Beispiele: | Freigabe | NTFS | Ergebnis über SMB | |---|---|---| | Lesen | Ändern | Lesen | | Ändern | Lesen | Lesen | | Vollzugriff | Ändern | Ändern | | Vollzugriff | Vollzugriff | Vollzugriff | | Ändern | keine Berechtigung | kein Zugriff | Beim lokalen Zugriff auf den Serverpfad gelten die Freigabeberechtigungen nicht. Dort werden nur die Dateisystemberechtigungen ausgewertet. Deshalb kann ein lokaler Test auf dem Server funktionieren, während der Zugriff über SMB fehlschlägt. --- **12. Lesen, Ändern und Vollzugriff unterscheiden** Typische NTFS-Rechte: | Recht | Bedeutung | |---|---| | Ordnerinhalt anzeigen | Ordner durchsuchen und Inhalte auflisten | | Lesen | Inhalte und Eigenschaften lesen | | Schreiben | Dateien oder Daten erstellen beziehungsweise schreiben | | Lesen und Ausführen | Dateien lesen und ausführbare Dateien starten | | Ändern | lesen, schreiben, ausführen und löschen | | Vollzugriff | zusätzlich Berechtigungen und Eigentum verwalten | Für normale gemeinsame Datenordner reicht häufig `Ändern`. `Vollzugriff` sollte nicht ohne fachlichen Grund vergeben werden. --- **13. Löschen benötigt besondere Beachtung** Zum Löschen eines Objekts kann abhängig von der ACL eines der folgenden Rechte entscheidend sein: - `Löschen` auf der Datei oder dem Ordner; - `Unterordner und Dateien löschen` auf dem übergeordneten Ordner. Dadurch können scheinbar widersprüchliche Situationen entstehen: - Benutzer kann eine Datei ändern, aber nicht löschen; - Benutzer kann eine Datei löschen, obwohl die Datei selbst keinen offensichtlichen Lösch-Eintrag zeigt; - Benutzer kann Dateien erstellen, aber nicht umbenennen; - Benutzer kann Ordner öffnen, aber bestimmte Unterordner nicht auflisten. Die Berechtigungen müssen deshalb auf dem betroffenen Objekt und dem übergeordneten Ordner geprüft werden. --- **14. Vererbung kontrollieren** ```powershell (Get-Acl 'D:\Freigaben\Daten\Abteilung').AreAccessRulesProtected ``` Mögliche Zustände: - Vererbung aktiv; - Vererbung deaktiviert und geerbte Einträge kopiert; - Vererbung deaktiviert und geerbte Einträge entfernt; - einzelne explizite Rechte ergänzen die geerbten Rechte; - explizite Verweigerung schränkt geerbte Zulassung ein. Typische Fehler: - neuer Unterordner übernimmt unerwartete Rechte; - Vererbung wurde an einer Zwischenebene unterbrochen; - Berechtigung gilt nur für den aktuellen Ordner; - Berechtigung gilt nur für Unterordner; - migrierte Dateien besitzen alte ACLs; - Eigentümer oder Vererbungsquelle stimmt nicht mehr. Berechtigungen sollten nicht rekursiv ersetzt werden, bevor Umfang, Vererbung und Rückweg vollständig geklärt sind. --- **15. Gruppenmitgliedschaften prüfen** AD-Mitgliedschaften eines Benutzers: ```powershell Get-ADPrincipalGroupMembership max.mustermann | Select-Object Name ``` Aktuelle Gruppen im Anmeldetoken: ```cmd whoami /groups ``` Aktuelles Konto: ```cmd whoami ``` Benutzer-SID: ```cmd whoami /user ``` Berechtigungen des aktuellen Tokens: ```cmd whoami /priv ``` Wichtige Unterscheidung: ```text Mitgliedschaft im Active Directory ≠ Mitgliedschaft im bereits erzeugten Anmeldetoken ``` Wurde ein Benutzer gerade einer Gruppe hinzugefügt, kann eine erneute Anmeldung erforderlich sein. Eine bloße Sperrung und Entsperrung des Bildschirms erzeugt normalerweise kein vollständig neues interaktives Anmeldetoken. --- **16. Effektive Berechtigungen bewerten** Die grafische Registerkarte befindet sich üblicherweise unter: ```text Eigenschaften → Sicherheit → Erweitert → Effektiver Zugriff ``` Dabei muss der richtige Benutzer beziehungsweise Sicherheitsprinzipal ausgewählt werden. Zu berücksichtigen sind: - direkte Benutzerrechte; - verschachtelte Gruppen; - Domänen- und lokale Gruppen; - geerbte Rechte; - explizite Rechte; - Verweigerungen; - aktuelles Token; - Share- und NTFS-Ebene; - Zugriff über DFS oder direkt auf den Zielserver. Die Anzeige der effektiven NTFS-Rechte ersetzt nicht die Prüfung der Freigabeberechtigungen. --- **17. Zulassen und Verweigern** Eine explizite Verweigerung kann ein ansonsten gewährtes Recht blockieren. Trotzdem darf nicht vereinfacht angenommen werden, dass jede sichtbare Verweigerung immer sämtliche Zulassungen überschreibt. Die Auswertung hängt unter anderem ab von: - expliziten und geerbten Einträgen; - Benutzer- und Gruppenzugehörigkeit; - Reihenfolge der kanonischen ACL; - betroffenem Einzelrecht; - Objekt- und Vererbungsbereich; - Share- und NTFS-Ebene. Verweigerungen sollten sparsam verwendet werden. Eine saubere Gruppen- und Ordnerstruktur ist häufig leichter zu analysieren. --- **18. Access-Based Enumeration** Access-Based Enumeration kann Ordner vor Benutzern ausblenden, die darauf keine Berechtigung besitzen. Einstellung anzeigen: ```powershell Get-SmbShare -Name Daten | Select-Object FolderEnumerationMode ``` Mögliche Folge: - Ordner existiert; - direkter Zugriff kann abhängig von den Rechten möglich sein; - Ordner erscheint beim Auflisten der Freigabe nicht. Ein ausgeblendeter Ordner wurde daher nicht zwangsläufig gelöscht oder nicht repliziert. --- **19. Geöffnete Dateien und SMB-Sitzungen prüfen** Auf dem Dateiserver: ```powershell Get-SmbSession ``` Geöffnete Dateien: ```powershell Get-SmbOpenFile ``` Gefiltert nach Pfad: ```powershell Get-SmbOpenFile | Where-Object { $_.Path -like '*\Daten\*' } ``` Wichtige Informationen: - Clientcomputer; - Benutzername; - Sitzungs-ID; - Dateipfad; - Anzahl geöffneter Dateien; - verbundene Zeit; - Leerlaufzeit; - verwendeter SMB-Dialekt. Eine Sitzung oder Datei darf nicht ungeprüft geschlossen werden. Nicht gespeicherte Daten können verloren gehen. --- **20. Dateisperren untersuchen** Typische Meldungen: - Datei wird von einem anderen Prozess verwendet; - Zugriff verweigert; - Dokument ist für die Bearbeitung gesperrt; - schreibgeschützter Zugriff; - Umbenennen oder Löschen nicht möglich. Mögliche Ursachen: - Datei ist auf einem anderen Client geöffnet; - Anwendung verwendet eine eigene Sperrdatei; - Virenscanner oder Indexdienst greift auf die Datei zu; - Backup- oder Synchronisationssoftware hält ein Handle; - Prozess auf dem Server verwendet die Datei; - vorherige Anwendungssitzung wurde nicht sauber beendet; - Benutzer besitzt kein Änderungs- oder Löschrecht; - Datei oder Ordner ist schreibgeschützt; - Anwendung verwendet ein eigenes Check-out-Verfahren. Werkzeuge: - `Get-SmbOpenFile`; - Computerverwaltung → Freigegebene Ordner → Geöffnete Dateien; - Sysinternals Handle; - Process Explorer; - Process Monitor; - anwendungsspezifische Protokolle. Nicht jede Meldung über eine „gesperrte Datei“ beweist eine technische SMB-Sperre. Anwendungen können eigene Sperrmechanismen verwenden. --- **21. SMB-Serverkonfiguration prüfen** ```powershell Get-SmbServerConfiguration ``` Ausgewählte Werte: ```powershell Get-SmbServerConfiguration | Select-Object EnableSMB1Protocol, EnableSMB2Protocol, RequireSecuritySignature, EncryptData, EnableLeasing, EnableOplocks, AuditSmb1Access ``` Clientkonfiguration: ```powershell Get-SmbClientConfiguration ``` Zu prüfen sind: - unterstützter SMB-Dialekt; - SMB-Signierung; - SMB-Verschlüsselung; - Gastzugriff; - alte SMB-Versionen; - Richtlinienänderungen; - Kompatibilität mit NAS, Scanner oder Altgerät; - Abweichungen zwischen funktionierendem und betroffenem Client. SMB 1 darf nicht pauschal als Problemlösung aktiviert werden. Das Protokoll ist veraltet und besitzt erhebliche Sicherheitsnachteile. Bei Altgeräten ist eine Aktualisierung, Segmentierung oder Ablösung zu prüfen. --- **22. Verwendeten SMB-Dialekt bestimmen** ```powershell Get-SmbConnection | Select-Object ServerName, ShareName, Dialect, Signed, Encrypted ``` Mögliche Beobachtungen: - moderner Client verwendet unerwartet alten Dialekt; - Signierung wird verlangt, aber nicht unterstützt; - Verschlüsselung wird verlangt, aber nicht ausgehandelt; - Verbindung zu einem alten NAS scheitert; - Verbindung über einen anderen Namen erzeugt einen anderen Authentifizierungsweg. Die tatsächlich verwendete Verbindung muss geprüft werden. Eine allgemeine Servereinstellung beweist noch nicht, welcher Dialekt in einer bestimmten Sitzung ausgehandelt wurde. --- **23. Kerberos und NTLM bei SMB** Tickets prüfen: ```cmd klist ``` Für SMB ist typischerweise ein Dienstticket für einen SPN nach folgendem Muster relevant: ```text cifs/fileserver01 ``` SPN suchen: ```cmd setspn -Q cifs/fileserver01 ``` Mit FQDN: ```cmd setspn -Q cifs/fileserver01.ad.example.local ``` Mögliche Ursachen für NTLM statt Kerberos: - Zugriff über IP-Adresse; - fehlender oder falscher SPN; - Zugriff über nicht registrierten Alias; - DNS-Problem; - keine geeignete Vertrauensbeziehung; - Anwendung oder Gerät unterstützt Kerberos nicht; - Kerberos schlägt fehl und NTLM-Fallback ist möglich. Ein erfolgreicher SMB-Zugriff beweist nicht automatisch, dass Kerberos verwendet wurde. --- **24. Zugriff über Alias prüfen** Beispiel: ```text \\fileserver01\Daten \\datenserver\Daten ``` Beide Namen können auf dieselbe IP-Adresse zeigen, aber für Kerberos unterschiedliche Dienstidentitäten darstellen. Zu prüfen sind: - DNS-Eintrag des Alias; - CIFS-SPN für den verwendeten Namen; - Konto, dem der SPN zugeordnet ist; - Cluster- oder Computerkonto; - doppelte SPNs; - vorhandene Kerberos-Tickets; - Server- und SMB-Konfiguration. Ein zusätzlicher DNS-CNAME allein stellt noch nicht sicher, dass Kerberos über den Alias funktioniert. --- **25. DFS-Namespace untersuchen** Ein DFS-Pfad kann Benutzer auf einen oder mehrere tatsächliche Zielserver verweisen: ```text \\ad.example.local\Daten\Abteilung ``` DFS-Namespace-Informationen: ```powershell Get-DfsnRoot ``` Ordner und Ziele: ```powershell Get-DfsnFolder ``` ```powershell Get-DfsnFolderTarget ``` Clientseitige DFS-Informationen: ```cmd dfsutil /pktinfo ``` DFS-Cache anzeigen: ```cmd dfsutil /pktinfo ``` Zu prüfen sind: - Namespace erreichbar; - DFS-Ordner vorhanden; - Zielserver korrekt; - Ziel aktiviert; - Client verwendet das erwartete Ziel; - Standortzuordnung korrekt; - Zielserver erreichbar; - DNS-Auflösung des tatsächlichen Zielservers; - Berechtigungen auf jedem Ziel; - Replikationsstatus; - veralteter Client-Referral-Cache. --- **26. DFS-Namespace und DFS-Replikation unterscheiden** | Funktion | Aufgabe | |---|---| | DFS Namespace | stellt einen einheitlichen logischen Pfad bereit | | DFS Replication | repliziert Ordnerinhalte zwischen Servern | Ein funktionierender Namespace beweist nicht, dass die Daten repliziert wurden. Umgekehrt kann die Replikation funktionieren, während ein Namespace-Ziel falsch konfiguriert oder nicht erreichbar ist. Typisches Fehlerbild: - Benutzer erreicht den DFS-Pfad; - abhängig vom ausgewählten Zielserver fehlen Dateien; - Dateien besitzen unterschiedliche Versionen; - Rechte unterscheiden sich zwischen Zielen; - ein Replikationspartner ist verzögert oder gestört. --- **27. DFS-Replikation prüfen** Relevanter Ereignisprotokollpfad: ```text Ereignisanzeige → Anwendungs- und Dienstprotokolle → DFS Replication ``` PowerShell: ```powershell Get-WinEvent -FilterHashtable @{ LogName = 'DFS Replication' StartTime = (Get-Date).AddHours(-4) } | Select-Object TimeCreated, Id, LevelDisplayName, Message ``` Replikationsgruppen: ```powershell Get-DfsReplicationGroup ``` Mitgliedschaften: ```powershell Get-DfsrMembership ``` Verbindungen: ```powershell Get-DfsrConnection ``` Zu dokumentieren sind: - Replikationsgruppe; - replizierter Ordner; - Quell- und Zielserver; - betroffene Richtung; - letzter Fehler; - Zeitpunkt; - freier Speicherplatz; - Datenbankzustand; - Backlog; - Konflikt- oder Staging-Bereich; - letzte Änderungen. Eine manuell erzwungene Synchronisation ist keine erste Diagnosemaßnahme. --- **28. Offline Files und Clientcache** Windows kann Netzwerkdateien lokal zwischenspeichern. Dadurch können Benutzer zeitweise mit einer lokalen Kopie arbeiten. Mögliche Fehlerbilder: - alte Dateiversion wird angezeigt; - Synchronisierung schlägt fehl; - Datei ist offline verfügbar, obwohl der Server erreichbar sein sollte; - Konflikt zwischen lokaler und serverseitiger Änderung; - Netzlaufwerk wird als offline angezeigt; - unterschiedliche Benutzer sehen unterschiedliche Stände; - Anwendung arbeitet weiter, obwohl der Server nicht erreichbar ist. Zu prüfen sind: - Synchronisierungscenter; - Offlineverfügbarkeit; - Netzwerkstatus; - verwendeter UNC- beziehungsweise DFS-Pfad; - Konflikte; - Ereignisprotokolle; - GPO-Konfiguration; - Speicherplatz im lokalen Cache. Der Offlinecache darf nicht ungeprüft zurückgesetzt werden. Nicht synchronisierte Benutzerdaten könnten verloren gehen. --- **29. Quotas und freier Speicherplatz** Freien Speicherplatz prüfen: ```powershell Get-Volume ``` Dateisystemlaufwerke: ```powershell Get-PSDrive -PSProvider FileSystem ``` FSRM-Quotas: ```powershell Get-FsrmQuota ``` Mögliche Symptome: - Datei kann nicht gespeichert werden; - Kopieren bricht ab; - „Nicht genügend Speicherplatz“; - Benutzer kann kleine, aber keine großen Dateien speichern; - Anwendung meldet nur einen allgemeinen Schreibfehler; - Freigabe ist erreichbar, Änderungen schlagen jedoch fehl; - DFS-R oder Druckspooler arbeitet nicht mehr. Zu unterscheiden sind: - physischer Datenträger voll; - Thin-Provisioning-Pool voll; - Benutzer- oder Ordnerquota erreicht; - VSS- oder Snapshotbereich belegt Speicher; - temporärer Speicherplatz erschöpft; - Dateisystem besitzt ein anderes Limit; - Backend-Speicher des NAS oder SAN ist voll. --- **30. Lange Pfade und Dateinamen** Mögliche Ursachen: - gesamter Pfad ist zu lang; - Anwendung unterstützt lange Pfade nicht; - Dateiname enthält nicht unterstützte Zeichen; - Name endet problematisch mit Punkt oder Leerzeichen; - reservierter Gerätename wird verwendet; - Anwendung besitzt ein eigenes kürzeres Pfadlimit; - Archiv- oder Synchronisationssoftware kann den Pfad nicht verarbeiten; - Quell- und Zielsystem verwenden unterschiedliche Namensregeln. Typische reservierte Namen unter Windows sind beispielsweise: ```text CON PRN AUX NUL COM1 LPT1 ``` Die Unterstützung langer Pfade hängt nicht nur vom Betriebssystem ab. Auch Anwendung, API und Konfiguration müssen sie unterstützen. --- **31. Eigentümer und ACL-Zustand** Eigentümer anzeigen: ```powershell (Get-Acl 'D:\Freigaben\Daten').Owner ``` Mögliche Probleme: - nicht mehr auflösbare SID; - migriertes Benutzer- oder Gruppenkonto; - Eigentümer ist nicht mehr vorhanden; - ACL wurde bei Kopie oder Restore verändert; - Vererbung ist beschädigt oder unerwartet unterbrochen; - Backup wurde ohne Sicherheitsinformationen wiederhergestellt; - Dateien stammen aus einer anderen Domäne; - NAS bildet Windows-SIDs nicht korrekt ab. Nicht auflösbare SIDs beweisen allein keinen Fehler. Sie können noch wirksame Sicherheitskennungen ehemaliger oder nicht erreichbarer Domänenkonten darstellen und müssen vor einer Entfernung zugeordnet werden. --- **32. Ereignisprotokolle für SMB prüfen** Wichtige Protokollpfade können sein: ```text Microsoft → Windows → SMBClient → Connectivity ``` ```text Microsoft → Windows → SMBClient → Security ``` ```text Microsoft → Windows → SMBServer → Operational ``` ```text Microsoft → Windows → SMBServer → Security ``` PowerShell-Beispiel: ```powershell Get-WinEvent -FilterHashtable @{ LogName = 'Microsoft-Windows-SMBClient/Connectivity' StartTime = (Get-Date).AddHours(-2) } | Select-Object TimeCreated, Id, LevelDisplayName, Message ``` Zusätzlich können relevant sein: - System; - Sicherheit; - DNS Client Events; - Kerberos; - NETLOGON; - DFS Replication; - Failover Clustering; - NTFS; - Disk; - StorPort; - anwendungsspezifische Protokolle. Event-ID, Provider, Zeitpunkt, Server, Client und vollständiger Ereignistext müssen gemeinsam bewertet werden. --- **33. SMB-Netzwerkverkehr untersuchen** Bei unklarem Netzwerk- oder Protokollfehler kann ein Paketmitschnitt erforderlich sein. Typische Filter: ```text tcp.port == 445 ``` ```text smb2 ``` ```text ip.addr == 192.0.2.20 && tcp.port == 445 ``` Zu untersuchen sind: - TCP-Verbindungsaufbau; - Retransmissions; - TCP Reset; - SMB-Negotiation; - Session Setup; - Tree Connect; - Authentifizierungsfehler; - SMB-Statuscodes; - lange Antwortzeiten; - Verbindungsabbruch; - Server- oder Clientverzögerung. Ein Paketmitschnitt kann Datei- und Benutzernamen sowie weitere vertrauliche Informationen enthalten und muss geschützt gespeichert werden. --- **34. Druckpfad verstehen** ```text Anwendung ↓ Druckertreiber ↓ Windows-Druckwarteschlange ↓ Spooler ↓ Druckserver oder direkter TCP/IP-Port ↓ Netzwerk ↓ Drucker ↓ Druckwerk, Papier und Verbrauchsmaterial ``` Die Meldung „Drucker druckt nicht“ kann daher verursacht werden durch: - Anwendung; - Treiber; - Spooler; - Queue; - Druckserver; - Berechtigung; - Netzwerk; - DNS; - Portkonfiguration; - SNMP; - Druckerzustand; - Papier oder Toner; - mechanische Störung. --- **35. Druckerfehler exakt eingrenzen** Zu dokumentieren sind: - Druckername; - Freigabename; - Druckserver; - Drucker-IP; - DNS-Name; - Treibername und Version; - verwendeter Port; - betroffener Client; - betroffener Benutzer; - Anwendung; - Dokumenttyp; - Zeitpunkt; - Status der Warteschlange; - vollständiger Fehlertext; - funktioniert eine Windows-Testseite; - funktioniert ein anderes Dokument; - funktioniert der Druck aus einer anderen Anwendung; - funktioniert ein anderer Benutzer; - funktioniert ein anderer Drucker; - betrifft es einen oder alle Clients. Diese Tests trennen Anwendung, Benutzer, Client, Treiber, Queue, Server und Gerät voneinander. --- **36. Drucker und Warteschlangen anzeigen** PowerShell: ```powershell Get-Printer ``` Ausgewählte Eigenschaften: ```powershell Get-Printer | Select-Object Name, ComputerName, DriverName, PortName, Shared, ShareName, PrinterStatus, JobCount ``` Bestimmter Drucker: ```powershell Get-Printer -Name 'Drucker-01' ``` Druckaufträge: ```powershell Get-PrintJob -PrinterName 'Drucker-01' ``` Druckerkonfiguration: ```powershell Get-PrintConfiguration -PrinterName 'Drucker-01' ``` --- **37. Print Spooler prüfen** ```powershell Get-Service Spooler ``` Ausführlicher: ```powershell Get-CimInstance Win32_Service ` -Filter "Name='Spooler'" | Select-Object Name, State, StartMode, StartName, ProcessId ``` Abhängigkeiten: ```powershell Get-Service Spooler -DependentServices ``` Ein Neustart des Spoolers: ```powershell Restart-Service Spooler ``` verändert den Zustand und kann alle lokalen beziehungsweise serverseitigen Druckaufträge beeinflussen. Vorher sind zu prüfen: - betrifft der Fehler alle Drucker; - hängen einzelne oder alle Aufträge; - befinden sich wichtige Aufträge in der Queue; - stürzt der Spooler wiederholt ab; - welcher Treiber oder Print Processor ist beteiligt; - was zeigen Ereignisprotokolle; - besteht ein Wartungs- oder Freigabefenster. --- **38. Druckaufträge kontrollieren** ```powershell Get-PrintJob -PrinterName 'Drucker-01' | Select-Object ID, DocumentName, UserName, SubmittedTime, JobStatus, Size ``` Einzelnen Auftrag entfernen: ```powershell Remove-PrintJob ` -PrinterName 'Drucker-01' ` -ID 17 ``` Vor dem Entfernen prüfen: - gehört der Auftrag zum untersuchten Fehler; - handelt es sich um einen produktiv wichtigen Auftrag; - wird die Queue dadurch für andere Benutzer freigegeben; - tritt der Fehler mit einem neuen Testauftrag wieder auf. Nicht sofort die gesamte Warteschlange leeren, wenn ein einzelner Auftrag die Ursache sein könnte. --- **39. Druckerport prüfen** ```powershell Get-PrinterPort ``` Bestimmter Port: ```powershell Get-PrinterPort -Name 'IP_192.0.2.50' ``` Zu prüfen sind: - richtige IP-Adresse; - richtiger DNS-Name; - Standard-TCP/IP-Port; - Raw oder LPR; - TCP-Port 9100; - LPR-Queue-Name; - SNMP aktiviert; - SNMP-Community; - WSD statt festem TCP/IP-Port; - Druckeradresse nach DHCP-Änderung; - alter Port nach Druckeraustausch. Porttest für RAW Printing: ```powershell Test-NetConnection 192.0.2.50 -Port 9100 ``` Mögliche weitere Protokolle hängen vom Drucksystem ab, beispielsweise IPP, IPPS, LPR oder SMB. --- **40. SNMP-Statusfehler** Ein Drucker kann erreichbar und druckfähig sein, aber in Windows als offline erscheinen, wenn die SNMP-Statusabfrage fehlschlägt. Mögliche Ursachen: - SNMP auf dem Drucker deaktiviert; - falsche Community; - UDP 161 blockiert; - SNMP-Version nicht kompatibel; - Drucker beantwortet Statusabfragen fehlerhaft; - falscher Port verweist auf ein anderes Gerät; - Sicherheitsrichtlinie verhindert die Abfrage. Das Deaktivieren des SNMP-Status kann als kontrollierter Diagnosetest dienen. Es ist jedoch keine allgemeine Lösung, weil dadurch echte Gerätestatusinformationen verloren gehen können. --- **41. Druckertreiber untersuchen** Installierte Treiber: ```powershell Get-PrinterDriver ``` Mögliche Treiberprobleme: - falsches Druckermodell; - alter Treiber; - beschädigtes Treiberpaket; - herstellerspezifischer und universeller Treiber kollidieren; - Architektur- oder Betriebssysteminkompatibilität; - Treiber verursacht Spooler-Absturz; - Point-and-Print-Richtlinie verhindert Installation; - Treiber unterstützt Gerätefunktion nicht; - Druckdatenformat passt nicht zum Drucker; - Upgrade hinterließ alte Treiberkomponenten. Treiber dürfen nicht ungeprüft auf einem produktiven Druckserver ersetzt werden. Dadurch können mehrere Warteschlangen und Benutzer betroffen sein. --- **42. Windows-Testseite verwenden** Eine Testseite trennt die Anwendung teilweise vom restlichen Druckpfad. PowerShell über WMI/CIM: ```powershell Invoke-CimMethod ` -ClassName Win32_Printer ` -MethodName PrintTestPage ` -Arguments @{} ` -Filter "Name='Drucker-01'" ``` Bewertung: | Ergebnis | Wahrscheinlicher Bereich | |---|---| | Testseite funktioniert, Anwendung nicht | Anwendung, Dokument, Format oder anwendungsspezifische Einstellungen | | Testseite bleibt in Queue | Spooler, Treiber, Port oder Druckserver | | Auftrag verlässt Queue, Drucker reagiert nicht | Port, Netzwerk, Protokoll oder Gerät | | Auftrag wird gedruckt, Ausgabe fehlerhaft | Treiber, Druckersprache, Gerätekonfiguration oder Hardware | | alle Drucker betroffen | Spooler, Server, Richtlinie oder gemeinsamer Dienst | | nur ein Drucker betroffen | Queue, Port, Treiber oder Gerät | --- **43. Druckereignisse prüfen** Wichtiger Protokollpfad: ```text Ereignisanzeige → Anwendungs- und Dienstprotokolle → Microsoft → Windows → PrintService → Operational ``` Das Operational-Protokoll muss je nach System zunächst aktiviert werden. PowerShell: ```powershell Get-WinEvent -FilterHashtable @{ LogName = 'Microsoft-Windows-PrintService/Operational' StartTime = (Get-Date).AddHours(-2) } | Select-Object TimeCreated, Id, LevelDisplayName, Message ``` Zusätzlich prüfen: - PrintService/Admin; - System; - Anwendung; - Spooler-Absturzereignisse; - Treiberereignisse; - Netzwerkereignisse; - Protokolle des Druckservers; - Weboberfläche und Ereignisprotokoll des Druckers. --- **44. CUPS unter Linux und macOS prüfen** Druckerstatus: ```bash lpstat -t ``` Standarddrucker: ```bash lpstat -d ``` Warteschlange: ```bash lpq ``` Druckaufträge: ```bash lpstat -o ``` Auftrag abbrechen: ```bash cancel ``` Alle Aufträge eines Druckers abbrechen: ```bash cancel -a ``` CUPS-Dienst unter systemd: ```bash systemctl status cups ``` Protokoll: ```bash journalctl -u cups ``` Je nach System können die CUPS-Protokolle zusätzlich unter folgendem Pfad liegen: ```text /var/log/cups/ ``` Zu prüfen sind: - CUPS-Dienst; - Queue-Zustand; - deaktivierte oder angehaltene Queue; - Geräte-URI; - Treiber beziehungsweise PPD; - Filterfehler; - Berechtigungen; - Erreichbarkeit des Druckers; - IPP-, LPR- oder RAW-Verbindung; - vollständiger CUPS-Fehlertext. --- **45. Typische Fehlerbilder** | Symptom | Mögliche Ursache | Nächster Test | |---|---|---| | Servername nicht erreichbar | DNS oder Netzwerk | `Resolve-DnsName`, `Test-NetConnection` | | IP funktioniert, Name nicht | DNS, Alias oder SPN | Kurzname, FQDN und DNS-Einträge vergleichen | | TCP 445 nicht erreichbar | Firewall, Routing oder SMB-Dienst | Porttest und Serverstatus | | Freigabe nicht gefunden | falscher Name oder Freigabe fehlt | `Get-SmbShare`, `net share` | | Freigabe öffnet sich, Unterordner nicht | NTFS-Rechte oder ABE | ACL und effektiven Zugriff prüfen | | Datei lesbar, aber nicht änderbar | fehlendes Schreib- oder Änderungsrecht | Share- und NTFS-Rechte | | Datei änderbar, aber nicht löschbar | Löschrecht oder Eltern-ACL | Datei- und Ordner-ACL prüfen | | Zugriff lokal möglich, über SMB nicht | Freigaberecht oder SMB-Pfad | `Get-SmbShareAccess` | | neuer Gruppeneintrag wirkt nicht | altes Anmeldetoken | `whoami /groups`, erneute Anmeldung | | Zugriff verweigert trotz Gruppenmitgliedschaft | Verweigerung, falsches Token oder NTFS-Recht | effektiven Zugriff prüfen | | Datei angeblich in Verwendung | offenes Handle oder Anwendungssperre | `Get-SmbOpenFile` | | Zugriff über Alias schlägt fehl | SPN oder Kerberos | `klist`, `setspn -Q` | | DFS-Pfad zeigt alte Daten | falsches Ziel oder DFS-R-Störung | `dfsutil /pktinfo`, DFS-R-Ereignisse | | Dateien unterscheiden sich je nach Client | unterschiedliche DFS-Ziele | Zielserver und Replikation vergleichen | | Speichern schlägt ab bestimmter Größe fehl | Quota oder freier Speicher | Volume und FSRM prüfen | | Drucker für alle Benutzer offline | Netzwerk, Port oder Gerät | Porttest und Druckerstatus | | nur ein Benutzer kann nicht drucken | Berechtigung oder Benutzerprofil | Druckerrechte und Vergleichsbenutzer | | nur eine Anwendung druckt nicht | Anwendung oder Dokument | Windows-Testseite | | alle Drucker eines Servers betroffen | Spooler oder Druckserver | Dienst und Ereignisse | | nur eine Queue betroffen | Auftrag, Treiber oder Port | Queue, Treiber und Port | | Auftrag bleibt in Warteschlange | Spooler, Treiber oder Port | PrintService-Protokoll | | Auftrag verschwindet, kein Ausdruck | Protokoll, Gerät oder Druckersprache | Druckerprotokoll und Port | | Drucker fälschlich offline | SNMP-Statusabfrage | SNMP-Konfiguration prüfen | | Spooler stürzt wiederholt ab | Treiber oder Print Processor | Ereignisse und Treiberzuordnung | --- **46. Vorgehensweise bei „Zugriff verweigert“** 1. vollständigen UNC-Pfad dokumentieren. 2. Benutzer und Client bestimmen. 3. konkrete fehlgeschlagene Aktion erfassen. 4. verwendetes Konto mit `whoami` prüfen. 5. aktuelle Gruppen mit `whoami /groups` prüfen. 6. Servername und Zieladresse prüfen. 7. SMB-Verbindung und verwendete Anmeldedaten prüfen. 8. Freigabeberechtigungen auslesen. 9. NTFS-Berechtigungen des betroffenen Objekts prüfen. 10. Vererbung und Eigentümer berücksichtigen. 11. Berechtigungen des übergeordneten Ordners prüfen. 12. explizite Verweigerungen untersuchen. 13. Test mit einem funktionierenden Benutzer durchführen. 14. genau eine kontrollierte Korrektur umsetzen. 15. Zugriff mit der ursprünglichen Aktion erneut testen. 16. Rechte nach dem Minimalprinzip dokumentieren. --- **47. Vorgehensweise bei „Datei ist gesperrt“** 1. Dateiname und vollständigen Pfad erfassen. 2. Benutzer, Client und Anwendung bestimmen. 3. prüfen, ob Lesen oder nur Bearbeiten fehlschlägt. 4. `Get-SmbOpenFile` auf dem Dateiserver auswerten. 5. Anwendungssperrdateien berücksichtigen. 6. Serverprozesse mit Handle oder Process Explorer prüfen. 7. Virenscanner, Backup und Synchronisation berücksichtigen. 8. Rechte zum Ändern und Löschen prüfen. 9. Benutzer kontaktieren, der die Datei geöffnet hält. 10. ungespeicherte Daten ausschließen. 11. erst danach gezielt das Handle oder die Sitzung schließen. 12. Datei erneut öffnen, ändern und speichern. 13. Ursache und Auswirkung dokumentieren. --- **48. Vorgehensweise bei DFS-Problemen** 1. logischen DFS-Pfad dokumentieren. 2. Client und Benutzer bestimmen. 3. DFS-Referral des Clients prüfen. 4. tatsächlichen Zielserver dokumentieren. 5. Zielserver per DNS und TCP 445 prüfen. 6. direkten UNC-Pfad zum Zielserver testen. 7. Namespace-Ordner und Ziele prüfen. 8. AD-Site und Zielpriorität berücksichtigen. 9. Rechte auf allen Zielen vergleichen. 10. Dateistände und Zeitstempel vergleichen. 11. DFS-R-Ereignisse prüfen. 12. Replikationsrichtung und Backlog untersuchen. 13. nur die nachgewiesene Ursache korrigieren. 14. Clientzugriff und Replikation erneut prüfen. --- **49. Vorgehensweise bei Druckproblemen** 1. Drucker, Queue, Server und Port dokumentieren. 2. genaue Meldung und Zeitpunkt erfassen. 3. Umfang bestimmen: ein Benutzer, Client, Drucker oder alle. 4. Warteschlange und Auftragsstatus prüfen. 5. Windows-Testseite auslösen. 6. Spoolerstatus prüfen. 7. PrintService-Ereignisse auswerten. 8. Druckername und IP-Adresse prüfen. 9. tatsächlichen Druckerport testen. 10. SNMP-Status kontrollieren. 11. Treibername und Version prüfen. 12. Berechtigungen der Queue prüfen. 13. Gerätestatus und Verbrauchsmaterial prüfen. 14. genau eine kontrollierte Maßnahme durchführen. 15. Testseite und ursprüngliches Dokument erneut drucken. 16. Ereignisse und Queue nachkontrollieren. --- **50. Maßnahmen und Rückwege** **Ursache: falsche Freigabeberechtigung** Nachweis: - SMB-Verbindung funktioniert; - Freigabe existiert; - `Get-SmbShareAccess` zeigt kein ausreichendes Recht; - NTFS-Berechtigung wäre ausreichend. Maßnahme: - vorgesehene Sicherheitsgruppe mit minimal erforderlichem Freigaberecht eintragen. Rollback: - ursprüngliche Freigabe-ACL dokumentiert wiederherstellen. Verifikation: - Verbindung neu testen; - konkrete Dateiaktion ausführen; - Freigabe- und NTFS-Rechte erneut kontrollieren. --- **Ursache: fehlende NTFS-Berechtigung** Nachweis: - Freigaberecht ist ausreichend; - effektiver NTFS-Zugriff zeigt das fehlende Einzelrecht; - Fehler tritt am konkreten Ordner oder Objekt auf. Maßnahme: - Berechtigung über die vorgesehene Sicherheitsgruppe und passende Vererbung korrigieren. Rollback: - vorherige ACL sichern und bei Bedarf wiederherstellen. Verifikation: - Lesen, Erstellen, Ändern und Löschen entsprechend dem Sollzustand einzeln testen. --- **Ursache: altes Anmeldetoken** Nachweis: - AD-Gruppenmitgliedschaft ist vorhanden; - `whoami /groups` enthält die Gruppe noch nicht; - Berechtigungen der Gruppe sind korrekt. Maßnahme: - Benutzer kontrolliert ab- und erneut anmelden. Rollback: - nicht erforderlich, wenn keine Konfiguration verändert wurde. Verifikation: - `whoami /groups`; - Zugriff auf die vorgesehene Ressource; - keine zusätzlichen Rechte vergeben. --- **Ursache: falsches DFS-Ziel** Nachweis: - Client-Referral zeigt auf unerwarteten Server; - direkter Zugriff auf das vorgesehene Ziel funktioniert; - Namespace-Konfiguration oder Zielstatus ist fehlerhaft. Maßnahme: - Zielstatus, Priorität oder Namespace-Zuordnung nach dokumentiertem Sollzustand korrigieren. Rollback: - ursprüngliche DFS-Konfiguration dokumentiert wiederherstellen. Verifikation: - Referral erneut prüfen; - DFS-Pfad öffnen; - Dateistand und Rechte kontrollieren. --- **Ursache: fehlerhafter Druckerport** Nachweis: - Queue und Spooler funktionieren; - Port zeigt auf eine alte oder falsche Adresse; - vorgesehener Drucker ist unter der richtigen Adresse erreichbar. Maßnahme: - Queue kontrolliert auf den korrekten Port umstellen. Rollback: - ursprünglichen Port und seine Einstellungen dokumentieren. Verifikation: - Windows-Testseite; - ursprüngliches Dokument; - Queue- und Druckerstatus; - PrintService-Ereignisse. --- **51. Nachkontrolle** Nach einer Maßnahme sind mindestens folgende Punkte zu prüfen: - vorgesehener Servername wird korrekt aufgelöst; - TCP 445 ist erreichbar; - SMB-Verbindung verwendet das vorgesehene Konto; - SMB-Dialekt und Sicherheitsanforderungen sind plausibel; - Freigabe zeigt auf den richtigen Pfad; - Freigabeberechtigungen entsprechen dem Sollzustand; - NTFS-Berechtigungen entsprechen dem Minimalprinzip; - Vererbung funktioniert wie vorgesehen; - aktuelles Token enthält die benötigten Gruppen; - Lesen, Erstellen, Ändern und Löschen wurden getrennt getestet; - keine unerwünschten zusätzlichen Rechte wurden vergeben; - keine wichtigen Dateien oder Sitzungen wurden getrennt; - DFS verweist auf das vorgesehene Ziel; - replizierte Daten sind konsistent; - ausreichend Speicherplatz ist vorhanden; - Quotas sind plausibel; - Druckwarteschlange verarbeitet neue Aufträge; - Druckerport zeigt auf das richtige Gerät; - Treiber und Spooler arbeiten stabil; - praktische Benutzerfunktion wurde getestet; - temporäre Diagnoseänderungen wurden zurückgenommen; - Ursache, Maßnahme, Rückweg und Ergebnis wurden dokumentiert. --- **52. Dokumentationsbeispiel** ```text Symptom: Der Benutzer konnte Dateien in der Freigabe lesen, aber keine neue Datei im Unterordner „Projekte“ erstellen. Zeitpunkt: 02.08.2026, 11:26 Uhr MESZ Benutzer: max.mustermann Client: CLIENT-17 Pfad: \\fileserver01.ad.example.local\Daten\Projekte Nachweis: DNS-Auflösung und TCP 445 waren erfolgreich. Die SMB-Verbindung verwendete das vorgesehene Domänenkonto. Die Freigabeberechtigung gewährte der zuständigen Gruppe „Ändern“. Die NTFS-Auswertung zeigte jedoch nur Leserechte auf dem Unterordner. Die Vererbung war an diesem Unterordner deaktiviert worden. Ursache: Bei einer früheren manuellen ACL-Änderung wurde die Vererbung auf dem Unterordner unterbrochen. Dadurch fehlte der vorgesehenen Gruppe das Änderungsrecht. Maßnahme: Nach Sicherung der bestehenden ACL wurde die freigegebene Berechtigungsstruktur des übergeordneten Ordners wiederhergestellt. Rollback: Die zuvor exportierte ACL kann wieder eingespielt werden. Verifikation: Der Benutzer kann Dateien lesen, erstellen, ändern und löschen. Er kann keine Berechtigungen verändern. Andere Abteilungsordner bleiben weiterhin unzugänglich. Es wurden keine zusätzlichen administrativen Rechte vergeben. Prävention: Berechtigungsänderungen erfolgen künftig ausschließlich über dokumentierte Sicherheitsgruppen und werden durch einen Test des effektiven Zugriffs geprüft. ``` --- **53. Entscheidungsbaum** ```text Datei- oder Freigabezugriff gestört ↓ Wird der richtige Servername aufgelöst? ├── Nein │ ↓ │ DNS, Alias und DFS-Namen prüfen │ └── Ja ↓ Ist TCP 445 erreichbar? ├── Nein │ ↓ │ Routing, Firewall und SMB-Dienst prüfen │ └── Ja ↓ Existiert die Freigabe und zeigt sie auf den richtigen Pfad? ├── Nein │ ↓ │ Freigabe- und Serverkonfiguration prüfen │ └── Ja ↓ Wird das vorgesehene Benutzerkonto verwendet? ├── Nein │ ↓ │ bestehende Verbindungen und Anmeldedaten prüfen │ └── Ja ↓ Sind Freigabeberechtigungen ausreichend? ├── Nein │ ↓ │ Freigabe-ACL kontrolliert korrigieren │ └── Ja ↓ Sind NTFS-Berechtigungen ausreichend? ├── Nein │ ↓ │ ACL, Vererbung, Gruppen und Token prüfen │ └── Ja ↓ Ist nur eine Datei oder Aktion betroffen? ├── Ja │ ↓ │ Sperre, Einzel-ACL, Pfad, Quota und Anwendung prüfen │ └── Nein ↓ DFS, Storage, Serverzustand und zentrale Abhängigkeiten prüfen ``` --- **54. Typische Prüfungsfragen** **Warum reicht ein erfolgreicher Ping zum Dateiserver nicht als Funktionsnachweis?**
Antwort anzeigen Ein Ping prüft eine bestimmte ICMP-Kommunikation. Er beweist weder die Erreichbarkeit von TCP 445 noch eine erfolgreiche SMB-Authentifizierung oder ausreichende Freigabe- und NTFS-Berechtigungen.
**Welche Berechtigungen wirken bei einem SMB-Zugriff auf einen NTFS-Ordner?**
Antwort anzeigen Es wirken sowohl die Freigabe- als auch die NTFS-Berechtigungen. Für den Zugriff über das Netzwerk ergibt sich die wirksame Berechtigung aus der restriktiveren Kombination beider Ebenen.
**Warum kann der lokale Zugriff auf einen Serverordner funktionieren, während der SMB-Zugriff fehlschlägt?**
Antwort anzeigen Beim lokalen Zugriff werden keine SMB-Freigabeberechtigungen ausgewertet. Über das Netzwerk wirken zusätzlich zu den NTFS-Rechten auch die Freigabeberechtigungen und die SMB-Authentifizierung.
**Warum kann eine neue Gruppenmitgliedschaft noch nicht wirksam sein?**
Antwort anzeigen Die Gruppe kann bereits im Active Directory eingetragen sein, aber im aktuellen Anmeldetoken fehlen. Häufig ist eine erneute Benutzeranmeldung erforderlich, damit ein neues Token erzeugt wird.
**Worin unterscheiden sich DFS Namespace und DFS Replication?**
Antwort anzeigen DFS Namespace stellt einen einheitlichen logischen Zugriffspfad bereit. DFS Replication synchronisiert Ordnerinhalte zwischen mehreren Servern. Beide Funktionen können unabhängig voneinander gestört sein.
**Warum sollte eine geöffnete SMB-Datei nicht sofort zwangsweise geschlossen werden?**
Antwort anzeigen Die zugehörige Anwendung kann noch nicht gespeicherte Änderungen besitzen. Ein erzwungenes Schließen kann Datenverlust oder beschädigte Anwendungszustände verursachen.
**Warum beweist ein erfolgreicher Zugriff über einen Alias nicht automatisch die Verwendung von Kerberos?**
Antwort anzeigen Fehlt ein passender CIFS-SPN für den Alias, kann der Zugriff abhängig von der Umgebung über NTLM erfolgen. Tickets und SPN-Zuordnung müssen gesondert geprüft werden.
**Welche Funktion besitzt der Print Spooler?**
Antwort anzeigen Der Print Spooler nimmt Druckaufträge entgegen, verarbeitet beziehungsweise zwischenspeichert sie und übergibt sie über die konfigurierte Warteschlange und den Druckerport an das Ziel.
**Warum kann ein Drucker fälschlich als offline angezeigt werden?**
Antwort anzeigen Die eigentliche Druckverbindung kann funktionieren, während die SNMP-Statusabfrage fehlschlägt. Ursachen können eine falsche Community, blockiertes UDP 161 oder eine fehlerhafte SNMP-Konfiguration sein.
--- **55. Prüfungsfallen** - erfolgreichen Ping mit funktionierendem SMB gleichsetzen; - nur die IP-Adresse, aber nicht den verwendeten Namen prüfen; - verbundenes Laufwerk prüfen, ohne den UNC-Pfad zu bestimmen; - Freigabe- und NTFS-Berechtigungen verwechseln; - nur die ACL der Freigabeebene prüfen; - nur die ACL des übergeordneten Ordners prüfen; - Vererbung und Einzelrechte nicht berücksichtigen; - Lesen, Schreiben, Ändern und Löschen gleichsetzen; - Gruppenmitgliedschaft im AD mit aktuellem Token gleichsetzen; - Benutzer direkt statt über Sicherheitsgruppen berechtigen; - Benutzer zur Fehlerbehebung in eine Administratorgruppe aufnehmen; - pauschal Vollzugriff gewähren; - Verweigerung ungeprüft entfernen; - ACLs rekursiv ersetzen, ohne Rückweg festzulegen; - Eigentümer übernehmen, ohne die ursprüngliche ACL zu sichern; - alte oder unbekannte SID ungeprüft löschen; - alle SMB-Verbindungen pauschal trennen; - Datei-Handle schließen, ohne ungespeicherte Daten auszuschließen; - SMB 1 als schnelle Kompatibilitätslösung aktivieren; - erfolgreichen Zugriff mit Kerberos-Authentifizierung gleichsetzen; - DNS-Alias ohne CIFS-SPN verwenden; - DFS-Namespace und DFS-Replikation verwechseln; - DFS-Cache leeren, bevor das verwendete Ziel dokumentiert wurde; - Replikation ungeprüft erzwingen; - Offlinecache zurücksetzen, ohne nicht synchronisierte Daten zu prüfen; - nur freien Speicherplatz, aber keine Quota prüfen; - Druckwarteschlange vollständig leeren, obwohl nur ein Auftrag betroffen ist; - Spooler sofort neu starten, ohne Ereignisse und Queue zu sichern; - Treiber auf einem produktiven Druckserver ungeprüft ersetzen; - SNMP dauerhaft deaktivieren, ohne die eigentliche Ursache zu prüfen; - Drucker per IP neu installieren, obwohl nur DNS oder Port falsch ist; - mehrere Änderungen gleichzeitig durchführen; - nur eine Testseite, aber nicht die ursprüngliche Benutzerfunktion prüfen. --- **56. Checkliste** - [ ] vollständiger UNC-Pfad wurde dokumentiert. - [ ] betroffener Benutzer wurde bestimmt. - [ ] betroffener Client wurde bestimmt. - [ ] genaue fehlgeschlagene Aktion wurde erfasst. - [ ] Fehlertext und Fehlercode wurden dokumentiert. - [ ] Zeitpunkt und Zeitzone wurden erfasst. - [ ] Servername wurde aufgelöst. - [ ] Ziel-IP wurde mit dem Sollzustand verglichen. - [ ] Kurzname, FQDN und Alias wurden unterschieden. - [ ] TCP 445 wurde geprüft. - [ ] tatsächliche SMB-Verbindung wurde geprüft. - [ ] verwendetes Benutzerkonto wurde geprüft. - [ ] bestehende Verbindungen wurden berücksichtigt. - [ ] gespeicherte Anmeldedaten wurden berücksichtigt. - [ ] Freigabe und lokaler Zielpfad wurden geprüft. - [ ] Freigabeberechtigungen wurden geprüft. - [ ] NTFS-Berechtigungen wurden geprüft. - [ ] Vererbung wurde geprüft. - [ ] Eigentümer wurde geprüft. - [ ] explizite Verweigerungen wurden geprüft. - [ ] Rechte des übergeordneten Ordners wurden berücksichtigt. - [ ] AD-Gruppenmitgliedschaften wurden geprüft. - [ ] aktuelles Anmeldetoken wurde geprüft. - [ ] effektiver Zugriff wurde bewertet. - [ ] Lesen, Erstellen, Ändern und Löschen wurden getrennt getestet. - [ ] Access-Based Enumeration wurde bei unsichtbaren Ordnern berücksichtigt. - [ ] geöffnete SMB-Dateien wurden geprüft. - [ ] Anwendungssperren wurden berücksichtigt. - [ ] SMB-Dialekt wurde geprüft. - [ ] Signierung und Verschlüsselung wurden berücksichtigt. - [ ] Kerberos und NTLM wurden unterschieden. - [ ] CIFS-SPN wurde bei Aliasproblemen geprüft. - [ ] DFS-Referral wurde bei DFS-Pfaden geprüft. - [ ] tatsächlicher DFS-Zielserver wurde bestimmt. - [ ] DFS-Replikation wurde bei abweichenden Datenständen geprüft. - [ ] Offline Files wurden berücksichtigt. - [ ] freier Speicherplatz wurde geprüft. - [ ] Quotas wurden geprüft. - [ ] Pfadlänge und Dateiname wurden berücksichtigt. - [ ] SMB- und Systemereignisse wurden geprüft. - [ ] Drucker, Queue, Server und Port wurden dokumentiert. - [ ] Spoolerstatus wurde geprüft. - [ ] Druckaufträge wurden geprüft. - [ ] Druckerport und Zieladresse wurden geprüft. - [ ] SNMP-Status wurde geprüft. - [ ] Treibername und Version wurden geprüft. - [ ] PrintService-Protokolle wurden geprüft. - [ ] Windows-Testseite wurde verwendet. - [ ] ursprüngliche Benutzerfunktion wurde erneut getestet. - [ ] genau eine kontrollierte Maßnahme wurde durchgeführt. - [ ] Rückweg wurde festgelegt. - [ ] keine unnötigen Rechte wurden vergeben. - [ ] Ursache, Maßnahme und Ergebnis wurden dokumentiert. --- **57. Schnellreferenz** | Beobachtung | Nächstes Werkzeug | |---|---| | Servername zeigt auf falsche IP | `Resolve-DnsName`, `nslookup` | | SMB-Port nicht erreichbar | `Test-NetConnection -Port 445` | | bestehende Netzlaufwerke unklar | `net use`, `Get-SmbMapping` | | verwendetes SMB-Konto unklar | `Get-SmbConnection` | | Freigabe fehlt | `Get-SmbShare`, `net share` | | Freigaberecht unklar | `Get-SmbShareAccess` | | NTFS-Recht unklar | `Get-Acl`, `icacls` | | aktuelle Gruppen unklar | `whoami /groups` | | Datei gesperrt | `Get-SmbOpenFile`, Handle | | SMB-Sitzung unklar | `Get-SmbSession` | | SMB-Version unklar | `Get-SmbConnection` | | Alias funktioniert nicht | `klist`, `setspn -Q` | | DFS-Ziel unklar | `dfsutil /pktinfo` | | DFS-Konfiguration unklar | `Get-DfsnFolderTarget` | | DFS-R-Störung | DFS-Replication-Protokoll | | Speicherplatz unklar | `Get-Volume`, `Get-PSDrive` | | Quota vermutet | `Get-FsrmQuota` | | Druckerstatus unklar | `Get-Printer` | | Druckaufträge hängen | `Get-PrintJob` | | Spoolerstatus unklar | `Get-Service Spooler` | | Druckerport unklar | `Get-PrinterPort` | | Treiber unklar | `Get-PrinterDriver` | | Druckereignis gesucht | PrintService/Operational | | CUPS-Status unklar | `lpstat -t`, `journalctl -u cups` | --- **Merksatz** > Bei Datei- und Freigabefehlern wird vom Namen über TCP 445, SMB-Sitzung und Authentifizierung bis zu Freigabe- und NTFS-Rechten geprüft. Bei Druckfehlern wird der Weg von Anwendung und Treiber über Queue, Spooler und Port bis zum physischen Drucker verfolgt. Rechte, Sitzungen, Dateien und Druckaufträge werden erst verändert, wenn Ursache, Auswirkung und Rückweg geklärt sind. --- **Quellen und weiterführende Dokumentation** **Offizielle Microsoft-Dokumentation** - [Microsoft Learn – SMB troubleshooting](https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/smb-file-server-share-troubleshooting) - [Microsoft Learn – Get-SmbConnection](https://learn.microsoft.com/en-us/powershell/module/smbshare/get-smbconnection) - [Microsoft Learn – Get-SmbShare](https://learn.microsoft.com/en-us/powershell/module/smbshare/get-smbshare) - [Microsoft Learn – Get-SmbShareAccess](https://learn.microsoft.com/en-us/powershell/module/smbshare/get-smbshareaccess) - [Microsoft Learn – Get-SmbSession](https://learn.microsoft.com/en-us/powershell/module/smbshare/get-smbsession) - [Microsoft Learn – Get-SmbOpenFile](https://learn.microsoft.com/en-us/powershell/module/smbshare/get-smbopenfile) - [Microsoft Learn – Get-SmbServerConfiguration](https://learn.microsoft.com/en-us/powershell/module/smbshare/get-smbserverconfiguration) - [Microsoft Learn – Get-Acl](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.security/get-acl) - [Microsoft Learn – Icacls](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/icacls) - [Microsoft Learn – File and folder permissions](https://learn.microsoft.com/en-us/windows-server/storage/file-server/enable-access-based-enumeration) - [Microsoft Learn – DFS Namespaces overview](https://learn.microsoft.com/en-us/windows-server/storage/dfs-namespaces/dfs-overview) - [Microsoft Learn – DFS Replication overview](https://learn.microsoft.com/en-us/windows-server/storage/dfs-replication/dfsr-overview) - [Microsoft Learn – DFSR troubleshooting](https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/dfsr-overview) - [Microsoft Learn – Get-DfsnFolderTarget](https://learn.microsoft.com/en-us/powershell/module/dfsn/get-dfsnfoldertarget) - [Microsoft Learn – Get-DfsReplicationGroup](https://learn.microsoft.com/en-us/powershell/module/dfsr/get-dfsreplicationgroup) - [Microsoft Learn – Get-Printer](https://learn.microsoft.com/en-us/powershell/module/printmanagement/get-printer) - [Microsoft Learn – Get-PrintJob](https://learn.microsoft.com/en-us/powershell/module/printmanagement/get-printjob) - [Microsoft Learn – Get-PrinterPort](https://learn.microsoft.com/en-us/powershell/module/printmanagement/get-printerport) - [Microsoft Learn – Get-PrinterDriver](https://learn.microsoft.com/en-us/powershell/module/printmanagement/get-printerdriver) - [Microsoft Learn – Windows print troubleshooting](https://learn.microsoft.com/en-us/troubleshoot/windows-client/printing/welcome-to-troubleshooting-windows-printing) **Offizielle CUPS-Dokumentation** - [OpenPrinting – CUPS Command-Line Printing](https://openprinting.github.io/cups/doc/options.html) - [OpenPrinting – CUPS Administration](https://openprinting.github.io/cups/doc/admin.html) - [OpenPrinting – CUPS Documentation](https://openprinting.github.io/cups/) # 8.4 Linux-Server – Dienste, Prozesse, Protokolle, Ressourcen und Speicher --- **1. Ziel dieser Seite** Diese Seite beschreibt die strukturierte Fehleranalyse auf Linux-Servern. Typische Störungen betreffen: - systemd-Dienste; - Prozesse; - Konfigurationsdateien; - Benutzer und Berechtigungen; - SELinux oder AppArmor; - Netzwerk und Ports; - DNS und Namensauflösung; - CPU, RAM und Swap; - Datenträger und Dateisysteme; - Inodes; - Mounts; - LVM und Software-RAID; - Paketverwaltung; - Cronjobs und systemd-Timer; - Kernel, Treiber und Hardware; - Bootvorgang; - Zeit- und Zertifikatsprobleme. Das Ziel ist nicht, einen Dienst möglichst schnell neu zu starten. Zuerst werden Fehlerzustand, Ursache, Auswirkungen und Rückweg dokumentiert. --- **2. Diagnosegrundsatz** ```text Symptom erfassen ↓ Umfang bestimmen ↓ Systemzustand und Zeitpunkt prüfen ↓ Dienst, Prozess und Port untersuchen ↓ Protokolle auswerten ↓ Abhängigkeiten prüfen ↓ Konfiguration und Berechtigungen prüfen ↓ Ressourcen und Storage prüfen ↓ Ursache nachweisen ↓ Eine kontrollierte Maßnahme durchführen ↓ Funktion und Nebenwirkungen kontrollieren ``` Ein erfolgreicher Prozessstart beweist noch keine funktionierende Anwendung. Ebenso beweist ein offener Port nicht, dass die Anwendung korrekte Antworten liefert. --- **3. Fehlerbild exakt erfassen** Zu dokumentieren sind: - Hostname; - Distribution; - Betriebssystemversion; - Kernelversion; - Architektur; - betroffener Dienst; - betroffene Anwendung; - vollständiger Fehlertext; - Fehlercode; - Zeitpunkt mit Zeitzone; - betroffener Benutzer; - Quell- und Zielsystem; - Port und Protokoll; - betroffene Funktion; - Umfang der Störung; - letzte funktionierende Nutzung; - letzte Änderungen; - installierte Updates; - Neustarts; - Ressourcenstatus; - bisherige Diagnose- und Änderungsversuche. Wichtige Abgrenzungsfragen: - Ist nur ein Benutzer betroffen? - Ist nur ein Client betroffen? - Ist nur eine Anwendung betroffen? - Ist nur eine Instanz betroffen? - Betrifft es einen oder mehrere Server? - Funktioniert der Dienst lokal? - Funktioniert der Dienst über das Netzwerk? - Ist nur IPv4 oder IPv6 betroffen? - Tritt der Fehler dauerhaft oder sporadisch auf? - Begann der Fehler nach einer Änderung? - Funktioniert die Anwendung, obwohl der Dienststatus einen Fehler meldet? --- **4. System identifizieren** Hostname: ```bash hostnamectl ``` Kurzer Hostname: ```bash hostname ``` Betriebssysteminformationen: ```bash cat /etc/os-release ``` Kernelversion und Architektur: ```bash uname -a ``` Nur Kernelversion: ```bash uname -r ``` Architektur: ```bash uname -m ``` Systemlaufzeit und Last: ```bash uptime ``` Letzter Systemstart: ```bash who -b ``` Aktuelle Zeit und Zeitzone: ```bash timedatectl ``` Diese Informationen sind wichtig, weil Befehle, Dateipfade, Paketmanager, Sicherheitsmodule und Protokollierung je nach Distribution und Version unterschiedlich sein können. --- **5. Letzte Änderungen bestimmen** Mögliche Ursachen kurz vor Beginn einer Störung: - Paketupdate; - Kernelupdate; - Konfigurationsänderung; - Zertifikatsaustausch; - Änderung von Benutzer oder Gruppe; - Änderung von Dateirechten; - Firewalländerung; - DNS-Änderung; - neue Mount-Konfiguration; - Storage-Erweiterung; - Neustart; - Deployment; - geänderte Umgebungsvariable; - neuer systemd-Drop-in; - geänderte SELinux- oder AppArmor-Regel; - abgelaufenes Kennwort oder Zertifikat. Anmeldehistorie: ```bash last ``` Fehlgeschlagene Anmeldungen, sofern unterstützt und berechtigt: ```bash lastb ``` Letzte Neustarts: ```bash last reboot ``` Zeitstempel einer Datei: ```bash stat /etc/example/application.conf ``` RPM-basierte Systeme: ```bash dnf history ``` Debian- und Ubuntu-Systeme: ```bash grep -E ' install | upgrade | remove ' /var/log/dpkg.log ``` Rotierte Protokolle müssen gegebenenfalls zusätzlich geprüft werden. --- **6. systemd-Gesamtzustand prüfen** Fehlgeschlagene Units: ```bash systemctl --failed ``` Systemzustand: ```bash systemctl is-system-running ``` Alle geladenen Dienste: ```bash systemctl list-units --type=service --all ``` Installierte Unit-Dateien: ```bash systemctl list-unit-files --type=service ``` Abweichende oder lokal angepasste Units: ```bash systemd-delta ``` Ein System kann als `degraded` angezeigt werden, obwohl die vom Benutzer benötigte Anwendung funktioniert. Deshalb müssen die fehlgeschlagenen Units einzeln bewertet werden. --- **7. Dienststatus untersuchen** Beispieldienst: ```bash systemctl status example.service ``` Aktivitätsstatus: ```bash systemctl is-active example.service ``` Autostartstatus: ```bash systemctl is-enabled example.service ``` Fehlerzustand: ```bash systemctl is-failed example.service ``` Ausgewählte Eigenschaften: ```bash systemctl show example.service \ -p ActiveState \ -p SubState \ -p Result \ -p ExecMainCode \ -p ExecMainStatus \ -p MainPID \ -p User \ -p Group \ -p FragmentPath ``` Zu unterscheiden sind: - `loaded`: Unit-Datei wurde geladen; - `active`: Unit ist aktiv; - `inactive`: Unit ist nicht aktiv; - `failed`: vorheriger Start oder Betrieb endete fehlerhaft; - `enabled`: Unit ist für automatischen Start eingebunden; - `disabled`: kein automatischer Start über die übliche Aktivierung; - `masked`: Start wurde durch eine Verknüpfung auf `/dev/null` blockiert; - `static`: Unit besitzt normalerweise keinen eigenen Installationsabschnitt und wird durch andere Units gestartet; - `activating`: Startvorgang läuft; - `deactivating`: Beendigung läuft. `enabled` bedeutet nicht, dass der Dienst gerade läuft. `active` bedeutet nicht automatisch, dass er beim nächsten Systemstart wieder gestartet wird. --- **8. Dienstprotokoll mit journalctl prüfen** Aktuelles Dienstprotokoll: ```bash journalctl -u example.service ``` Nur aktueller Systemstart: ```bash journalctl -u example.service -b ``` Vorheriger Systemstart: ```bash journalctl -u example.service -b -1 ``` Letzte 100 Einträge: ```bash journalctl -u example.service -n 100 ``` Fortlaufende Anzeige: ```bash journalctl -u example.service -f ``` Bestimmter Zeitraum: ```bash journalctl -u example.service \ --since "2026-08-02 10:00:00" \ --until "2026-08-02 11:00:00" ``` Warnungen und schwerere Meldungen des aktuellen Starts: ```bash journalctl -b -p warning ``` Kernelmeldungen des aktuellen Starts: ```bash journalctl -k -b ``` Ausführliche Ausgabe: ```bash journalctl -u example.service -o verbose ``` Zu dokumentieren sind: - genauer Zeitpunkt; - Unit; - Prozess-ID; - Benutzer; - Fehlercode; - Signal; - erste relevante Fehlermeldung; - nachfolgende Kaskadenfehler; - wiederholte Startversuche; - betroffene Datei; - betroffene Adresse oder Portnummer. Die letzte Fehlermeldung muss nicht die eigentliche Ursache sein. Häufig steht die erste relevante Meldung weiter oben. --- **9. Klassische Protokolldateien** Je nach Distribution und Dienst können zusätzlich relevant sein: ```text /var/log/syslog /var/log/messages /var/log/auth.log /var/log/secure /var/log/kern.log /var/log/audit/audit.log /var/log/dmesg /var/log/cron /var/log/maillog ``` Anwendungsprotokolle befinden sich häufig unter: ```text /var/log// ``` Letzte Zeilen anzeigen: ```bash tail -n 100 /var/log/syslog ``` Fortlaufend beobachten: ```bash tail -f /var/log/example/application.log ``` Komprimierte rotierte Protokolle durchsuchen: ```bash zgrep -i 'error' /var/log/example/application.log*.gz ``` Nicht jede Distribution verwendet alle genannten Dateien. Auf ausschließlich journalbasierten Systemen können einzelne klassische Protokolldateien fehlen. --- **10. Unit-Datei und Überschreibungen prüfen** Wirksame Unit einschließlich Drop-ins anzeigen: ```bash systemctl cat example.service ``` Pfad und Drop-ins: ```bash systemctl show example.service \ -p FragmentPath \ -p DropInPaths ``` Abhängigkeiten: ```bash systemctl list-dependencies example.service ``` Umgekehrte Abhängigkeiten: ```bash systemctl list-dependencies --reverse example.service ``` Startreihenfolge und Abhängigkeiten können beeinflusst werden durch: - `Requires=`; - `Wants=`; - `After=`; - `Before=`; - `BindsTo=`; - `Condition...=`; - `Assert...=`; - Socket-Aktivierung; - Mount-Abhängigkeiten; - Netzwerk-Targets; - Drop-in-Dateien; - Environment-Dateien. `After=` legt eine Reihenfolge fest, erzeugt allein aber keine Startabhängigkeit. --- **11. systemd-Konfiguration verifizieren** Unit-Dateien prüfen: ```bash systemd-analyze verify example.service ``` Nach einer Änderung an Unit-Dateien: ```bash systemctl daemon-reload ``` `daemon-reload` lädt die systemd-Konfiguration neu. Es startet den betroffenen Dienst nicht automatisch neu. Vor einem Neustart des Dienstes sind zu prüfen: - wurde nur die Unit-Datei oder auch die Anwendungskonfiguration geändert; - besitzt die Anwendung einen eigenen Syntaxprüfer; - verarbeitet der Dienst produktive Verbindungen; - gehen Sitzungen oder Daten verloren; - existiert ein Wartungsfenster; - ist ein Rückweg vorbereitet. --- **12. Anwendungsidentität prüfen** Der Dienst kann unter einem anderen Benutzer laufen als erwartet. systemd-Konfiguration: ```bash systemctl show example.service \ -p User \ -p Group \ -p SupplementaryGroups \ -p DynamicUser ``` Prozessbenutzer: ```bash ps -eo user,group,pid,ppid,stat,lstart,cmd ``` Bestimmter Prozess: ```bash ps -o user,group,pid,ppid,stat,lstart,cmd -p ``` Benutzerinformationen: ```bash id exampleuser ``` Gruppen eines Benutzers: ```bash id -nG exampleuser ``` Kontoeintrag: ```bash getent passwd exampleuser ``` Gruppeneintrag: ```bash getent group examplegroup ``` `getent` berücksichtigt die konfigurierte Namensdienstauflösung und ist deshalb bei LDAP-, Active-Directory- oder SSSD-Umgebungen häufig aussagekräftiger als das alleinige Lesen von `/etc/passwd`. --- **13. Prozesse untersuchen** Alle Prozesse: ```bash ps aux ``` Hierarchische Darstellung: ```bash ps -ef --forest ``` Prozesse eines Benutzers: ```bash ps -u exampleuser -f ``` Prozess anhand des Namens suchen: ```bash pgrep -a example ``` Prozessbaum: ```bash pstree -ap ``` Dynamische Anzeige: ```bash top ``` Falls installiert: ```bash htop ``` Zu prüfen sind: - Prozess vorhanden; - richtige ausführbare Datei; - richtiger Benutzer; - Elternprozess; - Startzeit; - CPU-Verbrauch; - Speicherverbrauch; - Prozesszustand; - Anzahl der Threads; - wiederholte Neustarts; - Zombie-Prozesse; - nicht unterbrechbarer Schlafzustand; - unerwartete Kommandozeilenparameter. --- **14. Prozesszustände bewerten** Wichtige Zustände in `ps`: | Zustand | Bedeutung | |---|---| | `R` | läuft oder ist ausführbar | | `S` | unterbrechbarer Schlafzustand | | `D` | nicht unterbrechbarer Schlafzustand, häufig I/O-bezogen | | `T` | angehalten oder verfolgt | | `Z` | Zombieprozess | | `I` | inaktiver Kernelthread | Ein Prozess im Zustand `D` kann häufig nicht sofort beendet werden, weil er auf eine Kernel- oder I/O-Operation wartet. Ein Zombie verbraucht normalerweise kaum Ressourcen. Er zeigt jedoch, dass der Elternprozess den Beendigungsstatus des Kindprozesses noch nicht abgeholt hat. --- **15. Signale und Prozessbeendigung** Normale Beendigungsanforderung: ```bash kill -TERM ``` Standardsignal von `kill`: ```bash kill ``` Erzwungene Beendigung: ```bash kill -KILL ``` Signale anzeigen: ```bash kill -l ``` `SIGTERM` erlaubt einem Prozess eine kontrollierte Beendigung. `SIGKILL` kann nicht abgefangen werden und verhindert eine geordnete Bereinigung. Vor einer Prozessbeendigung prüfen: - besitzt der Prozess ungespeicherte Daten; - hält er Datenbanktransaktionen; - verwaltet systemd den Prozess; - wird er automatisch neu gestartet; - existieren Kindprozesse; - ist der Prozess im Zustand `D`; - welcher Benutzer ist betroffen; - entstehen Ausfälle oder Inkonsistenzen. Ein von systemd verwalteter Prozess sollte normalerweise über die zuständige Unit und nicht ausschließlich über seine PID gesteuert werden. --- **16. Offene Dateien und Arbeitsverzeichnisse prüfen** Offene Dateien eines Prozesses: ```bash lsof -p ``` Prozesse mit Zugriff auf eine Datei: ```bash lsof /var/lib/example/data.db ``` Alternativ: ```bash fuser -v /var/lib/example/data.db ``` Prozesse auf einem Mountpoint: ```bash fuser -vm /mnt/data ``` Gelöschte, aber weiterhin geöffnete Dateien: ```bash lsof +L1 ``` Eine gelöschte Datei kann weiterhin Speicherplatz belegen, solange ein Prozess sie geöffnet hält. Der Speicher wird normalerweise erst nach dem Schließen des Deskriptors freigegeben. --- **17. Ausführbare Datei und Bibliotheken prüfen** Verwendete Binärdatei: ```bash readlink -f /proc//exe ``` Arbeitsverzeichnis: ```bash readlink -f /proc//cwd ``` Kommandozeile: ```bash tr '\0' ' ' < /proc//cmdline ``` Umgebungsvariablen, nur mit erforderlicher Berechtigung: ```bash tr '\0' '\n' < /proc//environ ``` Bibliotheksabhängigkeiten: ```bash ldd /usr/local/bin/example ``` `ldd` sollte nicht ungeprüft auf nicht vertrauenswürdige ausführbare Dateien angewendet werden. Je nach Datei und Implementierung kann dabei ein Sicherheitsrisiko entstehen. --- **18. Anwendungskonfiguration prüfen** Zu prüfen sind: - Pfad der tatsächlich geladenen Konfiguration; - Syntax; - Dateirechte; - Eigentümer; - Umgebungsvariablen; - Include-Dateien; - relative Pfade; - Zertifikate und Schlüssel; - Port und Bind-Adresse; - Datenbankverbindung; - DNS-Namen; - temporäre Verzeichnisse; - PID- und Socket-Dateien; - Abhängigkeiten; - Zeichencodierung; - Unterschiede zwischen Soll- und Ist-Konfiguration. Datei anzeigen: ```bash sed -n '1,200p' /etc/example/application.conf ``` Dateieigenschaften: ```bash stat /etc/example/application.conf ``` Viele Dienste besitzen einen eigenen Syntaxprüfer. Beispiele: ```bash sshd -t ``` ```bash nginx -t ``` ```bash apachectl configtest ``` Der passende Prüfbefehl muss zur tatsächlich installierten Anwendung und Version passen. --- **19. Dateirechte prüfen** Lange Darstellung: ```bash ls -la /var/lib/example ``` Numerische IDs: ```bash ls -lan /var/lib/example ``` Alle Bestandteile eines Pfades prüfen: ```bash namei -l /var/lib/example/data/file.db ``` Dateistatus: ```bash stat /var/lib/example/data/file.db ``` ACL anzeigen: ```bash getfacl /var/lib/example/data/file.db ``` Zu prüfen sind: - Eigentümer; - Gruppe; - klassische Modusbits; - ACL; - ACL-Maske; - Rechte aller übergeordneten Verzeichnisse; - Setuid; - Setgid; - Sticky Bit; - Dateisystem nur lesbar; - SELinux-Kontext; - AppArmor-Profil; - NFS-Einschränkungen; - Container- oder Namespace-Zuordnung. Für das Betreten eines Verzeichnisses wird das Ausführungsrecht benötigt. Ausreichende Rechte auf der Datei allein genügen nicht, wenn ein übergeordnetes Verzeichnis nicht durchlaufen werden darf. --- **20. Zugriff als Dienstbenutzer testen** Kontrollierter Lesetest: ```bash sudo -u exampleuser -- test -r /var/lib/example/data/file.db ``` Schreibbarkeit eines Verzeichnisses: ```bash sudo -u exampleuser -- test -w /var/lib/example/data ``` Pfadzugriff: ```bash sudo -u exampleuser -- namei -l /var/lib/example/data/file.db ``` Ein Test sollte möglichst dieselbe Identität, denselben Pfad und dieselbe Aktion wie die Anwendung verwenden. Keine produktiven Dateien ungeprüft verändern oder überschreiben. Für Schreibtests ist eine dafür vorgesehene Testdatei zu verwenden. --- **21. SELinux prüfen** Status: ```bash getenforce ``` Ausführlicher Status: ```bash sestatus ``` Dateikontext: ```bash ls -lZ /var/lib/example ``` Prozesskontext: ```bash ps -eZ ``` Aktuelle AVC-Meldungen: ```bash ausearch \ -m AVC,USER_AVC,SELINUX_ERR,USER_SELINUX_ERR \ -ts recent ``` Auswertung, sofern `setroubleshoot` installiert ist: ```bash sealert -a /var/log/audit/audit.log ``` Sollkontext eines Pfades prüfen: ```bash matchpathcon /var/lib/example/data ``` Kontext anhand der Richtlinie wiederherstellen: ```bash restorecon -Rv /var/lib/example ``` SELinux darf nicht pauschal deaktiviert werden, nur um eine Anwendung zum Laufen zu bringen. Eine Ablehnung weist häufig auf einen falschen Pfad, falsches Label, eine unpassende Dienstkonfiguration oder eine fehlende gezielte Richtlinie hin. Ein Wechsel in den permissiven Modus verändert den Sicherheitszustand des gesamten Systems und ist keine harmlose Standarddiagnose. --- **22. AppArmor prüfen** Status: ```bash aa-status ``` Kernel- und Auditmeldungen: ```bash journalctl -k | grep -i apparmor ``` Je nach System: ```bash grep -i apparmor /var/log/syslog ``` Mögliche Ursachen: - Anwendung verwendet einen neuen Pfad; - Profil erlaubt eine benötigte Datei nicht; - ausführbare Datei wurde verschoben; - Include-Regel fehlt; - Profil befindet sich im Enforce-Modus; - Anwendung startet einen nicht erlaubten Unterprozess; - Netzwerkzugriff ist eingeschränkt. Ein Profil sollte nicht ungeprüft deaktiviert werden. Zuerst sind Ablehnung, betroffener Pfad und notwendige Mindestberechtigung zu bestimmen. --- **23. Port und Socket prüfen** Lauschende TCP- und UDP-Sockets: ```bash ss -tulpn ``` Nur lauschende TCP-Sockets: ```bash ss -ltnp ``` Bestimmter Port: ```bash ss -ltnp 'sport = :443' ``` Bestehende TCP-Verbindungen: ```bash ss -tanp ``` Unix-Sockets: ```bash ss -lxnp ``` Zu unterscheiden sind: - kein Prozess lauscht; - Prozess lauscht nur auf `127.0.0.1`; - Prozess lauscht nur auf IPv6; - Prozess lauscht auf falscher Adresse; - anderer Prozess belegt den Port; - Socket-Aktivierung wird verwendet; - Firewall blockiert den Zugriff; - Anwendung lauscht, beantwortet Anfragen aber fehlerhaft. --- **24. Portkonflikt untersuchen** Belegung eines Ports: ```bash ss -ltnp 'sport = :8080' ``` Alternativ: ```bash lsof -nP -iTCP:8080 -sTCP:LISTEN ``` Mögliche Ursachen: - zweite Instanz wurde gestartet; - alter Prozess läuft noch; - Testdienst belegt den Produktionsport; - Container veröffentlicht denselben Hostport; - systemd-Socket besitzt den Port; - IPv4- und IPv6-Bindung kollidieren; - Konfiguration verwendet einen falschen Port. Ein Prozess darf nicht allein deshalb beendet werden, weil er den gewünschten Port belegt. Zuerst muss seine Funktion und Zuständigkeit geklärt werden. --- **25. Lokale Anwendungsfunktion prüfen** TCP-Verbindung: ```bash nc -vz 127.0.0.1 8080 ``` HTTP-Abfrage: ```bash curl -v http://127.0.0.1:8080/ ``` HTTPS einschließlich Zertifikatsprüfung: ```bash curl -v https://server.example.local/ ``` TLS-Verbindung untersuchen: ```bash openssl s_client \ -connect server.example.local:443 \ -servername server.example.local ``` Bewertung: | Ergebnis | Wahrscheinlicher Bereich | |---|---| | lokal kein Listener | Dienst, Konfiguration oder Startfehler | | lokal erreichbar, remote nicht | Firewall, Routing, Bind-Adresse oder Netzwerk | | TCP funktioniert, HTTP fehlerhaft | Anwendung, Reverse Proxy oder Backend | | HTTP über IP funktioniert, Name nicht | DNS, Virtual Host, SNI oder Zertifikat | | TLS schlägt fehl | Zertifikat, Schlüssel, Protokoll oder Cipher | | Antwort langsam | Anwendung, Backend, DNS, Storage oder Ressourcen | --- **26. Netzwerkkonfiguration prüfen** Adressen: ```bash ip address show ``` Kurzform: ```bash ip -br address ``` Links: ```bash ip -br link ``` Routingtabelle: ```bash ip route show ``` IPv6-Routen: ```bash ip -6 route show ``` Route zu einem konkreten Ziel: ```bash ip route get 192.0.2.20 ``` Nachbarn: ```bash ip neigh show ``` Netzwerkstatistik: ```bash ip -s link show ``` Zu prüfen sind: - Interface aktiv; - richtige IP-Adresse; - Präfix; - Default Gateway; - richtige Route; - Policy Routing; - VLAN; - Bond oder Bridge; - Paketfehler; - Drops; - MTU; - doppelte IP-Adresse; - IPv4- beziehungsweise IPv6-Auswahl. --- **27. Namensauflösung prüfen** Resolverkonfiguration: ```bash cat /etc/resolv.conf ``` Auf systemd-resolved-Systemen: ```bash resolvectl status ``` Namensauflösung über NSS: ```bash getent hosts server.example.local ``` DNS-Abfrage: ```bash dig server.example.local ``` Bestimmten DNS-Server abfragen: ```bash dig @192.0.2.53 server.example.local ``` Reverse Lookup: ```bash dig -x 192.0.2.20 ``` Zu unterscheiden sind: - DNS-Server nicht erreichbar; - falsche Suchdomäne; - falscher A- oder AAAA-Eintrag; - `/etc/hosts` überschreibt DNS; - Split DNS; - Cache enthält alten Wert; - Anwendung verwendet einen eigenen Resolver; - IPv6-Adresse wird bevorzugt, ist aber nicht erreichbar; - DNS-Auflösung funktioniert, die Anwendung verwendet jedoch einen anderen Namen. --- **28. Firewall prüfen** Je nach System können unterschiedliche Werkzeuge verwendet werden. firewalld: ```bash firewall-cmd --get-active-zones ``` ```bash firewall-cmd --list-all ``` nftables: ```bash nft list ruleset ``` iptables-Kompatibilitätsansicht: ```bash iptables -S ``` Zu prüfen sind: - zuständige Firewalltechnik; - aktive Zone; - Interface-Zuordnung; - Quellnetz; - Zielport; - Protokoll; - IPv4 und IPv6; - Eingangs- und Ausgangsrichtung; - Standardpolicy; - NAT; - Containerregeln; - Cloud- oder vorgelagerte Firewall; - Hostfirewall auf dem Gegenserver. Ein geöffneter Port in der Hostfirewall beweist nicht, dass vorgelagerte Firewalls, Routing oder die Anwendung funktionieren. --- **29. Paketmitschnitt** Beispiel für TCP-Port 443: ```bash tcpdump -ni any tcp port 443 ``` Bestimmter Host und Port: ```bash tcpdump -ni any \ host 192.0.2.20 and tcp port 443 ``` In Datei schreiben: ```bash tcpdump -ni any \ -s 0 \ -w /tmp/example-443.pcap \ tcp port 443 ``` Zu untersuchen sind: - kommen Anfragen am Server an; - sendet der Server Antworten; - TCP-SYN; - SYN/ACK; - Reset; - Retransmissions; - ICMP-Fehler; - falsches Interface; - falsche Quell- oder Zieladresse; - TLS-Handshake; - Zeitabstände; - MTU- oder Fragmentierungsprobleme. Paketmitschnitte können vertrauliche IP-Adressen, Hostnamen, Nutzdaten, Tokens und Anmeldeinformationen enthalten und müssen geschützt gespeichert sowie kontrolliert gelöscht werden. --- **30. CPU und Load prüfen** Überblick: ```bash uptime ``` Dynamische Prozessansicht: ```bash top ``` Logische Prozessoren: ```bash nproc ``` CPU-Informationen: ```bash lscpu ``` Falls `sysstat` installiert ist: ```bash mpstat -P ALL 1 5 ``` Prozessbezogene Statistik: ```bash pidstat 1 5 ``` Load Average beschreibt nicht ausschließlich CPU-Auslastung. Je nach Linux-Zustand können auch Tasks in nicht unterbrechbarem Zustand zur Last beitragen. Zu unterscheiden sind: - ein einzelner CPU-intensiver Prozess; - gleichmäßige Last auf allen CPUs; - Single-Thread-Limit; - hohe I/O-Wartezeit; - virtuelle CPU wird vom Hypervisor nicht ausreichend ausgeführt; - Interruptlast; - Prozessschleife; - zu viele gleichzeitig ausführbare Tasks. --- **31. Arbeitsspeicher prüfen** Speicherübersicht: ```bash free -h ``` Detaillierte Kernelwerte: ```bash cat /proc/meminfo ``` Prozesse nach Speicherverbrauch: ```bash ps aux --sort=-%mem | head ``` Falls verfügbar: ```bash vmstat 1 5 ``` Wichtige Unterscheidungen: - `free` ist nicht der allein verfügbare Speicher; - Cache kann bei Bedarf teilweise freigegeben werden; - `available` ist für die praktische Bewertung meist aussagekräftiger; - hoher Swap-Verbrauch beweist allein keine aktuelle Speicherknappheit; - aktive Swap-Ein- und -Auslagerung kann auf Speicherdruck hinweisen; - Speicherlimit eines Containers oder einer systemd-Unit kann unterhalb des Hostspeichers liegen. --- **32. OOM Killer untersuchen** Kernelmeldungen: ```bash journalctl -k -b | grep -Ei 'out of memory|oom|killed process' ``` Systemweites Journal: ```bash journalctl -b | grep -Ei 'out of memory|oom|killed process' ``` Mögliche Ursachen: - physischer Arbeitsspeicher erschöpft; - kein oder zu wenig Swap; - Speicherleck; - zu viele Prozesse; - Container- oder cgroup-Limit; - große temporäre Last; - falsche Anwendungskonfiguration; - übermäßiger Page Cache in Verbindung mit anderem Druck; - Kernel kann benötigten Speicher nicht bereitstellen. Zu dokumentieren sind: - beendeter Prozess; - Zeitpunkt; - Speicherverbrauch; - cgroup oder Container; - Host- und cgroup-Limit; - vorherige Last; - wiederholtes Auftreten; - Anwendungsprotokoll unmittelbar vor dem Kill. Ein automatischer Dienstneustart kann den OOM-Kill verdecken. Der Dienst erscheint anschließend wieder aktiv, obwohl die Ursache weiter besteht. --- **33. Swap prüfen** Aktive Swap-Bereiche: ```bash swapon --show ``` Speicherübersicht: ```bash free -h ``` Aktivität: ```bash vmstat 1 10 ``` Bei `vmstat` sind insbesondere zu beachten: - `si`: Swap-In; - `so`: Swap-Out; - `wa`: I/O-Wartezeit; - `r`: ausführbare Prozesse; - `b`: blockierte Prozesse. Swap darf nicht ungeprüft mit `swapoff` deaktiviert werden. Der Inhalt muss in den Arbeitsspeicher übernommen werden können; andernfalls drohen starke Last oder Fehler. --- **34. Speicherplatz prüfen** Dateisysteme: ```bash df -hT ``` Bestimmter Pfad: ```bash df -hT /var/lib/example ``` Verzeichnisgrößen: ```bash du -xhd1 /var ``` Größte Unterverzeichnisse: ```bash du -xhd1 /var | sort -h ``` Zu unterscheiden sind: - Dateisystem voll; - Thin Pool voll; - Snapshotbereich voll; - Quote erreicht; - gelöschte, aber geöffnete Datei; - reservierter Speicher; - anderes darunterliegendes Dateisystem; - temporäres Dateisystem voll; - Container-Overlay voll; - Logdatei wächst unkontrolliert; - Anwendung schreibt in einen unerwarteten Pfad. `df` und `du` können unterschiedliche Werte zeigen, beispielsweise wegen gelöschter, aber geöffneter Dateien oder wegen Mounts innerhalb des untersuchten Verzeichnisbaums. --- **35. Inodes prüfen** Inode-Nutzung: ```bash df -ih ``` Ein Dateisystem kann freien Speicherplatz besitzen und trotzdem keine neuen Dateien mehr aufnehmen, wenn keine freien Inodes vorhanden sind. Typische Ursachen: - sehr viele kleine Dateien; - Cache-Verzeichnis; - Mailqueue; - Sessiondateien; - temporäre Dateien; - fehlerhafte Rotation; - Anwendung erzeugt Dateien, löscht sie aber nicht; - Containerlayer; - Build- oder Paketcache. Anzahl der Einträge in einem kontrollierten Verzeichnisbaum: ```bash find /var/tmp/example -xdev -type f | wc -l ``` Bei sehr großen Verzeichnisbäumen kann bereits das Zählen erhebliche I/O-Last verursachen. --- **36. Mounts prüfen** Aktuelle Mounts: ```bash findmnt ``` Bestimmter Pfad: ```bash findmnt -T /var/lib/example ``` Blockgeräte und Dateisysteme: ```bash lsblk -f ``` Persistente Konfiguration: ```bash cat /etc/fstab ``` fstab-Konfiguration ohne tatsächliches Mounten prüfen: ```bash findmnt --verify ``` systemd-Mount-Units: ```bash systemctl list-units --type=mount --all ``` Zu prüfen sind: - richtiges Gerät oder UUID; - richtiger Mountpoint; - Dateisystemtyp; - Mountoptionen; - `ro` statt `rw`; - Netzwerkabhängigkeit; - `_netdev`; - Automount; - Berechtigungen; - verschachtelte Mounts; - nicht mehr erreichbares NFS- oder SMB-Ziel; - veralteter Handle; - Timeout; - lokales Verzeichnis wird sichtbar, weil der erwartete Mount fehlt. Eine Anwendung kann scheinbar korrekt in einen lokalen Ordner schreiben, obwohl das vorgesehene Netzwerk- oder Datenvolume nicht eingehängt ist. --- **37. Schreibgeschütztes Dateisystem** Mountoptionen: ```bash findmnt -o TARGET,SOURCE,FSTYPE,OPTIONS ``` Kernelmeldungen: ```bash journalctl -k -b | grep -Ei 'read-only|I/O error|filesystem|ext4|xfs' ``` Mögliche Ursachen: - Dateisystem wurde wegen Fehlern schreibgeschützt eingehängt; - Datenträgerfehler; - Storage-Verbindung unterbrochen; - falsche Mountoption; - Snapshot oder Image ist absichtlich read-only; - Container-Dateisystem ist schreibgeschützt; - NFS-Export ist read-only; - Cluster- oder Schutzmechanismus verhindert Schreibzugriff. Ein ungeprüftes Remount als `rw` kann eine bestehende Storage- oder Dateisystemstörung verschärfen. Zuerst müssen Kernelmeldungen und Datenträgerzustand bewertet werden. --- **38. Datenträger- und I/O-Fehler prüfen** Blockgeräte: ```bash lsblk -o NAME,TYPE,SIZE,FSTYPE,MOUNTPOINTS,MODEL,SERIAL ``` Kernelmeldungen: ```bash journalctl -k -b | grep -Ei 'I/O error|blk_update|reset|timeout|nvme|ata|scsi|ext4|xfs' ``` Falls `sysstat` installiert ist: ```bash iostat -xz 1 5 ``` S.M.A.R.T.-Informationen, sofern unterstützt: ```bash smartctl -a /dev/sda ``` NVMe-Informationen, sofern das Werkzeug installiert ist: ```bash nvme smart-log /dev/nvme0 ``` Zu prüfen sind: - I/O-Fehler; - Timeouts; - Resets; - Medienfehler; - hohe Latenz; - hohe Queue; - fehlendes Gerät; - Multipath-Fehler; - RAID-Degradation; - Dateisystemfehler; - virtuelle oder externe Storage-Abhängigkeit. S.M.A.R.T.-Tests und Reparaturwerkzeuge können Last oder Zustandsänderungen verursachen. Sie sind nicht ungeprüft auf produktivem Storage auszuführen. --- **39. Dateisystemprüfung sicher planen** Dateisystemtyp feststellen: ```bash findmnt -no FSTYPE,SOURCE,TARGET /var/lib/example ``` Ein klassisches `fsck` darf normalerweise nicht auf einem schreibend eingehängten Dateisystem ausgeführt werden. Vor einer Reparatur sind zu klären: - Dateisystemtyp; - Herstellerverfahren; - Mountzustand; - Backup; - Wartungsfenster; - Ausfallwirkung; - Storage- und RAID-Zustand; - erwartete Reparaturdauer; - Rückweg; - Notfallzugang. Bei XFS, ext4, Btrfs und anderen Dateisystemen unterscheiden sich Diagnose- und Reparaturwerkzeuge erheblich. --- **40. LVM prüfen** Übersicht: ```bash pvs ``` ```bash vgs ``` ```bash lvs ``` Ausführlicher: ```bash lvs -a -o +devices ``` Zu prüfen sind: - Physical Volume vorhanden; - Volume Group vollständig; - Logical Volume aktiv; - freier Platz in der Volume Group; - Thin Pool; - Thin-Metadaten; - Snapshot; - zugrunde liegende Geräte; - Dateisystemgröße; - Mountzustand. Ein vergrößertes Logical Volume bedeutet nicht automatisch, dass auch das darin enthaltene Dateisystem vergrößert wurde. --- **41. Software-RAID prüfen** Status: ```bash cat /proc/mdstat ``` Detailinformationen: ```bash mdadm --detail /dev/md0 ``` Zu prüfen sind: - RAID-Level; - aktive Geräte; - fehlende Geräte; - degradiert; - Rebuild; - Resync; - Geschwindigkeit; - Fehlerzähler; - Ersatzgerät; - zugrunde liegender Datenträgerzustand. Ein Rebuild erhöht die I/O-Last und ersetzt kein Backup. Ein zweiter Fehler während der Wiederherstellung kann je nach RAID-Level zum Datenverlust führen. --- **42. Netzwerk-Mounts prüfen** NFS-Mounts: ```bash findmnt -t nfs,nfs4 ``` SMB-/CIFS-Mounts: ```bash findmnt -t cifs ``` RPC-Dienste eines NFS-Servers: ```bash rpcinfo -p ``` NFS-Exporte, sofern erreichbar: ```bash showmount -e ``` Zu prüfen sind: - Namensauflösung; - Route; - Port; - Serverzustand; - Export oder Freigabe; - Protokollversion; - Mountoptionen; - Benutzer- und ID-Zuordnung; - Kerberos; - Firewall; - Timeout; - Hard- oder Soft-Mount; - veralteter NFS-Handle; - blockierte Prozesse im Zustand `D`. Ein hängender Netzwerk-Mount kann Befehle wie `df`, `du`, `ls` oder Anwendungen blockieren. --- **43. Paketverwaltung prüfen** Debian- und Ubuntu-Systeme: ```bash apt update ``` Installierten Paketstatus prüfen: ```bash dpkg -l ``` Unterbrochene Paketkonfiguration: ```bash dpkg --audit ``` RPM-basierte Systeme: ```bash dnf check ``` Installiertes Paket bestimmen: ```bash rpm -q ``` Datei einem Paket zuordnen: ```bash rpm -qf /usr/bin/example ``` Debian-Paket zuordnen: ```bash dpkg -S /usr/bin/example ``` Mögliche Ursachen: - Repository nicht erreichbar; - DNS- oder Proxyfehler; - abgelaufenes Repository-Zertifikat; - falsche Systemzeit; - Signaturfehler; - Paketdatenbank gesperrt; - abgebrochene Transaktion; - inkompatible Paketversionen; - fehlende Bibliothek; - Drittanbieter-Repository; - Paket wurde manuell überschrieben; - Konfigurationsdatei wurde bei einem Upgrade ersetzt oder nicht übernommen. Paketdatenbanken und Lockdateien dürfen nicht ungeprüft gelöscht werden. Zuerst ist zu bestimmen, ob ein legitimer Paketprozess aktiv ist. --- **44. Paketdateien verifizieren** RPM-Paket: ```bash rpm -V ``` Debian- und Ubuntu-Systeme, falls `debsums` installiert ist: ```bash debsums ``` Abweichungen können entstehen durch: - legitime Konfigurationsänderung; - Update; - beschädigte Datei; - manuelle Änderung; - Sicherheitsvorfall; - falsche Berechtigung; - falscher Eigentümer. Eine Abweichung beweist allein weder einen Defekt noch eine Manipulation. Dateityp und erwartete lokale Anpassung müssen berücksichtigt werden. --- **45. Cronjobs prüfen** Systemweite Crontab: ```bash cat /etc/crontab ``` Systemverzeichnisse: ```bash ls -la /etc/cron.d/ ``` Benutzer-Crontab: ```bash crontab -l ``` Crontab eines anderen Benutzers: ```bash sudo crontab -u exampleuser -l ``` Cron-Dienst: ```bash systemctl status cron ``` Je nach Distribution: ```bash systemctl status crond ``` Cron-Protokoll: ```bash journalctl -u cron ``` Oder: ```bash journalctl -u crond ``` Typische Ursachen: - falscher Benutzer; - eingeschränkte `PATH`-Variable; - relatives Arbeitsverzeichnis; - fehlende Umgebungsvariable; - falsche Zeitzone; - Shell-Unterschied; - fehlendes Ausführungsrecht; - Skript verwendet interaktive Eingaben; - Ausgabe und Fehler werden nicht protokolliert; - Datei besitzt falsche Zeilenenden; - überlappende Ausführungen; - Zielmount ist zum Ausführungszeitpunkt nicht verfügbar. Ein erfolgreicher manueller Skriptstart beweist nicht, dass der Cronjob mit seiner reduzierten Umgebung funktioniert. --- **46. systemd-Timer prüfen** Timer anzeigen: ```bash systemctl list-timers --all ``` Bestimmten Timer: ```bash systemctl status example.timer ``` Zugehörigen Dienst: ```bash systemctl status example.service ``` Protokolle: ```bash journalctl -u example.timer -u example.service ``` Konfiguration: ```bash systemctl cat example.timer ``` Zu prüfen sind: - Timer aktiv; - Timer aktiviert; - nächste Ausführung; - letzte Ausführung; - zugehörige Service-Unit; - Kalenderausdruck; - `Persistent=`; - Zufallsverzögerung; - Zeitzone; - Fehler der aufgerufenen Service-Unit. Der Timer kann erfolgreich ausgelöst haben, obwohl die zugehörige Service-Unit fehlgeschlagen ist. --- **47. Zeit und Zeitsynchronisation prüfen** Systemzeit: ```bash date --iso-8601=seconds ``` Status: ```bash timedatectl ``` Bei chrony: ```bash chronyc tracking ``` ```bash chronyc sources -v ``` Bei systemd-timesyncd: ```bash timedatectl timesync-status ``` Mögliche Auswirkungen falscher Zeit: - TLS-Zertifikate erscheinen ungültig; - Kerberos schlägt fehl; - Protokollereignisse lassen sich falsch zuordnen; - Tokens sind noch nicht oder nicht mehr gültig; - Cronjobs laufen zum falschen Zeitpunkt; - Replikation oder Clustermechanismen werden gestört; - Dateien besitzen unplausible Zeitstempel. Die Zeit darf auf produktiven Datenbank-, Cluster- oder Authentifizierungssystemen nicht ungeprüft sprunghaft verändert werden. --- **48. Zertifikate prüfen** Zertifikatsdatei: ```bash openssl x509 \ -in /etc/example/server.crt \ -noout \ -subject \ -issuer \ -dates \ -fingerprint ``` Private-Key-Dateirechte: ```bash stat /etc/example/server.key ``` Zertifikat und Schlüssel vergleichen, beispielhaft für RSA: ```bash openssl x509 \ -noout \ -modulus \ -in /etc/example/server.crt | openssl sha256 ``` ```bash openssl rsa \ -noout \ -modulus \ -in /etc/example/server.key | openssl sha256 ``` Zu prüfen sind: - Ablaufdatum; - Gültigkeitsbeginn; - Hostname beziehungsweise SAN; - Aussteller; - Zertifikatskette; - passender privater Schlüssel; - Dateirechte; - tatsächlich vom Dienst geladenes Zertifikat; - SNI; - Systemzeit; - vertrauenswürdige CA. Private Schlüssel dürfen nicht in Diagnoseprotokolle oder Tickets kopiert werden. --- **49. Kernelmeldungen prüfen** Aktueller Systemstart: ```bash journalctl -k -b ``` Warnungen und Fehler: ```bash journalctl -k -b -p warning ``` Klassische Anzeige: ```bash dmesg --level=emerg,alert,crit,err,warn ``` Mögliche relevante Meldungen: - I/O-Fehler; - Dateisystemfehler; - OOM; - Treiberfehler; - Linkverlust; - NIC-Reset; - SCSI- oder NVMe-Timeout; - Hardwarefehler; - Kernel-Warnung; - Soft Lockup; - Hard Lockup; - Hung Task; - Segmentation Fault; - AppArmor- oder SELinux-Ablehnung. Der `dmesg`-Puffer kann ältere Meldungen überschreiben. Das persistente Journal oder ein zentraler Logserver kann deshalb zusätzliche Informationen liefern. --- **50. Kernelmodule und Hardware prüfen** Geladene Module: ```bash lsmod ``` Modulinformationen: ```bash modinfo ``` PCI-Geräte und Treiber: ```bash lspci -k ``` USB-Geräte: ```bash lsusb ``` Hardwareübersicht: ```bash lscpu ``` ```bash lsblk ``` Mögliche Ursachen: - benötigtes Modul fehlt; - falsches Modul ist gebunden; - Firmware fehlt; - Kernelupdate passt nicht zu externem Modul; - DKMS-Build fehlgeschlagen; - Gerät wurde getrennt; - virtuelle Hardware wurde geändert; - Modulparameter sind falsch; - Secure Boot verhindert das Laden eines nicht vertrauenswürdigen Moduls. Kernelmodule dürfen nicht ungeprüft entladen werden. Ein Modul kann von Netzwerk-, Storage- oder anderen produktiven Geräten verwendet werden. --- **51. Bootfehler untersuchen** Bootzeit analysieren: ```bash systemd-analyze ``` Langsame Units: ```bash systemd-analyze blame ``` Kritische Kette: ```bash systemd-analyze critical-chain ``` Fehlgeschlagene Units: ```bash systemctl --failed ``` Protokoll des aktuellen Starts: ```bash journalctl -b ``` Protokoll des vorherigen Starts: ```bash journalctl -b -1 ``` Verfügbare Starts: ```bash journalctl --list-boots ``` Zu prüfen sind: - Kernelkommandozeile; - initramfs; - Root-Dateisystem; - fehlerhafte `/etc/fstab`; - fehlendes Blockgerät; - Netzwerk-Mount; - systemd-Abhängigkeit; - Timeout; - Dateisystemprüfung; - Treiber; - verschlüsseltes Volume; - falscher Default-Target; - wiederholt abstürzender Dienst. --- **52. Unerwarteten Neustart oder Absturz prüfen** Letzte Neustarts: ```bash last reboot ``` Vorheriger Boot: ```bash journalctl -b -1 -e ``` Kernelmeldungen des vorherigen Boots: ```bash journalctl -k -b -1 ``` Mögliche Ursachen: - geplanter Neustart; - Paket- oder Kernelupdate; - Stromausfall; - Hypervisoraktion; - Hardware-Watchdog; - Kernel Panic; - OOM; - Temperaturproblem; - manuelle Administratoraktion; - Cloud- oder Hostingereignis; - fehlerhafte Automation. Fehlende Abschlussmeldungen im Journal können auf einen abrupten Ausfall hinweisen, beweisen aber keine bestimmte Ursache. --- **53. Hängendes System und Hung Tasks** Nach Meldungen suchen: ```bash journalctl -k | grep -Ei 'blocked for more than|hung task|soft lockup|hard lockup' ``` Mögliche Ursachen: - blockiertes Storage; - hängender Netzwerk-Mount; - Treiberfehler; - defektes Gerät; - Kernelproblem; - hohe I/O-Latenz; - Deadlock; - Ressourcenerschöpfung. Magic SysRq kann in schweren Störungsfällen Diagnose- oder Notfallfunktionen auslösen. Die verfügbaren Funktionen hängen von Kernelkonfiguration und Systemwerten ab. Status: ```bash cat /proc/sys/kernel/sysrq ``` SysRq-Aktionen können erhebliche Auswirkungen bis hin zu Prozessbeendigung oder Neustart besitzen. Sie dürfen nur nach einem dafür vorgesehenen Notfallverfahren verwendet werden. --- **54. Strace als gezielte Tiefenanalyse** Systemaufrufe eines gestarteten Programms: ```bash strace -f -o /tmp/example.strace ``` An laufenden Prozess anhängen: ```bash strace -f -p ``` Nach Dateioperationen filtern: ```bash strace -f -e trace=file ``` Nach Netzwerkoperationen filtern: ```bash strace -f -e trace=network ``` Zu erkennen sind beispielsweise: - `ENOENT`: Datei oder Pfad nicht vorhanden; - `EACCES`: Zugriff verweigert; - `ECONNREFUSED`: Verbindung abgelehnt; - `ETIMEDOUT`: Zeitüberschreitung; - `ENOSPC`: kein Speicherplatz; - `EROFS`: Dateisystem nur lesbar. `strace` kann Leistung und Zeitverhalten beeinflussen sowie vertrauliche Dateinamen, Argumente und Daten sichtbar machen. --- **55. Typische Fehlerbilder** | Symptom | Mögliche Ursache | Nächster Test | |---|---|---| | Dienst startet nicht | Syntax, Rechte, Abhängigkeit oder fehlende Datei | `systemctl status`, `journalctl -u` | | Dienst beendet sich sofort | Anwendung meldet Fehler oder Prozess forkt anders als erwartet | Journal und `ExecMainStatus` | | Dienst ist `active`, Anwendung funktioniert nicht | interner Fehler, falscher Port oder Backend gestört | `ss`, `curl`, Anwendungslog | | Dienst ist `failed`, Prozess läuft | Prozess wurde außerhalb von systemd gestartet | `ps`, `systemctl show` | | Dienst startet nach Reboot nicht | nicht aktiviert oder Boot-Abhängigkeit fehlerhaft | `is-enabled`, Bootjournal | | Dienst läuft als falscher Benutzer | Unit oder Drop-in geändert | `systemctl cat`, `systemctl show` | | Konfigurationsänderung wirkt nicht | falsche Datei oder kein Reload/Restart | Prozessargumente und Unit prüfen | | Port ist nicht geöffnet | Dienststart oder Bind-Konfiguration | `ss -ltnp` | | Port ist nur lokal erreichbar | Bind-Adresse oder Firewall | `ss`, Firewall, Remote-Test | | Port bereits belegt | zweite Instanz oder anderer Dienst | `ss`, `lsof` | | Zugriff verweigert | Unix-Rechte, ACL, SELinux oder AppArmor | `namei`, `getfacl`, Auditlog | | Datei nicht gefunden, obwohl sie existiert | falscher Namespace, Mount oder Pfadbestandteil | `namei`, `findmnt`, Prozessumgebung | | Schreiben schlägt fehl | Rechte, `ro`, Speicher oder Inodes | `test -w`, `findmnt`, `df -h`, `df -i` | | `df` zeigt voll, `du` nicht | gelöschte offene Datei oder reservierter Bereich | `lsof +L1` | | `du` hängt | Netzwerk-Mount oder Storageproblem | `findmnt`, Prozesszustand, Kerneljournal | | hohe Load bei geringer CPU | I/O-Wait oder Tasks im Zustand `D` | `vmstat`, `iostat`, `ps` | | Prozess wurde unerwartet beendet | OOM, Signal oder Crash | Kernel- und Dienstjournal | | Server nutzt Swap stark | früherer oder aktueller Speicherdruck | `vmstat`, `free`, Prozessspeicher | | keine neuen Dateien trotz freiem Speicher | Inodes erschöpft | `df -ih` | | Mount fehlt nach Neustart | fstab, Abhängigkeit oder Gerät fehlt | `findmnt --verify`, Bootjournal | | Dateisystem plötzlich read-only | I/O- oder Dateisystemfehler | Kerneljournal | | Cronjob läuft manuell, aber nicht automatisch | Umgebung, Benutzer, Pfad oder Shell | Cronlog und kontrollierter Umgebungstest | | systemd-Timer löst aus, Aufgabe scheitert | zugehörige Service-Unit fehlerhaft | Journal beider Units | | TLS-Zertifikat angeblich abgelaufen | falsche Zeit oder altes geladenes Zertifikat | `timedatectl`, `openssl s_client` | | Paketupdate schlägt fehl | Repository, DNS, Signatur oder Lock | Paketmanager- und Prozessstatus | | Server startet langsam | Mount-, Netzwerk- oder Unit-Timeout | `systemd-analyze critical-chain` | | Netzwerk funktioniert nach IP, nicht nach Name | DNS oder NSS | `getent hosts`, `dig` | --- **56. Vorgehensweise bei „Dienst startet nicht“** 1. Host, Dienstname und Zeitpunkt dokumentieren. 2. `systemctl status` auswerten. 3. `systemctl show` auf Ergebnis und Exit-Status prüfen. 4. Dienstjournal seit dem letzten Startversuch lesen. 5. erste relevante Fehlermeldung bestimmen. 6. tatsächlich verwendete Unit und Drop-ins anzeigen. 7. Startbenutzer und Gruppen prüfen. 8. Anwendungskonfiguration mit dem vorgesehenen Syntaxprüfer testen. 9. benötigte Dateien und Pfade prüfen. 10. Unix-Rechte, ACL und alle Pfadbestandteile prüfen. 11. SELinux- oder AppArmor-Ablehnungen prüfen. 12. Portkonflikte prüfen. 13. Mounts und externe Abhängigkeiten prüfen. 14. Speicherplatz, Inodes, RAM und Limits kontrollieren. 15. genau eine nachgewiesene Ursache korrigieren. 16. Dienst kontrolliert starten. 17. Journal, Prozess, Port und Anwendungsfunktion nachkontrollieren. 18. Ursache, Maßnahme und Rückweg dokumentieren. --- **57. Vorgehensweise bei „Server ist langsam“** 1. Zeitraum und konkrete langsame Funktion erfassen. 2. Vergleichswert oder normalen Zustand bestimmen. 3. Load, CPU, RAM und Swap prüfen. 4. Prozesse nach CPU- und Speicherverbrauch sortieren. 5. Prozesszustände und blockierte Tasks prüfen. 6. `vmstat` auswerten. 7. I/O-Latenz und Datenträgerauslastung prüfen. 8. Kernelmeldungen auf Storage- oder Treiberfehler untersuchen. 9. Netzwerkfehler, Drops und Retransmissions berücksichtigen. 10. DNS-Antwortzeiten prüfen. 11. Anwendung und Backend getrennt testen. 12. cgroup-, Container- oder Unit-Limits prüfen. 13. geplante Jobs, Backups und Updates berücksichtigen. 14. Engpass anhand von Messwerten nachweisen. 15. eine kontrollierte Maßnahme durchführen. 16. dieselbe Funktion mit denselben Messwerten erneut testen. --- **58. Vorgehensweise bei „Kein Speicherplatz“** 1. betroffenen Pfad dokumentieren. 2. zugehöriges Dateisystem mit `findmnt -T` bestimmen. 3. Speicherplatz mit `df -hT` prüfen. 4. Inodes mit `df -ih` prüfen. 5. Quotas und Storage-Limits berücksichtigen. 6. Verzeichnisgrößen innerhalb desselben Dateisystems untersuchen. 7. gelöschte offene Dateien mit `lsof +L1` prüfen. 8. Logs, Caches, temporäre Dateien und Containerdaten unterscheiden. 9. LVM-Thin-Pool oder Snapshotbereich prüfen. 10. Ursache des Wachstums bestimmen. 11. Aufbewahrungs- und Löschregeln prüfen. 12. keine unbekannten Dateien pauschal löschen. 13. eine kontrollierte Bereinigung oder Erweiterung durchführen. 14. Anwendung und Speicherzustand erneut prüfen. 15. Präventionsmaßnahme wie Rotation, Monitoring oder Quota dokumentieren. --- **59. Vorgehensweise bei „Dateisystem oder Mount nicht verfügbar“** 1. betroffenen Mountpoint dokumentieren. 2. `findmnt` und `lsblk -f` auswerten. 3. Blockgerät, UUID und Dateisystemtyp bestimmen. 4. `/etc/fstab` prüfen. 5. `findmnt --verify` ausführen. 6. systemd-Mount-Unit und Journal prüfen. 7. Kernelmeldungen auf I/O-Fehler untersuchen. 8. bei Netzwerk-Mounts DNS, Route, Port und Server prüfen. 9. offene Prozesse und Abhängigkeiten berücksichtigen. 10. Storage-, RAID-, LVM- oder Multipath-Zustand prüfen. 11. Backup und Wartungsfenster klären. 12. nur die nachgewiesene Ursache korrigieren. 13. Mount kontrolliert herstellen. 14. Lese- und Schreibfunktion entsprechend dem Sollzustand testen. 15. Neustartverhalten gesondert verifizieren. --- **60. Maßnahmen und Rückwege** **Ursache: Syntaxfehler in der Dienstkonfiguration** Nachweis: - Dienstjournal nennt die Konfigurationsdatei und Zeile; - anwendungseigener Syntaxprüfer reproduziert den Fehler; - vorherige Konfiguration war funktionsfähig. Maßnahme: - fehlerhafte Anweisung nach dokumentiertem Sollzustand korrigieren. Rollback: - gesicherte vorherige Konfiguration wiederherstellen. Verifikation: - Syntaxprüfung; - Dienststart; - Journal; - Port; - praktische Anwendungsfunktion. --- **Ursache: falsche Dateiberechtigung** Nachweis: - Dienst läuft unter dem vorgesehenen Benutzer; - benötigte Aktion schlägt für diesen Benutzer fehl; - `namei`, `stat` oder `getfacl` zeigt das fehlende Recht; - kein SELinux- oder AppArmor-Problem liegt vor. Maßnahme: - Eigentümer, Gruppe oder Mindestberechtigung nach dem Sollzustand korrigieren. Rollback: - vorherige Eigentümer-, Modus- und ACL-Werte dokumentiert wiederherstellen. Verifikation: - Zugriff als Dienstbenutzer; - Dienststart; - keine unnötigen zusätzlichen Rechte; - Anwendungsfunktion. --- **Ursache: falscher SELinux-Kontext** Nachweis: - AVC-Meldung passt zum Fehlerzeitpunkt; - Pfad besitzt einen vom Richtlinien-Soll abweichenden Kontext; - Unix-Rechte sind ausreichend. Maßnahme: - vorgesehenen persistenten Dateikontext konfigurieren und Kontext kontrolliert wiederherstellen. Rollback: - vorherige lokale Kontextregel dokumentiert wiederherstellen oder entfernen. Verifikation: - korrekter Kontext; - keine neue AVC-Ablehnung; - Dienst- und Benutzerfunktion; - SELinux bleibt enforcing. --- **Ursache: Portkonflikt** Nachweis: - Anwendung meldet „Address already in use“; - `ss` oder `lsof` zeigt den belegenden Prozess; - Prozess und Zuständigkeit wurden identifiziert. Maßnahme: - falsche Doppelinstanz kontrolliert entfernen oder den vorgesehenen Dienstport nach Sollkonfiguration zuordnen. Rollback: - ursprüngliche Port- und Dienstkonfiguration wiederherstellen. Verifikation: - vorgesehener Prozess besitzt den Port; - Anwendung antwortet lokal und remote; - keine zweite Anwendung wurde beeinträchtigt. --- **Ursache: gelöschte offene Logdatei belegt Speicher** Nachweis: - `df` zeigt hohe Belegung; - `du` erklärt die Belegung nicht; - `lsof +L1` zeigt eine große gelöschte Datei; - zuständiger Prozess wurde bestimmt. Maßnahme: - Prozess nach betrieblicher Freigabe kontrolliert zum erneuten Öffnen seiner Logs veranlassen oder neu starten. Rollback: - bei einem reinen Reopen normalerweise nicht erforderlich; bei Neustart gilt das dienstbezogene Rückfallverfahren. Verifikation: - Dateideskriptor geschlossen; - Speicherplatz freigegeben; - neue Protokolldatei wird korrekt beschrieben; - Dienstfunktion bleibt erhalten. --- **61. Nachkontrolle** Nach einer Maßnahme sind mindestens folgende Punkte zu prüfen: - Dienst besitzt den erwarteten Zustand; - Prozess läuft unter dem vorgesehenen Benutzer; - Prozess wird nicht fortlaufend neu gestartet; - keine neuen Fehler erscheinen im Journal; - erwarteter Port wird von der richtigen Anwendung verwendet; - Bind-Adresse ist korrekt; - lokale Anwendungsfunktion funktioniert; - Remotezugriff funktioniert; - DNS-Name zeigt auf das richtige System; - Firewallzustand entspricht dem Soll; - benötigte Dateien sind erreichbar; - Eigentümer und Berechtigungen sind minimal und korrekt; - SELinux oder AppArmor bleibt wirksam; - erforderliche Mounts sind vorhanden; - Dateisystem ist im vorgesehenen Modus eingehängt; - Speicherplatz und Inodes sind ausreichend; - keine gelöschten großen Dateien bleiben geöffnet; - CPU, RAM, Swap und I/O sind plausibel; - keine neuen Kernel- oder Storagefehler erscheinen; - Timer oder Cronjob arbeitet auch automatisch; - Verhalten nach einem Neustart wurde berücksichtigt; - temporäre Diagnoseänderungen wurden zurückgenommen; - Ursache, Maßnahme, Rückweg und Ergebnis wurden dokumentiert. --- **62. Dokumentationsbeispiel** ```text Symptom: Der Dienst example-api ließ sich nach einem Konfigurationsupdate nicht mehr starten. Clients erhielten „Connection refused“ auf TCP-Port 8443. Zeitpunkt: 02.08.2026, 11:42 Uhr MESZ Server: linux-app-01.example.local Dienst: example-api.service Nachweis: systemctl status zeigte den Zustand „failed“. Im Journal war unmittelbar nach dem Startversuch ein Berechtigungsfehler für /etc/example-api/server.key dokumentiert. Der Dienst lief als Benutzer example-api. Ein kontrollierter Lesetest als example-api schlug fehl. Die übergeordneten Verzeichnisse waren zugänglich. Es gab keine passende SELinux- oder AppArmor-Ablehnung. Die Schlüsseldatei war nach dem Austausch irrtümlich root:root mit Modus 0600 zugeordnet worden. Ursache: Die neue private Schlüsseldatei besaß nicht den vorgesehenen Gruppeneigentümer. Der Dienstbenutzer konnte sie deshalb nicht lesen. Maßnahme: Nach Dokumentation des Ausgangszustands wurde die Datei der vorgesehenen Dienstgruppe zugeordnet. Der Modus blieb auf das erforderliche Minimum beschränkt. Rollback: Der ursprüngliche Eigentümer und die ursprüngliche Gruppe wurden dokumentiert und können wiederhergestellt werden. Verifikation: Der Konfigurationstest war erfolgreich. Der Dienst startete ohne neue Fehlermeldung. TCP-Port 8443 wurde durch den vorgesehenen Prozess geöffnet. Die lokale und externe HTTPS-Prüfung waren erfolgreich. Der private Schlüssel ist weiterhin nicht für andere Benutzer lesbar. Prävention: Der Zertifikatsaustausch wird künftig durch einen dokumentierten Ablauf mit Kontrolle von Eigentümer, Gruppe, Modus, Sicherheitskontext und anschließendem Konfigurationstest durchgeführt. ``` --- **63. Entscheidungsbaum** ```text Linux-Dienst oder Anwendung gestört ↓ Ist das System erreichbar und die Zeit plausibel? ├── Nein │ ↓ │ Boot, Netzwerk, Routing, DNS und Zeit prüfen │ └── Ja ↓ Ist die Unit aktiv? ├── Nein │ ↓ │ Status, Exit-Code und Dienstjournal prüfen │ └── Ja ↓ Läuft der erwartete Prozess unter der richtigen Identität? ├── Nein │ ↓ │ Unit, Drop-ins, Benutzer und Startmethode prüfen │ └── Ja ↓ Lauscht die Anwendung auf der vorgesehenen Adresse und dem Port? ├── Nein │ ↓ │ Konfiguration, Portkonflikt und Socket-Aktivierung prüfen │ └── Ja ↓ Funktioniert die Anwendung lokal? ├── Nein │ ↓ │ Anwendung, Backend, Rechte, Mounts und Ressourcen prüfen │ └── Ja ↓ Funktioniert der Zugriff über das Netzwerk? ├── Nein │ ↓ │ Bind-Adresse, Firewall, Route, DNS und Paketfluss prüfen │ └── Ja ↓ Benutzerfunktion, Lastverhalten und abhängige Systeme prüfen ``` --- **64. Typische Prüfungsfragen** **Warum reicht der Zustand `active` eines systemd-Dienstes nicht als vollständiger Funktionsnachweis?**
Antwort anzeigen Der Zustand zeigt, dass systemd die Unit als aktiv betrachtet. Er beweist nicht, dass die Anwendung auf dem richtigen Port lauscht, ihre Backends erreicht oder korrekte Antworten auf Benutzeranfragen liefert.
**Worin unterscheiden sich `enabled` und `active`?**
Antwort anzeigen `enabled` beschreibt die Einbindung für einen automatischen Start. `active` beschreibt den aktuellen Laufzeitzustand. Ein Dienst kann aktiv und gleichzeitig nicht aktiviert sein oder aktiviert, aber aktuell fehlgeschlagen sein.
**Warum sollte zuerst `SIGTERM` und nicht sofort `SIGKILL` verwendet werden?**
Antwort anzeigen `SIGTERM` ermöglicht dem Prozess eine kontrollierte Beendigung, beispielsweise das Schreiben von Daten und Schließen von Dateien. `SIGKILL` kann nicht behandelt werden und verhindert eine geordnete Bereinigung.
**Warum können `df` und `du` unterschiedliche Speicherbelegungen anzeigen?**
Antwort anzeigen Eine häufige Ursache sind gelöschte Dateien, die von einem laufenden Prozess weiterhin geöffnet gehalten werden. `du` findet sie nicht mehr im Verzeichnisbaum, während das Dateisystem den belegten Speicher weiterhin berücksichtigt.
**Warum kann ein Dateisystem trotz freiem Speicherplatz keine neue Datei aufnehmen?**
Antwort anzeigen Die verfügbaren Inodes können erschöpft sein. In diesem Fall ist noch Datenkapazität frei, aber es können keine weiteren Dateisystemobjekte angelegt werden.
**Warum beweist ein erfolgreicher manueller Skriptstart nicht, dass ein Cronjob funktioniert?**
Antwort anzeigen Cron verwendet häufig eine reduzierte Umgebung, einen anderen Benutzer, ein anderes Arbeitsverzeichnis und eine eingeschränkte `PATH`-Variable. Das Skript kann deshalb manuell funktionieren und automatisch scheitern.
**Warum sollte SELinux nicht pauschal deaktiviert werden?**
Antwort anzeigen Dadurch wird eine wichtige Sicherheitsschicht für das gesamte System entfernt, ohne die eigentliche Ursache zu beheben. Stattdessen müssen Ablehnung, Pfad, Dateikontext und notwendige Mindestberechtigung untersucht werden.
**Was bedeutet ein Prozess im Zustand `D`?**
Antwort anzeigen Der Prozess befindet sich in einem nicht unterbrechbaren Schlafzustand und wartet häufig auf eine I/O- oder Kerneloperation. Die zugrunde liegende Storage-, Mount- oder Treiberstörung muss untersucht werden.
**Warum kann ein fehlender Mount zu Daten am falschen Ort führen?**
Antwort anzeigen Wenn der vorgesehene Mount fehlt, bleibt das lokale Mountpoint-Verzeichnis sichtbar. Eine Anwendung kann dann unbemerkt in das lokale Root-Dateisystem statt auf das vorgesehene Volume schreiben.
--- **65. Prüfungsfallen** - einen Dienst sofort neu starten, bevor Status und Protokolle gesichert wurden; - `active` mit vollständiger Anwendungsfunktion gleichsetzen; - `enabled` mit aktuell laufend gleichsetzen; - nur die letzte statt der ersten ursächlichen Fehlermeldung betrachten; - Unit-Drop-ins nicht berücksichtigen; - `After=` mit einer Startabhängigkeit gleichsetzen; - Prozess außerhalb von systemd starten und dadurch den Sollzustand verfälschen; - sofort `SIGKILL` verwenden; - Prozess im Zustand `D` wie einen normalen hängenden Prozess behandeln; - Zombieprozess ungeprüft als Hauptursache hoher Last ansehen; - Anwendung als `root` starten, um Berechtigungsfehler zu umgehen; - pauschal Modus `777` vergeben; - nur die Dateirechte, aber nicht die übergeordneten Verzeichnisse prüfen; - ACL-Maske nicht berücksichtigen; - SELinux oder AppArmor pauschal deaktivieren; - Auditmeldungen ohne zeitlichen Zusammenhang bewerten; - Portöffnung mit funktionierender Anwendung gleichsetzen; - nur localhost testen; - nur Remotezugriff testen, ohne die lokale Anwendung zu prüfen; - nur IPv4 und nicht IPv6 berücksichtigen; - `/etc/hosts`, NSS und DNS verwechseln; - Firewallregel ändern, ohne Zone und Interface zu prüfen; - Paketmitschnitte ungeschützt speichern; - Load Average mit reiner CPU-Auslastung gleichsetzen; - niedrigen Wert bei `free` automatisch als Speichermangel bewerten; - hohen Swap-Verbrauch ohne aktuelle Swap-Aktivität als Fehler ansehen; - OOM-Kill übersehen, weil systemd den Dienst neu gestartet hat; - nur Speicherplatz, aber keine Inodes prüfen; - Dateien allein nach Größe ungeprüft löschen; - Logdatei löschen, obwohl der Prozess sie weiterhin geöffnet hält; - `df` oder `du` auf hängenden Netzwerk-Mounts ungeprüft ausführen; - fehlenden Mount übersehen und in das lokale Mountpoint-Verzeichnis schreiben; - ein read-only-Dateisystem sofort als `rw` remounten; - `fsck` auf einem schreibend eingehängten Dateisystem ausführen; - LVM-Volume vergrößern, aber das Dateisystem nicht berücksichtigen; - RAID-Rebuild mit Backup gleichsetzen; - Paketmanager-Lockdatei ungeprüft löschen; - Drittanbieter-Repository und Versionsabhängigkeiten nicht berücksichtigen; - Cronjob mit der interaktiven Benutzerumgebung testen; - Timerstatus prüfen, aber die zugehörige Service-Unit nicht; - Systemzeit ungeprüft sprunghaft ändern; - private Schlüssel in Protokolle oder Tickets kopieren; - Kernelmodule ungeprüft entladen; - mehrere Änderungen gleichzeitig durchführen; - nur den Dienststatus, aber nicht die ursprüngliche Benutzerfunktion nachtesten. --- **66. Checkliste** - [ ] Hostname und Betriebssystem wurden dokumentiert. - [ ] Kernelversion und Architektur wurden erfasst. - [ ] Zeitpunkt und Zeitzone wurden geprüft. - [ ] vollständiger Fehlertext wurde dokumentiert. - [ ] Umfang der Störung wurde bestimmt. - [ ] letzte funktionierende Nutzung wurde erfasst. - [ ] letzte Änderungen wurden geprüft. - [ ] systemd-Gesamtzustand wurde geprüft. - [ ] Unit-Status und Exit-Code wurden geprüft. - [ ] Dienstjournal wurde ausgewertet. - [ ] vorheriger Boot wurde bei Bedarf berücksichtigt. - [ ] tatsächlich verwendete Unit-Datei wurde geprüft. - [ ] Drop-ins wurden berücksichtigt. - [ ] Abhängigkeiten und Startreihenfolge wurden geprüft. - [ ] Anwendungsidentität wurde bestimmt. - [ ] Prozess und Prozesszustand wurden geprüft. - [ ] wiederholte Prozessneustarts wurden berücksichtigt. - [ ] offene Dateien wurden bei Bedarf geprüft. - [ ] tatsächlich verwendete Konfiguration wurde bestimmt. - [ ] Konfigurationssyntax wurde geprüft. - [ ] Eigentümer, Gruppe und Modus wurden geprüft. - [ ] alle Bestandteile des Pfades wurden geprüft. - [ ] ACL wurde berücksichtigt. - [ ] Zugriff wurde als Dienstbenutzer getestet. - [ ] SELinux wurde geprüft. - [ ] AppArmor wurde geprüft. - [ ] Listener, Port und Bind-Adresse wurden geprüft. - [ ] Portkonflikt wurde ausgeschlossen. - [ ] lokale Anwendungsfunktion wurde getestet. - [ ] Remotezugriff wurde getestet. - [ ] IP-Adressen und Routen wurden geprüft. - [ ] DNS und NSS wurden berücksichtigt. - [ ] Firewallregeln wurden geprüft. - [ ] IPv4 und IPv6 wurden unterschieden. - [ ] CPU und Load wurden geprüft. - [ ] RAM und Swap wurden geprüft. - [ ] OOM-Ereignisse wurden geprüft. - [ ] Speicherplatz wurde geprüft. - [ ] Inodes wurden geprüft. - [ ] gelöschte offene Dateien wurden berücksichtigt. - [ ] Mounts wurden geprüft. - [ ] `/etc/fstab` wurde bei Mountproblemen geprüft. - [ ] read-only-Zustand wurde berücksichtigt. - [ ] Kernel- und I/O-Fehler wurden geprüft. - [ ] LVM oder RAID wurde bei Bedarf geprüft. - [ ] Netzwerk-Mounts wurden berücksichtigt. - [ ] Paketstatus und letzte Updates wurden geprüft. - [ ] Cronjob oder systemd-Timer wurde in seiner tatsächlichen Umgebung geprüft. - [ ] Zeit- und Zertifikatsprobleme wurden berücksichtigt. - [ ] Boot- und Kernelmeldungen wurden geprüft. - [ ] genau eine kontrollierte Maßnahme wurde durchgeführt. - [ ] Rückweg wurde vor der Änderung festgelegt. - [ ] Dienst, Port und Benutzerfunktion wurden nachgetestet. - [ ] temporäre Diagnoseänderungen wurden zurückgenommen. - [ ] Ursache, Maßnahme und Ergebnis wurden dokumentiert. --- **67. Schnellreferenz** | Beobachtung | Nächstes Werkzeug | |---|---| | Betriebssystemversion unklar | `cat /etc/os-release` | | Kernelversion unklar | `uname -r` | | Systemzustand unklar | `systemctl is-system-running` | | fehlgeschlagene Units gesucht | `systemctl --failed` | | Dienststatus unklar | `systemctl status` | | Exit-Code unklar | `systemctl show` | | Dienstprotokoll gesucht | `journalctl -u` | | vorheriger Boot relevant | `journalctl -b -1` | | tatsächliche Unit unklar | `systemctl cat` | | Drop-ins vermutet | `systemctl show -p DropInPaths` | | Unit-Syntax unklar | `systemd-analyze verify` | | Prozess gesucht | `pgrep -a`, `ps` | | Prozessbaum benötigt | `pstree -ap` | | offene Datei unklar | `lsof`, `fuser` | | gelöschte Datei belegt Speicher | `lsof +L1` | | Dienstbenutzer unklar | `systemctl show -p User -p Group` | | Benutzergruppen unklar | `id`, `getent` | | Pfadberechtigung unklar | `namei -l`, `stat` | | ACL unklar | `getfacl` | | SELinux-Status unklar | `getenforce`, `sestatus` | | SELinux-Ablehnung vermutet | `ausearch` | | AppArmor-Ablehnung vermutet | `aa-status`, Kerneljournal | | Listener unklar | `ss -ltnp` | | Portkonflikt vermutet | `ss`, `lsof` | | lokale HTTP-Funktion unklar | `curl -v` | | TLS-Fehler | `openssl s_client` | | IP-Konfiguration unklar | `ip -br address` | | Route unklar | `ip route get` | | DNS-Auflösung unklar | `getent hosts`, `dig` | | Firewallzustand unklar | `firewall-cmd`, `nft` | | Paketfluss unklar | `tcpdump` | | CPU-Last unklar | `top`, `mpstat`, `pidstat` | | RAM unklar | `free -h`, `vmstat` | | OOM vermutet | `journalctl -k` | | Swap unklar | `swapon --show`, `vmstat` | | Speicherplatz unklar | `df -hT` | | Verzeichnisgröße unklar | `du -xhd1` | | Inodes unklar | `df -ih` | | Mount unklar | `findmnt` | | Blockgerät unklar | `lsblk -f` | | fstab fehlerhaft vermutet | `findmnt --verify` | | I/O-Fehler vermutet | Kerneljournal, `iostat` | | LVM-Zustand unklar | `pvs`, `vgs`, `lvs` | | Software-RAID unklar | `/proc/mdstat`, `mdadm --detail` | | Paketdatei verändert | `rpm -V`, `debsums` | | Cronjob unklar | Crontab und Cronjournal | | systemd-Timer unklar | `systemctl list-timers --all` | | Zeitsynchronisation unklar | `timedatectl`, `chronyc` | | Boot langsam | `systemd-analyze critical-chain` | | Systemaufruf scheitert | `strace` | --- **Merksatz** > Auf einem Linux-Server wird vom objektiven Symptom über Unit, Prozess, Protokoll, Identität, Port und Abhängigkeiten bis zu Berechtigungen, Sicherheitsrichtlinien, Ressourcen, Mounts und Kernel geprüft. Ein Dienst wird erst verändert oder neu gestartet, wenn der Fehlerzustand gesichert, die Auswirkung bewertet und ein Rückweg festgelegt wurde. `active`, ein offener Port und ein erfolgreicher lokaler Test sind jeweils nur Teilnachweise – entscheidend ist die ursprüngliche Benutzerfunktion. --- **Quellen und weiterführende Dokumentation** **Offizielle systemd-Dokumentation** - [systemd – systemctl](https://www.freedesktop.org/software/systemd/man/latest/systemctl.html) - [systemd – journalctl](https://www.freedesktop.org/software/systemd/man/latest/journalctl.html) - [systemd – systemd.service](https://www.freedesktop.org/software/systemd/man/latest/systemd.service.html) - [systemd – systemd.unit](https://www.freedesktop.org/software/systemd/man/latest/systemd.unit.html) - [systemd – systemd.timer](https://www.freedesktop.org/software/systemd/man/latest/systemd.timer.html) - [systemd – systemd-analyze](https://www.freedesktop.org/software/systemd/man/latest/systemd-analyze.html) - [systemd – systemd.resource-control](https://www.freedesktop.org/software/systemd/man/latest/systemd.resource-control.html) **Offizielle Linux-Kernel-Dokumentation** - [Linux Kernel – Administration Guide](https://docs.kernel.org/admin-guide/index.html) - [Linux Kernel – Magic SysRq](https://docs.kernel.org/admin-guide/sysrq.html) - [Linux Kernel – Kernel Parameters](https://docs.kernel.org/admin-guide/kernel-parameters.html) - [Linux Kernel – Out Of Memory Handling](https://docs.kernel.org/mm/oom.html) - [Linux Kernel – Software RAID](https://docs.kernel.org/admin-guide/md.html) **Offizielle Red-Hat-Dokumentation** - [Red Hat Enterprise Linux 9 – Systemadministration und Monitoring](https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9) - [Red Hat Enterprise Linux 9 – SELinux verwenden](https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/using_selinux/) - [Red Hat – SELinux-Probleme untersuchen](https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/using_selinux/troubleshooting-problems-related-to-selinux_using-selinux) - [Red Hat Enterprise Linux 9 – Dateisysteme verwalten](https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/managing_file_systems/) - [Red Hat Enterprise Linux 9 – Systemstatus und Leistung überwachen](https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/monitoring_and_managing_system_status_and_performance/) - [Red Hat Enterprise Linux 9 – Logische Volumes verwalten](https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/configuring_and_managing_logical_volumes/) **Offizielle Ubuntu-Dokumentation** - [Ubuntu Server – How to manage systemd services](https://documentation.ubuntu.com/server/how-to/software/manage-services/) - [Ubuntu Server – Security](https://documentation.ubuntu.com/server/explanation/security/) - [Ubuntu Server – Networking](https://documentation.ubuntu.com/server/explanation/networking/) **Linux-Handbuchseiten** - [Linux man-pages – Übersicht](https://man7.org/linux/man-pages/dir_all_alphabetic.html) - [man7 – proc(5)](https://man7.org/linux/man-pages/man5/proc.5.html) - [man7 – signal(7)](https://man7.org/linux/man-pages/man7/signal.7.html) - [man7 – capabilities(7)](https://man7.org/linux/man-pages/man7/capabilities.7.html) # 8.5 macOS – Prozesse, Dienste, Protokolle, Ressourcen und Speicher analysieren Diese Seite beschreibt die systematische Fehleranalyse auf macOS. Im Mittelpunkt stehen Prozesse, `launchd`-Dienste, Protokolle, CPU, Arbeitsspeicher, APFS-Datenträger, Dateiberechtigungen, Datenschutzfreigaben und Startprobleme. --- **8.5.1 Ziel und Abgrenzung** Nach dieser Seite soll beurteilt werden können: - ob eine Störung nur eine App, einen Benutzer oder das gesamte System betrifft; - ob ein Prozess ausgeführt wird, blockiert ist, abstürzt oder ungewöhnlich viele Ressourcen verbraucht; - ob ein Dienst im richtigen `launchd`-Bereich registriert ist; - ob Protokolle, Absturzberichte oder Systemdiagnosen eine Ursache belegen; - ob CPU, Arbeitsspeicher, Datenträger oder Dateisystem den Engpass bilden; - ob Unix-Berechtigungen, ACLs oder macOS-Datenschutzfreigaben den Zugriff verhindern; - ob Anmeldeobjekte, Hintergrunddienste oder Systemerweiterungen beteiligt sind; - ob ein Software-, Konfigurations- oder Hardwareproblem vorliegt. Eine laufende App, ein vorhandener Prozess oder ein registrierter Dienst beweist noch nicht, dass die ursprüngliche Benutzerfunktion funktioniert. --- **8.5.2 Besonderheiten der macOS-Systemarchitektur** Für die Fehleranalyse sind insbesondere folgende Komponenten wichtig: | Komponente | Aufgabe | Bedeutung für die Diagnose | |---|---|---| | Kernel | Verwaltet Hardware, Speicher, Prozesse und Systemressourcen | Kernel-Panics, Treiber- oder Hardwareprobleme können das gesamte System betreffen | | `launchd` | Startet und verwaltet Dienste, Agents und XPC-Dienste | Ein Dienst kann dauerhaft oder nur bei Bedarf gestartet werden | | LaunchDaemon | Systemweiter Hintergrunddienst | Wird gewöhnlich im `system`-Bereich verwaltet | | LaunchAgent | Benutzerbezogener Hintergrunddienst | Wird gewöhnlich im `gui/`-Bereich verwaltet | | Unified Logging | Zentrales Protokollsystem von macOS | Wird über „Konsole“ oder den Befehl `log` ausgewertet | | APFS | Standarddateisystem moderner macOS-Systeme | Container, Volumes, Snapshots und gemeinsam genutzter Speicher müssen unterschieden werden | | TCC | Datenschutz- und Zugriffssteuerung | Kann Zugriffe trotz korrekter Unix-Berechtigungen verhindern | | Systemerweiterungen | Erweiterungen für Netzwerk, Sicherheit, Treiber und andere Funktionen | Fehlerhafte Erweiterungen können systemweite Auswirkungen verursachen | | Aktivitätsanzeige | Grafische Prozess- und Ressourcenanalyse | Zeigt CPU, Speicher, Energie, Datenträger und Netzwerkaktivität | `launchd`-Dienste können bedarfsgesteuert arbeiten. Ein registrierter Dienst ohne aktuelle PID ist deshalb nicht automatisch fehlerhaft. --- **8.5.3 Typische Symptome** - Eine App startet nicht oder beendet sich sofort. - Eine App reagiert nicht mehr. - Ein Hintergrunddienst funktioniert nach der Anmeldung oder einem Neustart nicht. - Das System ist dauerhaft oder zeitweise langsam. - Der Lüfter läuft stark oder der Energieverbrauch ist ungewöhnlich hoch. - Der Speicherdruck steigt auf Gelb oder Rot. - Der verfügbare Datenträgerspeicher nimmt unerwartet ab. - Ein Prozess verursacht dauerhaft hohe CPU- oder Datenträgeraktivität. - Eine App kann bestimmte Dateien, Ordner, Geräte oder Netzwerkziele nicht verwenden. - Eine Funktion arbeitet nur unter einem bestimmten Benutzerkonto. - Der Fehler verschwindet im sicheren Modus. - Der Mac startet wiederholt neu oder meldet einen Kernel-Panic. - Ein externes Speichermedium wird nicht oder nur schreibgeschützt eingebunden. - Eine App funktioniert nach einem macOS- oder App-Update nicht mehr. --- **8.5.4 Kennzeichnung der Befehle** | Kennzeichnung | Bedeutung | |---|---| | `[LESEND]` | Liest Informationen aus und verändert normalerweise keine Konfiguration | | `[LIVE]` | Beobachtet laufende Ereignisse bis zum Abbruch | | `[PRIVILEGIERT]` | Benötigt möglicherweise `sudo` oder Administratorrechte | | `[BELASTEND]` | Kann CPU, Datenträger oder Protokollsystem zusätzlich belasten | | `[VERÄNDERND]` | Verändert einen Prozess, Dienst oder eine Systemeinstellung | | `[NEUSTART]` | Unterbricht laufende Sitzungen oder Funktionen | Vor verändernden Maßnahmen müssen Befund, Konfiguration und Rückweg dokumentiert werden. --- **8.5.5 Sicherheits- und Betriebswarnungen** - Flüchtige Informationen müssen vor dem Beenden einer App oder vor einem Neustart gesichert werden. - `kill -9`, erzwungenes Ausschalten und erzwungenes Aushängen eines Datenträgers können zu Datenverlust führen. - Apple-Systemdienste dürfen nicht versuchsweise deaktiviert oder aus `/System/Library` entfernt werden. - SIP, Gatekeeper, FileVault und Datenschutzfunktionen dürfen nicht als dauerhafte Fehlerlösung deaktiviert werden. - Protokolle, Systemberichte und `sysdiagnose`-Archive können Benutzernamen, Pfade, Seriennummern, Netzwerkdaten und andere vertrauliche Informationen enthalten. - `diskutil` besitzt sowohl lesende als auch destruktive Unterbefehle. Datenträgerkennung und Unterbefehl müssen vor der Ausführung kontrolliert werden. - Eine Dateisystemreparatur ersetzt kein Backup. - Das manuelle Löschen unbekannter Dateien aus `/Library`, `/System`, `/private` oder APFS-Systembereichen ist keine sichere Standardmaßnahme. - Bei verwalteten Macs können MDM-Richtlinien Einstellungen absichtlich erzwingen. - Befehlsoptionen können sich zwischen macOS-Versionen ändern. Maßgeblich ist die lokale Manpage der tatsächlich installierten Version. Beispiel: ```bash man launchctl man log man diskutil ``` --- **8.5.6 Benötigte Informationen** Vor der Diagnose sollten mindestens folgende Angaben erfasst werden: - genaue macOS-Version und Buildnummer; - Apple-Chip oder Intel-Prozessor; - Zeitpunkt und Häufigkeit der Störung; - betroffene App, Funktion, Benutzer und Geräte; - letzte Updates, Installationen oder Konfigurationsänderungen; - angemeldeter Benutzer und vorhandene Administratorrechte; - MDM- oder Unternehmensverwaltung; - angeschlossene Datenträger, Docks und USB-Geräte; - freier Speicherplatz; - genaue Fehlermeldung; - Verhalten nach Ab- und Anmeldung oder Neustart; - Verhalten unter einem anderen Benutzerkonto; - Verhalten im sicheren Modus; - vorhandene Absturz-, Spin- oder Panic-Berichte. --- **8.5.7 Systemzustand und Basisdaten sichern** Die folgenden Befehle sind lesend. Systeminformationen können Seriennummern und andere vertrauliche Daten enthalten und müssen vor einer Weitergabe geprüft werden. ```bash date sw_vers uname -a uname -m uptime who last reboot | head -n 10 system_profiler SPHardwareDataType SPSoftwareDataType ``` Wichtige Fragen: - Stimmt die Systemzeit? - Welche macOS-Version und welcher Build sind installiert? - Wurde das System kurz vor der Störung neu gestartet? - Betrifft das Problem einen Mac mit Apple-Chip oder einen Intel-Mac? - Ist die problematische App für die vorhandene Prozessorarchitektur geeignet? - Trat der Fehler unmittelbar nach einem Update auf? Die Installationshistorie kann ergänzend geprüft werden: ```bash system_profiler SPInstallHistoryDataType ``` Die zeitliche Übereinstimmung zwischen einer Installation und dem Beginn der Störung ist ein Hinweis, aber noch kein Ursachenbeweis. --- **8.5.8 Ungefährliche Schnellprüfung** ```bash df -h df -ih diskutil list vm_stat sysctl vm.swapusage ps -axo pid,ppid,user,state,%cpu,%mem,etime,command | head -n 30 log show --last 15m --style compact \ --predicate 'messageType == error OR messageType == fault' ``` Zusätzlich in der grafischen Oberfläche prüfen: 1. „Aktivitätsanzeige“ öffnen. 2. CPU, Speicher, Energie, Festplatte und Netzwerk kontrollieren. 3. Nach ungewöhnlich belastenden oder nicht reagierenden Prozessen suchen. 4. „Konsole“ öffnen und den Fehlerzeitraum untersuchen. 5. Unter „Systemeinstellungen → Allgemein → Speicher“ den verfügbaren Speicher prüfen. 6. Unter „Systemeinstellungen → Allgemein → Anmeldeobjekte & Erweiterungen“ auffällige Hintergrundobjekte erfassen. 7. Unter „Datenschutz & Sicherheit“ prüfen, ob die betroffene App die tatsächlich benötigten Freigaben besitzt. Noch keine Prozesse beenden, Dienste neu starten oder Dateien löschen. --- **8.5.9 Prozesse systematisch untersuchen** Prozesse können über die Aktivitätsanzeige oder das Terminal untersucht werden. Alle Prozesse anzeigen: ```bash ps -axo pid,ppid,user,state,%cpu,%mem,etime,command ``` Mehrere Messungen der aktiven Prozesse durchführen: ```bash top -l 3 -s 2 -o cpu \ -stats pid,command,cpu,mem,threads,state,time ``` Nach einem Prozess suchen: ```bash pgrep -fl "BeispielApp" ``` Einen bestimmten Prozess untersuchen, wobei `1234` durch die tatsächliche PID ersetzt wird: ```bash ps -p 1234 \ -o pid,ppid,user,state,%cpu,%mem,etime,command ``` Geöffnete Dateien und Verbindungen des Prozesses anzeigen: ```bash lsof -nP -p 1234 | head -n 100 ``` Einen Prozess für zehn Sekunden analysieren: ```bash sample 1234 10 -file "$HOME/Desktop/BeispielApp-sample.txt" ``` Alternativ kann in der Aktivitätsanzeige ein Prozess ausgewählt und über „Mehr → Prozess analysieren“ untersucht werden. Zu prüfen sind: - Elternprozess; - ausführender Benutzer; - Laufzeit; - CPU- und Speicherverbrauch; - geöffnete Dateien; - Netzwerkverbindungen; - wiederholte Neustarts; - nicht reagierende Threads; - zugehörige Protokoll- und Absturzmeldungen. Ein hoher Messwert während eines kurzen Startvorgangs kann normal sein. Aussagekräftiger ist eine wiederholte oder dauerhaft hohe Auslastung im Fehlerzeitraum. --- **8.5.10 Prozesse kontrolliert beenden** Zuerst sollte die App regulär beendet werden. Reagiert sie nicht, kann die Aktivitätsanzeige verwendet werden. Ein Prozess kann im Terminal zunächst mit `SIGTERM` zum geordneten Beenden aufgefordert werden: ```bash kill -TERM 1234 ``` Kennzeichnung: `[VERÄNDERND]` Risiken: - nicht gespeicherte Daten können verloren gehen; - verbundene Anwendungen können ihre Verbindung verlieren; - ein von `launchd` verwalteter Prozess kann automatisch erneut gestartet werden. `SIGKILL` beziehungsweise `kill -9` beendet einen Prozess ohne geordnetes Aufräumen und ist nur die letzte Eskalationsstufe: ```bash kill -KILL 1234 ``` Kennzeichnung: `[VERÄNDERND] [HOHES RISIKO]` Vorher müssen PID, Prozessname, Benutzer und Auswirkungen eindeutig geprüft werden. --- **8.5.11 Dienste und Agents mit launchd analysieren** Systemweite Dienste und benutzerbezogene Agents liegen in unterschiedlichen `launchd`-Bereichen. | Bereich | Typische Verwendung | |---|---| | `system` | Systemweite Daemons | | `user/` | Benutzerbereich ohne zwingenden Bezug zur grafischen Anmeldung | | `gui/` | Grafische Anmeldesitzung eines Benutzers | Systembereich anzeigen: ```bash launchctl print system ``` Bereich des aktuell angemeldeten Benutzers anzeigen: ```bash launchctl print gui/$(id -u) ``` Einen konkreten systemweiten Dienst prüfen: ```bash launchctl print system/com.example.service ``` Einen konkreten Benutzer-Agent prüfen: ```bash launchctl print gui/$(id -u)/com.example.agent ``` Deaktivierungszustände anzeigen: ```bash launchctl print-disabled system launchctl print-disabled gui/$(id -u) ``` Typische Speicherorte: ```text ~/Library/LaunchAgents /Library/LaunchAgents /Library/LaunchDaemons /System/Library/LaunchAgents /System/Library/LaunchDaemons ``` Eine Drittanbieter-Property-List syntaktisch prüfen: ```bash plutil -lint "/Library/LaunchDaemons/com.example.service.plist" ``` Zu untersuchen sind: - korrekter `launchd`-Bereich; - exaktes Dienstlabel; - Programmpfad und Argumente; - ausführender Benutzer; - letzte Exit-Codes; - Startbedingungen; - Standardausgabe und Fehlerausgabe; - Dateiberechtigungen der Property-List; - Existenz und Ausführbarkeit des hinterlegten Programms; - Abhängigkeiten und benötigte Dateien. Ein nicht laufender On-Demand-Dienst kann sich im Normalzustand befinden. Entscheidend ist, ob der vorgesehene Auslöser den Dienst startet und die Benutzerfunktion anschließend funktioniert. --- **8.5.12 Dienst kontrolliert neu starten** Ein eindeutig identifizierter Drittanbieterdienst kann zu Diagnosezwecken neu gestartet werden. Systemweiter Dienst: ```bash sudo launchctl kickstart -k system/com.example.service ``` Benutzer-Agent: ```bash launchctl kickstart -k gui/$(id -u)/com.example.agent ``` Kennzeichnung: `[VERÄNDERND]` Vorher dokumentieren: - Dienstlabel; - aktueller Status; - PID; - offene Verbindungen; - aktuelle Protokollmeldungen; - mögliche Benutzerunterbrechung; - erwartetes Ergebnis. Ein erfolgreicher Neustart beweist nur, dass der Dienst erneut gestartet werden konnte. Danach muss die ursprüngliche Funktion getestet werden. --- **8.5.13 Unified Logging und Konsole** Die App „Konsole“ und der Befehl `log` greifen auf das zentrale macOS-Protokollsystem zu. Fehler und Fault-Meldungen der letzten 30 Minuten: ```bash log show --last 30m --style compact \ --predicate 'messageType == error OR messageType == fault' ``` Meldungen eines bestimmten Prozesses: ```bash log show --last 30m --style compact \ --predicate 'process == "BeispielApp"' ``` Bestimmten Zeitraum untersuchen: ```bash log show \ --start "2026-08-02 13:00:00" \ --end "2026-08-02 13:30:00" \ --style compact ``` Protokollmeldungen live verfolgen: ```bash log stream --style compact --level info \ --predicate 'process == "BeispielApp"' ``` Kennzeichnung: `[LIVE]` Die Live-Ausgabe wird mit `Ctrl-C` beendet. Ein Protokollarchiv der letzten 30 Minuten erstellen: ```bash sudo log collect --last 30m \ --output "$HOME/Desktop/macOS-30m.logarchive" ``` Kennzeichnung: `[PRIVILEGIERT] [DATENSCHUTZRELEVANT]` Bei der Auswertung beachten: - Fehlerzeitpunkt möglichst genau eingrenzen; - Prozess, Subsystem und Kategorie berücksichtigen; - erste Fehlermeldung einer Fehlerkette suchen; - wiederholte Folgefehler nicht automatisch als Ursache interpretieren; - Meldungen vor und nach dem Fehler vergleichen; - normale Warnungen von reproduzierbaren Fehlern unterscheiden; - fehlende Protokollmeldungen sind kein Beweis für Fehlerfreiheit; - Info- und Debug-Meldungen werden nicht immer dauerhaft gespeichert. --- **8.5.14 Absturz-, Spin- und Diagnoseberichte** Die App „Konsole“ zeigt unter anderem: - Absturzberichte mit der Erweiterung `.ips`; - Spin-Berichte nicht reagierender Prozesse; - Protokollberichte; - Diagnoseberichte; - ältere Einträge aus `system.log`; - System- und Benutzerberichte. Benutzerbezogene Diagnoseberichte können zusätzlich in folgendem Verzeichnis liegen: ```bash ls -lt "$HOME/Library/Logs/DiagnosticReports" | head -n 20 ``` Systemweite Diagnoseberichte: ```bash sudo ls -lt "/Library/Logs/DiagnosticReports" | head -n 20 ``` Wichtige Inhalte eines Absturzberichts: - betroffener Prozess und Version; - Zeitpunkt; - Prozessorarchitektur; - Exception Type; - Termination Reason; - auslösender Thread; - verwendete Bibliotheken; - wiederkehrende Funktionsnamen oder Module; - Übereinstimmung mit dem tatsächlichen Fehlerzeitpunkt. Ein einzelner Absturzbericht beweist nicht automatisch einen dauerhaften Defekt. Entscheidend sind Reproduzierbarkeit, Häufigkeit und Übereinstimmung mit der beobachteten Störung. --- **8.5.15 CPU-Auslastung analysieren** Grafisch: 1. Aktivitätsanzeige öffnen. 2. Bereich „CPU“ auswählen. 3. Nach `% CPU` sortieren. 4. Messung während der Störung beobachten. 5. Prozess analysieren oder Spindump erstellen. Im Terminal: ```bash top -l 5 -s 2 -o cpu \ -stats pid,command,cpu,mem,threads,state,time ``` Mögliche Befunde: | Befund | Mögliche Bedeutung | |---|---| | Ein Prozess dauerhaft stark ausgelastet | Endlosschleife, fehlerhafte Verarbeitung oder außergewöhnliche Arbeitslast | | Viele Prozesse gleichzeitig ausgelastet | Systemweite Last, Indizierung, Update oder konkurrierende Aufgaben | | Hohe CPU mit normaler Benutzerfunktion | Möglicherweise erwartete Verarbeitung | | Niedrige CPU bei langsamer App | Warten auf Datenträger, Netzwerk, Sperre oder externen Dienst | | App reagiert nicht und CPU ist nahezu null | Blockierter Thread oder Warten auf eine Ressource | | Wiederkehrende kurze Lastspitzen | Regelmäßiger Agent, Synchronisation oder geplanter Hintergrundprozess | Die CPU-Auslastung muss immer zusammen mit Prozesszustand, Benutzerfunktion, Protokollen und I/O-Aktivität bewertet werden. --- **8.5.16 Arbeitsspeicher analysieren** Apple empfiehlt, den Speicherdruck und nicht nur den freien Arbeitsspeicher zu bewerten. Grafisch: 1. Aktivitätsanzeige öffnen. 2. Bereich „Speicher“ auswählen. 3. Speicherdruck beobachten. 4. Speicher, komprimierten Speicher und Swap-Nutzung prüfen. 5. Nach Speicherverbrauch sortieren. Terminalprüfung: ```bash vm_stat sysctl vm.swapusage ``` Mehrere Messungen im Abstand von zwei Sekunden: ```bash vm_stat -c 5 2 ``` Wichtige Werte: - freie und aktive Speicherseiten; - komprimierter Speicher; - Page-ins und Page-outs; - Swap-ins und Swap-outs; - Entwicklung der Werte während der Störung. Interpretation: | Befund | Bewertung | |---|---| | Speicherdruck Grün | Speicherverwaltung arbeitet derzeit ausreichend | | Speicherdruck Gelb | Ressourcen werden knapp; Verlauf und verursachende Prozesse prüfen | | Speicherdruck Rot | Akuter Speicherengpass wahrscheinlich | | Hohe Komprimierung ohne Störung | Kann normal sein | | Wachsende Swap-Nutzung und Leistungseinbruch | Speicherengpass oder übermäßiger Prozessverbrauch möglich | | Einzelner Prozess wächst kontinuierlich | Mögliches Speicherleck | | Hohe historische Swap-Zahl ohne aktuelle Änderung | Kein ausreichender Ursachenbeweis | Ein einmaliger Gesamtwert ist weniger aussagekräftig als die Veränderung während des reproduzierten Fehlers. --- **8.5.17 Datenträger, APFS und Speicherplatz analysieren** Dateisystembelegung: ```bash df -h df -h /System/Volumes/Data df -ih ``` Datenträgerstruktur: ```bash diskutil list diskutil info / diskutil apfs list ``` Lokale Time-Machine-Snapshots anzeigen: ```bash tmutil listlocalsnapshots / ``` Speicherbelegung im Benutzerordner untersuchen: ```bash du -x -h -d 1 "$HOME" 2>/dev/null | sort -h ``` Datenträgeraktivität beobachten: ```bash iostat -w 2 -c 5 ``` Dateisystem oder Datenträger-I/O für 15 Sekunden verfolgen: ```bash sudo fs_usage -w -f diskio -t 15 ``` Kennzeichnung: `[PRIVILEGIERT] [LIVE] [BELASTEND] [DATENSCHUTZRELEVANT]` Ein Volume prüfen: ```bash diskutil verifyVolume / ``` Kennzeichnung: `[PRÜFEND] [POTENZIELL BELASTEND]` Bei APFS beachten: - mehrere Volumes können Speicher innerhalb eines Containers gemeinsam nutzen; - lokale Snapshots können Speicher belegen; - löschbarer Speicher wird nicht in jeder Anzeige identisch dargestellt; - System- und Datenvolume bilden gemeinsam das startfähige macOS-System; - ein voller Datenträger kann Updates, Protokollierung, Swap, App-Starts und Datenbanken beeinträchtigen; - freie Inodes und freier Speicherplatz sind unterschiedliche Größen; - externe Datenträger können durch Kabel, Stromversorgung, Adapter oder Dateisystemfehler ausfallen. Für Reparaturen sollte das Festplattendienstprogramm verwendet werden. Apple empfiehlt, „Erste Hilfe“ zuerst für die Volumes, anschließend für die Container und zuletzt für das physische Speichergerät auszuführen. Bei Problemen mit dem Startvolume kann die macOS-Wiederherstellung erforderlich sein. --- **8.5.18 Dateiberechtigungen, ACLs und erweiterte Attribute** Identität des aktuellen Benutzers prüfen: ```bash id groups ``` Datei oder Ordner untersuchen: ```bash ls -ldeO@ "/Pfad/zum/Ordner" stat -x "/Pfad/zum/Ordner" ``` Dabei werden unter anderem sichtbar: - Eigentümer; - Gruppe; - klassische Unix-Berechtigungen; - ACL-Einträge; - Dateiflags; - erweiterte Attribute. Zu prüfen ist der gesamte benötigte Pfad. Schreibrechte auf eine Datei reichen beispielsweise nicht aus, wenn ein übergeordneter Ordner nicht betreten oder verändert werden darf. Berechtigungen dürfen nicht pauschal mit `chmod -R 777` geöffnet werden. Dadurch entstehen Sicherheitsprobleme, und bestehende ACLs oder Eigentümerfehler werden nicht zuverlässig behoben. --- **8.5.19 Datenschutzfreigaben und TCC** macOS schützt bestimmte Daten und Geräte zusätzlich zu den Unix-Berechtigungen. Mögliche Freigaben sind unter anderem: - Dateien und Ordner; - Festplattenvollzugriff; - Kamera; - Mikrofon; - Bildschirm- und Systemaudioaufnahme; - Bedienungshilfen; - Automation; - Eingabeüberwachung; - Bluetooth; - lokales Netzwerk. Ein Zugriff kann deshalb fehlschlagen, obwohl `ls -l` korrekte Unix-Berechtigungen anzeigt. Prüfung: 1. „Systemeinstellungen → Datenschutz & Sicherheit“ öffnen. 2. Nur die für die App tatsächlich benötigte Kategorie auswählen. 3. Prüfen, ob die richtige App oder das richtige Terminalprogramm eingetragen ist. 4. Nach einer Änderung die betroffene App gegebenenfalls vollständig beenden und neu starten. 5. Funktion erneut testen. Festplattenvollzugriff sollte nicht pauschal vergeben werden. Die kleinste benötigte Freigabe ist vorzuziehen. --- **8.5.20 App-Signatur, Gatekeeper und Quarantäne prüfen** Eine App kann wegen einer beschädigten Signatur, einer nicht vertrauenswürdigen Herkunft oder einer unvollständigen Installation nicht starten. Signatur einer Beispiel-App prüfen: ```bash codesign --verify --deep --strict --verbose=2 \ "/Applications/Beispiel.app" ``` Gatekeeper-Bewertung prüfen: ```bash spctl --assess --type execute --verbose=4 \ "/Applications/Beispiel.app" ``` Erweiterte Attribute anzeigen: ```bash xattr -l "/Applications/Beispiel.app" ``` Diese Befehle sind lesend. Ein negatives Ergebnis sollte durch eine unveränderte, signierte Installationsdatei des Herstellers behoben werden. Das Entfernen von Quarantäneattributen, das Ad-hoc-Signieren oder das Deaktivieren von Gatekeeper ist keine allgemeine Fehlerlösung. --- **8.5.21 Anmeldeobjekte, Hintergrunddienste und Erweiterungen** Grafische Prüfung: 1. „Systemeinstellungen → Allgemein → Anmeldeobjekte & Erweiterungen“ öffnen. 2. „Bei der Anmeldung öffnen“ erfassen. 3. „Im Hintergrund erlauben“ erfassen. 4. installierte Erweiterungen prüfen. 5. unbekannte oder zeitlich zur Störung passende Drittanbieterkomponenten dokumentieren. Systemerweiterungen anzeigen: ```bash systemextensionsctl list ``` MDM-Registrierungsstatus prüfen: ```bash profiles status -type enrollment ``` Sicherheitszustände können ergänzend gelesen werden: ```bash fdesetup status csrutil status spctl --status ``` Diese Zustände dürfen nicht ohne begründete Anforderung verändert werden. Wenn Anmeldeobjekte als Ursache vermutet werden: 1. vollständige Liste sichern; 2. verdächtige Drittanbieterobjekte kontrolliert deaktivieren; 3. ab- und wieder anmelden oder neu starten; 4. ursprüngliche Funktion testen; 5. Objekte einzeln wieder aktivieren; 6. den tatsächlich verursachenden Eintrag bestätigen. --- **8.5.22 Netzwerkabhängigkeiten kurz prüfen** Wenn eine App langsam ist oder einen Dienst nicht erreicht, muss zwischen lokalem Prozessproblem und externer Abhängigkeit unterschieden werden. ```bash scutil --dns route -n get default netstat -rn lsof -nP -iTCP -sTCP:LISTEN ``` Fragen: - Ist die lokale App blockiert oder wartet sie auf DNS? - Ist das Ziel per IP und Name erreichbar? - Ist ein erforderlicher lokaler Listener vorhanden? - Verhindern Proxy, VPN, Firewall oder lokaler Netzwerkzugriff die Verbindung? - Wartet die App auf einen Server, eine API, eine Freigabe oder einen Cloud-Dienst? Die ausführliche Netzwerkdiagnose erfolgt nach den Abläufen aus Kapitel 3. --- **8.5.23 Fehler auf Benutzer, System oder Hardware eingrenzen** | Test | Erkenntnis | |---|---| | Nur eine App betroffen | App-Konfiguration, App-Daten oder Abhängigkeit wahrscheinlich | | Mehrere Apps eines Benutzers betroffen | Benutzerprofil, TCC, LaunchAgent oder Anmeldeobjekt möglich | | Alle Benutzer betroffen | Systemdienst, systemweite Konfiguration, Datenträger oder Hardware möglich | | Fehler nur mit einem externen Gerät | Gerät, Kabel, Adapter, Stromversorgung oder Treiber untersuchen | | Fehler verschwindet nach App-Neustart | Prozesszustand wahrscheinlich, Ursache aber noch nicht bewiesen | | Fehler verschwindet nach Abmeldung | Benutzerbezogener Agent oder Sitzungszustand möglich | | Fehler verschwindet im sicheren Modus | Drittanbietererweiterung, Anmeldeobjekt oder zusätzlich geladene Komponente möglich | | Fehler bleibt im sicheren Modus bestehen | Grundsystem, Benutzerdateien, Hardware oder weiterhin aktive Abhängigkeit untersuchen | | Fehler tritt auch in der Wiederherstellung auf | Hardware oder Datenträger wird wahrscheinlicher | | Apple Diagnose meldet Referenzcode | Hardwarebefund dokumentieren und nach Apple-Vorgabe weiterbearbeiten | --- **8.5.24 Sicherer Modus** Der sichere Modus hilft zu prüfen, ob beim normalen Start zusätzlich geladene Software beteiligt ist. Mac mit Apple-Chip: 1. Mac vollständig ausschalten. 2. Ein-/Ausschalter gedrückt halten, bis die Startoptionen erscheinen. 3. Startvolume auswählen. 4. Umschalttaste gedrückt halten. 5. „Im gesicherten Modus fortfahren“ auswählen. Intel-Mac: 1. Mac einschalten oder neu starten. 2. Sofort die Umschalttaste gedrückt halten. 3. Taste loslassen, wenn das Anmeldefenster erscheint. Der sichere Modus ist ein Kreuztest. Wenn der Fehler dort nicht auftritt, ist damit noch keine einzelne Ursache bewiesen. Anschließend müssen Anmeldeobjekte, Agents, Erweiterungen und Drittanbietersoftware einzeln geprüft werden. Ein normaler Neustart beendet den sicheren Modus. --- **8.5.25 Apple Diagnose und Wiederherstellung** Apple Diagnose prüft Hardwarekomponenten. Mac mit Apple-Chip: 1. Mac ausschalten. 2. Nicht benötigte externe Geräte trennen. 3. Ein-/Ausschalter gedrückt halten, bis die Startoptionen erscheinen. 4. Befehlstaste und `D` gedrückt halten, bis der Mac neu startet. 5. Diagnoseanweisungen befolgen. 6. angezeigte Referenzcodes dokumentieren. Intel-Mac: 1. Mac einschalten. 2. Sofort `D` gedrückt halten. 3. Falls erforderlich, beim Start `Option-D` verwenden. 4. Diagnoseanweisungen befolgen. 5. Referenzcodes dokumentieren. Die macOS-Wiederherstellung wird benötigt, wenn beispielsweise das Startvolume nicht im laufenden System repariert werden kann. - Apple-Chip: Ein-/Ausschalter bis zu den Startoptionen gedrückt halten und „Optionen“ auswählen. - Intel-Mac: beim Einschalten `Command-R` gedrückt halten. Eine erfolgreiche Apple Diagnose schließt nicht jede denkbare Hardwarestörung aus. Sporadische Fehler, Kabelprobleme oder externe Geräte müssen weiterhin durch Kreuztests untersucht werden. --- **8.5.26 Systematischer Diagnoseablauf** 1. **Störung aufnehmen** Benutzer, App, Funktion, Zeitpunkt, Häufigkeit und genaue Meldung erfassen. 2. **Umfang bestimmen** Eine App, ein Benutzer, alle Benutzer oder der gesamte Mac? 3. **Basiszustand sichern** macOS-Version, Build, Architektur, Laufzeit, Installationshistorie und Speicherplatz dokumentieren. 4. **Fehler reproduzieren** Zeitpunkt notieren und nur den erforderlichen Ablauf ausführen. 5. **Prozess prüfen** Existenz, Benutzer, Elternprozess, Zustand, CPU, Speicher und offene Dateien untersuchen. 6. **Dienstzuordnung prüfen** Richtiges `launchd`-Label und richtigen Bereich bestimmen. 7. **Protokolle korrelieren** Meldungen unmittelbar vor, während und nach dem Fehler auswerten. 8. **Ressourcen untersuchen** CPU, Speicherdruck, Swap, Datenträgerbelegung und I/O messen. 9. **Zugriff prüfen** Unix-Berechtigungen, ACLs, TCC-Freigaben und App-Signatur unterscheiden. 10. **Abhängigkeiten prüfen** Netzwerk, DNS, Server, API, Freigabe, Cloud-Dienst oder externes Gerät kontrollieren. 11. **Fehlerdomäne isolieren** Anderer Benutzer, sicherer Modus, getrennte Peripherie oder Wiederherstellung verwenden. 12. **Hypothese formulieren** Erwartetes Prüfergebnis und Gegenbeweis festlegen. 13. **Eine kontrollierte Maßnahme durchführen** Risiko, Rückweg und Messkriterium dokumentieren. 14. **Ursprüngliche Funktion verifizieren** Nicht nur den Prozessstatus, sondern den realen Benutzerablauf testen. 15. **Nachkontrolle durchführen** Protokolle und Ressourcen erneut prüfen sowie Rückfall ausschließen. --- **8.5.27 Befundmatrix** | Befund | Mögliche Erklärung | Nächster Nachweis | |---|---|---| | App-Prozess fehlt | App wurde nicht gestartet oder beendet sich sofort | Absturzbericht und zeitlich passende Logs prüfen | | Prozess läuft, App reagiert nicht | Thread blockiert oder wartet auf Ressource | Prozessanalyse oder Spindump erstellen | | Dienstlabel im `system`-Bereich nicht gefunden | Falsches Label, falscher Bereich oder Dienst nicht geladen | Property-List und tatsächliches Label prüfen | | Agent fehlt im `gui/`-Bereich | Falscher Benutzer oder keine grafische Sitzung | UID und Anmeldesitzung prüfen | | Dienst besitzt keine PID | On-Demand-Zustand oder Startfehler | Auslöser betätigen und Logs beobachten | | Hohe CPU bei einem Prozess | Schleife, hohe Last oder fehlerhafte Verarbeitung | Mehrfach messen und Prozess analysieren | | Niedrige CPU, App trotzdem langsam | Warten auf I/O, Netzwerk oder Sperre | `fs_usage`, Netzwerk und Prozessanalyse | | Speicherdruck Gelb oder Rot | Speicherengpass | Speicherverbrauch und zeitliche Entwicklung prüfen | | Swap wächst während der Störung | Arbeitsspeicher reicht für aktuelle Last nicht aus | verursachende Prozesse bestimmen | | Startvolume fast voll | Apps, Updates, Logs und Swap beeinträchtigt | große Verzeichnisse und Snapshots prüfen | | Viele lokale Snapshots | Speicher wird durch Snapshots mitbelegt | Time-Machine-Zustand und Richtlinie prüfen | | Unix-Rechte korrekt, Zugriff trotzdem verweigert | TCC- oder Sandbox-Einschränkung | Datenschutzfreigabe der richtigen App prüfen | | Signaturprüfung schlägt fehl | App beschädigt oder verändert | Originaldatei des Herstellers vergleichen | | Nur ein Benutzer betroffen | Benutzerprofil, LaunchAgent oder TCC | anderes Benutzerkonto als Kreuztest | | Fehler verschwindet im sicheren Modus | zusätzliche Software beteiligt | Drittanbieterkomponenten einzeln prüfen | | Kernel-Panics treten wiederholt auf | Treiber-, Erweiterungs- oder Hardwareproblem | Panic-Berichte, Peripherietest und Apple Diagnose | | Prozess und Port sind vorhanden, Funktion scheitert | Abhängigkeit oder Anwendungsebene fehlerhaft | vollständigen Benutzerpfad Ende zu Ende prüfen | --- **8.5.28 Mögliche Ursachen und erforderliche Nachweise** | Mögliche Ursache | Erforderlicher Nachweis | |---|---| | Fehlerhafte App-Konfiguration | Fehler ist mit gesicherter Standardkonfiguration reproduzierbar beziehungsweise verschwindet kontrolliert ohne diese Konfiguration | | Beschädigte App-Installation | Signatur- oder Integritätsprüfung schlägt fehl und eine unveränderte Herstellerinstallation funktioniert | | Fehlerhafter LaunchAgent | Fehler tritt nur im zugehörigen Benutzerkontext auf und verschwindet nach kontrollierter Deaktivierung | | Fehlerhafter LaunchDaemon | Systemweiter Fehler korreliert mit Dienststatus, Logs und reproduzierbarem Neustartverhalten | | CPU-Engpass | CPU ist während der Störung dauerhaft ausgelastet und der verursachende Prozess ist bestimmt | | Speicherengpass | Speicherdruck und Swap wachsen während der reproduzierten Störung | | Voller Datenträger | Freier Speicher ist kritisch niedrig und die Funktion arbeitet nach kontrollierter Freigabe wieder | | APFS- oder Dateisystemfehler | `diskutil`, Erste Hilfe oder Systemprotokolle melden konkrete Fehler | | Berechtigungsfehler | Zugriff scheitert mit konkretem Berechtigungsbefund und funktioniert nach minimaler Korrektur | | TCC-Verweigerung | Benötigte Datenschutzfreigabe fehlt und die Funktion arbeitet nach gezielter Freigabe | | Netzwerkabhängigkeit | Lokaler Prozess arbeitet, aber DNS, Verbindung oder Zielsystem scheitert reproduzierbar | | Drittanbietererweiterung | Fehler verschwindet im sicheren Modus und kehrt mit der einzeln aktivierten Erweiterung zurück | | Hardwarefehler | Apple Diagnose, wiederkehrende Panic-Berichte oder unabhängige Kreuztests belegen den Fehler | --- **8.5.29 Kontrollierte Maßnahmen, Risiko und Rückweg** | Maßnahme | Risiko | Rückweg | |---|---|---| | App regulär beenden und neu öffnen | Nicht gespeicherte Daten | App erneut starten und gesicherte Daten öffnen | | Prozess mit `SIGTERM` beenden | Funktionsunterbrechung | App oder Dienst kontrolliert neu starten | | Drittanbieterdienst mit `kickstart` neu starten | Kurzzeitiger Dienstausfall | dokumentierten Ausgangszustand und Konfiguration wiederherstellen | | Anmeldeobjekt vorübergehend deaktivieren | Funktion steht nach Anmeldung nicht bereit | Eintrag anhand der gesicherten Liste wieder aktivieren | | TCC-Freigabe gezielt erteilen | zusätzlicher Datenzugriff | Freigabe nach Test wieder entziehen | | Drittanbieter-App aktualisieren | neue Version kann Konfiguration verändern | Installationsdatei und Konfiguration der vorherigen Version sichern | | App aus Originalquelle neu installieren | lokale App-Bestandteile werden ersetzt | Konfiguration und Benutzerdaten vorher sichern | | Nicht benötigte Benutzerdaten verschieben | Datei steht am alten Ort nicht mehr bereit | Datei aus dem Sicherungsort zurückverschieben | | Sicherer Modus | eingeschränkte Funktionen | normal neu starten | | Erste Hilfe ausführen | zusätzliche Datenträgerbelastung | aktuelles Backup bereithalten; bei Fehler abbrechen und Befund sichern | | Peripheriegerät trennen | zugehörige Funktion steht nicht bereit | Gerät nach Test wieder anschließen | Pro Maßnahme darf möglichst nur eine relevante Variable verändert werden. --- **8.5.30 Verifikation** Nach einer Maßnahme müssen mindestens folgende Prüfungen erfolgen: - ursprünglicher Benutzerablauf funktioniert vollständig; - App startet und reagiert; - benötigter Dienst wird im richtigen Kontext ausgeführt; - erwartete Datei- und Netzwerkzugriffe funktionieren; - keine neuen Fehler oder Fault-Meldungen erscheinen; - CPU-Auslastung normalisiert sich; - Speicherdruck bleibt im normalen Bereich; - Swap wächst nicht weiter ungewöhnlich; - ausreichender Datenträgerspeicher ist vorhanden; - temporär erteilte Rechte wurden geprüft oder zurückgenommen; - deaktivierte Sicherheitsfunktionen wurden nicht als Dauerlösung belassen; - Funktion bleibt nach Ab- und Anmeldung stabil; - falls relevant, Funktion bleibt nach einem kontrollierten Neustart stabil; - keine andere Benutzerfunktion wurde beeinträchtigt. --- **8.5.31 Präventionsmaßnahmen** - macOS und Anwendungen kontrolliert aktuell halten; - vor Updates Kompatibilität geschäftskritischer Software prüfen; - ausreichend freien Datenträgerspeicher vorhalten; - Backups regelmäßig durchführen und Wiederherstellung testen; - Anmeldeobjekte und Hintergrunddienste dokumentieren; - nicht mehr benötigte Drittanbietererweiterungen entfernen; - Datenschutzfreigaben nach dem Minimalprinzip vergeben; - Installationsquellen und Signaturen prüfen; - Baseline-Werte für CPU, Speicher, Datenträger und Startzeit erfassen; - zentrale oder regelmäßige Protokollauswertung für wichtige Systeme einrichten; - Änderungen mit Zeitpunkt, Version und Rückweg dokumentieren; - Systemdiagnosen und Protokolle datenschutzgerecht behandeln; - bei wiederkehrenden Kernel-Panics Hardware und Erweiterungen frühzeitig isolieren. --- **8.5.32 Typische Fehler bei der Diagnose** - Einen Prozess allein wegen eines hohen Einzelwerts beenden. - Einen fehlenden PID-Wert automatisch als Dienstfehler interpretieren. - Einen Agent im `system`-Bereich suchen, obwohl er im Benutzerkontext läuft. - Nur nach dem Wort „error“ suchen und Zeit, Prozess oder Subsystem ignorieren. - Alte Protokollmeldungen mit dem aktuellen Fehler verwechseln. - Freien RAM als einziges Speicherkriterium verwenden. - APFS-Container, Volume, Snapshot und physisches Laufwerk gleichsetzen. - Unix-Berechtigungen und TCC-Freigaben verwechseln. - Gatekeeper oder SIP zum Testen dauerhaft deaktivieren. - `chmod -R 777` als allgemeine Berechtigungslösung verwenden. - unbekannte Systemdateien oder lokale Snapshots manuell löschen. - sofort `kill -9` verwenden. - nach einem Neustart den vorherigen flüchtigen Zustand nicht mehr rekonstruieren können. - nur prüfen, ob ein Prozess läuft, statt die ursprüngliche Benutzerfunktion zu testen. --- **8.5.33 Typische Prüfungsfragen** **Warum beweist ein laufender Prozess noch keine funktionierende Anwendung?** Der Prozess kann blockiert sein, auf eine Ressource warten oder eine benötigte Abhängigkeit nicht erreichen. Entscheidend ist die vollständige Benutzerfunktion. **Was ist der Unterschied zwischen einem LaunchDaemon und einem LaunchAgent?** Ein LaunchDaemon arbeitet systemweit. Ein LaunchAgent arbeitet im Kontext eines Benutzers beziehungsweise einer Benutzeranmeldung. **Warum kann ein registrierter launchd-Dienst keine PID besitzen, ohne fehlerhaft zu sein?** Bedarfsgesteuerte Dienste werden möglicherweise erst gestartet, wenn ein definierter Auslöser eintritt. **Warum ist der Speicherdruck aussagekräftiger als nur der freie Arbeitsspeicher?** macOS nutzt freien Speicher unter anderem für Caches und Komprimierung. Der Speicherdruck zeigt besser, ob die Speicherverwaltung die aktuelle Last noch ausreichend bewältigt. **Warum sollte kill -9 nicht als erste Maßnahme verwendet werden?** Der Prozess erhält keine Möglichkeit, Dateien zu schließen, Daten zu speichern oder seinen Zustand geordnet zu bereinigen. **Warum können korrekte Unix-Berechtigungen trotzdem zu einer Zugriffsverweigerung führen?** Zusätzliche macOS-Schutzmechanismen wie TCC können den Zugriff auf Dateien, Geräte oder geschützte Daten verhindern. **Was bedeutet es, wenn ein Fehler im sicheren Modus nicht auftritt?** Zusätzlich geladene Software, Anmeldeobjekte oder Erweiterungen werden wahrscheinlicher. Eine konkrete Ursache ist dadurch noch nicht bewiesen. **Warum müssen Protokolle zeitlich mit der Störung korreliert werden?** Ein System erzeugt auch im Normalbetrieb Warnungen und Fehler. Erst die zeitliche und funktionale Übereinstimmung macht eine Meldung für den konkreten Vorfall relevant. **Warum ersetzt eine erfolgreiche Erste-Hilfe-Prüfung kein Backup?** Die Prüfung schützt nicht vor späterem Hardwareausfall, versehentlichem Löschen oder bereits beschädigten beziehungsweise fehlenden Benutzerdaten. --- **8.5.34 Checkliste** - [ ] Störung und ursprüngliche Benutzerfunktion dokumentiert - [ ] betroffene App, Benutzer und Geräte bestimmt - [ ] Zeitpunkt und Häufigkeit erfasst - [ ] macOS-Version, Build und Architektur gesichert - [ ] letzte Installationen und Änderungen geprüft - [ ] Systemlaufzeit und Neustarts erfasst - [ ] Prozessstatus und Ressourcen gemessen - [ ] Elternprozess und ausführender Benutzer geprüft - [ ] richtiges `launchd`-Label bestimmt - [ ] richtiger `launchd`-Bereich geprüft - [ ] Protokolle auf den Fehlerzeitraum begrenzt - [ ] Absturz-, Spin- oder Panic-Berichte geprüft - [ ] CPU-Auslastung mehrfach gemessen - [ ] Speicherdruck und Swap geprüft - [ ] Datenträgerspeicher und APFS-Struktur geprüft - [ ] Snapshots und große Verzeichnisse berücksichtigt - [ ] Unix-Berechtigungen und ACLs geprüft - [ ] TCC-Freigaben getrennt geprüft - [ ] App-Signatur bei Startproblemen geprüft - [ ] Anmeldeobjekte und Systemerweiterungen erfasst - [ ] Netzwerk- und externe Abhängigkeiten geprüft - [ ] Kreuztest mit anderem Benutzer durchgeführt - [ ] sicherer Modus bei Bedarf verwendet - [ ] Hardwarediagnose bei entsprechendem Verdacht durchgeführt - [ ] vor Änderung Risiko und Rückweg dokumentiert - [ ] nur eine kontrollierte Änderung durchgeführt - [ ] ursprüngliche Benutzerfunktion verifiziert - [ ] Protokolle und Ressourcen nachkontrolliert - [ ] temporäre Diagnoseänderungen zurückgenommen - [ ] Ergebnis und Präventionsmaßnahme dokumentiert --- **8.5.35 Schnellreferenz** | Aufgabe | Befehl oder Werkzeug | |---|---| | macOS-Version | `sw_vers` | | Prozessorarchitektur | `uname -m` | | Systemlaufzeit | `uptime` | | Hardware- und Softwarebericht | `system_profiler SPHardwareDataType SPSoftwareDataType` | | Prozesse | `ps -axo pid,ppid,user,state,%cpu,%mem,etime,command` | | Live-Ressourcen | `top` oder Aktivitätsanzeige | | Prozess suchen | `pgrep -fl "Prozessname"` | | offene Dateien eines Prozesses | `lsof -nP -p 1234` | | Prozess analysieren | `sample 1234 10 -file Bericht.txt` | | Systemweite launchd-Dienste | `launchctl print system` | | Benutzer-Agents | `launchctl print gui/$(id -u)` | | Property-List prüfen | `plutil -lint Datei.plist` | | letzte Protokolle | `log show --last 30m` | | Protokolle live | `log stream` | | Arbeitsspeicher | `vm_stat` | | Swap | `sysctl vm.swapusage` | | Speicherbelegung | `df -h` | | Datenträgerstruktur | `diskutil list` | | APFS-Struktur | `diskutil apfs list` | | lokale Snapshots | `tmutil listlocalsnapshots /` | | Datenträger-I/O | `iostat -w 2 -c 5` | | Dateiaktivität | `sudo fs_usage` | | Berechtigungen und ACLs | `ls -ldeO@ Pfad` | | Systemerweiterungen | `systemextensionsctl list` | | MDM-Status | `profiles status -type enrollment` | | App-Signatur | `codesign --verify` | | Gatekeeper-Bewertung | `spctl --assess` | | grafische Protokolle | Konsole | | CPU, Speicher und I/O | Aktivitätsanzeige | | Dateisystemprüfung | Festplattendienstprogramm | | Hardwareprüfung | Apple Diagnose | --- **8.5.36 Quellen** **Offizielle Apple-Dokumentation** - [Aktivitätsanzeige – Benutzerhandbuch](https://support.apple.com/de-de/guide/activity-monitor/welcome/mac) - [Mac-Prozesse in der Aktivitätsanzeige anzeigen](https://support.apple.com/de-de/guide/activity-monitor/actmntr1001/mac) - [CPU-Aktivität in der Aktivitätsanzeige anzeigen](https://support.apple.com/de-de/guide/activity-monitor/actmntr43452/mac) - [Speichernutzung in der Aktivitätsanzeige anzeigen](https://support.apple.com/de-de/guide/activity-monitor/actmntr1004/mac) - [Systemdiagnose in der Aktivitätsanzeige ausführen](https://support.apple.com/de-de/guide/activity-monitor/actmntr2225/mac) - [Konsole – Benutzerhandbuch](https://support.apple.com/de-de/guide/console/welcome/mac) - [Protokollmeldungen in der App „Konsole“ anzeigen](https://support.apple.com/de-de/guide/console/cnsl1012/mac) - [Berichte in der App „Konsole“ anzeigen](https://support.apple.com/de-de/guide/console/cnsl664be99a/mac) - [Speichermedium mit dem Festplattendienstprogramm reparieren](https://support.apple.com/de-de/guide/disk-utility/dskutl1040/mac) - [Mac im sicheren Modus starten](https://support.apple.com/de-de/guide/mac-help/mh21245/mac) - [Apple Diagnose verwenden](https://support.apple.com/de-de/102550) - [Zugriff auf Dateien und Ordner steuern](https://support.apple.com/de-de/guide/mac-help/mchld5a35146/mac) - [Einstellungen für Datenschutz und Sicherheit](https://support.apple.com/de-de/guide/mac-help/mchl211c911f/mac) - [Anmeldeobjekte und Erweiterungen verwalten](https://support.apple.com/de-de/guide/mac-help/mtusr003/mac) - [Systeminformationen über den Mac abrufen](https://support.apple.com/de-de/guide/mac-help/syspr35536/mac) **Befehlsreferenzen** Die maßgebliche Befehlsreferenz ist die jeweilige lokale macOS-Manpage: ```bash man launchd man launchctl man log man vm_stat man diskutil man fs_usage man system_profiler ``` Der folgende Spiegel stellt aus Xcode extrahierte Manpages bereit, ist jedoch keine offizielle Apple-Supportseite. Bei Abweichungen gilt die lokale Manpage der installierten macOS-Version: - [launchctl(1)](https://keith.github.io/xcode-man-pages/launchctl.1.html) - [launchd(8)](https://keith.github.io/xcode-man-pages/launchd.8.html) - [log(1)](https://keith.github.io/xcode-man-pages/log.1.html) - [vm_stat(1)](https://keith.github.io/xcode-man-pages/vm_stat.1.html) - [diskutil(8)](https://keith.github.io/xcode-man-pages/diskutil.8.html) - [fs_usage(1)](https://keith.github.io/xcode-man-pages/fs_usage.1.html) - [system_profiler(8)](https://keith.github.io/xcode-man-pages/system_profiler.8.html) # 9. TCP, UDP, Ports, Firewall, NAT und Proxy # 9.1 Ports, Sockets, Listener und gebundene Adressen **Ziel dieser Seite** Diese Seite beschreibt die systematische Diagnose von Ports, Sockets, Listenern und gebundenen IP-Adressen unter Windows, Linux, macOS sowie in Container- und Kubernetes-Umgebungen. Nach der Bearbeitung muss nachvollziehbar geprüft werden können: - welches Transportprotokoll verwendet wird; - auf welchem Port ein Dienst lauschen soll; - an welche lokale Adresse der Socket gebunden ist; - welcher Prozess den Socket besitzt; - ob der Socket im richtigen Netzwerk-Namespace existiert; - ob ein lokaler Listener tatsächlich erreichbar ist; - ob Firewall, NAT, Portweiterleitung oder Proxy beteiligt sind; - ob ein Portkonflikt vorliegt; - ob TCP- und UDP-Verhalten richtig unterschieden werden; - ob die Anwendung auf Protokollebene korrekt antwortet. Ein sichtbarer Listener beweist nur, dass im untersuchten Netzwerk-Namespace ein Socket gebunden wurde. Er beweist nicht, dass der Dienst von einem entfernten Client erreichbar ist oder auf Anwendungsebene korrekt funktioniert. --- **Sicherheits- und Wirkungsklassen** | Kennzeichnung | Bedeutung | |---|---| | **LESEND** | Erfasst ausschließlich vorhandene Zustände. | | **NETZAKTIV** | Erzeugt Netzwerkverkehr zum geprüften Ziel. | | **SENSITIV** | Kann interne Adressen, Prozesse, Verbindungen oder Nutzdaten sichtbar machen. | | **ÄNDERND** | Verändert Konfiguration oder Laufzeitzustand. | | **AUSFALLRISIKO** | Kann bestehende Verbindungen oder Dienste beeinträchtigen. | Socket- und Prozesslisten können interne Dienstnamen, Benutzerkonten, Zieladressen und aktive Kommunikationsbeziehungen enthalten. Ausgaben und Netzwerkaufzeichnungen müssen entsprechend geschützt werden. --- **Grundbegriffe** | Begriff | Bedeutung | |---|---| | **Port** | Numerische Kennzeichnung eines Dienstendpunkts innerhalb eines Transportprotokolls. | | **Socket** | Vom Betriebssystem verwalteter Kommunikationsendpunkt. | | **Listener** | TCP-Socket, der auf neue eingehende Verbindungen wartet. | | **Bind** | Zuordnung eines Sockets zu einer lokalen IP-Adresse und einem lokalen Port. | | **Local Address** | Lokale IP-Adresse, an die der Socket gebunden ist. | | **Local Port** | Lokaler TCP- oder UDP-Port des Sockets. | | **Remote Address** | Adresse der Gegenstelle einer bestehenden Verbindung. | | **Remote Port** | Port der Gegenstelle einer bestehenden Verbindung. | | **Wildcard-Bindung** | Bindung an alle geeigneten lokalen Adressen, beispielsweise `0.0.0.0`. | | **Loopback-Bindung** | Bindung ausschließlich an die lokale Rückschleifenschnittstelle. | | **Netzwerk-Namespace** | Isolierte Netzwerksicht eines Systems oder Containers mit eigenen Schnittstellen, Routen und Sockets. | Ein Port ist nicht unabhängig vom Transportprotokoll zu betrachten. TCP-Port `53` und UDP-Port `53` sind unterschiedliche Endpunkte und können von unterschiedlichen Sockets verwendet werden. --- **Portnummern und Portbereiche** TCP- und UDP-Portnummern besitzen einen Wertebereich von `0` bis `65535`. | Bereich | IANA-Bezeichnung | Typische Verwendung | |---|---|---| | `0–1023` | System Ports | Standardisierte oder systemnahe Dienste | | `1024–49151` | User Ports | Registrierte Anwendungsdienste | | `49152–65535` | Dynamic and/or Private Ports | Dynamische Clientports und private Verwendung | Port `0` besitzt eine besondere Bedeutung und wird nicht wie ein normaler Dienstport verwendet. Eine Anwendung kann beim Binden an Port `0` das Betriebssystem einen freien lokalen Port auswählen lassen. Auf Unix-artigen Systemen erfordert das Binden niedriger Ports häufig erhöhte Berechtigungen oder eine Fähigkeit wie `CAP_NET_BIND_SERVICE`. Das genaue Verhalten ist jedoch vom Betriebssystem und dessen Konfiguration abhängig. Eine Eintragung im IANA-Verzeichnis bedeutet nicht, dass ein Port ausschließlich von dem dort genannten Dienst verwendet werden darf. Für die Diagnose ist die tatsächlich wirksame Konfiguration entscheidend. --- **Socket- und Verbindungsmodell** Ein TCP-Listener wird im Wesentlichen durch folgende Angaben beschrieben: ```text Transportprotokoll + lokale IP-Adresse + lokaler Port ``` Beispiel: ```text TCP 192.0.2.25:443 ``` Eine aufgebaute TCP-Verbindung wird durch beide Endpunkte unterschieden: ```text Transportprotokoll lokale IP-Adresse lokaler Port entfernte IP-Adresse entfernter Port ``` Beispiel: ```text TCP lokal: 192.0.2.25:443 remote: 198.51.100.40:53124 ``` Ein einzelner TCP-Listener auf Port `443` kann deshalb viele gleichzeitige Verbindungen bedienen. Die einzelnen Verbindungen unterscheiden sich mindestens durch die entfernte Adresse oder den entfernten Port. UDP besitzt keinen TCP-Verbindungsaufbau und keinen TCP-Zustand `LISTEN`. Ein UDP-Endpunkt kann dennoch an eine lokale Adresse und einen lokalen Port gebunden sein und Datagramme empfangen. --- **Gebundene Adressen richtig interpretieren** | Bindung | Bedeutung | |---|---| | `127.0.0.1:8080` | Nur über IPv4-Loopback des eigenen Systems erreichbar | | `192.0.2.25:8080` | Nur über diese konkrete IPv4-Adresse erreichbar | | `0.0.0.0:8080` | IPv4-Wildcard; Bindung an alle geeigneten lokalen IPv4-Adressen | | `[::1]:8080` | Nur über IPv6-Loopback erreichbar | | `[::]:8080` | IPv6-Wildcard; Bindung an alle geeigneten lokalen IPv6-Adressen | | `:8080` | Innerhalb des betreffenden Container-Netzwerks gebunden | | `:8080` | Innerhalb des Kubernetes-Pod-Netzwerks gebunden | Eine Bindung an `0.0.0.0` bedeutet nicht, dass ein Client die Zieladresse `0.0.0.0` verwenden soll. Der Client verwendet eine konkrete erreichbare Adresse des Servers. Bei einer Bindung an `[::]` darf nicht ungeprüft angenommen werden, dass derselbe Socket auch IPv4-Verbindungen akzeptiert. Das Verhalten hängt unter anderem vom Betriebssystem, der Socketoption `IPV6_V6ONLY` und der Anwendung ab. IPv4 und IPv6 müssen getrennt geprüft werden. --- **Loopback-, Wildcard- und spezifische Bindung** **Loopback-Bindung** ```text 127.0.0.1:8080 [::1]:8080 ``` Der Dienst ist grundsätzlich nur vom eigenen Netzwerk-Namespace erreichbar. Das ist beispielsweise für lokale Backends hinter einem Reverse Proxy sinnvoll. Ein entfernter Client kann diesen Listener nicht direkt erreichen. **Wildcard-Bindung** ```text 0.0.0.0:8080 [::]:8080 ``` Der Dienst lauscht grundsätzlich auf allen dafür geeigneten Adressen der entsprechenden Protokollfamilie. Dazu können gehören: - LAN-Schnittstellen; - WLAN-Schnittstellen; - VPN-Schnittstellen; - öffentliche Schnittstellen; - virtuelle Switches; - Container-Bridges. Ob der Dienst tatsächlich von jedem Netz erreichbar ist, wird zusätzlich durch Routing, Firewall, NAT, Sicherheitsgruppen und vorgelagerte Systeme bestimmt. **Bindung an eine konkrete Adresse** ```text 192.0.2.25:8080 ``` Der Dienst nimmt Verbindungen nur über diese lokale Adresse an. Die Bindung kann beim Dienststart fehlschlagen, wenn: - die Adresse nicht mehr am System vorhanden ist; - die Schnittstelle noch nicht verfügbar ist; - DHCP eine andere Adresse vergeben hat; - die Adresse erst durch einen später gestarteten VPN-Tunnel entsteht; - die Anwendung vor der Netzwerkkonfiguration gestartet wird; - sich der Dienst in einem anderen Netzwerk-Namespace befindet. --- **TCP-Zustände** | Zustand | Einordnung | |---|---| | `LISTEN` | Lokaler Socket wartet auf neue TCP-Verbindungen. | | `SYN-SENT` | Verbindungsaufbau wurde begonnen; Antwort steht noch aus. | | `SYN-RECEIVED` | Ein SYN wurde empfangen und der Aufbau ist noch nicht abgeschlossen. | | `ESTABLISHED` | TCP-Verbindung ist aufgebaut. | | `FIN-WAIT-1` | Lokale Seite hat das Schließen begonnen. | | `FIN-WAIT-2` | Lokale Seite wartet nach eigenem FIN auf das FIN der Gegenstelle. | | `CLOSE-WAIT` | Gegenstelle hat geschlossen; lokale Anwendung muss noch schließen. | | `LAST-ACK` | Lokale Seite wartet auf die Bestätigung ihres abschließenden FIN. | | `TIME-WAIT` | Geschlossene Verbindung wird vorübergehend zur sicheren Protokollabwicklung vorgehalten. | | `CLOSED` | Keine aktive TCP-Verbindung. | Viele Einträge in `TIME-WAIT` sind nicht automatisch ein Fehler. Sie können bei kurzlebigen Verbindungen normal sein. Dauerhaft viele `CLOSE-WAIT`-Sockets können darauf hindeuten, dass die lokale Anwendung geschlossene Verbindungen nicht ordnungsgemäß freigibt. Dieser Befund muss über Zeitverlauf, Prozesszustand und Anwendungstelemetrie bestätigt werden. --- **Was ein Listener beweist – und was nicht** Ein Listener beweist: - ein Socket wurde im untersuchten Netzwerk-Namespace angelegt; - der Socket ist an einen lokalen Port gebunden; - das Betriebssystem führt ihn als empfangsbereiten TCP-Socket; - ein Prozess oder Kernelbestandteil besitzt den Socket. Ein Listener beweist nicht: - dass die Firewall eingehende Verbindungen erlaubt; - dass Routing zum Server funktioniert; - dass NAT oder Portweiterleitung korrekt sind; - dass ein Load Balancer das richtige Ziel verwendet; - dass die Anwendung nach dem Verbindungsaufbau korrekt antwortet; - dass TLS, HTTP, DNS oder ein anderes Anwendungsprotokoll funktioniert; - dass der Dienst unter dem erwarteten Namen erreichbar ist; - dass IPv4 und IPv6 gleichermaßen funktionieren; - dass der Listener im richtigen Container oder Netzwerk-Namespace existiert. --- **Erwarteten Endpunkt festlegen** Vor der Diagnose müssen mindestens folgende Sollangaben dokumentiert werden: ```text Dienst: Transportprotokoll: Erwartete lokale Adresse: Erwarteter lokaler Port: Erwarteter Netzwerk-Namespace: Erwartete Erreichbarkeit: Vorgelagerte Komponenten: ``` Ohne diese Sollangaben kann ein sichtbarer Socket nicht zuverlässig als richtig oder falsch bewertet werden. --- **Windows: TCP-Listener erfassen** **LESEND** Alle TCP-Verbindungen und Listener: ```powershell Get-NetTCPConnection ``` Nur TCP-Listener: ```powershell Get-NetTCPConnection ` -State Listen | Sort-Object LocalPort, LocalAddress ``` Bestimmten lokalen Port prüfen: ```powershell Get-NetTCPConnection ` -State Listen ` -LocalPort 443 ``` Ausgabe auf wesentliche Felder begrenzen: ```powershell Get-NetTCPConnection ` -State Listen | Select-Object ` LocalAddress, LocalPort, State, OwningProcess | Sort-Object LocalPort, LocalAddress ``` Zu prüfen sind: - `LocalAddress`; - `LocalPort`; - `State`; - `OwningProcess`; - mehrere Listener auf demselben Port; - getrennte IPv4- und IPv6-Einträge; - unerwartete Loopback-Bindung; - unerwartete Wildcard-Bindung. --- **Windows: Prozess eines TCP-Listeners bestimmen** **LESEND** Beispiel für Port `443`: ```powershell Get-NetTCPConnection ` -State Listen ` -LocalPort 443 | ForEach-Object { $connection = $_ $process = Get-Process ` -Id $connection.OwningProcess ` -ErrorAction SilentlyContinue [pscustomobject]@{ LocalAddress = $connection.LocalAddress LocalPort = $connection.LocalPort ProcessId = $connection.OwningProcess ProcessName = $process.ProcessName ProcessPath = $process.Path } } ``` Einen bekannten Prozess prüfen: ```powershell Get-Process ` -Id 1234 ``` Die ausführbare Datei kann abhängig von Prozessschutz und Berechtigungen nicht immer angezeigt werden. --- **Windows: Prozess einem Dienst zuordnen** **LESEND** ```powershell $processId = 1234 Get-CimInstance ` -ClassName Win32_Service ` -Filter "ProcessId = $processId" | Select-Object ` Name, DisplayName, State, StartMode, ProcessId, PathName ``` Wenn kein Dienst zurückgegeben wird, kann der Prozess beispielsweise: - interaktiv gestartet worden sein; - durch einen Task gestartet worden sein; - zu einer Desktopanwendung gehören; - Teil einer Container- oder Virtualisierungsumgebung sein; - durch einen anderen Dienstprozess verwaltet werden. --- **Windows: UDP-Endpunkte erfassen** **LESEND** Alle UDP-Endpunkte: ```powershell Get-NetUDPEndpoint | Sort-Object LocalPort, LocalAddress ``` Bestimmten UDP-Port prüfen: ```powershell Get-NetUDPEndpoint ` -LocalPort 53 ``` UDP-Endpunkt mit Prozessinformationen anzeigen: ```powershell Get-NetUDPEndpoint ` -LocalPort 53 | ForEach-Object { $endpoint = $_ $process = Get-Process ` -Id $endpoint.OwningProcess ` -ErrorAction SilentlyContinue [pscustomobject]@{ LocalAddress = $endpoint.LocalAddress LocalPort = $endpoint.LocalPort ProcessId = $endpoint.OwningProcess ProcessName = $process.ProcessName } } ``` Das Vorhandensein eines UDP-Endpunkts beweist noch nicht, dass eine gesendete Anfrage verarbeitet oder beantwortet wird. --- **Windows: netstat als ergänzende Sicht** **LESEND** ```cmd netstat -ano ``` Nur TCP-Listener: ```cmd netstat -ano -p tcp ``` UDP-Endpunkte: ```cmd netstat -ano -p udp ``` Wiederholte Aktualisierung alle fünf Sekunden: ```cmd netstat -ano 5 ``` Beenden mit `Strg+C`. Wichtige Optionen: | Option | Bedeutung | |---|---| | `-a` | Zeigt aktive Verbindungen und Listener. | | `-n` | Zeigt numerische Adressen und Ports. | | `-o` | Zeigt die zugehörige Prozess-ID. | | `-p tcp` | Begrenzt die Anzeige auf TCP. | | `-p udp` | Begrenzt die Anzeige auf UDP. | Namensauflösung sollte für die erste Diagnose mit `-n` vermieden werden. Anderenfalls können DNS-Verzögerungen die Ausgabe verlangsamen oder Adressen durch Namen verdecken. --- **Windows: lokale IP-Adressen bestätigen** **LESEND** ```powershell Get-NetIPConfiguration ``` Alle verwendbaren IP-Adressen: ```powershell Get-NetIPAddress | Where-Object AddressState -eq "Preferred" | Sort-Object InterfaceIndex, AddressFamily ``` Eine Bindung an eine konkrete Adresse ist nur sinnvoll, wenn diese Adresse tatsächlich im richtigen Netzwerk-Compartment und auf der vorgesehenen Schnittstelle vorhanden ist. --- **Windows: Kernel- und HTTP.sys-Zuordnungen prüfen** Ein Port kann durch einen Kernelbestandteil oder eine gemeinsame HTTP-Infrastruktur verwaltet werden. Der sichtbare Besitzer muss daher nicht unmittelbar der erwartete Anwendungsprozess sein. Bei HTTP- oder HTTPS-Diensten unter Windows: **LESEND** ```cmd netsh http show servicestate ``` Registrierte URL-Zuordnungen: ```cmd netsh http show urlacl ``` Registrierte TLS-Zertifikatbindungen: ```cmd netsh http show sslcert ``` Portproxy-Konfiguration: ```cmd netsh interface portproxy show all ``` Zu prüfen sind: - welcher Dienst die URL registriert hat; - welcher Prozess eine HTTP.sys-Anforderungswarteschlange verwendet; - ob eine Portproxy-Regel besteht; - ob der sichtbare Hostport an ein anderes Ziel weiterleitet; - ob der Prozessbesitzer nur als `System` erscheint. Eine URL-Reservierung allein beweist keinen aktiven Listener. --- **Linux: TCP- und UDP-Sockets mit ss prüfen** `ss` ist unter Linux das bevorzugte Werkzeug zur Anzeige von Socketinformationen. **LESEND** TCP-Listener: ```bash ss -lnt ``` TCP-Listener einschließlich Prozessinformationen: ```bash sudo ss -lntp ``` UDP-Endpunkte: ```bash sudo ss -lnup ``` TCP- und UDP-Endpunkte gemeinsam: ```bash sudo ss -lntup ``` Bestimmten TCP-Port prüfen: ```bash sudo ss -lntp 'sport = :443' ``` Bestimmten UDP-Port prüfen: ```bash sudo ss -lnup 'sport = :53' ``` Alle TCP-Verbindungen und Zustände: ```bash ss -tan ``` Zusammenfassung: ```bash ss -s ``` Wichtige Optionen: | Option | Bedeutung | |---|---| | `-l` | Nur lauschende beziehungsweise unverbundene Endpunkte | | `-n` | Numerische Adressen und Ports | | `-t` | TCP | | `-u` | UDP | | `-p` | Prozessinformationen | | `-a` | Alle Sockets | | `-x` | Unix-Domain-Sockets | Prozessinformationen können erhöhte Berechtigungen erfordern. --- **Linux: Prozess mit lsof bestimmen** **LESEND** Alle lauschenden TCP-Sockets: ```bash sudo lsof -nP -iTCP -sTCP:LISTEN ``` Bestimmten TCP-Port prüfen: ```bash sudo lsof -nP -iTCP:443 -sTCP:LISTEN ``` Bestimmten UDP-Port prüfen: ```bash sudo lsof -nP -iUDP:53 ``` Wichtige Optionen: | Option | Bedeutung | |---|---| | `-n` | Keine Namensauflösung der IP-Adressen | | `-P` | Keine Umwandlung von Ports in Dienstnamen | | `-iTCP` | TCP-Sockets | | `-iUDP` | UDP-Sockets | | `-sTCP:LISTEN` | Nur TCP-Listener | Danach können Prozess und Dienst untersucht werden: ```bash ps -fp ``` Bei einem systemd-Dienst: ```bash systemctl status ``` Prozessbaum: ```bash pstree -p ``` Falls `pstree` nicht installiert ist: ```bash ps -ef --forest ``` --- **Linux: Netzwerkadressen und Namespace prüfen** **LESEND** ```bash ip address show ``` Kompakte Ansicht: ```bash ip -brief address ``` Netzwerk-Namespaces anzeigen: ```bash ip netns list ``` Socketansicht eines bekannten Prozess-Namespace: ```bash sudo nsenter \ -t \ -n \ ss -lntup ``` Dieser Test ist besonders wichtig, wenn ein Prozess in einem Container oder separaten Netzwerk-Namespace läuft. Ein Listener innerhalb eines Container-Namespace muss nicht als normaler Listener in der Sockettabelle des Hosts erscheinen. --- **macOS: TCP- und UDP-Sockets prüfen** Linux-`ss` ist unter macOS standardmäßig nicht verfügbar. Für die Prozesszuordnung ist `lsof` besonders geeignet. **LESEND** Alle TCP-Listener: ```bash sudo lsof -nP -iTCP -sTCP:LISTEN ``` Bestimmten TCP-Port prüfen: ```bash sudo lsof -nP -iTCP:443 -sTCP:LISTEN ``` UDP-Endpunkte: ```bash sudo lsof -nP -iUDP ``` Bestimmten UDP-Port prüfen: ```bash sudo lsof -nP -iUDP:53 ``` TCP-Socketzustände mit `netstat`: ```bash netstat -anv -p tcp ``` UDP-Sockets: ```bash netstat -anv -p udp ``` Lokale Netzwerkschnittstellen: ```bash ifconfig ``` Routing- und Schnittstelleninformationen: ```bash route -n get default ``` Für die Zuordnung eines Ports zu einem Prozess sollte unter macOS nicht allein auf `netstat` vertraut werden. `lsof` liefert dafür normalerweise die geeignetere Sicht. --- **Unix-Domain-Sockets und andere lokale IPC-Endpunkte** Nicht jede lokale Dienstkommunikation verwendet einen TCP- oder UDP-Port. Typische Alternativen sind: - Unix-Domain-Sockets; - Windows Named Pipes; - Shared Memory; - lokale Message Queues; - anwendungsspezifische IPC-Mechanismen. Linux: ```bash sudo ss -lxnp ``` Linux und macOS: ```bash sudo lsof -U ``` Ein Reverse Proxy kann beispielsweise über einen Unix-Domain-Socket mit seinem Backend kommunizieren. In diesem Fall ist für die Backendverbindung kein TCP-Listener sichtbar. Die Diagnose muss dann zusätzlich prüfen: - Pfad des Sockets; - Dateiberechtigungen; - Besitzer und Gruppe; - Existenz nach dem Dienststart; - Namespace oder Container; - SELinux- beziehungsweise AppArmor-Richtlinien; - Konfiguration von Proxy und Backend. --- **Portkonflikte erkennen** Typische Meldungen eines Bindungsfehlers sind: ```text Address already in use EADDRINUSE WSAEADDRINUSE Only one usage of each socket address is normally permitted ``` Mögliche Ursachen: - ein anderer Prozess besitzt bereits denselben Endpunkt; - eine alte Instanz der Anwendung läuft noch; - zwei Dienste verwenden dieselbe konfigurierte Adresse und denselben Port; - ein Wildcard-Listener kollidiert mit einer spezifischen Bindung; - IPv4- und IPv6-Verhalten wurde falsch eingeschätzt; - ein Dienst wird doppelt durch Service Manager und manuellen Start gestartet; - ein Container veröffentlicht bereits denselben Hostport; - eine Portproxy- oder Kernelkomponente ist beteiligt. Windows: ```powershell Get-NetTCPConnection ` -State Listen ` -LocalPort 8080 ``` ```powershell Get-NetUDPEndpoint ` -LocalPort 8080 ``` Linux: ```bash sudo ss -lntup 'sport = :8080' ``` macOS: ```bash sudo lsof -nP -iTCP:8080 -sTCP:LISTEN ``` Ein Port kann unter bestimmten Bedingungen absichtlich durch mehrere Prozesse oder Sockets gemeinsam verwendet werden. Beispiele sind Socketaktivierung, `SO_REUSEPORT`, gemeinsam verwaltete Kernel-Listener oder Clustermechanismen. Deshalb darf ein ungewöhnlicher Mehrfachbefund nicht ohne Prüfung als Fehler bewertet werden. --- **Weitere typische Bindungsfehler** | Meldung oder Fehler | Mögliche Einordnung | |---|---| | `Address already in use` | Endpunkt wird bereits verwendet. | | `Permission denied` | Fehlende Berechtigung, Sicherheitsrichtlinie oder geschützter Port. | | `EACCES` | Zugriff auf Adresse oder Port verweigert. | | `Cannot assign requested address` | Konfigurierte lokale Adresse ist nicht vorhanden. | | `EADDRNOTAVAIL` | Lokale Bindungsadresse steht nicht zur Verfügung. | | `Connection refused` | Zielsystem lehnt aktiv ab; häufig kein passender Listener. | | Timeout | Keine verwertbare Antwort; Paketverlust, Filterung, Routing oder Überlastung möglich. | | Verbindung erfolgreich, Protokollfehler | Transport funktioniert; Anwendung oder Protokollkonfiguration fehlerhaft. | Die Zuordnung ist eine erste Einordnung und kein alleiniger Ursachennachweis. --- **Lokalen TCP-Endpunkt testen** Ein lokaler Test muss zur tatsächlichen Bindung passen. Windows: **NETZAKTIV** ```powershell Test-NetConnection ` -ComputerName "127.0.0.1" ` -Port 8080 ` -InformationLevel Detailed ``` Test gegen die konkrete Schnittstellenadresse: ```powershell Test-NetConnection ` -ComputerName "192.0.2.25" ` -Port 8080 ` -InformationLevel Detailed ``` Linux und macOS: ```bash nc -vz 127.0.0.1 8080 ``` ```bash nc -vz 192.0.2.25 8080 ``` Ein erfolgreicher TCP-Test beweist nur, dass der TCP-Verbindungsaufbau funktioniert hat. Er beweist nicht, dass die Anwendung ein gültiges Ergebnis liefert. `Test-NetConnection -Port` prüft TCP. Es ist kein allgemeiner UDP-Test. --- **Loopback und Schnittstellenadresse getrennt testen** Die folgenden Befunde müssen unterschieden werden: | Loopback-Test | Test gegen Serveradresse | Mögliche Einordnung | |---|---|---| | erfolgreich | erfolgreich | Listener ist lokal über beide Pfade erreichbar | | erfolgreich | fehlgeschlagen | falsche Bindung, lokale Firewall oder Adressproblem | | fehlgeschlagen | erfolgreich | Dienst lauscht nur auf konkreter Adresse | | fehlgeschlagen | fehlgeschlagen | kein Listener, falscher Port, falsches Protokoll oder Dienstfehler | Ein Test gegen `localhost` kann je nach Namensauflösung zuerst `::1` oder `127.0.0.1` verwenden. Für eine eindeutige Diagnose müssen IPv4- und IPv6-Adressen ausdrücklich getestet werden. Windows: ```powershell Test-NetConnection ` -ComputerName "127.0.0.1" ` -Port 8080 ``` ```powershell Test-NetConnection ` -ComputerName "::1" ` -Port 8080 ``` Linux und macOS: ```bash nc -4 -vz 127.0.0.1 8080 ``` ```bash nc -6 -vz ::1 8080 ``` --- **Test von einem entfernten Client** Der Test muss von einem System erfolgen, das den realen Zugriffspfad möglichst genau abbildet. Windows: **NETZAKTIV** ```powershell Test-NetConnection ` -ComputerName "app.example.test" ` -Port 443 ` -InformationLevel Detailed ``` Linux und macOS: ```bash nc -vz app.example.test 443 ``` Getrennte Prüfung einer bekannten IP-Adresse: ```bash nc -vz 192.0.2.25 443 ``` Zu dokumentieren sind: - verwendeter Zielname; - aufgelöste Zieladresse; - Quelladresse; - Zielport; - TCP-Ergebnis; - Zeitpunkt; - Teststandort; - VPN-Zustand; - IPv4 oder IPv6; - direkter oder weitergeleiteter Pfad. Nur autorisierte Ziele und Ports dürfen geprüft werden. Breite Portscans sind für die Diagnose eines bekannten Dienstendpunkts normalerweise nicht erforderlich. --- **Anwendungsprotokoll statt nur Port prüfen** Nach erfolgreichem TCP-Verbindungsaufbau muss das erwartete Anwendungsprotokoll getestet werden. HTTP: ```bash curl -v http://127.0.0.1:8080/ ``` HTTPS mit korrektem Hostnamen und festgelegter Zieladresse: ```bash curl -v \ --resolve app.example.test:443:192.0.2.25 \ https://app.example.test/ ``` TLS mit Server Name Indication: ```bash openssl s_client \ -connect 192.0.2.25:443 \ -servername app.example.test ``` DNS über UDP: ```bash dig @192.0.2.53 example.test A ``` DNS über TCP: ```bash dig @192.0.2.53 example.test A +tcp ``` Ein erfolgreicher TCP-Test auf Port `443` beweist beispielsweise nicht: - dass der TLS-Handshake funktioniert; - dass das richtige Zertifikat geliefert wird; - dass SNI korrekt verarbeitet wird; - dass HTTP eine gültige Antwort liefert; - dass der erwartete virtuelle Host ausgewählt wird. --- **UDP richtig prüfen** UDP besitzt keinen TCP-Handshake. Deshalb kann ein allgemeiner UDP-Porttest kein gleichwertiges Ergebnis wie ein erfolgreicher TCP-Verbindungsaufbau liefern. Zu prüfen sind: - existiert ein lokaler UDP-Endpunkt? - verlässt die Anfrage den Client? - erreicht sie den Server? - antwortet die Anwendung? - erreicht die Antwort den Client? - wird ein ICMP-Fehler zurückgegeben? - wird ICMP unterwegs gefiltert? - wird das richtige Anwendungsprotokoll verwendet? Ein Aufruf wie: ```bash nc -vzu 192.0.2.53 53 ``` kann Datagramme erzeugen, liefert aber ohne geeignete Anwendungsantwort keinen belastbaren Nachweis für einen funktionsfähigen UDP-Dienst. Für UDP ist ein protokollspezifischer Test vorzuziehen, beispielsweise: - `dig` für DNS; - `ntpq`, `chronyc` oder ein geeigneter NTP-Test für NTP; - ein herstellerspezifischer Testclient; - eine begrenzte Netzwerkaufzeichnung. --- **Firewall und Listener getrennt betrachten** Die Diagnoseebenen sind voneinander zu trennen: ```text Anwendungsprozess → lokaler Socket → lokale Firewall → Routing und Netzwerk → externe Firewall oder NAT → Client ``` Mögliche Befunde: - Dienst läuft, aber kein Socket wurde gebunden; - Socket existiert, lokale Firewall blockiert; - lokale Prüfung funktioniert, entfernte Prüfung schlägt fehl; - entfernte Verbindung erreicht den Server, Antwortweg fehlt; - NAT leitet auf einen falschen Hostport weiter; - Load Balancer verwendet den falschen Backendport; - Reverse Proxy erreicht sein lokales Backend nicht. Ein laufender Dienststatus beweist keinen Listener. Ein Listener beweist keine Firewallfreigabe. --- **Windows-Firewallbezug lesend prüfen** Aktive eingehende Regeln anzeigen: **LESEND** ```powershell Get-NetFirewallRule ` -Enabled True ` -Direction Inbound | Select-Object ` DisplayName, Action, Profile, Direction ``` Portfilter zu einer bekannten Regel: ```powershell Get-NetFirewallRule ` -DisplayName "" | Get-NetFirewallPortFilter ``` Adressfilter: ```powershell Get-NetFirewallRule ` -DisplayName "" | Get-NetFirewallAddressFilter ``` Anwendungsfilter: ```powershell Get-NetFirewallRule ` -DisplayName "" | Get-NetFirewallApplicationFilter ``` Zu prüfen sind: - TCP oder UDP; - lokaler Port; - lokales Programm; - lokales und entferntes Adressnetz; - aktives Firewallprofil; - eingehende oder ausgehende Richtung; - Block- und Zulassungsregeln; - durch Gruppenrichtlinie gelieferte Regeln. Die Firewall darf nicht vorsorglich vollständig deaktiviert werden. Eine Änderung muss auf den nachgewiesenen Dienst, Port, Pfad und Zeitraum begrenzt werden. --- **Reverse Proxy und Backendlistener** Ein typischer Aufbau ist: ```text Client → Reverse Proxy auf 0.0.0.0:443 → Backend auf 127.0.0.1:8080 ``` In diesem Fall müssen zwei getrennte Endpunkte geprüft werden: - externer Listener des Reverse Proxys; - interner Listener des Backends. Mögliche Fehler: - Proxy lauscht nicht auf Port `443`; - Backend lauscht nicht auf Port `8080`; - Backend ist nur über IPv6 erreichbar, Proxy verwendet IPv4; - Proxy verwendet den falschen Backendport; - Backend befindet sich in einem Container und `127.0.0.1` bezeichnet dort einen anderen Namespace; - Proxy erwartet einen Unix-Domain-Socket; - TLS endet am Proxy, während das Backend fälschlich ebenfalls TLS erwartet; - Health Check und produktiver Zielport unterscheiden sich. Ein erfolgreicher externer TCP-Verbindungsaufbau beweist nicht, dass das Backend erreichbar ist. --- **Container und Netzwerk-Namespaces** Container besitzen häufig eine eigene Netzwerksicht. Dabei sind mindestens drei Endpunkte zu unterscheiden: ```text Anwendungsport im Container veröffentlichter Port auf dem Host Port des zugreifenden Clients ``` Beispiel: ```text Container: 172.18.0.5:80 Host: 192.0.2.25:8080 Client: verbindet zu 192.0.2.25:8080 ``` Ein Dienst, der innerhalb des Containers nur an `127.0.0.1:80` gebunden ist, ist über eine normale Portveröffentlichung häufig nicht erreichbar. Für den Zugriff über das Container-Netz muss er üblicherweise an der Containeradresse oder an einer geeigneten Wildcard-Adresse lauschen. --- **Docker: Portzuordnung prüfen** **LESEND** Laufende Container und veröffentlichte Ports: ```bash docker ps \ --format 'table {{.Names}}\t{{.Status}}\t{{.Ports}}' ``` Portzuordnungen eines Containers: ```bash docker port ``` Ausführliche Portkonfiguration: ```bash docker inspect \ \ --format '{{json .NetworkSettings.Ports}}' ``` Netzwerkmodus: ```bash docker inspect \ \ --format '{{.HostConfig.NetworkMode}}' ``` Containeradresse: ```bash docker inspect \ \ --format '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' ``` Listener innerhalb des Containers, falls `ss` vorhanden ist: ```bash docker exec \ \ ss -lntup ``` Alternativ, falls `lsof` vorhanden ist: ```bash docker exec \ \ lsof -nP -i ``` Fehlende Diagnosewerkzeuge im Container sind kein Nachweis für einen fehlenden Listener. Minimal gehaltene Images enthalten häufig weder `ss` noch `lsof`. --- **Docker-Portveröffentlichung interpretieren** Beispiele für Veröffentlichungen: ```text 127.0.0.1:8080:80 ``` Bedeutung: ```text Host 127.0.0.1:8080 → Containerport 80 ``` Dieser Hostport soll nur lokal erreichbar sein. ```text 8080:80 ``` Bedeutung: ```text Hostport 8080 → Containerport 80 ``` Ohne ausdrücklich angegebene Hostadresse veröffentlicht Docker den Port standardmäßig auf den Hostadressen. Die genaue Erreichbarkeit hängt zusätzlich von Docker-, Firewall- und IPv4-/IPv6-Konfiguration ab. Wichtige Unterscheidungen: - `EXPOSE` im Image veröffentlicht keinen Hostport; - `-p` beziehungsweise `--publish` erstellt eine Portveröffentlichung; - `-P` veröffentlicht dafür vorgesehene Ports automatisch auf Hostports; - Hostport und Containerport können unterschiedlich sein; - Container-IP und Host-IP sind unterschiedliche Adressen; - der Listener im Container muss zum Containerport passen; - im Host-Netzwerkmodus teilt der Container den Netzwerk-Namespace des Hosts; - im Host-Netzwerkmodus werden normale Publish-Optionen nicht wie bei einem Bridge-Netzwerk verwendet. Ein veröffentlichter Docker-Port muss nicht immer als gewöhnlicher Benutzerprozess-Listener in der erwarteten Host-Socketliste erscheinen. Weiterleitung kann abhängig von Plattform und Konfiguration über Firewall-, NAT- oder Proxymechanismen erfolgen. --- **Kubernetes: Portebenen unterscheiden** Bei Kubernetes sind mehrere Portangaben auseinanderzuhalten: | Feld | Bedeutung | |---|---| | `containerPort` | Deklarative Portangabe am Container; erzwingt keinen Listener. | | `targetPort` | Port, zu dem ein Service im ausgewählten Pod weiterleitet. | | `port` | Port des Kubernetes-Service. | | `nodePort` | Optionaler Port auf den Clusterknoten. | | Pod-Port | Tatsächlicher Socket des Prozesses im Pod. | | Ingress-/Gateway-Port | Extern bereitgestellter Listener eines Proxys oder Gateways. | Beispiel: ```yaml ports: - name: https port: 443 targetPort: 8443 ``` Der Service nimmt Verkehr auf Port `443` an und leitet ihn zum Zielport `8443` weiter. Wenn `targetPort` nicht angegeben wird, entspricht er standardmäßig dem Wert von `port`. Ein eingetragener `containerPort` erzeugt keinen Socket und startet keinen Dienst. --- **Kubernetes-Service und Endpunkte prüfen** **LESEND** Services: ```bash kubectl get service \ --all-namespaces ``` Bestimmten Service beschreiben: ```bash kubectl describe service \ \ -n ``` Service als YAML anzeigen: ```bash kubectl get service \ \ -n \ -o yaml ``` EndpointSlices anzeigen: ```bash kubectl get endpointslice \ -n \ -l kubernetes.io/service-name= \ -o wide ``` Pods und Pod-Adressen: ```bash kubectl get pods \ -n \ -o wide ``` Pod beschreiben: ```bash kubectl describe pod \ \ -n ``` Listener im Pod, falls das Werkzeug vorhanden ist: ```bash kubectl exec \ -n \ \ -- ss -lntup ``` Bei mehreren Containern im Pod: ```bash kubectl exec \ -n \ \ -c \ -- ss -lntup ``` Zu prüfen sind: - Service-Port; - `targetPort`; - benannter oder numerischer Zielport; - Selektor des Service; - passende Pods; - Ready-Zustand der Pods; - vorhandene EndpointSlices; - tatsächlicher Listener im Pod; - Bindung an Pod-IP oder Wildcard; - NetworkPolicy; - Sidecar- oder Service-Mesh-Proxy; - Ingress- oder Gateway-Konfiguration. Ein Service ohne passende Endpunkte kann existieren, obwohl kein Backend erreichbar ist. --- **Besonderheiten von NodePort, Service und Ingress** Ein Kubernetes-`NodePort` oder ein durch Regeln weitergeleiteter Service-Port muss nicht als klassischer Anwendungsprozess im Zustand `LISTEN` erscheinen. Je nach Plattform wird der Verkehr beispielsweise durch: - kube-proxy; - nftables; - iptables; - IPVS; - eBPF; - einen Cloud Load Balancer; - ein Ingress-Gateway weitergeleitet. Deshalb sind für Kubernetes mehrere Ebenen zu prüfen: ```text externer Listener oder Load Balancer → NodePort beziehungsweise Service → EndpointSlice → Pod-IP und targetPort → Prozess im Pod ``` Die alleinige Suche nach einem Hostprozess mit dem externen Port kann zu einer falschen Schlussfolgerung führen. --- **IPv4 und IPv6 getrennt prüfen** Zu prüfen sind: - existiert ein IPv4-Listener? - existiert ein IPv6-Listener? - welche Adresse liefert DNS? - welche Adresse wählt der Client zuerst? - ist die Firewall für beide Protokollfamilien passend konfiguriert? - existiert für beide Adressfamilien eine Route? - liefert die Anwendung auf beiden Pfaden dieselbe Antwort? Windows: ```powershell Get-NetTCPConnection ` -State Listen ` -LocalPort 443 | Select-Object LocalAddress, LocalPort, OwningProcess ``` Linux: ```bash sudo ss -lntp 'sport = :443' ``` Gezielter IPv4-Test: ```bash curl -4 -v https://app.example.test/ ``` Gezielter IPv6-Test: ```bash curl -6 -v https://app.example.test/ ``` Wenn IPv6 fehlschlägt und IPv4 funktioniert, darf der Fehler nicht durch dauerhaftes Abschalten von IPv6 verdeckt werden. Bindung, Routing, DNS und Firewall müssen getrennt untersucht werden. --- **Temporäre und dynamische Clientports** Beim Aufbau einer ausgehenden Verbindung verwendet der Client normalerweise einen lokalen Quellport aus einem dynamischen Bereich. Beispiel: ```text Client: 192.0.2.100:53124 Server: 192.0.2.25:443 ``` Der Serverdienst lauscht auf Port `443`. Der Clientport `53124` wurde für diese Verbindung lokal ausgewählt. Typische Diagnosefehler: - den dynamischen Clientport mit dem Serverport verwechseln; - eine eingehende Firewallregel für den Clientquellport erwarten; - einen `TIME-WAIT`-Eintrag als Serverlistener interpretieren; - nur nach dem Zielport suchen und die Verbindungsrichtung ignorieren. Die ausführliche Diagnose dynamischer Ports und Porterschöpfung erfolgt in der dafür vorgesehenen Folgeseite. --- **Dienststatus und Socketstatus vergleichen** | Dienststatus | Socketstatus | Einordnung | |---|---|---| | läuft | Listener vorhanden | Dienst hat mindestens einen erwarteten Socket angelegt | | läuft | Listener fehlt | Start teilweise fehlgeschlagen, falsche Konfiguration oder falscher Namespace | | beendet | Listener vorhanden | anderer Prozess, Kernelkomponente oder alte Instanz besitzt den Port | | startet wiederholt | Listener erscheint kurz | Absturz, Health-Check-Fehler oder Portkonflikt möglich | | läuft | falsche Adresse | Bindung oder Schnittstellenkonfiguration fehlerhaft | | läuft | falscher Port | Konfigurationsquelle oder Startparameter prüfen | Ein grüner Dienststatus ist kein ausreichender Funktionsnachweis. --- **Konfigurationsquelle des Listeners bestimmen** Mögliche Quellen der Bindung: - Anwendungskonfigurationsdatei; - Kommandozeilenparameter; - Umgebungsvariable; - Windows-Registry; - systemd-Unit; - Socketaktivierung; - Docker-Compose-Datei; - Kubernetes-Manifest; - Helm-Werte; - Reverse-Proxy-Konfiguration; - Orchestrator oder Service Discovery; - durch Gruppenrichtlinie oder zentrale Verwaltung gelieferte Einstellung. Zu dokumentieren sind: ```text wirksamer Port: wirksame Bindungsadresse: Quelle: geladene Version: Zeitpunkt der letzten Änderung: Neustart erforderlich: ``` Die Änderung einer nicht wirksamen Konfigurationsdatei führt zu keinem belastbaren Ergebnis. Zuerst muss bestimmt werden, welche Konfiguration der laufende Prozess tatsächlich verwendet. --- **Netzwerkaufzeichnung gezielt einsetzen** Eine Netzwerkaufzeichnung ist sinnvoll, wenn unklar bleibt: - ob der Client ein SYN sendet; - ob das SYN den Server erreicht; - ob der Server mit SYN/ACK oder RST antwortet; - ob die Antwort den Client erreicht; - ob UDP-Anfragen und Antworten übertragen werden; - ob ein Proxy oder Load Balancer beteiligt ist; - ob IPv4 oder IPv6 verwendet wird; - ob Verbindungen wiederholt aufgebaut werden; - ob der Server die Verbindung nach dem Aufbau beendet. Linux: **SENSITIV · LESEND** ```bash sudo tcpdump \ -ni any \ 'tcp port 443' \ -c 100 ``` Auf eine Gegenstelle begrenzen: ```bash sudo tcpdump \ -ni any \ 'host 198.51.100.40 and tcp port 443' \ -c 100 ``` UDP-Beispiel: ```bash sudo tcpdump \ -ni any \ 'udp port 53' \ -c 100 ``` macOS mit konkreter Schnittstelle: ```bash sudo tcpdump \ -ni en0 \ 'tcp port 443' \ -c 100 ``` Lokalen macOS-Verkehr auf Loopback: ```bash sudo tcpdump \ -ni lo0 \ 'tcp port 8080' \ -c 100 ``` Aufzeichnungen müssen auf den benötigten Port, Host und Zeitraum begrenzt werden. Sie können sensible Adressen und Nutzdaten enthalten. --- **TCP-Paketbefunde einordnen** | Beobachtung | Mögliche Einordnung | |---|---| | SYN verlässt Client, erreicht Server nicht | Routing, Firewall, NAT oder falsche Zieladresse | | SYN erreicht Server, keine Antwort | Filterung, Überlastung oder falscher Netzwerk-Namespace | | SYN erreicht Server, RST folgt | häufig kein passender Listener oder aktive Ablehnung | | SYN, SYN/ACK, ACK sichtbar | TCP-Verbindungsaufbau erfolgreich | | Aufbau erfolgreich, sofortiges FIN | Anwendung beendet Verbindung kontrolliert | | Aufbau erfolgreich, sofortiges RST | Anwendung, Proxy oder Protokollfehler möglich | | Server antwortet, Antwort erreicht Client nicht | Rückweg, Firewall, asymmetrisches Routing | | wiederholte SYN-Pakete | Client erhält keine verwertbare Antwort | Die Paketaufzeichnung muss möglichst auf beiden Seiten oder an einem geeigneten Zwischenpunkt korreliert werden. Eine Aufzeichnung nur am Client zeigt nicht sicher, ob das Paket den Server erreicht hat. --- **Systematischer Diagnoseablauf** 1. Exakte Fehlermeldung, Zeitpunkt und betroffene Anwendung dokumentieren. 2. Erwartetes Transportprotokoll bestimmen. 3. Erwarteten lokalen und entfernten Port bestimmen. 4. Erwartete Bindungsadresse festlegen. 5. Erforderliche Erreichbarkeit bestimmen: lokal, LAN, VPN oder öffentlich. 6. Host, Container, Pod und Netzwerk-Namespace unterscheiden. 7. Tatsächliche IP-Adressen des Systems erfassen. 8. DNS-Auflösung des Zielnamens dokumentieren. 9. TCP-Listener oder UDP-Endpunkt erfassen. 10. IPv4- und IPv6-Bindung getrennt auswerten. 11. Besitzenden Prozess bestimmen. 12. Prozess einem Dienst, Container oder Pod zuordnen. 13. Wirksame Konfigurationsquelle bestimmen. 14. Dienstprotokolle zum Startzeitpunkt prüfen. 15. Auf Portkonflikte oder Bindungsfehler prüfen. 16. Loopback-Endpunkt testen. 17. Konkrete lokale Schnittstellenadresse testen. 18. Test von einem repräsentativen entfernten Client durchführen. 19. Firewall, NAT und Portweiterleitung prüfen. 20. Reverse Proxy, Load Balancer oder Kubernetes-Service berücksichtigen. 21. Nach erfolgreichem Transport das Anwendungsprotokoll testen. 22. Bei Bedarf eine begrenzte Netzwerkaufzeichnung durchführen. 23. Hypothese, erwarteten Befund und Gegenbeweis formulieren. 24. Genau eine kontrollierte Maßnahme durchführen. 25. Identische Tests wiederholen. 26. Anwendung und weitere repräsentative Clients verifizieren. 27. Temporäre Diagnoseänderungen zurücknehmen. 28. Ursache und Prävention dokumentieren. --- **Hypothese und Gegenbeweis** Beispiel: ```text Hypothese: Der Webdienst ist ausschließlich an 127.0.0.1:8080 gebunden und deshalb von entfernten Clients nicht direkt erreichbar. Erwarteter Befund: Der lokale Test gegen 127.0.0.1:8080 funktioniert. Die Socketliste zeigt keinen Listener auf 192.0.2.25:8080 oder 0.0.0.0:8080. Der Test eines entfernten Clients schlägt fehl. Gegenbeweis: Die Socketliste zeigt einen Listener auf 0.0.0.0:8080 und eine Netzwerkaufzeichnung bestätigt, dass der Server eingehende SYN-Pakete mit SYN/ACK beantwortet. Testmethode: Socketliste, lokaler Test, entfernter Test und begrenzte Aufzeichnung. Risiko: Die lesenden Socketprüfungen sind risikoarm. Aktive Tests erzeugen Netzwerkverkehr, verändern aber nicht die Dienstkonfiguration. ``` Eine Änderung darf erst erfolgen, wenn die vermutete Ursache einen messbaren Befund besitzt. --- **Kontrollierte Maßnahmen** | Maßnahme | Voraussetzung | Risiko | |---|---|---| | Bindungsadresse korrigieren | falsche Adresse nachgewiesen | Dienst kann auf weiteren Netzen erreichbar werden | | Port korrigieren | Soll- und Ist-Port unterscheiden sich nachweislich | Clients oder Überwachung verwenden eventuell alten Port | | kollidierenden Prozess beenden | falscher Prozessbesitz eindeutig bestätigt | Prozess oder abhängiger Dienst fällt aus | | Dienst geordnet neu starten | Konfigurationsänderung erfordert Neustart | bestehende Verbindungen werden unterbrochen | | Firewallregel anpassen | Listener funktioniert lokal und Filterung ist bestätigt | unbeabsichtigte Freigabe | | Docker-Portzuordnung korrigieren | falscher Host- oder Containerport bestätigt | Container muss eventuell neu erstellt werden | | Kubernetes-`targetPort` korrigieren | Service und Pod-Listener stimmen nicht überein | laufender Dienstverkehr wird umgeleitet | | Reverse-Proxy-Ziel korrigieren | falscher Backendendpunkt nachgewiesen | alle über den Proxy laufenden Anfragen betroffen | | IPv4-/IPv6-Bindung korrigieren | Protokollfamilienfehler bestätigt | zusätzliche Angriffsfläche oder geänderte Erreichbarkeit | | Socketdateiberechtigung korrigieren | Unix-Socket und Zugriffsfehler bestätigt | weitere lokale Prozesse können Zugriff erhalten | Vor der Maßnahme sind zu dokumentieren: - Ausgangszustand; - betroffener Endpunkt; - Prozess und Dienst; - Konfigurationsquelle; - erwartete Wirkung; - Sicherheitsauswirkung; - Wartungsfenster; - Rückweg; - Erfolgskriterium. --- **Befundmatrix** | Befund | Mögliche Einordnung | Nächster Nachweis | |---|---|---| | Dienst läuft, Port fehlt | Bindung fehlgeschlagen oder falsche Konfiguration | Startprotokoll und wirksame Konfiguration | | Port vorhanden, falscher Prozess | Portkonflikt oder unerwarteter Dienst | Prozesspfad und Dienstzuordnung | | Listener nur auf `127.0.0.1` | nur lokale Erreichbarkeit vorgesehen oder Fehlkonfiguration | Sollbindung und Proxyaufbau prüfen | | Listener auf `0.0.0.0` | alle geeigneten IPv4-Adressen | Firewall und tatsächliche Erreichbarkeit prüfen | | Listener nur auf `[::]` | IPv6-Wildcard | IPv4 und IPv6 ausdrücklich getrennt testen | | lokaler Test funktioniert, remote nicht | Firewall, Routing, NAT oder Bindungsumfang | entfernte Aufzeichnung und Firewallzustand | | TCP-Verbindung funktioniert, Anwendung nicht | Anwendungs- oder Protokollfehler | HTTP-, TLS- oder Diensttest | | `Connection refused` | häufig kein passender Listener | Server-Socketliste und Paketaufzeichnung | | Timeout | keine verwertbare Antwort | Routing, Filterung und Aufzeichnung | | UDP-Endpunkt sichtbar, keine Antwort | Anwendung, Firewall oder Rückweg | protokollspezifischer Test und Aufzeichnung | | Port erscheint kurz und verschwindet | Prozess beendet sich oder startet neu | Prozess- und Dienstprotokolle | | Bindung meldet `Address already in use` | Endpunkt bereits belegt | Besitzer des vorhandenen Sockets bestimmen | | Bindung meldet `Address not available` | konfigurierte lokale IP fehlt | Schnittstellen und Startreihenfolge | | Docker-Port veröffentlicht, Anwendung nicht erreichbar | falscher Containerport oder Loopback-Bindung im Container | Listener innerhalb des Containers | | Kubernetes-Service ohne Endpunkte | Selektor oder Readiness fehlerhaft | Pods und EndpointSlices | | Service-Port stimmt, `targetPort` falsch | Weiterleitung auf falschen Pod-Port | Service-YAML und Pod-Listener | | Host zeigt keinen Listener, NodePort funktioniert | regelbasierte Weiterleitung | Kubernetes- und Host-Netzwerkregeln | | nur `localhost` schlägt fehl | IPv4-/IPv6-Auswahl oder Hosts-Auflösung | `127.0.0.1` und `::1` einzeln testen | | nur einige Clients scheitern | Netzpfad, Adressfamilie oder Richtlinie | erfolgreiche und fehlerhafte Pfade vergleichen | --- **Typische Diagnosefehler** - TCP und UDP nicht unterscheiden. - Einen UDP-Endpunkt als TCP-Listener interpretieren. - Nur nach der Portnummer suchen und das Protokoll ignorieren. - `0.0.0.0` als verwendbare Zieladresse eines Clients behandeln. - Loopback-Bindung und Wildcard-Bindung gleichsetzen. - Einen Listener als vollständigen Funktionsnachweis bewerten. - Nur den Dienststatus prüfen. - Den besitzenden Prozess nicht bestimmen. - Prozess-ID aus einer alten Aufnahme verwenden. - IPv4 und IPv6 nicht getrennt prüfen. - `localhost` als eindeutigen IPv4-Test behandeln. - Wildcard-Bindung automatisch als öffentliche Erreichbarkeit interpretieren. - Öffentliche Erreichbarkeit allein durch lokale Socketlisten bewerten. - `Test-NetConnection -Port` als UDP-Test verwenden. - Einen offenen TCP-Port mit funktionierendem TLS oder HTTP gleichsetzen. - Host- und Containerport verwechseln. - Container-IP und Host-IP verwechseln. - Den falschen Netzwerk-Namespace untersuchen. - `EXPOSE` mit einer Docker-Portveröffentlichung gleichsetzen. - Kubernetes-`containerPort` als echten Listener interpretieren. - `port`, `targetPort` und `nodePort` verwechseln. - Bei NodePort nur nach einem Benutzerprozess-Listener suchen. - Einen Reverse Proxy und sein Backend als einen einzigen Endpunkt behandeln. - Einen Portkonflikt durch wiederholte Neustarts verdecken. - Einen Prozess beenden, bevor seine Funktion und Abhängigkeiten geklärt sind. - Die Firewall vollständig deaktivieren. - Breite Portscans ohne technische Notwendigkeit durchführen. - Netzwerkaufzeichnungen unbegrenzt laufen lassen. - Sensible Socket- oder Paketdaten ungeschützt speichern. - Mehrere Konfigurationsvariablen gleichzeitig verändern. - Nach der Maßnahme nur lokal testen. - Temporäre Regeln und Diagnosewerkzeuge aktiv lassen. --- **Verifikation** Nach einer Maßnahme müssen mindestens folgende Punkte geprüft werden: - der erwartete Prozess läuft; - der Prozess besitzt den vorgesehenen Socket; - das richtige Transportprotokoll wird verwendet; - der richtige lokale Port ist gebunden; - die richtige lokale Adresse ist gebunden; - die Bindung existiert im richtigen Netzwerk-Namespace; - keine unerwartete zusätzliche Bindung besteht; - IPv4 funktioniert, sofern vorgesehen; - IPv6 funktioniert, sofern vorgesehen; - Loopback-Verhalten entspricht der Planung; - konkrete Schnittstellenadressen funktionieren; - lokale Firewallregeln entsprechen dem Sollzustand; - NAT oder Portweiterleitung verwendet den richtigen Zielport; - Docker-Host- und Containerport stimmen überein; - Kubernetes-`port` und `targetPort` stimmen mit dem Pod-Listener überein; - EndpointSlices enthalten die vorgesehenen Backends; - Reverse Proxy oder Load Balancer erreicht das Backend; - ein repräsentativer entfernter Client kann den Endpunkt erreichen; - das Anwendungsprotokoll liefert die erwartete Antwort; - keine neuen Bindungs-, Prozess- oder Dienstfehler entstehen; - temporäre Diagnoseänderungen wurden zurückgenommen; - Sicherheitsauswirkungen der Bindung wurden geprüft; - Ursache, Maßnahme und Prävention wurden dokumentiert. Eine einzelne erfolgreiche lokale TCP-Verbindung ist keine ausreichende Gesamtverifikation. --- **Dokumentationsvorlage** ```text Störung: Zeitpunkt: Betroffener Dienst: Betroffener Host: Netzwerk-Namespace: Transportprotokoll: Erwartete Bindung: Tatsächliche Bindung: Prozess: Dienstzuordnung: Konfigurationsquelle: Lokaler Test: Entfernter Test: Anwendungsprotokolltest: Firewall-, NAT- oder Proxyweg: IPv4-Befund: IPv6-Befund: Nachgewiesene Ursache: Gegenbeweis ausgeschlossen durch: Durchgeführte Maßnahme: Risiko und Rückweg: Verifikation: Prävention: ``` --- **Checkliste** - [ ] exakte Fehlermeldung dokumentiert - [ ] Zeitpunkt dokumentiert - [ ] Anwendung oder Dienst bestimmt - [ ] TCP und UDP unterschieden - [ ] erwarteten Port bestimmt - [ ] erwartete Bindungsadresse bestimmt - [ ] erforderliche Erreichbarkeit bestimmt - [ ] Host, Container und Pod unterschieden - [ ] Netzwerk-Namespace bestimmt - [ ] lokale IP-Adressen erfasst - [ ] DNS-Zieladressen dokumentiert - [ ] TCP-Listener geprüft - [ ] UDP-Endpunkte bei Bedarf geprüft - [ ] IPv4-Bindung geprüft - [ ] IPv6-Bindung geprüft - [ ] Loopback-Bindung geprüft - [ ] Wildcard-Bindung geprüft - [ ] Bindung an konkrete Adresse geprüft - [ ] Prozess-ID bestimmt - [ ] Prozessname und Pfad geprüft - [ ] Dienstzuordnung geprüft - [ ] Konfigurationsquelle bestimmt - [ ] Startparameter und Umgebungsvariablen berücksichtigt - [ ] Dienstprotokolle ausgewertet - [ ] Portkonflikt ausgeschlossen - [ ] Kernel- oder HTTP.sys-Zuordnung bei Bedarf geprüft - [ ] Portproxy bei Bedarf geprüft - [ ] lokalen Loopback-Test durchgeführt - [ ] konkrete lokale Serveradresse getestet - [ ] entfernten Clienttest durchgeführt - [ ] Quell- und Zieladresse dokumentiert - [ ] Firewallzustand berücksichtigt - [ ] NAT und Portweiterleitung berücksichtigt - [ ] Reverse Proxy berücksichtigt - [ ] Load Balancer berücksichtigt - [ ] Docker-Portzuordnung bei Bedarf geprüft - [ ] Listener innerhalb des Containers geprüft - [ ] Kubernetes-Service bei Bedarf geprüft - [ ] `port` und `targetPort` verglichen - [ ] EndpointSlices geprüft - [ ] tatsächlichen Pod-Listener geprüft - [ ] Anwendungsprotokoll getestet - [ ] UDP mit protokollspezifischem Werkzeug geprüft - [ ] bei Bedarf Netzwerkaufzeichnung durchgeführt - [ ] Aufzeichnung technisch und zeitlich begrenzt - [ ] Hypothese formuliert - [ ] Gegenbeweis festgelegt - [ ] Risiko und Rückweg dokumentiert - [ ] nur eine kontrollierte Änderung durchgeführt - [ ] identische Tests wiederholt - [ ] ursprüngliche Anwendung getestet - [ ] repräsentative entfernte Clients geprüft - [ ] temporäre Änderungen zurückgenommen - [ ] Ursache und Prävention dokumentiert --- **Schnellreferenz** | Aufgabe | Befehl | |---|---| | Windows-TCP-Verbindungen | `Get-NetTCPConnection` | | Windows-TCP-Listener | `Get-NetTCPConnection -State Listen` | | Windows-Port prüfen | `Get-NetTCPConnection -State Listen -LocalPort ` | | Windows-UDP-Endpunkte | `Get-NetUDPEndpoint` | | Windows-UDP-Port prüfen | `Get-NetUDPEndpoint -LocalPort ` | | Windows-Prozess prüfen | `Get-Process -Id ` | | Windows-Dienst zu PID | `Get-CimInstance Win32_Service -Filter "ProcessId = "` | | Windows-netstat | `netstat -ano` | | Windows-IP-Adressen | `Get-NetIPAddress` | | Windows-TCP-Test | `Test-NetConnection -ComputerName -Port ` | | Windows-HTTP.sys-Zustand | `netsh http show servicestate` | | Windows-URL-Reservierungen | `netsh http show urlacl` | | Windows-Portproxy | `netsh interface portproxy show all` | | Linux-TCP-Listener | `sudo ss -lntp` | | Linux-UDP-Endpunkte | `sudo ss -lnup` | | Linux-TCP-Port prüfen | `sudo ss -lntp 'sport = :'` | | Linux-Socketübersicht | `ss -s` | | Linux-Prozess zu TCP-Port | `sudo lsof -nP -iTCP: -sTCP:LISTEN` | | Linux-Prozess zu UDP-Port | `sudo lsof -nP -iUDP:` | | Linux-IP-Adressen | `ip -brief address` | | Linux-Netzwerk-Namespaces | `ip netns list` | | macOS-TCP-Listener | `sudo lsof -nP -iTCP -sTCP:LISTEN` | | macOS-UDP-Endpunkte | `sudo lsof -nP -iUDP` | | macOS-TCP-Sockets | `netstat -anv -p tcp` | | Unix-Domain-Sockets Linux | `sudo ss -lxnp` | | Unix-Domain-Sockets mit lsof | `sudo lsof -U` | | TCP-Test Linux/macOS | `nc -vz ` | | HTTP-Test | `curl -v http://:/` | | HTTPS-Test mit Zieladresse | `curl -v --resolve :: https:///` | | TLS-Test mit SNI | `openssl s_client -connect : -servername ` | | Docker-Portübersicht | `docker ps --format 'table {{.Names}}\t{{.Ports}}'` | | Docker-Portzuordnung | `docker port ` | | Docker-Netzwerkmodus | `docker inspect --format '{{.HostConfig.NetworkMode}}'` | | Listener im Container | `docker exec ss -lntup` | | Kubernetes-Services | `kubectl get service --all-namespaces` | | Kubernetes-Service prüfen | `kubectl describe service -n ` | | Kubernetes-EndpointSlices | `kubectl get endpointslice -n -l kubernetes.io/service-name=` | | Listener im Pod | `kubectl exec -n -- ss -lntup` | | begrenzte Linux-Aufzeichnung | `sudo tcpdump -ni any 'tcp port ' -c 100` | --- **Befehle und Maßnahmen, die nicht unkontrolliert als erste Diagnose verwendet werden dürfen** ```text Stop-Process taskkill Stop-Service Restart-Service Set-NetFirewallRule New-NetFirewallRule Remove-NetFirewallRule netsh advfirewall set allprofiles state off kill kill -9 systemctl stop systemctl restart iptables nft ufw disable firewall-cmd --permanent docker stop docker restart docker rm kubectl delete kubectl rollout restart Änderung einer Wildcard- oder öffentlichen Bindung Entfernen einer Portweiterleitung vollständiges Deaktivieren einer Hostfirewall ``` Das Beenden eines Prozesses oder Neustarten eines Dienstes kann den aktuellen Portbesitz zwar verändern, vernichtet aber möglicherweise den für die Ursachenanalyse wichtigen Ausgangszustand. --- **Quellen** **Offizielle Microsoft-Dokumentation** - [Microsoft Learn – Get-NetTCPConnection](https://learn.microsoft.com/en-us/powershell/module/nettcpip/get-nettcpconnection) - [Microsoft Learn – Get-NetUDPEndpoint](https://learn.microsoft.com/en-us/powershell/module/nettcpip/get-netudpendpoint) - [Microsoft Learn – Test-NetConnection](https://learn.microsoft.com/en-us/powershell/module/nettcpip/test-netconnection) - [Microsoft Learn – netstat](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/netstat) - [Microsoft Learn – Get-NetIPAddress](https://learn.microsoft.com/en-us/powershell/module/nettcpip/get-netipaddress) - [Microsoft Learn – Get-NetFirewallRule](https://learn.microsoft.com/en-us/powershell/module/netsecurity/get-netfirewallrule) - [Microsoft Learn – netsh http](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/netsh-http) - [Microsoft Learn – netsh interface portproxy](https://learn.microsoft.com/en-us/windows-server/networking/technologies/netsh/netsh-interface-portproxy) **Offizielle Linux- und Unix-Dokumentation** - [Linux man-pages – ss(8)](https://man7.org/linux/man-pages/man8/ss.8.html) - [Linux man-pages – lsof(8)](https://man7.org/linux/man-pages/man8/lsof.8.html) - [Linux man-pages – tcpdump(8)](https://man7.org/linux/man-pages/man8/tcpdump.8.html) - [Linux man-pages – ip-netns(8)](https://man7.org/linux/man-pages/man8/ip-netns.8.html) - [Linux man-pages – socket(7)](https://man7.org/linux/man-pages/man7/socket.7.html) - [Linux man-pages – tcp(7)](https://man7.org/linux/man-pages/man7/tcp.7.html) - [Linux man-pages – udp(7)](https://man7.org/linux/man-pages/man7/udp.7.html) **Offizielle Docker-Dokumentation** - [Docker Docs – Port publishing and mapping](https://docs.docker.com/engine/network/port-publishing/) - [Docker Docs – Networking overview](https://docs.docker.com/engine/network/) - [Docker Docs – docker container port](https://docs.docker.com/reference/cli/docker/container/port/) - [Docker Docs – Bridge network driver](https://docs.docker.com/engine/network/drivers/bridge/) - [Docker Docs – Host network driver](https://docs.docker.com/engine/network/drivers/host/) **Offizielle Kubernetes-Dokumentation** - [Kubernetes – Services, Load Balancing, and Networking](https://kubernetes.io/docs/concepts/services-networking/service/) - [Kubernetes – EndpointSlices](https://kubernetes.io/docs/concepts/services-networking/endpoint-slices/) - [Kubernetes API – Service](https://kubernetes.io/docs/reference/kubernetes-api/service-resources/service-v1/) - [Kubernetes – Network Policies](https://kubernetes.io/docs/concepts/services-networking/network-policies/) **Standards und Register** - [IANA – Service Name and Transport Protocol Port Number Registry](https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml) - [RFC 6335 – Service Name and Transport Protocol Port Number Registry](https://datatracker.ietf.org/doc/html/rfc6335) - [RFC 9293 – Transmission Control Protocol](https://datatracker.ietf.org/doc/html/rfc9293) - [RFC 768 – User Datagram Protocol](https://datatracker.ietf.org/doc/html/rfc768) - [RFC 3493 – Basic Socket Interface Extensions for IPv6](https://datatracker.ietf.org/doc/html/rfc3493) Für diese Seite wurden keine Community-Berichte oder Social-Media-Aussagen als technische Nachweise verwendet. # 9.2 TCP-Handshake, Timeouts und TCP Reset **Ziel dieser Seite** Diese Seite beschreibt den vollständigen Lebenszyklus einer TCP-Verbindung: - Verbindungsaufbau zwischen Client und Server; - Aushandlung wichtiger TCP-Optionen; - zuverlässige und geordnete Datenübertragung; - Bestätigungen, Sequenznummern und Wiederholungen; - kontrollierter Verbindungsabbau; - Timeouts auf unterschiedlichen Ebenen; - abrupter Verbindungsabbruch durch TCP Reset; - systematische Diagnose mit Windows, Linux, macOS und Paketaufzeichnungen. Nach der Bearbeitung muss unterschieden werden können: - ob bereits der TCP-Verbindungsaufbau scheitert; - welche Seite den Verbindungsaufbau nicht fortsetzt; - ob ein Port aktiv abgelehnt wird; - ob Pakete verworfen oder verzögert werden; - ob TCP erfolgreich aufgebaut wurde und erst das Anwendungsprotokoll scheitert; - ob eine Verbindung kontrolliert mit `FIN` oder abrupt mit `RST` beendet wurde; - ob ein Timeout aus TCP, der Anwendung, einem Proxy oder einer Firewall stammt; - welche Gegenstelle oder Zwischenkomponente wahrscheinlich einen Reset erzeugt hat; - ob Wiederholungen auf Paketverlust oder lediglich auf eine unvollständige Aufzeichnung zurückzuführen sind. Ein TCP-Fehler darf nicht allein anhand einer Anwendungsmeldung wie „Timeout“ oder „Connection reset“ eingeordnet werden. Er muss mit Socketzuständen, Zeitpunkten, Protokollen und bei Bedarf einer begrenzten Paketaufzeichnung korreliert werden. --- **Sicherheits- und Wirkungsklassen** | Kennzeichnung | Bedeutung | |---|---| | **LESEND** | Erfasst ausschließlich vorhandene Zustände. | | **NETZAKTIV** | Erzeugt Netzwerkverkehr zum geprüften Ziel. | | **SENSITIV** | Kann interne Adressen, Verbindungen oder Nutzdaten sichtbar machen. | | **ÄNDERND** | Verändert Konfiguration oder Laufzeitzustand. | | **AUSFALLRISIKO** | Kann Verbindungen, Prozesse oder Dienste beeinträchtigen. | Paketaufzeichnungen können enthalten: - interne und externe IP-Adressen; - Portnummern; - Hostnamen; - Anwendungsdaten; - Authentifizierungsinformationen; - Cookies oder Tokens; - unverschlüsselte Nutzdaten; - Zertifikatsinformationen; - Kommunikationsbeziehungen. Aufzeichnungen müssen technisch und zeitlich begrenzt, geschützt gespeichert und nach Abschluss der Diagnose kontrolliert entfernt werden. --- **Grundlegende Eigenschaften von TCP** TCP stellt Anwendungen einen zuverlässigen, geordneten und bidirektionalen Bytestrom zur Verfügung. TCP bietet unter anderem: - verbindungsorientierte Kommunikation; - Sequenznummern; - Bestätigungen; - Prüfsummen; - Wiederholungen verlorener Segmente; - Flusskontrolle; - Überlastkontrolle; - geordnete Übergabe der Daten; - kontrollierten Verbindungsabbau; - Erkennung bestimmter ungültiger oder nicht mehr existierender Verbindungen. TCP stellt keine Anwendungsnachrichten bereit. Eine Anwendung übergibt einen Bytestrom. Die Aufteilung in einzelne TCP-Segmente kann sich während der Übertragung ändern. Folgende Annahmen sind deshalb falsch: ```text Eine TCP-Verbindung entspricht einer Anfrage. Ein TCP-Segment entspricht einer Anwendungsnachricht. Ein ACK bedeutet, dass die Anwendung die Daten verarbeitet hat. Ein erfolgreicher Handshake bedeutet, dass HTTP, TLS oder die Anwendung funktioniert. ``` Ein TCP-ACK bestätigt grundsätzlich, dass die TCP-Implementierung der Gegenstelle die entsprechenden Bytes angenommen hat. Es beweist nicht, dass: - die Anwendung die Bytes gelesen hat; - die Anwendung die Anfrage verstanden hat; - Daten auf einen Datenträger geschrieben wurden; - eine Transaktion erfolgreich abgeschlossen wurde; - eine Anwendungsantwort erzeugt wurde. --- **TCP-Verbindung eindeutig bestimmen** Eine TCP-Verbindung wird durch ihre Endpunkte unterschieden: ```text Transportprotokoll lokale IP-Adresse lokaler Port entfernte IP-Adresse entfernter Port ``` Beispiel: ```text Client: 192.0.2.100:53124 Server: 192.0.2.25:443 ``` Die Verbindung kann kompakt dargestellt werden als: ```text 192.0.2.100:53124 → 192.0.2.25:443 ``` Auf der Serverseite ist dieselbe Verbindung aus umgekehrter Perspektive sichtbar: ```text lokal: 192.0.2.25:443 remote: 192.0.2.100:53124 ``` Bei NAT, Load Balancern oder Proxys können sich Adressen und Ports entlang des Pfads verändern. Paketaufzeichnungen auf verschiedenen Seiten müssen deshalb anhand von: - Zeitpunkt; - Richtung; - TCP-Flags; - Sequenznummern; - Nutzdaten; - übersetzten Adressen und Ports korreliert werden. --- **Wichtige TCP-Flags** | Flag | Bedeutung | |---|---| | `SYN` | Synchronisiert Sequenznummern und beginnt normalerweise den Verbindungsaufbau. | | `ACK` | Das Bestätigungsfeld ist gültig. | | `FIN` | Der Sender hat keine weiteren Daten mehr zu senden. | | `RST` | Verbindung zurücksetzen oder ungültige Verbindung ablehnen. | | `PSH` | Kennzeichnet Daten für eine zeitnahe Weitergabe innerhalb des TCP-Datenstroms. | | `URG` | Das Urgent-Pointer-Feld ist relevant. | | `ECE` | Wird im Zusammenhang mit Explicit Congestion Notification verwendet. | | `CWR` | Signalisiert eine reduzierte Congestion Window nach ECN. | `PSH` definiert keine Anwendungsnachricht und garantiert keine bestimmte Paketgröße oder sofortige Verarbeitung durch die Anwendung. --- **Verbindungsaufbau zwischen Client und Server** Der reguläre TCP-Verbindungsaufbau wird als Three-Way Handshake bezeichnet. ```text Client Server CLOSED LISTEN | | | SYN, Seq=x | |------------------------------------------>| | | | SYN, ACK, Seq=y, Ack=x+1 | |<------------------------------------------| | | | ACK, Ack=y+1 | |------------------------------------------>| | | ESTABLISHED ESTABLISHED ``` Die drei logischen Schritte sind: 1. Der Client sendet ein Segment mit `SYN`. 2. Der Server bestätigt das Client-SYN und sendet sein eigenes SYN mit `SYN, ACK`. 3. Der Client bestätigt das Server-SYN mit `ACK`. Das dritte Segment kann abhängig von Anwendung und TCP-Erweiterungen bereits Daten enthalten. Für die grundlegende Diagnose wird es dennoch als dritter Handshake-Schritt betrachtet. --- **Sequenznummern beim Handshake** Beispiel: ```text Client → Server: SYN Seq = 1000 Server → Client: SYN, ACK Seq = 7000 Ack = 1001 Client → Server: ACK Seq = 1001 Ack = 7001 ``` Ein SYN verbraucht eine Sequenznummer. Deshalb bestätigt der Server: ```text 1000 + 1 = 1001 ``` Auch das SYN des Servers verbraucht eine Sequenznummer. Der Client bestätigt: ```text 7000 + 1 = 7001 ``` Die tatsächlich verwendeten Initial Sequence Numbers werden von den TCP-Implementierungen bestimmt und sind nicht als einfache fortlaufende Werte vorhersehbar. --- **TCP-Zustände während des Verbindungsaufbaus** | Zustand | Bedeutung | |---|---| | `CLOSED` | Es besteht keine TCP-Verbindung. | | `LISTEN` | Der Server wartet auf neue Verbindungsanfragen. | | `SYN-SENT` | Ein SYN wurde gesendet; eine passende Antwort steht aus. | | `SYN-RECEIVED` | SYN wurde empfangen und mit SYN/ACK beantwortet; abschließendes ACK steht aus. | | `ESTABLISHED` | Der Handshake ist abgeschlossen. | Eine große Zahl von Verbindungen in `SYN-SENT` kann bedeuten: - Zieladresse nicht erreichbar; - Zielport wird gefiltert; - Rückweg ist fehlerhaft; - Server antwortet nicht; - SYN/ACK wird verworfen; - falsche IPv4- oder IPv6-Adresse; - Überlastung oder Ressourcenproblem; - ausgehende Verbindung wird lokal blockiert. Viele Einträge in `SYN-RECEIVED` können bedeuten: - abschließende ACKs erreichen den Server nicht; - Rückweg vom Server zum Client funktioniert, Hinweg des ACKs jedoch nicht; - Clients brechen den Aufbau ab; - SYN-Flood oder ungewöhnlich viele unvollständige Verbindungsversuche; - vorgeschaltete Systeme oder Health Checks öffnen Verbindungen nicht vollständig; - Serverwarteschlangen oder Ressourcen sind erschöpft. Ein einzelner kurz sichtbarer Zustand `SYN-SENT` oder `SYN-RECEIVED` ist normal. Entscheidend sind Häufigkeit, Dauer und Vergleich mit einer Baseline. --- **TCP-Optionen während des Handshakes** Wichtige Optionen werden typischerweise in SYN-Segmenten angeboten oder ausgehandelt. | Option | Zweck | |---|---| | `MSS` | Maximale TCP-Nutzdatenmenge, die die jeweilige Seite in einem Segment empfangen möchte. | | `Window Scale` | Erweitert die darstellbare TCP-Empfangsfenstergröße. | | `SACK Permitted` | Erlaubt Selective Acknowledgment. | | `Timestamps` | Unterstützt unter anderem RTT-Messungen und Schutzmechanismen gegen alte Segmente. | | `ECN` | Ermöglicht Überlastsignalisierung ohne zwingenden Paketverlust, sofern der Pfad sie unterstützt. | Bei der Diagnose müssen die SYN- und SYN/ACK-Optionen verglichen werden. Zu prüfen sind: - bietet der Client eine MSS an? - bietet der Server eine abweichende MSS an? - wird Window Scaling angeboten? - wird SACK unterstützt? - werden TCP-Timestamps verwendet? - verschwinden Optionen zwischen Client und Server? - verändert eine Firewall oder Optimierungskomponente SYN-Pakete? - unterscheiden sich erfolgreiche und fehlerhafte Verbindungen? Ein Handshake kann trotz unterschiedlicher angebotener Optionen erfolgreich sein. Die Optionen können jedoch das spätere Übertragungsverhalten beeinflussen. --- **Erfolgreicher TCP-Handshake** Eine normale Paketfolge ist: ```text Client → Server SYN Server → Client SYN, ACK Client → Server ACK ``` Dieser Befund beweist: - der Client konnte ein SYN senden; - das SYN erreichte einen antwortenden TCP-Endpunkt; - eine SYN/ACK-Antwort erreichte den Client; - das abschließende ACK konnte gesendet werden; - die TCP-Verbindung wurde mindestens kurzfristig aufgebaut. Dieser Befund beweist nicht: - dass TLS funktioniert; - dass das richtige Zertifikat geliefert wird; - dass HTTP antwortet; - dass der virtuelle Host stimmt; - dass die Anwendung gesund ist; - dass Authentifizierung funktioniert; - dass eine Datenbankanfrage verarbeitet wird; - dass die Verbindung dauerhaft stabil bleibt. --- **SYN ohne Antwort** Typischer Paketbefund: ```text Client → Server SYN Client → Server SYN erneut Client → Server SYN erneut ... Timeout ``` Mögliche Ursachen: - Zielhost ist nicht erreichbar; - Routing ist fehlerhaft; - lokale Firewall verwirft das SYN; - Netzwerkfirewall verwirft das SYN; - Zielport wird still verworfen; - SYN erreicht den Server nicht; - Server-SYN/ACK wird auf dem Rückweg verworfen; - falsche Zieladresse; - falsche Adressfamilie; - NAT-Zuordnung fehlt; - Load Balancer besitzt kein erreichbares Frontend; - Server oder Zwischenkomponente ist überlastet; - Paketaufzeichnung wurde am falschen Punkt durchgeführt. Aus einer alleinigen Clientaufzeichnung kann nicht sicher geschlossen werden, ob das SYN den Server erreicht hat. Dafür wird eine korrelierte Aufzeichnung am Server oder an einem geeigneten Zwischenpunkt benötigt. --- **SYN wird mit Reset beantwortet** Typischer Paketbefund: ```text Client → Server SYN Server → Client RST, ACK ``` Typische Einordnung: - Zielhost ist erreichbar; - auf dem angesprochenen Endpunkt existiert häufig kein passender Listener; - das Betriebssystem oder eine Zwischenkomponente lehnt die Verbindung aktiv ab; - eine Firewall kann mit einem Reset ablehnen; - ein Load Balancer besitzt möglicherweise kein verwendbares Backend; - Portweiterleitung zeigt auf einen geschlossenen Zielport. Eine Anwendung meldet in diesem Fall häufig: ```text Connection refused Verbindung abgelehnt No connection could be made because the target machine actively refused it ``` Die Meldung beweist nicht, dass der eigentliche Zielserver selbst den Reset erzeugt hat. Firewalls, Proxys und Load Balancer können ebenfalls TCP-Reset-Segmente erzeugen. --- **Server sendet SYN/ACK, erhält aber kein ACK** Typischer Befund am Server: ```text Client → Server SYN Server → Client SYN, ACK Server → Client SYN, ACK erneut Server → Client SYN, ACK erneut ... ``` Mögliche Ursachen: - SYN/ACK erreicht den Client nicht; - Clientfirewall verwirft die Antwort; - asymmetrischer Rückweg; - NAT-Zustand ist fehlerhaft; - Client sendet das ACK über einen anderen Pfad; - Quelladressprüfung verwirft das Paket; - Clientprozess wurde beendet; - fehlerhafte oder unvollständige Paketaufzeichnung; - Zwischenkomponente verwirft das abschließende ACK. Zur Eingrenzung werden Aufzeichnungen auf Client- und Serverseite benötigt. --- **Handshake funktioniert nur teilweise** | Paketbefund | Einordnung | |---|---| | kein SYN sichtbar | Anwendung startet keinen TCP-Aufbau oder Aufzeichnungspunkt ist falsch | | SYN sichtbar, keine Antwort | Filterung, Routing, Verlust oder fehlender Rückweg | | SYN gefolgt von RST | aktive Ablehnung | | SYN/ACK wird wiederholt | abschließendes ACK fehlt | | Handshake vollständig, danach keine Daten | Anwendung wartet, Protokollmissverständnis oder falsche Rolle | | Handshake vollständig, danach RST | Anwendung, Betriebssystem oder Zwischenkomponente bricht ab | | Handshake vollständig, danach FIN | kontrollierte Beendigung | | Handshake vollständig, TLS beginnt und stoppt | TLS- oder Anwendungsproblem, nicht TCP-Verbindungsaufbau | --- **Die kontrollierte Datenübertragung bei TCP** Nach dem Handshake können beide Seiten Daten senden. TCP arbeitet als bidirektionaler Bytestrom: ```text Client ⇄ Server ``` Jede Richtung besitzt eigene: - Sequenznummern; - Bestätigungen; - Empfangsfenster; - Sendepuffer; - Empfangspuffer; - Wiederholungszustände. Ein Client kann gleichzeitig Daten senden und Daten des Servers empfangen. --- **Sequenznummern bei der Datenübertragung** Beispiel: ```text Client sendet: Seq = 1001 TCP-Nutzdatenlänge = 500 Bytes ``` Der Server bestätigt als nächste erwartete Sequenznummer: ```text Ack = 1501 ``` Berechnung: ```text 1001 + 500 = 1501 ``` Die Bestätigungsnummer bezeichnet das nächste Byte, das die empfangende Seite erwartet. Wenn der Server `Ack = 1501` sendet, bestätigt er kumulativ alle Bytes bis einschließlich Sequenznummer `1500`. --- **Kumulative Bestätigungen** TCP-ACKs sind grundsätzlich kumulativ. Beispiel: ```text Segment 1: Seq 1001, Länge 500 Segment 2: Seq 1501, Länge 500 Segment 3: Seq 2001, Länge 500 ``` Wenn der Empfänger anschließend sendet: ```text Ack = 2501 ``` sind damit alle zusammenhängend empfangenen Bytes bis `2500` bestätigt. Ein fehlendes Segment kann dazu führen, dass der Empfänger weiterhin dieselbe nächste erwartete Sequenznummer bestätigt. --- **Selective Acknowledgment** Wenn SACK während des Handshakes erlaubt wurde, kann der Empfänger zusätzlich mitteilen, welche späteren Datenblöcke bereits angekommen sind. Beispiel: ```text Segment 1 angekommen Segment 2 fehlt Segment 3 angekommen Segment 4 angekommen ``` Der kumulative ACK verweist weiterhin auf Segment 2. SACK-Informationen können jedoch anzeigen, dass Segment 3 und Segment 4 bereits vorhanden sind. Dadurch muss der Sender nicht zwingend alle späteren Daten erneut übertragen. --- **Verzögerte ACKs** TCP-Implementierungen können Bestätigungen kurz verzögern, um: - mehrere empfangene Segmente gemeinsam zu bestätigen; - ACKs mit eigenen ausgehenden Daten zu kombinieren; - unnötige kleine Pakete zu reduzieren. Ein nicht sofort sichtbares ACK ist deshalb nicht automatisch ein Fehler. Entscheidend sind: - tatsächliche Verzögerungsdauer; - Wiederholungen; - Anwendungsreaktion; - Vergleich mit erfolgreichen Verbindungen; - Betriebssystem- und Protokollverhalten. --- **Flusskontrolle** Der Empfänger teilt über das TCP-Empfangsfenster mit, wie viele weitere Bytes er aufnehmen kann. Vereinfacht: ```text Sender darf nur so viele unbestätigte Daten senden, wie das angekündigte Empfangsfenster zulässt. ``` Ein kleiner werdendes Empfangsfenster kann darauf hindeuten, dass die empfangende Anwendung Daten nicht schnell genug aus dem Socket liest. Ein Empfangsfenster von null bedeutet, dass momentan kein weiterer Empfangspuffer verfügbar ist. Die ausführliche Diagnose von Zero Window und Übertragungsstillständen erfolgt auf der dafür vorgesehenen Seite zu Retransmissions, Zero Window und MTU-Problemen. --- **Überlastkontrolle** Zusätzlich zur Flusskontrolle begrenzt TCP die Sendemenge anhand des vermuteten Netzzustands. Wichtige Begriffe: | Begriff | Bedeutung | |---|---| | `cwnd` | Congestion Window des Senders | | `rwnd` | vom Empfänger angekündigtes Receive Window | | `RTT` | gemessene Round Trip Time | | `RTO` | berechneter Retransmission Timeout | | Slow Start | vorsichtige Erhöhung der Sendemenge zu Beginn oder nach bestimmten Verlusten | | Congestion Avoidance | kontrollierte Anpassung der Sendemenge | | Fast Retransmit | schnelle Wiederholung bei Verlusthinweisen | | Fast Recovery | Wiederherstellung nach bestimmten Verlustereignissen | Die tatsächlich sendbare unbestätigte Datenmenge wird unter anderem durch Empfangsfenster und Congestion Window begrenzt. --- **Retransmission Timeout** Ein Sender startet für noch nicht bestätigte Daten einen Wiederholungstimer. Der RTO wird aus gemessenen Laufzeiten und deren Schwankungen berechnet. Er ist kein fester universeller Wert. Wenn eine Bestätigung nicht rechtzeitig eintrifft: - läuft der Wiederholungstimer ab; - das betreffende Segment kann erneut gesendet werden; - der Wiederholungstimer wird typischerweise vergrößert; - die Sendegeschwindigkeit kann reduziert werden; - nach weiteren erfolglosen Versuchen kann die Verbindung aufgegeben werden. Die genaue Anzahl der Versuche und die Gesamtdauer sind abhängig von: - Betriebssystem; - TCP-Implementierung; - Verbindungsphase; - Anwendung; - Socketoptionen; - Systemkonfiguration; - Zwischenkomponenten. Es darf kein universeller TCP-Timeoutwert angenommen werden. --- **Fast Retransmit** Beim klassischen Fast-Retransmit-Verfahren können mehrere Duplicate ACKs den Sender darauf hinweisen, dass ein früheres Segment fehlt, während spätere Segmente angekommen sind. Der Sender kann das fehlende Segment wiederholen, bevor der normale RTO abläuft. Moderne TCP-Implementierungen können zusätzlich oder alternativ weitere Verlustalgorithmen und SACK-Informationen verwenden. Deshalb darf nicht jeder Fast-Retransmit ausschließlich anhand einer festen Zahl von Duplicate ACKs erklärt werden. --- **Duplicate ACKs richtig einordnen** Duplicate ACKs können entstehen durch: - tatsächlich verlorenes Segment; - Paketumordnung; - duplizierte Pakete; - verzögerte Übertragung; - unvollständige Paketaufzeichnung; - asymmetrische Aufzeichnung; - unterschiedliche Netzwerkpfade; - Captureverlust am Analysesystem. Ein Duplicate ACK ist ein Hinweis und kein alleiniger Beweis für Paketverlust. --- **TCP-Retransmissions richtig einordnen** Eine als Retransmission markierte Übertragung kann bedeuten: - ursprüngliches Segment ging im Netzwerk verloren; - Bestätigung ging verloren; - ursprüngliches Segment wurde am Aufzeichnungspunkt nicht erfasst; - Pakete trafen in anderer Reihenfolge ein; - Aufzeichnungssoftware verlor Pakete; - Daten wurden durch Offloading anders dargestellt; - Wireshark ordnete den Datenstrom heuristisch ein. Wireshark-Analysefelder wie `tcp.analysis.retransmission` sind Analyseergebnisse und keine im TCP-Paket übertragenen Flags. --- **TCP Checksum Offloading berücksichtigen** Bei einer Aufzeichnung auf dem sendenden Host kann eine TCP-Prüfsumme als fehlerhaft erscheinen, obwohl das Netzwerkpaket später korrekt übertragen wird. Mögliche Ursache: - die Netzwerkkarte berechnet die Prüfsumme erst nach dem Aufzeichnungspunkt; - TCP Segmentation Offload zerlegt große Datenblöcke erst in der Netzwerkkarte; - Generic Receive Offload oder Large Receive Offload fasst Daten zusammen. Deshalb gilt: ```text Eine lokal als fehlerhaft angezeigte TCP-Prüfsumme beweist ohne weitere Prüfung keinen Netzwerkfehler. ``` Zu vergleichen sind: - Aufzeichnung am sendenden Host; - Aufzeichnung auf einem externen Messpunkt; - Offloading-Anzeige des Analysewerkzeugs; - erfolgreiche und fehlerhafte Verbindungen. --- **TCP besitzt keine Anwendungs-Lebendigkeitsprüfung** Eine bestehende TCP-Verbindung kann im Zustand `ESTABLISHED` verbleiben, obwohl: - die Gegenstelle ausgefallen ist; - ein Kabel getrennt wurde; - eine Firewall den Sitzungszustand gelöscht hat; - der Netzwerkpfad nicht mehr funktioniert; - die Anwendung der Gegenstelle nicht mehr reagiert. Solange keine Daten übertragen oder Prüfmechanismen ausgelöst werden, erkennt TCP einen solchen Zustand nicht zwingend sofort. Mögliche zusätzliche Mechanismen sind: - TCP Keepalive; - anwendungsspezifische Heartbeats; - Request-Timeouts; - Health Checks; - Sitzungszeitüberschreitungen; - erneuter Verbindungsaufbau. Ein TCP-Keepalive beweist nur eine Reaktion des TCP-Endpunkts. Es beweist nicht automatisch, dass die Anwendung fachlich gesund ist. --- **Timeout ist nicht gleich Timeout** Die Meldung „Timeout“ kann aus verschiedenen Ebenen stammen. | Timeoutart | Phase | Typischer Befund | |---|---|---| | DNS-Timeout | vor TCP | kein SYN zum eigentlichen Server | | TCP-Connect-Timeout | Handshake | SYN bleibt unbeantwortet | | TCP-Retransmission-Timeout | Datenübertragung | unbestätigte Segmente werden wiederholt | | TLS-Handshake-Timeout | nach TCP-Aufbau | TCP steht, TLS wird nicht abgeschlossen | | Application-Read-Timeout | nach Anfrage | TCP steht, erwartete Antwort fehlt | | Application-Write-Timeout | Datenversand | Anwendung kann nicht rechtzeitig schreiben | | Proxy-Connect-Timeout | Proxy zum Backend | Client erreicht Proxy, Proxy nicht das Backend | | Proxy-Read-Timeout | Proxy wartet auf Backend | Backendverbindung besteht, Antwort dauert zu lange | | Firewall-Idle-Timeout | längere Inaktivität | Sitzungszustand der Firewall wird entfernt | | NAT-Idle-Timeout | längere Inaktivität | NAT-Zuordnung läuft ab | | Load-Balancer-Idle-Timeout | längere Inaktivität | Load Balancer verwirft inaktive Sitzung | | TCP-Keepalive-Timeout | Prüfmechanismus | Gegenstelle reagiert nicht auf Keepalive-Probes | | Anwendungsdeadline | beliebige Phase | Anwendung bricht nach eigener Gesamtfrist ab | Vor einer Änderung muss festgestellt werden, welcher Zeitgeber tatsächlich abgelaufen ist. --- **Connect-Timeout erkennen** Typischer Ablauf: ```text Anwendung startet Verbindung Client sendet SYN keine verwertbare Antwort SYN wird wiederholt Anwendung meldet Timeout ``` Zu prüfen sind: - Zeitpunkt des ersten SYN; - Anzahl und Abstand der SYN-Wiederholungen; - Zeitpunkt der Anwendungsmeldung; - kommt ein SYN/ACK oder RST an? - erreicht das SYN den Server? - erreicht die Antwort den Client? - beendet die Anwendung den Versuch vor dem TCP-Stack? - versucht die Anwendung danach eine weitere Zieladresse? Bei mehreren DNS-Adressen kann die Anwendung nacheinander oder parallel unterschiedliche Ziele versuchen. Die sichtbare Gesamtdauer muss daher nicht dem Timeout eines einzelnen TCP-Versuchs entsprechen. --- **Anwendungs-Timeout nach erfolgreichem Handshake** Typischer Ablauf: ```text SYN SYN, ACK ACK Anwendungsanfrage keine oder verspätete Anwendungsantwort Anwendung meldet Timeout ``` TCP ist in diesem Fall grundsätzlich aufgebaut. Mögliche Ursachen: - Serveranwendung verarbeitet die Anfrage zu langsam; - Backenddienst reagiert nicht; - Datenbankabfrage blockiert; - Thread- oder Workerpool ist erschöpft; - Empfangsfenster wird klein oder null; - Proxy wartet auf ein Backend; - falsches Anwendungsprotokoll; - Deadlock oder Ressourcensperre; - Antwortpakete gehen verloren; - Anwendung verwendet eine zu kurze Frist. Die Diagnose darf nicht bei einem erfolgreichen Porttest enden. --- **Idle-Timeout erkennen** Typischer Ablauf: ```text TCP-Verbindung wird erfolgreich aufgebaut Datenübertragung funktioniert Verbindung bleibt längere Zeit inaktiv erste neue Übertragung schlägt fehl eine neue TCP-Verbindung funktioniert wieder ``` Mögliche Ursachen: - Firewall hat Sessiontabelleneintrag entfernt; - NAT-Zuordnung ist abgelaufen; - Load Balancer hat die Verbindung geschlossen; - Proxy hat seine Idle-Frist erreicht; - Serveranwendung hat die Sitzung beendet; - Client verwendet eine veraltete Verbindung aus einem Connection Pool; - TCP Keepalive ist nicht aktiv oder zu spät eingestellt. Benötigter Nachweis: - genaue Dauer der Inaktivität; - Zeitpunkt der letzten erfolgreichen Datenübertragung; - Paketfolge beim ersten erneuten Sendeversuch; - Verhalten bei einer frisch aufgebauten Verbindung; - konfigurierte Idle-Timeouts aller Zwischenkomponenten; - Anwendungspool- und Keepalive-Konfiguration. --- **TCP Reset** Ein TCP-Reset wird durch das Flag `RST` signalisiert. Ein Reset bedeutet grundsätzlich: ```text Diese TCP-Verbindung soll sofort zurückgesetzt werden oder der angesprochene TCP-Zustand ist nicht gültig. ``` Im Unterschied zu einem geordneten Abbau mit `FIN` ist ein Reset ein abrupter Abbruch. Mögliche Anwendungsmeldungen: ```text Connection reset by peer ECONNRESET An existing connection was forcibly closed by the remote host Die Verbindung wurde vom Kommunikationspartner zurückgesetzt SocketException: Connection reset ``` Die Formulierung „by peer“ bedeutet nicht zwingend, dass der eigentliche Anwendungsprozess der Gegenstelle den Reset absichtlich erzeugt hat. Der Reset kann stammen von: - Betriebssystem der Gegenstelle; - Anwendung; - lokalem Betriebssystem; - Firewall; - Load Balancer; - Reverse Proxy; - NAT-Gateway; - Intrusion-Prevention-System; - Service Mesh; - Container- oder Cloudnetzkomponente. --- **Typische Ursachen eines TCP Reset** - Verbindung zu einem geschlossenen TCP-Port; - Anwendung bricht einen Socket ausdrücklich ab; - Prozess wird beendet oder stürzt ab; - Anwendung schließt mit ungelesenen Eingangsdaten; - ungültiges Segment für eine nicht mehr existierende Verbindung; - Gegenstelle hat den Verbindungszustand verloren; - Host wurde neu gestartet; - alte Verbindung wird nach längerer Inaktivität erneut verwendet; - Firewall oder Load Balancer hat den Sitzungszustand entfernt; - Proxy lehnt eine Verbindung oder Anfrage ab; - Backend ist nicht verfügbar; - Protokoll wird auf dem falschen Port verwendet; - Sicherheitskomponente beendet die Sitzung; - Verbindungslimit oder Ressourcenlimit wurde erreicht; - Zeitüberschreitung führt zu einem erzwungenen Abbruch; - fehlerhafte NAT- oder Sessionzuordnung; - Paket gehört zu einer früheren Verbindung mit wiederverwendetem Port; - Anwendung verwendet eine abortive Socket-Schließung. Nicht jede Prozessbeendigung erzeugt zwingend einen Reset. Abhängig vom Socketzustand und Betriebssystem kann auch ein kontrollierter FIN-Abbau erfolgen. --- **Reset während des Handshakes** Paketfolge: ```text Client → Server SYN Server → Client RST, ACK ``` Mögliche Einordnung: - kein Listener auf dem Zielport; - Firewall lehnt aktiv ab; - Portweiterleitung zeigt auf geschlossenen Port; - Load Balancer lehnt ab; - falsche Zieladresse; - Dienst wurde beendet; - Listener existiert nur auf einer anderen lokalen Adresse; - IPv4-/IPv6-Bindung passt nicht. Nächster Nachweis: - Listener direkt auf dem Zielsystem prüfen; - Prozessbesitzer bestimmen; - Zieladresse und Adressfamilie bestätigen; - Paketaufzeichnung auf Serverseite durchführen; - Firewall- und NAT-Pfad prüfen. --- **Reset unmittelbar nach erfolgreichem Handshake** Paketfolge: ```text SYN SYN, ACK ACK RST ``` Mögliche Ursachen: - Anwendung akzeptiert und verwirft die Verbindung sofort; - Prozess- oder Workerlimit erreicht; - Zugriffskontrolle lehnt ab; - Proxy besitzt kein Backend; - Client beendet den Socket abrupt; - Server erwartet sofortige Protokolldaten; - Health Check verwendet ein unpassendes Protokoll; - Verbindungszustand ist zwischen Komponenten inkonsistent. Zu prüfen sind: - wer sendet den Reset? - wird vor dem Reset Anwendungsnutzlast übertragen? - existiert im Serverlog eine passende Verbindung? - tritt der Fehler bei jedem Client auf? - funktioniert ein protokollspezifischer Test? --- **Reset nach Übertragung einer Anfrage** Paketfolge: ```text Handshake erfolgreich Client sendet Anfrage Server oder Zwischenkomponente sendet RST ``` Mögliche Ursachen: - ungültiges Anwendungsprotokoll; - TLS-Daten an einem Klartextport; - Klartextdaten an einem TLS-Port; - fehlerhafte oder verbotene Anfrage; - Anwendung stürzt bei der Verarbeitung ab; - Proxy oder WAF beendet die Verbindung; - maximale Anfragegröße überschritten; - Sicherheitsrichtlinie löst aus; - Backend schließt abrupt; - Server liest die Anfrage nicht vollständig; - Client sendet weiter, nachdem der Server bereits geschlossen hat. Der Inhalt unmittelbar vor dem Reset ist für die Ursachenbestimmung besonders wichtig. --- **Reset nach längerer Inaktivität** Typischer Ablauf: ```text Verbindung ist ESTABLISHED keine Übertragung über längere Zeit Client sendet neue Daten RST wird empfangen ``` Mögliche Ursache: - Zwischenkomponente hat den Sitzungszustand gelöscht; - Server hat die Verbindung lokal bereits beendet; - Anwendung verwendet einen veralteten Socket; - Connection Pool prüft die Verbindung vor Wiederverwendung nicht; - Idle-Timeouts verschiedener Komponenten sind nicht abgestimmt. Zu vergleichen sind: - TCP-Keepalive; - Anwendungsheartbeat; - Firewall-Idle-Timeout; - NAT-Timeout; - Proxy-Timeout; - Load-Balancer-Timeout; - Connection-Pool-Lebensdauer. --- **Reset nach Wiederholungen** Möglicher Ablauf: ```text Daten werden gesendet Bestätigung fehlt Daten werden wiederholt weitere Wiederholungen RST oder lokaler Verbindungsabbruch ``` Ein Reset nach Wiederholungen kann bedeuten: - Netzwerkpfad war unterbrochen; - Gegenstelle hat den Zustand verloren; - Anwendung oder Betriebssystem gibt die Verbindung auf; - eine Zwischenkomponente reagiert auf eine nicht mehr bekannte Sitzung; - Prozess wurde während des Fehlers beendet. Die zeitliche Reihenfolge muss genau ausgewertet werden. Der Reset kann Folge und nicht Ursache des ursprünglichen Problems sein. --- **Reset-Absender bestimmen** In der Clientaufzeichnung ist zunächst die Quelladresse des Reset-Segments sichtbar. Sie ist jedoch nicht immer ein eindeutiger Beweis für den tatsächlichen Erzeuger. Zwischenkomponenten können: - mit der Adresse des Servers antworten; - Verbindungen stellvertretend terminieren; - NAT-Adressen verwenden; - einen eigenen TCP-Endpunkt darstellen; - Reset-Segmente erzeugen. Belastbarer Nachweis: 1. Aufzeichnung am Client. 2. Aufzeichnung am Server. 3. Zeitliche Synchronisation beider Systeme. 4. Vergleich derselben TCP-Verbindung. 5. Prüfung, ob der Reset den Server verlässt. 6. Prüfung, ob der Server den Reset überhaupt empfängt. 7. Protokolle von Firewall, Proxy und Load Balancer korrelieren. Beispiel: ```text Client sieht einen RST. Serveraufzeichnung zeigt keinen ausgehenden RST. Firewallprotokoll zeigt eine aktive Sitzungsbeendigung. Einordnung: Der Reset wurde wahrscheinlich von der Firewall erzeugt. ``` Dies ist eine Schlussfolgerung aus mehreren Befunden und nicht allein aus der IP-Quelladresse. --- **FIN, RST und Timeout unterscheiden** | Befund | Bedeutung | |---|---| | `FIN` | Sender beendet seine Senderichtung geordnet. | | `RST` | Verbindung wird abrupt zurückgesetzt. | | Timeout | Innerhalb der erwarteten Frist kam keine verwertbare Reaktion. | | ICMP-Fehler | IP- oder Netzwerkebene meldet ein Problem. | | Anwendungsfehler | TCP kann funktionieren, während das höhere Protokoll fehlschlägt. | Ein FIN bedeutet nicht zwingend, dass die gesamte Verbindung sofort beendet ist. TCP unterstützt einen geordneten Abbau je Richtung. --- **Verbindungsabbau zwischen Client und Server** Ein regulärer TCP-Abbau besteht logisch aus: ```text Teilnehmer A Teilnehmer B ESTABLISHED ESTABLISHED | | | FIN, ACK | |------------------------------------------>| | | FIN-WAIT-1 CLOSE-WAIT | | | ACK | |<------------------------------------------| | | FIN-WAIT-2 CLOSE-WAIT | | | FIN, ACK | |<------------------------------------------| | | TIME-WAIT LAST-ACK | | | ACK | |------------------------------------------>| | | TIME-WAIT CLOSED | | nach Ablauf der Wartezeit | CLOSED ``` Dies wird häufig als Four-Way Termination bezeichnet. In einer echten Aufzeichnung müssen nicht immer vier getrennte Pakete sichtbar sein. ACK und FIN können kombiniert werden. --- **FIN verbraucht eine Sequenznummer** Wie SYN verbraucht auch FIN eine Sequenznummer. Beispiel: ```text Teilnehmer A sendet: FIN, Seq = 5000 Teilnehmer B bestätigt: ACK = 5001 ``` Das FIN signalisiert: ```text Ich werde in dieser Richtung keine weiteren Daten mehr senden. ``` Die Gegenrichtung kann abhängig vom Anwendungs- und Socketzustand noch Daten übertragen. --- **Half-Close** Bei einem Half-Close wurde nur eine Senderichtung geordnet geschlossen. Beispiel: ```text Client sendet FIN. Server bestätigt FIN. Server sendet weiterhin verbleibende Antwortdaten. Server sendet später sein eigenes FIN. ``` Half-Close ist nicht dasselbe wie eine Half-Open Connection. | Begriff | Bedeutung | |---|---| | Half-Close | Eine Richtung wurde geordnet mit FIN beendet. | | Half-Open | Beide Endpunkte besitzen unterschiedliche Vorstellungen darüber, ob die Verbindung noch existiert. | Eine Half-Open Connection kann beispielsweise entstehen, wenn ein System neu startet und den früheren TCP-Zustand verliert, während die Gegenstelle die Verbindung weiterhin als vorhanden betrachtet. --- **TCP-Zustände beim Verbindungsabbau** | Zustand | Bedeutung | |---|---| | `FIN-WAIT-1` | Lokales FIN wurde gesendet; Bestätigung oder FIN der Gegenstelle steht aus. | | `FIN-WAIT-2` | Lokales FIN wurde bestätigt; FIN der Gegenstelle steht aus. | | `CLOSE-WAIT` | FIN der Gegenstelle wurde empfangen; lokale Anwendung hat noch nicht geschlossen. | | `CLOSING` | Beide Seiten haben nahezu gleichzeitig FIN gesendet. | | `LAST-ACK` | Lokales FIN wurde nach empfangenem FIN gesendet; abschließendes ACK steht aus. | | `TIME-WAIT` | Endpunkt wartet, damit verspätete Segmente einer alten Verbindung nicht falsch zugeordnet werden. | | `CLOSED` | Verbindung ist vollständig beendet. | --- **CLOSE-WAIT richtig interpretieren** `CLOSE-WAIT` bedeutet: ```text Die Gegenstelle hat ihre Senderichtung geschlossen. Das lokale Betriebssystem wartet darauf, dass die lokale Anwendung ihren Socket schließt. ``` Viele dauerhaft vorhandene `CLOSE-WAIT`-Sockets können hinweisen auf: - Anwendung liest EOF, schließt aber nicht; - Fehler im Connection-Handling; - blockierte Threads; - fehlende Fehlerbehandlung; - Ressourcenleck; - Anwendung wartet auf einen internen Vorgang; - Prozess reagiert nicht. `CLOSE-WAIT` wird nicht durch das bloße Ändern eines TCP-Timers behoben. Zuerst müssen Prozess und Anwendungscode beziehungsweise Herstellerprotokolle geprüft werden. --- **FIN-WAIT-2 richtig interpretieren** `FIN-WAIT-2` bedeutet: ```text Die lokale Seite hat ihre Senderichtung geschlossen. Die Gegenstelle hat dies bestätigt, aber noch kein eigenes FIN gesendet. ``` Mögliche Ursachen bei ungewöhnlich langen Beständen: - Gegenanwendung hält ihre Senderichtung offen; - Anwendung wartet auf weitere Verarbeitung; - Gegenprozess reagiert nicht; - Half-Close wird absichtlich verwendet; - Netzwerk- oder Zustandsproblem. Ein kurzfristiger `FIN-WAIT-2`-Zustand ist nicht automatisch fehlerhaft. --- **TIME-WAIT richtig interpretieren** `TIME-WAIT` schützt unter anderem davor, dass verspätete Segmente einer alten Verbindung einer späteren Verbindung mit denselben Endpunkten zugeordnet werden. Viele `TIME-WAIT`-Einträge können bei folgenden Arbeitslasten normal sein: - viele kurze HTTP-Verbindungen; - häufige Health Checks; - Proxy- oder API-Aufrufe; - fehlendes oder nicht genutztes Connection Pooling; - Lasttests; - Microservice-Kommunikation. Zu prüfen sind: - Rate neuer Verbindungen; - Wiederverwendung bestehender Verbindungen; - Quellportbestand; - Verbindungslaufzeit; - Baseline; - Anwendungskonfiguration. `TIME-WAIT` darf nicht vorsorglich durch aggressive Timeränderungen beseitigt werden. --- **Windows: TCP-Zustände prüfen** **LESEND** Alle TCP-Verbindungen: ```powershell Get-NetTCPConnection | Sort-Object State, LocalPort ``` Verbindungen im Zustand `SYN-SENT`: ```powershell Get-NetTCPConnection ` -State SynSent ``` Verbindungen im Zustand `SYN-RECEIVED`: ```powershell Get-NetTCPConnection ` -State SynReceived ``` Aufgebaute Verbindungen: ```powershell Get-NetTCPConnection ` -State Established ``` `CLOSE-WAIT`: ```powershell Get-NetTCPConnection ` -State CloseWait ``` `TIME-WAIT`: ```powershell Get-NetTCPConnection ` -State TimeWait ``` Bestimmten entfernten Port prüfen: ```powershell Get-NetTCPConnection ` -RemotePort 443 | Select-Object ` LocalAddress, LocalPort, RemoteAddress, RemotePort, State, OwningProcess ``` Serververbindungen eines lokalen Ports: ```powershell Get-NetTCPConnection ` -LocalPort 443 | Select-Object ` LocalAddress, LocalPort, RemoteAddress, RemotePort, State, OwningProcess ``` Kurzlebige Zustände können zwischen zwei Abfragen verschwinden. Eine Paketaufzeichnung ist für die vollständige zeitliche Reihenfolge zuverlässiger. --- **Windows: Prozess zuordnen** **LESEND** ```powershell Get-NetTCPConnection ` -RemotePort 443 | ForEach-Object { $connection = $_ $process = Get-Process ` -Id $connection.OwningProcess ` -ErrorAction SilentlyContinue [pscustomobject]@{ LocalAddress = $connection.LocalAddress LocalPort = $connection.LocalPort RemoteAddress = $connection.RemoteAddress RemotePort = $connection.RemotePort State = $connection.State ProcessId = $connection.OwningProcess ProcessName = $process.ProcessName } } ``` Ein Prozess kann zwischen Socketabfrage und Prozessabfrage bereits beendet sein. Fehlende Prozessinformationen müssen deshalb mit Zeitpunkt und Ereignisprotokollen korreliert werden. --- **Windows: TCP-Verbindung aktiv testen** **NETZAKTIV** ```powershell Test-NetConnection ` -ComputerName "app.example.test" ` -Port 443 ` -InformationLevel Detailed ``` Wichtige Felder: - `ComputerName`; - `RemoteAddress`; - `RemotePort`; - `InterfaceAlias`; - `SourceAddress`; - `TcpTestSucceeded`. `TcpTestSucceeded = True` bestätigt einen erfolgreichen TCP-Verbindungsaufbau für diesen Versuch. Es bestätigt nicht die Funktion von TLS, HTTP oder der eigentlichen Anwendung. Getrennte Prüfung einer konkreten Adresse: ```powershell Test-NetConnection ` -ComputerName "192.0.2.25" ` -Port 443 ` -InformationLevel Detailed ``` --- **Windows: TCP-Statistiken prüfen** **LESEND** ```cmd netstat -s -p tcp ``` IPv6-TCP-Statistiken: ```cmd netstat -s -p tcpv6 ``` Verfügbare Leistungsindikatoren suchen: ```powershell Get-Counter ` -ListSet "*TCP*" ``` Die Namen der Leistungsindikatoren können von Sprache und Windows-Version abhängen. Zähler müssen über einen definierten Zeitraum als Differenz oder Rate ausgewertet werden. Ein hoher kumulierter Wert seit dem Systemstart beweist keine aktuelle Störung. --- **Windows: Paketaufzeichnung mit pktmon** `pktmon` verändert den Aufzeichnungszustand und erstellt Dateien. **SENSITIV · ÄNDERND** Vorhandene Aufzeichnung stoppen: ```cmd pktmon stop ``` Vorhandene Filter entfernen: ```cmd pktmon filter remove ``` Filter für TCP-Port `443` anlegen: ```cmd pktmon filter add TCP443 -t TCP -p 443 ``` Aufzeichnung starten: ```cmd pktmon start --capture --pkt-size 0 --file-name C:\Temp\tcp443.etl ``` Nach reproduziertem Fehler stoppen: ```cmd pktmon stop ``` In PCAPNG konvertieren: ```cmd pktmon etl2pcap C:\Temp\tcp443.etl --out C:\Temp\tcp443.pcapng ``` Temporären Filter entfernen: ```cmd pktmon filter remove ``` Voraussetzungen: - Zielverzeichnis existiert; - ausreichend freier Speicher ist vorhanden; - Aufzeichnungszeitraum ist begrenzt; - Datei wird geschützt gespeichert; - Filter und Aufzeichnungszustand werden anschließend zurückgesetzt. --- **Linux: TCP-Zustände mit ss prüfen** **LESEND** Alle TCP-Sockets: ```bash ss -tan ``` TCP-Sockets mit Prozessinformationen: ```bash sudo ss -tanp ``` `SYN-SENT`: ```bash ss -tan state syn-sent ``` `SYN-RECEIVED`: ```bash ss -tan state syn-recv ``` Aufgebaute Verbindungen: ```bash ss -tan state established ``` `CLOSE-WAIT`: ```bash ss -tan state close-wait ``` `TIME-WAIT`: ```bash ss -tan state time-wait ``` Erweiterte TCP-Informationen für Zielport `443`: ```bash sudo ss -tin \ 'dport = :443' ``` Erweiterte Informationen für einen lokalen Serverport: ```bash sudo ss -tin \ 'sport = :443' ``` Je nach Zustand und Kernel können erweiterte Angaben enthalten sein: - RTT; - RTO; - Congestion Window; - Retransmissions; - Sendemenge; - Empfangsmenge; - Window Scaling; - MSS; - Timer. Die konkrete Ausgabe hängt von Kernel und TCP-Zustand ab. --- **Linux: TCP-Zähler prüfen** **LESEND** ```bash nstat -az ``` Bestimmte Zähler: ```bash nstat -az TcpRetransSegs ``` ```bash nstat -az TcpAttemptFails ``` ```bash nstat -az TcpEstabResets ``` Zusätzliche klassische Statistik: ```bash netstat -s ``` Zu beachten: - Zähler sind häufig kumulativ; - ein Reset-Zähler nennt nicht automatisch die betroffene Anwendung; - Container oder Netzwerk-Namespaces können eigene Sichten besitzen; - für eine aktuelle Störung sind Vorher-Nachher-Differenzen notwendig. --- **macOS: TCP-Zustände prüfen** **LESEND** ```bash netstat -anv -p tcp ``` TCP-Verbindungen mit Prozesszuordnung: ```bash sudo lsof -nP -iTCP ``` Aufgebaute TCP-Verbindungen: ```bash sudo lsof \ -nP \ -iTCP \ -sTCP:ESTABLISHED ``` Interaktive TCP-Ansicht: ```bash nettop -m tcp ``` TCP-Statistiken: ```bash netstat -s -p tcp ``` Kurzlebige Handshakezustände können auch unter macOS leichter mit einer Paketaufzeichnung als mit wiederholten Socketabfragen erfasst werden. --- **Aktive Tests unter Linux und macOS** TCP-Porttest: **NETZAKTIV** ```bash nc -vz app.example.test 443 ``` Linux mit begrenzter Wartezeit, abhängig von der installierten `nc`-Variante: ```bash nc -vz -w 5 app.example.test 443 ``` macOS mit TCP-Verbindungsfrist: ```bash nc -vz -G 5 app.example.test 443 ``` HTTP- oder HTTPS-Test mit getrennten Fristen: ```bash curl \ --connect-timeout 5 \ --max-time 15 \ -v \ https://app.example.test/ ``` Bedeutung: - `--connect-timeout` begrenzt die Verbindungsphase; - `--max-time` begrenzt den gesamten Aufruf. Ein Fehler nach erfolgreicher `Connected`-Meldung ist kein reiner TCP-Connect-Fehler mehr. --- **Paketaufzeichnung unter Linux** **SENSITIV · LESEND** Auf Port `443` begrenzen: ```bash sudo tcpdump \ -ni any \ 'tcp port 443' \ -c 200 ``` Auf einen Host und Port begrenzen: ```bash sudo tcpdump \ -ni any \ 'host 192.0.2.25 and tcp port 443' \ -c 200 ``` Mit ausführlicheren TCP-Informationen in Datei schreiben: ```bash sudo tcpdump \ -ni any \ -s 0 \ -w /tmp/tcp443.pcap \ 'host 192.0.2.25 and tcp port 443' ``` Nach reproduziertem Fehler mit `Strg+C` beenden. Die Datei enthält möglicherweise sensible Daten und muss anschließend geschützt ausgewertet und kontrolliert entfernt werden. --- **Paketaufzeichnung unter macOS** Verwendbare Schnittstellen anzeigen: ```bash tcpdump -D ``` Auf einer konkreten Schnittstelle: ```bash sudo tcpdump \ -ni en0 \ 'host 192.0.2.25 and tcp port 443' \ -c 200 ``` Lokale Loopback-Verbindung: ```bash sudo tcpdump \ -ni lo0 \ 'tcp port 8080' \ -c 200 ``` In Datei schreiben: ```bash sudo tcpdump \ -ni en0 \ -s 0 \ -w /tmp/tcp443.pcap \ 'host 192.0.2.25 and tcp port 443' ``` --- **Wireshark-Filter für TCP** Bestimmter Port: ```text tcp.port == 443 ``` Bestimmte IP-Adresse und Port: ```text ip.addr == 192.0.2.25 && tcp.port == 443 ``` Nur initiale SYN-Segmente: ```text tcp.flags.syn == 1 && tcp.flags.ack == 0 ``` SYN/ACK: ```text tcp.flags.syn == 1 && tcp.flags.ack == 1 ``` Reset: ```text tcp.flags.reset == 1 ``` FIN: ```text tcp.flags.fin == 1 ``` Vermutete Wiederholungen: ```text tcp.analysis.retransmission ``` Vermuteter Fast Retransmit: ```text tcp.analysis.fast_retransmission ``` Duplicate ACKs: ```text tcp.analysis.duplicate_ack ``` Zero Window: ```text tcp.analysis.zero_window ``` Ein bestimmter TCP-Datenstrom: ```text tcp.stream == 7 ``` Die Nummer des TCP-Streams wird von Wireshark innerhalb der geöffneten Aufzeichnung vergeben und ist keine übertragene Protokollnummer. --- **Aufzeichnung richtig planen** Vor Beginn sind festzulegen: ```text Client: Server: Port: Zeitfenster: Testhandlung: Aufzeichnungspunkte: Erwartete Paketfolge: Fehlerkriterium: ``` Die Systemzeiten der beteiligten Geräte müssen ausreichend synchron sein. Anderenfalls können Client-, Server-, Firewall- und Proxyprotokolle nicht zuverlässig korreliert werden. --- **Aufzeichnung am Client und Server vergleichen** | Clientaufzeichnung | Serveraufzeichnung | Mögliche Einordnung | |---|---|---| | SYN sichtbar | SYN nicht sichtbar | Fehler vor dem Server | | SYN sichtbar | SYN sichtbar | Hinweg funktioniert | | kein SYN/ACK am Client | SYN/ACK verlässt Server | Rückweg oder Filterung | | RST am Client | RST verlässt Server | Server oder Serveranwendung wahrscheinlich beteiligt | | RST am Client | kein RST am Server | Zwischenkomponente wahrscheinlich beteiligt | | Daten am Client gesendet | Daten erreichen Server | Hinweg der Daten funktioniert | | ACK fehlt am Client | ACK verlässt Server | Rückwegproblem | | Server erhält ACK nicht | Client sendet ACK | Filterung oder asymmetrischer Pfad | | FIN auf beiden Seiten | FIN verlässt ursprünglichen Sender | kontrollierter Abbau | | unterschiedliche Paketfolgen | Übersetzung oder Verlust | NAT, Proxy, Capturepunkt oder Netzwerkpfad prüfen | --- **NAT, Firewall, Proxy und Load Balancer berücksichtigen** Eine Ende-zu-Ende-Verbindung kann tatsächlich aus mehreren getrennten TCP-Verbindungen bestehen. Beispiel mit Reverse Proxy: ```text Client → TCP-Verbindung 1 → Reverse Proxy → TCP-Verbindung 2 → Backend ``` Ein Reset zwischen Proxy und Backend muss nicht als Reset zwischen Proxy und Client weitergegeben werden. Der Proxy kann stattdessen eine HTTP-Fehlerantwort erzeugen. Beispiel mit NAT: ```text Client intern: 192.0.2.100:53124 NAT extern: 203.0.113.10:62000 Server: 198.51.100.25:443 ``` Zu prüfen sind: - übersetzte Quelladresse; - übersetzter Quellport; - Sessiontabelleneintrag; - Ablaufzeit; - Rückweg; - Verbindung zum Backend; - getrennte Timeouts je TCP-Abschnitt; - welcher Abschnitt den Reset enthält. --- **Container und Kubernetes berücksichtigen** Eine TCP-Verbindung kann durch mehrere Netzwerk-Namespaces laufen: ```text Client → Hostport → Container-Netzwerk → Containersocket ``` oder: ```text Client → Load Balancer → Kubernetes-Service → Pod-IP → Anwendungscontainer ``` Zu prüfen sind: - Handshake am externen Endpunkt; - Handshake zum Backend; - Listener im Container oder Pod; - Host- und Containerport; - Service-`port` und `targetPort`; - Sidecar- oder Service-Mesh-Verbindung; - NetworkPolicy; - Readiness und EndpointSlices; - Reset innerhalb des Pods; - Reset am Ingress oder Gateway. Ein erfolgreicher Handshake zum Load Balancer beweist keinen erfolgreichen Handshake zum Backend. --- **Typische Fehlermeldungen einordnen** | Meldung | Mögliche TCP-Einordnung | |---|---| | `Connection refused` | häufig Reset als Antwort auf SYN | | `Connection timed out` | Handshake oder Datenübertragung ohne rechtzeitige Antwort | | `Connection reset by peer` | gültiger Reset wurde empfangen | | `Broken pipe` | Schreiben auf bereits geschlossene Verbindung | | `EOF` | Gegenstelle hat den Datenstrom beendet | | `Operation timed out` | Frist der Anwendung oder Bibliothek abgelaufen | | `No route to host` | Routing- oder lokal gemeldeter Erreichbarkeitsfehler | | `Network is unreachable` | keine verwendbare Route | | `TLS handshake timeout` | TCP möglicherweise erfolgreich, TLS nicht abgeschlossen | | `Read timed out` | Verbindung steht, erwartete Daten fehlen | | `Write timed out` | Daten konnten nicht innerhalb der Frist geschrieben werden | Der genaue Wortlaut hängt von Betriebssystem, Programmiersprache, Bibliothek und Anwendung ab. --- **Hypothese und Gegenbeweis** Beispiel für einen Connect-Timeout: ```text Hypothese: Eine Netzwerkfirewall verwirft die SYN-Pakete zum TCP-Port 443. Erwarteter Befund: Der Client sendet wiederholt SYN-Pakete. Der Server empfängt diese SYN-Pakete nicht. Es wird weder SYN/ACK noch RST empfangen. Gegenbeweis: Die Serveraufzeichnung zeigt das eingehende SYN und ein ausgehendes SYN/ACK. Testmethode: Zeitgleich begrenzte Paketaufzeichnung auf Client und Server. Erfolgskriterium: Der genaue Punkt des Paketverlusts ist eingegrenzt. Risiko: Die Aufzeichnung enthält interne Verbindungsdaten und muss geschützt werden. ``` Beispiel für einen Reset: ```text Hypothese: Der Reverse Proxy erzeugt den Reset, weil kein Backend verfügbar ist. Erwarteter Befund: Der Client-Handschlag mit dem Proxy ist erfolgreich. Der Proxy kann keine Verbindung zum Backend aufbauen. Der Client empfängt anschließend einen Reset. Das Backend empfängt keinen Verbindungsversuch oder lehnt ihn ab. Gegenbeweis: Der Backend-Handschlag ist erfolgreich und der Reset verlässt nachweislich das Backend. Testmethode: Aufzeichnungen und Protokolle an Client, Proxy und Backend korrelieren. ``` --- **Kontrollierte Maßnahmen** | Maßnahme | Voraussetzung | Risiko | |---|---|---| | Listener starten oder Bindung korrigieren | Reset wegen fehlendem Listener bestätigt | geänderte Erreichbarkeit | | Firewallregel korrigieren | Paketverlust an der Firewall nachgewiesen | unbeabsichtigte Freigabe | | Rückweg korrigieren | asymmetrischer oder fehlender Rückweg bestätigt | weitere Netze können betroffen sein | | NAT-Zuordnung korrigieren | falsche Übersetzung bestätigt | bestehende Sitzungen werden beeinflusst | | Proxy-Backend korrigieren | fehlerhafter Backendpfad nachgewiesen | produktiver Datenverkehr wird umgeleitet | | Idle-Timeout abstimmen | Sitzungsablauf nach Inaktivität bestätigt | mehr Sitzungszustand und Ressourcenverbrauch | | Connection-Pool-Lebensdauer anpassen | Wiederverwendung veralteter Verbindungen bestätigt | mehr neue Verbindungen | | Anwendungs-Timeout anpassen | Verarbeitung dauert legitim länger und Ursache ist bekannt | Fehler werden eventuell später erkannt | | TCP-Keepalive gezielt konfigurieren | verwaiste Idle-Verbindungen bestätigt | zusätzlicher Netzwerkverkehr | | Anwendung korrigieren | `CLOSE-WAIT`, abortives Schließen oder Absturz bestätigt | Dienstneustart oder Deployment erforderlich | | Backendkapazität erhöhen | Ressourcenengpass nachgewiesen | Kosten und Betriebsänderung | | Protokoll oder Zielport korrigieren | falsches Protokoll beziehungsweise falscher Port bestätigt | Clientkonfiguration ändert sich | Timeouts dürfen nicht pauschal verlängert werden, um Paketverlust, Deadlocks oder überlastete Backends zu verdecken. --- **Systematischer Diagnoseablauf** 1. Exakte Anwendungsmeldung aufnehmen. 2. Datum, Uhrzeit und Zeitzone dokumentieren. 3. Client, Server, Zielname und Zielport bestimmen. 4. Verwendete IP-Adresse und Adressfamilie erfassen. 5. Transportprotokoll bestätigen. 6. Erwarteten Listener auf dem Server prüfen. 7. Besitzenden Prozess bestimmen. 8. Lokalen TCP-Test am Server durchführen. 9. TCP-Test vom betroffenen Client durchführen. 10. Socketzustand während des Versuchs beobachten. 11. Prüfen, ob ein SYN erzeugt wird. 12. Prüfen, ob der Server das SYN empfängt. 13. Prüfen, ob SYN/ACK oder RST zurückgesendet wird. 14. Prüfen, ob das abschließende ACK ankommt. 15. Bei erfolgreichem Handshake Anwendungsdaten prüfen. 16. Connect- und Anwendungs-Timeout unterscheiden. 17. FIN und RST unterscheiden. 18. Reset-Richtung und Reset-Zeitpunkt bestimmen. 19. Client-, Server- und Zwischenprotokolle korrelieren. 20. Retransmissions und Duplicate ACKs auswerten. 21. Captureverlust und Offloading berücksichtigen. 22. NAT-, Firewall- und Proxyzustand prüfen. 23. Load Balancer und Backendverbindung getrennt prüfen. 24. Container- und Netzwerk-Namespace berücksichtigen. 25. Idle-Phase und Timeoutwerte dokumentieren. 26. Frische und wiederverwendete Verbindung vergleichen. 27. Hypothese und Gegenbeweis formulieren. 28. Genau eine kontrollierte Maßnahme durchführen. 29. Identischen Verbindungsversuch wiederholen. 30. Anwendungsprotokoll vollständig verifizieren. 31. Weitere repräsentative Clients prüfen. 32. Temporäre Filter und Aufzeichnungen entfernen. 33. Ursache, Maßnahme und Prävention dokumentieren. --- **Befundmatrix** | Befund | Mögliche Einordnung | Nächster Nachweis | |---|---|---| | kein SYN sichtbar | Anwendung, DNS oder lokaler Socketaufruf | Anwendungstrace und Zieladresse | | SYN wiederholt, keine Antwort | Drop, Routing oder Rückweg | serverseitige Aufzeichnung | | SYN erreicht Server nicht | Netzpfad vor dem Server | Zwischenpunkte und Firewalllogs | | SYN erreicht Server, kein SYN/ACK | lokaler Filter, kein Listener oder Überlastung | Socketliste und Servertrace | | SYN wird mit RST beantwortet | aktive Ablehnung | Reset-Erzeuger und Listener prüfen | | SYN/ACK verlässt Server, erreicht Client nicht | Rückweg oder Filterung | Client- und Firewallaufzeichnung | | SYN/ACK wird wiederholt | abschließendes ACK fehlt | Clientaufzeichnung | | Handshake vollständig | TCP-Connect funktioniert | Anwendungsprotokoll prüfen | | Handshake vollständig, keine Nutzdaten | Anwendung wartet oder startet Anfrage nicht | Anwendungstrace | | Anfrage gesendet, keine Antwort | Backend oder Anwendung langsam | Server- und Backendprotokolle | | RST direkt nach Handshake | Anwendung oder Zwischenkomponente lehnt ab | Reset-Sender und Logs | | RST nach Anfrage | Protokoll-, Anwendungs- oder Sicherheitsfehler | Daten vor dem Reset auswerten | | RST nach langer Inaktivität | Idle-Timeout oder veralteter Socket | Timeoutwerte und frische Verbindung | | FIN nach Anfrage | kontrollierte Schließung | Anwendungsergebnis prüfen | | viele `CLOSE-WAIT` | lokale Anwendung schließt nicht | Prozess- und Threadanalyse | | viele `TIME-WAIT` | viele kurzlebige Verbindungen | Verbindungsrate und Pooling | | viele `SYN-SENT` | Ziele antworten nicht | Ziel- und Pfadvergleich | | viele `SYN-RECEIVED` | Handshake bleibt unvollständig | Serverwarteschlange und Clientpfad | | Retransmissions nur in einer Capturedatei | Captureverlust oder Offloading möglich | zweiter Aufzeichnungspunkt | | frische Verbindung funktioniert | alte Verbindung fehlerhaft | Idle- und Poolingverhalten | | Porttest funktioniert, TLS scheitert | TCP funktioniert, TLS fehlerhaft | TLS-Handshake analysieren | | nur große Übertragung stockt | Verlust, Window oder MTU möglich | Folgeseite zu Retransmissions und MTU | | nur ein Backend erzeugt Resets | Backend- oder Pfadproblem | direkte Backendtests | | Reset am Client, nicht am Server | Zwischenkomponente wahrscheinlich | Firewall-, Proxy- und LB-Protokolle | --- **Typische Diagnosefehler** - Anwendungstimeout und TCP-Timeout gleichsetzen. - Einen erfolgreichen Ping als TCP-Nachweis verwenden. - Einen offenen TCP-Port als vollständigen Anwendungsnachweis bewerten. - Nur `Test-NetConnection` oder `nc` verwenden. - DNS-Zeit und TCP-Verbindungszeit vermischen. - Nur auf dem Client aufzeichnen. - Aus einer fehlenden Clientantwort schließen, dass der Server nichts gesendet hat. - Aus der RST-Quelladresse sicher auf den Erzeuger schließen. - Firewall, Proxy oder Load Balancer als Reset-Erzeuger ignorieren. - FIN und RST gleich behandeln. - `CLOSE-WAIT` durch Änderung von TCP-Timern beheben wollen. - `TIME-WAIT` pauschal als Fehler bewerten. - Wiederholungen ohne Sequenznummern und ACKs auswerten. - Duplicate ACKs automatisch als Paketverlust bewerten. - Wireshark-Analysemarkierungen als echte TCP-Flags interpretieren. - Checksum-Offloading ignorieren. - Captureverlust am Analysesystem ignorieren. - IPv4 und IPv6 nicht getrennt prüfen. - Client- und Serverzeit nicht synchronisieren. - NAT-Adressen und ursprüngliche Adressen verwechseln. - Proxyverbindung und Backendverbindung als eine einzige TCP-Verbindung behandeln. - Host-, Container- und Pod-Namespace verwechseln. - Veraltete Verbindung aus einem Pool nicht berücksichtigen. - Idle-Timeout ohne Messung vermuten. - Timeout pauschal erhöhen. - TCP Keepalive als Nachweis der Anwendungsgesundheit betrachten. - Firewall vollständig deaktivieren. - Prozess vorsorglich beenden. - Server vorsorglich neu starten. - mehrere Einstellungen gleichzeitig verändern. - Paketaufzeichnung ohne Filter laufen lassen. - sensible Capturedateien ungeschützt speichern. - nach der Maßnahme nur einen einzelnen erfolgreichen Versuch prüfen. --- **Verifikation** Nach einer Maßnahme müssen mindestens folgende Punkte geprüft werden: - Zielname wird zur richtigen Adresse aufgelöst; - richtige IPv4- oder IPv6-Adresse wird verwendet; - erwarteter TCP-Listener ist vorhanden; - richtiger Prozess besitzt den Listener; - SYN erreicht den Server; - SYN/ACK erreicht den Client; - abschließendes ACK erreicht den Server; - TCP-Verbindung erreicht `ESTABLISHED`; - keine unerwarteten Reset-Segmente entstehen; - Daten werden in beiden Richtungen übertragen; - ACKs bestätigen die erwarteten Sequenzbereiche; - Retransmissionsrate entspricht der Baseline; - Anwendung antwortet innerhalb der vorgesehenen Frist; - TLS funktioniert, sofern vorgesehen; - Proxy erreicht sein Backend; - Load Balancer verwendet gesunde Backends; - NAT- und Firewallzustand bleiben während der Sitzung bestehen; - wiederverwendete Verbindungen funktionieren; - Verhalten nach repräsentativer Inaktivität ist korrekt; - Verbindung wird kontrolliert beendet; - keine dauerhaft wachsenden `CLOSE-WAIT`-Bestände entstehen; - `TIME-WAIT`-Bestand ist zur Arbeitslast plausibel; - mehrere aufeinanderfolgende Versuche funktionieren; - weitere repräsentative Clients funktionieren; - temporäre Capturefilter wurden entfernt; - Aufzeichnungen wurden geschützt oder kontrolliert gelöscht; - Ursache, Maßnahme und Prävention wurden dokumentiert. Ein einzelner erfolgreicher Three-Way Handshake ist keine vollständige Verifikation der Anwendung. --- **Dokumentationsvorlage** ```text Störung: Zeitpunkt: Client: Server: Zielname: Zielport: Adressfamilie: Anwendung: Exakte Fehlermeldung: Verwendete Quelladresse: Verwendete Zieladresse: Listener: Handshake-Befund: Socketzustände: Anwendungsdaten: Timeoutart: Timeoutdauer: Reset-Absender: Nachweis des Reset-Absenders: Retransmissions: FIN-Befund: Zwischenkomponenten: Nachgewiesene Ursache: Gegenbeweis ausgeschlossen durch: Durchgeführte Maßnahme: Risiko und Rückweg: Verifikation: Prävention: ``` --- **Checkliste** - [ ] exakte Fehlermeldung dokumentiert - [ ] Datum, Uhrzeit und Zeitzone erfasst - [ ] Client und Server bestimmt - [ ] Zielname dokumentiert - [ ] Zieladresse dokumentiert - [ ] Quelladresse dokumentiert - [ ] Quell- und Zielport erfasst - [ ] IPv4 und IPv6 unterschieden - [ ] TCP-Listener geprüft - [ ] Prozessbesitzer bestimmt - [ ] lokalen TCP-Test durchgeführt - [ ] entfernten TCP-Test durchgeführt - [ ] SYN sichtbar - [ ] SYN/ACK oder RST ausgewertet - [ ] abschließendes ACK geprüft - [ ] Zustand `SYN-SENT` berücksichtigt - [ ] Zustand `SYN-RECEIVED` berücksichtigt - [ ] Zustand `ESTABLISHED` bestätigt - [ ] TCP-Optionen bei Bedarf verglichen - [ ] MSS geprüft - [ ] Window Scaling berücksichtigt - [ ] SACK-Unterstützung berücksichtigt - [ ] Anwendungsdaten nach dem Handshake geprüft - [ ] Sequenz- und Bestätigungsnummern ausgewertet - [ ] Retransmissions geprüft - [ ] Duplicate ACKs berücksichtigt - [ ] Captureverlust ausgeschlossen - [ ] Checksum-Offloading berücksichtigt - [ ] Connect-Timeout bestimmt - [ ] Anwendungs-Timeout bestimmt - [ ] TLS-Timeout bei Bedarf berücksichtigt - [ ] Proxy-Timeout bei Bedarf berücksichtigt - [ ] Idle-Timeout berücksichtigt - [ ] frische Verbindung getestet - [ ] wiederverwendete Verbindung getestet - [ ] TCP Keepalive bei Bedarf geprüft - [ ] RST-Richtung bestimmt - [ ] Reset-Absender eingegrenzt - [ ] FIN und RST unterschieden - [ ] Verbindungsabbau geprüft - [ ] `CLOSE-WAIT` berücksichtigt - [ ] `FIN-WAIT-2` berücksichtigt - [ ] `TIME-WAIT` berücksichtigt - [ ] Clientaufzeichnung durchgeführt - [ ] Serveraufzeichnung durchgeführt - [ ] Firewallprotokolle korreliert - [ ] NAT-Zustand berücksichtigt - [ ] Proxy und Backend getrennt geprüft - [ ] Load Balancer berücksichtigt - [ ] Container- oder Pod-Namespace berücksichtigt - [ ] Hypothese formuliert - [ ] Gegenbeweis festgelegt - [ ] Risiko und Rückweg dokumentiert - [ ] nur eine kontrollierte Maßnahme durchgeführt - [ ] identischen Test wiederholt - [ ] Anwendungsprotokoll verifiziert - [ ] weitere repräsentative Clients geprüft - [ ] temporäre Filter entfernt - [ ] Capturedateien geschützt oder entfernt - [ ] Ursache und Prävention dokumentiert --- **Schnellreferenz** | Aufgabe | Befehl oder Filter | |---|---| | Windows-TCP-Verbindungen | `Get-NetTCPConnection` | | Windows `SYN-SENT` | `Get-NetTCPConnection -State SynSent` | | Windows `SYN-RECEIVED` | `Get-NetTCPConnection -State SynReceived` | | Windows `ESTABLISHED` | `Get-NetTCPConnection -State Established` | | Windows `CLOSE-WAIT` | `Get-NetTCPConnection -State CloseWait` | | Windows `TIME-WAIT` | `Get-NetTCPConnection -State TimeWait` | | Windows-TCP-Test | `Test-NetConnection -ComputerName -Port -InformationLevel Detailed` | | Windows-TCP-Statistik | `netstat -s -p tcp` | | Windows-Paketmonitor | `pktmon` | | Linux-TCP-Sockets | `ss -tan` | | Linux-TCP-Details | `sudo ss -tin` | | Linux `SYN-SENT` | `ss -tan state syn-sent` | | Linux `SYN-RECEIVED` | `ss -tan state syn-recv` | | Linux `ESTABLISHED` | `ss -tan state established` | | Linux `CLOSE-WAIT` | `ss -tan state close-wait` | | Linux `TIME-WAIT` | `ss -tan state time-wait` | | Linux-TCP-Zähler | `nstat -az` | | macOS-TCP-Sockets | `netstat -anv -p tcp` | | macOS-Prozesszuordnung | `sudo lsof -nP -iTCP` | | macOS-Liveansicht | `nettop -m tcp` | | TCP-Porttest | `nc -vz ` | | HTTP-/HTTPS-Test | `curl --connect-timeout 5 --max-time 15 -v ` | | Linux-Aufzeichnung | `sudo tcpdump -ni any 'tcp port ' -c 200` | | macOS-Aufzeichnung | `sudo tcpdump -ni 'tcp port ' -c 200` | | Wireshark: Port | `tcp.port == ` | | Wireshark: initiales SYN | `tcp.flags.syn == 1 && tcp.flags.ack == 0` | | Wireshark: SYN/ACK | `tcp.flags.syn == 1 && tcp.flags.ack == 1` | | Wireshark: Reset | `tcp.flags.reset == 1` | | Wireshark: FIN | `tcp.flags.fin == 1` | | Wireshark: Retransmission | `tcp.analysis.retransmission` | | Wireshark: Fast Retransmit | `tcp.analysis.fast_retransmission` | | Wireshark: Duplicate ACK | `tcp.analysis.duplicate_ack` | | Wireshark: TCP-Stream | `tcp.stream == ` | --- **Befehle und Maßnahmen, die nicht unkontrolliert als erste Diagnose verwendet werden dürfen** ```text Stop-Process taskkill Stop-Service Restart-Service netsh int ip reset netsh winsock reset Set-NetFirewallRule New-NetFirewallRule Deaktivieren der Windows-Firewall kill kill -9 systemctl stop systemctl restart sysctl -w iptables nft ufw disable firewall-cmd --permanent docker restart docker stop kubectl delete kubectl rollout restart pauschales Erhöhen aller Timeouts aggressives Verkürzen von TIME-WAIT unkontrolliertes Aktivieren oder Ändern von TCP Keepalive Deaktivieren von TCP-Offloading ohne Vergleichstest Neustart von Firewall, Proxy oder Load Balancer ``` Ein Neustart kann TCP-Zustände, Sessiontabellen und den für die Diagnose wichtigen Ausgangszustand zerstören. --- **Quellen** **Standards** - [RFC 9293 – Transmission Control Protocol](https://datatracker.ietf.org/doc/html/rfc9293) - [RFC 1122 – Requirements for Internet Hosts – Communication Layers](https://datatracker.ietf.org/doc/html/rfc1122) - [RFC 5681 – TCP Congestion Control](https://datatracker.ietf.org/doc/html/rfc5681) - [RFC 6298 – Computing TCP's Retransmission Timer](https://datatracker.ietf.org/doc/html/rfc6298) - [RFC 7323 – TCP Extensions for High Performance](https://datatracker.ietf.org/doc/html/rfc7323) - [RFC 2018 – TCP Selective Acknowledgment Options](https://datatracker.ietf.org/doc/html/rfc2018) - [RFC 2883 – An Extension to the Selective Acknowledgement Option](https://datatracker.ietf.org/doc/html/rfc2883) - [RFC 5961 – Improving TCP's Robustness to Blind In-Window Attacks](https://datatracker.ietf.org/doc/html/rfc5961) **Offizielle Microsoft-Dokumentation** - [Microsoft Learn – Get-NetTCPConnection](https://learn.microsoft.com/en-us/powershell/module/nettcpip/get-nettcpconnection) - [Microsoft Learn – Test-NetConnection](https://learn.microsoft.com/en-us/powershell/module/nettcpip/test-netconnection) - [Microsoft Learn – netstat](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/netstat) - [Microsoft Learn – Packet Monitor](https://learn.microsoft.com/en-us/windows-server/networking/technologies/pktmon/pktmon) - [Microsoft Learn – pktmon filter add](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/pktmon-filter-add) - [Microsoft Learn – Troubleshoot TCP/IP connectivity](https://learn.microsoft.com/en-us/troubleshoot/windows-client/networking/tcp-ip-connectivity-issues-troubleshooting) - [Microsoft Learn – Guidance for troubleshooting TCP/IP communication](https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/troubleshoot-tcp-ip-communication-guidance) **Offizielle Linux-Dokumentation** - [Linux man-pages – ss(8)](https://man7.org/linux/man-pages/man8/ss.8.html) - [Linux man-pages – tcp(7)](https://man7.org/linux/man-pages/man7/tcp.7.html) - [Linux man-pages – tcpdump(8)](https://man7.org/linux/man-pages/man8/tcpdump.8.html) - [Linux Kernel Documentation – SNMP counters](https://docs.kernel.org/networking/snmp_counter.html) **Offizielle Wireshark-Dokumentation** - [Wireshark User’s Guide – TCP Analysis](https://www.wireshark.org/docs/wsug_html_chunked/ChAdvTCPAnalysis.html) - [Wireshark Display Filter Reference – TCP](https://www.wireshark.org/docs/dfref/t/tcp.html) - [Wireshark User’s Guide](https://www.wireshark.org/docs/wsug_html/) Für diese Seite wurden keine Community-Berichte oder Social-Media-Aussagen als technische Nachweise verwendet. # 9.3 UDP-Diagnose und ICMP-Fehlermeldungen **Ziel dieser Seite** Diese Seite beschreibt die systematische Diagnose von UDP-Kommunikation und zugehörigen ICMP- beziehungsweise ICMPv6-Fehlermeldungen. Nach der Bearbeitung muss unterschieden werden können: - ob ein lokaler UDP-Endpunkt vorhanden ist; - welcher Prozess den UDP-Port besitzt; - ob ein Datagramm den Client tatsächlich verlässt; - ob es den vorgesehenen Server erreicht; - ob die Serveranwendung das Datagramm verarbeitet; - ob eine Antwort erzeugt und zurückgesendet wird; - ob eine Firewall, NAT-Instanz oder andere Zwischenkomponente eingreift; - ob eine ICMP-Fehlermeldung zurückkommt; - ob ein Port geschlossen oder lediglich nicht eindeutig prüfbar ist; - ob Paketgröße, Fragmentierung oder Path MTU beteiligt sind; - ob Unicast, Broadcast oder Multicast verwendet wird; - ob der richtige Host-, Container- oder Pod-Namespace untersucht wird. UDP besitzt keinen Handshake und keine integrierte Empfangsbestätigung. Ein erfolgreich abgesendetes Datagramm beweist deshalb nicht, dass es den Zielhost oder die Zielanwendung erreicht hat. --- **Sicherheits- und Wirkungsklassen** | Kennzeichnung | Bedeutung | |---|---| | **LESEND** | Erfasst ausschließlich vorhandene Zustände. | | **NETZAKTIV** | Erzeugt Netzwerkverkehr zum geprüften Ziel. | | **SENSITIV** | Kann interne Adressen, Verbindungen oder Nutzdaten sichtbar machen. | | **ÄNDERND** | Verändert Konfiguration oder Laufzeitzustand. | | **AUSFALLRISIKO** | Kann Verbindungen, Dienste oder Netzwerkkomponenten beeinträchtigen. | UDP-Dienste dürfen nur mit gültigen, erwarteten und autorisierten Anfragen getestet werden. Unkontrollierte oder sehr schnelle UDP-Anfragen können: - Dienste überlasten; - Rate Limits auslösen; - Intrusion-Detection-Systeme alarmieren; - Verstärkungsangriffe begünstigen; - große Antwortmengen erzeugen; - produktive Protokollzustände beeinflussen. --- **Grundlegende Eigenschaften von UDP** UDP ist ein minimales, nachrichtenorientiertes Transportprotokoll. UDP bietet: - Quell- und Zielport; - Datagrammgrenzen; - Längenfeld; - Prüfsumme; - geringen Protokolloverhead; - Unicast-, Broadcast- und Multicast-Kommunikation. UDP bietet selbst nicht: - Verbindungsaufbau; - Verbindungsabbau; - Empfangsbestätigung; - Sequenznummern; - automatische Wiederholung; - Reihenfolgegarantie; - Duplikatschutz; - Flusskontrolle; - Überlastkontrolle; - Sitzungserkennung; - zuverlässige Erkennung einer ausgefallenen Gegenstelle. Eine Anwendung oder ein über UDP betriebenes Protokoll kann solche Funktionen selbst implementieren. Beispiele sind: - DNS mit eigenen Wiederholungen und TCP-Fallback; - QUIC mit eigener Zuverlässigkeit und Überlastkontrolle; - anwendungsspezifische Sequenznummern; - Zeitstempel; - Request-IDs; - Heartbeats; - Bestätigungsdatagramme. --- **TCP und UDP vergleichen** | Merkmal | TCP | UDP | |---|---|---| | Verbindungsaufbau | Three-Way Handshake | kein Handshake | | Datenmodell | Bytestrom | einzelne Datagramme | | Bestätigung | TCP-ACK | nicht in UDP enthalten | | Reihenfolge | durch TCP sichergestellt | nicht sichergestellt | | Wiederholung | durch TCP | nur durch Anwendung | | Flusskontrolle | vorhanden | nicht vorhanden | | Überlastkontrolle | vorhanden | nicht in UDP selbst | | Verbindungszustände | unter anderem `LISTEN`, `ESTABLISHED` | keine entsprechenden TCP-Zustände | | Reaktion bei geschlossenem Port | normalerweise TCP Reset | möglicherweise ICMP Port Unreachable | | Porttest | TCP-Handshake liefert klares Ergebnis | ohne Protokollantwort häufig mehrdeutig | Ein Test von TCP-Port `53` beweist nicht, dass UDP-Port `53` funktioniert. Umgekehrt beweist eine erfolgreiche UDP-DNS-Abfrage nicht automatisch, dass DNS über TCP funktioniert. --- **UDP-Header** Der UDP-Header besitzt vier Felder: ```text Quellport Zielport Länge Prüfsumme ``` Die Mindestlänge eines UDP-Datagramms beträgt acht Byte, weil der UDP-Header selbst acht Byte groß ist. | Feld | Größe | Bedeutung | |---|---:|---| | Source Port | 16 Bit | Port des Senders | | Destination Port | 16 Bit | Port des Empfängers | | Length | 16 Bit | Gesamtlänge von UDP-Header und UDP-Nutzdaten | | Checksum | 16 Bit | Prüfsumme über relevante IP-, UDP- und Nutzdatenfelder | UDP enthält keine Felder für: - Sequenznummer; - Bestätigungsnummer; - Empfangsfenster; - SYN; - FIN; - RST. Bei IPv4 kann eine UDP-Prüfsumme gemäß der ursprünglichen UDP-Spezifikation als nicht verwendet gekennzeichnet sein. Bei IPv6 ist eine gültige UDP-Prüfsumme grundsätzlich erforderlich; nur eng definierte Sonderfälle besitzen Ausnahmen. --- **UDP-Kommunikation eindeutig bestimmen** Ein UDP-Datagramm wird durch folgende Angaben eingeordnet: ```text Quell-IP-Adresse Quellport Ziel-IP-Adresse Zielport Transportprotokoll UDP ``` Beispiel: ```text Client: 192.0.2.100:53124 Server: 192.0.2.53:53 ``` Anfrage: ```text 192.0.2.100:53124 → 192.0.2.53:53 UDP ``` Antwort: ```text 192.0.2.53:53 → 192.0.2.100:53124 UDP ``` Eine Stateful Firewall oder NAT-Instanz kann diese Angaben verwenden, um einen zeitlich begrenzten Pseudo-Sitzungszustand zu verwalten. UDP selbst erzeugt diesen Zustand nicht. --- **UDP besitzt keinen Listenerzustand wie TCP** Werkzeuge sprechen bei UDP teilweise trotzdem von „Listening“, weil ein Prozess einen UDP-Endpunkt gebunden hat. Technisch bedeutet der Befund: ```text Ein UDP-Socket ist an eine lokale Adresse und einen lokalen Port gebunden. ``` Der Befund beweist nicht: - dass eine bestimmte Anfrage korrekt formatiert ist; - dass die Anwendung das Datagramm liest; - dass die Anwendung antwortet; - dass der Rückweg funktioniert; - dass die Firewall den Datenverkehr erlaubt; - dass NAT die Antwort richtig zuordnet; - dass der Dienst auf Anwendungsebene gesund ist. --- **Verbundener UDP-Socket** Eine Anwendung kann einen UDP-Socket mit einer Gegenstelle „verbinden“. Dieser Vorgang führt nicht zu einem Netzwerk-Handshake. Das Betriebssystem kann dadurch lediglich: - eine Standardzieladresse hinterlegen; - eingehende Datagramme auf eine Gegenstelle begrenzen; - bestimmte ICMP-Fehler dem Socket zuordnen; - normale `send`- und `receive`-Aufrufe ermöglichen. Ein als verbunden dargestellter UDP-Socket beweist deshalb keine erreichbare Gegenstelle. --- **Was ein erfolgreicher send-Aufruf beweist** Wenn eine Anwendung ein UDP-Datagramm erfolgreich an das Betriebssystem übergibt, bedeutet das zunächst: ```text Der lokale Netzwerkstack hat das Datagramm zur Übertragung angenommen. ``` Es beweist nicht: - dass die Netzwerkkarte es gesendet hat; - dass es die lokale Firewall passiert hat; - dass es den Zielhost erreicht hat; - dass ein Prozess am Zielport lauscht; - dass die Zielanwendung es verarbeitet hat; - dass eine Antwort erzeugt wurde; - dass die Antwort den Client erreicht. Für einen belastbaren Nachweis sind Protokollantwort, Serverprotokoll oder korrelierte Paketaufzeichnung notwendig. --- **Erwarteten UDP-Ablauf festlegen** Vor der Diagnose müssen mindestens folgende Angaben dokumentiert werden: ```text Anwendung: Quellhost: Zielhost: Quellport: Zielport: Adressfamilie: Anfrage: Erwartete Antwort: Timeout: Kommunikationsart: Zwischenkomponenten: ``` Bei einem Protokoll ohne Antwort muss der Nachweis auf der Empfängerseite erfolgen. --- **UDP-Diagnose benötigt ein protokollspezifisches Werkzeug** Ein allgemeiner UDP-Test kann häufig nur ein Datagramm senden. Er kann nicht sicher bestimmen, ob ein beliebiger UDP-Dienst korrekt arbeitet. Geeignete Tests sind beispielsweise: | Protokoll | Geeigneter Nachweis | |---|---| | DNS | gültige DNS-Abfrage mit `Resolve-DnsName` oder `dig` | | NTP | gültige Zeitabfrage mit vorgesehenem NTP-Werkzeug | | SNMP | gültige, autorisierte SNMP-Abfrage | | TFTP | kontrollierter TFTP-Protokolltest | | Syslog | Empfang im vorgesehenen Logziel bestätigen | | RADIUS | autorisierter Test mit passendem RADIUS-Werkzeug | | QUIC/HTTP/3 | HTTP/3-fähiger Client und Serverprotokolle | | anwendungsspezifisches UDP | Herstellerclient, Testfunktion oder definierte Testnachricht | Ein zufälliges oder leeres Datagramm kann von einem korrekt funktionierenden Dienst absichtlich ignoriert werden. --- **DNS als UDP-Diagnosebeispiel** Windows: **NETZAKTIV** ```powershell Resolve-DnsName ` -Name "example.test" ` -Type A ` -Server "192.0.2.53" ` -DnsOnly ``` Linux und macOS: ```bash dig \ @192.0.2.53 \ example.test \ A ``` Vergleich über TCP: ```bash dig \ @192.0.2.53 \ example.test \ A \ +tcp ``` Auswertung: | UDP | TCP | Mögliche Einordnung | |---|---|---| | funktioniert | funktioniert | beide Transportwege grundsätzlich nutzbar | | fehlerhaft | funktioniert | UDP-Filterung, Fragmentierung, EDNS oder MTU möglich | | funktioniert | fehlerhaft | TCP-Port, Firewall oder TCP-Listener prüfen | | beide fehlerhaft | beide Pfade oder DNS-Dienst betroffen | Server, Zone, Routing und Firewall prüfen | Der Vergleich ist protokollspezifisch. Er darf nicht auf beliebige UDP-Dienste übertragen werden. --- **Allgemeine UDP-Porttests richtig bewerten** Ein Aufruf wie: ```bash nc -vzu 192.0.2.53 53 ``` liefert bei UDP keinen gleichwertigen Nachweis wie ein erfolgreicher TCP-Handshake. Mögliche Ergebnisse ohne Antwort: - Port ist geöffnet, aber die Anwendung ignoriert die ungültige Anfrage; - Port wird gefiltert; - Datagramm erreicht den Server nicht; - Antwort erreicht den Client nicht; - ICMP-Fehler wird gefiltert; - Zielhost ist ausgefallen; - Anwendung antwortet grundsätzlich nicht; - Werkzeug interpretiert fehlende Antwort als möglichen Erfolg. `nc -u` darf deshalb nur zum gezielten Erzeugen eines autorisierten Datagramms verwendet werden. Für die Funktionsprüfung ist ein protokollspezifischer Test erforderlich. --- **Windows: UDP-Endpunkte erfassen** **LESEND** Alle UDP-Endpunkte: ```powershell Get-NetUDPEndpoint | Sort-Object LocalPort, LocalAddress ``` Bestimmten UDP-Port prüfen: ```powershell Get-NetUDPEndpoint ` -LocalPort 53 ``` Wesentliche Felder anzeigen: ```powershell Get-NetUDPEndpoint | Select-Object ` LocalAddress, LocalPort, OwningProcess | Sort-Object LocalPort, LocalAddress ``` Zu prüfen sind: - lokale Adresse; - lokaler Port; - Prozess-ID; - IPv4 oder IPv6; - Loopback-, spezifische oder Wildcard-Bindung; - mehrere Prozesse oder Endpunkte; - unerwarteter Netzwerk-Namespace. --- **Windows: Prozess eines UDP-Endpunkts bestimmen** **LESEND** ```powershell Get-NetUDPEndpoint ` -LocalPort 53 | ForEach-Object { $endpoint = $_ $process = Get-Process ` -Id $endpoint.OwningProcess ` -ErrorAction SilentlyContinue [pscustomobject]@{ LocalAddress = $endpoint.LocalAddress LocalPort = $endpoint.LocalPort ProcessId = $endpoint.OwningProcess ProcessName = $process.ProcessName ProcessPath = $process.Path } } ``` Einen bekannten Prozess prüfen: ```powershell Get-Process ` -Id 1234 ``` Einem Windows-Dienst zuordnen: ```powershell $processId = 1234 Get-CimInstance ` -ClassName Win32_Service ` -Filter "ProcessId = $processId" | Select-Object ` Name, DisplayName, State, StartMode, ProcessId, PathName ``` --- **Windows: UDP mit netstat prüfen** **LESEND** ```cmd netstat -ano -p udp ``` Die Ausgabe zeigt unter anderem: - lokale Adresse; - lokalen Port; - Prozess-ID. UDP besitzt dabei keinen TCP-Zustand wie `LISTENING` oder `ESTABLISHED`. Numerische Darstellung ist für die erste Diagnose vorzuziehen, damit keine Namensauflösung die Ausgabe verändert oder verzögert. --- **Windows: UDP-Statistiken prüfen** **LESEND** IPv4: ```cmd netstat -s -p udp ``` IPv6: ```cmd netstat -s -p udpv6 ``` Verfügbare Leistungsindikatoren: ```powershell Get-Counter ` -ListSet "*UDP*" ``` Die Namen der Leistungsindikatoren können abhängig von Systemsprache und Windows-Version abweichen. Kumulative Zähler müssen über ein definiertes Zeitfenster verglichen werden. Ein hoher Gesamtwert seit dem Systemstart beweist keine aktuelle Störung. --- **Windows: Test-NetConnection ist kein UDP-Porttest** Dieser Befehl: ```powershell Test-NetConnection ` -ComputerName "192.0.2.53" ` -Port 53 ``` prüft TCP-Port `53`. Er prüft nicht UDP-Port `53`. Folgende Schlussfolgerung ist daher unzulässig: ```text TcpTestSucceeded = True also funktioniert UDP-Port 53. ``` Für UDP muss ein passendes Anwendungsprotokoll verwendet oder der Datenweg mit einer Paketaufzeichnung nachgewiesen werden. --- **Windows: UDP-Test mit PortQry** PortQry ist ein separat bereitzustellendes Microsoft-Diagnosewerkzeug und nicht auf jedem Windows-System vorinstalliert. **NETZAKTIV** ```cmd portqry.exe -n 192.0.2.53 -p UDP -e 53 ``` Mögliche Einordnung: | PortQry-Ergebnis | Bedeutung | |---|---| | `LISTENING` | PortQry hat eine verwertbare Protokollantwort erhalten. | | `NOT LISTENING` | PortQry hat typischerweise ICMP Port Unreachable erhalten. | | `LISTENING OR FILTERED` | Es kam keine eindeutige Antwort; geöffnet und still oder gefiltert sind nicht unterscheidbar. | Für einige bekannte Protokolle sendet PortQry speziell formatierte Anfragen. Bei beliebigen UDP-Diensten bleibt ein fehlendes Ergebnis mehrdeutig. PortQry darf nur gegen autorisierte Zielsysteme eingesetzt werden. --- **Linux: UDP-Endpunkte mit ss prüfen** **LESEND** Gebundene UDP-Endpunkte: ```bash sudo ss -lunp ``` Alle UDP-Sockets: ```bash sudo ss -uanp ``` Bestimmten lokalen Port prüfen: ```bash sudo ss -lunp \ 'sport = :53' ``` Ausgabe ohne Prozessinformationen: ```bash ss -lun ``` Wichtige Felder: - lokale Adresse; - lokaler Port; - Prozess; - Empfangswarteschlange; - Sendewarteschlange; - IPv4 oder IPv6. Prozessinformationen können erhöhte Berechtigungen erfordern. --- **Linux: Prozess mit lsof bestimmen** **LESEND** Alle UDP-Sockets: ```bash sudo lsof \ -nP \ -iUDP ``` Bestimmten UDP-Port prüfen: ```bash sudo lsof \ -nP \ -iUDP:53 ``` Prozess prüfen: ```bash ps -fp ``` Bei systemd: ```bash systemctl status ``` Ein laufender Dienst beweist nicht, dass er den erwarteten UDP-Port im richtigen Netzwerk-Namespace gebunden hat. --- **Linux: UDP-Zähler prüfen** **LESEND** Alle Netzwerkstatistiken: ```bash nstat -az ``` Ausgewählte UDP-Zähler: ```bash nstat -az UdpInDatagrams ``` ```bash nstat -az UdpNoPorts ``` ```bash nstat -az UdpInErrors ``` ```bash nstat -az UdpRcvbufErrors ``` ```bash nstat -az UdpSndbufErrors ``` Klassische Übersicht: ```bash netstat -su ``` Schnittstellenzähler: ```bash ip -s link ``` Mögliche Hinweise: | Zähler | Mögliche Einordnung | |---|---| | `UdpInDatagrams` | empfangene und zugestellte UDP-Datagramme | | `UdpNoPorts` | Datagramme für nicht belegte UDP-Ports | | `UdpInErrors` | allgemeine UDP-Empfangsfehler | | `UdpRcvbufErrors` | Empfangspuffer konnte Datagramme nicht aufnehmen | | `UdpSndbufErrors` | Sendepufferfehler | | Schnittstellen-Drops | Verlust an oder nahe der Netzwerkschnittstelle | Die genaue Zählerverfügbarkeit hängt von Kernel und Werkzeugversion ab. --- **macOS: UDP-Endpunkte prüfen** **LESEND** ```bash sudo lsof \ -nP \ -iUDP ``` Bestimmten UDP-Port prüfen: ```bash sudo lsof \ -nP \ -iUDP:53 ``` Socketübersicht: ```bash netstat -anv -p udp ``` UDP-Statistiken: ```bash netstat -s -p udp ``` Netzwerkschnittstellen: ```bash ifconfig ``` Interaktive Netzwerkansicht: ```bash nettop ``` `lsof` ist unter macOS für die Zuordnung eines UDP-Ports zu einem Prozess normalerweise geeigneter als `netstat`. --- **Empfangswarteschlange und Anwendungsgeschwindigkeit** Ein Datagramm kann den Host erreichen, aber verloren gehen, bevor die Anwendung es verarbeitet. Mögliche Ursachen: - Anwendung liest nicht schnell genug; - Empfangspuffer ist voll; - CPU-Überlastung; - Prozess hängt; - Workerpool ist erschöpft; - zu hohe Datagrammrate; - Datagramme sind größer als erwartet; - Kernel- oder Schnittstellenpuffer laufen über; - Container besitzt zu geringe Ressourcen; - Anwendung verwirft ungültige oder unerwartete Nachrichten. Benötigte Nachweise: - Paketaufzeichnung am Empfänger; - UDP- und Schnittstellenzähler; - Socketwarteschlange; - Prozess-CPU und Speicher; - Anwendungsprotokoll; - Rate und Größe der Datagramme; - Vergleich mit einer Baseline. Wenn ein Datagramm in der Paketaufzeichnung des Servers sichtbar ist, beweist das noch nicht, dass die Anwendung es aus dem Socket gelesen hat. --- **ICMP ist nicht nur Ping** ICMP dient zur Übertragung von Kontroll- und Fehlermeldungen für IP. Ping verwendet: - ICMP Echo Request; - ICMP Echo Reply. ICMP umfasst jedoch zusätzlich Meldungen wie: - Destination Unreachable; - Port Unreachable; - Time Exceeded; - Fragmentation Needed; - Packet Too Big; - Parameter Problem; - Redirect. ICMPv4 und ICMPv6 sind nicht identisch. Sie verwenden unterschiedliche Typen, Codes und Protokollmechanismen. Das vollständige Blockieren von ICMP kann Fehlerdiagnose und Path MTU Discovery beeinträchtigen. Bei IPv6 besitzt ICMPv6 darüber hinaus grundlegende Bedeutung für mehrere IPv6-Funktionen. --- **ICMP-Fehler einer UDP-Anfrage zuordnen** Eine ICMP-Fehlermeldung enthält Teile des Pakets, das den Fehler ausgelöst hat. Dadurch können Betriebssystem, Firewall oder Analysewerkzeug die Meldung beispielsweise folgender Kommunikation zuordnen: ```text 192.0.2.100:53124 → 192.0.2.53:53 UDP ``` Zu prüfen sind im eingebetteten ursprünglichen Paket: - ursprüngliche Quelladresse; - ursprüngliche Zieladresse; - UDP-Quellport; - UDP-Zielport; - Protokollnummer; - gegebenenfalls weitere Anwendungsdaten. Bei NAT muss auch die ICMP-Fehlermeldung korrekt zur ursprünglichen internen Kommunikation zurückübersetzt werden. --- **Häufige ICMPv4-Typen** | Typ | Bezeichnung | Typische Bedeutung | |---:|---|---| | `0` | Echo Reply | Antwort auf Echo Request | | `3` | Destination Unreachable | Ziel, Protokoll oder Port nicht erreichbar | | `5` | Redirect | Hinweis auf einen anderen nächsten Router | | `8` | Echo Request | Ping-Anfrage | | `11` | Time Exceeded | TTL abgelaufen oder Fragmentwiederherstellung zu langsam | | `12` | Parameter Problem | Fehler in einem IP-Headerfeld | ICMP Source Quench ist veraltet und darf nicht als moderner Überlastkontrollmechanismus verwendet werden. --- **ICMPv4 Destination Unreachable** ICMPv4 verwendet für Destination Unreachable den Typ `3`. | Code | Bedeutung | |---:|---| | `0` | Network Unreachable | | `1` | Host Unreachable | | `2` | Protocol Unreachable | | `3` | Port Unreachable | | `4` | Fragmentation Needed and DF Set | | `5` | Source Route Failed | | `9` | Network Administratively Prohibited | | `10` | Host Administratively Prohibited | | `13` | Communication Administratively Prohibited | Nicht jedes Gerät verwendet alle Codes. Firewalls können Fehler außerdem still verwerfen oder andere Meldungen erzeugen. --- **ICMPv4 Port Unreachable** Typischer Ablauf: ```text Client → Server: UDP-Datagramm an Port 9999 Server → Client: ICMP Destination Unreachable Type 3, Code 3 Port Unreachable ``` Mögliche Einordnung: - Zielhost wurde erreicht; - auf dem angesprochenen UDP-Port ist häufig kein passender Endpunkt vorhanden; - eine Firewall oder Zwischenkomponente kann die Meldung erzeugt haben; - NAT- oder Portweiterleitungsziel besitzt keinen passenden UDP-Dienst. Der genaue Erzeuger muss anhand von Aufzeichnungen und Protokollen bestimmt werden. --- **ICMPv4 Fragmentation Needed** Typischer Befund: ```text ICMP Type 3, Code 4 Fragmentation Needed and DF Set ``` Bedeutung: - ein IPv4-Paket ist für den nächsten Link zu groß; - das Paket darf aufgrund gesetztem DF-Bit nicht fragmentiert werden; - die Meldung kann eine verwendbare MTU enthalten; - der Sender muss die Paketgröße anpassen. Wenn diese ICMP-Meldung gefiltert wird, kann ein Path-MTU-Black-Hole entstehen: ```text kleine Datagramme funktionieren große Datagramme schlagen fehl keine verwertbare Fehlermeldung erreicht den Sender ``` --- **ICMPv4 Time Exceeded** ICMPv4 verwendet Typ `11`. | Code | Bedeutung | |---:|---| | `0` | TTL während der Weiterleitung abgelaufen | | `1` | Zeit für Fragmentwiederherstellung abgelaufen | TTL-Ablauf wird unter anderem von Traceroute verwendet, um Zwischenrouter sichtbar zu machen. Ein Stern in einer Traceroute-Ausgabe beweist nicht, dass der betreffende Router ausgefallen ist. Er kann ICMP-Antworten filtern oder begrenzen und trotzdem normalen Datenverkehr weiterleiten. --- **Häufige ICMPv6-Typen** | Typ | Bezeichnung | |---:|---| | `1` | Destination Unreachable | | `2` | Packet Too Big | | `3` | Time Exceeded | | `4` | Parameter Problem | | `128` | Echo Request | | `129` | Echo Reply | ICMPv6 enthält außerdem wichtige Mechanismen für IPv6. Es darf nicht pauschal wie optionaler Ping-Verkehr behandelt werden. --- **ICMPv6 Destination Unreachable** ICMPv6 verwendet Typ `1`. | Code | Bedeutung | |---:|---| | `0` | No Route to Destination | | `1` | Communication Administratively Prohibited | | `2` | Beyond Scope of Source Address | | `3` | Address Unreachable | | `4` | Port Unreachable | | `5` | Source Address Failed Ingress/Egress Policy | | `6` | Reject Route to Destination | Port Unreachable bei IPv6: ```text ICMPv6 Type 1, Code 4 ``` --- **ICMPv6 Packet Too Big** ICMPv6 verwendet: ```text Type 2, Code 0 ``` Die Meldung enthält die MTU des nächsten Links. IPv6-Router fragmentieren weitergeleitete Pakete nicht. Wenn ein Paket zu groß ist, muss der sendende Endpunkt seine Paketgröße anpassen oder selbst geeignete Fragmentierung verwenden. Das Blockieren von ICMPv6 Packet Too Big kann dazu führen, dass: - kleine UDP-Datagramme funktionieren; - größere Datagramme verschwinden; - Tunnel oder VPN-Pfade betroffen sind; - Anwendungen in Timeouts laufen; - die Ursache fälschlich beim UDP-Dienst gesucht wird. --- **ICMPv6 Time Exceeded** ICMPv6 verwendet Typ `3`. | Code | Bedeutung | |---:|---| | `0` | Hop Limit während der Weiterleitung abgelaufen | | `1` | Fragment Reassembly Time Exceeded | Das IPv6 Hop Limit entspricht funktional dem IPv4-TTL-Konzept. --- **ICMPv6 Parameter Problem** ICMPv6 verwendet Typ `4`. | Code | Bedeutung | |---:|---| | `0` | fehlerhaftes Headerfeld | | `1` | unbekannter Next-Header-Typ | | `2` | unbekannte IPv6-Option | Die Meldung kann auf das fehlerhafte Feld innerhalb des ursprünglichen Pakets verweisen. --- **Keine ICMP-Antwort ist mehrdeutig** Wenn auf ein UDP-Datagramm weder eine Anwendungsantwort noch eine ICMP-Fehlermeldung folgt, sind unter anderem möglich: - UDP-Port ist geöffnet, Anwendung antwortet aber nicht auf diese Anfrage; - Anfrage ist ungültig; - Anwendung antwortet grundsätzlich nicht; - Datagramm wurde unterwegs verworfen; - lokale Firewall verwirft es; - Netzwerkfirewall verwirft es; - Zielhost ist nicht erreichbar; - Antwortweg ist fehlerhaft; - ICMP wird gefiltert; - ICMP wird durch Rate Limiting unterdrückt; - NAT-Zustand fehlt; - Server ist überlastet; - Empfangspuffer ist voll; - Anwendung verwirft das Datagramm; - Paketaufzeichnung wurde am falschen Punkt durchgeführt. Das Ergebnis darf nicht ohne weiteren Nachweis als „Port offen“ oder „Port geschlossen“ dokumentiert werden. --- **ICMP Rate Limiting berücksichtigen** Hosts und Router können ICMP-Fehlermeldungen begrenzen. Folgen: - der erste Test liefert ICMP Port Unreachable; - spätere Tests liefern keine Meldung; - nur ein Teil der verlorenen Datagramme erzeugt ICMP; - ein UDP-Scan zeigt uneinheitliche Ergebnisse; - die Abwesenheit von ICMP wird fälschlich als Filterung interpretiert. Diagnosetests müssen mit geringer, kontrollierter Rate durchgeführt werden. --- **ICMP-Fehler müssen nicht die Anwendung erreichen** Ob eine Anwendung einen ICMP-Fehler wahrnimmt, hängt ab von: - Betriebssystem; - Socket-API; - verbundenem oder unverbundenem UDP-Socket; - Fehlerwarteschlange; - Anwendungscode; - NAT; - Firewall; - Zuordenbarkeit zum ursprünglichen Datagramm. Eine Anwendung kann deshalb einen Timeout melden, obwohl in einer Paketaufzeichnung eine ICMP-Fehlermeldung sichtbar ist. Umgekehrt kann das Betriebssystem einen Socketfehler melden, obwohl die Anwendung selbst keine ICMP-Pakete auswertet. --- **UDP, MTU und Fragmentierung** Ein UDP-Datagramm bleibt für die Anwendung eine einzelne Nachricht. Auf IP-Ebene kann das zugehörige Paket jedoch fragmentiert werden. Probleme großer UDP-Datagramme: - Verlust eines Fragments verwirft das gesamte Datagramm; - Firewalls verwerfen Fragmente; - NAT kann Fragmente nicht korrekt zuordnen; - Tunnel reduzieren die nutzbare Path MTU; - Fragmentwiederherstellung läuft in einen Timeout; - ICMP Fragmentation Needed oder Packet Too Big wird blockiert; - Anwendung besitzt keine geeignete Größenanpassung; - unterschiedliche Pfade besitzen unterschiedliche MTUs. Typischer Befund: ```text kleine Anfrage funktioniert kleine Antwort funktioniert große Antwort schlägt fehl über VPN tritt der Fehler häufiger auf Paketaufzeichnung zeigt Fragmente oder ICMP Packet Too Big ``` IP-Fragmentierung sollte nicht vorsorglich erzwungen werden. Die Anwendung muss geeignete Nachrichtengrößen und Path-MTU-Verfahren verwenden. --- **UDP und Checksummen diagnostizieren** Eine ungültige UDP-Prüfsumme kann dazu führen, dass ein Datagramm ohne Anwendungsantwort verworfen wird. Zu prüfen sind: - wird die Prüfsumme in der Aufzeichnung als gültig angezeigt? - stammt die Aufzeichnung vom sendenden Host? - ist Checksum Offloading aktiv? - zeigt eine externe Aufzeichnung denselben Befund? - steigen UDP-Checksum- oder Eingangsfehlerzähler? - tritt der Fehler nur auf einer Schnittstelle auf? Wie bei TCP kann eine lokal vor der Netzwerkkarte aufgenommene Prüfsumme scheinbar fehlerhaft sein, obwohl sie später durch die Hardware korrekt berechnet wird. Eine einzelne lokale Anzeige `Bad Checksum` ist deshalb kein ausreichender Fehlernachweis. --- **Unicast, Broadcast und Multicast unterscheiden** | Kommunikationsart | Ziel | |---|---| | Unicast | genau ein IP-Endpunkt | | Broadcast | alle geeigneten IPv4-Teilnehmer eines Broadcastbereichs | | Multicast | Mitglieder einer Multicastgruppe | Bei Broadcast und Multicast sind zusätzlich zu prüfen: - richtige Zieladresse; - richtige lokale Schnittstelle; - Broadcastberechtigung des Sockets; - Multicastgruppenmitgliedschaft; - IGMP bei IPv4; - MLD bei IPv6; - Switch-Snooping; - VLAN; - TTL beziehungsweise Hop Limit; - Routerunterstützung; - Firewallregeln; - Anwendung mit mehreren Schnittstellen; - erwartetes Antwortverhalten. Ein Dienst kann auf Unicast funktionieren und auf Broadcast oder Multicast dennoch fehlschlagen. IPv6 verwendet keinen Broadcast. Vergleichbare Aufgaben werden dort durch Multicastmechanismen umgesetzt. --- **Stateful Firewall und UDP** Eine Stateful Firewall kann für UDP einen temporären Zustand anhand des Datenflusses anlegen. Beispiel: ```text Client 192.0.2.100:53124 → Server 192.0.2.53:53 erwartete Antwort: Server 192.0.2.53:53 → Client 192.0.2.100:53124 ``` Zu prüfen sind: - Quell- und Zieladresse; - Quell- und Zielport; - UDP-Protokoll; - Richtung des ersten Datagramms; - Zustandstimer; - erwartete Antwortadresse; - erwarteter Antwortport; - NAT-Übersetzung; - asymmetrischer Rückweg; - Rate Limits. Wenn die Antwort erst nach Ablauf des Firewallzustands eintrifft, kann sie verworfen werden. --- **NAT und UDP** NAT kann eine interne Kommunikation wie folgt übersetzen: ```text intern: 192.0.2.100:53124 extern: 203.0.113.10:62000 Ziel: 198.51.100.53:53 ``` Die Antwort muss an die übersetzte Adresse und den übersetzten Port zurückkehren: ```text 198.51.100.53:53 → 203.0.113.10:62000 ``` Mögliche Fehler: - NAT-Zustand läuft zu früh ab; - Antwort verwendet unerwartete Quelladresse; - Antwort kommt von anderem Serverport; - asymmetrischer Rückweg umgeht die NAT-Instanz; - ICMP-Fehler wird nicht korrekt zurückübersetzt; - mehrere Clients kollidieren durch fehlerhafte Portzuordnung; - Portweiterleitung wurde nur für TCP eingerichtet; - interne und externe UDP-Ports stimmen nicht überein. TCP- und UDP-Portweiterleitungen müssen getrennt konfiguriert werden. --- **Load Balancer und UDP** Ein UDP-Load-Balancer kann Datagramme anhand des Flows einem Backend zuordnen. Zu prüfen sind: - Frontendadresse; - Frontendport; - Protokoll UDP; - Backendport; - Health-Check-Protokoll; - Flow-Hash; - Quellportverhalten; - UDP-Idle-Timeout; - Rückweg über denselben Load Balancer; - Direct Server Return; - Backendzustand; - Antwortquelladresse. Wenn ein Client bei jedem Datagramm einen anderen Quellport verwendet, kann ein Load Balancer unterschiedliche Backends auswählen. Ein erfolgreicher Health Check beweist nicht automatisch, dass der produktive UDP-Pfad funktioniert. --- **Docker: UDP-Veröffentlichung prüfen** Docker-Portveröffentlichungen müssen das Transportprotokoll berücksichtigen. Beispiel: ```text 53:53/udp ``` Ohne `/udp` wird eine Veröffentlichung typischerweise als TCP-Veröffentlichung behandelt. Laufende Container und Ports: **LESEND** ```bash docker ps \ --format 'table {{.Names}}\t{{.Status}}\t{{.Ports}}' ``` Portzuordnung: ```bash docker port ``` Ausführliche Konfiguration: ```bash docker inspect \ \ --format '{{json .NetworkSettings.Ports}}' ``` UDP-Endpunkt im Container: ```bash docker exec \ \ ss -lunp ``` Compose-Beispiel: ```yaml ports: - "53:53/udp" ``` Zu prüfen sind: - wurde UDP ausdrücklich veröffentlicht? - stimmt der Hostport? - stimmt der Containerport? - lauscht die Anwendung im Container? - ist sie an Loopback oder an die Containeradresse gebunden? - verwendet der Client Hostadresse oder Containeradresse? - blockiert die Hostfirewall? - existiert eine passende NAT-Regel? `EXPOSE 53/udp` im Image veröffentlicht den Port nicht automatisch auf dem Host. --- **Kubernetes: UDP-Service prüfen** Wenn `protocol` nicht angegeben wird, verwendet ein Kubernetes-Service standardmäßig TCP. Für UDP muss das Protokoll ausdrücklich passen. Beispiel: ```yaml ports: - name: dns-udp protocol: UDP port: 53 targetPort: 53 ``` Service anzeigen: ```bash kubectl get service \ \ -n \ -o yaml ``` Service beschreiben: ```bash kubectl describe service \ \ -n ``` EndpointSlices: ```bash kubectl get endpointslice \ -n \ -l kubernetes.io/service-name= \ -o wide ``` UDP-Endpunkt im Pod: ```bash kubectl exec \ -n \ \ -- ss -lunp ``` Bei mehreren Containern: ```bash kubectl exec \ -n \ \ -c \ -- ss -lunp ``` Zu prüfen sind: - `protocol: UDP`; - Service-`port`; - `targetPort`; - Pod-Endpunkt; - Service-Selektor; - EndpointSlices; - Readiness; - NetworkPolicy; - CNI-Implementierung; - NodePort oder Load Balancer; - Rückweg; - UDP-Idle-Timeout. Ein eingetragener `containerPort` erzeugt keinen UDP-Endpunkt. --- **Windows-Paketaufzeichnung mit pktmon** `pktmon` verändert den Aufzeichnungszustand und erstellt Dateien. **SENSITIV · ÄNDERND** Vorhandene Aufzeichnung stoppen: ```cmd pktmon stop ``` Vorhandene Filter entfernen: ```cmd pktmon filter remove ``` UDP-Port `53` erfassen: ```cmd pktmon filter add UDP53 -t UDP -p 53 ``` ICMPv4 ergänzen: ```cmd pktmon filter add ICMPv4 -t ICMP ``` ICMPv6 ergänzen: ```cmd pktmon filter add ICMPv6 -t ICMPV6 ``` Aufzeichnung starten: ```cmd pktmon start --capture --pkt-size 0 --file-name C:\Temp\udp53.etl ``` Nach reproduziertem Fehler stoppen: ```cmd pktmon stop ``` In PCAPNG konvertieren: ```cmd pktmon etl2pcap C:\Temp\udp53.etl --out C:\Temp\udp53.pcapng ``` Filter zurücknehmen: ```cmd pktmon filter remove ``` Das Zielverzeichnis muss vorhanden sein. Aufzeichnung, Filter und erzeugte Dateien müssen nach der Diagnose kontrolliert behandelt werden. --- **Paketaufzeichnung unter Linux** UDP und ICMP gemeinsam: **SENSITIV · LESEND** ```bash sudo tcpdump \ -ni any \ '(udp port 53) or icmp or icmp6' \ -c 200 ``` Auf bestimmte Gegenstelle begrenzen: ```bash sudo tcpdump \ -ni any \ 'host 192.0.2.53 and ((udp port 53) or icmp or icmp6)' \ -c 200 ``` In Datei schreiben: ```bash sudo tcpdump \ -ni any \ -s 0 \ -w /tmp/udp53.pcap \ 'host 192.0.2.53 and ((udp port 53) or icmp or icmp6)' ``` Nach reproduziertem Fehler mit `Strg+C` beenden. --- **Paketaufzeichnung unter macOS** Verfügbare Schnittstellen: ```bash tcpdump -D ``` Auf konkreter Schnittstelle: ```bash sudo tcpdump \ -ni en0 \ 'host 192.0.2.53 and ((udp port 53) or icmp or icmp6)' \ -c 200 ``` In Datei schreiben: ```bash sudo tcpdump \ -ni en0 \ -s 0 \ -w /tmp/udp53.pcap \ 'host 192.0.2.53 and ((udp port 53) or icmp or icmp6)' ``` Bei lokalem Verkehr muss gegebenenfalls `lo0` statt der physischen Schnittstelle verwendet werden. --- **Wireshark-Filter für UDP und ICMP** Alle UDP-Pakete: ```text udp ``` Bestimmter UDP-Port: ```text udp.port == 53 ``` Bestimmte Adresse und Port: ```text ip.addr == 192.0.2.53 && udp.port == 53 ``` ICMPv4: ```text icmp ``` ICMPv6: ```text icmpv6 ``` ICMPv4 Destination Unreachable: ```text icmp.type == 3 ``` ICMPv4 Port Unreachable: ```text icmp.type == 3 && icmp.code == 3 ``` ICMPv4 Fragmentation Needed: ```text icmp.type == 3 && icmp.code == 4 ``` ICMPv4 Time Exceeded: ```text icmp.type == 11 ``` ICMPv6 Port Unreachable: ```text icmpv6.type == 1 && icmpv6.code == 4 ``` ICMPv6 Packet Too Big: ```text icmpv6.type == 2 ``` ICMPv6 Time Exceeded: ```text icmpv6.type == 3 ``` UDP und beide ICMP-Versionen: ```text udp || icmp || icmpv6 ``` Eine ICMP-Meldung muss zusammen mit dem darin eingebetteten ursprünglichen Paket ausgewertet werden. --- **Client- und Serveraufzeichnung vergleichen** | Clientaufzeichnung | Serveraufzeichnung | Mögliche Einordnung | |---|---|---| | UDP-Anfrage sichtbar | Anfrage nicht sichtbar | Verlust oder Filterung vor dem Server | | Anfrage sichtbar | Anfrage sichtbar | Hinweg bis zum Aufzeichnungspunkt funktioniert | | keine Antwort | Anwendung protokolliert Anfrage nicht | Socket, lokaler Filter oder Anwendungsverarbeitung | | keine Antwort | Anwendung protokolliert Anfrage | Anwendung erzeugt keine oder verspätete Antwort | | Antwort verlässt Server | Antwort erreicht Client nicht | Rückweg, NAT oder Firewall | | ICMP Port Unreachable am Client | Server erzeugt ICMP | Zielport wahrscheinlich nicht gebunden | | ICMP nur am Client sichtbar | Server zeigt keine Meldung | Zwischenkomponente als Erzeuger möglich | | ICMP verlässt Server | Client erhält es nicht | Rückweg oder ICMP-Filterung | | kleine Datagramme funktionieren | große erreichen Server nicht | MTU, Fragmentierung oder Filterung | | Anfrage und Antwort sichtbar | Anwendung meldet Timeout | Socketzuordnung, Frist oder Anwendungslogik | --- **Typische UDP-Paketfolgen** **Erfolgreiche Anfrage mit Antwort** ```text Client → Server UDP-Anfrage Server → Client UDP-Antwort ``` **Geschlossener UDP-Port** ```text Client → Server UDP-Anfrage Server → Client ICMP Port Unreachable ``` **Stilles Verwerfen** ```text Client → Server UDP-Anfrage keine Antwort keine ICMP-Meldung ``` **Server verarbeitet Anfrage nicht** ```text Client → Server UDP-Anfrage Anfrage erreicht Serverschnittstelle keine Anwendungsantwort ``` **Rückwegfehler** ```text Client → Server UDP-Anfrage Server → Client UDP-Antwort Antwort erreicht Client nicht ``` **Path-MTU-Problem** ```text kleine UDP-Datagramme funktionieren großes UDP-Datagramm wird verworfen ICMP Fragmentation Needed oder Packet Too Big ``` --- **Traceroute und ICMP Time Exceeded** Traceroute nutzt schrittweise erhöhte TTL- beziehungsweise Hop-Limit-Werte. Zwischenrouter können darauf mit ICMP Time Exceeded antworten. Linux mit UDP-Probes: **NETZAKTIV** ```bash traceroute \ -U \ -p 33434 \ 192.0.2.53 ``` IPv6: ```bash traceroute \ -6 \ 2001:db8::53 ``` Die genaue Standardmethode von Traceroute hängt von Betriebssystem und Implementierung ab. Ein unvollständiger Traceroute beweist keinen vollständigen Pfadausfall. Router können: - ICMP-Antworten filtern; - Antworten begrenzen; - nur Datenverkehr weiterleiten; - für Antwort und Weiterleitung unterschiedliche Richtlinien verwenden; - auf einem asymmetrischen Rückweg antworten. --- **Hypothese und Gegenbeweis** Beispiel für einen geschlossenen UDP-Port: ```text Hypothese: Auf dem Server ist kein UDP-Endpunkt an Port 9999 gebunden. Erwarteter Befund: Die lokale Socketliste zeigt keinen UDP-Endpunkt auf Port 9999. Die Serveraufzeichnung zeigt die eingehende UDP-Anfrage. Der Server sendet ICMP Port Unreachable zurück. Gegenbeweis: Ein Prozess besitzt UDP-Port 9999 und protokolliert die eingehende Anfrage. Testmethode: Socketliste, Prozesszuordnung und korrelierte Paketaufzeichnung. Risiko: Die Anfrage erzeugt Netzwerkverkehr und muss dem erwarteten Protokoll entsprechen. ``` Beispiel für einen Rückwegfehler: ```text Hypothese: Die UDP-Antwort verlässt den Server, wird aber durch eine Firewall auf dem Rückweg verworfen. Erwarteter Befund: Die Serveraufzeichnung zeigt die ausgehende Antwort. Die Clientaufzeichnung zeigt diese Antwort nicht. Die Firewall protokolliert einen Drop für den Antwortflow. Gegenbeweis: Die Clientaufzeichnung zeigt die Antwort vollständig. Testmethode: Zeitgleiche Aufzeichnung auf Client und Server sowie Firewallprotokoll. ``` --- **Kontrollierte Maßnahmen** | Maßnahme | Voraussetzung | Risiko | |---|---|---| | UDP-Endpunkt starten oder Bindung korrigieren | fehlender Endpunkt bestätigt | geänderte Erreichbarkeit | | Firewallregel für UDP korrigieren | UDP-Drop nachgewiesen | unbeabsichtigte Freigabe | | ICMP-Regel korrigieren | benötigte Fehlermeldung wird nachweislich blockiert | zusätzliche Kontrollmeldungen werden zugelassen | | NAT-Regel um UDP ergänzen | nur TCP oder falsches Protokoll bestätigt | öffentliche Erreichbarkeit ändert sich | | UDP-Idle-Timeout abstimmen | ablaufender Sitzungszustand bestätigt | mehr Zustands- und Speicherverbrauch | | Antwortquelladresse korrigieren | falsche Quelladresse bestätigt | Routing und Dienstbindung ändern sich | | Datagrammgröße reduzieren | MTU- oder Fragmentierungsproblem bestätigt | Protokollverhalten oder Leistung ändert sich | | Receive Buffer anpassen | Pufferüberlauf nachgewiesen | höherer Speicherverbrauch | | Anwendungsgeschwindigkeit verbessern | Empfangsverlust durch Verarbeitung bestätigt | Anwendungsänderung erforderlich | | Docker-Publish auf `/udp` korrigieren | fehlende UDP-Veröffentlichung bestätigt | Container muss eventuell neu erstellt werden | | Kubernetes-Service auf UDP korrigieren | falsches Serviceprotokoll bestätigt | produktiver Servicepfad ändert sich | | Multicastmitgliedschaft korrigieren | fehlende Gruppenmitgliedschaft bestätigt | zusätzlicher Multicastempfang | | Rate Limit anpassen | legitimer Verkehr wird nachweislich begrenzt | Überlastungs- und Missbrauchsrisiko | Vor jeder Änderung sind Ausgangszustand, Risiko, Rückweg und Erfolgskriterium zu dokumentieren. --- **Systematischer Diagnoseablauf** 1. Exakte Fehlermeldung und Zeitpunkt aufnehmen. 2. Anwendung und Protokoll bestimmen. 3. Bestätigen, dass tatsächlich UDP verwendet wird. 4. Quell- und Zieladresse dokumentieren. 5. Quell- und Zielport dokumentieren. 6. IPv4 und IPv6 unterscheiden. 7. Unicast, Broadcast oder Multicast bestimmen. 8. Erwartete Anfrage und Antwort beschreiben. 9. Lokalen UDP-Endpunkt auf dem Server prüfen. 10. Besitzenden Prozess bestimmen. 11. Richtige Bindungsadresse prüfen. 12. Host-, Container- und Pod-Namespace unterscheiden. 13. Anwendungsprotokolle auf dem Server prüfen. 14. Protokollspezifischen Test vom Client durchführen. 15. UDP-Anfrage auf dem Client erfassen. 16. Prüfen, ob die Anfrage den Server erreicht. 17. Prüfen, ob die Anwendung die Anfrage verarbeitet. 18. Prüfen, ob eine Antwort erzeugt wird. 19. Prüfen, ob die Antwort den Client erreicht. 20. Quelladresse und Quellport der Antwort prüfen. 21. ICMPv4- und ICMPv6-Meldungen auswerten. 22. ICMP-Erzeuger und eingebettetes Originalpaket prüfen. 23. Stateful Firewall und UDP-Zustand prüfen. 24. NAT-Übersetzung und Rückweg prüfen. 25. Idle-Timeouts berücksichtigen. 26. UDP- und Schnittstellenzähler vergleichen. 27. Empfangspuffer und Anwendungsleistung prüfen. 28. Kleine und große gültige Datagramme vergleichen. 29. MTU, Fragmentierung und Tunnel berücksichtigen. 30. Bei Multicast Gruppenmitgliedschaft und Switch prüfen. 31. Hypothese und Gegenbeweis formulieren. 32. Genau eine kontrollierte Maßnahme durchführen. 33. Identischen Test wiederholen. 34. Anwendung und mehrere Versuche verifizieren. 35. Temporäre Aufzeichnung und Filter zurücknehmen. 36. Ursache und Prävention dokumentieren. --- **Befundmatrix** | Befund | Mögliche Einordnung | Nächster Nachweis | |---|---|---| | kein lokaler UDP-Endpunkt | Dienst fehlt oder falscher Namespace | Prozess und Dienststart prüfen | | Endpunkt nur auf Loopback | nur lokale Erreichbarkeit | Sollbindung prüfen | | Endpunkt vorhanden, Anfrage erreicht Server nicht | Netzwerk oder Firewall | Client- und Zwischenaufzeichnung | | Anfrage erreicht Server, Anwendung sieht sie nicht | Socket, Firewall oder Puffer | Prozesslog und UDP-Zähler | | Anwendung sieht Anfrage, antwortet nicht | Protokoll oder Anwendung | Anwendungslogik prüfen | | Antwort verlässt Server, erreicht Client nicht | Rückweg, NAT oder Firewall | Client- und Firewallaufzeichnung | | ICMP Port Unreachable | Zielport nicht gebunden oder aktive Ablehnung | lokale Socketliste | | ICMP Administratively Prohibited | Richtlinie blockiert | Firewall- oder Routerkonfiguration | | keine Antwort und kein ICMP | geöffnet/still oder gefiltert | serverseitige Aufzeichnung | | kleine Datagramme funktionieren | Basispfad funktioniert | größere gültige Nachricht testen | | große Datagramme scheitern | MTU, Fragmentierung oder Puffer | ICMP und Fragmente erfassen | | ICMP Fragmentation Needed | IPv4-Paket zu groß und DF gesetzt | Path MTU prüfen | | ICMPv6 Packet Too Big | IPv6-Paket überschreitet Path MTU | gemeldete MTU auswerten | | `UdpNoPorts` steigt | Datagramme erreichen ungebundene Ports | Zielport und Dienst prüfen | | `UdpRcvbufErrors` steigt | Empfangspuffer überlastet | Datenrate und Anwendung prüfen | | nur nach Inaktivität fehlerhaft | UDP-Zustand abgelaufen | Firewall-/NAT-Timeout | | neue Anfrage funktioniert sofort | alter Pseudo-Sitzungszustand fehlerhaft | Flow und Quellport vergleichen | | Docker zeigt nur TCP-Publish | UDP nicht veröffentlicht | Portkonfiguration prüfen | | Kubernetes-Service nutzt TCP | falsches Serviceprotokoll | Manifest korrigieren | | Service hat keine Endpunkte | Selektor oder Readiness | Pods und EndpointSlices | | Multicast nur auf einem Host fehlerhaft | Gruppenmitgliedschaft oder Schnittstelle | IGMP/MLD und Socket prüfen | | Wireshark zeigt Bad Checksum nur lokal | Checksum Offloading möglich | externe Aufzeichnung | | PortQry meldet `LISTENING OR FILTERED` | Ergebnis nicht eindeutig | gültiger Protokolltest und Servertrace | --- **Typische Diagnosefehler** - TCP- und UDP-Port mit derselben Nummer gleichsetzen. - `Test-NetConnection -Port` als UDP-Test verwenden. - Einen erfolgreichen Ping als UDP-Nachweis bewerten. - Einen UDP-Endpunkt als vollständigen Funktionsnachweis behandeln. - Von einem erfolgreichen send-Aufruf auf die Zustellung schließen. - `nc -u` als eindeutigen Porttest verwenden. - Eine ungültige Testnachricht an einen Dienst senden. - Aus fehlender Antwort auf einen geschlossenen oder gefilterten Port schließen. - `LISTENING OR FILTERED` als sicher geöffnet interpretieren. - ICMP ausschließlich mit Ping gleichsetzen. - Alle ICMP-Meldungen blockieren. - ICMPv4 und ICMPv6 verwechseln. - ICMP Port Unreachable nicht dem eingebetteten Paket zuordnen. - ICMP-Quelladresse ohne weiteren Nachweis als Erzeuger behandeln. - ICMP Rate Limiting ignorieren. - Nur auf dem Client aufzeichnen. - Antwortquelladresse und Antwortport nicht prüfen. - Stateful Firewallzustand bei UDP ignorieren. - UDP-Idle-Timeout nicht berücksichtigen. - TCP-Portweiterleitung als UDP-Portweiterleitung betrachten. - `/udp` bei Docker-Portveröffentlichung vergessen. - Kubernetes-`protocol` nicht prüfen. - `containerPort` als echten Endpunkt bewerten. - Container- und Host-Namespace verwechseln. - kleine und große Datagramme nicht vergleichen. - Fragmentierung und Tunnel-MTU ignorieren. - eine lokale Bad-Checksum-Anzeige ungeprüft als Fehler bewerten. - Empfangspuffer und Anwendungsleistung ignorieren. - Unicast, Broadcast und Multicast nicht unterscheiden. - Multicastgruppenmitgliedschaft nicht prüfen. - Netzwerkaufzeichnungen unbegrenzt laufen lassen. - UDP-Tests mit hoher Rate durchführen. - Firewall vorsorglich vollständig deaktivieren. - mehrere Variablen gleichzeitig verändern. - nur einen einzelnen erfolgreichen Antwortversuch verifizieren. --- **Verifikation** Nach einer Maßnahme müssen mindestens folgende Punkte geprüft werden: - der richtige UDP-Endpunkt ist vorhanden; - der richtige Prozess besitzt den Port; - richtige Bindungsadresse wird verwendet; - IPv4 funktioniert, sofern vorgesehen; - IPv6 funktioniert, sofern vorgesehen; - der Client verwendet den richtigen Zielport; - die Anfrage verlässt den Client; - die Anfrage erreicht den Server; - die Anwendung verarbeitet die Anfrage; - die Anwendung erzeugt die erwartete Antwort; - die Antwort verwendet die richtige Quelladresse; - die Antwort verwendet den richtigen Quellport; - die Antwort erreicht den Client; - keine unerwarteten ICMP-Fehler entstehen; - ICMP Fragmentation Needed oder Packet Too Big funktioniert; - kleine und repräsentativ große Datagramme funktionieren; - keine UDP-Empfangspufferfehler entstehen; - Firewallzustand bleibt ausreichend lange bestehen; - NAT übersetzt Anfrage, Antwort und ICMP korrekt; - Docker veröffentlicht ausdrücklich UDP; - Kubernetes-Service verwendet `protocol: UDP`; - `port` und `targetPort` stimmen; - EndpointSlices enthalten die vorgesehenen Pods; - Broadcast oder Multicast funktioniert, sofern erforderlich; - mehrere aufeinanderfolgende Versuche funktionieren; - ursprüngliche Anwendung funktioniert; - weitere repräsentative Clients funktionieren; - temporäre Filter wurden entfernt; - Aufzeichnungen wurden geschützt oder kontrolliert gelöscht; - Ursache, Maßnahme und Prävention wurden dokumentiert. Eine einzelne sichtbare UDP-Antwort ist keine ausreichende Verifikation für alle Clients, Paketgrößen und Netzwerkpfade. --- **Dokumentationsvorlage** ```text Störung: Zeitpunkt: Anwendung: Client: Server: Adressfamilie: Kommunikationsart: Quellport: Zielport: Erwartete Anfrage: Erwartete Antwort: UDP-Endpunkt: Clientaufzeichnung: Serveraufzeichnung: ICMP-Befund: Paketgröße: Fragmentierung: Firewallzustand: NAT-Zuordnung: Timeout: UDP-Zähler: Nachgewiesene Ursache: Gegenbeweis ausgeschlossen durch: Durchgeführte Maßnahme: Risiko und Rückweg: Verifikation: Prävention: ``` --- **Checkliste** - [ ] exakte Fehlermeldung dokumentiert - [ ] Zeitpunkt und Zeitzone erfasst - [ ] Anwendung bestimmt - [ ] UDP als Transport bestätigt - [ ] TCP und UDP unterschieden - [ ] Client und Server bestimmt - [ ] Quelladresse dokumentiert - [ ] Zieladresse dokumentiert - [ ] Quellport dokumentiert - [ ] Zielport dokumentiert - [ ] IPv4 und IPv6 unterschieden - [ ] Unicast, Broadcast oder Multicast bestimmt - [ ] erwartete Anfrage beschrieben - [ ] erwartete Antwort beschrieben - [ ] lokalen UDP-Endpunkt geprüft - [ ] Bindungsadresse geprüft - [ ] Prozessbesitzer bestimmt - [ ] Dienstzuordnung geprüft - [ ] Host-, Container- und Pod-Namespace unterschieden - [ ] protokollspezifischen Test verwendet - [ ] `Test-NetConnection` nicht als UDP-Nachweis verwendet - [ ] Clientaufzeichnung durchgeführt - [ ] Serveraufzeichnung durchgeführt - [ ] ausgehende Anfrage bestätigt - [ ] Eingang am Server bestätigt - [ ] Verarbeitung durch Anwendung bestätigt - [ ] ausgehende Antwort bestätigt - [ ] Eingang der Antwort am Client bestätigt - [ ] Antwortquelladresse geprüft - [ ] Antwortquellport geprüft - [ ] ICMPv4 geprüft - [ ] ICMPv6 geprüft - [ ] ICMP-Typ und Code dokumentiert - [ ] eingebettetes ursprüngliches Paket geprüft - [ ] ICMP-Erzeuger eingegrenzt - [ ] ICMP Rate Limiting berücksichtigt - [ ] Stateful Firewallzustand geprüft - [ ] NAT-Zuordnung geprüft - [ ] UDP-Idle-Timeout berücksichtigt - [ ] asymmetrischen Rückweg berücksichtigt - [ ] UDP-Zähler ausgewertet - [ ] Schnittstellen-Drops geprüft - [ ] Empfangspuffer geprüft - [ ] Anwendungslast geprüft - [ ] Checksum Offloading berücksichtigt - [ ] kleine Datagramme getestet - [ ] repräsentativ große Datagramme getestet - [ ] MTU berücksichtigt - [ ] Fragmentierung geprüft - [ ] ICMP Packet Too Big berücksichtigt - [ ] Docker-Protokoll bei Bedarf geprüft - [ ] Kubernetes-Serviceprotokoll bei Bedarf geprüft - [ ] EndpointSlices bei Bedarf geprüft - [ ] Multicastgruppenmitgliedschaft bei Bedarf geprüft - [ ] Hypothese formuliert - [ ] Gegenbeweis festgelegt - [ ] Risiko und Rückweg dokumentiert - [ ] nur eine kontrollierte Maßnahme durchgeführt - [ ] identischen Test wiederholt - [ ] ursprüngliche Anwendung getestet - [ ] weitere repräsentative Clients geprüft - [ ] temporäre Filter entfernt - [ ] Aufzeichnungen geschützt oder entfernt - [ ] Ursache und Prävention dokumentiert --- **Schnellreferenz** | Aufgabe | Befehl oder Filter | |---|---| | Windows-UDP-Endpunkte | `Get-NetUDPEndpoint` | | Windows-UDP-Port | `Get-NetUDPEndpoint -LocalPort ` | | Windows-UDP-netstat | `netstat -ano -p udp` | | Windows-UDP-Statistik | `netstat -s -p udp` | | Windows-UDP-PortQry | `portqry.exe -n -p UDP -e ` | | Windows-Paketmonitor | `pktmon` | | Windows-DNS-UDP-Test | `Resolve-DnsName -Name -Server -DnsOnly` | | Linux-UDP-Endpunkte | `sudo ss -lunp` | | Linux-alle UDP-Sockets | `sudo ss -uanp` | | Linux-UDP-Port | `sudo ss -lunp 'sport = :'` | | Linux-Prozess zu UDP-Port | `sudo lsof -nP -iUDP:` | | Linux-UDP-Zähler | `nstat -az` | | Linux-Schnittstellenzähler | `ip -s link` | | macOS-UDP-Sockets | `sudo lsof -nP -iUDP` | | macOS-UDP-netstat | `netstat -anv -p udp` | | macOS-UDP-Statistik | `netstat -s -p udp` | | DNS-UDP-Test | `dig @ ` | | DNS-TCP-Vergleich | `dig @ +tcp` | | Linux-Aufzeichnung | `sudo tcpdump -ni any '(udp port ) or icmp or icmp6' -c 200` | | macOS-Aufzeichnung | `sudo tcpdump -ni '(udp port ) or icmp or icmp6' -c 200` | | Wireshark UDP-Port | `udp.port == ` | | Wireshark ICMPv4 | `icmp` | | Wireshark ICMPv6 | `icmpv6` | | ICMPv4 Port Unreachable | `icmp.type == 3 && icmp.code == 3` | | ICMPv4 Fragmentation Needed | `icmp.type == 3 && icmp.code == 4` | | ICMPv4 Time Exceeded | `icmp.type == 11` | | ICMPv6 Port Unreachable | `icmpv6.type == 1 && icmpv6.code == 4` | | ICMPv6 Packet Too Big | `icmpv6.type == 2` | | ICMPv6 Time Exceeded | `icmpv6.type == 3` | --- **Befehle und Maßnahmen, die nicht unkontrolliert als erste Diagnose verwendet werden dürfen** ```text Stop-Process taskkill Stop-Service Restart-Service Set-NetFirewallRule New-NetFirewallRule Deaktivieren der Windows-Firewall netsh int ip reset netsh winsock reset kill kill -9 systemctl stop systemctl restart sysctl -w iptables nft ufw disable firewall-cmd --permanent docker restart docker stop kubectl delete kubectl rollout restart unkontrollierte UDP-Portscans UDP-Lasttests ohne Freigabe ungefilterte Broadcasts ungefilterte Multicasttests pauschales Zulassen aller ICMP-Typen vollständiges Blockieren von ICMP oder ICMPv6 willkürliche Erhöhung von Socketpuffern unkontrollierte Änderung von UDP-Idle-Timeouts ``` Ein Neustart kann Socketzustände, Zähler, NAT-Zuordnungen und den für die Diagnose wichtigen Ausgangszustand zerstören. --- **Quellen** **Standards** - [RFC 768 – User Datagram Protocol](https://datatracker.ietf.org/doc/html/rfc768) - [RFC 8085 – UDP Usage Guidelines](https://datatracker.ietf.org/doc/html/rfc8085) - [RFC 1122 – Requirements for Internet Hosts – Communication Layers](https://datatracker.ietf.org/doc/html/rfc1122) - [RFC 792 – Internet Control Message Protocol](https://datatracker.ietf.org/doc/html/rfc792) - [RFC 1812 – Requirements for IP Version 4 Routers](https://datatracker.ietf.org/doc/html/rfc1812) - [RFC 4443 – ICMPv6 for IPv6](https://datatracker.ietf.org/doc/html/rfc4443) - [RFC 8200 – Internet Protocol, Version 6 Specification](https://datatracker.ietf.org/doc/html/rfc8200) - [RFC 1191 – Path MTU Discovery](https://datatracker.ietf.org/doc/html/rfc1191) - [RFC 8201 – Path MTU Discovery for IPv6](https://datatracker.ietf.org/doc/html/rfc8201) - [RFC 4821 – Packetization Layer Path MTU Discovery](https://datatracker.ietf.org/doc/html/rfc4821) - [RFC 8899 – Datagram PLPMTUD](https://datatracker.ietf.org/doc/html/rfc8899) - [RFC 4890 – Recommendations for Filtering ICMPv6 Messages in Firewalls](https://datatracker.ietf.org/doc/html/rfc4890) - [RFC 6633 – Deprecation of ICMP Source Quench Messages](https://datatracker.ietf.org/doc/html/rfc6633) **Offizielle Microsoft-Dokumentation** - [Microsoft Learn – Get-NetUDPEndpoint](https://learn.microsoft.com/en-us/powershell/module/nettcpip/get-netudpendpoint) - [Microsoft Learn – netstat](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/netstat) - [Microsoft Learn – PortQry command-line tool](https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/portqry-command-line-port-scanner-v2) - [Microsoft Learn – Packet Monitor](https://learn.microsoft.com/en-us/windows-server/networking/technologies/pktmon/pktmon) - [Microsoft Learn – Pktmon command formatting](https://learn.microsoft.com/en-us/windows-server/networking/technologies/pktmon/pktmon-syntax) - [Microsoft Learn – Resolve-DnsName](https://learn.microsoft.com/en-us/powershell/module/dnsclient/resolve-dnsname) **Offizielle Linux- und Projektdokumentation** - [Linux man-pages – ss(8)](https://man7.org/linux/man-pages/man8/ss.8.html) - [Linux man-pages – udp(7)](https://man7.org/linux/man-pages/man7/udp.7.html) - [Linux man-pages – icmp(7)](https://man7.org/linux/man-pages/man7/icmp.7.html) - [Linux man-pages – ipv6(7)](https://man7.org/linux/man-pages/man7/ipv6.7.html) - [Linux man-pages – tcpdump(8)](https://man7.org/linux/man-pages/man8/tcpdump.8.html) - [Linux man-pages – traceroute(8)](https://man7.org/linux/man-pages/man8/traceroute.8.html) - [ISC BIND 9 – Manual Pages und dig](https://bind9.readthedocs.io/en/stable/manpages.html) **Offizielle Wireshark-Dokumentation** - [Wireshark Display Filter Reference – UDP](https://www.wireshark.org/docs/dfref/u/udp.html) - [Wireshark Display Filter Reference – ICMP](https://www.wireshark.org/docs/dfref/i/icmp.html) - [Wireshark Display Filter Reference – ICMPv6](https://www.wireshark.org/docs/dfref/i/icmpv6.html) - [Wireshark User’s Guide](https://www.wireshark.org/docs/wsug_html/) **Offizielle Containerdokumentation** - [Docker Docs – Port publishing and mapping](https://docs.docker.com/engine/network/port-publishing/) - [Docker Docs – Networking overview](https://docs.docker.com/engine/network/) - [Kubernetes – Service](https://kubernetes.io/docs/concepts/services-networking/service/) - [Kubernetes – EndpointSlices](https://kubernetes.io/docs/concepts/services-networking/endpoint-slices/) - [Kubernetes – Network Policies](https://kubernetes.io/docs/concepts/services-networking/network-policies/) Für diese Seite wurden keine Community-Berichte oder Social-Media-Aussagen als technische Nachweise verwendet. # 9.4 Lokale Host-Firewall prüfen **Ziel dieser Seite** Diese Seite beschreibt die systematische Diagnose einer lokalen Host-Firewall unter Windows, Linux und macOS sowie ihre Abgrenzung von: - fehlenden Listenern; - falschen Bindungsadressen; - Netzwerkfirewalls; - Access Control Lists; - NAT und Portweiterleitungen; - Proxys und Load Balancern; - Container- und Kubernetes-Regeln; - VPN- und Endpoint-Security-Filtern; - Anwendungsfehlern. Nach der Bearbeitung muss nachvollziehbar geprüft werden können: - welche lokale Firewalltechnik tatsächlich aktiv ist; - welches Netzwerkprofil, welche Zone oder welche Schnittstelle gilt; - welche eingehende und ausgehende Standardaktion verwendet wird; - welche Regel den betroffenen Datenverkehr erlaubt oder blockiert; - aus welcher Richtlinienquelle die wirksame Regel stammt; - ob TCP, UDP, ICMPv4 und ICMPv6 getrennt berücksichtigt wurden; - ob ein Paket den Host erreicht; - ob es durch die Host-Firewall verworfen wird; - ob ein Prozess oder Dienst trotz passender Regel nicht lauscht; - ob Container-, Hypervisor- oder Endpoint-Security-Filter beteiligt sind; - wie eine Änderung sicher vorbereitet und verifiziert wird. Eine Host-Firewall darf nicht vorsorglich vollständig deaktiviert werden. Zuerst müssen der betroffene Datenfluss und die tatsächlich wirksame Regel nachgewiesen werden. --- **Sicherheits- und Wirkungsklassen** | Kennzeichnung | Bedeutung | |---|---| | **LESEND** | Erfasst ausschließlich vorhandene Zustände. | | **NETZAKTIV** | Erzeugt Netzwerkverkehr zum geprüften Ziel. | | **SENSITIV** | Kann interne Regeln, Adressen, Programme oder Kommunikationsbeziehungen sichtbar machen. | | **ÄNDERND** | Verändert Firewallkonfiguration oder Protokollierung. | | **AUSFALLRISIKO** | Kann bestehende Verbindungen, Verwaltung oder Dienste beeinträchtigen. | Firewallregeln und Protokolle können sicherheitsrelevante Informationen enthalten: - interne Netze; - Verwaltungsports; - erlaubte Quelladressen; - Anwendungspfade; - Dienstnamen; - Benutzer- und Gruppenbezüge; - VPN-Schnittstellen; - Sicherheitsprodukte; - Cloud- und Containerbereiche. Diese Informationen müssen geschützt gespeichert und weitergegeben werden. --- **Aufgabe einer lokalen Host-Firewall** Eine lokale Host-Firewall filtert Netzwerkverkehr direkt auf einem Endgerät oder Server. Abhängig vom Betriebssystem kann sie prüfen: - eingehenden Verkehr zum lokalen Host; - ausgehenden Verkehr des lokalen Hosts; - weitergeleiteten Verkehr; - Transportprotokoll; - lokale und entfernte Adressen; - lokale und entfernte Ports; - Netzwerkprofil oder Zone; - Schnittstelle; - Programm; - Dienst; - Benutzer; - Paket- oder Verbindungszustand; - IPsec-Authentifizierung; - Container- oder VM-Netzwerkpfade. Eine Host-Firewall ersetzt keine Netzwerkfirewall. Beide Ebenen können gleichzeitig filtern. --- **Datenpfad vereinfachen** Eingehender Datenverkehr: ```text Client → Netzwerkfirewall → Servernetzwerkschnittstelle → lokale Host-Firewall → lokaler Socket → Anwendung ``` Ausgehender Datenverkehr: ```text Anwendung → lokaler Socket → lokale Host-Firewall → Servernetzwerkschnittstelle → Netzwerkfirewall → Ziel ``` Container- oder VM-Verkehr kann zusätzlich einen Weiterleitungspfad verwenden: ```text Client → Hostnetzwerkschnittstelle → Host-Firewall oder NAT → virtuelle Bridge → Container- oder VM-Firewall → Anwendung ``` Jede Ebene muss getrennt nachgewiesen werden. --- **Host-Firewall, Listener und Anwendung unterscheiden** | Befund | Aussage | |---|---| | Dienst läuft | Prozessstatus ist vorhanden | | Listener vorhanden | Socket wurde gebunden | | lokale Verbindung funktioniert | lokaler Netzwerkpfad funktioniert | | entfernte Verbindung funktioniert | der getestete Ende-zu-Ende-Pfad funktioniert | | Firewallregel vorhanden | eine konfigurierte Regel existiert | | Firewallregel wirksam | Regel gilt für den konkreten Datenfluss | | Paket wird geloggt | Paket wurde an einem bestimmten Filterpunkt erfasst | | Anwendung antwortet | Transport und Anwendung funktionieren für den Test | Eine vorhandene Allow-Regel beweist nicht, dass: - das richtige Profil aktiv ist; - die Regel aktiviert ist; - Protokoll und Port stimmen; - die Quelladresse zum Regelbereich gehört; - das richtige Programm verwendet wird; - keine Blockregel Vorrang hat; - eine zentral verwaltete Richtlinie die Regel überschreibt; - der Dienst tatsächlich lauscht. --- **Prüfdaten des betroffenen Flows** Vor der Regelsuche muss der Datenfluss exakt dokumentiert werden. ```text Richtung: Transportprotokoll: Quelladresse: Quellport: Zieladresse: Zielport: Lokales Programm: Lokaler Dienst: Schnittstelle: Netzwerkprofil oder Zone: Zeitpunkt: ``` Ohne diese Angaben kann nicht sicher entschieden werden, ob eine Firewallregel zum Fehler passt. --- **Eingehend, ausgehend und weitergeleitet** | Richtung | Bedeutung | |---|---| | eingehend | Verkehr ist an den lokalen Host adressiert | | ausgehend | Verkehr wird durch einen lokalen Prozess erzeugt | | weitergeleitet | Verkehr durchquert den Host zu einem anderen Endpunkt | Unter Linux entsprechen diese Pfade häufig den Netfilter-Hooks beziehungsweise Basischains: ```text input output forward ``` Ein Paket für einen Container oder eine virtuelle Maschine kann den Hostpfad `forward` verwenden, obwohl der Client den Hostport anspricht. Eine Regel im lokalen `input`-Pfad muss deshalb nicht für weitergeleiteten Containerverkehr gelten. --- **Loopback ist kein vollständiger Firewalltest** Ein Test gegen: ```text 127.0.0.1 ::1 localhost ``` prüft den Loopbackpfad. Dieser Test bildet nicht zwingend ab: - die physische Netzwerkschnittstelle; - das aktive Firewallprofil; - die externe Quelladresse; - eine VPN-Schnittstelle; - NAT oder Portweiterleitung; - eine Netzwerkfirewall; - den Container-Weiterleitungspfad. Auch ein Test gegen die eigene LAN-Adresse vom selben Host kann lokal geroutet werden und muss nicht denselben Pfad wie ein entfernter Client verwenden. Für eine vollständige Prüfung ist ein repräsentativer externer Client erforderlich. --- **Firewallzustände richtig interpretieren** | Aktion | Typisches Verhalten | |---|---| | Allow oder Accept | passender Verkehr darf den Filterpunkt passieren | | Drop | Paket wird ohne aktive Fehlermeldung verworfen | | Reject | Paket wird verworfen und es kann eine Ablehnung zurückgesendet werden | | Log | Ereignis wird protokolliert; allein keine Allow- oder Blockaktion | | Default Deny | nicht ausdrücklich erlaubter Verkehr wird blockiert | | Default Allow | nicht ausdrücklich blockierter Verkehr wird erlaubt | Ein TCP-Reset kann entstehen durch: - geschlossenen TCP-Port; - Anwendung; - lokale Firewall mit Reject-Verhalten; - Netzwerkfirewall; - Proxy; - Load Balancer. Ein Timeout kann durch stilles Drop-Verhalten entstehen, beweist aber nicht automatisch eine Firewallblockierung. --- **Wirksame Richtlinie statt nur Konfigurationsdatei prüfen** Firewallregeln können stammen aus: - lokaler Konfiguration; - Gruppenrichtlinie; - MDM; - Sicherheitsbaseline; - Endpoint-Security-Software; - Cloudmanagement; - Containerplattform; - Hypervisor; - VPN-Client; - Service Manager; - temporärer Laufzeitkonfiguration. Entscheidend ist die tatsächlich aktive Richtlinie. Eine Konfigurationsdatei oder GUI kann vom wirksamen Kernelzustand abweichen, wenn: - Änderungen noch nicht geladen wurden; - Laufzeit- und permanente Konfiguration unterschiedlich sind; - eine zentrale Richtlinie Vorrang besitzt; - ein anderer Firewallmanager verwendet wird; - Containerwerkzeuge eigene Regeln erzeugt haben; - ein Sicherheitsprodukt zusätzliche Filter installiert hat. --- **Windows-Firewallprofile** Windows verwendet drei Firewallprofile: | Profil | Typische Verwendung | |---|---| | `Domain` | Netzwerk mit erkannter und authentifizierter Active-Directory-Domäne | | `Private` | als vertrauenswürdig eingestuftes privates Netzwerk | | `Public` | nicht vertrauenswürdiges oder öffentliches Netzwerk | Regeln können für ein oder mehrere Profile gelten. Ein häufiger Fehler ist: ```text Allow-Regel gilt nur für Domain oder Private. Die aktive Schnittstelle verwendet jedoch Public. ``` Windows kann unterschiedliche Profile gleichzeitig für unterschiedliche Schnittstellen verwenden. --- **Windows: aktive Netzwerkprofile prüfen** **LESEND** ```powershell Get-NetConnectionProfile | Select-Object ` InterfaceAlias, InterfaceIndex, Name, NetworkCategory, IPv4Connectivity, IPv6Connectivity ``` Zu prüfen sind: - richtige Schnittstelle; - aktive Netzwerkkategorie; - VPN-Adapter; - virtuelle Adapter; - unerwartetes `Public`-Profil; - mehrere gleichzeitig aktive Profile; - IPv4- und IPv6-Konnektivität. Das Domainprofil darf nicht manuell als Ersatz für eine fehlerhafte Domänenerkennung erzwungen werden. Zuerst müssen DNS, Erreichbarkeit, Authentifizierung und Netzwerkidentifikation geprüft werden. --- **Windows: Firewallprofile prüfen** **LESEND** ```powershell Get-NetFirewallProfile | Select-Object ` Name, Enabled, DefaultInboundAction, DefaultOutboundAction, AllowInboundRules, AllowLocalFirewallRules, AllowLocalIPsecRules, NotifyOnListen, LogFileName, LogMaxSizeKilobytes, LogAllowed, LogBlocked ``` Wirksame Profile aus dem aktiven Richtlinienspeicher: ```powershell Get-NetFirewallProfile ` -PolicyStore ActiveStore | Format-List * ``` Zu dokumentieren sind: - ist das Profil aktiviert? - welche Standardaktion gilt eingehend? - welche Standardaktion gilt ausgehend? - sind lokale Regeln zulässig? - sind lokal konfigurierte IPsec-Regeln zulässig? - werden blockierte Pakete protokolliert? - wo liegt die Protokolldatei? - welche maximale Größe besitzt sie? Die Standardaktionen dürfen nicht ungeprüft als `Block` beziehungsweise `Allow` angenommen werden. --- **Windows: aktive Regeln erfassen** **LESEND** Alle wirksamen Regeln: ```powershell Get-NetFirewallRule ` -PolicyStore ActiveStore ``` Aktivierte Regeln: ```powershell Get-NetFirewallRule ` -PolicyStore ActiveStore ` -Enabled True ``` Aktivierte eingehende Allow-Regeln: ```powershell Get-NetFirewallRule ` -PolicyStore ActiveStore ` -Enabled True ` -Direction Inbound ` -Action Allow ``` Aktivierte eingehende Blockregeln: ```powershell Get-NetFirewallRule ` -PolicyStore ActiveStore ` -Enabled True ` -Direction Inbound ` -Action Block ``` Aktivierte ausgehende Blockregeln: ```powershell Get-NetFirewallRule ` -PolicyStore ActiveStore ` -Enabled True ` -Direction Outbound ` -Action Block ``` Herkunft der Regeln: ```powershell Get-NetFirewallRule ` -PolicyStore ActiveStore ` -Enabled True | Select-Object ` Name, DisplayName, Direction, Action, Profile, PolicyStoreSourceType, PolicyStoreSource ``` `ActiveStore` stellt die zusammengeführte aktive Richtlinie der auf das System wirkenden Policy Stores dar. Eine Abfrage ohne `-PolicyStore ActiveStore` kann eine andere Sicht liefern. --- **Windows: vollständige Regeldarstellung** **LESEND** ```powershell Show-NetFirewallRule ` -PolicyStore ActiveStore ``` Für eine bekannte Regel: ```powershell Get-NetFirewallRule ` -PolicyStore ActiveStore ` -Name "" | Format-List * ``` Die eigentlichen Port-, Adress-, Programm- und Dienstbedingungen werden in zugeordneten Filterobjekten verwaltet. --- **Windows: Portfilter prüfen** **LESEND** Alle Portfilter: ```powershell Get-NetFirewallPortFilter ` -PolicyStore ActiveStore ``` Regeln für lokalen Port `443` suchen: ```powershell Get-NetFirewallPortFilter ` -PolicyStore ActiveStore | Where-Object LocalPort -eq "443" | Get-NetFirewallRule | Select-Object ` Name, DisplayName, Enabled, Direction, Action, Profile, PolicyStoreSourceType, PolicyStoreSource ``` Regeln für entfernten Port `443`: ```powershell Get-NetFirewallPortFilter ` -PolicyStore ActiveStore | Where-Object RemotePort -eq "443" | Get-NetFirewallRule | Select-Object ` Name, DisplayName, Enabled, Direction, Action, Profile ``` Danach muss der vollständige Portfilter der gefundenen Regel geprüft werden: ```powershell Get-NetFirewallRule ` -PolicyStore ActiveStore ` -Name "" | Get-NetFirewallPortFilter | Format-List * ``` Zu prüfen sind: - TCP oder UDP; - lokaler Port; - entfernter Port; - ICMP-Typ; - dynamische Schlüsselwörter; - `Any` oder konkreter Wert. --- **Windows: Adressfilter prüfen** **LESEND** ```powershell Get-NetFirewallRule ` -PolicyStore ActiveStore ` -Name "" | Get-NetFirewallAddressFilter | Format-List * ``` Zu prüfen sind: - `LocalAddress`; - `RemoteAddress`; - einzelne Hosts; - Subnetze; - `Any`; - lokale Subnetze; - IPv4 oder IPv6; - dynamische oder richtlinienbasierte Bereiche. Eine Allow-Regel für: ```text RemoteAddress = 192.0.2.0/24 ``` gilt nicht für einen Client aus: ```text 198.51.100.0/24 ``` --- **Windows: Programmfilter prüfen** **LESEND** ```powershell Get-NetFirewallRule ` -PolicyStore ActiveStore ` -Name "" | Get-NetFirewallApplicationFilter | Format-List * ``` Zu prüfen sind: - vollständiger Programmpfad; - aktuell gestartete ausführbare Datei; - geänderter Installationspfad; - neue Programmversion; - 32-Bit- oder 64-Bit-Pfad; - symbolische Verknüpfungen; - Launcher und eigentlicher Serverprozess; - `Any` oder konkretes Programm. Eine Regel für einen alten Anwendungspfad gilt nicht automatisch für eine neue Programmdatei. --- **Windows: Dienstfilter prüfen** **LESEND** ```powershell Get-NetFirewallRule ` -PolicyStore ActiveStore ` -Name "" | Get-NetFirewallServiceFilter | Format-List * ``` Zu prüfen sind: - konkreter Windows-Dienst; - Dienstname statt Anzeigename; - gemeinsam verwendeter Prozess; - Service Hardening; - `Any` oder konkreter Dienst. Eine Regel kann für einen Dienst gelten, obwohl mehrere Dienste denselben Prozess wie `svchost.exe` verwenden. --- **Windows: Schnittstellenfilter prüfen** **LESEND** ```powershell Get-NetFirewallRule ` -PolicyStore ActiveStore ` -Name "" | Get-NetFirewallInterfaceFilter | Format-List * ``` Zu prüfen sind: - konkrete Schnittstelle; - Schnittstellentyp; - LAN; - WLAN; - Remote Access; - VPN; - virtuelle Schnittstelle. Eine Regel für LAN muss nicht für einen VPN- oder WLAN-Pfad gelten. --- **Windows: Regelbedingungen vollständig dokumentieren** Für eine gefundene Regel müssen mindestens folgende Informationen zusammengeführt werden: ```text Name: Status: Richtung: Aktion: Profile: Protokoll: Lokaler Port: Entfernter Port: Lokale Adresse: Entfernte Adresse: Programm: Dienst: Schnittstelle: Richtlinienquelle: ``` Erst der Vergleich aller Bedingungen mit dem konkreten Datenfluss zeigt, ob die Regel tatsächlich passt. --- **Windows-Regelvorrang** Für Windows-Firewallregeln gilt unter anderem: - eine ausdrücklich definierte Allow-Regel kann die eingehende Standardblockierung übersteuern; - eine ausdrücklich definierte Blockregel besitzt Vorrang vor einer widersprechenden Allow-Regel; - spezifischere Regeln können gegenüber weniger spezifischen Regeln maßgeblich sein; - zentrale Richtlinien können lokale Konfigurationsmöglichkeiten begrenzen; - Service-Hardening- und IPsec-Anforderungen können zusätzlich wirken. Windows-Firewallregeln dürfen nicht wie eine einfache von oben nach unten abgearbeitete ACL-Liste interpretiert werden. --- **Windows: Gruppenrichtlinienbezug prüfen** **LESEND** Zusammenfassung der angewendeten Computerrichtlinien: ```cmd gpresult /scope computer /r ``` Wirksame Firewallregeln enthalten zusätzlich: ```powershell PolicyStoreSourceType PolicyStoreSource ``` Zu prüfen sind: - stammt die Regel aus lokaler Konfiguration? - stammt sie aus einer Domänenrichtlinie? - dürfen lokale Firewallregeln zusammengeführt werden? - wurde die erwartete GPO angewendet? - existiert eine Blockregel aus einer anderen Richtlinie? - wird die Einstellung durch MDM verwaltet? - erscheint eine lokale Änderung nach Richtlinienaktualisierung erneut oder verschwindet sie? Eine zentral verwaltete Regel darf nicht durch eine lokale Parallelregel umgangen werden. --- **Windows: Firewallprotokoll prüfen** Der Protokollpfad kann je Profil abweichen und muss über `Get-NetFirewallProfile` bestimmt werden. Typischer Standardpfad: ```text %SystemRoot%\System32\LogFiles\Firewall\pfirewall.log ``` Letzte Einträge: **LESEND · SENSITIV** ```powershell Get-Content ` "$env:SystemRoot\System32\LogFiles\Firewall\pfirewall.log" ` -Tail 100 ``` Nach Adresse oder Port suchen: ```powershell Get-Content ` "$env:SystemRoot\System32\LogFiles\Firewall\pfirewall.log" ` -Tail 1000 | Select-String "192.0.2.100|443" ``` Zu korrelieren sind: - Aktion; - Datum und Uhrzeit; - Protokoll; - Quell- und Zieladresse; - Quell- und Zielport; - Richtung beziehungsweise Pfad; - betroffene Schnittstelle; - identischer Testzeitpunkt. Fehlende Einträge beweisen nicht, dass die Firewall nicht beteiligt ist. Protokollierung kann deaktiviert, begrenzt oder an einem anderen Pfad konfiguriert sein. --- **Windows: temporäre Protokollierung** Vor einer Änderung müssen die vorhandenen Profilwerte dokumentiert werden. Aktuellen Zustand sichern: ```powershell Get-NetFirewallProfile | Select-Object ` Name, LogFileName, LogMaxSizeKilobytes, LogAllowed, LogBlocked ``` Blockprotokollierung für ein bestimmtes Profil aktivieren: **ÄNDERND · SENSITIV** ```powershell Set-NetFirewallProfile ` -Profile Domain ` -LogBlocked True ``` Die Änderung muss: - autorisiert sein; - auf das betroffene Profil begrenzt werden; - hinsichtlich Speicherbedarf überwacht werden; - nach dem Test auf den dokumentierten Ausgangswert zurückgesetzt werden. Das Aktivieren der Protokollierung für erlaubte Verbindungen kann sehr große Datenmengen erzeugen. --- **Windows Filtering Platform prüfen** Windows Filtering Platform, kurz WFP, bildet die Filterplattform für Windows-Firewall, IPsec und weitere Filterkomponenten. Relevante Security-Ereignisse können sein: | Ereignis-ID | Bedeutung | |---:|---| | `5152` | WFP hat ein Paket blockiert. | | `5154` | Anwendung oder Dienst durfte auf eingehende Verbindungen lauschen. | | `5155` | Anwendung oder Dienst wurde am Lauschen gehindert. | | `5156` | WFP hat eine Verbindung erlaubt. | | `5157` | WFP hat eine Verbindung blockiert. | | `5158` | Bindung an einen lokalen Port wurde erlaubt. | | `5159` | Bindung an einen lokalen Port wurde blockiert. | Blockereignisse lesen: **LESEND · SENSITIV** ```powershell Get-WinEvent ` -FilterHashtable @{ LogName = "Security" Id = 5152, 5155, 5157, 5159 } ` -MaxEvents 100 ``` Diese Ereignisse stehen nur zur Verfügung, wenn die entsprechenden Überwachungsrichtlinien aktiv waren. Zu prüfen sind: - Application Name; - Process ID; - Direction; - Source Address; - Source Port; - Destination Address; - Destination Port; - Protocol; - Filter Run-Time ID; - Layer Name; - Zeitpunkt. Sehr umfangreiche WFP-Überwachung kann viele Ereignisse erzeugen und muss gezielt eingesetzt werden. --- **Windows: netsh als ergänzende Sicht** **LESEND** Profile: ```cmd netsh advfirewall show allprofiles ``` Regeln: ```cmd netsh advfirewall firewall show rule name=all verbose ``` Überwachungszustand: ```cmd netsh advfirewall monitor show firewall ``` Der ältere Kontext: ```text netsh firewall ``` sollte nicht mehr für die aktuelle Verwaltung verwendet werden. Für moderne Systeme sind PowerShell-NetSecurity-Cmdlets und `netsh advfirewall` vorgesehen. --- **Windows: Drittanbieterfilter berücksichtigen** Verkehr kann blockiert werden, obwohl keine passende Windows-Firewall-Blockregel sichtbar ist. Mögliche zusätzliche Filter: - Endpoint Detection and Response; - Antiviren-Netzwerkfilter; - Data Loss Prevention; - VPN-Client; - Webfilter; - Network-Extension- oder WFP-Callout-Treiber; - Zero-Trust-Agent; - Hypervisorfilter; - Cloud-Sicherheitsagent. Hinweise: - Fehler beginnt nach Installation oder Update eines Sicherheitsprodukts; - WFP-Ereignis verweist auf einen fremden Filter; - Windows-Firewallprotokoll zeigt keinen Drop; - Paket erreicht die Schnittstelle, aber nicht die Anwendung; - nur ein bestimmter Prozess ist betroffen; - eine andere Anwendung auf demselben Portpfad funktioniert. Sicherheitssoftware darf nicht ohne Freigabe beendet oder deinstalliert werden. --- **Windows: Hyper-V, WSL und Container** Verkehr zu einer VM, WSL-Instanz oder einem Container kann zusätzliche Filterebenen durchlaufen. Zu unterscheiden sind: - Windows-Host-Firewall; - Hyper-V-Firewall; - virtueller Switch; - Host Network Service; - Container-NAT; - Gastbetriebssystem-Firewall; - Kubernetes- oder CNI-Regeln. Verfügbare Hyper-V-Firewall-Cmdlets prüfen: ```powershell Get-Command ` -Name "*NetFirewallHyperV*" ` -ErrorAction SilentlyContinue ``` Wenn entsprechende Cmdlets vorhanden sind, müssen Hyper-V-Profile und Regeln zusätzlich geprüft werden. Eine Allow-Regel im normalen Hostprofil beweist nicht automatisch, dass Verkehr zu einer VM oder WSL-Instanz erlaubt wird. --- **Linux: verwendetes Firewall-Backend bestimmen** Auf Linux-Systemen können mehrere Werkzeuge vorhanden sein: - nftables; - iptables-legacy; - iptables-nft; - firewalld; - UFW; - Container- oder Kuberneteskomponenten; - eBPF-, XDP- oder `tc`-Filter. Zuerst muss bestimmt werden, welches System die aktive Richtlinie verwaltet. Versionen prüfen: **LESEND** ```bash nft --version ``` ```bash iptables --version ``` Eine iptables-Ausgabe kann auf ein Backend hinweisen: ```text iptables vX.Y.Z (nf_tables) ``` oder: ```text iptables vX.Y.Z (legacy) ``` Aktive Manager: ```bash systemctl is-active firewalld ``` ```bash systemctl is-active ufw ``` Die Installation oder Aktivität eines Managers beweist nicht, dass keine weiteren Regeln existieren. --- **Linux: nftables-Regelsatz prüfen** **LESEND · SENSITIV** ```bash sudo nft list ruleset ``` Mit Regel-Handles: ```bash sudo nft -a list ruleset ``` Zu prüfen sind: - Tabellenfamilie; - Tabellenname; - Basischains; - Hook; - Priorität; - Chain Policy; - Sprünge in weitere Chains; - Regeln; - Sets; - Maps; - Protokoll; - Adressen; - Ports; - Schnittstellen; - Verbindungszustände; - Counter; - Log-Aktionen; - `accept`, `drop` oder `reject`. Wichtige Tabellenfamilien: | Familie | Bedeutung | |---|---| | `inet` | gemeinsame Verarbeitung von IPv4 und IPv6 | | `ip` | IPv4 | | `ip6` | IPv6 | | `bridge` | Bridgeverkehr | | `arp` | ARP | | `netdev` | früher Paketpfad an Netzgeräten | Eine Regel in `inet` kann sowohl IPv4 als auch IPv6 betreffen. Separate `ip`- und `ip6`-Regeln müssen getrennt geprüft werden. --- **Linux: nftables-Hooks prüfen** Typische Hooks: | Hook | Datenpfad | |---|---| | `input` | Verkehr zum lokalen Host | | `output` | lokal erzeugter Verkehr | | `forward` | weitergeleiteter Verkehr | | `prerouting` | vor der Routingentscheidung | | `postrouting` | nach der Routingentscheidung | | `ingress` | früher Eingangspfad | Der Name einer Chain muss nicht ihrem Hook entsprechen. Entscheidend ist die tatsächliche Chain-Definition. Beispiel: ```text chain host_in { type filter hook input priority filter; policy drop; } ``` Eine frei benannte Chain ohne Hook wirkt nur, wenn eine andere Regel in sie springt. --- **Linux: nftables-Counter auswerten** Regeln können Zähler für Pakete und Bytes enthalten. Beispielausgabe: ```text counter packets 42 bytes 3360 drop ``` Für einen kontrollierten Test: 1. aktuellen Zählerstand dokumentieren; 2. genau einen Test ausführen; 3. Regelsatz erneut lesen; 4. Zählerdifferenz prüfen; 5. Quelladresse, Zielport und Protokoll abgleichen. Ein unveränderter Zähler beweist nicht automatisch, dass die Regel nicht betroffen ist: - die Regel besitzt eventuell keinen Counter; - eine frühere Regel beendet die Verarbeitung; - der Datenfluss verwendet eine andere Chain; - die Aufzeichnung erfolgt in einem anderen Namespace; - ein XDP- oder `tc`-Filter verwirft früher. Zähler dürfen nicht vorsorglich zurückgesetzt werden, weil dadurch Beweisdaten verloren gehen. --- **Linux: iptables-Regeln prüfen** **LESEND · SENSITIV** IPv4: ```bash sudo iptables \ -L \ -n \ -v \ --line-numbers ``` IPv6: ```bash sudo ip6tables \ -L \ -n \ -v \ --line-numbers ``` Vollständiger IPv4-Regelsatz mit Countern: ```bash sudo iptables-save \ -c ``` Vollständiger IPv6-Regelsatz: ```bash sudo ip6tables-save \ -c ``` Wichtige Optionen: | Option | Bedeutung | |---|---| | `-L` | Chains und Regeln anzeigen | | `-n` | numerische Adressen und Ports | | `-v` | ausführliche Anzeige und Counter | | `--line-numbers` | Regelpositionen anzeigen | | `-c` bei `iptables-save` | Counter mit ausgeben | `iptables -L` allein bildet nicht immer alle Tabellen und benutzerdefinierten Zusammenhänge ausreichend ab. `iptables-save` liefert eine vollständigere Regelsatzdarstellung. --- **Linux: INPUT, OUTPUT und FORWARD unterscheiden** Typische Bedeutung: ```text INPUT: Paket ist an den Linux-Host selbst adressiert. OUTPUT: Paket wurde auf dem Linux-Host erzeugt. FORWARD: Paket wird durch den Linux-Host weitergeleitet. ``` Containerverkehr kann beispielsweise durchlaufen: ```text PREROUTING → FORWARD → POSTROUTING ``` Eine Allow-Regel in `INPUT` hilft in diesem Fall nicht zwingend. --- **Linux: firewalld-Zustand prüfen** **LESEND** Dienstzustand: ```bash firewall-cmd --state ``` Aktive Zonen und Zuordnungen: ```bash firewall-cmd --get-active-zones ``` Standardzone: ```bash firewall-cmd --get-default-zone ``` Alle Zonen: ```bash firewall-cmd --list-all-zones ``` Bestimmte aktive Zone: ```bash firewall-cmd \ --zone= \ --list-all ``` Rich Rules: ```bash firewall-cmd \ --zone= \ --list-rich-rules ``` Richtlinienobjekte: ```bash firewall-cmd --get-policies ``` ```bash firewall-cmd --list-all-policies ``` Zu prüfen sind: - welche Schnittstelle gehört zu welcher Zone? - existiert eine Quelladresszuordnung? - welche Services sind erlaubt? - welche Ports sind erlaubt? - welche Protokolle sind erlaubt? - existieren Rich Rules? - existieren ICMP-Blocks? - existieren aktive Policy Objects? - welches Zielverhalten besitzt die Zone? Die Standardzone ist nicht automatisch die tatsächlich für jede Schnittstelle wirksame Zone. --- **Linux: firewalld-Laufzeit und permanente Konfiguration** firewalld unterscheidet: | Konfiguration | Wirkung | |---|---| | Runtime | aktuell aktiv, geht ohne Übernahme bei Reload oder Neustart verloren | | Permanent | gespeichert, wird bei Reload oder Start zur Runtime-Konfiguration | Runtime-Konfiguration einer Zone: ```bash firewall-cmd \ --zone= \ --list-all ``` Permanente Konfiguration: ```bash firewall-cmd \ --permanent \ --zone= \ --list-all ``` Beide Ausgaben müssen verglichen werden. Mögliche Fehler: - Regel ist permanent gespeichert, aber noch nicht geladen; - Regel existiert nur zur Laufzeit und verschwindet nach Neustart; - Reload hat eine Diagnosefreigabe entfernt; - falsche Zone wurde geändert; - Schnittstelle wechselte die Zone; - Quelladressbindung besitzt eine andere Wirkung als erwartet. Ein `firewall-cmd --reload` ist eine Änderung und darf nicht als erster Diagnoseschritt verwendet werden. --- **Linux: bestimmten firewalld-Port prüfen** Runtime: ```bash firewall-cmd \ --zone= \ --query-port=443/tcp ``` Service: ```bash firewall-cmd \ --zone= \ --query-service=https ``` Permanent: ```bash firewall-cmd \ --permanent \ --zone= \ --query-port=443/tcp ``` Ein positives Ergebnis beweist nur, dass Port oder Service in dieser Zone konfiguriert ist. Es beweist nicht: - dass die Schnittstelle zu dieser Zone gehört; - dass keine Rich Rule blockiert; - dass der Dienst lauscht; - dass eine vorgelagerte Firewall erlaubt; - dass der Client aus dem passenden Quellbereich kommt. --- **Linux: UFW prüfen** **LESEND** Status und Standardrichtlinien: ```bash sudo ufw status verbose ``` Nummerierte Regeln: ```bash sudo ufw status numbered ``` Von UFW verwaltete hinzugefügte Regeln: ```bash sudo ufw show added ``` Vollständigere Netfilter-Sicht: ```bash sudo ufw show raw ``` Zu prüfen sind: - aktiv oder inaktiv; - eingehende Standardaktion; - ausgehende Standardaktion; - IPv4- und IPv6-Regeln; - Quelladressen; - Ports; - Protokolle; - Schnittstellen; - Reihenfolge; - gerouteter Verkehr. `ufw status` zeigt nicht zwingend alle Regeln, die außerhalb von UFW erzeugt wurden. Ein Status `inactive` beweist deshalb nicht, dass im Kernel keine anderen Netfilterregeln aktiv sind. --- **Linux: vorhandene Firewallprotokolle prüfen** Kernelmeldungen im betroffenen Zeitraum: **LESEND · SENSITIV** ```bash journalctl \ -k \ --since "15 minutes ago" ``` firewalld-Dienstmeldungen: ```bash journalctl \ -u firewalld \ --since "15 minutes ago" ``` UFW-Dienstmeldungen: ```bash journalctl \ -u ufw \ --since "15 minutes ago" ``` Zu beachten: - Dienstmeldungen sind nicht automatisch Paketlogs; - eine Regel muss eine Log-Aktion besitzen, damit sie Paketdetails erzeugt; - Logziele können Journal, Kernelringpuffer, Syslog oder NFLOG sein; - Logpräfixe müssen zum Datenfluss passen; - umfangreiche Paketprotokollierung kann Systeme und Datenträger belasten. Neue Logregeln dürfen nur gezielt, rate-limitiert und zeitlich begrenzt erstellt werden. --- **Linux: eBPF-, XDP- und tc-Filter berücksichtigen** Pakete können vor oder außerhalb der erwarteten nftables- oder iptables-Regel verworfen werden. Schnittstellendetails: ```bash ip \ -details \ link show \ dev ``` `tc`-Ingressfilter: ```bash sudo tc \ filter show \ dev \ ingress ``` `tc`-Egressfilter: ```bash sudo tc \ filter show \ dev \ egress ``` Falls `bpftool` vorhanden ist: ```bash sudo bpftool net ``` Mögliche Verursacher: - CNI-Plugin; - Kubernetes NetworkPolicy; - Sicherheitsagent; - DDoS-Schutz; - Service Mesh; - XDP-Programm; - Traffic Control; - Cloud- oder Hostingagent. Diese Filter dürfen nicht ohne Kenntnis ihres Besitzers entfernt werden. --- **macOS: zwei Firewallbereiche unterscheiden** Unter macOS müssen mindestens zwei unterschiedliche Mechanismen getrennt betrachtet werden: | Mechanismus | Aufgabe | |---|---| | Application Layer Firewall | steuert eingehende Verbindungen anhand von Apps und Diensten | | Packet Filter `pf` | paket- und regelbasierte Filterung auf Netzwerkebene | Zusätzlich können vorhanden sein: - Network Extensions; - Endpoint-Security-Produkte; - VPN-Filter; - Content Filter; - DNS-Proxy; - Drittanbieter-Firewall; - MDM-Konfigurationsprofile. Die macOS Application Firewall wird nicht primär als frei konfigurierbare Portfirewall verwaltet. Apple beschreibt sie als anwendungsbezogene Firewall. --- **macOS: Application Firewall in der Oberfläche prüfen** Aktueller Pfad: ```text Apple-Menü → Systemeinstellungen → Netzwerk → Firewall ``` Zu prüfen sind: - Firewall aktiviert oder deaktiviert; - „Alle eingehenden Verbindungen blockieren“; - Liste zugelassener und blockierter Apps; - automatisch zugelassene integrierte Software; - automatisch zugelassene signierte Software; - Tarnmodus; - MDM-Verwaltung. Die genaue Darstellung kann je nach macOS-Version und Geräteverwaltung abweichen. --- **macOS: Application Firewall im Terminal prüfen** **LESEND** Gesamtstatus: ```bash sudo /usr/libexec/ApplicationFirewall/socketfilterfw \ --getglobalstate ``` Block-All-Zustand: ```bash sudo /usr/libexec/ApplicationFirewall/socketfilterfw \ --getblockall ``` Tarnmodus: ```bash sudo /usr/libexec/ApplicationFirewall/socketfilterfw \ --getstealthmode ``` Anwendungsliste: ```bash sudo /usr/libexec/ApplicationFirewall/socketfilterfw \ --listapps ``` Lokale Hilfe und verfügbare Optionen: ```bash /usr/libexec/ApplicationFirewall/socketfilterfw \ --help ``` Zusammenfassung über System Profiler: ```bash system_profiler SPFirewallDataType ``` Zu prüfen sind: - richtiger Anwendungspfad; - signierte oder integrierte Anwendung; - Allow- oder Blockstatus; - globales Blockieren; - MDM-Vorgabe; - geänderte App nach Update; - Launcher und tatsächlicher Listenerprozess. --- **macOS: pf-Zustand prüfen** **LESEND · SENSITIV** Status: ```bash sudo pfctl -s info ``` Filterregeln: ```bash sudo pfctl -sr ``` NAT-Regeln: ```bash sudo pfctl -sn ``` Zustandstabelle: ```bash sudo pfctl -ss ``` Gesamtübersicht: ```bash sudo pfctl -sa ``` Zu prüfen sind: - ist `pf` aktiviert? - welche Regeln und Anchors sind geladen? - existieren Block- oder Pass-Regeln? - welche Schnittstellen werden verwendet? - existieren NAT- oder Redirect-Regeln? - passt ein State zum betroffenen Datenfluss? - verwaltet ein Systemdienst oder Sicherheitsprodukt den Anchor? Apple weist darauf hin, dass Packet Filter keine unterstützte API für die Integration eigener Softwareprodukte ist. Systembestandteile können die Regeln verwalten und verändern. Die Diagnose vorhandener Zustände ist deshalb von einer dauerhaften eigenen Produktintegration zu unterscheiden. --- **macOS: Network Extensions und Sicherheitsfilter** Installierte System Extensions: **LESEND** ```bash systemextensionsctl list ``` Mögliche Filterkomponenten: - Content Filter; - Packet Tunnel; - App Proxy; - DNS Proxy; - Endpoint Security; - Hersteller-VPN; - Zero-Trust-Agent. Eine deaktivierte Application Firewall beweist nicht, dass keine Network Extension den Verkehr filtert. Sicherheits- oder VPN-Erweiterungen dürfen nicht ohne Freigabe entfernt oder deaktiviert werden. --- **Docker und Host-Firewall** Docker kann auf dem Host eigene iptables- oder nftables-Regeln erzeugen, um: - Bridge-Netzwerke zu isolieren; - veröffentlichte Ports weiterzuleiten; - NAT und Masquerading umzusetzen; - DNS-Verkehr in Netzwerk-Namespaces zu behandeln. Zu prüfen sind: ```bash docker info ``` ```bash docker network ls ``` ```bash docker ps \ --format 'table {{.Names}}\t{{.Ports}}' ``` ```bash docker inspect \ \ --format '{{json .NetworkSettings.Ports}}' ``` Wichtige Punkte: - veröffentlichter Containerverkehr kann den Forward-Pfad verwenden; - Docker kann eigene Chains oder nftables-Tabellen erzeugen; - Docker-Regeln dürfen nicht vorsorglich gelöscht werden; - das Abschalten der Docker-Firewallverwaltung kann Containerkommunikation beschädigen; - UFW-, firewalld-, iptables- und Docker-Sichten müssen zusammen betrachtet werden; - Backend und Docker-Version müssen berücksichtigt werden. Ein freigegebener Hostport beweist nicht, dass die Anwendung im Container lauscht. --- **Kubernetes und lokale Host-Firewall** Auf einem Kubernetes-Knoten können zusätzlich wirken: - kube-proxy; - CNI-Plugin; - NetworkPolicy; - eBPF-Regeln; - NodePort; - Service; - Ingress; - Host-Firewall des Knotens; - Cloud-Sicherheitsgruppe. NetworkPolicy ist nicht dasselbe wie die allgemeine Host-Firewall. Zu prüfen sind: ```bash kubectl get networkpolicy \ --all-namespaces ``` ```bash kubectl get service \ --all-namespaces ``` ```bash kubectl get pods \ --all-namespaces \ -o wide ``` ```bash kubectl get endpointslice \ --all-namespaces ``` Bei hostnahen Problemen müssen zusätzlich CNI- und Knotenkonfiguration berücksichtigt werden. --- **TCP-Fehlerbilder einer lokalen Firewall** | Paketbefund | Mögliche Einordnung | |---|---| | SYN erreicht Host nicht | vorgelagerter Pfad oder falsche Zieladresse | | SYN erreicht Host, Firewall loggt Drop | lokale Host-Firewall bestätigt | | SYN erreicht Host, kein Listener | Betriebssystem kann RST senden | | SYN erreicht Host, Listener vorhanden, keine Antwort | lokale Filterung, Prozess oder Überlastung | | Host sendet SYN/ACK, Client erhält es nicht | ausgehender Filter oder Rückweg | | Verbindung wird sofort zurückgesetzt | Reject, fehlender Listener oder Anwendung | | lokaler Test funktioniert, externer nicht | Bindung, Profil, Host-Firewall oder Netzwerkpfad | | nur ein Quellnetz fehlerhaft | RemoteAddress- oder Zonenregel | | nur IPv6 fehlerhaft | fehlende IPv6-Regel oder ICMPv6-Problem | | nur nach VPN-Verbindung fehlerhaft | Profil-, Schnittstellen- oder VPN-Filter | --- **UDP-Fehlerbilder einer lokalen Firewall** | Paketbefund | Mögliche Einordnung | |---|---| | UDP-Anfrage erreicht Host nicht | vorgelagerter Pfad | | Anfrage erreicht Host, Drop wird geloggt | lokale Host-Firewall | | Anfrage erreicht Host und Prozess nicht | Hostfilter, Namespace oder Puffer | | Anwendung antwortet, Antwort verlässt Host nicht | ausgehende Hostfilterung | | keine Antwort und kein ICMP | geöffnet/still oder Drop | | ICMP Port Unreachable | kein passender UDP-Endpunkt oder aktive Ablehnung | | nur große Datagramme scheitern | Fragment-, MTU- oder ICMP-Filterung | | Broadcast oder Multicast scheitert | Schnittstellen-, Zonen- oder Gruppenregel | Ein allgemeiner TCP-Porttest ist kein Nachweis für UDP. --- **ICMP und ICMPv6 prüfen** Firewallregeln müssen ICMPv4 und ICMPv6 getrennt betrachten. Zu prüfen sind: - Echo Request und Echo Reply; - Destination Unreachable; - Port Unreachable; - Time Exceeded; - Fragmentation Needed; - Packet Too Big; - Parameter Problem; - notwendige IPv6-Kontrollmeldungen. Das Blockieren von Ping beweist nicht, dass TCP oder UDP blockiert wird. Umgekehrt kann Ping funktionieren, während ein TCP- oder UDP-Port blockiert ist. Das vollständige Blockieren von ICMP oder ICMPv6 kann Path MTU Discovery und Diagnose beeinträchtigen. --- **Paketaufzeichnung und Firewallprotokoll kombinieren** Eine Paketaufzeichnung allein zeigt nicht immer, ob ein Paket alle lokalen Filterstufen passiert hat. Der Aufzeichnungspunkt kann vor oder nach bestimmten Filtern liegen. Belastbarer Nachweis: 1. Testzeitpunkt genau dokumentieren. 2. Paketaufzeichnung auf dem Host starten. 3. Firewallcounter oder Protokoll erfassen. 4. Genau einen Test ausführen. 5. Listener und Prozesszustand erfassen. 6. Firewallprotokoll mit dem Flow abgleichen. 7. Paketaufzeichnung und Regelcounter vergleichen. 8. Test vom repräsentativen Client wiederholen. --- **Windows-Paketaufzeichnung mit pktmon** `pktmon` kann Paketerfassung und Drop-Erkennung innerhalb des Windows-Netzwerkstacks unterstützen. Filter zurücksetzen: **SENSITIV · ÄNDERND** ```cmd pktmon stop ``` ```cmd pktmon filter remove ``` Filter für TCP-Port `443`: ```cmd pktmon filter add TCP443 -t TCP -p 443 ``` Aufzeichnung starten: ```cmd pktmon start --capture --pkt-size 0 --file-name C:\Temp\firewall443.etl ``` Nach reproduziertem Fehler stoppen: ```cmd pktmon stop ``` Konvertieren: ```cmd pktmon etl2pcap C:\Temp\firewall443.etl --out C:\Temp\firewall443.pcapng ``` Filter entfernen: ```cmd pktmon filter remove ``` Das Zielverzeichnis muss vorhanden sein. Aufzeichnung und Filter müssen anschließend zurückgenommen werden. --- **Linux-Paketaufzeichnung** **LESEND · SENSITIV** TCP-Port `443`: ```bash sudo tcpdump \ -ni any \ 'tcp port 443' \ -c 200 ``` UDP-Port `53` und ICMP: ```bash sudo tcpdump \ -ni any \ '(udp port 53) or icmp or icmp6' \ -c 200 ``` Bestimmte Schnittstelle und Gegenstelle: ```bash sudo tcpdump \ -ni \ 'host 192.0.2.100 and tcp port 443' \ -c 200 ``` Eine sichtbare eingehende Anfrage beweist, dass sie den Capturepunkt erreicht hat. Ob sie die Anwendung erreicht, muss zusätzlich mit Firewallcounter, Socket- und Anwendungsbefund geprüft werden. --- **macOS-Paketaufzeichnung** Verfügbare Schnittstellen: ```bash tcpdump -D ``` Bestimmte Schnittstelle: ```bash sudo tcpdump \ -ni en0 \ 'host 192.0.2.100 and tcp port 443' \ -c 200 ``` Loopback: ```bash sudo tcpdump \ -ni lo0 \ 'tcp port 8080' \ -c 200 ``` Application Firewall, `pf`, Network Extension und Anwendung müssen getrennt ausgewertet werden. --- **Lokalen und entfernten Test vergleichen** Windows: **NETZAKTIV** ```powershell Test-NetConnection ` -ComputerName "127.0.0.1" ` -Port 443 ``` ```powershell Test-NetConnection ` -ComputerName "192.0.2.25" ` -Port 443 ``` Von einem entfernten Client: ```powershell Test-NetConnection ` -ComputerName "app.example.test" ` -Port 443 ` -InformationLevel Detailed ``` Linux und macOS: ```bash nc -vz 127.0.0.1 443 ``` ```bash nc -vz 192.0.2.25 443 ``` Von einem entfernten Client: ```bash nc -vz app.example.test 443 ``` Auswertung: | lokaler Test | entfernter Test | Mögliche Einordnung | |---|---|---| | erfolgreich | erfolgreich | getesteter TCP-Pfad funktioniert | | erfolgreich | fehlerhaft | Bindung, Host-Firewall oder Netzwerkpfad | | fehlerhaft | fehlerhaft | Listener, Dienst, Port oder lokale Filterung | | Loopback erfolgreich, LAN-IP fehlerhaft | Bindung oder schnittstellenbezogene Regel | | IPv4 erfolgreich, IPv6 fehlerhaft | IPv6-Bindung oder IPv6-Firewall | | ohne VPN erfolgreich, mit VPN fehlerhaft | Profil-, Schnittstellen- oder VPN-Regel | --- **Host-Firewall von Netzwerkfirewall abgrenzen** | Nachweis | Einordnung | |---|---| | Paket erreicht Serverschnittstelle nicht | Problem vor dem Server | | Paket erreicht Host und Host-Firewall loggt Drop | lokale Host-Firewall bestätigt | | Paket erreicht Host, kein Drop, kein Listener | Dienst- oder Bindungsproblem | | Paket erreicht Host, Listener vorhanden, Anwendung loggt nichts | lokaler Filter, Endpoint Security oder Anwendung | | Antwort verlässt Serverschnittstelle | lokaler ausgehender Pfad wahrscheinlich passiert | | Antwort verlässt Host nicht und Outbound-Drop wird geloggt | lokale ausgehende Firewall | | Client- und Serveraufzeichnung unterscheiden sich | Verlust oder Filterung im Zwischenpfad | | anderer Server im selben Netz funktioniert | hostspezifische Konfiguration wahrscheinlich | Eine Paketaufzeichnung an nur einem Punkt reicht häufig nicht zur eindeutigen Abgrenzung. --- **Hypothese und Gegenbeweis** Beispiel: ```text Hypothese: Die aktive Windows-Firewall blockiert eingehende TCP-Verbindungen auf Port 443, weil die Allow-Regel nur für das Domainprofil gilt, die aktive Schnittstelle aber dem Public-Profil zugeordnet ist. Erwarteter Befund: Get-NetConnectionProfile zeigt Public. Die Regel gilt nur für Domain. Der lokale Listener auf Port 443 ist vorhanden. Der lokale Test funktioniert. Der entfernte Test schlägt fehl. Das Firewallprotokoll zeigt einen Drop für den Testflow. Gegenbeweis: Die Schnittstelle verwendet Domain und eine wirksame Allow-Regel passt vollständig zu Protokoll, Port, Quelladresse und Programm. Testmethode: Profil-, Regel-, Listener-, Protokoll- und Paketprüfung. Risiko: Die lesenden Prüfungen verändern den Firewallzustand nicht. ``` Linux-Beispiel: ```text Hypothese: Die Netzwerkschnittstelle befindet sich in der firewalld-Zone public, aber die Freigabe wurde in der Zone internal angelegt. Erwarteter Befund: firewall-cmd --get-active-zones ordnet die Schnittstelle public zu. Port 443 ist in public nicht erlaubt, in internal jedoch vorhanden. Der Listener existiert und ein externer Test schlägt fehl. Gegenbeweis: Die Schnittstelle ist internal zugeordnet oder eine andere wirksame Regel erlaubt den konkreten Flow. ``` --- **Kontrollierte Maßnahmen** | Maßnahme | Voraussetzung | Risiko | |---|---|---| | vorhandene passende Regel aktivieren | Regel ist geprüft und nur deaktiviert | Dienst wird erreichbar | | Profilzuordnung korrigieren | falsche Netzwerkkategorie nachgewiesen | Vertrauensniveau des Netzwerks ändert sich | | gezielte Allow-Regel erstellen | konkreter legitimer Flow bestätigt | zusätzliche Angriffsfläche | | zu breite Regel einschränken | unnötiger Geltungsbereich bestätigt | legitime Clients können ausfallen | | falsche Blockregel korrigieren | Blockregel als Ursache nachgewiesen | Schutzwirkung kann reduziert werden | | Programmpfad aktualisieren | Anwendungspfad hat sich nachweislich geändert | falsches Programm könnte freigegeben werden | | RemoteAddress-Bereich korrigieren | Quellnetz stimmt nachweislich nicht | weitere Quellen können Zugriff erhalten | | TCP-/UDP-Protokoll korrigieren | Protokollverwechslung bestätigt | zusätzlicher Transportweg wird geöffnet | | IPv6-Regel ergänzen | Dienst soll IPv6 nutzen und Block ist bestätigt | zusätzliche IPv6-Erreichbarkeit | | firewalld-Runtime und Permanent angleichen | Abweichung bestätigt | Wirkung über Neustart hinaus | | Container-Weiterleitungsregel korrigieren | Forward-Pfad bestätigt | mehrere Container können betroffen sein | | Endpoint-Security-Ausnahme beantragen | Produktfilter als Ursache bestätigt | zentrale Sicherheitswirkung | | Logging zeitlich begrenzt aktivieren | vorhandene Daten reichen nicht | Speicher- und Datenschutzrisiko | Vor jeder Änderung müssen dokumentiert werden: - genaue Regel; - Richtlinienquelle; - betroffener Flow; - Sicherheitsauswirkung; - verantwortlicher Besitzer; - Freigabe; - Ausgangszustand; - Rückweg; - Erfolgskriterium; - vorgesehenes Testverfahren. --- **Systematischer Diagnoseablauf** 1. Exakte Fehlermeldung aufnehmen. 2. Zeitpunkt und Zeitzone dokumentieren. 3. Client, Server und Anwendung bestimmen. 4. TCP, UDP, ICMPv4 oder ICMPv6 bestimmen. 5. Quell- und Zieladressen dokumentieren. 6. Quell- und Zielports dokumentieren. 7. Listener und Bindungsadresse prüfen. 8. Besitzenden Prozess bestimmen. 9. lokalen Loopbacktest durchführen. 10. konkrete lokale Schnittstellenadresse testen. 11. Test von einem repräsentativen entfernten Client durchführen. 12. Paketfluss eingehend, ausgehend oder weitergeleitet bestimmen. 13. aktive Firewalltechnik bestimmen. 14. aktives Profil, aktive Zone oder Schnittstelle bestimmen. 15. Standardaktionen prüfen. 16. wirksame Regeln erfassen. 17. Allow- und Blockregeln prüfen. 18. Protokoll- und Portfilter vergleichen. 19. Adressbereiche vergleichen. 20. Programm- und Dienstfilter vergleichen. 21. Schnittstellenfilter vergleichen. 22. Richtlinienquelle bestimmen. 23. zentrale Richtlinien und lokale Zusammenführung prüfen. 24. Firewallcounter und vorhandene Protokolle auswerten. 25. bei Bedarf zeitlich begrenzte Protokollierung aktivieren. 26. Paketaufzeichnung am Host durchführen. 27. Paketaufzeichnung mit einem zweiten Punkt vergleichen. 28. Container-, VM- und Namespacepfade berücksichtigen. 29. Endpoint Security, VPN und zusätzliche Filter berücksichtigen. 30. Hypothese und Gegenbeweis formulieren. 31. Genau eine kontrollierte Änderung durchführen. 32. identischen Test wiederholen. 33. Anwendung statt nur Porttest verifizieren. 34. weitere repräsentative Clients prüfen. 35. temporäre Protokollierung und Filter zurücknehmen. 36. Ursache, Maßnahme und Prävention dokumentieren. --- **Befundmatrix** | Befund | Mögliche Einordnung | Nächster Nachweis | |---|---|---| | kein Listener | kein Firewallproblem nachgewiesen | Dienst und Bindung prüfen | | lokaler Test funktioniert, remote nicht | Firewall, Bindung oder Netzwerkpfad | Serveraufzeichnung | | Paket erreicht Server nicht | vorgelagerter Pfad | Netzwerkfirewall und Routing | | Paket erreicht Server, Drop wird geloggt | lokale Host-Firewall | passende Regel bestimmen | | Paket erreicht Server, kein Drop, kein App-Log | Endpoint Filter oder Anwendung | Prozess- und WFP/eBPF-Befund | | Allow-Regel vorhanden, falsches Profil | Regel nicht wirksam | aktive Profilzuordnung | | Allow-Regel vorhanden, falsche Zone | Regel nicht wirksam | firewalld-Zuordnung | | Allow-Regel vorhanden, falsches Protokoll | TCP-/UDP-Verwechslung | Portfilter | | Allow-Regel vorhanden, falsche Quelladresse | Scope passt nicht | Adressfilter | | Allow-Regel vorhanden, alter Programmpfad | App-Filter passt nicht | Prozesspfad | | Blockregel und Allow-Regel treffen zu | Blockregel kann Vorrang besitzen | vollständige Regelbedingungen | | lokale Regel verschwindet | zentrale Verwaltung | PolicyStoreSource oder MDM | | UFW inaktiv, Verkehr blockiert | andere Netfilterregeln | `nft list ruleset` | | firewalld-Port permanent, nicht runtime | noch nicht wirksam | Runtime vergleichen | | firewalld-Port runtime, nicht permanent | verschwindet bei Reload | Permanent vergleichen | | nft-Counter steigt an Drop-Regel | Regel trifft den Flow | Zeit und 5-Tupel prüfen | | iptables-Counter bleibt unverändert | anderer Pfad oder Backend | nftables und Namespace prüfen | | Application Firewall erlaubt App, trotzdem blockiert | `pf`, Network Extension oder VPN | weitere Filter prüfen | | Docker-Port veröffentlicht, Hostzugriff scheitert | Forward-/Docker-Regel oder Container | Docker-Regeln und Listener | | Hostdienst funktioniert, Container nicht | Namespace oder Forward-Pfad | Container-Socket und NAT | | nur IPv6 blockiert | fehlende IPv6-Regel | `ip6`, `inet` oder ICMPv6 | | nur VPN betroffen | Schnittstellen-, Profil- oder VPN-Filter | Zustand mit und ohne VPN | | Antwort verlässt Host, Client sieht sie nicht | Problem nach dem Host | Rückweg und Netzwerkfirewall | --- **Typische Diagnosefehler** - Firewall prüfen, bevor der Listener geprüft wurde. - Dienststatus mit Listener gleichsetzen. - lokalen Loopbacktest als externen Nachweis verwenden. - nur die GUI prüfen. - persistente Konfiguration statt aktiver Richtlinie prüfen. - Windows `PersistentStore` mit `ActiveStore` verwechseln. - nur nach einer Allow-Regel suchen. - Blockregeln nicht berücksichtigen. - Windows-Regeln wie eine einfache ACL-Liste interpretieren. - aktives Windows-Profil nicht prüfen. - VPN- und virtuelle Schnittstellen ignorieren. - Programmpfad und Dienstfilter nicht prüfen. - Quelladressbereich nicht prüfen. - TCP und UDP verwechseln. - IPv4- und IPv6-Regeln nicht getrennt prüfen. - Ping als vollständigen Firewalltest verwenden. - ICMPv6 vollständig blockieren. - firewalld-Standardzone mit aktiver Zone gleichsetzen. - firewalld-Runtime und Permanent nicht vergleichen. - UFW-Status als vollständigen Netfilterzustand bewerten. - iptables und nftables unkontrolliert parallel verändern. - Chain-Hooks und Policies nicht prüfen. - Regelcounter ohne Vorher-Nachher-Vergleich bewerten. - Containerverkehr im `INPUT`- statt `FORWARD`-Pfad suchen. - Docker-Regeln vorsorglich löschen. - Kubernetes NetworkPolicy mit Host-Firewall gleichsetzen. - macOS Application Firewall mit `pf` gleichsetzen. - Network Extensions und Endpoint Security ignorieren. - Paketaufzeichnung allein als Nachweis der Firewallaktion verwenden. - Firewallprotokollierung dauerhaft und unbegrenzt aktivieren. - die Firewall vollständig deaktivieren. - Sicherheitssoftware beenden oder deinstallieren. - mehrere Regeln gleichzeitig ändern. - keine Rückfallmöglichkeit dokumentieren. - nur einen einzelnen erfolgreichen Test durchführen. - temporäre Diagnosefreigaben aktiv lassen. --- **Verifikation** Nach einer Maßnahme müssen mindestens folgende Punkte geprüft werden: - der erwartete Listener ist vorhanden; - richtige Adresse und richtiger Port sind gebunden; - der richtige Prozess besitzt den Socket; - das richtige Firewallprofil ist aktiv; - die richtige Linux-Zone ist aktiv; - richtige Schnittstelle ist zugeordnet; - wirksame Standardaktionen entsprechen dem Sollzustand; - die vorgesehene Regel ist aktiviert; - Regelrichtung stimmt; - TCP, UDP, ICMPv4 oder ICMPv6 stimmt; - lokale und entfernte Ports stimmen; - lokale und entfernte Adressbereiche stimmen; - Programm- und Dienstfilter stimmen; - Profil- beziehungsweise Zonenumfang stimmt; - keine widersprechende Blockregel greift; - Richtlinienquelle ist dokumentiert; - lokaler Test funktioniert; - Test über die konkrete Schnittstellenadresse funktioniert; - entfernter Test funktioniert; - ursprüngliche Anwendung funktioniert; - IPv4 funktioniert, sofern vorgesehen; - IPv6 funktioniert, sofern vorgesehen; - UDP funktioniert, sofern vorgesehen; - notwendige ICMP- und ICMPv6-Meldungen funktionieren; - Container- oder VM-Pfad funktioniert; - Firewallcounter zeigen den erwarteten Pfad; - keine neuen unerwarteten Drops entstehen; - Sicherheitsumfang wurde nicht unnötig erweitert; - temporäre Regeln wurden entfernt; - temporäre Protokollierung wurde zurückgesetzt; - mehrere repräsentative Clients funktionieren; - Ursache, Maßnahme und Prävention wurden dokumentiert. Eine vollständig deaktivierte Firewall ist keine gültige Verifikation einer sicheren Lösung. --- **Dokumentationsvorlage** ```text Störung: Zeitpunkt: Client: Server: Anwendung: Richtung: Transportprotokoll: Quelladresse und Port: Zieladresse und Port: Listener: Schnittstelle: Firewalltechnik: Aktives Profil oder Zone: Standardaktion: Wirksame Regel: Richtlinienquelle: Portfilter: Adressfilter: Programm- oder Dienstfilter: Firewallprotokoll: Paketaufzeichnung: Zusätzliche Filter: Nachgewiesene Ursache: Gegenbeweis ausgeschlossen durch: Durchgeführte Maßnahme: Sicherheitsauswirkung: Risiko und Rückweg: Verifikation: Prävention: ``` --- **Checkliste** - [ ] exakte Fehlermeldung dokumentiert - [ ] Zeitpunkt und Zeitzone erfasst - [ ] Client und Server bestimmt - [ ] Anwendung bestimmt - [ ] Prozess und Dienst bestimmt - [ ] Richtung bestimmt - [ ] TCP, UDP, ICMPv4 oder ICMPv6 bestimmt - [ ] Quelladresse erfasst - [ ] Zieladresse erfasst - [ ] Quellport erfasst - [ ] Zielport erfasst - [ ] Listener geprüft - [ ] Bindungsadresse geprüft - [ ] Prozessbesitzer geprüft - [ ] lokalen Loopbacktest durchgeführt - [ ] konkrete lokale Adresse getestet - [ ] entfernten Clienttest durchgeführt - [ ] Host-, Container- und VM-Pfad unterschieden - [ ] aktive Firewalltechnik bestimmt - [ ] Windows-Profil geprüft - [ ] Linux-Zone geprüft - [ ] Schnittstellenzuordnung geprüft - [ ] Firewallstatus geprüft - [ ] eingehende Standardaktion geprüft - [ ] ausgehende Standardaktion geprüft - [ ] wirksame aktive Regeln erfasst - [ ] Allow-Regeln geprüft - [ ] Blockregeln geprüft - [ ] Regelrichtung geprüft - [ ] Profil- oder Zonenumfang geprüft - [ ] Protokollfilter geprüft - [ ] lokalen Port geprüft - [ ] entfernten Port geprüft - [ ] lokale Adresse geprüft - [ ] entfernte Adresse geprüft - [ ] Programmpfad geprüft - [ ] Dienstfilter geprüft - [ ] Schnittstellenfilter geprüft - [ ] Richtlinienquelle bestimmt - [ ] lokale Regelzusammenführung geprüft - [ ] GPO oder MDM berücksichtigt - [ ] Firewallcounter ausgewertet - [ ] vorhandene Protokolle ausgewertet - [ ] Client- und Serverzeit korreliert - [ ] Paketaufzeichnung durchgeführt - [ ] zweiten Aufzeichnungspunkt berücksichtigt - [ ] IPv4 geprüft - [ ] IPv6 geprüft - [ ] ICMPv4 geprüft - [ ] ICMPv6 geprüft - [ ] Container-Firewallregeln berücksichtigt - [ ] Hypervisorfilter berücksichtigt - [ ] VPN-Filter berücksichtigt - [ ] Endpoint Security berücksichtigt - [ ] nftables und iptables unterschieden - [ ] firewalld-Runtime geprüft - [ ] firewalld-Permanent geprüft - [ ] UFW-Rohzustand bei Bedarf geprüft - [ ] macOS Application Firewall geprüft - [ ] macOS `pf` geprüft - [ ] macOS Network Extensions berücksichtigt - [ ] Hypothese formuliert - [ ] Gegenbeweis festgelegt - [ ] Sicherheitsauswirkung dokumentiert - [ ] Risiko und Rückweg dokumentiert - [ ] nur eine kontrollierte Maßnahme durchgeführt - [ ] identischen Test wiederholt - [ ] ursprüngliche Anwendung getestet - [ ] weitere repräsentative Clients geprüft - [ ] temporäre Regel entfernt - [ ] Protokollierung zurückgesetzt - [ ] Ursache und Prävention dokumentiert --- **Schnellreferenz** | Aufgabe | Befehl | |---|---| | Windows-Netzwerkprofil | `Get-NetConnectionProfile` | | Windows-Firewallprofile | `Get-NetFirewallProfile` | | wirksame Windows-Regeln | `Get-NetFirewallRule -PolicyStore ActiveStore` | | aktivierte Windows-Regeln | `Get-NetFirewallRule -PolicyStore ActiveStore -Enabled True` | | Windows-Blockregeln | `Get-NetFirewallRule -PolicyStore ActiveStore -Enabled True -Action Block` | | Windows-Portfilter | `Get-NetFirewallPortFilter -PolicyStore ActiveStore` | | Windows-Adressfilter | `Get-NetFirewallAddressFilter -PolicyStore ActiveStore` | | Windows-Programmfilter | `Get-NetFirewallApplicationFilter -PolicyStore ActiveStore` | | Windows-Dienstfilter | `Get-NetFirewallServiceFilter -PolicyStore ActiveStore` | | vollständige Windows-Regeln | `Show-NetFirewallRule -PolicyStore ActiveStore` | | Windows-Firewallprotokoll | `Get-Content "$env:SystemRoot\System32\LogFiles\Firewall\pfirewall.log" -Tail 100` | | Windows-WFP-Blockereignisse | `Get-WinEvent -FilterHashtable @{LogName="Security"; Id=5152,5155,5157,5159}` | | Windows-netsh-Profile | `netsh advfirewall show allprofiles` | | Windows-netsh-Regeln | `netsh advfirewall firewall show rule name=all verbose` | | nftables-Regelsatz | `sudo nft list ruleset` | | nftables mit Handles | `sudo nft -a list ruleset` | | iptables-Regeln | `sudo iptables -L -n -v --line-numbers` | | IPv6-iptables | `sudo ip6tables -L -n -v --line-numbers` | | iptables-Gesamtsicht | `sudo iptables-save -c` | | firewalld-Zustand | `firewall-cmd --state` | | aktive firewalld-Zonen | `firewall-cmd --get-active-zones` | | firewalld-Zone | `firewall-cmd --zone= --list-all` | | permanente firewalld-Zone | `firewall-cmd --permanent --zone= --list-all` | | firewalld-Port prüfen | `firewall-cmd --zone= --query-port=/` | | UFW-Status | `sudo ufw status verbose` | | nummerierte UFW-Regeln | `sudo ufw status numbered` | | vollständige UFW-Sicht | `sudo ufw show raw` | | Kernelprotokoll | `journalctl -k --since "15 minutes ago"` | | macOS-Firewallstatus | `sudo /usr/libexec/ApplicationFirewall/socketfilterfw --getglobalstate` | | macOS-App-Liste | `sudo /usr/libexec/ApplicationFirewall/socketfilterfw --listapps` | | macOS-Firewallübersicht | `system_profiler SPFirewallDataType` | | macOS-pf-Status | `sudo pfctl -s info` | | macOS-pf-Regeln | `sudo pfctl -sr` | | macOS-pf-States | `sudo pfctl -ss` | | macOS-System-Extensions | `systemextensionsctl list` | | Windows-TCP-Test | `Test-NetConnection -ComputerName -Port ` | | Linux/macOS-TCP-Test | `nc -vz ` | | Linux-Aufzeichnung | `sudo tcpdump -ni any 'tcp port ' -c 200` | --- **Befehle und Maßnahmen, die nicht unkontrolliert als erste Diagnose verwendet werden dürfen** ```text Set-NetFirewallProfile -Enabled False netsh advfirewall set allprofiles state off Disable-NetFirewallRule ohne exakte Regelbegrenzung Enable-NetFirewallRule ohne exakte Regelbegrenzung Remove-NetFirewallRule New-NetFirewallRule ohne dokumentierten Scope netsh int ip reset netsh winsock reset nft flush ruleset iptables -F iptables -X ip6tables -F ufw disable ufw reset firewall-cmd --reload firewall-cmd --complete-reload systemctl stop firewalld systemctl restart firewalld pfctl -d pfctl -F all Änderung oder Entfernen von Docker-Regeln Deaktivieren der Docker-Firewallverwaltung Entfernen von Kubernetes- oder CNI-Regeln Deaktivieren eines VPN-Filters Beenden oder Deinstallieren von Endpoint Security dauerhafte ungefilterte Paketprotokollierung ``` Ein vollständiges Deaktivieren der Firewall verändert den Sicherheitszustand, kann Richtlinien verletzen und liefert keinen präzisen Nachweis darüber, welche Regel den ursprünglichen Fehler verursacht hat. --- **Quellen** **Offizielle Microsoft-Dokumentation** - [Microsoft Learn – Windows Firewall overview](https://learn.microsoft.com/en-us/windows/security/operating-system-security/network-security/windows-firewall/) - [Microsoft Learn – Windows Firewall rules](https://learn.microsoft.com/en-us/windows/security/operating-system-security/network-security/windows-firewall/rules) - [Microsoft Learn – Manage Windows Firewall with the command line](https://learn.microsoft.com/en-us/windows/security/operating-system-security/network-security/windows-firewall/configure-with-command-line) - [Microsoft Learn – Configure Windows Firewall logging](https://learn.microsoft.com/en-us/windows/security/operating-system-security/network-security/windows-firewall/configure-logging) - [Microsoft Learn – Get-NetFirewallProfile](https://learn.microsoft.com/en-us/powershell/module/netsecurity/get-netfirewallprofile) - [Microsoft Learn – Get-NetFirewallRule](https://learn.microsoft.com/en-us/powershell/module/netsecurity/get-netfirewallrule) - [Microsoft Learn – Show-NetFirewallRule](https://learn.microsoft.com/en-us/powershell/module/netsecurity/show-netfirewallrule) - [Microsoft Learn – Get-NetFirewallPortFilter](https://learn.microsoft.com/en-us/powershell/module/netsecurity/get-netfirewallportfilter) - [Microsoft Learn – Get-NetFirewallAddressFilter](https://learn.microsoft.com/en-us/powershell/module/netsecurity/get-netfirewalladdressfilter) - [Microsoft Learn – Get-NetFirewallApplicationFilter](https://learn.microsoft.com/en-us/powershell/module/netsecurity/get-netfirewallapplicationfilter) - [Microsoft Learn – Get-NetFirewallServiceFilter](https://learn.microsoft.com/en-us/powershell/module/netsecurity/get-netfirewallservicefilter) - [Microsoft Learn – WFP auditing and logging](https://learn.microsoft.com/en-us/windows/win32/fwp/auditing-and-logging) - [Microsoft Learn – Event 5152](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-5152) - [Microsoft Learn – Event 5157](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-5157) - [Microsoft Learn – Packet Monitor](https://learn.microsoft.com/en-us/windows-server/networking/technologies/pktmon/pktmon) - [Microsoft Learn – netsh advfirewall](https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/netsh-advfirewall-firewall-control-firewall-behavior) **Offizielle Netfilter- und Linux-Dokumentation** - [nftables Documentation](https://wiki.nftables.org/wiki-nftables/index.php/Main_Page) - [nftables – Counters](https://wiki.nftables.org/wiki-nftables/index.php/Counters) - [Linux man-pages – nft(8)](https://man7.org/linux/man-pages/man8/nft.8.html) - [Linux man-pages – iptables(8)](https://man7.org/linux/man-pages/man8/iptables.8.html) - [Linux man-pages – iptables-save(8)](https://man7.org/linux/man-pages/man8/iptables-save.8.html) - [Linux man-pages – tcpdump(8)](https://man7.org/linux/man-pages/man8/tcpdump.8.html) **Offizielle firewalld- und Ubuntu-Dokumentation** - [firewalld – Documentation](https://firewalld.org/documentation/) - [firewalld – firewall-cmd](https://firewalld.org/documentation/man-pages/firewall-cmd.html) - [firewalld – Runtime and permanent configuration](https://firewalld.org/documentation/man-pages/firewalld.html) - [firewalld – Zone configuration](https://firewalld.org/documentation/man-pages/firewalld.zone.html) - [firewalld – Policy Objects](https://firewalld.org/documentation/man-pages/firewalld.policies.html) - [Ubuntu Manpage – ufw(8)](https://manpages.ubuntu.com/manpages/noble/man8/ufw.8.html) **Offizielle Apple-Dokumentation** - [Apple – Change Firewall settings on Mac](https://support.apple.com/guide/mac-help/change-firewall-settings-on-mac-mh11783/mac) - [Apple – Block connections to your Mac with a firewall](https://support.apple.com/guide/mac-help/block-connections-to-your-mac-with-a-firewall-mh34041/mac) - [Apple Platform Security – Firewall security in macOS](https://support.apple.com/guide/security/firewall-security-in-macos-seca0e83763f/web) - [Apple Deployment – Firewall payload settings](https://support.apple.com/guide/deployment/firewall-payload-settings-dep8d306275f/web) - [Apple – TCP and UDP ports used by Apple software products](https://support.apple.com/en-us/103229) - [Apple Developer – Packet Filter is not API](https://developer.apple.com/documentation/technotes/tn3165-packet-filter-is-not-api) **Offizielle Containerdokumentation** - [Docker Docs – Packet filtering and firewalls](https://docs.docker.com/engine/network/packet-filtering-firewalls/) - [Docker Docs – Docker with iptables](https://docs.docker.com/engine/network/firewall-iptables/) - [Docker Docs – Docker with nftables](https://docs.docker.com/engine/network/firewall-nftables/) - [Docker Docs – Port publishing and mapping](https://docs.docker.com/engine/network/port-publishing/) - [Kubernetes – Network Policies](https://kubernetes.io/docs/concepts/services-networking/network-policies/) - [Kubernetes – Services](https://kubernetes.io/docs/concepts/services-networking/service/) Für diese Seite wurden keine Community-Berichte oder Social-Media-Aussagen als technische Nachweise verwendet. # 9.5 Netzwerkfirewall, ACL-Reihenfolge und Stateful Inspection Eine Netzwerkfirewall kontrolliert den Datenverkehr zwischen Netzen, Sicherheitszonen, Standorten, Cloud-Umgebungen oder einzelnen Netzsegmenten. Eine vorhandene Freigaberegel beweist jedoch noch nicht, dass der Datenverkehr tatsächlich erlaubt wird. Entscheidend sind unter anderem: - die tatsächlich durchlaufene Firewall; - die Eingangs- und Ausgangsschnittstelle; - Quell- und Zielzone; - Quell- und Zieladresse; - Quell- und Zielport; - Protokoll; - Regelreihenfolge und Priorität; - NAT-Verarbeitung; - Routingentscheidung; - bestehender Sitzungszustand; - zusätzliche Sicherheitsprofile; - Rückweg; - Hochverfügbarkeitszustand; - verwendeter virtueller Firewallkontext; - Zeitpunkt und Konfigurationsversion. Diese Seite behandelt Netzwerkfirewalls und zentrale Netzwerk-ACLs. Die lokale Firewall eines Endgeräts oder Servers wurde bereits unter **9.4 Lokale Host-Firewall prüfen** behandelt. --- **Ziele** Nach der Bearbeitung dieser Seite soll nachvollziehbar geprüft werden können: - ob der betroffene Datenverkehr die vorgesehene Firewall durchläuft; - welche Regel tatsächlich angewendet wird; - ob eine allgemeinere Regel eine spezifische Regel überschattet; - ob ein implizites Verbot greift; - ob die Firewall zustandsbehaftet oder zustandslos arbeitet; - ob eine vorhandene Sitzung den aktuellen Test beeinflusst; - ob der Rückverkehr einer bestehenden Sitzung zugeordnet wird; - ob NAT, Routing oder Zonenwahl die Regelzuordnung verändern; - ob ein Sicherheitsprofil trotz erlaubender Netzwerkregel blockiert; - ob die Störung an der Firewall oder an einem anderen Netzabschnitt liegt; - wie eine Änderung kontrolliert und anschließend verifiziert wird. --- **Sicherheits- und Änderungsgrundsätze** Eine Netzwerkfirewall ist häufig ein zentraler Sicherheits- und Verfügbarkeitsbestandteil. Unkontrollierte Änderungen können viele Systeme gleichzeitig betreffen. Vor jeder Änderung sind mindestens festzuhalten: - betroffene Anwendung; - Quelle und Ziel; - benötigtes Protokoll; - benötigte Ports; - Datenflussrichtung; - betroffene Sicherheitszonen; - aktuell passende Regel; - aktuelle Konfigurationsversion; - zuständige Freigabe; - Risiko; - Rückweg; - Erfolgskriterium; - vorgesehenes Testverfahren; - Wartungs- oder Änderungsfenster. Nicht als erste Diagnosemaßnahme geeignet sind: - Firewall deaktivieren; - eine allgemeine `any`-zu-`any`-Freigabe erstellen; - Regelwerk vollständig neu laden; - produktive Regeln ungeprüft verschieben; - Sitzungs- oder Verbindungstabellen vollständig löschen; - NAT-Tabellen vollständig leeren; - Hochverfügbarkeitsumschaltung erzwingen; - Sicherheitsprofile pauschal deaktivieren; - Intrusion Prevention abschalten; - TLS-Inspektion global ausschalten; - Paketfilterung durch eine direkte Umgehungsroute umgehen; - Firewall oder Cluster vorsorglich neu starten; - Zähler vor der Beweissicherung zurücksetzen. Eine kurzfristige Testregel muss genauso präzise wie eine dauerhafte Regel begrenzt werden. Sie benötigt: - eindeutigen Namen; - dokumentierten Zweck; - exakte Quelle; - exaktes Ziel; - erforderliches Protokoll; - erforderlichen Zielport; - Protokollierung; - verantwortliche Person; - Ablaufzeitpunkt; - dokumentierte Entfernung. --- **Netzwerkfirewall und Host-Firewall unterscheiden** | Merkmal | Netzwerkfirewall | Host-Firewall | |---|---|---| | Standort | zwischen Netzen oder Sicherheitszonen | direkt auf dem Endgerät oder Server | | Sichtbarer Datenverkehr | nur Verkehr, der die Firewall tatsächlich durchläuft | ein- und ausgehender Verkehr des lokalen Systems | | Typische Regeln | Zonen, Netze, Adressen, Dienste, Anwendungen | Programme, Dienste, Profile, lokale Ports, Benutzer | | Zustandsverwaltung | zentrale Sitzungstabelle | lokale Verbindungstabelle | | Protokollierung | zentrale Firewall- und Sicherheitsprotokolle | lokales Betriebssystemprotokoll | | Häufige Fehlerquelle | falsche Zone, Regelreihenfolge, NAT, Route, Sitzung | falsches Profil, Dienstregel, Programmpfad | | Umgehungsmöglichkeit | lokales Routing oder direkter Pfad zwischen Systemen | normalerweise nicht für lokalen Netzwerkverkehr | Eine Netzwerkfirewall kann nur Datenverkehr prüfen, der tatsächlich über sie geleitet wird. Befinden sich Quelle und Ziel beispielsweise im selben VLAN, kann der Verkehr die zentrale Firewall vollständig umgehen. --- **Vereinfachter Datenfluss** Ein typischer Datenfluss kann folgende Verarbeitungsschritte enthalten: 1. Paket trifft auf einer Eingangsschnittstelle ein. 2. Eingangszone oder Sicherheitskontext wird bestimmt. 3. Vorhandene Sitzung wird gesucht. 4. NAT- und Routingregeln werden ausgewertet. 5. Ausgangsschnittstelle und Ausgangszone werden bestimmt. 6. Sicherheitsregel wird ermittelt. 7. Zusätzliche Prüfungen werden ausgeführt. 8. Paket wird weitergeleitet oder verworfen. 9. Eine neue Sitzung wird angelegt oder eine vorhandene aktualisiert. 10. Rückverkehr wird einer Sitzung zugeordnet. 11. Ereignisse, Zähler und Sitzungsdaten werden protokolliert. Die genaue Reihenfolge von NAT, Routing, Sicherheitsrichtlinie, Anwendungserkennung und Inhaltsprüfung ist produktspezifisch. Sie muss für das eingesetzte Firewallprodukt und die verwendete Softwareversion geprüft werden. --- **Einen Datenfluss eindeutig beschreiben** Vor der Regelprüfung muss der betroffene Datenfluss vollständig beschrieben werden. Beispiel: ```text Zeitpunkt: 2026-08-02 10:15:32 Europe/Berlin Quelle: 192.0.2.100 Quellzone: CLIENTS Quellport: 53124 Ziel: 198.51.100.25 Zielzone: SERVER Zielport: 443 Protokoll: TCP Anwendung: HTTPS-Zugriff auf app.example.test Erwarteter Pfad: CLIENTS -> FW-CLUSTER-01 -> SERVER Erwartete Regel: ALLOW-CLIENTS-APP-HTTPS Erwartete NAT-Verarbeitung: keine ``` Bei TCP und UDP wird ein Datenfluss typischerweise über das Fünf-Tupel beschrieben: ```text Quelladresse Quellport Zieladresse Zielport IP-Protokoll ``` Für die Firewalldiagnose kommen weitere Merkmale hinzu: - Eingangsschnittstelle; - Ausgangsschnittstelle; - Quellzone; - Zielzone; - Mandant oder virtueller Kontext; - Benutzeridentität; - erkannte Anwendung; - NAT-Adressen und NAT-Ports; - Zeitplan; - Sicherheitsprofil; - VPN- oder Tunnelzuordnung; - Regel-ID; - Sitzungs-ID. --- **Quellport und Zielport nicht verwechseln** Bei einer üblichen Clientverbindung verwendet der Client einen dynamischen Quellport und der Server einen bekannten Zielport. Beispiel: ```text 192.0.2.100:53124 -> 198.51.100.25:443/TCP ``` Dabei gilt: | Feld | Bedeutung | |---|---| | `192.0.2.100` | Clientadresse | | `53124` | dynamischer Quellport des Clients | | `198.51.100.25` | Serveradresse | | `443` | Zielport des HTTPS-Dienstes | Eine Freigabe, die irrtümlich den Quellport `443` statt des Zielports `443` prüft, passt normalerweise nicht auf diesen Verbindungsaufbau. Der Rückverkehr besitzt vertauschte Adressen und Ports: ```text 198.51.100.25:443 -> 192.0.2.100:53124/TCP ``` Bei einer zustandsbehafteten Firewall wird dieser Rückverkehr üblicherweise über den bestehenden Sitzungszustand erlaubt. Bei einer zustandslosen ACL muss der Rückverkehr ausdrücklich berücksichtigt werden. --- **Eingehend und ausgehend richtig einordnen** `Inbound`, `ingress`, `outbound` und `egress` beziehen sich auf eine bestimmte Schnittstelle, Zone oder Ressource. Die Begriffe dürfen nicht ohne diesen Bezug verwendet werden. Beispiel: ```text Clientnetz -> Firewall -> Servernetz ``` Aus Sicht der Firewall: - auf der Client-Schnittstelle trifft der Verbindungsaufbau eingehend ein; - zur Server-Schnittstelle verlässt er die Firewall ausgehend; - der Rückverkehr trifft auf der Server-Schnittstelle eingehend ein; - zum Clientnetz verlässt er die Firewall ausgehend. Bei Cloud-ACLs kann sich `inbound` oder `outbound` auf ein Subnetz, eine Netzwerkschnittstelle oder eine virtuelle Maschine beziehen. Deshalb müssen Ressource und Richtung immer gemeinsam dokumentiert werden. --- **Arten der Filterung** | Verfahren | Auswertung | Sitzungszustand | Typische Eigenschaft | |---|---|---:|---| | zustandslose ACL | jedes Paket einzeln | nein | Rückverkehr benötigt eigene passende Regel | | Stateful Inspection | Paket und bestehende Sitzung | ja | Rückverkehr bestehender Sitzungen wird zugeordnet | | Proxy-Firewall | beendet und vermittelt die Verbindung | ja | Client und Ziel kommunizieren nicht direkt miteinander | | Application Firewall | Anwendung oder Protokollinhalt | ja | Entscheidung kann von erkannter Anwendung abhängen | | Next-Generation Firewall | Netzwerk-, Sitzungs-, Benutzer- und Anwendungsdaten | ja | zusätzliche URL-, Malware-, IPS- oder TLS-Prüfung | | Cloud Security Group | ressourcenbezogene Regeln | häufig ja | Verhalten unterscheidet sich von Subnetz-ACLs | | Cloud Network ACL | subnetzbezogene Paketfilterung | häufig nein | Priorität und Rückregeln sind besonders wichtig | Die Produktbezeichnung allein reicht nicht zur Bewertung. Es muss geprüft werden, welche Regelkomponente den betroffenen Datenfluss tatsächlich verarbeitet. --- **ACL-Reihenfolge** Viele Netzwerkfirewalls und Router prüfen Regeln in einer definierten Reihenfolge. Häufig gilt: 1. Regeln werden von oben nach unten oder nach Priorität geprüft. 2. Die erste vollständig passende Regel bestimmt die Aktion. 3. Nach einem Treffer werden nachfolgende Regeln nicht mehr geprüft. 4. Trifft keine Regel zu, greift häufig eine implizite Standardaktion. Dieses Verhalten ist verbreitet, aber nicht für jedes Produkt und jede Regelart identisch. Zu prüfen sind: - globale Regeln; - lokale Regeln; - geerbte Regeln; - Schnittstellen-ACLs; - Zonenregeln; - Vorregeln und Nachregeln; - Parent- und Child-Policies; - Regelgruppen; - Sicherheitsprofile; - herstellerspezifische Ausnahme- und Standardregeln. --- **Beispiel für eine sinnvolle Reihenfolge** Anforderung: - Host `192.0.2.66` darf den Server nicht erreichen. - Andere Clients aus `192.0.2.0/24` dürfen HTTPS verwenden. - Nicht ausdrücklich erlaubter Verkehr wird protokolliert verworfen. Vereinfachte Regelreihenfolge: ```text 10 deny tcp 192.0.2.66/32 -> 198.51.100.25/32 port 443 log 20 permit tcp 192.0.2.0/24 -> 198.51.100.25/32 port 443 log 90 deny ip any -> any log ``` Die spezifische Sperre steht vor der allgemeineren Freigabe. Fehlerhafte Reihenfolge: ```text 10 permit tcp 192.0.2.0/24 -> 198.51.100.25/32 port 443 log 20 deny tcp 192.0.2.66/32 -> 198.51.100.25/32 port 443 log 90 deny ip any -> any log ``` Wenn das Produkt nach dem ersten Treffer beendet, wird Host `192.0.2.66` bereits durch Regel `10` erlaubt. Regel `20` ist für diesen Datenfluss nicht erreichbar. --- **Überschattete, redundante und widersprüchliche Regeln** | Regelproblem | Beschreibung | Auswirkung | |---|---|---| | überschattete Regel | frühere allgemeinere Regel deckt alle Treffer der späteren Regel ab | spätere Regel wird nie verwendet | | teilweise überschattete Regel | frühere Regel deckt einen Teil des späteren Bereichs ab | Regel wirkt nur für den verbleibenden Teil | | redundante Regel | Regel erlaubt oder verbietet bereits identisch behandelten Verkehr | unnötige Komplexität | | widersprüchliche Regel | gleiche oder überlappende Kriterien besitzen andere Aktion | Ergebnis hängt von Reihenfolge ab | | veraltete Regel | zugehöriger Dienst oder Eigentümer existiert nicht mehr | unnötige Angriffsfläche | | ungebundene ACL | ACL ist definiert, aber keiner Schnittstelle oder Zone zugeordnet | keine Wirkung | | falscher Kontext | Regel liegt in anderem Mandanten oder virtuellen System | keine Wirkung auf den betroffenen Verkehr | | falsche Richtung | Regel ist für Gegenrichtung angelegt | erwarteter Verbindungsaufbau bleibt blockiert | | falsche Adressphase | Regel verwendet falsche NAT-Adresse | kein Treffer | | falsche Regelart | Netzwerkregel statt Anwendungsregel oder umgekehrt | unerwartete Verarbeitung | Regelanalysen des Herstellers können bei der Erkennung helfen. Das Ergebnis muss trotzdem mit realen Trefferzählern, Protokollen und einem kontrollierten Verbindungstest bestätigt werden. --- **Implizite Standardaktion** Viele ACL- und Firewallregelwerke besitzen am Ende eine implizite Verweigerung. Diese Regel ist möglicherweise nicht als normale Konfigurationszeile sichtbar. Vereinfachtes Modell: ```text permit deny deny any any ``` Ein explizites abschließendes Verbot mit Protokollierung kann die Diagnose erleichtern: ```text deny any any log ``` Ob eine solche Regel sinnvoll und zulässig ist, hängt vom Produkt und der Protokollierungsleistung ab. Eine stark ausgelastete abschließende Protokollregel kann sehr viele Ereignisse erzeugen. Zu prüfen sind: - existiert eine implizite Verweigerung? - welche Regelart besitzt sie? - gilt sie pro Schnittstelle, Zone, Regelgruppe oder Kontext? - wird ein Treffer protokolliert? - existieren Ausnahmen für System- oder Verwaltungsverkehr? - greifen vorher noch globale oder geerbte Regeln? - existiert eine vom Hersteller bereitgestellte Standardregel? Ein fehlender sichtbarer `deny`-Eintrag beweist nicht, dass nicht passender Verkehr erlaubt wird. --- **Regelkriterien vollständig prüfen** Eine moderne Firewall kann deutlich mehr als nur IP-Adresse und Port auswerten. | Kriterium | Zu prüfender Punkt | |---|---| | Quellzone | stimmt die Zone der tatsächlichen Eingangsschnittstelle? | | Zielzone | entspricht sie der durch Routing bestimmten Ausgangszone? | | Quelladresse | Originaladresse, NAT-Adresse oder Adressobjekt? | | Zieladresse | Originalziel oder übersetztes Ziel? | | Quellport | dynamischer Port oder fest definierter Dienstport? | | Zielport | tatsächlich verwendeter Dienstport? | | Protokoll | TCP, UDP, ICMP, ESP, GRE oder anderes IP-Protokoll? | | Anwendung | bereits erkannt, noch unbekannt oder verschlüsselt? | | Dienst | fest definierter Port oder anwendungsabhängiger Standardport? | | Benutzer | konnte die Firewall die Identität ermitteln? | | Gerät | passt die Geräte- oder Endpunktklassifizierung? | | Zeitplan | ist die Regel zum Fehlerzeitpunkt aktiv? | | URL-Kategorie | wird das Ziel einer anderen Kategorie zugeordnet? | | FQDN-Objekt | auf welche Adressen wurde der Name aufgelöst? | | Sicherheitsprofil | Malware-, IPS-, Datei- oder URL-Prüfung aktiv? | | Mandant | richtiger virtueller Router oder Firewallkontext? | | VPN | gilt eine zusätzliche VPN- oder Tunnelregel? | Eine Regel kann auf Netzwerkebene `allow` ergeben und anschließend trotzdem durch ein Sicherheitsprofil blockiert werden. --- **Adress- und Dienstobjekte prüfen** Regeln verwenden häufig Objekte statt direkt eingetragener IP-Adressen und Ports. Zu prüfen sind: - aktueller Objektinhalt; - CIDR-Präfix; - IPv4- oder IPv6-Zuordnung; - einzelne Adresse oder gesamtes Netz; - verschachtelte Objektgruppen; - doppelte Gruppenmitgliedschaften; - dynamische Gruppen; - Cloud-Tags; - FQDN-Auflösung; - Aktualisierungszeitpunkt; - Portbereich; - TCP- oder UDP-Zuordnung; - deaktivierte oder abgelaufene Objekte; - Synchronisation zwischen Clusterknoten. Beispiel für eine häufige Netzmaskenverwechslung: ```text 192.0.2.0/24 ``` umfasst: ```text 192.0.2.0 bis 192.0.2.255 ``` Dagegen umfasst: ```text 192.0.2.100/32 ``` nur die einzelne Adresse: ```text 192.0.2.100 ``` Bei Produkten mit Wildcard-Masken ist die Schreibweise nicht mit einer normalen Subnetzmaske gleichzusetzen. --- **FQDN- und dynamische Objekte** Ein FQDN-Objekt kann von der Firewall regelmäßig in eine oder mehrere IP-Adressen aufgelöst werden. Zu prüfen sind: - welcher DNS-Server von der Firewall verwendet wird; - ob die DNS-Auflösung erfolgreich ist; - welche A- und AAAA-Adressen gespeichert sind; - TTL und Aktualisierungszeitpunkt; - unterschiedliche Antworten durch Geo-DNS oder CDN; - Erreichbarkeit über IPv4 und IPv6; - maximale Anzahl unterstützter Adressen; - Verhalten bei fehlgeschlagener Aktualisierung; - Synchronisation im Cluster. Ein Client und eine Firewall können denselben FQDN zu unterschiedlichen Zieladressen auflösen. Dann kann eine scheinbar passende FQDN-Regel den tatsächlichen Clientverkehr verfehlen. --- **Stateful Inspection** Eine zustandsbehaftete Firewall bewertet nicht jedes Paket vollständig unabhängig. Sie führt eine Sitzungstabelle und ordnet weitere Pakete einem bekannten Datenfluss zu. Vereinfachter TCP-Ablauf: 1. Client sendet `SYN`. 2. Firewall findet keine vorhandene Sitzung. 3. Firewall prüft Route, Zone, NAT und Richtlinie. 4. Bei Erlaubnis wird ein Sitzungseintrag angelegt. 5. Server sendet `SYN, ACK`. 6. Firewall ordnet das Paket der bestehenden Sitzung zu. 7. Client sendet `ACK`. 8. Sitzung wechselt in den etablierten Zustand. 9. Weitere Pakete werden anhand der Sitzung verarbeitet. 10. `FIN`, `RST` oder Timeout beendet die Sitzung. Eine zustandsbehaftete Firewall kann Pakete verwerfen, wenn diese nicht zum erwarteten Zustand passen, beispielsweise: - `ACK` ohne bekannte Sitzung; - unerwartete TCP-Flags; - Rückverkehr mit abweichenden Adressen oder Ports; - Sequenznummer außerhalb des akzeptierten Fensters; - verspäteter Rückverkehr nach Sitzungsablauf; - Rückverkehr über einen anderen nicht synchronisierten Firewallknoten; - fragmentierter Verkehr, der nicht korrekt zugeordnet werden kann. --- **Typische Daten eines Sitzungseintrags** Ein Sitzungseintrag kann unter anderem enthalten: ```text Sitzungs-ID Protokoll Quellzone Zielzone Eingangsschnittstelle Ausgangsschnittstelle Original-Quelladresse Original-Quellport Original-Zieladresse Original-Zielport übersetzte Quelladresse übersetzter Quellport übersetzte Zieladresse übersetzter Zielport passende Regel Anwendung TCP-Zustand Startzeit letzte Aktivität Timeout gesendete Pakete empfangene Pakete gesendete Bytes empfangene Bytes Sitzungsendgrund Clusterbesitzer ``` Die Sitzungstabelle ist ein wichtiger Nachweis, ersetzt aber nicht die Prüfung der tatsächlichen Anwendung. Eine vorhandene Sitzung beweist nur, dass die Firewall einen Zustand führt. Sie beweist nicht automatisch: - dass der Serverprozess korrekt antwortet; - dass TLS funktioniert; - dass die Anwendung ein gültiges Ergebnis liefert; - dass Nutzdaten in beide Richtungen übertragen werden; - dass die Sitzung nicht bereits festhängt; - dass alle weiteren Sicherheitsprüfungen erfolgreich sind. --- **Zustandslos und zustandsbehaftet vergleichen** | Prüfpunkt | Zustandslose ACL | Stateful Firewall | |---|---|---| | Verarbeitung | jedes Paket einzeln | Paket plus Sitzungszustand | | Rückverkehr | benötigt passende Gegenregel | bestehender Sitzung zugeordnet | | TCP-Zustand | normalerweise nicht vollständig verfolgt | Handshake und Status werden verfolgt | | UDP | jedes Datagramm nach Regel | häufig zeitlich begrenzte Pseudositzung | | ICMP | eigene Regeln pro Richtung erforderlich | kann Anfrage und Antwort zuordnen | | Asymmetrischer Pfad | Regel kann trotzdem passen | häufig Sitzungsproblem | | Ressourcenverbrauch | geringer | Sitzungstabelle benötigt Speicher | | Timeoutwirkung | keine Sitzung | Rückverkehr kann nach Ablauf verworfen werden | | Regeländerung | wirkt auf folgende Pakete | bestehende Sitzungen können abweichend behandelt werden | Das Verhalten bei Regeländerungen und bestehenden Sitzungen ist produktspezifisch. Einige Systeme prüfen bestehende Sitzungen nicht sofort erneut, andere beenden betroffene Sitzungen oder bewerten bestimmte Eigenschaften erneut. --- **TCP-Verkehr prüfen** Bei TCP sind mindestens folgende Punkte zu unterscheiden: - erreicht das `SYN` die Firewall? - welche Regel trifft auf das `SYN`? - verlässt das `SYN` die Firewall? - erreicht das `SYN` den Server? - sendet der Server ein `SYN, ACK` oder `RST`? - erreicht die Antwort dieselbe Firewallinstanz? - wird die Antwort der Sitzung zugeordnet? - erreicht die Antwort den Client? - wird der Handshake vollständig abgeschlossen? - endet die Sitzung durch `FIN`, `RST`, Timeout oder Richtlinie? Befundbeispiele: | Paketfolge | Mögliche Einordnung | |---|---| | wiederholte `SYN`, keine Antwort | Paketverlust, Firewall-Drop, falsche Route oder Server antwortet nicht | | `SYN`, danach sofortiges `RST` | Ziel lehnt aktiv ab oder Zwischenkomponente erzeugt Reset | | `SYN`, `SYN-ACK`, anschließend kein `ACK` | Rückweg zum Client oder Clientseite prüfen | | vollständiger Handshake, danach sofortiger `RST` | Anwendung, Proxy, Sicherheitsprofil oder Protokollproblem | | Daten nur in eine Richtung | Rückweg, asymmetrischer Pfad oder Sicherheitsprüfung | | Sitzung in Firewall vorhanden, keine Serverantwort | Zielsystem, nachgelagerte Firewall oder Route prüfen | --- **UDP-Verkehr prüfen** UDP besitzt keinen TCP-Handshake. Stateful Firewalls führen deshalb häufig eine zeitlich begrenzte Pseudositzung. Beispiel: ```text 192.0.2.100:54000 -> 198.51.100.53:53/UDP ``` Die Firewall kann anschließend eine passende Antwort erlauben: ```text 198.51.100.53:53 -> 192.0.2.100:54000/UDP ``` Zu prüfen sind: - wurde das erste Datagramm durch eine Regel erlaubt? - wurde eine Pseudositzung angelegt? - trifft die Antwort vor Ablauf des UDP-Timeouts ein? - stimmen Antwortadresse und Antwortport mit dem erwarteten Datenfluss überein? - verwendet die Anwendung mehrere Zieladressen oder Ports? - wechselt das Protokoll von UDP zu TCP? - wird ICMP `Destination Unreachable` zurückgegeben? - blockiert eine zustandslose Gegen-ACL den Rückverkehr? Ein vorhandener UDP-Sitzungseintrag beweist keine erfolgreiche Anwendungskommunikation. --- **ICMP und ICMPv6 prüfen** ICMP transportiert nicht nur Echo-Anfrage und Echo-Antwort, sondern auch wichtige Fehlermeldungen. Beispiele: - Ziel nicht erreichbar; - Port nicht erreichbar; - Fragmentierung erforderlich; - Time Exceeded; - Parameter Problem; - Packet Too Big bei IPv6. Zu prüfen sind: - ICMP-Typ und ICMP-Code; - Richtung; - Quell- und Zieladresse; - Zuordnung zu einer ursprünglichen Sitzung; - separate ICMP-Regeln; - ICMP-Inspektionsfunktion; - IPv4- und IPv6-Regeln; - Rate Limits; - vorgeschaltete Router-ACLs. Das pauschale Blockieren von ICMP kann Diagnose, Path-MTU-Discovery und besonders IPv6-Funktionen beeinträchtigen. --- **Sitzungstimeouts** Stateful Firewalls entfernen inaktive Sitzungen nach definierten Zeiträumen. Zu prüfen sind: - TCP-Handshake-Timeout; - TCP-Idle-Timeout; - TCP-Time-Wait- oder Closing-Timeout; - UDP-Timeout; - ICMP-Timeout; - anwendungsspezifischer Timeout; - halb offene Verbindungen; - Langzeitverbindungen; - Keepalive-Verhalten; - maximale Sitzungsdauer; - benutzerdefinierte Timeoutprofile; - Sitzungslast und Tabellenfüllstand. Typische Symptome eines Timeoutproblems: - kurze Verbindungen funktionieren; - lange Leerlaufphasen beenden die Verbindung; - Anwendung meldet nach einer festen Zeit einen Abbruch; - die nächste Übertragung nach Inaktivität schlägt fehl; - eine neue Verbindung funktioniert sofort wieder; - Client und Server halten die Sitzung unterschiedlich lange für gültig. Ein Timeout sollte nur geändert werden, wenn der zeitliche Zusammenhang nachgewiesen wurde. Eine pauschale Erhöhung kann den Speicherverbrauch und die Anzahl gleichzeitig geführter Sitzungen vergrößern. --- **Bestehende Sitzungen bei Regeländerungen** Nach einer Regeländerung sind neue und bestehende Verbindungen getrennt zu prüfen. Mögliche produktabhängige Verhaltensweisen: - neue Sitzungen verwenden die neue Regel; - vorhandene Sitzungen laufen nach alter Entscheidung weiter; - vorhandene Sitzungen werden neu bewertet; - verweigernde Änderung beendet passende Sitzungen; - NAT-Änderung wirkt erst auf neue Sitzungen; - Anwendungserkennung ändert die verwendete Regel während der Sitzung; - Clusterknoten besitzen vorübergehend unterschiedliche Zustände. Deshalb muss ein Test dokumentieren: ```text Test A: bereits vor der Änderung bestehende Verbindung Test B: nach der Änderung vollständig neu aufgebaute Verbindung ``` Wenn ein neuer Test erforderlich ist, sollte nur die einzelne betroffene Anwendungssitzung kontrolliert beendet werden. Das vollständige Löschen der Sitzungstabelle ist unverhältnismäßig und kann viele produktive Verbindungen unterbrechen. --- **Routing und Zielzone** Die Zielzone wird bei vielen Firewalls anhand der Ausgangsschnittstelle oder Routingentscheidung bestimmt. Zu prüfen sind: - aktive Route zur Zieladresse; - Präfixlänge; - nächster Hop; - Routinginstanz oder VRF; - Policy-Based Routing; - ECMP; - Tunnelroute; - dynamisches Routing; - Failoverroute; - Ausgangsschnittstelle; - daraus resultierende Zielzone. Eine Sicherheitsregel kann inhaltlich korrekt aussehen, aber nicht passen, wenn die Firewall aufgrund einer falschen Route eine andere Zielzone bestimmt. Beispiel: ```text Erwartet: CLIENTS -> SERVER Tatsächlich: CLIENTS -> WAN ``` In diesem Fall ist nicht zuerst die Regel `CLIENTS -> SERVER` zu verändern. Zunächst muss geklärt werden, warum die Route zur falschen Ausgangszone führt. --- **NAT und Sicherheitsrichtlinie** NAT kann Adressen und Ports verändern. Beispiel einer Zielübersetzung: ```text Original: 203.0.113.40:55000 -> 198.51.100.10:443 Nach DNAT: 203.0.113.40:55000 -> 10.20.30.40:8443 ``` Beispiel einer Quellübersetzung: ```text Original: 10.10.20.25:53124 -> 203.0.113.80:443 Nach SNAT: 198.51.100.5:61001 -> 203.0.113.80:443 ``` Für die Diagnose sind beide Ansichten zu dokumentieren: | Merkmal | Vor NAT | Nach NAT | |---|---|---| | Quelladresse | ursprünglicher Absender | übersetzte Quelladresse | | Quellport | ursprünglicher Quellport | übersetzter Quellport | | Zieladresse | aufgerufene Zieladresse | internes oder übersetztes Ziel | | Zielport | aufgerufener Zielport | übersetzter Zielport | Je nach Hersteller, Regelart und Richtung kann die Sicherheitsrichtlinie vor oder nach einer bestimmten NAT-Verarbeitung ausgewertet werden. Es darf nicht angenommen werden, dass eine Firewallregel immer die öffentliche oder immer die private Adresse verwenden muss. Zu prüfen sind: - NAT-Regel; - Sicherheitsregel; - Reihenfolge der Verarbeitung; - Original- und Übersetzungsadresse; - Original- und Übersetzungsport; - NAT-Ausnahme; - Hairpin- oder U-Turn-NAT; - doppelte NAT-Regeln; - Proxy-ARP; - Rückroute; - NAT-Sitzung; - Porterschöpfung; - Clusterzustand. Eine passende Sicherheitsregel kann durch eine falsche NAT-Regel wirkungslos bleiben. --- **Zonen und virtuelle Kontexte** Viele Firewalls besitzen: - Sicherheitszonen; - virtuelle Router; - virtuelle Systeme; - Mandanten; - Security Contexts; - Routinginstanzen; - Verwaltungs- und Datenebenen; - zentrale und lokale Richtlinien. Zu prüfen sind: - richtige Firewall; - aktiver Clusterknoten; - richtiger Mandant; - richtiger virtueller Kontext; - richtige Routinginstanz; - richtige Policy-Version; - richtige Eingangszone; - richtige Ausgangszone; - globale oder geerbte Regeln; - lokale Ausnahmen; - zentral verwaltete und lokal definierte Regeln. Eine Regel in einem anderen virtuellen Kontext kann denselben Namen besitzen, aber für den betroffenen Datenverkehr vollständig wirkungslos sein. --- **Zusätzliche Sicherheitsprüfungen** Eine Regel mit der Aktion `allow` bedeutet bei modernen Firewalls häufig nur, dass der Datenfluss weiter geprüft werden darf. Weitere mögliche Prüfungen: - Intrusion Prevention; - Malware-Erkennung; - Antivirus; - Dateitypprüfung; - URL-Filterung; - DNS-Sicherheitsprüfung; - Anwendungskontrolle; - Benutzeridentifikation; - Data Loss Prevention; - Botnet-Erkennung; - TLS-Entschlüsselung; - Zertifikatsprüfung; - Protokolldekodierung; - Geo-IP-Regel; - Reputationsprüfung; - Threat-Intelligence-Regel; - DoS-Schutz; - Zone Protection; - Flood Protection. Deshalb sind mindestens zwei Entscheidungen zu unterscheiden: ```text Netzwerkregel: allow Sicherheitsprofil: block ``` Im Protokoll können dafür mehrere Einträge entstehen. Ein `allow`-Ereignis darf nicht isoliert als Nachweis einer erfolgreichen Verbindung bewertet werden. --- **Application-Awareness** Eine anwendungsbasierte Firewall kann eine Sitzung zunächst anhand des Ports behandeln und später die erkannte Anwendung berücksichtigen. Zu prüfen sind: - erkannte Anwendung; - Zeitpunkt der Erkennung; - unbekannte oder unvollständige Anwendung; - abweichender Port; - verschlüsselter Datenverkehr; - SNI; - HTTP-Hostheader; - ALPN; - QUIC; - Portwechsel; - abhängige Anwendungen; - benötigte Grundanwendung; - Regel mit `application-default`; - TLS-Entschlüsselungsstatus. Beispiel: ```text TCP-Port: 443 Erkannte Anwendung: quic Erwartete Anwendung: ssl/web-browsing ``` Eine reine Portfreigabe sagt nicht aus, welche Anwendung tatsächlich transportiert wird. --- **Regelbindung prüfen** Eine definierte ACL oder Policy wirkt nur, wenn sie an der richtigen Stelle eingebunden ist. Zu prüfen sind: - Schnittstelle; - Richtung; - Sicherheitszone; - Regelgruppe; - Policy-Paket; - virtueller Kontext; - Mandant; - Gerätegruppe; - Zielgerät; - aktive Konfiguration; - erfolgreicher Commit; - erfolgreicher Deploymentstatus; - Synchronisation im Cluster; - zentrale Vererbung. Beispielbefund: ```text ACL: WEB-IN Konfiguriert: ja Gebunden an: DMZ-Schnittstelle eingehend Tatsächlicher Verkehr: tritt an WAN-Schnittstelle ein Ergebnis: ACL WEB-IN verarbeitet diesen Datenfluss nicht ``` --- **Aktive und gespeicherte Konfiguration unterscheiden** Je nach Produkt können unterschiedliche Konfigurationsstände existieren: - bearbeitete Konfiguration; - Kandidatenkonfiguration; - gespeicherte Startkonfiguration; - laufende Konfiguration; - zuletzt erfolgreich ausgerollte Richtlinie; - zentral vorgesehene Richtlinie; - lokale Gerätekonfiguration; - Konfiguration des aktiven Knotens; - Konfiguration des passiven Knotens. Zu prüfen sind: - wurde die Änderung gespeichert? - wurde sie erfolgreich geprüft? - wurde sie committed? - wurde sie auf das richtige Gerät ausgerollt? - ist das Deployment abgeschlossen? - existieren Warnungen oder Fehler? - verwenden alle Clusterknoten dieselbe Version? - wurde eine lokale Änderung durch zentrale Verwaltung überschrieben? Eine im Managementsystem sichtbare Regel beweist nicht, dass sie bereits auf der Datenebene aktiv ist. --- **Hochverfügbarkeit und Cluster** Bei einem Firewallcluster sind zusätzlich zu prüfen: - aktiver und passiver Knoten; - Clusterzustand; - Konfigurationssynchronisation; - Sitzungssynchronisation; - NAT-Synchronisation; - Routingzustand; - Linkstatus; - Split-Brain-Schutz; - Eigentümer der Sitzung; - Datenpfad des Hinverkehrs; - Datenpfad des Rückverkehrs; - Zustand nach Failover; - Zeitstempel der letzten Umschaltung. Typischer Fehler: ```text Hinverkehr: FW-A Rückverkehr: FW-B Sitzungssynchronisation: fehlerhaft ``` FW-B kennt die durch FW-A aufgebaute Sitzung möglicherweise nicht und verwirft den Rückverkehr als ungültig. Asymmetrische Pfade und Connection Tracking werden in **9.6 Asymmetrische Pfade, Sessiontabellen und Connection Tracking** weiter vertieft. --- **Cloud-Firewalls und Cloud-ACLs** Cloud-Plattformen können mehrere Filterebenen kombinieren: - Security Group an der Netzwerkschnittstelle; - Subnetz-ACL; - zentrale Cloud-Firewall; - Load Balancer; - Web Application Firewall; - Kubernetes Network Policy; - Plattformdienst-Firewall; - lokaler Hostfilter; - On-Premises-Firewall; - Routing- und Transitkomponente. Diese Ebenen müssen einzeln geprüft werden. --- **AWS Security Groups und Network ACLs** | Merkmal | AWS Security Group | AWS Network ACL | |---|---|---| | Zuordnung | Netzwerkschnittstelle oder Ressource | Subnetz | | Zustand | stateful | stateless | | Regeln | Freigaberegeln | Erlauben und Verweigern | | Rückverkehr | für verfolgte Verbindung automatisch berücksichtigt | muss durch Gegenregel erlaubt werden | | Reihenfolge | keine klassische First-Match-Reihenfolge der Freigaberegeln | nach Regelnummer | | Diagnosefokus | tatsächlich zugeordnete Gruppen | tatsächlich zugeordnete Subnetz-ACL | | Ephemeral Ports | Rückverkehr durch Zustand | ausdrücklich berücksichtigen | Bei einer AWS Network ACL muss beispielsweise für eine eingehend erlaubte TCP-Verbindung auch der ausgehende Rückverkehr zum dynamischen Clientport erlaubt sein. Vereinfachtes Beispiel: ```text Inbound: TCP von 192.0.2.0/24 zu Zielport 443 erlauben Outbound: TCP zu 192.0.2.0/24 und benötigtem dynamischem Clientportbereich erlauben ``` Der tatsächlich verwendete Portbereich hängt vom Clientbetriebssystem, der Anwendung und gegebenenfalls weiteren NAT-Komponenten ab. --- **Azure Network Security Groups** Azure Network Security Groups arbeiten zustandsbehaftet und verwenden Regeln mit Prioritätswerten. Grundprinzip: ```text kleinere Prioritätszahl = höhere Priorität ``` Beispiel: ```text Priorität 100: Deny TCP 192.0.2.66 -> 10.20.30.40:443 Priorität 200: Allow TCP 192.0.2.0/24 -> 10.20.30.40:443 ``` Zu prüfen sind: - NSG am Subnetz; - NSG an der Netzwerkschnittstelle; - effektive Sicherheitsregeln; - Priorität; - Standardregeln; - Service Tags; - Application Security Groups; - NAT-Bezug; - Azure Firewall; - User Defined Routes; - Load Balancer; - Network Watcher Flow Logs; - tatsächlich verwendete private Zieladresse. Bei eingehendem Verkehr verarbeitet eine Azure NSG die Regeln nach der Übersetzung einer öffentlichen in eine private IP-Adresse. Bei ausgehendem Verkehr erfolgt die NSG-Verarbeitung vor der Übersetzung einer privaten in eine öffentliche Adresse. --- **Netzwerkregel und Anwendungsfirewall unterscheiden** Eine Netzwerkfirewall prüft typischerweise IP-Adressen, Ports, Protokolle, Sitzungen und gegebenenfalls Anwendungen. Eine Web Application Firewall prüft dagegen HTTP- oder HTTPS-Anfragen auf Anwendungsebene. Beispiel: ```text Netzwerkfirewall: TCP 443 erlaubt Web Application Firewall: HTTP-Anfrage wegen Regelverletzung blockiert ``` Ein erfolgreicher TCP-Handshake bis zum Reverse Proxy beweist daher nicht, dass die Webanwendung die Anfrage akzeptiert. --- **Ausgangszustand erfassen** Vor Veränderungen sind folgende Informationen zu sichern: ```text Datum und Uhrzeit Zeitzone Clientname und Clientadresse Servername und Serveradresse Quellport Zielport Protokoll Anwendung exakte Fehlermeldung betroffener Benutzer Eingangs- und Ausgangszone erwarteter Firewallpfad aktiver Firewallknoten Regelname und Regel-ID NAT-Regel Sitzungs-ID Policy-Version Logeinträge Trefferzähler Paketaufzeichnungen ``` Die Uhren von Client, Server, Firewall und zentralem Protokollsystem müssen ausreichend synchronisiert sein. Andernfalls können zusammengehörige Ereignisse falsch zugeordnet werden. --- **Fehlerumfang bestimmen** Zu klären ist: - betrifft die Störung nur einen Client? - betrifft sie ein gesamtes Quellnetz? - betrifft sie nur eine Zieladresse? - betrifft sie alle Ziele einer Zone? - betrifft sie nur einen Port? - betrifft sie TCP, UDP oder ICMP? - betrifft sie IPv4, IPv6 oder beide? - tritt sie nur über VPN auf? - tritt sie nur über einen Standort auf? - betrifft sie neue oder auch bestehende Sitzungen? - tritt sie erst seit einer Regeländerung auf? - betrifft sie nur einen Clusterknoten? - tritt sie nur zu bestimmten Uhrzeiten auf? - betrifft sie nur eine erkannte Anwendung? - ist sie von der Nutzlastgröße abhängig? Ein präzise begrenzter Fehlerumfang verhindert unnötig weitreichende Regeländerungen. --- **Firewallpfad nachweisen** Der vorgesehene Firewallpfad darf nicht nur aus dem Netzplan abgeleitet werden. Mögliche Nachweise: - Traceroute; - Routingtabellen; - Flow Logs; - NetFlow oder IPFIX; - Firewall-Sitzungstabelle; - Eingangs- und Ausgangsaufzeichnung; - Schnittstellenzähler; - MAC- und ARP-Tabellen; - Cloud Network Watcher; - zentrale SD-WAN- oder Transitprotokolle; - Logeintrag mit Eingangs- und Ausgangszone. Zu beachten ist, dass Traceroute nicht jede Firewall sichtbar macht. Eine transparente Firewall oder ein Gerät, das TTL-Abläufe nicht beantwortet, kann im Traceroute fehlen. --- **Regelwerk zunächst nur lesend prüfen** Zu erfassen sind: - Name der aktiven Policy; - Regel-ID; - Regelname; - Position oder Priorität; - Quelle; - Ziel; - Zonen; - Protokoll; - Quellport; - Zielport; - Anwendung; - Aktion; - Sicherheitsprofile; - Zeitplan; - Protokollierung; - Trefferzähler; - letztes Trefferdatum; - Ersteller; - Änderungsreferenz; - Objektinhalte; - Standardaktion. Ein Screenshot allein ist kein idealer technischer Nachweis. Wenn möglich, sollten zusätzlich exportierbare Text- oder Konfigurationsdaten mit Zeitstempel gesichert werden. Dabei sind Zugangsdaten, Schlüssel und andere schützenswerte Informationen zu entfernen. --- **Trefferzähler richtig auswerten** Ein Trefferzähler kann zeigen, dass Verkehr eine Regel erreicht hat. Er muss jedoch vorsichtig interpretiert werden. Zu beachten sind: - einige Produkte zählen nur den ersten Paket- oder Sitzungsaufbau; - andere zählen alle passenden Pakete; - Hardware-Offloading kann separate Zähler verwenden; - Zähler können pro Clusterknoten geführt werden; - zentrale Ansicht kann verzögert sein; - ein breites Regelobjekt kann Verkehr vieler Systeme zählen; - alte Treffer beweisen keinen Treffer beim aktuellen Test; - Zähler können nach Neustart oder Deployment zurückgesetzt sein; - ein Zähleranstieg bei einer `allow`-Regel beweist keine erfolgreiche Anwendung; - ein Zählerstand von null kann auf falschen Pfad, falsche Regel oder falschen Kontext hinweisen. Belastbarer Ablauf: 1. aktuellen Zählerstand mit Uhrzeit dokumentieren; 2. genau einen kontrollierten Test ausführen; 3. Zähler erneut ablesen; 4. Differenz bewerten; 5. gleichzeitig Firewallprotokoll und Anwendungsergebnis prüfen. Zähler dürfen erst nach der Beweissicherung und nur mit Freigabe zurückgesetzt werden. --- **Firewallprotokolle auswerten** Ein brauchbarer Protokolleintrag enthält möglichst: - Ereigniszeit; - Firewallname; - Clusterknoten; - virtuellen Kontext; - Eingangszone; - Ausgangszone; - Eingangs- und Ausgangsschnittstelle; - Quelladresse; - Quellport; - Zieladresse; - Zielport; - Protokoll; - NAT-Adressen und NAT-Ports; - Regelname; - Regel-ID; - Aktion; - erkannte Anwendung; - Sicherheitsprofil; - Sitzungs-ID; - Pakete und Bytes je Richtung; - Sitzungsendgrund; - Drop-Grund. Nach exakt diesen Merkmalen sollte gefiltert werden: ```text source = 192.0.2.100 destination = 198.51.100.25 destination_port = 443 protocol = TCP time = 2026-08-02 10:15:00 bis 10:16:00 ``` Ein fehlender Logeintrag beweist nicht automatisch, dass die Firewall den Datenfluss nicht gesehen hat. Mögliche Gründe: - Protokollierung ist für die Regel deaktiviert; - nur Sitzungsende wird protokolliert; - Sitzung läuft noch; - Ereignisse werden verzögert übertragen; - falscher Clusterknoten wurde geprüft; - falscher Mandant wurde geprüft; - Protokolle werden gefiltert oder begrenzt; - Datenfluss verwendet einen anderen Pfad; - Paket wird vor der normalen Sicherheitsregel verworfen; - Hardware-Offload verwendet andere Diagnosezähler; - Rate Limiting unterdrückt Ereignisse. --- **Erlaubt-, Verworfen- und Sitzungsendgründe unterscheiden** Mögliche Aktionen und Endgründe: | Befund | Mögliche Bedeutung | |---|---| | `allow` | Netzwerkregel hat den Datenfluss zugelassen | | `deny` | Sicherheitsregel hat den Datenfluss verworfen | | `drop` | Paket wurde ohne aktive Ablehnungsantwort verworfen | | `reject` | Firewall sendet eine aktive Ablehnungsantwort | | `reset-client` | Firewall sendet TCP-RST zum Client | | `reset-server` | Firewall sendet TCP-RST zum Server | | `aged-out` | Sitzung ist durch Timeout abgelaufen | | `tcp-rst-from-client` | Client hat die Sitzung beendet | | `tcp-rst-from-server` | Server hat die Sitzung beendet | | `policy-deny` | Richtlinie hat den Aufbau blockiert | | `threat` oder `ips-drop` | Sicherheitsprofil hat blockiert | | `decrypt-error` | TLS-Entschlüsselung ist fehlgeschlagen | | `resources-unavailable` | Kapazitäts- oder Ressourcengrenze | | `invalid-state` | Paket passt nicht zum erwarteten Sitzungszustand | | `no-route` | keine verwendbare Route | | `nat-failure` | NAT-Verarbeitung ist fehlgeschlagen | Die genaue Benennung ist herstellerspezifisch. --- **Policy-Match- und Packet-Tracer-Werkzeuge** Viele Hersteller bieten Werkzeuge an, die einen hypothetischen Datenfluss gegen die aktuelle Konfiguration prüfen. Benötigte Eingaben: ```text Eingangsschnittstelle Quellzone Quelladresse Quellport Zieladresse Zielport Protokoll Benutzer oder Anwendung, sofern erforderlich ``` Solche Werkzeuge können unter anderem zeigen: - Routingentscheidung; - NAT-Regel; - Sicherheitsregel; - Ausgangsschnittstelle; - Zielzone; - zulassende oder verweigernde Phase; - implizite Standardaktion. Ein Simulationsergebnis beweist nicht: - dass das reale Paket die Firewall erreicht; - dass die physische Schnittstelle funktioniert; - dass der Server erreichbar ist; - dass der Rückweg stimmt; - dass die Anwendung antwortet; - dass eine nachgelagerte Firewall erlaubt; - dass ein Sicherheitsprofil den realen Inhalt akzeptiert; - dass derselbe Clusterknoten den realen Datenfluss verarbeitet. Die Simulation muss mit einem realen Test, Protokollen und gegebenenfalls Paketaufzeichnungen kombiniert werden. --- **Cisco IOS ACLs lesend prüfen** Beispielbefehle: ```text show ip access-lists ``` ```text show ip access-lists ``` ```text show running-config | section access-list ``` ```text show running-config | include ip access-group ``` ```text show ip interface ``` Zu prüfen sind: - Reihenfolge der Einträge; - `permit` oder `deny`; - Trefferzähler; - implizites Verbot; - Schnittstellenbindung; - Richtung `in` oder `out`; - Wildcard-Masken; - Protokoll; - Quell- und Zielport; - IPv4- oder IPv6-ACL. Die genaue Syntax hängt von Plattform und Softwareversion ab. --- **Cisco Secure Firewall ASA lesend prüfen** ACLs und Bindungen: ```text show access-list ``` ```text show access-group ``` Verbindungen und NAT: ```text show conn ``` ```text show conn address 192.0.2.100 ``` ```text show xlate ``` Routing: ```text show route ``` Simulation eines TCP-Pakets: ```text packet-tracer input inside tcp 192.0.2.100 53124 198.51.100.25 443 detailed ``` Drop-Zähler: ```text show asp drop ``` `show asp drop` liefert interne Drop-Zähler und ist für gezielte Fehleranalysen vorgesehen. Die Ausgabe ist umfangreich und muss zeitlich mit einem kontrollierten Test korreliert werden. Bei Cisco ASA verwenden normale Zugriffsregeln für NAT-Verkehr die reale Adresse des Ziels. Dieses Verhalten darf nicht ungeprüft auf andere Firewallprodukte übertragen werden. --- **Juniper SRX lesend prüfen** Beispielbefehle: ```text show security policies ``` ```text show security policies hit-count ``` ```text show security flow session ``` ```text show security flow session source-prefix 192.0.2.100 ``` ```text show security flow session destination-prefix 198.51.100.25 ``` ```text show route 198.51.100.25 ``` Für eine Richtlinienzuordnung kann abhängig von Junos-Version und Konfiguration `show security match-policies` verwendet werden. Die vollständige lokale Syntax ist mit der CLI-Hilfe zu prüfen. Juniper-Sicherheitsrichtlinien werden innerhalb des zutreffenden Zonenkontexts in Reihenfolge ausgewertet. Die erste passende Richtlinie bestimmt die Aktion. --- **Palo Alto Networks lesend prüfen** Sitzungssuche: ```text show session all filter source 192.0.2.100 destination 198.51.100.25 destination-port 443 ``` Routingprüfung: ```text test routing fib-lookup virtual-router ip 198.51.100.25 ``` Policy-Match-Tests und genaue Filteroptionen sind versionsabhängig. Vor der Ausführung ist die lokale CLI-Hilfe zu verwenden: ```text test security-policy-match ? ``` ```text show session all filter ? ``` Bei der Auswertung sind unter anderem zu prüfen: - Regelname; - Quell- und Zielzone; - Anwendung; - Dienst; - NAT-Regel; - Sicherheitsprofile; - Sitzungsendgrund; - Pakete und Bytes je Richtung. Palo-Alto-Sicherheitsregeln werden innerhalb der Regelbasis von oben nach unten ausgewertet. Die erste passende Regel wird angewendet. Spezifische Regeln müssen daher vor allgemeineren Regeln stehen. --- **Linux als Netzwerkfirewall lesend prüfen** Wenn ein Linux-System als Router oder Firewall eingesetzt wird, können abhängig von der Konfiguration folgende Prüfungen relevant sein. Aktives nftables-Regelwerk: ```bash sudo nft list ruleset ``` Regelwerk mit Handles: ```bash sudo nft -a list ruleset ``` Routing: ```bash ip route show ``` ```bash ip -6 route show ``` Weiterleitungseinstellung: ```bash sysctl net.ipv4.ip_forward ``` ```bash sysctl net.ipv6.conf.all.forwarding ``` Connection Tracking, sofern das Werkzeug vorhanden ist: ```bash sudo conntrack -L ``` Gezielte Suche: ```bash sudo conntrack -L \ -s 192.0.2.100 \ -d 198.51.100.25 \ -p tcp ``` Zu beachten sind: - richtige Chain; - Hook; - Priorität; - Tabelle; - Familie `ip`, `ip6` oder `inet`; - Eingangs- und Ausgangsschnittstelle; - Default Policy; - NAT-Chain; - Connection-Tracking-Zustand; - Paketzähler; - Weiterleitung im Kernel. Das Löschen von Conntrack-Einträgen ist eine verändernde Maßnahme und darf nicht als erster Diagnoseschritt erfolgen. --- **Paketaufzeichnung an der Firewall** Eine Paketaufzeichnung ist sinnvoll, wenn nicht eindeutig ist: - ob das Paket die Firewall erreicht; - ob es die Firewall wieder verlässt; - ob die Antwort zurückkommt; - ob NAT wie vorgesehen angewendet wird; - ob ein Reset erzeugt wird; - ob Pakete wiederholt werden; - ob nur eine Richtung sichtbar ist; - ob Fragmentierung auftritt; - ob der Datenfluss einen anderen Ausgang verwendet. Idealer Vergleich: ```text Aufzeichnung A: Eingangsschnittstelle Aufzeichnung B: Ausgangsschnittstelle ``` Befundbeispiele: | Eingang | Ausgang | Einordnung | |---|---|---| | Paket nicht sichtbar | Paket nicht sichtbar | Pfad vor der Firewall prüfen | | Paket sichtbar | Paket nicht sichtbar | Firewallverarbeitung, Regel, NAT oder Route prüfen | | Paket mit übersetztem Ziel sichtbar | Paket erreicht Server | Firewall hat Hinverkehr weitergeleitet | | Serverantwort am Ausgangsnetz sichtbar | Antwort nicht zum Clientnetz | Firewallzustand, NAT oder Rückroute prüfen | | vollständiger Verkehr auf beiden Seiten | Client meldet trotzdem Fehler | Host, Anwendung, Proxy oder TLS prüfen | Bei Hardware-Offloading kann eine allgemeine Paketaufzeichnung möglicherweise nicht alle weitergeleiteten Pakete zeigen. Dann sind herstellerspezifische Capture-Funktionen, Dataplane-Diagnosen oder ein externer SPAN/TAP erforderlich. Aufzeichnungen müssen: - zeitlich begrenzt; - auf Quelle und Ziel gefiltert; - vor unberechtigtem Zugriff geschützt; - nach der Auswertung kontrolliert gelöscht oder archiviert; - datenschutzrechtlich und organisatorisch freigegeben werden. --- **Hypothese und Gegenbeweis formulieren** Beispiel: ```text Hypothese: Die allgemeine Freigaberegel mit Priorität 100 erlaubt das gesamte Clientnetz und überschattet die nachfolgende Sperrregel für 192.0.2.66. Erwarteter Befund: Ein Policy-Match-Test für 192.0.2.66 -> 198.51.100.25:443 nennt die allgemeine Freigaberegel. Der Trefferzähler der Sperrregel ändert sich beim Test nicht. Gegenbeweis: Der reale Datenfluss trifft nachweislich die Sperrregel und wird durch diese verworfen. Testmethode: Policy-Match, kontrollierter Verbindungsversuch, Regelzähler und Firewallprotokoll zeitlich korrelieren. Risiko: Nur lesende Diagnose; keine Auswirkung auf Produktivverkehr. Erfolgskriterium: Tatsächlich angewendete Regel ist mit Regel-ID und Logeintrag eindeutig nachgewiesen. ``` Weitere mögliche Hypothesen: - Datenverkehr durchläuft eine andere Firewall. - Falsche Route führt zur falschen Zielzone. - Firewallregel verwendet die öffentliche statt der intern ausgewerteten Adresse. - Eine vorgelagerte globale Regel blockiert vor der lokalen Regel. - Bestehende Sitzung verwendet noch den alten Richtlinienzustand. - Sicherheitsprofil blockiert nach einer erlaubenden Netzwerkregel. - Rückverkehr erreicht einen anderen Clusterknoten. - Eine zustandslose Cloud-ACL blockiert den dynamischen Rückport. - FQDN-Objekt enthält nicht die vom Client verwendete Zieladresse. - IPv4 ist erlaubt, IPv6 jedoch nicht. - Die Regel ist konfiguriert, aber nicht ausgerollt. --- **Kontrollierte Maßnahmen** | Maßnahme | Voraussetzung | Risiko | Rückweg | |---|---|---|---| | Regelreihenfolge korrigieren | Überschattung nachgewiesen | andere Datenflüsse können anders behandelt werden | vorherige Reihenfolge wiederherstellen | | spezifische Freigabe ergänzen | fehlende Freigabe bestätigt | zusätzliche Angriffsfläche | neue Regel deaktivieren oder entfernen | | Adressobjekt korrigieren | Objektinhalt nachweislich falsch | alle Regeln mit diesem Objekt betroffen | vorherigen Objektstand wiederherstellen | | Dienstobjekt korrigieren | Port oder Protokoll falsch | weitere Anwendungen können betroffen sein | vorherige Definition wiederherstellen | | Zonenbezug korrigieren | tatsächlicher Pfad nachgewiesen | Segmentierungswirkung ändert sich | vorherige Zonenregel wiederherstellen | | NAT-Regel korrigieren | Übersetzungsfehler bestätigt | Erreichbarkeit und Rückweg ändern sich | vorherige NAT-Regel aktivieren | | Route korrigieren | falsche Ausgangszone oder falscher Next Hop | viele Ziele können betroffen sein | vorherige Route wiederherstellen | | Logging aktivieren | fehlende Beweisdaten | zusätzliche Last und Datenmenge | Logging zurücknehmen | | einzelne Sitzung beenden | alte Sitzung beeinflusst Test | eine produktive Verbindung wird unterbrochen | Anwendung baut neue Sitzung auf | | Timeout anpassen | zeitabhängiger Sitzungsabbruch nachgewiesen | höhere Sitzungsanzahl und Ressourcennutzung | alten Timeoutwert wiederherstellen | | Sicherheitsprofil korrigieren | Fehlklassifizierung nachgewiesen | Schutzwirkung kann sinken | vorheriges Profil wiederherstellen | | Cluster-Synchronisation reparieren | Zustandsabweichung nachgewiesen | Failover- und Sitzungsrisiko | herstellerspezifischer Rückfallplan | Eine allgemeine Testfreigabe ist kein geeigneter Ersatz für eine präzise Ursachenanalyse. --- **Vollständiger Diagnoseablauf** 1. Exakte Fehlermeldung, Anwendung, Client, Benutzer und Uhrzeit dokumentieren. 2. Quelladresse und tatsächlichen Quellport bestimmen. 3. Zieladresse, Zielport und Protokoll bestimmen. 4. IPv4 und IPv6 unterscheiden. 5. Erwarteten Datenfluss und Sollzustand dokumentieren. 6. Umfang der Störung bestimmen. 7. Host-Firewalls als eigene Filterebenen berücksichtigen. 8. Direkte Erreichbarkeit und Dienstzustand prüfen. 9. Erwarteten Netzwerkpfad dokumentieren. 10. Tatsächlichen Firewallpfad nachweisen. 11. Aktiven Firewall- oder Clusterknoten bestimmen. 12. Richtigen Mandanten und virtuellen Kontext bestimmen. 13. Eingangs- und Ausgangsschnittstelle bestimmen. 14. Quell- und Zielzone bestimmen. 15. Route zur Zieladresse prüfen. 16. Policy-Based Routing, VRF und Tunnel berücksichtigen. 17. Originaladressen und Originalports dokumentieren. 18. NAT-Adressen und NAT-Ports dokumentieren. 19. Aktive NAT-Regel bestimmen. 20. Aktive Sicherheitsrichtlinie bestimmen. 21. Regelreihenfolge und Prioritäten prüfen. 22. Globale, geerbte und lokale Regeln berücksichtigen. 23. Implizite Standardaktion bestimmen. 24. Adress-, Dienst- und FQDN-Objekte auflösen. 25. Zeitpläne und Identitätskriterien prüfen. 26. Anwendungs- und Sicherheitsprofile prüfen. 27. Policy-Match- oder Packet-Tracer-Test durchführen. 28. Ergebnis nicht mit realem Durchsatz gleichsetzen. 29. Regelzähler mit Ausgangswert dokumentieren. 30. Genau einen kontrollierten Verbindungstest ausführen. 31. Zähleränderung und Protokolle auswerten. 32. Sitzungstabelle prüfen. 33. TCP-, UDP- oder ICMP-Zustand auswerten. 34. Pakete und Bytes je Richtung vergleichen. 35. Sitzungsendgrund auswerten. 36. Bestehende und neue Sitzung unterscheiden. 37. Bei Bedarf Eingangs- und Ausgangsaufzeichnung durchführen. 38. Hin- und Rückverkehr vergleichen. 39. Cluster- und Zustandssynchronisation prüfen. 40. Weitere Cloud- oder Subnetz-ACLs prüfen. 41. Hypothese, erwarteten Befund und Gegenbeweis formulieren. 42. Genau eine kontrollierte Maßnahme vorbereiten. 43. Risiko, Rückweg und Erfolgskriterium dokumentieren. 44. Maßnahme freigeben und umsetzen. 45. Neue Verbindung mit identischen Parametern testen. 46. Regel, Sitzung, Pakete, Bytes und Anwendungsergebnis verifizieren. 47. Repräsentative weitere Datenflüsse auf Nebenwirkungen prüfen. 48. Temporäre Logging- und Testregeln zurücknehmen. 49. Ursache, Maßnahme und Prävention dokumentieren. --- **Befundmatrix** | Befund | Mögliche Einordnung | Nächster Nachweis | |---|---|---| | kein Firewalllog | falscher Pfad, Logging deaktiviert oder früher Drop | Route, Capture und Regelprotokollierung prüfen | | `deny` durch erwartete Regel | Freigabe fehlt oder Regelinhalt falsch | Regelkriterien und Sollzustand vergleichen | | `deny` durch andere Regel | Überschattung oder falscher Kontext | Reihenfolge und Priorität prüfen | | implizites `deny` | keine ausdrückliche Regel passt | Zonen, Adressen, Protokoll und Ports prüfen | | Allow-Regel hat Zähler null | Verkehr trifft Regel nicht | Pfad, Bindung, Kontext und Objekte prüfen | | Allow-Regel zählt, Anwendung scheitert | späterer Filter, Rückweg oder Anwendung | Sitzungsende, Sicherheitsprofil und Capture | | nur Hinpakete gezählt | Rückweg oder Serverantwort fehlt | Serverseite und Rückroute prüfen | | Pakete in beide Richtungen, null Nutzdaten | Handshake- oder Anwendungsproblem | TCP-Flags, TLS und Anwendung prüfen | | Sitzung `aged-out` | keine Antwort oder Idle-Timeout | Paketfluss und Timeoutdauer prüfen | | Sitzung endet mit Server-RST | Server oder Zwischenkomponente lehnt ab | servernahe Aufzeichnung und Dienstprotokoll | | Sitzung endet mit Client-RST | Client oder Anwendung beendet | Clientaufzeichnung und Anwendungsprotokoll | | Policy-Test erlaubt, reales Paket fehlt | Firewall wird nicht erreicht | vorgelagertes Routing und Filter prüfen | | Policy-Test erlaubt, reales Paket wird verworfen | zusätzliche Prüfung oder Zustand | Drop-Grund und Sicherheitsprofil | | Zielzone unerwartet | Route oder VRF falsch | Routingentscheidung prüfen | | NAT-Ziel unerwartet | falsche oder frühere NAT-Regel | NAT-Reihenfolge und Übersetzungstabelle | | neue Verbindung scheitert, alte funktioniert | neue Richtlinie oder NAT-Entscheidung | alte und neue Sitzung vergleichen | | alte Verbindung scheitert, neue funktioniert | veralteter Sitzungszustand | gezielt einzelne Sitzung untersuchen | | nur UDP-Rückverkehr fehlt | stateless ACL oder Timeout | Gegenrichtung und UDP-Sitzung prüfen | | nur große Pakete scheitern | MTU, Fragmentierung oder ICMP-Block | Paketgröße und ICMP-Fehler prüfen | | nur IPv6 scheitert | fehlende IPv6-Regel oder Route | IPv6-Regelwerk und `ip -6 route` | | nur ein Clusterknoten betroffen | Konfigurations- oder Zustandsabweichung | Knoten direkt vergleichen | | AWS Security Group erlaubt, Verkehr scheitert | NACL, Route, Hostfilter oder Dienst | alle Filterebenen prüfen | | AWS NACL erlaubt Hinweg, Rückweg fehlt | zustandslose Rückregel fehlt | dynamischen Rückportbereich prüfen | | Azure NSG-Regel vorhanden, trifft nicht | Priorität oder andere NSG | effektive Regeln an NIC und Subnetz | | `allow`, danach Threat-Drop | Sicherheitsprofil blockiert | Bedrohungs- oder IPS-Protokoll | | FQDN-Regel trifft nicht | andere DNS-Auflösung | Firewall- und Clientauflösung vergleichen | | nur bestimmte Uhrzeit betroffen | Regelzeitplan oder automatisches Deployment | Zeitplan und Änderungsprotokoll | | nur nach Failover betroffen | Sitzungs- oder NAT-Synchronisation | HA-Status und neue Sitzung prüfen | --- **Typische Diagnosefehler** - Netzwerkfirewall und Host-Firewall verwechseln. - Nur den vorgesehenen und nicht den tatsächlichen Netzwerkpfad betrachten. - Von einer vorhandenen Regel auf eine wirksame Regel schließen. - Quellport und Zielport verwechseln. - Eingehend oder ausgehend ohne Bezug auf Schnittstelle oder Ressource angeben. - Sicherheitszonen nicht dokumentieren. - Regelreihenfolge ignorieren. - Implizite Verweigerung übersehen. - Globale oder geerbte Regeln nicht berücksichtigen. - Regel in falschem Mandanten oder Kontext prüfen. - Definierte, aber nicht gebundene ACL übersehen. - Bearbeitete und aktive Konfiguration verwechseln. - Fehlerhaftes Deployment nicht prüfen. - Adressobjekte nur nach Namen bewerten. - Verschachtelte Objektgruppen nicht auflösen. - Wildcard-Maske als Subnetzmaske lesen. - IPv4-Freigabe als IPv6-Freigabe interpretieren. - FQDN-Auflösung der Firewall nicht mit der Clientauflösung vergleichen. - Öffentliche und private NAT-Adresse verwechseln. - Herstellerabhängige NAT-Reihenfolge annehmen. - Falsche Route durch eine zusätzliche Firewallfreigabe verdecken. - Eine `allow`-Aktion als vollständigen Erfolgsnachweis bewerten. - Sicherheitsprofile und Anwendungserkennung ignorieren. - Policy-Simulation als Nachweis realer Weiterleitung verwenden. - Nur einen Clusterknoten prüfen. - Sitzungszähler ohne Zeitbezug auswerten. - Regelzähler vor der Beweissicherung zurücksetzen. - Alte und neue Sitzungen nicht unterscheiden. - Sitzungstabelle vollständig löschen. - UDP wie TCP diagnostizieren. - Bei zustandsloser ACL den Rückverkehr vergessen. - ICMP pauschal sperren. - Nur Echo-Anfragen als ICMP betrachten. - Pro Verbindungstest mehrere Variablen ändern. - Paketaufzeichnung ohne präzisen Filter starten. - Nur die Eingangsschnittstelle aufzeichnen. - Hardware-Offloading bei Captures ignorieren. - Firewall vorsorglich neu starten. - Allgemeine `any any`-Regel als Test erstellen. - Temporäre Freigaben oder Protokollierungen aktiv lassen. - Nur das Diagnosewerkzeug und nicht die ursprüngliche Anwendung testen. - Ursache und Präventionsmaßnahme nicht dokumentieren. --- **Verifikation** Nach einer Maßnahme müssen mindestens folgende Punkte geprüft werden: - Client verwendet die erwartete Quelladresse; - Zieladresse entspricht dem Sollzustand; - Protokoll und Zielport sind korrekt; - der Datenfluss durchläuft die vorgesehene Firewall; - richtiger Clusterknoten und Kontext werden verwendet; - Eingangs- und Ausgangszone sind korrekt; - Routingentscheidung ist korrekt; - NAT verwendet die erwarteten Adressen und Ports; - die vorgesehene Sicherheitsregel trifft; - keine allgemeinere Regel überschattet sie; - Regelzähler steigt beim kontrollierten Test; - Firewallprotokoll enthält die erwartete Aktion; - keine nachgelagerte Sicherheitsprüfung blockiert; - Sitzung wird korrekt angelegt; - TCP-Handshake wird vollständig abgeschlossen; - UDP-Antwort wird der Sitzung zugeordnet; - benötigte ICMP-Fehlermeldungen werden transportiert; - Pakete und Bytes sind in beiden Richtungen plausibel; - Sitzungsendgrund ist erwartungsgemäß; - neue Verbindung funktioniert; - bestehende Verbindungen wurden nicht unbeabsichtigt beeinflusst; - IPv4 und IPv6 funktionieren, sofern erforderlich; - weitere repräsentative Quellen funktionieren; - weitere repräsentative Ziele funktionieren; - Hochverfügbarkeit und Synchronisation sind fehlerfrei; - Cloud-Sicherheitsgruppen und Subnetz-ACLs sind konsistent; - ursprüngliche Anwendung funktioniert; - temporäre Testregeln wurden entfernt; - temporäre Protokollierung wurde zurückgenommen; - Konfigurationsstand wurde gesichert; - Ursache, Änderung, Rückweg und Prävention wurden dokumentiert. Eine erfolgreiche Policy-Simulation oder ein einzelner steigender Regelzähler ist keine ausreichende Gesamtverifikation. --- **Dokumentationsvorlage** ```text Störung: Datum und Uhrzeit: Betroffene Anwendung: Quelle: Ziel: Protokoll: Erwarteter Pfad: Tatsächlicher Pfad: Firewall: Virtueller Kontext: Eingang: Ausgang: Originaldatenfluss: Ziel-IP:Port> Übersetzter Datenfluss: NAT-Ziel-IP:Port> Routingentscheidung: Erwartete Regel: Tatsächlich passende Regel: Sicherheitsprofile: Sitzungs-ID: Pakete und Bytes: Sitzungsendgrund: Protokollbefund: Paketaufzeichnung: Hypothese: Erwarteter Nachweis: Gegenbeweis: Nachgewiesene Ursache: Durchgeführte Maßnahme: Risiko: Rückweg: Verifikation: Prävention: ``` --- **Checkliste** - [ ] exakte Fehlermeldung dokumentiert - [ ] Datum, Uhrzeit und Zeitzone erfasst - [ ] betroffenen Client erfasst - [ ] betroffene Anwendung erfasst - [ ] Quelladresse ermittelt - [ ] Quellport ermittelt - [ ] Zieladresse ermittelt - [ ] Zielport ermittelt - [ ] Protokoll bestimmt - [ ] IPv4 und IPv6 unterschieden - [ ] erwarteten Datenfluss dokumentiert - [ ] Fehlerumfang bestimmt - [ ] lokale Host-Firewalls berücksichtigt - [ ] tatsächlichen Netzwerkpfad nachgewiesen - [ ] tatsächlich durchlaufene Firewall bestimmt - [ ] aktiven Clusterknoten bestimmt - [ ] richtigen Mandanten oder Kontext bestimmt - [ ] Eingangsschnittstelle bestimmt - [ ] Ausgangsschnittstelle bestimmt - [ ] Quellzone bestimmt - [ ] Zielzone bestimmt - [ ] Routingentscheidung geprüft - [ ] VRF oder virtuellen Router geprüft - [ ] Policy-Based Routing berücksichtigt - [ ] Originaladressen dokumentiert - [ ] Originalports dokumentiert - [ ] NAT-Adressen dokumentiert - [ ] NAT-Ports dokumentiert - [ ] NAT-Regel bestimmt - [ ] aktive Sicherheitsrichtlinie bestimmt - [ ] Regel-ID dokumentiert - [ ] Regelposition oder Priorität dokumentiert - [ ] Regelreihenfolge geprüft - [ ] globale Regeln geprüft - [ ] geerbte Regeln geprüft - [ ] implizite Standardaktion geprüft - [ ] ACL-Bindung geprüft - [ ] aktive Konfigurationsversion geprüft - [ ] Deploymentstatus geprüft - [ ] Cluster-Synchronisation geprüft - [ ] Quellobjekt aufgelöst - [ ] Zielobjekt aufgelöst - [ ] Dienstobjekt aufgelöst - [ ] verschachtelte Gruppen geprüft - [ ] FQDN-Objekt geprüft - [ ] Firewall- und Client-DNS-Ergebnis verglichen - [ ] Zeitplan geprüft - [ ] Benutzer- oder Geräteidentität geprüft - [ ] erkannte Anwendung geprüft - [ ] Sicherheitsprofile geprüft - [ ] Policy-Match-Test durchgeführt - [ ] Simulation nicht als alleinigen Nachweis verwendet - [ ] Ausgangszähler dokumentiert - [ ] kontrollierten Test durchgeführt - [ ] Regelzähler erneut geprüft - [ ] Firewallprotokolle korreliert - [ ] erlaubende und blockierende Ereignisse unterschieden - [ ] Sitzungstabelle geprüft - [ ] Sitzungs-ID dokumentiert - [ ] TCP-Zustand geprüft - [ ] UDP-Pseudositzung berücksichtigt - [ ] ICMP-Typ und Code berücksichtigt - [ ] Pakete je Richtung geprüft - [ ] Bytes je Richtung geprüft - [ ] Sitzungsendgrund ausgewertet - [ ] bestehende und neue Sitzung unterschieden - [ ] Sitzungstimeouts geprüft - [ ] bei Bedarf Eingangscapture durchgeführt - [ ] bei Bedarf Ausgangscapture durchgeführt - [ ] Hin- und Rückverkehr verglichen - [ ] Hardware-Offloading berücksichtigt - [ ] weitere Netzwerk-ACLs geprüft - [ ] Cloud Security Groups geprüft - [ ] Cloud-Subnetz-ACLs geprüft - [ ] Hypothese formuliert - [ ] Gegenbeweis definiert - [ ] Risiko dokumentiert - [ ] Rückweg dokumentiert - [ ] nur eine kontrollierte Maßnahme durchgeführt - [ ] identischen Test wiederholt - [ ] ursprüngliche Anwendung verifiziert - [ ] repräsentative weitere Datenflüsse geprüft - [ ] temporäre Testregel entfernt - [ ] temporäre Protokollierung zurückgenommen - [ ] Ursache und Prävention dokumentiert --- **Schnellreferenz** | Aufgabe | Beispiel | |---|---| | Datenfluss dokumentieren | `192.0.2.100:53124 -> 198.51.100.25:443/TCP` | | Cisco IOS ACLs anzeigen | `show ip access-lists` | | Cisco IOS ACL-Bindung prüfen | `show ip interface` | | ASA ACLs anzeigen | `show access-list` | | ASA ACL-Bindung anzeigen | `show access-group` | | ASA Sitzungen anzeigen | `show conn` | | ASA Sitzung nach Adresse filtern | `show conn address 192.0.2.100` | | ASA NAT-Zustand anzeigen | `show xlate` | | ASA Route anzeigen | `show route` | | ASA Datenfluss simulieren | `packet-tracer input inside tcp 192.0.2.100 53124 198.51.100.25 443 detailed` | | ASA Drop-Zähler anzeigen | `show asp drop` | | Juniper Policies anzeigen | `show security policies` | | Juniper Policy-Treffer anzeigen | `show security policies hit-count` | | Juniper Sitzungen anzeigen | `show security flow session` | | Juniper Route prüfen | `show route 198.51.100.25` | | Palo Alto Sitzung suchen | `show session all filter source 192.0.2.100 destination 198.51.100.25 destination-port 443` | | Palo Alto Route prüfen | `test routing fib-lookup virtual-router ip 198.51.100.25` | | Linux nftables anzeigen | `sudo nft list ruleset` | | Linux nftables mit Handles | `sudo nft -a list ruleset` | | Linux Routing anzeigen | `ip route show` | | Linux IPv6-Routing anzeigen | `ip -6 route show` | | Linux Conntrack anzeigen | `sudo conntrack -L` | Befehle, die nicht als erste Diagnosemaßnahme verwendet werden dürfen: ```text clear conn clear xlate clear access-list counters clear security flow session clear session all conntrack -F nft flush ruleset iptables -F policy commit ohne geprüften Änderungsplan Firewall deaktivieren Cluster-Failover erzwingen Firewalldienst neu starten allgemeine any-any-Freigabe erstellen Sicherheitsprofile global deaktivieren ``` --- **Quellen** **Grundlagen und Standards** - [NIST SP 800-41 Revision 1 – Guidelines on Firewalls and Firewall Policy](https://csrc.nist.gov/pubs/sp/800/41/r1/final) - [RFC 793 – Transmission Control Protocol](https://datatracker.ietf.org/doc/html/rfc793) - [RFC 9293 – Transmission Control Protocol](https://datatracker.ietf.org/doc/html/rfc9293) - [RFC 768 – User Datagram Protocol](https://datatracker.ietf.org/doc/html/rfc768) - [RFC 792 – Internet Control Message Protocol](https://datatracker.ietf.org/doc/html/rfc792) - [RFC 4443 – Internet Control Message Protocol for IPv6](https://datatracker.ietf.org/doc/html/rfc4443) - [RFC 3022 – Traditional IP Network Address Translator](https://datatracker.ietf.org/doc/html/rfc3022) - [RFC 4787 – NAT Behavioral Requirements for UDP](https://datatracker.ietf.org/doc/html/rfc4787) - [RFC 7857 – NAT Behavioral Requirements Updates](https://datatracker.ietf.org/doc/html/rfc7857) **Cisco** - [Cisco – Configure IP Access Lists](https://www.cisco.com/c/en/us/support/docs/security/ios-firewall/23602-confaccesslists.html) - [Cisco Secure Firewall ASA – Access Rules](https://www.cisco.com/c/en/us/td/docs/security/asa/asa919/configuration/firewall/asa-919-firewall-config/access-rules.html) - [Cisco Secure Firewall ASA – `packet-tracer` Command Reference](https://www.cisco.com/c/en/us/td/docs/security/asa/asa-cli-reference/I-R/asa-command-ref-I-R/pa-pn-commands.html) - [Cisco Secure Firewall ASA – `show` Command Reference](https://www.cisco.com/c/en/us/td/docs/security/asa/asa-cli-reference/S/asa-command-ref-S/show-t-commands.html) - [Cisco Secure Firewall ASA – `show asp drop` Usage](https://www.cisco.com/c/en/us/td/docs/security/asa/asa-cli-reference/show_asp_drop_command_usage/show-asp-drop-command-usage.html) **Juniper Networks** - [Juniper – Configuring Security Policies](https://www.juniper.net/documentation/us/en/software/junos/security-policies/topics/topic-map/security-policy-configuration.html) - [Juniper – Reordering Security Policies](https://www.juniper.net/documentation/us/en/software/junos/security-policies/topics/topic-map/security-reordering-policies.html) - [Juniper – `show security match-policies`](https://www.juniper.net/documentation/us/en/software/junos/cli-reference/topics/ref/command/show-security-match-policies.html) - [Juniper – Monitoring and Troubleshooting Security Policies](https://www.juniper.net/documentation/us/en/software/junos/security-policies/topics/topic-map/monitoring-troubleshooting-security-policy.html) **Palo Alto Networks** - [Palo Alto Networks – Security Policy Rules](https://docs.paloaltonetworks.com/network-security/security-policy/administration/security-rules) - [Palo Alto Networks – Security Policy](https://docs.paloaltonetworks.com/network-security/security-policy/administration/security-policy) - [Palo Alto Networks – Security Policy Rule Best Practices](https://docs.paloaltonetworks.com/best-practices/security-policy-best-practices/security-policy-best-practices/deploy-security-policy-best-practices/security-policy-rule-best-practices) - [Palo Alto Networks – Traffic Log Fields](https://docs.paloaltonetworks.com/pan-os/10-1/pan-os-admin/monitoring/use-syslog-for-monitoring/syslog-field-descriptions/traffic-log-fields) **Amazon Web Services** - [AWS – Control Subnet Traffic with Network ACLs](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html) - [AWS – Control Traffic Using Security Groups](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-security-groups.html) - [AWS – Security Group Rules](https://docs.aws.amazon.com/vpc/latest/userguide/security-group-rules.html) - [AWS – Network ACL Examples](https://docs.aws.amazon.com/vpc/latest/userguide/nacl-examples.html) - [AWS – Infrastructure Security in Amazon VPC](https://docs.aws.amazon.com/vpc/latest/userguide/infrastructure-security.html) **Microsoft Azure** - [Microsoft Learn – Azure Network Security Groups Overview](https://learn.microsoft.com/en-us/azure/virtual-network/network-security-groups-overview) - [Microsoft Learn – Azure Firewall Rule Processing Logic](https://learn.microsoft.com/en-us/azure/firewall/rule-processing) - [Microsoft Learn – Azure Virtual Network Traffic Routing](https://learn.microsoft.com/en-us/azure/virtual-network/virtual-networks-udr-overview) - [Microsoft Learn – Azure Network Security Best Practices](https://learn.microsoft.com/en-us/azure/security/fundamentals/network-best-practices) Für diese Seite wurden keine Community-Beiträge oder Hersteller-Social-Media-Aussagen als fachlicher Nachweis verwendet. # 9.6 Asymmetrische Pfade, Sessiontabellen und Connection Tracking Bei asymmetrischem Routing verwenden Hin- und Rückverkehr einer Kommunikation unterschiedliche Netzwerkpfade. Für gewöhnliche Router ist das nicht grundsätzlich fehlerhaft: Jeder Router entscheidet für jedes Paket anhand seiner eigenen Routingtabelle. Zustandsbehaftete Firewalls, NAT-Gateways, Load Balancer und andere Stateful-Systeme müssen jedoch zusammengehörige Pakete einer gespeicherten Sitzung zuordnen können. Erreicht der Verbindungsaufbau eine Firewall, der Rückverkehr aber eine andere Firewall ohne synchronisierten Sitzungszustand, kann das Antwortpaket als unbekannt oder ungültig verworfen werden. Eine vorhandene Freigaberegel löst dieses Problem nicht, weil nicht die Regel, sondern der fehlende Sitzungszustand die Ursache ist. --- **Ziele** Nach der Bearbeitung dieser Seite soll nachvollziehbar geprüft werden können: - ob Hin- und Rückverkehr denselben zustandsbehafteten Datenpfad verwenden; - welche Firewall oder welcher Clusterknoten eine Sitzung angelegt hat; - ob eine passende Sitzungstabelle vorhanden ist; - welchen Zustand eine TCP-, UDP- oder ICMP-Kommunikation besitzt; - ob Connection Tracking ausgelastet oder fehlerhaft ist; - ob ECMP, Policy-Based Routing, dynamisches Routing oder NAT eine Asymmetrie erzeugt; - ob Sitzungszustände zwischen HA-Knoten synchronisiert werden; - ob bestehende Sitzungen einen Test verfälschen; - an welcher Stelle der Hin- oder Rückweg abweicht; - wie eine Routing- oder Sitzungsänderung kontrolliert verifiziert wird. --- **Sicherheits- und Änderungsgrundsätze** Sessiontabellen und Connection Tracking enthalten den aktuellen Zustand produktiver Verbindungen. Unkontrollierte Eingriffe können gleichzeitig unterbrechen: - Benutzerverbindungen; - Datenbankverbindungen; - VPN-Tunnel; - Dateiübertragungen; - VoIP-Sitzungen; - Streamingverbindungen; - Backups; - Replikation; - Clusterkommunikation; - Verwaltungszugriffe. Nicht als erste Diagnosemaßnahme geeignet sind: - vollständige Sessiontabelle löschen; - Conntrack-Tabelle leeren; - Firewallcluster neu starten; - Failover erzwingen; - Routingprotokoll neu starten; - ECMP vollständig deaktivieren; - produktive Routen ungeprüft entfernen; - Source NAT pauschal aktivieren; - Stateful Inspection deaktivieren; - TCP State Bypass einschalten; - Timeouts ohne Nachweis erhöhen; - Conntrack-Maximalwert ohne Kapazitätsprüfung verändern; - Hardware-Offloading global abschalten; - allgemeine Stateless-Regeln erstellen; - Paketprüfungen global lockern. Vor einer Änderung sind mindestens zu dokumentieren: - Ausgangszustand; - betroffene Datenflüsse; - aktuelle Route in beiden Richtungen; - aktive Sitzung; - zuständiger Firewallknoten; - NAT-Zustand; - Clusterzustand; - Risiko; - Rückweg; - Erfolgskriterium; - Wartungsfenster; - verantwortliche Freigabe. --- **Symmetrischen und asymmetrischen Pfad unterscheiden** Symmetrischer Pfad: ```text Hinweg: Client -> Router A -> Firewall A -> Router B -> Server Rückweg: Server -> Router B -> Firewall A -> Router A -> Client ``` Asymmetrischer Pfad: ```text Hinweg: Client -> Router A -> Firewall A -> Router B -> Server Rückweg: Server -> Router C -> Firewall B -> Router D -> Client ``` Entscheidend ist nicht, ob jeder einzelne Router identisch ist. Entscheidend ist, ob zustandsabhängige Komponenten in beiden Richtungen den benötigten Sitzungszustand besitzen. | Situation | Mögliche Wirkung | |---|---| | Hin- und Rückweg nutzen dieselbe Stateful Firewall | Sitzung kann normalerweise korrekt zugeordnet werden | | unterschiedliche Router, aber dieselbe Firewall | kann funktionieren | | unterschiedliche Clusterknoten mit funktionierender State-Synchronisation | kann funktionieren | | unterschiedliche nicht synchronisierte Firewalls | Rückverkehr kann verworfen werden | | rein zustandslose ACLs in beiden Richtungen | kann mit passenden Gegenregeln funktionieren | | NAT nur auf dem Hinweggerät | Rückverkehr kann falsches Ziel oder falschen Pfad verwenden | | asymmetrischer Pfad durch Sicherheitsprofil | vollständige Inhaltsprüfung kann unmöglich sein | | Rückweg umgeht die Firewall vollständig | Firewall sieht nur eine Richtung und Protokolle bleiben unvollständig | --- **Asymmetrie ist nicht automatisch ein Routingfehler** IP-Routing verlangt nicht grundsätzlich, dass Hin- und Rückweg identisch sind. Asymmetrie wird problematisch, wenn eine beteiligte Komponente Informationen aus beiden Richtungen benötigt. Typische zustandsabhängige Komponenten: - Stateful Firewall; - NAT-Gateway; - Intrusion Prevention System; - Application Delivery Controller; - Load Balancer; - Reverse Proxy; - VPN-Gateway; - WAN-Optimierer; - DDoS-Schutzsystem; - Carrier-Grade NAT; - Cloud Network Firewall; - Linux-Router mit Netfilter Connection Tracking. Die Diagnosefrage lautet deshalb nicht nur: ```text Existiert ein Rückweg? ``` Sondern: ```text Verwendet der Rückweg alle zustandsabhängigen Komponenten, die den Hinweg verarbeitet haben? ``` --- **Einen Datenfluss eindeutig identifizieren** Für TCP und UDP wird ein Datenfluss üblicherweise über das Fünf-Tupel beschrieben: ```text Quelladresse Quellport Zieladresse Zielport IP-Protokoll ``` Beispiel: ```text Originalrichtung: 192.0.2.100:53124 -> 198.51.100.25:443/TCP Antwortrichtung: 198.51.100.25:443 -> 192.0.2.100:53124/TCP ``` Zusätzlich zu dokumentieren sind: - Datum und Uhrzeit; - Zeitzone; - Eingangs- und Ausgangsschnittstelle; - Quell- und Zielzone; - VRF oder Routinginstanz; - ursprüngliche Adressen; - übersetzte Adressen; - ursprüngliche Ports; - übersetzte Ports; - Firewallknoten; - Sitzungs-ID; - Routingentscheidung; - Anwendung; - Tunnel oder VPN; - Mandant oder virtueller Kontext. Nur die Zieladresse und den Zielport zu dokumentieren reicht nicht. Mehrere gleichzeitige Sitzungen können dasselbe Ziel verwenden und sich nur durch Quelladresse oder Quellport unterscheiden. --- **Sessiontabelle und Connection Tracking** Eine Sessiontabelle speichert Informationen über aktuell bekannte Datenflüsse. Linux Netfilter bezeichnet diese Funktion als Connection Tracking oder kurz Conntrack. Ein Eintrag kann unter anderem enthalten: ```text IP-Protokoll Original-Quelladresse Original-Quellport Original-Zieladresse Original-Zielport Antwort-Quelladresse Antwort-Quellport Antwort-Zieladresse Antwort-Zielport TCP-Zustand NAT-Status Sitzungsmarkierung Timeout Pakete je Richtung Bytes je Richtung erkannte Anwendung passende Richtlinie Eingangs- und Ausgangsschnittstelle Clusterbesitzer ``` Die Sessiontabelle ermöglicht unter anderem: - Rückverkehr einer erlaubten Verbindung zuordnen; - ungültige TCP-Pakete erkennen; - UDP-Antworten einer Pseudositzung zuordnen; - ICMP-Fehler einer ursprünglichen Kommunikation zuordnen; - NAT in beiden Richtungen konsistent anwenden; - zusammengehörige Anwendungsdatenflüsse erkennen; - Sitzungen zwischen HA-Knoten synchronisieren. --- **Conntrack-Zustände** Bei Netfilter und vergleichbaren Systemen werden häufig folgende generische Zustände unterschieden: | Zustand | Bedeutung | |---|---| | `NEW` | gültiger Beginn oder frühes Paket eines noch nicht in beide Richtungen bestätigten Datenflusses | | `ESTABLISHED` | gültige Pakete wurden in beiden Richtungen gesehen | | `RELATED` | neuer Datenfluss steht in erwarteter Beziehung zu einer vorhandenen Verbindung | | `INVALID` | Paket kann keiner gültigen Verbindung zugeordnet werden oder verletzt Erwartungen | | `UNTRACKED` | Paket wurde ausdrücklich von Connection Tracking ausgenommen | Die Zustände sind nicht mit dem gleichnamigen TCP-Zustand `ESTABLISHED` gleichzusetzen. Ein Firewall- oder Conntrack-Zustand beschreibt die Sicht des Tracking-Systems. Beispiel eines üblichen nftables-Prinzips: ```nft ct state established,related accept ct state invalid drop ``` Das ist nur ein vereinfachtes Beispiel. Das vollständige Regelwerk, die Richtung und der Sicherheitsbedarf müssen separat geprüft werden. --- **TCP-Zustände innerhalb der Sitzung** TCP besitzt zusätzlich protokollspezifische Zustände. | Zustand | Einordnung | |---|---| | `SYN_SENT` | Verbindungsanfrage wurde in Originalrichtung gesehen | | `SYN_RECV` | passende Antwort mit SYN und ACK wurde gesehen | | `ESTABLISHED` | TCP-Verbindungsaufbau wurde bestätigt | | `FIN_WAIT` | eine Seite hat die reguläre Beendigung begonnen | | `CLOSE_WAIT` | Gegenstelle hat die Beendigung begonnen | | `LAST_ACK` | letztes Bestätigungspaket für Verbindungsabbau wird erwartet | | `TIME_WAIT` | Schutzphase nach regulärem Verbindungsende | | `CLOSE` | Verbindung gilt als geschlossen | | `RETRANS` oder vergleichbarer Zustand | Wiederholungen oder fehlende Bestätigungen wurden erkannt | | `UNACK` | Daten oder Steuerinformationen wurden noch nicht bestätigt | Die genaue Benennung und Zustandslogik hängen vom verwendeten Produkt ab. --- **Typischen Conntrack-Eintrag lesen** Beispiel: ```text tcp 6 431982 ESTABLISHED src=192.0.2.100 dst=198.51.100.25 sport=53124 dport=443 src=198.51.100.25 dst=192.0.2.100 sport=443 dport=53124 packets=169 bytes=14322 packets=113 bytes=34787 [ASSURED] ``` Einordnung: | Feld | Bedeutung | |---|---| | `tcp` | Transportprotokoll | | `6` | IP-Protokollnummer für TCP | | `431982` | verbleibender Timeout in Sekunden | | `ESTABLISHED` | protokollspezifischer Tracking-Zustand | | erster Adressblock | Originalrichtung | | zweiter Adressblock | Antwortrichtung | | `packets` | gezählte Pakete der jeweiligen Richtung | | `bytes` | gezählte Bytes der jeweiligen Richtung | | `[ASSURED]` | Antwortverkehr und ausreichend bestätigter Zustand wurden erkannt | Die genaue Darstellung hängt von Kernel-, Conntrack- und Distributionsversion ab. --- **Wichtige Conntrack-Markierungen** | Markierung | Bedeutung | |---|---| | `[UNREPLIED]` | bisher wurde keine passende Antwortrichtung gesehen | | `[ASSURED]` | der Datenfluss wurde in beiden Richtungen ausreichend bestätigt | | `src-nat` | Quellübersetzung ist beteiligt | | `dst-nat` | Zielübersetzung ist beteiligt | | `expected` | Datenfluss wurde durch eine Erwartung einer anderen Verbindung angekündigt | | `seen-reply` | Antwortverkehr wurde erkannt | | `offload` | Sitzung wurde in einen beschleunigten Datenpfad ausgelagert | | `hw-offload` | Verarbeitung erfolgt zumindest teilweise in Hardware | `[UNREPLIED]` bedeutet nicht automatisch, dass der Server nicht geantwortet hat. Die Antwort könnte: - einen anderen Rückweg genommen haben; - vor dem Tracking-System verworfen worden sein; - nach dem Timeout eingetroffen sein; - eine abweichende Adresse oder einen abweichenden Port verwenden; - von einer anderen Firewall verarbeitet worden sein. --- **RELATED-Verbindungen und Erwartungen** Einige Protokolle verwenden zusätzliche Datenverbindungen, die zu einer bestehenden Steuerverbindung gehören. Mögliche Beispiele: - FTP; - bestimmte RPC-Verfahren; - SIP und dynamische Medienströme; - TFTP; - ältere oder herstellerspezifische Protokolle. Ein Connection-Tracking-Helper kann für den zusätzlichen Datenfluss eine Erwartung anlegen. Dieser Datenfluss kann anschließend als `RELATED` eingeordnet werden. Zu prüfen sind: - wird ein Helper verwendet? - ist der Helper ausdrücklich zugewiesen? - ist die Protokollerkennung verschlüsselt oder unverschlüsselt? - stimmen dynamisch ausgehandelte Adressen und Ports? - verändert NAT die Nutzdaten? - nimmt der zusätzliche Datenfluss denselben zustandsbehafteten Pfad? - ist der Helper auf der verwendeten Version noch vorgesehen und sicher? Helpers dürfen nicht pauschal aktiviert werden. Sie greifen in die Protokollverarbeitung ein und können zusätzliche Sicherheits- und Kompatibilitätsauswirkungen besitzen. --- **Warum asymmetrischer Rückverkehr verworfen wird** Beispiel: 1. Client sendet ein TCP-`SYN`. 2. Firewall A prüft die Sicherheitsregel. 3. Firewall A legt eine Sitzung an. 4. Server sendet `SYN, ACK`. 5. Routing leitet die Antwort über Firewall B. 6. Firewall B besitzt keine passende Sitzung. 7. Firewall B sieht ein Antwortpaket ohne bekannten Verbindungsaufbau. 8. Firewall B verwirft es als unbekannt oder ungültig. Vereinfachte Sicht: ```text Firewall A: SYN gesehen Sitzung vorhanden SYN-ACK nicht gesehen Firewall B: SYN nicht gesehen Sitzung nicht vorhanden SYN-ACK gesehen ``` Mögliche Symptome: - Client sendet wiederholt `SYN`; - Server sendet wiederholt `SYN, ACK`; - Client empfängt keine Antwort; - eine Firewall zeigt `SYN_SENT` oder `[UNREPLIED]`; - andere Firewall zeigt Invalid-State-Drops; - Regelprotokolle zeigen nur eine Richtung; - Verbindung funktioniert nach manchen Routingänderungen zufällig; - Verbindung funktioniert nur über einen bestimmten Clusterknoten. --- **Asymmetrie innerhalb derselben Firewall** Auch wenn beide Richtungen dieselbe physische Firewall verwenden, können unterschiedliche Kontexte die Zuordnung verhindern: - unterschiedliche virtuelle Systeme; - unterschiedliche VRFs; - unterschiedliche Sicherheitszonen; - unterschiedliche Routinginstanzen; - unterschiedliche Mandanten; - unterschiedliche Tunnel; - unterschiedliche logische Systeme; - unterschiedliche virtuelle Router; - getrennte Sessiontabellen. Deshalb muss nicht nur der Gerätename, sondern auch der vollständige Verarbeitungskontext übereinstimmen. --- **Häufige Ursachen asymmetrischer Pfade** - unterschiedliche Standardrouten; - unterschiedlich gelernte dynamische Routen; - ECMP; - per-Packet Load Balancing; - Policy-Based Routing; - Source-Based Routing; - mehrere Internetanschlüsse; - SD-WAN-Pfadauswahl; - BGP-Multihoming; - unterschiedliche OSPF-Kosten; - längeres oder kürzeres Präfix; - statische Route nur auf einer Seite; - VRF-Leak; - fehlende Rückroute; - Load Balancer; - Direct Server Return; - NAT Gateway; - unterschiedliche VPN-Tunnel; - mehrere Transit-Gateways; - Cloud User Defined Routes; - Kubernetes- oder Overlay-Netz; - Cluster mit unvollständiger State-Synchronisation; - Failover während einer aktiven Sitzung; - fehlerhafte Route Redistribution; - serverseitige zweite Netzwerkkarte; - falsches Standardgateway des Servers; - Proxy- oder Reverse-Proxy-Pfad; - Container- oder Host-NAT. --- **Längstes Präfix und Routenauswahl** Router bevorzugen grundsätzlich die spezifischste passende Route. Beispiel: ```text 10.0.0.0/8 über Firewall A 10.20.30.0/24 über Firewall B ``` Für das Ziel: ```text 10.20.30.40 ``` wird die spezifischere Route `/24` verwendet. Eine allgemeine Standardroute über die erwartete Firewall garantiert deshalb nicht, dass ein bestimmtes Ziel tatsächlich diese Firewall verwendet. Zu prüfen sind: - Zielpräfix; - Präfixlänge; - Routingprotokoll; - administrative Distanz oder Preference; - Metrik; - nächster Hop; - Ausgangsschnittstelle; - Routinginstanz; - Route Policy; - aktive und alternative Route. --- **ECMP** Equal-Cost Multi-Path ermöglicht die Nutzung mehrerer gleichwertiger Routen. Mögliche Verteilungsverfahren: - pro Paket; - pro Datenfluss; - Hash über Quell- und Zieladresse; - Hash über Fünf-Tupel; - gewichtete Verteilung; - resilienter Hash; - dynamische Auslastungsverteilung. Per-Flow-ECMP hält normalerweise alle Pakete eines Datenflusses auf demselben Hinweg. Es garantiert jedoch nicht automatisch, dass die Gegenstelle für den Rückweg denselben Firewallknoten auswählt. Zu prüfen sind: - welche Felder in den Hash einfließen; - ob Hin- und Rückrichtung denselben Hash ergeben; - ob beide Seiten dieselben Pfade kennen; - ob Link- oder Routingänderungen den Hash neu verteilen; - ob Clusterknoten Sitzungen synchronisieren; - ob der nächste Hop ein Stateful-Gerät ist; - ob Fragmentierung die Hash-Auswahl verändert; - ob NAT vor oder nach der ECMP-Auswahl erfolgt. Ein Problem, das nur bei einem Teil der Verbindungen auftritt, kann auf ECMP oder eine fehlerhafte Teilstrecke hinweisen. --- **Policy-Based Routing** Policy-Based Routing kann die normale Zielroutenauswahl überschreiben. Mögliche Kriterien: - Quelladresse; - Zieladresse; - Protokoll; - Quellport; - Zielport; - Eingangsschnittstelle; - DSCP; - Benutzer; - Anwendung; - Sicherheitszone; - Routingmarkierung. Zu prüfen sind: - passende PBR-Regel; - Regelreihenfolge; - nächster Hop; - Zustand des nächsten Hops; - Fallbackverhalten; - Rückrichtung; - Routingmarkierungen; - NAT-Abhängigkeit; - Verfügbarkeitstracking; - lokale Ausnahmen. Typischer Fehler: ```text Hinweg: PBR erzwingt Firewall A Rückweg: normale Route verwendet Firewall B ``` Die korrekte Sicherheitsregel auf beiden Firewalls löst den fehlenden gemeinsamen Sitzungszustand nicht. --- **Dynamisches Routing** Bei OSPF, IS-IS, BGP oder anderen dynamischen Routingprotokollen können sich Hin- und Rückwege unabhängig ändern. Zu prüfen sind: - empfangene Präfixe; - angekündigte Präfixe; - Route Policies; - Filterlisten; - lokale Preference; - MED; - AS-PATH; - OSPF-Kosten; - administrative Distanz; - Route Redistribution; - zusammengefasste Routen; - spezifischere Präfixe; - ECMP; - Konvergenzzeit; - Flapping; - Graceful Restart; - aktiver nächster Hop; - Zeitpunkt der letzten Änderung. Ein Pfad kann im stabilen Zustand symmetrisch und während einer Routingkonvergenz vorübergehend asymmetrisch sein. --- **Mehrere Netzwerkkarten am Server** Ein Server mit mehreren Netzwerkkarten kann den Rückverkehr über eine andere Schnittstelle senden. Zu prüfen sind: - IP-Adresse je Schnittstelle; - Standardgateway; - spezifische Routen; - Routingmetrik; - Source Address Selection; - Policy Routing; - Bonding oder Teaming; - VRF; - Container- oder Namespace-Routen; - virtuelle Switches; - Hypervisor-Routing; - Reverse Path Filtering. Beispiel: ```text Anfrage erreicht: eth1 / 10.20.30.40 Serverantwort verlässt: eth0 / Standardgateway über anderes Netz ``` Der Serverdienst kann korrekt antworten, während die Antwort einen unzulässigen oder nicht zustandsbehafteten Rückweg verwendet. --- **Reverse Path Filtering** Reverse Path Filtering prüft, ob die Quelladresse eines eingehenden Pakets aus Sicht der Routingtabelle über einen plausiblen Pfad erreichbar ist. Unter Linux sind typischerweise folgende Betriebsarten relevant: - deaktiviert; - strikte Prüfung; - lose Prüfung. Lesende Prüfung: ```bash sysctl net.ipv4.conf.all.rp_filter ``` ```bash sysctl net.ipv4.conf.default.rp_filter ``` Schnittstellenspezifisch: ```bash sysctl net.ipv4.conf.eth0.rp_filter ``` Eine strikte Prüfung kann legitimen asymmetrischen Verkehr verwerfen. Sie darf jedoch nicht ohne Sicherheitsbewertung deaktiviert werden. Zuerst sind Route, Quelladresse und tatsächlicher Datenpfad nachzuweisen. --- **NAT und asymmetrische Pfade** NAT benötigt normalerweise einen konsistenten Zustand für Original- und Antwortrichtung. Beispiel mit Source NAT: ```text Originalrichtung: 10.10.20.25:53124 -> 203.0.113.80:443 Nach SNAT: 198.51.100.5:61001 -> 203.0.113.80:443 ``` Der Server antwortet an: ```text 203.0.113.80:443 -> 198.51.100.5:61001 ``` Nur die NAT-Komponente mit der passenden Übersetzung weiß, dass die Antwort zurückübersetzt werden muss zu: ```text 203.0.113.80:443 -> 10.10.20.25:53124 ``` Erreicht die Antwort ein anderes NAT-Gateway ohne synchronisierten Zustand, fehlt die Zuordnung. Zu prüfen sind: - welches Gerät SNAT oder DNAT durchführt; - Original- und Übersetzungsadressen; - Original- und Übersetzungsports; - NAT-Sitzungs-ID; - NAT-Pool; - Port Address Translation; - Rückroute zur übersetzten Adresse; - HA-Synchronisation; - Porterschöpfung; - NAT-Regelreihenfolge; - Hairpin- oder U-Turn-NAT; - doppelte NAT-Verarbeitung. Source NAT kann bewusst verwendet werden, um den Rückverkehr zu einer bestimmten Komponente zurückzuführen. Diese Maßnahme verändert jedoch Quelladressen und kann Protokollierung, Zugriffskontrolle und Nachvollziehbarkeit beeinflussen. --- **Load Balancer und Direct Server Return** Bei einem normalen Proxy- oder Full-NAT-Load-Balancer verlaufen Hin- und Rückverkehr häufig über den Load Balancer. Bei Direct Server Return kann der Server direkt zum Client antworten, ohne den Load Balancer erneut zu durchlaufen. Das kann beabsichtigt sein, erfordert aber ein passendes Design. Zu prüfen sind: - Betriebsart des Load Balancers; - Full Proxy, NAT oder Direct Server Return; - virtuelle IP-Adresse; - Backendadresse; - Source NAT; - Rückroute des Backends; - Firewallzustand; - Health Probes; - Client-IP-Erhaltung; - Server-Loopschnittstelle; - ARP-Verhalten; - Sicherheitsprofile; - Protokollierung in beiden Richtungen. Eine Firewall darf nicht fälschlich erwarten, beide Richtungen zu sehen, wenn das freigegebene Architekturdesign bewusst Direct Server Return verwendet. --- **Firewallcluster und State-Synchronisation** Ein HA-Cluster kann unter anderem synchronisieren: - TCP-Sitzungen; - UDP-Pseudositzungen; - NAT-Übersetzungen; - VPN-Zustände; - Authentifizierungsinformationen; - Sequenznummern; - Zeitstempel; - Anwendungszustände; - Persistenzinformationen. Nicht jede Sitzungsart und nicht jede Funktion wird zwangsläufig synchronisiert. Zu prüfen sind: - Clusterbetriebsart; - Active/Passive oder Active/Active; - Zustandssynchronisationsschnittstelle; - Paketverlust auf dem Synchronisationslink; - Latenz; - Synchronisationswarteschlangen; - unterstützte Sitzungsarten; - NAT-Synchronisation; - Anwendungssynchronisation; - Softwareversionsgleichheit; - Konfigurationsgleichheit; - aktiver Sitzungseigentümer; - letzter Failoverzeitpunkt; - Split-Brain-Zustand; - Neustart eines Knotens; - Initialsynchronisation; - Tabellenfüllstand. Eine erfolgreiche Konfigurationssynchronisation beweist keine erfolgreiche Sitzungssynchronisation. --- **Active/Passive** Bei Active/Passive verarbeitet normalerweise nur der aktive Knoten den produktiven Verkehr. Der passive Knoten erhält je nach Produkt Sitzungsinformationen. Nach einem Failover sind folgende Ergebnisse möglich: - bestehende Sitzungen laufen weiter; - nur bestimmte Sitzungsarten laufen weiter; - NAT bleibt erhalten, Anwendungszustand jedoch nicht; - Verbindungen müssen neu aufgebaut werden; - Sitzungen gehen wegen unvollständiger Synchronisation verloren; - der neue aktive Knoten besitzt veraltete Zustände. Zu prüfen sind: - war die Sitzung vor dem Failover synchronisiert? - war die Synchronisationsschnittstelle fehlerfrei? - besitzt der neue aktive Knoten die passende Sitzung? - blieb die NAT-Zuordnung erhalten? - wurde die Route zusammen mit der Firewallrolle umgeschaltet? - erreichen beide Richtungen den neuen aktiven Knoten? --- **Active/Active** Bei Active/Active können mehrere Knoten gleichzeitig produktiven Verkehr verarbeiten. Das erfordert je nach Architektur: - Flow-Pinning; - konsistentes Hashing; - State Sharing; - Session Ownership; - Cluster-Forwarding; - symmetrische Next-Hop-Auswahl; - funktionierende NAT-Synchronisation. Besonders kritisch ist: ```text SYN: Knoten A SYN-ACK: Knoten B Folgepakete: abwechselnd A und B ``` Wenn die Plattform diesen Datenpfad nicht ausdrücklich unterstützt, können Sitzungen verworfen oder Sicherheitsprüfungen umgangen werden. --- **Synchronisationsverzögerung** State-Synchronisation erfolgt nicht immer vollständig synchron vor der Paketweiterleitung. Bei kurzen Datenflüssen oder einem schnellen Pfadwechsel kann das Antwortpaket den zweiten Knoten erreichen, bevor der Zustand übertragen wurde. Mögliche Symptome: - nur erste Verbindung nach Failover scheitert; - Wiederholung funktioniert; - sehr kurze UDP-Anfragen sind besonders betroffen; - Probleme treten nur unter hoher Last auf; - Clusterprotokolle zeigen verlorene oder verspätete Updates; - Sitzung ist auf dem aktiven, aber nicht auf dem anderen Knoten sichtbar. Die Lösung ist nicht automatisch ein längerer Timeout. Zu prüfen sind Synchronisationslink, unterstützte Betriebsart, Flow-Pinning und Routingdesign. --- **Connection-Tracking-Kapazität** Eine Sessiontabelle besitzt eine begrenzte Kapazität. Bei Linux sind insbesondere relevant: ```text nf_conntrack_count nf_conntrack_max nf_conntrack_buckets ``` Lesende Prüfung: ```bash sysctl net.netfilter.nf_conntrack_count ``` ```bash sysctl net.netfilter.nf_conntrack_max ``` ```bash sysctl net.netfilter.nf_conntrack_buckets ``` Alternative direkte Anzeige: ```bash cat /proc/sys/net/netfilter/nf_conntrack_count ``` ```bash cat /proc/sys/net/netfilter/nf_conntrack_max ``` Auslastung berechnen: ```text Auslastung in Prozent = nf_conntrack_count / nf_conntrack_max × 100 ``` Beispiel: ```text nf_conntrack_count = 245760 nf_conntrack_max = 262144 Auslastung = 245760 / 262144 × 100 = 93,75 % ``` Ein hoher Tabellenfüllstand kann zu folgenden Symptomen führen: - neue Verbindungen schlagen fehl; - bestehende Sitzungen funktionieren weiterhin; - Kernel meldet volle Conntrack-Tabelle; - Einträge werden vorzeitig entfernt; - Drop- oder Insert-Failed-Zähler steigen; - UDP- oder Kurzzeitsitzungen erhöhen die Last stark; - NAT-Verbindungen können nicht mehr angelegt werden. Eine Vergrößerung von `nf_conntrack_max` benötigt eine Speicher- und Lastbewertung. Sie beseitigt keine Ursache wie Portscan, DDoS, fehlerhafte Anwendung oder ungeeignete Timeouts. --- **Conntrack-Statistiken** Sofern `conntrack-tools` installiert ist: ```bash sudo conntrack -S ``` Mögliche Statistikfelder sind: - gefundene Einträge; - Suchvorgänge; - eingefügte Einträge; - fehlgeschlagene Einfügungen; - Drops; - Early Drops; - Fehler; - Hash-Kollisionen; - zu lange Suchketten. Ein einzelner Gesamtzähler ohne Zeitbezug ist wenig aussagekräftig. Belastbarer Ablauf: 1. Zähler und Uhrzeit erfassen. 2. definierten Testzeitraum starten. 3. genau einen reproduzierbaren Test durchführen. 4. Zähler erneut erfassen. 5. Differenz mit Paketaufzeichnung und Protokollen korrelieren. --- **Timeouts** Sessiontabellen entfernen inaktive Einträge nach protokoll- und zustandsabhängigen Zeiträumen. Unter Linux können unter anderem relevant sein: ```bash sysctl net.netfilter.nf_conntrack_tcp_timeout_syn_sent ``` ```bash sysctl net.netfilter.nf_conntrack_tcp_timeout_syn_recv ``` ```bash sysctl net.netfilter.nf_conntrack_tcp_timeout_established ``` ```bash sysctl net.netfilter.nf_conntrack_tcp_timeout_time_wait ``` ```bash sysctl net.netfilter.nf_conntrack_udp_timeout ``` ```bash sysctl net.netfilter.nf_conntrack_udp_timeout_stream ``` ```bash sysctl net.netfilter.nf_conntrack_icmp_timeout ``` Die konkreten Werte sind Systemzustand und Konfiguration und dürfen nicht aus einer allgemeinen Dokumentation als garantierte lokale Werte übernommen werden. Typische Timeoutbefunde: | Befund | Mögliche Einordnung | |---|---| | Verbindung bricht nach fester Leerlaufzeit ab | Idle-Timeout | | neue Verbindung funktioniert sofort | vorherige Sitzung ist abgelaufen oder wurde verworfen | | UDP-Antwort kommt verspätet und wird verworfen | UDP-Tracking-Eintrag bereits entfernt | | Langzeitverbindungen scheitern unter Last | vorzeitiges Aging oder Tabellenknappheit | | nach Failover fehlen nur ältere Sitzungen | unvollständige Zustandssynchronisation | --- **Offloading berücksichtigen** Firewalls und Linux-Netfilter können etablierte Datenflüsse in einen beschleunigten Pfad oder in Hardware auslagern. Mögliche Auswirkungen: - allgemeine Softwarezähler steigen nicht bei jedem Paket; - Paketaufzeichnung auf der Steuer- oder Softwareebene sieht nicht alle Pakete; - Sitzungsdaten werden verzögert aktualisiert; - ein Flow erscheint als `offload` oder `hw-offload`; - Fehlerzähler befinden sich auf einer anderen Datenebene; - eine Änderung wirkt erst nach Rückkehr aus dem Offloadpfad oder nach Sitzungsende. Zu prüfen sind: - ist der Datenfluss ausgelagert? - wo werden Hardwarezähler angezeigt? - kann das Produkt gezielt einen Flow erfassen? - verändert die Diagnosefunktion den Offloadstatus? - besitzt jeder Clusterknoten eigene Hardwaretabellen? Offloading darf nicht pauschal deaktiviert werden, da dies die Leistungsfähigkeit der Firewall erheblich beeinflussen kann. --- **Hin- und Rückweg getrennt prüfen** Eine Traceroute nur vom Client zum Server zeigt nicht den Rückweg. Erforderlich sind nach Möglichkeit: ```text Test A: Client -> Server Test B: Server -> Client ``` Windows: ```powershell tracert 198.51.100.25 ``` ```powershell Test-NetConnection ` -ComputerName "198.51.100.25" ` -Port 443 ` -InformationLevel Detailed ``` Linux: ```bash traceroute 198.51.100.25 ``` ```bash tracepath 198.51.100.25 ``` macOS: ```bash traceroute 198.51.100.25 ``` Traceroute-Ergebnisse sind nur ein Teilnachweis. Firewalls können: - TTL-Fehlermeldungen unterdrücken; - transparent arbeiten; - auf Traceroute-Protokolle anders reagieren; - mehrere Pfade verwenden; - ICMP, UDP und TCP unterschiedlich routen; - im Rückweg nicht sichtbar sein. Für anwendungsnahes Tracing kann abhängig von Plattform und Freigabe ein TCP-basierter Traceroute zum tatsächlichen Zielport verwendet werden. --- **Lokale Routingentscheidung prüfen** Windows: ```powershell Get-NetRoute ` -AddressFamily IPv4 | Sort-Object DestinationPrefix, RouteMetric ``` Bestimmte Zielroute: ```powershell Find-NetRoute ` -RemoteIPAddress "198.51.100.25" ``` Klassische Anzeige: ```cmd route print ``` Linux: ```bash ip route get 198.51.100.25 ``` Mit angenommener Quelladresse: ```bash ip route get 198.51.100.25 from 192.0.2.100 ``` Policy-Regeln: ```bash ip rule show ``` Alle Routingtabellen: ```bash ip route show table all ``` IPv6: ```bash ip -6 route get 2001:db8::25 ``` macOS: ```bash route -n get 198.51.100.25 ``` Die lokale Routenausgabe zeigt nur die Entscheidung des untersuchten Systems. Sie beweist nicht den vollständigen End-to-End-Pfad. --- **Linux-Conntrack lesend prüfen** Alle Einträge anzeigen: ```bash sudo conntrack -L ``` Nur TCP: ```bash sudo conntrack -L -p tcp ``` Nach Originalquelle und Originalziel filtern: ```bash sudo conntrack -L \ -p tcp \ -s 192.0.2.100 \ -d 198.51.100.25 \ --dport 443 ``` Nach UDP filtern: ```bash sudo conntrack -L \ -p udp \ -s 192.0.2.100 \ -d 198.51.100.53 \ --dport 53 ``` Anzahl anzeigen: ```bash sudo conntrack -C ``` Statistiken anzeigen: ```bash sudo conntrack -S ``` Conntrack-Ereignisse beobachten: ```bash sudo conntrack -E ``` Gezielt TCP-Ereignisse beobachten: ```bash sudo conntrack -E -p tcp ``` Mögliche Ereignisse: ```text [NEW] [UPDATE] [DESTROY] ``` Die Ereignisbeobachtung sollte auf einen kurzen Testzeitraum begrenzt werden. Auf stark ausgelasteten Systemen kann eine ungefilterte Ausgabe sehr groß werden und interne Kommunikationsdaten enthalten. --- **Direkte Kernelansicht** Falls `conntrack` nicht installiert ist, kann abhängig vom System eine Kernelansicht existieren: ```bash sudo cat /proc/net/nf_conntrack ``` Gezielte Textfilterung: ```bash sudo grep 'dst=198.51.100.25' /proc/net/nf_conntrack ``` Diese Schnittstelle kann fehlen oder durch Namespace- und Berechtigungseinstellungen eingeschränkt sein. Das `conntrack`-Werkzeug bietet normalerweise bessere Filter- und Ereignisfunktionen. --- **Netzwerk-Namespaces und Container** Container, Kubernetes und Linux-Netzwerk-Namespaces können eigene Routing-, Firewall- und Conntrack-Kontexte besitzen. Zu prüfen sind: - Host-Namespace; - Container-Namespace; - Pod-Namespace; - Bridge; - veth-Schnittstellen; - Overlay-Netz; - Service-NAT; - kube-proxy-Betriebsart; - CNI-Plugin; - Node-Firewall; - Cloud-Firewall; - eBPF-Datenpfad; - Host- und Podroute; - Rückweg zum ursprünglichen Node. Namespaces anzeigen: ```bash ip netns list ``` Routing in einem Namespace: ```bash sudo ip netns exec ip route show ``` Schnittstellen: ```bash sudo ip netns exec ip address show ``` Ein Conntrack-Eintrag auf dem Host muss anhand der vor und nach NAT sichtbaren Adressen geprüft werden. Die Anwendung kann innerhalb des Containers andere Adressen sehen als die Host-Firewall. --- **Cisco Secure Firewall ASA prüfen** Verbindungen anzeigen: ```text show conn ``` Nach Adresse filtern: ```text show conn address 192.0.2.100 ``` Anzahl und Kapazität: ```text show conn count ``` NAT-Zustände: ```text show xlate ``` HA-Zustand: ```text show failover ``` Routing: ```text show route ``` Drop-Zähler: ```text show asp drop ``` Datenfluss simulieren: ```text packet-tracer input inside tcp 192.0.2.100 53124 198.51.100.25 443 detailed ``` Zu vergleichen sind: - existiert die Sitzung? - welcher Knoten besitzt sie? - stimmen Original- und Übersetzungsadressen? - steigen Bytes in beiden Richtungen? - welcher TCP-Zustand oder welche Flags werden angezeigt? - sind Failover und State-Synchronisation fehlerfrei? - steigt ein Drop-Zähler beim kontrollierten Test? Cisco ASA bietet für bestimmte ausdrücklich geplante asymmetrische Szenarien einen TCP State Bypass. Dieser deaktiviert jedoch wesentliche zustandsabhängige Prüfungen und unterstützt nicht alle Funktionen. Er ist keine allgemeine Reparaturmaßnahme für fehlerhaftes Routing. --- **Juniper SRX prüfen** Aktive Sitzungen: ```text show security flow session ``` Nach Quelle: ```text show security flow session source-prefix 192.0.2.100 ``` Nach Ziel: ```text show security flow session destination-prefix 198.51.100.25 ``` Route: ```text show route 198.51.100.25 ``` Flow-Statistiken: ```text show security flow statistics ``` Clusterzustand: ```text show chassis cluster status ``` Zu prüfen sind: - Ingress- und Egress-Interface; - Quell- und Zielzone; - Sitzungsstatus; - NAT; - Timeout; - Pakete und Bytes; - Session Owner; - HA- oder Clusterknoten; - Drop-Statistiken; - verwendete Routinginstanz. Die verfügbaren Filter unterscheiden sich nach Junos-Version und Plattform. Die lokale CLI-Hilfe ist deshalb zusätzlich zu verwenden. --- **Palo Alto Networks prüfen** Sitzung nach Datenfluss suchen: ```text show session all filter source 192.0.2.100 destination 198.51.100.25 destination-port 443 ``` Filtermöglichkeiten prüfen: ```text show session all filter ? ``` Routingentscheidung: ```text test routing fib-lookup virtual-router ip 198.51.100.25 ``` HA-Zustand: ```text show high-availability state ``` Zu prüfen sind: - Session-ID; - Session Owner; - Quell- und Zielzone; - Original- und NAT-Tupel; - Anwendung; - Sicherheitsregel; - Pakete und Bytes beider Richtungen; - Sitzungsendgrund; - Hardware-Offload; - HA-Synchronisation; - virtueller Router. Die genaue Syntax und Feldbezeichnung hängt von PAN-OS-Version, Plattform und Betriebsart ab. --- **AWS Network Firewall** AWS Network Firewall benötigt für zustandsbehaftete Verarbeitung, dass Anfrage und Antwort denselben Firewallendpunkt durchlaufen. Zu prüfen sind: - Firewallendpunkt je Availability Zone; - VPC-Routingtabellen; - Transit Gateway; - Appliance Mode; - Ingress- und Egress-Routen; - NAT Gateway; - Internet Gateway; - Gateway Load Balancer; - zentrale Inspection VPC; - Flow Logs; - Alert Logs; - Stateful Rule Groups; - Availability-Zone-Affinität. AWS Network Firewall unterstützt keine asymmetrische Weiterleitung zu unterschiedlichen Firewallendpunkten. Anfrage und Antwort müssen demselben Endpunkt zugeführt werden. Ein Reachability-Analyzer-Ergebnis kann die modellierte Erreichbarkeit prüfen, ersetzt aber nicht die Auswertung realer Flow- und Alert-Logs. --- **AWS Security Group Connection Tracking** AWS Security Groups sind zustandsbehaftet und verfolgen Verbindungen. Zu prüfen sind: - tatsächlich zugeordnete Security Groups; - eingehende und ausgehende Regeln; - Netzwerkschnittstellen; - Connection-Tracking-Kapazität; - Idle-Timeouts; - asymmetrische Pfade über mehrere Netzwerkschnittstellen; - Network ACLs; - Gateway- und Transitpfade. Asymmetrisches Routing über verschiedene Netzwerkschnittstellen kann bei verfolgten Datenflüssen die erreichbare Leistung beeinträchtigen. AWS empfiehlt nach Möglichkeit symmetrische Topologien. --- **Azure Firewall und Network Virtual Appliances** Bei Azure sind unter anderem zu prüfen: - User Defined Routes; - effektive Routen der Netzwerkschnittstelle; - Azure Firewall; - Network Virtual Appliance; - Load Balancer; - Virtual WAN; - ExpressRoute; - VPN Gateway; - VNet Peering; - NAT Gateway; - Hub-and-Spoke-Routing; - aktive und aktive NVA-Instanzen; - Zustandssynchronisation; - SNAT-Verhalten. Effektive Routen per PowerShell: ```powershell Get-AzEffectiveRouteTable ` -NetworkInterfaceName "" ` -ResourceGroupName "" ``` Ein öffentlicher Load Balancer und eine private Firewallroute können einen asymmetrischen Pfad erzeugen, wenn der Hinverkehr über die öffentliche Load-Balancer-Adresse eintrifft und der Rückverkehr über die private Firewalladresse geführt wird. Bei Active/Active-NVAs muss geprüft werden, ob: - beide Richtungen dieselbe Instanz verwenden; - Flow-Pinning existiert; - Session Sharing unterstützt wird; - ECMP zu unterschiedlichen Instanzen führt. --- **Paketaufzeichnung systematisch planen** Für einen vollständigen Pfadvergleich sind möglichst vier Beobachtungspunkte hilfreich: | Punkt | Beobachtung | |---|---| | A | Paket verlässt den Client | | B | Paket erreicht und verlässt die zustandsbehaftete Komponente | | C | Paket erreicht den Server und Antwort verlässt ihn | | D | Antwort erreicht oder verfehlt die zustandsbehaftete Komponente | Empfohlener Filter: ```text host 192.0.2.100 and host 198.51.100.25 and tcp port 443 ``` Mit `tcpdump`: ```bash sudo tcpdump \ -ni any \ 'host 192.0.2.100 and host 198.51.100.25 and tcp port 443' ``` Nur TCP-Flags und Zeitverhalten prüfen: ```bash sudo tcpdump \ -ni any \ -tttt \ 'host 192.0.2.100 and host 198.51.100.25 and tcp port 443' ``` Für NAT müssen gegebenenfalls zwei Filter verwendet werden: ```text vor NAT: 10.10.20.25:53124 -> 203.0.113.80:443 nach NAT: 198.51.100.5:61001 -> 203.0.113.80:443 ``` Paketaufzeichnungen dürfen nur autorisiert, zielgerichtet und zeitlich begrenzt durchgeführt werden. --- **Zeitstempel korrelieren** Alle beteiligten Systeme sollten eine ausreichend genaue Zeitbasis verwenden: - Client; - Server; - Router; - Firewallknoten; - Load Balancer; - Cloud-Logs; - SIEM; - Paketaufzeichnungssystem. Zu dokumentieren sind: ```text Datum Uhrzeit Zeitzone Zeitquelle ungefähre Zeitabweichung ``` Schon wenige Sekunden Unterschied können bei kurzen Verbindungsversuchen zu einer falschen Zuordnung führen. --- **Pakete und Bytes je Richtung auswerten** | Befund | Mögliche Einordnung | |---|---| | nur Originalpakete, keine Antwortpakete | Serverantwort fehlt oder verwendet anderen Rückweg | | Antwortpakete am Server, nicht an Firewall | Route zwischen Server und Firewall prüfen | | Antwortpakete an anderer Firewall | asymmetrischer Rückweg | | beide Richtungen in Sitzung, Client empfängt nichts | nachgelagerter Pfad zum Client prüfen | | wenige Pakete, Sitzung bleibt `SYN_SENT` | SYN-ACK fehlt | | Pakete in beide Richtungen, aber kaum Bytes | Handshake ohne Anwendungsdaten | | hohe Bytes nur in einer Richtung | Anwendung, ACK-Pfad oder Filterproblem | | Sitzung verschwindet sofort | RST, Policy-Drop, Timeout oder Tabellenproblem | | Sitzung bleibt lange `[UNREPLIED]` | keine zugeordnete Antwort | Zähler müssen während genau eines reproduzierbaren Tests verglichen werden. --- **NetFlow, IPFIX und Flow Logs** Flow-Daten können Hinweise liefern auf: - Quelle; - Ziel; - Ports; - Protokoll; - Eingangs- und Ausgangsschnittstelle; - Pakete; - Bytes; - Start- und Endzeit; - TCP-Flags; - nächste Hops; - zulassende oder verweigernde Aktion. Einschränkungen: - Sampling kann einzelne Datenflüsse übersehen; - Export erfolgt möglicherweise verzögert; - NAT kann unterschiedliche Datensätze erzeugen; - Flow Logs zeigen nicht immer den vollständigen Paketinhalt; - mehrere Geräte können denselben Datenfluss unterschiedlich darstellen; - fehlender Flow-Datensatz beweist nicht zwingend fehlenden Verkehr. Flow-Daten sind besonders hilfreich, wenn Hin- und Rückrichtung auf unterschiedlichen Geräten sichtbar werden. --- **Hypothese und Gegenbeweis formulieren** Beispiel: ```text Hypothese: Der TCP-Verbindungsaufbau läuft über Firewall A, der Rückverkehr aufgrund einer spezifischeren Serverroute jedoch über Firewall B. Firewall B besitzt keinen synchronisierten Sitzungszustand und verwirft das SYN-ACK. Erwarteter Befund: Firewall A zeigt eine Sitzung im Zustand SYN_SENT oder UNREPLIED. Firewall B zeigt keinen passenden Sitzungseintrag, aber einen Invalid-State-Drop für das SYN-ACK. Eine serverseitige Paketaufzeichnung zeigt, dass das SYN-ACK den Server verlässt. Gegenbeweis: Hin- und Rückverkehr durchlaufen nachweislich Firewall A, und Firewall A sieht das SYN-ACK in derselben Sitzung. Testmethode: Routingtabellen, Sessiontabellen und zeitgleiche Paketaufzeichnungen auf Client-, Server- und Firewallseite vergleichen. Risiko: Nur lesende Diagnose und begrenzte Paketaufzeichnung. Erfolgskriterium: Abweichender Rückweg und verwerfendes Gerät sind mit Zeitstempel, Sitzungsdaten und Routingentscheidung eindeutig belegt. ``` --- **Kontrollierte Maßnahmen** | Maßnahme | Voraussetzung | Risiko | Rückweg | |---|---|---|---| | spezifische Rückroute korrigieren | falscher Rückweg nachgewiesen | weitere Ziele können betroffen sein | alte Route wiederherstellen | | Routingmetrik korrigieren | falsche Pfadauswahl bestätigt | Konvergenz und Lastverteilung ändern sich | alte Metrik wiederherstellen | | PBR-Regel korrigieren | asymmetrische PBR-Entscheidung bestätigt | andere markierte Flows betroffen | vorherige PBR-Regel aktivieren | | ECMP-Hash oder Flow-Pinning korrigieren | Verteilung auf unterschiedliche Stateful-Knoten bestätigt | Lastverteilung verändert sich | vorherige Einstellung wiederherstellen | | Cluster-State-Synchronisation reparieren | fehlende Synchronisation nachgewiesen | HA-Verhalten betroffen | herstellerspezifischer Rückfallplan | | SNAT gezielt einsetzen | Rückweg muss technisch gebunden werden | Originalquelle wird verdeckt | SNAT-Regel entfernen | | NAT-Regel korrigieren | falscher NAT-Besitzer oder falsche Übersetzung bestätigt | Erreichbarkeit vieler Verbindungen | alte NAT-Regel wiederherstellen | | einzelne Sitzung löschen | veralteter Eintrag nachgewiesen | genau diese Verbindung wird unterbrochen | Anwendung baut Sitzung neu auf | | Timeout korrigieren | nachweislicher Timeoutkonflikt | höhere Tabellenbelegung | alten Wert wiederherstellen | | Conntrack-Kapazität erhöhen | Tabellenlimit und ausreichender Speicher nachgewiesen | höherer Speicherbedarf | alten Grenzwert wiederherstellen | | fehlerhafte Quelle begrenzen | ungewöhnlich viele Sessions einer Quelle bestätigt | legitime Kommunikation kann betroffen sein | Begrenzung entfernen | | Active/Active-Design anpassen | Plattform unterstützt Asymmetrie nicht | Verfügbarkeit und Verteilung ändern sich | vorheriges Routingdesign wiederherstellen | Eine Änderung an Routing, NAT oder HA muss als zusammenhängende Ende-zu-Ende-Änderung bewertet werden. --- **Vollständiger Diagnoseablauf** 1. Exakte Fehlermeldung dokumentieren. 2. Datum, Uhrzeit und Zeitzone erfassen. 3. Betroffene Anwendung bestimmen. 4. Quell- und Zielsystem bestimmen. 5. Quelladresse und Quellport erfassen. 6. Zieladresse und Zielport erfassen. 7. Protokoll bestimmen. 8. IPv4 und IPv6 unterscheiden. 9. Originalrichtung dokumentieren. 10. Antwortrichtung dokumentieren. 11. NAT vor und nach Übersetzung dokumentieren. 12. Fehlerumfang bestimmen. 13. Erwarteten Hinweg dokumentieren. 14. Erwarteten Rückweg dokumentieren. 15. Lokale Clientroute prüfen. 16. Lokale Serverroute prüfen. 17. Policy Routing auf beiden Endsystemen prüfen. 18. Routinginstanzen und VRFs berücksichtigen. 19. Tatsächlichen Hinweg nachweisen. 20. Tatsächlichen Rückweg unabhängig nachweisen. 21. Alle zustandsbehafteten Komponenten erfassen. 22. Aktive Firewall- und Clusterknoten bestimmen. 23. Sessiontabellen auf allen möglichen Knoten prüfen. 24. Sitzungs-ID dokumentieren. 25. Original- und Antwort-Tupel vergleichen. 26. TCP-, UDP- oder ICMP-Zustand auswerten. 27. `[UNREPLIED]`, `[ASSURED]` oder vergleichbare Markierung prüfen. 28. Pakete und Bytes je Richtung vergleichen. 29. NAT-Sitzung und NAT-Besitzer prüfen. 30. Regel- und Drop-Protokolle korrelieren. 31. Cluster- und State-Synchronisation prüfen. 32. Zeitpunkt des letzten Failovers prüfen. 33. ECMP und Hash-Verfahren prüfen. 34. PBR und Source Routing prüfen. 35. dynamische Routen und spezifischere Präfixe prüfen. 36. Load Balancer und Direct Server Return berücksichtigen. 37. Cloud-Routingtabellen und Firewallendpunkte prüfen. 38. Conntrack-Auslastung erfassen. 39. Conntrack-Fehlerzähler erfassen. 40. Timeouts dokumentieren. 41. Hardware-Offloading berücksichtigen. 42. kontrollierten Verbindungstest durchführen. 43. bei Bedarf Conntrack-Ereignisse beobachten. 44. bei Bedarf Paketaufzeichnung an mehreren Punkten durchführen. 45. Hypothese und Gegenbeweis formulieren. 46. genau eine kontrollierte Maßnahme vorbereiten. 47. Risiko, Rückweg und Erfolgskriterium dokumentieren. 48. Maßnahme freigeben und umsetzen. 49. vollständig neue Sitzung aufbauen. 50. Hin- und Rückweg erneut prüfen. 51. Session- und NAT-Zustand erneut prüfen. 52. ursprüngliche Anwendung verifizieren. 53. weitere repräsentative Datenflüsse prüfen. 54. temporäre Aufzeichnungen und Diagnoseregeln zurücknehmen. 55. Ursache, Maßnahme und Prävention dokumentieren. --- **Befundmatrix** | Befund | Mögliche Einordnung | Nächster Nachweis | |---|---|---| | Sitzung nur auf Firewall A | Firewall B besitzt keinen Zustand | Rückweg und State-Synchronisation prüfen | | Firewall A zeigt `[UNREPLIED]` | keine zugeordnete Antwort | serverseitige Aufzeichnung und Rückroute | | Server sendet SYN-ACK, Client empfängt nichts | Rückweg wird verworfen | Firewalls des Rückwegs erfassen | | Firewall B meldet `INVALID` | unbekannter oder fehlerhafter Zustand | ursprünglichen SYN-Pfad bestimmen | | Verbindung funktioniert nur manchmal | ECMP oder einzelner fehlerhafter Pfad | mehrere Tests mit Quellports vergleichen | | Verbindung funktioniert nach Wiederholung | Synchronisationsverzögerung oder Routingkonvergenz | Cluster- und Routingzeitpunkte prüfen | | nur neue Verbindungen scheitern | Conntrack-Tabelle voll oder neue Policy | Kapazität und Insert-Failed-Zähler | | bestehende Verbindungen funktionieren | Zustand vorhanden, neue Einträge scheitern | Sessionlimit und Ressourcenauslastung | | nach Failover brechen Sitzungen ab | State- oder NAT-Synchronisation unvollständig | HA-Protokoll und Tabellen vergleichen | | nur lange Leerlaufverbindungen brechen ab | Idle-Timeout | Timeout und Keepalive vergleichen | | UDP bleibt `[UNREPLIED]` | Antwort fehlt oder anderer Rückweg | Antwortaufzeichnung und UDP-Timeout | | unterschiedliche NAT-Abbildung je Knoten | NAT-Synchronisation fehlerhaft | Übersetzungstabellen vergleichen | | gleicher Firewallname, Sitzung fehlt | anderer VSYS, VRF oder Kontext | vollständigen Verarbeitungskontext prüfen | | Hinweg über VPN, Rückweg über Internet | Präfixankündigung oder PBR | Routen auf Server- und Gatewayseite | | nur ein Zielpräfix betroffen | spezifischere Route | Longest-Prefix-Match prüfen | | nur ein Teil der Clients betroffen | Quellrouting, Hash oder PBR | Quellen und Quellports vergleichen | | Conntrack-Auslastung nahe Grenzwert | Tabellenknappheit | Neu-, Drop- und Early-Drop-Rate | | `insert_failed` steigt | neue Einträge können nicht angelegt werden | Tabellenlimit und Speicher prüfen | | viele `UNREPLIED`-Einträge | Scans, nicht erreichbare Ziele oder Rückwegproblem | Quellen, Ziele und Rate analysieren | | Flow ist hardware-offloaded | Softwarecapture eventuell unvollständig | Hardwarezähler oder externen TAP verwenden | | AWS Firewall sieht nur eine Richtung | unterschiedliche Firewallendpunkte | Routingtabellen je Availability Zone | | Azure NVA-Instanzen sehen je eine Richtung | Active/Active ohne Flow-Symmetrie | ECMP und Session Sharing prüfen | | Traceroute wirkt symmetrisch, Sitzung fehlt | Traceroute nutzt anderen Datenfluss | Capture mit echtem Protokoll und Port | | Sitzung vorhanden, keine Anwendung | Netzwerkpfad möglicherweise korrekt | TLS, Protokoll und Serverdienst prüfen | --- **Typische Diagnosefehler** - Hin- und Rückweg als automatisch identisch betrachten. - Nur eine Traceroute vom Client ausführen. - Traceroute-Ergebnis als vollständigen Pfadnachweis bewerten. - Nur die Routingtabelle der Firewall prüfen. - Lokale Serverroute und Standardgateway ignorieren. - Längstes Präfix übersehen. - Policy-Based Routing nicht prüfen. - ECMP nur auf dem Hinweg betrachten. - Per-Flow-ECMP mit garantierter Ende-zu-Ende-Symmetrie gleichsetzen. - Mehrere virtuelle Kontexte einer Firewall übersehen. - Sessiontabelle nur auf einem Clusterknoten prüfen. - Konfigurations- und Zustandssynchronisation verwechseln. - `[UNREPLIED]` automatisch als Serverausfall interpretieren. - `ESTABLISHED` als erfolgreichen Anwendungsnachweis bewerten. - Generischen Conntrack-Zustand und TCP-Zustand verwechseln. - Original- und Antwort-Tupel nicht vergleichen. - Vor-NAT- und Nach-NAT-Adressen verwechseln. - NAT-Besitzer nicht bestimmen. - Bestehende und neue Sitzungen nicht unterscheiden. - Alle Sessions vorsorglich löschen. - Conntrack-Tabelle vollständig leeren. - Timeouts ohne zeitlichen Nachweis verändern. - Conntrack-Maximalwert ohne Speicherprüfung erhöhen. - `INVALID` pauschal erlauben. - Stateful Inspection deaktivieren. - TCP State Bypass als Standardlösung einsetzen. - Sicherheitsauswirkungen von Stateless-Betrieb ignorieren. - Direct Server Return als Fehler behandeln, obwohl es Teil des Designs ist. - Hardware-Offloading bei Capture und Zählern ignorieren. - Nur eine Richtung der Paket- und Bytezähler auswerten. - Flow Logs ohne Berücksichtigung von Sampling bewerten. - Uhren und Zeitzonen nicht synchronisieren. - Mehrere Variablen gleichzeitig verändern. - Nur den Porttest und nicht die ursprüngliche Anwendung verifizieren. - Temporäre Captures und Diagnoseprotokollierung aktiv lassen. --- **Verifikation** Nach einer Maßnahme müssen mindestens folgende Punkte geprüft werden: - Client verwendet die erwartete Quelladresse; - Server verwendet die erwartete Antwortadresse; - Quell- und Zielports entsprechen dem Sollzustand; - Hinweg entspricht dem freigegebenen Design; - Rückweg entspricht dem freigegebenen Design; - alle zustandsabhängigen Komponenten sehen beide Richtungen; - richtige Firewall- und Clusterknoten verarbeiten die Sitzung; - Sitzung wird im richtigen virtuellen Kontext angelegt; - NAT-Übersetzung ist in beiden Richtungen konsistent; - TCP-Handshake wird vollständig abgeschlossen; - UDP-Antwort wird der Pseudositzung zugeordnet; - ICMP-Fehler werden korrekt zugeordnet; - Sessiontabelle zeigt Pakete und Bytes in beiden Richtungen; - Sitzung erreicht den erwarteten Zustand; - kein Invalid-State-Drop entsteht; - Conntrack-Auslastung bleibt innerhalb der Baseline; - Insert-Failed- und Drop-Zähler steigen nicht; - State-Synchronisation ist fehlerfrei; - bestehende und neue Sitzungen verhalten sich erwartungsgemäß; - Failoververhalten entspricht dem Sollzustand; - IPv4 und IPv6 funktionieren, sofern erforderlich; - ursprüngliche Anwendung funktioniert; - weitere repräsentative Quellen funktionieren; - weitere repräsentative Ziele funktionieren; - kein unbeabsichtigter Bypass der Sicherheitskontrolle entstand; - temporäre Diagnosen wurden zurückgenommen; - Ursache, Maßnahme und Prävention wurden dokumentiert. Eine einzelne erfolgreiche Verbindung nach einer Routingänderung ist keine ausreichende Verifikation. Bei ECMP- oder Clusterproblemen müssen mehrere neue Verbindungen mit unterschiedlichen Quellports geprüft werden. --- **Dokumentationsvorlage** ```text Störung: Datum und Uhrzeit: Betroffene Anwendung: Originalrichtung: Ziel-IP:Port/Protokoll> Antwortrichtung: Quell-IP:Port/Protokoll> NAT vor Übersetzung: NAT nach Übersetzung: Erwarteter Hinweg: Tatsächlicher Hinweg: Erwarteter Rückweg: Tatsächlicher Rückweg: Zustandsbehaftete Komponenten: Firewall- oder Clusterknoten: Virtueller Kontext: Sitzungs-ID: Sitzungszustand: Session Owner: Pakete und Bytes: Timeout: NAT-Sitzung: <Übersetzung und Besitzer> Conntrack-Auslastung: Fehlerzähler: Cluster-Synchronisation: Paketaufzeichnung: Hypothese: Erwarteter Nachweis: Gegenbeweis: Nachgewiesene Ursache: Durchgeführte Maßnahme: Risiko: Rückweg: Verifikation: Prävention: ``` --- **Checkliste** - [ ] exakte Fehlermeldung dokumentiert - [ ] Datum, Uhrzeit und Zeitzone erfasst - [ ] betroffene Anwendung bestimmt - [ ] Quelladresse erfasst - [ ] Quellport erfasst - [ ] Zieladresse erfasst - [ ] Zielport erfasst - [ ] Protokoll bestimmt - [ ] IPv4 und IPv6 unterschieden - [ ] Originalrichtung dokumentiert - [ ] Antwortrichtung dokumentiert - [ ] Vor-NAT-Tupel dokumentiert - [ ] Nach-NAT-Tupel dokumentiert - [ ] Fehlerumfang bestimmt - [ ] erwarteten Hinweg dokumentiert - [ ] tatsächlichen Hinweg nachgewiesen - [ ] erwarteten Rückweg dokumentiert - [ ] tatsächlichen Rückweg nachgewiesen - [ ] lokale Clientroute geprüft - [ ] lokale Serverroute geprüft - [ ] Standardgateways geprüft - [ ] längstes passendes Präfix geprüft - [ ] Policy Routing geprüft - [ ] VRFs und Routinginstanzen geprüft - [ ] dynamische Routen geprüft - [ ] ECMP geprüft - [ ] ECMP-Hash-Verfahren berücksichtigt - [ ] SD-WAN-Pfadauswahl geprüft - [ ] VPN- und Tunnelpfade geprüft - [ ] Load Balancer berücksichtigt - [ ] Direct Server Return berücksichtigt - [ ] zustandsabhängige Komponenten erfasst - [ ] richtige Firewall bestimmt - [ ] aktiven Clusterknoten bestimmt - [ ] virtuellen Firewallkontext bestimmt - [ ] Sessiontabellen aller möglichen Knoten geprüft - [ ] Sitzungs-ID dokumentiert - [ ] Session Owner bestimmt - [ ] generischen Tracking-Zustand geprüft - [ ] TCP-Zustand geprüft - [ ] UDP-Pseudositzung berücksichtigt - [ ] ICMP-Zuordnung berücksichtigt - [ ] `[UNREPLIED]` oder vergleichbaren Zustand geprüft - [ ] `[ASSURED]` oder vergleichbaren Zustand geprüft - [ ] Pakete je Richtung verglichen - [ ] Bytes je Richtung verglichen - [ ] Timeout geprüft - [ ] Sitzungsendgrund geprüft - [ ] NAT-Sitzung geprüft - [ ] NAT-Besitzer bestimmt - [ ] Cluster-State-Synchronisation geprüft - [ ] Konfigurationssynchronisation getrennt geprüft - [ ] letzten Failoverzeitpunkt geprüft - [ ] Conntrack-Anzahl erfasst - [ ] Conntrack-Maximalwert erfasst - [ ] Conntrack-Auslastung berechnet - [ ] Conntrack-Statistiken geprüft - [ ] Insert-Failed-Zähler geprüft - [ ] Drop- und Early-Drop-Zähler geprüft - [ ] Hardware-Offloading berücksichtigt - [ ] Flow Logs geprüft - [ ] Paketaufzeichnung am Client durchgeführt, sofern erforderlich - [ ] Paketaufzeichnung an der Firewall durchgeführt, sofern erforderlich - [ ] Paketaufzeichnung am Server durchgeführt, sofern erforderlich - [ ] Zeitstempel korreliert - [ ] Hypothese formuliert - [ ] Gegenbeweis definiert - [ ] Risiko dokumentiert - [ ] Rückweg dokumentiert - [ ] nur eine kontrollierte Maßnahme durchgeführt - [ ] vollständig neue Sitzung getestet - [ ] mehrere Verbindungen bei ECMP geprüft - [ ] ursprüngliche Anwendung verifiziert - [ ] repräsentative weitere Datenflüsse geprüft - [ ] temporäre Diagnosen zurückgenommen - [ ] Ursache und Prävention dokumentiert --- **Schnellreferenz** | Aufgabe | Befehl | |---|---| | Windows-Routingtabelle | `route print` | | Windows-Routen | `Get-NetRoute` | | Windows-Zielroute | `Find-NetRoute -RemoteIPAddress "198.51.100.25"` | | Windows-Traceroute | `tracert 198.51.100.25` | | Linux-Zielroute | `ip route get 198.51.100.25` | | Linux-Zielroute mit Quelle | `ip route get 198.51.100.25 from 192.0.2.100` | | Linux-Policy-Routing | `ip rule show` | | Linux-alle Routingtabellen | `ip route show table all` | | Linux-IPv6-Route | `ip -6 route get 2001:db8::25` | | Linux-Traceroute | `traceroute 198.51.100.25` | | Linux-Path-MTU/Pfad | `tracepath 198.51.100.25` | | macOS-Zielroute | `route -n get 198.51.100.25` | | macOS-Traceroute | `traceroute 198.51.100.25` | | Conntrack-Einträge | `sudo conntrack -L` | | Conntrack-Anzahl | `sudo conntrack -C` | | Conntrack-Statistiken | `sudo conntrack -S` | | Conntrack-Ereignisse | `sudo conntrack -E` | | aktueller Conntrack-Füllstand | `sysctl net.netfilter.nf_conntrack_count` | | maximales Conntrack-Limit | `sysctl net.netfilter.nf_conntrack_max` | | Conntrack-Hash-Buckets | `sysctl net.netfilter.nf_conntrack_buckets` | | Reverse Path Filtering | `sysctl net.ipv4.conf.all.rp_filter` | | Cisco ASA Sitzungen | `show conn` | | Cisco ASA Sitzungsanzahl | `show conn count` | | Cisco ASA NAT | `show xlate` | | Cisco ASA HA | `show failover` | | Cisco ASA Drops | `show asp drop` | | Juniper Sitzungen | `show security flow session` | | Juniper Flow-Statistik | `show security flow statistics` | | Juniper Cluster | `show chassis cluster status` | | Palo Alto Sitzungssuche | `show session all filter source 192.0.2.100 destination 198.51.100.25 destination-port 443` | | Palo Alto HA | `show high-availability state` | Verändernde Befehle und Maßnahmen, die nicht als erste Diagnose verwendet werden dürfen: ```text conntrack -F conntrack -D clear conn clear xlate clear session all clear security flow session Firewall-State-Bypass aktivieren TCP State Bypass aktivieren Stateful Inspection deaktivieren Conntrack-Limit ungeprüft erhöhen Sessiontimeout ungeprüft erhöhen Routingprotokoll neu starten Cluster-Failover erzwingen Firewallcluster neu starten ECMP global deaktivieren produktive Route ungeprüft entfernen SNAT pauschal aktivieren Hardware-Offloading global deaktivieren ``` --- **Quellen** **Standards und Grundlagen** - [NIST SP 800-41 Revision 1 – Guidelines on Firewalls and Firewall Policy](https://csrc.nist.gov/pubs/sp/800/41/r1/final) - [RFC 9293 – Transmission Control Protocol](https://datatracker.ietf.org/doc/html/rfc9293) - [RFC 768 – User Datagram Protocol](https://datatracker.ietf.org/doc/html/rfc768) - [RFC 792 – Internet Control Message Protocol](https://datatracker.ietf.org/doc/html/rfc792) - [RFC 4443 – Internet Control Message Protocol for IPv6](https://datatracker.ietf.org/doc/html/rfc4443) - [RFC 3022 – Traditional IP Network Address Translator](https://datatracker.ietf.org/doc/html/rfc3022) - [RFC 4787 – NAT Behavioral Requirements for UDP](https://datatracker.ietf.org/doc/html/rfc4787) - [RFC 7857 – Updates to NAT Behavioral Requirements](https://datatracker.ietf.org/doc/html/rfc7857) **Linux Kernel und Netfilter** - [Linux Kernel Documentation – Netfilter Conntrack Sysfs Variables](https://docs.kernel.org/networking/nf_conntrack-sysctl.html) - [Linux Kernel Documentation – Conntrack Netlink Specification](https://docs.kernel.org/next/netlink/specs/conntrack.html) - [Netfilter – Conntrack Tools User Manual](https://conntrack-tools.netfilter.org/manual.html) - [Netfilter – `conntrack` Command Documentation](https://conntrack-tools.netfilter.org/conntrack.html) - [nftables – Matching Connection Tracking Stateful Metadata](https://wiki.nftables.org/wiki-nftables/index.php/Matching_connection_tracking_stateful_metainformation) - [nftables – Flowtables](https://wiki.nftables.org/wiki-nftables/index.php/Flowtable) **Cisco** - [Cisco Secure Firewall ASA – Connection Settings](https://www.cisco.com/c/en/us/td/docs/security/asa/asa920/configuration/firewall/asa-920-firewall-config/conns-connlimits.html) - [Cisco – Configure TCP State Bypass on ASA](https://www.cisco.com/c/en/us/support/docs/security/asa-5500-x-series-next-generation-firewalls/118995-configure-asa-00.html) - [Cisco Secure Firewall ASA – `show` Command Reference](https://www.cisco.com/c/en/us/td/docs/security/asa/asa-cli-reference/S/asa-command-ref-S/show-t-commands.html) - [Cisco Secure Firewall ASA – `packet-tracer` Command Reference](https://www.cisco.com/c/en/us/td/docs/security/asa/asa-cli-reference/I-R/asa-command-ref-I-R/pa-pn-commands.html) - [Cisco Secure Firewall ASA – `show asp drop` Usage](https://www.cisco.com/c/en/us/td/docs/security/asa/asa-cli-reference/show_asp_drop_command_usage/show-asp-drop-command-usage.html) **Juniper Networks** - [Juniper – `show security flow session`](https://www.juniper.net/documentation/us/en/software/junos/cli-reference/topics/ref/command/show-security-flow-session.html) - [Juniper – Express Path Overview](https://www.juniper.net/documentation/us/en/software/junos/flow-packet-processing/topics/topic-map/security-express-path.html) **Amazon Web Services** - [AWS Network Firewall – Avoiding Asymmetric Routing](https://docs.aws.amazon.com/network-firewall/latest/developerguide/asymmetric-routing.html) - [AWS Network Firewall – Troubleshooting General Issues](https://docs.aws.amazon.com/network-firewall/latest/developerguide/troubleshooting-general-issues.html) - [AWS Network Firewall – Analyzing Stateless Rule Groups](https://docs.aws.amazon.com/network-firewall/latest/developerguide/stateless-rule-group-analyzer.html) - [Amazon EC2 – Security Group Connection Tracking](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-connection-tracking.html) **Microsoft Azure** - [Microsoft Learn – Asymmetrisches Routing mit mehreren Netzwerkpfaden](https://learn.microsoft.com/de-de/azure/expressroute/expressroute-asymmetric-routing) - [Microsoft Learn – Integrate Azure Firewall with Azure Standard Load Balancer](https://learn.microsoft.com/en-us/azure/firewall/integrate-lb) - [Microsoft Learn – Diagnose an Azure Virtual Machine Routing Problem](https://learn.microsoft.com/en-us/azure/virtual-network/diagnose-network-routing-problem) - [Microsoft Learn – Virtual WAN Hub Routing Policies](https://learn.microsoft.com/en-us/azure/virtual-wan/how-to-routing-policies) Für diese Seite wurden keine Community-Beiträge oder Hersteller-Social-Media-Aussagen als fachlicher Nachweis verwendet. # 9.7 Ephemeral Ports und Verbindungsgrenzen Beim Aufbau einer ausgehenden TCP- oder UDP-Kommunikation benötigt das initiierende System normalerweise einen freien lokalen Quellport. Dieser kurzzeitig verwendete Port wird als dynamischer, temporärer oder ephemerer Port bezeichnet. Beispiel: ```text Client: 192.0.2.100:53124 Server: 198.51.100.25:443 Datenfluss: 192.0.2.100:53124 -> 198.51.100.25:443/TCP ``` Der Server verwendet den bekannten Zielport `443`. Der Client verwendet den dynamisch ausgewählten Quellport `53124`. Wenn kein geeigneter Quellport, Socket, Dateideskriptor, NAT-Eintrag oder Verbindungseintrag mehr verfügbar ist, können neue Verbindungen fehlschlagen, obwohl: - das Ziel erreichbar ist; - die Firewallregel stimmt; - der Serverdienst läuft; - bestehende Verbindungen weiterhin funktionieren; - Ping erfolgreich ist; - DNS korrekt auflöst. --- **Ziele** Nach der Bearbeitung dieser Seite soll nachvollziehbar geprüft werden können: - welcher dynamische Portbereich auf einem System tatsächlich gilt; - wie viele Ports dieses Bereichs belegt sind; - welcher Prozess besonders viele Verbindungen erzeugt; - ob `TIME_WAIT`, `CLOSE_WAIT` oder andere Zustände auffällig sind; - ob lokale Porterschöpfung oder SNAT-Porterschöpfung vorliegt; - ob ein NAT-Gateway, Load Balancer oder eine Firewall die Grenze erreicht; - ob statt Ports eine andere Verbindungsgrenze betroffen ist; - warum bestehende Sitzungen funktionieren, während neue Verbindungen scheitern; - wie Verbindungswiederverwendung und Connection Pooling die Last reduzieren; - wie eine Kapazitätsänderung sicher geplant und verifiziert wird. --- **Sicherheits- und Änderungsgrundsätze** Port- und Verbindungsgrenzen dürfen nicht ohne Ursachenanalyse verändert werden. Eine größere Grenze kann das Symptom verschieben, während die eigentliche Ursache bestehen bleibt. Mögliche Ursachen sind: - fehlerhafte Anwendungsschleife; - fehlende Verbindungswiederverwendung; - nicht geschlossene Sockets; - ungewöhnlich hohe Verbindungsrate; - langsames oder nicht antwortendes Ziel; - zu großer Retry-Sturm; - Portscan; - Schadsoftware; - DDoS; - ungeeignete NAT-Architektur; - fehlerhafte Timeouts; - fehlende Kapazitätsplanung. Nicht als erste Diagnosemaßnahme geeignet sind: - Server vorsorglich neu starten; - NAT-Gateway neu erstellen; - Firewall-Sitzungstabelle vollständig löschen; - Conntrack-Tabelle leeren; - dynamischen Portbereich ungeprüft erweitern; - `TIME_WAIT`-Dauer ungeprüft verkürzen; - Socket- oder Dateideskriptorgrenzen maximal erhöhen; - Verbindungsbegrenzungen deaktivieren; - mehrere öffentliche IP-Adressen ohne Kapazitätsnachweis ergänzen; - alle Anwendungspools neu starten; - Keepalive- oder Timeoutwerte pauschal verändern; - Sicherheitssoftware deaktivieren. Vor jeder Änderung sind zu dokumentieren: - Ausgangszustand; - aktueller Portbereich; - Anzahl belegter Ports; - Verbindungszustände; - betroffene Prozesse; - häufigste Ziele; - Verbindungsrate; - NAT- oder SNAT-Auslastung; - weitere Ressourcenlimits; - Risiko; - Rückweg; - Erfolgskriterium; - Testverfahren. --- **Portnummernbereiche** IANA unterscheidet folgende Bereiche: | Bereich | Bezeichnung | Typische Verwendung | |---:|---|---| | `0–1023` | System Ports | bekannte und besonders geschützte Dienste | | `1024–49151` | User Ports | registrierte Anwendungsdienste | | `49152–65535` | Dynamic/Private Ports | dynamische oder private Verwendung | Der IANA-Bereich `49152–65535` ist eine allgemeine Einteilung. Er beweist nicht, dass ein Betriebssystem lokal genau diesen Bereich verwendet. Der tatsächlich verwendete Bereich kann abhängen von: - Betriebssystem; - Betriebssystemversion; - TCP oder UDP; - IPv4 oder IPv6; - Netzwerknamespace; - Anwendung; - expliziter Socketbindung; - Systemrichtlinie; - Containerplattform; - Cloudplattform; - NAT-Gerät; - benutzerdefinierter Konfiguration. Deshalb muss der aktuelle Bereich auf dem betroffenen System ausgelesen werden. --- **Ephemeren Quellport und Serverport unterscheiden** Normale Clientverbindung: ```text 192.0.2.100:53124 -> 198.51.100.25:443/TCP ``` | Port | Rolle | |---:|---| | `53124` | dynamischer Quellport des Clients | | `443` | Zielport des Serverdienstes | Rückverkehr: ```text 198.51.100.25:443 -> 192.0.2.100:53124/TCP ``` Der Server benötigt nicht für jeden eingehenden Client einen neuen lokalen Listenerport. Alle HTTPS-Verbindungen können lokal den Serverport `443` verwenden, weil die vollständigen Verbindungen durch unterschiedliche Adressen und Ports unterscheidbar bleiben. --- **Das Verbindungstupel** Eine TCP- oder UDP-Kommunikation wird typischerweise über folgende Merkmale unterschieden: ```text Quelladresse Quellport Zieladresse Zielport Protokoll ``` Beispiel: ```text 192.0.2.100:53124 -> 198.51.100.25:443/TCP ``` Eine gleichzeitig bestehende Verbindung kann denselben lokalen Port möglicherweise gegenüber einem anderen Ziel verwenden: ```text 192.0.2.100:53124 -> 203.0.113.80:443/TCP ``` Ob und wie ein Betriebssystem lokale Ports zwischen verschiedenen Zielen wiederverwendet, hängt von Implementierung, Bindungsart und Socketoptionen ab. Deshalb gilt nicht allgemein: ```text Anzahl dynamischer Ports = maximale Gesamtzahl aller ausgehenden Verbindungen ``` Die Grenze muss immer im Zusammenhang mit Quelladresse, Zieladresse, Zielport, Protokoll, NAT und Verbindungszustand bewertet werden. --- **Anzahl eines Portbereichs berechnen** Allgemeine Berechnung: ```text Anzahl = Endport - Startport + 1 ``` Beispiel: ```text Startport: 49152 Endport: 65535 Anzahl: 65535 - 49152 + 1 = 16384 Ports ``` Davon können abzuziehen sein: - reservierte Ports; - bereits gebundene Ports; - Ports in aktiven Verbindungen; - noch nicht wiederverwendbare Verbindungstupel; - Ports in `TIME_WAIT`; - anwendungsspezifische Ausschlüsse; - System- oder Plattformreservierungen; - Sicherheitsrichtlinien; - NAT- oder Providerbeschränkungen. Die theoretische Anzahl ist deshalb keine garantierte Verbindungskapazität. --- **TCP und UDP getrennt betrachten** TCP und UDP besitzen getrennte Protokollräume. Derselbe numerische Port kann gleichzeitig für TCP und UDP verwendet werden. Beispiel: ```text TCP 53124 UDP 53124 ``` Das sind zwei unterschiedliche Transportendpunkte. Zu prüfen sind daher getrennt: - dynamischer TCP-Portbereich; - dynamischer UDP-Portbereich; - TCP-Verbindungen; - UDP-Endpunkte; - TCP-Time-Wait-Zustände; - UDP-Tracking- und NAT-Timeouts; - protokollspezifische Cloudlimits. Eine funktionierende UDP-Verbindung beweist nicht, dass noch TCP-Ports verfügbar sind. --- **IPv4 und IPv6 getrennt prüfen** Betriebssysteme und Plattformen können Portbereiche oder Zustände für IPv4 und IPv6 getrennt verwalten. Zu prüfen sind: - verwendete Adressfamilie; - IPv4-Portbereich; - IPv6-Portbereich; - Dual-Stack-Verhalten; - Happy-Eyeballs-Verbindungen; - getrennte Firewallregeln; - getrennte NAT- oder SNAT-Pfade; - IPv4-mapped IPv6 Sockets; - Anwendung mit mehreren parallelen Verbindungsversuchen. Eine Anwendung kann bei einem Namensaufruf mehrere IPv6- und IPv4-Verbindungen starten. Dadurch kann die Zahl der Verbindungsversuche höher sein als die Zahl sichtbarer Benutzeranfragen. --- **Lokale und übersetzte Ports unterscheiden** Ein NAT- oder SNAT-Gerät kann den lokalen Quellport verändern. Beispiel: ```text Vor SNAT: 10.10.20.25:53124 -> 203.0.113.80:443 Nach SNAT: 198.51.100.5:61001 -> 203.0.113.80:443 ``` Dabei existieren zwei unterschiedliche Portbetrachtungen: | Ebene | Port | |---|---:| | lokaler Clientport | `53124` | | externer SNAT-Port | `61001` | Der Client kann lokal noch Ports besitzen, während der SNAT-Portpool des Gateways erschöpft ist. Umgekehrt kann das NAT-Gateway noch Kapazität besitzen, während das lokale Betriebssystem keinen geeigneten Quellport mehr findet. --- **Lokale Porterschöpfung** Lokale Porterschöpfung liegt vor, wenn ein System für eine neue ausgehende Kommunikation keinen geeigneten lokalen Port beziehungsweise kein verwendbares lokales Verbindungstupel mehr zuweisen kann. Typische Symptome: - neue ausgehende TCP-Verbindungen schlagen fehl; - bestehende TCP-Verbindungen funktionieren weiter; - Fehler tritt nach längerer Laufzeit auf; - Neustart behebt das Problem nur vorübergehend; - viele Verbindungen besitzen denselben Prozess; - viele Einträge befinden sich in `TIME_WAIT`; - sehr viele Einträge befinden sich in `CLOSE_WAIT`; - hohe Anzahl von Verbindungen zu demselben Ziel; - DNS, Kerberos, RPC, Datenbank- oder API-Aufrufe scheitern gleichzeitig; - eingehende Verbindungen können teilweise weiter funktionieren; - Fehler verschwindet, sobald Verbindungen aus der Tabelle altern. Mögliche Fehlermeldungen sind abhängig von Betriebssystem und Anwendung: ```text Cannot assign requested address Address already in use No buffer space available Too many open files Only one usage of each socket address is normally permitted Connection timed out Connection failed ``` Diese Meldungen sind nicht gleichbedeutend. Beispielsweise kann `Address already in use` auch auf eine einzelne explizite Portkollision hinweisen. --- **SNAT-Porterschöpfung** Bei SNAT teilen sich mehrere interne Systeme eine oder mehrere externe IP-Adressen. Beispiel: ```text 10.10.20.11 -> 198.51.100.5 10.10.20.12 -> 198.51.100.5 10.10.20.13 -> 198.51.100.5 ``` Das NAT-Gateway muss die Verbindungen über externe Quellports eindeutig zuordnen. Eine hohe Konzentration auf dasselbe Ziel kann besonders kritisch sein: ```text viele interne Systeme -> eine öffentliche NAT-Adresse -> eine Zieladresse -> ein Zielport ``` Beispiel: ```text 1000 interne Anwendungsinstanzen -> 198.51.100.5 -> 203.0.113.80:443 ``` Mögliche Symptome: - nur ausgehende Verbindungen über das NAT-Gateway scheitern; - interne Ziele funktionieren; - bestehende Verbindungen funktionieren; - neue Verbindungen zu einem häufig genutzten Ziel schlagen fehl; - Verbindungen zu anderen Zieladressen funktionieren; - Fehler tritt nur unter Last auf; - Cloudmetrik zeigt Port Allocation Errors; - zusätzliche NAT-IP verbessert das Verhalten; - Connection Pooling reduziert die Fehler. --- **Porterschöpfung pro Ziel einordnen** Der kritische Grenzfall ist häufig nicht die Gesamtzahl aller Ziele, sondern eine hohe Zahl gleichzeitiger oder schnell wiederholter Verbindungen zu genau derselben Kombination aus: ```text Ziel-IP-Adresse Zielport Protokoll ``` Beispiel: ```text 203.0.113.80:443/TCP ``` Ein API-Gateway, Datenbankserver, Proxy oder zentrales Authentifizierungssystem kann dadurch einen besonders konzentrierten Portbedarf erzeugen. Zu prüfen sind: - Anzahl unterschiedlicher Zieladressen; - Anzahl unterschiedlicher Zielports; - Verbindungen je Ziel; - neue Verbindungen pro Sekunde; - durchschnittliche Lebensdauer; - Anteil wiederverwendeter Verbindungen; - Retryrate; - Timeoutdauer; - DNS-Lastverteilung; - NAT-IP-Adressen; - Backend- oder Zielverteilung. --- **TIME_WAIT** Nach dem regulären Ende einer TCP-Verbindung kann das System das Verbindungstupel für eine bestimmte Zeit im Zustand `TIME_WAIT` halten. Zweck ist unter anderem: - verspätete Segmente einer alten Verbindung abzufangen; - eine neue gleichartige Verbindung nicht mit alten Paketen zu vermischen; - den abschließenden Verbindungsabbau zuverlässig behandeln zu können. Viele `TIME_WAIT`-Einträge sind nicht automatisch ein Fehler. Sie zeigen jedoch eine hohe Rate kurzlebiger TCP-Verbindungen. Kritisch wird die Situation, wenn gleichzeitig: - neue ausgehende Verbindungen scheitern; - der dynamische Portbereich stark belegt ist; - Windows-Ereignisse auf Porterschöpfung hinweisen; - ein einzelner Prozess besonders viele Verbindungen erzeugt; - ein einzelnes Ziel stark konzentriert ist; - die Einträge schneller entstehen als sie freigegeben werden. Ein hoher `TIME_WAIT`-Bestand ohne Verbindungsfehler beweist keine aktuelle Porterschöpfung. --- **CLOSE_WAIT** `CLOSE_WAIT` bedeutet vereinfacht: 1. Die Gegenstelle hat das Ende der Verbindung angekündigt. 2. Das lokale Betriebssystem hat dies an die Anwendung gemeldet. 3. Die lokale Anwendung hat ihren Socket noch nicht vollständig geschlossen. Viele dauerhaft bestehende `CLOSE_WAIT`-Einträge können auf eine Anwendung hinweisen, die Verbindungen nicht korrekt schließt. Zu prüfen sind: - betroffener Prozess; - Alter der Verbindungen; - Wachstum über die Zeit; - Remoteziele; - Anwendungsprotokolle; - Thread- oder Taskzustand; - Fehlerbehandlung; - Connection Pool; - Dateideskriptorverbrauch. `CLOSE_WAIT` beweist nicht automatisch eine erschöpfte dynamische Portmenge. Es kann jedoch gleichzeitig Sockets, Dateideskriptoren, Speicher und lokale Verbindungstupel binden. --- **SYN_SENT** Viele Verbindungen im Zustand `SYN_SENT` bedeuten, dass das lokale System Verbindungsanfragen gesendet hat, aber der TCP-Handshake noch nicht abgeschlossen wurde. Mögliche Ursachen: - Ziel antwortet nicht; - Firewall verwirft; - Rückroute fehlt; - Ziel ist überlastet; - falsche Zieladresse; - Paketverlust; - zu lange Anwendungstimeouts; - Retry-Sturm; - SYN-Pakete werden schneller erzeugt als sie ablaufen. Viele lang anhaltende `SYN_SENT`-Verbindungen können Ports und Sockets binden, obwohl keine erfolgreiche Anwendungskommunikation entsteht. --- **ESTABLISHED** Viele `ESTABLISHED`-Verbindungen können beabsichtigt sein, beispielsweise bei: - Datenbank-Connection-Pools; - HTTP-Keepalive; - HTTP/2; - WebSockets; - Message Brokern; - Streaming; - Replikation; - persistenten Agentenverbindungen. Zu prüfen sind: - sind die Verbindungen aktiv oder ungenutzt? - entspricht die Anzahl der Konfiguration? - werden alte Verbindungen ersetzt, ohne geschlossen zu werden? - existiert eine obere Poolgrenze? - besitzt jede Anwendungsinstanz einen eigenen Pool? - wächst die Zahl dauerhaft? - passt die Summe aller Instanzpools zur Zielkapazität? Eine hohe Zahl etablierter Verbindungen ist nicht automatisch Porterschöpfung. Sie kann jedoch andere Grenzwerte erreichen. --- **FIN_WAIT und LAST_ACK** Viele Verbindungen in Zuständen des Verbindungsabbaus können auf Probleme beim sauberen Beenden hinweisen. Zu prüfen sind: - antwortet die Gegenstelle auf den Verbindungsabbau? - besitzt die Anwendung geeignete Schließ- und Abbruchlogik? - blockiert eine Firewall abschließende Pakete? - existiert ein asymmetrischer Rückweg? - werden Verbindungen durch Timeouts statt kontrolliert beendet? - treten Paketverluste auf? - ist das Ziel überlastet? Die genaue Bedeutung ist anhand der TCP-Zustandsfolge und einer Paketaufzeichnung zu prüfen. --- **UDP und QUIC** UDP besitzt keinen TCP-Verbindungsabbau und keinen TCP-`TIME_WAIT`-Zustand. Trotzdem können UDP-Sockets, NAT-Zuordnungen und Connection-Tracking-Einträge Ports belegen. Betroffene Anwendungen können sein: - DNS; - VoIP; - Streaming; - QUIC und HTTP/3; - VPN; - Telemetrie; - Gaming; - Monitoring. Zu prüfen sind: - lokale UDP-Endpunkte; - NAT-Timeout; - Conntrack-Timeout; - Portwiederverwendung; - Antwortverkehr; - QUIC-Verbindungsrate; - Anzahl externer Ziele; - Firewallzustand; - anwendungsspezifische Socketverwaltung. Eine Analyse ausschließlich der TCP-Verbindungen übersieht UDP- oder QUIC-bedingte Engpässe. --- **RPC-Dynamik nicht mit Clientports verwechseln** Windows RPC kann nach dem Kontakt zum RPC Endpoint Mapper auf TCP-Port `135` einen dynamischen Serverport verwenden. Vereinfachter Ablauf: 1. Client kontaktiert Ziel auf TCP `135`. 2. Endpoint Mapper nennt den dynamischen Serverport. 3. Client verbindet sich mit diesem Zielport. 4. Der Client verwendet dafür zusätzlich einen eigenen dynamischen Quellport. Beispiel: ```text Client: 192.0.2.100:53124 RPC-Server: 198.51.100.25:52044 Verbindung: 192.0.2.100:53124 -> 198.51.100.25:52044/TCP ``` Dabei sind beide Ports dynamisch, aber mit unterschiedlichen Rollen: | Port | Rolle | |---:|---| | `53124` | dynamischer Clientquellport | | `52044` | dynamisch zugewiesener RPC-Serverzielport | Firewallregeln müssen diese Rollen korrekt berücksichtigen. --- **Porterschöpfung und andere Verbindungsgrenzen unterscheiden** | Grenze | Typischer Befund | |---|---| | dynamischer lokaler Portbereich | kein geeigneter Quellport für neue Verbindung | | SNAT-Portpool | NAT-Gerät kann keine neue Übersetzung anlegen | | Socketgrenze | Anwendung oder Kernel kann keinen weiteren Socket anlegen | | Dateideskriptorgrenze | Prozess erhält beispielsweise `Too many open files` | | Prozesshandlegrenze | Betriebssystem oder Prozess erreicht Handlegrenze | | Conntrack-Tabelle | Firewall oder Router kann keinen neuen Zustand anlegen | | Firewall-Sessionlimit | neue Sitzungen werden verworfen | | NAT-Sessionlimit | neue NAT-Zuordnungen schlagen fehl | | TCP-SYN-Backlog | neue Handshakes warten oder werden verworfen | | Accept-Backlog | vollständig aufgebaute Verbindungen werden nicht schnell genug angenommen | | Anwendungslimit | Dienst erlaubt nur definierte Zahl paralleler Verbindungen | | Connection-Pool-Limit | Anwendung wartet auf freien Poolplatz | | Thread- oder Workerlimit | Verbindungen werden nicht rechtzeitig verarbeitet | | Datenbanklimit | maximale Datenbanksitzungen erreicht | | Load-Balancer-Limit | Flow-, Port- oder Zielgrenze erreicht | | Cloudquote | plattformspezifische Obergrenze erreicht | | Zielsystemlimit | Gegenstelle begrenzt Quellen oder Verbindungsrate | | API-Rate-Limit | Anwendung lehnt Anfragen trotz funktionierender TCP-Verbindung ab | Ein erfolgreicher TCP-Porttest beweist nicht, dass die Anwendung noch einen Datenbankpoolplatz oder Worker besitzt. --- **Windows: dynamischen Portbereich anzeigen** IPv4 TCP: ```cmd netsh int ipv4 show dynamicport tcp ``` IPv4 UDP: ```cmd netsh int ipv4 show dynamicport udp ``` IPv6 TCP: ```cmd netsh int ipv6 show dynamicport tcp ``` IPv6 UDP: ```cmd netsh int ipv6 show dynamicport udp ``` Bei aktuellen unterstützten Windows-Versionen ist der Standardbereich normalerweise: ```text Startport: 49152 Endport: 65535 Anzahl: 16384 ``` Der tatsächliche Systemwert ist trotzdem mit `netsh` zu prüfen. TCP, UDP, IPv4 und IPv6 werden getrennt angezeigt. --- **Windows: TCP-Verbindungen anzeigen** Alle TCP-Verbindungen: ```powershell Get-NetTCPConnection ``` Etablierte Verbindungen: ```powershell Get-NetTCPConnection ` -State Established ``` `TIME_WAIT`: ```powershell Get-NetTCPConnection ` -State TimeWait ``` `CLOSE_WAIT`: ```powershell Get-NetTCPConnection ` -State CloseWait ``` Ausgehende Verbindungsversuche: ```powershell Get-NetTCPConnection ` -State SynSent ``` Nach Ziel filtern: ```powershell Get-NetTCPConnection ` -RemoteAddress "198.51.100.25" ` -RemotePort 443 ``` Nach Prozess-ID filtern: ```powershell Get-NetTCPConnection ` -OwningProcess ``` Prozess bestimmen: ```powershell Get-Process ` -Id ``` --- **Windows: Zustände zählen** ```powershell Get-NetTCPConnection | Group-Object State | Sort-Object Count -Descending | Select-Object Count, Name ``` Mögliche Ausgabe: ```text Count Name ----- ---- 8200 TimeWait 1450 Established 200 CloseWait 35 SynSent ``` Die Werte müssen mit einer Baseline und dem aktuellen Fehlerzeitpunkt verglichen werden. --- **Windows: Verbindungen je Prozess zählen** ```powershell Get-NetTCPConnection | Group-Object OwningProcess | Sort-Object Count -Descending | Select-Object -First 20 Count, Name ``` Die Spalte `Name` enthält in diesem Fall die Prozess-ID. Einzelne Prozess-IDs auflösen: ```powershell Get-Process ` -Id ``` Ausführlicher Zusammenhang: ```powershell Get-NetTCPConnection | ForEach-Object { $process = Get-Process -Id $_.OwningProcess -ErrorAction SilentlyContinue [PSCustomObject]@{ State = $_.State LocalAddress = $_.LocalAddress LocalPort = $_.LocalPort RemoteAddress = $_.RemoteAddress RemotePort = $_.RemotePort PID = $_.OwningProcess Process = $process.ProcessName } } | Sort-Object Process, State ``` Auf stark belasteten Systemen kann diese Auswertung umfangreich sein. Sie sollte gezielt und während des Fehlerzeitraums durchgeführt werden. --- **Windows: häufigste Ziele ermitteln** ```powershell Get-NetTCPConnection | Where-Object State -ne Listen | Group-Object RemoteAddress, RemotePort | Sort-Object Count -Descending | Select-Object -First 20 Count, Name ``` Damit kann festgestellt werden, ob sich sehr viele Verbindungen auf ein einzelnes Ziel konzentrieren. --- **Windows: klassische Netstat-Auswertung** Verbindungen, Ports und Prozess-IDs: ```cmd netstat -ano ``` Mit ausführbarer Datei, administrative Eingabeaufforderung erforderlich: ```cmd netstat -anob ``` Gebundene Ports einschließlich bestimmter nicht aktiver TCP-Bindungen: ```cmd netstat -anoq ``` `TIME_WAIT` zählen: ```cmd netstat -ano | find /c "TIME_WAIT" ``` `CLOSE_WAIT` zählen: ```cmd netstat -ano | find /c "CLOSE_WAIT" ``` `SYN_SENT` zählen: ```cmd netstat -ano | find /c "SYN_SENT" ``` Ein einfacher Textzähler ist nur ein Indikator. Für die Zuordnung zu Prozess, Ziel, Zeit und Portbereich ist die vollständige Ausgabe erforderlich. --- **Windows: Ereignisse prüfen** Windows kann bei Porterschöpfung unter anderem TCP/IP-Ereignisse `4227` und `4231` protokollieren. Gezielte Suche: ```powershell Get-WinEvent ` -FilterHashtable @{ LogName = "System" Id = 4227, 4231 StartTime = (Get-Date).AddHours(-24) } | Select-Object TimeCreated, Id, ProviderName, Message ``` Die Ereignisse müssen zeitlich mit den tatsächlichen Verbindungsfehlern korreliert werden. Ein hoher `TIME_WAIT`-Bestand allein bestätigt keine Porterschöpfung. Microsoft empfiehlt zusätzlich, reale ausgehende Verbindungsfehler und passende Ereignisse nachzuweisen. --- **Windows: Portbereich eines Tests berücksichtigen** Wenn der ausgelesene TCP-Bereich beispielsweise `49152–65535` lautet: ```powershell $startPort = 49152 $endPort = 65535 Get-NetTCPConnection | Where-Object { $_.LocalPort -ge $startPort -and $_.LocalPort -le $endPort } | Group-Object State | Sort-Object Count -Descending | Select-Object Count, Name ``` Die Werte müssen an den tatsächlich mit `netsh` ermittelten Bereich angepasst werden. --- **Linux: lokalen Portbereich anzeigen** ```bash sysctl net.ipv4.ip_local_port_range ``` Alternative: ```bash cat /proc/sys/net/ipv4/ip_local_port_range ``` Beispielausgabe: ```text 32768 60999 ``` Das ist nur ein Beispiel. Die lokale Ausgabe ist maßgeblich. Reservierte lokale Ports: ```bash sysctl net.ipv4.ip_local_reserved_ports ``` Alternative: ```bash cat /proc/sys/net/ipv4/ip_local_reserved_ports ``` `ip_local_port_range` und `ip_local_reserved_ports` sind getrennte Einstellungen. Beide beeinflussen, welche Ports für automatische Zuweisungen zur Verfügung stehen. --- **Linux: Socketübersicht** ```bash ss -s ``` Mögliche Bereiche der Zusammenfassung: - Gesamtzahl der Sockets; - TCP-Sockets; - etablierte Verbindungen; - geschlossene Zustände; - `TIME_WAIT`; - UDP-Sockets; - RAW-Sockets; - fragmentierte Zustände. Die genaue Darstellung hängt von der installierten `iproute2`-Version ab. --- **Linux: TCP-Verbindungen anzeigen** Alle TCP-Sockets: ```bash ss -tan ``` Mit Prozessinformationen: ```bash sudo ss -tanp ``` Etablierte Verbindungen: ```bash ss -tan state established ``` `TIME_WAIT`: ```bash ss -tan state time-wait ``` `CLOSE_WAIT`: ```bash ss -tan state close-wait ``` `SYN_SENT`: ```bash ss -tan state syn-sent ``` Listener: ```bash ss -lntp ``` Nach Ziel filtern: ```bash ss -tanp \ dst 198.51.100.25:443 ``` --- **Linux: Zustände zählen** ```bash ss -Htan | awk '{print $1}' | sort | uniq -c | sort -nr ``` Nur `TIME_WAIT` zählen: ```bash ss -Htan state time-wait | wc -l ``` Nur `CLOSE_WAIT` zählen: ```bash ss -Htan state close-wait | wc -l ``` Nur `SYN_SENT` zählen: ```bash ss -Htan state syn-sent | wc -l ``` --- **Linux: Kernel-Socketstatistik** IPv4 und allgemeine Socketstatistik: ```bash cat /proc/net/sockstat ``` IPv6: ```bash cat /proc/net/sockstat6 ``` Mögliche Felder sind unter anderem: - verwendete Sockets; - TCP in use; - orphaned; - `TIME_WAIT`; - zugewiesener Speicher; - UDP in use; - RAW in use; - fragmentierte Pakete. Die Werte sind Momentaufnahmen und müssen mit einer Baseline verglichen werden. --- **Linux: Dateideskriptorgrenzen** Grenze der aktuellen Shell: ```bash ulimit -n ``` Grenzen eines laufenden Prozesses: ```bash cat /proc//limits ``` Offene Dateideskriptoren eines Prozesses zählen: ```bash ls -1 /proc//fd | wc -l ``` Systemweite Dateideskriptorinformationen: ```bash cat /proc/sys/fs/file-nr ``` Systemweite Obergrenze: ```bash sysctl fs.file-max ``` Sockets werden unter Unix-ähnlichen Betriebssystemen über Dateideskriptoren angesprochen. Ein Prozess kann deshalb die Dateideskriptorgrenze erreichen, obwohl im dynamischen Portbereich noch Ports frei sind. --- **Linux: Listener- und Backloggrenzen** Aktuelle Listener: ```bash ss -lnt ``` Globale Obergrenze des Listen-Backlogs: ```bash sysctl net.core.somaxconn ``` TCP-SYN-Backlog: ```bash sysctl net.ipv4.tcp_max_syn_backlog ``` Bei einem Listening Socket zeigt `ss` abhängig von Version und Kontext unter anderem aktuelle und maximale Warteschlangenwerte an. Ein Backlogproblem betrifft eingehende Verbindungen und ist nicht mit ausgehender Porterschöpfung gleichzusetzen. --- **Linux: Conntrack zusätzlich prüfen** Anzahl aktuell verfolgter Verbindungen: ```bash sysctl net.netfilter.nf_conntrack_count ``` Maximalwert: ```bash sysctl net.netfilter.nf_conntrack_max ``` Statistiken, sofern `conntrack-tools` installiert ist: ```bash sudo conntrack -S ``` Eine volle Conntrack-Tabelle kann neue Verbindungen verhindern, obwohl das lokale Betriebssystem noch Quellports besitzt. --- **macOS: Portbereich prüfen** Verfügbare Portbereichsparameter anzeigen: ```bash sysctl -a | awk '/net\.inet\.ip\.portrange/' ``` Je nach macOS-Version können unter anderem folgende Werte verfügbar sein: ```bash sysctl net.inet.ip.portrange.first ``` ```bash sysctl net.inet.ip.portrange.last ``` ```bash sysctl net.inet.ip.portrange.hifirst ``` ```bash sysctl net.inet.ip.portrange.hilast ``` Die tatsächlich vorhandenen Parameter und Werte sind auf dem betroffenen Mac zu prüfen. --- **macOS: Verbindungen und Prozesse prüfen** TCP-Verbindungen: ```bash netstat -anv -p tcp ``` TCP-Sockets mit Prozessen: ```bash sudo lsof -nP -iTCP ``` Nur etablierte TCP-Verbindungen: ```bash sudo lsof -nP -iTCP -sTCP:ESTABLISHED ``` Nur Listener: ```bash sudo lsof -nP -iTCP -sTCP:LISTEN ``` TCP-Statistik: ```bash netstat -s -p tcp ``` Interaktive Netzwerksicht: ```bash nettop -m tcp ``` Die genaue Ausgabe unterscheidet sich je nach macOS-Version. --- **Prozess statt nur Portbereich untersuchen** Die wichtigste Frage lautet häufig: ```text Welcher Prozess erzeugt die Verbindungen? ``` Zu dokumentieren sind: - Prozessname; - Prozess-ID; - Dienst; - ausführbare Datei; - Benutzerkonto; - Startzeit; - Anzahl TCP-Verbindungen; - Anzahl UDP-Sockets; - Zustandsverteilung; - häufigste Ziele; - neue Verbindungen pro Sekunde; - Retryrate; - Fehlerprotokolle; - Connection-Pool-Konfiguration; - zuletzt durchgeführte Änderung. Ein Portbereich sollte nicht erweitert werden, bevor der verursachende Prozess und sein Verbindungsverhalten bekannt sind. --- **Verbindungsrate und gleichzeitige Verbindungen unterscheiden** | Metrik | Bedeutung | |---|---| | gleichzeitige Verbindungen | aktuell parallel bestehende Datenflüsse | | neue Verbindungen pro Sekunde | Geschwindigkeit des Verbindungsaufbaus | | geschlossene Verbindungen pro Sekunde | Geschwindigkeit des Abbaus | | `TIME_WAIT`-Bestand | noch nicht vollständig wiederverwendbare TCP-Zustände | | durchschnittliche Lebensdauer | Zeit bis zum Verbindungsende | | Retryrate | zusätzliche Versuche nach Fehler oder Timeout | | Wiederverwendungsquote | Anfragen pro bestehender Verbindung | Eine Anwendung mit nur wenigen gleichzeitig aktiven Anfragen kann trotzdem sehr viele Ports verbrauchen, wenn sie für jede Anfrage eine neue Verbindung erstellt. --- **Planungsnäherung für kurzlebige Verbindungen** Vereinfachte Abschätzung: ```text dauerhaft mögliche neue Verbindungen pro Sekunde ≈ verfügbare Portkombinationen / Belegungsdauer ``` Beispiel: ```text verfügbare Ports: 16384 angenommene Belegungsdauer: 240 Sekunden Näherung: 16384 / 240 ≈ 68 neue Verbindungen pro Sekunde ``` Diese Rechnung ist nur ein vereinfachtes Planungsmodell für eine konzentrierte Zielkombination. Das reale Verhalten hängt unter anderem ab von: - Betriebssystem; - Portauswahl; - Portwiederverwendung; - Zieladressen; - Zielports; - Quelladressen; - NAT; - TCP-Zustand; - Socketoptionen; - Sicherheitsrichtlinien; - Plattformlimits. Die Näherung darf nicht als garantierter Grenzwert verwendet werden. --- **Connection Pooling** Connection Pooling hält eine begrenzte Menge bestehender Verbindungen bereit und verwendet sie für mehrere Vorgänge erneut. Mögliche Vorteile: - weniger TCP-Handshakes; - weniger TLS-Handshakes; - geringere Verbindungsrate; - weniger `TIME_WAIT`; - geringerer Portverbrauch; - geringere CPU-Last; - geringere Latenz; - weniger Last auf NAT und Firewall. Zu prüfen sind: - minimale Poolgröße; - maximale Poolgröße; - Pool pro Prozess; - Pool pro Instanz; - Pool pro Benutzer; - Pool pro Ziel; - Idle-Timeout; - maximale Lebensdauer; - Health Check; - Validierung vor Wiederverwendung; - Verhalten bei Zielausfall; - Retrylogik; - Schließen beim Anwendungsende. Ein unbegrenzt großer Pool beseitigt keine Kapazitätsgrenzen und kann das Zielsystem überlasten. --- **HTTP-Verbindungen wiederverwenden** Für HTTP-basierte Anwendungen sind relevant: - HTTP/1.1 Keep-Alive; - HTTP/2-Multiplexing; - HTTP/3 über QUIC; - Proxyverbindungen; - maximale parallele Verbindungen pro Ziel; - DNS-Änderungen; - TLS-Sitzungswiederverwendung; - Clientbibliothek; - Lebensdauer des HTTP-Clients. Ein häufiges Fehlmuster ist die Erstellung eines neuen HTTP-Clients und einer neuen TCP-/TLS-Verbindung für jede einzelne Anfrage. Besser ist eine kontrollierte Wiederverwendung mit: - begrenztem Pool; - korrekten Timeouts; - Fehlerbehandlung; - DNS-Aktualisierung; - Gesundheitsprüfung; - sauberem Schließen beim Anwendungsende. Die konkrete Implementierung hängt von Programmiersprache, Framework und Bibliothek ab. --- **Retries kontrollieren** Ein langsames oder ausgefallenes Ziel kann einen Retry-Sturm auslösen. Beispiel: ```text 100 Anfragen × 5 sofortige Wiederholungen = 500 Verbindungsversuche ``` Bei mehreren Anwendungsinstanzen: ```text 500 Versuche × 20 Instanzen = 10000 Verbindungsversuche ``` Zu prüfen sind: - maximale Anzahl von Wiederholungen; - Wartezeit; - exponentielles Backoff; - zufällige Streuung oder Jitter; - Circuit Breaker; - Gesamtzeitlimit; - Wiederholung nur idempotenter Operationen; - gemeinsames Ziel aller Instanzen; - Verhalten bei DNS- oder TLS-Fehlern. Sofortige und unbegrenzte Retries können eine kleine Störung zu Port-, Socket- und Zielüberlastung verstärken. --- **AWS NAT Gateway** AWS dokumentiert für ein NAT Gateway pro zugeordneter IPv4-Adresse bis zu `55.000` gleichzeitige Verbindungen zu jedem eindeutigen Ziel. Ein eindeutiges Ziel wird dabei bestimmt durch: ```text Ziel-IP-Adresse Zielport Protokoll ``` Zu prüfen sind: - NAT-Gateway-Typ; - zugeordnete IPv4-Adressen; - Anzahl Verbindungen je Ziel; - CloudWatch-Metriken; - Port Allocation Errors; - Verbindungsversuche; - Idle Timeouts; - Availability Zone; - Routing; - Zielkonzentration. Mögliche relevante CloudWatch-Metriken sind abhängig vom Ressourcentyp unter anderem: - `ActiveConnectionCount`; - `ConnectionAttemptCount`; - `ErrorPortAllocation`; - `IdleTimeoutCount`; - `PacketsDropCount`. Zusätzliche NAT-IP-Adressen können die Kapazität erhöhen. Vorher muss jedoch geprüft werden, ob die Anwendung unnötig viele neue Verbindungen erstellt. --- **Azure NAT Gateway** Azure NAT Gateway stellt pro öffentlicher IPv4-Adresse `64.512` SNAT-Ports bereit. Ein NAT Gateway kann mehrere öffentliche IP-Adressen verwenden. Microsoft dokumentiert außerdem eine Grenze gleichzeitiger Verbindungen je eindeutigem Zielendpunkt. Die jeweils aktuelle Plattformdokumentation ist für die eingesetzte Ressource zu prüfen. Zu prüfen sind: - Anzahl öffentlicher IP-Adressen; - zugeordnete Subnetze; - SNAT Connection Count; - Failed SNAT Connection Count; - Zieladresse und Zielport; - Verbindungsrate; - TCP- und UDP-Nutzung; - Idle Timeouts; - Load-Balancer-Outbound-Regeln; - Azure Firewall; - NAT-Gateway-Zuordnung. TCP und UDP besitzen beim Azure NAT Gateway getrennte SNAT-Portinventare. --- **Azure Load Balancer** Ein Azure Load Balancer kann ausgehende SNAT-Ports nach konfigurierten Outbound Rules und Backendanzahl zuteilen. Zu prüfen sind: - Load-Balancer-SKU; - Outbound Rule; - Anzahl Backendinstanzen; - zugewiesene SNAT-Ports je Instanz; - verwendete öffentliche IP-Adressen; - Idle Timeout; - Port-Reuse; - SNAT-Port-Metriken; - Port Allocation Failures; - NAT-Gateway-Zuordnung. Eine ungleichmäßige Verbindungsverteilung kann dazu führen, dass eine einzelne Backendinstanz ihre Portzuteilung erreicht, obwohl andere Instanzen noch Kapazität besitzen. --- **Google Cloud NAT** Google Cloud NAT kann Ports statisch oder dynamisch auf VMs verteilen. Zu prüfen sind: - NAT-IP-Adressen; - minimale Ports pro VM; - maximale Ports pro VM; - dynamische Portzuweisung; - Endpoint-Independent Mapping; - Portnutzung je VM; - verworfene Pakete; - Zielkonzentration; - VM- und Podanzahl; - Verbindungsrate; - Logging und Monitoring. Bei dynamischer Portzuweisung kann eine schnelle Laststeigerung vorübergehend Pakete verlieren, während die Portzuweisung erweitert wird. Lasttests sollten deshalb auch den Anstieg der Verbindungsrate berücksichtigen. --- **Container und Kubernetes** Mehrere Container oder Pods können sich einen Host-, Node- oder NAT-Portpool teilen. Zu prüfen sind: - Netzwerkmodus; - eigener oder gemeinsamer Network Namespace; - Node-IP; - Pod-IP; - Host-NAT; - kube-proxy; - CNI-Plugin; - eBPF-Datenpfad; - Cloud NAT; - Service Mesh; - Sidecar Proxy; - Zahl der Pods; - Poolgröße pro Pod; - Retryverhalten; - Rolling Deployment; - Horizontal Scaling. Beispiel: ```text 50 Pods × 200 ausgehende Poolverbindungen = 10000 Verbindungen ``` Ein Scale-out kann den Gesamtportbedarf erhöhen, obwohl jede einzelne Instanz unverändert arbeitet. --- **Proxies und Gateways** Forward Proxies, Reverse Proxies, API Gateways und Service-Mesh-Sidecars initiieren eigene ausgehende Verbindungen. Dadurch existieren getrennte Verbindungsabschnitte: ```text Client -> Proxy Proxy -> Ziel ``` Zu prüfen sind für jeden Abschnitt: - Quelladresse; - Quellport; - Zieladresse; - Zielport; - Connection Pool; - maximale Verbindungen; - Idle Timeout; - Retrylogik; - NAT; - TLS-Terminierung; - Zahl der Worker; - Backendverteilung. Der Client kann ausreichend Ports besitzen, während der Proxy seinen ausgehenden Portpool erschöpft. --- **Firewalls und Connection Tracking** Zusätzlich zum Quellport muss eine Stateful Firewall oder ein NAT-Router häufig einen Sitzungseintrag anlegen. Zu prüfen sind: - aktuelle Sitzungsanzahl; - maximales Sitzungslimit; - Neuverbindungen pro Sekunde; - NAT-Übersetzungen; - Verbindungen je Quelle; - Verbindungen je Ziel; - halb offene Sitzungen; - UDP-Pseudositzungen; - Timeouts; - Drop-Zähler; - Tabellenfüllstand; - Cluster-Synchronisation. Eine Portbereichserweiterung am Client kann die Firewall stärker belasten und dort die nächste Grenze erreichen. --- **Serverseitige Verbindungsgrenzen** Wenn eingehende Verbindungen scheitern, sind zusätzlich zu prüfen: - Listener vorhanden; - Listeneradresse; - Listenerport; - SYN-Backlog; - Accept-Backlog; - maximale Clients; - Workerzahl; - Threadzahl; - Prozessgrenze; - Dateideskriptorgrenze; - Datenbankpool; - Zielabhängigkeiten; - CPU; - Speicher; - Garbage Collection; - Lizenzgrenze; - Rate Limit; - Reverse Proxy; - Load Balancer. Typische Unterscheidung: | Befund | Mögliche Einordnung | |---|---| | SYN erhält keine Antwort | Netzwerk, Firewall, Backlog oder Überlastung | | SYN erhält RST | kein Listener oder aktive Ablehnung | | TCP-Handshake erfolgreich, Anwendung wartet | Worker-, Pool- oder Backendproblem | | bestehende Clients funktionieren, neue nicht | Backlog, Verbindungslimit oder Ressourcenerschöpfung | | nur ausgehende Serveraufrufe scheitern | lokale Ports, NAT, Pool oder Zielproblem | --- **Baseline erfassen** Eine Port- und Verbindungsdiagnose benötigt Vergleichswerte. Sinnvolle Baseline: ```text dynamischer Portbereich TCP-Verbindungen gesamt UDP-Sockets gesamt ESTABLISHED TIME_WAIT CLOSE_WAIT SYN_SENT LISTEN Verbindungen je Prozess Verbindungen je Ziel neue Verbindungen pro Sekunde Dateideskriptoren je Prozess Conntrack-Auslastung NAT-Sitzungen SNAT-Portnutzung Fehlerzähler CPU und Speicher ``` Messpunkte: - Normalbetrieb; - Lastspitze; - unmittelbar vor der Störung; - während der Störung; - nach der Erholung; - nach einer kontrollierten Maßnahme. --- **Hypothese und Gegenbeweis formulieren** Beispiel: ```text Hypothese: Der Anwendungsdienst erstellt für jeden API-Aufruf eine neue HTTPS-Verbindung zum Ziel 203.0.113.80:443. Die Verbindungen verbleiben anschließend in TIME_WAIT, bis der dynamische TCP-Portbereich erschöpft ist. Erwarteter Befund: Während der Störung schlagen neue ausgehende Verbindungen fehl. Windows protokolliert Ereignis 4227 oder 4231. Die Anzahl der TIME_WAIT-Verbindungen zum Ziel 203.0.113.80:443 ist sehr hoch und gehört überwiegend zum gleichen Prozess. Gegenbeweis: Der dynamische Portbereich besitzt während der Störung ausreichend freie Kapazität, es existieren keine passenden TCP/IP-Ereignisse, und der Verbindungsfehler tritt bereits vor der lokalen Portzuweisung oder ausschließlich am Zielsystem auf. Testmethode: Portbereich, Get-NetTCPConnection, Prozesszuordnung, Systemereignisse und eine kontrollierte Testverbindung zeitlich korrelieren. Risiko: Nur lesende Diagnose. Erfolgskriterium: Portbelegung, verursachender Prozess, Zielkonzentration und Verbindungsfehler sind für denselben Zeitpunkt nachgewiesen. ``` --- **Kontrollierte Maßnahmen** | Maßnahme | Voraussetzung | Risiko | Rückweg | |---|---|---|---| | Connection Pooling aktivieren | hohe Rate kurzlebiger Verbindungen bestätigt | fehlerhafte Altverbindungen können wiederverwendet werden | vorherige Clientkonfiguration | | HTTP-Verbindungen wiederverwenden | neue Verbindung pro Anfrage nachgewiesen | DNS- und Lebensdauerverhalten beachten | vorheriges Clientverhalten | | Poolgröße begrenzen | unkontrolliert großer Pool bestätigt | Wartezeiten bei Last | vorherige Poolgröße | | Retries begrenzen | Retry-Sturm nachgewiesen | einzelne Anfrage schlägt früher fehl | vorherige Retrykonfiguration | | Backoff und Jitter ergänzen | gleichzeitige Wiederholungen vieler Instanzen | längere Wiederherstellungszeit | alte Retryrichtlinie | | Anwendung korrigieren | nicht geschlossene Sockets bestätigt | Deploymentrisiko | vorherige Anwendungsversion | | Portbereich erweitern | tatsächliche lokale Porterschöpfung bestätigt | Überschneidungen und höhere Folgelast | vorherigen Bereich wiederherstellen | | zusätzliche Quell-IP verwenden | Kapazitätsbedarf und Architektur bestätigt | Routing, Firewall und Freigaben ändern sich | alte IP-Zuordnung | | zusätzliche NAT-IP verwenden | SNAT-Erschöpfung bestätigt | Kosten und Ziel-Allowlisting | zusätzliche IP entfernen | | NAT-Gateway skalieren | Plattformmetrik bestätigt Engpass | Kosten und Architekturänderung | vorherige Ressourcengröße | | Timeouts anpassen | ungeeigneter Timeout nachgewiesen | veraltete Zustände oder höhere Last | alten Timeoutwert wiederherstellen | | Dateideskriptorgrenze erhöhen | FD-Limit nachgewiesen und Speicher ausreichend | höherer Ressourcenverbrauch | alten Grenzwert wiederherstellen | | Conntrack-Kapazität erhöhen | Tabellenlimit nachgewiesen | höherer Speicherverbrauch | alten Wert wiederherstellen | | Serverpool skalieren | Zielkapazität nachgewiesen | zusätzliche Verbindungen und Kosten | Skalierung zurücknehmen | Die Ursachenbehebung in der Anwendung ist einer dauerhaften rein infrastrukturellen Vergrößerung vorzuziehen, wenn die Anwendung unnötig viele Verbindungen erzeugt. --- **Vollständiger Diagnoseablauf** 1. Exakte Fehlermeldung erfassen. 2. Datum, Uhrzeit und Zeitzone dokumentieren. 3. Betroffene Anwendung bestimmen. 4. Ausgehende und eingehende Verbindungen unterscheiden. 5. Quell- und Zielsystem bestimmen. 6. Quelladresse und Zieladresse erfassen. 7. Quellport und Zielport erfassen. 8. TCP, UDP und QUIC unterscheiden. 9. IPv4 und IPv6 unterscheiden. 10. Umfang der Störung bestimmen. 11. Prüfen, ob bestehende Verbindungen weiter funktionieren. 12. Prüfen, ob nur neue Verbindungen scheitern. 13. Dynamischen Portbereich auslesen. 14. Reservierte und ausdrücklich gebundene Ports berücksichtigen. 15. Anzahl aktueller TCP-Verbindungen erfassen. 16. UDP-Sockets erfassen. 17. TCP-Zustände gruppieren. 18. `TIME_WAIT` auswerten. 19. `CLOSE_WAIT` auswerten. 20. `SYN_SENT` auswerten. 21. Verbindungen nach Prozess gruppieren. 22. Verbindungen nach Ziel gruppieren. 23. Verbindungsrate messen. 24. Retryrate bestimmen. 25. Connection-Pool-Konfiguration prüfen. 26. Dateideskriptoren und Handles prüfen. 27. Listener- und Backloggrenzen prüfen. 28. Anwendungs- und Workerlimits prüfen. 29. Conntrack-Auslastung prüfen. 30. Firewall- und NAT-Sitzungsgrenzen prüfen. 31. Vor-NAT- und Nach-NAT-Ports dokumentieren. 32. SNAT-Portnutzung prüfen. 33. Cloudmetriken und Port Allocation Errors prüfen. 34. Container-, Node- und Podkontext berücksichtigen. 35. Proxy- und Sidecar-Verbindungen getrennt prüfen. 36. Anwendungsprotokolle auswerten. 37. Betriebssystemereignisse auswerten. 38. kontrollierte Testverbindung durchführen. 39. bei Bedarf Paketaufzeichnung durchführen. 40. Hypothese und Gegenbeweis formulieren. 41. genau eine kontrollierte Maßnahme vorbereiten. 42. Risiko, Rückweg und Erfolgskriterium dokumentieren. 43. Maßnahme freigeben und umsetzen. 44. neue Verbindungen unter gleicher Last testen. 45. Portbelegung und Zustände erneut messen. 46. SNAT-, Conntrack- und Fehlerzähler erneut prüfen. 47. ursprüngliche Anwendung verifizieren. 48. Nebenwirkungen auf andere Dienste prüfen. 49. temporäre Diagnosemaßnahmen zurücknehmen. 50. Ursache, Maßnahme und Prävention dokumentieren. --- **Befundmatrix** | Befund | Mögliche Einordnung | Nächster Nachweis | |---|---|---| | bestehende Verbindungen funktionieren, neue nicht | Port-, NAT-, Conntrack- oder Backloggrenze | jeweilige Auslastungszähler prüfen | | viele `TIME_WAIT` | hohe Rate kurzlebiger TCP-Verbindungen | Prozess, Ziel und Verbindungsrate | | viele `CLOSE_WAIT` | Anwendung schließt Sockets nicht | Prozess und Anwendungscode prüfen | | viele `SYN_SENT` | Ziel antwortet nicht oder Rückweg fehlt | Paketaufzeichnung und Route | | viele `ESTABLISHED` | Pool oder Langzeitverbindungen | Aktivität, Poolgrenze und Alter | | Windows-Ereignis 4227 | lokaler Endpunkt kann nicht sicher wiederverwendet werden | Portbestand und Prozesszuordnung | | Windows-Ereignis 4231 | Zuweisung eines ephemeren Ports fehlgeschlagen | dynamischen Bereich und Belegung prüfen | | `Cannot assign requested address` | kein verwendbarer lokaler Endpunkt oder falsche Bindung | Ports, lokale IP und Anwendung | | `Too many open files` | Dateideskriptorgrenze | Prozesslimits und offene FDs | | lokale Ports frei, Cloudfehler bleibt | SNAT- oder Plattformgrenze | Cloudmetrik und NAT-Gateway | | nur ein Ziel betroffen | Verbindungen pro Zielkombination erschöpft | Ziel-IP, Port und Protokoll gruppieren | | andere Ziele funktionieren | zielbezogene NAT- oder Gegenstellenbegrenzung | Zielkonzentration und Plattformlimit | | Neustart hilft nur vorübergehend | Zustände werden geleert, Ursache bleibt | Wachstum über die Zeit erfassen | | zusätzliche NAT-IP hilft | SNAT-Kapazität wahrscheinlich betroffen | Port Allocation Error vor und nach Änderung | | mehr Pods verschlechtern Fehler | Gesamtpool und Verbindungsrate steigen | Poolgröße × Podanzahl berechnen | | nur Lastspitzen betroffen | Portzuweisung oder Rate überschritten | Verbindungen pro Sekunde messen | | TCP funktioniert, UDP nicht | getrennte UDP-Port- oder NAT-Grenze | UDP-Sockets und NAT-Timeout | | HTTP/1.1 problematisch, HTTP/2 besser | Multiplexing reduziert Verbindungen | Verbindungsrate vergleichen | | Firewall-Sessions voll | Connection Tracking oder Sessionlimit | Firewallstatistik und Drops | | Serverhandshake gelingt, Anfrage wartet | Worker-, Pool- oder Backendgrenze | Anwendungsmetriken | | Listener-Queue wächst | Anwendung akzeptiert zu langsam | CPU, Worker und Backlog | | Pool erschöpft, Ports frei | Anwendungslimit statt Portlimit | Poolwartezeit und Poolbelegung | | viele Retries | Fehler verstärkt Verbindungslast | Backoff- und Retrykonfiguration | | Portbereich angepasst, Fehler wandert zur Firewall | nachgelagerte Grenze erreicht | Firewall- und Conntrack-Kapazität | --- **Typische Diagnosefehler** - IANA-Portbereich ungeprüft als lokalen Betriebssystembereich annehmen. - Quellport und Zielport verwechseln. - RPC-Zielports und Clientquellports gleichsetzen. - TCP und UDP nicht getrennt prüfen. - IPv4 und IPv6 nicht getrennt prüfen. - Lokalen Port und SNAT-Port verwechseln. - Portanzahl als garantierte Gesamtverbindungszahl interpretieren. - Zieladresse und Zielport bei der Kapazität ignorieren. - Nur Gesamtverbindungen und nicht Verbindungen je Ziel prüfen. - `TIME_WAIT` allein als Beweis der Porterschöpfung verwenden. - `CLOSE_WAIT` als normalen Portablauf behandeln. - `SYN_SENT` ohne Netzwerkprüfung als Portproblem bewerten. - Prozesszuordnung nicht durchführen. - Verbindungsrate nicht messen. - Retries und Backoff nicht prüfen. - Connection Pooling nicht berücksichtigen. - Poolgröße nur pro Instanz und nicht über alle Instanzen berechnen. - Container, Pods oder Sidecars übersehen. - Proxy- und Zielverbindung als eine einzige Verbindung betrachten. - Dateideskriptorgrenze mit Portgrenze verwechseln. - Conntrack-Tabelle nicht prüfen. - Firewall-Sessionlimit ignorieren. - NAT-Gateway-Metriken nicht prüfen. - Cloudlimits aus einer anderen Ressource übertragen. - Portbereich als erste Maßnahme erweitern. - `TIME_WAIT`-Dauer vorsorglich verkürzen. - Server neu starten, bevor Beweisdaten gesichert sind. - Alle Sitzungen löschen. - Anwendungslimit durch Infrastrukturvergrößerung verdecken. - Nur eine einzelne Testverbindung durchführen. - Last- und Langzeittest nach der Maßnahme auslassen. - Temporäre Diagnoseaufzeichnungen aktiv lassen. --- **Verifikation** Nach einer Maßnahme müssen mindestens folgende Punkte geprüft werden: - tatsächlicher dynamischer Portbereich ist dokumentiert; - reservierte Ports überschneiden sich nicht unerwartet; - neue Verbindungen werden zuverlässig aufgebaut; - bestehende Verbindungen bleiben stabil; - `TIME_WAIT`-Bestand entspricht der erwarteten Verbindungsrate; - `CLOSE_WAIT` wächst nicht dauerhaft; - `SYN_SENT` wächst nicht dauerhaft; - verursachender Prozess ist eindeutig bestimmt; - Connection Pool arbeitet innerhalb seiner Grenze; - Verbindungen werden wiederverwendet; - Retryrate entspricht der Vorgabe; - Dateideskriptorverbrauch bleibt unterhalb des Limits; - Listener- und Accept-Backlogs sind unauffällig; - Conntrack-Tabelle besitzt ausreichende Reserve; - Firewall-Sitzungslimit wird nicht erreicht; - NAT-Sitzungen besitzen ausreichende Reserve; - SNAT-Portfehler treten nicht mehr auf; - Cloudmetriken zeigen keine fehlgeschlagenen Portzuweisungen; - TCP und UDP funktionieren, sofern erforderlich; - IPv4 und IPv6 funktionieren, sofern erforderlich; - alle Anwendungsinstanzen funktionieren; - mehrere Ziele funktionieren; - konzentrierte Verbindungen zum Hauptziel funktionieren; - Lastspitze wird erfolgreich verarbeitet; - ursprüngliche Anwendung funktioniert; - keine neue Sicherheitsumgehung entstand; - keine unnötige allgemeine Portfreigabe besteht; - temporäre Diagnosen wurden zurückgenommen; - Ursache, Maßnahme und Prävention wurden dokumentiert. Eine erfolgreiche Einzelverbindung direkt nach einem Neustart ist keine ausreichende Verifikation. Porterschöpfung muss unter repräsentativer Last und über einen ausreichend langen Zeitraum ausgeschlossen werden. --- **Dokumentationsvorlage** ```text Störung: Datum und Uhrzeit: Betroffene Anwendung: Betroffenes System: Datenfluss: Ziel-IP:Port/Protokoll> Adressfamilie: Dynamischer Portbereich: Reservierte Ports: Verbindungen gesamt: ESTABLISHED: TIME_WAIT: CLOSE_WAIT: SYN_SENT: UDP-Sockets: Hauptverursachender Prozess: Häufigstes Ziel: Verbindungsrate: Connection Pool: Retryverhalten: Dateideskriptoren: Conntrack: Firewall-Sitzungen: NAT vor Übersetzung: NAT nach Übersetzung: <öffentliche IP und SNAT-Port> SNAT-Portnutzung: Plattformlimit: Hypothese: Erwarteter Nachweis: Gegenbeweis: Nachgewiesene Ursache: Durchgeführte Maßnahme: Risiko: Rückweg: Verifikation: Prävention: ``` --- **Checkliste** - [ ] exakte Fehlermeldung dokumentiert - [ ] Datum, Uhrzeit und Zeitzone erfasst - [ ] betroffene Anwendung bestimmt - [ ] Quelladresse erfasst - [ ] Quellport erfasst - [ ] Zieladresse erfasst - [ ] Zielport erfasst - [ ] TCP und UDP unterschieden - [ ] IPv4 und IPv6 unterschieden - [ ] ausgehende und eingehende Verbindung unterschieden - [ ] Fehlerumfang bestimmt - [ ] bestehende Verbindungen getestet - [ ] neue Verbindungen getestet - [ ] dynamischen TCP-Portbereich ausgelesen - [ ] dynamischen UDP-Portbereich ausgelesen - [ ] reservierte Ports geprüft - [ ] theoretische Portanzahl berechnet - [ ] tatsächliche Portbelegung erfasst - [ ] TCP-Verbindungen gezählt - [ ] UDP-Sockets gezählt - [ ] `ESTABLISHED` gezählt - [ ] `TIME_WAIT` gezählt - [ ] `CLOSE_WAIT` gezählt - [ ] `SYN_SENT` gezählt - [ ] FIN-Zustände berücksichtigt - [ ] Prozesszuordnung durchgeführt - [ ] häufigste Prozesse bestimmt - [ ] häufigste Ziele bestimmt - [ ] Verbindungen je Ziel bestimmt - [ ] Verbindungsrate gemessen - [ ] Retryrate gemessen - [ ] Connection Pool geprüft - [ ] Poolgröße über alle Instanzen berechnet - [ ] HTTP-Verbindungswiederverwendung geprüft - [ ] Dateideskriptorgrenze geprüft - [ ] offene Dateideskriptoren gezählt - [ ] Prozesshandles berücksichtigt - [ ] Listener geprüft - [ ] SYN-Backlog geprüft - [ ] Accept-Backlog geprüft - [ ] Worker- und Threadgrenzen geprüft - [ ] Anwendungslimit geprüft - [ ] Datenbankverbindungslimit geprüft - [ ] Conntrack-Auslastung geprüft - [ ] Firewall-Sitzungsgrenze geprüft - [ ] NAT-Sitzungsgrenze geprüft - [ ] Vor-NAT-Port dokumentiert - [ ] Nach-NAT-Port dokumentiert - [ ] SNAT-Portpool geprüft - [ ] Cloudmetriken geprüft - [ ] Port Allocation Errors geprüft - [ ] Cloudressource und Ressourcentyp bestimmt - [ ] Container- oder Podkontext berücksichtigt - [ ] Proxy- und Sidecar-Verbindungen berücksichtigt - [ ] Betriebssystemereignisse geprüft - [ ] Anwendungsprotokolle geprüft - [ ] Baseline verglichen - [ ] Hypothese formuliert - [ ] Gegenbeweis definiert - [ ] Risiko dokumentiert - [ ] Rückweg dokumentiert - [ ] nur eine kontrollierte Maßnahme durchgeführt - [ ] Einzeltest durchgeführt - [ ] Lasttest durchgeführt - [ ] Langzeitverhalten geprüft - [ ] ursprüngliche Anwendung verifiziert - [ ] Nebenwirkungen geprüft - [ ] temporäre Diagnosen zurückgenommen - [ ] Ursache und Prävention dokumentiert --- **Schnellreferenz** | Aufgabe | Befehl | |---|---| | Windows IPv4-TCP-Portbereich | `netsh int ipv4 show dynamicport tcp` | | Windows IPv4-UDP-Portbereich | `netsh int ipv4 show dynamicport udp` | | Windows IPv6-TCP-Portbereich | `netsh int ipv6 show dynamicport tcp` | | Windows IPv6-UDP-Portbereich | `netsh int ipv6 show dynamicport udp` | | Windows TCP-Verbindungen | `Get-NetTCPConnection` | | Windows etablierte Verbindungen | `Get-NetTCPConnection -State Established` | | Windows `TIME_WAIT` | `Get-NetTCPConnection -State TimeWait` | | Windows `CLOSE_WAIT` | `Get-NetTCPConnection -State CloseWait` | | Windows `SYN_SENT` | `Get-NetTCPConnection -State SynSent` | | Windows Netstat | `netstat -ano` | | Windows gebundene Ports | `netstat -anoq` | | Windows relevante Ereignisse | `Get-WinEvent -FilterHashtable @{LogName="System"; Id=4227,4231}` | | Linux-Portbereich | `sysctl net.ipv4.ip_local_port_range` | | Linux-reservierte Ports | `sysctl net.ipv4.ip_local_reserved_ports` | | Linux-Socketübersicht | `ss -s` | | Linux-TCP-Sockets | `ss -tan` | | Linux-TCP mit Prozessen | `sudo ss -tanp` | | Linux `TIME_WAIT` | `ss -tan state time-wait` | | Linux `CLOSE_WAIT` | `ss -tan state close-wait` | | Linux `SYN_SENT` | `ss -tan state syn-sent` | | Linux-Listener | `ss -lntp` | | Linux-Socketstatistik | `cat /proc/net/sockstat` | | Linux-FD-Limit der Shell | `ulimit -n` | | Linux-Prozesslimits | `cat /proc//limits` | | Linux-systemweites FD-Limit | `sysctl fs.file-max` | | Linux-Listen-Backlog | `sysctl net.core.somaxconn` | | Linux-SYN-Backlog | `sysctl net.ipv4.tcp_max_syn_backlog` | | Linux-Conntrack-Anzahl | `sysctl net.netfilter.nf_conntrack_count` | | Linux-Conntrack-Maximum | `sysctl net.netfilter.nf_conntrack_max` | | macOS-Portparameter | `sysctl -a \| awk '/net\.inet\.ip\.portrange/'` | | macOS-TCP-Verbindungen | `netstat -anv -p tcp` | | macOS-TCP-Prozesse | `sudo lsof -nP -iTCP` | | macOS-Netzwerkübersicht | `nettop -m tcp` | Verändernde Befehle und Maßnahmen, die nicht als erste Diagnose verwendet werden dürfen: ```text netsh int ipv4 set dynamicport ... netsh int ipv6 set dynamicport ... sysctl -w net.ipv4.ip_local_port_range=... sysctl -w net.ipv4.tcp_fin_timeout=... TcpTimedWaitDelay ungeprüft verändern MaxUserPort ungeprüft verändern ulimit pauschal maximal erhöhen LimitNOFILE ungeprüft erhöhen fs.file-max ungeprüft erhöhen net.core.somaxconn ungeprüft erhöhen net.ipv4.tcp_max_syn_backlog ungeprüft erhöhen nf_conntrack_max ungeprüft erhöhen conntrack -F Firewall-Sitzungen vollständig löschen NAT-Sitzungen vollständig löschen Server vorsorglich neu starten NAT-Gateway vorsorglich neu erstellen öffentliche IP-Adressen ohne Kapazitätsplanung ergänzen Connection Pool unbegrenzt vergrößern Timeouts pauschal verkürzen Sicherheitsbegrenzungen deaktivieren ``` --- **Quellen** **Standards und Portregistrierung** - [IANA – Service Name and Transport Protocol Port Number Registry](https://www.iana.org/assignments/service-names-port-numbers/) - [RFC 6335 – Internet Assigned Numbers Authority Procedures for Service Names and Transport Protocol Port Numbers](https://datatracker.ietf.org/doc/html/rfc6335) - [RFC 7605 – Recommendations on Using Assigned Transport Port Numbers](https://datatracker.ietf.org/doc/html/rfc7605) - [RFC 6056 – Recommendations for Transport-Protocol Port Randomization](https://datatracker.ietf.org/doc/html/rfc6056) - [RFC 9293 – Transmission Control Protocol](https://datatracker.ietf.org/doc/html/rfc9293) - [RFC 768 – User Datagram Protocol](https://datatracker.ietf.org/doc/html/rfc768) - [RFC 4787 – NAT Behavioral Requirements for UDP](https://datatracker.ietf.org/doc/html/rfc4787) - [RFC 7857 – Updates to NAT Behavioral Requirements](https://datatracker.ietf.org/doc/html/rfc7857) **Microsoft Windows** - [Microsoft Learn – TCP/IP Port Exhaustion Troubleshooting](https://learn.microsoft.com/en-us/troubleshoot/windows-client/networking/tcp-ip-port-exhaustion-troubleshooting) - [Microsoft Learn – Get-NetTCPConnection](https://learn.microsoft.com/en-us/powershell/module/nettcpip/get-nettcpconnection) - [Microsoft Learn – Configure RPC Dynamic Port Allocation with Firewalls](https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/configure-rpc-dynamic-port-allocation-with-firewalls) **Linux Kernel und Manpages** - [Linux Kernel Documentation – IP Sysctl](https://docs.kernel.org/networking/ip-sysctl.html) - [Linux Kernel Documentation – Netfilter Conntrack Sysfs Variables](https://docs.kernel.org/networking/nf_conntrack-sysctl.html) - [Linux man-pages – `IP_LOCAL_PORT_RANGE`](https://man7.org/linux/man-pages/man2/IP_LOCAL_PORT_RANGE.2const.html) - [Linux man-pages – `ip(7)`](https://man7.org/linux/man-pages/man7/ip.7.html) - [Linux man-pages – `tcp(7)`](https://man7.org/linux/man-pages/man7/tcp.7.html) - [Linux man-pages – `socket(7)`](https://man7.org/linux/man-pages/man7/socket.7.html) - [iproute2 – `ss(8)`](https://man7.org/linux/man-pages/man8/ss.8.html) - [Netfilter – Conntrack Tools User Manual](https://conntrack-tools.netfilter.org/manual.html) **Amazon Web Services** - [AWS – NAT Gateway Basics](https://docs.aws.amazon.com/vpc/latest/userguide/nat-gateway-basics.html) - [AWS – Work with NAT Gateways](https://docs.aws.amazon.com/vpc/latest/userguide/nat-gateway-working-with.html) - [AWS – Troubleshoot NAT Gateways](https://docs.aws.amazon.com/vpc/latest/userguide/nat-gateway-troubleshooting.html) **Microsoft Azure** - [Microsoft Learn – Source Network Address Translation with Azure NAT Gateway](https://learn.microsoft.com/en-us/azure/nat-gateway/nat-gateway-snat) - [Microsoft Learn – Azure NAT Gateway Resource](https://learn.microsoft.com/en-us/azure/nat-gateway/nat-gateway-resource) - [Microsoft Learn – Troubleshoot Azure NAT Gateway Connectivity](https://learn.microsoft.com/en-us/troubleshoot/azure/nat-gateway/troubleshoot-nat-connectivity) - [Microsoft Learn – Azure Load Balancer Outbound Connections](https://learn.microsoft.com/en-us/azure/load-balancer/load-balancer-outbound-connections) - [Microsoft Learn – Troubleshoot Azure Load Balancer Outbound Connectivity](https://learn.microsoft.com/en-us/troubleshoot/azure/load-balancer/troubleshoot-outbound-connection) **Google Cloud** - [Google Cloud – Cloud NAT IP Addresses and Ports](https://cloud.google.com/nat/docs/ports-and-addresses) - [Google Cloud – Troubleshoot Cloud NAT](https://cloud.google.com/nat/docs/troubleshooting) Für diese Seite wurden keine Community-Beiträge oder Hersteller-Social-Media-Aussagen als fachlicher Nachweis verwendet. # 9.8 NAT, Portweiterleitung und Hairpin NAT im Datenpfad Network Address Translation verändert IP-Adressen und gegebenenfalls Transportports innerhalb eines Datenflusses. Eine Verbindung kann deshalb an verschiedenen Stellen des Netzwerkpfads mit unterschiedlichen Adressen und Ports sichtbar sein. Beispiel einer eingehenden Portweiterleitung: ```text Externer Client: 198.51.100.40:53124 Öffentliche Adresse: 203.0.113.10:8443 Interner Server: 192.0.2.25:443 ``` Vor der Zielübersetzung: ```text 198.51.100.40:53124 -> 203.0.113.10:8443/TCP ``` Nach der Zielübersetzung: ```text 198.51.100.40:53124 -> 192.0.2.25:443/TCP ``` Eine scheinbar richtige Firewallregel kann wirkungslos bleiben, wenn sie die falsche Adressphase, das falsche Protokoll, die falsche Schnittstelle oder den falschen Übersetzungsport verwendet. --- **Ziele** Nach der Bearbeitung dieser Seite soll nachvollziehbar geprüft werden können: - welche Adressen und Ports vor und nach NAT verwendet werden; - ob Source NAT, Destination NAT oder Port Address Translation greift; - welche NAT-Regel tatsächlich angewendet wird; - ob eine Portweiterleitung auf das richtige interne Ziel zeigt; - ob Firewallregel, Routing und NAT zusammenpassen; - ob der Rückverkehr dieselbe NAT-Komponente durchläuft; - ob ein vorgeschaltetes NAT oder Carrier-Grade NAT eingehende Verbindungen verhindert; - ob Hairpin NAT beziehungsweise NAT Loopback unterstützt wird; - warum eine Verbindung intern, extern oder nur über die öffentliche Adresse fehlschlägt; - wie Container-, Cloud- und Load-Balancer-NAT berücksichtigt werden; - wie eine NAT-Änderung kontrolliert verifiziert wird. --- **Sicherheits- und Änderungsgrundsätze** Eine Portweiterleitung veröffentlicht einen internen Dienst über einen zusätzlichen Netzwerkpfad. Vor der Einrichtung sind mindestens zu prüfen: - geschäftlicher Zweck; - verantwortlicher Diensteigentümer; - erforderliches Protokoll; - erforderlicher Port; - erlaubte Quelladressen; - Authentifizierung; - Verschlüsselung; - Patchstand; - Protokollierung; - Rate Limiting; - Monitoring; - Rückweg; - Rücknahmezeitpunkt; - Risiko; - Freigabe. Besonders schützenswerte Verwaltungs- und Dateidienste sollten nicht ohne zusätzliche Schutzarchitektur direkt aus dem Internet veröffentlicht werden. Dazu gehören beispielsweise: - RDP; - SMB; - SSH mit schwacher Authentifizierung; - Datenbankports; - Hypervisorverwaltung; - NAS-Verwaltung; - Router- oder Firewallverwaltung; - unverschlüsselte Weboberflächen; - interne Verzeichnisdienste. Geeignetere Zugriffsmöglichkeiten können sein: - VPN; - Zero-Trust-Zugriff; - Bastion Host; - Jump Host; - Reverse Proxy mit starker Authentifizierung; - Application Gateway; - Web Application Firewall; - privater Cloudendpunkt. Nicht als erste Diagnosemaßnahme geeignet sind: - alle Ports weiterleiten; - DMZ-Host-Funktion eines Routers aktivieren; - Exposed Host einrichten; - Firewall vollständig deaktivieren; - allgemeine `any`-zu-`any`-Regel erstellen; - NAT-Tabelle vollständig leeren; - alle Verbindungstabellen löschen; - UPnP pauschal aktivieren; - Server direkt mit öffentlicher Adresse verbinden; - Managementport testweise veröffentlichen; - Router oder Firewall vorsorglich neu starten; - mehrere NAT-Regeln gleichzeitig verändern. --- **NAT ist keine Firewall** NAT verändert Adressen oder Ports. Eine Firewall entscheidet anhand einer Sicherheitsrichtlinie, ob Datenverkehr erlaubt oder verworfen wird. Beide Funktionen können sich im selben Gerät befinden, bleiben aber logisch getrennt. Beispiel: ```text NAT-Regel: 203.0.113.10:8443 -> 192.0.2.25:443 Firewallregel: TCP von 198.51.100.0/24 zu 192.0.2.25:443 erlauben ``` Mögliche Kombinationen: | NAT | Firewall | Ergebnis | |---|---|---| | vorhanden | erlaubt | Verbindung kann weiterverarbeitet werden | | vorhanden | blockiert | Übersetzung kann passen, Verkehr wird trotzdem verworfen | | fehlt | erlaubt | Freigabe besitzt möglicherweise kein erreichbares Ziel | | falsch | erlaubt | Verkehr erreicht falsches System oder falschen Port | | vorhanden | falsche Richtung | Verbindungsaufbau bleibt blockiert | | automatisch erstellt | unbekannt | Sicherheitswirkung muss ausdrücklich geprüft werden | Einige Router erzeugen zusammen mit einer Portweiterleitung automatisch eine Firewallfreigabe. Andere Produkte verlangen eine getrennte Regel. Dieses Verhalten ist hersteller- und versionsabhängig. --- **NAT-Begriffe** | Begriff | Bedeutung | |---|---| | NAT | Oberbegriff für die Übersetzung von Netzwerkadressen | | SNAT | Änderung der Quelladresse | | DNAT | Änderung der Zieladresse | | PAT | Übersetzung von Transportports, häufig zusammen mit Adressübersetzung | | NAPT | Übersetzung von Netzwerkadresse und Transportport | | Masquerading | SNAT auf die aktuelle Adresse einer Ausgangsschnittstelle | | statisches NAT | fest definierte Zuordnung | | dynamisches NAT | Zuordnung aus einem Adresspool | | Portweiterleitung | statische eingehende Zieladress- und/oder Portübersetzung | | 1:1-NAT | feste Zuordnung einer internen zu einer externen Adresse | | Twice NAT | Quelle und Ziel werden abhängig voneinander in einer Regel verarbeitet | | NAT Exemption | bestimmter Datenverkehr wird ausdrücklich nicht übersetzt | | Hairpin NAT | interner Client erreicht internes Ziel über dessen externe NAT-Adresse | | NAT Loopback | gebräuchliche Bezeichnung für Hairpin NAT | | NAT Reflection | herstellerabhängige Bezeichnung für Hairpin-Verarbeitung | | U-Turn NAT | weitere gebräuchliche Bezeichnung für Hairpin NAT | | CGNAT | NAT im Netz des Internetzugangsanbieters | | NAT64 | Übersetzung zwischen IPv6 und IPv4 | | NPTv6 | zustandslose Übersetzung von IPv6-Präfixen | Die Begriffe werden von Herstellern nicht immer einheitlich verwendet. --- **Source NAT** Source NAT verändert die Quelladresse eines ausgehenden Datenflusses. Vor SNAT: ```text 192.0.2.100:53124 -> 198.51.100.25:443 ``` Nach SNAT: ```text 203.0.113.10:61001 -> 198.51.100.25:443 ``` Das Zielsystem sieht als Quelle: ```text 203.0.113.10:61001 ``` und normalerweise nicht: ```text 192.0.2.100:53124 ``` Typische Anwendungsfälle: - private IPv4-Clients greifen auf das Internet zu; - mehrere interne Systeme teilen sich eine öffentliche Adresse; - Rückverkehr soll über eine bestimmte Firewall geführt werden; - überlappende Netze werden verbunden; - ein Ziel erlaubt nur definierte Quelladressen; - Hairpin-Verkehr wird symmetrisch über das NAT-Gerät geführt. Auswirkungen: - ursprüngliche Quelladresse ist am Ziel nicht direkt sichtbar; - Protokolle zeigen gegebenenfalls nur die NAT-Adresse; - Portkapazität der NAT-Adresse wird benötigt; - Rückverkehr ist an die NAT-Sitzung gebunden; - Quell-IP-basierte Sicherheitsentscheidungen verändern sich. --- **Destination NAT** Destination NAT verändert die Zieladresse eines eingehenden Datenflusses. Vor DNAT: ```text 198.51.100.40:53124 -> 203.0.113.10:8443 ``` Nach DNAT: ```text 198.51.100.40:53124 -> 192.0.2.25:443 ``` Typische Anwendungsfälle: - Portweiterleitung; - Veröffentlichung eines internen Servers; - Weiterleitung an Reverse Proxy; - Load Balancing; - transparente Proxyfunktion; - Umleitung auf einen lokalen Dienst. Zu prüfen sind: - externe Zieladresse; - externer Zielport; - internes Ziel; - interner Zielport; - Protokoll; - Eingangsschnittstelle; - Quellbereich; - Firewallregel; - Rückroute; - Zustandstabelle. --- **Port Address Translation** PAT ermöglicht die Unterscheidung vieler Datenflüsse über dieselbe externe IP-Adresse. Beispiel: ```text 192.0.2.100:53124 -> 203.0.113.10:61001 192.0.2.101:53124 -> 203.0.113.10:61002 ``` Beide Clients können dasselbe Ziel verwenden: ```text 198.51.100.25:443 ``` Das NAT-Gerät hält dafür getrennte Zuordnungen: ```text 203.0.113.10:61001 -> 192.0.2.100:53124 203.0.113.10:61002 -> 192.0.2.101:53124 ``` PAT benötigt: - freie Übersetzungsports; - eine Sitzungstabelle; - passende Timeouts; - einen symmetrischen Rückweg; - ausreichende NAT-Kapazität. --- **1:1-NAT** Bei 1:1-NAT wird eine interne Adresse fest einer externen Adresse zugeordnet. Beispiel: ```text Öffentlich: 203.0.113.25 Intern: 192.0.2.25 ``` Mögliche Übersetzung: ```text 203.0.113.25 <-> 192.0.2.25 ``` 1:1-NAT bedeutet nicht automatisch, dass alle Ports erlaubt sind. Die Firewallrichtlinie muss weiterhin festlegen: - zulässige Quellen; - zulässige Protokolle; - zulässige Ports; - Richtung; - Protokollierung; - Sicherheitsprofile. --- **Portweiterleitung** Eine Portweiterleitung ordnet eine externe Kombination einer internen Kombination zu. Beispiel: ```text Externe Adresse: 203.0.113.10 Externer Port: 8443 Protokoll: TCP Internes Ziel: 192.0.2.25 Interner Port: 443 ``` Vereinfachte Regel: ```text TCP 203.0.113.10:8443 -> TCP 192.0.2.25:443 ``` Eine vollständige Portweiterleitung benötigt mindestens: - richtige öffentliche Adresse; - richtige Eingangsschnittstelle; - richtiges Protokoll; - richtigen externen Port; - richtige interne Zieladresse; - richtigen internen Port; - aktiven Serverdienst; - lokale Serverfirewall; - zentrale Firewallfreigabe; - korrekte Rückroute; - funktionierenden NAT-Zustand. --- **Externen und internen Port unterscheiden** Die Portnummern müssen nicht identisch sein. Beispiel: ```text Extern: TCP 8443 Intern: TCP 443 ``` Mögliche Diagnosefehler: - extern Port `443` testen, obwohl `8443` veröffentlicht ist; - Firewall für internen Port `8443` öffnen, obwohl Server auf `443` hört; - Server auf `8443` prüfen, obwohl DNAT auf `443` übersetzt; - TCP-Regel anlegen, obwohl Anwendung UDP verwendet; - IPv4-NAT testen, obwohl DNS eine IPv6-Adresse liefert. --- **TCP und UDP getrennt weiterleiten** Eine Portnummer bezeichnet ohne Transportprotokoll keinen vollständigen Dienstendpunkt. Diese beiden Regeln sind verschieden: ```text TCP 203.0.113.10:8443 -> 192.0.2.25:443 ``` ```text UDP 203.0.113.10:8443 -> 192.0.2.25:443 ``` Zu prüfen sind: - TCP; - UDP; - gegebenenfalls beide Protokolle; - ICMP-Verhalten; - QUIC über UDP; - anwendungsspezifische Zusatzports; - dynamisch ausgehandelte Ports. Ein erfolgreicher TCP-Test beweist keine funktionierende UDP-Weiterleitung. --- **Eingangsschnittstelle und Zieladresse** Eine NAT-Regel kann an eine bestimmte Eingangsschnittstelle oder öffentliche Zieladresse gebunden sein. Beispiele: - WAN1; - WAN2; - VPN; - Mobilfunk; - öffentliche Adresse A; - öffentliche Adresse B; - virtuelle IP-Adresse; - Load-Balancer-Adresse. Typischer Fehler: ```text NAT-Regel: gilt nur für WAN1 Tatsächlicher Datenverkehr: trifft über WAN2 ein ``` Die Regel ist vorhanden, verarbeitet diesen Datenfluss aber nicht. --- **Vollständiger eingehender Datenpfad** Ein eingehender Zugriff kann folgende Ebenen durchlaufen: 1. öffentlicher DNS-Eintrag; 2. Internetzugangsanbieter; 3. vorgeschaltetes Provider-NAT; 4. Modem oder Router; 5. Edge-Firewall; 6. öffentliche IP-Adresse; 7. DNAT- oder Portweiterleitungsregel; 8. Sicherheitsregel; 9. interne Route; 10. VLAN- oder Segmentfirewall; 11. Load Balancer; 12. Reverse Proxy; 13. Containerhost; 14. veröffentlichter Hostport; 15. Containerport; 16. lokale Host-Firewall; 17. Serverprozess; 18. Anwendung. Jede Ebene muss mit ihrer vor und nach der Verarbeitung sichtbaren Adresse geprüft werden. --- **Vollständiger Rückweg** Der Rückverkehr einer eingehenden Verbindung muss die zustandsbehaftete NAT-Komponente wieder erreichen. Beispiel: ```text Hinweg: 198.51.100.40 -> 203.0.113.10 -> 192.0.2.25 Rückweg: 192.0.2.25 -> 203.0.113.10 -> 198.51.100.40 ``` Wenn der Server über ein anderes Gateway antwortet: ```text 192.0.2.25 -> anderer Router -> 198.51.100.40 ``` fehlt dort möglicherweise die Rückübersetzung. Mögliche Folgen: - Client erhält eine Antwort mit unerwarteter Quelladresse; - Antwort wird durch eine Firewall verworfen; - TCP-Handshake bleibt unvollständig; - NAT-Sitzung bleibt ohne Rückverkehr; - Server sendet wiederholt `SYN, ACK`; - Client sendet wiederholt `SYN`. --- **NAT-Reihenfolge ist produktspezifisch** Die Verarbeitung kann unter anderem umfassen: - Eingangsschnittstelle bestimmen; - bestehende Sitzung suchen; - DNAT anwenden; - Route bestimmen; - Zielzone bestimmen; - Sicherheitsregel prüfen; - SNAT anwenden; - Ausgangsschnittstelle bestimmen; - Paket weiterleiten. Die genaue Reihenfolge unterscheidet sich zwischen: - Linux Netfilter; - Cisco ASA; - Palo Alto Networks; - Juniper SRX; - Fortinet; - Cloud-Firewalls; - Heimroutern; - Load Balancern; - Containerplattformen. Es darf nicht pauschal angenommen werden, dass eine Firewallregel immer: - die öffentliche Adresse; - die private Adresse; - den externen Port; - den internen Port; - die Vor-NAT-Zone; - die Nach-NAT-Zone verwenden muss. Maßgeblich ist die Dokumentation des eingesetzten Produkts und der Softwareversion. --- **NAT-Regelreihenfolge** NAT-Regeln können priorisiert oder der Reihe nach ausgewertet werden. Mögliche Probleme: - allgemeinere Regel steht vor spezifischer Regel; - bestehende Masquerade-Regel erfasst den Datenfluss; - NAT-Ausnahme überschattet die gewünschte Übersetzung; - doppelte Portweiterleitung verwendet denselben externen Port; - falsche Schnittstelle besitzt höhere Priorität; - Twice-NAT-Regel beendet die weitere Auswertung; - alte Regel ist noch aktiv; - zentrale Policy überschreibt lokale Regel; - IPv6-Regel wird mit IPv4-Regel verwechselt. Zu dokumentieren sind: - Regel-ID; - Regelname; - Reihenfolge; - Quellbereich; - Zielbereich; - Protokoll; - Ports; - Schnittstellen; - Trefferzähler; - letzte Verwendung; - aktive Konfigurationsversion. --- **Statische interne Zieladresse** Das Ziel einer Portweiterleitung muss dauerhaft erreichbar bleiben. Geeignete Möglichkeiten: - statische Serveradresse; - DHCP-Reservierung; - stabile virtuelle IP-Adresse; - Load-Balancer-Adresse; - Serviceadresse. Typischer Fehler: ```text Portweiterleitung: 192.0.2.25 Aktuelle Serveradresse: 192.0.2.37 ``` Die NAT-Regel ist syntaktisch korrekt, zeigt aber auf ein nicht mehr verwendetes Ziel. Zu prüfen sind: - aktuelle IP-Adresse; - DHCP-Lease; - Adressreservierung; - DNS; - ARP- oder Neighbor-Tabelle; - Serverroute; - Mehrfachadressierung; - Cluster- oder Failoveradresse. --- **Öffentliche Erreichbarkeit prüfen** Eine eingehende Portweiterleitung benötigt eine von außen erreichbare Zieladresse. Zu prüfen sind: - WAN-Adresse des eigenen Routers; - öffentliche DNS-Adresse; - von einem autorisierten externen System beobachtete Quelladresse; - vorgeschaltetes Modem; - weiterer Router; - Provider-NAT; - Carrier-Grade NAT; - DS-Lite; - Mobilfunk-NAT; - VPN oder Tunnel; - dynamische öffentliche Adresse; - IPv4 oder IPv6. Eine private Adresse auf der WAN-Schnittstelle ist nicht direkt aus dem öffentlichen Internet erreichbar. --- **Private IPv4-Bereiche** RFC 1918 definiert: ```text 10.0.0.0/8 172.16.0.0/12 192.168.0.0/16 ``` Das bedeutet: ```text 10.0.0.0 bis 10.255.255.255 172.16.0.0 bis 172.31.255.255 192.168.0.0 bis 192.168.255.255 ``` Befindet sich die WAN-Adresse des eigenen Routers in einem dieser Bereiche, existiert mindestens ein weiteres vorgeschaltetes Routing- oder NAT-System. --- **Shared Address Space und CGNAT** RFC 6598 reserviert für Provider-NAT: ```text 100.64.0.0/10 ``` Das umfasst: ```text 100.64.0.0 bis 100.127.255.255 ``` Dieser Bereich ist kein RFC-1918-Privatnetz, wird aber für Shared Address Space und häufig für Carrier-Grade NAT verwendet. Hinweise auf vorgeschaltetes NAT: - WAN-Adresse liegt in einem privaten Bereich; - WAN-Adresse liegt in `100.64.0.0/10`; - Router-WAN-Adresse weicht von der extern beobachteten Adresse ab; - Portweiterleitung funktioniert trotz richtiger lokaler Konfiguration nicht; - Internetzugang funktioniert ausschließlich ausgehend; - Anbieter nennt DS-Lite oder CGNAT; - öffentliche IPv4-Adresse ist nicht Bestandteil des Anschlusses. Eine Abweichung der Adressen ist ein Hinweis und muss unter Berücksichtigung von VPN, Proxy, mehreren Leitungen und Providerarchitektur bewertet werden. --- **Doppeltes NAT** Beispiel: ```text Internet -> Providerrouter 192.168.0.1 -> eigener Router 192.168.0.2 -> Server 192.0.2.25 ``` Für eine eingehende Verbindung können zwei Weiterleitungen erforderlich sein: ```text Providerrouter: 203.0.113.10:8443 -> 192.168.0.2:8443 Eigener Router: 192.168.0.2:8443 -> 192.0.2.25:443 ``` Zusätzlich müssen beide Firewalls und beide Rückwege passen. Besser kann je nach freigegebener Architektur sein: - Bridge- oder Modemmodus; - eigener Router als einziges NAT-Gateway; - statische Route statt zweitem NAT; - öffentliche Adresse direkt am Edge-Gerät; - kontrollierte DMZ-Verbindung zwischen den Geräten. Ein Exposed Host ist keine geeignete Standardlösung, weil dadurch möglicherweise sehr viele Ports weitergeleitet werden. --- **Carrier-Grade NAT und Portweiterleitung** Befindet sich die öffentliche IPv4-Adresse auf einem Provider-NAT, kann der eigene Router keine beliebige eingehende Abbildung auf diesem Providergerät erstellen. Mögliche Lösungen hängen vom Anbieter ab: - öffentliche IPv4-Adresse buchen; - statische öffentliche IPv4-Adresse verwenden; - IPv6 mit geeigneter Firewallfreigabe verwenden; - VPN mit eingehendem Tunnelendpunkt verwenden; - Reverse Tunnel; - Cloud-Reverse-Proxy; - providerseitige Portzuordnung; - Port Control Protocol, sofern tatsächlich unterstützt. Die technische und sicherheitstechnische Eignung muss für den konkreten Dienst bewertet werden. --- **Hairpin NAT** Hairpin NAT ermöglicht einem internen Client den Zugriff auf einen internen Server über dessen externe NAT-Adresse. Beispiel: ```text Interner Client: 192.0.2.100 Öffentliche Dienstadresse: 203.0.113.10:443 Interner Server: 192.0.2.25:443 ``` Der Client verwendet: ```text 192.0.2.100:53124 -> 203.0.113.10:443 ``` Das NAT-Gerät übersetzt das Ziel: ```text 192.0.2.100:53124 -> 192.0.2.25:443 ``` Abhängig von Topologie und Produkt muss zusätzlich die Quelle übersetzt werden, damit der Server über dasselbe NAT-Gerät antwortet. --- **Hairpin NAT mit Quellübersetzung** Mögliche Verarbeitung: ```text Ursprünglich: 192.0.2.100:53124 -> 203.0.113.10:443 Nach Hairpin DNAT und SNAT: 192.0.2.1:61001 -> 192.0.2.25:443 ``` Dabei ist: ```text 192.0.2.1 ``` eine Adresse des NAT-Gateways. Der Server antwortet an das Gateway: ```text 192.0.2.25:443 -> 192.0.2.1:61001 ``` Das Gateway stellt für den Client wieder die erwartete Ansicht her: ```text 203.0.113.10:443 -> 192.0.2.100:53124 ``` Vorteil: - Hin- und Rückverkehr durchlaufen dieselbe NAT-Sitzung. Nachteil: - der Server sieht möglicherweise nicht die ursprüngliche Clientadresse; - Protokolle zeigen die Gatewayadresse; - quelladressbasierte Richtlinien verändern sich. --- **Direkter Rückweg als Hairpin-Problem** Client und Server befinden sich im selben internen Subnetz: ```text Client: 192.0.2.100 Server: 192.0.2.25 ``` Wenn nur das Ziel übersetzt wird, kann der Server direkt antworten: ```text 192.0.2.25:443 -> 192.0.2.100:53124 ``` Der Client hat die Verbindung jedoch zu folgender Adresse aufgebaut: ```text 203.0.113.10:443 ``` Eine direkte Antwort von: ```text 192.0.2.25:443 ``` passt nicht zur erwarteten Gegenstelle. Mögliche Symptome: - interner Zugriff über private Adresse funktioniert; - externer Zugriff über öffentliche Adresse funktioniert; - interner Zugriff über öffentliche Adresse scheitert; - Server sieht das eingehende Paket; - NAT-Gerät sieht keinen Rückverkehr; - Client verwirft die unerwartete Antwort. --- **Hairpin NAT ist nicht überall verfügbar** Mögliche Produktbezeichnungen: - NAT Loopback; - NAT Reflection; - Hairpin NAT; - U-Turn NAT; - Same-Interface NAT; - Intra-Interface NAT. Zu prüfen sind: - wird Hairpin NAT unterstützt? - ist es aktiviert? - gilt es für IPv4, IPv6 oder beide? - gilt es für dieselbe Schnittstelle? - benötigt es eine zusätzliche SNAT-Regel? - wird die ursprüngliche Clientadresse erhalten? - greift die richtige Firewallregel? - verwendet es dieselbe öffentliche Adresse? - funktioniert es bei mehreren WAN-Adressen? - ist es mit Load Balancer oder Proxy kompatibel? Das Verhalten darf nicht von einem anderen Routermodell oder Hersteller übertragen werden. --- **Split DNS als Alternative** Statt Hairpin NAT kann internes DNS den Dienstnamen direkt auf die interne Adresse auflösen. Extern: ```text app.example.test -> 203.0.113.10 ``` Intern: ```text app.example.test -> 192.0.2.25 ``` Vorteile: - interner Verkehr bleibt intern; - keine Hairpin-NAT-Sitzung erforderlich; - ursprüngliche Clientadresse bleibt sichtbar; - weniger Last auf der Edge-Firewall; - einfacherer Datenpfad. Zu prüfen sind: - identischer FQDN; - TLS-Zertifikat für den FQDN; - interne und externe DNS-Zone; - TTL; - DNSSEC-Kontext; - VPN- und Split-DNS-Verhalten; - Load-Balancer-Abhängigkeit; - unterschiedliche Anwendungspfade; - IPv4- und IPv6-Antworten. Split DNS ist nicht automatisch besser, wenn intern derselbe Reverse Proxy, dieselbe Web Application Firewall oder dieselben Sicherheitsprüfungen benötigt werden. --- **Internen und externen Test unterscheiden** Mindestens drei Tests sind getrennt zu dokumentieren: ```text Test A: interner Client -> interne Serveradresse Test B: interner Client -> öffentliche Dienstadresse Test C: externer Client -> öffentliche Dienstadresse ``` Einordnung: | Test A | Test B | Test C | Mögliche Einordnung | |---:|---:|---:|---| | erfolgreich | erfolgreich | erfolgreich | grundlegender Pfad funktioniert | | erfolgreich | fehlerhaft | erfolgreich | Hairpin NAT oder internes DNS | | erfolgreich | erfolgreich | fehlerhaft | externe Weiterleitung, Provider, WAN oder Firewall | | fehlerhaft | fehlerhaft | fehlerhaft | Serverdienst, Host-Firewall oder interne Route | | fehlerhaft | erfolgreich | erfolgreich | unterschiedliche interne Adresse oder Sicherheitsregel | | erfolgreich | fehlerhaft | fehlerhaft | DNAT-Regel oder öffentliche Adresszuordnung | | fehlerhaft | fehlerhaft | erfolgreich | externer Proxy oder anderer Backendpfad | Test C muss tatsächlich aus einem externen Netz erfolgen. Ein Mobilgerät im WLAN ist kein externer Test. Auch ein VPN kann den Datenpfad zurück ins interne Netz führen. --- **DNS und NAT gemeinsam prüfen** Ein FQDN kann liefern: - öffentliche IPv4-Adresse; - öffentliche IPv6-Adresse; - interne IPv4-Adresse; - interne IPv6-Adresse; - Load-Balancer-Adresse; - CDN-Adresse; - Proxyadresse. Windows: ```powershell Resolve-DnsName ` -Name "app.example.test" ` -Type A ``` ```powershell Resolve-DnsName ` -Name "app.example.test" ` -Type AAAA ``` Linux und macOS: ```bash dig app.example.test A ``` ```bash dig app.example.test AAAA ``` Zu prüfen sind: - welche Adresse verwendet die Anwendung tatsächlich? - ist diese Adresse Bestandteil der NAT-Regel? - greift IPv6 ohne IPv4-NAT? - existiert Split DNS? - verwendet der Browser verschlüsseltes DNS? - ist ein Proxy beteiligt? - ist der DNS-Eintrag nach Adressänderung aktuell? Eine korrekte IPv4-Portweiterleitung hilft nicht, wenn der Client aufgrund eines AAAA-Eintrags direkt IPv6 verwendet. --- **IPv6 und NAT** IPv6 benötigt für normale öffentliche Erreichbarkeit nicht dieselbe Form von IPv4-Portübersetzung. Ein global adressierter IPv6-Server ist trotzdem nicht automatisch erreichbar. Zu prüfen sind: - globale IPv6-Adresse; - Präfixdelegation; - IPv6-Route; - IPv6-Firewall; - Listener auf IPv6; - AAAA-Eintrag; - Privacy Address; - stabile Serveradresse; - NDP; - ICMPv6; - Providerfilter; - Reverse Proxy; - NPTv6 oder NAT64. NAT darf nicht als Ersatz für eine IPv6-Firewall betrachtet werden. NPTv6 übersetzt IPv6-Präfixe zustandslos und besitzt ein anderes Verhalten als klassische IPv4-Portübersetzung. --- **Automatische Portabbildungen** Anwendungen können je nach Umgebung automatische Portabbildungen anfordern, beispielsweise über: - UPnP Internet Gateway Device; - NAT-PMP; - Port Control Protocol; - herstellerspezifische Verfahren. Zu prüfen sind: - ist die Funktion aktiviert? - welche Anwendung hat die Regel erstellt? - welcher interne Host ist Ziel? - welcher externe Port wurde vergeben? - welches Protokoll wird verwendet? - wie lange gilt die Abbildung? - existiert Authentifizierung oder Zugriffskontrolle? - bleibt die Regel nach Anwendungsende bestehen? - wird die Regel protokolliert? - überschneidet sie sich mit administrativen Regeln? Automatische Portabbildungen können die vorgesehene Sicherheitskontrolle umgehen. Sie dürfen nicht nur zur schnellen Fehlerbehebung aktiviert werden. --- **Application Level Gateways** Ein NAT-Gerät kann Protokollinhalte analysieren und Adressen oder Ports innerhalb der Nutzdaten verändern. Mögliche Protokolle: - FTP; - SIP; - H.323; - TFTP; - bestimmte VPN-Protokolle; - ältere RPC-Verfahren. Zu prüfen sind: - ALG aktiviert oder deaktiviert; - verschlüsselte oder unverschlüsselte Nutzdaten; - dynamisch ausgehandelte Ports; - NAT-Helper; - fehlerhafte Protokollumschreibung; - Herstellerfehler; - Interaktion mit TLS; - zusätzliche Firewallregeln. Ein ALG kann helfen, aber auch Verbindungen beschädigen. Es darf nur nach nachgewiesenem Zusammenhang verändert werden. --- **NAT und TLS** NAT verändert normalerweise nicht den TLS-Hostnamen oder das Zertifikat. Beispiel: ```text FQDN: app.example.test Öffentliche Adresse: 203.0.113.10 Interner Server: 192.0.2.25 ``` Das Zertifikat muss zum verwendeten Namen passen: ```text app.example.test ``` und nicht zwangsläufig zur öffentlichen oder privaten IP-Adresse. NAT kann jedoch indirekt TLS-Probleme verursachen, wenn: - falscher Backendserver erreicht wird; - externer und interner Port unterschiedliche Dienste liefern; - SNI an falschen Reverse Proxy gelangt; - Hairpin-Zugriff einen anderen Proxy umgeht; - Split DNS ein anderes Ziel liefert; - TLS-Inspektion beteiligt ist; - Proxy Protocol oder ursprüngliche Clientadresse erwartet wird. --- **Reverse Proxy und Portweiterleitung** Häufig zeigt eine Portweiterleitung nicht direkt auf den Anwendungsserver, sondern auf einen Reverse Proxy. Beispiel: ```text Internet: 203.0.113.10:443 DNAT: 192.0.2.20:443 Reverse Proxy: app.example.test -> 192.0.2.25:8080 ``` Zu prüfen sind zwei getrennte Verbindungen: ```text Client -> Reverse Proxy Reverse Proxy -> Backend ``` Mögliche Fehlerstellen: - öffentliche DNAT-Regel; - Firewall; - TLS-Zertifikat; - SNI; - Proxy-VHost; - Backendadresse; - Backendport; - Proxyroute; - Backendfirewall; - Health Check; - Hostheader; - WebSocket-Weiterleitung; - Timeout; - ursprüngliche Clientadresse. Ein erfolgreicher externer TCP-Handshake bis zum Reverse Proxy beweist nicht, dass das Backend erreichbar ist. --- **Docker-Portveröffentlichung** Ein Docker-Container in einem Bridge-Netz ist normalerweise nicht allein durch `EXPOSE` von außen erreichbar. Der Port muss veröffentlicht oder über einen anderen Proxy bereitgestellt werden. Beispiel: ```bash docker run \ -p 8080:80 \ nginx ``` Bedeutung: ```text Hostport 8080 -> Containerport 80 ``` Ohne ausdrücklich angegebene Hostadresse kann ein veröffentlichter Port auf allen geeigneten Hostadressen gebunden werden. Sicherer auf den lokalen Host begrenzt: ```bash docker run \ -p 127.0.0.1:8080:80 \ nginx ``` Damit ist der Port für einen lokalen Reverse Proxy erreichbar, aber nicht automatisch über jede externe Hostschnittstelle. --- **Docker-Portzuordnung prüfen** Laufende Container und veröffentlichte Ports: ```bash docker ps \ --format 'table {{.Names}}\t{{.Ports}}' ``` Portzuordnung eines Containers: ```bash docker port ``` Vollständige Netzwerkinformation: ```bash docker inspect ``` Hostlistener: ```bash ss -lntp ``` Containerlistener: ```bash docker exec \ ss -lntp ``` Falls `ss` im Container nicht installiert ist, sind Anwendungsprotokolle, Health Checks oder die im Image verfügbaren Diagnosewerkzeuge zu verwenden. Zu unterscheiden sind: ```text Routerport Hostport Containerport Anwendungsport ``` Beispiel: ```text 203.0.113.10:8443 -> 192.0.2.20:6875 -> Container:80 ``` --- **Docker-Netzwerkmodus berücksichtigen** | Netzwerkmodus | NAT- oder Portverhalten | |---|---| | Bridge | Portveröffentlichung und NAT üblich | | Host | Container verwendet den Netzwerkstack des Hosts; `-p` wird nicht angewendet | | Macvlan | Container kann eigene Adresse im Netz besitzen | | Ipvlan | direkte adressbasierte Anbindung je nach Betriebsart | | Overlay | zusätzlicher Overlay- und Orchestrierungspfad | | None | keine normale externe Netzwerkanbindung | Bei `host`-Netzwerkmodus besitzt der Container keinen getrennten Host-zu-Container-Portpfad. Eine konfigurierte `-p`-Option wird nicht als normale Portweiterleitung verwendet. --- **Docker und Firewallregeln** Docker kann für Bridge-Netze eigene Firewall- und NAT-Regeln erzeugen. Zu prüfen sind: - nftables oder iptables; - Docker-spezifische Chains; - veröffentlichte Ports; - Host-Firewall; - Forwarding; - Masquerading; - benutzerdefinierte Regeln; - Docker-Netzwerk; - Startreihenfolge; - Neustart des Docker-Daemons; - Firewallreload. Eigene Regeln dürfen nicht ungeprüft vor, nach oder innerhalb von Docker-verwalteten Regelketten eingefügt werden. --- **Kubernetes-Datenpfad** Mögliche Ebenen: ```text öffentliche Adresse -> Cloud Load Balancer -> Ingress Controller -> Kubernetes Service -> Pod ``` Oder: ```text Node-IP:NodePort -> Service -> Pod ``` Lesende Prüfungen: ```bash kubectl get services \ --all-namespaces \ -o wide ``` ```bash kubectl get ingress \ --all-namespaces ``` ```bash kubectl get endpointslices \ --all-namespaces ``` ```bash kubectl describe service \ \ --namespace ``` Zu prüfen sind: - Service-Typ; - ClusterIP; - NodePort; - LoadBalancer-Adresse; - TargetPort; - Selector; - EndpointSlices; - Podport; - Network Policy; - Ingressregel; - Hostname; - TLS; - External Traffic Policy; - Source NAT; - Health Checks. --- **Windows WinNAT lesend prüfen** NAT-Objekte: ```powershell Get-NetNat ``` Statische Abbildungen: ```powershell Get-NetNatStaticMapping ``` Aktive NAT-Sitzungen: ```powershell Get-NetNatSession ``` Netzwerkschnittstellen: ```powershell Get-NetIPConfiguration ``` Routing: ```powershell Get-NetRoute ``` Listener: ```powershell Get-NetTCPConnection ` -State Listen ``` WinNAT wird unter anderem für Hyper-V- und Windows-Container-Netze verwendet. Die Cmdlets zeigen keine NAT-Konfiguration eines getrennten physischen Routers. --- **Linux nftables lesend prüfen** Vollständiges Regelwerk: ```bash sudo nft list ruleset ``` Tabellen: ```bash sudo nft list tables ``` Eine bekannte NAT-Tabelle anzeigen: ```bash sudo nft list table ip nat ``` Die Tabelle muss nicht `ip nat` heißen. Maßgeblich ist die Ausgabe von: ```bash sudo nft list tables ``` Regelwerk mit Handles: ```bash sudo nft -a list ruleset ``` Zu suchen sind unter anderem: ```text dnat snat masquerade redirect prerouting postrouting output input ``` Bei nftables sind: - `dnat` und `redirect` für geeignete NAT-Chains wie `prerouting` oder `output` vorgesehen; - `snat` und `masquerade` für geeignete NAT-Chains wie `postrouting` vorgesehen. Die tatsächliche Chain, Priorität und Familie sind zu prüfen. --- **Vereinfachtes nftables-DNAT-Beispiel** ```nft table ip nat { chain prerouting { type nat hook prerouting priority dstnat; iifname "wan0" \ ip daddr 203.0.113.10 \ tcp dport 8443 \ dnat to 192.0.2.25:443 } } ``` Dieses Beispiel enthält nur die Zielübersetzung. Zusätzlich erforderlich sein können: - Forwarding; - Filterregel; - Rückroute; - SNAT; - Hairpin-Regel; - Protokollierung; - IPv6-Regel; - dauerhaftes Konfigurationsmanagement. Es darf nicht ungeprüft in ein produktives Regelwerk übernommen werden. --- **Vereinfachtes nftables-Hairpin-Prinzip** ```nft table ip nat { chain prerouting { type nat hook prerouting priority dstnat; ip saddr 192.0.2.0/24 \ ip daddr 203.0.113.10 \ tcp dport 443 \ dnat to 192.0.2.25:443 } chain postrouting { type nat hook postrouting priority srcnat; ip saddr 192.0.2.0/24 \ ip daddr 192.0.2.25 \ tcp dport 443 \ masquerade } } ``` Dieses vereinfachte Prinzip erzwingt, dass der Rückverkehr wieder über das NAT-Gateway läuft. Adressen, Schnittstellen, Sicherheitsregeln und Regelprioritäten müssen an die tatsächliche Umgebung angepasst und freigegeben werden. --- **Linux iptables lesend prüfen** NAT-Regeln: ```bash sudo iptables \ -t nat \ -L \ -n \ -v \ --line-numbers ``` Regeln in speicherbarer Syntax: ```bash sudo iptables \ -t nat \ -S ``` IPv6-Regeln, sofern verwendet: ```bash sudo ip6tables \ -t nat \ -S ``` Filter- und Forwardingregeln: ```bash sudo iptables \ -L FORWARD \ -n \ -v \ --line-numbers ``` Aktive Weiterleitung: ```bash sysctl net.ipv4.ip_forward ``` IPv6-Weiterleitung: ```bash sysctl net.ipv6.conf.all.forwarding ``` --- **Linux Connection Tracking** Aktive NAT- und Verbindungseinträge: ```bash sudo conntrack -L ``` TCP-Einträge zu einem internen Server: ```bash sudo conntrack -L \ -p tcp \ -d 192.0.2.25 \ --dport 443 ``` Ereignisse während eines kontrollierten Tests: ```bash sudo conntrack -E ``` Zu prüfen sind: - Originalrichtung; - Antwortrichtung; - Quell- und Zielports; - `src-nat`; - `dst-nat`; - `[UNREPLIED]`; - `[ASSURED]`; - Timeout; - Paket- und Bytezähler. Das vollständige Leeren der Conntrack-Tabelle ist keine erste Diagnosemaßnahme. --- **Cisco Secure Firewall ASA prüfen** NAT-Regeln: ```text show nat ``` Details und Treffer: ```text show nat detail ``` Übersetzungen: ```text show xlate ``` Verbindungen: ```text show conn ``` Nach Adresse filtern: ```text show conn address 192.0.2.25 ``` Routing: ```text show route ``` Simulation: ```text packet-tracer input outside tcp 198.51.100.40 53124 203.0.113.10 8443 detailed ``` Zu prüfen sind: - passende NAT-Regel; - NAT-Abschnitt und Reihenfolge; - reale und übersetzte Adresse; - externer und interner Port; - ACL; - Route; - Eingangs- und Ausgangsschnittstelle; - Ergebnis jeder Verarbeitungsphase. Bei aktuellen Cisco-ASA-Regelwerken werden Zugriffsregeln im NAT-Kontext anhand realer Adressen ausgewertet. Dieses Verhalten darf nicht auf andere Produkte übertragen werden. --- **Cloud-NAT und eingehende Verbindungen** Ein Cloud-NAT-Gateway dient häufig ausschließlich der ausgehenden Kommunikation privater Ressourcen. Wichtig: ```text Outbound NAT ist nicht automatisch Inbound Port Forwarding ``` Für eingehende Veröffentlichung können stattdessen erforderlich sein: - öffentliche Instanzadresse; - Load Balancer; - Network Load Balancer; - Application Gateway; - Cloud Firewall DNAT; - Reverse Proxy; - API Gateway; - Ingress Controller; - private Verbindung; - VPN. --- **AWS NAT Gateway** AWS NAT Gateway erlaubt privaten Ressourcen ausgehende Verbindungen. Es nimmt keine unaufgeforderten eingehenden Internetverbindungen für diese Ressourcen an. Zu prüfen sind: - public oder private NAT Gateway; - Subnetz; - Routingtabelle; - Internet Gateway; - Elastic IP; - Security Groups der Instanz; - Network ACLs; - Rückverkehr einer ausgehenden Sitzung; - CloudWatch-Metriken. Eine Portweiterleitung auf ein AWS NAT Gateway ist nicht der vorgesehene Weg zur Veröffentlichung eines privaten Servers. Mögliche Alternativen: - Application Load Balancer; - Network Load Balancer; - öffentliche Instanzadresse mit Security Group; - AWS Network Firewall beziehungsweise geeignete zentrale Firewall; - API Gateway; - VPN oder PrivateLink, abhängig vom Anwendungsfall. --- **Azure NAT Gateway** Azure NAT Gateway stellt ausgehende Internetkonnektivität für ein Subnetz bereit. Unaufgeforderte eingehende Internetverbindungen werden nicht bereitgestellt. DNAT wird nur für Antwortpakete einer zuvor ausgehend aufgebauten Kommunikation angewendet. Für eingehende Veröffentlichung können je nach Anforderung verwendet werden: - Azure Load Balancer; - Application Gateway; - Azure Firewall DNAT; - öffentliche IP-Adresse einer Ressource; - API Management; - Front Door; - privater Endpunkt; - VPN. Zu prüfen sind: - Subnetzanbindung; - öffentliche NAT-Adressen; - effektive Route; - Azure Firewall; - Load Balancer; - Network Security Group; - User Defined Route; - Zielressource; - Health Probe. --- **Paketaufzeichnung entlang des NAT-Pfads** Für einen NAT-Nachweis sind mehrere Beobachtungspunkte erforderlich. Beispiel: | Beobachtungspunkt | Erwarteter Datenfluss | |---|---| | vor Edge-Firewall | `198.51.100.40:53124 -> 203.0.113.10:8443` | | nach DNAT | `198.51.100.40:53124 -> 192.0.2.25:443` | | am Server | `198.51.100.40:53124 -> 192.0.2.25:443` | | Serverantwort | `192.0.2.25:443 -> 198.51.100.40:53124` | | nach Rückübersetzung | `203.0.113.10:8443 -> 198.51.100.40:53124` | Mit `tcpdump` auf dem externen Abschnitt: ```bash sudo tcpdump \ -ni \ 'host 198.51.100.40 and host 203.0.113.10 and tcp port 8443' ``` Auf dem internen Abschnitt: ```bash sudo tcpdump \ -ni \ 'host 198.51.100.40 and host 192.0.2.25 and tcp port 443' ``` Am Server: ```bash sudo tcpdump \ -ni any \ 'host 198.51.100.40 and tcp port 443' ``` Die Platzhalter müssen durch autorisierte reale Werte ersetzt werden. --- **Befund aus Paketaufzeichnungen** | WAN-Eingang | LAN-Ausgang | Serverantwort | Einordnung | |---:|---:|---:|---| | nein | nein | nein | Problem vor dem NAT-Gerät | | ja | nein | nein | NAT-, Firewall- oder Routingproblem | | ja | ja | nein | Server, Host-Firewall oder Dienst prüfen | | ja | ja | ja, aber nicht am NAT | falscher Rückweg | | ja | ja | ja und Rückübersetzung | Clientpfad oder Anwendung prüfen | | Hairpin am LAN sichtbar | kein Hairpin-Ausgang | Hairpin NAT fehlt oder passt nicht | | DNAT korrekt | falscher interner Port | NAT-Regel korrigieren | | Paket erreicht falschen Server | falsches Zielobjekt oder alte Regel | Regel und Objekt prüfen | Hardware-Offloading kann verhindern, dass eine allgemeine Softwareaufzeichnung alle Pakete zeigt. Dann sind herstellerspezifische Captures, SPAN oder TAP erforderlich. --- **Porttest richtig ausführen** Windows: ```powershell Test-NetConnection ` -ComputerName "203.0.113.10" ` -Port 8443 ` -InformationLevel Detailed ``` Linux und macOS: ```bash nc -vz 203.0.113.10 8443 ``` HTTPS mit FQDN: ```bash curl \ -v \ https://app.example.test:8443/ ``` Ein TCP-Porttest beweist nur den TCP-Aufbau bis zu der Komponente, die antwortet. Er beweist nicht: - richtigen Backendserver; - korrekte Anwendung; - gültiges TLS-Zertifikat; - korrekten Hostheader; - funktionierende Authentifizierung; - funktionierende Datenbank; - korrekte UDP-Weiterleitung. Ein UDP-Test benötigt eine anwendungsspezifische Antwort, Protokollauswertung oder Paketaufzeichnung. --- **Externer Test** Ein externer Test muss aus einem tatsächlich unabhängigen Netz erfolgen. Mögliche Testsysteme: - autorisierter Server in einem anderen Standort; - freigegebene Cloud-VM; - Mobilfunkverbindung ohne WLAN; - externer Monitoringstandort; - vereinbarter Testhost eines Dienstleisters. Zu dokumentieren sind: - externe Quelladresse; - Zeitpunkt; - DNS-Ergebnis; - Zieladresse; - Zielport; - Protokoll; - Ergebnis; - Firewalllog; - NAT-Regeltreffer; - Serversicht. Öffentliche Portscan-Webseiten sollten nicht unkontrolliert für interne oder sensible Dienste verwendet werden. --- **NAT-Protokollierung** Ein geeigneter NAT- oder Firewalllogeintrag enthält möglichst: - Zeitstempel; - Eingangs- und Ausgangsschnittstelle; - Quellzone; - Zielzone; - Original-Quelladresse; - Original-Quellport; - Original-Zieladresse; - Original-Zielport; - übersetzte Quelladresse; - übersetzter Quellport; - übersetzte Zieladresse; - übersetzter Zielport; - Protokoll; - NAT-Regel; - Sicherheitsregel; - Sitzungs-ID; - Aktion; - Pakete; - Bytes; - Sitzungsendgrund. Ein fehlender NAT-Logeintrag kann bedeuten: - Datenverkehr erreicht das Gerät nicht; - Logging ist deaktiviert; - falscher Clusterknoten wird geprüft; - falscher virtueller Kontext wird geprüft; - andere NAT-Regel trifft; - Paket wird vor NAT verworfen; - Sitzung bestand bereits; - Hardware-Offload verwendet andere Zähler. --- **Hypothese und Gegenbeweis formulieren** Beispiel: ```text Hypothese: Die Portweiterleitung 203.0.113.10:8443 zeigt korrekt auf 192.0.2.25:443. Interne Clients können die öffentliche Adresse jedoch nicht verwenden, weil die Firewall kein Hairpin NAT für dieselbe interne Zone ausführt. Erwarteter Befund: Der interne Direktzugriff auf 192.0.2.25:443 funktioniert. Ein externer Zugriff auf 203.0.113.10:8443 funktioniert. Beim internen Zugriff auf 203.0.113.10:8443 steigt der Trefferzähler der normalen WAN-DNAT-Regel nicht oder der Rückverkehr umgeht die NAT-Sitzung. Gegenbeweis: Der Hairpin-Datenfluss wird nachweislich übersetzt, Hin- und Rückverkehr durchlaufen dieselbe NAT-Sitzung und die Antwort erreicht den Client mit der erwarteten öffentlichen Quelladresse. Testmethode: Drei getrennte Zugriffe über interne Adresse, öffentliche Adresse von intern und öffentliche Adresse von extern durchführen. NAT-Zähler, Sitzungstabelle und Paketaufzeichnung korrelieren. Risiko: Nur lesende Diagnose und kontrollierte Verbindungstests. Erfolgskriterium: Fehler ist eindeutig auf Hairpin-Verarbeitung, Rückweg oder eine nachgelagerte Anwendungsebene begrenzt. ``` --- **Kontrollierte Maßnahmen** | Maßnahme | Voraussetzung | Risiko | Rückweg | |---|---|---|---| | DNAT-Ziel korrigieren | falsche interne Adresse nachgewiesen | anderes System wird veröffentlicht | alte Zieladresse wiederherstellen | | externen Port korrigieren | falscher Port bestätigt | Clients müssen neuen Port verwenden | alten Port wiederherstellen | | internen Port korrigieren | tatsächlicher Listener nachgewiesen | falscher Dienst kann erreicht werden | alten Zielport wiederherstellen | | Protokoll korrigieren | TCP-/UDP-Abweichung bestätigt | zusätzliche Erreichbarkeit | alte Protokollregel | | Quellbereich einschränken | zulässige Quellen bekannt | legitime Quellen können fehlen | vorherigen Bereich wiederherstellen | | Rückroute korrigieren | asymmetrischer Rückweg bestätigt | weitere Ziele betroffen | alte Route wiederherstellen | | Hairpin DNAT ergänzen | interner öffentlicher Zugriff erforderlich | zusätzlicher interner Pfad | Regel entfernen | | Hairpin SNAT ergänzen | direkter Rückweg verhindert Sitzung | ursprüngliche Client-IP geht verloren | SNAT-Regel entfernen | | Split DNS einrichten | interner Direktpfad freigegeben | interner Pfad unterscheidet sich extern | vorherige DNS-Antwort | | Host-Firewall korrigieren | Serverdrop bestätigt | zusätzliche Angriffsfläche | alte Regel | | Containerport korrigieren | Host-/Containerabweichung bestätigt | Dienst wird anders veröffentlicht | alte Portzuordnung | | Reverse-Proxy-Ziel korrigieren | falsches Backend bestätigt | Anwendungspfad verändert sich | alte Proxykonfiguration | | öffentliche IPv4 bereitstellen | CGNAT bestätigt und fachlich erforderlich | Kosten und größere Angriffsfläche | Vertrag oder Zuweisung zurücknehmen | | NAT-Regelreihenfolge korrigieren | Überschattung nachgewiesen | andere Datenflüsse betroffen | alte Reihenfolge | --- **Vollständiger Diagnoseablauf** 1. Exakte Fehlermeldung erfassen. 2. Datum, Uhrzeit und Zeitzone dokumentieren. 3. Betroffene Anwendung bestimmen. 4. FQDN dokumentieren. 5. DNS-A- und AAAA-Antworten prüfen. 6. tatsächlich verwendete Zieladresse bestimmen. 7. TCP, UDP oder anderes Protokoll bestimmen. 8. externen Zielport bestimmen. 9. internen Zielport bestimmen. 10. externe Quelladresse dokumentieren. 11. öffentliche Zieladresse dokumentieren. 12. internes Ziel dokumentieren. 13. Vor-NAT-Tupel dokumentieren. 14. Nach-NAT-Tupel dokumentieren. 15. Umfang der Störung bestimmen. 16. interne Direktverbindung testen. 17. internen Zugriff über öffentliche Adresse testen. 18. tatsächlich externen Zugriff testen. 19. WAN-Adresse des Edge-Geräts prüfen. 20. vorgeschaltetes NAT oder CGNAT prüfen. 21. doppeltes NAT berücksichtigen. 22. richtige Eingangsschnittstelle bestimmen. 23. richtige öffentliche Zieladresse bestimmen. 24. aktive NAT-Konfiguration prüfen. 25. NAT-Regelreihenfolge prüfen. 26. NAT-Regeltreffer dokumentieren. 27. Firewallregel getrennt prüfen. 28. Routing zum internen Ziel prüfen. 29. Host-Firewall prüfen. 30. Listener des Serverdienstes prüfen. 31. Serverantwort und Rückroute prüfen. 32. NAT-Sitzung oder Translation Table prüfen. 33. Hin- und Rückverkehr vergleichen. 34. Hairpin-Unterstützung prüfen. 35. Hairpin-DNAT und gegebenenfalls SNAT prüfen. 36. Split-DNS-Verhalten berücksichtigen. 37. Reverse Proxy oder Load Balancer prüfen. 38. Container-Hostport und Containerport prüfen. 39. Kubernetes-Servicepfad berücksichtigen. 40. automatische Portabbildungen prüfen. 41. ALG oder NAT-Helper berücksichtigen. 42. IPv4 und IPv6 getrennt prüfen. 43. Cloud-NAT und Inbound-Komponente unterscheiden. 44. bei Bedarf Paketaufzeichnung vor und nach NAT durchführen. 45. Hypothese und Gegenbeweis formulieren. 46. genau eine kontrollierte Maßnahme vorbereiten. 47. Risiko, Rückweg und Erfolgskriterium dokumentieren. 48. Maßnahme freigeben und umsetzen. 49. neue Sitzung aufbauen. 50. internen, Hairpin- und externen Test wiederholen. 51. NAT-, Firewall- und Anwendungslogs verifizieren. 52. weitere repräsentative Quellen testen. 53. temporäre Regeln und Captures zurücknehmen. 54. Ursache, Maßnahme und Prävention dokumentieren. --- **Befundmatrix** | Befund | Mögliche Einordnung | Nächster Nachweis | |---|---|---| | interne Adresse funktioniert, öffentliche intern nicht | Hairpin NAT oder Split DNS | Hairpin-Sitzung und Rückweg prüfen | | öffentliche Adresse extern funktioniert | DNAT und externer Pfad grundsätzlich aktiv | internen Hairpin-Pfad getrennt prüfen | | öffentliche Adresse extern nicht erreichbar | Provider, CGNAT, WAN, DNAT oder Firewall | WAN-IP und NAT-Regeltreffer | | NAT-Regelzähler bleibt null | falsche IP, Schnittstelle, Port oder Pfad | Capture vor dem NAT-Gerät | | NAT-Regel trifft, Firewall blockiert | getrennte Sicherheitsrichtlinie | Firewalllog und Adressphase | | NAT und Firewall erlauben, Server antwortet nicht | Host-Firewall, Listener oder Dienst | serverseitiges Capture | | Server antwortet, NAT sieht Antwort nicht | falsche Rückroute | Serverroute und Gateway | | Rückantwort besitzt private Quelladresse | fehlende Rückübersetzung oder Hairpin-Asymmetrie | NAT-Sitzung und Pfad | | WAN-Adresse ist privat | vorgeschaltetes NAT | Upstreamgerät prüfen | | WAN-Adresse liegt in `100.64.0.0/10` | CGNAT wahrscheinlich | Provider und externe Adresse | | Router-WAN-IP weicht von externer IP ab | vorgeschaltetes NAT, VPN oder Proxy | vollständigen Ausgangspfad prüfen | | TCP funktioniert, UDP nicht | Protokollregel oder UDP-State | UDP-Capture und NAT-Timeout | | IPv4 funktioniert, FQDN nicht | AAAA-Pfad oder DNS | A-/AAAA-Antwort vergleichen | | externer Port offen, falsche Anwendung | falsches DNAT-Ziel oder Reverse Proxy | Backend und Hostheader prüfen | | Docker-Hostport lauscht nicht | Port nicht veröffentlicht oder Container gestoppt | `docker ps` und `docker port` | | Hostport lauscht, Container antwortet nicht | Containerdienst oder Zielport | Containerlistener und Logs | | Container direkt erreichbar, öffentlich nicht | Router-, Host- oder DNAT-Pfad | schrittweise Porttests | | Zugriff nach Routerneustart kurz möglich | Zustand, dynamische Adresse oder Konflikt | Translation Table und WAN-IP | | nur manche Quellen funktionieren | Quellfilter oder NAT-Filterverhalten | Regeln und Quelladressen vergleichen | | Zugriff über IP, nicht über Namen | DNS, SNI oder Zertifikat | FQDN und TLS-Prüfung | | intern anderer Server als extern | Split DNS oder Proxyunterschied | DNS-Antworten und Backend | | AWS NAT Gateway sendet ausgehend, kein Inbound | erwartetes Produktverhalten | Load Balancer oder andere Inbound-Komponente | | Azure NAT Gateway sendet ausgehend, kein Inbound | erwartetes Produktverhalten | Azure Firewall DNAT oder Load Balancer | | nach Regeländerung alte Sitzung bleibt | bestehender Translation State | vollständig neue Sitzung testen | | extern klappt nur über einen WAN-Anschluss | NAT-Regel nur an einer Schnittstelle | WAN-Bindung und Routing | --- **Typische Diagnosefehler** - NAT als Firewall betrachten. - Vorhandene NAT-Regel als vollständige Freigabe bewerten. - Öffentliche und private Adresse verwechseln. - externen und internen Port verwechseln. - TCP und UDP nicht unterscheiden. - IPv4 und IPv6 nicht getrennt prüfen. - FQDN nicht auf A und AAAA prüfen. - Regel an falscher WAN-Schnittstelle übersehen. - NAT-Regelreihenfolge ignorieren. - alte oder überschattete Regel nicht erkennen. - Rückweg nicht prüfen. - nur Hinrichtung aufzeichnen. - NAT-Sitzung nicht auswerten. - bestehende und neue Sitzung nicht unterscheiden. - interne Direktverbindung als Nachweis externer Erreichbarkeit verwenden. - internen Zugriff auf öffentliche Adresse als externen Test bewerten. - Mobilgerät im WLAN als externes System verwenden. - VPN-Pfad beim externen Test übersehen. - CGNAT nicht berücksichtigen. - `100.64.0.0/10` mit normalem RFC-1918-Netz gleichsetzen. - doppeltes NAT übersehen. - DMZ Host oder Exposed Host als schnelle Lösung aktivieren. - Hairpin NAT als überall vorhandene Funktion annehmen. - Split DNS ohne Betrachtung von Proxy und Sicherheitskontrollen einsetzen. - Hairpin-SNAT ohne Auswirkungen auf Clientprotokollierung aktivieren. - NAT als Schutzmechanismus für IPv6 verwenden. - UPnP zur Fehlerbehebung pauschal aktivieren. - automatisch erzeugte Portabbildungen nicht prüfen. - ALG ohne Nachweis deaktivieren oder aktivieren. - Docker-`EXPOSE` mit Portveröffentlichung verwechseln. - Docker-Hostport und Containerport verwechseln. - `-p` bei Host-Netzwerkmodus als wirksam annehmen. - Kubernetes Service Port und TargetPort verwechseln. - Cloud NAT Gateway als Inbound-Portweiterleitung behandeln. - erfolgreichen TCP-Handshake als Anwendungserfolg bewerten. - NAT- oder Conntrack-Tabelle vorsorglich leeren. - mehrere NAT- und Firewallregeln gleichzeitig verändern. - temporäre Portweiterleitung aktiv lassen. - Ursache und Sicherheitswirkung nicht dokumentieren. --- **Verifikation** Nach einer Maßnahme müssen mindestens folgende Punkte geprüft werden: - DNS liefert die vorgesehenen Adressen; - Client verwendet die erwartete Adressfamilie; - öffentliche Zieladresse stimmt; - WAN-Adresse stimmt; - vorgeschaltetes NAT ist berücksichtigt; - externes Protokoll stimmt; - externer Port stimmt; - internes Ziel stimmt; - interner Port stimmt; - NAT-Regel trifft; - richtige NAT-Regel trifft; - Regelreihenfolge ist korrekt; - Firewallregel erlaubt nur den benötigten Verkehr; - Quellbereich ist angemessen begrenzt; - internes Routing funktioniert; - Server besitzt die erwartete Adresse; - Serverdienst lauscht; - Host-Firewall erlaubt den benötigten Verkehr; - Rückroute führt über die richtige NAT-Komponente; - NAT-Sitzung enthält korrekte Original- und Antworttupel; - interner Direktzugriff funktioniert; - Hairpin-Zugriff funktioniert, sofern vorgesehen; - Split DNS funktioniert, sofern vorgesehen; - externer Zugriff aus einem unabhängigen Netz funktioniert; - TCP und UDP funktionieren, sofern erforderlich; - IPv4 und IPv6 funktionieren, sofern vorgesehen; - TLS-Zertifikat und SNI stimmen; - Reverse Proxy erreicht das richtige Backend; - Docker-Host- und Containerport stimmen; - Kubernetes Service und Endpoint stimmen; - keine unbeabsichtigte Portveröffentlichung besteht; - keine allgemeine Exposed-Host-Regel aktiv ist; - Logs zeigen die erwartete Quelle und Übersetzung; - Monitoring erkennt Ausfälle; - temporäre Regeln und Captures wurden zurückgenommen; - Ursache, Maßnahme und Prävention wurden dokumentiert. Eine erfolgreiche Verbindung aus dem internen Netz reicht nicht als Verifikation einer Internet-Portweiterleitung. --- **Dokumentationsvorlage** ```text Störung: Datum und Uhrzeit: Betroffene Anwendung: FQDN: DNS-Antworten: Externe Quelle: Öffentliches Ziel: Protokoll: Internes Ziel: Vor-NAT-Tupel: Ziel:Port> Nach-NAT-Tupel: Ziel:Port> NAT-Gerät: Eingangsschnittstelle: Ausgangsschnittstelle: NAT-Regel: Firewallregel: NAT-Sitzung: WAN-Adresse: Extern beobachtete Adresse: Vorgeschaltetes NAT: CGNAT: Rückroute: Serverlistener: Host-Firewall: Containerzuordnung: Hostport -> Containerport> Reverse Proxy: Interner Direktzugriff: Interner Zugriff über öffentliche Adresse: Externer Zugriff: Paketaufzeichnung: Hypothese: Erwarteter Nachweis: Gegenbeweis: Nachgewiesene Ursache: Durchgeführte Maßnahme: Risiko: Rückweg: Verifikation: Prävention: ``` --- **Checkliste** - [ ] exakte Fehlermeldung dokumentiert - [ ] Datum, Uhrzeit und Zeitzone erfasst - [ ] Anwendung bestimmt - [ ] FQDN dokumentiert - [ ] A-Eintrag geprüft - [ ] AAAA-Eintrag geprüft - [ ] tatsächliche Zieladresse bestimmt - [ ] IPv4 und IPv6 unterschieden - [ ] TCP und UDP unterschieden - [ ] externe Quelladresse erfasst - [ ] öffentlichen Zielport erfasst - [ ] internes Ziel erfasst - [ ] internen Zielport erfasst - [ ] Vor-NAT-Tupel dokumentiert - [ ] Nach-NAT-Tupel dokumentiert - [ ] Fehlerumfang bestimmt - [ ] interne Direktverbindung getestet - [ ] internen Zugriff über öffentliche Adresse getestet - [ ] echten externen Zugriff getestet - [ ] WAN-Adresse geprüft - [ ] extern beobachtete Adresse geprüft - [ ] vorgeschaltetes NAT geprüft - [ ] CGNAT geprüft - [ ] doppeltes NAT geprüft - [ ] öffentliche Adresszuordnung geprüft - [ ] richtige Eingangsschnittstelle geprüft - [ ] richtige Ausgangsschnittstelle geprüft - [ ] NAT-Regel bestimmt - [ ] NAT-Regelposition geprüft - [ ] NAT-Regeltreffer geprüft - [ ] Überschattung geprüft - [ ] NAT-Ausnahme geprüft - [ ] Firewallregel getrennt geprüft - [ ] Quellbereich geprüft - [ ] interne Route geprüft - [ ] Rückroute geprüft - [ ] Serveradresse geprüft - [ ] DHCP-Reservierung geprüft - [ ] Serverlistener geprüft - [ ] Host-Firewall geprüft - [ ] NAT-Sitzung geprüft - [ ] Originalrichtung geprüft - [ ] Antwortrichtung geprüft - [ ] Pakete und Bytes je Richtung geprüft - [ ] Hairpin-Unterstützung geprüft - [ ] Hairpin-DNAT geprüft - [ ] Hairpin-SNAT geprüft - [ ] Auswirkung auf Client-IP-Protokollierung geprüft - [ ] Split DNS geprüft - [ ] TLS-Zertifikat geprüft - [ ] SNI geprüft - [ ] Reverse Proxy geprüft - [ ] Load Balancer geprüft - [ ] Backend geprüft - [ ] Docker-Netzwerkmodus geprüft - [ ] Docker-Hostport geprüft - [ ] Containerport geprüft - [ ] Containerlistener geprüft - [ ] Kubernetes Service geprüft - [ ] Kubernetes TargetPort geprüft - [ ] EndpointSlices geprüft - [ ] automatische Portabbildungen geprüft - [ ] UPnP, NAT-PMP oder PCP geprüft - [ ] ALG und NAT-Helper geprüft - [ ] Cloud-NAT und Inbound-Komponente unterschieden - [ ] Paketaufzeichnung vor NAT durchgeführt, sofern erforderlich - [ ] Paketaufzeichnung nach NAT durchgeführt, sofern erforderlich - [ ] Hypothese formuliert - [ ] Gegenbeweis definiert - [ ] Risiko dokumentiert - [ ] Rückweg dokumentiert - [ ] nur eine kontrollierte Maßnahme durchgeführt - [ ] vollständig neue Sitzung getestet - [ ] ursprüngliche Anwendung verifiziert - [ ] weitere repräsentative Quellen geprüft - [ ] temporäre Weiterleitung entfernt - [ ] temporäre Captures entfernt - [ ] Ursache und Prävention dokumentiert --- **Schnellreferenz** | Aufgabe | Befehl | |---|---| | Windows-NAT-Objekte | `Get-NetNat` | | Windows-statische NAT-Abbildungen | `Get-NetNatStaticMapping` | | Windows-NAT-Sitzungen | `Get-NetNatSession` | | Windows-Routing | `Get-NetRoute` | | Windows-Listener | `Get-NetTCPConnection -State Listen` | | Windows-DNS A | `Resolve-DnsName -Name "app.example.test" -Type A` | | Windows-DNS AAAA | `Resolve-DnsName -Name "app.example.test" -Type AAAA` | | Windows-TCP-Porttest | `Test-NetConnection -ComputerName "203.0.113.10" -Port 8443` | | Linux-nftables-Regelwerk | `sudo nft list ruleset` | | Linux-nftables-Tabellen | `sudo nft list tables` | | Linux-nftables mit Handles | `sudo nft -a list ruleset` | | Linux-iptables-NAT | `sudo iptables -t nat -L -n -v --line-numbers` | | Linux-iptables-NAT-Regeln | `sudo iptables -t nat -S` | | Linux-Forwardingregeln | `sudo iptables -L FORWARD -n -v --line-numbers` | | Linux-IPv4-Forwarding | `sysctl net.ipv4.ip_forward` | | Linux-Conntrack | `sudo conntrack -L` | | Linux-Conntrack-Ereignisse | `sudo conntrack -E` | | Linux-Listener | `ss -lntp` | | Linux/macOS-DNS A | `dig app.example.test A` | | Linux/macOS-DNS AAAA | `dig app.example.test AAAA` | | Linux/macOS-TCP-Porttest | `nc -vz 203.0.113.10 8443` | | HTTPS-Test | `curl -v https://app.example.test:8443/` | | Docker-Ports | `docker ps --format 'table {{.Names}}\t{{.Ports}}'` | | Docker-Portzuordnung | `docker port ` | | Docker-Details | `docker inspect ` | | Kubernetes-Services | `kubectl get services --all-namespaces -o wide` | | Kubernetes-Ingress | `kubectl get ingress --all-namespaces` | | Kubernetes-Endpunkte | `kubectl get endpointslices --all-namespaces` | | Cisco-ASA-NAT | `show nat` | | Cisco-ASA-NAT-Details | `show nat detail` | | Cisco-ASA-Übersetzungen | `show xlate` | | Cisco-ASA-Verbindungen | `show conn` | | Cisco-ASA-Routing | `show route` | Verändernde Befehle und Maßnahmen, die nicht als erste Diagnose verwendet werden dürfen: ```text New-NetNat Add-NetNatStaticMapping Remove-NetNat Remove-NetNatStaticMapping nft add rule ... dnat ... nft add rule ... snat ... nft flush ruleset iptables -t nat -F conntrack -F clear xlate clear conn Firewall deaktivieren Exposed Host aktivieren DMZ Host aktivieren alle Ports weiterleiten UPnP pauschal aktivieren NAT-PMP pauschal aktivieren PCP pauschal aktivieren ALG ungeprüft deaktivieren ALG ungeprüft aktivieren Router vorsorglich neu starten Firewall vorsorglich neu starten öffentliche Verwaltungsports testweise freigeben allgemeine any-any-Regel erstellen ``` --- **Quellen** **Standards** - [RFC 2663 – IP Network Address Translator Terminology and Considerations](https://datatracker.ietf.org/doc/html/rfc2663) - [RFC 3022 – Traditional IP Network Address Translator](https://datatracker.ietf.org/doc/html/rfc3022) - [RFC 4787 – NAT Behavioral Requirements for UDP](https://datatracker.ietf.org/doc/html/rfc4787) - [RFC 5382 – NAT Behavioral Requirements for TCP](https://datatracker.ietf.org/doc/html/rfc5382) - [RFC 5508 – NAT Behavioral Requirements for ICMP](https://datatracker.ietf.org/doc/html/rfc5508) - [RFC 7857 – Updates to NAT Behavioral Requirements](https://datatracker.ietf.org/doc/html/rfc7857) - [RFC 1918 – Address Allocation for Private Internets](https://datatracker.ietf.org/doc/html/rfc1918) - [RFC 6598 – Shared Address Space Request](https://datatracker.ietf.org/doc/html/rfc6598) - [RFC 6886 – NAT Port Mapping Protocol](https://datatracker.ietf.org/doc/html/rfc6886) - [RFC 6887 – Port Control Protocol](https://datatracker.ietf.org/doc/html/rfc6887) - [RFC 6296 – IPv6-to-IPv6 Network Prefix Translation](https://datatracker.ietf.org/doc/html/rfc6296) - [RFC 2993 – Architectural Implications of NAT](https://datatracker.ietf.org/doc/html/rfc2993) **Microsoft Windows** - [Microsoft Learn – Get-NetNat](https://learn.microsoft.com/en-us/powershell/module/netnat/get-netnat) - [Microsoft Learn – Get-NetNatStaticMapping](https://learn.microsoft.com/en-us/powershell/module/netnat/get-netnatstaticmapping) - [Microsoft Learn – Get-NetNatSession](https://learn.microsoft.com/en-us/powershell/module/netnat/get-netnatsession) - [Microsoft Learn – Set Up a NAT Network](https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/setup-nat-network) - [Microsoft Learn – Windows Container Network Drivers](https://learn.microsoft.com/en-us/virtualization/windowscontainers/container-networking/network-drivers-topologies) **Linux Netfilter** - [Netfilter – nftables Manual](https://www.netfilter.org/projects/nftables/manpage.html) - [Netfilter – iptables Extensions Manual](https://ipset.netfilter.org/iptables-extensions.man.html) - [Netfilter – Conntrack Tools User Manual](https://conntrack-tools.netfilter.org/manual.html) - [Linux Kernel Documentation – Netfilter Conntrack Sysfs Variables](https://docs.kernel.org/networking/nf_conntrack-sysctl.html) **Docker und Kubernetes** - [Docker Docs – Port Publishing and Mapping](https://docs.docker.com/engine/network/port-publishing/) - [Docker Docs – Networking Overview](https://docs.docker.com/engine/network/) - [Docker Docs – Bridge Network Driver](https://docs.docker.com/engine/network/drivers/bridge/) - [Docker Docs – Host Network Driver](https://docs.docker.com/engine/network/drivers/host/) - [Docker Docs – Packet Filtering and Firewalls](https://docs.docker.com/engine/network/packet-filtering-firewalls/) - [Kubernetes Documentation – Service](https://kubernetes.io/docs/concepts/services-networking/service/) - [Kubernetes Documentation – Ingress](https://kubernetes.io/docs/concepts/services-networking/ingress/) **Cisco** - [Cisco Secure Firewall ASA – NAT Basics](https://www.cisco.com/c/en/us/td/docs/security/asa/asa920/configuration/firewall/asa-920-firewall-config/nat-basics.html) - [Cisco – Configure NAT and ACLs on ASA](https://www.cisco.com/c/en/us/support/docs/security/asa-5500-x-series-next-generation-firewalls/115904-asa-config-dmz-00.html) - [Cisco Secure Firewall ASA – `packet-tracer` Command Reference](https://www.cisco.com/c/en/us/td/docs/security/asa/asa-cli-reference/I-R/asa-command-ref-I-R/pa-pn-commands.html) **Amazon Web Services** - [AWS – NAT Gateways](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html) - [AWS – NAT Gateway Basics](https://docs.aws.amazon.com/vpc/latest/userguide/nat-gateway-basics.html) - [AWS – NAT Gateway Use Cases](https://docs.aws.amazon.com/vpc/latest/userguide/nat-gateway-scenarios.html) - [AWS – Internet Gateways](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Internet_Gateway.html) **Microsoft Azure** - [Microsoft Learn – Azure NAT Gateway Overview](https://learn.microsoft.com/en-us/azure/nat-gateway/nat-overview) - [Microsoft Learn – Azure NAT Gateway Resource](https://learn.microsoft.com/en-us/azure/nat-gateway/nat-gateway-resource) - [Microsoft Learn – Azure Load Balancer Outbound Connections](https://learn.microsoft.com/en-us/azure/load-balancer/load-balancer-outbound-connections) - [Microsoft Learn – Azure Firewall DNAT](https://learn.microsoft.com/en-us/azure/firewall/dnat-rules) Für diese Seite wurden keine Community-Beiträge oder Hersteller-Social-Media-Aussagen als fachlicher Nachweis verwendet.