Vulnerability scanning and benchmarks

Why this matters

Two questions, asked continuously rather than once: what is wrong with this system, and has anything got in. Scanning answers the first, detection the second, and benchmarks give you a standard to measure against so "secure" means something specific.

One idea here is worth more than the rest, because it causes real arguments with auditors: backported patches. A Red Hat package can be fully patched while reporting an old version number, so a naive scanner declares it vulnerable and the finding is wrong. Knowing why saves a great deal of pointless remediation.

The lesson

CVEs and CVSS

A CVE — Common Vulnerabilities and Exposures — is a unique identifier for one specific flaw: CVE-2024-3094. It is a name, not a severity. Its purpose is that everyone can refer to the same issue unambiguously.

CVSS — the Common Vulnerability Scoring System — scores severity from 0.0 to 10.0:

The base score is built from attack vector (network, adjacent, local, physical), complexity, privileges required, user interaction, and the impact on confidentiality, integrity and availability.

The score is not your risk. A CVSS 9.8 in a package you have installed but never run is less urgent than a 6.5 in your public web server. CVSS describes the flaw in the abstract; you supply the context — is it reachable, is it exploited in the wild, what does it touch. Treating the number as a work queue means fixing the wrong things first.

dnf updateinfo list --security          # security updates available
dnf updateinfo info CVE-2024-3094       # what a specific CVE affects
dnf update --security                   # apply only security updates
apt list --upgradable

Backported patches, and why scanners get this wrong

This is the important one.

Enterprise distributions do not upgrade to new upstream versions during a release's life, because that would change behaviour. Instead they backport the security fix — taking the patch from the new version and applying it to the old one, keeping the version number.

So RHEL might ship openssl-1.1.1k-12.el8, where upstream fixed the flaw in 1.1.1n. The package is patched. The version string still says 1.1.1k.

A scanner comparing version numbers reports it as vulnerable, and is wrong. Verify against the distribution's own data:

rpm -q --changelog openssl | grep CVE-2024      # is this CVE fixed here?
dnf updateinfo info --cve CVE-2024-3094
apt changelog openssl | grep CVE

If the changelog names the CVE, it is fixed regardless of the version number. This is worth being able to explain: "the scanner says we are vulnerable" is answered with the changelog entry, not by upgrading to a version your distribution does not ship.

Vulnerability scanning and configuration auditing

OpenSCAP implements SCAP — the Security Content Automation Protocol — and audits a system against a published policy, reporting per-rule pass or fail with remediation.

dnf install openscap-scanner scap-security-guide
ls /usr/share/xml/scap/ssg/content/

oscap info /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml   # profiles available

oscap xccdf eval \
  --profile xccdf_org.ssgproject.content_profile_cis \
  --results scan.xml --report report.html \
  /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml

oscap xccdf generate fix --profile cis --output remediate.sh scan.xml
oscap oval eval --report vuln.html com.redhat.rhsa-RHEL9.xml   # CVE check

generate fix produces a remediation script. Read it before running it — it will happily apply every failed control, some of which will break your application. Remediation is a decision per rule, not a batch operation.

CIS Benchmarks are the consensus configuration standards OpenSCAP profiles usually implement. They come in two levels: Level 1 is defensible on almost any system, Level 2 trades functionality for security and needs thought.

Neither is a target to score 100% on. Some controls will not fit; the useful output is a documented, reasoned exception list rather than a perfect number achieved by breaking things.

Anti-malware

Linux malware is real, and a Linux file server also stores files that will infect Windows clients.

dnf install clamav clamav-update
freshclam                              # update signatures
clamscan -r /home                      # scan a directory
clamscan -r --infected --remove /tmp
systemctl enable --now clamav-freshclam

Signature scanning catches known malware. It will not catch a targeted attack or a novel implant, which is why it sits alongside file integrity monitoring rather than replacing it.

Indicators of compromise

An IOC is evidence that something has already happened. On Linux the ones worth checking directly:

find / -perm -4000 -type f 2>/dev/null | diff /root/suid-baseline.txt -
crontab -l; ls -la /etc/cron.*                  # unexpected scheduled jobs
ss -tulnp                                       # unexpected listeners
last | head -50                                 # unexpected logins
lastb | head -50                                # brute-force attempts
grep -rE 'ssh-(rsa|ed25519)' /home/*/.ssh/authorized_keys   # keys you did not add
ls -la /etc/systemd/system/                     # unexpected units
find / -mtime -1 -type f 2>/dev/null | head     # recently modified files

The pattern: persistence has to live somewhere. An attacker who wants to survive a reboot must leave a cron job, a systemd unit, an SSH key, a setuid binary or a modified init script. Enumerate those places and you find most of what is there.

The high-value single checks are a new setuid-root binary, an SSH key in authorized_keys that nobody added, and a systemd unit nobody wrote — each is close to unambiguous.

Service misconfigurations

Frequently a bigger risk than an unpatched CVE, because they are exploitable without any special knowledge:

• Default or unchanged credentials
• A database bound to 0.0.0.0 rather than 127.0.0.1
• Directory listing enabled on a web server
• Anonymous access permitted where it should not be
• Debug or verbose error modes left on in production
• Overly permissive file permissions on configuration holding secrets

ss -tulnp                                      # what is exposed, and where bound
grep -rE '^\s*(bind|listen)' /etc/mysql/ /etc/postgresql/
find /etc -name "*.conf" -perm /o+r | xargs grep -l -i password 2>/dev/null

That last command finds world-readable configuration files containing a password, which is a depressingly productive search on inherited systems.

Tools of the trade

Port scanners find what is listening — from outside, which is the view that matters:

nmap -sS -p- 10.0.0.5             # all TCP ports
nmap -sV -sC 10.0.0.5             # versions plus default scripts
nmap --script vuln 10.0.0.5       # known-vulnerability scripts

Scan your own hosts from outside the host. ss shows what the machine thinks it is doing; a scan shows what the network can actually reach, and the two differ whenever a firewall rule is wrong in either direction.

Protocol analysers show what is actually on the wire:

tcpdump -i eth0 -w capture.pcap
tshark -i eth0 -Y "http.request"

The security use is confirming that traffic you believe is encrypted actually is. A capture showing plaintext credentials on a link somebody assured you was TLS is the kind of evidence that ends the discussion.

Only scan and capture where you are authorised to. On networks you do not own this is at best a disciplinary matter.

File integrity, in outline

Knowing what changed is the other half of detection, and it is the subject of the next lesson: AIDE and rkhunter build a baseline of file hashes and report deviations, which catches the modified binary that signature scanning misses.

On the exam

• A CVE identifies a flaw; CVSS scores its severity 0–10. The score is not your risk — reachability and exposure decide that.
• Backported patches keep the old version number, so version-comparing scanners produce false positives. Check rpm -q --changelog or dnf updateinfo info --cve.
• OpenSCAP audits against a profile; oscap xccdf generate fix produces a remediation script that should be read before running.
• CIS Benchmarks come in Level 1 (broadly safe) and Level 2 (trades functionality).
• IOCs to check: new setuid binaries, unexpected cron jobs and systemd units, unknown SSH keys, unexpected listeners.
• Misconfiguration — default credentials, a service bound to 0.0.0.0 — is often a bigger risk than an unpatched CVE.
• Scan from outside the host; ss and a port scan answer different questions.