Como blindar uma nova VPS: os primeiros dez minutos

Um servidor novo está mais exposto no exato momento em que recebe um endereço IP. Scanners automatizados varrem o espaço IPv4 inteiro continuamente, então as primeiras tentativas de login contra uma máquina implantada há um minuto costumam chegar antes de você terminar de ler a mensagem de boas-vindas. Nada disso é direcionado a você — é ruído de fundo da internet, e é por isso que um servidor sem blindagem, com senha no root, é comprometido em questão de horas, não de meses. A boa notícia é que fechar essa porta é trabalho rápido: dez minutos de passos em ordem eliminam praticamente todo o risco oportunista. Este guia cobre esse checklist, a ordem que evita que você fique trancado para fora da própria máquina, e uma coisa que a maioria dos tutoriais de blindagem nunca menciona — os detalhes pessoais que uma configuração padrão silenciosamente grava em uma máquina que você alugou justamente para que ela não ficasse vinculada a você.

Contra o que a blindagem realmente protege

A blindagem vale a pena precisamente porque seus benefícios são estreitos e reais. Ter clareza sobre esse limite evita uma falsa sensação de segurança nas áreas que ela não alcança.

• Ela elimina completamente o atacante oportunista. Bots de credential stuffing, força bruta contra o SSH e varreduras em busca de painéis de administração expostos falham diante de uma autenticação só por chave e de um firewall que nega tudo por padrão.
• Ela limita o estrago quando algo que você roda tem uma falha. Um serviço vinculado ao localhost atrás de uma porta fechada não pode ser alcançado por um estranho nem mesmo no dia em que o CVE dele é publicado.
• Ela reduz o custo de um erro. Usuários sem privilégios, chaves separadas e patches automáticos fazem com que uma única decisão ruim não entregue a máquina inteira.
• Ela não esconde o servidor da sua hospedagem. Qualquer pessoa com acesso ao hypervisor pode, em princípio, ler a memória de uma máquina em funcionamento — uma questão sobre de quem você aluga, não sobre as regras do seu firewall.
• Ela não torna você anônimo. A blindagem protege a máquina; se ela fica vinculada ao seu nome é algo decidido no cadastro e no pagamento, bem antes do seu primeiro login.

Essa última distinção é a que as pessoas costumam inverter. Um servidor perfeitamente blindado, comprado com cartão de crédito no seu nome legal, continua sendo um servidor no seu nome legal. As duas camadas se complementam: a hospedagem sem KYC e um saldo financiado em cripto decidem a quem a máquina pertence no papel, e os dez minutos a seguir decidem quem consegue entrar nela.

A ordem que evita que você fique trancado para fora

Quase toda história de terror sobre blindagem é a mesma história: alguém desativou a autenticação por senha antes de confirmar que a chave funcionava, ou ativou um firewall cujas regras não incluíam o SSH, e ficou trancado para fora de uma máquina que não conseguia mais alcançar. A ordem existe justamente para tornar isso impossível. Instale a chave primeiro e comprove que ela funciona em uma segunda janela. Só depois desative as senhas. Adicione a regra do firewall para o SSH antes de ativar o firewall, nunca depois.

Também vale a pena saber qual é o seu caminho de recuperação antes de precisar dele. Uma VPS que só pode ser alcançada por SSH tem exatamente uma porta de entrada, então o console no painel do seu provedor é o plano B que transforma ficar trancado para fora em um contratempo, e não em uma reinstalação do zero. Confira se consegue abri-lo enquanto tudo ainda está funcionando.

Passo a passo: os primeiros dez minutos em uma máquina nova

