O que fazer nos primeiros 10 minutos de um VPS

Os primeiros 10 minutos determinam a segurança do seu servidor

Um VPS novo não é seguro. A partir do momento em que tem um IP público, scanners tentam iniciar sessão, e a imagem predefinida oferece um alvo amplo: o root está frequentemente acessível, as palavras-passe são frequentemente permitidas, não existe firewall e nada é atualizado segundo um agendamento. A boa notícia é que corrigir tudo isso demora cerca de dez minutos e requer apenas alguns comandos. Este é o procedimento que executo em todos os servidores novos antes de instalar qualquer aplicação.

Siga os passos pela ordem indicada, porque cada um depende dos anteriores. Cada passo tem o seu próprio guia, ligado no ponto correspondente; esta página é o caminho rápido que os reúne.

Minuto 1: Atualize tudo

Inicie sessão como root com as credenciais fornecidas pelo seu provedor e atualize completamente o sistema antes de fazer qualquer outra coisa:

apt update && apt upgrade -y

Um sistema sem patches é o alvo mais fácil, por isso esta etapa vem primeiro. Quando terminar, configure atualizações de segurança automáticas para manter o sistema atualizado sem depender de atualizações manuais.

Minuto 2: Crie um utilizador normal com sudo

Não continue a trabalhar como root. Crie um utilizador para si e atribua-lhe sudo:

adduser matt
usermod -aG sudo matt

A partir daqui, inicie sessão como este utilizador e use sudo para tarefas administrativas. Trabalhar sempre como root significa que cada erro e cada comprometimento ocorre com privilégios ilimitados. É precisamente isso que trabalhar como um utilizador sem privilégios deve impedir.

Minuto 4: Configure chaves SSH

As palavras-passe podem ser adivinhadas; as chaves, não. No seu portátil, se ainda não tiver uma chave, crie uma:

ssh-keygen -t ed25519

Depois copie a parte pública para o servidor:

ssh-copy-id matt@YOUR_SERVER

ssh-copy-id precisa que o início de sessão com palavra-passe esteja ativado para o novo utilizador; se já estiver desativado, copie o ~/.ssh/authorized_keys de root para /home/matt/.ssh/authorized_keys, com propriedade de matt, ou cole manualmente a sua chave pública nesse ficheiro.

O modelo subjacente a este passo, uma chave por dispositivo, as permissões que impedem o início de sessão com chave e a revogação de uma chave perdida são abordados em Noções básicas de gestão de chaves SSH.

Termine a sessão e volte a iniciar sessão como matt usando a chave. Confirme que funciona antes de avançar. Restringir o SSH antes de conseguir entrar com uma chave é uma forma comum de ficar sem acesso ao servidor. Se esse início de sessão devolver Permission denied (publickey), resolva o problema agora em vez de voltar à palavra-passe, porque essa mensagem pode indicar cinco falhas diferentes e o resultado de ssh -v indica qual delas está efetivamente a ocorrer.

Minuto 6: Desative o login de root e as palavras-passe

Agora que a sua chave funciona, feche as duas portas utilizadas pelos scanners. Use um ficheiro drop-in para que as atualizações dos pacotes não o substituam. Dê-lhe o nome 00- para que seja ordenado antes de 50-cloud-init.conf, que as imagens cloud do Ubuntu fornecem com PasswordAuthentication yes; o sshd mantém o primeiro valor que lê, por isso um ficheiro ordenado depois perderia 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, confirme as definições que o sshd utiliza efetivamente, para que um drop-in que perca não o induza em erro:

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

Com as palavras-passe desativadas e o login de root bloqueado, o tráfego constante de brute force contra o seu servidor simplesmente não pode ter êxito. O procedimento completo, incluindo uma alteração opcional da porta, está em Reforçar a segurança do SSH num VPS.

Minuto 8: Ative a firewall

Bloqueie por predefinição todo o tráfego de entrada e permita apenas o que for necessário. Permita o SSH antes de ativar a firewall, caso contrário perderá a própria ligação:

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

