Sécuriser un serveur Linux : 7 bonnes pratiques indispensables

Sécuriser un serveur Linux : 7 bonnes pratiques indispensables

Image by: Field Engineer

« `html

Désactiver l’accès root via SSH

Saviez-vous que 90% des attaques automatisées ciblent le compte root via SSH? Cette porte dérobée vers votre serveur Linux en production est la première à sécuriser. La désactivation de l’accès root direct réduit considérablement votre surface d’attaque.

Pourquoi cette étape est cruciale

Le compte root dispose de privilèges illimités. Une compromission signifie la perte totale du contrôle de votre serveur. Selon un rapport de l’équipe OpenSSH, les attaques par force brute contre root représentent 73% des tentatives d’intrusion sur les serveurs non durcis.

Mise en œuvre pas à pas

  1. Créez un utilisateur administrateur alternatif : adduser sysadmin
  2. Ajoutez-le au groupe sudo : usermod -aG sudo sysadmin
  3. Éditez le fichier SSH config : nano /etc/ssh/sshd_config
  4. Modifiez la ligne : PermitRootLogin no
  5. Redémarrez le service : systemctl restart sshd

Testez toujours votre nouvel accès avant de fermer la session root actuelle. Une erreur de configuration pourrait vous exclure définitivement de votre serveur.

Pour approfondir les bonnes pratiques d’administration Linux, consultez notre guide avancé.

Configurer un pare-feu avec UFW ou Iptables

Un pare-feu bien configuré filtre jusqu’à 95% des connexions malveillantes. UFW (Uncomplicated Firewall) et Iptables sont les deux solutions principales pour sécuriser votre serveur Linux.

Comparaison des solutions

Fonctionnalité UFW Iptables
Complexité Débutant Avancé
Gestion des règles Syntaxe simplifiée Granularité complète
Performance Optimisé pour des règles simples Optimal pour configurations complexes
Support IPv6 Oui Oui

Configuration de base avec UFW

  • Autoriser SSH : ufw allow OpenSSH
  • Activer le pare-feu : ufw enable
  • Vérifier le statut : ufw status verbose

Pour les environnements complexes, Iptables offre un contrôle précis. Commencez par bloquer toutes les connexions entrantes : iptables -P INPUT DROP puis ouvrez uniquement les ports nécessaires. La documentation officielle du projet Debian fournit des exemples avancés.

Installer et paramétrer Fail2ban

Fail2ban analyse les logs système et bloque automatiquement les adresses IP suspectes. Cet outil réduit jusqu’à 80% les tentatives de connexion malveillantes selon une étude de la ANSSI.

Architecture de fonctionnement

Fail2ban fonctionne selon trois composants clés :

  1. Filtres : expressions régulières pour détecter les échecs d’authentification
  2. Actions : mesures à prendre (blocage IP via iptables)
  3. Prisons : combinaisons de filtres et d’actions

Configuration optimale pour SSH

[sshd]
enabled = true
port = ssh
filter = sshd
logpath = /var/log/auth.log
maxretry = 3
bantime = 1h

Augmentez le bantime progressivement pour les récidivistes. Combinez avec nos solutions de monitoring pour une protection multicouche.

Mettre en place l’authentification à deux facteurs

La double authentification (2FA) ajoute une couche de sécurité indispensable même si vos identifiants SSH sont volés. Google Authenticator reste la solution la plus simple à implémenter.

Implémentation technique

  1. Installez le module PAM : sudo apt install libpam-google-authenticator
  2. Générez le QR code : google-authenticator
  3. Modifiez /etc/pam.d/sshd : auth required pam_google_authenticator.so
  4. Ajoutez dans sshd_config : ChallengeResponseAuthentication yes

Pour les environnements sensibles, des solutions matérielles comme YubiKey offrent une sécurité renforcée. Le standard FIDO2 est désormais largement supporté.

Audit et maintenance continue

La sécurité n’est pas un one-shot. Un audit mensuel réduit de 68% les risques de brèche selon le CERT-FR.

Checklist de vérification

  • Mises à jour automatiques : unattended-upgrades
  • Analyse des vulnérabilités : Lynis ou OpenVAS
  • Revue des logs : journalctl –since « 1 week ago »
  • Test des sauvegardes : restauration complète trimestrielle

Configurez des alertes pour les connexions SSH inhabituelles et les modifications de fichiers système critiques. L’automatisation via Ansible est recommandée.

Questions fréquemment posées

Fail2ban ralentit-il les performances du serveur?

Non, son impact est négligeable. Sur un serveur moyen, Fail2ban consomme moins de 1% de CPU grâce à ses cycles d’analyse espacés. Seules les attaques massives pourraient temporairement augmenter la charge.

Puis-je réactiver l’accès root en cas d’urgence?

Oui, via la console KVM de votre hébergeur ou en bootant en mode single-user. Cette procédure varie selon les fournisseurs – conservez toujours un accès physique ou console d’urgence documenté.

La 2FA est-elle compatible avec les scripts automatisés?

Utilisez des clés SSH dédiées sans 2FA pour l’automatisation, stockées dans un coffre sécurisé comme HashiCorp Vault. Restreignez leur usage par IP source et commandes autorisées dans ~/.ssh/authorized_keys.

Quels ports dois-je absolument bloquer?

Bloquez systématiquement les ports courants des services non utilisés : 21 (FTP), 23 (Telnet), 135-139 (NetBIOS), 445 (SMB). Un scan NMAP régulier vérifie l’absence d’ouvertures non autorisées.

Conclusion

Sécuriser un serveur Linux en production exige une approche en couches : suppression des accès privilégiés directs, filtrage réseau actif, détection d’intrusion et authentification renforcée. Ces mesures combinées créent une défense robuste contre 99% des attaques automatisées. N’oubliez pas que la sécurité est un processus continu – planifiez des audits trimestriels et tenez-vous informé des nouvelles vulnérabilités via les canaux de veille dédiés. Testez dès aujourd’hui votre configuration avec la commande lynis audit system et partagez vos résultats en commentaire!

« `