البنية الأمنية في Odoo 19: الجمع الصحيح بين جدار الحماية والمصادقة الثنائية والصلاحيات وWeb RBL

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

يوضح هذا المقال كيفية تأمين Odoo 19 على نحو صحيح — من خلال طبقات متعددة تتكامل فيما بينها بدل الاكتفاء بإجراء واحد: جدار الحماية والوكيل العكسي، ووحدتنا مفتوحة المصدر Web RBL، والمصادقة الثنائية، وسياسة كلمات المرور، والصلاحيات — مع توضيح محاولات الهجوم التي تتصدى لها كل طبقة فعليًا. وفي النهاية، يقدّم المقال دليلًا خطوة بخطوة لتطبيق هذه الإجراءات على أي تثبيت خاص لـ Odoo.

الدفاع في العمق: لماذا لا يكفي إجراء واحد أبدًا

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

نعتمد أربع طبقات، لكل منها مهمة مختلفة:

• جدار الحماية / الوكيل العكسي — يمنع ما يتضح أنه خبيث قبل أن يصل إلى الخادم أصلًا
• Web RBL — يربط بين الجانبين: يستخلص Odoo من سجل التطبيق معلومات لا يستطيع جدار الحماية رؤيتها، ثم يزوّده بها
• Odoo نفسه — المصادقة الثنائية، وسياسة كلمات المرور، والصلاحيات، وإدارة الجلسات
• قاعدة البيانات & التشغيل — النسخ الاحتياطي، وحماية الوصول إلى الإدارة، وإبقاء الأسرار خارج جميع السجلات

تتناول الأقسام التالية كل طبقة على حدة.

الطبقة 1: جدار الحماية والوكيل العكسي

جدار الحماية هو أول جهة ترى الطلب، والوحيدة التي تستطيع منع المهاجم من الوصول إلى كل خدمة على الخادم — بما في ذلك الموقع وخادم البريد ومنفذ VPN وواجهة الإدارة الخاصة بها. وتختلف الوظائف المناسبة للتفعيل بحسب الشركة المصنّعة، لكن الأشكال الأساسية واحدة لدى OPNsense وpfSense وHAProxy وFortiGate وSophos وCheck Point:

قوائم RBL: الطريقة القياسية لتوزيع بيانات السمعة

يرمز RBL إلى Real-time Blackhole List، وهو مصطلح نشأ في عالم البريد الإلكتروني: عنوان واحد في كل سطر، في قائمة متاحة عبر HTTP ويُعاد تحميلها بانتظام. ويستطيع كل جدار حماية تقريبًا قراءة قائمة كهذه وإنشاء قواعد منها — في OPNsense وpfSense بصيغة URL Table Alias، وفي HAProxy كملف ACL، وفي FortiGate بصيغة External Block List، وفي Palo Alto بصيغة External Dynamic List، بينما تستخدم Cisco وSophos وJuniper وMikroTik أسماء خاصة بها للمبدأ نفسه.

هنا تحديدًا يأتي دور وحدتنا — وهنا تبدأ الطبقة الثانية.

الطبقة 2: Web RBL — حلقة الوصل بين التطبيق وجدار الحماية

يرى جدار الحماية حزم البيانات، ولا يدرك منطق التطبيق. فهو لا يعرف أن طلب /xmlrpc/2/common هو محاولة تسجيل دخول، أو أن طلب عشرين مسارًا مختلفًا خلال أربع عشرة ثانية يدل على أداة فحص، أو أن عنوانًا نجح للتو في تخمين كلمة مرور. وحده Odoo يعرف كل ذلك. Web RBL، وحدتنا مفتوحة المصدر (AGPL-3)، تتيح الاستفادة من هذه المعرفة — داخل Odoo نفسه، وكذلك في جدار الحماية الذي يسبقه، عبر توفيرها في صورة قائمة RBL.

تُزامَن قوائم التهديدات باستمرار، ولكل منها مستوى خاص بها.

فيما يلي موجز لما شرحه المقال السابق بالتفصيل:

• التعرّف على الأنماط في المسارات: ملفات .env، ومجلدات .git، وملفات الإعداد، ومحاولات استطلاع WordPress وPHP، واجتياز المسارات، وتنفيذ الأوامر عبر واجهات الذكاء الاصطناعي الجديدة
• الحماية من هجمات تسجيل الدخول مع الاحتفاظ بعدّاد المحاولات عبر عمليات إعادة التشغيل — بخلاف عدّاد Odoo الداخلي الموجود في الذاكرة
• تقييم كل عنوان بدرجة من 0 إلى 100، مع توضيح الأسباب بلغة مفهومة
• تُكتشف أخطاء الإعداد (QNAP وAutodiscover وSynology) ولا يُطبَّق عليها الحظر أبدًا، لأن الحظر لا يصلح الخلل، بل يخفيه
• قوائم تهديدات خارجية مثل Spamhaus وFireHOL وعُقد خروج Tor، تُزامَن باستمرار
• قائمة سماح للعناوين التي يجب ألّا تُحظر أبدًا

