📋 🥠 🚶🏾 تقرير أمان الشبكة ومدى توفره Qrator Labs 💇🏼 👾 ⏪

لدينا تقليد في مختبرات Qrator - في البداية ، وبالتأكيد ليس شهر فبراير النهاية ، كل عام ينشر تقريرًا عن العام السابق.

مثل أي كيان معمر ، فهو محاط بالعديد من القصص ذات الصلة. على سبيل المثال ، لقد أصبح بالفعل فألًا "جيدًا" عندما يصل هجوم DDoS آخر في بداية شهر كانون الثاني (يناير) على صفحات الشركة ، وهو ما لا يتوفر لدينا الوقت لإبلاغه في التقرير. 2020 كان نصف الاستثناء - تمكنا من وصف ناقلات الهجوم (تضخيم TCP SYN-ACK) ، لكن كان على الضيف qrator.net أن جاء الضيف (وليس واحدًا) فقط في 18 يناير ، ولكن على الفور مع الضيوف: 116 جيجابت في الثانية عند 26 Mpps.

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

سنبدأ بموضوعين من أكثر المواضيع إثارة للاهتمام العام الماضي: تضخيم SYN-ACK و "تحسينات" BGP.

تضخيم TCP SYN-ACK والبروتوكولات الأخرى

يعني نمو سوق إنترنت الأشياء ، من بين أمور أخرى ، أنه يمكن للمهاجمين استغلال الأجهزة الضعيفة إذا رغبوا في ذلك ، مما يؤدي إلى إنشاء نطاق ترددي كبير للهجوم - كما حدث في منتصف العام عندما تم استخدام بروتوكول WSDD لإحداث ضرر واضح. كان بروتوكول Apple ARMS ، الذي تم استخدامه للحصول على معامل تضخيم من الترتيب 35.5 ، مرئيًا أيضًا في الهجمات على شبكة تصفية Qrator Labs.

خلال عام 2019 ، تعلم الجمهور أيضًا عن مضخمات الصوت الجديدة (PCAP) ، وشاهدوا شخصيًا أيضًا ناقل الهجوم المعروف منذ فترة طويلة والذي يشمل TCP - SYN-ACK. الفرق الرئيسي بين هذه الطريقة وتضخيم UDP النموذجي هو أن ناقل SYN-ACK لا يستخدم استجابة أكبر من الطلب - وبدلاً من ذلك ، فإنه يحاول فقط الرد على طلب TCP عدة مرات ، وبالتالي إنشاء معامل تضخيم ملحوظ. نظرًا لأن الغيوم العامة على الإنترنت تستجيب للحزم بتزييف عنوان المصدر ، فقد أصبحت الهجمات التي تنطوي على ناقل تضخيم SYN-ACK أحد أخطر التهديدات على الشبكة. حدث الأوج عندما تحول مزود استضافة سحابة رئيسي Servers.com إلى مختبرات Qratorمع طلب للمساعدة في تحييد هجمات DDoS ، بما في ذلك ناقل SYN-ACK.

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

على الرغم من أن تضخيم TCP SYN-ACK ليس جديدًا ، فقد ظل حتى الآن ناقل هجوم غير معروف نسبيًا. يرسل مهاجم حزم SYN إلى جميع خدمات TCP العامة على الإنترنت ، ويستبدل عنوان المصدر بعنوان الضحية ، وتستجيب كل من هذه الخدمات بدورها عدة مرات في محاولة لإنشاء اتصال - عادةً من 3 إلى 5. لفترة طويلة جدًا ، تم اعتبار ناقل الهجوم هذا لا معنى له ، وفقط في يوليو 2019 رأينا أن المهاجمين كانوا قادرين على توليد ما يكفي من النطاق الترددي المهاجم لزعزعة البنى التحتية للشبكات الضخمة والموزعة. هذا أمر غير معتاد بشكل خاص ، نظرًا للحقيقة المذكورة بالفعل لعدم وجود "تضخيم الاستجابة" في حد ذاته واستخدام فقط إمكانية إعادة الاتصال في البروتوكول في حالة الفشل. لأولئك،أي شخص مهتم بالبروتوكولات الأخرى ذات "القدرات" المتشابهة ، يمكنك الإشارة إلى بروتوكول QUIC ، الذي يوفر للخادم بالفعل خيار الرد على طلب العميل باستجابة مكبرة (على الرغم من أن مشروع البروتوكول "يوصي أيضًا" بعدم إرسال استجابة أكثر من ثلاثة أضعاف حجم الطلب).

