فحص سيرفر لينكس من البرمجيات الخبيثة: الأدوات والجدولة

فحص سيرفر لينكس من البرمجيات الخبيثة يحتاج ثلاث أدوات تكمّل بعضها، لا أداة واحدة: ClamAV لفحص الملفات بالتواقيع، وMaldet (Linux Malware Detect) لاصطياد سكربتات PHP الخبيثة في مجلدات الرفع، وrkhunter لكشف الـrootkit والتعديلات على ملفات النظام. شغّلها ليلاً بين الساعة 2 و5 فجراً بأولوية منخفضة عبر nice وionice، ووجّه تقاريرها لبريدك أو لقناة تنبيهات. عند اكتشاف إصابة حقيقية لا تكتفِ بحذف الملف، اعزل السيرفر وابحث عن طريقة الدخول ثم ابنِ سيرفراً نظيفاً من الصفر وانقل البيانات بعد فحصها، لأن المهاجم الذي ترك ملفاً واحداً ظاهراً غالباً ترك بابين مخفيين.

في هذا الدليل نمر على علامات الإصابة الشائعة، وما يكشفه كل أداة وما يفوتها، وجدولة عملية لا تؤثر على الأداء وقت الذروة، وخطة الاستجابة خطوة بخطوة.

علامات الإصابة التي تراها قبل أي أداة

أغلب الإصابات على سيرفرات لينكس اليوم ليست فيروسات بالمعنى القديم، هي سكربتات تستغل ثغرة في تطبيق ويب أو كلمة مرور ضعيفة ثم تستخدم مواردك. هذه أشهر العلامات بالترتيب من الأكثر تكراراً:

