رای بدهید

الزامات پیاده سازی DMARC

احراز هویت ایمیل در ESA مبتنی بر پروفایل است ولی برخلاف DKIM پروفایل پیش فرض باید بگونه ای سازگار با مشخصه‌ها باشد. ESA به صورت پیش فرض به نحوی رفتار می‌کند که هیچ یک از پیام‌ها از بین نرود، بنابراین پروفایل پیش فرض احراز هویت DMARC به صورت “No Action” است. علاوه بر این به منظور فعال کردن قابلیت تولید گزارش ملزم به ویرایش بخش DMARC از پالیسی های ایمیل هستیم.
تنظیمات احراز هویت DMARC، مشابه دو مورد دیگر به بخش تنظیمات پیش فرض پالیسی Mail Flow اعمال می‌شود. از فعال شدن ارسال گزارش فیدبک اطمینان حاصل کنید، این گزینه یکی از مهمترین قابلیت‌های DMARC برای فرستنده است. در زمان انتشار این مقاله ESA از تولید گزارش Failure به ازای هر پیام پشتیبانی نمیکرد (بر چسب “ruf” در پالیسی DMARC).

DMARC برای گیرنده

اقدامات و پالیسی های DMARC توسط فرستنده توصیه می‌شود لیکن برخلاف SPF و DKIM در عمل هیچ پیکربندی خارج از پروفایل پیکربندی قابل اعمال نیست. همچنین نیازی به ساخت فیلترهای محتوا نیست.
احراز هویت DMARC فیلدهایی را به هدر Authentication-Results می‌افزاید:
Authentication-Results: mx1.hc4-93.c3s2.smtpi.com; dkim=pass (signature verified)
header.i=MileagePlus@news.united.com; dmarc=pass (p=none dis=none) d=news.united.com
در نمونه فوق، DMARC براساس هم ترازی شناسه DKIM تایید می‌شود و فرستنده درخواست پالیسی “none” ارسال می کند. این مساله نشان دهنده وضعیت “monitor” در مراحل استقرار DMARC است.

چنانچه به سایر دامین‌ها و یا 3rd party سرویس ایمیل ارایه می‌کنید

بزرگترین مساله در سازگاری ESPs با DMARC، دستیابی به هماهنگی کامل شناسه است. زمانیکه قصد توسعه DMARC را دارید، ملزم به اطمینان از صحت تنظیمات SPF هستید، به گونه ای که کلیه دامنه های مرتبط، گیت وی خروجی شما را در رکوردهای SPF خود داشته و پیام هایی را که از منظر همترازی قابل قبول نیستند، ارسال نمی کنند. اصولا این عمل از طریق استفاده از دامین های متفاوت برای MAIL FROM و شناسه Header From صورت می گیرد. این خطا اغلب هنگامیکه از برنامه هایی که اعلان ها و هشدارهایی از طریق ایمیل ارسال می کنند رخ می دهد، زیرا اغلب توسعه دهندگان نرم افزارها از عواقب ناسازگاری شناسه های ایمیل اطلاعی ندارند.
همانگونه که پیشتر ذکر شد، ملزم به اطمینان از کاربری پروفایل امضا DKIM مجزا برای هریک از دامنه ها هستیم، بدین ترتیب پروفایل امضا شما به صورت صحیح به دامینی که درخواست امضا ارسال شده است، از طریق Header From ارجاع داده می شود. چنانچه شما از زیردامنه های خود استفاده می کنید، امکان امضا با یک کلید وجود دارد لیکن باید از مطابقت با DKIM در پالیسی های adkim=”r”) DMARC”) اطمینان حاصل کنید.
به صورت کلی چنانچه سرویسهای ایمیل برای تعداد بالایی از 3rd party ارایه می کنید، توصیه می شود راهنمایی هایی در مورد چگونگی ارسال ایمیلی که از دریافت آن اطمینان داشته باشیم تهیه کنید.

دامنه ها و زیردامنه های فاقد ترافیک ایمیل

از دیگر مزایای DMARC نسبت به سایر تکنولوژی های احراز هویت ایمیل پیشین، قابلیت آن در برخورد با زیر دامنه ها است. به صورت پیش فرض پالیسی DMARC به کلیه زیردامنه ها اعمال می شود. زمانیکه رکوردهای DMARC policy را اصلاح می کنید، اگر هیچ رکوردی در سطح Header From FQDN تعریف نشده باشد، دریافت کننده ایمیل ملزم به تصمیم گیری در خصوص دامین فرستنده و جستجوی رکورد پالیسی است.
پالیسی برای Organizational Domain بگونه ایست که میتوان پالیسی مجزایی به هریک از زیردامنه ها اعمال کرد ( برچسب “sp” در رکورد DMARC) که این پالیسی به کلیه زیردامنه هایی که پالیسی DMARC مجزایی ندارند، اعمال خواهد شد.
در سناریوی بخش SPF شما امکان:
 انتشار یک رکورد صریح DMARC برای هریک از زیردامنه های که در گروه منابع معتبر ایمیل قرار دارند.
 پالیسی “reject” را در کلیه زیردامنه های رکوردهای Organizational Domain policy منتشر می کنیم، به این ترتیب کلیه ایمیلهایی که از منابع جعلی ارسال میشوند، پذیرفته نخواهند شد.
