أمن البنية التحتية

ركّزنا في الفصول السابقة على أمن الأنظمة الطرفية (end-systems) المتّصلة بالإنترنت، وعلى تأمين الاتصال بين الأطراف بينما تعبر حركتهم الإنترنت. لكنّ الإنترنت ذاته يتألّف من بنيةٍ تحتية (infrastructure)، مثل الموجِّهات (routers)، يجب أن تُحمى هي الأخرى من الهجمات. وأكثرُ المجالين إثارةً للقلق هما نظامُ التوجيه بين النطاقات (interdomain routing) ونظامُ أسماء النطاقات (domain name system, DNS). ويعرَض كلا النظامين للهجمات بصورةٍ اعتيادية. وهما كذلك نظامان موزّعان معقّدان. فعلى الرّغم من أنّ توزيع وظائف التوجيه والتسمية يساعد على جعل هذين النظامين صامدين أمام الأعطال (resilient to failure)، فإنّ هنالك فرصًا كثيرةً للهجوم. ونناقش في هذا الفصل بعضَ الجوهود المتواصلة الرامية إلى تحسين مقاومتهما للهجمات. ^[1]

يبني النقاشُ التالي على بعض المفاهيم التي قدّمناها في الفصول السابقة. ومن أبرزها مفهومُ البنية التحتية للمفاتيح العامة (public key infrastructure, PKI) الذي قدّمناه في الفصل 4 والذي تقوم عليه عمليةُ TLS، فإنّه يؤدّي أيضًا دورًا مهمًّا في تأمين البنية التحتية. فبينما تنطبق مبادئُ الشهادات وسلاسلِ الثقة على أيّ بنيةٍ تحتيةٍ للمفاتيح العامة، فإنّ تفاصيلَ كيفية توزيع الشهادات وما تشيرُ إليه تختلف في كلّ تطبيق. ونصف في الأقسام التالية المقارباتِ المختلفة لِلبنية التحتية للمفاتيح العامة في خدمات البنية التحتية.

وتوافرُ البنية التحتية (availability)، بما في ذلك مقاومتُها لهجمات حجب الخدمة (denial-of-service, DoS)، مهمٌّ بوضوح لعمل الإنترنت. ويتولّا على نحوٍ متزايد بنيةٌ تحتيةٌ موزّعة مثل شبكات توزيع المحتوى (content distribution networks, CDNs) التخفيفَ من هذه الهجمات، كما سنناقش في القسم الأخير من هذا الفصل.

8.1 BGP وأمن التوجيه

في معظمِ الأمور، الموجِّه (router) ليس سوى حاسوبٍ مخصَّصٍّ الغرض له بعضُ الواجهات عاليةِ السرعة وبرمجياتٍ متخصّصةٍ لأداءِ مهامٍ مثل حساب المسارات وإعلانها. فذلك تحتاج الموجِّهاتُ إلى الحماية مثل الأنظمة الطرفية، مثلًا بكلمات مرورٍ قويّة ومصادقةِ عواملَ متعدّدة، وباستعمال قوائم تحكّمِ الوصول وجدرانِ الحماية، وهكذا. لكنّ ذلك ليس سوى نقطةِ انطلاق، إذ تُدخل بروتوكولاتُ التوجيه نفسها فرصًا للهجوم. فبروتوكول BGP، أي بروتوكول البوابة الحدودية (Border Gateway Protocol)، معرَّضٌ لمجموعةٍ واسعةٍ من الهجمات، وهو بروتوكولُ التوجيه الوحيدُ المتوقَّع أن يتجاوز حدود نطاقٍ إداريٍّ واحد، فذلك نركّز اهتمامنا هنا.

أمّا التحدّي الرئيسي في تأمين بنية توجيه الإنترنت فينحصر في هذا السؤال: كيف يمكنك أن تثق بإعلانِ توجيهٍ ورد عبر BGP؟ للوهلة الأولى يبدو هذا شبيهًا بالمشكلة التي حلّها TLS: كيف نعرف أنّنا نتحدّث إلى الموقع الذي أردنا الاتصالَ به؟ لكنّ هذه المشكلة لها مستوياتَ متعدّدة حين يأتي التوجيه بين النطاقات. فحين يكون لديك اتصالٌ آمنٌ مشفَّر إلى مصرفك، فأنت على الأرجح تثق بأنّهم سيعرضون عليك معلوماتٍ دقيقةً عن حسابك (في الغالب — فالبنوك تخطئ أحيانًا)، ويحمي الاتصالُ الآمنُ تلك المعلومات من تعديلِها على يد مهاجم. لكنّ الاتصالَ الآمن المشفَّر بموقع جريدة نيويورك تايمز (The New York Times) لا يعني أنّ عليك تصديقَ كلِّ كلمةٍ تنشرها تلك الجريدة. ومثلًا، الاتصالُ الآمن بمتحدّث BGP (وهو موجِّهٌ يشغّل BGP) لا يعني ضمنًا أنّ كلَّ إعلانِ مسارٍ يقدّمه ذلك المتحدّث موثوق. ونحن بحاجة إلى النظر عن قربٍ أكثر في كيفية عمل BGP لنرى أين تكمن التحدّيات.

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

يحتاج متحدّثُ BGP إلى الثقة بأنّ المسارات الواردة إليه من نظيره صحيحة، ويبيّن أنّ هذا تحدٍّ متعدّد الأوجه. وقد كتب جيف هَستن (Geoff Huston)، كبيرُ العلماء في APNIC، تصنيفًا مفيدًا للتهديدات التي يواجهها BGP، وكلُّها تتعلّق بالثقة بين النظراء.

يطرح هذا التصنيف الأسئلة التالية على الاتصال بين متحدّثَي BGP:

• كيف تُحمى جلسةُ BGP من التعديل أو الانقطاع؟
• كيف يتحقّق المتحدّث من هوية نظيره؟
• كيف يتحقّق المتحدّث من أصالة معلومات التوجيه المستلَمة من نظيرٍ ما واكتمالها؟
• كيف يعرف المتحدّث أنّ الإعلانات المستلَمة تمثّل بالفعل الحالةَ الحقيقيةَ لتوجيه النظير؟
• ما مدى حداثة المعلومات المستلَمة، وهل ما زالت صالحة؟

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

قراءات إضافية

S. Murphy. تحليلُ الثغرات الأمنية في BGP. RFC 4272، يناير 2006.

G. Huston. مسحٌ لتأمين التوجيه بين النطاقات، الجزء 1: BGP — التصميمُ والتهديدات ومتطلّباتُ الأمن. مدوّنة APNIC، أغسطس 2021.

L. Peterson وB. Davie. شبكاتُ الحواسيب: مقاربةُ الأنظمة. التوجيهُ بين النطاقات.

8.1.1 المصادقة والسلامة

ولأنّ BGP يعمل فوق اتصال TCP، فقد أُوصي لسنواتٍ كثيرة بأن يُصادَق على اتصال TCP وأن تُحمى سلامتُه باستخدام مصادقة MD5. لكنّ خيارَ مصادقة MD5 في TCP يُعدّ اليوم غيرَ آمنٍ بما يكفي (بسبب هجماتٍ معروفةٍ على خوارزمية MD5). كما يفتقر إلى إدارةٍ ديناميكيةٍ للمفاتيح وإلى القدرة على تحديث الخوارزمية التشفيرية، فذلك استُبدل بخيارِ مصادقةٍ عامّةٍ في TCP هو بديلٌ أفضل، وهو موضَّحٌ في RFC 5925.

قد يبدو نوعًا ما غيرَ متوقَّعٍ (counterintuitive) أنّ BGP لا يعمل اليوم فوق TLS، بالنظر إلى نضج تلك التقنية وانتشارها الواسع. أمّا التفسيرُ لهذا فيعود إلى مجموعةٍ من العوامل، منها التاريخ والجمودُ (inertia) والنموذجُ التشغيليُّ المختلف بين تشغيل BGP وبين الاتصال بموقعٍ بعيد. فمثلًا، كثيرًا ما تُشغَّل جلساتُ BGP بين موجِّهاتٍ متّصلةٍ مباشرةً عند نقطةِ تبادلٍ نظيرٍ إلى نظير أو عند نقاط تبادل الإنترنت (Internet exchange points, IXPs)، وهذا يتيح طريقةً بسيطةً قائمةً على TTL لمنع التزوير. وخصوصيةُ تحديثات BGP أهمّ إلى حدٍّ بعيدٍ أقلّ من الأصالة. وكما سنرى، فإنّ في إثبات أصالة إعلان BGP الكثيرَ أكثرَ مجرّد مصادقةِ الرسائل الواردة من النظير.

حين كان BGP قيد التطوير في الثمانينيات والتسعينيات من القرن الماضي، كانت TLS لا تزال في المستقبل البعيد، وكانت عمليّاتُ تشفير الحزم وفكّ تشفيرها مكلفةةً حسابيًّا على نحوٍ عام. فذلك كان من المنطقيّ أن يكون التركيزُ الأوّل على مصادقة الرسائل، أوّلًا باستخدام MD5 ثمّ بخوارزمياتٍ محدَّثة، بدلًا من توفير الحماية الأكبر التي يقدّمها التشفير.

