Loggernaut-Konfigurationen

Backup Strategien

Loggernaut unterstützt aktuell zwei Backup-Strategien für die automatisierte Sicherung von Roh-Logs:

SFTP-Backup – Speicherung auf einem SFTP-Server
S3-Backup – Speicherung in einem S3-kompatiblen Objektspeicher

Beide Optionen bieten eine optionale clientseitige Verschlüsselung mit dem AGE-Verschlüsselungsverfahren.

SFTP Backup

Das Backup-System, automatisiert die Übertragung aller bisher ausschließlich auf dem Management-Server gespeicherten Roh-Logs auf einen SFTP-Server. Die detaillierte Konfiguration dieser Funktion ist in der Loggernaut config.json beschrieben und bietet Ihnen eine effiziente Methode zur Sicherung Ihrer Daten.

Auswahl der Backup Strategie

Im Parameter strategy wird festgelegt, wie Loggernaut mit Backups umgeht:

Wert

Beschreibung

local

Logs werden ausschließlich lokal auf dem Loggernaut gespeichert.

remove

Logs werden nach Ablauf der definierten TTL gelöscht.

sftp

Logs werden an einen externen SFTP-Server übertragen. Die Option sftp muss konfiguriert sein.

Vorsicht bei SFTP-Chroot! Wenn das Ziel '/user/siem/logs' ist und das Chroot auf '/user' festgelegt ist, sollte das tatsächliche Ziel '/siem/logs' sein, um mögliche Probleme zu vermeiden

SFTP-spezifische Felder

Feld

Beschreibung

Hinweise

permissions

Dateiberechtigungen im Unix-Stil (z. B. "0666"). Erlaubt allen Benutzern Lese- und Schreibzugriff.

remoteDirectory

Verzeichnis auf dem SFTP-Server, in dem die Logs gespeichert werden.

Wenn das Zielverzeichnis z. B. /user/siem/logs lautet und der Chroot auf /user gesetzt ist, muss remoteDirectory auf /siem/logs gesetzt werden!

keepLocalCopy

Wenn false, werden alle Logs außerhalb der TTL gelöscht, sobald sie erfolgreich übertragen wurden. Bei true bleibt eine Kopie lokal auf dem Logger erhalten.

SSH-Zugangsdaten (sftp.ssh)

Konfigurationswert

Beschreibung

Hinweise

username

Benutzername für die SSH-Verbindung zum SFTP-Server.

password

Passwort zur Authentifizierung. Kann leer bleiben, wenn ein SSH-Schlüssel verwendet wird.

Dieses Feld können Sie leer lassen, wenn ein Schlüssel verwendet werden.

ip

IP-Adresse des SFTP/SSH-Servers.

port

Port für die SSH-Verbindung. Standard ist 22, falls leer gelassen.

Wenn Sie dieses Feld leer lassen, wird der Standardport 22 genutzt.

privateKeyPath

Pfad zum privaten SSH-Schlüssel. Nur erforderlich, wenn eine Schlüssel-basierte Authentifizierung genutzt wird.

Wenn Sie ein Passwort verwenden, müssen Sie hier keine Anpassungen vornehmen.

privateKeyPassphrase

Passwort für den privaten Schlüssel, falls dieser verschlüsselt ist.

knownHostsPath

Pfad zur Datei known_hosts zur Verifikation des SFTP-Servers. Wird dieses Feld leer gelassen, entfällt die Hostprüfung.

Wenn Sie diese Angabe leer lassen, wird kein Host-Check durchgeführt und angenommen, dass der richtige Server angegeben wurde. Es muss nicht die von SSH angelegte 'known_hosts'-Datei sein, wenn nur dieser Host zugelassen werden soll, jedoch muss das Format dem der "originalen" Datei entsprechen.

Fügen Sie den Code in Ihrer /opt/enginsight/loggernaut/config.json hinzu und passen Sie die Konfiguration wie oben beschrieben an.

