Sécuriser et dépanner un serveur de services : nftables, fail2ban et méthode

Sécuriser un serveur de services, c'est réduire ce qui est exposé (ports, comptes, informations), filtrer ce qui reste avec un pare-feu local, bloquer automatiquement les attaques répétées et durcir chaque service. Dépanner, c'est trouver méthodiquement la couche qui ne fonctionne pas, du service au réseau. Ce chapitre configure le pare-feu local nftables de srv-glpi, installe fail2ban, rassemble les réglages de durcissement des chapitres précédents dans une liste de contrôle, et donne une méthode de dépannage applicable à tous les services. Le durcissement du système lui-même (SSH, comptes, sudo, AppArmor, mises à jour) est traité dans le cours Linux — Administration système, et les principes du durcissement dans le cours Cybersécurité des infrastructures.

Réduire la surface d'attaque

Chaque port ouvert est une porte. Commence par la liste de ce qui écoute vraiment :

sudo ss -tlnup

Netid State  Local Address:Port  Process
udp   UNCONN 127.0.0.1:323       users:(("chronyd",pid=611,fd=5))
tcp   LISTEN 127.0.0.1:3306      users:(("mariadbd",pid=1027,fd=21))
tcp   LISTEN 127.0.0.1:25        users:(("master",pid=1290,fd=13))
tcp   LISTEN 0.0.0.0:22          users:(("sshd",pid=702,fd=3))
tcp   LISTEN 0.0.0.0:80          users:(("nginx",pid=812,fd=5))
tcp   LISTEN 0.0.0.0:443         users:(("nginx",pid=812,fd=6))

Lis la colonne Local Address : 127.0.0.1 signifie que le service n'est joignable que depuis la machine (MariaDB, Postfix, chrony), 0.0.0.0 ou * qu'il écoute sur toutes les interfaces. Sur srv-glpi, seuls SSH, HTTP et HTTPS doivent être joignables depuis le réseau. Tout autre port ouvert est soit un service à désinstaller, soit un service à faire écouter en local.

Le pare-feu local avec nftables

Le pare-feu pfSense filtre les flux entre les VLAN ; il ne voit pas ce qui circule à l'intérieur d'un même VLAN. Un pare-feu local sur chaque serveur ajoute une seconde barrière (on parle de défense en profondeur) : si un serveur voisin est compromis, il ne peut joindre de srv-glpi que ce qui est explicitement autorisé. Sous Debian 13, le pare-feu du noyau se configure avec nftables, qui remplace iptables.

La politique de srv-glpi, tirée de la matrice des flux :

/etc/nftables.conf :

#!/usr/sbin/nft -f

flush ruleset

table inet filtre {
    set admin {
        type ipv4_addr
        flags interval
        elements = { 192.168.10.208/28 }
    }
    set clients_glpi {
        type ipv4_addr
        flags interval
        elements = { 192.168.10.64/26, 192.168.10.208/28 }
    }

    chain entree {
        type filter hook input priority filter; policy drop;

        ct state established,related accept
        ct state invalid drop
        iif "lo" accept

        icmp type echo-request accept
        icmpv6 type { echo-request, nd-neighbor-solicit, nd-neighbor-advert, nd-router-advert } accept

        ip saddr @admin tcp dport 22 accept
        ip saddr @clients_glpi tcp dport { 80, 443 } accept
        ip saddr 192.168.10.180 tcp dport 3306 accept

        limit rate 10/minute log prefix "nft-refus: "
    }

    chain transfert {
        type filter hook forward priority filter; policy drop;
    }

    chain sortie {
        type filter hook output priority filter; policy accept;
    }
}

Appliquer sans se couper. Une règle SSH fausse, et tu perds la main sur le serveur. Vérifie d'abord la syntaxe, garde la console de Proxmox ouverte, puis applique :

sudo nft -c -f /etc/nftables.conf      # vérifie sans appliquer
sudo systemctl enable --now nftables   # applique, et à chaque démarrage
sudo nft list ruleset
journalctl -k -g "nft-refus" --since "10 min ago"   # les refus journalisés

Pour les autres serveurs du cours, seules les règles d'ouverture changent :

Bloquer les attaques par force brute avec fail2ban

