מישהו יכול לשלוח כרגע מייל שנראה כאילו הגיע מהדומיין שלכם. לא דומיין דומה, לא שם תצוגה מזויף - הדומיין האמיתי שלכם, בשורת הכתובת בתיבה של הלקוח. אלא אם שלוש רשומות DNS קיימות ואוכפות, שום דבר באינטרנט לא עוצר אותו.
שלוש הרשומות האלה הן SPF, DKIM ו-DMARC. הן הסיבה שהונאת דואר עסקי מצליחה מול חברות מסוימות ונכשלת מול אחרות, והן לא עולות כסף אלא תשומת לב.
למה זה חשוב יותר מבעבר
הונאת דואר עסקי נשארת אחת מקטגוריות ההפסד הגבוהות ביותר בדיווחים ל-FBI, והמנגנון הוא התחזות ולא תוכנה זדונית[1]. הגורם האנושי מופיע ברוב הפריצות, והודעה שמאומתת כדומיין שלכם זוכה להרבה יותר אמון מהודעה שלא[2].
גם ספקי הדואר הפסיקו להתייחס לזה כרשות. Google דורשת אימות מכל מי ששולח ל-Gmail בנפח, כולל מדיניות DMARC מפורסמת לשולחים גדולים[3]. דואר לא מאומת פשוט לא מגיע יותר ויותר, וכך בקרת אבטחה הופכת גם לבקרת מסירה.
שלוש הרשומות, בשפה פשוטה
SPF מפרטת אילו שרתים רשאים לשלוח דואר בשם הדומיין שלכם. השרת המקבל בודק את כתובת ה-IP מול הרשימה המפורסמת[4]. זו רשימת אורחים.
DKIM מוסיפה חתימה קריפטוגרפית לכל הודעה ומפרסמת את המפתח הציבורי ב-DNS, כך שהמקבל יכול לאמת שההודעה לא שונתה ושהיא באמת יצאה מפלטפורמת הדואר שלכם[5]. זו חותמת שעווה.
DMARC מחברת בין השתיים. היא אומרת למקבלים מה לעשות כשהודעה נכשלת - כלום, הסגר או דחייה - ולאן לשלוח דוחות על מי שולח בשמכם[6]. זו ההוראה לשומר בכניסה.
SPF ו-DKIM בלי DMARC הם המצב החצי-גמור הנפוץ: הבדיקות רצות, התוצאה נזרקת, ואיש לא רואה את הדוחות.
סדר ההטמעה
סדר ההטמעה
ימי עבודה שחלפו
ציר זמן של הטמעת DMARC על פני כשמונה שבועות: מיפוי שולחים בשבוע 1, SPF ו-DKIM בשבועות 1-2, DMARC ב-p=none בשבוע 2, ארבעה שבועות ניטור והרשאה, ואז הסגר בשבוע 6 ודחייה בשבוע 8. תקופת הניטור היא העמודה הארוכה ביותר.
1
מפו כל מערכת ששולחת בשמכםשבוע 1
הנהלת חשבונות, CRM, דיוור, הזמנות, חתימה דיגיטלית, מערכת קריאות
2
פרסמו SPF והפעילו DKIM לדומיין שלכםשבועות 1-2
שימו לב למגבלת 10 השאילתות של SPF במערכי רב-ספקים
3
פרסמו DMARC ב-p=none עם כתובת לדוחותשבוע 2
4
קראו את הדוחות המצטברים והרשו את השולחים שפספסתםשבועות 2-6
השלב שקובע אם האכיפה תשבור משהו
5
עברו ל-p=quarantineשבוע 6
6
עברו ל-p=rejectשבוע 8
כמעט כל הזמן שחולף הוא תקופת הניטור, לא עבודת ה-DNS.
הטמעה של TechSuit, מדורגת לפי הנחיית NCSC
הסדר אינו נתון למשא ומתן. פרסום `p=reject` לפני שיודעים אילו מערכות לגיטימיות שולחות בשמכם הוא הדרך שבה חברה מפסיקה לקבל את החשבוניות שלה, את התראות ה-CRM ואת אישורי ההזמנות באותו אחר צהריים. ההנחיה של NCSC מציגה את אותה התקדמות מדורגת, ותקופת הניטור היא החלק שמדלגים עליו[7].
מה בדרך כלל נשבר
1שולחים נשכחים. מערכת הנהלת החשבונות, כלי הדיוור, מערכת ההזמנות וספק החתימה הדיגיטלית כולם שולחים בשמכם. כל אחד צריך הרשאה, ולרשומת SPF יש תקרה קשיחה של 10 שאילתות DNS, שמערכי רב-ספקים חוצים בקלות[4].
2יישור (alignment). הודעה יכולה לעבור SPF ועדיין להיכשל ב-DMARC אם הדומיין שעבר אינו הדומיין שהקורא רואה. יישור הוא מה ש-DMARC באמת בודקת, ולכן "SPF ירוק" אינו תשובה[6].
3העברות. רשימות תפוצה וכללי העברה אוטומטית שוברים SPF מעצם תכנונם. DKIM שורדת העברה, ולכן צריך את שתי הרשומות ולא אחת.
4אף אחד לא קורא את הדוחות. דוחות DMARC מגיעים כ-XML. בלי מפענח או שירות שקורא אותם, שלב הניטור לא מייצר דבר וההטמעה נתקעת ב-`p=none` לשנים.
איך עושים את זה ב-Microsoft 365
מיקרוסופט חותמת דואר יוצא בתצורת DKIM ברירת מחדל, אך ההנחיה המפורסמת היא להפעיל DKIM עבור הדומיין שלכם כדי שהחתימה תתיישר עם הדומיין שהנמענים רואים[8]. זה שינוי של שתי רשומות CNAME ומתג בפורטל האבטחה.
SPF היא רשומת TXT אחת שמציינת את תשתית השליחה של מיקרוסופט ואת השולחים החיצוניים. DMARC היא רשומת TXT נוספת ב-`_dmarc.yourdomain.com`, שמתחילה ב-`p=none` עם כתובת לדוחות.
שום דבר מזה אינו פרויקט. הוא דורש רשימה מלאה של מי שולח בשמכם, וזה החלק שלוקח זמן.
מה זה לא עושה
אימות דואר עוצר התחזות לדומיין *שלכם*. הוא לא עושה דבר מול דומיין דומה, מול תיבה שנפרצה ושולחת הונאה מאומתת לחלוטין, או מול ספק שהחשבון שלו נחטף. לאלה צריך MFA, גישה מותנית ותהליך אימות לשינוי פרטי תשלום - בקרות נפרדות שנכשלות בנפרד[1].
הערות לפי מדינה
ישראל. רוב העסקים הקטנים כאן מריצים Microsoft 365 או Google Workspace עם דומיין שנרשם דרך משווק מקומי, וה-DNS מוחזק פעמים רבות אצל הרשם ולא אצל ספק הדואר. ודאו מי רשאי לערוך את האזור לפני שמתכננים שינוי.
אירופה. סעיף 21 ב-NIS2 מונה אמצעי ניהול סיכונים הכוללים היגיינת סייבר בסיסית; מדיניות DMARC מפורסמת היא אחת הראיות הזולות ביותר שאפשר להציג לכך[9].
ספרד. משפחות הבקרה של ENS מתייחסות במפורש להגנה על דואר אלקטרוני, ורשומות האימות הן היישום הקונקרטי של הבקרה הזו ולא תוספת נחמדה.
מה לעשות עם זה
1בדקו מה אתם מפרסמים היום. שאילתת DNS אחת לרשומות ה-TXT של הדומיין אומרת אם SPF ו-DMARC קיימות ומה המדיניות.
2רשמו כל מערכת ששולחת דואר בשמכם, כולל אלה שהשיווק הקים בלי לספר ל-IT.
3פרסמו DMARC ב-`p=none` עם כתובת לדוחות, ובאמת קראו את הדוחות כמה שבועות.
4עברו ל-`p=quarantine` ואז ל-`p=reject` ברגע שהדוחות מציגים רק מקורות שאתם מזהים.
שאלות שאנחנו נשאלים
מקורות
כל נתון במאמר הזה מוביל למקור בעל שם. במקומות שבהם אנחנו מצטטים מספרים שלנו, הם מגיעים מעבודה שעשינו עם עסקים קטנים בישראל וברחבי אירופה - ואנחנו אומרים זאת במפורש.