Beispielkonfiguration (ohne Verschlüsselung) {

    "api": {...},
    "siem": {...},
    ...,
    "backup": {
        "strategy": "sftp",
        "sftp": {
            "permissions": "0666",
            "remoteDirectory": "/logs",
            "keepLocalCopy": false,
            "ssh": {
                "username": "siem",
                "password": "****",
                "ip": "****",
                "port": 22,
                "privateKeyPath": "/opt/enginsight/loggernaut/ssh/id_ed25519",
                "privateKeyPassphrase": "*****",
                "knownHostsPath": "/root/.ssh/known_hosts"
            }
        }
    }
}

Beispielkonfiguration mit AGE-Verschlüsselung Loggernaut unterstützt aktuell ausschließlich das Verschlüsselungspaket age. Generieren eines AGE-Schlüsselpaares

Sie können das benötigte Schlüsselpaar wie folgt erzeugen:

mit AGE-CLI:

age-keygen -o key.txt

mit Loggernaut:

./loggernaut -generate-age-keys

Dabei wird ein Public-/Private-Key-Paar erzeugt. Nur der öffentliche Schlüssel kommt in die Konfiguration. Der private Schlüssel muss sicher aufbewahrt werden, um Backups später entschlüsseln zu können. Backup mit Verschlüsselung {

  "backup": {
    "strategy": "sftp",
    "sftp": {
      "permissions": "0666",
      "remoteDirectory": "/logs",
      "keepLocalCopy": true,
      "ssh": {
        "username": "siem",
        "ip": "192.168.1.100",
        "port": 22,
        "privateKeyPath": "/opt/enginsight/loggernaut/ssh/id_ed25519",
        "knownHostsPath": "/root/.ssh/known_hosts"
      }
    },
    "encryption": {
      "package": "age",
      "publickey": "age1ms3c0gmdxakx3lxzlp422g78lju4pmrse0rp6jl8lpu696yvea7qttzsl0"
    }
  }
}

Technische Hinweise zur Verschlüsselung:

Aktuell wird ausschließlich das AGE-Verschlüsselungspaket unterstützt.
- Ein gültiger AGE Public Key beginnt immer mit age und enthält nur Zeichen aus [a-z0-9]. Beispiel: age1ms3c0gmdxakx3lxzlp422g78lju4pmrse0rp6jl8lpu696yvea7qttzsl0

Alle Organisationen auf einer SIEM-Instanz verwenden denselben Public Key zur Verschlüsselung. Es gibt keine org-spezifische Schlüsselkonfiguration, und alle Backups werden beim gleichen S3-Provider abgelegt. Die Entschlüsselung erfolgt mithilfe des zugehörigen Private Keys, der zentral gepflegt werden muss.

Starten Sie abschließend den Loggernaut neu, um die Konfigurationen zu übernehmen. sudo systemctl restart ngs-loggernaut

S3-Backup

Nutzen Sie diese Backup-Option, um Backupdateien automatisiert und sicher in einem S3-kompatiblen Speicher abzulegen. Die folgende Anleitung zeigt, wie Sie den Loggernaut entsprechend konfigurieren.

Benötigte Informationen vom S3-Provider
Konfigurationswert
Beschreibung
endpoint
Die URL des Speicherendpunkts. Dieser kann je nach Anbieter variieren, folgt jedoch oft dem Schema: https://(region).(s3/storage).(hostingprovider).(tld)
accessKeyId
Die API-Zugangskennung zur Authentifizierung.
accessKeySecret
Der geheime Schlüssel zum API-Zugang.
region
Die Region des Speicherdienstes (z. B. eu-central).
Entscheiden Sie vor der Konfiguration, ob Sie eine Verschlüsselung der Backups wünschen und definieren Sie ein geeignetes Bucket-Prefix.
1. Verschlüsselung Sie haben die Möglichkeit, Backupdateien vor dem Upload clientseitig zu verschlüsseln. Unterstützt wird aktuell ausschließlich das AGE-Verschlüsselungsverfahren. Alternativ kann die Verschlüsselung auch deaktiviert werden.
2. Bucket-Prefix definieren Jeder Kunde erhält automatisch einen eigenen Bucket. Der Name ergibt sich aus folgendem Schema:
  <bucketPrefix>-<orgId>
  Beispiel: example-siem-backup-1234abcd
  Loggernaut prüft beim Start automatisch, ob das verwendete Prefix ein gültiger Bucketname ist.

