NexTool Solutions

A sua instância do GLPI está exposta a vulnerabilidades já catalogadas e não sabe? Na maioria dos parques que assumimos em sustentação, ninguém consegue responder de imediato qual CVE afeta a versão em produção nem se o PHP tem os sinalizadores de segurança corretos. O módulo CVE Scan Vulnerabilidades do NexTool cruza a versão instalada com bases públicas de CVE e audita 19 pontos críticos do ambiente em segundos, gerando um Security Score visual.

O problema

As equipas de service desk que operam o GLPI raramente têm um processo formal para rastrear as vulnerabilidades associadas à versão em produção. O NVD (NIST) e a GitHub Advisory Database publicam CVEs continuamente, mas acompanhar isso à mão, versão a versão, é inviável para quem também abre e fecha pedidos o dia inteiro.

Pior: a versão do software é apenas metade do risco. O ambiente PHP e a configuração do servidor introduzem falhas silenciosas - display_errors ativo em produção a expor caminhos e stack traces, um cookie de sessão sem HttpOnly, a ausência de Content-Security-Policy ou de Strict-Transport-Security. Cada um destes detalhes é uma superfície de ataque que costuma aparecer apenas depois do incidente, quando já é tarde.

Como funciona o CVE Scan

Ao executar a análise, o módulo deteta a versão pela constante GLPI_VERSION e cruza com uma base dinâmica de CVEs montada a partir de três fontes:

• NVD / NIST - a fonte autoritativa para a pontuação CVSS e os metadados oficiais de cada falha.
• GitHub Advisory Database - os advisories publicados pelo próprio projeto GLPI, com as versões afetadas e a versão que corrige cada falha por linha de versão (como 10.0 e 11.0), além da ligação do advisory.
• Base estática de recurso - lista integrada no módulo com as falhas críticas e altas, usada antes da primeira atualização da base e em ambientes que não chegam ao GitHub nem ao NVD.

A junção é feita por CVE ID: o NVD prevalece para o CVSS, o GitHub entra com os intervalos de versões e as ligações de advisory. A base local é atualizada todos os dias por uma tarefa automática e, a pedido, pelo botão Atualizar base; a análise em si não consulta o GitHub nem o NVD, e se as duas fontes falharem a base anterior continua em vigor. Em paralelo ao cruzamento de CVEs, o módulo executa 19 verificações de segurança do ambiente, agrupadas em cinco categorias: configuração do PHP (8 checks), verificações específicas do GLPI (4, entre elas as palavras-passe predefinidas das contas de instalação), cabeçalhos HTTP (4), permissões de ficheiros (2) e versão do PHP (1), que aponta PHP fora do suporte de segurança. O resultado torna-se um Security Score de 0 a 100, com faixa de cor - vermelho para crítico, amarelo para moderado e verde para saudável - e cada item mostra o estado, a versão que corrige a falha e a instrução de correção.

O que vê e que o GLPI nativo não mostra

O que aprendemos a executá-lo no terreno

Na sustentação, o check que mais reprova num ambiente de cliente é o session.cookie_secure - e quase sempre a causa está fora do GLPI. O GLPI está atrás de um proxy inverso que termina o TLS, por isso o PHP vê a ligação como http e não marca o cookie como seguro. A correção não é no GLPI: é acertar o cabeçalho X-Forwarded-Proto no proxy e forçar HSTS na fronteira. O segundo campeão é o diretório install/ esquecido depois do setup. O GLPI até avisa disso no ecrã de início de sessão, mas num parque de dezenas de instâncias esse aviso passa despercebido - é o score consolidado que obriga a equipa a olhar. Por isso tratamos o CVE Scan como termómetro, não como veredicto: aponta o ponto, mas a decisão de corrigir na origem certa continua a ser de quem sustenta o ambiente.

Verificar os mesmos pontos à mão

Antes de instalar seja o que for, consegue reproduzir parte do diagnóstico diretamente no servidor. Estes são exatamente alguns dos pontos que o módulo audita no PHP e no sistema de ficheiros:

# Sinalizadores de PHP que o CVE Scan audita (executar no servidor do GLPI)
php -i | grep -Ei 'display_errors|expose_php|allow_url_include|cookie_httponly|cookie_secure'

# Permissao do ficheiro de credenciais da base de dados: deve ser 400 ou 440, nunca 644
stat -c '%a %n' /var/www/glpi/config/config_db.php

# Diretorio de instalacao que deveria ter sido removido apos o setup
test -f /var/www/glpi/install/install.php && echo 'ALERTA: install/ ainda presente - remover'

# Versao do PHP: alertar se estiver em fim de vida (EOL)
php -r 'echo PHP_VERSION, PHP_EOL;'

O módulo automatiza isto, adiciona o cruzamento com as bases de CVE e guarda o histórico - mas executar os comandos acima já mostra porque a auditoria manual não escala para além de duas ou três instâncias.

Como ativar

1. Instale o plugin NexTool no seu GLPI.
2. Aceda a Configuração > NexTool > Módulos.
3. Localize o cartão CVE Scan Vulnerabilidades, clique em Instalar e depois em Ativar.
4. Abra o módulo e, no Painel, clique em Atualizar base e depois em Executar scan.
5. Opcional: indique um token do GitHub e uma API Key do NVD no separador de configurações para elevar os limites de pedidos das bases externas.

Para quem é indicado (e quando não)

É indicado para administradores de GLPI que precisam de uma auditoria de segurança rápida e recorrente, equipas que enfrentam auditorias internas ou externas e precisam de evidência do estado do ambiente, e gestores que querem acompanhar a postura de segurança ao longo do tempo pelo histórico de análises. Não é uma solução mágica: não substitui um pentest, não corrige nada sozinho e não deve virar desculpa para adiar a atualização do GLPI. Se o seu ambiente já tem um scanner corporativo (Nessus, Qualys) a apontar para o mesmo anfitrião, o CVE Scan é um complemento leve e específico do GLPI, não um concorrente.

Compatibilidade

• GLPI: 10.x e 11.x
• Plano: FREE
• Plugin: NexTool 6.11.0 ou superior

Próximo passo

O CVE Scan Vulnerabilidades faz parte do NexTool, plugin modular para GLPI. Conheça os restantes módulos ou fale com a equipa para uma avaliação de segurança completa do seu ambiente.

Revisto pela equipa NexTool Solutions.