Como proteger uma VPS Linux: checklist de segurança para servidor em produção

Uma VPS Linux recém-instalada não está automaticamente pronta para produção. SSH exposto com senhas fracas, serviços e portas sem necessidade e pacotes desatualizados ampliam a superfície de ataque. Colocar uma aplicação no ar é apenas uma parte do trabalho: também é preciso controlar quem entra no servidor e o que fica acessível pela rede.

Containers não eliminam essa responsabilidade. Uma porta publicada por engano ou um segredo vazado pode expor dados; sem backup recuperável e monitoramento, falhas e tentativas de força bruta podem passar despercebidas. Este checklist organiza medidas práticas de hardening Linux para reduzir riscos e preparar a recuperação. A segurança exige manutenção contínua; nenhuma configuração elimina todos os riscos.

1. Atualize o sistema antes de colocar a VPS em produção

Em Ubuntu e Debian, confira se a versão da distribuição ainda recebe suporte e aplique as atualizações de segurança dos repositórios oficiais. Revise pacotes, bibliotecas e kernel, não apenas a aplicação. Atualizar o kernel instalado pode exigir reinicialização para que o servidor passe a executar a versão corrigida; outros componentes podem precisar de reinício do serviço.

Antes de atualizar em produção, verifique compatibilidade com banco, runtime e aplicações, confirme um backup recuperável e defina uma janela de manutenção. Atualizações automáticas de segurança podem ajudar, mas o escopo, os reinícios e os alertas devem acompanhar o risco do ambiente. Não deixe mudanças maiores de versão acontecerem sem planejamento nem trate a instalação de atualizações como uma tarefa que nunca mais precisa ser feita.

2. Não use root diretamente para tudo

Crie contas individuais para administração e use sudo nas operações que realmente exigem elevação. Isso ajuda a identificar responsáveis e evita trabalhar o tempo inteiro em uma sessão root. Porém, uma conta autorizada a executar qualquer comando com sudo continua tendo poder administrativo total: a redução de privilégio depende das permissões concedidas, não apenas do nome do usuário.

Separe usuários de pessoas, aplicações e rotinas de backup. Conceda acesso somente aos arquivos e comandos necessários, revise grupos e remova contas que não são mais usadas. Antes de restringir root, teste a conta administrativa e sua elevação de privilégio, preservando uma forma de recuperação pelo console do provedor.

3. Proteja o SSH

Prefira autenticação por chaves e proteja a chave privada com permissões adequadas e uma frase-senha, sem compartilhá-la entre administradores. Para desabilitar autenticação por senha ou login direto de root, primeiro confirme uma segunda conexão com o usuário e a chave que continuarão permitidos, teste sudo e verifique o acesso ao console. Mantenha a sessão atual aberta durante a mudança e teste novamente após aplicar a configuração.

A validação com sshd -t, executada com os privilégios necessários, verifica a sintaxe e a validade básica da configuração, mas não comprova que seu usuário conseguirá autenticar. Revise também configurações incluídas e regras condicionais. Desabilitar PasswordAuthentication sozinho pode não impedir senha via keyboard-interactive/PAM: confira KbdInteractiveAuthentication e AuthenticationMethods, preservando MFA quando utilizado, e teste que os métodos proibidos realmente são recusados. Limite usuários ou grupos autorizados, tentativas de autenticação, tempo de login e sessões conforme a operação, entendendo que keepalives não são um limite de inatividade do shell. Acompanhe os logs para confirmar o comportamento real.

Quando viável, restrinja a origem do SSH a uma VPN ou a endereços administrativos conhecidos, considerando acessos de emergência. Trocar a porta pode reduzir o ruído de bots que procuram a porta padrão, mas não substitui autenticação forte, atualizações ou controle de acesso.

4. Configure um firewall

