تخطَّ إلى المحتوى

وضع جهاز MikroTik: دليل الأمان والتشغيل

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

وضع جهاز MikroTik: دليل الأمان والتشغيل

Diagram showing how RouterOS device-mode sits below user permissions and gates high-risk tools

ما هو وضع الجهاز (وما ليس كذلك)

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

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

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

لماذا قدمت MikroTik وضع الجهاز

السبب باختصار: مهاجمون تعلموا كيف يحولون الموجهات الطرفية إلى أسلحة على نطاق الإنترنت.

الدافع الرئيسي كان عصر شبكة بوت نت Mēris. استُخدمت الموجهات المخترقة كمرسلات ومولِّدات حركة مرور عن طريق إساءة استخدام ميزات مصممة للمهندسين لكنها كارثية عند الاستغلال على نطاق واسع.

تشمل الأدوات المعتادة للإساءة:

  • وكيل SOCKS، يستخدم لنفق مرور الهجمات.
  • اختبار عرض النطاق الترددي، يُستخدم لتضخيم الحركة.
  • الجدولة + fetch، تستخدم للاستمرارية وتسليم الحمولات.

يرمي وضع الجهاز لتطبيق مبدأ أقل الامتيازات على مستوى النظام. يجعل “الاستيلاء عن بُعد” أقل ربحية. حتى لو سرق المهاجم بيانات اعتماد، فلا يمكنه تفعيل أعلى الأدوات خطورة بدون خطوة مادية.

مصافحة التحقق المادي

قاعدة تحكم حاسمة هي التحقق من الوصول المادي.

إذا حاولت تفعيل ميزة مقيدة من no إلى yes، يقبل RouterOS الطلب لكن يبقيه في حالة انتظار. يجب تأكيده محليًا، غالبًا عبر ضغط زر أو إعادة تشغيل باردة (قطع التشغيل وتشغيله) ضمن المهلة المحددة.

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

نصيحة: اعتبر تغييرات وضع الجهاز كـ “تحكم في التغيير”. إذا كان الجهاز في موقع بعيد، خطط لكيفية تنفيذ إعادة التشغيل المطلوبة (PDU ذكي، PoE مدار، تواجد في الموقع).

موقع وضع الجهاز ضمن طبقة الأمان

ها هي صورة ذهنية عملية:

  • مجموعات المستخدمين: “ما يمكن لهذا المستخدم النقر عليه أو كتابته.”
  • جدار الحماية: “ما هي الحركة التي تصل إلى الخدمات.”
  • وضع الجهاز: “ما السماح للنظام بتشغيله أصلاً.”

إذاً، لا، وضع الجهاز لا يحل محل جدار الحماية. إنه الخط الدفاعي الأخير عند حدوث خطأ ما.

الأطوار، العلامات، وما يتم حظره في الواقع

يتم تكوين وضع الجهاز عبر /system/device-mode. داخليًا، هو مجموعة من علامات منطقية تتحكم في الأنظمة الفرعية.

أمثلة على العلامات التي تؤثر كثيرًا في العمليات:

  • fetch: يحظر /tool/fetch وأي أتمتة تعتمد عليه.
  • scheduler: يحظر /system/scheduler والسيناريوهات المجدولة.
  • socks: يمنع تفعيل وكيل SOCKS.
  • bandwidth-test وtraffic-gen: يمنع أدوات اختبار النطاق وتوليد الحركة.
  • container: يمنع حاويات RouterOS إلا إذا تم تمكينها صراحة.
  • partitions وrouterboard: يمنع تغييرات التخزين منخفض المستوى وإعدادات التمهيد.
  • install-any-version / allowed-versions: يحد من هبوط الإصدارات التي تعيد الثغرات الأمنية القديمة.

اعتمادًا على إصدار RouterOS، قدمت MikroTik أيضًا أطوارًا معرفة مسبقًا (مثلاً: home، basic، advanced، وrose لفئات الأجهزة). الأسماء أقل أهمية من النتيجة. قد يصل جهاز جديد بحالة مقيدة تخرق الإعدادات الافتراضية حتى تخطط لها.

التطور الفني حسب الإصدارات وتحليل سجل التعديلات

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

المرحلة 1: أمان الحاويات (RouterOS v7.4beta - v7.12)

