الخلاصة

  • جعل RFC 742 السطر الذي لا يحتوي إلا على CRLF طلباً لقائمة كل الموجودين على النظام، مع الأسماء ومواقع الطرفيات وإمكان إضافة العمل ومدة الخمول.
  • أبقى RFC 1288 تبادل TCP ذي السطر الواحد، لكنه ألزم الخادم بالجواب أو الرفض الصريح للقائمة العامة والتمرير، وأوصى بأن يختار المسؤول كل ذرة معلومات تُكشف.
  • نسّق المنفذ 79 موضع السؤال فقط. لم يوثّق الشخص أو صدق الرد، ولم يمنح طالب المعلومة حقاً فيها، ولم يجعل النص الموجّه للبشر آمناً تلقائياً عند عرضه.

كان الفراغ أوسع أمر ممكن

وصف RFC 742، المؤرخ في 30 ديسمبر 1977، خدمة بسيطة: الاتصال بالمقبس 117 بالثماني، أي 79 بالعشري، ثم إرسال سطر ينتهي بـCRLF، وتلقي تقرير يختلف حسب النظام قبل أن يغلق الخادم الاتصال.

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

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

نشأت الفكرة في مجتمع محدد. ذكر RFC 742 مواقع SAIL وSRI وأنظمة ITS، وربط برنامج FINGER الذي كتبه Les Earnest في SAIL ببرنامج NAME في ITS، ونسب تنفيذ البروتوكول إلى Earl Killian وBrian Harvey. داخل مجتمع بحثي صغير قد تبدو معرفة الحضور أداة تعاون.

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

النص البشري لم يملك حداً موحداً

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

طلب الرمز /W مزيداً من التفصيل. سماه النص القديم Whois switch، ثم صحح RFC 1288 موضعه إلى بداية الاستعلام. يستطيع آخر RUIP زيادة الإسهاب أو تجاهل الطلب. لم تكن هناك طبقة توثيق ثانية تبرر الحصول على تفاصيل أكثر.

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

سهولة القراءة لا تعني توحيد المعنى. قد يقيس idle آخر ضغطة في نظام ونشاط المهمة في آخر. وقد يعني غياب السطر أن لا أحد موجود، أو أن الخادم لا يعرف، أو أن السياسة تحجب. الرد هو عرض محلي لحالة المضيف، لا قياس عالمي.

جعل الرفض جواباً غيّر معنى الصمت

نشر RFC 1196 في ديسمبر 1990 بناء على سلوك BSD الشائع. حاول التوضيح من دون كسر تطبيقات كثيرة، وصرّح بأن غرض البروتوكول—إرجاع معلومات عن مستخدمي النظام—حساس في ذاته.

وفي ديسمبر 1991 صحح RFC 1288 موضع /W والمسافات وإغلاق الاتصال. بقيت الآلية: TCP 79 وASCII وسطر CRLF وجواب ثم إغلاق. التحول الأهم كان إظهار قرار السياسة كحالة مستقلة.

عند استعلام {C} الفارغ، يجب على الخدمة الإجابة أو الرفض الفعّال. إن أجابت أعادت الأسماء الكاملة على الأقل، وينبغي أن يستطيع المسؤول اختيار إضافة الطرفية والمكتب والهاتف والمهمة ومدة الخمول. وإن عطل القائمة، يستطيع قول إنه يرفضها بدلاً من التظاهر بأن لا أحد متصل.

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

وأوصى RFC 1288 بالتحكم الذري في الحقول. قد يكشف مسؤول هواتف وأوقات login، ويقتصر آخر على المكتب والهاتف المهني، ويقف ثالث عند الاسم الأدنى. القواعد المشتركة لم تعد تعني حزمة مشتركة من البيانات الشخصية.

التمرير غيّر من يستطيع الوصول إلى من

يسمح Q2 بسلسلة @hostname. يفتح RUIP الأول اتصال Finger آخر، ويرسل بقية السؤال، ثم يعيد الجواب إلى المصدر. لا تفرض القواعد حداً اعتباطياً لعدد المضيفين.

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

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

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

أعطى plan حق الكتابة ولم يعط حق تحديد كل القراء

منح plan المستخدم صوتاً مباشراً: ساعات، سفر، مشروع، وسيلة اتصال. لكن الكاتب لا يرى بالضرورة كل من يستطيع سؤال الخدمة. تأليف المحتوى وتوزيعه سلطتان مختلفتان.

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

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

هناك ثلاث مسؤوليات: يكتب المستخدم، ويحدد المشغل ما يخرج من المضيف، ويقرر العميل كيف يعرض. موافقة واحد لا تنوب عن الآخرين.

النص الموجه للبشر بقي إدخالاً غير موثوق

أوصى RFC 1288 بأن يرشح العميل افتراضياً المحارف غير القابلة للطباعة، ويترك ASCII المرئي وtab وCRLF. فقد تغير escape sequences اسم نافذة X أو تنفذ آثاراً مربكة في طرفية القارئ.

وعند الإرسال، سبق أن نبه RFC 742 إلى أن عميل Telnet عاماً قد يضيف تفاوض IAC فيفسد سطر Finger. حمل النص لا يجعل بروتوكولين متكافئين في أوامرهما الخفية.

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

صلابة البرنامج وتقليل الإفشاء دليلان منفصلان

استشهد RFC 1288 بدودة Morris ليضع Finger عند محيط أمان المضيف إلى جانب Telnet وFTP وSMTP. حتى daemon صغير يحتاج مقاومة المدخلات المشوهة واختبار الاختراق.

ومع ذلك قد يكون البرنامج سليماً ويقول أكثر مما ينبغي. ذكر RFC تطبيقاً يعيد آخر login وآخر قراءة للبريد ووجود بريد غير مقروء ومرسل أحدث رسالة. يستطيع المراقب تتبع المحادثات وموضع الانتباه بلا استغلال برمجي.

وبالعكس، قلة الحقول لا تثبت أمان الكود. parser والتمرير والبرامج ومحارف التحكم تحتاج اختبارات مستقلة. حماية العملية وتقليل البيانات يكمل أحدهما الآخر ولا يستبدله.

يوفر سجل الاستعلامات دليلاً على التعداد والأسماء المتكررة و/W وQ2. لكنه يسجل أيضاً اهتمام أشخاص بأشخاص، فيحتاج غرضاً ومدة وصول وحذف خاصة به.

حفظت IANA العنوان ولم تمنح حق المعرفة

يسجل سجل IANA لأسماء الخدمات وأرقام المنافذ finger على المنفذ 79 في TCP وUDP، بينما يحدد RFC 1288 خدمة TCP. تحفظ الخانة موضع اللقاء التاريخي.

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

كان Finger يعرض رؤية لحظية لجلسات المضيف، ومعها أحياناً وصف ذاتي. لم يكن بيان هوية موقعاً ولا سجلاً إدارياً ذا تاريخ تغييرات.

نجا السؤال حين فقد سلطته الافتراضية

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

بقي الاستعلام العام مع إمكان رفضه. بقي التفصيل مع اختيار حقوله. بقي التمرير مع توصية المنع. بقي plan من دون أن يساوي التأليف توزيعاً بلا حد. بقي النص الحر مع ترشيح العميل.

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

المصادر وحدود الدليل

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