توقف التضخيم عن كونه تهديدًا لمعاملات تبلغ حوالي 100x - من الواضح أن 3-5x كافية اليوم. يكاد يكون من المستحيل حل هذه المشكلة دون القضاء على ظاهرة حركة المرور "المنتحلة" كفئة - يجب ألا يتمكن المهاجم من محاكاة معرف شبكة شخص ما وإغراقه بحركة المرور من مصادر المحتوى المشروع. لا يعمل BCP38 (مجموعة من أفضل الممارسات والمقبولة عمومًا لإنشاء الشبكات وحل المواقف الإشكالية) على الإطلاق ، ويقيم مبدعو بروتوكولات النقل الجديدة - مثل QUIC - تقييمًا ضعيفًا للخطر الذي تشكله حتى قدرات التضخيم الصغيرة جدًا. هم على الجانب الآخر.

تحتاج الشبكات إلى طريقة موثوقة لتجاهل حركة المرور المنتحلة أو الحد منها على الأقل - ويجب أن تحتوي هذه الأداة على معلومات كافية حول شرعية مصدر الطلب. تعد الشبكات السحابية المملوكة لشركات مثل Amazon و Akamai و Google و Azure اليوم هدفًا مثاليًا تقريبًا لتضخيم TCP - لديهم الكثير من الأجهزة القوية التي يمكن أن تلبي جميع أهداف المهاجم تقريبًا.

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

مزيد من تطوير بروتوكول BGP ضروري من أجل استخدامه في مكافحة الانتحال في مجموعة بروتوكول TCP / IP. تختلف جداول التوجيه بشكل أساسي عن جداول الشبكة الفرعية ، ونحن بحاجة إلى تعليم الشبكة لعزل حزمة غير مشروعة والتخلص منها بسرعة - وبعبارة أخرى ، توفير المصادقة على مستوى البنية التحتية للشبكة. يجب الانتباه ليس إلى "عنوان الوجهة" ، ولكن إلى "عنوان المصدر" من أجل مطابقته مع المعلومات الواردة في جدول التوجيه.

BGP - "محسنون"

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

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

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

تمت كتابة العديد من النصوص لعام 2019 ، بما في ذلك من قبل شركتنا.، حول مخاطر "تحسين BGP". في حالة Verizon ، بطبيعة الحال ، فإن إنشاء سياسة تصفية جديدة لكل مستهلك جديد للخدمة ليس أمرًا ممتعًا. ومن المعروف أيضًا أن Verizon لا تحتوي على فلاتر ، لأنها اتخذت مئات المسارات الإشكالية من عميل AS396531 الخاص ، وهو "كعب" - نظام مستقل مع اتصال واحد. علاوة على ذلك ، لم يكن لدى عملاق الاتصالات حد للشبكة الفرعية لهذا الاتصال. لم يكن هناك حتى فحص أساسي لوجود مشغلين آخرين من المستوى 1 في طريقهم من المستهلك (يتم بدء هذا النوع من الفحص بشكل افتراضي ولا يتطلب الدعم أو التغيير).

في الصحافة ، تمت مناقشة هذا الحادث ، بما في ذلك Verizon و Cloudflare ، بقوة. بالإضافة إلى الإجراءات التي يمكن أن تتخذها شركة Verizon ، لاحظ الكثيرون فوائد RPKI والسجل الأقصى الصارم في ROA. ولكن ماذا عن maxLength؟ من المعروف أنه مع التحقق الدقيق من الحد الأقصى لطول التسجيل ، تصبح جميع الإعلانات التي تشير إلى شبكات فرعية أصغر غير صحيحة عند التحقق من عائد الاستثمار. من المعروف أيضًا أن هناك سياسة لإعادة تعيين المسارات غير الصالحة. هناك أيضًا مسودة داخل IETF ، تشير إلى أن maxLength يجب أن تكون مساوية لطول بادئة الشبكة.

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

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

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

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

في مارس 2019 ، كانت هناك حالة أخرى ، لم نربطها في وقت واحد بتحسين BGP. ومع ذلك ، فإنه يستحق الاهتمام أيضًا.

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

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

إذا تحدثنا عن آليات أمان BGP أخرى ، فلن يساعد ASPA في هذا النوع من الاعتراض ، لأن AS_PATH ينتمي إلى المسار الصحيح. BGPSec غير فعال حاليًا بسبب نقص الدعم والقدرة المتبقية على تنفيذ هجمات خفض المستوى.

