ماذا تفعل إذا تم اختراق خادم VPS الخاص بك؟

لا تحاول تنظيف خادم VPS مخترق

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

لا يمكنك إثبات خلو النظام من الـrootkit، لأن الأدوات التي ستستخدمها لإثبات ذلك هي نفسها الأدوات التي يسيطر عليها المهاجم.

هذه هي الحجة الكاملة. وإليك الآلية الكامنة وراء ذلك. يمكن للمهاجم الذي وصل إلى صلاحيات root استبدال ps بحيث لا يظهر معرف عملية (PID) معين في مخرجاته أبداً. سطر واحد في /etc/ld.so.preload يقوم بتحميل كود المهاجم في كل برنامج مرتبط ديناميكياً على الجهاز، وبذلك تكذب كل من ls وss وfind بنفس الطريقة المتسقة. يمكن لوحدة نواة قابلة للتحميل (loadable kernel module) إخفاء الملفات تحت مستوى نداءات النظام (system calls)، بحيث يرى حتى الملف الثنائي الذي قمت بتحميله للتو قرصاً نظيفاً. أنت تحذف برنامج التعدين، فينخفض رسم بياني لاستهلاك المعالج، ويصبح الخادم هادئاً. الهدوء هو أيضاً ما تبدو عليه الأبواب الخلفية (backdoors) العاملة.

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

تأكّد من وقوع اختراق فعلي

العديد من الخوادم التي يُبلّغ عن تعرّضها للاختراق ليست كذلك في الواقع. إنّ آلاف محاولات تسجيل الدخول الفاشلة عبر SSH يومياً هي مجرد ضجيج خلفي للإنترنت، لأن كل عنوان IPv4 عام يخضع للمسح المستمر. إنّ مخرجات lastb المليئة بمحاولات root وadmin تعني فقط أن الماسحات الضوئية قد عثرت على المنفذ الخاص بك، ولا تعني أن أحداً قد تمكّن من الدخول.

هذه الإشارات تعني وجود مشكلة حقيقية:

• تسجيل دخول ناجح لا يمكنك تفسيره، مثل Accepted password for root from 203.0.113.7.
• وجود مفتاح في authorized_keys لم تقم بإضافته.
• إشعار إساءة استخدام من مزود الاستضافة بشأن حركة مرور صادرة من خادمك.
• عملية تستهلك 100% من المعالج وتحمل اسماً منسوخاً من خيط معالجة (kernel thread). غالباً ما يتم الإبلاغ عن برمجيات التعدين التي تُزرع عبر منافذ Redis وDocker المكشوفة بأسماء مثل kdevtmpfsi وkinsing.
• اتصالات صادرة إلى عناوين لا تستخدمها أي من خدماتك.

يوجد اختبار سريع لكشف تمويه خيوط المعالجة. خيوط المعالجة الحقيقية تُطبع داخل أقواس مربعة ولا يوجد ملف تنفيذي خلفها، لذا يفشل أمر sudo ls -l /proc/<pid>/exe معها ويظهر No such file or directory. إذا كانت العملية المطبوعة باسم [kworker/0:2] تملك رابط exe يشير إلى مسار تحت /tmp، فهي مجرد برنامج مستخدم عادي ينتحل اسم خيط معالجة.

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

اقطع الشبكة من لوحة تحكم المزود، لا من داخل الخادم

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

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

هناك سببان لعدم القيام بذلك من داخل الخادم. جدار الحماية الذي تضبطه داخل نواة (kernel) مخترقة يخضع لسيطرة تلك النواة، ويمكن للمستخدم root مسح قواعد nftables بسهولة تامة. كما أن تنفيذ sudo ip link set enp1s0 down عبر SSH سيقطع جلستك أنت أولاً، مما سيؤدي إلى طردك من الجهاز الذي كنت في منتصف فحصه.

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

لا تقم بإعادة التشغيل بعد. تحقق أولاً مما إذا كان المجلد /var/log/journal موجوداً. إذا كان هذا المجلد مفقوداً، فإن journald يكتب في /run/log/journal، وهو مسار موجود في الذاكرة، لذا فإن إعادة التشغيل ستمحو سجل الاختراق. كما تختفي العمليات الجارية عند إعادة التشغيل، وغالباً ما تكون أسطر أوامرها هي أوضح دليل قد تحصل عليه.

