Sécuriser un nouveau serveur Ubuntu avant d'y mettre des applications

Un serveur Ubuntu neuf, chez n’importe quel fournisseur, arrive avec un seul compte (root), une seule porte d’entrée (un mot de passe ou une clé générée par le fournisseur) et aucune règle de pare-feu. C’est acceptable pour les cinq premières minutes pendant que vous prenez vos repères, mais ce n’est pas encore un serveur sur lequel faire tourner quoi que ce soit. Quiconque scanne internet à la recherche de ports SSH ouverts le trouvera en quelques heures, et un compte root accessible par mot de passe est exactement ce qu’il espère trouver. À la fin de ce guide, vous aurez un utilisateur non-root avec sa propre clé SSH, la connexion root et l’authentification par mot de passe désactivées toutes les deux, un pare-feu qui ne laisse passer que les ports que vous utilisez réellement, fail2ban qui surveille les tentatives de force brute, les mises à jour de sécurité qui s’appliquent d’elles-mêmes, et une courte liste de vérifications pour confirmer que tout ça est bel et bien en place.

Ce qu’il vous faut

• Un serveur Ubuntu 24.04 LTS neuf, chez n’importe quel fournisseur, avec ses identifiants SSH root initiaux (un mot de passe ou une clé générée par le fournisseur).
• Votre propre paire de clés SSH sur votre machine (ssh-keygen -t ed25519 si vous n’en avez pas déjà une).
• Un nom d’utilisateur non-root que vous voulez créer sur le serveur (ce guide utilise deploy).
• Environ vingt minutes, la plupart passées à lire des sorties plutôt qu’à taper.

Étape 1 : créer un utilisateur sudo non-root

Tout faire en root veut dire qu’une seule commande mal tapée, un script compromis ou une clé qui fuit donne accès à toute la machine. Un compte séparé avec sudo vous donne la même capacité d’administrer le serveur, mais seulement quand vous le demandez délibérément, et c’est le compte que Railyard (ou n’importe quel outil de déploiement) utilisera réellement plus tard.

En tant que root :

adduser deploy
usermod -aG sudo deploy

adduser vous guide pour définir un mot de passe et quelques détails optionnels; usermod -aG sudo ajoute le nouveau compte au groupe sudo, qui sur Ubuntu est déjà configuré pour accorder les pleins droits administratifs.

Vérifiez que ça a fonctionné : lancez id deploy et confirmez que sudo apparaît dans la liste des groupes. Ensuite, su - deploy suivi de sudo whoami devrait demander le mot de passe de l’utilisateur deploy et afficher root.

Étape 2 : copier votre clé SSH et tester la connexion

Avant de toucher à quoi que ce soit dans sshd_config, faites fonctionner la connexion par clé pour le nouvel utilisateur et confirmez-la depuis un tout nouveau terminal, pendant que votre session root originale reste ouverte comme filet de sécurité.

La manière simple, depuis votre propre machine :

ssh-copy-id deploy@YOUR_SERVER_IP

Si ssh-copy-id n’est pas disponible, faites-le à la main en tant qu’utilisateur deploy sur le serveur :

mkdir -p ~/.ssh
echo "ssh-ed25519 AAAA... your-public-key-here" >> ~/.ssh/authorized_keys
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Maintenant, dans un deuxième terminal, sans fermer votre session root existante, essayez de vous connecter avec le nouvel utilisateur :

ssh deploy@YOUR_SERVER_IP

Vous devriez vous retrouver directement dans un shell en tant que deploy (il peut demander la phrase de passe de votre propre clé si vous en avez défini une, mais pas un mot de passe pour le compte). Si ça échoue pour une raison quelconque, réglez-le maintenant, toujours depuis votre session root originale. Ne passez pas à l’étape suivante tant que ça ne fonctionne pas.

Étape 3 : désactiver la connexion root et l’authentification par mot de passe

Une fois la connexion par clé confirmée, l’accès root et l’authentification par mot de passe ne sont plus des portes dont vous avez besoin ouvertes, et les laisser ouvertes est exactement ce que la plupart des scanneurs SSH automatisés cherchent.

Modifiez /etc/ssh/sshd_config :

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes

Avant de recharger quoi que ce soit, vérifiez que le fichier est syntaxiquement valide :

