Sécuriser un serveur Ubuntu : les 30 premières minutes

Dès qu’un serveur reçoit une adresse publique, des inconnus viennent frapper à la porte. Personne ne te vise toi en particulier : des scanners automatiques parcourent tout Internet, essaient les portes les plus courantes avec les mots de passe les plus courants. Regarde /var/log/auth.log sur n’importe quelle machine neuve au bout d’une heure et tu les verras. Ce guide, c’est ce que nous ferions pendant la première demi-heure, dans l’ordre qui évite de t’enfermer dehors.

Il vise Ubuntu Server LTS. La version actuelle est Ubuntu 26.04 LTS, sortie en avril 2026 et supportée cinq ans, jusqu’en avril 2031 d’après les notes de version officielles. Les mêmes étapes fonctionnent sur la 24.04. Pars d’une LTS, pas d’une version intermédiaire : tu veux des années de mises à jour de sécurité, pas neuf mois.

Avant de commencer : garde deux terminaux

Chaque étape qui change la façon dont tu te connectes a le même risque : tu casses tout, et la seule porte d’entrée était la session que tu viens de fermer. Ouvre donc deux sessions SSH sur le serveur. Utilise la première pour faire les modifications et la seconde, que tu ne touches pas, comme bouée de sauvetage. Ne la ferme qu’une fois qu’une toute nouvelle troisième connexion a fonctionné. La plupart des hébergeurs proposent aussi une console web qui marche sans SSH : repère où se trouve la tienne avant d’en avoir besoin.

1. Tout mettre à jour

sudo apt update
sudo apt upgrade

Une image neuve peut avoir des semaines, voire des mois de retard. Si la mise à jour a remplacé le noyau, la machine t’indique qu’un redémarrage est nécessaire (le fichier /var/run/reboot-required existe). Fais-le tout de suite, tant que rien ne dépend encore du serveur.

2. Créer un utilisateur normal avec sudo

Travailler en root, c’est transformer chaque faute de frappe en catastrophe, et chaque ligne de log dit « root ». Crée plutôt un utilisateur :

sudo adduser alice
sudo usermod -aG sudo alice

Remplace alice par ton propre prénom. Ne te connecte pas encore avec cet utilisateur : il lui faut d’abord une clé.

3. Se connecter avec une clé SSH

Un scanner ne peut pas deviner une clé, alors qu’il peut deviner un mot de passe. La documentation Ubuntu sur OpenSSH recommande une clé ed25519. Sur ton propre ordinateur, pas sur le serveur :

ssh-keygen -t ed25519
ssh-copy-id alice@your-server-address

Protège la clé privée avec une passphrase. Puis teste, dans un nouveau terminal :

ssh alice@your-server-address
sudo whoami

Si tu entres sans qu’on te demande le mot de passe du compte (une demande de passphrase concerne ta clé, pas le serveur) et que sudo whoami affiche root, l’étape 3 fonctionne. La documentation précise aussi que les permissions des fichiers comptent : authorized_keys ne doit pas être modifiable par les autres utilisateurs, sinon le serveur peut refuser de lui faire confiance.

4. Activer le pare-feu, SSH en premier

Le guide du pare-feu Ubuntu utilise ufw, et met en garde contre le seul point qui compte : l’activer en SSH sans avoir autorisé SSH d’abord te coupe la connexion. Dans cet ordre :

sudo ufw default deny incoming
sudo ufw allow OpenSSH
sudo ufw enable
sudo ufw status verbose

À partir de maintenant, rien de l’extérieur n’atteint le serveur tant que tu ne l’as pas ouvert. Quand tu installes un serveur web ou un serveur de jeu, ouvre son port à ce moment-là (sudo ufw allow 25565/tcp pour un serveur Minecraft, par exemple), et pas avant. Un pare-feu comme celui-ci ne limite pas ce que la machine peut joindre vers l’extérieur, une autre question dont nous reparlons dans pourquoi les serveurs de jeu gratuits se font détourner.

5. Verrouiller sshd, et prouver que ça marche

Maintenant que les clés fonctionnent, désactive les mots de passe et la connexion en root. La documentation dit de valider la configuration avant de redémarrer. Un piège pratique : Ubuntu lit les fichiers de /etc/ssh/sshd_config.d/ dans l’ordre alphabétique, et pour la plupart des options, c’est la première valeur lue qui gagne. Certaines images cloud fournissent un fichier comme 50-cloud-init.conf qui définit PasswordAuthentication yes. Si ton fichier s’appelle 99-hardening.conf, il perd. Nomme le tien pour qu’il passe en premier :

