إشعار
يتطلب الوصول إلى هذه الصفحة تخويلاً. يمكنك محاولة تسجيل الدخول أو تغيير الدلائل.
يتطلب الوصول إلى هذه الصفحة تخويلاً. يمكنك محاولة تغيير الدلائل.
يمكنك تكوين جدار حماية Azure باستخدام قواعد NAT، وقواعد الشبكة، وقواعد التطبيق باستخدام قواعد كلاسيكية أو سياسة جدار الحماية. افتراضيا، يمنع جدار الحماية في Azure جميع حركة المرور حتى تقوم يدويا بتكوين القواعد التي تسمح بحركة المرور. يتم إنهاء القواعد، لذلك تتوقف معالجة القواعد على التطابق.
معالجة القواعد باستخدام القواعد الكلاسيكية
يعالج جدار الحماية مجموعات القواعد حسب الأولوية حسب نوع القاعدة، من أرقام أقل إلى أرقام أعلى (من 100 إلى 65,000). يمكن أن يحتوي اسم مجموعة القواعد فقط على حروف أو أرقام أو خطوط تحت أو نقاط أو شرطات. يجب أن يبدأ بحرف أو رقم، وينتهي بحرف، أو رقم، أو شرطة سفلية. أقصى طول للاسم هو 80 حرف.
في البداية، قم بتوزيع أرقام أولوية جمع القواعد على 100 زيادات (100، 200، 300، وهكذا) حتى يكون لديك مجال لإضافة المزيد من مجموعات القواعد إذا لزم الأمر.
معالجة القواعد باستخدام سياسة جدار الحماية
باستخدام سياسة الجدار الناري، تنظم القواعد داخل مجموعات القواعد ومجموعات جمع القواعد. مجموعات مجموعات القواعد تحتوي على صفر أو أكثر من مجموعات القواعد. مجموعات القواعد هي نوع NAT أو Network أو Applications. يمكنك تعريف أنواع متعددة من مجموعات القواعد ضمن مجموعة قواعد واحدة. يمكنك تعريف صفر أو أكثر من القواعد في مجموعة قواعد. يجب أن تكون القواعد في مجموعة القواعد من نفس النوع (NAT، الشبكة، أو التطبيق).
يعالج النظام القواعد بناء على أولوية مجموعة جمع القواعد وأولوية جمع القواعد. الأولوية هي أي رقم يتراوح بين 100 (أولوية قصوى) و65000 (أولوية أدنى). يعالج النظام مجموعات جمع القواعد ذات الأولوية الأعلى أولا. داخل مجموعة جمع القواعد، يعالج النظام مجموعات القواعد ذات الأولوية الأعلى (أقل رقم) أولا.
إذا ورثت سياسة جدار الحماية من سياسة أصلية، فإن مجموعات جمع القواعد في السياسة الأصلية دائما لها الأولوية بغض النظر عن أولوية سياسة الفرع.
إشعار
يقوم النظام دائما بمعالجة قواعد التطبيق تلو الأخرى قواعد الشبكة، ويعالج قواعد الشبكة تلو الأخرى قواعد DNAT بغض النظر عن مجموعة جمع القواعد أو أولوية مجموعة القواعد وميراث السياسات.
لتلخيص:
- سياسة الوالدين دائما لها الأولوية على وثيقة الطفل.
- يعالج النظام مجموعات جمع القواعد بترتيب الأولوية.
- يعالج النظام مجموعات القواعد بترتيب الأولوية.
- يعالج النظام قواعد DNAT، ثم قواعد الشبكة، ثم قواعد التطبيق.
إليك مثال على سياسة مع أربع مجموعات لجمع القواعد. يتم توريث BaseRCG1 و BaseRCG2 من سياسة أصلية؛ تنتمي ChildRCG1وChildRCG2 إلى سياسة الطفل.
نصيحة
الاختصارات المستخدمة في هذه الجداول: RCG = مجموعة جمع القواعد، RC = مجموعة قواعد. تتراوح أرقام الأولوية من 100 (أعلى أولوية) إلى 65,000 (أدنى أولوية).
هيكل السياسات:
| المستوى | الاسم | نوع | أولوية | القواعد | النهج |
|---|---|---|---|---|---|
| مجموعة | BaseRCG1 | مجموعة مجموعة القواعد | 200 | 8 | الوالد |
| مجموعة | DNATRC1 | DNAT | 600 | 7 | الوالد |
| مجموعة | DNATRC3 | DNAT | 610 | 3 | الوالد |
| مجموعة | NetworkRC1 | شبكة | 800 | 1 | الوالد |
| مجموعة | BaseRCG2 | مجموعة مجموعة القواعد | 300 | 3 | الوالد |
| مجموعة | AppRC2 | استمارة التقديم | 1200 | 2 | الوالد |
| مجموعة | NetworkRC2 | شبكة | 1300 | 1 | الوالد |
| مجموعة | ChildRCG1 | مجموعة مجموعة القواعد | 300 | 5 | طفل |
| مجموعة | ChNetRC1 | شبكة | 700 | 3 | طفل |
| مجموعة | ChAppRC1 | استمارة التقديم | 900 | 2 | طفل |
| مجموعة | ChildRCG2 | مجموعة مجموعة القواعد | 650 | 9 | طفل |
| مجموعة | ChNetRC2 | شبكة | 1100 | 2 | طفل |
| مجموعة | ChAppRC2 | استمارة التقديم | 2000 | 7 | طفل |
| مجموعة | ChDNATRC3 | DNAT | 3000 | 2 | طفل |
يكرر جدار الحماية جميع مجموعات جمع القواعد ثلاث مرات — مرة لكل نوع قاعدة بالترتيب: DNAT، ثم الشبكة، ثم التطبيق. داخل كل تمريرة، يعالج المجموعات بترتيب الأولوية، ثم تجمع القواعد داخل كل مجموعة بترتيب الأولوية. يوضح الجدول التالي تسلسل المعالجة الكامل لهذا المثال:
ترتيب المعالجة:
| خطوة | مجموعة القواعد | نوع | المجموعة الأصلية RCG |
|---|---|---|---|
| 1 | DNATRC1 | DNAT | BaseRCG1 (200) |
| 2 | DNATRC3 | DNAT | BaseRCG1 (200) |
| 3 | ChDNATRC3 | DNAT | ChildRCG2 (650) |
| 4 | NetworkRC1 | شبكة | BaseRCG1 (200) |
| 5 | NetworkRC2 | شبكة | BaseRCG2 (300) |
| 6 | ChNetRC1 | شبكة | ChildRCG1 (300) |
| 7 | ChNetRC2 | شبكة | ChildRCG2 (650) |
| 8 | AppRC2 | استمارة التقديم | BaseRCG2 (300) |
| 9 | ChAppRC1 | استمارة التقديم | ChildRCG1 (300) |
| 10 | ChAppRC2 | استمارة التقديم | ChildRCG2 (650) |
لمزيد من المعلومات حول مجموعات قواعد سياسة جدار الحماية، راجع مجموعات قواعد نهج جدار حماية Azure
التحليل الذكي للتهديدات
إذا قمت بتمكين التصفية المعتمدة على استخبارات التهديدات، فإن تلك القواعد لها الأولوية القصوى. جدار الحماية من Azure دائما يعالجها أولا، قبل قواعد الشبكة والتطبيق. يمكن أن يؤدي التصفية المعتمدة على ذكاء التهديدات إلى حظر حركة المرور قبل أن يعالج جدار الحماية في Azure أي قواعد مهيأة. لمزيد من المعلومات، راجع التصفية المستندة إلى التحليل الذكي للمخاطر في Azure Firewall.
IDPS
عندما تقوم بتكوين IDPS في وضع التنبيه ، يعمل محرك IDPS بالتوازي مع منطق معالجة القواعد. يقوم بتوليد تنبيهات عند التواقيع المتطابقة لكل من التدفقات الواردة والخارجة. لمطابقة توقيع IDPS، يقوم Azure Firewall بتسجيل تنبيه في سجلات جدار الحماية. ومع ذلك، بما أن محرك IDPS يعمل بالتوازي مع محرك معالجة القواعد، فقد تولد حركة المرور التي ترفض أو تسمح بها قواعد التطبيق أو الشبكة إدخال سجل آخر.
عند تكوين IDPS في وضع التنبيه والرفض ، يعمل محرك IDPS بشكل داخلي ويتم تفعيله بعد محرك معالجة القواعد. لذا كلا المحركين يولدان تنبيهات وقد يحجب تدفقات المطابقة.
انقطاعات الجلسة التي يقوم بها IDPS تمنع التدفق بصمت. لذلك لا يتم إرسال RST على مستوى TCP. نظرا لأن IDPS يفحص دائما حركة المرور بعد مطابقة قاعدة الشبكة أو التطبيق (السماح أو الرفض) ووضع علامات في السجلات، فقد يتم تسجيل رسالة إسقاط أخرى عندما يقرر IDPS رفض الجلسة بسبب تطابق توقيع.
عند تفعيل فحص TLS، يقوم Azure Firewall بفحص كل من حركة المرور غير المشفرة والمشفرة.
دعم حركة المرور الضمنية (TCP/UDP ذات الحالة)
يمكنك ضبط قواعد جدار الحماية للسماح بحركة المرور في اتجاه واحد فقط. على سبيل المثال، يمكن لجدار حماية Azure السماح بالاتصالات التي تبدأها من شبكة محلية إلى شبكة افتراضية لها، مع شرط حظر الاتصالات الجديدة التي تبدأها من شبكة Azure الافتراضية إلى الشبكة المحلية . لتطبيق هذه السياسة، أضف قاعدة رفض صريحة لحركة المرور من شبكة Azure الافتراضية إلى الشبكة المحلية .
يدعم جدار الحماية Azure هذا التكوين. جدار الحماية في Azure هو حالة ثابتة، لذا يسمح بإرجاع حركة المرور لاتصال TCP أو UDP قائم (على سبيل المثال، حزم SYN-ACK/ACK للاتصال الذي بدأته من الموقع) حتى عندما توجد قاعدة رفض صريحة في الاتجاه المعاكس. قاعدة الرفض الصريحة تستمر في حظر الاتصالات الجديدة التي تبدأها من شبكة Azure الافتراضية إلى الشبكة المحلية.
الاتصال الصادر
قواعد الشبكة وقواعد التطبيق
إذا قمت بتكوين قواعد الشبكة وقواعد التطبيق، فإن جدار حماية Azure يطبق قواعد الشبكة بترتيب الأولوية قبل قواعد التطبيق. جارٍ إلغاء القواعد. لذا، إذا وجد جدار الحماية في Azure تطابقا في قاعدة الشبكة، فلن يعالج أي قواعد أخرى. إذا قمت بتكوين IDPS، فإن جدار الحماية في Azure يشغله على جميع حركة المرور التي يتم عبورها. عندما يجد IDPS تطابقا في التوقيع، يمكنه توليد تنبيهات أو حجب حركة المرور المشبوهة، حسب وضع IDPS.
تقيم قواعد التطبيق الحزمة حسب ترتيب الأولوية إذا لم يكن هناك تطابق لقواعد الشبكة وإذا كان البروتوكول هو HTTP أو HTTPS أو MSSQL.
بالنسبة إلى HTTP، يبحث Azure Firewall عن تطابق قاعدة التطبيق وفقاً لعنوان المضيف. بالنسبة إلى HTTPS، يبحث Azure Firewall عن تطابق قاعدة التطبيق وفقاً لـ SNI فقط.
في كل من حالات HTTP وHTTPS التي تم فحصها بواسطة TLS، يتجاهل جدار الحماية عنوان IP الوجهة لحزمة البيانات ويستخدم عنوان IP الذي تم حله بواسطة DNS من عنوان المضيف. إذا كان هناك عدم تطابق في المنفذ بين منفذ TCP الفعلي والمنفذ في رأس المضيف، فإن جدار الحماية يسقط حركة المرور. Azure DNS أو DNS مخصص تقوم بتكوينه على جدار الحماية يقوم بحل DNS.
إشعار
جدار الحماية Azure يملأ دائما بروتوكوليتي HTTP وHTTPS (مع فحص TLS) مع تعيين رأس XFF (X-Forwarded-For) على عنوان IP المصدر الأصلي.
عندما تحتوي قاعدة التطبيق على فحص TLS، يقوم محرك قواعد الجدار الناري بمعالجة SNI، رأس المضيف، وكذلك رابط URL ليتطابق القاعدة.
إذا لم يجد جدار الحماية في Azure تطابقا ضمن قواعد التطبيق، فإنه يقيم الحزمة مقابل مجموعة قواعد البنية التحتية. إذا لم يجد جدار الحماية في Azure تطابقا بعد، فإنه يرفض الحزمة بشكل افتراضي.
مجموعة قواعد البنية التحتية
يتضمن جدار حماية Azure مجموعة قواعد مضمنة لأجل FQDNs البنية الأساسية المسموح بها بشكل افتراضي. FQDNs هي خاصة بالمنصة ولا يمكن استخدامها لأغراض أخرى. تتم معالجة جمع قواعد البنية التحتية بعد قواعد التطبيق وقبل قاعدة الرفض النهائية.
تتضمن مجموعة قواعد البنية التحتية المدمجة الخدمات التالية:
- حساب الوصول إلى مستودع صور منصة التخزين (PIR)
- الوصول إلى حالة تخزين الأقراص المدارة
- Azure Diagnostics and Logging (MDS)
تجاوز جمع قواعد البنية التحتية
يمكنك تجاوز مجموعة قواعد البنية التحتية المدمجة عن طريق إنشاء مجموعة قواعد رفض كل التطبيقات التي تتم معالجتها في النهاية. دائما ما تعالج قبل جمع قواعد البنية التحتية. أي شيء غير موجود في مجموعة قواعد البنية التحتية يرفض تلقائيا.
إشعار
يمكنك تكوين قواعد الشبكة ل TCP أو UDP أو ICMP أو أي بروتوكول IP. أي يشمل بروتوكول IP جميع بروتوكولات IP كما هو معرف في وثيقة أرقام بروتوكول سلطة أرقام الإنترنت المخصصة للإنترنت (IANA). إذا قمت بتكوين منفذ وجهة بشكل صريح، فإن القاعدة تترجم إلى قاعدة TCP+UDP. قبل 9 نوفمبر 2020، فإن أي يقصد بها TCP، أو UDP، أو ICMP. لذلك، ربما تكون قد قمت بتكوين قاعدة قبل ذلك التاريخ باستخدام Protocol = Any، ومنافذ الوجهة = '*'. إذا لم تكن تنوي السماح بأي بروتوكول IP كما هو معرف حاليا، قم بتعديل القاعدة لتكوين البروتوكولات التي تريدها بشكل صريح (TCP، UDP، أو ICMP).
الاتصال الوارد
قواعد DNAT وقواعد الشبكة
يمكنك تمكين الاتصال بالإنترنت الوارد أو الإنترانت عن طريق تكوين ترجمة عناوين شبكة الوجهة (DNAT) كما هو موضح في فلترة حركة المرور الواردة من الإنترنت أو الإنترانت باستخدام جدار الحماية Azure باستخدام بوابة Azure. قواعد NAT تنطبق في الأولوية قبل قواعد الشبكة. إذا وجد جدار الحماية في Azure تطابقا، فإنه يترجم الحركة وفقا لقاعدة DNAT ويسمح بذلك. لذا، الحركة لا تخضع لأي معالجة إضافية بموجب قواعد الشبكة الأخرى. لأسباب أمنية، أضف مصدرا محددا لإنترنت للسماح بالوصول إلى الشبكة ب DNAT وتجنب استخدام البطاقات الغريبة.
جدار الحماية في Azure لا يطبق قواعد التطبيق للاتصالات الواردة. لذا، إذا كنت تريد تصفية حركة مرور HTTP/S الواردة، استخدم جدار حماية تطبيقات الويب (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 — الاسم: جمع الإنكار، الأولوية: 100، الإجراء: الرفض
| الاسم | البروتوكول | نوع المصدر | المصدر | نوع الوجهة | عنوان الوجهة | منافذ الوجهة |
|---|---|---|---|---|---|---|
| الرفض-SSH | TCP | عنوان IP | * | عنوان IP | * | 22 |
النتيجة
يتم رفض اتصالات SSH لأن مجموعة قواعد الشبكة ذات الأولوية الأعلى تحجزها. تتوقف معالجة القواعد عند هذه النقطة.
تغييرات القاعدة
إذا غيرت قاعدة لرفض حركة المرور المسموح بها سابقا، فإن جدار الحماية في Azure يحذف أي جلسات موجودة ذات صلة.
تصرف تأكيد الاتصال ثلاثي الاتجاه
كخدمة ذات حالة، يُكمل Azure Firewall عملية تأكيد اتصال TCP ثلاثية الاتجاهات لحركة الانتقال المسموح بها، من المصدر إلى الوجهة. على سبيل المثال، من VNet-A إلى VNet-B.
إنشاء قاعدة السماح من VNet-A إلى VNet-B لا يعني أن الاتصالات الجديدة التي تم بدؤها من VNet-B إلى VNet-A مسموح بها.
وبالتالي، لا تحتاج إلى إنشاء قاعدة رفض صريحة من VNet-B إلى VNet-A.