तुम्हारे AI असिस्टेंट ने मुझे शेल एक्सेस दे दिया

अपने लोकल या VPS OpenClaw/Moltbot सेटअप को सुरक्षित कैसे करें

OpenClaw (पहले Clawdbot/Moltbot) आपको एक पर्सनल AI असिस्टेंट देता है जो WhatsApp, Slack, Discord, iMessage और अन्य चैनल्स पर काम करता है। लेकिन अगर आप उसके गेटवे, नोड कंट्रोल्स या SSH को बिना मजबूत ऑथेंटिकेशन के पब्लिक इंटरनेट पर रखते हैं, तो आप अजनबियों को आपकी मशीन पर शेल एक्सेस की ओर बढ़ने का रास्ता दे रहे हैं।

यह गाइड सबसे सुरक्षित डिफ़ॉल्ट दिखाता है: OpenClaw के गेटवे को लूपबैक पर रखें, इसे केवल अपने टेलनेट के लिए Tailscale Serve के साथ एक्सपोज़ करें, SSH को लॉक करें, और बाहर से सत्यापित करें कि गेटवे सार्वजनिक नहीं है।

प्रोजेक्ट के तेज़ी से अपनाने ने असली सुरक्षा चिंताएँ सामने लाईं: Shodan स्कैन ने पहले कुछ हफ्तों में 2,847 एक्सपोज़्ड इंस्टेंस पाए, और एक GitHub सुरक्षा ऑडिट इश्यू ने कोडबेस में 512 फाइंडिंग्स रिपोर्ट कीं। कुछ ऑटोमेटेड स्कैनर आउटपुट था और कुछ जनवरी 2026 में OpenClaw नाम बदलने के बाद से बदल गया है, इसलिए इस नंबर को सटीक वर्तमान कमजोरी गिनती के बजाय एक चेतावनी संकेत मानें। आपको सुरक्षा विशेषज्ञ बनने की ज़रूरत नहीं है—बस आपको डिप्लॉय करने से पहले ऑपरेटर सरफेस को पब्लिश करने से बचना है।

आप वास्तव में क्या एक्सपोज़ कर रहे हैं

आपने इसे कैसे इंस्टॉल और एक्सपोज़ किया, इसके आधार पर तीन सरफेस हैं जिन्हें जाँचना चाहिए:

• पोर्ट 22: VPS पर SSH एक्सेस
• पोर्ट 18789: गेटवे कंट्रोल UI और WebSocket API
• ब्राउज़र/नोड कंट्रोल: गेटवे/नोड पेयरिंग मॉडल के ज़रिए रिमोट नोड एक्जीक्यूशन और ब्राउज़र ऑटोमेशन

वर्तमान OpenClaw रिमोट-एक्सेस डॉक्स कहते हैं कि गेटवे WebSocket डिफ़ॉल्ट रूप से लूपबैक से बाइंड होता है और LAN/tailnet/custom बाइंड को तब तक रखने की सलाह देते हैं जब तक आप जानबूझकर विकल्प न चुनें। यह अच्छा है। जोखिम तब सामने आता है जब आप उस डिफ़ॉल्ट को ओवरराइड करते हैं, Docker पोर्ट पब्लिश करते हैं, रिवर्स प्रॉक्सी जोड़ते हैं, Funnel चालू करते हैं, या SSH को दुनिया के लिए खुला छोड़ देते हैं।

गेटवे सबसे बड़ा है। यह आपके असिस्टेंट के लिए ऑपरेटर सरफेस है, जिसमें टूल इन्वोकेशन पाथ शामिल हैं। अगर यह इंटरनेट से पहुँच योग्य है और ऑथ गायब, कमज़ोर, बायपास या लीक हो गया है, तो हमलावर आपकी उपयोगकर्ता अनुमतियों के साथ एजेंट को चला सकता है या टूल इन्वोक कर सकता है।

ब्राउज़र कंट्रोल लगभग उतना ही संवेदनशील है। वर्तमान OpenClaw डॉक्स ब्राउज़र कंट्रोल को ब्राउज़र मशीन पर पेयर किए गए नोड होस्ट के माध्यम से चलाने और नोड पेयरिंग को ऑपरेटर एक्सेस की तरह मानने की सलाह देते हैं। अगर गेटवे पेयर किए गए नोड पर system.run इन्वोक कर सकता है, तो वह उस नोड पर रिमोट कोड एक्जीक्यूशन है, जो गेटवे की नोड पॉलिसी और नोड की अपनी एक्जीक्यूशन अप्रूवल के अधीन है।

SSH तो SSH है। अगर आप पासवर्ड ऑथेंटिकेशन को सक्षम करके चला रहे हैं, तो सार्वजनिक VPS पर ब्रूट फोर्स प्रयास अपरिहार्य हैं।

