أصبحت وصلة العميل حدًا أمنيًا: RFC 2267 وBCP 38

الخلاصة

• اقترحت RFC 2267 فحص بادئة المصدر على الواجهة التي تستقبل حركة العميل لدى مزوّد الخدمة، حيث يمكن معرفة البادئات المسموح بها محليًا.
• جعل BCP 38 هذا الفحص ممارسة موصى بها في 2000، لكن اجتياز المرشح يحدد شبكةً أو وصلةً مرجحة ولا يعرّف الجهاز أو الشخص خلف الحزمة.

الضحية ترى العنوان ولا ترى المرسل

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

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

مزوّد الخدمة يعرف وصلة العميل

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

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

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

فحص البادئة ليس فحص مسار العودة

فرّقت RFC 2267 بين اقتراحها وفحص آخر: هل سيخرج المسار العائد إلى عنوان المصدر من الواجهة نفسها التي وصلت منها الحزمة؟ لم يوصِ المؤلفان بجعل ذلك قاعدة عامة، لأن عدم تماثل المسارات في الإنترنت سيجعلها إشكالية. أما اقتراحهما فيقارن بادئة المصدر بما يجوز للشبكة المتصلة بتلك الواجهة أن ترسله.

يعمل الفحصان عند المدخل، لكنهما يجيبان عن سؤالين مختلفين. يعتمد فحص العودة على اتجاه جدول التوجيه، بينما يعتمد مرشح العميل على النطاقات المصرّح بها على تلك الوصلة. تناولت RFC 3704 لاحقًا آليات الترشيح للشبكات متعددة الاتصال وحدّثت RFC 2827. أما طرائق RPF الصارمة والممكنة والمتساهلة ومفاضلاتها فهي موضوع مستقل، ولا تعيد هذه المقالة شرحها.

تنقّل الأجهزة أظهر موضع الاستثناء

قد يكون العنوان صحيحًا لجهاز متنقل، لكنه غير متوقع على الشبكة التي اتصل بها مؤقتًا. ذكرت RFC 2267 حالة Mobile IP: يمكن لحزمة صادرة من شبكة زائرة أن تحمل عنوان الجهاز في شبكته الأصلية، فيرفضها مرشح لا يسمح إلا ببادئة الشبكة الزائرة. أشارت المذكرة إلى النفق العكسي، الذي وصفته لاحقًا RFC 2344، لنقل الحزمة إلى وكيل المنزل قبل توجيهها إلى الإنترنت.

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

من مذكرة معلوماتية إلى BCP 38

صدرت RFC 2267 في يناير 1998 بصفتها وثيقة معلوماتية لا تحدد معيارًا للإنترنت. وفي مايو 2000، ألغت RFC 2827 الوثيقة السابقة وأبقت عنوان «Network Ingress Filtering»، لكن ضمن فئة أفضل الممارسات الحالية ورقم BCP 38. بقيت الفكرة الأساسية كما هي: يرشّح مزوّد الخدمة حركة العميل عند دخولها، كي لا تستخدم مصادر لم تستعملها شبكة العميل على نحو مشروع.

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

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

كان التحول التاريخي عمليًا ومحدودًا: لم تعد الضحية وحدها مطالبة بتفسير مصدر قد يكون كاذبًا. وضعت RFC 2267 فحصًا قابلًا للتحقق عند الحد بين مزوّد الخدمة والعميل، حيث يمكن حفظ علاقة البادئة بالوصلة وتطبيقها. أعطى BCP 38 لهذه الممارسة اسمًا مشتركًا. أما فعاليتها على وصلة معينة فظلت رهينة قاعدة محلية دقيقة ومثبتة وفعّالة.

المصادر

1. RFC 2267 — Network Ingress Filtering
2. RFC 2827 — Network Ingress Filtering (BCP 38)
3. RFC 1812 — متطلبات موجّهات IP الإصدار الرابع
4. RFC 2002 — دعم التنقل عبر IP
5. RFC 2344 — الأنفاق العكسية لـMobile IP
6. RFC 3704 — الترشيح في الشبكات متعددة الاتصال (BCP 84)