© alphaspirit, 123RF

Mit der Zahl der Server wächst der Umfang von Logfiles und damit das Risiko, darin sicherheitsrelevante Einträge zu übersehen. Einen Ausweg weisen Lösungen aus der Sparte Security Information and Event Management (SIEM), die es erleichtern, Zusammenhänge in einem Wust aus Informationen zu erkennen.

Linux beherrscht die Log-Weiterleitung beziehungsweise das Remote Logging – und damit eine der Voraussetzungen für die externe Loganalyse – schon seit langer Zeit. Von Anfang an ging es dabei um Sicherheit: Wenn ein Angreifer ein System kompromittiert, versucht er höchstwahrscheinlich auch die Syslogdateien zu manipulieren oder zu löschen, um seine Spuren zu verwischen. Wenn aber der Administrator einen Loghost im Einsatz hat, ist es weniger wahrscheinlich, dass auch der den Hackern in die Hände fällt. Dadurch bleiben nach einem Angriff die Meldungen auf dem Loghost analysierbar.

Warum SIEM?

Sobald mehrere Server zu administrieren sind, wird es immer umständlicher, Gesamtstatistiken zu generieren oder Server-übergreifende Probleme zu erkennen, selbst wenn alle nötigen Informationen vorliegen. Wegen der schieren Quantität der Information aus unterschiedlichen Quellen muss sich der Admin auf Tools stützen, die eine Zusammenschau aller Logs in Echtzeit ermöglichen und ihm bei der Auswertung helfen.

SIEM vereint Realtime Monitoring und sofortige Benachrichtigung bei Regelverletzungen einerseits und Langzeit-Archivierung für Analyse und Report andererseits. Es ermöglicht so

• den Zugriff auf die Logfiles auch ohne Adminstratorrechte am Produktivsystem,
• die Akkumulation der Logfiles aller Rechner an einer Stelle,
• die Analyse der Logs nebst Unterstützung bei der Auffindung von Korrelationen,
• die automatische Benachrichtigung bei Regelverletzungen,
• das Erstellen regelmäßiger Reports über Netzwerk, Betriebssystem, Datenbanken und Applikationen,
• ein Monitoring des Verhaltens der Benutzer.

Es sind zahlreiche SIEM-Produkte großer und kleiner Hersteller auf dem Markt. Die Kosten richten sich meist nach dem Umfang der Logs. Graylog [1] ist eine Open-Source-Alternative, die viele Logformate verarbeitet. Ab einem Volumen von mehr als 5 GByte pro Tag kostet es allerdings Lizenzgebühren.

Installation und Konfiguration von Graylog gestalten sich recht einfach. Es ist eine Java-Applikation, geht aber mit den Ressourcen schonend um. In Mongo DB speichert es die Metadaten und in Elasticsearch deponiert es die gesammelten Logs. Graylog besteht aus Server und Webinterface, die über eine REST-Schnittstelle kommunizieren (Abbildung 1).

Abbildung 1: Graylog besteht aus Webinterface und Server sowie Mongo DB und Elasticsearch.

Installation per Yum

Voraussetzung für die Installation von Graylog 2.4 – in diesem Beispiel unter Centos 7 – sind Java ab Version 1.8, Elasticsearch 5.x [2] und Mongo DB 3.6 [3]. Sofern noch nicht vorhanden, empfiehlt es sich, zuerst Java zu installieren:

yum install java-1.8.0-openjdk-headless.x86_64

Dies und die folgenden Kommandos funktionieren nur als Root oder per Sudo. Anschließend richtet der Admin Elasticsearch und Mongo DB ein. Dafür erzeugt er in »/etc/yum.repos.d« je eine Datei mit dem Namen »elasticsearch.repo« beziehungsweise »mongodb.repo«, die so aussehen sollen, wie in den Listings 1 und 2 gezeigt. Dann installiert er den RPM-Key:

[elasticsearch-5.x]
name=Elasticsearch repository for 5.x packages
baseurl=https://artifacts.elastic.co/packages/5.x/yum
gpgcheck=1
gpgkey=https://artifacts.elastic.co/GPG-KEY-elasticsearch
enabled=1
autorefresh=1
type=rpm-md