• استهلاك معالج ثابت فوق 90% بعملية اسمها غريب مثل kdevtmpfsi أو xmrig أو اسم عشوائي من 8 أحرف، وهذا غالباً تعدين عملات رقمية.
• ملفات PHP داخل مجلدات الرفع مثل uploads أو storage/app/public، وفيها دوال مثل eval(base64_decode( أو gzinflate بنص مشفّر طويل.
• مهام cron لم تضفها تنزّل سكربتاً من عنوان خارجي كل دقيقة عبر curl أو wget.
• مفاتيح SSH جديدة في ~/.ssh/authorized_keys لمستخدم root أو لمستخدم التطبيق.
• اتصالات صادرة غير مفسّرة على منافذ مثل 3333 أو 4444 أو 6667، تظهر في ss -tunp.
• رسائل بريد صادرة بالآلاف من سكربت PHP، وتلاحظها حين يتأخر وصول بريدك الحقيقي لصندوق الوارد عند العملاء.

فحص سريع يدوي يأخذ أقل من 5 دقائق ويعطيك صورة أولية:

top -b -n1 | head -20
ss -tunp | grep ESTAB
crontab -l; ls -la /etc/cron.d /var/spool/cron
find /var/www -name "*.php" -path "*uploads*" -mtime -7
grep -rl "eval(base64_decode" /var/www --include=*.php | head

ClamAV وMaldet وrkhunter: ماذا يكشف كل واحد

الخطأ الشائع أن تثبّت ClamAV وحده وتعتبر السيرفر محمياً. ClamAV صُمّم أساساً لفحص المرفقات والملفات التنفيذية، وقاعدة تواقيعه ضعيفة نسبياً أمام سكربتات الويب المعدّلة يدوياً. لهذا نجمع الأدوات الثلاث:

الأداة	ما تكشفه جيداً	ما يفوتها	زمن فحص تقريبي لـ50GB
ClamAV	ملفات تنفيذية معروفة، مرفقات، أدوات تعدين مشهورة	سكربتات PHP المشفرة الجديدة	من 40 إلى 90 دقيقة
Maldet	webshells وحقن PHP وملفات في uploads	rootkit على مستوى النواة	من 20 إلى 45 دقيقة
rkhunter	rootkit، تعديل ملفات النظام مثل ls وps، منافذ مشبوهة	محتوى تطبيقات الويب	من 2 إلى 5 دقائق

تثبيت ClamAV وتحديث التواقيع

apt install clamav clamav-daemon -y
systemctl stop clamav-freshclam
freshclam
systemctl enable --now clamav-freshclam

خدمة freshclam تحدّث التواقيع تلقائياً حتى 24 مرة يومياً، والـdaemon يستهلك قرابة 1GB من الذاكرة بعد تحميل القاعدة، فإن كان سيرفرك على 2GB فقط استخدم clamscan بدون daemon وقت الفحص المجدول فقط.

Maldet مع محرك ClamAV

Maldet يقرأ تواقيع ClamAV إذا وجدها، فيصير الفحص أسرع وأدق. بعد التثبيت عدّل الملف /usr/local/maldetect/conf.maldet:

email_alert="1"
email_addr="ops@example.sa"
scan_clamscan="1"
quarantine_hits="1"
quarantine_clean="0"
scan_ignore_root="0"

خيار quarantine_hits ينقل الملف المصاب للحجر بدل حذفه، وهذا مهم لأنك تحتاج الملف لاحقاً لتعرف كيف دخل المهاجم. أما quarantine_clean فاتركه معطلاً لأن "التنظيف" التلقائي قد يكسر ملفاً سليماً حُقن فيه سطر.

rkhunter وخط الأساس

apt install rkhunter -y
rkhunter --update
rkhunter --propupd
rkhunter --check --sk --rwo

الأمر --propupd يسجّل بصمة ملفات النظام الحالية كخط أساس، فشغّله فقط على سيرفر نظيف وبعد كل تحديث للحزم، وإلا ستسجّل الملف المعدّل على أنه الأصل.

جدولة الفحص ليلاً بأقل أثر على الأداء

فحص كامل للقرص يقرأ كل بايت، وعلى قرص فيه 200GB قد يرفع زمن الاستجابة لقاعدة البيانات من 2ms إلى 30ms أثناء الفحص لو شغّلته بأولوية عادية. الحل ثلاث طبقات: توقيت ذكي، وأولوية منخفضة، وفحص تزايدي.

# /etc/cron.d/malware-scan
# فحص تزايدي يومي لملفات آخر يومين في مجلدات الويب
30 2 * * * root nice -n 19 ionice -c3 /usr/local/sbin/maldet -r /var/www 2 >/dev/null 2>&1
# فحص rkhunter يومي
15 3 * * * root /usr/bin/rkhunter --cronjob --report-warnings-only | mail -s "rkhunter $(hostname)" ops@example.sa
# فحص ClamAV كامل أسبوعياً ليلة الجمعة
0 3 * * 5 root nice -n 19 ionice -c3 clamscan -ri --exclude-dir="^/(proc|sys|dev)" / > /var/log/clamscan-weekly.log

الخيار ionice -c3 يجعل القرص يخدم الفحص فقط حين لا يطلبه أحد غيره، وnice -n 19 يعطيه أدنى أولوية على المعالج. انتبه لتوقيت السيرفر نفسه: لو كان على UTC فالساعة 2:30 عنده تعني 5:30 صباحاً بتوقيت الرياض، فاضبط المنطقة الزمنية أولاً بـtimedatectl set-timezone Asia/Riyadh حتى لا يتزامن الفحص مع بداية الدوام.

إن كنت على الاستضافة السحابية المُدارة فالفحص على مستوى الخادم ضمن الإدارة، أما على الخادم السحابي فأنت صاحب الصلاحية الكاملة والمسؤولية عن هذه الجدولة.

ماذا تفعل عند اكتشاف إصابة

أول تنبيه يجيك سيغريك بحذف الملف وإغلاق الموضوع، وهذا أكبر خطأ ممكن. اتبع هذا الترتيب:

1. لا تطفئ السيرفر فوراً، لأن الذاكرة فيها عمليات واتصالات تحتاجها للتحقيق. احفظ مخرجات ps auxf وss -tunp وlast -50 في ملف خارج السيرفر.
2. اعزل الشبكة بجدار ناري يسمح فقط بـSSH من عنوانك، حتى يتوقف التعدين أو الإرسال أو التواصل مع خادم التحكم.
3. خذ لقطة أو نسخة من القرص كما هو، فهي دليلك لمعرفة نقطة الدخول.
4. حدّد طريقة الدخول: راجع سجلات الويب حول وقت إنشاء الملف المصاب (stat يعطيك الوقت)، وابحث عن طلبات POST لمسار الملف، وراجع /var/log/auth.log لمحاولات SSH الناجحة.
5. دوّر كل الأسرار: كلمات قواعد البيانات ومفاتيح API ومفاتيح SSH، لأن ملف .env غالباً قُرئ.
6. ابنِ سيرفراً جديداً وانقل البيانات بعد فحصها، ثم أغلق الثغرة قبل إعادة التشغيل.

لماذا إعادة البناء أسلم من التنظيف

التنظيف يفترض أنك تعرف كل ما فعله المهاجم، وهذا افتراض نادراً ما يصح. في تحليلات الحوادث المنشورة، نسبة كبيرة من السيرفرات التي "نُظفت" أُصيبت مجدداً خلال 30 يوماً، لأن المهاجم يترك عادة أكثر من طريق للعودة: مستخدم نظام جديد، ومفتاح SSH، وخدمة systemd باسم يشبه خدمة حقيقية، وwebshell ثانٍ باسم بريء مثل wp-cache.php. حين يكون rootkit على مستوى النواة، حتى أوامر ls وps نفسها تكذب عليك.

إعادة البناء على خادم سحابي أصبحت رخيصة زمنياً: سيرفر جديد يتفعّل خلال ثوانٍ، وتثبيت الحزم بسكربت أو Ansible يأخذ من 10 إلى 30 دقيقة، ثم تنقل الكود من Git لا من السيرفر المصاب، وتنقل قاعدة البيانات بعد مراجعة جداول المستخدمين والصلاحيات، وتنقل ملفات الرفع بعد فحصها بـMaldet وحذف أي ملف PHP منها. باقة أساس بـ3,450 ريالاً سنوياً شامل الضريبة، أي قرابة 9.5 ريالات يومياً، وهذا أقل بكثير من كلفة يوم عمل تضيع في مطاردة باب خلفي لا تعرف مكانه.

النسخ الاحتياطي هنا خط دفاعك الأخير، لكن انتبه: النسخة التي أُخذت بعد الإصابة مصابة أيضاً. لهذا الاحتفاظ لمدة أطول مهم، وإضافة النسخ اليومي بحفظ 30 يوماً بـ2,000 ريال سنوياً تعطيك نقطة رجوع قبل تاريخ الإصابة حتى لو اكتشفتها بعد أسبوعين.

خطة عملية تطبقها هذا الأسبوع

1. ثبّت ClamAV وMaldet وrkhunter، وشغّل rkhunter --propupd بعد التأكد أن السيرفر نظيف.
2. اضبط المنطقة الزمنية ثم أضف ملف cron أعلاه مع تعديل البريد.
3. امنع تنفيذ PHP داخل مجلدات الرفع من إعدادات Nginx، وهذا وحده يوقف أغلب webshells:

   location ~* /uploads/.*\.php$ { deny all; }

4. جهّز سكربت بناء للسيرفر من الصفر واختبره مرة واحدة على سيرفر تجريبي، حتى يكون قرار إعادة البناء عند الإصابة قراراً سهلاً لا مشروعاً.
5. راجع الأسعار والباقات لإضافة النسخ الاحتياطي بحفظ 30 يوماً إن كانت بياناتك حرجة.

الفحص الدوري لا يمنع الاختراق، لكنه يقصّر المدة بين الإصابة واكتشافها من أسابيع إلى ساعات، وهذه المدة هي التي تحدد حجم الضرر.