وبهذا السياق، فإنّ فكرةَ تشغيل BGP فوق TLS مجالُ بحثٍ حاليّ، وهي تقدّم منافعَ محتملة تتجاوز مجرّد إضافة الخصوصية إلى إعلانات BGP. وأبرزُ ما في ذلك أنّ إدارةَ الشهادات لـ TLS صارت مؤتمتةً إلى حدٍّ بعيد، وهذا يناقض التهيئةَ اليدوية التي يجب أداؤها عند استعمال مصادقة MD5 أو المصادقة القائمة على TCP مع BGP. وتعرض الورقةُ أدناه عن النقل الآمن لـ BGP هذه المقاربة وتقترح تحسيناتٍ إضافية قد ترفع من أمن BGP أكثر. لكنّ الممارسةَ الأفضل الموصى بها لجلسات BGP (الموصوفة في RFC 7454) لا تتّسع لتشغيل BGP فوق TLS.

وسواء استُعملت TLS أو آليةُ مصادقةٍ أكثرُ أساسيّة، فإنّ الأثر لا يتجاوز التحقّق من أنّ المعلومات جاءت من النظير المقصود وأنّها لم تُعدَّل أثناء عبورها. أمّا الجزءُ الأصعبُ بكثيرٍ من أمن توجيه الإنترنت فيكمن في التحقّق من معلومات التوجيه نفسها. فحين يُعلن نظيرٌ مسارًا إلى بادئةٍ معيّنة، كيف نعرف أنّه يملك هذا المسار فعلًا؟

قراءات إضافية

T. Wirtgen وN. Rybowski وC. Pelsser وO. Bonaventure. الفوائدُ المتعدّدة للنقل الآمن في BGP. ACM CONEXT، ديسمبر 2024.

J. Durand وI. Pepelnjak وG. Doering. تشغيلُ BGP وأمنُه. RFC 7454، فبراير 2015.

8.1.2 صحّة معلومات التوجيه

حين يُعلن متحدّثُ BGP مسارًا إلى بادئةٍ معيّنة، كيف نعرف أنّه يملك هذا المسار حقًّا؟ وهل نعرف أنّه سيستعمل المسارَ إن طُلب منه ذلك؟ بل هل هو مُخوَّل أصلًا باستعماله؟ والإجابةُ القصيرة عن كلّ هذه الأسئلة أنّنا لا نعرف، لكنّنا سعينا عقودًا لبناء آليّاتٍ تمكّن من الثقةِ أكثر في صحّة هذه الإعلانات. وقد وثّقت شارون غولدبرغ (Sharon Goldberg) عام 2014 هذا السعيَ وبطءَ تقدّمه توثيقًا جيّدًا. ورغم أنّ التقدّم مستمرٌّ اليوم، فإنّ دراسةً أحدثَ من تيستارت وكلارك (Testart and Clark) عام 2021 أشارت إلى أنّ التقدّم ظلّ بطيئًا. وهناك أسبابُ عدّة لبطء التقدّم، كما سنناقش أدناه.

ولنبدأ بمثالٍ بسيطٍ ومُدرَسٍ جيّدًا. عام 2008، أمرَت الحكومةُ في باكستان مزوّداتِ الخدمة بحجب الوصول إلى YouTube للمستخدمين داخل البلاد. واختارت إحدى مزوّداتِ الخدمة (Pakistan Telecom) أن تفعل ذلك بإعلان مسارٍ إلى بادئةٍ تقع ضمن النطاق المخصّص لـ YouTube. وبعبارةٍ أخرى، أعلنَت «لديّ مسارٌ جيّد إلى YouTube»، ومن ثمّ استطاعت إعادةَ توجيه الحركة التي تحاول اتّباع ذلك المسار. وكانت المشكلةُ أنّ هذا المسار لم يكن طريقةً صالحةً للوصول إلى YouTube فحسب، بل كان أيضًا مسارًا أكثرَ تحديدًا، أي أنّه يخصّ بادئةً أطولَ من المسار الحقيقي إلى YouTube الذي كان يُعلنه أنظمةٌ مستقلّةٌ ذاتيّةٌ أخرى. وبما أنّ توجيه IP يقوم على أطول مُطابقةٍ للبادئة في جدول التوجيه (longest-prefix match)، فإنّ المسارَ الأكثرَ تحديدًا يتغلّب على الأقلّ تحديدًا حين تطابق الحزمُ البادئةَ الأطول. وقد تحوّل هذا إلى مشكلةٍ تتجاوز حدود باكستان كثيرًا حين أعلنَت المزوّدُ المسارَ إلى مزوّدٍ أكبر في اتجاه الأعلى (upstream). فأصبح المزوّدُ الأعلى يرى المسارَ الأكثرَ تحديدًا بوصفه معلومةَ توجيهٍ مستقلّةً عن المسار الحقيقي الأقلّ تحديدًا، فأعاد إعلانَ ذلك المسار الكاذب إلى نظيره. وقد أدّى تكرارُ تطبيق هذا القرار — قبولَ المسار الأكثر تحديدًا وإعادةَ إعلانه — إلى أن رأت نسبةٌ كبيرةٌ من الإنترنت الموجِّهَ الصغير في باكستان مسارًا حقيقيًّا إلى YouTube. وخلال دقائقٍ صارت نسبةٌ كبيرةٌ من الإنترنت ترسل حركةَ طلبات YouTube إلى باكستان، مؤدّيةً إلى انقطاعٍ عالميّ لخدمة YouTube. وقد عولجت المشكلةُ بتدخّلٍ يدويٍّ لدى عدّة مزوّداتٍ لإيقاف الإعلان العالميّ عن ذلك المسار الكاذب.

وثمة أشكالُ هجومٍ كثيرةٌ أخرى ممكنةٌ على BGP، لكنّها تأخذ في الغالب شكلَ مسارٍ يُعلَن ثمّ يُنشر حين لا ينبغي أن يُعلَن. وهناك إجراءٌ بسيطٌ نسبيًا كان من المفترض أن يمنع الحادثةَ الموصوفة أعلاه: ينبغي ألّا يقبل نظامُ AS المزوّدُ الذي يقع مباشرةً فوق Pakistan Telecom في اتجاه الأعلى (upstream) الإعلانَ القائلَ «لديّ مسارٌ إلى YouTube». فكيف يمكنه أن يعرف أنّ عليه ألّا يقبله؟ فبعد كلّ شيء، يحتاج BGP إلى أن يكون ديناميكيًّا، ولذلك فإنّ البادئةَ المُعلَنة حديثًا يكون صحيحًا في غالبِ الأحيان. وأحدُ الحلول لهذه المشكلة هو استعمال سجلّات توجيه الإنترنت (Internet Routing Registries, IRRs)، التي تؤدّي دورَ قواعدِ بياناتٍ تربط بادئاتِ العناوين بالأنظمة المستقلّةِ الذاتيّة المخوَّلة بإعلانها. وفي المثال السابق، بما أنّ YouTube ليست عميلًا لـ Pakistan Telecom، فإنّ السجلَّ سيبيّن أنّ بادئةَ YouTube يجب ألّا تُعلَن من قِبل هذا النظام المستقلّ. ومسؤوليةُ ترشيحِ الإعلان الكاذب تقع على مزوّدِ الخدمة في اتجاه الأعلى (upstream)، الذي عليه أن يستعلم دوريًّا عن سجلٍّ واحدٍ أو أكثر من سجلّات IRR كي يحتفظ بمجموعةِ مرشِّحاتٍ محدَّثةٍ يطبّقها على نظيره في اتجاه الأسفل (downstream).

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

وهناك أيضًا مسألةُ ما إذا كانت كلُّ المعلومات التي يوفّرها سجلٌّ من سجلّات IRR جديرةً بالثقة. ونناقش في ما يلي المقارباتَ لبناء الثقة في المعلومات التي يوفّرها هذا السجلّ.

وعلاوةً على ذلك، كما لوحظ في المقالة «لماذا يستغرقُ تأمينُ توجيه الإنترنت هذه المدّةَ الطويلة؟»، فإنّ دوافعَ ترشيحِ البادئات غيرُ متوفّقةٍ جيّدًا. فكلفةُ الترشيح تقع على النظام المستقلّ الذاتيّ الذي يقع مباشرةً فوق مزوّدِ الخدمة الذي يسوء سلوكه في اتجاه الأعلى (upstream)، بينما تعود المنفعةُ إلى كيانٍ بعيدٍ (YouTube في مثالنا) الذي يتجنّب أثرَ ذلك على حركته بفضل عمل مزوّدِ خدمةٍ لا تربطه به أيّ علاقة.

وتعتمد مقاربةٌ أكثرُ تطوّرًا على استعمال بياناتٍ موقَّعةٍ تشفيريًّا تُجيز لنظامٍ مستقلٍّ ذاتيّ معيَّن أن يعلن مساراتٍ إلى بادئةٍ معيّنة. وتُعرَف التقنيةُ التي تقف خلف ذلك باسم RPKI، أي البنية التحتية للمفاتيح العامة للموارد (Resource Public Key Infrastructure). ويبني RPKI على مفاهيم التوقيعات التشفيرية وتسلسل الشهادات الهرميّ الذي قدّمناه في الفصول السابقة.

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

قراءات إضافية

S. Goldberg. لماذا يستغرقُ تأمينُ توجيه الإنترنت هذه المدّةَ الطويلة؟. ACM Queue، أغسطس 2014.

