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 :
apt update && apt upgrade -y1. 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) :
adduser marie
usermod -aG sudo marie2. 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 :
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_SERVEURssh-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.
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.
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 verbose5. 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.
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 sshdignoreip 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.
sudo apt install unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades
# Simulation : montre ce qui serait installé
sudo unattended-upgrade --dry-run --debug/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.
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/restaurationpg_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 enroot. - Connexion par clé SSH, testée depuis un second terminal.
PermitRootLogin noetPasswordAuthentication noconfirmés parsshd -T.- ufw actif, seuls SSH, HTTP et HTTPS ouverts.
- fail2ban actif sur
sshd, ton IP dansignoreip. - Correctifs de sécurité installés chaque jour.
- Sauvegardes hors du serveur, et une restauration déjà faite.