WordPress et le danger des pages d’erreur 404

La semaine dernière, un de nos clients nous a appelé pour nous aviser que son site avait été “Hacké”, du moins c’est ce que son hébergeur lui a dit. Chez Varmédia nous n’avons pas la prétention d’être parfait, mais à force de corrigé des sites qui ont été piratés, nous avons développé une expertise à sécuriser les sites WordPress de nos clients et c’est très rare que nous ayons affaire à des sites piratés.

L’hébergeur a pris la peine de faire les mises à jour WordPress en vain, pour finalement régler le problème (selon lui encore une fois) en désactivant le “child theme” que nous avions créé. À priori, cette affirmation nous semblait étrange, mis à part quelques fichiers CSS et des “override” du thème original il n’y a pas tant de logique “corruptible” dans ce code. Mais bon c’était un fait à considérer dans notre analyse.

Comme le site de notre client était sur un serveur d’hébergement partagé sur des serveurs qui ne nous appartenait pas, nous avons commencé par rapatrier le site sur son propre serveur de sorte à premièrement isoler le site afin de nous permettre un meilleur diagnostique et deuxièmement comme le site s’emballait au point de faire “crasher” le serveur, nous ne voulions pas nuire aux autres sites de nos clients si nous l’avions rapatrié sur un serveur partagé.

Maintenant que le site est sur nos serveurs, nous procédons aux procédures habituelles de vérification d’intrusions / virus. En règle générale, nous trouvons des traces de fichiers modifiés récemment, des lignes de code contentant des “eval()”, “base64()”, des chaines de charactère encodées en Hexadecimal, etc. Car il ne faut pas se le cacher la majorité des site WordPress piratés sont utilisés pour envoyer des pourriels ou ils sont utilisés pour faire des opérations nécessitant  énormément de puissance de processeur (“hash cracking”). Le cas présent rien de ça, pas d’intrusions visible, pas de virus, pas de scripts qui utilisent le(s) processeurs directement seulement un “htop” qui nous montre nos ressources prises à 100% et quantité astronomique de bande passante qui défile sous nos yeux.

La deuxième partie de notre analyse consiste à analyser les performances de WordPress, pour se faire nous installons l’extension “WP Performance Profiler” et nous analysons les données, certaine page du site génère jusqu’à 3000 requêtes MySQL ce qui est immense, comme le mot d’ordre est de remettre le site “Live” le plus rapidement possible, voici comment nous procédons, la moitié de l’équipe se concentre sur analyser et optimiser le code actuel (on veut éliminer les requêtes en trop) et l’autre moitié se concentre sur optimiser les performances du site (Google Insights Speed test Score) à l’aide de d’extensions et d’optimisation d’images, de fichiers CSS et de fichiers JS dans le but de diminuer le stress sur le serveur.

Rendu à 23:30, nous réussissons à mettre une version fonctionnelle en ligne Yeah! Mais ça nous “bug” encore, car malgré qu’il fonctionne le site est encore lent et demande beaucoup trop de ressources pour un simple WordPress / WooCommerce avec quelques “custom post types”. Comme on dit: “Demain est un autre jour”.

Le lendemain, une partie de l’équipe continue à aller chercher des millisecondes en optimisant du code et moi je suis sur Google à chercher des pistes de solutions en vain. Rendu en après-midi, je me rends sur les Logs de KeyCDN (nous avons configuré un CDN, pour essayer de réduire le stress sur le serveur) je me rends compte que le serveur dessert quasiment autant de contenu livré avec un statut 404 que de contenu correctement livré. En regardant les fichiers qui ont des erreurs 4xx, je me rends compte qu’ils ont des caractères latins “Accents” dans leurs noms.

statut_404_graph

Bingo! Je comprends maintenant ce qu’il se passe, il y a un “wdiget” (slider) dans le pied de page qui affiche des images de produits en boucle, dans ces produits certaines images donnent des erreurs 404, comme le thème WordPress a sa propre page 404 qui elle utilise le thème WordPress (dont la fonction “get_footer()”) le résultat en chargeant le fichier avec l’erreur 404 nous chargeons à la place une page 404 générée par WordPress qui elle recharge une page 404 dans son pied de page pour nous créer une jolie fonction récursive qui n’a pas de condition d’arrêt ou ce qu’on appelle une boucle infinie…

Il nous reste qu’à régler le trouble maintenant, ce que nous faisons en deux étapes:

1) Nous commençons par créer une page 404 qui offre un contenu statique, c’est certain que notre page statique n’est pas aussi jolie et pratique que celle du thème (quoique c’est possible de faire aussi beau en investissant un peu de temps) mais il ne faut pas oublier que cette page est affichée en cas d’erreur et que le but de cette page est d’aviser l’utilisateur de cette erreur et surtout lui fournir un point de sortie (lien vers la page d’accueil).
En procédant ainsi, nous bloquons la récursion au premier niveau, nous ne venons pas le fait même de régler notre trouble au niveau du serveur.
Cette étape est assez simple il s’agit de créer ou de modifier le fichier 404.php sous le répertoire du thème actif ex: /home/user/public_html/wp-content/themes/nom-du-theme/404.php

2) Nous devons régler nos erreurs 404 à la base, pour se faire nous avons installé l’extension (plugin) “Media File Renamer” qui permet de renommer les noms de fichiers téléversés (médias) en une seul action groupée et qui ensuite fera le changement de nom  à chacun des téléversements, réglant ainsi le problème à la base pour le futur!

En conclusion, à partir de maintenant il sera part de notre procédure de création de sites sous WordPress de créer une page 404 statique et nous croyons que c’est une pratique que tous devraient adopter!

Pour références:

Les symptômes:

  1. Un site très lent;
  2. Des processus  “/usr/sbin/apache2 -k start” qui s’accumulent et qui ne se terminent jamais;
  3. Des milliers de requêtes SQL (nous les avons vus par “WP Performance Profiler”);
  4. Aucune trace, d’intrusion, de virus ou de “root kit”;
  5. Des erreurs semblables dans le error.log (niveau serveur “/var/log/apache2”):
    “[core:notice] [pid 2460] AH00051: child pid 7542 exit signal Segmentation fault (11), possible coredump in /etc/apache2”;
  6. Des erreurs semblables dans le error.log (niveau serveur “/var/log/apache2”):
    “[mpm_prefork:notice] [pid 2460] AH00171: Graceful restart requested, doing restart”;
  7. Aucune erreur dans les “error log” au niveau du compte;
  8. Une immense consommation de bande passante spontanément;
  9. Rien qui semble anormal dans les “access log”;

Les outils utilisés:

  1. KeyCDN un “Content Delivery Network”, qui fait ce qu’il prétent à un prix très abordale;
  2. WordPress Performance Profiler  extension WordPress permettant de diagnostiquer les “Bottles Neck” pour 9$ cette extension vaut vraiment le coup;
  3. Media File Renamer extension Worpress permettant de renommer les fichiers médias soit au téléversement, soit en action groupée, sincèrement le prix de la version PRO à 40$ est dispendieuse pour le peu d’options supplémentaire qu’elle ajoute.

 

Vous avez des troubles de performance avec votre site WordPress?

Chez Varmédia Inc. nous sommes experts dans l’optimisation des performances de site WordPress, nos tarifs sont concurrentiels, nos services sont garantis alors n’hésitez pas à nous joindre pour tous vos besoins d’optimisation.

 

Fév, 27, 2017

0

SHARE THIS