En attendant que la peinture sèche sur ce nouveau site, je préfère annoncer la couleur : ce site se fera pirater. Pourquoi une telle certitude ? Parce que c’est comme cela qu’un responsable de la sécurité informatique fonctionne : il sait que le pire arrivera, il doit s’y préparer et arrêter de vendre à ces patrons un rêve impossible : une sécurité absolue.
Ce site se fera pirater parce que j’ai choisi, pour l’instant, d’en administrer une partie moi-même. J’avais choisi Blogger en 2006 parce que je suis profondément fainéant : j’avais envie de publier des billets de blog, pas d’en gérer la tuyauterie. Quand le premier blog s’est fait pirater, j’ai eu besoin de l’équipe sécurité de Google pour le remettre sur pied (et je les remercie encore pour leur rapidité). Une fois nettoyé, ils ont remonté une sauvegarde que j’ai ensuite pu comparer avec mes propres sauvegardes.
Alors pourquoi quitter ces terres confortables pour un territoire incertain ?
Passer du poste de DSI multicartes à celui de RSSI m’a donné le goût du risque, mais aussi la certitude qu’il n’existe pas de situation de sécurité absolue : une faille de sécurité peut être découverte par une personne malveillante avant tout le monde, et surtout avant l’éditeur du logiciel : c’est ce que l’on appelle une faille 0day. Tant que la faille n’est pas repérée par un « gentil » elle sera exploitée par un « méchant » (je caricature un peu, mais vous voyez l’idée). Et quand le « gentil » aura repéré la faille, il faudra que l’éditeur du logiciel la corrige, vérifie que la correction ne génère pas de nouvelle faille, puis la diffuse aux utilisateurs du logiciel sous la forme d’une rustine (patch). Il faut ensuite que l’utilisateur fasse la mise à jour. Pendant tout le temps qui s’écoule entre la découverte de la faille et l’application de la mise à jour, le site est vulnérable. Et être responsable de la sécurité informatique n’implique pas d’être capable de passer son temps à chercher des failles, à les faire corriger en alertant. Certains le sont, pas moi.
Mais s’occuper de sécurité informatique, cela nécessite aussi de mettre un peu les mains dans le cambouis, ne serait-ce que pour comprendre et mieux appréhender les risques informatiques.
Bloguer est pour moi un passe-temps, une thérapie, un amusement, un partage, une expérience, et une tentative de laisser à mes enfants une trace de mon passage. Ce n’est pas une vitrine de mon savoir-faire, surtout en matière de sécurité. J’en connais un peu plus que certains, mais bien moins que beaucoup : l’idée est de faire progresser ceux qui ont envie, même si cela fait rire les connaisseurs.
J’ai choisi WordPress. OMG ! Les raisons : parce que c’est joli. C’est aussi le CMS le plus utilisé, donc celui qui a la plus grande communauté d’utilisateurs. C’est du coup aussi le CMS le plus ciblé par des attaquants. C’est donc un bon terrain d’expérimentations pour moi. Quand ce site aura été piraté, que je serai rouge de confusion, il sera alors temps de le réparer, de parfaire sa sécurité et de le réinstaller à partir des sauvegardes. La honte sera passagère. J’aurai appris parce que je serai tombé.
Pour rassurer certains lecteurs inquiets, je n’ai pas baissé les bras à peine le site en place. J’ai installé le minimum de plugins, mis en place des fichiers .htaccess contraint et forcé puisque je n’ai pas accès à la conf du serveur Apache sur mon serveur mutualisé. J’ai configuré un certificat pour le https, en priant pour qu’il se mette correctement à jour le moment venu. Bref, je retrouve le boulot d’admin que je faisais il y a 20 ans, mais en beaucoup plus compliqué.
Et surtout, je continue à faire des sauvegardes, que je teste régulièrement. Si vous voyez que le site est en rade, c’est soit qu’il a été piraté, soit que mon test de restauration s’est mal passé, soit une configuration DNS hasardeuse, soit un test de protection quelconque qui s’avère inefficace, soit ma bascule vers mon Yunohost de secours qui s’est mal passée, soit qu’une mise à jour importante de sécurité a eu lieu pendant que j’étais loin du clavier, par exemple en vacances, soit que j’ai oublié de payer l’hébergement.
Il ne faut pas avoir honte de s’être fait pirater. Ceux qui pensent ne pas s’être fait pirater, ce sont juste ceux qui ne s’en sont pas encore rendu compte.
Hello
ça commence bien, le /readme.html est pas accessible 😉
Welcome to WordPress !
De mon coté, j’utilise le thème Sydney que je trouve assez sympa et
Wordfence Security & All In One WP Security pour le niveau application 🙂
Le reste des extensions sont dédiées à augmenter la perf, sans que j’ai trop a bosser… W3C total cache et des optimiser de JS & Images.
En général avec une update système, l’auto update du core WP plus une update plugins fréquente, hormis si tu es target, tu devrais pas craindre grand chose.
Amuse toi bien 😉
Hello Lince,
Tu penses qu’il ne faut pas divulguer le readme sinon on connait la version de WordPress ? La divulgation serait donc une source de piratage ?
Alors pourquoi nous indiquer que tu utilises le thème « sydney » et les plugins « Wordfence & AIOWPS » puis « W3TC » ? Alors que c’est ça le premier vecteurs de failles : les plugins et thèmes ?
😉
@Julio le Potier
« Tu penses qu’il ne faut pas divulguer le readme sinon on connait la version de WordPress? »
Il semblerait que vous ayez lu un peu vite.
Lince a écrit:
« ça commence bien, le /readme.html est pas accessible »
Lince aurait du écrire « le readme N’est pas accessible ». Mais en dehors de cette faute de syntaxe de plus en plus courante, ile a parfaitement raison: le readme renvoi une page non accessible 🙂
Probablement parce qu’il n’a pas été remplis 😉
Pour ce qui est de déterminer la version de wordpress (et de tout ce qui est accessible par l’ordinateur client), outre l’exploration du code brut il existe de nombreux plugin coté client qui s’en chargent très bien.
Hello @Julio
comme @Alfred l’a bien dit, en regardant le code source des pages, on verra toutes les infos que j’ai donné 😉
Ne pas afficher le readme est plus une « bonne pratique », d’où mon « ça commence bien ».
@Alfred, effectivement, je n’ai pas relu le post 😀
« Alors que c’est ça le premier vecteurs de failles : les plugins et thèmes » C’est indéniable, tout est une question de choix et d’analyse de risque, minimiser le risque tout en satisfaisant les besoins utilisateur / admin.
Afin d’éviter de mettre tous mes oeufs dans un même panier et notamment la base de donnée, je passe par une Jamstack, un générateur de site static. Mon chouchou étant Hugo (gohugo.io)
Comme ça l’utilisateur n’a que de l’html / css compilé en amont. Les pages sont plus légères et le risque d’attaque est diminué.
Intéressant ! Mais du coup, pas de possibilité de commentaires ?
Si si c’est possible d’intégrer des commentaires dans un site statique, soit avec un service tiers comme Disqus (bof bof), soit en contournant le système de commentaires, voir https://jamstatic.fr/2016/12/09/des-commentaires-statiques-avec-jekyll-et-staticman/
Bon article, bonne philosophie.
Je rejoins votre opinion sur la faille 0day.
Quand je bossais en labo, il y avait le « risk assessment ». Un pavé à remplir, relire et signer. En gros: recenser tout ce qui était dangereux et pourquoi, comment éviter les accidents et comment limiter les conséquences d’un accident si malgré toutes les précautions celui-ci se produisait. Car il se produirait.
A mon avis, tout site web (tout support informatique?) est piratable par définition.
La seule hypothèse que je peux imaginer pour ne pas être piratable serait d’être hébergé sur un serveur bloqué en lecture de manière MATÉRIELLE. Autrement dit non pas avec du code informatique (eeprom, bios flashable, etc), mais avec un interrupteur mécanique. Des données sur support non modifiables matériellement (CD-R?). Et pour éviter les possibilité de piratage sur le trajet entre le lecteur du site et son auteur (ex: DNS poisoning), d’être connecté par fibre optique directement à tous ses lecteurs. Autrement dit, de ne pas être sur internet. :D.
Ceci dit…
Il est toujours possible de cambrioler une maison mais c’est plus facile si les portes sont ouvertes. Et corollaire du précédent, si vos portes sont verrouillées et que vous avez un garde armé dans votre maison, le nombre de personnes capable de vous cambrioler sera très réduit.
Appliqué à un site web, cela donne qu’avec des fichiers .htaccess bien écrits et autres règles de sécurité bien en place, on diminue pas mal le nombre d’assaillants. Et pour les autres, il y a la sauvegarde régulière du site. :).
« C’est aussi le CMS le plus utilisé, donc celui qui a la plus grande communauté d’utilisateurs. C’est du coup aussi le CMS le plus ciblé par des attaquants. »
Mais comme c’est l’un de ceux ayant la plus grande communauté, c’est donc logiquement un de ceux dont les failles 0day sont détectées (et réparées?) les plus vite, non?
Je n’ai pas de préjugé contre wordpress.
Pas utilisé depuis longtemps mais dans mon souvenir il était bon pour publier de simples billets sans s’embêter trop. Tenter de lui faire pondre des sites web complexes avec un max de fioritures était par contre aussi facile que de traverser l’Atlantique en canoë. Mais il sinon il fait bien ce pour quoi il a été pensé.