WordPress est un CMS vraiment très pratique et complet à la fois mais on peut lui trouver aussi quelques défauts. Dans cet article je vais aborder une petite partie de la sécurité sur WordPress.
Le CMS WordPress est, à mon avis, un outil relativement mature. Il propose de nombreuses fonctionnalités et est extrêmement souple. On peut créer ses propres thèmes, ses propres plugins,… WordPress a beaucoup d’atouts pour séduire sur internet et est par conséquent utilisé par beaucoup de monde. Etant donné que ce CMS est beaucoup utilisé cela va être une cible privilégiée pour les hackers. C’est pourquoi il ne faut pas négliger l’aspect sécurité sur WordPress (et de façon globale d’ailleurs !).
WordPress est un CMS open source ce qui facilite énormément la vie des hackers, ils peuvent directement analyser le code pour trouver les éventuelles failles de sécurité.
Je pense qu’il faut être conscient du fait qu’un CMS très largement répandu s’expose à de nombreuses attaques. Au final c’est logique, quand vous lancez un site et bien vous essayez de choisir les mots clés qui vous rapporterons le plus de trafic. Pour cela vous essaierez de vous positionner sur des mots clés avec un gros volume de recherche. Et bien c’est pareil pour les hackers/pirates et compagnie, ils s’attaquent aux logiciels/applications les plus utilisés pour avoir une plus grosse force de frappe.
Une fois que l’on est conscient de ça on peut remettre en cause le choix de WordPress lorsque l’on souhaite démarrer un projet. Si on décide de lancer un réseau de site sous WordPress, autant vous dire qu’il vaut mieux trouver des outils permettant de gérer votre réseau. Parce que si vous ne mettez plus à jour vos WordPress il se peut que vous manquiez d’importante mises à jour de sécurité, et là vous vous exposez plus que jamais aux intrusions. Bref, je ne vais pas m’étendre sur l’éventuel dilemme : « WordPress ou pas WordPress ? ».
Vous l’aurez compris : les mises à jours de sécurité sont importantes et il ne faut pas les négliger. Et il faut vous méfiez des thèmes et plugins wordpress provenant de source peu fiable.
Si par mégarde vous avez un site sous WordPress que vous n’avez pas mis à jour depuis très longtemps et que vous suspectez une intrusion il faut directement allez consulter les logs du serveur.
Que faire en cas d’intrusion ?
Dans la partie qui suit je vais présenter la démarche effectuée qui a été nécessaire pour parvenir à supprimer un script malveillant qui avait été injecté.
Tout d’abord pour contextualiser un peu l’histoire j’ai du intervenir sur un WordPress qui n’était plus maintenu depuis plusieurs mois. Quand je me suis connecté sur l’administration il y avait un bon nombre de mises à jours de WordPress, de plugins, de thèmes,… Et dans le paquet de mise à jour en attente il y a fort à parier qu’il y avait une ou plusieurs mises à jour de sécurité.
Déjà la première action effectué a été la mise à jours de l’ensemble (core wordpress, plugins, thèmes). Ensuite il a fallu allez voir les logs sur le serveur voir ce qu’il se passait exactement.
En examinant les logs du site touché on voit directement d’où vient le problème. On peut voir un grand nombre de requête provenant d’IP différentes, je suis donc allez voir le script qui était appelé pour voir de quoi il s’agissait et ce n’était pas très beau à voir.
Supprimer ce fichier n’a pas suffit, évidemment le hacker avait laissé d’autres fichiers pour avoir une porte ouverte sur le site et y injecter à nouveau d’autres scripts malveillants.
Très vite après que ces scripts soient supprimés je pouvais en voir de nouveaux. C’est reparti pour faire un autre tour dans les logs et voir cette fois ci l’endroit par lequel les fichiers ont été déposés.
On peut voir beaucoup d’erreur 404 car j’avais supprimé les fichiers mais le réseau de bot continuait à venir interroger ces pages. En revanche, on voit des status 200 accédant à des pages contenus dans le dossier wp-admin avec comme user agent Windows NT 5.1 (un windows XP). Tout autant d’indice qui m’ont incité à aller voir ces fichiers. Et là j’ai bien évidemment trouvé des scripts malicieux à nouveau. Je les ai supprimés et maintenant tout roule.
En conclusion
Quand on utilise un CMS très répandu la sécurité est d’autant plus importante, alors il faut penser à faire les mises à jours. Etant donné que WordPress possède énormément de fichier si jamais vous suspectez une intrusion, les logs vous permettrons de confirmer ou non vos pressentiments.
Il manque quelques infos pour aider, et notamment comment trouver ledit fichier :
en regardant les logs d’accès courants (visiblement Apache en ce qui concerne cet article)
tail -f /var/log/apache2/[site]-access.log
(le nom de ce fichier de log est défini dans /etc/apache2/sites-available/[nomSite] en général)
une fois identifié un fichier, pour voir tout ce qui s’est fait sur ce fichier historiquement
cat /var/log/apache2/site-access.log | grep “nomdufichierInjecte”
mais il faut aussi faire un grep sur l’IP du mec qui a posté le script initialement pour voir tout ce qu’il a fait.
Il faut en préventif bien vérifier les droits sur chaque dossier, bien vérifier chaque plugin qu’on installe, surtout ceux incluant des formulaires, et installer si possible sur son serveur (si on a un dédié) fail2ban par exemple pour bloquer les attaques.
En général, si on a une attaque de type DDOS (beaucoup de requêtes vers un script en particulier), il faut rediriger tous les appels à ce fichier vers /dev/null (à voir avec votre infogérant)
Merci beaucoup d’avoir bien complété cet article.
Effectivement, il vaut mieux prévenir que guérir. Veiller à bien mettre à jour ses sites peut éviter de nombreux désagréments.
Sur mon blog j’ai aussi mis en place wp better security qui semble combler pas mal de failles utilisés par les hackers pour s’en prendre aux sites wordpress. Je pense également utiliser incapsula pour ajouter un niveau de protection suplémentaire.
Il m est arrivé sur un de mes blog wordpress que je n’ai plus mis à jour depuis un bon moment, mon blog était redirigé vers une market place pour revendre mon nom de domaine et voler mes contenus.
En analysant j’ai trouvé un bout de code en footer codé en base 64 si je retirai le code ça foutait mon site en l’air donc j’ai changé de thème tout simplement en mettant à jour wordpress.
Ce n’est pas aussi ressemblant que ton cas de hacking mais bon je voulais vous le faire partager.
C’est un gros souci effectivement avec wordpress, cela m’est arrivé une fois et c’est plutôt désagéable, j’avais trouvé une petite liste sympa pour sécuriser un peu wordpress.
http://wpchannel.com/14-astuces-securiser-site-wordpress/
mieux vaut prévenir que guérir.
Il est certain que la sécurité des sites sur WordPress est importante mais je pense que peu de webmasters s’en préoccupent tant qu’ils n’ont pas été hackés.
Maintenant, il existe plusieurs actions pour sécuriser un site sous WordPress (plugins, manipulations .htaccess…) mais je me dis qu’il est réellement difficile de fermer toutes les portes. En effet, il est ardu de vraiment savoir si tel ou tel thème ou plugin provient d’une source sûre car bien souvent, on ne connait pas l’auteur. Et puis les hackers sont généralement très forts et il suffit de fermer une porte pour qu’ils en ouvrent une autre juste à côté.
Sinon, je trouve très juste ce que vous dîtes quand vous stipulez que les hackers s’attaquent à WordPress car il est très utilisé, cela me fait penser à la différence de virus qu’il peut exister entre les plateformes Windows, Linux et Mac OS.
Oui je pense que tant que l’on ne se fait pas hacker on a peut être du mal à en prendre conscience… C’est comme pour les backups, on n’en fait pas et le jour ou le disque dur crashe on commence à en faire. En général on apprend de ses erreurs, surtout quand c’est lié a une profession…
C’est en effet dur d’être totalement sécurisé quand on ne contrôle pas tout de A à Z, si on veut du fiable il vaut surement plus se tourner vers du sur mesure.
Et c’est tout à fait pareil que pour la différence de virus entre les plateformes Windows et Mac OS… Pourquoi réfléchir à mettre au point un virus pour toucher 1000 ordinateurs quand on peut en toucher 1 000 000 si on choisit un autre système d’exploitation.
Merci pour ce témoignage, car je travaille sur la sensibilisation des utilisateurs de solutions de publication comme les CMS. WordPress est effectivement victime de son succès, mais en réfléchissant un peu aucun n’est vraiment sécurisé. Comme vous dites, c’est la popularité qui attire les hackers, et la promesse de pouvoir infecter rapidement et facilement des milliers de sites.
Et dans ce sens, le développement sur-mesure n’est pas plus fiable. Il suffit que le codeur ait pris un bout de script mal pensé, ou mal implémenté une fonction de vérification par exemple (voire pas du tout) et c’est le drame.
En général, au sein de l’association Réseau Dumac, nous préconisons un travail de nettoyage de footprint. En enlevant déjà toute mention aux solutions ou technologies utilisées, on minimise les risques de se faire repérer comme une proie potentielle 😉
Oui c’est vrai que même pour du fait maison on n’est pas à l’abri. Mais si on part du principe que si on fait du sur mesure alors on contrôle tout le développement et même si on récupère des scripts à droite et à gauche je pense qu’il vaut mieux vérifier le code avant et ne prendre dans ce code que ce qui est utile.
Après le nettoyage de footprint c’est vrai que c’est aussi important ! Encore une fois quand on cherche des spots pour poser des liens on utilise Google avec des mots clé comme “inurl:”, et ce genre de fonction marche justement à cause des footprints laissées par les CMS. Et si un CMS est vulnérable on peut très bien trouver tout ou partie des sites qui utilisent ce CMS précis via Google.
Je me suis jamais vraiment penché sur l’analyse de log et je dois bien avouer que je crois réellement que c’est un de mes plus grands tords…
Roland du SEO Camp en est un bon spécialiste et je pense qu’il y a beaucoup de choses à en tirer, plus même que le simple fait de contrer des failles de sécurité et de cleaner son CMS.
Bon ça devient complexe par contre, je suis pas trop un gars de l’ombre serveur 😀
Merci pour ce bon retour d’expérience.
Peux tu nous dire sur quoi étaient basées tes pressentiments sur le fait que le site était hacké ?
Sinon l’approche est pertinente, mais si on a backupé des version clean régulièrement, c’est pas plus rapide de remettre en place le tout dernier backup, et éventuellement remettre à jour ceux qui a évolué depuis ?
Enfin, il y a-t-il un liste de plugin non fiable, qu’il faudrait éviter d’installer pour des raisons de sécurité ? Ou alors les hackers s’attaquent également aux plugins les plus utilisés, car avec un “marché” plus important ?
Ce site était sur un kimsufi qui avait 2 ans et jusqu’à présent je n’avais pas de soucis, mais là le serveur faisait que planté. J’ai donc regardé la charge serveur et les pics n’étaient absolument pas normaux.
Alors oui les backups peuvent faire l’affaire, mais qui nous dit que les backups ne sont eux aussi pas contaminés ? Peut-être que dans les backups il y a déjà les codes malveillant mais qu’ils ne se sont activés que plus tard.
Je n’ai pas de liste de plugin non fiable à communiquer après je pense que oui les hackers visent aussi les plugins les plus utilisés
Bonjour et merci pour ton article (et pour les commentaires).
Ce n’est pas évident de sécuriser WordPress totalement ou autre chose d’ailleurs.
J’ai fait un saut sur l’article avec les 14 astuces, il y en à prendre et à laisser d’après les commentaires.
Personnellement, je fais les mises à jours de WordPress et des plugins, j’utilise Akismet, et Better WP Security ( à utiliser avec précaution, si possible essayez le sur un site test pour vous familiariser avec les paramètres ).
Je fais les thèmes, soit depuis une bonne base (genesis), soit depuis les thèmes WordPress de base.
J’évite les thèmes avec énormément (trop) de fonctions qui ne serviront jamais pour la vitesses du site principalement mais aussi pour la sécurité.
Pour le moment sur mes sites (et ceux de mes clients) pas de problème pour l’instant, on croise les doigts (pas facile pour écrire 😉 ).
Je continue ma visite sur le site …