ثلاث جهات، وضابط واحد: قائمة وجهات مسموح بها لوكلاء AI على خادم Linux، ولماذا لا يكفي فرض قيود داخل الأداة

إذا كان خادمك يشغّل n8n أو وكيلًا ينفّذ مهام أو خادم MCP أو سكربتًا يتواصل مع نموذج، ففيه عملية تقرر بنفسها إلى أين تتصل عبر الشبكة. ومن المرجح أن القيود التي وضعتها لها موجودة داخل الأداة نفسها: إعداد في ملف، أو تعليمة في الموجّه، أو قائمة أدوات مسموح بها. أما الاتصالات، فيجب تسجيلها في مكان لا يكتب فيه الوكيل.

ما نُشر

Anthropic، 9 أكتوبر. نشرت الشركة تقريرًا عن أفعال غير مقصودة للنماذج رُصدت أثناء التقييمات والاستخدام الداخلي. يصف التقرير أربعة أنواع من السلوك: استغلال عيوب أساسية في برمجيات موقع تابع لطرف ثالث لتنفيذ أوامر على خادمه، وإرسال نموذج حقيقي على موقع بدلًا من نموذج تدريبي، وتجاوز قيد للوصول إلى معلومات يتطلب الوصول إليها رمزًا أو دفع رسوم، واستخدام خدمات اختصار الروابط لتجاوز قيد في أداة fetch. وبحسب الشركة، كان الأثر الفعلي للحالات المكتشفة حتى الآن ضئيلًا، ولم تمسّ أي منها بيانات العملاء، على حد علمها. وبناءً على هذه النتائج، وسّعت الشركة قطع الاتصال المباشر بالإنترنت ليشمل جميع التقييمات الداخلية. وسيستمر القطع إلى أن تتحقق من أن وسائل المراقبة لديها ترصد هذه السلوكيات بصورة موثوقة. وتعمل الشركة أيضًا على تقليص وصول وكلائها الداخليين إلى الإنترنت ونقلهم إلى بنية تحتية مُدارة ذات عزل قوي.

MITRE ATT&CK. أُضيفت التقنية T1700, AI-Enabled Exfiltration إلى الإصدار 20 من ATT&CK. تصف التقنية مهاجمًا يدفع وكيل AI تابعًا لمؤسسة إلى تسريب معلومات، من خلال حقن موجّه مباشر أو غير مباشر، أو بطرق أخرى. ويستغل المهاجم لهذا الغرض الأدوات التي يُسمح للوكيل باستخدامها. يصف أحد تحليلات استراتيجية الكشف المرفقة بالتقنية عملية مرتبطة بالذكاء الاصطناعي تصل إلى معلومات خارج النطاق المسموح به. ثم ينشأ اتصال من سلسلة العمليات نفسها إلى وجهة غير مدرجة في قائمة نقاط النهاية المسموح بها للذكاء الاصطناعي. وبحسب Cyber Security News، صدر هذا الإصدار في 13 أكتوبر.

CERT-In، 15 أكتوبر. نشر الفريق الوطني الهندي للاستجابة للطوارئ التنبيه CIAD-2026-0049 بدرجة خطورة Critical. وبحسب الهيئة، أبلغ مزوّدو نماذج طوعًا بأن نماذجهم وصلت، أثناء البحث والتقييم، إلى أنظمة فعلية لمؤسسات في الهند وقرأت سجلات أعمال، منها معلومات شخصية ومواد سرية. أتاح هذا الوصولَ وجود بيانات اعتماد مكشوفة في ملفات الإعداد ومستودعات الشيفرة العامة، وصلاحيات سحابية أوسع من اللازم. ولم تكتشف أي من المؤسسات هذا الوصول بنفسها. تشمل التوصيات حظر حركة الشبكة الصادرة (egress) افتراضيًا، والسماح فقط بالوجهات اللازمة للمهمة. ويجب فرض ذلك على مستوى الشبكة، لا عبر تعليمات للنموذج. وتوصي الهيئة أيضًا بتسجيل الطلبات التي بدأها النموذج، قدر الإمكان: الوجهة والمنفذ والبروتوكول والنتيجة. وللمؤسسات التي تشغّل وكلاء، توصي الهيئة بتخصيص هوية منفصلة وقصيرة العمر لكل تشغيل، وقصر حركة الشبكة الصادرة على الوجهات اللازمة، والاحتفاظ بسجل نشاط مقاوم للتعديل.

