Como configurar VPS Ubuntu 24.04 do zero com segurança e performance

Configurar uma VPS Ubuntu 24.04 do zero requer seguir cinco etapas críticas: criar usuário não-root com sudo, desabilitar login root via SSH, configurar firewall UFW, habilitar atualizações automáticas de segurança e instalar fail2ban contra força bruta. Pular qualquer uma dessas etapas deixa o servidor exposto a bots que varrem portas SSH 24/7.

TL;DR: Ubuntu 24.04 em VPS exige hardening básico antes de rodar qualquer aplicação: usuário dedicado, SSH apenas por chave pública, firewall ativo e proteção anti-brute-force. O setup leva 20–30 minutos e evita 99% dos ataques automatizados.

A maioria dos ataques a servidores Linux acontece nas primeiras 48 horas após provisionamento — período em que bots descobrem IPs novos e testam credenciais padrão. Um servidor Ubuntu recém-criado com root habilitado recebe centenas de tentativas de login por hora.

Este guia detalha cada comando necessário para endurecer a VPS antes de subir aplicações. Os passos valem para VPS na Rollin Host (Frankfurt ou US-East) ou qualquer provedor que entregue Ubuntu 24.04 limpo com acesso root inicial.

Por que Ubuntu 24.04 em VPS?

Ubuntu 24.04 LTS (Noble Numbat) traz suporte estendido até 2029 e kernel 6.8, ideal para cargas de produção que exigem estabilidade previsível. A versão LTS recebe apenas patches de segurança e bugfixes críticos — sem surpresas em produção.

Vantagens técnicas da 24.04 para VPS:

• Suporte a cgroups v2 nativo, essencial para limitar recursos de containers e processos
• AppArmor ativo por padrão, reduzindo superfície de ataque de serviços expostos
• Repositórios com versões recentes de Nginx (1.24), PostgreSQL (16) e Python (3.12)
• Atualizações de segurança garantidas por 5 anos sem upgrade de major version

A escolha entre Ubuntu 22.04 e 24.04 depende do ciclo de vida da aplicação. Para projetos iniciados em 2026, a 24.04 oferece janela de suporte mais longa e base mais moderna para dependências.

Quem provisiona VPS para rodar automações em n8n ou agentes de IA precisa dessa base estável — migrar Ubuntu major version com aplicação em produção é operação de risco.

Acesso inicial e primeira atualização

Ao provisionar VPS na Rollin Host ou outro provedor, você recebe IP público e senha root temporária por e-mail. O primeiro login acontece via SSH:

ssh root@SEU_IP_AQUI

Confirme o fingerprint do servidor (aparece apenas na primeira conexão) e troque a senha root imediatamente:

passwd

Antes de qualquer configuração, atualize a lista de pacotes e aplique patches de segurança pendentes:

apt update && apt upgrade -y

Esse comando sincroniza os repositórios do Ubuntu e instala atualizações de kernel, bibliotecas e serviços. O servidor pode solicitar reinicialização se o kernel foi atualizado:

reboot

Aguarde 1–2 minutos e reconecte via SSH. A partir daqui, nunca mais use root diretamente para tarefas do dia a dia.

Criar usuário não-root com privilégios sudo

Rodar comandos como root é má prática — qualquer erro ou exploit executa com permissões totais. O padrão seguro é criar usuário dedicado e conceder sudo apenas quando necessário.

Crie o usuário (substitua deploy pelo nome desejado):

adduser deploy

Defina senha forte quando solicitado. Adicione o usuário ao grupo sudo para permitir elevação de privilégio:

usermod -aG sudo deploy

Teste a configuração trocando para o novo usuário:

su - deploy
sudo apt update

Digite a senha do usuário deploy quando o sudo pedir. Se o comando executar sem erro, o sudo está configurado corretamente.

Por que isso importa: logs do sistema registram qual usuário executou cada comando sudo. Em ambientes com múltiplos administradores, rastreabilidade é requisito básico de auditoria.

A partir daqui, todos os comandos devem ser executados como deploy (ou o nome escolhido), usando sudo apenas quando necessário.

Configurar autenticação SSH por chave pública

Senha SSH é vetor de ataque: bots testam milhares de combinações por minuto. Autenticação por chave pública elimina esse risco — sem a chave privada correta, login é matematicamente inviável.

