UFW & Fail2ban (Protection réseau et blocage des attaques)

1. Vue d’ensemble du concept et problématique système

Un serveur Linux exposé publiquement sur Internet est soumis à un scan automatisé continu par des botnets. Ces scanners recherchent des ports ouverts, des mots de passe SSH faibles, des bases de données exposées (PostgreSQL, Redis, MySQL) ainsi que des panneaux d’administration non sécurisés. En l’absence de pare-feu réseau structuré, le serveur devient vulnérable aux attaques par déni de service (DoS), à l’épuisement des limites de descripteurs de sockets ouverts et à un accès non autorisé direct.

UFW (Uncomplicated Firewall) et Fail2ban constituent une architecture de défense active à deux niveaux :

• UFW (Niveau statique) : Interface simplifiée pour configurer les sous-systèmes iptables / nftables du noyau Linux selon le principe Default-Deny : toutes les connexions entrantes sont bloquées, sauf pour les ports explicitement autorisés (SSH, HTTP/HTTPS).
• Fail2ban (Niveau dynamique) : Démon d’analyse comportementale qui surveille les journaux système et modifie dynamiquement les règles du pare-feu, isolant les adresses IP des bots présentant des motifs d’attaques par force brute ou de sondage de vulnérabilités.

+-------------------------------------------------------------------+
| Trafic entrant (Internet)                                         |
+---------------------------------+---------------------------------+
                                  |
                                  v
                   +-----------------------------+
                   |       Démon Fail2ban        |
                   | (Analyse des logs journald/auth)|
                   +--------------+--------------+
                                  | DROP dynamique (par exemple, 24 h)
                                  v
                   +-----------------------------+
                   |        UFW / Netfilter      |
                   |  (noyau iptables / nftables)|
                   +--------------+--------------+
                                  |
              +-------------------+-------------------+
              | Autorisé (22, 80, 443)               | Bloqué (DROP)
              v                                       v
    +-------------------+                   +-------------------+
    | Services système  |                   | Paquet détruit    |
    | (Nginx, SSHd)     |                   | sans réponse      |
    +-------------------+                   +-------------------+

2. Taxonomie architecturale et modèle mental

La protection du nœud repose sur une répartition claire des responsabilités entre les composants :

1. Filtre réseau du noyau (Netfilter / nftables) :
   • Moteur bas niveau intégré au noyau Linux, inspectant les en-têtes de chaque paquet réseau transitant par les interfaces réseau.
2. UFW (Uncomplicated Firewall) :
   • Utilitaire de gestion simple des chaînes de filtrage INPUT, OUTPUT, FORWARD.
   • Offre une syntaxe compréhensible pour l’humain, remplaçant les constructions complexes de iptables.
   • Applique une politique statique : blocage des plages de ports non autorisées.
3. Fail2ban (Infiltration Prevention Framework) :
   • Jail (Prison) : Entité de configuration liant un filtre (filter.d), un journal de logs et une action de blocage (action.d).
   • Filter : Ensemble d’expressions régulières (failregex) utilisé pour analyser les erreurs d’authentification.
   • Action : Instruction (par exemple, iptables-multiport) ajoutant temporairement une IP dans la chaîne de rejet des paquets.

3. Pipeline technique et mécanique interne

Déploiement de base et configuration UFW

[!IMPORTANT] Autorisez toujours le port SSH avant d’activer le pare-feu afin d’éviter de bloquer votre propre session :

# 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

Configuration de Fail2ban (/etc/fail2ban/jail.local)

Ne modifiez jamais directement jail.conf (il est écrasé lors des mises à jour du paquet) ; créez plutôt un fichier de surcharge (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

Gestion du démon :

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

4. Scénarios d’ingénierie pratiques en production

01. Protection contre le scan ciblé de vulnérabilités Nginx / serveur web

Les attaquants déploient des scanners (nikto, sqlmap) générant des centaines de requêtes vers /wp-login.php, /.env, /phpmyadmin. Un filtre personnalisé /etc/fail2ban/filter.d/nginx-botsearch.conf est créé pour traquer dans les logs les codes de statut 404 et 403 associés à ces chemins. Après 3 tentatives, l’IP est bloquée pendant 7 jours au niveau du pare-feu, préservant ainsi le CPU de l’instance.

02. Restriction d’accès aux métriques internes Prometheus et services DB

Le serveur de monitoring ou la base de données PostgreSQL doit écouter sur une interface externe pour la réplication ou le scraping de métriques. Plutôt que d’exposer publiquement les ports, configurez des restrictions basées sur les adresses IP spécifiques des nœuds partenaires :

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"

Toutes les autres requêtes sur ces ports sont silencieusement abandonnées sans envoi de TCP RST (mode stealth).

03. Déblocage d’urgence via fail2ban-client

Un développeur se trompe lors d’une connexion avec une clé incorrecte et son IP domestique est bannie. L’administrateur se connecte via un nœud Jump et retire le blocage sans redémarrer l’ensemble du service :

sudo fail2ban-client set sshd unbanip 203.0.113.45

5. Pièges courants, erreurs typiques et sécurité

1. Docker contourne UFW via iptables : Lorsque Docker lance un conteneur avec l’option -p 8080:8080, il crée des règles dans la chaîne PREROUTING ayant priorité sur celles d’UFW. Le port s’ouvre alors au monde entier, même si ufw status indique un blocage. Corrigez cela en liant les ports exclusivement au loopback (-p 127.0.0.1:8080:8080) ou en désactivant la gestion iptables dans /etc/docker/daemon.json ({"iptables": false}).
2. Saturation des logs en l’absence de logrotate : Si Fail2ban analyse des gigaoctets de logs de serveur web sans rotation, le démon consommera 100 % du CPU du cœur en tentant de lire le fichier depuis le début. Assurez-vous que logrotate compresse correctement les fichiers journaux.
3. Blocage de vos propres proxys (Cloudflare / Reverse Proxy) : Si le serveur web fonctionne derrière Cloudflare ou AWS ALB, Fail2ban dans sa configuration standard bloquera les adresses IP de Cloudflare elles-mêmes, plutôt que les vrais clients. Configurez le module mod_remoteip dans Nginx/Apache pour restaurer l’en-tête X-Forwarded-For avant d’activer les jails HTTP.