Tailscale समाधान

OpenClaw के लिए, Tailscale आपको ऑपरेटर सेवाओं को पब्लिश किए बिना रिमोट एक्सेस देता है:

1. आपका OpenClaw इंस्टेंस VPS या लोकल मशीन पर चलता है
2. गेटवे लूपबैक से बंधा रहता है और Tailscale Serve के माध्यम से पहुँचा जाता है, या यह स्पष्ट ऑथ के साथ सीधे टेलनेट IP से बाइंड होता है
3. आप सर्वर और अपने पर्सनल डिवाइस दोनों पर Tailscale इंस्टॉल करते हैं
4. आप OpenClaw को उसके Tailscale IP या MagicDNS नाम से एक्सेस करते हैं
5. इंटरनेट पर बाकी सभी को कुछ नहीं दिखता, जब तक आप जानबूझकर Funnel या कोई दूसरा सार्वजनिक प्रॉक्सी सक्षम नहीं करते

क्या आपको OpenClaw को Tailscale मैनेज करने देना चाहिए?

OpenClaw में बिल्ट-इन Tailscale इंटीग्रेशन है जो गेटवे के लिए tailscale serve या tailscale funnel कॉन्फ़िगर कर सकता है।

सर्व मोड चीज़ों को केवल आपके टेलनेट पर रखता है। गेटवे 127.0.0.1 से बंधा रहता है जबकि Tailscale राउटिंग और HTTPS को संभालता है। जब gateway.auth.allowTailscale सक्षम होता है, तो OpenClaw Tailscale आइडेंटिटी हैडर्स का उपयोग करके कंट्रोल UI/WebSocket ट्रैफ़िक को ऑथेंटिकेट कर सकता है और tailscale whois के साथ स्रोत को सत्यापित कर सकता है। यह ज़्यादातर पर्सनल डिप्लॉयमेंट के लिए सही मोड है।

फ़नल मोड गेटवे को Tailscale की सार्वजनिक एंडपॉइंट फ़ीचर के माध्यम से सार्वजनिक रूप से एक्सपोज़ करता है। Tailscale के अपने डॉक्स फ़नल को स्थानीय सेवा पर व्यापक इंटरनेट ट्रैफ़िक रूट करने के रूप में वर्णित करते हैं। OpenClaw फ़नल को तब तक शुरू करने से मना कर देता है जब तक गेटवे ऑथ मोड password न हो, लेकिन फिर भी आप ऑपरेटर सरफेस के लिए सार्वजनिक एक्सपोज़र चुन रहे हैं।

OpenClaw की सुरक्षा दस्तावेज़ीकरण स्पष्ट है कि प्रॉम्प्ट इंजेक्शन और टूल एक्सेस पर्सनल असिस्टेंट के लिए मुख्य जोखिम हैं। एजेंट को चुपचाप खुद को सार्वजनिक बनाने का रास्ता न दें। सर्व का विवेकपूर्ण उपयोग करें, फ़नल से बचें जब तक आपको वास्तव में सार्वजनिक एक्सेस की ज़रूरत न हो, और किसी भी tailscale कमांड के लिए एक्जीक्यूशन अप्रूवल की आवश्यकता रखें।

OpenClaw को सुरक्षित रूप से सेट अप करना

चरण 1: Tailscale इंस्टॉल करें

अपने VPS या लोकल सर्वर पर:

# Install Tailscale
curl -fsSL https://tailscale.com/install.sh | sh

# Authenticate (opens a browser to log in)
sudo tailscale up

# Get your Tailscale IP
tailscale ip -4
# Output: 100.x.x.x

अपने क्लाइंट मशीन पर, आधिकारिक डाउनलोड पेज से Tailscale इंस्टॉल करें और उसी टेलनेट में साइन इन करें।

अब दोनों मशीनें एक ही प्राइवेट नेटवर्क पर हैं। आप अपने VPS को उसके Tailscale IP से पिंग कर सकते हैं, और यह एन्क्रिप्टेड टनल के माध्यम से रूट होगा।

चरण 2: OpenClaw को Tailscale उपयोग के लिए कॉन्फ़िगर करें

वर्तमान सबसे सुरक्षित पैटर्न है: गेटवे को लूपबैक पर रखें और Tailscale Serve के साथ उसे अपने टेलनेट के लिए एक्सपोज़ करें।

OpenClaw कॉन्फ़िग में:

{
  gateway: {
    bind: "loopback",
    tailscale: { mode: "serve" },
  },
}

फिर सर्व के साथ गेटवे शुरू करें:

openclaw gateway --tailscale serve

OpenClaw के डॉक्स कहते हैं कि यह गेटवे को 127.0.0.1 पर रखता है जबकि Tailscale HTTPS और टेलनेट राउटिंग प्रदान करता है। आप इसे अपने सार्वजनिक VPS IP पर नहीं, बल्कि https://<magicdns-name>/ पर खोलते हैं।

