Rootkits are malicious tools attackers install to keep persistent, stealthy access to a compromised system. Regular rootkit scanning is an essential part of server security hygiene — especially for cloud servers that run public services.

This guide covers:

• What rkhunter and chkrootkit do ✅

• Installation on Debian/Ubuntu and RHEL/AlmaLinux ✅

• Updating signatures and performing scans ✅

• Automating scans with cron ✅

• Interpreting results & remediation steps ✅

• Best practices and caveats ✅

💡 Overview: rkhunter vs chkrootkit

• rkhunter (Rootkit Hunter)

  • Uses checksum comparisons, file properties, and known rootkit signatures.

  • Checks for suspicious files, hidden processes, suspicious ports, and common backdoors.

  • Good for periodic, signature + heuristic-based checks.

• chkrootkit

  • Collection of small tests to detect known rootkit behaviors (e.g., ls, ifconfig replacements).

  • Fast, targeted tests — useful as a second opinion.

✅ Recommended: Use both tools regularly — they complement one another.

🛠️ Installation

Debian / Ubuntu

sudo apt update
sudo apt install rkhunter chkrootkit -y

RHEL / CentOS / AlmaLinux / Fedora

# Enable EPEL for RHEL/CentOS/AlmaLinux if needed
sudo dnf install epel-release -y

# Install packages
sudo dnf install rkhunter chkrootkit -y

🔁 Initial Setup & Updating Databases

rkhunter — update its data files

# Update rkhunter properties and data
sudo rkhunter --update
sudo rkhunter --propupd   # create/update local file property database (run AFTER a clean system baseline)

Note: --propupd should be run once on a clean/trusted system or after you've verified the system state — this updates the baseline file hashes.

chkrootkit — no signature DB, but keep the package updated

sudo chkrootkit -V    # show version
# The program itself updates with system packages (apt/dnf). Reinstall/rebuild when package updates appear.

🔎 Running Scans (Interactive)

rkhunter — basic scan

sudo rkhunter --check --sk   # --sk = skip keypress prompts, good for noninteractive

Common useful flags:

• --checkall (run all tests)

• --report-warnings-only (show only warnings)

• --nolog / --logfile <path> (control logging)

Example:

sudo rkhunter --check --report-warnings-only --logfile /var/log/rkhunter/rkhunter.log

chkrootkit — run the full check

sudo chkrootkit

Or for a quick scan:

sudo chkrootkit -q    # quiet mode with minimal output

📄 Scheduling Regular Scans (cron)

Create a daily cron job (example: /etc/cron.daily/rkhunter_chkrootkit):

sudo nano /etc/cron.daily/rkhunter_chkrootkit

Insert:

#!/bin/sh
# Update rkhunter DB and run scan
/usr/bin/ rkhunter --update
/usr/bin/ rkhunter --propupd  # only if you intend to reset baseline (use with caution)
/usr/bin/ rkhunter --check --silent

# Run chkrootkit
/usr/sbin/chkrootkit -q

Make executable:

sudo chmod +x /etc/cron.daily/rkhunter_chkrootkit

⚠️ Important: Avoid running --propupd automatically — it resets the baseline and can hide compromises. Only use it when you are sure the system is clean (e.g., after provisioning).

🧾 Log Files & Checking Results

• rkhunter logs:

  • Default: /var/log/rkhunter.log or /var/log/rkhunter/rkhunter.log (depends on packaging)

  • You can also specify --logfile during runs.

• chkrootkit output:

  • STDOUT when run interactively. Redirect to a file for persistent logs:

    sudo chkrootkit | tee /var/log/chkrootkit.log
    

• Inspect cron-run outputs in system mail or configured log destinations, or redirect outputs inside your cron script to log files or to email.

❗ Interpreting Results & Handling False Positives

Both tools can report false positives (benign software flagged as suspicious). Typical examples:

• Custom kernel modules

• Nonstandard utilities or locally compiled binaries

• Modified tools due to updates

Workflow when a test flags something suspicious:

1. Don’t panic. Treat as potential indicator, not proof.

2. Inspect the flagged file/process: ls -l, stat, file, sha256sum it and compare with known-good sources.

3. Check process info: ps aux | grep <pid> and lsof -p <pid> to see open files and network sockets.

4. Verify package origin: dpkg -S /path/to/file or rpm -qf /path/to/file to check which package owns the file.

5. Search hashes online (vendor checksums) or compare with a known-good backup.

6. If confirmed malicious: isolate the host, take full disk images/snapshots (preserve for forensics), then rebuild OS from clean images.

🩺 Remediation Steps (If Compromise Suspected)

1. Isolate the server from the network immediately.

2. Preserve evidence:

   • Create disk snapshots or forensic images.

   • Export logs (/var/log/), memory if possible (volatility, liME), and process lists.

3. Collect indicators: file paths, hashes, timestamps, network connections.

4. Rebuild from a trusted OS image — do not rely on cleaning an infected system unless you are performing a verified forensic cleanup.

5. Rotate credentials (passwords, keys) used on the compromised host.

6. Review ingress vector: exposed services, outdated software, compromised credentials, vulnerable web apps.

7. Harden and re-deploy: patching, minimal packages, firewalls, 2FA for admin access, monitoring/IDS.

🔐 Extra Tips & Best Practices

• Baseline first: Run rkhunter --propupd on fresh, trusted installs to build a baseline.

• Don't auto-update the baseline in scripts. Manual baseline updates after maintenance are safer.

• Combine with other tools: OSSEC, AIDE (file integrity), auditd, fail2ban, intrusion detection systems, and centralized logging (ELK/Graylog).

• Use immutable backups/snapshots so you can compare suspicious binaries.

• Keep packages updated: rootkits often exploit unpatched services.

• Use SELinux/AppArmor where possible — they limit damage of compromised processes.

• Alerting: forward scan outputs to a SIEM or send urgent emails on warnings (grep Warning/INFECTED in logs).

🧩 AlmaLinux / SELinux Notes

• On SELinux-enabled systems, normal rkhunter/chkrootkit behavior should work. If you see permission denials, check audit logs (/var/log/audit/audit.log) and use ausearch/audit2allow for troubleshooting.

• If you create a custom baseline, ensure SELinux contexts on files are correct (restorecon -Rv /path). Some checks may flag SELinux-labeled files if contexts differ from expected.

⛔ Caveats & Limitations

• Rootkit scanners are not foolproof. Advanced rootkits can hide from these tools (kernel-level, in-memory-only).

• Regular scanning is defensive; it’s part of a broader security posture (patching, least privilege, monitoring).

• Never rely on these tools alone to declare a system “clean.” Use them as indicators for further investigation.

✅ Example Quick Checklist (for your Back2Cloud readers)

1. Install rkhunter and chkrootkit.

2. Update rkhunter data: sudo rkhunter --update.

3. Create a trusted baseline: sudo rkhunter --propupd (only on known-clean systems).

4. Run and log scans daily via cron.

5. Investigate and preserve evidence for any suspicious findings.

6. Rebuild compromised servers from trusted images.

7. Harden, patch, and monitor continuously.

📌 Conclusion

rkhunter and chkrootkit are valuable, lightweight tools for detecting known rootkit signatures and suspicious behavior on Linux cloud servers. When combined with proactive hardening, file integrity monitoring, centralized logging, and a well-practiced incident response plan, they help you maintain a more secure cloud environment.