[ DKIM ]

مراقبة محددات ومفاتيح DKIM دون المطالبة بأن DNS يثبت التوقيع المباشر

اجمع بين مراقبة تغيير DNS واختبارات الرسائل المستلمة لقياس صحة DKIM الفعلية.

بواسطة فريق البحث EmailAuth

[النقاط الرئيسية]

  • احتفظ بنشر DNS والتحقق من الرسالة ومواءمتها بشكل منفصل.
  • تصنيف الغياب والمهلة والإلغاء والتغييرات بشكل واضح.
  • أرفق كل ملاحظة بمسارها ووقتها وأدلتها.
في هذه الصفحة

A محدد يمكن أن يخبرك جهاز المراقبة بأن بيانات التحقق قد تغيرت أو اختفت. لا يمكن إثبات أن الخدمة لا تزال ترسل، أو أن مفتاحها الخاص يطابق المفتاح المنشور، أو أن رسائلها تصل بشكل متوافق DKIM. قم ببناء عمليات فحص منفصلة للتكوين المنشور وسلوك الرسالة الملحوظ.

ابدأ بطرق الإرسال المعروفة

إنشاء جرد من تكوين المرسل المعتمد والرسائل المستلمة من الممثل. لكل مسار سجل مالك العمل أو المجال d أو المحدد أو مالك DNS أو TXT المتوقع أو CNAME الترتيب وآخر وقت توقيع تمت ملاحظته وحالة دورة الحياة. لا تفترض أن تخمين المحددات الشائعة يكتشف كل موقع. يوفر DKIM المحدد في كل توقيع بدلاً من تحديد خدمة تعداد DNS كاملة.

للحصول على توقيع باستخدام s=invoice2 و d=brand.example, قم بفحص invoice2._domainkey.brand.example ضمن RFC 6376 §3.6.2.1. اتبع CNAME المتوقع لبيانات التحقق الخاصة به. قم بتخزين طابع زمني للمراقبة وبصمة المفتاح العام حتى يمكن مقارنة التغيير بالتناوب المعتمد. لا تقم أبدًا بجمع المفاتيح الخاصة في نظام المراقبة.

افصل بين نتائج جهاز المراقبة

تعتبر الإجابة المفقودة ومهلة DNS والمفتاح الذي تم إبطاله والمفتاح الذي تم تغييره أحداثًا مختلفة. RFC 6376 §6.1.2 يميز فشل استعلام المفتاح عن المفتاح الغائب، وتمثل قيمة p الفارغة إبطالًا تحت RFC 6376 §3.6.1. قم بتسجيل تفاصيل الاستجابة بدلاً من ترجمة كل خطأ إلى انقطاع عام.

لا يزال المفتاح الحالي يحتاج إلى فحوصات بناء الجملة والخوارزمية. RFC 8301 §3.1 يحظر التوقيع والتحقق من rsa-sha1؛ RFC 8301 §3.2 تحديث متطلبات حجم RSA: يجب أن يستخدم الموقعون 1024 بت على الأقل ويجب أن يستخدموا 2048 بت على الأقل. قد يكون دعم المنتج وسياسة التشفير التنظيمية الحالية أكثر صرامة. لا يمكن لتغيير بصمة الإصبع وحده أن يخبرك ما إذا كان التناوب مسموحًا به أم لا.

أضف حلقة أدلة حية

قم بإرسال رسائل يتم التحكم فيها عبر كل مسار إنتاج مهم إلى صندوق بريد يمكنك فحص رسالته الأولية والمصادقة الموثوقة الخاصة به. سجل d وs المرصودة ونتائج التحقق و تنسيق مع من. قم بممارسة متغيرات الرسالة التي يمكن أن تؤثر على المعالجة النهائية، مثل HTML والمرفقات.

شاشة توضيحية: يستمر DNS في تقديم الفاتورة 2، لكن رسالة جديدة تحتوي على لا DKIM-Signature. يتم تمرير فحص النشر بينما يفشل التحقق من التوقيع. وفي حالة أخرى، التوقيع موجود ولكن تجزئة الجسم فشل بعد تغيير تذييل البوابة. لم يتم حل أي من الحادثتين من خلال الإعلان عن صحة سجل DNS . هذه حالات اختبار اصطناعية، وليست حوادث خدمة مُقاسة.

