Proteja Sua VPS: Um Checklist dos Primeiros 10 Minutos

Escrito pela equipe ApexVPS • Última atualização: julho de 2026 • leitura de 9 min

Uma VPS Linux recém-criada é sondada por bots automatizados em poucos minutos após ficar online, então o primeiro movimento mais inteligente é seguir um checklist de proteção de VPS antes de instalar qualquer outra coisa. Este guia é esse checklist: uma rotina prática dos primeiros 10 minutos que você pode seguir em qualquer servidor Ubuntu ou Debian novo para criar um usuário não-root, proteger o SSH, ativar um firewall e fechar a porta para logins de força bruta. Todos os comandos abaixo são padrão e seguros para copiar, e nenhum exige ferramentas especiais — apenas seu terminal e alguns minutos.

Siga os passos em ordem. Cada um se baseia no anterior, e no final você terá um servidor muito mais difícil de invadir do que a imagem padrão com a qual começou.

Por que a pressa? O espaço de IPv4 público é varrido continuamente. Mecanismos de busca para dispositivos conectados à internet, junto com incontáveis botnets, catalogam novos hosts e tentam credenciais padrão o tempo todo. A lacuna entre "servidor está no ar" e "servidor está sendo atacado" é medida em minutos, não em dias. Gastar dez minutos focados nessas noções básicas tira você do grupo de alvos fáceis que as ferramentas automatizadas adoram, e isso não custa nada além da sua atenção.

Antes de começar

Você precisará de acesso SSH ao seu novo servidor e do endereço IP que seu provedor enviou por e-mail. Na ApexVPS, todo plano inclui acesso root completo, então você pode concluir todo esse processo de endurecimento sozinho. Abra um terminal e conecte-se como root (ou o usuário padrão criado pela sua imagem):

ssh root@your_server_ip

Uma regra é mais importante do que qualquer outra: nunca desabilite um método de login até confirmar que a substituição funciona. Mantenha sua primeira sessão SSH aberta enquanto testa uma segunda. Se algo der errado, essa sessão aberta é sua rede de segurança.

Passo 1 — Atualize o sistema

Software atualizado é a base de toda lista de verificação de segurança para VPS. Comece atualizando o índice de pacotes e instalando as correções de segurança mais recentes:

sudo apt update && sudo apt upgrade -y

Em uma imagem nova, isso frequentemente puxa dezenas de atualizações, incluindo correções do kernel e do OpenSSH. Se o kernel for atualizado, planeje uma reinicialização com sudo reboot assim que o restante da lista estiver concluído.

Passo 2 — Crie um usuário não root com sudo

Fazer login diretamente como root é arriscado: um único comando errado é executado com privilégios ilimitados, e root é a primeira conta que todo atacante tenta invadir. Crie um usuário dedicado e conceda a ele direitos administrativos por meio de sudo:

adduser deploy
usermod -aG sudo deploy

O primeiro comando cria a conta e solicita uma senha; o segundo o adiciona ao grupo sudo. Troque deploy por qualquer nome que você queira. A partir de agora, você fará login como este usuário e elevará para root somente quando um comando específico precisar.

Passo 3 — Configure autenticação por chave SSH

Senhas podem ser adivinhadas; chaves SSH efetivamente não podem. Gere um par de chaves Ed25519 moderno na sua máquina local (não no servidor):

ssh-keygen -t ed25519 -C "[email protected]"

Aceite o local padrão e, idealmente, defina uma frase secreta. Em seguida, copie a chave pública para o seu novo usuário no servidor:

ssh-copy-id deploy@your_server_ip

Se ssh-copy-id não estiver disponível, crie o diretório e o arquivo manualmente no servidor, cole sua chave pública no ~/.ssh/authorized_keys e ajuste as permissões:

mkdir -p ~/.ssh
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Agora abra um novo terminal e confirme que você pode fazer login sem senha: ssh deploy@your_server_ip. Não avance até que isso funcione — o próximo passo depende disso.

Passo 4 — Reforce o SSH: desative login root e senhas

Com o login por chave comprovado, desligue as opções mais fracas. Edite a configuração do daemon SSH:

sudo nano /etc/ssh/sshd_config

Defina (ou descomente e altere) estas três diretivas:

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes

Valide o arquivo antes de aplicá-lo e reinicie o serviço:

sudo sshd -t
sudo systemctl restart ssh

O comando sshd -t detecta erros de digitação que poderiam bloqueá-lo. Após a reinicialização, teste uma nova conexão em um terminal separado. O login root sobre SSH e a adivinhação de senha estão agora fora de cogitação.

Altere a porta SSH (opcional)

Mover o SSH da porta 22 não impedirá um atacante determinado, mas esconderá você do ruído de fundo constante dos bots que só escaneiam a porta padrão. Se você quiser, adicione uma linha como Port 2222 em /etc/ssh/sshd_config. Crucialmente, abra a nova porta no seu firewall (próximo passo) antes de reiniciar o SSH, ou você será bloqueado.

Passo 5 — Ative um firewall com UFW

Um firewall garante que apenas as portas que você pretende expor estejam acessíveis. Ubuntu e Debian vêm com UFW (Uncomplicated Firewall), que é exatamente o que o nome promete. Defina um padrão sensato e permita SSH antes de ativá-lo:

sudo apt install ufw -y
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH
sudo ufw enable
sudo ufw status verbose

O perfil OpenSSH abre a porta 22. Se você mudou o SSH na etapa anterior, permita a nova porta com sudo ufw allow 2222/tcp. Executando um site? Adicione HTTP e HTTPS:

sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

Todo o resto permanece fechado por padrão, que é exatamente o que você deseja em um servidor público.

Passo 6 — Instale fail2ban para impedir força bruta

Mesmo com chaves, os atacantes continuarão martelando sua porta SSH. O fail2ban monitora seus logs e bloqueia temporariamente qualquer IP que falhar muitas vezes. Instale-at e habilite:

sudo apt install fail2ban -y
sudo systemctl enable --now fail2ban

Para personalizar as regras, copie a configuração padrão para uma substituição local para que as atualizações nunca sobrescrevam suas alterações e edite-a:

sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
sudo nano /etc/fail2ban/jail.local

Na seção [sshd], você pode ajustar valores como maxretry e bantime. Recarregue com sudo systemctl restart fail2ban e verifique quem está atualmente banido usando sudo fail2ban-client status sshd.

Etapa 7 — Ative as atualizações de segurança automáticas

Falhas de segurança são descobertas constantemente, e as que prejudicam são as correções que você nunca aplicou. O pacote unattended-upgrades instala atualizações importantes para você em um agendamento:

sudo apt install unattended-upgrades -y
sudo dpkg-reconfigure -plow unattended-upgrades

Escolha "Sim" quando solicitado, e o Ubuntu ou Debian aplicará silenciosamente as atualizações de segurança em segundo plano. Este único passo fecha a lacuna entre a divulgação de uma vulnerabilidade e o seu servidor estar protegido.

Etapa 8 — Desative serviços não utilizados e endurecimento básico

Cada serviço que escuta na rede é uma porta de entrada em potencial, então remova o que você não precisa. Liste o que está realmente rodando e o que está vinculado a uma porta:

sudo systemctl list-units --type=service --state=running
sudo ss -tulpn

Se você notar um serviço que não está usando, desative e pare-o:

sudo systemctl disable --now <service-name>

Algumas vitórias rápidas adicionais completam a lista de verificação:

Para uma visão mais aprofundada, em nível de framework, da configuração segura, a Fundação OWASP publica diretrizes de endurecimento e segurança amplamente respeitadas que valem a pena adicionar aos favoritos à medida que sua configuração cresce.

Sua lista de verificação de 10 minutos de relance

