Configuring ClamAV and Maldet for Real-Time Malware Detection in Shared Web Hosting

In high-density shared web hosting environments, passive periodic malware scans are fundamentally inadequate for defending against modern zero-day PHP webshells, automated backdoor injections, and rapid credential stealers that execute within milliseconds of upload. Deploying Linux Malware Detect (LMD / Maldet) paired with the resident ClamAV clamd scanning engine provides an autonomous, real-time event-driven defense layer across thousands of virtual hosts without saturating NVMe storage arrays or exhausting CPU cycles. System administrators managing robust platforms like CpanelFree rely on kernel-level inotify hooks to intercept malicious files at the exact moment of creation, neutralizing payloads before web servers can parse or deliver them.

Real-Time Malware Detection Architecture: Inotify Kernel Subsystems & Daemon Scanning

Traditional hosting security models rely on scheduled nightly or weekly cron jobs executing recursive filesystem scans. On servers hosting hundreds or thousands of tenant accounts with millions of collective inodes, this approach introduces two catastrophic failures: massive dwell time (attackers have hours or days of uninterrupted execution) and severe I/O starvation during scan execution. Real-time scanning solves both issues by shifting from an exhaustive crawl model to an event-driven notification paradigm.

At the architectural core of this design is the Linux inotify API, which extends the VFS (Virtual Filesystem Switch) layer. When an application (such as an Apache or LiteSpeed worker running PHP-FPM, or an FTP daemon like Pure-FTPd) creates or modifies a file within any tenant document root (/home/*/public_html), the kernel emits specific filesystem events: primarily IN_CLOSE_WRITE (a file opened for writing was closed) and IN_MOVED_TO (a file was moved or uploaded into the directory). The Maldet inotify monitoring daemon intercepts these file descriptors and dispatches the corresponding paths directly to the ClamAV scanning engine.

Engine Comparison: Default Maldet vs. Inotify + ClamD Integration

Deploying real-time detection without deep kernel and engine tuning can cripple server responsiveness. The matrix below contrasts standard out-of-the-box configurations against an enterprise-grade tuned implementation running on multi-tenant NVMe clusters:

Step 1: Kernel Tuning for High-Density Inotify Watches

The standard Linux kernel limits inotify watches to 8,192 directories per user. In a production shared hosting server with 500 to 2,000 cPanel or DirectAdmin users, each having complex WordPress, Joomla, or Drupal installations, the required directory watch count easily exceeds 500,000 directories. If the inotify watch table overflows, the kernel silently drops filesystem events, rendering real-time protection completely blind.

Apply the following persistent kernel parameter overrides in /etc/sysctl.d/99-inotify-maldet.conf to allocate sufficient memory structures for enterprise-scale real-time monitoring:

# /etc/sysctl.d/99-inotify-maldet.conf
# Optimized Linux Inotify Subsystem Limits for Real-Time Multi-Tenant Scanning

# Maximum directory watches allocated across all user instances (1,048,576)
fs.inotify.max_user_watches = 1048576

# Maximum inotify events allowed in the kernel queue before dropping (65,536)
fs.inotify.max_queued_events = 65536

# Maximum inotify instances that can be created per real UID (2,048)
fs.inotify.max_user_instances = 2048

Load these parameters immediately into the active running kernel without rebooting:

sysctl --system

Step 2: Configuring ClamAV Daemon (clamd) for High-Throughput Socket I/O

ClamAV must be configured as a multi-threaded daemon listening on a local UNIX domain socket. This eliminates the latency and overhead of TCP network handshakes while ensuring permissions match the Maldet execution context.

Verify or modify the ClamAV daemon configuration file (typically located at /etc/clamd.d/scan.conf on RHEL/AlmaLinux/Rocky or /etc/clamav/clamd.conf on Debian/Ubuntu):

# /etc/clamd.d/scan.conf (RHEL/AlmaLinux) or /etc/clamav/clamd.conf (Debian/Ubuntu)
# Production High-Throughput Daemon Configuration

LogFile /var/log/clamd.scan
LogFileMaxSize 100M
LogTime yes
LogSyslog no

LocalSocket /var/run/clamd.scan/clamd.sock
LocalSocketMode 660
LocalSocketGroup clamscan

# Multi-threading and Concurrency Controls
MaxThreads 16
MaxQueue 200
IdleTimeout 60

# Scan Limits and Protection Against Decompression Bombs
MaxFileSize 50M
MaxScanSize 150M
MaxFiles 1500
MaxRecursion 10

# Stream and Performance Optimization
StreamMaxLength 50M
ReadTimeout 180
CommandReadTimeout 30
SelfCheck 3600

# Security Scanning Modules
ScanPE yes
ScanELF yes
ScanOLE2 yes
ScanPDF yes
ScanSWF yes
ScanHTML yes
ScanArchive yes
AlertEncrypted no

Ensure the socket directory exists with proper ownership and start the clamd service:

mkdir -p /var/run/clamd.scan
chown clamscan:clamscan /var/run/clamd.scan
systemctl enable --now clamd@scan

Step 3: Hardening Linux Malware Detect (conf.maldet) for Real-Time Execution

Maldet is the intelligent orchestration engine. It ships with specialized signatures tailored for web-hosting malware—such as obfuscated PHP functions (eval(base64_decode(...))), c99/r57 webshells, symlink race exploits, and mail injection scripts—that generic antivirus engines often overlook.

Edit /usr/local/maldetect/conf.maldet to enable the ClamAV binary engine, enforce automated quarantine, and restrict inotify scanning strictly to active web document roots:

# /usr/local/maldetect/conf.maldet
# Enterprise Production Configuration for Real-Time Inotify Monitoring

# Email Alerts Configuration
email_alert=1
email_addr="[email protected]"
email_subj="[MALDET ALERT] Malware Detected & Quarantined on $(hostname)"

# Quarantine Management (Instant Neutralization)
quarantine_hits=1
quarantine_clean=1
quarantine_susp=0
quarantine_susp_minuid=1000

# ClamAV Integration (Crucial for Low Latency)
scan_clamav=1
clamav_socket="/var/run/clamd.scan/clamd.sock"

# Inotify Monitoring Parameters
inotify_nice=19
inotify_ionice=7
inotify_minfilesize=64
inotify_maxfilesize=15728640
inotify_docroot="public_html"

# Signature Update Scheduling & General Limits
autoupdate_signatures=1
autoupdate_version=1
scan_user_access=0
scan_ignore_root=1
scan_tmpdir_paths="/tmp /var/tmp /dev/shm"

Step 4: Managing Inotify Exclusions and False Positive Mitigations

Shared hosting nodes generate immense volume in transient cache and session directories. If WordPress cache plugins (like LiteSpeed Cache, WP Super Cache, or W3 Total Cache) write thousands of static HTML and CSS fragments every second, they can overwhelm the inotify event pipe. Sysadmins must define targeted exclusions to maintain system efficiency.

Configure /usr/local/maldetect/ignore_paths to exclude volatile, non-executable directories:

# /usr/local/maldetect/ignore_paths
# Exclude High-Volume Transient Storage & Static Caches
^/home/.*/public_html/wp-content/cache/.*
^/home/.*/public_html/var/cache/.*
^/home/.*/public_html/media/cache/.*
^/home/.*/public_html/storage/framework/cache/.*
^/var/lib/php/session/.*
^/tmp/sess_.*

Additionally, define /usr/local/maldetect/ignore_file_ext to bypass purely binary non-executable media files that are already validated by application-layer MIME checks:

# /usr/local/maldetect/ignore_file_ext
.jpg
.jpeg
.png
.webp
.gif
.svg
.woff
.woff2
.ttf
.eot
.mp4
.mp3

Step 5: Systemd Unit Hardening with Cgroups v2 Resource Governance

To prevent the real-time scanning agent from impacting web traffic during sudden surges of file modifications (such as automated WordPress updates or mass Git deployments), wrap the Maldet monitoring process in a hardened systemd unit file with strict CPU and I/O limits using Linux Cgroups v2.

Create the unit file at /etc/systemd/system/maldet-monitor.service:

# /etc/systemd/system/maldet-monitor.service
[Unit]
Description=Linux Malware Detect (Maldet) Real-Time Inotify Monitor
After=network.target [email protected]
[email protected]

[Service]
Type=forking
PIDFile=/usr/local/maldetect/inotify/inotify.pid
ExecStart=/usr/local/maldetect/maldet --monitor /home
ExecStop=/usr/local/maldetect/maldet --kill-monitor
Restart=on-failure
RestartSec=10

# Process Priority and I/O Scheduling
Nice=19
IOSchedulingClass=best-effort
IOSchedulingPriority=7

# Cgroups v2 Resource Throttling
CPUWeight=100
CPUQuota=150%
MemoryHigh=2G
MemoryMax=3G
IOWeight=100

# Security Hardening Directives
ProtectSystem=strict
ProtectHome=read-only
ReadWritePaths=/usr/local/maldetect /var/log /tmp
PrivateTmp=true
CapabilityBoundingSet=CAP_DAC_READ_SEARCH CAP_SYS_PTRACE CAP_KILL

[Install]
WantedBy=multi-user.target

Reload systemd, enable, and initiate the real-time monitoring service:

systemctl daemon-reload
systemctl enable --now maldet-monitor.service

Step 6: Operational Verification & Malware Triage Workflow

Once activated, verify that the inotify worker is actively tracking tenant accounts and communicating with the ClamAV daemon. Inspect the Maldet inotify log:

tail -f /usr/local/maldetect/logs/inotify_log

To safely test the end-to-end detection and quarantine pipeline without introducing real malicious code, inject an EICAR test string into a dummy tenant document root:

echo 'X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*' > /home/testuser/public_html/eicar.php

Within 200 to 400 milliseconds, examine the primary event log at /usr/local/maldetect/logs/event_log. You should observe an immediate hit, followed by file relocation to /usr/local/maldetect/quarantine/ with file permissions stripped to 0000:

[DATE] maldet(12482): {scan} file /home/testuser/public_html/eicar.php flagged as Eicar-Test-Signature
[DATE] maldet(12482): {quar} file /home/testuser/public_html/eicar.php moved to /usr/local/maldetect/quarantine/eicar.php.12482
[DATE] maldet(12482): {quar} quarantine successful on /home/testuser/public_html/eicar.php

Frequently Asked Questions