Comment sécuriser un VPS public : checklist de déploiement vérifiable

Sécuriser un VPS public ne consiste pas à appliquer une longue liste de commandes trouvées en ligne. Il faut réduire les accès, connaître les services exposés, appliquer les mises à jour, prévoir la restauration et vérifier le résultat après chaque modification. Commencez par les contrôles les plus simples : comptes séparés, SSH par clé, pare-feu minimal, sauvegarde testée et journaux consultables sans secrets.

Ce guide est une checklist d’exploitation défensive. Il ne remplace pas les consignes de votre distribution, les exigences de votre hébergeur ou un audit adapté à des données sensibles.

Ce que vous allez faire

Vous allez inventorier le serveur, limiter l’administration distante, fermer les ports non nécessaires, établir un rythme de correctifs et tester une reprise. Le résultat attendu n’est pas « serveur parfaitement sécurisé », mais un système dont les accès et les actions de récupération sont connus.

Prérequis

• Un accès console fourni par l’hébergeur, au cas où une règle réseau vous verrouillerait dehors.
• Une clé SSH de secours vérifiée depuis un second terminal.
• La documentation de la distribution et une fenêtre de maintenance.
• Une sauvegarde ou un snapshot dont vous comprenez les limites.
• La liste des applications que le VPS doit réellement héberger.

Évitez de modifier SSH, le pare-feu et les comptes depuis une seule session non sauvegardée. Gardez une seconde connexion ouverte jusqu’à ce que le nouvel accès soit confirmé.

1. Inventorier comptes et services

Avant de fermer quoi que ce soit, listez les comptes, les processus en écoute, les tâches planifiées et les répertoires applicatifs. Demandez pour chaque port : quel programme l’écoute, qui en a besoin et depuis quelle origine. Un port inconnu n’est pas automatiquement malveillant, mais une règle réseau ne peut pas être revue sans cette information.

Vérification : conservez un inventaire daté, puis comparez-le après chaque déploiement. Les nouveaux ports, utilisateurs ou services doivent avoir un propriétaire explicite.

2. Séparer administration et application

N’exécutez pas l’application web sous le même compte que l’administration. Créez un compte applicatif avec un répertoire et des permissions limités ; n’ajoutez pas de privilèges sudo s’il n’en a pas besoin. Utilisez les privilèges élevés seulement lors d’une opération d’administration identifiée, pas dans un script de démarrage permanent.

Pour SSH, privilégiez des clés protégées plutôt que des mots de passe réutilisables, désactivez les méthodes que vous n’utilisez pas après test et limitez les comptes autorisés. Une désactivation trop rapide peut toutefois vous exclure : testez le nouvel accès dans une seconde session avant de fermer la première.

Vérification : connectez-vous avec le compte applicatif et confirmez qu’il ne peut ni lire les secrets d’administration ni exécuter d’action sudo. Connectez-vous ensuite avec la clé d’administration prévue et vérifiez que l’authentification par mot de passe non nécessaire échoue.

3. Réduire la surface réseau

Le pare-feu doit autoriser uniquement les services nécessaires. Une application HTTP publique nécessite habituellement un proxy HTTPS ; une base de données ou une interface d’administration ne devrait pas devenir publique par commodité. Lorsque c’est possible, limitez SSH à des adresses ou à un réseau d’administration connu, sans vous empêcher d’accéder au serveur en cas d’urgence.

Les règles entrantes ne suffisent pas. Les sorties d’un service peuvent aussi être importantes, surtout pour un worker, un agent IA ou un système qui traite des fichiers non fiables. Listez les API, stockages et webhooks attendus ; ajoutez délais, limites de débit et alertes sur les échecs inhabituels.

Vérification : testez depuis l’extérieur les ports réellement ouverts, puis contrôlez depuis le VPS que l’application fonctionne toujours. Documentez les exceptions temporaires et leur date de retrait.

4. Appliquer les correctifs sans perdre la maîtrise

Activez les mises à jour de sécurité selon les recommandations de votre distribution ou planifiez-les avec une fenêtre de maintenance. Les correctifs n’ont de valeur que si vous savez quels services doivent redémarrer et comment observer leur retour. Un redémarrage automatique peut être approprié pour certains environnements, mais il doit s’accompagner d’une alerte et d’une vérification de disponibilité.