Use UFW, nftables ou iptables conforme a distribuição e a arquitetura, evitando gerenciar regras sobrepostas sem entender sua interação. Adote bloqueio de entrada por padrão e libere apenas os fluxos necessários; a política de saída depende das aplicações, integrações, DNS e rotinas de atualização. Portas 22, 80 e 443 são exemplos comuns de SSH e web, não uma lista que toda VPS deve abrir.

Revise também o firewall do provedor e as regras para IPv4 e IPv6. Antes de ativar ou restringir regras, autorize o caminho administrativo correto, valide uma nova conexão e mantenha acesso ao console. Não bloqueie a única entrada disponível para depois descobrir se a configuração funciona.

Portas publicadas pelo Docker podem contornar regras de entrada do UFW. Confira o encaminhamento de tráfego e os mecanismos de filtragem compatíveis com o backend de firewall utilizado pelo Docker. Faça testes de alcance a partir de outra máquina, nos endereços públicos IPv4 e IPv6 disponíveis: a regra escrita não é prova de que a porta está inacessível.

5. Use Fail2ban ou mecanismo equivalente

Fail2ban pode identificar falhas repetidas de autenticação nos logs e bloquear temporariamente a origem. Além do SSH, serviços web podem usar essa camada quando registram falhas identificáveis e há filtros adequados. Configure jails para os serviços existentes, apontando para o arquivo ou journal correto e usando filtros compatíveis com o formato dos registros. Ajuste quantidade de tentativas, intervalo de observação e duração do bloqueio à rotina do servidor.

Teste a detecção, a aplicação e a remoção do bloqueio sem comprometer seu acesso, inclusive em IPv6 quando utilizado. Revise falsos positivos e exceções com cuidado. Atrás de um proxy, confirme que os logs identificam o IP real do cliente de forma confiável e que o mecanismo de bloqueio atua na camada certa, em vez de bloquear o proxy inteiro. Fail2ban reduz tentativas repetidas, mas não substitui autenticação forte nem impede o uso de credenciais já vazadas.

6. Feche serviços e portas desnecessárias

Faça um inventário antes de alterar serviços. ss -lntup mostra sockets TCP em escuta e sockets UDP, incluindo endereços e portas; a identificação completa dos processos pode exigir privilégios. systemctl list-units --type=service --state=running lista serviços em execução em sistemas com systemd, e docker ps mostra containers ativos e suas portas publicadas. São comandos de inspeção, não de remoção.

Relacione cada item à aplicação responsável e verifique se ele escuta em loopback, rede privada ou interfaces públicas. Painéis de teste, bancos antigos e serviços de uma aplicação abandonada não devem continuar expostos por inércia. Só desative ou remova o que tiver dependências verificadas, com mudança planejada; complemente o inventário com testes externos, pois sockets locais não mostram sozinhos o efeito do firewall, NAT ou das regras do Docker.

7. Proteja bancos de dados

Mantenha PostgreSQL, MySQL/MariaDB e outros bancos acessíveis por loopback, rede privada ou VPN conforme a localização das aplicações. Em containers, uma rede interna dedicada pode ser mais apropriada que publicar a porta no host. Portas como 5432 e 3306 não precisam ficar públicas quando só aplicações internas usam o banco; combine endereço de escuta, regras de acesso do banco e firewall.

Exija autenticação com credenciais fortes, crie usuários separados por aplicação e limite permissões às operações necessárias. Não use a conta administrativa do banco na conexão cotidiana da aplicação. Quando o tráfego cruza a rede, configure TLS com validação do certificado conforme o cliente e o banco. Mantenha versões suportadas e backups consistentes, protegendo também credenciais e dados das cópias.

8. Segurança em Docker

Use imagens de fontes confiáveis, identifique as versões implantadas e estabeleça uma rotina para atualizar, testar e recriar containers com correções. Fixar uma versão ou digest melhora a previsibilidade, mas não atualiza a imagem automaticamente. Revise redes internas, portas publicadas, volumes e permissões de arquivos, alinhando UID e GID com o usuário que executa o processo.

