Magento : changer le chemin admin après un incident
Changer le chemin admin après un incident réduit le brute force sur /admin. Ça ne révoque pas une clé API déjà volée. On fait les deux. Et on prévient l’équipe : tout le monde avait bookmarké l’ancienne URL.
Utile contre le brute force, inutile contre une clé API déjà volée. Faites les deux. Prévenez l'équipe : tout le monde a bookmarké /admin.
Ce que le custom admin path fait (vraiment)
Magento 2 permet un frontName admin autre que `admin`. Les bots qui tapent /admin reçoivent une 404. Moins de bruit dans les logs, moins de charge, moins de réussites sur des mots de passe faibles. C’est utile. Ce n’est pas de la magie.
Après incident, c’est un durcissement de sortie, comme fermer xmlrpc sur WordPress. On le fait une fois le site propre, les comptes revus, les clés tournées. Le changer au milieu d’un nettoyage, c’est occuper deux personnes sur un bookmark pendant que le module checkout sale tourne encore.
Si l’attaquant a déjà un cookie, une intégration, ou le nouveau chemin (il lit env.php), le changement ne sert à rien contre lui. Il sert contre le prochain scan anonyme.
Ce qu’il ne fait pas
Il ne retire pas un module malveillant, un cron, un admin user. Il ne tourne pas les clés d’intégration (Adobe Commerce / Magento integrations, tokens). Il ne lève pas Safe Browsing. Il ne remplace pas un changement de secrets panel et SSH.
Un chemin « secret » n’est pas un secret : il finit dans l’historique, les tickets, les bookmarks, les captures. Traitez-le comme un réduit de surface, pas comme un mot de passe.
Les API (REST/SOAP) ont leurs propres URLs. Un attaquant avec un token d’intégration n’a pas besoin de /admin. Tournez les intégrations le même jour. Cousin des clés webservice.
Le faire après, pas à la place du nettoyage
Pendant que le site sert encore un HTML sale, changer le path occupe l’équipe et casse les accès légitimes. Nettoyez (Magento piraté), puis path + 2FA + users.
Un réexamen Google se fiche du frontName. Blacklist : contenu.
Si vous êtes verrouillé hors du BO, le path n’est pas le premier levier : app/etc/env.php, SSH, backup. Ne « devinez » pas le path en production comme un exercice.
Comment le poser sans se verrouiller
Le frontName se configure (env.php / config) selon votre version et votre mode (config.php vs env). Suivez la doc officielle Adobe de votre minor. Faites-le en maintenance courte, cache flush, deux sessions test (vous + un collègue) avant de communiquer largement.
Gardez un accès SSH. Un path mal tapé + cache = équipe dehors. Avoir le levier CLI pour remettre un frontName connu.
On ne publie pas ici une recette d’intrusion ni un script de scan de path. Votre path, votre doc interne, pas un gist public avec le nom de la boutique.
- SSH / déploiment encore valides.
- Maintenance courte.
- Flush cache, test login, puis message interne.
Prévenir les humains (et les scripts)
Email interne : nouvelle URL, pas d’ancienne dans les favoris. Les intégrateurs, le community manager, le stagiaire qui « met les pubs à jour ». Un bookmark /admin = tickets « le site est down ». Envoyez l’URL par un canal déjà authentifié ( Slack interne, gestionnaire de mots de passe), pas dans un fil client public ni en commentaire de ticket hébergeur.
Scripts de monitoring (uptime sur /admin) : à mettre à jour, sinon alertes fausses. Les recette Cypress / Playwright des agences aussi.
Ne postez pas le nouveau path sur Twitter ni en commentaire de ticket public d’hébergeur.
2FA, comptes, intégrations
Users admin Magento : liste, révocation, 2FA (Adobe / module). Intégrations : régénérer. Tokens REST. Comptes deployment. Le path est la cerise, pas le gâteau. Un token d’intégration « ERP » oublié contourne le frontName autant qu’un bookmark : même après-midi, autre écran, même sérieux que les clés Presta.
Un compte partagé « marketing » : cassez-le en comptes nominatifs. Le path custom + un mot de passe Slack, c’est encore un compte partagé.
Voisin de serveur / autre magento sur le même host : réputation IP si le bruteforce continue sur l’IP, pas sur votre path.
Caches, CDN, WAF
Varnish / Fastly / Cloudflare peuvent cacher une 404 /admin ou au contraire exposer le nouveau path dans un rapport. Purge. Règle WAF : protégez le nouveau chemin (restriction IP si vous êtes une équipe fixe — pas toujours possible avec des community managers nomades).
Ne bloquez pas /admin seulement : les bots passeront au nouveau dès qu’il fuit. La restriction IP / 2FA tient ; le path seul, non.
HTTP vs HTTPS : le vieux path en http ne doit pas servir un autre panel.
Le reste du dossier Magento
Modules communautaires, app/code, cron, generated, composer. Le path n’y figure pas. Si la boutique est encore sale, déclarez. Commerce + cartes : coût d’erreur élevé.
Documentez le frontName dans un gestionnaire de secrets, pas dans le README du dépôt public.
J+30 : brute force /admin en baisse (normal), tentatives sur le nouveau path = fuite du path, pas un échec de Magento. 2FA et users alors, pas un troisième path.