Protegendo um novo VPS

O que realmente compromete servidores

Não são zero-days. Na prática: força bruta de senha SSH contra credenciais fracas, serviços não corrigidos deixados rodando por meses, painéis administrativos expostos com senhas padrão e vulnerabilidades de aplicativos no que o operador instalou. A lista é entediante e não mudou em quinze anos.

A lista abaixo está ordenada por quanto risco cada passo remove por minuto gasto. Faça em ordem e pare quando ficar sem paciência — você ainda terá removido a maior parte do risco.

Passo 1 — Apenas chaves SSH

Essa única mudança elimina o ataque mais comum por completo. Gere uma chave Ed25519, copie a parte pública para o servidor e edite /etc/ssh/sshd_config para definir PasswordAuthentication no, PermitRootLogin prohibit-password e KbdInteractiveAuthentication no.

Teste a chave em um segundo terminal antes de fechar o primeiro. Ficar trancado para fora é embaraçoso e, em uma máquina com acesso ao console, totalmente recuperável — mas faça na ordem certa mesmo assim.

Etapa 2 — firewall com bloqueio por padrão

Use nftables no Debian e Ubuntu modernos, ou firewalld em derivados do RHEL. Bloqueie por padrão o tráfego de entrada, permita conexões estabelecidas e relacionadas, permita a porta SSH, permita o que a carga de trabalho realmente precisa e nada mais.

A disciplina importante é que "nada mais" é o ponto central. Um firewall com uma regra permissiva adicionada durante a depuração e nunca removida é um firewall que não está fazendo nada.

• Política padrão: bloquear entrada, aceitar saída
• Aceitar conexões estabelecidas e relacionadas
• Aceitar loopback
• Aceitar sua porta SSH, idealmente com limite de taxa
• Aceitar portas da carga de trabalho, listadas explicitamente
• Aceitar ICMP echo — não quebre a descoberta de MTU de caminho

Etapa 3 — atualizações de segurança automáticas

unattended-upgrades no Debian e Ubuntu, dnf-automatic em derivados do RHEL, configurados apenas para atualizações de segurança. A maioria dos comprometimentos explora vulnerabilidades corrigidas meses antes.

Ative a reinicialização automática em uma janela de manutenção se sua carga de trabalho tolerar. Atualizações de kernel não fazem nada até a máquina reiniciar, e um servidor com 400 dias de uptime e onze CVEs de kernel pendentes não é um distintivo de honra.

Etapa 4 — fail2ban e uma nota sobre seu valor real

Com a autenticação por senha já desabilitada, o fail2ban impede relativamente poucos comprometimentos reais. O que ele faz é reduzir drasticamente o ruído dos logs, o que importa porque um log cheio de milhares de tentativas falhas é um log que ninguém lê, e logs não lidos são como intrusões reais passam despercebidas por semanas.

A jail sshd padrão é suficiente. Adicione jails para qualquer outra coisa que você exponha à internet.

Etapa 5 — reduza a superfície de ataque

Execute ss -tlnp e veja o que está escutando. Em uma instalação padrão, isso geralmente inclui serviços que você não sabia que estavam rodando e não precisa. Remova-os em vez de bloqueá-los com firewall — software que não está instalado não tem vulnerabilidades.

Vincule serviços que só precisam de acesso local a 127.0.0.1 em vez de 0.0.0.0. Um banco de dados escutando em todas as interfaces atrás de um firewall está a uma má configuração de se tornar público.

O que pular

Mudar a porta SSH reduz o ruído dos logs e impede exatamente zero ataques direcionados. Faça se quiser, mas não conte como segurança. Port knocking adiciona fragilidade para um ganho marginal. Sistemas de detecção de intrusão geram alertas que ninguém tria em um único servidor.

Se você quiser mais uma etapa significativa após as cinco acima, é backups criptografados fora do local em uma jurisdição diferente, testados restaurando-os de fato. Capacidade de recuperação vale mais do que outra camada de prevenção.