VPS com firewall e hardening de segurança

Resposta direta

Uma VPS segura começa com acesso SSH por chave, usuário administrativo sem login root direto, firewall liberando apenas as portas necessárias, atualizações aplicadas com rotina clara, fail2ban bloqueando tentativas repetidas e backups testados fora do próprio servidor. Para um projeto web comum, a configuração inicial costuma liberar somente 22 ou uma porta SSH alternativa restrita por IP, 80 e 443 para tráfego HTTP e HTTPS, além de bloquear todo o restante por padrão. Antes de colocar WordPress, API, n8n, painel de controle ou aplicação própria em produção, confirme quem administra o sistema operacional, onde ficam os backups, como restaurar o serviço e quais alertas avisam sobre queda, disco cheio ou aumento anormal de tentativas de login.

Resumo rápido

• Use chaves SSH e desative login por senha assim que confirmar o acesso alternativo.
• Configure firewall com política padrão de negar entrada e liberar só portas necessárias.
• Ative atualizações de segurança, mas planeje janelas para pacotes sensíveis como kernel e banco de dados.
• Instale fail2ban para reduzir ataques de força bruta em SSH, Nginx, Apache e painéis expostos.
• Separe backups de snapshots e teste restauração com frequência, não apenas a criação da cópia.
• Revise serviços ativos com comandos como ss -tulpn, systemctl e logs do sistema.
• Documente um checklist de produção antes de publicar aplicações reais na VPS.

Antes de abrir a VPS para a internet

A primeira decisão de segurança vem antes do primeiro comando: entender quem é responsável por cada camada. Em uma VPS não gerenciada, o provedor entrega o servidor virtual, rede, painel e infraestrutura física, mas a configuração do Linux, firewall, usuários, pacotes, logs, backups de aplicação e correções ficam com você. Em uma VPS gerenciada, parte dessas tarefas pode ser assumida pelo provedor ou por uma equipe terceirizada. Essa diferença muda tudo, principalmente quando o projeto deixa de ser laboratório e começa a receber usuários reais. Se você ainda está escolhendo o modelo operacional, o guia sobre VPS gerenciada ou não gerenciada ajuda a separar custo, autonomia e responsabilidade técnica.

Entenda o modelo de responsabilidade

Pense em uma VPS Ubuntu 24.04 com 2 vCPUs, 4 GB de RAM e 80 GB de SSD rodando Nginx, PostgreSQL e uma aplicação Node.js. O provedor pode garantir que a máquina virtual liga, recebe IP público e mantém conectividade. Ele não sabe se você deixou a porta 5432 do PostgreSQL aberta para o mundo, se publicou uma chave privada por engano ou se o painel administrativo está usando senha fraca. Esses pontos pertencem ao hardening do sistema e precisam entrar no processo de implantação.

Hardening não é uma ação única. É um conjunto de escolhas que reduzem a superfície de ataque. Menos portas abertas, menos serviços rodando, menos contas com privilégio, menos autenticação por senha e mais rastreabilidade. Em servidores Linux, a linha de base mínima inclui usuário não root com sudo, SSH por chave, firewall local, pacotes atualizados, logs preservados e backup externo. Em Windows Server, os conceitos são parecidos, mas a implementação muda para RDP restrito, Windows Defender Firewall, políticas de senha, atualização via Windows Update e auditoria de eventos. Se a dúvida for de sistema operacional, veja também o comparativo entre VPS Linux ou VPS Windows, porque a escolha afeta comandos, ferramentas e rotina de suporte.

Crie uma linha de base antes do deploy

Uma boa linha de base começa com inventário. Rode hostnamectl, ip addr, df -h, free -m, ss -tulpn e systemctl --type=service --state=running antes de instalar a aplicação. Guarde a saída em um arquivo interno ou wiki do projeto. Isso cria uma foto inicial do ambiente e facilita descobrir o que mudou depois de instalar Docker, painel, banco de dados ou agente de monitoramento. Em times pequenos, essa documentação evita o cenário clássico: alguém abre uma porta temporária para testar e ninguém fecha depois.

Firewall na VPS: portas mínimas e regras seguras

