En bref : le moyen le plus efficace de protéger l'espace d'administration est de ne l'ouvrir qu'à des réseaux connus : par liste d'IP autorisées dans le serveur web, via un VPN avec adresse de sortie fixe ou avec une seconde authentification préalable. Il faut une liste complète de toutes les adresses d'administration, un traitement correct des proxys et des CDN, et un test depuis l'extérieur. Cette protection complète l'authentification à deux facteurs et les mises à jour, elle ne les remplace pas.
Pourquoi le back-office est-il ouvert en premier lieu ?
Dans de nombreuses entreprises, les administrateurs ont mis à jour PHP la semaine dernière et redémarré les workers. Ceux qui consultent ensuite les journaux d'accès constatent souvent autre chose : la page de connexion du CMS, l'outil de base de données et le panneau d'hébergement sont appelés jour et nuit depuis le monde entier. Pourtant, seule une poignée de personnes de l'équipe en a besoin.
Chacune de ces adresses est une surface d'attaque. Les formulaires de connexion sont soumis à des essais en série, les outils d'administration contiennent leurs propres failles, et les extensions du back-office sont souvent moins bien examinées que le noyau d'un CMS. Si des inconnus ne peuvent même pas atteindre ces zones, de nombreuses attaques échouent avant même de commencer.
En toute honnêteté : contre PHP2Shell lui-même, cela n'aide que peu. Les failles se trouvent dans l'interpréteur et, selon php.net, peuvent être déclenchées sans authentification via des pages PHP publiques. La protection du back-office est un durcissement durable, pas un correctif d'urgence.
Protéger l'espace admin par IP, VPN ou seconde authentification
Il n'existe pas une seule bonne méthode. Ce qui compte, c'est la façon dont votre équipe travaille et l'endroit où tourne le site.
| Méthode | Adaptée à | Limite |
|---|---|---|
| Liste d'IP autorisées dans le serveur web | Bureau à adresse fixe, petites équipes | adresses changeantes en télétravail, entretien de la liste |
| VPN avec adresse de sortie fixe | Équipes réparties, prestataires | le VPN doit lui-même être bien sécurisé et à jour |
| Authentification préalable (authentification HTTP) | Complément lorsqu'une adresse fixe est impossible | mot de passe supplémentaire, utile uniquement avec TLS |
| Certificats clients | Peu d'appareils, gérés de façon fixe | émission et révocation des certificats exigent de la discipline |
| Nom d'hôte propre, réservé au réseau interne | Grands environnements avec DNS interne | refonte de l'application, tous les CMS ne le permettent pas |
En pratique, une combinaison a fait ses preuves : autorisation limitée au VPN ou au réseau de l'entreprise, avec une seconde authentification comme filet de sécurité. La connexion proprement dite au CMS reste protégée par un procédé à deux facteurs, comme décrit dans le guide Authentification à deux facteurs pour les accès administrateur.
Quelles adresses font réellement partie du back-office ?
Le point faible le plus fréquent n'est pas la technique, mais une liste incomplète. Procédez donc dans cet ordre :
- Recenser les pages de connexion du CMS ou de la boutique, y compris les adresses de connexion alternatives que créent des extensions.
- Rechercher les outils d'administration : interfaces de base de données, gestionnaires de fichiers, scripts d'installation, pages d'état et de supervision.
- Inclure les panneaux d'hébergement et de serveur, qui tournent souvent sur des ports dédiés.
- Vérifier les instances de test et de préproduction, qui utilisent souvent les mêmes identifiants que le site en production.
- Délimiter les interfaces : certains chemins du back-office sont aussi appelés par le front-end public, par exemple pour des requêtes Ajax. Vous ne devez pas les bloquer à l'aveugle, sinon les formulaires ou les paniers cessent de fonctionner.
Le point cinq est la raison pour laquelle une protection doit toujours être testée. Avec WordPress, par exemple, un fichier du dossier d'administration est aussi utilisé pour des fonctions publiques.
Configuration : liste d'IP plus seconde authentification
Sous Nginx, les deux conditions peuvent être combinées. Avec satisfy all, une requête doit provenir d'un réseau autorisé et réussir en plus la seconde authentification. Le chemin, les adresses et la transmission à PHP sont des valeurs d'exemple :
location ^~ /backend/ {
satisfy all;
allow 192.0.2.0/24; # réseau de l'entreprise (valeur d'exemple)
allow 198.51.100.10; # sortie du VPN (valeur d'exemple)
deny all;
auth_basic "Interner Bereich";
auth_basic_user_file /etc/nginx/htpasswd-backend;
location ~ \.php$ {
include snippets/fastcgi-php.conf;
fastcgi_pass unix:/run/php/php-fpm.sock;
}
}
La location PHP imbriquée est importante : à cause de ^~, les autres règles pour .php ne sont plus évaluées. Sous Apache, vous obtenez le même résultat avec un bloc dans lequel les deux conditions doivent être remplies :
<Location "/backend">
AuthType Basic
AuthName "Interner Bereich"
AuthUserFile /etc/apache2/htpasswd-backend
<RequireAll>
Require ip 192.0.2.0/24 198.51.100.10
Require valid-user
</RequireAll>
</Location>
Le fichier de mots de passe doit se trouver en dehors du webroot. La seconde authentification transmet les identifiants à chaque requête ; ne l'utilisez donc qu'avec HTTPS.
Avant toute modification, gardez un second accès au serveur, par exemple une session SSH déjà ouverte. Si vous vous verrouillez vous-même, vous aurez sinon besoin de l'hébergeur.
Les pièges : CDN, proxy, IPv6 et télétravail
Si votre site se trouve derrière un CDN comme Cloudflare ou un répartiteur de charge, le serveur web ne voit d'abord que les adresses de ce dernier. Une liste d'IP autorisées bloquerait alors tout le monde ou laisserait tout passer. Le serveur web doit reprendre l'adresse réelle depuis un en-tête : avec set_real_ip_from et real_ip_header sous Nginx, avec mod_remoteip sous Apache.
Règle à respecter : n'accepter l'en-tête que depuis les adresses de vos propres proxys. Sinon, n'importe quel visiteur peut simuler une origine quelconque. Il est tout aussi important que le serveur d'origine ne soit pas directement joignable, car sinon le proxy et ses règles peuvent être contournés. Vous trouverez des indications à ce sujet dans Pare-feu pour serveur web.
Deux autres points sont souvent négligés. Si le serveur est joignable en IPv6, les adresses IPv6 de votre réseau ont aussi besoin d'une entrée, sinon les administrateurs en IPv6 se heurtent à un blocage. Et les connexions Internet des particuliers changent régulièrement d'adresse. Pour le télétravail et les prestataires externes, un VPN est donc généralement la solution la plus stable.
Comment vérifier que la protection fonctionne
Une règle non testée ne compte pas comme mise en œuvre. Vérifiez depuis une connexion extérieure au réseau de l'entreprise, par exemple via le réseau mobile :
# Attendu : 403 (bloqué) ou 401 (seconde authentification demandée)
curl -s -o /dev/null -w "%{http_code}\n" https://www.example.de/backend/
# Vérifier aussi directement les fichiers PHP, pas seulement le répertoire
curl -s -o /dev/null -w "%{http_code}\n" https://www.example.de/backend/index.php
Refaites ensuite les mêmes appels depuis le réseau de l'entreprise ou le VPN : la page doit y être accessible. Contrôlez ensuite le front-end public, c'est-à-dire formulaires, recherche et panier. Dans les journaux des jours suivants, les accès aux adresses d'administration ne devraient plus apparaître presque qu'avec le statut 401 ou 403.
Si l'espace était ouvert jusqu'ici, un coup d'œil aux comptes existants s'impose. La façon de trouver des administrateurs inconnus est décrite dans Trouver des comptes admin inconnus dans le CMS et sur le serveur. En complément, une protection contre les essais massifs ralentit les attaques ; voir Protéger les connexions admin contre la force brute.
Comment PHP SOS aide-t-il concrètement ?
- Nous recensons toutes les adresses d'administration de vos sites, panneaux et outils, et les séparons des chemins nécessaires au public.
- Nous choisissons avec vous la méthode adaptée, selon la taille de l'équipe, le télétravail et l'hébergement.
- Nous mettons les règles en place dans le serveur web, tenons compte du CDN, du proxy et d'IPv6, et gardons une voie de retour ouverte.
- Nous testons de l'extérieur et de l'intérieur et remettons une courte documentation avec les réseaux autorisés.
La protection des espaces d'administration fait partie de notre durcissement de serveur pour serveurs web PHP.
Questions fréquentes
Un mot de passe sûr pour la connexion au CMS ne suffit-il pas ?
Un mot de passe robuste et une authentification à deux facteurs sont indispensables, mais ils ne protègent que la connexion elle-même. Les failles dans les pages de connexion, les extensions ou les outils d'administration restent accessibles à tous. Une protection au niveau du réseau ou du serveur web empêche les inconnus d'y parvenir.
Que faire si mes collaborateurs ont des adresses IP changeantes ?
Dans ce cas, un VPN avec adresse de sortie fixe est généralement une meilleure solution qu'une liste d'adresses individuelles. Tous les administrateurs se connectent d'abord au VPN, et le serveur web n'autorise que cette adresse. Une seconde authentification préalable est une autre option.
Un blocage par IP fonctionne-t-il aussi derrière Cloudflare ou un répartiteur de charge ?
Uniquement si le serveur web reprend l'adresse réelle du visiteur depuis un en-tête de confiance et n'accepte cet en-tête que de son propre proxy. Sinon, il ne voit que les adresses du proxy ou se fie à des indications falsifiées. En outre, le serveur d'origine ne devrait pas être directement joignable depuis Internet.
Un espace admin protégé protège-t-il contre PHP2Shell ?
Seulement de manière très limitée. Les failles PHP2Shell se trouvent dans l'interpréteur PHP et peuvent être exploitées sans authentification via n'importe quelle page PHP publique. Contre PHP2Shell, ce qui aide, c'est la mise à jour de PHP suivie du redémarrage de tous les workers ; la protection ne réduit que le reste de la surface d'attaque.