Checks Reference

Complete reference of all 287 security checks. Each entry describes what is validated, why it matters, and the security consequences of a failed check.

AUTH Users & Authentication 8 PAM Password Policies 5 NET Network & Firewall 11 SVC Services & Processes 13 FS Filesystem & Permissions 12 LOG Logging & Auditing 9 PKG Packages & Updates 4 HARD Kernel Hardening 12 BOOT Boot Security & MAC 8 CRON Scheduled Jobs 7 CRYPTO TLS/SSL & Cryptography 9 SEC Secrets & Credentials 4 CTR Container Security 11 RLIM Resource Limits 7 NFS Network Filesystems 4 MAL Rootkits & Malware 4 BAK Backups 4

AUTH — Users & Authentication

Validates user accounts, SSH configuration, sudo policies, and file permissions that control who can access the system and how they authenticate.

AUTH-001 SSH root login disabled CRITICAL

Verifies that PermitRootLogin is set to no in /etc/ssh/sshd_config and drop-in configs.

Why it matters: Direct root login via SSH allows attackers to brute-force the most privileged account on the system. A successful attack grants full control immediately — no privilege escalation needed. Disabling root login forces attackers to compromise a regular user first, then escalate, which is significantly harder and leaves more forensic evidence.
References: CIS Benchmark 5.2.10, DISA STIG V-72247

AUTH-002 SSH password authentication disabled HIGH

Checks that PasswordAuthentication is set to no, requiring key-based authentication only.

Why it matters: Password-based SSH authentication is vulnerable to brute-force and credential stuffing attacks. SSH keys provide cryptographically strong authentication that cannot be guessed. Even with fail2ban, password authentication exposes the server to large-scale automated attacks.
References: CIS Benchmark 5.2.15

AUTH-003 Only root has UID 0 CRITICAL

Scans /etc/passwd for any account besides root with UID 0.

Why it matters: Any account with UID 0 has unrestricted root privileges. A hidden UID 0 account is a common backdoor technique — an attacker creates a seemingly harmless user that secretly has full system control. This bypasses sudo logging and audit trails.
References: CIS Benchmark 6.2.2

AUTH-004 No users with empty password CRITICAL

Reads /etc/shadow to find accounts with an empty password hash field.

Why it matters: An account with an empty password can be accessed by anyone — locally, via SSH (if password auth is enabled), or through any PAM-based service. This is equivalent to leaving a door wide open. Attackers scan for these accounts as a trivial entry point.
References: CIS Benchmark 6.2.1

AUTH-005 System accounts have nologin shell HIGH

Verifies that system accounts (UID < 1000) use /sbin/nologin or /bin/false as their shell.

Why it matters: System accounts like www-data, mysql, or nobody exist to run services with limited privileges. If these accounts have a real login shell, an attacker who compromises a service can pivot to an interactive session, install tools, and establish persistence. Nologin shells prevent this lateral movement.
References: CIS Benchmark 5.5.2

AUTH-006 No excessive NOPASSWD in sudoers HIGH

Scans /etc/sudoers and /etc/sudoers.d/ for NOPASSWD directives.

Why it matters: NOPASSWD entries allow users to execute commands as root without re-authenticating. If an attacker compromises a user session (stolen SSH key, session hijacking), they inherit passwordless root access. Every NOPASSWD entry is a potential privilege escalation path that should be minimized and audited.
References: CIS Benchmark 5.3.4

AUTH-007 Sensitive auth files have correct permissions HIGH

Validates /etc/passwd (644), /etc/shadow (640), and /etc/group (644).

Why it matters: /etc/shadow contains password hashes — if world-readable, any user can copy the hashes and crack them offline at their leisure. Incorrect permissions on /etc/passwd could allow modification of user accounts. These files are the foundation of Linux authentication.
References: CIS Benchmark 6.1.2–6.1.4

AUTH-008 su restricted via pam_wheel MEDIUM

Checks /etc/pam.d/su for an active pam_wheel.so requirement.

Why it matters: Without pam_wheel.so, any user who knows root's password can use su to become root. Restricting su to the wheel group limits who can even attempt to escalate, adding a layer of defense even if root's password is leaked.
References: CIS Benchmark 5.6

PAM — Password Policies

Validates PAM (Pluggable Authentication Modules) configuration for password strength, reuse prevention, and account lockout policies.

PAM-001 Password quality enforced via pam_pwquality MEDIUM

Verifies pam_pwquality is enabled and configured with minlen ≥ 14 and minclass ≥ 4.

Why it matters: Weak passwords are the #1 attack vector for credential-based attacks. Without enforced complexity, users will choose passwords like "password123" that fall in seconds to dictionary attacks. NIST SP 800-63B recommends minimum 14 characters with multiple character classes.
References: CIS Benchmark 5.4.1

PAM-002 Password reuse prevention configured MEDIUM

Checks pam_pwhistory or pam_unix with remember ≥ 5.

Why it matters: If users can reuse passwords, a previously compromised password remains valid indefinitely. Remembering the last 5+ passwords forces users to create genuinely new credentials after a breach, closing the window of exposure.
References: CIS Benchmark 5.4.3

PAM-003 Account lockout after failed attempts HIGH

Validates pam_faillock is configured with deny ≤ 5 and unlock_time ≥ 900 seconds.

Why it matters: Without account lockout, an attacker can attempt unlimited password guesses against local accounts. Even with strong passwords, a sufficiently persistent attacker can eventually succeed. Lockout after 5 attempts with a 15-minute cooldown makes brute-force impractical while remaining usable.
References: CIS Benchmark 5.4.2, DISA STIG V-71943

PAM-004 PAM module ordering correct MEDIUM

Ensures pam_faillock appears before pam_unix in the auth stack.

Why it matters: If pam_unix processes the authentication attempt before pam_faillock, the lockout mechanism is bypassed entirely — failed attempts are never counted. This is a subtle misconfiguration that completely negates account lockout protection.
References: CIS Benchmark 5.4.2

PAM-005 Password expiration configured LOW