خذ لقطة للقرص قبل أن تلمس أي شيء

تؤدي اللقطة (Snapshot) والنسخة الاحتياطية (Backup) وظائف مختلفة في هذا السياق. اللقطة التي تأخذها الآن هي نسخة من قرص مخترق: إنها دليلك الجنائي، وهي الوسيلة الوحيدة التي تتيح لك التراجع بعد أن تقوم بالكتابة فوق شيء ما عن طريق الخطأ. أما نسخك الاحتياطية القديمة فهي مسار الاستعادة. إذا كانت لوحة تحكم مزود الخدمة لديك تستخدم المصطلحين بشكل فضفاض، فاقرأ كيف تختلف لقطات VPS عن النسخ الاحتياطية الحقيقية أولاً، لأن قواعد الاحتفاظ وسلوك الاستعادة ليسا متطابقين.

خذ اللقطة من لوحة تحكم المزود قبل تسجيل الدخول مرة أخرى. اللقطة الحية (Live snapshot) متوافقة مع حالة الانهيار (Crash consistent): فهي تلتقط حالة القرص كما كانت في تلك اللحظة، تماماً مثل فصل الطاقة عنه. هذا مقبول للأغراض الجنائية. سمِّ اللقطة باسم يمنع أي شخص من استعادتها عن طريق الخطأ. اسم مباشر مثل COMPROMISED-do-not-restore-2026-08-12 هو مستوى الدقة المناسب. احتفظ بها حتى تنتهي تحقيقاتك ويتم إغلاق أي تذكرة إساءة استخدام مع مستضيفك.

كيفية الدخول عند تعذّر الاتصال عبر SSH

هناك مساران، كلاهما متاح في لوحة تحكم مزود الخدمة. تتصل وحدة التحكم عبر الويب (VNC أو المنفذ التسلسلي) بالجهاز وكأنك قمت بتوصيل لوحة مفاتيح فعلية. تعمل هذه الطريقة عندما يتوقف sshd عن العمل، أو عند إعداد جدار الحماية بشكل خاطئ، أو عندما يقوم المهاجم بتغيير منفذ SSH. تعتمد هذه الطريقة على المصادقة بكلمة مرور محلية، لذا قد تحتاج إلى إعادة تعيين كلمة مرور root في الخادم الذي يعتمد على المفاتيح فقط قبل أن تصبح وحدة التحكم مفيدة.

يُعد وضع الإنقاذ (Rescue mode) الخيار الأفضل. فهو يقوم بإقلاع نظام حي صغير مع إرفاق قرصك دون تشغيله، مما يجعل أوامرك موثوقة: النواة (kernel) المخترقة والملفات الثنائية (binaries) المخترقة لا تعمل. قم بتركيب (mount) القرص للقراءة فقط.

lsblk -f
sudo mkdir -p /mnt/victim
sudo mount -o ro /dev/vda1 /mnt/victim

إذا أظهر lsblk وحدات تخزين LVM (مدير وحدات التخزين المنطقية) بدلاً من قسم عادي، فقم بتنشيطها أولاً باستخدام sudo vgchange -ay، ثم قم بتركيب الجهاز الذي يظهر تحت /dev/mapper/.

لا تقم بعمل chroot إلى القرص المركّب للتجول فيه. يقوم chroot بتنفيذ الملفات الثنائية الخاصة بالمهاجم بصلاحياتك، مما يلغي تماماً الغرض من إقلاع وضع الإنقاذ.

جمع الأدلة التي لا تزال موثوقة

نفّذ هذه الأوامر من وضع الإنقاذ (rescue mode)، مع تثبيت القرص للقراءة فقط في المسار /mnt/victim. ابدأ بسجلات الدخول، لأنها تحدد تاريخ الاختراق، وتسهّل فهم كل شيء آخر بمجرد تحديد الإطار الزمني.

sudo grep -aE 'Accepted (password|publickey)' /mnt/victim/var/log/auth.log
sudo last -f /mnt/victim/var/log/wtmp
sudo lastb -f /mnt/victim/var/log/btmp
sudo journalctl -D /mnt/victim/var/log/journal -u ssh --since "2026-07-01"

