كل حالات استخدام ServerGuard

كل بند أدناه هو حالة استخدام للمعالجة. نسرد المُحفّز الذي يفتح الحادث والاستجابة التي ننفّذها.

استعادة قواعد البيانات

نراقب تنبيهات ChkServd لـ MySQL، نقرأ ملف الأخطاء الفعلي، ثم نعيد تشغيل MariaDB بأمان أو نُحيل الإجراءات الخطرة إلى موافقة المسؤول.

توقف MySQL / MariaDB

المُحفّز: تنبيه ChkServd لـ mysql أو فشل وحدة mariadb.service. نقرأ ملف الأخطاء خلال أقل من دقيقة من التنبيه.
الاستجابة: نُشخّص أربعة أسباب جذرية معروفة: تجاوز buffer pool للذاكرة المتاحة، رفض صلاحية على slow-log، فقدان auth_socket.so، وفشل تهيئة InnoDB. الثلاثة الأولى نُصلحها ونتحقق منها تلقائيًا، وتلف InnoDB يُحال إلى الموافقة قبل أي استرجاع.

ووردبريس تحت الحمل

تكدّس PHP-FPM من حلقات WP-Cron، استغلال xmlrpc.php، وفيضان زواحف البوتات الذي يستنزف بركة حساب واحد.

استهلاك CPU عالٍ بسبب تكدّس PHP-FPM

المُحفّز: ضغط مستمر على المعالج مع تراكم عمليات php-fpm في نفس البركة، أو تنبيه 360 Monitoring.
الاستجابة: نحدد حساب cPanel الذي تتكدّس عنده البركة، نمسح جدول cron من wp_options، نُفعّل DISABLE_WP_CRON، ونعيد دورة تلك البركة فقط. إعادة تشغيل الخادم بأكمله من أجل موقع واحد أداة خاطئة.

تحصين أمن ووردبريس

المُحفّز: إضافة خادم جديد، أو أي حادث أُغلق باكتشاف برمجية خبيثة على موقع ووردبريس.
الاستجابة: نُعطّل WP-Cron من جانب العميل ونستبدله بـ cron على الخادم، نمنع xmlrpc.php على مستوى .htaccess، ونرفع حد ذاكرة PHP على مواقع ea-php81 التي تحتاجه. ملف التحصين يُطبَّق لكل حساب cPanel، لا على مستوى الخادم.

صد زواحف البوتات

المُحفّز: عنوان IP واحد يُجري حجمًا غير اعتيادي من الطلبات على روابط الفلاتر (?filter_, min_price=, max_price=).
الاستجابة: نطابق user-agent بقائمة معروفة (meta-externalagent، MJ12bot، AhrefsBot)، نُضيف قاعدة Disallow إلى robots.txt، ونحجب النطاق النشط في Imunify360. المواقع بلا تخزين مؤقت تُعلَّم لتنبيه المهندس المناوب.

القرص والنسخ الاحتياطية

ضغط الـ inode والأقسام، تجاوز سياسة احتفاظ JetBackup، وملفات السجل التي تملأ /var بهدوء قبل أن يلاحظ أحد.

امتلاء القرص الحرج

المُحفّز: بريد فشل النسخ الاحتياطي أو ضغط متصاعد على الأقسام في الجذر أو /home.
الاستجابة: ندوّر السجلات الكبيرة (آمن، تلقائي)، نحذف مجموعات JetBackup الأقدم من حد الاحتفاظ (آمن)، ونُسجّل أكبر عشرة مسارات. أي إجراء يلمس محتوى /home/{user} ينتظر الموافقة.

إدارة النسخ الاحتياطية

المُحفّز: ضغط على القرص في /home أو /backup، أو بريد فشل JetBackup.
الاستجابة: نحذف مجموعات النسخ الأقدم من سبعة أيام عند وجود أكثر من أربع مجموعات (آمن، تلقائي بعد إشعار 30 دقيقة). الحذف الذي يُبقي مجموعة أو اثنتين فقط، أو إزالة ملفات أكبر من 1GB من /home، ينتظر الموافقة دائمًا.

