حالات استخدام أدوات تحليل الشذوذ في الشبكة: كشف التسرب

في أحد الأحداث ، تبع ذلك مناقشة مثيرة للاهتمام حول فائدة حلول NTA (تحليل حركة مرور الشبكة) ، والتي ، باستخدام البنية التحتية لشبكة القياس عن بعد Netflow (أو بروتوكولات التدفق الأخرى) ، تجعل من الممكن اكتشاف مجموعة واسعة من الهجمات. جادل معارضوي أنه عند تحليل الرؤوس والمعلومات ذات الصلة (ولا تحلل NTA نص حزمة البيانات ، على عكس أنظمة الكشف عن الهجمات الكلاسيكية ، IDS) ، لا يمكنك رؤية الكثير. في هذه المقالة سأحاول دحض هذا الرأي وجعل المحادثة أكثر جوهرية ، سأعطي بعض الأمثلة الحقيقية عندما تساعد NTA بالفعل في تحديد مختلف الشذوذ والتهديدات المفقودة في المحيط أو حتى بعد المحيط. وسأبدأ بالتهديد الذي جاء أولاً في تصنيف التهديدات في العام الماضي ، وأعتقد أنه سيبقى كذلك هذا العام.سوف يتعلق الأمر بتسريبات المعلومات والقدرة على اكتشافها عبر القياس عن بعد للشبكة.

لن أفكر في الوضع بأيدي أعوج من المسؤولين الذين تركوا الإنترنت يبحثون عن مرونة غير محمية أو MongoDB. دعونا نتحدث عن الإجراءات المستهدفة من المهاجمين ، كما كان الحال مع القصة المشهورة لمكاتب ائتمان Equifax. دعني أذكرك أنه في هذه الحالة ، اخترق المهاجمون أولاً الثغرة الأمنية التي لم يتم إصلاحها لبوابة الويب العامة ، ثم لخوادم قاعدة البيانات الداخلية. وبقيت دون أن يلاحظها أحد منذ عدة أشهر ، وتمكنوا من سرقة البيانات على 146 مليون عميل لمكتب الائتمان. هل يمكن تحديد مثل هذا الحادث باستخدام حلول منع فقدان البيانات؟ على الأرجح لا ، لأن أجهزة DLP الكلاسيكية ليست مصممة خصيصًا لمهمة مراقبة حركة المرور من قواعد البيانات باستخدام بروتوكولات محددة ، وحتى في حالة تشفير حركة المرور هذه.لكن حل فئة NTA يمكن بسهولة اكتشاف مثل هذه التسريبات من خلال تجاوز قيمة عتبة معينة لكمية المعلومات التي تم تنزيلها من قاعدة البيانات. بعد ذلك ، سأوضح كيف تم تكوين كل هذا واكتشافه باستخدام حل Cisco Stealthwatch Enterprise.

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



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



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



في مجموعة خوادم DHCP ، اتضح أن هذه عقدة مع العنوان 10.201.0.15 ، التفاعل الذي يمثل حوالي 50 ٪ من جميع حركة المرور من خوادم قاعدة البيانات.



السؤال المنطقي التالي الذي نطرحه على أنفسنا كجزء من التحقيق هو: "وما هذه العقدة مثل 10.201.0.15؟ مع من يتفاعل؟ كم مرة؟ ما البروتوكولات؟ "



اتضح أن العقدة التي تهمنا تتواصل مع قطاعات وعقد مختلفة من شبكتنا (وهذا ليس مفاجئًا ، لأنه خادم DHCP) ، لكن السؤال يتسبب في الكثير من التفاعل مع خادم المحطة الطرفية بالعنوان 10.201.0.23. هل هذا طبيعي؟ من الواضح أن هناك نوعًا من الشذوذ. لا يمكن لخادم DHCP التواصل بنشاط مع خادم طرفي - 5610 دفق و 23.5 جيجابايت من البيانات.



ويتم هذا التفاعل من خلال NFS.



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



كان الشك بسبب حقيقة تفاعل P2P مع بورتوريكو ، والتي شكلت 90 ٪ من جميع حركة المرور. علاوة على ذلك ، أرسل خادم طرفي لدينا أكثر من 17 غيغابايت من البيانات إلى بورتوريكو عبر المنفذ 53 ، المرتبط ببروتوكول DNS. هل يمكنك أن تتخيل أن لديك مثل هذا الحجم من البيانات المرسلة عبر DNS؟ وأذكرك أنه وفقًا لأبحاث Cisco ، تستخدم 92٪ من البرامج الضارة DNS لإخفاء نشاطها (تنزيل التحديثات ، وتلقي الأوامر ، وتفريغ البيانات).