ظهر وضع الجهاز أول مرة مرتبطًا بدعم الحاويات (بيئات متوافقة مع Docker) في RouterOS v7.4beta.9 أدركت MikroTik أن السماح بتنفيذ ثنائيات من طرف ثالث كان مخاطرة غير مسبوقة. فكان حزمة الحاويات أول من يتطلب التفعيل عبر /system/device-mode/update container=yes مع الضغط على زر. خلال هذه الفترة كان يُنظر لوضع الجهاز كـ “مفتاح أمان الحاويات” وليس كإطار شامل.

المرحلة 2: الأساس الأمني (v7.13 و v6.49.8)

في خطوة مهمة للدعم طويل الأمد، قامت MikroTik بتطبيق عناصر من وضع الجهاز لفرع v6 في الإصدار 6.49.8 وأدخلت خاصية allowed-versions في الإصدار 7.13.1. تحظر allowed-versions (مثلاً 7.13+، 6.49.8+) إمكانية الرجوع لنسخ البرنامج الثابت قبل تطبيق تصحيحات أمنية هامة. هذا يصد هجمات الرجوع حيث يحاول المهاجم الرجوع لإصدار ضعيف مثل Chimay-Red (CVE-2017-20149).

المرحلة 3: تجديد الإصدار 7.17

شكل الإصدار 7.17، الصادر أوائل 2025، توسعة كبيرة للإطار. قدم مفهوم “الأطوار” المعرفة مسبقًا التي تصنف الأجهزة حسب فئتها ومتطلباتها.

اسم الطورفئة الأجهزةوضع الأمانالقيود الرئيسية (افتراضي)
AdvancedCCR, 1100, متقدممتسامحcontainer, traffic-gen, install-any-version
HomehAP, cAP, SOHOصارمscheduler, fetch, socks, bandwidth-test, sniffer
BasicRB قياسي، محولاتمتوازنsocks, bandwidth-test, proxy, zerotier
RoseRDS، لاسلكي خارجياستخدام خاصمثل Advanced لكن container=yes¹

¹ أثناء الترقية لـ v7.17، أعاد النظام تسمية طور “enterprise” القديم إلى “advanced”. لحالات نشر قائمة، حاولت MikroTik الحفاظ على الوظائف عبر تعيين الموديلات المترقّية مطابقًا لملفها. لكن هذا أدى لصراعات تشغيل فورية مع تعطيل خواص كـ traffic-gen و repartition حتى في وضع advanced.

المرحلة 4: الأتمتة والتحسين (v7.19 - v7.22)

ركزت آخر النسخ على كسر “مأزق الأتمتة” الناجم عن شرط الوصول المادي. إصدار 7.19.4 قدم طور rose لدعم تثبيت الحاويات في أجهزة RDS.

إصدار 7.22rc3 (فبراير 2026) أضاف إمكانية برمجة وضع الجهاز عبر Netinstall وFlashFig عبر “سكريبت الوضع”. يسمح ذاك لمشغلي الشبكات بتحديد حالة الأمان أثناء وميض الصورة الأولي، متجاوزًا حاجة الضغط على أزرار على ألوف الوحدات. كما أزال الإصدار خاصية authorized-public-key-hash المثار حولها التكهنات بشأن تغييرات الوضع عن بعد عبر مفاتيح SSH.

حالة “معلمة” وعداد المحاولات

وضع الجهاز ليس مجرد علامات ثابتة.

يمكن لـ RouterOS تمييز الجهاز كـ معلم عند كشف سلوك مشبوه، مثل العبث بملفات النظام أو سيناريوهات تدل على استمرارية. حينها قد يلجأ النظام لتفعيل حالة أمان أشد عبر تعطيل الأدوات المقيدة.

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

معنى تشغيلي: عند رؤية محاولات غير متوقعة، فلتتحقق أولًا. لا تُمكن المزيد من الميزات فقط لجعلها تعمل.

معاناة التهيئة: مأزق الأتمتة

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

مأزق كلاسيكي:

  1. يقلع الموجه في وضع مقيد.
  2. يحتاج سيناريو الإقلاع الأول /tool/fetch لتنزيل إعداد أو شهادة.
  3. fetch محظور في وضع الجهاز.
  4. يفشل الإقلاع ولا يمكن إصلاح الجهاز عن بُعد.

بعض الفرق يجب أن تفتح كل وحدة يدويًا، تفعّل الميزات، وتعيد التغليف. وهذا غير عملي.

بدأت عمليات التهيئة الحديثة تتحسن بالسماح بضبط وضع الجهاز أثناء وميض الصورة (مثلاً بواسطة سكريبتات الوضع في Netinstall/FlashFig). إذا تدير حجمًا كبيرًا، خطط لعملية الصورة الذهبية.

