DevOps9 min de leitura

Segurança de Servidor Linux: SSH Keys, UFW, Fail2Ban e Hardening

Configuração completa de segurança em VPS Ubuntu: SSH key com Ed25519, desativar root login, UFW com regras granulares, Fail2Ban com jail para SSH e Nginx, Docker e UFW (o problema das iptables), e unattended-upgrades.

12 de agosto de 2026

Ao provisionar um VPS, ele entra no ar com o IP público visível ao mundo. Em questão de minutos, bots automatizados começam a tentar login SSH com senhas comuns. Logs do /var/log/auth.log em servidores sem hardening mostram centenas de tentativas por hora. Este artigo cobre a sequência completa de hardening para um servidor Ubuntu recém-criado.

O hardening não precisa ser complexo para ser eficaz. Os 5 passos abaixo cobrem a grande maioria dos vetores de ataque em servidores VPS: eliminar a conta root remota, substituir senhas por criptografia de chave pública, restringir portas expostas, banir IPs que fazem brute force, e manter o sistema atualizado automaticamente. Execute-os na ordem apresentada — preferencialmente logo após o provisionamento.

1. Crie um Usuário Não-Root

bash

1# Nunca opere como root em produção
# Nunca opere como root em produção
2# Crie um usuário dedicado para a aplicação
# Crie um usuário dedicado para a aplicação
3adduser deploy
adduser deploy
4usermod -aG sudo deploy
usermod -aG sudo deploy
5

6# Copie a chave SSH do root para o novo usuário
# Copie a chave SSH do root para o novo usuário
7mkdir -p /home/deploy/.ssh
mkdir -p /home/deploy/.ssh
8cp /root/.ssh/authorized_keys /home/deploy/.ssh/
cp /root/.ssh/authorized_keys /home/deploy/.ssh/
9chown -R deploy:deploy /home/deploy/.ssh
chown -R deploy:deploy /home/deploy/.ssh
10chmod 700 /home/deploy/.ssh
chmod 700 /home/deploy/.ssh
11chmod 600 /home/deploy/.ssh/authorized_keys
chmod 600 /home/deploy/.ssh/authorized_keys

2. SSH com Chave Ed25519 (sem senhas)

A chave Ed25519 é preferida sobre RSA 2048: chaves menores, mais rápidas de assinar, resistentes a ataques de canal lateral e amplamente suportadas. Desativar o PasswordAuthentication elimina completamente ataques de força bruta baseados em senha — um atacante sem a chave privada não tem como entrar, independente de quantas tentativas faça.

bash

1# Na sua máquina LOCAL: gere uma chave Ed25519 (mais moderna e segura que RSA 2048)
# Na sua máquina LOCAL: gere uma chave Ed25519 (mais moderna e segura que RSA 2048)
2ssh-keygen -t ed25519 -C "deploy@meu-projeto" -f ~/.ssh/meu-projeto_ed25519
ssh-keygen -t ed25519 -C "deploy@meu-projeto" -f ~/.ssh/meu-projeto_ed25519
3

4# Copie a chave pública para o servidor
# Copie a chave pública para o servidor
5ssh-copy-id -i ~/.ssh/meu-projeto_ed25519.pub deploy@IP_DO_SERVIDOR
ssh-copy-id -i ~/.ssh/meu-projeto_ed25519.pub deploy@IP_DO_SERVIDOR
6

7# No servidor: configure o SSH
# No servidor: configure o SSH
8sudo nano /etc/ssh/sshd_config
sudo nano /etc/ssh/sshd_config
9

10# Altere ou confirme estas linhas:
# Altere ou confirme estas linhas:
11# PermitRootLogin no              # Nunca root via SSH
# PermitRootLogin no              # Nunca root via SSH
12# PasswordAuthentication no       # Apenas chave criptográfica
# PasswordAuthentication no       # Apenas chave criptográfica
13# PubkeyAuthentication yes
# PubkeyAuthentication yes
14# Port 2222                       # Opcional: porta não-padrão (reduz bots)
# Port 2222                       # Opcional: porta não-padrão (reduz bots)
15# AllowUsers deploy               # Apenas o usuário deploy pode conectar
# AllowUsers deploy               # Apenas o usuário deploy pode conectar
16

