Linux Anti Malware Guide: ClamAV and Compliance Scanning

Most Linux servers in a payment or regulated estate either run no malware scanning at all or run a scanner nobody has checked in years, and both fail an audit as soon as an assessor asks for evidence. Auditors increasingly expect a reasoned answer to "do Linux servers need antivirus", backed by coverage reports, scan logs and a documented exemption process. This guide covers the compliance-driven layer: when signature scanning is required, how to run open-source scanners such as ClamAV at fleet scale, on-access versus scheduled scanning, file shares and upload paths, containers, and the evidence a PCI DSS or ISO/IEC 27001 assessor will ask for. Behavioural endpoint detection on Linux is covered in the Linux Detection and Response Guide, and this page does not repeat it. It is written for Linux, platform and security engineers who own server baselines and audit evidence. Tools are named in alphabetical order, and order is never a ranking.

Key takeaways

Scanning is the default, exemption is earned. PCI DSS v4.0.1 5.2.1 expects anti-malware on all system components unless a periodic, documented evaluation under 5.2.3 concludes a component is not at risk.
Signature scanning and EDR answer different questions. Signature scanners find known bad files at rest and in transit; behavioural tools find suspicious activity. 5.3.2 accepts either periodic plus real-time scans or continuous behavioural analysis.
Where files enter matters more than where they sit. Upload directories, SFTP landing zones, Samba and NFS shares and mail relays are where a Linux scanner protects other systems, including Windows clients.
On-access scanning has hard prerequisites. ClamAV prevention needs fanotify permission events in the kernel; without them it falls back to notify-only, which detects but cannot block.
Stale signatures are a silent failure. Unsupported scanner versions can be blocked from signature downloads, so version currency and update age need monitoring, not just a cron entry.

Do Linux servers need antivirus?

The honest answer is "it depends on the server's role and the rules you are under", and the decision has to be written down. Linux malware is real and is mostly server-side: web shells dropped through vulnerable applications (ATT&CK T1505.003 Web Shell), cryptominers (T1496.001 Compute Hijacking), tools pulled in after initial access (T1105 Ingress Tool Transfer) and ransomware built for Linux and hypervisor hosts. ATT&CK lists anti-malware as mitigation M1049 Antivirus/Antimalware; see the M1049 Antivirus/Antimalware page for how it maps across techniques, and the ATT&CK Linux, Cloud and ESXi Malware Software Hub for named families.

A Linux host also matters as a carrier. A file server or upload service that stores a Windows macro document or a malicious archive is not itself harmed, but every client that opens the file is. That is the strongest operational reason to scan on Linux, independent of compliance.

Server role	Typical malware exposure	Scanning approach
Web and application servers accepting uploads	Web shells, malicious uploads served to users	Scan the upload path on write or before the file is published; scheduled scan of web roots
File servers (Samba, NFS), SFTP and managed file transfer	Carrier for Windows and macOS malware	On-access or on-close scanning of shares, daily scheduled scan
Mail relays and gateways	Malicious attachments	Inline scanning through the MTA (for example a milter)
Internet-facing servers with interactive logins	Dropped tooling, miners, persistence	EDR or behavioural agent plus scheduled signature scans
Container hosts and Kubernetes nodes	Malicious images, miners in compromised pods	Image scanning in the pipeline, runtime protection on nodes
Single-purpose hardened appliances with no user-writable paths	Low, but reassess as threats change	Candidate for a documented "not at risk" evaluation

What the standards actually require

The PCI DSS Requirement 5 Guide covers every sub-requirement; this section shows how each lands on Linux.

