Vulnerability scanning

Table of Contents

Why Vulnerability Scanning Matters in Hardening

Vulnerability scanning is the systematic process of detecting known weaknesses in a system, service, or application by comparing what’s running on the system against:

Known CVEs (Common Vulnerabilities and Exposures)
Misconfiguration checks
Outdated software versions
Weak or missing security controls

Within a hardening workflow, scanning is how you:

Validate your hardening work
Find regressions (e.g., a package update re-enables a weak cipher)
Continuously track exposure as new CVEs appear

This chapter focuses on practical, host-centric scanning and how to integrate it into a Linux hardening process.

Types of Vulnerability Scanners

Network vs Host-Based Scanning

Network scanners

Scan from the outside, over the network
Discover open ports, protocols, banners, and fingerprint services
Good for: “What can an attacker see from here?”
Examples: Nmap + NSE, OpenVAS/GVM, Nessus, Qualys, Nexpose

Host-based scanners

Run on the system (agent or local script)
Inspect installed packages, kernel, configuration, and local files
Good for: “What is actually installed and misconfigured on this host?”
Examples: OpenSCAP, Lynis, osquery, distro security scanners (e.g., debian-security-support)

You usually want both:

Network view to model external exposure
Host view to model true risk (including local-only issues, kernel CVEs, misconfigurations)

Authenticated vs Unauthenticated Scans

Unauthenticated scans

No login to the host; rely on banners, fingerprints
Low fidelity; easy to miss context (e.g. claim a service is vulnerable based only on banner)
Useful for simulating an anonymous Internet attacker

Authenticated scans

Use SSH keys, agents, or privilege escalation to inspect inside the system
Higher accuracy; fewer false positives
Required for serious hardening and compliance work

For hardening, prefer authenticated scans wherever possible.

Core Concepts and Terminology

CVEs, CVSS, and CPEs

CVE: Identifier for a specific vulnerability, e.g. CVE-2024-12345
CVSS: Scoring system (0–10) giving severity and exploitability
CPE: Common Platform Enumeration naming format for software/hardware

Scanners map:

Detected software (via package databases, banners, fingerprints)
To CPEs
Then to CVEs with CVSS scores

This mapping is imperfect; understanding that imperfection is critical when interpreting results.

False Positives and False Negatives

False positive: Scanner claims a vulnerability that doesn’t actually apply

Example: Banner shows OpenSSL 1.1.1, but distro backported security patches, so CVE is fixed

False negative: Vulnerability exists but scanner doesn’t find it

Example: Custom-compiled software not in package database

Hardening requires you to:

Maintain a process to review and classify findings
Document accepted risks and justifications
Use multiple data sources when it matters (vendor advisories, distro security trackers)

Typical Vulnerability Scanning Workflow

A pragmatic host hardening workflow with scanning might look like:

Define scope and assumptions

Which hosts, networks, and environments (prod/stage/dev)?
What is “in scope” for compliance or audits?

Establish a baseline scan

Run initial authenticated host scans
Run a perimeter network scan from a representative vantage point
Archive scan results as the “pre-hardening” state

Harden the system

Apply OS and package updates
Apply baseline hardening (sysctl, SSH settings, firewall, etc. – covered in the hardening chapter)
Remove or restrict unnecessary services

Run post-hardening scans

Compare before/after
Ensure:

Fewer exposed ports
Fewer high/critical CVEs
No newly introduced critical findings (e.g., misconfigured firewall rule)

Triage and remediation

Sort by severity and exploitability
Identify quick wins vs. architectural issues
Open tickets / tasks with clear owners and remediation plans

Continuous scanning

Schedule regular scans (daily/weekly)
Track new vulnerabilities that appear in:

New software you deploy
Old software as new CVEs are discovered

Practical Host-Based Scanning on Linux

Distro Security Tools and Package Vulnerability Checks

Most distributions publish security advisories and have tooling to detect vulnerable installed packages.

Debian / Ubuntu

apt integrates with security advisories indirectly; you can:

Keep updated:

    sudo apt update
    sudo apt upgrade

Use debian-security-support (Debian) to check unsupported packages:

    sudo apt install debian-security-support
    check-support-status

Third-party tools like debsecan (Debian) or ubuntu-security-status (Ubuntu) can map installed packages to CVEs using distro data.

RHEL / CentOS / AlmaLinux / Rocky Linux

yum/dnf work with security advisories:

  sudo dnf updateinfo list security
  sudo dnf update --security

RHEL provides oscap content and vendor-certified scanning with OpenSCAP (more below).

Fedora

Similar to RHEL-based:

  sudo dnf updateinfo
  sudo dnf update --security