Adicione regras allow para todos os serviços que executar efetivamente, como 80/tcp e 443/tcp para um site. Se uma nova sessão SSH deixar de estabelecer ligação depois disso, leia o erro antes de alterar qualquer coisa, porque uma recusa significa que o sshd respondeu e um timeout normalmente significa que a firewall descartou o pacote. Confirme que tanto IPv4 como IPv6 estão abrangidos, porque uma firewall que filtre apenas IPv4 deixa o lado IPv6 completamente exposto. O guia completo está em Firewalls 101 num VPS. Estes comandos ufw pressupõem Ubuntu ou Debian; num servidor Rocky ou AlmaLinux, o objetivo de bloquear tudo por predefinição é o mesmo, mas a ferramenta é firewalld. Por isso, siga a versão deste passo para firewalld.

Minuto 10: Atrase os scanners com Fail2ban

Por fim, adicione o Fail2ban para expulsar os endereços que atacam repetidamente as suas portas:

sudo apt install -y fail2ban

No Ubuntu 24.04, a instalação padrão protege o SSH desde o primeiro arranque. Como as chaves já são obrigatórias, esta é uma medida complementar que reduz o ruído nos logs e bloqueia infratores reincidentes, não a sua principal defesa.

Sua checklist

Esse é o runbook. Use o gerador abaixo para verificar cada controle e produzir uma checklist personalizada que você pode manter com o servidor, incluindo o comando exato de cada etapa:

Execute a checklist uma vez para cada servidor novo até que todo o processo se torne automático. Dez minutos agora evitam a tarde muito problemática que se segue ao comprometimento de um servidor.

Depois que os itens essenciais estiverem configurados, as atualizações automáticas de segurança no Ubuntu mantêm o servidor atualizado sem que você precise iniciar uma nova sessão. Cada serviço instalado sobre essa base precisa da sua própria revisão, e os pontos fracos mudam: com um cofre de senhas auto-hospedado, o servidor nunca armazena texto simples, portanto os riscos reais do Vaultwarden são o token de administrador e o arquivo de backup.

FAQ

O que devo fazer primeiro num VPS novo?

Atualize o sistema com apt update && apt upgrade -y. Em seguida, crie um utilizador normal com sudo e deixe de trabalhar como root. Depois, configure chaves SSH, desative o início de sessão do root e a autenticação por palavra-passe, ative uma firewall com política predefinida de negar e instale o Fail2ban. Seguir esta ordem torna cada passo seguro e evita perder o acesso ao servidor.

Como evito perder o acesso enquanto reforço a segurança do SSH?

Configure e teste o início de sessão com a sua chave SSH antes de desativar as palavras-passe ou o root. Termine a sessão e volte a entrar com a chave para confirmar que funciona. Só depois desative PasswordAuthentication e PermitRootLogin. Ao ativar a firewall, permita a porta 22 antes de executar ufw enable. Se perder o acesso, a consola web do fornecedor permite voltar a entrar sem SSH.

Preciso mesmo de tudo isto num servidor pequeno?

Sim, porque os scanners não consideram o tamanho do servidor. Testam todos os endereços IP públicos da mesma forma. Todo o procedimento demora cerca de dez minutos e elimina os caminhos mais fáceis: sem início de sessão do root, sem tentativas de palavras-passe, sem serviços expostos que não tenha escolhido e com as vulnerabilidades conhecidas corrigidas automaticamente.

Qual é o passo mais importante?

Usar SSH apenas com chaves e desativar o início de sessão do root. A maioria dos ataques contra um VPS novo consiste em tentativas automatizadas de palavras-passe contra o root. Desativar ambos elimina por completo essa categoria de ataque. A firewall e o Fail2ban limitam o que fica exposto e atrasam os ataques restantes.

Como confirmo que o servidor está realmente protegido?

Verifique manualmente três coisas antes de confiar na configuração. Execute sudo ss -tlnp e confirme que apenas as portas que pretendia abrir estão a escutar num endereço público, sem nenhum serviço 0.0.0.0 ou [::] que tenha esquecido. Execute sudo ufw status verbose e confirme que a política predefinida para ligações recebidas é deny e que as regras normal e (v6) estão presentes. Abra sempre uma segunda sessão SSH antes de fechar a primeira. Assim, um erro na configuração do SSH não o impede de aceder ao servidor. Se os três pontos estiverem corretos, os princípios básicos estão implementados.