
🌐 Aussi en: English · Deutsch · Español
Il y a quelques jours, l’actualité nous a servi une histoire délicieusement inquiétante : OpenAI a reconnu que deux de ses modèles d’IA, pendant une évaluation de sécurité, se sont bel et bien échappés de leur sandbox de test, se sont baladés sur l’Internet ouvert et ont pénétré l’infrastructure de production de Hugging Face — en enchaînant une véritable faille zero-day — tout ça pour voler le corrigé d’un benchmark 🤖💥 (Malwarebytes, The Hacker News). Cette histoire, c’est la version cauchemar. Ce que j’ai fait, c’est l’exact contraire, ennuyeux et bien sage : j’ai pris une IA et je l’ai lâchée sur mon propre blog — avec autorisation, volontairement, sans aller là où elle n’était pas invitée — juste pour voir si mes propres défenses tiennent vraiment. Le même genre de technologie, mais tournée vers l’intérieur, vers quelque chose qui m’appartient, et non vers les serveurs de quelqu’un d’autre. Rien ne s’est échappé de quoi que ce soit. 🪞 Petit avertissement avant que quelqu’un ne s’étrangle : ce blog est à moi. Autoriser un scan de sécurité, c’est l’affaire d’un comité d’une seule personne, et le comité a voté oui. ✅ Aucune sandbox n’a été maltraitée, rien ne s’est échappé, et la seule infrastructure en danger était la mienne. Après toute la saga wp2shell, j’étais de toute façon curieux : mon blog tourne sur une stack K3s + WordPress faite maison, que je durcis moi-même — avec, en toute transparence, une IA sur le siège passager, aussi bien pour le durcissement que pour cette évaluation même. Alors, comment tiendrait-il le coup si quelqu’un venait le titiller exprès ? Une seule façon de le savoir : voir ce qui tombe.🎩 Petit détour : chapeaux blancs, gris et noirs
Comme tous les lecteurs ne vivent pas au pays de la sécurité : le mot « hacker » existe en plusieurs couleurs, et elles comptent :- 🤍 White hat : les gentils. Ils testent des systèmes avec autorisation pour trouver et combler les failles avant les méchants. Pensez à un inspecteur de la sécurité incendie.
- 🖤 Black hat : les vrais criminels. Ils entrent par effraction sans autorisation, pour l’argent ou pour nuire. L’histoire des modèles d’OpenAI qui ont pénétré Hugging Face, plus haut, c’est en gros un black hat accidentel.
- 🩶 Gray hat : l’entre-deux. Il fouille dans la zone floue — généralement sans mauvaise intention, mais pas toujours proprement dans les clous non plus.
🚫 Round 1 : le serveur bannit son propre propriétaire
J’ai commencé comme commence n’importe quel attaquant qui s’ennuie : un petit scan de ports pour voir ce qui écoute. Des connexions rapides sur une poignée de ports. Quelques millisecondes plus tard — tous les ports, sans exception, se sont éteints. HTTP, HTTPS, et même mon propre accès SSH d’administration. Le pare-feu avait vu la rafale de connexions, décidé « ça, c’est un scanner » et jeté mon IP entière dans une liste de blocage. 🧱 Puis, plus tard, en continuant à fouiner, j’ai demandé quelques-uns des chemins classiques du genre « y a-t-il une sauvegarde oubliée qui traîne ». Au bout de deux requêtes, la couche de détection d’intrusion s’est dit « sondage de chemins connus comme malveillants, on arrête là » et m’a collé un bannissement de 24 heures. 🔨 J’ai dû me débannir moi-même via la console de l’hébergeur, comme un serrurier qui a enfermé ses clés dans sa voiture. C’est exactement ce qu’on veut. Un attaquant ne tombe pas sur une cible patiente et indulgente — il a droit à une poignée de requêtes avant que toute son IP ne parte dans un trou noir. Le calcul est catastrophique pour lui : griller une IP, n’apprendre presque rien, réessayer depuis une nouvelle, se faire bannir à nouveau. 🔁 Ce n’est pas un mur, c’est un mur qui mord.✅ Le tableau des scores : tout ce que je lui ai lancé
Une fois que je me suis (à contrecœur) mis moi-même en liste blanche pour pouvoir enfin tester la couche applicative, voici la checklist que j’ai déroulée — les trucs ennuyeux qui décident discrètement si un site est une cible facile ou non :- 🔒 TLS : uniquement 1.2 et 1.3, chiffrement moderne, anciens protocoles refusés. ✔️
- 🧾 En-têtes de sécurité : HSTS avec preload, protection contre le clickjacking, MIME-sniffing désactivé, referrer et permissions verrouillés. ✔️
- 🕵️ Empreinte du serveur : aucune version du serveur web, aucune version de PHP qui fuite dans les en-têtes. ✔️
- 👤 Énumération des noms d’utilisateur (le premier pas classique avant une séance de devinette de mots de passe) : bloquée par toutes les voies que j’ai essayées — la vieille astuce de la query, l’API REST, tout. ✔️
- 📡 xmlrpc (l’amplificateur que les bots adorent pour le brute force) : fermé, en GET comme en POST. ✔️
- 🗂️ Fichiers sensibles (config, dotfiles, métadonnées VCS, la liste de courses habituelle) : refusés. ✔️
- 📁 Listage des répertoires : désactivé. Rien à parcourir. ✔️
- 🔑 Les endpoints sensibles de l’API REST : chacun de ceux qui comptaient a répondu par un sec « vous n’avez pas le droit de faire ça. » ✔️
😰 Celui qui m’a rendu nerveux (et puis non)
Chaque site WordPress a sa pièce la plus effrayante, et ici c’était le plugin de migration/sauvegarde. Ces outils peuvent, en principe, livrer une archive complète du site — base de données, config, secrets, tout le journal intime — si la porte n’est pas verrouillée. Alors j’ai secoué cette porte-là en particulier. 🚪 Elle était verrouillée. Chaque action sensible répondait « non autorisé » tant que je n’étais pas connecté, et le plugin lui-même était à jour, sans contournement connu. C’était le résultat qui m’importait vraiment, et il est revenu propre. 🎯 La leçon pour quiconque fait tourner WordPress : le plugin capable d’exporter tout votre site, c’est celui qu’il faut vérifier en premier, pas en dernier.🔧 Ce que j’ai trouvé — et corrigé le soir même
Aucun pentest ne ressort parfaitement propre, le mien non plus — mais les restes étaient l’équivalent sécurité de « vous avez laissé une fenêtre non verrouillée au troisième étage, derrière un portail fermé à clé ». Du ceinture-et-bretelles :- 📄 Quelques numéros de version de composants étaient lisibles à des endroits où ils n’avaient rien à faire. Divulguer des versions n’aide un attaquant que si vous êtes en retard sur les correctifs — cette stack se met à jour et redémarre toute seule, donc c’est surtout une question de propreté. Resserré quand même.
- 💾 La règle qui bloque les fichiers de sauvegarde d’éditeur égarés ne couvrait pas quelques suffixes (ceux que laisse votre éditeur en terminal). Rien n’était réellement exposé — mais « rien n’était exposé aujourd’hui » n’est pas une mesure de sécurité, alors j’ai élargi le filet. Désormais, tout ce qui ressemble à un fichier oublié se voit opposer un refus net.
- 📊 Le seul vrai « ah, bien vu » de la journée : mon tableau de bord de monitoring a toujours été protégé par un vrai nom d’utilisateur + mot de passe — mais c’était la seule connexion de toute la machine sans blocage automatique contre le brute force, contrairement à la connexion du blog, qui bannit à vue ceux qui devinent en boucle. J’ai donc offert au tableau de bord le même traitement : quelques échecs de connexion d’affilée, et toute l’IP est priée de sortir. Un mot de passe et un videur désormais, pas seulement le mot de passe. 🚪👮




