Xinux Wiki - Benutzerbeiträge [de]

SMTP - Beispiel

2026-04-24T06:06:17Z

Maximilian.pottgiesser:

Telnet
*telnet 10.10.XX.5 25

<pre>
EHLO client.it2XX.lab
MAIL FROM:<sender@it2XX.lab>
RCPT TO:<empfaenger@i21XX.lab>
DATA
Subject: Testmail Kurs 1106
From: sender@it2XX.lab
To: empfaenger@it2XX.lab

Hallo,
das ist eine Testmail im Klartext.
Wireshark laeuft mit - Passwort und Inhalt sind sichtbar!

Viele Gruesse
.
QUIT
</pre>

SMTP - Beispiel

2026-04-24T06:05:46Z

Maximilian.pottgiesser:

Telnet
*telnet 10.10.XX.10 25

<pre>
EHLO client.it2XX.lab
MAIL FROM:<sender@it2XX.lab>
RCPT TO:<empfaenger@i21XX.lab>
DATA
Subject: Testmail Kurs 1106
From: sender@it2XX.lab
To: empfaenger@it2XX.lab

Hallo,
das ist eine Testmail im Klartext.
Wireshark laeuft mit - Passwort und Inhalt sind sichtbar!

Viele Gruesse
.
QUIT
</pre>

SMTP - Beispiel

2026-04-24T05:36:49Z

Maximilian.pottgiesser:

Telnet
*telnet 10.10.XX.12 25

<pre>
EHLO client.it2XX.lab
MAIL FROM:<sender@it2XX.lab>
RCPT TO:<empfaenger@i21XX.lab>
DATA
Subject: Testmail Kurs 1106
From: sender@it2XX.lab
To: empfaenger@it2XX.lab

Hallo,
das ist eine Testmail im Klartext.
Wireshark laeuft mit - Passwort und Inhalt sind sichtbar!

Viele Gruesse
.
QUIT
</pre>

SMTP - Beispiel

2026-04-24T05:35:46Z

Maximilian.pottgiesser: Die Seite wurde neu angelegt: „<pre> EHLO client.it2XX.lab MAIL FROM:<sender@it2XX.lab> RCPT TO:<empfaenger@i21XX.lab> DATA Subject: Testmail Kurs 1106 From: sender@it2XX.lab To: empfaenger@…“

<pre>
EHLO client.it2XX.lab
MAIL FROM:<sender@it2XX.lab>
RCPT TO:<empfaenger@i21XX.lab>
DATA
Subject: Testmail Kurs 1106
From: sender@it2XX.lab
To: empfaenger@it2XX.lab

Hallo,
das ist eine Testmail im Klartext.
Wireshark laeuft mit - Passwort und Inhalt sind sichtbar!

Viele Gruesse
.
QUIT
</pre>

Aufgaben 1106

2026-04-24T05:35:02Z

Maximilian.pottgiesser:

*[[TCP/IP Aufgaben ISO/TCP-IP Modelle]]

*[[TCP/IP Aufgaben Block IP]]
*[[TCP/IP Aufgaben Block TCP]]
*[[TCP/IP Aufgaben Block UDP]]
*[[TCP/IP Aufgaben Block ARP]]

*[[Wahl der Geräte]]
*[[Subnetting Berechnen Aufgaben]]
*[[Subnetting Aufgaben]]
*[[Supernetting Aufgaben]]
*[[Routing Aufgaben]]

