هل يعد Ollama آمنًا؟ تقييم أمني عملي

يُعد Ollama آمنًا لما يستخدمه معظم الناس عادةً. فعند تشغيل نموذج محليًّا، يتم تنفيذ الاستنتاج بالكامل على جهازك: فلا تغادر مدخلاتك (تعليماتك) ومخرجات النموذج جهازك أبدًا، ويمكنك التأكد من ذلك بفصل جهازك عن الشبكة — فسيظل كل شيء يعمل بشكل طبيعي. كما أن البرنامج مفتوح المصدر (مرخّص بموجب رخصة MIT) ولديه سجل أمني معقول.

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

ما الذي يرسله Ollama وما الذي يبقى محليًّا

أثناء الاستنتاج باستخدام نموذج مخزن محليًّا، لا يغادر أي شيء جهازك. ولا توجد قناة لجمع البيانات الوصفية (Telemetry) لإرسال مدخلاتك إلى أي مكان. وبما أن Ollama برنامج مفتوح المصدر، فمن الممكن التحقق من ذلك — ويمكنك التأكد منه شخصيًّا باستخدام جدار حماية أو أداة لمراقبة حركة المرور الخارجة مثل Little Snitch على نظام ماك أو إس.

ويقوم Ollama بالاتصال بالشبكة في حالات محددة وقابلة للتنبؤ بها فقط:

تستحق خاصية النموذج السحابي توضيحًا: ففي الإصدارات الأحدث من Ollama، يمكن تشغيل النماذج الكبيرة على البنية التحتية الخاصة بـ Ollama. وهذه الخاصية اختيارية صراحةً — فهي تتطلب تسجيل الدخول، وتكون النماذج السحابية موسومة على هذا النحو — ولكن إن كنت قد اخترت Ollama تحديدًا للحفاظ على بياناتك داخل بيئتك المحلية (on-premises)، فيجب أن تدرك وجود هذه الميزة وأن تمتنع عن استخدامها. وكل ما تقوم بتشغيله دون تسجيل الدخول يبقى محليًّا.

الخطر الحقيقي: واجهة برمجة التطبيقات (API) المكشوفة وغير الموثوقة

يقدِّم Ollama واجهة برمجة تطبيقات HTTP (API) على المنفذ 11434. وبشكل افتراضي، يرتبط بعنوان 127.0.0.1, أي أن العمليات الجارية على جهازك فقط هي التي يمكنها الوصول إليه. وهذا الإعداد الافتراضي آمن.

تبدأ المشكلة عندما يضبط الأشخاص قيمة OLLAMA_HOST=0.0.0.0 — عادةً للسماح لواجهة ويب أو جهاز آخر على الشبكة بالاتصال. أما واجهة برمجة تطبيقات Ollama فهي لا توجد مصادقة مضمنة. فلا توجد مفاتيح واجهة برمجة تطبيقات (API keys)، ولا كلمات مرور، ولا شيء على الإطلاق. وأي شخص يستطيع الوصول إلى هذا المنفذ يمكنه أن:

• يعرض قائمة النماذج المثبتة لديك (/api/tags) وينفِّذ عمليات توليد غير محدودة على وحدة معالجة الرسومات (GPU) الخاصة بك وعلى نفقتك
• يحمِّل نماذج جديدة لملء مساحة قرصك الصلب، أو يحذف النماذج الموجودة لديك
• وفي الإصدارات القديمة، قد تكون العواقب أسوأ: فقد كان هناك ثغرة أمنية تتعلق باجتياز مسار الملفات (path-traversal) في عملية تنزيل النماذج، تعرف باسم CVE-2024-37032 («Probllama»)، والتي كانت قد تؤدي إلى تنفيذ تعليمات برمجية عن بُعد على الخوادم المعرَّضة. وقد تم إصلاح هذه الثغرة في الإصدار 0.1.34 عام 2024، لكنها توضح إلى أي مدى قد تتفاقم مخاطر «التعرُّض دون مصادقة»

وهذا ليس سيناريو افتراضيًّا. فعمليات المسح الشاملة على الإنترنت كشفت مرارًا وتكرارًا عن آلاف حالات تشغيل Ollama التي تستجيب عبر المنفذ 11434 على الإنترنت المفتوح — ومعظمها على الأرجح غير مقصود. وإن كنت ستستفيد من هذه المقالة في أمرٍ واحد فقط، فهو: عدم إعادة توجيه المنفذ 11434 إلى الإنترنت أبدًا، والارتباط فقط بعنوان 0.0.0.0 إذا وُجد جدار حماية أو وكيل (proxy) أمامه.

