الشيفرة المصدرية: github.com/Alex0176/odoo-web-rbl — AGPL-3، قابلة للاستخدام بحرية.
من يشغّل خادم Odoo على الإنترنت يتلقى زيارات. ليس من حين لآخر، بل دون انقطاع. على مدى سبعة عشر يومًا سجّلنا على مواقعنا الخمسة 731.297 طلبًا وحلّلناها. 110.511 منها لم تكن زوارًا، بل بحثًا آليًا عن الثغرات وبيانات الدخول وملفات الإعداد.
يصف هذا المقال Web RBL، وهي وحدة مفتوحة المصدر لـ Odoo 19 Community تكتشف هذه الحركة وتقيّمها وتسجّلها وترفضها — وتنشر قائمة الحظر بصيغة قائمة RBL، أي بالصيغة التي تقرأها جدران الحماية والوكلاء العكسيون مباشرةً. وجميع الأرقام مأخوذة من التشغيل الفعلي.
ما الذي تستطيعه الوحدة — الوظائف في لمحة
| الوظيفة | ما تفعله | الوضع عند التسليم |
|---|---|---|
| اكتشاف الأنماط | تكتشف عمليات الاستكشاف من خلال المسار واللاحقة: .env و.git وملفات الإعداد ومفاتيح السحابة وتعليمات البناء في CI/CD وWordPress وPHP وPath Traversal ومديري قواعد البيانات وGraphQL وتنفيذ الأوامر عبر /api/fs/exec وواجهات مماثلة | حظر |
| ثلاثة مستويات لكل نمط | حظر أو عدّ أو إبلاغ — قابلة للتبديل لكل نمط، دون شيفرة | لكل نمط |
| العتبات | عدد مرات تطابق النمط نفسه قبل الحظر؛ وفي تسجيل الدخول عشر مرات | 10 عند تسجيل الدخول |
| صدّ محاولات تسجيل الدخول | محاولات تسجيل دخول فاشلة عبر النموذج وعبر XML-RPC/JSON-RPC، وفحوص جلسات فاشلة، ووصول إلى مدير قواعد البيانات — في قاعدة البيانات وليس في الذاكرة العاملة | مفعّل |
| اكتشاف الروبوتات عند تسجيل الدخول | من يتجاهل رسالة الانتظار بعد عشر محاولات فاشلة ويواصل الطرق يُحظر فورًا | حظر |
| اكتشاف السلوك | عناوين تولّد في خمس دقائق عشرين صفحة خطأ وتكاد لا تولّد صفحة صحيحة — أي تخمّن بدلاً من أن تقرأ | إبلاغ |
| تقييم 0–100 | ما مدى اليقين بأن مهاجمًا يقف وراء العنوان؟ يُحسب من شدة النمط وعدد الأنماط المختلفة والأيام اللافتة والنطاقات المتأثرة وعدد الإصابات — مع تعليل بنص واضح | مفعّل |
| حظر تسجيل الدخول حسب التقييم | ابتداءً من تقييم قابل للضبط يُمنع تسجيل الدخول، ويبقى الموقع قابلًا للقراءة | ابتداءً من 40 |
| اشتباه في بيانات دخول مسروقة | يتم الإبلاغ عن عملية تسجيل دخول ناجحة من عنوان مشبوه، وإسنادها عند الرغبة كمهمة — مرة واحدة لكل عنوان في اليوم | مفعّل |
| قوائم التهديدات | عُقد خروج Tor وSpamhaus DROP وFireHOL Level 1 وblocklist.de مُهيَّأة مسبقًا؛ ويمكن إدخال أي قائمة RBL أخرى عبر عنوانها، مع مطابقة يومية ومستوى مستقل لكل قائمة | إبلاغ |
| منع الوصول إلى تسجيل الدخول | المستوى الرابع للقوائم والدول: الموقع قابل للقراءة، بينما نموذج تسجيل الدخول والواجهات البرمجية مغلقة — الرد المناسب على Tor | خيار |
| بلد المنشأ | البلد لكل مطابقة ولكل عنوان عبر GeoLite2؛ وتتولى الوحدة تحديث قاعدة البيانات بنفسها بمفتاح ترخيص مجاني | عرض |
| قواعد الدول | حظر، أو منع الوصول إلى تسجيل الدخول، أو إبلاغ، أو سماح صريح — لكل دولة على حدة، ودون قيمة افتراضية عن قصد | لا شيء |
| الإعدادات الخاطئة | يتم التعرّف على QNAP وSynology وExchange Autodiscover وActiveSync وWebDAV/CalDAV/CardDAV، ولا يُحظر أي منها أبدًا، وتُدرج في قائمة عمل مع نتيجة الفحص والنطاق المتأثر | إبلاغ |
| تذكرة لكل عنوان | تتحول نتيجة الفحص إلى تذكرة عند الرغبة — تذكرة واحدة بالضبط لكل عنوان، وتُعاد فتح التذكرة المغلقة بدلًا من إنشاء أخرى مكررة | إيقاف |
| الصفحات الإلزامية والمُجمِّعات | يبقى مسار صفحة بيانات الناشر (Impressum) المعتمد متاحًا دائمًا؛ ويتم رصد التجريب الآلي لصيغ الكتابة الأخرى، ويُحظر عند الرغبة | إبلاغ |
| قائمة السماح | عناوين وشبكات لا تُحظر أبدًا؛ تمتلئ يوميًا من جدار الحماية (أطراف VPN المقابلة) ومن نطاقات العناوين المنشورة لـ Googlebot وBingbot | مفعّل |
| ربط العملاء | تُنسب المطابقة الصادرة من شبكة أحد العملاء إليه — انطلاقًا من قائمة السماح، لا بالتخمين اليدوي أبدًا | مفعّل |
| النطاق والمعرّف لكل مطابقة | أي موقع جرى الوصول إليه، وبأي User-Agent — وكلاهما غير موجود في سجل الوصول | مفعّل |
| التحليل | مخطط وجدول محوري لجميع المطابقات: حسب النمط واليوم والنطاق والدولة والعنوان | مفعّل |
| الطُّعم | تتلقى المسابير ردودًا مُختلَقة بقيمة كناري؛ ومن يطلبها لاحقًا يكون قد قرأها | إيقاف |
| توزيع RBL | قائمة الحظر كقائمة عناوين بسيطة أو بصيغة JSON على عنوان خاص محمي برمز Token — لـ HAProxy وOPNsense وأي جدار حماية يقرأ قوائم URL | مفعّل |
كل ما يُسلَّم بوضع إبلاغ أو إيقاف أو خيار فهو كذلك عن قصد: من يُفعّل حظرًا فعليًا ينبغي أن يفعل ذلك لأنه راقب النظام بضعة أيام، ولأنه يعرف من يقع في القائمة — لا لأن الإعداد الافتراضي أراد ذلك.
التحليل: المطابقات لكل نمط خلال سبعة أيام. أعلى عمود هو البحث عن ملفات .env.
قوائم RBL: طريقة قياسية لتوزيع قوائم الحظر
تعني RBL اختصار Real-time Blackhole List. والمصطلح مأخوذ من عالم البريد الإلكتروني، حيث تنشر Spamhaus وجهات أخرى منذ التسعينيات قوائم بعناوين المرسلين الضارين. والمبدأ بسيط للغاية، ولهذا السبب بالذات واسع الانتشار: عنوان واحد في كل سطر، يمكن جلبه عبر HTTP، ويُعاد تحميله بانتظام. لا صيغة تحتاج إلى تحليل أولًا، ولا واجهة برمجية تتطلب أداة خاصة.
يستطيع عمليًا كل جدار حماية وكل وكيل عكسي (Reverse Proxy) قراءة قائمة كهذه وبناء قواعد منها. تسمي الشركات المصنِّعة ذلك بأسماء مختلفة، لكن الآلية واحدة في كل مكان:
- OPNsense وpfSense — URL Table Alias: تحميل قائمة العناوين عبر HTTP، واستخدامها كاسم مستعار (Alias) في قواعد جدار الحماية، مع تحديث كل ساعات أو يوميًا
- HAProxy — ملفات ACL وMaps:
src -f sperrliste.txtفي قاعدةhttp-request deny، ويمكن إعادة تحميلها عبر واجهة وقت التشغيل دون إعادة تشغيل - nginx — وحدة geo مع ملف عناوين مُضمَّن، أو تعليمات
denyمن ملفincludeمُولَّد - Fortinet FortiGate — External Block List أو Threat Feed: عنوان URL واحد يجلب منه جدار الحماية قائمة IP ويستخدمها في السياسات
- Palo Alto Networks — External Dynamic List (EDL): المبدأ نفسه، كنوع كائن مستقل في سياسات الأمان
- Check Point — Custom Intelligence Feeds وIP Block Lists عبر عنوان URL
- Cisco Secure Firewall (Firepower) — Security Intelligence Feeds بمصادر قوائم خاصة
- Sophos Firewall — Third-Party Threat Feeds: قوائم عناوين من عنوان URL كمصدر لقواعد الحظر
- Juniper SRX — Dynamic Address Entries من الخلاصات (Feeds)
- MikroTik RouterOS — Address Lists، تُملأ عبر سكربت و
fetchمن عنوان URL - CrowdSec — قوائم خاصة كمصدر للـ Bouncer على كل نظام مدعوم
بهذه الصيغة بالذات توزّع Web RBL قائمة الحظر الخاصة بها. فيُسقط جدار الحماية الحزم قبل وصولها إلى خادم الويب — ومعها كل محاولة أخرى من العنوان نفسه، مثلًا نحو خادم البريد أو بوابة VPN.
في الاتجاهين، لكن في المكان الصحيح
الطريق يعمل بالاتجاه المعاكس أيضًا: في Web RBL يمكن إدخال أي قائمة RBL — عنوان URL ومستوى، وينتهي الأمر. عُقد خروج Tor وSpamhaus DROP وFireHOL وblocklist.de مُهيَّأة مسبقًا، وتُضاف قوائم أخرى بثلاث نقرات. تقسّم الوحدة كل قائمة إلى نطاقات عناوين وتطابق كل طلب معها خلال بضع ميكروثوانٍ.
ومع ذلك: الأجدى استخدام القوائم الخارجية على جدار الحماية الذي يسبق الخادم. لثلاثة أسباب. فجدار الحماية يرى جميع الخدمات لا HTTP فقط — والعنوان الموجود في قائمة Spamhaus ينبغي أن يُحجب أيضًا عن خادم البريد وعن VPN. كما أنه يُسقط الحزم على مستوى الحزمة قبل قيام أي اتصال أصلًا، فلا يكلّف خادم التطبيقات شيئًا. وهو المكان الذي تُدار فيه مثل هذه القوائم أصلًا؛ والنسخة الثانية داخل التطبيق هي موضع ثانٍ قد تتقادم فيه.
فما فائدة القوائم داخل الوحدة إذن؟ لما لا يستطيعه جدار الحماية. فهو لا يعرف نموذج تسجيل الدخول. أما Web RBL فيستطيع أن يمنع عنوانًا من قائمة Tor من الوصول إلى تسجيل الدخول مع الاستمرار في تقديم الموقع — فمن أراد القراءة بصورة مجهولة يحق له ذلك؛ ومن أراد تجريب كلمات المرور بصورة مجهولة فلا. كما يستطيع الإبلاغ عن تسجيل دخول ناجح من عنوان مُدرج في قائمة بوصفه حالة اشتباه. وكلا الأمرين يحتاج القائمة في المكان الذي يجري فيه تسجيل الدخول.
التقييم بدل الحدس
العنوان الذي سأل مرة واحدة عن /wp-login.php يختلف عن عنوان تحرّك في يومين بخمسة أنماط مختلفة عبر ثلاثة نطاقات. يحوّل Web RBL ذلك إلى درجة تقييم من 0 إلى 100 — مما رآه بنفسه، دون خدمة خارجية ودون أي استعلام نحو الخارج.
مُدخل واحد: 99 مطابقة، ودرجة تقييم 84، والتعليل بنص واضح — أشد نمط خطورة، وخمسة أنماط جدّية مختلفة، ويومان مشبوهان، وأكثر من عشرين مطابقة.
تحدد درجة التقييم أمرين. فابتداءً من قيمة قابلة للضبط يصبح تسجيل الدخول ممنوعًا — يبقى الموقع قابلًا للقراءة، لكن من بحث أصلًا عن بيانات الدخول لا تُتاح له فرصة تجريب ما وجده. وتسجيل الدخول الناجح من عنوان ذي درجة تقييم يُبلَّغ عنه: فعندها لم يعد أحدهم يخمّن، بل كان يعرف. إما أن يكون المستخدم المخوَّل في سفر، أو أن بيانات الدخول قد ضاعت — والوحدة لا تحسم ذلك، بل تعرضه على من يستطيع الاستفسار. أما كلمة المرور نفسها فلا تُمَسّ في أي موضع.
قائمة الحظر، مرشّحة بدرجة تقييم 40 فأكثر: عدد المطابقات، والأيام المشبوهة، والنطاقات المتأثرة، وآخر مسار لكل عنوان.
ما الذي يحميه Web RBL — الحماية بالتفصيل
1. بيانات الدخول تبقى غير مكتشفة
أكبر فئة هجمات جرى قياسها لا تبحث عن ثغرات في Odoo، بل عن أسرار تُركت في غير موضعها. على مدى سبعة عشر يومًا:
- 57.721 طلبًا على ملفات
.env— وفيها كلمات مرور قواعد البيانات ومفاتيح API وأسرار الجلسات - 5.535 طلبًا على ملفات الإعدادات
- 4.388 طلبًا على بيانات الدخول إلى السحابة:
credentials.jsonوservice-account.jsonوfirebase-adminsdk.jsonوrclone.confو.git-credentials - 2.811 طلبًا على مجلدات
.git— ومن يعثر على أحدها يحمّل الشيفرة المصدرية كاملة مع سجل التغييرات - 1.907 طلبًا على تعليمات البناء مثل
.github/workflows/deploy.ymlأو.gitlab-ci.yml، وفيها أسماء السجلات (Registries) وأسماء المفاتيح
والحاسم هنا ليس عدد الطلبات، بل عدد العناوين المختلفة: فقد ورد /credentials.json من 98 عنوانًا، و/.git-credentials من 92. وهذا ليس ماسحًا منفردًا، بل مجموعة قياسية تعمل في العالم كله في وقت واحد.
2. محاولات تسجيل الدخول تذهب هباءً — بصورة دائمة
يتضمن Odoo آلية كبح خاصة به ضد تجريب كلمات المرور. ولها ثلاثة حدود موثقة في الشيفرة المصدرية لـ Odoo نفسه: العدّاد موجود في الذاكرة العاملة للعملية ويُصفَّر عند كل إعادة تشغيل، وهو يؤخّر فقط بدل أن يحظر، ولا يحسب إلا المحاولات التي تصل إلى مرحلة التحقق من كلمة المرور.
يتدخل Web RBL في المواضع نفسها، لكنه يكتب في قاعدة البيانات. وبذلك يصبح:
- الحالة تنجو من كل إعادة تشغيل وتسري عبر جميع العمليات العاملة
- يُرصد الطريقان معًا: نموذج تسجيل الدخول
/web/loginوالواجهات/xmlrpc/2/commonو/jsonrpc - وتُرصد أيضًا المحاولات التي لا تصل أبدًا إلى التحقق من كلمة المرور — مثل تسجيلات الدخول دون معرّف جلسة صالح
- ويُحتسب أي وصول فاشل إلى مدير قواعد البيانات؛ وهو أخطر محاولة تسجيل دخول على الإطلاق
حُدّد حد تسجيلات الدخول بعشرة، والسبب قياس: من بين تسعة تسجيلات دخول فاشلة خلال سبعة عشر يومًا كانت الغالبية من عملاء أعدّوا الوصول بأنفسهم على جهاز آخر وأدخلوا النطاق الخاطئ — وفي إحدى الحالات نطاقهم هم، لكن بشرطة بدل النقطة. فالحظر عند أول محاولة فاشلة كان سيصيب لا المهاجمين، بل العملاء أثناء الإعداد.
أما من يواصل الطرق رغم أن الخادم ردّ عليه بـ «يُرجى الانتظار قليلًا» فيُحظر فورًا. فهذه الرسالة يقرؤها إنسان وينتظر؛ ومن يتجاهلها فهو برنامج. نمط خاص بحد صفري يلتقط هذه الحالة بالذات، ولا يمكنه أن يصيب زميلًا: فلا يصل إليه إلا من تجاوز عشر محاولات فاشلة ثم واصل بعدها.
3. الهجوم لم يعد يكلّف الخادم شيئًا
كان المسبار على مسار مثل /@fs/../../.env مكلفًا قبل الوحدة: يبحث Odoo عن صفحة الخطأ ويعرضها، ويتعثر عند بناء العنوان بسبب مقاطع النقاط، ثم يفشل بالتالي حتى في صفحة الخطأ الخاصة بصفحة الخطأ. سجلّا تتبّع (Stack Trace) لكل مسبار. وقد قيس 28.401 خطأ من هذا النوع خلال سبعة عشر يومًا، إضافة إلى 9.467 خطأً تابعًا.
يتدخل Web RBL في ir.http._match، أي قبل تحديد المسار. ويأتي الرد دون قالب، ودون وصول إلى قاعدة البيانات يتجاوز فحص الحظر، ودون سطر في السجل. والفحص مقابل قائمة السماح وقوائم التهديدات وقواعد الدول يجري من الذاكرة المؤقتة عبر نطاقات عناوين مرتبة — بضع ميكروثوانٍ، حتى مع أكثر من ثلاثين ألف نطاق.
4. جدار الحماية يطرد المهاجم قبل أن يصل
تُنشر قائمة الحظر كقائمة RBL تقرؤها HAProxy وOPNsense مباشرة. وبذلك لا يصل المهاجم إلى خادم الويب أصلًا — ولا إلى أي خدمة أخرى على المضيف نفسه. فالوصول الذي رُصد مرة على أنه ضار يحمي الجهاز بأكمله بأثر رجعي.
ثلاثة مستويات: حظر وعدّ وإبلاغ
ليس كل طلب يذهب هباءً هجومًا. ولهذا يميّز Web RBL بين ثلاثة مستويات، ويمكن تبديل المستوى لكل نمط دون المساس بالشيفرة.
| المستوى | الطلب المُحفِّز | النتيجة بالنسبة للعنوان |
|---|---|---|
| حظر | يُرفض | محظور 24 ساعة، وبصورة دائمة بعد ثلاثة أيام مشبوهة |
| عدّ | يمرّ | يُسجَّل فقط، دون حظر |
| إبلاغ | يمرّ | يُسجَّل مع نص نتيجة الفحص، ولا يُحظر أبدًا |
وللقوائم التهديدية والدول مستوى رابع: منع الوصول إلى تسجيل الدخول. يبقى الموقع قابلًا للقراءة، بينما يُغلق نموذج تسجيل الدخول والواجهات البرمجية. وهذا هو الحل الوسط لكل ما هو مشبوه دون أن يكون بالضرورة ضارًا — Tor، أو نطاق مركز بيانات، أو بلد لا عملاء لنا فيه.
ما الهجمات التي يتم رصدها
جميع الأنماط مختبرة مقابل حركة مرور حقيقية. وعدد العناوين المختلفة مذكور بجانبها عن قصد — فهو يبيّن هل يصيب النمط ماسحًا منفردًا أم أسلوبًا واسع الانتشار.
| فئة الهجوم | الطلبات | العناوين |
|---|---|---|
سحب ملفات .env | 57.721 | 223 |
| مسابير PHP | 12.237 | 256 |
| اجتياز المسارات (Path Traversal) نحو هدف مُجزٍ | 10.046 | 64 |
| ملفات الإعدادات | 5.535 | 114 |
| مفاتيح الدخول إلى السحابة | 4.388 | 152 |
| مسابير WordPress | 3.366 | 385 |
سحب .git | 2.811 | 255 |
| استكشاف Odoo (مدير قواعد البيانات، الاستعلام عن الإصدار) | 2.500 | 213 |
سلاسل أدوات الذكاء الاصطناعي وتنفيذ الأوامر (/mcp و/api/fs/exec) | 2.450 | 74 |
| تعليمات البناء (CI/CD) | 1.907 | 88 |
| نقاط نهاية GraphQL | 1.878 | 71 |
والفئة الأحدث لافتة للنظر. فقد طُلب /api/fs/exec 369 مرة من 54 عنوانًا مختلفًا — وهذا ليس وصولًا للقراءة، بل محاولة لتنفيذ أوامر. لم تكن مثل هذه الأهداف موجودة قبل عامين؛ فهي ناتجة عن واجهات أدوات الذكاء الاصطناعي الجديدة وطوابير المهام. ومن يوجّه دفاعه نحو WordPress وPHP فقط لا يرى شيئًا من ذلك. ولذلك تُثقل هذه الفئة التقييم بدرجة كبيرة.
قوائم التهديدات وبلد المنشأ
أربع قوائم، و32.851 نطاق عناوين، كلها على «إبلاغ فقط». وكل قائمة إضافية هي عنوان ومستوى.
القائمة الخارجية ادعاء يطرحه شخص آخر، لأسباب لا نعرفها، عن حركة مرور لم نرَها قط. وقد تكون خاطئة أو قديمة أو مخصصة لغرض آخر: فـ blocklist.de تجمع في الأساس عناوين جرّبت في مواضع أخرى تسجيلات دخول SSH، وهذا يقول القليل عن خادم ويب. ولهذا يحتفظ Web RBL بالقوائم الخارجية منفصلة عن قائمة الحظر الخاصة به، ولهذا أيضًا فالإعداد الافتراضي هو إبلاغ. وقائمة السماح الخاصة بنا تتغلب دائمًا: فعميل نعرفه أثقل وزنًا من تقدير طرف ثالث.
يظهر بلد المنشأ في كل مطابقة وكل عنوان. وهو لا غنى عنه للتقييم — فمحاولة تسجيل دخول من بلدنا نفسه في العاشرة صباحًا تختلف عن محاولة من بلد لا يوجد فيه عميل واحد. أما للحظر الشامل فهو قليل الجدوى، وهذا ما تقوله أرقامنا: فالمهاجمون في قائمتنا جاؤوا في معظمهم من نطاقات سحابية في بلجيكا وفنلندا وهولندا. وحظر كل ما هو خارج الدول الناطقة بالألمانية لم يكن ليصيبهم — بل كان سيصيب موظفينا في إجازاتهم وعملاءنا في رحلات العمل.
تُسلَّم قواعد الدول فارغة، وتوضح الواجهة السبب.
الإبلاغ عن الإعدادات الخاطئة بدل الحظر
الحالة الأكثر تكرارًا في حركة المرور الفعلية ليست هجومًا ولا زائرًا، بل برنامج معطوب يحسب خادم الويب شيئًا آخر:
- 1.367 استدعاءً لواجهة الويب الخاصة بجهاز NAS من QNAP — عميل مزامنة لم يعد هدفه صحيحًا. وقد طرق منفذ واحد الباب 962 مرة.
- 65 استعلام Autodiscover — برنامج Outlook يحسب نطاق الويب خادم Exchange الخاص به
مثل هذه العناوين لا تُحظر أبدًا. فالحظر لا يعالج العطل بل يخفيه — ويصيب صاحب الجهاز المضبوط خطأً أصلًا. وبدلًا من ذلك يُنشأ مُدخل بنص نتيجة الفحص والنطاقات المتأثرة، يتحول منه عند الرغبة تلقائيًا إلى تذكرة: تذكرة واحدة بالضبط لكل عنوان، وإذا أُغلقت وظهر العنوان مجددًا أُعيد فتح التذكرة نفسها بدل إنشاء تذكرة ثانية.
يتم التعرّف على QNAP وSynology وExchange Autodiscover وActiveSync وكذلك عملاء WebDAV وCalDAV وCardDAV. وتذكر الأنماط أسماء ملفات ومجلدات محددة بدقة، لا مجرد امتدادات: ففي المجلد نفسه /cgi-bin/ تقع استدعاءات المزامنة غير الضارة بجوار مسابير كلاسيكية مثل printenv.pl.
قائمة السماح: عناوين لا تُحظر أبدًا
ثمن الخطأ ليس واحدًا لجميع العناوين. فمع ماسح من مركز بيانات لا يكلّف الإنذار الخاطئ شيئًا. أما مع الطرف المقابل لنفق موقع، فإنه يكلّف الموقع كله.
لذلك توجد قائمة ثانية تسبق الأولى: عناوين وشبكات لا تُحظر أبدًا. وهي لا تُسكت شيئًا — فمن يرد فيها يظل يُفحص ويُسجَّل، وتسقط النتيجة فقط. وهذا هو الفرق عن الاستثناء في جدار الحماية: فهو يُعمي، أما هذه فتجعل النظام صبورًا فحسب.
تمتلئ يوميًا من مصدرين: من جدار الحماية نفسه بجميع أطراف VPN المقابلة، كي لا يعتمد النفق المُنشأ حديثًا على أن يتذكر أحدهم قائمة الحظر — ومن نطاقات العناوين المنشورة لدى Google وMicrosoft لبرامج الزحف الخاصة بهما. وبهذا وحده يمكن التمييز بين Googlebot حقيقي وماسح ينتحل هذا الاسم. ويجب ألا تُحظر محركات البحث أبدًا؛ فمن يحجبها يُخرج موقعه من الفهرسة دون طريق للعودة.
وهنا تسري قاعدة أهم من المطابقة نفسها: الرد الفارغ لا يحذف أبدًا. فإذا لم يردّ المصدر، أو ردّ فارغًا أو بما لا يُفهم، بقيت القائمة دون تغيير. فقائمة سماح تُفرغ نفسها عند حدوث عطل تأخذ معها جميع الأنفاق في أسوأ لحظة يمكن تخيّلها.
وإذا كان مُدخل في قائمة السماح مرتبطًا بعميل، فإن كل مطابقة من شبكته تُنسب إليه. وبذلك يصبح للإعداد الخاطئ جهة اتصال فورًا، دون أن يضطر أحد إلى البحث عن العناوين.
البيانات الإلزامية وجامعو البيانات الآليون
صفحة بيانات الناشر (Impressum) ليست صفحة عادية. يجب أن تبقى متاحة للبشر، فالحظر عليها يصنع بالضبط المخالفة التي يبحث عنها الجامع. وهي في الوقت نفسه الصفحة التي يرد فيها الاسم والعنوان — ومن ثم هدف الحصاد الآلي.
في موجة الإنذارات القانونية في النمسا بسبب تضمين خطوط Google، أظهرت السجلات أن الرسائل لم تنشأ من زيارات فردية، بل من حملة آلية شاملة: مضيفون مختلفون لا صلة بينهم، بفارق أجزاء من الثانية.
يحل Web RBL ذلك عبر التخفيض بدل الاستثناء. فالمسار المعتمد /impressum لا يطابق أي نمط ويبقى متاحًا دائمًا. أما صيغ الكتابة الأخرى مثل /impressum.php — التي لا يمكن أن توجد على موقع Odoo — فيُبلَّغ عنها، ومن لا يريد قبول الحصاد الآلي يغيّر معاملًا واحدًا. أما sitemap وrobots فهما مستثنيان من ذلك وغير قابلين للحظر من حيث المبدأ: فلا بيانات شخصية فيهما، وجلبهما هو مهمة كل زاحف لمحركات البحث.
النطاق والمعرّف: ما ينقص سجل الوصول
لا يسجّل سجل الوصول في werkzeug المضيف المطلوب ولا معرّف المُستدعي. وOdoo يحصل على كليهما بطبيعة الحال — فبدون المضيف لما استطاع اختيار الموقع الصحيح مع تعدد المواقع. لكن لا يمكن الرجوع إليهما لاحقًا.
يحتفظ Web RBL بكليهما لكل مطابقة. وهذا يجيب عن سؤالين لا يمكن الإجابة عنهما بغير ذلك: أي موقع يخاطبه إعداد خاطئ — ومن ثم لأي عميل يعود النطاق — وهل يزور العنوان صفحة واحدة أم جميع الصفحات. فتعدد النطاقات غير المترابطة لدى العنوان نفسه هو علامة الحملة الشاملة، وهو يرفع التقييم.
أما حجم أهمية المعرّف فقد أظهره تحليل على أحد مواقعنا: فقد عُزي أكثر من سبعين بالمئة من حركة المرور الكلية هناك إلى مُستدعٍ واحد، موزعة على أكثر من مئة عنوان. ودون المعرّف كان ذلك سيبدو كأنه ماسح موزَّع. لكنه كان GPTBot، زاحف OpenAI — كان يسأل مرارًا عن robots.txt ويتصرف بصورة صحيحة تمامًا.
الجوانب الأمنية بالتفصيل
1. رصد الوكيل — أخطر موضع على الإطلاق
إذا كان Odoo يعمل خلف وكيل عكسي (Reverse Proxy) وكان proxy_mode مضبوطًا خطأً، فإن الوحدة ترى العنوان نفسه في كل طلب: عنوان الوكيل. وعندها سيؤدي الحظر إلى حجب جميع الزوار في وقت واحد.
لذلك يتحقق Web RBL قبل كل حظر مما إذا كان تحديد العنوان موثوقًا. فهو يشترط proxy_mode مع ترويسة إعادة التوجيه، ويمتنع عن العمل إذا وصل توجيه دون proxy_mode، ويمتنع كذلك عند وجود أكثر من وكيل وسيط واحد. وعند الشك لا يُحظر شيء.
2. الشبكات الخاصة بنا لا تُحظر أبدًا
نطاقات العناوين الخاصة وLoopback وLink-Local وCGNAT مستثناة بصورة ثابتة. ولا يمكن أن تصل إلى القائمة بأي حال، ولا حتى يدويًا. والأمر نفسه ينطبق على القوائم الخارجية: تُهمَل عند القراءة النطاقات الخاصة والمحجوزة والشبكات الضخمة على نحو غير معقول.
3. لا يجوز لخطأ ذاتي أن يُسقط الموقع معه
يجري الفحص كله داخل غلاف حماية يلتقط كل خطأ. وما يفشل هنا يُسجَّل، ويستمر الطلب دون تغيير. إن وحدة حماية تُسقط الموقع عند وقوع خطأ في ذاتها لهي أسوأ من انعدام الحماية. كما تجري جميع الاستعلامات في مسار الطلب دون لغة متصفح الزائر ودون ترتيب حسب الحقول المترجمة — فلا يجوز لزائر بلغة غير مثبّتة أن يُفشل الفحص.
4. المراقبة قبل الحظر
بعد التثبيت يكون حظر العناوين المُدرجة في القوائم معطّلًا مع الطلبات العادية. تُرفض المسابير وتُسجَّل، وكل ما عداها يمرّ. وبذلك يمكن مراقبة من يقع فعلًا في القائمة بضعة أيام قبل أن يُحجب أحد. والأمر نفسه ينطبق على رصد السلوك وقوائم التهديدات وقواعد الدول: الإبلاغ أولًا، والحظر بعد التمعّن.
5. أنماط ضيقة بدل شبكات واسعة
الزائر المُشخَّص خطأً أغلى ثمنًا من مسبار فات رصده. ولذلك يحمل كل نمط مستواه الخاص، ويمكن تبديله لكل نمط. وامتداد الملف وحده نادرًا ما يكفي: ففي .php تقف 14.012 مسبارًا حقيقيًا مقابل حفنة من الروابط القديمة، وفي .asp تنعكس النسبة. مثل هذه القرارات ينبغي أن تُقاس لا أن تُخمَّن.
6. السماح اليدوي لعنوان يبقى قائمًا
من سمح لعنوان ما كان لديه سبب. ومطابقة أخرى لا تُبطل هذا القرار بصمت.
7. القائمة محمية لكنها ليست سرًا
تشترط نقطة النهاية رمز Token، وترد بدونه برمز 404 لا 403 — فلا يتأكد بذلك وجود العنوان أصلًا. والمقارنة تجري بزمن ثابت. والقائمة نفسها لا تحتوي على شيء سري: فهي مؤلفة من عناوين طرقت بابنا من تلقاء نفسها.
8. لا أسرار في السجلات
عند فشل تسجيلات الدخول يُدوَّن اسم المستخدم المُجرَّب، ولا تُدوَّن كلمة المرور أبدًا. وفي مدير قواعد البيانات لا يُقرأ أي شيء من القيم المُمرَّرة: فهناك تأتي كلمة المرور الرئيسية في المقدمة، ومُدخل في قائمة حظر ينتقل إلى كل نسخة احتياطية لقاعدة البيانات. ومفتاح ترخيص GeoLite2 موجود في معامل النظام فقط ولا يظهر في أي سطر من السجل.
9. الطُّعم لا يكشف شيئًا قابلًا للاستغلال
يرد Web RBL اختياريًا على المسابير بمحتوى مُختلَق يتضمن قيمة كناري فريدة. ومن يطلب هذه القيمة لاحقًا يكون قد قرأ الرد المزيّف وتصرّف بناءً عليه — فالإنذار الخاطئ هنا مستبعد. ولا تحتوي الطُّعوم على أي بيانات قابلة للاستغلال ولا مسارات حقيقية ولا بيانات دخول صالحة. تُسلَّم هذه الوظيفة معطّلة، لأنها تغيّر السلوك بصورة ظاهرة للخارج.
ما لا تستطيعه الوحدة
هي لا تحل محل جدار الحماية ولا محل جدار حماية تطبيقات الويب (WAF). فهي تتعرف على أنماط الاستكشاف المعروفة في المسارات، وعلى تسجيلات الدخول الفاشلة، والسلوك المريب — لا على الهجمات على النماذج، ولا على محاولات الحقن في المعاملات.
كما أنها ترى فقط ما يعود عبر HTTP. أما ما يفعله مهاجم بما استولى عليه من بيانات الوصول إلى قواعد البيانات أو صناديق البريد فيبقى غير مرئي — ولهذا بالذات تكون قيم الكناري مسارات لا بيانات دخول.
ولا تحل محل الحرص: فوحدة ترفض مسابير .env لا تجعل ملف .env المُسلَّم عن غير قصد غير خطير.
التوافر
يتوفر Web RBL علنًا بموجب ترخيص AGPL-3، ويعمل لدينا في بيئة الإنتاج على خمسة مواقع:
github.com/Alex0176/odoo-web-rbl
تتطلب الوحدة Odoo 19 Community ولا تعتمد على شيء سوى base وweb. والربط بنظام التذاكر اختياري ولا يتطلب نظام تذاكر بعينه؛ ودون نظام كهذا لا يحدث شيء ببساطة. أما بلد المنشأ فيحتاج قاعدة بيانات GeoLite2 المجانية من MaxMind؛ وإن لم تتوفر بقي الحقل فارغًا وعمل كل شيء آخر دون تغيير.
للمزيد: كيف يندرج Web RBL في بنية أمنية متكاملة -- مع جدار الحماية والمصادقة الثنائية والصلاحيات، بما في ذلك دليل خطوة بخطوة: الجمع الصحيح بين عناصر بنية أمان Odoo 19.
يسعدنا تلقي الأسئلة والملاحظات وتقارير الأخطاء — ويفضَّل أن تكون على هيئة Issue في GitHub.