5.2.1 coverage: anti-malware on all system components except those a periodic evaluation finds not at risk. On Linux the gap is usually build pipelines and auto-scaled instances that never received the agent or package. Compare the in-scope inventory with scanner check-ins monthly.
5.2.2 capability: the solution detects all known types of malware and removes, blocks or contains them. A scheduled clamscan that only logs detections meets detection; a configured --move to quarantine, or on-access prevention, provides containment.
5.2.3 and 5.2.3.1 not at risk: a documented list of components not at risk, an evaluation of evolving threats to them, and confirmation they still need no protection, at a frequency set by a targeted risk analysis under 12.3.1. "It is Linux" is not an evaluation. See the PCI DSS Customised Approach and Targeted Risk Analysis Guide.
5.3.1 automatic updates: signature databases update automatically, for ClamAV through freshclam running as a daemon or from cron.
5.3.2 and 5.3.2.1 scanning model: periodic scans plus active or real-time scans, or continuous behavioural analysis. If you rely on periodic scans, their frequency comes from a targeted risk analysis.
5.3.4 logs: anti-malware audit logs enabled and retained per 10.5.1, so scanner logs must reach the central log platform.
5.3.5 tamper resistance: users cannot disable or alter anti-malware without time-limited management authorisation. On Linux that means root-owned configuration, no user sudo rights over the scanner service, and alerting when the service stops.

Two other points shape Linux decisions. The PCI SSC FAQ on application allowlisting says allowlisting can count toward Requirement 5 only if the implementation meets all sub-requirements, because many allowlisting tools cannot detect and remove malware; allowlisting such as fapolicyd supplements a scanner rather than replacing it. Outside PCI, ISO/IEC 27001:2022 Annex A 8.7 (protection against malware), NIST SP 800-53 SI-3 Malicious Code Protection and CIS Controls v8.1 Control 10 ask for the same outcome without prescribing a scanning model. See the CIS Control 10 Malware Defenses Guide.

Choosing a scanning model

Model	What it catches	Costs and limits	Best fit
Scheduled full or incremental scan	Known malware at rest, including files written while no scanner was running	I/O and CPU load during the window; detection delay equals the interval	Every in-scope host as the baseline; evidence for 5.3.2
On-access scanning (fanotify)	Known malware at the moment a file is opened, with optional blocking	Kernel prerequisites, latency on busy directories, watch limits	Shares, upload paths, landing zones
Application-integrated scanning	Known malware in a specific file flow (upload, mail, transfer) before it is stored or served	Needs code or MTA integration; only covers that flow	Upload services, mail gateways
Pipeline scanning of images and artefacts	Known malware baked into container images and packages	Does not see what changes at runtime	Container and artefact registries
Behavioural EDR	Suspicious process, network and persistence activity, including fileless techniques	Agent licensing and tuning; covered in its own guide	Interactive and internet-facing servers

Small estates: a supported distribution package of ClamAV, freshclam as a service, a nightly incremental scan of writable paths and on-access scanning of any share is usually enough for compliance, with logs shipped to the SIEM.
Large estates: standardise one scanning profile per server role in configuration management, run a private signature mirror, and decide explicitly which roles rely on EDR behavioural analysis for 5.3.2 and which on signature scanning, so assessors see one rule rather than host-by-host exceptions.
EDR already deployed: if the EDR vendor documents malware detection and blocking on Linux and you rely on it for 5.3.2, a separate signature scanner may still be justified on file shares and upload paths, where the threat is files served to others rather than processes on the host. See EDR vs Antivirus.

Open-source scanners on Linux

These are tools, not products under review; each is described from its own documentation.

Tool	What it is	Detection content	Real-time option
ClamAV	Open-source anti-virus engine with a scanning daemon (clamd), command-line scanners (clamscan, clamdscan), an updater (freshclam) and an on-access client (clamonacc)	Official signature databases plus custom signatures	On-access scanning through fanotify
Linux Malware Detect (LMD, maldet)	GPLv2 scanner aimed at web-layer threats such as PHP shells and encoded backdoors on hosting servers	MD5, SHA-256, hex, compound and YARA signatures; can hand scanning to ClamAV	inotify monitor mode, batch-scanning queued files every 15 seconds by default
YARA	Pattern-matching tool for identifying and classifying malware by textual or binary rules	Rules you write or source	None of its own; used inside other scanners and for hunting

A common pairing on web hosting is LMD for web-shell signatures with ClamAV as its scanning engine: LMD prefers a remote clamdscan, then a local clamd, then the clamscan binary, and its installer links LMD signatures into ClamAV's data directory. YARA is better treated as a hunting and incident response tool than as the scanner of record for compliance.

Running ClamAV at fleet scale

Daemon, clients and sockets

