Quelle est la première chose à faire sur un nouveau VPS ?

Entrez avec une clé SSH et désactivez la connexion par mot de passe. Des bots automatisés martèlent le port 22 avec des tentatives de mot de passe dans les minutes qui suivent la mise en ligne d'un serveur ; une clé rend ces tentatives inutiles. Tout le reste est secondaire par rapport à ce seul changement.

Ai-je besoin d'un pare-feu si je ne fais tourner qu'un service ?

Oui. Un pare-feu (ufw) signifie que seuls les ports que vous ouvrez explicitement sont joignables — donc un service que vous avez oublié d'avoir démarré, ou qu'une dépendance a ouvert, n'est pas exposé silencieusement. C'est deux commandes et cela ferme toute une catégorie d'erreurs.

fail2ban est-il nécessaire si j'ai désactivé la connexion par mot de passe ?

C'est facultatif une fois les clés imposées — avec les mots de passe désactivés, la force brute ne peut de toute façon pas réussir. fail2ban réduit surtout le bruit des journaux et bloque tôt les IP abusives. Bon à avoir, pas critique, sur une machine à clés uniquement.

Dois-je changer le port SSH ?

C'est de la sécurité cosmétique — quitter le 22 réduit le bruit des journaux des bots stupides mais n'arrête aucun attaquant déterminé. Faites-le si le bruit vous dérange, mais ne le confondez pas avec une vraie protection. Des clés + pas de mots de passe, c'est ce qui compte vraiment.

Comment garder un VPS patché automatiquement ?

Activez unattended-upgrades (Debian/Ubuntu) pour que les correctifs de sécurité s'installent tout seuls. C'est l'habitude la plus rentable après les clés SSH — la plupart des intrusions exploitent des bugs connus et déjà corrigés sur des serveurs que personne n'a mis à jour.

Sécuriser un nouveau VPS : la checklist qui compte vraiment

Les dix premières minutes sur un VPS neuf décident discrètement beaucoup de choses. Une nouvelle IP publique commence à être sondée par des bots automatisés presque immédiatement — ils ne vous ciblent pas vous, ils scannent tout. Ne faites rien et vous comptez sur la chance. Faites quatre ou cinq petites choses et vous avez fermé les portes qui se font réellement défoncer. Voici la liste, par ordre de priorité, avec les commandes.

1. Clés SSH, et couper la connexion par mot de passe

C'est celle qui compte le plus. Si vous pouvez vous connecter avec un mot de passe, un bot qui le devine le peut aussi — et ils en essaient des milliers par minute.

Depuis votre portable, si vous n'avez pas déjà une clé :

ssh-keygen -t ed25519 -C "you@laptop"
ssh-copy-id root@your-server-ip

Puis sur le serveur, désactivez les mots de passe :

# /etc/ssh/sshd_config.d/99-hardening.conf
PasswordAuthentication no
PermitRootLogin prohibit-password

sudo systemctl reload ssh

⚠️ Testez une deuxième session SSH avant de fermer la première — si la connexion par clé fonctionne, parfait ; sinon, vous avez encore la session ouverte pour corriger. Se verrouiller dehors est le classique auto-but ici.

2. Un pare-feu — refus par défaut

N'exposez que ce que vous voulez. Sur Ubuntu/Debian :

sudo apt install -y ufw
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH        # ou votre port SSH
sudo ufw enable

Maintenant un service égaré ne peut pas être joint depuis l'extérieur à moins que vous ne l'ouvriez. Cela attrape la chose que vous oublierez inévitablement.

Une note pour les offres de type NAT : votre SSH atterrit sur un port redirigé, pas le 22, et vous ne pouvez pas ouvrir de ports entrants arbitraires — l'isolation fait une partie de ce travail pour vous. Sur une offre à IP dédiée, vous possédez tous les ports, le pare-feu travaille donc davantage.

3. Mises à jour de sécurité automatiques

La plupart des serveurs qui se font compromettre n'étaient pas des cibles habiles — ils faisaient tourner un bug connu qu'un correctif avait déjà réglé, sur une machine que personne n'a mise à jour. Rendez le patch automatique :

sudo apt install -y unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades

À régler puis oublier. C'est l'habitude la plus rentable après les clés SSH.

4. fail2ban (facultatif, mais peu coûteux)

Avec la connexion par mot de passe déjà désactivée, la force brute ne peut pas gagner — il s'agit donc de réduire le bruit et de bannir tôt les IP abusives plutôt que d'une protection centrale :

sudo apt install -y fail2ban
sudo systemctl enable --now fail2ban

Ça vaut le coup pour des journaux plus calmes ; sautez-le sans culpabilité si vous gardez les choses minimales.

Ce que vous pouvez sauter

Changer le port SSH — réduit le bruit des bots, n'arrête aucun vrai attaquant. Cosmétique. Ne le confondez pas avec la sécurité.
Un réglage élaboré d'IDS/SELinux — excessif pour une machine à usage unique faisant tourner un bot ou un agent. Rendements décroissants.

Le résumé honnête

Si vous ne faites qu'une seule chose, faites des clés SSH + pas de connexion par mot de passe. Ajoutez le pare-feu et les mises à jour auto et vous avez géré l'écrasante majorité du risque réel en bien moins de dix minutes. Tout ce qui vient après, c'est du peaufinage.

Vous faites tourner un agent ou un bot toujours actif sur la machine ? Associez ceci à le garder en vie sous systemd pour qu'il survive aux redémarrages et aux plantages, pas seulement aux attaquants.