Loggernaut-Konfigurationen

SFTP Backup Server

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.

Konfiguration des SFTP Backup Servers

  1. Fügen Sie den Code in Ihrer /opt/enginsight/loggernaut/config.json wie folgt hinzu.

{
    "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"
            }
        }
    }
}
  1. Passen Sie die Standardeinstellungen wie folgt an:

Individuelle Anpassungen:

  • strategy

    • local: Die Logs werden lokal auf dem Loggernaut gespeichert.

    • remove: Alle Logs außerhalb der TTL werden gelöscht.

    • sftp: Nutzung eines SFTP-Servers (Das SFTP-Objekt muss in diesem Fall entsprechend konfiguriert werden).

sftp.permissions: Geben Sie hier die Dateiberechtigungen im Unix-Stil ("0666") und erlauben Sie somit allen Benutzern vollen Lese- und Schreibzugriff.

sftp.remoteDirectory: Geben Sie den Verzeichnispfad an, in dem die Logs gespeichert werden sollen.

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.keepLocalCopy: Wenn auf 'false' gesetzt, werden alle Logs außerhalb der TTL auf dem Logger gelöscht, sobald sie auf den SFTP-Server übertragen wurden.

sftp.ssh.username: Geben Sie den Benutzername für den SFTP-SSH-Nutzer an.

sftp.ssh.password: Geben Sie Ihr SSH-Passwort für den SFTP-Nutzer an.

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

sftp.ssh.ip: Geben Sie hier die IP-Adresse des SFTP/SSH-Servers an.

sftp.ssh.port: Geben Sie hier den Port an, auf dem der SFTP/SSH-Server läuft.

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

sftp.ssh.privateKeyPath: Geben Sie hier den Pfad zum privaten SSH-Schlüssel an.

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

sftp.ssh.privateKeyPassphrase: Geben Sie (falls vorhanden) hier das Passwort für den privaten Schlüssel an.

sftp.ssh.knownHostsPath: Geben Sie hier den Pfad zu den bekannten Hosts an, um zu überprüfen, ob der SFTP-Server der richtige ist.

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.

  1. Starten Sie abschließend den Loggernaut neu, um die Konfigurationen zu übernehmen.

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

  1. 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.

  2. 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.

  1. Konfigurieren Sie den Loggernaut wie gewohnt.

  2. 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"
  },
  1. 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.

Last updated