الأمن وهجمات Brute Force

هجمات SSH وwp-login، فشل watchdog لـ csf/lfd، واكتشافات Imunify360 للبرمجيات الخبيثة التي تحتاج عزلًا وسجل تدقيق.

هجوم Brute Force على SSH

المُحفّز: فيض من محاولات SSH الفاشلة من نفس الـ /24 خلال نافذة الفحص.
الاستجابة: نتحقق من قائمة عناوين IP المسموحة للمسؤول لكل خادم أولًا، فلها الأولوية دائمًا. الشبكات الفرعية الأجنبية تُحجب عبر Imunify360 ip-list، والشبكات داخل الدولة المسجلة للمؤسسة تُحال إلى الموافقة لتجنب إقفال مسؤول مسافر. كل حجب قابل للتراجع عبر حقل rollback_command.

فشل CSF / lfd

المُحفّز: تنبيه ChkServd لـ lfd أو إنهاء lfd بإشارة 9 (بصمة تعارض Imunify360).
الاستجابة: نستعيد csf.conf من ملف reset profile عند فقدانه، نكتب version.txt إذا أسقطته ترقية الحزمة، ونُعطّل مراقبة lfd عبر whmapi1 حين يكون Imunify360 هو الجدار الفعّال. كل الأسباب الأربعة المعروفة آمنة.

اكتشاف برمجيات خبيثة

المُحفّز: تنبيه برمجيات خبيثة من Imunify360، أو موقع يُعيد التوجيه إلى نطاق مجهول رغم أن الخادم نظيف.
الاستجابة: نُشغّل فحصًا حسب الطلب على الـ docroot المتأثر، نسرد الملفات الخبيثة، ونتحقق من قواعد RewriteRule المحقونة في .htaccess. العزل وحذف الملفات يُسجَّلان في جدول التدقيق؛ حذف صفوف قاعدة البيانات في wp_posts ينتظر الموافقة.

البريد وشهادات SSL

تنظيف طوابير Exim، إجراءات الإزالة من قوائم DNSBL، وتجديد شهادات Let's Encrypt التي فاتت AutoSSL.

تضخّم طابور بريد Exim

المُحفّز: ارتفاع غير اعتيادي في طابور Exim، أو تنبيه ChkServd لـ exim.
الاستجابة: نحدد المرسل الأكبر، نمسح الرسائل المجمدة غير القابلة للتسليم، ونُبرز إصابات الـ DNSBL في التشخيص. تعليق الحساب المخترق إجراء حساس وينتظر الموافقة.

إدراج IP الخادم في القوائم السوداء

المُحفّز: ظهور الـ IP الصادر في Spamhaus ZEN أو Barracuda أو SpamCop خلال فحص دوري.
الاستجابة: نتعقّب الحساب المتسبب عبر exim_mainlog، نُحيل تعليق الحساب للموافقة، نمسح طابور البريد الصادر، ونُقدّم طلبات الإزالة لكل DNSBL مع كتابة رابط الطلب في سجل التدقيق.

فشل شهادة SSL / Let's Encrypt

المُحفّز: شهادة تنتهي خلال 14 يومًا، أو بريد فشل AutoSSL.
الاستجابة: نُعيد محاولة AutoSSL لكل مستخدم، نُصلح قواعد .htaccess التي تحجب .well-known/acme-challenge، نسمح بـ user-agent الخاص بـ ACME في ModSecurity عند تفعيل القاعدة، ونُنبّه عند وجود شهادة wildcard مدفوعة لا يمكن تجديدها تلقائيًا.

صحة المنصة

Apache وDNS وcPanel/WHM وتعليقات الحسابات وFTP وcron وOOM وNTP. السطح خارج MySQL الذي يجب أن يبقى أخضر.

فشل Apache / LiteSpeed أو إنذار خاطئ من ModSecurity