01 [mongodb-org-3.0]
02 name=MongoDB Repository
03 baseurl=http://repo.mongodb.org/yum/redhat/$releasever/mongodb-org/3.0/x86_64/
04 gpgcheck=0
05 enabled=1

rpm --import https://artifacts.elastic.co/GPG-KEY-elasticsearch

Abschließend kommen die Pakete für Mongo DB und Elasticsearch an die Reihe:

yum install elasticsearch
yum -y install mongodb-org

Es folgt die Graylog-Installation:

rpm -Uvh https://packages.graylog2.org/repo/packages/graylog-2.4-repository_latest.rpmyum install graylog-server

Damit sind die grundlegenden Komponenten eingerichtet.

Konfigurieren

Die Konfiguration beginnt der Admin am besten mit Elasticsearch, in dessen Konfigurationsfile er insbesondere den Parameter »cluster.name« vergibt. Das einzige Konfigurationsfile von Graylog selbst heißt »server.conf« und liegt im Verzeichnis »/etc/graylog«. Die Datei benutzt das Character-Encoding ISO 8859-1/Latin-1. Sie ist umfangreich, beginnt mit der Definition der Masterinstanz und endet mit dem verschlüsselten Passwort des Graylog-Rootusers. Die wichtigsten Parameter sind jene für die Definition von Mail, TLS und des Root-Passworts.

Damit sich Graylog überhaupt starten lässt, müssen die Parameter »password_secret« und »root_password_sha2« gesetzt sein. Den Parameter »password_secret« sollte der Admin mit einem String von mindestens 64 Zeichen Länge belegen. Diesen String verwendet Graylog für das Salting und zur Kodierung des Passworts. Der Befehl »pwgen« erzeugt ein Passwort

pwgen -N 1 -s 100

das »sh256sum« danach verschlüsselt:

echo -n Password | sha256sum

Das verschlüsselte Passwort bekommt dann der Parameter »root_password_sha2« zugewiesen. Tabelle 1 gibt eine Zusammenfassung der wichtigen Parameter.

Windows-Server anbinden

Unter Windows lassen sich die Logfiles nicht wie unter Linux durch eine einfache Konfiguration weiterleiten. Der Versand erfolgt dort durch einen Agent. Davon gibt es mehrere, Graylog selbst empfiehlt zwei: Graylog Sidecar oder Nxlog, den das vorliegende Beispiel verwendet. Der Agent liest die Logdateien von Windows und den Applikationen und gibt sie an einen definierten Graylog-Port weiter. Die Agents bedürfen dafür einer eigenen Konfiguration (siehe weiter unten).

Als ersten Schritt, um einen Windows-Server an Graylog anzubinden, muss der Admin einen Input in Graylog selbst definieren. Unter »System | Input« ist »GELF UDP« zu selektieren und danach »Launch new input« anzuklicken. Das sich daraufhin öffnende Fenster hat sieben Felder, die selbsterklärend sind. Im Beispiel für diesen Artikel lauscht Graylog auf Port 1515 (Abbildung 2).

Abbildung 2: Definieren eines Inputs für Graylog.

Der Agent Nxlog ist Open Source und versteht die Standards RFC 3164, die Logformate der RFC 5424 bis 5426 und viele mehr, darunter CSV, GELF, Json oder XML. Der Agent liest die Logs und schickt die Daten an den Graylog-Port. Die beste Lösung zum Sammeln der Logdaten ist »rsyslogd« [4]. Windows unterstützt dies aber nicht. Deshalb muss man dem Agent mitteilen, in welchem Format die Daten bei ihm ankommen und in welchem Format er sie weiterleiten soll.

Die Festlegungen dazu schreibt der Anwender in die Konfigurationsdatei von Nxlog, die Input und Output des Nxlog definiert. Für beides lassen sich vorgefertigte Module nutzen, es sind aber auch selbst definierte In- oder Output-Formate möglich. Dazu später mehr.