لا يزال هناك دافع لزيادة الربحية بسبب تلقي كل حركة مرور الأنظمة الذاتية مع العديد من مقدمي الخدمات وغياب أي وسيلة للحماية.

العدد الإجمالي للحلقات الثابتة في الشبكة.

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

باستخدام Radar.Qrator ، يمكنك تتبع مثل هذه الأحداث. للقيام بذلك ، نحتاج إلى معلومات أساسية حول البادئات الخاصة بك. يمكنك إنشاء جلسة BGP مع جامع وتوفير معلومات حول رؤيتك للإنترنت. كما نقدر بشكل إيجابي أولئك الذين هم على استعداد لإرسال جدول توجيه كامل (عرض كامل) إلينا - وهذا يساعد على تتبع مدى الحوادث ، ولكن لمصلحتك الخاصة والبدء في استخدام الأداة ، فإن قائمة المسارات تكفي فقط للبادئات الخاصة بك. إذا كان لديك بالفعل جلسة مع Radar.Qrator ، يرجى التحقق من أنك ترسل المسارات. للكشف التلقائي والإبلاغ عن الهجمات على مساحة العنوان الخاصة بك ، هذه المعلومات ضرورية.

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

البنوك

في عام 2019 ، أجرينا دراسة في روسيا ، أظهرت أن المؤسسات المالية سجلت زيادة في أهمية أمن المعلومات وبدأت في إعطاء هذه الاستثمارات أولوية أعلى.

تحدد البنوك المستجيبة الضرر المالي والسمعي على أنه أخطر عواقب خروقات أمن المعلومات.

تعتبر معظم المؤسسات المالية التي شملتها الدراسة أن الحلول الهجينة هي أكثر الوسائل فعالية لمواجهة هجمات الحرمان الموزعة من الخدمة.

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

التجارة الإلكترونية

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

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

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

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

DNS عبر HTTPS مقابل DNS عبر TLS

كان أحد أهم مواضيع عام 2019 هو الجدل حول التكنولوجيا التي يحملها المستقبل - DoH أو DoT. يرجع التناقض الأولي إلى كل من الاختلافات الكبيرة في التشريعات المختلفة (الاتحاد الأوروبي لحماية البيانات العامة مقابل القوانين الفيدرالية وقوانين الولايات في الولايات المتحدة الأمريكية) ، والمنافسة في سوق المتصفح الرئيسي: Google Chrome و Mozilla Firefox ، وكذلك Apple Safari. لسنا مستعدين للقول ما إذا كان إدخال أي من هذه التقنيات سيقلل من عدد مكبرات الصوت على الإنترنت. ومع ذلك ، مع خيار DoT ، يبدو هذا ممكنًا أكثر من وجهة نظر معمارية بسبب إنشاء اتصالات آمنة بين محللي DNS. فيما يتعلق بالتوقعات الأخرى ، سننتظر القرار الذي ستتخذه السوق.

أكثر الصناعات هجومًا في عام 2019.

نقاط الضعف في إقرار TCP

في يونيو 2019 ، ظهرت التفاصيل الأولى حول وجود ثغرات أمنية خطيرة في بعض عمليات تنفيذ مجموعة بروتوكولات TCP / IP ، وفقًا لما أوردته Netflix . من المفترض ، تم اكتشاف المشكلة في الأصل في نظام تشغيل FreeBSD ، وبعد ذلك تلقت شركتنا تأكيدًا على وجود نفس الثغرات ونقاط الضعف الأخرى في Linux.

أخطر CVE-2019-11477 (SACK Panic) ، والذي يمكن أن يسمح للمهاجم باستدعاء ذعر kernel باستخدام سلسلة من الحزم المشكلة خصيصًا. يمكن أن تؤدي ثلاث نقاط ضعف أخرى إلى الاستهلاك المفرط للموارد ، مما قد يؤدي إلى الحرمان من الخدمة.

يمكن أن يؤدي تعطيل وظيفة SACK إلى زيادة وقت الاستجابة ، ومع ذلك ، فإن هذا سيحمي الخوادم من هجمات رفض الخدمة المحتملة - يعد الانخفاض المؤقت في أداء TCP / IP ، وفقًا لـ Qrator Labs ، طريقة معقولة لتحييد ثغرة خطيرة. لطالما كانت التصحيحات التي تغطي نقاط الضعف هذه متاحة ويوصى بالتثبيت.

