Hôtes (HCR)

Le module Hôtes vérifie la configuration de vos machines Linux et Windows contre des référentiels de durcissement, sans agent et sans connexion à la machine : il lit une copie de son disque, créée dans votre compte cloud le temps du scan. Un constat est produit par contrôle en échec et par hôte.

La copie de disque

Pour chaque volume relevé par l'inventaire, le scanner de disques de Ctadel procède ainsi dans votre compte, sur les six clouds (AWS, Azure, Google Cloud, Scaleway, OVHcloud, OUTSCALE) :

1. Il crée un instantané du volume, puis un volume à partir de cet instantané.
2. Il démarre une petite machine de scan, étiquetée Ctadel, et lui attache ce volume. Au démarrage, elle installe les outils de lecture nécessaires (dont Trivy pour l'inventaire des paquets, et la lecture des systèmes de fichiers NTFS et du registre Windows). Son réseau est décrit dans Réglages du scanner.
3. Il s'y connecte en SSH et monte la copie en lecture seule, sans rejouer le journal du système de fichiers. Il cherche la partition système, celle qui porte /etc/os-release ou un registre Windows ; les partitions de démarrage et EFI sont écartées, et une partition sans système de fichiers lisible (LUKS, membre LVM ou RAID, swap) est ignorée. Un disque sans partition système est traité comme un disque de données, lu par les modules Données et Secrets mais pas par celui-ci.
4. Il joue les contrôles, puis détache le volume et supprime la machine, le volume et l'instantané. La suppression est faite sur tous les chemins, y compris après une erreur ou une interruption du scan. Un scan dispose de 45 minutes. Une fois par heure et par compte, Ctadel supprime aussi les ressources étiquetées Ctadel de plus de deux heures qu'un scan interrompu aurait laissées.

Le type de système est déduit de la copie : NTFS signifie Windows, le reste Linux ; seules les règles de la plateforme détectée (ou de plateforme « Any ») sont jouées. Les systèmes immuables et conteneurisés (Container-Optimized OS, Flatcar, Bottlerocket) ne sont pas contrôlés : leur configuration n'est pas dans les fichiers que les règles lisent. Les volumes derrière un PersistentVolumeClaim Kubernetes passent par le même chemin.

Les référentiels et les familles de contrôles

Les règles référencent les CIS Benchmarks (Red Hat Enterprise Linux, Ubuntu, Windows, Docker, Azure), les STIG de la DISA et l'OWASP. Des variantes par distribution (Amazon Linux 2023, Red Hat Enterprise Linux 8 et 9, Oracle Linux 8 et 9, Ubuntu 20.04, 22.04 et 24.04, SUSE) reprennent le même contrôle sous le nom du référentiel de cette distribution ; elles ne sont jouées que sur la distribution qu'elles nomment, lue dans /etc/os-release (ID_LIKE compte, donc une règle Red Hat s'applique à Rocky et Alma).

Plateforme	Catégories
Linux	SSH, noyau (sysctl, modules), système de fichiers (permissions, propriétaires, options de montage, SUID, fichiers accessibles en écriture à tous), paquets (présents ou interdits), services (activés ou désactivés au démarrage), mots de passe et comptes, authentification (PAM, sudo), audit (auditd), démarrage (GRUB), correctifs (fin de support), pare-feu, chiffrement, SELinux, réseau, Docker, kubelet des nœuds Kubernetes
Windows	Sécurité réseau (SMB, LDAP, NTLM), authentification et protection des identifiants, services, Defender, exécution automatique, administration à distance (WinRM, RDP), audit, pare-feu, politique de mots de passe, sécurité basée sur la virtualisation, installateur, journalisation et journaux d'événements, protection contre les exploits, chiffrement, domaine, impression, bac à sable, navigateur

Chaque règle porte une sévérité, une catégorie, un type de contrôle et ses paramètres, une correction, et pour la plupart une commande d'audit manuel qui permet de vérifier l'état sur la machine. Les règles qui nomment une distribution, un rôle de serveur Windows (contrôleur de domaine, serveur membre, poste de travail, lu dans la ruche SYSTEM) ou une condition d'exclusion (un moteur de conteneurs présent rend le transfert IP légitime) ne sont jouées que là où elles s'appliquent ; ailleurs elles répondent SKIPPED avec la raison. La page « Politiques » permet d'activer ou de désactiver chaque règle ; voir Politiques.

Ce qu'une copie de disque permet de lire

Une copie de disque porte toute la configuration de démarrage, mais pas l'état en mémoire. Le tableau indique comment chaque type de contrôle est évalué hors ligne.

Type de contrôle	Lecture sur la copie
Valeur de configuration	Le fichier nommé par la règle ; pour sshd_config, la configuration que sshd applique (première valeur gagnante, fichiers Include, blocs Match écartés, valeurs par défaut d'OpenSSH). Un fichier absent du disque donne SKIPPED : le logiciel n'est pas installé.
Paramètres du noyau	Les fichiers sysctl de configuration, dans leur ordre d'application
Modules du noyau	Les fichiers modprobe.d (install, blacklist) et modules-load.d
Services	L'état au démarrage d'après les liens *.wants et les unités masquées de systemd, alias compris. Le constat dit « activé au démarrage », pas « en cours d'exécution ».
Options de montage	/etc/fstab et les unités de montage systemd
Paquets	La base dpkg, apk ou rpm de la copie
Règles d'audit	Les fichiers de règles auditd chargés au démarrage
Permissions, propriétaires, contenu, existence, recherche de fichiers, SUID, écriture pour tous	Le système de fichiers de la copie
Comptes et politique de mots de passe	/etc/passwd, /etc/shadow, /etc/login.defs, PAM
Docker, kubelet	daemon.json et le fichier KubeletConfiguration aux emplacements de kubeadm, EKS, AKS et GKE ; sans fichier kubelet, le disque n'est pas un nœud : SKIPPED
Fin de support	/etc/os-release comparé au calendrier de fin de support publié par endoflife.date, que Ctadel rafraîchit avant chaque scan
Registre Windows	Les ruches SOFTWARE, SYSTEM, SAM et SECURITY sont lues sur la copie ; une valeur non configurée prend la valeur par défaut de Windows quand la règle la donne, et échoue sinon
Services Windows	La valeur Start dans la ruche SYSTEM ; un service absent satisfait « désactivé », comme le prévoit le CIS
Pare-feu Windows	La stratégie de groupe (SOFTWARE\Policies) d'abord, puis le magasin local
Politique de comptes Windows	La politique de comptes de la ruche SAM (longueur et complexité du mot de passe, verrouillage) et l'état des comptes Administrateur et Invité ; sur un contrôleur de domaine la politique est dans Active Directory : SKIPPED
Journaux d'événements Windows	Taille et rétention dans le registre, stratégie de groupe puis clé du service

Ce qui est conservé et affiché

Seuls les contrôles en échec deviennent des constats : hôte, règle, valeur observée, valeur attendue, message, fichier concerné. Un contrôle qui passe à nouveau ferme le constat au scan suivant. Les résultats PASS et SKIPPED ne sont pas enregistrés et n'apparaissent pas dans l'application. Chaque échec nouveau déclenche une notification de type hôtes ; voir Notifications.

La page « Revue de configuration des hôtes » (adresse /hcr) liste les constats du projet actif, ouverts et fermés, triés par sévérité puis par date, avec les colonnes « Sévérité », « Statut », « Règle », « Plateforme », « Hôte » et « Fichier ». Les filtres portent sur « Sévérité », « Statut », « Plateforme » et « Hôte » ; le regroupement sur les mêmes champs. Le bouton « Exporter CSV » exporte la liste filtrée. La page affiche au plus 2 000 constats. Un clic sur une ligne ouvre le panneau de détail, décrit dans Lire un constat.

Règles désactivées

Une partie du catalogue est livrée désactivée, la raison écrite dans la description de la règle sous la forme Disabled: <raison>. En font partie les contrôles qui n'ont pas de source sur une copie de disque : une commande exécutée sur l'hôte en marche (dont les contrôles de pare-feu Linux et de correctifs Windows écrits comme des commandes), les attributions de droits utilisateur et la stratégie d'audit avancée de Windows. Ces règles restent dans le catalogue et ne produisent rien.

Limites

• Le module lit une copie de disque, pas la machine. Il ne voit ni les processus, ni les connexions réseau, ni les services réellement en cours d'exécution : « actif » est lu comme « activé au démarrage ». Un service démarré à la main, ou arrêté après le démarrage, n'est pas vu.
• Marqués SKIPPED et donc invisibles dans l'application : les règles qui ne s'appliquent pas à la distribution ou au rôle du serveur ; les contrôles dont le fichier n'est pas sur le disque (logiciel non installé) ; les contrôles kubelet sur un disque sans kubelet ; la politique de comptes d'un contrôleur de domaine ; une ruche Windows illisible. Les attributions de droits utilisateur et la stratégie d'audit avancée de Windows ne sont pas lues du tout.
• Un disque chiffré (LUKS, BitLocker) ne peut pas être monté : aucun contrôle n'est joué. Un volume LVM n'est lu que si la machine de scan parvient à l'activer.
• Les systèmes immuables (Container-Optimized OS, Flatcar, Bottlerocket) et les disques de données ne sont pas contrôlés.
• Les résultats PASS ne sont pas conservés : l'application ne permet pas de prouver qu'un contrôle est satisfait, seulement qu'il n'est plus en échec.
• Les règles de fin de support dépendent du calendrier endoflife.date disponible au moment du scan ; une distribution absente du calendrier n'est pas jugée.
• Les variantes par distribution ne couvrent que les versions nommées ci-dessus ; les autres distributions sont jugées par les règles génériques.
• Le scan crée un instantané, un volume et une machine dans votre compte, facturés le temps du scan. Si le compte connecté n'a pas les droits correspondants, aucun disque n'est lu.