Proteger um novo VPS na primeira hora

Observe o journalctl -u ssh em um servidor que está online há uma hora e o volume vai assustar na primeira vez que você ver. Não deveria. O que você está vendo é a radiação de fundo da internet: um punhado de operações de varredura, algumas acadêmicas, algumas comerciais, algumas criminosas, que enumeram o espaço IPv4 inteiro continuamente e entregam os resultados a bots de adivinhação de credenciais. Seu endereço foi alcançado porque existe, em ordem numérica, e será alcançado de novo em algumas horas, faça você o que fizer.

Isso muda o formato do problema de um jeito útil. Você não está se defendendo de um adversário que escolheu você e vai se adaptar; você está se defendendo de um script com um repertório fixo — root, admin, ubuntu, test, git, oracle, postgres, e as vinte mil senhas que já apareceram em vazamentos de dados. Ele não tem paciência, não tem criatividade e nenhum interesse em uma máquina que não responde de primeira. Desligar a autenticação por senha não desacelera esse atacante. Isso o tira do tabuleiro por completo.

Dois detalhes valem a pena saber. Primeiro, o IPv6 é dramaticamente mais silencioso, porque um /64 não pode ser varrido por completo — mas no momento em que seu registro AAAA se torna público, ou o endereço da sua máquina aparece em um cabeçalho de e-mail ou em um log de transparência de certificados, o silêncio acaba. Nunca trate o IPv6 como um esconderijo; trate-o como um palheiro menor. Segundo, um endereço IPv4 tem um passado. Ele teve um inquilino antes de você, e se esse inquilino configurou mal um servidor de e-mail ou hospedou algo que acabou em uma lista negra, você herda a reputação até ela se dissipar. Se e-mail importa para você, verifique o endereço nas blocklists de sempre antes de construir em cima dele — é uma checagem de cinco minutos que evita duas semanas depurando entregabilidade.

Quase todo comprometimento real de um servidor pequeno começa em um de dois lugares: uma senha que podia ser adivinhada, ou um serviço que estava escutando e não deveria estar. As correções correspondentes são PasswordAuthentication no e um firewall com política padrão drop. Não são glamourosas, juntas levam quinze minutos, e valem mais do que todos os outros controles desta página somados.

O motivo é estrutural, não estatístico. As duas são fechadas por padrão — falham para o lado seguro. Um sshd somente com chaves não pode sofrer brute-force não importa quantas tentativas cheguem, porque não existe caminho no código que aceite uma senha. Um firewall com bloqueio padrão protege serviços que você ainda nem instalou, incluindo o banco de dados que você vai adicionar daqui a três meses e esquecer de vincular ao localhost. Tudo o mais em um checklist de hardening é enumeração do que pode dar errado: uma lista de coisas específicas para desligar, que só é completa até onde a lista alcança.

Então, se você só vai ler uma seção e fechar a aba, leia esta, faça os passos 2 a 5 abaixo, e considere a hora bem gasta. O resto é genuinamente útil e genuinamente secundário.