Firewall de VPS precisa seguir uma regra simples: bloquear tudo na entrada e liberar apenas o que tem função clara. Em um servidor web básico, as portas normalmente expostas são 80 para HTTP, 443 para HTTPS e 22 para SSH. Mesmo assim, SSH não precisa ficar aberto para qualquer IP em todos os cenários. Se você trabalha sempre de uma rede corporativa, VPN ou IP fixo, restrinja a origem. Se usa IP residencial dinâmico, considere uma VPN como WireGuard, Tailscale ou acesso via bastion host antes de deixar SSH exposto globalmente.

UFW para Ubuntu e Debian

No Ubuntu e em muitas imagens Debian, o UFW é suficiente para começar com segurança. Ele simplifica regras do netfilter e reduz erro operacional. Um fluxo inicial seguro seria este:

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verbose

Se o SSH estiver em uma porta alternativa, por exemplo 2222, libere a porta antes de reiniciar o serviço. Um erro comum é alterar sshd_config, reiniciar o SSH e só depois lembrar do firewall. Faça o oposto: crie a nova regra, teste uma segunda sessão e mantenha a sessão antiga aberta até confirmar login. Para restringir SSH por origem, use algo como sudo ufw allow from 203.0.113.10 to any port 22 proto tcp. O IP de exemplo deve ser trocado pelo endereço autorizado real.

Cloud firewall e firewall local não são rivais

Muitos provedores de Cloud Server oferecem firewall no painel, incluindo regras por instância, projeto ou rede privada. Esse recurso é útil porque filtra tráfego antes de chegar ao sistema operacional. Ainda assim, ele não substitui o firewall local. O ideal é usar as duas camadas: cloud firewall para bloquear portas na borda e UFW, nftables ou firewalld dentro da VPS para manter proteção caso alguém altere regras no painel ou migre a máquina.

Em aplicações com banco de dados no mesmo servidor, a porta 5432 do PostgreSQL ou 3306 do MySQL não deve aparecer aberta publicamente. Use ss -tulpn para verificar escuta e configure o banco para responder apenas em 127.0.0.1 quando a aplicação estiver no mesmo host. Em Docker, atenção extra: regras publicadas com -p 0.0.0.0:5432:5432 expõem o serviço para todas as interfaces. Prefira publicar internamente, usar redes Docker privadas e expor somente o proxy reverso. Firewall bom não compensa uma aplicação mal publicada, mas reduz bastante o impacto de erro humano.

SSH seguro: chaves, usuários e acesso administrativo

O SSH costuma ser a porta mais atacada de uma VPS recém-criada. Bots varrem blocos inteiros de IPs procurando servidores com senha fraca, usuário root habilitado e versões antigas. A defesa começa com chaves, não com senhas longas. Gere uma chave moderna, como Ed25519, proteja com passphrase e copie a chave pública para o servidor. No computador local, o comando ssh-keygen -t ed25519 -C usuario@projeto cria um par adequado para a maioria dos casos. A chave privada fica na sua máquina. A VPS recebe apenas a chave pública em ~/.ssh/authorized_keys.

Desative senha e root remoto

Depois de criar um usuário administrativo e testar o acesso, edite /etc/ssh/sshd_config com cuidado. As diretivas mais comuns são:

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
MaxAuthTries 3
AllowUsers deploy

Em seguida, valide a configuração com sudo sshd -t antes de reiniciar o serviço. Se o comando não retornar erro, reinicie com sudo systemctl reload ssh ou sudo systemctl reload sshd, conforme a distribuição. Mantenha uma sessão conectada enquanto testa outra. Essa prática simples evita ficar trancado fora do servidor por erro de digitação. Em ambientes com mais de uma pessoa, crie um usuário por operador. Evite compartilhar o mesmo usuário deploy entre todos, porque isso dificulta auditoria e revogação.

Cuide do ciclo de vida das chaves

Chave SSH também envelhece. Quando alguém sai do time, perde notebook ou muda de função, remova a chave pública correspondente. Um arquivo authorized_keys com dez entradas sem dono conhecido vira risco silencioso. Em equipes pequenas, mantenha uma planilha simples ou repositório privado com o identificador de cada chave pública, dono, data de criação e servidores autorizados. Não armazene chaves privadas no repositório, nem em imagem Docker, nem em arquivo de configuração da aplicação.

Se você precisa de acesso administrativo frequente, use sudo com grupos bem definidos. O usuário da aplicação não deve ter permissão ampla. Um serviço web rodando como www-data, nodeapp ou appuser não precisa instalar pacotes ou editar firewall. Essa separação reduz danos se a aplicação for comprometida. Também ajuda em troubleshooting, porque processos, arquivos e logs ficam mais fáceis de associar a uma função. Segurança de SSH não é só trocar a porta 22 por outra. Porta alternativa diminui ruído nos logs, mas não substitui chaves, bloqueio de senha, usuários separados e revisão periódica.

