प्रदर्शन की भाषा चुनें

विशेष रिपोर्ट · 2026-10-25 23:18 JST

Tailwormभीतर की सीमाओं पर
फिर से विचार करें।

Tailscale / headscale उपयोगकर्ताओं के लिए।
सबसे पहले जाँचें: किन्हें SSH कनेक्शन की अनुमति दी है, और कनेक्शन के बाद उनके पास क्या अधिकार हैं।

आज क्या जाँचना है ↓6 स्क्रीन की मोशन प्रस्तुति देखें →

आधार समय 23:18 JST / 14:18 UTC है। प्राथमिक स्रोत वास्तव में इस समय के बाद प्राप्त किए गए।
शोध पृष्ठ और संबंधित पक्ष की प्रतिक्रिया बदल सकते हैं, इसलिए इन्हें उस समय के अपरिवर्तनीय मूल पाठ का रिकॉर्ड नहीं मानते।

शोध का विषय1.104.2 / 0.29.5Tailscale / headscale
विक्रेताजाँच और सुधार जारीप्रभावित कॉन्फ़िगरेशन की जाँच जारी
Tailworm का सुधार वाला संस्करणइस समीक्षा में अभी तय नहींप्रमाणपत्र अपडेट से अलग रखें

01 / अपना जोखिम पहचानें

आप किन सुविधाओं का इस्तेमाल करते हैं?

नीचे शोधकर्ता की पुनरुत्पादन रिपोर्ट का सारांश है। हमने इस जाँच में PoC नहीं चलाया। 11 मदों में कॉन्फ़िगरेशन और खतरे के मॉडल से जुड़ी टिप्पणियाँ भी हैं; इन्हें 11 CVE या सेंधमारी की 11 घटनाएँ नहीं माना जाता।

SSH / निष्कर्ष 1–3, 5

Tailscale SSH

इसके लिए SSH चालू वाले नोड से कनेक्शन की अनुमति और संबंधित फ़ॉरवर्डिंग अधिकार होना आवश्यक है। रिपोर्ट के अनुसार root द्वारा Unix socket के संचालन और पाथ रेस के कारण अधिकार की सीमा पार हो सकती है।

जाँचें: सक्षम नोड, SSH नियम, अनावश्यक फ़ॉरवर्डिंग
स्वयं होस्ट किया हुआ / निष्कर्ष 6

headscale

0.29.5 में सार्वजनिक पंजीकरण मार्ग के ज़रिए मेमोरी समाप्त होने और कैश से प्रविष्टियाँ निकाले जाने की रिपोर्ट है। शोधकर्ता का यह भी कहना है कि SSH फ़ॉरवर्डिंग को रोका नहीं जा सकता।

जाँचें: सार्वजनिक पहुँच, SSH अनुमति, मेमोरी और पंजीकरण की निगरानी
प्रयोगात्मक / निष्कर्ष 4

conn25 कनेक्टर

रिपोर्ट के अनुसार conn25 का इस्तेमाल करने की capability वाला उपकरण कनेक्टर का वास्तविक गंतव्य चुन सकता है। LAN, metadata और cluster तक पहुँचने वाले मार्ग जाँचें।

जाँचें: conn25 का उपयोग, उपयोग की अनुमति, वास्तविक गंतव्य का egress
SERVE / निष्कर्ष 7–11

Serve / Funnel

इनमें विशेषाधिकार वाले socket की ओर TCP फ़ॉरवर्डिंग, कॉन्फ़िगरेशन के बाद रेस, सभी interface पर bind और कई mount के लिए प्राधिकरण जैसी बातें हैं। प्रभाव operator के कॉन्फ़िगरेशन और ऐप के प्राधिकरण पर निर्भर करता है।

जाँचें: forward कॉन्फ़िगरेशन, listen का दायरा, backend प्राधिकरण

DERP client की मेमोरी समाप्त होने के लिए उसे दुर्भावनापूर्ण relay से कनेक्ट कराने में सक्षम होना आवश्यक है। इससे यह सामान्य निष्कर्ष नहीं निकाला जा सकता कि सभी उपयोगकर्ता एक ही मार्ग से प्रभावित होंगे। हर मद का विवरण और सीमाएँ (अंग्रेज़ी) →

02 / आज कदम उठाएँ

