CIS Controls in Config Files: Core Dumps, cron, Modules, sysctl and TLS

The CIS Benchmarks are consensus hardening checklists: a few hundred numbered controls per distribution, each with an audit (how to prove it) and a remediation (how to fix it). A scanner such as CIS-CAT or OpenSCAP walks that list on your host and marks each control pass or fail.

For the controls in this lesson the audit reads configuration files, because the file is what survives a reboot. A value you set live with sysctl -w and never wrote down is gone at the next boot, and the next scan fails it again. So every control here has the same two halves the hardening guide taught: the persistent setting (one line in the right file) and the effective value (what the running system does now). Write the first, then prove the second with the tool that reads it back.

The five families below come from the CIS Ubuntu 22.04 benchmark and its STIG neighbours: core dumps, cron access, unused kernel modules, network kernel parameters and the system-wide TLS policy. Each step shows where the setting lives, the exact line, and how to check it.

A core dump is a copy of a crashed process's memory written to disk. That memory can hold whatever the process was handling: private keys, session tokens, password hashes read from /etc/shadow. CIS closes it in three places, because three different mechanisms produce dumps:

• *` hard core 0** in /etc/security/limits.conf (or a .conf` file in `/etc/security/limits.d/`, which `pam_limits` also reads). A hard* limit is a ceiling the user can't raise, so ulimit -c unlimited fails. Some scanners only read limits.conf itself, so when the benchmark names that file, put the line there.
• `fs.suid_dumpable = 0` in a file under /etc/sysctl.d/. It decides whether a process that changed privilege (a setuid program such as passwd) may dump at all: 0 never, 1 always (debugging only), 2 only as a root-readable file.
• `Storage=none` in the [Coredump] section of /etc/systemd/coredump.conf, for hosts where systemd-coredump catches crashes and stores them under /var/lib/systemd/coredump. ProcessSizeMax=0 stops it from even processing one.

Scheduled jobs are a favourite persistence spot, so CIS limits who may create them and protects the files that define them. Access is decided by two pairs of files, read the same way by crontab and by at:

• If `/etc/cron.allow` exists, only the users listed in it may use crontab. cron.deny is then ignored entirely, so a user listed in both is allowed: the allow file wins.
• If only `/etc/cron.deny` exists, everyone may use crontab except the users it lists. That is a blocklist, and every account created later is allowed by default.
• If neither exists, it's a build-time default: Debian and Ubuntu allow everyone, some builds allow only root. (RHEL ships an empty cron.deny, which also allows everyone.)

at.allow and at.deny work the same way for at, except that with neither file only root may use it. Root can always use both tools. CIS wants the allow-list model: cron.allow and at.allow present, listing only the accounts that need them, and the deny files removed so nobody mistakes them for the control.

Linux loads most drivers on demand. Mount a cramfs or udf image, or plug in a USB stick, and the kernel asks modprobe to load the matching module, pulling rarely-used and rarely-audited filesystem code into the kernel because of a file an attacker handed you. CIS lists the filesystems most servers never use (cramfs, freevxfs, hfs, hfsplus, jffs2, udf, and usb-storage for removable media) and wants each one unloadable.

Two lines in a file under /etc/modprobe.d/ do it, and they do different jobs. The file name must end in .conf: modprobe reads only *.conf files there, so the same lines in cis.conf.bak or cis.txt do nothing, and modprobe -n -v cramfs will tell you so.

• `install <module> /bin/false` tells modprobe to run /bin/false instead of loading the module. Every load request fails, including an explicit modprobe <module> by root.
• `blacklist <module>` only stops the module from loading automatically through an alias (the udev and hardware path). An explicit modprobe still loads a module that is only blacklisted.

CIS wants both: the install line is the actual stop, and the blacklist line is what its audit also looks for.

CIS section 3.3 tunes how the kernel treats packets that try to change its routing. Most keys come in all and default pairs. net.ipv4.conf.all.<key> covers every interface that exists now (for most of these keys the kernel combines it with the per-interface value), and net.ipv4.conf.default.<key> is the template copied to interfaces created later. Set both.

| Key | CIS value | Why |

|---|---|---|

| accept_redirects | 0 | An ICMP redirect rewrites your route table. A forged one sends your traffic through the attacker. |

| secure_redirects | 0 | The same, for redirects claiming to come from a listed gateway. |

| send_redirects | 0 | Only routers send redirects. A server that does is misconfigured. |

| accept_source_route | 0 | Source-routed packets choose their own path, which bypasses your network's filtering. |

| log_martians | 1 | Log packets with impossible source addresses, an early sign of spoofing. |

| rp_filter | 1 | Strict reverse-path filtering: drop a packet whose source isn't reachable back through the interface it arrived on. 2 is the looser mode. |

| icmp_echo_ignore_broadcasts | 1 | Ignore pings sent to a broadcast address (smurf amplification). It has no all/default pair. |

Write them to one drop-in. The file name matters, as the next block shows.

Every program linked against OpenSSL (web servers, mail, curl, scripts) reads openssl.cnf when it starts. A system default section in that file sets a floor all of them inherit unless the program overrides it. Two directives carry the policy:

• `MinProtocol = TLSv1.2` refuses TLS 1.0 and 1.1.
• `CipherString = DEFAULT@SECLEVEL=2` sets the security level. Level 2 means at least 112-bit security: RSA and DH keys of 2048 bits or more, no SHA-1 certificate signatures, no export or NULL ciphers. Level 3 raises RSA to 3072 bits.

The section is reached through a chain of names, and every link has to be there:

1. openssl_conf = <init> in the global section, meaning above the first [header]. Anything below a header belongs to that section, and OpenSSL never looks for openssl_conf there.

2. [<init>] with ssl_conf = <ssl>.

3. [<ssl>] with system_default = <policy>.

4. [<policy>] with the directives.

The section names are yours to choose. Ubuntu 22.04 already ships the chain with SECLEVEL=2 but no MinProtocol. A trimmed or hand-written file may have no chain at all.

Run these in your lab terminal as a mini CIS audit. Each one only reads. For every command, say the verdict out loud the way a findings report would: control, expected value, observed value, pass or fail. The labs cis-core-dumps, cis-cron-hardening, cis-filesystem-modules, cis-network-params and security-tls-crypto-policy each start from a failing host and grade the files exactly the way these checks read them.