Un VPS neuf est une machine vierge connectée à Internet, et Internet n'attend pas. En quelques heures d'exposition d'un serveur non configuré, des scanners automatisés sondent les ports courants, essaient les identifiants par défaut et recherchent des logiciels non corrigés. La différence entre un serveur qui survit à ces sondages et un autre se décide généralement avant la mise en ligne, pas après un incident. Le durcissement de la sécurité est une tâche à réaliser avant le lancement.
La bonne nouvelle, c'est que le durcissement d'un VPS est une tâche limitée. La liste de contrôle ci-dessous couvre les douze actions les plus importantes, regroupées en quatre phases. Aucune n'exige d'outillage exotique : il s'agit d'administration Linux standard, faite avec méthode. Chaque VPS NVMe d'Open Vista inclut une adresse IPv4 dédiée, un panneau de gestion, des sauvegardes automatiques et un support 24/7 en français et en anglais, ce qui couvre une partie du travail (sauvegardes, accès console) tandis que le reste demeure à votre charge.
Partir d'une base propre
1. Appliquez toutes les mises à jour du système d'exploitation avant le lancement. Installez les derniers paquets, puis redémarrez pour que le noyau en cours d'exécution corresponde à celui installé. Un serveur démarré à jour a bien moins de failles à combler ensuite.
2. N'installez que le nécessaire. Chaque paquet supplémentaire représente une surface d'attaque potentielle et une chose de plus à corriger. Évitez les outils graphiques et les services de démonstration sur un VPS de production ; n'ajoutez un logiciel que lorsqu'une tâche l'exige.
3. Créez un utilisateur administrateur dédié. Travaillez au quotidien avec un utilisateur non root disposant des droits sudo. Le compte root doit être réservé à des actions administratives précises, jamais aux connexions courantes : cela rend les erreurs plus difficiles et les journaux d'audit plus clairs.
Verrouiller SSH et les accès d'administration
4. Passez aux clés SSH et désactivez l'authentification par mot de passe. Copiez votre clé publique sur le serveur, vérifiez que vous pouvez vous connecter avec, puis définissez `PasswordAuthentication no` et `PermitRootLogin no` dans `sshd_config`. L'authentification par clé élimine la cible de force brute la plus courante : l'invite de mot de passe SSH.
5. Limitez qui peut accéder à SSH. Si votre équipe travaille depuis des adresses fixes, restreignez SSH à ces IP dans le pare-feu. Si les adresses varient, laissez SSH ouvert mais protégé par des clés et un limiteur de tentatives de connexion comme fail2ban.
6. Protégez chaque interface d'administration. Le panneau de gestion fourni avec votre VPS est un outil puissant : utilisez un mot de passe fort et unique, activez tout second facteur proposé et, si possible, limitez l'accès au panneau aux réseaux de confiance. Un attaquant qui accède au panneau peut contourner la plupart des protections du serveur.
Réduire la surface réseau
7. Configurez le pare-feu avec une politique de refus par défaut. N'autorisez que les ports dont vos services ont réellement besoin (généralement 22 pour SSH, 80 et 443 pour le web) et bloquez tout le reste. Sur un VPS neuf, aucun port entrant ne devrait être ouvert par défaut.
8. Désactivez ou désinstallez les services inutilisés. Vérifiez les ports en écoute avec `ss -tulpn` et remettez en question chaque entrée. Si un service n'est pas nécessaire, arrêtez-le et désactivez-le. Une surface d'écoute plus réduite, c'est une posture de sécurité plus simple.
9. Supprimez ou désactivez les identifiants par défaut et les fichiers d'exemple. Si votre pile inclut des bases de données d'exemple, des utilisateurs de démonstration ou des clés API par défaut, supprimez-les. Changez aussi tous les mots de passe par défaut créés lors de l'installation : c'est là que les scanners automatisés remportent leurs premiers succès.
Automatiser les mises à jour, les sauvegardes et la supervision
10. Activez les mises à jour de sécurité automatiques. Configurez les mises à jour sans intervention (unattended upgrades) pour les correctifs de sécurité, afin que le serveur se maintienne entre vos fenêtres de maintenance. Surveillez les journaux de mise à jour pour confirmer leur exécution.
11. Vérifiez votre chaîne de sauvegarde avant la mise en production. Chaque formule Open Vista inclut des sauvegardes automatiques, mais une sauvegarde que vous n'avez jamais restaurée est une supposition, pas une protection. Lancez une restauration dans un environnement de test, confirmez que vos données et votre configuration reviennent, et notez la durée de la restauration. Documentez la procédure : vous ne vous en souviendrez pas pendant un incident.
12. Mettez en place la supervision et la revue des journaux. Au minimum, examinez les journaux d'authentification (`journalctl` ou `/var/log/auth.log`) chaque jour ou chaque semaine, et utilisez un outil simple de supervision de la disponibilité ou des ressources qui vous alerte en cas d'anomalie. Les incidents de sécurité laissent des traces dans les journaux ; encore faut-il que quelqu'un les lise.
La liste de contrôle en 12 points avant la mise en ligne
1. [ ] Système d'exploitation entièrement à jour et redémarré.
2. [ ] Seuls les paquets nécessaires sont installés.
3. [ ] Le travail quotidien s'effectue avec un utilisateur sudo non root.
4. [ ] SSH utilise des clés ; connexion par mot de passe et connexion root désactivées.
5. [ ] SSH restreint par le pare-feu ou fail2ban.
6. [ ] Mot de passe du panneau de gestion robuste et accès restreint.
7. [ ] Pare-feu en refus par défaut ; seuls 22, 80 et 443 ouverts.
8. [ ] Services inutilisés arrêtés et désactivés.
9. [ ] Identifiants par défaut et fichiers d'exemple supprimés.
10. [ ] Mises à jour de sécurité automatiques activées.
11. [ ] Sauvegardes vérifiées par un test de restauration.
12. [ ] Revue des journaux et supervision en place.
FAQ
Pourquoi l'authentification par clé SSH est-elle si importante ? Les connexions par mot de passe sont scannées et attaquées en continu dès qu'un serveur est joignable. Les clés sont des secrets cryptographiquement longs, impossibles à deviner, et désactiver l'authentification par mot de passe élimine toute la catégorie des attaques par force brute et par dictionnaire contre SSH.
Un pare-feu suffit-il à lui seul ? Non. Un pare-feu réduit la surface d'attaque, mais il ne fait rien contre les vulnérabilités des services que vous exposez, les identifiants faibles ou les logiciels non corrigés. Pare-feu, mises à jour, contrôle des accès et supervision fonctionnent ensemble : c'est pourquoi la liste de contrôle les regroupe.
Mon hébergeur inclut des sauvegardes automatiques. Dois-je quand même tester les restaurations ? Oui. Les sauvegardes automatiques garantissent que les données sont capturées selon un calendrier, mais seul un test de restauration prouve que les sauvegardes sont complètes, lisibles et assez rapides pour vos besoins de reprise. Tester avant la mise en ligne coûte bien moins cher que de découvrir des problèmes pendant une panne.
Je ne suis pas un expert Linux. Puis-je quand même gérer un VPS sécurisé ? Oui, si vous suivez une liste de contrôle comme celle-ci et vous appuyez sur le support de votre fournisseur pour les étapes qui vous mettent en doute. Le support 24/7 d'Open Vista est disponible en français et en anglais, et l'entreprise est un cabinet de conseil informatique basé à Rabat, au Maroc, dont le fondateur apporte plus de 15 ans d'expérience en direction informatique au Canada, en Europe et en Afrique (références : Desjardins, Hydro-Québec, CDW Canada et Groupe Deschênes). En cas de doute, demandez avant de lancer.
La sécurité est une configuration que l'on fait une fois et que l'on maintient ensuite indéfiniment. Démarrez votre prochain projet sur une infrastructure qui le permet : comparez les formules VPS NVMe d'Open Vista (sans engagement, IPv4 dédiée, panneau de gestion, sauvegardes automatiques et support 24/7) sur https://openvista.ma/en/vps et commandez sur my.openvista.ma, avec un déploiement en moins de 15 minutes.