دليل المُحلِّل المحلي

نشر جهاز المُحلِّل المحلي لـ DNS Armor™: التثبيت على ESXi وHyper-V وKVM، وأوضاع الوكيل والمحلي، وActive Directory، والإتاحة العالية، وتسجيل SIEM، والمراقبة.

دليل النشر الشامل — DNS Armor™ Protect (DNS Firewall)

1. مقدمة#

يقدّم هذا المستند إجراءات نشر شاملة لتطبيق وظائف المُحلِّل المحلي لـ DNS Armor™ Protect (DNS Firewall) ضمن البنية التحتية لأمن DNS الخاصة بك. يعمل مكوّن Local Resolver كوسيط ذكي يدير توجيه استعلامات DNS، ويطبّق سياسات الأمن، ويفرض الحماية من التهديدات، ويُحسّن أداء الاستجابة، مع الحفاظ على تكامل سلس مع البنية التحتية الحالية لشبكتك.

1.1 الغرض من المستند#

يوفّر دليل النشر هذا تعليمات خطوة بخطوة لتثبيت المُحلِّل المحلي Protect وتكوينه والتحقق من صحته في كلا وضعي التشغيل: DNS Forward Proxy (DFP) و Local Resolver. يغطي الدليل ما يلي:

• إجراءات تثبيت كاملة من نشر الجهاز الافتراضي حتى التحويل إلى الإنتاج
• تكوين سياسات مفصّل لكلا وضعي التشغيل
• تكامل Active Directory للسجلات المعتمدة على الهوية
• بنية نشر عالية التوافر
• إجراءات شاملة للتحقق واستكشاف الأخطاء وإصلاحها

1.2 الجمهور المستهدف#

صُمِّم هذا الدليل للمختصين التقنيين المسؤولين عن البنية التحتية لأمن DNS:

• مسؤولو الشبكة (Network Administrators) - المسؤولون عن البنية التحتية لـ DNS والتوجيه
• مهندسو الأمن (Security Engineers) - إدارة سياسات أمن DNS والحماية من التهديدات
• فِرَق البنية التحتية لتقنية المعلومات (IT Infrastructure Teams) - نشر الأنظمة الافتراضية وصيانتها
• مسؤولو الأنظمة (System Administrators) - الإشراف على Active Directory والبنية التحتية للسجلات

المتطلبات الأساسية: ينبغي أن يكون لدى القرّاء معرفة عملية بمفاهيم DNS، ومنصات الافتراضية، ومبادئ أمن الشبكات، والعمليات الأساسية لسطر أوامر Linux.

1.3 اصطلاحات المستند#

تُستخدم الاصطلاحات التالية في هذا المستند:

⚠️ حرج (CRITICAL) إجراءات قد تؤدي إلى انقطاع الخدمة إن لم تُنفَّذ بشكل صحيح

⚡ مهم (IMPORTANT) معلومات رئيسية تؤثر على الأمن أو الوظائف

ℹ️ ملاحظة (NOTE) سياق إضافي أو معلومات مفيدة

✅ أفضل ممارسة (BEST PRACTICE) النهج الموصى به استناداً إلى الخبرة الميدانية

💡 نصيحة (TIP) اقتراحات للتحسين أو اختصارات

2. نظرة عامة على الحل#

يوفّر DNS Armor™ Protect (DNS Firewall) خيارات نشر مرنة لحماية شبكات الشركات والمستخدمين المتنقلين من التهديدات القائمة على DNS من خلال الفحص الشامل والتصفية وذكاء التهديدات. يجلب Local Resolver حلّ Protect إلى الموقع المحلي (on-premises) ويدعم نموذجَيْ نشر متمايزَين، كلٌ منهما مُحسَّن لمتطلبات تنظيمية محددة.

2.1 الخدمات الأساسية#

2.1.1 خدمة DNS Proxy#

توفّر خدمة DNS Proxy إعادة توجيه آمنة لاستعلامات DNS مع القدرات التالية:

• النقل الآمن: إعادة توجيه اتصالات DNS باستخدام بروتوكول DNS over HTTPS (DoH)، مما يضمن نقلاً مشفّراً للاستعلامات إلى البنية التحتية السحابية لـ Protect
• الحماية من التهديدات: تطبيق ذكاء تهديدات شامل وتصفية أمنية على كل حركة DNS
• دعم النطاقات الداخلية: الحفاظ على توافق كامل مع تحليل النطاقات الداخلية عبر قوائم تجاوز قابلة للتكوين
• أداء عالٍ: معالجة استعلامات مُحسَّنة تدعم حتى 300,000 استعلام في الثانية (QPS) مع العتاد المناسب

2.1.2 جدار حماية DNS المحلي#

يُمكّن Local DNS Firewall من فرض الأمن داخل الموقع بالميزات التالية:

• الفحص المحلي: إجراء تصفية أمنية لـ DNS واكتشاف التهديدات القائم على الذكاء الاصطناعي محلياً دون إعادة توجيه الحركة إلى السحابة
• دعم الامتثال: ضمان السيادة على البيانات ودعم البيئات ذات متطلبات الامتثال الصارمة
• المزامنة ثنائية الاتجاه: الحفاظ على تبادل ثنائي الاتجاه لسجلات DNS وذكاء الأمن مع البنية التحتية السحابية لرؤية مركزية
• التحليل الإحصائي: توفير تحليلات مجمّعة عبر عمليات النشر السحابية وداخل الموقع

2.1.3 موصّل Active Directory#

يُثري موصّل Active Directory سجلات DNS بمعلومات الهوية:

• إسناد المستخدم: استرداد اسم المستخدم ومعلومات النطاق من Active Directory لمسارات تدقيق شاملة
• رؤية محسّنة: تعيين عناوين IP إلى مستخدمين محددين للتقارير والتحقيقات القائمة على الهوية
• تكامل في الوقت الفعلي: معالجة سجلات أحداث أمن Windows (Event ID 4624) في الوقت الفعلي
• نقل عبر syslog: استقبال أحداث المصادقة عبر syslog آمن فوق TLS على منفذ TCP 6514

ℹ️ ملاحظة (NOTE) وظيفة AD Connector متاحة في كلا وضعَي Local Resolver و DNS Forward Proxy.

2.1.4 موصّل سجلات السحابة#

يُسهّل Cloud Logs Connector تكامل السجلات الخارجية:

• استرداد السجلات: استرداد سجلات استعلامات DNS وجدار الحماية من منصة Protect
• ثلاثة تدفقات للسجلات: إرسال أحداث جدار حماية DNS (RPZ)، وسجلات استعلامات DNS، وسجلات تدقيق البوابة كثلاثة تدفقات syslog متمايزة
• CEF عبر Syslog: كل سجل هو رسالة ArcSight CEF متوافقة مع المعايير داخل غلاف syslog بتنسيق RFC 3164 على المِرفق (facility)‏ local4، ومعرَّفة بالهوية Secure Domains | Logs Connector | 1.0.0
• دعم SIEM: تنسيق CEF مدعوم أصلاً في ArcSight و Microsoft Sentinel و Elastic؛ وتتوفر قوالب إعداد جاهزة لـ Splunk و QRadar في الملحق D
• سجلات الامتثال: ضمان الاحتفاظ بسجلات التدقيق لمتطلبات الامتثال التنظيمي

2.2 أوضاع التشغيل#

يدعم المُحلِّل المحلي Protect وضعَيْ تشغيل متمايزَين، كلٌ منهما مصمم لسيناريوهات نشر ومتطلبات تنظيمية محددة.

2.2.1 وضع Local Resolver Proxy#

النموذج التشغيلي (Operational Model)

في وضع Local Resolver Proxy، يعمل جهاز Local Resolver الافتراضي كعامل إعادة توجيه يُرسل استعلامات DNS إلى منصة Protect السحابية للفحص وتطبيق السياسات.

الخصائص الرئيسية (Key Characteristics)

• فرض السياسات في السحابة: يتم تكوين جميع سياسات الأمن وإدارتها وفرضها في البوابة السحابية
• إدارة مركزية: تحديثات السياسات تصبح فعّالة فوراً دون تغييرات تكوين محلية
• قابلية التوسع: الاستفادة من البنية التحتية السحابية لقدرة الفحص
• موارد محلية مُخفّضة: متطلبات ذاكرة أقل مقارنةً بالوضع المحلي (Local Mode)

تدفق معالجة الاستعلامات (Query Processing Flow)

1. تُوجَّه استعلامات DNS من العملاء إلى جهاز Local Resolver الافتراضي (عبر DHCP أو التكوين الثابت)
2. تُعاد توجيه النطاقات الداخلية (قائمة التجاوز) مباشرةً إلى خوادم DNS المحلية
3. تُشفَّر الاستعلامات الخارجية عبر DoH وتُرسل إلى سحابة Protect
4. تطبّق المنصة السحابية سياسات الأمن وذكاء التهديدات
5. تُعاد الاستجابات الآمنة إلى العملاء؛ وتُحجب الاستعلامات الخبيثة
6. تُسجَّل جميع الإجراءات في البوابة السحابية

حالات الاستخدام المثالية (Ideal Use Cases)

• المؤسسات التي تعطي الأولوية لإدارة السياسات المركزية
• البيئات ذات اتصال إنترنت موثوق
• عمليات النشر التي تتطلب الحد الأدنى من تخصيص الموارد المحلية
• عمليات نشر متعددة المواقع مع فرض سياسات متسق

2.2.2 وضع Local Resolver#

النموذج التشغيلي (Operational Model)

في وضع Local Resolver، يُجري الجهاز الافتراضي جميع عمليات فحص DNS والتصفية وفرض السياسات محلياً داخل الموقع، مع مزامنة سحابية اختيارية للرؤية والإدارة.

الخصائص الرئيسية (Key Characteristics)

• فرض السياسات محلياً: تُدفع سياسات الأمن من السحابة لكنها تُنفَّذ محلياً على الجهاز الافتراضي
• السيادة على البيانات: تُعالَج جميع استعلامات وسجلات DNS وتُخزَّن على قرص الجهاز الافتراضي المحلي
• اعتماد سحابي مُخفَّض: الحفاظ على التشغيل أثناء انقطاع اتصال الإنترنت
• متطلبات موارد أعلى: يتطلب ذاكرة إضافية لقواعد بيانات ذكاء التهديدات المحلية

تدفق معالجة الاستعلامات (Query Processing Flow)

1. تُوجَّه استعلامات DNS من العملاء إلى جهاز Local Resolver الافتراضي
2. تُعاد توجيه النطاقات الداخلية (قائمة التجاوز) مباشرةً إلى خوادم DNS المحلية
3. تُفحَص الاستعلامات الخارجية محلياً باستخدام ذكاء التهديدات داخل الموقع
4. يُطبّق محرك جدار الحماية المحلي سياسات الأمن ويحجب التهديدات
5. تُعاد توجيه الاستعلامات النظيفة إلى مُعيدي التوجيه (DNS forwarders) المُكوَّنين
6. تُزامَن السجلات اختيارياً مع السحابة للتقارير المركزية

حالات الاستخدام المثالية (Ideal Use Cases)

• المؤسسات ذات متطلبات الامتثال للسيادة على البيانات
• البيئات التي تتطلب استمرار أمن DNS أثناء انقطاع الإنترنت
• عمليات النشر في المناطق ذات زمن استجابة مرتفع للخدمات السحابية
• المؤسسات التي تُفضّل التحكم المحلي في فرض الأمن

2.3 بنية تدفق الحركة#

2.3.1 تدفق الحركة في وضع Proxy#

المرحلة 1: التحقق من الاتصال السحابي (Phase 1: Cloud Connectivity Validation)

يُجري جهاز Local Resolver الافتراضي فحوصات صحية مستمرة مع البنية التحتية السحابية لـ Protect:

• التحقق المُجدوَل من الاتصال يضمن توفر الخدمة
• المزامنة المنتظمة للتكوين تحافظ على وضع أمني متسق
• التبديل التلقائي للخدمة استناداً إلى حالة الاتصال

المرحلة 2: توجيه استعلامات DNS (Phase 2: DNS Query Routing)

تُكوَّن نقاط نهاية العملاء لاستخدام Local Resolver كخادم DNS الأساسي:

• DHCP Option 6: تتلقى البيئات ذات IP الديناميكي تكوين خادم DNS تلقائياً
• كائنات نهج المجموعة (GPO): نشر تكوين DNS الثابت عبر Active Directory
• التكوين اليدوي: تكوين محطات العمل الفردية بعنوان IP لـ Local Resolver

المرحلة 3: تصنيف الاستعلامات ومعالجتها (Phase 3: Query Classification and Processing)

يُصنِّف Local Resolver الاستعلامات استناداً إلى الوجهة:

• النطاقات الداخلية: الاستعلامات المطابقة لقائمة نطاقات مستثناة تُعاد توجيهها مباشرةً إلى خوادم DNS المعتمدة في الشركة دون فحص
• النطاقات الخارجية: الاستعلامات الموجَّهة إلى الإنترنت تُشفَّر باستخدام بروتوكول DoH وتُرسل إلى خدمات سحابة Protect

المرحلة 4: المعالجة الأمنية السحابية (Phase 4: Cloud Security Processing)

تُجري منصة Protect السحابية تحليلاً أمنياً شاملاً:

• بحث عن ذكاء التهديدات في الوقت الفعلي عبر أكثر من 10 ملايين مؤشر
• تصفية قائمة على الفئات (البرمجيات الخبيثة، التصيد الاحتيالي، المحتوى غير المناسب)
• اكتشاف نفق DNS بقوة الذكاء الاصطناعي
• فرض السياسات استناداً إلى متطلبات الأمن التنظيمية

المرحلة 5: استمرارية الأعمال (Phase 5: Business Continuity)

يضمن النظام توافراً مستمراً لخدمة DNS:

• التبديل التلقائي إلى البنية التحتية المحلية لـ DNS أثناء انقطاع الاتصال السحابي
• تكوين عالي التوافر عبر عمليات نشر متعددة لـ Local Resolver
• التدهور التدريجي يحافظ على وظائف DNS الأساسية

2.3.2 تدفق الحركة في الوضع المحلي#

المرحلة 1: تكوين الأجهزة المُدارة (Phase 1: Endpoint Configuration)

تُكوَّن أجهزة العملاء عبر طرق تعيين خادم DNS القياسية:

• يُحدد DHCP Option 6 جهاز Local Resolver كخادم DNS الأساسي
• يُكوَّن خادم DNS ثانوي للتبديل (جهاز Local Resolver آخر أو DNS الشركة)
• إدارة مركزية لحركة DNS عبر البنية التحتية المحلية

المرحلة 2: تصنيف الاستعلامات (Phase 2: Query Classification)

يُصنّف Local Resolver استعلامات DNS الواردة:

• استعلامات DNS المحلية: الطلبات الموجهة إلى النطاقات الداخلية تُوجَّه مباشرةً إلى خوادم DNS التجاوز المعيّنة دون فحص
• استعلامات DNS الخارجية: الاستعلامات الموجَّهة إلى الإنترنت تخضع لتصفية أمنية محلية

المرحلة 3: المعالجة الأمنية المحلية (Phase 3: Local Security Processing)

يُجري جدار حماية DNS داخل الموقع فحصاً شاملاً:

• اكتشاف التهديدات القائم على الذكاء الاصطناعي يحلّل أنماط الاستعلامات بحثاً عن الشذوذ
• فرض السياسات في الوقت الفعلي دون اعتماد سحابي
• قاعدة بيانات ذكاء التهديدات المحلية توفّر حماية من البرمجيات الخبيثة والتصيد
• تطبيق التصفية القائمة على الفئات وفقاً للسياسات المُكوَّنة

المرحلة 4: تحليل DNS (Phase 4: DNS Resolution)

بعد الفحص الأمني، تُحلَّل الاستعلامات:

• تُعاد توجيه الاستعلامات النظيفة إلى مُعيدي التوجيه المُكوَّنين (مُحلِّلات مزود الإنترنت، أو مزودي DNS العامين، أو DNS الشركة عند المنبع)
• تُعيد الاستعلامات المحجوبة NXDOMAIN أو IP لصفحة الحجب المُكوَّنة
• تُسجَّل جميع الإجراءات محلياً مع مزامنة سحابية اختيارية

المرحلة 5: مزامنة السجلات (Phase 5: Log Synchronization)

تُدار سجلات DNS والأمن وفقاً للتكوين:

• تخزين محلي على قرص الجهاز الافتراضي للوصول الفوري
• تحميل سحابي اختياري للتقارير المركزية والتحليلات
• تصدير syslog خارجي لتكامل SIEM

3. تخطيط ما قبل النشر#

3.1 قائمة التحقق قبل التنفيذ#

أكمل قائمة التحقق التالية قبل بدء النشر لضمان تنفيذ سلس:

الوصول وبيانات الاعتماد#

• تأكيد الوصول إلى بوابة DNS Armor™ Protect (DNS Firewall): https://dnsarmor.secure-domains.org
• التحقق من بيانات اعتماد مسؤول البوابة
• التحقق من صلاحيات إنشاء مفتاح API (الإدارة (Administration) → مفاتيح API (API Keys))

البنية التحتية للشبكة#

• تحديد عنوان IP المستهدف لجهاز Local Resolver الافتراضي
• توثيق معلومات الشبكة الفرعية والبوابة
• تحديد عناوين IP لمُعيدي توجيه DNS (مزود الإنترنت أو DNS العام)
• توثيق عناوين IP لخوادم DNS الداخلية
• اعتماد قواعد جدار الحماية للاتصالات المطلوبة (انظر القسم 3.3.2)

تخطيط النطاقات والسياسات#

• تجميع قائمة النطاقات الداخلية (النطاقات التي تتجاوز الفحص)
• توثيق نطاقات/شبكات فرعية للشبكة الخاصة
• تحديد عناوين IP الخارجية/العامة (لوضع DFP)
• تعريف سياسات أمن DNS (فئات الحجب، موجزات التهديدات)
• تحديد جدول فرض السياسات (24/7 أو قائم على الوقت)

منصة الافتراضية#

• تأكيد منصة المُشرِف الافتراضي (VMware/Hyper-V/KVM)
• اعتماد تخصيص موارد الجهاز الافتراضي (CPU، الذاكرة، القرص حسب جدول التحجيم)
• تحديد مخزن البيانات/التخزين بمساحة 250GB متاحة
• تحضير تكوين الشبكة الافتراضية/VLAN

تكامل Active Directory (إن وُجد)#

• تحديد وحدات تحكم النطاق (Domain Controllers) لإعادة توجيه السجلات
• اختيار أداة إعادة توجيه السجلات (يُوصى بـ NXLog)
• اعتماد قواعد جدار الحماية لـ syslog من DC إلى Resolver (TCP 6514)
• التحقق من صلاحيات سجل الأحداث

تخطيط التوافر العالي (إن وُجد)#

• تحديد عدد الأجهزة الافتراضية لـ Local Resolver (يُوصى باثنين كحد أدنى)
• تقييم موازن الحمل (اختياري، تبديل عميل DNS كافٍ)
• توثيق خطة اختبار التبديل

التكامل والتسجيل#

• تحديد خادم syslog/SIEM خارجي (إن لزم)
• تأكيد اتصال syslog والمنفذ
• توثيق متطلبات الاحتفاظ بالسجلات
• تحديد خادم NTP لمزامنة الوقت

إدارة التغيير#

• اعتماد بطاقة التحكم في التغيير
• جدولة نافذة صيانة التنفيذ
• توثيق خطة التراجع
• إكمال التواصل مع الجهات المعنية
• تحديد مجموعة مستخدمين تجريبية للاختبار الأولي

✅ أفضل ممارسة (BEST PRACTICE) جدولة النشر خلال نافذة صيانة لإتاحة وقت كافٍ للاختبار والتحقق قبل التحويل إلى الإنتاج.

3.2 متطلبات النظام#

3.2.1 المُشرِفات الافتراضية المدعومة#

جهاز المُحلِّل المحلي Protect الافتراضي متوافق مع منصات الافتراضية التالية:

• VMware ESXi: الإصدار 6.5 أو أعلى
• Microsoft Hyper-V: Windows Server 2016 أو أعلى مع تفعيل دور Hyper-V
• KVM/QEMU: الإصدار 2.0 أو أعلى
• أخرى: أي مُشرِف افتراضي يدعم تنسيقات OVA/VMDK القياسية

3.2.2 متطلبات الموارد - الوضع المحلي#

يتطلب وضع Local Resolver تخصيص ذاكرة أعلى للحفاظ على قواعد بيانات ذكاء التهديدات المحلية وإجراء الفحص داخل الموقع.

المصطلحات (Terminology)

• QPS: Queries Per Second - عدد استعلامات DNS التي يستطيع النظام معالجتها
• CHR: Cache Hit Rate - النسبة المئوية للاستعلامات التي تُجاب من ذاكرة التخزين المؤقت (95% نموذجية)

دليل التحجيم (Sizing Guideline)

💡 نصيحة (TIP) حساب سريع: تقريباً كل 5 عناوين IP تُولِّد 1 QPS في المتوسط. فمثلاً، شبكة بـ 500 IP تُولِّد عادةً ~100 QPS كحمل أساسي.

⚡ مهم (IMPORTANT) متطلبات الموارد تفترض معدل إصابة ذاكرة تخزين مؤقت 95%. قد تتطلب البيئات ذات معدلات إصابة أقل موارد إضافية.

3.2.3 متطلبات الموارد - وضع Proxy#

متطلبات الذاكرة لوضع DNS Forward Proxy أقل لأن الفحص الأمني يحدث في السحابة.

✅ أفضل ممارسة (BEST PRACTICE) ابدأ بتكوين 8 vCPU لعمليات النشر النموذجية. وسّع للأعلى أو للأسفل بناءً على أنماط الاستخدام الفعلية المرصودة خلال المرحلة التجريبية.

تخصيص مساحة القرص (Disk Space Allocation)

• نظام التشغيل: ~20 GB
• تخزين السجلات: 180-200 GB (فترة الاحتفاظ تعتمد على حجم الاستعلامات)
• ذكاء التهديدات: ~5GB (الوضع المحلي فقط)
• الحمل العام للنظام: 10 GB محجوزة

3.3 متطلبات الشبكة#

يتطلب كل جهاز Local Resolver افتراضي واجهتي شبكة:

• eth0 — الإدارة (Management): الوصول إلى واجهة الويب (HTTPS 443) وSSH (TCP 22)، والاتصال بالأجهزة الموجودة في الشبكة الفرعية لـ eth0
• eth1 — DNS والإنترنت: استقبال استعلامات DNS من العملاء وحمل جميع الحركة المتجهة إلى الإنترنت (Protect Cloud، وموجزات التهديدات، ومُعيدو توجيه DNS)؛ وتُكوَّن البوابة الافتراضية على eth1

ℹ️ ملاحظة (NOTE) تتم جميع الاتصالات المتجهة إلى الإنترنت عبر eth1. تستخدم الحركة المتجهة إلى الأجهزة في الشبكة الفرعية نفسها لـ eth0 الواجهة eth0، وتستخدم كل الحركة الأخرى eth1.

3.3.1 الاتصالات المطلوبة#

يتطلب جهاز Local Resolver الافتراضي اتصالاً شبكياً بأنظمة مختلفة بحسب الميزات المُفعَّلة:

الاتصالات الإلزامية (Mandatory Connectivity)

• واجهة Management API (HTTPS 443 إلى api.secure-domains.org و api-dev.secure-domains.org) - للإدارة ومزامنة السياسات والفحوصات الصحية
• عناوين IP المخصصة لـ Protect Cloud (HTTPS 443) - لتمرير استعلامات DoH (وضع Proxy فقط)
• توزيع موجزات التهديدات (HTTPS 443 إلى 2ffa7d66f51860e0ce53f4154c49c787.r2.cloudflarestorage.com) - لتنزيل موجزات معلومات التهديدات والتحديثات
• خوادم DNS الداخلية (DNS 53) - لتحليل نطاقات مستثناة
• عملاء DNS (DNS 53) - لاستقبال الاستعلامات من الأجهزة المُدارة

الاتصالات الاختيارية (Optional Connectivity)

• وحدات تحكم النطاق (Syslog/TLS 6514) - لتكامل Active Directory
• خوادم syslog/SIEM الخارجية (متغيرة) - لإعادة توجيه السجلات
• خوادم NTP (NTP 123) - لمزامنة الوقت
• خوادم DNS على الإنترنت (DNS 53، أي وجهة) - الوضع المحلي مع التحليل التكراري (Recursion)
• مُعيدو توجيه DNS (DNS 53) - الوضع المحلي مع مُعيدي توجيه مخصصين (مزود الإنترنت أو خوادم DNS العامة)

