نصب و فعال کردن آنتی‌ویروس ClamAV در cPanel

برای نصب ClamAV در cPanel امروز هیچ چیزی را از سورس کامپایل نمی‌کنید: کافی است افزونه‌ی clamavconnector را از WHM نصب کنید تا cPanel خودش باینری‌ها، سرویس clamd و کرونِ به‌روزرسانی امضاها را برایتان بسازد. خودِ نصب چند کلیک بیشتر نیست؛ بخش سخت ماجرا این است که بدانید این آنتی‌ویروس دقیقاً چه چیزی را می‌گیرد و چه چیزی را نمی‌گیرد — و اینکه وقتی همین سرویس باعث شد آپلود فایل در کنترل‌پنل با خطا برگردد، چه کار درستی باید بکنید.

ClamAV چه چیزی را می‌گیرد و چه چیزی را نمی‌گیرد

ClamAV موتوری امضامحور است: فایل را با دیتابیسی از نمونه‌های شناخته‌شده مقایسه می‌کند و اگر تطابقی نبود، فایل را سالم اعلام می‌کند. این تفاوت را جدی بگیرید:

• معمولاً می‌گیرد: بدافزارهای پخش‌شده به‌صورت انبوه — پیوست‌های آلوده‌ی ایمیل در مسیر Exim (که فیلتر هرزنامه‌ی آن را SpamAssassin تکمیل می‌کند؛ راه‌اندازی آن روی دایرکت‌ادمین را در نصب SpamAssassin در دایرکت ادمین آورده‌ایم)، وب‌شل‌های پرتکرار PHP در public_html، بک‌دُرهای قالب و افزونه‌ی نال‌شده، و فایل‌های آلوده‌ی ویندوزی که کاربر آپلود کرده است.
• معمولاً نمی‌گیرد: بدافزار هدفمند یا تازه‌نوشته‌شده، کدی که با چند لایه مبهم‌سازی برای هر سایت متفاوت تولید می‌شود، حمله‌هایی که فایلی روی دیسک نمی‌گذارند، و سوءاستفاده از رمز یا کلید لو رفته.

پس ClamAV یک صافی است، نه ضمانت؛ اگر توقع دارید بعد از نصبش دیگر سایتی هک نشود، توقع اشتباهی دارید.

نصب و فعال کردن در cPanel

در WHM (بخش مدیریتی سی‌پنل) وارد مسیر cPanel > Manage Plugins شوید. در این صفحه فهرست افزونه‌های رسمی cPanel را می‌بینید؛ افزونه‌ی clamavconnector را پیدا کنید، گزینه‌ی Install and keep updated را تیک بزنید و ذخیره کنید. نصب چند دقیقه طول می‌کشد و در این فاصله لازم نیست کاری بکنید.

یک نکته‌ی مهم درباره‌ی راهنماهای قدیمی: بعضی از آن‌ها می‌گویند بعد از نصب افزونه، آپاچی را ریستارت کنید. این کار نه لازم است و نه اثری دارد؛ ClamAV سرویس مستقلی به نام clamd است و هیچ ربطی به وب‌سرور ندارد. تنها جایی که واقعاً چیزی باید بازسازی شود مسیر ایمیل است، آن هم وقتی گزینه‌های اسکن را در Exim Configuration Manager تغییر بدهید که خودِ cPanel پیکربندی Exim را می‌سازد و سرویس را بالا می‌آورد.

در همان راهنماها آمده که پس از نصب، آیتمی به نام Configure ClamAV Scanner زیر بخش Plugins در WHM ظاهر می‌شود. اگر چنین آیتمی را در نسخه‌ی امروزی WHM نمی‌بینید نگران نباشید و دنبالش نگردید؛ پیکربندی مؤثر موتور در فایل /usr/local/cpanel/3rdparty/etc/clamd.conf است، اسکن ایمیل از WHM > Exim Configuration Manager کنترل می‌شود و اسکن دستی هم از ابزار Virus Scanner کاربر یا از خط فرمان انجام می‌شود.

اگر ترجیح می‌دهید از خط فرمان کار کنید، روی سرورهای مبتنی بر RPM مثل AlmaLinux و CloudLinux همین دو دستور کافی است:

/usr/local/cpanel/scripts/update_local_rpm_versions --edit target_settings.clamav installed
/usr/local/cpanel/scripts/check_cpanel_pkgs --fix --targets=clamav