sudo sshd -t

Si tout est en ordre, rechargez le service (sur Ubuntu, l’unité systemd s’appelle ssh, pas sshd) :

sudo systemctl reload ssh

Vérifiez que ça a fonctionné depuis un troisième terminal, nouveau (gardez encore une fois votre session de travail ouverte) : ssh root@YOUR_SERVER_IP devrait être refusé d’emblée, et ssh deploy@YOUR_SERVER_IP avec le mauvais mot de passe devrait échouer immédiatement sans même demander de mot de passe, puisque l’authentification par mot de passe est complètement désactivée. Votre connexion par clé déjà établie en tant que deploy devrait continuer à fonctionner exactement comme avant.

Étape 4 : configurer ufw

Un pare-feu qui refuse tout par défaut, puis autorise explicitement seulement les ports que vous utilisez, fait en sorte qu’un port que vous avez oublié de fermer (ou un service que vous avez installé et oublié) n’est pas accessible depuis internet simplement parce qu’il écoute.

sudo apt update
sudo apt install ufw
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable

22/tcp garde SSH accessible (vous pouvez utiliser sudo ufw allow OpenSSH à la place si vous préférez le profil d’application nommé), 80/tcp et 443/tcp couvrent le HTTP et le HTTPS pour ce que vous finirez par déployer. Si vous savez que vous ne servirez rien en HTTP, vous pouvez retirer la règle 80/tcp, même si la plupart des configurations TLS utilisent brièvement le port 80 pour l’émission de certificats.

Vérifiez que ça a fonctionné : sudo ufw status verbose devrait montrer Status: active, Default: deny (incoming), allow (outgoing), et les trois règles que vous venez d’ajouter en ALLOW.

Étape 5 : installer et configurer fail2ban

Même avec l’authentification par mot de passe désactivée, votre port SSH accepte toujours des tentatives de connexion, et un flot constant d’essais de connexion automatisés encombre vos journaux et consomme un peu de CPU pour rien. fail2ban surveille le journal d’authentification et bannit temporairement les adresses IP qui échouent trop de fois à s’authentifier.

sudo apt install fail2ban
sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

La convention de fail2ban est de laisser jail.conf intact (il est écrasé à chaque mise à jour du paquet) et de mettre vos modifications dans jail.local, qui est lu après et a priorité. Ouvrez /etc/fail2ban/jail.local et assurez-vous que la section sshd ressemble à ceci :

[sshd]
enabled = true
port = ssh
maxretry = 5
bantime = 1h
findtime = 10m

Ça bannit une adresse IP pendant une heure après cinq tentatives échouées dans une fenêtre de dix minutes. Ensuite, activez et démarrez le service :

sudo systemctl enable --now fail2ban

Vérifiez que ça a fonctionné : sudo fail2ban-client status sshd devrait montrer le jail en cours d’exécution, avec des compteurs pour les adresses actuellement en échec et actuellement bannies.

Étape 6 : activer les mises à jour de sécurité automatiques

La plupart des compromissions de serveurs ne sont pas des failles zero-day, ce sont des vulnérabilités connues dans des paquets que personne n’a pris le temps de mettre à jour. unattended-upgrades applique les correctifs de sécurité automatiquement, selon un horaire, sans que vous ayez à vous rappeler de vous connecter en SSH pour lancer apt upgrade.

sudo apt install unattended-upgrades

Ubuntu livre ceci avec les mises à jour de sécurité déjà activées pour la version courante une fois installé. Confirmez (et ajustez au besoin) les deux fichiers de configuration :

/etc/apt/apt.conf.d/20auto-upgrades devrait contenir :

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

/etc/apt/apt.conf.d/50unattended-upgrades liste les origines de paquets autorisées à se mettre à jour automatiquement; le dépôt de sécurité de votre version est inclus par défaut.

Vérifiez que ça a fonctionné : sudo unattended-upgrade --dry-run --debug affiche ce qui serait fait lors de la prochaine exécution sans rien changer réellement. Une fois que le service a tourné pour de vrai (il vérifie une fois par jour), /var/log/unattended-upgrades/unattended-upgrades.log montre ce qu’il a installé.

Étape 7 : définir le fuseau horaire et le nom d’hôte du serveur

