دسته بندی:

دستورات پرکاربرد اسکنر CXS؛ راهنمای نصب، اسکن و قرنطینه

دستورات پرکاربرد اسکنر CXS؛ راهنمای نصب، اسکن و قرنطینه

حدود ۸ دقیقه مطالعه

پیش از هر چیز — وضعیت امروز CXS: شرکت Way to the Web، سازندهٔ ConfigServer، در ۳۱ آگوست ۲۰۲۵ فعالیتش را تعطیل کرد و فروش لایسنس، پشتیبانی و دانلود همهٔ محصولاتش از جمله cxs متوقف شد؛ دامنهٔ download.configserver.com هم دیگر اصلاً resolve نمی‌شود. یعنی امروز نصب تازهٔ cxs ممکن نیست و نسخه‌های نصب‌شده هم دیگر به‌روزرسانی امضا و وصلهٔ امنیتی نمی‌گیرند.

برخلاف CSF که درست پیش از تعطیلی تحت لایسنس GPLv3 منتشر شد و امروز چند فورک فعال دارد، برای cxs چنین اتفاقی نیفتاد و فورک نگه‌داری‌شده‌ای ندارد. بنابراین این مطلب برای کسانی نوشته شده که cxs از قبل روی سرورشان نصب است و می‌خواهند تا زمان مهاجرت از آن استفاده کنند. اگر دنبال راه‌اندازی تازهٔ اسکنر بدافزار هستید، سراغ گزینه‌های فعال بروید — مثلاً Imunify360 یا ClamAV.

یک نکتهٔ مهم دربارهٔ امضاها: ارزش هر اسکنر بدافزار به تازگی دیتابیس امضایش است. اسکنری که دیگر به‌روز نمی‌شود، بدافزارهای جدید را نمی‌شناسد؛ پس به نتیجهٔ «پاک است» آن تکیهٔ کامل نکنید.

یک اکانت روی سرور آلوده شده، فایل‌های ناشناس داخل public_html پیدا کرده‌اید و می‌دانید CXS روی سرور نصب است، اما تنها چیزی که از آن بلدید دکمه‌های افزونه‌اش در WHM است. برای اسکن هدفمند یک کاربر، یک فایل یا کل سرور، خط فرمان هم سریع‌تر است و هم کنترل بیشتری به شما می‌دهد. در ادامه، دستورات پرکاربرد اسکنر CXS همراه با پیش‌نیازها، روش اطمینان از درست کار کردن اسکن و خطاهای رایج آمده است.

اسکنر CXS چیست و چه کاری می‌کند

CXS کوتاه‌شده‌ی ConfigServer eXploit Scanner است؛ محصولی از ConfigServer Services، همان تیمی که فایروال CSF را می‌سازد. برخلاف یک آنتی‌ویروس عمومی، تمرکز CXS روی چیزی است که واقعاً روی سرورهای هاست اشتراکی اتفاق می‌افتد: وب‌شل‌ها، بک‌دورهای PHP، کیت‌های فیشینگ، فایل‌های مخربی که از راه فرم‌های آپلود آسیب‌پذیر بالا می‌روند و اسکریپت‌های قدیمی و آسیب‌پذیر. تشخیص آن ترکیبی از امضا (signature) و قواعد محتوایی روی خود فایل است و می‌تواند موتور ClamAV را هم به‌عنوان لایه‌ی ویروس‌یاب کنار خودش به کار بگیرد.

دو نکته را پیش از هر کاری بدانید: CXS یک محصول تجاری و لایسنس‌دار است و لایسنس آن به سرور گره می‌خورد؛ و CXS جایگزین فایروال، آنتی‌ویروس یا به‌روزرسانی CMS نیست، مکمل آن‌هاست.