*[[traceroute Aufgabe]]
*[[1106 - Analyse und Fehlersuche]]
*[[DNS Aufgaben]]
*[[SMTP - Beispiel]]
{{#drawio:1106-Netz}}

1106 - Analyse und Fehlersuche

2026-04-23T19:07:54Z

Maximilian.pottgiesser: /* Labor 4 */

Labore befinden sich im Share ''\\Platz02Doz\Share''.

= Labor 1 =
*Finden Sie heraus warum, Client1 kein Internet hat.
*Konfigurieren Sie Client1 so, dass er Internetzugriff hat.

= Labor 2 =
*Finden Sie heraus warum, Client1 kein Internet hat.
*Konfigurieren Sie den Router so, dass Client1 Internetzugriff hat.

= Labor 3 =
*Finden Sie heraus warum, die Clients keine Webseiten im Internet aufrufen können.
*Beheben Sie den Fehler entweder über den DNS-Server oder den Router.

= Labor 4 =
*Die Clients sollen die Webseite '''http://web.it2XX.int/i1XX/index.html''' besuchen können.
*Die Clients sollen Internetzugriff bekommen.

1106 - Analyse und Fehlersuche

2026-04-23T18:43:32Z

Maximilian.pottgiesser: /* Labor 4 */

Labore befinden sich im Share ''\\Platz02Doz\Share''.

= Labor 1 =
*Finden Sie heraus warum, Client1 kein Internet hat.
*Konfigurieren Sie Client1 so, dass er Internetzugriff hat.

= Labor 2 =
*Finden Sie heraus warum, Client1 kein Internet hat.
*Konfigurieren Sie den Router so, dass Client1 Internetzugriff hat.

= Labor 3 =
*Finden Sie heraus warum, die Clients keine Webseiten im Internet aufrufen können.
*Beheben Sie den Fehler entweder über den DNS-Server oder den Router.

= Labor 4 =
*Die Clients sollen die Webseite '''http://web.it2XX.int''' besuchen können.
*Die Clients sollen Internetzugriff bekommen.

SMTP-Mailpit

2026-04-23T13:54:17Z

Maximilian.pottgiesser:

<pre>
# Zielordner anlegen
New-Item -ItemType Directory -Path "C:\mailpit"

# Aktuelle Version herunterladen
Invoke-WebRequest `
-Uri "https://github.com/axllent/mailpit/releases/latest/download/mailpit-windows-amd64.zip" `
-OutFile "C:\mailpit\mailpit.zip"

# Entpacken
Expand-Archive -Path "C:\mailpit\mailpit.zip" -DestinationPath "C:\mailpit"

# Zip aufräumen
Remove-Item "C:\mailpit\mailpit.zip"

#Starten
C:\mailpit\mailpit.exe --smtp 0.0.0.0:25 --listen 0.0.0.0:8025
</pre>

SMTP-Mailpit

2026-04-23T13:46:56Z

Maximilian.pottgiesser: Die Seite wurde neu angelegt: „<pre> # Zielordner anlegen New-Item -ItemType Directory -Path "C:\mailpit" # Aktuelle Version herunterladen Invoke-WebRequest ` -Uri "https://github.com/ax…“

Technik der Netze - Netzwerkdienste und Protokolle als Basis der Optimierung

2026-04-23T13:46:36Z

Maximilian.pottgiesser: /* TCP/IP Dienste (Theorie + Praxis) */

= Allgemeines =

* [[Robin Will]]
* [[Benutzer:Linkai.zhang|Linkai Zhang]]
* [[Zeiten]]
* [[1106 - Plan]]
* [[1106 - Netzplan]]
* [[1106 - Website]]

=Auffrischung und Vertiefung der Kenntnisse in den LAN-Technologien=

* [[ISO/OSI-Referenzmodell]]
* [[LAN-Technologien]]
* [[Protokolle und Dienste]]

=Vertiefung der Kenntnisse TCP/IP=
* [[IP-Header-Aufbau, Fragmentierung, ARP, Fehlerüberwachung im IP]]
* [[UDP-Header-Aufbau, und TCP-Header-Aufbau]]
* [[Network Address Translation]]
* [[IP-Adressieung - Subnetting / Supernetting (Wiederholung und Auffrischung)]]
* [[Routing Protokolle]]

=TCP/IP Dienste (Theorie + Praxis)=
* [[DHCP]]
* [[DNS]]
* [[WINS]]
* [[SMTP]]
* [[SMTP-Mailpit]]
* [[HTTP]]
* [[RAS]]
* [[SNMP]]
* [[IPsec]]
* [[NAP]]
* [[ILL]]

=Ablauf und Probleme eines Datendialogs=
*[[Datendialog]]

=Analyse und Fehlersuche in Windows Netzen=
*[[Analyse und Fehlersuche in Windows Netzen]]

=Analysetechnik=
* [[Protokollanalyse in Theorie und Praxis]]

=Aufgaben=
*[[Aufgaben 1106]]

SNMP Windows Server

2026-04-23T11:33:46Z

Maximilian.pottgiesser: Die Seite wurde neu angelegt: „Auf jedem Windows Server der überwacht werden soll: <pre> # SNMP-Feature installieren Install-WindowsFeature SNMP-Service -IncludeManagementTools # Dienst au…“

Auf jedem Windows Server der überwacht werden soll:
<pre>
# SNMP-Feature installieren
Install-WindowsFeature SNMP-Service -IncludeManagementTools

# Dienst auf Automatisch setzen
Set-Service -Name SNMP -StartupType Automatic
Start-Service SNMP
SNMP per GUI konfigurieren:

Start → Services → SNMP Service → Rechtsklick → Eigenschaften → Security
→ Community String: "public" → Rights: READ ONLY → Add
→ "Accept SNMP packets from these hosts"
→ IP von LibreNMS eintragen: 10.10.XX.10 → Add
→ OK → Dienst neu starten
</pre>

SNMP

2026-04-23T11:33:13Z

Maximilian.pottgiesser: /* Umsetzung */

=Allgemein=
*[[SNMP Erklärung]]
*[[SNMP Sicherheit]]

=Umsetzung=
*[[SNMP Server]]
*[[SNMP Client]]
*[[SNMP Version 3]]
*[[SNMP Browser]]
*[[SNMP Windows Server]]

1106 - Website

2026-04-23T09:23:27Z

Maximilian.pottgiesser:

<pre>
Set-Content -Path "C:\inetpub\wwwroot\it1XX\index.html" -Value @"
<!DOCTYPE html>
<html lang="de">
<head>
<meta charset="UTF-8">
<title>Schulungslab Login – it1XX</title>
<style>
* { box-sizing: border-box; margin: 0; padding: 0; }
body {
font-family: Arial, sans-serif;
background: #f0f2f5;
display: flex;
justify-content: center;
align-items: center;
min-height: 100vh;
}
.card {
background: white;
padding: 40px;
border-radius: 8px;
box-shadow: 0 2px 12px rgba(0,0,0,0.1);
width: 360px;
}
.card h1 {
font-size: 22px;
margin-bottom: 8px;
color: #1a1a2e;
}
.card p {
font-size: 13px;
color: #666;
margin-bottom: 24px;
}
label {
display: block;
font-size: 13px;
font-weight: bold;
color: #333;
margin-bottom: 4px;
}
input {
width: 100%;
padding: 10px 12px;
border: 1px solid #ccc;
border-radius: 4px;
font-size: 14px;
margin-bottom: 16px;
}
input:focus {
outline: none;
border-color: #4a90e2;
}
button {
width: 100%;
padding: 11px;
background: #4a90e2;
color: white;
border: none;
border-radius: 4px;
font-size: 15px;
cursor: pointer;
}
button:hover { background: #357abd; }
.info {
margin-top: 20px;
padding: 10px;
background: #fff8e1;
border-left: 3px solid #f0a500;
font-size: 12px;
color: #555;
border-radius: 2px;
}
.footer {
margin-top: 16px;
text-align: center;
font-size: 11px;
color: #aaa;
}
</style>
</head>
<body>
<div class="card">
<h1>Unternehmensportal</h1>
<p>Bitte melden Sie sich mit Ihren Zugangsdaten an.</p>

<form method="POST" action="/login.php">
<label for="username">Benutzername</label>
<input type="text" id="username" name="username"
placeholder="benutzername" autocomplete="off">

<label for="password">Passwort</label>
<input type="password" id="password" name="password"
placeholder="••••••••" autocomplete="off">

<button type="submit">Anmelden</button>
</form>

<div class="info">
Schulungsumgebung – Zugangsdaten werden im Klartext übertragen.
Wireshark Filter: <strong>tcp.port == 80</strong>
</div>

<div class="footer">it1XX.lab · Kurs 1106 · Technik der Netze</div>
</div>
</body>
</html>
"@
</pre>

<pre>
Set-Content -Path "C:\inetpub\wwwroot\it1XX\login.html" -Value @"
<!DOCTYPE html>
<html lang="de">
<head>
<meta charset="UTF-8">
<title>Angemeldet</title>
<style>
body { font-family: Arial, sans-serif; background: #f0f2f5;
display: flex; justify-content: center; align-items: center; min-height: 100vh; }
.card { background: white; padding: 40px; border-radius: 8px;
box-shadow: 0 2px 12px rgba(0,0,0,0.1); width: 360px; text-align: center; }
h1 { color: #2e7d32; margin-bottom: 12px; }
p { color: #555; font-size: 14px; }
a { display: inline-block; margin-top: 20px; color: #4a90e2; font-size: 13px; }
</style>
</head>
<body>
<div class="card">
<h1>Anmeldung erfolgreich</h1>
<p>Die Zugangsdaten wurden im Klartext übertragen.<br>
Prüfen Sie jetzt Ihren Wireshark-Mitschnitt.</p>
<a href="/index.html">Zurück zum Login</a>
</div>
</body>
</html>
"@

</pre>

<pre>
(Get-Content "C:\inetpub\wwwroot\it1XX\index.html") `
-replace 'action="/login.php"', 'action="/login.html"' | `
Set-Content "C:\inetpub\wwwroot\it1XX\index.html"
</pre>

1106 - Website

2026-04-23T09:22:04Z

Maximilian.pottgiesser: Die Seite wurde neu angelegt: „<pre> Set-Content -Path "C:\inetpub\wwwroot\it1XX\login.html" -Value @" <!DOCTYPE html> <html lang="de"> <head> <meta charset="UTF-8"> <title>Angemeldet</t…“

<pre>
Set-Content -Path "C:\inetpub\wwwroot\it1XX\login.html" -Value @"
<!DOCTYPE html>
<html lang="de">
<head>
<meta charset="UTF-8">
<title>Angemeldet</title>
<style>
body { font-family: Arial, sans-serif; background: #f0f2f5;
display: flex; justify-content: center; align-items: center; min-height: 100vh; }
.card { background: white; padding: 40px; border-radius: 8px;
box-shadow: 0 2px 12px rgba(0,0,0,0.1); width: 360px; text-align: center; }
h1 { color: #2e7d32; margin-bottom: 12px; }
p { color: #555; font-size: 14px; }
a { display: inline-block; margin-top: 20px; color: #4a90e2; font-size: 13px; }
</style>
</head>
<body>
<div class="card">
<h1>Anmeldung erfolgreich</h1>
<p>Die Zugangsdaten wurden im Klartext übertragen.<br>
Prüfen Sie jetzt Ihren Wireshark-Mitschnitt.</p>
<a href="/index.html">Zurück zum Login</a>
</div>
</body>
</html>
"@

</pre>

Technik der Netze - Netzwerkdienste und Protokolle als Basis der Optimierung

2026-04-23T09:21:32Z

Maximilian.pottgiesser: /* Allgemeines */

= Allgemeines =

* [[Robin Will]]
* [[Benutzer:Linkai.zhang|Linkai Zhang]]
* [[Zeiten]]
* [[1106 - Plan]]
* [[1106 - Netzplan]]
* [[1106 - Website]]

=Auffrischung und Vertiefung der Kenntnisse in den LAN-Technologien=

* [[ISO/OSI-Referenzmodell]]
* [[LAN-Technologien]]
* [[Protokolle und Dienste]]

=Vertiefung der Kenntnisse TCP/IP=
* [[IP-Header-Aufbau, Fragmentierung, ARP, Fehlerüberwachung im IP]]
* [[UDP-Header-Aufbau, und TCP-Header-Aufbau]]
* [[Network Address Translation]]
* [[IP-Adressieung - Subnetting / Supernetting (Wiederholung und Auffrischung)]]
* [[Routing Protokolle]]

=TCP/IP Dienste (Theorie + Praxis)=
* [[DHCP]]
* [[DNS]]
* [[WINS]]
* [[SMTP]]
* [[HTTP]]
* [[RAS]]
* [[SNMP]]
* [[IPsec]]
* [[NAP]]
* [[ILL]]

=Ablauf und Probleme eines Datendialogs=
*[[Datendialog]]

=Analyse und Fehlersuche in Windows Netzen=
*[[Analyse und Fehlersuche in Windows Netzen]]

=Analysetechnik=
* [[Protokollanalyse in Theorie und Praxis]]

=Aufgaben=
*[[Aufgaben 1106]]

Datei:1106-Netzplan.drawio.png

2026-04-23T06:12:49Z

Maximilian.pottgiesser: Maximilian.pottgiesser lud eine neue Version von Datei:1106-Netzplan.drawio.png hoch

Datei:1106-Netzplan.drawio.png

2026-04-22T13:32:37Z

Maximilian.pottgiesser: Maximilian.pottgiesser lud eine neue Version von Datei:1106-Netzplan.drawio.png hoch

Datei:1106-Netzplan.drawio.png

2026-04-22T11:58:28Z

Maximilian.pottgiesser: Maximilian.pottgiesser lud eine neue Version von Datei:1106-Netzplan.drawio.png hoch

Datei:1106-Netzplan.drawio.png

2026-04-22T08:46:38Z

Maximilian.pottgiesser: Maximilian.pottgiesser lud eine neue Version von Datei:1106-Netzplan.drawio.png hoch

Datei:1106-Netzplan.drawio.png

2026-04-22T07:06:38Z

Maximilian.pottgiesser:

1106 - Netzplan

2026-04-22T06:39:23Z

Maximilian.pottgiesser:

1106 - Netzplan

2026-04-22T06:39:11Z

Maximilian.pottgiesser: Die Seite wurde neu angelegt: „{{#drawio:1106-Netz}}“

Technik der Netze - Netzwerkdienste und Protokolle als Basis der Optimierung

2026-04-22T06:38:59Z

Maximilian.pottgiesser: /* Allgemeines */

= Allgemeines =

* [[Robin Will]]
* [[Benutzer:Linkai.zhang|Linkai Zhang]]
* [[Zeiten]]
* [[1106 - Plan]]
* [[1106 - Netzplan]]

=Auffrischung und Vertiefung der Kenntnisse in den LAN-Technologien=

* [[ISO/OSI-Referenzmodell]]
* [[LAN-Technologien]]
* [[Protokolle und Dienste]]

=Vertiefung der Kenntnisse TCP/IP=
* [[IP-Header-Aufbau, Fragmentierung, ARP, Fehlerüberwachung im IP]]
* [[UDP-Header-Aufbau, und TCP-Header-Aufbau]]
* [[Network Address Translation]]
* [[IP-Adressieung - Subnetting / Supernetting (Wiederholung und Auffrischung)]]
* [[Routing Protokolle]]

=TCP/IP Dienste (Theorie + Praxis)=
* [[DHCP]]
* [[DNS]]
* [[WINS]]
* [[SMTP]]
* [[HTTP]]
* [[RAS]]
* [[SNMP]]
* [[IPsec]]
* [[NAP]]
* [[ILL]]

=Ablauf und Probleme eines Datendialogs=
*[[Datendialog]]

=Analyse und Fehlersuche in Windows Netzen=
*[[Analyse und Fehlersuche in Windows Netzen]]

=Analysetechnik=
* [[Protokollanalyse in Theorie und Praxis]]

=Aufgaben=
*[[Aufgaben 1106]]

Supernetting Aufgaben

2026-04-21T12:19:19Z

Maximilian.pottgiesser: /* Aufgabe */

=Sie haben folgende Netze=

a. 172.155.127.0/24

b. 172.155.128.0/24

c. 172.155.129.0/24

d. 172.155.130.0/24

e. 172.155.131.0/24

f. 172.155.132.0/24
=Aufgabe=

*Welche Netze können zusammengelegt werden wenn die Netzmaske 255.255.252.0 lautet soll?
*Wie lautet die Netzbeginn?
*Wie lautet der Broadcast?
*Wieviel Rechner können maximal an diesem Netz angeschlossen sein?

=Sie haben folgende Netze=

a. 10.53.0.0/16

b. 10.54.0.0/16

c. 10.55.0.0/16

d. 10.56.0.0/16

e. 10.57.0.0/16

f. 10.58.0.0/16

g. 10.59.0.0/16

=Aufgabe=

*Welche Netze können zusammengelegt werden wenn die Netzmaske 255.248.0.0 lautet soll? (Nicht alle Netze sind hier angegeben. Also nicht verunsichern lassen (-: )

*Wie lautet die Netzbeginn?
*Wie lautet der Broadcast?
*Wieviel Rechner können maximal an diesem Netz angeschlossen sein?

Subnetting Aufgaben

2026-04-21T12:07:24Z

Maximilian.pottgiesser: /* Aufgabe 2 */

=Aufgabe=
;Ein neues Callcenter wird gegründet.
;Sie bekommen die Aufgabe ein Adressierungschema zu planen.
;Sie sollen ein Teil eines Callcenterverbundes werden und bekommen folgendes Netz zugewiesen:
;172.29.32.0/22
;Callcenter Agents benötigen 267 IP Adressen
;Teamleitung benötigt 18 IP Adressen
;Geschäftsleitung benötigt 17 IP Adressen.
;Buchhaltung benötigt 4 IP Adressen
;Akquise benötigt 6 IP Adressen
*Teilen Sie die Netze ein und halten Sie diese so klein wie möglich.
*Berücksichtigen Sie, dass die Teamleitung sich um 50% erhöhen könnte.
*Es wird darüber nachgedacht in Zukunft Mitarbeiter über VPN anzubinden. Hier sollte man mit einer Kapaziät von 50 Mitarbeitern rechnen.
{{#drawio:callcenter-1}}

=Aufgabe 2 =
;Ein neues Callcenter wird gegründet.
;Sie bekommen die Aufgabe ein Adressierungschema zu planen.
;Sie sollen ein Teil eines Callcenterverbundes werden und bekommen folgendes Netz zugewiesen:
;192.168.48.0/22
;Callcenter Agents benötigen 412 IP Adressen
;Teamleitung benötigt 18 IP Adressen
;Geschäftsleitung benötigt 17 IP Adressen.
;Buchhaltung benötigt 32 IP Adressen
;VPN User benötigt 72 IP Adressen
;Akquise benötigt 2 IP Adressen

*Teilen Sie die Netze ein und halten Sie diese so klein wie möglich.

=Aufgabe 3=
;Ein Administrator plant ein neues Adressierungsschema in der Firma und benötigt dafür ihre Hilfe.

;Folgendes Lagebild sei gegeben:
;Produktion benötigt 257 IP Adressen
;Buchhaltung benötigt 4 IP Adressen
;Marketing benötigt 6 IP Adressen
;Geschäftsleitung benötigt 17 IP Adressen
;Betriebsrat benötigt 2 IP Adressen

;Dem Administrator wurde das IP Netz 24.12.0.0/22 zugeteilt. Adressieren sie aus diesem Netz alle Bereiche und machen die Netze so klein wie möglich.
;Im Marketing und in der Buchhaltung rechnet die Geschäftsleitung mit einem Aufwuchs von 100% in den nächsten Jahren, berücksichtigen Sie das in ihrer Planung

Subnetting Aufgaben

2026-04-21T12:04:39Z

Maximilian.pottgiesser: /* Aufgabe */

Subnetting Berechnen Aufgaben

2026-04-21T11:53:27Z

Maximilian.pottgiesser: /* Aufgabe 8 */

=Aufgabe 1=
;Sie haben folgende IP Address vorgegeben 212.88.77.3/24
*Wie lautet die Netzbeginn?
*Wie lautet der Broadcast?
*Wieviele IP Addressen können real vergeben werden?

=Aufgabe 2=
;Sie haben folgende IP Address vorgegeben 12.6.139.3/16
*Wie lautet die Netzbeginn?
*Wie lautet der Broadcast?
*Wieviele IP Addressen können real vergeben werden?

=Aufgabe 3=
;Sie haben folgende IP Address vorgegeben 6.67.35.156/8
*Wie lautet die Netzbeginn?
*Wie lautet der Broadcast?
*Wieviele IP Addressen können real vergeben werden?

=Aufgabe 4=
;Sie haben folgende IP Address vorgegeben 76.68.145.16/12
*Wie lautet die Netzbeginn?
*Wie lautet der Broadcast?
*Wieviele IP Addressen können real vergeben werden?

=Aufgabe 5=
;Sie haben folgende IP Address vorgegeben 192.168.178.153/28
*Wie lautet die Netzbeginn?
*Wie lautet der Broadcast?
*Wieviele IP Addressen können real vergeben werden?
*[[Aufgabe 5 als Vorzeigebeispiel]]

=Aufgabe 6=
;Sie haben folgende IP Address vorgegeben 192.168.178.153/27
*Wie lautet die Netzbeginn?
*Wie lautet der Broadcast?
*Wieviele IP Addressen können real vergeben werden?
=Aufgabe 7=
;Sie haben folgende IP Address vorgegeben 6.67.29.156/22
*Wie lautet die Netzbeginn?
*Wie lautet der Broadcast?
*Wieviele IP Addressen können real vergeben werden?
=Aufgabe 8=
;Sie haben folgende IP Address vorgegeben 172.16.133.111/255.255.248.0
*Wie lautet die Netzbeginn?
*Wie lautet der Broadcast?
*Wieviele IP Addressen können real vergeben werden?

=Aufgabe 9=
;Sie haben folgende IP Address vorgegeben 10.176.133.111/255.128.0.0
*Wie lautet die Netzbeginn?
*Wie lautet der Broadcast?
*Wieviele IP Addressen können real vergeben werden?

Subnetting Berechnen Aufgaben

2026-04-21T11:48:14Z

Maximilian.pottgiesser: /* Aufgabe 4 */

=Aufgabe 1=
;Sie haben folgende IP Address vorgegeben 212.88.77.3/24
*Wie lautet die Netzbeginn?
*Wie lautet der Broadcast?
*Wieviele IP Addressen können real vergeben werden?

=Aufgabe 2=
;Sie haben folgende IP Address vorgegeben 12.6.139.3/16
*Wie lautet die Netzbeginn?
*Wie lautet der Broadcast?
*Wieviele IP Addressen können real vergeben werden?

=Aufgabe 3=
;Sie haben folgende IP Address vorgegeben 6.67.35.156/8
*Wie lautet die Netzbeginn?
*Wie lautet der Broadcast?
*Wieviele IP Addressen können real vergeben werden?

=Aufgabe 4=
;Sie haben folgende IP Address vorgegeben 76.68.145.16/12
*Wie lautet die Netzbeginn?
*Wie lautet der Broadcast?
*Wieviele IP Addressen können real vergeben werden?

=Aufgabe 5=
;Sie haben folgende IP Address vorgegeben 192.168.178.153/28
*Wie lautet die Netzbeginn?
*Wie lautet der Broadcast?
*Wieviele IP Addressen können real vergeben werden?
*[[Aufgabe 5 als Vorzeigebeispiel]]

=Aufgabe 6=
;Sie haben folgende IP Address vorgegeben 192.168.178.153/27
*Wie lautet die Netzbeginn?
*Wie lautet der Broadcast?
*Wieviele IP Addressen können real vergeben werden?
=Aufgabe 7=
;Sie haben folgende IP Address vorgegeben 6.67.29.156/22
*Wie lautet die Netzbeginn?
*Wie lautet der Broadcast?
*Wieviele IP Addressen können real vergeben werden?
=Aufgabe 8=
;Sie haben folgende IP Address vorgegeben 172.16.133.111/255.255.248.0
*Wie lautet die Netzbeginn?
*Wie lautet der Broadcast?
*Wieviele IP Addressen können real vergeben werden?
=Aufgabe 9=
;Sie haben folgende IP Address vorgegeben 10.176.133.111/255.128.0.0
*Wie lautet die Netzbeginn?
*Wie lautet der Broadcast?
*Wieviele IP Addressen können real vergeben werden?

Subnetting Berechnen Aufgaben

2026-04-21T11:43:36Z

Maximilian.pottgiesser: /* Aufgabe 3 */

=Aufgabe 1=
;Sie haben folgende IP Address vorgegeben 212.88.77.3/24
*Wie lautet die Netzbeginn?
*Wie lautet der Broadcast?
*Wieviele IP Addressen können real vergeben werden?

=Aufgabe 2=
;Sie haben folgende IP Address vorgegeben 12.6.139.3/16
*Wie lautet die Netzbeginn?
*Wie lautet der Broadcast?
*Wieviele IP Addressen können real vergeben werden?

=Aufgabe 3=
;Sie haben folgende IP Address vorgegeben 6.67.35.156/8
*Wie lautet die Netzbeginn?
*Wie lautet der Broadcast?
*Wieviele IP Addressen können real vergeben werden?

=Aufgabe 4=
;Sie haben folgende IP Address vorgegeben 76.68.145.16/12
*Wie lautet die Netzbeginn?
*Wie lautet der Broadcast?
*Wieviele IP Addressen können real vergeben werden?
=Aufgabe 5=
;Sie haben folgende IP Address vorgegeben 192.168.178.153/28
*Wie lautet die Netzbeginn?
*Wie lautet der Broadcast?
*Wieviele IP Addressen können real vergeben werden?
*[[Aufgabe 5 als Vorzeigebeispiel]]

=Aufgabe 6=
;Sie haben folgende IP Address vorgegeben 192.168.178.153/27
*Wie lautet die Netzbeginn?
*Wie lautet der Broadcast?
*Wieviele IP Addressen können real vergeben werden?
=Aufgabe 7=
;Sie haben folgende IP Address vorgegeben 6.67.29.156/22
*Wie lautet die Netzbeginn?
*Wie lautet der Broadcast?
*Wieviele IP Addressen können real vergeben werden?
=Aufgabe 8=
;Sie haben folgende IP Address vorgegeben 172.16.133.111/255.255.248.0
*Wie lautet die Netzbeginn?
*Wie lautet der Broadcast?
*Wieviele IP Addressen können real vergeben werden?
=Aufgabe 9=
;Sie haben folgende IP Address vorgegeben 10.176.133.111/255.128.0.0
*Wie lautet die Netzbeginn?
*Wie lautet der Broadcast?
*Wieviele IP Addressen können real vergeben werden?

Subnetting Berechnen Aufgaben

2026-04-21T11:41:51Z

Maximilian.pottgiesser: /* Aufgabe 2 */

=Aufgabe 1=
;Sie haben folgende IP Address vorgegeben 212.88.77.3/24
*Wie lautet die Netzbeginn?
*Wie lautet der Broadcast?
*Wieviele IP Addressen können real vergeben werden?

=Aufgabe 2=
;Sie haben folgende IP Address vorgegeben 12.6.139.3/16
*Wie lautet die Netzbeginn?
*Wie lautet der Broadcast?
*Wieviele IP Addressen können real vergeben werden?

=Aufgabe 3=
;Sie haben folgende IP Address vorgegeben 6.67.35.156/8
*Wie lautet die Netzbeginn?
*Wie lautet der Broadcast?
*Wieviele IP Addressen können real vergeben werden?
=Aufgabe 4=
;Sie haben folgende IP Address vorgegeben 76.68.145.16/12
*Wie lautet die Netzbeginn?
*Wie lautet der Broadcast?
*Wieviele IP Addressen können real vergeben werden?
=Aufgabe 5=
;Sie haben folgende IP Address vorgegeben 192.168.178.153/28
*Wie lautet die Netzbeginn?
*Wie lautet der Broadcast?
*Wieviele IP Addressen können real vergeben werden?
*[[Aufgabe 5 als Vorzeigebeispiel]]

=Aufgabe 6=
;Sie haben folgende IP Address vorgegeben 192.168.178.153/27
*Wie lautet die Netzbeginn?
*Wie lautet der Broadcast?
*Wieviele IP Addressen können real vergeben werden?
=Aufgabe 7=
;Sie haben folgende IP Address vorgegeben 6.67.29.156/22
*Wie lautet die Netzbeginn?
*Wie lautet der Broadcast?
*Wieviele IP Addressen können real vergeben werden?
=Aufgabe 8=
;Sie haben folgende IP Address vorgegeben 172.16.133.111/255.255.248.0
*Wie lautet die Netzbeginn?
*Wie lautet der Broadcast?
*Wieviele IP Addressen können real vergeben werden?
=Aufgabe 9=
;Sie haben folgende IP Address vorgegeben 10.176.133.111/255.128.0.0
*Wie lautet die Netzbeginn?
*Wie lautet der Broadcast?
*Wieviele IP Addressen können real vergeben werden?

Subnetting Berechnen Aufgaben

2026-04-21T11:37:14Z

Maximilian.pottgiesser: /* Aufgabe 1 */

=Aufgabe 1=
;Sie haben folgende IP Address vorgegeben 212.88.77.3/24
*Wie lautet die Netzbeginn?
*Wie lautet der Broadcast?
*Wieviele IP Addressen können real vergeben werden?

=Aufgabe 2=
;Sie haben folgende IP Address vorgegeben 12.6.139.3/16
*Wie lautet die Netzbeginn?
*Wie lautet der Broadcast?
*Wieviele IP Addressen können real vergeben werden?
=Aufgabe 3=
;Sie haben folgende IP Address vorgegeben 6.67.35.156/8
*Wie lautet die Netzbeginn?
*Wie lautet der Broadcast?
*Wieviele IP Addressen können real vergeben werden?
=Aufgabe 4=
;Sie haben folgende IP Address vorgegeben 76.68.145.16/12
*Wie lautet die Netzbeginn?
*Wie lautet der Broadcast?
*Wieviele IP Addressen können real vergeben werden?
=Aufgabe 5=
;Sie haben folgende IP Address vorgegeben 192.168.178.153/28
*Wie lautet die Netzbeginn?
*Wie lautet der Broadcast?
*Wieviele IP Addressen können real vergeben werden?
*[[Aufgabe 5 als Vorzeigebeispiel]]

=Aufgabe 6=
;Sie haben folgende IP Address vorgegeben 192.168.178.153/27
*Wie lautet die Netzbeginn?
*Wie lautet der Broadcast?
*Wieviele IP Addressen können real vergeben werden?
=Aufgabe 7=
;Sie haben folgende IP Address vorgegeben 6.67.29.156/22
*Wie lautet die Netzbeginn?
*Wie lautet der Broadcast?
*Wieviele IP Addressen können real vergeben werden?
=Aufgabe 8=
;Sie haben folgende IP Address vorgegeben 172.16.133.111/255.255.248.0
*Wie lautet die Netzbeginn?
*Wie lautet der Broadcast?
*Wieviele IP Addressen können real vergeben werden?
=Aufgabe 9=
;Sie haben folgende IP Address vorgegeben 10.176.133.111/255.128.0.0
*Wie lautet die Netzbeginn?
*Wie lautet der Broadcast?
*Wieviele IP Addressen können real vergeben werden?

Supernetting

2026-04-21T09:24:32Z

Maximilian.pottgiesser: /* Binär */

;Unter Supernetting versteht die Zusammenfassung von Netzen.

;Vorteile sind kürzere Routingeinträge, kürzere Accesslisten, klarere Strukturen.

Beispiel:

{|class="wikitable" style="text-align:center;
!colspan="32"| Netze
|-
|colspan="8" style="width:25%;" |193.158.232.0/24
|colspan="8" style="width:25%;" |193.158.233.0/24
|colspan="8" style="width:25%;" |193.158.234.0/24
|colspan="8" style="width:25%;" |193.158.235.0/24
|-
|colspan="16" style="width:50%;" |193.158.232.0/23
|colspan="16" style="width:25%;" |193.158.234.0/23
|-
|colspan="32" style="width:50%;" |193.158.232.0/22
|}

;Beim Zusammenfügen von Netzen gelten folgende Regeln (alle müssen eingehalten werden):

*Man legt zwei Netze zusammen in dem man an der Netzwerkmaske das am weitesten rechts stehende gesetzte Bit von 1 in 0 umwandelt.
*Das Netz mit der niedrigsten Netznummer muss die neue Netznummer stellen.
*Das Netz mit dem höchsten Broadcast muss den neuen Broadcast stellen.
*Die Netze müssen kontinuierlich (fortlaufend) sein. Es dürfen keine Lücken vorhanden sein. Sie müssen also nebeneinander liegen.

;Schlussfolgerung:

Man kann Netze zusammenfassen wenn, die Subnetzsmaske verringert wird und der Wert w (interessantes Oktett der Netznummer)
des niedrigsten Netzes durch die Anzahl der zusammenzulegenden Netze ohne Rest teilbar ist.

w = interessantes Oktett des niedrigsten Netzes

n = Anzahl der zusammenzulegenden Netze

Bedingung: <math>w\ mod\ n = 0 </math>

=Modulo Rechner=
*http://www.mathe24.net/modulo.html?action=do

Supernetting

2026-04-21T09:18:43Z

Maximilian.pottgiesser: /* Binär */

Supernetting

2026-04-21T09:18:32Z

Maximilian.pottgiesser:

UDP-Header-Aufbau, und TCP-Header-Aufbau

2026-04-21T05:59:52Z

Maximilian.pottgiesser:

*[[Udp | UDP-Header-Aufbau]]
*[[Tcp | TCP-Header-Aufbau]]
*[[Ports]]
*[[Sockets]]

ISO/OSI-Referenzmodell

2026-04-20T07:43:33Z

Maximilian.pottgiesser:

International Organization for Standardization / Open Systems Interconnection model

*[[ISO/OSI Referenzmodel Prinzip]]
*[[ISO/OSI Referenzmodel]]
*[[ISO/OSI Referenzmodel Devices]]
*[[TCP/IP Referenz Modell]]
*[[RFCs]]
*[[TCP/IP vs. ISO/OSI]]

ISO/OSI-Referenzmodell

2026-04-20T07:41:53Z

Maximilian.pottgiesser:

Schulungen

2026-04-20T05:37:30Z

Maximilian.pottgiesser:

</div>
<div style="margin-left: 20px;">
[[Datei:Rf.png|rechts|300px]]
</div>
</div>

=Aktuelle Schulungen=
* [[Linux - Netzwerk und Serveradminstration]]
* [[Linux - Security und Firewall]]
* [[Technik der Netze - Netzwerkdienste und Protokolle als Basis der Optimierung]]

=Schulungen=
* [[Linux - Netzwerk und Serveradminstration]]
* [[Virtualisierung Proxmox]]
* [[VMWare VSPhere]]
* [[IPv6 Training]]
* [[Linux - Security und Firewall]]
* [[Linux - Erweiterte Netzwerk- und Serveradministration für Fortgeschrittene]]
* [[Cyber Security II.]]
* [[Analyse und Monitoring von Netzwerken]]
* [[Cyber Security I.]]
* [[Kali Linux Grundlagen]]
* [[Kali Tools]]
* [[Linux Grundlagen - 3 Tage]]
* [[Linux - Einsatz in heterogenen Netzen]]
* [[Ubuntu Linux Administration]]
* [[Virtualisierung in Linux]]
* [[IT-Sicherheitsaspekte in heterogenen Netzwerken]]
* [[Cisco Routing & Switching Fundamentals]]
* [[Linux - Erweiterte Systemadministration für Fortgeschrittene]]
* [[Linux Infrastrukturdienste (INFS)]]
* [[VMWare VSPhere]]
* [[Linux - Erweiterte Systemadministration für Fortgeschrittene]]
* [[VoIP Grundlagen]]
* [[Technik der Netze - Grundlagen]]
* [[Vertiefung UNIX-/Linux Netzwerke]]
* [[Bash Programmierung]]
* [[Linux - Shell Programmierung (Bash)]]
* [[Informationssicherheit in Linux-Umgebungen]]
* [[Linux Härtung]]
* [[Linux Grundlagen]]
* [[Suse Linux Administration]]
* [[Grundlagenwissen für Administratoren]]
* [[Praxis Beispiel von Vulnhub]]
* [[Docker Kurs]]
* [[Grundlagen-Workshop Container-Virtualisierung]]
* [[Veeam]]
* [[VoIP]]
* [[LPIC Zertifizierung]]
* [[Live Hacks]]
* [[Windows Server ADS]]
* [[Cyber Angriffe Defense]]
* [[Red Team Pictures]]
* [[CIS Benchmarks]]
* [[IT 600 b - Linux/Unix]]
* [[Grundlegende Sicherheitsaspekte in IP-Netzen]]
* [[Moodle]]
* [[Rocky]]

=Infos=
* [[Vorträge]]
* [[Videos]]

=Misc=
*[[GNS3]]
*[[Putty Tools]]
*[[Was kann ich in einem Netzwerk entdecken?]]
*[[AuNvn Misc]]
*[[Hacking]]
*[[Aufgaben]]
*[[hacking cheat sheet]]
*[[Risikostufen für Schwachstellen]]
*[[filius-daten]]
*[[vSphere Client Zertifikat]]
*[[Linux Tools]]
*[[Tools for recon]]
*[[DSVGO]]
*[[Mimikatz]]
*[[Bankprojekt]]
*[[Dash-to-Dock Debian]]
*[[Debian Gnome Rechte Maustaste]]
*[[Fake Ports mit socat]]
*[[Golden Ticket]]
*[[Linux Grundlagen Rest]]
*[[PowerShell / HTA Payload Demonstration (Lab Only)]]
*[[Bitwarden]]

*[[Templates]]
=Gucken=
*https://github.com/kgretzky/evilginx2
*https://www.caine-live.net/
*https://cybersudo.org/downgrade-https-to-http--man-in-the-middle-attack/
*[[Bounty Hunters Tools]]
*https://github.com/carlospolop/PEASS-ng/tree/master/linPEAS
;rootkit finder
*https://github.com/fkie-cad/ryoshi
;rootkit
*https://github.com/shell-dot/tuoni
*https://github.com/MatheuZSecurity/Singularity

=Jeopardy=
*[[Jeopardy Regeln]]
*https://jeopardylabs.com/play/mailserver
*https://jeopardylabs.com/play/proxy-server
*https://jeopardylabs.com/play/apache2-tageskurs
*https://jeopardylabs.com/play/datenbanken-mariadb-php-apache2

Proxmox Upgrade 8 zu 9

2026-03-12T08:43:40Z

Maximilian.pottgiesser: /* HA Status prüfen */

==HA Status prüfen==
ha-manager status

ha-manager set <vmid> --state stopped

==Upgrade möglichkeiten prüfen==
pve8to9 --full

==Repositories anpassen==
sed -i 's/bookworm/trixie/g' /etc/apt/sources.list

sed -i 's/bookworm/trixie/g' /etc/apt/sources.list.d/*.list

ggf. /etc/apt/sources.list.d/ unötige Repos leeren

==Upgrade durchführen==

apt update

apt -o Dpkg::Options::="--force-confold" dist-upgrade

issues Y
chrony keep local
<pre>
Configuration file '/etc/chrony/chrony.conf'
==> Modified (by you or by a script) since installation.
==> Package distributor has shipped an updated version.
What would you like to do about it ? Your options are:
Y or I : install the package maintainer's version
N or O : keep your currently-installed version
D : show the differences between the versions
Z : start a shell to examine the situation
The default action is to keep your current version.
*** chrony.conf (Y/I/N/O/D/Z) [default=N] ?
</pre>
<pre>
Configuration file '/etc/lvm/lvm.conf'
==> Modified (by you or by a script) since installation.
==> Package distributor has shipped an updated version.
What would you like to do about it ? Your options are:
Y or I : install the package maintainer's version
N or O : keep your currently-installed version
D : show the differences between the versions
Z : start a shell to examine the situation
The default action is to keep your current version.
*** lvm.conf (Y/I/N/O/D/Z) [default=N] ?
</pre>
==Nach dem Upgrade==
reboot

pveversion

uname -r

pvecm status

Proxmox Upgrade 8 zu 9

2026-03-12T08:43:30Z

Maximilian.pottgiesser:

==HA Status prüfen==
ha-manager status
ha-manager set <vmid> --state stopped

==Upgrade möglichkeiten prüfen==
pve8to9 --full

==Repositories anpassen==
sed -i 's/bookworm/trixie/g' /etc/apt/sources.list

sed -i 's/bookworm/trixie/g' /etc/apt/sources.list.d/*.list

ggf. /etc/apt/sources.list.d/ unötige Repos leeren

==Upgrade durchführen==

apt update

apt -o Dpkg::Options::="--force-confold" dist-upgrade

issues Y
chrony keep local
<pre>
Configuration file '/etc/chrony/chrony.conf'
==> Modified (by you or by a script) since installation.
==> Package distributor has shipped an updated version.
What would you like to do about it ? Your options are:
Y or I : install the package maintainer's version
N or O : keep your currently-installed version
D : show the differences between the versions
Z : start a shell to examine the situation
The default action is to keep your current version.
*** chrony.conf (Y/I/N/O/D/Z) [default=N] ?
</pre>
<pre>
Configuration file '/etc/lvm/lvm.conf'
==> Modified (by you or by a script) since installation.
==> Package distributor has shipped an updated version.
What would you like to do about it ? Your options are:
Y or I : install the package maintainer's version
N or O : keep your currently-installed version
D : show the differences between the versions
Z : start a shell to examine the situation
The default action is to keep your current version.
*** lvm.conf (Y/I/N/O/D/Z) [default=N] ?
</pre>
==Nach dem Upgrade==
reboot

pveversion

uname -r

pvecm status

Proxmox Ceph

2026-03-09T06:11:48Z

Maximilian.pottgiesser: Die Seite wurde neu angelegt: „= Ceph in Proxmox VE = == Einleitung == Ceph ist ein verteiltes Storage-System, das in Proxmox VE nativ integriert ist. Es ermöglicht es, den lokalen Speich…“

= Ceph in Proxmox VE =

== Einleitung ==

Ceph ist ein verteiltes Storage-System, das in Proxmox VE nativ integriert ist. Es ermöglicht es, den lokalen Speicher mehrerer Nodes zu einem gemeinsamen, hochverfügbaren Storage-Pool zusammenzufassen – ohne externe SAN- oder NAS-Appliance.

Dieses Dokument richtet sich an Schulungsteilnehmer und erklärt Ceph von den Grundlagen bis zur praktischen Einrichtung in Proxmox.

== Das Problem: Warum Ceph? ==

In einem klassischen Proxmox-Cluster mit lokalem Speicher (z. B. ZFS auf jedem Node) gibt es ein grundlegendes Problem:

* Fällt ein Node aus, sind die darauf gespeicherten VM-Daten nicht verfügbar.
* Live-Migration von VMs zwischen Nodes erfordert gemeinsamen (''shared'') Speicher.
* Ein externes SAN oder NAS ist teuer und bildet einen ''Single Point of Failure''.

Ceph löst diese Probleme, indem es die Daten '''verteilt und repliziert''' über alle beteiligten Nodes speichert.

== Entstehungsgeschichte ==

{| class="wikitable"
|-
! Zeitraum !! Ereignis
|-
| 2004–2007 || Entwicklung als Forschungsprojekt an der '''University of California, Santa Cruz (UCSC)''' durch '''Sage Weil''' im Rahmen seiner Doktorarbeit. Finanziert u. a. durch das U.S. Department of Energy und Lawrence Livermore National Laboratory.
|-
| 2006 || Erste Veröffentlichung als '''Open Source'''.
|-
| 2007 || Veröffentlichung der Dissertation: ''"Ceph: Reliable, Scalable, and High-Performance Distributed Storage"''
|-
| 2010 || Aufnahme des Ceph-Clients in den '''Linux Mainline-Kernel'''.
|-
| 2012 || Sage Weil gründet die Firma '''Inktank''' für kommerziellen Enterprise-Support.
|-
| 2014 || '''Red Hat übernimmt Inktank''' für ca. 175 Mio. USD. Ceph wird zum zentralen Baustein der Red Hat Storage-Strategie.
|-
| Heute || Aktive Community-Entwicklung unter der LGPL. Releases werden alphabetisch benannt (Luminous, Nautilus, Octopus, Quincy, Reef, Squid …). Beiträge von Red Hat, Canonical, SUSE u. v. m.
|}

Die Kernidee von Sage Weil war, ein verteiltes Dateisystem zu bauen, das '''ohne zentrale Metadaten-Server''' auskommt und stattdessen den '''CRUSH-Algorithmus''' nutzt, um die Datenverteilung rein rechnerisch zu bestimmen.

== Analogie: Die verteilte Bibliothek ==

Ceph lässt sich gut mit einer verteilten Bibliothek vergleichen:

Stell dir vor, du hast '''drei Bibliotheken''' (Nodes) in einer Stadt. Statt jedes Buch nur in einer Bibliothek zu lagern, wird jedes Buch in '''Kopien (Replikate)''' auf mindestens zwei Bibliotheken verteilt. Wenn eine Bibliothek abbrennt, sind alle Bücher noch in den anderen verfügbar.

* Die '''Bibliothekare''' entsprechen den OSDs – sie verwalten die Bücher.
* Der '''zentrale Katalog''' entspricht den MONs – er weiß, welches Buch wo liegt.
* Die '''Verwaltung''' entspricht dem MGR – sie sammelt Statistiken und bietet Übersicht.

== Kernkomponenten ==

=== MON (Monitor) ===

Der ''Buchhalter'' des Clusters. MONs kennen den Zustand des gesamten Clusters und verwalten die ''Cluster Map''.

* Es wird immer eine '''ungerade Anzahl''' benötigt (1, 3, 5) wegen des Quorum-Prinzips.
* In Proxmox läuft typischerweise ein MON auf jedem Node.
* MONs speichern '''keine Nutzdaten''', sondern nur Metadaten über den Cluster-Zustand.

=== OSD (Object Storage Daemon) ===

Die eigentlichen ''Arbeiter'' im Cluster. Jede physische Disk bekommt einen eigenen OSD.

* OSDs speichern die Daten, replizieren untereinander und melden ihren Zustand an die MONs.
* Die Anzahl der OSDs bestimmt die Gesamtkapazität und Performance des Clusters.
* Fällt ein OSD aus, übernehmen die verbleibenden OSDs automatisch die Wiederherstellung (''Recovery'').

=== MGR (Manager) ===

Das ''Dashboard'' des Clusters. Manager sammeln Metriken und bieten Web-GUI sowie Monitoring-Schnittstellen.

* Läuft in der Regel auf denselben Nodes wie die MONs.
* Stellt das Ceph-Dashboard in der Proxmox-Oberfläche bereit.

=== Zusammenfassung der Rollen ===

{| class="wikitable"
|-
! Komponente !! Rolle !! Anzahl (Empfehlung)
|-
| MON || Cluster-Zustand & Quorum || 3 (ungerade Anzahl)
|-
| OSD || Datenspeicherung & Replikation || 1 pro physischer Disk
|-
| MGR || Monitoring & Dashboard || 1–2 pro Cluster
|}

== CRUSH-Map und Placement Groups ==

=== CRUSH-Algorithmus ===

CRUSH ('''C'''ontrolled '''R'''eplication '''U'''nder '''S'''calable '''H'''ashing) ist das Herzstück von Ceph. Er bestimmt '''rein rechnerisch''', wo Daten gespeichert werden – ohne zentrale Lookup-Tabelle.

Die '''CRUSH-Map''' ist ein Regelwerk, das sicherstellt:
* Replikate landen '''nie auf demselben Node'''.
* Die Verteilung berücksichtigt die physische Topologie (Racks, Nodes, Disks).
* Neue OSDs werden automatisch in die Verteilung aufgenommen.

=== Placement Groups (PGs) ===

Placement Groups sind eine '''Zwischenschicht''' zwischen den Objekten und den OSDs.

Anstatt jedes einzelne Objekt individuell einem OSD zuzuordnen, werden Objekte in PGs gruppiert. Man kann sich PGs wie '''Postleitzahlen''' vorstellen: Statt jede Adresse einzeln zu routen, wird nach Postleitzahl sortiert.

* Die Anzahl der PGs beeinflusst die Verteilungsgenauigkeit.
* Proxmox berechnet automatisch sinnvolle PG-Werte.

== Pools und Proxmox-Integration ==

=== Was ist ein Pool? ===

Ein '''Pool''' ist ein logischer Speicherbereich in Ceph mit eigenen Regeln für:
* '''Replikationsfaktor''' (z. B. size=3, min_size=2)
* '''Placement Groups'''
* '''CRUSH-Regeln''' (auf welchen OSDs darf gespeichert werden?)

=== Einrichtung in Proxmox (Überblick) ===

# Ceph auf allen Nodes installieren (über die Proxmox-GUI unter ''Ceph'')
# '''MONs erstellen''' auf jedem Node
# '''OSDs erstellen''' – physische Disks zuweisen
# '''Pool anlegen''' mit gewünschtem Replikationsfaktor
# Pool als '''Proxmox-Storage''' einbinden (RBD)

Danach steht der Ceph-Pool als Storage für VMs und Container zur Verfügung. Live-Migration funktioniert sofort, da alle Nodes auf denselben Daten arbeiten.

== Wichtige Praxishinweise ==

=== Mindestanforderungen ===

{| class="wikitable"
|-
! Kriterium !! Empfehlung
|-
| Anzahl Nodes || Mindestens '''3''' (Quorum)
|-
| Netzwerk || Dediziertes Ceph-Netzwerk, mindestens '''10 GbE''' (eigenes VLAN empfohlen)
|-
| Disks || SSDs für Performance-Pools, HDDs für Kapazitäts-Pools
|-
| RAM || Richtwert: ca. 1–2 GB RAM pro OSD
|}

=== Replikationsfaktor und nutzbarer Speicher ===

Der Standard-Replikationsfaktor ist '''size=3, min_size=2'''. Das bedeutet:
* Jedes Objekt wird auf '''3 OSDs''' gespeichert.
* Bei Ausfall eines OSDs sind noch '''2 Kopien''' verfügbar (Cluster bleibt voll funktional).
* '''Nutzbarer Speicher''' = ca. '''⅓ der Rohkapazität'''.

''Beispiel:'' 3 Nodes mit je 1 TB = 3 TB roh → ca. '''1 TB nutzbar'''.

=== Typische Stolpersteine ===

* '''Recovery Storms:''' Wenn ein ausgefallener OSD zurückkehrt, beginnt eine Resynchronisation, die erhebliche I/O-Last erzeugen kann.
* '''Netzwerk-Bandbreite:''' Ceph ist netzwerkintensiv. Ohne dediziertes Netzwerk leidet die Performance aller Dienste.
* '''Falsche PG-Anzahl:''' Zu wenige PGs → ungleichmäßige Verteilung. Zu viele PGs → unnötiger Overhead.
* '''Gemischte Disk-Typen:''' SSDs und HDDs im selben Pool führen zu inkonsistenter Performance. Separate Pools verwenden.

== Abgrenzung zu Alternativen ==

{| class="wikitable"
|-
! Lösung !! Vorteile !! Nachteile
|-
| '''Ceph (nativ in Proxmox)''' || Nativ integriert, horizontal skalierbar, kein SPOF, kein externes Storage nötig || Mindestens 3 Nodes, Netzwerk-intensiv, Komplexität
|-
| '''ZFS-Replikation''' || Einfach einzurichten, gute Performance || Kein echtes Shared Storage, manuelles Failover
|-
| '''NFS/iSCSI (extern)''' || Bekannt, einfach || Externer Server = SPOF, zusätzliche Hardware nötig
|-
| '''GlusterFS''' || Einfacher als Ceph || Nicht nativ in Proxmox, weniger verbreitet
|}

== Live-Demo: Hochverfügbarkeit testen ==

Der effektivste Weg, Ceph zu verstehen, ist eine '''Live-Demo''':

# VM auf dem Ceph-Pool erstellen und starten.
# Einen Node '''herunterfahren''' (auf dem die VM ursprünglich lief).
# Beobachten, wie die VM auf einem anderen Node '''automatisch weiterläuft'''.
# Ceph-Status prüfen: <code>ceph status</code> zeigt den degradierten Zustand.
# Node wieder hochfahren und die '''automatische Recovery''' beobachten.

Dieser ''"Wow-Moment"'' verdeutlicht den Mehrwert von Ceph besser als jede Theorie.

== Nützliche Befehle ==

{| class="wikitable"
|-
! Befehl !! Beschreibung
|-
| <code>ceph status</code> || Gesamtstatus des Clusters (Health, OSDs, PGs)
|-
| <code>ceph osd tree</code> || Baumansicht aller OSDs und ihrer Zuordnung zu Nodes
|-
| <code>ceph df</code> || Speicherverbrauch pro Pool und gesamt
|-
| <code>ceph osd pool ls detail</code> || Detaillierte Pool-Informationen
|-
| <code>ceph health detail</code> || Detaillierte Gesundheitsinformationen bei Warnungen
|-
| <code>rados bench</code> || Einfacher Performance-Benchmark
|}

== Zusammenfassung ==

{{Hinweis|'''Merkregel:''' Ceph verteilt Daten über mehrere Nodes, sodass kein einzelner Ausfall zum Datenverlust führt – und Proxmox kann das out of the box.}}

== Quellen und weiterführende Links ==

* [https://docs.ceph.com/ Offizielle Ceph-Dokumentation]
* [https://pve.proxmox.com/wiki/Deploy_Hyper-Converged_Ceph_Cluster Proxmox Wiki: Deploy Hyper-Converged Ceph Cluster]
* [https://pve.proxmox.com/pve-docs/chapter-pveceph.html Proxmox VE Ceph-Dokumentation]

Virtualisierung Proxmox

2026-03-09T06:11:39Z

Maximilian.pottgiesser: /* Unterichte */

==Unterichte==
* [[Unterschied LXC zu VM]]
* [[Proxmox Cluster]]
* [[Proxmox Speicher]]
* [[Proxmox Ceph]]

==Umgebung==
* [[IP Addressen Clients(Eins)]]

==Aufgaben==
* [[Win 11 Installation]]
* [[Proxmox Rechteverwaltung Zusatzaufgaben]]
* [[Hyper -V Zusatzaufgabe]]
* [[Qemu Guest Tools Debian 13]]
* [[Proxmox Snapshots Zusatzaufgaben]]
* [[Proxmox Upgrade 8 zu 9]]

==Troubleshooting==
* [[VM reagiert nicht]]
* [[Speicher wird nicht freigegeben]]
* [[Proxmox Cluster Troubleshooting]]

==PrüfungsVorbereitung==
* [[Proxmox Routineanweisungen]]
* [[Proxmox Übungsprüfung]]

Proxmox Speicher

2026-03-04T07:12:19Z

Maximilian.pottgiesser: Die Seite wurde neu angelegt: „= Speicher – Ergänzungen und Vertiefungen = == Blockspeicher vs. Dateispeicher == === Analogie === Stell dir den Hypervisor als '''Lagerverwalter''' vor.…“

= Speicher – Ergänzungen und Vertiefungen =

== Blockspeicher vs. Dateispeicher ==

=== Analogie ===

Stell dir den Hypervisor als '''Lagerverwalter''' vor.

Beim '''Blockspeicher''' (z.B. LVM, iSCSI, Ceph RBD) bekommt der Lagerverwalter einen leeren Bereich, der in nummerierte, gleich große Fächer aufgeteilt ist. Er kann dort VM-Festplatten als große zusammenhängende Blöcke ablegen — aber er kann nicht reinschauen, was drin ist. Er sieht nur "Block 47 bis 520 gehört zu VM-Disk disk-0 von VM 101". Was die VM intern damit macht (ext4 formatieren, Dateien anlegen), ist für den Hypervisor unsichtbar.

Beim '''Dateispeicher''' (z.B. Directory, NFS, CephFS) hat der Lagerverwalter ein fertiges Regalsystem mit Ordnern. Er sieht die VM-Disks als einzelne Dateien liegen — zum Beispiel <code>vm-101-disk-0.qcow2</code> im Ordner <code>images/101/</code>. Er kann die Datei kopieren, verschieben, umbenennen oder sichern, ohne die VM dafür fragen zu müssen. Genau deshalb eignet sich Dateispeicher gut für Backups und ISO-Images.

'''Kernunterschied aus Hypervisor-Sicht:''' Kann der Hypervisor die VM-Disks als Dateien sehen und anfassen, oder sind es nur Blockbereiche, die er als Ganzes verwaltet?

=== Dateisystem auf Blockspeicher? ===

Ein häufiges Missverständnis: Der Hypervisor legt bei echtem Blockspeicher '''kein''' Dateisystem drauf. Er nutzt stattdessen einen '''Volume Manager''' (LVM, Ceph RBD, ZFS Zvols), der die Zuordnung von Blöcken zu VMs übernimmt — das ist eine andere Abstraktionsschicht als ein Dateisystem.

* '''LVM/LVM-Thin:''' Verwaltet logische Volumes direkt als Blockgeräte. Die VM bekommt <code>/dev/dm-X</code> zugewiesen — ein rohes Blockgerät. Da liegt keine Datei <code>vm-101-disk-0.qcow2</code> in einem Ordner. Die Zuordnung läuft über LVM-Metadaten, nicht über ein Dateisystem.
* '''iSCSI:''' Der Hypervisor bekommt ein Blockgerät übers Netzwerk und reicht es direkt an die VM durch. Kein Dateisystem auf Hypervisor-Ebene.
* '''ZFS:''' Sonderfall, da ZFS beides gleichzeitig ist:
** '''ZFS Dataset''' → Dateispeicher, qcow2-Dateien liegen darin
** '''ZFS Zvol''' → Rohes Blockgerät, kein Dateisystem dazwischen

== Copy-on-Write (CoW) ==

=== Grundprinzip ===

Bei einem klassischen Dateisystem wie ext4 wird ein Block direkt überschrieben, wenn eine Datei geändert wird — der alte Inhalt ist danach weg. Bei ZFS passiert das nie:

# ZFS schreibt die neuen Daten in einen '''freien Block'''
# Der Zeiger im Metadaten-Baum wird aktualisiert
# Erst danach wird der alte Block als frei markiert

Der ursprüngliche Block wird also '''nie''' direkt überschrieben.

=== Konsistenz ohne Journal ===

Bei ext4 braucht man ein Journal, das Schreibvorgänge protokolliert, damit nach einem Stromausfall das Dateisystem repariert werden kann. ZFS braucht das nicht — weil der alte Zustand immer intakt bleibt, bis der neue vollständig geschrieben ist.

* Entweder der neue Zeiger wurde aktualisiert → neue Daten gelten
* Oder nicht → alte Daten gelten (intakt)

Es gibt keinen Zwischenzustand, in dem das Dateisystem inkonsistent sein könnte. Deshalb gibt es bei ZFS auch kein <code>fsck</code>.

=== Snapshots durch CoW ===

Wenn ZFS einen Snapshot erstellt, muss es '''keine Daten kopieren'''. Es merkt sich einfach: "Die Blöcke, die jetzt existieren, bitte nicht freigeben." Da CoW sowieso nie alte Blöcke überschreibt, bleiben die Snapshot-Blöcke erhalten, während neue Änderungen in neue Blöcke geschrieben werden.

* Ein Snapshot kostet initial '''null''' zusätzlichen Speicher
* Er wächst nur, wenn sich Daten ändern (alte Blöcke werden aufbewahrt statt freigegeben)

=== Metadaten-Baum (Merkle Tree) ===

ZFS organisiert alle Daten in einer Baumstruktur:

* Jeder Block hat eine Prüfsumme, die im '''übergeordneten''' Block gespeichert wird (nicht im Block selbst)
* Wenn sich ein Block ändert, muss CoW auch den Eltern-Block neu schreiben (Prüfsumme ändert sich), und dessen Eltern, bis hoch zum '''Überblock''' (uberblock) an der Wurzel
* Dadurch kann ZFS Korruption auf jeder Ebene erkennen

=== Auswirkungen in der Praxis ===

* '''Fragmentierung:''' Weil Blöcke nie an der gleichen Stelle überschrieben werden, fragmentiert der Speicher über die Zeit. Bei HDDs spürbar, bei SSDs weniger relevant.
* '''Schreib-Amplifikation:''' Durch das Neu-Schreiben des ganzen Pfads im Baum entsteht bei kleinen Änderungen mehr I/O als bei einem klassischen Dateisystem. Das ist der Preis für Konsistenz und Integrität.

=== Analogie für den Unterricht ===

Stell dir ein '''Notizbuch''' vor. Ein klassisches Dateisystem radiert eine Zeile aus und schreibt neu drüber — wenn dabei der Strom ausfällt, ist die Zeile halb radiert und unleserlich.

ZFS schreibt die neue Version auf eine '''frische Seite''' und ändert erst dann das Inhaltsverzeichnis. Fällt der Strom aus, steht im Inhaltsverzeichnis entweder noch die alte Seite (intakt) oder schon die neue (auch intakt).

Und ein Snapshot? Das ist einfach die Anweisung: "'''Diese Seite nicht rausreißen''', auch wenn wir eine neue Version haben."

== Disk-Formate: Raw vs. qcow2 ==

=== Raw ===

Ein 1:1-Abbild der virtuellen Festplatte. Wenn einer VM 50 GB zugewiesen werden, wird (bei Thick Provisioning) eine 50-GB-Datei oder ein 50-GB-Logical-Volume angelegt.

* Keine Struktur drumherum, keine Metadaten, kein Header — einfach nur rohe Blöcke
* Kommt bei Blockspeicher (LVM, Zvols, iSCSI) zum Einsatz, da Blockspeicher kein Dateiformat braucht
* '''Maximale Performance''' durch direkten Zugriff ohne Indirektion

=== qcow2 (QEMU Copy-on-Write, Version 2) ===

Ein intelligentes Container-Format mit Header, Metadaten und Zuordnungstabelle.

'''Vorteile gegenüber Raw:'''

* '''Thin Provisioning auf Dateiebene:''' Eine 50-GB-Disk belegt anfangs nur wenige MB und wächst mit den tatsächlich geschriebenen Daten
* '''Snapshots innerhalb der Datei:''' qcow2 kann intern mehrere Zustände halten. Bei einem Snapshot wird (ähnlich wie bei ZFS CoW) in einen neuen Bereich geschrieben, der alte bleibt erhalten
* '''Backing Files:''' Eine Basis-Datei (z.B. ein sauberes Debian-Image) kann als Grundlage dienen, davon abgeleitete qcow2-Disks speichern nur die Unterschiede (Linked Clones)

'''Nachteil:''' Kleiner Performance-Overhead durch die Zuordnungstabelle — jeder I/O muss erst aufgelöst werden.

=== Zusammenhang mit der Speicherart ===

{| class="wikitable"
|-
! Speicherart !! Format !! Thin Provisioning durch
|-
| LVM-Thin || Raw || LVM selbst
|-
| ZFS Zvol || Raw || ZFS selbst
|-
| iSCSI || Raw || Storage-Backend
|-
| Directory || qcow2 || qcow2-Format
|-
| NFS || qcow2 || qcow2-Format
|-
| ZFS Dataset || qcow2 || qcow2-Format
|}

Die Wahl des Disk-Formats hängt direkt mit der Speicherart zusammen: Bei Blockspeicher übernimmt der Volume Manager das Thin Provisioning, deshalb wird Raw genutzt. Bei Dateispeicher muss das Format selbst Thin Provisioning mitbringen, deshalb qcow2.

Virtualisierung Proxmox

2026-03-04T07:12:10Z

Maximilian.pottgiesser: /* Unterichte */

==Unterichte==
* [[Unterschied LXC zu VM]]
* [[Proxmox Cluster]]
* [[Proxmox Speicher]]

==Umgebung==
* [[IP Addressen Clients(Eins)]]

==Aufgaben==
* [[Win 11 Installation]]
* [[Proxmox Rechteverwaltung Zusatzaufgaben]]
* [[Hyper -V Zusatzaufgabe]]
* [[Qemu Guest Tools Debian 13]]
* [[Proxmox Snapshots Zusatzaufgaben]]
* [[Proxmox Upgrade 8 zu 9]]

==Troubleshooting==
* [[VM reagiert nicht]]
* [[Speicher wird nicht freigegeben]]
* [[Proxmox Cluster Troubleshooting]]

==PrüfungsVorbereitung==
* [[Proxmox Routineanweisungen]]
* [[Proxmox Übungsprüfung]]

Suricata IDS am Switch Ubuntu

2026-02-27T07:58:02Z

Maximilian.pottgiesser:

=Idee=
;Managment Schnittstelle
enp0s3
;SniffingSchnittstelle
enp0s8
=Netzwerk=
*sudo vim /etc/netplan/50-cloud-init.yaml
<pre>
network:
version: 2
ethernets:
enp0s3:
addresses:
- "172.26.54.25/24"
nameservers:
addresses:
- 1.1.1.1
search:
- sec-labs.de
routes:
- to: "default"
via: "172.26.54.1"
enp0s8:
optional: true
addresses: []
dhcp4: false
dhcp6: false
</pre>

==Promiscuous Mode==
<pre>
cat <<'EOF' | sudo tee /etc/systemd/system/suricata-nic.service
[Unit]
Description=Configure enp0s8 for Suricata sniffing
After=network-online.target
Wants=network-online.target

[Service]
Type=oneshot
ExecStart=/sbin/ip link set enp0s8 promisc on
ExecStart=/sbin/ethtool -K enp0s8 gro off lro off tso off gso off
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target
EOF
</pre>

*sudo systemctl daemon-reload
*sudo systemctl enable --now suricata-nic.service

prüfen
*ethtool -k enp0s8 | grep -E "generic-receive|tcp-segmentation|generic-segmentation"
*ip link show enp0s8 | grep -i promisc

=Suricata Konfiguration=
*cat /etc/suricata/suricata.yaml
<pre>
*cat /etc/resolv.conf
search sec-labs.de
nameserver 1.1.1.1
*cat /etc/hostname
ids.sec-labs.de

%YAML 1.1
---
# Variablen für die Adressgruppen festlegen
vars:
address-groups:
LAN: "[172.26.53.0/24]"
DMZ: "[10.0.10.0/24]"
SERVER: "[172.26.54.0/24]"
INT: "[$LAN,$DMZ,$SERVER]"
HOME_NET: "$INT"
EXTERNAL_NET: "!$INT"

# Standard-Log-Verzeichnis
default-log-dir: /var/log/suricata/

# Statistiken aktivieren
stats:
enabled: yes
interval: 8

# Ausgaben konfigurieren
outputs:
- fast:
enabled: yes
filename: fast.log
append: yes
- alert-debug:
enabled: yes
filename: alert-debug.log
append: yes
- stats:
enabled: yes
filename: stats.log
append: yes
totals: yes
threads: no
- eve-log:
enabled: yes
filename: eve.json
types:
- alert
- dns
- http
- tls
- flow
- ssh
- stats

# Logging-Einstellungen
logging:
default-log-level: notice
outputs:
- console:
enabled: yes
- file:
enabled: yes
level: info
filename: suricata.log

# Netzwerkschnittstellen konfigurieren
af-packet:
- interface: enp0s8
threads: auto
cluster-id: 98
cluster-type: cluster_flow
defrag: yes

# PID-Datei
pid-file: /var/run/suricata.pid

# Coredump-Einstellungen
coredump:
max-dump: unlimited

# Host-Modus
host-mode: auto

# Unix-Befehlseingabe konfigurieren
unix-command:
enabled: yes
filename: /var/run/suricata-command.socket

# Engine-Analyse-Einstellungen
engine-analysis:
rules-fast-pattern: yes
rules: yes

# Defragmentierungseinstellungen
defrag:
memcap: 32mb
hash-size: 65536
trackers: 65535
max-frags: 65535
prealloc: yes
timeout: 60

# Standardregelverzeichnis
default-rule-path: /etc/suricata/rules

# Regel-Dateien
rule-files:
- local.rules

# Klassifikationsdatei
classification-file: /etc/suricata/classification.config

# Referenzkonfigurationsdatei
reference-config-file: /etc/suricata/reference.config
</pre>
=Eigene Regeln=
*cat /etc/suricata/rules/local.rules
<pre>
# ICMP: einfacher Ping/Traceroute (schneller Funktionstest)
# Test: ping -c1 <ZIEL>
alert icmp any any -> any any (msg:"ICMP Test"; classtype:misc-activity; sid:41;)

# HTTP: mögliches Command-Injection-Merkmal (Semikolon) in POST-Body
# Test: curl -X POST http://<ZIEL>/ -d "q=test%3Bls"
alert http any any -> any any (msg:"Command Injection - Semicolon in POST DATA"; classtype:web-application-attack; flow:established; content:"%3B"; nocase; http_client_body; sid:2;)

# HTTP: mögliches SQLi-Merkmal (einfaches Hochkomma) in POST-Body
# Test: curl -X POST http://<ZIEL>/login -d "u=a&p='%20OR%201=1"
alert http any any -> any any (msg:"Possible SQL Injection (singlequote in POST)"; classtype:web-application-attack; flow:established,to_server; content:"%27"; nocase; http_client_body; sid:3;)

# DNS: Policy – verbietet "google" in DNS-Queries
# Test: dig google.com @<FW>
alert dns any any -> any any (msg:"Kein Googlen"; dns.query; content:"google"; nocase; classtype:policy-violation; sid:43;)

# DoS: viele identische kurze HTTP-GETs (LOIC-ähnlich)
# Test: ab -n 1000 -c 500 http://<ZIEL>/
alert tcp any any -> any any (msg:"ET DOS Terse HTTP GET Likely LOIC"; flow:to_server,established; dsize:18; content:"GET / HTTP/1.1|0d 0a 0d 0a|"; depth:18; threshold:type both,track by_dst,count 500,seconds 60; classtype:own-dos; sid:54; rev:2; metadata:created_at 2014_10_03, confidence Medium, signature_severity Major, updated_at 2019_07_26;)

# Scan: TCP SYN-Sweep (viele SYN in kurzer Zeit)
# Test: nmap -sS -p1-100 <ZIEL>
alert tcp $EXTERNAL_NET any -> $HOME_NET any (msg:"OWN SCAN TCP SYN sweep"; flow:stateless,to_server; flags:S; detection_filter:track by_src,count 20,seconds 5; classtype:attempted-recon; sid:60; rev:1;)

# Scan: TCP NULL-Scan (keine Flags gesetzt)
# Test: nmap -sN -p1-100 <ZIEL>
alert tcp $EXTERNAL_NET any -> $HOME_NET any (msg:"OWN SCAN TCP NULL scan"; flow:stateless,to_server; flags:0; detection_filter:track by_src,count 5,seconds 10; classtype:attempted-recon; sid:61; rev:1;)

# Scan: TCP FIN-Scan (nur FIN)
# Test: nmap -sF -p1-100 <ZIEL>
alert tcp $EXTERNAL_NET any -> $HOME_NET any (msg:"OWN SCAN TCP FIN scan"; flow:stateless,to_server; flags:F; detection_filter:track by_src,count 5,seconds 10; classtype:attempted-recon; sid:62; rev:1;)

# Scan: TCP XMAS-Scan (FIN+PSH+URG)
# Test: nmap -sX -p1-100 <ZIEL>
alert tcp $EXTERNAL_NET any -> $HOME_NET any (msg:"OWN SCAN TCP XMAS scan"; flow:stateless,to_server; flags:FPU; detection_filter:track by_src,count 5,seconds 10; classtype:attempted-recon; sid:63; rev:1;)

# Scan: UDP-Sweep mit leerer Payload
# Test: nmap -sU --min-rate=1000 <ZIEL>
alert udp $EXTERNAL_NET any -> $HOME_NET 1:65535 (msg:"OWN SCAN UDP sweep (empty probes)"; flow:to_server; dsize:0; detection_filter:track by_src,count 15,seconds 10; classtype:attempted-recon; sid:64; rev:1;)

# Scan: ICMP Ping-Sweep (viele Echo-Requests)
# Test: nmap -sn <NETZ>/24
alert icmp $EXTERNAL_NET any -> $HOME_NET any (msg:"OWN SCAN ICMP ping sweep"; itype:8; detection_filter:track by_src,count 10,seconds 5; classtype:attempted-recon; sid:65; rev:1;)
# --- ICMP Flood / Ping Flood (klassischer DDos) ---
alert icmp any any -> $HOME_NET any (msg:"ICMP Flood Potential Detected"; threshold: type both, track by_dst, count 100, seconds 10; sid:1000001; rev:1;)

# --- UDP Flood ---
alert udp any any -> $HOME_NET any (msg:"UDP Flood Potential Detected"; threshold: type both, track by_dst, count 200, seconds 5; sid:1000002; rev:1;)

# --- TCP SYN Flood (Sehr häufiger DDos-Typ) ---
alert tcp any any -> $HOME_NET any (flags:S; msg:"TCP SYN Flood Potential Detected"; threshold: type both, track by_dst, count 150, seconds 10; sid:1000003; rev:1;)

# --- HTTP Flood (Layer 7 Attacke) ---
alert http any any -> $HOME_NET any (msg:"HTTP Flood Potential Detected"; threshold: type both, track by_dst, count 300, seconds 10; sid:1000004; rev:1;)

# --- DNS Amplification / große DNS Antworten ---
alert udp any 53 -> $HOME_NET any (msg:"Possible DNS Amplification Attack"; dnsize: > 512; threshold: type both, track by_src, count 50, seconds 5; sid:1000005; rev:1;)

# --- (Optional) Einfacher "Hello World" Treffer für Tests ---
alert tcp any any -> $HOME_NET any (msg:"TEST - SSH Connection Attempt"; content:"SSH"; nocase; sid:1000006; rev:1;)
</pre>
=Starten=
*systemctl enable suricata --now

=wazuh=
*vim /var/ossec/etc/ossec.conf
<pre>
<ossec_config>
<localfile>
<log_format>json</log_format>
<location>/var/log/suricata/eve.json</location>
</localfile>
</ossec_config>
</pre>
*systemctl restart wazuh-agent

Suricata IDS am Switch Ubuntu

2026-02-27T07:48:32Z

Maximilian.pottgiesser: Die Seite wurde neu angelegt: „=Idee= ;Managment Schnittstelle enp0s3 ;SniffingSchnittstelle enp0s8 =Netzwerk= *sudo vim /etc/netplan/50-cloud-init.yaml <pre> network: version: 2 etherne…“

Suricate IDS mit Evebox

2026-02-27T07:43:01Z

Maximilian.pottgiesser:

*[[Suricata Installation]]
*[[Suricata IDS am Switch]]
*[[Suricata IDS am Switch Ubuntu]]
*[[EveBox]]

Wireshark 8421

2026-02-26T12:29:04Z

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

= Wireshark Praxis – Cybersecurity Training =

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

Wireshark 8421

2026-02-26T10:32:02Z

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

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

Cyber Security II.

2026-02-26T10:31:57Z

Maximilian.pottgiesser: /* Todo */

=Grundlegendes=

[[Datei:Cyber-security-2-1.png|500px]]
*[[Thomas Will]]
*[[Zeiten KO]]
*[[Zeiten DD]]
*[[Cyber Security II. - Was wollen wir praktisch tun]]
*[[Cyber Security II. Netzplan]]
*[[Cyber Security II. Punkte]]

=Todo=
*[[Internet der Dinge (IoT)]]
*[[MQTT]]
*[[Industrie 4.0 (Sicherheit vernetzter Systeme)]]
*[[Einheitliche Kommunikation (plattformbasierte Bündelung von Apps, Effizienz)]]
*[[Cloud-Sicherheit]]
*[[Cyber-Risiken (Phishing, Ransomeware)]]
*[[Spionage, Sabotage, Missbrauch]]
*[[Massen- vs. Speerangriffe]]
*[[Fortgeschrittenen persistente Bedrohungen (APT)]]
*[[Informationssicherheits-Managementsysteme (ISMS)]]
*[[Sicherheitsinformations- und Ereignisverwaltung (SIEM) vorstellen, erklären und demonstrieren]]
*[[Team zur Reaktion auf Computersicherheitsvorfälle]]
*[[Cybersicherheits-/Schwachstellenbewertung]]
*[[Vulnerability Scanner Ablauf]]
*[[Penetrationstests unter Linux]]
*[[Firewalls der nächsten Generation]]
**[[WAF]]
*[[Angriff mit hydra und Abwehr mit Crowdsec]]
*[[Erkennung und Verhinderung von Eindringlingen]]
*[[Identitätsbasierter Zugriff und Profilerstellung]]
*[[Übungen zu Szenarien in einer für die Teilnehmenden bereitgestellten Lehrumgebung]]
*[[Sicherheitsbewusstsein vertiefen und Haltungsbewertung]]
*[[Kali Purple Home]]
*[[Wenn ein Angreiffer in ihrem Netz ist]]
*[[Verantwortung]]
*[[Wireshark 8421]]

=Links=
;Cyber Bedrohung am Beispiel des Ukraine Krieg
*https://www.youtube.com/watch?v=Yjogm9ejcPQ
;Mobile Verification Toolkit
*https://docs.mvt.re/en/latest/
;Patchen von Androidgeräten
*https://opensource.srlabs.de/projects/snoopsnitch
;Wlan Router
*https://www.gl-inet.com/products/gl-e750/
;Wireless Geographic Logging Engine
*https://www.wigle.net/
;Surveillance under Surveillance
*https://sunders.uber.space/
;Feldjäger testen VIRTUAL REALITY für Häuserkampf
*https://www.youtube.com/watch?v=m3JOjHmaBSA
;Firehol
*https://firehol.org/
;ADHD Tools Usage Document
*https://adhdproject.github.io/#!index.md
=Crowdsec=
*https://www.crowdsec.net/
*[[Crowdsec]]
=IDS mit Evebox=
*[[Suricate IDS mit Evebox]]