C. Testart وD. Clark. مقاربةٌ قائمةٌ على البيانات لفهم حالة أمن توجيه الإنترنت. TPRC 48، فبراير 2021.

8.1.3 التحقّقُ من أصل المسار (ROV)

أوّلُ استعمالات RPKI هو تمكينُ نظامٍ مستقلٍّ ذاتيّ من إثبات أنّه مُخوَّل بإطلاق إعلانات التوجيه لبادئاتِ عناوينَ معيّنة. ويحتوي تفويضُ أصل المسار (Route Origin Authorization, ROA) على شهادةٍ ورقمِ نظامٍ مستقلٍّ ذاتيّ ومجموعةِ بادئاتٍ مُجيزٍ لهذا النظام أن يعلنها. ويُوقَّع ROA تشفيريًّا على يد كيانٍ يُوثَق في تقديم هذا التفويض، وهو عادةً الجهةُ التي خُصّصت لها هذه البادئةُ من العناوين. فمثلًا، تُخصَّص لمزوّدِ خدمةٍ عادةً مجموعةٌ معيّنةٌ من البادئات، وقد يُطلق إعلاناتَ توجيهٍ لتلك البادئات. ويتيح ROA لمزوّد الخدمة أن يؤكد أنّه يملك الصلاحيةَ بالإعلان، ويمكّن متحدّثات BGP في أنحاء الإنترنت من التحقّق من هذا التأكيد.

إنّ توزيعَ العناوين في الإنترنت عمليةٌ هرمية. وتقع سجلّاتُ الإنترنت الإقليمية (Regional Internet Registries, RIRs) في قمة الهرم لتوزيع العناوين. ويجعلها موقعُها في هرم توزيع العناوين موضعًا منطقيًّا لجذور الثقة في RPKI، المعروفة بـ مراسي الثقة (trust anchors). وهناك خمسةُ سجلّاتٍ إقليمية في العالم (ARIN وRIPE وAPNIC وAFRINIC وLACNIC)، ولكلٍّ منها شهادةُ جذرٍ في RPKI.

ويعمل التوزيعُ الهرميّ للعناوين على النحو التالي: يستطيع سجلٌّ إقليميّ تخصيصَ كتلةٍ من فضاء العناوين لمزوّدِ خدمة، فيستطيع المزوّدُ إعادةَ توزيع أجزاءٍ من تلك الكتلة على كلٍّ من عملائه. وقد توجد طبقاتٌ إضافيةٌ في هذا الهرم. ويمكن إنشاءُ تسلسلٍ هرميٍّ للشهادات يتبع هذا التوزيعَ الهرميّ للعناوين. وتُشكّل السجلّاتُ الإقليمية مراسيَ ثقةٍ تنطلق منها سلاسلُ الثقة، على نحوٍ مشابهٍ تمامًا لمتصفّحٍ حديثٍ يأتي مع مجموعةٍ من سلطاتِ الشهادات (certificate authorities, CAs) الجذرية الموثوقة، بحيث يمكن التحقّقُ من صحّة الشهادات التي تُصدرها المواقعُ والتي وقّعتها تلك السلطات.

إنّ تمييزًا جوهريًّا بين RPKI والشهادات التي نعرفها من TLS هو هذا: إنّ شهادات TLS تُستعمل للتحقّق من هويّة موقع ويب (مثلًا، شهادةُ cnn.com تُخبر متصفّحك أنّه يتحدّث فعلًا إلى الكيان الذي يشغّل cnn.com)، في حين تُستعمل شهادات RPKI للتحقّق من الموارد المخصَّصة لكيانٍ ما مثل مزوّدِ خدمةٍ أو عميلٍ نهائي. والمواردُ في حالة شهادات ROA هي بادئاتُ عناوين IP. وبما أنّ توزيعَ عناوين IP يبدأ من السجلّات الإقليمية وينزل إلى مزوّدات الخدمة وصولًا إلى العملاء النهائيين، فإنّ شهادات الموارد تُولَّد في كلّ مستوىٍ من مستويات الهرم.

الشكل 24. سلسلةُ الثقة في RPKI.

يبيّن الشكل 24 كيف تُرتَّب الشهادات في مثالٍ بسيطٍ لمزوّدِ خدمة A ولعميلٍ له هو C. وهناك سلسلةُ ثقةٍ من شهادة الجذر إلى العميل، على نحوٍ يشبه التسلسلَ الهرميّ للشهادات الذي رأيناه مستعمَلًا مع TLS. لكنّ الهدف هنا في نهاية المطاف هو تصديق صلاحية نظامٍ مستقلٍّ ذاتيّ معيَّن في إعلان بادئة، ولذلك تختلف تفاصيلُ الشهادات عن تلك المستعملة في TLS. فمثلًا، الشهادةُ التي يُصدرها مزوّدُ الخدمة A، في أقصى يمين الصورة، تقول إنّ بادئةَ عناوينَ معيّنةٍ خُصّصت للعميل C، وتتضمّن المفتاحَ العامَّ للعميل C. وهذه الشهادةُ موقَّعةٌ من مزوّدِ الخدمة A بواسطة المفتاح الخاصّ لـ A. فإذا استطعنا الثقةَ بـ A تعلّمنا أمرين عن C: مفتاحَه العامَّ ومجموعةَ العناوين المخصَّصةَ لصاحب ذلك المفتاح. ولاحظ أنّنا لا نتعلّم من هو C (على خلاف شهادة TLS)؛ إنّما نتعلّم المفتاحَ العامَّ للكيان المخوَّل بإطلاق إعلانات التوجيه لبادئةٍ ما أو لبادئاتٍ.

وفي مستوى أعلى في السلسلة، يكون السجلُّ الإقليمي للإنترنت (RIR) قد أصدر شهادةً تقول إنّ مزوّدَ الخدمة A يملك صلاحيةَ تخصيص عناوين من بعض البادئة. ويجب أن تكون البادئةُ التي خُصّصها A للعميل C بادئةً فرعيةً ضمن التخصيص الذي أجراه السجلّ الإقليمي. وباتّباع السلسلة عائدًا إلى شهادة الجذر، يمكن إثباتُ أنّ C مخوَّلٌ فعلًا بإعلان البادئة المخصَّصة له من قِبل A.

حتى هذه النقطة، فقد أنشأنا مجموعةَ ربطٍ (bindings) بين المفاتيح العامة — التي تحتفظ بها كياناتٌ مثل سجلّات الإنترنت ومزوّدات الخدمة والعملاء النهائيين — وبين بادئاتِ عناوين IP المخصَّصة لتلك الكيانات. والخطوةُ التالية هي إنشاءُ تفويضِ أصل المسار (ROA)، وهو كائنٌ موقَّعٌ تشفيريًّا يربط بادئةً بنظامٍ مستقلٍّ ذاتيّ مخوَّلٍ بإطلاق إعلانات التوجيه لتلك البادئة.

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

الشكل 25. لتفويضِ أصل المسار سلسلةُ ثقةٍ تعود إلى جذر RPKI.

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

ولاحظ التناقضَ مع الاستعمالات السابقة للشهادات التي رأيناها: فأداةُ التحقّق المحلّية تبني تصوُّرًا كاملًا لتسلسل الشهادات مسبقًا استعدادًا لقرارات التوجيه التالية، بدلًا من التحقّق من صحّة الشهادات بوصفه جزءًا من إنشاء جلسة (كما يحدث في TLS مثلًا). وتصير المستودعاتُ الآن جزءًا أساسيًّا من بنية التوجيه لدينا، ويجب أن تكون هي نفسها مؤمَّنةً ومحميّةً من هجمات حجب الخدمة.

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

وبإقرار RPKI، صار من الممكن الآن إجراءُ التحقّق من أصل المسار (Route Origin Validation, ROV). أي أنّه إذا ادّعى نظامٌ مستقلٌّ ذاتيّ معيَّن أنّه منشئُ بادئةٍ ما، فيمكن التحقّقُ من هذا الادّعاء مقابل المعلومات الموجودة في RPKI. فمثلًا، لو ادّعت Pakistan Telecom الآن أنّها النظامُ المستقلّ منشئُ بادئةٍ فرعيةٍ من بادئات YouTube، ليمكن اكتشافُ ذلك فورًا بوصفه معلوماتٍ كاذبةً والتخلّصُ منه من أيّ موجِّهٍ يستقبل إعلانًا كهذا، لا من جيران مزوّدِ الخدمة المُسيء فحسب.

الشكل 26. يحتفظ كلُّ نظامٍ مستقلٍّ ذاتيّ بذاكرةٍ مؤقّتةٍ محلّيةٍ لمستودع RPKI، واستعلامُ متحدّثات BGP هذه الذاكرةَ المحلّية، مما يتيح لها التحقّقَ من إعلانات BGP.

