ملخص
- مسار الهوية العامة قوي. يربط RIPE ORG-IL186-RIPE بـ MITIGATOR CLOUD LLC في موسكو، AS51464 يُسمى IBANK2RU، AS43048 يُسمى mitigator-cloud، وتظهر عروض RIPEstat الحالية كلا ASNين معلن عنهما في 12 يوليو 2026.
- يشير مسار الخدمة العامة إلى سعة تنظيف DDoS، وليس VPS عادي للخدمة الذاتية. يصف Mitigator Cloud خدمة روسية على مدار الساعة طوال أيام الأسبوع للعملاء من الشركات والبنوك وشركات تكنولوجيا المعلومات ومقدمي الخدمات، مع تحويل حركة المرور عن طريق تغيير سجل A، أو إعلان BGP ثابت أو أثناء الهجوم، وبادئات المزود، ونفق L2 وتسليم الوكيل العكسي.
- مخاطر الاعتماد الرئيسية مادية وتشغيلية. يعتمد العملاء على عقد التنظيف ومنافذ التوجيه وسعة الوصلة الصاعدة وسياسة البادئات وتغييرات DNS أو BGP ومسارات تسليم حركة المرور النظيفة وسلطة الدعم ونوافذ التحديث وإجراءات النسخ الاحتياطي وتوفر المهندسين أثناء الهجمات.
- درجة الأدلة متوسطة. هوية التوجيه وادعاءات الخدمة مدعومة جيداً بمصادر عامة؛ أدلة المنشأة والرفوف والسعة الاحتياطية واختبار الاستعادة وقابلية نقل العملاء لا تزال ضعيفة في السجل العام.
السؤال المفيد يبدأ من iBank2.RU
عنوان هذا الملف الشخصي يستخدم الاسم المدمج الغريب IBANK2RU MITIGATOR CLOUD LLC لأن الأدلة العامة تفعل الشيء نفسه. النظام الذاتي المعين في 2010 لم يُسمَ على اسم علامة تجارية سحابية حديثة. يُطلقسجل AS51464 في RIPEعلى الشبكة اسمIBANK2RU، ويربطها بـ ORG-IL186-RIPE، ويسرد مجموعة AS تسمىAS-IBANK2RU. يصف كائن مسار109.232.248.0/21البادئة بأنهاIBANK2.RU, Ltd.في 46 شارع نيجنيايا بيرفومايسكايا في موسكو، مع AS51464 كأصل. نفس العنوان يظهر في مسار مؤسسة RIPE لـ MITIGATOR CLOUD LLC.
مسار iBank2.RU الأقدم هذا مهم لأن الخدمة التي يتم تسويقها الآن باسم Mitigator Cloud تقدم نفسها كخليفة لوظيفة تنظيف حركة المرور، وليست منصة سحابية من الصفر. تقولالصفحة الرئيسية لـ Mitigator Cloudإن مركز كفاءة للحماية من DDoS أُنشئ في 2009، ومركز تنظيف حركة المرور المسمى iBank2.RU أُنشئ في 2010، وفي 2015 تم نقل مركز تنظيف iBank2.RU إلى حل MITIGATOR المطور داخلياً وأعيدت تسميته إلى Mitigator Cloud. هذه ادعاءات من تأليف الشركة، لذا لا ينبغي التعامل معها كدليل مستقل على كل تفاصيل التشغيل. ومع ذلك، فهي مركزية لفهم ما يفترض أن تكون عليه سعة الاستضافة: مكان يمكن فيه تحويل حركة مرور العملاء وفحصها وتصفيتها وإعادتها نظيفة.
بعبارة أخرى، الخطر لا يقتصر على ما إذا كان الجهاز الافتراضي يمكن تشغيله. الخطر هو ما إذا كانت الخدمة المحمية تظل قابلة للوصول عند ظهور حركة مرور معادية وتغيير توجيه حركة المرور تحت الضغط. قد يعتمد العميل على Mitigator Cloud لأن تطبيقاً محمياً بواسطة وكيل عكسي، أو لأنه يمكن الإعلان عن بادئة نحو خدمة التنظيف، أو لأنه يمكن تبديل سجل A، أو لأن نفقاً يسلم حركة المرور النظيفة إلى العميل، أو لأن مزود خدمة يستخدم سعة Mitigator خلف عقد الخدمة الخاص به. كل نموذج يحول وعداً سحابياً إلى سلسلة من الأصول المادية: أجهزة التوجيه والروابط والخوادم والتراخيص ومعالجات الحزم والتخزين والمراقبة ومكاتب الدعم ونوافذ الإصلاح.
يدعم السجل العام معاملة IBANK2RU MITIGATOR CLOUD LLC كاعتماد حقيقي على شبكة خدمة. لا يدعم معاملتها كسحابة متعددة المواقع شفافة تماماً ومحققة بشكل مستقل. هذا الفرق هو جوهر المقال. يمكن أن تكون الشركة مهمة حتى عندما لا تكشف المصادر العامة عن رفوفها. غياب الأدلة على مستوى الرفوف ليس دليلاً على الغياب؛ إنها مشكلة العناية الواجبة للمشتري.
الهوية القانونية والشبكية أوضح من هوية الرفوف
الهوية القانونية الشبكية هي أقوى جزء في الملف. يُعرّفكائن مؤسسة RIPE ORG-IL186-RIPEشركة MITIGATOR CLOUD LLC، البلد RU، مع عنوان موسكو في 46 شارع نيجنيايا بيرفومايسكايا، الرمز البريدي 105203، ورقم الهاتف +7 495 965 15 64. يسمي الكائنEXH1-RIPEكجهة اتصال للانتهاكات ويشير إلىMNT-IBANK2RUكأحد المشرفين. تم إنشاء السجل في نوفمبر 2009 وآخر تعديل في مايو 2026.
كائن المشرفMNT-IBANK2RUمفيد أيضاً لأنه يظهر الاستمرارية. تم إنشاؤه في نوفمبر 2009 وآخر تعديل في مايو 2026. يُسمىكائن الدور EXH1-RIPEiBank2RU Admin، ويعطي نفس عنوان موسكو، ويسرد[email protected]كصندوق بريد للانتهاكات. هذه ليست تفاصيل تسويقية. إنها تفاصيل سجل تربط تسمية iBank2.RU القديمة والاسم القانوني الحالي لـ Mitigator Cloud ومسار موارد أرقام الإنترنت العامة.
AS51464 هي شبكة iBank2.RU الأضيق. يظهر RIPE أنها مخصصة، تم إنشاؤها في 31 أغسطس 2010 وآخر تعديل في يونيو 2022. تذكر سياسة الاستيراد والتصدير خادم التوجيه في موسكو AS8631 وAS42861 وAS29226 وAS43048 وAS207104. يؤكدسجل RDAP لـ RIPE لـ AS51464اسم AS IBANK2RU ونطاق التخصيص أحادي AS وتاريخ التسجيل 2010 وروابط المسجل بـ ORG-IL186-RIPE وMNT-IBANK2RU.
AS43048 هي شبكة Mitigator الأوسع. يستخدمسجل AS43048 في RIPEاسم ASmitigator-cloud، ويربطه بـ ORG-IL186-RIPE، ويسرد سياسة مع RETN AS9002 وSpaceWeb AS202984 وCOMCOR AS8732 وخادم التوجيه في موسكو AS8631 وAS51464 وعدة ASNs تشبه العملاء أو الأقران. تاريخ آخر تعديل هو 18 يونيو 2026، وهو حديث بما يكفي لجعل الكائن ذا صلة بتحليل التوجيه الحالي مع استمرار الحاجة إلى قياسات BGP للحالة الحالية.
هيكل AS المزدوج مهم. يحمل AS51464 هوية iBank2.RU القديمة وبصمة IPv4 صغيرة ولكنها نشطة. يبدو أن AS43048 يحمل وضع التوجيه الأوسع لحماية السحابة، مع المزيد من الجيران المرصودين وIPv6. تشمل مجموعة ASAS-MITIGATOR-CLOUDكلاً من AS43048 وAS51464 وعدة ASNs أخرى. هذا يدعم سطح سياسة توجيه أوسع، لكن لا ينبغي تفسيره بشكل خاطئ على أنه مخطط ملكية. يمكن أن تعكس عضوية مجموعة AS العملاء أو الأقران أو الوصلات السفلية أو احتياجات سياسة التوجيه. يجب على عميل الخدمة المحمية أن يهتم بالـ AS المحدد والبادئة المحددة التي تحمل حركة مروره، وليس فقط اسم العلامة التجارية على صفحة الخدمة.
ما تعلن Mitigator Cloud علناً أنها تبيعه
أوضح دليل موجه للعملاء هوصفحة Mitigator Cloud. تصف الخدمة بالروسية بأنها حماية شاملة من DDoS على مدار الساعة طوال أيام الأسبوع للعملاء من الشركات والبنوك وشركات تكنولوجيا المعلومات ومقدمي الخدمات، مع مراقبة على مدار الساعة. تدعي الحماية ضد أنواع هجمات L3-L7، ونهج فردي، واكتشاف تلقائي للهجمات مع وقت استجابة يصل إلى خمس ثوانٍ، وإشعارات بالهجوم عبر البريد الإلكتروني وTelegram وVestochka push والرسائل النصية القصيرة. تقول الصفحة أيضاً أن الخدمة مبنية على برنامج MITIGATOR، الذي تصفه بأنه برنامج روسي مسجل في سجل البرامج المحلي تحت رقم 4063 ومعتمد من FSTEC بموجب شهادة رقم 5059.
هذا ليس تدقيقاً محايداً. إنها نسخة خدمة من تأليف الشركة. قيمتها أنها تحدد سطح الخدمة الذي يُطلب من العميل شراءه. Mitigator Cloud لا تدعي فقط "السحابة" بشكل تجريدي. تصف خيارات ملموسة لتوجيه حركة المرور: استبدال سجل A، إعلان BGP دائم، إعلان BGP أثناء الهجوم، واستخدام بادئات Mitigator Cloud. تصف أيضاً خيارات التسليم لحركة المرور النظيفة: نفق L2، وكيل عكسي TCP، وكيل عكسي HTTP/HTTPS. تلك التفاصيل تغير تحليل المخاطر من ملف استضافة عام إلى ملف توجيه وتنظيف.
موقع المنتجmitigator.ru/mainengيصف MITIGATOR كبرنامج حماية من DDoS للعملاء من الشركات والشركات الحكومية ومقدمي خدمات الأمن. يقول أن المنتج يكتشف ويقمع هجمات DDoS من المستوى L3-L7 ويحتوي على أكثر من 50 إجراء مضاد باستخدام منطق التحدي والاستجابة والسمعة والاعتماد على المعدل والتعبير العادي والتحقق والتحديد وقائمة IP وسلوك التطبيق. تضيفصفحة حولادعاءات المنتج حول التحكم في الوصول والحماية على مستوى السياسة والتحكم في API ولوحات المعلومات والتسليم بحاوية Docker ودعم معالج x86-64 وبطاقة الشبكة ودعم نفق GRE والتجاوز عبر الأجهزة. تصفصفحة الخدماتالتنفيذ والدعم والمساعدة الخبيرة والتدريب والمساعدة الحية أثناء الهجمات.
هناك حدود مهمة هنا. تقدم بيانات موقع المنتج AO BIFIT كمنظمة البرمجيات وراء MITIGATOR، بينما تسمي صفحة الخدمة السحابية LLC Mitigator Cloud في التذييل وتعطي[email protected]بالإضافة إلى نفس رقم الهاتف في موسكو الذي ظهر في RIPE. لا تستنتج هذه المقالة علاقة ملكية مؤسسية تتجاوز ما تقوله الصفحات العامة وسجلات التسجيل. إنها تتعامل مع صفحات المنتج كدليل لكيفية وصف تكنولوجيا الخدمة، وصفحات RIPE والسحابة كدليل لهوية خدمة شبكة Mitigator Cloud.
بالنسبة للعملاء، تشير ادعاءات الخدمة إلى عدة أسئلة حول الاعتماد. إذا كانت الحماية تتم عن طريق استبدال سجل A، فما مدى سرعة تغيير DNS وما هي قيم TTL السارية؟ إذا كانت الحماية تتم عن طريق إعلان BGP دائم، فما هي تغييرات زمن الوصول والتوجيه الطبيعية حتى بدون هجوم؟ إذا كانت الحماية تتم فقط أثناء الهجمات، فمن يأذن بالإعلان وكيف تتأثر الجلسات الحالية؟ إذا تم تسليم حركة المرور النظيفة عبر نفق أو وكيل، فأين ينتهي التشفير، ومن يحتفظ بالأسرار، وما هي السجلات المخزنة، وماذا يحدث عند فشل نقطة نهاية النفق؟ هذه ليست أسئلة أكاديمية. إنها الأماكن التي تصبح فيها خدمة التنظيف الموعودة اعتماداً تشغيلياً حقيقياً.
AS51464 نشط وصغير ومقتصر على IPv4 في اللقطة الحالية
يعطي RIPEstat إشارة أقوى من موقع الويب لأنه يظهر حالة التوجيه المرصودة. أظهرنظرة عامة على AS لـ AS51464أن الحامل هوIBANK2RU MITIGATOR CLOUD LLCووضع علامة على AS كمعلن عنه في 12 يوليو 2026. أظهرعرض حالة التوجيهأول مشاهدة في أغسطس 2010، ورؤية حالية في 12 يوليو 2026، ورؤية كاملة لـ IPv4 عبر عينات أقران RIS في RIPE، ولا رؤية IPv6، وست بادئات IPv4 معلنة، و2,304 عنوان IPv4، وثلاثة عشر جاراً مرصوداً.
سردعرض البادئات المعلنة لـ AS51464الإعلانات الحالية بما في ذلك 109.232.248.0/21 و109.232.252.0/24 و109.232.253.0/24 و109.232.254.0/24 و109.232.255.0/24 و185.6.47.0/24. القائمة الدقيقة يمكن أن تتغير، ولا ينبغي التعامل مع اللقطة كمخزون دائم. يكفي لإثبات أن AS51464 ليس تسمية خاملة. كان مرئياً في BGP في الوقت الذي تم فحصه.
يضيفعرض اتساق توجيه AS لـ AS51464فارقاً دقيقاً مفيداً. أظهر عدة بادئات كانت موجودة في كل من BGP وبيانات سجل توجيه RIPE، بما في ذلك 109.232.248.0/21 و109.232.252.0/24 و109.232.253.0/24. أظهر أيضاً علاقات سياسة حيث كان بعض الأقران موجودين في كل من BGP وعروض whois بينما كان آخرون مرئيين فقط في عرض واحد. على سبيل المثال، ظهر AS43048 في كل من BGP وwhois للاستيراد والتصدير، بينما كان العديد من الأقران المرصودين في BGP دون سياسة whois مطابقة في ذلك الإخراج. هذا لا يجعل التوجيه خاطئاً. يعني ذلك أن العملاء يجب أن يتحققوا من كائنات المسار الدقيقة والمرشحات وقبول الوصلة الصاعدة للبادئات التي سيستخدمونها.
RPKI ليس قوة مرئية في بيانات AS51464 التي تم أخذ عينات منها. أرجعتدعوة التحقق من RPKI من RIPEstat لـ AS51464 و109.232.248.0/21قيمةغير معروف، مع عدم وجود ROAs مصادقة. الفحص المماثل لـ 185.6.44.0/22 أعاد أيضاً غير معروف. غير معروف ليس غير صالح. يعني ببساطة أن تفويض أصل المسار لم يكن مرئياً لتلك المجموعات التي تم أخذ عينات منها في إخراج المدقق. العميل الذي يعتمد وقت تشغيله على تصفية الوصلة الصاعدة يجب أن يسأل ما إذا كانت بادئة الخدمة الدقيقة لها ROA صالح، وما هي كائنات المسار الموجودة، وما هي الوصلات الصاعدة التي تقبلها، وماذا يحدث إذا تغيرت سياسة أصل المسار أثناء الهجوم.
المعنى التشغيلي لـ AS51464 محدود إذاً. إنه نشط وصغير ومقتصر على IPv4 في القياسات الحالية ومرتبط بقوة باسم iBank2.RU. يمكن أن يدعم اعتماديات الخدمة المحمية، لكنه لا يثبت بحد ذاته الحجم أو تخطيط الغرفة أو السعة الاحتياطية خلف الخدمة.
AS43048 هو سطح الحماية الأوسع
يبدو AS43048 أقرب إلى سطح التوجيه الحالي لسحابة الحماية. أظهرنظرة عامة على AS من RIPEstat لـ AS43048أن الحامل هوmitigator-cloud MITIGATOR CLOUD LLCووضع علامة على AS كمعلن عنه في 12 يوليو 2026. أظهرعرض حالة التوجيهأول مشاهدة في يوليو 2007، ورؤية حالية في يوليو 2026، وسبع بادئات IPv4، و2,304 عنوان IPv4، وبادئة IPv6 واحدة، و65,536 IPv6 /48، وثلاثة وأربعين جاراً مرصوداً. إدخال IPv6 كبير لأن البادئة المرصودة هي /32، وليس لأن كل /48 يستخدم بالضرورة من قبل العملاء.
أظهرعرض البادئات المعلنة لـ AS43048إعلانات تشمل 185.6.44.0/22 و91.209.119.0/24 و109.232.248.0/22 وعدة مسارات 109.232.248.0/24 حتى 109.232.251.0/24 و2a02:4f40::/32. يصف كائن المسار62a02:4f40::/32بأنه IBANK2.RU مع الأصل AS43048. أرجعتدعوة التحقق من RPKI لـ AS43048 و2a02:4f40::/32أيضاً غير معروف مع عدم وجود ROAs مصادقة.
لدى AS43048 كائن سياسة أغنى من AS51464. يسرد سجل RIPE aut-num علاقات العبور أو السياسة مع AS9002 وAS202984 وAS8732 وAS8631، بالإضافة إلى عدة ASNs يقبل بها AS43048 ويعلن عن أي مسارات بالعودة. يُظهر عرض اتساق التوجيه من RIPEstat وجود AS9002 وAS202984 وAS8732 وAS207104 وAS52016 وAS206955 وAS51464 في كل من BGP وwhois لصفوف الاستيراد/التصدير، بينما يُظهر أيضاً جيران BGP مرصودين غير موجودين في إخراج سياسة whois. مرة أخرى، هذا ليس مشكلة تلقائياً. إنه سبب لنسأل أي العلاقات هي عبور إنتاجي، وأيها عملاء، وأيها خاصة، وأيها تحمل حركة مرور التنظيف أثناء الهجوم.
PeeringDB أرق بكثير. يُعيداستعلام شبكة PeeringDB لـ AS43048شبكة مسماة MITIGATOR CLOUD LLC، تم إنشاؤها في يونيو 2025 وتم تحديثها بعد ذلك بوقت قصير، لكنها لا تعطي مستوى حركة مرور معلناً، ولا سياسة نظير عامة، ولا موقع ويب عام، ولا أعداد IX أو منشآت في الحقول التي تم إرجاعها.إدخال مؤسسة PeeringDBمشابه في ندرته. تُعيد عروض APInetixlanوnetfacلشبكة PeeringDB تلك قوائم فارغة.
يجب قراءة فجوة PeeringDB هذه بعناية. العديد من الشبكات الحقيقية لا تحتفظ ببيانات كاملة لمنشآت PeeringDB. الصفوف الفارغة لـ IX أو المنشأة لا تثبت أن Mitigator Cloud تفتقر إلى منافذ التبادل أو الرفوف أو مواقع الناقل. لكنها تعني أن القارئ العام لا يمكنه استخدام PeeringDB للتحقق من مكان وجود الخدمة، أو ما إذا كانت هناك مواقع مستقلة، أو أي المنشآت تستضيف أجهزة التوجيه، أو كم عدد الأماكن التي يمكنها تنظيف حركة المرور في وقت واحد. بالنسبة للمشتري، يحول السجل العام العبء إلى أدلة العقد والمخططات واختبارات المسار وإجراءات الحوادث.
سعة الاستضافة هنا هي سعة تنظيف
يطلق التكليف على هذا ملف سعة استضافة، لكن الأدلة العامة تشير إلى نوع متخصص من سعة الاستضافة: سعة تنظيف DDoS وتسليم الخدمة المحمية. تلك السعة لا تزال مادية. يجب أن تدخل الحزم إلى منفذ شبكة. يجب أن تفحصها أجهزة التنظيف أو الخوادم. يجب أن تغادر حركة المرور المشروعة عبر منفذ آخر أو نفق أو وكيل. يجب على DNS وBGP إرسال حركة المرور إلى المكان الصحيح في الوقت الصحيح. يجب على المهندسين تمييز حركة مرور الهجوم عن حركة مرور العملاء دون التسبب في انقطاع ثانٍ.
تشرحوثائق نشر Mitigatorلماذا هذا ليس مجرد منتج وكيل موقع ويب بسيط. تصف عمليات نشر متناظرة وغير متناظرة، ودفاع دائم وعند الطلب، ونماذج اتصال مادية في الخط، وعلى عصا، وشبكة LAN مشتركة، وأوضاع شفاف L2 وموجه L3، وتوسع أفقي عبر LACP أو ECMP، وVRRP، ونفق GRE، وأمثلة على إعلانات BGP. وتذكر أيضاً أن الحماية الدائمة تقوم بتصفية الهجمات بمجرد ظهورها ولكنها يمكن أن تؤثر على أمثلية المسار والحمل، بينما تقلل الحماية عند الطلب الحمل الخلفي العادي ولكنها تزيد الفترة الزمنية قبل وصول حركة المرور إلى الحماية وقد تعيد تعيين الجلسات القائمة.
هذا مصدر عملي بشكل ملحوظ لمخاطر العميل. إذا استخدم عميل محمي الوضع الدائم، تصبح سعة Mitigator جزءاً من المسار الطبيعي حتى في الأيام الهادئة. كل نافذة صيانة، وتغيير إجراء مضاد، وتغيير مسار، وحدود معالج حزم يمكن أن تؤثر على المستخدمين الحقيقيين. إذا استخدم العميل الوضع عند الطلب، قد يكون المسار الطبيعي أنظف حتى يبدأ الهجوم، لكن العميل يعتمد بعد ذلك على عتبات الكشف والإشارات وانتشار التوجيه وعودة حركة المرور النظيفة تحت الضغط. في كلا النموذجين، الخدمة فقط بقدر مرونة المسار المادي والتوجيهي خلفها.
وثائق إشارات BGPذات صلة مماثلة. تصف MITIGATOR باستخدام BGP للإشارة إلى مشغلي الاتصالات الصاعدة أو مزودي الأمن المُدارين، مع إضافة البادئات إلى قائمة الإشارات عند تجاوز عتبات الكشف التلقائي. تحذر من أنه إذا لم يتم تكوين خدمة التنظيف الخارجية لمواصلة التنظيف أثناء ملاحظة حركة مرور عالية، فإن انخفاض المعدل بعد بدء التنظيف يمكن أن يتسبب في إزالة البادئات وتوقف التنظيف، مما يخلق خطر التذبذب. بالنسبة للعميل، هذا يعني أن خدمة التنظيف ليست ببساطة "تشغيل" أو "إيقاف". إنها آلة حالة تشمل العتبات والإعلانات وتكوين الجيران والمجتمعات والقفزات التالية وسلوك الوصلة الصاعدة والتوقيت.
تشرحصفحة الأسعارقيد سعة خفي آخر: تراخيص MITIGATOR تحد من معدل حركة المرور الداخلة إلى النظام، مع احتساب كل من حركة مرور الهجوم وحركة المرور المشروعة. تقول الصفحة أن الحد الأدنى لعرض النطاق الترددي المرخص المتاح للشراء هو 100 ميجابت في الثانية، مع حد أدنى لخطوة التعيين قدره 50 ميجابت في الثانية لجهاز، وأن التسعير يحسب عند الطلب. العميل الذي يشتري خدمة حماية سحابية قد لا يرى أبداً مقابض الترخيص هذه، لكن الاقتصاديات لا تزال سارية. حركة مرور الهجوم تستهلك السعة. حركة المرور المشروعة تستهلك السعة. التجهيز الزائد يكلف مالاً. التجهيز الناقص يحول الهجوم إلى حركة مرور مشروعة مسقطة.
لهذا السبب لا يمكن تحويل بصمة التوجيه العامة مباشرة إلى سعة العميل. تُظهر AS51464 وAS43048 شبكات حية. لا تظهر مقدار إنتاجية المنظف المثبتة وكم منها مرخص وكم محجوز وكم تم بيعه بالفعل وكم متاح في مدينة محددة أو مدى سرعة زيادة السعة. بالنسبة لبنك أو شركة تكنولوجيا معلومات أو مزود خدمة، السؤال التجاري الرئيسي ليس فقط "هل يعلن AS عن مسارات؟" بل "ما حجم الهجوم ومستوى حركة المرور العادي المشمول تعاقدياً، وأين، وعبر أي مسار عودة؟"
قصة الرفوف والمنشآت لا تزال غير مسجلة إلى حد كبير
غموض المنشأة هو أكبر ضعف عام. يعطي RIPE عنواناً قانونياً واتصالاً في موسكو. يعطي كائن المسار نفس عنوان موسكو. تعطي الخدمة السحابية رقم هاتف روسي وعنوان بريد إلكتروني. تلك التفاصيل ترسخ الكيان في روسيا، لكنها لا تحدد قاعات البيانات أو مزودي الاستضافة المشتركة أو بصمات الرفوف أو طوبولوجيا الطاقة أو غرف لقاء الناقل أو ترتيبات الأيدي عن بعد أو مخزون قطع الغيار المستخدمة من قبل خدمة التنظيف.
PeeringDB لا يسد الفجوة. AS43048 لديه إدخال، لكن قوائم IX والمنشآت العامة فارغة. لم يُرجع AS51464 إدخال شبكة PeeringDB قابلاً للاستخدام في الاستعلام المستخدم لهذه المراجعة. مرة أخرى، هذا ليس دليلاً على عدم وجود بنية تحتية. إنه دليل على أن الدليل العام الذي يستخدمه معظم المشغلين للإفصاح عن المنشآت والتبادل لا يجيب حالياً على الأسئلة العملية للمشتري.
بالنسبة لمزود تخفيف DDoS، سؤال المنشأة أشد خطورة مما هو عليه بالنسبة للاستضافة العادية. يمكن للخدمة المستضافة العادية أحياناً تحمل نافذة صيانة قصيرة إذا كان لديها نسخ احتياطي وتواصل مع العملاء. خدمة التنظيف غالباً ما تكون مطلوبة في اللحظة التي تكون فيها السعة والموظفون تحت أقصى ضغط. إذا تم تحويل حركة المرور عبر BGP أو DNS، تصبح عقد التنظيف وأجهزة التوجيه الحدودية وروابط عودة حركة المرور النظيفة جزءاً من مسار الإنتاج للعميل. إذا فقدت تلك العقد الطاقة، أو فشل مفتاح أعلى الرف، أو تشبع بطاقة خط موجه، أو تعطلت نقطة نهاية نفق، أو منع تأخير الوصول إلى المنشأة الاستبدال، فقد يكون العميل المحمي في وضع أسوأ مما كان عليه قبل التحويل.
لذلك يجب على العملاء طلب أدلة خاصة بالموقع. أين توجد عقد التنظيف المستخدمة لهذا العقد؟ هل هناك موقعان مستقلان فيزيائياً للتنظيف أم فقط خيارا توجيه في مجال عطل واحد؟ أي الناقلين يدخل كل موقع؟ هل يتم إنهاء أنفاق العودة في نفس غرفة عقد التنظيف؟ أي المكونات لها قطع غيار محلية؟ أي الأنشطة تتطلب أيدي عن بعد في المنشأة؟ ماذا يحدث إذا كان العميل تحت هجوم أثناء نافذة الصيانة الخاصة بالمزود؟
لا يمكن للسجل العام الإجابة على تلك الأسئلة. يمكنه فقط تبرير طرحها. يشير مزيج الـ ASNs الحية وادعاءات الشركة والإفصاح المتناثر عن المنشآت إلى خدمة حقيقية مع فجوة تحقق عام. تلك الفجوة يمكن إدارتها لمشترٍ متطور، ولكن فقط إذا تعامل المشتري مع استقلالية المنشأة كدليل يجب الحصول عليه، وليس وعداً يجب افتراضه.
سياسة العبور والتوجيه هي اعتماديات مواجهة للعميل
تشير سياسة التوجيه العامة إلى تنوع مفيد، لكنها لا تثبت بذاتها المرونة. يسرد AS43048 عدة علاقات وصلة صاعدة ونظير في RIPE، ويرصد RIPEstat ثلاثة وأربعين جاراً. يرصد AS51464 ثلاثة عشر جاراً. تُظهر مخرجات اتساق التوجيه علاقات حية موثقة وغير موثقة. تتضمن مجموعة AS مجموعة أوسع من ASNs. كل هذا يقول أن Mitigator Cloud لديها سطح توجيه ذو معنى.
لا يقول أن كل خدمة عميل يمكنها النجاة من كل فشل في الوصلة الصاعدة. يعتمد تخفيف DDoS على مكان دخول حركة المرور المعادية، والمسارات التي تفضلها الشبكات البعيدة، ومدى سرعة انتشار تغييرات BGP، وما إذا كانت حركة مرور العودة تتبع مساراً قابلاً للتطبيق. العميل الذي يستخدم إعلان BGP دائم عبر Mitigator Cloud يحتاج إلى معرفة أي الوصلات الصاعدة تحمل البادئة في التشغيل العادي وما إذا كان أي مزود واحد أو اختيار مسار محلي يخلق نقطة اختناق. العميل الذي يستخدم إعلان BGP أثناء الهجوم يحتاج إلى معرفة مدى سرعة تقارب الشبكات البعيدة، وما إذا كانت المسارات الأكثر تحديداً مقبولة، وما إذا كانت الوصلات الصاعدة للعميل ستسمح بإجراء التوجيه.
حالة RPKI غير المعروفة للبادئات التي تم أخذ عينات منها هي أيضاً عنصر عناية واجبة حقيقي. غير معروف ليس فشلاً، والعديد من الشبكات لا تزال تعمل بحالة غير معروفة. لكن التحقق من أصل المسار يؤثر بشكل متزايد على قرارات التصفية واستكشاف الأخطاء وإصلاحها وثقة الحوادث. العميل الذي يريد بادئة محمية بواسطة Mitigator Cloud يجب أن يتحقق من AS الأصل الدقيق وكائن المسار وحالة ROA وخطة تصفية الوصلة الصاعدة قبل أول هجوم. يجب أيضاً اختبار سحب المسار واستعادته خلال فترة هادئة. الاختبار أثناء الهجوم هو طريقة سيئة لتعلم كيف يتصرف المسار.
التمييز في وثائق المنتج بين الوضعين الدائم وعند الطلب يجعل هذا أكثر أهمية. قد يعطي الوضع الدائم تصفية أسرع لكنه يمكن أن يجعل Mitigator Cloud جزءاً من زمن الوصول الثابت والتعرض للفشل. قد يحافظ الوضع عند الطلب على المسار الطبيعي لكنه يعتمد على سرعة الكشف والإشارات وتغيير التوجيه. لا يوجد نموذج أفضل عالمياً. الإجابة الصحيحة تعتمد على الخدمة المحمية وتحمل زمن الوصول ومهارة شبكة العميل وملف الهجوم ومعالجة TLS وتكلفة الجلسات المسقطة.
اختبار عملي واحد للمشتري هو إمكانية التتبع على مستوى البادئة. اطلب من Mitigator Cloud تحديد مسار AS الدقيق المتوقع قبل وأثناء وبعد الهجوم. اسأل أي المجتمعات أو القفزات التالية مستخدمة. اسأل ما إذا كانت حركة المرور النظيفة تعود عبر نفق L2 أو GRE أو وكيل عكسي TCP أو وكيل عكسي HTTP/HTTPS. اسأل ما إذا كانت حركة مرور الخروج للعميل متناظرة أم غير متناظرة. اسأل ما هي السجلات التي تثبت أن حدث توجيه وقع. إذا بقيت الإجابة على مستوى العلامة التجارية، فإن العميل لم يحدد بعد الاعتماد التشغيلي.
الدعم جزء من المنتج، وليس ملحقاً
تعد صفحة Mitigator Cloud بالمراقبة على مدار الساعة طوال أيام الأسبوع والإشعارات. تصف صفحة خدمات المنتج دعم التنفيذ وخبرة البائع والتدريب وتيارات العملاء المغلقة والمساعدة الخبيرة أثناء الهجمات. هذه ادعاءات ذات مغزى لأن حماية DDoS هي بنية تحتية مدعومة بالبشر. الكشف التلقائي والإجراءات المضادة قيّمة، لكن بقاء العميل غالباً ما يعتمد على من يمكنه تفويض الخطوة التالية.
أثناء حادث حقيقي، قد تحتاج العديد من الفرق إلى التصرف: فريق تطبيق العميل، مشغل DNS الخاص بالعميل، فريق شبكة العميل، فريق دعم Mitigator Cloud، مزودو الوصلة الصاعدة، الأيدي عن بعد في المنشأة، وربما بائع البرنامج. إذا استخدم العميل وكيل عكسي، قد يلمس الدعم أيضاً TLS والرؤوس واستعادة IP المصدر وسلوك يشبه WAF ومشاركة السجلات. إذا استخدم العميل BGP، قد يلمس الدعم إعلانات البادئات والمجتمعات ومرشحات المسار ونقاط نهاية النفق. إذا استخدم العميل دفق سجلات HTTP، قد يحتاج الدعم إلى أن يرسل الخادم المحمي قياسات مفيدة أثناء الضغط.
لا تظهر الأدلة العامة إحصائيات تاريخ الحوادث أو سجلات استجابة الدعم أو شروط رصيد الخدمة أو مخططات التصعيد. هذا طبيعي؛ العديد من المزودين يبقون تلك خاصة. يعني ذلك أن العملاء يجب أن يسألوا صراحة. من يمكنه تغيير سياسة الحماية خارج ساعات العمل؟ من يمكنه الإعلان عن بادئة أو سحبها؟ من يمكنه إضافة إجراء مضاد طارئ؟ من يمكنه استبدال خادم فاشل أو محول شبكة؟ من يمكنه الموافقة على تغيير نفق؟ من يمكنه التراجع عن تحديث؟ من يمكنه التحدث إلى مزود الوصلة الصاعدة للعميل؟ يجب أن يكون لدى الشخص الذي يجيب على هاتف الدعم مسار إلى شخص ذي سلطة.
تعزز الوثائق هذا لأن النظام نفسه له حالة. بيانات الكتلة وبيانات المثيل والمقاييس والسياسات والعتبات وجيران BGP وإعدادات النفق وحالة الإصدار كلها مهمة. فريق دعم يفهم فقط واجهة الويب قد لا يكون كافياً أثناء انقطاع شديد. فريق دعم بسلطة شبكية عميقة ولكن لا وصول له إلى سياق تطبيق العميل قد يكون محدوداً أيضاً. يجب أن يعرف العميل أين يقع الحد قبل أن تصبح الخدمة حية.
التحديثات والنسخ الاحتياطي وتصميم الكتلة يخلقان نوافذ إصلاح
وثائق المنتج مفيدة بشكل غير معتاد فيما يتعلق بنوافذ الإصلاح لأنها تصف التكلفة التشغيلية لتشغيل التكنولوجيا. تقولصفحة وضع الكتلةأن قواعد البيانات المشتركة لجميع مثيلات MITIGATOR مخزنة فيزيائياً على خادم واحد في تصميم المثيل الأساسي، وأن المثيلات الأخرى تصل إلى قاعدة بيانات المثيل الأساسي. إذا تم تجميع كتلة من مثيلات مستقلة سابقاً، تحذر الصفحة من أن السياسات الحالية وبيانات الحوادث والرسوم البيانية والمعلومات المخزنة الأخرى على المثيلات غير القائدة يتم حذفها ما لم يتم حفظها أولاً. هذا ليس فشلاً في خدمة العملاء؛ إنها حقيقة إدارة نظم عادية يجب التخطيط لها.
تصفصفحة التخزين الداخلي المتسامح مع الأخطاءنموذجاً أقوى حيث يتم تخزين نسخ قاعدة بيانات متزامنة فيزيائياً على خوادم مختلفة. تصف أيضاً النسخ المتماثل المتدفق وpgfailover وترقية الاستعداد عندما يكون الأساسي غير متاح والحاجة إلى اتصال موثوق بين العقد وسلوك الانقسام الدماغي إذا قسمت الاتصالات الكتلة. تحذر الصفحة صراحةً من عدم استخدام أسماء النطاقات لأن الاتصال سينقطع في حالة فشل DNS. بالنسبة للعملاء، تلك التفاصيل الواحدة ذهب: وثائق البائع نفسها تعترف بأن الأسماء ووصول العقد وحالة التخزين يمكن أن تصبح جزءاً من نمط الفشل.
تقولصفحة النسخ الاحتياطيأن النسخ الاحتياطي ممكن فقط لنفس إصدار MITIGATOR الذي تم به النسخ الاحتياطي. تميز بين بيانات الكتلة وبيانات المثيل والمقاييس، وتصف أشكال النسخ الاحتياطي الكامل والخفيف. تقول أيضاً أن الاسترداد يتطلب حذف حجم PostgreSQL الحالي واستعادة البيانات، وأن الدعم قد يحتاج إلى سجلات الاستعادة إذا ظهرت أخطاء. هذه هندسة عادية. تعني أيضاً أنه لا ينبغي للعميل أن يسأل فقط "هل لديك نسخ احتياطي؟" السؤال الأفضل هو "متى تم اختبار آخر استعادة على الإصدار الذي يدير الخدمة التي أستخدمها؟"
تسردصفحة الإصداراتحالات الإصدار الحالية والمدعومة وغير المدعومة. تقولصفحة تحديث v26.04أن التحديثات إلى v26.04 تتطلب نواة لينكس 5.0 أو أعلى لوظائف MITIGATOR الكاملة، ويجب تنفيذها من إصدار ثانوي v25.12.5 أو أحدث، وتتطلب نسخاً احتياطياً كاملاً لأن إصدار PostgreSQL يتغير ويجب استعادة قاعدة البيانات. هذه هي حقيقة نافذة الصيانة خلف خدمة الحماية. حتى لو لم ير العميل أبداً شاشة إدارة المنتج، فإن قدرة المزود على صيانة ونسخ احتياطي واستعادة منصة الحماية الخاصة به تؤثر على وقت تشغيل العميل.
يجب على العملاء أن يسألوا كيف تتعامل Mitigator Cloud مع هذه النوافذ في خدمتها المستضافة. هل سياسات العملاء مخزنة في ترتيب متسامح مع الأخطاء متعدد العقد؟ هل يتم الاحتفاظ بالمقاييس وسجلات الحوادث بعد الاستعادة؟ هل يتم التحديث موقعاً تلو الآخر؟ هل يتم تصريف تسليم حركة المرور النظيفة قبل الصيانة؟ هل يتم سحب إعلانات المسار أو الإبقاء عليها؟ هل يتم إخطار العملاء عندما تتم ترقية منصة الحماية نفسها؟ تشرح الوثائق العامة قيود تشغيل التكنولوجيا. لا تثبت كيف تطبق الخدمة السحابية تلك القيود.
موقع البيانات روسي، لكن معالجة البيانات مسألة منفصلة
منطقة التكليف هي RU، والأدلة العامة تدعم روسيا كسياق تشغيلي. يسرد RIPE شركة MITIGATOR CLOUD LLC في موسكو. تصف صفحة السحابة خدمة روسية وتسمي شهادات تنظيمية روسية. رقم الهاتف روسي. تم تأطير الخدمة حول العملاء من الشركات الروسية والبنوك وشركات تكنولوجيا المعلومات ومقدمي الخدمات. AS51464 وAS43048 هما موارد أرقام في منطقة RIPE مرتبطة بالمؤسسة الروسية.
يدعم هذا أطروحة موقع روسي، لكنه لا يجيب على كل سؤال حول معالجة البيانات. يمكن لتخفيف DDoS كشف مواد تشغيلية حساسة حتى عندما لا يستضيف قاعدة بيانات تطبيق العميل. قد ترى حماية الوكيل العكسي بيانات وصفية HTTP وربما حركة مرور مفكوكة التشفير، حسب النموذج. يمكن أن تتضمن حماية HTTPS عدم فك تشفير أو نقل شهادة/مفتاح أو دفق سجل، وفقاً لصفحة Mitigator Cloud. قد تكشف الحماية القائمة على BGP قوائم البادئات وقياسات حركة المرور وتوقيعات الهجوم وتصميم شبكة العميل. قد تحمل الأنفاق حركة مرور إنتاجية نظيفة إلى العميل.
بالنسبة للعملاء المنظمين أو الحساسين، السؤال ليس ببساطة "هل المزود روسي؟" بل أين يتم فحص حركة المرور، وأين تخزن السجلات، وما إذا كانت مفاتيح TLS منقولة، ومن يمكنه قراءة التقاطات الحزم، وأين تتم معالجة القياسات وبيانات السمعة، ومدة الاحتفاظ ببيانات الهجوم، وما إذا كانت أي وظيفة دعم أو مراقبة تعبر حدوداً قضائية. تشير صفحة الخدمة العامة إلى خيارات؛ لا تنشر عقداً كاملاً لمعالجة البيانات.
لذلك من الأفضل فهم سيادة البيانات كموضوع عناية واجبة بدلاً من فائدة تلقائية. قد يفضل بنك روسي أو مزود خدمة خدمة DDoS روسية لأسباب تتعلق بالمشتريات أو زمن الوصول أو لغة الدعم أو التنظيم. هذا التفضيل لا يلغي الحاجة إلى توثيق أين تتدفق حركة المرور النظيفة، ومن لديه وصول تشغيلي، وكيف يتم الاحتفاظ بالأدلة بعد الحادث.
من يتأثر عندما تفشل هذه السعة
يتبع السكان المتأثرون قائمة العملاء في صفحة Mitigator Cloud: العملاء من الشركات والبنوك وشركات تكنولوجيا المعلومات ومقدمو الخدمات. بالنسبة للبنك، قد يعني الفشل أن صفحة تسجيل دخول العميل أو واجهة الخدمات المصرفية عبر الإنترنت أو خدمة مجاورة للدفع أو موقع ويب عام يصبح بطيئاً أو غير قابل للوصول أثناء الهجوم. بالنسبة لشركة تكنولوجيا معلومات، قد يعني الفشل فقدان قابلية الوصول لنقاط نهاية SaaS أو بوابات العملاء أو واجهات برمجة التطبيقات أو لوحات المعلومات. بالنسبة لمزود الخدمة، قد يتسلسل الفشل إلى العملاء النهائيين الذين يعتقدون أنهم اشتروا الحماية من مزودهم الخاص، وليس من Mitigator Cloud مباشرة.
تعتمد آلية التأثير على نموذج الخدمة. إذا تم استخدام تبديل سجل A، يمكن أن يبقي تأخير DNS وذاكرة التخزين المؤقت للمحلل القديمة بعض المستخدمين على المسار غير المحمي بينما ينتقل آخرون عبر Mitigator Cloud. إذا تم استخدام إعلان BGP دائم، فإن Mitigator Cloud تكون دائماً في مسار البيانات، لذا يمكن أن تؤثر الانقطاعات من جانب المزود على حركة المرور العادية. إذا تم استخدام BGP أثناء الهجوم، يصبح وقت تقارب التوجيه وقبول المرشح واستقرار الإعلان جزءاً من الحادث. إذا تم إرجاع حركة المرور النظيفة عبر نفق L2 أو وكيل عكسي TCP أو وكيل عكسي HTTP/HTTPS، يمكن أن يفشل مسار العودة بشكل مستقل عن مسار التنظيف الوارد.
يمكن أن تكون النتائج الإيجابية الخاطئة ضارة مثل الهجمات المفقودة. الإجراء المضاد الذي يحجب العملاء المعاديين ولكنه يحجب أيضاً شبكات الهاتف المحمول المشروعة أو NATs المؤسسية أو ردود الدفع أو عملاء API يمكن أن يحول الحماية إلى توقف ذاتي. تؤكد صفحات المنتج على أنواع إجراءات مضادة عديدة وضوابط على مستوى السياسة. هذه المرونة قيّمة فقط إذا كان المزود والعميل يمكنهما ضبطها بالسرعة الكافية والتحقق من حركة المرور المشروعة أثناء الحادث.
نفس الشيء صحيح لنضوب السعة. ترخيص أو منفذ مادي مصمم لحركة المرور العادية بالإضافة إلى هجمات معتدلة يمكن أن تطغى عليه هجمات أكبر. لأن صفحة الأسعار تقول أن حركة المرور الواردة تشمل كلاً من حركة مرور الهجوم والمشروعة لأغراض الترخيص، فإن الضغط الاقتصادي مرئي حتى لو لم ير العميل الأرقام الداخلية للمزود. يجب أن يعرف العميل ما إذا كانت الخدمة المحمية لديها عرض نطاق نظيف ملتزم وسياسة اندفاع ومسار ترقية طارئ وسلوك واضح عندما تتجاوز حركة المرور المستوى المتفق عليه.
ما يجب على العميل التحقق منه قبل الاعتماد على الخدمة
التحقق الأول هو الهوية والنطاق. يجب على العميل تأكيد ما إذا كانت خدمته ستنفذ على AS51464 أو AS43048 أو AS عميل أو بادئات Mitigator Cloud. يجب تأكيد البادئات الدقيقة وكائنات المسار وحالة ROA والوصلات الصاعدة والمجتمعات ومسارات AS العادية. لا ينبغي قبول اسم مجموعة AS كدليل كافٍ على مسار الإنتاج.
التحقق الثاني هو وضع توجيه حركة المرور. يجب أن يعرف العميل ما إذا كانت الحماية دائمة أو عند الطلب، وما إذا كان DNS أو BGP أو بادئات المزود مستخدمة، ومن لديه السلطة لتفعيل كل طريقة. إذا تم استخدام الحماية عند الطلب، يجب على العميل إجراء تمرين توجيه أو DNS خاضع قبل ظهور خطر الإنتاج. إذا تم استخدام الحماية الدائمة، يجب على العميل وضع خط أساس لزمن الوصول ومجالات الفشل وسلوك الصيانة أثناء حركة المرور العادية.
التحقق الثالث هو استقلالية الموقع. يجب على العميل أن يسأل كم عدد مواقع التنظيف المستقلة في الخدمة المحددة، وأين تقع على مستوى مدينة أو فئة منشأة، وما إذا كانت تشترك في أجهزة توجيه الوصلة الصاعدة أو التخزين أو الطاقة أو DNS أو خدمات التحكم أو فرق الدعم، وأي جزء من الخدمة لا يزال يعتمد على غرفة واحدة. لا تجيب بيانات PeeringDB العامة على هذا.
التحقق الرابع هو عودة حركة المرور النظيفة. بالنسبة للأنفاق، اسأل كيف تتم حماية نقاط النهاية ومراقبتها، وكيف يتم تدوير المفاتيح، وما هو عرض النطاق الملزم، وماذا يحدث عندما يتعطل النفق. بالنسبة للوكيل العكسي، اسأل كيف يتم الحفاظ على عناوين IP المصدر، وكيف تتم معالجة TLS، وما هي السجلات التي يتم جمعها، وما هي التغييرات المطلوبة من العميل. بالنسبة لحماية HTTP/HTTPS بدون فك تشفير، اسأل أي طرق الكشف تظل فعالة وأي فئات هجوم تتطلب سجلات أو مواد مفتاحية.
التحقق الخامس هو الصيانة والاستعادة. اسأل متى يتم أخذ النسخ الاحتياطية للمنصة، وما إذا تم اختبار الاستعادة على الإصدار الجاري، وكيف يتم ترتيب التحديثات، وما إذا كانت إعلانات المسار تتغير أثناء الصيانة، وكيف تتم حماية حالة سياسة العميل، وما هي سجلات الحوادث التي تبقى بعد الاستعادة. تظهر وثائق MITIGATOR تفاصيل الإصدار والتخزين والنسخ الاحتياطي مهمة؛ يجب أن يترجم عقد الخدمة المستضافة تلك التفاصيل إلى التزامات مواجهة للعميل.
التحقق السادس هو سلطة الدعم. تأكد من المسار على مدار الساعة من إنذار العميل إلى إجراء المهندس. اسأل من يمكنه إضافة إجراء مضاد، أو تغيير إعلان BGP، أو تحديث نفق، أو فحص سجلات، أو التحدث إلى الوصلات الصاعدة، أو التراجع عن تغيير برمجي، أو الموافقة على زيادة سعة طارئة. تخفيف DDoS ليس فقط منتجاً لمعالجة الحزم. إنها خدمة قرار تحت ضغط الوقت.
درجة الأدلة والخلاصة
درجة الأدلة متوسطة. أدلة الهوية قوية: سجلات مؤسسة RIPE والمشرف والدور وaut-num ومسار ومسار6 وRDAP تربط باستمرار بين iBank2.RU وMITIGATOR CLOUD LLC وAS51464 وAS43048. أدلة الشبكة قوية بما يكفي لإظهار التوجيه الحالي: يضع RIPEstat علامة على كلا ASNين كمعلن عنهما في 12 يوليو 2026، مع ظهور AS51464 كشبكة أصغر مقتصرة على IPv4 وظهور AS43048 كشبكة حماية أوسع مع IPv4 وIPv6 والمزيد من الجيران المرصودين.
أدلة الخدمة ذات مغزى أيضاً. تصف Mitigator Cloud علناً حماية روسية على مدار الساعة طوال أيام الأسبوع من DDoS للعملاء من الشركات والبنوك وشركات تكنولوجيا المعلومات ومقدمي الخدمات، مع خيارات ملموسة لتوجيه حركة المرور وتسليم حركة المرور النظيفة. تشرح وثائق منتج MITIGATOR الآليات وراء تلك الادعاءات: إشارات BGP وأوضاع الدائمة وعند الطلب والأنفاق والكتل والتخزين المتسامح مع الأخطاء والنسخ الاحتياطية ودعم الإصدارات ومتطلبات التحديث.
الجزء الضعيف هو التحقق المادي والتشغيلي. لا تحدد المصادر العامة المنشآت والرفوف والسعة الاحتياطية وإنتاجية المنظف المثبتة وتخصيص الترخيص واختبارات الاستعادة وتاريخ الحوادث ومخطط تصعيد الدعم أو شروط قابلية نقل العملاء. PeeringDB متناثر بدلاً من أن يكون مطمئناً. حالة RPKI للبادئات التي تم أخذ عينات منها غير معروفة. يدعم السجل العام اعتماداً حقيقياً، لكنه لا يدعم ادعاء مرونة مدقق بالكامل.
بالنسبة للعملاء، الاستنتاج العملي بسيط. تعامل مع IBANK2RU MITIGATOR CLOUD LLC كمزود سعة حية لخدمات محمية روسية يعتمد وعده السحابي على أجهزة التوجيه وعقد التنظيف والترانزيت والدعم ونوافذ الإصلاح. اشترِ الخدمة فقط بعد التحقق من المسار الدقيق والغرفة والنفق والنسخ الاحتياطي والدعم والتزامات السعة للحمل الذي سيعتمد عليها.