هذا المقال مكون من جزئين: أحدهما دراسة استقصائية عن تكنولوجيا مصائد مخترقي الشبكات “Honeypot” والآخر حالة دراسية تصف مصائد low-interaction وتنفيذها في تطبيقات جافا. تعطي الدراسة الاستقصائية لمحة موجزة عن مفاهيم Honeypot وتشير الى أعمال أكثر تفصيلا .اما الحالة الدراسية المطبقة تتضمن العديد من القرارات اللازمة عند تصميم مصائد low-interaction
المقدمة:
في هذا القسم سوف نصف نظام كشف التسلل الى الشبكات، كنهج تقليدي لأمان الشبكة. وتالياً سنقوم بتقديم لمحة تاريخية موجزة عن honeypots.
سيختتم الجزء بمناقشة عامة عن مزايا وعيوب ال honeypots.
1.1 أنظمة كشف تسلل الشبكات
الهدف من نظام كشف التسلل (IDS ) هو “التحديد، والتفضيل في نفس الوقت ، وكشف الاستخدام غير المصرح به و إساءة استخدام أنظمة الكمبيوتر من داخل او خارج الشبكة .
يتم استخدام (IDS ) كبديل (أو تكملة) لبناء جدار حول الشبكة. جدران الحماية احيانا غير فعالة في بعض الحالات ، بما في ذلك الفشل في منع الهجمات من داخل الشبكة.
على الرغم أن الأساسات وضعت لأنظمة الكشف، الا أنها لم تكن موضوعة حتى عمل paxson في عام 1998 على ان تصبح أساليب بناء أنظمة الكشف في الوقت المناسب متاحة للجميع .
يقوم النظام بتحويل تيار من الحزم في سلسلة من احداث الشبكة الرفيعة المستوى التي يمكن تحليلها حسب نظام السياسة الأمنية .
منذ 1999، امتد هذا العمل ليتضمن تقنيات تعليم الآلات المتقدمة بالإضافة الى كشف افضل عن التهديدات مثل هجمات الحرمان من الخدمة . ومع ذلك، في حين ان IDS لا زالت تتقدم ، الا أن طرق إحباط IDSs أصبحت أكثر انتشارا .
على سبيل المثال، Wagner و Soto قاما بتطوير فئة من الهجمات المحاكيه التي تحاكي السلوك الاصلي للتطبيق ، وفي ضوء هذه الهجمات المحاكيه كذلك الإنتشار المتزايد للإتصالات المشفرة ، فإن البدائل مثل honeypots أصبحت أكثر شعبية.
1.2 مصائد مخترقي الشبكات “Honeypot “
التعريف الدقيق للHoneypot مثير للجدل، ولكن معظم التعاريف تتضمن ما يلي:
Honeypot هو “مصدر معلومات خاصة بالنظام والتي تحتوي على معلومات خاصة بالاستخدام غير المصرح به أو غير المشروع ” (www.securityfocus.com)
وتعريف اخر اكثر عملية ،ومحدودية ، من pcmag.com:
” خادم تم اعداده للكشف عن المتسلل بواسطة محاكاه الواقع الافتراضي للسيرفرات. اذ يبدو كخادم عادي يقوم بالعمل، ولكن كل البيانات والمعاملات مزيفه. تقع إما في أو خارج جدار الحماية، ويتم استخدام المصيدة لمعرفة المزيد عن تقنيات المتسلل وكذلك تحديد نقاط الضعف في النظام الحقيقي .
في الممارسة العملية، فإن المصائد” Honeypots” عبارة عن أجهزة كمبيوتر غير محمية .
في المصيدة يتم تسجيل كل الإجراءات والتفاعلات مع المستخدمين. حيث ان مصائد مخترقي الشبكات لا توفر أي خدمات حقيقه ، قد يكون بعضها مزيف او ضار . Talabis يقدم مصائد يمكنها الكشف عن المتسللين بدقة عاليه .
1.3 تاريخ مصائد مخترقي الشبكات:
كانت أول مصيدة متوفرة للعلن هي Deception ToolKit ل Fred Cohen في عام 1998 والتي كان “يهدف لجعلها تبدو للمهاجمين كما لو [كان] في نظام تشغيل DTK عدد كبير من نقاط الضعف المعروفة على نطاق واسع.
أصبحت أكثر مصائد مخترقي الشبكات متاحة سواء علناً أو تجارياً في أواخر التسعينات. كما بدأت الديدان ” worms ” تتكاثر في بداية عام 2000، أثبتت مصائد مخترقي الشبكات ضرورة التقاط وتحليل الديدان.
في عام 2004، تم إدخال مصائد مخترقي الشبكات الافتراضية التي تسمح بتشغيل مصائد متعددة على خادم واحد .
1.4 أنواع honeypots:
هناك نوعان شائعان من فئات مصائد مخترقي الشبكات المتاحة اليوم، وهما high-interaction و low-interaction . يتم تعريف هذه الفئات على أساس الخدمات، أو مستوى التفاعل، التي تقدمه المصيدة للقراصنة المحتملين .
تتيح مصائد High-interaction للقراصنة التفاعل مع النظام كما يفعلون بأي نظام تشغيل عادي، بهدف الاستيلاء على أكبر قدر ممكن من المعلومات عن تقنيات المهاجم.
أي أمر أو طلب يتوقعه المستخدم النهائي ليتم تثبيته متاح وبشكل عام، هناك القليل من القيود الموضوعة على ما يمكن للمخترق القيام به بمجرد انه / انها اخترق للنظام.
بينما مصائد low-interaction, تقدم للقراصنة خدمات محاكاة مع مجموعة فرعية محدودة من الوظائف التي يتوقعونها من الخادم، بهدف الكشف عن مصادر النشاط الغير مصرح به. على سبيل المثال، فإن خدمة HTTP على مصيدة low-interaction تدعم فقط الأوامر اللازمة لتحديد أن هناك محاولة استغلال معروفة .
بعض المؤلفين يصنفون مصائد مخترقي الشبكات الى فئة ثالثة، وهي medium-interaction ، حيث توفر تفاعلاً اكبر من مصائد low-interaction ، ولكن أقل من أنظمة high-interaction . مصيدة medium-interaction قد تنفذ و بشكل كامل بروتوكول HTTP لمحاكاة تنفيذية لمورد معروف ، مثل Apache . ومع ذلك، لا توجد تطبيقات من مصائد medium-interaction وفي هذا المقال ، فإن تعريف مصائد low-interaction يتضمن وظائف مصائد medium-interaction وذلك لأنها لا توفر سوى تنفيذ جزئي للخدمات ولا تسمح بالتفاعل النموذجي الكامل مع النظام مثل مصائد high-interaction .
1.5 مزايا وعيوب عامة ل Honeypots:
توفر مصائد مخترقي الشبكات العديد من المزايا من خلال بعض الحلول الأمنية، بما في ذلك أنظمة كشف تسلل الشبكات:
- ايجابيات كاذبة أقل نظرا لعدم استخدام المصيدة في حركات المرور الشرعية
- جمع قواعد بيانات صغيرة، ذات قيمة عالية، لأنها تسجل نشاط غير شرعي فقط
- العمل في بيئات مشفرة
- لا تتطلب توقيع هجوم معروف، على عكس IDS .
مصائد مخترقي الشبكات ليست مثالية، على الرغم من أنه :
- يمكن استخدامها من قبل المهاجمين لمهاجمة الأنظمة الأخرى .
- مراقبة التفاعلات تتم فقط مباشرة مع المصيدة – كما أنه لا يمكنها الكشف عن الهجمات ضد ألأنظمة ألاخرى
- يحتمل أن يتم كشفها من قبل المهاجم
الحلول الأمنية التقليدية ، مثل أنظمة كشف التسلل، قد لا تكون كافية في ضوء الهجمات ألاكثر تعقيداً . توفر مصائد مخترقي الشبكات آلية للكشف عن الهجمات الغير مألوفه ، وحتى في البيئات المشفرة. وقد حققت تقدماً مثل المحاكاة الافتراضية حيث جعلت مصائد مخترقي الشبكات “Honeypots ” أكثر فعالية. كما أن مصائد مخترقي الشبكات لها عيوب، على الرغم من ذلك فمن المهم أن نفهم كيف تعمل مصائد مخترقي الشبكات من أجل تعظيم فعاليتها.
2. آخر الاتجاهات والتطورات :
في هذا القسم، سوف نناقش الاتجاه نحو تجميع ال honeypots إلى honeynets أو honeyfarms . ال shadow Honeypots و distributed honeypots ، كلاهما تقنيات حديثة ،وسيتم عرضها لاحقاً .
2.1 Honeynets و Honeyfarms
Honeynets وhoneyfarms هي أسماء تعطى لمجموعات من مصائد مخترقي الشبكات . Honeyfarms تميل إلى أن تكون أكثر مركزية. توفر مصائد مخترقي الشبكات تجميعا للعديد من الاتفاقيات التي تساعد على تخفيف الكثير من أوجه القصور في مصائد مخترقي الشبكات التقليدية. على سبيل المثال، غالبا مصائد مخترقي الشبكات تقييد حركة المرور الصادرة من أجل تجنب مهاجمة غير المصيدة. ومع ذلك، يسمح هذا القيد بكشف هوية مصائد مخترقي الشبكات للمهاجم. He et al . استخدم honeyfarms كنقاط لإعادة توجيه حركة المرور الصادرة من كل مصيدة فردية. هذه النقاط الموجهة تتصرف أيضاً مثل الضحايا الحقيقيين. ويبين الشكل (1) إعادة توجيه لحركة المرور الصادرة من مصيدة إلى نقطة أخرى في honeyfarm.
![fig1]()
2.2 Shadow Honeypots:
Shadow Honeypots هي عبارة عن مزيج من honeypots وأنظمة الكشف عن الشذوذ (ADS)، والتي تعتبر بديل آخر لأنظمة كشف التسلل المستندة إلى بعض القواعد .يمكن العثور على مقارنة بين ADS مع أنظمة كشف أخرى من هنا .
Shadow honeypots أولاً تُفصل الحركات الشاذة من حركات المرور العادية. يتم إرسال حركة المرور الشاذة إلى Shadow honeypot التي تعتبر خدمة شرعية كما هو مبين في الشكل 2.
إذا تم الكشف عن هجوم من قبل Shadow honeypot ، يتم تجاهل أي تغييرات في الأوامر في المصيدة. غير ذلك، يتم التعامل مع العملية والتغيرات بشكل صحيح. في حين تتطلب Shadow honeypots الكثير من الأعباء ، الا أنها مفيدة لأنها تكشف عن الهجمات المحتملة إثر حالة الخدمة. وتقدم دراسات تنفيذية .![fig2]()
2.3 Distributed Honeypots
إحدى سيئات honeypots هو أنها يجب أن تأخذ جزءا كبيرا من مساحة العنوان من أجل أن تكون فعالة ومفيدة (حيث ان المهاجمين و البرمجيات الخبيثة يجب أن تستهدف honeypots).
Yang et al . وفر إطارا موزعا للحوسبة الشبكية حيث يقوم المضيف المشروع بإعادة توجيه المستخدمين المشبوهين الى مصيدة واحدة .
ويتم استخدام بديل من قبل Honey@home وفيها كل عميل مسؤول عن عنوان IP واحد غير مستخدم . يتم إعادة توجيه حركة مرور العميل بشكل مجهول من خلال شبكة Tor إلى مجموعة من مصائد مخترقي الشبكات المتوسطة
Honeyfarms ،honeynets, distributed honeypots جميعها تعزز الحاجة إلى رصد مجموعة كبيرة من عناوين الشبكة من أجل أن تكون المصيدة فعالة. كما تم مناقشته في القسم 2.1، تجميع honeypots يمكنه أيضا إضافة وظائف لhoneypots عن طريق السماح للعمليات كالمحاكاة الصادرة عن حركة المرور.
3 منتجات honeypot الحالية :
في هذا القسم، سوف نقدم شرحاً موجزا جداً عن Honeyd و HoneyBot، و Specter honeypots. وسوف نصف ما يميز المنتج ونوفر معلومات مرجعية لكل واحدة منها . من ثم سنقدم المشورة للاختيار بين الحلول.
3.1 Honeyd
Honeyd هي مصيدة Linux /Unix التي وضعها الباحث الأمني Niels provos .
Honeyd فتحت آفاقا جديدة حيث أنه يمكنها أن تنشئ عدد من المضيفين الظاهريين على الشبكة (بدلا من مجرد استخدام مضيف فعلي واحد).
يمكن للمصيدة محاكاة أنظمة تشغيل مختلفة (والتي تختلف في كيفية الرد على بعض الرسائل) والخدمات.
حيث أن Honeyed تحاكي أنظمة التشغيل على مستوى حزمة TCP / IP، يمكنها حتى خداع أدوات تحليل الشبكة المتطورة مثل Nmap . و رجوعا للهجوم، يمكن ل Honeyd محاولة التعرف على المضيف البعيد . الموقع الرسمي لمشروع Honeyd .
3.2 HoneyBOT
honeybot هي عبارة عن Windows medium-interaction honeypot مقدمة من قبل Atomic Software Solutions
حيث بدأت في الأصل كمحاولة للكشف عن رمز Red and Nimda worms في عام 2001 واصبحت مجانية الاستخدام للجميع منذ 2005.
HoneyBot تسمح للمهاجمين بتحميل الملفات إلى منطقة محجورة من أجل كشف حصان طروادة والجذور الخفية. واجهة مستخدم HoneyBot مبينة في الشكل 3.
![fig3]()
3.3 Specter
مصممين Specter يصفونه بأنه “نظام لكشف التسلل القائم على المصيدة”. ومع ذلك، فإن المنتج في الأصل مصيدة تهدف الى جذب المهاجمين بعيدا عن نظم الإنتاج وجمع الأدلة ضد المهاجمين. Specter لديه بعض الميزات المثيرة للإهتمام التي لا توجد في غيرها من الحلول:
- Specter يجعل شرك البيانات متاحة للمهاجمين للوصول والتنزيل.ملفات البيانات هذه تترك علامات على كمبيوتر المهاجم كدليل
- يمكن ل Specter محاكاة الآلات في حالات مختلفة: نظام مكون بشكل سيئ أو نظام مؤمن أو نظام تالف (مع فشل الأجهزة أو البرمجيات )، أو نظام لا يمكن التنبؤ به.
- Specter يقوم بمحاولات نشطة لجمع المعلومات عن كل مهاجم.
ويبين الشكل 4 مركز تحكم Specter الرئيسي . يمكن العثور على Specter على الانترنت http: //www.specter.com
![fig4]()
3.4 المقارنة:
HoneyBOT هو وسيلة رائعة لبدء استكشاف عالم مصائد مخترقي الشبكات . على الرغم من أنها تفتقر إلى وظائف Honeyd و Specter (ومغلقة المصدر) إلا أنها تسمح للمستخدمين بتشغيل المصيدة بسرعة. و كمصيدة مفتوحة المصدر، Honeyd مرنة تماما. رغم أن لديها العديد من الميزات المعقدة، مثل تكنولوجيا تصميم الشبكة الظاهرية ، إن تكنولوجيا المصيدة الأساسية سهلة الاستخدام.
Specter مغلق المصدر وغير حر. ولكن، كمنتج تجاري، فقد تم الاهتمام كثيرا ببناء واجهة المستخدم الرسومية والنظام المساعد فية . وعلاوة على ذلك، فإنه يشمل العديد من (التكنولوجيا وبراءات الاختراع المنتظرة ) والفريدة من نوعها. على سبيل المثال، يمكن ل Specter ترك علامات قابلة للتحقق على أجهزة المهاجم. ويقدم الجدول 1 مقارنة موجزة لمصائد مخترقي الشبكات
![Screenshot_2016-09-07-03-48-58-1]()
4 HoneyRJ: حالة دراسية تنفيذية لمصيدة low-interaction:
تطبيق، HoneyRJ، هو تنفيذ لمصيدة low-interaction . كما هو محدد أعلاه، مصيدة low-interaction تخدم عددا من البروتوكولات محدودة الوظائف بقصد الاستيلاء على المصدر من حركة المرور القادمة إلى المصيدة. تقع المصيدة في عنوان IP والذي يتم استخدامه فقط لغرض المصيدة وليس لأي خدمات مشروعة. أن أية اتصالات إلى أن البرنامج يتم اعتبارها خبيثة ويتم تسجيلها لفحصها في وقت لاحق .
وقد تم تصميم HoneyRJ لتكون بسيطة للغاية وقابلة للتمديد بسهولة. تعكس قرارات التصميم لدينا الرغبة في إنشاء تطبيق بسيط حيث يوضح مفهوم مصيدة low-interaction ، ويسمح لأي شخص لديه الحد الأدنى من المعرفة التقنية لتوسيع نطاق التطبيق ليشمل البروتوكولات المرجوة منه.
4.1 الميزات التنفيذية
HoneyRJ يدعم الميزات الأساسية التالية:
- دعم لبروتوكولات متعددة – يدعم التطبيق إضافة أي بروتوكول يريده المستخدم الى برنامج من خلال تنفيذ واجهة جافا المقدمة. أي فئة تنفذ الواجهة يمكن أن تضاف إلى تطبيق HoneyRJ وسوف يتفاعل HoneyRJ مع العملاء وفقا للمنطق المعرف في تلك الفئة. انظر للقسم 4.4 للحصول على تفاصيل بشأن تنفيذ البروتوكولات.
- لا يوجد حد لعدد اتصالات العميل – HoneyRJ يحتوي على تصميم متعدد الخيوط بحيث يمكن الاستماع للاتصالات والتحدث مع أي عدد من العملاء في وقت واحد.
- التسجيل – يقوم HoneyRJ بإنشاء ملف تسجل لكل اتصال ويسجل كل الحزم المرسلة والمستلمة.
- الواجهة الرسومية – يقدم HoneyRJ واجهة مستخدم رسومية بسيطة “GUI” للسماح للمستخدم السيطرة على التطبيق .
- قابلية التهيئة -يمكن تهيئة التطبيق في وقت التحويل البرمجي لضبط العديد من الخيارات.
فيما يلي ميزات الوقاية من هجمات الحرمان من الخدمات “DOS” التي تنفذ في HoneyRJ:
- انتهاء وقت محاولة الاتصال: قد يحاول احد القراصنة شن هجوم DOS على مصيدة من خلال فتح عدد كبير من الاتصالات وتركها في حالة خمول. هذا من شأنه منع المسؤول أو هاكر آخر من فتح اتصال إلى جهاز يشغيل HoneyRJ لأن نظام التشغيل سيكون قد استنفد موارد شبكته. سيتم إغلاق جميع اتصالات HoneyRJ بعد انقضاء مهلة فترة التهيئة (افتراضيا بعد دقيقتين). إذا كان الاتصال خاملاً لحين انتهاء المهلة ، سوف يقوم HoneyRJ بإغلاق الإتصال وإذا لم يصبح خاملا فسيقوم HoneyRJ بإغلاق الإتصال بشكل إجباري بعد وصوله لفترة المهلة
- فترة الانتظار لاتصالات متعددة: قد يحاول القراصنة شن هجوم DOS على المصيدة من خلال فتح إتصالات بسرعة، ويحتمل استخدام كمية كبيرة من موارد النظام. هذا من شأنه منع المصيدة من التقاط حركة المرور من قراصنة آخرين أو بدء إتصالات جديدة. وتفرض HoneyRJ فترة من الزمن للتهيئة (افتراضيا، 5 ثواني) بين الاتصالات المتزامنة على البروتوكول. خلال هذه الفترة، لا يمكن للهاكر إنشاء اتصالات جديدة إلى البروتوكول.
4.2 تصميم التطبيق
يقدم هذا القسم لمحة عامة عن عملية تصميم التطبيق، بما في ذلك قرارات ما قبل التصميم، وقرارات التصميم ذات الصلة والوثائق على الأجزاء الداخلية للتطبيق. وقد قمنا بإختيار اللغة التطويرية والبيئة، ومن ثم قمنا بإعطاء نظرتنا على قرارات التصميم الرئيسية بما في ذلك تصميم المؤشرات وشكل التسجيل بالإضافة إلى الآثار الأمنية . وأخيرا، قمنا بتوثيق التدفق الداخلي للتطبيقات ، و وضعنا قسماً عن كيفية كتابة وتثبيت بروتوكول إضافي لHoneyRJ.
4.2.1 اختيار اللغة التطويرية
اخترنا جافا “Java” كلغة التطوير لعدة أسباب. أولا، نحن على دراية بلغة جافا من خلال الدورات السابقة وخبراتنا في الخارج، مما يتيح لنا تركيز وقتنا في التصميم والتطوير، وليس في تعلم اللغة. ثانيا، توفر جافا مآخذ تنفيذية رفيعة المستوى ومستقرة وسهلة الاستخدام، لذلك نحن لسنا بحاجة لتعلم مأخذ البرمجة ذات المستوى المنخفض، مما يسمح لنا بالتركيز على التصميم والتطوير. وأخيرا، تقدم جافا مكتبة مؤشرات ممتازة والتي خففت تنفيذنا للHoneyRJ كتطبيق متعددة المؤشرات.
4.2.2 اختيار بيئة التطوير المتكاملة (IDE)
IDE هو تطبيق يوفر لمطوري البرمجيات بيئة تخفف المهام ذات الصلة ببرمجة البرمجيات. اخترنا Eclipse ك DIE حيث نطور المشروع.
Eclipse منتج حر مفتوح المصدر و معتمد من قبل Washington University CEC . ويوفر جميع الميزات التي قد نتوقعها تطبيقات IDE الحديثة: رمز الانتهاء و اعادة الهيكلة وإدارة الحزم .
وقد تم بناء Eclipse أيضا لدعم javadoc، الذي يسمح بالاشتقاق السهل لوثائق شفرة المصدر . نحن على دراية وثيقة في بيئة Eclipse من خلال الدورات الدراسية والخبرات الخارجية، مما يسمح لنا ببدء البرمجة دون منحنيات التعلم المرتبطة في بيئات IDE الغير مألوفة.
4.2.3 قرارات التصميم
وقد قمنا بتلخيص افكارنا وراء قرارات التصميم التي وقعت مع تطوير HoneyRJ. ونتيجة كل قرار ملخصة في الاسفل ، بالإضافة الى التفاصيل المقدمة عن كيفية وصولنا لهذا القرار. قراراتنا تتبع رغبتنا في إنشاء مصيدة low-interaction بسيطة، لكن قابلة للتشعب بما يكفي لتشغيل بروتوكولات متعددة والتحدث مع العديد من العملاء في وقت واحد.
4.2.3.1 تشعبات متعددة لدعم اتصالات متعددة
يمكن ل HoneyRJ الاستماع على بروتوكولات متعددة ويمكنه التحدث مع العديد من العملاء على كل بروتوكول في آن واحد. قررنا تصميم HoneyRJ لدعم اتصالات متعددة لأنه بخلاف ذلك سيكون التطبيق محدودا للغاية من حيث فائدته كمصيدة: يمكن للتطبيق تسجيل دخول اتصال هاكر واحد فقط في نفس الوقت . بوجود اتصال واحد متوفر فقط، فإنك لن تكون قادرا على تشغيل بروتوكولات متعددة أو رؤية وصلات متعددة من هاكر واحد . وهذا من شأنه أن يحد من فائدة من البيانات التي تم جمعها من قبل HoneyRJ وبالتالي قررنا أن ننفذ HoneyRJ كتطبيق متعدد التشعبات.
إن تصميمنا متعدد التشعبات مبني على أساس التصميم في قسم “Supporting Multiple Clients ” من مقال Java Sockets.
كل بروتوكول فعال في HoneyRJ لديه مؤشر يستمع للاتصالات على المخارج. كما هو مبين في الشكل 5، عندما يتلقى اي مؤشر اتصال، يتم اطلاق مؤشر ترابط فعال للتحدث مع العميل المتصل، بينما يستمر مؤشر الترابط الرئيسي بالاستماع على الاتصالات. هذا التصميم يتيح للتطبيق الاستماع على منافذ متعددة ، والتحدث مع عدة عملاء في نفس الوقت .
![fig5]()
4.2.3.2 تسجيل الدخول إلى الملفات النصية البسيطة:
HoneyRJ يخزن سجل الملفات كوثائق نصية في الدليل المحلي، ويقوم بتحديثها كلما تقدم الاتصال . قررنا تخزين السجلات كوثائق نصية بسيطة للسماح للمستخدم قراءتها بسهولة والسماح بالتحليل من قبل طرف ثالث . بدلا من ذلك، كان بإمكاننا تخزين ملفات السجل كسلسلة للوازم جافا ؛ ولكن ذلك سيتطلب تطبيقاً للمعاينة والذي سيمنع التحليل البسيط في المستقبل.
اخترنا تحديث ملف السجل باستمرا كلما تقدم الاتصال للسماح للمستخدم بمراقبة الإتصالات الفعالة عن طريق عرض ملف السجل ، وهذا يوفر للمستخدم مرونة أكبر من كتابة ملفات السجل في نهاية الاتصالات يحمي من فقدان بيانات السجل في حال انهيار التطبيق . وأخيرا، إذا كان المستخدم يرغب في مشاهدة ملفات السجل المكتملة فقط، فيمكنه اختيار فتح الملفات النصية فقط و التي تمثل الاتصالات المغلقة .
إن تنسيق ملفات السجل معرف في القسم 5.2.1 من دليل المستخدم، وهو مبني على تنسيق ipfw لملف السجل .
اخترنا لتخزين الطابع الزمني و إرسال واستقبال عناوين بروتوكول الإنترنت و المنافذ و محتويات الحزمة لأن هذه المعلومات ذات صلة مباشرة بتحديد مكان وجود العملاء وأعمالهم فور اتصالهم.
4.2.3.3 انشاء بروتوكلين اضافيين بسهولة:
يوفر HoneyRJ القدرة على إنشاء بروتوكول جديد عن طريق تطبيق واجهة جافا المقدمة. لقد قمنا بتصميم التطبيق بهذه الطريقة للسماح للمستخدم بإرسال بروتوكولات إضافية تتجاوز البروتوكولات العينة المقدمة مع HoneyRJ. البروتوكولات الغير قياسية (على سبيل المثال، بروتوكول معين لمنتج شركة) يمكن أن يكتب لHoneyRJ باستخدام هذه البنية. وبالإضافة إلى توفير درجة عالية من التخصيص للمستخدم النهائي، فإن قرار التصميم هذا جعل تنفيذ البروتوكولات العينة بسيطاً . عملية كتابة بروتوكول موصوفة بمزيد من التفصيل في القسم 4.4 من تنفيذ البروتوكولات الإضافية.
4.2.3.4 دعم للبروتوكولات المبنية على السلاسل
يعتمد HoneyRJ فقط على البروتوكولات القائمة على السلاسل ولا يدعم نقل البيانات الثنائية. قمنا بتنفيذ HoneyRJ بهذه الطريقة في المقام الأول للبساطة. ومع ذلك، هناك تداعيات أمنية تتعلق بالسماح للمستخدمين بتحميل الملفات الثنائية. على سبيل المثال، يمكن للهاكر تحميل ملف ثنائي مع فيروس ومن ثم تنفيذه من خلال هجوم تجاوز سعة المخزن المؤقت الموجود في نظام تشغيل HoneyRJ. العديد من البروتوكولات قائمة على النصوص وبالتالي HoneyRJ قادر على دعم معظم البروتوكولات ألتي يريد المستخدم تنفيذها.
4.2.3.5 منع هجوم DOS
تم تصميم HoneyRJ مع مهلة اتصال وفترة انتظار بين الاتصالات إلى البروتوكول. هذا التصميم يمنع هحمان الحرمان من الخدمة من قبل المستخدمين الخبيثين . وقد ادرجنا هذه الضمانات لأن الجمهور المستهدف الذي سيتصل ب HoneyRJ غير موثوق وفي الواقع، يقومون بإتصالات خبيثة فقط. بدون هذه الضمانات سيتمكن، القراصنة من شن هجوم DOS ضد الآلة التي تشغل HoneyRJ . أي اتصال بقي مفتوحاً ل HoneyRJ سيتم تلقائيا قطعه بعد انتهاء مهلة التهيئة (افتراضيا، بعد دقيقتين ). وهذا يمنع القراصنة من ترك الآلاف الاتصالات مفتوحة وبالتالي يمنع المستخدمين الآخرين أو المسؤول من الاتصال بالجهاز الذي يشغل HoneyRJ . وبالإضافة إلى ذلك، بمجرد يقبل البروتوكول الاتصال، سوف ينتظر فترة من الزمن للتهيئة (افتراضيا، 5 ثواني) قبل قبول آخر إتصال على ذاك البروتوكول. هذا يمنع المستخدم من افتتاح عدد كبير من الاتصالات في فترة قصيرة من الزمن.
4.3 المكونات الداخلية للتطبيق:
يصف هذا القسم تدفق الأحداث داخل HoneyRJ عندما يتم تشغيل التطبيق، وعند إضافة وبدأ وحدة نمطية. هذا القسم يشير الى فئات non-GUI فقط، حيث أن واجهة المستخدم الرسومية توفر وظيفة تغليفية فقط لهذه الفئات.
إن المدرج في الملحق هو JavaDoc لHoneyRJ، والذي يقدم وصفا لكل طريقة ومتغير مستخدم في التطبيق. إذا كنت ترغب في إجراء تغييرات كبيرة في HoneyRJ، فإننا نوصيك بقراءة JavaDoc قبل البدء. يتكون تطبيق HoneyRJ من فئتين رئيسيتين وهما HoneyRJ وLIModule، واثنين من الطبقات المساعدة وهما، LIModuleThreadand LIProtocol.
يعد HoneyRJ الفئة الرئيسية للتطبيق وتسيطر على فئات LIModule المتعددة، والتي توفر دعم الاتصال لتنفيذ البروتوكولات. تحتوي كل LIModule تحتوي فئة تنفذ واجهة LIProtocol لتوفير منطق للتواصل مع العملاء المتصلين. وقذ تم إطلاق LIModuleThread من قبل LIModule على اتصال العميل للتواصل معه.
4.3.1 إطلاق وتهيئة HoneyRJ :
هذا القسم يفصل عملية التهيئة من فئة التطبيق الرئيسي ، “HoneyRJ” تحتوي فئة HoneyRJ على واحد أو أكثر من الوحدات وتقدم الخدمات المتعلقة بإدارة هذه الوحدات. ويظهر الشكل 6 لمحة عامة عن إلاطلاق و التهيئة. عند إطلاق تطبيق ، فإنه يتم استدعاء فئة منشئ HoneyRJ يقوم المنشئ بإنشاء بنية HashMap لتخزين LIModules الواردة. يعين HashMap رقم منفذ إلى LIModule ، مما يسمح للتطبيق بالتأكد انه تم تحميل وحدة لكل منفذ. بمجرد تهيئة HashMap .
تم انشاء دليل التسجيل وتم حفظ مرجع إلى هذا الدليل كعضو متغير للتمرير في وقت لاحق لإضافة LIModules . عند هذه النقطة، HoneyRJ مستعد لإضافة وحدات . تم تهيئة مثيل من LIModule (انظر للقسم 4.3.2 لمزيد من التفاصيل على تهيئة وحدة نمطية)، وتم تمريرها إلى أسلوب registerservice () من فئة HoneyRJ والتي تضيفها إلى HashMap ، لضمان عدم تعريف وحدات أخرى على المنفذ الخاص بها.
بمجرد إضافتها إلى HashMap ، يتم استدعاء اسلوب الوحدة النمطية registerparent () ، ويعطيها حق الوصول إلى دليل التسجيل المقدم من HoneyRJ . يتم إضافة وحدات إضافية بعد بتكرار هذه العملية. عند هذه النقطة، HoneyRJ ينتظر المستخدم لبدء إضافة وحدات. بمجرد ان يبدأ المستخدم بإضافة الوحدات، سيستمع التطبيق للاتصالات.
![fig6]()
4.3.2 تهيئة LIModule :
يعطي هذا القسم تفاصيل عملية تهيئة وLIModule والخطوات التي تحدث عند بدء LIModule.
يقوم LIModule بمعالجة الاتصالات ويسجل المتعلقة ببروتوكول واحد. يظهر الشكل 7 لمحة عامة عن العملية في . لإنشاء LIModule، يتم استدعاء منشئ LIModule مع فئة تهيئه تنفيذ واجهة LIProtocol (انظر الى القسم 4.3.3 لمزيد من التفاصيل عن واجهة LIProtocol). يتم تخزين فئة LIProtocol المعطاة في المنشئ كعضو متغير . في هذه المرحلة، LIModule ينتظر فئة HoneyRJ لتسجيل نفسه بالوحدة بواسطة استدعاء الأسلوب registerParent (). سجلت مرة واحدة، وبمجرد التسجيل يقوم LIModule بتخزين إشارة إلى الأصل من أجل الوصول لاحقا لمعلومات دليل التسجيل الأصلي. الوحدة الآن على استعداد ليتم بدأها من قبل المستخدم.
بمجرد البدء، تطلق الوحدة نفسها إلى التشعب وتنشئ ServerSocket. “JavaDocumentation2004” يستمع على المنفذ المحدد من قبل LIProtocol المعطى.
عندما يتصل العميل بالمنفذ، تقوم وLIModule بإطلاق LIModuleThread مع مقبس المتصل. يتصل LIModuleThread مع القراصنة وفقا لLIProtocol، في حين تواصل LIModule الاستماع إلى الاتصالات الجديدة.
![fig7]()
Figure 7
4.3.3 نطرة عامة على واجهة LIProtocol :
يحدد LIProtocol خمسة أساليب يجب أن تنفذ من قبل فئة من البروتوكول. من هذه الطرق الخمسة، طريقة processInput () التي تقوم بمعظم العمل، في حين توفر الأساليب الأربعة الأخرى المعلومات حول البروتوكول. عندما يتم تشغيل LIModuleThread للتعامل مع اتصال العميل ، فإنه يقوم بإنشاء مثيل من الفئة التي تنفذ واجهة LIProtocol . عملية استقبال وإرسال الرسائل مبينة في الشكل 8، باستخدام بروتوكول FTP كمثال على ذلك. كل حزمة ترد من العميل في المقبس يتم تحويلها إلى سلسلة مكونات وتمرر كمتغير إلى اسلوب processInput () . ومن المتوقع بعد ذلك ان تعالج processInput () السلسلة وترد جوابها إلى العميل كناقل لمكونات السلسلة . يتم إرسال كل سلسلة في الناقل المرجع إلى العميل كسطر منفصل. إذا قام بروتوكول الخاص بك بارجاع سلسلة واحدة فقط ، يتم توفير طريقة مساعدة ، LIHelper.vectorFromString ()، لإنشاء مكون موجه من سلسلة واحدة.
وتعرف الأساليب الأخرى من واجهة LIProtocol النحو التالي:
- whoTalksFirst () – قيمة العائد من هذا الأسلوب يتيح للLIModuleThread معرفة ما إذا كان العميل أو الخادم يرسل الرسالة الأولى فور تأسيس اتصال. في مصطلحات HoneyRJ، وهذا يشار إليه بإسم الذين ” يتحدثون أولا .” يتم تعريفه من قبل تعداد TALK_FIRST ولها قيمتين: SVR_FIRST (إذا قام الخادم بإرسال الرسالة الأولى) وCLIENT_FIRST (إذا قام العميل بإرسال الرسالة الأولى).
البروتوكول المعرف بأن الخادم لديه يقوم بالعملية أولاً سيكون طلب أول رسالة له باستدعاء processinput () مع مكون فارغ كالمؤشر . على التنفيذ تميز هذا وإعادة الرسالة الأولى.
- getport () – القيمة الصحيحة العائدة من من هذا الأسلوب تتيح لLimodule معرفة على ماذا يستمع منفذ البروتوكول.
- toString () – يتم استخدام قيمة عائد السلسلة في هذه الطريقة لتسمية ملفات السجل وتحديد البروتوكول في واجهة المستخدم الرسوميةGUI. يجب ان ترجع سلسلة تحدد اسم البروتوكول، على سبيل المثال، “FTP “.
- • isconnectionover () – قيمة العائد المنطقية من هذا الأسلوب تشير إلى LIModuleThread إذا اعتقد البروتوكول ان الاتصال قد انتهى، وهذا يعني، انه لا يجب إرسال او تلقي المزيد من الرسائل . يتم التحقق من قيمة الإرجاع من هذا الأسلوب بعد إرسال سلسلة المكونات التي تم إرجاعها بواسطة processinput () إلى العميل. يجب ان يعيد الأسلوب منطقية صحيحة إذا انتهى الاتصال أو كانت المنطقية غير صحيحة إذا كان البروتوكول لا يزال يتوقع إرسال أو إستقبال الرسائل.
للمواصفات الكاملة من الأساليب (بما في ذلك أنواع عوائد جافا وأنواع المؤشرات )، يرجى الاطلاع على JavaDoc المدرجة في الملحق.
![fig8]()
في هذا القسم، استعرضنا الطبقات التي تشكل تطبيق HoneyRJ
. HoneyRJ هي الطبقة الرئيسية التي تحتوي على فئات LIModule، لكل واحدة منها مضيف بروتوكول واحد. وتعرف البروتوكولات من خلال تنفيذ واجهة LIProtocol. عندما يتصل عميل، يتم إنشاء LIModuleThread لاجراء محادثات مع هذا العميل
4.4 تنفيذ بروتوكولات إضافية:
HoneyRJ يسمح للمستخدم بكتابة بروتوكولات اضافية و “إلحاق ” تلك البروتوكولات إلى HoneyRJ. يوضح هذا القسم الخطوات المطلوبة لتنفيذ البروتوكول. خلال هذا القسم ، تقدم كل الأمثلة في سياق بروتوكول FTP الذي قمنا بتطويره. عملية إنشاء بروتوكول جديد تبدأ مع العديد من قرارات التصميم الرئيسية. وبعدها يمكنك إنشاء فئة تنفذ الطرق 5 في واجهة LIProtocol. ثم ستضيف إشارة إلى الفئة التي تم إنشاؤها في اسلوب التطبيق الرئيسي من خلال تعديل بسيط على ملف HoneyRJMain.java.
عملية كتابة بروتوكول تتطلب معرفة ببرمجة جافا: على ألاقل ، فهم هياكل بيانات جافا المألوفة وبرمجة المكونات الموجهة . في هذا القسم، نفترض أن المستخدم يستخدم بيئة التطوير المتكاملة Eclipse . وبالإضافة إلى ذلك، نفترض لديك معرفة وثيقة بالبروتوكول الذي سوف تنفذه.
4.4.1 قرارات تصميم بروتوكول رئيسي
قبل البدء في البرمجة، ستحتاج إلى إجراء العديد من القرارات الأساسية حول البروتوكول الخاص بك:
- ما هو اسم البروتوكول الخاص بك؟ اتخذ قرار بشأن اسم مختصر (يفضل أن يكون أقل من 5 أحرف) عن البروتوكول الذي سيتم استخدامه للعرض في واجهة المستخدم الرسومية ولتسمية ملف السجل على سبيل المثال ، “FTP ” هو الاسم لبروتوكول FTP.
- • بمجرد أن يتم تأسيس الاتصال، هل يبدأ الخادم أو العميل الحديث أولا؟ Ftp هو مثال على البروتوكولات التي يتحدث فيها المنفذ أولا: بمجرد تأسيس الاتصال، ينتظر العميل للخادم لارسال رسالة “220 Service Ready” IRC هو مثال على البروتوكولات التي يتحدث فيها العميل أولا: بمجرد تأسيس الاتصال، ينتظر الخادم العميل لإرسال رسالة ” NICK username “
- على اي منفذ يدار البروتوكول الخاص بك؟ معظم البروتوكولات المشتركة لديها منافذ معرفة في وثيقة التعريف الخاصة بهم RFC. إذا كنت تنفذ بروتوكولا مخصصا، وهذا قرار يجب ان تتأكد منه بنفسك، ومع ذلك، فإننا نوصيك بعدم إعادة استخدام المنافذ المعروفة للبروتوكول المخصص. قائمة المنافذ المعروفة متوفرة من IANA في http://www.iana.org/assignments/port-numbers. يعملFTP على منفذ 21.
4.4.2 التنفيذ:
تسلح بإجابات لقرارات التصميم، يمكنك أن تبدأ ببرمجة البروتوكول الخاص بك. أولا، قم باستيراد مشروع Eclipse المعطى كجزء من شفرة المصدر إلى Eclipse باتباع التعليمات في وثائق Eclipse [Eclipse08]. الخطوة التالية هي إنشاء فئة عامة لتطبق واجهة LIModule. نوصيك بتسمية الفئة ك [اسم] البروتوكول، لتحل محل [Name ] مع الاسم الذي قررته في جزء القرارات الرئيسية، وتخزين الفئة في حزمة برتوكول /thesrc بداخل مشروع Eclipse .
- puplic class ftpprotocol implements LIProtocol
الفئة التي تنفذ بروتوكول FTP تسمى “FtpProtocol .”
وبمجرد إنشاء الفئة، إسمح لEclipse بتوليد اساليب skeleton التي تطبق الواجهة. سوف تحتاج إلى إنشاء اساليب tostring () باستخدام ” Override /Implement methods ” وشغلها في Eclipse . تعد اساليب tostring ()، getport () و whotalksfirst () بسيطة التنفيذ وتمثل الجواب على اسئلة القرار الرئيسية .
- public TALK_FIRST whoTalksFirst(){return TALK_FIRST.SVR_FIRST; }
يتطلب بروتوكول FTP الخادم لإرسال الرسالة الأولى.
- public String toString(){return “FTP”; } return
قررنا تسمية بروتوكول نقل الملفات ببروتوكول FTP .
- public int getPort(){return 21; } return
يستمع بروتوكول FTP على المنفذ 21.
الطريقتين المتبقيتين isconnectionover () و processinput ()، هما أكثر تحديا، حيث يتطلب التنفيذ المناسب تذكر حالة العميل المتصل . عند تنفيذ بروتوكول FTP يستخدم عضو متغير connectionstate لتخزين حالة الاتصال وتنفيذ بيان التبديل () على هذا المتغير في طريقة processinput () لتحديد ما إذا تم إستلام الإدخال المناسب وارسال الاستجابة .
يتم تنفيذ isconnectionover () بفحص إذا كان متغير connectionstate يساوي الثابت الذي يمثل الحالة المغلقة.
طريقة processinput () ترجع ناقل سلسلة المكونات ردا على السلسلة. إذا كنت تحتاج إلى سلسلة واحدة فقط ردا على رسالة، يتم توفير طريقة مساعدك ثابتة مساعد طريقة lihelper.vectorfromstring () لتوفير وقت تلخيص كل استجابات السلسلة كناقل. الطريقة الثابتة تعيد الناقل مع السلسلة المعطاة كالعضو الوحيد.
- public Vector<String> processInput(String msg) { /* seesource code for implementation */}
- public boolean isConnectionOver(){return connectionState == KILLED; }
4.4.3 إضافة البروتوكول:
والآن بعد أن أنشأت فئة البروتوكول الخاص بك، يجب عليك ان تجعل تطبيق HoneyRJ يعلم به . هذه العملية بسيطة وتتطلب إضافة عدة أسطر من التعليمات البرمجية لطريقة التطبيق الرئيسي (). افتح ملف SRC / honeyrj / HoneyRJMain.java. داخل الأسلوب الرئيسي ()، أضف الأسطر التالية بعد خط 17، createSampleProtocols ():
- LIProtocol yourProtocol = new [ NAMEOFCLASS] ( );
استبدال [NAMEOFCLASS] باسم الفئة، على سبيل المثال، بروتوكول FTP.
لبروتوكول FTP، ينتهي الخط ببروتوكول جديد FTProtocol();
- LIModule yourModule = newLIModule (yourProtocol);
لا يتطلب هذا السطر أي تعديل. أنه ينشئ LIModule التي ستغطي فئة البروتوكول الخاص بك، وتوفر مقابس الاتصالات .
- gui.AddModule(yourModule);
هذا السطر لا يتطلب أي تعديل. ويضيف البروتوكول الخاص بك إلى HoneyRJ و HoneyRJ GUI .
في هذه المرحلة ، لقد نجحت في إضافة بروتوكول جديد لHoneyRJ. يمكنك تشغيل ملف HoneyRJMain.java كتطبيق جافا وعرض النتائج
وباختصار، فإن عملية إنشاء بروتوكول إضافي في HoneyRJ تتكون من اتخاذ العديد من قرارات تصميم وتنفيذ واجهة LIProtocol وفقا لإجابات قرارات التصميم . بمجرد إنشاء الفئة، يتم اتباع عدة خطوات بسيطة لإضافة البروتوكول الجديد للتطبيق.
5.الملخص:
تقليديا، تم استخدام IDS من قبل مسؤولي الشبكة لمراقبة حركة المرور على الشبكة بفاعلية لكشف اي نشاط غير مصرح به. ومع ذلك، في عالم اليوم تستخدم الاتصالات المشفرة على نحو متزايد، والذي لم تقدر انظمة كشف التسلل على رصده أصبحت مصائد مخترقي الشبكات Honeypots بديلا جذابا بشكل متزايد لتحديد مصادر حركة المرور الخبيثة.
تم اختراع ال honeypots، في عام 1998، ‘وظيفتها هي تسجيل جميع الاتصالات ومحاولات الاتصال. يجب وضع نظام Honeypots على عنوان IP غير مستخدم، بحيث لا يتم توجيه اي محاولات اتصال مشروعة إلى المصيدة. يتوفر نوعان رئيسيين من honeypots المتاحة اليوم: high-interaction و low-interaction . مصائد low-interaction بسيطة وتوفر تطبيقات جزئية من البروتوكولات الشائعة، بهدف تسجيل فقط مصدر حركة المرور الخبيثة . ومصائد high-interaction أكثر تعقيدا وغالبا ما تكون خوادم عادية ببرمجيات رصد متقدمة وتهدف الى مساعدة الباحثون في فهم عمليات التفكير الداخلية للقراصنة.
لا تزال honeypots حقلا متطورا من علم الحاسوب الآلي، مع التطورات الأخيرة أنشئت شبكات honeypots في جميع أنحاء العالم ، عادة يشار إليها ب honeynets و distributed honeypots.
قمنا بتقديم حالة دراسية لتنفيذ مصيدة low-interaction في جافا “Java ” ، تسمى HoneyRJ. توفر HoneyRJ التسجيل الأساسي، والتمدد المتوقع في مصيدة low-interaction حديثة
ترجمة لمقال : A Practical Guide to Honeypots
اقرأ ايضا مقال : شرح انشاء SSH Honeypot بأستخدام اداة Kippo والذي يشرح طريقه استخدام مصيده لبروتوكول SSH