3.3.2 قواعد جدار الحماية#

كوّن قواعد جدار الحماية التالية للسماح بتدفقات الحركة المطلوبة. ينبغي توثيق جميع القواعد في طلب تغيير جدار الحماية لديك. حيثما يكون Local Resolver VM هو المصدر أو الوجهة، تظهر بين قوسين الواجهة التي تمر عبرها الحركة (انظر القسم 3.3). ويوضح عمود الوضع (Mode) ما إذا كانت القاعدة تنطبق على وضع Proxy أو الوضع المحلي أو كليهما.

* تُخصَّص عناوين IP الخاصة بـ Protect Cloud لمؤسستك عند إنشاء الحساب.
† eth0 عندما يكون الطرف الآخر في الشبكة الفرعية نفسها لـ eth0، وeth1 في غير ذلك.

⚠️ حرج (CRITICAL) عدم السماح بقاعدة AD Event Logs (من وحدات تحكم النطاق إلى الواجهة eth1 في Local Resolver VM عبر TCP 6514) سيمنع تكامل Active Directory. تأكد من وجود هذه القاعدة قبل محاولة تكوين AD.

3.4 ورقة عمل جمع المعلومات#

أكمل ورقة العمل التالية خلال مرحلة التخطيط. ستكون هذه المعلومات مطلوبة أثناء النشر.

تكوين شبكة الجهاز الافتراضي#

اسم مضيف Local Resolver: ___________________________
عنوان IP لـ eth0 (الإدارة): ___________________________
قناع الشبكة الفرعية لـ eth0 (Subnet Mask): ___________________________
عنوان IP لـ eth1 (DNS والإنترنت): ___________________________
قناع الشبكة الفرعية لـ eth1 (Subnet Mask): ___________________________
البوابة الافتراضية (Default Gateway) على eth1: ___________________________
DNS الأساسي (للجهاز الافتراضي ذاته): ___________________________
DNS الثانوي (للجهاز الافتراضي ذاته): ___________________________

البنية التحتية لـ DNS#

خادم DNS الداخلي 1: ___________________________
خادم DNS الداخلي 2: ___________________________
DNS Forwarder 1: ___________________________
DNS Forwarder 2: ___________________________

نطاقات مستثناة (الداخلية)#

النطاق 1: ___________________________
النطاق 2: ___________________________
النطاق 3: ___________________________
(أضف المزيد حسب الحاجة)

شبكات فرعية للشبكة الخاصة#

الشبكة الفرعية 1: ___________________________ (مثال: 192.168.1.0/24)
الشبكة الفرعية 2: ___________________________ (مثال: 10.0.0.0/16)
الشبكة الفرعية 3: ___________________________

عناوين IP الخارجية/العامة (وضع DFP)#

IP عام 1: ___________________________ (عنوان NAT)
IP عام 2: ___________________________

تكامل Active Directory#

وحدة تحكم النطاق 1: ___________________________
وحدة تحكم النطاق 2: ___________________________
اسم نطاق AD: ___________________________

التسجيل الخارجي (اختياري)#

خادم SIEM/Syslog: ___________________________
منفذ Syslog: ___________________________
بروتوكول Syslog: UDP / TCP / TLS
مِرفق Syslog (الافتراضي local4): ___________________________
منصة SIEM (لقوالب الملحق D): ArcSight / Sentinel / Splunk / QRadar / Elastic / أخرى

التوافر العالي (اختياري)#

IP Local Resolver الثانوي: ___________________________
IP Local Resolver الثالث: ___________________________
VIP لموازن الحمل (إن استُخدم): ___________________________

القسم 4: التثبيت والتكوين (Installation & Configuration)

4. التثبيت والتكوين#

4.1 التحضير قبل التثبيت#

4.1.1 الوصول إلى البوابة#

قبل بدء نشر الجهاز الافتراضي، تحقّق من الوصول إلى بوابة إدارة DNS Armor™ Protect (DNS Firewall):

1. انتقل إلى: https://dnsarmor.secure-domains.org
2. سجّل الدخول ببيانات اعتمادك الإدارية
3. تحقّق من امتلاك صلاحيات الوصول إلى أقسام الإدارة (Administration) وجدار حماية DNS (DNS Firewall) (الإعداد (Setup)، الأمان (Security)، المراقبة (Monitoring))

ℹ️ ملاحظة (NOTE) إن لم يكن لديك وصول إلى البوابة، تواصل مع مسؤول DNS Armor™ أو support@secure-domains.org لطلب بيانات الاعتماد.

4.1.2 تقييم البيئة#

راجع ورقة عمل جمع المعلومات المُكتمَلة (القسم 3.4) وتحقّق من توفر جميع المعلومات المطلوبة:

• تفاصيل تكوين الشبكة (IP، الشبكة الفرعية، البوابة)
• عناوين خوادم DNS (الداخلية ومُعيدو التوجيه)
• قائمة تجاوز النطاقات الداخلية
• نطاقات الشبكة الفرعية لتطبيق السياسات
• توثيق اعتماد قواعد جدار الحماية

4.1.3 تنزيل صورة الجهاز الافتراضي#

نزِّل صورة الجهاز الافتراضي المناسبة لمنصة المُشرِف الافتراضي لديك:

1. سجّل الدخول إلى بوابة Protect: https://dnsarmor.secure-domains.org
2. انتقل إلى: الإدارة (Administration) → التنزيلات (Downloads) وافتح علامة التبويب Local Resolver
3. اختر طراز الجهاز الافتراضي المطابق لبيئتك:
   • VMware ESXi: نزِّل تنسيق OVA (VMware OVA — لـ VMware ESXi وVirtualBox)
   • Microsoft Hyper-V: نزِّل تنسيق VHD/VHDX (Microsoft VHD — لـ Hyper-V وAzure)
   • KVM/QEMU: نزِّل تنسيق QCOW2 (OpenStack QCOW2 — لـ KVM وOpenStack)
4. انقر تنزيل (Download) واحفظ الملف في موقع يمكن الوصول إليه من وحدة تحكم إدارة المُشرِف الافتراضي
5. تحقّق من سلامة الملف المُنزَّل باستخدام المجموع الاختباري المُقدَّم (إن توفر)

ℹ️ ملاحظة (NOTE) توفّر علامة التبويب نفسها ملف Local Resolver MIB (تعريفات مراقبة SNMP) لاستيراده في أنظمة إدارة الشبكات مثل PRTG أو Nagios أو Zabbix أو SolarWinds.

✅ أفضل ممارسة (BEST PRACTICE) نزِّل أحدث إصدار متاح لضمان حصولك على آخر التحديثات الأمنية وتعزيزات الميزات.

4.2 نشر الجهاز الافتراضي#

4.2.1 إنشاء الجهاز الافتراضي#

انشر جهاز المُحلِّل المحلي Protect الافتراضي وفقاً لمنصة المُشرِف الافتراضي لديك:

VMware ESXi

1. افتح vSphere Client أو vCenter
2. انقر بزر الفأرة الأيمن على المضيف/المجموعة المستهدَفة واختر Deploy OVF Template
3. اختر ملف OVA المُنزَّل
4. قدِّم اسماً للجهاز الافتراضي (مثال: "DNS-Armor-Resolver-01")
5. اختر مخزن البيانات الوجهة (تأكّد من توفر 250 GB من المساحة)
6. اختر الشبكة/VLAN المناسبة للجهاز الافتراضي
7. خصّص موارد CPU والذاكرة وفقاً لجدول التحجيم (القسم 3.2)
8. راجع الإعدادات وانقر Finish للنشر

Microsoft Hyper-V

1. افتح Hyper-V Manager
2. انقر New → Virtual Machine
3. حدّد الاسم وموقع ملفات الجهاز الافتراضي
4. اختر Generation 2 (UEFI) أو Generation 1 (BIOS) بناءً على الصورة
5. خصّص الذاكرة وفقاً لجدول التحجيم (فعّل Dynamic Memory إن رغبت)
6. كوِّن الشبكات (الاتصال بمحوّل افتراضي مناسب)
7. اختر Use an existing virtual hard disk واستعرض إلى ملف VHD/VHDX المُنزَّل
8. خصّص عدد CPU وفقاً لجدول التحجيم
9. أكمل المعالج وتحقّق من الإعدادات

KVM/QEMU

1. انسخ صورة QCOW2 إلى موقع تخزين مناسب
2. أنشئ جهازاً افتراضياً جديداً باستخدام virt-manager أو سطر الأوامر:

virt-install \
  --name dns-armor-resolver-01 \
  --memory 32768 \
  --vcpus 4 \
  --disk /path/to/dns-armor.qcow2 \
  --network bridge=br0 \
  --graphics vnc \
  --os-type linux \
  --import

اضبط قيم الذاكرة وCPU وفقاً لجدول التحجيم

⚡ مهم (IMPORTANT) لا تشغّل الجهاز الافتراضي حتى تتحقّق من تكوين الشبكة وتؤكّد أن الجهاز الافتراضي متصل بـ VLAN الصحيح.

4.2.2 الإقلاع الأولي وتسجيل الدخول#

شغّل الجهاز الافتراضي المنشور حديثاً وادخل إلى وحدة التحكم:

1. ابدأ تشغيل الجهاز الافتراضي عبر واجهة إدارة المُشرِف الافتراضي
2. انتظر اكتمال عملية الإقلاع (عادةً 2-3 دقائق)
3. سيظهر طلب تسجيل الدخول على وحدة التحكم

بيانات الاعتماد الافتراضية (Default Credentials)

• اسم المستخدم (Username): admin
• كلمة المرور (Password): secure-domains

⚠️ حرج (CRITICAL) يجب تغيير كلمة المرور الافتراضية فور تسجيل الدخول الأولي. عدم القيام بذلك يمثّل ثغرة أمنية كبيرة.

ℹ️ ملاحظة (NOTE) يحدث تسجيل الدخول الأولي عبر وحدة تحكم الجهاز الافتراضي. سيُكوَّن الوصول إلى واجهة الويب في الخطوات اللاحقة.

4.2.3 تكوين الشبكة#

كوِّن إعدادات الشبكة لجهاز Local Resolver الافتراضي. يحتوي الجهاز على واجهتين: eth0 (الإدارة) وeth1 (DNS والإنترنت)؛ انظر القسم 3.3.

الخيار 1: تكوين DHCP (غير موصى به للإنتاج)

إذا كانت بيئتك تستخدم DHCP وأردت أن يحصل الجهاز الافتراضي على عنوان IP تلقائياً:

• سيحاول الجهاز الافتراضي DHCP على كلتا الواجهتين (eth0 وeth1) عند الإقلاع
• تحقّق من العناوين المُعيَّنة للواجهتين eth0 وeth1 باستخدام: ip addr show
• انتقل إلى القسم 4.2.4

✅ أفضل ممارسة (BEST PRACTICE) استخدم تكوين IP ثابت لخوادم DNS في الإنتاج لضمان تكوين متسق لالأجهزة المُدارة.

الخيار 2: تكوين IP ثابت (موصى به)

لتكوين الشبكة يدوياً:

1. من وحدة تحكم الجهاز الافتراضي، نفّذ سكربت تكوين الشبكة:

sudo ./set_networking

2. يعمل السكربت كمعالج إرشادي (guided wizard): يكوّن أولاً eth0 (الإدارة)، ثم eth1 (DNS والإنترنت)، ثم خوادم DNS التي يستخدمها الجهاز الافتراضي ذاته:

[Step 1 of 3] eth0 - Management interface
Enter eth0 IP Address: [Management IP, e.g., 192.168.100.10]
Enter eth0 Subnet Mask: [e.g., 255.255.255.0]

[Step 2 of 3] eth1 - DNS and Internet interface
Enter eth1 IP Address: [DNS listening IP that clients will use, e.g., 10.10.20.10]
Enter eth1 Subnet Mask: [e.g., 255.255.255.0]
Enter eth1 Default Gateway: [e.g., 10.10.20.1]

[Step 3 of 3] DNS servers for the VM itself
Enter Primary DNS: [e.g., 10.10.20.1]
Enter Secondary DNS (optional): [press Enter to skip]

3. راجع ملخص التكوين للواجهتين
4. أكِّد لتطبيق الإعدادات
5. انتظر إعادة تشغيل خدمة الشبكة (10-15 ثانية)
6. تحقّق من الواجهتين ومن اتصال الشبكة (تخرج الحركة المتجهة إلى الإنترنت عبر eth1):

ip addr show eth0
ip addr show eth1
ping 8.8.8.8
ping dnsarmor.secure-domains.org

⚡ مهم (IMPORTANT) خوادم DNS المُكوَّنة هنا تستخدم بواسطة جهاز Local Resolver الافتراضي ذاته لاتصال الإدارة. ولا تُستخدم كمُعيدي توجيه DNS لاستعلامات العملاء.

ℹ️ ملاحظة (NOTE) لا تُكوَّن بوابة افتراضية على eth0: فهي تصل فقط إلى الأجهزة الموجودة في شبكتها الفرعية (محطات عمل المسؤولين، وأي وحدات تحكم نطاق أو خوادم DNS داخلية أو NTP أو SIEM ضمن تلك الشبكة الفرعية). وتستخدم كل الحركة الأخرى، بما فيها جميع الحركة المتجهة إلى الإنترنت، الواجهة eth1 (انظر القسم 3.3).

4.2.4 الوصول إلى واجهة الويب#

يوفّر جهاز Local Resolver الافتراضي واجهة إدارة قائمة على الويب للتكوين والمراقبة:

1. من محطة عمل المسؤول، افتح متصفح ويب
2. انتقل إلى عنوان الواجهة eth0 (الإدارة): https://[LOCAL_RESOLVER_ETH0_IP] (مثال: https://192.168.100.10)
3. اقبل تحذير الشهادة الموقّعة ذاتياً (يمكنك إضافتها إلى الشهادات الموثوقة)
4. ستظهر صفحة تسجيل الدخول لـ المُحلِّل المحلي لـ DNS Armor™

بيانات اعتماد تسجيل الدخول (Login Credentials)

• اسم المستخدم (Username): admin
• كلمة المرور (Password): secure-domains (ما لم تكن قد غُيِّرت في وحدة التحكم)

5. انقر تسجيل الدخول (Login) للوصول إلى لوحة التحكم

ℹ️ ملاحظة (NOTE) تستخدم واجهة الويب HTTPS على المنفذ 443. تأكّد من أن قواعد جدار الحماية تسمح بالوصول من محطات عمل المسؤولين إلى الواجهة eth0 (الإدارة).

نظرة عامة على لوحة التحكم (Dashboard Overview)

عند تسجيل الدخول بنجاح، تعرض علامة التبويب لوحة التحكم (Dashboard):

• موارد النظام (System Resources): رسوم بيانية للاستخدام الفعلي لـ CPU والذاكرة والقرص
• حالة الخدمة (Service Status): حالة الخدمات الأساسية (DNS Proxy, Firewall, AD Connector)
• إحصائيات سريعة (Quick Statistics): معدل الاستعلامات الحالي، معدل إصابة ذاكرة التخزين المؤقت، الاستعلامات المحجوبة

ℹ️ ملاحظة (NOTE) سيعرض قسم تكوين النظام (System Configuration) المعلومات الكاملة فقط بعد إكمال إعداد البوابة في القسم 4.2.5.

4.2.5 تكوين إعداد النظام#

يُنشئ قسم إعداد النظام (System Setup) الاتصال بين جهاز Local Resolver الافتراضي وبوابة إدارة Protect السحابية.

4.2.5.1 تكوين مفتاح API (API Key Configuration)

يُصادق مفتاح API لـ Local Resolver مع البوابة السحابية ويُمكِّن مزامنة السياسات:

1. في واجهة ويب Local Resolver، انتقل إلى: علامة التبويب إعداد النظام (System Setup)
2. حدّد موقع حقل مفتاح API (API Key) (فارغ حالياً)

3. افتح علامة تبويب جديدة في المتصفح وسجّل الدخول إلى بوابة Protect: https://dnsarmor.secure-domains.org
4. انتقل إلى: الإدارة (Administration) → مفاتيح API (API Keys) (الصفحة نفسها معنونة رموز API (API Codes))
5. انقر إنشاء رمز API (Create API Code)
6. اختر العميل (Customer) (أو الموزّع (Reseller)) والمستأجر (Tenant) الذي ينتمي إليه هذا Local Resolver وأكِّد
7. انسخ رمز API المعروض فوراً باستخدام زر النسخ إلى الحافظة (copy-to-clipboard)

⚠️ حرج (CRITICAL) يُعرض رمز API الكامل مرة واحدة فقط — وبعد ذلك تبقى آخر 4 أحرف منه فقط ظاهرة في البوابة. خزّنه بأمان في نظام إدارة كلمات المرور لديك. في حال فقدانه، استخدم إعادة تعيين رمز API (Reset API Code) في صفحة رموز API (API Codes) لتوليد بديل (يُبطِل هذا الإجراء الرمز الحالي فوراً).

8. عُد إلى واجهة ويب Local Resolver
9. الصق رمز API في حقل مفتاح API (API Key)
10. سيُخفى المفتاح للأمان بعد الحفظ

ℹ️ ملاحظة (NOTE) يستطيع كل مستأجر (tenant) الاحتفاظ بما يصل إلى 3 رموز API للمرونة التشغيلية ولتدوير الرموز.

4.2.5.2 تكوين المعرّف الفريد (Unique Identifier Configuration)

المعرّف الفريد (Unique Identifier) هو تسمية يحدّدها العميل تربط جهاز Local Resolver هذا بسياسات في البوابة السحابية:

1. في حقل المعرّف الفريد (Unique Identifier)، أدخل معرّفاً ذا معنى
   • مثال: "SITE-NYC-RESOLVER-01"
   • مثال: "HQ-DNS-PRIMARY"
2. استخدم الحروف والأرقام والشَرطات والشَرطات السفلية فقط (دون مسافات)
3. يجب أن يتطابق هذا المعرّف تماماً عند إنشاء السياسات في البوابة

⚡ مهم (IMPORTANT) المعرّف الفريد حسّاس لحالة الأحرف ويجب إدخاله بشكل متطابق في تكوين سياسة البوابة السحابية.

4. انقر حفظ (Save) لتثبيت مفتاح API والمعرّف الفريد
5. سيتحقّق النظام من الاتصال بالبوابة السحابية
6. تؤكّد رسالة النجاح التسجيل الناجح
7. ستعرض لوحة التحكم الآن تفاصيل التكوين المُزامَنة

✅ أفضل ممارسة (BEST PRACTICE) استخدم اصطلاح تسمية متسقاً للمعرّفات الفريدة عبر مؤسستك (مثال: SITE-LOCATION-FUNCTION-INSTANCE).

4.2.6 تكوين معالجة السجلات#

كوِّن إعدادات معالجة السجلات والمزامنة:

انتقل إلى: قسم إعداد النظام (System Setup) → معالجة السجلات والمزامنة (Log Processing & Sync)

خيارات مزامنة السجلات (Log Synchronization Options)

الخيار 1: إرسال جميع السجلات التاريخية (افتراضي) (Send All Historical Logs)

• يُرسل جميع سجلات DNS وجدار الحماية من بداية تشغيل Local Resolver
• استخدم هذا الخيار لعمليات النشر الجديدة لضمان رؤية كاملة للسجلات
• قد تستغرق المزامنة الأولية وقتاً بحسب حجم الاستعلامات

الخيار 2: تاريخ بدء مخصّص (Custom Start Date)

• ابدأ معالجة السجلات من تاريخ/وقت محدد
• مفيد لعمليات النشر المرحلية أو عند عدم الحاجة إلى البيانات التاريخية
• اختر التاريخ باستخدام عنصر التحكم في منتقي التاريخ

تكوين Syslog الخارجي (اختياري) (External Syslog Configuration)

لإعادة توجيه السجلات إلى خادم syslog خارجي أو SIEM:

1. فعّل إرسال السجلات إلى خادم Syslog خارجي (Send Logs to External Syslog Server)
2. أدخل التفاصيل التالية:
   • عنوان IP/اسم مضيف خادم Syslog (Syslog Server IP/Hostname): خادم syslog الوجهة
   • المنفذ (Port): عادةً 514 (UDP)، 1514 (TCP)، أو 6514 (TLS)
   • البروتوكول (Protocol): اختر UDP أو TCP أو TLS بناءً على متطلبات الخادم
   • التنسيق (Format): اختر تأطير syslog — ‏RFC 3164 (الافتراضي) أو RFC 5424 (يحافظ على السنة ودقة الميلي ثانية في الطابع الزمني)
3. انقر اختبار الاتصال (Test Connection) للتحقق من الاتصال
4. انقر حفظ (Save) لتطبيق التكوين

ما الذي يرسله المُحلِّل (What the Resolver Sends)

كل سجل يُعاد توجيهه هو رسالة ArcSight CEF متوافقة مع المعايير داخل غلاف syslog:

<166>Aug  5 00:14:07 secure-domains-local-resolver dns-rpz: CEF:0|Secure Domains|Logs Connector|1.0.0|1001|DNS RPZ|7|rt=… dhost=… src=… cs4Label=TenantName cs4=…

• المِرفق (Facility): ‏local4 افتراضياً، لذا فإن قيمة PRI الافتراضية هي <166> (المِرفق local4 = ‏20 × 8 + الخطورة info = ‏6). وجِّه أي مرشِّح مِرفق على جانب المُجمِّع إلى local4.
• خطورة syslog: مثبَّتة عمداً على info لكل سجل. تكمن خطورة كل حدث في الحقل السابع من ترويسة CEF ‏(7 لسجلات RPZ، و2 للاستعلامات، و5 للتدقيق) — وهو المكان الذي تقرأ منه جميع منصات SIEM. لو تغيّرت خطورة syslog أيضاً، فإن مُجمِّعاً يرشِّح على local4.info سيُسقط بصمت سجلات RPZ عالية الخطورة، وهي بالضبط الأحداث الأهم لك.
• هوية المصدر: تحمل ترويسة CEF الهوية Secure Domains | Logs Connector | 1.0.0. تعتمد منصات SIEM على زوج المورّد + المنتج لاختيار المُحلِّل ومصدر السجلات — وهي عقد ثابت لن يتغيّر.

تدفقات السجلات (Log Streams)

تُرسَل ثلاثة تدفقات مستقلة، تتمايز بوسم syslog ‏(TAG) وبمعرّف CEF ‏(SignatureID):

يتوفر المخطط الكامل حقلاً بحقل، وسجلات نموذجية مطابقة بالبايت، وقواعد التحليل، وقوالب الإعداد الجاهزة لكل من ArcSight و Microsoft Sentinel و Splunk و QRadar و Elastic في الملحق D: حزمة تكامل SIEM.

⚡ مهم (IMPORTANT) فضّل النقل عبر TCP أو TLS أو RELP. يبلغ حجم سجلات RPZ نحو 650 بايت وقد تتجاوز الحد العملي البالغ 1024 بايت لتنسيق RFC 3164 عبر UDP؛ يحدث الاقتطاع بصمت، وسجل CEF المقتطع يفشل تحليله كلياً.

✅ أفضل ممارسة (BEST PRACTICE) استخدم syslog فوق TLS (المنفذ 6514) عند نقل السجلات عبر شبكات غير موثوقة لضمان سرية وسلامة السجلات.

4.2.7 إعدادات الشبكة#

راجع وكوِّن إعدادات الشبكة لـ Local Resolver:

انتقل إلى: علامة التبويب الشبكة (Network)

تكوين عنوان IP (IP Address Configuration)

• يعرض عناوين IP المُكوَّنة حالياً للواجهتين eth0 وeth1 في Local Resolver
• للتعديل، استخدم سكربت set_networking المستند إلى وحدة التحكم (القسم 4.2.3)

مُعيدو توجيه DNS (DNS Forwarders)

مُعيدو توجيه DNS هم خوادم DNS عند المنبع التي ستتلقى الاستعلامات بعد الفحص الأمني:

• الوضع المحلي (Local Mode): تُعاد توجيه الاستعلامات هنا بعد الفحص المحلي
• وضع Proxy (Proxy Mode): هذا الإعداد لا يُستخدم عادةً (تذهب الاستعلامات إلى السحابة)

خيارات شائعة لمُعيدي توجيه DNS (Common DNS Forwarder Options)

