Detecting Compromise on Linux Servers: ClamAV, Lynis, AIDE and Rootkit Checkers
A practical detection toolkit for Debian, Ubuntu and RHEL servers: ClamAV for web roots and uploads, Lynis audits, AIDE file-integrity checks, rootkit scanners and their honest limits.
How do you know a Linux server has not been compromised? No single tool can promise that, but a small, free toolkit gets you most of the way: ClamAV to scan web roots and uploaded files for known malware, Lynis to audit the configuration, AIDE to alert you when system files change, and, with clear caveats, rkhunter or chkrootkit for known rootkit traces. Schedule them, send the results somewhere a person reads them, and decide in advance what you will do when one of them flags something. Below are the commands for Debian 12/13, Ubuntu 24.04 and RHEL/AlmaLinux 9/10.
This guide is about detection. Prevention (updates, firewall, SSH) is covered in our Linux server hardening essentials.
What each tool does, and what it does not
| Tool | What it checks | What it will not tell you |
|---|---|---|
| ClamAV | Files against known malware signatures | New or custom malware without a signature |
| Lynis | Configuration weaknesses, missing hardening | Whether an attacker is already inside |
| AIDE | Which files changed since your baseline | Whether a change was malicious or a legitimate update |
| rkhunter / chkrootkit | Known rootkit files and suspicious settings | Rootkits they do not know, or ones that hide from the running system |
dpkg --verify / rpm -Va |
Packaged files that differ from the package checksums | Changes to files no package owns, such as your website |
None of them replaces backups, patching or monitoring.
ClamAV: scanning web roots and uploads
ClamAV is an open-source antivirus engine maintained by Cisco Talos. On servers it is most useful for directories where outsiders can place files: website roots, upload folders, shared drives and mail attachments.
Install and keep signatures current
## Debian / Ubuntu
sudo apt install clamav clamav-daemon
systemctl status clamav-freshclam
## RHEL / AlmaLinux (packages come from EPEL)
sudo dnf install epel-release # on RHEL, follow the EPEL setup instructions
sudo dnf install clamav clamd clamav-freshclam
sudo freshclam
sudo systemctl enable --now clamav-freshclam
freshclam downloads the official signature databases, and the clamav-freshclam service keeps them updated. A scanner with stale signatures gives false comfort, so check that service whenever you review the server.
clamscan or clamd?
clamscanis a standalone command. It loads the whole signature database on every run, which is slow to start and uses a lot of memory while it runs. It is fine for a nightly job.clamdis a daemon that keeps the engine loaded, andclamdscansends files to it. It is faster for frequent scans or for checking uploads as they arrive. It keeps the signatures in memory all the time, and by default it briefly loads a second engine while reloading signatures (ConcurrentDatabaseReload), so size the server's RAM accordingly. Never expose clamd's TCP socket to the internet: ClamAV's documentation notes it has no authentication.
A nightly scan of the web root that only reports infected files:
sudo nice -n 19 clamscan -r -i --log=/var/log/clamscan-www.log /var/www
With the daemon running:
sudo clamdscan --multiscan --fdpass -i /var/www
clamscan exits with code 1 when it finds something, which makes it easy to wire into alerts. Avoid --remove. ClamAV's own documentation warns about false positives and suggests --move or --copy to a quarantine folder instead, so a person can review the file first.
Be realistic about coverage. ClamAV catches known malware and many common PHP web shells, but attackers often modify their code to avoid signatures. A clean ClamAV result means "nothing known was found", not "this site is clean".
Lynis: auditing the configuration
Lynis is an open-source security auditing tool from CISOfy. It runs hundreds of checks and reports warnings and suggestions; fixing them is up to you.
## Debian / Ubuntu
sudo apt install lynis
## RHEL / AlmaLinux (EPEL)
sudo dnf install lynis
sudo lynis audit system
The details go to /var/log/lynis.log and the findings to /var/log/lynis-report.dat. The summary includes a "hardening index". Treat it as a way to track progress on the same server over time, not as a grade to compare with other systems. Read the warnings first, and do not apply every suggestion blindly: some are not relevant to a web server or a database host.
Run it monthly and after major changes.
AIDE: file-integrity monitoring
AIDE (Advanced Intrusion Detection Environment) records a baseline of file attributes and hashes, then reports what was added, removed or changed.
Create the baseline
Build the baseline on a server you trust, right after setup or right after you have verified it is clean.
## Debian / Ubuntu
sudo apt install aide
sudo aideinit # builds the baseline in /var/lib/aide/
sudo aide --config /etc/aide/aide.conf --check
## RHEL / AlmaLinux 9/10 (AppStream)
sudo dnf install aide
sudo aide --init
sudo mv /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz
sudo aide --check
On Debian and Ubuntu, the package already schedules a daily check (through cron or a systemd timer, depending on the release) and emails the report to root, so make sure root's mail reaches a real person. On RHEL, Red Hat recommends at least weekly checks, preferably daily, for example from /etc/crontab:
05 4 * * * root /usr/sbin/aide --check
Keep the noise down and the baseline trustworthy
- After legitimate changes (package updates, config edits), review the report, then accept the new state with
aide --updateand move the new database into place. Without this step, real alerts drown in expected changes. - Tune the rules in
/etc/aide.conf(RHEL) or/etc/aide/aide.conf.d/(Debian/Ubuntu) to skip paths that change constantly, such as caches. - Protect the database. An attacker with root can rebuild it. Red Hat's documentation recommends keeping the database, the configuration and the
aidebinary in a secure location such as read-only media. At minimum, copy the database off the server and record its checksum (sha256sum /var/lib/aide/aide.db*) somewhere the server cannot write.
As a quick extra check, both package managers can verify installed files against package checksums: sudo dpkg --verify on Debian/Ubuntu and sudo rpm -Va on RHEL/AlmaLinux. Expect some legitimate changes to configuration files.
Rootkit checkers: useful, with limits
rkhunter looks for known rootkit files, changed system binaries and suspicious settings. Its latest release, 1.4.6, dates from February 2018. Debian, Ubuntu and EPEL still package it, but its knowledge of new threats is limited, and it is known for false positives that need tuning.
sudo apt install rkhunter # or: sudo dnf install rkhunter (EPEL)
sudo rkhunter --propupd # store current file properties as the baseline
sudo rkhunter --check --sk --rwo
Run --propupd only when you trust the system's current state, and again after package updates you have reviewed; otherwise rkhunter will flag every updated binary.
chkrootkit is a similar, older project. It is still active: its website lists version 0.59, released in January 2026, while Debian 13 ships 0.58b. It is packaged for Debian and Ubuntu (sudo apt install chkrootkit, then sudo chkrootkit).
The important limit applies to both: these tools run on the system they are checking. A rootkit that controls the kernel can hide from them. A clean result is reassuring, not proof; a warning deserves investigation, not instant panic.
A simple scanning schedule
| Check | Frequency | Where results go |
|---|---|---|
| Signature updates (freshclam) | Automatic (service) | Service status in your monitoring |
| ClamAV on web roots and uploads | Nightly | Email or ticket when exit code is 1 |
| AIDE integrity check | Daily | Email to a monitored mailbox |
| rkhunter or chkrootkit | Weekly | Email, reviewed with AIDE |
| Lynis audit | Monthly and after major changes | Reviewed and tracked over time |
Test that each alert actually reaches someone.
What to do if something is found
- Do not delete first. Quarantine the file (
--move) and keep a copy of the logs. You may need them to understand how it got there. - Judge the scope. A ClamAV hit in an upload folder may mean a malicious file was uploaded but never ran. An AIDE alert on
/usr/binor a rootkit warning suggests the attacker may have root access. - Assume the worst for system-level findings. If system binaries were replaced, the safest fix is to rebuild the server from known-good media and restore clean data from backups taken before the compromise, not to clean it in place.
- Rotate credentials that were stored on or used from that server.
- Follow your incident plan. Our guide on the first 24 hours after a data breach walks through containment and notification, and our hacked website cleanup steps cover the website side.
Get help watching your Linux servers
Setting these tools up is the easy part; reading the alerts every day is what makes them work. Core Florida IT installs, tunes and monitors malware scanning and file-integrity checks on business Linux servers in Miami-Dade, across South Florida and remotely nationwide, through our managed IT support and server setup and repair services. Request a free IT assessment and we will review what is watching your servers today.
