Aller au contenu
Sommaire
Serveurs

Gestion du pare-feu et de la sécurité du serveur Cloud

Traduction automatique. L'original en anglais est disponible si besoin.

Chaque serveur KapsuleHost est livré avec un pare-feu géré qui refuse le trafic entrant par défaut, ainsi qu'une protection contre les attaques par force brute, un pare-feu pour applications web et des correctifs de sécurité automatiques, tous contrôlés depuis une seule page dans KPanel.

Les paramètres par défaut sont choisis pour que tout nouveau serveur soit sûr avant que vous n'y touchiez à quoi que ce soit. Ce que vous ajoutez généralement correspond aux ports dont votre propre application a besoin. Ce guide vous fait parcourir toute la page Gestion du serveur, car le pare-feu en 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

  1. Connectez-vous à KPanel.
  2. Cliquez sur Serveurs Cloud dans la barre latérale gauche, puis cliquez sur votre serveur.
  3. 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 suit : « Pare-feu, correctifs du système d'exploitation, fail2ban et ModSecurity. Les modifications s'appliquent via SSH en quelques secondes. »

La page Gestion du serveur pour un serveur cloud dans KPanel

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 pour l'instant. Vérifiez que le serveur est en cours d'exécution et accessible.

La politique de pare-feu par défaut

La section Pare-feu (UFW) énonce 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 sauf si une règle l'autorise.
  • Le port 22 est toujours ouvert, donc un changement de pare-feu ne peut jamais vous bloquer l'accès à la machine.
  • Les ports dont votre pile d'application a besoin, comme 80 et 443 pour une application web, sont ouverts pour vous.
  • Le trafic sortant du serveur n'est pas limité.

Sans règles personnalisées, la section affiche « No custom rules. Defaults: SSH + app-stack ports. » C'est un état sain, 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 jeu ou multimédia sur un port UDP.

  1. Ouvrez la section Pare-feu (UFW).
  2. Tapez le numéro du Port dans le premier champ. Les valeurs valides vont de 1 à 65535.
  3. Choisissez TCP ou UDP.
  4. Choisissez Allow ou Deny.
  5. 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 vers 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 immédiatement ce port.

Exposer un port de base de données à Internet entier est l'une des façons les plus courantes dont un serveur est compromis. Avant d'autoriser 3306, 5432, 6379 ou 27017, demandez-vous si ce qui se connecte pourrait atteindre la base de données via l'interface loopback du serveur lui-même ou un réseau privé à la place. Si cela doit vraiment être accessible de l'extérieur, assurez-vous que le service lui-même nécessite une authentification forte et un chiffrement.

Ajoutez d'abord la règle, puis démarrez le service. Un service qui se lance derrière un port fermé ressemble exactement à un service qui n'a pas démarré, et vous pouvez passer beaucoup de temps à déboguer la mauvaise couche.

Piles d'application

La section Pile d'application indique à la plateforme quel type d'application ce serveur exécute, afin que le préréglage de renforcement puisse y être adapté. L'installation d'une application via le panneau définit cela pour vous.

Les piles reconnues sont WordPress, WooCommerce, Ghost, Nextcloud, GitLab, Mattermost, Generic web et No app stack. La section se décrit comme suit : « 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 la façon dont les autres protections sont réglées, notamment visiblement dans fail2ban.

fail2ban

fail2ban surveille les tentatives d'authentification et bannit les adresses qui échouent régulièrement. Il est activé par défaut et la page le décrit comme suit : « 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 mot de passe en rien du tout. Sur une pile WordPress ou WooCommerce, elle protège également le formulaire de connexion, qui est l'endroit où la plupart des attaques contre WordPress se produisent réellement.

ModSecurity, le pare-feu pour applications web