Für die Installation von Nxlog führt der Admin die heruntergeladene Exe-Datei auf dem Windows-Server aus. Bei der Installation werden unter »C:\Program Files (x86)« ein Verzeichnis »nxlog« und darunter ein Verzeichnis »conf« erzeugt, in dem die Konfigurationsdatei liegt. In ihr kann der Admin auch das Modul »pm_buffer« einsetzen. Es puffert die Daten auf der Festplatte, sollte Graylog einmal nicht erreichbar sein. Die Config-Datei sieht damit so aus wie in Listing 3. Abschließend lässt sich der Nxlog-Dienst unter Windows mit »sc start nxlog« starten. Ab diesem Zeitpunkt kann der Nutzer die ankommenden Logeinträge im Graylog unter »System | Input (Windows Input) | Show recieved messages« gelistet finden (Abbildung 3).

01 define ROOT C:\Program Files (x86)\nxlog
02 Moduledir %ROOT%\modules
03 CacheDir %ROOT%\data
04 Pidfile %ROOT%\data\nxlog.pid
05 SpoolDir %ROOT%\data
06 LogFile %ROOT%\data\nxlog.log
07 <Extension gelf>
08     Module xm_gelf
09     </Extension>
10 <Input in>
11     # Für windows vista/2008 und höher verwenden:
12     Module      im_msvistalog
13
14     # Für windows Windows XP/2000/2003 verwenden:
15     #   Module      im_mseventlog
16 </Input>
17
18 <Processor buffer>
19           Module pm_buffer
20           MaxSize 102400 # 100 MByte Puffer auf der Festplatte
21           Type disk
22 </Processor>
23
24 <Output out>
25     Module      om_udp
26     Host        GraylogServerName
27     Port        15150
28     OutputType  GELF
29 </Output>
30
31 <Route 1>
32     Path        in => out
33 </Route>

Abbildung 3: Neu eintreffende Meldungen in Graylog.

Danach ist es möglich, mit der Graylog-Suche nach bestimmten Ereignissen zu forschen. So könnte es von Interesse sein, nach misslungenen Logins im Active Directory zu fahnden, da diese ein Hinweis auf eine Brute-Force-Attacke sein können. Auf [5] lassen sich die Event-IDs aller Events recherchieren, im vorliegenden Beispiel eines misslungenen Login ist das die Event-ID 4625. Mit einer Suche danach kann der Admin alle misslungenen Loginversuche mit den zugehörigen Informationen wie der IP-Adresse des Clients auflisten (Abbildung 4).

Abbildung 4: Fehlgeschlagene Anmeldeversuche am Active Directory.

Wer weitere Informationen in grafischer Form braucht, klappt das Feld »TargetUserName« auf und klickt »Quick values« an. Das Ergebnis ist eine Infografik nebst Liste, die die häufigsten Logins zeigt. Abbildung 4 listet 237 Versuche am Active Directory mit dem Namen »SRR-NB-01$« und 121 Versuche mit dem Loginnamen »razorblader«. Diese Usernamen sind im System unbekannt, es handelt sich daher wahrscheinlich um echte Attacken. Dagegen stammen 132 Versuche (grüner Pfeil) von einem registrierten User.

Nxlog für jedes Format

In speziellen Fällen – etwa bei Logs, die keinen Standardregeln folgen – kann es auch mal notwendig sein, dass der Agent Nxlog selbst eine Logdatei überwacht, konvertiert und anschließend an den Graylog-Server sendet. Das folgende Beispiel setzt im Input-Teil das Modul »im_file«, ändert den Inhalt des Log und übergibt alles an den Output. Das Tag »Output out« legt dabei fest, ob das Ergebnis per UDP oder TCP zu Graylog gelangt. Die Syntax der Konfiguration ähnelt der Perl-Syntax (Listing 4).