ثلاثة مصادر، ومواصفات واحدة

تُظهر قراءة المنشورات الثلاثة معًا ثلاثة متطلبات تتكرر فيها جميعًا.

يُفرض القيد خارج الوكيل. يبيّن تقرير Anthropic السبب. فبحسب الشركة، تقيّد بعض أدوات fetch لديها طول العناوين التي يمكن للنموذج طلبها. والهدف هو تقليل خطر استخدام العناوين الطويلة لأفعال غير مرغوب فيها، مثل إخراج كميات أكبر من المعلومات. تجاوزت بعض النماذج، ومنها Claude Opus 5 وClaude Mythos 5، هذا القيد باستخدام خدمات مجانية لاختصار الروابط. ورصد مشغّل خدمة da.gd هذا الاستخدام أيضًا وأبلغ الشركة به. تصف Anthropic معظم هذه السلوكيات بأنها إصرار (persistence): عندما يعجز النموذج عن إتمام المهمة كما حُددت، يتجاوز القيد بدلًا من التوقف. وتشير الشركة أيضًا إلى أن بعض الحالات وقعت أثناء الاستخدام المعتاد للوكلاء، وليس في التقييمات وحدها. ويتلقى وكيلك أيضًا مهام بالقدر نفسه من الغموض. وعندما يرى الوكيل في القيد عقبة أمام الهدف، فقد يبحث عن طريقة لتجاوزه. أما قاعدة جدار الحماية في النواة، فلا تخضع للتفاوض مع الوكيل.

يرتبط القيد بالعملية. يربط تحليل MITRE الاتصال الصادر بسلسلة عمليات الوكيل، وتطلب CERT-In هوية منفصلة لكل تشغيل. ولا تلبّي قائمة سماح واحدة للخادم بأكمله هذا المتطلب: فعملية النسخ الاحتياطي تحتاج إلى الوصول إلى تخزين الكائنات، وCI يحتاج إلى الوصول إلى مستودع الشيفرة، بينما لا يحتاج الوكيل على الأرجح إلى أي منهما. يجب أن تكون لكل وكيل قائمته الخاصة.

لا يعتمد التسجيل على أقوال الوكيل. تحذّر CERT-In من الاعتماد فقط على مراجعة نصوص التفاعلات بعد وقوعها. فقد تفوّت هذه المراجعة نشاطًا يعرضه النموذج على أنه مشروع في تبريره. وتكتب Anthropic أن ما يورده النموذج عن استدلاله ليس بالضرورة دليلًا موثوقًا على أسباب تصرفه. ففي إحدى الحالات، بحسب التقرير، ادّعى النموذج في تبريره أنه يكتفي بعرض خطوات العملية، لكنه أرسل النموذج فعليًا. أما التسجيل الذي يمكن الاعتماد عليه، فيجري على مستوى الاتصالات، بواسطة مكوّن آخر.

ما نتعلمه من خدمات اختصار الروابط

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

وللسبب نفسه، يُفضّل اعتماد أسماء مضيفين محددة بدلًا من نطاقات كاملة. فالسماح الشامل بنطاق يتيح الوصول إلى جميع نطاقاته الفرعية، وهي تحديدًا مواضع يمكن إخفاء المعلومات فيها. واستعلامات DNS أيضًا قناة لنقل المعلومات: إذ يمكن تضمين البيانات في الاسم الذي يطلب الوكيل الاستعلام عنه.

فجوة Linux، والقائمة التي لم يكتبها أحد نيابةً عنك