تبيّن الشكل 26 بعضَ الجوانب العملية للتحقّق من أصل المسار. يحتفظ النظامُ المستقلّ الذاتيّ الذي يجري هذا التحقّقُ بذاكرةٍ مؤقّتةٍ محلّيةٍ لمستودع RPKI، تُجلب باستخدام rsync أو بروتوكول فوارق مستودع RPKI (RPKI Repository Delta Protocol, RRDP). ويستعيد متحدّثُ BGP داخل النظام المستقلّ مجموعةَ تفويضاتِ الأصل الصالحة بالاستعلام من الذاكرة المحلّية، مستعملًا بروتوكولًا آخرَ يُدعى بروتوكول RPKI إلى الموجِّه (RPKI-to-router, RTR). ويتيح هذا البروتوكولَ للموجِّه تلقّيَ تحديثاتٍ دوريةٍ لمجموعة تفويضاتِ الأصل الصالحة من الذاكرة المحلّية. ومع توفّر هذه المعلومات في يده، يستطيع الموجِّه التحقّقَ من صحّة النظام المستقلّ الذاتيّ المُطلق في إعلانات BGP التي يتلقّاها من أنظمةٍ مستقلّةٍ ذاتيّةٍ أخرى.

ورغم أنّ هناك أشكالًا كثيرةً من الهجوم أو سوء الإعداد لا تكشفها ROV (ولا سيما نظامٌ مستقلٌّ ذاتيّ يُعلن زورًا مسارًا غيرَ موجودٍ فعليًا إلى نظامٍ مستقلٍّ ذاتيّ مُطلقٍ صالح)، فإنّها تمنع عددًا كبيرًا من المشكلات، ولا سيما تلك الناجمة عن سوء الإعداد.

ويسير تبنّي RPKI لأغراض التحقّق من أصل المسار باطرادٍ منذ عدّة سنوات. ويتابع المعهدُ الوطنيّ للمعايير والتقنية (NIST) تبنّيَ تفويضاتِ الأصل — انظر قسم «قراءات إضافية». وعند وقت الكتابة، يُظهر مراقبُ RPKI التابع لـ NIST أنّه من بين المسارات المعلن عنها عالميًّا في BGP، وعددها أكثرُ من مليون، تغطّيها تفويضاتُ أصلٍ صالحة بنحو 56% منها. ويُكتشف أقلُّ من 2% على أنّها غيرُ صالحة (يفشل فحص ROV)، بينما لا تتضمّن الـ 42% الباقية أيّ معلومات تفويضِ أصل. والنظرُ في الانتشار عبر الزمن يُظهر زيادةً مطردةً في تفويضاتِ الأصل الصالحة مقابل انخفاضٍ في مجموعة «غير الموجود» — أي الإعلانات التي لا تحمل تفويضَ أصل. ورغم أنّ 56% بعيدةٌ كلَّ البعد عن 100%، فإنّ هذا المستوى من الاختراق إنجازٌ مهمٌّ — ولا سيما بالنظر إلى الصعوبة التاريخية التي تنطوي عليها إجراءُ تغييرات في توجيه الإنترنت وفي «نواة» الإنترنت.

وثمة نقطةٌ أخيرةٌ جديرةٌ بالذكر عن RPKI، وهي أنّه، مثله مثل بُنى الشهادات الأخرى، يعتمد على قوائمِ إبطال الشهادات (Certificate Revocation Lists, CRLs) لإبطال الشهادات. وهذا مهمٌّ لمعالجة حالاتٍ مثل إعادةَ تخصيص بادئةِ عناوينٍ من مزوّدٍ إلى آخر. والخبرُ السارّ أنّ قوائمَ الإبطال هذه تُوزَّع من مستودعات RPKI كما تُوزَّع بقيةُ الكائنات في RPKI.

قراءات إضافية

NIST. مراقبُ RPKI.

8.1.4 التحقّقُ من المسارات (BGPsec)

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

وتوجد بضعُ مقترحاتٍ مختلفةٍ لكيفية التحقّق الآمن من المسارات. ونركّز هنا على معيار BGPsec الصادر عن IETF، إذ يوضّح المقاربةَ العامة والتحدّياتِ التي تواجه بلوغَ انتشارٍ واسع.

وعلى خلاف ROV، فإنّ التحقّقَ من المسارات في BGPsec يعتمد على تبنّي عملياتٍ تشفيرية بوصفها جزءًا من BGP نفسه. فكلُّ متحدّث BGP (موجِّهٍ) يشارك في التحقّق من المسارات يوقّع إعلاناته بمفتاحٍ خاصٍّ خاصٍّ بموجِّهه. والمفتاحُ العامُّ المقابل لمفتاحٍ خاصٍّ كهذا مُضمَّنٌ في شهادةٍ تُنشر في RPKI. وتشملُ هذه الشهاداتُ كذلك رقمَ النظام المستقلّ الذاتيّ (أو الأرقامَ) التي تقابل النظام المستقلّ الذاتيّ الذي يقع فيه الموجِّه.

وكما في جميع شهادات المفاتيح العامة، نحتاج إلى سلسلةِ ثقةٍ من جذرٍ موثوق إلى شهادة الموجِّه. فمثلًا، يمكن للسجلّ الإقليمي أن يوفّر جذرَ الثقة، وأن يوقّع شهاداتٍ لمزوّدات الخدمة، الذين يمكنهم بدورهم أن يعملوا كسلطاتِ شهاداتٍ لموجِّهاتهم. واستعمالُ كلمة «يمكن» في هذه الفقرة يعكس انعدامَ انتشار BGPsec في العالم الحقيقي.

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

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

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

ولننظر الآن في عملية بناء مسارٍ إلى بادئةٍ معيّنة. يتألّف المسارُ من مجموعةٍ من الأنظمة المستقلّة الذاتيّة. فمثلًا، يوقّع موجِّهٌ في النظام المستقلّ AS1، وهو النظام المُطلق، إعلانًا يقول إنّه أصلُ البادئة، باستعمال مفتاحه الخاصّ. كما أنّه يُدرِج رقم النظام المستقلّ الهدف، AS2، الذي يرسل إليه الإعلان، ضمن مجموعة الحقول التي يغطّيها التوقيع. وهكذا ينتهي الأمر إلى رسالة تقول «يستطيع AS1 الوصولَ إلى البادئة P وقد أرسل هذه المعلومات إلى AS2»، موقَّعةً من موجِّهٍ تابعٍ لـ AS1.

ويتلقّى موجِّهٌ في AS2 هذا الإعلان، وبعد أن يتحقّق من التوقيع يستطيع الآن أن يضيف نفسه إلى المسار. ويستطيع موجِّهُ AS2 الآن أن يُصدر إعلانًا موقَّعًا يقول «المسار <AS2,AS1> يؤدّي إلى البادئة P»، ويوقّعه بمفتاحه الخاصّ. ويُدرِج فيه الرسالةَ الكاملةَ الموقَّعة القادمة من AS1 إضافةً إلى المسار الجديد. ومرةً أخرى، قبل التوقيع، يُدرِج رقمَ النظام المستقلّ الذاتيّ الهدف الذي يرسل إليه هذا الإعلان. ويتلقّى هذا الإعلانَ النظامُ AS3 الذي يستطيع الآن أن يضيف نفسه إلى المسار ويوقّع النتيجة، وهكذا دواليك.

وإدراجُ النظام المستقلّ الذاتيّ الهدف ضمن الموادّ الموقَّعة جوهريٌّ لتشغيل BGPsec على نحوٍ صحيح. فافترض مثلًا أن يحاول AS3 أن يكذب في المسار الذي لديه إلى AS1، مدّعيًا أنّ المسار <AS3,AS1> صالح (مع تخطّي AS2). وهو لا يستطيع بناءَ رسالةٍ صالحةٍ بهذا الادّعاء انطلاقًا من المعلومات التي تلقّاها من AS2، لأنّ AS2 هو الهدف الذي حدّده AS1. وأيُّ محاولة لبناء مسارٍ موقَّع <AS3,AS1> يمكن كشفُها على أنّها غيرُ صالحة، لأنّ العبارةَ الموقَّعة الصادرة من AS1 تشير إلى أنّ هدفَها كان AS2 لا AS3.

وهكذا، حين يتلقّى إعلانٌ موقَّعٌ صالح، يتوصّل المستلِمُ إلى التحقّق من أنّ كلّ نظامٍ مستقلٍّ ذاتيّ في السلسلة المؤدّية إلى الوجهة قد تلقّى إعلانًا ببقية المسار إلى الوجهة. ورغم أنّ هذا لا يثبت بصورةٍ قاطعة أنّ المسارَ إلى الوجهة قادرٌ فعليًّا على حمل البيانات، فإنّه يثبت أنّ مجموعةً من الإعلانات توصّلت إلى طريقها على امتداد المسار المذكور. ويبقى من الممكن أن يكون قد أعلن نظامٌ مستقلٌّ ذاتيّ مسارًا لن يفي به — فمثلًا، قد يرفض AS2 (أو يعجز عن) تحويل الحركة من AS3 إلى AS1 رغم أنّه أعلن المسار. ومن المخاوف تحديدًا تسرُّباتُ المسارات (route leaks)، حيث يؤدّي سوءُ الإعداد إلى أن يعلن نظامٌ مستقلٌّ ذاتيّ مسارًا بالخطأ، دون أيّ نيّةٍ في اجتذاب الحركة إلى تلك البادئة. وحين تصل هذه الحركة، قد تُرهق مواردَ النظام المستقلّ الذاتيّ الذي أعلن المسار بالخطأ، فيُنظر في إسقاط الحركة.

