كيف تدقق في الوضع الأمني لنطاقك: دليل شامل
دليل خطوة بخطوة لتقييم الوضع الأمني لنطاقك — من DNS وSSL إلى مصادقة البريد الإلكتروني والخدمات المكشوفة والتعرض للخروقات. أدوات وتقنيات عملية مُتضمّنة.
ما هو الوضع الأمني للنطاق
الوضع الأمني لنطاقك هو مجموع جميع تكويناته الدفاعية وتعرّضاته وثغراته كما تُرى من الخارج. يجيب على سؤال بسيط: لو نظر مهاجم إلى نطاقك الآن، ماذا سيجد؟
معظم المؤسسات لديها نقاط عمياء. تُكوّن SSL مرة وتنساها. تضيف سجلات SPF لكنها لا تتقدم أبداً إلى تطبيق DMARC. تُوقف خدمات لكنها تترك سجلات DNS تشير إلى بنية تحتية مهجورة. كل نقطة عمياء هي فرصة للمهاجمين.
تدقيق الوضع الأمني يفحص بشكل منهجي كل طبقة مرئية خارجياً من نطاقك لتحديد نقاط الضعف قبل أن يفعل المهاجمون ذلك.
الخطوة 1: عدّد أصول نطاقك
قبل أن تتمكن من تقييم الأمان، تحتاج إلى جرد كامل لما تحميه.
اكتشاف النطاقات الفرعية
نطاقك المسجّل هو مجرد قمة الجبل الجليدي. معظم المؤسسات لديها عشرات إلى مئات النطاقات الفرعية، كثير منها منسي أو غير مُصان.
التقنيات:
- سجلات شفافية الشهادات (crt.sh): استعلم عن جميع شهادات SSL التي أُصدرت لنطاقك. هذا يكشف نطاقات فرعية ربما نسيتها.
- تخمين DNS بالقوة: أدوات مثل Subfinder أو Amass تجرّب أسماء نطاقات فرعية شائعة على خوادم DNS الخاصة بنطاقك.
- استغلال محركات البحث: عمليات بحث Google مثل
site:*.yourdomain.comتكشف النطاقات الفرعية المفهرسة. - أرشيف الويب: Wayback Machine يؤرشف صفحات من نطاقات فرعية قد لم تعد نشطة لكن لا تزال لديها سجلات DNS.
ما يجب البحث عنه:
- نطاقات فرعية تشير إلى خدمات تم إيقافها (سجلات CNAME معلّقة — خطر اختراق النطاق الفرعي)
- بيئات تطوير أو تجريب مكشوفة للإنترنت
- أدوات داخلية متاحة بدون VPN (Jenkins، Grafana، لوحات إدارة)
- تطبيقات قديمة لم تعد تُصان أو تُحدَّث
تخطيط عناوين IP والشبكة
حدد جميع عناوين IP المرتبطة بنطاقك:
- سجلات A لجميع النطاقات والنطاقات الفرعية
- سجلات MX (خوادم البريد)
- عمليات بحث DNS عكسية على نطاقات IP المعروفة
- اكتشاف أصول مزودي الخدمات السحابية (AWS، Azure، GCP — تحقق مما إذا كانت الموارد مرتبطة بنطاقك)
الخطوة 2: قيّم أمان DNS
DNS هو الأساس. إذا تم اختراق DNS، لا شيء آخر يهم.
نظافة السجلات
راجع كل سجل DNS من حيث الدقة والضرورة:
- سجلات A/AAAA: هل جميع السجلات تشير إلى خوادم نشطة ومُصانة؟
- سجلات CNAME: هل جميع الأسماء المستعارة تُحلّ إلى خدمات لا تزال تتحكم فيها؟
- سجلات MX: هل خوادم البريد مُرتّبة بشكل صحيح حسب الأولوية؟ هل هناك سجلات MX غير متوقعة قد تشير إلى هجوم اعتراض البريد؟
- سجلات TXT: هل سجلات SPF وDKIM وDMARC موجودة ومُكوّنة بشكل صحيح؟
- سجلات NS: هل خوادم الأسماء هي ما تتوقعه؟ التغييرات غير المصرّح بها في NS هي علامة على اختطاف DNS.
DNSSEC
تحقق مما إذا كان DNSSEC مُفعّلاً ومُكوّناً بشكل صحيح. DNSSEC يمنع انتحال DNS عن طريق التوقيع الرقمي للاستجابات. بدونه، يمكن للمهاجمين على مسار الشبكة إعادة توجيه مستخدميك إلى خوادم ضارة.
سجلات CAA
سجلات تفويض سلطة الشهادات تحدد أي جهات إصدار شهادات مسموح لها بإصدار شهادات لنطاقك. بدون سجلات CAA، يمكن لأي جهة إصدار إصدار شهادة لنطاقك، مما يزيد خطر إصدار شهادات غير مصرّح بها.
الخطوة 3: قيّم تكوين SSL/TLS
أخطاء تكوين SSL هي أحد أكثر النتائج شيوعاً في التدقيقات الأمنية.
صحة الشهادة
لكل نطاق فرعي يحمل شهادة SSL:
- هل الشهادة صالحة (غير منتهية، غير موقّعة ذاتياً للإنتاج)؟
- هل سلسلة الشهادات مكتملة (لا شهادات وسيطة مفقودة)؟
- هل الشهادة تستخدم قوة مفتاح كافية (RSA 2048+ أو ECDSA 256+)؟
- هل الشهادة من جهة إصدار موثوقة؟
- هل الشهادة تغطي أسماء النطاقات الصحيحة (تحقق من SANs)؟
تكوين البروتوكول
- عطّل TLS 1.0 و1.1. هذه الإصدارات بها ثغرات معروفة ومهملة من جميع المتصفحات الرئيسية.
- فعّل TLS 1.3 حيثما أمكن. TLS 1.3 يزيل مجموعات التشفير الضعيفة بالتصميم ويقلل تأخير المصافحة.
- عطّل مجموعات التشفير الضعيفة. RC4 و3DES وتشفيرات مستوى التصدير لا يجب تفعيلها أبداً.
ترويسات الأمان
تحقق من ترويسات استجابة HTTP على جميع الخدمات المواجهة للويب:
- Strict-Transport-Security (HSTS): يفرض اتصالات HTTPS. أضف
includeSubDomainsوفكّر في التحميل المسبق لـ HSTS. - Content-Security-Policy (CSP): يمنع هجمات XSS والحقن عن طريق التحكم في الموارد التي يمكن للمتصفح تحميلها.
- X-Frame-Options أو CSP frame-ancestors: يمنع Clickjacking عن طريق التحكم فيما إذا كان يمكن تضمين صفحاتك في iframes.
- X-Content-Type-Options: يمنع هجمات التخمين من نوع MIME.
- Permissions-Policy: يتحكم في ميزات المتصفح (الكاميرا، الميكروفون، الموقع الجغرافي) التي يمكن لصفحاتك الوصول إليها.
الخطوة 4: دقق في مصادقة البريد الإلكتروني
انتحال البريد الإلكتروني يظل أحد أكثر نواقل الهجوم فعالية. نطاق بمصادقة بريد إلكتروني ضعيفة هو مسؤولية.
تقييم SPF
- هل سجل SPF موجود وينتهي بـ
-all(فشل صارم)؟ - هل سجل SPF يبقى ضمن حد 10 عمليات بحث DNS؟
- هل جميع خدمات الإرسال الشرعية مُتضمّنة (Google Workspace، SendGrid، Mailchimp، إلخ)؟
- هل هناك تضمينات واسعة جداً تصرّح بمرسلين أكثر من اللازم؟
تقييم DKIM
- هل محددات DKIM مُكوّنة لجميع خدمات الإرسال؟
- هل مفاتيح DKIM تستخدم طولاً كافياً (RSA 2048 بت كحد أدنى)؟
- هل يتم التحقق من توقيعات DKIM بواسطة الخوادم المستقبلة؟ (تحقق من تقارير DMARC المجمّعة)
تقييم DMARC
- هل سجل DMARC منشور على
_dmarc.yourdomain.com؟ - هل السياسة مضبوطة على
quarantineأوreject؟ (p=noneيراقب فقط، لا يحمي) - هل سياسة النطاق الفرعي (
sp=) مضبوطة؟ بدونها، يمكن للمهاجمين انتحال رسائل من أي نطاق فرعي. - هل يتم جمع وتحليل التقارير المجمّعة (
rua) والتفصيلية (ruf)؟ - ما هو معدل نجاح DMARC؟ أي شيء أقل من 95% يشير إلى مشاكل في التكوين.
الخطوة 5: افحص الخدمات المكشوفة
تحليل المنافذ والخدمات
استخدم Shodan أو Censys أو Nmap لتحديد جميع الخدمات المواجهة للإنترنت على عناوين IP الخاصة بك:
- أغلق المنافذ غير الضرورية. فقط الخدمات التي يجب أن تكون متاحة علنياً يجب أن تكون قابلة للوصول من الإنترنت.
- تحقق من إصدارات الخدمات. البرمجيات القديمة مع CVEs معروفة هي أكثر ناقل وصول أولي شيوعاً.
- أزل الصفحات الافتراضية. صفحات خوادم الويب الافتراضية وواجهات إدارة قواعد البيانات وصفحات تصحيح الأطر تكشف تفاصيل المكدّس التقني للمهاجمين.
- تحقق من ضوابط الوصول. لوحات الإدارة ونقاط نهاية API وواجهات الإدارة يجب أن تتطلب مصادقة ويُفضّل تقييدها بعنوان IP أو VPN.
تعرّض الموارد السحابية
تحقق من الموارد السحابية المُكوّنة بشكل خاطئ:
- حاويات S3 أو تخزين الكائنات المكافئ مع وصول قراءة عام
- لوحات تحكم Kubernetes مكشوفة بدون مصادقة
- مثيلات قواعد بيانات بنقاط نهاية عامة
- بوابات API بدون مصادقة صحيحة
الخطوة 6: تحقق من التعرض للخروقات
هذه هي الطبقة التي تفوتها معظم التدقيقات الذاتية. حتى مع تكوين تقني مثالي، أمان نطاقك مُخترق إذا تسرّبت بيانات اعتماد الموظفين.
ما يجب التحقق منه
- هل أي عناوين بريد إلكتروني على نطاقك تظهر في قواعد بيانات الخروقات المعروفة؟
- هل كلمات المرور المسرّبة لا تزال صالحة محتملاً (لم تُغيّر منذ الخرق)؟
- هل نطاقك ذُكر في منتديات الويب المظلم أو مواقع النصوص المسرّبة؟
- هل هناك قوائم Combo Lists لبيانات الاعتماد تستهدف مؤسستك بنشاط؟
لماذا يهم
بيانات اعتماد واحدة مسرّبة من خرق طرف ثالث — كلمة مرور مطور من أداة SaaS مخترقة، أو بيانات اعتماد مسؤول تنفيذي من حساب شخصي مخترق — يمكن أن توفر الوصول الأولي لأنظمة الشركة. مراقبة الخروقات ليست اختيارية لتقييم الوضع الأمني الكامل.
تجميع كل شيء معاً
تدقيق أمان نطاق شامل يتطلب فحص جميع الطبقات الست. التحدي هو أن معظم الأدوات المجانية تتناول طبقة واحدة فقط في كل مرة، ولا يغطي أي منها التعرض للخروقات بشكل شامل.
أجرِ فحص استخبارات النطاق من Rikon للحصول على تقييم شامل للوضع الأمني في تقرير PDF واحد. Rikon يغطي تكوين DNS وتحليل SSL/TLS ومصادقة البريد الإلكتروني والخدمات المكشوفة والتعرض للخروقات ويوفر خطة إصلاح مولّدة بالذكاء الاصطناعي مُرتّبة حسب خطورة المخاطر.
دفعة واحدة بقيمة 39.99 دولار. لا اشتراك. لا رسوم متكررة. تحليل كامل يُسلَّم في دقائق.
نطاقك هو الباب الأمامي لكل ما تفعله عبر الإنترنت. دققه قبل أن يفعل شخص آخر ذلك.