ترحيل تصفية F5 iRules X-Forwarded-For إلى RELIANOID WAF/IPDS

عرض الفئات

ترحيل تصفية F5 iRules X-Forwarded-For إلى RELIANOID WAF/IPDS

4 دقائق للقراءة

نظرة عامة #

تشرح هذه المقالة كيفية ترحيل قاعدة iRule الخاصة بـ F5 BIG-IP المستخدمة لحظر الطلبات بناءً على X-Forwarded-For إدخال رأس HTTP RELIANOID باستخدام التكامل نظام WAF/IPDS (نظام منع وكشف الاختراقات) مدعوم بواسطة ModSecurity/OWASP متوافق مع مجموعة القواعد.

تقوم قاعدة iRule الأصلية بفحص X-Forwarded-For رأس HTTP ويعيد 410 Gone عندما يتم العثور على تطابق مع قائمة عناوين IP.

قاعدة F5 الأصلية #

عند إرسال طلب HTTP، إذا كان حقل "X-Forwarded-For" في رأس HTTP يحتوي على "31.192.108.123" أو "65.103.109.21" أو "193.90.12.87" أو "208.100.0.117" أو "100.113.150.102" أو "176.10.99.200" [HTTP::header values ​​"X-Forwarded-For"] يحتوي على "163.172.143.114" || [HTTP::header values ​​"X-Forwarded-For"] يحتوي على "163.172.209.46" || [HTTP::header values ​​"X-Forwarded-For"] يحتوي على "188.138.9.49" || [HTTP::header values ​​"X-Forwarded-For"] يحتوي على "217.23.13.129" || [HTTP::header values ​​"X-Forwarded-For"] يحتوي على "162.247.72.27" || [HTTP::header values ​​"X-Forwarded-For"] يحتوي على "194.67.208.57" || { HTTP::respond 410 } } { HTTP::respond 41.216.186.114 } }

RELIANOID نهج الهجرة #

In RELIANOIDيمكن تطبيق هذا المنطق باستخدام:

  • وحدة WAF/IPDS
  • قواعد ModSecurity/OWASP المخصصة
  • ملف مطابقة عناوين IP الخارجية

هذا النهج أكثر قابلية للتوسع وأسهل في الصيانة من تضمين مقارنات عناوين IP متعددة داخل برنامج نصي.

منتجات ينصح بها RELIANOID معمار #

تستخدم عملية الترحيل ما يلي:

  • فحص رأس HTTP X-Forwarded-For
  • ملف القائمة السوداء الخارجية الذي يحتوي على عناوين IP
  • مطابقة عناوين IP الديناميكية باستخدام عوامل تشغيل مجموعة قواعد ModSecurity/OWASP

المزايا:

  • إدارة أسهل لملكية الإنترنت
  • قائمة سوداء مركزية
  • لا حاجة لتعديل القواعد مع كل تغيير في عنوان IP
  • قابلية تطوير أفضل

تكوين قواعد جدار حماية تطبيقات الويب #

يمكن تكوين قاعدة ModSecurity/OWASP التالية في الوضع الخام داخل وحدة WAF/IPDS.

SecRule REQUEST_HEADERS:X-Forwarded-For "@ipMatchFromFile /usr/local/relianoid/config/ipds/waf/sets/xff_blacklist.data" "\ id:1001,\ msg:'Custom Match',\ phase:1,\ deny,\ nolog"

كيف تعمل القاعدة #

تقوم هذه القاعدة بالإجراءات التالية:
REQUEST_HEADERS:X-Forwarded-For: يقرأ ترويسة HTTP من نوع X-Forwarded-For
@ipMatchFromFile: يقارن قيمة العنوان بملف خارجي
xff_blacklist.txt: يحتوي على قائمة عناوين IP المحظورة
phase:1: يتم التنفيذ أثناء معالجة رأس الطلب
deny: يحظر الطلبات المطابقة
nolog: يعطل تسجيل الطلبات المطابقة

تكوين ملف القائمة السوداء #

أنشئ ملف القائمة السوداء:

/usr/local/relianoid/config/ipds/waf/sets/xff_blacklist.data

محتويات المثال:

31.192.108.123
65.103.109.21
193.90.12.87
208.100.0.117
100.113.150.102
176.10.99.200
163.172.143.114
163.172.209.46
188.138.9.49
217.23.13.129
162.247.72.27
194.67.208.57
41.216.186.114

قم بتكوين القاعدة عبر واجهة المستخدم الرسومية #

أنشئ قائمة بيانات IP #

أنشئ ملف بيانات WAF جديدًا في القسم IPDS > WAF > الملفات بما في ذلك محتوى قائمة عناوين IP:

ملف بيانات القائمة السوداء لجدار حماية تطبيقات الويب (WAF) الخاص بـ Relanoid IPDS

أنشئ شرط القاعدة #

أنشئ مجموعة قواعد جديدة لجدار حماية تطبيقات الويب (WAF) في القسم IPDS > WAF > مجموعات القواعد بما في ذلك شرط مطابقة عنوان IP:

relanoid ipds waf xff blacklist rule farm enable

قم بتفعيل القاعدة في المزرعة #

قم بتفعيل مجموعة القواعد وقم بتعيينها للمزارع المطلوبة.

relanoid ipds waf xff blacklist rule farm enable

ملاحظة تشغيلية هامة #

أي تعديل على ملف القائمة السوداء يتطلب ما يلي:

  • إيقاف قاعدة WAF
  • إعادة تطبيق قاعدة WAF

يؤدي هذا إلى إعادة تحميل القاعدة وتطبيق قائمة عناوين IP المُحدَّثة. سيؤثر هذا فقط على قواعد جدار حماية تطبيقات الويب (WAF) التي تم فحصها في المزارع المتأثرة، ولن يؤثر على حركة البيانات الفعلية التي تمر عبر موازن الأحمال.

التحقق من الصحة والاختبار #

يمكن استخدام الأمر التالي للتحقق من صحة سلوك القاعدة:

curl -k -H "X-Forwarded-For: IP_ADDRESS" https://LB_VIP -v

على سبيل المثال:

curl -k -H "X-Forwarded-For: 31.192.108.123" https://192.168.1.100 -v

نتيجة متوقعة #

عندما يتطابق عنوان IP مع القائمة السوداء:

  • تم رفض الطلب بواسطة جدار حماية تطبيقات الويب
  • يتم إرجاع استجابة خطأ HTTP

تحسين اختياري: إرجاع رمز HTTP 410 #

تقوم قاعدة F5 iRule الأصلية بإرجاع ما يلي بشكل صريح:

HTTP 410 غير موجود

بشكل افتراضي، تمنع قواعد ModSecurity/OWASP الإجراءات التي قد تُرجع HTTP 403 Forbidden.

إذا كانت هناك حاجة إلى تكافؤ سلوكي دقيق، فيمكن تحسين القاعدة للعودة 410.

على سبيل المثال:

SecRule REQUEST_HEADERS:X-Forwarded-For "@ipMatchFromFile /usr/local/relianoid/config/ipds/waf/xff_blacklist.txt" "\ id:1001,\ msg:'Custom Match',\ phase:1,\ deny,\ status:410,\ nolog"

فحص الجهاز #

القاعدة غير مفعلة #

التحقق:

  • تم تفعيل WAF/IPDS على المزرعة
  • تم تحميل القاعدة بشكل صحيح
  • يوجد رأس الطلب
  • تمت إعادة تشغيل القاعدة بعد تغييرات الملف

الطلبات غير محظورة #

التحقق من:

  • تنسيق IP داخل الملف
  • لا توجد مسافات إضافية أو أحرف مخفية
  • أذونات الملفات الصحيحة

العنوان مفقود #

قد لا ترسل بعض الخوادم الوسيطة في اتجاه المنبع البيانات. X-Forwarded-For. تحقق من صحة البيانات باستخدام:

curl -k -H "X-Forwarded-For: 1.2.3.4" https://LB_VIP -v

يلزم تسجيل البيانات لتحديد المشاكل وإصلاحها #

إزالة مؤقتة:

نولوغ

يسمح هذا بتسجيل قواعد ModSecurity/OWASP لأغراض تصحيح الأخطاء.

أفضل الممارسات #

  • الاحتفاظ بملفات القائمة السوداء مركزياً
  • استخدم الأتمتة لتحديثات القائمة السوداء
  • قم بمراجعة عناوين IP المحظورة بشكل دوري
  • قم بحماية ملفات قواعد جدار حماية تطبيقات الويب (WAF) باستخدام الأذونات المناسبة.
  • يُفضّل استخدام الملفات الخارجية بدلاً من القواعد المُبرمجة مسبقاً لضمان قابلية التوسع.

ملخص #

قواعد F5 iRules قيد التنفيذ X-Forwarded-For يمكن نقل عملية التصفية بكفاءة إلى RELIANOID باستخدام وحدة WAF/IPDS المتكاملة وقواعد ModSecurity.

ويوفر هذا النهج:

  • إدارة عناوين IP مركزية
  • قابلية تطوير أفضل
  • صيانة أسهل
  • تكامل جدار حماية تطبيقات الويب الأصلي
  • تقليل تعقيد البرمجة النصية

📄 قم بتنزيل هذه الوثيقة بصيغة PDF #

    ُ:البريد الالكتروني *