Mantenha este resumo em um local útil — é toda a rotina para proteger um VPS em formato de lista de verificação, para que você possa repeti-lo em poucos minutos em cada novo servidor que você criar:

  1. Atualize todos os pacotes e reinicie se o kernel mudou.
  2. Crie um usuário não-root e adicione-o ao grupo sudo.
  3. Gere uma chave SSH Ed25519 e copie a chave pública para o servidor.
  4. Confirme que o login baseado em chave funciona em um segundo terminal.
  5. Desative o login root e a autenticação por senha em sshd_config.
  6. Opcionalmente, mova o SSH para uma porta não padrão.
  7. Ative o UFW, negue as conexões de entrada por padrão e permita apenas as portas que você usa.
  8. Instale o fail2ban para banir automaticamente tentativas de força bruta.
  9. Ative as atualizações de segurança sem supervisão.
  10. Desative serviços não utilizados e revise o que está escutando.

Nenhum desses passos é difícil por si só, mas pular qualquer um deles deixa uma lacuna óbvia. Feitos juntos, eles formam uma base sólida que impede a grande maioria dos ataques oportunistas. A partir daqui, você pode adicionar extras conforme suas necessidades crescem — um proxy reverso com TLS, uma ferramenta de detecção de intrusão, isolamento por serviço com contêineres ou um backup externo do seu próprio em cima dos snapshots do provedor.

Como a ApexVPS complementa seu endurecimento

A lista de verificação acima endurece o sistema operacional, mas algumas ameaças vivem abaixo dele. Ataques volumétricos e falhas de hardware são tratados na camada de infraestrutura, e é aí que o seu provedor importa. Todo plano ApexVPS inclui proteção DDoS sempre ativa, para que uma enxurrada de tráfego seja absorvida antes de chegar ao seu firewall, além de backups automatizados — diários no Starter Pro e snapshots por hora nos planos Business e Enterprise — para que um erro ou comprometimento nunca signifique começar do zero. Monitoramento 24/7 e CPU e RAM verdadeiramente dedicados significam que um vizinho barulhento não pode nem te atrasar nem se tornar seu problema.

Você pode ver o conjunto completo de proteções na visão geral dos recursos da ApexVPS e comparar o que cada plano inclui na página de planos e preços de VPS. Se você está protegendo um servidor especificamente para executar seus próprios aplicativos, o nosso guia de VPS para autohospedagem combina perfeitamente com esta lista. O cadastro é somente com e-mail e o checkout é somente com criptomoedas via OxaPay — Bitcoin, Ethereum, USDT e mais de 30 moedas, sem cartão de crédito, sem conta bancária e sem KYC.

Perguntas frequentes

Qual é a primeira coisa a fazer para proteger um novo VPS?

Atualize todos os pacotes com sudo apt update && sudo apt upgrade -y, depois crie um usuário não-root com direitos sudo para parar de fazer login como root. Esses dois passos fecham os caminhos de ataque mais comuns e mais danosos antes de configurar qualquer outra coisa.

Devo alterar a porta SSH padrão?

É opcional. Mover o SSH para fora da porta 22 reduz o volume de varreduras automatizadas nos seus logs, mas não é segurança real por si só — autenticação por chave, firewall e fail2ban fazem o trabalho pesado. Se você mudar a porta, abra a nova no UFW antes de reiniciar o SSH para não ficar bloqueado.

Ainda preciso de um firewall se uso chaves SSH?

Sim. As chaves SSH protegem apenas o serviço SSH; um firewall como o UFW controla todas as outras portas da máquina. Negar todo o tráfego de entrada por padrão e permitir apenas as portas que você realmente usa é uma parte essencial de qualquer checklist de VPS seguro, com ou sem chaves.

O fail2ban é necessário em um VPS?

É altamente recomendado. Mesmo com logins por senha desabilitados, os bots continuarão sondando sua porta SSH e poluindo seus logs. O fail2ban bloqueia automaticamente os infratores reincidentes, reduzindo o ruído e bloqueando a pequena chance de um ataque de força bruta bem-sucedido contra qualquer serviço.

A ApexVPS inclui proteção DDoS e backups?

Sim. Todos os planos vêm com proteção DDoS sempre ativa e backups automatizados — diários no Starter Pro e snapshots por hora no Business e Enterprise — além de monitoramento 24/7. Isso complementa o endurecimento do seu próprio sistema operacional, cobrindo a camada de infraestrutura que você não pode proteger de dentro do servidor.

Quer facilitar a proteção? Veja a proteção DDoS, backups e recursos dedicados em todos os planos ApexVPS →