clamscan vs clamdscan: clamscan builds a new engine and loads the full database each time it runs, which is slow and memory-heavy on every invocation. clamdscan sends work to a running clamd, which keeps the database loaded. Use clamdscan for anything scheduled or repeated.
Socket exposure: set LocalSocket in clamd.conf (it is disabled by default) and restrict LocalSocketMode, because the default socket permissions are world-accessible. The ClamAV docs warn not to expose the clamd TCP socket to the internet because it does not authenticate traffic; if you use TCPSocket for a central scanning service, bind it to a private interface and firewall it.
Permissions: clamd's user must be able to read what it scans. Rather than running clamd as root, use clamdscan --fdpass, where the client opens each file and passes the descriptor over the Unix socket (not available over TCP).
Throughput: --multiscan spreads directory scans across clamd worker threads; tune MaxThreads and MaxQueue against the host's CPU budget.
Response: prefer --move or --copy to a quarantine directory over --remove, as the docs advise, because false positives happen. Use the VirusEvent directive to raise an alert on each detection.

Signature updates and version currency

freshclam: run it as a daemon (freshclam -d) or from cron. The ClamAV docs suggest a minute between 3 and 57 that is not a multiple of 10, because round minutes are heavily used. Set NotifyClamd so clamd reloads after updates.
Private mirror: large fleets and segmented networks should not have every host pull from the public CDN, where downloads are rate-limited per public IP. The documented options are cvdupdate (mirrors CVD and CDIFF files; serve them with a production web server that supports HTTP Range requests) or a freshclam mirror. Clients point DatabaseMirror at a cvdupdate mirror, or use PrivateMirror with ScriptedUpdates no for a freshclam mirror. Set DNSDatabaseInfo no where clients have no internet DNS.
Supported versions: ClamAV long-term support releases receive at least three years of support plus a further year of signature access, and end-of-life versions may be blocked from downloading official signatures. Track the version matrix and keep to the latest patch version, or an old fleet will quietly stop updating.
Proxy credentials: if freshclam uses HTTPProxyPassword, restrict freshclam.conf permissions, since the password sits in the file.

On-access scanning

Prerequisites: Linux kernel 3.8 or later, fanotify with CONFIG_FANOTIFY_ACCESS_PERMISSIONS enabled for blocking, and clamonacc running with elevated privileges alongside clamd. Without permission events the scanner runs notify-only.
Scope: list directories with OnAccessIncludePath; / is rejected because prevention on the root filesystem could lock up the system. Subdirectories are tracked through inotify, whose default watch limit of 8,192 may need raising on deep trees.
Prevention: OnAccessPrevention yes blocks access to detected files. The docs note prevention can seriously affect performance on busy directories, so pilot it on a share before enabling it widely.
Exclusions: set OnAccessExcludeUname to clamd's own user to avoid scan loops, and use OnAccessExcludePath sparingly. Record every exclusion with an owner and review date; see the EDR Tuning and Exclusions Management Guide for the governance pattern.

File shares, uploads and containers

Upload paths: write uploads to a quarantine directory, scan with clamdscan, then move clean files to the served location. Never serve directly from the upload directory. See the File Upload Security Guide.
Samba and NFS: on-access scanning on the file server protects every client, including Windows endpoints, but sizing matters: estimate open-file rates at peak and test latency before enabling prevention.
Container images: scan image file systems in the build pipeline or registry alongside vulnerability scanning, so malware is caught before deployment. See Container Image Scanning vs SCA.
Running containers: containers are short-lived and usually immutable, so an in-container scanner adds little; protect the node and rely on runtime protection for behaviour. See Container Runtime Protection vs Host EDR.
Persistent volumes: volumes that accept user content are file shares by another name; scan them on a schedule from a dedicated job with read-only mounts.

How to implement

Classify roles: map every in-scope Linux host to a role from the table above, and decide per role whether it is scanned, covered by behavioural EDR for 5.3.2, or a candidate for a "not at risk" evaluation.
Write the targeted risk analyses: one for the periodic scan frequency (5.3.2.1) and one for the evaluation frequency of exempt components (5.2.3.1), approved before rollout.
Stand up updates first: deploy the private mirror and freshclam configuration, and confirm clients update before any scanning starts.
Deploy in detect-only mode: push clamd and scheduled clamdscan jobs through configuration management with logging only, to a pilot ring of non-critical hosts per role, for two to four weeks. Review detections and false positives.
Enable containment: switch scheduled scans to quarantine moves and enable on-access prevention on pilot shares, measuring file-open latency before and after.
Roll out by ring: extend to production rings, internet-facing and upload hosts first.
Roll back cleanly: keep prevention behind a configuration flag so you can return a share to notify-only by changing OnAccessPrevention and restarting clamonacc, without removing detection or logging.
Prove it: drop the EICAR test file into each protected path and confirm detection, quarantine and the SIEM alert end to end.

