هل خادم الذكاء الاصطناعي لديك مكشوف؟ كيف تؤمّن Ollama (المنفذ 11434)

شاهد الفيديو (دقيقتان):

تشغيل نماذج الذكاء الاصطناعي الخاصة بك باستخدام Ollama أمر رائع، إلى أن يصبح الإنترنت كله قادرًا على استخدامها. فواجهة برمجة التطبيقات (API) في Ollama لا تحميها كلمة مرور. إذا كان المنفذ (Port) 11434 متاحًا من الخارج، فيمكن لأي شخص أن يعرض قائمة نماذجك، ويشغّل الأوامر على معالج الرسوميات (GPU) لديك، ويسحب النماذج أو يرفعها، ويستغل أي ثغرة في إصدارك.

والمهاجمون يفعلون ذلك فعلًا وعلى نطاق واسع:

• شبكة البوتات PoeLLM (أكتوبر 2026). اكتشف مختبر Black Lotus Labs التابع لشركة Lumen حملةً أصابت أكثر من 3,400 خادم منذ أبريل 2026. معظم الضحايا يشغّلون أدوات ذكاء اصطناعي مفتوحة المصدر مثل LiteLLM وOllama. تشغّل الخوادم المصابة برامج تعدين العملات الرقمية XMRig، وتفتح صدفة أوامر عن بُعد (Remote Shell)، وتبحث عن ضحايا جدد. بل إن شبكة البوتات تخفي عنوان خادم التحكم الخاص بها داخل قصيدة مستضافة على GitHub.
• ثغرة Bleeding Llama، المعرّفة CVE-2026-7482 (درجة CVSS 9.1). وجدت شركة Cyera أن ملف نموذج مُعدًّا بطريقة خاصة يجعل إصدارات Ollama القديمة تسرّب محتوى ذاكرة الكومة (Heap Memory)، بما فيها الأوامر النصية والمحادثات ومتغيرات البيئة (Environment Variables)، دون الحاجة إلى تسجيل دخول. وقد أحصت الشركة نحو 300,000 نسخة من Ollama مكشوفة على الإنترنت.

إليك كيف تفحص خادمك وتصلحه. جميع الأوامر أدناه مخصصة لنظامَي Ubuntu/Debian مع systemd. القائمة الكاملة موجودة في الملف ollama-lockdown-commands.txt.

الخطوة 0: تحقّق من العنوان الذي يستمع عليه Ollama

على الخادم نفّذ:

ss -tlnp | grep 11434

ما تراه	معناه
127.0.0.1:11434	هذا الجهاز وحده يستطيع الوصول إلى Ollama. الوضع آمن.
0.0.0.0:11434 أو *:11434 أو [::]:11434	جميع بطاقات الشبكة تستمع. إذا كان للخادم عنوان IP عام، فالإنترنت يستطيع الوصول إليه.

ثم تحقّق من جهاز آخر (حاسوبك المحمول، أو هاتفك عبر بيانات الجوال):

curl http://YOUR-SERVER-IP:11434/api/tags

إذا حصلت على قائمة بنماذجك بصيغة JSON، فالمهاجم يستطيع الحصول عليها أيضًا.

الإصلاح 1: اربط Ollama بـ localhost

يستمع Ollama افتراضيًا على 127.0.0.1:11434. وغالبًا ما تنكشف الخوادم لأن أحدهم ضبط OLLAMA_HOST=0.0.0.0 ليستخدمه من حاسوب آخر. أعِده إلى وضعه الأصلي:

sudo systemctl edit ollama.service

أضف هذين السطرين، ثم احفظ واخرج:

[Service]
Environment="OLLAMA_HOST=127.0.0.1:11434"

sudo systemctl daemon-reload
sudo systemctl restart ollama
ss -tlnp | grep 11434    # now 127.0.0.1:11434

على Windows، غيّر متغير البيئة الخاص بالمستخدم OLLAMA_HOST ثم أعد تشغيل Ollama. وعلى macOS، استخدم launchctl setenv OLLAMA_HOST "127.0.0.1:11434" ثم أعد تشغيل التطبيق.

الجزء الخادع: Docker

