Practic orice ghid despre Suricata se încheie cu instalarea Elasticsearch, Logstash și Kibana. Pentru un singur VPS acesta este un sfat prost: ansamblul cere patru gigaocteți de memorie și supraveghere permanentă, în timp ce tu voiai doar să vezi ce a prins IDS-ul într-o zi. Suricata funcționează excelent și fără ele — are însă o particularitate din cauza căreia mulți o instalează și o dezinstalează o săptămână mai târziu.

Mina din setările implicite

Din start, Suricata scrie în eve.json peste treizeci de tipuri de evenimente: nu doar alerte, ci fiecare interogare DNS, fiecare strângere de mână TLS, fiecare tranzacție HTTP, ARP, DHCP, flux după flux. Plus un stats.log separat la fiecare opt secunde. Rotația jurnalelor Suricata nu o configurează deloc — este sarcina administratorului, despre care nu scrie nicăieri cu litere mari.

O cifră de pe un server real: 15 gigaocteți în două zile — nouă în eve.json și aproape șase în stats.log. Până la discul plin mai rămâneau vreo cinci zile. Trafic pe server era puțin; pe un nod încărcat ar fi fost vorba de ore.

Verifică imediat la tine:

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

Păstrează doar ce citești

Dacă te uiți la alerte și nu faci analiză criminalistică de rețea, din eve-log îți trebuie exact un tip de evenimente. În /etc/suricata/suricata.yaml găsește blocul outputs și, la types pentru eve-log, păstrează alert, restul comentează-l. Tot acolo dezactivează ieșirea statisticilor:

  - stats:
      enabled: no

După modificare — verificarea obligatorie a configurației, înainte de repornirea serviciului:

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

Ordinea contează: testul nu trece dacă regulile nu sunt încă descărcate. Mai întâi suricata-update, apoi verificarea configurației, apoi pornirea.

Rotația care chiar funcționează

Fișierul /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
}

Două linii de aici nu sunt evidente și amândouă sunt critice.

su suricata suricata — fără ea, logrotate sare în tăcere peste toate fișierele. Directorul /var/log/suricata aparține grupului suricata, nu lui root, iar logrotate consideră o astfel de configurație nesigură. Eroare nu ajunge nici în poștă, nici în jurnal; pur și simplu vei fi convins că rotația există, până se termină discul. Singurul mod de a prinde asta din timp este o rulare în gol:

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

create 0664 suricata suricata — drepturile fișierului nou. Cu drepturile implicite (0640), orice panou sau script care citește jurnalele fără root va vedea gol după prima rotație.

Ce mai trebuie configurat în afară de jurnale

HOME_NET. Este descrierea a ceea ce Suricata consideră „al său”. Valoarea implicită enumeră toate intervalele private, în timp ce VPS-ul are adresă publică — rezultatul este că o parte dintre reguli nu se declanșează sau se declanșează invers. Indică-ți rețeaua explicit.

Reguli. Setul Emerging Threats Open se descarcă prin comanda suricata-update, pusă în cron o dată pe zi. Semnăturile zgomotoase individuale se dezactivează în /etc/suricata/disable.conf după identificator — nu te teme să folosești asta: setul este gândit pentru rețele de firmă, iar vreo zece reguli se vor declanșa pe un server web obișnuit în permanență și fără motiv.

Modul de lucru. Implicit, Suricata ascultă o copie a traficului și doar avertizează (IDS). Modul de blocare (IPS, prin nfqueue) pe un singur server este un risc în primul rând pentru tine: o alarmă falsă și îți închizi singur accesul. Începe cu observarea și urmărește o lună ce se prinde.

Cum se citește fără Kibana

Alertele scurte se află în /var/log/suricata/fast.log — o linie per eveniment, lizibil cu ochiul liber:

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

Detaliile sunt în eve.json, câte un obiect JSON pe linie. Tot ce se face de obicei instalând Kibana se rezolvă cu o singură comandă:

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

Acestea sunt cele mai frecvente douăzeci de semnături. O astfel de listă pe o săptămână răspunde cinstit la întrebarea ce se întâmplă de fapt cu serverul și arată totodată ce reguli e timpul să dezactivezi.

De ce asta, dacă există deja Fail2ban

Sunt de natură diferită. Fail2ban citește jurnalele aplicațiilor și reacționează la autentificări eșuate — adică la ceea ce a ajuns deja la un serviciu. Suricata se uită la traficul propriu-zis și vede ceea ce nu ajunge în jurnale: scanări de porturi, tentative de exploatare după semnături cunoscute, contactul cu servere de comandă din interiorul mașinii tale. Ultimul lucru este deosebit de valoros: o conexiune ieșită către un C2 străin este cel mai timpuriu semn că ceva rulează deja pe server fără știrea ta.

Este normal să le ai pe amândouă, nu intră în conflict. Întrebarea este doar dacă cineva le citește ieșirea mai des decât o dată pe trimestru. Cum arată aceleași alerte pe o pagină, împărțite pe categorii și surse, arată demonstrația de mai jos.