ومن الإعدادات الأدق دقةً ما يلي: OLLAMA_ORIGINS يتحكم في أصول المتصفحات التي يُسمح لها باستدعاء واجهة برمجة التطبيقات (API). والإعداد الافتراضي مقيد جدًّا، مما يقلل من احتمال تفاعل مواقع الويب الضارة مع مثيلك المحلي من خلال متصفحك. ولا تضبطه على قيمة * إلا إذا كنت تدرك تمامًا التنازلات الأمنية المرتبطة بذلك.

أصل النموذج: مصدر أوزانه

أما الخطر الحقيقي الثاني فهو ما تقوم بتنزيله، وليس الأداة التي تقوم بالتنزيل. وبعض الحقائق تساعد في تقدير مستوى هذا الخطر بدقة أكبر:

• تستخدم نماذج Ollama تنسيق GGUF، الذي يخزن الأوزان على هيئة بيانات، وليس كتعليمات برمجية قابلة للتنفيذ. وهذا يجعلها أكثر أمانًا بشكل جذري مقارنةً بملفات الاختبارات القديمة المستندة إلى pickle في إطار PyTorch، والتي كان يمكنها تنفيذ تعليمات برمجية عشوائية عند التحميل.
• إن كون البيانات «غير قابلة للتنفيذ» لا يمثل ضمانة لأمان مطلق — فقد تم اكتشاف ثغرات سابقة في برامج تحليل ملفات GGUF، وبالتالي فإن ملفًا تم إنشاؤه بقصد خبيث لا يخلو تمامًا من المخاطر. وتحديث Ollama باستمرار يغطي هذه الثغرات.
• يتم التحقق من النماذج التي يتم سحبها من المكتبة الرسمية باستخدام ملخَّصات SHA-256 المدرجة في بياناتها التعريفية (manifests)، لذا فإن ما تتلقاه يطابق بالضبط ما تقدمه السجلات.
• كما قد يتصرف النموذج سلوكًا خاطئًا على مستوى المحتوى: فقد يوجِّه مؤشر النظام المدمج في نموذج تم رفعه من قِبل المجتمع أو قالب الدردشة الخاص به المخرجات بطريقة لم تكن ضمن اختيارك. ورغم أن درجة خطورة ذلك منخفضة، فإنه يستحق المعرفة خاصةً إذا كنت تبني تطبيقاتك على نماذج غير مألوفة.

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

تقوية الأمان حسب نظام التشغيل

ماك أو إس

كلاهما يركِّزان على النماذج الرئيسية والشائعة الاستخدام. يُحدِّث تطبيق سطح المكتب نفسه تلقائيًّا، ما يغطي جانب التصحيحات الأمنية. ويرتبط Ollama افتراضيًّا بعنوان localhost ما لم تقم بتغيير ذلك — والطريقة الموثَّقة لتغيير هذا الارتباط هي launchctl setenv OLLAMA_HOST "0.0.0.0" ~/.ollama/modelsثم إعادة تشغيل التطبيق، لذا إن لم تكن قد نفذت هذه الأوامر من قبل، فأنت تستخدم الإعداد الافتراضي الآمن. أما النماذج فتُخزَّن في

ويندوز

يُدار Ollama من شريط المهام (system tray) ويُحدَّث تلقائيًّا. وتُعيَّن متغيرات البيئة مثل OLLAMA_HOST من خلال الإعدادات → النظام → حول → إعدادات النظام المتقدمة → متغيرات البيئة، ثم إعادة تشغيل Ollama من شريط المهام. أما النماذج فتُخزَّن تحت %USERPROFILE%.ollamamodels. وإن كنت قد عرَّضت المنفذ للاستخدام عبر شبكة المنطقة المحلية (LAN)، فتحقَّق من جدار الحماية في Windows Defender وتأكد من أن قاعدة الإدخال (inbound rule) الخاصة بـ Ollama تطبَّق فقط على الشبكات الخاصة (Private networks)، وليس على الشبكات العامة (Public).

لينكس

يُثبِّت البرنامج النصي للتثبيت Ollama كخدمة systemd. أما التهيئة فتتم عبر systemctl edit ollama.service, بإضافة أسطر مثل Environment="OLLAMA_HOST=0.0.0.0" تحت القسم [Service] — مرة أخرى، لا تفعل ذلك إلا عمداً. وإن كنت مضطرًّا للاستماع إلى جميع الواجهات، فقيِّد نطاق المنفذ باستخدام جدار الحماية الخاص بك، مثلاً: ufw allow from 192.168.1.0/24 to any port 11434. ولاحظ أن تثبيتات Linux لا تتم فيها ليس التحديث التلقائي؛ بل تقوم بالتحديث بإعادة تشغيل البرنامج النصي الرسمي للتثبيت. راجع دليلنا دليل تثبيت Ollama للحصول على الأوامر الدقيقة حسب توزيعة Linux.