تحذير: /system/reset-configuration قد لا يعيد ضبط وضع الجهاز في النماذج المتعددة. إذا كان سؤالك “إعادة الضبط = المصنع”، قد تصادف مفاجآت.

كيفية تفعيل ميزة ضرورية بأمان (مثال CLI)

عندما تحتاج بالفعل ميزة مقيدة، اتبع إجراء متوقع.

  1. تحقق من الحالة الحالية
/system/device-mode/print
  1. اطلب التغيير مع مهلة
/system/device-mode/update fetch=yes activation-timeout=10m
  1. قم بالتأكيد المادي
  • اضغط زر الوضع/إعادة الضبط مرة (يختلف حسب الموديل)، أو
  • قم بإعادة تشغيل الجهاز كهربائيًا (إعادة تشغيل باردة).
  1. التحقق
/system/device-mode/print

إذا فاتتك المهلة، يلغي RouterOS التغيير المعلق ويبقي السياسة القديمة.

التفعيل المعتمد على المخاطر: مصفوفة قرار سريعة

القدرةالحاجة الشرعية المعتادةالخطر الرئيسينهج أكثر أمانًا
fetchجلب الإعدادات، تجديد الشهاداتتسليم حمولة عن بعدالسماح فقط لنقاط HTTPS معروفة؛ تقييد الحركة الصادرة
schedulerالنسخ الاحتياطية، مهام الصيانةاستمراريةالحفاظ على السيناريوهات بسيطة؛ المراقبة للمهام غير المتوقعة
socksنفق داخلياستخدام كمرسل بوت نتربطه على VLAN الإدارة فقط؛ تقييد جدار الحماية
traffic-gen / bandwidth-testاختبارات الاتصالهجمات حرمان/تضخيمالتمكين فقط خلال نافذة الصيانة
containerتشغيل خدمات على الموجهاستمرارية طويلة الأمدتفضيل الخوادم المخصصة؛ تقوية التخزين وجدار الحماية

كيف يؤثر هذا على اعتماد MKController (وضع الجهاز معطل)

يعتمد MKController على وصول إداري متوقع. قد يكون وضع الجهاز “فرامل غير مرئية” أثناء بدء الاستخدام.

إذا منع وضع الجهاز إجراءً مطلوبًا (مثلاً تفعيل خدمة، تنفيذ سكريبت، أو السماح بأداة أثناء الإعداد)، فقد يتوقف سير التبني. تظهر العلامة غالبًا كـ “الجهاز متاح لكن فشل في المهام.”

لهذا يركز دليل استكشاف الأخطاء على وضع الجهاز معطل كعنصر محدد ينبغي تدقيقه: إذا منع وضع الجهاز القدرات المطلوبة، قد تحتاج خطوة تأكيد مادية مخططة قبل اعتماد الجهاز وإدارته بالكامل عبر MKController. انظر البند 4 هنا: https://mkcontroller.com/docs/management/troubleshooting/troubleshooting/#4-device-mode-disabled

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

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

قائمة التحقق بعد الترقية التي يمكنك توحيدها

استخدمها بعد ترقيات RouterOS أو استلام عتاد جديد:

  • تأكد من الطور الحالي وهل يطابق سياستك.
  • تحقق من أدوات تعتمد عليها (مثلاً fetch وscheduler).
  • راجع سياسة الإصدارات المسموح بها إذا كنت تعمل في بيئات منظمة.
  • افحص عداد المحاولات وحالة flagged للأنحرافات.
  • وثق المواقع التي تتطلب التحقق المادي وكيف ستقوم به.

للمراجع الرسمية حول وضع الجهاز، توثيق MikroTik هو نقطة انطلاق جيدة: https://help.mikrotik.com/docs/spaces/ROS/pages/93749258/Device-mode

حول MKController

نأمل أن تكون الرؤى أعلاه ساعدتك على فهم عالم MikroTik والإنترنت بشكل أفضل! 🚀
سواء كنت تضبط الإعدادات أو تحاول فقط تنظيم الفوضى الشبكية، MKController هنا لجعل حياتك أبسط.

مع إدارة مركزية سحابية، تحديثات أمان مؤتمتة، ولوحة تحكم يسهل على الجميع إتقانها، لدينا ما يلزم للارتقاء بعمليتك.

👉 ابدأ فترة تجريبية مجانية 3 أيام الآن على mkcontroller.com — واختبر تحكم الشبكة السهل الحقيقي.