Skip to content
Documentation

Modules

Hosts (HCR)

The Linux and Windows hardening checks evaluated on a disk copy, the benchmarks followed, what a disk copy lets Ctadel read, what is marked SKIPPED and why, and the “Host Configuration Review” page.

The Hosts module checks the configuration of your Linux and Windows machines against hardening benchmarks, without an agent and without connecting to the machine: it reads a copy of its disk, created in your cloud account for the duration of the scan. One finding is raised per failed check and per host.

The disk copy

For each volume recorded by the inventory, Ctadel's disk scanner proceeds as follows in your account, on the six clouds (AWS, Azure, Google Cloud, Scaleway, OVHcloud, OUTSCALE):

  1. It creates a snapshot of the volume, then a volume from that snapshot.
  2. It starts a small scanner machine, tagged Ctadel, and attaches that volume to it. At start-up it installs the tools it needs to read the disk. Its network is described in Scanner settings.
  3. It connects over SSH and mounts the copy read-only, without replaying the filesystem journal. It looks for the system partition, the one holding /etc/os-release or a Windows registry; boot and EFI partitions are set aside, and a partition with no readable filesystem (LUKS, LVM or RAID member, swap) is skipped. A disk with no system partition is treated as a data disk, read by the Data and Secrets modules but not by this one.
  4. It evaluates the checks, then detaches the volume and deletes the machine, the volume and the snapshot. Deletion happens on every path, including after an error or an interruption of the scan. A scan gets 45 minutes. Once an hour and per account, Ctadel also removes Ctadel-tagged resources older than two hours that an interrupted scan may have left behind.

The system type is inferred from the copy: NTFS means Windows, anything else Linux; only the rules of the detected platform (or of platform "Any") are evaluated. Immutable and container operating systems (Container-Optimized OS, Flatcar, Bottlerocket) are not checked: their configuration is not in the files the rules read. Volumes behind a Kubernetes PersistentVolumeClaim go through the same path.

Benchmarks and check families

The rules reference the CIS Benchmarks (Red Hat Enterprise Linux, Ubuntu, Windows, Docker, Azure), the DISA STIGs and OWASP. Distribution variants (Amazon Linux 2023, Red Hat Enterprise Linux 8 and 9, Oracle Linux 8 and 9, Ubuntu 20.04, 22.04 and 24.04, SUSE) carry the same check under the name of that distribution's benchmark; they are only evaluated on the distribution they name, read from /etc/os-release (ID_LIKE counts, so a Red Hat rule applies to Rocky and Alma).

PlatformCategories
LinuxSSH, kernel (sysctl, modules), filesystem (permissions, owners, mount options, SUID, world-writable files), packages (present or forbidden), services (enabled or disabled at boot), passwords and accounts, authentication (PAM, sudo), audit (auditd), boot (GRUB), patching (end of support), firewall, encryption, SELinux, network, Docker, kubelet of Kubernetes nodes
WindowsNetwork security (SMB, LDAP, NTLM), authentication and credential protection, services, Defender, autoplay, remote management (WinRM, RDP), audit, firewall, password policy, virtualization-based security, installer, logging and event logs, exploit protection, encryption, domain, printing, sandbox, browser

Each rule carries a severity, a category, a remediation, and for most of them a manual audit command to verify the state on the machine. Rules that name a distribution, a Windows server role (domain controller, member server, workstation, read from the SYSTEM hive) or an exclusion condition (a container runtime present makes IP forwarding legitimate) are only evaluated where they apply; elsewhere they answer SKIPPED with the reason. The "Policies" page lets you enable or disable each rule; see Policies.

What a disk copy lets Ctadel read

A disk copy carries the whole boot configuration, but not the in-memory state. The table says what each family of checks reads on the copy.

