الملخص

  • من 29 مارس حتى 7 أبريل 2014، أظهرت أدلة Google وRIPE Atlas أن حركة البيانات الموجهة إلى مُحلِّلات DNS العامة قد تصل إلى أنظمة إجابة داخل الشبكات التركية بدلاً من الخدمة الخارجية المتوقعة. وتُثبت الملاحظات حدوث اعتراضٍ عند نقاط قياس محددة، لا وجود إعداد واحد موحّد على مستوى الدولة.
  • تتبع المساءلة الضوابط التي تحدد المسار الفعلي والإجابة: الإعلان عن المسارات وتثبيتها، وإعادة التوجيه، وهوية المُحلِّل، وسلامة استجابة DNS، والقياس المستقل، والاستعادة الموثّقة. ولا تعالج سجلات التسجيل، وDNSSEC، وRPKI، وDNS المشفر سوى جزء من تلك السلسلة.

عنوان مألوف، خدمة غير مألوفة

يبدو تغيير إعدادات الكمبيوتر أو الموجّه لاستخدام مُحلِّل DNS عام تكراري خيارًا مباشرًا. يُدخل المستخدم عنوانًا مثل 8.8.8.8، ويرسل استعلام DNS إلى ذلك العنوان، ويتوقع أن يستقبله مُحلِّل Google العام. في التشغيل العادي، يكون هذا التوقع مفيدًا، لكنه ليس دليلاً على ما فعلته الشبكة بالحزمة. يعبّر العنوان عن الوجهة المقصودة، بينما تحدد حالة التوجيه وإعادة التوجيه النظام الذي يستقبل حركة البيانات فعليًا، وتحدد البرمجيات على ذلك النظام الإجابة المُعادة.

أصبح هذا التمييز مرئيًا تشغيليًا داخل الشبكات التركية بين 29 مارس و7 أبريل 2014. أظهرت القياسات أن حركة البيانات الموجهة إلى عناوين IP الخاصة بمُحلِّلات عامة تصل إلى أنظمة إجابة داخل البنية التحتية التركية بدلاً من الخدمات الخارجية المتوقعة. وقالت Google إنها أكدت تقارير موثوقة بأن خدمة DNS العامة الخاصة بها كانت تتعرض للاعتراض من قِبل معظم مزودي خدمة الإنترنت الأتراك. وقدمت قياسات RIPE Atlas ملاحظات مستقلة: شهدت بعض المجسات في تركيا تغيرات مفاجئة في زمن الاستجابة وتلقت إجابات مرتبطة بالبنية التحتية التركية، بينما لم تُظهر مجسات أخرى السلوك نفسه.

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

لا يبرر السجل العام قصة آلية واحدة بسيطة. وصفت حسابات BGPMon وInternet Society إعلانات BGP عالية التحديد، بما في ذلك إعلان /32 لعنوان مُحلِّل Google. كما ناقشت مواد قُدمت في RIPE 68 التوجيه بوصفه وسيلة الاعتراض. وأضافت إعادة بناء Stéphane Bortzmeyer تقييدًا مهمًا: لم تُظهر نافذة فحص لدى Turk Telekom إعادة التوجيه كمسار BGP عادي بالمسار المرئي المتوقع، مما أوحى بأن جزءًا على الأقل من الأثر قد يكون ناتجًا عن مسار ثابت أو داخلي محلي. لذلك تدعم الملاحظات العامة حدوث اعتراض عند نقاط قياس محددة، لكنها لا تثبت أن اختطاف BGP واحدًا منتشرًا عالميًا، أو إعداد توجيه واحدًا، أو سياسة إجابة واحدة كانت تعمل على مستوى الدولة.

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

الحدث المحدود: من 29 مارس إلى 7 أبريل

يبدأ التسلسل الزمني المعني عندما أظهرت قياسات من شبكات الوصول التركية تغيرًا في معالجة حركة البيانات المرسلة إلى مُحلِّلات عامة تكراري. يمكن تجاوز حجب DNS التقليدي عندما يختار المستخدم مُحلِّلًا خارجيًا بدلاً من المُحلِّل الذي يوفره مزود الوصول. كان تصعيد 2014 موضوع التحليل مختلفًا عن مجرد قيام مزود الوصول بإعادة إجابة مُتلاعب بها من خدمة DNS الخاصة به المعلنة؛ إذ كان يمكن للمستخدمين اختيار عنوان مُحلِّل عام صراحةً ومع ذلك تصل حزمهم إلى نظام إجابة آخر داخل شبكة الوصول.

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

