OPNsense-WebGUI-Login-Logs korrekt dekodieren: Wenn der Solaris-Decoder dazwischenfunkt

Einleitung

Beim Einbinden neuer Logquellen in Wazuh stoßen Einsteiger wie erfahrene Administratoren gleichermaßen auf ein wiederkehrendes Problem: Ein vorhandener Standard-Decoder greift „zu früh“ und verhindert die saubere Analyse eines eigentlich ganz anderen Logformats. Besonders häufig tritt dies bei Syslog-basierten Quellen auf, deren program_name generisch ist. Ein typisches Beispiel sind OPNsense-WebGUI-Logs, die durch den integrierten solaris_bsm-Decoder fehlklassifiziert werden. Dieser Artikel erklärt, warum das passiert, weshalb Regel-Overwrites hier nicht helfen und welche sauberen Lösungswege es gibt.

Ausgangslage / Problemstellung

OPNsense sendet erfolgreiche WebGUI-Login-Events per Syslog, etwa in folgender Form:

2026-01-07T09:43:37+00:00 OPNMItest.mydomain audit[29500]: /index.php: Successful login for user 'root' from: 192.168.1.1

Wazuh erkennt dabei den program_name audit und ordnet das Event automatisch dem Decoder solaris_bsm zu. In der Folge greift die zugehörige Regel mit der ID 6100 (Level 0), wodurch das Ereignis praktisch „neutralisiert“ wird.
Versuche, dieses Verhalten mit eigenen Regeln (<if_sid>6100</if_sid>) oder über <decoded_as>solaris_bsm</decoded_as> zu umgehen, führen zu Validierungsfehlern oder greifen nicht wie erwartet.

Technische Analyse

Das Verhalten ist kein Bug, sondern eine Konsequenz der Wazuh-Decode-Pipeline:

  1. Predecoder extrahiert Timestamp, Hostname und program_name.
  2. Decoder-Auswahl erfolgt ausschließlich auf Basis von prematch, program_name oder Parent-Decoder-Logik.
  3. Regeln werden erst nach erfolgreichem Decoding angewendet.

Entscheidend ist:

  • Regeln können Decoder nicht ersetzen oder überschreiben.
  • Ein Rule-Overwrite (overwrite="yes") ändert nur Attribute wie Level oder Beschreibung, nicht aber, welcher Decoder verwendet wird.
  • Sobald ein Decoder greift, sind alle nachfolgenden Decoder ausgeschlossen.

Der solaris_bsm-Decoder ist relativ generisch und matcht auf audit, was in vielen Nicht-Solaris-Umgebungen zu Fehlklassifizierungen führt – insbesondere bei Firewalls oder Appliances, die denselben Programmnamen verwenden.

Lösung / Best Practices

Es gibt zwei saubere, unterstützte Lösungsansätze. Welcher sinnvoll ist, hängt vom Einsatzszenario ab.

1. Solaris-Decoder und -Regeln vollständig ausschließen
Wenn im eigenen Umfeld keine Solaris-Systeme betrieben werden, ist dies der pragmatischste und stabilste Weg. Über decoder_exclude und rule_exclude wird das komplette Solaris-BSM-Regelwerk deaktiviert.
Nach einem Neustart des Wazuh Managers bleibt das Event zunächst ohne Decoder – und kann anschließend gezielt mit eigenen OPNsense-Decodern verarbeitet werden.

Vorteile:

  • Keine Fehlklassifizierung mehr
  • Volle Kontrolle über eigene Decoder
  • Klare, wartbare Logik

2. Solaris-Regeln überschreiben (nicht empfohlen für dieses Problem)
Ein Overwrite der Regel 6100 kann zwar das Alert-Level anheben oder die Beschreibung ändern, ändert aber nichts am Decoder-Match. Für den eigentlichen Zweck – Felder wie User oder Quell-IP aus OPNsense-Logs zu extrahieren – ist dieser Ansatz ungeeignet. Er kaschiert lediglich das Symptom, nicht die Ursache.

Lessons Learned / Best Practices

  • Decoder-Logik hat Vorrang vor Regeln – falscher Decoder bedeutet falsche Analyse.
  • Regel-Overwrites können Decoder nicht „umgehen“.
  • Generische program_name-Matches sind häufige Ursachen für Fehlzuordnungen.
  • Nicht benötigte Standard-Decoder sollten konsequent ausgeschlossen werden.
  • Erst wenn kein Decoder matched, ist der Weg frei für saubere Custom-Decoder.

Fazit

Das Problem mit OPNsense-WebGUI-Logs und dem solaris_bsm-Decoder ist ein klassisches Beispiel dafür, warum Verständnis der Wazuh-Decode-Reihenfolge essenziell ist. Wer versucht, Decoder-Probleme mit Regeln zu lösen, arbeitet gegen die Architektur von Wazuh. Die saubere Lösung besteht darin, nicht benötigte Decoder auszuschließen und anschließend gezielt eigene Decoder für die tatsächliche Logquelle zu erstellen. Das Ergebnis ist eine robuste, transparente und langfristig wartbare Loganalyse.

Mehr zu Wazuh …
https://wazuh.com/?utm_source=ambassadors&utm_medium=referral&utm_campaign=ambassadors+program

Mehr zum Wazuh Ambassador Program …
https://wazuh.com/ambassadors-program/?utm_source=ambassadors&utm_medium=referral&utm_campaign=ambassadors+program

https://wazuh.slack.com/archives/C0A933R8E/p1767788054215199