1. 01Atualize o índice de pacotes e os pacotes instaladosUma imagem recém-criada é uma fotografia do momento em que foi montada. Deixá-la em dia é a ação de maior valor de toda a lista, e leva menos de um minuto.
2. 02Crie um usuário sem privilégios com sudoTrabalhar como root o tempo todo significa que cada erro de digitação e cada processo roda com autoridade total. Crie um usuário comum, adicione-o ao grupo sudo ou wheel, e use esse usuário no dia a dia.
3. 03Copie sua chave pública para esse usuárioGere uma chave ed25519 na sua própria máquina se ainda não tiver uma, depois envie a metade pública com ssh-copy-id. A chave privada nunca sai do seu notebook.
4. 04Abra um segundo terminal e confirme que o login por chave funcionaNão pule esta etapa. Faça login como o novo usuário usando a chave, em uma janela nova, antes de mudar qualquer coisa na autenticação.
5. 05Desative a autenticação por senha e o login de rootDefina PasswordAuthentication no e PermitRootLogin prohibit-password, depois recarregue o sshd. A força bruta contra a máquina agora não tem mais nada para adivinhar.
6. 06Ative um firewall que nega tudo por padrão, com o SSH liberadoNegue toda a entrada, libere sua porta SSH, e só então ative o firewall. Adicione depois, uma de cada vez, as portas que seus próprios serviços precisarem.
7. 07Ative as atualizações automáticas de segurançaunattended-upgrades no Debian e no Ubuntu, dnf-automatic na família RHEL. É isso que mantém a máquina segura no sexto mês, quando você já parou de prestar atenção nela.
8. 08Liste o que está escutando e feche o que não deveria estarUm único ss -tulpn mostra todo socket aberto. Qualquer coisa que você não colocou ali de propósito deve ser removida ou vinculada ao localhost.

SSH: só chave, e as configurações que realmente importam

A autenticação por chave pública é praticamente toda a blindagem do SSH. Com as senhas desativadas, um atacante precisa de uma chave privada que não tem, e nenhuma quantidade de tentativas produz uma. Gere chaves ed25519 — elas são curtas, rápidas e o padrão moderno — e proteja a chave com uma passphrase, para que um notebook roubado não vire um servidor roubado. Todo o resto no sshd_config é refinamento em cima dessa única decisão.

• PasswordAuthentication no — a configuração que acaba com a força bruta. Verifique antes que sua chave funciona, em uma segunda sessão.
• PermitRootLogin prohibit-password — o root ainda pode ser alcançado por chave para recuperação, mas nunca por senha. Depois de comprovar que seu usuário sudo funciona, defina como no.
• AllowUsers ou AllowGroups — uma lista explícita de quem pode fazer login, para que uma conta de serviço criada por algum pacote nunca vire uma porta de entrada via SSH.
• KbdInteractiveAuthentication no — fecha o outro caminho interativo que pode reativar silenciosamente os prompts de senha em algumas distribuições.
• Uma segunda chave para um segundo dispositivo, em vez de copiar a mesma chave privada de um lado para outro. Perder um celular deve significar remover uma linha do authorized_keys, não trocar tudo.
• Mudar o SSH para fora da porta 22 corta drasticamente o volume dos seus logs, mas trate isso como redução de ruído, não como segurança de verdade — não muda nada para quem está realmente de olho no seu IP.

Se quiser ir além das chaves, o arranjo mais forte é não expor o SSH publicamente de jeito nenhum: coloque a máquina atrás de um túnel WireGuard e bloqueie a porta 22 no firewall para que ela só aceite conexões vindas do endereço do túnel. Isso transforma seu daemon SSH em algo que a internet não consegue enxergar, o que é um resultado melhor do que qualquer quantidade de blindagem de configuração em um SSH exposto.

O firewall: negar tudo por padrão, depois abrir exatamente o que você usa

Um firewall só faz sentido se o padrão dele for recusar. Permitir tudo e depois bloquear as portas conhecidas como ruins é fazer ao contrário: você acaba protegendo os serviços de que se lembrou e expondo os que esqueceu. Negue todo o tráfego de entrada, permita o de saída, e depois abra portas individuais conforme for implantando as coisas que precisam delas. O Linux moderno usa nftables por baixo dos panos, e o ufw ou o firewalld são interfaces perfeitamente boas para isso — a ferramenta importa muito menos do que o padrão escolhido.