وإذا لم يكن بروتوكول DNS DNS مفتوحًا فقط ، ولكن لم يتم فحصه ، فعندئذ لدينا فجوة كبيرة في محيطنا.



بمجرد أن تسببت العقدة 10.201.0.23 في مثل هذه الشكوك ، دعنا نرى من لا يزال يتحدث إليه؟



يتبادل "المشتبه فيه" نصف حركة المرور مع العقدة 10.201.3.18 ، التي يتم وضعها في مجموعة من محطات العمل لموظفي قسم المبيعات والتسويق. إلى أي مدى تعتبر هذه هي الطريقة التي تستخدمها مؤسستنا للخادم الطرفي "للتواصل" مع كمبيوتر البائع أو المسوق؟



لذا ، أجرينا تحقيقاً واكتشفنا الصورة التالية. تم "سكب" البيانات من خادم قاعدة البيانات على خادم DHCP مع نقلها لاحقًا عبر NFS إلى خادم طرفي داخل شبكتنا ، ثم إلى عناوين خارجية في بورتوريكو باستخدام بروتوكول DNS. هذا انتهاك واضح للسياسات الأمنية. في الوقت نفسه ، تفاعل خادم المحطة الطرفية أيضًا مع إحدى محطات العمل داخل الشبكة. ما سبب هذا الحادث؟ حساب مسروق؟ الجهاز المصاب؟ نحن لا نعلم. سيتطلب هذا استمرارًا للتحقيق ، والذي كان قائمًا على حل فئة NTA ، والذي يسمح بتحليل الحالات الشاذة لحركة مرور الشبكة.



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



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



إذا تم الكشف عن مثل هذا الحدث ، يقوم نظام تحليل حركة مرور الشبكة على الفور بإنشاء إشارة إنذار بالمراسلة ، ويرسلها إلى الإعدادات إلى SIEM ، حسب وسائل الاتصال ، أو يمكنه حتى منع المخالفة المكتشفة تلقائيًا (تقوم Cisco Stealthwatch بذلك عن طريق التفاعل مع Cisco ISE )



تذكر أنه عندما ذكرت الحالة مع Equifax ، ذكرت أن المهاجمين استخدموا قناة مشفرة لتفريغ البيانات. بالنسبة إلى ميزة منع فقدان البيانات (DLP) ، تصبح حركة المرور هذه مهمة غير قابلة للحل ، ولكن بالنسبة لحلول فئة NTA ، فإنها لا تقوم بذلك - فهي تتتبع أي حركة مرور زائدة أو تفاعل غير مصرح به بين العقد ، بغض النظر عن التشفير.



تم عرض حالة واحدة فقط أعلاه (في المواد التالية سننظر في أمثلة أخرى لاستخدام NTA لأغراض تتعلق بأمن المعلومات) ، ولكن في الواقع ، تسمح لك الحلول الحديثة لفئة تحليل حركة مرور الشبكة بإنشاء قواعد مرنة للغاية مع مراعاة ليس فقط المعلمات الأساسية لرأس حزمة IP:



ولكن أيضًا إجراء تحليل أعمق ، حتى ربط الحادث باسم المستخدم من Active Directory ، والبحث عن الملفات الضارة عن طريق التجزئة (على سبيل المثال ، التي تم الحصول عليها كمؤشر تسوية من SOSOPKA ، FinCERT ، Cisco Threat Grid ، إلخ) ، إلخ.



من السهل تنفيذها. على سبيل المثال ، هذه هي الطريقة التي تبدو بها القاعدة المعتادة للكشف عن جميع أنواع التفاعل بين خوادم قواعد البيانات والعقد الخارجية باستخدام أي بروتوكول خلال الثلاثين يومًا الماضية. نرى أن قواعد البيانات الخاصة بنا "تم توصيلها" بالعقد الخارجية لقطاع DBMS باستخدام بروتوكولات DNS و SMB والمنفذ 8088.



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



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



فيما يلي مثال مثير للاهتمام وحيوي لاستخدام أدوات مراقبة Netflow (وبروتوكولات التدفق الأخرى) للأمن السيبراني. في الملاحظات التالية ، أخطط لإظهار كيف يمكنك استخدام NTA لاكتشاف التعليمات البرمجية الضارة (على سبيل المثال ، Shamoon) ، والخوادم الضارة (على سبيل المثال ، حملة DNSpionage) ، وبرامج الوصول عن بعد (RAT) ، وتجاوز وكلاء الشركة ، وما إلى ذلك.

Source: https://habr.com/ru/post/undefined/