Gateway एक्सपोज़र रनबुक

यह रनबुक व्यापक सुरक्षा मार्गदर्शन को दूरस्थ पहुँच और मैसेजिंग एक्सपोज़र के लिए ऑपरेटर चेकलिस्ट में बदलती है।

एक्सपोज़र पैटर्न चुनें

वर्कफ़्लो को पूरा करने वाला सबसे सीमित पैटर्न चुनें।

Gateway पर सीधे सार्वजनिक पोर्ट-फ़ॉरवर्डिंग से बचें। यदि सार्वजनिक पहुँच आवश्यक हो, तो उसके सामने पहचान-सचेत प्रॉक्सी रखें और प्रॉक्सी को Gateway तक पहुँचने वाला एकमात्र नेटवर्क पथ बनाएँ।

प्रारंभिक इन्वेंट्री

बाइंड, प्रॉक्सी, Tailscale या चैनल नीति बदलने से पहले इन्हें दर्ज करें:

• Gateway होस्ट, OS उपयोगकर्ता और स्थिति डायरेक्टरी (डिफ़ॉल्ट ~/.openclaw)।
• Gateway URL और बाइंड मोड (gateway.bind; डिफ़ॉल्ट पोर्ट 18789)।
• प्रमाणीकरण मोड, टोकन/पासवर्ड स्रोत या विश्वसनीय प्रॉक्सी पहचान स्रोत।
• प्रत्येक सक्षम चैनल और क्या वह DM, समूह या Webhook स्वीकार करता है।
• गैर-स्थानीय प्रेषकों की पहुँच में आने वाले एजेंट।
• प्रत्येक पहुँच योग्य एजेंट की टूल प्रोफ़ाइल, सैंडबॉक्स मोड और उन्नत टूल नीति।
• उन एजेंटों के लिए उपलब्ध बाहरी क्रेडेंशियल।
• ~/.openclaw/openclaw.json और क्रेडेंशियल के बैकअप का स्थान।

यदि एक से अधिक व्यक्ति बॉट को संदेश भेज सकते हैं, तो इसे प्रति-उपयोगकर्ता होस्ट अलगाव नहीं, बल्कि टूल के साझा प्रत्यायोजित अधिकार के रूप में मानें।

आधारभूत जाँच

पहुँच खोलने से पहले चलाएँ:

openclaw doctoropenclaw security auditopenclaw security audit --deepopenclaw health

पहले गंभीर निष्कर्षों का समाधान करें। चेतावनियाँ केवल तभी स्वीकार करें, जब वे डिप्लॉयमेंट के लिए जानबूझकर रखी गई और दस्तावेज़ीकृत हों। प्रत्येक checkId का अर्थ और उसकी सुधार कुंजी जानने के लिए सुरक्षा ऑडिट जाँच देखें।

दूरस्थ CLI सत्यापन के लिए, क्रेडेंशियल स्पष्ट रूप से पास करें:

openclaw gateway probe --url ws://127.0.0.1:18789 --token "$OPENCLAW_GATEWAY_TOKEN"

यह न मानें कि स्थानीय कॉन्फ़िगरेशन के क्रेडेंशियल किसी स्पष्ट दूरस्थ URL पर लागू होते हैं।

न्यूनतम सुरक्षित आधाररेखा

उजागर किए गए डिप्लॉयमेंट के शुरुआती बिंदु के रूप में इस संरचना का उपयोग करें:

{  gateway: {    bind: "loopback",    auth: {      mode: "token",      token: "replace-with-a-long-random-token",    },  },  session: {    dmScope: "per-channel-peer",  },  agents: {    defaults: {      sandbox: { mode: "non-main" },    },  },  tools: {    profile: "messaging",    exec: { security: "deny", ask: "always" },    elevated: { enabled: false },  },}

एक बार में एक नियंत्रण का विस्तार करें: लिखने में सक्षम टूल सक्रिय करने से पहले किसी विशिष्ट चैनल की अनुमत-सूची जोड़ें, या दूरस्थ Control UI ट्रैफ़िक स्वीकार करने से पहले रिवर्स प्रॉक्सी सक्रिय करें।

