Sécuriser un nouveau VPS Ubuntu étape par étape
Sécurisez un nouveau VPS Ubuntu en le mettant à jour, en créant un administrateur nommé, en autorisant l'accès SSH par clé, en limitant les services exposés, en activant un pare-feu hôte et en configurant la surveillance et les sauvegardes. Effectuez chaque modification dans l'ordre, gardez la console du fournisseur disponible et ne fermez jamais la session SSH d'origine tant qu'une seconde connexion n'a pas réussi.
Points clés
- S'applique à
- Versions Ubuntu Server prises en charge utilisant systemd et OpenSSH
- Mesure de protection principale
- Conserver l'accès à la console et tester une seconde session
- Authentification
- Clé SSH protégée par une phrase secrète pour un utilisateur nommé
- Restauration
- Sauvegarde indépendante et restauration testée
Mettre à jour et vérifier avant de modifier l'accès
Ne prendre un instantané du fournisseur que si la plateforme le propose et que vous Veuillez noter qu'il ne s'agit pas d'une sauvegarde indépendante. Connectez-vous via la méthode initiale documentée, confirmez l'image du système d'exploitation et appliquez les mises à jour des dépôts avec sudo apt update, puis sudo apt full-upgrade. Lisez les invites avant d'accepter les remplacements de fichiers de configuration, puis exécutez sudo reboot si un noyau ou un composant essentiel le requiert.
Reconnectez-vous et inventoriez les écouteurs avec sudo ss -tulpn. Chaque écouteur public doit avoir un propriétaire et une fonction. Une image cloud Ubuntu minimale peut différer d'une image d'installation ; ne présumez donc jamais des services activés. Enregistrez la configuration de référence avant d'installer une pile d'applications.
- Utilisez uniquement les dépôts et les clés auxquels vous faites confiance.
- Supprimez les logiciels inutilisés après avoir vérifié qu'ils ne constituent pas une dépendance.
- Planifiez les mises à jour plutôt que de laisser la première mise à niveau comme un événement ponctuel.
Créez un administrateur nommé et fournissez des clés SSH.
Créez un compte distinct avec sudo adduser deploy, en remplaçant « deploy » par le nom de votre choix, puis accordez-lui les droits d'administrateur avec sudo usermod -aG sudo deploy. Ajoutez la partie publique de votre clé SSH à ce compte utilisateur (~/.ssh/authorized_keys) à l'aide de la fonction de clé du fournisseur ou avec ssh-copy-id. Ne téléchargez jamais le fichier de clé privée.
Ouvrez un second terminal et testez ssh deploy@SERVER_IP. Vérifiez que sudo -v fonctionne. Ce n'est qu'après ce test que vous pourrez envisager de désactiver la connexion directe en tant que root et par mot de passe. Modifiez le fichier de configuration avec sudoedit /etc/ssh/sshd_config.d/60-local-hardening.conf, définissez PermitRootLogin no et PasswordAuthentication no, validez avec sudo sshd -t, puis rechargez avec sudo systemctl reload ssh. Laissez la session ouverte et testez à nouveau.
- Remplacez explicitement tous les noms et adresses d'exemple.
- Utilisez une phrase secrète locale et un gestionnaire de mots de passe ou un agent sécurisé.
- Si la validation échoue, corrigez le fichier ; ne rechargez pas SSH.
Autorisez uniquement les services réseau nécessaires.
UFW d'Ubuntu est une interface pare-feu hôte pratique. Assurez-vous d'abord que votre service SSH utilise le port attendu. Autorisez-le avec sudo ufw allow OpenSSH. Si vous avez modifié le port intentionnellement, créez plutôt la règle correspondante. Inspectez l'état proposé avec sudo ufw status verbose, activez-le avec sudo ufw enable et vérifiez l'accès depuis un nouveau terminal avant de fermer l'ancien.
N'ajoutez les ports d'application que lorsque le service est installé et opérationnel. Pour un serveur web, cela signifie généralement les ports TCP 80 et 443, mais il n'existe pas de liste universelle. Un pare-feu de fournisseur et un UFW peuvent se compléter ; documentez les deux afin qu'un intervenant en cas d'incident puisse identifier la couche qui a bloqué le trafic.
- N'activez jamais un pare-feu de blocage par défaut à distance sans une règle d'autorisation SSH.
- Liez les bases de données privées à des interfaces locales ou privées.
- Réexécutez
sudo ss -tulpnaprès le déploiement du logiciel.
Intégrez le durcissement dans une routine d'exploitation
Installez et vérifiez les mises à jour de sécurité automatiques avec sudo apt install unattended-upgrades, puis configurez-les selon votre politique de maintenance et de redémarrage. Surveillez le disque, la mémoire, les échecs d'authentification, l'état des services, l'expiration des certificats et les résultats des sauvegardes. N'exposez pas d'agent de surveillance sans authentification ni restrictions réseau.
Créez une sauvegarde indépendante et versionnée, puis restaurez-la sur un système de test isolé. Stockez les codes de récupération et les instructions de la console séparément du VPS. Les paramètres de sécurité évoluent ; comparez donc cette liste de contrôle générique avec la documentation Ubuntu actuelle et les besoins de votre application avant la mise en production.
- Vérifiez régulièrement les comptes et clés d'administrateur.
- Mettez à jour les applications ainsi que le système d'exploitation.
- Documentez une procédure de récupération avant de supprimer toute méthode de connexion.
Sources
Questions fréquentes
Devrais-je modifier le port SSH ?
Cela peut réduire le bruit des analyses de routine, mais ne remplace pas l'authentification par clé, les correctifs, les contrôles d'accès et la surveillance. Si vous le modifiez, mettez à jour chaque couche du pare-feu et effectuez un test avant de terminer la session.
Puis-je désactiver immédiatement la connexion root ?
Uniquement après qu'un utilisateur nommé puisse s'authentifier par clé, obtenir l'accès sudo requis et se reconnecter dans une session distincte. Conservez la récupération de la console.
UFW est-il suffisant pour sécuriser le VPS ?
Non. Un pare-feu limite l'accessibilité du réseau ; il ne corrige pas les logiciels vulnérables, ne protège pas les identifiants volés, ne sécurise pas la logique applicative et ne remplace pas les sauvegardes.