怎么在Linux利用ClamAV配置实时监控防止病毒文件上传-linux运维-PHP中文网

clamav 实时防护需依赖 clamd 守护进程配合 inotifywait 或 fanotify，禁用低效的 clamscan 轮询；必须配置 localsocket、权限及 systemd 托管，并在应用层同步校验以消除竞争窗口。

怎么在linux利用clamav配置实时监控防止病毒文件上传

ClamAV 本身不支持真正的实时监控，得靠 clamd + inotify 或第三方工具

ClamAV 命令行扫描器 clamscan 是单次扫描工具，无法监听文件变化。真正做上传防护必须启用守护进程 clamd，再配合 clamdscan 和文件系统事件机制。常见误区是直接用 clamscan --recursive 定时轮询，延迟高、资源浪费大，且根本拦不住刚写入的恶意文件。

实际可行路径只有两条：

用 clamd + inotifywait（轻量、可控，适合 Web 上传目录如 /var/www/uploads）
用 clamd + fanotify（内核级，更可靠但配置复杂，需 root 权限和较新内核）

绝大多数中小站点选第一种就够了。注意：clamd 默认不监听本地 socket，必须手动启用 LocalSocket 并设权限，否则 clamdscan 连不上。

启用 clamd 并配置 LocalSocket 路径与权限

clamd 配置文件位置因发行版而异：/etc/clamav/clamd.conf（Debian/Ubuntu）或 /etc/clamd.d/scan.conf（RHEL/CentOS）。关键要改三处：

取消注释并确认 LocalSocket /var/run/clamav/clamd.ctl（路径必须和后续脚本一致）
设置 FixStaleSocket yes，避免重启后 socket 文件残留导致启动失败
加上 User clamav（不要用 root 启动），同时确保 /var/run/clamav/ 目录属主是 clamav:clamav，权限 750

改完重启服务：sudo systemctl restart clamav-daemon（Debian）或 sudo systemctl restart clamd@scan（RHEL）。验证是否生效：sudo -u clamav clamdscan --fdpass /dev/null，返回 OK 才算通。

用 inotifywait 监控上传目录并触发 clamdscan

只监控 CREATE 和 MovedTo 事件（覆盖上传完成场景，比如 PHP 的 move_uploaded_file() 本质是 rename）。别监听 WRITE，小文件可能被扫到一半，误报率高。

示例脚本片段（保存为 /usr/local/bin/scan-on-upload.sh）：

Linux installer

先解析安全源，运行本地CLI安装、启动、卸载Linux桌面应用。用户请求时使用。

下载

#!/bin/bash
UPLOAD_DIR="/var/www/uploads"
INOTIFY_CMD="inotifywait -m -e create,moved_to --format '%w%f' $UPLOAD_DIR"
<p>$INOTIFY_CMD | while read FILE; do</p><h1>跳过临时文件（如 .part、.tmp）</h1><p>[[ "$FILE" =~ .(part|tmp|swp)$ ]] && continue</p><h1>扫描，超时 30 秒，只报病毒，静默删除（按需调整）</h1><p>if ! sudo -u clamav clamdscan --fdpass --stream "$FILE" 2>/dev/null | grep -q 'FOUND'; then
echo "$(date): OK $FILE" >> /var/log/clamav/upload-scan.log
else
echo "$(date): INFECTED $FILE" >> /var/log/clamav/upload-scan.log
rm -f "$FILE"
fi
done
</p>

用 systemd 托管这个脚本（避免挂掉）；注意 inotifywait 需要 inotify-tools 包，且单个 inotify 实例有句柄上限，默认 8192，大并发上传目录建议调高 /proc/sys/fs/inotify/max_user_watches。

Web 服务器层配合：上传前预检 or 上传后立即检查

纯 inotify 方案有竞争窗口——文件刚写入、还没来得及扫描就被 Web 程序读取了。更稳妥的做法是在应用层加一道钩子：

PHP 场景：在 move_uploaded_file() 后立刻调用 exec('clamdscan --fdpass --stream ' . escapeshellarg($tmpfile))，同步阻塞直到结果
Nginx 场景：用 upload_pass + 自定义 post-upload handler（需 Lua 模块或外部代理）

inotify 是兜底，应用层校验是主力。两者别只选一个。另外，clamdscan 的 --stream 模式比 --fdpass 更安全（避免路径穿越），但要求文件可读且不能是符号链接——上传目录的 umask 必须设为 002，让 clamav 用户能读到新文件。

病毒库更新频率、扫描超时时间、误删策略，这些没写进脚本的点，才是真正决定线上稳定性的部分。