tools.exec.security: "deny" सभी exec कॉल को अवरुद्ध करता है, जिनमें अहानिकर निदान भी शामिल हैं। यदि निदान या कम-जोखिम वाले कमांड आवश्यक हों, तो इसे केवल उन विशिष्ट प्रेषकों, एजेंटों, कमांड और अनुमोदन मोड को चुनने के बाद शिथिल करें, जो आपके खतरा मॉडल के अनुरूप हों।

DM और समूह एक्सपोज़र

मैसेजिंग चैनल अविश्वसनीय इनपुट सतहें हैं। DM या समूहों को अनुमति देने से पहले:

• dmPolicy: "open" की बजाय dmPolicy: "pairing" या सख्त allowFrom सूची को प्राथमिकता दें।
• "*" अनुमत-सूचियों को व्यापक टूल पहुँच के साथ संयोजित न करें।
• जब तक कक्ष कड़े नियंत्रण में न हो, समूहों में उल्लेख आवश्यक करें।
• जब कई लोग बॉट को DM भेज सकते हों, तो session.dmScope: "per-channel-peer" (या बहु-अकाउंट चैनलों के लिए "per-account-channel-peer") सेट करें, ताकि DM सत्र संदर्भ साझा न करें।
• साझा चैनलों को न्यूनतम टूल और बिना व्यक्तिगत क्रेडेंशियल वाले एजेंटों तक रूट करें।

पेयरिंग प्रेषक को बॉट सक्रिय करने की अनुमति देती है। यह उस प्रेषक को अलग होस्ट सुरक्षा सीमा नहीं बनाती।

रिवर्स प्रॉक्सी जाँच

पहचान-सचेत प्रॉक्सी के लिए:

• प्रॉक्सी को Gateway पर फ़ॉरवर्ड करने से पहले उपयोगकर्ताओं को प्रमाणित करना आवश्यक है।
• फ़ायरवॉल या नेटवर्क नीति को Gateway पोर्ट तक सीधी पहुँच अवरुद्ध करनी चाहिए।
• gateway.trustedProxies में केवल प्रॉक्सी स्रोत IP सूचीबद्ध होने चाहिए।
• प्रॉक्सी को क्लाइंट द्वारा दिए गए पहचान और फ़ॉरवर्डिंग हेडर हटाने या ओवरराइट करने चाहिए।
• जब प्रॉक्सी एक से अधिक ऑडियंस को सेवा देती हो, तब gateway.auth.trustedProxy.allowUsers सेट करें।
• gateway.auth.trustedProxy.allowLoopback का उपयोग केवल उसी-होस्ट प्रॉक्सी के लिए करें, जहाँ स्थानीय प्रक्रियाएँ विश्वसनीय हों और पहचान हेडर प्रॉक्सी के नियंत्रण में हों।

प्रॉक्सी परिवर्तनों के बाद openclaw security audit --deep चलाएँ। विश्वसनीय-प्रॉक्सी निष्कर्ष अत्यधिक महत्वपूर्ण संकेत हैं, क्योंकि प्रॉक्सी प्रमाणीकरण सीमा बन जाती है।

टूल और सैंडबॉक्स समीक्षा

किसी एजेंट को दूरस्थ प्रेषकों के लिए उजागर करने से पहले:

• पुष्टि करें कि कौन-से सत्र होस्ट पर और कौन-से सैंडबॉक्स में चलते हैं।
• होस्ट exec को अस्वीकार करें या उसके लिए अनुमोदन आवश्यक करें।
• जब तक किसी विशिष्ट, विश्वसनीय प्रेषक को उनकी आवश्यकता न हो, उन्नत टूल अक्षम रखें।
• खुली या अर्ध-खुली मैसेजिंग सतहों के लिए ब्राउज़र, कैनवास, Node, Cron, Gateway और सत्र-स्पॉन टूल से बचें।
• बाइंड माउंट सीमित रखें; क्रेडेंशियल, होम, Docker सॉकेट और सिस्टम पथों से बचें।
• काफी भिन्न विश्वास सीमाओं के लिए अलग Gateway, OS उपयोगकर्ता या होस्ट उपयोग करें।

