تكوين قواعد Azure Firewall
يمكنك تكوين قواعد NAT وقواعد الشبكة وقواعد التطبيقات على Azure Firewall باستخدام القواعد الكلاسيكية أو نهج جدار الحماية. يرفض Azure Firewall كل حركة انتقال بشكل افتراضي، حتى يتم تكوين القواعد يدوياً للسماح بالانتقال.
معالجة القواعد باستخدام القواعد الكلاسيكية
تتم معالجة مجموعات القواعد وفقاً لنوع القاعدة في ترتيب الأولوية، والأرقام الأقل إلى الأرقام الأعلى من 100 إلى 65.000. يمكن أن يحتوي اسم مجموعة القواعد على أحرف أو أرقام أو شرطة سفلية أو نقاط أو واصلة. يجب أن يبدأ بحرف أو رقم، وينتهي بحرف، أو رقم، أو شرطة سفلية. أقصى طول للاسم هو 80 حرف.
من الأفضل أن تقوم في البداية بتباعد أرقام أولوية مجموعة القواعد الخاصة بك بزيادات 100 (100 و200 و300 وما إلى ذلك) حتى يكون لديك مساحة لإضافة المزيد من مجموعات القواعد إذا لزم الأمر.
معالجة القاعدة باستخدام نهج جدار الحماية
باستخدام "نهج جدار الحماية"، يتم تنظيم القواعد داخل مجموعات القواعد ومجموعات مجموعة القواعد. تحتوي مجموعات مجموعة القواعد على صفر أو أكثر من مجموعات القواعد. مجموعات القواعد هي نوع NAT، أو الشبكة، أو التطبيقات. يمكنك تحديد أنواع متعددة لمجموعة القواعد داخل مجموعة قواعد واحدة. يمكنك تحديد صفر أو أكثر من القواعد في مجموعة القواعد. يجب أن تكون القواعد في مجموعة القواعد من نفس النوع (NAT، أو الشبكة، أو التطبيق).
تتم معالجة القواعد بناءً على أولوية مجموعة القواعد وأولوية مجموعة القواعد. الأولوية هي أي رقم يتراوح بين 100 (أولوية قصوى) و65000 (أولوية أدنى). تتم معالجة مجموعات القواعد ذات الأولوية القصوى أولاً. داخل مجموعة القواعد، تتم معالجة مجموعات القواعد ذات الأولوية القصوى (أقل رقم) أولاً.
إذا كانت سياسة جدار الحماية موروثة من سياسة أصلية، فإن مجموعات Rule Collection في السياسة الأصلية لها الأولوية دائماً بغض النظر عن أولوية السياسة الفرعية.
إشعار
تتم معالجة قواعد التطبيق دائماً بعد قواعد الشبكة، والتي تتم معالجتها بعد قواعد DNAT بغض النظر عن مجموعة القواعد أو أولوية مجموعة القواعد واتباع النهج.
فيما يلي مثال للسياسة:
بافتراض أن BaseRCG1 هي أولوية مجموعة قواعد (200) تحتوي على مجموعات القواعد: DNATRC1، DNATRC3، NetworkRC1.
BaseRCG2 هي أولوية مجموعة قواعد (300) تحتوي على مجموعات القواعد: AppRC2 وNetworkRC2.
ChildRCG1 هي أولوية مجموعة قواعد (200) تحتوي على مجموعات القواعد: ChNetRC1 و ChAppRC1.
ChildRCG2 هي مجموعة قواعد تحتوي على مجموعات القواعد: ChNetRC2، ChAppRC2، ChDNATRC3.
وفقا للجدول التالي:
| Name | نوع | الأولوية | القواعد | موروث من |
|---|---|---|---|---|
| BaseRCG1 | Rule collection group | 200 | 8 | النهج الأصل |
| DNATRC1 | جمع قاعدة DNAT | 600 | 7 | النهج الأصل |
| DNATRC3 | جمع قاعدة DNAT | 610 | 3 | النهج الأصل |
| NetworkRC1 | مجموعات قواعد الشبكة | 800 | 1 | النهج الأصل |
| BaseRCG2 | Rule collection group | 300 | 3 | النهج الأصل |
| AppRC2 | مجموعة قواعد التطبيق | 1200 | 2 | النهج الأصل |
| NetworkRC2 | مجموعات قواعد الشبكة | 1300 | 1 | النهج الأصل |
| ChildRCG1 | Rule collection group | 300 | 5 | - |
| ChNetRC1 | مجموعات قواعد الشبكة | 700 | 3 | - |
| ChAppRC1 | مجموعة قواعد التطبيق | 900 | 2 | - |
| ChildRCG2 | Rule collection group | 650 | 9 | - |
| ChNetRC2 | مجموعات قواعد الشبكة | 1100 | 2 | - |
| ChAppRC2 | مجموعة قواعد التطبيق | 2000 | 7 | - |
| ChDNATRC3 | جمع قاعدة DNAT | 3000 | 2 | - |
المعالجة الأولية:
تبدأ العملية بفحص مجموعة القواعد (RCG) بأقل عدد، وهو BaseRCG1 مع أولوية 200. داخل هذه المجموعة، يبحث عن مجموعات قواعد DNAT ويقيمها وفقا لأولوياتها. في هذه الحالة، يتم العثور على DNATRC1 (الأولوية 600) DNATRC3 (الأولوية 610) ومعالجتها وفقا لذلك.
بعد ذلك، ينتقل إلى RCG التالي، BaseRCG2 (الأولوية 200)، ولكنه لا يجد مجموعة قواعد DNAT.
بعد ذلك، ينتقل إلى ChildRCG1 (الأولوية 300)، أيضا دون مجموعة قواعد DNAT.
وأخيرا، يتحقق من ChildRCG2 (الأولوية 650) ويجد مجموعة قواعد ChDNATRC3 (الأولوية 3000).
التكرار داخل مجموعات مجموعة القواعد:
بالعودة إلى BaseRCG1، يستمر التكرار، هذه المرة لقواعد الشبكة. تم العثور على NetworkRC1 فقط (الأولوية 800).
ثم ينتقل إلى BaseRCG2، حيث يوجد NetworkRC2 (الأولوية 1300).
بالانتقال إلى ChildRCG1، يكتشف ChNetRC1 (الأولوية 700) كقاعدة NETWORK.
وأخيرا، في ChildRCG2، تجد ChNetRC2 (الأولوية 1100) كمجموعة قواعد NETWORK.
التكرار النهائي لقواعد التطبيق:
عند العودة إلى BaseRCG1، تتكرر العملية لقواعد التطبيق، ولكن لم يتم العثور على أي منها.
في BaseRCG2، يعرف AppRC2 (الأولوية 1200) كقاعدة APPLICATION.
في ChildRCG1، تم العثور على ChAppRC1 (الأولوية 900) كقاعدة APPLICATION.
وأخيرا، في ChildRCG2، فإنه يحدد موقع ChAppRC2 (الأولوية 2000) كقاعدة APPLICATION.
باختصار، تسلسل معالجة القواعد كما يلي: DNATRC1، DNATRC3، ChDNATRC3، NetworkRC1، NetworkRC2، ChNetRC1، ChNetRC2، AppRC2، ChAppRC1، ChAppRC2.
تتضمن هذه العملية تحليل مجموعات مجموعة القواعد حسب الأولوية، وضمن كل مجموعة، وترتيب القواعد وفقا لأولوياتها لكل نوع قاعدة (DNAT وNETWORK وAPPLIC).
لذلك تتم أولا معالجة جميع قواعد DNAT من جميع مجموعات جمع القواعد، وتحليل مجموعات مجموعة القواعد حسب ترتيب الأولوية وترتيب قواعد DNAT داخل كل مجموعة قواعد حسب ترتيب الأولوية. ثم نفس العملية لقواعد الشبكة، وأخيرا لقواعد التطبيق.
لمزيد من المعلومات حول مجموعات قواعد سياسة جدار الحماية، راجع مجموعات قواعد نهج جدار حماية Azure
التحليل الذكي للمخاطر
إذا قمت بتمكين التصفية المستندة إلى معلومات التهديد، فستكون هذه القواعد ذات أولوية قصوى وتتم معالجتها دائماً أولاً (قبل قواعد الشبكة والتطبيق). قد ترفض تصفية استخبارات التهديدات حركة الانتقال قبل معالجة أي قواعد تم تكوينها. لمزيد من المعلومات، راجع التصفية المستندة إلى التحليل الذكي للمخاطر في Azure Firewall.
IDPS
عند تكوين IDPS في وضع التنبيه، يعمل محرك IDPS بالتوازي مع منطق معالجة القواعد، ويقوم بإنشاء تنبيهات حول التوقيعات المتطابقة لكل من التدفقات الواردة والصادرة. لمطابقة توقيع IDPS، يتم تسجيل تنبيه في سجلات جدار الحماية. ومع ذلك، نظرا لأن محرك IDPS يعمل بالتوازي مع محرك معالجة القواعد، فقد لا تزال نسبة استخدام الشبكة مرفوضة أو مسموحا بها من قبل قواعد التطبيق/الشبكة بإنشاء إدخال سجل آخر.
عند تكوين IDPS في وضع التنبيه والرفض، فإن محرك IDPS مُضمن ونشط بعد محرك معالجة القواعد. لذا فإن كِلَا المحركَين يولد تنبيهات، وقد يحظران تدفقات متطابقة.
قطرات الجلسة التي يتم إجراؤها بواسطة IDPS تمنع التدفق بصمت. لذلك لا يتم إرسال RST على مستوى TCP. نظرا لأن IDPS يفحص حركة المرور دائما بعد مطابقة قاعدة الشبكة/التطبيق (السماح/الرفض) ووضع علامة عليها في السجلات، فقد يتم تسجيل رسالة إسقاط أخرى حيث يقرر IDPS رفض جلسة العمل بسبب تطابق التوقيع.
عند تمكين فحص TLS، يتم فحص كل حركة انتقال غير مشفرة.
الاتصال الصادر
قواعد الشبكة وقواعد التطبيقات
إذا قمتَ بتكوين قواعد الشبكة وقواعد التطبيق، فسيتم تطبيق قواعد الشبكة بترتيب الأولوية قبل قواعد التطبيق. جارٍ إلغاء القواعد. لذلك، إذا تم العثور على تطابق في قاعدة الشبكة، فلن تتم معالجة أي قواعد أخرى. إذا تم تكوينه، يتم إجراء IDPS على جميع حركات الانتقال التي تم اجتيازها وعند تطابق التوقيع، قد يقوم IDPS بتنبيه و/أو حظر حركة الانتقال المشبوهة.
ثم تقوم قواعد التطبيق بتقييم الحزمة بترتيب الأولوية إذا لم يكن هناك تطابق لقاعدة الشبكة، وإذا كان البروتوكول HTTP أو HTTPS أو MSSQL.
بالنسبة إلى HTTP، يبحث Azure Firewall عن تطابق قاعدة التطبيق وفقاً لعنوان المضيف. بالنسبة إلى HTTPS، يبحث Azure Firewall عن تطابق قاعدة التطبيق وفقاً لـ SNI فقط.
في كل من حالات HTTP وHTTPS التي تم فحصها بواسطة TLS، يتجاهل جدار الحماية عنوان IP الوجهة لحزمة البيانات ويستخدم عنوان IP الذي تم حله بواسطة DNS من عنوان المضيف. يتوقع جدار الحماية الحصول على رقم المنفذ في عنوان المضيف، وإلا فإنه يفترض المنفذ القياسي 80. إذا كان هناك عدم تطابق في المنفذ بين منفذ TCP الفعلي والمنفذ الموجود في عنوان المضيف، فسيتم وقف حركة الانتقال. يتم حل DNS بواسطة Azure DNS أو DNS مخصص إذا تم تكوينه على جدار الحماية.
إشعار
يتم دائماً تعبئة بروتوكولَي HTTP وHTTPS (مع فحص TLS) بواسطة Azure Firewall بعنوان XFF (X-Forwarded-For) يساوي عنوان IP الأصلي.
عندما تحتوي قاعدة تطبيق على فحص TLS، يعالج محرك قواعد جدار الحماية SNI، وعنوان المضيف، وكذلك عنوان URL لمطابقة القاعدة.
إذا لم يتم العثور على تطابق ضمن قواعد التطبيق، فسيتم تقييم الحزمة مقابل مجموعة قواعد البنية الأساسية. إذا لم يكن هناك تطابق، فسيتم رفض الحزمة افتراضياً.
إشعار
يمكن تكوين قواعد الشبكة لـ TCP، أو UDP، أو ICMP، أو أي بروتوكول IP. يتضمن أي بروتوكول IP جميع بروتوكولات IP على النحو المحدد في وثيقة أرقام بروتوكول هيئة أرقام الإنترنت المخصصة (IANA). إذا تم تكوين منفذ الوجهة بشكل صريح، فسيتم تحويل القاعدة إلى قاعدة TCP + UDP. قبل 9 نوفمبر 2020، فإن أي يقصد بها TCP، أو UDP، أو ICMP. لذلك، ربما تكون قد قمت بتكوين قاعدة قبل ذلك التاريخ باستخدام Protocol = Any، ومنافذ الوجهة = '*'. إذا كنت لا تنوي السماح بأي بروتوكول IP كما هو محدد حالياً، فقم بتعديل القاعدة لتكوين البروتوكول (البروتوكولات) الذي تريده بشكل صريح (TCP، أو UDP، أو ICMP).
الاتصال الوارد
قواعد DNAT وقواعد الشبكة
يمكن تمكين الاتصال بالإنترنت الوارد عن طريق تكوين ترجمة عنوان الشبكة الوجهة (DNAT) كما هو موضح في تصفية نسبة استخدام الشبكة الواردة باستخدام AZURE Firewall DNAT باستخدام مدخل Microsoft Azure. يتم تطبيق قواعد NAT بالأولوية قبل قواعد الشبكة. إذا تم العثور على تطابق، تتم ترجمة نسبة استخدام الشبكة وفقا لقاعدة DNAT ويسمح بها جدار الحماية. لذلك لا تخضع نسبة استخدام الشبكة لأي معالجة أخرى من قبل قواعد الشبكة الأخرى. لأسباب أمنية، فإن الطريقة المُوصى بها هي إضافة مصدر إنترنت مُحدد للسماح بوصول DNAT إلى الشبكة وتجنب استخدام أحرف البدل.
لا يتم تطبيق قواعد التطبيق على الاتصالات الواردة. لذلك، إذا كنت ترغب في تصفية نسبة استخدام شبكة HTTP أو HTTPS الواردة، يجب استخدام جدار حماية تطبيق الويب (WAF). لمزيد من المعلومات، راجع ما هو Azure Web Application Firewall؟
الأمثلة
توضح الأمثلة التالية نتائج بعض مجموعات القواعد هذه.
المثال 1
يُسمح بالاتصال بـ google.com بسبب وجود قاعدة شبكة مطابقة.
قاعدة الشبكة
- الإجراء: سماح
| الاسم | البروتوكول | نوع المصدر | المصدر | نوع الوجهة | عنوان الوجهة | منافذ الوجهة |
|---|---|---|---|---|---|---|
| السماح على شبكة الإنترنت | TCP | عنوان IP | * | عنوان IP | * | 80,443 |
قاعدة التطبيق
- الإجراء: الرفض
| الاسم | نوع المصدر | المصدر | Protocol:Port | FQDNs الهدف |
|---|---|---|---|---|
| Deny-google | عنوان IP | * | http: 80،https:443 | google.com |
النتيجة
يسمح بالاتصال google.com لأن الحزمة تطابق قاعدة السماح بشبكة ويب . تتوقف معالجة القواعد عند هذه النقطة.
المثال 2
يتم رفض حركة مرور SSH لأن مجموعة قواعد الشبكة رفض ذات أولوية أعلى تحظرها.
مجموعة قواعد الشبكة 1
- الاسم: السماح - المجموعة
- الأولوية: 200
- الإجراء: سماح
| الاسم | البروتوكول | نوع المصدر | المصدر | نوع الوجهة | عنوان الوجهة | منافذ الوجهة |
|---|---|---|---|---|---|---|
| السماح-SSH | TCP | عنوان IP | * | عنوان IP | * | 22 |
مجموعة قواعد الشبكة 2
- الاسم: الرفض - المجموعة
- Priority: 100
- الإجراء: الرفض
| الاسم | البروتوكول | نوع المصدر | المصدر | نوع الوجهة | عنوان الوجهة | منافذ الوجهة |
|---|---|---|---|---|---|---|
| الرفض-SSH | TCP | عنوان IP | * | عنوان IP | * | 22 |
النتيجة
تم رفض اتصالات SSH؛ لأن مجموعة قواعد الشبكة ذات الأولوية الأعلى تحظرها. تتوقف معالجة القواعد عند هذه النقطة.
تغييرات القاعدة
إذا قمت بتغيير قاعدة لرفض الزيارات المسموح بها سابقاً، فسيتم تجاهل أي جلسات حالية ذات صلة.
تصرف تأكيد الاتصال ثلاثي الاتجاه
كخدمة ذات حالة، يُكمل Azure Firewall عملية تأكيد اتصال TCP ثلاثية الاتجاهات لحركة الانتقال المسموح بها، من المصدر إلى الوجهة. على سبيل المثال، من VNet-A إلى VNet-B.
لا يعني إنشاء قاعدة سماح من VNet-A إلى VNet-B أنه يُسمح باتصالات جديدة بدأت من VNet-B إلى VNet-A.
نتيجة لذلك، ليست هناك حاجة إلى إنشاء قاعدة رفض صريحة من VNet-B إلى VNet-A. إذا قمت بإنشاء قاعدة الرفض هذه، يمكنك مقاطعة تأكيد الاتصال ثلاثي الاتجاه من قاعدة السماح الأولية من VNet-A إلى VNet-B.