Hardening général : les essentiels

Durcir (« hardening »), c'est réduire la surface d'attaque d'un système avant qu'il ne soit attaqué. Cette doc liste les mesures qui couvrent 95 % des cas réels sur un site web hébergé. Rien d'exotique, rien de théorique : la même checklist que nous appliquons chez Datacampus sur nos serveurs et que nous recommandons à nos clients pour leur partie applicative.

Trois principes directeurs

1. Moindre privilège

Chaque utilisateur, chaque process, chaque service doit avoir le minimum de droits nécessaires, pas un de plus. Un compte éditeur CMS ne devrait pas pouvoir installer des plugins. Un site A ne devrait pas lire les fichiers d'un site B. L'utilisateur PHP ne devrait pas pouvoir écrire dans le dossier d'installation du CMS.

2. Defense in depth

Plusieurs couches de protection plutôt qu'une seule. Si l'attaquant passe l'une, la suivante limite les dégâts : WAF > CMS à jour > plugin sécurité > MDP fort > 2FA > logs et alertes > backups. Aucune couche n'est parfaite, leur combinaison oui.

3. Mises à jour

80 % des compromissions exploitent une vulnérabilité déjà corrigée par un patch que la victime n'a pas appliqué. La meilleure défense reste de mettre à jour vite : core CMS, plugins, thèmes, librairies, OS. MAJ auto quand c'est possible et raisonnable.

Côté compte : votre identité numérique

Mots de passe forts, uniques, stockés dans un gestionnaire

• Minimum 14 caractères aujourd'hui (16+ pour les comptes critiques), générés aléatoirement.
• Un mot de passe par service — jamais de réutilisation. Une fuite sur un site mineur ne doit pas compromettre votre Plesk.
• Gestionnaire de mots de passe obligatoire : Bitwarden, 1Password, KeePassXC. Mémoriser une passphrase maître, laisser le gestionnaire gérer le reste.
• Passphrase maître : 4 à 6 mots aléatoires + un peu de variation (méthode diceware), pas « motdepasse2025 ».

2FA partout où c'est possible

Authentification à deux facteurs sur :

• Plesk / espace client Datacampus.
• Compte email (qui sert à reset tout le reste — le maillon faible).
• Admin CMS (WordPress : plugin Two Factor, Prestashop : module natif récent).
• GitHub / GitLab.
• Gestionnaire de MDP lui-même.

Préférer TOTP (app type Aegis, Raivo, 1Password) aux SMS (SIM swap). Clé de sécurité physique (YubiKey) pour les comptes les plus sensibles.

Comptes : hygiène de base

• Un compte par personne. Jamais de compte partagé « webmaster » — on ne sait plus qui a fait quoi.
• Supprimer les comptes inutiles : prestataires anciens, stagiaires partis, plugins ayant créé un user admin automatique.
• Rôles adaptés : l'éditeur rédige, il n'installe pas de plugins. Zéro « admin par défaut parce que c'est plus simple ».
• Revue périodique : une fois par trimestre, lister les comptes, désactiver les dormants.

Côté site : l'enveloppe HTTP

HTTPS obligatoire + HSTS

Certificat Let's Encrypt (gratuit, auto-renouvelé par Plesk/Datacampus), redirection http:// → https:// forcée, puis en-tête HSTS pour interdire le retour en HTTP même sur lien manuel.

Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains" env=HTTPS

Commencer avec une valeur courte (max-age=300) pour valider que tout fonctionne, puis monter à un an. Ajouter preload et soumettre à hstspreload.org pour durcir encore.

En-têtes de sécurité HTTP

À ajouter dans votre .htaccess (ou conf nginx) :

# Empêche l'affichage du site en iframe (clickjacking)
Header always set X-Frame-Options "SAMEORIGIN"

# Empêche le sniffing MIME
Header always set X-Content-Type-Options "nosniff"

# Limite les infos envoyées dans le Referer
Header always set Referrer-Policy "strict-origin-when-cross-origin"

# Limite les permissions des API navigateur
Header always set Permissions-Policy "geolocation=(), microphone=(), camera=()"

Content Security Policy (CSP) de base

La CSP limite les sources autorisées pour scripts, images, frames, etc. Bien configurée, elle neutralise la plupart des XSS. Une CSP trop stricte casse le site ; commencer en mode Report-Only :