چنین ساختار احراز هویت ایمیل، بهترین روش برای حفاظت از زیرساخت و نام تجاری شما خواهد بود.

مباحث ویژه در DMARC

چندین مشکل بالقوه در مبحث DMARC وجود دارد که از ماهیت و کاستی های سایر تکنولوژی هایی احراز هویت ایمیل که DMARC به آنها وابسته است، نشات گرفته است. مساله اصلی زمانی آشکار میشود که DMARC پالیسی “reject” اعمال و یا شناسه ارسال کنندگان متفاوت در یک پیام را با یکدیگر مرتبط می کند.
اغلب مشکلات با mailing list و نرم افزارهای مدیریت mailing list، زمانیکه یک ایمیل به یک mailing list ارسال می¬شود، در میان همه گیرندگان موجود در لیست توزیع می شود. اگرچه ایمیل نهایی، با آدرس فرستنده اصلی، از طریق زیرساخت مدیریت mailing list ارسال و درنتیجه تست failing SPF برای Header From صورت نخواهد گرفت ( اغلب زیرساختهای مدیریت mailing list از لیست ایمیلها با عنوان Envelope From و یا MAIL FROM و فرستنده اصلی با عنوان Header From استفاده می کنند.).
با توجه به اینکه DMARC احتمال شکست SPF وجود دارد، در این موارد به DKIM متکی خواهیم بود، اگرچه نرم افزارهای مدیرت mailing list اغلب پاورقی و یا برچسب موضوعی به همراه نام لیست به پیام می-افزایند که موجب ناکارآمدی تایید امضا DKIM خواهد شد.
توسعه دهندگان DKIM راهکارهای مختلفی را به منظور رفع این مشکل ارایه می کنند، که در اغلب این روشها از mailing list managers ، که از آدرس موجود در لیست در کلیه بخشهای From addresses و اشاره به فرستنده اصلی با استفاده از سایر روشها، استفاده می شود.
مشکلات مشابهی در فوروارد پیام از طریق کپی پیام اصلی و ارسال از طریق SMTP به گیرنده جدید، به وجود می آید. اگرچه امروزه بسیاری از Mail User Agent ، یک پیغام جدید ایجاد کرده و پیام فوروارد شده درون پیام جدید و یا بصورت پیوست آن قرار می دهند. پیامهایی که به این شکل ارسال می شوند چنانچه کاربر فوروارد کننده مورد قبول باشد، الزامات DMARC را فراهم میکنند( البته احراز هویت پیام اصلی را نمیتوان فراهم کرد).

نمونه ای از اقدامات صورت گرفته جهت پیاده سازی احراز هویت ایمیل

اگرچه ماهیت تکنولوژی ها احراز هویت ایمیل ساده است، لیکن روند اجرای یک زیرساخت کامل، پیچیده و طولانی خواهد بود. برای سازمانهای کوچک و افرادی که جریان ایمیل کنترل شده ای دارند این روند چندان پیچیده نیست لیکن پیاده سازی آن در سازمانهای بزرگ چالش برانگیز خواهد بود و معمولا آنها به منظور مدیریت پروژه از کمک مشاوران بهره می گیرند.

گام اول : DKIM

DKIM نسبتا بی وقفه است، زیرا پیامهای امضا نشده پذیرش خواهند شد..پیش از شروع پیاده سازی کلیه این مسایل را باید در نظر گرفت. با هر 3rd party که قصد واگذاری عملیات امضا DKIM به او را دارید تماس حاصل کرده و استراتژی مدیریت سلکتور آنها را بررسی کنید. برخی سازمانها کلیدهای مجزایی (سلکتور) برای هریک از واحدهای سازمانی متفاوت استفاده می کنند. همچنین برای امنیت بیشتر از چرخش دوره ای کلیدها استفاده کنید، توجه داشته باشید تا پیش از اطمینان از دریافت کلیه ایمیلهای ارسالی کلید پیشین حذف نشوند.
ملاحظات ویژه ای درخصوص سایز کلیدها باید لحاظ شود. اگرچه بصورت عام تصور میشود هرچه سایز کلید بزرگتر باشد بهتر است، ولی باید توجه داشت تولید دو امضای دیجیتال به ازای هر پیام بار کاری بالایی برای CPU و تاثیر منفی بر عملکرد گیت وی ایمیل‌های خروجی خواهد داشت. با توجه به حجم بالای محاسباتی، 2048 بیت در عمل بالاترین سایز کلید مورد استفاده است، لیکن در بسیاری از روشهای توسعه کلید 1024 بیتی سازگاری بهتری میان عملکرد و امنیت برقرار می‌کند.

