Liste de contrôle pour le durcissement du serveur Linux

Une installation Linux par défaut n'est pas une installation Linux sécurisée. Les mauvaises configurations telles que l'accès SSH racine ouvert, les pare-feux faibles et les logiciels non corrigés sont à l'origine de la majorité des violations. Les nouveaux serveurs font l'objet d'analyses automatisées dans les minutes qui suivent leur mise en ligne, de sorte que le durcissement doit intervenir avant toute autre chose.

Cette liste de contrôle couvre les étapes essentielles : verrouillage de SSH, configuration des pare-feu, application de correctifs, renforcement des autorisations de fichiers, activation des contrôles d'accès obligatoires et mise en place d'un système d'enregistrement des audits.

Verrouiller SSH

SSH est votre principal point d'accès et la première chose que les attaquants sondent. La configuration par défaut (authentification par mot de passe, connexion root, port 22) est exactement ce que les scanners automatiques recherchent.

Générez une paire de clés Ed25519, qui offre une meilleure sécurité et de meilleures performances que RSA :

ssh-keygen -t ed25519

Une fois que la connexion par clé fonctionne, mettez à jour le fichier /etc/ssh/sshd_config:

PasswordAuthentication no
ChallengeResponseAuthentication no
PubkeyAuthentication yes
PermitRootLogin no
AllowUsers yourname
MaxAuthTries 3
ClientAliveInterval 300
ClientAliveCountMax 2

Changez le port par défaut de 22 à quelque chose de moins évident. Cela n'arrêtera pas un attaquant déterminé, mais réduira considérablement le bruit des analyses automatiques.

Testez toujours les modifications à partir d'un second terminal avant de fermer la session en cours. Exécutez sudo sshd -t pour vérifier les erreurs de syntaxe, puis systemctl reload sshd pour appliquer les modifications sans interrompre les connexions actives.

Ajouter l'authentification à deux facteurs

l'authentification à deux facteurs signifie qu'un attaquant a besoin à la fois de votre clé SSH et d'un accès physique à votre appareil. Installez le module PAM de Google Authenticator :

sudo apt install libpam-google-authenticator   # Debian/Ubuntu
sudo dnf install google-authenticator           # RHEL/Fedora

Exécutez google-authenticator pour chaque utilisateur afin de générer une clé secrète et des codes de récupération. Stockez les codes de récupération hors ligne.

Ajoutez cette ligne au fichier /etc/pam.d/sshd:

auth required pam_google_authenticator.so

Puis mettez à jour le fichier /etc/ssh/sshd_config:

KbdInteractiveAuthentication yes
UsePAM yes
AuthenticationMethods publickey,keyboard-interactive

Gardez une session active ouverte pendant les tests. Les codes TOTP dépendent de l'exactitude de l'heure du système, assurez-vous donc que NTP fonctionne.

Configurer les pare-feu et Fail2Ban

Exécutez un pare-feu basé sur l'hôte même si votre serveur se trouve derrière un pare-feu de réseau. Le principe est simple : refuser tout le trafic entrant par défaut, puis n'autoriser que ce dont vous avez besoin.

Pour Ubuntu/Debian (UFW) :

ufw default deny incoming
ufw default allow outgoing
ufw limit ssh
ufw enable

Pour RHEL/Rocky/AlmaLinux (Firewalld) :

firewall-cmd --set-default-zone=public
firewall-cmd --permanent --add-service=ssh
firewall-cmd --permanent --add-service=https
firewall-cmd --reload

Durcissez la pile réseau du noyau en ajoutant ces paramètres au fichier /etc/sysctl.conf:

net.ipv4.tcp_syncookies = 1
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.icmp_echo_ignore_broadcasts = 1

Installer Fail2Ban

Fail2Ban surveille les tentatives de connexion et bannit les IP après des échecs répétés. Créez /etc/fail2ban/jail.local (n'éditez pas directement jail.conf, les mises à jour l'écraseront) et configurez-le pour bannir les IP pendant une heure après trois tentatives infructueuses en l'espace de 10 minutes. Définissez le backend correct pour votre pare-feu(banaction = ufw ou banaction = nftables).

Auditer les services et supprimer les protocoles hérités

Vérifiez ce qui est à l'écoute avec ss -tlnp et ce qui est en cours d'exécution avec systemctl list-units --type=service --state=running. Désactivez tout ce dont vous n'avez pas besoin : Bluetooth, CUPS, avahi-daemon, rpcbind.

Supprimez les protocoles hérités qui transmettent des données en clair :

Sur Debian/Ubuntu : sudo apt-get --purge remove xinetd nis tftpd telnetd rsh-server. Sur les systèmes basés sur RHEL : yum erase xinetd ypserv tftp-server telnet-server rsh-server. Vérifiez la suppression avec ss -tulpn.

Patch et automatisation des mises à jour

La mise à jour de votre système est le moyen le plus rapide de combler les failles de sécurité connues. Exécutez les mises à jour immédiatement après le provisionnement :

apt update && apt upgrade -y      # Debian/Ubuntu
dnf update -y                      # RHEL/Rocky

Automatisez ensuite les correctifs de sécurité. Sur Debian/Ubuntu, installez unattended-upgrades et configurez-le pour qu'il n'applique que les correctifs de sécurité. Sur RHEL/Rocky, installez dnf-automatic et définissez upgrade_type = security dans /etc/dnf/automatic.conf.

