Suricata IDS — detetor de rede

Alertas do Suricata sem uma stack ELK

O Suricata escreve o que encontra no eve.json, um objeto JSON por evento, e o conselho habitual é enviar tudo isso para o Elasticsearch e consultá-lo através do Kibana. Num cluster faz sentido. Num único VPS significa manter um motor de pesquisa, um coletor de registos e um servidor de painéis — vários gigabytes de memória e um segundo sistema para cuidar — só para ler alertas a partir da mesma máquina onde já tinham sido escritos.

Esta página lê o eve.json diretamente, bem como o fast.log quando é isso que a sua compilação produz. Mostra os alertas das últimas vinte e quatro horas agrupados por categoria, os endereços que geram mais deles e as assinaturas individuais com origem, destino, protocolo e gravidade.

Se o Suricata está a correr mas nada comunica, a causa está quase sempre nas regras e não no tráfego: uma instalação nova não traz assinaturas nenhumas enquanto o suricata-update não correr pelo menos uma vez. A outra surpresa habitual é a gravidade. A maior parte do que um sensor exposto comunica é varrimento de gravidade baixa que nunca dá em nada, por isso leia as categorias antes do contador.

Um sensor no fio tem um limite em que se tropeça com regularidade: o tráfego cifrado chega-lhe como um fluxo de bytes. Dirá que deste endereço veio uma ligação ao seu sítio, mas não dirá que o pedido levava uma tentativa de injeção de SQL. Isso é lido pelo ModSecurity, dentro do servidor web, depois da decifragem. Os dois não se substituem: um olha para a rede de fora, o outro para o pedido de dentro.