17sudo systemctl reload ssh
sudo systemctl reload ssh
18

19# ATENÇÃO: teste a conexão em um terminal separado ANTES de fechar o atual
# ATENÇÃO: teste a conexão em um terminal separado ANTES de fechar o atual
20# ssh -i ~/.ssh/meu-projeto_ed25519 deploy@IP -p 2222
# ssh -i ~/.ssh/meu-projeto_ed25519 deploy@IP -p 2222

3. Firewall com UFW

O UFW (Uncomplicated Firewall) é uma interface de linha de comando para o iptables, muito mais simples de usar. A regra fundamental é deny incoming por padrão: tudo que não for explicitamente permitido é bloqueado. Abra apenas as portas que a aplicação realmente precisa — nenhuma porta de banco de dados, Redis ou serviço interno deve ser exposta externamente.

bash

1# UFW: bloqueia tudo por padrão, abre apenas o necessário
# UFW: bloqueia tudo por padrão, abre apenas o necessário
2sudo ufw default deny incoming
sudo ufw default deny incoming
3sudo ufw default allow outgoing
sudo ufw default allow outgoing
4

5# Se mudou a porta SSH, use o número correto!
# Se mudou a porta SSH, use o número correto!
6sudo ufw allow 2222/tcp comment 'SSH'
sudo ufw allow 2222/tcp comment 'SSH'
7sudo ufw allow 80/tcp comment 'HTTP'
sudo ufw allow 80/tcp comment 'HTTP'
8sudo ufw allow 443/tcp comment 'HTTPS'
sudo ufw allow 443/tcp comment 'HTTPS'
9

10# Portas internas (banco, redis): NUNCA abra para 0.0.0.0
# Portas internas (banco, redis): NUNCA abra para 0.0.0.0
11# Acesse apenas via SSH tunnel ou rede interna do Docker
# Acesse apenas via SSH tunnel ou rede interna do Docker
12

13sudo ufw enable  # Confirme com 'y'
sudo ufw enable  # Confirme com 'y'
14sudo ufw status verbose
sudo ufw status verbose

Docker e UFW não se falam bem. O Docker modifica as iptables diretamente, contornando as regras do UFW. Se você expõe uma porta com ports: ['5432:5432'], o PostgreSQL fica acessível publicamente — ignorando o ufw deny. A solução: bind apenas no loopback ports: ['127.0.0.1:5432:5432'] para serviços que não devem ser acessados externamente. Para serviços entre containers, use a rede interna do Docker sem mapear portas.

4. Fail2Ban: Banimento Automático

O Fail2Ban monitora arquivos de log em tempo real e bane IPs que excedem um número de tentativas falhas. Para SSH, 3 senhas erradas equivalem a um ataque de força bruta — um usuário legítimo não erra a senha 3 vezes seguidas. O ban de 24 horas para SSH torna ataques distribuídos exaustivamente lentos. A configuração para Nginx também protege contra tentativas de enumeração de endpoints via rate limiting no nível do log.

bash

1sudo apt-get install -y fail2ban
sudo apt-get install -y fail2ban
2

3# Crie uma configuração local (nunca edite jail.conf diretamente)
# Crie uma configuração local (nunca edite jail.conf diretamente)
4sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
5sudo nano /etc/fail2ban/jail.local
sudo nano /etc/fail2ban/jail.local

jail.local