• Libere o SSH antes de ativar o firewall, nunca depois. Essa é a segunda forma mais comum de ficar trancado para fora da própria máquina.
• Abra só as portas que um serviço realmente precisa receber de fora. Um servidor web quer as portas 80 e 443; um banco de dados quase nunca quer nenhuma.
• Vincule serviços de uso só local ao 127.0.0.1, em vez de 0.0.0.0. Uma porta fechada e um serviço que nunca escuta publicamente são duas proteções independentes, e você quer as duas.
• Escreva regras para IPv6 além de IPv4. Um conjunto de regras que cobre só v4 em uma máquina dual-stack deixa o mesmo serviço totalmente aberto no endereço v6.
• Restrinja as portas de administração por endereço de origem sempre que puder. Se a administração sempre vem de um único endpoint de VPN, diga isso explicitamente na regra.
• Releia as regras depois de adicionar um serviço novo. Portas abertas para algo que você já removeu são o acúmulo silencioso que desfaz um começo limpo.

Algumas cargas de trabalho invertem essa lógica e precisam de uma porta escancarada de propósito — um relay Tor precisa aceitar conexões vindas de qualquer lugar, e um nó completo de Bitcoin só atende peers se a porta 8333 estiver alcançável. Tudo bem. A regra não é "não abrir nada", é "abrir de propósito", e um serviço feito para ser público é uma escolha deliberada.

fail2ban, e por que ele importa menos do que você imagina

O fail2ban observa seus logs e bane endereços que falham repetidamente na autenticação. Ele é genuinamente útil, mas vale a pena ser honesto sobre o que ele faz depois que você já desativou a autenticação por senha: nesse ponto, ninguém consegue ter sucesso adivinhando, então o fail2ban deixou de evitar uma invasão. O que ele evita são milhares de linhas de log inúteis por dia, o CPU que essas tentativas de conexão consomem, e o risco de um evento real ficar enterrado em um ruído que você parou de ler há meses.

Mesmo assim, vale os dez segundos de configuração, e ele se torna genuinamente protetor no momento em que você roda algo que aceita senha — o login de uma aplicação web, um servidor de e-mail, um painel de controle. Aponte-o para esses logs, não só para o sshd. Configure a janela de banimento em horas, não em minutos, e adicione seu próprio endereço à lista de exceções para que uma senha digitada errado não te deixe trancado para fora da sua própria máquina.

Atualizações que você não precisa lembrar de fazer

A ameaça realista para um servidor bem configurado não é alguém derrotando suas chaves SSH. É uma vulnerabilidade publicada para algo que você instalou e esqueceu, explorada por um scanner três dias depois, enquanto você estava ocupado com outras coisas. As atualizações automáticas de segurança são a resposta, e no Debian ou Ubuntu isso é o unattended-upgrades configurado para instalar o repositório de segurança; no Fedora, Rocky ou Alma é o dnf-automatic. Ative isso nos primeiros dez minutos e a máquina continua se corrigindo sozinha muito depois de sua atenção ter migrado para outra coisa.

As atualizações de kernel e da libc são a exceção que ainda depende de você: elas só fazem efeito depois de um reinício, então um servidor que está no ar há quatrocentos dias quase certamente está rodando código que foi corrigido no disco há um ano. O needrestart do Debian mostra quais serviços estão rodando contra bibliotecas já apagadas, e uma janela de reinicialização programada — mesmo que mensal — é a diferença entre patches instalados e patches realmente aplicados. De qualquer forma, tudo que você roda deveria sobreviver a um reinício inesperado; se não sobrevive, isso é um problema à parte que vale a pena corrigir.

Os vazamentos de identidade que um checklist de blindagem ignora

Esta é a seção que importa se você escolheu de propósito uma hospedagem offshore e sem KYC. Um guia de blindagem padrão é escrito pensando no servidor de uma empresa cujo dono é de conhecimento público, então ele nunca pergunta o que a configuração padrão anda registrando sobre você. Em uma máquina que você alugou anonimamente, vários desses padrões voltam a vincular seu nome a ela, silenciosamente.

