configurar novo vps com segurança

Os primeiros 10 minutos decidem o quão seguro seu servidor está

Um VPS recém-criado não é seguro. Assim que ele recebe um IP público, scanners tentam fazer login. A imagem padrão oferece um alvo fácil: root frequentemente acessível, senhas geralmente permitidas, sem firewall e sem atualizações agendadas. A boa notícia é que fechar todas essas brechas leva cerca de dez minutos e alguns comandos. Este é o runbook que eu executo em cada novo servidor antes de instalar qualquer coisa.

Siga a ordem, pois os passos são cumulativos. Cada um possui seu próprio guia, linkado durante o processo; esta página é o caminho rápido que os conecta.

Minuto 1: Atualize tudo

Faça login como root com as credenciais fornecidas pelo seu provedor e atualize o sistema completamente antes de qualquer outra coisa:

apt update && apt upgrade -y

Um servidor sem patches é o alvo mais fácil que existe, por isso este passo vem primeiro. Assim que terminar, configure atualizações automáticas de segurança para que o sistema permaneça atualizado sem que você precise lembrar.

Minuto 2: Crie um usuário comum com sudo

Não continue trabalhando como root. Crie um usuário para você e dê permissões de sudo:

adduser matt
usermod -aG sudo matt

A partir daqui, faça login com este usuário e use sudo para tarefas administrativas. Trabalhar sempre como root significa que qualquer erro ou comprometimento ocorrerá com poder ilimitado, que é exatamente o que rodar como um usuário sem privilégios visa prevenir.

Minuto 4: Configure chaves SSH

Senhas podem ser adivinhadas; chaves não. No seu próprio laptop, se ainda não tiver uma chave, crie uma:

ssh-keygen -t ed25519

Depois, copie a metade pública para o servidor:

ssh-copy-id matt@YOUR_SERVER

ssh-copy-id precisa estar com o login por senha ativado para o novo usuário; se já estiver desativado, copie o ~/.ssh/authorized_keys do root para o /home/matt/.ssh/authorized_keys (propriedade de matt), ou cole sua chave pública manualmente nesse arquivo.

O modelo por trás deste passo — uma chave por dispositivo, as permissões que impedem o login por chave e a revogação de uma chave perdida — é abordado em básicos de gerenciamento de chaves SSH.

Faça logout e login novamente como matt usando a chave, e confirme se funciona antes de ir para o próximo passo. Bloquear o SSH antes de conseguir entrar com uma chave é como as pessoas perdem o acesso ao servidor.

Minuto 6: Desative o login do root e senhas

Agora que sua chave funciona, feche as duas portas que os scanners utilizam. Use um arquivo de configuração adicional para que atualizações de pacotes não o sobrescrevam. Nomeie-o como 00- para que ele seja processado antes de 50-cloud-init.conf, que vem com as imagens cloud do Ubuntu com PasswordAuthentication yes; o sshd mantém o primeiro valor que lê, então um arquivo com ordenação posterior perderia a configuração silenciosamente:

sudo nano /etc/ssh/sshd_config.d/00-hardening.conf

PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no

Depois, recarregue o SSH:

sudo systemctl restart ssh

Em seguida, verifique as configurações que o sshd realmente está usando, para que um arquivo de configuração incorreto não te engane:

sudo sshd -T | grep -Ei 'passwordauthentication|permitrootlogin'

Com senhas desativadas e o login do root removido, o tráfego constante de brute-force contra seu servidor simplesmente não terá sucesso. O tratamento completo, incluindo a mudança opcional de porta, está em SSH hardening on a VPS.

Minuto 8: Ative o firewall

Bloqueie tudo o que entra por padrão e permita apenas o necessário. Permita o SSH antes de ativar o firewall, ou você cortará sua própria conexão:

sudo ufw default deny incoming
sudo ufw allow 22/tcp
sudo ufw enable

Adicione regras de allow para qualquer serviço que você realmente execute, como 80/tcp e 443/tcp para um site. Verifique se tanto IPv4 quanto IPv6 estão cobertos, pois um firewall que filtra apenas IPv4 deixa o lado IPv6 totalmente aberto. O guia completo está em Firewalls 101 on a VPS.

Minuto 10: Diminua os scanners com Fail2ban

Finalmente, adicione o Fail2ban para banir os endereços que atacam seus ports:

sudo apt install -y fail2ban

No Ubuntu 24.04, a instalação padrão protege o SSH desde o primeiro boot. Com o uso de chaves já exigido, este é um reforço que reduz o ruído nos logs e bloqueia infratores recorrentes, em vez de ser sua defesa principal.

Seu checklist

Este é o runbook. Use o gerador abaixo para marcar cada controle e gerar um checklist personalizado que você pode manter com o servidor, incluindo o comando exato para cada passo:

Execute isso uma vez por servidor novo e o processo se tornará automático. Dez minutos agora economizam uma tarde muito ruim após um servidor ser invadido.

Assim que o essencial estiver configurado, as atualizações automáticas de segurança no Ubuntu manterão o servidor atualizado sem que você precise logar novamente.

FAQ

O que devo fazer primeiro em um novo VPS?

Atualize o sistema com apt update && apt upgrade -y, depois crie um usuário comum com sudo e pare de trabalhar como root. A partir daí, configure chaves SSH, desative o login do root e a autenticação por senha, ative um firewall de bloqueio padrão e instale o Fail2ban. Fazê-los nessa ordem garante que cada passo seja seguro para evitar o bloqueio do seu próprio acesso.

Como evito perder o acesso enquanto reforço o SSH?

Configure e teste o login por chave SSH antes de desativar senhas ou o root. Faça logout e login com a chave para confirmar que funciona e só então desative PasswordAuthentication e PermitRootLogin. Ao ativar o firewall, permita a porta 22 antes de rodar ufw enable. Se você perder o acesso, o console web do seu provedor permite o retorno sem SSH.

Eu realmente preciso de tudo isso em um servidor pequeno?

Sim, porque os scanners não se importam com o tamanho do seu servidor. Eles tentam todos os IPs públicos da mesma forma. O runbook completo leva cerca de dez minutos e remove os caminhos fáceis: sem login de root, sem adivinhação de senhas, nada exposto que você não tenha escolhido e bugs conhecidos corrigidos automaticamente.

Qual é o passo mais importante?

SSH apenas por chave com o login do root desativado. A maioria dos ataques em um VPS novo são tentativas automatizadas de adivinhação de senha contra o root; desativar ambos torna essa categoria inteira de ataque impossível. O firewall e o Fail2ban então limitam o que está exposto e retardam qualquer outra tentativa.

Como confirmo que o servidor está realmente protegido?

Verifique três coisas manualmente antes de confiar no servidor. Rode sudo ss -tlnp e confirme que apenas as portas que você pretendia abrir estão ouvindo em um endereço público, sem nenhum serviço 0.0.0.0 ou [::] que você tenha esquecido. Rode sudo ufw status verbose e confirme que a política padrão de entrada é deny e que tanto as regras comuns quanto as de (v6) estão presentes. E sempre abra uma segunda sessão SSH antes de fechar a primeira, para que um erro na configuração do SSH não te bloqueie do servidor. Se as três estiverem corretas, o básico está pronto.