Praktycznie każdy poradnik o Suricacie kończy się instalacją Elasticsearcha, Logstasha i Kibany. Dla jednego VPS-a to zła rada: stos poprosi o cztery gigabajty pamięci i stałą uwagę, a chodziło tylko o to, żeby zobaczyć, co IDS złapał w ciągu doby. Suricata świetnie działa i bez nich — ma jednak pewną właściwość, przez którą instaluje się ją i tydzień później usuwa.

Mina w ustawieniach domyślnych

Fabrycznie Suricata zapisuje w eve.json ponad trzydzieści rodzajów zdarzeń: nie tylko alerty, ale każde zapytanie DNS, każde uzgodnienie TLS, każdą transakcję HTTP, ARP, DHCP, przepływ po przepływie. Do tego osobny stats.log co osiem sekund. Rotacji dzienników Suricata przy tym nie konfiguruje wcale — to zadanie administratora, i nigdzie nie jest napisane dużymi literami.

Liczba z prawdziwego serwera: 15 gigabajtów w dwie doby — dziewięć w eve.json i prawie sześć w stats.log. Do zapełnienia dysku zostało jakieś pięć dni. Ruchu na tym serwerze nie było nawet dużo; na obciążonym węźle liczyłoby się to w godzinach.

Warto sprawdzić u siebie od razu:

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

Zostawić tylko to, co się czyta

Jeśli oglądamy alerty, a nie zajmujemy się informatyką śledczą sieci, z eve-log potrzebny jest dokładnie jeden rodzaj zdarzeń. W /etc/suricata/suricata.yaml należy znaleźć blok outputs i w types przy eve-log zostawić samo alert, resztę zakomentować. W tym samym miejscu wyłączamy wynik statystyk:

  - stats:
      enabled: no

Po zmianie obowiązkowe jest sprawdzenie konfiguracji — przed restartem usługi:

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

Kolejność ma znaczenie: test nie przejdzie, jeśli reguły nie zostały jeszcze wczytane. Najpierw suricata-update, potem sprawdzenie konfiguracji, potem start.

Rotacja, która naprawdę działa

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

Dwa wiersze nie są tu oczywiste i oba mają kluczowe znaczenie.

su suricata suricata — bez niego logrotate po cichu pominie wszystkie pliki. Katalog /var/log/suricata należy do grupy suricata, a nie do roota, i logrotate uznaje taki układ za niebezpieczny. Błędu nie będzie ani w poczcie, ani w dzienniku; będziemy po prostu przekonani, że rotacja działa — dopóki nie skończy się miejsce. Jedyny sposób, by wyłapać to wcześniej, to przebieg na sucho:

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

create 0664 suricata suricata — prawa nowego pliku. Przy wartościach domyślnych (0640) każdy panel albo skrypt czytający dzienniki nie jako root po pierwszej rotacji zobaczy pustkę.

Co ustawić poza dziennikami

HOME_NET. To opis tego, co Suricata uważa za własne. Wartość domyślna wylicza wszystkie zakresy prywatne, a VPS ma adres publiczny — w efekcie część reguł nie zadziała albo zadziała odwrotnie. Sieć trzeba wskazać jawnie.

Reguły. Zestaw Emerging Threats Open pobiera polecenie suricata-update, które trafia do crona raz na dobę. Poszczególne hałaśliwe sygnatury wyłącza się po identyfikatorze w /etc/suricata/disable.conf — nie należy się tego bać: zestaw pisano dla sieci korporacyjnej, a na zwykłym serwerze WWW kilkanaście reguł będzie odpalać stale i bez powodu.

Tryb. Domyślnie Suricata nasłuchuje kopii ruchu i tylko ostrzega (IDS). Tryb blokujący (IPS przez nfqueue) na jedynym serwerze to ryzyko przede wszystkim dla nas samych: jedno fałszywe trafienie i sami odcinamy sobie dostęp. Zacząć trzeba od obserwacji i przez miesiąc patrzeć, co się łapie.

Czytanie bez Kibany

Krótkie alerty leżą w /var/log/suricata/fast.log — jeden wiersz na zdarzenie, czytelne gołym okiem:

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

Szczegóły są w eve.json, po jednym obiekcie JSON na wiersz. Wszystko, dla czego zwykle instaluje się Kibanę, robi jedno polecenie:

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

To dwadzieścia najczęstszych sygnatur. Taka lista za tydzień uczciwie odpowiada na pytanie, co dzieje się z serwerem, i przy okazji pokazuje, które reguły pora wyłączyć.

Po co to, skoro jest już Fail2ban

Inna natura. Fail2ban czyta dzienniki aplikacji i reaguje na nieudane logowania — czyli na to, co już dotarło do usługi. Suricata patrzy na sam ruch i widzi to, czego w dziennikach nie będzie: skanowanie portów, próby wykorzystania znanych podatności według sygnatur, połączenia do serwerów sterujących z wnętrza naszej maszyny. To ostatnie jest szczególnie cenne: połączenie wychodzące do cudzego serwera sterującego to najwcześniejszy znak, że na serwerze działa już coś, czego nikt z nas nie uruchamiał.

Trzymanie obu narzędzi jest normalne, nie kolidują ze sobą. Pytanie tylko, czy ktoś czyta ich wyniki częściej niż raz na kwartał. Jak te same alerty wyglądają na jednej stronie, w podziale na kategorie i źródła, pokazuje demonstracja poniżej.