Praktisch jede Suricata-Anleitung endet mit der Installation von Elasticsearch, Logstash und Kibana. Für einen einzelnen VPS ist das ein schlechter Rat: Der Stapel verlangt vier Gigabyte Arbeitsspeicher und ständige Aufmerksamkeit, dabei wollten Sie nur sehen, was das IDS an einem Tag gefangen hat. Suricata arbeitet auch ohne sie hervorragend — aber sie hat eine Eigenheit, wegen der man sie installiert und eine Woche später wieder entfernt.

Die Mine in den Voreinstellungen

Ab Werk schreibt Suricata mehr als dreißig Ereignistypen in eve.json: nicht nur Meldungen, sondern jede DNS-Anfrage, jeden TLS-Handshake, jede HTTP-Transaktion, ARP, DHCP, Datenfluss um Datenfluss. Dazu ein eigenes stats.log alle acht Sekunden. Eine Protokollrotation richtet Suricata dabei nicht ein — das ist Aufgabe des Administrators, und nirgends steht es in großen Lettern.

Eine Zahl von einem echten Server: 15 Gigabyte in zwei Tagen — neun in eve.json und knapp sechs in stats.log. Bis zur vollen Festplatte blieben etwa fünf Tage. Viel Datenverkehr gab es auf diesem Server nicht einmal; auf einem stark genutzten Knoten wäre es eine Frage von Stunden gewesen.

Prüfen Sie es bei sich sofort:

sudo du -sh /var/log/suricata/*

Behalten Sie nur, was Sie lesen

Wenn Sie Meldungen ansehen und keine Netzwerkforensik betreiben, brauchen Sie aus eve-log genau einen Ereignistyp. Suchen Sie in /etc/suricata/suricata.yaml den Block outputs und lassen Sie unter types bei eve-log nur alert stehen; den Rest kommentieren Sie aus. Schalten Sie an derselben Stelle die Statistikausgabe ab:

  - stats:
      enabled: no

Nach der Änderung ist die Konfigurationsprüfung Pflicht — vor dem Neustart des Dienstes:

sudo suricata -T -c /etc/suricata/suricata.yaml -v

Die Reihenfolge ist wichtig: Der Test besteht nicht, wenn die Regeln noch nicht geladen sind. Zuerst suricata-update, dann die Konfigurationsprüfung, dann der Start.

Eine Rotation, die tatsächlich funktioniert

Die Datei /etc/logrotate.d/suricata:

/var/log/suricata/*.log /var/log/suricata/*.json {
    daily
    rotate 7
    maxsize 200M
    missingok
    compress
    delaycompress
    create 0664 suricata suricata
    su suricata suricata
    postrotate
        systemctl kill -s HUP suricata
    endscript
}

Zwei Zeilen darin sind nicht offensichtlich und beide entscheidend.

su suricata suricata — ohne sie überspringt logrotate stillschweigend sämtliche Dateien. Das Verzeichnis /var/log/suricata gehört der Gruppe suricata und nicht root, und logrotate hält eine solche Konstellation für unsicher. Weder in der Mail noch im Protokoll erscheint ein Fehler; Sie sind schlicht überzeugt, dass die Rotation läuft — bis die Festplatte voll ist. Der einzige Weg, das vorher zu bemerken, ist ein Trockenlauf:

sudo logrotate -d /etc/logrotate.d/suricata

create 0664 suricata suricata — die Rechte der neuen Datei. Mit den Vorgabewerten (0640) sieht jedes Panel und jedes Skript, das die Protokolle nicht als root liest, nach der ersten Rotation nur noch Leere.

Was außer den Protokollen einzustellen ist

HOME_NET. Das beschreibt, was Suricata als eigenes Netz betrachtet. Der Vorgabewert listet alle privaten Bereiche auf, ein VPS hat aber eine öffentliche Adresse — dadurch greifen manche Regeln nicht oder greifen genau verkehrt herum. Geben Sie Ihr Netz ausdrücklich an.

Regeln. Den Satz Emerging Threats Open holt suricata-update; der Befehl gehört einmal täglich in den Cron. Einzelne laute Signaturen werden in /etc/suricata/disable.conf per Kennung abgeschaltet — scheuen Sie sich nicht davor: Der Satz ist für ein Unternehmensnetz gedacht, und auf einem gewöhnlichen Webserver löst ein Dutzend Regeln ständig und ohne Anlass aus.

Betriebsart. Standardmäßig hört Suricata eine Kopie des Datenverkehrs mit und warnt nur (IDS). Der blockierende Betrieb (IPS über nfqueue) ist auf einem einzelnen Server vor allem ein Risiko für Sie selbst: ein Fehlalarm, und Sie haben sich ausgesperrt. Beginnen Sie mit Beobachten und sehen Sie sich einen Monat lang an, was hängen bleibt.

Lesen ohne Kibana

Kurzmeldungen liegen in /var/log/suricata/fast.log — eine Zeile je Ereignis, mit bloßem Auge lesbar:

sudo tail -50 /var/log/suricata/fast.log

Die Einzelheiten stehen in eve.json, ein JSON-Objekt pro Zeile. Alles, wofür sonst Kibana installiert wird, erledigt ein einziger Befehl:

sudo jq -r 'select(.event_type=="alert") | .alert.signature' \
    /var/log/suricata/eve.json | sort | uniq -c | sort -rn | head -20

Das sind die zwanzig häufigsten Signaturen. Über eine Woche beantwortet eine solche Liste ehrlich, was mit dem Server los ist — und zeigt zugleich, welche Regeln abzuschalten sind.

Wozu das Ganze, wenn Fail2ban schon läuft

Sie sind grundverschieden. Fail2ban liest Anwendungsprotokolle und reagiert auf fehlgeschlagene Anmeldungen — also auf das, was einen Dienst bereits erreicht hat. Suricata betrachtet den Datenverkehr selbst und sieht, was in keinem Protokoll stehen wird: Portscans, Exploit-Versuche nach bekannten Signaturen, Verbindungen zu Steuerungsservern aus Ihrer Maschine heraus. Letzteres ist besonders wertvoll: Eine ausgehende Verbindung zu einem fremden Command-and-Control-Server ist das früheste Anzeichen dafür, dass auf dem Server bereits etwas läuft, das Sie nicht gestartet haben.

Beide zu betreiben ist in Ordnung, sie geraten sich nicht ins Gehege. Die Frage ist nur, ob jemand ihre Ausgabe häufiger als einmal im Quartal liest. Wie dieselben Meldungen auf einer Seite aussehen, aufgeteilt nach Kategorie und Quelle, zeigt die Demo unten.