غياب ملف /var/log/auth.log ليس أمراً مريباً بحد ذاته. بعض صور Ubuntu الحالية تُشحن بدون rsyslog، لذا يكتب sshd السجلات في journal فقط، وهو ما يقرأه السطر journalctl -D. ما يستحق الانتباه هو وجود فجوة في سجلات يفترض أنها متصلة، أو ملف سجل تم تقليصه إلى صفر بايت. مسح السجلات أمر شائع وعادة ما يتم بطريقة غير متقنة.

بعد ذلك، افحص الحسابات والمفاتيح.

sudo find /mnt/victim/root /mnt/victim/home -name 'authorized_keys*' -exec ls -l {} +
sudo awk -F: '$3 == 0 {print $1}' /mnt/victim/etc/passwd
sudo lsattr /mnt/victim/root/.ssh/authorized_keys

يطبع السطر awk كل حساب بمعرف مستخدم (UID) يساوي 0. أي شيء غير root في هذه المخرجات يعني وجود حساب root ثانٍ. النمط find يطابق عمداً authorized_keys2 أيضاً، لأن OpenSSH يقرأ كلا اسمي الملفين افتراضياً، ومن السهل تجاهل الملف الثاني. إذا طبع الأمر lsattr حرف i في قائمة السمات، فهذا يعني أن الملف غير قابل للتغيير (immutable): يضبط المهاجم هذه السمة ليفشل محاولتك لحذف مفتاحه مع ظهور الخطأ Operation not permitted، فيظن المسؤول المنهك أن التعديل قد تم بنجاح.

تختبئ الاستمرارية (persistence) في عدد قليل من الأماكن، لذا افحصها جميعاً.

sudo ls -lt /mnt/victim/etc/systemd/system
sudo ls -l /mnt/victim/etc/cron.d /mnt/victim/var/spool/cron/crontabs
sudo cat /mnt/victim/etc/ld.so.preload
sudo grep -rnE 'curl|wget|base64|/dev/tcp' /mnt/victim/etc/update-motd.d /mnt/victim/etc/rc.local /mnt/victim/root/.bashrc /mnt/victim/root/.profile

لا يوجد الملف /etc/ld.so.preload في أنظمة Ubuntu أو Debian العادية، لذا فإن No such file or directory هي النتيجة السليمة، وأي محتوى فيه يستحق اهتمامك. ملف تسجيل دخول يقوم بتمرير مخرجات base64 -d إلى shell هو أمر مريب؛ فملفات الإعداد المشروعة لا تحتاج لإخفاء نصوصها.

ابنِ الجدول الزمني بناءً على وقت التغيير (ctime) بدلاً من وقت التعديل (mtime).

sudo find /mnt/victim -xdev -newerct '2026-08-01' -type f -printf '%TF %TT %p\n' | sort

يسمح الأمر touch بضبط وقت التعديل على أي قيمة يريدها المهاجم، لذا فإن mtime كاذب بسهولة. يتم تحديث وقت التغيير (ctime) عند أي تغيير في الـ inode، ولا يمكن للأمر touch إرجاعه للخلف، لذا يعطي -newerct قائمة أكثر صدقاً لما تمت كتابته مؤخراً. هذا لا يزال ليس دليلاً قاطعاً، لأن حساب root يمكنه تغيير ساعة النظام أو الكتابة مباشرة على جهاز الكتلة (block device).

سلامة الحزم تستحق أمراً واحداً وتحذيراً واحداً. على نظام قيد التشغيل، يطبع sudo dpkg --verify سطراً لكل ملف حزمة لم يعد مجموع التحقق (checksum) الخاص به متطابقاً، مع وجود 5 في عمود مجموع التحقق، ويقوم sudo debsums -ac بنفس المهمة بما في ذلك ملفات الإعداد عند تثبيت حزمة debsums. اقرأ النتيجة في اتجاه واحد فقط. ملف /usr/sbin/sshd المتغير هو دليل حقيقي. التقرير النظيف لا يثبت شيئاً، لأن حساب root نفسه الذي استبدل الملف الثنائي يمكنه إعادة كتابة قوائم مجموع التحقق الموجودة تحت /var/lib/dpkg/info/. تتبع ماسحات الـ rootkit مثل rkhunter و chkrootkit نفس القاعدة: العثور على نتيجة إيجابية هو معلومة، أما الفحص النظيف فلا يعني خلو النظام من الاختراق.