यदि दूरस्थ उपयोगकर्ता पूरी तरह विश्वसनीय नहीं हैं, तो अलगाव अलग डिप्लॉयमेंट से आना चाहिए, केवल प्रॉम्प्ट या सत्र लेबल से नहीं।

परिवर्तन के बाद सत्यापन

प्रत्येक एक्सपोज़र परिवर्तन के बाद:

1. openclaw security audit --deep दोबारा चलाएँ।
2. पुष्टि करें कि अधिकृत कनेक्शन सफलतापूर्वक जुड़ता है।
3. पुष्टि करें कि अनधिकृत प्रेषक या ब्राउज़र सत्र को अस्वीकार किया जाता है।
4. पुष्टि करें कि लॉग सीक्रेट छिपाते हैं।
5. पुष्टि करें कि DM/समूह रूटिंग केवल इच्छित एजेंट तक पहुँचती है।
6. पुष्टि करें कि उच्च-प्रभाव वाले टूल अनुमोदन माँगते हैं या अस्वीकार किए जाते हैं।
7. स्वीकार की गई शेष चेतावनियों का दस्तावेज़ीकरण करें।

जब तक वर्तमान एक्सपोज़र परिवर्तन समझ में न आ जाए, अगले परिवर्तन पर आगे न बढ़ें।

रोलबैक योजना

यदि Gateway अत्यधिक उजागर हो सकता है:

{  gateway: {    bind: "loopback",  },  channels: {    whatsapp: { dmPolicy: "disabled" },    telegram: { dmPolicy: "disabled" },    discord: { dmPolicy: "disabled" },    slack: { dmPolicy: "disabled" },  },  tools: {    exec: { security: "deny", ask: "always" },    elevated: { enabled: false },  },}

फिर:

1. सार्वजनिक फ़ॉरवर्डिंग, Tailscale Funnel या रिवर्स प्रॉक्सी रूट रोकें।
2. Gateway टोकन/पासवर्ड और प्रभावित एकीकरण क्रेडेंशियल रोटेट करें।
3. अनुमत-सूचियों से "*" और अनपेक्षित प्रेषकों को हटाएँ।
4. हाल के ऑडिट लॉग, रन इतिहास, टूल कॉल और कॉन्फ़िगरेशन परिवर्तनों की समीक्षा करें।
5. openclaw security audit --deep दोबारा चलाएँ।
6. वर्कफ़्लो को पूरा करने वाले सबसे सीमित पैटर्न के साथ पहुँच दोबारा सक्रिय करें।

समीक्षा चेकलिस्ट

• जब तक कोई दस्तावेज़ीकृत कारण न हो, Gateway केवल लूपबैक पर रहता है।
• गैर-लूपबैक पहुँच में प्रमाणीकरण और फ़ायरवॉल सुरक्षा है तथा कोई सीधा सार्वजनिक रूट नहीं है।
• विश्वसनीय-प्रॉक्सी डिप्लॉयमेंट में सख्त प्रॉक्सी IP और हेडर नियंत्रण हैं।
• DM डिफ़ॉल्ट रूप से खुली पहुँच के बजाय पेयरिंग या अनुमत-सूचियों का उपयोग करते हैं।
• समूहों में उल्लेख या स्पष्ट अनुमत-सूचियाँ आवश्यक हैं।
• साझा चैनलों की पहुँच व्यक्तिगत क्रेडेंशियल तक नहीं है।
• गैर-मुख्य सत्र सैंडबॉक्स मोड में चलते हैं।
• होस्ट exec और उन्नत टूल अस्वीकृत हैं या अनुमोदन द्वारा नियंत्रित हैं।
• लॉग सीक्रेट छिपाते हैं।
• गंभीर ऑडिट निष्कर्षों का समाधान किया गया है।
• रोलबैक चरणों का परीक्षण और दस्तावेज़ीकरण किया गया है।