O Falco é conhecido como ferramenta para Kubernetes, e quase todos os guias sobre ele estão escritos para clusters. No entanto não está preso a clusters: vigia chamadas ao sistema, e num servidor vulgar com um sítio isso funciona exatamente da mesma maneira. Simplesmente, quase ninguém escreve sobre esse caso.

É útil onde as outras ferramentas se calam. Uma web shell num sítio não viola permissão nenhuma, não produz acessos falhados e não corresponde a assinatura nenhuma se foi escrita à mão. Mas apresenta um comportamento anómalo para um servidor web: o processo do PHP-FPM inicia um interpretador de comandos. É isso que o Falco vê.

O que deteta

Eventos típicos num servidor vulgar:

  • um interpretador gerado pelo processo do servidor web ou do PHP: sinal praticamente inequívoco de uma web shell;
  • um programa iniciado a partir de /tmp, /dev/shm ou /var/tmp;
  • ficheiros sensíveis (/etc/shadow, chaves privadas) lidos por um processo que nada tem a ver com eles;
  • alteração de binários do sistema;
  • uma ligação de saída a partir de um processo que não deveria usar a rede.

Instalação

A escolha decisiva faz-se na instalação: como o Falco obtém as chamadas ao sistema. A variante moderna assenta em eBPF e não exige compilar um módulo do núcleo nem cabeçalhos do núcleo:

sudo falcoctl driver config --type modern_ebpf
sudo systemctl restart falco

O módulo clássico do núcleo precisa de cabeçalhos e é recompilado depois de cada atualização do núcleo: num servidor onde as atualizações se instalam sozinhas, é uma fonte recorrente de serviço morto. Se o núcleo for suficientemente recente (5.8 ou superior), escolha eBPF e esqueça o problema.

Para verificar que chegam mesmo eventos:

sudo systemctl status falco
sudo journalctl -u falco -n 50

O ruído e como o eliminar

É este o trabalho a sério. O conjunto de regras que vem de origem visa ambientes com contentores, e num servidor vulgar uma parte considerável ou não se aplica ou dispara continuamente.

As regras fornecidas (/etc/falco/falco_rules.yaml) não se editam: o ficheiro é substituído na atualização. As suas alterações vão para /etc/falco/falco_rules.local.yaml, e é aí também que se desligam as regras supérfluas:

- rule: Terminal shell in container
  enabled: false

O que costuma ser preciso ajustar num servidor sem contentores:

  • todas as regras sobre contentores: sem contentores apenas ocupam espaço no relatório;
  • «Write below etc»: dispara em cada instalação de pacote e em cada alteração sua a um ficheiro de configuração. É precisa uma exceção para apt, dpkg e unattended-upgrades, ou os eventos chegam em torrente;
  • «Read sensitive file untrusted»: dispara com agentes de monitorização, ferramentas de cópia de segurança e ferramentas de auditoria como o Lynis;
  • os arranques a partir de pastas temporárias: existem exceções legítimas, como a compilação de uma aplicação ou um navegador automatizado que extrai um controlador para uma pasta temporária. Esses eventos parecem inquietantes mas explicam-se, e é melhor criar já a exceção para o caminho concreto do que voltar a raciocinar de cada vez.

A ordem razoável é a mesma de qualquer outra ferramenta de deteção: na primeira semana apenas observar e criar exceções, e só depois tratar um evento que apareça como sinal. A regra é simples: se o relatório contém com regularidade eventos que não lê, não lhe está a servir de nada.

Para onde enviar os eventos

A saída configura-se em /etc/falco/falco.yaml: um ficheiro, o diário do sistema ou a passagem a um programa externo. Para um servidor único basta um ficheiro com rotação a seguir; não se esqueça da rotação, o ficheiro de eventos cresce como qualquer registo e por omissão ninguém o vigia.

As prioridades devem ser usadas para separar: os eventos críticos onde os verá de imediato, o resto no diário geral para analisar mais tarde.

Falco e auditd não são a mesma coisa

Ambos vigiam chamadas ao sistema, mas com fins diferentes. O auditd regista o que acontece para que o quadro possa ser reconstruído mais tarde: não avalia nada e não comunica nada, mantém um diário. O Falco aplica regras no momento do evento e diz «isto parece suspeito»: dá um sinal em vez de um registo.

Ter ambos é razoável: o diário para a reconstrução, os sinais para a reação. Se for preciso escolher um, o auditd é mais útil num servidor onde o essencial é reconstruir a sequência dos acontecimentos depois de um incidente; o Falco onde se pretende um sinal precoce sobre um minerador em funcionamento ou uma web shell.

Vale o espaço num servidor pequeno

A resposta honesta: nem sempre. O Falco processa chamadas ao sistema e faz-se sentir no processador de uma máquina carregada. Se o servidor aloja um sítio e ainda não tem nem controlo de integridade nem atualizações automáticas decentes, não é por aí que se deve começar.

O seu momento chega mais tarde, quando o básico está feito e resta a pergunta sobre o que se passa no servidor que os registos não mostram. Cobre uma classe de eventos melhor do que todas as outras juntas: um interpretador iniciado pelo processo do servidor web. Como ficam os eventos divididos por prioridade e por regra mostra-o a página de demonstração abaixo.