الخلاصة

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

حماية قناة التحكم لا تحدد مسار بيانات العميل

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

هذه زاوية مفيدة لقراءة RFC 5418، وهو تحليل معلوماتي نُشر عام 2009. يفحص المخاطر التي تظهر عندما تُقسّم نقطة الوصول المستقلة إلى عنصرين: Wireless Termination Point (WTP) عند الطرف اللاسلكي وAccess Controller (AC) في موقع آخر. تخرج تفاعلات كانت داخل جهاز واحد لتعبر شبكة من الطبقة الثالثة. ويعتمد الأمن، بحسب الوثيقة، على الشبكة الواقعة بين الطرفين وعلى كيفية توزيع الوظائف بينهما.

النطاق محدد: تحليل تهديدات CAPWAP مع IEEE 802.11. ليست الوثيقة مسحاً للمنتجات المنشورة أو تقريراً عن حادثة أو معياراً للإنترنت. قيمتها أنها تفصل أسئلة قد يخفيها الرسم المعماري: من هو الطرف الآخر؟ ما الدور المسموح له به؟ أي مفاتيح تصله؟ وأين تسلك بيانات العميل فعلياً؟

تستعير هذه المقالة منهجاً تحريرياً من الملاحظة 65 لهينغ لو، «Running-Code Primacy»: قارن الادعاءات بما تنفذه الأنظمة وما يستطيع المشغّل التحقق منه. تتناول تلك الملاحظة تصميم أنظمة تنسيق الإنترنت، ولا تضع متطلبات لأمن الشبكات اللاسلكية. هنا تعني ببساطة أن الرسم أو نص السياسة لا يحل محل دليل على بيانات الاعتماد والأدوار وعلاقات المتحكمات ومسار التمرير القائم.

CAPWAP يضيف علاقات ثقة جديدة

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

يتضمن المثال المبسّط في RFC 5418 سبع علاقات أو عمليات نقل للمفاتيح على الأقل:

الخطوة العلاقة أو النقل ما تثبته في المثال
1 WTP–AC علاقة نظير CAPWAP
2 AC–AAA اتصال موثّق بين المتحكم وخدمة المصادقة
3 المحطة–AAA مصادقة EAP وإنتاج مادة مفتاح
4 AAA → AC تسليم Pairwise Master Key إلى المتحكم
5 AC–المحطة مصافحة من أربع مراحل تنتج مفاتيح مؤقتة
6 AC → WTP تسليم مفتاح مؤقت عندما يكون التشفير موزعاً
7 WTP–المحطة حماية الوصلة اللاسلكية للعميل

ليس هذا تفاوضاً واحداً شاملاً من طرف إلى طرف. يوضح RFC 5418 أن كل علاقة ثنائية. ثقة المحطة بخادم AAA، وثقة AAA بـ AC، وثقة AC بـ WTP لا تعني تلقائياً أن على المحطة أن تثق بهذا WTP. قد يحافظ WTP مخترق على علاقته مع AC، وفي الوقت نفسه يقدّم معلومات مضللة للمحطة. ويمكن لجهاز مخترق في التسلسل الهرمي أن يؤثر في الأجهزة الواقعة تحته.

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

ماذا يثبت المفتاح المشترك، وما الذي لا يثبته؟

يميّز RFC 5418 بين المصادقة والتفويض. تسأل المصادقة ما إذا كان الطرف يستطيع إثبات هوية أو امتلاك بيانات اعتماد. أما التفويض فيحدد الموارد والعمليات المسموح بها لذلك الطرف.

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

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

تسمح الشهادات بفحوص أدق، لكن الوثيقة لا تعتبر مجرد تقديم شهادة سياسة تسجيل مكتملة. يناقش RFC 5418 اسماً للموضوع يتضمن عنوان MAC وحقول Extended Key Usage للتمييز بين دوري AC وWTP. لا تفيد هذه الفحوص إلا إذا تحقق الجهاز المستقبل من أن الاسم مقبول في هذا النشر وفرض الغرض الخاص بالدور بدقة. وقد يؤدي قبول غرض عام لاستخدام موسع إلى محو التمييز ما لم تُضف فحوص أخرى للاسم.