تكتسب خاصيتان أهمية خاصة في هذا المقال، لارتباطهما المباشر بجدار الحماية وتسجيل الدخول.

القائمة المستقرة جديرة بالثقة

نادرًا ما تتغير قائمة السماح — أي العناوين التي لا تُحظر أبدًا، مثل عناوين ربط مواقعنا ببعضها. وهذا تحديدًا مصدر قيمتها، لا عيب فيها: فعندما تكاد القائمة لا تتغير على مدى أيام، يلفت أي تغيير نادر الانتباه فورًا. والتحديث التلقائي اليومي ليس موجودًا لكثرة التغييرات، بل لتجنب الاضطرار إلى إدخال التغيير النادر يدويًا — فهذه هي الخطوة التي تُنسى عادةً. وبهذه الطريقة تحديدًا اكتشفنا أحد أخطاء الإعداد لدينا الشهر الماضي: لم تكشفه أحداث كثيرة، بل حدث واحد لم يكن أحد يعرف عنه شيئًا، إلى أن حُظرت واجهة QNAP Web API لأحد العملاء بالخطأ. ومنذ ذلك الحين، أُدرج QNAP ضمن أخطاء الإعداد التي لا تُحظر أبدًا، بل يُبلَّغ عنها فقط.

تسجيل الدخول هو الموضع الذي لا يراه جدار الحماية

يستطيع جدار الحماية حظر عنوان. لكنه لا يستطيع معرفة ما إذا كان تسجيل الدخول قد نجح، فضلًا عن معرفة ما إذا كان قد جاء من عنوان كان يبحث قبل قليل عن بيانات دخول. أما Web RBL فيستطيع ذلك: فعند بلوغ التقييم عتبة قابلة للضبط، يُمنع تسجيل الدخول كليًا، ويُبلَّغ عن أي تسجيل دخول ناجح من عنوان مريب — وهذه هي حلقة الوصل مع الطبقة التالية.

الطبقة 3: تأمين Odoo نفسه

المصادقة الثنائية: سر ثانٍ لا يمكن إعادة استخدامه

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

يتضمن Odoo 19 Community هذه الميزة أصلًا — في صورة وحدة قابلة للتثبيت باسم Two-Factor Authentication (TOTP)، مع خيار احتياطي عبر البريد الإلكتروني. ويُعدّها كل مستخدم لنفسه باستخدام رمز QR وأي تطبيق مصادقة شائع:

الإعداد: امسح رمز QR، وأكّد الرمز المكوّن من ستة أرقام مرة واحدة، وانتهى الأمر.

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

سياسة كلمات المرور: وجود حد أدنى للطول ليس أمرًا مضمونًا

من دون وحدة إضافية، لا يفرض Odoo Community حدًا أدنى لطول كلمات المرور؛ إذ يمكن للمستخدم تعيين كلمة مرور من ثلاثة أحرف ما لم يمنعه أحد. وتسُدّ وحدة Password Policy المخصصة هذه الثغرة تحديدًا، بفرض حد أدنى للطول على الخادم، بدل الاكتفاء باقتراحه في المتصفح. أما من يريد مزيدًا من الضوابط، مثل فرض انتهاء صلاحية كلمات المرور أو الاحتفاظ بسجل يمنع إعادة استخدامها، فيحتاج إلى وحدة من OCA أو من جهة خارجية؛ فإصدار Community يُبقي هذه الوظائف محدودة عمدًا.

الصلاحيات: لا يُمنح الوصول إلا لمن يحتاج إليه

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

يقوم الجزء الأكبر من الحماية على مبدأين:

يمكن مراجعة الأمرين في الشاشة نفسها التي تُضبط فيها المصادقة الثنائية:

شاشة واحدة، وأربع أدوات للتحكم: كلمة المرور، وعامل المصادقة الثاني، ومفاتيح API، والأجهزة المسجّل دخولها.

الجلسات والأجهزة: من سجّل دخوله حاليًا

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

الطبقة 4: قاعدة البيانات والتشغيل

الطبقة الرابعة هي الأقل ظهورًا والأشد حساسية للأخطاء في الوقت نفسه، لأن أي خطأ فيها قد يقوّض كل ما بُني قبلها.