Arch / Manjaro

Rolling-release: reduce “known vulnerable” windows by updating frequently:

  sudo pacman -Syu

Use third-party tools or monitoring scripts that compare installed versions to Arch security advisories.

openSUSE / SUSE Linux Enterprise

Use zypper to specifically apply security updates:

  sudo zypper lp -g security  # list patches
  sudo zypper patch --category security

For hardening, tie vulnerability scanning with your package update policy: unpatched software is the most common, easily measurable risk.

OpenSCAP (SCAP-Based Scanning)

OpenSCAP implements the SCAP standards suite (XCCDF, OVAL, etc.) and is widely used for:

Compliance checks (CIS, DISA STIG, etc.)
Vulnerability checks via OVAL definitions

Core ideas:

Content: XML files that define what to check (for a specific OS/version)
Engine: oscap interprets that content and runs checks on your system

Basic Usage

Install OpenSCAP and relevant content:

RHEL/Fedora (example):

  sudo dnf install openscap-scanner scap-security-guide

Debian/Ubuntu (packages may vary by release):

  sudo apt install libopenscap8 ssg-base

List available profiles (e.g., for RHEL-like systems):

oscap info /usr/share/xml/scap/ssg/content/ssg-<your-distro>-ds.xml

Run a scan with a specific profile:

sudo oscap xccdf eval \
  --profile xccdf_org.ssgproject.content_profile_standard \
  --results results-xccdf.xml \
  --report report-xccdf.html \
  /usr/share/xml/scap/ssg/content/ssg-<your-distro>-ds.xml

For vulnerability (OVAL) scanning, you may use OVAL feeds supplied by your distro or third parties:

sudo oscap oval eval --results oval-results.xml --report oval-report.html <oval-definitions.xml>

Open the HTML report and look for:

High-severity failed rules
Vulnerabilities that are directly remediable via updates
Misconfiguration findings that impact your hardening baseline

Integrating with Hardening

Use OpenSCAP profiles aligned with your security baseline (e.g., CIS Level 1)
After hardening, re-run scans to confirm:

Hardening rules are implemented
OVAL-defined vulnerabilities are absent or accepted with justification

Lynis: Lightweight Host Audit & Vulnerability Scanner

Lynis is a host-based auditing tool focused on Unix-like systems. It’s useful for:

Quick, agentless security assessments
Combining misconfiguration checks and vulnerability hints

Installation

On many systems you can install from packages, or directly from upstream tarball:

# Example for Debian/Ubuntu
sudo apt install lynis

Running a Scan

sudo lynis audit system

Key outputs:

A list of findings with IDs (e.g. SSH-7408)
A hardening index (a numeric score)
Recommendations with “suggested actions”

To use it in hardening:

Map Lynis findings to your hardening checklist
Fix issues, then re-run to track score improvements
Integrate in CI or cron for regular checks

Specialized Tools: osquery and Custom Checks

osquery exposes system state as SQL tables. While not a scanner by itself, you can:

Maintain queries that detect:

Outdated packages
Weak SSH configuration
Unapproved listening services

Run scheduled queries and alert on changes

For highly specialized environments, it can be more maintainable to:

Use osquery for policy enforcement and detection
Use traditional scanners (OpenSCAP, Lynis) for broad, standards-based scans

Network-Based Vulnerability Scanning

Port Scanning as a Baseline

Before running complex scanners, always know which ports are open.

Nmap Port Scanning

Quick scan of common ports:

nmap -sS -T4 <target>

More comprehensive:

nmap -sS -sV -O -p- <target>

-sV: service version detection
-O: OS detection
-p-: scan all 65535 TCP ports

Use this to:

Confirm that your firewall and service hardening is effective
Discover unintended services (e.g., a forgotten test daemon)

Nmap Scripting Engine (NSE) for Known Vulnerabilities

NSE packs many vuln-related scripts. Example:

nmap --script vuln -sV <target>

This runs scripts tagged vuln against detected services to check for:

Known CVEs on common services
Default credentials or weak configuration in some cases

Use NSE carefully:

Some scripts can be intrusive or cause service instability
Run against staging first; coordinate with service owners

Full-Fledged Network Vulnerability Scanners

Tools like OpenVAS/GVM, Nessus, or Qualys:

Maintain large CVE and check databases
Perform authenticated and unauthenticated scans
Generate management-level reports (trend charts, SLA tracking)

From a hardening standpoint:

Start with an Internet-facing perimeter scan
Then add internal scans from key network vantage points
Use authenticated scanning for critical servers

Align scanning with change windows to avoid surprises and plan remediation.