• Sua chave pública SSH carrega um comentário — por padrão, o seu nome de usuário local e o hostname do seu notebook, algo como alex@alex-macbook — e esse comentário fica gravado ao pé da letra no authorized_keys do servidor. Defina-o com a flag -C ao gerar a chave, ou edite a linha depois de copiá-la.
• O hostname que você escolhe para o servidor acaba aparecendo em logs, em cabeçalhos de e-mail, em saídas de monitoramento e às vezes em banners de serviço. Um hostname genérico não revela nada; o seu nome ou o da sua empresa, sim.
• O fuso horário do sistema. As imagens de nuvem vêm por padrão em UTC, o que não conta nada a ninguém. Configurá-lo para o seu fuso local ajuda a estreitar onde você está, e os timestamps de cada log passam a confirmar seu horário de trabalho.
• A configuração do Git copiada para a máquina, que carrega o nome e o e-mail com que você assina seus commits. O mesmo vale para arquivos de histórico do shell, dotfiles sincronizados da sua estação de trabalho, e qualquer credencial guardada em cache durante um teste apressado.
• O e-mail que você entrega ao Let's Encrypt na emissão do certificado, que passa a fazer parte de um registro público desse certificado. Use um endereço que não esteja ligado à sua identidade.
• Banners de versão do servidor web e cabeçalhos X-Powered-By, além de qualquer ferramenta de análise, relatório de falhas ou agente de monitoramento de fornecedor que "liga para casa" a partir da máquina com um identificador de conta anexado.

Vale a pena manter essas camadas bem separadas na cabeça. A blindagem mantém estranhos fora da máquina. Esses detalhes evitam que a máquina descreva você para quem já está de olho nela. E a camada de pagamento decide se algum dia existiu um nome para ser encontrado — um assunto tratado com honestidade em o Bitcoin é pseudônimo, não anônimo, e levado adiante em recarregar em Monero. Cada camada falha sozinha; juntas, elas seguram.

Backups: a parte que a blindagem não faz por você

Nenhuma regra de firewall protege contra um banco de dados apagado, um disco que falhou ou uma mudança de configuração que parecia razoável na hora. Backups são o único controle que te recupera dos próprios erros que você comete, que é estatisticamente a forma mais provável de você perder dados em uma máquina bem protegida. Criptografe-os antes que saiam do servidor, mantenha pelo menos uma cópia em algum lugar que o próprio servidor não consiga alcançar, e configure-os para rodar em uma agenda fixa, em vez de quando você se lembrar.

Esse último ponto importa mais do que parece: um processo de backup que o próprio servidor pode sobrescrever é um backup que qualquer coisa com root no servidor pode destruir. Enviar arquivos criptografados para um servidor de armazenamento separado — ou puxá-los de lá, para que as credenciais fiquem fora da máquina que está sendo salva — te dá uma cópia que sobrevive à máquina. E faça a restauração uma vez, de propósito, enquanto nada está quebrado. Um backup nunca testado é uma hipótese, não uma rede de segurança.

Erros que desfazem o trabalho silenciosamente

• Desativar a autenticação por senha antes de testar a chave, e só descobrir o erro em um notebook que não consegue mais fazer login.
• Ativar o firewall antes de liberar o SSH — o mesmo tranco para fora, só que chegando pelo caminho contrário.
• Escrever regras só para IPv4, deixando todo serviço alcançável pelo endereço IPv6 da máquina.
• Blindar tudo com cuidado no primeiro dia e depois instalar um painel de controle, um banco de dados e uma stack de monitoramento que abrem suas próprias portas sem serem consultados.
• Rodar tudo como root para economizar um "sudo", de modo que a primeira falha em qualquer coisa vire um comprometimento total.
• Tratar o fail2ban como substituto das chaves, o que deixa um jogo de adivinhação de senha rodando só um pouco mais devagar.
• Supor que dá para esconder um servidor alugado da própria hospedagem criptografando o disco — a criptografia completa de disco protege um disco roubado, não uma máquina em funcionamento.
• Nunca reiniciar, deixando meses de patches de kernel instalados parados no disco enquanto o kernel antigo continua rodando.

Nada disso é difícil, e nada disso demora. Faça na ordem certa, comprove cada passo a partir de um segundo terminal antes de seguir para o próximo, e a máquina que você implantou há poucos minutos deixa de ser uma oportunidade para quem estiver varrendo o espaço de endereços. Depois, implante o que você realmente veio fazer aqui — um site, um nó, um túnel, um endpoint de modelo privado — sobre uma base que você consegue entender de ponta a ponta.