UFW & Fail2ban (Proteção de Rede e Bloqueio de Ataques)

1. Visão geral do conceito e problema sistêmico

Um servidor Linux publicamente acessível na internet está sujeito a varreduras automatizadas contínuas por parte de botnets. Os scanners procuram portas abertas, senhas SSH fracas, bancos de dados expostos (PostgreSQL, Redis, MySQL) e painéis administrativos desprotegidos. Sem um firewall de rede sistemático, o servidor torna-se vulnerável a ataques de negação de serviço (DoS), esgotamento dos limites de descritores de socket abertos e acesso não autorizado direto.

UFW (Uncomplicated Firewall) e Fail2ban formam um sistema de proteção ativa em dois níveis:

• UFW (Nível Estático): Interface simplificada para configurar os subsistemas iptables / nftables do kernel Linux sob o princípio Default-Deny: todas as conexões de entrada são bloqueadas, exceto pelas portas explicitamente permitidas (SSH, HTTP/HTTPS).
• Fail2ban (Nível Dinâmico): Daemon de análise comportamental que monitora logs do sistema e modifica dinamicamente as regras do firewall, isolando endereços IP de bots que demonstram padrões de ataques brute-force ou sondagem de vulnerabilidades.

+-------------------------------------------------------------------+
| Tráfego de entrada (Internet)                                     |
+---------------------------------+---------------------------------+
                                  |
                                  v
                   +-----------------------------+
                   |      Daemon Fail2ban        |
                   | (Análise de logs journald/auth)|
                   +--------------+--------------+
                                  | DROP dinâmico (ex.: 24 horas)
                                  v
                   +-----------------------------+
                   |         UFW / Netfilter     |
                   |   (iptables / nftables do kernel) |
                   +--------------+--------------+
                                  |
              +-------------------+-------------------+
              | Permitido (22, 80, 443)               | Bloqueado (DROP)
              v                                       v
    +-------------------+                   +-------------------+
    | Serviços do sistema |                 | Pacote descartado  |
    | (Nginx, SSHd)       |                 | sem resposta       |
    +-------------------+                   +-------------------+

2. Taxonomia arquitetural e modelo mental

A proteção do nó baseia-se em uma clara separação de responsabilidades entre os componentes:

1. Filtro de Rede do Kernel (Netfilter / nftables):
   • Motor de baixo nível no kernel Linux que verifica os cabeçalhos de cada pacote de rede nas interfaces de rede.
2. UFW (Uncomplicated Firewall):
   • Utilitário de gerenciamento simples das cadeias de filtragem INPUT, OUTPUT, FORWARD.
   • Fornece uma sintaxe legível por humanos em vez das complexas construções sintáticas do iptables.
   • Garante uma política estática: bloqueio de faixas de portas não autorizadas.
3. Fail2ban (Infiltration Prevention Framework):
   • Jail (Isolador): Entidade de configuração que vincula um filtro (filter.d), um log e uma ação de bloqueio (action.d).
   • Filter: Conjunto de expressões regulares (failregex) para fazer parsing de erros de autenticação.
   • Action: Instrução (por exemplo, iptables-multiport) que adiciona temporariamente IPs à cadeia de descarte de pacotes.

3. Pipeline técnico e mecânica interna

Implantação básica e configuração do UFW

[!IMPORTANT] Sempre permita a porta SSH antes de ativar o firewall para evitar bloquear sua própria sessão:

# 1. Скидання та дефолтні політики (заборонити все вхідне, дозволити вихідне)
sudo ufw default deny incoming
sudo ufw default allow outgoing

# 2. Дозвіл критичних портів
sudo ufw allow 22/tcp comment "OpenSSH"
sudo ufw allow 80/tcp comment "HTTP (Let's Encrypt)"
sudo ufw allow 443/tcp comment "HTTPS"

# 3. Активація фаєрволу
sudo ufw --force enable
sudo ufw status verbose

Configuração do Fail2ban (/etc/fail2ban/jail.local)

Nunca edite jail.conf diretamente (ele é sobrescrito por atualizações do pacote); crie um arquivo de overrides:

[DEFAULT]
# Список довірених IP (білий список, який ніколи не блокується)
ignoreip = 127.0.0.1/8 ::1 198.51.100.12

# Час блокування (1 день) та вікно спостереження (10 хвилин)
bantime  = 24h
findtime = 10m
maxretry = 5

# Використання systemd backend для сучасних дистрибутивів (Ubuntu 22.04/24.04, Debian 12)
backend = systemd
banaction = ufw

[sshd]
enabled = true
port    = 22
mode    = aggressive

[nginx-http-auth]
enabled = true
port    = http,https
logpath = /var/log/nginx/error.log

Gerenciamento do daemon:

sudo systemctl enable --now fail2ban
# Перевірка статусу ізолятора SSH
sudo fail2ban-client status sshd

4. Cenários práticos de engenharia em produção

01. Proteção contra varredura direcionada de vulnerabilidades Nginx / web server

Atacantes executam scanners (nikto, sqlmap) que geram centenas de requisições para /wp-login.php, /.env, /phpmyadmin. Cria-se um filtro customizado /etc/fail2ban/filter.d/nginx-botsearch.conf que rastreia códigos de status 404 e 403 para esses caminhos nos logs. Após 3 tentativas, o IP é bloqueado por 7 dias no nível do firewall, preservando a CPU da instância.

02. Restrição de acesso a métricas internas Prometheus e serviços de BD

O servidor de monitoramento ou banco de dados PostgreSQL precisa escutar uma interface externa para replicação ou scraping de métricas. Em vez de abrir portas publicamente, configura-se uma restrição baseada em endereços IP específicos de nós parceiros:

sudo ufw allow from 10.0.0.15 to any port 9090 proto tcp comment "Prometheus scraper"
sudo ufw allow from 10.0.0.20 to any port 5432 proto tcp comment "Postgres Replica"

Todas as outras requisições para essas portas são descartadas sem enviar TCP RST (modo stealth).

03. Desbloqueio emergencial via fail2ban-client

Um desenvolvedor erra ao conectar com uma chave incorreta e seu IP doméstico entra na lista de banimento. O administrador conecta-se através de um Jump-node e remove o bloqueio sem reiniciar todo o serviço:

sudo fail2ban-client set sshd unbanip 203.0.113.45

5. Armadilhas, erros comuns e segurança

1. Docker contorna o UFW via iptables: Quando o Docker inicia um container com o parâmetro -p 8080:8080, ele cria regras na cadeia PREROUTING que têm prioridade sobre as regras do UFW. A porta fica aberta para o mundo inteiro, mesmo que ufw status mostre proibição. Corrija isso vinculando as portas exclusivamente ao loopback (-p 127.0.0.1:8080:8080) ou desativando o gerenciamento do iptables em /etc/docker/daemon.json ({"iptables": false}).
2. Estouro de logs na ausência de logrotate: Se o Fail2ban processa logs gigabytes do web server sem rotação, o daemon começará a consumir 100% da CPU do núcleo ao tentar ler o arquivo desde o início. Certifique-se de que o logrotate comprime corretamente os arquivos de log.
3. Bloqueio dos próprios proxies (Cloudflare / Reverse Proxy): Se o web server opera atrás de Cloudflare ou AWS ALB, o Fail2ban na configuração padrão bloqueará os IPs do próprio Cloudflare em vez dos clientes reais. Configure o módulo mod_remoteip no Nginx/Apache para restaurar o X-Forwarded-For antes de ativar os jails HTTP.