Une attaque par force brute essaie des milliers de mots de passe sur un service exposé ; une attaque par dictionnaire essaie les mots de passe et les noms de comptes les plus courants. fail2ban lit les journaux, compte les échecs par adresse et, au-delà d'un seuil, ajoute une règle de pare-feu qui bloque cette adresse pendant un temps donné.

sudo apt install fail2ban

Sous Debian 13, fail2ban est préconfiguré : la prison (jail) sshd est active, lit le journal systemd et bloque avec nftables (/etc/fail2ban/jail.d/defaults-debian.conf). Ajoute tes réglages dans un fichier à toi, jamais dans jail.conf, que les mises à jour remplacent :

# /etc/fail2ban/jail.d/sorbier.conf
[DEFAULT]
bantime  = 1h
findtime = 10m
maxretry = 5
# Ne jamais bloquer le réseau d'administration
ignoreip = 127.0.0.1/8 ::1 192.168.10.208/28

# Debian 13 : les échecs SSH sont tracés par sshd-session
[sshd]
journalmatch = _SYSTEMD_UNIT=ssh.service + _COMM=sshd + _COMM=sshd-session

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

sudo systemctl restart fail2ban
sudo fail2ban-client status
sudo fail2ban-client get sshd journalmatch     # vérifie que sshd-session est bien lu
# _SYSTEMD_UNIT=ssh.service + _COMM=sshd + _COMM=sshd-session
sudo fail2ban-client status sshd
# Status for the jail: sshd
# |- Filter
# |  |- Currently failed: 1
# |  |- Total failed:     38
# |  `- Journal matches:  _SYSTEMD_UNIT=ssh.service + _COMM=sshd + _COMM=sshd-session
# `- Actions
#    |- Currently banned: 2
#    |- Total banned:     4
#    `- Banned IP list:   198.51.100.23 203.0.113.99
sudo fail2ban-client set sshd unbanip 198.51.100.23   # débloquer une adresse

Durcir chaque service : la liste de contrôle

Ce tableau rassemble les réglages vus dans le cours. C'est une base de recette : chaque ligne se vérifie par une commande.

systemd peut aussi enfermer un service : lui interdire d'écrire hors de certains dossiers, de voir les fichiers personnels, d'obtenir de nouveaux privilèges. systemd-analyze security note l'exposition de chaque service de 0 (très enfermé) à 10 (aucune restriction) :

systemd-analyze security nginx.service

La plupart des services des paquets Debian obtiennent un score élevé, faute de restrictions dans leur unité. On peut en ajouter avec systemctl edit nginx (directives ProtectSystem=, ProtectHome=, NoNewPrivileges=…), mais avec prudence : une restriction trop forte empêche le service de fonctionner. C'est une piste d'amélioration à citer, à tester sur une maquette.

La méthode de dépannage

Quand un utilisateur dit « GLPI ne marche pas », la panne peut se trouver à chaque étage du chemin. La méthode : partir du service et remonter vers le client, en vérifiant chaque couche avec une commande, jusqu'à celle qui échoue.

tcpdump est le juge de paix entre « le réseau » et « le serveur » : si les paquets du client n'arrivent pas sur l'interface du serveur, inutile de chercher dans Nginx ; s'ils arrivent et que le serveur ne répond pas, la cause est sur le serveur (pare-feu local, service).

Exercices

#!/usr/sbin/nft -f

flush ruleset

table inet filtre {
    set admin {
        type ipv4_addr
        flags interval
        elements = { 192.168.10.208/28 }
    }
    set clients_smb {
        type ipv4_addr
        flags interval
        elements = { 192.168.10.64/26, 192.168.10.128/27 }
    }

    chain entree {
        type filter hook input priority filter; policy drop;
        ct state established,related accept
        ct state invalid drop
        iif "lo" accept
        icmp type echo-request accept
        icmpv6 type { echo-request, nd-neighbor-solicit, nd-neighbor-advert, nd-router-advert } accept

        ip saddr @admin tcp dport 22 accept
        ip saddr @clients_smb tcp dport 445 accept
        ip saddr 192.168.10.184 tcp dport 2049 accept

        limit rate 10/minute log prefix "nft-refus: "
    }
    chain transfert {
        type filter hook forward priority filter; policy drop;
    }
    chain sortie {
        type filter hook output priority filter; policy accept;
    }
}