لقد تم تكليفي مؤخراً لتحليل وإنتقاد مقالة البروفيسور بروس نيكّل في أسلوبه المنهجي لتحري أي وجود في الشبكة العنكبوتية حيث قام بكتابة مقالة طويلة مقترح أسلوب منهجي يجب اتباعه من قبل المحققين للتحقيق عن أي وجود في الشبكة العنكبوتية. لقد تم نشر مقالة بروس نيكّل من قبل الناشر “إلسيفير” وهم معروفون بإهتمامهم بالمقالات العلمية التكنولوجية وأيضاً المجالات الطبية.في حال إهتمامكم بالمقالة الأصلية يمكنكم البحث عنها في موقع بروس الشخصي في قائمة المصادر نهاية هذا المقال. في هذه المقالة سوف أقوم بتحليل مقالة البروفيسور بروس الذي قام بكتابتها في عام 2004 وسوف أبدي رأيي في بعض النقاط وربما أعدل بعضها لإبداء وجهة نظري الشخصية مع الإلتزام بإتباع نفس أسلوب الكاتب الأصلي.
عن الكاتب:
بحسب الناشر للمقالة الأصلية, بروس ج. نيكّل “يعمل في قسم الحد من المخاطر في بنك “يو بي اس” في مجال التحقيق الجنائي الرقمي, حيث عمل معهم في هذا القسم منذ عام 1997. يحمل شهادة الماجستير في إدارة الشبكات بجانب العديد من الدورات في مجال أمن المعلومات والتحقيق الجنائي الرقمي. حصل بروس نيكل مؤخراً على شهادة الدكتوراة في مجال التحقيق الجنائي الرقمي للشبكات.
أعمال أخرى للكاتب :
Forensic acquisition and analysis of magnetic tapes. Feb (2005).
Generalizing sources of live network evidence. Sep (2005).
Improving evidence acquisition from live network sources. May (2006).
A portable network forensic evidence collector. Oct (2006).
An introduction to investigating IPv6 networks. July (2007).
Forensic analysis of GPT disks and GUID partition tables. Sep (2009).
عن الناشر:
“السيفير” يكنون أنفسهم بالناشر الرائد عالمياً في مجال العلم والمعلومات الصحية. حيث يقوموا بخدمة أكثر من 30 مليون من العلماء,الطلاب, والمحترفين في مجال الطب والمعلومات. مقر الشركة الرئيسي في أمستردام حيث توظف اكثر من 7000 شخص في 24 بلد مختلف حول العالم. يحتوي مجتمعهم على أكثر من 7000 محرر, و 70000 عضو هيئة تحرير, و 300,000 مرجع, و أكثر من 600,000 مؤلف.
التحليل:
من المعروف في هذه الأيام بأن كل جهاز متصل على الإنترنت يحمل عنوان بروتوكول انترنت خاص به المعروف بالآي بي, حيث يقوم بتحديد هوية كل جهاز على الشبكة, ونظراً للتطور العملاق الذي حصل للإنترنت في السنوات الأخيرة, عدد الأجهزة المتصلة بالإنترنت ازداد بشكل خيالي مما أدى لظهور العديد من الخدمات المتوفرة عن طريق الشبكة, مثل البريد الإلكتروني, تطبيقات الشبكة, خدمات قواعد البيانات وخلافه من الخدمات الأخرى التي تديرها مجموعات متخصصه ومنفصلة. ولهذا السبب قام البروفيسور بروس بالإهتمام في ابتكار طريقة منهجية مقترحاً لجميع المهتمين بالمجال الأمني اتباعها للحصول على جميع المعلومات المتعلقة بأي عنوان على الشبكة. هذه الطريقة المنهجية سوف تولد لنا دليل جنائي وتقرير معتمد بطريقة مرتبة موضحة جميع الجهات المسؤولة للعنوان على الشبكة, وكوني مهتم بالمجال الجنائي انا أنصح أي محقق جنائي بإتباع هذا الأسلوب المقترح بالإضافة للإقتراحات التي قمت بها لتعديل بعض الأوامر للحصول على نتيجة أفضل حيث سوف أقوم بسردها بالتفصيل في هذه المقالة.
بدأ البروفيسور بروس مقالته مفصحاً بأن طرق حفظ الخصوصية المتبعة هذه الأيام غالباً مايتم إساءة استخدامها من قبل المجرمين لإخفاء هوياتهم. لذلك, كلما زاد عدد الجهات المسؤولة في وجود أي جهاز على الشبكة يصبح من الصعب لهذا الجهاز او العنوان بأن يكون مجهول كلياً. بعد ذلك تحدث البروفيسور عن الجهات الكبرى المسؤولة لإدارة الخدمات الموجودة على الشبكة. تلك الجهات هي:
مسجلي النطاقات: المجموعات المعروفة بـ Top Level Domain Registrar حيث تكمن مسؤوليتها بتوفير النطاقات لطالبي التسجيل.
طالبي التسجيل “registrants”: الجهات التي تقوم بالذهاب إلى مسجلي النطاقات لتسجيل النطاق. حيث يحمل النطاق المسجل جميع التفاصيل الخاصة بمسجله.
مسؤولي خوادم الدي إن إس: حيث تكمن مسؤوليتهم في التحكم بمجال الدي إن إس وإدارته.
المسؤولين الإقليميين لعناوين الشبكة: تكمن مسؤوليتهم بإدارة عناوين البروتوكول الخاصة بكل قارة تقريباً, حيث تديرها على شكل مجموعات منفصلة مسؤولة. وبناءاً على المعلومات المتوفرة من منظمة المصادر الرقمية هذه الجهات هي:
- ARIN: لقارة أمريكا الشمالية وبعض جزر الكاريبيان.
- LACNIC: لأمريكا الجنوبية وجزر الكاريبيان.
- AfriNIC: لقارة أفريقيا.
- APNIC: لجنوب وجنوب شرق قارة آسيا شاملاً الهند.
- RIPE: لروسيا, اوروبا والشرق الاوسط.
مديري الشبكات: وهي المنظمات المسؤولة لإدارة مجالات معينة من عناوين الآيبي.
مديري خوادم الإنترنت: حيث تكمن مسؤوليتهم بإدارة الخادم وتمكينه لإستضافة وحفظ البيانات, قد يحملوا مسؤولية الهاردوير (الأجهزة الصلبة) أيضاً.
مديري خوادم البريد الإلكتروني: حيث ينقسموا لقسمين, قسم يدير الخوادم الخاصة بتخزين البريد الإلكتروني وحفظه, وقسم آخر مسؤول عن إدارة خوادم إرسال البريد الإلكتروني.
مزود الخدمة: وهم المسؤولين لتوفير الباندويث “كمية نقل البيانات” لمزودي بيانات أصغر, يمتكلوا القدرة أيضاً لمراقبة البيانات وإدارتها وحجبها.
شركات الإتصالات السلكية واللاسلكية: حيث تكمن مسؤوليتهم بالمحافظة على الاتصال بين مزود الخدمة والعميل, وأنا أقصد هنا على سبيل المثال الرابط الفعلي بين العميل ومزود الخدمة.
التوجيه و مسؤولي أنظمة التحكم الذاتي: حيث تكمن مسؤوليتهم بتبادل معلومات التوجيه “Routing Information” مع الأقران “peers”.
أسلوب التحقيق عن أي وجود في الشبكة:
في هذه الجزئية من المقالة سوف أقوم بشرح طريقة البروفيسور بروس للتحقيق عن أي عنوان على الشبكة, وفي هذه الحالة سوف نقوم بإستخدام النطاق example.com على سبيل المثال كمشتبه به.
سوف نقوم بسرد الطريقة المفصلة للحصول على جميع المعلومات الخاصة بهذا النطاق بحيث يمكن التعامل معها كدليل جنائي رقمي.
التجهيز لعملية التحقيق:
سوف نقوم بإستخدام لينكس/يونكس لعملية التحقيق حيث سوف نستخدم سطر الأوامر في جميع الخطوات ولن نتطرق للواجهة الرسومية لعدة أسباب سوف نقوم بسردها:
1- أي ملف يتم إنشائه سوف يحتوي في بياناته الوصفية التوقيت الذي تم فيه الحصول على الدليل الرقمي أو الملف.
2- أي دليل يتم الحصول عليه بإستخدام سطر الأوامر سوف يتم تخزينه بداخل ملف مباشرة دون التطرق للنسخ واللصق وبالتالي التجنب من الاخطاء البشرية الممكنة من ذلك.
3- أي عنوان خادم يتم إستخدامه في عملية إستخراج البيانات سوف يتم إيضاح بياناته في الأمر, بالتالي نثبت بأننا أستخدمنا مصادر شرعية وموثوقة في استخراج البيانات.
4- توفير ملف تسجيل لعملية التحقيق كاملة من البداية حتى النهاية, وذلك للعودة لها لاحقاً لدراستها او خلافه.
بعد سرد الاسباب لإستخدام لينكس وسطر الأوامر سوف نبدأ عملية التحقيق, بدايةً نقوم بإنشاء ملف وتشغيل الامر سكريبت لتسجيل جميع الاوامر التي سوف نقوم باستخدامها:
$ mkdir evidence
$ cd evidence
$ script record.txt
الآن سوف نبدأ بالتحقيق عن المشتبه به, قبل البدء سوف اقوم بسرد بعض المفاتيح التي سوف نستخدمها لتسمية الملفات بعد كل امر نقوم بكتابته بصيغة Xfilename حيث حرف الإكس سوف يكون احدى المفاتيح التالية:
W=Whois, N=Nslookup, T=Traceroute
والناتج من عملية التحقيق سوف يكون إجمالي هذه الملفات التي سوف تكون الأساس للتقرير الخاص للتحقيق, مع العلم أنه يجب للمحقق تدوين جميع ما يحدث وجميع الخطوات الخاصة بالتحقيق أيضاً.
بعدما تم التعرف على المفاتيح التي سوف نستخدمها نقوم بكتابة هذا الأمر في سطر الأوامر حتى نثبت أن التوقيت مضبوط في جهاز المحقق :
$ ntpq -p > timesync.txt
مع التنبه بأنه يفضل إستخدام صلاحيات الجذر أو مستخدم لديه صلاحيات لإستخدام الأوامر السابقة والتالية في هذا التقرير. بعد ذلك نقوم بذكر تاريخ التحقيق في التقرير ونستخدم الأمر المعروف:
$ date
عندها سوف نكون قد انتهينا من أساسيات التقرير والآن يمكننا الذهاب إلى الخطوات الرئيسية للتحقيق.
التحقق من الشركة المسجلة للنطاق والمسجل الشخصي (مالك الدومين)
Investigating the Domain Registry and the Registrant:
عملية التحقيق تتكون من مجموعة من الإستطلاعات أو الإستعلامات, لذلك يجب علينا معرفة ماهي خوادم الإستعلام التي قد نتطرق لإستخدامها (معروفة باللغة الإنجليزية whois servers):
1- لعناوين .com, .net و .edu نستخدم الخادم whois.internic.net .
2- لعناوين .org نستخدم whois.pir.org .
3- لعناوين مثل .biz أو .info يمكنكم العثور على الخوادم الخاصة بها من هنا: http://www.iana.org/domains/root/db/ والبحث في قائمة gTLDs .
4- للعناوين الخاصة بالدول مثل .uk أو .sa وخلافه يمكنكم الذهاب لنفس الرابط السابق واختيار الفلتر ccTLDs.
بعدما عرفنا عناوين الخوادم الخاصة بالإستطلاع لنعود للمشتبه به الذي قمنا بإختياره في هذا التقرير كمثال وهو example.com ونقوم بكتابة الأمر التالي:
$ whois -h whois.internic.net example.com > W_DomainRegistry.txt
قد يستغرب بعضكم ! بأن الأمر لم يصدر أي بيانات في سطر الأوامر ويعود السبب لأننا استخدمنا ال ” > ” لتسجيل الناتج من الأمر في الملف W_DomainRegistry.txt, حيث لقرائته يمكننا إستخدام الأمر cat أو more. بعد ذلك نقوم بكتابة البيانات تحت العنوان الجانبي ” Domain Name Registry – بيانات تسجيل النطاق “في التقرير الخاص بالتحقيق, حيث الأمر السابق سوف يزودنا بالبيانات التالية: إسم المسجل للنطاق, عنوان خادم الإستطلاع, الموقع الخاص بالمسجل على الإنترنت.
الآن بعد معرفة خادم الإستطلاع الخاص بالمسجل للنطاق نقوم بإستخدامه لإستخراج البيانات الخاصة بالمسجل الشخصي للنطاق (مالك الدومين)
$ whois -h whois.iana.org example.com > W_DomainOwner.txt
والناتج من الأمر سوف يتم تسجيله تحت العنوان الجانبي ” Domain Owner – المالك الشخصي للنطاق “, مع التنبه والحذر بأن البيانات التي سوف نقوم بإستخراجها قد لا تكون صحيحة, قد تكون مزيفة او مشفرة لذلك لا يجب علينا لوم الشركة المسجلة للنطاق بتاتاً !.
التحقق من مالك الدي إن إس
Investigating the DNS owners:
الأوامر السابقة زودتنا بعنوان خادم الإستطلاع الذي على أساسه سوف نقوم بالتحقق عن طريقه عن مالك الدي إن إس, ونسجل الناتج من الأمر تحت العنوان الجانبي ” DNS Server Owners – ملاك الدي إن إس ” ونكتب الأوامر بنفس الخطوات السابقة :
$ whois -h whois.internic.net iana-servers.net > W_DNSserverRegistry.txt
$ whois -h whois.register.com iana-servers.net > W_DNSserverOwner.txt
في المقالة الأصلية الخاصة بالبروفيسور بروس, للأسف لم يقوم بتسجيل الناتج من الخطوة الأولى في ملف خاص, وهذا قد يؤدي لنقص في الأدلة, لذلك من وجهة نظري الشخصية وبناءاً على أن التحقيق الرقمي يتطلب تسجيل كل صغيرة وكبيرة عن أي عملية تحقيق يجب علينا تسجيل أي أمر يتم كتابته في هذا التحقيق. حيث الطريقة التي أتبعها البروفيسور هي:
$ whois -h whois.internic.net iana-server.net #find registrar
$ whois -h whois.register.com iana-servers.net > W_DNSserver.txt
ونلاحظ بأن في أمره الأول لم يقم بتوجيه الناتج من الأمر إلى أي ملف, فبحكم أن البروفيسور يهدف لإصدار دليل رقمي منظم أؤمن بأن الطريقة التي اتبعتها كان يجب إتخاذها من الأساس لهذا أقترح إضافة عنوان جانبي آخر وهو ” DNS Server Registry – الشركة المسجلة للدي إن إس “.
التحقق من عنوان الآي بي الخاص بملاك الشبكة
Investigating the IP network owners:
بعد جمع البيانات السابقة يجب علينا أيضاً معرفة من المالك لعنوان الآي بي ونبدأ بإستخراج الآي بي أولاً :
$ nslookup www.example.com a.iana-servers.net > N_Website.txt
قد يخبرني البعض بأنه يمكننا إستخدام الأمر nslookup بدون الحاجة إلى ذكر عنوان الدي إن إس, لكن لإثبات بأننا جمعنا المعلومات من مصادر شرعية وموثوقة يجب علينا كتابتها وإظهارها في ملف القضية لتقوية الدليل. والآن بعدما حصلنا على عنوان الآي بي يجب علينا معرفة من هو المالك, ولمعرفته يجب علينا اختيار خادم إستطلاع من القوائم المزودة سابقاً, وبحكم علمنا بأن عنوان الآي بي أمريكي سوف نقوم بإستخدام عنوان خادم الإستطلاع الأمريكي ARIN و هو whois.arin.net وفي حال لم نعرف من الإقليم الخاص بالآي بي نقوم بتجربة جميع عناوين الخاصة بالأقاليم الخمسة حتى نجد الإقليم الصحيح. حسناً لنتابع :
$ whois -h whois.arin.net 192.0.34.166 > W_IPaddress.txt
في هذه الخطوة يجب علينا تسجيل جميع البيانات في التقرير تحت العنوان الجانبي ” Network Owners – ملاك الشبكة “.
التحقق من الدي إن إس العكسي
Investigating the reverse DNS :
إقتباساً من البرفيسور بروس “هنالك المزيد من المعلومات التي يمكن أن نجدها عن ملاك محتملين. وذلك يتم عن طريق الإستعلام عن سجلات بداية السلطة (Start Of Authority – SOA) الخاصة بعناوين in-addr.arpa”. لكتابة الأمر التالي يجب علينا كتابة الخانات الثلاث الأولى من عنوان الآي بي ابتداءاً من اليمين أي بالعكس هكذا:
$ nslookup -type=SOA 34.0.192.in-addr,arpa > N_inaddrarpa.txt
الذي سوف يخرج لنا عنوان خادم المنشأ (Origin Name Server) وهو dns1.icann.org, حيث سوف نقوم بعمل إستطلاع\إستعلام عن المالك الخاص به بإستخدام خادم الإستطلاع whois.pir.org :
$ nslookup -h whois.pir.org icann.org > W_IPDNSserver.txt
ويتم كتابة جميع النواتج تحت نفس العنوان الجانبي السابق ” Network Owners – ملاك الشبكة “.
التحقق من المالك للخادم
Investigating the web server owner:
إذا كان الموقع مستضاف في خادم مشترك, فقد يوجهنا الآي بي الخاص به إلى موقع آخر أو المالك الأصلي للخادم وليس للموقع. لذلك يجب علينا الحصول على النطاق الأصلي لعنوان الآي بي (FQDN – Fully Qualified Domain Name) للخادم. لقد حذرنا البروفيسور في مقالته بأن أي متحكم في المجال الخاص بالآي بي يمكنه تعيين أي مستضيف أو نطاق لعناوين الآي بي. لذلك يجب علينا إستخدام نفس إسم الخادم الذي تم إستخراجه مسبقاً a.iana-servers.net حتى يتم تجاوز هذه العقبة.
$ nslookup 192.0.34.166 a.iana-servers.net > N_IPaddress.txt
وإذا كان الناتج غير متطابق عندها سوف نقوم بإستخراج البيانات عن المستضيف :
$ whois -h whois.inernic.net examplehoster.com > W_WebserverRegister.txt
$ whois -h whois.godaddy.com examplehoster.com > W_Webserver.txt
مره أخرى, قمت بتعديل الأوامر بما أراه أفضل. جميع المعلومات التي تم جمعها في هذا الجزء تسجل تحت العنوان الجانبي “Web Server Owners – مالك خادم الويب”.
التحقق من مزود خدمة الإنترنت
Investigating the upstream ISPs:
بكل بساطة نقوم بإستخدام أمر traceroute لإستخراج بيانات عن مزودي الخدمة كالتالي:
$ traceroute 192.0.34.166 > T_FromMyISP.txt
لإتباع الناتج المعطى من البروفيسور, لقد وجد المزود alter.net في الدورات الاخيرة من الناتج (الناتج يختلف في الوقت الحالي, حيث تقوم ICANN بنفسها بتزويد الخدمة للعنوان), على أي حال يجب علينا عمل إستطلاع للمزود الذي وجدناه بعد كتابة الأمر traceroute:
$ whois -h whois.internic.net alter.net > W_UpstreamISPRegistry.txt
$ whois -h whois.networksolutions.com alter.net > W_UpstreamISP.txt
جميع البيانات التي استخرجناها في هذا الجزء يتم تسجيلها تحت العنوان الجانبي “Upstream ISPs – مزود الخدمة للمشتبه به”.
التحقق من معلومات التوجيه
Investigating the routing information:
الآن يجب علينا تحليل الآي بي الخاص بالمشتبه به في مثالنا هذا للحصول على الرقم المستقل للنظام (Autonomous System Number – ASN) للحصول على معلوماته. قام الدكتور بروس بإختيار العنوان whois.radb.net من http://www.irr.net لأنه يحتوي على سجلات أغلب خوادم التسجيل.
$ whois -h whois.radb.net 192.0.34.166 > W_IRR.txt
والناتج سوف يكون الرقم المستقل للنظام وهو 20144. الذي سوف نستخرج بياناته كالتالي:
$ whois -h whois.arin.net “a 20144” > W_ASOwners.txt
جميع البيانات التي يتم استخراجها يتم تسجيلها تحت العنوان الجانبي ” AS Owners – ملاك النظام المستقل”.
التحقق من الموقع الفعلي
Investigating the physical location:
التحقق من الموقع الفعلي للمشتبه به مهم جداً, لأنه بحكم أننا نعرف المزود الخاص للخدمة يمكننا معرفة شركة الإتصالات المسؤولة لتوفير الخدمة للشخص نفسه التي قد تساعد في الحصول عن العديد من المعلومات والأدلة المؤكدة عن المتهم. في حال كانت هذه البيانات معروفة يجب تسجيلها تحت العنوان الجانبي “Telecommunications Carrier – شركة الإتصالات الناقلة للخدمة”.
التحقق من مالك خادم البريد الإلكتروني
Investigating the email owners:
بمجرد إستخدام الأمر nslookup وتغيير نوع الإستطلاع إلى MX يمكننا الحصول على بيانات خادم البريد.
$ nslookup -type=MX example.com a.iana-servers.net > N_MXServer.txt
بعدها يتم تسجيل الناتج تحت العنوان الجانبي “EMail Server Owner – مالك خادم البريد الإلكتروني”.
توضيب الدليل وحفظه
Packaging and preserving the evidence:
بعد هذا الجزء من أهم الأجزاء لأي محقق جنائي رقمي, لأنه يجب علينا الحرص على عدم حصول أي تغيير في البيانات ولا حتى حرف واحد وإلا بطل الدليل !, قبل الإستمرار يجب علينا إنهاء التسجيل في سطر الأوامر بعدما استخدمنا الأمر script ثم نقوم بضغط الدليل وإستخراج كود الهاش “hash” الذي به سوف نؤكد عدم حصول أي تغيير في البيانات مع عمليات النسخ للدليل وخلافه.
$ exit
$ cd ..
$ tar cvf evidence.tar evidence
ثم نقوم بإستخراج الهاش كالتالي:
$ md5 evidence.tar > evidence.md5
الآن, يجب علينا تسجيل كود الإم دي فايف في التقرير وايضاً يجب أن يتم حفظه في مكان آمن حتى إذا قام محقق آخر بالتحقق في القضية عندها سوف يتأكد من أن البيانات لم يتم تعديلها عن طريق الهاش كود الذي تم استخراجه الذي سوف يؤكد للمحقق الآخر بأن الدليل لم يتم العبث به.
عرض الدليل
Presenting the evidence:
التقرير الذي قمنا بكتابته خلال الخطوات السابقة يحتوي على العديد من جهات الإتصال لكل جهة مسؤولة لكل خدمة. حيث كانت تحتوي على تفاصيل الهويات الخاصة بكل جهة من أسماء, أرقام هاتف, والعديد من البيانات القيمة. وهذا الدليل هو الذي سوف نستخدمه في القضية لإثبات إدانة او براءة المدعى عليه في أي قضية جنائية رقمية.
الخلاصة:
كخلاصة لهذا التحليل, كان من المستحسن للبروفيسور بروس نيكل أن يوضح لنا بعض الطرق التي يمكننا من خلالها إستخراج البيانات المخفاة او المشفرة عن خوادم الإستطلاع. وأيضاً كما تم التوضيح سابقاً أتوقع أن المقالة سوف تكون أكثر وضوحاً لو كانت تحتوي على النواتج الخاصة بالأوامر بحسب ما رآها البروفيسور بروس آنذاك لأنها شكلت عقبة كبيرة أمامي واستنزفت الكثير من وقتي عند تحليل المقالة الخاصة به وتجربة الأوامر شخصياً وتحليل بياناتها. لكن جميع النقاط السابقة ليست ذات إشكالية كبيرة, ولكنها سوف تجعل مقالته أكثر وضوحاً وبالتالي إيصال الصورة كاملة لأي قارئ لمقالاته. لقد أبدع البروفيسور في إيصال فكرته المنهجية وأنا أنصح أي محقق بإتباع نفس هذا الأسلوب أو الأسلوب الذي قمت بطرحه بناءاً على الأساس الذي بناه البروفيسور بروس. أتمنى من الجميع أو من لديه إهتمام قراءة المقالة الأصلية التي نشرها البروفيسور بروس التي قد تحتوي على نقاط أخرى لم أتطرق لها في تحليل.
بعض التحسينات الممكنة للمقالة الأصلية للكاتب بروس:
1- تحديث مقالته, والإعتماد على أدوات أفضل مثل إستخدام dig بدلاً عن nslookup.
2- وضع صور للشاشة لبعض الأجزاء المهمة, وإضافة النواتج للأوامر التي أستخدمها في مقالته.
3- بما أن نظام لينكس/يونكس هو النظام المفضل لإجراء هذا التحقيق, لماذا لا يتم كتابة “باش سكربت – Bash Script” لعملية التحقيق بدلاً من كتابة جميع هذه الأوامر يدوياً ؟
4- توفير نسخة نموذجية من التقرير الناتج من هذا التحقيق.
لماذا نصحت بإستخدام DIG بدلاً عن nslookup ؟
مشكلة nslookup أنه لا يستخدم مكتبات BIND, بل يستخدم أساليبه الخاصة للإستعلام عن أسماء الخوادم. بالرغم أن تصرف nslookup مشابهه جداً للأساليب المتبعة في مكتبات BIND, إلا أنه يختلف قليلاً. آلبيتز و لاي المؤلفين لكتاب nslookup and dig قالوا بأن “nslookup لا يحاكي لا الـresolver (المحلل) ولا الـ name server (إسم الخادم) بالضبط, لكن يحاكيهم بمافيه الكفاية لتكون أداة مقبولة لعملية التحليل”. لذلك آلية عمل nslookup والطريقة التي يتبعها لتحليل خوادم الدي إن إس قد تحتوي على قصور. لذلك ينصح بإستخدام DIG بدلاً عن nslookup. من وجهة نظري الشخصية أتوقع أن DIG يحل العديد من المشاكل التي واجهتها عند إستخدام nslookup من رسائل خطأ وخلافه من المشكلات التي تظهر عند عمل أي تحليل أو إستطلاع. مع العلم أن مطوري BIND باتوا يستنكروا nslookup مؤخراً ! حيث يظهر أنهم لا يهتموا بأداة قديمة جداً !!.
كلمة أخيرة:
انتقادي لـnslookup في هذا التحليل لا يعني بأن هذه الآداة عقيمة, هذه الأداة كانت ولازالت من أفضل الأدوات. لكن نظراً للطريقة التي تتعامل بها هذه الأداة أنا وغيري من المهتمين ننصح بإستخدام DIG. لكن على العموم, لا أتوقع بأن إستخدام nslookup سوف يؤثر حتماً على مجريات التحقيق أو النواتج المخرجة منه, لكن من الأفضل دائماً استخدام البدائل الأفضل في حال وجد البديل لها خاصة إذا كانت تحل القصور الموجودة في البديل القديم.
عن الكاتب:
بحسب الناشر للمقالة الأصلية, بروس ج. نيكّل “يعمل في قسم الحد من المخاطر في بنك “يو بي اس” في مجال التحقيق الجنائي الرقمي, حيث عمل معهم في هذا القسم منذ عام 1997. يحمل شهادة الماجستير في إدارة الشبكات بجانب العديد من الدورات في مجال أمن المعلومات والتحقيق الجنائي الرقمي. حصل بروس نيكل مؤخراً على شهادة الدكتوراة في مجال التحقيق الجنائي الرقمي للشبكات.
أعمال أخرى للكاتب :
Forensic acquisition and analysis of magnetic tapes. Feb (2005).
Generalizing sources of live network evidence. Sep (2005).
Improving evidence acquisition from live network sources. May (2006).
A portable network forensic evidence collector. Oct (2006).
An introduction to investigating IPv6 networks. July (2007).
Forensic analysis of GPT disks and GUID partition tables. Sep (2009).
عن الناشر:
“السيفير” يكنون أنفسهم بالناشر الرائد عالمياً في مجال العلم والمعلومات الصحية. حيث يقوموا بخدمة أكثر من 30 مليون من العلماء,الطلاب, والمحترفين في مجال الطب والمعلومات. مقر الشركة الرئيسي في أمستردام حيث توظف اكثر من 7000 شخص في 24 بلد مختلف حول العالم. يحتوي مجتمعهم على أكثر من 7000 محرر, و 70000 عضو هيئة تحرير, و 300,000 مرجع, و أكثر من 600,000 مؤلف.
التحليل:
من المعروف في هذه الأيام بأن كل جهاز متصل على الإنترنت يحمل عنوان بروتوكول انترنت خاص به المعروف بالآي بي, حيث يقوم بتحديد هوية كل جهاز على الشبكة, ونظراً للتطور العملاق الذي حصل للإنترنت في السنوات الأخيرة, عدد الأجهزة المتصلة بالإنترنت ازداد بشكل خيالي مما أدى لظهور العديد من الخدمات المتوفرة عن طريق الشبكة, مثل البريد الإلكتروني, تطبيقات الشبكة, خدمات قواعد البيانات وخلافه من الخدمات الأخرى التي تديرها مجموعات متخصصه ومنفصلة. ولهذا السبب قام البروفيسور بروس بالإهتمام في ابتكار طريقة منهجية مقترحاً لجميع المهتمين بالمجال الأمني اتباعها للحصول على جميع المعلومات المتعلقة بأي عنوان على الشبكة. هذه الطريقة المنهجية سوف تولد لنا دليل جنائي وتقرير معتمد بطريقة مرتبة موضحة جميع الجهات المسؤولة للعنوان على الشبكة, وكوني مهتم بالمجال الجنائي انا أنصح أي محقق جنائي بإتباع هذا الأسلوب المقترح بالإضافة للإقتراحات التي قمت بها لتعديل بعض الأوامر للحصول على نتيجة أفضل حيث سوف أقوم بسردها بالتفصيل في هذه المقالة.
بدأ البروفيسور بروس مقالته مفصحاً بأن طرق حفظ الخصوصية المتبعة هذه الأيام غالباً مايتم إساءة استخدامها من قبل المجرمين لإخفاء هوياتهم. لذلك, كلما زاد عدد الجهات المسؤولة في وجود أي جهاز على الشبكة يصبح من الصعب لهذا الجهاز او العنوان بأن يكون مجهول كلياً. بعد ذلك تحدث البروفيسور عن الجهات الكبرى المسؤولة لإدارة الخدمات الموجودة على الشبكة. تلك الجهات هي:
مسجلي النطاقات: المجموعات المعروفة بـ Top Level Domain Registrar حيث تكمن مسؤوليتها بتوفير النطاقات لطالبي التسجيل.
طالبي التسجيل “registrants”: الجهات التي تقوم بالذهاب إلى مسجلي النطاقات لتسجيل النطاق. حيث يحمل النطاق المسجل جميع التفاصيل الخاصة بمسجله.
مسؤولي خوادم الدي إن إس: حيث تكمن مسؤوليتهم في التحكم بمجال الدي إن إس وإدارته.
المسؤولين الإقليميين لعناوين الشبكة: تكمن مسؤوليتهم بإدارة عناوين البروتوكول الخاصة بكل قارة تقريباً, حيث تديرها على شكل مجموعات منفصلة مسؤولة. وبناءاً على المعلومات المتوفرة من منظمة المصادر الرقمية هذه الجهات هي:
- ARIN: لقارة أمريكا الشمالية وبعض جزر الكاريبيان.
- LACNIC: لأمريكا الجنوبية وجزر الكاريبيان.
- AfriNIC: لقارة أفريقيا.
- APNIC: لجنوب وجنوب شرق قارة آسيا شاملاً الهند.
- RIPE: لروسيا, اوروبا والشرق الاوسط.
مديري الشبكات: وهي المنظمات المسؤولة لإدارة مجالات معينة من عناوين الآيبي.
مديري خوادم الإنترنت: حيث تكمن مسؤوليتهم بإدارة الخادم وتمكينه لإستضافة وحفظ البيانات, قد يحملوا مسؤولية الهاردوير (الأجهزة الصلبة) أيضاً.
مديري خوادم البريد الإلكتروني: حيث ينقسموا لقسمين, قسم يدير الخوادم الخاصة بتخزين البريد الإلكتروني وحفظه, وقسم آخر مسؤول عن إدارة خوادم إرسال البريد الإلكتروني.
مزود الخدمة: وهم المسؤولين لتوفير الباندويث “كمية نقل البيانات” لمزودي بيانات أصغر, يمتكلوا القدرة أيضاً لمراقبة البيانات وإدارتها وحجبها.
شركات الإتصالات السلكية واللاسلكية: حيث تكمن مسؤوليتهم بالمحافظة على الاتصال بين مزود الخدمة والعميل, وأنا أقصد هنا على سبيل المثال الرابط الفعلي بين العميل ومزود الخدمة.
التوجيه و مسؤولي أنظمة التحكم الذاتي: حيث تكمن مسؤوليتهم بتبادل معلومات التوجيه “Routing Information” مع الأقران “peers”.
أسلوب التحقيق عن أي وجود في الشبكة:
في هذه الجزئية من المقالة سوف أقوم بشرح طريقة البروفيسور بروس للتحقيق عن أي عنوان على الشبكة, وفي هذه الحالة سوف نقوم بإستخدام النطاق example.com على سبيل المثال كمشتبه به.
سوف نقوم بسرد الطريقة المفصلة للحصول على جميع المعلومات الخاصة بهذا النطاق بحيث يمكن التعامل معها كدليل جنائي رقمي.
التجهيز لعملية التحقيق:
سوف نقوم بإستخدام لينكس/يونكس لعملية التحقيق حيث سوف نستخدم سطر الأوامر في جميع الخطوات ولن نتطرق للواجهة الرسومية لعدة أسباب سوف نقوم بسردها:
1- أي ملف يتم إنشائه سوف يحتوي في بياناته الوصفية التوقيت الذي تم فيه الحصول على الدليل الرقمي أو الملف.
2- أي دليل يتم الحصول عليه بإستخدام سطر الأوامر سوف يتم تخزينه بداخل ملف مباشرة دون التطرق للنسخ واللصق وبالتالي التجنب من الاخطاء البشرية الممكنة من ذلك.
3- أي عنوان خادم يتم إستخدامه في عملية إستخراج البيانات سوف يتم إيضاح بياناته في الأمر, بالتالي نثبت بأننا أستخدمنا مصادر شرعية وموثوقة في استخراج البيانات.
4- توفير ملف تسجيل لعملية التحقيق كاملة من البداية حتى النهاية, وذلك للعودة لها لاحقاً لدراستها او خلافه.
بعد سرد الاسباب لإستخدام لينكس وسطر الأوامر سوف نبدأ عملية التحقيق, بدايةً نقوم بإنشاء ملف وتشغيل الامر سكريبت لتسجيل جميع الاوامر التي سوف نقوم باستخدامها:
$ mkdir evidence
$ cd evidence
$ script record.txt
الآن سوف نبدأ بالتحقيق عن المشتبه به, قبل البدء سوف اقوم بسرد بعض المفاتيح التي سوف نستخدمها لتسمية الملفات بعد كل امر نقوم بكتابته بصيغة Xfilename حيث حرف الإكس سوف يكون احدى المفاتيح التالية:
W=Whois, N=Nslookup, T=Traceroute
والناتج من عملية التحقيق سوف يكون إجمالي هذه الملفات التي سوف تكون الأساس للتقرير الخاص للتحقيق, مع العلم أنه يجب للمحقق تدوين جميع ما يحدث وجميع الخطوات الخاصة بالتحقيق أيضاً.
بعدما تم التعرف على المفاتيح التي سوف نستخدمها نقوم بكتابة هذا الأمر في سطر الأوامر حتى نثبت أن التوقيت مضبوط في جهاز المحقق :
$ ntpq -p > timesync.txt
مع التنبه بأنه يفضل إستخدام صلاحيات الجذر أو مستخدم لديه صلاحيات لإستخدام الأوامر السابقة والتالية في هذا التقرير. بعد ذلك نقوم بذكر تاريخ التحقيق في التقرير ونستخدم الأمر المعروف:
$ date
عندها سوف نكون قد انتهينا من أساسيات التقرير والآن يمكننا الذهاب إلى الخطوات الرئيسية للتحقيق.
التحقق من الشركة المسجلة للنطاق والمسجل الشخصي (مالك الدومين)
Investigating the Domain Registry and the Registrant:
عملية التحقيق تتكون من مجموعة من الإستطلاعات أو الإستعلامات, لذلك يجب علينا معرفة ماهي خوادم الإستعلام التي قد نتطرق لإستخدامها (معروفة باللغة الإنجليزية whois servers):
1- لعناوين .com, .net و .edu نستخدم الخادم whois.internic.net .
2- لعناوين .org نستخدم whois.pir.org .
3- لعناوين مثل .biz أو .info يمكنكم العثور على الخوادم الخاصة بها من هنا: http://www.iana.org/domains/root/db/ والبحث في قائمة gTLDs .
4- للعناوين الخاصة بالدول مثل .uk أو .sa وخلافه يمكنكم الذهاب لنفس الرابط السابق واختيار الفلتر ccTLDs.
بعدما عرفنا عناوين الخوادم الخاصة بالإستطلاع لنعود للمشتبه به الذي قمنا بإختياره في هذا التقرير كمثال وهو example.com ونقوم بكتابة الأمر التالي:
$ whois -h whois.internic.net example.com > W_DomainRegistry.txt
قد يستغرب بعضكم ! بأن الأمر لم يصدر أي بيانات في سطر الأوامر ويعود السبب لأننا استخدمنا ال ” > ” لتسجيل الناتج من الأمر في الملف W_DomainRegistry.txt, حيث لقرائته يمكننا إستخدام الأمر cat أو more. بعد ذلك نقوم بكتابة البيانات تحت العنوان الجانبي ” Domain Name Registry – بيانات تسجيل النطاق “في التقرير الخاص بالتحقيق, حيث الأمر السابق سوف يزودنا بالبيانات التالية: إسم المسجل للنطاق, عنوان خادم الإستطلاع, الموقع الخاص بالمسجل على الإنترنت.
الآن بعد معرفة خادم الإستطلاع الخاص بالمسجل للنطاق نقوم بإستخدامه لإستخراج البيانات الخاصة بالمسجل الشخصي للنطاق (مالك الدومين)
$ whois -h whois.iana.org example.com > W_DomainOwner.txt
والناتج من الأمر سوف يتم تسجيله تحت العنوان الجانبي ” Domain Owner – المالك الشخصي للنطاق “, مع التنبه والحذر بأن البيانات التي سوف نقوم بإستخراجها قد لا تكون صحيحة, قد تكون مزيفة او مشفرة لذلك لا يجب علينا لوم الشركة المسجلة للنطاق بتاتاً !.
التحقق من مالك الدي إن إس
Investigating the DNS owners:
الأوامر السابقة زودتنا بعنوان خادم الإستطلاع الذي على أساسه سوف نقوم بالتحقق عن طريقه عن مالك الدي إن إس, ونسجل الناتج من الأمر تحت العنوان الجانبي ” DNS Server Owners – ملاك الدي إن إس ” ونكتب الأوامر بنفس الخطوات السابقة :
$ whois -h whois.internic.net iana-servers.net > W_DNSserverRegistry.txt
$ whois -h whois.register.com iana-servers.net > W_DNSserverOwner.txt
في المقالة الأصلية الخاصة بالبروفيسور بروس, للأسف لم يقوم بتسجيل الناتج من الخطوة الأولى في ملف خاص, وهذا قد يؤدي لنقص في الأدلة, لذلك من وجهة نظري الشخصية وبناءاً على أن التحقيق الرقمي يتطلب تسجيل كل صغيرة وكبيرة عن أي عملية تحقيق يجب علينا تسجيل أي أمر يتم كتابته في هذا التحقيق. حيث الطريقة التي أتبعها البروفيسور هي:
$ whois -h whois.internic.net iana-server.net #find registrar
$ whois -h whois.register.com iana-servers.net > W_DNSserver.txt
ونلاحظ بأن في أمره الأول لم يقم بتوجيه الناتج من الأمر إلى أي ملف, فبحكم أن البروفيسور يهدف لإصدار دليل رقمي منظم أؤمن بأن الطريقة التي اتبعتها كان يجب إتخاذها من الأساس لهذا أقترح إضافة عنوان جانبي آخر وهو ” DNS Server Registry – الشركة المسجلة للدي إن إس “.
التحقق من عنوان الآي بي الخاص بملاك الشبكة
Investigating the IP network owners:
بعد جمع البيانات السابقة يجب علينا أيضاً معرفة من المالك لعنوان الآي بي ونبدأ بإستخراج الآي بي أولاً :
$ nslookup www.example.com a.iana-servers.net > N_Website.txt
قد يخبرني البعض بأنه يمكننا إستخدام الأمر nslookup بدون الحاجة إلى ذكر عنوان الدي إن إس, لكن لإثبات بأننا جمعنا المعلومات من مصادر شرعية وموثوقة يجب علينا كتابتها وإظهارها في ملف القضية لتقوية الدليل. والآن بعدما حصلنا على عنوان الآي بي يجب علينا معرفة من هو المالك, ولمعرفته يجب علينا اختيار خادم إستطلاع من القوائم المزودة سابقاً, وبحكم علمنا بأن عنوان الآي بي أمريكي سوف نقوم بإستخدام عنوان خادم الإستطلاع الأمريكي ARIN و هو whois.arin.net وفي حال لم نعرف من الإقليم الخاص بالآي بي نقوم بتجربة جميع عناوين الخاصة بالأقاليم الخمسة حتى نجد الإقليم الصحيح. حسناً لنتابع :
$ whois -h whois.arin.net 192.0.34.166 > W_IPaddress.txt
في هذه الخطوة يجب علينا تسجيل جميع البيانات في التقرير تحت العنوان الجانبي ” Network Owners – ملاك الشبكة “.
التحقق من الدي إن إس العكسي
Investigating the reverse DNS :
إقتباساً من البرفيسور بروس “هنالك المزيد من المعلومات التي يمكن أن نجدها عن ملاك محتملين. وذلك يتم عن طريق الإستعلام عن سجلات بداية السلطة (Start Of Authority – SOA) الخاصة بعناوين in-addr.arpa”. لكتابة الأمر التالي يجب علينا كتابة الخانات الثلاث الأولى من عنوان الآي بي ابتداءاً من اليمين أي بالعكس هكذا:
$ nslookup -type=SOA 34.0.192.in-addr,arpa > N_inaddrarpa.txt
الذي سوف يخرج لنا عنوان خادم المنشأ (Origin Name Server) وهو dns1.icann.org, حيث سوف نقوم بعمل إستطلاع\إستعلام عن المالك الخاص به بإستخدام خادم الإستطلاع whois.pir.org :
$ nslookup -h whois.pir.org icann.org > W_IPDNSserver.txt
ويتم كتابة جميع النواتج تحت نفس العنوان الجانبي السابق ” Network Owners – ملاك الشبكة “.
التحقق من المالك للخادم
Investigating the web server owner:
إذا كان الموقع مستضاف في خادم مشترك, فقد يوجهنا الآي بي الخاص به إلى موقع آخر أو المالك الأصلي للخادم وليس للموقع. لذلك يجب علينا الحصول على النطاق الأصلي لعنوان الآي بي (FQDN – Fully Qualified Domain Name) للخادم. لقد حذرنا البروفيسور في مقالته بأن أي متحكم في المجال الخاص بالآي بي يمكنه تعيين أي مستضيف أو نطاق لعناوين الآي بي. لذلك يجب علينا إستخدام نفس إسم الخادم الذي تم إستخراجه مسبقاً a.iana-servers.net حتى يتم تجاوز هذه العقبة.
$ nslookup 192.0.34.166 a.iana-servers.net > N_IPaddress.txt
وإذا كان الناتج غير متطابق عندها سوف نقوم بإستخراج البيانات عن المستضيف :
$ whois -h whois.inernic.net examplehoster.com > W_WebserverRegister.txt
$ whois -h whois.godaddy.com examplehoster.com > W_Webserver.txt
مره أخرى, قمت بتعديل الأوامر بما أراه أفضل. جميع المعلومات التي تم جمعها في هذا الجزء تسجل تحت العنوان الجانبي “Web Server Owners – مالك خادم الويب”.
التحقق من مزود خدمة الإنترنت
Investigating the upstream ISPs:
بكل بساطة نقوم بإستخدام أمر traceroute لإستخراج بيانات عن مزودي الخدمة كالتالي:
$ traceroute 192.0.34.166 > T_FromMyISP.txt
لإتباع الناتج المعطى من البروفيسور, لقد وجد المزود alter.net في الدورات الاخيرة من الناتج (الناتج يختلف في الوقت الحالي, حيث تقوم ICANN بنفسها بتزويد الخدمة للعنوان), على أي حال يجب علينا عمل إستطلاع للمزود الذي وجدناه بعد كتابة الأمر traceroute:
$ whois -h whois.internic.net alter.net > W_UpstreamISPRegistry.txt
$ whois -h whois.networksolutions.com alter.net > W_UpstreamISP.txt
جميع البيانات التي استخرجناها في هذا الجزء يتم تسجيلها تحت العنوان الجانبي “Upstream ISPs – مزود الخدمة للمشتبه به”.
التحقق من معلومات التوجيه
Investigating the routing information:
الآن يجب علينا تحليل الآي بي الخاص بالمشتبه به في مثالنا هذا للحصول على الرقم المستقل للنظام (Autonomous System Number – ASN) للحصول على معلوماته. قام الدكتور بروس بإختيار العنوان whois.radb.net من http://www.irr.net لأنه يحتوي على سجلات أغلب خوادم التسجيل.
$ whois -h whois.radb.net 192.0.34.166 > W_IRR.txt
والناتج سوف يكون الرقم المستقل للنظام وهو 20144. الذي سوف نستخرج بياناته كالتالي:
$ whois -h whois.arin.net “a 20144” > W_ASOwners.txt
جميع البيانات التي يتم استخراجها يتم تسجيلها تحت العنوان الجانبي ” AS Owners – ملاك النظام المستقل”.
التحقق من الموقع الفعلي
Investigating the physical location:
التحقق من الموقع الفعلي للمشتبه به مهم جداً, لأنه بحكم أننا نعرف المزود الخاص للخدمة يمكننا معرفة شركة الإتصالات المسؤولة لتوفير الخدمة للشخص نفسه التي قد تساعد في الحصول عن العديد من المعلومات والأدلة المؤكدة عن المتهم. في حال كانت هذه البيانات معروفة يجب تسجيلها تحت العنوان الجانبي “Telecommunications Carrier – شركة الإتصالات الناقلة للخدمة”.
التحقق من مالك خادم البريد الإلكتروني
Investigating the email owners:
بمجرد إستخدام الأمر nslookup وتغيير نوع الإستطلاع إلى MX يمكننا الحصول على بيانات خادم البريد.
$ nslookup -type=MX example.com a.iana-servers.net > N_MXServer.txt
بعدها يتم تسجيل الناتج تحت العنوان الجانبي “EMail Server Owner – مالك خادم البريد الإلكتروني”.
توضيب الدليل وحفظه
Packaging and preserving the evidence:
بعد هذا الجزء من أهم الأجزاء لأي محقق جنائي رقمي, لأنه يجب علينا الحرص على عدم حصول أي تغيير في البيانات ولا حتى حرف واحد وإلا بطل الدليل !, قبل الإستمرار يجب علينا إنهاء التسجيل في سطر الأوامر بعدما استخدمنا الأمر script ثم نقوم بضغط الدليل وإستخراج كود الهاش “hash” الذي به سوف نؤكد عدم حصول أي تغيير في البيانات مع عمليات النسخ للدليل وخلافه.
$ exit
$ cd ..
$ tar cvf evidence.tar evidence
ثم نقوم بإستخراج الهاش كالتالي:
$ md5 evidence.tar > evidence.md5
الآن, يجب علينا تسجيل كود الإم دي فايف في التقرير وايضاً يجب أن يتم حفظه في مكان آمن حتى إذا قام محقق آخر بالتحقق في القضية عندها سوف يتأكد من أن البيانات لم يتم تعديلها عن طريق الهاش كود الذي تم استخراجه الذي سوف يؤكد للمحقق الآخر بأن الدليل لم يتم العبث به.
عرض الدليل
Presenting the evidence:
التقرير الذي قمنا بكتابته خلال الخطوات السابقة يحتوي على العديد من جهات الإتصال لكل جهة مسؤولة لكل خدمة. حيث كانت تحتوي على تفاصيل الهويات الخاصة بكل جهة من أسماء, أرقام هاتف, والعديد من البيانات القيمة. وهذا الدليل هو الذي سوف نستخدمه في القضية لإثبات إدانة او براءة المدعى عليه في أي قضية جنائية رقمية.
الخلاصة:
كخلاصة لهذا التحليل, كان من المستحسن للبروفيسور بروس نيكل أن يوضح لنا بعض الطرق التي يمكننا من خلالها إستخراج البيانات المخفاة او المشفرة عن خوادم الإستطلاع. وأيضاً كما تم التوضيح سابقاً أتوقع أن المقالة سوف تكون أكثر وضوحاً لو كانت تحتوي على النواتج الخاصة بالأوامر بحسب ما رآها البروفيسور بروس آنذاك لأنها شكلت عقبة كبيرة أمامي واستنزفت الكثير من وقتي عند تحليل المقالة الخاصة به وتجربة الأوامر شخصياً وتحليل بياناتها. لكن جميع النقاط السابقة ليست ذات إشكالية كبيرة, ولكنها سوف تجعل مقالته أكثر وضوحاً وبالتالي إيصال الصورة كاملة لأي قارئ لمقالاته. لقد أبدع البروفيسور في إيصال فكرته المنهجية وأنا أنصح أي محقق بإتباع نفس هذا الأسلوب أو الأسلوب الذي قمت بطرحه بناءاً على الأساس الذي بناه البروفيسور بروس. أتمنى من الجميع أو من لديه إهتمام قراءة المقالة الأصلية التي نشرها البروفيسور بروس التي قد تحتوي على نقاط أخرى لم أتطرق لها في تحليل.
بعض التحسينات الممكنة للمقالة الأصلية للكاتب بروس:
1- تحديث مقالته, والإعتماد على أدوات أفضل مثل إستخدام dig بدلاً عن nslookup.
2- وضع صور للشاشة لبعض الأجزاء المهمة, وإضافة النواتج للأوامر التي أستخدمها في مقالته.
3- بما أن نظام لينكس/يونكس هو النظام المفضل لإجراء هذا التحقيق, لماذا لا يتم كتابة “باش سكربت – Bash Script” لعملية التحقيق بدلاً من كتابة جميع هذه الأوامر يدوياً ؟
4- توفير نسخة نموذجية من التقرير الناتج من هذا التحقيق.
لماذا نصحت بإستخدام DIG بدلاً عن nslookup ؟
مشكلة nslookup أنه لا يستخدم مكتبات BIND, بل يستخدم أساليبه الخاصة للإستعلام عن أسماء الخوادم. بالرغم أن تصرف nslookup مشابهه جداً للأساليب المتبعة في مكتبات BIND, إلا أنه يختلف قليلاً. آلبيتز و لاي المؤلفين لكتاب nslookup and dig قالوا بأن “nslookup لا يحاكي لا الـresolver (المحلل) ولا الـ name server (إسم الخادم) بالضبط, لكن يحاكيهم بمافيه الكفاية لتكون أداة مقبولة لعملية التحليل”. لذلك آلية عمل nslookup والطريقة التي يتبعها لتحليل خوادم الدي إن إس قد تحتوي على قصور. لذلك ينصح بإستخدام DIG بدلاً عن nslookup. من وجهة نظري الشخصية أتوقع أن DIG يحل العديد من المشاكل التي واجهتها عند إستخدام nslookup من رسائل خطأ وخلافه من المشكلات التي تظهر عند عمل أي تحليل أو إستطلاع. مع العلم أن مطوري BIND باتوا يستنكروا nslookup مؤخراً ! حيث يظهر أنهم لا يهتموا بأداة قديمة جداً !!.
كلمة أخيرة:
انتقادي لـnslookup في هذا التحليل لا يعني بأن هذه الآداة عقيمة, هذه الأداة كانت ولازالت من أفضل الأدوات. لكن نظراً للطريقة التي تتعامل بها هذه الأداة أنا وغيري من المهتمين ننصح بإستخدام DIG. لكن على العموم, لا أتوقع بأن إستخدام nslookup سوف يؤثر حتماً على مجريات التحقيق أو النواتج المخرجة منه, لكن من الأفضل دائماً استخدام البدائل الأفضل في حال وجد البديل لها خاصة إذا كانت تحل القصور الموجودة في البديل القديم.
0 التعليقات:
إرسال تعليق