Verstehen, was zwischen zwei Systemen passiert
In Modul 4 haben wir gelernt, wie Systeme in Netzwerken organisiert, adressiert und miteinander verbunden sind. Jetzt betrachten wir den eigentlichen Kommunikationsvorgang: Welche Regeln gelten, wie wird ein Dienst angesprochen und welche technischen Spuren entstehen auf dem Weg vom Client zum Server?
Netzwerk vorhanden – aber wie wird gesprochen?
Ein Netzwerk schafft den Weg zwischen Systemen. Damit daraus verständliche Kommunikation wird, benötigen beide Seiten gemeinsame Regeln.
Was ist ein Protokoll?
Ein Protokoll definiert Regeln für technische Kommunikation. Es beschreibt beispielsweise, wie eine Nachricht aufgebaut ist, wer eine Kommunikation beginnt, wie eine Antwort aussieht und wie Fehler behandelt werden.
SYSTEM A SYSTEM B │ │ ├──── Nachricht ────────►│ │◄──── Antwort ──────────┤ │ │ └── beide folgen denselben Regeln
Mehrere Protokolle arbeiten zusammen
Ein Webseitenaufruf besteht nicht aus einem einzigen Protokoll. Verschiedene Protokolle übernehmen unterschiedliche Aufgaben und bauen funktional aufeinander auf.
HTTP → Was möchte die Anwendung? TLS → Wie wird der Inhalt geschützt? TCP → Wie werden Daten zuverlässig transportiert? IP → Zu welchem System müssen die Daten? Ethernet → Wie bewegen sie sich im lokalen Netz?
Dieses Denken in Schichten hilft später beim Lesen von Wireshark-, Zeek- und anderen Netzwerkdaten.
Header und Payload
Protokolle ergänzen Daten um Steuerinformationen. Vereinfacht kann man zwischen Header und Payload unterscheiden.
┌──────────────┬──────────────────────────┐ │ HEADER │ PAYLOAD │ ├──────────────┼──────────────────────────┤ │ Steuerdaten │ eigentliche Nutzdaten │ └──────────────┴──────────────────────────┘
Welche Informationen im Header stehen, hängt vom jeweiligen Protokoll ab. Genau deshalb können Netzwerkdaten technische Metadaten enthalten, obwohl der eigentliche Inhalt geschützt oder verschlüsselt ist.
IP-Adresse und Port erfüllen unterschiedliche Aufgaben
Eine IP-Adresse führt zu einem System. Ein Port hilft dem Betriebssystem dabei, die Kommunikation dem richtigen Dienst beziehungsweise Prozess zuzuordnen.
IP-Adresse + Port
Ein Server kann gleichzeitig viele Dienste anbieten. Deshalb reicht die Ziel-IP allein nicht aus.
203.0.113.20:22 → typischerweise SSH 203.0.113.20:80 → typischerweise HTTP 203.0.113.20:443 → typischerweise HTTPS 203.0.113.20:3389 → typischerweise RDP
Quellport, Zielport und Kommunikationsfluss
Ein Client verwendet typischerweise einen temporären Quellport und spricht damit den Zielport eines Dienstes an.
CLIENT SERVER 10.20.5.17:52144 ───────────────► 203.0.113.20:443 Quell-IP 10.20.5.17 Quellport 52144 Ziel-IP 203.0.113.20 Zielport 443 Protokoll TCP
Diese Kombination wird häufig als Kommunikationsfluss betrachtet. Quelle, Ziel, Ports, Transportprotokoll und Zeitpunkt sind für spätere Verkehrsdatenanalysen besonders wichtig.
Wie Daten zwischen Endpunkten transportiert werden
TCP und UDP verfolgen unterschiedliche Ziele. ICMP wiederum transportiert vor allem Kontroll- und Fehlermeldungen für IP-Netze.
TCP – verbindungsorientiert und zuverlässig
TCP baut vor der eigentlichen Datenübertragung einen Verbindungszustand auf. Vereinfacht beginnt dies mit dem Three-Way-Handshake.
CLIENT SERVER │──── SYN ─────────────────►│ │◄─── SYN / ACK ────────────│ │──── ACK ─────────────────►│ │ │ │ Verbindung steht │
TCP nummeriert Daten, bestätigt Empfang und kann fehlende Segmente erneut übertragen. Dadurch eignet es sich für Anwendungen, bei denen Vollständigkeit und Reihenfolge wichtig sind.
UDP – weniger Overhead, andere Verantwortung
UDP baut keine vergleichbare Verbindung auf und bestätigt einzelne Datagramme nicht automatisch. Das macht das Protokoll schlank, verlagert Zuverlässigkeitsmechanismen aber gegebenenfalls in die Anwendung.
TCP: „Hast du meine Daten erhalten?“ UDP: „Hier sind meine Daten.“
Typische Beispiele für UDP-Nutzung sind DNS-Anfragen und Echtzeitkommunikation – wobei moderne Anwendungen je nach Verfahren auch andere Transportmechanismen einsetzen können.
ICMP – Rückmeldungen des IP-Netzes
ICMP transportiert Kontroll- und Fehlermeldungen. Werkzeuge wie ping nutzen ICMP Echo Request und Echo Reply, um Erreichbarkeit zu prüfen.
CLIENT ── ICMP Echo Request ──► ZIEL CLIENT ◄── ICMP Echo Reply ──── ZIEL
ICMP ist kein Ersatz für TCP oder UDP. Es liefert vielmehr Informationen über den Zustand beziehungsweise die Erreichbarkeit im IP-Netz.
DNS – von einem Namen zur IP-Adresse
Menschen arbeiten gern mit Namen. Netzwerkkommunikation benötigt am Ende jedoch eine erreichbare Adresse.
Warum DNS benötigt wird
Beim Aufruf einer Domain muss ein System häufig zunächst herausfinden, welche IP-Adresse zu diesem Namen gehört.
training.spice.local
│
▼
DNS
│
▼
10.20.50.8Die Namensauflösung kann mehrere technische Komponenten und Caches einbeziehen. Für den Einstieg ist entscheidend: Eine DNS-Anfrage kann zeitlich vor der eigentlichen Verbindung zum Zielsystem liegen.
DNS als analytische Spur
Eine DNS-Beobachtung kann zeigen, dass ein System nach einem bestimmten Namen gefragt hat. Sie beweist jedoch nicht automatisch, dass anschließend erfolgreich eine Anwendungskommunikation mit dem Ziel stattgefunden hat.
DNS QUERY client → „Welche Adresse hat portal.example?“ DNS RESPONSE resolver → „203.0.113.20“ DANACH MÖGLICH: client → 203.0.113.20:443
Wie eine Webanfrage technisch einzuordnen ist
Jetzt verbinden wir Modul 3 und Modul 4: Eine Client-Anwendung spricht über das Netzwerk mit einer Server-Anwendung – und nutzt dafür ein Anwendungsprotokoll.
HTTP – Request und Response
HTTP arbeitet nach einem Anfrage-Antwort-Prinzip. Ein Client fordert eine Ressource an, der Server antwortet.
CLIENT WEBSERVER │──── GET /login ──────────►│ │ │ │◄── 200 OK + Antwort ──────│
Methoden wie GET oder POST beschreiben die Art der Anfrage. Statuscodes wie 200, 404 oder 500 helfen, die Serverantwort einzuordnen.
HTTPS und TLS
HTTPS bedeutet vereinfacht: HTTP wird innerhalb einer durch TLS geschützten Verbindung übertragen. TLS dient insbesondere dem Schutz von Vertraulichkeit und Integrität sowie der Authentisierung der Gegenstelle über Zertifikate.
HTTP-DATEN │ ▼ TLS-SCHUTZ │ ▼ TCP │ ▼ IP
Verschlüsselung bedeutet dabei nicht, dass keinerlei technische Informationen mehr entstehen. Adressen, Ports, Zeitpunkte, Datenmengen und weitere Metadaten können je nach Beobachtungspunkt weiterhin sichtbar sein.
Inhalt und Metadaten trennen
Diese Trennung wird für spätere Module zentral. Ein Beobachtungspunkt kann beispielsweise erkennen, dass zwei Systeme kommunizieren, ohne den geschützten Anwendungsinhalt unmittelbar lesen zu können.
MÖGLICHERWEISE SICHTBAR ✓ Quell-/Ziel-IP ✓ Quell-/Zielport ✓ Zeitpunkte ✓ Datenmengen ✓ Transportprotokoll NICHT AUTOMATISCH SICHTBAR ✗ verschlüsselter HTTP-Inhalt ✗ Passwörter im TLS-geschützten Datenstrom
Vom Domainnamen bis zur Serverantwort
Wir setzen die bisher getrennten Bausteine zu einem einzigen Kommunikationsvorgang zusammen.
Eine HTTPS-Verbindung Schritt für Schritt
1. Benutzer öffnet https://portal.example
│
▼
2. DNS ermittelt eine IP-Adresse
│
▼
3. Client kennt das Zielsystem
│
▼
4. TCP-Verbindung wird aufgebaut
│
▼
5. Zielport 443 wird angesprochen
│
▼
6. TLS-Verbindung wird ausgehandelt
│
▼
7. HTTP-Anfrage wird geschützt übertragen
│
▼
8. Server verarbeitet die Anfrage
│
▼
9. Server sendet eine Antwort
│
▼
10. Browser verarbeitet und zeigt das ErgebnisDas Modell ist bewusst vereinfacht. Es reicht aber bereits aus, um später einzelne Beobachtungen aus PCAP, Zeek, OpenSearch oder Überwachungsdaten in einen Gesamtvorgang einzuordnen.
Vom einzelnen Paket zum Datenfluss
Eine einzelne Beobachtung erzählt selten die ganze Geschichte. Aussagekräftiger wird die Analyse, wenn mehrere Ereignisse zeitlich und technisch zusammengeführt werden.
10:31:04 DNS client → resolver portal.example 10:31:05 TCP client → server:443 SYN 10:31:05 TCP server → client SYN/ACK 10:31:05 TLS client ↔ server Handshake 10:31:06 DATA client ↔ server verschlüsselt
Vier Aussagen, die bei Netzwerkkommunikation zu kurz greifen
Öffne alle vier Karten. Sie trainieren genau die Unterscheidungen, die später bei der Bewertung technischer Daten wichtig werden.
Baue den Webaufruf Schritt für Schritt auf
Der Ablauf verbindet die Kernkonzepte dieses Moduls. Klicke dich durch alle Schritte.
Kommunikationsbausteine sicher zuordnen
Ordne die Aussagen den passenden Begriffen zu. Alle acht Zuordnungen müssen korrekt sein.
Adressierung und Dienst
Transport
Anwendungsprotokolle
Schutz und Beobachtung
Wissenscheck – Modul 5
Für den vollständigen Modulabschluss müssen alle zwölf Antworten korrekt sein.
Aus Netzstruktur wird ein verständlicher Kommunikationsvorgang
Nach Modul 4 konntest du ein Netzwerk technisch lesen. Nach Modul 5 kannst du nun erstmals nachvollziehen, wie zwei Anwendungen über dieses Netzwerk miteinander kommunizieren und welche Datenpunkte dabei entstehen.
Im nächsten Modul wechseln wir von der Kommunikation zur Server- und Infrastrukturperspektive: Wo laufen Dienste, wie sind Server aufgebaut und wie greifen Administration, Prozesse und Netzwerkdienste ineinander?