Linux
Sécuriser un serveur Linux Ubuntu en production : guide complet
Introduction
Un serveur Linux fraîchement installé est une passoire : SSH ouvert sur le port 22, connexion root possible, pas de pare-feu actif. Ce guide vous donne la checklist complète de durcissement que j'applique systématiquement sur tous mes déploiements en production en Afrique de l'Ouest.
Étape 1 — Mise à jour et création d'un utilisateur non-root
Bash — Premier démarrage sécurisé (Ubuntu 22.04/24.04)
# Mise à jour complète du système apt update && apt upgrade -y && apt autoremove -y # Créer un utilisateur admin non-root adduser sysadmin usermod -aG sudo sysadmin # IMPORTANT : Testez la connexion avec cet utilisateur # dans un autre terminal avant de bloquer root !
Étape 2 — Durcissement SSH
/etc/ssh/sshd_config — Paramètres de sécurité recommandés
Port 2222 # Changer le port par défaut AddressFamily inet # IPv4 uniquement si IPv6 non utilisé PermitRootLogin no # Interdire la connexion root directe PasswordAuthentication no # Forcer les clés SSH uniquement PubkeyAuthentication yes MaxAuthTries 3 # Max 3 tentatives par connexion ClientAliveInterval 300 # Déconnecter après 5 min d'inactivité ClientAliveCountMax 2 AllowUsers sysadmin # Whitelist des utilisateurs autorisés X11Forwarding no PrintLastLog yes
Bash — Générer et déployer une clé SSH (depuis votre poste)
# Sur votre poste client : ssh-keygen -t ed25519 -C "sysadmin@smanconde" ssh-copy-id -i ~/.ssh/id_ed25519.pub -p 22 sysadmin@VOTRE_IP # Puis redémarrer SSH sur le serveur : systemctl restart sshd
Étape 3 — Pare-feu UFW
Bash — Configuration UFW (Uncomplicated Firewall)apt install ufw -y
# Politique par défaut : bloquer tout en entrée
ufw default deny incoming
ufw default allow outgoing
# Ouvrir uniquement les ports nécessaires
ufw allow 2222/tcp # SSH sur port personnalisé
ufw allow 80/tcp # HTTP (si serveur web)
ufw allow 443/tcp # HTTPS
# Activer et vérifier
ufw enable
ufw status verbose
Étape 4 — Fail2ban contre le brute force
Bash — Installation et configuration Fail2ban
apt install fail2ban -y # Créer la configuration locale (NE PAS modifier jail.conf) cat > /etc/fail2ban/jail.local << EOF [DEFAULT] bantime = 3600 findtime = 600 maxretry = 3 banaction = ufw ignoreip = 127.0.0.1/8 ::1 192.168.1.0/24 [sshd] enabled = true port = 2222 logpath = %(sshd_log)s backend = %(sshd_backend)s EOF systemctl enable fail2ban systemctl start fail2ban # Vérifier le statut fail2ban-client status sshd
Étape 5 — Mises à jour automatiques de sécurité
Bash — Unattended-upgrades (patchs de sécurité auto)
apt install unattended-upgrades apt-listchanges -y dpkg-reconfigure -pmedium unattended-upgrades # Vérifier la configuration générée cat /etc/apt/apt.conf.d/20auto-upgrades # Devrait afficher : # APT::Periodic::Update-Package-Lists "1"; # APT::Periodic::Unattended-Upgrade "1";
Conseil terrain (Sman) : Sur des serveurs en production en Guinée, j'active les mises à jour automatiques uniquement pour les patchs de sécurité, pas les mises à jour de version. Cela évite les régressions inattendues tout en maintenant le niveau de sécurité.
Checklist finale de durcissement
- ✅ Utilisateur non-root avec sudo configuré
- ✅ Authentification par clé SSH uniquement (PasswordAuthentication no)
- ✅ Port SSH non-standard (ex: 2222)
- ✅ Connexion root désactivée (PermitRootLogin no)
- ✅ UFW actif avec politique deny-all en entrée
- ✅ Fail2ban opérationnel sur SSH
- ✅ Mises à jour de sécurité automatiques activées
- ✅ Audit des connexions avec journalctl
Conclusion
Ces étapes couvrent le minimum incompressible pour tout serveur Linux en production. Pour les serveurs hébergeant des applications critiques (messagerie, base de données, ERP), ajoutez-y un audit de sécurité périodique avec Lynis, une surveillance des logs via Wazuh et un chiffrement des disques LUKS pour les données sensibles.