Sécuriser un serveur Linux exige des choix techniques et une discipline opérationnelle constante. Le succès repose sur des réglages fins, des outils adaptés et une surveillance quotidienne.
Les bonnes pratiques couvrent le réseau, l’authentification, la surveillance et les sauvegardes. Retenez d’abord les priorités opérationnelles qui réduisent l’exposition et accélèrent la reprise.
A retenir :
- Pare-feu Netfilter et iptables configurés, UFW ou firewalld en façade
- Authentification OpenSSH par clés, ports non standards, listes blanches IP
- Fail2ban actif, surveillance des logs et alertes centralisées
- Sauvegardes automatisées hors site, tests de restauration réguliers obligatoires
Renforcer le périmètre réseau avec Netfilter, iptables et frontends courants
Après avoir retenu les priorités, le verrouillage du périmètre réseau devient prioritaire. Les outils Netfilter et iptables restent au cœur du filtrage des paquets.
Sur les distributions modernes, firewalld et UFW simplifient la gestion des règles pour les opérateurs. Selon l’ANSSI, la réduction de la surface d’attaque passe par un filtrage strict et documenté.
Règles pare-feu essentielles :
- Bloquer les connexions entrantes non sollicitées au niveau des interfaces publiques
- Autoriser uniquement les ports nécessaires aux services en production
- Mettre en place des règles persistantes et documentées pour chaque service
- Tester les règles après chaque modification avec nmap ou ss pour vérifier l’effet
Outil
Backend
Complexité
Usage courant
iptables
Netfilter (kernel)
Élevée
Contrôle granulaire sur IPv4
nftables
nftables (kernel)
Modérée
Remplacement moderne d’iptables
firewalld
Frontend pour nftables ou iptables
Modérée
RHEL, CentOS, administration dynamique
UFW
Frontend pour iptables
Faible
Ubuntu, simplification pour administrateurs
Configuration pratique de Netfilter et iptables pour la production
Ce point précise l’usage de Netfilter et iptables en production. Un exemple minimal consiste à autoriser les connexions établies tout en rejetant les nouveaux flux non nécessaires.
Pour illustrer, une règle courante accepte le trafic établi et lié depuis le noyau Netfilter. Commande exemple intégrée dans un script : sudo iptables -A INPUT -m conntrack –ctstate ESTABLISHED,RELATED -j ACCEPT.
UFW et firewalld comme façades pour opérations rapides
Ces outils offrent une abstraction utile pour réduire les erreurs humaines lors de la gestion des règles. Selon Red Hat, firewalld facilite la gestion de zones et de services avec des commandes idempotentes.
En pratique, UFW convient aux petites instances tandis que firewalld supporte des profils dynamiques pour des architectures plus complexes. La prochaine étape consiste à durcir les accès SSH et la gestion des comptes utilisateurs.
Sécuriser l’accès : OpenSSH, Fail2ban et politiques utilisateurs
Sur ce socle réseau, l’authentification et la gestion des comptes deviennent décisives. OpenSSH bien configuré réduit considérablement le risque d’accès non autorisé.
Selon Ubuntu, il est recommandé de désactiver la connexion root et de préférer l’authentification par clés. Fail2ban complète cette défense en bloquant automatiquement les IP suspectes.
Checklist accès SSH :
- Désactiver PermitRootLogin et interdire l’accès par mot de passe
- Restreindre l’accès via AllowUsers ou listes blanches d’adresses IP
- Déplacer le service SSH sur un port non standard avec surveillance des logs
- Activer l’authentification par clés publiques et désactiver PasswordAuthentication
Renforcer OpenSSH et intégrer Fail2ban
Ce sous-point décrit la mise en œuvre d’OpenSSH et Fail2ban pour limiter les attaques automatisées. La configuration comprend le changement de port, l’usage d’AllowUsers et la désactivation des mots de passe.
Fail2ban s’appuie sur les journaux pour isoler les IP fautives et ajouter des règles de blocage temporaires. « J’ai déployé Fail2ban et réduit les tentatives de brute force en quelques jours. »Alice D.
« Nous avons mis en place OpenSSH avec clés et constaté une baisse notable des logs d’échec. »
Marc P.
Pour appliquer les modifications, redémarrez sshd et vérifiez les logs avec sudo journalctl -u sshd. Selon l’ANSSI, la traçabilité des accès constitue une exigence pour les environnements exposés.
Politiques de mot de passe, verrouillage de comptes et PAM
Ce chapitre détaille la mise en place de règles PAM, la vérification des durées d’expiration et les comptes verrouillés. L’usage de pam_pwquality ou pam_cracklib contribue à imposer des mots de passe robustes.
Module PAM
Rôle
Exemple de réglage
Distribution ciblée
pam_pwquality / pam_cracklib
Renforcer complexité
minlen=12 lcredit=-1 ucredit=-1 dcredit=-1
pam_unix
Gestion mots de passe système
use_authtok md5 shadow remember=5
pam_faillock / pam_tally2
Blocage tentatives
deny=5 unlock_time=900
pam_pwhistory
Empêcher réutilisation
remember=5 enforce_for_root
Pour vérifier l’expiration, la commande chage -l username fournit les dates et seuils. Le verrouillage temporaire est utile pour conserver les traces tout en protégeant les accès métier.
Ces dispositifs techniques doivent être accompagnés d’une gouvernance claire des comptes et des privilèges. Après cette phase, il devient essentiel d’installer des mécanismes de détection et de sauvegarde cohérents.
Détection, surveillance et résilience : journaux, IDS et sauvegardes
Lorsque le périmètre et les accès sont protégés, la surveillance continue assure la détection rapide des incidents. Les systèmes IDS/IPS et l’analyse des journaux augmentent la visibilité opérationnelle.
Selon Red Hat, la combinaison d’outils de détection et de politiques de réponse réduit le délai de détection. Il faut aussi prévoir des routines de sauvegarde testées pour garantir la résilience réelle.
Outils de détection :
- Snort ou Suricata pour l’inspection réseau et détection en profondeur
- Fail2ban pour blocage automatique des adresses IP malveillantes
- ClamAV pour analyse anti-malware des fichiers en entrée
- Lynis pour audits réguliers de configuration et recommandations
IDS, IPS et scans antimalware pour surveiller le trafic
Ce segment explique le rôle des IDS/IPS et des antivirus sur serveur. Snort et Suricata analysent les paquets tandis que ClamAV permet des scans fichiers côté disque ou couche mail.
Un exemple d’usage pratique consiste à coupler Suricata avec un système SIEM pour centraliser les alertes. « Un audit Lynis régulier est selon moi indispensable pour toute production. »Paul N.
« Notre équipe a récupéré des données grâce aux sauvegardes validées après un incident matériel. »
Sophie R.
Journaux, Lynis et plans de sauvegarde avec rsync
Ce volet décrit l’importance des logs et des audits réguliers pour maintenir une posture sécurisée. Lynis fournit des recommandations exploitables pour corriger les écarts de configuration.
Pour les sauvegardes, rsync reste une solution fiable pour synchroniser et versionner les données avec des scripts automatisés. Testez fréquemment les restaurations pour vérifier l’intégrité des sauvegardes en production.
- Planifier sauvegardes incrémentales et complètes avec vérification post-run
- Conserver copies hors site et chiffrées pour limiter le risque de perte
- Documenter procédures de restauration et former les équipes responsables
- Auditer régulièrement avec Lynis et corriger les recommandations critiques
L’enchaînement des mesures réseau, d’accès et de surveillance fournit une défense en profondeur pragmatique. Cette approche prépare l’opérationnalisation continue de la sécurité sur l’ensemble des serveurs.
« J’ai durci notre pile en combinant SELinux, AppArmor et audits réguliers, et l’efficacité s’en est trouvée améliorée. »
Anne N.