{"id":4664,"date":"2026-09-21T02:01:12","date_gmt":"2026-09-20T20:31:12","guid":{"rendered":"https:\/\/cpanelfree.com\/blog\/configuring-clamav-and-maldet-for-real-time-malware-detection-in-shared-web-hosting\/"},"modified":"2026-09-21T02:01:12","modified_gmt":"2026-09-20T20:31:12","slug":"configuring-clamav-and-maldet-for-real-time-malware-detection-in-shared-web-hosting","status":"publish","type":"post","link":"https:\/\/cpanelfree.com\/blog\/configuring-clamav-and-maldet-for-real-time-malware-detection-in-shared-web-hosting\/","title":{"rendered":"Configuring ClamAV and Maldet for Real-Time Malware Detection in Shared Web Hosting"},"content":{"rendered":"

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<\/a> 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.<\/p>\n

<\/p>\n

Real-Time Malware Detection Architecture: Inotify Kernel Subsystems & Daemon Scanning<\/h2>\n
\n Direct Answer:<\/strong> Real-time malware detection in shared hosting combines Linux Malware Detect (Maldet) with ClamAV’s clamd daemon via the Linux inotify kernel subsystem. Inotify monitors tenant document roots for write and move file descriptors, instantly submitting new or modified files to clamd via UNIX domain sockets for sub-second signature verification and automated quarantine.\n<\/div>\n

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.<\/p>\n

At the architectural core of this design is the Linux inotify<\/code> 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<\/code>), the kernel emits specific filesystem events: primarily IN_CLOSE_WRITE<\/code> (a file opened for writing was closed) and IN_MOVED_TO<\/code> (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.<\/p>\n

Architecture Note:<\/strong> Never allow Maldet to invoke the standalone clamscan<\/code> binary for real-time monitoring. The standalone binary reloads several gigabytes of malware signature databases into memory on every single invocation, resulting in catastrophic CPU spikes and memory exhaustion. Real-time scanning must route all queries through the persistent clamd<\/code> daemon via a dedicated UNIX domain socket (\/var\/run\/clamav\/clamd.sock<\/code> or \/var\/run\/clamd.scan\/clamd.sock<\/code>).<\/div>\n

Engine Comparison: Default Maldet vs. Inotify + ClamD Integration<\/h2>\n

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:<\/p>\n\n\n\n\n\n\n\n\n\n\n
Feature \/ Metric<\/th>\nStandard \/ Default<\/th>\nTuned \/ Production<\/th>\n<\/tr>\n<\/thead>\n
Scan Engine Type<\/td>\nInternal Maldet Regex Engine<\/td>\nClamAV clamd Daemon (UNIX Socket)<\/td>\n<\/tr>\n
Detection Latency (TTR)<\/td>\n12 – 24 Hours (Cron Dwell)<\/td>\n< 350 Milliseconds (Real-Time Inotify)<\/td>\n<\/tr>\n
CPU Overhead Per Event<\/td>\nHigh (Fork overhead & DB load)<\/td>\nNegligible (< 2% IPC Socket Query)<\/td>\n<\/tr>\n
Inotify Watch Capacity<\/td>\n8,192 Watches (Kernel Default)<\/td>\n1,048,576 Watches (Custom Sysctl)<\/td>\n<\/tr>\n
Memory Footprint<\/td>\nVolatile Spikes (1.5GB\/process)<\/td>\nStable Resident (1.8GB clamd static)<\/td>\n<\/tr>\n
Quarantine Automation<\/td>\nAlert Only (Manual Intervention)<\/td>\nInstant Auto-Quarantine + Clean (0-day)<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Step 1: Kernel Tuning for High-Density Inotify Watches<\/h2>\n

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.<\/p>\n

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

# \/etc\/sysctl.d\/99-inotify-maldet.conf\n# Optimized Linux Inotify Subsystem Limits for Real-Time Multi-Tenant Scanning\n\n# Maximum directory watches allocated across all user instances (1,048,576)\nfs.inotify.max_user_watches = 1048576\n\n# Maximum inotify events allowed in the kernel queue before dropping (65,536)\nfs.inotify.max_queued_events = 65536\n\n# Maximum inotify instances that can be created per real UID (2,048)\nfs.inotify.max_user_instances = 2048<\/code><\/pre>\n
Load these parameters immediately into the active running kernel without rebooting:<\/p>\n
sysctl --system<\/code><\/pre>\n
Memory Budgeting Calculation:<\/strong> Each inotify watch consumes approximately 1,080 bytes of non-swappable kernel slab memory (on 64-bit kernels). Allocating 1,048,576 watches requires approximately 1.1 GB of RAM if fully utilized. Ensure the host has adequate physical memory before setting values above one million.<\/div>\n
Step 2: Configuring ClamAV Daemon (clamd) for High-Throughput Socket I\/O<\/h2>\n
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.<\/p>\n
Verify or modify the ClamAV daemon configuration file (typically located at \/etc\/clamd.d\/scan.conf<\/code> on RHEL\/AlmaLinux\/Rocky or \/etc\/clamav\/clamd.conf<\/code> on Debian\/Ubuntu):<\/p>\n
# \/etc\/clamd.d\/scan.conf (RHEL\/AlmaLinux) or \/etc\/clamav\/clamd.conf (Debian\/Ubuntu)\n# Production High-Throughput Daemon Configuration\n\nLogFile \/var\/log\/clamd.scan\nLogFileMaxSize 100M\nLogTime yes\nLogSyslog no\n\nLocalSocket \/var\/run\/clamd.scan\/clamd.sock\nLocalSocketMode 660\nLocalSocketGroup clamscan\n\n# Multi-threading and Concurrency Controls\nMaxThreads 16\nMaxQueue 200\nIdleTimeout 60\n\n# Scan Limits and Protection Against Decompression Bombs\nMaxFileSize 50M\nMaxScanSize 150M\nMaxFiles 1500\nMaxRecursion 10\n\n# Stream and Performance Optimization\nStreamMaxLength 50M\nReadTimeout 180\nCommandReadTimeout 30\nSelfCheck 3600\n\n# Security Scanning Modules\nScanPE yes\nScanELF yes\nScanOLE2 yes\nScanPDF yes\nScanSWF yes\nScanHTML yes\nScanArchive yes\nAlertEncrypted no<\/code><\/pre>\n
Ensure the socket directory exists with proper ownership and start the clamd service:<\/p>\n
mkdir -p \/var\/run\/clamd.scan\nchown clamscan:clamscan \/var\/run\/clamd.scan\nsystemctl enable --now clamd@scan<\/code><\/pre>\n
Step 3: Hardening Linux Malware Detect (conf.maldet) for Real-Time Execution<\/h2>\n
Maldet is the intelligent orchestration engine. It ships with specialized signatures tailored for web-hosting malware\u2014such as obfuscated PHP functions (eval(base64_decode(...))<\/code>), c99\/r57 webshells, symlink race exploits, and mail injection scripts\u2014that generic antivirus engines often overlook.<\/p>\n
Edit \/usr\/local\/maldetect\/conf.maldet<\/code> to enable the ClamAV binary engine, enforce automated quarantine, and restrict inotify scanning strictly to active web document roots:<\/p>\n
# \/usr\/local\/maldetect\/conf.maldet\n# Enterprise Production Configuration for Real-Time Inotify Monitoring\n\n# Email Alerts Configuration\nemail_alert=1\nemail_addr=\"sysadmin@cpanelfree.com\"\nemail_subj=\"[MALDET ALERT] Malware Detected & Quarantined on $(hostname)\"\n\n# Quarantine Management (Instant Neutralization)\nquarantine_hits=1\nquarantine_clean=1\nquarantine_susp=0\nquarantine_susp_minuid=1000\n\n# ClamAV Integration (Crucial for Low Latency)\nscan_clamav=1\nclamav_socket=\"\/var\/run\/clamd.scan\/clamd.sock\"\n\n# Inotify Monitoring Parameters\ninotify_nice=19\ninotify_ionice=7\ninotify_minfilesize=64\ninotify_maxfilesize=15728640\ninotify_docroot=\"public_html\"\n\n# Signature Update Scheduling & General Limits\nautoupdate_signatures=1\nautoupdate_version=1\nscan_user_access=0\nscan_ignore_root=1\nscan_tmpdir_paths=\"\/tmp \/var\/tmp \/dev\/shm\"<\/code><\/pre>\n
Crucial Tuning Directive:<\/strong> Setting inotify_docroot=\"public_html\"<\/code> is an essential architectural optimization. Without this restriction, Maldet will monitor entire home directories\u2014including massive mailbox stores (\/home\/user\/mail\/<\/code>), SSL certificates, and backup archives\u2014which rapidly exhausts inotify watches and saturates scanning queues with benign file activity.<\/div>\n
Step 4: Managing Inotify Exclusions and False Positive Mitigations<\/h2>\n
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.<\/p>\n
Configure \/usr\/local\/maldetect\/ignore_paths<\/code> to exclude volatile, non-executable directories:<\/p>\n
# \/usr\/local\/maldetect\/ignore_paths\n# Exclude High-Volume Transient Storage & Static Caches\n^\/home\/.*\/public_html\/wp-content\/cache\/.*\n^\/home\/.*\/public_html\/var\/cache\/.*\n^\/home\/.*\/public_html\/media\/cache\/.*\n^\/home\/.*\/public_html\/storage\/framework\/cache\/.*\n^\/var\/lib\/php\/session\/.*\n^\/tmp\/sess_.*<\/code><\/pre>\n
Additionally, define \/usr\/local\/maldetect\/ignore_file_ext<\/code> to bypass purely binary non-executable media files that are already validated by application-layer MIME checks:<\/p>\n
# \/usr\/local\/maldetect\/ignore_file_ext\n.jpg\n.jpeg\n.png\n.webp\n.gif\n.svg\n.woff\n.woff2\n.ttf\n.eot\n.mp4\n.mp3<\/code><\/pre>\n
Step 5: Systemd Unit Hardening with Cgroups v2 Resource Governance<\/h2>\n
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.<\/p>\n
Create the unit file at \/etc\/systemd\/system\/maldet-monitor.service<\/code>:<\/p>\n
# \/etc\/systemd\/system\/maldet-monitor.service\n[Unit]\nDescription=Linux Malware Detect (Maldet) Real-Time Inotify Monitor\nAfter=network.target clamd@scan.service\nRequires=clamd@scan.service\n\n[Service]\nType=forking\nPIDFile=\/usr\/local\/maldetect\/inotify\/inotify.pid\nExecStart=\/usr\/local\/maldetect\/maldet --monitor \/home\nExecStop=\/usr\/local\/maldetect\/maldet --kill-monitor\nRestart=on-failure\nRestartSec=10\n\n# Process Priority and I\/O Scheduling\nNice=19\nIOSchedulingClass=best-effort\nIOSchedulingPriority=7\n\n# Cgroups v2 Resource Throttling\nCPUWeight=100\nCPUQuota=150%\nMemoryHigh=2G\nMemoryMax=3G\nIOWeight=100\n\n# Security Hardening Directives\nProtectSystem=strict\nProtectHome=read-only\nReadWritePaths=\/usr\/local\/maldetect \/var\/log \/tmp\nPrivateTmp=true\nCapabilityBoundingSet=CAP_DAC_READ_SEARCH CAP_SYS_PTRACE CAP_KILL\n\n[Install]\nWantedBy=multi-user.target<\/code><\/pre>\n
Reload systemd, enable, and initiate the real-time monitoring service:<\/p>\n
systemctl daemon-reload\nsystemctl enable --now maldet-monitor.service<\/code><\/pre>\n
Step 6: Operational Verification & Malware Triage Workflow<\/h2>\n
Once activated, verify that the inotify worker is actively tracking tenant accounts and communicating with the ClamAV daemon. Inspect the Maldet inotify log:<\/p>\n
tail -f \/usr\/local\/maldetect\/logs\/inotify_log<\/code><\/pre>\n
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:<\/p>\n
echo 'X5O!P%@AP[4\\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*' > \/home\/testuser\/public_html\/eicar.php<\/code><\/pre>\n
Within 200 to 400 milliseconds, examine the primary event log at \/usr\/local\/maldetect\/logs\/event_log<\/code>. You should observe an immediate hit, followed by file relocation to \/usr\/local\/maldetect\/quarantine\/<\/code> with file permissions stripped to 0000<\/code>:<\/p>\n
[DATE] maldet(12482): {scan} file \/home\/testuser\/public_html\/eicar.php flagged as Eicar-Test-Signature\n[DATE] maldet(12482): {quar} file \/home\/testuser\/public_html\/eicar.php moved to \/usr\/local\/maldetect\/quarantine\/eicar.php.12482\n[DATE] maldet(12482): {quar} quarantine successful on \/home\/testuser\/public_html\/eicar.php<\/code><\/pre>\n
Frequently Asked Questions<\/h2>\n
\nWhy does Maldet report "inotify: no space left on device" even when disk space is free?<\/summary>\n
This error indicates that the kernel inotify watch table has been exhausted, not your physical disk. Linux returns ENOSPC<\/code> when the number of monitored directories exceeds fs.inotify.max_user_watches<\/code>. To resolve this, increase the value to 1048576<\/code> in \/etc\/sysctl.d\/99-inotify-maldet.conf<\/code> and execute sysctl --system<\/code>.<\/p>\n<\/details>\n
\nHow do I restore a false positive that was automatically quarantined?<\/summary>\n
To restore a quarantined file, run maldet --restore \/usr\/local\/maldetect\/quarantine\/filename.PID<\/code> or pass the scan report ID using maldet --restore SCAN_ID<\/code>. To prevent re-quarantine, add the file’s MD5\/SHA256 signature or absolute path to \/usr\/local\/maldetect\/ignore_file_ext<\/code> or \/usr\/local\/maldetect\/ignore_paths<\/code> before restarting the monitor.<\/p>\n<\/details>\n
\nDoes real-time inotify scanning introduce noticeable I\/O delay for website visitors?<\/summary>\n
No. The inotify subsystem operates asynchronously in kernel space. File reads (GET requests) trigger no inotify write events. Only newly created or modified files (POST uploads, CMS file saves) generate events, which are queued and verified out-of-band via the persistent clamd UNIX socket within 200-400ms without blocking PHP-FPM worker execution.<\/p>\n<\/details>\n
\nHow do ClamAV and Maldet signatures stay synchronized with new threats?<\/summary>\n
ClamAV signatures update continuously via the freshclam<\/code> daemon, pulling official Cisco Talos definitions. Maldet maintains its own automated daily cron (\/etc\/cron.daily\/maldet<\/code>) that queries R-fx Networks signature servers for real-time web-hosting threat updates, MD5 hashes, and hex pattern definitions.<\/p>\n<\/details>\n
\n
Ready to Deploy High-Performance Infrastructure?<\/h3>\n
Experience blazing-fast NVMe storage, unmetered bandwidth, and enterprise LiteSpeed caching on CpanelFree.<\/p>\n
  Get Started with Free Cloud Hosting →<\/a>\n<\/div>\n","protected":false},"excerpt":{"rendered":"
Harden multi-tenant Linux nodes against zero-day PHP shells using ClamAV and Maldet with inotify-driven, real-time malware detection.<\/p>\n","protected":false},"author":1,"featured_media":4663,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[172],"tags":[57,177,87,173,101],"class_list":["post-4664","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-security-hardening","tag-almalinux","tag-databases-performance","tag-devops","tag-security-hardening","tag-sysadmin"],"_links":{"self":[{"href":"https:\/\/cpanelfree.com\/blog\/wp-json\/wp\/v2\/posts\/4664","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/cpanelfree.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/cpanelfree.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/cpanelfree.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/cpanelfree.com\/blog\/wp-json\/wp\/v2\/comments?post=4664"}],"version-history":[{"count":0,"href":"https:\/\/cpanelfree.com\/blog\/wp-json\/wp\/v2\/posts\/4664\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/cpanelfree.com\/blog\/wp-json\/wp\/v2\/media\/4663"}],"wp:attachment":[{"href":"https:\/\/cpanelfree.com\/blog\/wp-json\/wp\/v2\/media?parent=4664"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/cpanelfree.com\/blog\/wp-json\/wp\/v2\/categories?post=4664"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/cpanelfree.com\/blog\/wp-json\/wp\/v2\/tags?post=4664"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}