Evite containers privilegiados, capabilities desnecessárias e montagens amplas do filesystem do host. Execute a aplicação sem root quando ela permitir, verificando acesso aos volumes. O socket do Docker dá acesso a operações com poder sobre o host: montar esse socket com :ro não torna a API somente leitura e não é uma proteção suficiente. Não o disponibilize a aplicações que não precisam administrar containers.

Variáveis de ambiente não são um cofre de segredos: podem aparecer em inspeções e ferramentas de diagnóstico para quem tem acesso suficiente. Secrets do Docker Compose baseados em arquivo permitem entregar o conteúdo montado ao container, mas não criptografam sozinhos o arquivo de origem. Proteja armazenamento, permissões, acesso ao daemon e o processo de entrega das credenciais, sem incluí-las na imagem ou no repositório.

9. Proteja Nginx, Traefik e proxies reversos

Configure HTTPS com certificados válidos e acompanhe a renovação automática. Redirecione HTTP para HTTPS nas rotas públicas apropriadas, preservando os fluxos necessários à validação de certificados. A porta 443 costuma atender o tráfego HTTPS; a porta 80 pode ser necessária para redirecionamento ou validação de certificados por HTTP, dependendo do método escolhido. Não abra portas extras do proxy ou do backend sem necessidade, e mantenha dashboards administrativos autenticados e, preferencialmente, restritos por VPN ou rede de gestão.

Revise headers de segurança conforme a aplicação. Ative HSTS somente depois de confirmar HTTPS e avaliar o impacto nos subdomínios; includeSubDomains e preload exigem cuidado adicional, pois podem afetar serviços que ainda dependem de HTTP e dificultar a reversão. Teste CSP com as origens realmente usadas pela aplicação, podendo começar em modo de relatório, em vez de copiar uma política que quebra scripts, fontes ou integrações.

Aplique limites de requisição onde fizer sentido, especialmente em login e endpoints sensíveis. Se houver outro proxy ou CDN à frente, aceite headers de IP encaminhado somente de proxies conhecidos e efetivamente autorizados; confiar em qualquer origem permite falsificar a identidade usada em logs e limites. Confirme também que um acesso direto à origem não contorna a restrição pretendida.

10. Mantenha backups fora do próprio servidor

Uma cópia no disco da VPS pode desaparecer junto com o servidor ou ser alterada por quem comprometer o host. Mantenha backups externos de arquivos, configurações, volumes persistentes e bancos. Snapshots ajudam em alguns cenários, mas não garantem uma cópia independente nem consistência do banco em execução; use procedimentos compatíveis com o banco para obter dados restauráveis.

Proteja as cópias com criptografia, controle de acesso e retenção, mantendo as chaves disponíveis por um caminho seguro de recuperação. Quando possível, separe as permissões de envio das permissões de exclusão dos backups. Defina RPO, a perda máxima de dados aceitável em tempo, e RTO, o tempo-alvo para recuperar o serviço. Um backup que nunca foi testado pode não ser recuperável. Teste a restauração em ambiente separado, incluindo dados e aplicação: uma rotina que termina sem erro não comprova que o negócio consegue voltar a operar.

11. Configure monitoramento

Acompanhe CPU, memória, disco, inodes, carga e estado dos serviços, além da disponibilidade das aplicações por uma verificação externa. Inclua validade de certificados SSL, falhas relevantes nos logs e execução dos backups, observando a idade da última cópia bem-sucedida. Para investigar pressão de recursos, o checklist para servidor Linux lento ajuda a organizar o diagnóstico.

Envie alertas para um canal que não dependa exclusivamente da mesma VPS. Se o host cair, um monitor hospedado apenas nele pode deixar de avisar. Defina responsáveis e limites úteis, teste a entrega dos alertas e revise ruídos recorrentes. Segurança também depende de detectar comportamento anormal e indisponibilidade rapidamente. Monitoramento precisa gerar uma ação possível, não apenas acumular gráficos ou mensagens ignoradas.