المُحفّز: تنبيه ChkServd لـ httpd، أو موجة مفاجئة من ردود 403/406 على نطاق افتراضي واحد.
الاستجابة: نُشغّل apachectl configtest، نقرأ معرّف قاعدة ModSecurity من سجل الأخطاء، ونُعطّل تلك القاعدة فقط للنطاق المتأثر. استنفاد بركة العمال وتعارض المنافذ يُعالَجان بإعادة التشغيل؛ أخطاء قراءة .htaccess تُنبّه المهندس المناوب بالسطر المخطئ.

فشل منطقة DNS

المُحفّز: موقع غير قابل للوصول لكن الخادم سليم، ويفشل dig @localhost.
الاستجابة: نُعيد تشغيل BIND عند انهيار حقيقي ونُشغّل named-checkzone على المنطقة المتعطلة. استرجاع ملفات المناطق التالفة وتعارض glue records في المسجّل تُحال إلى المهندس المناوب؛ لا نُعدّل ملفات المناطق آليًا.

أعطال cPanel / WHM المختصة

المُحفّز: تنبيهات ChkServd لـ cpaneld، فشل فحص ترخيص cPanel، أو إقفال cPHulk للـ IP الخاص بالمسؤول.
الاستجابة: نُعيد تشغيل cpaneld عند انهيار نظيف، نُعيد فحص الترخيص ضد lp.cpanel.net، ونسمح للـ IP الخاص بالمسؤول داخل cphulkd مباشرة عند منع الوصول إلى WHM. فشل إعادة بناء EasyApache يُنبّه مع آخر إعداد معروف.

تعليق حساب لتجاوز حد الموارد

المُحفّز: تحوّل حساب cPanel إلى SUSPENDED عبر cPHulk أو watchdog حدود الموارد.
الاستجابة: نسحب سبب التعليق من cphulkd_log، تاريخ الاستهلاك، ونشاط Exim الأخير. إلغاء التعليق إجراء خطر؛ ينتظر الموافقة دائمًا، ولا نُلغي تعليق حساب طابوره مليء بالبريد المزعج.

فشل خدمة FTP

المُحفّز: تنبيه ChkServd لـ pure-ftpd، أو نمط انتهاء مهلة على المنفذ 21.
الاستجابة: نُعيد تشغيل pure-ftpd عند انهيار نظيف ونفتح نطاق المنافذ السلبية في CSF عند ظهور بصمة انتهاء قناة البيانات. ضبط MaxClientsNumber وتعارض المنفذ 21 ينتظران الموافقة.

فشل خدمة cron

المُحفّز: crond متوقف خلال فحص دوري، أو وظائف مجدولة لا تُنفَّذ.
الاستجابة: نُعيد تشغيل crond عند انهيار نظيف ونُفعّل وظائف WordPress المفقودة عبر بديل الخادم الذي أعددناه لتحصين ووردبريس. الإدخالات التالفة في crontab تُنبّه بالسطر المخطئ، ولا نُعدّل crontabs المستخدمين آليًا.

OOM Killer / استنزاف الـ swap

المُحفّز: أحداث OOM في dmesg، أو ضغط متصاعد على الـ swap.
الاستجابة: نقرأ dmesg لاسم العملية المقتولة، نضبط innodb_buffer_pool_size عند سقوط MySQL، نُقلّل pm.max_children عند سقوط PHP-FPM، ونُنشئ ملف swap بحجم 2GB على المضيفات بلا swap.

NTP / انحراف الوقت

المُحفّز: انحراف زمني ملحوظ، أو أخطاء مصافحة SSL مردّها إلى انحراف الساعة.
الاستجابة: نُعيد تشغيل chronyd، نُشغّل chronyc makestep لمزامنة فورية، ونتحقق من timedatectl status بعدها. المضيفات بلا chrony تُنبّه المهندس المناوب، ولا نُثبّت حزم بدون موافقة.