Validates /etc/login.defs: PASS_MAX_DAYS ≤ 365, PASS_MIN_DAYS ≥ 1, PASS_WARN_AGE ≥ 7.

Why it matters: Password aging ensures credentials don't remain valid indefinitely. While NIST 800-63B no longer recommends periodic rotation for strong passwords, many compliance frameworks (PCI DSS, HIPAA) still require it. PASS_MIN_DAYS prevents users from cycling through passwords to return to their favorite.
References: CIS Benchmark 5.5.1

NET — Network & Firewall

Evaluates network security: firewall status, exposed ports, IP forwarding, DNS security, and SNMP configuration.

NET-001 Firewall is active CRITICAL

Detects active firewall via ufw, nftables, or iptables with loaded rules.

Why it matters: A server without a firewall exposes every listening service to the entire network. Any vulnerability in any service becomes directly exploitable. A firewall is the most fundamental network defense — without it, internal services (databases, admin panels, debug ports) are accessible to attackers.
References: CIS Benchmark 3.5.1, DISA STIG V-72315

NET-002 No unnecessary open ports HIGH

Parses /proc/net/tcp and /proc/net/tcp6 to list all listening TCP ports.

Why it matters: Every open port is an attack surface. Unnecessary services listening on the network increase the risk of exploitation. A forgotten debug server, an unused database port, or a test API can all be entry points. Regular port auditing ensures only intended services are exposed.
References: CIS Benchmark 3.5.4

NET-003 IP forwarding disabled MEDIUM

Checks net.ipv4.ip_forward and net.ipv6.conf.all.forwarding are 0.

Why it matters: IP forwarding turns the server into a router, allowing it to pass traffic between networks. If enabled unintentionally, an attacker who compromises the server can use it to reach otherwise isolated networks, bypassing network segmentation and firewall rules.
References: CIS Benchmark 3.2.1

NET-004 Services not bound to 0.0.0.0 MEDIUM

Identifies services listening on all interfaces (0.0.0.0) instead of localhost or specific IPs.

Why it matters: A service bound to 0.0.0.0 is accessible from every network interface. Internal services (monitoring, management, databases) should bind to localhost or a management interface only. Binding to all interfaces unnecessarily extends the attack surface to public networks.

NET-005 DNS resolvers configured LOW

Verifies nameserver entries exist in /etc/resolv.conf.

Why it matters: Without DNS resolvers, the system cannot resolve hostnames — breaking package updates, certificate validation (CRL/OCSP), and security tool connectivity. This is primarily an availability concern but can also prevent security updates from being fetched.

NET-006 DNSSEC validation enabled LOW

Checks DNSSEC=yes in systemd-resolved or presence of Unbound resolver.

Why it matters: Without DNSSEC, DNS responses can be forged (DNS spoofing/cache poisoning). An attacker can redirect the server to malicious IP addresses for package repositories, update servers, or API endpoints. DNSSEC cryptographically validates DNS responses to prevent tampering.

NET-007 DNS over TLS/HTTPS configured LOW

Verifies DNSOverTLS=yes or opportunistic in systemd-resolved.

Why it matters: Standard DNS queries are sent in cleartext, allowing anyone on the network path to see which domains the server resolves. DNS over TLS/HTTPS encrypts queries, preventing traffic analysis and DNS-based surveillance or interception.

NET-008 IPv6 disabled or properly configured MEDIUM

Checks if IPv6 is disabled or, if enabled, that Router Advertisements are rejected (accept_ra=0).

Why it matters: If IPv6 is enabled but not managed, rogue Router Advertisements can redirect traffic through an attacker-controlled gateway (MITM). Many organizations don't monitor IPv6 traffic, making it an invisible attack channel. If IPv6 isn't needed, disabling it removes this entire attack surface.

NET-009 SNMP v1/v2c disabled HIGH

Checks /etc/snmp/snmpd.conf for rocommunity/rwcommunity directives (v1/v2c).

Why it matters: SNMP v1/v2c transmits community strings (passwords) in cleartext and has no encryption. An attacker sniffing the network captures the community string and gains read or read-write access to the device's management data — including routing tables, interface configs, and system information. Only SNMPv3 with authentication and encryption is considered secure.
References: CIS Benchmark 3.6

NET-010 Default SNMP community strings removed CRITICAL

Checks for public and private community strings in snmpd.conf.

Why it matters: "public" and "private" are the default SNMP community strings that attackers try first. Automated scanners and worms target these defaults. With rwcommunity private, an attacker can modify device configurations remotely. This is one of the most common and easily exploited misconfigurations in network devices.
References: CVE-2002-0012, CVE-2002-0013

NET-011 SNMP removed if unused LOW

Verifies snmpd is not installed or not running when not needed.

Why it matters: Unnecessary services increase attack surface. SNMP has a history of vulnerabilities and, if not actively used for monitoring, should be removed entirely rather than just disabled. Removing the package eliminates the risk of accidental re-enabling.

SVC — Services & Processes

Audits running services and daemons — identifies insecure protocols, validates time synchronization, checks critical security services, and reviews mail server configuration.

SVC-001 No insecure services running CRITICAL

Detects telnet, rsh, rlogin, xinetd, tftp, and vsftpd services.

Why it matters: These protocols transmit data (including credentials) in cleartext. Telnet, rsh, and rlogin are legacy remote access protocols that have been superseded by SSH for decades. Any of these running on a server is an immediate, exploitable vulnerability that allows credential interception.
References: CIS Benchmark 2.2.x, DISA STIG V-72239

SVC-002 SSH ciphers and timeouts hardened HIGH

Checks for weak ciphers (3DES, Blowfish, Arcfour), weak MACs (MD5, SHA1-96), and idle session timeouts.

Why it matters: Weak ciphers can be broken by well-resourced attackers, compromising SSH session confidentiality. Idle timeouts prevent abandoned sessions from being hijacked. An SSH session left open indefinitely is an invitation for anyone with physical or lateral access to use it.

SVC-003 NTP/chrony synchronized MEDIUM

Verifies system clock is NTP synchronized via timedatectl.