Beispielkonfigurationen

Backup ohne Verschlüsselung

{

  "backup": {
    "strategy": "s3",
    "s3": {
      "endpoint": "eu-central.storage.s3provider.example",
      "accessKeyId": "XXXXXXXXXXXXXXXX",
      "accessKeySecret": "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX",
      "bucketPrefix": "example-siem-backup",
      "region": "eu-central",
      "keepLocalCopy": true
    }
  }
}

Wird kein encryption-Block angegeben, erfolgt das Backup ohne Verschlüsselung!

Verschlüsselung explizit deaktivieren

Alternativ kann die Verschlüsselung explizit ausgeschaltet werden:

"encryption": {
  "package": "none"
}

Auch ein leerer String ist möglich:

"package": ""

Backup mit AGE-Verschlüsselung Loggernaut unterstützt aktuell ausschließlich das Verschlüsselungspaket age.

Generieren eines AGE-Schlüsselpaares
Sie können das benötigte Schlüsselpaar wie folgt erzeugen:
mit AGE-CLI:
```
age-keygen -o key.txt
```
mit Loggernaut:
```
./loggernaut -generate-age-keys
```
Dabei wird ein Public-/Private-Key-Paar erzeugt. Nur der öffentliche Schlüssel kommt in die Konfiguration. Der private Schlüssel muss sicher aufbewahrt werden, um Backups später entschlüsseln zu können.

Konfiguration mit Verschlüsselung

{
  "backup": {
    "strategy": "s3",
    "s3": {
      "endpoint": "eu-central.storage.s3provider.example",
      "accessKeyId": "XXXXXXXXXXXXXXXX",
      "accessKeySecret": "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX",
      "bucketPrefix": "example-siem-backup",
      "region": "eu-central",
      "keepLocalCopy": true
    },
    "encryption": {
      "package": "age",
      "publickey": "age1ms3c0gmdxakx3lxzlp422g78lju4pmrse0rp6jl8lpu696yvea7qttzsl0"
    }
  }
}

Technische Hinweise zur Verschlüsselung:

Aktuell wird ausschließlich das AGE-Verschlüsselungspaket unterstützt.
- Ein gültiger AGE Public Key beginnt immer mit age und enthält nur Zeichen aus [a-z0-9]. Beispiel: age1ms3c0gmdxakx3lxzlp422g78lju4pmrse0rp6jl8lpu696yvea7qttzsl0

Erweiterte Optionen
Option
Beschreibung
keepLocalCopy:true
Gibt an, ob zusätzlich eine lokale Kopie der Backupdateien gespeichert werden soll (Standard: true).
"skipSSL": true
Wenn auf true gesetzt, wird HTTPS deaktiviert. Nur für interne Netze empfohlen!

skipSSL sollte nicht aktiviert werden, wenn Backups über das öffentliche Internet übertragen werden.

Full-Text Search Datalake

Die Full-Text Search ermöglicht es Ihnen, nach beliebigen Texten in ihren Logs zu suchen, um relevante Informationen noch schneller zu finden. Durchsuchen Sie Logs nun gezielt nach Inhalten, ohne dabei betreffende Felder angeben zu müssen. Wodurch nun auch die Ausgabe felderübergreifender Ergebnisse möglich ist.

Bedenken Sie bitte, dass die Aktivierung der Full-Text Search die Größe des Indexes stark vergrößern kann! Sein Sie sich im Vorhinein darüber bewusst und stellen Sie ausreichend Ressourcen zur Verfügung.

Aktivierung bei bestehenden Accounts

Als bestehender Enginsight Nutzer müssen Sie zur Datei /opt/enginsight/loggernaut/config.json navigieren und auf der JSON-Root-Ebene den Eintrag "fullTextSearch": true hinzufügen.
Starten Sie anschließend den Loggernaut neu, um die Änderungen zu übernehmen.

Beachten Sie zwingend, dass nur Logs, die nach der Aktivierung an das SIEM gesendet werden, über die Freitextsuche auffindbar sind. Alte Logs sind nicht durchsuchbar!

Deaktivierung nach Neuinstallation

