Um VPS recém-criado fica exposto a ataques automatizados poucos minutos depois de entrar no ar — este checklist guia você pela primeira hora de proteção que garante que ele continue seu.
Todo servidor novo começa com as mesmas fraquezas: um login root padrão, uma porta SSH que só aceita senha, firewall totalmente aberto e nenhuma atualização automática. Bots varrem todo o espaço IPv4 continuamente, então "ainda ninguém sabe meu IP" nunca é verdade.
Este guia é um checklist de proteção ordenado e pronto para copiar. Siga de cima para baixo em uma máquina Debian ou Ubuntu recém-instalada e você fechará as brechas que os atacantes realmente exploram, não aquelas com que o "teatro de segurança" se preocupa.
Antes de tocar no servidor
Duas decisões tomadas antes do seu primeiro login economizam horas depois. Prepare sua chave SSH e escolha um nome de usuário que não seja root.
- 1
Gere uma chave SSH moderna
Na sua própria máquina, execute ssh-keygen -t ed25519 -C "you@device". As chaves Ed25519 são curtas, rápidas e mais fortes que o antigo padrão RSA-2048.
- 2
Mantenha a chave privada fora do servidor
A metade privada nunca sai do seu laptop. Você só copia o arquivo .pub para os servidores. Ignorar essa regra é como as pessoas acabam se trancando para fora e precisando reprovisionar tudo.
- 3
Anote suas credenciais de provisionamento
A maioria dos provedores envia por e-mail uma senha root temporária ou injeta sua chave no momento da criação. Se uma chave foi injetada, você pode pular direto para a criação de um usuário.
Se o seu host injeta sua chave SSH no momento do deploy, você nunca chega a ter uma janela baseada em senha — a maior superfície de ataque desaparece antes mesmo do boot.
Passo 1 — Atualize tudo e depois mantenha atualizado
Um kernel ou OpenSSL desatualizado é a única falha que nenhuma regra de firewall corrige. Atualize antes de configurar qualquer outra coisa.
- Debian/Ubuntu: apt update && apt full-upgrade -y e depois reinicie se o kernel tiver mudado.
- Ative o unattended-upgrades para que os patches de segurança sejam aplicados automaticamente: apt install unattended-upgrades && dpkg-reconfigure unattended-upgrades.
- Reinicie em um horário que você controla — configure Unattended-Upgrade::Automatic-Reboot para um horário de baixo uso, em vez de deixar kernels parcialmente aplicados.
Passo 2 — Crie um usuário de verdade e aposente o root
Fazer login como root significa que uma única sessão comprometida controla a máquina inteira e não deixa rastro de auditoria. Em vez disso, crie para você uma conta sudo nomeada.
- 1
Adicione o usuário
adduser deploy e depois usermod -aG sudo deploy (use wheel em sistemas da família RHEL).
- 2
Instale sua chave para esse usuário
No seu laptop: ssh-copy-id deploy@your-server-ip. Isso grava sua chave pública em ~/.ssh/authorized_keys com as permissões corretas.
- 3
Teste antes de trancar a porta
Abra um segundo terminal e confirme que você consegue dar ssh deploy@server e executar sudo -v. Nunca desative o root ou as senhas até que uma sessão nova funcione.
Regra de ouro da proteção de SSH: mantenha sua sessão atual aberta e comprove que o novo login funciona em uma segunda janela antes de alterar qualquer configuração de autenticação. Esse único hábito evita quase todo tipo de bloqueio.
Passo 3 — Proteção do SSH, a parte que mais importa
O SSH é a porta da frente de todo VPS, e é onde a maioria das tentativas automatizadas de login se concentra. Edite /etc/ssh/sshd_config (ou um drop-in em /etc/ssh/sshd_config.d/) e defina estas chaves.
Aplique com sshd -t para validar a sintaxe e depois systemctl restart ssh. Se o sshd -t reportar um erro, corrija-o antes de reiniciar, ou você pode derrubar o daemon.
Mudar a porta do SSH além da 22 é opcional e só reduz o ruído nos logs — é obscuridade, não segurança. Assim que o PasswordAuthentication estiver desativado, os bots de varredura de portas não têm nada para adivinhar, então concentre seu esforço em chaves, não em jogos de porta.
Passo 4 — Ative um firewall padrão-negar
Um daemon SSH protegido ainda compartilha a máquina com todos os outros serviços em escuta. Um firewall torna o padrão "fechado, a menos que eu tenha aberto".
- 1
Defina a base
Com o ufw: ufw default deny incoming e ufw default allow outgoing.
- 2
Permita apenas o que você serve
ufw allow OpenSSH, e ufw allow 80,443/tcp apenas se esta máquina realmente hospedar tráfego web.
- 3
Ative e verifique
ufw enable e depois ufw status verbose. Tudo que não estiver listado agora está inacessível a partir da internet.
Inclua a regra do SSH no firewall antes de ativar o ufw. Ativar um firewall padrão-negar sem uma regra de permissão para a sua própria porta vai derrubar sua sessão.
Passo 5 — Retarde ataques de força bruta com o Fail2ban
Mesmo com as senhas desativadas, os bots continuam batendo na porta e inflando seus logs. O Fail2ban bane os reincidentes no nível do firewall.
- apt install fail2ban — a jail sshd já vem pronta para uso.
- Copie jail.conf para jail.local e aumente o bantime (por exemplo, 1h) e reduza o maxretry (por exemplo, 3) conforme sua preferência.
- Verifique se está funcionando com fail2ban-client status sshd para ver a contagem de IPs banidos.
Passo 6 — Reduza a superfície de ataque
O serviço mais seguro é aquele que não está em execução. Audite o que está em escuta e elimine o que você não precisa.
Audite as portas abertas
ss -tulpn lista todos os sockets em escuta e o processo por trás de cada um. Investigue qualquer coisa que você não tenha iniciado deliberadamente.
Remova pacotes obsoletos
Desative ou desinstale os serviços que você não está usando — um banco de dados ou agente de e-mail deixado em execução é puro risco.
Isole os serviços
Vincule daemons internos, como bancos de dados, a 127.0.0.1 para que nunca fiquem expostos mesmo se o firewall falhar.
Trave as permissões
Garanta que ~/.ssh esteja com permissão 700 e authorized_keys com 600. Permissões erradas fazem o sshd ignorar sua chave silenciosamente.
Passo 7 — Registre, monitore e conheça sua linha de base
A proteção não é um evento único. Você precisa perceber quando algo muda.
- Revise a atividade de autenticação com journalctl -u ssh ou lastb para logins malsucedidos.
- Considere o auditd para um registro à prova de adulteração das ações privilegiadas.
- Mantenha um backup fora do servidor de /etc e dos seus dados, para que uma máquina comprometida possa ser reconstruída do zero, em vez de continuar sendo usada depois do fato.
Onde o próprio host importa
A proteção via software protege o sistema operacional, mas é o provedor que decide o que está por baixo dele — filtragem de rede, rastro de pagamento e se uma identidade chega a ser vinculada ao servidor. Na ChainVPS, todo plano já vem com filtragem DDoS e banda ilimitada, e os servidores são pagos a partir de um saldo pré-pago em cripto, com 21 moedas disponíveis incluindo Monero, sem KYC. Se o seu modelo de ameaça inclui não vincular um servidor à sua identidade, nossos planos de VPS offshore foram feitos exatamente para isso.
A localização também faz parte da proteção: seis das nossas quinze regiões são jurisdições de nível privacidade (NL, CH, RO, IS, MD, LU). Combinar um sistema operacional protegido com um servidor dedicado offshore mantém tanto a superfície de software quanto a jurídica bem fechadas.
O checklist de uma hora, resumido
- Atualização completa do sistema + patches de segurança automáticos ativados
- Usuário sudo nomeado criado, chave instalada, login testado
- Login SSH do root e autenticação por senha, ambos desativados
- Configuração do SSH validada com sshd -t e recarregada
- Firewall padrão-negar ativo, apenas as portas necessárias abertas
- Fail2ban em execução na jail do sshd
- Portas abertas auditadas, serviços não utilizados removidos
- Backup fora do servidor e revisão de logs implementados
Devo mudar a porta do SSH para algo diferente de 22?
É opcional e reduz apenas o ruído nos logs, não o risco real. Assim que a autenticação por senha estiver desativada e as chaves forem obrigatórias, mudar a porta acrescenta obscuridade em vez de segurança — priorize desativar as senhas primeiro.
É seguro desativar a autenticação por senha se eu tiver apenas uma chave?
Sim, desde que você tenha testado o login por chave em uma sessão separada e mantenha um backup da chave privada. Muitos provedores também oferecem um console web ou modo de recuperação, então você nunca fica realmente trancado para fora do hardware.
Ainda preciso de firewall se o SSH for o único serviço?
Sim. Um firewall padrão-negar protege você de serviços que você esqueceu que instalou e de qualquer coisa que um pacote futuro comece a escutar silenciosamente. Não custa nada e elimina surpresas.
Com que frequência devo revisar a proteção?
As atualizações de segurança automáticas cuidam do trabalho diário, mas revise as portas em escuta e os logs de autenticação após qualquer instalação importante de software e pelo menos uma vez por mês. Trate uma linha de base protegida como algo que você verifica, não algo que você configura uma vez e esquece.
