Hardening de Servidores Web: O Checklist Definitivo de Segurança (2026)

By HelpSysAdminMonitoramento e Troubleshooting (Diagnóstico)

Hardening de Servidores. Este é um guia estruturado de Hardening (Endurecimento) focado em ambientes de produção. O objetivo não é apenas “fechar portas”, mas aplicar o conceito de Defesa em Profundidade (Defense in Depth), onde múltiplas camadas de segurança se sobrepõem para proteger o servidor caso uma delas falhe.

Aqui está o checklist definitivo para SysAdmins, cobrindo desde o Sistema Operacional até a Aplicação.

1. Sistema Operacional (A Fundação)

Antes de instalar qualquer serviço web, o sistema base (AlmaLinux, Debian, Ubuntu, etc.) deve estar seguro.

  • Princípio do Menor Privilégio: Nunca opere como root. Crie um usuário com sudo e use-o para administração.
  • Atualizações Automáticas: Configure atualizações de segurança automáticas (ex: dnf-automatic no RHEL/AlmaLinux ou unattended-upgrades no Debian).
  • Particionamento Seguro: Se possível, monte partições como /tmp, /var/tmp e /dev/shm com as flags noexec e nosuid para impedir a execução de scripts maliciosos em diretórios temporários.
  • Remoção de Bloatware: Remova pacotes desnecessários. Se o servidor é web, ele não precisa de cups (impressão), X11 (interface gráfica) ou avahi-daemon.

2. Acesso SSH (A Porta de Entrada)

A maioria dos ataques automatizados visa a porta 22.

  • Autenticação via Chave SSH: Desabilite login por senha. Apenas chaves Ed25519 ou RSA (4096 bits).
  • Porta Personalizada: Mude a porta padrão (22) para algo acima de 1024 (ex: 50222) para evitar scanners de massa básicos.
  • Desativar Root Login: No sshd_config, defina PermitRootLogin no.
  • Restrição de Usuários: Use a diretiva AllowUsers para permitir login apenas de usuários específicos.
  • Autenticação de Dois Fatores (2FA): Implemente Google Authenticator ou similar no SSH para uma camada extra crítica.
  • Clique aqui e veja o artigo SSH seguro além de mudar a porta

3. Firewall e Rede (O Perímetro)

O tráfego deve ser filtrado antes de tocar nos seus serviços.

  • Feche tudo, abra o necessário: A política padrão (INPUT) deve ser DROP. Abra apenas portas essenciais (80, 443 e sua porta SSH personalizada).
  • Ferramentas de Gestão:
    • CSF (ConfigServer Security & Firewall): Excelente para servidores cPanel/DirectAdmin, com interface gráfica e detecção de ataques.
    • UFW/Firewalld: Para setups mais limpos/manuais.
  • Proteção contra Brute-Force (IPS):
  • Bloqueio de ICMP: Desabilite respostas de Ping (ou limite a taxa) para evitar reconhecimento de rede e flood.

4. Web Server (Nginx, Apache, LiteSpeed)

A configuração padrão dos servidores web quase sempre expõe informações desnecessárias.

  • Ocultar Versão (Security via Obscurity):
    • Nginx: server_tokens off;
    • Apache: ServerSignature Off e ServerTokens Prod
    • LiteSpeed: Desative “Server Signature” no WebAdmin.
  • Cabeçalhos de Segurança (HTTP Headers): Implemente para mitigar XSS e Clickjacking:
    • Strict-Transport-Security (HSTS)
    • X-Frame-Options: SAMEORIGIN
    • X-Content-Type-Options: nosniff
    • X-XSS-Protection: 1; mode=block
  • TLS/SSL Robusto:
    • Desabilite TLS 1.0 e 1.1. Use apenas TLS 1.2 e 1.3.
    • Use cifras fortes (High Ciphers).
  • WAF (Web Application Firewall): Utilize ModSecurity com as regras da OWASP ou soluções proprietárias (como o WAF do Imunify360 ou CloudLinux) para filtrar injeções SQL e XSS em tempo real.

5. PHP e Aplicação (Onde o Código Roda)