پیش‌نیازهای اجرای دستورات

  • دسترسی root از طریق SSH؛ CXS از خط فرمان با کاربر عادی قابل استفاده نیست.
  • لایسنس فعال و متصل به همان سروری که روی آن کار می‌کنید.
  • نصب بودن CXS. با این دستور مطمئن شوید فایل اجرایی در دسترس است:
which cxs
cxs --help

خروجی cxs --help مهم‌تر از هر مرجع دیگری است، چون فهرست سوئیچ‌ها بین نسخه‌های CXS تفاوت دارد و سوئیچ‌های تک‌حرفی (مثل -T، -B، -U، -D) بیش از همه در معرض تغییرند. قاعده‌ی ساده: هیچ سوئیچی را — به‌ویژه سوئیچ‌هایی که فایل حذف یا قرنطینه می‌کنند — از روی این مقاله یا هر مقاله‌ی دیگری کورکورانه اجرا نکنید؛ اول در خروجی cxs --help همان نسخه‌ای که روی سرور نصب است ببینید دقیقاً چه کاری می‌کند.

نکته‌ی دوم: در نمونه‌های این مقاله، هرچه داخل براکت آمده ([file]، [num]، [filename]) جای‌نگه‌دار است. خودِ براکت را تایپ نکنید؛ به‌جای آن مقدار واقعی را بگذارید.

نصب CXS روی سرور

نصب CXS با اسکریپت رسمی cxsinstaller.pl انجام می‌شود و الگوی کلی آن چنین است:

cd /usr/src && wget <آدرس دقیق cxsinstaller.tgz از مستندات رسمی ConfigServer>
tar -xzf cxsinstaller.tgz
perl cxsinstaller.pl

عمداً آدرس دانلود را اینجا ننوشته‌ایم: آدرس فایل نصب محصولات ConfigServer در طول زمان عوض شده و یک URL قدیمی در بهترین حالت خطای ۴۰۴ می‌دهد و در بدترین حالت شما را به سمت یک فایل ناشناس می‌برد. خط wget را از صفحه‌ی رسمی نصب CXS یا از پنل لایسنس خودتان کپی کنید. به همین دلیل هم پاک کردن فایل‌های نصب را با الگوی * انجام ندهید؛ اگر خواستید تمیزکاری کنید، دقیقاً نام همان فایل‌ها را بنویسید.

اسکریپت نصب، ماژول‌های Perl لازم را بررسی می‌کند و در صورت وجود cPanel، افزونه‌ی آن را هم در WHM اضافه می‌کند. اگر لایسنس روی IP سرور فعال نشده باشد، نصب در همین مرحله متوقف می‌شود؛ این یکی از رایج‌ترین دلایل شکست نصب است.

دستورات پرکاربرد اسکنر CXS

اسکن بر اساس کاربر

برای اسکن هوم‌دایرکتوری یک کاربر مشخص:

cxs --user USERNAME

و برای اسکن همه‌ی کاربران سرور:

cxs --allusers

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

اسکن یک فایل یا مسیر مشخص

اگر فایل مشکوک را پیدا کرده‌اید، مسیر کامل آن را مستقیم به CXS بدهید:

cxs /path/to/file
cxs /home/USERNAME/public_html/xmlrpc.php

مسیر را دقیق و بدون فاصله بنویسید؛ اگر مسیر واقعی فاصله دارد، آن را داخل کوتیشن بگذارید: cxs "/home/USERNAME/public_html/my file.php". دادن یک مسیر پوشه به‌جای فایل هم مجاز است و کل آن شاخه اسکن می‌شود.

محدود کردن اسکن به public_html

برای این‌که فقط ریشه‌ی سایت و زیرشاخه‌های آن اسکن شود و بقیه‌ی هوم‌دایرکتوری (میل، بکاپ، فایل‌های شخصی) کنار گذاشته شود:

cxs --www [file]

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

کنترل بار سرور و اجرای پس‌زمینه

CXS سوئیچی برای محدود کردن اثر اسکن روی load سرور دارد:

cxs -T [num]

