هجوم موجَّه على لوحات تحكم الاستضافة لا يحتاج أكثر من ستة طلبات POST غير مصادَقة لزرع باب خلفي. وكلها ترد بـ HTTP 302 التي تبدو رفضاً وليست كذلك. إليك البصمة الدقيقة، وكيف تجدها في سجلاتك، والتغيير الواحد الذي يزيل فئة الهجوم بأكملها.
بصمة الهجوم إن كنت تشغّل لوحة تحكم استضافة، ابحث في سجل الوصول عن هذا التسلسل. يصل دفعةً واحدة على حساب، ثم يتكرر بعد ساعة على الذي يليه: POST /{account}/index.php?module=wordpress_manager&acc=list_domains POST /{account}/index.php?module=addons&act=wp_autologin POST /{account}/index.php?module=wordpress_manager&acc=scan_installations POST /{account}/index.php?module=domains&acc=dirlist POST /{account}/index.php?module=letsencrypt&acc=list POST /{account}/index.php?module=git_manager&acc=list_repos وخاصّتان تميّزانه كهجوم موجَّه لا مسحاً عشوائياً. يخمّن اسم الحساب أولاً. الطلب الأول في كل دفعة يستخدم اسماً مشتقاً من النطاق، مثل "exampleapp" لنطاق example.app، فيرد 404. ثم تجرّب المحاولة الثانية اسم الحساب الحقيقي فتصيب. المهاجم يعدّ الأسماء ثم ينطلق. والترتيب مقصود. معالج wp_autologin هو الحمولة: على لوحة مصابة يُنفَّذ قبل فحص الجلسة. وبقية الطلبات ترسم خريطة الهدف — عدّ النطاقات، والبحث عن تنصيبات ووردبريس، وسرد المجلدات، وحصر الشهادات، وقراءة مستودعات git. وكلها POST، فلا تظهر المعاملات في ترويسة referer ولا يبقى منها أثر في سجل المتصفح. والطلبات متباعدة بدقائق، أدنى من أي عتبة تقييد معدّل. ولماذا ستبدو سجلاتك مطمئنة كل تلك الطلبات ردّت بـ 302 على خادمنا. إعادة توجيه إلى صفحة الدخول. تبدو رفضاً لمستدعٍ غير مصادَق. ولم تكن كذلك. شفرة الوحدة نُفِّذت أولاً، ثم صدرت إعادة التوجيه. رمز الحالة يصف نهاية الطلب لا ما جرى خلاله. والدليل في حجم الرد. على تلك النقطة تكون إعادة التوجيه الحقيقية 59 بايت، وكانت ردود المهاجم بين 89 و94. شيء ما أُنتِج قبل الارتداد. grep 'wp_autologin' access_log | awk '{print $9, $10}' | sort | uniq -c حجم موحّد يعني رفضاً حقيقياً. وأحجام متفاوتة تعني أن شفرة عملت. ما يتركه المهاجم ملفات مسمّاة لتذوب بين ملفات اللوحة نفسها: cwp_login_74fde05d.php cwp_login_d17bd3ce.php مزروعة في مجلد ويب الحساب. والبادئة مختارة بدقة ليقرأها من يتصفّح المجلد كملف منصة فيمضي. ابحث عن النمط لا عن الاسم، فلاحقة التجزئة تختلف بين تنصيب وآخر: find /home -maxdepth 3 -name 'cwp_login_*.php' -o -maxdepth 3 -name 'cwp_*.php' | grep -v /usr/local الحل لا يوجد خيار إعداد يغلق هذا. الشفرة المصابة تعيش داخل اللوحة، وفي كثير من التنصيبات لا تتوفر نسخة مرقّعة أصلاً — بل قد تنشر نقطة تحديث المزوّد نفسها نسخة أقدم مما تشغّله بالفعل. فاحذف سطح الهجوم بدلاً من ذلك. في CSF، أخرج منافذ اللوحة من قائمة الوارد نهائياً: TCP_IN = "20,21,25,53,80,110,113,143,443,465,587,853,993,995,2080,2095,2096,2443" ولاحظ الغائب: 2082 و2083 و2086 و2087. لوحة المستخدم، ولوحة الإدارة، ونسختاهما المشفّرتان. لم يعد بإمكان طلب غير مصادَق بلوغ موجّه الوحدات إطلاقاً — مرقّعاً كان أم لا، بوحدة معروفة أم بأخرى تُكتشف بعد عام. طبّق بالأمر: csf -r اقرأ هذا قبل أن تنسخ ذلك السطر منفذ SSH ليس في تلك القائمة أيضاً. لا 22 ولا منفذ مخصّص. الصقها كما هي وسيُرفض اتصالك التالي، نهائياً، وبلا وصول لوحدة تحكم فعلية عند كثير من مزوّدي VPS. اختر طريق عودتك قبل التطبيق. اسمح لعنوان إداري ثابت: csf -a 203.0.113.10 "admin". فمدخلات csf.allow تتجاوز TCP_IN بالكامل، ولهذا تغطي SSH واللوحة معاً. أو استخدم خادماً وسيطاً. نحن نمرّ عبر VPS صغير بعنوان ثابت، وهو وحده المسموح. وهذا الخيار الصحيح حين يكون اتصالك بعنوان متغيّر. ولا تسمح لنطاق متغيّر تصادف أنك عليه اليوم. عنوان محطتنا تنقّل بين ثمانية عناوين في شهر واحد. فالسماح لكتلة المزوّد كاملة يُفرغ الإجراء من معناه، والسماح لعنوان واحد منها يقفل عليك غداً. وتحقّق من شبكة خارجية قبل أن تغلق الجلسة التي طبّقت التغيير، وأبقِ تلك الجلسة مفتوحة حتى تتأكد أن اتصالاً جديداً ينجح. فحصان إضافيان يستحقان التشغيل IPv6 قائمة منفصلة. فـ TCP6_IN في CSF يُضبط استقلالاً، وغالباً ما يبقى محتوياً على منافذ اللوحة. تحقّق أولاً هل يستمع شيء على IPv6 فعلاً بالأمر: ss -lnt | grep 208. فإن أظهر عمود العنوان 0.0.0.0 فالخدمة على IPv4 حصراً والقائمة السادسة خاملة. وإن أظهر [::] فتحصينك على IPv4 قابل للتجاوز، وTCP6_IN يحتاج المعاملة نفسها. كرونات الحسابات غير المميّزة. فالاقتحام نفسه ترك مهمة مجدولة تحت حساب عادي تعيد كتابة باب خلفي كل عشرين دقيقة من حمولة base64. وحذف الملف بلا معنى ما دامت الجدولة قائمة: for f in /var/spool/cron/*; do echo "== $f"; grep -vE '^\s*(#|$)' "$f"; done ما يغلقه هذا وما لا يغلقه حذف المنافذ ينهي كل هجوم غير مصادَق على اللوحة — الفئة بأكملها، دائماً، وبلا ارتهان لإصدار من المزوّد. ولا يحمي التطبيقات التي يستضيفها عملاؤك. فإضافة ووردبريس مصابة على المنفذ 443 لا يمسّها شيء من هذا. كما يكلّفك وصول عملائك المباشر للوحة عبر الإنترنت. فإن كانوا يحتاجونه وجب إعادة فتح المنافذ، وحينها تصير قاعدة WAF تحجب act=wp_autologin و acc=dirlist الحد الأدنى قبل إعادة الفتح.
