من قلب السيرفر: دليلك الكامل للتعامل مع اختراق ووردبريس واستعادة موقعك كالمحترفين

أذكرها جيداً تلك الليلة. كانت الساعة تقارب الثانية صباحاً، وأنا أغوص في سطور كود لمشروع ذكاء اصطناعي معقد. رنّ الهاتف، رقم غريب. على الطرف الآخر كان صوت شاب مرتبك، بالكاد يجمع كلماته: “أستاذ أبو عمر؟ أنا فلان، صاحب متجر ‘زيتون بلادي’. الموقع… الموقع راح!”.

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

قلت له: “اهدأ يا خوي، خذ نفس عميق. الفوضى والتسرع هم أكبر أعدائك الآن. خلينا نمشي خطوة خطوة، وإن شاء الله بترجع الأمور أحسن من أول”. في تلك اللحظة، تحولت من مبرمج إلى طبيب جراح رقمي، والمريض هو سيرفر ينزف بيانات. هذه القصة ليست فريدة من نوعها، بل هي كابوس يتكرر مع الكثيرين. واليوم، سأشارككم خارطة الطريق التي اتبعتها تلك الليلة، والتي أتبعها دائماً في مثل هذه المواقف الحرجة.

المرحلة الأولى: التشخيص الجنائي (Forensics) – فك شيفرة الفوضى

قبل أن تحذف ملفاً واحداً أو تثبّت أي إضافة حماية، يجب أن تفهم ماذا حدث. العرض الظاهر (إعلانات، بطء، إعادة توجيه) هو مجرد حمّى، أما الفيروس الحقيقي فمختبئ في أعماق النظام. هنا تبدأ مهمة المحقق الرقمي.

استنطاق سجلات الوصول (Access Logs): أول خيط في القضية

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

نصيحة أبو عمر: لا تعتمد على إحصائيات ووردبريس أو Google Analytics. نريد الحقيقة الخام من قلب السيرفر. مكان هذه السجلات عادة يكون في /var/log/nginx/access.log أو /var/log/apache2/access.log.

ابحث عن الأنماط المريبة:

  • طلبات POST غريبة: هل ترى طلبات POST كثيرة تستهدف ملفات لا يفترض أن تستقبل بيانات، مثل ملفات الصور في wp-content/uploads أو ملفات PHP بأسماء عشوائية (مثل x8fGz.php)؟ هذه علامة خطر كبرى.
  • عناوين IP نشطة بشكل مفرط: هل هناك عنوان IP واحد يرسل مئات الطلبات في دقائق معدودة؟ قد يكون هذا هو المخترق أثناء تحميل ملفاته الخبيثة.
  • استهداف ملفات حساسة: ابحث عن طلبات تستهدف xmlrpc.php أو wp-login.php بشكل متكرر، فهذه محاولات تخمين لكلمات المرور.

البحث عن “الجواسيس” – الملفات المعدلة حديثاً

بعد أن كوّنت فكرة أولية من السجلات، حان وقت البحث عن الأدلة المادية. عبر اتصال SSH بالسيرفر، سنبحث عن أي ملفات تم إنشاؤها أو تعديلها مؤخراً. الأمر find هو صديقك الصدوق هنا.

للبحث عن كل الملفات التي تم تعديلها في آخر يومين (48 ساعة):

find . -type f -mtime -2

ركّز بحثك في المجلدات التالية:

  • /wp-content/uploads: المكان المفضل للمخترقين لرفع الـ “Shells” أو الأبواب الخلفية، لأن ووردبريس بطبيعته يسمح برفع الملفات إلى هذا المجلد.
  • /wp-content/plugins و /wp-content/themes: قد يضيف المخترق ملفات خبيثة داخل مجلدات الإضافات والقوالب لتبدو كأنها جزء منها.
  • /wp-includes والمجلد الرئيسي: في الحالات المتقدمة، قد يتم تعديل الملفات الأساسية لووردبريس.

مراقبة استهلاك الموارد: من يسرق قوة السيرفر؟

هل اشتكى لك العميل من بطء شديد في الموقع؟ افتح أداة مراقبة العمليات مثل htop أو top عبر الـ Terminal.

htop

انظر إلى قائمة العمليات. هل ترى عملية PHP تستهلك 99% أو 100% من المعالج (CPU)؟ هذا ليس طبيعياً أبداً. غالباً ما يكون هذا سكريبت خبيث يقوم بأحد أمرين:

  1. تعدين العملات الرقمية (Crypto Mining): يستغل قوة معالج سيرفرك لتعدين عملات رقمية لحساب المخترق.
  2. إرسال البريد العشوائي (Spamming): يستخدم سيرفرك كمنصة لإرسال آلاف رسائل السبام.

إذا وجدت عملية كهذه، سجل معرّفها (PID) ومسار السكريبت الذي تعمل عليه. هذا دليل ثمين.

المرحلة الثانية: العزل والحجر الصحي – وقف النزيف فوراً

