Une liste de vérification pratique pour un VPS flambant neuf : authentification SSH par clé, pare-feu, mises à jour automatiques et supervision - la base que nous appliquons à chaque serveur EGYmass.
Les sept étapes de sécurité indispensables à tout VPS sont : l'authentification SSH par clé, un pare-feu hôte, des mises à jour de sécurité automatiques, une protection anti-force-brute à la fail2ban, TLS partout, des sauvegardes automatisées quotidiennes, et une supervision qui vous alerte quand quelque chose ne va pas.
La connexion par mot de passe est le service le plus attaqué sur Internet. Désactivez l'authentification par mot de passe et la connexion root via SSH, et exigez une clé - idéalement une clé ed25519 protégée par une phrase secrète, générée avec ssh-keygen et copiée sur le serveur avec ssh-copy-id. La règle qui vous évite l'histoire du serveur verrouillé : gardez votre session actuelle ouverte, modifiez sshd_config pour passer PasswordAuthentication à no et PermitRootLogin à prohibit-password, puis connectez-vous depuis un second terminal et confirmez que la clé fonctionne. Ce n'est qu'alors que vous pouvez fermer la première session. Enfin, traitez la clé comme une clé de maison : une sur votre ordinateur, une copie hors ligne, et un chemin de récupération documenté - car une clé perdue sans solution de repli signifie un ticket de support et une réinstallation forcée.
N'ouvrez que les ports réellement nécessaires au service - généralement SSH, HTTP et HTTPS - et refusez tout le reste par défaut : tout paquet entrant refusé sauf règle explicite, trafic sortant autorisé. Appliquez les mêmes règles à IPv6, ce n'est pas un détail secondaire - un serveur qui ne filtre qu'IPv4 reste pleinement joignable via sa seconde pile. Rendez les règles persistantes pour qu'un redémarrage ne laisse pas le serveur grand ouvert. Le piège classique est d'activer un pare-feu sans ouvrir le port SSH par lequel vous êtes connecté : au premier paquet bloqué, vous êtes dehors, exactement comme en perdant la clé - alors ouvrez d'abord ce port, et vérifiez depuis une seconde session avant de valider.
Activez les mises à niveau non surveillées pour les correctifs de sécurité, afin qu'une CVE soit corrigée en quelques heures plutôt qu'en quelques semaines. Les mises à jour au niveau des paquets sont celles qui ne doivent jamais attendre un humain ; la seule partie qui mérite une planification délibérée est la mise à jour du noyau, qui exige un redémarrage pour s'appliquer - choisissez une fenêtre de maintenance, ou utilisez le live patching si la distribution le permet. Deux habitudes rendent les mises à jour automatiques sûres plutôt qu'effrayantes : lisez le journal des mises à jour régulièrement pour que les échecs silencieux remontent au lieu de s'accumuler, et surveillez les paquets épinglés ou bloqués, car un paquet épinglé vulnérable ne se corrigera pas tout seul. Des correctifs appliqués avec une semaine de retard, c'est ainsi que de petits serveurs deviennent des éléments de grands botnets.
Des robots martèlent SSH et les pages de connexion jour et nuit. Avec une authentification SSH par clé uniquement, l'attaque en force du port SSH est déjà une voie morte - c'est précisément pour cela que les bots se sont tournés vers les surfaces encore ouvertes : les formulaires de connexion web, les panneaux d'administration, la messagerie. Exécutez un outil comme fail2ban ou un limiteur de débit comparable qui bannit les tentatives répétées échouées assez longtemps pour que l'attaque ne soit plus rentable, et laissez-le alimenter le pare-feu pour que les bannissements deviennent de vraies règles plutôt que des lignes de journal. Ajoutez la limitation de débit et un WAF devant vos applications web pour filtrer les requêtes malveillantes avant qu'elles n'atteignent votre code. Mesurez-le une fois par mois : si une adresse IP a produit hier des milliers de connexions échouées, le garde fait son travail.
Terminez TLS 1.3 devant vos services - 1.2 au minimum, jamais rien d'antérieur - avec des suites cryptographiques modernes solides, et redirigez chaque requête HTTP vers HTTPS pour qu'une URL mal saisie ne livre pas vos identifiants au réseau. Ajoutez HSTS une fois la redirection en place depuis un certain temps, et elle bloque le repli HTTP dès la première visite. Gérez les certificats avec un client ACME automatisé, avec un renouvellement vérifié quotidiennement et la date d'expiration exportée vers la supervision : un certificat qui se renouvelle silencieusement peut aussi échouer silencieusement, et un certificat expiré est la seule panne que les visiteurs voient avant tous vos tableaux de bord. Le renouvellement ne doit jamais être un rappel d'agenda qui devient silencieusement un incident.
Une sauvegarde que vous n'avez jamais restaurée n'est pas une sauvegarde - c'est un espoir. Automatisez des instantanés quotidiens de ce qui reconstruit vraiment le service : les exports de base de données, les fichiers de configuration et les données des utilisateurs, pas seulement le disque entier. Conservez des copies hors serveur et idéalement hors site - c'est la différence entre une panne matérielle et une mauvaise matinée - et fixez une politique de rétention pour que les anciennes sauvegardes se nettoient toutes seules au lieu de remplir le disque que vous supervisez à l'étape sept. Chiffrez tout ce qui quitte le serveur. Puis prouvez-le : une fois par trimestre, restaurez dans un environnement de test et confirmez que le service revient réellement - car une sauvegarde silencieusement corrompue échouera le jour où vous en aurez besoin, et ce n'est pas le bon jour pour l'apprendre.
Vous ne pouvez pas réagir à un incident dont vous n'entendez jamais parler. Supervisez disque, mémoire, CPU et la santé de chaque service, et alertez sur la tendance plutôt que sur l'état binaire : un disque à 85 pour cent et qui grimpe est une alerte, un disque qui reste à 85 pour cent pendant un an n'en est pas une. Intégrez ce qui tombe en panne silencieusement - l'expiration des certificats, les jobs de sauvegarde qui se sont arrêtés, les connexions échouées qui montent en flèche, les mises à jour de sécurité qui ne s'appliquent plus - car ce sont les incidents que vous découvrirez sinon par un message client. Acheminez les alertes vers un canal que quelqu'un lit vraiment, avec une règle d'escalade pour les nuits et les week-ends. L'objectif est d'apprendre qu'un disque est presque plein avant qu'il n'emporte la base de données avec lui.
Clés SSH et pare-feu d'abord - ce sont les moins chères et elles arrêtent les attaques les plus courantes -, puis les mises à jour automatiques, puis fail2ban. TLS, sauvegardes et supervision peuvent suivre, mais aucune ne devrait attendre plus d'une semaine sur un serveur exposé à Internet.
C'est la base. La production nécessite aussi une couche WAF/IDS en frontal, une procédure de restauration testée, des environnements isolés et une politique de contrôle d'accès. Ces sept étapes font passer un serveur de vulnérable par défaut à solide.
Oui - c'est exactement la base que nous appliquons à chaque serveur EGYmass, et la pile derrière notre service de configuration VPS. La même automatisation et la même supervision gardent nos propres produits en ligne.
Configuration VPS EGYmass avec multi-hébergement, TLS 1.3, supervision 24/7 et déploiement automatisé.
Filtrage au niveau réseau qui tient à distance les domaines de logiciels malveillants et de trackers de votre équipe et de vos serveurs.
Filtrage au niveau réseau qui écarte les domaines de malware et de tracking de vos serveurs et de votre équipe.
EGYmass gère l'hébergement, la sécurité et la maintenance continue - pour que vous puissiez vous concentrer sur votre produit.
Consultation gratuite