Gluon: تحديث موقع العقدة أثناء التشغيل العادي

تم إنشاؤها على ١٣ فبراير ٢٠١٤  ·  14تعليقات  ·  مصدر: freifunk-gluon/gluon

بالأمس ، كنت أتحدث مع خبراء الشحن المجاني الآخرين حول ميزات Gluon الجديدة. لقد استنتجت أن عدم القدرة على تحديث موقع العقد عن بُعد يمثل مشكلة كبيرة. هذا يرجع أساسًا إلى اختلاف سير العمل الفعلي لإعداد العقد عما توقعناه.

عدم تطابق سير العمل

يبدو سير العمل المتوقع كما يلي:

  1. يريد المستخدم إعداد عقدة جديدة ،
  2. يفكر بالضبط في مكان وضعه ويسترجع إحداثيات WGS84 لهذا الموقع ،
  3. تثبيت البرامج الثابتة ،
  4. زيارات configmode ،
  5. يحدد الموقع ،
  6. الأماكن في الموقع المذكور ،
  7. يرسل المفتاح العام إلى المجتمع.

ومع ذلك ، يبدو أن سير العمل الأكثر شيوعًا هو:

  1. يريد المستخدمون إعداد عقدة جديدة ،
  2. تثبيت البرامج الثابتة ،
  3. زيارات configmode ،
  4. يرسل المفتاح العمومي ،
  5. يفكر في مكان وضعه ،
  6. يضع العقدة في الموقع المطلوب.

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

الحل المقترح

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

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

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

لن يسمح بتغيير كلمة السر نفسها. وبالتالي ، لن يتمكن المهاجم من قفل العقدة في موقع ما بعد اكتساب المعرفة بكلمة الرمز. مرة أخرى ، تم فرض configmode.

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

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

شكرًا على القراءة ، وشكرًا لـ Linus وكل شخص آخر تحدثت إليه بخصوص هذه المشكلة على مساهماتهم! واسمحوا لي أن أعرف ما هو رأيك في هذا في التعليقات.

(هل ذكرت أن الحالة ستكون قادرة على إظهار خريطة حتى يتمكن المستخدم من وضع عقدة دون معرفة WGS84؟)

enhancement question

التعليق الأكثر فائدة

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

ال 14 كومينتر

من الجيد أنك ذكرت تلك النقطة الأخيرة بين قوسين ، لأنها أقنعتني. ؛-P

لقد أجريت لي أنا وTX نقاشًا كبيرًا حول وضع أجزاء التكوين في Statuspage على IRC وما زلت غير مرتاح للغاية لجعل صفحة الحالة للقراءة والكتابة وقائمة على النص (لأنه ، كما تعلم ، يفتح إمكانية وجود ثغرات أمنية). وما زلت أرى أكبر مشكلة في "كلمة المرور": سيقوم الأشخاص بإدخال كلمة المرور المعتادة بشكل أعمى ، بغض النظر عن حجم التحذير الكبير والبدين والجريء والوميض بعدم القيام بذلك. ويجب أن يصل إعداد كلمة المرور إلى وضع الخبير ، على ما أعتقد.

إذا تم تنفيذ ذلك ، فربما يكون من الممكن تنفيذ المصادقة باستخدام HTTP Digest؟ بهذه الطريقة سيتعين على المهاجم استخدام تقنية MITM بدلاً من الاستنشاق العادي.

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

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

مضغوط: نفِّذها ، لكن جهِّز حججك.

ملخص HTTP

أرغب في استخدام المصادقة القائمة على الملخص. للأسف ، uhttpd لا يدعمها.

مشاكل الأمان / إدخال الرمز

أنا متأكد من أنه يمكننا التعامل معها بشكل جيد. لم أسمع عن أي مشاكل في حقن الكود مع luci لذا ربما يكون هناك عدد قليل منها. يمكننا أيضًا تشغيل fuzzers لاختبارها.

كلمة المرور / كلمة مرور المستخدم

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

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

ارتباط بالعقدة

هذه في الواقع مشكلة لم تحل. يمكنني تخيل عرض عنوان IPv6 الخاص بالعقدة أسفل حقل إدخال كلمة المرور مباشرة ، مثل: "ضع إشارة مرجعية على هذا [الرابط] لتغيير إحداثيات العقدة بمجرد تشغيلها."