printf 'PasswordAuthentication no\nPermitRootLogin no\n' | sudo tee /etc/ssh/sshd_config.d/01-hardening.conf
sudo sshd -t
sudo systemctl restart ssh

Ensuite, ne fais pas confiance au fichier : demande au démon ce qu’il utilise réellement.

sudo sshd -T | grep -i -E 'passwordauthentication|permitrootlogin'

Tu dois voir passwordauthentication no et permitrootlogin no. Ouvre maintenant un troisième terminal et reconnecte-toi. Alors seulement, ferme la bouée de sauvetage.

Faut-il déplacer SSH sur un autre port ? Ça réduit le bruit dans les logs, et rien d’autre : un scanner trouve n’importe quel port en quelques secondes. Ce n’est pas de la sécurité, et sur les versions récentes d’Ubuntu le service SSH peut être démarré via un socket systemd, donc changer le port demande plus que d’éditer une ligne. Passe ton chemin sauf si tu as une raison.

6. Mises à jour de sécurité automatiques

D’après la documentation Ubuntu, le paquet unattended-upgrades est installé par défaut sur Ubuntu Server, et /etc/apt/apt.conf.d/20auto-upgrades le pilote. Vérifie qu’il contient :

APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";

Teste la configuration sans rien modifier :

sudo unattended-upgrade -v --dry-run

Les redémarrages automatiques sont désactivés tant que tu ne les actives pas (Unattended-Upgrade::Automatic-Reboot dans /etc/apt/apt.conf.d/50unattended-upgrades), donc une mise à jour du noyau attend que tu redémarres. Sur un serveur de jeu, un redémarrage éjecte tous les joueurs : n’active les redémarrages automatiques que volontairement, à une heure qui convient à tes joueurs.

7. fail2ban, pour ce qu’il sait faire

fail2ban lit les fichiers de log et, quand une adresse échoue trop souvent à s’authentifier, ajoute une règle de pare-feu qui la rejette pendant un moment. Installe-le et regarde la jail SSH :

sudo apt install fail2ban
sudo fail2ban-client status sshd

Mets tes propres réglages dans /etc/fail2ban/jail.local plutôt que de modifier jail.conf, que les mises à jour du paquet peuvent remplacer. Reste réaliste sur ce qu’il fait. Avec la connexion par mot de passe désactivée, deviner un mot de passe ne peut de toute façon pas réussir : le principal avantage est donc un log plus calme et moins de CPU gaspillé. Le projet le dit lui-même : il réduit les tentatives échouées mais ne peut pas supprimer le risque d’une authentification faible. Les clés sont la vraie protection ; fail2ban, c’est du rangement.

Ce qu’un honeypot sur le port 22 t’apprend

Si tu es curieux de savoir qui frappe à ta porte, un honeypot répond à la question sans danger. Cowrie est un honeypot SSH et Telnet qui fait semblant d’être un système Unix et enregistre les identifiants essayés, les commandes tapées et les fichiers qu’un intrus tente de télécharger. Fais-le tourner sur une machine isolée qui ne contient rien de toi, et garde ton vrai accès SSH à un endroit où il ne peut pas être confondu avec lui.

Ce que les gens rapportent d’habitude de ces logs n’a rien de glamour, et c’est justement la leçon. Ce sont des observations courantes d’opérateurs de honeypots, pas des mesures de notre part :

• Les mots de passe essayés sont les plus évidents, comme admin, 123456 ou root. Les attaques sont bon marché et larges, pas astucieuses.
• Après une connexion « réussie », les premières commandes sont souvent les mêmes : regarder la machine, puis télécharger et exécuter un script. Ce script est la charge utile, et le fichier mérite d’être gardé et partagé avec les personnes qui analysent les malwares.
• Le but est rarement tes données. C’est le processeur et le réseau de ta machine : minage, relais de trafic, scan d’autres personnes.

Ce dernier point est celui qui compte pour n’importe quel hébergeur. Nous avons raconté un cas réel dans Deux serveurs gratuits, un opérateur de proxy.

Le résultat, en une liste

• Un utilisateur normal avec sudo, connexion par clé uniquement, pas de connexion en root, vérifié avec sshd -T.
• Un pare-feu qui refuse le trafic entrant, sauf ce que tu as ouvert.
• Des mises à jour de sécurité qui s’installent toutes seules.
• Un log plus calme.

Une demi-heure, aucun coût, et le serveur n’est plus la cible facile. Si tu préfères partir d’une machine déjà gérée, un serveur de jeu ou un bot chez Alama t’évite tout ce chapitre, au prix de ne pas avoir root sur la machine.