هذه هي الحالة التي يقع فيها حتى مديرو الأنظمة ذوو الخبرة.

1. الصورة ollama/ollama تستمع على جميع الواجهات داخل الحاوية (Container)، وهذا متوقع، لأن Docker يحتاج إلى توجيه حركة المرور إليها.
2. الخيار -p 11434:11434 ينشر ذلك المنفذ على جميع واجهات الجهاز المضيف (Host).
3. يكتب Docker قواعد iptables الخاصة به، لذلك فإن المنافذ المنشورة تتجاوز UFW. فتوثيق Docker نفسه يقول إن حركة المرور "تُحوَّل قبل أن تمرّ عبر إعدادات جدار الحماية ufw". أي أن قاعدة ufw deny لديك لا تفعل شيئًا هنا.

الحل هو نشر المنفذ على localhost فقط:

docker run -d --name ollama -v ollama:/root/.ollama \
  -p 127.0.0.1:11434:11434 ollama/ollama

ومع Docker Compose:

services:
  ollama:
    image: ollama/ollama
    ports:
      - "127.0.0.1:11434:11434"

إذا كان Open WebUI يعمل في ملف Compose نفسه، فإنه يستطيع الوصول إلى Ollama عبر الشبكة الداخلية (http://ollama:11434)، لذلك قد لا تحتاج إلى نشر المنفذ أصلًا.

الإصلاح 2: احظر المنفذ على أي حال

هذا مبدأ الدفاع المتعدد الطبقات (Defense in Depth): إذا غيّر أحدهم OLLAMA_HOST لاحقًا، يظل جدار الحماية يحظر المنفذ (في التثبيتات المباشرة على النظام؛ راجع ملاحظة Docker أعلاه).

sudo ufw deny 11434/tcp
sudo ufw status numbered

إذا كنت تستخدم آلة افتراضية سحابية (Cloud VM)، فتأكد أيضًا من أن المنفذ 11434 غير مفتوح في مجموعة الأمان (Security Group) لدى مزوّد الخدمة.

الإصلاح 3: تحتاج إلى وصول عن بُعد؟ استخدم Nginx مع كلمة مرور وHTTPS

لا تفتح المنفذ 11434 نفسه أبدًا. ضع Nginx في الواجهة، واشترط تسجيل الدخول، ودَع Nginx يتواصل مع Ollama عبر localhost:

sudo apt install nginx apache2-utils
sudo htpasswd -c /etc/nginx/.ollama-users mouhimen

الملف /etc/nginx/sites-available/ollama:

server {
    listen 443 ssl;
    server_name ai.mouhimen.dev;
    ssl_certificate     /etc/letsencrypt/live/ai.mouhimen.dev/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/ai.mouhimen.dev/privkey.pem;

    location / {
        auth_basic           "Ollama";
        auth_basic_user_file /etc/nginx/.ollama-users;
        proxy_pass           http://127.0.0.1:11434;
        proxy_set_header     Host localhost:11434;
        proxy_read_timeout   300s;
        proxy_buffering      off;
    }
}

sudo ln -s /etc/nginx/sites-available/ollama /etc/nginx/sites-enabled/
sudo nginx -t && sudo systemctl reload nginx
sudo ufw allow 443/tcp
curl -u mouhimen https://ai.mouhimen.dev/api/tags

لماذا Host localhost:11434؟ لأن صفحة الأسئلة الشائعة في Ollama تستخدمه في مثال Nginx الخاص بها، وهو يجعل فحص المضيف في Ollama يقبل الطلبات. أما proxy_buffering off فيسمح بتدفق الرموز (Tokens) تباعًا بدلًا من وصولها دفعة واحدة. ولإعداد HTTPS وترويسات الأمان (Security Headers)، شاهد الفيديو الخاص بي Secure Nginx in 5 settings. وتُعدّ الشبكة الافتراضية الخاصة (VPN) مثل WireGuard أو Tailscale خيارًا أكثر أمانًا إذا كانت أجهزتك وحدها تحتاج إلى الوصول.

الإصلاح 4: حدّث Ollama (وLiteLLM)

ollama -v
curl -fsSL https://ollama.com/install.sh | sh    # re-running the installer updates Ollama on Linux
docker pull ollama/ollama                        # Docker: pull, then recreate the container

• الإصدار 0.17.1 من Ollama أو أحدث يصلح ثغرة Bleeding Llama (CVE-2026-7482). صدر الإصلاح في فبراير 2026، لكن ملاحظات الإصدار لم تذكر أنه إصلاح أمني، لذلك لم تُحدَّث خوادم كثيرة قط.
• الإصدار 1.83.7 من LiteLLM أو أحدث يصلح الثغرة CVE-2026-42271، وهي ثغرة حقن أوامر (Command Injection) تصنّفها وكالة CISA على أنها مُستغلّة فعليًا، وتستهدفها شبكة البوتات PoeLLM. بعد التحديث، غيّر المفتاح الرئيسي (Master Key) لـ LiteLLM وجميع مفاتيح API المرتبطة به.

هل كان خادمك مكشوفًا من قبل؟

إذا كان الوصول إلى الخادم ممكنًا قبل أن تصلحه، فتعامل معه على أنه ربما يكون مُخترقًا:

• ابحث عن برامج التعدين: استخدم top أو htop لرصد الاستهلاك المرتفع للمعالج، وps aux | grep -i -E "xmrig|kryptex|iron"، وnvidia-smi لرصد عمليات مجهولة على معالج الرسوميات.
• تحقّق من وجود مهام cron أو خدمات systemd أو مفاتيح SSH جديدة: crontab -l وls /etc/systemd/system وcat ~/.ssh/authorized_keys.
• شغّل ollama list واحذف النماذج التي لم تسحبها بنفسك.
• غيّر أي أسرار (Secrets) موجودة في متغيرات البيئة على الخادم، لأن ثغرة Bleeding Llama قد تسرّبها.

قائمة التحقق

• الأمر ss -tlnp | grep 11434 يُظهر 127.0.0.1:11434
• Docker ينشر 127.0.0.1:11434:11434 (أو لا ينشر أي منفذ)
• القاعدة ufw deny 11434/tcp مُفعّلة، ومجموعة الأمان السحابية مغلقة
• الوصول عن بُعد يتم فقط عبر Nginx مع كلمة مرور وHTTPS، أو عبر VPN
• إصدار Ollama هو 0.17.1 أو أحدث، وإصدار LiteLLM هو 1.83.7 أو أحدث مع مفاتيح مُغيَّرة
• الأمر curl http://YOUR-SERVER-IP:11434/api/tags من جهاز آخر يُرفض

شاهد الفيديو:

المصادر

• Help Net Security، برمجية PoeLLM الخبيثة تخفي خادم التحكم (C2) في قصيدة على GitHub (مختبر Lumen Black Lotus Labs)، 8 أكتوبر 2026: https://www.helpnetsecurity.com/2026/10/08/poellm-malware-github-poem-ai-servers/
• Cyera Research، ثغرة Bleeding Llama، تسريب ذاكرة حرج في Ollama (CVE-2026-7482): https://www.cyera.com/blog/bleeding-llama-a-critical-memory-leak-in-the-worlds-most-popular-local-ai-platform
• Indusface، الجدول الزمني للثغرة CVE-2026-7482 والإصدار الذي أصلحها (0.17.1): https://www.indusface.com/blog/cve-2026-7482-bleeding-llama-vulnerability/
• Help Net Security، ثغرة LiteLLM CVE-2026-42271 تتعرض لهجمات فعلية، وCISA تحذّر: https://helpnetsecurity.com/2026/06/09/litellm-vulnerability-under-active-attack-cisa-warns-cve-2026-42271
• الأسئلة الشائعة في Ollama (OLLAMA_HOST، ووكيل Nginx): https://docs.ollama.com/faq
• توثيق Docker، تصفية الحزم وجدران الحماية (Docker وufw): https://docs.docker.com/engine/network/packet-filtering-firewalls/

عبد المهيمن شموط · mouhimen.dev · Take away support: حلول تقنية المعلومات، في أقل من دقيقتين.

---

هذا المقال ترجمة عربية للمقال الأصلي باللغة الإنجليزية للكاتب عبد المهيمن شموط على mouhimen.dev.