12. Revise logs e tentativas de acesso

Consulte os registros de autenticação, SSH, sudo, Nginx ou Traefik, aplicações e Docker. Em algumas instalações Ubuntu e Debian, a autenticação aparece em /var/log/auth.log; em outras, consulte o journal e a unidade SSH correspondente à distribuição. Compare horários, usuários, origens e mudanças recentes para distinguir falhas legítimas, tentativas de força bruta e acessos inesperados.

Configure rotação e retenção, incluindo os logs dos containers, para não esgotar o disco. Restrinja quem pode ler ou alterar registros e considere uma cópia centralizada fora do host para eventos importantes. Logs podem conter dados pessoais, tokens e informações de clientes: evite registrar segredos, limite a retenção à necessidade e remova dados sensíveis antes de compartilhar trechos para diagnóstico.

13. Proteja credenciais e variáveis de ambiente

Proteja arquivos .env, tokens, API keys e senhas de banco. Nunca versione arquivos com segredos nem exponha credenciais em bundles de frontend, camadas de imagens, mensagens de erro ou logs. Variáveis incorporadas ao código que roda no navegador são públicas, mesmo que tenham vindo de um arquivo de ambiente. Restrinja permissões de arquivos e acesso aos painéis, pipelines e backups que carregam credenciais; use um gerenciador de segredos quando a operação justificar.

Separe credenciais por aplicação e ambiente, limite seus privilégios e defina rotação compatível com as dependências. Em caso de exposição ou suspeita de vazamento, revogue ou substitua o segredo e investigue seu uso. Apagar o arquivo da versão atual do repositório não invalida a credencial nem remove cópias do histórico, de imagens ou de logs antigos.

14. Faça revisão periódica da VPS

Defina uma frequência e um responsável para revisar usuários, chaves SSH, versões do sistema e das aplicações, portas, containers e imagens. Confira backups e testes de restauração, certificados, alertas e logs. Faça uma revisão adicional após deploys importantes, mudanças de equipe ou de rede; uma configuração adequada hoje pode deixar de ser suficiente com novas dependências.

Retire aplicações abandonadas, acessos de antigos colaboradores e secrets sem uso depois de verificar suas dependências. Registre mudanças e pendências para que a próxima revisão não comece do zero. Se a distribuição saiu de suporte ou o ambiente precisa ser reorganizado, planeje a transição com o serviço de migração de servidores e o guia de migração de VPS com planejamento da indisponibilidade, em vez de improvisar uma troca em produção.

Checklist de segurança para VPS Linux

Use esta lista como roteiro de verificação, não como confirmação automática. Os quadrados estão vazios: cada item depende de evidência no seu ambiente, e exceções devem ter justificativa e responsável.

• Sistema atualizado
• Usuário administrativo sem uso direto de root
• SSH com autenticação forte
• Login root direto revisado/desabilitado quando possível
• Firewall ativo
• Apenas portas necessárias abertas
• Fail2ban ou proteção equivalente
• Bancos não expostos desnecessariamente
• Docker revisado
• Containers sem privilégios desnecessários
• Proxy reverso usando HTTPS
• Painéis administrativos protegidos
• Backups externos configurados
• Restore testado
• Monitoramento ativo
• Alertas funcionando
• Logs sendo revisados
• Credenciais protegidas
• Atualizações e revisão periódica definidas

Não quer administrar a segurança do servidor sozinho?

A Jupiter TI atua com Linux e VPS, hardening, firewall, Docker, Nginx, Traefik, backups, monitoramento, atualizações, migrações e gestão contínua. O trabalho parte das aplicações, dos acessos e das condições reais de manutenção para definir prioridades e mudanças que façam sentido no ambiente.

Conheça o suporte para servidores Linux e os serviços da Jupiter TI. Entre em contato para apresentar sua infraestrutura e conversar sobre o apoio necessário, seja na configuração inicial ou na administração ao longo do tempo.