وعلى خلاف ROV، فإنّ قصّة انتشار التحقّق من المسارات باستخدام BGPsec مُحبطة. فلم نصف إلّا واحدًا من عدة مقترحاتٍ للتحقّق تشفيريًّا من المسارات المُعلنة في BGP، لكنّ الحقيقة المؤسِّفة أنّ أيًّا منها لم ينتشر بشكلٍ يُذكر. وهناك تحدّيان على الأقلّ في التحقّق من المسارات يسهمان في هذا الحال. أوّلهما أنّ بدءُ إجراءِ عملياتٍ تشفيرية بوصفه جزءًا من BGP مكلفٌ نسبيًّا (على خلاف ROV، حيث تحدث العمليات التشفيرية بمعزل عن التحقّق من رسائل BGP). أمّا الثاني فهو مشكلةُ العمل الجماعي (collective action problem): فحين يتحمّل مزوّدُ خدمةٍ واحدٌ كلفةَ تنفيذ BGPsec، فإنّه لا يُحسّن وضعَ ذلك المزوّد بأيّ قدرٍ يُذكر. ولا حين تبلغ كتلةٌ حرجةٌ من مزوّدات الخدمة إلى استعمال BGPsec يبدأ هذا الأخير في تقديم منافعَ تدريجيةٍ كبيرةٍ مقارنةً بـ ROV. وفي المقابل، فإصدارُ تفويضِ أصلٍ ما يمنح فورًا المنفعةَ لمزوّدِ الخدمة الذي يُصدره. وتُجسّد هذه الحالة الورقةُ العلمية «أمنُ BGP في الانتشار الجزئي». ويعرض القسم التالي مقاربةً تَعِد بمعالجة هاتين المشكلتين معًا.

قراءات إضافية

R. Lychev وS. Goldberg وM. Schapira. أمنُ BGP في الانتشار الجزئي: هل تستحقُّ الألفاظُ هذا العسر؟. ACM SIGCOMM، أغسطس 2013.

8.1.5 تفويضُ مزوّد النظام المستقلّ (ASPA)

وعند وقت الكتابة، يجري في IETF جهدٌ لوضع معيار لمقاربةٍ للتحقّق من المسارات تُعرف بـ ASPA، أي تفويضِ مزوّد النظام المستقلّ (AS Provider Authorization). وتقوم الفكرةُ على استعمال مجموعةٍ جديدةٍ من الكائنات في RPKI لتوثيق العلاقات بين الأنظمة المستقلّة الذاتيّة، ثمّ استعمال تلك المعلومات للتحقّق من صحّة إعلانات BGP فور ورودها.

وتشارك ASPA مع ROV خاصيّةً مريحة: فلا تُضاف أيّ عملياتٍ تشفيرية إلى BGP نفسه. فكما يبني ROV قاعدةَ بياناتٍ (في RPKI) لمَن يُجيز له إطلاقُ إعلان، تبني ASPA قاعدةَ بياناتٍ تُظهر أيُّ الأنظمة المستقلّة الذاتيّة توفّر خدمةَ ترانزيت لأنظمةٍ مستقلّةٍ ذاتيّةٍ أخرى. وهذا أيضًا يستعمل RPKI، لكن بنوعٍ مختلفٍ من الشهادات، تُعرف بسجلّات ASPA.

ومن المكوّنات المهمّة في ASPA هي الرؤيةُ بأنّ العلاقات بين الأنظمة المستقلّة الذاتيّة يمكن وضعها في مجموعةٍ صغيرةٍ من الأصناف. أوّلًا، إذا لم تكن هناك وصلةُ BGP بين زوجٍ من الأنظمة المستقلّة الذاتيّة، فلا توجد بينهما علاقة — ومن ثمّ فلا ينبغي أن نرى هذا الزوج متجاورَين في مسارٍ معلن. وأمّا أيُّ زوجٍ من الأنظمة المستقلّة الذاتيّة يتّصل فعلًا، فيمكن عادةً تصنيفُ العلاقة بينهما بأنّها من عميلٍ إلى مزوّد (customer-to-provider)، أو من نظيرٍ إلى نظير (peer-to-peer). فالعميلُ يعتمد على المزوّد في توصيل الحركة إلى نظامه المستقلّ الذاتيّ ومنه، وهذا يعني أنّه متوقَّعٌ أن يظهر رقمُ النظام المستقلّ الذاتيّ للمزوّد في إعلانات التوجيه المعبَّرة عن الوصول إلى نظام العميل. وفي المقابل، لا تسلِّم الأنظمةُ المستقلّةُ الذاتيّةُ للعميل حركةً إلى أنظمة مزوّديها إلّا إذا كانت تلك الحركة منبعَها النظامُ المستقلّ الذاتيّ للعميل نفسه أو عملاءُ ذلك العميل.

وتُصوَّر العلاقةُ بين العملاء والمزوّدين عادةً بصريًّا بوصفها توجيهًا «خاليًا من الوديان» (valley-free). فإعلانات التوجيه تتدفّق «إلى أعلى» من العملاء إلى المزوّدين، ثمّ (اختياريًّا) «عبرَ» المسار بين النظراء، ثمّ «إلى أسفل» من المزوّدين إلى العملاء، كما هو مبيَّن في الشكل 27. وفي هذه الصورة، تُرسمُ الأنظمةُ المستقلّةُ الذاتيّةُ للعميل تحت أنظمة مزوّديها، بينما النظامان في القمة بينهما علاقةُ نظيرٍ إلى نظير. والمساراتُ الخاليةُ من الوديان تتميّز بأنها لا تبدأ بالنزول (نحو العملاء) ثمّ تصعد مجدّدًا نحو المزوّدين. وظهورُ وادٍ مؤشِّرٌ قويٌّ على تسرّبِ مسارٍ ما. وقاعدةُ البيانات التي تؤسّس علاقات العميل بالمزوّد تمنحنا القدرةَ على كشف هذه الشذوذات.

الشكل 27. بنيةٌ طوبولوجيةٌ للأنظمة المستقلّة الذاتيّة خاليةٌ من الوديان.

ولنفترض أنّ نظامين مستقلّين ذاتيَّين، هما X وY، ينشران قائمةَ مزوّديهما باستعمال كائنات ASPA في RPKI. ولنفترض أنّ هناك كائن ASPA صادرًا من النظام المستقلّ Y يؤكد أنّ النظام المستقلّ X أحدُ مزوّديه، وكذلك كائن ASPA صادرًا من النظام المستقلّ X لا يضمّ النظام المستقلّ Y في قائمة مزوّديه. فإذا تلقّى موجِّهٌ إعلانًا يظهر فيه Y بوصفه مزوّدًا لـ X، فإنّ ذلك خاطئٌ بوضوح، ويُسقط الموجِّهُ الإعلان. أمّا مسألةُ كيف نستطيع تمييزُ أنّ نظامًا مستقلًّا ذاتيًّا معيّنًا مزوّدٌ أو عميلٌ أو نظيرٌ لنظامٍ مستقلٍّ ذاتيّ آخر، فهي مسألةٌ دقيقةٌ بعضَ الشيء، لكنّها تعتمد على خصائص التوجيه الخالي من الوديان. فلا يمكن أن نخلط عشوائيًّا بين روابط العميل بالمزوّد وروابط المزوّد بالعميل في مسارٍ صالح؛ بل لا بدّ من مجموعةٍ من المسارات تذهب «إلى أعلى» نحو المزوّدين، يليها مسارٌ جانبيٌّ واحدٌ على الأكثر، ثمّ مجموعةٌ من المسارات تذهب «إلى أسفل» نحو العملاء. وكلّما زاد عددُ العلاقات المودَعة في RPKI، ازدادت قدرةُ متحدّث BGP على كشف المسارات غير الصالحة.

وتضيف ASPA أمنًا إضافيًّا إلى نظام التوجيه يفوق ما يقدّمه ROV، لأنّها تكشف الهجمات التي يعلن فيها نظامٌ مستقلٌّ ذاتيّ مساراتٍ يكون فيها النظام المستقلّ الذاتيّ المُطلق صحيحًا (أي أنّه مغطّىٌ بتفويض أصلٍ صالح) لكنّ المسار غيرُ مشروع. وتُعرف هذه الهجمات بـ اختطافاتِ بادئاتِ المصدرِ المزوَّر (forged-origin prefix hijacks).

وعلاوةً على ذلك، تكشف ASPA بعضَ مشكلات التوجيه (مثل تسرُّب المسارات العرضي) التي لا تكشفها BGPsec. وذلك لأنّ BGPsec تُظهر أنّ الأنظمة المستقلّة الذاتيّة متّصلة ببعضها، لكنّها لا توثّق علاقات العميل بالمزوّد. كما تقدّم ASPA منافعَ حتى لو انتشرت جزئيًّا على مسارٍ ما، كما يوضّح المثال أعلاه. وبعبارةٍ أخرى، فإنّها صالحةٌ للانتشار التدريجي.

قراءات إضافية

A, Azimov وآخرون. التحقّقُ من مسار AS في BGP بالاعتماد على كائنات تفويض مزوّد النظام المستقلّ (ASPA). مسودّة إنترنت، عملٌ جارٍ.

8.2 أمنُ DNS والتسمية

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

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