قدمت RIPE Atlas ساعة ثانية تستند إلى القياس لا إلى تأكيد الشركات. كانت المجسات في تركيا تصل سابقًا إلى مُحلِّل Google بأسلوب anycast بنمط زمن استجابة واحد. وخلال الحدث، سجلت بعضها انخفاضًا مفاجئًا إلى أقل من عشرة أجزاء من الثانية. إن مُحلِّلًا يبدو الوصول إليه بهذه السرعة من شبكات الوصول تلك لا يتسق مع المسار السابق إلى نسخة Google المتوقعة، ويتسق مع نظام إجابة أقرب بكثير. كما أعادت اختبارات DNS عنوانًا مرتبطًا بالبنية التحتية لـTurk Telekom لدى بعض المجسات. ولم يُظهر مجسان الأثر نفسه، وهي ملاحظة تمنع التعامل مع المجموعة المقاسة على أنها موحدة.

كانت نهاية الحدث أيضًا لها أكثر من ساعة. لاحظ حساب RIPE أن المُحلِّل الزائف توقف عن إعادة توجيه استعلامات تتعلق بـTwitter قبل أن تختفي خدمة 8.8.8.8 الزائفة نفسها. وعادت أزمنة الاستجابة إلى نمطها السابق مساء 7 أبريل. تفصل هذه الملاحظات ثلاث حالات على الأقل: ظلت حركة البيانات تصل إلى مُحلِّل غير متوقع؛ وتغيرت سياسة المُحلِّل تجاه اسم معين مُستعلَم عنه؛ واستُعيد التوجيه إلى الخدمة العامة المتوقعة. ووصف الحالات الثلاث ببساطة «انتهى الحجب» سيتجاهل أدلة البنية التحتية.

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

ما أكدته Google—وما بقي خارج نطاق رؤيتها

شغّلت Google الخدمة المقصودة، وأعلنت عناوين anycast الخاصة بها، وكانت قادرة على مراقبة حركة البيانات الواصلة إلى مواقع مُحلِّلاتها. وكانت قادرة أيضًا على مقارنة تقارير المستخدمين وقياسات الشبكة بسلوك الخدمة المتوقع. لذلك يُعد بيانها دليلاً قويًا على أن الشركة لم تعتبر أنظمة الإجابة المرصودة في تركيا نسخًا شرعية من خدمة Google Public DNS. وهو أيضًا الأساس المناسب لنسبة الادعاء بأن معظم مزودي خدمة الإنترنت الأتراك كانوا متورطين.

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

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

ما قاسه RIPE Atlas

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

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

كانت بيانات DNS المُعادة إشارة أخرى. أفاد حساب RIPE بأن بعض الاختبارات أعادت إجابات تشير إلى البنية التحتية لـTurk Telekom. ويتعلق هذا الدليل بالبيانات التي يرسلها المُحلِّل المُجيب، ولا يكشف وحده كيف وصل الاستعلام إلى هناك. فمسار سياسة محلي، أو مسار مضيف ثابت، أو بروتوكول توجيه داخلي، أو إعلان BGP أكثر تحديدًا، أو نظام إعادة توجيه حزم ما، يمكن أن يغير جميعًا الخدمة المستقبلة مع ترك آثار مختلفة في سجلات مستوى التحكم. وتساعد الإجابة على تحديد حدوث استبدال الخدمة، لكنها ليست أثر مسار كامل.

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

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

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

سبع حقائق يجب ألا تُختزل في «اختطاف DNS»

عبارة «اختطاف DNS» مريحة، لكنها قد تخفي سلسلة التحكم. وتتضح أدلة 2014 أكثر عند تقسيمها إلى سبع حقائق منفصلة.

أولاًالإعلان عن المسار. في BGP، تعلن الشبكة إمكانية الوصول إلى بادئة IP بسمات منشأ ومسار. وصفت حسابات BGPMon وInternet Society إعلانات عالية التحديد لعناوين DNS عامة، بما في ذلك /32 لعنوان مُحلِّل Google. وهذا دليل على رسالة مستوى التحكم كما نقلها هؤلاء المراقبون، وليس تلقائيًا دليلاً على أن كل شبكة قبلت الإعلان أو أن الإعلان نفسه كان مرئيًا عالميًا.

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

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