Why it matters: Accurate time is essential for log correlation, certificate validation, Kerberos authentication, and forensic investigation. A skewed clock can cause TLS certificates to appear invalid, authentication to fail, and incident timelines to be unreconstructable. Attackers can exploit time skew to replay expired tokens.

SVC-004 NTP daemon not running as root LOW

Checks that chrony/ntpd runs as a dedicated user, not root.

Why it matters: If the NTP daemon has a vulnerability, running as root gives the attacker full system access. Running as a dedicated user (_chrony) limits the blast radius of a compromise to the NTP service only. This follows the principle of least privilege.

SVC-005 NTS enabled LOW

Checks chrony for Network Time Security (NTS) authentication.

Why it matters: Standard NTP is unauthenticated — a network attacker (MITM) can feed false time to the server. NTS adds cryptographic authentication to NTP, preventing time manipulation attacks that could be used to replay expired credentials or invalidate security certificates.

SVC-006 Time sources are trusted LOW

Verifies NTP sources are reachable and selected via chronyc sources.

Why it matters: Unreachable or untrusted NTP sources mean the system clock may drift without detection. An attacker who controls time sources can manipulate the server's notion of time, affecting logging, certificate validation, and scheduled security tasks.

SVC-007 Critical services active HIGH

Ensures sshd and intrusion prevention (fail2ban/crowdsec) are running.

Why it matters: Without fail2ban or CrowdSec, SSH brute-force attacks proceed unchecked — attackers can attempt thousands of passwords per minute. These tools automatically ban offending IPs after failed attempts, dramatically reducing the effectiveness of automated attacks.

SVC-008 No unnecessary root processes MEDIUM

Lists processes running as UID 0 that are not in the expected set (systemd, sshd, cron, etc.).

Why it matters: Every process running as root is a potential privilege escalation target. If an unexpected application runs as root and has a vulnerability, the attacker immediately gets full system access. Services should run with the minimum privileges required.

SVC-009 MTA configured as local-only HIGH

Verifies Postfix inet_interfaces = loopback-only.

Why it matters: A mail server listening on external interfaces can be exploited for spam relay, phishing campaigns, and as a pivot point for lateral movement. Most servers only need local mail delivery (cron notifications, system alerts) and should not accept mail from the network.

SVC-010 MTA is not an open relay CRITICAL

Checks Postfix mynetworks does not include 0.0.0.0/0.

Why it matters: An open relay allows anyone on the internet to send email through your server. This will result in your server being blacklisted, used for spam/phishing campaigns, and potentially held legally responsible for the content relayed. Open relays are actively scanned for by spammers.

SVC-011 Root mail forwarded LOW

Verifies root mail alias in /etc/aliases forwards to a monitored account.

Why it matters: System alerts, cron job errors, and security notifications are sent to root by default. If root mail is not forwarded, these critical alerts go unread, and security incidents or system failures are missed.

SVC-012 No desktop environment installed MEDIUM

Detects GDM, LightDM, SDDM, or graphical.target as default.

Why it matters: Desktop environments install hundreds of packages (browsers, media players, office suites) that massively increase the attack surface. GUI frameworks (X11, Wayland) have their own vulnerability history. Servers should run in multi-user (text) mode only.

SVC-013 Automount disabled MEDIUM

Checks that autofs is not running.

Why it matters: Autofs automatically mounts filesystems when accessed, which can be exploited to mount malicious NFS shares or USB devices. Disabling automount forces manual, auditable mounting of external filesystems.

FS — Filesystem & Permissions

Validates filesystem permissions, SUID/SGID binaries, mount options, and partition layout to prevent privilege escalation and unauthorized access.

FS-001 No unnecessary SUID/SGID files HIGH

Finds SUID/SGID binaries not in the known-safe list (sudo, passwd, mount, etc.).

Why it matters: SUID binaries run with the file owner's privileges (usually root) regardless of who executes them. A vulnerability in any SUID binary is a direct path to root. Attackers specifically search for unusual SUID files as privilege escalation targets. Every SUID binary not strictly needed should have its bit removed.
References: CIS Benchmark 6.1.13–6.1.14

FS-002 No world-writable files outside /tmp HIGH

Searches the filesystem for files with world-write permission (mode 0002) outside temporary directories.

Why it matters: World-writable files can be modified by any user. If a script or configuration file is world-writable, an attacker with low-privilege access can inject malicious code that executes with higher privileges. This is a classic privilege escalation technique.
References: CIS Benchmark 6.1.10

FS-003 Sticky bit on /tmp and /var/tmp HIGH

Verifies the sticky bit is set on world-writable directories.

Why it matters: Without the sticky bit, any user can delete or rename files created by other users in a shared directory. In /tmp, this enables symlink attacks — an attacker replaces a temporary file with a symlink to a critical system file, causing a privileged process to overwrite or corrupt it.
References: CIS Benchmark 1.1.22

FS-004 Sensitive partitions have restrictive mount options MEDIUM

Validates nodev, nosuid, noexec on /tmp, /var/tmp, /home.

Why it matters: noexec prevents execution of binaries from the partition, blocking attackers from running downloaded malware. nosuid prevents SUID elevation from user-writable areas. nodev prevents creation of device files that could access hardware directly. Together, these mount options significantly limit post-exploitation capabilities.

FS-005 /dev/shm mounted with nodev,nosuid,noexec MEDIUM

Validates shared memory tmpfs mount options.

Why it matters: /dev/shm is a world-writable tmpfs commonly used by attackers to stage and execute malware because it resides in RAM and leaves no disk trace. Adding noexec prevents direct execution from shared memory, forcing attackers to use more detectable techniques.

FS-006 Home directories not world-readable MEDIUM

