Mist Network
Checklist de segurança para VPS: 12 passos para proteger um servidor novo
Um VPS novo é escaneado por bots minutos depois de entrar no ar. Este checklist de 12 passos mostra o que travar na primeira hora e o que continuar fazendo todo mês.
Um checklist de segurança para VPS é a lista de passos que você executa em todo servidor novo antes de colocar algo importante nele: travar o SSH, ativar um firewall, manter o sistema atualizado, limitar o que roda e garantir que dá para se recuperar. Bots automatizados começam a sondar IPs novos em minutos, então a primeira hora vale mais do que qualquer ajuste posterior.
Os passos abaixo partem de um VPS Linux como Ubuntu ou Debian com acesso root. Os comandos são exemplos; adapte à sua distribuição. Siga na ordem e mantenha uma segunda sessão SSH aberta enquanto altera configurações de login, para que um erro não deixe você trancado do lado de fora.
Por que blindar um VPS novo
Um servidor virtual privado dá controle total, o que também significa responsabilidade total. Diferente da hospedagem compartilhada, ninguém aplica patches nos seus pacotes nem vigia seus logins. A maioria das invasões reais não vem de exploits engenhosos, e sim de falhas simples: senhas SSH fracas, um app web desatualizado, uma porta de banco de dados exposta ou um serviço de teste esquecido.
A primeira hora: 8 passos essenciais
- Atualize tudo — rode
apt update && apt upgrade(ou o equivalente da sua distribuição) e reinicie se o kernel mudou. - Crie um usuário não root — adicione um usuário com sudo e use-o no dia a dia em vez do root.
- Use chaves SSH — gere um par de chaves no seu computador e copie a chave pública para o servidor com
ssh-copy-id. - Desative login por senha e root — em
/etc/ssh/sshd_configdefinaPasswordAuthentication noePermitRootLogin noe reinicie o SSH depois de testar o login por chave em outra sessão. - Ative um firewall — com ufw, libere só o necessário, por exemplo
ufw allow OpenSSH,ufw allow 80,443/tcpe depoisufw enable. - Ative atualizações de segurança automáticas — no Debian/Ubuntu instale e habilite o
unattended-upgrades. - Instale o fail2ban — ele bloqueia IPs que erram o login repetidamente, freando ataques de força bruta.
- Defina fuso horário e hostname — carimbos de tempo corretos tornam logs e certificados confiáveis.
Blindagem contínua: mais 4 passos
- Remova o que não usa — desinstale pacotes desnecessários e pare serviços que não precisa. Verifique as portas abertas com
ss -tulpn. - Mantenha bancos de dados privados — vincule MySQL, PostgreSQL ou Redis a 127.0.0.1 ou a uma rede privada, nunca à internet pública.
- Faça backup fora do servidor — copie os backups para outro local e teste uma restauração. Um snapshot na mesma máquina não é backup.
- Monitore logs e recursos — revise os logs de autenticação, configure alertas simples de disponibilidade e espaço em disco e investigue picos de CPU inesperados.
O checklist em resumo
| Área | Ação | Frequência |
|---|---|---|
| Acesso | Somente chaves SSH, sem root ou senha | Uma vez; revisar chaves a cada trimestre |
| Rede | Firewall só com as portas necessárias | A cada novo serviço |
| Atualizações | Segurança automática mais upgrades manuais | Automática diária; manual mensal |
| Força bruta | fail2ban ou similar | Uma vez; conferir bloqueios de vez em quando |
| Serviços | Remover software sem uso, bancos de dados locais | Revisão mensal |
| Recuperação | Backups externos com restauração testada | Backup diário; teste de restauração trimestral |
| Web | HTTPS, CMS e plugins atualizados | Semanal |
Protegendo a camada web
Se o VPS hospeda um site, a aplicação costuma ser o ponto mais fraco. Mantenha CMS, plugins e frameworks atualizados, use HTTPS com um certificado gratuito e rode cada site com seu próprio usuário de sistema, para que um site comprometido não leia os outros. Adicione um registro CAA ao domínio para que só a autoridade certificadora escolhida emita certificados, e aponte o domínio corretamente com nosso guia sobre como apontar um domínio para um VPS.
Guarde segredos como chaves de API e senhas de banco em arquivos de ambiente com permissões restritas, nunca num diretório web público ou num repositório Git.
Acesso para equipes e vários administradores
Servidores raramente continuam com um único usuário por muito tempo. Assim que um colega, freelancer ou ferramenta de deploy precisa de acesso, a forma como você distribui credenciais passa a fazer parte da segurança.
- Uma chave por pessoa — cada administrador tem sua conta e sua chave SSH. Nunca compartilhe a senha root ou uma única chave na equipe.
- Chaves separadas para automação — pipelines de CI e rotinas de backup recebem chaves próprias, restritas aos comandos ou diretórios necessários.
- Remova o acesso no mesmo dia — quando alguém sai do projeto, apague o usuário e a chave imediatamente. Revise os arquivos
authorized_keysa cada trimestre. - Registre ações privilegiadas — o sudo grava quem executou o quê, o que facilita muito rastrear erros e incidentes.
- Proteja também o painel — a conta no provedor pode reinstalar ou apagar o servidor; use senha forte e única e autenticação em dois fatores quando disponível.
O que fazer se suspeitar de invasão
- Não apague evidências de imediato; tire um snapshot ou copie os logs primeiro.
- Troque todas as senhas e chaves SSH que tiveram contato com o servidor.
- Procure usuários, cron jobs, chaves SSH e processos desconhecidos.
- Na dúvida, reinstale a partir de uma imagem limpa e restaure os dados de um backup anterior ao incidente.
Uma base segura com o VPS da mistREG
A mistREG oferece servidores VPS KVM na Eslovênia (UE) com NVMe SSD e AMD EPYC. O KVM dá a cada servidor seu próprio kernel, então você pode usar o firewall, os ajustes de kernel ou as ferramentas de segurança que quiser. O provisionamento é automático: cerca de 60 segundos após o pagamento, o IP e a senha root aparecem no painel, prontos para este checklist. Saiba mais no guia de VPS offshore.
Crie uma conta, recarregue com cripto ou cartão e escolha um servidor na seção de planos. Dúvidas? Nossa equipe está no Telegram em @mistnetwork.
