VPS پر OpenClaw کو محفوظ طریقے سے کیسے چلائیں

OpenClaw کیا ہے، اور اسے پہلے سخت محفوظ کیوں کرنا چاہیے

OpenClaw ایک self-hosted AI agent ہے۔ آپ اسے اپنے سرور پر چلاتے ہیں، اسے کسی large language model سے جوڑتے ہیں، اور یہ shell commands چلا سکتا ہے، browser کو کنٹرول کر سکتا ہے، آپ کی files پڑھ اور لکھ سکتا ہے، اور chat apps سے بھیجے گئے آپ کے messages پر کارروائی کر سکتا ہے۔ اس tool کی پوری افادیت اسی رسائی پر مبنی ہے، اور یہی اس کا مکمل خطرہ بھی ہے۔ جو agent کوئی بھی command چلا سکتا ہو، وہ اتنا ہی محفوظ ہوتا ہے جتنا وہ system جس پر یہ چل رہا ہے اور وہ حدود جو آپ نے اس کے گرد مقرر کی ہیں۔

اس guide کا رخ 2 حقائق متعین کرتے ہیں۔ اول، OpenClaw اس طرح بنایا گیا ہے کہ اسے آپ خود سخت محفوظ کریں۔ اس کا security model مضبوط tool policies، sandboxing اور محتاط permissions کی ذمہ داری کسی محفوظ default کے بجائے operator پر ڈالتا ہے۔ دوم، project کو پہلے ہی ایک سنگین security event کا سامنا ہو چکا ہے: مارچ 2026 میں 4 دن کے اندر 9 security issues ظاہر کیے گئے، جن میں ایک critical privilege-escalation flaw، CVE-2026-32922، بھی شامل تھا، جسے 10 میں سے 9.9 کی severity دی گئی۔ ان میں سے کوئی بھی حقیقت یہ نہیں کہتی کہ آپ کو OpenClaw سے گریز کرنا چاہیے۔ ان کا مطلب یہ ہے کہ آپ اسے لاپرواہی سے نہ چلائیں، اور یہ guide محتاط طریقہ فراہم کرتی ہے۔ محتاط طریقے کا ایک حصہ یہ پہلے سے طے کرنا ہے کہ agent آپ سے پوچھے بغیر کتنا کام کر سکتا ہے۔ یہ وہ فیصلہ ہے جسے Claude Code اپنے permission modes میں واضح کرتا ہے، کیونکہ جس server کے سامنے آپ موجود نہیں ہوتے اسے اس laptop کے مقابلے میں زیادہ سخت setting درکار ہوتی ہے جسے آپ خود دیکھ رہے ہوں۔

اچھی خبر بھی ہے۔ OpenClaw پہلے ہی آپ کے لیے ایک محفوظ فیصلہ کرتا ہے: اس کا gateway، یعنی وہ واحد process جو ہر چیز کو کنٹرول کرتا ہے، default طور پر loopback address پر listening کرتا ہے، اس لیے یہ internet سے قابل رسائی نہیں ہوتا، جب تک آپ خاص طور پر اسے expose نہ کریں۔ ذیل میں زیادہ تر کام اسی حالت کو برقرار رکھنے اور کسی خرابی کی صورت میں نقصان کے دائرے کو محدود کرنے سے متعلق ہے۔

OpenClaw کے لیے اپنا غیر مراعات یافتہ صارف بنائیں

کسی agent کو root کے طور پر کبھی نہ چلائیں۔ اگر OpenClaw root کے طور پر چل رہا ہو اور کوئی مسئلہ پیش آ جائے، خواہ وہ bug ہو، غلط instruction ہو، یا اوپر بیان کردہ CVE جیسا مسئلہ، تو نقصان کی کوئی حد نہیں رہتی۔ ایک dedicated system user بنائیں، جس کے پاس login shell اور sudo نہ ہو، اور agent کو اسی صارف کے طور پر چلائیں:

sudo useradd --system --home /opt/openclaw --shell /usr/sbin/nologin openclaw

OpenClaw کی ملکیت کی تمام چیزیں /opt/openclaw کے تحت رہتی ہیں اور اسی account کی ملکیت ہوتی ہیں۔ یہ سب سے اہم قدم ہے۔ یہی اصول غیر مراعات یافتہ صارف کے طور پر services چلانا میں بھی بیان کیا گیا ہے: agent جس account کے طور پر چلتا ہے، وہی اس نقصان کی حد مقرر کرتا ہے جو agent کر سکتا ہے۔

OpenClaw انسٹال کریں

OpenClaw ایک npm package کے طور پر تقسیم کیا جاتا ہے، اس لیے اگر سرور پر Node.js موجود نہ ہو تو پہلے اسے انسٹال کریں۔ package کو globally انسٹال کریں۔ اس سے openclaw binary ہر user کے لیے PATH میں شامل ہو جاتی ہے۔ اس کے بعد ایک بار onboarding step چلائیں:

sudo npm install -g openclaw@latest
sudo -u openclaw openclaw onboard

