الخلاصة

  • تحوّل أداة Abuse Contact Finder بادئةً أو عنوان IP أو رقم ASN إلى عناوين abuse-c المعنية بتلقي تقارير الإساءة، لكن وثائق الأداة نفسها تحذّر من أن هذه المعلومات «غير صحيحة أو غير متاحة في كثير من الحالات».
  • تتأكد السياسة 2017-02 من أن صندوق abuse-c مُهيّأ ومن أن الرسائل يمكن أن تصل إليه، ولا تفحص ما يحدث بعد التسليم؛ وقد صيغ هذا الحد صراحةً في نقاش إعادة التحقق الدوري الذي سُحب اقتراحه في 2020.

ما تفعله الأداة، وما تقوله عن حدودها

عند إدخال بادئة أو عنوان IP واحد أو رقم نظام مستقل (ASN) في واجهة Abuse Contact Finder، يعيد الاستعلام قائمة abuse_contacts — وهي عناوين البريد المخصصة لتلقي تقارير الإساءة — إلى جانب الحقل authoritative_rir الذي يحدد السجل الإقليمي المسؤول عن المورد. لا يستنبط الاستعلام عناوين من الويب، بل يقرأ ما هو مسجّل في قاعدة بيانات RIPE، وتصف الوثائق نفسها البيانات بأنها “in many cases incorrect or not available”؛ أي إن الأداة توجّه المراسلة ولا تضمن أن يقرأ أحد الرسالة.

وتضع RIPE-658، الموجّهة إلى فرق الاستجابة للحوادث وجهات معالجة الإساءة، قاعدة بيانات RIPE وRIPEstat بين الأدوات التي يمكن استخدامها لإيجاد «أفضل جهة اتصال مطابقة» لمورد مثل عنوان IP، وتصف سجل abuse-c بأنه «الطريقة المفضلة للإبلاغ عن أي شكل من أشكال الإساءة». أما الدليل العملي على RIPE Labs فقد شرح كيفية الاستعلام بالعنوان أو البادئة أو رقم ASN، وبيّن أن الأداة تعرض منذ 2015 عنوان abuse-c وحده امتثالًا للسياسة ripe-563، واقترح صياغة يمكن للمُبلّغ إضافتها إلى رسالته لبيان أن العنوان وُجد عبر الأداة.

ويحدد موقع RIPE NCC الخاص بالإساءة توزيع المسؤولية بصراحة: مشغّل الشبكة، لا RIPE NCC، هو المسؤول عن معالجة تقرير الإساءة، ودور NCC يقتصر على التأكد من أن عناوين abuse-c في قاعدة البيانات صالحة ومحدّثة. ويضيف الموقع: “There is nothing we can do if a network operator chooses not to reply”.

ما تفحصه عملية التحقق وما تستبعده صراحةً

شرحت RIPE NCC في تعريف طريقة التحقق أن الأداة المنفذة للسياسة 2017-02 تبحث عن أخطاء التنسيق، وتتحقق من سجلات DNS، وتلتمس العناوين الوهمية أو الفخاخ (honeypot)، وتستخدم ping للتأكد من وجود صندوق البريد وقدرته على استقبال الرسائل. لا ترسل العملية أي بريد، ولا تتطلب أي إجراء عند النجاح، والموارد القديمة (legacy) خارج نطاق السياسة. وتنقل الوثيقة أيضًا: “We have no say in what network operators do with any abuse reports they receive”.

أرقام التنفيذ: 77,168 سمة و5,457 حالة إخفاق

وفق ملخص تنفيذ السياسة في RIPE 79، فُحصت 77,168 سمة abuse-mailbox مميزة؛ اجتاز 71,711 منها (93%) التحقق الآلي، وأخفق 5,457 (7%). تحقق توافق السياسة في 1 يونيو 2018 واكتمل تنفيذها في 10 أكتوبر 2019، مع تحديث نحو 8,000 سمة خلال 2019. استلزم التحقق الأولي ثلاثة موظفين مؤقتين بدوام كامل، واحتاج 20-25% من التذاكر إلى متابعة يدوية.

