Sécurité — Hardening

Checklist Sécurité
Serveurs Linux & Windows

Points de contrôle CIS Benchmark, recommandations ANSSI et bonnes pratiques DevSecOps pour sécuriser vos serveurs en production.

AuteurSOL-IT Solutions Informatiques

Version1.0 — 2026

RéférentielsCIS Benchmark · ANSSI · OWASP

OS couvertsUbuntu/Debian · CentOS/RHEL · Windows Server

Niveaux de criticité

Critique — À corriger immédiatement, risque d'intrusion direct

Élevé — À corriger dans les 48h

Moyen — À traiter dans le sprint en cours

Info — Bonne pratique recommandée

Score de conformité : Non démarré

0 / 0 points validés

🔐

1. Configuration SSH

Première surface d'attaque sur tout serveur Linux exposé

Point de contrôle	Priorité	✓
Désactiver la connexion root SSH `PermitRootLogin no` Dans /etc/ssh/sshd_config — empêche les attaques brute force sur root	Critique
Authentification par clé uniquement `PasswordAuthentication no` Désactiver les mots de passe SSH, uniquement clés RSA/Ed25519	Critique
Changer le port SSH par défaut `Port 2222` Réduit les scans automatiques sur le port 22	Élevé
Limiter les utilisateurs SSH autorisés `AllowUsers deployer admin` Seuls les utilisateurs listés peuvent se connecter via SSH	Élevé
Timeout de session inactive `ClientAliveInterval 300 / ClientAliveCountMax 2` Déconnecte les sessions inactives après 10 minutes	Moyen
Utiliser des clés Ed25519 (non RSA 1024/2048) `ssh-keygen -t ed25519 -C "deployer@serveur"` Ed25519 est plus sécurisé et performant que RSA	Moyen
Désactiver le transfert X11 `X11Forwarding no` Réduit la surface d'attaque	Info

🔥

2. Firewall et réseau

Restriction des accès réseau entrants et sortants

Point de contrôle	Priorité	✓
Firewall actif (UFW / firewalld / iptables) `ufw enable && ufw default deny incoming` Politique par défaut : tout bloquer, autoriser explicitement	Critique
N'ouvrir que les ports nécessaires `ufw allow 443/tcp && ufw allow 2222/tcp` 80 (redirect → 443), 443 (HTTPS), port SSH uniquement	Critique
Bloquer les accès directs à la base de données PostgreSQL/MySQL ne doit jamais être accessible depuis l'extérieur (port 5432/3306 fermé)	Critique
Activer fail2ban `apt install fail2ban && systemctl enable fail2ban` Bloque automatiquement les IPs après X tentatives échouées	Élevé
Désactiver IPv6 si non utilisé `net.ipv6.conf.all.disable_ipv6 = 1` Dans /etc/sysctl.conf — réduit la surface d'attaque	Moyen
Activer les logs de connexion UFW `ufw logging on` Traçabilité des tentatives de connexion	Info

👤

3. Gestion des utilisateurs et droits

Principe du moindre privilège

Point de contrôle	Priorité	✓
Désactiver le compte root (Linux) `passwd -l root` Utiliser sudo plutôt que root direct	Critique
Créer un utilisateur de déploiement dédié `adduser deployer && usermod -aG sudo deployer` Ne jamais déployer avec un utilisateur personnel ou root	Élevé
Sudo sans mot de passe uniquement pour les commandes nécessaires `deployer ALL=(ALL) NOPASSWD: /bin/systemctl reload nginx` Limiter le NOPASSWD aux commandes précises uniquement	Élevé
Vérifier les utilisateurs avec UID 0 `awk -F: '$3 == 0 {print}' /etc/passwd` Seul root doit avoir l'UID 0	Élevé
Permissions des fichiers sensibles `chmod 600 /etc/ssh/sshd_config && chmod 640 /var/log/auth.log` Fichiers de config non lisibles par les utilisateurs ordinaires	Moyen
Politique de mot de passe forte `apt install libpam-pwquality` Minimum 12 caractères, complexité, expiration	Moyen

