Så gott som varje guide om Suricata slutar med att man installerar Elasticsearch, Logstash och Kibana. För en enda VPS är det ett dåligt råd: den kombinationen vill ha fyra gigabyte minne och ständig tillsyn, medan allt du ville var att se vad IDS fångat under dygnet. Suricata fungerar utmärkt utan dem — men den har en egenhet som gör att många installerar den och river bort den en vecka senare.

Minan i standardinställningarna

Ur lådan skriver Suricata drygt trettio typer av händelser till eve.json: inte bara larm, utan varje DNS-fråga, varje TLS-handskakning, varje HTTP-transaktion, ARP, DHCP, flöde efter flöde. Plus en separat stats.log var åttonde sekund. Loggrotation ställer Suricata inte in alls — det är administratörens uppgift, och det står ingenstans med stora bokstäver.

En siffra från en riktig server: 15 gigabyte på två dygn — nio i eve.json och nästan sex i stats.log. Till full disk återstod ungefär fem dagar. Trafiken på servern var samtidigt måttlig; på en belastad nod hade det handlat om timmar.

Kontrollera hos dig själv med en gång:

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

Behåll bara det du läser

Om du tittar på larm och inte sysslar med nätverksforensik behöver du exakt en händelsetyp ur eve-log. I /etc/suricata/suricata.yaml, leta upp blocket outputs och behåll alert under types för eve-log, kommentera bort resten. Stäng av statistikutskriften på samma ställe:

  - stats:
      enabled: no

Efter ändringen — obligatorisk konfigurationskontroll, före omstarten av tjänsten:

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

Ordningen spelar roll: testet går inte igenom om reglerna ännu inte är hämtade. Först suricata-update, sedan konfigurationskontrollen, sedan start.

Rotation som faktiskt fungerar

Filen /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
}

Två rader här är icke uppenbara och båda är avgörande.

su suricata suricata — utan den hoppar logrotate tyst över alla filer. Katalogen /var/log/suricata tillhör gruppen suricata och inte root, och logrotate betraktar den uppsättningen som osäker. Något felmeddelande kommer inte i posten och inte i loggen; du är helt enkelt övertygad om att rotationen finns tills disken tar slut. Enda sättet att fånga det i förväg är en torrkörning:

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

create 0664 suricata suricata — rättigheterna på den nya filen. Med standardrättigheterna (0640) ser varje panel eller skript som läser loggarna utan root bara tomhet efter första rotationen.

Vad du ska ställa in utöver loggarna

HOME_NET. Det är beskrivningen av vad Suricata betraktar som ”sitt”. Standardvärdet räknar upp alla privata adressintervall, medan en VPS har en publik adress — följden är att en del regler inte utlöses eller utlöses baklänges. Ange ditt eget nät uttryckligen.

Regler. Uppsättningen Emerging Threats Open hämtas med suricata-update, som läggs i cron en gång per dygn. Enskilda bullriga signaturer stängs av i /etc/suricata/disable.conf med sitt id — var inte rädd för att använda det: uppsättningen är gjord för företagsnät, och ett tiotal regler kommer på en vanlig webbserver att utlösas hela tiden utan orsak.

Läge. Som standard lyssnar Suricata på en kopia av trafiken och varnar bara (IDS). Blockeringsläget (IPS, via nfqueue) på en enda server är framför allt en risk för dig själv: ett falskt larm och du har stängt ute dig själv. Börja med observation och se en månad vad som fastnar.

Hur du läser utan Kibana

Korta larm ligger i /var/log/suricata/fast.log — en rad per händelse, läsbart för ögat:

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

Detaljerna finns i eve.json, ett JSON-objekt per rad. Allt det man vanligen installerar Kibana för görs med ett kommando:

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

Det är de tjugo vanligaste signaturerna. En sådan lista över en vecka svarar ärligt på frågan vad som egentligen händer med servern och visar samtidigt vilka regler det är dags att stänga av.

Varför detta när Fail2ban redan finns

De är olika till sin natur. Fail2ban läser applikationsloggar och reagerar på misslyckade inloggningar — alltså på det som redan nått fram till en tjänst. Suricata tittar på själva trafiken och ser det som aldrig hamnar i loggarna: portskanningar, försök till kända exploits, kontakt med styrservrar inifrån din maskin. Det sista är särskilt värdefullt: en utgående anslutning till en främmande C2 är det tidigaste tecknet på att något på servern redan körs utan din vetskap.

Att ha båda verktygen är normalt, de krockar inte. Frågan är bara om någon läser deras utdata oftare än en gång per kvartal. Hur samma larm ser ut på en sida, uppdelade på kategorier och källor, visar demonstrationen nedan.