Sécuriser un nouveau VPS : la checklist

1. Installer toutes les mises à jour

Les images cloud datent souvent de plusieurs semaines. Mettez tout à jour avant d'installer quoi que ce soit d'autre, et redémarrez si le noyau ou les bibliothèques de base ont changé.

sudo apt update && sudo apt full-upgrade -y
[ -f /var/run/reboot-required ] && echo "reboot needed"

sudo dnf upgrade --refresh -y
sudo dnf needs-restarting -r

Sur la famille RHEL, needs-restarting -r indique si un redémarrage est nécessaire. Redémarrez avec sudo reboot et reconnectez-vous.

2. Créer votre propre utilisateur avec sudo

Travaillez avec un utilisateur nominatif qui a sudo, pas en root : les actions sont journalisées sous un nom, et la connexion de root pourra être désactivée à l'étape suivante.

sudo adduser deploy
sudo usermod -aG sudo deploy

sudo useradd -m deploy
sudo passwd deploy
sudo usermod -aG wheel deploy

Copiez votre clé SSH pour cet utilisateur (ssh-copy-id deploy@SERVER_IP depuis votre ordinateur), connectez-vous avec lui depuis un second terminal et vérifiez sudo -v. Assurez-vous ensuite que seul root a l'identifiant utilisateur 0 et qu'aucun compte n'a de mot de passe vide : la première commande ne doit afficher que root, la seconde rien du tout.

awk -F: '$3 == 0 {print $1}' /etc/passwd
sudo awk -F: '$2 == "" {print $1}' /etc/shadow

3. Verrouiller SSH

Clés uniquement, pas de connexion root, peu de tentatives par connexion. La procédure complète, avec les vérifications et le changement de port, se trouve dans Comment stopper les attaques par force brute SSH. La version courte, une fois que la connexion par clé fonctionne :

sudo tee /etc/ssh/sshd_config.d/00-hardening.conf > /dev/null <<'EOF'
PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no
MaxAuthTries 4
EOF
sudo sshd -t && echo "config OK"

sudo systemctl reload ssh

sudo systemctl reload sshd

4. Activer le pare-feu

Refusez tout en entrée, puis n'ouvrez que ce que le serveur propose. Ici SSH sur le 22 et un serveur web sur le 80 et le 443 ; laissez de côté ce que vous ne faites pas tourner.

sudo apt install -y ufw
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp
sudo ufw allow 80,443/tcp
sudo ufw enable
sudo ufw status verbose

sudo dnf install -y firewalld
sudo systemctl enable --now firewalld
sudo firewall-cmd --permanent --add-service=ssh
sudo firewall-cmd --permanent --add-service=http --add-service=https
sudo firewall-cmd --reload
sudo firewall-cmd --list-all

• Sur RHEL 9 et ses recompilations, la zone par défaut autorise aussi cockpit : retirez-le avec sudo firewall-cmd --permanent --remove-service=cockpit si vous ne l'utilisez pas, puis rechargez.
• Docker publie les ports des conteneurs avec ses propres règles iptables, que ufw ne voit pas : un port publié avec -p 8080:80 est ouvert même si ufw dit le contraire. Publiez sur 127.0.0.1:8080:80 quand seul le proxy local en a besoin.
• La plupart des hébergeurs proposent aussi un pare-feu cloud ou un groupe de sécurité. Utilisez-le comme seconde couche, avec les mêmes règles.

5. Activer les mises à jour de sécurité automatiques

La plupart des serveurs compromis font tourner un logiciel dont le correctif était disponible depuis des semaines. Laissez le serveur installer lui-même les mises à jour de sécurité.

sudo apt install -y unattended-upgrades
sudo tee /etc/apt/apt.conf.d/20auto-upgrades > /dev/null <<'EOF'
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";
EOF
sudo unattended-upgrade --dry-run --debug 2>&1 | tail -n 20

Les mises à jour installées sont définies dans /etc/apt/apt.conf.d/50unattended-upgrades (les mises à jour de sécurité sur Ubuntu ; celles de sécurité et des versions intermédiaires sur Debian). Les redémarrages automatiques sont désactivés, sauf si vous y définissez Unattended-Upgrade::Automatic-Reboot "true";.

sudo dnf install -y dnf-automatic
sudo sed -i -e 's/^upgrade_type.*/upgrade_type = security/' \
  -e 's/^apply_updates.*/apply_updates = yes/' /etc/dnf/automatic.conf
sudo systemctl enable --now dnf-automatic.timer
systemctl list-timers dnf-automatic.timer

• CentOS Stream ne publie pas de bulletins de sécurité : upgrade_type = security n'y installe donc rien. Utilisez upgrade_type = default.
• Fedora 41 et suivantes utilisent dnf5 : installez dnf5-plugin-automatic et définissez les mêmes options dans /etc/dnf/automatic.conf (voir man dnf5-automatic).
• Aucun des deux outils ne redémarre par défaut. Prévoyez un redémarrage quand le noyau est mis à jour.

6. Mettre en place des sauvegardes hors du serveur

Une sauvegarde sur le même serveur, ou seulement dans le même compte chez l'hébergeur, disparaît avec le serveur ou le compte. Gardez au moins une copie ailleurs, chiffrée, et testez une restauration. Les snapshots de l'hébergeur sont utiles en complément, pas à la place.

