çãA utilização da ferramenta opensource Zabbix no dia-a-dia de profissionais de TI é fundamental para garantir a estabilidade de ambientes, obtendo dados de sinais vitais e outras opções. Dentre essas outras opções, conforme necessidade e contexto, é possível explorarmos a ferramenta também como apoio na descoberta de vulnerabilidades de sistemas.
Neste post, falarei um pouco sobre como podemos rastrear vulnerabilidades em sistemas de forma a captar a constante mudança nos ambientes (coleta) e análise dos mesmos (decisão).
CVE-2022-0847
Ao início deste ano, a referida vulnerabilidade também conhecida por Dirty Pipe, trouxe a conhecimento uma vulnerabilidade do Kernel Linux em algumas versões que permitia a escalada de privilégios no sistema por usuário não autorizado. Essa vulnerabilidade afeta versões do Kernel acima de 5.8 e está descrita como corrigida (data da publicação do dia) para versões 5.16.11, 5.15.25 e 5.10.102 ou superiores. Neste post, nosso foco NÃO será a correção ou discussão sobre a vulnerabilidade, mas sim, como podemos captá-la.
Ok, como podemos então descobrir dentro de um parque de hosts, grandes ambientes, servidores… quais estão com a versão afetada?
MEIOS PARA ANÁLISE
Com base no problema, possíveis forma seriam acessar cada sistema e verificar sua versão, ou talvez, com alguma ferramenta extrair uma planilha e verificar quais são vulneraveis. Ainda que formas “efetivas”(e custosas), como manter essa informação atualizada e garantir a análise constante dos sistemas? repetir todo processo?
E que tal, definir uma coleta com intervalo automático, que faça análise prévia e alerte informe assim que o gatilho for atingido?
ZABBIX: COLETAR, DECIDIR E INFORMAR
Nativamente, a ferramenta possui uma chave para coletar do zabbix-agent do seu host monitorado qual a versão do sistema operacional está sendo executada. Esse item já tem coleta incluída por padrão em templates standard pós instalação, como o Linux by Zabbix agent, utilizando o item com chave de coleta system.uname
Assim, cada host com template terá a versão coletada com a mesma saída do comando no terminal ‘uname -a’, sendo abaixo destacado é a versão do kernel do sistema:
PROCESSANDO
Sem precisar gerar novas coleta, criamos um item dependente que obtém o valor do item Pai (imagem acima) e extraímos via Pré-processamento as informações desejadas. Nesse pré-processamento, utilizamos Expressões Regulares (POSIX Basic Regular Expressions) dentro de um script JavaScript, isso pois, nossa saída retornará True or False, 1 ou 0 respectivamente caso haja o Match.
Exemplos das expressões utilizas no código JS:
Expressão1: /\b(5\.([8-9]|[0-9][0-9])\.[0-9]+)+./g #Matches para todas versões 5 ou superiores
Expressão2: /\b(5\.((1[5-9]+)|([2-9][0-9]+))\.[0-9]+)+/g #Matches para algumas versões corrigidas
Basicamente, com uma estrutura condicional de código, definimos se o item é vulnerável
**Observe que o exemplo é enxuto, abrangendo este caso, a medida que se você identificar novas versões corrigidas ou vulneráveis, poderá expandi-lo.
Basicamente, com uma estrutura condicional de código, definimos se o item é vulnerável (value = 1) ou não vulnerável (value = 0). A partir disso cria-se uma trigger para alertar no caso positivo
- Item dependente:
- Pré-processamento:
- Trigger:
E assim, captamos nossos equipamentos para tomar a devida atenção e corrigirmos:
Note que, havendo qualquer alteração necessária, basta alterar em um único ponto para mudar sua referência e, melhor ainda, com coletas e análises constantes e automáticas;
CONCLUSÃO
Nesse post exploramos um exemplo de caso, mas, tantos outros são aplicados dia-a-dia e podem facilitar a rotina dos administradores de rede a identificar falhas em seu sistemas. Outros casos são, por exemplo, monitorar a página de CVE’s para uma determinada aplicação, e quando houver uma nova publicação gerar um alerta para informar, ou, verificar a versão de um aplicativo específico (apache, log4j, etc…) e alertar caso esteja em determinada versão.
Gilberto Knoerbes
Analista de Infraestrutura Pleno da Unirede