O365 Message Encryption & DNS Records

בפוסטים הקודמים דיברנו על התצורה ההיברידית בעבודה מול Office365. בפוסט הזה נתמקד בשכבות ההגנה שיש לנו בסביבת O365 שלנו כאנשי IT ונסביר למה אנחנו צריכים אותם.

בOffice365-  רשומות אלו הם דרישות חובה על מנת לאמת את הדומיין שלנו .

ברגע שיש לנו דומיין, בין אם הוא הדומיין הראשי או משני (להלן : Sub Domain) אנחנו צריכים לתחום אותו במס' דרכים:

‍

(Sender Policy Framework (SPF

מערכת פשוטה לאימות דואר אלקטרוני שמטרתה העיקרית היא לזהות זיוף והתחזות לגורמים אחרים. היא עושה זאת בעזרת מנגנון שמאפשר לשרתי קבלת הדואר לבדוק שהודעות המגיעות מדומיין מסוים.

האימות של רשומה זו מוגדרת על ידי הוספת רשומות  TXT בדוגמאות הבאות, כאשר הראשונה מתריעה כ- Hard Fail שבה המייל נחסם במידה והוא לא מזוהה אל מול שירותי Exchange Online ואילו השני מופיע כ- Soft Fail כבלתי מורשה לשלוח אך מקבל הודעת שגיאה.

• v=spf1 include:mail.outlook.protection.com -all
• v=spf1 include:mail.outlook.protection.com ~all

‍

בצד הספק רשומות TXT מסוג זה לוקח בין 24-48 שעות להתעדכן תלוי בצד הספק,

למידע נוסף על תצורת SPF לחצו כאן

שכבת הגנה נוספת התלויה ב-SPF היא DKIM.

‍

DKIM

DomainKeys identified Mail)) היא שיטה מבוססת DNS שמטרתה לזהות האם הודעה זויפה. תוך כדי שימוש בטקסט מוצפן  בכדי לבדוק את האותנטיות של הדוא"ל. מקורות האימייל יוצרים "Hashing", ואז מצפינים אותו בכותרת בלבד או בהודעה כולה תוך שימוש במפתח נסתר. תהליך זה למעשה מתרגם סימנים קריאים והופך אותם לרצף טקסט ייחודי.

המפתח הציבורי שתואם למפתח הפרטי מתפרסם בסאב דומיין מסוים שנעשה בו שימוש בהצפנה. מכיוון שרק אותו דומיין מורשה יכול לפרסם אימות DNS עבור הסב דומיין, זה מחבר את המפתח הציבורי עם בעל הדומיין.

כאשר מתקבל  מייל עם חתימת DKIM, הוא מקבל למעשה את אותו  מפתח ציבורי. אז השרת משתמש במפתח הציבורי בכדי לפענח את החתימה ששולבה בהודעה. לאחר מכן, שרת הדואר מחשב את ה"Hashing" של אותו דואר נכנס כבעל אלגוריתם זהה למקור האימייל. במידה וזה התקבל ונוצרת התאמה עבור הדומיין  כחתימה מקודדת, אז ההודעה מאומתת. אם לא, היא תידחה  ע"י הספק או לחילופין  תשלח אל תיקיית Junk E-mail בצד תיבת הדואר של המשתמש .

בעיקרון דרך זו הינה חתימה מאובטחת בשליחת דואר יוצא ע"י חתימה שהמייל נשלח מהדומיין שלנו ובקבלת דואר נכנס אל הדומיין שלנו .

על מנת להפעיל שכבה זו בOffice365 יש לפעול עפ"י הדרך הבאה :  

• הוספת רשומות DNS עבור כל דומיין שיש לנו גם אם הוא סאב דומיין , לדוגמה :  

‍

Host name:selector1._domainkey

Points to address or value:selector1-<domainGUID>._domainkey.<initialDomain>

TTL:3600

Host name:selector2._domainkey

Points to address or value:selector2-<domainGUID>._domainkey.<initialDomain>

TTL:3600

Enable DKIM signing for your custom domain in Office 365

Once you have published the CNAME records in DNS, you are ready to enable DKIM signing through Office 365. You can do this either through the Office 365 admin center or by using PowerShell.

To enable DKIM signing for your custom domain through the Office 365 admin center

1. Sign in to Office 365 with your work or school account.

2. Select the app launcher icon in the upper-left and choose Admin.

3. In the lower-left navigation, expand Admin and choose Exchange.

4. Go to Protection > dkim.

5. Select the domain for which you want to enable DKIM and then, for Sign messages for this domain with DKIM signatures, choose Enable. Repeat this step for each custom domain.

To enable DKIM signing for your custom domain by using PowerShell

6. Connect to Exchange Online PowerShell.

7. Run the following command:

New-DkimSigningConfig -DomainName <domain> -Enabled $true

Where domain is the name of the custom domain that you want to enable DKIM signing for.

For example, for the domain contoso.com:

New-DkimSigningConfig -DomainName contoso.com -Enabled $true

‍

נלקח מן המאמר הבא

‍

DMARC

Domain-Based Message Authentication, Reporting, and Conformance הינו פרוטוקול לצורך אימות דוא"ל שמסתמך על  SPF ו DKIM. הדומיין השולח משתמש בפרוטוקול זה בכדי למנוע דוא"ל מזוייף. יש לו תכונות הכוללות דיווח, תיאור המדיניות ותצורת זהות .

בOffice365  נשתמש בו כך :

נוסיף רשומת TXT המוגדרת בצורה הבאה  :

