Segurança
Segurança de VPS: checklist de 12 itens para servidor Linux
Uma VPS recém-contratada já recebe testes de portas e senhas de robôs do mundo inteiro. Doze itens deixam o servidor mais difícil de invadir: acesso SSH por chave, firewall, atualização automática, fail2ban, backup testado e monitoramento. Aplique na ordem do artigo, de preferência no dia da contratação.
SSH com chave, firewall, atualização automática, fail2ban, backup testado e monitoramento. Um checklist de 12 itens para deixar a sua VPS Linux mais difícil de invadir.
Contratar uma VPS é rápido. Em poucos minutos o servidor está no ar, com um IP público e acesso de root. O que pouca gente percebe é que, a partir desse momento, robôs do mundo inteiro já começam a testar portas e senhas nesse IP. Não é pessoal: é varredura automática, o tempo todo, em todos os endereços da internet.
A boa notícia é que a maior parte desses ataques é barrada por cuidados básicos. Este checklist reúne 12 itens que valem para qualquer VPS Linux (Ubuntu, Debian, AlmaLinux, Rocky), seja na Hostinger, na AWS, na DigitalOcean ou em qualquer outro provedor. Os comandos são exemplos para Debian e Ubuntu; em outras distribuições, o nome dos pacotes pode mudar.
Antes de começar: faça as mudanças com uma segunda sessão SSH aberta. Se algo der errado na configuração do acesso, você ainda tem por onde voltar.
1. Crie um usuário comum e pare de entrar como root
Trabalhar como root o tempo todo transforma qualquer erro em desastre e facilita a vida de quem descobre a senha. Crie um usuário próprio com adduser nome e dê permissão administrativa com usermod -aG sudo nome. A partir daí, use sudo só quando precisar.
2. Entre por chave SSH, não por senha
Senha pode ser adivinhada, vazada ou reaproveitada de outro serviço. Chave SSH é praticamente impossível de adivinhar. Gere a chave no seu computador (ssh-keygen -t ed25519), copie para o servidor (ssh-copy-id nome@ip) e teste o acesso. Só depois de confirmar que a chave funciona, desligue o login por senha.
3. Feche o SSH para root e para senha
No arquivo /etc/ssh/sshd_config, ajuste PermitRootLogin no e PasswordAuthentication no. Reinicie o serviço com sudo systemctl restart ssh (em algumas distribuições o serviço se chama sshd). A documentação do sshd_config explica cada opção. Trocar a porta padrão 22 reduz o barulho nos logs, mas não substitui esses dois ajustes.
4. Ligue o firewall e deixe aberto só o necessário
Um servidor web normalmente precisa de três portas: SSH, HTTP (80) e HTTPS (443). Banco de dados, painel de administração e serviços internos não devem ficar expostos para a internet. No Ubuntu, o ufw resolve em poucos comandos: sudo ufw allow OpenSSH, sudo ufw allow 80,443/tcp e sudo ufw enable. Confira o resultado com sudo ufw status. Muitos provedores também oferecem firewall no painel; usar os dois não atrapalha.
5. Atualize o sistema e ligue as atualizações de segurança automáticas
A maior parte das invasões em servidor pequeno explora falhas que já têm correção publicada. Rode sudo apt update && sudo apt upgrade com frequência e instale o pacote unattended-upgrades para aplicar as correções de segurança sozinho. A página da comunidade Ubuntu sobre atualizações automáticas mostra a configuração.
6. Bloqueie quem insiste em errar a senha
Mesmo com login por chave, os robôs continuam batendo. O fail2ban lê os logs e bloqueia por um tempo os IPs que erram demais. Ele é um bom complemento, mas tem limites claros; explicamos o que ele cobre e o que deixa de fora em fail2ban é suficiente?.
7. Remova o que você não usa
Cada serviço instalado é uma porta a mais. Liste o que está escutando na rede com sudo ss -tulpn e desinstale o que não tem motivo para estar ali: servidor de e-mail esquecido, painel de teste, banco de dados de um projeto antigo. Menos software significa menos atualização para acompanhar e menos falha possível.
8. Proteja o banco de dados
MySQL, PostgreSQL, MongoDB e Redis devem escutar só em 127.0.0.1 ou na rede interna, nunca no IP público. Use um usuário de banco por aplicação, com permissão só no que ela precisa, e senha longa e única. Bancos expostos sem senha ainda são uma das causas mais comuns de vazamento de dados.
9. Cuide das pastas de upload e das permissões
Se o site aceita upload, essa pasta é o alvo preferido para esconder webshell. Configure o servidor web para não executar PHP ou scripts dentro dela e valide o tipo do arquivo no código. O guia da OWASP sobre upload de arquivos lista os cuidados. Arquivos do site não precisam pertencer ao root nem ter permissão 777; dê ao servidor web só o que ele precisa ler e gravar. Em WordPress, veja também como achar e remover webshell.
10. Use HTTPS e mantenha o certificado em dia
Certificado gratuito do Let's Encrypt, renovado de forma automática pelo certbot, resolve para a maioria dos sites. Confira se a renovação está agendada com sudo certbot renew --dry-run. Certificado vencido derruba a confiança do visitante e, em alguns navegadores, bloqueia o acesso ao site.
11. Faça backup fora do servidor e teste a restauração
Backup guardado no mesmo servidor some junto com ele. Mantenha cópias em outro lugar (outro provedor, armazenamento de objetos, outra conta) e com pelo menos uma versão que o servidor não consiga apagar. Uma vez por mês, restaure um backup num ambiente de teste. Backup que nunca foi restaurado é só esperança.
12. Monitore e leia os sinais
Os 11 itens anteriores diminuem a chance de invasão, mas não zeram. Por isso o último item é saber quando algo mudou: arquivos novos em pastas sensíveis, processo estranho consumindo CPU, milhares de tentativas de login, pacote com vulnerabilidade conhecida. Ferramentas como o Lynis fazem uma auditoria pontual e dão uma nota de endurecimento do sistema. Para saber o que procurar à mão, veja como saber se o servidor foi invadido.
Resumo do checklist
| Item | Como conferir |
|---|---|
| Usuário comum com sudo | id nome mostra o grupo sudo |
| Login por chave | você entra sem digitar senha |
| Root e senha desligados no SSH | sudo sshd -T mostra permitrootlogin no e passwordauthentication no |
| Firewall ativo | sudo ufw status |
| Atualizações automáticas | pacote unattended-upgrades instalado |
| Bloqueio de força bruta | sudo fail2ban-client status |
| Só serviços necessários | sudo ss -tulpn |
| Banco só em localhost | porta do banco fora da lista pública |
| Upload sem execução | arquivo de teste em upload não roda |
| HTTPS renovando | sudo certbot renew --dry-run |
| Backup externo testado | última restauração com data |
| Monitoramento | alguém recebe e lê os alertas |
Quando o checklist não basta
Cuidar disso uma vez é fácil. O difícil é manter: lembrar de olhar os logs, perceber o arquivo novo na pasta de upload, acompanhar as vulnerabilidades publicadas toda semana. Em empresa pequena, quase sempre ninguém tem esse tempo.
É para isso que existe o Oven Sec, segurança de servidor Linux que roda dentro da VPS: a cada 12 horas ele varre arquivos, processos, logs e dependências, dá uma nota de postura para o servidor e manda o relatório para o canal da sua equipe. Para uma revisão completa do site e das contas feita por pessoas, veja a blindagem digital.
Fontes
- OpenBSD, manual do sshd_config.
- Ubuntu Community Help Wiki, AutomaticSecurityUpdates.
- OWASP Cheat Sheet Series, File Upload Cheat Sheet.
- Center for Internet Security, CIS Benchmarks.
- CISOfy, Lynis.