No Debian 13 e no Ubuntu 24.04, o /etc/ssh/sshd_config começa com uma linha Include /etc/ssh/sshd_config.d/*.conf, e as imagens cloud vêm com um arquivo nesse diretório — geralmente 50-cloud-init.conf — que já define PasswordAuthentication. Editar o arquivo principal e colar suas próprias diretivas no final parece natural e produz uma configuração que não faz o que diz que faz.

A regra é a única coisa sobre o sshd que surpreende quase todo mundo: para cada palavra-chave, o primeiro valor obtido vence. Isso é o oposto de quase todo outro sistema de mesclagem de configuração que você já usou. O Include fica perto do topo do arquivo principal, então um drop-in é lido antes do corpo do sshd_config — e entre os drop-ins, a ordem alfabética decide. Um arquivo chamado 10-hardening.conf vence o 50-cloud-init.conf. Um arquivo chamado 60-hardening.conf perde para ele, silenciosamente, e você não vai descobrir isso por um restart que reporta sucesso.

É por isso que você nunca deve confiar no arquivo que acabou de escrever. Pergunte ao daemon o que ele realmente resolveu:

sshd -t                 # syntax check — silence means valid
sshd -T | grep -Ei '^(permitrootlogin|passwordauthentication|pubkeyauthentication|kbdinteractive|allowusers|port) '

O sshd -T imprime a configuração efetiva depois que todo include, override e valor padrão já foi resolvido. Se essa saída disser passwordauthentication yes, a autenticação por senha está ligada, não importa o que qualquer arquivo no disco afirme. Nada além disso conta como verificação.

A segunda armadilha é da mesma família. O Ubuntu 24.04 inicia o sshd por ativação de socket: o ssh.socket é dono da porta de escuta, e o Port em sshd_config é completamente ignorado. Verifique com systemctl is-enabled ssh.socket; se estiver habilitado e você quiser uma porta diferente, mude-a com systemctl edit ssh.socket e um override ListenStream= — não no sshd_config, onde a configuração vai parecer certa e não vai fazer nada.

Vamos ser honestos quanto a isso, porque a internet não é. Mudar o sshd para a porta 2222 ou 47000 não impede nenhum atacante competente. Uma varredura TCP completa em um único host leva segundos, o serviço se anuncia no banner, e quem quer que tenha decidido atacar você especificamente vai encontrar antes de terminar o café.

O que essa mudança realmente faz é cortar o seu log de autenticação em algo como noventa e cinco por cento, e isso tem valor real: é a diferença entre logs que você só passa o olho e logs que você de fato lê. Sinal que você consegue ver vence sinal que está enterrado. Se você monitora qualquer coisa, um auth.log silencioso é a forma mais barata de tornar uma anomalia visível.

Os custos são pequenos, mas são reais, e são o motivo de chamarmos isso de opcional em vez de recomendado. Você vai esquecer a porta quando voltar daqui a oito meses. Uma porta não padrão acima de 1024 pode, em princípio, ser tomada por um processo sem privilégios se o sshd algum dia parar de escutar. Firewalls de saída restritivos em redes de clientes bloqueiam portas incomuns, então ocasionalmente você não vai conseguir alcançar seu próprio servidor a partir de um escritório ou de um hotel. E em um sistema ativado por socket você precisa mudar a porta no lugar certo, conforme a seção anterior. Faça isso se logs mais silenciosos importam para você. Não faça isso e depois se sinta seguro, e nunca faça isso no lugar de usar somente chaves.

Um firewall que lista o que bloquear é um sistema de arquivamento. Um firewall que lista o que permitir é um controle de segurança. A distinção é o jogo inteiro, porque só o segundo cobre o serviço que você vai instalar mês que vem, a porta de debug que você abriu numa sexta-feira, e o contêiner que resolveu se expor.

Na nossa plataforma você tem duas camadas, e elas são independentes. O filtro de borda é opcional, configurado por servidor no painel e aplicado no hypervisor, então o tráfego bloqueado nunca chega sequer ao seu guest — útil para regras de camada 4 que você quer aplicadas antes que o seu kernel gaste um ciclo com elas, e para manter um guest comprometido inalcançável enquanto você trabalha nele. O firewall do guest é inteiramente seu: nftables, iptables, pf, o que a sua imagem trouxer. Nós nunca tocamos nele. Use os dois se a máquina importa; use pelo menos o segundo sempre.

Duas coisas no ruleset do passo 5 merecem explicação, porque a maioria dos rulesets copiados e colados erra nelas. Não descarte todo o ICMP. Parece uma boa faxina, mas quebra o path-MTU discovery, o que produz a pior classe de bug que existe: requisições pequenas funcionam, respostas grandes travam, e nada nos seus logs menciona o firewall. Aceite no mínimo destination-unreachable, time-exceeded e parameter-problem. Não filtre o ICMPv6 por tipo a menos que você conheça a lista. O IPv6 depende do ICMPv6 para neighbour discovery e router advertisement; bloqueie-o de forma ampla e sua conectividade IPv6 morre de um jeito que parece problema de roteamento. Aceitar todo o ICMPv6 em um único host é uma troca razoável, e o ruleset abaixo faz exatamente isso.

Um aviso antes de você rodar flush ruleset: se o Docker estiver instalado, essa linha remove as regras de NAT e de filtro que o Docker escreveu, e a rede dos contêineres para de funcionar até que systemctl restart docker as recoloque. Carregue seu ruleset primeiro, reinicie o Docker depois, e leia a próxima seção antes de publicar uma única porta de contêiner.

Pergunte à máquina no que ela está escutando. Não no que você acha que instalou — no que está vinculado agora mesmo:

ss -tulpn | grep -vE '127\.0\.0\.1|\[::1\]'

Tudo que sobrevive a esse filtro é alcançável a partir de algum lugar que não a própria máquina. Em uma imagem padrão, os achados de sempre são rpcbind na 111 (nada que você rode precisa dele), um listener exim4 deixado pela instalação base, e um stub do systemd-resolved que é inofensivo em loopback e um resolver aberto se não estiver. Os perigosos aparecem depois, com software que você instalou de propósito: PostgreSQL em 0.0.0.0:5432 porque um tutorial mandou editar listen_addresses, Redis sem senha porque o Redis não tinha senha por padrão durante a maior parte da sua história, um node Elasticsearch, um exporter do Prometheus, um notebook Jupyter. Cada um desses já foi o primeiro passo de uma invasão real inúmeras vezes.

Agora a pegadinha que pega até quem toma cuidado. O Docker não pede permissão ao seu firewall. Quando você escreve -p 5432:5432, o Docker insere regras de DNAT na chain PREROUTING da tabela nat, que o kernel avalia antes de sua chain input sequer ver o pacote; o tráfego é então encaminhado para o contêiner. Sua política de bloqueio padrão na input não é consultada, o ufw status mostra a porta fechada, e o banco de dados está na internet pública. Esse é um comportamento documentado do Docker, é assim há uma década, e já expôs um número enorme de bancos de dados.

A correção é uma única string, e é o hábito que vale a pena criar:

# wrong — reachable from the entire internet, whatever your firewall says
docker run -p 5432:5432 postgres

# right — bound to loopback, reachable only through an SSH tunnel or a proxy
docker run -p 127.0.0.1:5432:5432 postgres

Por fim, busque uma opinião de fora. Um port scan feito a partir do próprio servidor te diz o que o kernel pensa; uma varredura feita de outro lugar te diz o que o mundo vê, que é o único número que importa. Rode nmap -Pn -p- <your-ip> a partir do seu laptop, não da máquina, e compare o resultado com a lista que você esperava.

A janela que compromete servidores pequenos não é o zero-day. São as quatro semanas entre um CVE se tornar público com uma prova de conceito funcional e a próxima vez que você por acaso vai logar. As ferramentas de ataque absorvem uma falha remota nova em questão de dias; uma máquina que você corrige “quando sobrar tempo” fica exposta durante todo esse intervalo, e todo operador honesto sabe quão longo esse intervalo realmente é.

A objeção às atualizações automáticas é o medo de quebrar algo, e vale a pena levar a sério — e depois restringir. Limite a automação ao pocket de segurança da sua distribuição, onde os mantenedores fazem backport das correções para a versão empacotada em vez de lançar novas versões upstream. Uma atualização de segurança do Debian para o openssl é um build corrigido da mesma versão que você já roda; o risco de isso mudar o comportamento é bem menor do que o risco de deixar um buraco remoto aberto por um mês. Upgrades de funcionalidade continuam manuais, onde devem ficar.

A parte que as pessoas pulam é o reboot. Um libssl corrigido no disco não faz nada pelo processo que mapeou o antigo na inicialização, e uma atualização de kernel não faz absolutamente nada até você dar boot nela. Ou você aceita um reboot sem intervenção em uma janela que você escolhe, ou instala o needrestart e deixa ele te dizer quais serviços estão rodando contra bibliotecas apagadas — mas faça um dos dois. “As atualizações automáticas estão ativadas” enquanto o uptime mostra 340 dias é uma ilusão confortável, e é a mais comum que vemos.

O fail2ban lê seus logs, percebe falhas repetidas vindas de um endereço e o bane por um tempo. O CrowdSec faz o mesmo e compartilha os veredictos por uma rede de participantes, então você consegue bloquear um endereço que já se comportou mal em outro lugar antes que ele chegue até você. Os dois são softwares bons. Nenhum dos dois faz o que a maioria das pessoas pensa que faz em um servidor SSH somente com chaves.

Uma vez que PasswordAuthentication é no, um brute-force de SSH não pode ter sucesso. Não é “dificilmente teria sucesso” — não existe caminho de código para isso. Banir um endereço depois de cinco falhas, portanto, não previne nada; reduz o volume de log e uma quantidade trivial de CPU. Isso é um benefício real, só não é um benefício de segurança, e a troca não é gratuita: uma jail mal escrita que observa o log errado já trancou mais administradores para fora dos próprios servidores do que atacantes.

Onde essas ferramentas realmente merecem seu lugar é uma camada acima, nos serviços que você de fato expõe: um formulário de login, um admin do WordPress, uma API com rate limit, um servidor de e-mail com SMTP AUTH. Esses sim aceitam senha, são vulneráveis a brute-force, e uma lista de banimento é exatamente o controle certo. Então nosso veredito é estreito e específico. Pule a jail no SSH. Coloque o CrowdSec ou o fail2ban na frente do que tiver um campo de senha. E qualquer um que você escolher, coloque seu próprio endereço de gerenciamento na whitelist primeiro — o ignoreip existe para a noite que você vai lembrar pelos motivos errados.

Prevenção é o que você consegue fazer em uma hora. Detecção é o que te avisa que a hora não foi suficiente. Não precisa ser elaborada, e em um único servidor três coisas baratas cobrem a maior parte do terreno.

Preserve os logs. Em muitas imagens o journal vive em /run e evapora no reboot, o que significa que o registro de um incidente desaparece no reboot que vem logo depois dele. Criar /var/log/journal é uma correção de uma linha só e a coisa de maior valor nesta seção.

Seja avisado sobre logins. Uma linha em /etc/ssh/sshrc que dispara o logger a cada início de sessão não custa nada e te dá um registro limpo e fácil de buscar com grep, separado da conversa própria do sshd. Um detalhe que pega as pessoas: o sshd roda ~/.ssh/rc em vez de /etc/ssh/sshrc quando o usuário tem um, então o arquivo do sistema é pulado exatamente para a conta com mais chance de ter um dotfile personalizado. Se você precisa de um hook que não possa ser sombreado, use pam_exec em vez disso.

Saiba como o sistema de arquivos estava no primeiro dia. O AIDE registra hashes dos seus binários, bibliotecas e unit files e reporta o que mudou desde então. A pegadinha é fundamental e geralmente ignorada: um banco de dados guardado na mesma máquina que ele monitora pode ser regenerado por quem quer que a tenha comprometido, e então a checagem reporta “nenhuma mudança” para sempre. Copie o banco de dados para fora da máquina, ou pelo menos registre o hash dele em outro lugar, e a ferramenta passa a valer os vinte minutos que custa. Deixado no lugar, é só uma falsa sensação de segurança.

O princípio geral vale a pena declarar sozinho: o log em que você não pode confiar é o que está na máquina comprometida. Qualquer coisa em que você realmente pretenda confiar — um journal, um banco de dados de integridade, um backup — deveria ter uma cópia em algum lugar que o mesmo atacante não controle. Um segundo servidor pequeno em outra jurisdição é uma resposta legítima para isso, e um de cinco dólares já basta.

Tudo o que vimos acima é trabalho de perímetro, e vale a pena ser preciso sobre esse limite para você não confundir uma porta da frente trancada com um cofre.

Não protege dados em uma máquina em execução. Um kernel enrijecido e um firewall fechado são irrelevantes para quem tem acesso ao hypervisor, e para o conteúdo da RAM enquanto a máquina está ligada. Se a sua preocupação é o disco quando o servidor está desligado, apreendido ou desativado, isso é criptografia de disco, e é um procedimento diferente com um modo de falha diferente — veja criptografar um disco de VPS com LUKS.

Não te torna anônimo. Um servidor pode estar perfeitamente protegido e ainda assim anunciar quem é o dono, por meio de um registro WHOIS, uma chave SSH reutilizada, uma tag de analytics, um cliente SSH que conecta de casa sem um salto intermediário, ou um certificado que amarra duas identidades. Pagar em Monero e depois logar a partir do seu próprio endereço desfaz o pagamento. Esse modo de falha tem sua própria página: os erros que te desanonimizam.

Não conserta a sua aplicação. Uma SQL injection, um endpoint de admin sem autenticação ou uma dependência com backdoor não se importam com as suas configurações de sshd. A maioria dos comprometimentos de servidores bem administrados chega pela porta que você abriu deliberadamente, de propósito, para um serviço que você escreveu ou instalou.

Não é um backup. Ransomware, um rm -rf com uma variável que estava vazia, e um upgrade que deu errado terminam todos do mesmo jeito. Tire uma cópia, coloque em outro lugar, e restaure a partir dela uma vez antes de precisar de verdade — a mesma disciplina que faz uma migração para outro host sobrevivível é a que faz uma terça-feira ruim sobrevivível.

Nada disso é um argumento contra a hora. É um argumento para saber exatamente o que essa hora comprou.