Sécuriser un site indépendant : pare-feu, restrictions de connexion, permissions de fichiers et analyse des malwares
1. Pare-feu : ajoutez un WAF au groupe de sécurité cloud et fermez d’abord les ports inutiles
Beaucoup croient que le pare-feu est un logiciel installé sur le serveur. En réalité, pour un site indépendant hébergé sur un cloud, la première ligne de défense est le groupe de sécurité du fournisseur cloud. Le plus grand danger est de laisser les ports 3306, 6379 et 9000 ouverts par défaut : la base de données et Redis sont alors directement exposés sur Internet, et un scanner peut les forcer en quelques minutes. La bonne méthode : n’autoriser que les ports 80 et 443 dans le groupe de sécurité, et limiter le port 22 à l’IP de sortie fixe de votre entreprise.
La deuxième ligne de défense est le WAF (pare-feu applicatif web). La version gratuite de Cloudflare suffit : elle bloque automatiquement les injections SQL, les XSS et les scanners courants. N’activez pas des règles WAF trop agressives, sinon vous bloquerez de vrais visiteurs. Commencez par le mode journalisation pendant 3 jours, puis passez en mode blocage si le taux de faux positifs est inférieur à 1 %.
| Port/service | État par défaut | État après sécurisation | Raison |
|---|---|---|---|
| 80/443 | Ouvert à 0.0.0.0/0 | Ouvert à 0.0.0.0/0 | Doit rester accessible depuis Internet |
| 22 SSH | Ouvert à 0.0.0.0/0 | Limité à l’IP fixe de l’entreprise, connexion par clé | Cible privilégiée des attaques par force brute |
| 3306 MySQL | Souvent ouvert par erreur | Autoriser uniquement 127.0.0.1 en local | Ne jamais exposer sur Internet |
| 6379 Redis | Souvent ouvert par erreur | Autoriser uniquement en local, définir un mot de passe | Un accès non autorisé permet d’y écrire une clé publique |
| 9000 PHP-FPM | Socket local | Rester en socket local, ne pas ouvrir en TCP | Aucun accès Internet nécessaire |
| 8888/Panneau Baota | Souvent exposé | Limiter par IP et changer le port par défaut | Le panneau est une cible d’attaque fréquente |
Exemple concret : un site WordPress sous panneau Baota, dont le groupe de sécurité était grand ouvert au lancement. Trois jours plus tard, le CPU du serveur montait à 100 %. En se connectant, on découvrait que le port 3306 était attaqué par force brute depuis des IP étrangères, et que les logs MySQL débordaient d’échecs de connexion. Après avoir limité le groupe de sécurité aux ports 80/443 et le port 22 à l’IP de l’entreprise, le CPU est retombé immédiatement à 5 %. Cet incident se règle en 10 minutes, mais la plupart des gens ne regardent même pas le groupe de sécurité au lancement.
Comment configurer les règles WAF : même logique que l’anti-spam des formulaires de contact: d’abord journaliser et observer, ensuite bloquer. Ne bloquez pas toutes les requêtes suspectes dès le départ.
2. Limiter les connexions : verrouiller la porte d’entrée des attaques par force brute
Sur WordPress, wp-admin est la première porte d’entrée des pirates sur un site indépendant. Nom d’utilisateur admin par défaut, mot de passe simple, page de connexion accessible publiquement : un scanner parcourt tout un dictionnaire en quelques heures. Contre-intuitif, mais vrai : installer une extension de limitation des connexions est plus efficace que n’importe quel produit de scan de sécurité, car la grande majorité des attaques par force brute n’atteignent jamais l’étape d’exploitation d’une faille : elles sont bloquées dès la page de connexion.
Le trio gagnant pour limiter les connexions : verrouillage 30 minutes après 5 échecs, changement du chemin de connexion par défaut (/wp-admin remplacé par une chaîne aléatoire), 2FA obligatoire. Mot de passe d’au moins 16 caractères, généré par un gestionnaire de mots de passe, jamais un mot suivi de chiffres. Idem pour SSH : désactivez l’authentification par mot de passe et n’autorisez que les clés.
| Paramètre | Valeur par défaut | Valeur de durcissement | Outil/mise en œuvre |
|---|---|---|---|
| Verrouillage après échecs | Illimité | Verrouillage 30 min après 5 échecs | Wordfence ou fail2ban personnalisé |
| Chemin de connexion | /wp-admin | Chaîne aléatoire type /login-7f3k | Extension WPS Hide Login |
| Authentification à deux facteurs | Non | 2FA TOTP obligatoire | Wordfence ou Two Factor |
| Longueur du mot de passe | 6 caractères | ≥ 16 caractères aléatoires | Généré par gestionnaire de mots de passe |
| Authentification SSH | Connexion par mot de passe | Clés uniquement, mot de passe désactivé | sshd_config : mettre PasswordAuthentication no |
| Utilisateur de base de données | root à distance | Utilisateur dédié, accès local uniquement | Créer un compte MySQL distinct |
Exemple concret : un SaaS à l’international, page de connexion admin sur /secret-admin, 2FA activée, verrouillage 30 minutes après 5 échecs. Les logs montrent environ 2 000 tentatives de connexion par semaine depuis des IP étrangères, toutes bloquées, aucune réussie. Sans limitation, avec une force de mot de passe moyenne, la probabilité de succès d’une attaque par credential stuffing dépasserait 30 % en 3 mois.
Pour la stratégie globale de choix des extensions et de la stack technique, voir les quatre extensions maison de la stack crater.
3. Permissions de fichiers : empêcher l’exécution des fichiers malveillants téléversés
Les permissions de fichiers sont une couche que beaucoup négligent. Après un piratage WordPress, l’attaquant téléverse généralement un webshell PHP dans wp-content/uploads. Si le dossier uploads autorise l’exécution de PHP, ce webshell prend immédiatement le contrôle du site ; s’il l’interdit, l’attaquant a beau le téléverser, il ne s’exécute pas et reste impuissant.
Les permissions standard : dossiers en 755, fichiers en 644, wp-config.php en 400 (lisible par le propriétaire uniquement). Ne mettez pas tout en 777 par facilité, c’est comme laisser la clé sur la porte. Dans la configuration nginx, ajoutez une règle au dossier uploads pour interdire l’exécution des fichiers .php, .phtml, .php5, etc.
| Approche | Permission | Propriétaire | Explication |
|---|---|---|---|
| Racine du site | 755 | www-data:www-data | Ne pas mettre 777 |
| wp-config.php | 400 | root | Illisible par le processus web |
| wp-content/themes | 755 | www-data | Droits d’écriture nécessaires aux mises à jour automatiques |
| wp-content/uploads | 755 | www-data | Exécution PHP interdite |
| wp-content/plugins | 755 | www-data | Écriture nécessaire aux mises à jour d’extensions |
| Dossier .git | Ne pas l’exposer sur le web | — | L’exposer divulguerait le code source |
Autre cause fréquente de piratage : les fichiers de sauvegarde de la base de données stockés directement dans le répertoire web. Beaucoup de plugins de sauvegarde enregistrent par défaut le .sql.gz dans wp-content/backup/, et un attaquant qui tombe dessus le télécharge et récupère toutes les données du site. La bonne pratique : placer les sauvegardes en dehors de la racine web, ou les envoyer automatiquement vers un stockage objet après la sauvegarde et supprimer la copie locale. Voir la stratégie de sauvegarde dans Sauvegarde et restauration : s’entraîner à réagir.
4. Scans malveillants et correctifs : une fois par semaine, corriger sous 7 jours
Un scan malveillant ne se fait pas seulement après avoir été piraté. Lancez chaque semaine une comparaison de hachage des fichiers du cœur : si les fichiers du cœur WordPress ne correspondent pas aux hachages de la version connue, c’est qu’ils ont été modifiés. Les mises à jour des extensions et des thèmes doivent être faites sous 7 jours : entre la divulgation d’une faille publique et son exploitation par des scanners automatisés, la fenêtre moyenne est de 14 jours, donc corriger sous 7 jours permet d’éviter la majorité des attaques.
Il existe trois types d’outils de scan : les extensions comme Wordfence détectent les signatures de webshell connues ; ClamAV effectue une analyse antivirus au niveau du serveur ; l’analyse des logs serveur révèle des schémas d’accès anormaux. Utilisez-les ensemble, ne comptez pas sur un seul outil pour tout couvrir. Pour la méthode d’analyse des logs de robots IA, voir Analyse des logs de crawlers IA, la même méthode d’analyse des logs permet de détecter les scanners malveillants.
| Point de contrôle | Fréquence | Outil | Traitement des anomalies |
|---|---|---|---|
| Comparaison de hachage des fichiers du cœur | Chaque semaine | Intégrité du cœur via Wordfence | Écart détecté, restaurer depuis une version propre |
| Mises à jour des extensions et thèmes | Chaque lundi | Back-office WP + logs | Mise à jour obligatoire sous 7 jours |
| Scan de webshell | Chaque semaine | ClamAV ou Wordfence | Isoler et supprimer les fichiers malveillants |
| Connexions suspectes | Chaque jour | Logs fail2ban | Bloquer automatiquement les IP attaquantes |
| Fichiers récemment modifiés dans le répertoire web | Chaque semaine | find -mtime -7 | Modification inattendue : vérifier immédiatement |
| Écritures anormales en base de données | Chaque semaine | Contenu base64 dans wp_posts | Nettoyer le code eval caché |
Rappel contre-intuitif : après un piratage, ne vous précipitez pas pour nettoyer en ligne. Le problème du nettoyage en ligne, c’est que les webshells et les tâches cron cachés dans la base de données ne sont jamais complètement supprimés, et l’infection revient deux semaines plus tard. La bonne procédure : couper l’accès public au site, restaurer depuis la dernière sauvegarde propre, changer tous les mots de passe et clés, vérifier les résidus dans les tâches cron et la base de données, puis remettre le site en ligne. Pour la procédure complète après un piratage, voir Nettoyage et réindexation après un piratage de site.
Pour la liste de contrôle quotidienne, voir Les six tâches mensuelles de la maintenance d’un site, intégrez-y le renforcement de la sécurité. Pour savoir comment définir les seuils d’alerte, voir Surveillance et alertes du site.
FAQ — Questions fréquentes
Votre site e-commerce a été piraté : que faire en premier ?
Faut-il acheter un WAF payant, ou la version gratuite de Cloudflare suffit-elle ?
À quelle fréquence mettre à jour les extensions WordPress, et les mises à jour automatiques sont-elles sûres ?
Comment définir les permissions de wp-config.php et du dossier uploads ?
Faut-il changer le port SSH par défaut 22, et peut-on garder la connexion par mot de passe ?
Comment détecter qu’un site a été piraté, y a-t-il des signes avant-coureurs ?
Pour conclure
En matière de sécurisation, le plus coûteux n’est pas l’outil, c’est l’état d’esprit du “ça devrait aller”. Un site indépendant n’est pas une banque, mais c’est votre porte d’entrée pour les demandes de devis : s’il est piraté ou tombe en panne, vous perdez de vrais prospects. Les quatre couches de défense n’ont pas besoin d’être déployées d’un coup, mais il faut suivre l’ordre : d’abord fermer les ports, puis limiter les connexions, puis ajuster les permissions de fichiers, et enfin lancer l’analyse. Les trois premières étapes se font en un après-midi, avec le meilleur retour sur investissement.
Trois étapes concrètes : premièrement, connectez-vous au groupe de sécurité cloud et fermez les ports 3306, 6379 et 8888 qui ne devraient pas être exposés sur Internet, en limitant SSH à l’IP de l’entreprise ; deuxièmement, changez le chemin de wp-admin, activez la 2FA, verrouillez après 5 échecs et passez SSH en connexion par clé ; troisièmement, lancez une fois par semaine à heure fixe un contrôle de hachage des fichiers principaux et une mise à jour des extensions. Ces trois étapes faites, vous bloquez déjà 80 % des attaques courantes.
Une phrase à retenir : un site indépendant est rarement piraté par un hacker de génie, mais souvent à cause d’un mot de passe faible, d’une extension non mise à jour ou d’une sauvegarde de base de données exposée. Boucher ces trois entrées est plus efficace que d’acheter n’importe quel produit de sécurité.