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

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

من الدقيقة 0 لـ 5: اتأكد إنه اختراق فعلا ووقف النزيف

متبدأش بالتنضيف. ابدأ بإنك تفهم أنت بتشوف إيه، لأن في مشاكل بسيطة شكلها اختراق، وفي اختراقات خطيرة شكلها عادي.

علامات الاختراق الحقيقي

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

مشاكل شكلها اختراق وهي مش كده

شهادة SSL منتهية، أو تحديث إضافة فشل وطلع شاشة بيضا، أو تغيير في الـ DNS ماتمش لحد آخره، أو ذاكرة PHP خلصت، كل دول بيطلعوا أعراض مخيفة. اتأكد من الأساسيات الأول: افتح الموقع في نافذة خاصة، واقرا نص الخطأ في المتصفح، واسأل آخر واحد اشتغل على الموقع عمل إيه. خمس دقايق فحص هتوفر عليك إعلان حالة طوارئ بسبب تحديث باظ.

أول قرار: وقف الموقع للجمهور

لو الموقع بيوزع فيروسات أو بيحول الزوار أو بيسحب بيانات كروت، وقفه عن الجمهور فورا. ده مش فشل، ده القرار الصح. موقع واقف ساعتين تكلفته أقل بكتير من موقع بيعدي العدوى لعملائك يومين وبعدين يتحط في القائمة السودا أسبوعين. أنضف طريقة إنك تعمل صفحة صيانة من السيرفر نفسه أو من الـ CDN، مش من إضافة جوا الموقع المخترق. لو بتستخدم Cloudflare فعل وضع Under Attack أو اعمل قاعدة في الفايروول تمنع كل الزيارات إلا الـ IP بتاعك. ولو مش عارف، اطلب من الاستضافة توقف الدخول العام وتسيب لك الوصول بالـ SSH أو الملفات.

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

من الدقيقة 5 لـ 15: احفظ الأدلة قبل ما تلمس أي حاجة

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

خد نسخة كاملة من الوضع الحالي

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

نزل اللوجات قبل ما تتمسح

كتير من الاستضافات بتدور اللوجات القديمة وتمسحها في أيام. نزلها دلوقتي. محتاج لوج الدخول على السيرفر (access log)، ولوج الأخطاء، ولوج PHP، ولو متاح لوج SSH وFTP وسجل دخول لوحة التحكم. في ووردبريس صدر كمان قايمة المستخدمين وآخر مرة دخل فيها كل واحد. وفي لارافيل احتفظ بمجلد storage/logs وطابور الـ queue وأي جداول تدقيق في قاعدة البيانات.

اكتب تسلسل زمني وأنت شغال

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

من الدقيقة 15 لـ 30: اقفل الأبواب

دلوقتي بتقطع وصول الهاكر. الترتيب مهم، لأن لو غيرت الباسوردات بترتيب غلط الهاكر يقدر يرجعها تاني.

1. أمن الإيميل الأول

إيميل الأدمن هو المفتاح الرئيسي. أي حد يتحكم فيه يقدر يعمل “نسيت كلمة المرور” على كل نظام تاني. غير باسورد الإيميل، وفعل التحقق بخطوتين، وشوف لو في قواعد تحويل (forwarding) مش أنت اللي عملتها، وراجع آخر عمليات الدخول. اعمل ده قبل أي حاجة تانية ومن جهاز تثق فيه.

2. غير كل بيانات الدخول اللي الموقع لمسها

غيرهم بالترتيب ده واعتبر كلهم اتسربوا:

باسورد لوحة الاستضافة وحساب تسجيل الدومين، مع تفعيل التحقق بخطوتين على الاتنين.
مفاتيح SSH وحسابات SFTP أو FTP. امسح أي حساب محدش يعرفه، وبطل FTP العادي خالص.
باسورد مستخدم قاعدة البيانات. حدثه في ملف wp-config.php أو ملف .env في لارافيل في نفس الوقت، وإلا الموقع هيفقد الاتصال.
باسوردات الأدمن والمحرر ومدير المتجر في ووردبريس. أي حساب مش معروف امسحه بدل ما تغير باسورده بس.
مفاتيح الـ API: بوابة الدفع، مزود الإيميل SMTP، خرائط جوجل، reCAPTCHA، واتساب، وربط الـ CRM. ألغيها وأصدر مفاتيح جديدة من لوحة كل مزود.

3. اقفل كل الجلسات المفتوحة وغير المفاتيح السرية