وفي تحديث النتائج المنشور في مايو 2019، حُدّثت نحو 9,500 جهة اتصال من أصل نحو 67,000 فُحصت (والرقم يشمل التكرارات)، وحُلّت نحو 60% من الحالات دون تدخل موظفي NCC، مع تغيّر وضع الإسناد لنحو 50 موردًا مستقلًا.

اقتراح 2019-04: الخط الذي رُسم ثم أُزيل

كان الاقتراح 2019-04 سيفرض التحقق كل ستة أشهر على الأقل من وجود صندوق abuse-c وقدرته على الاستقبال، ونصّت صفحته على أن «عملية التحقق هذه لن تفحص كيفية معالجة حالات الإساءة». وقدّرت تحليلات أثر NCC أن تطبيق النظام على نحو 93,000 سمة مميزة سيستلزم أكثر من 32,000 تذكرة في كل جولة، أي 64,000 تذكرة سنويًا، منها نحو 19,200 تذكرة يدوية في السنة. سُحب الاقتراح في 8 سبتمبر 2020، وفي 26 أكتوبر 2020 أيّد رؤساء مجموعات العمل قرار رؤساء مجموعة عمل مكافحة الإساءة بعد استئناف. الخط الفاصل بين التحقق من الوصول وقياس المعالجة لم يُرسم سهوًا، لكن كلفة التشغيل كانت عاملًا حاسمًا في إزالة الاقتراح.

الحالة المستقرة كما عُرضت في 2023

عرض مسؤولو NCC في RIPE 87 أرقامًا سنوية: نحو 19.6 ألف جهة اتصال في كائنات مؤسسات LIR، و58.1 ألفًا في كائنات موارد LIR، و15.4 ألفًا في كائنات الموارد المستقلة. يُفحص نحو 2,000 جهة اتصال أسبوعيًا، بمعدل فشل متكرر بين 6% و8%. يُستبدل abuse-c الباطل في كائنات الموارد بعنوان عامل لعضو LIR، بينما يؤدي العنوان الباطل في كائن LIR إلى تحقيق موسّع، وقد ينتهي الأمر بإنهاء عضوية عضو لا يستجيب. وفي تنظيف لسجلات ASN جرى الاتصال بأكثر من 4,000 من حاملي هذه الأرقام، فعاد نحو 2,150 (54%).

ولا تظهر في المصادر العامة المراجعة حالة موثّقة واحدة استُخدم فيها إنهاء العضوية فعليًا، ولا توزيع لمراحل الإخفاق (تنسيق مقابل DNS مقابل ping)؛ فالإنفاذ معروف نصًّا، واستخدامه العملي غير موثّق.

ماذا تقيس الأبحاث المستقلة بعد إرسال التقرير

أرسلت تجربة عشوائية محكمة 480 تقرير إساءة إلى مزودي استضافة وأصحاب مواقع، فوردت 89 رسالة، 11 منها فقط (12%) من إنسان بوضوح، و78 (88%) ردود آلية. والأهم أن بعض الجهات لم تردّ ومع ذلك عالجت المشكلة؛ فتخلّف الرد لا يعني تخلّف المعالجة، كما ترفع التقارير المفصلة معدلات المعالجة (الدراسة).

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

وتشرح الأسئلة الشائعة لـ CSIRT.CZ كيف يُستدل عبر قواعد بيانات السجلات الإقليمية على الجهة المسؤولة عن عنوان IP، وتذكر أن جهة الاتصال المسجلة هي قناة الإبلاغ عن الحوادث، وتنصح بعدم التصعيد إلى CSIRT.CZ إلا إذا لم يصل رد معقول خلال أيام.

الحدّ الذي يبقى مفتوحًا

يبقى سؤال واحد دون جواب مؤسسي: من يقيس ما يحدث بعد أن تصل رسالة الإساءة؟ يقيس السجل قابلية التسليم؛ وترصد دراسات أكاديمية معدلات الاستجابة لدى مزودي الاستضافة وبعض أدوات DNS، دون أن تنشئ مقاييس للمعالجة داخل منطقة RIPE. وتُظهر الوثائق المتاحة أن إعادة التحقق الدوري كانت مكلفة، وأن تحديد نطاق السياسة كان خيارًا واعيًا. ويظل ملف الأداة متاحًا في دليل BTW.