जाँचें और अनुमति का दायरा घटाएँ।

  1. SSH की वास्तविक पहुँच की सूची बनाएँ।केवल ज़रूरी उपयोगकर्ताओं और उपकरणों से ज़रूरी गंतव्यों तक पहुँच की अनुमति दें और अनावश्यक फ़ॉरवर्डिंग घटाएँ। सामान्य OpenSSH कनेक्शन और Tailscale SSH में अंतर रखें।
  2. महत्वपूर्ण होस्ट पर SSH अस्थायी रूप से बंद करने पर भी विचार करें।पहले प्रबंधन का वैकल्पिक मार्ग सुनिश्चित करें, फिर निर्णय लें। केवल गैर-root उपयोगकर्ता चुनना इस अधिकार वृद्धि को रोकने के लिए पर्याप्त नहीं माना जाता। यह विक्रेता की ओर से सबके लिए SSH बंद करने की सलाह नहीं है।
  3. check mode को सुधार न कहें।प्रवेश पर अतिरिक्त प्रमाणीकरण उपयोगी है, लेकिन यह अनुमति प्राप्त सत्र के भीतर अधिकार की समस्या हल नहीं करता।
  4. headscale, कनेक्टर और Serve को अलग-अलग जाँचें।सार्वजनिक पंजीकरण मार्ग, मेमोरी की सीमा, अनावश्यक conn25 अनुमति और विशेषाधिकार वाले socket की फ़ॉरवर्डिंग जाँचें। IP firewall स्थानीय socket रेस को नहीं रोक सकता। Kubernetes की egress सीमाओं को भी वास्तविक मार्ग पर सत्यापित करें।
  5. अपडेट का मिलान आधिकारिक सलाह से करें।जहाँ संभव हो स्वचालित अपडेट चालू करें और सुधार वाले संस्करण की घोषणाओं पर नज़र रखें। प्रभावित संस्करण, सुधार वाले संस्करण और कॉन्फ़िगरेशन से जोखिम घटाने के उपाय अलग-अलग दर्ज करें।

केवल पढ़कर जाँच शुरू करने के लिए। परिणाम या कॉन्फ़िगरेशन में मौजूद गोपनीय जानकारी सार्वजनिक न करें।

tailscale version
tailscale serve status
tailscale funnel status

सक्षम नोड और SSH नीति प्रबंधन कंसोल तथा तैनाती कॉन्फ़िगरेशन में भी जाँचें। CLI के आधिकारिक दस्तावेज़ / SSH के आधिकारिक दस्तावेज़

03 / सेंधमारी का संदेह हो तो

फिर से निर्माण करें, और उपकरण की पहचान निरस्त करें।

उपकरण को अलग करें और सबूत सुरक्षित रखें। नियंत्रण स्तर पर उपकरण हटाएँ या उसकी पहचान निरस्त करें तथा उजागर हुई पंजीकरण कुंजियाँ और API क्रेडेंशियल बदलें। root की सुरक्षा भंग हुई हो तो state की प्रतिलिपि बनाए जाने की संभावना भी जाँचें। केवल OS फिर से स्थापित करने से बाहर ले जाई गई कुंजियाँ निरस्त नहीं होतीं। हस्ताक्षर करने वाला नोड प्रभावित हो तो Tailnet Lock की कुंजियों पर भी विचार करें।

शोधकर्ता के नियंत्रण के कदम / उपकरण हटाने के आधिकारिक निर्देश

04 / एक अलग सुधार

1.104.2 पर अपडेट करने से भी
Tailworm का समाधान पूरा नहीं माना जाता।

10/21 का 1.104.2 संस्करण TS-2026-013 और eMudhra प्रमाणपत्र समस्या का समाधान करता है। Tailworm शोध भी इसी संस्करण पर किया गया है। प्रमाणपत्र अपडेट लागू करते हुए Tailworm के पुष्ट सुधार को अलग से ट्रैक करें।

Tailscale की आधिकारिक सुरक्षा सलाह / बदलावों का विवरण / headscale के रिलीज़

शोध रिपोर्ट और पुष्ट तथ्यों को अलग रखें।

शोधकर्ता: Erica Windisch / Cyberdione Labs। परीक्षण अवधि 10/22–24; Tailscale 1.104.2 और headscale 0.29.5। वास्तविक परिवेश में स्वतंत्र पुनरुत्पादन की पुष्टि नहीं की गई है। विक्रेता प्रभावित कॉन्फ़िगरेशन की जाँच कर रहा है; इसे शोधकर्ता की सभी 11 मदों की अलग-अलग स्वीकृति नहीं मानते। इस समीक्षा में समर्पित CVE, CVSS और सबसे पुराने सुधार वाले संस्करण की पुष्टि नहीं हुई है।

शोध साइट के सटीक संस्करण इतिहास और Reddit प्रतिक्रिया के संपादन का समय अभी तय नहीं है। प्राप्त करने के बाद की जानकारी को 23:18 से पहले की पुष्ट स्थिति पर लागू नहीं करते। रिकॉर्ड, हैश और जाँच की सीमाएँ रिपॉज़िटरी में दर्ज हैं।