ModSecurity inspecte les demandes HTTP contre l'ensemble de règles de base OWASP 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 uniquement est le bon point de départ. L'ensemble de règles Core Rule Set est complet, et sur une vraie application, certaines demandes légitimes correspondront à une règle. Exécutez-le en mode détection-uniquement pendant un certain temps, lisez les journaux, déterminez les règles auxquelles votre propre trafic déclenche, et seulement après passez au blocage à l'intérieur du serveur.

Activer le blocage sans tuner au 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 inhabituelles sont les victimes habituelles. Vérifiez vos journaux avant de basculer.

Application automatique des correctifs du système

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 situent 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 laissez cela désactivé, 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 une heure de fin. Les redémarrages ne se produisent que dans cette fenêtre. Définissez-la aux heures les plus calmes pour votre audience, et rappelez-vous que le champ est en UTC, pas votre heure locale.

Laissez la mise à jour automatique activée. L'immense majorité des serveurs compromis exécutent des logiciels avec un correctif publié des semaines auparavant. Un instantané antérieur à la correction avec restauration automatique signifie que l'objection habituelle, à savoir qu'une mise à jour pourrait casser quelque chose, est déjà traitée.

Historique des correctifs et application d'un correctif maintenant

La section Historique des correctifs répertorie chaque exécution avec un statut de RUNNING, SUCCESS, ROLLED_BACK, FAILED ou SKIPPED, le nombre de packages mis à jour, si le serveur a redémarré, et l'heure à laquelle il a démarré.

Pour appliquer immédiatement les correctifs plutôt que d'attendre le calendrier, cliquez sur Appliquer les correctifs maintenant. La confirmation se lit comme suit : « 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 rempli sa fonction : le serveur n'a pas redémarré correctement, donc l'instantané antérieur à la correction a été restauré. Consultez Instantanés de serveur cloud pour savoir comment ces instantanés fonctionnent.

Une baseline raisonnable

Pour la plupart des serveurs, voici toute la configuration de sécurité :

ParamètreRecommandé
Pare-feuActivé, règles par défaut, plus uniquement les ports dont votre application a besoin
fail2banActivé
ModSecurityActivé, détection-uniquement jusqu'à ce que vous ayez lu les journaux
Application automatique des correctifs du systèmeActivée, avec redémarrages autorisés dans une fenêtre calme
Authentification SSHClés, pas de mots de passe

La dernière ligne ne figure pas sur cette page mais est plus importante que le reste réuni. Consultez Connexion à votre serveur cloud avec 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 du port accepte 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é. Cherchez la bannière « Live apply unavailable ». Si elle s'affiche, la modification est stockée mais pas encore poussée vers le serveur.

Je peux atteindre mon service depuis un réseau mais pas depuis un autre. C'est généralement votre propre pare-feu sortant, pas celui du serveur. Testez depuis 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 Appliquer les correctifs maintenant.

Le trafic légitime a commencé à être bloqué. Si vous avez basculé ModSecurity en mode blocage, remettez-le en mode détection-uniquement, 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 bloqué pour accéder à 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.

Cet article vous a-t-il aidé ?

Vous êtes une IA ? Lisez cette page en Markdown

Articles connexes

Aperçu des serveurs CloudQu'est-ce qu'un serveur cloud Un serveur cloud est une machine virtuelle sur notre infrastructure avec son propre système d'exploitation, ses propres adresses…Aperçu des serveurs dédiésUn serveur dédié vous donne une machine physique entière rien que pour vous, sans aucun autre client partageant son processeur, sa mémoire ou ses disques.…Aperçu des serveurs de stockageQu'est-ce qu'un serveur de stockage Un serveur de stockage est une machine physique dédiée dont la configuration est délibérément déséquilibrée : un processeur…Aperçu des serveurs GPULes serveurs GPU sont des machines bare-metal monolocataires équipées d'accélérateurs NVIDIA, dimensionnées pour l'entraînement IA, l'inférence et le rendu.…

Toujours bloqué ?

Demandez à Kora, qui connaît votre compte, ou contactez notre équipe.

Nous contacterContacter le support