Falls Sie die Full-Text Search deaktivieren möchten, nehmen Sie einfach die folgende Konfiguration vor:

in der config.json den Eintrag "fullTextSearch": false setzen.

Backup-Log TTL

Die Backup-Log Time-to-Live (TTL) kann separat konfiguriert werden, um die Lebensdauer von Backup-Logs zu steuern. Verwenden Sie die folgende JSON-Konfiguration, um die TTL für Ihre Organisation festzulegen:

{
    "backup": {
        "strategy": "remove",
        "ttl": {
            "<org>": <ttlInTagen>
        }
    }
}

Ersetzen Sie <org> durch den Namen Ihrer Organisation und <ttlInTagen> durch die gewünschte Zeitdauer in Tagen, nach der die Backup-Logs automatisch entfernt werden sollen.

Beispielkonfiguration

Diese Konfiguration ermöglicht eine präzise Verwaltung der Backup-Log-Lebensdauer gemäß Ihren Anforderungen.

Im folgenden finden Sie eine entsprechende Beispielkonfiguration für die TTL-Logfiles:

{
    // Obligatorische Felder in der Konfiguration (irrelevant für TTL)
    "api": {
        "url": "",
        "accessKeySecret": "",
        "accessKeyId": ""
    },
    "siem": {
        "indecees": [
            ""
        ],
        "basicAuth": {
            "username": "",
            "password": ""
        }
    },
    // TTL für rohe Backup Logs auf dem Management Server
    "backup": {
        "strategy": "<remove|sftp>",
        "ttl": {
            "<orgid>": 90 // Angabe in Tagen
        }
    },
    // TTL von durchsuchbaren Logs im Solr-Cluster
    "ttl": {
        "<orgid>": 30 // Angabe in Tagen
    }
}

Bitte beachten Sie, dass die TTL (Time to Live) nur die Logs auf dem Management Server betrifft. Die Logs auf dem SFTP-Server werden vom Logger nicht mehr bearbeitet und bleiben daher unverändert. Weiterhin gilt die Anpassung nur für die jeweilige Organisation und muss im Falle pro Organisation durchgeführt werden.

Stellen Sie bitte sicher, dass Sie die Konfiguration entsprechend anpassen!

Geosplitting

Geosplitting in einem SIEM ermöglicht es Ihnen, mehrere SIEM-Cluster mit On-Premise zu nutzen, wodurch Datenhoheit und Performance durch die ausschließliche Nutzung von nur einem einzelnen Kunden gewährleistet werden.

Geosplitting ermöglicht es Ihnen bei Bedarf auch mehrere Unterorganisationen in ein neues Cluster zu verschieben. Weiterhin haben Sie auch die Möglichkeit mehrere Cluster zu erstellen.

Konfigurieren Sie den Loggernaut wie gewohnt.
Fügen Sie Ihrer Konfiguration den Punkt: "alternatives" hinzu und setzen Sie die folgenden Anweisungen um:

"siem": {
    "management": {
      "organisation": "organisation"
    },
    "alternatives": [{
      "organisations": ["organisation1", "organisation2"],
      "basicAuth": {
        "username": "****",
        "password": "****"
      },
      "url": "url",
      "numShards": 2,
      "replicationFactor": 1,
      "management": {
        "organisation": "organissation"
      }
    }],
    "basicAuth": {
      "username": "*****",
      "password": "*****"
    },
    "url": "url"
  },

Geben Sie unter den darunter folgenden Punkten die jeweiligen Informationen an:

"organisations" Alle dem Cluster zugehörigen Organisationen.
"management" Die Management-Organisation innerhalb des neuen Clusters darf den Zustand der anderen Organisationen einsehen. Dabei muss eine Organisation gewählt werden, die auch unter "alternatives" vorhanden ist. Ansonsten entspricht alles dem normalen SIEM-Setup.

Beachten Sie zwingend, dass keine Organisation doppelt vorkommt, also nicht gleichzeitig in zwei Clustern existiert. Alle Organisationen, die nicht in die Alternative verschoben wurden, verbleiben im Management-Cluster.

PreviousField Level Encryption NextTLS Verschlüsselung Datenbank

Last updated 1 month ago

Was this helpful?