به منظور پیاده سازی DMARC ملزم به :

a. شناسایی کلیه دامنه‌ها و زیردامنه هایی که به آنها ایمیل ارسال می‌کنید.
b. تولید کلید DKIM و ایجاد پروفایل امضا برای هریک از دامنه‌ها
c. ارایه کلید خصوصی مرتبط با هریک از 3rd party
d. انتشار کلیه ملیدهای عمومی در DNS مرتبط
e. بررسی آمادگی 3rd party جهت تایید امضا
f. فعال کردن قابلیت DKIM signing در بخش Mail Flow Policy مرتبط در ESAs
g. اعلام شروع عملیات امضا به 3rd party

گام دوم : SPF

پیاده سازی SPF قطعا سخت ترین و زمان برترین بخش اجرای احراز هویت ایمیل است. باتوجه به اینکه کاربری و مدیریت ایمیل بسیار ساده و فارغ از الزامات امنیتی است، بنابراین شرکتها به صورت سنتی پالیسی‌های سختگیرانه ای در مورد ایمیل اعمال نمی کنند. این مساله منجر به عدم آگاهی سازمانها از منابع مختلف داخلی و خارجی ایمیل خود، شده است. بزرگترین مشکل پیاده سازی SPF تشخیص اینکه در حال حاضر چه کسی در حال ارسال ایمیل معتبر از طرف شما است.
مسایلی که باید دنبال کنید:
a. اهداف آشکار: سرورهای Exchange و یا هرگونه سرورهای groupware و گیت وی ایمیل خروجی
b. هرگونه راهکار DLP و یا سیستمهای پردازش ایمیلی که امکان ارایه هشدار دارد.
c. سیستمهای CRM که اطلاعات مرتبط با مشتریان را ارسال می‌کنند.
d. برنامه های 3rd party مختلفی که ایمیل ارسال می‌کنند.
e. سرورهای تست ، lab و … که ایمیل ارسال می‌کنند.
f. رایانه های شخصی و سایر ابزارهایی که برای ارسال ایمیل خارجی پیکربندی شده است.
لیست فوق کامل نبوده زیرا سازمانها محیط های متفاوتی را تجربه می کنند، لیکن به عنوان یک راهنمای کلی مفید است. زمانیکه اغلب منابع ایمیل شما مشخص باشد، احتمال دارد تمایل داشته باشید یک قدم به عقب بازگشته و درعوض تایید جداگانه هر منبع از یک لیست استفاده کنید. در حالت ایده آل مگر در چند مورد استثنا، کلیه ایمیلهای خروجی شما ملزم به عبور از گیت وی خروجی است. چنانچه بازاریابی از طریق ایمیل داشته و یا از 3rd party استفاده می کنید باید زیرساخت موجود را از production email gateway تفکیک کنید. چنانچه شبکه ارسال ایمیل شما پیچیده باشد، ممکن است تمایل به مستندسازی وضعیت فعلی SPF داشته باشید، که این مساله در آینده زمان زیادی برای پاکسازی نیاز دارد.
چنانچه شما به دامینهای متفاوت در یک زیرساخت سرویسی ارایه می دهید، تمایل به ایجاد یک رکورد SPF عمومی و ارجاع آن به هریک از دامینها با استفاده از مکانیزم “include” داشته باشید. اطمینان حاصل کنید که رکورد SPF شما بیش از حد گسترده نباشد؛ به عنوان مثال چنانچه تنها پنج ابزار ارسال SMTP در یک شبکه سابنت /24 وجود داشته باشد، در مقابل افزودن آن به کل شبکه این پنچ آدرس مجزا را به رکورد SPF خود اضافه کنید. حال هدف این است که رکوردها تا حد امکان اختصاصی شود تا احتمال ایمیل‌های حاوی بدافزار با به خطر انداختن شناسه شما، به حداقل برسد.
با گزینه Softfail برای فرستنده های ناسازگار (“~all”) آغاز کنید و تنها زمانیکه از شناسایی کلیه منابع ایمیل اطمینان حاصل کردید وضعیت را به all”) Hardfail-“) تغییر دهید، در غیراینصورت در خطر از دست دادن production email قرار خواهید گرفت. پس از استقرار DMARC و اجرای آزمایشی آن در حالت monitor، قادر به شناسایی کلیه سیستم‌های از دست رفته و بروزرسانی کامل رکورد SPF خواهید بود. تنها در این وضعیت میتوان به صورت امن SPF را در وضعیت hardfail قرار داد.