تظهر في صفحة T1700 منصتان فقط: SaaS وWindows. ولا يظهر Linux. لا يعني ذلك أن الخطر غير موجود على خادم Linux، بل يعني أنه لا يوجد لديك ربط جاهز لهذه التقنية ببيئتك. كما تستند تحليلات الكشف لدى MITRE إلى معاملات مثل $AuthorizedAIEndpoints$ و$AuthorizedAIDataScope$. ونرى أن طريقة كتابتها تشير إلى أنها متغيرات يجب تحديد قيم لها. ولم يحددها أحد لخادمك. كذلك تفترض توصية CERT-In بالسماح بحركة الشبكة الصادرة إلى الوجهات اللازمة فقط أنك تعرف هذه الوجهات. لذلك، فإن مهمتك الأولى هي كتابة القائمة. فمن دونها، لا يوجد ما يمكن فرضه أو الاستناد إليه في الكشف.

تشير CERT-In إلى جانب آخر. فبحسب الهيئة، كانت نقاط الضعف المستغلة في جميع الحوادث التي شارك فيها وكلاء AI معروفة: بيانات اعتماد مكشوفة في الشيفرة وسجل المستودعات وملفات الإعداد، وواجهات API مهجورة، وواجهات إدارة مكشوفة للإنترنت، وبرمجيات وسيطة لم تُحدّث. وفي الحوادث التي أُبلغ عنها طوعًا، رُصد وكلاء يستعيدون بيانات الاعتماد المكشوفة نفسها ويعيدون استخدامها في عمليات منفصلة. أي إن خادمك قد يكون أيضًا وجهة لاتصالات وكيل يشغّله شخص آخر.

خطوات عملية

• احصر الوكلاء. لا تكتفِ بالعمليات التي تستمع على منفذ، بل أدرج أيضًا العمليات التي تتصل بالخارج فقط: وكيل ينفّذ مهمة، أو عملية أتمتة، أو سكربت مجدول.
• راقب قبل أن تكتب. سجّل على مدى فترة الوجهات التي تتصل بها كل عملية فعليًا، وحجم حركة الشبكة إلى كل وجهة.
• اكتب قائمة لكل وكيل. استخدم أسماء مضيفين محددة، بلا أحرف بدل. ولا تُدرج خدمات الاختصار وإعادة التوجيه، أو مواقع لصق النصوص، أو نقاط نهاية webhook العامة.
• افرض القيود على مستوى الشبكة، بحسب العملية. لا في الموجّه ولا في إعدادات الأداة. في Linux، يمكنك مثلًا استخدام IPAddressAllow في systemd، أو قاعدة nftables مخصّصة لـ cgroup الخاص بالخدمة.
• قيّد DNS أيضًا. يجب ألا يستعلم الوكيل المقيّد إلا عن الأسماء التي اعتمدتها.
• سجّل في مكان لا يكتب فيه الوكيل. سجّل الوجهة والمنفذ والبروتوكول والنتيجة. توصي CERT-In بالاحتفاظ بالسجلات لمدة لا تقل عن 180 يومًا.
• افحص الوصول الوارد أيضًا. ابحث عن بيانات اعتماد مكشوفة في الشيفرة وسجل commit وملفات الإعداد. واستبدل كل بيانات اعتماد انكشفت، وأزل إمكانية الوصول من الإنترنت إلى واجهات الإدارة، واشترط المصادقة متعددة العوامل لكل وصول إداري.

كيف يساعد nuDefend

ما الذي يعمل. يعرض nudefend workloads أدوات AI التي تعمل على الخادم: خوادم النماذج، وواجهات الدردشة، وقواعد البيانات المتجهية، ومنصات الأتمتة، وخوادم MCP. ويعرض الأدوات التي تعمل على المضيف أو داخل حاوية، والأساس الذي استند إليه في التعرّف على كل منها. ويتعرّف nuDefend أيضًا على الوكلاء الذين لا يستمعون للاتصالات، بل يتصلون بالخارج فقط.

