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")