الاستجابة لـ Tailworm: كيف عزّزنا أمان شبكة Tailscale لدينا دون تعطيل بيئة الإنتاج

كيف فحصنا شبكة Tailscale لدينا في ضوء نتائج Tailworm، وأزلنا مخاطر Tailscale SSH، وأبقينا جميع مهام الإنتاج قيد التشغيل.

ملخص

في 25 أكتوبر 2026، نشر أحد الباحثين الأمنيين تقرير “Tailworm”، الذي يتضمن 11 نتيجة تخص Tailscale وheadscale، وقد نُشر دون إفصاح منسّق (coordinated disclosure). وحتى وقت كتابة هذا المقال، لم تُصدر Tailscale أي إصلاح. وفي مساء اليوم نفسه، فحصنا شبكة Tailscale الخاصة بنا في ضوء كل نتيجة على حدة. أزلنا الثغرة الوحيدة التي كانت تنطبق علينا، وشدّدنا صلاحيات الوصول، وظلت جميع مهام الإنتاج تعمل طوال الوقت.

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

ما أورده تقرير Tailworm باختصار

تنقسم النتائج الإحدى عشرة إلى بضع مجموعات:

• Tailscale SSH (الأخطر). يمكن رفع صلاحيات جلسة SSH مصرّح بها إلى صلاحيات root على الجهاز المستهدف. وفي مختبر الباحث، انتشر الهجوم بعد ذلك من جهاز إلى آخر.
• App connectors. لا يجري التحقق من صحة الوجهات.
• استنزاف الذاكرة، في خادم التحكم وفي أجهزة العملاء.
• حالات حدّية في Serve وFunnel.

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

الخطوة 1: افحص قبل أن تغيّر

بدأنا بعمليات فحص للقراءة فقط، وسجّلنا النتائج قبل أن نلمس أي شيء:

• إصدارات عميل Tailscale المستخدمة
• الميزات المفعّلة فعليًا
• سجلات جلسات SSH لمدة 60 يومًا، لمعرفة من اتصل ومن أين، وما إذا كان أحد قد استخدم إعادة توجيه المنافذ أو المقابس
• قائمة الأجهزة، بما فيها الأجهزة التي لم تظهر منذ أشهر

النتائج:

• كان Tailscale SSH مفعّلًا في جزء من بيئتنا، ولذلك كانت النتائج F1–F3 وF5 ذات صلة بنا.
• لم تكن الميزات التي تعتمد عليها النتائج الأخرى مستخدمة، فلم ينطبق معظمها علينا.
• لم تُظهر سجلات SSH أي مصادر غير متوقعة ولا أي طلبات لإعادة التوجيه.

الخطوة 2: إزالة الثغرة دون انقطاع الخدمة

كان الحل البديهي هو إيقاف Tailscale SSH واستخدام المصادقة القياسية بالمفاتيح في OpenSSH بدلًا منه. لكن الفحص المسبق كشف لنا فخًا.

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

لذلك نفّذنا التحويل بهذا الترتيب:

1. أنشأنا مفتاحًا مخصصًا للأتمتة، يقتصر استخدامه على جهاز مصدر واحد، مع تعطيل إعادة التوجيه.
2. اختبرنا المسار الجديد قبل التحويل. فتحنا منفذ OpenSSH مؤقتًا لا يمكن الوصول إليه إلا من داخل الـ tailnet، واتصلنا من بيئة مماثلة لبيئة تشغيل المهام (دون وكيل SSH ودون طرفية)، بكل الطرق التي تستدعي بها سكربتاتنا SSH.
3. أجرينا اختبارات سلبية. رُفض المفتاح الجديد عند استخدامه من خارج المصدر المسموح به، ورُفضت طلبات إعادة التوجيه.
4. جهّزنا التراجع التلقائي أولًا. قبل إيقاف Tailscale SSH، جدولنا مؤقّتًا يعيد تشغيله تلقائيًا. ولم يكن مسار الاستعادة هذا يعتمد على عمل SSH.
5. نفّذنا التحويل، ثم تحققنا من كل مهمة مؤتمتة باتصالات جديدة. أكملت كل مهمة تشغيلًا فعليًا. ولم نعتبر أي جلسة مفتوحة مسبقًا دليلًا على النجاح.
6. أزلنا العناصر المؤقتة — المنفذ الإضافي وقاعدة الجدار الناري ومؤقّت التراجع — ثم تحققنا مرة أخرى.

الخطوة 3: تشديد ما تبقّى