• خوادم DNS لمزود الإنترنت: استخدم مُحلِّلات مزود خدمة الإنترنت لديك
• DNS العام: Google (8.8.8.8, 8.8.4.4)، Cloudflare (1.1.1.1)، Quad9 (9.9.9.9)
• DNS الشركة: خوادم DNS الداخلية عند المنبع
• Protect Cloud Resolvers: لطبقة إضافية من الحماية السحابية

1. أدخل عنوان IP لمُعيد توجيه DNS الأساسي
2. أدخل عنوان IP لمُعيد توجيه DNS الثانوي (موصى به)
3. انقر حفظ (Save) لتطبيق التكوين

⚡ مهم (IMPORTANT) يجب أن يكون مُعيدو توجيه DNS قابلين للوصول من جهاز Local Resolver الافتراضي. تحقّق من أن قواعد جدار الحماية تسمح بـ DNS الصادر (المنفذ 53) إلى هذه الخوادم.

4.2.8 مزامنة الوقت (NTP)#

مزامنة الوقت الدقيقة حرجة لربط السجلات والتحقق من الشهادات واستكشاف الأخطاء:

انتقل إلى: علامة التبويب NTP

أهمية تكوين NTP (Importance of NTP Configuration)

• الطوابع الزمنية للسجلات: تضمن الترتيب الزمني الدقيق للأحداث
• التحقق من الشهادات: شهادات SSL/TLS حسّاسة للوقت
• جدولة السياسات: السياسات القائمة على الوقت تتطلب وقت نظام دقيقاً
• التحليل الجنائي: ربط الأحداث عبر أنظمة متعددة
• المزامنة السحابية: تمنع مشاكل المزامنة بسبب انحراف الوقت

خوادم NTP الموصى بها (Recommended NTP Servers)

خوادم NTP العامة (Public NTP Servers)

• time.google.com - Google Public NTP
• pool.ntp.org - NTP Pool Project
• time.nist.gov - US NIST Time Service
• time.windows.com - Microsoft Time Service

خوادم NTP الداخلية (Internal NTP Servers)

• وحدات تحكم النطاق لديك (إن كانت مُكوَّنة كمصادر وقت)
• أجهزة NTP داخلية مخصّصة
• خدمات NTP لأجهزة الشبكة

خطوات التكوين (Configuration Steps)

1. انقر إضافة خادم NTP (Add NTP Server)
2. أدخل اسم مضيف خادم NTP أو عنوان IP
3. كرّر لإضافة خوادم إضافية (يُوصى بـ 3-4 للتكرار)
4. انقر حفظ التغييرات (Save Changes)
5. تحقّق من أن حالة المزامنة تظهر "Synced" بعد 1-2 دقيقة

✅ أفضل ممارسة (BEST PRACTICE) كوِّن 3 خوادم NTP على الأقل للتكرار. اخلط بين المصادر الداخلية والخارجية لضمان استمرار المزامنة أثناء انقطاع الإنترنت.

4.2.9 إدارة كلمات المرور#

غيِّر كلمة مرور المسؤول الافتراضية لتأمين Local Resolver:

انتقل إلى: علامة التبويب كلمة المرور (Password)

⚠️ حرج (CRITICAL) تغيير كلمة المرور الافتراضية إلزامي لنشر الإنتاج. بيانات الاعتماد الافتراضية موثّقة علنياً وتمثّل ثغرة أمنية حرجة.

متطلبات كلمة المرور (Password Requirements)

• الحد الأدنى 12 حرفاً (يُوصى بـ 16+)
• تتضمن أحرفاً كبيرة وصغيرة
• تتضمن أرقاماً
• تتضمن رموزاً خاصة
• لا تُعد استخدام كلمات مرور من أنظمة أخرى
• لا تستخدم كلمات قاموس شائعة

إجراء تغيير كلمة المرور (Change Password Procedure)

1. أدخل كلمة المرور الحالية: secure-domains (إن لم تُغيّر بعد)
2. أدخل كلمة المرور الجديدة المستوفية لمتطلبات التعقيد
3. أكِّد كلمة المرور الجديدة بإدخالها مرة أخرى
4. انقر تغيير كلمة المرور (Change Password)
5. سيتم تسجيل خروجك تلقائياً
6. سجّل الدخول مجدداً ببيانات الاعتماد الجديدة للتحقق

✅ أفضل ممارسة (BEST PRACTICE) خزّن كلمة المرور الجديدة في نظام إدارة كلمات المرور الخاص بمؤسستك (مثال: HashiCorp Vault، LastPass Enterprise، 1Password). لا تخزّن كلمات المرور في توثيق نصي عادي.

💡 نصيحة (TIP) ضع في الاعتبار تنفيذ تدوير كلمات المرور كل 90 يوماً وتأكّد من أن مسؤولين متعددين لديهم وصول عبر نظام إدارة كلمات المرور.

4.3 تكوين السياسات - وضع Local Resolver#

يُجري وضع Local Resolver فحص أمن DNS وفرض السياسات محلياً على الجهاز الافتراضي. تُكوَّن السياسات في البوابة السحابية وتُزامَن مع Local Resolver للتنفيذ المحلي.

4.3.1 إنشاء الشبكة الخاصة#

تُحدّد الشبكات الخاصة (Private Networks) شبكات IP فرعية داخلية حيث ستُطبَّق سياسات أمن DNS. يُتيح ذلك التحكم في السياسات على مستوى الشبكة الفرعية.

1. سجّل الدخول إلى بوابة Protect: https://dnsarmor.secure-domains.org
2. انتقل إلى: جدار حماية DNS → الإعداد (DNS Firewall → Setup) → الشبكات (Networks) واختر علامة التبويب الشبكات الخاصة (Private Networks)
3. انقر إنشاء شبكة (Create Network)

4. كوِّن الشبكة الخاصة:
   • العميل / المستأجر (Customer / Tenant): اختر العميل (أو الموزّع (Reseller)) والمستأجر الذي تنتمي إليه هذه الشبكة (في البيئات متعددة المستأجرين)
   • وصف الشبكة (Network Description): اسم وصفي (مثال: "Corporate-LAN"، "Guest-WiFi")
   • عنوان (عناوين) الشبكة (Network Address(es)): شبكة (شبكات) IP فرعية بترميز CIDR، تُدخَل واحدة في كل سطر أو مفصولة بفواصل؛ يُدعَم كلٌّ من IPv4 وIPv6 ويمكن الجمع بينهما في إرسال واحد (مثال: 192.168.1.0/24، 10.0.0.0/16، 2001:db8::/32)

5. انقر إنشاء شبكة خاصة (Create Private Network) لحفظ الشبكة الخاصة
6. كرّر للقطاعات الشبكية الإضافية التي تتطلب سياسات مختلفة

أمثلة على حالات الاستخدام (Use Case Examples)

• Corporate-Workstations (192.168.10.0/24): سياسات أمن المستخدمين القياسية
• Guest-Network (192.168.99.0/24): سياسات تقييدية، وصول محدود
• IT-Department (192.168.20.0/24): سياسات مرنة للموظفين التقنيين
• Lab-Environment (10.50.0.0/16): سياسات مخصّصة للتطوير/الاختبار

ℹ️ ملاحظة (NOTE) لا تُستخدم الشبكات الخارجية (External Networks) في وضع Local Resolver. تُحدّد الشبكات الخارجية عناوين IP العامة وتكون ذات صلة فقط في وضع DNS Forward Proxy.

⚡ مهم (IMPORTANT) لا يمكن حذف الشبكات المُستخدَمة. ترفض البوابة حذف شبكة خاصة مرتبطة بسياسة أمان أو مُشار إليها في تعيين موجزات شبكة لمُحلِّل محلي (Local Resolver network feed mapping)، وتعرض خطأً واضحاً يذكر السياسات أو المُحلِّلات التي تستخدمها. أزِل تلك المراجع أولاً، ثم احذف الشبكة.

4.3.2 إنشاء سياسة Local Resolver#

أنشئ سياسة Local Resolver الأساسية التي تُحدّد المعاملات التشغيلية:

1. انتقل إلى: جدار حماية DNS → الإعداد (DNS Firewall → Setup) → Local Resolver
2. انقر إنشاء Local Resolver (Create Local Resolver)

الخطوة 1: اختيار وضع التشغيل (Step 1: Operating Mode Selection)

1. في قسم وضع المُحلِّل (Resolver Mode)، اختر مُحلِّل محلي (Local Resolver)

ℹ️ ملاحظة (NOTE) يفرض وضع Local Resolver السياسات محلياً على الجهاز الافتراضي. تُدار التكوينات في البوابة السحابية لكن التنفيذ يحدث داخل الموقع.

الخطوة 2: تفاصيل السياسة (Step 2: Policy Details)

1. كوِّن إعدادات السياسة الأساسية:

• العميل / المستأجر (Customer / Tenant): اختر العميل والمستأجر الذي تنطبق عليه هذه الإعدادات
• المعرّف الفريد (Unique Identifier): أدخل المعرّف بالضبط كما هو مُكوَّن على جهاز Local Resolver الافتراضي (القسم 4.2.5.2)
  • يربط هذا المعرّف السياسة بالجهاز الافتراضي المحدد
  • يجب أن يتطابق تماماً (حسّاس لحالة الأحرف)
  • مثال: "SITE-NYC-RESOLVER-01"

⚠️ حرج (CRITICAL) إذا لم يتطابق المعرّف الفريد تماماً، فلن تُدفع السياسة إلى Local Resolver ولن يعمل فرض الأمن.

2. انقر التالي (Next) للمتابعة عبر بقية خطوات المعالج (الشبكة والأمان، إدارة التغذيات، الإعدادات المتقدمة)

4.3.3 تكوين نطاقات مستثناة#

نطاقات مستثناة (Bypass Domains) هي نطاقات داخلية ينبغي أن تُحلّ مباشرةً بواسطة خوادم DNS المحلية دون فحص أمني:

نطاقات مستثناة (Bypass Domains)

1. في قسم نطاقات مستثناة (Bypass Domains)، أضف النطاقات الداخلية:
   • تنسيق النطاق (Domain Format): أدخل أسماء نطاقات مؤهَّلة بالكامل أو نطاقات أُمّ
   • أمثلة:
     • corp.local - جميع المضيفين ضمن نطاق corp.local
     • internal.company.com - جميع المضيفين ضمن نطاق internal.company.com
     • dc01.corp.local - وحدة تحكم نطاق محددة
     • lab.local - بيئة الاختبار/التطوير
2. أدخِل كل نطاق داخلي في سطر مستقل (نطاق واحد في كل سطر)
3. راجع قائمة التجاوز للتأكد من اكتمالها

💡 نصيحة (TIP) يمكن تعريف نطاقات التجاوز بشكل مضمَّن لهذا المُحلِّل (تعريف مضمَّن (Define Inline)) أو ربطها بإعداد تجاوز مشترك (الربط بإعداد تجاوز (Link to Bypass Config)) يُدار مركزياً ضمن جدار حماية DNS → الإعداد (DNS Firewall → Setup) → النطاقات المستثناة (Bypass Domains). استخدم إعداداً مشتركاً عندما تحتاج عدة مُحلِّلات إلى نفس قائمة النطاقات الداخلية.

خوادم DNS التجاوز (Bypass DNS Servers)

1. كوِّن خوادم DNS التي ستحلّ نطاقات مستثناة:
   • الخادم 1 (Server 1): خادم DNS الداخلي الأساسي (مثال: وحدة تحكم النطاق)
   • الخادم 2 (Server 2): خادم DNS الداخلي الثانوي (موصى به)
   • أمثلة:
     • 192.168.1.10 - وحدة تحكم النطاق الأساسية
     • 192.168.1.11 - وحدة تحكم النطاق الثانوية

⚡ مهم (IMPORTANT) يجب أن تكون خوادم DNS التجاوز قابلة للوصول من جهاز Local Resolver الافتراضي. تكون عادةً وحدات تحكم النطاق أو البنية التحتية لـ DNS الداخلية.

تكوين Syslog (اختياري) (Syslog Configuration)

1. في حال إعادة توجيه السجلات إلى خادم SIEM/syslog خارجي:
   • خادم Syslog (Syslog Server): عنوان IP أو اسم مضيف جامع السجلات
   • منفذ Syslog (Syslog Port): المنافذ القياسية (514 UDP، 1514 TCP، 6514 TLS)
   • البروتوكول (Protocol): اختر UDP أو TCP أو TLS (فضّل TCP/TLS — قد تتجاوز سجلات RPZ حد 1024 بايت لتنسيق RFC 3164 عبر UDP)
   • التنسيق (Format): ‏RFC 3164 (الافتراضي) أو RFC 5424 (يحافظ على السنة ودقة الميلي ثانية)

ℹ️ ملاحظة (NOTE) تُرسَل السجلات بتنسيق ArcSight CEF على المِرفق local4 عبر ثلاثة تدفقات (DNS RPZ 1001، وDNS Query 1002، وAudit 1003). راجع القسم 4.2.6 لنظرة عامة على التنسيق والملحق D لمرجع الحقول وقوالب إعداد SIEM.

✅ أفضل ممارسة (BEST PRACTICE) استخدم syslog فوق TLS (المنفذ 6514) لحماية سرية السجلات أثناء النقل.

4.3.4 تكوين مُعيدي توجيه DNS#

مُعيدو توجيه DNS هم الخوادم عند المنبع التي تُرسل إليها استعلامات DNS النظيفة بعد الفحص الأمني المحلي:

1. في قسم موجِّهات DNS (الوضع المحلي) (DNS Forwarders (Local Mode))، انقر إضافة موجِّه (Add Forwarder) وأدخل عنوان IP لكل خادم DNS عند المنبع (يُوصى باثنين على الأقل للتكرار)

ℹ️ ملاحظة (NOTE) بدلاً من ذلك، فعّل تفعيل التكرار العودي لـ DNS (Enable DNS Recursion) للسماح للمُحلِّل بإجراء التحليل العودي الكامل بنفسه؛ وعندما يكون التكرار العودي لـ DNS مُعطَّلاً، يلزم موجِّه DNS واحد على الأقل. ويمكن تفعيل التحقق من DNSSEC للإجابات القادمة من المنبع عبر تفعيل التحقق من DNSSEC (Enable DNSSEC Validation).

خيارات مُعيدي توجيه شائعة (Common Forwarder Options)

• DNS مزود الإنترنت: مُحلِّلات مزود خدمة الإنترنت لديك
• DNS العام: 8.8.8.8 (Google)، 1.1.1.1 (Cloudflare)، 9.9.9.9 (Quad9)
• الشركة عند المنبع: البنية التحتية الحالية لـ DNS الشركة
• Protect Cloud: لطبقة حماية سحابية إضافية

2. انقر التالي (Next) للمتابعة إلى إدارة التغذيات

4.3.5 تعيينات موجزات الشبكة وقواعد الفحص#

تُحدِّد تعيينات موجزات الشبكة (Network Feed Mappings) أيّ سياسات الأمن تنطبق على أيّ قطاعات الشبكة:

إنشاء تعيين موجزات شبكة (Create Network Feed Mapping)

1. في قسم تعيينات موجزات الشبكة (Network Feed Mappings)، انقر إضافة تعيين شبكة (Add Network Mapping)
2. اختر الشبكة الخاصة (Select Private Network):
   • اختر الشبكة الخاصة (الشبكة الفرعية) حيث ينطبق هذا التعيين
   • يمكن إنشاء تعيينات متعددة لشبكات فرعية مختلفة
   • بدِّل بين الشبكة مُفعَّلة / الشبكة مُعطَّلة (Network Enabled / Network Disabled) و(اختيارياً) استخدام ECS (Use ECS) لكل تعيين
3. وضع التطبيق (Enforcement Mode): اختر كيفية التعامل مع المطابقات لهذه الشبكة:
   • حجب (Blocking): تُحجب المطابقات فعلياً
   • تسجيل (Logging): تُسجَّل المطابقات فقط دون حجبها (وضع المراقبة)
4. إجراء التجاوز (Override Action): افتراضي (Default) (تُطبِّق كل قاعدة/مجموعة قواعد إجراءها الخاص) أو إعادة توجيه (Redirect) إلى نطاق / IP لإعادة التوجيه (Redirect Domain / IP) محدد (صفحة الحجب). تأتي إجراءات كل قاعدة من مجموعات القواعد المحلية المُرفقة: NXDOMAIN (Block)، DROP، PASSTHRU (Allow)، REDIRECT
5. خصِّص موجزات الحماية لهذا التعيين (يظهر كل موجز مُرفق في قائمة ترتيب أولوية الموجزات (Feed Priority Order) لهذه الشبكة، حيث يمكن سحبه لإعادة ترتيبه):

التهديدات (Threats)

تحمي فئة موجز التهديدات (Threats) من جملة أمور، منها:

• نطاقات البرمجيات الخبيثة (Malware Domains): حجب خوادم القيادة والتحكم المعروفة للبرمجيات الخبيثة
• مواقع التصيد الاحتيالي (Phishing Sites): حجب نطاقات حصاد بيانات الاعتماد والتصيد
• برامج الفدية C2 (Ransomware C2): حجب قنوات اتصال برامج الفدية
• التعدين السيبراني (Cryptomining): حجب التعدين الخفي والتعدين غير المصرّح به
• الشبكات الروبوتية (Botnets): حجب البنية التحتية للقيادة والتحكم في الشبكات الروبوتية

ℹ️ ملاحظة (NOTE) يحتفظ Protect بأكثر من 10 ملايين مؤشر تهديد تُحدَّث باستمرار من مصادر ذكاء التهديدات العالمية.

الحماية من نفق DNS (DNS Tunneling Protection)

• فعّل كشف التهديدات المتقدم بالذكاء الاصطناعي لهذه الشبكة (Advanced AI Threat Detection for this Network) لتحديد محاولات تسريب البيانات
• يكتشف التحليل القائم على الذكاء الاصطناعي نفق DNS ونطاقات fast-flux وهجمات التسلل — ويؤدي تفعيله إلى تطبيق موجزات AI Tunneling Detection وAI FastFlux Detection وAI Infiltration Detection تلقائياً
• يحجب القنوات المخفية غير المصرّح بها عبر بروتوكول DNS

مرشحات الويب (تصفية فئات URL) (Web Filters (URL Category Filtering))

• خصِّص مرشحات الويب (Web Filters) لحجب الوصول حسب فئة الموقع (مثال: محتوى للبالغين، قمار، برمجيات خبيثة)
• فرض سياسات الاستخدام المقبول
• تشمل الفئات:
  • محتوى للبالغين/إباحي (Adult/Pornography)
  • قمار (Gambling)
  • مخدرات/مواد غير قانونية (Drugs/Illegal Substances)
  • أسلحة (Weapons)
  • خطاب الكراهية (Hate Speech)
  • وسائل التواصل الاجتماعي (اختياري) (Social Media)
  • وسائط البث (اختياري) (Streaming Media)
  • ألعاب (اختياري) (Gaming)
  • الإنتاجية/الأعمال (قائمة سماح) (Productivity/Business)

أنواع موجزات إضافية متاحة لكل تعيين: التطبيقات (Apps) (حجب التطبيقات)، والتصفية الجغرافية (Geo Filtering)، وموجزات RPZ الخارجي (External RPZ) (تُدار ضمن جدار حماية DNS → الأمان (DNS Firewall → Security) → الموجزات المؤتمتة (Automated Feeds))، ومجموعات القواعد المحلية (Local Rulesets)، وقائمة السماح الحصرية (Exclusive Allowlist) (تحجب كل استعلام باستثناء النطاقات المسموح بها صراحةً في مجموعة القواعد المختارة).

6. إعدادات الجدولة (اختياري) (Schedule Settings):

حدِّد متى يكون التطبيق نشطاً:

• نشط دائماً (Always active): فرض 24/7 (افتراضي)
• التفعيل الزمني (Time-based activation): قصر الفرض على أيام أسبوع ونطاقات زمنية محددة (مثال: 08:00-18:00، الإثنين-الجمعة). استخدم الإعدادات المسبقة السريعة (Quick Presets) — ساعات العمل (Business Hours) (الإثنين-الجمعة، 09:00-17:00 UTC)، أيام الأسبوع (Weekdays) (الإثنين-الجمعة، طوال اليوم)، عطلات نهاية الأسبوع (Weekends) (السبت-الأحد، طوال اليوم) — أو اختر أيام التفعيل (Active Days) ونطاق وقت التفعيل (Active Time Range (UTC)) مخصّصَين، مع نطاق تاريخ (Date Range) اختياري

أمثلة على الجداول (Example Schedules)

• حجب وسائل التواصل الاجتماعي خلال ساعات العمل (الإثنين-الجمعة 09:00-17:00 UTC)
• سياسات مرنة خلال عطلات نهاية الأسبوع
• مراقبة محسّنة خلال ساعات خارج العمل

تجاوزات النطاقات المخصّصة (اختياري) (Custom Domain Overrides)

تجاوز تصنيفات الفئات لنطاقات محددة باستخدام مجموعات القواعد:

• قواعد السماح (مجموعة قواعد محلية، الإجراء PASSTHRU) (Allow rules (Local Ruleset)): السماح بنطاق رغم حجب الفئة
  • مثال: السماح بـ linkedin.com حتى لو كانت وسائل التواصل الاجتماعي محجوبة
• قواعد الحجب (مجموعة قواعد محلية، الإجراء NXDOMAIN / DROP / REDIRECT) (Block rules (Local Ruleset)): حجب نطاق رغم سماح الفئة
  • مثال: حجب موقع قمار محدد غير موجود في الموجزات
• قائمة السماح الحصرية (Exclusive Allowlist): حجب كل استعلامات DNS باستثناء المسموح بها صراحةً في مجموعة القواعد المختارة

انظر القسم 4.3.7 لإنشاء مجموعات القواعد.

ترتيب أولوية الموجزات (Feed Priority Order)

⚡ مهم (IMPORTANT) تُقيَّم الموجزات المُرفقة بالشبكة بالترتيب. استخدم السحب والإفلات (أو زرَّي النقل إلى الأعلى (Move to top) / النقل إلى الأسفل (Move to bottom)) في قائمة ترتيب أولوية الموجزات لهذه الشبكة (Feed Priority Order for this Network) لإعادة ترتيبها:

• ينبغي أن تكون الموجزات/مجموعات القواعد الأكثر تحديداً في الأعلى
• ينبغي أن تكون الموجزات الواسعة في الأسفل
• ينبغي أن تسبق مجموعاتُ قواعد السماح (PASSTHRU) مجموعاتِ قواعد الحجب
• استخدم قواعد السماح في مجموعات القواعد للاستثناءات المحددة بدلاً من تعطيل موجزات بأكملها
• أبقِ تصفية الفئات الواسعة قائمة وأدِر الاستثناءات لكل نطاق
• عند تفعيل قائمة السماح الحصرية، تُعطَّل الموجزات الأخرى وإجراء التجاوز لهذا التعيين — ويُحجب كل ما لم يُسمح به صراحةً

انقر التالي (Next) للمتابعة إلى الخدمات الإضافية

4.3.6 موصّل Active Directory وسجلات السحابة#

كوِّن خدمات اختيارية لتعزيز الرؤية في خطوة الإعدادات المتقدمة (Advanced Settings):

موصّل Active Directory (Active Directory Connector)

فعّل تكامل Active Directory لإثراء السجلات بمعلومات هوية المستخدم:

1. حدِّد تفعيل موصّل Active Directory (Enable Active Directory Connector)
2. يُمكِّن هذا Local Resolver من استقبال سجلات مصادقة Windows
3. تفاصيل التكوين مغطّاة في القسم 5 (تكامل Active Directory)

فوائد تكامل AD (Benefits of AD Integration)

• تعيين عناوين IP إلى أسماء المستخدمين في سجلات DNS
• تحديد المستخدمين الذين وصلوا إلى نطاقات محجوبة أو مشبوهة
• دعم فرض السياسات القائمة على الهوية (مستقبلاً)
• تعزيز قدرات التحقيق الجنائي

تحميل سجلات السحابة (Cloud Logs Upload)

فعّل مزامنة السجلات إلى بوابة Protect السحابية:

1. حدِّد تفعيل تحميل سجلات السحابة (Enable Cloud Logs Upload) (متاح في وضع Local Resolver فقط)
2. يُكوِّن التحميل التلقائي لسجلات DNS وجدار الحماية إلى السحابة
3. يُمكّن التقارير المركزية عبر Local Resolvers متعددة
4. يوفّر الوصول إلى التحليلات ولوحات التحكم القائمة على السحابة

