Cedric Abonnel
7.9 KiB
Une fois le système de base configuré (dépôts, mises à jour, sudo, identification — sujets traités dans l'article précédent), la machine est fonctionnelle mais encore vulnérable et un peu fragile pour un usage sérieux. Ce deuxième article s'attaque aux gestes qui transforment un serveur « qui marche » en un serveur sur lequel on peut raisonnablement faire tourner quelque chose : sécuriser l'accès SSH, mettre en place un pare-feu, automatiser les correctifs de sécurité et soigner quelques détails opérationnels.
Sécuriser l'accès SSH
SSH est la porte d'entrée principale d'un serveur Linux. C'est aussi, statistiquement, la cible la plus attaquée : n'importe quelle IP publique reçoit en permanence des tentatives de connexion automatisées. Deux gestes simples changent radicalement la donne.
Passer à l'authentification par clé
Les mots de passe, même longs, restent vulnérables aux attaques par force brute et au phishing. Une paire de clés cryptographiques est à la fois plus sûre et plus pratique au quotidien.
Côté poste de travail, on génère une paire de clés modernes :
ssh-keygen -t ed25519 -C "cedrix@laptop"
L'algorithme ed25519 est aujourd'hui le choix par défaut recommandé : clés courtes, signatures rapides, sécurité solide. Le commentaire (-C) facilite l'identification de la clé quand on en gère plusieurs.
On copie ensuite la clé publique sur le serveur :
ssh-copy-id utilisateur@serveur
Cette commande dépose la clé publique dans ~/.ssh/authorized_keys côté serveur avec les bonnes permissions. À partir de là, la connexion se fait sans saisir de mot de passe — il faut tester depuis une nouvelle session avant de passer à l'étape suivante, sous peine de risquer de se retrouver enfermé dehors.
Désactiver la connexion root et les mots de passe
Une fois la connexion par clé validée, on durcit la configuration SSH. Le fichier à modifier est /etc/ssh/sshd_config :
sudo nano /etc/ssh/sshd_config
Les directives importantes à positionner (ou décommenter) sont :
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
La première interdit toute connexion directe en root via SSH : on devra obligatoirement se connecter avec un utilisateur normal puis élever ses droits via sudo. La deuxième supprime complètement l'authentification par mot de passe, ne laissant plus que les clés. La troisième confirme explicitement que l'authentification par clé est active.
On recharge ensuite le service pour appliquer les changements :
sudo systemctl reload ssh
Important : garder la session SSH actuelle ouverte et tester la nouvelle configuration depuis un autre terminal avant de fermer la première. En cas de problème, on peut encore corriger le tir.
Pour aller un cran plus loin, changer le port SSH par défaut (22) vers un port moins évident réduit considérablement le bruit dans les logs. Ce n'est pas de la sécurité au sens strict (un scan le retrouvera), mais c'est un filtre efficace contre les attaques automatisées.
Mettre en place un pare-feu
Par défaut, Debian n'a aucun pare-feu actif. Tout port ouvert par un service installé sera donc directement exposé. Deux outils standards existent : nftables (le successeur officiel d'iptables, bas niveau et puissant) et ufw (une surcouche pensée pour la simplicité). Pour démarrer, ufw est le bon compromis.
sudo apt install ufw
La logique consiste à tout bloquer en entrée par défaut, puis à n'ouvrir explicitement que ce qui doit l'être :
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow ssh
sudo ufw enable
Si SSH écoute sur un port non standard, remplacer ufw allow ssh par ufw allow 2222/tcp (ou le port choisi). Oublier cette étape avant un ufw enable est un grand classique du verrouillage involontaire.
Pour les services web, on ouvrira typiquement les ports 80 et 443 :
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
L'état du pare-feu se vérifie avec :
sudo ufw status verbose
Sur une architecture où la machine est derrière un reverse proxy (cas fréquent quand on expose plusieurs services sur un même domaine), seuls les ports utiles côté proxy doivent être ouverts au monde extérieur. Les services applicatifs eux-mêmes restent accessibles uniquement depuis le réseau interne.
Automatiser les correctifs de sécurité
Les failles de sécurité ne préviennent pas, et personne n'a envie de lancer manuellement apt upgrade chaque matin sur dix machines. Le paquet unattended-upgrades applique automatiquement les mises à jour du dépôt security.
sudo apt install unattended-upgrades
sudo dpkg-reconfigure --priority=low unattended-upgrades
La configuration se trouve ensuite dans /etc/apt/apt.conf.d/50unattended-upgrades. Par défaut, seuls les correctifs de sécurité sont appliqués automatiquement, ce qui est généralement le bon compromis : on profite des patches critiques sans risquer qu'une mise à jour fonctionnelle introduise une régression sur un service en production.
Quelques options qui méritent l'attention dans ce fichier :
Unattended-Upgrade::Automatic-Reboot: à régler sur"true"si l'on accepte les redémarrages automatiques après une mise à jour de noyau, ou"false"si l'on préfère les piloter à la main. La directiveAutomatic-Reboot-Timepermet alors de choisir l'horaire.Unattended-Upgrade::Mail: pour recevoir un rapport par mail des mises à jour appliquées, à condition d'avoir un MTA configuré sur la machine.
Le bon réflexe consiste à vérifier de temps en temps les logs dans /var/log/unattended-upgrades/ pour s'assurer que tout se déroule sans heurts.
Soigner les détails opérationnels
Quelques outils complémentaires améliorent significativement le confort et la résilience d'un serveur.
Fail2ban surveille les logs d'authentification et bannit temporairement les IP qui tentent trop de connexions échouées. Même avec SSH par clé uniquement, le service réduit considérablement le bruit dans les journaux :
sudo apt install fail2ban
La configuration par défaut surveille déjà SSH ; elle peut être étendue à d'autres services (nginx, Postfix, etc.) via des fichiers dans /etc/fail2ban/jail.d/.
Logwatch ou journalctl méritent qu'on s'y attarde. Sur une Debian récente, journalctl est l'outil central pour consulter les logs systemd :
journalctl -u ssh --since "1 hour ago"
journalctl -p err --since today
Prendre l'habitude de jeter un œil aux logs régulièrement — ou de mettre en place une remontée centralisée si l'on gère plusieurs machines — change beaucoup de choses en exploitation.
Un swap raisonnable, sur une VM ou un serveur dédié, évite que la machine ne devienne complètement injoignable en cas de pic de consommation mémoire. Sur un conteneur LXC en revanche, c'est généralement géré au niveau de l'hyperviseur.
Et après ?
Avec ces réglages, le serveur est dans un état correct pour accueillir des services réels : la surface d'attaque est réduite, les correctifs s'appliquent tout seuls, et les logs racontent ce qui se passe. La suite logique est l'installation de la pile applicative proprement dite (serveur web, base de données, runtime) et la mise en place d'un reverse proxy pour exposer plusieurs services derrière un même point d'entrée.
Comme évoqué dans le premier article, le moment où l'on commence à enchaîner ces étapes sur plusieurs machines est exactement celui où il faut basculer vers de l'automatisation : un script shell bien rangé pour commencer, puis Ansible ou un équivalent quand le parc grossit. Une bonne pratique consiste à versionner ces scripts dans un dépôt Git dédié à l'infrastructure, au même titre que le code applicatif.