1. Inventorier la surface d’attaque réelle
Listez ports publics, comptes SSH, comptes WordPress privilégiés, extensions, thèmes, tâches cron, API REST, XML-RPC, formulaires, répertoires inscriptibles, secrets, fournisseurs et flux de sauvegarde. Documentez le propriétaire et la raison de chaque exposition.
CISA maintient une liste de vulnérabilités exploitées connues; WordPress publie ses propres conseils de durcissement. Ces sources doivent alimenter l’inventaire, pas remplacer l’observation du serveur réel.
2. Mettre à jour le système et WordPress délibérément
Appliquez rapidement les correctifs de sécurité Debian, WordPress, PHP, serveur web, thèmes et extensions. Réduisez l’inventaire avant de l’automatiser : tout composant abandonné doit être retiré ou remplacé.
Pour un code applicatif verrouillé en production, désactivez les modifications depuis l’administration et utilisez une procédure de mise à jour contrôlée : sauvegarde, fenêtre de maintenance, mise à jour, validation, puis retour au verrouillage.
3. Durcir SSH sans perdre la voie de récupération
Utilisez des clés, interdisez la connexion root et les mots de passe, limitez les utilisateurs, désactivez transfert d’agent, redirection TCP et tunnels lorsqu’ils ne sont pas requis. Validez la configuration avec sshd -t avant rechargement.
Gardez la session courante ouverte et testez immédiatement une seconde connexion. Une mesure qui coupe l’accès opérationnel sans console de secours transforme un risque de sécurité en incident de disponibilité.
4. Appliquer un pare-feu à refus implicite
Exposez seulement les ports nécessaires — généralement SSH, HTTP et HTTPS — et gardez la base de données liée à l’interface locale. Validez aussi les règles du pare-feu infonuagique : un pare-feu hôte ne remplace pas la couche réseau du fournisseur.
Avant d’activer UFW, confirmez la règle SSH et conservez une voie de récupération. Documentez l’état précédent pour un retour arrière.
5. Retirer à PHP le droit de modifier le code
Le code WordPress devrait appartenir à un compte de déploiement ou à root et rester en lecture seule pour le processus web. Les écritures doivent être limitées aux téléversements, au cache et aux répertoires temporaires réellement utilisés.
Interdisez l’exécution de fichiers PHP dans uploads. Un téléversement malveillant ne devient alors pas automatiquement une porte d’exécution. Les permissions ne corrigent pas une vulnérabilité, mais elles en limitent les conséquences.
6. Protéger la frontière applicative
Imposez HTTPS à l’administration, MFA aux comptes privilégiés, moindre privilège, comptes individuels et secrets hors du dépôt. Retirez XML-RPC s’il n’est pas utilisé, limitez l’énumération d’utilisateurs REST et ajoutez des en-têtes de sécurité après validation de compatibilité.
Le CSP doit refléter les scripts, fontes, images et connexions réellement nécessaires. Un CSP décoratif trop permissif ne protège rien; un CSP trop strict non testé casse le site.
7. Détecter l’abus et préserver les preuves
Fail2ban peut bloquer les tentatives SSH répétées et les échecs d’authentification WordPress si ses expressions correspondent au format réel des journaux. Testez toujours les filtres avec fail2ban-regex avant activation.
Conservez les journaux assez longtemps pour enquêter, surveillez erreurs applicatives, changements de fichiers, disponibilité, certificats et sauvegardes. Évitez cependant de transformer la journalisation en collecte indéfinie de renseignements personnels.
8. Faire de la récupération une mesure de sécurité
Sauvegardez fichiers et base de données hors de la VM selon des objectifs de point et de temps de reprise. Chiffrez, limitez l’accès et testez une restauration. Une sauvegarde jamais restaurée est une hypothèse, pas un contrôle.
Chaque changement de sécurité doit produire un dossier horodaté, la configuration précédente et une commande de retour arrière. Vérifiez aussi les sommes de contrôle du cœur WordPress et l’intégrité des extensions connues.
Sources primaires à garder dans le runbook
Un registre de sources plus long est utile, mais la qualité vient de la traduction de ces recommandations en contrôles observables, responsables nommés et procédure de récupération.
