Início / Blog / Segurança

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

ItemComo conferir
Usuário comum com sudoid nome mostra o grupo sudo
Login por chavevocê entra sem digitar senha
Root e senha desligados no SSHsudo sshd -T mostra permitrootlogin no e passwordauthentication no
Firewall ativosudo ufw status
Atualizações automáticaspacote unattended-upgrades instalado
Bloqueio de força brutasudo fail2ban-client status
Só serviços necessáriossudo ss -tulpn
Banco só em localhostporta do banco fora da lista pública
Upload sem execuçãoarquivo de teste em upload não roda
HTTPS renovandosudo certbot renew --dry-run
Backup externo testadoúltima restauração com data
Monitoramentoalgué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

Software sob medida · est. 2026

Descubra o que corrigir primeiro. De graça e por escrito.

Diagnóstico gratuito do seu site, Google, processos e segurança visível. Sem compromisso.

Quero meu diagnóstico →