Sécurité et durcissement d'un serveur Linux

1. Principes #

Réduire la surface d'attaque.

Défense en profondeur #

• Minimalisme : installer seulement le nécessaire ; chaque paquet est une vulnérabilité potentielle.
• Moindre privilège : un compte par service, sans shell ; sudo limité.
• Mises à jour : correctifs de sécurité automatiques, redémarrages planifiés.
• Traçabilité : comptes nominatifs, journaux conservés hors du serveur.
• Référentiels : CIS Benchmarks, guide de l'ANSSI « Recommandations de configuration d'un système GNU/Linux ».

ss -tlnup                         # services exposés : chacun est-il nécessaire ?
systemctl list-unit-files --state=enabled
sudo apt purge telnetd rsh-server  # retirer les services obsolètes

2. SSH #

La porte d'entrée.

sshd_config #

# /etc/ssh/sshd_config.d/10-hardening.conf
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
AllowGroups ssh-users
MaxAuthTries 3
LoginGraceTime 30
X11Forwarding no
ClientAliveInterval 300
ClientAliveCountMax 2

sudo sshd -t && sudo systemctl reload ssh   # valider puis recharger
sudo grep 'Failed password\|Invalid user' /var/log/auth.log | tail

Erreur Courante : Gardez une session SSH ouverte pendant que vous testez la nouvelle configuration dans un second terminal : en cas d'erreur, vous pouvez encore corriger.

fail2ban #

fail2ban lit les journaux et bannit temporairement (via le pare-feu) les adresses qui accumulent les échecs.

# /etc/fail2ban/jail.local
[sshd]
enabled  = true
maxretry = 5
findtime = 10m
bantime  = 1h

sudo systemctl enable --now fail2ban
sudo fail2ban-client status sshd

3. Contrôle d'accès obligatoire #

SELinux et AppArmor.

Pourquoi #

Avec les permissions classiques (DAC), un processus compromis peut tout ce que peut son utilisateur. SELinux (famille Red Hat) et AppArmor (Debian, Ubuntu, SUSE) ajoutent une politique imposée par le noyau : nginx ne pourra lire que les fichiers étiquetés pour lui, même s'ils sont lisibles par tous.

SELinux #

getenforce ; sestatus                     # Enforcing, Permissive ou Disabled
ls -Z /var/www/html ; ps -eZ | grep nginx  # contextes
sudo ausearch -m avc -ts recent            # refus récents
sudo semanage fcontext -a -t httpd_sys_content_t '/srv/www(/.*)?'
sudo restorecon -Rv /srv/www               # appliquer le bon contexte
sudo setsebool -P httpd_can_network_connect on
sudo semanage port -a -t http_port_t -p tcp 8081

Erreur Courante : Désactiver SELinux pour « faire marcher » une application supprime une couche de protection. Diagnostiquez le refus (ausearch, audit2why) et corrigez le contexte.

AppArmor #

sudo aa-status                       # profils chargés et mode
sudo aa-complain /usr/sbin/nginx     # mode apprentissage (journalise sans bloquer)
sudo aa-enforce /usr/sbin/nginx
sudo journalctl -k | grep -i apparmor

4. Noyau, audit et intégrité #

Détecter et limiter.

sysctl #

# /etc/sysctl.d/90-hardening.conf
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv4.tcp_syncookies = 1
kernel.kptr_restrict = 2
kernel.dmesg_restrict = 1
fs.protected_symlinks = 1
fs.suid_dumpable = 0

Audit et intégrité #

sudo sysctl --system                        # appliquer
sudo auditctl -w /etc/passwd -p wa -k comptes   # surveiller les écritures
sudo ausearch -k comptes
sudo aide --init && sudo aide --check        # base d'intégrité des fichiers
sudo lynis audit system                      # audit de durcissement avec score

Bonne Pratique : Envoyez les journaux (auth, audit, sudo) vers une plateforme centrale : un attaquant qui obtient root efface d'abord les traces locales.

Secrets et chiffrement #

• Fichiers de secrets en 600, propriété du compte de service.
• Chiffrement des disques (LUKS) pour les portables et serveurs hors datacenter.
• Certificats TLS renouvelés automatiquement (certbot, ACME).
• Aucun secret dans l'historique du shell, les arguments de commande (visibles dans ps) ou Git.