.htaccess modifié sans vous : redirections, PHP et spam

Ce que WordPress y met vraiment

Le bloc `# BEGIN WordPress` … `# END WordPress` : réécriture vers `index.php`. C'est légitime. Un thème ou Yoast y ajoute parfois des en-têtes. Au-delà, tout `RewriteRule` vers un domaine tiers, tout `php_value`, tout `Auto prepend` est suspect jusqu'à preuve d'un dev nommé.

PrestaShop, Joomla, Drupal ont leurs blocs. La même règle : connaître le stock, isoler le surplus. Vider le fichier « pour tester » vous coûte les permaliens et, sur certains hôtes, tout le routage.

Nginx n'utilise pas `.htaccess`. Si votre site est en Nginx, le fichier peut être un reste Apache ou un leurre. La redirection vit alors dans le vhost. Ne passez pas deux heures sur un fichier mort.

Sauvegarder le fichier actuel, même sale

Téléchargez-le. Date, contenu. C'est la preuve de la redirection que vos clients ont vue. Le remplacer tout de suite par un modèle internet vous fait perdre les règles légitimes (HTTPS, www, cache) et la preuve.

Si le site est déjà en 500, le `.htaccess` est le premier suspect, pas le seul (`wp-config` syntaxe, quota). Renommez-le en `.htaccess.bak` : si le site revient, vous tenez le coupable. Puis vous réintroduisez le bloc WordPress propre, pas tout le bak.

Les copies automatiques (Updraft, cPanel) ont souvent déjà le fichier sale. Remonter « la dernière » replace la règle. Remontez plus loin, ou reconstituez le bloc officiel.

• Télécharger le `.htaccess` actuel.
• En 500 : renommer, tester, réinjecter le bloc CMS.
• Ne pas coller un tutoriel générique qui casse HTTPS.

Repérer les lignes qui ne devraient pas être là

`RewriteRule` vers `http://` un domaine de pharma, `ErrorDocument 404` vers un PHP inconnu, `<Files>` qui autorise `radio.php`, `php_flag engine` dans un dossier médias, `SetHandler application/x-httpd-php` sur des `.jpg`. Ces motifs reviennent. Un `RewriteCond %{HTTP_USER_AGENT}` Googlebot est du cloaking : voir cloaking Googlebot.

`php_value auto_prepend_file` ou `auto_append_file` : chaque page PHP charge un autre fichier. C'est une porte élégante. Notez le chemin cité, copiez ce fichier aussi.

Les encodages bizarres, les espaces en trop, un `RewriteEngine` deux fois : parfois c'est un merge raté de plugin, pas un pirate. Le critère reste : est-ce que ça redirige ou exécute hors métier ?

Redirections : visiteurs, Google, admin

Une règle peut ne viser que le mobile, que Googlebot, que les non-connectés. Vous, en admin sur desktop, ne voyez rien. Testez téléphone, navigation privée, clic depuis `site:`. C'est le même réflexe que pour site qui redirige.

`wp-admin` redirigé : l'attaquant vous empêche de rentrer. Passez par SFTP, pas par « je réinstalle ». Voir wp-admin redirige.

Une redirection 301 indexée par Google survit au fichier propre : l'index garde la cible un temps. Inspection d'URL + demande de réindexation des pages clés. Ce n'est pas Safe Browsing sauf page dangereuse encore en 200.

PHP handler et exécution dans uploads

Forcer PHP sur `.jpg` ou retirer `php_flag engine off` dans `uploads` : les doubles extensions deviennent des shells. Après incident, le correctif le moins cher est d'interdire l'exécution dans les médias. Voir interdire PHP dans uploads.

Un `.user.ini` à côté fait le même travail qu'un `.htaccess` `auto_prepend` sur certains hôtes PHP-FPM. Lisez les deux. Beaucoup de « j'ai nettoyé htaccess » laissent le `.user.ini`.

LiteSpeed a des règles spécifiques. Un bloc LiteSpeed pirate se mélange au cache légitime. Isolez avec les commentaires `# BEGIN`.

Erreur 500 : une règle mal formée

Une `RewriteRule` cassée, un `</IfModule>` en trop, un caractère Windows dans le fichier : 500 sur tout le site. L'attaquant n'a pas forcément voulu ça ; un plugin cleaner a pu tronquer. Le error.log Apache dit souvent « rewrite » ou « htaccess ».

Remettre un `.htaccess` minimal (bloc CMS + HTTPS si vous savez le coller) rétablit. Puis vous reajoutez cache et sécurité une ligne à la fois. Coller 80 lignes d'un forum « htaccess sécurisé » recrée le 500.

Si le 500 reste sans `.htaccess`, le problème est ailleurs : PHP fatal, quota, `wp-config`. Ne restez pas sur ce fichier par obstination.

Plusieurs `.htaccess`, pas un seul

Racine, `wp-admin`, `uploads`, un dossier aléatoire : chacun peut rediriger ou autoriser PHP. Nettoyer la racine et laisser `uploads/.htaccess` en `SetHandler` PHP, le kit survit. Cherchez `htaccess` en récursif (gestionnaire « rechercher », ou `find`).

Un dossier de phishing apporte souvent son propre fichier : interdire le listing, réécrire vers `index.html`. C'est un indice pour trouver le kit. Voir dossier aléatoire.

Les sous-domaines et addon domains ont leur propre racine. Un `.htaccess` propre sur `www` et sale sur `old.` explique « moi je vois rien ».

Qui le réécrit : plugin, cron, shell

WordPress réécrit le bloc BEGIN/END à chaque changement de permaliens. Un plugin SEO aussi. Un cron ou un shell réécrit tout le fichier. Si votre version propre ne tient pas 24 h, listez cron et PHP à la racine. C'est le motif « ça revient » n°1 sur ce fichier.

Un mu-plugin de trois lignes `file_put_contents(__DIR__ . '/../../.htaccess')` suffit. Ouvrez `mu-plugins` systématiquement dans ce dossier.

Permissions : un `.htaccess` en 777 invite l'écriture. 644 après nettoyage. Le propriétaire du fichier doit rester l'utilisateur FTP/PHP du site, sinon le CMS ne pourra plus mettre à jour les permaliens — et un technicien pressé remettra 777.

Refermer sans casser les URL

Bloc CMS officiel, HTTPS si déjà en place, interdiction PHP dans uploads, pas de rewrite vers un tiers. Testez home, un article, wp-admin, une image. Puis mobile et `site:`.

Si Chrome affichait une redirection dangereuse, déposez le réexamen après ces tests. Délai Safe Browsing souvent 24 à 72 h. Un `.htaccess` propre et une URL de kit encore en 200 : refus.

Vous pouvez déclarer le site. En attendant : copie du fichier, isolation des lignes, panel. Ne videz pas.

• Copie + isolation des lignes pirates.
• Tous les `.htaccess` du compte.
• `.user.ini` relu.
• Contrôle réécriture à J+1.