تثبت شهادة المصنّع جهة إصدار بيانات الاعتماد؛ لكنها لا تجيب عن سؤال العميل: أي AC يجب أن يقبله WTP في هذه الشبكة؟ وأي WTP ينتمي إلى هذا النشر؟ يذكر RFC 5418 صراحة أن التفويض بالشهادات والإعداد دون تدخل لا يتوافقان تماماً. ويفترض التحليل أن WTP يستطيع تحديد AC الصحيح وأن AC يستطيع تحديد WTPs الصحيحة؛ أما كيفية إنشاء هذا الاختيار فتقع خارج نطاقه. ينبغي إبقاء هذا الحد ظاهراً في الشراء ومراجعة الأمن.

AAA مسؤولية أخرى

في المثال المبسّط، يعمل AC كمصادِق ويتصل بخادم AAA عبر RADIUS أو Diameter. ويحذر RFC 5418 من أن بيانات الاعتماد طويلة الأجل إذا كانت غير فريدة أو ضعيفة العشوائية على وصلة AC–AAA قد تضر بأمن النشر كله. ويوصي بوصلة ذات مصادقة متبادلة وسرية وسلامة للبيانات، ويحيل إلى إرشادات إدارة مفاتيح AAA في RFC 4962.

تحمي هذه التوصية وصلة مختلفة عن WTP–AC. لا تتحقق جلسة DTLS الصحيحة بينهما تلقائياً من خادم AAA الذي اختاره المتحكم. كما أن استخدام EAP قوي بين المحطة وAAA لا يثبت أن المتحكم المقصود وحده سيتلقى مادة المفتاح الناتجة. ونجاح المصافحة اللاسلكية لا يثبت أن المفتاح وصل إلى WTP الصحيح. يحتاج المشغّل إلى تعيين مسؤول لكل بيانات اعتماد وقرار تفويض.

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

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

لا تكفي الهوية وتوزيع المفاتيح لوصف المعمارية. يميّز RFC 5418 بين رسائل التحكم وتمرير بيانات المستخدم، ويشرح أوضاع Split MAC وLocal MAC وغيرها. في Local MAC يتولى WTP معظم أعمال MAC، وتُجسر إطارات البيانات عادةً في الموقع. ولا تحدد مصطلحات CAPWAP وحدها كل اختيار لسلوك أنفاق البيانات.

يحدد RFC 5415 حدود البروتوكول: تمر رسالتا Discovery Request وDiscovery Response بلا DTLS كي يتمكن WTP من العثور على المتحكمات المرشحة؛ أما رسائل التحكم الأخرى فيجب أن تستخدم DTLS. وتظل حماية حزم البيانات اختيارية وتعتمد على سياسة AC. لذلك لا تثبت علاقة التحكم المحمية أن بيانات العميل تمر عبر AC أو تستخدم قناة بيانات محمية منفصلة أو تُمرر محلياً إلى الشبكة السلكية.

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

ولا يزيل التشفير كل التهديدات. يناقش RFC 5418 استنزاف الموارد والمراقبة السلبية وتحليل حركة المرور واعتراضاً يسبب إسقاط الحزم. كما يذكر هجمات خارج CAPWAP، مثل انتحال DNS أو DHCP وتسميم ذاكرة ARP المؤقتة. لا تقلل هذه الحدود من فائدة DTLS؛ بل توضّح أين تنتهي حمايته وأين يلزم مسؤول آخر.

مراجعة عملية تتبع العلاقات لا مربعات الاختيار

تبدأ مراجعة CAPWAP مفيدة من البنية الفعلية وتسأل:

  1. أي AC يقبله كل WTP؟ وكيف يُثبت أنه تابع لهذا النشر؟
  2. أي WTP يقبله كل AC؟ وكيف تُفصل أدوار الأجهزة؟
  3. هل المفاتيح المشتركة فريدة ومحدودة بما يكفي للفئة؟ ومن يستطيع الاطلاع عليها وتركيبها واستبدالها وإبطالها؟
  4. ما فحوص الاسم والدور التي يطبقها AC وWTP فعلياً؟ ماذا يحدث إذا كانت الشهادة صحيحة لكن الجهاز غائب عن قائمة النشر المسموح بها؟
  5. ما بيانات الاعتماد التي يستخدمها AC مع AAA؟ وأين يُسجل تسليم المفاتيح والتفويض به؟
  6. هل تمر بيانات العملاء عبر AC أم تُجسر محلياً؟ وأين يقع التشفير والتقسيم والفحص والتسجيل؟
  7. ما المخاطر الباقية رغم DTLS: استنزاف الموارد، تحليل الحركة، إسقاط الحزم، التلاعب بالاكتشاف أم استهداف LAN مجاورة؟

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

الحفاظ على حدود الوثيقة

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

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

المصادر