لا تستطيع حماية ما لا تعرفه، لكن معرفة اسم فرعي لا تعني أنك وجدت ثغرة. هذا الفرق مهم عندما يبني فريق الأمن جرداً لسطح الهجوم. قد يكشف اسم قديم في شهادة TLS، أو يظهر في DNS، أو يكون مرجعاً في مستند عام، ثم لا يجيب عند الفحص الحالي. وقد يجيب اسم آخر بصفحة تجريبية أو لوحة دخول تحتاج مراجعة من مالكها. اكتشاف النطاقات الفرعية هو جمع أدلة وربطها بهوية أصل، ثم تحديد ما إذا كانت النتيجة موجودة أو غائبة أو غير معروفة، لا إطلاق حكم سريع على الخطر.
تستخدم فرق الشركات العربية النطاقات الفرعية للتطبيقات ومراكز الدعم والحملات والبيئات التجريبية والواجهات البرمجية. ومع نمو المنتجات، قد ينشئ فريق اسماً من دون تحديث السجل المركزي. لذلك ابدأ بنطاقاتك المملوكة وبإذن واضح، واحتفظ بسجل يبين نطاق الاختبار وحدوده. توضح RFC 6962 فكرة السجلات العامة لشهادات TLS كوسيلة لتدقيق الإصدار، لكنها لا تقول إن كل اسم في السجل نشط الآن. DNS بدوره يعرض ما تنشره المنطقة الحالية، لكنه لا يكشف كل اسم تاريخي أو خاص.
مصادر الاكتشاف الثلاثة
ابدأ بشهادات TLS العامة، لأنها قد تحتوي أسماء SAN لم تكن في جردك. ثم راجع DNS للسجلات التي تعلنها المنطقة، مثل A وAAAA وCNAME وMX وNS وTXT عند صلتها بالاسم. بعد ذلك أضف نتائج الجرد الداخلي وملفات البنية وطلبات الفرق. لكل مصدر ثقة وحدود: الشهادة قديمة، وDNS قد يخفي اسماً غير منشور، والوثيقة قد تكون متجاوزة. اجمع المصدر والوقت والاسم الدقيق، ولا تدمج نتائج متشابهة قبل تطبيع الأحرف والنقاط والصيغ الدولية.
- شهادات TLS العامة وأسماء SAN المرتبطة بالنطاق.
- سجلات DNS الحالية وعمليات التحقق المصرح بها.
- قائمة الأصول الداخلية ومشاريع السحابة وسجلات نشر التطبيقات.
- الروابط والوثائق العامة التي تذكر API أو لوحة أو بيئة.
- تاريخ الملاحظات السابقة، مع تمييز ما رُصد فعلاً عما ورد في مصدر غير مؤكد.
الاكتشاف ليس مسحاً عدائياً
حافظ على نطاق دفاعي واضح. افحص أسماء نطاقك أو ما تملك تفويضاً مكتوباً لفحصه، والتزم بحدود زمنية وطلبات معقولة. لا تحاول تجاوز المصادقة أو الوصول إلى بيانات خاصة، ولا تستخدم نتيجة اسم مكشوف لتبرير اختبار استغلال. وظيفة الجرد أن تضع الأصل أمام مالكه، لا أن تحول كل اسم إلى هدف. إذا وجدت لوحة دخول أو بيئة اختبار، سجلها كإشارة تحتاج مراجعة، ثم أخطر الفريق المسؤول عبر القناة المعتمدة. السلامة الإجرائية تحمي الشركة والباحث وتمنع إزعاج خدمة صحيحة.
تقدم أداة النطاقات الفرعية نتائج عملية مع أدلة وتغطية محدودة، ويمكن استخدام Subdomain Finder API لتغذية جردك. لا تصف النتيجة بأنها قائمة كاملة، ولا تخلط بين الاسم المكتشف والاسم المتاح للتسجيل أو قابلية الاستيلاء. خزّن حالة present عندما يوجد دليل حديث، وunknown عندما يتعذر التحقق، وnot_requested عندما لم تدخل الخدمة في النطاق. هذا الفصل يمنع لوحة المخاطر من رفع أسماء لمجرد أن أحد المصادر رد بخطأ أو تأخر.
تحقق من الاسم بعد اكتشافه
بعد جمع الأسماء، اطلب DNS من المصدر المعتمد، ثم افحص HTTP وTLS وفق ما يسمح به نطاقك. تحقق من أن الاسم يجيب، وما إذا كان يعيد تحويلًا، ومن الشهادة التي يقدمها، ومن نوع الخدمة الظاهر. قد يعيد CNAME إلى مزود خارجي يحتاج مالكاً، وقد يشير A إلى عنوان لم يعد مستخدماً، وقد يجيب HTTP بصفحة افتراضية لا علاقة لها بالمنتج. لا تسجل محتوى حساساً في التقرير. يكفي رمز الاستجابة والعنوان النهائي والشهادة والوقت ومصدر الدليل.
افصل بين الاسم الموجود والخدمة الخطرة. وجود staging.example.com ليس ثغرة بحد ذاته، لكنه أصل يحتاج سياسة وصول ومالكاً وتاريخ إزالة. وجود dev قد يكون مقصوداً داخل شبكة خاصة، بينما ظهور اسم API في شهادة عامة قد يكشف أن الخدمة تحتاج مراجعة. استخدم درجة الأولوية المبنية على الحساسية وقابلية الوصول ومالك الخدمة، وليس على اسم فرعي مثير. إذا لم تجد مالكاً، ارفع الحالة كفجوة جرد، ولا تحذف DNS قبل فهم اعتمادياته.
سطح الهجوم في الشركات العربية
قد تستخدم الشركة نطاقات عربية ولاتينية، أو أسماء منفصلة لبلدان الخليج وشمال أفريقيا، أو نطاقاً فرعياً لكل حملة موسمية. اجمع هذه الصيغ في سجل واحد مع الاسم القانوني والمنتج والسوق. انتبه إلى Punycode والحروف المتشابهة، لأن تطبيع الاسم بصورة خاطئة قد يخفي أصلاً أو يكرر السجل. راجع أيضاً أسماء الخدمات التي تظهر في البريد أو تطبيق الهاتف، فالرابط الذي لا يظهر في الصفحة الرئيسية قد يبقى مهماً للعملاء. الترجمة المحلية للمسمى لا تعني أن سجل DNS يطابق الاسم الذي يراه المستخدم.
من قائمة أسماء إلى برنامج ملكية
- طبع كل اسم إلى صيغة موحدة، واربط الصيغ الدولية ببعضها عند الحاجة.
- سجل الدليل ومصدره ووقت الفحص وحالة التحقق.
- عيّن مالكاً تجارياً وتقنياً لكل اسم، أو افتح فجوة ملكية صريحة.
- صنف الأصل: إنتاج، اختبار، بريد، API، حملة، تحويل، أو غير معروف.
- حدد ما يجب مراقبته من DNS وTLS وHTTP والشهادة، وما يجب إزالته بعد موافقة.
- أعد الاكتشاف بعد تغييرات DNS والشهادات أو إطلاق منتج جديد.
أدخل دورة حياة النطاق الفرعي في إدارة التغيير. عند إنشاء اسم، يجب أن يعرف الفريق لماذا وجد، ومن يملك DNS وTLS والتطبيق، ومتى يعاد تقييمه. عند إيقاف مشروع، لا تحذف الاسم عشوائياً، بل تحقق من السجلات والتحويلات والشهادات وعمليات التكامل. الاسم المهجور قد يشير إلى خدمة خارجية أو يسبب استيلاءً إذا بقيت إحالة CNAME بلا مورد. اعمل مع فريق المشتريات عندما يكون الاسم مرتبطاً بخدمة طرف ثالث، وسجل إلغاء الربط خطوة صريحة في تذكرة الإيقاف.
كيف تفسر النتائج والحدود؟
النتيجة الموجبة تعني أن دليلاً محدداً ربط الاسم بالنطاق أو بالخدمة في وقت معين. لا تعني أنها شاملة أو حديثة إلى الأبد. النتيجة السلبية من مصدر غير سلطوي لا تعني أن الاسم غير موجود، و403 أو 429 أو مهلة لا تعني غياب الأصل. احتفظ بالنتيجة unknown عند الغموض، واذكر السبب. هذا الأسلوب يحسن تقارير الأمن، ويمنع قرارات شراء أو إزالة مبنية على نقص البيانات. عندما يتطلب الأمر عمقاً أكبر، اطلب موافقة واستخدم اختباراً مخصصاً داخل حدود التفويض.
اربط الأسماء المكتشفة بمؤشرات أخرى دون ادعاء زائد. قد يساعد فحص التقنية في معرفة نوع الخدمة، وقد يكشف فحص السمعة إشارة تحتاج مراجعة، وقد يوضح DNS تاريخياً متى ظهر الاسم. لا تستخدم هذه الإشارات لتسمية منتج أو جهة من دون دليل مباشر. اجعل التقرير قابلاً للقراءة من الأمن والتشغيل والمنتج: ما الاسم، ما الدليل، ما المالك، ما الحالة، ما الخطوة التالية؟ هذه اللغة المشتركة تحول جرداً متغيراً إلى قرارات يمكن تنفيذها.
قائمة النطاقات الفرعية الجيدة ليست الأطول، بل الأكثر قابلية لإسناد الملكية والتحقق والزوال المنظم.
مبدأ إدارة سطح الهجوم
أضف مؤشرات جودة للجرد نفسه: نسبة الأسماء المرتبطة بمالك، نسبة الأسماء التي تم التحقق منها حديثاً، وعدد النتائج التي بقيت unknown بسبب مصدر محجوب. راجع هذه المؤشرات مع فريق المنصة، لأن جرداً مليئاً بأسماء قديمة أو بلا مالك لا يحسن الاستجابة مهما كان طوله. احتفظ بأسماء مختبرة معروفة الحضور، وباسم مولد بأمان لاختبار الغياب، ثم قارنهما بعد كل تغيير في طريقة الاكتشاف. لا تضع أسماء العملاء أو الأسرار داخل اختبار عام.
عند اكتشاف أصل جديد، اسأل إن كان يجب أن يكون عاماً. قد يكون الحل هو تقييد الوصول أو إزالة DNS أو تحديث الشهادة أو توثيق الاستثناء. لا تبدأ بتغيير تقني قبل معرفة مالك المنتج، لأن النطاق الفرعي قد يخدم تكاملاً لا يظهر في الموقع. سجل القرار والموعد، ثم أعد الفحص بعد الإصلاح. هذه الدورة تجعل الاكتشاف مفيداً حتى عندما لا يؤدي إلى إزالة الاسم.
أضف فحصاً خاصاً للأسماء التي تخدم الدخول والدفع وواجهات API، لأنها تحمل قيمة أكبر من صفحة معلومات. تحقق من الشهادة والتحويل وملكية DNS، ثم راجع سياسة الوصول مع مالك الخدمة. إذا كان الاسم تابعاً لحملة انتهت، اطلب من التسويق تأكيد الإزالة قبل حذف السجلات. عند وجود نطاق عربي ونسخة لاتينية، اربطهما في بطاقة واحدة لكن احتفظ بكل دليل منفصلاً. هذا التنظيم يمنع أن تختفي خدمة مهمة خلف سجل مكرر أو ترجمة مختلفة.
راجع الأصول بعد كل تغيير كبير
يتغير جرد النطاقات الفرعية عند إطلاق منتج أو نقل مزود أو دمج شركة، لذلك ضع نقطة إعادة اكتشاف في خطة التغيير. قارن الأسماء الجديدة بالخط الأساس، وافتح تذكرة لأي اسم بلا مالك أو بلا غرض. لا تكتف بفحص الجذر، لأن البيئة الجديدة قد تنشئ api أو admin أو status خارج وثائق المنتج. راجع DNS وTLS معاً، وتأكد من أن الشهادة لا تكشف أسماء لم تعد تحت سيطرة الفريق. عندما يتغير الاسم، حدّث المراقبة والمالكين والمستندات في نفس الإصدار حتى لا تعود الفجوة بعد أسبوع.
قد يكون الاسم الخاص غير قابل للوصول من الإنترنت، لكن ظهوره في شهادة عامة أو سجل DNS يستحق تفسيراً. افصل الأصول الداخلية عن العامة في التقرير، ولا تعرض أسماء حساسة في لوحة يقرأها الجميع. إذا وجد فريقك CNAME يشير إلى خدمة خارجية، تحقق من أن المورد ما زال مرتبطاً وباسم مملوك، ثم أزل الربط عند انتهاء المشروع بعد مراجعة الاعتماديات. هذه الخطوة تحمي من بقاء إحالة قديمة، لكنها ليست دعوة إلى تجربة استيلاء أو اختبار خارج التفويض. الإجراء الصحيح هو توثيق وإبلاغ وقرار مالك.
اجعل الجرد قابلاً للاستخدام في الحوادث. عند ظهور طلب مشبوه، يستطيع المحلل معرفة مالك الاسم ونوع الخدمة وآخر فحص ودليل الوجود. وعند ظهور اسم جديد، يستطيع فريق التشغيل تأكيد هل هو إصدار مخطط أم أصل مجهول. خزّن لقطات مختصرة ومدة صلاحية، وامنع تكرار التنبيه عندما لا يتغير الدليل. إذا كانت نتيجة المصدر غير مكتملة، اكتب ذلك في العنوان نفسه. الوضوح في كلمة unknown أفضل من رقم كبير يعطي إحساساً خاطئاً بالتغطية.
اكتشاف النطاقات الفرعية عملية مستمرة توازن بين التغطية والاحترام واليقين. اجمع شهادات TLS وDNS والجرد الداخلي، تحقق من الاسم والخدمة، سجل الحدود، ثم اربط كل أصل بمالك ومراقبة وخطة حياة. ابدأ من أداة النطاقات الفرعية، واستخدم توثيق API إذا كنت تريد تشغيل فحص دوري داخل برنامج إدارة الأصول دون تقديم النتائج على أنها اكتمال مطلق.