Checks /home/* for world-readable/writable permissions.

Why it matters: World-readable home directories expose SSH keys, shell history, configuration files, and potentially credentials to all users. A low-privilege attacker can harvest private keys, API tokens, and database passwords from other users' home directories.

FS-007 No orphaned files LOW

Finds files without a valid owner or group in /usr, /etc, /var.

Why it matters: Orphaned files indicate deleted user accounts whose files remain. These files could contain sensitive data or be inherited by a new user assigned the same UID, inadvertently granting access to another user's files.

FS-008 Separate partitions for key directories MEDIUM

Verifies /tmp, /var, /var/log, /var/log/audit, /var/tmp, /home are separate mount points.

Why it matters: Separate partitions prevent a disk-filling attack in one area (e.g., log flooding in /var/log) from consuming all space and crashing the entire system. They also enable per-partition mount options (noexec, nosuid) and quotas for fine-grained security control.
References: CIS Benchmark 1.1.x

FS-009 /tmp on separate partition or tmpfs MEDIUM

Checks if /tmp is a dedicated mount point.

Why it matters: A separate /tmp partition allows enforcing noexec,nosuid,nodev and prevents temporary file abuse from affecting the root filesystem. Using tmpfs also ensures temporary files are cleared on reboot.

FS-010 /var/tmp with nodev,nosuid,noexec MEDIUM

Validates /var/tmp mount options.

Why it matters: Unlike /tmp, /var/tmp persists across reboots. Attackers use it to stash tools and maintain persistence. Restrictive mount options limit what can be done from this location.

FS-011 systemd tmp.mount enabled LOW

Checks if tmp.mount is active when /tmp is not a separate partition.

Why it matters: tmp.mount creates a tmpfs for /tmp, ensuring temporary files are RAM-backed, size-limited, and cleared on reboot — even without a dedicated partition.

FS-012 Temporary file cleanup configured LOW

Verifies systemd-tmpfiles-clean.timer is active.

Why it matters: Without periodic cleanup, temporary directories accumulate files indefinitely. This wastes disk space and allows attackers to maintain staged tools or data in temporary locations for extended periods.

LOG — Logging & Auditing

Validates that system logging, audit trails, and file integrity monitoring are properly configured. Logging is the foundation of incident detection and forensic investigation.

LOG-001 Syslog/journald active CRITICAL

Verifies rsyslog, syslog-ng, or systemd-journald is running.

Why it matters: Without logging, there is no record of what happened on the system. Security incidents go undetected, forensic investigation is impossible, and compliance requirements are violated. An attacker's first action is often to disable logging — if it's already off, they've already won.
References: CIS Benchmark 4.2.1, DISA STIG V-72077

LOG-002 auditd installed and running HIGH

Checks the auditd service is active.

Why it matters: The Linux Audit System provides detailed logging of system calls, file access, and security events beyond what syslog captures. It's required by PCI DSS, HIPAA, and most compliance frameworks. Without auditd, you cannot track who accessed sensitive files or executed privileged commands.
References: CIS Benchmark 4.1.1, DISA STIG V-72081

LOG-003 Audit rules for sensitive files HIGH

Verifies audit rules watch /etc/passwd, /etc/shadow, and /etc/sudoers.

Why it matters: These files control authentication and authorization. Audit rules create an alert trail when they are read or modified. Without these rules, an attacker can add users, change passwords, or grant sudo access without leaving audit evidence.

LOG-004 Log rotation configured MEDIUM

Checks /etc/logrotate.conf exists.

Why it matters: Without log rotation, logs grow until they fill the disk — causing service outages and losing the oldest (potentially most important) log entries. Rotation ensures logs are compressed, archived, and old entries are preserved for the required retention period.

LOG-005 Log files not world-readable MEDIUM

Verifies files in /var/log are not world-readable.

Why it matters: Logs can contain sensitive information: IP addresses, usernames, application errors with stack traces, and sometimes credentials. World-readable logs allow low-privilege users to harvest this intelligence.

LOG-006 AIDE or file integrity tool installed HIGH

Detects AIDE, Tripwire, Samhain, or OSSEC.

Why it matters: File integrity monitoring (FIM) detects unauthorized changes to system binaries, libraries, and configuration files. Without FIM, a rootkit that replaces /usr/bin/ssh with a backdoored version goes undetected. FIM is required by PCI DSS Requirement 11.5 and most security frameworks.
References: CIS Benchmark 1.3.1

LOG-007 AIDE database initialized MEDIUM

Checks for /var/lib/aide/aide.db.

Why it matters: AIDE without an initialized database does nothing. The baseline database must be created on a known-good system so that future comparisons detect changes accurately.

LOG-008 AIDE checks scheduled MEDIUM

Looks for AIDE cron jobs in /etc/cron.daily or /etc/crontab.

Why it matters: AIDE only detects changes when it runs. Without scheduled checks, unauthorized modifications accumulate undetected. Daily checks ensure changes are discovered within 24 hours.

LOG-009 AIDE covers critical paths MEDIUM

Verifies AIDE config monitors /bin, /sbin, /lib, /etc, /boot.

Why it matters: If AIDE doesn't monitor critical system directories, an attacker can modify binaries and libraries without triggering alerts. The monitored paths should include all locations where executables and configuration files reside.

PKG — Packages & Updates

Ensures the system is patched against known vulnerabilities and uses secure package repositories.

PKG-001 No pending security updates HIGH

Checks apt or dnf for pending security patches.

Why it matters: Unpatched vulnerabilities are the primary attack vector for server compromise. Exploit code for known CVEs is often publicly available within days of disclosure. Every day a security update is delayed increases the risk of exploitation. Automated scanning tools specifically target known, unpatched vulnerabilities.
References: CIS Benchmark 1.9

PKG-002 Package repositories use HTTPS MEDIUM

Validates apt sources and yum repos use https://.

Why it matters: HTTP repositories are vulnerable to MITM attacks — a network attacker can serve malicious packages that appear legitimate. While GPG signatures provide package integrity, HTTPS adds transport-layer confidentiality and makes interception significantly harder.

PKG-003 Kernel is up to date HIGH

Checks for /var/run/reboot-required indicating a pending kernel update.

Why it matters: Kernel vulnerabilities (e.g., Dirty COW, StackRot, nf_tables exploits) allow local privilege escalation from any user to root. A kernel update that isn't applied until reboot leaves the system running vulnerable code despite the patch being available.

PKG-004 Automatic security updates enabled MEDIUM

Verifies unattended-upgrades or dnf-automatic is active.

Why it matters: Manual patching is unreliable — critical updates get delayed by holidays, staff turnover, or oversight. Automatic security updates ensure patches are applied within hours of release, dramatically reducing the exposure window for known vulnerabilities.

HARD — Kernel Hardening

Validates kernel security parameters, module restrictions, and exploit mitigations that harden the system against common attack techniques.

HARD-001 Login banner configured LOW

Checks /etc/issue and /etc/issue.net have warning content.

Why it matters: Legal banners establish the legal basis for prosecution of unauthorized access in many jurisdictions. Without a warning banner, courts may find that the attacker had no notice that access was restricted, weakening legal action.

HARD-002 Core dumps disabled MEDIUM

Verifies core dumps are disabled via kernel configuration or limits.conf.

Why it matters: Core dumps contain the complete memory contents of a crashed process — including passwords, encryption keys, session tokens, and private data. If core dumps are written to world-readable locations, any user can harvest this sensitive information.

HARD-003 ASLR enabled HIGH

Checks kernel.randomize_va_space = 2 (full randomization).

Why it matters: Address Space Layout Randomization (ASLR) randomizes memory addresses of processes, making exploit techniques like return-oriented programming (ROP) and buffer overflow attacks significantly harder. Disabling ASLR makes every memory corruption vulnerability trivially exploitable.
References: CIS Benchmark 1.6.2

HARD-004 dmesg restricted MEDIUM

Verifies kernel.dmesg_restrict = 1.

Why it matters: Kernel messages (dmesg) contain hardware addresses, loaded modules, and system configuration details that help attackers craft targeted exploits. Restricting dmesg to root prevents information leakage to unprivileged users.

HARD-005 ptrace restricted MEDIUM

Checks kernel.yama.ptrace_scope ≥ 1.

Why it matters: ptrace allows a process to inspect and modify another process's memory. Without restrictions, any user can attach to other users' processes to steal credentials, inject code, or bypass security controls. Yama ptrace scope limits this to parent processes only.

HARD-006 /proc hardened MEDIUM

Verifies /proc is mounted with hidepid option.

Why it matters: Without hidepid, any user can see every process running on the system — including command-line arguments that may contain passwords, API keys, or other secrets passed as arguments. hidepid=2 hides processes owned by other users.

HARD-007 Swap encrypted or absent LOW

Checks if swap uses dm-crypt/LUKS encryption.

Why it matters: The kernel swaps memory pages to disk when RAM is low. Unencrypted swap can contain passwords, encryption keys, and sensitive data from any process. An attacker with physical access or a disk image can extract this data from swap.

HARD-008 Unused filesystem modules blacklisted MEDIUM

Verifies cramfs, freevxfs, hfs, hfsplus, jffs2, squashfs, udf are blocked.

Why it matters: Filesystem drivers parse complex data structures from potentially untrusted media. Vulnerabilities in rarely-used filesystem modules (cramfs, hfs, etc.) are common and can be triggered by inserting a malicious USB device or mounting a crafted disk image. Blacklisting prevents the kernel from loading these attack surfaces.

HARD-009 USB storage disabled MEDIUM

Checks usb-storage module is blacklisted.

Why it matters: USB storage devices are the primary vector for offline data exfiltration and malware delivery (BadUSB, Rubber Ducky). Blocking the usb-storage module prevents unauthorized data transfer via USB drives on servers that don't need removable media.

HARD-010 Wireless modules disabled LOW

Checks for wireless interfaces in /sys/class/net/.

Why it matters: Wireless interfaces on servers create an unmonitored network attack surface. An attacker within radio range can attempt to connect, bypassing all network-based firewalls and IDS. Servers should have no wireless capability.

HARD-011 Firewire/Thunderbolt DMA disabled MEDIUM

Verifies firewire-core and thunderbolt modules are blacklisted.

Why it matters: FireWire and Thunderbolt provide Direct Memory Access (DMA), allowing connected devices to read and write system RAM directly — bypassing all software security controls including full disk encryption. A physical attacker can extract encryption keys, inject rootkits, and read arbitrary memory using a DMA attack device.

HARD-012 Bluetooth disabled LOW

Checks bluetooth service is not active.

Why it matters: Bluetooth has a history of vulnerabilities (BlueBorne, BleedingTooth, KNOB) that allow remote code execution without user interaction. On servers, Bluetooth serves no purpose and adds unnecessary attack surface.

BOOT — Boot Security & MAC

Validates bootloader protection, Secure Boot, and mandatory access control (SELinux/AppArmor) that protect the system during startup and enforce security policies at runtime.

BOOT-001 GRUB password set HIGH

Checks grub.cfg for password_pbkdf2 or set superusers.

Why it matters: Without a GRUB password, anyone with physical access can boot into single-user mode (root shell without authentication), edit kernel parameters to bypass security controls, or boot from a USB device to access the filesystem. A GRUB password prevents unauthorized boot modifications.

BOOT-002 Bootloader config permissions HIGH

Verifies grub.cfg is mode 0600 owned by root.

Why it matters: If grub.cfg is readable, users can see the GRUB password hash and attempt offline cracking. If writable, they can modify boot parameters to gain root access on next reboot.

BOOT-003 Secure Boot enabled MEDIUM

Checks Secure Boot status via mokutil or EFI variables.

Why it matters: Secure Boot ensures only signed bootloaders and kernels are loaded, preventing bootkits — malware that loads before the OS and is invisible to all security tools. Without Secure Boot, an attacker with root access can install persistent bootloader-level malware that survives OS reinstallation.

BOOT-004 Single-user mode requires authentication HIGH

Verifies root has a password set in /etc/shadow.

Why it matters: If root has no password, single-user/rescue mode provides an unauthenticated root shell. An attacker with physical access (or GRUB access) can drop into a root shell and modify any system configuration.

BOOT-005 SELinux or AppArmor installed HIGH

Detects AppArmor or SELinux availability.

Why it matters: Mandatory Access Control (MAC) systems enforce security policies beyond traditional Unix permissions. Even if an attacker gains root through a vulnerability, MAC policies can prevent them from accessing sensitive files, binding to ports, or executing certain binaries. MAC is a critical layer of defense-in-depth.
References: CIS Benchmark 1.7.1, DISA STIG V-71989

BOOT-006 MAC in enforcing mode HIGH

Checks SELinux is Enforcing or AppArmor has profiles in enforce mode.

Why it matters: A MAC system in permissive mode logs violations but doesn't block them — it provides zero protection. Enforcing mode is required for MAC to actually prevent unauthorized actions. Permissive mode is only appropriate during policy development.

BOOT-007 No unconfined processes MEDIUM

Runs aa-unconfined to find processes without MAC profiles.

Why it matters: Unconfined processes run without MAC restrictions, negating the protection for those specific services. Critical services (web servers, databases) should have profiles. An unconfined service is the weak link in an otherwise hardened system.

BOOT-008 No MAC denials in logs LOW

Checks dmesg for AppArmor DENIED or SELinux AVC denial messages.

Why it matters: MAC denials indicate either misconfigured policies (legitimate actions being blocked) or actual security violations. Unreviewed denials may mean services are malfunctioning or that an active attack is being partially blocked. Either case requires investigation.

CRON — Scheduled Jobs

Audits cron and at job permissions, reviews scheduled tasks for suspicious activity, and ensures access control uses whitelists.

CRON-001 Cron daemon enabled LOW

Verifies cron service is running.

Why it matters: Many security tasks (log rotation, AIDE scans, backup jobs, certificate renewal) depend on cron. If cron is not running, these critical maintenance tasks silently fail.

CRON-002 /etc/crontab permissions MEDIUM

Validates /etc/crontab is mode 0600.

Why it matters: If /etc/crontab is readable, attackers learn the schedule of security tasks (when AIDE runs, when backups happen) and can time their activities to avoid detection. If writable, they can add jobs that execute as root.

CRON-003 Cron directories permissions MEDIUM

Checks /etc/cron.{hourly,daily,weekly,monthly} are mode 0700.

Why it matters: Cron directories with loose permissions allow unauthorized users to place scripts that execute with root privileges on a schedule. This is a common persistence mechanism for attackers.

CRON-004 cron.allow exists, cron.deny removed MEDIUM

Verifies whitelist approach for cron access control.

Why it matters: A deny-list approach (cron.deny) allows all users except those explicitly denied. A whitelist approach (cron.allow) denies all users except those explicitly permitted. Whitelisting is more secure because new users are denied by default.

CRON-005 at.allow exists, at.deny removed MEDIUM

Same whitelist verification for the at scheduler.

Why it matters: The at command schedules one-time jobs. Without access control, any user can schedule commands — potentially for malicious purposes like time-bomb attacks or delayed data exfiltration.

CRON-006 No suspicious cron jobs HIGH

Scans cron jobs for curl, wget, nc, bash -i, and similar patterns.

Why it matters: Attackers use cron jobs to maintain persistence — a cron job that downloads and executes a payload every hour ensures the attacker regains access even if their initial backdoor is removed. Network-fetching commands in cron jobs are a strong indicator of compromise or unauthorized activity.

CRON-007 User crontabs reviewed LOW

Lists users with personal crontabs in /var/spool/cron/.

Why it matters: User crontabs are often overlooked during security reviews. An attacker who compromises a user account can add a crontab for persistence without modifying system cron files, making detection harder.

CRYPTO — TLS/SSL & Cryptography

Validates cryptographic configuration: certificates, TLS versions, cipher suites, private key protection, and hash algorithms.

CRYPTO-001 System crypto policy is not LEGACY HIGH

Checks RHEL/Fedora system-wide crypto policy via update-crypto-policies.

Why it matters: The LEGACY crypto policy enables deprecated and weak algorithms (RC4, DES, SHA1) system-wide for all applications. This silently weakens every TLS connection, SSH session, and cryptographic operation on the server.

CRYPTO-002 No expired or expiring certificates HIGH

Scans PEM/CRT files in /etc/ssl/certs and /etc/pki/tls/certs for expiration.

Why it matters: Expired certificates cause service outages (clients reject expired certs) and security degradation (users learn to click through warnings). Certificates expiring within 30 days need immediate renewal planning to prevent both availability and security incidents.

CRYPTO-003 No self-signed certificates MEDIUM

Detects snakeoil and localhost certificates.

Why it matters: Self-signed certificates provide encryption but no authentication — clients cannot verify the server's identity. This makes the connection vulnerable to MITM attacks. In production, certificates should be issued by a trusted CA.

CRYPTO-004 TLS 1.0 and 1.1 disabled HIGH

Checks OpenSSL MinProtocol in /etc/ssl/openssl.cnf.

Why it matters: TLS 1.0 and 1.1 have known vulnerabilities (BEAST, POODLE, Lucky13) and have been deprecated by RFC 8996. All major browsers reject them. Continuing to support these versions exposes connections to downgrade attacks and known cryptographic weaknesses.

CRYPTO-005 No weak cipher suites HIGH

Lists OpenSSL ciphers and flags RC4, DES, 3DES, NULL, EXPORT, and anonymous suites.

Why it matters: Weak ciphers can be broken in real-time (NULL provides zero encryption, EXPORT uses intentionally weakened 40/56-bit keys, RC4 has statistical biases). An attacker can force a downgrade to a weak cipher via a MITM position and decrypt all traffic.

CRYPTO-006 Certificate chains complete MEDIUM

Verifies CA certificates bundle is installed.

Why it matters: Without the CA certificates bundle, the system cannot validate TLS certificates of remote services — package repository connections, API calls, and HTTPS requests cannot be verified. This may lead applications to disable certificate verification entirely, creating MITM vulnerability.

CRYPTO-007 Private key file permissions CRITICAL

Checks key files in /etc/ssl/private and /etc/pki/tls/private are mode ≤ 0600.

Why it matters: Private keys are the foundation of TLS security. A leaked private key allows an attacker to impersonate the server, decrypt all past and future traffic (if not using forward secrecy), and issue fraudulent certificates. Private keys must be readable only by root and the service that uses them.
References: CIS Benchmark 1.8

CRYPTO-008 FIPS mode enabled MEDIUM

Checks /proc/sys/crypto/fips_enabled.

Why it matters: FIPS 140-2/140-3 compliance is required by US federal agencies and many regulated industries. FIPS mode restricts the system to validated cryptographic algorithms and implementations. If your compliance framework requires FIPS, this check ensures it's active.

CRYPTO-009 No MD5/SHA1 in authentication HIGH

Scans /etc/shadow for $1$ (MD5) password hashes.

Why it matters: MD5 password hashes can be cracked at rates exceeding 10 billion guesses per second on modern GPUs. A password hashed with MD5 provides essentially no protection against offline cracking. Modern systems should use SHA-512 ($6$) or yescrypt which are designed to be computationally expensive.

SEC — Secrets & Credentials

Detects exposed credentials in environment files, shell history, and configuration files with insecure permissions.

SEC-001 No secrets in environment variables HIGH

Scans /etc/environment and /etc/profile.d/ for PASSWORD=, API_KEY=, SECRET=, etc.

Why it matters: Environment variables set in system-wide profiles are visible to all users via /proc/<pid>/environ. Secrets stored this way are trivially extractable. Use a secrets manager (Vault, AWS SSM) or file-based secrets with restrictive permissions instead.

SEC-002 No passwords in shell history HIGH

Checks .bash_history and .zsh_history for password-like commands.

Why it matters: Commands like mysql -u root -pMyPassword are recorded in shell history in cleartext. Anyone who gains access to the user's account (or their home directory) can read these credentials. History files should be regularly cleared and HISTCONTROL=ignorespace set so sensitive commands prefixed with a space are not recorded.

SEC-003 No credentials in world-readable files CRITICAL

Checks /etc/shadow, /etc/gshadow, /etc/security/opasswd permissions.

Why it matters: These files contain password hashes and authentication data. If world-readable, any user can copy the hashes and perform offline cracking at unlimited speed. A world-readable shadow file is equivalent to having no password protection at all.

SEC-004 Credential file permissions correct HIGH

Verifies .pgpass, .my.cnf, .netrc, .aws/credentials are mode ≤ 0600.

Why it matters: These files contain database passwords, FTP credentials, and cloud access keys in cleartext. If readable by other users, a single compromised account can cascade to database access, AWS account compromise, and lateral movement across the infrastructure.

CTR — Container Security

Audits Docker/Podman configuration, running containers, and container runtime security settings.

CTR-001 Docker/Podman detected INFO

Detects if a container runtime is installed.

Why it matters: Informational check that triggers the remaining container security checks. If no container runtime is installed, all CTR checks are automatically skipped.

CTR-002 Docker daemon configuration MEDIUM

Verifies /etc/docker/daemon.json exists.

Why it matters: The daemon configuration file controls Docker's security settings (TLS, logging, userns-remap, icc). Without it, Docker runs with default settings that are optimized for convenience rather than security.

CTR-003 Docker socket permissions HIGH

Checks /var/run/docker.sock is not world-accessible.

Why it matters: The Docker socket is equivalent to root access. Anyone who can write to the Docker socket can create a privileged container, mount the host filesystem, and gain full root access. The socket should be accessible only to root and the docker group.
References: CIS Docker Benchmark 3.15

CTR-004 No containers running as root HIGH

Inspects running containers for User: "" or User: "0".

Why it matters: A container running as root has UID 0 — if the container escapes (via a kernel vulnerability or misconfiguration), the attacker has root on the host. Running containers as non-root users limits the impact of container breakout.
References: CIS Docker Benchmark 4.1

CTR-005 No privileged containers CRITICAL

Checks HostConfig.Privileged flag for all running containers.

Why it matters: A privileged container has full access to the host's devices, capabilities, and kernel — it is effectively root on the host with no isolation. Container escape from a privileged container is trivial and well-documented. Privileged mode should never be used in production; use specific capabilities instead.
References: CIS Docker Benchmark 5.4

CTR-006 Container resource limits MEDIUM

Verifies memory and CPU limits are set for running containers.

Why it matters: Containers without resource limits can consume all host resources (CPU, memory), causing denial of service to other containers and the host itself. A compromised container performing crypto-mining or a fork bomb will affect all co-located services.

CTR-007 Docker content trust enabled MEDIUM

Checks DOCKER_CONTENT_TRUST=1 environment variable.

Why it matters: Content trust ensures only signed images can be pulled and run. Without it, a compromised registry or MITM attack can serve malicious images that appear legitimate. Content trust provides cryptographic verification of image integrity and publisher identity.

CTR-008 Inter-container communication restricted MEDIUM

Checks "icc": false in daemon.json.

Why it matters: By default, Docker allows all containers on the default bridge network to communicate freely. If one container is compromised, the attacker can reach all other containers directly. Disabling ICC forces containers to use explicit links or user-defined networks, implementing network segmentation.

CTR-009 Read-only root filesystem LOW

Checks HostConfig.ReadonlyRootfs for running containers.

Why it matters: A read-only root filesystem prevents an attacker from modifying container binaries, installing tools, or establishing persistence within the container. Applications should write only to explicitly mounted volumes.

CTR-010 Docker logging driver configured LOW

Verifies logging driver is not none.

Why it matters: Without logging, container activity is invisible. Security incidents within containers cannot be investigated, and compliance requirements for log retention cannot be met.

CTR-011 Images from trusted registries MEDIUM

Lists container images and flags those from unknown registries.

Why it matters: Images from untrusted registries may contain malware, backdoors, crypto-miners, or vulnerabilities. Supply chain attacks via malicious container images are increasingly common. Only images from vetted registries should be used.

RLIM — Resource Limits

Monitors system resource limits and disk usage to prevent denial of service and resource exhaustion.

RLIM-001 Open files limit LOW

Checks fs.file-max ≥ 65536.

Why it matters: A low open files limit can cause services to fail under load when they cannot open new sockets, files, or connections. This is primarily an availability concern but can impact security tools that need many file descriptors.

RLIM-002 Max user processes limit MEDIUM

Verifies nproc is configured in /etc/security/limits.conf.

Why it matters: Without process limits, a single user can execute a fork bomb (:(){ :|:& };:) that creates processes exponentially until the system crashes. Process limits contain the blast radius to a single user session.

RLIM-003 Stack size limits LOW

Checks stack size configuration in limits.conf.

Why it matters: Excessive stack sizes waste memory and can facilitate stack-based buffer overflow attacks. Reasonable limits help contain both resource consumption and exploit capabilities.

RLIM-004 No wildcard unlimited entries MEDIUM

Scans limits.conf for * ... unlimited entries.

Why it matters: Wildcard unlimited entries remove resource restrictions for all users, negating all other limit configurations. This opens the door to resource exhaustion attacks and fork bombs from any user account.

RLIM-005 Root filesystem below 85% HIGH

Checks disk usage of /.

Why it matters: A full root filesystem causes system-wide failures: logging stops (hiding attacker activity), package updates fail (leaving vulnerabilities unpatched), services crash (causing outages), and the system may become unbootable. Maintaining free space is both an availability and security requirement.

RLIM-006 Key directories have space MEDIUM

Checks /var, /var/log, and /tmp usage.

Why it matters: A full /var/log silently stops logging — the perfect cover for an attack. A full /tmp breaks applications that depend on temporary files. Monitoring individual directory usage catches problems before they cascade.

RLIM-007 Inode usage not exhausted HIGH

Runs df -i and checks for usage above 85%.

Why it matters: Inode exhaustion is more insidious than disk space exhaustion — the filesystem still shows free space, but no new files can be created. This breaks logging, application operation, and package management. Attackers can cause inode exhaustion by creating millions of small files.

NFS — Network Filesystems

Audits NFS exports, Samba shares, and related services to prevent unauthorized file access across the network.

NFS-001 NFS exports reviewed HIGH

Checks /etc/exports for world exports (*) and no_root_squash.

Why it matters: World-exported NFS shares are accessible from any host on the network. no_root_squash allows the remote root user to have root privileges on the NFS share, enabling them to create SUID binaries, modify sensitive files, and escalate privileges on the NFS server.

NFS-002 NFSv3 disabled MEDIUM

Checks vers3=no in /etc/nfs.conf.

Why it matters: NFSv3 relies on IP-based authentication, which can be spoofed. NFSv4 supports Kerberos authentication and has better security features. NFSv3 should be disabled when NFSv4 is available.

NFS-003 Samba config reviewed MEDIUM

Checks /etc/samba/smb.conf for guest ok = yes.

Why it matters: Guest access to Samba shares allows unauthenticated access to files. This can expose sensitive data and provide a staging area for attackers. WannaCry and similar worms exploit open SMB shares for propagation.

NFS-004 rpcbind disabled if unused MEDIUM

Checks if rpcbind runs without an active NFS server.

Why it matters: rpcbind maps RPC services to ports and has a history of vulnerabilities. If NFS is not in use, rpcbind is unnecessary attack surface that should be disabled.

MAL — Rootkits & Malware

Verifies rootkit detection tools and antimalware solutions are installed and scheduled.

MAL-001 Rootkit scanner installed MEDIUM

Detects rkhunter or chkrootkit.

Why it matters: Rootkits hide attacker presence by modifying system binaries and kernel modules. Without a rootkit scanner, a compromised server can remain undetected indefinitely. rkhunter checks file hashes, hidden processes, and known rootkit signatures.

MAL-002 Rootkit scans scheduled MEDIUM

Looks for rootkit scanner cron jobs.

Why it matters: A rootkit scanner that isn't run regularly provides no protection. Scheduled scans ensure rootkits are detected within the scan interval, limiting the duration of an undetected compromise.

MAL-003 ClamAV installed LOW

Detects clamscan or clamdscan.

Why it matters: Servers that handle file uploads or email are vectors for malware distribution. ClamAV can scan uploaded files and email attachments for known malware, preventing the server from becoming a distribution point.

MAL-004 Antimalware definitions updated MEDIUM

Checks clamav-freshclam service or rkhunter version.

Why it matters: Antimalware tools with outdated definitions cannot detect recent threats. New malware variants are released daily — definitions more than a week old miss a significant portion of current threats.

BAK — Backups

Validates that backup solutions are configured, encrypted, secured, and stored off-site — the last line of defense against data loss and ransomware.

BAK-001 Backup schedule exists HIGH

Detects backup tools (restic, borg, duplicity) and cron/timer schedules.

Why it matters: Without backups, any data loss event — ransomware, hardware failure, accidental deletion, or attacker sabotage — is permanent. Backups are the ultimate recovery mechanism. A backup tool without a schedule means backups are not happening automatically.

BAK-002 Backups are encrypted MEDIUM

Verifies backup tool supports encryption (borg, restic encrypt by default).

Why it matters: Unencrypted backups contain all the server's sensitive data in a portable, easily accessible format. If an attacker gains access to the backup storage, they get a complete copy of every database, configuration file, and secret — potentially across multiple time periods.

BAK-003 Backup files not world-readable HIGH

Checks permissions on common backup directories.

Why it matters: World-readable backup directories allow any user to access backup archives, which may contain sensitive data from restricted areas of the filesystem. Backup directories should be readable only by root and the backup service account.

BAK-004 Off-site backup exists MEDIUM

Warns to verify backup repository is on a remote host.

Why it matters: Backups stored only on the same server are destroyed by the same event that destroys the server — hardware failure, fire, ransomware encryption, or attacker sabotage. Off-site backups (remote server, S3, etc.) ensure recovery is possible even if the primary server is completely lost. This is the 3-2-1 backup rule: 3 copies, 2 media types, 1 off-site.
↑