كوكيز الجلسة المسروقة بتفضل شغالة حتى بعد تغيير الباسورد إلا لو ألغيتها. في ووردبريس بدل مفاتيح المصادقة والـ salts في wp-config.php، وده بيخرج كل المستخدمين بما فيهم الهاكر. في لارافيل غير APP_KEY بس لو فاهم هو بيشفر إيه، لأنه بيبطل الكوكيز المشفرة وأي حقول مشفرة في قاعدة البيانات، وبعدها امسح جدول الجلسات أو مخزن الجلسات.

4. دور على الأماكن اللي الهاكرز بيستخبوا فيها

تغيير الباسوردات ملوش لازمة لو الباب الخلفي لسه موجود. دور على الحاجات دي بالتحديد:

ملفات PHP جوا wp-content/uploads أو مسار public/storage في لارافيل. مجلدات الرفع المفروض فيها صور وملفات بس، مش كود تنفيذي.
ملفات اتعدلت قريب في مجلد الموقع. ترتيب الملفات بتاريخ التعديل غالبا بيكشف تاريخ الإصابة في ثواني.
ملفات بأسماء بتقلد ملفات النظام، زي نسخ من wp-config-sample.php أو class-wp-cache.php في فولدرات غريبة، أو أسماء حروف عشوائية.
ملف .htaccess متعدل فيه قواعد تحويل، أو سطر auto_prepend_file في ملف .user.ini أو php.ini بيحمل كود خبيث مع كل طلب.
المهام المجدولة. في ووردبريس اعرض أحداث الـ cron، وفي لارافيل وعلى السيرفر راجع الـ scheduler والـ crontab لأي سطر مش أنت اللي ضفته.
صفوف في قاعدة البيانات. أكواد جافاسكريبت خبيثة بتتحقن كتير في المقالات والودجت وجدول الخيارات وإعدادات القالب. دور على كلمات زي eval( وbase64_decode وأي دومين غريب في src لسكريبت.
مستخدمين أدمن مش معروفين، وكلمات مرور التطبيقات ومفاتيح الـ API.

من الدقيقة 30 لـ 45: اعرف دخلوا منين واقرر تنضف ولا تعيد البناء

تنضيف من غير ما تعرف نقطة الدخول هو أكتر سبب إن الموقع يتصاب تاني في أسبوع. الهاكر دخل من مكان. لو المكان ده لسه مفتوح، التنضيف مؤقت.

الأسباب الخمسة الأشهر

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

إضافة أو قالب قديم أو متروك فيه ثغرة معروفة. السكانرز الآلية بتدور على الإنترنت على نسخ معينة فيها ثغرات بعد ساعات من الإعلان عنها. الإضافات المدفوعة اللي بتتنزل من مصادر غير رسمية خطر خاص، لأنها كتير بتيجي ومعاها باب خلفي.
بيانات دخول مسروقة أو متكررة. باسورد اتسرب من خدمة تانية، أو لابتوب موظف مصاب، أو حساب مشترك لسه مع مقاول سابق.
عزل ضعيف في الاستضافة. في الاستضافة المشتركة الرخيصة، موقع واحد مخترق في نفس الحساب ممكن يصيب كل المواقع اللي جنبه. لو عندك كذا موقع في حساب استضافة واحد، اعتبرهم كلهم مخترقين.
ملفات إدارة أو تطوير مكشوفة. ملف .env ممكن يتفتح من برا، أو صفحة phpinfo منسية، أو نسخة من قاعدة البيانات متساب في مجلد الموقع، أو phpMyAdmin مفتوح للكل.
كود مخصص فيه ثغرات. رفع ملفات من غير فحص، أو SQL injection في نموذج بحث أو حجز، أو endpoint في الـ API من غير فحص صلاحيات. ده بيحصل في المشاريع المتسرعة أكتر من نواة ووردبريس المحدثة.

إزاي تقرا الأدلة

خد تاريخ تعديل أقدم ملف مشبوه وشوف لوج الدخول حوالين الوقت ده. دور على طلبات POST لروابط غريبة، وطلبات لملفات جوا مجلد uploads بتنتهي بـ php، وطلبات متكررة على xmlrpc.php أو wp-login.php من عنوان واحد. أول طلب خبيث غالبا بيظهر كرابط غريب قبل ظهور الملف الجديد بلحظات. الرابط ده بيدلك على المكون المصاب.

تنضف ولا تبني من جديد؟

في طريقين صح، والاختيار بيعتمد على قد إيه تقدر تثق في الكود.

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

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

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

من الدقيقة 45 لـ 60: اتأكد وقوي الحماية وارجع الموقع

تحقق قبل الإطلاق

قبل ما تشيل صفحة الصيانة، اتأكد إن التنضيف نجح. شغل فحص فيروسات بأداتين على الأقل، لأن كل أداة بتفوت حاجة. قارن checksum لملفات النواة بالأصلية: ووردبريس بيوفر ده في WP-CLI بأوامر verify-checksums للنواة والإضافات. افحص قاعدة البيانات لأي سكريبتات محقونة. افتح الموقع في نافذة خاصة من شبكة موبايل مش من مكتبك، عشان تكشف التحويلات المشروطة. وراجع كود الصفحة الرئيسية وصفحة منتج وصفحة اتصل بنا بحثا عن سكريبتات خارجية غريبة.

تقوية الحماية عشان نفس الباب ميتفتحش تاني

حدث نواة ووردبريس وكل الإضافات وكل القوالب، وامسح أي حاجة مش مستخدمة. إضافة متوقفة فيها ثغرة لسه ممكن تتستغل لو ملفاتها على السيرفر.
اقفل تعديل الملفات من لوحة التحكم بثابت في wp-config.php، وامنع تنفيذ PHP جوا مجلد uploads من إعدادات السيرفر.
فعل التحقق بخطوتين لكل أدمن، وقلل عدد حسابات الأدمن للناس اللي محتاجاها فعلا.
حط Web Application Firewall قدام الموقع، في الـ CDN أو على السيرفر، مع تحديد عدد المحاولات على صفحات الدخول وXML-RPC.
اظبط صلاحيات الملفات: عادة 644 للملفات و755 للمجلدات، مع تشديد أكتر على ملفات الإعدادات وملكيتها للمستخدم الصح.
استخدم SFTP أو مفاتيح SSH بس، وقفل FTP.
في لارافيل خلي APP_DEBUG على false في الإنتاج، وتأكد إن ملف .env برا مجلد public، وحدث المكتبات بانتظام مع تشغيل composer audit.

إزالة تحذيرات جوجل والمتصفح

لو جوجل علم الموقع، الموقع النضيف لوحده مش بيشيل التحذير. افتح Search Console وروح على Security Issues، وابعت طلب مراجعة بعد ما تشيل المحتوى المحقون. اشرح اللي لقيته واللي صلحته. جوجل عادة بيرد في أيام، والطلب الغامض احتمال رفضه أكبر. وتأكد كمان إن صفحات السبام المحقونة اتشالت وبترجع 404 أو 410 مش 200، وإن الـ sitemap فيها الروابط السليمة بس. وابعت طلب مراجعة لأي قوائم سودا تانية علمت الموقع زي Norton Safe Web أو قوائم سمعة مزود الإيميل.

الجانب التجاري: مين لازم يعرف

إصلاح تقني من غير خطة تواصل معناه إن الحادثة اتعاملت معاها نص تعامل.

العملاء والشركاء

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

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

قانون حماية البيانات الشخصية المصري

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

فريقك الداخلي

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

الاختراق بيكلف قد إيه فعلا، وليه الوقاية أرخص

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

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

قايمة من صفحة واحدة تحتفظ بيها

اطبعها وسيبها في مكان فريقك يلاقيها. قصيرة عن قصد.

الدقيقة 0 لـ 5: اتأكد من الأعراض، ووقف الموقع للجمهور لو بيوزع فيروسات أو بيحول الزوار.
الدقيقة 5 لـ 15: خد نسخة من الملفات وقاعدة البيانات، ونزل كل اللوجات، وابدأ تسلسل زمني بالتوقيت.
الدقيقة 15 لـ 30: أمن إيميل الأدمن، وغير بيانات الاستضافة وقاعدة البيانات وSSH والموقع والـ API، وبدل المفاتيح السرية، وامسح المستخدمين الغريبين، ودور على الأبواب الخلفية.
الدقيقة 30 لـ 45: حدد نقطة الدخول من اللوجات، واختار بين التنضيف في مكانه وإعادة البناء على سيرفر نضيف.
الدقيقة 45 لـ 60: افحص بأداتين، وتحقق من الـ checksums، وقوي الحماية، وأطلق الموقع، واطلب مراجعة جوجل لو اتعلم.
في نفس اليوم: بلغ العملاء والشركاء المتأثرين، وسجل الحادثة، وحدد فحص متابعة بعد 7 أيام وبعد 30 يوم.

ليه العدوى بترجع بعد أسبوع

أخطر لحظة في الحادثة هي الأسبوع اللي بعدها. الهاكر اللي لقى باب واحد غالبا سايب باب تاني لوقت بعدين، والبوتات الآلية بتفضل تحاول على نفس الرابط المصاب. راقب لوج الدخول كل يوم في الأسبوع الأول، وسيب تنبيهات تغيير الملفات شغالة، وأعد الفحص بعد 7 أيام وبعد 30 يوم. لو نفس نمط الطلب الخبيث ظهر تاني، يبقى نقطة الدخول لسه مقفولتش.

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

تعرض موقعك للاختراق؟ ما تفعله في أول 60 دقيقة