رابعًاهوية المُحلِّل. قد يقدم النظام الذي يستقبل حركة UDP أو TCP على المنفذ 53 نفسه كمُحلِّل تكراري ويجيب عن الطلبات، لكن حيازة حركة البيانات لعنوان ما ليست دليلاً على أنه الخدمة التي يتوقعها المستخدم. فـDNS التقليدي لم يوفر ربطًا تشفيريًا بين استعلام نصي واضح إلى عنوان IP وهوية Google التشغيلية. ويضيف anycast تعددًا شرعيًا للخدمة، لكن المستقبل المحلي غير المصرح به لا يصبح شرعيًا لمجرد أن العنوان يستخدم anycast.

خامسًاإجابة DNS. يمكن لمُحلِّل بديل أن يعيد إجابة صحيحة أو مُتلاعبًا بها أو خطأ أو لا إجابة، أو إجابات مختلفة لأسماء مختلفة. وتُظهر ملاحظة RIPE أن سياسة الاستعلامات المتعلقة بـTwitter تغيرت قبل اختفاء المُحلِّل غير المتوقع لماذا يجب اختبار الإجابة وهوية المُحلِّل بشكل منفصل. فالإجابة الصحيحة من الخدمة الخاطئة لا تثبت استعادة المسار المقصود، والإجابة الخاطئة تثبت مشكلة بيانات في ذلك الاستعلام لا تغيير كل استعلام.

سادسًاالتحقق من السلامة. يمكن لـDNSSEC أن يسمح للمُحقِّق بتوثيق بيانات DNS الموقعة عبر سلسلة ثقة صالحة، لكنه لا يحدد المسار، ولا يوثق اتصالاً نصيًا واضحًا إلى 8.8.8.8، ولا يوقع كل منطقة، ولا يجبر مُعترضًا على توفير التوفر. فحالة التحقق ملاحظة منفصلة يجب تسجيلها لكل اختبار.

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

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

تقارير /32 وأدلة المسار المحلي

تحدد بادئة IPv4 من نوع /32 عنوانًا واحدًا، ويمكن أن يكون الإعلان عن مسار بهذا التحديد وسيلة فعالة لجذب حركة البيانات حيث تقبله الشبكات، لأن مطابقة أطول بادئة تفضل عادة المسار المثبت الأكثر تحديدًا. لذلك تقدم وصفا BGPMon وInternet Society آلية معقولة لاعتراض موجه لعنوان مُحلِّل دون تحويل بادئة محيطة أكبر. وتنتمي تقاريرهما إلى إعادة البناء ولا يجوز تخفيفها إلى ادعاء غامض بأن «التوجيه كان متورطًا».

كما يجب عدم توسيعها إلى ما لا يدعمه السجل. فالإعلان الذي يرصده نظام مراقبة له بصمة انتشار تحددها سياسات التصدير والاستيراد والتصفية. ترفض بعض الشبكات بادئات أطول من الحدود التشغيلية الشائعة، بينما قد تقبلها أخرى أو تحتفظ بها في سياقات محدودة. ولا يثبت وجود /32 مُبلَّغ عنه أنه وصل إلى كل موجّه وصول تركي، أو أن كل موجّه اختاره، أو أنه تسبب في كل نتيجة من نتائج RIPE Atlas.

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

مجموعتا الأدلة لا تنفي إحداهما الأخرى ما لم يُصر المرء على إعداد واحد على مستوى الدولة. فإعلان محدد قد يؤثر على مزود واحد أو نطاق توجيه واحد بينما يستخدم مزود آخر آلية محلية. وقد توجد إشارة BGP عامة في وقت ما بينما يستمر مسار داخلي لفترة أطول. وقد تُعامل عناوين مُحلِّلات عامة مختلفة معاملة مختلفة. والسجل المقدم هنا لا يحسم هذه الاحتمالات، لذا يجب على المقال الدقيق أن يتركها مفتوحة.

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

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