अगर आप सर्व के बजाय सीधे टेलनेट बाइंड पसंद करते हैं, तो स्पष्ट गेटवे ऑथ का उपयोग करें:

{
  gateway: {
    bind: "tailnet",
    auth: {
      mode: "token",
      token: "replace-with-a-long-random-token",
    },
  },
}

फिर किसी दूसरे टेलनेट डिवाइस से कनेक्ट करें:

http://<tailscale-ip>:18789/
ws://<tailscale-ip>:18789

अगर आप Docker या किसी दूसरे कंटेनर रनटाइम में चला रहे हैं, तो पोर्ट पब्लिशिंग के प्रति अतिरिक्त सावधान रहें। -p 18789:18789 जैसा पब्लिश आमतौर पर सभी होस्ट इंटरफेस पर बाइंड होता है। लूपबैक प्लस Tailscale Serve को प्राथमिकता दें, या होस्ट साइड को स्पष्ट रूप से Tailscale IP पर बाइंड करें, यह पुष्टि करने के बाद कि कंटेनर को अभी भी ट्रैफ़िक मिल रहा है:

TAILSCALE_IP=$(tailscale ip -4)
docker run ... -p "$TAILSCALE_IP:18789:18789" ...

किसी भी Docker बदलाव के बाद, nmap से बाहर से और ss से लोकली जाँचें। Docker होस्ट फ़ायरवॉल धारणाओं को बायपास या पुनः क्रमित कर सकता है अगर आप इसे ध्यान में नहीं रखते।

चरण 3: SSH को लॉक करें

Tailscale के साथ भी, आपको SSH को ठीक से सुरक्षित करना चाहिए:

# Keep your current SSH session open while doing this.
# First, from your client machine, confirm you can SSH over Tailscale:
ssh your-user@SERVER_TAILSCALE_IP

# Put hardening in a drop-in file instead of rewriting sshd_config.
sudo tee /etc/ssh/sshd_config.d/99-openclaw-hardening.conf >/dev/null <<'EOF'
PasswordAuthentication no
PermitRootLogin no
KbdInteractiveAuthentication no
EOF

# Validate before reloading. Do not skip this.
sudo sshd -t
sudo systemctl reload ssh || sudo systemctl reload sshd

यह पासवर्ड-आधारित लॉगिन और रूट लॉगिन को अक्षम करता है। अगला चरण सार्वजनिक SSH को पूरी तरह से रोकने के लिए UFW का उपयोग करता है, जबकि tailscale0 पर SSH की अनुमति देता है।

चरण 4: फ़ायरवॉल नियम

दूसरी परत के रूप में फ़ायरवॉल सेट अप करें:

# Using UFW (Ubuntu/Debian)
sudo ufw allow in on tailscale0
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw enable
sudo ufw delete allow 22/tcp || true
sudo ufw reload
sudo ufw status verbose

Tailscale के अपने Ubuntu हार्डनिंग गाइड में इसी आकार का उपयोग किया गया है: tailscale0 की अनुमति दें, अन्य इनबाउंड ट्रैफ़िक को अस्वीकार करें, फिर सत्यापित करें कि सार्वजनिक SSH टाइमआउट होता है जबकि 100.x.y.z पते पर SSH अभी भी काम करता है। अगर आप उसी VPS पर सार्वजनिक वेबसाइट चलाते हैं, तो केवल उन्हीं सार्वजनिक नियमों को रखें जिनकी वास्तव में ज़रूरत है, जैसे 80/tcp और 443/tcp।

अपने एक्सपोज़र की जाँच करना

बाहर से ओपन पोर्ट्स की जाँच करें

उस मशीन से जो आपके Tailscale नेटवर्क पर नहीं है:

# Check if common public ports are exposed
nmap -p 22,80,443,18789 YOUR_PUBLIC_IP

# Expected output for a secured instance:
# 22/tcp   filtered ssh
# 18789/tcp filtered unknown

अगर 22 या 18789 के बजाय filtered या closed के बजाय open दिखता है, तो आपके पास समस्या है। अगर 80 या 443 खुला है, तो सुनिश्चित करें कि यह केवल आपकी जानबूझकर बनाई गई सार्वजनिक वेबसाइट या Tailscale Funnel एंडपॉइंट है, गलती से OpenClaw गेटवे नहीं।

लोकली क्या चल रहा है इसकी जाँच करें

अपने OpenClaw सर्वर पर:

# Show all listening ports and what they're bound to
sudo ss -tulpn | grep LISTEN

