Sécuriser un serveur Linux : checklist de base après installation
Checklist simple pour sécuriser un serveur Linux après installation : mises à jour, SSH, firewall, comptes utilisateurs et premiers réflexes de hardening.
Linux Server Hardening : ma checklist de base après installation
Quand on installe un serveur Linux, il ne faut pas partir du principe qu’il est sécurisé par défaut. Même si l’installation est propre, il y a toujours quelques réglages à faire rapidement : SSH, pare-feu, mises à jour, Fail2Ban, logs, utilisateurs, etc.
Dans ce post, je ne vais pas faire une checklist ultra complète pour environnement critique, mais plutôt une base simple : les premières choses que je ferais après l’installation d’un serveur Linux.
Le but n’est pas de rendre le serveur invincible, mais d’éviter les erreurs classiques : root accessible en SSH, mot de passe activé, ports ouverts inutilement, aucun pare-feu, aucun suivi des logs et mises à jour jamais faites.
Petite précision
Les commandes ci-dessous sont surtout orientées Debian / Ubuntu.Sur Rocky Linux, AlmaLinux ou RHEL, le principe reste le même, mais certains outils changent :
- apt devient dnf
- ufw est souvent remplacé par firewalld
- le service SSH peut s’appeler sshd au lieu de ssh
- SELinux est à prendre en compte
1. Mettre à jour le système
Avant de toucher à la configuration SSH ou au pare-feu, je commence toujours par mettre le système à jour.Sur Debian / Ubuntu :
sudo apt update
sudo apt upgrade -y
sudo apt autoremove -y
Sur Rocky Linux / AlmaLinux :
sudo apt upgrade -y
sudo apt autoremove -y
sudo dnf update -y
C’est basique, mais important. Un serveur fraîchement installé peut déjà avoir des paquets en attente de mise à jour, et certaines failles sont corrigées simplement en appliquant les derniers correctifs.
Mises à jour automatiques
Sur Ubuntu, on peut aussi activer les mises à jour de sécurité automatiques avec unattended-upgrades :
sudo apt install unattended-upgrades
sudo dpkg-reconfigure unattended-upgrades
Ce n’est pas obligatoire dans tous les cas, surtout sur un serveur de production sensible, mais pour un petit VPS ou un serveur personnel, ça peut éviter de laisser traîner des correctifs de sécurité pendant des semaines.
sudo dpkg-reconfigure unattended-upgrades
2. Sécuriser l’accès SSH
SSH est souvent la porte d’entrée principale d’un serveur Linux. Si le serveur est exposé sur Internet, il sera rapidement scanné par des bots.La première chose à faire, c’est donc de durcir un minimum SSH.
Ce que je recommande
- désactiver la connexion root directe- utiliser une clé SSH
- désactiver l’authentification par mot de passe
- limiter les utilisateurs autorisés
- éventuellement changer le port SSH
Le changement de port SSH n’est pas une vraie sécurité à lui seul. Ça ne remplace pas une clé SSH ou une bonne configuration. Par contre, ça réduit pas mal le bruit des bots qui scannent automatiquement le port 22.
Modifier la configuration SSH
Ouvrez le fichier de configuration :
sudo nano /etc/ssh/sshd_config
Exemple de configuration simple :
Port 2222
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
AllowUsers admin
Explication rapide :PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
AllowUsers admin
- Port 2222 : change le port SSH
- PermitRootLogin no : bloque la connexion directe avec root
- PasswordAuthentication no : désactive la connexion par mot de passe
- PubkeyAuthentication yes : active l’authentification par clé SSH
- AllowUsers admin : autorise uniquement l’utilisateur admin à se connecter
Attention : avant de redémarrer SSH, gardez toujours une session ouverte. Si vous faites une erreur dans la configuration, vous pouvez vous bloquer vous-même dehors.
Vérifiez la configuration avant de redémarrer :
sudo sshd -t
Si aucune erreur ne s’affiche, vous pouvez redémarrer SSH.Sur Debian / Ubuntu :
sudo systemctl restart ssh
Sur Rocky Linux / AlmaLinux :
sudo systemctl restart sshd
Ensuite, testez une nouvelle connexion SSH dans un autre terminal avant de fermer votre session actuelle :
ssh admin@IP_DU_SERVEUR -p 2222
3. Configurer un pare-feu
Un serveur ne devrait pas exposer plus de ports que nécessaire.L’idée est simple : on bloque tout en entrée, puis on autorise uniquement ce dont on a besoin.
Sur un serveur web classique, on peut par exemple ouvrir :
- le port SSH personnalisé
- le port 80 pour HTTP
- le port 443 pour HTTPS
Avec UFW sur Debian / Ubuntu
Installation :
sudo apt install ufw
Règles de base :
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 2222/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
Vérifier l’état du pare-feu :
sudo ufw default allow outgoing
sudo ufw allow 2222/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verbose
Attention : si vous avez changé le port SSH, pensez bien à l’autoriser avant d’activer UFW. Sinon, vous risquez de couper votre propre accès au serveur.
Avec firewalld sur Rocky Linux / AlmaLinux
Sur Rocky Linux, on utilise souvent firewalld.Vérifier que firewalld est actif :
sudo systemctl status firewalld
L’activer si besoin :
sudo systemctl enable --now firewalld
Ouvrir les ports nécessaires :
sudo firewall-cmd --permanent --add-port=2222/tcp
sudo firewall-cmd --permanent --add-service=http
sudo firewall-cmd --permanent --add-service=https
sudo firewall-cmd --reload
Vérifier les règles :
sudo firewall-cmd --permanent --add-service=http
sudo firewall-cmd --permanent --add-service=https
sudo firewall-cmd --reload
sudo firewall-cmd --list-all
4. Installer Fail2Ban
Fail2Ban est un outil très pratique pour limiter les attaques par brute-force.Il surveille les logs, par exemple ceux de SSH, et peut bannir temporairement une IP après plusieurs tentatives échouées.
Ce n’est pas une protection magique, mais c’est une bonne couche en plus, surtout sur un serveur exposé à Internet.
Installation sur Debian / Ubuntu
sudo apt update
sudo apt install fail2ban
sudo systemctl enable fail2ban
sudo systemctl start fail2ban
Vérifier l’état :
sudo apt install fail2ban
sudo systemctl enable fail2ban
sudo systemctl start fail2ban
sudo fail2ban-client status
Configuration simple pour SSH
Il vaut mieux éviter de modifier directement le fichier jail.conf, car il peut être écrasé lors d’une mise à jour. On va créer un fichier local :
sudo nano /etc/fail2ban/jail.d/sshd.local
Exemple de configuration :
[sshd]
enabled = true
port = 2222
maxretry = 5
findtime = 10m
bantime = 1h
Explication rapide :enabled = true
port = 2222
maxretry = 5
findtime = 10m
bantime = 1h
- enabled = true : active la protection SSH
- port = 2222 : indique le port SSH utilisé
- maxretry = 5 : nombre d’échecs autorisés
- findtime = 10m : période d’observation
- bantime = 1h : durée du bannissement
Redémarrer Fail2Ban :
sudo systemctl restart fail2ban
Vérifier la jail SSH :
sudo fail2ban-client status sshd
Si votre SSH utilise encore le port 22, remplacez simplement 2222 par 22.
5. Vérifier les services et les ports ouverts
Un autre réflexe important : regarder ce qui écoute sur le serveur.Parfois, un service tourne alors qu’on ne l’utilise pas vraiment. Et chaque service exposé est une surface d’attaque en plus.
Pour afficher les ports en écoute :
sudo ss -tulpn
Vous pouvez aussi utiliser :
sudo lsof -i -P -n
L’idée n’est pas de supprimer au hasard, mais de comprendre ce qui tourne.Si vous voyez un service inutile, vous pouvez l’arrêter :
sudo systemctl stop nom_du_service
Et le désactiver au démarrage :
sudo systemctl disable nom_du_service
6. Gérer les utilisateurs et sudo
Un serveur propre, ce n’est pas seulement SSH et le pare-feu. Il faut aussi faire attention aux comptes utilisateurs.Je préfère éviter d’utiliser root directement et passer par un utilisateur avec sudo.
Créer un utilisateur :
sudo adduser admin
L’ajouter au groupe sudo sur Debian / Ubuntu :
sudo usermod -aG sudo admin
Sur Rocky Linux / AlmaLinux :
sudo usermod -aG wheel admin
Vérifier les droits sudo :
sudo -l
Il faut aussi penser à supprimer ou verrouiller les comptes inutiles, surtout sur un serveur qui a déjà vécu.Lister les utilisateurs :
cat /etc/passwd
Verrouiller un compte :
sudo passwd -l nom_utilisateur
7. Vérifier les logs
Sécuriser un serveur, ce n’est pas seulement bloquer des ports. Il faut aussi regarder ce qui se passe dessus.Les logs permettent de voir les connexions SSH, les erreurs système, les services qui plantent ou les tentatives suspectes.
Quelques commandes utiles :
journalctl -xe
journalctl -u ssh
journalctl -u sshd
last
lastb
Sur Debian / Ubuntu, les logs d’authentification sont souvent dans :
journalctl -u ssh
journalctl -u sshd
last
lastb
sudo tail -f /var/log/auth.log
Sur Rocky Linux / AlmaLinux :
sudo tail -f /var/log/secure
Si vous voyez beaucoup de tentatives de connexion SSH échouées, ce n’est pas forcément surprenant sur un serveur exposé à Internet. C’est justement pour ça que la clé SSH, Fail2Ban et le pare-feu sont importants.
8. Installer auditd pour aller un peu plus loin
Pour un serveur personnel, ce n’est pas forcément obligatoire. Mais si vous voulez aller un peu plus loin, auditd peut être intéressant.Auditd permet d’auditer certains événements système : changements de fichiers sensibles, actions administrateur, authentifications, etc.
Sur Debian / Ubuntu :
sudo apt install auditd
sudo systemctl enable auditd
sudo systemctl start auditd
Sur Rocky Linux / AlmaLinux :
sudo systemctl enable auditd
sudo systemctl start auditd
sudo dnf install audit
sudo systemctl enable auditd
sudo systemctl start auditd
Vérifier le service :
sudo systemctl enable auditd
sudo systemctl start auditd
sudo systemctl status auditd
Là, on commence déjà à sortir de la checklist de base, mais c’est bon à connaître si vous voulez mieux suivre ce qui se passe sur le serveur.
9. Quelques erreurs à éviter
Modifier SSH sans garder une session ouverte
C’est l’erreur classique. Vous changez le port SSH ou vous désactivez le mot de passe, puis vous redémarrez le service. Si la configuration est mauvaise, vous êtes bloqué dehors.Gardez toujours une session ouverte pendant les tests.
Activer un pare-feu sans autoriser SSH
Même problème. Si vous activez UFW ou firewalld sans autoriser le port SSH, vous pouvez perdre l’accès au serveur.
Laisser root accessible en SSH
Root ne devrait pas être accessible directement depuis SSH. Il vaut mieux utiliser un compte utilisateur classique avec sudo.
Penser que changer le port SSH suffit
Changer le port réduit le bruit, mais ce n’est pas une vraie protection forte. La vraie base, c’est l’authentification par clé, la désactivation du mot de passe et le blocage du root login.
Ne jamais regarder les logs
Un serveur peut être attaqué ou mal configuré sans que vous le voyiez tout de suite. Les logs sont souvent le premier endroit à regarder quand quelque chose semble bizarre.
Conclusion
Le hardening Linux, ce n’est pas appliquer trois commandes magiques et considérer que le serveur est sécurisé pour toujours.C’est plutôt une série de bons réflexes : mettre à jour le système, sécuriser SSH, fermer les ports inutiles, installer Fail2Ban, gérer correctement les utilisateurs et vérifier les logs de temps en temps.
Ce n’est pas forcément spectaculaire, mais ce sont justement ces réglages de base qui évitent de laisser un serveur exposé bêtement.
Pour un petit VPS, un serveur de lab ou une machine Linux accessible à distance, cette checklist est déjà une bonne base de départ. Ensuite, selon l’usage du serveur, on peut aller plus loin avec SELinux, AppArmor, AIDE, une centralisation des logs, des sauvegardes propres, ou même un benchmark CIS.
Sources / inspiration
Checklist LinuxTeck sur le hardening LinuxDocumentation sshd_config
Documentation UFW Ubuntu
Documentation Fail2Ban Ubuntu-fr
Documentation Ubuntu sur unattended-upgrades