Atualizações, fail2ban e redução da superfície de ataque

Atualização de segurança é uma das camadas mais negligenciadas em VPS pequenas. O servidor nasce limpo, recebe uma aplicação, funciona por meses e ninguém volta para aplicar correções. Quando aparece uma falha em OpenSSL, OpenSSH, glibc, kernel, Nginx ou biblioteca de linguagem, o tempo de exposição cresce sem alarde. Em distribuições baseadas em Debian e Ubuntu, comece com sudo apt update && sudo apt upgrade. Em produção, prefira uma rotina com janela programada, teste em staging e registro do que foi alterado.

Atualização automática sem perder controle

O pacote unattended-upgrades pode aplicar correções de segurança automaticamente. Ele é útil para VPS simples, desde que você acompanhe logs e reinicializações pendentes. Instale e configure com:

sudo apt install unattended-upgrades apt-listchanges
sudo dpkg-reconfigure unattended-upgrades
sudo unattended-upgrades --dry-run --debug

O modo automático reduz exposição, mas não elimina planejamento. Atualizações de kernel podem exigir reboot. Banco de dados, runtime de aplicação e painel administrativo podem ter impacto se forem atualizados sem teste. Em um e-commerce, SaaS ou API com clientes pagantes, use pelo menos dois ambientes: staging para validar e produção para aplicar em janela combinada. Em uma VPS simples com blog ou automação interna, atualizações automáticas de segurança costumam ser um bom equilíbrio, desde que exista backup e monitoramento.

Fail2ban contra tentativas repetidas

Fail2ban observa logs e cria bloqueios temporários quando detecta comportamento suspeito. O caso clássico é SSH com muitas tentativas falhas em poucos minutos. Instale com sudo apt install fail2ban e crie um arquivo local, por exemplo /etc/fail2ban/jail.local, para não editar o padrão do pacote. Uma configuração inicial pode usar bantime = 1h, findtime = 10m e maxretry = 5. Para SSH, habilite o jail sshd e confira com sudo fail2ban-client status sshd.

O ganho prático aparece nos logs. Em vez de milhares de tentativas repetidas do mesmo IP, o atacante é bloqueado cedo. Você também pode proteger Nginx, Apache, autenticação básica, painéis como phpMyAdmin e endpoints administrativos, desde que os filtros correspondam ao formato real dos logs. Não trate fail2ban como substituto de firewall ou autenticação forte. Ele é uma camada reativa, muito útil contra abuso repetitivo, mas não corrige senha fraca, aplicação vulnerável ou painel antigo exposto. A combinação certa é firewall restritivo, SSH por chave, pacotes atualizados, fail2ban e logs revisados.

Backups, snapshots e recuperação após incidente

Backup é parte do hardening porque segurança também envolve recuperação. Uma VPS pode ser comprometida, ter disco corrompido, sofrer erro humano ou perder dados por atualização mal executada. Se a única cópia está no mesmo disco, você não tem backup de verdade. Você tem uma duplicação vulnerável ao mesmo incidente. Para uma aplicação web comum, pense em três camadas: snapshot da VPS para recuperação rápida, backup de arquivos da aplicação e backup consistente do banco de dados. Cada camada resolve um problema diferente.

Backup não é só tirar cópia

Snapshot captura o estado do servidor em um ponto no tempo. É ótimo para voltar rápido depois de uma atualização quebrada, mas pode não ser suficiente para bancos em alta escrita se não houver consistência. Backup de banco deve usar ferramenta própria, como pg_dump para PostgreSQL ou mysqldump e soluções físicas adequadas para MySQL e MariaDB. Arquivos de upload, certificados, variáveis de ambiente, configurações de Nginx e scripts de deploy também precisam entrar no plano. Para um WordPress pequeno, por exemplo, banco de dados e wp-content/uploads são tão importantes quanto a imagem da máquina.

O destino precisa ficar fora da VPS. Pode ser storage de objetos compatível com S3, outro servidor, solução de backup do provedor ou ferramenta dedicada. Antes de contratar ou ativar qualquer recurso, confirme política de retenção, frequência, criptografia, região e custo. O artigo sobre VPS com backup automático aprofunda essa diferença entre backup automático, snapshot e restauração, um ponto que costuma gerar confusão em ambientes pequenos.