الاختبارات الاصطناعية لها حدود أيضًا. لا يثبت التحقيق اليومي كل رسالة تم تمريرها بين المجسات. قم بدمجها مع تقارير المتلقي وأدلة الحوادث، مع الاعتراف بتغطية التقارير والتأخير.

توجيه التنبيهات القابلة للتنفيذ

إرفاق التنبيهات إلى الطريق والمالك. قم بمنع نافذة الصيانة المعتمدة بشكل صريح فقط، واحتفظ بسجل الأحداث وقم بتأكيد الموقع الجديد ببريد جديد بعد التناوب. قم بتصعيد التغييرات الرئيسية غير المتوقعة كأحداث أمنية محتملة دون الإعلان عن التسوية من التغيير وحده.

تقاعد صفوف المخزون التي لا معنى لها عمدا. قد يبقى المفتاح العام القديم للتحقق من الرسائل المؤجلة حتى عند توقف التوقيع الجديد. ميز تلك الحالة المخطط لها عن الوفد المهجور. يجب أن توضح لوحة المعلومات ما تمت ملاحظته ومتى وبأي طريقة، حتى لا تتنكر صحة DNS أبدًا كدليل على التوقيع المباشر.

إعادة إنشاء قرار التنبيه

استخدم أربعة مجسات اصطناعية لإبقاء طبقات التنبيه منفصلة. يتم تعيين التوقيع باستخدام d=brand.example و s=invoice2 إلى invoice2._domainkey.brand.example . إذا كان مفتاحه العام موجودًا ولكن نتيجة جهاز الاستقبال المقدم هي فشل تجزئة النص، فقم بإصدار تنبيه للتحقق من الرسالة. إذا كان مفتاحه غائبًا، قم بإصدار تنبيه بغياب المفتاح. إذا كان السجل المتوقع موجودًا ولكن الرسالة لا تحتوي على توقيع، فقم بإصدار تنبيه بفقدان التوقيع. لا ينتج عن المفتاح الحالي بالإضافة إلى نتيجة المرور المقدمة أي تنبيه لهذا المسبار وحده.

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

الأدلة اللازمة لاتخاذ القرار المقبل

للحصول على تنبيه تجزئة النص، احتفظ بالنتيجة المقدمة وتحقق من تمثيل النص وإعدادات c/l وقيمة bh وسلوك التنفيذ؛ عدم التطابق وحده لا يثبت محتوى البوابة المعدل. قم بتمييز المسار الذي لا يحتوي على مسبار جديد على أنه غير ملحوظ، حتى لو كان مفتاحه موجودًا. سجل بشكل منفصل ما إذا كان قد تم التحقق من المحاذاة، نظرًا لأن تمرير DKIM وحده ليس تمريرًا محاذاة.

[ الوجبات الجاهزة ]

احتفظ بنشر DNS والتحقق من الرسالة ومواءمتها بشكل منفصل. تصنيف الغياب والمهلة والإلغاء والتغييرات بشكل واضح. أرفق كل ملاحظة بمسارها ووقتها وأدلتها.

[ حسب الدور ]

ماذا يعني هذا بالنسبة لك

اختر دورك للخطوات العملية التالية.

تكنولوجيا المعلومات / مدير البريد

احتفظ بشيكات النشر والتوقيع منفصلة

تدعم الأدلة المختلفة ادعاءات مختلفة حول صحة DKIM .

الخطوات التالية

  1. تتبع أسماء المحددات الدقيقة وبصمات الأصابع الرئيسية.
  2. تصنيف أنواع استجابة DNS .
  3. احتفظ باختبارات الرسائل الأولية المؤرخة.

كبير مسؤولي أمن المعلومات / SecOps

مراجعة التغييرات غير المتوقعة في السلطة

تستحق التغييرات الرئيسية والتفويض الارتباط بالصيانة المعتمدة.

الخطوات التالية

  1. إذن تغيير التدقيق.
  2. حماية أدلة الرصد.
  3. قم بتعيين معايير التصعيد الأمني.

المؤسس / غير التقنية

مراقبة طرق العمل