# Look for lines like this (good for Serve):
# tcp   LISTEN 0   128   127.0.0.1:18789   *:*
#
# Or this (acceptable for direct tailnet bind with auth):
# tcp   LISTEN 0   128   100.x.y.z:18789   *:*
#
# NOT like this (bad):
# tcp   LISTEN 0   128   0.0.0.0:18789     *:*

अगर आपको 0.0.0.0 या ::: (IPv6 समकक्ष) दिखता है, तो वह सेवा दुनिया के लिए एक्सपोज़्ड है।

बिल्ट-इन सुरक्षा ऑडिट

OpenClaw में एक सुरक्षा ऑडिट कमांड शामिल है जो आपके कॉन्फ़िगरेशन की सुरक्षा सर्वोत्तम प्रथाओं के खिलाफ़ जाँच करता है:

openclaw security audit --deep
openclaw security audit --deep --fix

ऑडिट गेटवे एक्सपोज़र, Tailscale मोड, ऑथ सेटिंग्स, चैनल एक्सेस, टूल पॉलिसी, प्लगइन इन्वेंटरी और फ़ाइल अनुमतियों की जाँच करता है। --fix को उपयोगी सहायक मानें, फाइंडिंग्स को पढ़ने के विकल्प के रूप में नहीं।

यह क्या हल नहीं करता

Tailscale सबसे बड़ी गलती को हटा देता है: सार्वजनिक ऑपरेटर एक्सपोज़र। यह सब कुछ हल नहीं करता:

क्रेडेंशियल स्टोरेज: OpenClaw सेशन ट्रांसक्रिप्ट, OAuth टोकन और API कीज़ को डिस्क पर स्टोर करता है। सुनिश्चित करें कि इनके उचित फ़ाइल अनुमतियाँ हैं (फ़ाइलों के लिए chmod 600, प्राइवेट कॉन्फ़िग डायरेक्टरीज़ के लिए chmod 700) और ये वर्शन कंट्रोल में नहीं हैं। बिल्ट-इन ऑडिट इसकी जाँच करता है।

प्लगइन सैंडबॉक्सिंग: प्लगइन्स आपकी उपयोगकर्ता की पूर्ण अनुमतियों के साथ चलते हैं। केवल उन्हीं स्रोतों से प्लगइन्स इंस्टॉल करें जिन पर आप भरोसा करते हैं, और समीक्षा करें कि वे कौन सी क्षमताएँ अनुरोध करते हैं। ऑडिट टूल इंस्टॉल किए गए प्लगइन्स की सूची बनाता है।

डिवाइस सुरक्षा: अगर कोई आपके Tailscale अकाउंट को समझौता करता है या आपके टेलनेट पर डिवाइस चुराता है, तो वह आपके OpenClaw इंस्टेंस को एक्सेस कर सकता है। नए डिवाइस के लिए अप्रूवल की आवश्यकता रखने के लिए Tailscale डिवाइस ऑथराइज़ेशन सक्षम करें।

डिप्लॉयमेंट चेकलिस्ट

अपने OpenClaw/Moltbot इंस्टेंस को प्रोडक्शन-रेडी मानने से पहले:

• सर्वर और क्लाइंट दोनों पर Tailscale इंस्टॉल और ऑथेंटिकेट किया गया
• गेटवे को Tailscale Serve के साथ लूपबैक पर रखा गया, या स्पष्ट ऑथ के साथ tailnet से बाइंड किया गया
• SSH को पासवर्ड ऑथ और रूट लॉगिन अक्षम करने के लिए कॉन्फ़िगर किया गया
• फ़ायरवॉल (UFW या iptables/nftables) को tailscale0 की अनुमति देने और अनावश्यक सार्वजनिक इनग्रेस को अस्वीकार करने के लिए कॉन्फ़िगर किया गया
• बाहरी nmap स्कैन सभी पोर्ट्स को filtered या closed दिखाता है
• आंतरिक ss -tulpn गेटवे को केवल 127.0.0.1, ::1, या Tailscale IP पर बाइंड दिखाता है
• क्रेडेंशियल फ़ाइलों में 600 अनुमतियाँ और प्राइवेट कॉन्फ़िग डायरेक्टरीज़ में 700 अनुमतियाँ हैं
• openclaw security audit --deep चलाया गया और सभी फाइंडिंग्स को संबोधित किया गया
• अगर OpenClaw Tailscale मैनेजमेंट का उपयोग कर रहे हैं, तो एक्जीक्यूशन अप्रूवल सक्षम हैं
• नियमित बैकअप कॉन्फ़िगर किया गया (OpenClaw डेटा + कॉन्फ़िग्स)

संसाधन

• OpenClaw Security Guide
• OpenClaw Tailscale Integration
• Tailscale Serve CLI Reference
• Tailscale Funnel
• Use UFW to Lock Down an Ubuntu Server
• Security Audit: 512 Findings (GitHub Issue)
• Nmap Network Scanning Guide