Teste de restauração precisa entrar na rotina

Uma regra prática: backup não testado é hipótese. A cada mês, restaure uma cópia em uma VPS temporária ou ambiente isolado. Verifique se a aplicação sobe, se o banco abre, se os arquivos de upload aparecem e se segredos não foram expostos em lugar indevido. Registre o tempo de restauração. Se o projeto aceita ficar fora por no máximo 2 horas, mas você leva 6 horas para reconstruir tudo, o plano não atende o negócio.

Também defina RPO e RTO, mesmo de forma simples. RPO é quanto dado você aceita perder, por exemplo 15 minutos, 1 hora ou 24 horas. RTO é quanto tempo você aceita levar para voltar. Uma automação interna pode tolerar backup diário e restauração manual. Um checkout de loja virtual normalmente exige intervalos menores e processo mais ensaiado. Segurança não termina em bloquear ataque. Ela inclui voltar ao ar com dados íntegros depois que algo dá errado.

Checklist técnico antes de colocar aplicações em produção

Antes de apontar o domínio, liberar tráfego real e divulgar a aplicação, faça uma checagem técnica em camadas. Comece pela rede. Rode ss -tulpn e confirme quais processos escutam em portas TCP e UDP. Em uma VPS web padrão, você deve ver Nginx ou Apache em 80 e 443, SSH na porta definida e, no máximo, serviços internos presos a 127.0.0.1 ou rede privada. Se Redis, PostgreSQL, MySQL, Elasticsearch ou painel administrativo aparecem em 0.0.0.0, pare e revise. Esses serviços raramente precisam ficar públicos.

Validação de rede e serviços

Teste o firewall de fora do servidor. Use outra máquina, uma conexão residencial ou ferramenta de varredura controlada para conferir portas abertas. Um comando como nmap -Pn seu-ip pode ajudar em ambiente autorizado. Não use varredura agressiva contra terceiros. Dentro da VPS, valide regras com sudo ufw status numbered, logs com sudo journalctl -u ssh --since today e serviços habilitados com systemctl list-unit-files --state=enabled. Desabilite o que não precisa iniciar com o boot.

Em seguida, olhe TLS e proxy reverso. Certificados Let’s Encrypt devem renovar automaticamente, geralmente via certbot.timer ou integração do painel. Confirme com systemctl list-timers e faça um teste de renovação com sudo certbot renew --dry-run quando usar Certbot. No Nginx, redirecione HTTP para HTTPS, limite tamanho de upload quando fizer sentido e evite expor arquivos sensíveis. Aplicações Node.js, Python, PHP-FPM e containers devem ficar atrás do proxy, não diretamente expostas na porta da aplicação.

Logs, alertas e auditoria simples

A última etapa é visibilidade. Configure alertas para CPU alta sustentada, RAM quase esgotada, disco acima de 80%, serviço parado e certificado perto de expirar. Ferramentas como Netdata, Uptime Kuma, Prometheus com node_exporter ou monitoramento do próprio provedor podem cumprir esse papel. O nível depende do projeto. Para um site institucional, alerta de uptime e disco pode bastar. Para uma API de produção, monitore latência, taxa de erro, filas, banco e logs de aplicação.

Guarde também um checklist de aceite. Ele deve incluir acesso SSH testado por pelo menos duas pessoas autorizadas, senha desativada, backup restaurado em teste recente, firewall revisado, atualizações aplicadas, fail2ban ativo, domínio com HTTPS, logs funcionando e plano de rollback. Parece burocrático, mas economiza horas em incidentes. Quando algo quebra às 2 da manhã, uma lista simples vale mais do que memória.

Tabela comparativa de abordagens de segurança

Nem toda VPS precisa da mesma arquitetura de proteção. Um ambiente de desenvolvimento pessoal, uma aplicação interna e uma API pública têm riscos diferentes. A tabela abaixo organiza abordagens comuns sem transformar segurança em pacote fechado. Use como ponto de partida e adapte ao seu tráfego, time, orçamento e tolerância a indisponibilidade.

