SYSLOG-Parsing im Detail

In unserem letzten ELK-Blog, haben wir ELK (Elasticsearch, Logstash und Kibana) auf Docker eingerichtet. Jetzt werden wir diese komplexen Protokolle in Bausteine umwandeln, die es Ihnen ermöglichen, Visualisierungen in Kibana zu erstellen.

Wenn Sie Hands-On Practice with the ELK Stack noch nicht gelesen haben, können Sie beginnen, indem Sie das folgende GitHub-Repository klonen, um Ihre ELK-Stack einzurichten: https://github.com/object1st/elk-stack.git

_{cd elk-stack}

Befehlsausführung:

docker-compose up -d

Navigieren Sie dann in Ihrem Browser zur IP-Adresse oder DNS-Namen Ihrer VM (oder localhost, wenn Sie dies lokal durchführen) und greifen Sie über Port 5601 auf Kibana zu: http://myvm:5601

Parsing von Syslog

Am Ende dieses Walkthroughs können Sie erwarten:

• Eine komplexe Syslog-Nachricht geparst zu haben
• Intelligente Bedrohungserkennung erstellt zu haben, die automatisch einen Ransomware-Indikator erkennt
• Ein Dashboard erstellt zu haben, um den Alarm anzuzeigen

Die Herausforderung: Komplexe Protokollstrukturen

Lassen Sie uns mit einer realen Syslog-Nachricht beginnen.

Beispiel: Veeam Malware-Erkennung

Mar 20, 2025 @ 14:06:09.662 VBRSRV01 Veeam_MP: [origin enterpriseId="31023"] [categoryId=0 instanceId=41600 DetectionTimeUTC="03/20/2025 13:05:41" OibID="0e54d3bf-add8-48eb-9122-fad3ac1e8fb3" ActivityType="EncryptedData" UserName="TECH\user1" ObjectName="VM01" VbrHostName="vbrsrv01.tech.local" Description="Potential malware activity detected for OIB: 0e54d3bf-add8-48eb-9122-fad3ac1e8fb3 (VM01), rule: Encrypted data by user: TECH\user1."]

Warum diese Nachrichten wichtig sind

In dieser Protokollnachricht finden Sie wertvolle Einblicke – nehmen Sie sich einen Moment Zeit, um sie zu erkunden.

Veeam Nachricht:

• Potenzielle Ransomware-Aktivität im Gange
• Beteiligtes Benutzerkonto (TECH\user1)
• Betroffene virtuelle Maschine (VM01)
• Verhaltensmuster (Verschlüsselte Datenaktivität)

Aber in seinem aktuellen Zustand können Sie nicht einfach:

• Nachverfolgen, welche VMs potenziell betroffen sind.
• Verdächtige Aktivitäten über die Zeit korrelieren
• Berichte über diese Aktivitäten generieren

Schritt 1: Einfach anfangen, intelligent aufbauen

Hier machen die meisten Leute einen Fehler: Sie versuchen, alles auf einmal zu parsen und enden mit einer Konfiguration, die nicht funktioniert.

Wenn Sie mitarbeiten möchten, suchen Sie die Dateien im Ordner „Beispiele“ des GitHub-Repositorys. Wenn Sie ELK bereits aus dem vorherigen Blogbeitrag in Docker installiert haben, kopieren Sie einfach diese Dateien in Ihre Einrichtung. Während Sie durch diesen Blog arbeiten, ersetzen Sie die vorhandenen Dateien durch die hier bereitgestellten aktualisierten Versionen. Wenn Sie einen Fehler machen oder beim Bearbeiten verloren gehen, können Sie das Repository jederzeit erneut klonen, um von vorne zu beginnen.

1. Um zu verwenden, löschen Sie die logstash.conf in der Pipeline, indem Sie sie ersetzen mit

   logstash_version1.conf ($ cp ~/elk-stack/Examples/logstash_version1.conf ~/elk-stack/logstash/pipeline/logstash.conf)

2. Starten Sie den Logstash-Container neu ($ docker-compose restart logstash).

Warum dieser Ansatz funktioniert:

