DISALLOW_FILE_EDIT Activé mais toujours manipulé ? Les causes les plus courantes des privilèges et des vulnérabilités + solutions de dépannage et de renforcement détaillées

ouvre disallow_file_edit Si le message "Theme/plugin files have been changed, code inserted" apparaît toujours, ce n'est peut-être pas parce que le commutateur ne fonctionne pas, mais parce que l'optionLa falsification se produit "en dehors de l'éditeur".Les permissions des fichiers du serveur, le panel/FTP, le vol de compte, les vulnérabilités des plug-ins, les portes dérobées implantées, etc. peuvent directement modifier le fichier.

1) Mettons les choses au clair : qu'est-ce que DISALLOW_FILE_EDIT peut seulement bloquer ?

disallow_file_edit ne désactivera que le WordPress coulissesEditeur de fichiers apparence/plugin(Editeur de thème/plugin).
ilne sera pas (n'agira pas, n'arrivera pas, etc.)Mettez fin aux comportements suivants :

• faire passer (un projet de loi, une inspection, etc.) Gestionnaire de fichiers FTP/SFTP/SSH/PanelChangement direct de fichier
• Le code malveillant est stocké sur le serveur en tant que Permissions de processus PHPEcriture/réécriture de fichiers
• Téléchargement du webshell, écriture wp-content/uploadsetmu-plugins et al. (et autres auteurs)
• Modification des fichiers par le mécanisme de "mise à jour/installation" (cela nécessite un autre commutateur).DISALLOW_FILE_MODS)

C'est donc ce qu'indique l'expression "toujours falsifié" :Votre site ou votre serveur dispose encore d'entrées accessibles en écriture.

(2) Les neuf types de causes les plus courantes

2.1 Autorisations excessives du système de fichiers / erreurs de propriétaire (les plus courantes)

