أمان OpenClaw و Clawdbot: دليل التحصين الشامل والمخاطر

استضافة OpenClaw (المعروف سابقاً بـ Moltbot/Clawdbot) ذاتياً قد تتحول إلى حادث أمني بسرعة البرق. رأيت هذا السيناريو يتكرر كثيراً: منفذ واحد مكشوف، أو وضع غير آمن، أو تثبيت مهارة "مفيدة" إضافية، وفجأة يمتلك المهاجم القدرة على تنفيذ الأدوات وسرقة الرموز (Tokens) الخاصة بك. التقارير العامة تظهر تعرضاً واسعاً للإنترنت، بما في ذلك إحصائية تشير إلى حوالي 42,665 نسخة يمكن الوصول إليها، لذا فإن المسح العشوائي الانتهازي هو التهديد الأساسي هنا، وليس مجرد حالات نادرة.

يضع هذا الدليل مساراً لتعزيز الحماية (Hardening) يفترض أنك تريد قوة OpenClaw دون أن ترث نطاق الضرر الافتراضي الخاص به.

نموذج تهديد OpenClaw في 3 كلمات: Root, Agency, Keys

textCopy
Root: هل يمكن للعميل (Agent) كسر حدود الحاوية أو الوصول إلى المضيف (Host)؟
Agency: هل يمكن للعميل فعل أكثر مما ينبغي (أدوات، شبكة، مهارات)؟
Keys: هل يمكن للعميل أو المهاجم سرقة بيانات الاعتماد (البيئة، السجلات، الأقراص)؟

أفضل هذا النموذج لأنه يظل مفيداً حتى مع تغير التحذيرات الأمنية. أي ثغرة CVE جديدة تقع دائماً تقريباً في إحدى هذه الخانات، مما يخبرك بسرعة أي ضابط أمني كان سيوقفها (أو على الأقل يجعل استغلالها أصعب بكثير).

فشل الـ Root يأتي عادةً من الحاويات ذات الامتيازات (Privileged Containers)، وتركيب Docker socket، وصلاحيات Linux الواسعة. أما فشل الـ Agency فيميل للظهور بسبب "تضخم الأدوات" (السماح بإجراءات كثيرة جداً) و"تضخم الشبكة" (العميل يمكنه الوصول لأي شيء). بينما فشل الـ Keys هو الكلاسيكية التي لا تزال تلدغ الفرق التقنية: رموز في متغيرات البيئة (Env Vars)، سجلات التصحيح (Debug Logs)، التخزين المحلي غير المشفر، وبيانات اعتماد سحابية بصلاحيات واسعة جداً.

زادت الثغرات الخطيرة وأنماط الاستغلال النشطة من إلحاح الموقف في أوائل عام 2026، بما في ذلك سلسلة هجوم "النقرة الواحدة" التي تم الإبلاغ عن إصلاحها في إصدار v2026.1.29 مع توجيهات بالتحديث وتدوير الرموز: The Hacker News، تحذير جامعة تورنتو. تشمل العيوب الأخرى التي تم الإبلاغ عنها حقن الأوامر ومسارات التنفيذ عن بعد (RCE) (مثال: CVE-2026-24763) ومخاوف التعامل مع البوابة (Gateway) وصندوق الرمل (Sandbox) التي ناقشتها Tenable.

التعرض للإنترنت هو أسرع طريق للخسارة: اربط، استخدم بروكسي، وجدار حماية

bashCopy
# نمط التعرض الأدنى: اربط البوابة (Gateway) بالشبكة المحلية فقط (Loopback)
# استبدل [OPENCLAW_PORT] بالمنفذ الخاص بك (مثال: 3000)
docker run --rm -p 127.0.0.1:[OPENCLAW_PORT]:[OPENCLAW_PORT] [IMAGE]:[TAG]

الربط بـ 127.0.0.1 يجبر كل الوصول على المرور عبر المضيف المحلي. بصراحة، هذه الحركة الوحيدة تقضي على أكثر أنماط الفشل شيوعاً التي تلتقطها محركات بحث مثل Shodan: مستمع عام (Public Listener) مع مصادقة ضعيفة.

