آشنایی با پروتکل احراز هویت DMARC ایمیل

(DMARC (Domain-based Message Authentication, Reporting & Conformance آخرین و پیشرفته ترین پروتکل احراز هویت می باشد. اما مانند SPF و DKIM گاهی اوقات به درستی قابل درک نمی باشد.

DMARC تضمین می کند که ایمیل های قانونی به درستی در برابر استانداردهای DKIM و SPF تایید شده اند و فعالیت های جعلی از دامنه های تحت کنترل سازمان (دامنه های ارسال فعال، دامنه های ارسال نشده و دامنه های ثبت شده دفاع می کنند) مسدود شده است. دو مقوله اصلی DMARC، Alignment و Reporting هستند.

ویژگی DMARC Alignment از جعل کردن آدرس Header From جلوگیری می کند.

  • تطبیق نام دامنه در Header From با Envelope From در طی بررسی SPF
  • تطبیق نام دامنه در Header From با نام دامنه در امضای DKIM

 

نحوه کار DMARC:

پروتکل DMARC

برای پاس شدن DMARC، یک پیغام باید احراز هویت SPF و SPF Alignment و/یا احراز هویت DKIM و DKIM Alignment را پاس کند، یک پیغام در احراز هویت DMARC رد خواهد شد اگر در هر دو (1) SPF  یا SPF Alignment و (2)   DKIM یا DKIM Alignment رد شود.

DMARC به فرستنده ها اجازه می دهد تا به ارائه دهندگان ایمیل در مورد چگونگی برخورد با ایمیل های ناخواسته از طریق DMARC Policy کمک کند، تا هر گونه حدس و گمان در نحوه برخورد با ایمیل هایی که احراز هویت DKIM آنها Fail  شده از بین برود، فرستنده ها می توانند:

  • نظارت بر همه ایمیل ها برای درک اکوسیستم احراز هویت ایمیل خود و اطمینان از اینکه ایمیل های قانونی به درستی تایید می شوند
  • قرنطینه پیغام هایی که در احراز هویت DMARC رد شده اند ( انتقال به فولدر Spam )
  • Reject کردن پیغام هایی که در احراز هویت DMARC رد شده اند.

 

ارائه دهندگان صندوق پستی گزارشات جامعی را به فرستندگان ایمیل ارسال می کنند، که به آن ها ایمیل هایی که احراز هویت شده اند و چه آنهایی که رد شده اند را به همراه دلایل آن گزارش می دهند.

DMARC اولین و تنها تکنولوژی است که می تواند از آدرسHeader From  که کاربران در ایمیل خود می بیند محافظت نمایند، این کار نه تنها به محافظت مشتریان و سازمان کمک می کند بلکه مجرمان سایبری را دلسرد می کند چون کمتر به سراغ سازمانی که دارای رکورد DMARC است می روند.

آشنایی با پروتکل احراز هویت DKIM ایمیل

(DomainKeys Identified Mail (DKIM پیچیده ترین پروتکل تصدیق ایمیل می باشد، این مقاله به صورت اختصاصی به معرفی پروتکل DKIM خواهیم پرداخت. با ما همراه باشید:

(DomainKeys Identified Mail (DKIM یک پروتکل است که به سازمان ها اجازه می دهد تا انتقال پیام را به گونه ای که توسط ارائه دهندگان ایمیل قابل تایید باشد، انجام دهند. این تاییدیه توسط احراز هویت رمزنگاری شده (Cryptographic authentication) و از طریق کلید های Public  و Private  انجام می پذیرد.

DKIM  کمی پیچیده می باشد، در ادامه سعی می کنیم، به زبانی ساده آن را برای شما شرح دهیم.

 

گام اول: شناسایی عناصر یک پیغام برای Sign در DKIM

یک فرستنده ایمیل ابتدا باید تصمیم بگیرد که کدام Elements های یک ایمیل را می خواهد در فرایند Sign  قرار دهد، آن ها باید تصمیم بگیرند که کل پیام (Header,Body) یا فقط یک یا چند فیلد خاص در هدر ایمیل در جریان این فرایند رمزنگاری قرار بگیرد.، Element هایی که قرار است در Sign DKIM  قرار بگیرند نباید در حین انتقال پیام تغییر کنند، در غیر اینصورت احراز هویت DKIM رد یا Fail  می شود.

برای مثال، اگر یک ایمیل از Yahoo  به Gmail   forward شود، یاهو یک متن در بالای ایمیل مانند (forward By yahoo mail)  اضافه می کند و Body  ایمیل دچار تغییر می شود، اگر Body  جز Element  های امضا شده در فرایند DKIM  باشد، احراز هویت در ایمیل Forward  شده Fail  خواهد شد.

با این حال، اگر تنها یک Element از Header مانند فیلد From در فرایند امضای DKIM قرار گرفته باشد، و ایمیل از Yahoo به Gmail  forward شود، احراز هویت DKIM  تایید می شود، زیرا آن بخشی از ایمیل که تغییر کرده است در فرایند امضای DKIM  قرار نگرفته بوده است.

گام دوم: فرایند رمزنگاری

فرستنده باید یک سری تنظمیات بر روی Platform ایمیل خود انجام دهد، که به صورت خودکار یک Hash از Element هایی که قرار است در فرایند Sign قرار بگیرند ساخته شود. فرایند Hash، متن را تبدیل به یک رشته متنی منحصر بفرد می کند.

<From: Ehsan Ataei <IT@PardisMail.com

Subject: Testing

:Maps to the following unique hash string

3303baf8986f910720abcfa607d81f53

قبل از ارسال ایمیل، رشته متنی Hash  شده با استفاده از Private Key  رمزنگاری می شود، کلید خصوصی از ترکیب نام دامنه و Selector (هر اسمی امکان پذیر می باشد، بیشتر بر اساس نوع کاربری ایمیل انتخاب می شود) ساخته می شود، که به شما این قابلیت را می دهد که چندین کلید خصوصی قانونی برای یک دامنه داشته باشید( که برای مدیریت ایمیل و اهداف امنیتی مهم می باشد)، و فقط فرستنده به کلید خصوصی دسترسی دارد. بعد از کامل شدن فرایند رمزنگاری ایمیل ارسال می شود.

 

گام سوم: تایید DKIM Signature با کلید عمومی:

Mail سرور گیرنده بعد از دریافت ایمیل، متوجه می شود که ایمیل دارای امضای DKIM  می باشد، که نشان دهنده نام دامین و Selector  است که فرایند رمزنگاری را امضا کرده اند، دریافت کننده ایمیل یک پرس و جو Query DNS برای پیدا کردن کلید عمومی براسا Domain\Selector  برای تایید امضا انجام می دهد.

کلید عمومی دارای خصوصیات منحصربفردی است که تنها با کلید خصوصی که ایمیل را امضا کرده است، مطابقت دارد،که به عنوان keypair match هم شناخته می شود، که ارائه دهندگان ایمیل را قادر به رمزگشایی امضای DKIM   و بدست آوردن رشته اصلی Hash میسازد.

ارائه دهندگان ایمیل  سپس با استفاده از Element های شرکت کننده در امضای DKIM دوباره یک Hash از این عناصر میسازد، سپس هش را با هش بدست امده از DKIM Hash مقایسه می کند، اگر دو Hash  با هم مطابقت داشته باشند، ما می دانیم که:

  • دامنه با امضای DKIM مالک ایمیل می باشد، در غیر اینصورت فرایند رمزگشایی در وهله اول کار نخواهد کرد.
  • عناصر ایمیل که توسط DKIM امضا شده بودند در هنگام ارسال تغییری نکرده اند (زیرا اگر تغییر کرده بودند، Hash ها با یکدیگر مطابقت نداشتند).

 

ارائه دهندگان ایمیل که امضای DKIM را تایید می کنند، می توانند از اطلاعات مربوط به امضاکننده به عنوان بخشی از یک برنامه برای کاهش حملات Spam,Spoofing و Phishing  استفاده کنند، هر چند که DKIM به دریافت کنندگان ایمیل برای انجام، اقدامی خاص کمک نمی کند، بستگی به پیاده سازی DKIM می توان اطمینان حاصل کرد که پیام در نقل و انتقالات دستخوش تغییرات بوده است یا خیر

 

مشکل DKIM این است که به دلیل اجرای سخت پیاده سازی، فرستنده های کمتری آن را قبول کرده اند، این نقطه ضعف بدان معنی است که عدم وجود امضای DKIM لزوما نشان دهنده جعلی بودن ایمیل نیست، بنابراین DKIM یک راه قابل اعتماد برای تایید هویت فرستنده نیست، علاوه بر این DKIM برای کاربر نهایی غیر فنی قابل مشاهده نیست، و هیچ کاری برای جلوگیری از جعل هویت Header From  دامین نمی کند.

DMARC، آخرین و پیشرفته ترین پروتکل در احراز هویت ایمیل می باشد و این مشکل را با تضمین اینکه دامنه قابل مشاهده برای کاربر نهایی همان دامنه ای است که توسط SPF و DKIM بررسی و تایید شده است حل می کند. علاوه بر این، ارائه دهندگان صندوق پستی را با دستورالعمل مشخصی در مورد اینکه کدام ایمیل ها باید توسط DKIM  احراز هویت شوند و کدامیک نه کمک رسانی می کند.

چگونگی اضافه کردن reCAPTCHA به Outlook Web App

یکی از مسائل مهم این روزها در فناوری اطلاعات بحث امنیت می باشد که تمامی ادمین های شبکه را درگیر خود نموده است و همیشه باید حداکثر تدابیر امنیتی را برای شبکه های تحت پشتیبانی خود در نظر بگیرند تا از تهدیدهای اینترنتی در امان بمانند. در این مقاله قصد داریم تا شما را با یکی از راه های امن نمودن ایمیل سرور آشنا کنیم با ما همراه باشید:

در این مقاله می خواهیم در مورد نحوه اضافه کردن قابلیت امنیتی Google reCAPTCHA به صفحه OWA در Exchange Server صحبت کنیم.
قبل از شروع کار بهتر است اطلاعاتی در مورد این سرویس داشته باشید طبق اطلاعاتی که در سایت ویکی پدیا (https://fa.wikipedia.org/wiki/%D8%B1%DB%8C%E2%80%8C%DA%A9%D9%BE%DA%86%D8%A7) درج شده است در واقع reCAPTCHA نسخه جدید و بهینه CAPTCHA می باشد که این قابلیت جهت تفکیک ربات از انسان هنگام دسترسی به یک وب پیج کمک می‌کند. در نتیجه از طریق این قابلیت مطمئن می شوید که یک انسان قصد دسترسی به سایت مورد نظر را دارد. این قابلیت توسط لویز فن آخن، بن مائورر، کالین مک میلن، دیوید ابراهام و مانوئل بلوم در دانشگاه کارنگی ملون در محوطه دانشکده پیتسبرگ توسعه داده شد و سپس در سال 2009 به مالکیت گوگل در آمد.
همانطور که می‌دانید یکی از راههای اتصال کاربران به Exchange Server از طریق وب یا همان OWA می باشد که به صورت امن و از طریق پورت 443 انجام می شود اما ماهیت وب آسیب پذیر می‌باشد و نیاز است از طریق راهکاری جانبی نسبت به امن سازی بیشتر آن اقدامات لازم را انجام دهیم. یکی از این راهکارها اضافه کردن قابلیت Google reCAPTCHA می باشد. از طریق Google reCAPTCHA ابتدا مطمئن می‌شویم که کلاینتی که قصد لاگین به OWA دارید یک کاربر می‌باشد یا یک روبات. سپس از طریق نام کاربری و رمز عبور که برای کاربر نهایی در نظر گرفته شده است امکان لاگین و دسترسی به میل باکس فراهم می‌شود.
مراحل انجام کار به این صورت می‌باشد که ابتدا از طریق اکانت گوگل نسبت به ایجاد و رجیستر کردن یک سرویس reCAPTCHA برای دامین مورد نظر اقدام کنید و سپس از طریق کدهای اعلامی و تنظیمات لازم در Exchange Server امکان استفاده از این سرویس امنیتی در OWA فراهم شود.
مراحل انجام کار به صورت زیر می‌باشد:
1- ابتدا با سرچ کردن کلید واژه google recaptcha به صفحه https://www.google.com/recaptcha/intro/v3.html وارد شوید.
2- سپس با نام کاربری اکانت خود در Gmail لاگین کرده و نسبت به رجیستر دامین و اخذ کد برای reCAPTCHA اقدام کنید.

3- سپس با کلیک بر روی SUBMIT کد رجیستری مورد نیاز را دریافت کنید.

 

همانطور که مشاهده نمودید دریافت کد رجیستری reCAPTCHA به سادگی و در چند مرحله ساده انجام شد. مرحله بعدی مربوط به استفاده از این کدها در OWA می‌باشد.

در نظر داشته باشید که کل این فرآیند برنامه نویسی می‌باشد و برای متخصصین برنامه نویسی بسیار ساده می‌باشد اما شاید برای ادمینهای شبکه کاری سخت و پیچیده باشد. اگر مراحل این مقاله را به همین ترتیب و با دقت انجام دهید بدون نیاز به دانش برنامه نویسی به سادگی می‌توانید از قابلیت امنیتی Google reCAPTCHA در Exchange Server خود استفاده کنید.
4- به سروری که در آن Exchange Server را نصب نموده اید لاگین کنید و وارد مسیر زیر شوید:

C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\auth

از طریق notepad یک فایل با نام recaptcha.aspx ایجاد کنید و آن را باز کنید. محتویات زیر را عیناً در این فایل جایگذاری کنید.

<% @ Page AspCompat=True Language = “VB” %>
<%
‘ Put your own private key in the next line
Dim strPrivateKey As String = “SECRET KEY”
Dim strResponse = Request(“response”)
Dim objWinHTTP As Object
objWinHTTP = Server.CreateObject(“WinHTTP.WinHTTPRequest.5.1”)
objWinHTTP.Open(“POST”, “https://www.google.com/recaptcha/api/siteverify”, False)
objWinHTTP.SetRequestHeader(“Content-type”, “application/x-www-form-urlencoded”)
Dim strData As String = “secret=” & strPrivateKey & _
“&response=” & strResponse
objWinHTTP.Send(strData)
Dim strResponseText = objWinHTTP.ResponseText
Response.Write(strResponseText)
%>

Secret Key دریافت شده گوگل را به جای “SECRET KEY” جایگذاری کنید. فایل را ذخیره نموده و ببندید.
5- در همین مسیر فایلی به نام logon.aspx وجود دارد، ابتدا یک کپی از این فایل تهیه نمایید تا در صورت بروز مشکل امکان بازگشت به حالت فعلی را داشته باشید. سپس فایل را طریق نرم افزار notepad باز نموده و تغییرات زیر را در آن اعمال نمائید.
– از طریق میانبر CTRL-F نسبت به جستجوی پاراگراف زیر اقدام نمایید:

form action=”/owa/auth.owa” method=”POST” name=”logonForm”

سپس این محتوای داخل action را حذف نمایید، نتیجه نهایی می بایست به صورت زیر شود:

form action=” ” method=”POST” name=”logonForm”

 

– مجددا از طریق میانبر CTRL-F پاراگراف زیر را جستجو نمائید:

<div><input id=”passwordText”

– بلافاصله در خط بعدی محتوای زیر را اضافه نمائید:

<tr>
<td>
<script type=”text/j-avascript”>
function myClkLgn()
{
var oReq = new XMLHttpRequest();
var sResponse = document.getElementById(“g-recaptcha-response”).value;
var sData = “response=” + sResponse;
oReq.open(“GET”, “/owa/auth/recaptcha.aspx?” + sData, false);
oReq.send(sData);
if (oReq.responseText.indexOf(“true”) != -1)
{
document.forms[0].action = “/owa/auth.owa”;
clkLgn();
}
else
{
alert(“کد تأیید تکمیل نشده است” + “\n” +”reCAPTCHA is not valid”);
}
}
</script>
<script src=”https://www.google.com/recaptcha/api.js” async defer></script>
<div class=”g-recaptcha” data-sitekey=”SITE KEY”></div>
</td>
</tr>

– Site Key دریافت شده از گوگل را جایگزین SITE KEY کنید.
– مجدداً از طریق میانبر CTRL-F پاراگراف زیر را جستجو کنید:

<div on-click=”clkLgn()” class=”signinbutton” role=”button” tabIndex=”0″ >

به جای واژه clkLgn واژه myClkLgn را جایگزین کنید. نتیجه نهایی می بایست به صورت زیر شود:

<div on-click=”myClkLgn()” class=”signinbutton” role=”button” tabIndex=”0″ >

اکنون بدون اینکه نیاز به ری استارت سرور یا سرویس IIS داشته باشید قسمت گرافیکی مربوط به سرویس Google reCAPTCHA را در OWA خود مشاهده می‌کنید.
در نظر داشته باشید برای اینکه این قابلیت به درستی انجام شود سرور ایمیل باید به URL زیر دسترسی داشته باشد:

https://www.google.com/recaptcha/api.js

اگر اینترنت ایمیل سرور را از طریق فایروال محدود نموده‌اید حتما دسترسی به این URL را برای سرور فراهم کنید.

 

آشنایی پیش نیازهای Exchange Server 2019

در این مقاله قصد داریم تا شما را با پیش نیازهای این نرم افزار آشنا کنیم با ما همراه باشید:

 

سازگاری با نسخه های پیشین:

سازگاری Exchange 2019 با نسخه های قدیمی در جدول زیر شرح داده شده است:

exchange server 2019 prerequisites

پیش نیاز های مورد نیاز در شبکه
پیش نیاز ها و الزامات شبکه برای نصب Exchange 2019 Organization در جدول زیر شرح داده شده است:

exchange server 2019 prerequisites
معماری Directory Server:

نصب Active Directory بر روی سخت افزار 64-bit با یک ویندوز سرور 64-bit باعث افزایش عملکرد directory Service ها در Exchange 2019 خواهد شد.

نصب Exchange بر روی Active Directory
به دلایل امنیتی و کارایی، توصیه نمی شود که Exchange 2019 را بر روی Active Directory نصب کنید، Exchange 2019 را تنها بر روی Member Servers ها نصب نمایید.

 

exchange server 2019 prerequisites

سیستم عامل:

سیستم عامل های پشتیبانی شده برای نصب Exchange 2019 در جدول زیر شرح داده شده است:

exchange server 2019 prerequisites
نکته:
• نصب Exchange 2019 بر روی Window Server Core به صورت کامل پشتیبانی و توصیه می شود و ویژگی Desktop Experience دیگر جزء الزامات نیست.
• نصب Exchange 2019 بر روی Nano Server پشتیبانی نمی شود.

نسخه های پشتیبانی شده PowerShell در Exchange 2019
سرورهای Exchange 2019 از نسخه ای که در زمان انتشار ویندوز سرور قرار دارد پشتیبانی می کند، به هیچ وجه نسخه های Stand-Alone WMF or PowerShell را بر روی سرور Exchange نصب نکنید.
.NET Framework
توصیه می شود آخرین نسخه.NET Framework که توسط Exchange پشتیبانی می شود را نصب کنید.
.NET Framework هایی که در جدول زیر لیست نشده اند در هیچ نسخه ای از Exchange 2019 پشتیبانی نمی شوند، این شامل نسخه های جزئی و پچ در .NET می باشد.

exchange server 2019 prerequisites
نسخه های Outlook پشتیبانی شده
Outlook 2019
• Outlook 2016
• Outlook 2016 for Mac
• Outlook 2013
• Outlook for Mac for Office 365

پکپارچگی با Lync/Skype
برای ادغام Lync Presence و Lync Messaging با Exchange Server به Lync Server 2013 Cumulative Update 10 یا بالاتر و همچنین برای ادغام Skype for Business presence و Instant Messaging با Exchange Server به Skype for Business Server Cumulative Update 7 به بالا احتیاج است.