نصب امن OpenClaw روی VPS با systemd و firewall
OpenClaw میتواند فرمان shell اجرا و وب را مرور کند. این راهنما اجرای امن روی VPS را با کاربر غیرمجاز، firewall، مدیریت secrets و systemd توضیح میدهد؛ با توجه به 199 CVE در March 2026.
OpenClaw چیست و چرا باید ابتدا آن را سختسازی کنید
OpenClaw یک عامل هوش مصنوعی self-hosted است. آن را روی سرور خود اجرا میکنید، به یک مدل زبانی بزرگ متصلش میکنید و این عامل میتواند فرمانهای shell را اجرا کند، یک browser را کنترل کند، فایلهای شما را بخواند و بنویسد و بر اساس پیامهایی که از طریق برنامههای chat برایش میفرستید، اقدام کند. همین دامنهٔ دسترسی هدف اصلی این ابزار و در عین حال، کل ریسک آن است. عاملی که میتواند هر فرمانی را اجرا کند، فقط بهاندازهٔ سیستم میزبان و محدودیتهایی که برایش تعیین میکنید امن است.
دو واقعیت، رویکرد این راهنما را مشخص میکنند. نخست، OpenClaw بهگونهای طراحی شده است که شما آن را سختسازی کنید. مدل امنیتی آن، مسئولیت اعمال policyهای دقیق برای ابزارها، sandboxing و مجوزهای محتاطانه را بر عهدهٔ operator میگذارد، نه یک تنظیم پیشفرض امن. دوم، این پروژه تاکنون با یک وضعیت امنیتی جدی روبهرو بوده است: National Vulnerability Database تعداد 199 مورد CVE مربوط به OpenClaw را گزارش میکند که فقط در March 2026 منتشر شدهاند؛ 46 مورد از آنها در چهار روز، از 4 تا 7 March، منتشر شدهاند (تعدادها در 13 October 2026 بررسی شدهاند). یکی از نقصهای همان ماه، یک privilege escalation بحرانی با شناسهٔ CVE-2026-32922 است که امتیاز 9.9 از 10 گرفته و در نسخهٔ 2026.3.11 برطرف شده است. هیچیک از این دو واقعیت به این معنا نیست که باید از OpenClaw اجتناب کنید. معنای آن این است که نباید آن را به روش سهلانگارانه اجرا کنید؛ این راهنما روش محتاطانه را ارائه میدهد. بخشی از این روش محتاطانه، تصمیمگیری از پیش دربارهٔ میزان اقداماتی است که agent میتواند بدون پرسیدن اجازه انجام دهد؛ انتخابی که Claude Code آن را با permission modeهای خود صریح میکند و در آن، سروری که روبهروی آن ننشستهاید به تنظیم محدودکنندهتری از لپتاپی که در حال نظارت بر آن هستید نیاز دارد.
خبر خوب این است که OpenClaw یک انتخاب امن را از قبل برای شما انجام میدهد: gateway آن، یعنی تنها فرایندی که همهچیز را کنترل میکند، بهطور پیشفرض روی loopback address گوش میدهد؛ بنابراین از اینترنت قابل دسترسی نیست، مگر اینکه عمداً آن را در معرض دسترسی قرار دهید. بیشتر کارهای زیر برای حفظ همین وضعیت و محدودکردن دامنهٔ اثرگذاری در صورت بروز مشکل انجام میشوند.
ایجاد یک کاربر بدون دسترسی ویژه برای OpenClaw
هرگز یک agent را با کاربر root اجرا نکنید. اگر OpenClaw با دسترسی root اجرا شود و مشکلی پیش بیاید—خواه یک باگ باشد، یک دستور مخرب یا یک CVE مانند مورد بالا—هیچ محدودیتی برای میزان خسارت وجود نخواهد داشت. یک کاربر سیستمی اختصاصی بدون shell ورود و بدون دسترسی sudo ایجاد کنید و agent را با همان کاربر اجرا نمایید:
sudo useradd --system --home /opt/openclaw --shell /usr/sbin/nologin openclawتمام داراییهای OpenClaw در مسیر /opt/openclaw قرار دارند و مالکیت آنها متعلق به همان حساب کاربری است. این مهمترین گام است و از همان اصلی پیروی میکند که در اجرای سرویسها با کاربر بدون دسترسی ویژه توضیح داده شد: حسابی که یک agent با آن اجرا میشود، سقف توانایی آن برای ایجاد خرابی را تعیین میکند.
OpenClaw را نصب کنید
OpenClaw بهصورت یک npm package توزیع میشود؛ بنابراین اگر سرور Node.js ندارد، ابتدا آن را نصب کنید. پروژه به Node 24.16 یا جدیدتر، یا 26.1 یا جدیدتر، نیاز دارد. package را بهصورت global نصب کنید تا binary با نام openclaw برای همهٔ userها روی PATH قرار بگیرد، سپس مرحلهٔ یکبارهٔ onboarding را اجرا کنید:
sudo npm install -g openclaw@latest --allow-scripts=openclaw
sudo -u openclaw openclaw onboardوجود flag یعنی --allow-scripts=openclaw به این دلیل است که npm 12 بهطور پیشفرض scriptهای نصب package را مسدود میکند و OpenClaw برای اجرا به scriptهای خود نیاز دارد. در npm 11.15 یا قدیمیتر، که چنین optionای ندارد، این flag را حذف کنید. اجرای onboarding با user یعنی openclaw باعث میشود configuration عامل در home directory همان user، یعنی /opt/openclaw، قرار بگیرد، نه در home directory مربوط به root. پروژه همچنین installerای با نام curl -fsSL https://openclaw.ai/install.sh | bash ارائه میکند که همین نصب را در یک خط انجام میدهد. هنگام onboarding، flag یعنی --install-daemon را استفاده نکنید؛ این flag service خود OpenClaw را register میکند، در حالی که unit سختسازیشدهٔ systemd که در ادامه میسازید، محدودیتهای بیشتری دارد.
درگاه را روی loopback و پشت فایروال نگه دارید
درگاه بهصورت پیشفرض روی 127.0.0.1 گوش میدهد. آن را در همان وضعیت باقی بگذارید. تقریباً هیچ دلیلی برای انتشار این پورت روی اینترنت وجود ندارد؛ انجام این کار به هر کسی که آن را پیدا کند، یک جای پای از راه دور در فرآیندی میدهد که وظیفهاش اجرای دستورات است.
یک فایروال با سیاست default-deny در مقابل سرور قرار دهید تا هیچ سرویسی بهطور تصادفی در معرض دید قرار نگیرد:
sudo ufw default deny incoming
sudo ufw allow 22/tcp
sudo ufw enableدر اینجا باید از دو دام اجتناب کرد. فایروالی که فقط IPv4 را پوشش میدهد، میتواند همان سرویس را روی IPv6 کاملاً باز بگذارد، که دقیقاً همان شکاف فایروال IPv6 است که بسیاری از افراد را گرفتار میکند. همچنین اگر نیاز دارید از لپتاپ خود به درگاه دسترسی پیدا کنید، پورت را باز نکنید. از طریق یک VPN یا یک SSH tunnel به آن متصل شوید تا عامل (agent) هرگز روی اینترنت آزاد گوش ندهد.
ایزولهسازی اسرار
برنامه OpenClaw برای اتصال به هر مدل زبانی که انتخاب میکنید، به یک API key نیاز دارد. این کلید میتواند هزینه مالی برای شما ایجاد کند و از طریق عامل (agent) به جای شما عمل کند؛ بنابراین با آن مانند یک رمز عبور رفتار کنید. آن را در فایل unit یا هیچ مخزنی (repository) قرار ندهید. کلید را در فایلی بگذارید که فقط کاربر OpenClaw امکان خواندن آن را داشته باشد:
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فایل unit در systemd این فایل را با EnvironmentFile بارگذاری میکند، بنابراین کلید بدون اینکه در خط فرمان، لاگها یا تاریخچه shell شما باقی بماند، به پردازش میرسد. این الگو برای تمام اسرار موجود در سرور صادق است: یک بررسی امنیتی برای Vaultwarden خودمیزبان بیش از آنکه به رمزنگاری وابسته باشد، به توکن مدیریتی و فایل پشتیبان آن برمیگردد، زیرا مجوزهای فایل در نهایت تعیین میکنند که چه کسی میتواند یک راز ذخیرهشده را بخواند.
اجرای آن بهعنوان یک سرویس systemd امنسازیشده
اجرای agent تحت systemd، قابلیت راهاندازی مجدد خودکار، لاگهای تمیز از طریق journalctl و مهمتر از همه، مجموعهای از گزینههای sandbox در سطح هسته را در اختیار شما قرار میدهد که حتی در صورت نفوذ به پردازش، دسترسیهای آن را بهشدت محدود میکند. گزینههایی که برای یک agent بیشترین اهمیت را دارند عبارتند از: NoNewPrivileges تا پردازش هرگز نتواند امتیازات جدیدی کسب کند، ProtectSystem=strict تا سیستم فایل بهجز در مسیرهایی که اجازه نوشتن دادهاید، فقطخواندنی باشد، PrivateTmp برای داشتن یک دایرکتوری موقت ایزوله، و ProtectHome تا پردازش نتواند دایرکتوریهای home را بخواند.
یک unit کامل و امنسازیشده را در اینجا ایجاد کنید و سپس آن را در /etc/systemd/system/openclaw.service کپی کنید:
این unit، پردازش openclaw gateway را که یک پردازش طولانیمدت برای کنترل agent است، اجرا میکند؛ اگر which openclaw مسیر متفاوتی را در سرور شما نشان میدهد، ExecStart را مطابق با آن تغییر دهید. راهنمای کامل این دستورالعملها و همچنین daemon-reload و enable --now در اجرای یک برنامه بهعنوان سرویس systemd موجود است. خلاصه کار پس از جایگذاری unit:
sudo systemctl daemon-reload
sudo systemctl enable --now openclawامنسازی ورودی اصلی
امنیت یک سرور واسط (agent box) به اندازه امنیت کل سروری است که آن را میزبانی میکند. دو لایه دیگر کار را تکمیل میکنند. احراز هویت SSH را به حالت فقط-کلید (key-only) تغییر دهید و ورود کاربر root را غیرفعال کنید، همانطور که در سختسازی SSH روی VPS توضیح داده شده است؛ با این کار، حسابی که با آن سرور را مدیریت میکنید در برابر حملات brute-force ایمن میشود. سپس Fail2ban را اضافه کنید تا اسکنرهایی که تمام پورتهای عمومی را هدف قرار میدهند، مسدود شوند. هیچکدام از این موارد مستقیماً با OpenClaw در ارتباط نیستند، اما هر دو مسیرهایی را که یک مهاجم برای دسترسی به آن استفاده میکند، مسدود میکنند.
بهروزرسانی هدفمند و مستمر
افشای اطلاعات در مارس 2026، روشنترین دلیل برای بهروز ماندن است. یک باگ افزایش سطح دسترسی (privilege-escalation) در یک agent، بسیار جدیتر از یک برنامه وب معمولی است، زیرا agent در حال حاضر دستورات را اجرا میکند. نسخههای منتشرشده (releases) پروژه را زیر نظر داشته باشید، بهروزرسانیهای امنیتی را بهسرعت اعمال کنید و ارتقای OpenClaw را بهجای کاری که باید به تعویق بیفتد، بهعنوان بخشی از نگهداری روتین در نظر بگیرید.
برای درک اینکه دقیقاً چه چیزی را ایمنسازی میکنید، معماری یک agent به سبک OpenClaw اجزای متحرک آن را بررسی میکند و ساخت AI agent شخصی روی یک VPS ساختار کلی هر agent را توضیح میدهد. اگر در نهایت قصد دارید agent دومی را در کنار آن اجرا کنید، به یاد داشته باشید که دو نشست Claude Code روی یک VPS میتوانند کارها را به یکدیگر محول کنند؛ بنابراین هر کدام باید حساب کاربری و محدودیتهای خاص خود را داشته باشند و نباید دسترسیهای شما را به ارث ببرند.
FAQ
آیا اجرای OpenClaw روی یک VPS عمومی امن است؟
اگر آن را ایمنسازی (harden) کنید، میتواند امن باشد. OpenClaw ذاتاً ابزاری قدرتمند است: دستورات shell را اجرا میکند و یک مرورگر را کنترل میکند؛ بنابراین پیکربندی بیدقت آن واقعاً خطرناک است. این پروژه قبلاً یک CVE بحرانی داشته است (CVE-2026-32922 در مارس 2026). مدل امنیتی آن انتظار دارد که شما به عنوان مدیر سیستم، محدودیتها را اعمال کنید. آن را با یک کاربر بدون دسترسیهای ویژه (unprivileged) اجرا کنید، gateway آن را روی loopback و پشت یک فایروال با سیاست default-deny نگه دارید، کلیدهای API آن را ایزوله کنید و آن را به عنوان یک سرویس systemd ایمنشده اجرا کنید.
آیا باید gateway مربوط به OpenClaw را در معرض اینترنت قرار دهم؟
خیر. gateway بهصورت پیشفرض روی loopback متصل میشود و باید همانجا باقی بماند. این تنها فرآیندی است که agent را کنترل میکند؛ بنابراین یک gateway در معرض دید، مسیری از راه دور به چیزی است که وظیفهاش اجرای دستورات است. اگر نیاز دارید از راه دور به آن دسترسی داشته باشید، بهجای باز کردن پورت، از یک VPN یا SSH tunnel استفاده کنید.
OpenClaw باید با چه کاربری اجرا شود؟
با یک کاربر سیستمی اختصاصی که shell ورود ندارد و دسترسی sudo هم ندارد؛ هرگز از root استفاده نکنید. اگر agent مورد نفوذ قرار گیرد، حساب کاربری آن سقف میزان خسارت خواهد بود؛ بنابراین آن حساب باید فقط مالک فایلهای خودش در مسیری مانند /opt/openclaw باشد و هیچ دسترسی دیگری نداشته باشد.
چگونه کلیدهای API مربوط به OpenClaw را امن نگه دارم؟
آنها را در فایلی ذخیره کنید که فقط توسط کاربر OpenClaw قابل خواندن باشد (با مجوز 600) و آن را با استفاده از EnvironmentFile در systemd به سرویس تزریق کنید. کلید را خارج از فایل unit، خارج از تاریخچه shell و خارج از هرگونه مخزن git نگه دارید. اگر به نشت کلید مشکوک شدید، آن را تغییر دهید (rotate).