Maximilian.pottgiesser: /* Wireshark Praxis – Cybersecurity Training */

2026-02-26T12:29:04Z

Wireshark Praxis – Cybersecurity Training

Maximilian.pottgiesser: Die Seite wurde neu angelegt: „= Wireshark Praxis – Cybersecurity Training = ''Passend zur Nmap-Praxis – gleiche Umgebung, gleiche Netze'' == Netzwerkübersicht == {| class="wikitable…“

2026-02-26T10:32:02Z

Die Seite wurde neu angelegt: „= Wireshark Praxis – Cybersecurity Training = ''Passend zur Nmap-Praxis – gleiche Umgebung, gleiche Netze'' == Netzwerkübersicht == {| class="wikitable…“

Neue Seite

= Wireshark Praxis – Cybersecurity Training =

''Passend zur Nmap-Praxis – gleiche Umgebung, gleiche Netze''

== Netzwerkübersicht ==

{| class="wikitable"
! 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 ===
<pre>
# 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
</pre>

=== 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.

{| class="wikitable"
! Typ !! Syntax-Beispiel !! Wann verwenden
|-
| Capture-Filter || <code>host 172.26.54.10</code> || Vor dem Capture – reduziert Datenmenge
|-
| Capture-Filter || <code>port 80 or port 443</code> || Nur Webtraffic aufzeichnen
|-
| Capture-Filter || <code>net 172.26.54.0/24</code> || Ganzes Subnetz aufzeichnen
|-
| Display-Filter || <code>ip.addr == 172.26.54.10</code> || Nach dem Capture filtern
|-
| Display-Filter || <code>tcp.port == 80</code> || Bestimmten Port anzeigen
|-
| Display-Filter || <code>http.request.method == GET</code> || 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'''
<pre>
# 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
</pre>

'''Schritt 2: In Wireshark analysieren'''
<pre>
# 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
</pre>

'''Analyse-Fragen:'''
# Wie viele SYN-Pakete wurden gesendet?
# Welche Ports haben mit SYN+ACK geantwortet (offen)?
# Wird der 3-Way-Handshake abgeschlossen? (Nein – das ist der Stealth-Aspekt!)
# 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.

<pre>
# 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
</pre>

<pre>
# 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
</pre>

=== Aufgabe 2.3 – UDP Scan erkennen ===

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

<pre>
# 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
</pre>

'''Analyse-Fragen:'''
# Welche Ports erzeugen ICMP Port Unreachable (geschlossen)?
# Welche Ports zeigen keine Antwort (offen|filtered)?
# 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.

<pre>
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
</pre>

----

== Phase 3 – Protokollanalyse ==

=== Aufgabe 3.1 – HTTP-Traffic analysieren (DMZ) ===

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

<pre>
# 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/
</pre>

<pre>
# 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
</pre>

'''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.

<pre>
# 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)
</pre>

=== Aufgabe 3.3 – SMB-Traffic analysieren (win2022) ===

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

<pre>
# 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
</pre>

'''Analyse-Fragen:'''
# Welche SMB-Dialektversion wird ausgehandelt?
# Sind Benutzernamen im NTLM-Handshake sichtbar?
# 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.

<pre>
# 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
</pre>

----

== 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 ===
<pre>
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
</pre>

'''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 ===
<pre>
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
</pre>

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

=== Aufgabe 4.3 – Timing-Unterschiede visualisieren ===

Vergleiche die Paketrate bei verschiedenen Timing-Templates.

<pre>
# 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
</pre>

=== Aufgabe 4.4 – Source Port Manipulation ===
<pre>
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).
</pre>

----

== 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.

<pre>
# 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
</pre>

=== 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).

<pre>
# 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)
</pre>

'''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.

<pre>
# 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
</pre>

----

== Phase 6 – Fortgeschrittene Analyse ==

=== Aufgabe 6.1 – TLS-Handshake analysieren ===

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

<pre>
# 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
</pre>

'''Analyse-Fragen:'''
# Welche TLS-Version wird verwendet?
# Welche Cipher Suite wird ausgehandelt?
# Ist der Server Name (SNI) im Client Hello sichtbar?
# Welche Zertifikatsinformationen sind lesbar?

=== Aufgabe 6.2 – Wazuh-Agent-Kommunikation ===

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

<pre>
# 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
</pre>

'''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.

<pre>
# 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
</pre>

----

== 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:
# Welche Scan-Typen wurden verwendet?
# Von welcher IP kamen die Scans?
# Welche Hosts wurden gescannt?
# Welche Ports sind offen?
# Wurden Evasion-Techniken verwendet?

<pre>
# 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
</pre>

=== Szenario 2 – Incident Timeline erstellen ===

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

<pre>
# 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
</pre>

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

=== Szenario 3 – Korrelation: Wireshark + Wazuh + ELK ===

Ziel: Einen Angriff gleichzeitig in drei Systemen nachverfolgen.

{| class="wikitable"
! 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
|}

<pre>
# 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!
</pre>

----

== Cheat Sheet – Wichtigste Display-Filter ==

=== Basis-Filter ===

{| class="wikitable"
! Filter !! Beschreibung
|-
| <code>ip.addr == X.X.X.X</code> || Traffic von/zu einer IP
|-
| <code>ip.src == X.X.X.X</code> || Nur von einer IP
|-
| <code>ip.dst == X.X.X.X</code> || Nur zu einer IP
|-
| <code>tcp.port == 80</code> || TCP Port (src oder dst)
|-
| <code>udp.port == 53</code> || UDP Port
|-
| <code>eth.addr == aa:bb:cc:dd:ee:ff</code> || MAC-Adresse
|}

=== TCP-Flags ===

{| class="wikitable"
! Filter !! Beschreibung
|-
| <code>tcp.flags.syn == 1 && tcp.flags.ack == 0</code> || SYN (neue Verbindung)
|-
| <code>tcp.flags.syn == 1 && tcp.flags.ack == 1</code> || SYN+ACK (Port offen)
|-
| <code>tcp.flags.reset == 1</code> || RST (Port geschlossen / Abbruch)
|-
| <code>tcp.flags.fin == 1</code> || FIN (Verbindungsende)
|-
| <code>tcp.flags == 0x00</code> || NULL Scan
|-
| <code>tcp.flags == 0x29</code> || Xmas Scan (FIN+PSH+URG)
|}

=== Protokoll-Filter ===

{| class="wikitable"
! Filter !! Beschreibung
|-
| <code>http.request</code> || HTTP Requests
|-
| <code>dns</code> || DNS Traffic
|-
| <code>smb2</code> || SMB2 Traffic
|-
| <code>mqtt</code> || MQTT Traffic
|-
| <code>tls.handshake</code> || TLS Handshakes
|-
| <code>arp</code> || ARP Traffic
|-
| <code>icmp</code> || ICMP (Ping etc.)
|-
| <code>ssh</code> || SSH Traffic
|}

=== Scan-Erkennung ===

{| class="wikitable"
! Filter !! Erkennt
|-
| <code>tcp.flags.syn==1 && tcp.flags.ack==0</code> || SYN Scan
|-
| <code>icmp.type==3 && icmp.code==3</code> || UDP Scan (Port Unreachable)
|-
| <code>ip.flags.mf==1 || ip.frag_offset>0</code> || Fragmentierte Pakete
|-
| <code>tcp.window_size==1</code> || OS Fingerprinting Probe
|}

=== Nützliche tshark-Kommandos ===

<pre>
# 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
</pre>

----

== Weiterführende Quellen ==

* [https://www.wireshark.org/docs/wsug_html/ Wireshark User Guide (offiziell)]
* [https://www.wireshark.org/docs/dfref/ Wireshark Display Filter Reference]
* [https://www.wireshark.org/docs/man-pages/tshark.html tshark Manual]
* [https://documentation.wazuh.com/current/user-manual/ruleset/ruleset-xml-syntax/rules.html Wazuh Ruleset Dokumentation]
* Nmap Praxis (Begleitdokument)

← Nächstältere Version		Version vom 26. Februar 2026, 12:29 Uhr
Zeile 1:		Zeile 1:
	= Wireshark Praxis – Cybersecurity Training =		= Wireshark Praxis – Cybersecurity Training =
−
−	~~''Passend zur Nmap-Praxis – gleiche Umgebung, gleiche Netze''~~

	== Netzwerkübersicht ==		== Netzwerkübersicht ==

Wireshark 8421 - Versionsgeschichte

Maximilian.pottgiesser: /* Wireshark Praxis – Cybersecurity Training */

Maximilian.pottgiesser: Die Seite wurde neu angelegt: „= Wireshark Praxis – Cybersecurity Training = ''Passend zur Nmap-Praxis – gleiche Umgebung, gleiche Netze'' == Netzwerkübersicht == {| class="wikitable…“