onboarding کو openclaw user کے طور پر چلانے سے agent کی configuration اس کی home directory، /opt/openclaw، میں محفوظ ہوتی ہے، root کی home directory میں نہیں۔ پروجیکٹ ایک curl -fsSL https://openclaw.ai/install.sh | bash installer بھی فراہم کرتا ہے، جو یہی installation ایک command میں مکمل کر دیتا ہے۔ onboarding کے دوران --install-daemon flag استعمال نہ کریں۔ اس سے OpenClaw کی اپنی service رجسٹر ہو جائے گی، جبکہ ذیل میں بنائی جانے والی hardened systemd unit زیادہ سخت پابندیاں نافذ کرتی ہے۔

گیٹ وے کو loopback پر، firewall کے پیچھے رکھیں

گیٹ وے بطور ڈیفالٹ 127.0.0.1 پر bind ہوتا ہے۔ اسے وہیں رہنے دیں۔ اس port کو internet پر publish کرنے کی تقریباً کبھی ضرورت نہیں ہوتی۔ ایسا کرنے سے ہر وہ شخص جسے یہ port مل جائے، اس process تک remote foothold حاصل کر سکتا ہے جو commands چلاتا ہے۔

مشین کے سامنے default-deny firewall لگائیں، تاکہ کوئی چیز غلطی سے expose نہ ہو:

sudo ufw default deny incoming
sudo ufw allow 22/tcp
sudo ufw enable

یہاں دو غلطیوں سے بچیں۔ جو firewall صرف IPv4 کا احاطہ کرتا ہے، وہی service IPv6 پر مکمل طور پر کھلی چھوڑ سکتا ہے۔ یہی وہ IPv6 firewall خلا ہے جس کی وجہ سے بہت سے لوگ متاثر ہوتے ہیں۔ اگر آپ کو اپنے laptop سے گیٹ وے تک رسائی درکار ہو تو port نہ کھولیں۔ VPN یا SSH tunnel کے ذریعے رسائی حاصل کریں، تاکہ agent کبھی بھی open internet پر listening نہ کرے۔

اس کے secrets کو الگ رکھیں

OpenClaw کو اس language model کے لیے API key درکار ہوتی ہے جس سے آپ اسے منسلک کرتے ہیں۔ یہ key آپ کی رقم خرچ کر سکتی ہے اور agent کے ذریعے آپ کی طرف سے کارروائی بھی کر سکتی ہے، اس لیے اسے password سمجھیں۔ اسے unit file اور کسی بھی repository سے باہر رکھیں۔ اسے ایسی file میں محفوظ کریں جسے صرف OpenClaw user پڑھ سکے:

sudo install -o openclaw -g openclaw -m 600 /dev/null /opt/openclaw/openclaw.env
sudoedit /opt/openclaw/openclaw.env      # add ANTHROPIC_API_KEY=... or your model provider's key

systemd unit اس file کو EnvironmentFile کے ذریعے load کرتی ہے۔ اس طرح key command line، log یا shell history میں محفوظ ہوئے بغیر process تک پہنچ جاتی ہے۔ یہی طریقہ server کے ہر secret پر لاگو ہوتا ہے۔ self-hosted Vaultwarden کی hardening کا جائزہ اس کے encryption کے بجائے admin token اور backup file تک محدود نہیں ہوتا، کیونکہ اصل میں file permissions ہی طے کرتی ہیں کہ rest پر محفوظ secret کو کون پڑھ سکتا ہے۔

اسے hardened systemd service کے طور پر چلائیں

agent کو systemd کے تحت چلانے سے خودکار restarts، journalctl کے ذریعے منظم logs، اور سب سے اہم، kernel-level sandboxing options کا مجموعہ ملتا ہے۔ یہ options process کی رسائی کو محدود کرتے ہیں، چاہے وہ breached ہی کیوں نہ ہو۔ agent کے لیے سب سے اہم options NoNewPrivileges ہیں، تاکہ اسے کبھی نئی powers حاصل نہ ہوں؛ ProtectSystem=strict، تاکہ filesystem صرف ان مقامات کے علاوہ read-only رہے جہاں آپ writes کی اجازت دیں؛ PrivateTmp، اس کی اپنی isolated temporary directory کے لیے؛ اور ProtectHome، تاکہ یہ home directories کو نہ پڑھ سکے۔

یہاں ایک مکمل hardened unit بنائیں، پھر اسے /etc/systemd/system/openclaw.service میں copy کریں:

یہ unit openclaw gateway کو start کرتا ہے، جو agent کو control کرنے والا long-running process ہے؛ اگر which openclaw آپ کے server پر مختلف path دکھائے تو ExecStart کو اسی کے مطابق تبدیل کریں۔ ان directives، نیز daemon-reload اور enable --now کی مکمل وضاحت systemd service کے طور پر program چلانا میں موجود ہے۔ unit paste کرنے کے بعد مختصر طریقہ یہ ہے:

sudo systemctl daemon-reload
sudo systemctl enable --now openclaw

بیرونی رسائی کا دروازہ بھی محفوظ کریں

Agent box کی سکیورٹی اس کے گرد موجود server جتنی ہی مضبوط ہوتی ہے۔ کام مکمل کرنے کے لیے مزید 2 تہیں شامل کریں۔ SSH کو صرف cryptographic key authentication پر منتقل کریں اور root login بند کریں، جیسا کہ VPS پر SSH کو مضبوط بنانا میں بیان کیا گیا ہے۔ اس طرح جس account سے آپ box کو administer کرتے ہیں، اسے brute-force attack کا نشانہ نہیں بنایا جا سکے گا۔ پھر Fail2ban شامل کریں تاکہ ہر public port پر بار بار scan کرنے والے scanners کو روک دیا جائے۔ ان دونوں اقدامات سے OpenClaw براہ راست متاثر نہیں ہوتا، لیکن وہ ان راستوں کو بند کر دیتے ہیں جنہیں attacker اس تک پہنچنے کے لیے استعمال کر سکتا ہے۔

جان بوجھ کر اسے تازہ ترین رکھیں

مارچ 2026 میں سامنے آنے والی معلومات موجودہ ورژن استعمال کرتے رہنے کی سب سے واضح وجہ ہیں۔ کسی agent میں privilege escalation کا bug عام web app کے مقابلے میں کہیں زیادہ سنگین ہوتا ہے، کیونکہ agent پہلے ہی commands چلا رہا ہوتا ہے۔ project کی releases پر نظر رکھیں، security updates جلد لاگو کریں، اور OpenClaw upgrade کو معمول کی maintenance سمجھیں، نہ کہ ایسی چیز جسے مؤخر کیا جائے۔

یہ سمجھنے کے لیے کہ آپ حقیقت میں کس چیز کو harden کر رہے ہیں، OpenClaw طرز کے agent کا architecture مختلف اجزا کی وضاحت کرتا ہے، جبکہ VPS پر اپنا AI agent بنانا ہر agent کی عمومی ساخت بیان کرتا ہے۔ اگر آپ اس کے ساتھ دوسرا agent بھی چلائیں تو یاد رکھیں کہ ایک VPS پر دو Claude Code sessions ایک دوسرے کو کام دے سکتے ہیں۔ اس لیے ہر agent کے لیے الگ account اور الگ limits مقرر کریں، بجائے اس کے کہ وہ آپ کی settings inherit کرے۔

FAQ

کیا public VPS پر OpenClaw چلانا محفوظ ہے؟

اگر اسے harden کیا جائے تو ایسا کرنا ممکن ہے۔ OpenClaw کو طاقتور بنانے کے لیے ڈیزائن کیا گیا ہے: یہ shell commands چلاتا اور browser کو control کرتا ہے۔ اس لیے غیر محتاط setup حقیقی خطرہ بن سکتا ہے، اور project میں پہلے ہی ایک critical CVE موجود رہ چکا ہے (March 2026 میں CVE-2026-32922)۔ اس کا security model یہ توقع کرتا ہے کہ operator خود حدود نافذ کرے۔ اسے unprivileged user کے طور پر چلائیں، اس کے gateway کو loopback پر رکھ کر default-deny firewall کے پیچھے محفوظ کریں، اس کی API keys الگ رکھیں، اور اسے hardened systemd service کے طور پر چلائیں۔

کیا OpenClaw gateway کو internet پر expose کرنا چاہیے؟

نہیں۔ gateway default طور پر loopback پر bind ہوتا ہے، اور آپ کو اسے وہیں رہنے دینا چاہیے۔ یہی وہ واحد process ہے جو agent کو control کرتا ہے، اس لیے exposed gateway ایسے نظام تک remote راستہ فراہم کرتا ہے جو commands چلاتا ہے۔ اگر آپ کو اسے remote طور پر access کرنا ہو تو port کھولنے کے بجائے VPN یا SSH tunnel استعمال کریں۔

OpenClaw کو کس user کے طور پر چلانا چاہیے؟

ایک dedicated system user کے طور پر، جس کے پاس login shell اور sudo نہ ہو؛ اسے کبھی root کے طور پر نہ چلائیں۔ اگر agent compromise ہو جائے تو اس کا user account نقصان کی زیادہ سے زیادہ حد متعین کرتا ہے۔ اس لیے اس account کو صرف اپنی files کا مالک ہونا چاہیے، مثلاً /opt/openclaw کے تحت، اور کسی دوسری file کا نہیں۔

OpenClaw کی API keys کو کیسے محفوظ رکھوں؟

انہیں ایسی file میں محفوظ کریں جسے صرف OpenClaw user پڑھ سکے (mode 600)، اور systemd کے EnvironmentFile کے ذریعے اسے service میں load کریں۔ key کو unit file، shell history اور کسی بھی git repository سے باہر رکھیں۔ اگر کبھی شبہ ہو کہ key leak ہو گئی ہے تو اسے rotate کریں۔