Wireshark 8421

Aus Xinux Wiki
Version vom 26. Februar 2026, 10:32 Uhr von Maximilian.pottgiesser (Diskussion | Beiträge) (Die Seite wurde neu angelegt: „= Wireshark Praxis – Cybersecurity Training = ''Passend zur Nmap-Praxis – gleiche Umgebung, gleiche Netze'' == Netzwerkübersicht == {| class="wikitable…“)
(Unterschied) ← Nächstältere Version | Aktuelle Version (Unterschied) | Nächstjüngere Version → (Unterschied)
Zur Navigation springen Zur Suche springen

Wireshark Praxis – Cybersecurity Training

Passend zur Nmap-Praxis – gleiche Umgebung, gleiche Netze

Netzwerkübersicht

Segment Netz Relevante Hosts
WAN 192.168.Y.0/24 host200, Roadwarrior
DMZ 10.0.10.0/24 www.microsott.de (Apache2 + Wazuh Agent), waf.microsott.de
LAN 172.26.53.0/24 win11, kali
Server 172.26.54.0/24 win2022, sensor, mqtt, aktor, wazuh, elk, ubuntu

Wichtige Hinweise zur Umgebung:

  • Wireshark/tshark läuft auf dem Kali-Client (172.26.53.0/24) – alle Captures werden dort durchgeführt.
  • Für Captures auf anderen Hosts kann tcpdump verwendet und die PCAPs anschließend in Wireshark geöffnet werden.
  • Scans gegen www.microsott.de werden durch den Wazuh Agent detektiert – ideal für Korrelationsübungen (Wireshark + Wazuh + ELK).

Phase 1 – Grundlagen & Interface Setup

Ziel: Wireshark/tshark korrekt einrichten und den Unterschied zwischen Capture- und Display-Filtern verstehen.

Capture starten und Interface wählen

# Wireshark GUI starten
sudo wireshark &

# Oder: Capture direkt auf der Kommandozeile mit tshark
sudo tshark -i eth0 -w /tmp/capture.pcap

# Capture mit Zeitlimit (60 Sekunden)
sudo tshark -i eth0 -a duration:60 -w /tmp/timed_capture.pcap

# Capture mit Paketlimit (1000 Pakete)
sudo tshark -i eth0 -c 1000 -w /tmp/limited_capture.pcap

Capture-Filter vs. Display-Filter

Capture-Filter (BPF-Syntax) werden VOR dem Capture gesetzt und begrenzen, was aufgezeichnet wird. Display-Filter werden NACH dem Capture angewandt und filtern die Anzeige.

Typ Syntax-Beispiel Wann verwenden
Capture-Filter host 172.26.54.10 Vor dem Capture – reduziert Datenmenge
Capture-Filter port 80 or port 443 Nur Webtraffic aufzeichnen
Capture-Filter net 172.26.54.0/24 Ganzes Subnetz aufzeichnen
Display-Filter ip.addr == 172.26.54.10 Nach dem Capture filtern
Display-Filter tcp.port == 80 Bestimmten Port anzeigen
Display-Filter http.request.method == GET Nur HTTP GET Requests

Phase 2 – Nmap-Scans in Wireshark erkennen

Ziel: Die Nmap-Scans aus der Nmap-Praxis parallel in Wireshark mitschneiden und die Scan-Muster identifizieren.

Aufgabe 2.1 – TCP SYN Scan erkennen

Szenario: Führe einen SYN Stealth Scan gegen einen Host im Server-Netz durch und analysiere den Traffic in Wireshark.

Schritt 1: Capture starten 

# Terminal 1: Wireshark Capture starten
sudo tshark -i eth0 -w /tmp/syn_scan.pcap &

# Terminal 2: Nmap SYN Scan durchführen
sudo nmap -sS 172.26.54.10

Schritt 2: In Wireshark analysieren 

# Display-Filter: Nur SYN-Pakete (ohne ACK) anzeigen
tcp.flags.syn == 1 && tcp.flags.ack == 0

# SYN+ACK Antworten (offene Ports)
tcp.flags.syn == 1 && tcp.flags.ack == 1

# RST Antworten (geschlossene Ports)
tcp.flags.reset == 1

Analyse-Fragen:

  1. Wie viele SYN-Pakete wurden gesendet?
  2. Welche Ports haben mit SYN+ACK geantwortet (offen)?
  3. Wird der 3-Way-Handshake abgeschlossen? (Nein – das ist der Stealth-Aspekt!)
  4. Was sendet Nmap nach dem SYN+ACK? (RST – Verbindung wird abgebrochen)

Aufgabe 2.2 – TCP Connect Scan vs. SYN Scan

Ziel: Den Unterschied zwischen einem vollständigen TCP Connect Scan und einem SYN Scan im Paketfluss erkennen. 

# Terminal 1: Capture
sudo tshark -i eth0 -w /tmp/connect_scan.pcap &

# Terminal 2: TCP Connect Scan (KEIN Root nötig)
nmap -sT -p 22,80,443 172.26.54.10

# Display-Filter: Vollständiger 3-Way-Handshake
tcp.flags.syn == 1 && tcp.flags.ack == 0

# Dann: Follow TCP Stream (Rechtsklick → Follow → TCP Stream)
# Beim Connect Scan sieht man: SYN → SYN+ACK → ACK → RST
# Beim SYN Scan nur:           SYN → SYN+ACK → RST

Aufgabe 2.3 – UDP Scan erkennen

UDP-Scans erzeugen ein völlig anderes Muster. Offene Ports antworten oft nicht, geschlossene senden ICMP Port Unreachable. 

# Capture + Scan
sudo tshark -i eth0 -w /tmp/udp_scan.pcap &
sudo nmap -sU -p 53,161,67 172.26.54.10

# Display-Filter für ICMP Port Unreachable
icmp.type == 3 && icmp.code == 3

# Alle UDP-Pakete zum Ziel
udp && ip.dst == 172.26.54.10

Analyse-Fragen:

  1. Welche Ports erzeugen ICMP Port Unreachable (geschlossen)?
  2. Welche Ports zeigen keine Antwort (offen|filtered)?
  3. Warum dauert ein UDP-Scan so viel länger als TCP?

Aufgabe 2.4 – OS Fingerprinting erkennen

Nmap sendet spezielle Probes für OS-Erkennung. Diese sind im Capture gut erkennbar. 

sudo tshark -i eth0 -w /tmp/os_detect.pcap &
sudo nmap -O 172.26.54.10

# Display-Filter: Ungewöhnliche TCP-Flags und Window-Sizes
tcp.window_size == 1
tcp.flags == 0x00        # NULL Scan Probe
tcp.flags == 0x29        # FIN+PSH+URG Probe
tcp.flags.ecn == 1       # ECN Probe

Phase 3 – Protokollanalyse

Aufgabe 3.1 – HTTP-Traffic analysieren (DMZ)

Ziel: HTTP-Requests und Responses gegen den Apache2 auf www.microsott.de analysieren. 

# Capture starten (BPF Filter auf DMZ-Host)
sudo tshark -i eth0 -f 'host 10.0.10.108' -w /tmp/http_traffic.pcap &

# HTTP-Requests erzeugen
curl http://10.0.10.108/
curl http://10.0.10.108/nonexistent
curl -A 'Mozilla/5.0' http://10.0.10.108/

# Display-Filter in Wireshark
http.request                          # Alle HTTP Requests
http.response                         # Alle HTTP Responses
http.response.code == 404             # Nur 404 Not Found
http.request.method == GET            # Nur GET Requests
http.user_agent contains "Mozilla"    # User-Agent filtern

# Follow HTTP Stream: Rechtsklick → Follow → HTTP Stream

Hinweis: Der Wazuh Agent auf www.microsott.de loggt diese Zugriffe mit! Vergleiche das Wireshark-Capture mit den Wazuh-Alerts.

Aufgabe 3.2 – DNS-Analyse

DNS-Traffic gibt viel über die Netzwerkstruktur preis. Analysiere Queries und Responses. 

# Capture nur DNS-Traffic
sudo tshark -i eth0 -f 'port 53' -w /tmp/dns_traffic.pcap &

# DNS-Queries erzeugen
nslookup www.microsott.de
dig @172.26.54.X A www.microsott.de
dig @172.26.54.X AXFR microsott.de    # Zone Transfer Versuch

# Display-Filter
dns.qry.name == "www.microsott.de"    # Bestimmter Hostname
dns.qry.type == 1                     # A Records
dns.qry.type == 255                   # ANY Queries
dns.flags.rcode == 5                  # REFUSED (Zone Transfer)

Aufgabe 3.3 – SMB-Traffic analysieren (win2022)

SMB-Traffic enthält Informationen über Freigaben, Benutzer und Sessions. 

# Capture starten
sudo tshark -i eth0 -f 'host 172.26.54.X and port 445' -w /tmp/smb_traffic.pcap &

# SMB-Enumeration mit Nmap auslösen
sudo nmap --script smb-enum-shares,smb-enum-users -p 445 172.26.54.X

# Display-Filter
smb2                                   # Alle SMB2 Pakete
smb2.cmd == 1                          # Session Setup
smb2.cmd == 3                          # Tree Connect (Freigaben)
ntlmssp                                # NTLM Authentication
ntlmssp.auth.username                  # Benutzernamen extrahieren

Analyse-Fragen:

  1. Welche SMB-Dialektversion wird ausgehandelt?
  2. Sind Benutzernamen im NTLM-Handshake sichtbar?
  3. Welche Freigaben werden enumeriert?

Aufgabe 3.4 – MQTT-Traffic analysieren

MQTT ist ein IoT-Protokoll. Unverschlüsselter MQTT-Traffic (Port 1883) ist im Klartext lesbar. 

# Capture MQTT-Traffic
sudo tshark -i eth0 -f 'port 1883' -w /tmp/mqtt_traffic.pcap &

# MQTT Nmap Script auslösen
sudo nmap --script mqtt-subscribe -p 1883 172.26.54.X

# Display-Filter
mqtt                                   # Alle MQTT-Pakete
mqtt.msgtype == 1                      # CONNECT
mqtt.msgtype == 3                      # PUBLISH
mqtt.msgtype == 8                      # SUBSCRIBE
mqtt.topic                             # Topics anzeigen

# Wichtig: Bei Port 8883 (MQTT over TLS) sieht man nur TLS-Handshake!
tls.handshake && tcp.port == 8883

Phase 4 – Evasion-Techniken erkennen

Wichtig: Diese Phase zeigt, wie die Firewall- und IDS-Evasion-Techniken aus der Nmap-Praxis im Wireshark aussehen. Ideal für Red/Blue Team Vergleiche.

Aufgabe 4.1 – Fragmentierte Pakete erkennen

sudo tshark -i eth0 -w /tmp/fragmented.pcap &
sudo nmap -f 172.26.54.10

# Display-Filter
ip.flags.mf == 1                      # More Fragments Flag gesetzt
ip.frag_offset > 0                    # Fragment Offset > 0
ip.fragment                            # Alle Fragmente

Analyse: Vergleiche die Paketgrößen der fragmentierten Pakete mit einem normalen SYN Scan. Die Fragmentierung teilt TCP-Header über mehrere IP-Pakete auf, um einfache Paketfilter zu umgehen.

Aufgabe 4.2 – Decoy Scan erkennen

sudo tshark -i eth0 -w /tmp/decoy.pcap &
sudo nmap -D 10.10.10.1,10.10.10.2,10.10.10.3,ME 172.26.54.10

# Display-Filter: Alle SYN-Pakete zum Ziel
tcp.flags.syn == 1 && ip.dst == 172.26.54.10

# Dann: Statistics → Conversations → IPv4
# Hier sieht man Traffic von den Decoy-IPs UND der echten IP

Analyse-Fragen:

  1. Wie viele verschiedene Quell-IPs sind in den SYN-Paketen sichtbar?
  2. Kann man die echte IP vom Decoy unterscheiden? (Tipp: Antwortpakete)
  3. Welche IP erhält RST/SYN+ACK Antworten? (Nur die echte!)

Aufgabe 4.3 – Timing-Unterschiede visualisieren

Vergleiche die Paketrate bei verschiedenen Timing-Templates. 

# Paranoid Scan (extrem langsam)
sudo tshark -i eth0 -w /tmp/timing_T0.pcap &
sudo nmap -T0 -p 22,80,443 172.26.54.10

# Aggressive Scan (schnell)
sudo tshark -i eth0 -w /tmp/timing_T4.pcap &
sudo nmap -T4 -p 22,80,443 172.26.54.10

# In Wireshark vergleichen:
# Statistics → IO Graphs
# → Paketrate über Zeit visualisieren
# T0: Einzelne Pakete mit großen Pausen
# T4: Burst von vielen Paketen in kurzer Zeit

Aufgabe 4.4 – Source Port Manipulation

sudo tshark -i eth0 -w /tmp/srcport.pcap &
sudo nmap --source-port 53 172.26.54.10

# Display-Filter: Pakete mit Quellport 53
tcp.srcport == 53

# Warum Port 53? DNS-Traffic wird oft durch Firewalls gelassen.
# Ebenso Port 80 (HTTP) oder Port 88 (Kerberos).

Phase 5 – Angriffsmuster erkennen

Aufgabe 5.1 – Port Scan Muster identifizieren

Verwende Wireshark-Statistiken um Scan-Muster zu erkennen, ohne den Scan selbst durchgeführt zu haben. 

# Indikator 1: Viele Verbindungen zu verschiedenen Ports von einer IP
# Statistics → Conversations → TCP
# Sortieren nach Paketen → wenige Pakete pro Verbindung = Scan

# Indikator 2: Viele RST-Pakete
tcp.flags.reset == 1 && ip.src == 172.26.54.10

# Indikator 3: Sequenzielle Portnummern
# Statistics → Endpoints → TCP → Nach Port sortieren

# Indikator 4: Zeitmuster
# Statistics → IO Graphs → Spike in kurzer Zeit

Aufgabe 5.2 – WAF-Verhalten im Traffic sehen

Ziel: Vergleiche den HTTP-Traffic gegen www.microsott.de (ohne WAF) und waf.microsott.de (mit WAF). 

# Capture starten
sudo tshark -i eth0 -f 'host 10.0.10.108 or host 10.0.10.110' \
  -w /tmp/waf_compare.pcap &

# Requests OHNE WAF
curl "http://10.0.10.108/?id=1' OR '1'='1"
curl "http://10.0.10.108/?q=<script>alert(1)</script>"

# Requests MIT WAF (HTTPS, daher -sk)
curl -sk "https://10.0.10.110/?id=1' OR '1'='1"
curl -sk "https://10.0.10.110/?q=<script>alert(1)</script>"

# Display-Filter
http.response.code == 403             # WAF Blocks
http.response.code == 200             # Erfolgreiche Requests
tls.handshake.type == 1               # TLS Client Hello (WAF = HTTPS)

Hinweis: Bei HTTPS (waf.microsott.de) ist der HTTP-Payload verschlüsselt. Man sieht nur TLS-Handshake und verschlüsselte Daten. Die 403-Response erkennt man nur, wenn man den Traffic auf dem WAF-Server selbst mitschneidet.

Aufgabe 5.3 – Brute-Force Erkennung

Erkenne Brute-Force-Versuche gegen SSH oder SMB anhand des Traffic-Musters. 

# SSH Brute-Force Muster erkennen
# Viele SSH-Verbindungen von derselben IP in kurzer Zeit
ssh                                    # Alle SSH-Pakete
tcp.port == 22 && tcp.flags.syn == 1   # Neue SSH-Verbindungen

# Statistics → IO Graphs mit Filter:
# tcp.port == 22 && tcp.flags.syn == 1
# → Spike = potentieller Brute-Force

# SMB Login-Versuche
ntlmssp.messagetype == 3               # NTLM Auth Messages
smb2.nt_status == 0xc000006d           # STATUS_LOGON_FAILURE

Phase 6 – Fortgeschrittene Analyse

Aufgabe 6.1 – TLS-Handshake analysieren

Ziel: Verstehen, welche Informationen selbst bei verschlüsseltem Traffic sichtbar sind. 

# HTTPS-Verbindung aufbauen
sudo tshark -i eth0 -f 'host 10.0.10.110' -w /tmp/tls_traffic.pcap &
curl -sk https://10.0.10.110/

# Display-Filter
tls.handshake                          # TLS Handshake Pakete
tls.handshake.type == 1                # Client Hello
tls.handshake.type == 2                # Server Hello
tls.handshake.type == 11               # Certificate

# Sichtbar trotz Verschlüsselung:
tls.handshake.extensions_server_name   # SNI (Server Name)
tls.handshake.ciphersuite              # Cipher Suites
x509af.version                         # Zertifikat-Details

Analyse-Fragen:

  1. Welche TLS-Version wird verwendet?
  2. Welche Cipher Suite wird ausgehandelt?
  3. Ist der Server Name (SNI) im Client Hello sichtbar?
  4. Welche Zertifikatsinformationen sind lesbar?

Aufgabe 6.2 – Wazuh-Agent-Kommunikation

Analysiere die Kommunikation zwischen Wazuh Agent (www.microsott.de) und Wazuh Manager. 

# Capture des Wazuh-Agent-Traffics
sudo tshark -i eth0 -f 'host 172.26.54.X and (port 1514 or port 1515)' \
  -w /tmp/wazuh_traffic.pcap &

# Display-Filter
tcp.port == 1514                       # Agent Communication
tcp.port == 1515                       # Agent Registration

# Statistics → IO Graphs
# → Baseline-Traffic vs. Traffic während eines Nmap-Scans

Analyse: Führe während des Captures einen Nmap-Scan gegen www.microsott.de durch. Beobachte den Anstieg des Wazuh-Agent-Traffics, wenn neue Alerts generiert werden.

Aufgabe 6.3 – ARP-Analyse im LAN

ARP-Traffic verrät, welche Hosts im lokalen Segment aktiv sind. 

# ARP-Traffic aufzeichnen
sudo tshark -i eth0 -f 'arp' -w /tmp/arp_traffic.pcap &

# ARP-Scan auslösen
sudo nmap -sn --send-eth 172.26.53.0/24

# Display-Filter
arp.opcode == 1                        # ARP Requests (Who has?)
arp.opcode == 2                        # ARP Replies (is at)

# ARP-Spoofing erkennen:
# Mehrere verschiedene MACs für dieselbe IP = Verdacht!
# Statistics → Endpoints → Ethernet

Phase 7 – Übungsszenarien (Red vs. Blue)

Szenario 1 – Scan Detection Challenge

Red Team: Führt verschiedene Nmap-Scans gegen das Server-Netz durch (SYN, Connect, UDP, Aggressive).

Blue Team: Analysiert NUR das PCAP und muss folgende Fragen beantworten:

  1. Welche Scan-Typen wurden verwendet?
  2. Von welcher IP kamen die Scans?
  3. Welche Hosts wurden gescannt?
  4. Welche Ports sind offen?
  5. Wurden Evasion-Techniken verwendet?
# Blue Team: Nützliche Analyse-Schritte
# 1. Überblick: Statistics → Protocol Hierarchy
# 2. Gespräche: Statistics → Conversations
# 3. Endpunkte: Statistics → Endpoints
# 4. IO Graph: Statistics → IO Graphs
# 5. Expert Info: Analyze → Expert Information

Szenario 2 – Incident Timeline erstellen

Ziel: Aus einem PCAP eine chronologische Timeline eines simulierten Angriffs erstellen. 

# Red Team führt sequenziell durch:
# 1. Host Discovery
sudo nmap -sn 172.26.54.0/24
# 2. Port Scan
sudo nmap -sS --top-ports 1000 172.26.54.X
# 3. Service Enumeration
sudo nmap -sV -sC 172.26.54.X
# 4. Vulnerability Scan
sudo nmap --script vuln 172.26.54.X
# 5. SMB Enumeration
sudo nmap --script smb-enum-shares,smb-enum-users -p 445 172.26.54.X

# Blue Team erstellt Timeline:
# Zeitstempel | Quell-IP | Ziel-IP | Aktivität | Bewertung

Tipp: Nutze tshark -r capture.pcap -T fields -e frame.time -e ip.src -e ip.dst -e tcp.dstport -e _ws.col.Info für eine tabellarische Ausgabe.

Szenario 3 – Korrelation: Wireshark + Wazuh + ELK

Ziel: Einen Angriff gleichzeitig in drei Systemen nachverfolgen.

Schritt Aktion Prüfe in
1 Nmap SYN Scan gegen www.microsott.de Wireshark: SYN-Pakete
2 HTTP Enum gegen Apache2 Wireshark: HTTP Requests
3 Wazuh Alert prüfen Wazuh: alerts.log / Dashboard
4 ELK Dashboard prüfen Kibana: wazuh-alerts-*
5 Sensor-Traffic analysieren Wireshark: Sensor-Interface 
# Alle drei gleichzeitig:

# Terminal 1: Wireshark Capture
sudo tshark -i eth0 -f 'host 10.0.10.108' -w /tmp/correlation.pcap &

# Terminal 2: Nmap Scan + HTTP Enum
sudo nmap -A -T4 10.0.10.108

# Terminal 3: Wazuh Alerts live
ssh wazuh 'tail -f /var/ossec/logs/alerts/alerts.log' | grep -i apache

# Danach: Zeitstempel in allen drei Quellen abgleichen!

Cheat Sheet – Wichtigste Display-Filter

Basis-Filter

Filter Beschreibung
ip.addr == X.X.X.X Traffic von/zu einer IP
ip.src == X.X.X.X Nur von einer IP
ip.dst == X.X.X.X Nur zu einer IP
tcp.port == 80 TCP Port (src oder dst)
udp.port == 53 UDP Port
eth.addr == aa:bb:cc:dd:ee:ff MAC-Adresse

TCP-Flags

Filter Beschreibung
tcp.flags.syn == 1 && tcp.flags.ack == 0 SYN (neue Verbindung)
tcp.flags.syn == 1 && tcp.flags.ack == 1 SYN+ACK (Port offen)
tcp.flags.reset == 1 RST (Port geschlossen / Abbruch)
tcp.flags.fin == 1 FIN (Verbindungsende)
tcp.flags == 0x00 NULL Scan
tcp.flags == 0x29 Xmas Scan (FIN+PSH+URG)

Protokoll-Filter

Filter Beschreibung
http.request HTTP Requests
dns DNS Traffic
smb2 SMB2 Traffic
mqtt MQTT Traffic
tls.handshake TLS Handshakes
arp ARP Traffic
icmp ICMP (Ping etc.)
ssh SSH Traffic

Scan-Erkennung

Filter Erkennt
tcp.flags.syn==1 && tcp.flags.ack==0 SYN Scan
icmp.type==3 && icmp.code==3 UDP Scan (Port Unreachable)
ip.flags.mf==1 ip.frag_offset>0 Fragmentierte Pakete
tcp.window_size==1 OS Fingerprinting Probe

Nützliche tshark-Kommandos

# PCAP lesen mit Filter
tshark -r capture.pcap -Y 'http.request'

# Bestimmte Felder extrahieren
tshark -r capture.pcap -T fields -e ip.src -e ip.dst -e tcp.dstport

# Statistiken: Protokollhierarchie
tshark -r capture.pcap -z io,phs

# Statistiken: Conversations
tshark -r capture.pcap -z conv,tcp

# Statistiken: Endpoints
tshark -r capture.pcap -z endpoints,ip

# HTTP-Requests extrahieren
tshark -r capture.pcap -Y http.request -T fields \
  -e frame.time -e ip.src -e http.host -e http.request.uri

Weiterführende Quellen

Abgerufen von „http://wiki.ixheim.de/index.php?title=Wireshark_8421&oldid=67205“