دستور اول به cPanel می‌گوید ClamAV باید نصب باشد و دستور دوم واقعاً نصبش می‌کند. اگر در راهنمایی قدیمی نام check_cpanel_rpms را دیدید، همان اسکریپت است که در نسخه‌های امروزی cPanel به check_cpanel_pkgs تغییر نام داده و دیگر با نام قبلی روی سرور وجود ندارد. این کار دسترسی روت می‌خواهد؛ یعنی فقط روی سرور مجازی یا اختصاصی خودتان با لایسنس معتبر cPanel شدنی است و روی هاست اشتراکی چنین دسترسی‌ای ندارید.

همه چیز زیر شاخه‌ی /usr/local/cpanel/3rdparty/ نصب می‌شود: باینری‌ها در bin/، پیکربندی در etc/ و دیتابیس امضاها در share/clamav/. نسخه‌ی جداگانه‌ای از مخزن توزیع نصب نکنید؛ دو نصب موازی فقط تداخل می‌سازد.

روش قدیمیِ کامپایل از سورس را کنار بگذارید

راهنماهای قدیمی می‌گویند clamav-0.99.2.tar.gz را دانلود کنید، ./configure --disable-zlib-vcheck بزنید، make install کنید و بعد یک اسکریپت init برای CentOS 6 یا CentOS 7 بگیرید. هر چهار قدم این مسیر امروز غلط است:

• شاخه‌ی 0.99 و حتی 0.103 به پایان پشتیبانی رسیده‌اند و نسخه‌های منسوخ از دریافت امضاهای جدید مسدود می‌شوند. حاصلش یک آنتی‌ویروسِ ظاهراً نصب‌شده با دیتابیسی است که سال‌ها به‌روز نشده.
• ClamAV در شاخه‌ی 1.x با CMake ساخته می‌شود، نه با ./configure؛ پس آن دستورها اصلاً اجرا نمی‌شوند.
• CentOS 6 و CentOS 7 و CentOS 8 هر سه EOL هستند و cPanel امروز روی AlmaLinux و CloudLinux و Ubuntu اجرا می‌شود؛ Rocky Linux هم از فهرست سیستم‌عامل‌های پشتیبانی‌شده‌ی cPanel کنار گذاشته شده است. اسکریپت‌های SysV آن راهنماها روی این سیستم‌ها معنایی ندارند.
• باینری دست‌ساز در /usr/local با نسخه‌ای که cPanel مدیریت می‌کند تداخل پیدا می‌کند.

اگر ترجیح می‌دهید اصلاً درگیر این جزئیات نشوید، روی VPS مدیریت‌شده نصب و پیکربندی کنترل‌پنل و عیب‌یابی نرم‌افزارهای نصب‌شده بر عهده‌ی تیم ارائه‌دهنده است.

بررسی کنید که واقعاً کار می‌کند

cPanel یونیت /etc/systemd/system/clamd.service را می‌سازد، پس systemctl status clamd کار می‌کند و برای راه‌اندازی مجدد هم /usr/local/cpanel/scripts/restartsrv_clamd در دسترس است. اما مهم‌تر از «سرویس بالاست»، دیدن موتور و دیتابیس با هم است: دستور /usr/local/cpanel/3rdparty/bin/clamdscan --version نسخه و شماره و تاریخ دیتابیسی را چاپ می‌کند که همین حالا در حافظه‌ی دیمن بارگذاری شده — دقیقاً همان چیزی که باید بدانید — و اگر آن تاریخ مربوط به هفته‌ها قبل بود، عملاً آنتی‌ویروس ندارید. (اگر دیمن بالا نباشد همین سوئیچ روی /usr/local/cpanel/3rdparty/bin/clamscan --version نسخه و دیتابیس روی دیسک را نشان می‌دهد.) برای دیدن پیکربندی مؤثر هم /usr/local/cpanel/3rdparty/bin/clamconf کمک می‌کند.

در سمت کاربر، ابزار Virus Scanner در بخش Advanced کنترل‌پنل ظاهر می‌شود و کاربر می‌تواند پوشه‌ی خانگی یا ایمیل‌هایش را اسکن کند؛ گزینه‌های اسکن بدافزار ایمیل هم در زبانه‌ی Security از WHM > Exim Configuration Manager فعال‌شدنی می‌شوند و زبانه‌ی Filters فقط به فیلتر سیستمی و پیوست‌های خطرناک مربوط است.