مستقبل توجيه BGP

في نهاية عام 2019 ، Radar.Qrator هو أكبر منصة BGP العالمية للتوجيه والتحليلات مع أكثر من 650 جلسة محددة.

يعمل فريق Radar.Qrator على تحسين قابلية الاستخدام والموثوقية للخدمة ، وإدخال تحسينات على نموذج علاقة BGP ، وهو أساس خدمة مدفوعة لرصد نظام مستقل في الوقت الفعلي.

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

ينمو Radar.Qrator بشكل أسرع من المتوقع - سواء من حيث عدد زوار الموقع وعدد المشتركين في نفس الوقت. في عام 2020 ، وبفضل التعليقات الواردة من العملاء ، سيتم تقديم العديد من التحسينات الهامة في وقت واحد ، وسيكون أحد هذه الأشياء تخزينًا جديدًا للحوادث لكل نظام مستقل.

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

المخطط المقترح لآلية أسبا.

نأمل أيضا أنه خلال هذا العام ASPAسيصبح RFC - معيار شبكة معتمد. إن الحاجة إلى مجموعة أوسع من مجموعة IRR / RPKI ، وخفة الوزن أكثر من حل BGPSec ، واضحة للجميع في الصناعة. في عام 2019 ، أصبح من الواضح كيف يمكن لتكوين BGP غير الصحيح أن يؤدي إلى تسريبات مسار ذات عواقب وخيمة في شكل عدم توفر عدد كبير من الخدمات التي تشمل أكبر مزودي خدمة الإنترنت. والمثير للدهشة أن هذه الحوادث أثبتت مرة أخرى أنه لا توجد رصاصة فضية يمكنها التغلب على جميع السيناريوهات المحتملة لتطورها.

يحتاج أكبر مزودي الإنترنت في العالم إلى دعم الحركة الأولية. الخطوة التالية هي إشراك المجتمعات الكبيرة التي يمكن أن تساعد في العثور على مصدر تحويل المسار. بعبارات بسيطة ، فإن ASPA هي كيان جديد يجمع بين القدرات الحالية لـ ROA و RPKI - فهي تنفذ المبدأ البسيط: "اعرف المورد الخاص بك". يحتاج مالك AS إلى معرفة المنبع فقط من أجل تنفيذ طريقة موثوقة كافية للحماية من حوادث توجيه BGP.

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

واحدة من المزايا الرئيسية لـ ASPA هي أنها فكرة بسيطة للغاية. في عام 2020 ، من المخطط استكمال العمل على مشروع البروتوكول ، وإذا نجحت ، فإن IETF والمؤلفين المشاركين في المسودة سوف يتوصلون إلى توافق في الآراء بشأن تعزيز حالة البروتوكول.

التطور الحالي والمستقبلي لشبكة ترشيح Qrator

منطق التصفية

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

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

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

توزيع هجمات DDoS لعام 2019 حسب النطاق المستخدم.

HTTP / 2

تم حل المشكلات المتعلقة بتنفيذ بروتوكول HTTP / 2 (رفض ثغرات الخدمة) بشكل أساسي خلال عام 2019 ، مما سمح لنا بتمكين دعم هذا البروتوكول داخل شبكة تصفية Qrator.

الآن العمل مستمر بنشاط من أجل توفير حماية HTTP / 2 لكل عميل ، وإكمال فترة اختبار طويلة وعميقة. إلى جانب دعم HTTP / 2 ، قدم TLS 1.3 إمكانية استخدام eSNI مع الإصدار التلقائي لشهادات الأمان Let's Encrypt.

حاليا ، HTTP / 2 متاح عند الطلب كخيار إضافي.

الحاويات والتنظيم

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

يتطلب مستقبل تطوير وتطوير الشبكات الموزعة والمتسامحة مع الخطأ إدخال الأدوات المناسبة (CI / CD والاختبار التلقائي جزء منها) والقدرة على استخدامها لإنشاء وإدارة نظام مستقر وموثوق. مع زيادة كمية البيانات فقط ، يجب أن تنمو جهود المراقبة بعدها. الطريقة الأكثر طبيعية لبناء المراقبة هي توفير طريقة اتصال آمنة ويمكن ملاحظتها بسهولة للتطبيقات. نعتقد أن Kubernetes قد أثبتت بالفعل تنوعها وقابليتها للتطبيق ، وتخصصها الإضافي لاحتياجات البنية التحتية التي تحارب هجمات DDoS هو حقيقة العمل مع أي حل مفتوح المصدر.

