Segurança de VPS do zero: chaves SSH, firewall e Fail2ban

Uma VPS nova não pode ser considerada protegida logo após a instalação do Ubuntu. Antes mesmo de configurar o acesso, o servidor já fica visível para scanners: eles tentam descobrir senhas SSH, procuram painéis expostos e verificam vulnerabilidades comuns. Neste guia, vamos abordar a proteção básica de uma VPS do zero: criar um usuário separado, configurar o acesso por chave SSH, limitar as portas de rede com UFW e adicionar o Fail2ban. Todas as etapas são adequadas para o Ubuntu 22.04 e 24.04, desde que os comandos sejam executados por um usuário com permissões de sudo.

Antes da configuração: liste as portas

Não abra portas “por precaução”. Para um servidor web comum, são necessárias:

• 22/tcp — SSH; de preferência, limite o acesso por IP ou transfira-o para outra porta apenas como medida adicional;
• 80/tcp — HTTP, normalmente necessário para redirecionar para HTTPS e verificar o certificado;
• 443/tcp — HTTPS.

Uma porta de aplicação como 3000, 8080 ou 9000 não deve ficar acessível pela internet se houver um Nginx ou Caddy na frente dela. Vincule a aplicação a 127.0.0.1 ou permita a porta apenas na rede interna. Primeiro, descubra o que está escutando no servidor:

sudo ss -tulpn

Depois de instalar o Docker, verifique separadamente as regras do iptables: a publicação -p 3000:3000 pode abrir uma porta contornando a configuração esperada. Para um serviço público, é mais seguro usar um proxy HTTPS e ocultar a porta interna.

Etapa 1. Atualize o sistema e crie um administrador

Conecte-se à VPS usando a conta fornecida e instale as atualizações:

sudo apt update
sudo apt full-upgrade -y
sudo apt install -y ufw fail2ban unattended-upgrades

Crie um usuário pessoal. Substitua alex pelo seu nome:

sudo adduser alex
sudo usermod -aG sudo alex

Não remova o acesso inicial antes de testar a nova conta em uma janela separada do terminal. Esta é uma regra importante: é mais fácil corrigir um erro no SSH enquanto a sessão atual ainda está aberta.

Etapa 2. Crie uma chave SSH e instale-a no servidor

No seu computador com Linux, macOS ou Windows PowerShell, execute:

ssh-keygen -t ed25519 -C "alex@my-computer"

Pressione Enter para salvar a chave no arquivo padrão e defina uma passphrase. A chave privada não deve ser enviada em chats, colocada em um repositório ou copiada para a VPS. No servidor, você precisa transferir apenas o arquivo com a extensão .pub:

ssh-copy-id alex@SERVER_IP

Se ssh-copy-id não estiver disponível, abra a chave pública com o comando Get-Content $env:USERPROFILE\.ssh\id_ed25519.pub no PowerShell e depois adicione-a ao servidor:

sudo install -d -m 700 -o alex -g alex /home/alex/.ssh
sudo nano /home/alex/.ssh/authorized_keys
sudo chown alex:alex /home/alex/.ssh/authorized_keys
sudo chmod 600 /home/alex/.ssh/authorized_keys

Cole a chave em uma única linha e teste o acesso antes de desativar as senhas:

ssh alex@SERVER_IP
sudo whoami

O resultado esperado do último comando é root. Se o cliente SSH não encontrar a chave, indique-a explicitamente: ssh -i ~/.ssh/id_ed25519 alex@SERVER_IP.

Etapa 3. Bloqueie o root e o acesso por senha

Faça uma cópia de segurança da configuração do SSH:

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak
sudo nano /etc/ssh/sshd_config

Verifique se o arquivo contém estes parâmetros:

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
KbdInteractiveAuthentication no
MaxAuthTries 3

