Monitoramento de Blacklists (DNS-BL) com Zabbix

Autoria: Werneck Costa / Revisão e dicas: Aécio Pires

Em geral, todo domínio na Internet (Ex.: zabbix.com) possui no mínimo um servidor MX (Mail Exchanger). Este servidor possui um registro DNS específico e responde pelas comunicações via e-mail deste domínio.

Para quem administra este tipo de servidor, existe uma preocupação constante: a entrada destes IPs em Blacklists. Este processo, normalmente, se dá quando uma ou mais contas do domínio é ‘invadida’, passando a fazer parte de uma Rede de SPAMMERS normalmente enviando centenas ou milhares de e-mails mundo afora.

Como saber se meu servidor está listado com Servidor de SPAM?

R.: Existem vários sites que pesquisam isto de forma simples, bastando informar o IP de um MX. Exemplos: Multirbl, MXToolBox, WhatIsMyIP e DNSBL.

Dica: verificar o que são DNSBL.

Qual a implicação de ter meu servidor de e-mails listado?

R.: Praticamente todos os serviços e servidores de e-mail, consultam Blacklists para saber se seus remetentes são maliciosos ou não. Se seu servidor estiver listado (dependendo da Lista), seus usuários não conseguirão se comunicar com Gmail, Hotmail, Yahoo além de vários domínios particulares (de clientes, de fornecedores e etc).

Em alguns dos sites acima, existem mais de 200 listas de SPAM a serem consultadas, ou seja, com uma consulta dá pra se ter uma noção de como está a saúde do(s) seu(s) servidor(es) de e-mail.

O processo de remoção de uma Blacklist não é padronizado e geralmente leva algumas horas ou até dias. Em resumo, se seu servidor estiver listado, o quanto antes você souber e iniciar o processo de remoção, melhor (quanto mais tempo listado, menos e-mails trocados e mais reclamação de TODOS os usuários de seu domínio).

No final do Post, veja as dicas de como verificar quem são seus servidores MX e de como testar os sites de Blacklists com IPs de Servidores listados como SPAM senders.

O que o Zabbix tem a ver com toda essa história?

Simples:

1. Quanto mais tempo em uma Blacklist, mais reclamações e problemas;
2. O SysAdmin tem mais coisas a fazer do que ficar consultando Blacklists manualmente de hora em hora…
3. O que você acha de ter “alguém” consultando isto pra você e te avisando em caso de IP listado?

Ambiente:

1. Servidor e cliente Zabbix nas versões 2.2.0 e 2.2.2 (versões mais recentes devem funcionar sem problemas).

Mão na massa: Como fazer o Zabbix monitorar as Blacklists.

Primeira tentativa

O esquema de consulta à Blacklist via DNSBL (ou RBL) é feito através de uma consulta DNS, com algumas particularidades. Mas ainda assim, é ‘apenas’ uma consulta DNS. O problema do ‘fazer’ via Zabbix era encontrar a fonte das consultas e montar uma rotina que consultasse a lista e informasse a situação do IP em todas as Blacklists.

Na pesquisa, procurei fontes que provessem alguma API de forma que eu passasse o IP e ela me retornasse SIM ou NÃO. Assim, conheci a NeutrinoAPI que integra uma grande série de consultas diferentes e fornece respostas em formato JSON, ideal pra se trabalhar da forma que pensei (é necessário criar uma conta e gerar uma Chave de acesso usada na API).

OBS: é possível executar os diversos testes da imagem acima direto pelo Navegador.

Pra tratar esses dados, aproveitei a Dica do grande André Déo, onde comenta sobre o Software JQ, que recebe dados em JSON e permite que se altere posições, nomes de campos e etc. No fim, minha intensão era gerar uma Lista com as Blacklists e consultar uma a uma, mas não deu certo.

Motivos:

1. Ao consultar um IP que havia saído de certa Blacklist, a API continuava retornando como se ainda estivesse listado (problemas de cache DNS, informado ao Suporte deles);
2. O tratamento dos dados exigia algumas “camadas” de conversão (o JQ não aceitou nomes de campos com hífen).

Melhor formato para resolver a situação

O primeiro problema (e o maior deles) era criar uma lista com as Blacklists. Na verdade, se tratava de copiar de algum lugar central e com isso preparar os demais comandos a usarem essa lista. Eu já utilizava com certa frequência o site MultiRBL para as consultas manuais, mas não havia explorado o link “Info about all RBLs“. Nele, está a chave para o sucesso! 😀 – Uma super-lista com as Blacklists mais famosas contendo, dentre outras coisas, o nome (2) e o servidor (3) que responde à consulta DNS para RBL. Excelente!

