Passer au contenu 
Je vais te montrer comment Panneau de contrôle d'hébergement Sécurité pour WHM/cPanel et de fermer les portes d'entrée typiques. L'accent est mis sur les mises à jour, 2FA, le renforcement SSH, le pare-feu, la protection contre les logiciels malveillants, les sauvegardes, TLS, les protocoles, les droits et le renforcement PHP - expliqué de manière pratique et directement applicable pour Admins.
Points centraux
- Mises à jour introduire de manière conséquente et tenir à jour les modules tiers
- 2FA forcer et imposer des mots de passe forts
- SSH avec des clés, sans connexion root, changement de port
- Pare-feu configurer strictement et utiliser les alertes de log
- Sauvegardes automatiser, chiffrer, tester la restauration
Mise à jour de la base de données : Gestion des correctifs sans failles
Sans temps de réponse Mises à jour toute installation de WHM/cPanel reste vulnérable, car des failles connues sont ouvertes. J'active les mises à jour automatiques dans „Configuration du serveur > Préférences de mise à jour“ et je vérifie les messages du journal chaque jour. Je tiens à jour les modules tiers tels que les gestionnaires PHP, les caches ou les plugins de sauvegarde, tout comme Apache, MariaDB/MySQL et PHP. Lors des fenêtres de maintenance, je planifie des redémarrages afin que les mises à jour du noyau et des services soient pleinement efficaces. Je réduis ainsi sensiblement la surface d'attaque et empêche l'exploitation d'anciens systèmes. Versions.
Politique de mot de passe et 2FA qui stoppe les attaques
Les tentatives de force brute échouent si j'ai de fortes Mots de passe et en activant 2FA. Dans WHM, je définis une force de mot de passe d'au moins 80, j'interdis la réutilisation et je définis des intervalles de changement de 60 à 90 jours. Pour les comptes à privilèges, j'active l'authentification à facteurs multiples dans le Security Center et j'utilise des applications TOTP. Les gestionnaires de mots de passe facilitent le respect des mots de passe longs et aléatoires. J'évite ainsi que des données d'accès compromises sans deuxième facteur ne soient utilisées pour accéder au site. Intrusion plomb.
Mettre en place un accès SSH sécurisé
SSH reste un outil critique Chemin d'accès dans le système, c'est pourquoi je mise sur les clés plutôt que sur les mots de passe. Je modifie le port 22 par défaut afin de réduire les analyses triviales et je désactive complètement PermitRootLogin. Les administrateurs reçoivent des comptes individuels avec sudo, afin que je puisse attribuer chaque action. cPHulk ou Fail2Ban étrangle automatiquement les échecs répétés et bloque les IP suspectes. En outre, je limite SSH à certains réseaux ou VPN, ce qui réduit le Accès est fortement limitée.
Règles de pare-feu qui ne laissent passer que le strict nécessaire
Avec une stricte Pare-feu je bloque tout ce qui n'est pas explicitement autorisé. CSF (ConfigServer Security & Firewall) ou iptables me permettent de ne laisser ouverts que les ports nécessaires pour le panneau, le courrier et le web. Je mets les accès admin en liste blanche sur des IP fixes et j'enregistre des notifications pour les modèles suspects. Si de nouveaux services sont nécessaires, je documente chaque ouverture de port et je les supprime lorsqu'ils sont obsolètes. utile Conseils sur les pare-feu et les correctifs s'appliquent à tous les panels, même si je me concentre ici sur cPanel, et permettent d'éviter les configurations erronées.
Protection contre les logiciels malveillants à plusieurs niveaux
des téléchargements de fichiers, des plugins compromis ou des Scripts introduisent des codes malveillants si personne ne vérifie. Je prévois des analyses quotidiennes et hebdomadaires avec ClamAV, ImunifyAV ou Imunify360. Une détection en temps réel stoppe de nombreuses attaques avant qu'elles ne causent des dommages. Les découvertes sont immédiatement isolées par le système et j'en analyse la cause afin d'éviter toute répétition. En complément, je mise sur des règles de téléchargement restrictives et sur la mise en quarantaine, afin qu'une seule attaque ne devienne pas une menace. Cascade volonté.
Tester la stratégie de sauvegarde et de restauration
Les sauvegardes ne servent pas à grand-chose si je ne les fais pas régulièrement. teste. Dans WHM, je planifie des sauvegardes quotidiennes, hebdomadaires et mensuelles, je verrouille les archives et je les stocke hors site. Des tests de restauration avec des comptes aléatoires montrent si les données, les e-mails et les bases de données peuvent être restaurés proprement. Les sauvegardes versionnées protègent contre les manipulations inaperçues qui ne sont remarquées que plus tard. Tu peux aller plus loin en cliquant sur des sauvegardes automatisées, J'y présente les écueils typiques et les calendriers judicieux qui minimisent les pannes et permettent de réduire les coûts. Coûts économiser.
Forcer TLS/SSL partout
Les connexions non cryptées sont une porte ouverte Portail pour les enregistrements et les manipulations. J'active AutoSSL, je définis des redirections HTTPS forcées et je vérifie la validité des certificats. Pour IMAP, SMTP et POP3, j'utilise exclusivement des ports SSL et je désactive l'authentification en texte clair. Dans la mesure du possible, je connecte également les services internes via TLS. Je réduis ainsi considérablement les risques liés à la MIT et sécurise les mots de passe, les cookies et les données. Réunions.
Lire les protocoles et utiliser les alarmes
Les logs me disent ce qui s'est passé sur le Serveur se produit vraiment. Je vérifie régulièrement /usr/local/cpanel/logs/access_log, /var/log/secure et les logs de messagerie pour voir s'il y a des anomalies. Des outils comme Logwatch ou GoAccess produisent des aperçus rapides des tendances et des pics. En cas de tentatives de connexion répétées, de nombreuses erreurs 404 ou de pics soudains de ressources, je fais déclencher des alarmes. Une détection précoce permet de gagner du temps, d'éviter des dommages importants et d'obtenir plus rapidement des résultats. Mesures.
Attribution des droits selon le principe du moindre privilège
Chaque utilisateur ne reçoit que les Droits, qui sont absolument nécessaires. Dans WHM, je limite les revendeurs, j'utilise des listes de fonctionnalités pour des partages granulaires et je désactive les outils à risque. Je supprime systématiquement les comptes orphelins, car les accès non utilisés sont souvent oubliés. Je définis les droits de fichiers de manière restrictive et je garde les fichiers sensibles en dehors du webroot. Les personnes qui s'intéressent de plus près aux modèles de rôles trouveront des informations sur les thèmes suivants Rôles et droits des utilisateurs que j'applique 1:1 aux concepts de cPanel et qui me permettent de réduire considérablement les taux d'erreur. abaisse.
Durcissement de PHP et du serveur web sans lest
Beaucoup d'attaques visent des Fonctions dans PHP et le serveur web. Je désactive exec(), shell_exec(), passthru() et les fonctions similaires, j'active open_basedir et je désactive allow_url_fopen et allow_url_include. ModSecurity avec des règles appropriées filtre les requêtes suspectes avant qu'elles n'atteignent les applications. Via l'éditeur MultiPHP INI, je contrôle les valeurs par vHost afin d'encapsuler proprement les exceptions. Moins il y a de surface d'attaque active, plus il est difficile de Exploitation.
Ranger : éliminer ce qui est inutile
Plugins inutilisés, thèmes et Modules ouvrent des opportunités pour les pirates. Je vérifie régulièrement ce qui est installé et je supprime tout ce qui n'a pas d'utilité claire. En outre, je désinstalle les anciennes versions de PHP et les outils dont personne n'a plus besoin. Chaque réduction permet d'économiser de l'entretien, de réduire les risques et de faciliter les audits. Le système reste ainsi allégé et meilleur contrôlable.
Formation et sensibilisation des administrateurs et des utilisateurs
La technique ne protège que si les gens suivre. Je sensibilise les utilisateurs au phishing, j'explique le 2FA et je montre les règles de sécurité des mots de passe. Je forme les équipes d'administrateurs aux politiques SSH, aux modèles de logs et aux procédures d'urgence. De courtes formations récurrentes sont plus efficaces que de rares sessions marathon. Des instructions claires, des listes de contrôle et des exemples tirés du quotidien augmentent l'acceptation et réduisent les coûts. Erreur.
Comparaison des fournisseurs : fonctions de sécurité
Celui qui achète un hébergement doit être attentif à des Critères comme le durcissement du panneau, les services de sauvegarde et les temps de support. Le tableau suivant présente une évaluation condensée des fournisseurs courants. J'évalue le renforcement du panel, les offres de pare-feu et de sauvegarde ainsi que la qualité de l'assistance. Ces facteurs déterminent la rapidité avec laquelle une attaque est contrée et un système restauré. Un bon choix réduit la charge de travail et augmente Disponibilité.
| Placement | Fournisseur | Protection du panneau | Pare-feu/sauvegarde | Assistance aux utilisateurs |
|---|---|---|---|---|
| 1 | webhoster.de | Excellent | Très bon | Excellent |
| 2 | Contabo | Bon | Bon | Bon |
| 3 | Bluehost | Bon | Bon | Bon |
Isolation et limites de ressources : limiter les dégâts
De nombreux incidents dégénèrent parce qu'un compte compromis affecte l'ensemble du système. J'isole systématiquement les comptes : PHP-FPM par utilisateur, utilisateurs et groupes séparés, suEXEC/FCGI au lieu de l'interpréteur global. Avec LVE/CageFS (supporté par les piles cPanel courantes), je bloque les utilisateurs dans leur propre environnement et je fixe des limites pour le CPU, la RAM, les E/S et les processus. Les limitations empêchent ainsi qu'un seul compte ne déclenche un DoS contre ses voisins. En outre, j'active le réglage per-MPM/Worker et je limite les connexions simultanées afin que les pics restent contrôlables.
Durcissement du système et du système de fichiers
Je monte les répertoires temporaires comme /tmp, /var/tmp et /dev/shm avec noexec,nodev,nosuid, pour empêcher l'exécution de fichiers binaires. Je lie /var/tmp à /tmp pour que les règles soient cohérentes. Les répertoires en écriture globale reçoivent le bit sticky. Je n'installe pas les compilateurs et les outils de construction de manière globale et je n'en retire pas l'accès aux utilisateurs. En outre, je durcis le noyau avec des paramètres sysctl (par exemple, désactiver le transfert IP, désactiver les redirections ICMP, activer les cookies SYN) et je garde les services inutiles désactivés de manière permanente via systemctl. Une ligne de base propre empêche les exploits triviaux de fonctionner.
Peaufinage du TLS et du protocole
Je limite les protocoles à TLS 1.2/1.3, désactive les crypteurs non sécurisés et active l'OCSP Stapling. HSTS impose HTTPS à travers le navigateur, ce qui rend les attaques de rétrogradation plus difficiles. Pour les services Exim, Dovecot et cPanel, je définis des politiques de chiffrement identiques afin d'éviter les dérives faibles. Dans WHM > Tweak Settings, j'impose „Require SSL“ pour tous les logins et désactive les ports non cryptés lorsque c'est possible. Ainsi, le niveau de transport reste fort de manière cohérente.
En-tête de sécurité et protection des applications
Outre ModSecurity, je mise sur des en-têtes de sécurité comme Content-Security-Policy (CSP), X-Frame-Options, X-Content-Type-Options et Referrer-Policy. J'enregistre les paramètres par défaut de manière globale et ne les écrase que pour les exceptions contrôlées par vHost. Le Rate-Limiting (par ex. mod_evasive ou les équivalents NGINX dans les configurations de reverse proxy) freine le Credential-Stuffing et le Scraping. Important : tester régulièrement les règles WAF et réduire les fausses alertes, sinon les équipes contournent les mécanismes de protection. La protection n'est efficace que si elle est acceptée et exploitée de manière stable.
Sécurité de la messagerie : SPF, DKIM, DMARC et contrôles sortants
L'abus via le courrier sortant nuit à la réputation et aux listes d'adresses IP. Je signe les messages avec DKIM, je publie des enregistrements SPF précis et je définis des politiques DMARC qui passent progressivement de none à quarantine/reject. Dans Exim, je limite les destinataires par heure et les messages par plage horaire par domaine, j'active des limites de taux d'authentification et je bloque des comptes en cas de comportement de spam. Les contrôles RBL et la cohérence HELO/Reverse-DNS empêchent que le serveur lui-même ne devienne une source de spam. Ainsi, la distribution et la réputation de l'expéditeur restent stables.
Sécuriser les bases de données
Je renforce MariaDB/MySQL en supprimant les utilisateurs anonymes et les bases de données de test, en interdisant la racine à distance et en limitant la racine à l'authentification par socket. Je définis des comptes autorisés plus granulaires par application et environnement pour les utilisateurs d'applications (uniquement les opérations CRUD nécessaires). Les connexions des hôtes externes se font, si nécessaire, via TLS, les certificats font l'objet d'une rotation. Des tâches ANALYZE/OPTIMIZE régulières et une surveillance des logs (Slow Query Log) permettent de distinguer les variations de performance des attaques.
Politiques d'API, de jetons et d'accès à distance
cPanel/WHM propose des jetons d'API avec des profils d'autorisation. Je n'attribue des jetons qu'avec des scopes minimaux, je fixe des durées courtes, je les fais tourner régulièrement et j'enregistre chaque utilisation. L'automatisation externe (par ex. le provisionnement) s'effectue via des comptes de service dédiés, et non via des utilisateurs admin. Dans Tweak Settings, j'active la validation IP pour les sessions, je définis des délais de session serrés et je force les cookies sécurisés. Pour les accès externes, la règle est la suivante : VPN d'abord, panneau ensuite.
Monitoring, métriques et détection d'anomalies
En plus des logs, je regarde les métriques : CPU steal, IO wait, changement de contexte, états TCP, taux de connexion, files d'attente de courrier, proportions 5xx et hits WAF. Je définis des seuils par heure de la journée afin que les sauvegardes nocturnes ne produisent pas de fausses alertes. Je mesure le RPO/RTO en continu en enregistrant la durée de restauration et l'état des données. J'observe le trafic sortant (mail, HTTP) pour détecter les sauts - souvent le premier signal de scripts compromis. De bonnes métriques rendent la sécurité visible et planifiable.
Contrôles d'intégrité et audit
Avec AIDE ou des outils comparables, je capture une ligne de base propre et vérifie régulièrement les fichiers système, les binaires et les configurations critiques pour voir s'ils ont été modifiés. auditd régule les syscalls que je suis (par exemple setuid/setgid, accès à shadow, modifications de sudoers). En combinaison avec le log-shipping, j'obtiens une piste médico-légale solide si quelque chose se passe. L'objectif n'est pas de tout journaliser, mais de détecter les événements pertinents et critiques pour la sécurité et de les archiver de manière à ce qu'ils puissent être révisés.
Gestion de la configuration et contrôle de la dérive
Les modifications manuelles sont la source d'erreur la plus fréquente. Je conserve les paramètres du système et du tableau de bord sous forme de code et je les applique de manière reproductible. Des images d'or pour les nouveaux nœuds, des playbooks clairs pour les mises à jour et un principe de double contrôle pour les modifications critiques empêchent toute dérive. Je documente les modifications avec des tickets de changement, y compris le chemin de retour. En travaillant de manière reproductible, on peut calculer les risques et réagir plus rapidement en cas d'urgence.
Hygiène de Cron et des tâches
Je contrôle les tâches cron de manière centralisée : Uniquement les tâches nécessaires, des durées d'exécution aussi courtes que possible, des logs propres. cron.allow/deny limite les personnes autorisées à créer des tâches cron. J'accorde une attention particulière aux nouveaux cronjobs issus de sauvegardes de clients. J'interprète les commandes inattendues ou voilées comme des signaux d'alarme. Ici aussi, mieux vaut un petit nombre de tâches bien documentées qu'un patchwork confus.
Plan d'urgence, exercices et redémarrage
Un Incident-Runbook avec des étapes claires permet, en cas d'urgence, d'économiser des minutes qui sont décisives pour la panne ou la disponibilité. Je définis les voies de notification, les étapes d'isolation (réseau, comptes, services), les priorités pour les canaux de communication et les pouvoirs de décision. Des tests de redémarrage (tabletop et exercices de restauration réels) montrent si le RTO/RPO est réaliste. Chaque incident est suivi d'une analyse post-mortem propre avec une liste de mesures que je traite de manière cohérente.
Bilan succinct
Avec des Étapes je développe la sécurité de WHM/cPanel de manière mesurable : Mises à jour, 2FA, durcissement SSH, pare-feux stricts, contrôle des logiciels malveillants, sauvegardes testées, TLS, analyse des logs, droits minimaux et PHP allégé. Chaque mesure réduit les risques et permet de maîtriser les incidents. Mets en œuvre ces points par petites étapes, documente les modifications et respecte des routines de maintenance fixes. Ainsi, ton panel reste résistant et tu peux réagir de manière structurée en cas d'urgence. En s'y tenant, on réduit les temps d'arrêt, on protège les données et on évite des coûts élevés. Suivre.