restic est une option simple : chiffré, dédupliqué, vers SFTP, S3 et d'autres. Il est empaqueté pour Debian et Ubuntu, et dans EPEL pour la famille RHEL. Remplacez BACKUP_HOST par votre serveur de sauvegarde ; restic demande un mot de passe pour le dépôt, que vous devez conserver en dehors de ce serveur.

sudo apt install -y restic

sudo dnf install -y epel-release
sudo dnf install -y restic

sudo restic -r sftp:backup@BACKUP_HOST:/srv/restic/$(hostname) init
sudo restic -r sftp:backup@BACKUP_HOST:/srv/restic/$(hostname) backup /etc /home /root /var/www
sudo restic -r sftp:backup@BACKUP_HOST:/srv/restic/$(hostname) snapshots

Exportez les bases de données dans un fichier avant la sauvegarde (mysqldump --single-transaction, pg_dump) plutôt que de copier leurs répertoires de données pendant qu'elles tournent. Prouvez ensuite qu'une restauration fonctionne :

sudo restic -r sftp:backup@BACKUP_HOST:/srv/restic/$(hostname) restore latest --target /tmp/restore-test --include /etc/hostname
cat /tmp/restore-test/etc/hostname

7. Mettre en place la surveillance et les alertes

Vous devez savoir, sans vous connecter, quand le serveur est tombé, quand le disque se remplit et quand quelqu'un se connecte ou l'attaque. Au minimum :

• Une vérification de disponibilité externe du site ou du service, depuis l'extérieur de votre hébergeur.
• Une alerte sur l'espace disque et sur les services en échec.
• Une trace de qui s'est connecté, et une alerte sur les attaques et sur les modifications des fichiers système.

En attendant qu'un outil le fasse pour vous, ces commandes montrent les dernières connexions, les erreurs depuis le démarrage et l'espace disque libre :

last -n 20
sudo journalctl -p err -b --no-pager | tail -n 30
df -h /

8. Fermer les ports inutiles

Listez ce qui écoute. Une adresse 0.0.0.0 ou [::] signifie toutes les interfaces, donc internet, sauf si le pare-feu l'arrête.

sudo ss -tulpn

• Arrêtez et désactivez les services que vous n'utilisez pas.
• Les bases de données et les caches utilisés uniquement par le serveur lui-même écoutent sur localhost : bind-address = 127.0.0.1 pour MySQL et MariaDB, listen_addresses = 'localhost' pour PostgreSQL, bind 127.0.0.1 -::1 pour Redis.
• N'exposez jamais sur internet l'API Docker (2375, 2376) ni un Redis sans mot de passe : ce sont deux portes d'entrée courantes pour les crypto-mineurs.

sudo systemctl disable --now SERVICE_NAME

Vérifiez ensuite depuis l'extérieur, à partir d'une autre machine où nmap est installé. Seuls les ports ouverts à l'étape 4 doivent répondre.

nmap -Pn SERVER_IP

9. Garder l'horloge synchronisée

Les journaux de plusieurs serveurs ne concordent que si leurs horloges sont d'accord, et TLS, les codes de double authentification et la chronologie d'un incident dépendent tous de l'heure. Vérifiez-la :

timedatectl

Vous voulez voir System clock synchronized: yes. Si ce n'est pas le cas :

sudo apt install -y systemd-timesyncd
sudo timedatectl set-ntp true

sudo dnf install -y chrony
sudo systemctl enable --now chronyd
chronyc tracking

10. Conserver les journaux assez longtemps

Quand quelque chose arrive, la première question est ce qui s'est passé avant. Rendez le journal système persistant, avec une taille maximale et une durée de conservation que vous choisissez :

sudo mkdir -p /etc/systemd/journald.conf.d
sudo tee /etc/systemd/journald.conf.d/retention.conf > /dev/null <<'EOF'
[Journal]
Storage=persistent
SystemMaxUse=1G
MaxRetentionSec=1year
EOF
sudo systemctl restart systemd-journald
journalctl --disk-usage

• Dimensionnez la limite selon le disque : 1 Go suffit largement pour un petit serveur.
• La durée de conservation obligatoire dépend de vos contrats et de vos obligations (par exemple la déclaration d'incidents NIS2). Décidez-la, écrivez-la et réglez-la ici.
• Des journaux conservés uniquement sur le serveur peuvent être effacés par celui qui s'y introduit. Envoyez-en aussi une copie vers une autre machine ou un service de journaux.
• Les fichiers de /var/log (serveur web, auth.log sur Debian et Ubuntu) sont tournés par logrotate : la valeur rotate dans /etc/logrotate.d/ fixe le nombre d'anciens fichiers conservés.

Questions

Le pare-feu de l'hébergeur suffit-il, ou faut-il aussi ufw ou firewalld ?

Utilisez les deux quand c'est possible. Le pare-feu de l'hébergeur arrête le trafic avant qu'il atteigne le serveur ; celui du serveur le protège encore si les règles cloud sont modifiées par erreur ou si le serveur est déplacé.

Les mises à jour automatiques sont-elles sûres sur un serveur de production ?

Les mises à jour de sécurité des versions stables de ces distributions sont petites et testées, et bien moins risquées que de laisser tourner des failles connues. Laissez les redémarrages automatiques désactivés et planifiez-les, et gardez une sauvegarde testée.

Combien de temps faut-il conserver les journaux ?

Il n'y a pas de chiffre unique. Cela dépend de vos contrats et de règles comme NIS2 pour les entreprises qu'elle concerne. Fixez une durée, gardez une copie hors du serveur, et assurez-vous que le serveur conserve au moins de quoi enquêter sur les dernières semaines.