لهذا يجب التعامل مع «اختطاف BGP» وصفًا منسوبًا لنشاط توجيه مُبلَّغ عنه، لا الآلية العامة المثبتة. وعبارة «اعتراض DNS العام» هي المصطلح الجامع الأدق؛ فهي تذكر استبدال الخدمة المرصود مع ترك مجال لتحديد، مشغلًا بمشغل، ما إذا كان السبب BGP أو التوجيه الداخلي أو التوجيه الثابت أو ضابط إعادة توجيه آخر.

anycast: عنوان ثابت ونسخ شرعية متعددة

تستخدم خدمة Google Public DNS أسلوب anycast، مما يتيح الإعلان عن عنوان الخدمة نفسه من مواقع شرعية متعددة، وتوجه سياسة التوجيه المستخدم نحو نسخة قابلة للوصول. يمكن لهذا التصميم تحسين زمن الاستجابة والمرونة، لكنه يعني أيضًا أن عنوان IP لا يقابل خادمًا ماديًا واحدًا ثابتًا أو وجهة جغرافية واحدة غير قابلة للتغيير.

لا يلغي anycast الشرعي هوية الخدمة؛ فالنسخ المتعددة تُشغَّل بوصفها جزءًا من الخدمة المتوقعة نفسها، تحت توجيه مصرح به ورقابة تشغيلية. ولا يصبح نظام داخل شبكة وصول غير مرتبطة مُحلِّل Google لمجرد استقباله حزمًا موجهة إلى 8.8.8.8. ويكمن التمييز في التشغيل المصرح به وأدلة التوجيه وسلوك الخدمة، وعند توفرها في النقل الموثق، لا في الألفة البصرية للعنوان.

كما يجعل anycast اختبارات زمن الاستجابة المبسطة غير كافية. فقد ينتج انخفاض التأخير عن موقع شرعي جديد أو تغيير في سياسة التوجيه أو مستقبِل قريب غير مصرح به. وخلال الحدث التركي، اكتسب انخفاض زمن الاستجابة معنى لأنه تزامن مع استجابات DNS غير متوقعة وتأكيد Google للاعتراض. فبانعزال، لا يثبت «أسرع من الأمس» خطأً أو حتى عطلاً.

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

إجابات DNS والدور المحدود لـDNSSEC

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

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

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

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

لذلك يطرح تقييم DNS القابل للمساءلة أربعة أسئلة منفصلة: هل تلقى المُحلِّل المقصود الاستعلام؟ وهل أعاد المُحلِّل المُجيب البيانات المتوقعة؟ وهل تم التحقق من البيانات الموقعة بشكل صحيح؟ وهل كانت الخدمة متاحة؟ يُفيد DNSSEC في السؤال الثالث ويمكنه التأثير في الثاني، لكنه لا يستطيع الإجابة عن الأول بمفرده ولا ضمان الرابع.

DNS المشفر سياق لاحق، لا شرط بأثر رجعي

تم توحيد معياري DNS عبر TLS وDNS عبر HTTPS بعد حدث 2014، ويجب استخدامهما لشرح الضوابط المتاحة لهوية المُحلِّل الحالية والسرية، لا لإعادة كتابة خط الأساس التاريخي أو التلميح إلى أن الشبكات التركية فشلت في نشر معايير لم تكن موجودة بعد بشكلها اللاحق.

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

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

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

التحقق من منشأ المسار والنقطة العمياء للتوجيه المحلي

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

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

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

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

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

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

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

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

المسؤولية تتبع التحكم العملي

تتضح المساءلة أكثر عندما تتبع الأنظمة التي يمكن لكل جهة تشغيلها وفحصها واستعادتها.

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

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

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

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

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

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

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

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

اختبار استعادة يحافظ على الأدلة ويفحص التكرار

يجب إثبات الاستعادة لا استنتاجها من إجابة واحدة تبدو طبيعية، وتوحي القياسات التركية بتسلسل يمكن لعملية حادث مستقبلية توضيحه.

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

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

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

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

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

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

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

الخطوة الثامنة التأكيد المستقل. يجب أن تؤكد لوحات المشغلين والمجسات الخارجية ومشغّل المُحلِّل المتوقع ومراقبو المسارات معًا المسار وهوية نقطة النهاية والإجابات والنطاق المتأثر. ويجب أن يحدد سجل الإغلاق عناوين المُحلِّلات والشبكات المختبرة ومصدر المسار وأي إعلان خارجي أو مسار محلي ونظام الإجابة ونتائج التحقق والنقل ووقت استعادة كل طبقة والمجهولات المتبقية. ويجب الاحتفاظ بالنتيجة مدة كافية لاختبار التكرار لا إعلان اكتمالها بعد عينة ناجحة واحدة.