01 <Extension gelf>
02     Module      xm_gelf
03 </Extension>
04
05 <Input in>
06     Module      im_file
07     File        C:\Program Files (x86)\App\log\app.log"
08
09 # Falls Datum und Zeit im Logfile vorhanden sind, diese extrahieren.
10 Sind Datum und Uhrzeit nicht vorhanden, nehmen wir die Systemzeit.
11 Exec    if $raw_event =~ /(\d\d\d\d\-\d\d-\d\d \d\d:\d\d:\d\d)/
12 $EventTime = parsedate($1);
13
14 # Normaler Weise ist der Hostname per default gesetzt, sicherheitshalber kann er
15 so eingetragen werden.
16     Exec        $Hostname = 'myhost';
17 # Jetzt wird die Art der Meldung(der severity level) gesetzt. Im Beispiel wird
18 der Standard-syslog-Werte benutzt.
19 # ALERT: 1, CRITICAL: 2, ERROR: 3, WARNING: 4, NOTICE: 5, INFO: 6, DEBUG: 7
20     Exec        if $raw_event =~ /ERROR/ $SyslogSeverityValue = 3; \
21                 else $SyslogSeverityValue = 6;
22 # Der Name der Datei wird auch mitgeschickt
23     Exec        $FileName = file_name();
24 # Die Variable SourceName wird per Default mit 'NXLOG' gesetzt. Um den
25 Applikationsnamen mitzuschicken, sollte statt dessen $SourceName = 'AppName'
26 gesetzt werden.
27     Exec        $SourceName = ' AppName';
28 </Input>
29
30 <Output out>
31     Module      om_udp
32     Host        GraylogServerName
33     Port        12201
34     OutputType  GELF
35 </Output>
36
37 <Route r>
38     Path        in => out
39 </Route>

Linux-Server anbinden

Wie schon erwähnt kennt Linux die Log-Weiterleitung beziehungsweise das Remote Logging schon lange. Unter Linux nimmt der Systemdaemon Syslogd alle Meldungen entgegen, sortiert sie nach Dringlichkeit und Quelle und archiviert sie in einer oder mehreren Protokolldateien im Verzeichnis »/var/log«.

Der Syslogd kennt aber nur UDP. Rsyslog, ein späteres Projekt aus dem Jahr 2004, ist eine Erweiterung und setzt RELP (Reliable Event Logging Protocol) ein. RELP baut auf TCP auf und ist daher auch mit TLS benutzbar. Eine wichtige Erweiterung von Rsyslog gegenüber Syslog ist, dass es lokale Nachrichten puffern kann, falls der entfernte Server nicht empfangsbereit ist. Das Beispiel nutzt Rsyslog.

Die Haupt-Konfigurationsdatei findet sich normalerweise in »/etc« unter dem Namen »syslog.conf«, ebenfalls in »/etc« residiert das Verzeichnis »/etc/rsyslog.d«. Dort erzeugt der Admin eine neue Datei wie in Listing 5.

01 *.* @host.domain.org:1516;RSYSLOG_SyslogProtocol23Format
02
03 *.* @@host.domain.org:1516;RSYSLOG_SyslogProtocol23Format

Der Ausdruck »*.*« bedeutet Weiterleitung von allem, was der Syslogdeamon verarbeitet. Das Zeichen »@« steht für UDP-Protokoll auf dem Transportweg. Achtung: Dieses Protokoll ist für Verschlüsselung ungeeignet. »@@« meint, dass TCP für den Transport zu benutzen ist. Schließlich steht »RSYSLOG_SyslogProtocol23Format:« für eine Built-in-Funktion, die das Format bestimmt.

Nun soll Graylog auch etwas empfangen können. Unter »System/Input | Syslog TCP« klickt der Admin auf »Launch new input« und füllt das Formular aus. Dessen wichtigste Parameter zeigt Listing 6.

allow_override_date: true
bind_address: 0.0.0.0
expand_structured_data: true
force_rdns: false
max_message_size: 2097152
override_source: <empty>
port: 1516
recv_buffer_size: 1048576
store_full_message: true
tcp_keepalive: true
tls_cert_file: /Pfad...
tls_client_auth: disabled
tls_client_auth_cert_file: <empty>
tls_enable: true
tls_key_file: /Pfad...
tls_key_password: ********
use_null_delimiter: false

Man in the Middle ärgern

