Prévenir le piratage de son site est un impératif dans l’internet actuel. Un de mes amis affirme qu' »il n’y a pas de piratage, que du mauvais développement« . Le maintien à niveau des règles de sécurité est une chose primordiale à effectuer dès l’installation de son WordPress.
De nombreux outils permettent d’aider à l’amélioration de la sécurité, mais la première des opérations reste envers et contre tout le mot de passe. Je suis encore tombé récemment sur un client dont l’identifiant était « admin ». Autant vous dire que son blog s’était transformé en lieu de rencontre pour hackers chinois et coréens (je les imagine en train de prendre le thé ensemble, dans le dossier wp-includes, tout en envoyant des cookies malveillants aux visiteurs).
Un bon code, il tire. Un mauvais code, il tire, mais c’est pas pareil
Un bon mot de passe, c’est comme un bon identifiant : on doit utiliser des chiffres, des lettres, et des caractères spéciaux. Beaucoup se plaignent qu’ils ont du mal à les retenir, mais c’est là une fausse excuse, car il est tout à fait possible de saisir un mot de passe à la fois simple et sécurisé. L’idée est d’écrire en « leet », c’est-à-dire en remplaçant certaines lettres par des chiffres ou des symboles. Ainsi, cyrilchalamon pourrait s’écrire cyri!ch@!@m0n. Ici j’ai donc simplement remplacé les L par des !, les a par des @, et les O par des 0 (inutile d’essayer, faudrait pas croire que je suis bête au point de mettre mon identifiant sur mon blog ^_^ )
Si vous faites de même avec votre mot de passe, le niveau de sécurité sera déjà à un niveau correct, mais ce n’est pas encore suffisant.
Un admin toujours identique ?
Le gros souci de WordPress, c’est que l’administration du site est facilement repérable grâce à l’URL. Pas besoin d’être sorcier donc pour se rendre sur une interface de connexion, et de lancer un script de décryptage. Certains même effectuent des tests de sécurité directement « à la main », en tapant derrière leur ordinateur les mots admin, administrator, test, toto, titi, tutu, et j’en passe des vertes et des pas mûres, comme vous pouvez le constater sur l’image ci-contre.
Mon site est régulièrement testé par des petits malins, dont je note l’IP systématiquement afin d’améliorer ma blacklist personnelle (que vous pouvez retrouvez ici). Pour repérer les tentatives de connexion frauduleuses, j’utilise entre autres le plugin Limit Login Attempts, qui permet d’ajouter des règles de bannissement pour tout mot de passe ou identifiant erroné. Il est ainsi possible de bloquer des IP selon une durée plus ou moins longue, en fonction de ce que vous estimez être sécuritaire.
Voici donc mes réglages :
En effet, je n’ai pas intérêt à me rater… Encore que les accès au FTP et/ou à la base de données me permettent de rectifier le tir en cas d’erreur.
Une fois que les fautifs sont repérés, hop ! direction blacklist de mon htaccess (en fonction de l’IP utilisée, bien entendu). Le « deny from » reste une bonne arme pour prévenir de toute intrusion non souhaitée.
« Quel est le risque encouru si mon site n’est pas surveillé régulièrement, et que mon mot de passe est peu sécurisé ? » Je peux citer deux exemples, un pas très grave et un autre qui a failli se révéler dramatique.
Ce user « admin »
Un de mes clients n’a pas utilisé un mot de passe suffisamment complexe. Le hacker est donc entré dans le site, et a ajouté du code html dans les articles et pages. Cela donnait un truc du genre « buy some Viagra »… Bref, du spam en veux-tu en voilà. En modifiant les codes accès, tout simplement, le problème a été résolu et ne s’est plus jamais reproduit. Pour anecdote, le code html était écrit en blanc, donc quasi-invisible en back-office, mais tellement voyant en front-office (surtout quand le fond est plutôt sombre)
Mon deuxième exemple est plutôt récent. Une cliente avait « admin » pour identifiant, et seulement quatre lettres en guise de mot de passe. L’image ci-dessous vous décrira mon comportement lorsque j’ai découvert cela :
Autant vous dire qu’il y avait plus de 22 000 abonnés, pour la plupart uniquement pour du spam. Le (ou les) hackers avaient en plus ajouté six fichiers php dans les dossiers de WordPress, qui écrivaient directement dans TOUS les fichiers javascript des dossiers wp-content et wp-includes. Chaque visiteur sur le site avait ainsi le malheur de recevoir des cookies malveillants, et par-dessus le marché chaque fois qu’un nouveau fichier javascript était mis sur le site, les fichiers php se chargeaient de le véroler. Google – au bout d’un moment – l’a détecté et a carrément bloqué l’accès au site, alors qu’on démarrait une campagne Adwords. Pour les personnes en charge du webmarketing c’était plutôt la panique ! Le problème a été identifié et résolu, mais le temps que les moteurs se décident à autoriser l’accès au site, une journée entière s’est passée… Veni, vidi, vici !
Au passage, le site était indisponible avec Firefox, Chrome, mais aucun problème avec Internet Explorer, ce qui en dit encore une fois très long sur la sécurité de ce « navigateur » (mais c’est plus un sous-marin qu’autre chose !)
Bref, par pitié, sécurisez vos codes d’accès, je ne le répéterai jamais assez ! Et j’en profite pour re-citer ma loi du web :
« Le problème est régulièrement entre la chaise et le clavier ! »
Ha oui, et j’en suis à 3534 blocages à l’heure actuelle, ma blacklist va être plus épaisse qu’une encyclopédie de médecine à force 😀
Vous pouvez également sécuriser l’accès au back-office de votre site en utilisant des .htaccess couplés à des .htpasswd, comme je le fais de temps en temps.
Imprimer
Laisser un commentaire