و برای اجرای اسکن در پس‌زمینه:

cxs -B

مستقل از سوئیچ‌های خود CXS، یک روش همیشه‌درست برای پایین نگه داشتن فشار اسکن روی CPU و دیسک، اجرای آن با اولویت پایین است:

nice -n 19 ionice -c3 cxs --allusers

روش دیگر و امن‌تر برای اسکن طولانی، اجرای آن داخل screen یا tmux است تا قطع شدن SSH اسکن را نصفه‌کاره رها نکند.

ثبت نتیجه در فایل لاگ

cxs --logfile [file]

خروجی اسکن به فایل موردنظر پیوست (append) می‌شود. برای اسکن‌های زمان‌بندی‌شده این سوئیچ عملاً اجباری است، وگرنه نتیجه‌ی اسکن شبانه جایی ثبت نمی‌شود.

به‌روزرسانی اسکنر

cxs -U

این دستور نسخه‌ی CXS و مجموعه‌ی قواعد آن را به‌روز می‌کند. اسکنری که ماه‌ها به‌روز نشده، شل‌های جدید را نمی‌شناسد؛ به‌روزرسانی را در کرون بگذارید.

گزارش نمونه‌ی مخرب جدید به ConfigServer

cxs --wttw [filename]

اگر فایل مخربی پیدا کرده‌اید که CXS آن را تشخیص نداده، با این سوئیچ نمونه را برای بررسی و افزوده شدن به دیتابیس امضاها ارسال می‌کنید. پیش از ارسال مطمئن شوید فایل حاوی اطلاعات محرمانه‌ی مشتری (مثل فایل کانفیگ با رمز دیتابیس) نیست.

مدیریت فایل‌های قرنطینه‌شده

cxs -D

این دستور فایل‌های قرنطینه‌شده را حذف می‌کند و برگشت‌پذیر نیست؛ خطرناک‌ترین دستور کل این مقاله همین است. پیش از اجرای آن دو کار را انجام دهید: اول محتوای مسیر قرنطینه را یکی‌یکی ببینید و مطمئن شوید هیچ فایل سالمی به‌اشتباه قرنطینه نشده، و دوم یک کپی از کل مسیر قرنطینه بگیرید (مثلاً با tar، در مسیری بیرون از هوم کاربران) تا اگر فایل سالمی قربانی شد راه برگشت داشته باشید. مسیر قرنطینه در خروجی اسکن و در پیکربندی CXS مشخص است. اگر فایلی به‌اشتباه قرنطینه شده، همان فایل را از مسیر قرنطینه به محل اصلی برگردانید و مالکیت و سطح دسترسی آن را با chown و chmod اصلاح کنید.

پایش لحظه‌ای با cxswatch و ModSecurity

اسکن دستی فقط یک عکس لحظه‌ای از وضعیت سرور می‌دهد. CXS سرویسی به نام cxswatch دارد که تغییر و ایجاد فایل را در لحظه رصد می‌کند و فایل تازه‌نوشته‌شده را همان موقع اسکن می‌کند. علاوه بر آن، CXS می‌تواند از طریق ModSecurity فایل‌هایی را که کاربران با فرم‌های وب آپلود می‌کنند، در همان لحظه‌ی آپلود بررسی کند و شل را قبل از ذخیره شدن بگیرد.

systemctl status cxswatch
systemctl restart cxswatch
systemctl enable cxswatch

اگر systemctl status cxswatch پاسخ «Unit not found» داد، یعنی نام سرویس روی نسخه یا توزیع شما فرق دارد یا پایش لحظه‌ای اصلاً فعال نشده است. با systemctl list-units --all | grep -i cxs نام واقعی سرویس را پیدا کنید و سرویسی را که مطمئن نیستید چیست، restart نکنید.

