Linux Security Audit — Diagnostic Périodique

Architecture

security-scanner.py  ← wrapper scripts per mode  ← Hermes cron jobs (no_agent)
         │
         ├── local:  subprocess.run()
         └── VPS:    SSH multiplexé (ControlMaster)
         │
         └── Output: Google Sheets dashboard (gspread)
                     Telegram alert (optionnel)

Modes de Scan

Seuils de Score

• ≥ 80/100 — OK, logging simple
• 60–79/100 — WARN, action manuelle conseillée
• < 60/100 — CRITICAL, notification + action corrective immédiate

SSH Multiplexing (VPS)

Pour éviter le overhead des handshakes SSH répétés (chaque check ouvre une connexion), utiliser ControlMaster :

# ~/.hermes/scripts/security-scanner.py
VPS_SOCKET = "/tmp/ssh-vps-scan.sock"

ssh_cmd = [
    "ssh", "-i", VPS_KEY, "-p", VPS_PORT,
    "-o", "ControlMaster=auto",
    "-o", f"ControlPath={VPS_SOCKET}",
    "-o", "ControlPersist=120",
    f"{user}@{host}", cmd
]

Démarrer le canal maître au début du scan : ssh -N -f -o ControlMaster=auto ...

Cron Jobs (Hermes, no_agent)

Créer des wrappers shell par mode/machine :

#!/bin/bash
exec python3 ~/.hermes/scripts/security-scanner.py --mode=quick --vps 2>&1

Puis créer les cron jobs Hermes :

{
  "script": "cron-vps-quick.sh",
  "no_agent": true,
  "deliver": "local",
  "schedule": "0 */6 * * *"
}

Structure du Script Scanner

• run(cmd) — interface unifiée : local → subprocess, VPS → ssh_vps()
• SecurityReport — accumulateur de checks avec score (démarre à 100, déduit pour chaque FAIL)
• Chaque check est une fonction check_xxx(report) qui appelle report.add_check() et report.add_alert()
• Logging via gspread (authentication: ~/.config/gspread/service_account.json ou Google OAuth)
• Destination sheet: le script écrit dans la feuille “Agent Logs” du spreadsheet. L’ancien script VPS (sysguard.py) écrivait dans “🛡️ Security”. Si l’utilisateur signale que le dashboard n’est plus mis à jour, vérifier QUELLE feuille il regarde — voir cron-job-maintenance/references/multi-sheet-dashboard-diagnostic.md.
• Notification Telegram via ~/.hermes/scripts/notify.py

Pitfalls

1. SSH sans multiplexing = timeout en mode daily : 35+ connexions SSH individuelles en daily créent un overhead de handshake de 60-90s. Toujours activer ControlMaster.

2. sudo absent sur la machine locale : checks comme ufw status et fail2ban-client status échouent sans privilèges. Le script doit gérer cela comme un WARN, pas un crash.

   • fail2ban-check nécessite sudo : la fonction check_fail2ban() doit appeler sudo fail2ban-client status sshd pas fail2ban-client status sshd.
   • Sans NOPASSWD, sudo fail2ban-client échoue en non-interactif.
   • Solution : configurer /etc/sudoers.d/security-scanner avec bf ALL=(root) NOPASSWD: /usr/bin/fail2ban-client

3. apt list --upgradable lent sur VPS à forte charge : peut prendre 15-20s. Ne pas mettre timeout < 30s. Également, les dépôts tiers problématiques (UniFi, Warp, FreeDownloadManager) peuvent faire échouer apt update et causer un FAIL sur les mises à jour.

4. Google Sheets credentials : l’authentification gspread est locale. Pour les scans VPS, exécuter le script localement avec --vps (SSH) plutôt que de déployer le script sur le VPS.

5. Nettoyage socket SSH : le socket ControlMaster reste dans /tmp/ après le scan. La config ControlPersist=120 le nettoie automatiquement après 120s d’inactivité.

6. VPS sous-dimensionné : un VPS avec 11Go RAM dont 10Go utilisés + 4Go swap saturé → swap I/O = load élevé (46+). Cela ralentit l’exécution des commandes SSH et peut causer des timeouts. Le scanner le détecte comme CRITICAL sur la charge CPU.

7. Wrapper scripts doivent filtrer les exit codes 1 et 2 : le scanner quitte avec sys.exit(1) pour les avertissements (warnings) et sys.exit(2) pour les erreurs mineures non-bloquantes. Quand le scanner est invoqué via un wrapper no_agent=true cron job, cron interprète tout exit non-zéro comme une erreur et marque le job comme “error”. Solution : dans le wrapper, traiter exit 1 et exit 2 comme des succès :

   #!/bin/bash
   python3 ~/.hermes/scripts/security-scanner.py --mode=daily --local 2>&1
   rc=$?
   if [ $rc -eq 1 ] || [ $rc -eq 2 ]; then
     exit 0  # warnings et erreurs mineures ne sont pas des echecs cron
   fi
   exit $rc

8. Transient SSH congestion peut causer des faux “error” cron : quand le VPS est sous charge (swap I/O, load élevé), les connexions SSH des cron jobs no_agent=true peuvent timeout. Le job est marqué “error” même si le script distant fonctionne parfaitement. Diagnostic : cronjob(action='run', job_id=...) pour exécuter manuellement — si le script s’exécute correctement, c’était un faux positif SSH. Solution : baisser la fréquence des jobs, ou ajouter une retry logic dans le wrapper.

9. Préférer service_account.json à OAuth device flow pour les jobs cron : les tokens OAuth device flow expirent et nécessitent une ré-authentification manuelle tous les ~7 jours. Pour les cron automatisés, utiliser un compte de service Google avec gspread et Credentials.from_service_account_file() — les tokens de service account n’expirent pas. Si OAuth device flow est la seule option, prévoir un mécanisme de notification pour alerter l’utilisateur avant expiration.

Références

• CIS Benchmarks Debian 12
• NIST Cybersecurity Framework (CSF)
• Lynis hardening recommendations
• Debian Security Team advisories

Absorbed: Ubuntu Server Hardening

references/hardening-ubuntu.md — Complete hardening audit for Ubuntu servers: SSH config, fail2ban, UFW firewall, kernel parameters, and security baseline. Previously a standalone skill (ubuntu-server-security-hardening). Use this reference when the audit reveals hardening gaps that need remediation steps.