CheckRead on the copy
Configuration valueThe file named by the rule; for sshd_config, the configuration sshd applies (first value wins, Include files, Match blocks left out, OpenSSH defaults). A file absent from the disk gives SKIPPED: the software is not installed.
Kernel parametersThe sysctl configuration files, in their order of application
Kernel modulesThe modprobe.d files (install, blacklist) and modules-load.d
ServicesThe state at boot from systemd's *.wants links and masked units, aliases included. The finding says "enabled at boot", not "running".
Mount options/etc/fstab and systemd mount units
PackagesThe copy's dpkg, apk or rpm database
Audit rulesThe auditd rule files loaded at boot
Permissions, owners, content, existence, file search, SUID, world-writableThe copy's filesystem
Accounts and password policy/etc/passwd, /etc/shadow, /etc/login.defs, PAM
Docker, kubeletdaemon.json and the KubeletConfiguration file at the kubeadm, EKS, AKS and GKE locations; without a kubelet file the disk is not a node: SKIPPED
End of support/etc/os-release compared with the end-of-support calendar published by endoflife.date, which Ctadel refreshes before each scan
Windows registryThe SOFTWARE, SYSTEM, SAM and SECURITY hives are copied, repaired (transaction logs applied) and read; an unconfigured value takes the Windows default when the rule gives it, and fails otherwise
Windows servicesThe Start value in the SYSTEM hive; a service that is not installed satisfies "disabled", as CIS intends
Windows firewallGroup Policy (SOFTWARE\Policies) first, then the local store
Windows account policyThe F structure of SAM\Domains\Account (password length and complexity, lockout) and the state of the Administrator and Guest accounts; on a domain controller the policy lives in Active Directory: SKIPPED
Windows event logsSize and retention in the registry, Group Policy then the service key

What is kept and shown

Only failed checks become findings: host, rule, observed value, expected value, message, file concerned. A check that passes again closes the finding at the next scan. PASS and SKIPPED results are not stored and do not appear in the application. Each new failure triggers a hosts notification; see Notifications.

The "Host Configuration Review" page (address /hcr) lists the findings of the active project, open and closed, sorted by severity then by date, with the columns "Severity", "Status", "Rule", "Platform", "Host" and "File". Filters cover "Severity", "Status", "Platform" and "Host"; grouping covers the same fields. The "Export CSV" button exports the filtered list. The page shows at most 2,000 findings. Clicking a row opens the detail panel, described in Reading a finding.

The Host Configuration Review page with the list of findings, their platform and their host.
Figure 1. Figure 1. The “Host Configuration Review” page on the demo instance.

Disabled rules

Part of the catalogue ships disabled; the reason is written in the rule's description after Disabled:. Among them are the checks that need the running machine rather than its disk (a command run on the host, the Windows user rights assignments and advanced audit policy); enabled, they answer SKIPPED on every host.

Limits

  • The module reads a disk copy, not the machine. It sees neither processes, nor network connections, nor the services actually running: "active" is read as "enabled at boot". A service started by hand, or stopped after boot, is not seen.
  • Marked SKIPPED and therefore invisible in the application: rules that do not apply to the distribution or server role; checks whose file is not on the disk (software not installed); kubelet checks on a disk without a kubelet; the account policy of a domain controller; an unreadable Windows hive. Windows user rights assignments and the advanced audit policy are not read at all.
  • An encrypted disk (LUKS, BitLocker) cannot be mounted: no check is evaluated. An LVM volume is only read when the scanner machine can activate it.
  • Immutable systems (Container-Optimized OS, Flatcar, Bottlerocket) and data disks are not checked.
  • PASS results are not kept: the application cannot prove that a check is satisfied, only that it is no longer failing.
  • The end-of-support rules depend on the endoflife.date calendar available at scan time; a distribution absent from the calendar is not judged.
  • Distribution variants only cover the releases named above; other distributions are judged by the generic rules.
  • The scan creates a snapshot, a volume and a machine in your account, billed for the duration of the scan. If the connected account lacks the matching rights, no disk is read.