Sécuriser son serveur VPS : les réglages essentiels

Sécuriser son serveur VPS : les réglages essentiels

Un VPS, c'est un serveur allumé en permanence, directement exposé sur Internet. Dès les premières minutes, des bots scannent ses ports pour tenter de s'y connecter. Sans réglages de sécurité de base, votre serveur peut être compromis, servir de relais de spam ou héberger des données chiffrées contre rançon. Voici les réglages essentiels, à appliquer dès le premier jour.

1. SSH : fermez les portes d'entrée

• Désactivez le login root : connectez-vous avec un utilisateur dédié, puis passez par sudo. Dans /etc/ssh/sshd_config, réglez PermitRootLogin no.
• Utilisez des clés SSH au lieu des mots de passe : générez une paire de clés, copiez la clé publique sur le serveur (ssh-copy-id), puis activez PasswordAuthentication no.
• Changez le port SSH (ex. 2222) pour réduire le bruit des scanners automatiques. Ce n'est pas une sécurité en soi, mais cela élimine l'essentiel des tentatives.

2. Le pare-feu : n'ouvrez que l'essentiel

Avec UFW (Ubuntu) ou firewalld, la règle est simple : tout est fermé, sauf ce dont vous avez besoin.

• Autorisez uniquement SSH (votre port), HTTP 80 et HTTPS 443.
• Si vous ne l'avez pas encore fait, activez HTTPS dès que possible : le trafic en clair est lisible par n'importe qui sur le réseau.
• Vérifiez régulièrement les ports ouverts avec ss -tulpn et fermez tout ce qui ne sert pas : bases de données exposées, panneaux d'administration, services de démonstration.

3. Les mises à jour : le réflexe qui sauve

La plupart des compromissions exploitent des failles déjà corrigées. Activez les mises à jour automatiques de sécurité (unattended-upgrades) et lancez apt update && apt upgrade régulièrement. Un serveur à jour est un serveur que la grande majorité des attaques connues ne touche pas.

4. Fail2ban : découragez les intrusions

Fail2ban surveille les journaux et bannit automatiquement les adresses IP qui échouent trop souvent : connexions SSH ratées, tentatives sur les formulaires, scans répétés. Quelques minutes de configuration, et les attaques en force brute deviennent inutiles.

5. Ce qu'on oublie trop souvent

• Un utilisateur dédié par application, et jamais d'application lancée en root.
• Des sauvegardes hors du serveur : un serveur compromis, c'est aussi des données à restaurer.
• Une surveillance simple des journaux (journalctl, Logwatch) : une alerte tôt vaut mieux qu'une découverte tardive.

La sécurité d'un serveur ne se règle pas en un jour, mais ces réglages couvrent déjà l'essentiel des attaques réelles. C'est exactement ce que nous mettons en place chez iminwa sur chaque serveur que nous livrons : des bases saines, dès le premier déploiement.