Docker والوكالات العكسية (Reverse Proxies)

يعمل Ollama داخل حاوية Docker مع عزل نظام الملفات، ويصبح التعرُّض الشبكي واضحًا تمامًا. والتفاصيل الحرجة هنا تتعلَّق بكيفية نشر المنفذ. فالتكوين التالي آمن — حيث تكون واجهة برمجة التطبيقات (API) قابلة للوصول من الجهاز المضيف فقط:

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

أما التكوين التالي -p 11434:11434 فيقوم بنشر المنفذ على الكل واجهات الاستضافة — وتتلاعب Docker مباشرةً بجدول iptables، لذا فإن هذا الأمر في العديد من التهيئة يتجاوز قواعد ufw بالكامل . وهذه المجموعة (Docker + جدار حماية مفترض لكنه غير نشط) هي السبب وراء تعرض العديد من حالات Ollama للإنترنت عن طريق الخطأ. أضفلتمكين الوصول إلى وحدات معالجة الرسومات من شركة NVIDIA؛ ولا يؤثر هذا على الصورة الأمنية بأي شكل. --gpus=all إذا كنت فعلاً بحاجةٍ إلى الوصول عن بُعد، فضع وكيل عكسية (reverse proxy) مُصادَقًا عليه أمام خدمة Ollama واحتفظ بـ Ollama نفسها مرتبطةً بعنوان localhost. وإليك مثالاً بسيطاً باستخدام nginx مع مصادقة أساسية عبر HTTP:

server { listen 443 ssl; server_name ollama.example.com; # سطور شهادة SSL هناlocation / { auth_basic "Ollama"; auth_basic_user_file /etc/nginx/.htpasswd; proxy_pass http://127.0.0.1:11434; } }

وبديلٌ أبسط بكثيرٍ للاستخدام الشخصي هو استخدام شبكة افتراضية خاصة (mesh VPN) مثل Tailscale أو WireGuard، بحيث لا يكون المنفذ قابلاً للوصول إلا داخل شبكتك الخاصة، ولا يتصل إطلاقاً بالإنترنت العام.

احرص على تحديث Ollama باستمرار — فالتطبيقات المكتبية تقوم بذلك تلقائيًا؛ أما على أنظمة Linux، فقم بإعادة تشغيل نص التثبيت بشكل دوري.

قائمة التحقق من تقوية الأمان

• اترك
• عند القيمة الافتراضية ( OLLAMA_HOST ) ما لم تكن هناك حاجة فعلية لجهاز آخر للوصول إليها.127.0.0.1إذا قمت بربط الخدمة بعنوان
• , فقيّد منفذ 11434 في جدار الحماية ليسمح فقط بعناوين IP أو نطاقات IP الموثوقة. 0.0.0.0لا تُوجِّه منفذ 11434 أبداً نحو الإنترنت. استخدم وكيل عكسية (reverse proxy) مزوّداً بمصادقة، أو شبكة افتراضية خاصة (VPN).
• في بيئة Docker، استخدم الخيار
• -p 127.0.0.1:11434:11434 ، وذكّر نفسك بأن Docker قد يتجاوز ufw.حمّل النماذج (models) من المكتبة الرسمية فقط؛ وافحص ملفات GGUF التي ينشرها المجتمع أو الأطراف الثالثة بدقة قبل استيرادها.
• لا توسع صلاحية
• أكثر مما تحتاجه فعلاً. OLLAMA_ORIGINS لا تسجّل الدخول أو تستخدم النماذج السحابية إذا كان هدفك الوحيد هو معالجة البيانات محلياً (on-premises) دون أي اتصال خارجي.
• هل يرسل Ollama مدخلاتك أو محادثاتك إلى السحابة؟

الأسئلة الشائعة

لا، ليس أثناء الاستنتاج المحلي — إذ تبقى المدخلات والمخرجات والمستندات التي تُغذّي بها النموذج على جهازك فقط. والاستثناءات الوحيدة هي عمليات صريحة: عند تنزيل نموذج ما، يتم تحميل أوزانه من سجل Ollama، أما النماذج السحابية الاختيارية (التي تتطلب تسجيل الدخول) فهي التي تعالج المدخلات على خوادم Ollama. فإذا لم تُسجّل الدخول أبداً، فستعمل كل العمليات محلياً بالكامل.

هل يمكن تشغيل Ollama بالكامل دون اتصال بالإنترنت؟

نعم. وبمجرد تنزيل النموذج، يمكنك قطع الاتصال بالإنترنت تماماً، وسيظل الاستنتاج يعمل بشكل طبيعي. وهذه أقوى ضمانة ممكنة للخصوصية — فلا يمكن لأي إعداد أن يُسرب بيانات عبر اتصال غير موجود أصلاً. بل إن التشغيل في بيئات معزولة تامّاً (air-gapped) هو حالة استخدام مشروعة تماماً لـ Ollama.

هل وُجدت ثغرات أمنية خطيرة في Ollama؟

أشهرها كانت CVE-2024-37032 (المعروفة باسم «Probllama»)، وهي ثغرة تسمح بالتنقل بين المسارات (path-traversal) وقد تُمكّن المهاجمين البعيدين من تنفيذ تعليمات برمجية عن بُعد على الخوادم المعرّضة لهم؛ وقد تم إصلاحها في الإصدار 0.1.34 عام 2024. وكأي مشروع نشيط التطوير، تظهر المشكلات ويتم إصلاحها — وكل الثغرات المكتشفة حتى الآن تتطلب وصولاً شبكياً إلى واجهة برمجة التطبيقات (API)، وهو ما يعزز الحاجة إلى ربطها بعنوان localhost والبقاء على أحدث إصدار.

هل من الآمن عرض Ollama مباشرةً على الإنترنت؟

لا، ليس مباشرةً — فواجهة برمجة التطبيقات (API) لا تحتوي على أي آلية للمصادقة، وبالتالي فإن عرض الخدمة مباشرةً على الإنترنت يسمح لأي شخص باستخدام وحدة معالجة الرسومات الخاصة بك، وإدارة نماذجك، واستكشاف الثغرات غير المُعالَجة. وإذا كنت بحاجةٍ إلى الوصول عن بُعد، فضعها خلف وكيل عكسية مزوّد بالمصادقة وبروتوكول TLS، أو وصِل إليها عبر شبكة افتراضية خاصة مثل Tailscale. أما إعادة توجيه المنفذ 11434 مباشرةً فهو أسوأ إجراءٍ يمكنك اتخاذه مع Ollama.

هل النماذج المتاحة على موقع ollama.com آمنة للتنزيل؟

النماذج الرئيسية في المكتبة الرسمية (مثل Llama وQwen وMistral وGemma وما شابهها) هي ذات الأوزان المُدقَّقة على نطاق واسع والتي يستخدمها الجميع، ومقدمة مع التحقق من بصمة الملف (digest verification). أما تنسيق GGUF فهو تنسيق بيانات وليس كوداً قابلاً للتنفيذ، ما يزيل أكبر خطر تاريخي مرتبط بتنزيل النماذج. أما النماذج المنشورة من قِبل المجتمع فهي تتطلب فحصاً أكثر دقة — لأن أي شخص يمكنه النشر ضمن مساحة اسم مستخدم — لذا يُفضَّل استخدام النماذج المعروفة جيداً لأي استخدام جاد.

هل تشغيل Ollama محلياً أكثر أماناً من استخدام واجهة برمجة تطبيقات سحابية؟

بالنسبة لخصوصية البيانات، نعم: ف ничто يفوق عدم مغادرة المدخلات أبداً لجهازك، وهذا أمرٌ بالغ الأهمية عند التعامل مع بيانات خاضعة للتنظيم أو أكواد سرية. أما واجهات البرمجة السحابية فتنقل عبء الأمان وسياسات الاحتفاظ بالبيانات إلى موفّر الخدمة، مقابل التخلّي عن صيانة النظام وتجنب مخاطر التعرض الناتجة عن سوء التهيئة من جانبك. وإذا كان العامل الحاسم لديك هو التكلفة لا الخصوصية، فإن

توضح لك أين يُحقّق الأجهزة المحلية عائد استثمار أفضل. وإذا كنت تقارن بين برامج التشغيل المحلية، فإن آلة حاسبة لتحديد نقطة التعادل بين الاستضافة المحلية وواجهات برمجة التطبيقات (API) تتمتع بوضع أمني مشابهٍ إلى حدٍ كبير: فهي محلية افتراضياً، بينما يبقى التعرّض للشبكة أمراً اختيارياً. LM Studio يتمتع بموقف أمني مشابهٍ بشكل عام: محلي افتراضيًّا، مع إمكانية التعرُّض للخارج كخيارٍ اختياري.