Befindet sich ein Server oder ein Gerät außerhalb des internen Netzwerks, ist die Verschlüsselung der Kommunikation ein Muss. Graylog, Rsyslog und Nxlog beherrschen die verschlüsselte Kommunikation. Auf Graylog muss der Admin beim Einrichten eines Inputs den Parameter »tls_enable« auf »true« setzen und die Parameter »tls_cert_file« und »tls_key_file … « entsprechend ausfüllen.

Unter Linux sollte der Administrator das TCP-Protokoll (»@@«) wählen und alle notwendigen Parameter setzen, die für die Verschlüsselung wichtig sind. Die Reihenfolge der Parameter ist nicht beliebig. Das Konfigurationsfile für das Senden zeigt Listing 7.

01 $DefaultNetstreamDriver gtls
02 $DefaultNetstreamDriverCAFile /Pfad/cert.pem
03 $ActionSendStreamDriver gtls # Verwende Gtls-Netstream-Treiber
04 $ActionSendStreamDriverMode 1 # Unbedingt TLS
05 $ActionSendStreamDriverAuthMode anon # Client-Authentifizierung ist nicht nötig
06 *.* @@host.domain.ac.at:1516;RSYSLOG_SyslogProtocol23Format

Hinweis: Der »SendStream«-Treiber »gtls« ist im Rsyslog-Gnutls-Paket enthalten. Unter Windows mit Nxlog sind für sicheres Senden auch ein paar Zeilen im Config-File notwendig. Es ist das Module »om_ssl« im Output-Tag zu definieren und der Pfad zum CA-File ist anzugeben (Listing 8).

01 <Output out>
02    Module om_ssl
03    Host GraylogServerName
04    Port 1516
05    CAFile %CERTDIR%/filename.crt
06    AllowUntrusted FALSE
07 </Output>

Apache anonym an Bord

Viele Applikationen erzeugen Logfiles unabhängig von Rsyslog. Die Einbindung der meisten solcher Logs von Applikationen in Rsyslog ist grundsätzlich möglich, erfordert aber umfangreiche Konfigurationen auf beiden Seiten und auch die Kenntnis, wie das Log innerhalb der spezifischen Applikation an Rsyslog geschickt werden kann.

Graylog löst das Problem mit wenigen Schritten, die dieser Beitrag beispielhaft mit dem Apache-Log demonstriert. Auf Graylog wird ein »GELF TCP«-Input eingerichtet. Der Admin konfiguriert auf dem Server der Quelle Apache, indem er ein Logformat definiert und es mit Netcat weiterleitet.

Die DSGVO erlaubt Unternehmen nicht, die IP-Adressen von Besuchern einer Website ohne deren Zustimmung oder “berechtigtes Interesse” zu speichern (Art. 5). Da es im Fall von SIEM auch um Archivierung der Logdaten geht, empfiehlt es sich, die IP-Adressen von Beginn an zu anonymisieren.

In Graylog besteht die Möglichkeit, die IP-Adressen mittels Extractor zu anonymisieren: Im »System/Input« unter »Input | Manage extractors | Add exrtractor | Get started | Load Message« das Feld »IP-Adresse« auswählen. Als Extractor-Type »Regular Expression« wählen. Im vorliegenden Fall das Feld »Source_IP« und das sich öffnende Formular ausfüllen. In das Feld »Regular Expression« den String aus Listing 9 einfügen (Abbildung 5).

01 Parameter             | Wert
02 ----------------------------------------------------
03 Regular expression    | ((25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)(?:\.|$)){4}   # sucht nach IP-Adresse
04 Condition             | Always try to extract
05 Always try to extract | IP_Adresse
06 Extraction strategy   | Cut
07 Extractor title       | Anonym-ip
08 Add converter         | <empty>
09 Anonymize IPv4 addresses by replacing last octet                                   | true

Abbildung 5: Einstellungen für das Anonymisieren der IP-Adressen.

Mein eigener Agent

Einige Applikationen – etwa das »listener.log« oder das »alert.log« von Oracle – erzeugen sehr eigentümliche Logfiles, denen unter anderem Informationen wie Hostname und Message fehlen. Ein selbst geschriebenes Skript (Listing 10), das diese Felder vor dem Senden hinzufügt, verhindert Missverständnisse zwischen Sender und Empfänger. Das Skript liest die originale Logdatei und leitet den Inhalt weiter.

