ردّ الخادم من دون أن يعطي الوقت: حدود «قبلة الموت» في NTP

الخلاصة

• حزمة Kiss-o’-Death ليست عينة وقت ضعيفة؛ يكون stratum فيها صفراً، وتصبح طوابع الاستقبال والإرسال غير محددة ويجب طرحها، فيما يحمل المعرّف ذا الأحرف الأربعة حالة العلاقة.
• لا يستطيع الخادم فرض DENY أو RSTR أو RATE على برنامج بعيد. صلاحية Origin Timestamp، والمصادقة حين تتوافر، والسقف المحلي، والفعل الذي نفذه العميل فعلاً، كلها أدلة منفصلة.

يمكن لحزمة أن تجيب عن سؤالين مختلفين تماماً. الرد العادي في NTP يقدم مادة لحساب الوقت. أما Kiss-o’-Death، أو KoD، فيقول إن الخادم لن يقدم تلك المادة، ثم يقترح ما ينبغي أن يفعله العميل بعلاقته معه. التشابه في شكل الحزمة لا يجعل نوعي الدليل متساويين.

هذه المسافة بين «وصل رد» و«وصل وقت» هي التي حفظت للعميل قراره المحلي. وهي أيضاً التي جعلت الآلية عرضة للتجاهل وسوء التنفيذ والتزوير.

وُجد الحقل قبل أن توجد دلالته الجديدة

حدد RFC 1305 عام 1992 حقل Stratum بثماني بتات وReference Identifier بأربعة أوكتات. كان stratum 0 «غير محدد»، وكان المعرّف في المستويين صفر وواحد يعرض كأربعة محارف ASCII. واحتفظ RFC 2030 بهذا الشكل في SNTPv4 عام 1996.

لكن الوثيقتين لم تعرفا KoD. لا تكفي مساحة فارغة في بنية الحزمة لصنع اتفاق أو سلطة. جاء RFC 4330 عام 2006 ليذكر أن دلالة Reference Identifier عند stratum 0 لم تكن محددة، وليجعله رمزاً للحالة والتحكم في الوصول والمعدل.

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

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

الصفر أخرج الحزمة من قياس الوقت

أدخل RFC 5905 الآلية في NTPv4. عند stratum 0 لا تصلح الحزمة للمزامنة، ويُقرأ Reference Identifier بوصفه kiss code. كما أن Receive Timestamp وTransmit Timestamp في KoD غير محددين ويجب التخلص منهما.

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

DENY وRSTR يطلبان تفكيك الارتباط والكف عن الإرسال إلى الخادم. RATE يطلب إطالة فترة الاستطلاع لتقليل الطلبات. أما INIT وSTEP في RFC 4330 فيصفان حالات مؤقتة. هذه الرموز تسمي انتقالات محددة، ولا تثبت أن سياسة المنع عادلة أو أن صاحب الرمز هو الخادم الصحيح.

صحح erratum اتجاه حلقة التحكم

قال النص المنشور من RFC 5905 في البداية إن على العميل الذي يستقبل RATE أن يقلل فترة الاستطلاع. تقليل الفترة يزيد عدد الحزم، أي إنه يضاعف الضغط الذي تحاول الرسالة خفضه. صحح Errata 3007 الموثق العبارة: ينبغي زيادة الفترة.

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

وهنا تظهر طبيعة KoD التعاونية. لا ينفذ الخادم تعليمة داخل العميل. برنامج قديم قد يتجاهلها، وآخر معيب قد يسرّع، وبرنامج مطيع بلا حدود قد يقبل تأخيراً ضاراً.

مطابقة الطلب لا تثبت هوية الخادم

يشترط RFC 8633 ألا يقبل العميل KoD إلا إذا كان Origin Timestamp صالحاً ويطابق طلباً ما زال معلقاً. يمنع هذا الردود القديمة أو غير المطلوبة من تغيير الحالة بسهولة.

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

لا يحتاج المهاجم إلى تزوير الساعة. DENY مزيف يزيل مصدراً صالحاً، وRATE مزيف يؤخر جمع العينة التالية. إنه يتحكم في توقيت البحث عن الدليل وفي الجهة التي يُطلب منها.

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

أبقى العميل حداً لمستقبله

حتى رسالة RATE الصحيحة لا ينبغي أن تضبط المؤقت بلا سقف. قد يصمت عميل يقبل قيمة poll ضخمة زمناً طويلاً بسبب خطأ أو تزوير. يذكر RFC 8633 سقفاً معقولاً لا يزيد فيه أس poll على 13، أي قرابة ساعتين.

يعرف الخادم ضغطه، لكن العميل يعرف حاجته إلى الاستمرارية وتنوع المصادر. يسمح له التصميم بالتراجع ضمن حد، لا بتسليم جدول طلباته كله للطرف الآخر.

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

NTSN استثناء ضيق عند انهيار حالة الحماية

تضيف Network Time Security حماية للتبادل العادي، لكنها تواجه مفارقة: إذا عجز الخادم عن التحقق من cookie أو authenticator لدى العميل، فلن يستطيع إنتاج الرد المحمي المعتاد الذي يشرح الفشل.

يعرف RFC 8915 الرمز NTSN لهذه الحالة. يرسل الخادم KoD من دون NTS Cookie ومن دون NTS Authenticator and Encrypted Extension Fields. وإذا كان العميل قد تلقى سابقاً ردوداً موثقة، فيشترط Unique Identifier يطابق طلباً معلقاً، وإلا طرح الرسالة.

حتى مع المطابقة لا يبدأ العميل فوراً حلقة تبادل مفاتيح. ينتظر موعد الاستطلاع الطبيعي التالي؛ فإن لم يصل رد محمي صالح، يعيد NTS-KE مع تقييد معدل المحاولات، ويواصل استعمال معلماته القديمة حتى ينجح الإعداد الجديد.

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

سجل الرموز لا يمنحها سلطة تشغيلية

أنشأ RFC 5905 سجلاً لدى IANA لتجنب أن تمنح مواصفات مختلفة الرمز القصير نفسه معاني متعارضة. وحدّث RFC 9748 القواعد عام 2025: حتى أربعة محارف ASCII، وحشو بأوكتات صفرية للرمز الأقصر، وحجز البادئة X للتجارب، واستخدام الحروف اللاتينية الكبيرة والأرقام للتسجيلات الجديدة وفق Specification Required.

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

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

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