فوائد تحميل السجلات إلى السحابة (Benefits of Cloud Log Upload)

• رؤية مركزية عبر جميع عمليات نشر Local Resolver
• تقارير وتحليلات قائمة على السحابة
• احتفاظ طويل الأمد بالسجلات في التخزين السحابي
• ربط التهديدات عبر المواقع
• نسخة احتياطية من السجلات للتعافي من الكوارث

💡 نصيحة (TIP) فعّل كلاً من AD Connector وتحميل سجلات السحابة لتحقيق أقصى رؤية وقدرة جنائية.

3. انقر إنشاء مُحلِّل محلي (Create Local Resolver) لإنهاء الإعداد
4. ستُدفع السياسة تلقائياً إلى جهاز Local Resolver الافتراضي خلال 60 ثانية
5. تحقّق من مزامنة السياسة في واجهة ويب الجهاز الافتراضي (لوحة التحكم → تكوين النظام)

4.3.7 مجموعات القواعد المحلية (اختياري) (Local Rulesets)#

توفّر مجموعات القواعد المحلية (Local Rulesets) وظيفة قائمة التحكم في الوصول (ACL) للتحكم الدقيق في النطاقات وعناوين IP:

انتقل إلى: جدار حماية DNS → الأمان (DNS Firewall → Security) → مجموعات القواعد (Rulesets)

حالات استخدام مجموعات القواعد (Use Cases for Rulesets)

• قائمة السماح (Allow list): السماح دائماً بنطاقات/عناوين IP محددة بصرف النظر عن الفئة
• قائمة الحجب (Block list): الحجب دائماً لنطاقات/عناوين IP محددة بصرف النظر عن السياسة
• تحكم مخصّص (Custom Control): إدارة نطاقات خاصة بالمؤسسة
• الامتثال (Compliance): فرض المتطلبات التنظيمية لنطاقات محددة

إنشاء مجموعة قواعد (Create Ruleset)

1. انقر إنشاء مجموعة قواعد محلية (Create Local Ruleset)
2. اختر العميل (أو الموزّع (Reseller)) والمستأجر، ثم قدِّم اسماً (Name) وصفياً (دون مسافات؛ مثال: "Corporate-Allowlist", "Executive-Bypass")

3. إضافة قواعد (Add Rules):
   • نوع القاعدة (Rule Type): قاعدة مطابقة النطاق (Domain Match Rule) (تُدعَم حروف البدل مثل *.example.com)، أو قاعدة مطابقة IP (IP Match Rule) (CIDR)، أو قاعدة PTR (DNS العكسي) (PTR (Reverse DNS) Rule)
   • النطاق (Domain): أدخل اسم نطاق أو نمط حروف بدل (لقواعد IP: الشبكة (الشبكات) الفرعية أو عنوان (عناوين) IP؛ القيم المتعددة مفصولة بفواصل)
     • مثال: example.com
     • مثال: *.partner-company.com
   • الإجراء (Action): اختر سماح (Allow) أو حجب (Block) — PASSTHRU (Allow)، أو NXDOMAIN (Block)، أو DROP، أو REDIRECT (إلى نطاق/IP)
4. انقر إضافة قاعدة (Add Rule) لكل إدخال
5. راجع القواعد للتأكد من اكتمالها
6. فعّل اختيارياً وضع قائمة السماح الحصرية (Exclusive Allowlist Mode) — تُحجب كل حركة DNS باستثناء النطاقات/عناوين IP المسموح بها صراحةً في مجموعة القواعد هذه (تُفرض جميع القواعد على PASSTHRU (Allow)، وتُحدِّد إجراء الحجب الافتراضي (Default Block Action) لكل ما عداها)
7. انقر إنشاء مجموعة قواعد (Create Ruleset)

إرفاق مجموعة القواعد بإعداد المُحلِّل (Attach Ruleset to Resolver Configuration)

1. انتقل إلى: جدار حماية DNS → الإعداد (DNS Firewall → Setup) → المحللات المحلية (Local Resolvers)
2. عدِّل المُحلِّل المحلي المُنشأ سابقاً
3. في قسم تعيينات موجزات الشبكة (Network Feed Mappings)، أرفق مجموعة القواعد (نوع الموجز مجموعات القواعد المحلية (Local Rulesets)، أو قائمة السماح الحصرية (Exclusive Allowlist)) وحدِّد موضعها في ترتيب أولوية الموجزات (Feed Priority Order)
4. احفظ التغييرات

⚡ مهم (IMPORTANT) تُقيَّم مجموعات القواعد وفق ترتيب أولوية الموجزات. وستتجاوز إدخالات السماح (PASSTHRU) الموضوعة قبل موجزات الحجب عمليات حجب الفئات/التهديدات.

✅ أفضل ممارسة (BEST PRACTICE) وثّق المبرّر التجاري لكل إدخال سماح لأغراض التدقيق.

ℹ️ ملاحظة (NOTE) لا يمكن حذف مجموعة قواعد مرتبطة بمُحلِّل محلي أو سياسة أمان — تحجب البوابة الحذف وتعرض قائمة بالمُحلِّلات أو السياسات التي تستخدمها. افصلها أولاً.

4.4 تكوين السياسات - وضع DNS Forward Proxy#

يُعيد وضع DNS Forward Proxy توجيه استعلامات DNS إلى منصة Protect السحابية للفحص وفرض السياسات. تحدث جميع المعالجة الأمنية في السحابة.

4.4.1 إنشاء الشبكة (الخاصة والخارجية)#

يتطلب وضع DNS Forward Proxy تعريف كل من الشبكات الخاصة (Private) والخارجية (External):

إنشاء الشبكات الخاصة (Create Private Networks)

تُحدِّد الشبكات الخاصة شبكات العملاء الفرعية الداخلية (مشابه للوضع المحلي):

1. انتقل إلى: جدار حماية DNS → الإعداد (DNS Firewall → Setup) → الشبكات (Networks) واختر علامة التبويب الشبكات الخاصة (Private Networks)
2. انقر إنشاء شبكة (Create Network)

كوِّن تفاصيل الشبكة:

• العميل / المستأجر (Customer / Tenant): اختر العميل (أو الموزّع (Reseller)) والمستأجر الذي تنتمي إليه هذه الشبكة
• وصف الشبكة (Network Description): اسم وصفي (مثال: "Office-Network")
• عنوان (عناوين) الشبكة (Network Address(es)): شبكة (شبكات) فرعية داخلية بترميز CIDR (مثال: 192.168.1.0/24)، واحدة في كل سطر أو مفصولة بفواصل؛ ويمكن الجمع بين IPv4 وIPv6

انقر إنشاء شبكة خاصة (Create Private Network)

إنشاء الشبكات الخارجية (Create External Networks)

تُحدِّد الشبكات الخارجية عناوين IP العامة/NAT التي تستقبل منها السحابة استعلامات DNS:

1. انتقل إلى: جدار حماية DNS → الإعداد (DNS Firewall → Setup) → الشبكات (Networks) واختر علامة التبويب الشبكات الخارجية (External Networks)
2. انقر إنشاء شبكة (Create Network)

3. كوِّن تفاصيل الشبكة:
   • العميل / المستأجر (Customer / Tenant): اختر العميل (أو الموزّع (Reseller)) والمستأجر الذي تنتمي إليه هذه الشبكة
   • وصف الشبكة (Network Description): الموقع المصدر أو معرّف الموقع (مثال: "Office-Public-IP")
   • عنوان (عناوين) الشبكة (Network Address(es)): عنوان IP عام أو نطاق CIDR، واحد في كل سطر أو مفصولة بفواصل
     • مثال: 203.0.113.45 (IP عام واحد)
     • مثال: 203.0.113.0/24 (نطاق IP)

انقر إنشاء شبكة خارجية (Create External Network)

ℹ️ ملاحظة (NOTE) تُحدِّد الشبكات الخارجية الاستعلامات حسب IP المصدر. إذا كانت مؤسستك لديها مواقع متعددة بـ IPs عامة مختلفة، أنشئ شبكات خارجية منفصلة لكل منها.

⚡ مهم (IMPORTANT) لا يمكن حذف شبكة خارجية مرتبطة بسياسة أمان — تحجب البوابة الحذف وتعرض خطأً واضحاً يذكر السياسات التي تستخدمها. إذا كانت الشبكة مُفعَّلة لـ RPZ، ألغِ تفعيلها أولاً. افصلها عن تلك السياسات، ثم احذفها.

4.4.2 إنشاء سياسة Forward Proxy#

أنشئ سياسة DNS Forward Proxy:

1. انتقل إلى: جدار حماية DNS → الإعداد (DNS Firewall → Setup) → Local Resolver
2. انقر إنشاء Local Resolver (Create Local Resolver)

الخطوة 1: اختيار وضع التشغيل (Step 1: Operating Mode Selection)

1. في قسم وضع المُحلِّل (Resolver Mode)، اختر وكيل توجيه DNS (DNS Forward Proxy)

ℹ️ ملاحظة (NOTE) في وضع DNS Forward Proxy، يعمل جهاز Local Resolver الافتراضي كعامل إعادة توجيه. تحدث جميع عمليات الفحص وفرض السياسات في سحابة Protect.

الخطوة 2: تفاصيل السياسة (Step 2: Policy Details)

1. كوِّن إعدادات السياسة:

• العميل / المستأجر (Customer / Tenant): اختر العميل والمستأجر المناسبَين
• المعرّف الفريد (Unique Identifier): أدخل المعرّف بالضبط من جهاز Local Resolver الافتراضي
  • يجب أن يطابق القيمة المُكوَّنة في القسم 4.2.5.2
  • حسّاس لحالة الأحرف

انقر التالي (Next)

4.4.3 تكوين التجاوز و Syslog#

نطاقات مستثناة (Bypass Domains)

كوِّن النطاقات الداخلية لتجاوز الفحص السحابي:

1. أضف النطاقات الداخلية في قسم نطاقات مستثناة (Bypass Domains):
   • التنسيق: domain.local، internal.corp.com
   • تُحلَّ هذه النطاقات بواسطة خوادم DNS التجاوز
2. خوادم DNS التجاوز (Bypass DNS Servers): أدخل عناوين IP لخوادم DNS الداخلية
   • عادةً وحدات تحكم النطاق

تكوين Syslog (اختياري) (Syslog Configuration)

1. كوِّن إعادة توجيه syslog الخارجية إن لزم:
   • خادم Syslog (Syslog Server): عنوان IP/اسم مضيف جامع السجلات الخارجي
   • المنفذ (Port): منفذ syslog (514, 1514, 6514)
   • البروتوكول (Protocol): UDP أو TCP أو TLS (فضّل TCP/TLS — قد تتجاوز سجلات RPZ حد 1024 بايت لتنسيق RFC 3164 عبر UDP)
2. انقر التالي (Next)

ℹ️ ملاحظة (NOTE) تُرسَل السجلات بتنسيق ArcSight CEF على المِرفق local4 عبر ثلاثة تدفقات (DNS RPZ 1001، وDNS Query 1002، وAudit 1003). راجع القسم 4.2.6 لنظرة عامة على التنسيق والملحق D لمرجع الحقول وقوالب إعداد SIEM.

تعيينات موجزات الشبكة (لا تُستخدم في وضع Proxy) (Network Feed Mappings)

تنطبق تعيينات موجزات الشبكة (Network Feed Mappings) فقط في وضع Local Resolver. في وضع DNS Forward Proxy، يتم تجاوز هذا القسم:

ℹ️ ملاحظة (NOTE) تُكوَّن قواعد الفحص لوضع DNS Forward Proxy بشكل منفصل في السياسات الأمنية السحابية (Cloud Security Policies) (القسم 4.4.4).

انقر التالي (Next) للمتابعة.

تكوين موصّل Active Directory (Active Directory Connector Configuration)

كوِّن تكامل AD (اختياري):

1. حدِّد تفعيل موصّل Active Directory (Enable Active Directory Connector) إن كانت تعيين هوية المستخدم مطلوبة
2. تكوين AD Connector مفصّل في القسم 5
3. انقر إنشاء (Create) لإنهاء سياسة Forward Proxy

4.4.4 السياسات الأمنية السحابية#

في وضع DNS Forward Proxy، تُنشأ سياسات الأمن بشكل منفصل تحت قسم الأمن (Security):

انتقل إلى: جدار حماية DNS → الأمان (DNS Firewall → Security) → سياسات السحابة (Cloud Policies) (الصفحة معنونة سياسات الأمان (Security Policies)) وانقر إنشاء سياسة (Create Policy). يتكوّن المعالج من أربع خطوات: Tenant Info → Basic Settings → Mapping → Security Rules.

الخطوة 1: اختيار المستأجر (Step 1: Tenant Selection)

• العميل / المستأجر (Customer / Tenant): اختر العميل (أو الموزّع (Reseller)) والمستأجر المناسبَين

الخطوة 2: حالة السياسة والجدولة (Step 2: Policy Status and Scheduling)

1. كوِّن تفعيل السياسة:
   • اسم السياسة (Policy Name): اسم واضح ووصفي
   • الحالة (Status): اضبط السياسة على نشط لتمكين الفرض
   • التفعيل الزمني (Time-Based Activation): حدِّد متى تكون السياسة نشطة
     • اتركه مُعطَّلاً للفرض على مدار الساعة 24/7 (افتراضي)
     • أو فعّله، واضبط المنطقة الزمنية (Timezone)، واقصر الفرض على أيام نشطة (Active Days) ونطاق تاريخ (Date Range) ونطاق زمني (Time Range) محددة

الخطوة 3: إرفاق الشبكة (Step 3: Network Attachment)

1. إرفاق الشبكة الخارجية (Attach External Network): اختر IP العام (مصدر الاستعلامات)
2. إرفاق الشبكة الخاصة (Attach Private Network): اختر الشبكة الفرعية الداخلية

ℹ️ ملاحظة (NOTE) يجب إرفاق كل من الشبكتين الخارجية والخاصة. تُحدِّد الشبكة الخارجية المصدر، وتوفّر الشبكة الخاصة سياقاً عن قطاع العميل.

الخطوة 4: إجراءات الفرض (Step 4: Enforcement Actions)

1. كوِّن فرض الأمن:

التهديدات (Threats)

• فعّل الموجزات بناءً على مشهد التهديدات:
  • نطاقات البرمجيات الخبيثة (Malware Domains)
  • مواقع التصيد الاحتيالي (Phishing Sites)
  • برامج الفدية C2 (Ransomware C2)
  • التعدين السيبراني (Cryptomining)
  • الشبكات الروبوتية (Botnets)
• أكثر من 10 ملايين مؤشر تهديد محدَّث باستمرار. ويمكن أيضاً إرفاق موجزات RPZ الخارجي (External RPZ) (من جدار حماية DNS → الأمان (DNS Firewall → Security) → الموجزات المؤتمتة (Automated Feeds))

الحماية من نفق DNS (DNS Tunneling Protection)

• فعّل كشف نفق DNS بالذكاء الاصطناعي (AI Tunneling Detection) — ويؤدي تفعيل كشف التهديدات المتقدم بالذكاء الاصطناعي (Advanced AI Threat Detection) إلى تطبيقه تلقائياً مع AI FastFlux Detection وAI Infiltration Detection
• يحدّد التحليل بقوة الذكاء الاصطناعي نفق DNS ونطاقات fast-flux وهجمات التسلل
• يحجب القنوات السرية للاتصال عبر DNS

مرشحات الويب (تصفية فئات URL) (Web Filters (URL Category Filtering))

• خصِّص مرشحات الويب (Web Filters) لحجب فئات المواقع (محتوى للبالغين، قمار، إلخ)؛ وتتوفر أيضاً قواعد التطبيقات (Apps) والمرشِّح الجغرافي (Geo Filter)
• وضع السياسة (Policy Mode) — حظر (Blocking): تُحجب المطابقات فعلياً
• وضع السياسة (Policy Mode) — تسجيل (Logging): تُسجَّل المطابقات فقط دون حجبها (وضع المراقبة)

تجاوزات النطاقات المخصّصة (Custom Domain Overrides)

• مجموعة قواعد محلية (Local Ruleset): السماح بنطاقات محددة أو حجبها بصرف النظر عن أحكام الفئات
• قائمة السماح الحصرية (Exclusive Allowlist): حجب كل استعلامات DNS باستثناء المسموح بها صراحةً في مجموعة القواعد المختارة
• إجراء التجاوز (Override Action): يمكن اختيارياً إعادة توجيه الاستعلامات المحجوبة إلى نطاق/IP مخصّص (إعادة توجيه (Redirect)) بدلاً من استجابة الحجب الافتراضية؛ ويُبقي خيار افتراضي (Default) الإجراء الخاص بكل قاعدة (NXDOMAIN (Block)، أو DROP، أو PASSTHRU (Allow)، أو REDIRECT من مجموعات القواعد المحلية المُرفقة)

2. انقر إنشاء سياسة (Create Policy) للإنهاء

⚡ مهم (IMPORTANT) اضبط وضع السياسة على حظر (Blocking) للفرض الفعلي؛ واستخدم تسجيل (Logging) (يظهر باسم Monitoring في قائمة السياسات) للتحقق من سياسة جديدة مقابل حركة حقيقية قبل تفعيل الحجب.

⚡ مهم (IMPORTANT) تُعالَج القواعد داخل السياسة من الأعلى إلى الأسفل. اسحب الإدخالات في ترتيب أولوية القواعد (Rule Priority Order) لإعادة ترتيبها (الأولوية الأعلى أولاً).

مجموعات القواعد المحلية (اختياري) (Local Rulesets)

تعمل مجموعات القواعد في وضع DNS Forward Proxy بنفس طريقة الوضع المحلي (القسم 4.3.7):

1. انتقل إلى: جدار حماية DNS → الأمان (DNS Firewall → Security) → مجموعات القواعد (Rulesets) وانقر إنشاء مجموعة قواعد محلية (Create Local Ruleset)
2. أنشئ مجموعات قواعد للتحكم في السماح (PASSTHRU) / الحجب (NXDOMAIN، DROP، REDIRECT)، أو قائمة سماح حصرية (Exclusive Allowlist)
3. أرفق مجموعات القواعد بالسياسات الأمنية في خطوة قواعد الأمان (Security Rules) (الخطوة 4) ورتّبها في ترتيب أولوية القواعد (Rule Priority Order)

✅ أفضل ممارسة (BEST PRACTICE) استخدم مجموعات القواعد باعتدال. الإفراط في إدخالات السماح قد يقوّض فعالية الأمن.

القسم 5: تكامل Active Directory (Active Directory Integration)

5. تكامل Active Directory#

5.1 نظرة عامة والفوائد#

يُثري موصّل Active Directory سجلات DNS وجدار الحماية بمعلومات هوية المستخدم عبر ربط عناوين IP بأسماء المستخدمين المُصادَق عليهم. يوفّر ذلك رؤية حرجة للتحقيقات الأمنية وفرض السياسات والتقارير الامتثالية.

الفوائد الرئيسية#

• إسناد المستخدم (User Attribution): تحديد المستخدمين الذين وصلوا إلى نطاقات محددة
• التحقيق الجنائي (Forensic Investigation): تتبع الحوادث الأمنية إلى حسابات مستخدمين فردية
• الامتثال للسياسات (Policy Compliance): إثبات فرض السياسات على مستوى المستخدم لعمليات التدقيق
• الاستجابة للحوادث (Incident Response): تحديد المستخدمين المتأثرين بسرعة خلال الأحداث الأمنية
• التحليل السلوكي (Behavioral Analysis): اكتشاف أنماط السلوك الشاذة للمستخدم

مدعوم في كلا الوضعَين#

✅ وظيفة موصّل Active Directory متاحة في كلا وضعَي Local Resolver و DNS Forward Proxy.

5.2 البنية والمتطلبات#

تدفق البيانات#

Domain Controllers → Windows Event Logs (Event ID 4624)
                   ↓
            NXLog Forwarder
                   ↓
         Syslog over TLS (TCP 6514)
                   ↓
   Local Resolver AD Connector Service
                   ↓
   IP-to-Username Mapping Database
                   ↓
DNS/Firewall Logs (enriched with username)

المتطلبات#

متطلبات وحدة تحكم النطاق (Domain Controller Requirements)

• Windows Server 2012 R2 أو أعلى
• تدقيق سجل أحداث الأمن مفعّل (افتراضي)
• جدار الحماية يسمح بـ TCP 6514 الصادر إلى Local Resolver
• وصول إداري لتثبيت مُعيد توجيه NXLog

متطلبات Local Resolver (Local Resolver Requirements)

• خدمة AD Connector مُفعَّلة (مُكوَّنة في القسم 4.3.6 أو 4.4.3)
• جدار الحماية يسمح بـ TCP 6514 الوارد من وحدات تحكم النطاق
• مساحة قرص كافية لقاعدة بيانات تعيين المستخدمين

متطلبات الشبكة (Network Requirements)

• وحدات تحكم النطاق تستطيع الوصول إلى جهاز Local Resolver الافتراضي على منفذ TCP 6514
• اتصال منخفض زمن الاستجابة (< 50 ms موصى به) للربط في الوقت الفعلي

5.3 خطوات التنفيذ#

5.3.1 تفعيل AD Connector على Local Resolver#

يُفعَّل AD Connector أثناء إنشاء السياسة:

1. سجّل الدخول إلى بوابة DNS Armor™ Protect (DNS Firewall): https://dnsarmor.secure-domains.org
2. انتقل إلى: جدار حماية DNS → الإعداد (DNS Firewall → Setup) → المحللات المحلية (Local Resolvers)
3. عدِّل إعداد Local Resolver الموجود (أو فعّله أثناء الإنشاء)
4. في خطوة الإعدادات المتقدمة (Advanced Settings)، حدِّد تفعيل موصّل Active Directory (Enable Active Directory Connector)
5. احفظ السياسة
6. سيقوم جهاز Local Resolver الافتراضي تلقائياً بـ:
   • بدء خدمة AD Connector
   • بدء الاستماع على منفذ TCP 6514 لـ syslog فوق TLS
   • إنشاء قاعدة بيانات تعيين المستخدمين
7. تحقّق من حالة AD Connector في واجهة ويب Local Resolver:
   • انتقل إلى: لوحة التحكم (Dashboard)
   • أكِّد أن خدمة AD Connector (AD Connector Service) تعرض الحالة: قيد التشغيل (Running)

5.3.2 تثبيت NXLog على وحدات تحكم النطاق#

NXLog هو عامل إعادة توجيه السجلات الموصى به لسجلات أحداث Windows. تم اختبار التكوين المُقدَّم والتحقق من صحته لحالة الاستخدام هذه.

خطوات التثبيت (Installation Steps)

1. نزِّل NXLog Community Edition من: https://nxlog.co/products/nxlog-community-edition
2. شغّل المُثبِّت على كل وحدة تحكم نطاق
3. اقبل مسار التثبيت الافتراضي: C:\nxlog
4. أكمل معالج التثبيت

التكوين (Configuration)

1. انتقل إلى: C:\nxlog\conf\
2. اعمل نسخة احتياطية من nxlog.conf الحالي:

copy nxlog.conf nxlog.conf.backup

3. استبدل nxlog.conf بالتكوين التالي:

###############################################################################
## NXLog Configuration - DNS Armor™ Active Directory Connector
## Event ID 4624 (Successful Logons) Only
## Location: C:\nxlog\conf\nxlog.conf
###############################################################################

define ROOT C:\nxlog
define RESOLVER_HOST 192.168.100.10
define RESOLVER_PORT 6514

Moduledir %ROOT%\modules
CacheDir %ROOT%\data
Pidfile %ROOT%\data\nxlog.pid
SpoolDir %ROOT%\data
LogFile %ROOT%\data\nxlog.log
LogLevel INFO

<Extension _syslog>
    Module xm_syslog
</Extension>

