How to Detect Malware on Linux Server Using ClamAV —

Alright, let’s cut straight to it. Your Linux server could have malware running on it right now — and you wouldn’t even know. I’ve seen it happen more times than I can count. A client calls in, their website is redirecting visitors to some sketchy page, or their CPU is maxed out at 100% for no apparent reason, and when we dig in? Webshells, crypto miners, backdoors — the whole nine yards. All on a “secure” Linux box.

Here’s the thing: Linux servers are prime targets these days. Not because Linux is insecure — it’s not — but because the majority of the internet runs on Linux. Web servers, databases, containers, cloud instances — you name it. Attackers know this, and they’ve gotten really creative with how they compromise these systems. So if you’re not actively scanning for malware, you’re basically flying blind.

Good news? There’s a solid, free tool that does exactly what we need: ClamAV. Let me walk you through how to set it up from scratch, run effective scans, automate the whole process, and handle whatever it finds. No fluff, just the stuff that actually works.

Why Linux Servers Get Malware (And Why It Matters)

Before we jump into the commands, let’s talk about why this matters. I still run into sysadmins who think Linux is somehow immune to malware. That used to be somewhat true fifteen years ago when Linux had a tiny desktop market share. But today? Linux dominates the server world. And where there’s market share, there’s attackers.

The malware landscape for Linux has evolved significantly. We’re talking about webshells disguised as innocent PHP files, reverse shells that give attackers remote access, cryptocurrency miners that silently eat up your CPU cycles, and rootkits that hide deep in the system. Some of these are sophisticated enough to survive a reboot and even hide from basic process monitoring.

The impact on production environments is real. I’ve seen cases where a crypto miner ran undetected for three months, driving up hosting costs by thousands of dollars. I’ve seen webshells that gave attackers access to every database on the server. And the worst part? Most of these could have been caught early with a simple automated scan.

Common entry points include outdated CMS software (looking at you, WordPress plugins), weak SSH passwords, unsecured file upload forms, supply chain attacks through compromised dependencies, and shared hosting environments where one compromised account can affect others. If you’re running a production server without malware detection, you’re essentially gambling with your infrastructure.

What Is ClamAV and Why Use It?

ClamAV is an open-source antivirus engine designed for Unix-like systems. It’s been around since 2002, it’s actively maintained, and it’s used by millions of servers worldwide. It’s not the only option, but it’s arguably the best free option for Linux malware detection.

Here’s why ClamAV is worth your time:

• Free and open source — no licensing costs, whether you’re running one server or a thousand.
• Regularly updated signatures — the ClamAV Virus Database gets updated multiple times per day.
• Versatile scanning — files, directories, mailboxes, archives, embedded documents — it handles them all.
• Automation-friendly — works great with cron jobs, clamd daemon for real-time scanning, and integrates with monitoring tools.
• Massive community — if you hit an issue, someone’s already solved it and posted about it.

Now, ClamAV isn’t perfect. It’s primarily signature-based, so zero-day exploits or heavily obfuscated malware might slip through. That’s why the best approach is to combine it with other tools — but we’ll get to that later. For now, let’s get ClamAV installed and running.

Step 1: Install ClamAV on Your Distro

Installation is straightforward across most distributions. Here’s the breakdown.

Ubuntu / Debian

sudo apt update && sudo apt install clamav clamav-daemon -y

After installation, the clamav-freshclam service should automatically start updating the signature database. However, sometimes the database lock from the installation process is still active. If you see a “database is locked” error, stop the service and run the update manually:

sudo systemctl stop clamav-freshclam
sudo freshclam
sudo systemctl start clamav-freshclam

CentOS / AlmaLinux / Rocky Linux

sudo dnf install epel-release -y
sudo dnf install clamav clamav-update -y
sudo systemctl enable clamav-freshclam
sudo systemctl start clamav-freshclam

Fedora

sudo dnf install clamav clamav-update -y
sudo systemctl enable --now clamav-freshclam

Once the packages are installed, the most critical next step is updating the signature database. Don’t skip this — your detection is only as good as your signatures.

Step 2: Update the Signature Database

Even though freshclam runs automatically, always run a manual update before your first scan. The database that comes with the package could be days or weeks old depending on when it was built.

sudo freshclam

You should see output similar to:

ClamAV update process started at Tue Aug 25 10:30:00 2026
_daily.cvd database downloaded from database.clamav.net
Database updated successfully (4621857 signatures)

If you run into issues, here’s a quick troubleshooting table:

Error	Cause	Fix
“Database lock error”	Another freshclam process is running	Kill all freshclam processes, wait 30 seconds, retry
“Could not resolve host”	DNS resolution failure	Check /etc/resolv.conf, verify DNS servers are correct
“Connection timed out”	Firewall blocking outbound 80/443	Ensure ports 80 and 443 are open outbound
“403 Forbidden”	ClamAV mirror temporarily down	Wait a few hours or try a different mirror

Step 3: Run Your First Scan

Now for the main event. There are several ways to scan, depending on what you need.

Scan a Specific Directory

The most common use case — scanning your web root:

sudo clamscan -r /var/www/html/

The -r flag makes it recursive, scanning all subdirectories and files.

Scan with Verbose Output

If you want to see every file being scanned (not just infected ones):

sudo clamscan -r --verbose /var/www/html/

Warning: this produces a LOT of output. For large directories, pipe it to a log file:

sudo clamscan -r --log=/var/log/clamav/scan-$(date +%Y%m%d).log /var/www/html/

Scan Infected Files Only

My personal favorite. Show me only what’s wrong:

sudo clamscan -r --infected /var/www/ /home/ /tmp/

This gives you a clean, focused output showing only the files ClamAV flagged as malicious.

Scan a Single File

Suspect one specific file? No need to scan the whole directory:

sudo clamscan /path/to/suspicious-file.php

Auto-Quarantine Infected Files

You can have ClamAV automatically move infected files to a quarantine directory:

sudo mkdir -p /var/quarantine
sudo chmod 700 /var/quarantine
sudo clamscan -r --move=/var/quarantine/ /var/www/html/

The quarantine directory should have strict permissions — you don’t want anyone accidentally executing quarantined malware.

Auto-Delete Infected Files (Use With Caution)

ClamAV can automatically remove detected files with the --remove flag:

sudo clamscan -r --remove /path/to/scan/

Be very careful with this. False positives do happen, and you could lose important files. I recommend quarantine over deletion for production environments.

Step 4: Automate Scanning with Cron

Manual scanning is great for initial checks, but for production servers, you need automation. This is where cron jobs come in.

Open the crontab editor:

sudo crontab -e

Add this line for a daily scan at 3 AM (low-traffic hours):

0 3 * * * /usr/bin/clamscan -r --infected --log=/var/log/clamav/daily-scan.log /var/www/ /home/ /tmp/ 2>&1 | mail -s "ClamAV Daily Scan Report" admin@domain.com

Here’s what this does:

• 0 3 * * * — runs at 3:00 AM every day
• --log= — saves output to a dated log file
• 2>&1 | mail — emails the scan report (requires a working mail setup on the server)

If you don’t have a mail server configured locally, you can log to syslog instead and have your monitoring tool pick it up:

0 3 * * * /usr/bin/clamscan -r --infected --log=/var/log/clamav/daily-scan.log /var/www/ /home/ /tmp/ && logger -t clamav-scan "Daily scan completed" || logger -t clamav-scan "Daily scan failed"

For even better monitoring, integrate with tools like Grafana and Prometheus to set up alerts when malware is detected. This is the production-grade approach that gives you real-time visibility into your server’s security status.

Step 5: Real-Time Scanning with clamd

Daily cron scans have a gap — malware that arrives between scans has hours to operate undetected. The solution is clamd, the ClamAV daemon that provides real-time scanning capabilities.

Install clamd (included in the clamav-daemon package):

sudo apt install clamav-daemon -y  # Debian/Ubuntu
sudo dnf install clamav clamav-daemon -y  # RHEL-based

Edit the clamd configuration:

sudo nano /etc/clamav/clamd.conf

Make sure these settings are configured:

Example
LocalSocket /var/run/clamd.ctl
LocalSocketMode 660
User clamav
ScanPE yes
ScanELF yes
ScanOLE2 yes
ScanPDF yes
ScanHTML yes
MaxFileSize 50M
MaxScanSize 100M

Start and enable the daemon:

sudo systemctl enable --now clamd

clamd listens on the /var/run/clamd.ctl socket and can be used by applications for on-access scanning. Some web server configurations can be set up to scan uploaded files in real-time through clamd, providing immediate detection of malicious uploads.

Step 6: Handling Detected Malware

So you’ve run a scan and found something. Now what?

First, don’t panic. Verify it’s actually malware and not a false positive. Here’s how:

1. Inspect the file — open it and look at the contents. Obfuscated code, base64-encoded strings, shell_exec calls to unknown URLs — these are red flags.
2. Check the timestamp — when was the file created or modified? If it appeared recently and you didn’t deploy it, that’s suspicious.
3. Check ownership — if a file in your web root is owned by root but should be owned by www-data or nginx, investigate further.
4. Submit to VirusTotal — upload the file hash or the file itself for a second opinion from dozens of antivirus engines.

Once confirmed as malware:

1. Back up the file first — even infected files can serve as forensic evidence. You might need to analyze how it got there.
2. Isolate it — move it to the quarantine directory. Don’t delete it yet.
3. Find the entry point — this is critical. How did the malware get in? Was it an exploited vulnerability, a compromised credential, or a malicious upload? If you remove the file without fixing the vulnerability, it’ll come right back.
4. Fix the vulnerability — patch your CMS, update plugins, harden SSH, fix file permissions — whatever the entry point was.
5. Re-scan everything — make sure there aren’t additional malicious files hiding elsewhere.

Step 7: Custom Signatures for Targeted Detection

For advanced users, ClamAV supports custom signatures. This is powerful when you have specific patterns you want to detect — like a particular webshell signature unique to your environment.

Create a custom hash-based signature:

# Get MD5 hash of the suspicious file
md5sum /path/to/suspicious/file
# Output: abc123def456789... /path/to/suspicious/file

# Add it to custom signatures
echo 'abc123def456789...:0:SuspiciousWebshell' | sudo tee -a /var/lib/clamav/custom.hdb

After adding custom signatures, update ClamAV to load them:

sudo freshclam
sudo systemctl restart clamd

Custom signatures are particularly useful in shared hosting environments where you can create signatures for known malicious file patterns across multiple accounts.

Best Practice: Defense in Depth

ClamAV is a strong first line of defense, but relying on a single tool is never a good strategy. Here’s the toolkit I recommend for comprehensive Linux server security:

Tool	Purpose	Install Command
ClamAV	Malware scanning (signature-based)	apt install clamav clamav-daemon
rkhunter	Rootkit detection	apt install rkhunter
AIDE	File integrity monitoring	apt install aide
fail2ban	Brute force protection	apt install fail2ban
ModSecurity	Web application firewall	apt install libmodsecurity
OSSEC	Host-based intrusion detection	ossec-hids package

Think of it like home security. You wouldn’t just lock the front door and call it a day — you’d have locks, an alarm system, maybe cameras, and motion sensors. Same principle applies to server security. Multiple layers mean multiple chances to catch threats before they cause damage.

Don’t forget the basics either: disable unused ports, configure your firewall properly (UFW or firewalld), disable root SSH login, use key-based authentication, and keep all software updated. These fundamental steps prevent most attacks before they even reach the scanning stage.

Tips for Optimal ClamAV Performance

Running ClamAV efficiently on a production server requires some tuning. Here are the tips that make the biggest difference:

1. Exclude unnecessary directories. Scanning node_modules, vendor, or cache directories is a waste of resources. Exclude them:

sudo clamscan -r --exclude-dir="node_modules" --exclude-dir="vendor" --exclude-dir=".cache" /var/www/html/

2. Schedule scans during off-peak hours. 2 AM to 5 AM is typically the lowest traffic window. Set your cron job accordingly.

3. Use ionice for I/O priority. This prevents ClamAV scans from starving your web server of disk I/O:

ionice -c3 /usr/bin/clamscan -r --infected /var/www/html/

4. Monitor log file sizes. ClamAV scan logs can grow large. Set up logrotate to keep them in check.

5. Use clamd for repeated scans. The daemon keeps signature data in memory, making subsequent scans significantly faster than running clamscan from scratch each time.

That’s the complete rundown on detecting malware on Linux servers using ClamAV. The key takeaway is simple: don’t wait until something goes wrong. Install ClamAV today, run your first scan, set up automated daily scanning, and build a proper security monitoring workflow around it. If you find something suspicious, follow the verification and remediation steps outlined above — isolate, investigate the entry point, fix the vulnerability, and scan again.

Want to strengthen your server’s overall security posture? Check out our Linux Server Hardening Guide for 2026 for comprehensive security hardening steps. And if brute force attacks are a concern (they should be), our Complete Fail2ban Setup Guide walks you through locking down SSH and other services.

Bottom line: malware on Linux is real, it’s growing, and the cost of ignoring it is way higher than the cost of prevention. Take this seriously — your production servers, your clients, and your future self will thank you for it.