المجهولات والحدود القانونية وانضباط الإسناد

تبقى عدة حقائق مهمة خارج السجل العام المحدد هنا؛ فالإعداد الدقيق لدى كل مزود خدمة إنترنت غير معروف، والمجموعة الكاملة لمسارات BGP والمسارات الداخلية والمدخلات الثابتة وأجهزة إعادة التوجيه وعناوين المُحلِّلات المتأثرة غير متاحة، والانقسام بين الآليات التي نقلها مراقبو BGP واحتمال التوجيه المحلي الذي حدده Bortzmeyer لا يمكن قياسه من هذه المواد.

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

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

الإسناد لا يقل أهمية للادعاءات الإيجابية؛ فعبارة «معظم مزودي خدمة الإنترنت الأتراك» تعود إلى Google، ووصف /32 يعود إلى تقارير BGPMon وInternet Society، وملاحظات زمن الاستجابة والإجابة وتباين المجسات والاستعادة تعود إلى RIPE Atlas، وتأهيل المسار المحلي/الثابت يعود إلى إعادة بناء Bortzmeyer. وإبقاء هذه التسميات ملتصقة يمنع سردًا ثانويًا من اكتساب يقين أكبر مما تدعمه أدلته الأساسية.

توجيه المُحلِّل بوصفه اختبارًا للمساءلة

كشف اعتراض DNS العام في تركيا عام 2014 فجوة بين الهوية المهيأة والواقع التشغيلي؛ فكان يمكن للمستخدم إبقاء 8.8.8.8 في لوحة إعدادات بينما تسلم شبكة الوصول الحزمة إلى مُحلِّل تكراري آخر. ولا يسد أي سجل منفرد هذه الفجوة؛ فتقارير /32 لا تثبت آلية عامة، وقد تفوت نافذة الفحص حالة إعادة التوجيه، ويمكن لـRIPE Atlas إظهار الاستبدال لا الجهة الداخلية التي وافقت، ولا يوثق DNSSEC مسارًا، وقد يفوت التحقق من المنشأ مسارًا ثابتًا محليًا، ولا يضمن DNS المشفر الموثق إمكانية الوصول.

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

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

المصادر

  1. https://security.googleblog.com/2014/03/googles-public-dns-intercepted-in-turkey.html
  2. https://labs.ripe.net/author/emileaben/a-ripe-atlas-view-of-internet-meddling-in-turkey/
  3. https://ripe68.ripe.net/programme/meeting-plan/dns-wg/
  4. https://www.ripe.net/community/wg/active-wg/dns/minutes/ripe-68-dns-working-group-minutes/
  5. https://ripe68.ripe.net/presentations/158-bortzmeyer-google-dns-turkey.pdf
  6. https://www.internetsociety.org/blog/2014/06/video-google-dns-hijacking-in-turkey-ripe-68/
  7. https://www.internetsociety.org/blog/2014/04/turkish-hijacking-of-dns-providers-shows-clear-need-for-deploying-bgp-and-dns-security/
  8. https://lists.dns-oarc.net/pipermail/dns-operations/2014-March/011460.html
  9. https://www.ripe.net/ripe/mail/archives/ripe-atlas/2014-March/001401.html
  10. https://www.bgpmon.net/turkey-hijacking-ip-addresses-for-popular-global-dns-providers/
  11. https://www2.bgpmon.net/bgp-routing-incidents-in-2014-malicious-or-not/
  12. https://www.bortzmeyer.org/dns-routing-hijack-turkey.html
  13. https://www.rfc-editor.org/rfc/rfc9505
  14. https://www.rfc-editor.org/rfc/rfc3833
  15. https://www.rfc-editor.org/rfc/rfc4033
  16. https://www.rfc-editor.org/rfc/rfc7454
  17. https://www.rfc-editor.org/rfc/rfc6811
  18. https://www.rfc-editor.org/rfc/rfc8484
  19. https://www.rfc-editor.org/rfc/rfc7858
  20. https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-189.pdf