المحتويات

المقدمة

المتطلبات الأساسية

المتطلبات

المكونات المستخدمة

معلومات أساسية

النقاط الرئيسية

نماذج يجب تجنبها

أفضل الممارسات الموصى بها

نقاط الهروب في أسماء المضيف دائما

حشوات الربط وتقييد الحروف

تجنب التكرار المتداخل وغير المحدود حيثما أمكن

نماذج الاختبار في مختبر متوافق مع PCRE2

الاختلافات في مطابقة عنوان URL ل HTTP و HTTPS

حركة مرور HTTPS (TLS)

حركة مرور HTTP (غير المشفرة)

تأثيرات التكوين

التحقق من الصحة

تمكين تسجيل الأخطاء

أمثلة التكوين

المطابقة المستندة إلى المضيف

مضيف/مسار HTTP المطابق

معلومات ذات صلة

المقدمة

يصف هذا وثيقة الإرشادات واعتبارات الأداء لاستخدام تعبيرات منتظمة في تصفية 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 قبل النشر للإنتاج.

معلومات ذات صلة

- دليل تكوين أمان Cisco Catalyst SD-WAN، Cisco IOS XE Catalyst SD-WAN، الإصدار 17.x

- الدعم الفني والتنزيلات من Cisco