<Input security_log>
    Module im_msvistalog
    SavePos TRUE
    ReadFromLast TRUE
    Query <QueryList>\
            <Query Id="0">\
             <Select Path="Security">*[System[(EventID=4624)]]</Select>\
            </Query>\
          </QueryList>

    Exec if $EventID == 4624 \
         { \
          if not defined($IpAddress) $IpAddress = "LOCAL"; \
          if $IpAddress == "::1" $IpAddress = "127.0.0.1"; \
          if not defined($WorkstationName) $WorkstationName = "N/A"; \
          if not defined($TargetUserName) $TargetUserName = "SYSTEM"; \
          if not defined($TargetDomainName) $TargetDomainName = "LOCAL"; \
          $TimeStr = strftime($EventTime, "%Y-%m-%d %H:%M:%S"); \
          $Message = "[SUCCESS-LOGON] " + \
                     "EventID: " + $EventID + " | " + \
                     "Timestamp: " + $TimeStr + " | " + \
                     "User: " + $TargetUserName + "@" + $TargetDomainName + " | " + \
                     "Workstation: " + $WorkstationName + " | " + \
                     "SourceIP: " + $IpAddress + " | " + \
                     "LogonType: " + $LogonType; \
          delete($Keywords); \
          delete($EventType); \
          delete($SeverityValue); \
          delete($LevelValue); \
          delete($TaskValue); \
          delete($OpcodeValue); \
          delete($RecordNumber); \
          delete($ProviderGuid); \
          delete($Version); \
          delete($Channel); \
          delete($Category); \
          delete($Opcode); \
          delete($Level); \
          delete($SubjectUserSid); \
          delete($SubjectUserName); \
          delete($SubjectDomainName); \
          delete($SubjectLogonId); \
          delete($TargetUserSid); \
          delete($TargetLogonId); \
          delete($LogonProcessName); \
          delete($AuthenticationPackageName); \
          delete($LogonGuid); \
          delete($TransmittedServices); \
          delete($LmPackageName); \
          delete($KeyLength); \
          delete($ProcessName); \
          delete($ProcessId); \
          delete($IpPort); \
          delete($ImpersonationLevel); \
          delete($ImpersonationLevelResolved); \
          delete($EventReceivedTime); \
          delete($SourceModuleName); \
          delete($SourceModuleType); \
          delete($EventID); \
          delete($ExecutionThreadID); \
          delete($ExecutionProcessID); \
          delete($TargetUserName); \
          delete($TargetDomainName); \
          delete($LogonType); \
          delete($IpAddress); \
          delete($TimeStr); \
          delete($WorkstationName); \
         }
</Input>

<Output syslog_tls>
    Module om_ssl
    Host %RESOLVER_HOST%
    Port %RESOLVER_PORT%
    AllowUntrusted TRUE
    Exec to_syslog_ietf();
</Output>

<Route r1>
    Path security_log => syslog_tls
</Route>

4. تعديل متغيرات التكوين (Modify Configuration Variables):
   • السطر 6: غيّر RESOLVER_HOST إلى عنوان IP لـ Local Resolver لديك
     • مثال: define RESOLVER_HOST 192.168.100.10
   • السطر 7: تحقّق أن RESOLVER_PORT مضبوط على 6514 (افتراضي)

⚡ مهم (IMPORTANT) تأكّد من صحة عنوان IP لـ RESOLVER_HOST. سيمنع IP غير الصحيح إعادة توجيه السجلات.

5. احفظ ملف التكوين
6. افتح Windows Services (services.msc)
7. حدّد موقع خدمة nxlog
8. انقر بزر الفأرة الأيمن واختر إعادة التشغيل (Restart)

التحقق من تشغيل NXLog (Verify NXLog Operation)

1. تحقّق من ملف سجل NXLog بحثاً عن أخطاء:

notepad C:\nxlog\data\nxlog.log

2. تحقّق من التقاط الأحداث:
   • ينبغي أن يُظهر السجل محاولات الاتصال بـ Local Resolver
   • ابحث عن "connection established" أو رسائل نجاح مماثلة
   • إن ظهرت أخطاء، تحقّق من عنوان IP والمنفذ وقواعد جدار الحماية

5.3.3 تكوين إعادة توجيه الأحداث#

تدقيق سجل أحداث Windows مُفعَّل عادةً افتراضياً على وحدات تحكم النطاق. تحقّق من التكوين:

1. افتح إدارة نهج المجموعة (Group Policy Management)
2. عدِّل سياسة وحدات تحكم النطاق الافتراضية (Default Domain Controllers Policy)
3. انتقل إلى:
   • Computer Configuration
   • → Policies
   • → Windows Settings
   • → Security Settings
   • → Advanced Audit Policy Configuration
   • → Audit Policies
   • → Logon/Logoff
4. تحقّق من ضبط تدقيق تسجيل الدخول (Audit Logon) على نجاح (Success)
5. إن لم يكن مُكوَّناً، اضبطه على نجاح (Success) وانقر OK
6. شغّل gpupdate /force على وحدات تحكم النطاق للتطبيق فوراً

5.3.4 التحقق والاختبار#

اختبار مصادقة المستخدم (Test User Authentication)

1. من محطة عمل العميل، صادِق على النطاق:
   • سجّل خروجك ثم سجّل الدخول مجدداً، أو
   • ادخل إلى مورد شبكي يتطلب المصادقة
2. تحقّق من تسجيل Event ID 4624 على وحدة تحكم النطاق:
   • افتح Event Viewer على DC
   • انتقل إلى: Windows Logs → Security
   • صفِّ بحسب Event ID 4624
   • أكِّد ظهور أحداث المصادقة الأخيرة
3. تحقّق من إعادة توجيه السجلات إلى Local Resolver:
   • انتظر 1-2 دقيقة لمعالجة السجلات
   • سجّل الدخول إلى بوابة Protect
   • انتقل إلى: جدار حماية DNS → المراقبة (DNS Firewall → Monitoring) → مراقبة DNS (DNS Monitor)
   • تحقّق من احتواء السجلات على حقلي اسم المستخدم (Username) والنطاق (Domain)
   • ينبغي أن يظهر اسم المستخدم بصيغة username@domain.local
4. تحقّق من حالة خدمة AD Connector:
   • سجّل الدخول إلى بوابة Protect
   • انتقل إلى: جدار حماية DNS → الإعداد (DNS Firewall → Setup) → المحللات المحلية (Local Resolvers)
   • حدّد موقع Local Resolver الخاص بك وافتح عرض التفاصيل (View Details)
   • أكِّد أن حالة المُحلِّل تظهر متصل (Connected) وأن موصّل AD (AD Connector) معروض كمُفعَّل
   • انتقل إلى علامة التبويب المراقبة (Monitoring) وتحت حالة الخدمات (Services Status) أكِّد أن خدمة AD Connector تُظهر حالة الإدارة (Admin) مُفعَّلة (Enabled) والحالة (Status) قيد التشغيل (Running)

مثال على إدخال سجل مُثرَى (Example Enriched Log Entry)

✅ نجاح (SUCCESS) إذا ظهر اسم المستخدم والنطاق في السجلات وكانت خدمة AD Connector قيد التشغيل، فإن تكامل AD يعمل بشكل صحيح.

5.4 استكشاف أخطاء AD Connector وإصلاحها#

المشكلة: أسماء المستخدمين لا تظهر في سجلات DNS#

الأسباب والحلول المحتملة (Possible Causes and Solutions)

1. خدمة NXLog غير مُشغَّلة:
   • تحقّق من حالة خدمة NXLog على وحدة تحكم النطاق
   • راجع C:\nxlog\data\nxlog.log بحثاً عن أخطاء
   • تحقّق من صياغة ملف التكوين
2. IP Local Resolver غير صحيح:
   • تحقّق من أن RESOLVER_HOST في nxlog.conf يطابق IP لـ Local Resolver
   • اختبر الاتصال: telnet [resolver-ip] 6514
3. جدار الحماية يحجب TCP 6514:
   • تحقّق من سماح جدار حماية وحدة تحكم النطاق بـ TCP 6514 الصادر
   • تحقّق من سماح جدار حماية Local Resolver بـ TCP 6514 الوارد
   • اختبر الاتصال من DC: Test-NetConnection -ComputerName [resolver-ip] -Port 6514
4. خدمة AD Connector غير مُفعَّلة:
   • تحقّق من تفعيل AD Connector في سياسة Local Resolver
   • تحقّق من أن لوحة تحكم Local Resolver تعرض خدمة AD Connector قيد التشغيل
5. مشاكل مزامنة الوقت:
   • تأكّد من مزامنة الوقت بين وحدات تحكم النطاق و Local Resolver (NTP)
   • انحراف الوقت > 5 دقائق قد يسبّب فشل الربط
6. أحداث المصادقة الأخيرة:
   • تعيين المستخدم إلى IP يتطلب مصادقة حديثة (Event 4624)
   • إذا كان المستخدم مسجَّلاً منذ أيام دون إعادة مصادقة، قد يكون التعيين قديماً
   • افرض تسجيل خروج/دخول المستخدم لتوليد Event 4624 جديد

أوامر التشخيص#

على وحدة تحكم النطاق (On Domain Controller)

# Verify NXLog service status
Get-Service nxlog

# Test connectivity to Local Resolver
Test-NetConnection -ComputerName [resolver-ip] -Port 6514

# View recent Event 4624 logs
Get-WinEvent -FilterHashtable @{LogName='Security'; ID=4624} -MaxEvents 10

القسم 6: تكوين التوافر العالي (High Availability Configuration)

6. تكوين التوافر العالي#

6.1 مبادئ التصميم#

يضمن التوافر العالي (HA) لـ المُحلِّل المحلي لـ DNS Armor™ Protect (DNS Firewall) فرضاً مستمراً لأمن DNS ويُلغي نقاط الفشل الواحدة. يستفيد نهج HA الموصى به من آليات تبديل عميل DNS الأصلية بدلاً من إدخال بنية تحتية إضافية لموازنة الحمل.

مبادئ التصميم الرئيسية#

• عدة مثيلات Resolver: انشر جهازَيْن افتراضيَّيْن على الأقل لـ Local Resolver لكل موقع
• تبديل DNS الأصلي: يُبدِّل عملاء DNS تلقائياً إلى الخوادم الثانوية
• دون اعتمادات خارجية: تجنّب تعقيد موازنات الحمل الخارجية عند عدم الحاجة
• تكوين متسق: ضمان أن جميع Resolvers لديها سياسات وإعدادات متطابقة

6.2 بنية النشر#

الحد الأدنى الموصى به للتكوين#

تحجيم النشر#

💡 نصيحة (TIP) تذكير بالتحجيم: تقريباً كل 5 عناوين IP تُولِّد 1 QPS في المتوسط.

✅ أفضل ممارسة (BEST PRACTICE) انشر resolvers عبر مضيفين فعليين مختلفين أو مناطق توافر مختلفة للحماية من فشل المُشرِف الافتراضي أو العتاد.

6.3 تكوين عميل DNS#

تُكوَّن عملاء DNS (محطات العمل، الخوادم، الأجهزة) بعدة خوادم DNS. سلوك عميل DNS الأصلي يوفّر تبديلاً تلقائياً.

تكوين DHCP (موصى به)#

كوِّن نطاق DHCP بعدة خوادم DNS:

1. افتح وحدة تحكم إدارة DHCP
2. انتقل إلى نطاق DHCP لديك
3. انقر بزر الفأرة الأيمن على خيارات النطاق (Scope Options) → تكوين الخيارات (Configure Options)
4. اختر 006 خوادم DNS (006 DNS Servers)
5. أضف عناوين IP لـ Local Resolver بترتيب الأولوية:
   • الأساسي: 192.168.100.10 (Resolver-01)
   • الثانوي: 192.168.100.11 (Resolver-02)
   • الثالث: 192.168.100.12 (Resolver-03) - إن نُشر
6. انقر OK للتطبيق

تكوين نهج المجموعة (بديل)#

لتكوين DNS الثابت عبر GPO:

1. افتح إدارة نهج المجموعة (Group Policy Management)
2. عدِّل GPO المناسب
3. انتقل إلى:
   • Computer Configuration → Policies → Administrative Templates → Network → DNS Client
4. كوِّن سياسة DNS Servers
5. أدخل IPs لـ Local Resolver بترتيب الأولوية

التكوين اليدوي (الاختبار/الاستثناءات)#

لتكوين محطة عمل فردية:

1. افتح مركز الشبكة والمشاركة (Network and Sharing Center)
2. انقر على محول الشبكة النشط
3. انقر خصائص (Properties)
4. اختر Internet Protocol Version 4 (TCP/IPv4)
5. انقر خصائص (Properties)
6. كوِّن خوادم DNS:
   • المُفضَّل: 192.168.100.10
   • البديل: 192.168.100.11

سلوك التبديل الأصلي#

يُعالج عملاء DNS فشل resolver تلقائياً:

1. يُرسل العميل الاستعلام إلى DNS الأساسي (Resolver-01)
2. إن لم يستجب خلال المهلة (~2-3 ثوانٍ)، يستعلم العميل DNS الثانوي (Resolver-02)
3. إن استجاب الثانوي، تستخدم الاستعلامات اللاحقة الثانوي كأساسي مؤقتاً
4. يعيد العميل المحاولة بشكل دوري للأساسي الأصلي لاكتشاف التعافي
5. لا يُطلب تدخّل المستخدم أو مراقبة خارجية

⚡ مهم (IMPORTANT) تبديل عميل DNS تلقائي وشفّاف للمستخدمين. لا حاجة إلى بنية تحتية إضافية لموازنة الحمل لـ HA الأساسي.

6.4 تكامل اختياري لموازن الحمل#

موازنات الحمل الخارجية اختيارية وعادةً غير ضرورية لـ HA لـ DNS. ومع ذلك، قد تكون مفيدة في سيناريوهات محددة.

متى نأخذ موازن الحمل بعين الاعتبار#

• توزيع حمل نشط-نشط: توزيع حمل الاستعلامات عبر جميع resolvers بالتساوي
• فحص صحي متقدم: مراقبة صحية أكثر تطوراً من مهلات DNS
• إدارة مركزية: VIP واحد يُبسّط تكوين العميل
• عمليات نشر كبيرة: 4+ resolvers حيث يكون توزيع الحمل المتساوي حرجاً

تكوين موازن الحمل#

عند نشر موازن حمل (F5، HAProxy، Citrix ADC، إلخ):

1. إنشاء IP افتراضي (VIP) (Create Virtual IP):
   • عيِّن VIP سيستخدمه العملاء كخادم DNS لديهم
   • مثال: 192.168.100.50
2. تكوين الفحوصات الصحية (Configure Health Checks):
   • البروتوكول (Protocol): استعلام DNS
   • الاستعلام (Query): أرسل استعلام DNS اختباري (مثال: "healthcheck.local")
   • الاستجابة المتوقعة (Expected Response): استجابة DNS صالحة (دون مهلة أو خطأ)
   • الفاصل (Interval): 10 ثوانٍ
   • المهلة (Timeout): 3 ثوانٍ
   • العتبة (Threshold): ضع علامة غير صحي بعد 3 إخفاقات متتالية
3. طريقة موازنة الحمل (Load Balancing Method):
   • التناوب الدائري (Round Robin): توزيع الاستعلامات بالتساوي (موصى به)
   • أقل اتصالات (Least Connections): الإرسال إلى أقل resolver انشغالاً
   • أقل وقت استجابة (Least Response Time): الإرسال إلى أسرع resolver
4. استمرار الجلسة (Session Persistence):
   • غير مطلوب: DNS بروتوكول عديم الحالة
   • استمرار IP المصدر اختياري ولكن غير ضروري
5. أعضاء التجمّع (Pool Members):
   • أضف جميع أجهزة Local Resolver الافتراضية إلى التجمّع
   • كوِّن فحوصات صحية فردية لكل عضو

تكوين العميل مع موازن الحمل#

• DHCP Option 006: 192.168.100.50 (VIP فقط)
• DNS البديل (Alternate DNS): احتياطي اختياري (DNS خارجي أو IP لـ resolver المتبقي)

ℹ️ ملاحظة (NOTE) حتى مع موازن حمل، كوِّن خادم DNS ثانوي في DHCP (إما VIP آخر أو IP لـ resolver مباشر) للحماية من فشل موازن الحمل.

موازن الحمل غير موصى به إذا#

• نشر صغير (< 2000 مستخدم)
• قيود الميزانية (تكاليف ترخيص إضافية)
• موارد تشغيلية محدودة (يضيف تعقيداً)
• تبديل DNS الأصلي يلبّي المتطلبات (عادةً كافٍ)

✅ أفضل ممارسة (BEST PRACTICE) ابدأ بتبديل DNS الأصلي (2 resolvers، دون موازن حمل). أضف موازن حمل فقط إذا برّرت متطلبات تجارية محددة التعقيد الإضافي.

القسم 7: التحقق من النشر (Deployment Validation)

7. التحقق من النشر#

7.1 الاختبار قبل الإنتاج#

قبل ترحيل حركة الإنتاج إلى المُحلِّل المحلي لـ DNS Armor™ Protect (DNS Firewall)، نفِّذ اختباراً شاملاً في بيئة مُتحكَّم بها.

7.1.1 اختبار تحليل DNS#

اختبار تجاوز النطاقات الداخلية (Test Internal Domain Bypass)

تحقّق من تحليل النطاقات الداخلية بشكل صحيح بواسطة خوادم DNS التجاوز:

1. كوِّن محطة عمل اختبار لاستخدام Local Resolver كخادم DNS
2. نفّذ بحثات DNS التالية:

nslookup dc01.corp.local [Local-Resolver-IP]
nslookup fileserver.corp.local [Local-Resolver-IP]
nslookup intranet.corp.local [Local-Resolver-IP]

النتيجة المتوقعة (Expected Result)

• النطاقات الداخلية تُحلَّ إلى عناوين IP داخلية صحيحة
• دون تأخير أو مهلة الاستعلام
• تأتي استجابات DNS من خوادم DNS التجاوز (وليس من السحابة أو الخارج)

✅ معايير النجاح (SUCCESS CRITERIA) جميع النطاقات الداخلية تُحلَّ بشكل صحيح بزمن استجابة < 50 ms.

اختبار تحليل النطاقات الخارجية (Test External Domain Resolution)

تحقّق من تحليل النطاقات الخارجية بشكل صحيح:

nslookup google.com [Local-Resolver-IP]
nslookup cloudflare.com [Local-Resolver-IP]
nslookup microsoft.com [Local-Resolver-IP]

النتيجة المتوقعة (Expected Result)

• النطاقات الخارجية تُحلَّ إلى عناوين IP العامة الصحيحة
• زمن الاستجابة < 100 ms (الوضع المحلي) أو < 200 ms (وضع Proxy)
• تُعالَج الاستعلامات عبر الفحص الأمني

✅ معايير النجاح (SUCCESS CRITERIA) جميع النطاقات الخارجية تُحلَّ بشكل صحيح دون مهلة أو أخطاء.

7.1.2 اختبار فرض السياسات#

اختبار فئة محجوبة (Test Blocked Category)

تحقّق من فرض الفئات المحجوبة:

1. حدِّد نطاقاً اختبارياً في فئة محجوبة:
   • قمار: casino.com، poker.com
   • للبالغين: (استخدم نطاقات اختبارية مناسبة)
   • برمجيات خبيثة: استخدم نطاق اختبار EICAR (إن توفر في البوابة)
2. حاول حلّ النطاق المحجوب:

nslookup casino.com [Local-Resolver-IP]

النتيجة المتوقعة (Expected Result)

• الاستعلام محجوب (استجابة NXDOMAIN أو IP لصفحة الحجب)
• عدم التحليل إلى عنوان IP الفعلي
• تسجيل الحدث في بوابة Protect

✅ معايير النجاح (SUCCESS CRITERIA) النطاقات المحجوبة لا تُحلَّ، والإجراء مُسجَّل.

اختبار فئة مسموح بها (Test Allowed Category)

تحقّق من تحليل النطاقات المسموح بها بشكل صحيح:

nslookup google.com [Local-Resolver-IP]
nslookup github.com [Local-Resolver-IP]

النتيجة المتوقعة (Expected Result)

• تُحلَّ النطاقات بشكل صحيح
• أوقات استجابة DNS طبيعية
• تسجيل الاستعلام كـ "مسموح به"

اختبار قواعد سماح مخصّصة (إن كانت مُكوَّنة) (Test Custom Allow Rules)

إذا كانت مجموعات القواعد المحلية مُكوَّنة بإدخالات سماح (PASSTHRU):

nslookup allowed-domain.com [Local-Resolver-IP]

النتيجة المتوقعة (Expected Result)

• يُحلَّ النطاق حتى لو كان في فئة محجوبة
• قاعدة السماح (PASSTHRU) لها الأسبقية عندما تكون مجموعة قواعدها أعلى من موجز الحجب في ترتيب أولوية الموجزات (Feed Priority Order)

7.1.3 اختبار نطاقات مستثناة#

اختبار قائمة التجاوز (Test Bypass List)

تحقّق من عدم فحص نطاقات مستثناة:

1. أضف نطاق اختبار برمجيات خبيثة معروف إلى قائمة التجاوز مؤقتاً
2. حاول تحليل النطاق
3. النتيجة المتوقعة: يُحلَّ النطاق (تجاوز الفحص)
4. أزل نطاق الاختبار من قائمة التجاوز

⚠️ تحذير (CAUTION) استخدم بالغ الحذر عند الاختبار بنطاقات خبيثة فعلية. نفّذ الاختبار في بيئة معزولة فقط.

7.2 التحقق من السجلات#

تحقّق من تسجيل جميع نشاط الاستعلامات بشكل صحيح:

1. سجّل الدخول إلى بوابة Protect: https://dnsarmor.secure-domains.org
2. انتقل إلى: جدار حماية DNS → المراقبة (DNS Firewall → Monitoring) → مراقبة DNS (DNS Monitor)
3. تحقّق مما يلي:
   • جميع استعلامات الاختبار تظهر في السجلات
   • عناوين IP المصدر صحيحة
   • الإجراءات (سماح/حجب) صحيحة
   • الطوابع الزمنية دقيقة
   • إذا كان AD Connector مُفعَّلاً: تظهر أسماء المستخدمين في السجلات

عيّنة من إدخال سجل#

التحقق من Syslog الخارجي (إن كان مُكوَّناً)#

إذا كان يُعاد توجيه السجلات إلى syslog/SIEM خارجي:

1. ادخل إلى خادم syslog أو وحدة تحكم SIEM
2. ابحث عن السجلات التي تحتوي على CEF:0|Secure Domains|Logs Connector
3. تحقّق من وصول التدفقات الثلاثة جميعها: dns-rpz ‏(SignatureID 1001)، وdns-query ‏(1002)، وaudit ‏(1003)
4. تحقّق من صحة تحليل محتوى الحقول — يجب أن يظهر اسم المستأجر (cs4)، والنطاق المُستعلَم عنه (dhost)، وعنوان IP للعميل (src)، والإجراء (act) كحقول منفصلة، لا كسلسلة واحدة غير مُحلَّلة
5. أكِّد وصول السجلات في الوقت الفعلي (تأخير < 30 ثانية)

لفحص ما يمر فعلياً على الشبكة عند المُجمِّع:

tcpdump -i any -A -n port 514 | grep -a 'CEF:0'

لحقن سجل اختباري صالح في المُجمِّع (استخدم عيّنة من الملحق D.4):

logger -n 127.0.0.1 -P 514 -T -p local4.info "<الصق سجلاً نموذجياً من الملحق D.4>"

ℹ️ ملاحظة (NOTE) إذا وصلت السجلات إلى المُجمِّع لكن SIEM لا يعرض شيئاً، فافحص مرشِّح المِرفق أولاً: يرسل المُحلِّل على local4 ‏(PRI 166). المُجمِّع الذي يرشِّح على مِرفق مختلف يُسقط كل السجلات بصمت.

7.3 التحويل إلى الإنتاج#

بعد الاختبار الناجح، رحّل حركة الإنتاج إلى المُحلِّل المحلي Protect:

نهج التدرّج المرحلي (موصى به)#

المرحلة 1: المجموعة التجريبية (Phase 1: Pilot Group)

1. حدِّد 10-20 مستخدماً تجريبياً من قسم تقنية المعلومات
2. كوِّن محطات عمل المستخدمين التجريبيين بـ DNS Local Resolver
3. راقب لمدة 24-48 ساعة
4. اجمع التغذية الراجعة وعالج أي مشاكل

المرحلة 2: نشر القسم (Phase 2: Department Rollout)

1. اختر قسماً تجارياً واحداً (غير حرج)
2. حدّث نطاق DHCP لـ VLAN القسم
3. يستلم المستخدمون تكوين DNS الجديد تلقائياً عند تجديد DHCP التالي
4. راقب لمدة 3-5 أيام عمل

المرحلة 3: النشر على نطاق الموقع (Phase 3: Site-Wide Deployment)

