Serveurs cloud
Gestion de pare-feu et de sécurité pour serveur cloud
Every KapsuleHost Server ships with a managed firewall that denies inbound traffic by default, plus brute-force protection, a web application firewall and automatic security patching, all controlled…
Gestion de la Sécurité et du Pare-feu du Serveur Cloud
Chaque serveur KapsuleHost est livré avec un pare-feu géré qui refuse le trafic entrant par défaut, plus une protection contre les attaques par force brute, un pare-feu d'application web et un correctif de sécurité automatique, tous contrôlés à partir d'une seule page dans KPanel.
Les paramètres par défaut sont choisis pour qu'un nouveau serveur soit sécurisé avant que vous ne touchiez à quoi que ce soit. Ce que vous ajoutez par-dessus est généralement juste les ports dont votre propre application a besoin. Ce guide vous explique toute la page Gestion du serveur, car le pare-feu est une section et les autres sections sont ce qui vous évite d'avoir besoin du pare-feu en premier lieu.
Ouverture de la Page de Gestion
- Connectez-vous à KPanel.
- Cliquez sur Cloud Servers dans la barre latérale gauche, puis cliquez sur votre serveur.
- Cliquez sur Management dans les boutons d'action en haut de la page.
L'adresse directe est /cloud-servers/<server-id>/management. La page se décrit comme « Firewall, OS patches, fail2ban, and ModSecurity. Changes apply over SSH within seconds. »
Si une bannière indique « Live apply unavailable. Changes will save to the next provisioning run but won't take effect immediately », le panneau ne peut pas atteindre le serveur en ce moment. Vos paramètres sont toujours enregistrés, ils ne sont simplement pas appliqués immédiatement. Vérifiez que le serveur est en cours d'exécution et accessible.
La Politique de Pare-feu par Défaut
La section Firewall (UFW) expose la politique en une ligne : « Default-deny inbound. SSH (22) is always open. App-stack ports open automatically. Add custom rules below. »
En pratique, cela signifie :
- Rien ne peut atteindre votre serveur depuis Internet à moins qu'une règle ne le permette.
- Le port 22 est toujours ouvert, donc un changement de pare-feu ne peut jamais vous enfermer hors de la machine.
- Les ports dont votre pile d'applications a besoin, comme 80 et 443 pour une application web, sont ouverts pour vous.
- Le trafic sortant du serveur n'est pas restreint.
Sans règles personnalisées, la section affiche « No custom rules. Defaults: SSH + app-stack ports. » C'est un état sain, non pas une configuration manquante.
Ajout d'une Règle Personnalisée
Ajoutez une règle quand vous exécutez quelque chose sur un port que la politique par défaut ne couvre pas : une application Node sur 3000, une base de données que vous devez atteindre directement sur 5432, un serveur de jeux ou de médias sur un port UDP.
- Ouvrez la section Firewall (UFW).
- Tapez le numéro de Port dans le premier champ. Les valeurs valides sont de 1 à 65535.
- Choisissez TCP ou UDP.
- Choisissez Allow ou Deny.
- Cliquez sur Add.
La règle apparaît dans la liste avec un badge ALLOW ou DENY et le port et le protocole, par exemple 3000/tcp. Elle est poussée sur le serveur via la connexion de gestion en quelques secondes.
Pour supprimer une règle, cliquez sur le X à la fin de sa ligne. La suppression d'une règle Allow ferme ce port à nouveau immédiatement.
L'exposition d'un port de base de données à tout Internet est l'une des façons les plus courantes qu'un serveur se fasse compromettre. Avant d'autoriser 3306, 5432, 6379 ou 27017, demandez-vous si la chose qui se connecte pourrait atteindre la base de données via l'interface loopback du serveur ou un réseau privé à la place. Si elle doit réellement être accessible de l'extérieur, assurez-vous que le service lui-même exige une authentification forte et du chiffrement.
Ajoutez la règle en premier, puis démarrez le service. Un service qui démarre derrière un port fermé a exactement le même aspect qu'un service dont le démarrage a échoué, et vous pouvez perdre beaucoup de temps à déboguer la mauvaise couche.
Piles d'Applications
La section App stack indique à la plateforme quel type d'application ce serveur exécute, afin que le préréglage de durcissement puisse être ajusté en conséquence. L'installation d'une application via le panneau le configure pour vous.
Les piles reconnues sont WordPress, WooCommerce, Ghost, Nextcloud, GitLab, Mattermost, Generic web et No app stack. La section s'explique ainsi : « The hardening preset is tuned to your app. Installing an app from the marketplace auto-sets this. »
La pile affecte les ports qui s'ouvrent automatiquement et comment les autres protections sont ajustées, plus visiblement dans fail2ban.
fail2ban
fail2ban surveille les tentatives d'authentification et bannit les adresses qui continuent à échouer. Il est activé par défaut et la page la décrit comme : « Bans IPs that brute-force SSH. For WordPress sites, adds wp-login.php protection too. »
Laissez-le activé. C'est la protection la moins coûteuse de la page, elle ne coûte rien en performance, et elle transforme un bruit de fond constant de tentatives de devinage de mots de passe en rien du tout. Sur une pile WordPress ou WooCommerce, elle protège aussi le formulaire de connexion, qui est l'endroit où la plupart des attaques contre WordPress atterrissent réellement.
ModSecurity, le Pare-feu d'Application Web
ModSecurity inspecte les requêtes HTTP par rapport à l'ensemble de règles OWASP Core Rule Set et signale celles qui ressemblent à des attaques. Sur un serveur KapsuleHost, il démarre en mode détection uniquement : « OWASP Core Rule Set in DetectionOnly mode by default. Logs suspicious traffic without blocking; flip to active mode in your server once tuned. »
La détection seule est le bon point de départ. L'ensemble de règles Core Rule Set est approfondi, et sur une véritable application, certaines requêtes légitimes correspondront à une règle. Exécutez-le en mode détection seule pendant un certain temps, lisez les journaux, déterminez quelles règles votre propre trafic active, et seulement ensuite basculez au blocage dans le serveur.
L'activation du blocage sans ajustement préalable peut casser votre propre site. Les soumissions de formulaires avec du texte enrichi, les téléchargements de fichiers et les clients API avec des charges utiles inhabituelles sont les victimes habituelles. Vérifiez vos journaux avant de basculer.
Correctif Automatique du Système d'Exploitation
Les mises à jour de sécurité sont appliquées pour vous. La section explique le filet de sécurité : « Security updates applied automatically. Snapshot-protected: a server snapshot is taken before each run, with automatic rollback if the server becomes unreachable after reboot. »
Deux paramètres se trouvent sous le bouton bascule :
- Allow automatic reboot when a kernel update needs it (only during quiet hours below). Les mises à jour du noyau ne prennent effet qu'après un redémarrage. Si vous le désactivez, les correctifs du noyau sont installés mais ne sont pas actifs jusqu'à ce que vous redémarriez vous-même.
- Quiet window (UTC), une heure de début et de fin. Les redémarrages se produisent uniquement dans cette fenêtre. Réglez-la sur les heures les plus calmes pour votre audience, et n'oubliez pas que le champ est en UTC, pas dans votre heure locale.
Laissez le correctif automatique activé. La grande majorité des serveurs compromis exécutent des logiciels avec un correctif qui a été publié des semaines plus tôt. Un snapshot de pré-correctif avec restauration automatique signifie que l'objection habituelle, qu'une mise à jour pourrait casser quelque chose, est déjà gérée.
Historique des Correctifs et Exécution Immédiate d'un Correctif
La section Patch history répertorie chaque exécution avec un statut de RUNNING, SUCCESS, ROLLED_BACK, FAILED ou SKIPPED, le nombre de paquets mis à jour, si le serveur a redémarré et l'heure de démarrage.
Pour appliquer les correctifs immédiatement au lieu d'attendre le calendrier, cliquez sur Run patch now. La confirmation se lit : « A snapshot is created first. The server stays online except for a brief reboot if a kernel update needs it. »
Une entrée ROLLED_BACK signifie que le filet de sécurité a fait son travail : le serveur n'est pas revenu correctement après un redémarrage, donc le snapshot de pré-correctif a été restauré. Voir Cloud Server Snapshots pour savoir comment ces snapshots fonctionnent.
Une Base Raisonnable
Pour la plupart des serveurs, c'est toute la configuration de sécurité :
| Paramètre | Recommandé |
|---|---|
| Pare-feu | Activé, règles par défaut, plus seulement les ports dont votre application a besoin |
| fail2ban | Activé |
| ModSecurity | Activé, détection seule jusqu'à ce que vous ayez lu les journaux |
| Correctif automatique du système d'exploitation | Activé, avec redémarrages autorisés dans une fenêtre calme |
| Authentification SSH | Clés, pas des mots de passe |
La dernière ligne ne se trouve pas sur cette page mais compte plus que le reste réuni. Voir Connecting to Your Cloud Server With SSH.
Dépannage
« Could not load management config. » Le panneau n'a pas pu lire les paramètres de ce serveur. Rechargez, et vérifiez que le serveur existe et est provisionné.
« Port must be 1-65535. » Le champ de port prend un nombre entier dans cette plage. Les plages et les noms de service ne sont pas acceptés ici.
Ma règle s'est enregistrée mais rien n'a changé. Recherchez la bannière « Live apply unavailable ». Si elle s'affiche, le changement est stocké mais pas encore poussé sur le serveur.
Je peux atteindre mon service à partir d'un réseau mais pas d'un autre. C'est généralement votre propre pare-feu sortant, pas celui du serveur. Testez à partir d'une connexion différente avant de modifier les règles ici.
Une exécution de correctif affiche FAILED. Lisez le message d'erreur sur la ligne. Un disque plein est la cause la plus courante. Libérez de l'espace et cliquez sur Run patch now.
Le trafic légitime a commencé à être bloqué. Si vous avez basculé ModSecurity en mode blocage, remettez-le en mode détection seule, lisez les journaux et identifiez la règle avant de réessayer.
Si une règle de pare-feu refuse de s'appliquer, ou si vous êtes enfermé hors d'un service que vous avez autorisé, envoyez un e-mail à support@kapsulehost.com avec le nom du serveur, le port et ce que vous vous attendez à atteindre.