المقدمة
يصف هذا وثيقة الإرشادات واعتبارات الأداء لاستخدام تعبيرات منتظمة في تصفية URL باستخدام محرك UTD. تستخدم تصفية URL في محرك UTD مكتبة التعبير العادي PCRE2.
تمت المساهمة من قبل يوجين خاباروف، من شركة Cisco Engineering.
المتطلبات الأساسية
المتطلبات
توصي Cisco بأن تكون لديك معرفة بالمواضيع التالية:
- صياغة التعبير النمطي (regex)
- مفاهيم تصفية URL
- تكوين الدفاع الموحد ضد التهديد (UTD)
- فروق بروتوكول HTTPS/HTTP
المكونات المستخدمة
لا يقتصر هذا المستند على إصدارات برامج ومكونات مادية معينة.
تم إنشاء المعلومات الواردة في هذا المستند من الأجهزة الموجودة في بيئة معملية خاصة. بدأت جميع الأجهزة المُستخدمة في هذا المستند بتكوين ممسوح (افتراضي). إذا كانت شبكتك قيد التشغيل، فتأكد من فهمك للتأثير المحتمل لأي أمر.
معلومات أساسية
على الرغم من قوة PCRE2، إلا أن بعض التعبيرات المعقدة أو "الجشعة" قد تتسبب في تراجعات مفرطة وقد تصل إلى الحدود الداخلية في محرك regex. عندما يحدث هذا، فإن النمط قد يستغرق وقتا طويلا جدا للمعالجة ويتم التعامل معه في نهاية المطاف على أنه "لا تطابق".
النقاط الرئيسية
- تعمل تقنية PCRE2 على فرض حدود داخلية على خطوات التراجع أو وقت المطابقة من أجل حماية موارد النظام.
- تكون بعض الأنماط صحيحة من حيث التركيب ولكن غير آمنة من الناحية الحسابية ويمكن أن تؤدي إلى "تعقب عكسي كارثي".
- عندما يتم تجاوز هذه الحدود، يمكن أن يقوم محرك regex بإجهاض المعالجة وعدم إرجاع أي تطابق، حتى في حالة تطابق URL مع النمط بشكل منطقي.
نماذج يجب تجنبها
تجنب عمليات إنشاء regex التي يتم دمجها:
- كميات متداخلة، على سبيل المثال: (...+)*، (.*)*، (.+)+، وهكذا
- تكرار أحرف البدل (.) على أجزاء كبيرة من السلسلة، خاصة بالقرب من نهاية النموذج
- نقاط غير مهربة في أسماء المجالات عند إستخدامها مع التكرار
على سبيل المثال، هنا يكون النمط صالحا من حيث التركيب لكنه قد يكون باهظ التكلفة لمعالجته:
^([a-zA-Z0-9-]+.)*portal.example.com$
ملاحظة: في هذه الحالة، ([a-zA-Z0-9-]+.)* هي مجموعة تحتوي على كمي متداخل (+ داخل *) بالإضافة إلى حرف بدل (.). في بعض المدخلات غير المتطابقة، محرك regex يستطيع أستكشاف عدد كبير جدا من المسارات الخلفية.
أفضل الممارسات الموصى بها
نقاط الهروب في أسماء المضيف دائما
أستخدم \. لمطابقة نقطة حرفية، على سبيل المثال:
^([a-zA-Z0-9-]+\.)*portal\.example\.com$
حشوات الربط وتقييد الحروف
أستخدم ^ و$ وتقييد إلى الأحرف المتوقعة (على سبيل المثال، [a-zA-Z0-9-] لتسميات المضيف) لتقليل التراجع.
تجنب التكرار المتداخل وغير المحدود حيثما أمكن
يفضل التركيبات الأكثر بساطة بدلا من الأنماط المعقدة التي تحاول تغطية كل شيء في ركيزة واحدة. تأملوا في عدة إدخالات محددة بدلا من تعبير واحد واسع جدا.
نماذج الاختبار في مختبر متوافق مع PCRE2
قبل النشر، قم باختبار أنماط regex في بيئة متوافقة مع PCRE2 وتجنب الأنماط التي تتسبب في حدوث "عمليات إرتداد كارثية" أو تحذيرات مماثلة.
ملاحظة: إذا وصل نمط regex إلى الحدود الداخلية لمحرك PCRE2، يمكن معالجته على أنه "غير مطابق" بواسطة محرك تصفية URL. في مثل هذه الحالات، يرجع تصنيف عنوان URL إلى الفئة أو السمعة، وليس نتيجة تغيير القائمة السوداء/القائمة البيضاء. تكون الحدود الدقيقة خاصة بالتنفيذ ويمكن أن تتغير بين الإصدارات. يجب أن تصمم منحنيات بشكل متحفظ.
الاختلافات في مطابقة عنوان URL ل HTTP و HTTPS
يفحص محرك UTD عناوين URL بشكل مختلف لحركة مرور HTTPS و HTTP. يؤثر ذلك على كيفية تصميم التعبيرات العادية لتصفية URL.
حركة مرور HTTPS (TLS)
لحركة مرور HTTPS المشفرة، لا يقوم محرك UTD بفك تشفير الحمولة بشكل افتراضي.
- تستخدم تصفية URL إشارة اسم الخادم (SNI) من ClientHello لأمان طبقة النقل (TLS).
- يتم تطبيق نمط regex على اسم مضيف SNI فقط، على سبيل المثال: api.example.com
في هذه الحالة، تتم مطابقة نمط مستند إلى اسم المضيف مع سلسلة اسم المضيف api.example.com مثل:
^([a-zA-Z0-9-]+\.)*example\.com$
حركة مرور HTTP (غير المشفرة)
لحركة مرور HTTP العادية، يمكن لمحرك UTD رؤية طلب HTTP الكامل (سطر الطلب والرؤوس).
حسب التنفيذ، السلسلة المعطاة إلى ال regex محرك يستطيع تضمنت:
- عنوان الربط الكامل أو سطر الطلب (على سبيل المثال، GET /path؟param=value http/1.1) أو
- رأس المضيف مقترن بالمسار (على سبيل المثال، api.example.com/path)
ونتيجة لذلك، يمكن أن يحتوي إدخال regex ل HTTP على أحرف إضافية مثل /، ؟، وسلسلات الاستعلام، وليس اسم المضيف العاري فقط.
تأثيرات التكوين
يمكن أن يطابق regex الذي تم تصميمه فقط لأسماء المضيف (على سبيل المثال، api.example.com) HTTPS بشكل صحيح (SNI) ولكنه يفشل في مطابقة طلب HTTP الذي يحتوي على URL كامل أو سلسلة المضيف+المسار.
لتصفية كل من حركة مرور HTTP و HTTPS بنفس النمط، يجب عليك:
- تصميم النماذج بشكل أساسي حول أسماء المضيف
- التحقق من السلوك مقابل كل من HTTP و HTTPS في سجلات UTD
التحقق من الصحة
تمكين تسجيل الأخطاء
الخطوة 1. قم بتشغيل الأمر debug utd engine standard url-filtering level info لتمكين تسجيل تصحيح الأخطاء.
الخطوة 2. قم بتشغيل الوحدة النمطية UTD الخاصة بعرض عملية التسجيل show logging process | قم بتضمين الأمر api.example.com للتحقق من السجلات.
مثال الإخراج:
2025/11/27 11:45:28.195000350 {ioxman_R0-0}{255}: [utd] [21292]: (note): :(#0):INSP-URLF event->server_name - api.example.com
2025/11/27 11:45:28.195001873 {ioxman_R0-0}{255}: [utd] [21292]: (note): :(#0):INSP-URLF URL: api.example.com, len: 27
2025/11/27 11:45:28.195009216 {ioxman_R0-0}{255}: [utd] [21292]: (note): :(#0):INSP-URLF Regex matched successful at offset: 0, pattern: api.example.com
2025/11/27 11:45:28.195022442 {ioxman_R0-0}{255}: [utd] [21292]: (note): :(#0):INSP-URLF URLF whitelist matched successful: idx=772, pattern=api.example.com
2025/11/27 11:45:33.530605572 {ioxman_R0-0}{255}: [utd] [21292]: (note): :(#0):INSP-URLF URL: api.example.com/path, len: 28
2025/11/27 11:45:33.530606333 {ioxman_R0-0}{255}: [utd] [21292]: (note): :(#0):INSP-URLF Regex not matched pattern=api.example.com/path
2025/11/27 11:45:33.530614980 {ioxman_R0-0}{255}: [utd] [21292]: (note): :(#0):INSP-URLF URLF whitelist not matched: idx=791, pattern=api.example.com/path
أمثلة التكوين
المطابقة المستندة إلى المضيف
للسماح بجميع المجالات الفرعية ل example.com، أستخدم النمط الذي يركز على اسم المضيف الموصى به (الخط الأساسي):
^([a-zA-Z0-9-]+\.)*example\.com$
هذا النمط:
- مطابقة example.com وapi.example.com وfoo.bar.example.com، وما إلى ذلك
- مناسب لمطابقة HTTPS (SNI)
- يستطيع أيضا طابقت HTTP إن الخيط يرى بالمحرك ال عار hostname
مضيف/مسار HTTP المطابق
إذا كان HTTP يتضمن مضيف/مسار وتريد تجاهل المسار، يمكنك مطابقة بادئة اسم المضيف وترك regex يتوقف عند حد كلمة بدلا من التبعية. *، على سبيل المثال:
^([a-zA-Z0-9-]+\.)*example\.com\b
ملاحظة: هنا، \b (حد الكلمات) يسمح بشكل فعال بالحروف مثل / أو ؟ in order to تبعت اسم المضيف دون طلب حرف بدل صريح.*. هذه العملية أقل تكلفة من إضافة .* في نهاية الأمر، وتتوافق بشكل أفضل مع الإرشادات لتجنب أحرف البدل الإضافية غير المحدودة.
تحذير: السلسلة الصحيحة التي تم تمريرها إلى محرك regex لطلبات HTTP هي خاصة بالتطبيق ويمكن أن تتطور. عند الشك، قم باختبار الأنماط مقابل كل من حركة مرور HTTP و HTTPS في بيئة معملية وتحقق من التطابقات في سجلات UTD قبل النشر للإنتاج.
معلومات ذات صلة
التعليقات