Zabbix FIM: Monitoramento de Integridade de Arquivos

Quando pensamos em Zabbix, a primeira imagem que vem à cabeça são gráficos de CPU, memória e tráfego de rede. Mas sabia que, trabalhando em conjunto com soluções como um Host IPS, ele pode ser um componente vital da sua estratégia de Defesa Cibernética?

Uma das táticas mais comuns de malwares e invasores (como rootkits) é alterar arquivos críticos do sistema, seja para garantir persistência, modificar configurações de DNS (como ao editar o arquivo /etc/hosts) ou injetar scripts maliciosos em sites.

Neste tutorial, vou ensinar como configurar o Zabbix para atuar como um FIM (File Integrity Monitor – Monitor de Integridade de Arquivos). Você será alertado no momento exato em que um arquivo sensível for modificado no seu servidor.

O Conceito: Como Funciona o Monitoramento de Integridade no Zabbix?

Não vamos monitorar o conteúdo do texto (o que seria pesado para o banco de dados), mas sim a assinatura digital (Checksum/Hash) do arquivo.

Se você tem um arquivo de configuração que não deveria mudar, o checksum dele deve ser constante. Se alguém editar uma vírgula sequer, o checksum muda drasticamente. É essa mudança precisa que o Zabbix vai detectar.

Passo 1: Criando o Item de Monitoramento FIM

O primeiro passo é dizer ao Zabbix qual arquivo “vigiar”. Vamos usar a chave nativa vfs.file.cksum.

Pré-requisito: a máquina cliente deve ter instalado o zabbix agent para Linux .

Assumindo que já realizou a instalação do Zabbix, acesse Data collection (Configuração) > Hosts.

Clique nos três pontos (…) na frente do host que você quer monitorar.

Selecione o host desejado (ou um Template) e vá em Items.

Clique em Create item e preencha as seguintes informações:

• Name: Integridade do arquivo /etc/passwd
• Type: Zabbix agent
• No campo “Key“, clique em Select.

Em seguida selecione “vfs.file.cksum[/etc/passwd]“.

Agora vamos alterar o local e o nome do arquivo clicando no campo abaixo.

Agora, vamos inserir o caminho e o nome do arquivo que vamos monitorar. No nosso caso prático, é o “/etc/passwd“.

Depois disso, altere o campo “Update Interval“. No nosso caso estamos deixando em “1m” porque queremos mostrar o momento em que o arquivo é alterado em tempo real. Em ambientes de produção podemos deixar esse valor mais elevado.

Type of information: Numeric (unsigned)

Update interval: 5m (Dica de Otimização: Não use 1m em produção. Arquivos de configuração mudam pouco. Utilizar 5m ou 10m economiza recursos valiosos).

History storage: insira o valor que faz mais sentido para a sua auditoria, como por exemplo 90d.

Clique em Add. O Zabbix agora está calculando o hash CRC32 desse arquivo a cada intervalo de tempo que você definiu.

Passo 2: Criando o Gatilho (Trigger) de Segurança

Agora precisamos da inteligência. O Zabbix deve disparar um alerta SE o hash atual for diferente do hash anterior.

Ainda no Host/Template, vá na aba Triggers.

Clique em Create trigger.

Preencha com atenção as propriedades do alerta:

Name: alert my passwd {HOST.NAME}

Severity: High (ou Disaster)

Expression:  clique em Add.

Agora clique em Select.

Procure pelo item que você criou. No nosso caso, o item criado foi o “my passwd“.

Depois de selecionar o item, vamos clicar em “Insert“.

Podemos observar que foram adicionados dados ao campo “Expression“.

Agora no campo “Expression“, usaremos a função change ou a comparação de valores. A lógica é: “O valor atual é diferente (<>) do último valor?”

last(/My_host/vfs.file.cksum[/etc/passwd]) <> last(/My_host/vfs.file.cksum[/etc/passwd], #2)

Vamos também selecionar os campos indicados abaixo para evitar que uma atualização no arquivo de senha sobrescreva o alarme.

• “OK event generation = None” , você pode mudar para None (Nenhum).
  • Resultado: O alerta sobe quando o arquivo muda e fica fixo no Dashboard para sempre, até que um administrador vá lá, veja o que aconteceu e feche o alerta manualmente.
• “PROBLEM event generation mode = Multiple“.
• E selecionar “Allow manual close” (Permitir fechamento manual).

Clique em Add.

Podemos ver na figura abaixo que o Trigger foi adicionado com sucesso.

Passo 3: O Teste de Fogo (Simulando um Backdoor)

De nada adianta configurar segurança se não validarmos com um cenário real. Em vez de apenas editar o arquivo, vamos simular o comportamento de um invasor tentando garantir Persistência.

Imagine que um atacante conseguiu acesso ao shell e, para garantir que ele consiga voltar depois, ele cria um usuário escondido. Vamos fazer isso:

Acesse o seu servidor Linux via terminal.

Execute o comando para criar um falso usuário “intruso”:

sudo useradd -M -s /bin/bash backdoortest

(Nota: Este comando adiciona uma nova linha ao final do arquivo /etc/passwd, alterando drasticamente o seu hash).

Aguarde o ciclo de coleta do Zabbix (ou force a checagem manual).

Vá ao Dashboard. O alerta de segurança deve disparar imediatamente.

Ao clicar nos detalhes do alerta, você saberá que o arquivo de usuários foi modificado sem autorização. Num cenário real, isso é o equivalente a um alarme de incêndio a tocar no SOC da sua empresa.