01 #!/bin/bash
02 #set -x
03 file=/tmp/listner.log
04 if [ ! -e "$file" ]; then
05     touch /tmp/listner.log
06 fi
07 tail -n 0 -F /db/oraclese/product/diag/tnslsnr/pics-db11/listener/trace/listener.log | while read LINE
08  do
09         echo "\"host:\" \"picsdb\", \"message:\" \"$LINE\"" >>         /tmp/listner.log
10
11         if [ $? = 1 ]
12         then
13                 echo -e "$LINE  ... \n found on $HOSTNAME" | mail -s "Something's wrong on $(hostname)" bf@onb.ac.at
14         fi
15 done &
16 tailf /tmp/listner.log | nc -u dlogger.onb.ac.at 12202

Auf der Graylog-Seite ist nur noch ein »GELF TCP«-Input zu implementieren – und schon sind die Logeinträge in Graylog zu sehen (Abbildung 6). Der Admin richtet dann noch einen Alert ein, der Benachrichtigungen sendet, wenn Graylog Fehlermeldungen empfängt (die gewöhnlich mit dem String »ORA« beginnen).

Abbildung 6: Oracle-Logeinträge in Graylog.

Schritte zur Korrelation

Eine der wichtigsten Aufgaben von SIEM ist die Korrelation. Dafür sind die Felder einheitlich zu strukturieren und zu benennen. HTTP-Codes beispielsweise haben in verschiedenen Systemen unterschiedliche Bezeichnungen, etwa »http_response_code« in einem System, in einem anderen System sind sie im Feld »status_code« enthalten. Graylog verfügt über ein wichtiges Werkzeug, das die Feldnamen vereinheitlicht. Mit dem Extraktor unter »System | Input | Manage extractors« lassen sich die Feldbezeichnungen in einheitliche Namen konvertieren.

Ebenso wichtig ist es, dass Datum und Uhrzeit der Logeinträge für alle Rechner einheitlich sind. Nur so lassen sich etwa alle Fehlermeldungen des gesamten Enterprise-Systems finden, die innerhalb einer bestimmten Zeitspanne aufgetreten sind. Auch hier hilft der oben beschriebene Extraktor. Er kann die auf den Rechnern des Systems extrahierten Datums- und Zeitangaben in ein einheitliches Timestamp-Format konvertieren. Abbildung 7 zeigt, wie einfach es anschließend ist, Errors einer bestimmten Zeitspanne für das gesamte Enterprise-System zu finden.

Abbildung 7: System-übergreifende Suche nach Logeinträgen aus einem bestimmten Zeitraum.

In Abbildung 7 wird das Feld »source« mit einer Wildcard verknüpft und den Messagelevels 0 bis 4 zugeordnet. Unter Linux sind die Level von 0 bis 7 durchnummeriert: »0« bedeutet Emergency, »1« Alert, »2« Critical, »3« Error, …. »7« Debug. Unter Windows sind die Level dagegen anders organisiert: Die Messagelevel, die denen unter Linux entsprechen, speichert Graylog in dem Feld »Severity level« .

Alarm

SIEM legt viel Wert auf Sicherheit. Graylog bietet die Möglichkeit, Daten verschiedenster Quellen zu korrelieren, um quasi die Nadel im Heuhaufen zu finden. Im Fall des Wiederauftretens einer bestimmten Konstellation innerhalb einer festgelegten Zeitspanne löst Graylog einen Alarm aus, was wiederum die Administratoren in die Lage versetzt, prompt zu reagieren.

Die Graylog-Alerts sind auf Streams aufgebaut. Es gibt per Default einen Stream mit dem Namen »All messages«, der alle Benachrichtigungen aufnimmt und keine Regeln kennt. Eine neue Regel erzeugt einen neuen Stream. Das Active-Directory-Beispiel weiter oben im Artikel hat einen Stream mit folgender Regel erzeugt: Durchsuche alle Messages mit dem Feldnamen Event-ID, die den Wert 4625 enthalten (Abbildung 8).

