Eigenes SIEM aufsetzen
Schelle Anleitung zur Wazuh-Installation
In diesem Beitrag möchte ich aufzeigen, wie einfach es ist, sein eigenes SIEM auzusetzen.
Oft begegnet man mir mit Unverständnis, wenn im Gespräch mit Freunden die Frage aufkommt: "Hast Du da keine Angst, wenn Du einen Server ins Internet stellst?"
Naja. Ich behalte sie sehr genau im Auge. Und wenn ich einmal nicht hinschauen kann, übernimmt mein SIEM diese Aufgabe für mich.
Bevor es losgeht: Installation von Basiswerkzeugen
Wichtige Tools wie curl und nala werden installiert. Zusätzlich wird sudo als Paket nachinstalliert und der Benutzer (in diesem Fall michael) zur Sudo-Gruppe hinzugefügt:
nala install curl sudo
usermod -aG sudo michael
Installation von Wazuh
Die eigentliche Installation des Wazuh SIEM erfolgt durch das Ausführen des Installationsskripts, welches von der offiziellen Wazuh-Webseite heruntergeladen wird. Dies erfolgt für die aktuelle Version 4.10 mit dem folgenden Befehl:
curl -sO https://packages.wazuh.com/4.10/wazuh-install.sh && sudo bash ./wazuh-install.sh -a -i
Nach Abschluss der Installation werden die Zugangsdaten angezeigt, mit denen man sich an der Webseite als admin anmelden kann.
Weiterführende Konfiguration
Die zentrale Konfiguration erfolgt über die Datei /var/ossec/etc/ossec.conf. In dieser Datei werden globale Einstellungen, Alarmeinstellungen, Remote-Verbindungen, Active Responses sowie weitere Module (wie syscheck, rootcheck und syscollector) definiert. Besonderes Augenmerk gilt der Definition der E-Mail-Benachrichtigungen (SMTP-Server, Absender, Empfänger) sowie den Regeln für die Active Response. Die Konfigurationsdatei beinhaltet darüber hinaus Einstellungen zu Log-Formaten, Synchronisation und weiteren Sicherheitsmodulen. Sie ist ziemlich selbsterklärend und bedarf nur wenig Anpassung.
Vielleicht möchte man sich Syslog-Meldungen genauer anschauen. Dazu muss man die Meldungen entgegennehmen. Ich habe mir UDP und TCP freigeschaltet:
<remote>
<connection>secure</connection>
<port>1514</port>
<protocol>tcp</protocol>
<queue_size>131072</queue_size>
</remote>
<remote>
<connection>syslog</connection>
<port>514</port>
<protocol>udp</protocol>
<allowed-ips>0.0.0.0/0</allowed-ips>
<local_ip>0.0.0.0</local_ip>
</remote> Aber auch das Wissen über Schwachstellen der Systeme, die man überwachen möchte, sind nützlich und können einfach eingeschaltet werden:
<vulnerability-detection>
<enabled>yes</enabled>
<index-status>yes</index-status>
<feed-update-interval>60m</feed-update-interval>
</vulnerability-detection> Nach Anpassung der Konfiguration erfolgt immer ein Neustart des Wazuh-Managers:
systemctl restart wazuh-manager.service
Login
Über wazuh habe ich ja bereits einiges geschrieben. Alle Funktionen, die man enabled hat, tauchen sofort in der Übersicht auf:
Wahrscheinlich möchte man sofort sehen, ob durch die Syslog-Meldungen Alarme generiert werden. Diese sieht man sofort unter Threat Hunting.
Ingest Pipeline für Filebeat anpassen
Im Rahmen der Integration mit Filebeat wird die Pipeline für Wazuh-Alarme in der Datei /usr/share/filebeat/module/wazuh/alerts/ingest/pipeline.json konfiguriert. Diese Pipeline umfasst mehrere Prozessoren, die JSON-Daten parsen, GeoIP-Informationen anreichern und Datumseinträge korrekt formatieren. Die detaillierte Konfiguration der einzelnen Prozessoren gewährleistet, dass eingehende Alarme optimal aufbereitet werden, bevor sie in Elasticsearch indexiert werden. Ich habe hier als Beispiel die Geolokation für alle SourceIP-Felder aktiviert, doch genau an dieser Stelle sind viele Änderungen möglich:
ingest/pipeline.json
{
"description": "Wazuh alerts pipeline",
"processors": [
{ "json" : { "field" : "message", "add_to_root": true } },
{
"set": {
"field": "data.aws.region",
"value": "{{data.aws.awsRegion}}",
"override": false,
"ignore_failure": true,
"ignore_empty_value" : true
}
},
{
"set": {
"field": "data.aws.accountId",
"value": "{{data.aws.aws_account_id}}",
"override": false,
"ignore_failure": true,
"ignore_empty_value" : true
}
},
{
"geoip": {
"field": "data.srcip",
"target_field": "GeoLocation",
"properties": ["city_name", "country_name", "region_name", "location"],
"ignore_missing": true,
"ignore_failure": true
}
},
{
"geoip": {
"field": "data.src_ip",
"target_field": "GeoLocation",
"properties": ["city_name", "country_name", "region_name", "location"],
"ignore_missing": true,
"ignore_failure": true
}
},
{
"geoip": {
"field": "data.win.eventdata.ipAddress",
"target_field": "GeoLocation",
"properties": ["city_name", "country_name", "region_name", "location"],
"ignore_missing": true,
"ignore_failure": true
}
},
{
"geoip": {
"field": "data.aws.sourceIPAddress",
"target_field": "GeoLocation",
"properties": ["city_name", "country_name", "region_name", "location"],
"ignore_missing": true,
"ignore_failure": true
}
},
{
"geoip": {
"field": "data.aws.client_ip",
"target_field": "GeoLocation",
"properties": ["city_name", "country_name", "region_name", "location"],
"ignore_missing": true,
"ignore_failure": true
}
},
{
"geoip": {
"field": "data.aws.service.action.networkConnectionAction.remoteIpDetails.ipAddressV4",
"target_field": "GeoLocation",
"properties": ["city_name", "country_name", "region_name", "location"],
"ignore_missing": true,
"ignore_failure": true
}
},
{
"geoip": {
"field": "data.aws.httpRequest.clientIp",
"target_field": "GeoLocation",
"properties": ["city_name", "country_name", "region_name", "location"],
"ignore_missing": true,
"ignore_failure": true
}
},
{
"geoip": {
"field": "data.gcp.jsonPayload.sourceIP",
"target_field": "GeoLocation",
"properties": ["city_name", "country_name", "region_name", "location"],
"ignore_missing": true,
"ignore_failure": true
}
},
{
"geoip": {
"field": "data.office365.ClientIP",
"target_field": "GeoLocation",
"properties": ["city_name", "country_name", "region_name", "location"],
"ignore_missing": true,
"ignore_failure": true
}
},
{
"date": {
"field": "timestamp",
"target_field": "@timestamp",
"formats": ["ISO8601"],
"ignore_failure": false
}
},
{
"date_index_name": {
"field": "timestamp",
"date_rounding": "d",
"index_name_prefix": "{{fields.index_prefix}}",
"index_name_format": "yyyy.MM.dd",
"ignore_failure": false
}
},
{ "remove": { "field": "message", "ignore_missing": true, "ignore_failure": true } },
{ "remove": { "field": "ecs", "ignore_missing": true, "ignore_failure": true } },
{ "remove": { "field": "beat", "ignore_missing": true, "ignore_failure": true } },
{ "remove": { "field": "input_type", "ignore_missing": true, "ignore_failure": true } },
{ "remove": { "field": "tags", "ignore_missing": true, "ignore_failure": true } },
{ "remove": { "field": "count", "ignore_missing": true, "ignore_failure": true } },
{ "remove": { "field": "@version", "ignore_missing": true, "ignore_failure": true } },
{ "remove": { "field": "log", "ignore_missing": true, "ignore_failure": true } },
{ "remove": { "field": "offset", "ignore_missing": true, "ignore_failure": true } },
{ "remove": { "field": "type", "ignore_missing": true, "ignore_failure": true } },
{ "remove": { "field": "host", "ignore_missing": true, "ignore_failure": true } },
{ "remove": { "field": "fields", "ignore_missing": true, "ignore_failure": true } },
{ "remove": { "field": "event", "ignore_missing": true, "ignore_failure": true } },
{ "remove": { "field": "fileset", "ignore_missing": true, "ignore_failure": true } },
{ "remove": { "field": "service", "ignore_missing": true, "ignore_failure": true } }
],
"on_failure" : [{
"drop" : { }
}]
}Nach der Anpassung ist wie immer ein erneuter Start des wazuh-manager notwendig, um die Änderungen zu übernehmen:
systemctl restart wazuh-manager.service
Und so hat man bereits nach kurzer Zeit einen guten Überblick über das aktuelle Geschehen im eigenen Netz.
Fazit
Wie man sieht, ist wazuh sehr schnell aufgesetzt und betriebsbereit. Früher hatte ich auch die Docker-Variante im Einsatz. Doch leider musste ich erkennen, dass aufgrund der Persistenz von Docker-Containern, die Config-Files an anderen Stellen und mit anderen Namen zu suchen sind. Daher bleibe ich bei der Installation in einer VM auf meinem Proxmox-Server.