عندما يتعلق الأمر بمراقبة أمان شبكة داخلية للشركة أو الإدارات ، يربطها الكثيرون بالتحكم في تسرب المعلومات وتنفيذ حلول DLP. وإذا حاولت تحسين السؤال وسألت عن كيفية اكتشافك للهجمات على الشبكة الداخلية ، فعادةً ما تكون الإجابة هي ذكر أنظمة كشف التطفل (IDS). وما كان الخيار الوحيد قبل 10-20 سنة أصبح مفارقة تاريخية اليوم. هناك خيار أكثر فعالية ، وفي بعض الأماكن هو الخيار الوحيد الممكن لمراقبة الشبكة الداخلية - لاستخدام بروتوكولات التدفق ، المصممة أصلاً للبحث عن مشاكل الشبكة (استكشاف الأخطاء وإصلاحها) ، ولكن مع مرور الوقت تحولت إلى أداة أمان مثيرة للاهتمام للغاية. سنتحدث هنا عن ماهية بروتوكولات التدفق وأي منها تساعد في اكتشاف هجمات الشبكة بشكل أفضل ، والمكان الأفضل لتنفيذ مراقبة التدفق ، وما الذي تبحث عنه عند نشر مثل هذا المخطط ، وحتى كيفية "رفعه" جميعًا على المعدات المحلية ، سنتحدث في نطاق هذه المقالة.
لن أتطرق إلى السؤال "لماذا نحتاج إلى مراقبة أمن البنية التحتية الداخلية؟" الجواب على ذلك واضح نوعا ما. ولكن إذا أردت ، مع ذلك ، أن تتأكد مرة أخرى أنه لا يمكنك الاستغناء عنها اليوم ، مقطع فيديو قصير يحتوي على قصة حول كيفية الدخول إلى شبكة شركة محمية بجدار حماية من خلال 17 طريقة. لذلك ، سنفترض أننا نفهم أن المراقبة الداخلية هي أمر ضروري ويبقى فقط لفهم كيفية تنظيمها.
أود تحديد ثلاثة مصادر بيانات رئيسية لمراقبة البنية التحتية على مستوى الشبكة:
- حركة المرور "الأولية" التي نلتقطها ونقدمها للتحليل إلى بعض أنظمة التحليل ،
- الأحداث من أجهزة الشبكة التي تمر من خلالها حركة المرور ،
- المعلومات المرورية الواردة عبر أحد بروتوكولات التدفق.
يعتبر الاستيلاء على حركة المرور الخام هو الخيار الأكثر شيوعًا بين رجال الأمن ، لأنه ظهر تاريخيًا وكان الأول على الإطلاق. أنظمة الكشف عن اختراق الشبكة التقليدية (كان نظام NetRanger التجاري الأول من شركة Wheel Group ، والذي اشترته شركة Cisco في عام 1998) منخرطًا للتو في التقاط حزم (وجلسات لاحقة) تم فيها البحث عن توقيعات معينة ("قواعد حاسمة" في مصطلحات FSTEC) ، إشارات الهجمات. بالطبع ، يمكنك تحليل حركة المرور الأولية ليس فقط باستخدام IDS ، ولكن أيضًا باستخدام أدوات أخرى (على سبيل المثال ، Wireshark أو tcpdum أو وظيفة NBAR2 في Cisco IOS) ، لكنها عادةً ما تفتقر إلى قاعدة المعرفة التي تميز أداة أمان المعلومات عن أداة تكنولوجيا المعلومات العادية.
لذا ، أنظمة كشف التسلل. الطريقة الأقدم والأكثر شيوعًا لاكتشاف هجمات الشبكة ، والتي تقوم بعمل جيد في المحيط (بغض النظر عن الأمر - الشركة ، مركز البيانات ، القطاع ، إلخ) ، لكنها تفشل في الشبكات الحديثة المحولة والمحددة بالبرمجيات. في حالة وجود شبكة مبنية على أساس مفاتيح تقليدية ، تصبح البنية التحتية لمستشعرات كشف التسلل كبيرة جدًا - سيتعين عليك وضع مستشعر على كل اتصال بالمضيف الذي تريد مراقبة الهجمات عليه. سيسعد أي مصنع ، بالطبع ، أن يبيع لك مئات وآلاف أجهزة الاستشعار ، لكنني أعتقد أن ميزانيتك لا يمكنها تحمل مثل هذه النفقات. أستطيع أن أقول أنه حتى في Cisco (ونحن مطورو NGIPS) لم نتمكن من القيام بذلك ، على الرغم من أن مسألة السعر مطروحة على ما يبدو. لا ينبغي أن يقف - هذا هو قرارنا. بالإضافة إلى ذلك ، السؤال الذي يطرح نفسه ، كيفية توصيل المستشعر في هذا الإصدار؟ في فجوة؟ ماذا لو فشل المستشعر نفسه؟ تتطلب وحدة تجاوز في المستشعر؟ استخدام المقسمات (الحنفية)؟ كل هذا يزيد من تكلفة الحل ويجعله باهظ الثمن لشركة من أي حجم.
يمكنك محاولة "تعليق" المستشعر على منفذ SPAN / RSPAN / ERSPAN وتوجيه حركة المرور إليه من منافذ التبديل الضرورية. يزيل هذا الخيار جزئيًا المشكلة الموصوفة في الفقرة السابقة ، لكنه يطرح مشكلة أخرى - لا يمكن لمنفذ SPAN استقبال كل حركة المرور التي سيتم إرسالها إليه تمامًا - لن يكون لديه نطاق ترددي كافٍ. على استعداد للتضحية بشيء. إما أن تترك بعض العقد دون مراقبة (ثم تحتاج أولاً إلى ترتيبها حسب الأولوية) ، أو لا ترسل كل حركة المرور من العقدة ، ولكن نوعًا معينًا فقط. على أي حال ، يمكننا تفويت بعض الهجمات. بالإضافة إلى ذلك ، يمكن شغل منفذ SPAN لاحتياجات أخرى. نتيجة لذلك ، سيتعين علينا مراجعة هيكل الشبكة الحالي وربما إجراء تعديلات عليه من أجل تغطية شبكتك إلى الحد الأقصى مع عدد أجهزة الاستشعار لديك (وتنسيق ذلك مع تكنولوجيا المعلومات).
ماذا لو كانت شبكتك تستخدم طرقًا غير متماثلة؟ وإذا كنت قد نفذت أو تخطط لتطبيق SDN؟ ولكن ماذا لو كنت بحاجة إلى مراقبة الأجهزة أو الحاويات الافتراضية التي لا تصل حركة المرور الخاصة بها إلى المفتاح المادي على الإطلاق؟ هذه هي الأسئلة التي لا يحبها بائعي IDS التقليديين لأنهم لا يعرفون كيفية الإجابة عليها. ربما سيقنعونك بأن كل هذه التقنيات العصرية هي دعاية وأنك لست بحاجة إليها. ربما سيتحدثون عن الحاجة للبدء على نطاق صغير. أو ربما سيقولون إنك بحاجة إلى وضع دراس قوي في وسط الشبكة وتوجيه كل حركة المرور إليها باستخدام موازين التحميل. مهما كان الخيار المعروض عليك ، فأنت بحاجة إلى أن تفهم بوضوح كيف يناسبك. وفقط بعد ذلك اتخاذ قرار بشأن اختيار نهج لرصد أمن المعلومات للبنية التحتية للشبكة. بالعودة إلى التقاط الحزم ، أود أن أقول إن هذه الطريقة لا تزال تحظى بشعبية كبيرة وهامة ، لكن الغرض الرئيسي منها هو مراقبة الحدود ؛ الحدود بين مؤسستك والإنترنت ، والحدود بين مركز البيانات وبقية الشبكة ، والحدود بين نظام التحكم في العملية وقطاع الشركة. في هذه الأماكن ، لا يزال لدى IDS / IPS الكلاسيكي الحق في الوجود والقيام بعمل جيد مع مهامهم.
دعنا ننتقل إلى الخيار الثاني. يمكن أيضًا استخدام تحليل الأحداث القادمة من أجهزة الشبكة لأغراض الكشف عن التطفل ، ولكن ليس كآلية رئيسية ، نظرًا لأنه لا يكتشف سوى فئة صغيرة من عمليات التطفل. بالإضافة إلى ذلك ، فإن بعض التفاعلات متأصلة فيه - يجب أن يحدث الهجوم أولاً ، ثم يجب إصلاحه بواسطة جهاز الشبكة ، والذي سيشير بطريقة أو بأخرى إلى وجود مشكلة في أمن المعلومات. هناك عدة طرق من هذا القبيل. يمكن أن يكون سجل النظام أو RMON أو SNMP. يتم استخدام البروتوكولين الأخيرين لمراقبة الشبكة في سياق أمان المعلومات فقط إذا احتجنا إلى اكتشاف هجوم DoS على معدات الشبكة نفسها ، نظرًا لاستخدام RMON و SNMP ، يمكنك ، على سبيل المثال ، مراقبة الحمل على المعالج المركزي للجهاز أو واجهاته. يعد هذا أحد "أرخص" (كل شخص لديه سجل نظام أو SNMP) ، ولكنه أيضًا أكثر الطرق فاعلية من جميع الطرق لمراقبة أمان المعلومات للبنية التحتية الداخلية - يتم إخفاء العديد من الهجمات عنه ببساطة. بالطبع ، لا ينبغي إهمالها ، ويساعدك تحليل سجل النظام نفسه على تحديد التغييرات في تكوين الجهاز نفسه في الوقت المناسب ، مما يعرضه للخطر ، ولكنه ليس مناسبًا جدًا لاكتشاف الهجمات على الشبكة بأكملها.
الخيار الثالث هو تحليل المعلومات المتعلقة بحركة المرور التي تمر عبر جهاز يدعم أحد بروتوكولات التدفق العديدة. في هذه الحالة ، بغض النظر عن البروتوكول ، تتكون البنية التحتية للدفق بالضرورة من ثلاثة مكونات:
- تدفق التوليد أو التصدير. عادةً ما يتم تعيين هذا الدور إلى جهاز توجيه أو جهاز تبديل أو أي جهاز شبكة آخر ، والذي يسمح لك ، عند تمرير حركة مرور الشبكة عبر نفسه ، باستخراج المعلمات الرئيسية منه ، والتي يتم نقلها بعد ذلك إلى وحدة التجميع. على سبيل المثال ، بروتوكول Netflow الخاص بشركة Cisco مدعوم ليس فقط على أجهزة التوجيه والمحولات ، بما في ذلك الافتراضية والصناعية ، ولكن أيضًا على وحدات التحكم اللاسلكية وجدران الحماية وحتى الخوادم.
- تدفق المجموعة. نظرًا لوجود أكثر من جهاز شبكة واحد في شبكة حديثة ، تظهر مشكلة تجميع التدفقات ودمجها ، والتي يتم حلها بمساعدة ما يسمى المجمعين الذين يعالجون التدفقات المستلمة ثم يرسلونها للتحليل.
- تحليل التدفق. يأخذ المحلل المهمة الفكرية الرئيسية ويطبق خوارزميات مختلفة على التدفقات ويستخلص بعض الاستنتاجات. على سبيل المثال ، في إحدى وظائف تكنولوجيا المعلومات ، يمكن لمحلل كهذا تحديد اختناقات الشبكة أو تحليل ملف تعريف حمل حركة المرور لتحسين الشبكة بشكل أكبر. ولأمن المعلومات ، يمكن لمحلل كهذا اكتشاف تسرب البيانات أو انتشار التعليمات البرمجية الضارة أو هجمات DoS.
لا تعتقد أن مثل هذه البنية ثلاثية المستويات معقدة للغاية - فجميع الخيارات الأخرى (مع استثناء محتمل لأنظمة مراقبة الشبكة التي تعمل مع SNMP و RMON) تعمل أيضًا وفقًا لها. لدينا مولد بيانات للتحليل ، وهو عبارة عن جهاز شبكة أو جهاز استشعار قائم بذاته. لدينا نظام لجمع الإنذارات ولدينا نظام إدارة للبنية التحتية للمراقبة بأكملها. يمكن دمج المكونين الأخيرين في عقدة واحدة ، ولكن في شبكات كبيرة إلى حد ما أو أقل ، يتم نشرهما عادةً على جهازين ، على الأقل ، من أجل ضمان قابلية التوسع والموثوقية.
على عكس تحليل الحزم ، الذي يعتمد على دراسة رأس وجسم البيانات لكل حزمة والجلسات التي تتكون منها ، يعتمد تحليل التدفق على جمع البيانات الوصفية حول حركة مرور الشبكة. متى وكم ومن أين وأين وكيف ... هذه هي الأسئلة التي يجيب عليها تحليل القياس عن بعد للشبكة باستخدام بروتوكولات التدفق المختلفة. في البداية ، تم استخدامها لتحليل الإحصائيات والبحث عن مشاكل تكنولوجيا المعلومات في الشبكة ، ولكن بعد ذلك ، مع تطوير آليات التحليل ، أصبح من الممكن تطبيقها على نفس القياس عن بُعد لأغراض أمنية. يجدر التأكيد هنا على أن تحليل التدفق لا يحل محل أو يحل محل التقاط الحزم. كل من هذه الطرق لها نطاقها الخاص. ولكن في سياق هذه المقالة ، فإن تحليل التدفق هو الأنسب لمراقبة البنية التحتية الداخلية. لديك أجهزة شبكة (سواء كانت تعمل في نموذج معرف بالبرمجيات أو وفقًا لقواعد ثابتة) لا يمكن للهجوم تجاوزها. يمكنه تجاوز مستشعر IDS الكلاسيكي ، ولكن ليس جهاز الشبكة الذي يدعم بروتوكول التدفق. هذه هي ميزة هذه الطريقة.
من ناحية أخرى ، إذا كنت بحاجة إلى قاعدة أدلة لإنفاذ القانون أو فريق التحقيق في الحادث الخاص بك ، فلا يمكنك الاستغناء عن التقاط الحزمة - لا يعد قياس الشبكة عن بُعد نسخة من حركة المرور التي يمكن استخدامها لجمع الأدلة ؛ مطلوب من أجل الكشف السريع واتخاذ القرار في مجال أمن المعلومات. من ناحية أخرى ، باستخدام تحليل القياس عن بُعد ، لا يمكنك "كتابة" كل حركة مرور الشبكة (إن وجدت ، فإن Cisco تشارك أيضًا في مراكز البيانات :-) ، ولكن فقط التي تشارك في الهجوم. ستكمل أدوات تحليل القياس عن بُعد في هذا الصدد آليات التقاط الحزم التقليدية بشكل جيد ، مما يعطي أمرًا للالتقاط والتخزين الانتقائي. خلاف ذلك ، سيكون لديك بنية تحتية تخزين هائلة.
تخيل شبكة تعمل بسرعة 250 ميجابت في الثانية. إذا كنت تريد حفظ كل هذا الحجم ، فستحتاج إلى 31 ميغابايت من التخزين لثانية واحدة من نقل حركة المرور ، و 1,8 غيغابايت لدقيقة واحدة ، و 108 غيغابايت لمدة ساعة واحدة ، و 2,6 تيرابايت في يوم واحد. لتخزين البيانات اليومية من شبكة ذات عرض نطاق ترددي يبلغ 10 جيجابت / ثانية ، ستحتاج إلى 108 تيرابايت من التخزين. لكن بعض المنظمين يطلبون منك تخزين بيانات الأمان لسنوات ... يساعدك التسجيل عند الطلب لتحليل التدفق على تقليل هذه القيم من حيث الحجم. بالمناسبة ، إذا تحدثنا عن نسبة حجم البيانات المسجلة للقياس عن بعد للشبكة والتقاط البيانات الكاملة ، فستكون تقريبًا من 1 إلى 500. بالنسبة لنفس القيم المذكورة أعلاه ، يتم تخزين فك تشفير كامل من إجمالي حركة المرور اليومية ستكون 5 و 216 غيغابايت ، على التوالي (يمكنك حتى الكتابة إلى محرك أقراص محمول عادي).
إذا كانت طريقة التقاط بيانات الشبكة الأولية لأدوات التحليل هي نفسها تقريبًا من بائع إلى بائع ، ففي حالة تحليل التدفق ، يكون الوضع مختلفًا. هناك العديد من المتغيرات لبروتوكولات التدفق ، والاختلافات التي تحتاج إلى معرفتها في سياق الأمان. الأكثر شيوعًا هو بروتوكول Netflow الذي طورته Cisco. هناك عدة إصدارات من هذا البروتوكول تختلف في قدراتها وكمية المعلومات المسجلة حول حركة المرور. الإصدار الحالي هو التاسع (Netflow v9) ، والذي تم من خلاله تطوير معيار الصناعة Netflow v10 ، المعروف أيضًا باسم IPFIX. اليوم ، يدعم معظم بائعي الشبكات Netflow أو IPFIX في أجهزتهم. ولكن هناك العديد من المتغيرات الأخرى لبروتوكولات التدفق - sFlow و jFlow و cFlow و rFlow و NetStream وما إلى ذلك ، والتي يعد sFlow الأكثر شيوعًا منها. غالبًا ما يتم دعمه من قبل الشركات المصنعة المحلية لمعدات الشبكة بسبب سهولة التنفيذ. ما هي الاختلافات الرئيسية بين Netflow ، كمعيار واقعي ، ونفس sFlow؟ أود أن أسلط الضوء على عدد قليل من العناصر الرئيسية. أولاً ، يحتوي Netflow على حقول قابلة للتكوين بواسطة المستخدم بدلاً من الحقول الثابتة في sFlow. وثانيًا ، وهذا هو أهم شيء في حالتنا ، يجمع sFlow ما يسمى بالقياس عن بُعد بأخذ العينات ؛ على عكس Netflow و IPFIX غير المستندة إلى عينات. ما الفرق بينهم؟
تخيل أنك قررت قراءة الكتاب "زملائي غاري ماكنتاير وجوزيف مونيتز ونديم الفردان (يمكنكم تنزيل جزء من الكتاب من الرابط). لديك ثلاثة خيارات لتحقيق هدفك - قراءة الكتاب بالكامل ، أو تصفح الكتاب ، أو التوقف عند كل 10 أو 20 صفحة ، أو محاولة العثور على إعادة سرد للمفاهيم الأساسية في مدونة أو خدمة مثل SmartReading. لذا ، فإن القياس عن بُعد غير المأخوذ من العينات هو قراءة كل "صفحة" من حركة مرور الشبكة ، أي تحليل البيانات الوصفية لكل حزمة. القياس عن بعد بأخذ العينات هو دراسة انتقائية لحركة المرور على أمل أن تكون العينات المختارة هي ما تحتاجه. اعتمادًا على سرعة القناة ، سترسل عينات القياس عن بُعد كل حزمة 64 أو 200 أو 500 أو 1000 أو 2000 أو حتى 10000 لتحليلها.
في سياق مراقبة أمن المعلومات ، يعني هذا أن القياس عن بعد بأخذ العينات مناسب تمامًا لاكتشاف هجمات DDoS ، والمسح الضوئي ، ونشر التعليمات البرمجية الضارة ، ولكنه قد يفقد الهجمات الذرية أو متعددة الحزم التي لم يتم تضمينها في العينة المرسلة للتحليل. القياس عن بعد غير المنضبط لا يحتوي على أوجه قصور من هذا القبيل أيضًا. استخدام نطاق الهجمات المكتشفة أوسع بكثير. فيما يلي قائمة صغيرة بالأحداث التي يمكن اكتشافها باستخدام أدوات تحليل قياس الشبكة عن بُعد.
بالطبع ، لن يسمح لك بعض محلل Netflow مفتوح المصدر بالقيام بذلك ، لأن مهمته الرئيسية هي جمع القياس عن بعد وإجراء التحليل الأساسي عليه من وجهة نظر تكنولوجيا المعلومات. لتحديد تهديدات IS بناءً على التدفق ، من الضروري تزويد المحلل بمحركات وخوارزميات مختلفة ، والتي ستحدد مشاكل الأمن السيبراني بناءً على حقول Netflow القياسية أو المخصصة ، وتثري البيانات القياسية بالبيانات الخارجية من مصادر استخبارات التهديدات المختلفة ، إلخ.
لذلك ، إذا كان لديك خيار ، فقم بإيقافه على Netflow أو IPFIX. ولكن حتى إذا كانت أجهزتك تعمل فقط مع sFlow ، مثل الشركات المصنعة المحلية ، فيمكنك الاستفادة منها في هذه الحالة في سياق الأمان.
في صيف عام 2019 ، قمت بتحليل الفرص المتاحة لشركات تصنيع حديد الشبكات الروسية ، وأعلنت جميعها ، باستثناء NSG و Polygon و Craftway ، عن دعمها لـ sFlow (على الأقل Zelaks و Natex و Eltex و QTech و Rusteletech).
السؤال التالي الذي سيطرح أمامك هو مكان تنفيذ دعم التدفق لأغراض أمنية؟ في الواقع ، لم يتم طرح السؤال بشكل صحيح تمامًا. في المعدات الحديثة ، يتم دعم بروتوكولات التدفق دائمًا تقريبًا. لذلك ، سأعيد صياغة السؤال بشكل مختلف - ما هي الطريقة الأكثر فعالية لجمع القياس عن بُعد من وجهة نظر أمنية؟ ستكون الإجابة واضحة تمامًا - على مستوى الوصول ، حيث سترى 100٪ من كل حركة المرور ، حيث سيكون لديك معلومات مفصلة عن المضيفين (MAC ، VLAN ، معرف الواجهة) ، حيث يمكنك تتبع حتى حركة مرور P2P بين المضيفين ، والتي أمر بالغ الأهمية لفحص الكشف عن الشفرات الضارة وتوزيعها. على المستوى الأساسي ، قد لا ترى ببساطة بعض حركة المرور ، ولكن على مستوى المحيط سترى جيدًا ما إذا كان ربع حركة مرور الشبكة لديك. ولكن إذا كان لديك ، لسبب ما ، أجهزة غريبة على شبكتك تتيح للمهاجمين "الدخول والخروج" متجاوزين المحيط ، فلن يمنحك تحليل القياس عن بُعد منه أي شيء. لذلك ، للحصول على أقصى تغطية ، يوصى بتمكين جمع القياس عن بُعد على مستوى الوصول. في الوقت نفسه ، تجدر الإشارة إلى أنه حتى لو كنا نتحدث عن المحاكاة الافتراضية أو الحاويات ، فإن المفاتيح الافتراضية الحديثة تدعم أيضًا التدفق في كثير من الأحيان ، مما يسمح لك بالتحكم في حركة المرور هناك أيضًا.
لكن منذ أن طرحت الموضوع ، فأنا بحاجة للإجابة على السؤال ، ماذا لو ، بعد كل شيء ، المعدات ، المادية أو الافتراضية ، لا تدعم بروتوكولات التدفق؟ أم أن إدراجه ممنوع (على سبيل المثال ، في القطاعات الصناعية لضمان الموثوقية)؟ أم أن تشغيله يتسبب في ارتفاع استخدام وحدة المعالجة المركزية (يحدث هذا على الأجهزة القديمة)؟ لحل هذه المشكلة ، توجد مستشعرات افتراضية متخصصة (مستشعر التدفق) ، وهي عبارة عن مقسمات عادية تمرر حركة المرور من خلال نفسها وتبثها في شكل تدفق إلى وحدة التجميع. صحيح ، في هذه الحالة ، نحصل على مجموعة كاملة من المشكلات التي تحدثنا عنها أعلاه فيما يتعلق بأدوات التقاط الحزم. بمعنى ، من الضروري فهم ليس فقط مزايا تقنية تحليل التدفق ، ولكن أيضًا حدودها.
نقطة أخرى من المهم تذكرها عند الحديث عن أدوات تحليل التدفق. إذا طبقنا مقياس EPS (الحدث في الثانية ، الأحداث في الثانية) فيما يتعلق بالوسائل المعتادة لتوليد الأحداث الأمنية ، فإن هذا المؤشر لا ينطبق على تحليل القياس عن بُعد ؛ يتم استبداله بـ FPS (التدفق في الثانية ، التدفق في الثانية). كما في حالة EPS ، لا يمكن حسابها مسبقًا ، ولكن من الممكن تقدير العدد التقريبي للخيوط التي يولدها جهاز معين اعتمادًا على مهمته. على الإنترنت ، يمكنك العثور على جداول ذات قيم تقريبية لأنواع مختلفة من أجهزة المؤسسات وشروطها ، والتي ستسمح لك بتقدير نوع التراخيص التي تحتاجها لأدوات التحليل وما هي بنيتها؟ الحقيقة هي أن مستشعر IDS مقيد بنطاق ترددي معين ، والذي سوف "يسحب" ، ولجمع التدفق حدوده الخاصة التي يجب فهمها. لذلك ، في الشبكات الكبيرة الموزعة جغرافيًا ، يوجد عادةً العديد من المجمعين. عندما وصفت ، لقد أعطيت بالفعل عدد هواة الجمع لدينا - هناك 21 منهم. وهذا لشبكة منتشرة عبر القارات الخمس ويبلغ عددهم حوالي نصف مليون جهاز نشط).
نحن نستخدم الحل الخاص بنا كنظام مراقبة Netflow ، والتي تركز بشكل خاص على حل المشكلات الأمنية. يحتوي على العديد من المحركات المدمجة لاكتشاف الأنشطة الشاذة والمشبوهة والضارة بشكل واضح ، مما يسمح لك باكتشاف مجموعة واسعة من التهديدات المختلفة - من التشفير إلى تسرب المعلومات ، من توزيع التعليمات البرمجية الخبيثة إلى الاحتيال. مثل معظم أجهزة تحليل التدفق ، تم تصميم Stealthwatch على مخطط من ثلاثة مستويات (مولد - مجمّع - محلل) ، ولكن يتم استكماله بعدد من الميزات المثيرة للاهتمام والتي تعتبر مهمة في سياق المادة قيد الدراسة. أولاً ، يتكامل مع حلول التقاط الحزم (مثل Cisco Security Packet Analyzer) ، مما يسمح لك بتسجيل جلسات الشبكة المحددة للتحقيق والتحليل المتعمق لاحقًا. ثانيًا ، لتوسيع مهام الأمان على وجه التحديد ، قمنا بتطوير بروتوكول nvzFlow خاص يسمح لك "ببث" نشاط التطبيق على العقد الطرفية (الخوادم ومحطات العمل وما إلى ذلك) في القياس عن بُعد ونقله إلى المجمع لمزيد من التحليل. إذا كانت Stealthwatch في نسختها الأصلية تعمل مع أي بروتوكول تدفق (sFlow و rFlow و Netflow و IPFIX و cFlow و jFlow و NetStream) على مستوى الشبكة ، فإن دعم nvzFlow يسمح بربط البيانات أيضًا على مستوى العقدة ، وبالتالي. تحسين كفاءة النظام الإجمالية ورؤية هجمات أكثر من أجهزة تحليل تدفق الشبكة التقليدية.
من الواضح أنه عند الحديث عن أنظمة تحليل Netflow من وجهة نظر أمنية ، فإن السوق لا يقتصر على حل واحد من Cisco. يمكنك استخدام كل من الحلول التجارية والمجانية أو البرامج المشتركة. من الغريب أن أذكر حلول المنافسين على مدونة Cisco ، لذلك سأقول بضع كلمات حول كيفية تحليل القياس عن بعد للشبكة باستخدام أداتين شائعتين ، متشابهتين في الاسم ، لكن لا تزالان مختلفتين - SiLK و ELK.
SiLK عبارة عن مجموعة من الأدوات (نظام المعرفة على مستوى الإنترنت) لتحليل حركة المرور التي طورها American CERT / CC والتي تدعم ، في سياق مقالة اليوم ، Netflow (الإصداران الخامس والتاسع الأكثر شيوعًا) و IPFIX و sFlow واستخدام أدوات مساعدة مختلفة (rwfilter و rwcount و rwflowpack وما إلى ذلك) لإجراء عمليات مختلفة على القياس عن بعد للشبكة من أجل اكتشاف علامات الإجراءات غير المصرح بها فيه. ولكن هناك بعض الأشياء المهمة التي يجب ملاحظتها. SiLK هي أداة سطر أوامر وتقوم بإجراء تحليل عبر الإنترنت ، كل ذلك أثناء كتابة أمر النموذج (اكتشاف حزم ICMP أكبر من 5 بايت):
rwfilter --flowtypes=all/all --proto=1 --bytes-per-packet=200- --pass=stdout | rwrwcut --fields=sIP,dIP,iType,iCode --num-recs=15
غير مريح للغاية. يمكنك استخدام iSiLK GUI ، لكنها لن تجعل حياتك أسهل بكثير من خلال حل وظيفة التصور فقط ، وليس استبدال المحلل. وهذه هي النقطة الثانية. على عكس الحلول التجارية ، التي لديها بالفعل قاعدة تحليلية صلبة ، وخوارزميات اكتشاف الشذوذ المقابلة لسير العمل ، وما إلى ذلك ، في حالة SiLK ، سيتعين عليك القيام بكل هذا بنفسك ، الأمر الذي سيتطلب كفاءات مختلفة قليلاً منك عن استخدام جاهز بالفعل -مجموعة أدوات للاستخدام. هذا ليس جيدًا وليس سيئًا - هذه ميزة لأي أداة مجانية تقريبًا تأتي من حقيقة أنك تعرف ما يجب القيام به ، وستساعدك فقط في هذا (الأدوات التجارية أقل اعتمادًا على كفاءات مستخدميها ، على الرغم من أنه يفترض أيضًا أن المحللين يفهمون على الأقل أساسيات إجراء تحقيقات الشبكة ومراقبتها). لكن لنعد إلى SiLK. تكون دورة عمل المحلل معها كالتالي:
- صياغة الفرضية. يجب أن نفهم ما سنبحث عنه داخل شبكة القياس عن بعد ، وأن نعرف السمات الفريدة التي من خلالها سنحدد بعض الحالات الشاذة أو التهديدات.
- بناء نموذج. بعد صياغة فرضية ، نقوم ببرمجتها باستخدام نفس لغة Python أو shell أو غيرها من الأدوات التي لم يتم تضمينها في SiLK.
- اختبارات. حان الوقت للتحقق من صحة فرضيتنا ، والتي تم تأكيدها أو دحضها باستخدام أدوات SiLK التي تبدأ بـ "rw" و "set" و "bag".
- تحليل البيانات الحقيقية. في العملية التجارية ، تساعدنا SiLK في تحديد شيء ما ويجب على المحلل الإجابة على الأسئلة "هل وجدنا ما توقعناه؟" ، "هل يتوافق هذا مع فرضيتنا؟" ، "كيف سيقلل عدد الإيجابيات الخاطئة؟" ، "كيف تحسن مستوى الاعتراف؟" وما إلى ذلك وهلم جرا.
- تحسين. في المرحلة النهائية ، نقوم بتحسين ما تم القيام به في وقت سابق - نقوم بإنشاء قوالب ، وتحسين الشفرة وتحسينها ، وإعادة صياغة الفرضية وصقلها ، إلخ.
ستنطبق هذه الدورة على نفس Cisco Stealthwatch ، فقط الخطوة الأخيرة من هذه الخطوات الخمس تعمل تلقائيًا إلى أقصى حد ، مما يقلل من عدد أخطاء المحللين ويزيد من كفاءة اكتشاف الحوادث. على سبيل المثال ، في SiLK ، يمكنك إثراء إحصاءات الشبكة بالبيانات الخارجية على عناوين IP الضارة باستخدام البرامج النصية الخاصة بك ، وفي Cisco Stealthwatch ، هذه وظيفة مضمنة تعرض لك تنبيهًا فورًا إذا حدث تفاعل مع عناوين IP المدرجة في القائمة السوداء في الشبكة مرور.
إذا صعدت هرم البرامج "المدفوعة" لتحليل التدفق ، فسيتبع SiLK المجاني تمامًا برنامج ELK التجريبي ، الذي يتكون من ثلاثة مكونات رئيسية - Elasticsearch (فهرسة البيانات والبحث فيها وتحليلها) ، Logstash (إدخال / إخراج البيانات ) و Kibana (التصور). على عكس SiLK ، حيث يتعين عليك كتابة كل شيء بنفسك ، فإن ELK لديها بالفعل العديد من المكتبات / الوحدات الجاهزة (بعضها مدفوع ، والبعض الآخر ليس كذلك) التي تعمل على أتمتة تحليل القياس عن بعد للشبكة. على سبيل المثال ، يسمح لك مرشح GeoIP في Logstash بربط عناوين IP المراقبة بموقعها الجغرافي (نفس Stealthwatch لها هذه الوظيفة المدمجة).
تمتلك ELK أيضًا مجتمعًا كبيرًا إلى حد ما يضيف المكونات المفقودة إلى حل المراقبة هذا. على سبيل المثال ، للعمل مع Netflow و IPFIX و sFlow ، يمكنك استخدام الوحدة النمطية إذا لم تكن راضيًا عن وحدة Logstash Netflow التي تدعم Netflow فقط.
لإعطاء مزيد من الكفاءة في جمع التدفق والبحث فيه ، تفتقر ELK حاليًا إلى التحليلات الغنية المضمنة لاكتشاف الحالات الشاذة والتهديدات في القياس عن بُعد للشبكة. أي بعد دورة الحياة الموضحة أعلاه ، سيتعين عليك وصف نماذج الانتهاك بشكل مستقل ثم استخدامها في نظام القتال (لا توجد نماذج مدمجة).
بالطبع ، هناك امتدادات أكثر تعقيدًا لـ ELK ، والتي تحتوي بالفعل على بعض النماذج لاكتشاف الحالات الشاذة في القياس عن بُعد للشبكة ، لكن هذه الإضافات تكلف مالًا والسؤال هو ما إذا كانت اللعبة تستحق كل هذا العناء - اكتب نموذجًا مشابهًا بنفسك ، اشترِ تنفيذه من أجل أداة المراقبة الخاصة بك أو اشترِ حلاً جاهزًا لفئة تحليل حركة مرور الشبكة.
بشكل عام ، لا أريد الخوض في الجدل حول ما إذا كان من الأفضل إنفاق الأموال وشراء حل جاهز لرصد الحالات الشاذة والتهديدات في القياس عن بُعد للشبكة (على سبيل المثال ، Cisco Stealthwatch) أو اكتشاف ذلك بنفسك وقم بالتعديل نفس SiLK أو ELK أو nfdump أو OSU Flow Tools لكل تهديد جديد (أتحدث عن الأخيرين منهم آخر مرة)؟ يختار الجميع لأنفسهم وكل شخص لديه دوافعه الخاصة لاختيار أي من الخيارين. أردت فقط أن أوضح أن التتبع عن بعد للشبكة هو أداة مهمة للغاية في ضمان أمن الشبكة للبنية التحتية الداخلية الخاصة بك ويجب ألا تهملها ، حتى لا تضيف إلى القائمة شركة مذكورة اسمها في الوسائط جنبًا إلى جنب مع الصفات. "اختراق" ، "غير متوافق مع متطلبات أمن المعلومات" ، "لا يفكرون في أمان بياناتهم وبيانات العملاء.
بإيجاز ، أود أن أسرد النصائح الرئيسية التي يجب عليك اتباعها عند إنشاء مراقبة أمن المعلومات للبنية التحتية الداخلية الخاصة بك:
- لا تقصر نفسك على المحيط فقط! استخدم (واختر) البنية التحتية للشبكة ليس فقط لنقل حركة المرور من النقطة A إلى النقطة B ، ولكن أيضًا لحل مشكلات الأمن السيبراني.
- ادرس آليات مراقبة أمن المعلومات الموجودة في معدات شبكتك واستخدمها.
- للمراقبة الداخلية ، أعط الأفضلية لتحليل القياس عن بعد - فهو يسمح لك باكتشاف ما يصل إلى 80-90٪ من جميع حوادث أمن معلومات الشبكة ، بينما تفعل ما هو مستحيل عند التقاط حزم الشبكة وتوفير مساحة التخزين لجميع أحداث أمن المعلومات.
- لمراقبة التدفقات ، استخدم Netflow v9 أو IPFIX - فهي توفر مزيدًا من المعلومات في سياق الأمان وتسمح لك بمراقبة ليس فقط IPv4 ، ولكن أيضًا IPv6 و MPLS وما إلى ذلك.
- استخدم بروتوكول تدفق غير مستند إلى عينات - يوفر مزيدًا من المعلومات لاكتشاف التهديدات. على سبيل المثال ، Netflow أو IPFIX.
- تحقق من حمل معدات الشبكة - فقد لا تتمكن من معالجة بروتوكول التدفق أيضًا. ثم ضع في اعتبارك استخدام أجهزة استشعار افتراضية أو جهاز Netflow Generation.
- تنفيذ التحكم في المقام الأول على مستوى الوصول - سيمنحك هذا فرصة لرؤية 100٪ من إجمالي حركة المرور.
- إذا لم يكن لديك خيار وكنت تستخدم معدات شبكة روسية ، فاختر واحدًا يدعم بروتوكولات التدفق أو به منافذ SPAN / RSPAN.
- اجمع بين كشف التسلل / الهجوم / المنع على الحدود وأنظمة تحليل التدفق في الشبكة الداخلية (بما في ذلك في السحب).
بالنسبة للنصيحة الأخيرة ، أود أن أقدم توضيحًا سبق لي أن قدمته من قبل. يمكنك أن ترى أنه إذا قامت خدمة Cisco IS في وقت سابق ببناء نظام مراقبة IS الخاص بها بالكامل تقريبًا استنادًا إلى أنظمة الكشف عن التطفل وأساليب التوقيع ، فإنهم يمثلون الآن 20٪ فقط من الحوادث. يتم احتساب 20 ٪ أخرى من خلال أنظمة تحليل التدفق ، مما يشير إلى أن هذه الحلول ليست نزوة ، ولكنها أداة حقيقية في أنشطة خدمات أمن المعلومات في مؤسسة حديثة. علاوة على ذلك ، لديك أهم شيء لتنفيذها - البنية التحتية للشبكة ، والاستثمارات التي يمكن حمايتها بشكل إضافي عن طريق تعيين وظائف مراقبة أمن المعلومات للشبكة.
لم أتطرق عمدًا إلى موضوع الرد على الحالات الشاذة أو التهديدات المكتشفة في تدفقات الشبكة ، لكنني أعتقد أنه من الواضح أن المراقبة لا ينبغي أن تنتهي فقط باكتشاف التهديد. يجب أن يتبعه رد ويفضل أن يكون في الوضع التلقائي أو الآلي. لكن هذا موضوع لمقال منفصل.
معلومات إضافية:
ملاحظة. إذا كان من الأسهل بالنسبة لك الاستماع إلى كل ما تم كتابته أعلاه ، فيمكنك مشاهدة العرض التقديمي لمدة ساعة والذي شكل أساس هذه الملاحظة.
المصدر: www.habr.com