Blog

Sécuriser un VPS fraîchement loué : les 7 réglages indispensables

Utilisateur sudo, clé SSH, root et mots de passe coupés, pare-feu ufw, fail2ban, mises à jour automatiques et sauvegardes : les commandes pour Ubuntu et Debian.

Équipe Coxios5 min de lecture

  • Sécurité
  • SSH
  • Ubuntu
  • Debian
Tous les articles

Un VPS tout neuf est joignable par tout Internet dès son démarrage. Dans l'heure qui suit, des robots essaient déjà des mots de passe sur le port 22 : ce n'est pas une attaque contre toi, c'est un balayage permanent de toutes les adresses IP. Un serveur laissé avec la connexion root par mot de passe finit tôt ou tard par céder.

Voici les 7 réglages à faire avant d'installer quoi que ce soit, dans l'ordre. Les commandes sont écrites pour Ubuntu 22.04 / 24.04 et Debian 12. Commence par mettre le système à jour, connecté en root avec les identifiants reçus de ton hébergeur :

bash
apt update && apt upgrade -y

1. Créer un utilisateur non-root avec sudo

Travailler en root au quotidien, c'est s'exposer à ce qu'une faute de frappe ou un script mal relu ait tous les droits. Crée ton propre utilisateur et donne-lui sudo (sur une image Debian minimale, installe d'abord sudo avec apt install sudo) :

bash
adduser marie
usermod -aG sudo marie

2. Se connecter avec une clé SSH

Une clé SSH ne se devine pas, contrairement à un mot de passe. Génère-la sur ton ordinateur (pas sur le serveur), puis copie la partie publique chez ton nouvel utilisateur :

bash
ssh-keygen -t ed25519 -C "marie@portable"
ssh-copy-id -i ~/.ssh/id_ed25519.pub marie@IP_DU_SERVEUR

# Vérifie que la clé fonctionne avant d'aller plus loin
ssh -i ~/.ssh/id_ed25519 marie@IP_DU_SERVEUR
Sous Windows, ssh-copy-id n'existe pas : colle le contenu de id_ed25519.pub dans ~/.ssh/authorized_keys de l'utilisateur sur le serveur.

3. Couper la connexion root et les mots de passe

Une fois la clé testée, interdis à SSH d'accepter root et les mots de passe. Sur Ubuntu et Debian récents, le plus propre est un fichier dans /etc/ssh/sshd_config.d/. Le préfixe 00- compte : SSH garde la première valeur lue, et beaucoup d'images cloud livrent un 50-cloud-init.conf qui réactive les mots de passe.

bash
sudo tee /etc/ssh/sshd_config.d/00-durcissement.conf > /dev/null <<'EOF'
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
EOF

sudo sshd -t && sudo systemctl restart ssh
sudo sshd -T | grep -Ei 'permitrootlogin|passwordauthentication'
sshd -t vérifie la syntaxe avant le redémarrage, sshd -T affiche la configuration réellement appliquée : les deux lignes doivent finir par no.

Depuis ton second terminal, ssh root@IP_DU_SERVEUR doit maintenant répondre Permission denied (publickey). Changer le port 22 réduit le bruit dans les journaux mais n'apporte pas de vraie sécurité : la clé et fail2ban font le travail.

4. Activer un pare-feu avec ufw

Le principe : tout refuser en entrée, puis n'ouvrir que ce dont tu as besoin. Autorise SSH avant d'activer le pare-feu, sinon tu te coupes toi-même.

bash
sudo apt install ufw
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verbose

5. Bannir les attaques avec fail2ban

fail2ban lit les journaux de SSH et bannit pour un temps les adresses qui échouent trop souvent. Sur Debian 12, il n'y a plus de fichier /var/log/auth.log par défaut : on lit donc le journal systemd, ce qui marche aussi sur Ubuntu.

bash
sudo apt install fail2ban python3-systemd
sudo tee /etc/fail2ban/jail.local > /dev/null <<'EOF'
[DEFAULT]
bantime  = 1h
findtime = 10m
maxretry = 5

[sshd]
enabled = true
backend = systemd
EOF

sudo systemctl enable fail2ban
sudo systemctl restart fail2ban
sudo fail2ban-client status sshd
Ajoute ton IP fixe à ignoreip dans la section [DEFAULT] pour ne jamais te bannir toi-même. Le détail est dans Fail2ban expliqué simplement.

6. Installer les mises à jour de sécurité automatiquement

La plupart des serveurs piratés le sont par une faille corrigée depuis longtemps. unattended-upgrades installe chaque jour les correctifs de sécurité, sans toucher aux mises à jour majeures.

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

# Simulation : montre ce qui serait installé
sudo unattended-upgrade --dry-run --debug
Une mise à jour du noyau ne prend effet qu'au redémarrage. Le fichier /var/run/reboot-required apparaît quand c'est nécessaire, et l'option Unattended-Upgrade::Automatic-Reboot de /etc/apt/apt.conf.d/50unattended-upgrades peut s'en charger la nuit.

7. Prévoir des sauvegardes (et tester la restauration)

La sécurité, c'est aussi pouvoir repartir après une erreur, une suppression ou un disque qui lâche. Deux niveaux se complètent :

  • Les snapshots de l'hébergeur : une image complète du disque, en un clic depuis son interface, souvent en option payante. Idéal avant une grosse mise à jour.
  • Une sauvegarde des données hors du serveur : tes fichiers et un export de tes bases de données, envoyés ailleurs. Si le compte chez l'hébergeur est perdu, les snapshots le sont aussi.
bash
sudo apt install restic
restic -r sftp:backup@autre-serveur:/sauvegardes/vps init
restic -r sftp:backup@autre-serveur:/sauvegardes/vps backup /etc /home /srv

# Le test qui compte : restaurer
restic -r sftp:backup@autre-serveur:/sauvegardes/vps restore latest --target /tmp/restauration
Pour une base de données, sauvegarde un export (pg_dump, mysqldump) plutôt que ses fichiers en cours d'écriture. Une sauvegarde jamais restaurée n'est qu'un espoir.

Récapitulatif

Avant de déployer ta première application, vérifie que tout est coché :

  • Un utilisateur personnel avec sudo, plus de travail en root.
  • Connexion par clé SSH, testée depuis un second terminal.
  • PermitRootLogin no et PasswordAuthentication no confirmés par sshd -T.
  • ufw actif, seuls SSH, HTTP et HTTPS ouverts.
  • fail2ban actif sur sshd, ton IP dans ignoreip.
  • Correctifs de sécurité installés chaque jour.
  • Sauvegardes hors du serveur, et une restauration déjà faite.