rkhunter Integration with DefectDojo

rkhunter Integration with DefectDojo

rkhunter (Rootkit Hunter) is an open source host scanner for Unix-like systems, distributed through its SourceForge project, with 1.4.6 as the current release. It runs on the machine it is auditing and checks for known rootkit signatures, system binaries whose properties have changed, suspicious files, kernel module state, and network and logging configuration. Results are written to a plain text log, normally /var/log/rkhunter.log, which is the file DefectDojo imports.

rkhunter Integration with DefectDojo

We run rkhunter on our Linux hosts because it is cheap, needs no agent infrastructure, and catches the kind of tampering that application scanners never look at. The problem was always the output. Each run writes well over a thousand lines of passing checks with a handful of warnings buried inside, and nobody reads that log on fifty servers. Importing the rkhunter log into DefectDojo pulls out only the warnings, files them under the Asset that owns the host, and keeps a history, so a warning that appeared last night stands out from one we already reviewed and accepted.

Why rkhunter Matters

Host compromise usually shows up first as small changes to the operating system: a replaced binary, a hidden file, an unexpected kernel module, a logging daemon that stopped. rkhunter looks for exactly those signals.

• It compares system binaries against a stored baseline of file properties, so a modified ls or ps is flagged even when no signature matches.
• It checks for files and directories associated with known rootkits and backdoors.
• It reviews local configuration that attackers tend to weaken, such as SSH settings and whether system logging is running.
• It is a single shell-based tool that runs as root on the host, which makes it easy to add to hardening and audit routines.
• A log that nobody triages has no value. Warnings need an owner and a decision, and that is where DefectDojo comes in.

Advantages of This Integration

What we gained by sending rkhunter results through DefectDojo:

• Signal extracted from noise. The parser creates a Finding only for lines that end in [ Warning ]. Passing, skipped, and not-found checks stay out of DefectDojo entirely.
• History per host. Reimporting each run into the same Test mitigates warnings that cleared, adds new ones, and reactivates any that came back after a fix.
• Context on every Finding. Each description carries the rkhunter version, host name, and operating system from the log header, so a Finding still makes sense when someone reads it weeks later.
• Triage with a record. Container artefacts and known environment quirks can be marked false positive or risk-accepted with an expiry, instead of being mentally filtered on every run.
• Ownership and escalation. Findings can be assigned to the team that runs the host, commented on, and pushed to Jira when a warning needs investigation.
• Host findings next to everything else. Server integrity warnings sit on the same Asset as scanner results for the software deployed there, which gives a fuller picture in reporting.

How This Integration Works

DefectDojo imports rkhunter logs with the rkhunter Scan scan type.

1. Produce a single-run log. Run rkhunter as root on the host you want to audit:

rkhunter --check --sk --nocolors --noappend-log

--sk skips the keypress prompts, which matters in automation. --noappend-log overwrites the log instead of appending to it, so the file holds exactly one run. Without it, the log accumulates several audits and the same warning imports more than once. rkhunter audits the machine it runs on; inside a container it audits the container.

2. Import the log. In the UI, open the Engagement, choose Import Scan Results, select rkhunter Scan, and upload /var/log/rkhunter.log. To automate it from the host or a collection job, use the API, available in Community Edition and DefectDojo Pro:

curl "https://YOUR_INSTANCE/api/v2/import-scan/" 
  -H "Authorization: Token $DD_API_TOKEN" 
  -F "scan_type=rkhunter Scan" 
  -F "file=@/var/log/rkhunter.log" 
  -F "product_name=web-tier" 
  -F "engagement_name=Host Integrity" 
  -F "test_title=web-01" 
  -F "auto_create_context=true"

DefectDojo Pro users can run the same import with Universal Importer:

universal-importer import 
  --defectdojo-url "https://YOUR_INSTANCE.cloud.defectdojo.com/" 
  --scan-type "rkhunter Scan" 
  --report-path "/var/log/rkhunter.log" 
  --product-name "web-tier" 
  --engagement-name "Host Integrity" 
  --auto-create-context

3. Reimport on a schedule. For hosts you audit regularly, send each new log to /api/v2/reimport-scan/ against the host's existing Test so cleared warnings are mitigated and the history stays in one place.

Data Granularity: What Gets Imported

Because file path, line, and CWE are empty, deduplication effectively compares the title and the full description, including the host and version context.

Use Cases

Across a server fleet: A nightly cron job runs rkhunter on each Linux host and reimports the log into a Test named for that host. The security team reviews only new warnings each morning instead of reading logs, and the Asset view shows which hosts have open integrity findings.

When validating a golden image: A platform team runs rkhunter against a freshly built base image, triages every warning once, and risk-accepts the expected ones. Later builds that introduce a new warning show up as a new Finding rather than one more line in a long log.

During incident response: After a suspected compromise, responders run rkhunter on the affected hosts and import the results into a dedicated Engagement. Warnings become Findings with notes and owners, and the record of what was checked and when stays attached to the incident.

For compliance evidence: Auditors asking for proof of integrity monitoring can see each host's rkhunter imports, the warnings raised, and how each one was resolved or accepted.

Operational Tips

• Every warning imports at Medium. Triage by check, and lower or raise severity on the Finding once you know whether it is a real indicator or an environment artefact.
• Some warnings are normal in containers, such as a missing or empty kernel modules directory. Mark these false positive or risk-accept them with an expiry so they do not distract from real changes.
• The host name and rkhunter version are part of the description, and the description is part of the hash. Containers that get a random host name on every start will create new Findings each run, so set a stable host name or use a fresh Test per run.
• Upgrading rkhunter changes the version line in every description, which changes the hash. Expect one round of new Findings after an upgrade and close the old ones by reimporting.
• Always use --noappend-log. An appended log contains several runs, and each repeated warning imports again.
• Refresh rkhunter's file properties baseline after planned package updates, otherwise legitimate binary changes surface as warnings.
• Use one Test per host and reimport into it. Tags such as the environment or data center make it easy to filter host findings in metrics.