Dossiers en 777 : le réglage qui a permis l'écriture
Après nettoyage, remettez 755 sur les dossiers et 644 sur les fichiers, sauf besoin réel. Le 777 « pour que ça marche » est une porte d'écriture. L'hébergeur peut vous dire le umask correct — ce n'est pas un détail de geek, c'est ce qui a permis de poser la backdoor.
Après nettoyage, remettez 755/644, sauf besoin réel. Le 777 « pour que ça marche » est une porte. L'hébergeur peut vous dire le umask correct.
Ce que 777 veut dire ici
Tout le monde (y compris d'autres utilisateurs de la machine, selon l'isolation) peut lire, écrire, exécuter/traverser. Sur un mutualisé mal isolé, le site voisin écrit chez vous. Sur un VPS, un process compromis le fait. Ce n'est pas « le pirate a un code secret 777 ». C'est vous, ou un plugin, qui avez ouvert l'écriture.
On parle de permissions Unix classiques. Windows / IIS a un équivalent (Tout le monde : modification). Même hygiène : pas d'écriture globale sur le cœur du CMS.
Les chiffres 755 / 644 sont l'usage WordPress / Prestashop documenté. Pas une superstition. Voir aussi la page backdoor : la porte *est* le fichier ; le 777 est souvent *comment* il est arrivé.
Pourquoi on l'a mis, pourquoi ça reste
Un installateur, un tuto de 2014, un support « mettez 777 sur wp-content le temps de l'upload », un umask trop large, un plugin de cache. Personne ne est revenu en arrière. L'incident le révèle. Ce n'est pas forcément une malveillance interne.
L'attaquant, lui, peut *aussi* chmod après entrée. Trouver du 777 n'identifie pas l'entrée. Ça identifie une surface. On referme, on chasse la porte quand même.
Documentez « 777 trouvé sur tels chemins » pour l'assureur et le contrat (qui avait dit de le faire).
- Souvent un geste de confort oublié.
- Parfois un geste de l'attaquant.
- Dans les deux cas : on remet juste.
La cible : qui peut écrire
L'utilisateur PHP du site (celui de l'hébergeur) doit pouvoir écrire *là où le métier écrit* : uploads, certains caches. Pas sur `wp-config.php`, pas sur tout `wp-includes`, pas sur les mu-plugins si vous n'installez rien ainsi. Un cœur inscriptible, c'est une porte posée en une requête.
Le FTP et PHP sont parfois deux utilisateurs. D'où les tutos 777. La bonne réponse est un umask / une config host (PHP tourne avec le bon uid), pas 777. Ticket : « quel est le réglage recommandé chez vous ? »
Les fichiers de config à 666 : secrets lisibles *et* réécrits. Prioritaires.
Valeurs usuelles CMS
Dossiers 755, fichiers 644. `wp-config.php` parfois 440 / 400 selon le host (le PHP doit encore le lire). Prestashop : suivez *leur* doc actuelle, pas un forum. Les écarts se justifient un par un (dossier de cache X).
Un récursif brutal `755/644` sur tout le compte est souvent le bon départ *après* copie. Puis on relâche *un* dossier si un plugin légitime ne peut plus écrire, pas l'inverse (tout en 777 puis on verra).
Les binaires et scripts doivent rester non inscriptibles au monde. L'exécution PHP dans uploads, elle, se refuse à part (article dédié).
Comment remettre sans casser
Copie. Inventaire des 777/666 (liste de chemins). Application des valeurs usuelles. Test : home, admin, upload d'une image, passage caisse. Un plugin qui hurle : on ouvre *son* dossier, on ne re-777 pas la racine.
Le gestionnaire cPanel a parfois un bouton « permissions ». Vérifiez ce qu'il fait (certains remettent 777). Préférez un geste maîtrisé ou l'hébergeur.
Windows : retirez « Users / Everyone : write » sur le code, gardez l'identité du pool sur les dossiers d'upload.
Cas particuliers (cache, uploads)
Cache : 755 suffit presque toujours. S'il exige plus, c'est souvent un malentendu uid. Uploads : écriture pour PHP, pas d'exécution. `wp-content` entier en 777 est excessif.
Les sessions PHP dans un dossier du site en 777 : déplacez-les hors web si possible. Autre surface.
Les backups zip dans un dossier 777 listable : exfiltration. Sortez-les. Sauvegardes.
Lien avec la porte et le voisin
777 + voisin = réinfection sans « faille WordPress ». Cause 4 des 48 h. Isolation host + permissions justes.
Refermer 644 et laisser le one-liner : vous avez juste rendu la *prochaine* écriture plus dure. Chassez encore.
Un cron qui `chmod 777` toutes les nuits (vieux script de deploy) : trouvez-le. Sinon votre belle soirée est annulée à 3 h.
Vérifier dans une semaine
Relistez les permissions trop ouvertes. Si elles reviennent, un script ou un humain (agence « ça marchait pas ») les a remises. Parlez-en, écrivez-le dans le contrat.
Une ligne dans le registre : « permissions ramenées à 755/644 le … ». Mesure datée.
Créer un compte si le umask host vous échappe et que chaque correctif recasse l'upload. C'est un ticket à deux (vous + host), pas une honte.
- 755/644 par défaut, écarts justifiés.
- Plus jamais « tout wp-content en 777 ».
- Revérifier : un cron peut les rouvrir.