Épinglez les versions applicatives lorsque cela est nécessaire, lisez les notes de mise à jour et testez une copie pour les changements majeurs. Ne gardez pas indéfiniment une version connue vulnérable au prétexte qu’un upgrade est difficile : planifiez plutôt la migration et les tests nécessaires.

Vérification : après une maintenance, contrôlez la version du système, la disponibilité des services attendus, les journaux d’erreur et la santé fonctionnelle de l’application. Conservez un lien vers l’incident ou le changement associé.

5. Sauvegarder et restaurer

Sauvegardez les données métier, les configurations contrôlées et les secrets nécessaires à la récupération dans des emplacements distincts et protégés. Un snapshot de machine peut être utile, mais il ne remplace pas une exportation testée d’une base ni une procédure pour reconstruire les identifiants. Définissez une rétention et une responsabilité : qui vérifie les sauvegardes, qui peut les restaurer et dans quel délai ?

La preuve la plus forte est un exercice de restauration isolé. Restaurez une copie, démarrez l’application sans trafic réel et vérifiez l’intégrité, les droits et les données. Notez les étapes manuelles ; elles révèlent souvent des secrets ou dépendances oubliés.

Vérification : effectuez une restauration de test périodique et mesurez son temps. Une sauvegarde non restaurée ne permet pas d’affirmer que le service est récupérable.

6. Observer sans divulguer

Centralisez, lorsque nécessaire, les événements utiles : échecs d’authentification, redémarrages, saturation disque, erreurs applicatives et changements de configuration. Ne versez pas de mots de passe, cookies, clés API ou contenus utilisateurs complets dans les logs. Limitez l’accès aux journaux et définissez leur durée de conservation.

Un serveur silencieux n’est pas forcément sain. Préparez des alertes simples pour l’espace disque, la disponibilité et les échecs répétés ; elles sont plus actionnables qu’un flux massif de logs non filtrés.

Problèmes fréquents et solutions

Vous avez perdu SSH après un changement. Utilisez la console d’hébergeur, corrigez la règle avec la seconde clé vérifiée et documentez la séquence. Ne désactivez pas la console tant qu’elle est votre recours.

Une base est exposée publiquement. Restreignez son écoute au réseau nécessaire, faites passer les accès via l’application ou un réseau privé et remplacez les identifiants si l’exposition n’est pas explicable.

Une sauvegarde existe mais personne ne sait la restaurer. Créez un exercice isolé et transformez ses étapes en runbook ; l’objectif est la reprise, pas le simple stockage d’archives.

FAQ

Faut-il fermer SSH ?

Non si vous en avez besoin. Réduisez plutôt qui peut s’y connecter, avec quelles méthodes et depuis quelles origines, puis surveillez les échecs.

Un pare-feu suffit-il ?

Non. Il complète les comptes séparés, correctifs, sauvegardes, secrets limités et supervision.

Faut-il mettre à jour automatiquement ?

Le choix dépend de votre exploitation. Quelle que soit la stratégie, prévoyez une observation après mise à jour et une procédure de retour.

Un VPS a-t-il besoin d’une sauvegarde si le code est dans Git ?

Oui. Git ne sauvegarde ni les données, ni les configurations d’exécution, ni les secrets de reprise.

Quelle est la priorité après un premier déploiement ?

Validez les accès, le pare-feu et une restauration de test. Ces contrôles apportent plus de preuve qu’une longue liste d’options non vérifiées.

Conclusion

Un VPS public devient plus défendable lorsque vous pouvez répondre à quatre questions : qui accède, quels ports sont ouverts, comment les services sont corrigés et comment les données sont restaurées. Faites une modification à la fois et vérifiez son effet : c’est plus sûr que de cocher une checklist sans preuve.

Pour replacer ces mesures de sécurité dans le choix de l’infrastructure, consultez le comparatif des hébergeurs français.

Sources et limites

Sources primaires : CISA — Securing Web Servers, OWASP Linux Hardening et OWASP Logging. Les commandes et services dépendent de la distribution et de l’hébergeur. Ce guide ne remplace pas une réponse à incident ou un audit de votre environnement.