و«تسميمُ الذاكرة المؤقّتة» (cache poisoning) — الذي يُشار إليه أحيانًا أيضًا بـ انتحالِ DNS (DNS spoofing) — شكلٌ شائعٌ من أشكال الهجوم على DNS. فإذا تمكّن المهاجمُ من إجبار محلِّلٍ على إجراء استعلامٍ تكرّري إلى خادم أسماءٍ مخوَّل، أو من التنبّؤِ بتوقيت إجراء استعلامٍ كهذا، فبإمكانه أن يحاول إرسال ردٍّ مزيَّفٍ على ذلك الاستعلام. ويبيّن الشكل 28 والشكل 29 مثالًا على ذلك.

الشكل 28. مثالٌ على حلّ أسماء DNS.

وحين يعمل كلُّ شيءٍ على النحو المقصود، تُجري آلةُ العميل استعلامًا إلى محلِّل DNS المحلّي، الذي لا يجد شيئًا في ذاكرته المؤقّتة فيرسل استعلامًا إلى خادم أسماءٍ مخوَّل. وهذه واحدةٌ من أبسط سيناريوهات حلّ الأسماء حين لا تكون الإجابةُ مخزّنةً محلّيًّا أصلًا. (وسيُحتاج في كثيرٍ من الأحوال إلى استعلاماتٍ متعدّدة في الخطوة 2.) ثمّ تُعاد الإجابةُ من الخادم المخوَّل وتُخزَّن وتُعاد إلى العميل. أمّا الطلباتُ اللاحقة للاستعلام نفسه من أيّ عميلٍ يخدمه المحلِّل المحلّي، فيمكن الآن تقديمُها من ذاكرة المحلِّل دون حدوث الخطوتين 2 و3.

الشكل 29. مهاجمٌ يسمّم ذاكرة DNS المؤقّتة.

يعتمد هجومُ تسميم الذاكرة المؤقّتة على إدخال معلوماتٍ كاذبة إلى ذاكرة خادمٍ مؤقّتة، حيث ستبقى هناك حتى تنتهي مدةُ البقاء (time to live, TTL) لتلك المعلومات. وكثيرًا ما يكون TTL بحجم الساعة تقريبًا. وهناك طرقٌ كثيرةٌ لفعل ذلك؛ وسنرسم احتماليةً واحدة.

ولنفترض أنّ المهاجمَ قادرٌ على رؤية طلب العميل (1) في الشكل 28، ربما بالتجسّس على شبكة WiFi مفتوحة. فيستطيع المهاجمُ الآن أن يغرق المحلِّلَ بنسخٍ مزوَّفةٍ من الاستجابة المتوقَّعة (3)، أملًا في أنّ كثرةَ المحاولات تكفي لتوليد استجابةٍ يقبلها المحلِّل. وحقلُ ID في ترويسة DNS حقلٌ بعرض 16 بت، ومنفذُ UDP الخاصّ بـ DNS قيمةٌ معروفةٌ جيدًا، ولذلك لا توجد سوى $2^{32}$ تركيبةً ممكنةً من ID ومنفذ UDP للعميل لفائدة عميلٍ وخادمٍ معيّنين. وهذا يجعل هجماتِ القوّة الغاشمة ممكنةَ التطبيق.

وحتى مع انعدامِ رؤيةِ حركة العميل، يستطيع المهاجمُ إجبارَ المحلِّل على إجراء استعلاماتٍ إلى example.com بإرسال استعلاماته الخاصة، ثمّ إرسال فيضِ الاستجابات لانتحال صفة الخادم المخوَّل. وإن نجح ذلك، تُركت البيانات المزوَّفة في الذاكرة المؤقّتة حتى انتهاء مدّتها. وسيتلقّى بقيةُ عملاء المحلِّل الآن النتيجةَ السيّئة من الذاكرة. وهناك تنويعاتٌ كثيرةٌ لهذا النوع من الهجوم، جُمعت على نحوٍ واسع في RFC 3833 الذي يحلّل التهديدات التي يواجهها DNS.

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

قراءات إضافية

L. Peterson وB. Davie. شبكاتُ الحواسيب: مقاربةُ الأنظمة. خدمةُ الأسماء (DNS).

D. Atkins وR. Austein. تحليلُ التهديدات لنظام أسماء النطاقات (DNS). RFC 3833، أغسطس 2004.

مجهول. الأضرارُ الجانبيةُ للرقابة على الإنترنت بحجب DNS. Computer Communications Review، يوليو 2012.

8.2.1 هجماتُ تكبير DNS

هناك صنفٌ من هجمات حجب الخدمة (denial-of-service, DoS) يستغلّ خصائص DNS لشنّ هجماتٍ على أنظمةٍ أخرى، بدلًا من أن يكون هجومًا على DNS نفسه. وتذكّر أنّ DNS يقوم على UDP. ففرسل خادمُ الأسماء استجابةً إلى عنوان IP الذي أُرسل منه الاستعلام، وبما أنّه لا وجود لاتصال TCP يُنشَأ، فإنّ استعمالَ عنوان مصدرٍ مزيَّفٍ في الاستعلام أمرٌ سهلٌ نسبيًّا. وهكذا يمكن خداعُ خادم الأسماء ليُرسل الحركةَ إلى مضيفٍ بغير حذر. ومن السهل أن نرى كيف يمكن تحويلُ ذلك إلى هجوم حجب خدمةٍ موزّع: فبالإمكان لعدة مضيفات (مثلًا مجموعةٍ من المضيفات في شبكةِ برامجِ تجسس) أن تُجري طلباتٍ منسَّقةً إلى مجموعةٍ من خوادم الأسماء، مع استخدام العنوان المزيَّف نفسه في الطلبات جميعها. ولا يقتصر هذا الأمر على توجيه كمّيةٍ كبيرةٍ من الحركة إلى العنوان الهدف، بل يمكن أيضًا جعلُ خوادم الأسماء تؤدّي وظيفةَ تكبير للحركة (traffic amplification)، لأنّ الاستجابةَ لاستعلام DNS قد تكون أكبرَ بكثيرٍ من الاستعلام الذي أثارها. وعلى وجه التحديد، فإنّ نوع استعلام DNS «ANY» يجعل كلَّ سجلّات النطاق تُعاد، وقد تكون هذه كمّيةً كبيرةً من البيانات تُعاد في استعلامٍ بسيط. وقد وُضّح مؤخّرًا في RFC معاملةُ هذه الاستعلامات على نحوٍ من شأنه أن يقلّل أثر استعلامات ANY، لكنّ ذلك ليس حلًّا كاملًا لهجمات تكبير DNS.

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

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

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

8.2.2 امتداداتُ أمان DNS (DNSSEC)

ولأنّ استعلامات DNS في التصميم الأصلي كانت مخططاتِ بياناتٍ UDP غيرَ مصادَق عليها وواضحةَ النصّ، فإنّ المقاربةَ الطبيعية لمنع الهجمات على DNS هي استعمالُ بعض التقنيات المبيَّنة في الفصل 5 لمصادقة استجابات DNS. وهذا بالضبط ما تفعله أوّلُ محاولةٍ كبيرةٍ لتحسين أمن DNS، وهي امتداداتُ أمان DNS (DNS Security Extensions, DNSSEC).

وتشبه الخطوةُ الأولى في DNSSEC مقاربةً رأيناها مستعملةً في سياقاتٍ أخرى: وهي إنشاءُ سلاسلَ مفاتيحَ عموميةٍ موثوقةٍ باستعمال تسلسلٍ هرميٍّ للشهادات. وتذكّر أنّ في DNS لدينا علاقةٌ هرميةٌ قائمةٌ بين النطاقات، يقعُ النطاقُ الجذريُّ في قمتها، ومن ثمّ فإنّ من الطبيعيّ إنشاءَ تسلسلٍ هرميٍّ للشهادات يتبع التسلسلَ الهرميّ للنطاقات. وكتذكير، انظر مثالَ التسلسل الهرميّ الوارد في قسم DNS من كتابنا الرئيسي، وقد أُعيد هنا.

الشكل 30. التسلسلُ الهرميُّ لخوادم أسماء DNS.

ولنفترض مثلًا أنّ مسؤولَ نطاق princeton.edu يريد البدءَ في توقيع الاستجابات التي يُصدرها خادمُ الأسماء الذي يديره. عليه أن يحصل على شهادةٍ للمفتاح العامّ الذي ينوي استعمالَه، وستُصدر هذه الشهادةَ ويوقّعَها نطاق .edu. ويحتاج نطاق .edu بدوره إلى شهادةٍ لإثبات أنّ مفتاحَه موثوق، وتُصدر هذه الشهادةَ ويوقّعَها النطاقُ الجذريّ. وكما في أنظمةٍ أخرى مثل شهادات TLS، فإنّ إنشاءَ جذرِ الثقة يجب أن يتمّ عبر وسيلةٍ خارج النطاق. وثمّة في الواقع عمليةٌ رسميةٌ معقّدةٌ لتوليد المفتاح الجذريّ — مراسمُ توقيعٍ بمشاركةِ متعدّدِ المشاركين والمراجعين — تمكّن من الوثوق بمفاتيح النطاق الجذريّ.