التغيير في متوسط مدة هجمات DDoS من 2018 إلى 2019.

Yandex.Cloud و Ingress 2.0

في عام 2019 ، قدمنا مع Yandex.Cloud ، إصدارًا محدثًا من خدمتنا لتصفية حركة المرور الواردة - Ingress ، مما أدى إلى توسيع قدرات التصفية والتكوين بشكل كبير ، مما يوفر للمستخدم واجهات إدارة واضحة. يعمل الإصدار الجديد من الخدمة بالفعل على شبكة تصفية Qrator Labs ، وكذلك على شبكة Yandex.Cloud.

لقد قطع فريق Yandex.Cloud شوطًا طويلاً معنا ، حيث جمع بين بنيتين أساسيتين باستخدام العقد الفعلية Qrator Labs الموجودة داخل البنية التحتية للشريك والتي تعمل على حركة المرور.

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

كما نعتبر نجاحًا كبيرًا أن الإصدار الجديد من الخدمة بديهي للمستخدم النهائي ويسمح لك بتهيئة معلمات التصفية بشكل أكثر مرونة.

شهادات TLS 1.3 و ECDSA

في بداية عام 2019 ، كتب مختبرات Qrator عن دعم TLS الإصدار 1.3 مع تعطيل SSL v.3. نظرًا لتوفر خدمة معادلة DDoS دون الكشف عن مفاتيح التشفير ، تم إجراء تحسينات إضافية على نظام التصفية هذا ، مما يزيد من سرعة وموثوقية ترجمة سجل النظام. دعونا نتذكر نتائج قياسات الأداء .

نوع التوقيع	المصافحة في الثانية
ECDSA (prime256v1 / nistp256)	3358.6
RSA 2048	972.5

كما ترى ، على مركز واحد من Intel® Xeon® Silver 4114 CPU @ 2.20GHz (تم إصداره في الربع الثالث من 17) ، فإن الفرق الكلي بين أداء ECDSA و RSA المقبول عمومًا بطول رئيسي يبلغ 2048 بت هو 3.5 مرة.

دعونا نلقي نظرة على نتائج تشغيل الأمر opensl -speed لـ ECDSA و RSA على نفس المعالج.

نوع التوقيع	إشارة	تحقق	تسجيل / ثانية	تحقق / ثانية
RSA 2048 بت	717 ثانية	20.2 ثانية	1393.9	49458.2
256 بت ECDSA (nistp256)	25.7 ثانية	81.8 ثانية	38971.6	12227.1

هنا يمكننا أن نجد تأكيدًا لرسالة مكتوبة مسبقًا حول كيفية اختلاف العمليات الحسابية للتوقيع والتحقق منه بين ECC و RSA. حاليا، مسلحة مع TLS 1.3، والترميز القائم على المنحنيات الإهليلجية يعطي زيادة كبيرة في أداء الخادم مع ل مستوى أعلى من الحماية مقارنة RSA. هذا هو السبب الرئيسي الذي يجعلنا في Qrator Labs نوصي ونشجع بشدة العملاء المستعدين لاستخدام شهادات ECDSA أيضًا. على وحدات المعالجة المركزية الحديثة ، فإن مكاسب الأداء لصالح ECDSA هي 5x.

تحسينات أصغر

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

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

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

مقارنة بين مجموعتي التصنيف الرئيسيتين لهجمات DDoS لعام 2019.

IPv6

تستعد مختبرات Qrator بنشاط لبدء استخدام IPv6 كجزء من خدمات تصفية حركة المرور. بالنسبة لأي شركة للأمن السيبراني ، لا يمكن أن يكون مثل هذا الانتقال أوليًا. نظرًا لطبيعة هجمات DDoS ، فإن تحييد هجمات الشبكة باستخدام IPv6 يتطلب تغييرًا جذريًا في النهج ، حيث لم يعد من الممكن التعامل مع أي شكل من أشكال "القائمة" ، للتعامل مع الحد النظري البالغ ^2،128 عنوان IP. والأمر يتعلق فقط ببروتوكول التحكم في الإرسال ، وليس في الاعتبار UDP.

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

انتيبوت

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

