RousselTMLEARNING

Article · Administration Linux : de la découverte à l'expertise

Sécurité et durcissement

1. Principes #

Réduire la surface d'attaque.

Défense en profondeur #

Couches de sécurité
Aucune mesure n'est suffisante seule.
  • 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 #

Chaîne de fail2ban
fail2ban réduit le bruit ; l'authentification par clé reste la vraie protection.

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.

DAC puis MAC
Un fichier lisible par tous reste inaccessible à nginx s'il n'a pas le bon contexte.

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.

📄 Sécurité et durcissement d'un serveur Linux →

Mon suivi

  • ⏱ Durée estimée : ≈ 11 min

Connectez-vous pour suivre votre progression et prendre des notes. Se connecter

✉️ Poser une question

Articles recommandés

Bonnes Pratiques Kubernetes

Meilleures pratiques pour sécuriser et optimiser les déploiements Kubernetes.

Comparaison Offres Kubernetes

Analyse complète des offres managées de Kubernetes avec points forts, fonctionnalités, tarificati...

Stratégies de placement Kubernetes

Présentation des stratégies de placement dans Kubernetes pour optimiser la gestion des charges de...

CNI Kubernetes : Flannel, Calico et Cilium comparés

Kubernetes CNI : comprendre les plugins réseau (Container Network Interface) et comparer Flannel,...

Gestionnaires de packages

Les différents gestionnaires de packages pour Kubernetes et leurs avantages.

Jobs vs Serverless

Comparaison entre les Jobs Kubernetes et le modèle Serverless pour le calcul de tâches en arrière...

PersistentVolume, PersistentVolumeClaim et StorageClass dans Kubernetes

PersistentVolume (PV), PersistentVolumeClaim (PVC) et StorageClass dans Kubernetes : différences,...

Resource Quota Kubernetes

Guide complet sur les quotas de ressources Kubernetes pour la gestion des namespaces.

ConfigMaps et Secrets

Guide complet sur les ConfigMaps et Secrets dans Kubernetes.