La sécurisation multicouche d'un serveur Web Linux

1. Couche 0 : Sécurité physique et disponibilité

Point clé	Bonnes pratiques
Contrôle d'accès	Baie cadenassée, badge nominatif, vidéo‑surveillance, historique d'entrées.
Alimentation & clim'	Onduleurs (UPS) + groupe électrogène ; sondes de température et d'hygrométrie.
Plan B	Procédures de reprise d'activité (PRA) et de sauvegarde hors site.

2. Couche 2 : Segmentation réseau

VLAN pour isoler : DMZ, réseau de gestion, réseau utilisateurs internes.
ACL sur les switchs/routeurs pour interdire les transits inutiles.
802.1X : authentification des équipements avant d'obtenir un port actif.

3. Couches 3--4 : Pare‑feu et contrôle de flux

3.1 Choisir son moteur

Linux	BSD	Appliance BSD
nftables (recommandé)	pf,npf,ipf,ipfw	UTM, OPNsense/pfSense, DynFi, Kernun

3.2 Bonnes pratiques

Politique par défaut DROP (entrants) et STATEFUL (suivre l'état des connexions - autoriser le retour !).
Tables/IP sets pour listes noires/blanches à chaud.
Rate‑limiting (SYN‑flood, HTTP bursts) :

# nftables : 100 nouvelles connexions HTTPS par IP et par minute
add rule inet filter input tcp dport 443 ct state new counter limit rate 100/minute accept

Synproxy ou syn‑cookies pour soulager le noyau en cas de flood TCP.

4. Couche 4/5 : Chiffrement et transport

Thème	Actions concrètes
TLS 1.3	Désactivez TLS 1.0/1.1 ; ciphersuites courtes, PFS uniquement.
Certificats	Let's Encrypt (ACME, Certbot, rDNS correct, renouvèlement auto).
Sécurité HTTP	HSTS (max-age ≥ 6 mois), OCSP stapling, ALPN pour HTTP/2 et HTTP/3 (QUIC).
Tests	SSL Labs A+ ; testssl.sh dans votre CI/CD.

5. Couche 6 : Durcissement du système d'exploitation

Domaine	Exemples
Principes du moins‑privilège	Un service = un utilisateur système non‑login (useradd -r).
Modules de sécurité	SELinux (enforcing), AppArmor, Seccomp, cgroups, namespaces.
Surface de boot	Désactiver USB, IPv6 si inutile, modules noyau non utilisés (via modprobe.d).
Mises à jour	unattended-upgrades, snapshot LVM/Btrfs avant patch critique.

6. Couche 7 : Sécurité applicative

6.1 Web Application Firewall (WAF)

ModSecurity (Apache/Nginx) + règles OWASP CRS.
NAXSI (Nginx only) ou OpenResty pour Lua‑scripting avancé.

6.2 En‑têtes HTTP essentiels

add_header Content-Security-Policy "default-src 'self';" always;
add_header X-Content-Type-Options "nosniff" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;

6.3 Code & dépendances

Audit SAST/DAST dans la pipeline GitLab/GitHub.
SBOM (Software Bill of Materials) : CycloneDX, SPDX.

7. Détection & réponse : journaux, IDS/IPS et monitoring

Outil	Rôle	Points forts
Fail2ban	Parse les logs, bannit via pare‑feu	Simple, léger, scriptable (filtres « jails »)
CrowdSec	Équivalent Fail2ban, mais synchronisé + menace partagée	Décisions en temps réel, communauté, bouncer pour nftables, nginx, etc.
Suricata / Snort	IDS/IPS réseau	Détection profonde (DPI), règles ET/OSINT
Wazuh / OSSEC	HIDS, SIEM, FIM	Agrège logs, corrélation, réponse active
Prometheus + Grafana / Zabbix	Supervision	Alerting, métrologie, tableaux de bord

7.1 Cycle de réaction

Collecte : centraliser via rsyslog ou journald + fluent‑bit/Logstash.
Corrélation & alerte : seuils, règles Sigma/Yara.
Réponse : playbooks Ansible/Salt pour bloquer, isoler, redémarrer.

8. Gestion proactive des mises à jour (Patchs)

Inventaire : ansible-inventory --graph.
Périodes de maintenance documentées.
Automatisation : déploiement canari → validation → production.
Rollback : snapshots (btrfs sub snap zfs), images VM, immu‑backup (WORM).

9. Protection anti‑DDoS

Niveaux	Mesures
Edge/Cloud	CDN (Cloudflare, Fastly), Anycast, scrubbing center.
Pare‑feu local	SYN‑proxy, limite de connexion, drop UDP amplification.
Application	Cache agressif, HTTP 429 avec Retry-After, circuit‑breaker.

10. Sauvegarde & reprise après sinistre

3‑2‑1 : trois copies, sur deux supports différents, une hors site.
Chiffrement au repos : cryptsetup luks + GPG pour archives.
Tests réguliers : restauration automatisée (Ansible + Packer) dans un bac à sable.

11. Zoom : Fail2ban (asynchrone) vs alternatives synchrones

Critère	Fail2ban	CrowdSec	PF (« tables states/limit »)
Déclenchement	Analyse log (secondes)	Log + temps réel	Kernel stack (instantané)
Complexité	Faible	Moyenne (agents + bouncers)	Faible (syntax PF)
Scalabilité	Locale	Distribuée (décisions partagées)	Locale (mais very fast)
Charge CPU	Très faible	Légère	Faible
Écosystème	Jails génériques, custom filters	Marketplace de scénarios	Intégré BSD, DynFi, OPNsense, pfSense

Extrait de configuration Fail2ban :

[sshd]
enabled = true
port = 22
filter = sshd
logpath = /var/log/auth.log
maxretry = 5
findtime = 600
bantime = 3600
action = nftables-multiport[name=sshd, port="22", protocol=tcp]

Bonnes pratiques Fail2ban

Garder les journaux en local le temps voulu pour l'analyse forensic.
Exporter les bans dans une overlay IPset pour éviter de redémarrer le pare‑feu.
Tester vos filtres avec : fail2ban-regex /var/log/auth.log /etc/fail2ban/filter.d/sshd.conf.

12. Checklist de mise en production (résumé)

MAJ système et redémarrage contrôlé.
Pare‑feu actif (nft list ruleset propre et commenté).
TLS A+ vérifié.
Backup OK + test de restauration.
Supervision : alertes mails/SMS déclenchées (fausse panne).
Documentation à jour dans le Wiki d'équipe.

Rappels

La sécurité d'un serveur Web Linux n'est jamais un produit que l'on achète, mais un processus que l'on entretient : veille, audit, correctifs, revues régulières de configuration et exercices de crise.
Fail2ban reste un excellent premier rempart, surtout sur des VPS ou serveurs dédiés économiques ; toutefois, combinez‑le toujours à des mécanismes plus proches du noyau (nftables) et à des services externes (CDN/anti‑DDoS) pour tenir face aux attaques volumétriques modernes.

Pour aller plus loin

OWASP Top 10 & ASVS -- méthodologies d'audit applicatif.
Hardening Guides : CIS Benchmarks (Debian, Ubuntu, RHEL), Project "DevSec".
Outils de scan : lynis, openscap, cis-cat, trivy (containers).
Formation continue : TryHackMe, Hack The Box, Root‑Me (lab "Blue Team")

↑ Haut de page