الآن بعد أن تأكدت من وجود اختراق وجمعت بعض الأدلة، يجب أن توقف الضرر فوراً. لا تبدأ بالتنظيف بعد، بل قم بعزل الموقع لمنع المخترق من إحداث المزيد من الفوضى أو سرقة المزيد من البيانات.

إغلاق الأبواب: وضع الصيانة من قلب السيرفر

لا تعتمد على إضافة “Maintenance Mode” من ووردبريس، فقد تكون هي نفسها مخترقة أو قد يعطلها المخترق. العزل الحقيقي يتم من مستوى السيرفر.

استخدم ملف .htaccess (إذا كنت تستخدم Apache) لقطع الوصول عن الجميع باستثناء عنوان الـ IP الخاص بك.

# .htaccess
Order Deny,Allow
Deny from all
Allow from YOUR_IP_ADDRESS

استبدل YOUR_IP_ADDRESS بالـ IP الخاص بك (يمكنك معرفته بالبحث في جوجل عن “what is my ip”). الآن، أنت فقط من يستطيع الوصول للموقع.

تغيير الأقفال: تجميد الحسابات وقطع الجلسات

تصرف وكأن كل كلمات المرور قد سُرقت:

  • غيّر كلمة مرور مدير ووردبريس (جميع حسابات الأدمن).
  • غيّر كلمة مرور قاعدة البيانات (من لوحة تحكم الاستضافة ثم قم بتحديثها في ملف wp-config.php).
  • غيّر كلمة مرور حساب الـ FTP/SFTP.
  • غيّر كلمة مرور لوحة تحكم الاستضافة (cPanel, Plesk, etc.).

نصيحة أبو عمر الحاسمة: تغيير كلمة المرور لا يكفي لطرد المخترق إذا كان لا يزال مسجلاً دخوله. لقطع جميع الجلسات فوراً، اذهب إلى ملف wp-config.php وغيّر قيم مفاتيح التشفير والأمان (Salts). يمكنك توليد مفاتيح جديدة من هذا الرابط الرسمي. بمجرد حفظ الملف، سيتم تسجيل خروج جميع المستخدمين فوراً.

نزع سلاح المجلدات الخطرة

المخترقون يعشقون مجلد wp-content/uploads لأنه قابل للكتابة. حتى لو قمت بتنظيفه، قد يتمكنون من رفع ملف PHP خبيث مرة أخرى. لمنع هذا، أنشئ ملف .htaccess داخل مجلد uploads وضع فيه الكود التالي لمنع تنفيذ أي ملف PHP بداخله:

# /wp-content/uploads/.htaccess
<Files "*.php">
Deny from all
</Files>

هذه الخطوة وحدها كفيلة بصدّ نسبة كبيرة من محاولات الاختراق المستقبلية.

المرحلة الثالثة: الاستئصال والتنظيف – عملية جراحية دقيقة

الآن، الموقع معزول وأنت المتحكم الوحيد. حان وقت التنظيف العميق.

قاعدة “لا تثق بأحد”: استبدال ملفات الووردبريس الأساسية

لا تحاول أبداً “تنظيف” ملفات ووردبريس الأساسية (مجلدي wp-admin و wp-includes) يدوياً. قد يكون المخترق قد خبأ كوداً خبيثاً في سطر يصعب تمييزه. الحل الوحيد الموثوق هو الاستبدال الكامل:

  1. قم بتحميل نسخة نظيفة وجديدة من ووردبريس من موقع wordpress.org.
  2. على السيرفر، احذف مجلدي wp-admin و wp-includes بالكامل.
  3. قم برفع المجلدين الجديدين من النسخة النظيفة التي حملتها.
  4. استبدل باقي الملفات في المجلد الرئيسي (مثل index.php, wp-login.php, etc.) بالملفات الجديدة، باستثناء ملفي wp-config.php و .htaccess ومجلد wp-content.

تنظيف الملفات الحساسة: wp-config.php و .htaccess

افتح هذين الملفين يدوياً وافحصهما سطراً بسطر. في .htaccess، ابحث عن أي قواعد إعادة توجيه غريبة. في wp-config.php، ابحث عن أي دوال مشبوهة مثل eval(), base64_decode(), gzinflate() أو أي استدعاء لملفات غير معروفة عبر include أو require.

التدقيق اليدوي في مجلد wp-content

هذا هو الجزء الأصعب. افحص مجلدات plugins و themes. أي إضافة أو قالب تشك فيه، احذفه وأعد تثبيته من المصدر الرسمي. افحص ملفات القالب النشط، خصوصاً functions.php, header.php, footer.php، فهي أهداف شائعة لحقن الأكواد الخبيثة.

نصيحة أبو عمر: استخدم الأمر grep للبحث عن نصوص مشبوهة داخل كل الملفات. على سبيل المثال، للبحث عن دالة eval المشفرة:

grep -r "eval(base64_decode" .

سيظهر لك هذا الأمر قائمة بكل الملفات التي تحتوي على هذا النمط الخطير.