اگر سایت شما روی سرویس اشتراکی مثل هاست وردپرس ایران است، هیچ‌کدام از این تنظیم‌های سطح سرور دست شما نیست؛ آن لایه‌ها را ارائه‌دهنده مدیریت می‌کند و کار شما امن نگه‌داشتن خود سایت است.

تازه نگه‌داشتن امضاها با freshclam

افزونه خودش یک رکورد کرون برای کاربر روت اضافه می‌کند که روزی یک بار freshclam را اجرا می‌کند؛ با crontab -l می‌توانید ببینیدش. cPanel مقدار DatabaseMirror را هم در /usr/local/cpanel/3rdparty/etc/freshclam.conf روی آینه‌ی خودش تنظیم می‌کند، نه CDN عمومی. این تنظیم را دستکاری نکنید و فرکانس به‌روزرسانی را بی‌دلیل بالا نبرید؛ درخواست بیش از حد به آینه‌های عمومی می‌تواند به مسدود شدن آی‌پی سرور منجر شود.

برای عیب‌یابی، تاریخ main.cld و daily.cld را در /usr/local/cpanel/3rdparty/share/clamav/ ببینید. اگر daily.cld کهنه بود، یک بار freshclam را دستی و بدون --quiet اجرا کنید تا خطای واقعی را ببینید. شایع‌ترین دلایل شکست: بسته بودن ترافیک خروجی در فایروال، پر شدن دیسک، و مالکیت نادرست پوشه‌ی دیتابیس که باید متعلق به کاربر clamav باشد.

اسکن دستی از خط فرمان

راهنماهای قدیمی برای اسکن سرور می‌گویند وارد SSH شوید، cd /home بزنید و clamscan -vr را اجرا کنید. این دستور واقعاً اجرا می‌شود، اما بدترین شکل ممکن برای اسکن یک سرور زنده است: clamscan دیمن را نادیده می‌گیرد و کل دیتابیس امضاها را از نو در حافظه می‌خواند، و خروجی‌اش به‌طور پیش‌فرض برای هر فایل سالم هم یک خط OK چاپ می‌کند که سوئیچ -v آن را پرگوتر هم می‌کند؛ حاصل صدها هزار خط خروجی است که پیدا کردن آن یک خط آلوده در میانش شانسی می‌شود. معادل درست امروزی این است — به cd هم نیازی نیست، مسیر را مستقیم بدهید:

/usr/local/cpanel/3rdparty/bin/clamdscan -i --fdpass /home/username

معنای سوئیچ‌ها:

• -i (معادل --infected) فقط فایل‌های آلوده و خلاصه‌ی پایانی را چاپ می‌کند؛ یعنی دقیقاً برعکس کاری که -v می‌کند.
• --fdpass فایل را از طریق file descriptor به دیمن می‌دهد؛ بدون آن، اگر clamd با کاربر خودش اجرا شود و اجازه‌ی خواندن پوشه‌ی خانگی کاربران را نداشته باشد، انبوهی خطای دسترسی می‌گیرید.
• -l /var/log/clamdscan.log خروجی را در فایل هم نگه می‌دارد؛ برای اسکن کرونی لازم است.
• کد خروجی دستور معنادار است: 0 یعنی چیزی پیدا نشد، 1 یعنی آلودگی پیدا شد و 2 یعنی خودِ اسکن به خطا خورد. در اسکریپت کرون به همین کد نگاه کنید، نه به متن خروجی.

اگر clamd بالا نیست یا عمداً نمی‌خواهید سراغش بروید، نسخه‌ی بدون دیمن همین کار را می‌کند؛ فقط کندتر و پرمصرف‌تر است:

/usr/local/cpanel/3rdparty/bin/clamscan -ri /home/username

یک هشدار جدی: سوئیچ --remove را روی دیتای کاربران اجرا نکنید. ClamAV مثبت کاذب دارد و یک تطابق اشتباه روی یک فایل سالمِ سایت، بدون هیچ راه بازگشتی، آن را پاک می‌کند. اگر می‌خواهید کار خودکار باشد از --move به یک پوشه‌ی قرنطینه‌ی خارج از دسترس وب استفاده کنید و بعد خودتان نگاه کنید.