Próximo passo: criação de um Script que “sugue”, transforme os dados e crie uma lista só com as informações importantes. Este processo é feito por um script que utiliza o “$ wget” e o desconhecido (por mim, até então) “$ html2text”. Para transformar isso em funções e dados concretos, criei três arquivos:

1. O script (shell/bash) “dnsbl.sh“: acessa a página com as Blacklists, faz o Download do HTML, converte com o “html2text” e salva a lista tratada;
2. O arquivo “ignorar-blacklists.txt” trata alguns erros nas Blacklists como por exemplo, a APEWS que está fora do jogo há tempos, mas que não sai das consultas, além de outras listas em que é preciso ter um cadastro específico para poder consultar. É possível adicionar manualmente as entradas que queira remover das consultas;
3. O script “dnsbl-discovery.sh” que, como o próprio nome diz, cuida do LLD para que seja gerado um item para cada Blacklist e nossos IPs possam ser consultados em todas elas;
4. O arquivo “dnsbl.conf” contém os UserParameters necessários aos novos itens relacionados às Blacklists.

OBS: Estou monitorando as Blacklists como itens do meu servidor de e-mails (MX do domínio), ou seja, as configurações à seguir precisam ser feitas nele. Para quem for seguir o tutorial, é possível configurar a gosto (minha instalação de agente segue o seguinte caminho: “/usr/local/zabbix/“).

Para fazer tudo isso funcionar, é preciso acertar algumas coisas:

1. Instalar o “html2text” (apt-get install html2text ou yum install html2text -> Debian/Ubuntu ou CentOS/RedHat, respectivamente);
2. Editar o arquivo “zabbix_agentd.conf”, e habilite o ‘include’ (descomentando a diretiva) que aponta para o diretório “zabbix_agentd.conf.d”. No meu caso, ficou assim: “Include=/usr/local/zabbix/etc/zabbix_agentd.conf.d/“. É dentro deste diretório, que adicionaremos os UserParameters, como em outros tutoriais. É necessário a reinicialização do processo “zabbix_agented” (/etc/init.d/zabbix-agent restart;ps aux|grep -i zabbix) para aplicar as alterações no .conf;
3. Dentro do diretório /usr/local/zabbix/etc/zabbix_agentd.conf.d/ descompacte o arquivo “dnsbl.conf.gz”;
4. Crie os diretórios scripts e temp (no meu caso, dentro de /usr/local/zabbix/) e dê permissões ao Usuário/grupo zabbix de leitura e execução;
5. Dentro do diretório scripts, descompactar os arquivos “dnsbl-discovery.sh.gz” e “dnsbl.sh.gz” e dê permissão de execução para ambos. Nestes arquivos, procure a variável “ZABBIX_HOME=/usr/local/zabbix” e altere para a pasta base de sua instalação;
6. Dentro do diretório temp, descompactar o arquivo “ignorar-blacklists.txt.gz”.

O arquivo “dnsbl.conf” possui os novos itens relacionados às Blacklists. Estes itens é que serão cadastrados no Zabbix. Itens disponíveis:

up.dnsbl.discovery
up.dnsbl.ml
up.dnsbl.co
up.dnsbl.ls
up.dnsbl.cl[*]
up.dnsbl.ct[*]
up.dnsbl.h

Vamos aos primeiros testes.

Atenção: todos os testes à seguir, devem ser executados com o usuário zabbix. Este usuário é usado nas execuções que contém UserParameters e afins, por tanto, deve ter um shell válido no sistema e acesso aos diretórios citados abaixo.

Para comprovar que os passos anteriores deram certo, no diretório scripts, execute o script “dnsbl.sh” (sem passar nenhum parâmetro). A saída deve ser como esta:

./dnsbl.sh

