Så godt som enhver veiledning om Suricata slutter med at man installerer Elasticsearch, Logstash og Kibana. For én enkelt VPS er det et dårlig råd: den kombinasjonen vil ha fire gigabyte minne og stadig tilsyn, mens alt du ville, var å se hva IDS-en fanget i løpet av døgnet. Suricata fungerer utmerket uten dem — men den har en egenhet som gjør at mange installerer den og river den vekk en uke senere.

Minen i standardinnstillingene

Rett ut av boksen skriver Suricata drøyt tretti typer hendelser til eve.json: ikke bare varsler, men hver DNS-forespørsel, hvert TLS-håndtrykk, hver HTTP-transaksjon, ARP, DHCP, strøm etter strøm. I tillegg en egen stats.log hvert åttende sekund. Loggrotasjon setter Suricata ikke opp i det hele tatt — det er administratorens oppgave, og det står ingen steder med store bokstaver.

Et tall fra en virkelig server: 15 gigabyte på to døgn — ni i eve.json og nesten seks i stats.log. Til full disk gjensto omtrent fem dager. Trafikken på serveren var samtidig moderat; på en belastet node ville det dreid seg om timer.

Kontroller hos deg selv med en gang:

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

Behold bare det du leser

Ser du på varsler og ikke driver med nettverksetterforskning, trenger du nøyaktig én hendelsestype fra eve-log. I /etc/suricata/suricata.yaml finner du blokken outputs og beholder alert under types for eve-log, resten kommenteres bort. Slå av statistikkutskriften samme sted:

  - stats:
      enabled: no

Etter endringen — obligatorisk konfigurasjonskontroll, før omstart av tjenesten:

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

Rekkefølgen betyr noe: testen går ikke gjennom hvis reglene ennå ikke er hentet. Først suricata-update, så konfigurasjonskontrollen, så start.

Rotasjon som faktisk virker

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
}

To linjer her er ikke opplagte, og begge er avgjørende.

su suricata suricata — uten den hopper logrotate stille over alle filene. Katalogen /var/log/suricata tilhører gruppen suricata og ikke root, og logrotate regner det oppsettet som utrygt. Noen feilmelding kommer verken i posten eller i loggen; du er rett og slett overbevist om at rotasjonen finnes, helt til disken tar slutt. Eneste måte å fange det på forhånd er en tørrkjøring:

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

create 0664 suricata suricata — rettighetene på den nye filen. Med standardrettighetene (0640) ser ethvert panel eller skript som leser loggene uten root, bare tomhet etter første rotasjon.

Hva du skal stille inn utover loggene

HOME_NET. Det er beskrivelsen av hva Suricata regner som «sitt». Standardverdien lister opp alle private adresseområder, mens en VPS har en offentlig adresse — følgen er at noen regler ikke utløses, eller utløses omvendt. Angi ditt eget nett uttrykkelig.

Regler. Settet Emerging Threats Open hentes med suricata-update, som legges i cron én gang i døgnet. Enkelte støyende signaturer slås av i /etc/suricata/disable.conf med sin id — ikke vær redd for å bruke det: settet er laget for bedriftsnett, og et titalls regler vil på en vanlig webserver utløses hele tiden uten grunn.

Modus. Som standard lytter Suricata på en kopi av trafikken og bare advarer (IDS). Blokkeringsmodus (IPS, via nfqueue) på én enkelt server er først og fremst en risiko for deg selv: ett falskt utslag, og du har stengt deg selv ute. Begynn med observasjon og se en måned hva som fanges opp.

Hvordan du leser uten Kibana

Korte varsler ligger i /var/log/suricata/fast.log — én linje per hendelse, lesbart for øyet:

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

Detaljene ligger i eve.json, ett JSON-objekt per linje. Alt man vanligvis installerer Kibana for, gjøres med én kommando:

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

Det er de tjue vanligste signaturene. En slik liste over en uke svarer ærlig på spørsmålet om hva som egentlig skjer med serveren, og viser samtidig hvilke regler det er på tide å slå av.

Hvorfor dette når Fail2ban allerede finnes

De er ulike av natur. Fail2ban leser applikasjonslogger og reagerer på mislykkede innlogginger — altså på det som allerede har nådd fram til en tjeneste. Suricata ser på selve trafikken og oppdager det som aldri havner i loggene: portskanninger, forsøk på kjente utnyttelser, kontakt med styringsservere innenfra maskinen din. Det siste er særlig verdifullt: en utgående forbindelse til en fremmed C2 er det tidligste tegnet på at noe på serveren allerede kjører uten din viten.

Å ha begge verktøyene er normalt, de kolliderer ikke. Spørsmålet er bare om noen leser utdataene deres oftere enn én gang i kvartalet. Hvordan de samme varslene ser ut på én side, fordelt på kategorier og kilder, viser demonstrasjonen nedenfor.