Slack

Einleitung Viele Anwendungen und Appliances können Logs ausschließlich per Syslog oder HTTP ausliefern. In Wazuh-Umgebungen stellt sich daher regelmäßig die Frage, wie solche Daten zuverlässig, strukturiert und regelbasiert ausgewertet werden können. Obwohl Wazuh einen nativen Syslog-Empfang bietet, zeigen Community-Diskussionen und Best Practices, dass der Weg über dateibasierte Logsammlung häufig stabiler und flexibler ist. Dieser Artikel hier weiterlesen

Einleitung Die IT Hygiene-Sektion im Wazuh Dashboard bietet eine zentrale Übersicht über Inventarisierungs- und Konfigurationsdaten (z. B. OS-Details, installierte Software, Prozesse, Netzwerk) aus allen überwachten Endpunkten. Diese Daten werden von den Syscollector-Modulen der Agenten gesammelt, in der Wazuh Indexer-Datenbank aggregiert und im Dashboard visualisiert. Wazuh Dokumentation Wenn in dieser Sektion jedoch nur „No results match hier weiterlesen

Einleitung (Einordnung, Relevanz für Security/SIEM/Wazuh) Windows Sysmon Event ID 3 („Network connection“) ist eine der wichtigsten Telemetriequellen für Threat Hunting, IOC-Matching und Threat-Intel-Enrichment (z. B. via OpenCTI). In Wazuh wirkt das auf den ersten Blick trivial: „Ich schreibe eine Rule auf EventID 3, dann bekomme ich Alerts.“ In der Praxis scheitert es aber häufig an hier weiterlesen

Einleitung (Einordnung, Relevanz für Security/SIEM/Wazuh) Beim Bau eigener Wazuh-Regeln kommt es oft zu einem Missverständnis, das in SIEM-Setups schnell zu falschen Alarmen oder – schlimmer – zu verdeckten Erkennungsregeln führt: Rule-IDs steuern keine Priorität. Entscheidend sind die Matching-Logik, die Regelhierarchie und die Severity/Level-Semantik in Kombination mit der Alert-Schwelle des Managers. Dieser Beitrag zeigt anhand eines hier weiterlesen

Einleitung UEBA-Logik in Wazuh lebt davon, dass Basiserkennung, Klassifizierung und Korrelation sauber ineinandergreifen: erst wird ein Event zuverlässig erkannt (Parent Rule), dann kategorisiert (z. B. Severity/Incident Type), und erst darauf baut die eigentliche UEBA-Korrelation (Frequency/Timeframe/Same-field) auf. In der Praxis scheitert genau dieses Konstrukt jedoch häufig nicht an der Korrelation selbst, sondern an zwei unscheinbaren Basics: hier weiterlesen

EinleitungDer Betrieb von Wazuh in Kubernetes-Umgebungen wie AWS EKS bringt klare Vorteile bei Skalierung und Hochverfügbarkeit, legt aber auch Verhaltensweisen offen, die in klassischen VM-Deployments weniger auffallen. Zwei besonders kritische Symptome treten dabei immer wieder auf: stetig wachsender Speicherverbrauch von wazuh-manager-worker-Pods und exakt periodische CPU-Spikes, die ganze Nodes destabilisieren können. Dieser Artikel ordnet beide Effekte hier weiterlesen

EinleitungPasswortrotation ist in produktiven SIEM-/XDR-Umgebungen Pflicht – aber in verteilten Wazuh-Deployments kann ein unvollständig durchgezogener Passwortwechsel schnell zum Totalausfall des Dashboards führen. Typisches Symptom: opensearch-dashboards wirft fortlaufend [ResponseError], während der Manager und der Indexer scheinbar „laufen“. Dieser Artikel erklärt die häufigsten Ursachen in der Wazuh-Architektur, warum wazuh-passwords-tool.sh auf dem Manager nur die Help-Page ausgibt oder hier weiterlesen

Einleitung (Einordnung, Relevanz für Security/SIEM/Wazuh) Ein klassischer „SIEM-Albtraum“ im Wazuh-Betrieb: Ereignisse werden korrekt dekodiert, Regeln feuern, Alerts werden sauber nach alerts.json geschrieben – aber im Dashboard ist nichts zu sehen. In fast allen Fällen ist das kein UI-Problem, sondern ein Indexing-Problem: Filebeat versucht Alerts in den Wazuh Indexer zu schreiben, wird aber wegen Mapping-Konflikten (Field-Typen) hier weiterlesen