• Beginnen Sie mit funktionierendem Input/Output
• Verwenden Sie stdout, um genau zu sehen, was Logstash erhält (wird in den Docker-Container-Protokollen angezeigt)
• Rohprotokolle gehen weiterhin an Elasticsearch (nichts geht verloren)
• Komplexität schrittweise aufbauen, ohne Dinge zu brechen

Schritt 2: Testen Sie Ihre Einrichtung

1. Senden Sie Ihre Beispielnachrichten an Logstash und beobachten Sie die Ausgabe. Hier sind einige Methoden, die Sie verwenden können, um selbst eine Syslog-Nachricht zu senden.
2. Verwendung von netcat:

• Kopieren und fügen Sie den folgenden Befehl in Ihre CLI ein (Veeam Syslog-Nachricht):

echo '<14>1 2025-03-20T14:06:09.662307+02:00 VBRSRV01 Veeam_MP - - [origin enterpriseId="31023"] [categoryId=0 instanceId=41600 DetectionTimeUTC="03/20/2025 13:05:41" OibID="0e54d3bf-add8-48eb-9122-fad3ac1e8fb3" ActivityType="EncryptedData" UserName="TECH\user1" ObjectName="VM01" VbrHostName="vbrsrv01.tech.local" Description="Potential malware activity detected"]' | nc -u -q0 localhost 5514

• Sie sollten etwas wie dies sehen, wenn Sie docker logs logstash eingeben:

Dies ist ein Problem, da alles Wertvolle in einem riesigen Nachrichtenfeld gefangen ist:

“"message" =&gt; "<14>1 2025-03-20T14:06:09.662307+02:00 VBRSRV01 Veeam_MP - - [origin enterpriseId=\"31023\"] [categoryId=0 instanceId=41600 DetectionTimeUTC=\"03/20/2025 13:05:41\" OibID=\"0e54d3bf-add8-48eb-9122-fad3ac1e8fb3\" ActivityType=\"EncryptedData\" UserName=\"TECH\\user1\" ObjectName=\"VM01\" VbrHostName=\"vbrsrv01.tech.local\" Description=\"Potential malware activity detected\"]\n",”

Um dieses Problem zu beheben, parsen Sie die Protokolle, um sie sauberer zu machen.

Hier wird es interessant (und etwas beängstigend, wenn Sie neu in Regex sind). Wir werden dieses Protokoll zerlegen und es einfacher machen, Informationen herauszupicken.

Bevor wir Code schreiben, lassen Sie uns verstehen, womit wir arbeiten:

Veeam Struktur: [Zeitstempel] [Hostname] [Anwendung]: [ursprüngliche Daten] [Erkennungsdaten]

Schritt 3: Grundlegendes Parsing

Kopieren Sie die nächste Logstash-Datei:

1. Um zu verwenden, löschen Sie die logstash.conf in der Pipeline, indem Sie sie ersetzen mit logstash_version2.conf ($

cp ~/elk-stack/Examples/logstash_version2.conf  ~/elk-stack/logstash/pipeline/logstash.conf) 

2. Starten Sie den Logstash-Container neu ($ docker-compose restart logstash)

Grok-Muster dekodiert:

• %{POSINT:priority} → Erfasst positive Ganzzahlen als "priority"
• %{TIMESTAMP_ISO8601:timestamp} → Eingebautes Muster für ISO-Zeitstempel
• %{IPORHOST:host} → IP-Adresse oder Hostname
• %{GREEDYDATA:raw_message} → Alles andere (das werden wir als nächstes parsen)

Dieses neue Grok-Muster ist darauf ausgelegt, rohe Syslog-Nachrichten in strukturierte, verwendbare Daten zu zerlegen. Es trennt speziell die grundlegenden Komponenten einer Syslog-Nachricht (wie Zeitstempel, Hostname und Protokollebene), identifiziert die Anwendungsquelle, die das Protokoll generiert, und kennzeichnet jede Nachricht für die weitere Verarbeitung in der Pipeline. Dieser grundlegende Schritt ermöglicht später im Workflow komplexeres Parsing, Anreicherung und Alarmierungslogik.

