La première heure sur un nouveau serveur dédié Linux : la checklist de durcissement

D'abord la réponse : la checklist

Huit étapes, à peu près dans l'ordre où vous devriez les faire. Chacune prend quelques minutes ; toute la liste tient confortablement dans votre première heure sur la machine :

1. Créez un utilisateur administrateur non-root avec sudo ; arrêtez de vous connecter en tant que root.
2. Faites passer SSH aux clés uniquement et durcissez sshd_config.
3. Appliquez une base de pare-feu en default-deny : autorisez SSH et vos services, droppez le reste.
4. Activez les mises à jour de sécurité automatiques.
5. Installez fail2ban pour bannir les adresses qui échouent à l'authentification.
6. Vérifiez que la synchronisation horaire est active.
7. Vérifiez ce qui écoute et supprimez ou liez en interne tout ce qui ne devrait pas être public.
8. Rendez les logs persistants et parcourez-les une fois.

Tout ce qui figure sur cette liste défend contre le modèle de menace réel du premier jour d'un serveur exposé à internet : scan automatisé et indiscriminé, et credential stuffing. Les recherches sur les honeypots de Unit 42 ont trouvé des services exposés attaqués en quelques minutes après leur mise en ligne, et 80 % des honeypots compromis en moins de 24 heures : les scanners se moquent de qui vous êtes, seulement que vous ayez répondu. Les détails, distribution par distribution, suivent.

Étape 1 : un utilisateur non-root avec sudo

Travailler en permanence en root signifie que chaque faute de frappe s'exécute avec tous les privilèges et que chaque service mal configuré part par défaut sur un blast radius maximal. Deux minutes :

adduser deploy
usermod -aG sudo deploy      # Debian/Ubuntu
usermod -aG wheel deploy     # RHEL/AlmaLinux/Rocky

Copiez votre clé SSH vers le nouvel utilisateur (ssh-copy-id [email protected], ou collez-la dans ~/.ssh/authorized_keys), confirmez que vous pouvez vous connecter et faire sudo -i, puis seulement verrouillez SSH. L'ordre compte : ne désactivez jamais une porte avant que la nouvelle ne s'ouvre de manière démontrée.

Étape 2 : SSH (clés uniquement, root verrouillé)

L'authentification par mot de passe est exactement ce sur quoi parient les botnets qui scannent. Éliminez-la :

# /etc/ssh/sshd_config.d/10-hardening.conf
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no

Validez ensuite et rechargez. sshd -t vérifie la syntaxe de la configuration pour qu'une faute de frappe ne puisse pas mettre SSH à terre avec elle :

sshd -t && systemctl reload ssh    # 'sshd' on the RHEL family

Gardez votre session actuelle ouverte et confirmez qu'une nouvelle connexion fonctionne avant de vous déconnecter. Cette habitude (tester la nouvelle porte pendant que l'ancienne est encore ouverte) fait la différence entre durcir et s'enfermer dehors. (Si jamais cela tourne mal quand même, l'accès console hors bande vous sauve ; on y revient à la fin.)

À savoir :

• Les distributions modernes livrent des réglages crypto SSH par défaut raisonnables ; vous n'avez plus besoin de composer vos listes de chiffrement à la main.
• PermitRootLogin prohibit-password (root par clé uniquement) est une alternative défendable à no si votre outillage a réellement besoin de connexions root ; préférez no plus sudo quand vous avez le choix.
• Sur les versions récentes d'Ubuntu, sshd est activé par socket (ssh.socket), ce qui, la plupart du temps, n'a pas d'importance, jusqu'à ce que vous changiez le port, où là, cela en a énormément. Ce qui nous amène à :
• Changer le port SSH est une réduction de bruit, pas une mesure de sécurité. Cela réduit le spam de logs des scanners les plus bêtes ; cela ne ralentit pas un attaquant équipé d'un scanner de ports. Faites-le pour des logs plus calmes si vous voulez, jamais à la place des clés.

Étape 3 : la base de pare-feu

Debian et Ubuntu sont livrés sans aucune règle de pare-feu. Chaque service à l'écoute est joignable depuis le monde entier dès qu'il démarre. La base prend cinq minutes : default-deny en entrée, autoriser le trafic established, mettre SSH et vos services réels sur liste blanche, et bien régler ICMP (ne le bloquez pas en bloc ; cela casse la découverte de path-MTU et IPv6).

Nous avons rédigé le jeu de règles complet et annoté dans son propre guide, des règles de pare-feu par défaut sensées pour un serveur Linux, avec la même politique en nftables natif, ufw et firewalld, plus la mécanique pour éviter de vous enfermer dehors. Si vous ne suivez qu'un seul lien de cette checklist, que ce soit celui-là. (Vous hésitez entre les syntaxes de règles ? iptables vs nftables.)