در راهنماهای قدیمی این سرویس با service cxswatch restart یا /etc/init.d/cxswatch restart مدیریت می‌شد. روی هر توزیعی که systemd دارد — AlmaLinux، Rocky Linux، Ubuntu و CentOS 7 — شکل درست همان systemctl است و فرم قدیمی فقط از راه لایه‌ی سازگاری کار می‌کند. اگر هنوز روی CentOS 6 یا ۷ هستید، هر دو به پایان پشتیبانی رسیده‌اند و مهاجرت به AlmaLinux یا Rocky Linux مقدم بر هر بحث اسکن بدافزار است.

زمان‌بندی اسکن با cron

مسیر کامل فایل اجرایی را با which cxs بگیرید و در کرون از همان مسیر کامل استفاده کنید؛ متغیر PATH در محیط کرون با محیط شل شما یکسان نیست و رایج‌ترین دلیل «اجرا نشدن اسکن شبانه» همین است.

0 3 * * 0 /usr/sbin/cxs --allusers --logfile /var/log/cxs.log

مسیر /usr/sbin/cxs فقط یک نمونه است؛ هر چیزی که which cxs روی سرور خودتان برگرداند، همان درست است و باید جایگزین شود. پیش از سپردن دستور به کرون، یک بار همان خط را دستی در SSH اجرا کنید تا مطمئن شوید بدون خطا کار می‌کند.

چطور مطمئن شویم اسکن درست کار کرده است

  • فایل لاگی که با --logfile تعیین کرده‌اید باید بعد از اسکن رشد کند؛ لاگ خالی یعنی اسکن اصلاً اجرا نشده.
  • در اسکن پس‌زمینه، با pgrep -a cxs از در حال اجرا بودن فرایند مطمئن شوید (ps aux | grep cxs خودِ دستور grep را هم در خروجی نشان می‌دهد و گمراه‌کننده است).
  • مسیر قرنطینه را بررسی کنید؛ اگر CXS چیزی پیدا کرده باشد، فایل‌ها آنجا هستند.
  • برای پایش لحظه‌ای، وضعیت سرویس را با systemctl status cxswatch ببینید.

خطاها و مشکلات رایج

  • False positive: یکی از رایج‌ترین دردسرهای CXS است. اسکریپت‌های قانونی که از eval، کد فشرده یا رمزگذاری‌شده استفاده می‌کنند، ممکن است مخرب علامت بخورند. هرگز خروجی اسکن را بدون بررسی به‌صورت گروهی حذف نکنید.
  • خطای لایسنس بعد از مهاجرت: لایسنس به سرور گره خورده؛ بعد از تغییر سرور یا IP باید لایسنس منتقل شود، وگرنه به‌روزرسانی و اسکن کار نمی‌کند.
  • بالا رفتن load هنگام --allusers: با اجرای شبانه، nice/ionice و در صورت امکان محدود کردن اسکن به --www کنترلش کنید.
  • پر شدن دیسک: مسیر قرنطینه و فایل لاگ با گذشت زمان بزرگ می‌شوند؛ برای هر دو چرخش و پاک‌سازی دوره‌ای در نظر بگیرید.

چه زمانی نباید به CXS تکیه کرد

اگر سرور همین حالا آلوده است، اسکن کردن مرحله‌ی اول است نه راه‌حل. تا وقتی نقطه‌ی ورود بسته نشده — افزونه یا قالب آسیب‌پذیر، رمز FTP لو رفته، نسخه‌ی قدیمی CMS — شل حذف‌شده ظرف چند ساعت برمی‌گردد. همچنین اجرای cxs -D روی سروری که تازه اسکن شده و نتایج آن بررسی نشده، یعنی حذف احتمالی فایل‌های سالم مشتری. ترتیب درست این است: اسکن، بررسی دستی نتایج، بستن راه نفوذ، به‌روزرسانی نرم‌افزار سایت، و بعد پاک‌سازی قرنطینه.

آموزش‌های مرتبط

خدمات مرتبط آنلاین سرور