{"schema_version":"1.0","service":"Publicasta","type":"article","id":745,"slug":"carbonato_exposed_docker_daemons_response","title":"تكشف CARBONATO لماذا يعني كشف واجهة Docker API اختراق المضيف، لا مجرد مشكلة في الحاوية","excerpt":"تستهدف حملة CARBONATO واجهات Docker غير الموثقة المكشوفة على الإنترنت. تبدأ الاستجابة الصحيحة بإزالة التعرض، وفحص المضيف، وتدوير الأسرار، ومراجعة كل بيئة Docker يمكن الوصول إليها.","language":"ar","default_language":"en","canonical_url":"https://publicasta.com/cybersecurity/carbonato_exposed_docker_daemons_response?lang=ar","image":{"url":"https://publicasta.com/storage/projects/9/pages/745/2026/10/e0e84b0a-a1d3-4792-aed0-fb9fd83a79da.webp","alt":"رسم توضيحي تحريري لمضيف Docker مكشوف يوضح مسار وصول من الإنترنت إلى الخادم وطبقة التحكم بالحاويات."},"publisher":{"id":9,"slug":"cybersecurity","name":"Cybersecurity Without Panic","url":"https://publicasta.com/cybersecurity"},"author":{"name":"Anton R"},"published_at":"2026-10-01T13:58:51+00:00","updated_at":"2026-10-01T13:58:51+00:00","content_markdown":"المضيف الذي يتيح واجهة برمجة تطبيقات Docker غير موثقة على الإنترنت لا يقدم مجرد ميزة مريحة للإدارة عن بُعد؛ بل يفتح طريقاً عن بُعد إلى الجهاز الذي يشغّل الحاويات. والحملة التي أُبلغ عنها باسم CARBONATO في 30 سبتمبر تجعل هذا الفرق صعب التجاهل: إذ يستخدم المهاجمون واجهات Docker Remote API المكشوفة لإنشاء حاويات ذات صلاحيات مرتفعة، وترسيخ الاستمرارية، وسرقة بيانات الاعتماد، والبحث عن مضيفي Docker آخرين.\n\n ![رسم توضيحي تحريري لمضيف Docker مكشوف يوضح مسار وصول من الإنترنت إلى الخادم وطبقة التحكم بالحاويات.](https://publicasta.com/storage/projects/9/pages/745/2026/10/e0e84b0a-a1d3-4792-aed0-fb9fd83a79da.webp)\n\n تستحق الحادثة الانتباه لأنها ليست، في جوهرها، قصة عن ثغرة جديدة في Docker. إنها قصة عن وضع واجهة إدارية على شبكة غير موثوقة من دون حدّ للمصادقة. صحيح أن البرمجية الخبيثة تضيف حمولة حديثة، من بينها إطار عمل مفتوح المصدر لوكلاء الذكاء الاصطناعي أُعيد توظيفه، لكن شرط التمكين أقدم وأبسط: كل من يستطيع الوصول إلى البرنامج الخفي يمكنه أن يطلب منه تنفيذ عمليات تتمتع بسلطة المضيف.\n\n بالنسبة إلى الفرق التي تشغّل Docker على خوادم سحابية، أو أجهزة بناء، أو مضيفي تطوير، أو خدمات مستضافة ذاتياً، أو أنظمة طرفية، فإن الاستجابة الصحيحة هي تقييم التعرض والاختراق. أغلق المسار غير الموثق، وحدد ما إذا كان المضيف قد استُخدم، وأدر كل ما كان قادراً على قراءته، ثم راجع الأنظمة المجاورة. إعادة تثبيت حاوية أو تغيير وسم صورة لا يكفي إذا كان المضيف الأساسي أو بيانات اعتماده قد أصبحا بالفعل تحت سيطرة طرف آخر.\n\n ## ماذا يقول تقرير CARBONATO فعلياً\n\n تقول [النشرة الاستشارية لوكالة الأمن السيبراني في سنغافورة](https://www.csa.gov.sg/alerts-and-advisories/advisories/ad-2026-012/) المنشورة في 30 سبتمبر إن الباحثين حددوا حملة شبكة روبوتية تستهدف مضيفي Docker الذين كانت واجهاتهم البعيدة غير الموثقة مكشوفة على الإنترنت، وعادةً عبر المنفذ TCP 2375. وتصف النشرة حملة تستخدم وظائف Docker المشروعة لإنشاء حاوية ذات صلاحيات مرتفعة تتيح الوصول إلى نظام ملفات المضيف وعملياته وشبكته.\n\n هذا التسلسل مهم. فالمهاجم لا يحتاج إلى استغلال خطأ في سلامة الذاكرة داخل Docker Engine إذا كان البرنامج الخفي يقبل طلبات إدارية من طرف غير موثوق. فالطلب الطبيعي بالنسبة إلى مسؤول، مثل إنشاء حاوية أو تركيب مسار أو تشغيل عملية أو ربط شبكة، يمكن أن يتحول إلى تحكم على مستوى المضيف عندما يكون صاحب الطلب غير موثق ويعمل البرنامج الخفي بامتيازات عالية.\n\n وتقول النشرة السنغافورية إن الحملة تستطيع إنشاء وصول بعيد مستمر، وسرقة بيانات الاعتماد وغيرها من المعلومات الحساسة، وفحص الشبكات المتصلة بحثاً عن مضيفي Docker مكشوفين إضافيين. لكنها لا تدعي أن كل مضيف مكشوف قد اختُرق، ولا تقدم مؤشراً شاملاً يمكنه وحده إثبات وقوع حادث أو نفيه. وهذه الحدود مهمة. فالنشرة سبب لفحص التعرض والسجلات، وليست إذناً بوصف كل عملية تثبيت لـ Docker بأنها مصابة.\n\n وتضيف [مذكرة بحثية من تحالف أمن السحابة](https://labs.cloudsecurityalliance.org/research/csa-research-note-carbonato-botnet-docker-ai-agent-20260928/) سياقاً حول الحمولة. فهي تصف CARBONATO بأنها شبكة روبوتية ذاتية الانتشار تثبّت إطار عمل مفتوح المصدر غير معدل لوكلاء الذكاء الاصطناعي، هو Hermes Agent، ثم تغيّر إعدادات شخصيته بحيث يخدم الإطار أهداف المشغلين. وتقول المذكرة إن المضيفين المصابين يفحصون نطاقات الشبكات المجاورة بحثاً عن برامج Docker خفية إضافية.\n\n الجزء غير المعتاد هو اختيار الحمولة. أما الجزء الأهم للمدافعين فما زال مسار الوصول. قد يجذب وجود إطار للذكاء الاصطناعي الانتباه، لكن المهاجم لا يحتاج إلى وكيل ذكاء اصطناعي لتحويل برنامج Docker الخفي المكشوف إلى حادث خطير. فالتعرض الإداري نفسه قد يتيح سرقة بيانات الاعتماد، أو تعدين العملات المشفرة، أو تنفيذ أفعال مدمرة، أو تمرير الاتصالات، أو التحرك الجانبي، أو نشر باب خلفي تقليدي.\n\n ## لماذا يحتاج المنفذ 2375 إلى استجابة دقيقة\n\n تميّز وثائق Docker بين المقبس المحلي المعتاد والاتصالات الشبكية البعيدة. افتراضياً، يستخدم Docker مقبس Unix غير شبكي على Linux وmacOS. ويمكن بدلاً من ذلك تنفيذ الإدارة عن بُعد عبر SSH أو عبر مقبس TCP محمي بـ TLS ومصادقة العميل.\n\n وتحدد وثائق Docker أيضاً التقسيم التقليدي للمنافذ: يُستخدم TCP 2375 عادةً لاتصال غير آمن وغير مشفر بـ TLS، بينما يرتبط TCP 2376 تقليدياً بـ TLS. لكن رقم المنفذ وحده لا يثبت وقوع اختراق، كما أن استخدام منفذ مختلف لا يجعل واجهة غير موثقة آمنة. إن المنفذ 2375 مجرد إشارة مفيدة للاكتشاف، لأنه يدل غالباً على إعداد برنامج Docker الخفي للوصول البعيد العادي.\n\n السؤال الحاسم ليس: «هل المنفذ 2375 مفتوح؟» بمعزل عن السياق، بل هو:\n\n - ما العملية التي تستمع على المنفذ؟\n- هل يمكن الوصول إلى المستمع من الإنترنت العام، أو من شبكة مؤسسية واسعة، أو من قطاع إدارة مقيد فقط؟\n- هل يطلب مصادقة ويخوّل العميل على نحو مناسب؟\n- أي برنامج Docker خفي، وحساب، ومضيف، وحمولة تقف وراءه؟\n- هل توجد سجلات تظهر طلبات لم ينفذها مالك النظام؟\n\n قد تكون الخدمة المواجهة للإنترنت خطرة حتى عندما لا تكون متاحة عالمياً. فالبرنامج الخفي المكشوف على شبكة داخلية مسطحة قد يكون متاحاً لمحطة عمل مخترقة، أو جهاز متعاقد، أو حساب تطوير، أو حمولة أخرى لا ينبغي لها إطلاقاً أن تتمتع بتحكم إداري في المضيف. إن عبارة «إنه مفتوح داخل VPC فقط» تصف الشبكة، لكنها لا تمثل نموذجاً للتفويض.\n\n ## المشكلة الجذرية: الوصول إلى Docker هو وصول إلى المضيف\n\n الحاويات حدود عزل مفيدة، لكن الوصول إلى برنامج Docker الخفي امتياز إداري. وتحذر Docker من أن تغيير ربط البرنامج الخفي إلى مقبس TCP، أو منح الوصول إلى مقبس Unix عبر مجموعة `docker`، قد يسمح للمستخدم بالحصول على وصول بمستوى الجذر إلى المضيف. ومن السهل تجاهل هذا التحذير عندما يحاول فريق معالجة مشكلة في نظام البناء أو جعل التطوير عن بُعد أكثر راحة.\n\n قد تتمكن الحاوية التي أُنشئت بامتيازات مرتفعة من رؤية موارد المضيف أو تعديلها. وحتى من دون إعادة تنفيذ سلسلة الهجوم، فإن الدلالة الدفاعية واضحة: تعامل مع بيانات اعتماد برنامج Docker الخفي والوصول إلى المقبس كما تتعامل مع بيانات اعتماد الجذر. وينبغي أن تكون في الفئة نفسها من المخاطر التي تشمل مفاتيح مسؤول السحابة، وواجهات إدارة برامج مراقبة الأجهزة الافتراضية، والوصول إلى مستوى التحكم في Kubernetes.\n\n ولهذا أيضاً فإن حذف حاوية مشبوهة إجراء احتواء ضعيف إذا اتُخذ وحده. فإذا كان المهاجم قد امتلك وصولاً إلى مستوى البرنامج الخفي، فقد يكون قرأ متغيرات البيئة، أو ركّب أدلة من المضيف، أو فحص حاويات أخرى، أو نسخ ملفات الإعداد، أو عدّل آليات بدء التشغيل، أو أنشأ حسابات إضافية، أو جمع بيانات اعتماد من المضيف. وقد لا تكون الحاوية الظاهرة سوى أثر واحد لاختراق أوسع.\n\n وينطبق المبدأ نفسه على مشغلات التكامل والبناء المستمر. فمشغل بناء لديه وصول إلى مقبس Docker ذي امتيازات يمكنه كشف الشيفرة المصدرية، ومواد التوقيع، وبيانات اعتماد الحزم، ورموز السحابة، وصلاحيات النشر. كما أن حاسوب المطور الذي يركب مقبس Docker يمكن أن يكشف الملفات المحلية وبيئة المضيف. وبذلك قد تصل واجهة بعيدة أُنشئت للراحة من سير عمل الحاويات إلى الهوية والبنية التحتية المحيطة به.\n\n ## ما الذي ينبغي للمسؤولين فعله أولاً\n\n يجب أن تقلل الاستجابة الأولى قدرة المهاجم على الوصول من دون إتلاف الأدلة.\n\n ### 1. تحديد كل برنامج Docker خفي ذي تعرض شبكي\n\n ابدأ بجرد موثوق بدلاً من الاعتماد على الذاكرة. راجع مجموعات الأمان السحابية، وجدران الحماية على المضيف، وموازنات التحميل، ومسارات VPN، وسجلات اكتشاف الخدمات، وإعدادات مضيفي الحاويات، وملفات وحدات systemd، وملفات إعداد البرنامج الخفي، وقوالب التنسيق، ومستودعات البنية التحتية كالشيفرة.\n\n ابحث عن مستمعي برنامج Docker الخفي على منفذي TCP 2375 و2376، لكن ابحث أيضاً عن المنافذ المخصصة والروابط التي تجعل البرنامج الخفي يستمع على جميع الواجهات. راجع بيئات الإنتاج وغير الإنتاج معاً. فكثيراً ما تكون مضيفات التطوير أكثر تعرضاً وأقل مراقبة، كما تكون متصلة بشبكات تحتوي على بيانات اعتماد مهمة.\n\n توصي [إرشادات تقليص التعرض على الإنترنت الصادرة عن CISA](https://www.cisa.gov/resources-tools/resources/exposure-reduction) ببناء رؤية للأصول المواجهة للإنترنت وتقليل التعرض غير الضروري. وينطبق النهج نفسه على التعرض الداخلي: حدد ما يمكن الوصول إليه، ومن أين، ولأي سبب تجاري. فالأصل الغائب عن الجرد لا يمكن ترقيعه أو مراقبته أو التحقيق فيه على نحو موثوق.\n\n إذا كان البرنامج الخفي غير الموثق مكشوفاً، فقيّد الوصول فوراً على طبقة الشبكة مع الحفاظ على السجلات وسجلات التغيير. الهدف الطارئ هو إيقاف الاتصالات الجديدة غير الموثقة. ولا تفترض أن تغيير جدار الحماية يثبت نظافة المضيف؛ فهو يغير فقط من يستطيع الوصول إليه.\n\n ### 2. إزالة الوصول البعيد العادي غير المحمي\n\n توصي [الإرشادات الرسمية لـ Docker حول حماية مقبس البرنامج الخفي](https://docs.docker.com/engine/security/protect-access/) باستخدام SSH أو TLS لتأمين الوصول البعيد. وقد يكون SSH خياراً عملياً لسير عمل المشغلين، لأنه يمرر الطلبات إلى مقبس Unix البعيد مع الاعتماد على نموذج المصادقة والتفويض الموجود على المضيف.\n\n عندما يكون وصول TCP مطلوباً فعلاً، استخدم TLS متبادلاً مع مصادقة الطرفين وسلطة شهادات مضبوطة، واحمِ المفاتيح الخاصة، وقيّد شبكات المصدر، وسجّل النشاط الإداري. فخدمة مشفرة بـ TLS لكنها غير موثقة تظل مشكلة تفويض. التشفير يحمي حركة البيانات من المراقبة والتلاعب؛ لكنه لا يقرر ما إذا كان ينبغي السماح لعميل بإنشاء حاويات ذات صلاحيات مرتفعة.\n\n فضّل مسار إدارة خاصاً على مستمع عام. طبّق مبدأ أقل الامتياز على الهويات التي تستطيع إدارة البرنامج الخفي، وافصل الإدارة البشرية عن الأتمتة، وتجنب توزيع شهادة عميل قابلة لإعادة الاستخدام على نطاق واسع على مهام البناء أو فرق متعددة. وينبغي التعامل مع شهادة عميل تمنح وصولاً غير مقيد إلى Docker باعتبارها بيانات اعتماد لجذر المضيف.\n\n لا تعالج التعرض بتغيير رقم المنفذ وحده. يجب أن تتفق مجموعات الأمان، وجدران الحماية على المضيف، والتوجيه، والمصادقة، والتفويض كلها على حد الإدارة المقصود.\n\n ### 3. الحفاظ على الأدلة ومراجعتها\n\n بالنسبة إلى مضيف يحتمل تعرضه، احفظ سجلات النظام، وجدار الحماية، والسحابة، وDocker، والتنسيق، والهوية ذات الصلة قبل تدوير النظام أو إعادة بنائه. حدد الفترة التي كان فيها البرنامج الخفي قابلاً للوصول، وقارنها بتقارير الحملة وبالقياس عن بُعد الموجود لديك.\n\n تشمل أسئلة المراجعة المفيدة ما يلي:\n\n - هل ظهرت طلبات غير متوقعة إلى نقاط نهاية Docker API؟\n- هل أُنشئت حاويات أو شُغّلت أو أوقفت أو أزيلت خارج نوافذ النشر المعتادة؟\n- هل ظهرت صورة أو سجل أو شبكة أو وحدة تخزين أو سر جديد؟\n- هل رُكّبت مسارات من المضيف داخل حاويات على نحو غير متوقع؟\n- هل شُغّلت حاوية بامتيازات مرتفعة، أو بشبكة المضيف، أو بوصول إلى أدلة حساسة؟\n- هل أُنشئت عمليات أو مستخدمون أو مهام مجدولة أو خدمات أو مفاتيح SSH أو إدخالات بدء تشغيل جديدة على المضيف؟\n- هل أجرى المضيف اتصالات صادرة غير معتادة، خصوصاً إلى بنية قيادة وسيطرة أو سجلات غير مألوفة؟\n- هل أظهر مضيفون آخرون في الشبكة نفسها محاولات اتصال مرتبطة بـ Docker بعد ذلك بفترة قصيرة؟\n\n ليس الهدف البحث عن اسم ملف سحري واحد. يستطيع المهاجمون إزالة الحاويات، وإعادة تسمية العمليات، واستخدام أدوات مشروعة، أو نشر حمولة مختلفة. اربط نشاط واجهة API بتنفيذ العمليات، وتدفقات الشبكة، والوصول إلى السجلات، وأحداث التدقيق السحابية، وسجلات مزود الهوية.\n\n إذا كان المضيف يحتوي على حمولات حساسة أو كانت السجلات لا تستطيع تحديد ما حدث، فاعزله واتبع عملية الاستجابة للحوادث في المؤسسة. أعد البناء من صورة موثوقة عندما تكون سلامة المضيف موضع شك. وتكون إعادة البناء أكثر مصداقية عندما تُراجع بيانات الاعتماد والإعدادات ومصنوعات النشر أيضاً، بدلاً من نسخها بالكامل من النظام الذي يحتمل اختراقه.\n\n ### 4. تدوير الأسرار المكشوفة وفقاً لسلطتها\n\n افترض أن الأسرار التي كان يستطيع برنامج Docker الخفي أو المضيف أو وحدات التخزين المركبة أو متغيرات البيئة أو طبقات الصور أو العمليات قيد التشغيل قراءتها ربما انكشفت. أعطِ الأولوية لبيانات الاعتماد بحسب ما تستطيع فعله، لا بحسب المكان الذي خُزنت فيه.\n\n قد يشمل ذلك مفاتيح الوصول إلى السحابة، ورموز CI، ورموز مستودعات الشيفرة، وبيانات اعتماد السجلات، وكلمات مرور قواعد البيانات، ومفاتيح SSH، ومفاتيح التوقيع، وأسرار الويب هوك، ورموز حسابات الخدمة، وبيانات الاعتماد المضمّنة في ملفات النشر. ألغِها أو أدرها من مسار إداري موثوق. وتحقق مما إذا كانت بيانات الاعتماد الجديدة قد استُخدمت على نحو غير متوقع بعد إصدارها.\n\n تدوير بيانات الاعتماد من دون إلغاء القديمة غير مكتمل إذا ظلت القديمة صالحة. كما أن التدوير من دون مراجعة السجلات يفوّت احتمال أن المهاجم استخدم السر بالفعل للوصول إلى خدمة أخرى. والتدوير من دون خريطة للاعتماديات قد يعطل الإنتاج، لذلك ينبغي تنسيقه، لكن الإزعاج التشغيلي ليس سبباً لترك بيانات اعتماد عالية القيمة فعالة بعد تعرض موثوق.\n\n راجع أيضاً الأسرار التي لم تُخزّن مباشرة على المضيف لكنها كانت قابلة للوصول من خلال هويته. فقد يوسّع دور مثيل سحابي مخترق، أو هوية حمولة، أو حساب خدمة CI نطاق الحادث إلى ما هو أبعد بكثير من خادم Docker واحد.\n\n ## كيف تبدو البنية الآمنة\n\n يحتوي إعداد Docker القابل للدفاع عنه عادةً على مسار إداري ضيق وسبب صريح لكل استثناء.\n\n في الإدارة المحلية، أبقِ مقبس Unix الافتراضي محمياً بضوابط الوصول على المضيف، وقيّد العضوية في مجموعة `docker`. فالعضوية ليست تسهيلاً بريئاً؛ إذ يمكنها توفير تحكم واسع في البرنامج الخفي، وبالتالي في المضيف.\n\n في الإدارة البعيدة، استخدم SSH أو TLS متبادل المصادقة، وقيّد عناوين المصدر، وضع الخدمة خلف شبكة إدارة أو VPN حيثما كان ذلك مناسباً. احتفظ بالسجلات خارج المضيف حتى لا يستطيع المهاجم محو النسخة الوحيدة. راقب إصدار الشهادات، واستخدام المفاتيح، والتغييرات في إعداد البرنامج الخفي.\n\n في بيئات CI، تجنب منح مهمة بناء غير موثوقة مقبس مضيف ذي امتيازات. ضع في الحسبان الأوضاع عديمة الجذر، والمشغلين المعزولين، والعاملين قصيري العمر، وفصل هويات البناء عن هويات النشر، وواجهات API محدودة النطاق. وإذا احتاج البناء فعلاً إلى عمليات ذات امتيازات، فتعامل مع المشغل باعتباره نظاماً إدارياً عالي المخاطر واعزله وفقاً لذلك.\n\n في البيئات السحابية، أدرج مستمعي Docker ضمن إدارة سطح الهجوم واكتشاف انحراف الإعداد. فقد يُفسد قالب آمنَ نص تشغيل لاحق، أو إعداداً مضمّناً في صورة، أو أمراً استُخدم لاستكشاف مشكلة، أو استثناءً مؤقتاً في جدار الحماية يتحول إلى إعداد دائم.\n\n بالنسبة إلى المطورين، وثّق سير العمل المعتمد للوصول البعيد. كثيراً ما تنشئ الفرق مستمعين غير آمنين لأن المسار الآمن غير واضح أو غير مريح. ويوفر سياق SSH مدعوم، أو بيئة تطوير مُدارة، أو خدمة بناء مصممة جيداً، بديلاً عن ضغط كشف البرنامج الخفي مباشرة.\n\n ## كيف تميز بين التعرض والاختراق المؤكد\n\n إن وجود مستمع Docker عام أو واسع الانتشار داخلياً نتيجة خطيرة، لكنه لا يثبت تلقائياً أن مهاجماً استخدمه. أبقِ الحالات الثلاث منفصلة في سجلات الحوادث:\n\n 1. **تأكد التعرض:** كان البرنامج الخفي يقبل، أو يستطيع قبول، اتصالات من شبكة غير موثوقة.\n2. **تحديد نشاط مشبوه:** تظهر السجلات أو القياس عن بُعد على المضيف طلبات أو عمليات أو نشاطاً شبكياً أو تغييرات إعداد لا تفسرها أعمال مصرح بها.\n3. **تأكد الاختراق:** يملك المحققون أدلة كافية على أن طرفاً غير مصرح له حصل على التحكم أو وصل إلى البيانات.\n\n يحسن هذا التفريق القرارات. فتأكد التعرض يجب أن يؤدي إلى الإغلاق الفوري ومراجعة قائمة على المخاطر. وتحديد النشاط المشبوه يجب أن يؤدي إلى الاحتواء والاستجابة للحادث. أما تأكد الاختراق فيجب أن يؤدي إلى تحديد النطاق الكامل، وإلغاء بيانات الاعتماد، والاستعادة، وتقييم الحاجة إلى الإخطار، واستخلاص الدروس.\n\n كما يمنع هذا التفريق خطأين شائعين. الأول هو التهاون: «لم نرَ حاوية خبيثة، إذن كان التعرض بلا ضرر». والثاني هو المبالغة: «كان المنفذ 2375 مفتوحاً، إذن اختُرقت البيئة بأكملها بالتأكيد». يمكن للتقرير الأمني الجيد أن يكون عاجلاً من دون التظاهر بمعرفة أكثر مما تسمح به الأدلة.\n\n ## زاوية الذكاء الاصطناعي ثانوية، لكنها مفيدة\n\n يشير استخدام CARBONATO لإطار وكلاء الذكاء الاصطناعي إلى طريقة قد يعبّئ بها المهاجمون الأتمتة، لكنه ليس سبباً لاعتبار كل مكوّن للذكاء الاصطناعي خبيثاً بطبيعته. والإطار الذي وصفه تحالف أمن السحابة مفتوح المصدر ويمكن أن تكون له استخدامات مشروعة. وإعادة توظيفه داخل شبكة روبوتية تجسد نمطاً أمنياً مألوفاً: يصبح البرنامج المشروع جزءاً من هجوم عندما يسيطر الخصم على بيئة التنفيذ والإعداد المحيطين به.\n\n لذلك ينبغي للمدافعين إضافة البرامج المثبتة، وملفات الإعداد، والنشاط المجدول، والوجهات الصادرة، وبيانات الاعتماد التي جرى الوصول إليها إلى نطاق التحقيق. فالبحث عن اسم منتج واحد فقط قد يفوّت نشراً معدلاً أو حمولة مختلفة تماماً. وفي المقابل، فإن حظر اسم إطار مشروع من دون إصلاح تعرض Docker يترك مسار الوصول الأصلي مفتوحاً.\n\n والدرس الأوسع يتعلق بحدود الأتمتة. قد يجعل إطار الذكاء الاصطناعي الذي يعمل على مضيف مخترق تنفيذ المهام أكثر مرونة، لكنه لا ينشئ السلطة الأولية. فقد جاءت السلطة من برنامج Docker الخفي. وتظل المصادقة القوية، وتقسيم الشبكة، وسلامة المضيف، ونظافة بيانات الاعتماد، والسجلات المفيدة هي الضوابط المهمة.\n\n ## قائمة عملية للمراجعة التالية\n\n يمكن للفرق تحويل هذه الحادثة إلى مراجعة ضوابط قابلة للتكرار:\n\n - جرد جميع برامج Docker الخفية والشبكات التي تستطيع الوصول إليها.\n- تأكد من عدم كشف واجهة Docker API غير موثقة على الإنترنت أو على شبكة داخلية غير موثوقة.\n- ابحث عن TCP 2375 وعن مستمعي البرنامج الخفي المخصصين، لا عن أسماء الخدمات المتوقعة فقط.\n- استبدل إدارة TCP غير الرسمية بـ SSH أو TLS متبادل المصادقة مضبوط على نحو صحيح.\n- قيّد الوصول إلى مقبس Docker وراجع العضوية في مجموعة `docker`.\n- افصل مشغلي CI عن شبكات الإنتاج الحساسة وبيانات الاعتماد الحساسة.\n- اجمع سجلات Docker والمضيف وجدار الحماية والسحابة والهوية والسجل في مكان مركزي.\n- راجع إنشاء الحاويات غير المتوقع، وإعدادات الامتيازات، وتركيبات المضيف، والصور الجديدة، والاتصالات الصادرة.\n- أدر بيانات الاعتماد التي ربما كانت قابلة للقراءة من المضيفين أو الحمولات المتأثرة.\n- أعد بناء المضيفين عندما لا يمكن إثبات سلامتهم من وسائط موثوقة.\n- أضف تعرض البرنامج الخفي وانحراف الإعداد إلى الفحوص الأمنية الدورية.\n- وثّق سير عمل معتمداً للإدارة البعيدة حتى لا ينشئ المهندسون مستمعين طارئين.\n\n ## المصادر\n\n - [نشرة حول حملة شبكة CARBONATO الروبوتية التي تستهدف برامج Docker الخفية المكشوفة](https://www.csa.gov.sg/alerts-and-advisories/advisories/ad-2026-012/) — وكالة الأمن السيبراني في سنغافورة، مصدر حقائق، 30 سبتمبر 2026.\n- [Carbonato: وكيل ذكاء اصطناعي تتحكم به Telegram يختطف مضيفي Docker](https://labs.cloudsecurityalliance.org/research/csa-research-note-carbonato-botnet-docker-ai-agent-20260928/) — تحالف أمن السحابة، مصدر حقائق، 28 سبتمبر 2026.\n- [حماية مقبس برنامج Docker الخفي](https://docs.docker.com/engine/security/protect-access/) — وثائق Docker، مصدر سياقي.\n- [إعداد الوصول البعيد إلى برنامج Docker الخفي](https://docs.docker.com/engine/daemon/remote-access/) — وثائق Docker، مصدر سياقي.\n- [مرجع أمر dockerd وتحذيرات الأمان](https://docs.docker.com/reference/cli/dockerd/) — وثائق Docker، مصدر سياقي.\n- [إرشادات تقليص التعرض على الإنترنت](https://www.cisa.gov/resources-tools/resources/exposure-reduction) — وكالة الأمن السيبراني وأمن البنية التحتية، مصدر سياقي.\n- [تستخدم برمجية Carbonato الخبيثة الجديدة وكلاء الذكاء الاصطناعي لاختطاف مضيفي Docker المكشوفين](https://www.bleepingcomputer.com/news/security/new-carbonato-malware-uses-ai-agents-to-hijack-exposed-docker-hosts/) — BleepingComputer، مصدر نقاشي.\n\n تذكّر CARBONATO في الوقت المناسب بأن طبقة التحكم في منصة الحاويات نفسها أصل بالغ الأهمية. الإجراء الدفاعي الحاسم ليس التكهن بمدى جدة الحمولة، بل التحقق ممن يستطيع الوصول إلى البرنامج الخفي، وما الذي يستطيع البرنامج الخفي فعله، وما الذي فعله مؤخراً، وما الهويات التي ستنكشف إذا اختُرق المضيف. وعندما تصبح هذه الأسئلة جزءاً روتينياً من العمل، يصبح التحكم في الخطر أسهل من دون هلع أو تفكير رغائبي.","available_translations":[{"language":"ar","title":"تكشف CARBONATO لماذا يعني كشف واجهة Docker API اختراق المضيف، لا مجرد مشكلة في الحاوية","html_url":"https://publicasta.com/cybersecurity/carbonato_exposed_docker_daemons_response?lang=ar","markdown_url":"https://publicasta.com/cybersecurity/carbonato_exposed_docker_daemons_response.md?lang=ar","json_url":"https://publicasta.com/cybersecurity/carbonato_exposed_docker_daemons_response.json?lang=ar","api_url":"https://publicasta.com/api/public/v1/channels/cybersecurity/articles/carbonato_exposed_docker_daemons_response?lang=ar"},{"language":"de","title":"CARBONATO zeigt, warum eine offengelegte Docker-API ein Host-Kompromittierungsszenario und kein Containerproblem ist","html_url":"https://publicasta.com/cybersecurity/carbonato_exposed_docker_daemons_response?lang=de","markdown_url":"https://publicasta.com/cybersecurity/carbonato_exposed_docker_daemons_response.md?lang=de","json_url":"https://publicasta.com/cybersecurity/carbonato_exposed_docker_daemons_response.json?lang=de","api_url":"https://publicasta.com/api/public/v1/channels/cybersecurity/articles/carbonato_exposed_docker_daemons_response?lang=de"},{"language":"en","title":"CARBONATO Shows Why an Exposed Docker API Is a Host Compromise, Not a Container Problem","html_url":"https://publicasta.com/cybersecurity/carbonato_exposed_docker_daemons_response?lang=en","markdown_url":"https://publicasta.com/cybersecurity/carbonato_exposed_docker_daemons_response.md?lang=en","json_url":"https://publicasta.com/cybersecurity/carbonato_exposed_docker_daemons_response.json?lang=en","api_url":"https://publicasta.com/api/public/v1/channels/cybersecurity/articles/carbonato_exposed_docker_daemons_response?lang=en"},{"language":"es","title":"CARBONATO demuestra por qué una API de Docker expuesta implica comprometer el host, no solo un contenedor","html_url":"https://publicasta.com/cybersecurity/carbonato_exposed_docker_daemons_response?lang=es","markdown_url":"https://publicasta.com/cybersecurity/carbonato_exposed_docker_daemons_response.md?lang=es","json_url":"https://publicasta.com/cybersecurity/carbonato_exposed_docker_daemons_response.json?lang=es","api_url":"https://publicasta.com/api/public/v1/channels/cybersecurity/articles/carbonato_exposed_docker_daemons_response?lang=es"},{"language":"fr","title":"CARBONATO montre qu’une API Docker exposée compromet l’hôte, pas seulement les conteneurs","html_url":"https://publicasta.com/cybersecurity/carbonato_exposed_docker_daemons_response?lang=fr","markdown_url":"https://publicasta.com/cybersecurity/carbonato_exposed_docker_daemons_response.md?lang=fr","json_url":"https://publicasta.com/cybersecurity/carbonato_exposed_docker_daemons_response.json?lang=fr","api_url":"https://publicasta.com/api/public/v1/channels/cybersecurity/articles/carbonato_exposed_docker_daemons_response?lang=fr"},{"language":"pl","title":"CARBONATO pokazuje, że ujawnione API Dockera oznacza przejęcie hosta, a nie tylko problem z kontenerem","html_url":"https://publicasta.com/cybersecurity/carbonato_exposed_docker_daemons_response?lang=pl","markdown_url":"https://publicasta.com/cybersecurity/carbonato_exposed_docker_daemons_response.md?lang=pl","json_url":"https://publicasta.com/cybersecurity/carbonato_exposed_docker_daemons_response.json?lang=pl","api_url":"https://publicasta.com/api/public/v1/channels/cybersecurity/articles/carbonato_exposed_docker_daemons_response?lang=pl"},{"language":"ru","title":"CARBONATO показывает: открытый Docker API — это компрометация хоста, а не проблема контейнера","html_url":"https://publicasta.com/cybersecurity/carbonato_exposed_docker_daemons_response?lang=ru","markdown_url":"https://publicasta.com/cybersecurity/carbonato_exposed_docker_daemons_response.md?lang=ru","json_url":"https://publicasta.com/cybersecurity/carbonato_exposed_docker_daemons_response.json?lang=ru","api_url":"https://publicasta.com/api/public/v1/channels/cybersecurity/articles/carbonato_exposed_docker_daemons_response?lang=ru"},{"language":"zh","title":"CARBONATO 揭示：暴露在公网的 Docker API 是主机失陷问题，而不只是容器问题","html_url":"https://publicasta.com/cybersecurity/carbonato_exposed_docker_daemons_response?lang=zh","markdown_url":"https://publicasta.com/cybersecurity/carbonato_exposed_docker_daemons_response.md?lang=zh","json_url":"https://publicasta.com/cybersecurity/carbonato_exposed_docker_daemons_response.json?lang=zh","api_url":"https://publicasta.com/api/public/v1/channels/cybersecurity/articles/carbonato_exposed_docker_daemons_response?lang=zh"}],"_links":{"self":"https://publicasta.com/cybersecurity/carbonato_exposed_docker_daemons_response.json?lang=ar","api":"https://publicasta.com/api/public/v1/channels/cybersecurity/articles/carbonato_exposed_docker_daemons_response?lang=ar","html":"https://publicasta.com/cybersecurity/carbonato_exposed_docker_daemons_response?lang=ar","canonical":"https://publicasta.com/cybersecurity/carbonato_exposed_docker_daemons_response?lang=ar","markdown":"https://publicasta.com/cybersecurity/carbonato_exposed_docker_daemons_response.md?lang=ar","json":"https://publicasta.com/cybersecurity/carbonato_exposed_docker_daemons_response.json?lang=ar","channel":"https://publicasta.com/api/public/v1/channels/cybersecurity","channel_articles":"https://publicasta.com/api/public/v1/channels/cybersecurity/articles","search":"https://publicasta.com/api/public/v1/search","documentation":"https://publicasta.com/api-docs#reading-publicasta","openapi":"https://publicasta.com/api-docs/openapi.json","llms":"https://publicasta.com/llms.txt"}}