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

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

لو عندك وصول SSH بصلاحيات root، تقدر تغير باسورد مستخدم MySQL باستخدام هاش الباسورد: UPDATE mysql.user SET Password=PASSWORD('newpass') WHERE User='root'; FLUSH PRIVILEGES;. لو لأ، تقدر تشغل WHM API أو سكريبت الإدارة في cPanel. بس لو الهاكر وصل لـ root أصلاً، يبقى السيرفر اتسرق بالكامل. راجع اللوجات، bind.log، secure log وغيرهم.

في الحالات دي شركة الاستضافة بتتحرك ببطء شديد فعلاً. لكن لو تقدر توصل لـ SSH تبقى مرتاح شوية... تقدر تغير باسورد الـ root. بصراحة أو تعمل sudo su وتكتب passwd root. لكن لو وصلوا لكل السيرفر يبقى في malware كمان — عمل فورمات كامل ثم إعادة تثبيت وانتهى الموضوع.

في وصول SSH؟ لو في وصول root: ssh root@[IP]، passwd [enter]، اكتب الباسورد الجديد، confirm. لو في وصول مستخدم فقط: sudo su، passwd، الباسورد الجديد. بانل شركة الاستضافة ده حاجة ثانوية، المهم وصول السيرفر. لو مفيش وصول SSH خالص، ممكن تضطر تتصل بشركة الاستضافة تليفونياً. ينصح بمراجعة اللوجات: /var/log/auth.log، /var/log/secure (أنظمة Red Hat)، دي بتقول مين دخل.

بتتكلم بسرعة أوي يا أستاذ، هل السيرفر اتسرق بالكامل عشان باسورد البانل اتغير؟ ولا بس باسورد cPanel؟ لو لسه تقدر تدخل SSH يبقى لسه ملكك. الخطوة الأولى: ادخل SSH، ادخل bash، اعمل root. بعدين نشوف...

وكيف حللتم هذه النقطة؟ وقت اكتشاف المشكلة يحدد تكلفتها بشكل مباشر.

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

لم أكن أعلم بهذا.

هذا العنوان مؤرشف.

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

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

هذا كل شيء، أرجو المعذرة إذا أطالت.

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

سأتحدث من الطرف الآخر، فأنا من جانب الموردين. كل بند غير مكتوب هو بند سيتذكره الطرفان بشكل مختلف لاحقًا.

معظم الحوادث لا تبدأ من ثغرة أمنية، بل من كلمة مرور مسربة. بالطبع يختلف الأمر إذا كانت حالتك مختلفة.

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

تم الحفظ.

هناك فخ هنا، لا أريد المرور عليه دون ذكره. إذا قمت بتوبيخ الإنذارات الكاذبة، فلن يقوم أحد بالإبلاغ مرة أخرى.

دعني أتركها كملاحظة، قد تكون مفيدة.

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

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

تشتت النقاش، دعني ألخصه. طيب بيئات الاختبار المنسية تصبح ثغرات أمنية أكثر تكرارًا من الأنظمة الحية.

قضيت وقتًا طويلاً في هذا المجال. لا يتم التحقق من تغييرات معلومات الدفع أبداً عبر القناة الواردة منها.

إذا كانت قناة الإشعارات طويلة، فلن تصل الإشعارات؛ والإشعار غير الواصل يعني حدثًا يُكتشف متأخرًا. دعني أتركها كملاحظة، قد تكون مفيدة.