الخلاصة

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

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

في بيئة الاختبار توقف المحلّل بخطأ. في بيئة الإنتاج، كانت النسخة أقدم ولم تتحقق من كل قراءة. تحوّل ملف «التقاط» إلى قناة تنفيذ ضد خدمة التحليل نفسها.

لم يكن الخطأ أن LinkType غير صحيح. كان صحيحاً تماماً، ولذلك وصل الإدخال إلى الكود الذي أراده المهاجم.

هذه هي الحدود الأمنية التي يضعها مشروع Link-Layer Types for PCAP-related Capture File Formats. تحمل المراجعة 18 تاريخ 6 أبريل 2026 وتنتهي في 8 أكتوبر 2026. عند نقطة البحث في 3 أكتوبر، كانت Internet-Draft نشطة ضمن OPSAWG، ومقصوداً بها وضع Informational، وفي قائمة RFC Editor بانتظار أول محرر، من دون رقم RFC. تقدمها في المسار التحريري لا يثبت سلامة أي محلّل منشور.

يقترح المشروع سجلاً لدى IANA لقيم LinkType التي تستخدمها صيغتا PCAP وpcapng. القيمة غير الموقعة ذات 16 بت تختار واحداً من مئات تنسيقات البيانات الوصفية وتغليف الطبقة الثانية أمام الحزمة. إنها تجيب عن سؤال: ما القواعد التي ينبغي أن أستخدمها لفهم هذه البايتات؟

ولا تجيب عن سؤال آخر: هل هذه البايتات جديرة بالثقة؟

كل تنسيق مسجل يوسّع سطح التحليل

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

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

مشروع PCAP-09 يطلب التحقق من رأس الملف، ورؤوس سجلات الحزم، وكل البيانات التي يحللها القارئ وفق LINKTYPE. يمكن أن تكون الرؤوس أو الحزم مشوهة عمداً. الاعتراف بالرقم لا يلغي هذا الالتزام؛ بل يحدد مجموعة إضافية من الحدود التي يجب فحصها.

الاقتطاع حقيقة في الدليل وحدّ في الذاكرة

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

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

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

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

السجل ينسق رقماً ولا يعتمد برنامجاً

تُخصص القيم من 0 إلى 65000 عبر Expert Review وفق RFC 8126، بينما تُحجز 65001 إلى 65535 للاستخدام التجريبي. تبقى القيم الخاصة التاريخية 147 إلى 162 مدعومة، لكن الاستخدامات الجديدة ينبغي أن تختار المجال التجريبي.

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

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

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

العزل ليس بديلاً عن الدقة، بل شرط لها

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

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

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

الاختبار الذي يهم هو اختبار الحدود

تقتضي أولوية الكود العامل ألا نكتفي بملف نموذجي سليم. ينبغي توليد حقول طول تتجاوز البايتات الفعلية، وحسابات تفيض، وحزم مقتطعة عند كل حد مهم، وSections تعيد استخدام Interface ID، وقيمة DLT تُحوَّل خطأ، وقيم تجريبية متصادمة. ينبغي تشغيلها تحت أدوات كشف أخطاء الذاكرة وداخل العزل نفسه المستخدم في الإنتاج.

ثم نختبر لغة النظام: هل يقول «تعذر التحليل»، أم يملأ حقولاً افتراضية؟ هل يميز «غير موجود في الجزء المحفوظ» عن «غير موجود في الحزمة»؟ هل يربط فشل المحلّل بالنسخة والتعريف، أم يعيد كتابة الملف كأنه دليل سلبي؟

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

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

المصادر