انسخ ما جمعته خارج الجهاز قبل القيام بأي إجراء تدميري.

sudo tar --ignore-failed-read -C /mnt/victim -czf /root/evidence-2026-08-12.tgz \
  var/log etc root/.ssh root/.bash_history home
sha256sum /root/evidence-2026-08-12.tgz

دوّن هذا الـ hash في مكان خارج الخادم. إذا تحول الأمر لاحقاً إلى مطالبة تأمين أو تقرير شرطة، فإن القدرة على إثبات أن الأرشيف لم يتغير منذ لحظة الجمع هي الفرق بين كونه دليلاً وبين كونه مجرد مجلد ملفات. حذف الأشياء عن طريق الخطأ أثناء التحقيق أمر وارد، والنسخة الاحتياطية (snapshot) بالإضافة إلى هذا الأرشيف هي ما يجعل الموقف قابلاً للتعافي. التراجع عن أمر rm خاطئ بعد وقوعه أصعب بكثير مما يتوقعه الناس، كما يشرح استعادة الملفات المحذوفة باستخدام rm -rf.

اعثر على المنفذ الذي تسللوا منه

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

تسجيل الدخول بكلمة مرور عبر SSH. سطر Accepted password for root من عنوان لا تعرفه هو الإجابة بحد ذاته. تحقق من PasswordAuthentication في /etc/ssh/sshd_config وفي كل ملف تحت /etc/ssh/sshd_config.d/. يستخدم sshd القيمة الأولى التي يحصل عليها لأي كلمة مفتاحية، ويقع سطر Include في أعلى الملف الرئيسي على Ubuntu، لذا فإن أي ملف إعدادات إضافي سيتجاوز بصمت الإعداد الذي قمت بتعديله في الأسفل.

خدمة منشورة دون مصادقة. مثل Redis على المنفذ 6379، أو Docker API على 2375، أو قاعدة بيانات مرتبطة بـ 0.0.0.0 بدلاً من 127.0.0.1. Docker هو المفاجأة الشائعة. نشر منفذ حاوية يُدرج قواعد DNAT (ترجمة عنوان الشبكة الوجهة) التي يتم تقييمها قبل سلاسل ufw، لذا قد يبلغ ufw status عن منفذ بأنه محظور بينما تجيب الحاوية التي خلفه على الإنترنت بأكمله. افهم هذا قبل إعادة البناء: لماذا تتجاوز منافذ Docker المنشورة جدار ufw تغطي ترتيب القواعد والحل.

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

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

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

قم بتدوير جميع بيانات الاعتماد التي قد يكون الجهاز قد اطلع عليها

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

• كل مفتاح SSH خاص مخزن على الخادم، بالإضافة إلى كل حساب في مكان آخر كان يثق بالمفتاح العام المطابق.
• أي مفتاح قمت بتمريره إلى الجهاز باستخدام ssh -A. يترك توجيه الوكيل (Agent forwarding) مقبساً (socket) تحت /tmp، ويمكن للمستخدم root على ذلك الجهاز استخدامه للمصادقة بصفتك في أي مكان يُقبل فيه مفتاحك، طالما ظلت جلستك مفتوحة.
• رموز API في ملفات .env، وفي أسطر Environment= الخاصة بـ systemd، وفي إعدادات CI، وفي بيانات اعتماد المزود.
• كلمات مرور قواعد البيانات، وحسابات التطبيقات التي تستخدمها.
• مفاتيح TLS (أمن طبقة النقل) الخاصة التي كان يحتفظ بها الخادم. أعد إصدار الشهادة وألغِ القديمة.
• كلمة مرور حساب الاستضافة الخاص بك، مع تفعيل المصادقة الثنائية. يمكن لتلك اللوحة إعادة بناء كل خادم تملكه، وأخذ لقطات له، والوصول إلى وحدة التحكم (console) الخاصة به، لذا فهي المحيط الحقيقي.
• أي كلمة مرور كُتبت في جلسة shell على ذلك المضيف أثناء اختراقه، لأن المستخدم root يمكنه تسجيل جلسة الطرفية (terminal) فور حدوثها.

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

قائمة التحقق من إعادة البناء