Detection and measurement

Log sources: clamd and clamonacc logs (enable LogTime and log rotation), freshclam update logs, scheduled scan summaries, and service stop events from systemd. Forward all to the central platform and retain per 10.5.1. See the Linux Logging and auditd for Defenders Guide.
Alert on: any detection, scanner service stopped, signature age above threshold, on-access client exited, and configuration file changes (pair with the Linux File Integrity Monitoring Guide).

Metrics that show the programme works:

Coverage: percentage of in-scope Linux hosts reporting a healthy scanner or approved behavioural agent (target 100 per cent, with exemptions documented).
Signature freshness: percentage of hosts with databases updated in the last 24 hours.
Scan completion: percentage of scheduled scans that completed in the window over the last 30 days.
Exemption currency: percentage of "not at risk" evaluations reviewed within their risk-analysis frequency.
Time to triage: median hours from detection to analyst decision.
Version currency: hosts on a scanner version inside the vendor support window.

Common failure patterns

The blanket Linux exemption: declaring all Linux "not at risk" with no list, no threat evaluation and no review date. It fails 5.2.3 on first reading.
clamscan in cron on every host: reloading the full database per run causes memory spikes that get the job disabled, and nobody notices the scans stopped.
Frozen signatures: an end-of-life scanner version blocked from updates, or a mirror that stopped syncing, while dashboards still show the service running.
Notify-only mistaken for prevention: on-access configured on a kernel without fanotify permission events, so detections are logged but access is never blocked.
Exposed scanning service: a clamd TCP socket reachable beyond the hosts that need it, or a world-writable local socket.
Exclusions that swallow the risk: excluding upload or web-root paths for performance, which are precisely where web shells land.

Framework mapping

Framework	Reference	What this guide supports
PCI DSS v4.0.1	5.2.1 to 5.2.3.1, 5.3.1 to 5.3.5	Coverage, exemptions, updates, scanning model, logs, tamper resistance
NIST SP 800-53 Rev 5	SI-3, SI-3(4), SI-4, CM-7	Malicious code protection, privileged-only updates, monitoring, least functionality
NIST CSF 2.0	PR.PS-05, DE.CM-09	Preventing unauthorised software, monitoring runtime environments
CIS Controls v8.1	Control 10 Malware Defenses	Deploying, updating and centrally managing anti-malware
ISO/IEC 27001:2022	Annex A 8.7	Protection against malware
MITRE ATT&CK v20	M1049; T1505.003, T1496.001, T1105	Mitigation and the Linux techniques scanning helps detect

Where identity fits

Scanning infrastructure holds its own non-human identities: the clamd service account, mirror credentials, proxy passwords in freshclam.conf, and any service account a central scanning job uses to mount shares. Give each a dedicated, non-interactive account with read-only access to what it scans, keep credentials out of world-readable files, and review them with other service accounts. See How to Detect Service Account Misuse.

Practitioner checklist

Every in-scope Linux host is mapped to a role and a scanning model.
"Not at risk" components are listed, threat-evaluated and reviewed at a frequency set by a targeted risk analysis.
freshclam (or the vendor updater) runs automatically from a private mirror, and signature age is alerted on.
Scheduled scans use clamdscan against a running clamd, with quarantine rather than deletion.
Shares and upload paths have on-access scanning, with prevention enabled after a latency pilot.
The clamd socket is local with restricted permissions, or a TCP socket bound to a private, firewalled interface.
Exclusions have an owner, a reason and a review date.
Scanner logs, update logs and service stops reach the SIEM and are retained per 10.5.1.
Scanner versions stay inside the supported window.
EICAR tests run after every change and quarterly.

Linux Anti Malware Guide: Compliance Scanning for Servers, Containers and File Shares