_dmarc.microsoft.com.   3600    IN      TXT     "v=DMARC1; p=none; pct=100; rua=mailto:d@rua.agari.com; ruf=mailto:d@ruf.agari.com; fo=1"

מצרף גם מדריך הגדרת DMARC בארגון שיש בו Office365 :

Implement DMARC for inbound mail

You don't have to do a thing to set up DMARC for mail that you receive in Office 365. We've taken care of everything for you. If you want to learn what happens to mail that fails to pass our DMARC checks, see How Office 365 handles inbound email that fails DMARC.

Implement DMARC for outbound mail from Office 365

If you use Office 365 but you aren't using a custom domain, that is, you use onmicrosoft.com, you don't need to do anything else to configure or implement DMARC for your organization. SPF is already set up for you and Office 365 automatically generates a DKIM signature for your outgoing mail. For more information about this signature, see Default behavior for DKIM and Office 365.

If you have a custom domain or you are using on-premises Exchange servers in addition to Office 365, you need to manually implement DMARC for your outbound mail. Implementing DMARC for your custom domain includes these steps:

• Step 1: Identify valid sources of mail for your domain

• Step 2: Set up SPF for your domain in Office 365

• Step 3: Set up DKIM for your custom domain in Office 365

• Step 4: Form the DMARC TXT record for your domain in Office 365

Step 1: Identify valid sources of mail for your domain

If you have already set up SPF then you have already gone through this exercise. However, for DMARC, there are additional considerations. When identifying sources of mail for your domain there are two questions you need to answer:

• What IP addresses send messages from my domain?

• For mail sent from third parties on my behalf, will the 5321.MailFrom and 5322.From domains match?

Step 2: Set up SPF for your domain in Office 365

Now that you have a list of all your valid senders you can follow the steps to Set up SPF in Office 365 to help prevent spoofing.

For example, assuming contoso.com sends mail from Exchange Online, an on-premises Exchange server whose IP address is 192.168.0.1, and a web application whose IP address is 192.168.100.100, the SPF TXT record would look like this:

contoso.com  IN  TXT  " v=spf1 ip4:192.168.0.1 ip4:192.168.100.100 include:spf.protection.outlook.com -all"

As a best practice, ensure that your SPF TXT record takes into account third-party senders.

Step 3: Set up DKIM for your custom domain in Office 365

Once you have set up SPF, you need to set up DKIM. DKIM lets you add a digital signature to email messages in the message header. If you do not set up DKIM and instead allow Office 365 to use the default DKIM configuration for your domain, DMARC may fail. This is because the default DKIM configuration uses your initial onmicrosoft.com domain as the 5322.From address, not your custom domain. This forces a mismatch between the 5321.MailFrom and the 5322.From addresses in all email sent from your domain.

If you have third-party senders that send mail on your behalf and the mail they send has mismatched 5321.MailFrom and 5322.From addresses, DMARC will fail for that email. To avoid this, you need to set up DKIM for your domain specifically with that third-party sender. This allows Office 365 to authenticate email from this 3rd-party service. However, it also allows others, for example, Yahoo, Gmail, and Comcast, to verify email sent to them by the third-party as if it was email sent by you. This is beneficial because it allows your customers to build trust with your domain no matter where their mailbox is located, and at the same time Office 365 won't mark a message as spam due to spoofing because it passes authentication checks for your domain.

For instructions on setting up DKIM for your domain, including how to set up DKIM for third-party senders so they can spoof your domain, see Use DKIM to validate outbound email sent from your custom domain in Office 365.

Step 4: Form the DMARC TXT record for your domain in Office 365

Although there are other syntax options that are not mentioned here, these are the most commonly used options for Office 365. Form the DMARC TXT record for your domain in the format:

_dmarc.domain  TTL  IN  TXT  "v=DMARC1; pct=100; p=policy"

where:

• domain is the domain you want to protect. By default, the record protects mail from the domain and all subdomains. For example, if you specify _dmarc.contoso.com, then DMARC protects mail from the domain and all subdomains, such as housewares.contoso.com or plumbing.contoso.com.

• TTL should always be the equivalent of one hour. The unit used for TTL, either hours (1 hour), minutes (60 minutes), or seconds (3600 seconds), will vary depending on the registrar for your domain.

• pct=100 indicates that this rule should be used for 100% of email.

• policy specifies what policy you want the receiving server to follow if DMARC fails. You can set the policy to none, quarantine, or reject.

For information about which options to use, become familiar with the concepts in Best practices for implementing DMARC in Office 365.

‍

Examples:

• Policy set to none

• _dmarc.contoso.com 3600 IN  TXT  "v=DMARC1; p=none"

• Policy set to quarantine

• _dmarc.contoso.com 3600 IN  TXT  "v=DMARC1; p=quarantine"

• Policy set to reject

_dmarc.contoso.com  3600 IN  TXT  "v=DMARC1; p=reject"

נלקח מהמאמר הנ"ל

אותו מאמר אגב מתאר את הBest Practice-  לעבוד עם DMARC.

לסיכום , את הבדיקות הנ"ל ניתן לבצע דרך כלי Nslookup או דרך אתר MX Tool Box כדי לוודא את תקינות כלל הרשומות שציינתי.

https://mxtoolbox.com/

ישנם ארגונים היום שמפעילים רק אחת מהשכבות או שתיים מהם שלרוב זה SPF וגם DKIM.

DMARC נחשב כהגדרה מחמירה והפעלת כלל השכבות יוצרת הגנה אחת כללית.

‍

‍

מאת : עידן נפתלי | יועץ וארכיטקט תשתיות מחשוב, פתרונות ענן ואבטחת מידע | U-BTech Solutions.

‍