إلى أين يتصل. يسجّل nuDefend الوجهات التي تتصل بها كل أداة AI، وحجم حركة الشبكة المرسلة إلى كل وجهة، ووقت رصد الوجهة أول مرة. وعندما يتعرّف على الوجهة، يعرض اسمها ووصفًا لنوع نشاطها. يعرض nudefend egress review <workload> جميع وجهات أداة واحدة، ويبيّن ما إذا كانت المراقبة قد غطّت الفترة كاملة. وتُحفظ التقارير والسجل التاريخي في قاعدة بيانات محلية على الخادم.

تُبنى القائمة من حركة الشبكة الفعلية. في المرحلة الأولى، يكتفي nuDefend بالتسجيل. وفي نهاية فترة المراقبة، تتكوّن قائمة تستند إلى حركة الشبكة المرصودة. وفي شاشة Outbound، تعتمد الوجهات التي تحتاج إليها الأداة فعلًا. أما العناوين التي تشترك عدة خدمات في استخدامها، فلا تُعتمد تلقائيًا، بل تُعلّم لمراجعتك.

تُفرض القيود في طبقة أدنى من الأداة. بعد تفعيل القيد، لا تستطيع الأداة الاتصال إلا بالوجهات التي اعتمدتها. وتُحظر كل محاولة للاتصال بوجهة أخرى قبل أن تغادر حركة الشبكة الخادم. ولا يسري القيد إلا على الأداة التي اخترتها، بينما يواصل باقي الخادم العمل كالمعتاد. ويمكن تطبيق القيد على كل أداة يتعرّف عليها النظام تقريبًا، وتوضح الشاشة لكل أداة ما إذا كانت مقيّدة. وإذا لم تؤكد القيد نهائيًا خلال عشر دقائق، فسيُلغى تلقائيًا. يراقب nuDefend نفسه ويستعيد قواعده إذا حاول أحد تغييرها.

وما يستعلم عنه أيضًا. لا تستطيع الأداة المقيّدة الاستعلام إلا عن العناوين التي اعتمدتها. ويُوقَف أي استعلام آخر قبل أن يغادر الخادم. ويسري الاعتماد على الاسم المحدد، لا على نطاقاته الفرعية. ويظهر كل استعلام أُوقف في الشاشة بجانب اسم الأداة. وغالبًا ما يكون ذلك أول مؤشر على أن أداة تحاول الوصول إلى وجهة لم تعتمدها.

والجانب المستقبِل أيضًا. يعرض nudefend expose كل خدمة تستمع على الخادم، ومن يستطيع الوصول إليها. وينبّه nuDefend عندما تصبح خدمة كانت داخلية متاحة من الخارج. وتُحدّث قائمة تهديدات موقّعة كل 30 دقيقة، وتحظر حركة الشبكة إلى العناوين والنطاقات الخبيثة ومنها. وتُحظر في جدار الحماية المحاولات المتكررة لتخمين كلمات المرور في SSH والبريد وFTP وصفحات تسجيل الدخول إلى الموقع.

مزيد من التفاصيل في صفحة حركة الشبكة الصادرة، وصفحة الانكشاف، والوثائق.

الخلاصة

يشير مختبر AI، وإطار تقنيات MITRE، وهيئة وطنية للأمن السيبراني إلى الضابط نفسه: قائمة وجهات معتمدة لكل وكيل، تُفرض على مستوى الشبكة لا في الموجّه، وتسجيل للاتصالات لا يعتمد على أقوال الوكيل. وتوضح حالات استخدام خدمات اختصار الروابط التي وصفتها Anthropic ما يحدث عندما يكون القيد داخل الأداة. على خادم Linux، لم يكتب أحد قائمة الوجهات المسموح بها نيابةً عنك. لذلك، هذه هي المهمة الأولى: التحقق من الوجهات التي يتصل بها كل وكيل، وكتابة قائمة لا تشمل خدمات تمرير عامة، وفرضها في طبقة أدنى من الوكيل.