🔄

4. Mises à jour et patchs

La majorité des intrusions exploitent des vulnérabilités connues non patchées

Point de contrôle	Priorité	✓
Système à jour au moment du déploiement `apt update && apt upgrade -y && apt autoremove -y` Toujours déployer sur un OS patché	Critique
Activer les mises à jour automatiques de sécurité `dpkg-reconfigure -plow unattended-upgrades` Patchs de sécurité appliqués automatiquement	Élevé
Supprimer les paquets inutiles `apt-get remove --purge telnet ftp rsh-server` Chaque paquet installé est une surface d'attaque potentielle	Moyen
Vérifier les dépendances des applications (composer audit, npm audit) `composer audit && npm audit` CVEs dans les librairies applicatives	Moyen

🌐

5. Sécurité applicative et web

Nginx, HTTPS, headers de sécurité

Point de contrôle	Priorité	✓
HTTPS obligatoire avec TLS 1.2+ uniquement `ssl_protocols TLSv1.2 TLSv1.3;` Désactiver SSLv3, TLS 1.0 et TLS 1.1 dans Nginx/Apache	Critique
Headers de sécurité HTTP `add_header X-Frame-Options "SAMEORIGIN";` X-Frame-Options, X-XSS-Protection, X-Content-Type-Options, HSTS, CSP	Critique
Masquer la version du serveur web `server_tokens off;` Ne pas exposer la version de Nginx/Apache aux attaquants	Élevé
Variables d'environnement — jamais dans le code Clés API, mots de passe DB, secrets JWT doivent être dans .env (gitignored) ou variables d'environnement système	Critique
.env absent du dépôt Git `echo ".env" >> .gitignore && git rm --cached .env` Vérifier l'historique Git : aucun secret ne doit avoir été commité	Critique
Rate limiting sur les endpoints d'authentification `limit_req_zone $binary_remote_addr zone=login:10m rate=10r/m;` Prévention brute force sur /login, /api/auth	Élevé
APP_DEBUG=false en production Ne jamais afficher les stack traces et informations système aux utilisateurs	Élevé

📊

6. Logs, audit et monitoring

Détection et traçabilité des incidents

Point de contrôle	Priorité	✓
Logs centralisés (journald, syslog, ELK...) `journalctl -u nginx --since "1 hour ago"` Logs applicatifs, système et sécurité centralisés et retenus ≥ 90 jours	Élevé
Monitoring des connexions SSH échouées `grep "Failed password" /var/log/auth.log \| tail -20` Alertes sur ≥ 10 tentatives depuis la même IP	Élevé
Alertes uptime et consommation ressources CPU > 90%, mémoire > 85%, disque > 80% → notification email/Slack	Moyen
Audit trail applicatif immutable Chaque action sensible (création/modification/suppression de données) doit être logguée avec utilisateur, timestamp et IP	Moyen
Plan de réponse aux incidents documenté Qui contacter, quelles actions en cas de détection d'intrusion	Info

💾

7. Sauvegardes et reprise d'activité

Une sauvegarde non testée n'est pas une sauvegarde

Point de contrôle	Priorité	✓
Sauvegardes quotidiennes automatisées de la base de données `pg_dump dbname \| gzip > backup_$(date +%Y%m%d).sql.gz` Stockées hors du serveur de production (S3, autre VPS, NAS)	Critique
Rétention des sauvegardes ≥ 30 jours Pouvoir restaurer une version antérieure en cas d'attaque ransomware ou corruption	Élevé
Test de restauration mensuel Vérifier que la restauration fonctionne réellement sur un environnement de test	Élevé
Sauvegardes chiffrées `gpg --symmetric --cipher-algo AES256 backup.sql.gz` Les sauvegardes contiennent des données sensibles — les chiffrer au repos	Moyen

Checklist SécuritéServeurs Linux & Windows