ورغم وجود أوجهِ تشابهٍ واضحةٍ مع سلاسل الثقة المستعملة في TLS، فإنّ الفارقَ اللافت هنا هو أنّ سلسلةَ الشهادات التي يجب اتّباعها محدَّدةٌ بدقّةٍ بحسب التسلسل الهرميّ لـ DNS. فبينما يمكن أن تُصدر شهادةُ TLS مجموعةٌ من سلطات الشهادات، فإنّ شهادات أيّ نطاقٍ في DNSSEC يجب أن يُصدرها النطاقُ الأب. ولهذا بعضُ المزايا، مثل الحدّ من فرص السلوك السيّئ من جانب سلطات الشهادات الذي وقع أحيانًا مع شهادات TLS. غير أنّ هذا أيضًا يجلب نقطةَ ضعف: إذا لم يكن نطاقُك الأب، أو أيّ نطاقٍ في المسار بين النطاق طالبِ الشهادة والجذر، يستعمل DNSSEC، فإنّ هذا النطاق عاجزٌ عن استعمال DNSSEC. وبعبارةٍ أخرى، يبدأ DNSSEC من قمة التسلسل الهرميّ للنطاقات وينزل إلى الأوراق، وأيّ نطاقٍ على هذا المسار يفشل في تنفيذ DNSSEC يمنع أبناءَه من تنفيذه. فمثلًا، بالاستناد إلى الشكل أعلاه، إذا لم ينفّذ princeton.edu تطبيقَ DNSSEC، فحظُّ قسم الحاسوب في حوزته ضئيلٌ إن أراد تنفيذه، إذ لا يمكنه أن يُوقَّع مفتاحُه من قِبل النطاق الأب.

ولنأخذ مثالًا من العالم الحقيقيّ على استعمال DNSSEC، فقد جعلنا النطاق systemsapproach.org يستعمل DNSSEC. وللتحقّق من أنّه يعمل فعلًا، استعملنا الأداةَ مفتوحةَ المصدر DNSviz للتحقّق ممّا إذا كان نطاقُنا موقَّعًا على نحوٍ صحيح. وتُنتج DNSviz تقريرًا تفصيليًّا يمكن التقاطُه بيانيًّا، كما هو مبيَّن في الشكل 31. وأبرزُ ما يُلاحَظ في هذا الشكل هو التسلسلُ الهرميُّ ذو الطبقات الثلاث من النطاق الجذريّ إلى نطاق .org إلى نطاق systemsapproach.org، حيث يوقّع النطاقُ الأب مفتاحَ النطاق الابن، بحيث يمكن لمحلّلات DNS بعدها التحقّقَ من تواقيع النطاق الابن.

الشكل 31. التحقّقُ من مفاتيح DNS وتواقيعها بواسطة DNSviz.

إنّ اشتراطَ التنفيذ في كلّ مستوىٍ من الجذر إلى الورقة يُعدّ أحدَ العوائق أمام تبنّي DNSSEC التي أشار إليها مقالٌ لجيف هَستن (Geoff Huston) من APNIC حول ضعف انتشار هذه التقنية (انظر «قراءات إضافية»). ومعه أنّ العمل على تأمين DNS جارٍ منذ أكثر من ثلاثين سنة، ولم يبلغ انتشارُه 40% بعد (استنادًا إلى قياساتٍ أوردتها APNIC وInternet Society)، فمن المعقول أن نسأل هل هو أرجحُ يومًا ما في أن ينجح. ويشير هَستن إلى أسبابٍ أخرى عدّة ت نجاحَه، وليس أقلّها أنّ TLS، وإن كان يحلّ مشكلةً مختلفة، يتجاوز نوعًا ما الحاجةَ إلى التحقّق من DNS. فإذا كنت تعرف أنّك متّصلٌ بالموقع الصحيح عبر HTTPS لأنّه أثبت هويّتَه بشهادة TLS تثق بها، فهل يهمّك حقًّا أيُّ عنوان IP استخدمته البروتوكولاتُ الأساسية لوصولك إلى الموقع؟

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

وتُجسّد تحدّياتُ تأمين DNS نقطةً أثَرنا إليها في مطلع الكتاب بشأن قاعدة الحوسبة الموثوقة (trusted computing base, TCB) وتقليص حجمها. فإذا كان يلزم الوثوقُ بـ DNS كي تعمل الأنظمةُ المعتمِدة على الإنترنت بأمان، فإنّنا قد اخترنا مكوّنًا من مكوّنات نظامٍ كبيرٍ موزّعٍ يحتاج إلى تأمين. ولأنّنا لم نفلح إلى حدٍّ بعيدٍ في جعل DNS آمنًا على مدى ثلاثين سنة، فإنّه من حسن الحظّ أنّ TLS (وأنظمةٌ أخرى تستعمل التشفير من الطرف إلى الطرف) يوفّر اتصالاتٍ آمنةً فوق بنيةٍ تحتيةٍ غير موثوقة. وبعبارةٍ أخرى، فإنّنا قد استثنينا DNS من TCB.

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

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

قراءات إضافية

G. Huston. هل حانَ وقتُ وضع حدٍّ لـ DNSSEC؟. مدوّنة APNIC، مايو 2024.

8.2.3 DNS المُعمّى (DoH وDoT وODNS)

ومعي انتشارِ TLS لتشفير حركة HTTP والمصادقة عليها، كما ناقشنا في الفصل 6، فلا ينبغي أن يدهشنا وجودُ عدّة طرائقَ معيارية الآن لإرسال استعلامات DNS واستجاباتها عبر قنواتٍ محميّةٍ بـ TLS. وقد تعدّدت المقترحاتُ المتشابهةُ لتحقيق هذه النتيجة، حيث قيّدت IETF معيارَ كلٍّ من DNS فوق TLS (DoT) في RFC 7858، و DNS فوق HTTPS (DoH) في RFC 8484. وهناك بعضُ الجدل حول مزايا كلٍّ منهما، لكنّ الفروق بينهما ليست كبيرةً جدًّا لأغراض نقاشنا.

والفكرةُ الأساسية وراء المقاربتين بسيطةٌ بما يكفي. فبدلًا من إرسال استعلامات DNS واستجاباتها بوصفها مخططاتِ بياناتٍ UDP نصًّا صريحًا، ينشئ عميلُ DNS اتصالَ TLS أو HTTPS مع محلِّل DNS، ثمّ يُصدر استعلاماته بوصفها طلباتٍ داخل تلك القناة المشفَّرة. أمّا تفاصيلُ كيفية ترميز الطلبات والاستجابات فهي مبيَّنةٌ في وثائق RFC، ولا نحتاج إلى التوقّف عندها هنا.

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

وهناك خطرٌ أمنيٌّ بارزٌ آخر لا تعالجه أيٌّ من المقاربات التي ناقشناها حتى الآن هو خصوصيةُ العميل الذي يُرسل الاستعلامات. فالمحلِّلُ لديه وصولٌ إلى جميع طلبات العميل بصيغتها غير المشفَّرة، وهو ما يبدو شرطًا لخدمتها. لكنّ هناك جهودًا أُبذلت لتحسين خصوصية طلبات العميل باستعمال تقنيةٍ تُعرف بـ DNS الغافِل (Oblivious DNS).

الشكل 32. DNS الغافِل.

وتتمثّل الفكرةُ المركزية في DNS الغافِل في إخفاء هوية العميل عن المحلِّل. ويُتحقَّق من ذلك بالاستناد إلى DoH لتشفير الطلبات القادمة من العميل والاستجابات المُرسَلة إليه، مستعملًا مفتاحًا مرتبطًا بالهدف. لكن بدلًا من إرسال الاستعلامات مباشرةً إلى الهدف كما في DoH القياسية، يُدخل DNS الغافِل وكيلًا (proxy) بين العميل والهدف. فيتلقّى الوكيلُ طلبًا مشفَّرًا لا يستطيع تفسيره، ثمّ يمرّر الطلبَ إلى الهدف. ويستطيع الهدفُ فكّ تشفير الطلب، لكنّه لا يعرف أيُّ عميلٍ أرسله، ويرسل استجابةً مشفَّرةً إلى الوكيل. وما دام الوكيلُ يدعم مزيجًا من العملاء، وما دام الوكيلُ والهدفُ لا يتواطآن، فلا يملك أيٌّ منهما المعلومات اللازمة لمعرفة ما يطلبه عميلٌ بعينه.

وإنّ DNS الغافِل بروتوكولٌ تجريبي، لكنّ بعضَ عمليات النشر موجودةٌ بالفعل لكلٍّ من سلوك الوكيل وسلوك الهدف. ومن اللافت أنّ Apple بنت خدمةً تركّز على الخصوصية تجمع بين DNS الغافِل وعدّة تقنياتٍ أخرى لدعم التصفّح الخاص. كما أنّ مشغّلي شبكات التوزيع الكبيرة (CDN) مثل Cloudflare يوفّرون دعمًا لوظيفة الهدف.

قراءات إضافية

Z. Hu وآخرون. مواصفةُ DNS فوق طبقة أمان النقل (TLS). RFC 7858، مايو 2016.

P. Hoffman وP. McManus. استعلاماتُ DNS فوق HTTPS (DoH). RFC 8484، أكتوبر 2018.

P. Schmitt وA. Edmundson وA. Mankin وN. Feamster. DNS الغافِل: خصوصيةٌ عمليةٌ لاستعلامات DNS. وقائعُ ورشةِ أبحاثِ الشبكات التطبيقية لعام 2019، 2019.

8.3 التخفيفُ من حجب الخدمة

