Summary

  • فصل RFC 2979 بين رفض أمني مقصود وبين إخفاق غير مقصود لاستخدام متوافق؛ وفي الحالة الثانية تقع مسؤولية الإصلاح على الجدار الناري والبرمجيات المرتبطة به.
  • أوضحت أمثلة اكتشاف MTU وامتدادات SMTP كيف يستطيع وسيط قطع محادثة كاملة أثناء تطبيق قاعدة تبدو بسيطة.

رفض السياسة ليس عطل البروتوكول نفسه

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

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

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

حذف خطأ ICMP قد يحول مساراً صالحاً إلى ثقب أسود

جعل مثال اكتشاف Path MTU القاعدة ملموسة. في IPv4 يستطيع المرسل ضبط بت Don't Fragment. وإذا لم يستطع رابط لاحق نقل الحزمة، يعيد موجّه رسالة ICMP من نوع “Destination Unreachable / Fragmentation Needed” لكي يخفض المرسل حجم الحزم. أما الجدار الذي يسمح بالخروج ثم يحذف الرد المطابق، فيجعل المرسل يعيد حركة أكبر من اللازم مراراً: ثقب أسود، لا قراراً أمنياً مفيداً.

لم يطلب RFC 2979 السماح بكل ICMP. فقد ميز الخطأ المرتبط بحركة مشروعة صادرة عن رسائل Echo أو Redirect أو أخطاء لا صلة لها، وهي أمور يمكن للسياسة حجبها. السياق مهم: تحتوي عائلة البروتوكول نفسها معلومات تحكم لازمة لتبادل صالح وأخرى يمكن رفضها.

قائمة امتدادات SMTP صنعت عدم توافق بين ثلاثة أطراف

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

لم تكن العبرة أن يطبق كل جدار ناري كل امتداد جديد. أوصى RFC 2979 بأن تسهل بروتوكولات التطبيقات العمل عبر الجدران ما دام ذلك لا يضر بالتطبيق. كما حذر من تغليف بروتوكول جديد داخل HTTP لمجرد توقع فتح المنفذ 80؛ فقد يكون النطاق الفرعي الآمن أو آلية عبور مناسبة أو منفذ منفصل مسجل خياراً أوضح.

ما الذي يثبته السجل وما الذي لا يثبته

RFC 2979 مذكرة Informational وليس معياراً للإنترنت. يسجل تاريخ المسودة موافقة IESG في أغسطس 2000 ثم نشر المذكرة في أكتوبر. وهذا يثبت وجود مبدأ تصميم وأمثلة، لا معدل اعتماد في المنتجات ولا امتثالاً تنفيذياً ولا تراجعاً في التحايل ولا تحسناً أمنياً مقاساً.

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

أما RFC 3093 فهو وثيقة مجاورة مختلفة: نشرت في 1 أبريل 2001 واقترحت Firewall Enhancement Protocol لنقل IP/TCP داخل HTTP. لا تثبت أن RFC 2979 أخفق أو أن النفق انتشر. وكذلك لا ينبغي الخلط بين التصفية وNAT؛ فقد فصل RFC 2979 صراحة بين الوظيفتين حتى إن جمعهما جهاز واحد.

المصادر: RFC 2979؛ RFC 2775؛ RFC 3093؛ تاريخ المسودة؛ RFC 1191؛ RFC 1869.