گام سوم : DMARC

پس از انجام تنظیمات SPF و DKIM زمان ایجاد پالیسی های DMARC رسیده است. شرایط مختلفی را که در بخش پیش به آنها اشاره شد در نظر گرفته و درصورت وجود زیرساخت ایمیل پیچیده آمادگی استقرار بیش از یک رکورد DMARC را داشته باشید.
ایجاد ایمیلهای جایگزینی که گزارشها را دریافت می کنند، و یا ایجاد نرم افزارهای تحت وب که امکان ارایه آن را داشته باشد. هیچ آدرس ایمیل دقیقی برای این منظور تعریف نشده است، لیکن میتواند به شکل توصیفی مانند : rua@domain.com، dmarc.rua@domain.com، mailauth-rua@domain.com و … ایجاد شوند. از وجود یک فرآیند جایگزین برای عاملی جهت پایش آدرسها و ویرایش پیکربندی SPF، DKIM و DMARC و هشدار تیم‌های امنیتی در وضعیت spoofing campaign، اطمینان حاصل کنید. در ابتدا، در زمان تعریف رکوردها به منظور پوشش کلیه مسایلی که در ارتباط با پیکربندی SPF و DKIM از قلم افتاده است، بار کاری زیادی وجود دارد. پس از مدتی گزارشات تنها احتمال تلاش‌هایی برای spoofing را نمایش خواهند داد.
در ابتدا پالیسی DMARC را در وضعیت “none” و وضعیت گزینه ارسال گزارش را در حالت تست تمام وضعیت‌هایfail “fo=1 قرار داده، که در این حالت به سرعت کلیه خطاهای موجود در SPF و DKIM بدون تاثیرگذاری بر ترافیک گزارش می شود. زمانیکه نتایج گزارشها رضایت بخش بود باتوجه به پالیسی امنیتی و اولویت های خود، پالیسی را در وضعیت “quarantine” و “reject” قرار دهید. مجددا از وجود عاملی که به صورت پیوسته به تحلیل گزارشات DMARC دریافت شده برای کلیه حالتهای false positive، اطمینان حاصل کنید.
پیاده سازی صحیح و کامل DMARC، فرآیندی پیچیده و طولانی است. برخی از نتایج ( در پیاده سازی رسمی DMARC) از طریق انتشار یک مجموعه ناقص از رکوردها و پالیسی “none” بدست می آید. این مساله برای سازمان‌های ارسال کننده و همچنین اینترنت به عنوان محلی که همه سازمانها به منظور ارتقا نهایی قابلیت هایش، آن را پیاده سازی می کنند جذاب است.
حال به ارایه یک طرح کلی و جدول زمانی مناسب برای پیاده سازی یک پروژه نمونه پرداخته می‌شود. باید توجه داشت که سازمان‌ها متفاوت بوده و این مراحل برای کلیه سازمانها دقیق و متناسب با نیازهای آنها نخواهد بود:

ردیف	موضوع	زمان
1	برنامه ریزی و تهیه مقدمات DKIM	2-4 هفته
2	آزمون اجرای DKIM	2 هفته
3	شناسایی فرستنده معتبر SPF	2-4 هفته
4	آماده سازی پالیسی DMARC	2 هفته
5	اجرای تست رکوردهای SPF و DMARC	4-8 هفته
6	اجرای تست SPF به همراه hardfail	2هفته
7	اجرای تست DMARC به همراه quarantine/reject	4 هفته
8	پایش گزارشات DMARC و تطبیق SPF/DKIM با این گزارشات	به صورت پیوسته

پیاده سازی در سازمانهای کوچک زمان کمتری به ویژه در مراحل 3و4 نیاز دارد. صرف نظر از سادگی زیرساخت ایمیل، معمولا زمان زیادی به انجام تست‌ها و بررسی فیدبک گزارشها اختصاص دهید. سازمان‌ های بزرگتر مراحل فوق را در زمانهای طولانی تر و الزامات سختگیرانه تری تجربه می کنند. معمولا سازمانهایی با زیرساخت ایمیل پیچیده، نه تنها از جنبه‌های پیاده سازی احراز هویت بلکه از منظر مدیریت کل پروژه و هماهنگی تیم ها و ادارات از کمک مشاوران بهره می گیرند.

در این خصوص، شرکت پایه ریزان فناوری هوشمند توانایی ارائه انواع لایسنس‌های شبکه را دارد و شما می‌توانید برای خرید لایسنس Cisco ESA اقدام به درخواست قیمت کنید.