طلبات أخرى مماثلة

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

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

كلمة المرور لمرة واحدة

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

يمكن استخدام كلمة السر لمرة واحدة. على سبيل المثال ، نجح أول من يغير الإحداثيات (على الحالة) ويدخل كلمة المرور الصحيحة. بعد ذلك ، يتم قفله ويجب تعيين كلمة مرور أخرى في وضع التكوين.

قد يكون هذا اختياريًا ولكني أخشى أنه قد يجعل وضع التكوين معقدًا مرة أخرى (مربعا اختيار ، 3 حقول إدخال لتعيين الإحداثيات).

ألا ينبغي أن يكون ملخص HTTP قابلاً للتنفيذ في البرنامج النصي خلف uhttpd أيضًا؟ إنها مجرد رؤوس وأشياء ، بعد كل شيء ...

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

لم يتم وضع علامة عليها مع علامة فارقة ، لذا فهي بالتأكيد ليست أداة عرض لعام 2014.1 ، ولكن إذا اتفقنا على بنائها ، فقد تصل إلى عام 2014.

نعم انت على حق. يمكن تنفيذ ملخص HTTP باستخدام الرؤوس فقط.

يبدو أن العودة إلى المصادقة المستندة إلى كلمة المرور لأي شيء يمثل قفزة هائلة إلى الوراء بالنسبة لي.

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

ولا أرى مشكلة في اضطرار المستخدمين للعودة إلى وضع التكوين مرة واحدة عند تثبيت عقدة في مكان ما.

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

لماذا لا يكون لديك صفحة تهيئة خاصة يمكن الوصول إليها عبر http: //node.ffhh عندما تكون العقدة متصلة أولاً بشبكة freifunk (عبر شبكة أو vpn). إذا لم يقم المالك بزيارة وضع التكوين ، فلن يعمل freifunk. ربما باستخدام زر إعادة الضبط كنوع من المصادقة ("اضغط على زر html هذا وزر إعادة الضبط خلال 30 ثانية للسماح بتكوين العقدة").

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

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

أي حلول الآن؟ هل قام شخص ما بتنفيذ شيء مثل هذا محليًا بالفعل؟

جاء hexa بفكرة استخدام OTP المستند إلى الوقت (أي RFC 6238) للمصادقة. أنا نوعا ما أحب هذا النهج. لكي يعمل هذا ، سيظهر للمستخدم رمز QR (+ سلسلة) لإعداد "عميل" OTP (أي هاتف ذكي). يجب أن يكون المستخدم قادرًا على إعادة تعيين الرمز المميز (أو تعطيل الميزة تمامًا).

هذه بعيدة عن الفكرة الملائمة المتمثلة في سهولة ضبط الموقع الجغرافي مع صفحة الحالة (مع وضع المصادقة على الإطلاق) .. ولكن إذا كان لديك اتصال ssh ولم تكن خائفًا من المحطات الطرفية - فإليك بعض البرامج الصغيرة المفيدة مثل lat lon alt location geoguess https: / /github.com/viisauksena/gluon-banner/tree/master/files/usr/bin/ يمكنك إضافتها افتراضيًا إلى العقد أو البرامج الثابتة الخاصة بك

ماذا عن تلميح كبير

تأكد من كتابة الإحداثيات الجغرافية قبل المتابعة

التي ستظهر مرة واحدة فقط عند الاتصال الأول بوضع التكوين بعد تثبيت جديد؟

blocktrronmweineltrotanid هل نغلق هذا؟

قال NeoRaider

ولا أرى مشكلة في اضطرار المستخدمين للعودة إلى وضع التكوين مرة واحدة عند تثبيت عقدة في مكان ما.

أعتقد أن هذا صحيح ... العودة إلى وضع التكوين أمر ممكن. ليس هناك حاجة إلى حل معقد للغاية هنا ولم يتم تنفيذ هذا في 5 سنوات. لذلك ربما لن ينتهي هذا أبدًا ...

هل كانت هذه الصفحة مفيدة؟
0 / 5 - 0 التقييمات