Header set Content-Security-Policy-Report-Only "default-src 'self'; img-src 'self' data: https:; style-src 'self' 'unsafe-inline'; script-src 'self'; frame-ancestors 'self'"

Laisser tourner quelques jours, collecter les violations (console navigateur), ajuster, puis basculer en Content-Security-Policy (sans -Report-Only). Test avec Mozilla Observatory pour un score et des recommandations.

Cookies : Secure + HttpOnly + SameSite

Tout cookie de session doit porter :

• Secure — uniquement envoyé en HTTPS.
• HttpOnly — inaccessible au JavaScript (mitige le vol par XSS).
• SameSite=Lax (ou Strict pour le back-office) — protection CSRF.

Sur WordPress ≥ 5.8, géré automatiquement pour les cookies de login. Côté applicatif, vérifier les cookies émis par les plugins tiers.

Côté serveur : ce que nous gérons (et ce que vous voyez)

fail2ban

Bannit automatiquement les IP qui accumulent des échecs d'authentification (SSH, FTP, Plesk, WordPress login si hook installé). Déployé sur toutes nos infrastructures. Côté applicatif, vous pouvez ajouter un plugin (WPS Limit Login, Wordfence) qui applique la même logique au login CMS.

SSH : clés uniquement

Sur un VPS, désactiver l'authentification par mot de passe dans /etc/ssh/sshd_config :

PasswordAuthentication no
PermitRootLogin prohibit-password
# Idéalement, déplacer sur un port non standard (non-32768-60999)
# Port 2222

Utiliser une clé Ed25519 (ssh-keygen -t ed25519), protégée par passphrase. Ajouter la clé publique dans ~/.ssh/authorized_keys sur le serveur.

Pare-feu applicatif (WAF)

Couche de filtrage qui bloque les requêtes malveillantes avant qu'elles atteignent le site :

• Imunify360 — disponible sur certaines offres Plesk Datacampus.
• Wordfence (application) — WAF applicatif pour WordPress.
• Cloudflare — WAF en amont, se configure sur votre zone DNS.
• ModSecurity + OWASP CRS — à installer côté Apache/nginx sur un VPS.

Permissions fichiers

Bonne base pour un CMS classique :

• Dossiers : 755.
• Fichiers : 644.
• Jamais de 777 — c'est un drapeau rouge pour les scanners.
• wp-config.php / .env : 640 (ou 600), propriétaire restreint.

Audit continu

Scans réguliers

• Wordfence / Imunify — scan hebdomadaire au minimum, avec alerte email.
• Mozilla Observatory (observatory.mozilla.org) — note de A+ à F sur vos en-têtes HTTP.
• SSL Labs (ssllabs.com/ssltest) — qualité de la config TLS.
• Security Headers (securityheaders.com) — rapide et concret.

Revue plugins / thèmes

• Désinstaller ce qui n'est plus utilisé. Un plugin inactif non supprimé reste exploitable.
• Vérifier la date de dernière MAJ : au-delà de 12 mois sans update, considérer l'abandon.
• S'abonner à Patchstack, WPScan, CVE databases pour être alerté des failles sur vos dépendances.

Analyse des logs d'accès

Consultation mensuelle ou alertes automatiques sur :

• Pics de trafic inexpliqués.
• Requêtes POST vers des URL inhabituelles.
• User-Agents anormaux.
• Bursts de codes d'erreur 401/403 (bruteforce).

Monitoring uptime

UptimeRobot, Uptime Kuma (auto-hébergé), ou la supervision Datacampus : détecter en minutes une indisponibilité ou un rebond anormal (votre site rend un 200 mais avec le mauvais contenu).

Plan de réponse à incident

Préparer avant qu'il n'y ait incident. Document court de 1 page, partagé avec l'équipe :

• Qui prévenir et dans quel ordre (Datacampus, DPO, direction, client).
• Contacts et numéros d'urgence.
• Où sont les backups, depuis quand, politique de rétention.
• Actions de confinement pré-écrites (couper le site, IP de maintenance, etc.).
• Obligations réglementaires : notification CNIL 72 h si données personnelles compromises.

Voir la doc Mon site est hacké : que faire ? pour la procédure détaillée quand l'incident arrive.

Checklist express