# 12. Sniffing, Analyse und Fehlersuche # 12.1 Sniffing, Paketmitschnitt und Netzwerkanalyse Sniffing bedeutet: Netzwerkverkehr mitschneiden und analysieren. Dabei werden Datenpakete sichtbar gemacht, damit man verstehen kann, was im Netzwerk wirklich passiert. Typische Werkzeuge sind: - Wireshark - tcpdump - tshark - Packet Capture auf Firewalls - Switch-Port-Mirroring - Browser-Entwicklertools - Logdateien als Ergänzung Merksatz: Sniffing zeigt den tatsächlichen Netzwerkverkehr. --- **Warum nutzt man Paketmitschnitte?** Ein Paketmitschnitt hilft, wenn normale Fehlermeldungen nicht ausreichen. Man kann damit prüfen: Kommt ein Paket überhaupt an? Antwortet das Zielsystem? Wird DNS korrekt gefragt? Findet ein TCP-Handshake statt? Gibt es Wiederholungen? Gibt es Timeouts? Wird die Verbindung aktiv abgelehnt? Wird TLS aufgebaut? Werden DHCP-Pakete gesendet? Gibt es ARP-Probleme? Merksatz: Paketmitschnitt hilft, Vermutungen durch echte Daten zu ersetzen. --- **Sniffing ist nicht immer erlaubt** Netzwerkverkehr kann sensible Informationen enthalten. Beispiele: - Benutzernamen - Passwörter - Cookies - Tokens - E-Mail-Inhalte - interne IP-Adressen - Kundendaten - personenbezogene Daten - vertrauliche Kommunikation Deshalb gilt: Paketmitschnitte nur mit Erlaubnis, Zweckbindung und möglichst begrenztem Umfang durchführen. Merksatz: Sniffing ist technisch hilfreich, aber datenschutz- und sicherheitsrelevant. --- **Was sieht man in einem Paketmitschnitt?** In einem Paketmitschnitt sieht man je nach Protokoll: - Quell-MAC-Adresse - Ziel-MAC-Adresse - Quell-IP-Adresse - Ziel-IP-Adresse - Protokoll - Quellport - Zielport - Flags - Paketgröße - Zeitstempel - DNS-Anfragen - TCP-Handshake - TLS-Handshake - unverschlüsselte Nutzdaten Bei verschlüsselten Verbindungen sieht man den Inhalt nicht einfach im Klartext. Merksatz: Metadaten sind oft sichtbar, Inhalte bei TLS meist nicht. --- **OSI-Schichten im Paketmitschnitt** Ein Paketmitschnitt zeigt mehrere OSI-Schichten gleichzeitig. | Sichtbarer Bereich | OSI-Schicht | |---|---:| | MAC-Adressen | 2 | | VLAN-Tags | 2 | | IP-Adressen | 3 | | ICMP | 3 | | TCP / UDP | 4 | | Ports | 4 | | TLS-Handshake | 6 / 7-Bezug | | DNS, HTTP, DHCP, SMTP | 7 | Merksatz: Paketmitschnitt verbindet die Schichten sichtbar miteinander. --- **Wireshark** Wireshark ist ein grafisches Werkzeug zur Analyse von Netzwerkpaketen. Es zeigt Pakete übersichtlich mit: - Paketliste - Paketdetails - Rohdaten - Protokollauswertung - Filtern - Zeitinformationen - Verbindungsübersichten Wireshark eignet sich besonders gut, um Protokolle Schritt für Schritt zu verstehen. Merksatz: Wireshark macht Netzwerkverkehr sichtbar und lesbar. --- **tcpdump** tcpdump ist ein Kommandozeilenwerkzeug für Paketmitschnitte. Es wird häufig auf Linux, Unix, Firewalls, Servern oder Netzwerkgeräten verwendet. Vorteile: - schnell - leicht auf Servern nutzbar - gut für SSH-Sitzungen - kann Mitschnitte als Datei speichern - gut für gezielte Filter Merksatz: tcpdump ist Paketmitschnitt auf der Kommandozeile. --- **tshark** tshark ist die Kommandozeilenversion von Wireshark. Es kann Pakete aufzeichnen, filtern und Protokolldaten ausgeben. Typische Nutzung: - Analyse auf Servern - automatisierte Auswertung - schnelle Suche in Mitschnitten - Export bestimmter Felder Merksatz: tshark bringt Wireshark-Funktionen auf die Kommandozeile. --- **Packet Capture auf Firewalls** Viele Firewalls bieten eine eingebaute Paketmitschnittfunktion. Vorteil: Man sieht, ob Pakete an der Firewall ankommen und auf welchem Interface sie erscheinen. Das ist hilfreich bei: - NAT-Problemen - Routingproblemen - DMZ-Verkehr - VPN-Problemen - Firewall-Regelprüfung - asymmetrischem Routing Merksatz: Mitschnitt auf der Firewall zeigt, was die Firewall wirklich sieht. --- **Switch-Port-Mirroring** Ein Switch leitet normalerweise nur relevante Frames an den passenden Port weiter. Damit ein Analysegerät trotzdem Verkehr anderer Ports sehen kann, nutzt man: Port Mirroring oder: SPAN-Port Dabei wird Verkehr von einem oder mehreren Ports auf einen Analyseport kopiert. Merksatz: Port Mirroring kopiert Verkehr zu einem Analyseport. --- **Warum sieht man nicht automatisch alles?** In geswitchten Netzwerken sieht ein normaler Client nicht den gesamten Verkehr. Er sieht hauptsächlich: - eigenen Verkehr - Broadcasts - Multicasts - bestimmte lokale Pakete Er sieht normalerweise nicht: den gesamten Verkehr anderer Clients Dafür braucht man Port Mirroring, Mitschnitt am Zielsystem oder Mitschnitt an einer Firewall. Merksatz: In geswitchten Netzen sieht man ohne Mirror nicht alles. --- **Promiscuous Mode** Promiscuous Mode bedeutet: Die Netzwerkkarte nimmt auch Frames an, die nicht direkt an ihre eigene MAC-Adresse gerichtet sind. Das ist für Sniffing hilfreich. Aber: In geswitchten Netzwerken reicht Promiscuous Mode allein nicht, um fremden Verkehr zu sehen. Merksatz: Promiscuous Mode hilft, ersetzt aber kein Port Mirroring. --- **Capture Filter und Display Filter** Bei Wireshark und tcpdump gibt es unterschiedliche Filterarten. Capture Filter: bestimmen, was überhaupt aufgezeichnet wird. Display Filter: bestimmen, was nachträglich angezeigt wird. Beispiel: Capture Filter: nur Verkehr zu Host 192.168.10.20 mitschneiden Display Filter: im vorhandenen Mitschnitt nur DNS anzeigen Merksatz: Capture Filter begrenzt Aufnahme. Display Filter begrenzt Anzeige. --- **Capture Filter** Capture Filter werden vor oder während der Aufnahme angewendet. Vorteil: kleinere Dateien weniger Daten bessere Übersicht weniger sensible Daten Nachteil: was nicht aufgezeichnet wurde, kann man später nicht analysieren. Merksatz: Capture Filter nur setzen, wenn klar ist, was benötigt wird. --- **Display Filter** Display Filter werden nach der Aufnahme angewendet. Vorteil: alle Daten bleiben erhalten Ansicht kann beliebig eingegrenzt werden ideal für Analyse Beispiele für Filterideen: nur eine IP-Adresse nur DNS nur TCP-Fehler nur HTTP nur Pakete mit Reset Merksatz: Display Filter sind sicherer für Analyse, weil die Rohdaten erhalten bleiben. --- **Wichtige Filtergedanken** Typische Fragen: Welche IP-Adresse interessiert mich? Welcher Port interessiert mich? Welches Protokoll interessiert mich? Welche Richtung interessiert mich? Welche Fehlermeldung sehe ich? Welche Zeitspanne ist relevant? Beispiele: Verkehr eines bestimmten Hosts DNS-Anfragen TCP-Verbindungen zu Port 443 ICMP-Pakete DHCP-DORA ARP-Anfragen Merksatz: Gute Filter entstehen aus einer klaren Fragestellung. --- **MAC-Adressen im Mitschnitt** MAC-Adressen gehören zu OSI-Schicht 2. Sie zeigen, welche Geräte im lokalen Netzwerksegment miteinander kommunizieren. Wichtig: MAC-Adressen ändern sich bei jedem Routing-Hop. Ein Paket zum Internet hat im LAN als Ziel-MAC nicht den Webserver im Internet, sondern die MAC-Adresse des Standard-Gateways. Merksatz: Im lokalen Netz ist die Ziel-MAC oft das Gateway. --- **IP-Adressen im Mitschnitt** IP-Adressen gehören zu OSI-Schicht 3. Sie zeigen: Quell-IP Ziel-IP Bei NAT können sich IP-Adressen ändern. Beispiel: vor NAT: private Client-IP nach NAT: öffentliche Firewall-IP Merksatz: IP-Adressen zeigen logische Endpunkte, können durch NAT geändert werden. --- **Ports im Mitschnitt** Ports gehören zu OSI-Schicht 4. Sie zeigen, welcher Dienst angesprochen wird. Beispiel: Zielport TCP 443: typischerweise HTTPS Zielport TCP 22: typischerweise SSH Zielport UDP 53: typischerweise DNS Merksatz: Ports helfen, Dienste zu erkennen. --- **Quellport und Zielport** Bei Client-Server-Verbindungen nutzt der Client meist einen temporären Quellport. Beispiel: Client: 192.168.10.50:53124 Server: 203.0.113.10:443 Dabei ist: 53124 = temporärer Quellport 443 = Zielport des Dienstes Merksatz: Der bekannte Dienstport ist meistens der Zielport beim Server. --- **TCP-Handshake im Mitschnitt** TCP baut eine Verbindung mit drei Schritten auf: SYN SYN-ACK ACK Im Mitschnitt sieht man dadurch, ob eine TCP-Verbindung zustande kommt. | Beobachtung | mögliche Bedeutung | |---|---| | SYN, SYN-ACK, ACK | Verbindung aufgebaut | | nur SYN-Wiederholungen | keine Antwort, Firewall oder Routingproblem | | SYN, RST | Ziel lehnt aktiv ab | | SYN, SYN-ACK, danach kein ACK | Rückweg oder Clientproblem | | viele Retransmissions | Paketverlust oder Blockierung | Merksatz: TCP-Handshake ist einer der wichtigsten Hinweise im Mitschnitt. --- **TCP SYN** SYN bedeutet: Client möchte eine TCP-Verbindung starten. Wenn man nur SYN-Pakete sieht, aber keine Antwort, kann das bedeuten: Ziel antwortet nicht. Firewall blockiert. Rückweg fehlt. Ziel-IP ist falsch. Dienst ist nicht erreichbar. Routing stimmt nicht. Merksatz: Nur SYN ohne Antwort deutet auf keine erreichbare Antwort hin. --- **TCP SYN-ACK** SYN-ACK bedeutet: Server akzeptiert den Verbindungsaufbau grundsätzlich und antwortet. Wenn SYN-ACK ankommt, ist der Zielport grundsätzlich erreichbar. Danach muss der Client mit ACK bestätigen. Merksatz: SYN-ACK zeigt: Ziel hat auf TCP-Verbindungsversuch geantwortet. --- **TCP ACK** ACK bestätigt empfangene Daten oder Verbindungsaufbau. ACKs sind normaler Bestandteil von TCP. Sie zeigen, dass Pakete angekommen sind und die Verbindung fortgesetzt werden kann. Merksatz: ACK bestätigt Empfang. --- **TCP RST** RST steht für: Reset Ein RST beendet oder verweigert eine Verbindung aktiv. Mögliche Ursachen: - Dienst läuft nicht - Port geschlossen - Anwendung lehnt ab - Firewall sendet Reset - falsches Protokoll auf Port - Verbindung wird abgebrochen Merksatz: RST = aktive Ablehnung oder Abbruch. --- **TCP Retransmission** Retransmission bedeutet: TCP sendet ein Paket erneut. Grund: keine Bestätigung erhalten Mögliche Ursachen: - Paketverlust - Firewall blockiert Pakete - Überlastung - schlechter Link - Rückwegproblem - Ziel antwortet nicht Merksatz: Retransmissions deuten auf verlorene oder unbeantwortete Pakete hin. --- **TCP Window** TCP Window beschreibt, wie viele Daten empfangen werden können, bevor eine Bestätigung nötig ist. Wenn das Fenster sehr klein oder null wird, kann das auf Leistungsprobleme hindeuten. Beispiel: Empfänger kann nicht schnell genug verarbeiten. Merksatz: TCP Window betrifft Flusskontrolle und Leistung. --- **UDP im Mitschnitt** UDP hat keinen Verbindungsaufbau wie TCP. Es gibt keinen SYN, kein SYN-ACK und kein ACK für den Verbindungsaufbau. Bei UDP prüft man: Wird Anfrage gesendet? Kommt Antwort zurück? Gibt es ICMP-Fehler? Wird der richtige Port genutzt? Merksatz: UDP ist verbindungslos, deshalb sieht man keinen Handshake. --- **ICMP im Mitschnitt** ICMP gehört zu Schicht 3. Es wird genutzt für: - Ping - Ziel nicht erreichbar - Time Exceeded - Fragmentierung nötig - Diagnosemeldungen ICMP-Meldungen können wichtige Hinweise geben. Beispiel: Destination Unreachable Merksatz: ICMP liefert oft Hinweise auf Netzwerkprobleme. --- **ARP im Mitschnitt** ARP gehört zur lokalen IPv4-Kommunikation. ARP fragt: Welche MAC-Adresse gehört zu dieser IPv4-Adresse? Beispiel: Wer hat 192.168.10.1? Antwort: 192.168.10.1 ist bei MAC-Adresse xx:xx:xx:xx:xx:xx Merksatz: ARP löst IPv4-Adresse zu MAC-Adresse im lokalen Netz auf. --- **ARP-Probleme erkennen** Typische Hinweise: viele ARP-Anfragen ohne Antwort falsche MAC-Adresse doppelte IP-Adresse Gateway antwortet nicht Client fragt falsches Ziel direkt Mögliche Ursachen: - Ziel nicht im lokalen Netz - falsche Netzmaske - falsches Gateway - VLAN falsch - IP-Konflikt - Gerät offline Merksatz: ARP-Probleme zeigen oft lokale Layer-2- oder Layer-3-Fehler. --- **DNS im Mitschnitt** DNS ist häufig sehr gut im Mitschnitt erkennbar. Man sieht: welche Namen gefragt werden welcher DNS-Server gefragt wird welche Antwort zurückkommt ob A- oder AAAA-Records angefragt werden ob NXDOMAIN zurückkommt ob Antwort verzögert ist Merksatz: DNS-Mitschnitt zeigt, welcher Name wirklich wohin aufgelöst wird. --- **DHCP im Mitschnitt** DHCP kann man im Mitschnitt gut erkennen. Der klassische Ablauf: Discover Offer Request Acknowledge Fehlerbilder: Discover ohne Offer: DHCP-Server oder Relay antwortet nicht. Offer kommt, aber kein Ack: Anfrage oder Serverbestätigung gestört. falsche Optionen: Gateway oder DNS falsch verteilt. Merksatz: DHCP-DORA ist im Mitschnitt gut nachvollziehbar. --- **TLS im Mitschnitt** Bei TLS sieht man normalerweise nicht den verschlüsselten Inhalt. Man sieht aber oft: TLS-Version Server Name Indication Zertifikatsinformationen Cipher-Aushandlung Handshake-Fehler Verbindungsabbrüche Wichtig: Der Inhalt von HTTPS bleibt ohne Entschlüsselung geschützt. Merksatz: TLS versteckt Inhalte, aber der Handshake liefert Hinweise. --- **SNI im Mitschnitt** SNI steht für: Server Name Indication Der Client teilt beim TLS-Aufbau mit, welchen Hostnamen er erreichen möchte. Das ist wichtig, wenn mehrere HTTPS-Dienste auf derselben IP laufen. Beispiel: wiki.firma.de cloud.firma.de git.firma.de alle über: dieselbe IP und TCP 443 Merksatz: SNI zeigt den gewünschten TLS-Hostnamen. --- **HTTP im Mitschnitt** Unverschlüsseltes HTTP kann im Mitschnitt direkt gelesen werden. Man sieht zum Beispiel: Methode Pfad Host-Header Statuscode Header teilweise Inhalte Bei HTTPS sieht man diese Inhalte normalerweise nicht, weil sie verschlüsselt sind. Merksatz: HTTP ist lesbar, HTTPS schützt den Inhalt. --- **FTP und Telnet im Mitschnitt** FTP und Telnet können unverschlüsselte Inhalte übertragen. Bei klassischem FTP können sichtbar sein: Benutzername Passwort Befehle Dateiinhalte Bei Telnet können sichtbar sein: Login Passwort Befehle Merksatz: Unverschlüsselte Protokolle sind im Mitschnitt gefährlich sichtbar. --- **SMB im Mitschnitt** SMB-Verkehr kann Hinweise liefern bei: Zugriff verweigert Verbindungsproblemen Namensproblemen Protokollversionsproblemen Dateioperationen Authentifizierungsproblemen Wichtig: Moderne SMB-Kommunikation kann teilweise signiert oder verschlüsselt sein. Merksatz: SMB-Mitschnitte helfen bei Freigabe- und Rechteproblemen. --- **Zeitstempel im Mitschnitt** Zeitstempel zeigen, wann Pakete gesendet oder empfangen wurden. Sie helfen bei: Timeouts Verzögerungen Wiederholungen langsamen Antworten Reihenfolge von Ereignissen Wichtig: Systemzeit des Analysegeräts sollte korrekt sein. Merksatz: Ohne korrekte Zeit sind Mitschnitte schwerer auszuwerten. --- **Paketgröße** Die Paketgröße kann Hinweise geben. Beispiele: sehr kleine Pakete: Steuerinformationen, ACKs, Handshake große Pakete: Datenübertragung fragmentierte Pakete: MTU- oder Fragmentierungsthemen möglich Merksatz: Paketgrößen können Leistungs- oder MTU-Probleme sichtbar machen. --- **MTU-Probleme im Mitschnitt** MTU steht für: Maximum Transmission Unit MTU-Probleme können auftreten, wenn Pakete zu groß sind und Fragmentierung nicht richtig funktioniert. Typische Hinweise: Verbindungen bauen auf, aber größere Datenübertragungen hängen. Webseiten laden teilweise. VPN-Verbindungen haben Probleme. ICMP Fragmentation Needed fehlt oder wird blockiert. Merksatz: MTU-Probleme zeigen sich oft erst bei größeren Paketen. --- **Wo sollte man mitschneiden?** Der Ort des Mitschnitts ist entscheidend. Mögliche Stellen: Client Server Firewall WAN Firewall LAN Firewall DMZ Switch Mirror Port Router VPN-Gateway Reverse Proxy Je nach Stelle sieht man unterschiedliche Informationen. Merksatz: Der Mitschnittort entscheidet, was man sehen kann. --- **Clientseitiger Mitschnitt** Ein Mitschnitt am Client zeigt: was der Client wirklich sendet welche DNS-Anfragen gestellt werden welche IP erreicht wird ob Antwort zurückkommt welche Fehlversuche entstehen Gut bei: Einzelclient-Problemen DNS-Problemen Browserproblemen VPN-Clientproblemen Merksatz: Client-Mitschnitt zeigt die Sicht des Clients. --- **Serverseitiger Mitschnitt** Ein Mitschnitt am Server zeigt: ob Anfragen beim Server ankommen von welcher IP sie ankommen auf welchem Port sie ankommen ob der Server antwortet ob die Host-Firewall beteiligt sein könnte Gut bei: Dienstproblemen Firewallverdacht NAT-Fragen Rückwegproblemen Merksatz: Server-Mitschnitt zeigt, ob der Dienst wirklich erreicht wird. --- **Firewall-Mitschnitt** Ein Mitschnitt auf der Firewall zeigt: kommt Verkehr auf WAN an? wird Verkehr nach NAT weitergeleitet? kommt Antwort zurück? auf welchem Interface erscheint Verkehr? wird Rückverkehr sichtbar? Gut bei: NAT DMZ VPN Routing Portweiterleitung asymmetrischem Routing Merksatz: Firewall-Mitschnitt zeigt den Übergang zwischen Zonen. --- **Mehrere Mitschnitte vergleichen** Manchmal braucht man Mitschnitte an mehreren Stellen. Beispiel: Client sendet SYN. Firewall WAN sieht SYN. Firewall DMZ sieht weitergeleitetes SYN. Server sieht kein SYN. Dann liegt das Problem zwischen Firewall und Server. Oder: Server antwortet. Firewall sieht Antwort. Client sieht Antwort nicht. Dann Rückweg oder Filter prüfen. Merksatz: Mehrere Mitschnitte zeigen, wo Pakete verschwinden. --- **Paketmitschnitt und Logs kombinieren** Paketmitschnitte zeigen Verkehr. Logs zeigen Entscheidungen und Anwendungszustände. Beispiele: Firewall-Log: Paket wurde blockiert. Webserver-Log: Anfrage kam an und erzeugte 500. Auth-Log: Anmeldung wurde abgelehnt. Paketmitschnitt: TCP-Verbindung wurde aufgebaut. Merksatz: Mitschnitt und Logs ergänzen sich. --- **Typische Analysefragen** Bei einem Paketmitschnitt fragt man: Sehe ich überhaupt Pakete? Sehe ich die richtige Quelle? Sehe ich das richtige Ziel? Sehe ich den richtigen Port? Sehe ich DNS vorher? Sehe ich einen TCP-Handshake? Sehe ich Reset oder Timeout? Sehe ich TLS-Handshake? Sehe ich Antwortpakete? Sehe ich Wiederholungen? Sehe ich ICMP-Fehler? Passt die Richtung? Merksatz: Mitschnitt immer mit konkreter Frage auswerten. --- **Typisches Fehlerbild: Nur SYN-Wiederholungen** Wenn man nur SYN-Pakete sieht, aber keine SYN-ACK-Antwort, kann das bedeuten: Ziel nicht erreichbar Firewall droppt falsche Ziel-IP Routingproblem Rückweg fehlt Dienst oder Host antwortet nicht NAT falsch Merksatz: Nur SYN-Wiederholungen deuten auf fehlende Antwort hin. --- **Typisches Fehlerbild: RST nach SYN** Wenn auf ein SYN direkt ein RST kommt, kann das bedeuten: Port geschlossen Dienst läuft nicht Host lehnt Verbindung ab Firewall lehnt aktiv ab falscher Zielport Merksatz: RST nach SYN heißt: Verbindung wird aktiv abgelehnt. --- **Typisches Fehlerbild: DNS NXDOMAIN** NXDOMAIN bedeutet: Name existiert nicht. Mögliche Ursachen: falscher Name DNS-Zone fehlt Tippfehler interner DNS nicht genutzt falscher Suchsuffix Split DNS falsch Merksatz: NXDOMAIN heißt: DNS kennt diesen Namen nicht. --- **Typisches Fehlerbild: DHCP Discover ohne Offer** Wenn ein Client DHCP Discover sendet, aber kein Offer erhält, kann das bedeuten: DHCP-Server nicht erreichbar DHCP-Relay fehlt VLAN falsch DHCP-Server down Firewall blockiert Scope voll falsches Netzwerk Merksatz: Discover ohne Offer: Client findet keinen antwortenden DHCP-Server. --- **Typisches Fehlerbild: TLS Alert** Ein TLS Alert zeigt, dass der TLS-Aufbau ein Problem hat. Mögliche Ursachen: Zertifikatproblem falscher Hostname inkompatible TLS-Version inkompatible Cipher Suite Client oder Server bricht ab mTLS-Zertifikat fehlt Merksatz: TLS Alert deutet auf Problem im TLS-Handshake hin. --- **Typisches Fehlerbild: Viele Retransmissions** Viele Retransmissions können bedeuten: Paketverlust Überlastung Firewall blockiert einzelne Pakete Rückwegproblem WLAN-Probleme MTU-Probleme schlechte Verbindung Merksatz: Viele Wiederholungen zeigen, dass Bestätigungen fehlen. --- **Typisches Fehlerbild: ARP ohne Antwort** ARP-Anfragen ohne Antwort können bedeuten: Ziel ist nicht im lokalen Netz Ziel ist offline VLAN falsch falsche IP-Adresse falsche Netzmaske Gateway nicht erreichbar IP-Konflikt Merksatz: ARP ohne Antwort zeigt lokale Erreichbarkeitsprobleme. --- **Sicherheit beim Speichern von Mitschnitten** Paketmitschnitte können sensible Daten enthalten. Deshalb: nur notwendige Dauer mitschneiden Filter nutzen Dateien sicher speichern Zugriff beschränken Mitschnitte nach Zweck löschen keine Mitschnitte unnötig weitergeben personenbezogene Daten beachten Merksatz: Mitschnittdateien wie sensible Daten behandeln. --- **PCAP-Dateien** Paketmitschnitte werden häufig als PCAP oder PCAPNG gespeichert. Diese Dateien können später geöffnet und analysiert werden. Vorteile: - spätere Analyse möglich - Weitergabe an Fachabteilung möglich - Vergleich mit Logs möglich - Dokumentation eines Fehlerfalls Achtung: PCAP-Dateien können vertrauliche Informationen enthalten. Merksatz: PCAP ist praktisch, aber sensibel. --- **Was ein Paketmitschnitt nicht automatisch liefert** Ein Paketmitschnitt zeigt nicht automatisch: warum ein Benutzer keine Berechtigung hat warum eine Anwendung intern Fehler wirft warum ein Passwort falsch ist warum ein Serverprozess abgestürzt ist welche Firewall-Regel intern entschieden hat ob ein Zertifikat fachlich richtig beantragt wurde Dafür braucht man zusätzlich: Logs Konfiguration Berechtigungsprüfung Dienststatus Fachwissen Merksatz: Paketmitschnitt zeigt Verkehr, aber nicht jede Ursache. --- **Typische IHK-Fragen** In AP1 und AP2 kann zum Beispiel gefragt werden: - Was versteht man unter Sniffing? - Wofür nutzt man einen Paketmitschnitt? - Was ist Wireshark? - Was ist tcpdump? - Was ist Port Mirroring? - Warum sieht man in einem geswitchten Netzwerk nicht automatisch allen Verkehr? - Was ist der Unterschied zwischen Capture Filter und Display Filter? - Was sieht man bei einem TCP-Handshake? - Was bedeuten SYN, SYN-ACK und ACK? - Was bedeutet TCP Reset? - Was bedeuten Retransmissions? - Warum sieht man bei HTTPS den Inhalt nicht einfach im Klartext? - Was kann man bei DNS im Mitschnitt erkennen? - Was zeigt DHCP-DORA im Mitschnitt? - Warum sind Paketmitschnitte sensibel? --- **Typische Prüfungsfallen** Sniffing zeigt echten Netzwerkverkehr. Sniffing ist datenschutzrelevant. Wireshark ist grafisch. tcpdump ist Kommandozeile. In geswitchten Netzen sieht man nicht automatisch alles. Port Mirroring kopiert Verkehr auf Analyseport. Promiscuous Mode allein reicht im Switch-Netz oft nicht. Capture Filter begrenzt Aufnahme. Display Filter begrenzt Anzeige. Was nicht aufgezeichnet wurde, kann später nicht analysiert werden. TCP hat Handshake. UDP hat keinen Handshake. SYN startet TCP-Verbindung. SYN-ACK ist Serverantwort. ACK bestätigt. RST lehnt ab oder beendet. Retransmission bedeutet erneutes Senden. TLS schützt Inhalte. HTTP ist lesbar, HTTPS normalerweise nicht. FTP und Telnet sind im Mitschnitt gefährlich sichtbar. Mitschnittort ist entscheidend. Logs und Mitschnitt ergänzen sich. --- **Wichtige Begriffe kurz erklärt** | Begriff | Kurze Erklärung | |---|---| | Sniffing | Mitschneiden von Netzwerkverkehr | | Paketmitschnitt | Aufzeichnung von Paketen | | Wireshark | grafisches Analysewerkzeug | | tcpdump | Kommandozeilenwerkzeug für Mitschnitte | | tshark | Wireshark auf Kommandozeile | | PCAP | Datei mit Paketmitschnitt | | Port Mirroring | Kopieren von Switch-Verkehr auf Analyseport | | SPAN | Port-Mirroring-Begriff bei Switches | | Promiscuous Mode | Netzwerkkarte nimmt fremde Frames an | | Capture Filter | Filter vor der Aufnahme | | Display Filter | Filter für Anzeige nach Aufnahme | | SYN | TCP-Verbindungsstart | | SYN-ACK | TCP-Antwort des Servers | | ACK | Bestätigung | | RST | Reset, aktive Ablehnung oder Abbruch | | Retransmission | erneutes Senden eines Pakets | | ARP | IPv4-Adresse zu MAC-Adresse | | ICMP | Diagnose- und Fehlermeldungsprotokoll | | SNI | Hostname im TLS-Handshake | | TLS Alert | Fehlermeldung im TLS-Handshake | | NXDOMAIN | DNS-Name existiert nicht | | DORA | DHCP Discover, Offer, Request, Acknowledge | --- **IHK-sichere Kurzformulierung** Sniffing bezeichnet das Mitschneiden und Analysieren von Netzwerkverkehr. Mit Werkzeugen wie Wireshark, tcpdump oder Paketmitschnitten auf Firewalls kann geprüft werden, welche Pakete tatsächlich gesendet und empfangen werden. Dabei lassen sich unter anderem MAC-Adressen, IP-Adressen, Ports, Protokolle, TCP-Handshakes, DNS-Anfragen, DHCP-Abläufe, ICMP-Meldungen, TLS-Handshakes und Wiederholungen erkennen. In geswitchten Netzwerken sieht ein Client nicht automatisch den gesamten Verkehr; dafür ist häufig Port Mirroring oder ein Mitschnitt an der richtigen Stelle nötig. Paketmitschnitte können sensible Daten enthalten und müssen deshalb sorgfältig und nur mit berechtigtem Zweck eingesetzt werden. --- **Merksätze** Sniffing = Netzwerkverkehr mitschneiden. Paketmitschnitt zeigt echten Verkehr. Wireshark ist grafisch. tcpdump ist Kommandozeile. tshark ist Wireshark für die Kommandozeile. PCAP-Dateien enthalten Mitschnitte. Mitschnitte können sensible Daten enthalten. In geswitchten Netzen sieht man nicht automatisch alles. Port Mirroring kopiert Verkehr. Promiscuous Mode reicht allein oft nicht. Capture Filter begrenzt Aufnahme. Display Filter begrenzt Anzeige. Mitschnittort ist entscheidend. MAC-Adressen gehören zu Schicht 2. IP-Adressen gehören zu Schicht 3. Ports gehören zu Schicht 4. DNS gehört zu Schicht 7. TCP hat Handshake. UDP hat keinen Handshake. SYN startet TCP-Verbindung. SYN-ACK antwortet. ACK bestätigt. RST lehnt ab oder beendet. Retransmission bedeutet erneutes Senden. ARP löst IPv4 zu MAC auf. ICMP liefert Diagnosehinweise. DHCP-DORA ist im Mitschnitt sichtbar. TLS schützt Inhalte. HTTP ist lesbar. HTTPS ist normalerweise nicht lesbar. FTP und Telnet sind unsicher, weil Inhalte sichtbar sein können. Logs und Paketmitschnitt zusammen auswerten. # 12.2 Wireshark-Analyse: Filter, Protokolle und typische Fehlerbilder Wireshark ist ein grafisches Werkzeug zur Analyse von Netzwerkverkehr. Mit Wireshark kann man Paketmitschnitte öffnen, filtern und auswerten. Ziel ist nicht nur: Pakete sehen Sondern: Verstehen, was im Netzwerk wirklich passiert. Merksatz: Wireshark zeigt Pakete, aber die Analyse entsteht durch gezielte Fragen. --- **Grundidee der Wireshark-Analyse** Ein Paketmitschnitt kann sehr viele Daten enthalten. Ohne Filter ist die Analyse schnell unübersichtlich. Deshalb arbeitet man mit Fragen: Welche IP-Adresse interessiert mich? Welcher Dienst funktioniert nicht? Welcher Port wird genutzt? Gibt es DNS-Anfragen? Gibt es einen TCP-Handshake? Gibt es Timeouts? Gibt es Reset-Pakete? Gibt es TLS-Fehler? Kommt eine Antwort zurück? Merksatz: Erst Fragestellung, dann Filter. --- **Wireshark-Oberfläche** Wireshark zeigt typischerweise drei Bereiche: | Bereich | Bedeutung | |---|---| | Paketliste | alle aufgezeichneten Pakete als Übersicht | | Paketdetails | aufgeschlüsselte Protokollinformationen | | Paketbytes | Rohdaten des Pakets | Die Paketliste zeigt zum Beispiel: Zeit Quelle Ziel Protokoll Länge Information Merksatz: Paketliste zeigt Überblick, Paketdetails zeigen Inhalt. --- **Paketliste** In der Paketliste sieht man jedes Paket als Zeile. Wichtige Spalten: No. Time Source Destination Protocol Length Info Diese Spalten helfen, den Ablauf der Kommunikation zu verstehen. Merksatz: Die Paketliste zeigt die zeitliche Reihenfolge der Pakete. --- **Paketdetails** Die Paketdetails zeigen, welche Protokollschichten im Paket enthalten sind. Beispiele: Frame Ethernet IPv4 oder IPv6 TCP oder UDP TLS HTTP DNS DHCP Damit kann man sehen, welche Schichten beteiligt sind. Merksatz: Paketdetails zeigen die Protokolle Schicht für Schicht. --- **Paketbytes** Die Paketbytes zeigen die Rohdaten des Pakets. Das ist besonders wichtig, wenn man sehr genau prüfen möchte, welche Daten wirklich übertragen wurden. Für die IHK reicht meist: verstehen, dass dies die Rohdaten sind. Merksatz: Paketbytes sind die technische Rohansicht. --- **Display Filter** Display Filter bestimmen, welche Pakete angezeigt werden. Sie ändern nicht die gespeicherte Aufzeichnung. Beispielgedanke: Zeige nur DNS. Zeige nur Pakete zu dieser IP. Zeige nur TCP-Resets. Zeige nur HTTP. Merksatz: Display Filter blenden aus, löschen aber nichts aus der Aufnahme. --- **Capture Filter** Capture Filter bestimmen, was überhaupt aufgezeichnet wird. Vorteil: weniger Daten kleinere Datei bessere Übersicht weniger sensible Informationen Nachteil: nicht aufgezeichnete Pakete sind später verloren. Merksatz: Capture Filter vor Aufnahme, Display Filter nach Aufnahme. --- **Capture Filter und Display Filter vergleichen** | Filterart | Zeitpunkt | Wirkung | |---|---|---| | Capture Filter | vor oder während Aufnahme | begrenzt, was aufgezeichnet wird | | Display Filter | nach Aufnahme | begrenzt nur die Anzeige | Merksatz: Capture Filter spart Daten. Display Filter hilft bei Analyse. --- **Wichtige Wireshark-Display-Filter** | Ziel | Filteridee | |---|---| | bestimmte IP anzeigen | ip.addr == 192.168.10.20 | | nur Quelle | ip.src == 192.168.10.20 | | nur Ziel | ip.dst == 192.168.10.20 | | bestimmter TCP-Port | tcp.port == 443 | | bestimmter UDP-Port | udp.port == 53 | | nur DNS | dns | | nur HTTP | http | | nur TLS | tls | | nur ARP | arp | | nur ICMP | icmp | | nur DHCP | dhcp | | nur TCP Reset | tcp.flags.reset == 1 | | nur TCP SYN | tcp.flags.syn == 1 | | TCP Retransmissions | tcp.analysis.retransmission | Merksatz: Display Filter müssen zur Fragestellung passen. --- **IP-Adresse filtern** Wenn ein bestimmter Host untersucht wird, filtert man nach dessen IP-Adresse. Beispiel: ip.addr == 192.168.10.20 Das zeigt Pakete, bei denen diese IP-Adresse Quelle oder Ziel ist. Merksatz: ip.addr zeigt Verkehr mit einer bestimmten IP. --- **Quelle und Ziel unterscheiden** Manchmal muss man genauer unterscheiden. Quelle: ip.src == 192.168.10.20 Ziel: ip.dst == 192.168.10.20 Das ist hilfreich, wenn man wissen will: Wer startet die Verbindung? Wer antwortet? Merksatz: ip.src = Quelle. ip.dst = Ziel. --- **Port filtern** Ports helfen, Dienste zu erkennen. Beispiel: tcp.port == 443 zeigt TCP-Verkehr, bei dem Port 443 als Quell- oder Zielport vorkommt. Genauer: tcp.dstport == 443 zeigt Pakete, die zu einem Dienst auf Port 443 gehen. Merksatz: Zielport zeigt meist den angesprochenen Dienst. --- **TCP und UDP getrennt betrachten** Portnummern allein reichen nicht. Beispiele: tcp.port == 443 ist nicht dasselbe wie: udp.port == 443 Das ist wichtig bei: HTTPS klassisch über TCP 443 HTTP/3 über UDP 443 DNS über UDP/TCP 53 Merksatz: Port immer mit TCP oder UDP betrachten. --- **DNS analysieren** DNS ist häufig der erste Schritt vor einer Verbindung. Mit Filter: dns sieht man DNS-Anfragen und Antworten. Wichtige Fragen: Welcher Name wird gefragt? Welcher DNS-Server wird gefragt? Welche IP-Adresse wird zurückgegeben? Kommt NXDOMAIN? Wird IPv4 oder IPv6 angefragt? Gibt es lange Antwortzeiten? Merksatz: DNS zeigt, wohin ein Name wirklich aufgelöst wird. --- **DNS A und AAAA** A-Record: Name zu IPv4-Adresse AAAA-Record: Name zu IPv6-Adresse Im Mitschnitt kann man sehen, ob ein Client IPv4, IPv6 oder beides anfragt. Fehlerfall: AAAA zeigt auf nicht erreichbare IPv6-Adresse, obwohl IPv4 funktionieren würde. Merksatz: DNS-Antworten können IPv4 und IPv6 betreffen. --- **DNS NXDOMAIN** NXDOMAIN bedeutet: Name existiert nicht. Mögliche Ursachen: - Tippfehler - falscher DNS-Suffix - falscher DNS-Server - interne Zone fehlt - Split DNS falsch - Name wurde nicht angelegt Merksatz: NXDOMAIN heißt: DNS kennt diesen Namen nicht. --- **TCP-Analyse** TCP-Verbindungen erkennt man am Handshake: SYN SYN-ACK ACK Mit Wireshark prüft man: Gibt es SYN? Kommt SYN-ACK zurück? Wird ACK gesendet? Gibt es RST? Gibt es Retransmissions? Gibt es Timeouts? Merksatz: TCP-Analyse beginnt oft beim Handshake. --- **TCP SYN filtern** Ein SYN startet eine TCP-Verbindung. Filteridee: tcp.flags.syn == 1 Achtung: SYN-ACK enthält ebenfalls SYN. Wenn man nur reine SYN-Pakete ohne ACK sehen möchte, braucht man sinngemäß: SYN gesetzt, ACK nicht gesetzt. Merksatz: SYN zeigt Verbindungsversuche. --- **TCP SYN-ACK erkennen** SYN-ACK ist die Antwort des Servers auf ein SYN. Bedeutung: Der Zielport antwortet grundsätzlich. Wenn SYN-ACK zurückkommt, ist der Weg zum Server und zurück zumindest für diesen Schritt vorhanden. Merksatz: SYN-ACK zeigt, dass der Server auf den TCP-Verbindungsaufbau antwortet. --- **TCP ACK erkennen** ACK bestätigt den Empfang. Nach SYN und SYN-ACK bestätigt der Client mit ACK. Dann ist der TCP-Verbindungsaufbau abgeschlossen. Merksatz: SYN, SYN-ACK, ACK = TCP-Verbindung aufgebaut. --- **TCP Reset erkennen** Ein Reset beendet oder verweigert eine Verbindung. Filter: tcp.flags.reset == 1 Mögliche Ursachen: - Port geschlossen - Dienst läuft nicht - Anwendung lehnt ab - Firewall sendet Reset - falsches Protokoll - Verbindung wird aktiv beendet Merksatz: RST ist eine aktive Ablehnung oder Beendigung. --- **TCP Retransmissions erkennen** Retransmissions sind erneute Übertragungen. Filteridee: tcp.analysis.retransmission Mögliche Ursachen: - Paketverlust - Firewall blockiert einzelne Pakete - WLAN-Probleme - Überlastung - Rückwegproblem - MTU-Problem Merksatz: Retransmissions bedeuten: Bestätigung fehlt oder Paket ging verloren. --- **TCP Zero Window** TCP Zero Window bedeutet: Empfänger kann aktuell keine weiteren Daten aufnehmen. Mögliche Ursachen: - Anwendung verarbeitet Daten zu langsam - Empfänger überlastet - Ressourcenproblem - System hängt Merksatz: Zero Window deutet auf Empfänger- oder Leistungsproblem hin. --- **TCP Dup ACK** Duplicate ACK bedeutet: Eine Bestätigung wird mehrfach gesendet. Das kann auf Paketverlust oder fehlende Segmente hinweisen. In Kombination mit Retransmissions kann es Netzwerkprobleme sichtbar machen. Merksatz: Duplicate ACK kann auf verlorene TCP-Segmente hindeuten. --- **UDP analysieren** UDP hat keinen Verbindungsaufbau. Bei UDP prüft man: Wird eine Anfrage gesendet? Kommt eine Antwort zurück? Gibt es ICMP-Fehler? Wird der richtige UDP-Port genutzt? Ist der Server erreichbar? Blockiert eine Firewall? Beispiele: DNS DHCP NTP SNMP VoIP HTTP/3 Merksatz: UDP hat keinen Handshake, deshalb muss man Anfrage und Antwort direkt prüfen. --- **ICMP analysieren** ICMP liefert Diagnoseinformationen. Wichtige ICMP-Meldungen: Echo Request Echo Reply Destination Unreachable Time Exceeded Fragmentation Needed ICMP kann Hinweise geben auf: Routingfehler blockierte Ziele MTU-Probleme Traceroute-Ablauf nicht erreichbare Netze Merksatz: ICMP-Fehler sind wichtige Hinweise, nicht nur Ping. --- **ARP analysieren** ARP wird im lokalen IPv4-Netz genutzt. Typische ARP-Frage: Wer hat diese IPv4-Adresse? Wenn viele ARP-Anfragen ohne Antwort sichtbar sind, kann das bedeuten: Ziel ist offline. falsches VLAN. falsche Netzmaske. Gateway nicht erreichbar. IP-Konflikt. falsche Adresse. Merksatz: ARP-Probleme sind lokale Netzwerkprobleme. --- **DHCP analysieren** DHCP erkennt man am Ablauf: Discover Offer Request Acknowledge Wichtige Fehlerbilder: | Beobachtung | mögliche Ursache | |---|---| | Discover ohne Offer | Server oder Relay antwortet nicht | | Offer kommt, aber kein Request | Client akzeptiert Angebot nicht | | Request ohne ACK | Server bestätigt nicht | | falsche Optionen | DHCP-Konfiguration falsch | | Client bekommt APIPA | DHCP fehlgeschlagen | Merksatz: DHCP-DORA ist im Mitschnitt gut prüfbar. --- **HTTP analysieren** Bei unverschlüsseltem HTTP sieht man: Methode URL-Pfad Host-Header Header Statuscode teilweise Inhalt Wichtige HTTP-Statuscodes: 200 OK 301 / 302 Weiterleitung 400 Bad Request 401 Unauthorized 403 Forbidden 404 Not Found 500 Internal Server Error 502 Bad Gateway 503 Service Unavailable 504 Gateway Timeout Merksatz: HTTP-Statuscodes helfen bei Schicht-7-Fehlersuche. --- **HTTPS analysieren** Bei HTTPS ist der Inhalt verschlüsselt. Man sieht normalerweise nicht: Pfad Formularinhalt Session-Cookie HTTP-Header Nutzdaten Man sieht aber häufig: Ziel-IP Port TLS-Handshake SNI Zertifikatsinformationen Verbindungsabbrüche TLS Alerts Merksatz: HTTPS schützt Inhalte, aber Verbindungsmetadaten bleiben sichtbar. --- **TLS-Handshake prüfen** Beim TLS-Handshake wird eine sichere Verbindung ausgehandelt. Im Mitschnitt können sichtbar sein: Client Hello Server Hello Zertifikat Cipher-Auswahl TLS-Version SNI TLS Alert Typische Fehler: Zertifikat passt nicht. TLS-Version passt nicht. Cipher Suite passt nicht. Client bricht ab. Server bricht ab. Merksatz: TLS-Handshake zeigt, ob HTTPS-Sicherheit ausgehandelt werden kann. --- **SNI prüfen** SNI steht für: Server Name Indication SNI zeigt, welchen Hostnamen der Client beim TLS-Aufbau anfordert. Das ist wichtig bei mehreren HTTPS-Diensten auf einer IP-Adresse. Beispiel: wiki.firma.de cloud.firma.de git.firma.de alle auf derselben IP und TCP 443. Merksatz: SNI hilft, den gewünschten HTTPS-Hostnamen zu erkennen. --- **Zertifikatsinformationen im Mitschnitt** Je nach TLS-Version und Situation können Zertifikatsinformationen sichtbar sein. Wichtig zu prüfen: Ausgestellt für welchen Namen? Aussteller? Gültigkeit? Zertifikatskette? Passt der Name zum Aufruf? Achtung: Bei modernen TLS-Versionen und bestimmten Verfahren sind nicht immer alle Informationen gleich sichtbar. Merksatz: Zertifikate geben Hinweise auf HTTPS-Probleme. --- **Follow TCP Stream** Wireshark kann zusammengehörende TCP-Daten anzeigen. Funktion: Follow TCP Stream Das ist hilfreich bei unverschlüsselten Protokollen. Beispiele: HTTP Telnet FTP SMTP ohne TLS Achtung: Bei verschlüsseltem HTTPS sieht man den Inhalt nicht im Klartext. Merksatz: Follow TCP Stream zeigt zusammenhängende TCP-Kommunikation. --- **Conversations** Wireshark kann Gespräche anzeigen. Conversations zeigen zum Beispiel: welche IPs miteinander gesprochen haben wie viele Pakete übertragen wurden wie viele Bytes übertragen wurden welche TCP-Verbindungen bestanden Das hilft, wichtige Verbindungen im Mitschnitt zu finden. Merksatz: Conversations zeigen, welche Systeme miteinander kommunizieren. --- **Endpoints** Endpoints zeigen beteiligte Kommunikationspartner. Beispiele: IP-Adressen MAC-Adressen Ports Das ist nützlich, um herauszufinden: welche Systeme im Mitschnitt aktiv sind wer besonders viel Verkehr erzeugt welche Ziele angesprochen werden Merksatz: Endpoints zeigen beteiligte Systeme. --- **IO Graphs** IO Graphs zeigen Netzwerkverkehr über Zeit. Damit erkennt man: Lastspitzen Pausen Übertragungsverlauf Wiederholungsmuster Zeitpunkte von Fehlern Das ist hilfreich bei Performanceproblemen. Merksatz: IO Graphs helfen, Verkehr zeitlich zu verstehen. --- **Expert Information** Wireshark bietet Expert Information. Dort werden auffällige Dinge gesammelt, zum Beispiel: Retransmissions Resets Malformed Packets Warnings Fehler Hinweise auf Protokollprobleme Wichtig: Expert Information ist hilfreich, aber nicht jede Warnung ist automatisch die Ursache. Merksatz: Expert Information ist Hinweis, nicht endgültiger Beweis. --- **Farben in Wireshark** Wireshark nutzt Farben, um Protokolle und Auffälligkeiten leichter sichtbar zu machen. Beispiele: DNS TCP Fehler Resets ARP Die genaue Farbe ist weniger wichtig als die technische Aussage. Merksatz: Farben helfen beim Überblick, ersetzen aber keine Analyse. --- **Namensauflösung in Wireshark** Wireshark kann IP-Adressen als Namen anzeigen. Das kann hilfreich sein, aber auch verwirren. Problem: angezeigter Name kann aus Cache, DNS oder lokaler Auflösung stammen. Für genaue Analyse ist oft besser: echte IP-Adressen anzeigen. Merksatz: Namensauflösung in Wireshark kann hilfreich, aber auch irreführend sein. --- **Zeitansicht** Wireshark kann Zeit unterschiedlich anzeigen. Beispiele: Zeit seit Beginn des Mitschnitts absolute Uhrzeit Zeit seit vorherigem Paket Zeit seit vorherigem angezeigten Paket Für Fehlersuche wichtig: Wie lange dauert die Antwort? Wann beginnt Timeout? Welche Pakete gehören zeitlich zusammen? Merksatz: Zeitdarstellung passend zur Analyse wählen. --- **Paketverlust erkennen** Hinweise auf Paketverlust: Retransmissions Duplicate ACKs fehlende Antworten lange Wartezeiten Verbindungsabbrüche wiederholte DNS-Anfragen wiederholte SYN-Pakete Mögliche Ursachen: WLAN-Probleme defekte Kabel Überlastung Firewall-Probleme Routingprobleme MTU-Probleme Merksatz: Paketverlust zeigt sich oft durch Wiederholungen. --- **MTU-Probleme erkennen** MTU-Probleme sind manchmal schwer zu erkennen. Typische Hinweise: kleine Verbindungen funktionieren große Datenübertragungen hängen TLS-Verbindungen brechen ab VPN-Verbindungen sind instabil Fragmentation Needed erscheint viele Retransmissions bei größeren Paketen Merksatz: Wenn kleine Pakete gehen, große aber nicht, an MTU denken. --- **Falsches Protokoll auf richtigem Port** Manchmal wird ein Dienst mit falschem Protokoll angesprochen. Beispiele: HTTPS-Anfrage an HTTP-Port HTTP-Anfrage an HTTPS-Port FTP statt SFTP LDAP statt LDAPS falsches Backend-Protokoll im Reverse Proxy Im Mitschnitt sieht man dann oft: Reset TLS Alert ungültige Antwort sofortiger Abbruch unerwartete Daten Merksatz: Richtiger Port reicht nicht, das Protokoll muss auch stimmen. --- **Firewall-Problem erkennen** Mögliche Hinweise auf Firewall-Probleme: SYN ohne Antwort ICMP unreachable keine Antwort trotz korrektem Ziel Verbindung geht aus einem Netz, aber nicht aus anderem Paket kommt an Firewall an, aber nicht am Ziel Firewall-Log zeigt Drop oder Deny Merksatz: Firewall-Probleme erkennt man am besten mit Mitschnitt plus Logs. --- **Dienstproblem erkennen** Hinweise auf Dienstproblem: TCP-Verbindung wird aufgebaut, danach kommt Fehler. Server sendet RST. HTTP 500. HTTP 503. Anwendung antwortet falsch. Login wird abgelehnt. Backend antwortet nicht. Dienst lauscht nicht auf erwartetem Port. Merksatz: Wenn TCP steht, aber Anwendung fehlschlägt, Schicht 7 prüfen. --- **DNS-Problem erkennen** Hinweise auf DNS-Probleme: keine DNS-Antwort falsche IP-Adresse NXDOMAIN falscher DNS-Server AAAA statt A problematisch interner Name wird extern gefragt Split DNS falsch DNS-Timeout Merksatz: DNS-Probleme sieht man oft vor dem eigentlichen Verbindungsversuch. --- **NAT-Problem erkennen** Hinweise auf NAT-Probleme: externe Anfrage kommt an, wird aber nicht intern sichtbar falsche Ziel-IP nach NAT falscher Port nach NAT Antwort kommt nicht zurück Quelladresse unerwartet interner Zugriff über öffentliche IP scheitert Firewall-Mitschnitt zeigt Übersetzung nicht Merksatz: NAT-Probleme erkennt man durch Vergleich vor und nach der Firewall. --- **Reverse-Proxy-Problem erkennen** Hinweise: Client bekommt 502. Client bekommt 504. Proxy antwortet, Backend aber nicht. TLS am Proxy funktioniert, interne Verbindung scheitert. Host-Header falsch. falsches Backend ausgewählt. DNS des Backends falsch. Merksatz: Reverse-Proxy-Fehler liegen oft zwischen Proxy und Backend. --- **Mehrere Mitschnittpunkte verwenden** Bei unklaren Problemen hilft ein Vergleich. Beispiel: Mitschnitt am Client: Anfrage wird gesendet. Mitschnitt an Firewall: Anfrage kommt an. Mitschnitt am Server: Anfrage kommt nicht an. Dann liegt das Problem zwischen Firewall und Server. Merksatz: Mehrere Mitschnittpunkte zeigen, wo Pakete verloren gehen. --- **Typische Analyse-Reihenfolge** Eine sinnvolle Reihenfolge: 1. Fehlerzeitpunkt bestimmen. 2. Richtige Schnittstelle wählen. 3. Mitschnitt starten. 4. Fehler reproduzieren. 5. Mitschnitt stoppen. 6. Nach beteiligter IP filtern. 7. DNS prüfen. 8. TCP- oder UDP-Verhalten prüfen. 9. TLS oder Anwendung prüfen. 10. Resets, Retransmissions und ICMP prüfen. 11. Logs vergleichen. 12. Ergebnis dokumentieren. Merksatz: Mitschnitt gezielt aufnehmen, Fehler nachstellen, dann filtern. --- **Typische Fehler bei der Analyse** Häufige Fehler sind: - auf falscher Schnittstelle mitschneiden - zu früh oder zu spät mitschneiden - falscher Filter - wichtigen Verkehr durch Capture Filter ausschließen - DNS nicht beachten - NAT nicht beachten - verschlüsselte Inhalte erwarten - jedes Wireshark-Warning überbewerten - Logs ignorieren - Uhrzeit nicht vergleichen Merksatz: Schlechter Mitschnitt kann zu falschen Schlussfolgerungen führen. --- **Datenschutz bei Wireshark** Wireshark-Mitschnitte können sensible Daten enthalten. Beispiele: - IP-Adressen - MAC-Adressen - Benutzernamen - Cookies - Tokens - interne Hostnamen - E-Mail-Inhalte - unverschlüsselte Passwörter - personenbezogene Daten Deshalb: nur so lange wie nötig mitschneiden nur relevanten Verkehr erfassen Zugriff auf PCAP-Dateien beschränken Mitschnitte sicher speichern Mitschnitte nach Zweck löschen Merksatz: Paketmitschnitte wie vertrauliche Daten behandeln. --- **Was Wireshark nicht automatisch löst** Wireshark zeigt Verkehr, aber nicht automatisch die Ursache. Man braucht zusätzlich: - Netzwerkwissen - Protokollverständnis - Logs - Konfigurationen - Dienststatus - Berechtigungsinformationen - Firewall-Regeln - DNS-Informationen Merksatz: Wireshark zeigt Hinweise, die Ursache muss man fachlich einordnen. --- **Typische IHK-Fragen** In AP1 und AP2 kann zum Beispiel gefragt werden: - Was ist Wireshark? - Wofür verwendet man Display Filter? - Wofür verwendet man Capture Filter? - Was ist der Unterschied zwischen Capture Filter und Display Filter? - Wie erkennt man einen TCP-Handshake? - Was bedeutet SYN? - Was bedeutet SYN-ACK? - Was bedeutet ACK? - Was bedeutet RST? - Was bedeuten Retransmissions? - Warum sieht man HTTPS-Inhalte nicht im Klartext? - Was kann man im TLS-Handshake trotzdem erkennen? - Was bedeutet NXDOMAIN? - Wie erkennt man DHCP-Probleme im Mitschnitt? - Warum ist der Mitschnittort wichtig? - Warum sind Paketmitschnitte datenschutzrelevant? --- **Typische Prüfungsfallen** Display Filter ändern nicht die Aufnahme. Capture Filter begrenzen die Aufnahme. Was nicht aufgezeichnet wurde, kann später nicht analysiert werden. ip.addr zeigt Quelle oder Ziel. ip.src zeigt nur Quelle. ip.dst zeigt nur Ziel. tcp.port und udp.port unterscheiden. TCP 443 ist nicht UDP 443. DNS kann UDP und TCP 53 nutzen. TCP hat Handshake. UDP hat keinen Handshake. SYN startet Verbindung. SYN-ACK ist Serverantwort. ACK bestätigt. RST ist aktive Ablehnung oder Abbruch. Retransmission bedeutet erneutes Senden. HTTPS-Inhalte sind verschlüsselt. TLS-Handshake kann trotzdem Hinweise geben. SNI zeigt gewünschten Hostnamen. Wireshark-Warnungen sind Hinweise, nicht automatisch Ursache. Mitschnittort ist entscheidend. PCAP-Dateien können sensible Daten enthalten. --- **Wichtige Begriffe kurz erklärt** | Begriff | Kurze Erklärung | |---|---| | Wireshark | grafisches Werkzeug zur Paketanalyse | | Paketliste | Übersicht aller Pakete | | Paketdetails | Protokollinformationen eines Pakets | | Paketbytes | Rohdaten eines Pakets | | Display Filter | Filter für Anzeige | | Capture Filter | Filter für Aufnahme | | ip.addr | IP-Adresse als Quelle oder Ziel | | ip.src | Quell-IP-Adresse | | ip.dst | Ziel-IP-Adresse | | tcp.port | TCP-Port als Quelle oder Ziel | | udp.port | UDP-Port als Quelle oder Ziel | | SYN | TCP-Verbindungsstart | | SYN-ACK | TCP-Antwort des Servers | | ACK | Bestätigung | | RST | Reset | | Retransmission | erneutes Senden | | Zero Window | Empfänger kann keine Daten aufnehmen | | Dup ACK | doppelte Bestätigung | | NXDOMAIN | DNS-Name existiert nicht | | SNI | Hostname im TLS-Handshake | | TLS Alert | TLS-Fehlermeldung | | Follow TCP Stream | zusammenhängende TCP-Daten anzeigen | | Conversations | Kommunikationsbeziehungen | | Endpoints | beteiligte Systeme | | Expert Information | Wireshark-Hinweise auf Auffälligkeiten | --- **IHK-sichere Kurzformulierung** Wireshark ist ein grafisches Werkzeug zur Analyse von Netzwerkpaketen. Mit Display Filtern kann man die Anzeige eines vorhandenen Mitschnitts eingrenzen, während Capture Filter bereits vor der Aufnahme festlegen, welche Pakete überhaupt aufgezeichnet werden. In Wireshark lassen sich unter anderem DNS-Anfragen, TCP-Handshakes, UDP-Kommunikation, ICMP-Meldungen, ARP, DHCP-Abläufe, TLS-Handshakes, Resets und Retransmissions erkennen. Bei HTTPS sind die Inhalte normalerweise verschlüsselt, aber Metadaten wie IP-Adressen, Ports, TLS-Handshake und häufig SNI können sichtbar sein. Paketmitschnitte müssen gezielt erstellt und datenschutzbewusst behandelt werden, da sie sensible Informationen enthalten können. --- **Merksätze** Wireshark zeigt Netzwerkpakete grafisch. Erst Fragestellung, dann Filter. Paketliste zeigt Überblick. Paketdetails zeigen Protokolle. Paketbytes zeigen Rohdaten. Display Filter begrenzen Anzeige. Capture Filter begrenzen Aufnahme. Was nicht aufgenommen wurde, kann später nicht analysiert werden. ip.addr = Quelle oder Ziel. ip.src = Quelle. ip.dst = Ziel. tcp.port ist nicht udp.port. TCP hat Handshake. UDP hat keinen Handshake. SYN startet Verbindung. SYN-ACK antwortet. ACK bestätigt. RST beendet oder lehnt ab. Retransmissions zeigen fehlende Bestätigungen. DNS vor Verbindungsaufbau prüfen. NXDOMAIN heißt: Name existiert nicht. DHCP-DORA ist im Mitschnitt sichtbar. HTTPS schützt Inhalte. TLS-Handshake liefert trotzdem Hinweise. SNI zeigt gewünschten Hostnamen. Follow TCP Stream hilft bei unverschlüsselten Protokollen. Expert Information ist Hinweis, nicht automatisch Ursache. Mitschnittort entscheidet, was sichtbar ist. Mehrere Mitschnitte können Paketverluststellen zeigen. PCAP-Dateien vertraulich behandeln. # 12.3 tcpdump, tshark und Paketmitschnitt auf der Kommandozeile Neben Wireshark gibt es wichtige Werkzeuge für Paketmitschnitte auf der Kommandozeile. Besonders wichtig sind: - tcpdump - tshark - netstat / ss - curl - nc - ping - traceroute / tracert - nslookup / dig Diese Werkzeuge sind besonders nützlich, wenn man auf Servern, Firewalls, Routern oder per SSH arbeitet. Merksatz: Wireshark ist grafisch. tcpdump und tshark arbeiten auf der Kommandozeile. --- **Warum Kommandozeilenwerkzeuge wichtig sind** In der Praxis hat man nicht immer eine grafische Oberfläche. Beispiele: Linux-Server per SSH Firewall-Konsole Container-Host Cloud-Server NAS-System Router Recovery-Umgebung minimale Serverinstallation Dort sind Kommandozeilenwerkzeuge oft schneller und direkter. Merksatz: Auf Servern ist die Kommandozeile oft das wichtigste Analysewerkzeug. --- **tcpdump** tcpdump ist ein Werkzeug, mit dem Netzwerkverkehr auf der Kommandozeile mitgeschnitten werden kann. Es kann: - Pakete live anzeigen - Pakete nach Host filtern - Pakete nach Port filtern - Pakete nach Protokoll filtern - Mitschnitte in Dateien speichern - PCAP-Dateien erzeugen Diese PCAP-Dateien kann man später mit Wireshark öffnen. Merksatz: tcpdump zeichnet Pakete auf und kann PCAP-Dateien erzeugen. --- **tcpdump-Grundidee** tcpdump lauscht auf einer Netzwerkschnittstelle. Beispiele für Schnittstellen: eth0 ens18 en0 wlan0 br0 docker0 vlan10 Wichtig: Man muss die richtige Schnittstelle auswählen. Wenn man auf der falschen Schnittstelle mitschneidet, sieht man den relevanten Verkehr nicht. Merksatz: Richtige Schnittstelle wählen, sonst ist der Mitschnitt wertlos. --- **Schnittstellen anzeigen** Vor einem Mitschnitt prüft man, welche Schnittstellen vorhanden sind. Typische Idee: tcpdump -D Damit werden verfügbare Interfaces angezeigt. Danach wählt man die passende Schnittstelle aus. Merksatz: Erst Schnittstellen anzeigen, dann Mitschnitt starten. --- **Einfacher tcpdump-Mitschnitt** Ein einfacher Mitschnitt auf einer Schnittstelle: tcpdump -i eth0 Bedeutung: -i eth0: auf Schnittstelle eth0 mitschneiden Dieser Mitschnitt zeigt viele Pakete live auf der Konsole. Merksatz: tcpdump -i Schnittstelle startet einen Live-Mitschnitt. --- **Namensauflösung vermeiden** tcpdump kann IP-Adressen und Ports in Namen auflösen. Das kann die Ausgabe verlangsamen oder verwirren. Daher nutzt man häufig: -n oder: -nn Bedeutung: keine Namensauflösung keine Portnamenauflösung Beispiel: tcpdump -nn -i eth0 Merksatz: -nn zeigt IPs und Ports unverändert an. --- **Paketinhalt ausführlicher anzeigen** Mit mehr Ausführlichkeit sieht man mehr Details. Typisch: -v -vv -vvv Beispiel: tcpdump -nn -vv -i eth0 Aber: mehr Details sind nicht immer übersichtlicher. Merksatz: Mehr Ausgabe hilft nur, wenn man sie auch gezielt auswertet. --- **In Datei speichern** Für spätere Analyse speichert man Mitschnitte in eine Datei. Beispiel: tcpdump -nn -i eth0 -w capture.pcap Bedeutung: -w capture.pcap: Mitschnitt in Datei schreiben Die Datei kann später mit Wireshark geöffnet werden. Merksatz: Mit -w speichert tcpdump einen Mitschnitt als Datei. --- **Datei wieder lesen** Eine gespeicherte PCAP-Datei kann mit tcpdump gelesen werden. Beispiel: tcpdump -nn -r capture.pcap Bedeutung: -r: Datei lesen Merksatz: Mit -r liest tcpdump gespeicherte Mitschnitte. --- **Nur bestimmten Host mitschneiden** Wenn nur ein bestimmter Host interessiert, filtert man nach IP-Adresse. Beispiel: tcpdump -nn -i eth0 host 192.168.10.20 Das zeigt Pakete, bei denen diese IP Quelle oder Ziel ist. Merksatz: host filtert Quelle oder Ziel. --- **Nur Quelle oder Ziel filtern** Quelle filtern: tcpdump -nn -i eth0 src host 192.168.10.20 Ziel filtern: tcpdump -nn -i eth0 dst host 192.168.10.20 Merksatz: src = Quelle. dst = Ziel. --- **Nach Netzwerk filtern** Man kann auch ganze Netze filtern. Beispiel: tcpdump -nn -i eth0 net 192.168.10.0/24 Das zeigt Verkehr, bei dem dieses Netz beteiligt ist. Merksatz: net filtert ein ganzes Subnetz. --- **Nach Port filtern** Beispiel: tcpdump -nn -i eth0 port 443 Das zeigt Pakete, bei denen Port 443 als Quell- oder Zielport vorkommt. Genauer: tcpdump -nn -i eth0 dst port 443 zeigt Pakete, die zu Zielport 443 gehen. Merksatz: port zeigt Quell- oder Zielport. dst port zeigt den Zielport. --- **TCP und UDP filtern** Man kann gezielt TCP oder UDP filtern. Beispiel TCP: tcpdump -nn -i eth0 tcp port 443 Beispiel UDP: tcpdump -nn -i eth0 udp port 53 Wichtig: TCP 53 und UDP 53 sind unterschiedlich. Merksatz: Protokoll und Port zusammen prüfen. --- **DNS mitschneiden** DNS nutzt häufig UDP 53, kann aber auch TCP 53 verwenden. Beispiel: tcpdump -nn -i eth0 port 53 Oder genauer: tcpdump -nn -i eth0 udp port 53 Wichtig: Bei großen Antworten oder Zonentransfers kann TCP 53 relevant sein. Merksatz: DNS nicht nur als UDP denken, auch TCP 53 beachten. --- **HTTP und HTTPS mitschneiden** HTTP: tcpdump -nn -i eth0 tcp port 80 HTTPS: tcpdump -nn -i eth0 tcp port 443 Bei HTTPS sieht man den Inhalt nicht im Klartext, aber man sieht Verbindungsaufbau, IP-Adressen, Ports, TLS-Handshake und Fehler. Merksatz: HTTPS-Inhalte sind verschlüsselt, aber Verbindungsdaten sind sichtbar. --- **SSH mitschneiden** SSH nutzt typischerweise TCP 22. Beispiel: tcpdump -nn -i eth0 tcp port 22 Man sieht: Verbindungsaufbau Pakete Abbrüche Timeouts Man sieht nicht: eingegebene Befehle im Klartext, weil SSH verschlüsselt ist. Merksatz: SSH schützt Inhalte, tcpdump sieht aber Verbindungsmetadaten. --- **ICMP mitschneiden** ICMP wird für Diagnose genutzt. Beispiel: tcpdump -nn -i eth0 icmp Damit sieht man zum Beispiel: Ping-Anfragen Ping-Antworten Destination Unreachable Time Exceeded Merksatz: ICMP zeigt Diagnose- und Fehlermeldungen. --- **ARP mitschneiden** ARP ist wichtig im lokalen IPv4-Netz. Beispiel: tcpdump -nn -i eth0 arp Damit sieht man ARP-Anfragen und ARP-Antworten. Typische Frage: Wer hat diese IP-Adresse? Merksatz: ARP hilft bei lokalen Erreichbarkeitsproblemen. --- **DHCP mitschneiden** DHCP nutzt UDP 67 und UDP 68. Beispiel: tcpdump -nn -i eth0 port 67 or port 68 Damit kann man den DORA-Ablauf sehen: Discover Offer Request Acknowledge Merksatz: DHCP-DORA lässt sich mit tcpdump gut prüfen. --- **Filter kombinieren** Filter können kombiniert werden. Beispiel: tcpdump -nn -i eth0 host 192.168.10.20 and tcp port 443 Bedeutung: Zeige nur TCP-443-Verkehr mit Host 192.168.10.20. Weitere logische Verknüpfungen: and or not Merksatz: Mit and, or und not werden tcpdump-Filter gezielt. --- **Beispiel: Alles außer SSH anzeigen** Wenn man per SSH auf einem Server arbeitet, kann der eigene SSH-Verkehr die Anzeige stören. Dann kann man SSH ausblenden: tcpdump -nn -i eth0 not port 22 Merksatz: Eigenen SSH-Verkehr bei Bedarf ausblenden. --- **Beispiel: Fehler reproduzieren** Gute Vorgehensweise: 1. Mitschnitt vorbereiten. 2. Mitschnitt starten. 3. Fehler gezielt auslösen. 4. Mitschnitt stoppen. 5. Datei sichern. 6. Mit Wireshark analysieren. Merksatz: Mitschnitt immer passend zum Fehlerzeitpunkt erstellen. --- **Mitschnitt begrenzen** Paketmitschnitte können schnell sehr groß werden. Möglichkeiten: nur bestimmte IP mitschneiden nur bestimmten Port mitschneiden nur kurze Zeit mitschneiden Datei begrenzen Rotation nutzen nicht unnötig viele Daten erfassen Merksatz: So wenig wie möglich, so viel wie nötig mitschneiden. --- **Warum PCAP-Dateien sensibel sind** PCAP-Dateien können enthalten: - interne IP-Adressen - MAC-Adressen - Hostnamen - Benutzernamen - Cookies - Tokens - unverschlüsselte Passwörter - E-Mail-Inhalte - interne Protokolle - Kundendaten Deshalb: sicher speichern Zugriff begrenzen nicht unnötig weitergeben nach Zweck löschen Merksatz: PCAP-Dateien wie vertrauliche Daten behandeln. --- **tshark** tshark ist die Kommandozeilenversion von Wireshark. Es nutzt ähnliche Analysefunktionen, aber ohne grafische Oberfläche. tshark kann: - live mitschneiden - PCAP-Dateien lesen - Display Filter verwenden - Felder ausgeben - automatisiert auswerten - Protokolle analysieren Merksatz: tshark ist Wireshark für die Kommandozeile. --- **tshark für vorhandene Dateien** Eine vorhandene PCAP-Datei kann mit tshark gelesen werden. Beispiel: tshark -r capture.pcap Mit Filtern kann man gezielt suchen. Beispielidee: nur DNS anzeigen nur HTTP anzeigen nur bestimmte IP anzeigen Merksatz: tshark eignet sich gut für schnelle PCAP-Auswertung. --- **tcpdump oder tshark?** | Werkzeug | Stärke | |---|---| | tcpdump | schnell mitschneiden, auf vielen Systemen verfügbar | | tshark | detailliertere Protokollauswertung auf Kommandozeile | | Wireshark | grafische Analyse, sehr übersichtlich | Merksatz: tcpdump zum Aufnehmen, Wireshark oder tshark zum Analysieren. --- **ss** ss zeigt Netzwerk-Sockets auf Linux-Systemen. Damit prüft man: welche Dienste lauschen welche Verbindungen bestehen welche Ports offen sind welche Prozesse Ports verwenden Beispielidee: Lauscht ein Dienst wirklich auf Port 443? Merksatz: ss zeigt lokale Ports und Verbindungen. --- **netstat** netstat ist ein älteres Werkzeug, das ähnliche Informationen wie ss anzeigen kann. Es zeigt unter anderem: - offene Ports - aktive Verbindungen - Routingtabelle - Schnittstellenstatistiken Auf modernen Linux-Systemen wird häufig ss bevorzugt. Merksatz: netstat ist älter, ss ist auf Linux oft moderner. --- **Lauschende Dienste prüfen** Wenn ein Dienst nicht erreichbar ist, prüft man lokal: Lauscht der Dienst überhaupt? Beispielhafte Fragestellung: Hört der Webserver auf TCP 80 oder TCP 443? Hört SSH auf TCP 22? Hört die Datenbank nur auf localhost? Hört der Dienst auf der richtigen IP-Adresse? Merksatz: Dienst muss lokal lauschen, bevor er extern erreichbar sein kann. --- **localhost-Falle** Ein Dienst kann nur auf localhost lauschen. Beispiel: 127.0.0.1:8080 Dann ist er nur lokal auf dem System erreichbar, aber nicht von anderen Geräten im Netzwerk. Für externe Erreichbarkeit muss er auf einer passenden Adresse lauschen. Merksatz: Dienst auf localhost ist nicht automatisch im Netzwerk erreichbar. --- **curl** curl ist ein Werkzeug zum Testen von HTTP, HTTPS und vielen anderen Protokollen. Es kann zeigen: - Statuscode - Header - Weiterleitungen - TLS-Fehler - Antwortinhalt - API-Antworten Merksatz: curl testet Webdienste und APIs direkt. --- **curl und HTTP-Status** Mit curl kann man prüfen, welchen HTTP-Status ein Server zurückgibt. Wichtige Fragen: Kommt 200? Kommt 301 oder 302? Kommt 401? Kommt 403? Kommt 404? Kommt 500? Kommt 502? Merksatz: curl zeigt, was ein Webserver tatsächlich antwortet. --- **curl und Header** HTTP-Header enthalten wichtige Informationen. Beispiele: Content-Type Location Server Set-Cookie Authorization Cache-Control Strict-Transport-Security Mit curl kann man Header gezielt anzeigen. Merksatz: Header erklären oft, warum ein Webdienst sich so verhält. --- **curl und TLS** curl kann TLS-Probleme sichtbar machen. Typische Fehler: Zertifikat abgelaufen Name passt nicht CA nicht vertrauenswürdig TLS-Version nicht kompatibel Zertifikatskette unvollständig Merksatz: curl hilft bei HTTPS- und Zertifikatsproblemen. --- **nc** nc steht für netcat. Es kann verwendet werden, um einfache TCP- oder UDP-Verbindungen zu testen. Typische Nutzung: Ist ein TCP-Port erreichbar? Antwortet ein einfacher Dienst? Kann ich manuell Daten senden? Beispielgedanke: Porttest für TCP 443, TCP 22 oder TCP 25. Merksatz: nc ist ein einfaches Werkzeug für Port- und Verbindungstests. --- **Porttest richtig einordnen** Ein erfolgreicher Porttest bedeutet: TCP-Verbindung zum Port ist möglich. Er bedeutet nicht automatisch: Anwendung funktioniert korrekt. Login funktioniert. Zertifikat passt. Berechtigung stimmt. API antwortet richtig. Merksatz: Port offen ist nur ein Teil der Diagnose. --- **ping** ping nutzt ICMP Echo Request und Echo Reply. Es prüft grob: Ist ein Ziel per ICMP erreichbar? Ping sagt nicht: ob ein TCP-Port offen ist ob DNS korrekt ist ob HTTPS funktioniert ob Anwendung antwortet ob Anmeldung funktioniert Merksatz: Ping prüft nicht den Dienst. --- **traceroute und tracert** traceroute oder tracert zeigen den Weg zu einem Ziel. Sie helfen bei: Routingproblemen Erreichbarkeitsproblemen ungewöhnlichen Pfaden Netzunterbrechungen hoher Latenz Wichtig: Firewalls können traceroute-Ergebnisse beeinflussen. Merksatz: traceroute zeigt Hinweise auf den Weg, aber nicht immer den vollständigen echten Pfad. --- **nslookup** nslookup prüft DNS-Auflösung. Damit kann man fragen: Welche IP liefert DNS für diesen Namen? Welcher DNS-Server antwortet? Gibt es überhaupt eine Antwort? Gut für einfache DNS-Prüfung. Merksatz: nslookup prüft Namensauflösung. --- **dig** dig ist ein detaillierteres DNS-Werkzeug. Es zeigt unter anderem: - DNS-Antworten - Record-Typen - Antwortzeiten - Nameserver - TTL - Autorität - zusätzliche Antworten dig ist besonders hilfreich, wenn DNS genauer analysiert werden soll. Merksatz: dig ist detaillierte DNS-Analyse. --- **openssl s_client** openssl s_client prüft TLS-Verbindungen. Damit kann man sehen: - Zertifikat - Zertifikatskette - TLS-Version - Cipher - Serverantwort - SNI-Verhalten Besonders nützlich bei: HTTPS LDAPS IMAPS SMTPS POP3S Merksatz: openssl s_client hilft bei TLS- und Zertifikatsproblemen. --- **journalctl** journalctl zeigt Logs auf Systemen mit systemd. Damit kann man prüfen: Dienst gestartet? Dienst abgestürzt? Fehler beim Start? Berechtigungsproblem? Port bereits belegt? Konfigurationsfehler? Merksatz: journalctl zeigt System- und Dienstlogs auf Linux. --- **Windows-Ereignisanzeige** Die Windows-Ereignisanzeige zeigt System- und Anwendungsereignisse. Wichtige Bereiche: Anwendung Sicherheit System Setup Dienstspezifische Protokolle Hilfreich bei: Anmeldefehlern Dienstfehlern RDP-Problemen DNS- oder DHCP-Problemen Zertifikatsproblemen Merksatz: Ereignisanzeige ist wichtig für Windows-Fehlersuche. --- **PowerShell Test-NetConnection** Unter Windows kann Test-NetConnection helfen. Es prüft zum Beispiel: Namensauflösung TCP-Verbindung zu einem Port Ziel-IP grundlegende Erreichbarkeit Beispielhafte Fragestellung: Ist TCP 443 erreichbar? Ist TCP 3389 erreichbar? Merksatz: Test-NetConnection ist ein Windows-Werkzeug für Porttests. --- **Werkzeuge richtig kombinieren** Kein Werkzeug beantwortet alles. Beispiel Webdienst funktioniert nicht: nslookup: DNS prüfen ping: grobe Erreichbarkeit prüfen Test-NetConnection oder nc: Port prüfen curl: HTTP-Antwort prüfen tcpdump: Verkehr prüfen Logs: Dienstfehler prüfen Merksatz: Diagnose entsteht durch Kombination mehrerer Werkzeuge. --- **Beispiel: HTTPS funktioniert nicht** Sinnvolle Prüfung: 1. DNS mit nslookup oder dig prüfen. 2. Port TCP 443 mit nc oder Test-NetConnection prüfen. 3. HTTP-Antwort mit curl prüfen. 4. Zertifikat mit curl oder openssl s_client prüfen. 5. tcpdump oder Wireshark bei Verbindungsproblemen nutzen. 6. Webserver- oder Reverse-Proxy-Logs prüfen. Merksatz: HTTPS-Probleme mit DNS, Port, TLS, Anwendung und Logs prüfen. --- **Beispiel: SSH funktioniert nicht** Sinnvolle Prüfung: 1. Ziel-IP oder Hostname prüfen. 2. TCP 22 prüfen. 3. Lokalen SSH-Dienst prüfen. 4. Firewall und Host-Firewall prüfen. 5. Benutzer und Schlüssel prüfen. 6. SSH-Logs prüfen. 7. tcpdump bei Timeout oder unklarer Verbindung nutzen. Merksatz: SSH-Probleme mit Port, Dienst, Benutzer, Schlüssel und Logs prüfen. --- **Beispiel: DNS funktioniert nicht** Sinnvolle Prüfung: 1. Welcher DNS-Server ist eingetragen? 2. Ist DNS-Server erreichbar? 3. Antwortet UDP 53? 4. Antwortet bei Bedarf TCP 53? 5. Liefert DNS richtige Antwort? 6. Gibt es NXDOMAIN? 7. Gibt es falschen Cache? 8. tcpdump zeigt echte DNS-Anfrage? Merksatz: DNS-Fehler mit Server, Port, Antwort und Cache prüfen. --- **Beispiel: DHCP funktioniert nicht** Sinnvolle Prüfung: 1. Client sendet Discover? 2. DHCP-Server antwortet mit Offer? 3. Client sendet Request? 4. Server sendet Acknowledge? 5. Scope hat freie Adressen? 6. DHCP-Relay korrekt? 7. VLAN korrekt? 8. Firewall blockiert UDP 67/68? Merksatz: DHCP mit DORA analysieren. --- **Beispiel: RDP funktioniert nicht** Sinnvolle Prüfung: 1. Hostname oder IP prüfen. 2. TCP 3389 prüfen. 3. Remote Desktop aktiviert? 4. Host-Firewall erlaubt? 5. Benutzer berechtigt? 6. VPN oder Gateway nötig? 7. Windows-Ereignisanzeige prüfen. 8. Nicht direkt aus Internet veröffentlichen. Merksatz: RDP-Probleme mit Port, Dienst, Berechtigung und Sicherheit prüfen. --- **Typische Fehler bei Werkzeugnutzung** Häufige Fehler: - nur ping testen und Dienstproblem übersehen - DNS nicht prüfen - TCP und UDP verwechseln - falsche Schnittstelle mitschneiden - falschen Port prüfen - internen und externen Test verwechseln - NAT nicht berücksichtigen - Logs ignorieren - verschlüsselte Inhalte im Klartext erwarten Merksatz: Werkzeugergebnisse immer fachlich einordnen. --- **Diagnose nach Schichten** | Schicht | typische Werkzeuge | |---:|---| | 1 | Link-Status, Kabeltest, Switchport | | 2 | ARP, MAC-Tabelle, VLAN-Prüfung | | 3 | ping, traceroute, Routingtabelle | | 4 | nc, Test-NetConnection, ss, tcpdump | | 5–6 | TLS-Prüfung, openssl s_client | | 7 | curl, nslookup, dig, Logs, Anwendungstest | Merksatz: Das Werkzeug richtet sich nach der vermuteten Schicht. --- **Was Kommandozeilenwerkzeuge nicht ersetzen** Sie ersetzen nicht: - saubere Dokumentation - Verständnis der Netzstruktur - Firewall-Regelprüfung - Berechtigungsprüfung - Dienstkonfiguration - Monitoring - Sicherheitskonzept - Datenschutz beim Mitschnitt Merksatz: Werkzeuge liefern Hinweise, Fachwissen macht daraus eine Diagnose. --- **Typische IHK-Fragen** In AP1 und AP2 kann zum Beispiel gefragt werden: - Wofür nutzt man tcpdump? - Was ist eine PCAP-Datei? - Wofür steht tshark? - Was ist der Unterschied zwischen tcpdump und Wireshark? - Warum muss man die richtige Schnittstelle wählen? - Wie filtert man nach Host, Port oder Protokoll? - Warum ist tcpdump mit -w nützlich? - Warum sind Mitschnittdateien sensibel? - Wofür nutzt man curl? - Wofür nutzt man nc? - Was prüft ping? - Warum reicht ping nicht aus? - Wofür nutzt man nslookup oder dig? - Wofür nutzt man openssl s_client? - Wie kombiniert man Werkzeuge bei der Fehlersuche? --- **Typische Prüfungsfallen** tcpdump ist Kommandozeile. Wireshark ist grafisch. tshark ist Wireshark auf Kommandozeile. tcpdump kann PCAP-Dateien speichern. PCAP-Dateien können sensible Daten enthalten. Falsche Schnittstelle bedeutet falsche Sicht. -nn verhindert Namensauflösung. host filtert Quelle oder Ziel. src ist Quelle. dst ist Ziel. port filtert Quell- oder Zielport. TCP und UDP getrennt betrachten. DNS kann UDP und TCP 53 nutzen. DHCP nutzt UDP 67 und 68. Ping prüft ICMP, nicht den Dienst. Porttest beweist nicht, dass Anwendung funktioniert. curl prüft Webdienste besser als ping. openssl s_client hilft bei TLS. Logs und Mitschnitt ergänzen sich. Werkzeuge ersetzen keine fachliche Analyse. --- **Wichtige Begriffe kurz erklärt** | Begriff | Kurze Erklärung | |---|---| | tcpdump | Kommandozeilenwerkzeug für Paketmitschnitte | | tshark | Wireshark-Funktion auf Kommandozeile | | PCAP | Datei mit aufgezeichneten Paketen | | Interface | Netzwerkschnittstelle | | Capture | Aufnahme von Paketen | | -i | Schnittstelle auswählen | | -w | Mitschnitt in Datei schreiben | | -r | Mitschnitt aus Datei lesen | | -n / -nn | Namensauflösung abschalten | | host | Quelle oder Ziel filtern | | src | Quelle | | dst | Ziel | | port | Port filtern | | ss | lokale Sockets und Ports anzeigen | | netstat | älteres Werkzeug für Netzwerkstatus | | curl | Web- und API-Anfragen testen | | nc | einfache Port- und Verbindungstests | | ping | ICMP-Erreichbarkeit prüfen | | traceroute | Weg zum Ziel prüfen | | nslookup | DNS einfach prüfen | | dig | DNS detailliert prüfen | | openssl s_client | TLS-Verbindungen prüfen | | journalctl | Linux-Systemlogs anzeigen | | Ereignisanzeige | Windows-Logs anzeigen | | Test-NetConnection | Windows-Porttest | --- **IHK-sichere Kurzformulierung** tcpdump ist ein Kommandozeilenwerkzeug zum Mitschneiden von Netzwerkverkehr und kann Mitschnitte als PCAP-Datei speichern, die später mit Wireshark analysiert werden kann. tshark ist die Kommandozeilenversion von Wireshark und eignet sich für detaillierte Auswertungen ohne grafische Oberfläche. Bei der Analyse muss die richtige Netzwerkschnittstelle gewählt und gezielt nach Host, Port, Protokoll oder Netz gefiltert werden. Ergänzende Werkzeuge wie curl, nc, ping, traceroute, nslookup, dig, openssl s_client, ss, netstat und Logdateien helfen, DNS, Ports, TLS, Dienste und Verbindungen systematisch zu prüfen. Ein einzelnes Werkzeug reicht selten aus; eine zuverlässige Diagnose entsteht durch die Kombination mehrerer Hinweise. --- **Merksätze** tcpdump = Paketmitschnitt auf Kommandozeile. tshark = Wireshark auf Kommandozeile. Wireshark = grafische Analyse. PCAP = gespeicherter Paketmitschnitt. Richtige Schnittstelle ist entscheidend. -nn verhindert Namensauflösung. -w schreibt Mitschnitt in Datei. -r liest Mitschnitt aus Datei. host filtert Quelle oder Ziel. src filtert Quelle. dst filtert Ziel. port filtert Quell- oder Zielport. TCP und UDP nicht verwechseln. DNS kann UDP und TCP nutzen. DHCP nutzt UDP 67 und 68. SSH nutzt typischerweise TCP 22. HTTPS nutzt typischerweise TCP 443. Ping prüft ICMP, nicht Anwendung. Porttest prüft Erreichbarkeit, nicht Anwendungserfolg. curl prüft HTTP und HTTPS. nc testet einfache Verbindungen. nslookup und dig prüfen DNS. openssl s_client prüft TLS. ss zeigt lokale Ports. Logs zeigen Dienstfehler. Mitschnitt und Logs gemeinsam auswerten. PCAP-Dateien vertraulich behandeln. Werkzeuge liefern Hinweise, Fachwissen liefert die Diagnose. # 12.4 Systematische Netzwerkfehlersuche nach dem OSI-Modell Netzwerkfehlersuche sollte nicht zufällig erfolgen. Besser ist ein systematisches Vorgehen nach Schichten. Das OSI-Modell hilft dabei, Fehler Schritt für Schritt einzugrenzen. Grundidee: erst einfache Grundlagen prüfen dann höhere Schichten prüfen Fehler sauber eingrenzen Messergebnisse dokumentieren nicht vorschnell raten Merksatz: Systematische Fehlersuche spart Zeit und verhindert falsche Vermutungen. --- **Warum nach Schichten prüfen?** Viele Fehler sehen ähnlich aus. Beispiel: Webseite öffnet nicht. Mögliche Ursachen können sein: Kabel defekt WLAN getrennt falsches VLAN falsche IP-Adresse Gateway fehlt DNS falsch Port blockiert Zertifikat ungültig Webserver down Benutzer nicht berechtigt Ohne Struktur sucht man schnell an der falschen Stelle. Merksatz: Ein Symptom kann viele Ursachen auf verschiedenen Schichten haben. --- **Top-Down und Bottom-Up** Es gibt zwei typische Vorgehensweisen: Bottom-Up Top-Down Bottom-Up bedeutet: Man beginnt unten bei Schicht 1 und arbeitet sich nach oben. Top-Down bedeutet: Man beginnt bei der Anwendung und arbeitet sich nach unten. Beide Methoden sind sinnvoll, je nach Fehlerbild. Merksatz: Bottom-Up beginnt beim Kabel. Top-Down beginnt bei der Anwendung. --- **Bottom-Up-Methode** Bottom-Up prüft von unten nach oben: Schicht 1: Kabel, Link, Signal Schicht 2: MAC, Switch, VLAN Schicht 3: IP, Subnetz, Gateway, Routing Schicht 4: TCP, UDP, Ports Schicht 5–7: Sitzung, Darstellung, Anwendung Vorteil: grundlegende Fehler werden früh erkannt. Merksatz: Bottom-Up ist gut, wenn unklar ist, ob überhaupt Netzverbindung besteht. --- **Top-Down-Methode** Top-Down beginnt bei der Anwendung. Beispiel: Benutzer sagt: E-Mail funktioniert nicht. Dann prüft man zuerst: Mailclient Anmeldung Fehlermeldung Servername Protokoll Port DNS Netzwerk Vorteil: schneller, wenn der Fehler klar an einem Dienst hängt. Merksatz: Top-Down ist gut, wenn ein bestimmter Dienst betroffen ist. --- **Divide-and-Conquer-Methode** Divide and Conquer bedeutet: Problem in der Mitte eingrenzen. Man prüft zuerst eine mittlere Schicht, zum Beispiel IP-Erreichbarkeit oder Port-Erreichbarkeit. Beispiel: Ping zum Server funktioniert. Dann weiß man: Schicht 1 bis 3 sind wahrscheinlich grundsätzlich ok. Dann prüft man weiter: Port Dienst Anmeldung Anwendung Merksatz: Divide and Conquer halbiert den Suchbereich. --- **Vergleichsmethode** Bei der Vergleichsmethode vergleicht man: funktionierendes System mit fehlerhaftem System Beispiele: anderer Client funktioniert anderer Benutzer funktioniert anderes VLAN funktioniert anderer Browser funktioniert anderer DNS-Server liefert andere Antwort Dadurch erkennt man Unterschiede. Merksatz: Vergleich zeigt, was beim fehlerhaften Fall anders ist. --- **Fehler reproduzieren** Ein Fehler sollte möglichst reproduzierbar gemacht werden. Fragen: Wann tritt der Fehler auf? Bei welchem Benutzer? Bei welchem Client? Bei welchem Dienst? Seit wann? Nach welcher Änderung? Immer oder nur manchmal? Intern oder extern? Mit WLAN oder LAN? Mit VPN oder ohne VPN? Merksatz: Nur reproduzierbare Fehler lassen sich sauber messen. --- **Fehlerbild genau aufnehmen** Vor der Analyse sollte man das Fehlerbild genau aufnehmen. Nicht ausreichend: Internet geht nicht. Besser: Benutzer kann https://intranet.firma.local öffnen, aber https://portal.firma.de nicht. Fehler im Browser: DNS_PROBE_FINISHED_NXDOMAIN. Noch besser: Zeitpunkt, Client-IP, Benutzer, DNS-Server, Fehlermeldung, betroffener Dienst. Merksatz: Genaue Fehlerbeschreibung ist Teil der Diagnose. --- **W-Fragen bei Netzwerkfehlern** Wichtige Fragen: Wer ist betroffen? Was funktioniert nicht? Wann tritt der Fehler auf? Wo tritt der Fehler auf? Wie äußert sich der Fehler? Seit wann besteht der Fehler? Was wurde zuletzt geändert? Welche Systeme funktionieren noch? Merksatz: Gute Fragen grenzen den Fehler ein. --- **Einzelner Benutzer oder alle Benutzer?** Wenn nur ein Benutzer betroffen ist, prüft man eher: Benutzerkonto Berechtigungen Passwort MFA Clientprofil lokale Einstellungen Browsercache gespeicherte Zugangsdaten Wenn alle Benutzer betroffen sind, prüft man eher: Dienst Server DNS Netzwerk Firewall Zertifikat zentrale Authentifizierung Provider Infrastruktur Merksatz: Einzelner Benutzer = Konto oder Client. Alle Benutzer = Dienst oder Infrastruktur. --- **Ein Client oder mehrere Clients?** Wenn nur ein Client betroffen ist, prüft man: Netzwerkkabel WLAN IP-Konfiguration DNS-Einstellungen lokale Firewall Proxy VPN Zertifikatsspeicher lokale Software Wenn mehrere Clients betroffen sind, prüft man: Switch VLAN DHCP DNS Gateway Firewall Server zentrale Dienste Merksatz: Ein Client betroffen: lokal prüfen. Viele Clients betroffen: Infrastruktur prüfen. --- **Intern oder extern betroffen?** Wenn intern alles funktioniert, extern aber nicht, prüft man: externe DNS-Auflösung öffentliche IP NAT Firewall WAN → DMZ Provider CGNAT Zertifikat Reverse Proxy Wenn extern funktioniert, intern aber nicht, prüft man: internes DNS Split DNS Hairpin NAT interne Firewall interne Route Proxy-Einstellungen Merksatz: Interne und externe Sicht getrennt prüfen. --- **Nur WLAN oder auch LAN?** Wenn nur WLAN betroffen ist, prüft man: WLAN-Signal SSID WLAN-Passwort VLAN-Zuordnung am Access Point DHCP im WLAN-Netz Roaming Störungen Access Point Client-Treiber Wenn LAN auch betroffen ist, liegt die Ursache eher bei: IP-Konfiguration Gateway DNS Firewall Dienst zentraler Infrastruktur Merksatz: WLAN-Fehler nicht automatisch als Internetfehler behandeln. --- **Nur ein VLAN betroffen?** Wenn nur ein VLAN betroffen ist, prüft man: VLAN-ID Switchport-Modus Tagged oder Untagged Trunk Access-Port DHCP-Scope Gateway für VLAN Firewall-Regeln Routing ACLs Merksatz: VLAN-bezogene Fehler sind oft Schicht 2 und 3. --- **Nur ein Dienst betroffen?** Wenn nur ein Dienst betroffen ist, prüft man eher: DNS-Name des Dienstes Ziel-IP Port Protokoll Firewall-Regel Dienststatus Zertifikat Authentifizierung Berechtigung Anwendungslogs Beispiel: Internet funktioniert, aber SMB-Freigabe nicht. Dann ist nicht das ganze Netzwerk down, sondern ein Dienst oder Zugriffspfad gestört. Merksatz: Ein Dienst betroffen: Dienstkette prüfen. --- **Schicht 1 prüfen** Schicht 1 ist die Bitübertragungsschicht. Prüfpunkte: Kabel steckt? Link-LED aktiv? richtiger Port? Netzteil aktiv? SFP-Modul korrekt? Glasfaser richtig gesteckt? WLAN-Signal vorhanden? keine physische Beschädigung? Duplex oder Speed auffällig? Werkzeuge: Sichtprüfung Linkstatus Kabeltester Switchport-Status WLAN-Signalprüfung Merksatz: Ohne funktionierende Schicht 1 funktioniert darüber nichts. --- **Schicht 2 prüfen** Schicht 2 ist die Sicherungsschicht. Prüfpunkte: MAC-Adresse sichtbar? Switchport aktiv? VLAN korrekt? Access oder Trunk richtig? MAC-Adresstabelle passend? STP blockiert? Broadcast-Sturm? ARP funktioniert? keine doppelte IP im lokalen Netz? Werkzeuge: Switch-MAC-Tabelle ARP-Tabelle VLAN-Konfiguration Wireshark Switch-Logs Merksatz: Schicht 2 betrifft lokale Kommunikation im richtigen Netzsegment. --- **Schicht 3 prüfen** Schicht 3 ist die Vermittlungs- oder Netzwerkschicht. Prüfpunkte: IP-Adresse korrekt? Subnetzmaske korrekt? Gateway korrekt? Routing korrekt? Zielnetz erreichbar? keine APIPA-Adresse? keine doppelte IP? IPv4 oder IPv6 korrekt? Rückweg vorhanden? Werkzeuge: ipconfig ifconfig ip addr ping traceroute / tracert route print ip route Routingtabelle Merksatz: Schicht 3 beantwortet: Komme ich zum richtigen Netz? --- **Schicht 4 prüfen** Schicht 4 ist die Transportschicht. Prüfpunkte: TCP oder UDP? richtiger Port? Port offen? Dienst lauscht? Firewall blockiert? TCP-Handshake vollständig? UDP-Antwort vorhanden? NAT oder PAT beteiligt? Rückweg korrekt? Werkzeuge: nc Test-NetConnection ss netstat tcpdump Wireshark Firewall-Logs Merksatz: Schicht 4 beantwortet: Ist der Dienstport erreichbar? --- **Schicht 5 prüfen** Schicht 5 ist die Sitzungsschicht. Prüfpunkte: Session wird aufgebaut? Session bleibt bestehen? Benutzer wird ständig ausgeloggt? Cookie korrekt? Session Timeout? Load Balancer mit Session-Stickiness? Session-Speicher erreichbar? Typische Fehler: Login-Schleife Session läuft sofort ab Warenkorb wird vergessen Remote-Sitzung bricht ab Merksatz: Schicht 5 betrifft Sitzungen und deren Verwaltung. --- **Schicht 6 prüfen** Schicht 6 ist die Darstellungsschicht. Prüfpunkte: TLS korrekt? Zertifikat gültig? Name passt zum Zertifikat? CA vertrauenswürdig? Datenformat korrekt? Zeichencodierung korrekt? Kompression korrekt? JSON oder XML gültig? Typische Fehler: Zertifikatswarnung falsche Umlaute ungültiges JSON TLS-Handshake-Fehler falscher Content-Type Merksatz: Schicht 6 betrifft Darstellung, Codierung, Kompression und Verschlüsselung. --- **Schicht 7 prüfen** Schicht 7 ist die Anwendungsschicht. Prüfpunkte: Dienst läuft? richtige URL? richtiger Hostname? richtige Methode? richtiger Statuscode? Anmeldung korrekt? Berechtigung vorhanden? Anwendung antwortet? API korrekt? Logs vorhanden? Backend erreichbar? Typische Fehler: HTTP 404 HTTP 500 Login fehlgeschlagen Zugriff verweigert DNS falsch Mail kommt nicht an API antwortet mit Fehler Merksatz: Schicht 7 betrifft den konkreten Dienst und seine Antwort. --- **DNS als häufiger Sonderfall** DNS gehört zur Anwendungsschicht, wirkt aber auf fast alle anderen Dienste. Wenn DNS falsch ist, sucht man oft am falschen Ziel. Typische DNS-Fehler: falsche IP-Adresse NXDOMAIN falscher DNS-Server Split DNS falsch veralteter Cache IPv6-Antwort nicht erreichbar MX-Record falsch Merksatz: DNS immer früh prüfen, wenn Namen verwendet werden. --- **DHCP als häufiger Sonderfall** DHCP gehört zur Anwendungsschicht, liefert aber Schicht-3-Konfiguration. DHCP-Fehler führen zu: keiner IP-Adresse APIPA 169.254.x.x falschem Gateway falschem DNS falschem VLAN falscher Lease Merksatz: DHCP-Fehler wirken wie IP- oder Internetprobleme. --- **Firewall als häufiger Sonderfall** Firewalls können mehrere Schichten betreffen. Je nach Firewall prüft sie: IP-Adressen Ports Protokolle Zustand Anwendung Benutzer Zonen Bei Firewall-Verdacht prüfen: Quelle Ziel Port Protokoll Richtung Zone Regel Logs NAT Rückweg Merksatz: Firewall-Fehler mit Quelle, Ziel, Port, Richtung und Logs prüfen. --- **NAT als häufiger Sonderfall** NAT kann IP-Adressen und Ports verändern. Deshalb muss man wissen: Welche Adresse sieht der Client? Welche Adresse sieht der Server? Gibt es Source NAT? Gibt es Destination NAT? Gibt es PAT? Gibt es Portweiterleitung? Stimmt der Rückweg? Merksatz: Bei NAT immer vor und nach der Übersetzung denken. --- **Logs immer einbeziehen** Logs liefern oft die entscheidenden Hinweise. Wichtige Logs: Client-Logs Server-Logs Firewall-Logs DNS-Logs DHCP-Logs Webserver-Logs Reverse-Proxy-Logs Authentifizierungslogs VPN-Logs Ereignisanzeige journalctl Merksatz: Logs zeigen Entscheidungen, Mitschnitte zeigen Verkehr. --- **Paketmitschnitt gezielt einsetzen** Ein Paketmitschnitt ist besonders hilfreich, wenn unklar ist: ob Pakete ankommen ob Antworten zurückkommen ob DNS korrekt gefragt wird ob TCP-Handshake klappt ob UDP-Antworten kommen ob NAT richtig arbeitet ob Retransmissions auftreten ob Reset oder Timeout entsteht Merksatz: Mitschnitt nutzen, wenn der echte Verkehr unklar ist. --- **Fehler nach Änderung** Viele Störungen entstehen nach Änderungen. Beispiele: Firewall-Regel geändert DNS-Eintrag geändert DHCP-Scope geändert VLAN geändert Zertifikat erneuert Server-IP geändert Dienst aktualisiert Reverse Proxy angepasst Passwort oder Rechte geändert VPN-Konfiguration geändert Merksatz: Nach Änderung zuerst die Änderung prüfen. --- **Change und Rollback** Bei Änderungen sollte vorher klar sein: Was wird geändert? Warum wird es geändert? Wer ist verantwortlich? Wann wird getestet? Wie wird zurückgerollt? Welche Systeme sind betroffen? Gibt es ein Backup? Gibt es Dokumentation? Rollback bedeutet: Änderung zurücknehmen, wenn sie Probleme verursacht. Merksatz: Keine kritische Änderung ohne Rückweg. --- **Dokumentation während der Fehlersuche** Während der Fehlersuche sollte man dokumentieren: Fehlerbild Zeitpunkt betroffene Systeme betroffene Benutzer getestete Schritte Messergebnisse Logs Änderungen gefundene Ursache Lösung offene Punkte Merksatz: Gute Dokumentation verhindert doppelte Arbeit. --- **Hypothesen bilden** Eine Hypothese ist eine fachliche Vermutung, die getestet wird. Beispiel: Hypothese: DNS zeigt auf falsche IP. Test: nslookup oder dig ausführen. Ergebnis: Wenn DNS falsch ist, Hypothese bestätigt. Wenn nicht: Hypothese verwerfen und nächste Ursache prüfen. Merksatz: Hypothesen müssen getestet, nicht geglaubt werden. --- **Nicht mehrere Dinge gleichzeitig ändern** Wenn man mehrere Dinge gleichzeitig ändert, weiß man später nicht, welche Änderung geholfen oder geschadet hat. Besser: eine Änderung durchführen testen Ergebnis dokumentieren nächste Änderung durchführen Merksatz: Eine Änderung pro Testschritt. --- **Workaround und Ursachenbehebung unterscheiden** Ein Workaround umgeht ein Problem vorübergehend. Eine Ursachenbehebung beseitigt die Ursache. Beispiel: Workaround: Benutzer nutzt IP-Adresse statt DNS-Namen. Ursache: DNS-Eintrag ist falsch. Die Ursache muss trotzdem behoben werden. Merksatz: Workaround ist nicht automatisch Lösung. --- **Typische Fehlerbilder und erste Einordnung** | Fehlerbild | erste Vermutung | |---|---| | Kein Link | Schicht 1 | | IP 169.254.x.x | DHCP-Problem | | Gateway nicht erreichbar | Schicht 2 / 3 | | Name löst nicht auf | DNS | | Ping geht, Port nicht | Schicht 4 / Firewall / Dienst | | Port offen, HTTP 500 | Anwendung / Backend | | Zertifikatswarnung | TLS / Zeit / Name | | Zugriff verweigert | Autorisierung | | Login schlägt fehl | Authentifizierung | | Nur extern gestört | NAT / Firewall / DNS extern | | Nur intern gestört | DNS intern / Hairpin NAT / Routing | Merksatz: Fehlerbild gibt Hinweis, aber noch keinen Beweis. --- **Beispiel: Webseite öffnet nicht** Systematische Prüfung: 1. URL korrekt? 2. DNS löst korrekt auf? 3. Ziel-IP erreichbar? 4. TCP 443 erreichbar? 5. TLS-Zertifikat gültig? 6. HTTP-Statuscode prüfen. 7. Reverse Proxy prüfen. 8. Backend prüfen. 9. Webserver-Logs prüfen. 10. Firewall-Logs prüfen. Merksatz: Webfehler mit DNS, Port, TLS, HTTP und Logs prüfen. --- **Beispiel: Client bekommt keine IP-Adresse** Systematische Prüfung: 1. Link vorhanden? 2. VLAN korrekt? 3. DHCP Discover sichtbar? 4. DHCP Offer sichtbar? 5. DHCP-Scope frei? 6. DHCP-Relay korrekt? 7. Firewall erlaubt UDP 67/68? 8. Richtiger DHCP-Server? 9. Keine Rogue-DHCP-Antwort? 10. Client erhält Lease? Merksatz: DHCP-Fehler mit DORA eingrenzen. --- **Beispiel: Server per SSH nicht erreichbar** Systematische Prüfung: 1. Ziel-IP oder DNS prüfen. 2. Routing prüfen. 3. TCP 22 erreichbar? 4. SSH-Dienst läuft? 5. Host-Firewall erlaubt? 6. zentrale Firewall erlaubt? 7. Benutzer oder Schlüssel korrekt? 8. SSH-Logs prüfen. 9. Fail2ban oder Sperre prüfen. 10. Host-Key-Warnung prüfen. Merksatz: SSH-Fehler mit Netz, Port, Dienst, Benutzer und Logs prüfen. --- **Beispiel: SMB-Freigabe Zugriff verweigert** Systematische Prüfung: 1. Servername löst korrekt auf? 2. TCP 445 erreichbar? 3. SMB-Dienst läuft? 4. Benutzer korrekt angemeldet? 5. Freigabeberechtigung korrekt? 6. Dateisystemberechtigung korrekt? 7. Gruppenmitgliedschaft korrekt? 8. gespeicherte Anmeldedaten falsch? 9. Datei gesperrt? 10. Logs prüfen. Merksatz: SMB-Zugriff braucht Verbindung, Anmeldung und Rechte. --- **Beispiel: E-Mail kommt nicht an** Systematische Prüfung: 1. Absender erhält Fehlermeldung? 2. MX-Record korrekt? 3. DNS korrekt? 4. SMTP TCP 25 erreichbar? 5. Mailserver zuständig? 6. Spamfilter oder Quarantäne? 7. SPF, DKIM, DMARC korrekt? 8. Postfach voll? 9. TLS-Problem? 10. Mailserver-Logs prüfen. Merksatz: Mailfehler mit DNS, SMTP, Authentifizierung, Spamfilter und Logs prüfen. --- **Beispiel: VPN verbunden, aber interne Systeme nicht erreichbar** Systematische Prüfung: 1. VPN-Verbindung wirklich aktiv? 2. VPN-IP erhalten? 3. Route ins interne Netz vorhanden? 4. DNS für interne Namen korrekt? 5. Firewall-Regel VPN → Zielnetz korrekt? 6. Benutzergruppe berechtigt? 7. Split Tunnel korrekt? 8. Zielsystem-Firewall erlaubt? 9. Rückweg korrekt? 10. Logs prüfen. Merksatz: VPN braucht Tunnel, Adresse, Route, DNS, Firewall und Rechte. --- **Beispiel: Nur langsam, nicht komplett kaputt** Bei Performanceproblemen prüft man zusätzlich: Latenz Paketverlust Bandbreite Duplex WLAN-Signal Retransmissions Serverlast DNS-Verzögerungen MTU Proxy VPN Speicher und CPU Festplatten-I/O Merksatz: Langsam ist nicht dasselbe wie nicht erreichbar. --- **Latenz** Latenz ist die Verzögerung, bis Daten ihr Ziel erreichen und eine Antwort zurückkommt. Hohe Latenz stört besonders: VoIP Videokonferenzen Remote Desktop Online-Anwendungen Datenbankzugriffe interaktive Anwendungen Merksatz: Latenz = Verzögerung. --- **Paketverlust** Paketverlust bedeutet: Pakete gehen unterwegs verloren. Folgen: Verbindungen werden langsam. TCP sendet erneut. Audio oder Video stottert. VPN wird instabil. Webseiten laden unvollständig. Hinweise: Retransmissions verlorene Ping-Antworten Abbrüche Timeouts Merksatz: Paketverlust erzeugt Wiederholungen und Instabilität. --- **Bandbreite** Bandbreite beschreibt, wie viele Daten pro Zeit übertragen werden können. Geringe Bandbreite führt zu: langsamen Downloads ruckelnden Streams langen Backups langsamer Dateiübertragung Engpässen bei vielen Benutzern Merksatz: Bandbreite = maximale Datenmenge pro Zeit. --- **Jitter** Jitter ist die Schwankung der Verzögerung. Besonders störend bei: VoIP Videokonferenzen Echtzeitanwendungen Streaming Remote-Zugriff Merksatz: Jitter = schwankende Latenz. --- **MTU** MTU steht für: Maximum Transmission Unit MTU beschreibt, wie groß ein Paket auf einem Übertragungsweg maximal sein darf. MTU-Probleme können verursachen: Webseiten laden teilweise. VPN ist instabil. große Downloads brechen ab. kleine Pings funktionieren, große Pakete nicht. Merksatz: MTU-Probleme zeigen sich oft erst bei größeren Paketen. --- **Fehlerklasse: Erreichbarkeit** Erreichbarkeitsfehler bedeuten: Ziel ist gar nicht oder nur teilweise erreichbar. Prüfen: Link IP Gateway Routing Firewall NAT Port Dienst Merksatz: Erreichbarkeit zuerst technisch eingrenzen. --- **Fehlerklasse: Namensauflösung** Namensauflösungsfehler bedeuten: Name wird nicht oder falsch aufgelöst. Prüfen: DNS-Server DNS-Record DNS-Suffix Split DNS Cache A/AAAA CNAME MX interne und externe Antwort Merksatz: Name falsch bedeutet oft Ziel falsch. --- **Fehlerklasse: Authentifizierung** Authentifizierungsfehler bedeuten: Identität wird nicht akzeptiert. Prüfen: Benutzername Passwort MFA Konto gesperrt Konto deaktiviert Zertifikat Token Zeit LDAP/AD/IdP Merksatz: Authentifizierung = Wer bist du? --- **Fehlerklasse: Autorisierung** Autorisierungsfehler bedeuten: Identität ist bekannt, aber Rechte fehlen. Prüfen: Gruppen Rollen Freigaberechte Dateisystemrechte API-Scopes Richtlinien Mandant alte Session Merksatz: Autorisierung = Was darfst du? --- **Fehlerklasse: Anwendung** Anwendungsfehler bedeuten: Netzwerkverbindung besteht, aber der Dienst funktioniert nicht korrekt. Prüfen: Logs Statuscodes Backend Datenbank Konfiguration Version Abhängigkeiten Speicher CPU Berechtigungen Datenformat Merksatz: Wenn Netzwerk steht, aber Dienst fehlerhaft antwortet, Anwendung prüfen. --- **Fehlerklasse: Sicherheit** Sicherheitsmechanismen können Verkehr bewusst blockieren. Beispiele: Firewall IDS/IPS WAF Antivirus EDR Spamfilter Proxy MFA Conditional Access Geoblocking Rate Limiting Merksatz: Nicht jede Blockierung ist ein Fehler, manchmal ist sie gewollt. --- **Abschluss einer Fehlersuche** Am Ende sollte klar sein: Was war die Ursache? Wie wurde sie nachgewiesen? Was wurde geändert? Welche Systeme waren betroffen? Wie wurde getestet? Ist die Lösung dauerhaft? Muss dokumentiert werden? Muss Monitoring angepasst werden? Muss Prävention verbessert werden? Merksatz: Eine Fehlersuche endet mit Ursache, Lösung und Dokumentation. --- **Typische IHK-Fragen** In AP1 und AP2 kann zum Beispiel gefragt werden: - Warum hilft das OSI-Modell bei der Fehlersuche? - Was bedeutet Bottom-Up-Fehlersuche? - Was bedeutet Top-Down-Fehlersuche? - Was ist Divide and Conquer bei der Fehlersuche? - Warum muss man Fehler genau eingrenzen? - Warum reicht „Internet geht nicht“ nicht als Fehlerbeschreibung? - Welche Schichten prüft man bei fehlender Verbindung? - Warum prüft man DNS frühzeitig? - Warum sind Logs wichtig? - Warum sollte man nicht mehrere Dinge gleichzeitig ändern? - Was ist ein Workaround? - Was ist der Unterschied zwischen Authentifizierung und Autorisierung? - Wie geht man bei einem Webfehler systematisch vor? - Wie geht man bei DHCP-Problemen systematisch vor? - Wie geht man bei VPN-Problemen systematisch vor? --- **Typische Prüfungsfallen** Nicht sofort die Firewall beschuldigen. Nicht nur ping testen. Nicht nur Port testen. DNS kann viele Fehler verursachen. DHCP gehört zu Schicht 7, wirkt aber auf Schicht 3. Firewall kann mehrere Schichten betreffen. NAT verändert Adressen und Ports. Ein einzelner Benutzer deutet oft auf Konto oder Client. Alle Benutzer deuten eher auf zentrale Infrastruktur. Intern und extern getrennt prüfen. WLAN und LAN getrennt prüfen. Authentifizierung ist nicht Autorisierung. Workaround ist nicht Ursachenbehebung. Eine Änderung pro Testschritt. Nach Änderung zuerst Änderung prüfen. Logs und Mitschnitt ergänzen sich. Langsam ist ein anderes Fehlerbild als nicht erreichbar. --- **Wichtige Begriffe kurz erklärt** | Begriff | Kurze Erklärung | |---|---| | Fehlersuche | systematisches Finden einer Ursache | | Bottom-Up | von Schicht 1 nach oben prüfen | | Top-Down | von Anwendung nach unten prüfen | | Divide and Conquer | Suchbereich durch mittlere Prüfung eingrenzen | | Vergleichsmethode | funktionierenden und fehlerhaften Fall vergleichen | | Fehlerbild | beobachtetes Problem | | Reproduzierbarkeit | Fehler lässt sich gezielt erneut auslösen | | Hypothese | testbare Vermutung | | Workaround | vorübergehende Umgehung | | Ursachenbehebung | eigentliche Ursache beseitigen | | Rollback | Änderung zurücknehmen | | Latenz | Verzögerung | | Paketverlust | Pakete gehen verloren | | Bandbreite | Datenmenge pro Zeit | | Jitter | Schwankung der Verzögerung | | MTU | maximale Paketgröße | | Authentifizierung | Identität prüfen | | Autorisierung | Rechte prüfen | | Log | Ereignisprotokoll | | Paketmitschnitt | aufgezeichneter Netzwerkverkehr | --- **IHK-sichere Kurzformulierung** Das OSI-Modell hilft bei der Netzwerkfehlersuche, weil Fehler systematisch nach Schichten eingegrenzt werden können. Bei der Bottom-Up-Methode beginnt man bei Schicht 1 mit physischer Verbindung und arbeitet sich bis zur Anwendungsschicht hoch. Bei der Top-Down-Methode beginnt man bei der Anwendung und prüft dann nach unten. Wichtig sind eine genaue Fehlerbeschreibung, die Eingrenzung betroffener Benutzer und Systeme, die Prüfung von DNS, DHCP, IP-Konfiguration, Routing, Firewall, NAT, Ports, Diensten, Authentifizierung, Autorisierung und Logs. Messergebnisse sollten dokumentiert werden, und Änderungen sollten einzeln getestet werden. Ein Workaround kann kurzfristig helfen, ersetzt aber nicht die Beseitigung der eigentlichen Ursache. --- **Merksätze** OSI-Modell hilft bei Fehlersuche. Nicht raten, sondern schrittweise prüfen. Bottom-Up beginnt bei Schicht 1. Top-Down beginnt bei der Anwendung. Divide and Conquer grenzt den Fehlerbereich ein. Fehlerbild genau aufnehmen. Einzelner Benutzer: Konto oder Client prüfen. Alle Benutzer: Dienst oder Infrastruktur prüfen. Intern und extern getrennt prüfen. WLAN und LAN getrennt prüfen. DNS früh prüfen. DHCP mit DORA prüfen. Firewall mit Quelle, Ziel, Port, Richtung und Logs prüfen. NAT vor und nach Übersetzung denken. Logs zeigen Entscheidungen. Mitschnitte zeigen Verkehr. Nach Änderung zuerst Änderung prüfen. Eine Änderung pro Test. Workaround ist nicht Ursache. Langsam ist nicht gleich nicht erreichbar. Latenz = Verzögerung. Paketverlust = verlorene Pakete. Jitter = schwankende Verzögerung. MTU = maximale Paketgröße. Authentifizierung = Wer bist du? Autorisierung = Was darfst du? Fehlersuche endet mit Ursache, Lösung und Dokumentation. # 12.5 Typische Netzwerkfehler und ihre Ursachen Netzwerkfehler können auf vielen verschiedenen Schichten entstehen. Ein sichtbares Problem ist oft nur ein Symptom. Beispiel: Webseite öffnet nicht. Das kann viele Ursachen haben: - DNS falsch - Server nicht erreichbar - Port blockiert - Zertifikat ungültig - Webserver down - Reverse Proxy falsch - Benutzer nicht berechtigt Merksatz: Ein Fehlerbild zeigt nur das Symptom, nicht automatisch die Ursache. --- **Warum Fehlerbilder wichtig sind** Fehlerbilder helfen, die Suche einzugrenzen. Man fragt: Was genau funktioniert nicht? Was funktioniert noch? Wer ist betroffen? Seit wann? Wurde etwas geändert? Ist der Fehler dauerhaft oder sporadisch? Gibt es eine Fehlermeldung? Je genauer das Fehlerbild, desto schneller findet man die Ursache. Merksatz: Gute Fehlerbeschreibung ist der erste Diagnoseschritt. --- **Fehlerbild: Kein Netzwerklink** Typische Anzeichen: - keine Link-LED - Netzwerkadapter zeigt getrennt - Switchport down - keine Verbindung über Kabel - keine Pakete sichtbar - kein DHCP Discover Mögliche Ursachen: - Kabel defekt - Kabel nicht richtig gesteckt - falscher Port - Switchport deaktiviert - Netzwerkkarte deaktiviert - SFP-Modul defekt - falsches Glasfasermodul - Stromversorgung fehlt Wahrscheinliche Schicht: Schicht 1 Merksatz: Kein Link ist meistens ein physisches Problem. --- **Fehlerbild: Link vorhanden, aber keine IP-Adresse** Typische Anzeichen: - Netzwerk verbunden - aber keine gültige IP-Adresse - Windows zeigt 169.254.x.x - DHCP schlägt fehl - keine Verbindung zum Gateway - Client meldet eingeschränkte Konnektivität Mögliche Ursachen: - DHCP-Server nicht erreichbar - DHCP-Scope voll - DHCP-Relay fehlt - falsches VLAN - Firewall blockiert UDP 67/68 - Switchport falsch konfiguriert - Client im falschen Netz - DHCP-Dienst gestoppt Wahrscheinliche Schichten: Schicht 2 Schicht 3 Schicht 7 wegen DHCP Merksatz: 169.254.x.x deutet häufig auf DHCP-Probleme hin. --- **Fehlerbild: Falsche IP-Adresse** Typische Anzeichen: - Client hat IP aus falschem Netz - Gateway passt nicht - DNS passt nicht - Zugriff auf interne Dienste funktioniert nicht - nur manche Dienste erreichbar Mögliche Ursachen: - falsches VLAN - falscher DHCP-Scope - Rogue-DHCP-Server - statische IP falsch gesetzt - falsches WLAN - falsche Netzwerkdose - DHCP-Reservierung falsch Wahrscheinliche Schichten: Schicht 2 Schicht 3 Schicht 7 wegen DHCP Merksatz: Falsche IP bedeutet oft: falsches Netz oder falsche DHCP-Konfiguration. --- **Fehlerbild: Gateway nicht erreichbar** Typische Anzeichen: - lokale IP vorhanden - andere Geräte im Netz eventuell erreichbar - Internet nicht erreichbar - Ping zum Gateway schlägt fehl - Routing funktioniert nicht Mögliche Ursachen: - falsches Gateway eingetragen - Gateway offline - VLAN falsch - falsche Netzmaske - ARP funktioniert nicht - Firewall blockiert ICMP - Switchport im falschen VLAN - IP-Konflikt Wahrscheinliche Schichten: Schicht 2 Schicht 3 Merksatz: Ohne Gateway keine Kommunikation in andere Netze. --- **Fehlerbild: Lokales Netz funktioniert, Internet nicht** Typische Anzeichen: - interne Server erreichbar - Gateway erreichbar - externe Webseiten nicht erreichbar - DNS oder Routing auffällig - nur Internetzugriff betroffen Mögliche Ursachen: - Standardroute fehlt - Internetrouter down - Firewall blockiert WAN - DNS falsch - NAT funktioniert nicht - Providerstörung - Proxy falsch - VPN verändert Routing - öffentliche Verbindung gestört Wahrscheinliche Schichten: Schicht 3 Schicht 4 Schicht 7 Merksatz: Intern geht, extern nicht: Gateway, DNS, NAT und Provider prüfen. --- **Fehlerbild: IP funktioniert, Name nicht** Typische Anzeichen: - Zugriff per IP funktioniert - Zugriff per DNS-Name funktioniert nicht - Browser meldet DNS-Fehler - nslookup liefert keine oder falsche Antwort - nur bestimmte Namen betroffen Mögliche Ursachen: - falscher DNS-Server - DNS-Eintrag fehlt - DNS-Eintrag zeigt falsch - DNS-Cache veraltet - Split DNS falsch - Suchsuffix falsch - interne Zone fehlt - IPv6-Record zeigt auf falsches Ziel Wahrscheinliche Schicht: Schicht 7 wegen DNS Merksatz: IP geht, Name nicht: DNS prüfen. --- **Fehlerbild: Name löst auf falsche IP auf** Typische Anzeichen: - DNS liefert Antwort - aber falscher Server wird erreicht - falsches Zertifikat erscheint - falsche Webseite wird angezeigt - intern und extern unterschiedliche Ergebnisse Mögliche Ursachen: - falscher A-Record - falscher AAAA-Record - falscher CNAME - Split DNS falsch - DNS-Cache alt - falscher DNS-Server - alte öffentliche IP - interne Zone überschreibt externe Zone Wahrscheinliche Schicht: Schicht 7 Merksatz: Falsche DNS-Antwort führt zum falschen Ziel. --- **Fehlerbild: Ping funktioniert, Dienst nicht** Typische Anzeichen: - Ziel antwortet auf Ping - aber Webseite, SSH, SMB oder RDP funktioniert nicht - Porttest schlägt fehl - Anwendung meldet Verbindungsfehler Mögliche Ursachen: - Dienst läuft nicht - Port blockiert - Host-Firewall blockiert - zentrale Firewall blockiert - Dienst lauscht auf falscher IP - falscher Port - falsches Protokoll - Anwendung falsch konfiguriert Wahrscheinliche Schichten: Schicht 4 Schicht 7 Merksatz: Ping beweist nicht, dass ein Dienst funktioniert. --- **Fehlerbild: Port offen, Anwendung funktioniert nicht** Typische Anzeichen: - Porttest erfolgreich - TCP-Verbindung möglich - aber Anwendung liefert Fehler - HTTP 500 oder 502 - Login schlägt fehl - API antwortet mit Fehler - Dienst bricht Verbindung ab Mögliche Ursachen: - Anwendung defekt - Backend nicht erreichbar - Datenbankfehler - falsche Konfiguration - Authentifizierungsproblem - Berechtigung fehlt - falsches Datenformat - Zertifikatsproblem - Reverse Proxy falsch Wahrscheinliche Schichten: Schicht 5 Schicht 6 Schicht 7 Merksatz: Offener Port ist nur Verbindung, nicht Anwendungserfolg. --- **Fehlerbild: Timeout** Timeout bedeutet: Es kommt keine Antwort innerhalb der erwarteten Zeit. Typische Anzeichen: - Verbindung hängt - Browser lädt lange - SSH wartet und bricht ab - Porttest läuft ins Timeout - SYN-Wiederholungen im Mitschnitt Mögliche Ursachen: - Firewall droppt Pakete - Ziel nicht erreichbar - Routingproblem - Rückweg fehlt - Dienst antwortet nicht - falsche IP - NAT falsch - Provider blockiert Wahrscheinliche Schichten: Schicht 3 Schicht 4 Schicht 7 Merksatz: Timeout bedeutet meistens: keine passende Antwort kommt zurück. --- **Fehlerbild: Connection Refused** Connection Refused bedeutet: Das Zielsystem lehnt die Verbindung aktiv ab. Typische Anzeichen: - schnelle Fehlermeldung - TCP RST im Mitschnitt - Host erreichbar - Port nimmt keine Verbindung an Mögliche Ursachen: - Dienst läuft nicht - falscher Port - Dienst lauscht nur auf localhost - Host-Firewall lehnt aktiv ab - Anwendung nimmt keine Verbindung an - Dienst wurde gestoppt Wahrscheinliche Schichten: Schicht 4 Schicht 7 Merksatz: Connection Refused heißt: Ziel erreichbar, aber Dienst nimmt nicht an. --- **Fehlerbild: Zugriff verweigert** Typische Anzeichen: - Anmeldung möglich - aber Ressource nicht zugänglich - HTTP 403 - SMB Zugriff verweigert - API meldet Forbidden - Anwendung zeigt keine Daten Mögliche Ursachen: - Gruppe fehlt - Rolle fehlt - Freigaberecht fehlt - Dateisystemrecht fehlt - API-Scope fehlt - falscher Mandant - Richtlinie blockiert - alte Session - Benutzer nicht autorisiert Wahrscheinliche Schicht: Schicht 7 Merksatz: Zugriff verweigert ist meistens ein Autorisierungsproblem. --- **Fehlerbild: Anmeldung schlägt fehl** Typische Anzeichen: - Login nicht möglich - HTTP 401 - falsche Zugangsdaten - MFA schlägt fehl - LDAP-Bind schlägt fehl - Kerberos-Fehler - Konto gesperrt Mögliche Ursachen: - Benutzername falsch - Passwort falsch - Konto gesperrt - Konto deaktiviert - Passwort abgelaufen - MFA nicht eingerichtet - Zeitabweichung - LDAP oder AD nicht erreichbar - falscher Identity Provider Wahrscheinliche Schicht: Schicht 7 Merksatz: Anmeldung fehlgeschlagen: Authentifizierung prüfen. --- **Fehlerbild: Zertifikatswarnung** Typische Anzeichen: - Browser warnt vor Zertifikat - Mailclient meldet Zertifikatsfehler - LDAPS oder HTTPS funktioniert nicht - Name passt nicht - Zertifikat abgelaufen - CA nicht vertrauenswürdig Mögliche Ursachen: - Zertifikat abgelaufen - falscher Hostname - falsches Zertifikat - Zwischenzertifikat fehlt - Systemzeit falsch - interne CA nicht vertraut - DNS zeigt auf falschen Server - Reverse Proxy liefert falsches Zertifikat Wahrscheinliche Schichten: Schicht 6 Schicht 7 Merksatz: Zertifikatsfehler mit Name, Zeit, CA und DNS prüfen. --- **Fehlerbild: Webseite zeigt 404** 404 bedeutet: Ressource nicht gefunden. Typische Ursachen: - falsche URL - falscher Pfad - Route fehlt - Datei fehlt - Reverse Proxy leitet falsch - Anwendung erwartet anderen Basis-Pfad - falscher virtueller Host Wahrscheinliche Schicht: Schicht 7 Merksatz: 404 bedeutet: Unter diesem Pfad wurde nichts gefunden. --- **Fehlerbild: Webseite zeigt 500** 500 bedeutet: interner Serverfehler. Typische Ursachen: - Fehler in Anwendung - Datenbank nicht erreichbar - Konfiguration falsch - fehlende Rechte - Anwendung abgestürzt - Speicherproblem - Backendfehler - Abhängigkeit fehlt Wahrscheinliche Schicht: Schicht 7 Merksatz: 500 ist meist ein Problem der Anwendung oder des Servers. --- **Fehlerbild: Webseite zeigt 502** 502 bedeutet: Bad Gateway Typisch bei Reverse Proxys. Mögliche Ursachen: - Backend nicht erreichbar - Backend läuft nicht - falscher Backend-Port - falsches Backend-Protokoll - DNS zum Backend falsch - Firewall blockiert Proxy zu Backend - Backend antwortet ungültig Wahrscheinliche Schicht: Schicht 7 Merksatz: 502 bedeutet oft: Proxy erreicht Backend nicht korrekt. --- **Fehlerbild: Webseite zeigt 503** 503 bedeutet: Dienst nicht verfügbar. Mögliche Ursachen: - Dienst gestoppt - Wartungsmodus - Server überlastet - Backend nicht verfügbar - Ressourcenmangel - Anwendung startet gerade - Load Balancer hat keine gesunden Backends Wahrscheinliche Schicht: Schicht 7 Merksatz: 503 bedeutet: Dienst ist aktuell nicht verfügbar. --- **Fehlerbild: Webseite zeigt 504** 504 bedeutet: Gateway Timeout Typisch: Proxy oder Gateway wartet zu lange auf Antwort vom Backend. Mögliche Ursachen: - Backend zu langsam - Backend hängt - Firewall blockiert Rückweg - Datenbank langsam - Timeout zu kurz - Netzwerkproblem zwischen Proxy und Backend Wahrscheinliche Schichten: Schicht 4 Schicht 7 Merksatz: 504 bedeutet: Gateway wartet vergeblich auf Backend-Antwort. --- **Fehlerbild: Mail kommt nicht an** Typische Anzeichen: - Absender erhält Bounce - Empfänger sieht keine Mail - Mail landet im Spam - Mail verzögert sich - SMTP-Fehler - NDR wird erzeugt Mögliche Ursachen: - MX-Record falsch - SMTP-Port blockiert - Mailserver nicht zuständig - Spamfilter blockiert - SPF, DKIM oder DMARC falsch - Postfach voll - Domain falsch - TLS-Problem - Blacklisting Wahrscheinliche Schicht: Schicht 7 Merksatz: Mailfehler mit DNS, SMTP, Spamfilter und Logs prüfen. --- **Fehlerbild: SMB-Freigabe nicht erreichbar** Typische Anzeichen: - Netzlaufwerk verbindet nicht - `\\server\freigabe` funktioniert nicht - Zugriff verweigert - Freigabe nicht gefunden - Benutzer sieht Netzlaufwerk nicht Mögliche Ursachen: - DNS-Name falsch - TCP 445 blockiert - SMB-Dienst läuft nicht - Freigabe existiert nicht - Benutzer nicht berechtigt - Freigabe- oder Dateisystemrechte falsch - gespeicherte Zugangsdaten falsch - SMB-Version inkompatibel Wahrscheinliche Schichten: Schicht 4 Schicht 7 Merksatz: SMB-Probleme mit Name, Port, Dienst und Rechten prüfen. --- **Fehlerbild: VPN verbunden, aber keine internen Dienste** Typische Anzeichen: - VPN zeigt verbunden - interne Server nicht erreichbar - DNS intern funktioniert nicht - nur Internet geht - bestimmte Netze fehlen Mögliche Ursachen: - Route fehlt - Split Tunnel falsch - interne DNS-Server fehlen - Firewall-Regel VPN → LAN fehlt - Benutzergruppe nicht berechtigt - Rückweg fehlt - Zielserver-Firewall blockiert - falscher VPN-Adresspool Wahrscheinliche Schichten: Schicht 3 Schicht 4 Schicht 7 Merksatz: VPN verbunden heißt nicht automatisch: interne Ressourcen erlaubt. --- **Fehlerbild: Nur manche Webseiten gehen nicht** Typische Anzeichen: - viele Webseiten funktionieren - einzelne Seiten nicht - bestimmte Domains nicht erreichbar - Zertifikatsfehler nur bei bestimmten Seiten - DNS oder Proxy auffällig Mögliche Ursachen: - DNS-Problem für bestimmte Domain - Proxy blockiert - Firewall-Kategorie blockiert - Zertifikatsproblem - IPv6-Problem - MTU-Problem - CDN-Störung - Geoblocking - Browsercache - HSTS-Problem Wahrscheinliche Schichten: Schicht 3 Schicht 6 Schicht 7 Merksatz: Einzelne Webseiten betroffen: DNS, Proxy, Zertifikat und IPv6 prüfen. --- **Fehlerbild: Verbindung ist langsam** Typische Anzeichen: - Webseiten laden langsam - Downloads langsam - RDP verzögert - VoIP stockt - Dateiübertragung langsam - Anwendungen reagieren träge Mögliche Ursachen: - hohe Latenz - Paketverlust - geringe Bandbreite - WLAN-Störung - Duplexproblem - überlasteter Server - überlastete Firewall - DNS-Verzögerung - VPN-Overhead - MTU-Problem Wahrscheinliche Schichten: alle Schichten möglich Merksatz: Langsam ist ein eigenes Fehlerbild, nicht einfach „geht nicht“. --- **Fehlerbild: Verbindung bricht sporadisch ab** Typische Anzeichen: - Verbindung funktioniert zeitweise - SSH bricht ab - VPN trennt sich - WLAN verliert Verbindung - RDP friert ein - Downloads brechen ab Mögliche Ursachen: - WLAN-Störungen - Paketverlust - DHCP-Lease-Probleme - instabile Leitung - MTU-Problem - Firewall-Timeout - NAT-Timeout - Serverüberlastung - Energieoptionen am Client - Roaming-Probleme Wahrscheinliche Schichten: Schicht 1 bis 7 möglich Merksatz: Sporadische Fehler brauchen Zeitbezug, Logs und Monitoring. --- **Fehlerbild: Nur große Dateien oder große Webseiten brechen ab** Typische Anzeichen: - kleine Webseiten gehen - große Downloads brechen ab - VPN instabil - Uploads hängen - TLS-Verbindung startet, hängt aber später Mögliche Ursachen: - MTU-Problem - Fragmentierung blockiert - Paketverlust - Proxy-Timeout - Firewall-Timeout - Upload-Limit - Speicherproblem - schlechte Verbindung Wahrscheinliche Schichten: Schicht 3 Schicht 4 Schicht 6 Schicht 7 Merksatz: Kleine Daten gehen, große nicht: MTU und Paketverlust prüfen. --- **Fehlerbild: Nur ein VLAN hat Probleme** Typische Anzeichen: - andere Netze funktionieren - ein Standort oder Netzsegment betroffen - DHCP nur dort gestört - Gateway nur dort nicht erreichbar - bestimmtes WLAN betroffen Mögliche Ursachen: - VLAN-ID falsch - Trunk lässt VLAN nicht durch - Access-Port falsch - DHCP-Scope falsch - DHCP-Relay fehlt - Gateway des VLANs down - Firewall-Regel für VLAN fehlt - Routing für VLAN fehlt Wahrscheinliche Schichten: Schicht 2 Schicht 3 Merksatz: Ein VLAN betroffen: VLAN, Gateway, DHCP und Routing prüfen. --- **Fehlerbild: Nur ein Standort hat Probleme** Typische Anzeichen: - andere Standorte funktionieren - WAN-Verbindung langsam oder down - lokale Dienste funktionieren, zentrale Dienste nicht - VPN oder MPLS gestört Mögliche Ursachen: - Standortleitung gestört - Router down - VPN-Tunnel down - Routingproblem - DNS lokal falsch - lokale Firewall blockiert - Bandbreite ausgelastet - Providerstörung Wahrscheinliche Schichten: Schicht 1 bis 4 Merksatz: Ein Standort betroffen: WAN, Router, VPN, DNS und lokale Infrastruktur prüfen. --- **Fehlerbild: Nur ein Benutzer hat Probleme** Typische Anzeichen: - andere Benutzer am gleichen Gerät funktionieren - Benutzer kann sich nicht anmelden - bestimmte Berechtigungen fehlen - Benutzer sieht Daten nicht - MFA funktioniert nicht Mögliche Ursachen: - Passwort falsch - Konto gesperrt - Gruppenmitgliedschaft fehlt - Rolle fehlt - Profilproblem - MFA falsch eingerichtet - Lizenz fehlt - gespeicherte Zugangsdaten falsch - Session alt Wahrscheinliche Schicht: Schicht 7 Merksatz: Einzelner Benutzer: Konto, Rechte und Profil prüfen. --- **Fehlerbild: Nur ein Client hat Probleme** Typische Anzeichen: - andere Clients funktionieren - gleicher Benutzer auf anderem Gerät funktioniert - lokaler Browserfehler - lokales Netzwerkproblem - falsche IP oder DNS nur auf diesem Client Mögliche Ursachen: - falsche IP-Konfiguration - falscher DNS - lokale Firewall - Proxy-Einstellungen - VPN aktiv oder falsch - Zertifikatsspeicher - Browsercache - Malware oder Sicherheitssoftware - Treiberproblem - defektes Kabel oder WLAN Wahrscheinliche Schichten: Schicht 1 bis 7 Merksatz: Einzelner Client: lokale Konfiguration prüfen. --- **Fehlerbild: Alle Benutzer haben Probleme** Typische Anzeichen: - mehrere Clients betroffen - Dienst generell nicht erreichbar - zentrale Anwendung gestört - viele Tickets gleichzeitig - Monitoring schlägt an Mögliche Ursachen: - Server down - DNS-Störung - DHCP-Störung - Firewall-Änderung - Zertifikat abgelaufen - Datenbank down - Providerstörung - zentrales Update fehlerhaft - Authentifizierungsdienst gestört Wahrscheinliche Schichten: zentrale Infrastruktur oder Dienst Merksatz: Alle betroffen: zentralen Dienst und Infrastruktur prüfen. --- **Fehlerbild: Nach Update funktioniert Dienst nicht** Typische Anzeichen: - Fehler begann direkt nach Update - Anwendung startet nicht - neue Fehlermeldung - alte Konfiguration nicht kompatibel - Abhängigkeiten fehlen Mögliche Ursachen: - Versionskonflikt - geänderte Konfigurationsoption - Dienst startet nicht - Rechte geändert - Datenbankmigration fehlgeschlagen - Zertifikat oder TLS geändert - Firewall- oder Portänderung - Cacheproblem Wahrscheinliche Schicht: meist Schicht 7, teilweise Schicht 4 bis 6 Merksatz: Nach Update zuerst Update, Logs und Kompatibilität prüfen. --- **Fehlerbild: Nach Firewall-Änderung funktioniert Dienst nicht** Typische Anzeichen: - Fehler direkt nach Regeländerung - bestimmte Verbindungen blockiert - nur bestimmte Richtung betroffen - Firewall-Logs zeigen Drops Mögliche Ursachen: - falsche Regelreihenfolge - falsche Quelle - falsches Ziel - falscher Port - TCP/UDP verwechselt - falsche Zone - NAT vergessen - Rückweg blockiert - temporäre Regel entfernt Wahrscheinliche Schicht: Schicht 3 / 4, je nach Firewall auch Schicht 7 Merksatz: Nach Firewall-Änderung: Regel, Richtung, NAT und Logs prüfen. --- **Fehlerbild: Nach DNS-Änderung falsches Ziel** Typische Anzeichen: - einige Clients erreichen neues Ziel - andere noch altes Ziel - Zertifikat passt nicht - falscher Server antwortet - interne und externe Antwort unterschiedlich Mögliche Ursachen: - DNS-Cache - TTL noch aktiv - falscher Record geändert - Split DNS vergessen - CNAME zeigt falsch - alter Record existiert noch - Client nutzt anderen DNS-Server Wahrscheinliche Schicht: Schicht 7 Merksatz: Nach DNS-Änderung: Cache, TTL und richtigen DNS-Server prüfen. --- **Fehlerbild: Nach Zertifikatserneuerung Fehler** Typische Anzeichen: - Browser warnt - TLS-Handshake scheitert - App verbindet nicht mehr - Reverse Proxy liefert altes Zertifikat - Zwischenzertifikat fehlt Mögliche Ursachen: - falsches Zertifikat installiert - Zertifikatskette unvollständig - privater Schlüssel passt nicht - Dienst nicht neu geladen - SNI falsch - Zertifikat enthält Namen nicht - Client vertraut CA nicht Wahrscheinliche Schichten: Schicht 6 Schicht 7 Merksatz: Zertifikatserneuerung braucht richtigen Namen, Schlüssel, Kette und Dienstreload. --- **Fehlerbild: Nach VLAN-Änderung keine Verbindung** Typische Anzeichen: - Client bekommt falsche oder keine IP - Gateway nicht erreichbar - bestimmter Switchport betroffen - WLAN-SSID betroffen - nur ein Netzsegment betroffen Mögliche Ursachen: - Access-Port falsches VLAN - Trunk erlaubt VLAN nicht - Native VLAN falsch - DHCP-Relay fehlt - Gateway für VLAN fehlt - Firewall-Regel für neues VLAN fehlt - Routing fehlt Wahrscheinliche Schichten: Schicht 2 Schicht 3 Merksatz: Nach VLAN-Änderung: VLAN-Zuordnung, Trunk, Gateway und DHCP prüfen. --- **Fehlerbild: Nach Passwortänderung Anwendung kaputt** Typische Anzeichen: - Dienst startet nicht - Anwendung kann Datenbank nicht erreichen - LDAP-Bind schlägt fehl - API-Zugriff schlägt fehl - wiederholte Loginfehler im Log Mögliche Ursachen: - Dienstkonto-Passwort geändert - Passwort nicht in Anwendung aktualisiert - Konto gesperrt - Secret falsch hinterlegt - Token abgelaufen - alte Session ungültig - gespeicherte Zugangsdaten falsch Wahrscheinliche Schicht: Schicht 7 Merksatz: Dienstkonten und gespeicherte Secrets bei Passwortänderungen beachten. --- **Erste Einordnung nach Fehlermeldung** | Fehlermeldung | erste Richtung | |---|---| | Kein Netzwerk | Schicht 1 bis 3 | | DNS-Name nicht gefunden | DNS | | Zeitüberschreitung | Routing, Firewall, Rückweg, Dienst | | Verbindung abgelehnt | Dienst oder Host-Firewall | | 401 Unauthorized | Authentifizierung | | 403 Forbidden | Autorisierung | | 404 Not Found | falscher Pfad oder Ressource fehlt | | 500 Internal Server Error | Anwendung oder Backend | | 502 Bad Gateway | Reverse Proxy oder Backend | | Zertifikat ungültig | TLS, DNS, Zeit oder CA | | Zugriff verweigert | Rechte | Merksatz: Fehlermeldung gibt Richtung, aber ersetzt keine Prüfung. --- **Erste Einordnung nach betroffener Menge** | Betroffen | wahrscheinliche Richtung | |---|---| | ein Benutzer | Konto, Rechte, MFA, Profil | | ein Client | lokale Konfiguration | | ein Raum | Switch, WLAN, VLAN | | ein VLAN | VLAN, DHCP, Gateway, Firewall | | ein Standort | WAN, Router, Provider, VPN | | alle Benutzer | zentraler Dienst oder Infrastruktur | | nur extern | DNS extern, NAT, Firewall, Provider | | nur intern | DNS intern, Routing, Hairpin NAT, Firewall | Merksatz: Betroffene Menge hilft, die Fehlerstelle einzugrenzen. --- **Erste Einordnung nach Änderung** | Letzte Änderung | zuerst prüfen | |---|---| | Firewall-Regel | Quelle, Ziel, Port, Richtung, Logs | | NAT-Regel | öffentliche IP, Ziel, Port, Protokoll | | DNS-Eintrag | Record, TTL, Cache, interner/externer DNS | | Zertifikat | Name, Kette, Schlüssel, Dienstreload | | VLAN | Access, Trunk, Gateway, DHCP | | Update | Logs, Version, Konfiguration, Abhängigkeiten | | Passwort | Dienstkonto, Secret, Sperrung | | VPN | Route, DNS, Benutzergruppe, Firewall | | Rechte | Gruppen, Rollen, ACLs, Session | Merksatz: Die letzte Änderung ist oft der wichtigste Hinweis. --- **Was man vermeiden sollte** Nicht vorschnell: Firewall ausschalten alle Ports öffnen Any-Any erlauben Rechte auf Vollzugriff setzen Zertifikatswarnungen ignorieren DNS wild ändern mehrere Dinge gleichzeitig ändern Logs ignorieren Fehlermeldung nur überfliegen Workaround als Lösung stehen lassen Merksatz: Schnelle unsaubere Änderungen erzeugen neue Probleme. --- **Typische IHK-Fragen** In AP1 und AP2 kann zum Beispiel gefragt werden: - Warum ist ein Fehlerbild nur ein Symptom? - Was deutet auf ein DHCP-Problem hin? - Was bedeutet 169.254.x.x? - Warum reicht Ping nicht als Dienstprüfung? - Was bedeutet Timeout? - Was bedeutet Connection Refused? - Was bedeutet HTTP 401? - Was bedeutet HTTP 403? - Was bedeutet HTTP 404? - Was bedeutet HTTP 500? - Was bedeutet HTTP 502? - Warum kann DNS wie ein Firewallproblem wirken? - Warum kann ein Zertifikatsfehler durch DNS entstehen? - Wie grenzt man Fehler nach betroffenen Benutzern ein? - Warum ist die letzte Änderung wichtig? --- **Typische Prüfungsfallen** Symptom ist nicht Ursache. 169.254.x.x deutet auf DHCP-Problem. Ping reicht nicht für Dienstprüfung. Port offen reicht nicht für Anwendungserfolg. Timeout und Connection Refused unterscheiden. 401 ist Authentifizierung. 403 ist Autorisierung. 404 ist Ressource oder Pfad. 500 ist Anwendung oder Server. 502 ist häufig Proxy zu Backend. DNS früh prüfen. Zertifikat hängt mit Name, Zeit und Vertrauen zusammen. Einzelner Benutzer bedeutet oft Konto oder Rechte. Alle Benutzer bedeutet eher Infrastruktur. Nur intern oder nur extern getrennt prüfen. Letzte Änderung zuerst prüfen. Nicht mehrere Dinge gleichzeitig ändern. --- **Wichtige Begriffe kurz erklärt** | Begriff | Kurze Erklärung | |---|---| | Fehlerbild | sichtbares Symptom eines Problems | | Ursache | eigentlicher technischer Grund | | Symptom | beobachtbare Auswirkung | | Timeout | keine Antwort innerhalb der Zeit | | Connection Refused | Ziel lehnt aktiv ab | | APIPA | automatische 169.254.x.x-Adresse | | NXDOMAIN | DNS-Name existiert nicht | | HTTP 401 | nicht authentifiziert | | HTTP 403 | nicht berechtigt | | HTTP 404 | nicht gefunden | | HTTP 500 | interner Serverfehler | | HTTP 502 | Bad Gateway | | Rückweg | Antwortweg zurück zur Quelle | | Split DNS | intern und extern unterschiedliche DNS-Antwort | | Hairpin NAT | interner Zugriff über öffentliche Adresse | | Rogue DHCP | unerwünschter DHCP-Server | | Dienstkonto | Konto für Anwendung oder Dienst | | Workaround | vorübergehende Umgehung | | Root Cause | eigentliche Ursache | --- **IHK-sichere Kurzformulierung** Typische Netzwerkfehler müssen anhand ihres Fehlerbildes systematisch eingeordnet werden. Ein Symptom wie „Webseite öffnet nicht“ kann Ursachen auf verschiedenen OSI-Schichten haben, zum Beispiel DNS, Routing, Firewall, Port, TLS, Anwendung oder Berechtigung. Eine Adresse aus dem Bereich 169.254.0.0/16 deutet häufig auf ein DHCP-Problem hin. Ein erfolgreicher Ping beweist nicht, dass ein Dienst funktioniert, und ein offener Port beweist nicht, dass die Anwendung korrekt arbeitet. Timeout, Connection Refused, HTTP-Statuscodes, Zertifikatswarnungen und Zugriff-verweigert-Meldungen geben Hinweise auf die Fehlerursache, müssen aber durch Tests, Logs und Konfigurationsprüfung bestätigt werden. --- **Merksätze** Fehlerbild ist Symptom, nicht Ursache. Gute Fehlerbeschreibung spart Zeit. Kein Link: Schicht 1 prüfen. 169.254.x.x: DHCP prüfen. Gateway nicht erreichbar: Schicht 2 und 3 prüfen. IP geht, Name nicht: DNS prüfen. Ping geht, Dienst nicht: Port, Firewall und Dienst prüfen. Port offen, Anwendung kaputt: Schicht 7 prüfen. Timeout: keine passende Antwort. Connection Refused: Ziel lehnt aktiv ab. Zugriff verweigert: Autorisierung prüfen. Login fehlgeschlagen: Authentifizierung prüfen. Zertifikatsfehler: Name, Zeit, CA und DNS prüfen. 404: Pfad oder Ressource fehlt. 500: Anwendung oder Serverproblem. 502: Proxy erreicht Backend nicht sauber. 503: Dienst nicht verfügbar. 504: Gateway wartet zu lange. Mailfehler: DNS, SMTP und Logs prüfen. SMB-Fehler: TCP 445, Anmeldung und Rechte prüfen. VPN verbunden heißt nicht: Zugriff erlaubt. Langsam ist nicht gleich nicht erreichbar. Kleine Daten gehen, große nicht: MTU prüfen. Ein Benutzer: Konto und Rechte prüfen. Ein Client: lokale Konfiguration prüfen. Alle Benutzer: zentrale Infrastruktur prüfen. Letzte Änderung zuerst prüfen. # 12.6 Logauswertung, Monitoring und Dokumentation bei Netzwerkfehlern Logs und Monitoring sind wichtige Hilfsmittel bei der Fehlersuche. Ein Paketmitschnitt zeigt, welche Pakete übertragen werden. Logs zeigen, was Systeme, Dienste, Firewalls und Anwendungen entschieden oder gemeldet haben. Monitoring zeigt, ob Systeme und Dienste dauerhaft verfügbar und leistungsfähig sind. Merksatz: Mitschnitt zeigt Verkehr. Logs zeigen Ereignisse. Monitoring zeigt Zustand über Zeit. --- **Warum Logs wichtig sind** Viele Fehler sind ohne Logs schwer zu verstehen. Beispiele: Benutzer kann sich nicht anmelden. Firewall blockiert Verbindung. Webserver liefert HTTP 500. Datenbank lehnt Verbindung ab. Zertifikat wird abgelehnt. VPN-Verbindung wird getrennt. DHCP vergibt keine Adresse. DNS liefert falsche Antwort. Ohne Logs sieht man oft nur das Symptom. Merksatz: Logs liefern Hinweise auf die Ursache. --- **Was ist ein Log?** Ein Log ist ein Ereignisprotokoll. Darin steht, was ein System oder Dienst festgestellt hat. Typische Angaben: - Zeitpunkt - Quelle - Ziel - Benutzer - Dienst - Aktion - Fehlercode - Meldung - Schweregrad - betroffene Komponente Merksatz: Ein Log ist ein technisches Ereignistagebuch. --- **Typische Logquellen** Wichtige Logquellen in Netzwerken: - Firewall-Logs - Router-Logs - Switch-Logs - DNS-Logs - DHCP-Logs - VPN-Logs - Webserver-Logs - Reverse-Proxy-Logs - Authentifizierungslogs - Mailserver-Logs - Datenbank-Logs - Betriebssystem-Logs - Anwendungslogs - Cloud-Logs - Monitoring-Alarme Merksatz: Die richtige Logquelle hängt vom Fehlerbild ab. --- **Firewall-Logs** Firewall-Logs zeigen, ob Verkehr erlaubt oder blockiert wurde. Wichtige Informationen: - Quelle - Ziel - Quellport - Zielport - Protokoll - Aktion - Regelname - Interface - Zone - NAT-Übersetzung - Zeit Beispiele für Aktionen: allow deny drop reject Merksatz: Firewall-Logs zeigen, welche Regel wirklich gegriffen hat. --- **Firewall-Log richtig lesen** Bei Firewall-Logs prüft man: Kommt der Verkehr an der Firewall an? Welche Quelle sieht die Firewall? Welches Ziel sieht die Firewall? Welcher Port wird genutzt? TCP oder UDP? Wird erlaubt oder blockiert? Welche Regel trifft? Ist NAT sichtbar? Gibt es Rückverkehr? Merksatz: Nicht die gedachte Regel zählt, sondern die tatsächlich getroffene Regel. --- **Keine Firewall-Logs sichtbar** Wenn kein passender Logeintrag sichtbar ist, kann das bedeuten: Verkehr kommt gar nicht bei der Firewall an. falsche Firewall wird geprüft. falsches Interface wird geprüft. Logging ist deaktiviert. DNS zeigt auf ein anderes Ziel. Route geht anderen Weg. Client sendet keine Anfrage. vorgeschaltetes Gerät blockiert. Zeitfilter ist falsch gesetzt. Merksatz: Kein Log heißt nicht automatisch: Firewall ist unschuldig. --- **Router-Logs** Router-Logs helfen bei: Routingproblemen Verbindungsabbrüchen WAN-Störungen VPN-Tunneln Interface-Fehlern Nachbarschaftsproblemen Routing-Protokollen Typische Hinweise: Interface up/down Route geändert Tunnel down Paket verworfen Gateway nicht erreichbar Merksatz: Router-Logs zeigen Wege und Verbindungszustände. --- **Switch-Logs** Switch-Logs sind wichtig für Schicht 2. Sie zeigen zum Beispiel: Port up/down VLAN-Fehler STP-Änderungen Loop-Erkennung Port-Security-Verletzungen Duplex- oder Speed-Probleme MAC-Flapping PoE-Probleme Trunk-Probleme Merksatz: Switch-Logs helfen bei lokalen Netz- und VLAN-Problemen. --- **MAC-Flapping** MAC-Flapping bedeutet: dieselbe MAC-Adresse erscheint schnell wechselnd an verschiedenen Switchports. Mögliche Ursachen: - Netzwerkschleife - falsch angeschlossener Switch - falsche Link Aggregation - virtuelle Umgebung - fehlerhafte Redundanz - Loop über Patchkabel Merksatz: MAC-Flapping ist ein Warnzeichen für Schicht-2-Probleme. --- **STP-Logs** STP steht für: Spanning Tree Protocol STP verhindert Schleifen in Layer-2-Netzen. STP-Logs zeigen zum Beispiel: Topology Change Port Blocking Port Forwarding Root Bridge Wechsel Loop erkannt Merksatz: STP-Logs sind wichtig bei Schleifen und Broadcast-Stürmen. --- **DNS-Logs** DNS-Logs zeigen Namensauflösungen. Wichtige Fragen: Welcher Client fragt? Welcher Name wird gefragt? Welche Antwort wird geliefert? Gibt es NXDOMAIN? Gibt es SERVFAIL? Wird intern oder extern gefragt? Gibt es ungewöhnlich viele Anfragen? Merksatz: DNS-Logs zeigen, welche Namen tatsächlich aufgelöst werden. --- **DHCP-Logs** DHCP-Logs zeigen, wie IP-Adressen vergeben werden. Wichtige Informationen: - Client-MAC-Adresse - angebotene IP-Adresse - vergebene IP-Adresse - Lease-Zeit - Scope - DHCP-Optionen - Konflikte - Fehlermeldungen Typische Fehler: Scope voll falscher Scope DHCP-Relay fehlt Lease-Konflikt unbekannter Client Merksatz: DHCP-Logs erklären, warum ein Client welche IP bekommt oder nicht bekommt. --- **VPN-Logs** VPN-Logs zeigen, ob ein Tunnel aufgebaut wird und warum er scheitert. Wichtige Hinweise: Benutzername Client-IP VPN-IP Authentifizierung erfolgreich oder fehlgeschlagen Zertifikatsfehler MFA-Fehler Gruppenrichtlinie zugewiesene Routen Tunnel aufgebaut oder getrennt Fehlercode Merksatz: VPN verbunden heißt nicht automatisch: Zugriff auf interne Systeme erlaubt. --- **Webserver-Logs** Webserver-Logs zeigen HTTP-Anfragen und Antworten. Typische Angaben: - Client-IP - Zeitpunkt - Methode - Pfad - Statuscode - User-Agent - Antwortgröße - Bearbeitungszeit Beispiele: GET /index.html 200 POST /login 401 GET /admin 403 GET /missing 404 GET /app 500 Merksatz: Webserver-Logs zeigen, was die Anwendung oder der Webserver geantwortet hat. --- **Reverse-Proxy-Logs** Reverse-Proxy-Logs sind besonders wichtig bei veröffentlichten Webdiensten. Sie zeigen: - externer Client - Hostname - Pfad - Backend-Ziel - HTTP-Status - TLS-Informationen - Weiterleitungsfehler - Timeout - 502 oder 504 - ausgewähltes Backend Merksatz: Reverse-Proxy-Logs zeigen den Übergang vom Client zum Backend. --- **Authentifizierungslogs** Authentifizierungslogs zeigen, ob eine Anmeldung erfolgreich war oder nicht. Typische Hinweise: - Benutzername - Quelle - Zeitpunkt - Erfolg oder Fehler - falsches Passwort - Konto gesperrt - MFA erforderlich - Token ungültig - Gruppenmitgliedschaft - Kerberos- oder LDAP-Fehler Merksatz: Authentifizierungslogs beantworten: Wer wollte sich anmelden, und warum ging es nicht? --- **Autorisierungsfehler in Logs** Autorisierung bedeutet: Ein Benutzer ist bekannt, hat aber nicht die nötigen Rechte. Typische Hinweise: Access denied Forbidden Permission denied Insufficient privileges Missing role Group required Scope missing Merksatz: Authentifizierung prüft Identität. Autorisierung prüft Rechte. --- **Mailserver-Logs** Mailserver-Logs helfen bei E-Mail-Problemen. Sie zeigen: - eingehende Verbindung - ausgehende Verbindung - Absender - Empfänger - SMTP-Statuscode - Spamfilter-Entscheidung - TLS-Fehler - Zustellversuch - Bounce - Queue-Status Merksatz: Mailserver-Logs zeigen, wo eine E-Mail hängen bleibt oder abgelehnt wird. --- **Datenbank-Logs** Datenbank-Logs helfen bei Anwendungsfehlern. Typische Hinweise: - Verbindung fehlgeschlagen - Benutzer nicht berechtigt - Passwort falsch - Datenbank nicht erreichbar - SQL-Fehler - langsame Abfragen - Locking-Probleme - Speicher- oder Verbindungsgrenze erreicht Merksatz: HTTP 500 kann seine Ursache in der Datenbank haben. --- **Betriebssystem-Logs** Betriebssystem-Logs zeigen Systemereignisse. Beispiele: Dienst gestartet Dienst gestoppt Dienst abgestürzt Speicher voll Festplatte voll Netzwerkinterface down Treiberfehler Berechtigungsfehler Zeitproblem Zertifikatproblem Merksatz: Systemlogs zeigen, ob das Betriebssystem selbst Probleme meldet. --- **Anwendungslogs** Anwendungslogs sind oft die wichtigste Quelle bei Schicht-7-Problemen. Sie zeigen zum Beispiel: Konfigurationsfehler fehlende Datei Datenbankfehler API-Fehler Berechtigungsfehler ungültiges Datenformat ungültige Session Fehler beim Start Stacktrace Timeout zu Backend Merksatz: Wenn Netzwerk steht, aber Anwendung fehlschlägt, Anwendungslogs prüfen. --- **Cloud-Logs** In Cloud-Umgebungen gibt es zusätzliche Logquellen. Beispiele: - Security Groups - Network Security Groups - Load Balancer Logs - Cloud Firewall Logs - IAM Logs - Audit Logs - DNS Logs - API Gateway Logs - Container Logs - Kubernetes Events Merksatz: In Cloud-Umgebungen liegen Netzwerkentscheidungen oft in mehreren Diensten. --- **Container-Logs** Container-Logs zeigen Ausgaben der Anwendung im Container. Typische Hinweise: Dienst startet nicht. Port ist belegt. Datenbank nicht erreichbar. Umgebungsvariable fehlt. Berechtigung fehlt. Volume fehlt. DNS-Name im Docker-Netz falsch. Backend nicht erreichbar. Zertifikat fehlt. Merksatz: Container-Logs zeigen, was die Anwendung im Container meldet. --- **Zeitstempel in Logs** Zeitstempel sind entscheidend. Man muss prüfen: Stimmen Uhrzeiten der Systeme? Welche Zeitzone wird verwendet? Ist NTP korrekt? Passt der Fehlerzeitpunkt? Sind Logs in UTC oder lokaler Zeit? Sind Client, Server und Firewall zeitlich vergleichbar? Merksatz: Ohne korrekte Zeit sind Logs schwer vergleichbar. --- **NTP und Logs** NTP sorgt für korrekte Zeitsynchronisation. Falsche Uhrzeiten verursachen Probleme bei: Logvergleich Zertifikaten Kerberos MFA Tokens Monitoring Vorfallanalyse Merksatz: Korrekte Zeit ist Grundlage für sinnvolle Logauswertung. --- **Schweregrade in Logs** Logs haben oft Schweregrade. Typische Stufen: | Stufe | Bedeutung | |---|---| | Debug | sehr detaillierte Diagnoseinformationen | | Info | normale Information | | Warning | Warnung, mögliches Problem | | Error | Fehler | | Critical | schwerer Fehler | | Alert | sofortige Aufmerksamkeit nötig | | Emergency | System praktisch nicht mehr nutzbar | Merksatz: Nicht jede Warnung ist die Ursache, aber jede Warnung ist ein Hinweis. --- **Debug-Logs** Debug-Logs sind sehr detailliert. Vorteil: liefern viele Informationen Nachteil: erzeugen große Datenmengen können sensible Informationen enthalten können Leistung beeinflussen sind schwerer zu lesen Debug sollte oft nur gezielt und zeitlich begrenzt aktiviert werden. Merksatz: Debug nur gezielt und vorübergehend nutzen. --- **Logrotation** Logrotation bedeutet: alte Logdateien werden archiviert, komprimiert oder gelöscht, damit Speicherplatz nicht voll läuft. Wichtig: Logs dürfen nicht unkontrolliert wachsen. Problem: Wenn Speicher voll läuft, können Dienste ausfallen. Merksatz: Logrotation schützt vor volllaufenden Systemen. --- **Logaufbewahrung** Logaufbewahrung beschreibt, wie lange Logs gespeichert werden. Dabei spielen eine Rolle: - gesetzliche Vorgaben - Datenschutz - Sicherheitsanforderungen - Speicherplatz - Vorfallanalyse - Unternehmensrichtlinien Merksatz: Logs so lange wie nötig, aber nicht unnötig lange speichern. --- **Datenschutz bei Logs** Logs können personenbezogene oder sensible Daten enthalten. Beispiele: Benutzername IP-Adresse E-Mail-Adresse Standort Login-Zeit Gerät Fehlerdetails Tokens Session-Informationen Deshalb: Zugriff beschränken Zweck beachten Aufbewahrung regeln sensible Daten vermeiden Logs sicher speichern Merksatz: Logs sind oft personenbezogen und müssen geschützt werden. --- **Zentrale Logsammlung** In größeren Umgebungen werden Logs zentral gesammelt. Vorteile: - einheitliche Suche - bessere Korrelation - langfristige Auswertung - Alarmierung - Schutz vor Manipulation auf Einzelsystem - bessere Vorfallanalyse Beispiele für Konzepte: Syslog SIEM Logserver zentraler Monitoring-Stack Merksatz: Zentrale Logs erleichtern Analyse und Sicherheit. --- **Syslog** Syslog ist ein verbreitetes Verfahren, um Logs von Netzwerkgeräten und Servern zentral zu sammeln. Typische Quellen: Router Switches Firewalls Linux-Systeme Appliances Merksatz: Syslog sammelt Ereignisse zentral. --- **SIEM** SIEM steht für: Security Information and Event Management Ein SIEM sammelt, korreliert und bewertet sicherheitsrelevante Ereignisse. Es kann helfen bei: Angriffserkennung Compliance Vorfallanalyse Alarmierung Korrelation von Ereignissen ungewöhnlichem Verhalten Merksatz: SIEM verbindet Logs zu sicherheitsrelevanten Erkenntnissen. --- **Korrelation** Korrelation bedeutet: Ereignisse aus mehreren Quellen werden zusammen betrachtet. Beispiel: Firewall meldet blockierte Verbindung. Webserver meldet viele 404. Auth-Log meldet viele Loginfehler. IDS meldet Angriffsmuster. Zusammen kann daraus ein Angriff erkennbar werden. Merksatz: Einzelne Logs sind Hinweise, korrelierte Logs ergeben Zusammenhang. --- **Monitoring** Monitoring überwacht Systeme und Dienste dauerhaft. Es beantwortet Fragen wie: Ist der Dienst erreichbar? Ist der Server ausgelastet? Ist Speicherplatz knapp? Läuft der Prozess? Ist das Zertifikat bald abgelaufen? Ist die Latenz erhöht? Gibt es Paketverlust? Ist ein Standort offline? Merksatz: Monitoring erkennt Probleme, bevor Benutzer sie melden. --- **Monitoring-Arten** Typische Monitoring-Arten: - Verfügbarkeitsmonitoring - Performance-Monitoring - Netzwerkmonitoring - Dienstmonitoring - Logmonitoring - Sicherheitsmonitoring - Zertifikatsmonitoring - Kapazitätsmonitoring Merksatz: Monitoring kann Verfügbarkeit, Leistung, Sicherheit und Kapazität prüfen. --- **Verfügbarkeitsmonitoring** Verfügbarkeitsmonitoring prüft, ob ein System oder Dienst erreichbar ist. Beispiele: Ping erfolgreich? TCP-Port offen? HTTP-Status 200? DNS antwortet? VPN-Tunnel up? Datenbank erreichbar? Merksatz: Verfügbarkeit bedeutet: Dienst antwortet grundsätzlich. --- **Performance-Monitoring** Performance-Monitoring prüft Leistungswerte. Beispiele: CPU-Auslastung RAM-Auslastung Festplatten-I/O Netzwerklast Latenz Paketverlust Antwortzeit Datenbankabfragezeit Merksatz: Performance-Monitoring zeigt, ob ein Dienst langsam oder überlastet ist. --- **Netzwerkmonitoring** Netzwerkmonitoring prüft Netzwerkkomponenten. Beispiele: Switchports Router Firewalls Access Points VPN-Tunnel WAN-Leitungen Bandbreite Interface-Fehler Paketverlust Latenz Merksatz: Netzwerkmonitoring zeigt Zustand der Infrastruktur. --- **Dienstmonitoring** Dienstmonitoring prüft konkrete Dienste. Beispiele: Webserver läuft? Datenbank erreichbar? DNS antwortet? DHCP verfügbar? Mailqueue wächst? Reverse Proxy antwortet? API liefert erwarteten Status? Merksatz: Dienstmonitoring prüft, ob ein Dienst fachlich nutzbar ist. --- **Zertifikatsmonitoring** Zertifikatsmonitoring prüft TLS-Zertifikate. Wichtige Fragen: Wann läuft das Zertifikat ab? Passt der Hostname? Ist die Zertifikatskette gültig? Wird das richtige Zertifikat ausgeliefert? Ist die CA vertrauenswürdig? Merksatz: Zertifikate sollten überwacht werden, bevor sie ablaufen. --- **Kapazitätsmonitoring** Kapazitätsmonitoring prüft, ob Ressourcen knapp werden. Beispiele: Speicherplatz RAM CPU Bandbreite Datenbankgröße Loggröße Anzahl Verbindungen DHCP-Leases Lizenzgrenzen Merksatz: Kapazitätsprobleme kündigen sich oft vorher an. --- **Alarmierung** Monitoring ist nur hilfreich, wenn wichtige Probleme auch gemeldet werden. Alarmierung kann erfolgen über: E-Mail SMS App Dashboard Ticket Chat Pager Wichtig: Nicht zu viele unnötige Alarme, sonst werden wichtige Alarme ignoriert. Merksatz: Gute Alarmierung ist relevant, verständlich und handlungsfähig. --- **False Positive und False Negative** False Positive: Alarm, obwohl kein echtes Problem vorliegt. False Negative: Kein Alarm, obwohl ein echtes Problem vorliegt. Beides ist problematisch. Merksatz: Monitoring muss sinnvoll eingestellt und regelmäßig geprüft werden. --- **Schwellwerte** Schwellwerte legen fest, wann ein Alarm ausgelöst wird. Beispiele: CPU über 90 Prozent Speicherplatz unter 10 Prozent frei Zertifikat läuft in 14 Tagen ab Ping-Verlust über 5 Prozent Antwortzeit über 2 Sekunden HTTP-Status nicht 200 Merksatz: Schwellwerte müssen zum Dienst passen. --- **Trends** Monitoring zeigt nicht nur aktuelle Werte, sondern auch Entwicklungen. Beispiele: Speicherplatz wird jede Woche knapper. Antwortzeiten steigen langsam. Bandbreite ist montags überlastet. Logdateien wachsen ungewöhnlich stark. DHCP-Leases reichen bald nicht mehr. Merksatz: Trends helfen, Probleme vor dem Ausfall zu erkennen. --- **Baseline** Eine Baseline beschreibt, was für ein System normal ist. Beispiel: normale CPU-Auslastung normale Antwortzeit normale Anzahl Verbindungen normale DNS-Anfragen normale Bandbreite Ohne Baseline weiß man schwer, ob ein Wert auffällig ist. Merksatz: Baseline = normales Verhalten als Vergleichswert. --- **Dokumentation** Dokumentation beschreibt, wie ein System aufgebaut ist und wie es betrieben wird. Wichtige Inhalte: - Netzplan - IP-Adressplan - VLAN-Plan - Firewall-Regeln - NAT-Regeln - DNS-Zonen - DHCP-Scopes - Serverrollen - Dienste - Zugangspfade - Ansprechpartner - Änderungen - Notfallverfahren Merksatz: Gute Dokumentation beschleunigt Fehlersuche. --- **Netzplan** Ein Netzplan zeigt, wie Netzbereiche und Geräte verbunden sind. Er enthält zum Beispiel: Router Switches Firewalls Server VLANs Standorte VPNs DMZ Internetanschluss IP-Netze Merksatz: Netzplan zeigt, wie das Netzwerk aufgebaut ist. --- **IP-Adressplan** Ein IP-Adressplan zeigt, welche Netze und Adressen verwendet werden. Beispiele: 192.168.10.0/24 Clients 192.168.20.0/24 Server 192.168.30.0/24 DMZ 192.168.40.0/24 Management 192.168.50.0/24 Gäste Merksatz: IP-Adressplan verhindert Verwechslungen und Doppelvergaben. --- **VLAN-Dokumentation** Eine VLAN-Dokumentation enthält: VLAN-ID Name Subnetz Gateway DHCP-Scope Zweck zugehörige Switchports Trunks Firewall-Zone Merksatz: VLANs ohne Dokumentation führen schnell zu Fehlkonfigurationen. --- **Firewall- und NAT-Dokumentation** Dokumentiert werden sollten: Quelle Ziel Dienst Port Protokoll Richtung Zone NAT-Ziel Zweck Verantwortlicher Ticket Ablaufdatum bei temporären Regeln Merksatz: Firewall-Regeln ohne Zweck sind später schwer bewertbar. --- **DNS-Dokumentation** DNS-Dokumentation enthält: Zonen A-Records AAAA-Records CNAMEs MX-Records TXT-Records interne und externe Namen Split-DNS-Regeln TTL zuständige Systeme Merksatz: DNS-Dokumentation verhindert falsche Zielauflösungen. --- **DHCP-Dokumentation** DHCP-Dokumentation enthält: Scope Adressbereich Ausschlüsse Reservierungen Lease-Zeit Gateway-Option DNS-Option Relay-Adresse VLAN-Zuordnung Merksatz: DHCP-Dokumentation erklärt, warum Clients welche Konfiguration bekommen. --- **Änderungsdokumentation** Änderungen sollten nachvollziehbar sein. Wichtige Angaben: Was wurde geändert? Warum wurde es geändert? Wann wurde es geändert? Wer hat es geändert? Welche Systeme sind betroffen? Wie wurde getestet? Gibt es Rollback? Gibt es ein Ticket? Merksatz: Ohne Änderungsdokumentation ist Fehlersuche nach Änderungen schwer. --- **Incident-Dokumentation** Bei Störungen sollte dokumentiert werden: Startzeit Endezeit betroffene Systeme betroffene Benutzer Fehlerbild Ursache Maßnahmen Lösung Workaround Kommunikation Nacharbeiten Merksatz: Incident-Dokumentation hilft, aus Fehlern zu lernen. --- **Root Cause Analysis** Root Cause Analysis bedeutet: die eigentliche Ursache eines Problems finden. Nicht nur: Dienst neu starten Sondern fragen: Warum ist der Dienst abgestürzt? Warum war Speicher voll? Warum gab es keinen Alarm? Warum wurde die Logrotation nicht eingerichtet? Merksatz: Root Cause Analysis sucht die Ursache hinter dem Symptom. --- **Post-Mortem** Ein Post-Mortem ist eine Nachbesprechung nach einer Störung. Ziele: Ursache verstehen Ablauf rekonstruieren Verbesserungen finden Schuldzuweisungen vermeiden Maßnahmen ableiten Wiederholung verhindern Merksatz: Post-Mortem soll Systeme verbessern, nicht Personen beschuldigen. --- **Lessons Learned** Lessons Learned sind Erkenntnisse aus einer Störung. Beispiele: Monitoring muss erweitert werden. Zertifikate müssen überwacht werden. Firewall-Regeln müssen dokumentiert werden. Backups müssen getestet werden. Change-Prozess muss angepasst werden. Runbook muss erstellt werden. Merksatz: Lessons Learned machen aus Störungen Verbesserungen. --- **Runbook** Ein Runbook ist eine Schritt-für-Schritt-Anleitung für wiederkehrende Aufgaben oder Störungen. Beispiele: Webdienst neu starten Zertifikat erneuern VPN-Tunnel prüfen DHCP-Scope erweitern Firewall-Regel prüfen Backup wiederherstellen Merksatz: Runbooks machen wiederkehrende Arbeiten sicherer und schneller. --- **Checkliste für Logauswertung** 1. Fehlerzeitpunkt bestimmen. 2. Betroffene Systeme bestimmen. 3. Passende Logquelle auswählen. 4. Zeitfilter setzen. 5. Fehlermeldungen suchen. 6. Schweregrad beachten. 7. Ereignisse vor und nach dem Fehler prüfen. 8. Logs mehrerer Systeme vergleichen. 9. Zeitabweichungen beachten. 10. Ergebnis dokumentieren. Merksatz: Logs immer zeitlich und fachlich einordnen. --- **Checkliste für Monitoring** 1. Wird der Dienst überwacht? 2. Wird der richtige Port geprüft? 3. Wird die Anwendung geprüft oder nur Ping? 4. Gibt es sinnvolle Schwellwerte? 5. Gibt es Alarmierung? 6. Werden Zertifikate überwacht? 7. Werden Ressourcen überwacht? 8. Werden Trends betrachtet? 9. Gibt es zu viele Fehlalarme? 10. Werden Alarme bearbeitet? Merksatz: Monitoring muss den Dienst wirklich abbilden. --- **Checkliste für Dokumentation** 1. Netzplan aktuell? 2. IP-Adressplan aktuell? 3. VLANs dokumentiert? 4. Firewall-Regeln dokumentiert? 5. NAT-Regeln dokumentiert? 6. DNS-Einträge dokumentiert? 7. DHCP-Scopes dokumentiert? 8. Verantwortliche bekannt? 9. Änderungen dokumentiert? 10. Notfallverfahren vorhanden? Merksatz: Dokumentation ist ein Werkzeug, nicht nur Verwaltung. --- **Typische Fehler bei Logs und Monitoring** Häufige Fehler: Logs werden nicht aktiviert. Logs werden zu kurz gespeichert. Logs laufen voll. Zeitstempel stimmen nicht. falsche Zeitzone wird übersehen. Monitoring prüft nur Ping. Zertifikate werden nicht überwacht. Alarme gehen an niemanden. zu viele Fehlalarme entstehen. Dokumentation ist veraltet. Änderungen werden nicht dokumentiert. Root Cause wird nicht gesucht. Merksatz: Logs und Monitoring müssen gepflegt werden. --- **Typische IHK-Fragen** In AP1 und AP2 kann zum Beispiel gefragt werden: - Warum sind Logs bei der Fehlersuche wichtig? - Welche Informationen enthält ein Firewall-Log? - Warum ist die Uhrzeit bei Logs wichtig? - Warum ist NTP für Logauswertung wichtig? - Was ist Monitoring? - Was ist der Unterschied zwischen Verfügbarkeits- und Performance-Monitoring? - Warum reicht Ping-Monitoring nicht immer aus? - Was ist ein Schwellwert? - Was ist eine Baseline? - Warum müssen Zertifikate überwacht werden? - Was gehört in eine Netzwer dokumentation? - Warum ist Änderungsdokumentation wichtig? - Was ist eine Root Cause Analysis? - Was ist ein Runbook? - Warum können Logs personenbezogene Daten enthalten? --- **Typische Prüfungsfallen** Logs zeigen Ereignisse, nicht automatisch die Ursache. Monitoring zeigt Zustand über Zeit. Ping-Monitoring reicht nicht für Anwendungserfolg. Firewall-Logs zeigen getroffene Regeln. Kein Log kann auch falschen Weg bedeuten. Zeitstempel müssen vergleichbar sein. NTP ist wichtig für Logs, Zertifikate und Authentifizierung. Debug-Logs nur gezielt aktivieren. Logs können sensible Daten enthalten. Logrotation verhindert volle Datenträger. Zentrale Logsammlung erleichtert Analyse. SIEM korreliert sicherheitsrelevante Ereignisse. Monitoring braucht sinnvolle Schwellwerte. Zu viele Fehlalarme führen zu Alarmmüdigkeit. Baseline zeigt normales Verhalten. Dokumentation muss aktuell sein. Änderung ohne Dokumentation erschwert Fehlersuche. Root Cause ist wichtiger als nur Neustart. Runbooks helfen bei wiederkehrenden Aufgaben. --- **Wichtige Begriffe kurz erklärt** | Begriff | Kurze Erklärung | |---|---| | Log | Ereignisprotokoll | | Logquelle | System oder Dienst, der Logs erzeugt | | Firewall-Log | Protokoll von erlaubtem oder blockiertem Verkehr | | Systemlog | Betriebssystemereignisse | | Anwendungslog | Meldungen einer Anwendung | | Debug-Log | sehr detaillierte Diagnoseausgabe | | Logrotation | Archivieren oder Löschen alter Logs | | Logaufbewahrung | Zeitraum der Speicherung | | Syslog | Verfahren zur zentralen Logsammlung | | SIEM | System zur Sicherheitsauswertung von Logs | | Korrelation | Zusammenführen mehrerer Ereignisse | | Monitoring | dauerhafte Überwachung | | Schwellwert | Grenze für Alarmierung | | False Positive | Fehlalarm | | False Negative | fehlender Alarm trotz Problem | | Baseline | normales Verhalten als Vergleich | | Netzplan | grafische Netzdokumentation | | IP-Adressplan | Übersicht verwendeter Netze und Adressen | | Änderungsdokumentation | Nachweis von Änderungen | | Incident | Störung oder Sicherheitsvorfall | | Root Cause Analysis | Suche nach eigentlicher Ursache | | Post-Mortem | Nachbesprechung nach Störung | | Lessons Learned | Erkenntnisse zur Verbesserung | | Runbook | Schritt-für-Schritt-Anleitung | --- **IHK-sichere Kurzformulierung** Logs, Monitoring und Dokumentation sind zentrale Bestandteile der Netzwerkfehlersuche. Logs zeigen Ereignisse und Entscheidungen von Systemen, Diensten, Firewalls, Anwendungen und Betriebssystemen. Monitoring überwacht Verfügbarkeit, Leistung, Kapazität und Sicherheit über einen längeren Zeitraum und kann Probleme frühzeitig melden. Wichtig sind korrekte Zeitstempel, NTP, sinnvolle Schwellwerte, Logrotation, Datenschutz und zentrale Logsammlung. Dokumentation wie Netzplan, IP-Adressplan, VLAN-Plan, Firewall-Regeln, NAT-Regeln, DNS-Einträge und DHCP-Scopes hilft, Fehler schneller einzugrenzen. Nach Störungen sollten Ursache, Maßnahmen und Verbesserungen dokumentiert werden. --- **Merksätze** Mitschnitt zeigt Verkehr. Logs zeigen Ereignisse. Monitoring zeigt Zustand über Zeit. Dokumentation zeigt Aufbau und Änderungen. Firewall-Logs zeigen getroffene Regeln. DNS-Logs zeigen Namensauflösung. DHCP-Logs zeigen Adressvergabe. VPN-Logs zeigen Tunnel und Anmeldung. Webserver-Logs zeigen HTTP-Antworten. Reverse-Proxy-Logs zeigen Backend-Probleme. Authentifizierungslogs zeigen Loginprobleme. Anwendungslogs zeigen Schicht-7-Fehler. Zeitstempel müssen stimmen. NTP ist wichtig für Logvergleich. Debug nur gezielt aktivieren. Logs können sensible Daten enthalten. Logrotation verhindert volle Datenträger. Zentrale Logs erleichtern Analyse. SIEM korreliert Sicherheitsereignisse. Monitoring erkennt Probleme früh. Ping-Monitoring reicht oft nicht. Schwellwerte müssen sinnvoll sein. Baseline zeigt normales Verhalten. Zertifikate überwachen. Netzplan aktuell halten. IP-Adressplan aktuell halten. Firewall- und NAT-Regeln dokumentieren. Änderungen dokumentieren. Root Cause suchen, nicht nur Symptom beheben. Runbooks helfen bei wiederkehrender Fehlersuche. # 12.7 Merksätze und Prüfungswissen zu Sniffing, Analyse und Fehlersuche Diese Seite fasst die wichtigsten Inhalte zu Sniffing, Paketmitschnitt, Wireshark, tcpdump, systematischer Fehlersuche, Logs, Monitoring und Dokumentation zusammen. Diese Themen sind besonders wichtig, weil sie in der Praxis und in Prüfungsaufgaben häufig miteinander verbunden werden. Merksatz: Netzwerkanalyse bedeutet: messen, prüfen, vergleichen und fachlich einordnen. --- **Grundidee der Netzwerkanalyse** Netzwerkanalyse soll klären, was wirklich passiert. Dabei nutzt man: - Fehlerbeschreibung - OSI-Modell - Paketmitschnitt - Logs - Monitoring - Konfigurationsprüfung - Vergleich mit funktionierenden Systemen Ziel ist nicht, blind etwas zu ändern. Ziel ist: Ursache finden Ursache nachweisen Ursache beheben Ergebnis dokumentieren Merksatz: Nicht raten, sondern prüfen. --- **Sniffing** Sniffing bedeutet: Netzwerkverkehr mitschneiden und analysieren. Dabei werden Pakete sichtbar gemacht. Man erkennt zum Beispiel: - Quell- und Ziel-MAC - Quell- und Ziel-IP - Protokoll - Port - DNS-Anfragen - TCP-Handshake - TLS-Handshake - DHCP-Ablauf - ICMP-Meldungen - Wiederholungen - Resets - Timeouts Merksatz: Sniffing zeigt den tatsächlichen Netzwerkverkehr. --- **Paketmitschnitt** Ein Paketmitschnitt ist eine Aufzeichnung von Netzwerkpaketen. Er hilft bei Fragen wie: Kommt das Paket an? Antwortet das Ziel? Wird DNS richtig gefragt? Findet ein TCP-Handshake statt? Gibt es Retransmissions? Gibt es Resets? Gibt es TLS-Fehler? Gibt es ICMP-Fehler? Kommt DHCP-DORA zustande? Merksatz: Paketmitschnitt ersetzt Vermutungen durch Messdaten. --- **PCAP-Datei** Paketmitschnitte werden häufig als PCAP oder PCAPNG gespeichert. Vorteile: - spätere Analyse möglich - Analyse mit Wireshark möglich - Weitergabe an Fachabteilung möglich - Beweissicherung bei Störungen - Vergleich mit Logs möglich Achtung: PCAP-Dateien können sensible Daten enthalten. Merksatz: PCAP-Dateien wie vertrauliche Daten behandeln. --- **Datenschutz bei Paketmitschnitten** Paketmitschnitte können enthalten: - IP-Adressen - MAC-Adressen - Hostnamen - Benutzernamen - Cookies - Tokens - unverschlüsselte Passwörter - E-Mail-Inhalte - personenbezogene Daten - interne Strukturen Deshalb: nur mit berechtigtem Zweck nur so lange wie nötig nur relevanten Verkehr sicher speichern Zugriff begrenzen nach Zweck löschen Merksatz: Sniffing ist technisch nützlich, aber datenschutzrelevant. --- **Wireshark** Wireshark ist ein grafisches Werkzeug zur Paketanalyse. Es zeigt: - Paketliste - Paketdetails - Paketbytes - Protokolle - Filtermöglichkeiten - Conversations - Endpoints - Expert Information Wireshark eignet sich besonders gut, um Protokollabläufe sichtbar zu machen. Merksatz: Wireshark macht Netzwerkverkehr lesbar. --- **tcpdump** tcpdump ist ein Kommandozeilenwerkzeug für Paketmitschnitte. Typische Nutzung: auf Servern auf Firewalls auf Routern per SSH in minimalen Linux-Umgebungen tcpdump kann Mitschnitte live anzeigen oder als PCAP-Datei speichern. Merksatz: tcpdump ist Paketmitschnitt auf der Kommandozeile. --- **tshark** tshark ist die Kommandozeilenversion von Wireshark. Es eignet sich für: - PCAP-Auswertung ohne GUI - automatisierte Analyse - Protokollauswertung - Filterung - Ausgabe bestimmter Felder Merksatz: tshark bringt Wireshark-Funktionen auf die Kommandozeile. --- **Capture Filter und Display Filter** Capture Filter: bestimmen, was überhaupt aufgezeichnet wird. Display Filter: bestimmen, was nachträglich angezeigt wird. | Filterart | Zeitpunkt | Wirkung | |---|---|---| | Capture Filter | vor oder während Aufnahme | begrenzt Aufzeichnung | | Display Filter | nach Aufnahme | begrenzt Anzeige | Merksatz: Capture Filter spart Daten. Display Filter hilft bei Analyse. --- **Wichtige Wireshark-Filter** | Fragestellung | Filteridee | |---|---| | bestimmte IP | ip.addr == 192.168.10.20 | | Quell-IP | ip.src == 192.168.10.20 | | Ziel-IP | ip.dst == 192.168.10.20 | | TCP-Port | tcp.port == 443 | | UDP-Port | udp.port == 53 | | DNS | dns | | ARP | arp | | ICMP | icmp | | HTTP | http | | TLS | tls | | TCP Reset | tcp.flags.reset == 1 | | Retransmission | tcp.analysis.retransmission | Merksatz: Filter müssen zur Frage passen. --- **Wichtige tcpdump-Filter** | Ziel | Beispiel | |---|---| | Interface mitschneiden | tcpdump -i eth0 | | keine Namensauflösung | tcpdump -nn -i eth0 | | Host filtern | tcpdump -nn -i eth0 host 192.168.10.20 | | Quelle filtern | tcpdump -nn -i eth0 src host 192.168.10.20 | | Ziel filtern | tcpdump -nn -i eth0 dst host 192.168.10.20 | | Port filtern | tcpdump -nn -i eth0 port 443 | | TCP-Port | tcpdump -nn -i eth0 tcp port 443 | | UDP-Port | tcpdump -nn -i eth0 udp port 53 | | ICMP | tcpdump -nn -i eth0 icmp | | ARP | tcpdump -nn -i eth0 arp | | Datei schreiben | tcpdump -nn -i eth0 -w capture.pcap | | Datei lesen | tcpdump -nn -r capture.pcap | Merksatz: tcpdump-Filter möglichst gezielt setzen. --- **Mitschnittort** Der Ort des Mitschnitts ist entscheidend. Mögliche Stellen: - Client - Server - Firewall - Router - Switch Mirror Port - Reverse Proxy - VPN-Gateway - Container-Host Je nach Ort sieht man andere Pakete. Merksatz: Der Mitschnittort entscheidet, was sichtbar ist. --- **Port Mirroring** In geswitchten Netzwerken sieht ein Client nicht automatisch den gesamten Verkehr. Port Mirroring kopiert Verkehr von einem oder mehreren Switchports auf einen Analyseport. Auch genannt: SPAN Merksatz: Port Mirroring macht fremden Switch-Verkehr für Analyse sichtbar. --- **Promiscuous Mode** Promiscuous Mode bedeutet: Die Netzwerkkarte nimmt auch Frames an, die nicht direkt an ihre eigene MAC-Adresse gerichtet sind. Wichtig: In geswitchten Netzen reicht das allein oft nicht, weil der Switch fremden Verkehr gar nicht an diesen Port sendet. Merksatz: Promiscuous Mode ersetzt kein Port Mirroring. --- **TCP-Handshake** TCP baut eine Verbindung mit drei Schritten auf: SYN SYN-ACK ACK Bedeutung: SYN: Client möchte Verbindung starten. SYN-ACK: Server antwortet und akzeptiert grundsätzlich. ACK: Client bestätigt. Merksatz: SYN, SYN-ACK, ACK = TCP-Verbindung aufgebaut. --- **TCP-Fehlerbilder** | Beobachtung | mögliche Bedeutung | |---|---| | nur SYN-Wiederholungen | keine Antwort, Firewall, Routing oder Rückweg | | SYN und RST | Port geschlossen oder Verbindung aktiv abgelehnt | | viele Retransmissions | Paketverlust oder fehlende Bestätigung | | Zero Window | Empfänger kann keine Daten aufnehmen | | SYN, SYN-ACK, kein ACK | Rückweg oder Clientproblem | | Handshake klappt, Anwendung fehlerhaft | höhere Schicht prüfen | Merksatz: TCP-Analyse beginnt beim Handshake. --- **UDP-Analyse** UDP hat keinen Verbindungsaufbau. Es gibt keinen TCP-Handshake. Bei UDP prüft man: Anfrage gesendet? Antwort zurück? richtiger Port? ICMP-Fehler? Firewall blockiert? Dienst antwortet? Beispiele für UDP: DNS DHCP NTP SNMP VoIP Merksatz: UDP hat keinen Handshake, deshalb Anfrage und Antwort direkt prüfen. --- **DNS-Analyse** DNS ist häufig der erste Schritt vor einer Verbindung. Prüfen: Welcher DNS-Server wird gefragt? Welcher Name wird gefragt? Welche Antwort kommt zurück? A oder AAAA? NXDOMAIN? falscher DNS-Server? Split DNS? Cache? TTL? Merksatz: DNS-Probleme sieht man oft vor dem eigentlichen Verbindungsversuch. --- **DHCP-Analyse** Der klassische DHCP-Ablauf lautet: Discover Offer Request Acknowledge Kurz: DORA Fehlerbilder: Discover ohne Offer: DHCP-Server oder Relay antwortet nicht. Offer ohne Request: Client akzeptiert Angebot nicht. Request ohne Acknowledge: Server bestätigt nicht. Merksatz: DHCP mit DORA prüfen. --- **ARP-Analyse** ARP löst im lokalen IPv4-Netz auf: IPv4-Adresse zu MAC-Adresse Typische ARP-Fehler: viele ARP-Anfragen ohne Antwort falsche MAC-Adresse doppelte IP-Adresse Gateway antwortet nicht VLAN falsch falsche Netzmaske Merksatz: ARP-Probleme sind lokale Schicht-2- oder Schicht-3-Probleme. --- **ICMP-Analyse** ICMP liefert Diagnose- und Fehlermeldungen. Beispiele: Echo Request Echo Reply Destination Unreachable Time Exceeded Fragmentation Needed Wichtig: ICMP ist mehr als Ping. Merksatz: ICMP-Meldungen können Ursachen sichtbar machen. --- **TLS-Analyse** Bei TLS sieht man normalerweise nicht den verschlüsselten Inhalt. Man sieht aber häufig: Client Hello Server Hello SNI Zertifikatsinformationen TLS-Version Cipher-Auswahl TLS Alert Typische Probleme: falscher Hostname abgelaufenes Zertifikat nicht vertrauenswürdige CA inkompatible TLS-Version unvollständige Zertifikatskette Merksatz: TLS schützt Inhalte, aber der Handshake liefert Hinweise. --- **SNI** SNI steht für: Server Name Indication SNI zeigt beim TLS-Aufbau, welchen Hostnamen der Client erreichen möchte. Wichtig bei: mehreren HTTPS-Diensten auf einer IP-Adresse Merksatz: SNI zeigt den gewünschten HTTPS-Hostnamen. --- **HTTP-Analyse** Bei HTTP prüft man: Methode Host-Header Pfad Statuscode Header Weiterleitung Antwortzeit Anwendungsmeldung Wichtige Statuscodes: | Code | Bedeutung | |---:|---| | 200 | OK | | 301 / 302 | Weiterleitung | | 400 | Bad Request | | 401 | nicht authentifiziert | | 403 | nicht berechtigt | | 404 | nicht gefunden | | 500 | interner Serverfehler | | 502 | Bad Gateway | | 503 | Dienst nicht verfügbar | | 504 | Gateway Timeout | Merksatz: HTTP-Statuscodes helfen bei Schicht-7-Fehlern. --- **Ping richtig einordnen** Ping prüft ICMP-Erreichbarkeit. Ping zeigt nicht: ob TCP 443 offen ist ob HTTPS funktioniert ob DNS korrekt ist ob Anmeldung klappt ob Berechtigung besteht ob Anwendung gesund ist Merksatz: Ping ist kein vollständiger Diensttest. --- **Porttest richtig einordnen** Ein Porttest zeigt: Verbindung zum Port möglich oder nicht. Er zeigt nicht automatisch: Anwendung funktioniert Login funktioniert Zertifikat passt Berechtigung stimmt Datenbank erreichbar API antwortet fachlich korrekt Merksatz: Offener Port heißt nicht: Anwendung funktioniert. --- **Wichtige Analysewerkzeuge** | Werkzeug | Zweck | |---|---| | ping | ICMP-Erreichbarkeit | | traceroute / tracert | Weg zum Ziel | | nslookup | einfache DNS-Prüfung | | dig | detaillierte DNS-Prüfung | | curl | HTTP/HTTPS/API-Test | | nc | Port- und Verbindungstest | | Test-NetConnection | Windows-Porttest | | ss | lokale Ports und Verbindungen | | netstat | Netzwerkstatus, älter | | openssl s_client | TLS- und Zertifikatsprüfung | | tcpdump | Paketmitschnitt CLI | | tshark | PCAP-Analyse CLI | | Wireshark | grafische Paketanalyse | | journalctl | Linux-Logs | | Ereignisanzeige | Windows-Logs | Merksatz: Kein Werkzeug beantwortet alles. --- **Systematische Fehlersuche nach OSI** | Schicht | Prüfung | |---:|---| | 1 | Kabel, Link, Signal, WLAN | | 2 | MAC, VLAN, Switch, ARP | | 3 | IP, Subnetz, Gateway, Routing | | 4 | TCP, UDP, Ports, Firewall | | 5 | Sitzung, Session, Timeout | | 6 | TLS, Zertifikat, Codierung | | 7 | Anwendung, DNS, DHCP, HTTP, Authentifizierung | Merksatz: OSI-Modell hilft, den Fehlerbereich einzugrenzen. --- **Bottom-Up** Bottom-Up bedeutet: von Schicht 1 nach oben prüfen. Beispiel: Kabel Link VLAN IP Gateway Port Dienst Anwendung Merksatz: Bottom-Up beginnt beim Fundament. --- **Top-Down** Top-Down bedeutet: bei der Anwendung beginnen und nach unten prüfen. Beispiel: Webseite HTTP-Status TLS Port DNS Routing Link Merksatz: Top-Down beginnt beim sichtbaren Dienst. --- **Divide and Conquer** Divide and Conquer bedeutet: Man prüft eine mittlere Ebene, um den Suchbereich zu verkleinern. Beispiel: Ping geht, aber Webdienst nicht. Dann ist grob klar: IP-Erreichbarkeit ist wahrscheinlich vorhanden, aber Port, Firewall, TLS oder Anwendung müssen weiter geprüft werden. Merksatz: Divide and Conquer halbiert den Suchbereich. --- **Fehlerbild sauber aufnehmen** Wichtige Fragen: Wer ist betroffen? Was funktioniert nicht? Was funktioniert noch? Seit wann? Wo tritt der Fehler auf? Intern oder extern? LAN oder WLAN? VPN oder lokal? Nur ein Benutzer oder alle? Welche Fehlermeldung? Was wurde zuletzt geändert? Merksatz: Gute Fehlerbeschreibung ist Diagnosearbeit. --- **Typische Fehlerbilder** | Fehlerbild | erste Richtung | |---|---| | kein Link | Schicht 1 | | 169.254.x.x | DHCP | | Gateway nicht erreichbar | Schicht 2 / 3 | | IP geht, Name nicht | DNS | | Ping geht, Port nicht | Schicht 4 / Firewall / Dienst | | Port offen, Anwendung fehlerhaft | Schicht 7 | | Timeout | keine passende Antwort | | Connection Refused | Dienst lehnt aktiv ab | | 401 | Authentifizierung | | 403 | Autorisierung | | 404 | Pfad oder Ressource fehlt | | 500 | Anwendung oder Server | | 502 | Proxy zu Backend | | Zertifikatswarnung | TLS, DNS, Zeit oder CA | Merksatz: Fehlerbild gibt Richtung, aber noch keinen Beweis. --- **Authentifizierung und Autorisierung** Authentifizierung bedeutet: Wer bist du? Beispiele: Benutzername Passwort MFA Zertifikat Token Autorisierung bedeutet: Was darfst du? Beispiele: Rolle Gruppe Rechte Freigabe API-Scope Merksatz: 401 ist oft Authentifizierung. 403 ist oft Autorisierung. --- **Timeout und Connection Refused** Timeout: Keine Antwort kommt zurück. Mögliche Ursachen: Firewall droppt Routing fehlt Rückweg fehlt Ziel antwortet nicht Connection Refused: Ziel lehnt aktiv ab. Mögliche Ursachen: Dienst läuft nicht falscher Port Dienst lauscht nicht Host lehnt ab Merksatz: Timeout = keine Antwort. Refused = aktive Ablehnung. --- **MTU-Probleme** MTU steht für: Maximum Transmission Unit Typische Hinweise: kleine Pakete funktionieren große Übertragungen hängen VPN instabil Webseiten laden teilweise Downloads brechen ab viele Retransmissions Fragmentation Needed fehlt oder wird blockiert Merksatz: Kleine Daten gehen, große nicht: MTU prüfen. --- **Logs** Logs zeigen Ereignisse und Entscheidungen. Wichtige Logquellen: - Firewall-Logs - DNS-Logs - DHCP-Logs - VPN-Logs - Webserver-Logs - Reverse-Proxy-Logs - Authentifizierungslogs - Systemlogs - Anwendungslogs - Mailserver-Logs - Datenbank-Logs Merksatz: Logs zeigen, was Systeme entschieden oder gemeldet haben. --- **Monitoring** Monitoring überwacht Systeme und Dienste dauerhaft. Es prüft zum Beispiel: Erreichbarkeit Antwortzeiten CPU RAM Speicherplatz Bandbreite Paketverlust Zertifikate Dienste Logs Verbindungen Merksatz: Monitoring erkennt Probleme über Zeit. --- **Dokumentation** Gute Dokumentation enthält: - Netzplan - IP-Adressplan - VLAN-Plan - Firewall-Regeln - NAT-Regeln - DNS-Einträge - DHCP-Scopes - Serverrollen - Dienste - Ansprechpartner - Änderungen - Notfallverfahren Merksatz: Dokumentation ist ein Werkzeug für Fehlersuche. --- **Root Cause Analysis** Root Cause Analysis bedeutet: die eigentliche Ursache finden. Nicht nur: Dienst neu starten Sondern: Warum ist der Dienst abgestürzt? Warum war Speicher voll? Warum gab es keinen Alarm? Warum wurde die Änderung nicht getestet? Merksatz: Ursache beheben, nicht nur Symptom beseitigen. --- **Workaround und Lösung** Workaround: vorübergehende Umgehung Lösung: eigentliche Ursache wird beseitigt Beispiel: Workaround: IP-Adresse statt DNS-Namen verwenden. Ursache: DNS-Eintrag falsch. Lösung: DNS-Eintrag korrigieren. Merksatz: Workaround ist nicht automatisch Lösung. --- **Eine Änderung pro Test** Bei Fehlersuche sollte man nicht viele Dinge gleichzeitig ändern. Besser: eine Hypothese bilden einen Test durchführen Ergebnis prüfen dokumentieren nächste Hypothese testen Merksatz: Mehrere Änderungen gleichzeitig verschleiern die Ursache. --- **Nach Änderung zuerst Änderung prüfen** Wenn ein Fehler nach einer Änderung auftritt, prüft man zuerst diese Änderung. Beispiele: Firewall-Regel geändert DNS geändert Zertifikat erneuert VLAN geändert Update installiert Passwort geändert Reverse Proxy angepasst VPN geändert Merksatz: Die letzte Änderung ist oft der wichtigste Hinweis. --- **Sicherheitsbewusstsein bei Analyse** Analysewerkzeuge können sensible Informationen offenlegen. Beispiele: unverschlüsselte Passwörter Tokens Cookies interne Hostnamen IP-Adressbereiche Benutzerinformationen Fehlermeldungen Konfigurationsdetails Deshalb: Zugriff beschränken Dateien schützen keine unnötigen Mitschnitte Logs nicht ungeschützt teilen Datenschutz beachten Merksatz: Diagnose darf keine neue Sicherheitslücke erzeugen. --- **Typische IHK-Fragen** In AP1 und AP2 kann zum Beispiel gefragt werden: - Was versteht man unter Sniffing? - Wofür nutzt man Wireshark? - Wofür nutzt man tcpdump? - Was ist eine PCAP-Datei? - Was ist Port Mirroring? - Warum sieht man im Switch-Netz nicht automatisch allen Verkehr? - Was ist der Unterschied zwischen Capture Filter und Display Filter? - Wie erkennt man einen TCP-Handshake? - Was bedeuten SYN, SYN-ACK und ACK? - Was bedeutet RST? - Was bedeutet Retransmission? - Warum sieht man HTTPS-Inhalte nicht im Klartext? - Was kann man bei DNS im Mitschnitt erkennen? - Wie analysiert man DHCP? - Warum reicht Ping nicht aus? - Warum reicht ein Porttest nicht aus? - Wie hilft das OSI-Modell bei der Fehlersuche? - Was ist Bottom-Up? - Was ist Top-Down? - Was ist Divide and Conquer? - Warum sind Logs wichtig? - Warum ist Monitoring wichtig? - Warum ist Dokumentation wichtig? --- **Typische Prüfungsfallen** Sniffing zeigt echten Verkehr. Sniffing ist datenschutzrelevant. Wireshark ist grafisch. tcpdump ist Kommandozeile. tshark ist Wireshark auf Kommandozeile. PCAP-Dateien können sensible Daten enthalten. In geswitchten Netzen sieht man nicht automatisch alles. Port Mirroring kopiert Verkehr. Promiscuous Mode reicht allein oft nicht. Capture Filter begrenzen Aufnahme. Display Filter begrenzen Anzeige. TCP hat Handshake. UDP hat keinen Handshake. SYN startet TCP-Verbindung. SYN-ACK ist Serverantwort. ACK bestätigt. RST lehnt ab oder beendet. Retransmission bedeutet erneutes Senden. DNS früh prüfen. DHCP-DORA kennen. ICMP ist mehr als Ping. HTTPS-Inhalte sind verschlüsselt. TLS-Handshake kann trotzdem Hinweise liefern. SNI zeigt gewünschten Hostnamen. Ping prüft nicht den Dienst. Port offen heißt nicht Anwendung funktioniert. Timeout und Connection Refused unterscheiden. 401 ist Authentifizierung. 403 ist Autorisierung. OSI-Modell hilft beim Eingrenzen. Logs und Mitschnitt ergänzen sich. Monitoring zeigt Zustand über Zeit. Dokumentation beschleunigt Fehlersuche. --- **Wichtige Begriffe kurz erklärt** | Begriff | Kurze Erklärung | |---|---| | Sniffing | Mitschneiden von Netzwerkverkehr | | Paketmitschnitt | Aufzeichnung von Paketen | | PCAP | Datei mit Paketmitschnitt | | Wireshark | grafisches Analysewerkzeug | | tcpdump | Kommandozeilenwerkzeug für Mitschnitt | | tshark | Wireshark auf Kommandozeile | | Port Mirroring | Verkehr auf Analyseport kopieren | | Promiscuous Mode | Netzwerkkarte nimmt fremde Frames an | | Capture Filter | Filter vor der Aufnahme | | Display Filter | Filter nach der Aufnahme | | SYN | TCP-Verbindungsstart | | SYN-ACK | TCP-Antwort des Servers | | ACK | Bestätigung | | RST | Reset, aktive Ablehnung oder Abbruch | | Retransmission | erneutes Senden | | ARP | IPv4-Adresse zu MAC-Adresse | | ICMP | Diagnose- und Fehlermeldungsprotokoll | | DNS | Namensauflösung | | DHCP-DORA | Discover, Offer, Request, Acknowledge | | SNI | Hostname im TLS-Handshake | | TLS Alert | TLS-Fehlermeldung | | Bottom-Up | von Schicht 1 nach oben prüfen | | Top-Down | von Anwendung nach unten prüfen | | Divide and Conquer | Suchbereich in der Mitte eingrenzen | | Timeout | keine Antwort | | Connection Refused | aktive Ablehnung | | Authentifizierung | Identität prüfen | | Autorisierung | Rechte prüfen | | Log | Ereignisprotokoll | | Monitoring | dauerhafte Überwachung | | Root Cause | eigentliche Ursache | | Workaround | vorübergehende Umgehung | | Runbook | Schritt-für-Schritt-Anleitung | --- **IHK-sichere Gesamtformulierung** Sniffing bezeichnet das Mitschneiden und Analysieren von Netzwerkverkehr. Mit Werkzeugen wie Wireshark, tcpdump oder tshark können Pakete untersucht werden, um DNS-Anfragen, ARP, ICMP, TCP-Handshakes, UDP-Kommunikation, DHCP-DORA, TLS-Handshakes, Resets, Retransmissions und Timeouts zu erkennen. In geswitchten Netzwerken sieht ein Client nicht automatisch den gesamten Verkehr; dafür wird häufig Port Mirroring benötigt. Das OSI-Modell hilft bei der Fehlersuche, indem Fehler schichtweise eingegrenzt werden. Ping und Porttests liefern nur Teilinformationen und ersetzen keine vollständige Prüfung von DNS, Routing, Firewall, NAT, Dienst, TLS, Anwendung, Logs und Berechtigungen. Logs, Monitoring und Dokumentation ergänzen Paketmitschnitte und sind wichtig, um Ursachen nachzuweisen und dauerhaft zu beheben. --- **Wichtigste Merksätze** Nicht raten, sondern messen. Sniffing zeigt echten Verkehr. Paketmitschnitt zeigt Pakete. Logs zeigen Ereignisse. Monitoring zeigt Zustand über Zeit. Dokumentation zeigt Aufbau und Änderungen. Wireshark ist grafisch. tcpdump ist Kommandozeile. tshark ist Wireshark auf Kommandozeile. PCAP-Dateien sind sensibel. Mitschnittort ist entscheidend. Port Mirroring kopiert Switch-Verkehr. Capture Filter vor Aufnahme. Display Filter nach Aufnahme. TCP hat Handshake. UDP hat keinen Handshake. SYN, SYN-ACK, ACK = TCP-Verbindung aufgebaut. RST bedeutet aktive Ablehnung oder Abbruch. Retransmission bedeutet erneutes Senden. DNS immer früh prüfen. DHCP mit DORA prüfen. ARP ist lokal wichtig. ICMP ist mehr als Ping. TLS schützt Inhalte. SNI zeigt Hostnamen. HTTP-Statuscodes helfen bei Schicht 7. Ping reicht nicht aus. Port offen reicht nicht aus. Timeout ist keine Antwort. Connection Refused ist aktive Ablehnung. 401 ist Authentifizierung. 403 ist Autorisierung. OSI-Modell grenzt Fehler ein. Bottom-Up beginnt unten. Top-Down beginnt oben. Divide and Conquer grenzt mittig ein. Eine Änderung pro Test. Letzte Änderung zuerst prüfen. Workaround ist nicht automatisch Lösung. Root Cause suchen. Ergebnisse dokumentieren.