1. حدّث جميع نطاقات DHCP لاستخدام Local Resolver
2. افرض تجديد DHCP اختيارياً: ipconfig /release ثم ipconfig /renew
3. راقب حجم الاستعلامات وأداء النظام
4. تحقّق من أن جميع الشبكات الفرعية تعمل بشكل صحيح

المرحلة 4: التحقق (Phase 4: Validation)

1. أكِّد أن 95%+ من العملاء يستخدمون Local Resolver
2. تحقّق من تطابق أحجام الاستعلامات مع التوقعات
3. راجع التهديدات والفئات المحجوبة
4. اجمع التغذية الراجعة من المستخدمين

نهج الانفجار الكبير (بديل)#

للمواقع الصغيرة (< 500 مستخدم):

1. جدّول نافذة الصيانة
2. حدّث جميع نطاقات DHCP في وقت واحد
3. أعلن للمستخدمين
4. راقب عن كثب لأول 2-4 ساعات
5. كن مستعداً بخطة تراجع (إعادة DHCP إلى خوادم DNS الأصلية)

خطة التراجع#

في حال ظهور مشاكل أثناء التحويل:

1. حدّث نطاقات DHCP لاستعادة خوادم DNS الأصلية
2. افرض تجديد DHCP أو انتظر التجديد التلقائي
3. تحقّق من المشاكل وحلّها
4. حاول التحويل مجدداً بعد المعالجة

ℹ️ ملاحظة (NOTE) يحدّد وقت إيجار DHCP مدى سرعة انتشار التغييرات. أوقات الإيجار الأقصر (مثلاً 8 ساعات) تُمكِّن نشراً أسرع لكنها تزيد حمل خادم DHCP.

القسم 8: المراقبة والعمليات (Monitoring & Operations)

8. المراقبة والعمليات#

8.1 المراقبة الصحية#

المراقبة المنتظمة تضمن استمرار Local Resolver في التشغيل بشكل أمثل:

مراقبة البوابة السحابية#

1. سجّل الدخول إلى بوابة DNS Armor™ Protect (DNS Firewall): https://dnsarmor.secure-domains.org
2. انتقل إلى: جدار حماية DNS → الإعداد (DNS Firewall → Setup) → المحللات المحلية (Local Resolvers)

مؤشرات الحالة الصحية#

تعرض صفحة المحللات المحلية (Local Resolvers) حالة الاتصال لكل عملية نشر لمُحلِّل محلي، مُستمدَّة من أحدث نبضة قلب (heartbeat) لكل مُحلِّل (آخر ظهور (Last Seen)) — وليست علامة تُضبط يدوياً:

• متصل (Connected): أبلغ المُحلِّل السحابةَ خلال الدقائق القليلة الماضية وهو قيد التشغيل
• غير متصل (Disconnected): لم يُبلِّغ المُحلِّل مؤخراً، أو لم يتصل قط (تحقّق فوراً)

تُلخِّص بطاقات لوحة التحكم في الصفحة عدد المُحلِّلات المتصلة، ونسبة الاتصال المئوية، وتوزيع وضعَي Local وProxy.

8.2 استخدام الموارد#

راقب موارد النظام لضمان سعة كافية:

عرض موارد البوابة السحابية#

انتقل إلى: جدار حماية DNS → الإعداد (DNS Firewall → Setup) → المحللات المحلية (Local Resolvers)، اختر المُحلِّل، افتح عرض التفاصيل (View Details)، وانتقل إلى علامة التبويب المراقبة (Monitoring)

عرض إحصائيات الموارد#

تعرض علامة التبويب المراقبة (Monitoring) إحصائيات استخدام الموارد (Resource Usage Statistics) (رسوم استخدام CPU والذاكرة)، وإحصائيات أداء الذاكرة المؤقتة (Cache Performance Statistics)، ونظرة عامة على استعلامات DNS (DNS Queries Overview)، ومقاييس الأمان والأداء (Security & Performance Metrics) لنطاق زمني قابل للاختيار. راقب:

• استخدام CPU (CPU Utilization): ينبغي أن يبقى < 70% خلال التشغيل العادي
• استخدام الذاكرة (Memory Usage): ينبغي أن يبقى < 80% من RAM المُخصَّص
• مساحة القرص (Disk Space): راقب استهلاك تخزين السجلات
• إنتاجية الشبكة (Network Throughput): راقب لتشبع عرض النطاق
• الاستعلامات في الثانية (QPS): معدل الاستعلامات الحالي مقابل السعة

إجراءات المعالجة#

في حال اكتشاف قيود على الموارد:

• CPU/الذاكرة: زِدْ موارد الجهاز الافتراضي أو انشر resolver إضافياً
• مساحة القرص: اضبط سياسة الاحتفاظ بالسجلات أو زِد حجم القرص
• QPS: انشر resolver إضافياً لتوزيع الحمل

8.3 اكتشاف نفق DNS#

راقب محاولات نفق DNS واستجب لها:

انتقل إلى: جدار حماية DNS → الإعداد (DNS Firewall → Setup) → المحللات المحلية (Local Resolvers)، اختر المُحلِّل، افتح عرض التفاصيل (View Details)، وانتقل إلى علامة التبويب نفق DNS (DNS Tunneling) (متاحة في وضع Local Resolver)

مؤشرات نفق DNS#

• تكرار استعلامات مرتفع بشكل غير عادي من مصدر واحد
• استعلامات بها بيانات مشفّرة في تسميات النطاق الفرعي
• أنماط استعلام غير قياسية (مثال: استعلامات سجل TXT)
• استعلامات إلى نطاقات غامضة أو مُسجَّلة حديثاً

إجراءات الاستجابة#

1. التحقيق (Investigate): راجع IP المصدر والمستخدم (إن كان AD مُدمَجاً)
2. الاستثناء (Exempt) (إن كان مشروعاً): بعض التطبيقات تستخدم DNS لأغراض مشروعة
   • أضف النطاق إلى قوائم استثناء كشف الذكاء الاصطناعي في علامة التبويب نفق DNS (DNS Tunneling) (قوائم منفصلة لكشوفات النفق والتسلل و fast-flux — Securedomains.AI.Tunneling وSecuredomains.AI.Infiltration وSecuredomains.AI.FastFlux — نطاق واحد لكل سطر) واحفظ، كي لا يعود كاشف الذكاء الاصطناعي المعني يُبلِّغ عنه
   • وثّق المبرّر التجاري
3. حجب (Block) (إن كان خبيثاً): أضف قاعدة حجب (NXDOMAIN / DROP / REDIRECT) للنطاق في مجموعة قواعد، أو حقّق في الجهاز المُدار

حالات استخدام مشروعة لنفق DNS#

• اتصال احتياطي للبوابات الأَسْرى (captive portals)
• اتصالات أجهزة إنترنت الأشياء (IoT)
• بعض حِزم استمرار VPN client

⚡ مهم (IMPORTANT) لا تحجب جميع اكتشافات نفق DNS بشكل أعمى. حقّق للتمييز بين النشاط المشروع والخبيث.

8.4 الإدارة عن بُعد#

أدِر Local Resolver عن بُعد من البوابة السحابية:

انتقل إلى: جدار حماية DNS → الإعداد (DNS Firewall → Setup) → المحللات المحلية (Local Resolvers)، اختر المُحلِّل، افتح عرض التفاصيل (View Details)، وانتقل إلى علامة التبويب الإجراءات (Actions) (اللوحة: تعليمات وإجراءات المُحلِّل (Resolver Instructions & Actions)). اختر التعليمات المطلوبة وانقر إرسال جميع التعليمات (Submit All Instructions) لإرسالها إلى المُحلِّل دفعة واحدة؛ وتُقرأ التعليمات الحالية من المُحلِّل عند تحميل علامة التبويب. يجب أن يكون المُحلِّل متصلاً (Connected) لاستقبال التعليمات.

الإجراءات البعيدة المتاحة#

إعادة تشغيل المُحلِّل (Reboot Resolver)

• يعيد تشغيل خدمة المُحلِّل على جهاز Local Resolver الافتراضي
• الاستخدام لـ: تطبيق التحديثات، حلّ المشاكل المؤقتة
• وقت التوقف: انقطاع قصير للخدمة (تأكّد من تكوين HA للحفاظ على الخدمة)

تكوين الشبكة (تغيير عنوان IP) (Network Configuration)

• تعديل إعدادات واجهات شبكة Local Resolver (eth0 / eth1) وإعدادات خوادم DNS عن بُعد (تكوين IPv4 وIPv6 لكل واجهة، عبر DHCP أو بشكل ثابت)
• الاستخدام لـ: إعادة تكوين الشبكة، تعارضات IP

تكوين API (استبدال رمز API) (API Configuration)

• تعرض علامة التبويب الإجراءات (Actions) رمز API الحالي للمُحلِّل وتتيح لك إدخال رمز API جديد (New API Code)
• الاستخدام لـ: تدوير الرمز، الاشتباه في تسريب الرمز
• أنشئ رموز API أو أعد تعيينها ضمن الإدارة (Administration) → مفاتيح API (API Keys) (انظر القسم 4.2.5.1)، ثم طبّق الرمز الجديد هنا

مسح ذاكرة DNS المؤقتة وإعادة تحميل الخدمات (Flush DNS Cache & Reload Services)

• يمسح ذاكرة DNS المؤقتة ويعيد تشغيل خدمات DNS
• الاستخدام لـ: فرض حالة نظيفة بعد تغييرات جوهرية في السياسة أو قائمة التجاوز
• يسبّب انقطاعاً قصيراً للخدمة (عادةً 5-15 ثانية أثناء مسح الذاكرة المؤقتة وإعادة تشغيل الخدمات)

ℹ️ ملاحظة (NOTE) لا تتطلب تغييرات التكوين العادية دفعاً يدوياً — يُزامِن المُحلِّل تكوينه من البوابة تلقائياً (كل 60 ثانية تقريباً).

⚡ مهم (IMPORTANT) إعادة التشغيل عن بُعد ستسبّب انقطاعاً قصيراً لخدمة DNS. تأكّد من توفر resolvers ثانوية للحفاظ على استمرارية الخدمة.

حذف مُحلِّل محلي (Deleting a Local Resolver)#

لإيقاف تشغيل مُحلِّل محلي (decommission):

1. انتقل إلى: جدار حماية DNS → الإعداد (DNS Firewall → Setup) → المحللات المحلية (Local Resolvers)
2. افتح قائمة الإجراءات (Actions) للمُحلِّل واختر حذف (Delete)
3. أكِّد الحذف (لا يمكن التراجع عن هذا الإجراء)
4. أوقف تشغيل الجهاز الافتراضي وأزِله من المُشرِف الافتراضي لديك

ℹ️ ملاحظة (NOTE) يزيل حذف المُحلِّل تكوينه السحابي لكنه لا يحذف الكائنات التي كان يشير إليها (الشبكات الخاصة، إعدادات التجاوز، مجموعات القواعد). ولا يمكن حذف تلك الكائنات ما دام أي مُحلِّل أو سياسة أمان لا يزال يستخدمها — تحجب البوابة هذا الحذف بخطأ استخدام واضح يذكر الكائنات المُشيرة، حتى تُزال كل المراجع.

القسم 9: دليل استكشاف الأخطاء وإصلاحها (Troubleshooting Guide)

9. دليل استكشاف الأخطاء وإصلاحها#

9.1 المشاكل الشائعة وحلولها#

المشكلة 1: جهاز Local Resolver الافتراضي لا يستطيع الوصول إلى البوابة السحابية#

الأعراض (Symptoms)

• تعرض لوحة التحكم "غير قادر على المزامنة مع السحابة"
• تحديثات السياسة لا تُطبَّق
• إحصائيات الموارد لا تُحدَّث في البوابة

خطوات استكشاف الأخطاء وإصلاحها (Troubleshooting Steps)

1. تحقّق من اتصال الإنترنت من الجهاز الافتراضي:

ping 8.8.8.8
ping dnsarmor.secure-domains.org

2. اختبر اتصال HTTPS:

curl -I https://dnsarmor.secure-domains.org

3. تحقّق من سماح قواعد جدار الحماية بـ HTTPS الصادر (TCP 443)
4. تحقّق من تحليل DNS لاسم مضيف البوابة
5. تحقّق من تكوين الوكيل إذا كانت البيئة تستخدم وكيل HTTP

الحل (Resolution)

• كوِّن جدار الحماية للسماح بوصول HTTPS الصادر للجهاز الافتراضي
• إذا استُخدم الوكيل، كوِّن إعدادات الوكيل في الجهاز الافتراضي
• تحقّق من صحة مفتاح API في إعداد النظام

المشكلة 2: استعلامات DNS لا يُعاد توجيهها#

الأعراض (Symptoms)

• العملاء لا يستطيعون تحليل أي نطاقات (داخلية أو خارجية)
• استعلامات DNS تنتهي مهلتها
• اتصال الشبكة يعمل لكن تحليل الاسم يفشل

خطوات استكشاف الأخطاء وإصلاحها (Troubleshooting Steps)

1. تحقّق من حالة خدمة Local Resolver:
   • تحقّق من لوحة التحكم → تكوين النظام → حالة الخدمة
   • جميع الخدمات الحرجة ينبغي أن تعرض "Running"
2. اختبر تحليل DNS مباشرة من جهاز Local Resolver الافتراضي:

nslookup google.com 127.0.0.1

3. تحقّق من تكوين مُعيدي توجيه DNS وقابليتهم للوصول
4. تحقّق من سماح جدار الحماية بـ DNS الصادر (UDP/TCP 53) إلى مُعيدي التوجيه
5. راجع السجلات بحثاً عن أخطاء

الحل (Resolution)

• أعد تشغيل خدمة DNS عبر واجهة الويب أو الإدارة عن بُعد
• تحقّق من صحة عناوين IP لمُعيدي توجيه DNS
• كوِّن قواعد جدار الحماية للسماح بـ DNS الصادر
• تأكّد من أن الجهاز الافتراضي لديه اتصال إنترنت

المشكلة 3: النطاقات الداخلية لا تُحلَّ#

الأعراض (Symptoms)

• النطاقات الداخلية (مثال: corp.local) تفشل في التحليل
• النطاقات الخارجية تعمل بشكل صحيح
• قائمة التجاوز مُكوَّنة لكنها لا تعمل

خطوات استكشاف الأخطاء وإصلاحها (Troubleshooting Steps)

1. تحقّق من صحة تكوين نطاقات مستثناة في السياسة
2. تحقّق من تحديد خوادم DNS التجاوز وإمكانية الوصول إليها
3. اختبر اتصال خادم DNS التجاوز من Local Resolver:

nslookup dc01.corp.local [bypass-dns-server-ip]

4. تحقّق من صياغة قائمة التجاوز (استخدام حروف البدل، تنسيق النطاق)
5. تحقّق من حلقات إعادة توجيه DNS

الحل (Resolution)

• صحّح قائمة نطاقات مستثناة في سياسة البوابة
• تحقّق من عناوين IP لخوادم DNS التجاوز
• تأكّد من قدرة خوادم DNS التجاوز على الوصول إلى Local Resolver
• تجنّب إعادة توجيه DNS الدائرية (Local Resolver → Bypass DNS → Local Resolver)

المشكلة 4: تحديثات السياسة لا تُطبَّق#

الأعراض (Symptoms)

• تغييرات السياسة في البوابة لا تأخذ مفعولها
• النطاقات المحجوبة لا تزال تُحلَّ
• التكوين غير متزامن

خطوات استكشاف الأخطاء وإصلاحها (Troubleshooting Steps)

1. تحقّق من تطابق المعرّف الفريد بالضبط بين البوابة والجهاز الافتراضي
2. تحقّق من صحة مفتاح API وعدم انتهاء صلاحيته
3. تحقّق من الاتصال السحابي (انظر المشكلة 1)
4. تحقّق من حالة مزامنة السياسة في لوحة التحكم
5. افرض المزامنة اليدوية إن توفرت

الحل (Resolution)

• صحّح المعرّف الفريد إن وُجد عدم تطابق
• أعد توليد رمز API (الإدارة (Administration) → مفاتيح API (API Keys) → إعادة تعيين رمز API (Reset API Code)) وطبّق الرمز الجديد على المُحلِّل
• أعد تشغيل جهاز Local Resolver الافتراضي لفرض تحديث التكوين
• تحقّق من عدم حجب جدار الحماية لاستدعاءات HTTPS API

المشكلة 5: أسماء مستخدمي Active Directory لا تظهر في السجلات#

الأعراض (Symptoms)

• سجلات DNS تعرض عناوين IP لكن دون أسماء مستخدمين
• AD Connector مُفعَّل لكنه لا يعمل
• سجلات الأحداث لا تصل من وحدات تحكم النطاق

خطوات استكشاف الأخطاء وإصلاحها (Troubleshooting Steps)

1. تحقّق من أن خدمة AD Connector قيد التشغيل (لوحة التحكم → حالة الخدمة)
2. تحقّق من حالة خدمة NXLog على وحدات تحكم النطاق:

Get-Service nxlog

3. راجع ملف سجل NXLog على DC:

notepad C:\nxlog\data\nxlog.log

4. اختبر الاتصال من DC إلى Local Resolver TCP 6514:

Test-NetConnection -ComputerName [resolver-ip] -Port 6514

5. تحقّق من سماح جدار الحماية بـ DC → Resolver TCP 6514
6. تحقّق من توليد Event 4624 في سجل أمن DC

الحل (Resolution)

• ابدأ أو أعد تشغيل خدمة NXLog على وحدات تحكم النطاق
• صحّح RESOLVER_HOST IP في nxlog.conf إن كان غير صحيح
• كوِّن قواعد جدار الحماية للسماح بـ TCP 6514
• افرض مصادقة المستخدم لتوليد Event 4624
• تحقّق من مزامنة الوقت بين DC و Resolver

المشكلة 6: استخدام عالٍ لـ CPU أو الذاكرة#

الأعراض (Symptoms)

• CPU باستمرار > 80%
• استخدام الذاكرة > 90%
• أوقات استجابة DNS بطيئة
• النظام غير مستجيب

خطوات استكشاف الأخطاء وإصلاحها (Troubleshooting Steps)

1. راجع QPS الحالي (Queries Per Second) مقابل سعة الجهاز الافتراضي
2. تحقّق من حجم الاستعلامات المرتفع بشكل غير عادي أو هجوم (تضخيم DNS)
3. راجع تخصيص الموارد مقابل توصيات جدول التحجيم
4. حدِّد العملاء الأكثر استعلاماً (قد يشير إلى سوء تكوين)
5. تحقّق من حلقات استعلام DNS

الحل (Resolution)

• زِدْ تخصيص CPU/الذاكرة للجهاز الافتراضي وفقاً لجدول التحجيم
• انشر Local Resolver إضافي لتوزيع الحمل
• حقّق وعالج حلقات استعلام DNS
• احجب العملاء المسيئين إن كنت تحت هجوم
• حسِّن إعدادات ذاكرة التخزين المؤقت إن أمكن

المشكلة 7: الاستعلامات تفشل بشكل متقطع#

الأعراض (Symptoms)

• استعلامات DNS تنجح أحياناً وتفشل أحياناً
• سلوك غير متسق
• المستخدمون يبلّغون عن مشاكل اتصال متفرّقة

خطوات استكشاف الأخطاء وإصلاحها (Troubleshooting Steps)

1. تحقّق من استخدام الموارد العالي (CPU، الذاكرة، الشبكة)
2. تحقّق من ثبات مُعيدي توجيه DNS وقابليتهم للوصول
3. اختبر مشاكل اتصال الشبكة (فقد الحِزم، زمن الاستجابة)
4. راجع السجلات بحثاً عن أنماط في الإخفاقات
5. تحقّق من تحديد معدل استعلام DNS

الحل (Resolution)

• أضف مُعيدي توجيه DNS ثانويين للتكرار
• حقّق وحلّ مشاكل اتصال الشبكة
• زِد موارد الجهاز الافتراضي إن كانت المشكلة متعلقة بالأداء
• كوِّن عدة Local Resolvers لـ HA
• اضبط إعدادات مهلة الاستعلام إن لزم

9.2 أوامر التشخيص#

وحدة تحكم جهاز Local Resolver الافتراضي#

# Check network connectivity
ping 8.8.8.8
ping dnsarmor.secure-domains.org
curl -I https://dnsarmor.secure-domains.org

# Test DNS resolution
nslookup google.com 127.0.0.1
nslookup google.com [dns-forwarder-ip]

# Check listening ports
sudo netstat -tunlp | grep 53
sudo netstat -tunlp | grep 6514

# Monitor resource usage
top
free -h
df -h

# Check time synchronization
timedatectl status

اختبار عميل Windows#

REM Test DNS resolution via Local Resolver
nslookup google.com [Local-Resolver-IP]

REM Display current DNS configuration
ipconfig /all

REM Flush DNS cache
ipconfig /flushdns

REM Renew DHCP configuration
ipconfig /release
ipconfig /renew

REM Test connectivity to Local Resolver
ping [Local-Resolver-IP]
Test-NetConnection -ComputerName [Local-Resolver-IP] -Port 53

تشخيصات PowerShell#

# Test DNS resolution with timing
Measure-Command { Resolve-DnsName google.com -Server [Local-Resolver-IP] }

# Test multiple domains
$domains = @("google.com", "microsoft.com", "cloudflare.com")
foreach ($domain in $domains) {
    Resolve-DnsName $domain -Server [Local-Resolver-IP]
}

# Check DNS server configuration
Get-DnsClientServerAddress

# View DNS cache
Get-DnsClientCache

9.3 تصعيد الدعم#

إذا تعذّر حلّ المشاكل باستخدام هذا الدليل، تواصل مع دعم DNS Armor™:

قبل التواصل مع الدعم، اجمع#

1. وصف المشكلة (Problem Description):
   • وصف مفصّل للمشكلة
   • متى بدأت المشكلة؟
   • هل تغيّر شيء مؤخراً؟
   • كم عدد المستخدمين المتأثرين؟
2. تفاصيل البيئة (Environment Details):
   • إصدار Local Resolver (من لوحة التحكم)
   • وضع التشغيل (محلي أو Proxy)
   • موارد الجهاز الافتراضي (CPU، الذاكرة، القرص)
   • منصة المُشرِف الافتراضي
3. تفاصيل التكوين (Configuration Details):
   • المعرّف الفريد
   • تكوين الشبكة الخاصة
   • قائمة نطاقات مستثناة
   • تكوين مُعيدي توجيه DNS
4. معلومات التشخيص (Diagnostic Information):
   • لقطة شاشة للوحة التحكم تُظهر استخدام الموارد
   • مقتطفات سجلات ذات صلة (من القسم 9.2)
   • مخطط الشبكة يُظهر البنية التحتية لـ DNS
   • التغييرات الأخيرة أو أنشطة الصيانة
5. خطوات استكشاف الأخطاء المُجراة (Troubleshooting Steps Already Performed):
   • اذكر جميع خطوات استكشاف الأخطاء التي حاولتها
   • نتائج أوامر التشخيص
   • أي حلول بديلة مؤقتة طُبِّقت

معلومات الاتصال#

• دعم البريد الإلكتروني (Email Support): support@secure-domains.org
• البوابة (Portal): https://dnsarmor.secure-domains.org
• دعم الهاتف (Phone Support): (تحقّق من البوابة للحصول على رقم الهاتف الحالي)
• اتصال الطوارئ (Emergency Contact): (لانقطاعات الإنتاج الحرجة)

مستويات أولوية تذكرة الدعم#

• P1 - حرج (Critical): انقطاع كامل لـ DNS، جميع المستخدمين متأثرون
• P2 - عالٍ (High): انقطاع جزئي لـ DNS، تأثير كبير على المستخدمين
• P3 - متوسط (Medium): أداء متدهور، تأثير محدود على المستخدمين
• P4 - منخفض (Low): مشكلة بسيطة أو تجميلية أو طلب تحسين

⚡ مهم (IMPORTANT) للمشاكل الحرجة P1، اتصل بالدعم الهاتفي فوراً بالإضافة إلى إرسال تذكرة.

القسم 10: الملاحق (Appendices)

10. الملاحق#

الملحق أ: بطاقة المرجع السريع (Appendix A: Quick Reference Card)#

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

الأوامر الحرجة#

# Test DNS resolution nslookup google.com 127.0.0.1 # Check network configuration ip addr show # Verify connectivity ping 8.8.8.8 ping dnsarmor.secure-domains.org # Monitor resources top free -h df -h

اتصالات الطوارئ#

• بريد الدعم (Support Email): support@secure-domains.org
• البوابة (Portal): https://dnsarmor.secure-domains.org

