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

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

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

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

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

प्री-फ़्लाइट इन्वेंटरी

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

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

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

बेसलाइन जांच

एक्सेस खोलने से पहले ये चलाएं:

openclaw doctoropenclaw security auditopenclaw security audit --deepopenclaw health

पहले गंभीर निष्कर्षों को हल करें। चेतावनियां केवल तब स्वीकार्य हो सकती हैं जब वे जानबूझकर हों और डिप्लॉयमेंट के लिए दस्तावेजीकृत हों।

रिमोट 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 ट्रैफ़िक स्वीकार करने से पहले रिवर्स प्रॉक्सी सक्षम करें।

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

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

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

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

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

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

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

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

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

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

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

• पुष्टि करें कि कौन से सेशन होस्ट पर चलते हैं और कौन से सैंडबॉक्स में।
• होस्ट exec को अस्वीकार करें या उसके लिए अनुमोदन आवश्यक करें।
• जब तक किसी विशिष्ट, विश्वसनीय प्रेषक को उनकी जरूरत न हो, एलिवेटेड टूल अक्षम रखें।
• खुले या अर्ध-खुले मैसेजिंग सतहों के लिए ब्राउज़र, कैनवास, node, cron, gateway, और session-spawn टूल से बचें।
• बाइंड माउंट संकीर्ण रखें और क्रेडेंशियल, होम, Docker सॉकेट, और सिस्टम पथों से बचें।
• भौतिक रूप से अलग भरोसे की सीमाओं के लिए अलग gateways, 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 और एलिवेटेड टूल अस्वीकार किए जाते हैं या अनुमोदन-गेटेड हैं।
• लॉग सीक्रेट्स को रिडैक्ट करते हैं।
• गंभीर ऑडिट निष्कर्ष हल किए गए हैं।
• रोलबैक चरणों का परीक्षण और दस्तावेजीकरण किया गया है।