زمان‌بندی اسکن و هزینه‌ی واقعی آن

این بخش معمولاً دست‌کم گرفته می‌شود. سرویس clamd کل دیتابیس امضاها را در حافظه نگه می‌دارد و این دیتابیس امروز چند صد مگابایت است؛ در عمل انتظار داشته باشید بیش از یک گیگابایت رم فقط صرف همین سرویس شود و با بزرگ‌تر شدن دیتابیس بالاتر هم برود. چند قاعده بار را قابل تحمل نگه می‌دارد:

• clamdscan را جایگزین clamscan کنید؛ اولی از دیمنِ از قبل بارگذاری‌شده استفاده می‌کند و دومی هر بار کل دیتابیس را از نو می‌خواند.
• اسکن را با nice و ionice و در کم‌ترافیک‌ترین ساعت شبانه‌روز اجرا کنید؛ اسکن کامل یک سرور پر از سایت بیش از آنکه CPU بخواهد، دیسک را اشباع می‌کند.
• به‌جای اسکن سراسری /home، هر شب چند حساب را نوبتی اسکن کنید.
• برای کنار گذاشتن مسیرهای کش و بکاپ حواستان به ابزار باشد: سوئیچ --exclude-dir فقط گزینه‌ی clamscan است و clamdscan چنین سوئیچی ندارد؛ استثناهای دیمن را باید با دستورِ ExcludePath در clamd.conf تعریف کنید.
• اگر clamd به فایل‌های کاربران دسترسی ندارد، سوئیچ --fdpass را به clamdscan بیفزایید.
• اسکن هنگام دسترسی با clamonacc روی سرور شلوغ گران است؛ پیش از فعال‌سازی اثرش را روی لود اندازه بگیرید.

وقتی آپلود در cPanel با Access denied شکست می‌خورد

عارضه‌ای که بعد از فعال کردن ClamAV روی سرور زیاد گزارش می‌شود این است که آپلود فایل در کنترل‌پنل با پیام Access denied. ERROR برمی‌گردد. پیش از هر کاری مطمئن شوید مقصر واقعاً ClamAV است؛ پر شدن دیسک سرور، تمام شدن سهمیه‌ی (quota) حساب و مالکیت غلط پوشه‌ی خانگی هم می‌توانند آپلود را با خطای دسترسی رد کنند. اگر df -h و وضعیت کوتای حساب سالم بودند، سراغ clamd بروید.

الگو ساده است: تا وقتی clamd نصب و فعال است اما پاسخ نمی‌دهد — متوقف شده، کرش کرده یا سوکتش در دسترس نیست — عملیاتی که منتظر جواب اوست به‌جای ادامه دادن با خطا برمی‌گردد. پس اول وضعیت و لاگ سرویس را ببینید:

systemctl status clamd
journalctl -u clamd --since "1 hour ago"

راه دم‌دستی خاموش و روشن کردن سرویس از خود WHM هم هست: در Service Configuration > Service Manager گزینه‌ی clamd را پیدا کنید، تیک Enabled را بردارید و ذخیره کنید، بعد دوباره برگردید و تیک را بزنید و ذخیره کنید. ارزش این کار بیشتر تشخیصی است: اگر با خاموش بودن clamd آپلود درست شد، دیگر شک ندارید که مشکل از همین سرویس است. از خط فرمان اما تمیزتر و سریع‌تر است:

/usr/local/cpanel/scripts/restartsrv_clamd

در راهنماهای قدیمی دو دستور دیگر هم برای ریستارت پیشنهاد شده که تکلیفشان باید روشن شود. clamd restart اصلاً دستور معتبری نیست؛ clamd خودِ باینری دیمن است و آرگومان restart نمی‌گیرد؛ این خط کاری را که انتظار دارید انجام نمی‌دهد. service clamd restart هم روی سیستم‌های امروزی فقط پوسته‌ای است که درخواست را به systemd می‌سپارد؛ اگر می‌خواهید مستقیم بنویسید:

systemctl restart clamd

روی سرور تحت cPanel ترجیح با restartsrv_clamd است، چون همان مسیری است که خودِ پنل برای مدیریت و مانیتور سرویس‌ها استفاده می‌کند و وضعیت سرویس در Service Manager با واقعیت یکی می‌ماند.

