Hardening e vulnerabilidades

Bloquear ataques é metade do trabalho; a outra metade é fechar o que os deixou entrar. Cada servidor executa uma verificação de hardening e uma auditoria de software 10 minutos depois que o agente inicia, e depois uma vez por dia. Verificar agora e Verificar software agora, na aba Segurança do servidor, as executam na hora.

A verificação de hardening#

Ela examina:

• SSH: login como root, autenticação por senha, a porta padrão, X11 forwarding, número máximo de tentativas de autenticação;
• arquivos: permissões de /etc/shadow, /etc/passwd, sshd_config e do authorized_keys do root;
• portas: serviços escutando na rede pública;
• usuários: contas com UID 0 além do root, contas sem senha;
• firewall e processos (zumbis);
• credenciais: arquivos .env legíveis por todos, diretórios .git expostos nas raízes web, as permissões dos diretórios .ssh;
• servidor web: exposição da versão, listagem de diretórios, o método TRACE, protocolos TLS, cabeçalhos de segurança, limitação de taxa, tamanho do corpo das requisições e configurações de desempenho;
• versões: sistema operacional em fim de vida, kernel, atualizações de segurança pendentes, PHP, MySQL, OpenSSH e o servidor web.
• PHP: a configuração de cada runtime do PHP e de cada pool do PHP-FPM (veja Hardening do PHP mais abaixo).

Cada verificação explica o que é, por que importa e como corrigir.

As verificações de SSH leem a configuração que o sshd realmente usa: sshd -T ou, quando ele não pode rodar, os arquivos na mesma ordem do sshd (agente 1.0.35 ou mais recente). O sshd fica com o primeiro valor que lê, e nas distribuições atuais o sshd_config inclui os drop-ins de /etc/ssh/sshd_config.d/ logo no início, então um drop-in vence: em um servidor cloud recém-criado, o 50-cloud-init.conf do cloud-init muitas vezes reativa o login com senha. O resultado indica o arquivo e a linha que definem o valor, por exemplo /etc/ssh/sshd_config.d/50-cloud-init.conf:1: altere-o ali.

Quantas verificações um servidor recebe depende do servidor: de 40 a 50 na maioria. As verificações do servidor web dependem de estarem instalados o nginx, o Apache ou os dois, e as verificações de PHP (de seis a nove) são feitas para cada runtime de PHP e cada pool do PHP-FPM, então um servidor com muitos pools recebe mais.

Correções com um clique#

Dez verificações podem ser corrigidas com Corrigir automaticamente:

O InfraFence grava cada alteração em um arquivo próprio (/etc/ssh/sshd_config.d/00-infrafence-hardening.conf, ou zz-infrafence-hardening.conf para nginx e Apache), testa a configuração (sshd -t, nginx -t, apachectl configtest) e recarrega o serviço: sessões e conexões abertas não são cortadas. Desfazer correção reverte a alteração.

Algumas verificações nunca são automáticas, porque, feitas de forma errada, poderiam trancar você do lado de fora ou mudar o comportamento dos seus sites: login como root, autenticação por senha, a porta SSH, listagem de diretórios, protocolos TLS e cabeçalhos de segurança. A página de cada uma explica como corrigi-la manualmente. Em um servidor cuja configuração é controlada por um painel de hospedagem ou por uma ferramenta de gerenciamento de configuração, só as correções de permissões são automáticas.

Hardening do PHP#

A verificação lê a configuração efetiva de cada runtime do PHP no servidor: o PHP da distribuição, ondrej, remi, cPanel EA4, Plesk e CloudLinux alt-php. Ela segue o php.ini e o diretório de varredura na mesma ordem do PHP, e verifica cada pool do PHP-FPM com suas substituições php_value e php_admin_value. O PHP de linha de comando não é verificado.

"Com aprovação" exige a autenticação de dois fatores. As correções de cgi.fix_pathinfo e disable_functions só são aplicadas por um proprietário ou admin com sessão iniciada com autenticação de dois fatores: com Revisar e aplicar na aba Segurança do servidor, ou em Aprovações quando o AutoMode pede. Sem 2FA o painel não as aplica. Ative-a em Configurações › Segurança.

Cada achado indica o runtime, o pool, o valor e o arquivo e a linha de onde vem. Antes de você aprovar uma correção de disable_functions, o painel lista os arquivos dos sites que chamam essas funções (até 20).

As correções vão num arquivo do próprio InfraFence, zz-infrafence-hardening.ini no diretório de varredura do runtime; o php.ini e os arquivos dos seus pools nunca são editados. Quando um pool define o valor no próprio arquivo, um drop-in não consegue substituí-lo: o achado indica então a linha exata a mudar manualmente nesse arquivo. O agente testa a configuração (php-fpm -t), confere que o novo valor é o efetivo, recarrega o PHP-FPM sem interrupção (nunca um reinício) e faz a mesma verificação de sites das outras correções: se um site parar de responder, a mudança é desfeita. Uma correção no arquivo do runtime vale para todos os pools desse runtime que não definem o valor por conta própria.

O agente também vigia esses arquivos. Quando allow_url_include ou display_errors é ativado, o evento Configuração PHP arriscada apareceu indica o arquivo, uma vez por mudança. Se outra pessoa ou ferramenta alterar o arquivo do InfraFence (um painel, um pacote, alguém), você também recebe um evento.

No cPanel, Plesk e CloudLinux a configuração do PHP é informada, nunca alterada, e os arquivos por site (o php.ini do Plesk, o .user.ini do cPanel) são apenas informados.

É hardening e vigilância da configuração. Nada é carregado no PHP e isso não impede um ataque dentro da sua aplicação: essa parte fica com o firewall web e o scanner de malware.

Verificação e rollback#

Antes de uma correção, o agente anota quais portas SSH aceitam conexões e quais sites respondem sem erro de servidor, por HTTP e HTTPS (até 20 sites). Depois do reload, ele os verifica de novo por até 20 segundos. Se algum parar de responder, ele desfaz a alteração sozinho e o resultado mostra Desfeita pelo servidor. As correções de permissões não têm rollback: um modo mais restritivo não quebra um serviço.

A mesma verificação protege o fechamento de portas, os bloqueios de saída e os patches virtuais.

Vulnerabilidades (CVE)#

A auditoria de software envia a lista de pacotes instalados ao painel, que a compara com o banco de dados OSV. Isso funciona em Debian, Ubuntu, AlmaLinux e Rocky Linux. O quadro Vulnerabilidades (CVE) lista os pacotes com correção disponível e marca os que estão na lista da CISA de vulnerabilidades sabidamente exploradas (Explorada ativamente (CISA KEV)): atualize esses primeiro.

Atualizações de segurança#

Atualizar todos ou Atualizar este pacote instala as versões corrigidas. O agente atualiza apenas esses pacotes (nada novo é instalado ou removido), mantém os seus arquivos de configuração, se recusa a começar enquanto outra operação de pacotes estiver em andamento e nunca reinicia o servidor. A atualização de um pacote pode reiniciar o serviço dele por um instante. Quando é preciso reiniciar o servidor, ou um serviço ainda roda código antigo, o resultado avisa.

Pontuação de segurança#

Os resultados alimentam a pontuação de segurança do servidor, de 0 a 100, com as principais correções listadas primeiro. Veja Servidores.