فحص قاعدة البيانات: البحث عن الخلايا النائمة

قد يترك المخترق باباً خلفياً في قاعدة البيانات:

  • جدول wp_users: افحصه جيداً. هل هناك أي مستخدم بصلاحيات مدير (Administrator) لم تقم أنت بإنشائه؟ احذفه فوراً.
  • جدول wp_posts: ابحث عن أي أكواد <script> محقونة داخل محتوى المقالات والصفحات.
  • جدول wp_options: تحقق من قيمتي siteurl و home. وأيضاً ابحث عن أي خيارات Options تحتوي على أكواد خبيثة.

دراسة حالة: محاكاة اختراق “الفارماسيا” (Pharma Hack)

هذا سيناريو حقيقي تعاملت معه. اتصل بي صاحب موقع لشركة استشارات، وقال إن فريقه للتسويق الرقمي (SEO) أبلغه أن الموقع يظهر في نتائج بحث جوجل بروابط لبيع أدوية، لكن عندما يزورون الموقع مباشرة، يبدو كل شيء طبيعياً.

  • التشخيص: دخلت إلى السيرفر وفتحت ملف .htaccess. وجدت كوداً معقداً يقوم بالتحقق من “وكيل المستخدم” (User-Agent). إذا كان الزائر هو “Googlebot” (عنكبوت بحث جوجل)، يتم توجيهه لصفحة أخرى مليئة بروابط الأدوية. أما إذا كان زائراً عادياً، فيرى الموقع الطبيعي. هذا يسمى “Cloaking” (الإخفاء)، وهو سبب عدم ملاحظة العملاء للمشكلة.
  • العزل: قمت فوراً بتفعيل وضع الصيانة من السيرفر.
  • الحل:
    1. حذفت الكود الخبيث من .htaccess.
    2. استخدمت grep -r "HTTP_USER_AGENT" . للبحث عن مصدر هذا الكود، فوجدت ملف functions.php في القالب يحتوي على كود مشفر يقوم بحقن هذه القاعدة في .htaccess كل فترة.
    3. قمت باستبدال مجلد القالب بالكامل بنسخة نظيفة من مستودع Git الخاص بالمشروع.
    4. غيرت مفاتيح التشفير (Salts) في wp-config.php كإجراء احترازي أخير.

بعد هذه الخطوات، وطلب إعادة الفهرسة من Google Search Console، عاد الموقع نظيفاً تماماً في نتائج البحث خلال أيام.

الخلاصة: الوقاية خير من ألف علاج 🩹

التعامل مع الاختراق ليس معركة أدوات بقدر ما هو معركة منهجية وإجراءات. الهدوء في تشخيص السجلات، والصرامة في عزل الصلاحيات، والدقة في استبدال الملفات، هي المثلث الذهبي لعودة موقعك إلى الحياة. تذكر دائماً يا صديقي: النسخة الاحتياطية النظيفة والمحفوظة خارج السيرفر (Off-site Backup) هي طوق النجاة وخط الدفاع الأخير الذي لا يمكن التفريط فيه.

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

أبو عمر

سجل دخولك لعمل نقاش تفاعلي

كافة المحادثات خاصة ولا يتم عرضها على الموقع نهائياً

آراء من النقاشات

لا توجد آراء منشورة بعد. كن أول من يشارك رأيه!

آخر المدونات

التوظيف وبناء الهوية التقنية

سيرتي الذاتية عبرت فلتر الـ ATS لكنها فشلت أمام المدير التقني: كيف أعدت بناءها لتتحدث لغة المهندسين؟

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

28 فبراير، 2026 قراءة المزيد
التوسع والأداء العالي والأحمال

خدمة واحدة فاشلة كادت أن تسقط النظام بأكمله: كيف أنقذني نمط ‘قاطع الدائرة’ (Circuit Breaker) من كارثة متتالية؟

أتذكر ذلك اليوم جيداً، حين كادت خدمة واحدة أن تتسبب في انهيار نظامنا بالكامل في ليلة نهاية أسبوع مزدحمة. في هذه المقالة، أشارككم قصة حقيقية...

27 فبراير، 2026 قراءة المزيد
اختبارات الاداء والجودة

لقد ‘هاجمت’ تطبيقي بنفسي عمداً: كيف كشفت لي ‘هندسة الفوضى’ نقاط الضعف التي لم تظهرها الاختبارات التقليدية

أشارككم قصة حقيقية حول إطلاق فاشل كاد أن يدمر سمعتنا، وكيف قادتنا هذه التجربة المريرة إلى تبني "هندسة الفوضى" (Chaos Engineering). اكتشفوا معنا كيف يمكن...

26 فبراير، 2026 قراءة المزيد
التوسع والأداء العالي والأحمال

عاصفة من الطلبات كادت أن تغرق تطبيقي: كيف أنقذتني طوابير الرسائل (Message Queues) من كارثة الجمعة السوداء؟

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

24 فبراير، 2026 قراءة المزيد
البودكاست