Mettez en place des notifications par courriel pour les résultats des mises à jour. Désactiver les redémarrages automatiques sur les serveurs de production(Automatic-Reboot = false) afin que les redémarrages aient lieu pendant les fenêtres de maintenance planifiées. Pour les environnements à haute disponibilité, envisagez l'application de correctifs en direct avec Canonical Livepatch (Ubuntu) ou kpatch (RHEL).

Renforcer les systèmes de fichiers et les permissions

Auditez d'abord les fichiers binaires SUID et SGID. Ces fichiers s'exécutent avec des privilèges élevés et sont des cibles de choix pour l'exploitation :

find / -xdev \( -perm -4000 -o -perm -2000 \) -type f -ls

Resserrer les permissions sur les fichiers critiques : /etc/shadow doit être 600, /etc/passwd doit être 644, /etc/ssh/sshd_config doit être 600. Définissez un umask global de 027 dans /etc/profile pour empêcher les nouveaux fichiers d'être lisibles par le monde.

Trouvez et corrigez les fichiers inscriptibles dans le monde avec find / -xdev -type f -perm -0002 -ls. Pour les répertoires qui doivent rester inscriptibles (comme /tmp), appliquez le sticky bit : chmod 1777 /tmp.

Options de montage sécurisé

Modifiez le fichier /etc/fstab pour limiter ce qui peut se passer sur les partitions critiques :

Testez les modifications avec mount -o remount avant de redémarrer pour éviter les problèmes de démarrage.

Activer les contrôles d'accès obligatoires

SELinux et AppArmor ajoutent des restrictions au niveau du noyau sur ce que les processus peuvent faire. Utilisez le système fourni par votre distribution : SELinux pour RHEL/CentOS/Fedora, AppArmor pour Ubuntu/Debian/SUSE. Le passage de l'un à l'autre pose des problèmes de compatibilité.

SELinux : Vérifier l'état avec getenforce. Démarrer en mode permissif(setenforce 0) pendant au moins deux semaines pour capturer le comportement de la charge de travail sans rien casser. Surveiller les violations avec ausearch -m avc -ts recent. Utilisez audit2why pour diagnostiquer les blocages et audit2allow -M [nom_du_module] pour créer des modules de politique. Une fois que les journaux sont propres, passez à l'exécution avec setenforce 1, puis rendez-le permanent dans /etc/selinux/config.

AppArmor : Vérifier les profils actifs avec aa-status. Installer apparmor-utils pour les commandes de gestion. Démarrez les profils en mode "complain " avec aa-complain, puis passez en mode "enforce" avec aa-enforce une fois que vous êtes sûr de vous. Utilisez aa-genprof pour créer des profils pour des applications personnalisées.

Mise en place d'un système d'enregistrement et de suivi des audits

Sans enregistrement, les incidents ne laissent aucune trace. Installez auditd:

sudo apt-get install auditd audispd-plugins

Ajoutez une surveillance du système de fichiers pour les fichiers critiques :

-w /etc/passwd -p wa -k identity
-w /etc/shadow -p wa -k identity

Suivre toutes les exécutions de commandes au niveau de la racine :

-a always,exit -F arch=b64 -S execve -F euid=0 -k root_commands

Charger les règles avec augenrules --load et ajouter -e 2 à la fin de votre fichier de règles pour rendre la configuration inviolable (les changements nécessitent un redémarrage).

Surveillance de l'intégrité des fichiers avec AIDE

AIDE détecte les modifications de fichiers non autorisées en comparant l'état actuel à une base de référence connue. Installez-le, initialisez la base de données avec aideinit, et déplacez le fichier résultant dans /var/lib/aide/aide.db.gz. Mettez en place une tâche cron quotidienne pour exécuter aide --check et envoyer les résultats par courriel aux administrateurs.

Centraliser les journaux

Les journaux locaux sont inutiles si un attaquant disposant d'un accès root les supprime. Transférer les logs vers un serveur distant en temps réel en utilisant rsyslog avec un cryptage TLS. Ajouter au fichier /etc/rsyslog.conf:

*.* @@remote-host:514

Définissez LogLevel VERBOSE dans votre configuration SSH afin que les journaux incluent les empreintes de clés pour chaque connexion réussie. Pour les environnements de production gérant plusieurs serveurs, des outils tels que Wazuh ou OSSEC fournissent une détection d'intrusion basée sur l'hôte avec une analyse centralisée des journaux.

Maintenance continue

Le durcissement n'est pas une tâche ponctuelle. Les configurations dérivent, de nouvelles vulnérabilités apparaissent et les changements de personnel laissent des comptes orphelins.

Chaque semaine : Examiner les journaux Fail2Ban, vérifier l'échec des mises à jour, vérifier les sauvegardes.

Chaque mois : Auditer les comptes d'utilisateurs et les autorisations, examiner les services en cours d'exécution, lancer une analyse complète avec Lynis ou OpenSCAP.

Trimestriellement : Rotation des informations d'identification, mise à jour des règles de pare-feu, test de reprise après sinistre.

Utilisez des outils d'infrastructure en tant que code comme Ansible avec des rôles de durcissement dev-sec.io pour appliquer des configurations cohérentes à travers votre flotte et prévenir les dérives entre les audits.

Les serveurs dédiés de FDC vous donnent un accès complet à la racine et un contrôle total sur votre pile de sécurité. Explorez les options de serveurs dédiés pour construire sur une plateforme dont vous contrôlez chaque couche.