Vrijwel elke handleiding over Suricata eindigt met het installeren van Elasticsearch, Logstash en Kibana. Voor één VPS is dat een slecht advies: de stapel vraagt vier gigabyte geheugen en voortdurende aandacht, terwijl u alleen wilde zien wat de IDS in een dag heeft gevangen. Suricata werkt uitstekend zonder hen — maar heeft één eigenschap waardoor men hem installeert en een week later weer verwijdert.

De mijn in de standaardinstellingen

Standaard schrijft Suricata meer dan dertig soorten gebeurtenissen naar eve.json: niet alleen meldingen, maar elke DNS-vraag, elke TLS-handdruk, elke HTTP-transactie, ARP, DHCP, stroom na stroom. Plus een apart stats.log om de acht seconden. Logrotatie richt Suricata daarbij helemaal niet in — dat is de taak van de beheerder, en nergens staat het in grote letters.

Een getal van een echte server: 15 gigabyte in twee dagen — negen in eve.json en bijna zes in stats.log. Er restten nog ongeveer vijf dagen tot de schijf vol was. Veel verkeer had die server niet eens; op een druk knooppunt was het een kwestie van uren geweest.

Controleer het meteen bij uzelf:

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

Bewaar alleen wat u leest

Kijkt u naar meldingen en doet u geen netwerkforensiek, dan is uit eve-log precies één soort gebeurtenis nodig. Zoek in /etc/suricata/suricata.yaml het blok outputs en laat onder types bij eve-log alleen alert staan; de rest zet u tussen commentaar. Schakel op diezelfde plek de statistiekuitvoer uit:

  - stats:
      enabled: no

Na de wijziging is de configuratiecontrole verplicht — vóór het herstarten van de dienst:

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

De volgorde doet ertoe: de test slaagt niet als de regels nog niet geladen zijn. Eerst suricata-update, dan de configuratiecontrole, dan de start.

Een rotatie die echt werkt

Het bestand /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
}

Twee regels daarin zijn niet vanzelfsprekend en beide zijn doorslaggevend.

su suricata suricata — zonder die slaat logrotate alle bestanden stilzwijgend over. De map /var/log/suricata is eigendom van de groep suricata en niet van root, en logrotate beschouwt zo'n opstelling als onveilig. Er komt geen fout in de mail en geen in het logboek; u bent er eenvoudigweg van overtuigd dat er rotatie is — tot de schijf vol raakt. De enige manier om het vooraf te merken is een proefdraaiing:

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

create 0664 suricata suricata — de rechten op het nieuwe bestand. Met de standaardwaarden (0640) ziet elk paneel of script dat de logboeken niet als root leest, na de eerste rotatie niets meer.

Wat er naast de logboeken ingesteld moet worden

HOME_NET. Dat beschrijft wat Suricata als het eigene beschouwt. De standaardwaarde somt alle privébereiken op, maar een VPS heeft een openbaar adres — waardoor sommige regels niet afgaan of juist omgekeerd afgaan. Geef uw netwerk uitdrukkelijk op.

Regels. De set Emerging Threats Open haalt suricata-update binnen; dat commando hoort eenmaal daags in cron. Afzonderlijke luidruchtige handtekeningen zet u per aanduiding uit in /etc/suricata/disable.conf — wees niet bang daar gebruik van te maken: die set is voor een bedrijfsnetwerk bedoeld, en op een gewone webserver gaat een dozijn regels voortdurend en zonder aanleiding af.

Modus. Standaard luistert Suricata naar een kopie van het verkeer en waarschuwt alleen (IDS). De blokkeermodus (IPS, via nfqueue) op één enkele server is vooral een risico voor uzelf: één vals alarm en u hebt zichzelf de toegang ontnomen. Begin met kijken en besteed een maand aan wat er wordt gevangen.

Lezen zonder Kibana

Korte meldingen staan in /var/log/suricata/fast.log — één regel per gebeurtenis, met het blote oog leesbaar:

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

De details staan in eve.json, één JSON-object per regel. Alles waarvoor men gewoonlijk Kibana installeert, past in één commando:

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

Dat zijn de twintig meest voorkomende handtekeningen. Over een week beantwoordt zo'n lijst eerlijk wat er met de server aan de hand is, en laat meteen zien welke regels het tijd is om uit te zetten.

Waarom, als Fail2ban er al is

De aard verschilt. Fail2ban leest logboeken van toepassingen en reageert op mislukte aanmeldingen — dus op wat een dienst al heeft bereikt. Suricata kijkt naar het verkeer zelf en ziet wat in geen enkel logboek zal staan: poortscans, exploitpogingen volgens bekende handtekeningen, verbindingen naar aanstuurservers vanuit uw machine. Dat laatste is bijzonder waardevol: een uitgaande verbinding naar andermans aanstuurserver is het vroegste teken dat er op de server al iets draait dat u niet hebt gestart.

Beide draaien is normaal, ze zitten elkaar niet in de weg. De enige vraag is of iemand hun uitvoer vaker dan eens per kwartaal leest. Hoe diezelfde meldingen op één pagina eruitzien, uitgesplitst naar categorie en bron, toont de demo hieronder.