الملحق ب: مسرد المصطلحات (Appendix B: Glossary of Terms)#

الملحق ج: تكوينات نموذجية (Appendix C: Sample Configurations)#

تكوين NXLog نموذجي لـ Active Directory#

انظر القسم 5.3.2 للتكوين الكامل.

تكوين DHCP نموذجي#

Scope: 192.168.1.0/24
Option 006 DNS Servers:
  - 192.168.100.10 (Primary Local Resolver)
  - 192.168.100.11 (Secondary Local Resolver)
  - 192.168.1.1 (Fallback - Corporate DNS)

قائمة نطاقات تجاوز نموذجية#

corp.local
internal.company.com
dc01.corp.local
dc02.corp.local
fileserver.corp.local
lab.local

مُعيدو توجيه DNS نموذجيون#

Primary: 8.8.8.8 (Google Public DNS)
Secondary: 1.1.1.1 (Cloudflare DNS)

الملحق D: حزمة تكامل SIEM (قوالب Logs Connector)#

هذا الملحق هو المرجع المعتمد لتدفقات السجلات الثلاثة التي يرسلها Logs Connector إلى خادم syslog خارجي أو SIEM (القسم 4.2.6)، مع قوالب إعداد جاهزة للنسخ واللصق لكل من ArcSight و Microsoft Sentinel و Splunk و QRadar و Elastic، إضافة إلى تكوين rsyslog على جانب المُجمِّع.

💡 نصيحة (TIP) كل قالب أدناه قابل للتنزيل والنسخ كما هو: انقر اسم الملف لتنزيله، أو استخدم زر نسخ (Copy) المجاور له لنسخ الكتلة كاملة إلى الحافظة. تُولَّد التنزيلات في متصفحك من الصفحة نفسها — دون روابط خارجية.

D.1 تنسيق الإرسال (Wire Format)#

كل سجل يرسله Logs Connector له الشكل التالي:

<PRI>MMM dd HH:mm:ss HOSTNAME TAG: CEF:0|Secure Domains|Logs Connector|1.0.0|<SignatureID>|<Name>|<Sev>|<extension>

• PRI — ‏166 افتراضياً = المِرفق local4 ‏(20) × 8 + الخطورة info ‏(6). المِرفق قابل للتغيير (القسم D.12). خطورة syslog مثبَّتة عمداً على info لكل سجل: خطورة كل حدث موجودة في الحقل السابع من ترويسة CEF، ولو تغيّرت خطورة syslog أيضاً لأسقط مُجمِّعٌ يرشِّح على local4.info سجلات RPZ عالية الخطورة بصمت.
• التأطير (Framing) — ‏RFC 3164 افتراضياً. يحافظ RFC 5424 على السنة ودقة الميلي ثانية. يتوفر تأطير قديم (legacy) بدون <PRI> لعمليات النشر المرحلية (القسم D.12).
• المورّد / المنتج / الإصدار — ‏Secure Domains / Logs Connector / 1.0.0. تعتمد منصات SIEM على زوج المورّد + المنتج لاختيار المُحلِّل ومصدر السجلات، لذا فهذه القيم عقد ثابت لن يتغيّر.

D.2 مرجع حقول CEF#

تُستخدم مفاتيح قاموس CEF القياسية حيثما وُجدت. وكل ما عداها يستخدم آلية السلاسل المخصصة الموسومة (csN + csNLabel) — وهي نقطة الامتداد الرسمية في معيار CEF — ما يجعل كل قيمة موصوفة ذاتياً في واجهة SIEM. ترقيم الخانات متسق عبر التدفقات: ‏cs4 هو دائماً TenantName وcs6 هو دائماً EndpointAgent، لذا تمتد قاعدة ارتباط واحدة عبر كل التدفقات.

D.2.1 ‏RPZ — ‏SignatureID 1001

D.2.2 ‏DNS Query — ‏SignatureID 1002

نفس مجموعة حقول RPZ ناقص act وcs2 وcs3 وcs5.

D.2.4 الاسم المُستعلَم عنه موجود في dhost وفيه فقط

جرى تقييم مفتاح CEF المسمى destinationDnsDomain ورُفض عمداً. فهو مفتاح CEF حقيقي، لكنه يعني "جزء نطاق DNS من الاسم الكامل FQDN" — أي icloud.com وليس mask.icloud.com — وتتصرف برامج فك الترميز وفق هذا المعنى قبل أن يكون لك أي تحكم:

• يعيّنه مُرمِّز CEF في Logstash مباشرة إلى destination.registered_domain
• يعيّنه Sentinel إلى العمود DestinationDnsDomain، الذي يقرؤه محتوى ASIM والتحليلات المدمجة كنطاق قابل للتسجيل (registrable domain)

إرسال الاسم الكامل FQDN هناك كان سيغذي بصمت قيماً مثل mask.icloud.com في حقول يعاملها كل مستهلك كنطاق قابل للتسجيل، ما يُفسد أي تجميع أو اكتشاف يعتمد عليها. كما أن إنتاج القيمة الصحيحة يتطلب قائمة اللواحق العامة (public-suffix list)، وهو ما لا شأن لمُرسِل سجلات به. أما dhost ‏(destinationHostName) فمُعرَّف في القاموس على أنه بهيئة FQDN ويُعيَّن أصلاً في كل منصات SIEM، لذا فهو كافٍ وحده. وعلى المستهلك الذي يحتاج النطاق القابل للتسجيل اشتقاقه لاحقاً في مسار المعالجة.

ℹ️ ملاحظة (NOTE) ما تزال قوالب SIEM أدناه تحتوي على معالجة دفاعية لـ destinationDnsDomain ‏(coalesce، وتراجع case()، وrename مشروط، ونمط في LSX). هذه المعالجات عديمة الأثر تماماً مع الإخراج الحالي، وأُبقيت حتى تظل القوالب صالحة إذا ظهر المفتاح يوماً — من تغيير مستقبلي أو من بيانات تاريخية لدى عميل.

D.2.3 ‏Audit — ‏SignatureID 1003

D.3 قواعد التحليل الواجب على المستهلك احترامها#

القوالب أدناه لكل منصة SIEM تُطبِّق هذه القواعد بالفعل. إذا كتبت مُحلِّلاً خاصاً بك، فاحترم القواعد الخمس كلها:

1. الإفلات (Escaping). يُفلت الامتداد \ ← \\، و= ← \=، والسطر الجديد ← \n. أما العمود | فيُفلت في الترويسة فقط، وأبداً في الامتداد. أزل الإفلات بهذا الترتيب (الشرطة المائلة العكسية أخيراً) وإلا فستتلف القيم التي تحتوي كليهما.
2. القيم قد تحتوي مسافات. لا يوجد اقتباس في CEF؛ تمتد القيمة حتى الرمز key= التالي. لا تقسم الامتداد على المسافات — فذلك سيمزّق قيماً مثل cs6=M7mad MSP Test iPhone [iOS 26.5.2; iPhone16;2].
3. المفاتيح المُصنَّفة النوع قد تغيب. تُحذف src وspt وsourceTranslatedAddress وrt كلياً عند عدم وجود قيمة صالحة بدلاً من ملئها بـ na — لأن منصات SIEM تتحقق من نوع هذه الأعمدة وترفض القيم غير الصالحة. عامل الغياب على أنه "غير معروف"؛ ولا تفترض الوجود.
4. المفاتيح النصية موجودة دائماً، وتستخدم na عند عدم المعرفة. مجموعة المفاتيح لكل SignatureID ثابتة.
5. حجم السجل. يبلغ حجم سجلات RPZ نحو 650 بايت وقد يتجاوز 1024 مع اسم نطاق طويل واسم جهاز طويل. يقتطع RFC 3164 عبر UDP عند 1024 بايت في العديد من المُجمِّعات — فضّل TCP أو TLS أو RELP لسجلات RPZ.

D.4 سجلات نموذجية (Sample Records)#

عيّنات مطابقة بالبايت للتدفقات الثلاثة. استخدمها للتحقق من مُحلِّل أو لحقن سجلات اختبارية عبر logger (القسم 7.2).

‏RPZ ‏(dns-rpz، 1001)

📄 الملف: sample-rpz.cef

<166>Aug  5 00:14:07 secure-domains-local-resolver dns-rpz: CEF:0|Secure Domains|Logs Connector|1.0.0|1001|DNS RPZ|7|rt=1785888847000 dhost=mask.icloud.com src=178.81.193.105 spt=53284 cs1Label=DnsRecordType cs1=A sourceTranslatedAddress=192.168.100.92 cs2Label=RpzPolicy cs2=doh.ioc2rpz cs3Label=RpzRule cs3=mask.icloud.com act=REDIRECT(blocked.secure-domains.org) suser=na shost=na cs4Label=TenantName cs4=Test778 cs5Label=RpzMode cs5=Blocking cs6Label=EndpointAgent cs6=M7mad MSP Test iPhone [iOS 26.5.2; iPhone16;2] flexString1Label=EndpointType flexString1=Mobile Agent v1.1 deviceExternalId=test-msp-lr-proxy dvchost=secure-domains-local-resolver

‏DNS Query ‏(dns-query، 1002)

📄 الملف: sample-query.cef

<166>Aug  5 00:14:09 secure-domains-local-resolver dns-query: CEF:0|Secure Domains|Logs Connector|1.0.0|1002|DNS Query|2|rt=1785888849000 dhost=a.root-servers.net. src=178.81.193.105 spt=38172 cs1Label=DnsRecordType cs1=A suser=na shost=na cs4Label=TenantName cs4=Master-Tenant cs6Label=EndpointAgent cs6=M7mad MSP Test iPhone [iOS 26.5.2; iPhone16;2] flexString1Label=EndpointType flexString1=Mobile Agent v1.1 deviceExternalId=test-msp-lr-proxy dvchost=secure-domains-local-resolver

‏Audit ‏(audit، 1003)

📄 الملف: sample-audit.cef

<166>Aug  5 00:14:11 secure-domains-local-resolver audit: CEF:0|Secure Domains|Logs Connector|1.0.0|1003|Audit Log|5|rt=1785888851000 act=Update cs1Label=ResourceType cs1=Policy cs2Label=ResourceName cs2=Default Policy suser=m7mad cs3Label=UserEmail cs3=m7mad@secure-domains.org src=178.81.193.105 msg=changed action from a\=b to c\=d cs4Label=TenantName cs4=Test778 cs5Label=CustomerName cs5=MSP Reseller deviceExternalId=test-msp-lr-proxy dvchost=secure-domains-local-resolver

D.5 هل تحتاج منصة SIEM لديّ إلى مُحلِّل؟#

‏ArcSight وحدها بلا أي إعداد فعلياً. يستوعب Sentinel و Elastic السجلات دون جهد لكنهما يعرضان أسماء خانات CEF الخام حتى يُحمَّل القالب؛ أما QRadar و Splunk فيحتاجان قالبيهما ليكونا قابلَين للاستخدام أصلاً.

D.6 تكوين المُجمِّع (rsyslog)#

ضع ما يلي في /etc/rsyslog.d/60-secure-domains.conf على مضيف إعادة توجيه السجلات. يستقبل على UDP/TCP 514، ويرفع حد حجم الرسالة، ويعيد التوجيه إلى وكيل Azure Monitor المحلي لأجل Sentinel (أو يكتب إلى ملف لموصلات تتبّع الملفات)، ويُبقي السجلات خارج /var/log/syslog:

📄 الملف: 60-secure-domains.conf

# Secure Domains -> collector forwarding (rsyslog)
# Place in /etc/rsyslog.d/60-secure-domains.conf on the log-forwarder host.
#
# The resolver emits RFC3164 on facility local4 (PRI 166 = local4.info).
# This is exactly what the Microsoft Sentinel CEF-via-AMA pipeline expects,
# and it is why the resolver defaults to local4 rather than leaving the PRI
# absent: with no <PRI>, rsyslog assigns facility "user" and a local4 filter
# silently drops every record.

# --- receive ---------------------------------------------------------
module(load="imudp")
input(type="imudp" port="514")
module(load="imtcp")
input(type="imtcp" port="514")

# Raise the max message size: RPZ records run ~650 bytes and can exceed the
# 1024-byte default with a long FQDN plus a long device name. Truncation is
# silent, and a truncated CEF record fails to parse entirely.
$MaxMessageSize 8k

# --- forward to the local Azure Monitor Agent (Sentinel) --------------
# The AMA CEF connector listens on 127.0.0.1:28330.
local4.* @@127.0.0.1:28330

# --- or: write to file for a file-tailing connector -------------------
# template(name="RawMsg" type="string" string="%rawmsg%\n")
# local4.*  action(type="omfile" file="/var/log/secure-domains-cef.log" template="RawMsg")

# Do not also send these to /var/log/syslog
local4.*  stop

⚡ مهم (IMPORTANT) يستخدم المُحلِّل المِرفق local4 افتراضياً بدلاً من ترك PRI غائباً لسبب وجيه: بدون <PRI> يعيّن rsyslog المِرفق user، وعندها يُسقط مرشِّح local4 كل السجلات بصمت.

D.7 إعداد ArcSight#

‏CEF هو التنسيق الأصلي في ArcSight، لذا لا حاجة إلى مُحلِّل أو FlexConnector:

1. الموصّل (Connector): ‏SmartConnector لـ Syslog NG Daemon (أو Syslog File)
2. يُعرَّف الجهاز تلقائياً من ترويسة CEF: ‏Device Vendor = Secure Domains، و Device Product = Logs Connector، و Device Version = 1.0.0
3. تُعيَّن المفاتيح القياسية مباشرة على حقول ArcSight: ‏src ← Source Address، وspt ← Source Port، وdhost ← Destination Host Name، وact ← Device Action، وsuser ← Source User Name، وshost ← Source Host Name، وmsg ← Message، وrt ← Device Receipt Time، وdeviceExternalId ← Device External ID، وdvchost ← Device Host Name، وsourceTranslatedAddress ← Source Translated Address
4. تُعرض cs1..cs6 تلقائياً باستخدام قيم csNLabel الخاصة بها، فتُظهر واجهة ESM/Logger عبارة "TenantName" بدلاً من "Device Custom String 4"

اختياري: تصنيف الأحداث (Event Categorization)

احفظ ما يلي باسم securedomains_categorization.csv وضعه في $ARCSIGHT_HOME/user/agent/acp/categorizer/current/securedomains/logsconnector.csv على مضيف الموصّل لتعبئة حقول التصنيف، وهي ما يعتمد عليه معظم محتوى الارتباط المدمج:

📄 الملف: securedomains_categorization.csv

Event Name,categoryObject,categoryBehavior,categoryTechnique,categoryDeviceGroup,categorySignificance,categoryOutcome
DNS RPZ,/Host/Application/Service,/Access/Start,/Exploit/Denial of Service,/Firewall,/Informational/Warning,/Failure
DNS Query,/Host/Application/Service,/Access/Start,,/IDS/Network,/Informational,/Success
Audit Log,/Host/Application,/Modify/Configuration,,/Application,/Informational,/Success

D.8 إعداد Microsoft Sentinel#

موصّل CEF عبر AMA يفك ترميز CEF إلى CommonSecurityLog بالفعل، لذا لا حاجة إلى مُحلِّل مخصص للاستيعاب. تقتصر دوال KQL أدناه على إعادة تسمية أعمدة CEF العامة إلى أسماء ذات معنى حتى لا يضطر المحللون والقواعد إلى تذكّر ما يحمله DeviceCustomString4. احفظ كل كتلة كدالة مساحة عمل (Workspace Function) بالاسم الوارد في تعليقها الترويسي. يُحسم العمود QueriedDomain عبر سلسلة تراجع case() ‏(DestinationHostName ← DestinationDnsDomain ← الخام في AdditionalExtensions) حتى لا يؤدي سقوط مفتاح واحد إلى إفراغ أهم عمود في المُحلِّل — راجع D.2.4 لمعرفة سبب أولوية dhost.

⚡ مهم (IMPORTANT) شرط مسبق: يجب أن يقبل مُجمِّع AMA CEF المِرفق local4 — فهذا ما يرسله المُحلِّل ‏(PRI 166 = ‏local4.info). إذا كان DCR لديك يرشِّح المرافق، فأدرج local4، وإلا أُسقطت السجلات قبل وصولها إلى مساحة العمل ولن تُرجع أيٌّ من هذه الدوال شيئاً.

📄 الملف: SecureDomains_Parsers.kql

// =====================================================================
// Secure Domains — Microsoft Sentinel parsers
// =====================================================================
// The CEF-via-AMA connector already decodes CEF into CommonSecurityLog, so
// NO custom parser is required to ingest. These functions only rename the
// generic CEF columns to meaningful ones so analysts and rules do not have to
// remember what DeviceCustomString4 holds.
//
// Save each block as a Workspace Function with the name in the header comment.
//
// Prerequisite: the AMA CEF collector must accept facility local4 — that is
// what the resolver sends (PRI 166 = local4.info). If your DCR filters
// facilities, include local4 or records are dropped BEFORE reaching the
// workspace and nothing here will run.
// =====================================================================


// --- Function name: SecureDomainsRPZ ---------------------------------
CommonSecurityLog
| where DeviceVendor == "Secure Domains"
    and DeviceProduct == "Logs Connector"
    and DeviceEventClassID == "1001"
| project
    TimeGenerated,
    EventTime            = ReceiptTime,
    ResolverId           = DeviceExternalID,
    ResolverHost         = DeviceName,
    TenantName           = DeviceCustomString4,
    // dhost and destinationDnsDomain carry the SAME queried FQDN (the resolver
    // emits the full name in both). dhost stays primary because FIELD-REFERENCE
    // documents it as always present; the fallbacks exist so a single dropped key
    // cannot blank out the most important column in the whole parser.
    // Fallback 2 is the mapped column: Microsoft's CEF-to-CommonSecurityLog table
    // maps CEF `destinationDnsDomain` -> `DestinationDnsDomain`, a real string
    // column in the fixed schema. Fallback 3 covers the case where a collector or
    // DCR does not apply that mapping and leaves the raw key in AdditionalExtensions.
    // case() rather than coalesce() because CommonSecurityLog fills absent keys with
    // empty strings, not nulls, and coalesce() would happily return the empty string.
    QueriedDomain        = case(
                               isnotempty(DestinationHostName),  DestinationHostName,
                               isnotempty(DestinationDnsDomain), DestinationDnsDomain,
                               extract(@"destinationDnsDomain=([^\s;]+)", 1, AdditionalExtensions)),
    ClientPublicIP       = SourceIP,
    ClientPort           = SourcePort,
    ClientPrivateIP      = SourceTranslatedAddress,
    RecordType           = DeviceCustomString1,
    RpzPolicy            = DeviceCustomString2,
    RpzRule              = DeviceCustomString3,
    RpzMode              = DeviceCustomString5,
    ActionApplied        = DeviceAction,
    UserName             = SourceUserName,
    ComputerName         = SourceHostName,
    EndpointAgent        = DeviceCustomString6,
    EndpointType         = FlexString1,
    Severity             = LogSeverity
| extend IsBlocked = ActionApplied startswith "REDIRECT"


// --- Function name: SecureDomainsDNSQuery ----------------------------
CommonSecurityLog
| where DeviceVendor == "Secure Domains"
    and DeviceProduct == "Logs Connector"
    and DeviceEventClassID == "1002"
| project
    TimeGenerated,
    EventTime            = ReceiptTime,
    ResolverId           = DeviceExternalID,
    ResolverHost         = DeviceName,
    TenantName           = DeviceCustomString4,
    // Same dhost / destinationDnsDomain duplication as the RPZ stream — see the
    // comment in SecureDomainsRPZ for why the fallback chain is shaped this way.
    // Kept identical on purpose so SecureDomainsAll unions a consistent column.
    QueriedDomain        = case(
                               isnotempty(DestinationHostName),  DestinationHostName,
                               isnotempty(DestinationDnsDomain), DestinationDnsDomain,
                               extract(@"destinationDnsDomain=([^\s;]+)", 1, AdditionalExtensions)),
    ClientPublicIP       = SourceIP,
    ClientPort           = SourcePort,
    ClientPrivateIP      = SourceTranslatedAddress,
    RecordType           = DeviceCustomString1,
    UserName             = SourceUserName,
    ComputerName         = SourceHostName,
    EndpointAgent        = DeviceCustomString6,
    EndpointType         = FlexString1


// --- Function name: SecureDomainsAudit -------------------------------
CommonSecurityLog
| where DeviceVendor == "Secure Domains"
    and DeviceProduct == "Logs Connector"
    and DeviceEventClassID == "1003"
| project
    TimeGenerated,
    EventTime            = ReceiptTime,
    ResolverId           = DeviceExternalID,
    ResolverHost         = DeviceName,
    TenantName           = DeviceCustomString4,
    CustomerName         = DeviceCustomString5,
    ActionType           = DeviceAction,
    ResourceType         = DeviceCustomString1,
    ResourceName         = DeviceCustomString2,
    OperatorUser         = SourceUserName,
    OperatorEmail        = DeviceCustomString3,
    OperatorIP           = SourceIP,
    Details              = Message


// --- Function name: SecureDomainsAll (union across streams) ----------
union
    (SecureDomainsRPZ      | extend Stream = "RPZ"),
    (SecureDomainsDNSQuery | extend Stream = "Query"),
    (SecureDomainsAudit    | extend Stream = "Audit")


// =====================================================================
// ASIM normalisation (optional)
// =====================================================================
// Map the DNS streams onto the ASIM DNS schema so built-in ASIM content works.
// Function name: ASimDnsSecureDomains
//
// The new destinationDnsDomain CEF key gets NO ASIM field of its own: ASIM DNS
// models the queried name as DnsQuery and nothing else, and the key is a verbatim
// duplicate of dhost. Feeding it in via QueriedDomain (which already resolves both
// keys) keeps DnsQuery single-valued and keeps built-in ASIM DNS content working.
union
    (SecureDomainsRPZ | extend _Blocked = true),
    (SecureDomainsDNSQuery | extend _Blocked = false, RpzMode = "", ActionApplied = "")
| extend
    EventVendor       = "Secure Domains",
    EventProduct      = "Logs Connector",
    EventType         = "lookup",
    EventSubType      = "response",
    EventSchema       = "Dns",
    EventSchemaVersion= "0.1.6",
    EventResult       = iff(_Blocked, "Failure", "Success"),
    DnsResponseCodeName = iff(_Blocked, "NXDOMAIN", "NOERROR"),
    DvcAction         = iff(_Blocked, "Block", "Allow"),
    SrcIpAddr         = ClientPublicIP,
    SrcPortNumber     = toint(ClientPort),
    DnsQuery          = QueriedDomain,   // queried FQDN, from dhost / destinationDnsDomain
    DnsQueryTypeName  = RecordType,
    Dvc               = ResolverHost,
    DvcHostname       = ResolverHost,
    DvcId             = ResolverId,
    SrcUsername       = UserName,
    SrcHostname       = ComputerName
| project-away _Blocked


// =====================================================================
// Example detections
// =====================================================================

// Endpoints with a spike in blocked lookups (possible C2 beaconing)
SecureDomainsRPZ
| where IsBlocked
| summarize Blocks = count(), Domains = dcount(QueriedDomain)
    by EndpointAgent, ClientPublicIP, TenantName, bin(TimeGenerated, 1h)
| where Blocks > 50
| order by Blocks desc

// A resolver that stopped reporting — silent-failure watchdog
SecureDomainsAll
| summarize LastSeen = max(TimeGenerated) by ResolverId
| where LastSeen < ago(30m)

// Portal changes made outside business hours
SecureDomainsAudit
| extend Hour = datetime_part("hour", TimeGenerated)
| where Hour < 6 or Hour > 20
| project TimeGenerated, OperatorUser, ActionType, ResourceType, ResourceName, TenantName

D.9 إعداد Splunk#

لا يملك Splunk تحليل CEF أصلياً، لذا تُعرِّف حزمة إضافة تقنية (TA) صغيرة عملية الاستخراج. أنشئ مجلد التطبيق $SPLUNK_HOME/etc/apps/TA-secure-domains/، وضع ملفات .conf الأربعة أدناه في مجلده default/ وملف CSV الخاص بالبحث في مجلده lookups/، ثم أعد تشغيل Splunk. أنواع المصادر مقسّمة لكل تدفق حتى يمكن أن يختلف وسم CIM ‏(DNS مقابل Change). حقل query الخاص بـ CIM هو حقل محسوب — coalesce(destinationDnsDomain, dhost) — وليس اسماً بديلاً (alias)، فيبقى بذلك أحادي القيمة (الاسم البديل المزدوج كان سيكسر | stats count by query وإزالة التكرار) ويظل صحيحاً سواء ظهر destinationDnsDomain يوماً أم لا (راجع D.2.4).

