Ce coup d'oeil est consacré non pas à un site mais à toute une famille, les sites développés sous Wordpress et à un sujet dont on parle peu, la sécurité de ces sites.
Les exemples décrits ci-dessous sont des cas concrets, observés sur des sites que nous avons développés et pour lesquels des parades ont été apportées. Seuls les noms des sites ont été enlevés pour respecter la confidentialité des dossiers.
Un environnement performant souvent attaqué
Les sites développés avec un même CMS ont comme caractéristiques d'avoir tous la même structure informatique de base, bien connue de la communauté des développeurs mais aussi de celle des hackers et autres petits malins envers qui nous ne nourrissons aucune sympathie... ce qui fait qu'ils sont régulièrement attaqués et souvent avec succès.
Restons modestes, la grande majorité des sites ne présente aucun intérêt stratégique, les hackers se contentent "simplement" d'investir les sites pour y installer des bases d'envoi d'e-mails, des pages de liens, arrivant ainsi à détourner à leur profit un patient travail de référencement. Les cas d'attaques dans le but de nuire à une entreprise en particulier restent très exceptionnels.
Attaque d'un e-commerce
La librairie en ligne XY a été attaquée durant le mois d'août pour y installer quelques dizaines de liens en partie basse de la page d'accueil, écrits en blanc sur fond blanc. Détectée avec quelques jours de retard, cette attaque avait eu le temps de prendre toute son ampleur, modifiant sensiblement les résultats de l'indexation par Google.
Parades mises en oeuvre
- recherche du "point d'entrée" dans le site et sécurisation de celui-ci.
- nettoyage de tous les fichiers altérés par le hacker.
- modification de la structure d'accès à l'administration du site
- supression d'une fonction réputée fragile dans Wordpress
Attaque d'un site vitrine
Le site (purement institutionnel) YX a été attaqué à plusieurs reprises sans que nous ayons pu en déterminer les raisons dans la mesure où l'hébergeur du site protège son installation en mettant le site hors service immédiatement. Pour efficace qu'elle soit pour les installations de l'hébergeur, cette supression rend extrêmement difficile l'analyse de la situation et la mise en place des parades efficaces. On est alors obligés d'agir à l'aveuglette.
Parades mises en oeuvre
- restauration d'une version antérieure à l'attaque et restauration d'une version saine à partir des sauvegardes de l'hébergeur.
- installations des protections classiques (voir cas précédent)
Les modules à connaître
- Wordfence, un module de sécurité qui a le grand mérite de lancer des alertes en cas d'activité "anormale" sur un site.
- Move login qui permet de modifier l'accès à l'interface d'administration
- ce n'est pas un module mais citons tout de même la supression du fichier xmlrpc (utilisé pour des publications distantes dans les sites) et qui est un point d'entrée classique des hackers.
D'autres points ne doivent pas être négligés dans la mise en place d'une politique de sécurité, notamment le choix de l'hébergeur.
Pour gagner quelques sous, certains choisissent des hébergeurs low cost qui donnent satisfaction tant que tout se passe bien mais qui avouent rapidement leurs limites dés qu'un incident survient. Les soucis commencent avec un contact technique souvent réduit à une plate-forme joignable par mail quand ce n'est pas un principe de précaution appliqué à la lettre qui met le site attaqué hors d'accès et qui laisse l'entreprise victime fort démunie. A méditer au moment du choix du prestataire.
ndlr: les communautés de développeurs ont en commun de disposer d'une bonne dose de second degré dans leur travail et ce n'est pas le choix de l'image de la caravane effectué par Move login qui nous démentira...
La sélection du prestataire
La prudence est de mise et les exemples précédents montrent tout l'intérêt à choisir un prestataire sur et experimenté... il ne sera pas forcément toujours le moins cher, le tout etant de savoir ce que l'on veut !