Celle-ci ne concerne pas les attaquants, mais votre propre tranquillité d’esprit plus tard : des horodatages de journaux qui correspondent à votre propre horloge, et un nom d’hôte qui vous dit quel serveur vous regardez quand vous en avez plus d’un ouvert dans différents onglets de terminal.

sudo timedatectl set-timezone America/Montreal
sudo hostnamectl set-hostname myapp-server-01

Remplacez par le fuseau horaire IANA et le nom d’hôte qui vous conviennent; timedatectl list-timezones liste les valeurs valides si vous n’êtes pas certain du nom exact.

Vérifiez que ça a fonctionné : timedatectl montre le fuseau horaire que vous avez défini sous « Time zone », et hostnamectl montre le nouveau nom d’hôte sous « Static hostname ».

Étape 8 : passe de vérification finale

Avant de considérer le serveur prêt, déconnectez-vous complètement et confirmez que toute la configuration tient la route depuis zéro, pas seulement depuis la session que vous avez gardée ouverte tout du long :

• Ouvrez un tout nouveau terminal et lancez ssh deploy@YOUR_SERVER_IP. Vous devriez atterrir dans un shell en utilisant seulement votre clé, sans invite de mot de passe.
• ssh root@YOUR_SERVER_IP depuis ce même terminal neuf devrait être refusé.
• sudo ufw status verbose montre toujours active avec exactement les ports que vous voulez ouverts.
• sudo fail2ban-client status sshd montre le jail en cours d’exécution.
• sudo whoami en tant qu’utilisateur deploy retourne toujours root après une invite de mot de passe.

Si chacune de ces vérifications passe, le serveur est dans un état raisonnable pour y mettre quelque chose.

Le raccourci : faites-le avec Railyard

Aucune des étapes ci-dessus n’est faite par Railyard à votre place. Il ne touche pas à sshd_config, il ne configure pas ufw ni fail2ban, et il ne réglera pas votre fuseau horaire. Ce dont il a besoin d’un serveur que vous avez déjà durci de la façon décrite plus haut est étroit : l’utilisateur SSH a un sudo sans mot de passe, les ports 22, 80 et 443 sont accessibles depuis internet (exactement les règles que vous venez d’ajouter), et le serveur a au moins 1 Go de mémoire (2 Go ou plus si vous y construisez aussi des images d’applications).

Un détail à régler avant de connecter un serveur : la combinaison par défaut adduser plus usermod -aG sudo de l’étape 1 demande encore à deploy son mot de passe chaque fois qu’il exécute sudo, et Railyard a besoin que ça se fasse sans invite. Ajoutez un fichier sudoers pour ça :

echo "deploy ALL=(ALL) NOPASSWD:ALL" | sudo tee /etc/sudoers.d/deploy
sudo chmod 440 /etc/sudoers.d/deploy

À partir de là : Serveurs → Ajouter un serveur → Connecter votre propre serveur, pointez vers l’adresse IP de ce serveur avec la clé privée correspondant à la clé publique que vous avez copiée à l’étape 2. Cette clé privée est utilisée une seule fois pour l’installation et n’est pas conservée. Le serveur apparaît dans votre tableau de bord en quelques minutes, prêt à recevoir une application.

Si vous préférez ne pas provisionner de serveur à la main du tout, Railyard peut aussi créer un serveur directement sur votre propre compte infonuagique (DigitalOcean, Vultr, Hetzner, AWS ou OVH) et le configurer automatiquement, qui apparaît ensuite dans votre tableau de bord de la même façon. Dans les deux cas, le durcissement décrit plus haut reste votre responsabilité à maintenir en place : Railyard automatise le déploiement d’applications, les mises en production sans interruption, et la gestion des bases de données et des sauvegardes sur un serveur déjà sécurisé, c’est un raccourci qui passe par-dessus l’outillage de déploiement, pas par-dessus le durcissement lui-même.

Dépannage

Vous vous êtes retrouvé coincé dehors après avoir désactivé l’authentification par mot de passe. Ça arrive quand PasswordAuthentication no est rechargé avant que la connexion par clé ait vraiment été confirmée fonctionnelle. Si votre fournisseur offre une console web ou un mode de récupération, utilisez-le pour vous connecter localement et soit réactiver temporairement PasswordAuthentication yes, soit corriger la clé dans ~/.ssh/authorized_keys, puis retestez depuis un terminal neuf avant de la désactiver à nouveau.