ركّزنا في معظمِ هذا الكتاب على الهجمات التي تستهدف سرّيةَ المعلومات أو سلامتها، لكنّنا نحتاج أيضًا إلى الاهتمام بالتوافر (availability). وهذا ينطبق على الأنظمة الطرفية (مثل مواقع الويب) وعلى البنية التحتية للشبكة نفسها. وتُعرف هذه الهجمات عادةً باسم هجمات حجب الخدمة (Denial of Service, DoS)، وهي تتضمّن عادةً خصمًا يحاول إرهاقَ مواردَ «جيدة» (عرض نطاق الوصلة، ومعدّلات تمرير الحزم، وإنتاجية استجابة الخادم) بحركةٍ تولّدها مواردُ «سيّئة» (مثل شبكاتِ برامجِ التجسّس المبنية من مجموعةٍ موزّعةٍ من الأجهزة المخترَقة). ويمكن أن تساعد رُقَعُ الإصلاح (patching) ونشرُ أجهزة الأمن مثل جدران الحماية في حماية الأجهزة من الاختراق في المقام الأول، لكنّها ليست كاملة — فالثغراتُ الجديدة تظهر باستمرار، والإنسانُ كثيرًا ما يكون أضعفَ الحلقات. ولهذا نحتاج أيضًا إلى وسائل للتخفيف من أثر هجمات حجب الخدمة الموزّع (Distributed DoS, DDoS). وهذه مثالٌ آخر على الدفاع متعدّد الطبقات: احمِ الأجهزة من الاختراق، واحمِ أيضًا من الهجمات التي تُطلقها الأجهزة المخترَقة.

ومراعاةً لأنّ حركة DDoS تبدو مشروعةً عادةً (فهي كثيرةٌ فحسب)، فإنّ تحدّي DDoS يُعالَج بتدبيرين عامّين. ولاحظ أنّ أبعد ما يمكن أن نأملَه هو التخفيفُ من أثر هذه الهجمات؛ فلا يوجد علاجٌ شامل. ومن السهل فهمُ ذلك بمستوى حدسي: فأيُّ أنظمةٍ ننشرها للدفاع عن هجمات حجب الخدمة تمثّل نوعًا من الموارد التي يمكن أن تُصاب هي الأخرى بهجوم حجب خدمة. ولهذا تميل حلولُ التخفيف من حجب الخدمة إلى أن تكون موزّعةً هي الأخرى.

والتدبيرُ الأول هو امتصاصُ الهجمات المحتملة بموارد أكبرَ حتى من التي يستطيع الخصمُ حشدَها. وبالنسبة إلى محتوى الويب، يُفعل ذلك بالآلية نفسها المستعملة لامتصاص موجات تدفّقٍ شرعيٍّ من الحركة: وهي شبكةُ توزيع المحتوى (Content Distribution Network, CDN). وتقوم الفكرةُ على نسخ المحتوى (سواء كان فيلمًا أو قطعةً حرجةً من بيانات البنية التحتية) عبر عدّة خوادم متباعدةِ التوزيع. فطالما كانت السعةُ الإجمالية لهذه الخوادم أكبرَ من السعة الإجمالية لشبكةِ برامجِ التجسّس — ووزّعت شبكةُ التوزيعِ الطلباتِ توزيعًا جيّدًا على الخوادم المتاحة — بقي المحتوىُ متاحًا. ويتجاوز هذا المفهومُ — مفهومَ السعةِ الإجمالية — خوادمَ الويب المستجيبَ لطلبات HTTP GET. فالشبكةُ بحدّ ذاتها مجموعةٌ موزّعةٌ من موارد التمرير والإرسال، صُمِّمت لتوزيع تلك الموارد توزيعًا يتجنّب نقاطَ الاختناق الهشّة. ويوضّح DNS هذا تمامًا: فهو نظامٌ موزّعٌ على نحوٍّ شديد مصمَّمٌ لتجنّب نقاطِ الفشلِ المفردة بالاعتماد على التكرار (redundancy) في جميع مستويات الهرم.

والتدبيرُ الثاني هو ترشيحُ الحركة الخبيثة في أبكر وقتٍ ممكن (قريبًا من المصدر). فإذا جاءت هجومُ حجب خدمةٍ من مصدرٍ واحد، فإنّه من السهل «حجبُ» الحركة من ذلك المصدر عند نقطةِ دخولٍ إلى شبكةٍ تتحكّم بها. ولهذا تكون هجماتُ حجب الخدمة موزّعةً عادةً. فإسقاطُ حزم الهجوم (أو تحديدُ معدّلها) عند الموجِّه الحدوديِّ لمزوّد خدمة (أو عند جدار حمايةٍ لمؤسسةٍ ما) أفضلُ من السماح لتلك الحزم بأن تغمر نواةَ الشبكة وتصل إلى خادمٍ ضحيّة، لكنّ كلّما كان محيطُ شبكتك موزّعًا على نطاقٍ أوسع، استطاعت ترشيحَ الحزم الخبيثة في مرحلةٍ أسبق. واستنادًا إلى التدبير الأول، كلّما كانت مواردُ شبكتك موزّعةً على نطاقٍ أوسع، ازدادت سعتُك الكلّيةُ في الترشيح. وتوفّر الشبكاتُ العامةُ المتداخلة (overlay networks)، التي تقدّمها شركاتٌ مثل Cloudflare وFastly، مزيجًا من توزيع المحتوى والترشيح الموزّع للحزم. وهذه منتجاتٌ تجاريةٌ فيها تفاصيلٌ محجوبةٌ كثيرة، لكنّ المبادئ العامة المبيَّنة هنا تشرح استراتيجيتَها الكامنة.

وأخيرًا، لاحظ أنّ هجمات حجب الخدمة تُبرز الطابعَ الدائمَ لمعالجة الأمن. فأيُّ بروتوكولٍ أو نظامٍ يكاد يكون هدفًا لهجوم حجب خدمة. وقد ناقشنا في القسم السابق دورَ DNS في تكبير هجمات حجب الخدمة. وحين تُطلَق الهجمات على مواقع الويب، فإنّ المهاجمين غالبًا ما يستغلّون بروتوكول HTTP — إذ تُستهلك مواردُ خادمٍ كبيرةٌ في الاستجابة لطلبات GET المزيَّفة. ومن مثالٍ مختلفٍ تمامًا، يمكن مهاجمةُ تمرير حزم IP بحزمةِ «شجرة الكريسماس» (Christmas Tree)، وهي حزمةٌ مُفعَّلةٌ فيها خياراتٌ متعدّدة (أي أنّها «مضاءةٌ مثل شجرة الكريسماس»)، حيث يحتاج كلُّ خيارٍ من هذه الخيارات أن ينفّذ IP تعليماتٍ ما كان سينفّذها لتوجيه حزمةٍ عادية. وبالموجِّهِ ذي التنفيذ الساذج لـ IP خطرُ ألّا يستطيع تمريرَ الحزم بالسرعة الخطّية إذا كان مشغولًا بمعالجة الخيارات. ولهذا السبب تنفّذ الموجِّهات عادةً «مسارًا سريعًا» (fast path) يستطيع اللحاقَ بالسرعات الخطّية، و«مسارًا بطيئًا» (slow path) يعالج الحزم الاستثنائية، وفوق كلّ ذلك تُحدِّد بسرعة أيَّ المسارين ينتمي إليه كلُّ حزمة. وهذه صيغةٌ من صيغ التدبير الثاني — قرّر مبكّرًا لحماية الموارد.

ومن الأمثلة المعروفة جيدًا «فيضانُ SYN» (SYN Flood) الذي يستهدف TCP، حيث يغرق المهاجمُ خادمًا بطلبات SYN من غير أيّ نيّةٍ في استكمال مصافحة TCP وإنشاء اتصالٍ فعلًا. وهذا يُرهِق جدولَ اتصالات TCP، وقد يحرم العملاءَ الشرعيّين من الاتصال. ونظامُ كشف التسلّل (انظر الفصل التالي) يمكن أن يساعد في حماية الخوادم، لأنّ فيفيض حزم SYN سلوكٌ شاذّ، لكنّ الخوادم الفردية تستطيع أيضًا الحدّ من الأثر بترميز حالة الاتصال في رقم التسلسل المُضمَّن في SYN+ACK الذي ترسله إلى العميل — وهو ما يشبه «كعكةَ SYN» (SYN cookie) — ثمّ تخصيص حالة الاتصال محلّيًّا فقط بعد أن يتكلّف العميلُ عناءَ إرسال ACK صحيح لتلك الحزمة. وهذه صيغةٌ من صيغ التدبير الأول، إذ إنّها تُجبر المهاجمَ على استعمال مواردَ إضافية.

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

قراءات إضافية

X. Qie وR. Pang وL. Peterson. البرمجةُ الدفاعية: استعمالُ أدواتِ التعليقاتِ لبناء برمجياتٍ مقاومةٍ لحجب الخدمة. وقائعُ الندوة الخامسة حول تصميم أنظمة التشغيل وتنفيذها (OSDI)، Usenix، ديسمبر 2002.

---

1. شكرٌ جزيلٌ لـ Cecilia Testart على مساهماتها في هذا الفصل، ولا سيّما قِسمَي BGP وأمن التوجيه (Routing Security). ↩︎