props.conf

📄 الملف: props.conf

# Secure Domains — Splunk props.conf
# Place in $SPLUNK_HOME/etc/apps/TA-secure-domains/default/
#
# Splunk has no native CEF parsing, so this defines the extraction. Source
# types are split per stream so CIM tagging can differ (DNS vs Change).

[secure_domains:cef]
SHOULD_LINEMERGE = false
LINE_BREAKER = ([\r\n]+)
TRUNCATE = 8192
TIME_PREFIX = \srt=
TIME_FORMAT = %s%3N
MAX_TIMESTAMP_LOOKAHEAD = 20
# rt is epoch MILLIseconds. If rt is absent (typed field omitted) Splunk falls
# back to the syslog header time, which is why the fallback is left enabled.
KV_MODE = none
REPORT-cef_header = cef_header_extract
REPORT-cef_extension = cef_extension_kv
EVAL-vendor = "Secure Domains"
EVAL-product = "Logs Connector"
FIELDALIAS-sd_common = src AS src_ip dhost AS query suser AS user shost AS src_host
LOOKUP-sd_signature = secure_domains_signature signature_id OUTPUT stream_name

# Per-stream sourcetypes. Route to these with a transform on the syslog TAG
# (dns-rpz / dns-query / audit) — see transforms.conf.
[secure_domains:dns-rpz]
SHOULD_LINEMERGE = false
LINE_BREAKER = ([\r\n]+)
TIME_PREFIX = \srt=
TIME_FORMAT = %s%3N
KV_MODE = none
REPORT-cef_header = cef_header_extract
REPORT-cef_extension = cef_extension_kv
FIELDALIAS-sd_rpz = src AS src_ip suser AS user cs1 AS record_type cs2 AS rpz_policy cs3 AS rpz_rule cs4 AS tenant_name cs5 AS rpz_mode cs6 AS endpoint_agent flexString1 AS endpoint_type
# query (CIM Network Resolution) is a calculated field, not a FIELDALIAS,
# because the FQDN now arrives twice: dhost and destinationDnsDomain hold the
# identical value. Aliasing both onto query would make it multivalue with the
# same string twice, which breaks `| stats count by query` and dedup. coalesce
# prefers the explicit DNS key but falls back to dhost so events indexed before
# destinationDnsDomain existed stay searchable on the same CIM field name.
# Calculated fields run after aliasing, so this wins regardless of ordering.
EVAL-query = coalesce(destinationDnsDomain, dhost)
EVAL-action = if(match(act,"^REDIRECT"),"blocked","allowed")
EVAL-vendor_product = "Secure Domains Logs Connector"

[secure_domains:dns-query]
SHOULD_LINEMERGE = false
LINE_BREAKER = ([\r\n]+)
TIME_PREFIX = \srt=
TIME_FORMAT = %s%3N
KV_MODE = none
REPORT-cef_header = cef_header_extract
REPORT-cef_extension = cef_extension_kv
FIELDALIAS-sd_query = src AS src_ip suser AS user cs1 AS record_type cs4 AS tenant_name cs6 AS endpoint_agent flexString1 AS endpoint_type
# Same duplicate-FQDN situation as dns-rpz — see the note in that stanza for why
# this is a coalesce EVAL instead of a second alias onto query.
EVAL-query = coalesce(destinationDnsDomain, dhost)
EVAL-action = "allowed"
EVAL-vendor_product = "Secure Domains Logs Connector"

[secure_domains:audit]
SHOULD_LINEMERGE = false
LINE_BREAKER = ([\r\n]+)
TIME_PREFIX = \srt=
TIME_FORMAT = %s%3N
KV_MODE = none
REPORT-cef_header = cef_header_extract
REPORT-cef_extension = cef_extension_kv
FIELDALIAS-sd_audit = src AS src_ip suser AS user cs1 AS object_category cs2 AS object cs3 AS user_email cs4 AS tenant_name cs5 AS customer_name msg AS command
EVAL-vendor_product = "Secure Domains Logs Connector"

transforms.conf

📄 الملف: transforms.conf

# Secure Domains — Splunk transforms.conf

# --- CEF header: the seven pipe-delimited fields -------------------------
# Pipes inside header values are escaped as \| so the negated class must allow
# an escaped pipe through: (?:[^|\\]|\\.)*
[cef_header_extract]
REGEX = CEF:(?<cef_version>\d+)\|(?<vendor>(?:[^|\\]|\\.)*)\|(?<product>(?:[^|\\]|\\.)*)\|(?<product_version>(?:[^|\\]|\\.)*)\|(?<signature_id>(?:[^|\\]|\\.)*)\|(?<name>(?:[^|\\]|\\.)*)\|(?<severity>(?:[^|\\]|\\.)*)\|
MV_ADD = false

# --- CEF extension: key=value, values may contain spaces -----------------
# A value runs until the next ' key=' token. The lookahead is what makes
# space-bearing values (device names, actions) parse correctly. Do NOT
# replace this with a whitespace split.
[cef_extension_kv]
REGEX = (?:^|\s)([A-Za-z][A-Za-z0-9]*)=((?:[^\s\\]|\\.)*(?:\s(?![A-Za-z][A-Za-z0-9]*=)(?:[^\s\\]|\\.)*)*)
FORMAT = $1::$2
MV_ADD = true

# --- Route each stream to its own sourcetype by syslog TAG ---------------
[secure_domains_route_sourcetype]
REGEX = \s(dns-rpz|dns-query|audit):\s+CEF:0\|
FORMAT = sourcetype::secure_domains:$1
DEST_KEY = MetaData:Sourcetype

[secure_domains_signature]
filename = secure_domains_signature.csv

eventtypes.conf

📄 الملف: eventtypes.conf

# Secure Domains — CIM eventtypes
[secure_domains_dns_rpz]
search = sourcetype=secure_domains:dns-rpz

[secure_domains_dns_query]
search = sourcetype=secure_domains:dns-query

[secure_domains_dns_all]
search = sourcetype=secure_domains:dns-rpz OR sourcetype=secure_domains:dns-query

[secure_domains_audit]
search = sourcetype=secure_domains:audit

tags.conf

📄 الملف: tags.conf

# Secure Domains — CIM data model tagging
# DNS streams -> Network Resolution (DNS)
[eventtype=secure_domains_dns_all]
network = enabled
resolution = enabled
dns = enabled

# RPZ blocks additionally satisfy Intrusion Detection / Alerts
[eventtype=secure_domains_dns_rpz]
attack = enabled

# Portal audit -> Change
[eventtype=secure_domains_audit]
change = enabled
audit = enabled

inputs.conf (مثال)

📄 الملف: inputs.conf.example

# Secure Domains — example input.
# The resolver sends RFC3164 syslog on facility local4 (PRI 166).
# Prefer TCP/TLS over UDP: RPZ records approach the 1024-byte UDP limit.

[tcp://514]
sourcetype = secure_domains:cef
index = netops
# The transforms.conf router re-assigns the sourcetype per stream using the
# syslog TAG, so this value is only the pre-routing default.

lookups/secure_domains_signature.csv

📄 الملف: secure_domains_signature.csv

signature_id,stream_name
1001,DNS RPZ
1002,DNS Query
1003,Audit Log

D.10 إعداد QRadar#

1. مصدر السجلات (Log Source)
   • نوع مصدر السجلات: Universal CEF
   • البروتوكول: ‏Syslog ‏(يوصى بـ TCP؛ راجع تحذير UDP في D.3)
   • معرّف مصدر السجلات: اسم مضيف المُحلِّل، وهو حقل HOSTNAME في syslog ويصل أيضاً كـ dvchost / deviceExternalId
2. امتداد مصدر السجلات (Log Source Extension): ‏Admin ← Data Sources ← Log Source Extensions ← Add؛ ارفع ملف LSX أدناه واربطه بمصدر السجلات
3. خريطة QID: استورد خريطة QID أدناه عبر /opt/qradar/bin/qidmap_cli.sh -i -f SecureDomains_QIDmap.csv. بدونها يصل كل سجل كحدث مجهول ولا يمكن استخدامه في القواعد أو التقارير بالاسم
4. خصائص الأحداث المخصصة (CEPs): أنشئ CEPs للسلاسل المخصصة الموسومة لتصبح قابلة للبحث بالاسم — ‏cs1 DnsRecordType، وcs2 RpzPolicy، وcs3 RpzRule، وcs4 TenantName، وcs5 RpzMode، وcs6 EndpointAgent، وflexString1 EndpointType (أنماط regex موجودة في LSX؛ والمعاني في D.2)

⚡ مهم (IMPORTANT) خاصية CEP لاسم الاستعلام ليست اختيارية إن كنت تنوي البحث به. لا يملك نموذج الأحداث المُوحَّد في QRadar أي حقل لاسم استعلام DNS — فقائمة حقول المُطابِق في LSX موجّهة نحو الشبكة والهوية، ولا شيء فيها يصف نطاقاً مُستعلَماً عنه. لذا فإن CEP هي الآلية الصحيحة (وهي ذات الطريق الذي يسلكه تطبيق QRadar DNS Analyzer من IBM لحقول DNS لديه): استخدم النمط ext_dst_dns_domain من LSX، ومجموعة الالتقاط 1، وفعّل Optimize parsing لتكون الخاصية قابلة للبحث دون مسح الحمولة. حدِّد نطاق CEP بمعرّفات QID الخاصة بـ DNS ‏(1001/1002) — فسجلات التدقيق (1003) لا تحمل اسم استعلام، وأي نطاق أوسع يهدر تقييم regex على كل حدث تدقيق. يبقى dhost مُحلَّلاً أصلاً بواسطة Universal CEF DSM وهو الطريق الذي لا يحتاج أي إعداد للوصول إلى اسم الاستعلام.

⚠️ حرج (CRITICAL) لا تعيّن اسم الاستعلام على حقل المُطابِق HostName لتفادي إنشاء CEP. فحقل HostName هو اسم مضيف الهوية ويُغذَّى أصلاً من shost (اسم حاسوب العميل)؛ والكتابة فوقه باسم النطاق المُستعلَم عنه ستُلحق هويات أصول زائفة مثل mask.icloud.com بعنوان IP الخاص بالعميل وتُفسد قاعدة بيانات الأصول.

SecureDomains_LogSourceExtension.xml

📄 الملف: SecureDomains_LogSourceExtension.xml

<?xml version="1.0" encoding="UTF-8"?>
<!--
  Secure Domains - QRadar Log Source Extension (LSX)

  Import: Admin > Data Sources > Log Source Extensions > Add, upload this file,
  then attach it to the log source whose type is "Universal CEF".

  QRadar's Universal CEF DSM already parses standard CEF keys. This extension
  adds two things it cannot infer:
    1. EventCategory taken from the CEF SignatureID (1001/1002/1003), so each
       stream maps to its own QID instead of everything collapsing to one
       "Unknown CEF" event.
    2. Custom property extraction for the labelled cs1..cs6 / flexString1
       fields, plus destinationDnsDomain, which QRadar otherwise stores
       unparsed. QRadar's normalised event model has no DNS query name field,
       so these patterns exist to be reused verbatim as the regex of a Custom
       Event Property (see README.md) rather than to feed a matcher.
-->
<device-extension xmlns="event_parsing/device_extension">

  <pattern id="cef_signature_id"    xmlns=""><![CDATA[CEF:\d+\|[^|]*\|[^|]*\|[^|]*\|([^|]*)\|]]></pattern>
  <pattern id="cef_name"            xmlns=""><![CDATA[CEF:\d+\|[^|]*\|[^|]*\|[^|]*\|[^|]*\|([^|]*)\|]]></pattern>
  <pattern id="cef_severity"        xmlns=""><![CDATA[CEF:\d+\|[^|]*\|[^|]*\|[^|]*\|[^|]*\|[^|]*\|([^|]*)\|]]></pattern>

  <!-- Values may contain spaces; each stops at the next ' key=' token. -->
  <pattern id="ext_src"             xmlns=""><![CDATA[(?:^|\s)src=(\S+)]]></pattern>
  <pattern id="ext_spt"             xmlns=""><![CDATA[(?:^|\s)spt=(\d+)]]></pattern>
  <pattern id="ext_dhost"           xmlns=""><![CDATA[(?:^|\s)dhost=(\S+)]]></pattern>
  <!-- Same queried FQDN as dhost, under the CEF dictionary's DNS-specific key.
       Kept as its own pattern because a DNS-aware consumer keys on this name,
       and because dhost may be dropped from the stream later without this one
       following it. The lookahead (not \S+) is used for consistency with the
       other free-text keys: it is the form that stays correct if a value ever
       arrives with a space in it, e.g. an escaped or malformed name. -->
  <pattern id="ext_dst_dns_domain"  xmlns=""><![CDATA[(?:^|\s)destinationDnsDomain=(.*?)(?=\s[A-Za-z][A-Za-z0-9]*=|$)]]></pattern>
  <pattern id="ext_suser"           xmlns=""><![CDATA[(?:^|\s)suser=(.*?)(?=\s[A-Za-z][A-Za-z0-9]*=|$)]]></pattern>
  <pattern id="ext_shost"           xmlns=""><![CDATA[(?:^|\s)shost=(.*?)(?=\s[A-Za-z][A-Za-z0-9]*=|$)]]></pattern>
  <pattern id="ext_act"             xmlns=""><![CDATA[(?:^|\s)act=(.*?)(?=\s[A-Za-z][A-Za-z0-9]*=|$)]]></pattern>
  <pattern id="ext_stranslated"     xmlns=""><![CDATA[(?:^|\s)sourceTranslatedAddress=(\S+)]]></pattern>
  <pattern id="ext_devext_id"       xmlns=""><![CDATA[(?:^|\s)deviceExternalId=(.*?)(?=\s[A-Za-z][A-Za-z0-9]*=|$)]]></pattern>
  <pattern id="ext_dvchost"         xmlns=""><![CDATA[(?:^|\s)dvchost=(\S+)]]></pattern>
  <pattern id="ext_cs1"             xmlns=""><![CDATA[(?:^|\s)cs1=(.*?)(?=\s[A-Za-z][A-Za-z0-9]*=|$)]]></pattern>
  <pattern id="ext_cs2"             xmlns=""><![CDATA[(?:^|\s)cs2=(.*?)(?=\s[A-Za-z][A-Za-z0-9]*=|$)]]></pattern>
  <pattern id="ext_cs3"             xmlns=""><![CDATA[(?:^|\s)cs3=(.*?)(?=\s[A-Za-z][A-Za-z0-9]*=|$)]]></pattern>
  <pattern id="ext_cs4"             xmlns=""><![CDATA[(?:^|\s)cs4=(.*?)(?=\s[A-Za-z][A-Za-z0-9]*=|$)]]></pattern>
  <pattern id="ext_cs5"             xmlns=""><![CDATA[(?:^|\s)cs5=(.*?)(?=\s[A-Za-z][A-Za-z0-9]*=|$)]]></pattern>
  <pattern id="ext_cs6"             xmlns=""><![CDATA[(?:^|\s)cs6=(.*?)(?=\s[A-Za-z][A-Za-z0-9]*=|$)]]></pattern>
  <pattern id="ext_flex1"           xmlns=""><![CDATA[(?:^|\s)flexString1=(.*?)(?=\s[A-Za-z][A-Za-z0-9]*=|$)]]></pattern>

  <match-group order="1" description="Secure Domains Logs Connector" device-type-id-override="4000">

    <matcher field="EventCategory"   order="1" pattern-id="cef_signature_id" capture-group="1"/>
    <matcher field="EventName"       order="1" pattern-id="cef_name"         capture-group="1"/>
    <matcher field="Severity"        order="1" pattern-id="cef_severity"     capture-group="1"/>

    <matcher field="SourceIp"        order="1" pattern-id="ext_src"          capture-group="1"/>
    <matcher field="SourcePort"      order="1" pattern-id="ext_spt"          capture-group="1"/>
    <matcher field="UserName"        order="1" pattern-id="ext_suser"        capture-group="1"/>
    <matcher field="Identity HostName" order="1" pattern-id="ext_shost"      capture-group="1"/>
    <matcher field="PreNatSourceIp"  order="1" pattern-id="ext_stranslated"  capture-group="1"/>
    <matcher field="DeviceId"        order="1" pattern-id="ext_devext_id"    capture-group="1"/>

    <event-match-multiple device-event-category="1001" event-name="DNS RPZ"    severity="7"/>
    <event-match-multiple device-event-category="1002" event-name="DNS Query"  severity="2"/>
    <event-match-multiple device-event-category="1003" event-name="Audit Log"  severity="5"/>

  </match-group>
</device-extension>

ℹ️ ملاحظة (NOTE) القيمة device-type-id-override="4000" في ملف LSX هي قيمة مؤقتة. استبدلها بمعرّف نوع الجهاز الذي يعيّنه QRadar لمصدر سجلات Universal CEF لديك.

SecureDomains_QIDmap.csv

📄 الملف: SecureDomains_QIDmap.csv

name,description,severity,lowlevelcategory,eventid,vendorid
DNS RPZ Block,Secure Domains DNS firewall applied an RPZ policy to a lookup,7,18054,1001,0
DNS Query,Secure Domains resolver answered a DNS lookup,2,18051,1002,0
Portal Audit,Secure Domains portal configuration change,5,8054,1003,0

D.11 إعداد Elastic#

تكامل CEF في Elastic يفك ترميز الغلاف بالفعل، لذا لا يلزم شيء للاستيعاب. يقوم خط أنابيب الاستيعاب الاختياري أدناه بإعادة تسمية السلاسل المخصصة المفكوكة إلى حقول بأسلوب ECS ذات معنى ويضبط event.dataset / event.category لكل تدفق. أنشئه عبر PUT _ingest/pipeline/secure-domains-cef (أو من Kibana ← Stack Management ← Ingest Pipelines) واربطه بتدفق بيانات تكامل CEF:

يُغذَّى dns.question.name من destinationHostName، مع إعادة تسمية تراجعية مشروطة من destinationDnsDomain فقط عند غياب المصدر الأساسي (مع إسقاط القيمة المكررة حتى لا يتصادم الاثنان أبداً — راجع D.2.4). لا يُعيَّن destinationDnsDomain عمداً إلى dns.question.registered_domain: فهذا المُنتِج يضع فيه الاسم الكامل FQDN لا نطاقاً قابلاً للتسجيل — اشتق registered_domain لاحقاً في المسار (مثلاً بمعالج registered_domain فوق dns.question.name) إن احتجته. تنبيه: قد يقوم فاكّ ترميز CEF العامل بنمط ECS بنسخ destinationDnsDomain بنفسه إلى destination.registered_domain (مُرمِّز Logstash CEF يوثّق هذا التعيين)؛ تحقّق من ذلك في بيئتك وأسقطه هناك إن وُجد.

📄 الملف: secure-domains-cef-pipeline.json

{
  "description": "Secure Domains CEF -> ECS. The Elastic CEF integration already decodes the envelope; this pipeline renames the decoded custom strings into meaningful ECS-ish fields. DNS records (SignatureID 1001/1002) carry the queried FQDN twice, in dhost and destinationDnsDomain; audit records (1003) carry neither. destinationHostName is the authoritative source for dns.question.name; destinationDnsDomain is used only as a fallback when destinationHostName is absent, and is dropped when it duplicates the value already mapped, so the two never collide on one target. destinationDnsDomain is deliberately NOT mapped to dns.question.registered_domain: this producer puts the full FQDN in it, not a registrable domain. Derive registered_domain/top_level_domain downstream (e.g. a registered_domain processor over dns.question.name) if you need them. Caveat: if the upstream CEF decoder runs in ECS mode it may itself copy destinationDnsDomain to destination.registered_domain (the Logstash CEF codec documents that mapping); that copy would also hold the full FQDN, so verify on your deployment and drop it there if present.",
  "processors": [
    { "set": { "field": "event.module",  "value": "secure_domains" } },
    { "set": { "field": "observer.vendor", "value": "Secure Domains" } },
    { "set": { "field": "observer.product", "value": "Logs Connector" } },
    { "rename": { "field": "cef.extensions.deviceExternalId", "target_field": "observer.name", "ignore_missing": true } },
    { "rename": { "field": "cef.extensions.deviceHostName",   "target_field": "observer.hostname", "ignore_missing": true } },
    { "rename": { "field": "cef.extensions.destinationHostName", "target_field": "dns.question.name", "ignore_missing": true } },
    { "rename": { "field": "cef.extensions.destinationDnsDomain", "target_field": "dns.question.name", "ignore_missing": true, "if": "ctx.dns?.question?.name == null" } },
    { "remove": { "field": "cef.extensions.destinationDnsDomain", "ignore_missing": true, "if": "ctx.dns?.question?.name != null && ctx.dns.question.name == ctx.cef?.extensions?.destinationDnsDomain" } },
    { "rename": { "field": "cef.extensions.deviceCustomString1", "target_field": "dns.question.type", "ignore_missing": true } },
    { "rename": { "field": "cef.extensions.sourceAddress", "target_field": "source.ip", "ignore_missing": true } },
    { "rename": { "field": "cef.extensions.sourcePort",    "target_field": "source.port", "ignore_missing": true } },
    { "rename": { "field": "cef.extensions.sourceTranslatedAddress", "target_field": "source.nat.ip", "ignore_missing": true } },
    { "rename": { "field": "cef.extensions.sourceUserName", "target_field": "user.name", "ignore_missing": true } },
    { "rename": { "field": "cef.extensions.sourceHostName", "target_field": "host.name", "ignore_missing": true } },
    { "rename": { "field": "cef.extensions.deviceAction",   "target_field": "event.action", "ignore_missing": true } },
    { "rename": { "field": "cef.extensions.deviceCustomString4", "target_field": "organization.name", "ignore_missing": true } },
    { "rename": { "field": "cef.extensions.deviceCustomString2", "target_field": "rule.ruleset", "ignore_missing": true } },
    { "rename": { "field": "cef.extensions.deviceCustomString3", "target_field": "rule.name", "ignore_missing": true } },
    { "rename": { "field": "cef.extensions.deviceCustomString6", "target_field": "device.model.name", "ignore_missing": true } },
    { "rename": { "field": "cef.extensions.flexString1", "target_field": "device.manufacturer", "ignore_missing": true } },
    { "script": { "lang": "painless", "source": "def sid = ctx.cef?.device?.event_class_id; if (sid == '1001') { ctx.event.dataset = 'secure_domains.rpz'; ctx.event.category = ['network']; ctx.event.type = ['denied','info']; } else if (sid == '1002') { ctx.event.dataset = 'secure_domains.query'; ctx.event.category = ['network']; ctx.event.type = ['allowed','info']; } else if (sid == '1003') { ctx.event.dataset = 'secure_domains.audit'; ctx.event.category = ['configuration']; ctx.event.type = ['change']; }" } }
  ]
}

D.12 متقدم: خيارات الغلاف والتراجع (Rollback)#

حلّ كلٌ من تنسيق امتداد CEF وغلاف syslog محل تنسيق إخراج أقدم. إذا لم يكن مستهلك لاحق جاهزاً بعد، يمكنك التراجع لكل مُرسِل على حدة دون أي تغيير برمجي بإضافة رايات إلى سطر ExecStart في وحدة خدمة المُرسِل على طرفية الجهاز الافتراضي لـ Local Resolver (وحدة systemd لكل تدفق: dns-rpz وdns-query وaudit):

استخدم --legacy-extension --syslog-framing=legacy معاً للتراجع الكامل إلى الإخراج السابق للتغيير.

⚠️ حرج (CRITICAL) لا يُصدر --syslog-framing=legacy أي <PRI>، لذا سيصنّف rsyslog السجلات تحت المِرفق user — وعندها سيُسقطها بصمت أيُّ مرشِّح مُجمِّع على local4 (بما في ذلك قالب D.6 وقاعدة DCR في Sentinel). لا تستخدم التأطير القديم إلا مع مستهلكين يتوقعون التنسيق القديم.

نهاية المستند (END OF DOCUMENT)

DNS Armor™ Local Resolver - دليل النشر الشامل

v2.1 · يوليو 2026

© 2026 Secure Domains - جميع الحقوق محفوظة

للدعم التقني: support@secure-domains.org
البوابة: https://dnsarmor.secure-domains.org