3. Testen Sie erneut, um Unterschiede zu sehen:

echo '<14>1 2025-03-20T14:06:09.662307+02:00 VBRSRV01 Veeam_MP - - [origin enterpriseId="31023"] [categoryId=0 instanceId=41600 DetectionTimeUTC="03/20/2025 13:05:41" OibID="0e54d3bf-add8-48eb-9122-fad3ac1e8fb3" ActivityType="EncryptedData" UserName="TECH\user1" ObjectName="VM01" VbrHostName="vbrsrv01.tech.local" Description="Potential malware activity detected"]' | nc -u -q0 localhost 5514

4. Überprüfen Sie dann die Logstash-Containerprotokolle ($ docker logs logstash).

Die Felder, die wir extrahiert haben:

_{priority → 0}

_{timestamp → 2025-03-20T14:06:09.662307+02:00}

_{host → ["172.19.0.1", "VBRSRV01"]}

_{application → "Veeam_MP"}

_{severity → "Emergency"}

_{severity_level → 0}

Schritt 4: Tiefere Analyse des Parsings

Jetzt werden wir noch mehr parsen. Die Datei ist zu groß, um sie hier auszudrucken, aber sie befindet sich in Ihrem „Beispiele“-Ordner als logstash_version3.conf.

1. Um zu verwenden, löschen Sie die logstash.conf in der Pipeline, indem Sie sie ersetzen mit: logstash_version3.conf ($

   cp ~/elk-stack/Examples/logstash_version3.conf ~/elk-stack/logstash/pipeline/logstash.conf)

2. Starten Sie den Logstash-Container neu ($ docker-compose restart logstash).
3. Testen Sie an diesem Punkt Ihre Konfiguration. Sie sollten einzelne Felder anstelle eines großen Nachrichtenblocks sehen.
4. Führen Sie die gleiche Testnachricht erneut aus und überprüfen Sie dann die Logstash-Containerprotokolle ($ docker logs logstash).

Die Felder, die wir extrahiert haben:

_{enterprise_id → "31023"}

_{category_id → 0 (in Ganzzahl umgewandelt)}

_{instance_id → 41600 (in Ganzzahl umgewandelt)}

_{detection_time_utc → "03/20/2025 13:05:41"}

_{detection_timestamp → 2025-03-20T13:05:41.000Z (richtig geparster Zeitstempel)}

_{oib_id → "0e54d3bf-add8-48eb-9122-fad3ac1e8fb3" (eindeutige Alarm-ID)}

_{activity_type → "EncryptedData" (Malware-Indikator)}

_{username → "TECH\\user1"}

_{object_name → "VM01" (betroffene VM)}

_{vbr_hostname → "vbrsrv01.tech.local"}

_{description → "Potenzielle Malware-Aktivität erkannt"}

Schritt 5: Veeam Bedrohungsintelligenz und Fehlerbehandlung

Zu guter Letzt müssen wir unserem System Intelligenz hinzufügen und eine Fehlerbehandlung implementieren, um uns bei Bedarf beim Debuggen zu unterstützen. Die Hinzufügung von Intelligenz ist wichtig, da sie das Filtern nach geschäftlichen Auswirkungen ermöglicht, prioritätsbasierte Warnungen zulässt, die Erstellung von Dashboards intuitiv macht, umsetzbare Empfehlungen bietet und die Alarmmüdigkeit verringert.

So fügen Sie Intelligenz hinzu und behandeln Fehler:

1. Um zu verwenden, löschen Sie die logstash.conf in der Pipeline und ersetzen Sie sie durch: logstash_version4.conf ($ 

   cp ~/elk-stack/Examples/logstash_version4.conf ~/elk-stack/logstash/pipeline/logstash.conf)

2. Starten Sie den Logstash-Container neu ($ docker-compose restart logstash).
3. Warten Sie, bis die Pipeline läuft, und senden Sie dann die Testnachricht erneut:

echo '<14>1 2025-03-20T14:06:09.662307+02:00 VBRSRV01 Veeam_MP - - [origin enterpriseId="31023"] [categoryId=0 instanceId=41600 DetectionTimeUTC="03/20/2025 13:05:41" OibID="0e54d3bf-add8-48eb-9122-fad3ac1e8fb3" ActivityType="EncryptedData" UserName="TECH\user1" ObjectName="VM01" VbrHostName="vbrsrv01.tech.local" Description="Potential malware activity detected"]' | nc -u -q0 localhost 5514

Welche neuen Felder wir extrahiert haben:

_{threat_type → "potential_ransomware" (intelligente Bedrohungskategorisierung)}

_{event_category → "malware" (Sicherheitsklassifizierung)}

_{business_impact → "hoch" (Risikobewertung)}

_{alert_priority → "kritisch" (Eskalationspriorität)}

_{recommendation → "Sofortige Untersuchung erforderlich" (Reaktionsleitfaden)}

_{event_type → "security_event" (Ereignisklassifizierung)}

Abschnittszusammenfassung

In diesem Abschnitt haben wir erfolgreich Folgendes abgeschlossen:

• Geschäftlichen Kontext zu Rohereignissen hinzugefügt
• Intelligente Schweregradklassifizierung erstellt
• Bedrohungskategorisierungssystem aufgebaut
• Prioritätsbasierte Warnungen aktiviert

Schritt 6: Erstellen Sie eine Indexvorlage

Bevor wir Daten in Elasticsearch senden, müssen wir sie für unseren spezifischen Anwendungsfall optimieren.

1. Im GitHub-Repository finden Sie die Datei index_template.json, die wir in Kibana importieren können.

2. Lassen Sie uns einen curl-Befehl verwenden, um unsere index_template.json aus dem Ordner „Beispiele“ zu importieren.

Wenn Sie Schwierigkeiten haben, die Befehle hier zu kopieren, finden Sie sie auch in der README.md-Datei des GitHub-Repositorys

curl -X PUT "localhost:9200/_index_template/veeam-syslog-template" \ -H "Content-Type: application/json" \ -d @index_template.json

3. Sie sollten diese Nachricht sehen, wenn der Import erfolgreich war.

4. Als Nächstes erstellen wir ein Indexmuster (in späteren Versionen als Datenansichten bezeichnet).

• Geben Sie den folgenden Befehl ein:

curl -X POST "localhost:5601/api/saved_objects/index-pattern/syslog-pattern" -H "Content-Type: application/json" -H "kbn-xsrf: true" -d '{"attributes":{"title":"syslog-*","timeFieldName":"@timestamp"}}'

• Sie könnten auch über die WebUI erstellen.

5. Überprüfen Sie, ob das Indexmuster erstellt wurde, indem Sie die folgenden Aktionen ausführen:

• Gehen Sie zu Stack Management
• Klicken Sie auf „Indexmuster“ unter „Kibana“
• Hier können wir unser neu erstelltes Indexmuster sehen.

6. Als Nächstes müssen wir eine Visualisierung erstellen.

• Klicken Sie auf „Visualize Library.“
• Klicken Sie auf die Kachel „Lens“.
• Wählen Sie im Dropdown-Menü „Metric“.

7. Geben Sie im Filterfeld ein: threat_type: “potential_ransomware”

8. Wählen Sie „Overtime“ in der Mitte (das ist Ihre Wahl, wie Sie möchten, dass das Dashboard aussieht).

9. Speichern Sie die Visualisierung, indem Sie auf die Schaltfläche "Speichern" in der oberen rechten Ecke klicken und zu einem neuen Dashboard hinzufügen:

10. Ändern Sie den „Namen“ unter Metrics in „Alerts“ und wählen Sie Records auf der linken Seite.

• Sie sollten am Ende dies haben:

11. Speichern Sie dies in Ihrer Visualisierungsbibliothek und wählen Sie vorerst „Kein Dashboard“.

12. Als Nächstes erstellen Sie eine weitere Visualisierung, die wir „Betroffene Maschinen“ nennen werden.

