Faux admin, vrai piège : NotTodayHoney pour Laravel

On parle souvent de honeypot dans le contexte des formulaires web : un champ caché qui piège les bots. C’est utile, mais ça ne m’intéressait pas vraiment. Ce que je voulais, c’est quelque chose de plus fondamental, détecter une personne qui cherche à faire du mal à un système, et lui faire perdre son temps.

L’idée du honeypot reste la même : attirer vers quelque chose d’appétissant. Mais plutôt que de filtrer du spam, je voulais identifier des intentions malveillantes et réagir en conséquence.

Repenser le honeypot

La plupart des packages honeypot Laravel se concentrent sur les bots de formulaires. C’est un problème réel, mais ce n’est qu’une fraction des menaces auxquelles un projet web est exposé.

Trois profils d’attaquants m’intéressaient davantage :

Les scanners automatisés, des outils comme nuclei ou nmap qui parcourent l’internet à la recherche de surfaces d’attaque connues. Ils cherchent des endpoints comme /wp-admin, /phpmyadmin, ou des fichiers readme.txt révélateurs de versions vulnérables. Ils ne ciblent personne en particulier, ils récoltent de l’information à grande échelle.

Les opportunistes, des personnes qui, ayant trouvé un endpoint intéressant, tentent de l’exploiter. Un faux panneau d’administration visible, et ils essaient des combinaisons identifiants/mot de passe courants : admin/admin, root/root. Ils cherchent une porte mal fermée.

Les attaquants ciblés, ceux qui connaissent le système et tentent délibérément de le compromettre. L’utilisation d’un identifiant connu, d’un mot de passe issu d’une fuite, ou d’une combinaison qui n’aurait pas dû être accessible publiquement.

NotTodayHoney est né de cette lecture. Je voulais proposer aux équipes de développement, petits projets comme grandes applications, une solution simple, proche du code, qui détecte ces trois niveaux d’intention et réagit en conséquence.

Ce que fait NotTodayHoney

La documentation complète est disponible sur vinksyunit.github.io/NotTodayHoney.

Des pièges qui ressemblent à la vraie vie

Le package déploie des faux endpoints de connexion, des traps, qui imitent des interfaces connues :

• WordPress : /wp-admin/wp-login.php avec une fausse version affichée, des endpoints de l’API REST, des listings d’utilisateurs, et des fichiers readme.txt de plugins pour attirer les scanners CVE
• phpMyAdmin : /phpmyadmin avec des cookies de session qui imitent une vraie instance, même avant authentification
• Generic Admin : /admin/login avec un titre configurable pour coller à ce que les attaquants recherchent

Ces endpoints ne sont jamais accessibles aux utilisateurs légitimes. Chaque visite est donc un signal.

Trois niveaux de détection

Les événements collectés génèrent des alertes progressives :

Une IP qui visite le /wp-admin trois fois en une journée est probablement un scanner automatisé, une alerte légère suffit. Une IP qui soumet des credentials est une menace plus sérieuse. Une IP qui utilise un mot de passe issu d’une base de données compromise mérite 30 jours de blocage et une alerte critique.

Perdre le temps de l’attaquant

Toutes les réponses des traps sont retardées d’au minimum 1000ms, pas pour ralentir les utilisateurs légitimes (qui ne devraient jamais atteindre ces endpoints), mais pour qu’un attaquant ne puisse pas distinguer un honeypot d’un vrai service par le temps de réponse.

Sur les traps de connexion, on peut configurer une réponse fake_success : l’attaquant voit un faux dashboard vide et croit avoir réussi. Il continue à explorer, à perdre du temps, pendant que chaque action est loguée.

Mise en place

composer require vinksyunit/not-today-honey
php artisan vendor:publish --tag="not-today-honey-config"
php artisan vendor:publish --tag="not-today-honey-migrations"
php artisan migrate

Prérequis : PHP 8.4+ et Laravel 12+.

Bloquer sans se trahir

Une fois des IPs marquées comme menaçantes, le middleware HoneypotBlockMiddleware se charge de les bloquer. L’approche recommandée est de ne pas l’appliquer globalement. Si une IP bloquée obtient un 403 sur la page d’accueil, elle comprend immédiatement qu’elle est identifiée et change de tactique.

L’objectif est l’inverse : laisser l’attaquant naviguer librement sur les pages publiques, mais le bloquer silencieusement sur les zones qui comptent.

// bootstrap/app.php, protection ciblée uniquement
Route::middleware('nottodayhoney.block')->group(function () {
    Route::post('/login', [AuthController::class, 'store']);
    Route::post('/register', [RegisterController::class, 'store']);
    Route::prefix('/api')->group(function () {
        Route::post('/tokens/create', ...);
        Route::post('/password/reset', ...);
    });
    Route::prefix('/admin')->group(function () {
        // Toutes les routes sensibles d'administration
    });
});

Résultat : l’attaquant peut parcourir le site, il semble fonctionner normalement. Dès qu’il tente d’accéder à une fonctionnalité critique, la requête est bloquée. Il ne sait pas pourquoi, il ne sait pas depuis quand, et chaque nouvelle tentative est loguée.

Un outil de plus dans la stack Blue Team

NotTodayHoney est un outil de détection, pas de prévention. Il ne bloque pas des paquets réseau, n’applique pas de règles firewall, et ne corrige aucune vulnérabilité applicative. Ce qu’il fait, c’est repérer des signaux comportementaux et en alerter.

C’est son rôle exact dans une stack Blue Team, et il ne prétend pas en faire plus.

Une défense sérieuse s’organise en couches. NotTodayHoney s’intègre dans la couche applicative, aux côtés d’un reverse proxy ou d’un WAF en entrée de trafic, d’un blocage IP au niveau réseau, d’une authentification robuste, de code reviews orientées vecteurs d’injection, et de tests de pénétration qui révèlent ce que les honeypots ne voient pas.

Ce que NotTodayHoney apporte, c’est de la visibilité sur des comportements réels, pas des simulations. Les identifiants soumis sur un faux /wp-admin sont les vrais credentials que quelqu’un a essayé. C’est une information que les autres outils ne collectent pas.

Pour les petits projets, c’est souvent la première brique de monitoring de sécurité opérationnel qu’on peut poser sans budget ni infrastructure complexe. Pour les projets plus grands, c’est une source de signal supplémentaire qui vient enrichir un SIEM existant.

Facile à installer, proche du code, peu coûteux, c’est exactement ce que j’avais en tête en l’écrivant.

Vincent Demonchy

@vinksyunit · Full-stack, Avignon

⬇ Raw Markdown