Praticamente todos os guias sobre o Suricata terminam com a instalação de Elasticsearch, Logstash e Kibana. Para um único VPS é um mau conselho: a pilha pedirá quatro gigabytes de memória e atenção constante, quando tudo o que queria era ver o que o IDS apanhou num dia. O Suricata funciona muito bem sem eles, mas tem uma particularidade que leva a instalá-lo e a removê-lo uma semana depois.

A mina nas definições por omissão

De fábrica, o Suricata escreve no eve.json mais de trinta tipos de eventos: não só alertas, mas cada consulta DNS, cada aperto de mão TLS, cada transação HTTP, ARP, DHCP, fluxo atrás de fluxo. Mais um stats.log separado de oito em oito segundos. E o Suricata não configura rotação de registos nenhuma: é tarefa do administrador, e em lado nenhum está escrito em letras grandes.

Um número de um servidor real: 15 gigabytes em dois dias, nove no eve.json e quase seis no stats.log. Faltavam cerca de cinco dias para o disco encher. E o tráfego nesse servidor nem sequer era elevado; num nó com carga teria sido questão de horas.

Verifique já no seu:

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

Guarde apenas o que lê

Se olha para alertas e não faz análise forense de rede, do eve-log é necessário exatamente um tipo de evento. Em /etc/suricata/suricata.yaml encontre o bloco outputs e, em types do eve-log, deixe apenas alert, comentando o resto. Desative no mesmo sítio a saída de estatísticas:

  - stats:
      enabled: no

Depois da alteração, a verificação da configuração é obrigatória, antes de reiniciar o serviço:

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

A ordem importa: o teste não passa se as regras ainda não estiverem carregadas. Primeiro suricata-update, depois a verificação, depois o arranque.

Uma rotação que funciona mesmo

O ficheiro /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
}

Duas linhas ali não são óbvias e ambas são decisivas.

su suricata suricata: sem ela o logrotate salta em silêncio todos os ficheiros. A pasta /var/log/suricata pertence ao grupo suricata e não ao root, e o logrotate considera essa disposição insegura. Não há erro no correio nem no registo; ficará simplesmente convencido de que a rotação existe, até o disco encher. A única forma de o detetar antes é uma passagem em seco:

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

create 0664 suricata suricata: as permissões do ficheiro novo. Com os valores por omissão (0640), qualquer painel ou script que leia os registos sem ser root deixará de ver o que quer que seja depois da primeira rotação.

O que configurar além dos registos

HOME_NET. Descreve aquilo que o Suricata considera seu. O valor por omissão enumera todas as gamas privadas, mas um VPS tem endereço público, pelo que algumas regras não disparam ou disparam ao contrário. Indique a sua rede de forma explícita.

Regras. O conjunto Emerging Threats Open é trazido pelo suricata-update, que se põe no cron uma vez por dia. As assinaturas ruidosas concretas desativam-se por identificador em /etc/suricata/disable.conf: não tenha receio de o usar, esse conjunto foi pensado para uma rede empresarial, e num servidor web vulgar uma dúzia de regras dispara continuamente e sem motivo.

Modo. Por omissão o Suricata escuta uma cópia do tráfego e limita-se a avisar (IDS). O modo de bloqueio (IPS, através de nfqueue) num servidor único é um risco sobretudo para si próprio: um falso positivo e ficou sem acesso. Comece por observar e passe um mês a ver o que é apanhado.

Ler sem Kibana

Os alertas curtos estão em /var/log/suricata/fast.log: uma linha por evento, legível a olho:

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

O pormenor está no eve.json, um objeto JSON por linha. Tudo aquilo para que habitualmente se instala o Kibana cabe num comando:

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

São as vinte assinaturas mais frequentes. Ao longo de uma semana, uma lista destas responde com honestidade ao que se passa com o servidor e mostra ao mesmo tempo que regras está na altura de desativar.

Para quê, se já existe o Fail2ban

A natureza é diferente. O Fail2ban lê registos de aplicações e reage a acessos falhados, ou seja, ao que já chegou a um serviço. O Suricata olha para o próprio tráfego e vê o que em registo nenhum aparecerá: varrimentos de portas, tentativas de exploração segundo assinaturas conhecidas, ligações a servidores de comando a partir de dentro da sua máquina. Este último ponto é especialmente valioso: uma ligação de saída para um servidor de comando alheio é o indício mais precoce de que no servidor já corre algo que não foi iniciado por si.

Manter ambos é normal, não se estorvam. A única questão é se alguém lê a sua saída mais do que uma vez por trimestre. Como aparecem esses mesmos alertas numa página, divididos por categoria e origem, mostra-o a demonstração abaixo.