• Wählen Sie diesmal Tabelle, nicht Metrik, und verwenden Sie das Feld „Top-Werte von object_name“ und erneut Aufzeichnung. Ändern Sie die Namen der Spalten, indem Sie auf die rechten Seiten der Namen klicken und den Anzeigenamen ändern:

13. Speichern Sie erneut in Ihrer Bibliothek.

14. Lassen Sie uns nun eine weitere Tabellenvisualisierung erstellen – diesmal mit dem Feld „Top-Werte von Username“. Dies kann helfen, zu identifizieren, welche Benutzer möglicherweise während des Angriffs angemeldet waren. Denken Sie daran, dass dies rein zu Erkundungszwecken dient und zeigt, wie kreativ Sie die Daten nutzen können.

15. Erstellen Sie schließlich eine Flächenvisualisierung – diesmal mit Warnungen und Zeitachsen.

16. Fühlen Sie sich frei, weitere zu erstellen oder bestehende zu ändern, um ein Gefühl dafür zu bekommen. Wir haben einige sehr grundlegende Visualisierungen erstellt, nur um den Prozess zu erklären.

17. Erstellen Sie schließlich ein Dashboard und fügen Sie diese Visualisierungen hinzu.

18. Speichern Sie das Dashboard unter dem Namen „Potenzielle Ransomware.“

19. Um zu testen, senden wir eine weitere Warnung, als ob sie von Veeam stammt, aber ändern einige der Komponenten der Nachricht, damit wir sehen können, ob sie ordnungsgemäß verarbeitet wird.

20. Lassen Sie uns den Benutzernamen in Gustev und die VM in MainFrameSuper ändern.

echo '<14>1 2025-03-20T14:06:09.662307+02:00 VBRSRV01 Veeam_MP - - [origin enterpriseId="31023"] [categoryId=0 instanceId=41600 DetectionTimeUTC="03/20/2025 13:05:41" OibID="0e54d3bf-add8-48eb-9122-fad3ac1e8fb3" ActivityType="EncryptedData" UserName="NASA\Gustev\" ObjectName="MainFrameSuper" VbrHostName="vbrsrv01.tech.local" Description="Potential malware activity detected"]' | nc -u -q0 localhost 5514

• Wie wir sehen können, warnt uns unser Dashboard sofort nach Erhalt der Syslog-Nachricht:

Fazit

Als Sie diese Serie begonnen haben, standen Sie vor einer 347-Zeichen hohen Mauer aus kryptischem Text:

<14>1 2025-03-20T14:06:09.662307+02:00 VBRSRV01 Veeam_MP - - [origin enterpriseId="31023"] [categoryId=0 instanceId=41600 DetectionTimeUTC="03/20/2025 13:05:41" OibID="0e54d3bf-add8-48eb-9122-fad3ac1e8fb3" ActivityType="EncryptedData" UserName="TECH\user1" ObjectName="VM01" VbrHostName="vbrsrv01.tech.local" Description="Potential malware activity detected"]

Jetzt löst dieselbe Nachricht ein intelligentes Sicherheitsüberwachungssystem aus, das sofort identifiziert:

• Bedrohungstyp: Potenzielle Ransomware-Aktivität
• Prioritätsstufe: Kritische geschäftliche Auswirkungen
• Betroffener Benutzer: TECH\user1 (als Mensch identifiziert, nicht als Dienstkonto)
• Kompromittiertes Asset: VM01 virtuelle Maschine

In diesem Blog haben wir den Lesern ein klareres Bild davon gegeben, was mit einer Roh-Syslog-Nachricht geschehen muss, bevor sie in einem SIEM nützlich sein kann – insbesondere innerhalb des ELK-Stacks. Von der Analyse bis zur Anreicherung haben wir die wesentlichen Schritte aufgeschlüsselt, die laute Protokolle in umsetzbare Erkenntnisse verwandeln.

Im nächsten und letzten Teil unserer SIEM Elasticsearch Mini-Blog-Serie werden wir kurz darauf eingehen, wie man Fluentd anstelle von Logstash nutzt und auf Elastic Security eingehen.