لا يثبت سجل DNS السليم مصادقة الفاتورة أو إعادة تعيين كلمة المرور.

الخطوات التالية

  1. تحديد مسارات الإرسال الهامة.
  2. تعيين أصحاب للفشل.
  3. مراجعة تغطية التحقيق والثغرات.

[ الأسئلة الشائعة ]

الأسئلة المتداولة

هل يثبت المفتاح الحالي أن التوقيع نشط؟

لا. قم بتأكيد التوقيعات المرسلة والتحقق منها على الرسائل المستلمة.

RFC 6376 §5.5 RFC 6376 §6.1

هل يمكن DNS تعداد كافة المحددات؟

لا توجد آلية عامة لتعداد محدد DKIM . استخدم تكوين المرسل والتوقيعات المرصودة.

RFC 6376 §3.1 RFC 6376 §3.6.2.1

ما الذي يجب أن تغطيه بصمة الإصبع؟

استخدم تمثيلاً موثقًا لمواد التحقق العامة حتى يمكن مقارنة التغييرات بشكل متسق.

هل المهلة مفتاح تم إبطاله؟

لا، المهلة والغياب والإلغاء الصريح هي ملاحظات مختلفة.

RFC 6376 §3.6.1 RFC 6376 §6.1.2

هل يجب على المراقبة جمع المفاتيح الخاصة؟

لا. يعد التكوين العام واختبارات الرسائل الخاضعة للرقابة كافية لإجراء عمليات التحقق هذه.

هل يثبت مسبار واحد مرور جميع رسائل البريد؟

لا، يقوم المسبار بأخذ عينات من الطريق والوقت؛ توفر التقارير والحوادث الحقيقية أدلة إضافية.

هل يمكن أن يكون التغيير الرئيسي مشروعًا؟

نعم. قم بتسويتها مع التناوب المعتمد وتأكيد التحقق من الرسائل الجديدة.

RFC 6376 §3.1

متى يكون المفتاح القديم آمنًا للإزالة؟

استخدم معايير التقاعد الموثقة والتعرض لقائمة الانتظار وسياق الأمان بدلاً من عدم النشاط وحده.

RFC 6376 §3.1 RFC 6376 §8.3

[ مصادر ]

مصادر

  1. RFC 6376

    الأقسام §1 · §3.1 · §3.5 · §3.6.1 · §3.6.2.1 · §5.5 · §6.1 · §6.1.2 · §8.3

  2. RFC 8301

    الأقسام §3.1 · §3.2

  3. RFC 8601

    الأقسام §1.2 · §7.1

  4. RFC 9989

    الأقسام §4.4

[ مسرد ]

مسرد

DKIM
توقيع مرتبط بالمجال على محتوى الرسالة المحدد، ويتم التحقق منه باستخدام بيانات المفتاح العام.

RFC 6376 §1

محدد
القيمة s المستخدمة مع مجال التوقيع d للعثور على بيانات التحقق.

RFC 6376 §3.1 RFC 6376 §3.5

محاذاة DMARC
العلاقة المطلوبة بين المعرف المعتمد ومجال المؤلف.

RFC 9989 §4.4

مصدر المؤسسة

لماذا كبار المؤسسات المالية والحكومات تقاعدوا من لوحات معلومات أمان البريد الإلكتروني الخاصة بهم.

تبيع لك منصات مصادقة البريد الإلكتروني التقليدية لوحة تحكم وتطلب من مهندسيك القيام بهذا العمل. في البيئات عالية المخاطر، تعني المراقبة اليدوية تأخير التنفيذ، والانحراف في التكوين، ونطاقات الظل غير الخاضعة للمراقبة.

EmailAuth هي منصة مصدر البريد الإلكتروني الوكيل. وكلاؤنا ينفذون p=reject، حافظ على محاذاة المرسلين الخارجيين وانقل نطاقاتك إلى كاملها RFC 9989 الامتثال، وهو معيار DMARC الجديد، مع إمكانية التدقيق البشري في الحلقة.

الحكومات المؤسسات الكبيرة المؤسسات المالية من المستوى الأول

SaaS · إيجار مخصص · Air-gapped محليًا · تشفير BYOK

قاعدة المعرفة