إذا كنت بحاجة إلى وصول عن بعد، قم بإنهاء تشفير TLS وفرض المصادقة عند الوكيل العكسي (Reverse Proxy). أبقِ OpenClaw خاصاً خلفه.

nginxCopy
## /etc/nginx/conf.d/openclaw.conf
server {
    listen 443 ssl;
    server_name [OPENCLAW_FQDN];

    ssl_certificate /etc/letsencrypt/live/[OPENCLAW_FQDN]/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/[OPENCLAW_FQDN]/privkey.pem;

    # ترويسات الحماية الأساسية
    add_header X-Content-Type-Options nosniff always;
    add_header X-Frame-Options DENY always;
    add_header Referrer-Policy no-referrer always;

    location / {
        proxy_pass http://127.0.0.1:[OPENCLAW_PORT];

        # التوجيه الصحيح ليتمكن التطبيق من التحقق من المصدر والبروتوكول
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-Host $host;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

        # دعم WebSocket (شائع لواجهات العملاء الذكية)
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
}

هذا الإعداد مهم لأن الكثير من سلاسل الهجوم الواقعية تبدأ بشيء ممل مثل "مستخدم ينقر على رابط" أو "مهاجم يمكنه الوصول للبوابة"، ثم تتدحرج كرة الثلج لتصبح سرقة للرموز أو اختطاف للجلسة. حتى عندما يقوم التطبيق بإصدار التحديثات بسرعة، تمنحك طبقة البروكسي بوابة ثانية: TLS، قوائم السماح، ومعالجة متسقة للترويسات (Headers).

الآن ضع سياسة شبكة أمامه. إذا كان لديك نطاق IP ثابت للمسؤولين، افرضه في جدار الحماية.

bashCopy
# مثال: السماح فقط لعنوان CIDR الخاص بالشركة بالوصول للمنفذ 443
ufw default deny incoming
ufw allow from [CORP_CIDR] to any port 443 proto tcp
ufw enable

ضابط آخر يؤتي ثماره فعلاً في الممارسة العملية: افصل وصول واجهة إدارة المسؤولين (Admin UI) عن حركة مرور تنفيذ العميل (Agent Execution). اجعل الواجهة متاحة فقط عبر VPN، وأبقِ واجهات برمجة التطبيقات (APIs) الخاصة بوقت التشغيل خاصة. هذا الفصل غالباً ما يوقف تحول "استغلال الواجهة العابر" إلى "عميل يشغل أدوات في بيئة الإنتاج".

حدّث بسرعة وقم بتدوير الرموز بجدية تامة

bashCopy
## جرد الإصدارات قيد التشغيل (مثال لـ Docker)
docker ps --format 'table {{.Names}}\t{{.Image}}\t{{.RunningFor}}'

# سحب وتشغيل إصدار ثابت معروف
docker pull [IMAGE]:v2026.1.29
docker stop [CONTAINER]
docker run -d --name [CONTAINER] [OTHER_FLAGS] [IMAGE]:v2026.1.29

الترقية أمر أساسي، لكن تدوير الرموز (Token Rotation) هو ما يقطع الطريق على الاستمرار. إذا سرق مهاجم رمز البوابة الأسبوع الماضي، فإن التحديث اليوم لن يبطل مفعول الرمز سحرياً.

قم بالتدوير في ثلاثة أماكن، بهذا الترتيب: رموز البوابة/الجلسة، مفاتيح API المستخدمة بواسطة المهارات/الأدوات، ثم بيانات اعتماد مزود السحابة. احتفظ بنفذة تداخل قصيرة فقط إذا كانت خدمتك لا تتحمل الإبطال الفوري.

bashCopy
# مسح سريع "لإيجاد الأسرار المحتملة" قبل عملية التدوير
# هذا يلتقط الخطأ الشائع: أسرار تم الالتزام بها (Committed) أو تسجيلها عن طريق الخطأ.
rg -n --hidden -S "OPENCLAW|CLAWDBOT|MOLTBOT|token|apikey|api_key|secret|bearer|Authorization" .

# إذا كانت السجلات على القرص، ابحث هناك أيضاً
sudo rg -n -S "bearer|token|Authorization" /var/log

إليك الأمر: الخطر الذي لا يحظى بالتقدير الكافي هو أن أنظمة العملاء الذكية (Agents) تنشئ مسارات أسرار جديدة. تطبيق الويب العادي لديه بضعة أسرار معروفة. أما العميل الذكي فلديه مفاتيح مزود النموذج، وبيانات اعتماد الأدوات، ورموز سجل المهارات، وأحياناً رموز تصحيح "مؤقتة" لا يتم تنظيفها أبداً (نعم، يحدث هذا أكثر مما يعترف به الناس).

لقراءة أعمق حول سلسلة "النقرة الواحدة" وإصدار الإصلاح، انظر: The Hacker News و تحذير جامعة تورنتو. لخطوات تخفيف أوسع وثغرات CVE متعددة، استخدم دليل Tenable.

المهارات والإضافات هي سلسلة توريد: عامل ClawHub مثل npm في 2016

bashCopy
## السياسة: تثبيت المهارات فقط من مستودع داخلي مسموح به
## مثال: حظر الوصول الخارجي إلى السجلات العامة من شبكة وقت التشغيل
iptables -A OUTPUT -p tcp -d [PUBLIC_REGISTRY_IP_OR_CIDR] --dport 443 -j REJECT

سأبدأ من موقف الرفض لأن النظام البيئي قد تم استغلاله بالفعل على نطاق واسع. تصف التقارير أكثر من 400 مهارة خبيثة تم توزيعها عبر سجل ClawHub (تم تأكيد 386 منها)، غالباً ما تكون متنكرة كأدوات تشفير وتستخدم لسرقة بيانات الاعتماد والمفاتيح: Security Affairs، بالإضافة إلى تغطية استهداف المؤسسات من Bitdefender.

التحول الفريد مع مهارات العملاء الذكية هو أن "تداخل التبعيات" (Dependency Confusion) ليس المشكلة الوحيدة. المهارة الخبيثة لا تحتاج إلى تنفيذ فساد في الذاكرة. إنها تحتاج فقط لاستدعاء الأدوات التي سمحت بها أنت بالفعل، ثم إرسال النتائج بهدوء للخارج عبر HTTPS.

اجعل المهارات تمر عبر بوابة قبل أن تصل إلى وقت التشغيل. البوابة العملية هي: تثبيت الإصدارات (Pinning)، التحقق من التجزئة (Hashes)، فحص الحزمة، وطلب مراجعة الكود. إذا لم تتمكن من فعل الأربعة، فافعل التثبيت والمراجعة كحد أدنى (ليس مثالياً، لكنه يحدث فرقاً).

yamlCopy
# skills-allowlist.yaml
allowed_skills:
  - name: [SKILL_NAME]
    version: "[PINNED_VERSION]"
    source: "[INTERNAL_REPO_URL]"
    sha256: "[EXPECTED_SHA256]"

blocked_patterns:
  - "crypto"
  - "wallet"
  - "seed"

نعم، يبدو هذا صارماً، لكنه ببساطة كيف تتعامل الفرق الناضجة مع إضافات CI ومزودي Terraform. المهارات هي تنفيذ للكود ولكن بعلامة تجارية.

قيّد الوكالة (Agency): ابنِ "ميزانيات للأدوات" وبوابات تأكيد

jsonCopy
{
  "tools": {
    "filesystem": {
      "allow": true,
      "read_paths": ["/workspace"],
      "write_paths": ["/workspace/out"],
      "deny_paths": ["/", "/etc", "/home", "/root", "/var/run/docker.sock"]
    },
    "shell": {
      "allow": true,
      "allowed_commands": ["git", "python", "node", "npm", "pip"],
      "deny_flags": ["-c", "--eval"]
    },
    "network": {
      "allow": true,
      "egress_allowlist": ["api.github.com:443", "[INTERNAL_API_FQDN]:443"]
    }
  },
  "high_risk_actions": {
    "require_human_approval": ["shell", "filesystem.write", "network.external"]
  }
}

معظم حوادث OpenClaw ليست "ذكاءً اصطناعياً خرج عن السيطرة". إنها أشبه بـ: العميل كان لديه إذن لفعل الشيء الخطير، وقام موجه (Prompt) أو مهارة بدفعه لذلك. ميزانية الأدوات تجبرك على تحديد الغرض الفعلي للعميل (وما ليس من اختصاصه قطعاً).

قائمة deny_paths تمنع الأخطاء الكارثية الكلاسيكية: قراءة /etc، أو لمس مآخذ المضيف (Host Sockets)، أو التجول في أدلة المستخدمين. قائمة allowed_commands تمنع استخدام "الصدفة (Shell) كباب خلفي شامل"، حيث يصبح أي حقن للموجه تنفيذاً تعسفياً للأوامر. قائمة السماح بالخروج (Egress Allowlist) تحول سرقة البيانات إلى اتصال محظور بدلاً من تحقيق جنائي بعد الكارثة.

بوابة التأكيد ليست مجرد رسالة في واجهة المستخدم. يجب أن تنشئ حدثاً قابلاً للمراجعة يتضمن الإجراء الدقيق، والوسائط (Arguments)، والفرق (Diff) لما سيتغير.

pythonCopy
# نمط بوابة تأكيد بسيط: تجزئة (Hash) حمولة الإجراء المخطط له
import hashlib, json, time

def approval_payload(action: dict) -> dict:
    body = json.dumps(action, sort_keys=True).encode()
    return {
        "action": action,
        "sha256": hashlib.sha256(body).hexdigest(),
        "requested_at": int(time.time())
    }

planned = {
    "tool": "filesystem.write",
    "path": "/workspace/out/report.md",
    "bytes": 4812
}
print(json.dumps(approval_payload(planned), indent=2))

تجزئة الحمولة تمنع تحول "الموافقة على الكتابة" بهدوء إلى "موافقة على الكتابة وتسريب البيانات". يمكن للموافق التحقق من أن التجزئة تطابق ما رآه في واجهة المستخدم أو التذكرة.

للمزيد حول أنماط الثقة الصفرية (Zero Trust) التي تتوافق جيداً مع أدوات العملاء الذكية (الهوية، وضع الجهاز، وبوابات السياسة)، راجع دليلنا الشامل لأمن الثقة الصفرية.

تحصين وقت التشغيل: مستخدم غير جذري، لا امتيازات جديدة، للقراءة فقط، وبلا Docker Socket

yamlCopy
## docker-compose.yml (hardening baseline)
services:
  openclaw:
    image: [IMAGE]:v2026.1.29
    user: "10001:10001"
    read_only: true
    security_opt:
      - no-new-privileges:true
    cap_drop:
      - ALL
    tmpfs:
      - /tmp:rw,noexec,nosuid,size=256m
    ports:
      - "127.0.0.1:[OPENCLAW_PORT]:[OPENCLAW_PORT]"
    volumes:
      - type: bind
        source: ./workspace
        target: /workspace
        read_only: true
      - type: bind
        source: ./out
        target: /workspace/out
        read_only: false
    environment:
      - OPENCLAW_LOG_LEVEL=info

هنا يتم تحجيم الـ "Root". التوجيه user: "10001:10001" يزيل الجذر الافتراضي داخل الحاوية. cap_drop: ALL يقضي على معظم مسارات الامتيازات على مستوى النواة. read_only: true يجعل العديد من سلاسل الاستغلال تفشل لأنها لا تستطيع إسقاط ملفات ثنائية أو تعديل الإعدادات.

تقسيم التخزين (Mounts) مقصود. مساحة /workspace للقراءة فقط تمنع العميل من تعديل الكود الخاص به أو نصوص البناء. ومساحة /workspace/out القابلة للكتابة تمنحه مكاناً آمناً لإنتاج المخرجات. لقد شاهدت فرقاً تقوم بتركيب المستودع بالكامل للقراءة والكتابة ثم يتفاجؤون عندما يتمكن عميل مخترق من زرع باب خلفي في نظام CI.

إذا اقترح شخص ما تركيب /var/run/docker.sock لكي يتمكن العميل من "إدارة الحاويات"، فاعتبر ذلك وصولاً كاملاً على مستوى المضيف. الوصول إلى Docker socket هو فعلياً صلاحية Root على المضيف.

bashCopy
# فحص سريع لأخطر عملية تركيب (Mount) في الأسطول
docker inspect $(docker ps -q) | rg -n "/var/run/docker.sock"

التحكم في الخروج من الشبكة هو الرافعة الأخرى لتحصين وقت التشغيل. إذا كان العميل لا يستطيع الوصول إلا لعدد قليل من النقاط النهائية، يصبح حقن الموجه (Prompt Injection) أقل قيمة بكثير.

bashCopy
## مثال: إنشاء شبكة Docker مخصصة وحظر الخروج إلا للقائمة المسموحة عبر جدار حماية المضيف
docker network create openclaw_net
docker network connect openclaw_net [CONTAINER]

تختلف طريقة الفرض الدقيقة (iptables، مجموعات الأمان السحابية، سياسات شبكة Kubernetes)، لكن الهدف يظل واحداً: يجب ألا يكون لوقت التشغيل وصول افتراضي للإنترنت.

اكتشاف يعمل للعملاء الذكية: سجّل استدعاءات الأدوات، وليس فقط HTTP

jsonCopy
{
  "event": "tool.call",
  "request_id": "[REQ_ID]",
  "actor": "agent",
  "tool": "shell",
  "args": ["git", "remote", "-v"],
  "cwd": "/workspace",
  "egress": null,
  "result": "success",
  "ts": "2026-02-11T12:34:56Z"
}

سجلات التطبيقات التقليدية تخبرك بمن قام بتسجيل الدخول وأي نقطة نهاية طلبها. حوادث العملاء الذكية تحدث غالباً بعد تسجيل الدخول، باستخدام ميزات مشروعة. تسجيل استدعاء الأدوات (Tool-call logging) يمنحك الطبقة المفقودة: ماذا نفذ العميل، ماذا قرأ، وأين حاول الاتصال.

قم بالتنبيه على الأنماط التي نادراً ما تنتمي للتشغيل الطبيعي: ترميز base64، إنشاء الأرشيفات، الوصول لملفات الاعتماد، والنطاقات الخارجية غير المتوقعة. نبه أيضاً على أحداث "رفض الأداة". مما رأيته، الارتفاع المفاجئ في عمليات الرفض يعني غالباً أن محاولات حقن الموجه جارية بالفعل.

bashCopy
## مثال لاستعلامات البحث في سجلات JSON (jq)
jq -c 'select(.event=="tool.call" and .tool=="shell")' /var/log/openclaw/events.jsonl | head

jq -c 'select(.event=="tool.call" and .tool=="filesystem" and (.path|test("id_rsa|\\.aws|\\.ssh|kubeconfig")))' /var/log/openclaw/events.jsonl

اربط هذا بنظام SIEM الخاص بك إذا كان لديك واحد، لكن لا تنتظر عمل الـ SIEM لتبدأ. ملف JSONL محلي مع تدوير (Rotation) يكفي للتحقيق في حادثك الأول (وستحتاج لهذا الأثر الورقي).

أدوات ومنصات تجعل OpenClaw أكثر أماناً (وما تجيده حقاً)

هذه ليست اختيارات عامة "لمكدس أمني". إنها تتوافق بوضوح مع Root (Falco, Gatekeeper)، و Agency (Cilium)، و Keys (Vault)، بالإضافة إلى نظافة التحديثات (Trivy) وثقة الصور (Cosign).

إذا كنت ستضيف شيئاً واحداً فقط، سأضيف التحكم في الخروج (Egress Control)، لأنه يحول العديد من محاولات سرقة البيانات إلى مجرد ضجيج.

إشارات من العالم الحقيقي: ماذا تعني بيانات الصناعة لضوابطك

حققت Spotify انخفاضاً بنسبة 50% في متوسط وقت التعافي (MTTR) من خلال تبني أتمتة الاستجابة للحوادث وكتيبات التشغيل القياسية، كما ورد في محادثات هندسية وملخصات ممارسات SRE. نفس الانضباط ينطبق هنا: وافق مسبقاً على مسارات الأدوات الآمنة، واجعل الإجراءات الحساسة تتطلب سير عمل صريحاً.

تدير Netflix أعباء عمل ضخمة في حاويات مع عزل قوي لوقت التشغيل وممارسات تحديث مستمرة موصوفة في منشوراتهم الأمنية و SRE. الدرس المستفاد لـ OpenClaw بسيط: عامل العميل كعبء عمل غير موثوق، حتى عندما يكون العميل "الخاص بك".

يُستشهد بـ Stripe على نطاق واسع للتحكم الصارم في الوصول وأنماط إدارة الأسرار القوية في البيئات عالية الامتثال. بالنسبة لـ OpenClaw، هذا يعني بيانات اعتماد قصيرة الأجل ونطاقات ضيقة، وليس "مفتاح API واحد ليحكم الجميع".

هذه ليست أمثلة لـ "نسخ أدواتهم". إنها تظهر الاتجاه: الأتمتة زائد حواجز الحماية تتفوق على أمل أن تظل الموجهات (Prompts) نظيفة.

ابدأ من هنا

ابدأ من هنا (خطوتك الأولى)

قم بترقية OpenClaw إلى v2026.1.29 أو أحدث، ثم قم بتدوير جميع رموز البوابة خلال 60 دقيقة.

مكاسب سريعة (تأثير فوري)

• أعد ربط البوابة بـ 127.0.0.1 وضع TLS + مصادقة أمامها خلال يوم واحد.
• عطل أوضاع التصحيح/غير الآمنة واضبط OPENCLAW_LOG_LEVEL=info مع تسجيل استدعاء الأدوات خلال ساعتين.

تعمق أكثر (لمن يريد المزيد)

• نفذ قائمة سماح للمهارات مع إصدارات مثبتة وتحقق من التجزئة، ثم احظر الوصول الخارجي للسجلات العامة خلال أسبوعين.
• طبق تحصين الحاويات: مستخدم غير جذري، cap_drop: ALL، read_only: true، وعدم تركيب Docker socket عبر جميع البيئات خلال أسبوع واحد.

مصادر مفيدة

• ثغرة OpenClaw تتيح تنفيذ التعليمات البرمجية عن بعد بنقرة واحدة - نظرة عامة على إصدار التصحيح وسلسلة الهجوم.
• إشعار ثغرة OpenClaw - الجدول الزمني والإصدارات المتأثرة.
• Clawdbot: كيفية تخفيف الثغرات الأمنية للذكاء الاصطناعي العميل - خطوات التحصين وتفصيل المخاطر.
• استغلال مهارات MoltBot لتوزيع أكثر من 400 حزمة برمجيات خبيثة - تفاصيل مخاطر سلسلة التوريد للمهارات.
• عشرات الآلاف من أنظمة OpenClaw مكشوفة - حجم التعرض وأنماط سوء الإعداد.

الخلاصة

أمن OpenClaw يتلخص في التحكم في Root و Agency و Keys مع طبقات من الاحتكاك: ربط خاص، مصادقة بروكسي صارمة، تحديث سريع مع تدوير الرموز، قوائم سماح للمهارات، أدوات بأقل الامتيازات، وحاويات محصنة مع خروج مقيد.

التهديد ليس افتراضياً. التقارير العامة تربط بين الاستغلال الحقيقي والبوابات المكشوفة، والثغرات عالية الخطورة، والمهارات الخبيثة في النظام البيئي. إذا كان فريقك بحاجة إلى مراجعة هيكلية للتحصين ونشر DevSecOps للأنظمة العميلة (Agentic Systems)، يمكن لـ Joulyan IT Solutions إجراء تقييم أمني يحول هذه الضوابط إلى خط أساس قابل للتكرار عبر البيئات.