Container and Image Vulnerability Scanning

In containerized environments, you must scan:

Base images (OS libraries, runtimes)
Application dependencies (e.g., Python, Node.js, Java)
Running containers and their configuration (capabilities, volume mounts, privileged flags)

Popular image scanners include:

Trivy
Grype
Clair

Example using Trivy:

trivy image myapp:latest

Integrate image scanning:

In CI pipelines before pushing images
Regularly against existing registries
In conjunction with host-level scanning of container hosts

Prioritizing and Acting on Findings

You will always have more findings than you can fix immediately. A disciplined prioritization strategy is essential.

Prioritization Criteria

Combine several dimensions:

Severity (CVSS)

Focus on High/Critical ($\geq 7.0$) first, but consider context

Exposure

Is the vulnerable service Internet-facing?
Is it reachable from untrusted zones?

Exploitability

Public exploits or exploit kits?
Requires authentication or special conditions?

Compensating controls

Strong network segmentation?
WAF, reverse proxy, or strict ACLs in front?

You can create a simple formula, for example:

$$
\text{Risk Score} = \text{CVSS} \times \text{Exposure Factor} \times \text{Exploitability Factor}
$$

Where:

Exposure factor: 1 (internal only) to 3 (Internet-facing)
Exploitability factor: 1 (hard) to 3 (trivial / automated)

Use such a ranking to decide remediation order.

Remediation Strategies

Common hardening actions triggered by scans:

Patch / upgrade

Ideally, use distro packages
If vendor patch unavailable, consider backports or mitigation

Configuration change

Disable or restrict vulnerable feature / protocol
Tighten ciphers (e.g., SSH, TLS), disable weak algorithms

Service removal or isolation

Remove unused services and packages
Move risky services behind:

Reverse proxy
VPN
Jump host / bastion

Compensating controls

Firewall rules, SELinux/AppArmor policies
IDS/IPS signatures
Rate-limiting or access throttling

Each accepted risk should be:

Documented (what, why, under whose approval)
Tied to compensating controls
Revisited periodically

Scheduling and Automating Vulnerability Scans

Choosing Scan Frequencies

Typical patterns:

Critical Internet-facing systems

Network scans: weekly or even daily
Host scans: weekly or around major updates

Internal servers

Monthly host + network scans
More frequent if change rate is high

Workstations

Monthly or quarterly, depending on policy

Combine:

Regular full scans (baseline)
Targeted scans after changes

After major upgrades
After deploying new services
After major hardening changes

Automation with Cron and CI/CD

Example: Run Lynis weekly and keep logs:

sudo crontab -e

Add:

0 3 * * 1 /usr/sbin/lynis audit system --quiet --logfile /var/log/lynis-$(date +\%F).log

For OpenSCAP, you might:

Create a wrapper script that:

Runs oscap with your profile
Stores reports in a central location
Sends an alert if high-severity failures are present

In CI/CD:

Scan container images before pushing
Run configuration scans on infrastructure-as-code (e.g., Terraform) where supported
Fail builds on critical vulnerabilities or misconfigurations

Integrating Vulnerability Scanning into a Hardening Program

To make vulnerability scanning truly useful (and not just report spam):

Define policies

Acceptable maximum age for unpatched criticals
Required frequency of scans by asset class

Standardize tooling

Choose a primary host scanner and network scanner
Standardize profiles (OpenSCAP, Lynis configs, etc.)

Connect with patch management

Findings should feed directly into your patch/change process
Track time-to-remediate for key vulnerabilities

Measure and track trends

Number of open critical/high findings over time
Percentage of systems fully scanned in the last period
Hardening score trends (from Lynis / OpenSCAP profiles)

Ensure coverage

Use inventory/CMDB to verify all assets are included
Include ephemeral/cloud resources (dynamic IPs, autoscaling)

Common Pitfalls and How to Avoid Them

Relying on unauthenticated scans only

Get SSH/agent-based access for realistic results

Ignoring distro backports

Always cross-check CVEs with distro security advisories
Document when a CVE is “fixed via backport”

Treating scanner output as gospel

Manually verify high-impact findings
Be cautious with banner-based assumptions

Scanning once and forgetting

New CVEs appear continuously
Hardening is an ongoing process tied to scanning

Not aligning with operations

Coordinate with system owners; avoid scanning during peak load if tools are heavy
Integrate with change windows for remediation

By treating vulnerability scanning as a continuous feedback loop—informing and validating your hardening efforts—you convert raw findings into a structured, repeatable process for reducing risk on Linux systems.

Comments

Please login to add a comment.

Don't have an account? Register now!