حالا سؤال اصلی: چرا clamd می‌میرد؟ روی سرورهای کوچک شایع‌ترین دلیل حافظه است. همان‌طور که در بخش قبل گفتیم این سرویس بیش از یک گیگابایت رم فقط برای نگه‌داشتن دیتابیس امضاها می‌گیرد؛ روی یک VPS کم‌رم که MySQL و PHP هم رویش اجرا می‌شوند، clamd گزینه‌ی پرمصرفی است و معمولاً همان چیزی است که مکانیزم OOM کرنل قربانی می‌کند. اما حدس نزنید، نگاه کنید:

free -m
journalctl -k | grep -iE "out of memory|killed process|oom-kill"

روی توزیع‌های خانواده‌ی RHEL همین رد را در /var/log/messages و روی اوبونتو در /var/log/syslog هم می‌بینید. اگر نشانه‌ی OOM پیدا کردید، ریستارت دوباره‌ی سرویس فقط مسئله را چند ساعت عقب می‌اندازد: یا باید رم سرور را بالا ببرید، یا بپذیرید که این سرور جای اجرای دائمی clamd نیست و اسکن را به‌صورت زمان‌بندی‌شده با clamscan انجام بدهید.

و یک هشدار درباره‌ی راه‌حل رایجی که در انجمن‌ها تکرار می‌شود: «تیک clamd را بردار و دیگر روشنش نکن تا آپلود کار کند». این پاک کردن صورت‌مسئله است. سروری که سرویس آنتی‌ویروسش خاموش مانده، نه اسکن ایمیل دارد نه ابزار Virus Scanner کاربر کار می‌کند، و شش ماه بعد کسی به تصور اینکه سرور آنتی‌ویروس دارد تصمیم اشتباه می‌گیرد. اگر واقعاً به این نتیجه رسیده‌اید که ClamAV روی این سرور نمی‌ارزد، افزونه را از همان Manage Plugins حذف کنید تا وضعیت سرور شفاف باشد.

کارهایی که بیشتر از آنتی‌ویروس جواب می‌دهند

تجربه‌ی عملی می‌گوید بیشتر سایت‌های آلوده قربانی «ویروس» نشده‌اند، بلکه از یک افزونه‌ی به‌روزنشده یا یک دسترسی بازِ فایل ضربه خورده‌اند. اگر سرور همین حالا آلوده است هم پاک کردن تک‌تک شل‌ها معمولاً جواب نمی‌دهد، چون مهاجم راه بازگشتی برای خودش گذاشته؛ مسیر مطمئن‌تر بازسازی سرور و بازگرداندن از یک بکاپ سالم است و بهتر است پیش از هر تغییری با تیم پشتیبانی و مدیریت سرور مشورت کنید، چون حرکت اشتباه در این مرحله شواهد نفوذ را از بین می‌برد. فارغ از این، چند کار زیر اثر بیشتری از ClamAV دارند:

• سطح دسترسی فایل‌ها: فایل‌ها 644، پوشه‌ها 755، پیکربندی حساسی مثل wp-config.php محدودتر، و هرگز 777. اجرای PHP را هم در پوشه‌های آپلود ببندید.
• به‌روز بودن CMS: هسته، قالب و افزونه‌ها را به‌موقع به‌روز کنید و افزونه‌ی نال‌شده نصب نکنید؛ هیچ آنتی‌ویروسی جای این کار را نمی‌گیرد.
• فایروال و رمزهای قوی: یک فایروال CSF درست پیکربندی‌شده جلوی بخش بزرگی از تلاش‌های ورود را می‌گیرد، و با بررسی آخرین تغییر رمز کاربران می‌توانید حساب‌هایی را که سال‌هاست رمزشان عوض نشده پیدا کنید.
• بکاپ تغییرناپذیر: نسخه‌ی پشتیبان باید جایی باشد که کاربر وب‌سرور نتواند در آن بنویسد یا پاکش کند، ترجیحاً بیرون از همان سرور. بکاپی که تست بازیابی نشده، بکاپ نیست.

جمع‌بندی ساده است: ClamAV را نصب کنید، چون هزینه‌اش کم و سود آن در برابر بدافزارهای انبوه واقعی است؛ اما آن را لایه‌ی اول بدانید، نه آخرین خط دفاع.