.jpg)
המאמר מתמקד בהקשחה דואר ארגוני באמצעות Exchange Transport Rule בלבד, והינו חלק מסדרת אפשרויות להקשחה באמצעות Exchange Online Protection, Office ATP והמון כלים נוספים.
ספאם, פישינג ודואר זדוני הם בעיות שהולכות ומתגברות, וככל שעובר הזמן הטכניקות של התוקפים משתפרות. למשל לאחרונה, התקפות פישינג נעשות באמצעות בוטים (או יותר Bot Phishing), אשר משלבים קישורים מבוססים HTTPS.
ביצוע הונאות באמצעות תעבורת הדואר עלול להיות מגוונות עם אפשרויות שונות. למשל: שם תצוגה זהה, שם דומיין זהה, כתובת דואר זהה ולעיתים אפשר לשלב את כולם יחדיו, ולקבל משהו ממש אמיתי.
למשל, בדוגמה המצורפת התקבל "מייל" עם שם תצוגה, כתובת מייל ובקשה מסוימת. חשוב להדגיש כי שליחת הדואר נעשתה מתוך מנגנון כולל ומוגדר עם תקנים שונים כגון Dkim.
כיום, האפשרויות בשליחת דואר מתוך מנגנון מסוים פשוטה יותר מאשר בעבר, וישנם מנגנונים ברשת המאפשרים ביצוע התחזות עם כל הפרמטרים הנדרשים.
מיותר לומר שבמקרים מסוימים ישנה השקעה מרבית בקמפיינים, וניתן לראות לעיתים דוגמאות כמו זאת המצורפת - וגם לעין טכנית קשה לזהות את ההבדל.
מנגד, ניתן לראות התעסקות רבה בהגנה על הארגון, ולעיתים רבות מדובר על גבי שילוב מספר מערכות (שתיים או שלוש כאלו) המבצעות הגנה כדוגמת Content filtering, Anti-spam וכן הגנה באמצעות חיזוי או ממוקדות, בביצוע CDR או Sandboxים למיניהם, וזאת במטרה למנוע את מתקפת הפישינג הבאה.
האם לתוקפים יש הצלחה? כן, אחוזי הצלחה גבוהים.
מהיכן הבעיה מגיעה? מעבר לעובדה שהטכניקות של התוקפים תמיד נמצאות כמה צעדים על פני המערכות שמבצעות הגנה, אפשר לומר שבגלל ריבוי המערכות, אין ניצול נכון של היכולות בכל מערכת, אם אקח את הדוגמה של Exchange Online - אפשר לומר שרוב הארגונים מנצל רק אחוז קטן מהיכולות הקיימות.
חשוב להדגיש כי בהגנה על הדואר הארגוני, אנו יכולים לצמצם טעויות אנוש ולהקטין את שטח התקיפה באופן משמעותי.
הקשחת דואר ארגוני
להקשחת דואר ארגוני אין Best Practice או Recommendation מסוימים אלא Best from the Field וזאת בגלל סיבות רבות כמו העובדה להתקפות פישינג אין חוקים, אבל כן ישנה הרבה יצירתיות ודינמיות ולכן, נתחיל בהקשחות פשוטות, ומשם נתקדם עם המאמרים לתנאים מתקדמים כולל Prediction, וכל זאת באמצעות Exchange Online או ליתר דיוק, Exchange Transport Rule.
טיפ: אפשרויות החסימה והתניה ברמת ה-ETR הן רבות ומגוונות, למשל ניתן ליצור חוק המשווה בין from לבין return-path, ועל סמך השוואה לא תקינה למרקר או לחסום את הדואר. כלומר, כל מאפיין אשר קיים ברמת Message Header זמין לנו.
התראה על דואר חיצוני עם אותו Display Name
ביצוע Spoofing והתחזות על גבי שם תצוגה עם הערך של Display Name היא בעיה נפוצה, ולכן ניתן למרקר (או לחסום) דואר מהסוג הנ"ל באמצעות ההגדרה הבאה:
• הבעיה – דואר חיצוני אשר מגיע עם אותו שם תצוגה
• מניעה – חוק מותאם לדואר חיצוני עם אותו שם מזהה מול כלל תיבות הדואר
דגשים בחוק
• הגדרת נמענים חיצונים Outside the Organization
• הגדרת ערך לבדיקה באמצעות A Message header matches של כלל תיבות הדואר
• ביצוע פעולה המבוסס על חתימה לפי Prepend the disclaimer
טיפ: מכיוון שהגדרת תיבות דואר לכלל המשתמשים אינה אפשרית באופן פשוט מתוך הממשק, ניתן להגדיר את כלל תיבות הדואר באמצעות PowerShell סקריפט אשר כולל את ערך from לפי השורה הבאה $displayNames = (Get-Mailbox -ResultSize Unlimited).DisplayName
להורדת הסקריפט המלא ExchangeOnline/DN_EXT_SPoof_EXO
טיפ: האפשרויות של הגדרת תנאים וחוקים על גבי PowerShell רחבות יותר מאשר בממשק אדמין.
לאחר הגדרת החוק ושליחת דואר עם אותו Display Name מגורם חיצוני, נקבל את ההודעה הבאה
התראה על דואר חיצוני
דואר חיצוני עלול להכיל קישורים וקבצים זדוניים, ולכן משתמשים עלולים ללחוץ או לפתוח פריטים מגורם שכזה, כתוצאה מכך, החוק הבא מדגיש (מרקור הדואר וניתן לחסום גם) האם הדואר הגיע מגורם חיצוני.
• הבעיה – דואר מגורם חיצוני
• מניעה – חוק המדגיש קבלת דואר בגורם חיצוני
דגשים בחוק
• לוודא הגדרת Message from Outside the Organization
• אפשרי להוסיף לחוק התניה של Recipient located Inside the Organization
• בהגדרת Prepend the disclaimer, מומלץ לשמור על אותו מבנה כמו בחוק הקודם, וזאת על מנת לאפשר להציג את ההודעה באותו מבנה ולא בשורה נוספת ונפרדת
חסימת דואר עם דומיין זהה (Domain Look-Alike)
במקרים של טירגוט, התוקף שולח דואר עם דומיין אשר זהה לדומיין שלנו בכדי לבצע סוג של Impersonation ולכן במקרים כאלה ניתן לראות כי גם שם התצוגה וגם שם הדומיין הם זהים באופן שווה לנמען הפנימי.
החוק הבא חוסם קבלת דואר מגורם חיצוני עם שם דומיין זהה.
• הבעיה – דואר מגורם חיצוני עם אותו Domain Name
• מניעה – חסימת קבלת דואר מגורם חיצוני
דגשים בחוק
• הגדרת התניה של Sender is outside the Organization
• התניה עם Recipient is Inside the Organization
• חשוב מאוד The Sender domain is עם שם הדומיין הייעודי של הארגון
• ביצוע הפעולה יכול מגוון פעולות, ובדוגמה הבאה בחרתי באפשרות Generate Incident
טיפ: ביצוע האכיפה יכול להיות פעולה אחרת, אך מומלץ לא להגדיר במצב כזה אכיפה עם חתימה והתראה במייל אלא לחסום.
לסיכום
הפעולות והדרכים להגדרת תנאים וחוקים על גבי ETR, מאפשרים למרקר הודעות דואר מסוימות ולחסום מקרים אחרים, ואנו יכולים לשלוט על כל תעבורת הדואר בהתאם לערכים והפרמטרים המוצעים על גבי Exchange Online.
האפשרויות עם ETR הן מגוונות, ואנו יכולים לקחת כל מאפיין אשר קיים ברמת Message Header. בהצלחה!
מאת: אלי שלמה, מומחה למערכות מיקרוסופט וענן
רוצים להתעדכן בתכנים נוספים הקשורים לאבטחת ענן? הצטרפו לפורום המקצועי של IsraelClouds בתחום > להרשמה
המאמר מתמקד בהקשחה דואר ארגוני באמצעות Exchange Transport Rule בלבד, והינו חלק מסדרת אפשרויות להקשחה באמצעות Exchange Online Protection, Office ATP והמון כלים נוספים.
ספאם, פישינג ודואר זדוני הם בעיות שהולכות ומתגברות, וככל שעובר הזמן הטכניקות של התוקפים משתפרות. למשל לאחרונה, התקפות פישינג נעשות באמצעות בוטים (או יותר Bot Phishing), אשר משלבים קישורים מבוססים HTTPS.
ביצוע הונאות באמצעות תעבורת הדואר עלול להיות מגוונות עם אפשרויות שונות. למשל: שם תצוגה זהה, שם דומיין זהה, כתובת דואר זהה ולעיתים אפשר לשלב את כולם יחדיו, ולקבל משהו ממש אמיתי.
למשל, בדוגמה המצורפת התקבל "מייל" עם שם תצוגה, כתובת מייל ובקשה מסוימת. חשוב להדגיש כי שליחת הדואר נעשתה מתוך מנגנון כולל ומוגדר עם תקנים שונים כגון Dkim.
כיום, האפשרויות בשליחת דואר מתוך מנגנון מסוים פשוטה יותר מאשר בעבר, וישנם מנגנונים ברשת המאפשרים ביצוע התחזות עם כל הפרמטרים הנדרשים.
מיותר לומר שבמקרים מסוימים ישנה השקעה מרבית בקמפיינים, וניתן לראות לעיתים דוגמאות כמו זאת המצורפת - וגם לעין טכנית קשה לזהות את ההבדל.
מנגד, ניתן לראות התעסקות רבה בהגנה על הארגון, ולעיתים רבות מדובר על גבי שילוב מספר מערכות (שתיים או שלוש כאלו) המבצעות הגנה כדוגמת Content filtering, Anti-spam וכן הגנה באמצעות חיזוי או ממוקדות, בביצוע CDR או Sandboxים למיניהם, וזאת במטרה למנוע את מתקפת הפישינג הבאה.
האם לתוקפים יש הצלחה? כן, אחוזי הצלחה גבוהים.
מהיכן הבעיה מגיעה? מעבר לעובדה שהטכניקות של התוקפים תמיד נמצאות כמה צעדים על פני המערכות שמבצעות הגנה, אפשר לומר שבגלל ריבוי המערכות, אין ניצול נכון של היכולות בכל מערכת, אם אקח את הדוגמה של Exchange Online - אפשר לומר שרוב הארגונים מנצל רק אחוז קטן מהיכולות הקיימות.
חשוב להדגיש כי בהגנה על הדואר הארגוני, אנו יכולים לצמצם טעויות אנוש ולהקטין את שטח התקיפה באופן משמעותי.
הקשחת דואר ארגוני
להקשחת דואר ארגוני אין Best Practice או Recommendation מסוימים אלא Best from the Field וזאת בגלל סיבות רבות כמו העובדה להתקפות פישינג אין חוקים, אבל כן ישנה הרבה יצירתיות ודינמיות ולכן, נתחיל בהקשחות פשוטות, ומשם נתקדם עם המאמרים לתנאים מתקדמים כולל Prediction, וכל זאת באמצעות Exchange Online או ליתר דיוק, Exchange Transport Rule.
טיפ: אפשרויות החסימה והתניה ברמת ה-ETR הן רבות ומגוונות, למשל ניתן ליצור חוק המשווה בין from לבין return-path, ועל סמך השוואה לא תקינה למרקר או לחסום את הדואר. כלומר, כל מאפיין אשר קיים ברמת Message Header זמין לנו.
התראה על דואר חיצוני עם אותו Display Name
ביצוע Spoofing והתחזות על גבי שם תצוגה עם הערך של Display Name היא בעיה נפוצה, ולכן ניתן למרקר (או לחסום) דואר מהסוג הנ"ל באמצעות ההגדרה הבאה:
• הבעיה – דואר חיצוני אשר מגיע עם אותו שם תצוגה
• מניעה – חוק מותאם לדואר חיצוני עם אותו שם מזהה מול כלל תיבות הדואר
דגשים בחוק
• הגדרת נמענים חיצונים Outside the Organization
• הגדרת ערך לבדיקה באמצעות A Message header matches של כלל תיבות הדואר
• ביצוע פעולה המבוסס על חתימה לפי Prepend the disclaimer
טיפ: מכיוון שהגדרת תיבות דואר לכלל המשתמשים אינה אפשרית באופן פשוט מתוך הממשק, ניתן להגדיר את כלל תיבות הדואר באמצעות PowerShell סקריפט אשר כולל את ערך from לפי השורה הבאה $displayNames = (Get-Mailbox -ResultSize Unlimited).DisplayName
להורדת הסקריפט המלא ExchangeOnline/DN_EXT_SPoof_EXO
טיפ: האפשרויות של הגדרת תנאים וחוקים על גבי PowerShell רחבות יותר מאשר בממשק אדמין.
לאחר הגדרת החוק ושליחת דואר עם אותו Display Name מגורם חיצוני, נקבל את ההודעה הבאה
התראה על דואר חיצוני
דואר חיצוני עלול להכיל קישורים וקבצים זדוניים, ולכן משתמשים עלולים ללחוץ או לפתוח פריטים מגורם שכזה, כתוצאה מכך, החוק הבא מדגיש (מרקור הדואר וניתן לחסום גם) האם הדואר הגיע מגורם חיצוני.
• הבעיה – דואר מגורם חיצוני
• מניעה – חוק המדגיש קבלת דואר בגורם חיצוני
דגשים בחוק
• לוודא הגדרת Message from Outside the Organization
• אפשרי להוסיף לחוק התניה של Recipient located Inside the Organization
• בהגדרת Prepend the disclaimer, מומלץ לשמור על אותו מבנה כמו בחוק הקודם, וזאת על מנת לאפשר להציג את ההודעה באותו מבנה ולא בשורה נוספת ונפרדת
חסימת דואר עם דומיין זהה (Domain Look-Alike)
במקרים של טירגוט, התוקף שולח דואר עם דומיין אשר זהה לדומיין שלנו בכדי לבצע סוג של Impersonation ולכן במקרים כאלה ניתן לראות כי גם שם התצוגה וגם שם הדומיין הם זהים באופן שווה לנמען הפנימי.
החוק הבא חוסם קבלת דואר מגורם חיצוני עם שם דומיין זהה.
• הבעיה – דואר מגורם חיצוני עם אותו Domain Name
• מניעה – חסימת קבלת דואר מגורם חיצוני
דגשים בחוק
• הגדרת התניה של Sender is outside the Organization
• התניה עם Recipient is Inside the Organization
• חשוב מאוד The Sender domain is עם שם הדומיין הייעודי של הארגון
• ביצוע הפעולה יכול מגוון פעולות, ובדוגמה הבאה בחרתי באפשרות Generate Incident
טיפ: ביצוע האכיפה יכול להיות פעולה אחרת, אך מומלץ לא להגדיר במצב כזה אכיפה עם חתימה והתראה במייל אלא לחסום.
לסיכום
הפעולות והדרכים להגדרת תנאים וחוקים על גבי ETR, מאפשרים למרקר הודעות דואר מסוימות ולחסום מקרים אחרים, ואנו יכולים לשלוט על כל תעבורת הדואר בהתאם לערכים והפרמטרים המוצעים על גבי Exchange Online.
האפשרויות עם ETR הן מגוונות, ואנו יכולים לקחת כל מאפיין אשר קיים ברמת Message Header. בהצלחה!
מאת: אלי שלמה, מומחה למערכות מיקרוסופט וענן
רוצים להתעדכן בתכנים נוספים הקשורים לאבטחת ענן? הצטרפו לפורום המקצועי של IsraelClouds בתחום > להרשמה
לפרטים נוספים ויצירת קשר עם נציג אורקל
הודעתך לא התקבלה - נסה שוב מאוחר יותר