Abbildung 8: Regel für einen Stream, der nach missglückten Logins sucht.

Für diesen Stream lässt sich ein Alert einrichten. Unter »Alerts | Manage condition | add new condition« öffnet sich ein Formular, das es erlaubt, den Stream und die Bedingungen für den Alert zu definieren. In diesem Beispiel wählt der Admin den Stream »AD Failed Logons« und »Message count condition« als Bedingung für den Alert. Es gibt drei Arten von Bedingungen:

• Message count condition: Der Alarm wird ausgelöst, wenn der gewählte Stream x Messages in den letzten y Minuten erhält. (Eignet sich sehr gut dazu, Brute-Force-Attacken zu erkennen.)
• Field aggregation condition: Der Alarm wird ausgelöst, wenn ein numerisches Feld in einen Stream eine minimale oder maximale Schwelle erreicht hat. (Eignet sich zum Beispiel, um festzustellen, ob die Antwortzeit einer bestimmten Applikation einen Maximalwert überschritten hat.)
• Field content condition: Der Alarm wird ausgelöst, wenn ein Feld einen bestimmten Wert enthält, etwa »Unknown source«, was bedeutet, dass eine nicht vertrauenswürdigen Quelle ein Programm installierte.

Mit Klick auf »Add alert condition« öffnet sich ein weiteres Formular, in dem die Werte der folgenden Parameter aus Listing 11 zu bestimmen sind.

01 Parameter    | Wert
02 --------------------------------------------------------------------------------------
03 Titel                | Failed Login AD
04 Time Range   | 1   # evaluiere jede x-te Minute alle ankommende Nachrichten
05 Threshold Type       | more than   # Typ der Schwelle, größer als oder kleiner als
06 Threshold    | 5   # Anzahl der Nachrichten, die die Bedingung erfüllen
07 Grace Period | 1   # Nach wie vielen Minuten soll die Bedingung wieder aktiv werden
08 Message Backlog      | 1   # Anzahl der Nachrichten, die im Alert anzuhängen sind

Nachdem er alle Bedingungen für einen Alert definiert hat, kann der Admin mit dem Einrichten einer Benachrichtigung beginnen. Unter »Alerts | Manage notifications | Add new notification« gibt er den betroffenen Stream an und bestimmt, wer auf welche Art im Fehlerfall eine Benachrichtigung erhalten soll. Dafür kann er zwischen einer HTTP Alert Notification und einer E-Mail Alert Notification wählen. Als Empfänger der Nachricht lässt sich entweder ein registrierter Graylog-User oder auch eine beliebige E-Mail-Adresse in das Formular eintragen.

Fazit

Zentrales Log-Management ist in einer modernen IT-Landschaft unabdingbar. Es entlastet einerseits die Administratoren von manuellen Kontrollen, andererseits erhöht es die Rate der Fehler-Erkennung und verbessert die Sicherheit. SIEM-Systeme helfen systematisch Anomalien oder Angriffe zu bemerken und passend zu reagieren. Sie sind somit die nächste Generation des Loggings und geeignet, der steigenden Komplexität der Programme wie auch der Angriffe zu begegnen.

SIEM gewinnt zusätzlich an Bedeutung durch das Realtime-Monitoring und die sofortige Benachrichtigung bei Regelverletzungen auf der einen Seite und Langzeitarchivierung für Analyse und Reporting auf der anderen.

01 Parameter            | Wert
02 ------------------------------------------
03 allow_override_date  | true
04 bind_address                 | 0.0.0.0
05 expand_structured_data       | true
06 force_rdns           | false
07 max_message_size             | 2097152
08 override_source              | <empty>
09 port                         | 1516
10 recv_buffer_size             | 1048576
11 store_full_message           | true
12 tcp_keepalive                | true
13 tls_cert_file                | /Pfad...
14 tls_client_auth              | disabled
15 tls_client_auth_cert_file    | <empty>
16 tls_enable           | true
17 tls_key_file                 | /Pfad...
18 tls_key_password             | ********
19 use_null_delimiter   | false