Ce que fait WardPane 2.0
WardPane 2.0 héberge des sites statiques, PHP et Node.js avec des certificats automatiques et la prise en charge de Cloudflare. La protection et le contrôle du trafic s'appliquent par site, dans le serveur web. Dans la plupart des huit panneaux de la page de comparaison, ces fonctions passent par ModSecurity ou par un module payant.
Pour les débutants et pour les administrateurs expérimentés
Les débutants ont une seule commande pour installer, des certificats qui s'émettent tout seuls, des sites isolés et des réglages expliqués en termes simples. Les administrateurs expérimentés ont toutes les options, un terminal dans le navigateur, PM2 par propriétaire, .htaccess, des règles par site dans un ordre connu, l'API Cloudflare, l'export et l'import, des sommes de contrôle pour chaque version et le code source.
Hébergement
Les sites suivent une arborescence de type ISPmanager, appartiennent à un utilisateur Linux et sont servis par WardPane lui-même sur les ports 80 et 443.
- Sites et alias
- Un site, c'est un domaine plus jusqu'à 99 alias (un certificat Let's Encrypt contient au plus 100 noms). Un alias sert le site principal ou, s'il a son propre dossier, ce dossier. Les sites peuvent avoir un nom d'affichage.
- Arborescence par propriétaire
- Les fichiers se trouvent dans /var/www/<owner>/data/www/<domain>, avec les journaux et les fichiers temporaires à côté. Le propriétaire par défaut est www-root, un utilisateur Linux créé par WardPane. Les sites de la 1.x gardent leurs anciens dossiers.
- Trois gestionnaires
- Aucun gestionnaire (hébergement statique), PHP ou Node.js, choisi par site et modifiable à tout moment. Les réglages des autres gestionnaires sont conservés, revenir en arrière les restaure donc.
- Fichiers statiques
- Mode SPA (les chemins inconnus mènent à index.html), votre propre 404.html, ETags forts avec téléchargements reprenables, redirection HTTP vers HTTPS et liens symboliques qui ne peuvent jamais sortir du dossier du site.
- Environnements d'exécution
- Le panneau liste les versions de PHP installées sur le serveur et les versions majeures de Node.js qu'il prend en charge : 20, 22, 24 et 26, avec la 24 par défaut (la 20 est en fin de vie depuis avril 2026). Les builds de Node.js viennent de nodejs.org et sont vérifiés avec les sommes SHA256 publiées.
- Un menu sur chaque site
- Chaque ligne du tableau des sites a un menu avec toutes les actions de ce site, et un interrupteur désactive puis réactive un site sans rien supprimer.
- Shell dans le navigateur
- Un terminal directement dans le panneau : un shell root dans une session root, ou le shell du propriétaire du site dans le dossier du site. pm2 list et pm2 restart y fonctionnent pour les sites Node.js.
- Export et import
- Tous les sites avec tous leurs réglages, plus la liste de blocage globale, tiennent dans un seul fichier JSON. L'import fusionne ou remplace, vérifie d'abord tout le fichier et ne touche jamais aux fichiers de /var/www.
PHP et Node.js
Chaque site dynamique tourne sous son propre utilisateur Linux dans un bac à sable systemd. Un site défaillant ou piraté ne peut pas lire ses voisins.
- Un pool php-fpm par site
- Pas de pool partagé, pas d'opcache ni de sessions partagés. Le code est en lecture seule pour PHP ; il ne peut écrire que dans tmp/, logs/, data/ et les dossiers que vous indiquez, et PHP ne s'exécute jamais depuis ces dossiers.
- Un bac à sable PHP strict
- Tout le système de fichiers est en lecture seule et noexec, sauf php-fpm lui-même, open_basedir est défini, exec, system, shell_exec, proc_open, popen et putenv sont désactivés, et les appels système sont filtrés.
- .htaccess sans Apache
- Les règles de réécriture, redirections, règles d'accès, Basic auth, en-têtes et la mise en cache de vrais sites fonctionnent tels quels : WordPress, Laravel et les redirections habituelles vers HTTPS et www. Les lignes qu'il ne peut pas appliquer sont affichées, jamais devinées.
- Node.js avec PM2
- Choisissez une version majeure de Node.js, un script npm ou un fichier d'entrée, des variables d'environnement et des limites. Un démon PM2 par propriétaire fait tourner les applications, pm2 fonctionne donc depuis le shell du propriétaire.
- Le proxy devant l'application
- Les fichiers de public/ sont servis directement si vous le souhaitez, le reste va à l'application avec la vraie IP du visiteur dans X-Forwarded-For et X-Real-IP. Les WebSockets passent après les mêmes contrôles de protection.
- Redémarrage, npm install et journaux
- L'onglet Gestionnaire propose des boutons de redémarrage et de npm install (npm ci s'il y a un fichier de verrouillage), les journaux de sortie, d'erreurs et d'installation, et les scripts de package.json au choix.
Certificats et Cloudflare
Les certificats sont émis et renouvelés sans étape manuelle, y compris pour les sites derrière Cloudflare.
- Let's Encrypt, entièrement automatique
- Un certificat par site avec tous ses alias, renouvelé quand il lui reste un tiers de sa durée de vie. Les noms dont le DNS ne pointe pas vers le serveur sont ignorés puis ajoutés dès qu'il y pointe, et le panneau explique pourquoi.
- IPv6 vérifié aussi
- Let's Encrypt essaie d'abord IPv6, chaque enregistrement AAAA doit donc pointer vers le serveur. WardPane les vérifie avant de commander un certificat.
- Un certificat pour l'IP
- L'IP du serveur reçoit un certificat de courte durée, renouvelé tous les quelques jours. Le panneau à l'adresse https://<ip>:1500 s'ouvre sans avertissement.
- Limites de fréquence de Let's Encrypt
- Le panneau ne commande pas de certificat en double, signale en une fois tous les noms en échec d'une commande, attend plus longtemps après chaque échec et remplace un compte ACME désactivé.
- Un jeton Cloudflare en un clic
- Le bouton Créer un jeton Cloudflare ouvre Cloudflare avec les bonnes autorisations déjà remplies. Collez le jeton en retour, et le panneau peut vérifier et corriger les zones de vos sites.
Protection
Chaque site a ses propres contrôles, qui tournent dans le serveur web avant que PHP ou Node.js ne voient la requête. Une adresse n'est bannie que pour une attaque évidente.
- Limite de débit et bannissements
- Chaque adresse peut envoyer 150 requêtes en 10 secondes par défaut. Au-delà, elle reçoit une 404 et un bannissement pour le nombre de minutes choisi. Les visiteurs IPv6 sont comptés et bannis par leur /64, changer d'adresse ne sert donc à rien. Chaque site a sa liste d'autorisation.
- Bot Fight
- Bloque les robots d'IA, les robots SEO, les scanners de vulnérabilités, les scripts et les navigateurs headless, les user agents vides et votre propre liste. Moteurs de recherche et aperçus de liens seulement si vous le choisissez. La supervision et les lecteurs RSS sont laissés tranquilles.
- Sondes et charges malveillantes
- Les requêtes vers /.env, /.git, /wp-login.php et autres noms similaires qui n'existent pas sur le site font bannir l'adresse. Les charges évidentes d'injection SQL, de XSS, de traversée de répertoires et de Log4Shell dans l'URL entraînent un bannissement ; les cas ambigus font seulement rejeter la requête concernée.
- Détection des scans
- De nombreux échecs d'affilée (25 en 60 secondes par défaut) ressemblent à gobuster ou ffuf et font bannir l'adresse. Une image manquante compte pour un dixième d'échec, une vieille page aux images cassées n'est donc pas un scan.
- Robots vérifiés
- Google, Bing, DuckDuckGo, Apple, OpenAI, Anthropic, Perplexity et Ahrefs publient leurs plages d'IP. WardPane les télécharge chaque jour et bannit quiconque prétend être l'un d'eux depuis une autre adresse. Vous pouvez aussi bloquer ces robots par IP, même quand ils se cachent derrière le user agent d'un navigateur.
- Listes d'IP publiques
- Spamhaus DROP, FireHOL level 1 et blocklist.de, actualisées chaque jour, appliquées par site avec un seul interrupteur.
- Géo avec groupes
- Autorisez ou refusez des pays un par un ou par groupes : ex-URSS, CEI, UEE, UE, EEE, Schengen, OTAN, G7, G20, OCDE, BRICS, OCS, ASEAN, Ligue arabe, Mercosur, continents et plus encore. Ajoutez des exceptions et voyez la liste finale des pays.
- Réseaux d'hébergeurs et numéros d'AS
- Bloquez les requêtes venant d'AWS, Azure, Google Cloud, Hetzner, OVH, DigitalOcean, Vultr et d'autres clouds, d'où vient la plupart de l'automatisation, ou de n'importe quel numéro d'AS de votre liste.
- Filtre de langue
- Autorisez ou refusez selon la langue du navigateur, avec un interrupteur distinct pour les requêtes qui n'envoient aucune langue. Un signal supplémentaire utile à côté du pays, par exemple derrière un VPN.
- Appareils
- N'acceptez que Windows, macOS, Linux, Android, iOS ou d'autres, comme filtre pour les navigateurs ordinaires.
- Lien uniquement
- Paramètres d'URL obligatoires : le site ne s'ouvre qu'aux personnes arrivées par votre lien, par exemple ?ref=metaads depuis une publicité. Un cookie signé et, en option, l'IP du visiteur les laissent entrer ensuite. Les chemins des webhooks et des retours de paiement restent ouverts.
- Mot de passe
- Connexion HTTP Basic pour les brouillons et les copies de test d'un site. Les mots de passe sont stockés sous forme de hachages scrypt et vérifiés hors du thread principal, après tous les autres filtres.
- Protection contre le hotlinking
- Les autres sites ne peuvent pas intégrer vos images et fichiers. Choisissez les extensions, les sites autorisés (les jokers fonctionnent) et le traitement des requêtes sans Referer.
- En-têtes de sécurité
- X-Frame-Options, Referrer-Policy, HSTS avec includeSubDomains et preload, Content-Security-Policy et Permissions-Policy par site.
- Pot de miel
- Un chemin interdit par robots.txt. Un humain ne l'ouvre jamais, donc quiconque le demande est banni immédiatement.
- Pages de blocage personnalisées
- Votre propre page et code de statut (404, 403 ou 200) pour les blocages par appareil, bot, géo et lien, servie avec no-store.
- Liste de blocage globale
- Adresses et réseaux bloqués sur tous les sites, stockés sur disque et conservés après les redémarrages. Elle s'applique même là où la protection d'un site est désactivée.
Contrôle du trafic
Décidez qui atteint chaque site, dans quel ordre les règles s'appliquent et ce que voit un visiteur bloqué.
L'ordre des contrôles à chaque requête
- Cloudflare : vraie IP du visiteur, uniquement via Cloudflare
- Liste de blocage globale, puis liste d'autorisation du site
- Limite de débit et bannissements actifs
- Bot Fight : user agents, robots vérifiés, listes d'IP, sondes, charges malveillantes, scans, pot de miel
- Géo : pays et groupes, réseaux d'hébergeurs, numéros d'AS, langue du navigateur
- Appareils
- En-têtes de sécurité et protection contre le hotlinking
- Lien uniquement
- Mot de passe
- Règles .htaccess, puis le gestionnaire : fichiers, PHP ou Node.js
- Vraie IP adaptée à Cloudflare
- L'adresse du visiteur est prise dans CF-Connecting-IP uniquement quand la connexion vient vraiment de Cloudflare. La liste des réseaux est actualisée chaque jour depuis cloudflare.com.
- Uniquement via Cloudflare
- Les requêtes directes vers l'IP du serveur reçoivent une 404, personne ne peut donc contourner le CDN et ses règles.
- Quand l'interrupteur est désactivé
- Un site derrière Cloudflare qui n'est pas indiqué comme tel ne bannit jamais les adresses Cloudflare et bénéficie d'une limite dix fois plus élevée par serveur Cloudflare. Le journal suggère la correction.
- Cloudflare Workers
- Les requêtes d'un Worker sont comptées selon sa zone, avec les limites et bannissements normaux ; le Worker de votre propre zone est traité comme Cloudflare.
- Codes des pages de blocage
- Utilisez 404 pour ressembler à une adresse vide, 403 pour indiquer que la requête est refusée, ou 200 avec votre propre page. Les clients limités ou bannis reçoivent toujours une simple 404.
- Réponses sans risque pour le cache
- Les réponses qui dépendent d'un passage par le lien reçoivent Cache-Control: private et Vary: Cookie, un CDN ne les sert donc jamais à quelqu'un qui n'a pas le lien.
Sécurité du panneau
Le panneau tourne sous l'utilisateur non privilégié wardpane, et sa page de connexion a ses propres limites contre la force brute.
- Connexion root
- En option, connectez-vous en root avec le mot de passe root du serveur. Il est vérifié par unix_chkpwd via un petit assistant root sur un socket que seul le panneau peut ouvrir. Désactivée par défaut.
- Limites contre la force brute
- 5 échecs bloquent une adresse (en IPv6, son /64) pendant 15 minutes, et 50 échecs bloquent son /48. Une vague d'échecs venant de nombreuses adresses ferme la connexion aux adresses inconnues pendant 5 minutes. Les adresses qui se sont connectées au cours des 30 derniers jours continuent de fonctionner.
- Liste d'IP autorisées
- Avec PANEL_ALLOW_IPS défini, le panneau ne répond pas du tout aux autres adresses. Il refuse une liste qui bloquerait l'adresse que vous utilisez.
- Isolation de l'assistant root
- Le panneau écrit l'état souhaité ; un assistant root lancé par systemd vérifie à nouveau chaque valeur avant de créer des utilisateurs, des dossiers et des unités.
- PHP et Node.js isolés
- Utilisateurs Linux par site, système en lecture seule, /tmp privé, aucun nouveau privilège, limites de mémoire et de CPU et, en option, aucune connexion sortante.
- Sommes de contrôle des versions
- Chaque archive est publiée avec sa somme de contrôle SHA-256 et contient le code source complet. L'installateur la télécharge en HTTPS et vérifie le SHA-256 avant d'exécuter quoi que ce soit.
- Des mises à jour réversibles
- Chaque mise à jour fait une sauvegarde avec un script de restauration, vérifie que la nouvelle version démarre et revient en arrière d'elle-même si ce n'est pas le cas.
- Récupération de l'accès
- Si vous vous êtes enfermé dehors, une commande sur le serveur réinitialise la connexion au panneau et la liste d'IP autorisées, et lève les blocages de connexion.
Essayez-le sur un serveur de rechange
L'installation prend quelques minutes sur un Ubuntu 24.04 vierge.