• نسخ احتياطية منتظمة ومختبَرة، تُخزَّن في مكان منفصل عن الخادم نفسه. فالنسخة الاحتياطية التي لم تُجرَّب استعادتها قط ليست سوى افتراض بوجود نسخة صالحة.
• يجب ألا تُسجَّل الأسرار في أي ملف سجل. كلمات المرور، ومفاتيح API، وبيانات الترخيص: على من يطوّر إضافات مخصصة أن يعاملها مثل كلمة المرور الرئيسية نفسها، فلا يسجّلها في أي مكان، حتى لو كان ذلك «لتصحيح الأخطاء فقط».
• إبقاء الوحدات محدَّثة، ولا سيما وحدات الجهات الخارجية. فمن الطبيعي أن تتأخر الإضافات الحرة (من OCA وغيرها) في مواكبة إصدارات Odoo الجديدة؛ لذا يجدر التحقق قبل كل تثبيت من التبعيات التي ستُثبَّت تلقائيًا معها.

مسار تسجيل الدخول كاملًا

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

خمس نقاط يمكن أن يتوقف عندها الطلب الخبيث قبل بلوغ هدفه الفعلي، ونقطة وصول واحدة فقط يبلغها المستخدم المخوّل بعد اجتيازها جميعًا.

سيناريوهات الهجوم وسبل التصدي لها

يربط العرض التالي أنماط هجوم واقعية بالطبقات التي توقفها فعليًا. والعديد منها ليس مجرد افتراض نظري، بل رصدناه بأنفسنا خلال سبعة عشر يومًا من حركة الزيارات الفعلية على مواقعنا الخمسة.

خطوة بخطوة: تأمين تثبيت Odoo الخاص بك

الترتيب التالي هو ما كنا سنتبعه بأنفسنا، بدءًا بالإجراءات الأوسع أثرًا وصولًا إلى أدق الإعدادات.

1. فرض المصادقة الثنائية

1. إذا لم تكن الوحدة مثبّتة بعد، فافتح التطبيقات، وابحث عن «Two-Factor Authentication» وثبّتها (وعند تشغيل عدة مواقع، يُنصح أيضًا بتثبيت «Two-Factor Authentication by Mail» كخيار احتياطي).
2. افتح الإعدادات → الإعدادات العامة → الصلاحيات.
3. فعّل «فرض المصادقة الثنائية».
4. اختر السياسة: «الموظفون فقط» للمستخدمين الداخليين، أو «جميع المستخدمين» إذا أردت تضمين مستخدمي البوابة أيضًا (العملاء الذين لديهم حسابات وصول).
5. احفظ الإعدادات. بدءًا من محاولة تسجيل الدخول التالية، سيطلب Odoo من كل مستخدم لم يُعِدّ وسيلة التحقق الثانية إدخال رمز البريد الإلكتروني على الأقل، إلى أن يُعِدّ تطبيق المصادقة.

2. تحديد حد أدنى لطول كلمات المرور

1. افتح التطبيقات، وابحث عن «Password Policy» وثبّتها.
2. افتح الإعدادات → الإعدادات العامة → الصلاحيات.
3. اضبط «الحد الأدنى لطول كلمة المرور»؛ ويُعدّ اثنا عشر محرفًا قيمة بداية معقولة.
4. احفظ الإعدادات. تسري القاعدة فورًا على كل كلمة مرور جديدة أو يجري تغييرها، ولا تُطبَّق بأثر رجعي على كلمات المرور الحالية.

3. مراجعة الصلاحيات

1. افتح الإعدادات → المستخدمون & الشركات → المستخدمون.
2. افتح سجل كل مستخدم على حدة وراجع علامة تبويب صلاحيات الوصول لكل تطبيق: هل يحتاج هذا الشخص فعلًا إلى دور «مدير» أو «مسؤول النظام»، أم يكفي دور «مستخدم»؟
3. تحقق خصوصًا ممن يملك صلاحية الوصول إلى «الإعدادات» نفسها؛ إذ ينبغي أن يقتصر ذلك على مجموعة صغيرة جدًا.
4. لكل تكامل خارجي (المحاسبة، أو البرامج النصية المخصصة، أو تتبّع الوقت)، أنشئ مفتاح API مستقلًا في علامة تبويب «أمان الحساب» الخاصة بالمستخدم التقني المعني، بدلًا من مشاركة كلمة مرور المستخدم.

4. تثبيت Web RBL ومراقبته قبل تفعيل الحظر

1. نزّل الوحدة من github.com/Alex0176/odoo-web-rbl وضعها في مسار الإضافات، ثم ثبّتها.
2. راقبها بضعة أيام: تعرض قائمة Web RBL → التحليل الأنماط التي يجري رصدها فعليًا.
3. بعد ذلك فقط، فعّل web_rbl.sperren_aktiv من الإعدادات → تقني → معلمات النظام؛ فمن هذه اللحظة تُرفض فعليًا محاولات الاستكشاف المرصودة.
4. أضف قائمة الحظر المتاحة على العنوان المحدد في الوحدة والمحمِي برمز وصول إلى جدار الحماية بوصفها قائمة RBL (في OPNsense/pfSense بصيغة URL Table Alias، وفي HAProxy بصيغة ملف ACL).