Script para testar listas de DNS-BL afim de verificar se certo IP está listado como Remetente de SPAM.
-> Uso:
ml|montar_lista # Efetua o Download da lista em HMLT, converte para texto puro e monta em um formato "consultável" pelo Scripts.
co|contar_lista # Informa o tamanho da lista atual. Serve para controlar o Loop e pode ser utilizado como item informativo do Zabbix.
cl|consultar_dnsbl # Consulta um IP - informado como parâmetro 2 - em uma BlackList -informada como parâmetro 3-.
ct|consultar_dnsbl_todas # Consulta um IP -informada como parâmetro 2- todas as BlackList.
ls|listar_lista # Lista a lista com todas as Blacklists. Utilizado no Discovery e pode ser utilizado como item informativo do Zabbix.
ds|discover # Executa o discovery, devolvendo os Nomes e URLs das Blacklists -utilizadas no Zabbix- para criação de itens dinâmicos.
h|help # Mostra este Help
OBS: Todas as opções podem ser utilizadas em siglas ou completas.

Na execução sem parâmetros, o script retorna o “help”. Nele, as opções são auto-explicativas.

Para começar o trabalho, será preciso executar o script com a opção ml (ou montar_lista). Ela fará o Download e conversão dos dados no formato “consumível” pelo Zabbix.

./dnsbl.sh ml

O resultado deve ser algo como:

Para saber se realmente deu certo, acesse o diretório temp (no meu caso “/usr/local/zabbix/temp”) e verifique a presença do arquivo “blacklists.result”. Leia-o. Seu formato deve ser algo como:

OBS: Note que o arquivo tem três colunas (separadas por Pipes -> |). A primeira ainda é proveniente do Filtro inicial (para Info, WhiteList e BlackList). A segunda é o nome e a terceira o endereço pelo qual a Blacklist responde às consultas.

Seguindo a linha de testes, é interessante testar todos os possíveis parâmetros do script (com exceção do cl e ct por enquanto):

./dnsbl.sh co
retorno -> 250 (pode ser mais ou menos)
./dnsbl.sh ls
retorno -> todos as entradas da lista
./dnsbl.sh ds
retorno -> todos os elementos da lista no formato JSON (para LLD Zabbix)

Os parâmetros cl e ct servem para efetuar a consulta propriamente dita. O cl consulta uma lista, usando o IP passado como parâmetro. Exemplo:

./dnsbl.sh cl 111.224.250.131 bl.technovision.dk
Possíveis resultados:
0 -> IP não está listado na Blacklist especificada;
1 -> IP está listado na Blacklist
255 -> Erro ao processar a consulta (ou lista não existe ou erro do comando 'dig').

./dnsbl.sh ct 111.224.250.131

Retorno: uma sequência de números da consulta anterior. Como o Script consulta todas as listas em "/usr/local/zabbix/temp/blacklists.result", mostrará uma sequência de 0's, 1's ou 255's (misturados entre si). 

Exemplo:

O teste final é feito com o binário do Agente Zabbix. Pra isso, localize o diretório sbin de sua instalação Zabbix (no meu caso “/usr/local/zabbix/sbin”). Lá, execute o seguinte comando:

./zabbix_agentd -t up.dnsbl.co
Resultado deve ser algo como:
up.dnsbl.co                                   [t|250]

Experimente executar com os outros UserParameters encontrados em “/usr/local/zabbix/etc/zabbix_agentd.conf.d/dnsbl.conf” para verificar se o agente responderia e como responderia aos novos itens.

Com isso, encerramos os testes e podemos partir para o Zabbix! (até que enfim! :D).

OBS: se algo não funcionou volte, releia e refaça os passos principalmente com relação aos locais, edição de variáveis e permissões de arquivos.

Configuração do Zabbix

Importante: Antes de prosseguir com a criação dos itens, verifique num dos sites para consulta de Blacklists, se o IP do seu servidor está marcado como SPAMMER (o MultiRBL é o mais interessante).

Criação do mapeamento de valores (Value mapping): vá até Administração (Administration) -> Geral (General) -> Mapeamento de Valores (Value mapping):

crie um novo “Value mapping” com os seguintes dados:

Criação de uma regra de Discovery (LLD): a regra irá gerar ao menos um item que é a consulta em todas as Blacklists para um determinado IP. Tentei criar essa regra e o item em um Template (algo como Template_servidor_emails), mas não dá certo devido a alteração do protótipo de item não ser possível a nível de Host (que será atrelado ao Template). Então, é criar direto no Host mesmo:

Este LLD retorna as seguinte macros:

