Sécuriser WHM et cPanel sans bloquer vos administrateurs

Renforcer WHM peut interrompre l’administration si une restriction réseau, cPHulk et SSH sont modifiés simultanément. Security Advisor donne un point de départ utile ; la priorité opérationnelle consiste à conserver un accès de récupération vérifié pendant chaque changement.

Intention de recherche : sécuriser un serveur cPanel/WHM de production sans perdre l’accès administrateur. Exécutez les commandes sur votre serveur autorisé, avec les privilèges nécessaires.

1. Auditer l’exposition et préparer le secours

Problème et causes possibles

Un administrateur peut être bloqué par une IP de sortie différente, une règle IPv6 oubliée, un seuil anti-brute-force trop agressif, un code MFA invalide ou une configuration SSH incorrecte. Un service protégé par mot de passe demeure exposé au réseau tant que le pare-feu le permet.

Dans WHM, Security Center, ouvrez Security Advisor et classez les constats. Testez la console hors bande fournie par votre hébergeur, avec les droits nécessaires pour corriger le réseau et SSH. Une deuxième session SSH n’est pas un accès indépendant si le réseau est coupé.

ss montre les sockets en écoute, pas ce qu’Internet peut atteindre. sshd -T affiche la configuration effective de base ; les règles Match nécessitent aussi une vérification pour le compte et l’adresse concernés.

Depuis une autre machine autorisée, adaptez l’adresse et les ports :

Ce contrôle TCP ciblé ne constitue pas un inventaire complet. Vérifiez également les ports réellement utilisés pour SMTP, IMAP, DNS TCP/UDP, FTP passif ou services additionnels, en IPv4 et IPv6. Ne bloquez pas les ports clients parce qu’ils ne servent pas à l’administration.

Sauvegarder avant modification

Ce répertoire contient potentiellement des clés privées : gardez-le accessible uniquement à root. Exportez séparément la configuration du pare-feu réellement actif et les règles réseau du fournisseur. Relevez les listes cPHulk, les restrictions WHM et le plan de récupération. Les sauvegardes doivent inclure les fichiers SSH chargés par Include, notamment /etc/ssh/sshd_config.d/ lorsqu’il existe.

2. Appliquer les protections dans un ordre contrôlé

1. MFA : configurez Two-Factor Authentication dans WHM, Security Center, pour les administrateurs concernés. Testez une nouvelle connexion et la procédure de secours propre à votre installation avant de fermer la session initiale. La MFA WHM ne remplace pas une politique SSH.
2. cPHulk : examinez les historiques et définissez les seuils dans cPHulk Brute Force Protection. Autorisez seulement les IP d’administration stables et maîtrisées si une exception est nécessaire ; un réseau entier ou une IP partagée crée une exception excessive. Testez une connexion légitime et vérifiez les notifications.
3. SSH : fournissez une clé par administrateur et vérifiez son accès dans une nouvelle session. Avec WHM, Manage Shell Access, retirez l’accès inutile et limitez les comptes qui en ont besoin. Avant de désactiver l’authentification par mot de passe via SSH Password Authorization Tweak, testez la clé et l’élévation de privilèges. Ne bloquez root qu’après validation d’un autre chemin administrateur.
4. Validation SSH : après une modification de /etc/ssh/sshd_config ou de ses inclusions :

Un résultat sans erreur valide la syntaxe, pas votre capacité à vous connecter. Appliquez ensuite par la procédure de service adaptée à votre OS ou WHM, puis testez une nouvelle session tout en conservant l’ancienne. 5. Pare-feu et WHM : utilisez un seul gestionnaire cohérent avec l’installation. Ajoutez d’abord l’accès depuis le réseau administrateur ou VPN, vérifiez-le, puis restreignez SSH et WHM 2087. Répliquez la politique en IPv6. N’appliquez pas une règle générique deny-all sans les services clients et l’accès de secours. 6. Alertes et mises à jour : contrôlez Contact Manager et Update Preferences dans WHM. Testez la réception des alertes ; planifiez mises à jour et redémarrages avec sauvegarde, compatibilité vérifiée et accès console.

Retour arrière

Restaurez d’abord la règle qui a fermé l’accès, depuis la console indépendante si nécessaire. Pour SSH, reprenez les fichiers sauvegardés concernés, vérifiez avec sshd -t, puis appliquez au service. Ne restaurez pas toutes les protections en bloc : identifiez le changement fautif. Pour cPHulk ou MFA, utilisez la procédure de récupération préparée, sans élargir durablement les exceptions.

3. Vérification finale

Reconnectez-vous à WHM et SSH depuis le réseau autorisé. Confirmez le refus depuis un réseau non autorisé pour les interfaces restreintes, puis testez sites, e-mails et DNS depuis l’extérieur. Relancez Security Advisor et vérifiez que les alertes parviennent au bon destinataire.

Erreurs courantes

Changer de port SSH ne remplace pas les clés ni le filtrage. Une session déjà ouverte ne prouve pas qu’une nouvelle connexion fonctionne. N’installez pas plusieurs gestionnaires de pare-feu qui réécrivent les mêmes règles.

Recommandations en production

Documentez propriétaires des accès, IP autorisées, console de secours et dates de révision. Révoquez les comptes inutilisés et testez régulièrement la récupération après changement de fournisseur réseau.

Sources : cPanel, Security Advisor, sécurisation SSH.

Sur les réseaux sociaux

Retrouvez-le dans nos publications

Les étapes clés de cet article, en carrousel. Suivez-nous pour découvrir les prochaines. Nos publications sont rédigées en anglais.

• Voir sur Facebook
• Voir sur Instagram