ufw bloque un port dont votre application a besoin. Si quelque chose que vous déployez plus tard a besoin d’un port au-delà de 22, 80 et 443 (une base de données que vous exposez intentionnellement, un port d’application différent), ajoutez-le explicitement : sudo ufw allow 5432/tcp, puis revérifiez avec sudo ufw status verbose. C’est généralement plus sûr de garder les bases de données complètement hors d’internet et d’y accéder via un réseau privé plutôt que d’ouvrir un autre port.

fail2ban a banni votre propre adresse IP. Si vous tapez un mot de passe incorrect quelques fois pendant vos tests (ou que vous testez depuis un script qui réessaie rapidement), fail2ban peut bannir l’adresse IP depuis laquelle vous travaillez. Débannissez-la depuis une session encore connectée, ou depuis la console du serveur : sudo fail2ban-client set sshd unbanip YOUR_IP.

Vous pouvez vous connecter en SSH depuis la console du serveur mais pas depuis internet. La plupart des fournisseurs infonuagiques ajoutent leur propre pare-feu au niveau réseau (un « groupe de sécurité » ou « pare-feu infonuagique »), séparé de ufw. Si un port est ouvert dans ufw mais reste inaccessible, vérifiez aussi les paramètres de pare-feu du fournisseur; les deux doivent autoriser les mêmes ports pour que le trafic passe.

Foire aux questions

Dois-je faire tout ça si mon fournisseur a déjà son propre pare-feu ? Oui. Le pare-feu réseau d’un fournisseur est une première couche utile, mais il ne vous donne pas le SSH par clé seulement, il ne bannit pas les tentatives de force brute, et il ne corrigera pas un paquet vulnérable à votre place. Voyez ufw comme une deuxième couche, pas un remplacement.

Vers quel port devrais-je déplacer SSH ? Vous n’êtes pas obligé de le déplacer. Une fois la connexion root et l’authentification par mot de passe désactivées et fail2ban en surveillance, le port 22 n’est plus un point faible significatif, un scanneur qui trouve un port 22 ouvert ne peut pas faire grand-chose sans clé valide. Déplacer SSH vers un port non standard réduit surtout le bruit dans les journaux causé par les scans automatisés; si vous le faites, pensez à mettre à jour autant la directive Port de sshd_config que la règle ufw correspondante, et testez le nouveau port avant de fermer le 22.

À quelle fréquence devrais-je mettre à jour le serveur ? unattended-upgrades applique les correctifs de sécurité chaque jour de lui-même, ce qui couvre les mises à jour les plus importantes. Ça vaut quand même la peine de lancer sudo apt update && sudo apt upgrade à la main de temps en temps pour les mises à jour de paquets non liées à la sécurité, et de redémarrer après une mise à jour du noyau pour que le nouveau soit réellement chargé.

Ai-je encore besoin de fail2ban si l’authentification par mot de passe est déjà désactivée ? Ça vaut quand même la peine de le garder actif. Ça réduit le bruit dans les journaux et le (petit) coût en ressources des tentatives de connexion constamment échouées, et ça applique la même protection à n’importe quel autre service pour lequel vous ajouterez plus tard un jail, pas seulement SSH.

Est-ce que ça s’applique aussi aux versions LTS d’Ubuntu plus récentes ? L’approche générale (un utilisateur sudo non-root, SSH par clé seulement, ufw, fail2ban, mises à jour automatiques) se transpose aux autres versions LTS récentes d’Ubuntu; les commandes et chemins de fichiers de ce guide sont ceux qui s’appliquent à la 24.04. Si vous êtes sur une autre version, ça vaut la peine de vérifier rapidement auprès de la documentation actuelle d’Ubuntu pour tout ce qui aurait changé avant de fixer une étape de durcissement en place.

Aucune de ces étapes ne prend longtemps en soi, et une fois faites, vous n’avez plus à y penser avant le prochain serveur. Ce que vous y gagnez, c’est une machine où un scanneur égaré trouve une porte fermée plutôt qu’ouverte, et c’est la base à partir de laquelle devrait commencer tout serveur sur lequel vous faites tourner quelque chose de réel.