1[DEFAULT]
[DEFAULT]
2# Tempo de banimento padrão: 1 hora
# Tempo de banimento padrão: 1 hora
3bantime = 3600
bantime = 3600
4# Janela de observação: 10 minutos
# Janela de observação: 10 minutos
5findtime = 600
findtime = 600
6# Número de falhas permitidas antes do ban
# Número de falhas permitidas antes do ban
7maxretry = 5
maxretry = 5
8# Ignorar IPs locais
# Ignorar IPs locais
9ignoreip = 127.0.0.1/8 ::1
ignoreip = 127.0.0.1/8 ::1
10

11[sshd]
[sshd]
12enabled = true
enabled = true
13port = 2222          # Sua porta SSH personalizada
port = 2222          # Sua porta SSH personalizada
14logpath = %(sshd_log)s
logpath = %(sshd_log)s
15maxretry = 3         # SSH: 3 tentativas — mais rigoroso que o padrão
maxretry = 3         # SSH: 3 tentativas — mais rigoroso que o padrão
16bantime = 86400      # Ban por 24h em caso de falha no SSH
bantime = 86400      # Ban por 24h em caso de falha no SSH
17

18[nginx-limit-req]
[nginx-limit-req]
19enabled = true
enabled = true
20port = http,https
port = http,https
21logpath = /var/log/nginx/error.log
logpath = /var/log/nginx/error.log
22maxretry = 10
maxretry = 10

bash

1sudo systemctl enable fail2ban
sudo systemctl enable fail2ban
2sudo systemctl start fail2ban
sudo systemctl start fail2ban
3

4# Verificar status e IPs banidos
# Verificar status e IPs banidos
5sudo fail2ban-client status sshd
sudo fail2ban-client status sshd
6sudo fail2ban-client status nginx-limit-req
sudo fail2ban-client status nginx-limit-req
7

8# Desbanir um IP (caso você mesmo seja banido)
# Desbanir um IP (caso você mesmo seja banido)
9sudo fail2ban-client set sshd unbanip SEU_IP
sudo fail2ban-client set sshd unbanip SEU_IP

5. Atualizações Automáticas de Segurança

Vulnerabilidades em pacotes do sistema (OpenSSL, Kernel, SSH daemon) são a causa de muitas violações de segurança em servidores. O unattended-upgrades aplica automaticamente apenas patches de segurança — sem atualizar versões major que poderiam quebrar a aplicação. A janela entre a divulgação de uma CVE e sua exploração em massa é frequentemente de horas. Com atualizações automáticas, seu servidor é patcheado antes de você acordar.

bash

1sudo apt-get install -y unattended-upgrades
sudo apt-get install -y unattended-upgrades
2sudo dpkg-reconfigure --priority=low unattended-upgrades
sudo dpkg-reconfigure --priority=low unattended-upgrades
3

4# Confirme que está ativado
# Confirme que está ativado
5sudo systemctl status unattended-upgrades
sudo systemctl status unattended-upgrades
6

7# O arquivo de configuração fica em:
# O arquivo de configuração fica em:
8# /etc/apt/apt.conf.d/50unattended-upgrades
# /etc/apt/apt.conf.d/50unattended-upgrades
9# Por padrão, aplica apenas atualizações de segurança — não quebra o sistema
# Por padrão, aplica apenas atualizações de segurança — não quebra o sistema

Verifique periodicamente o log /var/log/auth.log para entender a atividade no servidor: sudo grep 'Invalid user\|Failed password\|Accepted publickey' /var/log/auth.log | tail -50. Se você ver centenas de tentativas de IPs diferentes, o Fail2Ban está funcionando — eles estão sendo banidos após 3 falhas.

Conclusão

Os 5 passos — usuário não-root, SSH com Ed25519 sem senha, UFW bloqueando tudo exceto o necessário, Fail2Ban banindo brute force, e atualizações automáticas de segurança — cobrem a superfície de ataque mais comum em servidores expostos à internet. O Docker requer atenção especial: sempre use bind no loopback (127.0.0.1) para portas que não devem ser públicas, pois o Docker contorna o UFW via iptables direto.