1. {#LISTA_NOME} – nome da lista indicado por campo 2 do arquivo “blacklists.result”. Para fins de cadastro de item com nome amigável no Zabbix;
2. {#LISTA_URL} – URL da lista indicado por campo 3 do arquivo “blacklists.result”. Para consulta DNS e verificação da Blacklist

Alterei o “Update interval” para cinco minutos (300 segundos), para que vejamos mais rapidamente os dados sendo coletados. Porém, como o processo de buscar a lista completa é oneroso e não tem necessidade de se repetir muitas vezes, um valor razoável para este parâmetro seria 3600 (uma hora).

Criação do protótipo de item: este item não é nada mais que um modelo para ser preenchido pelos dados provenientes do Discovery LLD.

A chave “up.dnsbl.cl[IP-DO-MX,{#LISTA_URL}]” deve conter o IP do MX como primeiro parâmetro. Em “Show value” deverá conter o “Value mapping” configurado anteriormente. O “New application” servirá para vermos em “Lastest data” (dados recentes), como está a atualização dos novos itens. Este protótipo só cadastrará um IP de Servidor MX. Caso possua mais de um, será necessário criar tantos itens de protótipo quanto o número de IPs a consultar.

Verificação dos resultados

Para ter certeza de que tudo correu bem, depois dos cadastros acima, aguarde de 5 a 10 minutos e verifique em “Dados Recentes” (Lastest data) se os novos itens estão sendo processados:

Veja que, para cada lista (identificada pelo Nome), existe um valor de retorno em “Lastest value” de acordo com o “Value mapping” configurado anteriormente.

Outro local para verificar é nos itens do próprio Host:

Considerações finais

Este tutorial não tem a intenção de esgotar o assunto, ou seja, não mostra todas as formas de fazer algo e sim a que me pareceu mais simples e sistemática. Todos os passos aqui descritos, foram feitos e testados no momento em que eram executados. Se algo não der certo, verifique os passos e repita-os novamente. Apesar disso, erros podem ocorrer por uma digitação errada no momento da criação do material. Isso é super-comum.

Ademais, aqui só está sendo mostrado como fazer o principal: criar a lista, montar o LLD e o item de verificação (único ou múltiplo). A seguir, indicações de itens importantes.

A fazer:

1. É importante aprender a lidar com o portal MuitlRBL. Nele, algumas listas são do Tipo Blacklist outras Whitelist dentre outros Tipos. Estes scripts apresentados aqui, só levam em consideração o Tipo Blacklist, mas é preciso ficar de olho em listas informacionais e tira-las das verificações, caso necessário (evitando falsos-positivos);
2. Algumas listas podem informar falsos-positivos quanto a listar o IP pesquisado. Caso queira remover certa lista das próximas verificações, adicionar a URL dela no arquivo “/usr/local/zabbix/temp/ignorar-blacklists.txt”;
3. Criar um item (direto no Host e não como protótipo) para atualização da lista diariamente com o item “up.dnsbl.ml”(com valor de retorno do tipo Texto). Cuidado no tempo de atualização, não é necessário atualizar a lista mais de uma vez por dia;
4. Criar um item (direto no Host e não como protótipo) para contar a quantidade de entradas na lista: “up.dnsbl.co”;
5. Criar “Triggers prototypes” para gera alertas caso o IP caia em uma das listas;
6. Criar novos UserParameters (por sua conta) que informem a quantidade de Blacklists em que o IP está listado (item com retorno numérico para geração de Gráficos);
7. Criar novos LLDs (por sua conta) que, ao invés de informar um IP do MX, informemos o domínio e automaticamente o Zabbix pegue todos os MX deste.

Outras dicas:

Como saber meus MX?

Simples: caso não tenha familiaridade com os comandos “nslookup” ou “dig”, sites como o Kloth permitem descobrir quaiquer registros DNS.

Como testar com IPs de SPAMMERS?

Para testar o script “dnsbl.sh” com um IP que é realmente um SPAMMER, acesso o site do Projeto Honeypot, na lista de “Spam Servers“copie um dos IPs e execute o script com os parâmetros necessários:

./dnsbl.sh ct IP-SPAMMER

Conclusão:

Agradeço pelo interesse em meu trabalho e peço desculpas caso não tenha encontrado aqui o que deseja. Apesar de tudo, o que me levou a publicar este material foi a necessidade que tive de resolver problemas como os citados nele. Espero que sirva igualmente aos colegas de profissão e que os que desejarem melhorar isto tudo, estejam à vontade.

Mais informações: Homepage da Comunidade Brasileira e lista de discussão oficial da mesma.

Abraço!