No seu computador local (Linux/macOS/WSL), gere o par de chaves:

ssh-keygen -t ed25519 -C "seu-email@exemplo.com"

Pressione Enter para salvar em ~/.ssh/id_ed25519. Defina passphrase para proteger a chave privada (recomendado).

Copie a chave pública para o servidor:

ssh-copy-id deploy@SEU_IP_AQUI

Digite a senha do usuário deploy uma última vez. O comando cria ~/.ssh/authorized_keys no servidor e adiciona sua chave pública.

Teste o login sem senha:

ssh deploy@SEU_IP_AQUI

Se conectou direto, a chave funciona. Agora desabilite autenticação por senha editando a configuração SSH:

sudo nano /etc/ssh/sshd_config

Localize e ajuste as seguintes linhas (remova # se estiverem comentadas):

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes

Salve (Ctrl+O, Enter) e saia (Ctrl+X). Reinicie o SSH:

sudo systemctl restart sshd

Atenção crítica: antes de fechar a sessão SSH atual, abra uma segunda conexão em outro terminal e teste o login com chave. Se algo falhar, você ainda tem a primeira sessão root aberta para corrigir. Nunca feche a última sessão até confirmar que o novo método funciona.

Configurar firewall UFW

Ubuntu 24.04 vem com ufw (Uncomplicated Firewall) instalado mas inativo. Firewall bloqueia todo tráfego não autorizado — essencial quando a VPS roda serviços como banco de dados ou APIs internas.

Antes de ativar o firewall, libere SSH para não perder o acesso:

sudo ufw allow OpenSSH

Se roda aplicação web, libere HTTP e HTTPS:

sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

Para aplicações específicas (PostgreSQL, Redis, etc.), libere apenas para IPs confiáveis:

sudo ufw allow from IP_CONFIAVEL to any port 5432

Ative o firewall:

sudo ufw enable

Confirme com y. Verifique as regras ativas:

sudo ufw status verbose

Política padrão: UFW bloqueia tudo que não está explicitamente liberado. Essa abordagem "deny by default" é correta — você adiciona exceções conforme provisiona serviços.

Quem hospeda ferramentas de automação com instalação em 1 clique precisa liberar portas específicas conforme a stack (ex: 8080 para n8n, 3000 para Typebot).

Habilitar atualizações automáticas de segurança

Patches de segurança saem semanalmente. Aplicar manualmente é inviável — atualizações automáticas resolvem 90% das vulnerabilidades críticas sem intervenção.

Instale o pacote unattended-upgrades:

sudo apt install unattended-upgrades -y

Configure para aplicar apenas atualizações de segurança:

sudo dpkg-reconfigure -plow unattended-upgrades

Escolha Yes quando perguntar se deseja habilitar. Edite o arquivo de configuração:

sudo nano /etc/apt/apt.conf.d/50unattended-upgrades

Certifique-se de que as linhas abaixo estão descomentadas (sem // no início):

"${distro_id}:${distro_codename}-security";
Unattended-Upgrade::Automatic-Reboot "false";

A diretiva Automatic-Reboot "false" impede reinicializações surpresa. Para aplicações críticas, agende janelas de manutenção e reinicie manualmente após kernels novos.

Verifique se o serviço está ativo:

sudo systemctl status unattended-upgrades

Trade-off honesto: atualizações automáticas podem quebrar aplicações que dependem de versões específicas de bibliotecas. Para VPS de produção rodando stacks complexas, considere testar atualizações em staging antes de aplicar.

Instalar e configurar Fail2ban

Fail2ban monitora logs de autenticação e bane IPs que tentam força bruta. Após 5 tentativas falhas de SSH em 10 minutos, o IP fica bloqueado por 10 minutos (configuração padrão).

Instale o pacote:

sudo apt install fail2ban -y

Crie arquivo de configuração local (nunca edite o .conf original):

sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
sudo nano /etc/fail2ban/jail.local

Localize a seção [sshd] e ajuste:

[sshd]
enabled = true
port = ssh
logpath = /var/log/auth.log
maxretry = 5
bantime = 600
findtime = 600

Salve e reinicie o Fail2ban:

sudo systemctl restart fail2ban
sudo systemctl enable fail2ban

Verifique o status:

sudo fail2ban-client status sshd

O output mostra IPs atualmente banidos. Após alguns dias, a lista cresce — evidência de que bots estão tentando e sendo bloqueados.

Para desbanir IP manualmente (útil se você mesmo foi bloqueado por erro):

sudo fail2ban-client set sshd unbanip SEU_IP

Configurações adicionais de hardening

Além dos cinco passos obrigatórios acima, recomendamos ajustes complementares para VPS de produção:

Desabilitar IPv6 se não usar: muitos ataques exploram IPv6 mal configurado. Se a aplicação não precisa, desabilite editando /etc/sysctl.conf:

net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1

Aplique:

sudo sysctl -p

Limitar uso de sudo com timeout: edite /etc/sudoers via visudo:

sudo visudo

Adicione:

Defaults timestamp_timeout=5

Sudo pedirá senha novamente após 5 minutos de inatividade, reduzindo janela de exploração se alguém deixar sessão aberta.

Instalar monitoramento básico: htop para inspeção visual de processos e netdata para métricas em tempo real:

sudo apt install htop -y

Para servidores rodando aplicações de IA que demandam GPU, monitoramento de temperatura e uso de VRAM é crítico — mas isso requer stack específica (nvidia-smi, Prometheus).

Principais aprendizados

• Usuário não-root com sudo é mandatório — nunca opere como root diretamente
• SSH por chave pública elimina 99% dos ataques de força bruta; desabilite senha
• Firewall UFW ativo com política "deny by default" e liberação explícita de portas
• Atualizações automáticas de segurança via unattended-upgrades mantêm o sistema patcheado
• Fail2ban bane IPs que tentam força bruta, reduzindo carga e ruído em logs
• Teste cada mudança em sessão SSH paralela antes de fechar a sessão original — evita lockout

Próximos passos

Com a VPS endurecida, a próxima etapa é provisionar a stack da aplicação. Quem usa Ubuntu para rodar automações pode instalar Docker, Nginx como reverse proxy e configurar SSL com Let's Encrypt.

Para quem precisa subir ferramentas de IA ou automação rapidamente, a Rollin Host oferece painel de aplicativos com instalação em 1 clique — n8n, Typebot, Flowise e outras ferramentas já vêm com Nginx e SSL configurados, poupando 2–3 horas de setup manual.

A configuração descrita acima vale para qualquer VPS Ubuntu 24.04, seja em Frankfurt (Alemanha) ou US-East (EUA). A latência de rede varia conforme a localização dos usuários finais, mas a segurança base é idêntica.

Se preferir VPS já otimizada para workloads de automação, conheça as VPS para n8n com Evolution API e Traefik pré-configurados. Para cargas de IA que exigem CPU dedicada, os planos de Servidor IA Cloud entregam Ollama e Open WebUI prontos para uso.

Perguntas frequentes

Preciso reiniciar a VPS após cada etapa de configuração?

Não. Apenas reinicie após atualizar o kernel (apt upgrade avisa se necessário) ou quando explicitamente indicado. Mudanças em SSH, firewall e Fail2ban aplicam sem reboot.

Posso usar senha SSH se for muito complexa?

Tecnicamente sim, mas não recomendamos. Bots testam milhões de combinações usando rainbow tables e leaks de senhas. Chave pública SSH (ed25519 ou RSA 4096 bits) é ordens de magnitude mais segura.

Fail2ban bloqueia meu próprio IP se eu errar a senha?

Sim, se ultrapassar maxretry (padrão 5 tentativas). O bloqueio dura 10 minutos (configuração padrão). Se acontecer, conecte por IP alternativo ou via console do provedor e desbloqueie manualmente.

UFW interfere com Docker?

Docker manipula iptables diretamente e pode sobrescrever regras do UFW. Se rodar containers, configure UFW antes de instalar Docker e use ufw allow explicitamente para portas de containers expostos.

Atualizações automáticas podem quebrar minha aplicação?

Apenas atualizações de segurança (-security) aplicam automaticamente — essas raramente quebram APIs. Atualizações de feature (-updates) não aplicam. Para aplicações sensíveis, teste em staging antes de habilitar unattended-upgrades em produção.

Como verificar se meu servidor sofreu tentativa de invasão?

Consulte o log de autenticação: sudo grep 'Failed password' /var/log/auth.log | tail -20. Se houver dezenas de IPs tentando login, o Fail2ban já deve ter banido a maioria. Use sudo fail2ban-client status sshd para ver IPs bloqueados.