1. أنشئ خادماً جديداً من صورة توزيعة نظيفة. لا تستخدم لقطة (snapshot) للخادم المخترق، ولا تستخدم استعادة كاملة لنظام ملفات الجذر.
2. ثبّت الحزم من مستودعات التوزيعة الرسمية. لا تنسخ أي ملف ثنائي (binary) من القرص القديم.
3. استعد البيانات فقط، من نسخة احتياطية مؤرخة قبل أقدم دليل في الجدول الزمني للاختراق. استعد ملفات تفريغ قواعد البيانات، والمرفقات، وحالة التطبيق. اترك /etc و/usr وملفات الوحدات (unit files) القديمة.
4. أدخل الأسرار (secrets) المجددة يدوياً. لا تنسخ ملف .env القديم.
5. افحص محتوى الويب المستعاد بحثاً عن أي ملفات أُضيفت خلال فترة الاختراق قبل نشره مجدداً.
6. حصّن الخادم قبل عرضه للإنترنت: استخدم مفاتيح SSH فقط، وأنشئ حساب عمل غير حساب root، وفعّل جدار حماية يرفض جميع الاتصالات الواردة افتراضياً، ولا تنشر أي خدمة على نطاق أوسع مما تحتاجه. اتبع خطوات الدقائق العشر الأولى على خادم VPS جديد، ثم حصّن SSH بشكل صحيح، ثم أضف fail2ban على Ubuntu 24.04 لتقليل ضجيج محاولات تسجيل الدخول. امنح كل خدمة حساباً خاصاً بصلاحيات محدودة لضمان أن أي اختراق مستقبلي لن يمنح المهاجم صلاحيات root.
7. أوقف تشغيل الخادم القديم، واحتفظ بلقطته حتى إغلاق التحقيق وأي بلاغات إساءة استخدام.
8. أصلح النسخ الاحتياطية. إذا كانت الخطوة 3 تعتمد على التخمين، فالدرس الحقيقي هو أن تاريخ النسخ الاحتياطي لديك كان قصيراً جداً بحيث لم يصل إلى ما قبل الاختراق. النسخ الاحتياطية المنسوخة خارج الخادم مع الاحتفاظ بها لفترات طويلة هي ما يضمن نقطة استعادة نظيفة في المرة القادمة: توفر لك النسخ الاحتياطي باستخدام restic على VPS كلا الميزتين.

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

ماذا يعني إشعار الإساءة الوارد من مزود الاستضافة

يعرف معظم المستخدمين أن خادمهم قد تعرّض للاختراق من خلال مزود الخدمة، وليس من خلال أدوات المراقبة الخاصة بهم. يرى مزودو الاستضافة حركة مرور البيانات الصادرة: هجمات القوة الغاشمة (brute force) عبر SSH ضد شبكات أخرى، أو رسائل مزعجة (spam) على المنفذ 25، أو مشاركة الخادم في هجمات الانعكاس (reflection attack). عادةً ما تتضمن التذكرة طوابع زمنية، ومنافذ، وعينة من تدفقات البيانات، بالإضافة إلى مهلة زمنية تُقاس بالساعات.

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

يُعد خادم العميل المخترق عملاً روتينياً بالنسبة لمزود الاستضافة، والتعامل معه بشكل جيد لا يُحسب ضدك. السؤال الأوسع حول مدى أمان استضافة VPS يعتمد في الغالب على ما يقوم العميل بضبطه، وهو بالضبط الجزء الذي ستقوم به الآن مجدداً من الصفر.

متى يجب الاستعانة بمتخصص

• إذا كان الخادم يحتوي على بيانات شخصية تخص أشخاصاً آخرين. بموجب اللائحة العامة لحماية البيانات (GDPR)، يجب إبلاغ سلطة الإشراف بأي خرق للبيانات الشخصية دون تأخير غير مبرر، وفي غضون 72 ساعة من لحظة اكتشافه إن أمكن ذلك. إن تحديد ما إذا كان هذا الوقت قد بدأ في النفاذ هو عمل قانوني، وليس عملاً إدارياً للنظم.
• إذا كانت بيانات بطاقات الدفع ضمن نطاق الخطر. تتطلب أنظمة البطاقات وجود محقق جنائي معتمد، وقد يؤدي عبثك بالخادم إلى الإضرار بالقضية.
• إذا كان هناك طلب فدية، أو إذا تم تشفير بياناتك.
• إذا كان بإمكان الجهاز الوصول إلى أجهزة أخرى: شبكة داخلية، أو Hypervisor، أو CI runner يحتوي على بيانات اعتماد للبيئة الإنتاجية. يُعتبر المضيف المخترق في مجموعة ما حادثاً يمس المجموعة بأكملها حتى يثبت العكس.
• إذا كنت بحاجة إلى أن تصمد الأدلة أمام شركات التأمين أو جهات إنفاذ القانون. توقف عند أخذ لقطة (snapshot)، وخذ صورة كاملة للقرص، وسجّل من تعامل معها ومتى.

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