EinleitungSoftware-Inventar und Konfigurations-Compliance gehören zu den zuverlässigsten Indikatoren für Drift, Shadow-IT und potenziell riskante Veränderungen auf Endpoints. Wazuh bringt dafür zwei wichtige Bausteine mit: System Inventory (Syscollector) für installierte Pakete/Programme und Security Configuration Assessment (SCA) für Policy-basierte Checks. Die häufige Anforderung aus dem Betrieb: „Bitte monatlich per E-Mail eine Übersicht, welche Endpoints vom Baseline-Stand abweichen hier weiterlesen

Einleitung SSH-Authentifizierungslogs sind eine zentrale Datenquelle für die Angriffserkennung in Wazuh. Gerade bei fehlgeschlagener Schlüssel-Authentifizierung („key-based auth required“) liefern sshd-Logs wichtige Hinweise auf Fehlkonfigurationen oder gezielte Angriffsversuche.Damit diese Ereignisse zuverlässig in Regeln verarbeitet werden können, ist eine korrekte Decoder-Strategie entscheidend – insbesondere bei lokalen Anpassungen. Dieser Artikel basiert auf einem realen Community-Fall und zeigt praxisnah, hier weiterlesen

Einleitung Cisco-IOS-Syslog ist in vielen Netzwerken eine der wichtigsten Telemetriequellen für Zugriffskontrolle und Incident Response. Gerade erfolgreiche Logins sind für Security-Teams relevant (z. B. für Anomalieerkennung, Laterale Bewegung, Valid-Accounts-Missbrauch). Wazuh bringt zwar bereits Cisco-IOS-Decoder und Regeln mit – in der Praxis möchte man aber oft eigene Felder extrahieren und eigene Alerts erzeugen, ohne die Standardregeln hier weiterlesen

Einleitung (Einordnung, Relevanz für Security/SIEM/Wazuh) Single Sign-on (SSO) über Microsoft Entra ID ist in vielen SIEM-Umgebungen ein Muss: zentrale Identitäten, MFA, kontrollierte Rollenvergabe und nachvollziehbare Zugriffe auf Dashboards. In Wazuh basiert SSO (SAML) im Kern auf der OpenSearch-Security-Konfiguration des Wazuh Indexers und erfordert ein sauberes Zusammenspiel aus YAML-Struktur, Dateipfaden und dem korrekten Einsatz von securityadmin.sh. hier weiterlesen

Einleitung Forcepoint DLP liefert für SIEM-Integrationen häufig CEF über Syslog. Auf dem Papier ist das ideal: ein standardisierter CEF-Header plus Extension als Key-Value-Paare. In der Praxis scheitert die Dekodierung in Wazuh aber oft genau dort, wo DLP-Events wertvoll werden: bei freien Textfeldern und Policy-/Kategorie-Namen mit Leerzeichen, Sonderzeichen oder Doppelpunkten. Das führt zu unvollständigen Feldern und hier weiterlesen

Einleitung CEF (Common Event Format) ist in vielen SIEM-Pipelines der „kleinste gemeinsame Nenner“ für Security-Telemetrie. In der Praxis stolpern Wazuh-Administratoren aber regelmäßig darüber, dass CEF-Events aus Kaspersky Security Center (KSC) nur teilweise geparst werden: Statt Header + Extension-Key/Value-Paare landen nur wenige Felder im Event. Das ist nicht nur lästig, sondern reduziert direkt den Detection- und hier weiterlesen

In der Praxis landen Citrix ADC (ehem. NetScaler) Syslog-Zeilen oft in einem Format, das stark an klassische ns.log-/Syslog-Ausgaben erinnert (z. B. 0-PPE-0 : TCP CONN_TERMINATE …). Dieses Muster matcht schnell auf generische/Default-Decoder (z. B. netscaler), sodass eigene Felder nicht wie gewünscht extrahiert werden oder „falsch“ interpretiert wirken. Ein typisches Citrix-Beispiel sieht u. a. so aus: hier weiterlesen

Einleitung Vulnerability Detection ist nur dann wirklich hilfreich, wenn Findings korrekt eingeordnet werden können. Gerade bei CVEs mit hohem Schweregrad führt eine falsche oder missverständliche Zuordnung schnell zu Verunsicherung – insbesondere in Audits oder Compliance-Prüfungen. Ein aktuelles Beispiel ist CVE-2024-56180, das in Wazuh auf Ubuntu 24.04 LTS als kritisch gemeldet wird, obwohl das betroffene Produkt hier weiterlesen