5. تأمين جدار الحماية نفسه

1. اجعل واجهة إدارة جدار الحماية متاحة من الشبكة الداخلية فقط، ولا تُتح الوصول إليها مطلقًا عبر العنوان العام نفسه المستخدم للموقع.
2. فعّل التحديثات الأمنية التلقائية لبرنامج جدار الحماية، إذا كانت الجهة المصنّعة توفّرها.
3. راجع إعدادات TLS: استخدم إصدارات البروتوكول الحديثة فقط، وعطّل أساليب التشفير القديمة.
4. إن كان ذلك متاحًا: اربط قائمة سمعة معروفة (مثل Spamhaus DROP) مباشرة على جدار الحماية — بمعزل عن Web RBL، لأن جدار الحماية يرى بذلك أيضًا الحركة نحو خدمات لا يصل إليها Odoo أبدًا.

6. إغلاق الوصول إلى إدارة قواعد البيانات

1. تحقق مما إذا كان /web/database/manager متاحًا من خارج الشبكة؛ فإن كان كذلك، فاضبط list_db = False في إعدادات Odoo أو احظر المسار على مستوى جدار الحماية.
2. عيّن كلمة مرور رئيسية طويلة وعشوائية لإدارة قواعد البيانات، ولا تدوّنها في أي مكان يمكن لأي شخص آخر قراءته.

7. اختبار النسخ الاحتياطي، لا الاكتفاء بإعداده

1. أعِدّ نسخًا احتياطيًا تلقائيًا ومنتظمًا، مع تخزين النسخ في مكان منفصل عن خادم Odoo.
2. استعِد نسخة فعلية مرة واحدة على الأقل، وتحقق من نجاح الاستعادة؛ فالنسخة الاحتياطية غير المختبَرة ليست سوى افتراض.

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

ما الذي لا تغني عنه هذه البنية الأمنية

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

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

هل تكفي كلمة مرور قوية لتأمين Odoo 19؟

لا. فقد تُسرق كلمة المرور من خدمة أخرى مهما بلغت قوتها، وعندها تتيح الدخول إلى كل خدمة تقبل كلمة المرور نفسها. ولا تتحقق حماية تصمد حتى بعد سرقة كلمة المرور إلا بالجمع بين المصادقة الثنائية، وجدار حماية أمام النظام، وتوزيع مدروس للصلاحيات.

كيف أفعّل المصادقة الثنائية في Odoo 19؟

ثبّت وحدة «Two-Factor Authentication (TOTP)» من إدارة التطبيقات، ثم فعّل فرض المصادقة من الإعدادات → الإعدادات العامة → الصلاحيات، واختر بين «الموظفون فقط» و«جميع المستخدمين». بعد ذلك، يُعِدّ كل مستخدم عامل المصادقة الثاني الخاص به باستخدام رمز QR.

ما هي قائمة RBL، ولماذا يحتاج إليها Odoo؟

RBL (Real-time Blackhole List) هي قائمة عناوين يمكن جلبها عبر HTTP، ويستطيع أي جدار حماية تقريبًا قراءتها. ولا يوفّر Odoo نفسه قائمة من هذا النوع؛ لذا تسُدّ وحدتنا Web RBL هذه الفجوة، إذ تتعرّف على حركة الطلبات الهجومية من سجل التطبيق نفسه، وتعيدها في صورة قائمة RBL إلى جدار الحماية الموجود أمامه.

هل يتمتع Odoo 19 Community بحماية كافية من دون وحدات إضافية؟

ليس بالكامل. فمن دون وحدة Password Policy، لا يوجد حد أدنى لطول كلمات المرور، ومن دون Two-Factor Authentication، لا يوجد عامل مصادقة ثانٍ، ومن دون وحدة مثل Web RBL، لا يرصد Odoo محاولات الاستكشاف ولا يتتبّع محاولات تسجيل الدخول المتكررة بعد إعادة التشغيل. ويمكن إضافة الإمكانات الأربع جميعها مجانًا.

التوافر

يتاح Web RBL للجمهور بموجب ترخيص AGPL-3، ونستخدمه فعليًا في بيئة الإنتاج على خمسة مواقع:

github.com/Alex0176/odoo-web-rbl

يتضمن المقال السابق وصفًا كاملًا للوظائف، يشمل جميع الأنماط وآلية التقييم وقوائم التهديدات: Web RBL – قائمة لحظر حركة الطلبات الهجومية على مواقعك.

نرحّب بالأسئلة والملاحظات وتقارير الأخطاء، ويُفضّل إرسالها عبر فتح Issue على GitHub.