Le résumé en une ligne par famille : ufw sur Ubuntu, firewall-cmd sur RHEL/Alma/Rocky, nftables natif sur Debian. Activez-le, autorisez le 22 plus vos ports de service, refusez le reste, pour les deux familles d'adresses.

Étape 4 : mises à jour de sécurité automatiques

La majorité des compromissions réelles exploitent des vulnérabilités pour lesquelles des correctifs étaient disponibles. Un serveur qui se corrige lui-même referme cette fenêtre sans dépendre du fait que vous lisiez les bulletins de sécurité au petit-déjeuner :

# Debian/Ubuntu — installed and on by default on Ubuntu Server; verify:
apt install unattended-upgrades
dpkg-reconfigure -plow unattended-upgrades

# RHEL/AlmaLinux/Rocky — security-only automatic updates:
dnf install dnf-automatic
# set upgrade_type = security in /etc/dnf/automatic.conf, then:
systemctl enable --now dnf-automatic.timer

Limitez-le aux mises à jour de sécurité (les deux réglages par défaut ci-dessus le font déjà), pour que les exécutions non surveillées ne vous surprennent pas avec des sauts de version majeurs. Les mises à jour du noyau ont toujours besoin d'un redémarrage pour prendre effet. Vérifiez de temps en temps ou planifiez des redémarrages ; unattended-upgrades peut effectuer des redémarrages automatiques contrôlés si votre charge de travail le permet.

Étape 5 : fail2ban (bannir sur preuve)

La limite de débit de votre pare-feu freine les tentatives de connexion à l'aveugle ; fail2ban lit le journal d'authentification et bannit les adresses qui échouent réellement, un blocage fondé sur des preuves qui complète à la fois le pare-feu et l'authentification par clé uniquement :

apt install fail2ban    # dnf install fail2ban (needs the EPEL repository on RHEL-family)

Les réglages par défaut du paquet activent la jail SSH, celle qui compte. Un ajustement qui vaut la peine dans /etc/fail2ban/jail.local : ajoutez vos propres IP de gestion à ignoreip pour qu'une clé mal saisie de votre côté ne puisse pas vous bannir.

Fail2ban est-il nécessaire une fois les mots de passe désactivés ? Strictement, non : l'authentification par clé uniquement ne cède pas à la force brute. Il mérite quand même sa place : il réduit nettement le bruit dans les logs, couvre les autres services que vous ajouterez plus tard (mail, panels, bases de données avec journaux d'authentification), et atténue le coût CPU des scanners agressifs.

Étape 6 : synchronisation horaire

Peu glamour et essentiel : la validation des certificats TLS, la réplication de base de données, la corrélation de logs pendant un incident et les tâches planifiées dépendent tous, discrètement, d'une heure correcte. Chaque distribution moderne livre un client NTP ; vérifiez juste qu'il est bien synchronisé :

timedatectl    # look for "System clock synchronized: yes" and "NTP service: active"

Debian/Ubuntu utilisent systemd-timesyncd par défaut ; la famille RHEL utilise chrony. Les deux conviennent pour un serveur ; il n'y a rien à régler le premier jour au-delà de confirmer le yes.

Étape 7 : auditez vos services à l'écoute

Rendez maintenant la liste blanche du pare-feu honnête en découvrant ce qui écoute réellement :

ss -tlnp    # TCP listeners; add -u for UDP

Lisez la sortie avec trois questions : Est-ce que je sais ce que c'est ? Doit-il être joignable depuis internet ? Est-il volontairement sur ma liste blanche de pare-feu ? Les résultats typiques sur une machine neuve sont anodins (sshd, systemd-resolved sur 127.0.0.53), mais c'est cette habitude qui attrape la base de données liée à 0.0.0.0 après le déploiement du mois prochain. Tout ce qui doit rester interne devrait être lié à 127.0.0.1 ou à une adresse de réseau privé, pas seulement filtré par le pare-feu : deux couches valent mieux qu'une.

Si vous utilisez Docker, sachez que les ports de conteneurs publiés contournent entièrement ufw : -p 8080:80 est exposé à internet quelles que soient vos règles. Liez-vous à localhost (-p 127.0.0.1:8080:80) ou utilisez la chaîne DOCKER-USER ; détails dans le guide du pare-feu.

Étape 8 : logs persistants, un survol

Sur certaines distributions, le journal systemd n'existe qu'en mémoire et disparaît au redémarrage, précisément quand vous en auriez besoin. Rendez-le persistant :

mkdir -p /var/log/journal && systemctl restart systemd-journald

Passez ensuite deux minutes à survoler journalctl -p warning -b pour savoir à quoi ressemble la « normale » sur cette machine ; la réponse à incident part d'une base de référence. Raccordez la machine à quelque monitoring que vous fassiez déjà tourner (même une alerte basique d'uptime ou de disque) ; la première heure a seulement besoin que les logs survivent et que quelqu'un soit prévenu quand la machine se comporte mal.