• أفرغنا سياسة Tailscale SSH. كانت السياسة الافتراضية تسمح لأي جهاز من أجهزة المستخدم بفتح جلسات SSH إلى أجهزته الأخرى، بما في ذلك بصلاحيات root، بعد إعادة موافقة أسبوعية عبر المتصفح. أفرغنا هذه السياسة، بحيث لا يمنح إعادة تفعيل Tailscale SSH عن طريق الخطأ أي صلاحية وصول.
• أغلقنا SSH أمام الإنترنت. قبل الإغلاق، تأكدنا من أن تسجيل الدخول عبر وحدة تحكم خارج النطاق (out-of-band) يعمل، حتى لا نُقفل الباب على أنفسنا. وبعد ذلك تحققنا من شبكة خارجية من أن SSH لم يعد يستجيب.
• فرضنا الموافقة على الأجهزة. يجب أن يوافق المسؤول على الأجهزة الجديدة قبل أن تتمكن من الانضمام.
• فحصنا مفاتيح التسجيل. لم يكن هناك أي مفتاح يحتاج إلى إلغاء.
• تأكدنا من تفعيل MFA على حساب المسؤول. فأي شخص يستولي على بيانات دخول المسؤول يمكنه إلغاء الضوابط على مستوى الشبكة.
• بدأنا مراقبة حركة البيانات الفعلية بين الأجهزة، حتى تستند الخطوة التالية — تضييق نطاق الأجهزة المسموح لها بالتواصل مع كل خدمة — إلى أدلة لا إلى تخمينات.

يحمي كلٌّ من Tailnet Lock والموافقة على الأجهزة من انضمام جهاز غير مصرّح به، لكن لا يمكن استخدامهما معًا، لذا اختر أحدهما عن وعي.

الخطوة 4: أصلِح دليل التشغيل لا الخادم فقط

كان إجراء الاستعادة القديم لدينا ينص على إعادة توصيل الخادم مع تفعيل Tailscale SSH. ولو اتُّبع بعد هذا التغيير، لأعاد الميزة الخطرة بصمت. لذلك أعدنا كتابته:

• شخّص المشكلة أولًا. هل انقطع اتصال الشبكة، أم أن المشكلة في SSH نفسه (المفاتيح أو الإعدادات أو الجدار الناري)؟ لكل حالة حلٌّ مختلف.
• أعد الاتصال دون تغيير الإعدادات. لا تستخدم أي خيارات إضافية، واحفظ إعدادات العقدة قبل إعادة الاتصال، ثم قارنها بعده.
• لا تفتح وصول الطوارئ إلا مع مؤقّت. احصل على الموافقة أولًا، وجدول الإغلاق التلقائي قبل الفتح، وقيّد المصدر، وتحقّق من IPv4 وIPv6 معًا.
• لا تُعِد تفعيل Tailscale SSH حتى في حالات الطوارئ. فتغيير سياسة الوصول الذي يتطلبه لا يمكن التراجع عنه تلقائيًا.

ما تعلّمناه

1. اعرف ما الذي تصادق عليه ميزة الأمان فعليًا قبل إزالتها. المفتاح الذي ذكرته سكربتاتنا لم يُستخدم قط.
2. اختبر المسار الذي ستنتقل إليه بعينه، في البيئة نفسها التي تعمل فيها مهامك، قبل التحويل.
3. جهّز آلية تراجع لا تعتمد على الشيء الذي تغيّره. مؤقّت، لا عبارة “سندخل عبر SSH ونصلحها”.
4. تحقّق من وصول الاستعادة قبل أن تُغلق بابًا. تأكدنا من الوصول عبر وحدة التحكم قبل إغلاق SSH أمام الإنترنت.
5. حدّث دليل التشغيل ضمن التغيير نفسه. فخطوة استعادة قديمة قد تُلغي إصلاحًا أمنيًا بعد أشهر.
6. اقرأ السياسات الافتراضية. “السماح لأجهزتك الخاصة، بما في ذلك root” كان الإعداد الافتراضي الذي بدأنا منه.
7. افصل بين “نجح التغيير” و”عولجت الثغرة”. لم نعد معرّضين للنتائج المتعلقة بـ Tailscale SSH، لكن ملف Tailworm ككل لن يُغلق حتى تصدر الإصلاحات من المصدر الأصلي (upstream). وسنحدّث عملاءنا عند صدورها.
8. قِس أولًا، ثم ضيّق. تأتي حركة البيانات المرصودة وقائمة الاعتماديات الفعلية قبل قواعد الوصول الأكثر صرامة، حتى لا يعطّل التشديد الأمني سير العمل.

الخطوات التالية

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

المراجع: تقرير Tailworm (tailworm.com) ووثائق Tailscale حول Tailnet Lock.