نظرًا لأن برامج التتبُّع تولد حصة متزايدة من حركة المرور ، يمكننا أن نتوقع لحظة مستقبلية عندما تنشئ الخدمات الكبيرة واجهات خاصة للبوتات الجيدة ، مما يمنحها معلومات شرعية. سيتم حظر الباقي. حتى الآن ، في بداية عام 2020 ، يمكن القول أنه لا يمكن لمستخدم شرعي بنسبة 100 ٪ الوصول إلى أي مورد على الإنترنت على الفور - لن يسمح الكثير بذلك إذا قلنا ، على سبيل المثال ، مجرد تغيير وكيل مستخدم المتصفح إلى عامل تعسفي.

داخل مختبرات Qrator ، تم تطوير خدمة المضاد الحيوي بنشاط لعدة سنوات ، ونتوقع في عام 2020 أن نقدمها لعملائنا الأوائل كجزء من خدمة بيتا. ستعمل هذه الخدمة في أوضاع شبه وتلقائية ، مما يجعل من الممكن تحديد وتعيين قواعد الأمان مقابل عدد من الطلبات الآلية أو الصادرة من الروبوتات.

معدات

بعد اختبار معالجات AMD الجديدة ، كان الموظفون المسؤولون في الشركة مفتونين لدرجة أنه في الربع الأول من عام 2020 ، ستقوم مختبرات Qrator Labs بتوظيف نقطة تواجد جديدة في أوساكا ، اليابان ، مبنية بالكامل على معالجات AMD. يعد الجيل الرابع من PCI Express ، المتوفر مع وحدات معالجة AMD ، بمضاعفة عرض النطاق الترددي بين وحدة المعالجة المركزية وواجهة الشبكة. خلال العام ، سيتم اختبار وتقييم استخدام هذا الرباط في أكثر السيناريوهات ضغطًا. تصبح القناة بين واجهة الشبكة والمعالج تدريجيًا رقبة ضيقة مع زيادة في كمية البيانات المرسلة في الشبكات. إن الجمع بين النوى الإضافية وذاكرة التخزين المؤقت الأكبر والإصدار الجديد من PCI Express يعد بتحقيق نتائج جيدة.

سبب آخر لاستخدام وحدة المعالجة المركزية AMD هو الحاجة إلى تنويع بنية الشبكة ، على الرغم من أن هذه هي نقطة الوجود الأولى لـ Qrator Labs ، المبنية بالكامل على المعالج الجديد.

نحن نتطلع حقًا إلى بدء عمل المعدات الجديدة ، والتي سيتم الإبلاغ عن إطلاقها بشكل منفصل في بداية عام 2020. نأمل أن يفي مزيج من معالجات AMD وبطاقات الشبكة عالية الأداء التي تستخدم PCI Express 4 بمتطلباتنا. تعتبر السوق الآسيوية واحدة من أسرع الأسواق نمواً ، وأود أن أقدر الاحتمالات الإضافية لتحييد هجمات DDoS بالمعدات الجديدة هناك.

في الوقت نفسه ، من المتوقع أيضًا وصول جيل جديد من معالجات Intel - Ice Lake. سيعتمد استخدامها الإضافي في بنيتنا التحتية إلى حد كبير على نتائج اختباراتهم ومقارنتهم.

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

فيما يتعلق بالمفاتيح - تواصل Qrator Labs العمل مع Mellanox ، والتي أثبتت مرارًا وتكرارًا أنها مورد وشريك موثوق به.

ليس هذا أمرًا سهلاً ، ولكن بينما تهيمن شركة Broadcom على سوق معدات الشبكات ، نأمل أن يمنح الاندماج مع NVidia Mellanox فرصة للمنافسة الجديرة بالاهتمام.

التحسينات المستقبلية لشبكة التصفية

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

كشفت 2019 أيضًا عن عدد من الأسئلة المتعلقة بحماية تقنية WebSockets. انتشاره وشعبيته ينمو فقط ، ولا يتم تقليل تعقيد الحماية المناسبة. خلال عام 2020 ، نتوقع العمل مع بعض عملائنا باستخدام تقنية WebSockets للعثور على أفضل طريقة لحمايتها ، حتى إذا أرسلنا بيانات عشوائية (غير معروفة).

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

نظرًا لأنك قد قرأت حتى النهاية ، فإليك ملف pdf . للتوزيع . لا تنس أمان الشبكة بنفسك - ولا تعطه للآخرين.

تقرير أمان الشبكة ومدى توفره Qrator Labs