No Ubuntu, as configurações também podem estar em /etc/ssh/sshd_config.d/*.conf, portanto verifique a configuração final:

sudo sshd -t
sudo sshd -T | grep -E 'permitrootlogin|passwordauthentication|pubkeyauthentication|maxauthtries'

Se sshd -t mostrar um erro, não reinicie o serviço até corrigir a sintaxe. Depois de uma verificação bem-sucedida, aplique as configurações:

sudo systemctl reload ssh

Mantenha a conexão SSH antiga aberta e, em uma nova janela, teste o acesso usando a chave. Desativar as senhas sem ter verificado a chave é a forma mais comum de perder o acesso ao servidor.

Etapa 4. Configure o UFW sem bloquear o SSH

O UFW é uma interface prática para as regras de rede do Linux. Primeiro, defina valores padrão seguros e depois permita o SSH e as portas web:

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp comment 'SSH'
sudo ufw allow 80/tcp comment 'HTTP'
sudo ufw allow 443/tcp comment 'HTTPS'
sudo ufw enable

Confirme a ativação somente depois de adicionar a regra do SSH. Veja o resultado:

sudo ufw status verbose
sudo ufw status numbered

Para um IP de escritório fixo, você pode limitar o SSH a esse endereço:

sudo ufw delete allow 22/tcp
sudo ufw allow from YOUR.PUBLIC.IP to any port 22 proto tcp comment 'SSH office'

Use esta opção somente se tiver um IP permanente e acesso ao console do provedor: se o endereço mudar, você poderá bloquear o próprio acesso.

Como abrir temporariamente a porta de uma aplicação

Se precisar verificar o serviço diretamente, crie uma regra com a origem limitada:

sudo ufw allow from YOUR.PUBLIC.IP to any port 8080 proto tcp

Depois do teste, remova-a usando o número exibido por ufw status numbered:

sudo ufw delete RULE_NUMBER

Não use sudo ufw allow 1:65535/tcp: uma regra assim transforma o firewall em mera formalidade.

Etapa 5. Ative o Fail2ban para SSH

O Fail2ban analisa os logs e adiciona uma regra de bloqueio temporário depois de várias tentativas de acesso malsucedidas. Ele não substitui a chave SSH nem o firewall, mas reduz o ruído causado por tentativas automáticas.

Crie uma configuração local para que uma atualização do pacote não substitua suas configurações:

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

Na seção [DEFAULT], defina valores razoáveis:

[DEFAULT]
bantime = 1h
findtime = 10m
maxretry = 5
backend = systemd
banaction = ufw

[sshd]
enabled = true
port = 22

Inicie o serviço e verifique o jail:

sudo systemctl enable --now fail2ban
sudo fail2ban-client status
sudo fail2ban-client status sshd

Na saída de sshd, observe o número de tentativas malsucedidas e os endereços bloqueados. Não adicione seu próprio IP à lista de bloqueio. Para uma exceção permanente, use o parâmetro ignoreip = 127.0.0.1/8 YOUR.PUBLIC.IP em [DEFAULT].

Etapa 6. Ative as atualizações automáticas

As atualizações automáticas são úteis para pacotes de segurança, mas ainda é necessário controlar a reinicialização do kernel:

sudo dpkg-reconfigure -plow unattended-upgrades
sudo systemctl status unattended-upgrades

Uma vez por semana, verifique se é necessário reiniciar:

test -f /var/run/reboot-required && echo 'Требуется перезапуск'

Antes de reiniciar manualmente, confirme que você tem uma chave funcional e acesso ao console da VPS. Depois da reinicialização, verifique os serviços da aplicação, o Nginx, o UFW e o Fail2ban.

Etapa 7. Verifique o resultado externamente

Faça a verificação a partir de outro computador, e não apenas pelo conteúdo dos arquivos de configuração:

ssh -o PreferredAuthentications=password -o PubkeyAuthentication=no alex@SERVER_IP

O comando deve terminar com uma recusa. O acesso funcional por chave deve ser testado separadamente:

ssh -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519 alex@SERVER_IP

Na VPS, verifique os endereços em escuta e as regras:

sudo ss -lntup
sudo ufw status numbered
sudo fail2ban-client status sshd

A porta da aplicação deve escutar em 127.0.0.1 se não tiver sido destinada ao acesso direto. A partir de um host externo, você pode usar nmap SERVER_IP, mas faça o scan somente do seu próprio servidor: verificar uma infraestrutura de terceiros sem autorização pode violar a lei e as regras do provedor.

Backups e recuperação

A proteção do SSH não evita a exclusão de dados, um erro do administrador ou o comprometimento da aplicação. Mantenha cópias do banco de dados, das configurações e dos arquivos dos usuários separadas da VPS. O esquema mínimo é uma cópia diária, várias versões dos dias anteriores e uma verificação periódica da restauração.

Não grave senhas e tokens em scripts expostos. Em caso de vazamento, revogue o segredo imediatamente e crie um novo.

Como escolher uma VPS para um projeto seguro

A segurança começa pelo controle da infraestrutura. Em uma VPS, você pode escolher o sistema operacional, as regras do firewall, o método de acesso, o backup e a localização dos serviços. Para um site ou uma API de pequeno porte, uma rede estável, SSD e um console de recuperação são mais importantes do que um excesso de núcleos virtuais.

Ao iniciar um projeto em uma VPS da tropic.host, defina antecipadamente seus pontos de entrada públicos: na maioria dos casos, SSH, HTTP e HTTPS são suficientes. Mantenha o banco de dados e os painéis de controle no ambiente interno. Para um projeto em crescimento, VPS separadas para a aplicação, o banco de dados e o monitoramento ajudam a dividir as zonas de falha.

Erros comuns

• Desativar a senha antes de verificar o acesso por chave. Mantenha a sessão atual e teste o novo acesso separadamente.
• Deixar 22/tcp aberto para o mundo todo quando seria possível permiti-lo somente a endereços confiáveis.
• Publicar portas do Docker diretamente. Primeiro, verifique as regras do Docker e do UFW.
• Instalar o Fail2ban e nunca mais consultar os logs. Depois das alterações, verifique journalctl -u ssh e o estado do jail.

Conclusão

A proteção básica de uma VPS leva pouco tempo quando executada na ordem correta: criar um usuário separado, instalar uma chave SSH, verificar o acesso, bloquear o root e as senhas, ativar o UFW, configurar o Fail2ban e as atualizações automáticas. Depois, adicione backups, logs e monitoramento externo.

Essas etapas não tornam o servidor invulnerável, mas eliminam os erros mais comuns da configuração inicial. Em seguida, adapte o perfil ao aplicativo específico: atualize as dependências, limite as permissões dos serviços, proteja os painéis administrativos e verifique regularmente as portas abertas.

FAQ

É necessário alterar a porta padrão do SSH?

Não necessariamente. Mudar a porta reduz o ruído gerado por automações, mas não substitui as chaves, a desativação das senhas, o UFW e o Fail2ban. Se alterar a porta, atualize a regra do firewall e o parâmetro port no jail do Fail2ban.

O que fazer se eu perder o acesso depois de configurar o UFW?

Use o console web ou o console de recuperação do provedor e verifique a regra do SSH e a configuração do sshd. Não encerre a sessão antiga e funcional enquanto o novo acesso não tiver sido confirmado.

O Fail2ban é suficiente para proteger o SSH?

Não. O Fail2ban reage a erros de acesso que já ocorreram. A base da proteção deve ser formada por chaves SSH, autorização por senha desativada, permissões mínimas para o usuário e um firewall limitado.

É possível permitir o SSH somente a partir de um IP?

Sim, se o endereço for permanente: adicione ao UFW uma regra allow from para esse IP. Providencie antecipadamente o console do provedor ou um acesso alternativo, pois a conexão será bloqueada depois que o IP mudar.

Com que frequência devo verificar a segurança da VPS?

Depois de cada alteração no SSH, no firewall ou na publicação de portas do Docker, faça uma verificação das portas e um teste de acesso. Como rotina, consulte as atualizações e os logs pelo menos uma vez por semana e teste a restauração dos backups regularmente.