iThemes / Solid Security après un hack : ce qu'il ne fait pas
Durcir les connexions est utile après. Pendant l'incident, iThemes / Solid Security ajoute du bruit : 403, logs pleins, parfois un lockout de votre propre IP. Fermez l'entrée, puis seulement activez les restrictions.
Durcir les connexions est utile après. Pendant l'incident, le plugin ajoute du bruit. Fermez l'entrée, puis seulement activez les restrictions.
Ce que le plugin sait faire
Limiter les tentatives de login, bannir des IPs, masquer un peu `wp-login`, forcer SSL, parfois des checksums. C'est du durcissement. Ça n'enlève pas un shell déjà posé. Ça n'empêche pas un RCE dans un plugin d'upload.
Solid Security est le nouveau nom. Les réglages ont migré ; les habitudes « tout cocher » aussi. Tout cocher casse le site plus souvent qu'un hack.
Pendant l'incident, désactivez les banissements automatiques ou le plugin : vous vous lockoutez, l'agence aussi, parfois Googlebot. iThemes écrit dans `.htaccess` et `wp-config.php` : ces fichiers sont déjà suspects, relisez-les pour séparer les lignes du plugin des includes pirates. Masquer wp-admin n'est pas une défense et complique le diagnostic. Durcir un site encore ouvert, c'est s'enfermer dehors.
Si Solid est déjà là le jour de l'incident, exportez ses logs (tentatives, IPs bannies) avant de le désactiver : une réussite de login y figure parfois, distincte du bruit. Puis rename du dossier le temps de travailler. Réactiver tout coché en fin de journée, c'est le lockout de l'agence à 19 h.
Ce qu'il ne fait pas
Comparer un thème enfant à un zip. Lire `wp_options`. Voir le voisin de compte. Nettoyer un générateur. C'est le même angle mort que Wordfence, avec moins de signatures malware. Wordfence limites.
Solid ne compare pas un thème enfant à un zip et ne voit pas le voisin de compte. C'est le même angle mort que Wordfence, avec moins de signatures malware. Wordfence ne suffit pas.
Lockout et investigation
Vous vous banissez en testant wp-login. L'agence se banit. Googlebot se prend un 403 si vous avez été trop large. Pendant un incident, désactivez les banissements automatiques ou le plugin entier, le temps de travailler. Récupération : fichier `enable-solid-security` / rename du dossier plugin via FTP — prévoyez-le avant.
Des 404 brute force sur wp-login, iThemes les gonfle en « attaque en cours ». C'est souvent du bruit quotidien. Brute force.
Prévoyez le recovery avant de réactiver : rename du dossier plugin via FTP, ou le fichier d'urgence documenté par Solid. Pendant l'investigation, une whitelist de votre IP suffit ; un ban automatique de Googlebot crée un « site disparu » artificiel. Les 404 wp-login gonflées en « attaque » sont souvent du bruit. Brute force.
Changement d'URL wp-admin
Masquer `/wp-admin/` n'est pas une défense sérieuse (les bots ont d'autres endpoints). Après un hack, ça complique le diagnostic et les prestataires. Remettez l'URL standard le temps du clean. Ce n'est pas ça qui a ouvert la porte.
Fichiers qu'il écrit
iThemes écrit dans `.htaccess` et parfois `wp-config.php` (clés, SSL, debug). Après un incident, ces fichiers sont déjà suspects. Relisez-les : séparez les lignes iThemes des includes pirates. Ne « reset » pas wp-config sans sauvegarde. wp-config.
Un robots.txt réécrit trop large : robots.txt.
Ouvrez `.htaccess` et `wp-config.php` après avoir désactivé Solid le temps du clean. Notez les blocs `# BEGIN iThemes` / Solid. Tout include hors de ces blocs est prioritaire. Un reset wp-config sans sauvegarde casse le site et perd la preuve.
Les blocs `# BEGIN` dans .htaccess et wp-config se relisent après désactivation. Tout ce qui est hors bloc et n'est pas à vous : prioritaire. Un reset « réparer la config » du plugin peut recoller un include que vous veniez de retirer si le backup interne du plugin est sale.
L'ordre : clean puis durcir
Copie, chasse, zips, users, PHP uploads. Puis 2FA, limitation login, alertes fichiers. Inverser : vous durcissez un site encore ouvert, et vous vous enfermez dehors. Par où commencer.
Copie, chasse, zips, users, PHP uploads, puis 2FA. Inverser, c'est durcir une porte ouverte et s'enfermer. Par où commencer.
Un seul filet
Wordfence ou Solid, pas les deux en WAF. Les règles se marchent dessus. Sucuri plugin en plus : non. Sucuri.
Réglages qui valent le coup ensuite
2FA admin, ban après N échecs raisonnable, notification de changement de fichier sur `wp-config` et `mu-plugins`, désactivation de l'éditeur de fichiers (`DISALLOW_FILE_EDIT`). Pas le « hide login » comme religion.
Après le clean : 2FA, limitation login raisonnable, alertes sur `wp-config` et `mu-plugins`, `DISALLOW_FILE_EDIT`. Un seul filet, pas Solid + Wordfence en WAF. Guide WordPress, créer un espace.
Hide login, ssl, et xmlrpc
Remettez l'URL wp-admin standard le temps du clean. Masquer `/wp-admin/` n'arrête pas wp-json ni xmlrpc et perd les prestataires. Solid peut désactiver xmlrpc : faites-le après le clean si l'app ne s'en sert pas. XML-RPC.
Des `define` SSL / debug ajoutés dans wp-config : identifiez-les. `WP_DEBUG_LOG` public est un autre incident. Coupez, retirez `debug.log` du web. wp-config.
Vous n'êtes pas obligé de payer Solid Pro pour refermer. Un durcissement simple après suffit. Créer un espace.
Réactiver Solid sans se lockouter
Après le clean : 2FA, 8 essais puis ban court, alertes `wp-config` / `mu-plugins`, DISALLOW_FILE_EDIT. Pas hide login comme religion. Pas WAF Solid + Wordfence. Testez wp-login et le checkout avant de partir. Recovery FTP noté dans le gestionnaire de mots de passe.
Si vous vous bannissez : rename du dossier plugin. Les 404 brute force quotidiennes ne justifient pas de tout recocher. Brute force. Créer un espace.