• wp-content/les répertoires de thèmes et les répertoires de plugins ne sont pas disponibles pour les utilisateurs du Web (par exemple, l'application www-data) est accessible en écriture, un PHP malveillant peut modifier le fichier une fois qu'il a atterri.
• Performance typique : insertion répétée du même paragraphe eval/base64/gzinflateVous l'avez supprimé et êtes revenu quelques heures plus tard.

2.2 Compte d'administrateur WordPress ou cookie volé

• Comptes supprimés, mots de passe faibles, mots de passe réutilisés, pas de 2FA
• Vol de cookies par des extensions de navigateur avec des "plugins/injection scripts usurpés".

2.3 Fuite de comptes FTP/SFTP/Panel

• Pagoda/1Panel/cPanel Fuite de login ou mots de passe faibles
• Interception des transferts FTP en clair (en particulier les anciens FTP)

2.4 Il existe des vulnérabilités à haut risque dans les plugins/thèmes (téléchargement, désérialisation, RCE, écriture de fichiers arbitraires).

• Représentation :téléchargements se produisant à l'intérieur .phpetphtmldes images bizarrement nommées (en fait PHP)
• Ou des fichiers "que vous n'avez jamais installés" dans le répertoire des plugins.

2.5 Portes dérobées persistantes : mu-plugins / drop-in / tâches automatisées

Regard ciblé :

• wp-content/mu-plugins/
• wp-content/plugins/ Il est déguisé en plug-in système.
• wp-content/advanced-cache.phpetobject-cache.php accueil
• wp-cron Ecriture et restauration temporisées de codes malveillants

2.6 Injection de base de données : scripts cachés dans les tables d'options/widgets/contenu des articles

• wp_options(autoload) bourré de JS malveillants.
• Module de construction de pages et de widgets intégré <script>(On dirait que le fichier n'a pas été modifié mais que la page a été détournée).

2.7 Le niveau du serveur a été mis hors service (infection latérale d'autres sites/hôtes partagés sur la même machine).

• Plusieurs stations sur le même hôte, tant qu'une station est compromise, elle peut affecter d'autres stations par le biais de problèmes de configuration des permissions.

2.8 Cache/CDN considéré à tort comme "encore altéré".

• Vous avez corrigé les fichiers sources, mais le CDN/cache continue de recracher du vieux contenu.
  (Il est recommandé de vérifier d'abord "si le hachage du fichier source a été modifié à nouveau" afin d'éviter toute erreur d'appréciation).

2.9 Liens développement/déploiement conduisant à des "dérogations automatiques".

• Git/CI, Scripts de synchronisation, Tâches de sauvegarde et de restauration pour écraser les anciens fichiers (y compris les fichiers malveillants) et les réintégrer.

3) Comment identifier rapidement : qui change réellement ? Qu'est-ce qui a changé ?

Les faire dans l'ordre permet de distinguer les erreurs judiciaires des "infections récurrentes" :

3.1 Confirmer d'abord si le fichier est réellement modifié ou s'il est mis en cache

• Enregistrement des documents falsifiésHeure de modification mtimeavechachage (informatique)
• Attendre 30 à 60 minutes et voir s'il y a un changement.

Si le hachage change : le fichier est effectivement modifié ; s'il ne change pas mais que la page est anormale : il s'agit probablement d'une injection de cache ou de base de données ou d'un détournement d'interface.

3.2 Effectuer un contrôle d'intégrité (localiser les "documents qui n'auraient pas dû être modifiés mais qui l'ont été")

• WordPress Core : vérifier que le document de base n'a pas été remplacé
• Plugins/thèmes : comparer avec le paquetage officiel ou retélécharger

3.3 Vérifier les fichiers "récemment ajoutés/récemment modifiés" (moyen le plus rapide de détecter les portes dérobées)

Catalogue ciblé :

• wp-content/uploads/
• wp-content/mu-plugins/
• wp-includes/etwp-admin/(Soyez attentifs aux fichiers inconnus dans le répertoire principal)
• Si le répertoire racine est nommé aléatoirement PHP

Dépannage commun de Linux (exemple)

# php fichiers modifiés dans les 3 derniers jours (par nombre de jours nécessaires)
find . -type f -nom "*.php" -mtime -3 -print

# téléchargements avec php ne fonctionnant pas en principe
find wp-content/uploads -type f \N( -nom "*.php" -o -nom "*.phtml" -o -nom "*.phar" \N) -print

# Recherche rapide de caractéristiques communes prêtant à confusion (pas de condamnation, juste des indices)
grep -R --numéro de ligne -E "base64_decode|gzinflate|str_rot13|eval\(|assert(" wp-content | head

4) Taux de réussite élevé du processus de réparation

4.1 Arrêter immédiatement le saignement

1. Activer temporairement les pages de maintenance / restreindre les connexions au backend (liste blanche d'adresses IP ou authentification de base)
2. Changement immédiat : mot de passe de l'administrateur WP, mot de passe de la base de données, mot de passe du panel, mot de passe SFTP/SSH, toutes les clés API
3. Obliger tous les administrateurs à se reconnecter (changement de mot de passe + cookie désactivé)

4.2 Dégagement de la porte arrière

• supprimer téléchargements Tous les scripts exécutables dans les téléchargements (principe : les téléchargements ne doivent pas être en PHP).
• Inspection et nettoyage mu-pluginsLe fichier, drop-in file (si vous n'êtes pas sûr de la source, sauvegardez-la et retirez-la pour validation)
• nom Zha wp-cronLes tâches de rédaction et d'extraction de scripts à distance sont chronométrées ou non.

4.3 Rechargement de confiance

• récupérer WordPress Document de base（Ne bougez pas. wp-config.php répondre en chantant wp-content (médias)
• Plugins et thèmes : réinstallation uniquement à partir de sources fiables.Ne pas conserver les anciennes archives/anciens répertoires

4.4 Modification de l'autorité

Ligne de base recommandée (pensées génériques) :

• Catalogue :755
• Documentation :644
• wp-config.php: Plus serré (par exemple 600/640(Vérifiez l'utilisateur et le groupe sous lesquels vous travaillez)
• Veillez à ce que l'utilisateur qui gère le site web n'ait pas accès en écriture à l'ensemble du site, du moins pas au répertoire principal.

4.5 Désactivation des téléchargements

• Désactivation de la configuration de Nginx/Apache wp-content/uploads Exécution de PHP
• Cette étape permet de couper court à une grande partie de la chaîne d'attaque "télécharger et exécuter".

5) Recommandations en matière de renforcement (rendre la "manipulation" difficile à la racine)

• ouvre DISALLOW_FILE_MODS(empêche l'installation/la mise à jour des fichiers en arrière-plan, réduit la surface d'écriture) : ne convient que si vous disposez d'un processus de déploiement discipliné (Git/CI).
• Activer 2FA, limiter les tentatives de connexion, modifier le chemin de connexion par défaut (mieux avec WAF)
• Désactiver XML-RPC (ou le limiter)
• Mise à jour régulière : WP core/plugins/themes (plus la fenêtre de vulnérabilité est courte, mieux c'est)
• Sur le WAF (plugin Cloudflare/WAF/protection de l'hôte), blocage des exploits RCE/upload les plus courants.
• Surveillance de l'intégrité des fichiers : alertes en cas de modification des fichiers (gain de temps considérable par rapport à un dépannage a posteriori).

6) Quand dois-je "reconstruire les serveurs/migration complète" ?

Si l'une des situations suivantes se produit, il est recommandé de réinstaller le système ou de migrer vers un environnement propre, puis de recommencer à partir de l'écran d'accueil.Sauvegarde de confianceRécupération :

• Vous avez trouvé le webshell et vous ne pouvez pas déterminer l'heure de l'intrusion.
• Multiples connexions anormales au compte/panel du serveur
• Le répertoire core est modifié à plusieurs reprises et vous avez nettoyé le thème du plugin, mais il continue de renvoyer l'information.

Contactez nous
Vous n'arrivez pas à lire le tutoriel ? Contactez-nous pour une réponse gratuite ! Aide gratuite pour les sites personnels et les sites de petites entreprises !	Service clientèle WeChat
① Tel : 020-2206-9892
② QQ咨询：1025174874
(iii) Courriel : [email protected]
④ Horaires de travail : du lundi au vendredi, de 9h30 à 18h30, jours fériés.