Vue d'ensemble du hardening système complet

Objectif global

• Réduire la surface d'attaque.
• Limiter les privilèges des services.
• Sécuriser la configuration réseau.
• Améliorer la résilience face aux attaques locales.
• Protéger contre les exploitations kernel.
• Isoler les applications critiques.

Environnement

La chaîne de confiance de boot est détaillée dans les pages Boot Trust, FIDO2 + LUKS et Secure Boot / UKI.

État validé

• VPN principal validé.
• Secure Boot personnalisé, UKI signé et suivi post-update.
• LUKS avec voies TPM2 + PIN, FIDO2, phrase de passe et clé de récupération.
• AppArmor et Firejail actifs selon périmètre.
• nftables en deny-by-default.
• auditd, FIM, widget SecOps et suivi backup Restic.
• Monitoring disque exposé au dashboard local sans mot de passe sudo.

Vue d'ensemble du hardening

Applications sandboxées       Firejail
Contrôle d'accès obligatoire AppArmor
Filtrage réseau              nftables
Services                     systemd hardening
Réseau runtime               sysctl
Base système                 kernel boot + runtime hardening

Couche 1 : Hardening kernel

Les paramètres boot et runtime limitent exploitation mémoire, fuite d'information, ptrace, BPF et comportements réseau dangereux.

slab_nomerge
init_on_alloc=1
init_on_free=1
randomize_kstack_offset=on
mitigations=auto
lsm=landlock,lockdown,yama,apparmor,bpf
apparmor=1
security=apparmor

kernel.kptr_restrict=2
kernel.dmesg_restrict=1
kernel.randomize_va_space=2
kernel.yama.ptrace_scope=1
kernel.unprivileged_bpf_disabled=1
net.core.bpf_jit_harden=2
fs.protected_symlinks=1
fs.protected_hardlinks=1
fs.suid_dumpable=0

Couche 2 : Firewall nftables

La politique de base reste deny-by-default en entrée et en forward, avec sortie libre et diagnostics limités.

chain input
  policy drop
  allow loopback
  drop invalid
  allow established,related
  allow limited icmp
  allow dhcp client

chain forward
  policy drop

chain output
  policy accept

Les exceptions libvirt NAT sont documentées séparément pour ne pas élargir globalement le firewall.

Couche 3 : Réduction surface réseau

Les protocoles réseau inutilisés sont bloqués par configuration module:

install dccp /bin/true
install sctp /bin/true
install rds /bin/true
install tipc /bin/true

lsmod | rg 'dccp|sctp|rds|tipc'

Couche 4 : Hardening services systemd

Les services exposés sont relus avec restrictions adaptées au besoin fonctionnel.

NoNewPrivileges=true
PrivateTmp=true
ProtectSystem=full
ProtectHome=true
UMask=027

Certains services réseau gardent des capacités nécessaires; le compromis sécurité/fonctionnalité est documenté au cas par cas.

Couche 5 : AppArmor

AppArmor est activé via LSM et appliqué progressivement sur services et applications.

aa-status
cat /sys/kernel/security/lsm
journalctl -k --since '1 hour ago' | rg 'apparmor.*DENIED'

État public validé: profils chargés, majorité en enforce, quelques profils en complain et absence de violation récente sur la fenêtre observée.

Couche 6 : Sandbox applicative Firejail

Firejail isole certaines applications desktop exposées. Les applications complexes ou incompatibles restent explicitement hors périmètre.

firejail --list
firejail <APPLICATION>
rg 'Exec=firejail' <DESKTOP_FILES_SCOPE>

Couche 7 : Permissions système

• UMASK restrictif pour éviter des fichiers trop ouverts.
• Core dumps désactivés pour limiter les fuites mémoire.
• Répertoire utilisateur privé.
• Résolution locale du hostname sans requête externe inutile.

umask
sysctl fs.suid_dumpable
stat -c '%A %U:%G %n' <HOME_DIR>

Audit et validation

Lynis donne une tendance, pas un objectif absolu. Les findings sont triés manuellement selon le contexte desktop.

lynis audit system --quick --no-colors
arch-audit
rg 'hardening_index|tests_performed' <LYNIS_REPORT>
<SECOPS_STATUS_SCRIPT>
<BACKUP_STATUS_SCRIPT>

Forces et limites

Forces: kernel durci, firewall strict, surface réseau réduite, services confinés, MAC actif, sandbox applicative, permissions restrictives et chaîne de boot documentée.

Limites: monitoring temps réel partiel, rolling release à suivre, exceptions desktop nécessaires et ajustements continus sur authentification matérielle hors boot.

Prochaines étapes

• Haute priorité: FIDO2 au-delà du boot, SDDM, Hyprlock, widget SecOps.
• Priorité moyenne: API locale sécurité, automatisation des checks, homelab sécurisé.
• Priorité basse: rationalisation secrets, WebAuthn infrastructure, SSH hardware-backed.

Commandes de vérification rapide

La version portfolio évite le script heredoc et présente les contrôles ligne par ligne:

cat /proc/cmdline | tr ' ' '\n' | rg 'slab|init_on|randomize|mitigations|lsm|apparmor'
cat /sys/kernel/security/lsm
nft list ruleset | rg 'policy'
aa-status | head -n 10
firejail --list
lsmod | rg 'dccp|sctp|rds|tipc'
sysctl kernel.kptr_restrict kernel.dmesg_restrict kernel.unprivileged_bpf_disabled
sysctl net.ipv4.conf.all.rp_filter net.ipv4.tcp_syncookies net.ipv4.ip_forward
rg 'hardening_index' <LYNIS_REPORT>

Conclusion

Le hardening système complet repose sur une défense en profondeur: refus par défaut, moindre privilège, isolation, audit et récupération. Il reste évolutif, car une posture de sécurité doit suivre les usages et les menaces.