Aller au contenu

Durcissement des systèmes Linux

1. Objectif du cours

Présenter une méthodologie opérationnelle de durcissement Linux appliquée à des serveurs critiques (ex. MediData) : préparation, durcissement du noyau et des fichiers, gestion des comptes, sécurisation des services réseau et validation continue.

2. Notions et définitions essentielles

  • DAC (Contrôle d'Accès Discrétionnaire) : permissions Unix classiques (owner/group/others).
  • MAC (Contrôle d'Accès Obligatoire) : couches additionnelles (SELinux/AppArmor).
  • Capabilities : granularisation des privilèges root pour processus.
  • Durcissement itératif : cycles courts, sauvegarde, test, documentation avant déploiement en production.
  • Baseline : collecte de métriques de performance (CPU, mémoire, disque, réseau) servant de référence.

3. Fonctionnement et principes

  • Défense en profondeur via couches complémentaires (DAC / MAC / capabilities) : une couche peut atténuer la compromission d'une autre.
  • Principe de moindre privilège : limiter droits des comptes, processus et services (éviter root systématique).
  • Approche méthodique : inventaire des services, sauvegardes multiniveaux, désactivation des services inutiles, tests et validation avant chaque changement.
  • Contrôle des flux réseau par firewall “deny by default” : n'autoriser que les flux explicitement nécessaires.
  • Documentation et monitoring continus pour détecter dérives et garantir la maintenabilité.

4. Commandes et manipulations

Regroupées par procédure — seules les commandes présentes dans le PDF sont listées, avec rôle succinct.

  • Sauvegardes / rollback
  • lvcreate -L1G -s -n backup-root /dev/vg0/root : créer snapshot LVM.
  • tar -czf /backup/config-$(date +%Y%m%d).tar.gz /etc /boot/grub : sauvegarde configs.
  • iptables-save > /backup/iptables.rules : exporter règles firewall.

  • dd if=/dev/sda of=/backup/system-image.img : image complète disque.

  • Inventaire et diagnostic

  • systemctl list-units --type=service --state=running : lister services actifs systemd.
  • ss -tuln : lister ports réseau ouverts.
  • ps aux --sort=-%cpu : processus triés par consommation CPU.

  • sar -A 300 > /tmp/baseline.txt : collecte automatique de métriques (exemple).

  • Noyau / paramètres sysctl

  • création d’un fichier dédié /etc/sysctl.d/99-security.conf + sysctl -p (ou sysctl -p /etc/sysctl.d/99-security.conf) : appliquer paramètres de sécurité.

  • Modules & capabilities

  • lsmod : lister modules kernel chargés.

  • getcap / setcap : audit/assignation de capabilities.

  • Permissions et comptes

  • chmod / chown exemples pour restreindre accès (/etc/shadow, clés SSH, /etc, /root, logs, /tmp).

  • usermod -L -s /bin/false daemon : verrouiller compte système.

  • SSH et clés

  • ssh-keygen -t rsa -b 4096 -C "admin@medidata.fr" ; ssh-copy-id : génération et distribution de clés.

  • systemctl restart sshd : appliquer configuration SSH.

  • Pare-feu

  • Exemples iptables pour autoriser services et policy DROP ; iptables-save / iptables-restore pour persistance.

  • Utilisation d’iptables-persistent (package) sur Debian pour restaurer règles au démarrage.

  • Audit & surveillance

  • systemctl enable auditd ; auditctl -w /etc/passwd -p wa -k account_changes : surveillance modifications comptes.
  • pam_tally2 utilisé pour verrouillage/relevé des comptes.

5. Sécurité et bonnes pratiques

  • Méthode itérative : « une modification à la fois, un test à la fois, une validation à la fois » ; maintenir session ouverte pendant les modifications.
  • Sauvegardes multiniveaux (snapshot, tar, export règles, image disque) avant toute modification.
  • Collecte de baseline pendant au moins 48 h pour comparer impact des changements.
  • Tester les désactivations de modules kernel et autres changements dans un laboratoire avant production.
  • Ne pas éditer le fichier système par défaut pour sysctl : préférer des fichiers .conf dédiés dans /etc/sysctl.d.
  • Automatiser uniquement les mises à jour de sécurité critiques et prévoir fenêtres de maintenance, notifications et rollback.
  • Documenter chaque modification (état initial, commande, test, rollback) et centraliser la documentation (wiki interne).
  • Surveiller et alerter sur connexions root et créations de comptes ; journaliser les actions sudo.

6. Points essentiels à retenir pour le TSSR

  • Prioriser les serveurs selon données sensibles : DB > proxy > web.
  • Principe « deny by default » pour le firewall : n’autoriser que ce qui est nécessaire.
  • Durcir noyau via sysctl (réduire informations exposées, protéger contre SYN flood, redirections ICMP).
  • Verrouiller comptes système et limiter sudo par règles granulaires.
  • Privilégier authentification par clés SSH et désactiver l’accès root direct.
  • Sauvegardes multiniveaux et stratégies de rollback indispensables avant durcissement.
  • Auditer initialement avec outils automatisés (Lynis/OpenVAS) et mesurer progrès via mêmes outils.
  • Contrôler persistances : règles firewall, configurations sysctl et services.
  • Mettre en place monitoring d’intégrité (checksums, auditd) et centralisation des logs.
  • Automatiser uniquement les patchs de sécurité avec tests post-installation.

7. Tableau récapitulatif

Élément Objectif principal Risque si absent Exemples d’application
DAC vs MAC vs Capabilities Défense en profondeur Escalade par contournement d’une couche Combinaison de permissions, SELinux/AppArmor, setcap
Backups multiniveaux Rollback / restauration sélective Perte de disponibilité en cas d’erreur Snapshot LVM / tar configs / image dd
Firewall (deny by default) Réduction surface d’attaque Services exposés non intentionnels Politique INPUT DROP, règles ciblées
PAM renforcé Protection auth et anti-brute force Verrous de comptes manquants, mots faibles Verrouillage après échecs, complexité mots de passe
Monitoring & audits Détection dérives et intrusions Dérive silencieuse des configurations Auditd, checksums, Lynis/OpenVAS scans

8. Vérifications pratiques

  • Comparer score Lynis et nombre de vulnérabilités OpenVAS avant/après durcissement.
  • Vérifier que les paramètres sysctl de sécurité sont actifs (état appliqué).
  • Contrôler journalisation des paquets martiens dans les logs noyau pour détecter usurpations IP.
  • Confirmer verrouillage/déverrouillage de comptes suite à échecs d’authentification (audit pam_tally2).
  • Tester l’authentification SSH par clés (connexion sans mot de passe) et absence d’accès root direct.
  • Valider persistance des règles firewall au redémarrage (restore automatique).
  • Contrôler intégrité des fichiers critiques via checksums et alertes d’auditd.
  • Effectuer scans de vulnérabilité et tests de pénétration basiques (reconnaissance, brute force, web) pour valider résistance aux attaques courantes.
  • Exécuter scripts de validation post-mise à jour pour vérifier disponibilité des services critiques.

9. Flashcards Anki

Quelles sont les trois couches complémentaires de sécurité Linux ? :: DAC, MAC et capabilities Commande exemple pour créer un snapshot LVM mentionnée dans le document :: lvcreate -L1G -s -n backup-root /dev/vg0/root Quel paramètre sysctl active la protection contre les SYN flood ? :: net.ipv4.tcp_syncookies = 1 Quel fichier est recommandé pour stocker les paramètres sysctl de sécurité ? :: /etc/sysctl.d/99-security.conf Options recommandées pour monter /tmp afin d’empêcher exécution et escalation ? :: noexec,nosuid,nodev Module PAM cité pour bloquer un compte après 3 échecs pendant 10 minutes :: pam_tally2.so deny=3 unlock_time=600 Commande indiquée pour sauvegarder les règles iptables dans le document :: iptables-save > /backup/iptables.rules Directive à mettre dans sshd_config pour interdire les connexions root directes :: PermitRootLogin no Outil d’audit Linux utilisé et cité avec score avant/après durcissement :: Lynis Mesure recommandée pour forcer le chiffrement des connexions MySQL :: require_secure_transport = ON