Scanning for malware

What a scanner is genuinely good at

• Uploaded files. If users upload to your server, scanning the upload directory catches known malware before it is served to someone else. This is the strongest case.
• Mail. ClamAV in front of Postfix removes a large share of attachments nobody wants.
• Web shells in hosting environments. The classic PHP backdoor in an outdated CMS is well covered by signature sets.

Running ClamAV sensibly

apt install clamav clamav-daemon

freshclam keeps signatures current — check that it is actually running, because stale signatures are the usual failure.

Scan what matters rather than the whole disk:

clamdscan --fdpass /srv/uploads /var/www

Use clamdscan against the daemon rather than clamscan, which loads the entire signature database on every run and will eat your memory. Exclude /proc, /sys and your backup directory, and schedule it off-peak — a full scan is IO-heavy. See cron jobs and timers.

For hosting environments, add the Linux Malware Detect signature set; it covers web shells considerably better than the base ClamAV set.

What it misses

Be clear-eyed about this:

• Anything new or targeted. Signatures describe the past.
• Living off the land. An intruder using curl, bash and cron leaves no malicious file to find.
• A stolen credential. Nothing to scan at all.
• A kernel-level rootkit, which can simply hide from the scanner running above it.

The checks that find more, faster

In rough order of how often they catch something real:

1. Unexpected outbound traffic — the earliest and clearest signal. See understanding your traffic.
2. Listening ports you did not open — ss -ltnp, compared against a known-good list.
3. Changed system binaries — knowing when a file changed, or just debsums -c.
4. New setuid files — find / -xdev -perm -4000 -type f.
5. Cron entries and systemd units nobody added, including per-user crontabs.
6. SSH keys in authorized_keys that you do not recognise. This is how persistence is usually kept.

rkhunter and chkrootkit automate several of these. They produce false positives; read the output rather than filing it.

If something is found

Do not simply delete the file and move on. The file is a symptom; the entry point is still there. Work through a compromised server, and if mail left the machine, spam complaints covers the cleanup and the reputation repair.

Tell us as well if traffic left the machine. We would rather hear it from you than from an abuse report — see abuse notices.

---

Still stuck? Mail support@novogara.com — an engineer answers, at any hour. Back to the knowledge base