FAQ

هل يمكنني تنظيف خادم VPS مخترق بدلاً من إعادة بنائه؟

لا يمكنك ذلك بثقة، لأنك ستطلب من النظام المخترق أن يقدّم تقريراً عن نفسه. يمكن لملف ps مستبدل أن يخفي عملية ما، كما يمكن لسطر في /etc/ld.so.preload حقن كود في كل أداة مرتبطة ديناميكياً تقوم بتشغيلها، بينما يمكن لوحدة kernel إخفاء ملفات عن جميع البرامج في آن واحد. يمكنك العثور على أشياء، لذا فإن وجود نتيجة إيجابية يعني شيئاً. لكنك لا تستطيع إثبات عدم وجود شيء، لذا فإن النتيجة النظيفة لا تعني شيئاً. التنظيف مقبول فقط إذا كان الخادم لا يحتوي على أي شيء يهمك، وإذا كنت تتقبل حقيقة أنه قد يُخترق مجدداً.

هل يجب عليّ إيقاف تشغيل خادم مخترق أم تركه يعمل؟

اقطع اتصاله بالشبكة من خلال لوحة تحكم المزود أولاً، ثم اتركه يعمل لفترة كافية لأخذ لقطة (snapshot) وفحص العمليات الجارية. إيقاف التشغيل يدمر قائمة العمليات، ويحذف السجلات بالكامل إذا كان /var/log/journal غير موجود، لأن journald يكتب حينها في الذاكرة تحت /run. أوقف تشغيله على أي حال إذا كان يشن هجمات نشطة على شبكات أخرى ولم تكن تملك طريقة لحظر حركة المرور الصادرة منه. إيقاف الضرر أهم من الاحتفاظ بالأدلة.

كيف أعرف متى دخل المهاجم إلى النظام؟

ابحث عن أقدم سطر في Accepted password أو Accepted publickey لا يمكنك تفسيره، سواء في /var/log/auth.log أو في السجلات. طابقه مع قائمة تواريخ التغيير باستخدام find / -xdev -newerct 'YYYY-MM-DD' -type f، لأن قيمة ctime أصعب في التزوير من mtime. ثم قارن كلاهما بالطوابع الزمنية في تذكرة الإساءة (abuse ticket) الخاصة بمزود الخدمة، والتي سُجّلت خارج الجهاز ولا يمكن تعديلها. اختر نسخة احتياطية أقدم من أقدم تاريخ بين هذه التواريخ الثلاثة. إذا لم يتطابق أي شيء، افترض أن الاختراق أقدم من تاريخ نسخك الاحتياطي، واستعد فقط البيانات التي يمكنك فحصها.

هل نسخ احتياطية آمنة للاستعادة بعد الاختراق؟

البيانات عادة ما تكون آمنة بعد فحصها، أما ملفات النظام فلا. النسخة الاحتياطية المأخوذة بعد الاختراق تحتوي على الباب الخلفي (backdoor)، لذا فإن استعادة نظام ملفات الجذر بالكامل تعيد المهاجم أيضاً. افحص مستودع النسخ الاحتياطي نفسه أيضاً: إذا كانت بيانات الاعتماد الخاصة به مخزنة على الخادم المخترق، فقد يكون السجل قد حُذف أو عُدّل، وهذا هو سبب تفضيل أهداف النسخ الاحتياطي التي تعتمد على الإضافة فقط (append-only) أو السحب (pull-based). استعد بيانات التطبيقات، ثم ثبّت البرامج مجدداً من مستودعات التوزيع الرسمية.

هل يجب عليّ إبلاغ أي شخص بأن خادم VPS الخاص بي قد تعرّض للاختراق؟

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