Cenário	Portas públicas recomendadas	Controles mínimos	Backup e restauração	Observações práticas
Site institucional ou blog pequeno	80, 443 e SSH restrito	UFW, SSH por chave, senha desativada, atualizações de segurança	Backup diário de arquivos e banco, snapshot antes de mudanças	Boa opção para 1 a 2 vCPUs e 2 GB de RAM se o tráfego for moderado
API ou SaaS em estágio inicial	80, 443 e SSH via VPN ou IP autorizado	Firewall em nuvem e local, fail2ban, logs centralizados, usuário por operador	Banco com backup frequente, retenção de 7 a 30 dias, teste mensal	Considere 2 a 4 vCPUs, 4 a 8 GB de RAM e staging separado
E-commerce ou produção sensível	80, 443, administração fora da internet pública	WAF quando aplicável, hardening de SSH, monitoramento, alertas, política de patches	RPO e RTO definidos, restauração ensaiada, cópia externa criptografada	Separe banco, aplicação e cache quando o volume justificar
Automação com n8n, workers ou filas	443 e SSH restrito, sem expor banco ou Redis	Proxy reverso, autenticação forte, firewall, fail2ban, variáveis protegidas	Backup de banco, workflows e credenciais exportáveis com cuidado	Atenção a webhooks públicos e permissões de credenciais internas

Um detalhe que muda a decisão é a localização e o modelo do provedor. DigitalOcean, Vultr, Linode/Akamai, AWS Lightsail, Google Cloud, Azure, Oracle Cloud, Hetzner, Contabo, Hostinger, HostGator, Locaweb e LetsCloud oferecem combinações diferentes de regiões, painel, firewall, snapshots, rede privada e suporte. Esses recursos mudam com o tempo e precisam ser conferidos nas páginas oficiais antes de qualquer comparação de preço ou promessa operacional. Para o contexto brasileiro, provedores com região local ou boa conectividade podem ajudar na latência, mas isso não substitui hardening. Segurança de sistema continua dependendo de configuração, rotina e recuperação.

A tabela também ajuda a evitar excesso de ferramentas. Instalar WAF, IDS, agente de logs, antivírus, painel, Docker, banco, cache e monitoramento em uma VPS de 1 GB pode causar mais instabilidade do que proteção. Comece com o essencial e cresça por risco real. Se o servidor guarda dados sensíveis, credenciais de clientes ou pagamentos, aumente o rigor. Se é um ambiente de teste desligado fora do expediente, simplifique, mas não deixe SSH com senha e portas abertas sem necessidade.

Recomendações por perfil

Dev solo

Para uma pessoa desenvolvedora cuidando de um projeto próprio, o melhor caminho é padronizar um checklist repetível. Use uma imagem LTS recente, crie usuário com sudo, configure SSH por chave, aplique UFW com 80, 443 e SSH restrito, instale fail2ban e ative atualizações de segurança. Uma VPS com 1 a 2 vCPUs, 2 GB de RAM e 40 GB de SSD pode servir para blog, landing page, API pequena ou automação leve, desde que banco e aplicação não disputem recursos demais. O maior risco aqui costuma ser pressa. Antes de publicar, teste backup, documente comandos de deploy e confirme que nenhuma porta de banco ficou pública.

Time pequeno

Em um time de 2 a 8 pessoas, o foco muda para controle de acesso e rastreabilidade. Cada pessoa deve ter sua própria chave SSH e seu próprio usuário, mesmo que todos usem sudo. Defina quem pode alterar firewall, quem pode reiniciar serviços e quem recebe alertas. Use staging para testar atualizações e scripts de deploy. Para aplicações com clientes reais, considere 2 a 4 vCPUs, 4 a 8 GB de RAM e pelo menos 80 GB de disco, não como regra universal, mas como ponto de partida confortável para proxy, aplicação, banco leve e monitoramento. O time também precisa de rotina de revogação de acesso quando alguém sai do projeto.

Produção crítica

Para produção crítica, trate a VPS como parte de uma arquitetura, não como uma máquina isolada. SSH deve passar por VPN, bastion host ou allowlist de IP. Banco de dados não deve ficar público. Logs devem sair do servidor ou ser enviados para uma solução externa, porque invasores podem apagar rastros locais. Backups precisam de retenção, criptografia e restauração testada. Defina RPO e RTO por escrito. Em muitos casos, separar aplicação, banco, cache e workers em instâncias diferentes melhora operação e reduz impacto de falhas, mas exige mais disciplina. Antes de ampliar complexidade, garanta que o básico esteja impecável: firewall, patching, acesso, monitoramento e recuperação.