Se o atacante passar pelo firewall e pelo Nginx, ele tentará explorar o PHP.

  • Desativar Funções Perigosas: No php.ini, use disable_functions para bloquear: exec, passthru, shell_exec, system, proc_open, popen, curl_exec, curl_multi_exec, parse_ini_file, show_source.
  • Open_basedir: Restrinja o PHP a ler arquivos apenas dentro do diretório do site do usuário, impedindo que um script invadido leia o /etc/passwd.
  • Ocultar Erros: Em produção, display_errors = Off. Erros devem ir para o log, nunca para a tela do usuário (vazamento de path).
  • Permissões de Arquivo:
    • Arquivos: 644 (Leitura/Escrita para dono, Leitura para outros).
    • Pastas: 755 (Execução/Leitura/Escrita para dono, Leitura/Execução para outros).
    • Configurações sensíveis (wp-config.php, .env): 600 ou 400.

6. Monitoramento e Auditoria (Visibilidade)

Você não pode proteger o que não vê.

  • Logs Centralizados: Se possível, envie logs para um servidor remoto ou serviço (ELK Stack, Graylog) para que, se o servidor for comprometido, os logs não sejam apagados.
  • Detecção de Intrusão (HIDS):
    • Wazuh: Uma solução completa XDR/SIEM que monitora integridade de arquivos (FIM), rootkits e conformidade.
    • Maldet (Linux Malware Detect): Scan periódico de malware em diretórios de upload.
  • Monitoramento de Recursos: Zabbix, Prometheus ou Netdata para identificar picos de CPU/RAM que indiquem mineração de cripto (cryptojacking) ou DDoS.

7. Backup e Recuperação (O Plano Z)

Hardening reduz o risco, mas não o elimina.

  • Regra 3-2-1: 3 cópias, 2 mídias diferentes, 1 local off-site (fora do data center original).
  • Imutabilidade: Se possível, use armazenamento de backup imutável (ex: AWS S3 Object Lock) para se proteger contra Ransomware que criptografa backups.
  • Teste de Restore: Um backup que nunca foi restaurado é apenas um arquivo ocupando espaço. Teste a recuperação mensalmente.

FAQ

O que é Hardening de Servidor e por que é essencial?

Hardening (ou endurecimento) é o processo de reduzir a superfície de ataque de um servidor, removendo softwares desnecessários, fechando portas não utilizadas e configurando o sistema operacional e serviços (como Nginx e PHP) com políticas restritivas. É essencial para prevenir invasões, vazamento de dados e garantir a estabilidade em ambientes de produção.

Qual a diferença entre um Firewall de Rede e um WAF?

O Firewall de Rede (como CSF, UFW ou Firewalld) filtra o tráfego baseado em portas e IPs (camadas 3 e 4), decidindo quem pode conectar ao servidor. Já o WAF (Web Application Firewall, como ModSecurity ou Cloudflare) analisa o conteúdo do tráfego HTTP/HTTPS (camada 7), bloqueando ataques específicos à aplicação, como SQL Injection e XSS.

É seguro usar autenticação por senha no SSH?

Não. Em ambientes de produção, recomenda-se desativar completamente o login por senha e utilizar apenas Chaves SSH (SSH Keys). Senhas são vulneráveis a ataques de força bruta (brute-force), enquanto chaves criptográficas oferecem um nível de segurança exponencialmente maior.

Como proteger o PHP em servidores de produção?

As melhores práticas incluem: desativar a exibição de erros (display_errors = Off), desabilitar funções perigosas no php.ini (como exec e shell_exec), restringir o acesso a arquivos com open_basedir e garantir que as permissões de arquivos e pastas estejam corretas (644 e 755, respectivamente).

Veja Mais:Segurança no WordPress em nível de servidor
Veja Mais:Mover o WordPress do Localhost para o Servidor online: Guia Prático e Seguro
Veja Mais:O que ninguém te conta sobre gerenciar servidores em produção
Veja Mais:Como Proteger seu Servidor Linux Contra Invasões: O Guia Essencial de Hardening
Veja Mais:Como instalar Crowdsec