L'aide-mémoire, par famille de distribution

Quelle famille faire tourner en premier lieu est une décision à part entière ; notre guide des distributions Linux couvre le sujet.

Ce qui ne mérite PAS votre temps dans la première heure

Un guide de durcissement honnête dit aussi où commencent les rendements décroissants :

• Le port knocking et l'autorisation par paquet unique. Amusant, obscur et fragile en exploitation ; clés + fail2ban ont déjà gagné ce combat.
• Désactiver SELinux ou AppArmor pour « réparer » une appli. L'inverse du durcissement. Laissez SELinux en enforcing / AppArmor activé ; quand quelque chose casse, corrigez la politique (ou les labels de l'appli), pas le framework.
• Les grandes tournées de durcissement noyau/sysctl. Au-delà des SYN cookies (déjà actifs par défaut) et de ce que règle votre guide de pare-feu, le réglage sysctl du premier jour relève du cargo cult. Faites-le plus tard, avec un benchmark et une raison.
• Les antivirus et scanners de rootkits. Sur un serveur Linux neuf à usage unique, ils consomment surtout de la RAM et produisent des faux positifs. Mis à part les régimes de conformité, laissez-les de côté aujourd'hui.
• Les passages de benchmark CIS. Utiles pour les flottes et les audits, excessifs pour la première heure. La checklist ci-dessus couvre l'intersection entre « impact élevé » et « effort réduit » ; les benchmarks formels peuvent venir avec la maturité.

Le principe : le durcissement de la première heure consiste à fermer les portes que les bots essaient réellement, puis à passer au travail pour lequel vous avez acheté le serveur.

Questions fréquentes

Est-ce utile de changer le port SSH ?

Comme réduction du bruit dans les logs : un peu ; comme sécurité : non. Les botnets non ciblés martèlent surtout le port 22, donc déplacer sshd calme vos logs, mais tout attaquant un tant soit peu motivé lance un scan de ports et le trouve en quelques secondes, et les ports non standard compliquent l'outillage et les pare-feux. Si vous le déplacez quand même, traitez cela comme un ajustement de confort ajouté par-dessus l'authentification par clé uniquement et fail2ban, jamais comme un substitut.

Ai-je encore besoin de fail2ban si l'authentification par mot de passe est désactivée ?

Besoin : non, la force brute ne peut pas battre une clé qu'elle ne peut pas deviner. Envie : sans doute. Fail2ban garde les logs d'authentification lisibles en bannissant le bruit de fond incessant des scanners, étend ce même bannissement fondé sur des preuves aux services que vous ajouterez plus tard, et réduit le coût en ressources d'être scanné. Ce sont cinq minutes de configuration pour un serveur durablement plus calme ; la plupart des exploitants considèrent que c'est un bon compromis.

Faut-il désactiver complètement la connexion root ?

Réglez PermitRootLogin sur no et utilisez sudo depuis un utilisateur nommé : c'est le bon réglage par défaut, et cela vous donne une attribution (quelle clé a fait quoi) plus un obstacle supplémentaire pour les attaquants. L'exception est l'automatisation qui a réellement besoin d'un accès root direct ; dans ce cas, PermitRootLogin prohibit-password (clés uniquement, jamais de mots de passe) est acceptable. Ce qui n'est jamais défendable sur un serveur exposé à internet, c'est root avec connexion par mot de passe.

En quoi un serveur dédié diffère-t-il d'un VPS pour le durcissement ?

La checklist est identique ; les différences se situent en périphérie. Sur un serveur dédié, vous possédez toute la pile, donc il n'y a pas d'agent du fournisseur dans votre OS ni de voisins avec qui partager le noyau ; en contrepartie, la reprise après incident est de votre responsabilité, ce qui rend deux choses plus importantes : l'accès console hors bande (pour quand un changement de pare-feu ou de sshd tourne mal) et les protections en bordure de réseau devant votre port. Vérifiez que votre fournisseur propose les deux avant d'en avoir besoin.

Déploiement sur Serverside

Le durcissement commence avant votre première connexion SSH : sur nos serveurs dédiés, une mitigation DDoS toujours active et un pare-feu de périphérie en libre-service se trouvent en amont de votre port (pour que le trafic non lié à un service puisse être droppé avant même d'atteindre la machine que vous durcissez), et l'accès console KVM-over-IP inclus fait qu'un changement raté de sshd ou de pare-feu se règle en deux minutes au lieu de vous enfermer dehors. Provisionnez Ubuntu, Debian, AlmaLinux/Rocky ou RHEL en moins d'une minute sur l'ASN 55285 et parcourez cette checklist de bout en bout.

Allez plus loin avec les guides complémentaires : règles de pare-feu par défaut sensées, iptables vs nftables, et (pour le jour où les scanners amènent des amis) les attaques DDoS expliquées.