משחק מודעות לפישינג

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

← חזרה לפורטפוליו
הניקוד הטוב ביותר: 0הרצף הטוב ביותר: 0סיבובים: 0

הדרכת אבטחת אימייל

הערות קצרות וברורות על SPF, DKIM, DMARC, CompAuth, ARC, DNSSEC, MX, יציאות SMTP, STARTTLS, EHLO, SEG ויסודות אימות אימייל קשורים.

אימות ואמון

SPF (Sender Policy Framework)

SPF הוא רשימת DNS של שרתים שמותר להם לשלוח דואר עבור דומיין.

  1. המקלט בודק את כתובת ה-IP השולחת מול הרשימה ומקבל תוצאה בסגנון pass או fail.
  2. SPF לא מגן על שם ה-From שרואים המשתמשים. השתמשו בו עם DMARC.
  3. שמרו על הרשומה פשוטה. יותר מדי חיפושי DNS עלולים לשבור את הבדיקה.

DKIM (DomainKeys Identified Mail)

DKIM הוא חתימה דיגיטלית שמוכיחה שדומיין חתם על ההודעה ושהיא לא שונתה בדרך.

  1. השולח חותם על חלקים מהמייל. המקלט בודק מפתח ציבורי ב-DNS.
  2. חתימה תקפה בונה אמון בדומיין החותם. היא לא מוכיחה לבדה ששדה ה-From הגלוי כן.
  3. סובבו מפתחות וחתמו על כותרות חשובות כמו From ו-Subject.

DMARC (Domain-based Message Authentication, Reporting and Conformance)

DMARC בודק ש-SPF או DKIM מתיישרים עם דומיין ה-From שרואים, ואז אומר מה לעשות בכשל.

  1. מדיניות יכולה לנטר (none), להעביר להסגר או לדחות דואר שנכשל.
  2. דוחות עוזרים לזהות זיופים וטעויות הגדרה.
  3. DMARC הוא מה שעוצר זיוף דומיין ישיר בפישינג וב-BEC.

BIMI (Brand Indicators for Message Identification)

BIMI יכול להציג לוגו מותג בתיבות תומכות כש-DMARC חזק.

  1. צריך DMARC באכיפה ועוד רשומת BIMI ב-DNS שמצביעה על לוגו.
  2. חלק מהספקים דורשים גם תעודת סימן מאומת.
  3. BIMI הוא תג אמון. הוא לא מחליף SPF, DKIM או DMARC.

CompAuth (Microsoft composite authentication)

CompAuth הוא ציון האותנטיות הכולל של Microsoft להודעה ב-Exchange Online.

  1. תראו אותו ב-Authentication-Results יחד עם SPF, DKIM ו-DMARC.
  2. הוא שוקל יותר מאות אחד, כולל מוניטין ויישור.
  3. בבדיקת פישינג ב-Microsoft 365 קראו CompAuth עם שאר תוצאות האימות.

ARC (Authenticated Received Chain)

ARC שומר תוצאות אימות קודמות כשהדואר מועבר או משוכתב באמצע הדרך.

  1. רשימות ושערים לעיתים שוברים DKIM כשהם משנים הודעה.
  2. ARC חותם על מה שהקפיצה הקודמת כבר בדקה.
  3. זה עוזר לדואר מועבר לגיטימי. זה לא אישור חופשי לזיוף.

DNSSEC (DNS Security Extensions)

DNSSEC חותם על תשובות DNS כדי שיהיה קשה יותר להחדיר רשומות מזויפות.

  1. DNS מזויף יכול להפנות דואר או לזייף רשומות SPF ו-DKIM.
  2. אימות אימייל תלוי ב-DNS אמין. DNSSEC מחזק את הבסיס הזה.
  3. צריך לפרסם רשומות ולוודא שה-resolvers באמת מאמתים.

MTA-STS (SMTP MTA Strict Transport Security)

MTA-STS אומר לשולחים להשתמש ב-TLS לדואר נכנס ולסרב להורדה לטקסט גלוי.

  1. מפרסמים סמן ב-DNS וקובץ מדיניות קצר ב-HTTPS.
  2. שולחים תומכים אוכפים TLS למארחי ה-MX שלכם.
  3. שמרו על תעודות MX תקינות כדי שהאכיפה לא תיצור השבתות.

DANE / TLSA

DANE קושר את תעודת ה-TLS הצפויה ל-SMTP ל-DNS באמצעות רשומות TLSA.

  1. נדרש DNSSEC. בלי DNSSEC מאומת אי אפשר לסמוך על TLSA.
  2. כשנתמך, זה מחזק TLS של SMTP מעבר לתעודות ווב רגילות.
  3. צוותים רבים משתמשים ב-MTA-STS כאפשרות אכיפת TLS פשוטה יותר.

SMTP ותעבורה

SMTP (Simple Mail Transfer Protocol)

SMTP הוא הפרוטוקול ששרתים משתמשים בו כדי להעביר אימייל ברשת.

  1. בדרך כלל המייל עובר מהלקוח לשרת שליחה, אחר כך מקפיצה לקפיצה, ואז לתיבה.
  2. היום הנתיב מסונן ובדרך כלל מוצפן ב-TLS.
  3. הבנת הקפיצות עוזרת לקרוא כותרות Received בבדיקת פישינג.

יציאות SMTP (25, 465, 587, 2525)

יציאות SMTP שונות משמשות למשימות שונות: ממסר בין שרתים מול שליחת משתמש.

  1. יציאה 25 היא מסירה בין שרתים.
  2. יציאה 587 היא יציאת השליחה המאומתת הרגילה. יציאה 465 מצפינה מההתחלה.
  3. יציאה 2525 היא גיבוי נפוץ כש-587 חסומה. עקבו אחרי הנחיות הספק.

STARTTLS מול TLS מובנה

STARTTLS משדרג הפעלת SMTP פשוטה להצפנה. TLS מובנה מצפין מיד בחיבור.

  1. STARTTLS מתחיל בגלוי ואז עובר אחרי EHLO.
  2. בלי מדיניות כמו MTA-STS או DANE, תוקף עלול לנסות להסיר STARTTLS.
  3. תמיד בדקו תעודות. הצפנה לבדה לא מוכיחה שהגעתם לשרת האמיתי.

EHLO ו-HELO

EHLO ו-HELO הם פקודות שלום ב-SMTP. EHLO גם מציג מה השרת תומך.

  1. לקוחות מודרניים צריכים להשתמש ב-EHLO.
  2. אחרי STARTTLS הלקוחות בדרך כלל שולחים EHLO שוב.
  3. ברכות מוזרות הן רמז חלש. קל לזייף אותן, אז אל תסמכו עליהן לבד.

MAIL FROM מול כותרת From

MAIL FROM הוא שולח המעטפה לבounced ו-SPF. From הוא מה שהמשתמשים רואים.

  1. שניהם יכולים להיות שונים גם במערכות אמיתיות וגם בפישינג.
  2. SPF בודק את המעטפה. DMARC בודק יישור מול דומיין ה-From הגלוי.
  3. למדו אנשים להסתכל מעבר לשם התצוגה אל הכתובת האמיתית.

VRFY ו-EXPN

VRFY שואל אם כתובת קיימת. EXPN מרחיב רשימת תפוצה. שניהם עוזרים לתוקפים לאסוף כתובות.

  1. השאירו אותם כבויים בשרתי דואר הפונים לאינטרנט.
  2. אם VRFY פתוח לעולם, טפלו בזה כממצא חיזוק.

Bounces ו-NDRs

Bounce או NDR אומר שהמסירה נכשלה. תוקפים גם מזייפים הודעות כשל כדי לפתות ללחיצה.

  1. שולחי מעטפה מזויפים יכולים להציף דומיינים תמימים ב-bounce spam.
  2. SPF ו-DMARC מצמצמים את הרעש הזה.
  3. התייחסו לדואר "delivery failed" עם קישורים כחשוד.

DNS וניתוב

MX (Mail Exchanger)

רשומות MX אומרות אילו שרתים מקבלים דואר לדומיין ובאיזה סדר.

  1. שולחים מחפשים MX ואז מתחברים למארחים האלה.
  2. גם MX גיבוי צריך סינון, אחרת הוא מושך ספאם.
  3. דומיין חדש עם MX חלש ובלי אימות יכול להיות רמז לטריאז', לא הוכחה לבדה.

רשומות A ו-AAAA

רשומות A ו-AAAA ממפות שמות מארח לכתובות IPv4 ו-IPv6.

  1. שמות MX חייבים להיפתר לכתובות לפני שאפשר להתחבר.
  2. שינוי כתובת דורש גם עדכון חומת אש, תעודה ו-SPF.
  3. IP שולח חשוד בכותרות Received שווה בדיקת מוניטין.

PTR / DNS הפוך (rDNS)

PTR ממפה IP חזרה לשם מארח. מקלטים רבים מצפים ל-rDNS נקי ב-SMTP.

  1. rDNS חסר או מבולגן עלול לפגוע במוניטין משלוח.
  2. זו היגיינה תפעולית, לא בקרה קריפטוגרפית כמו DKIM.

רשומות TXT לאימות אימייל

רשומות DNS TXT מחזיקות SPF, DMARC, מפתחות DKIM, BIMI, סמני MTA-STS ומדיניות דומה.

  1. DMARC נמצא ב-_dmarc.example.com. מפתחות DKIM תחת selector._domainkey.
  2. הגנו על חשבון ה-DNS. include ישנים ב-SPF גורמים לעיתים לכשלי אימות פתאומיים.

ערימת אבטחת אימייל

SEG (Secure Email Gateway)

SEG מסנן דואר מפני ספאם, פישינג, נוזקות ודליפת מידע לפני שההודעות מגיעות לתיבה.

  1. הוא יכול לשבת על MX או כמסנן ענן מול Microsoft 365 או Google Workspace.
  2. כלים נפוצים: שכתוב URL, ארגז חול לקבצים, ומודלי פישינג מבוססי AI.
  3. הדרכה יחד עם SEG עובדת טוב יותר מכל אחד לבד.

MTA (Mail Transfer Agent)

MTA הוא תוכנה שממסרת אימייל בין שרתים.

  1. דוגמאות: Postfix, Exim, Exchange Transport וממסרי ענן.
  2. MTA הפונה לאינטרנט חייב לחסום open relay ולהגן על התחברות לשליחה.

MSA (Mail Submission Agent)

MSA מקבל דואר מאפליקציות משתמש אחרי התחברות, בדרך כלל ביציאה 587.

  1. דרשו אימות חזק, TLS ומגבלות קצב כדי שחשבונות גנובים לא ישלחו ספאם בחופשיות.
  2. הפרידו שליחה מ-MX נכנס כשאפשר.

MDA (Mail Delivery Agent)

MDA מניח דואר שהתקבל בתיבה הסופית.

  1. זו הקפיצה האחרונה לתיבה, הסגר או ארכיון.
  2. באירועים התאימו יומני מסירה לפסקי SEG ולתוצאות אימות.

Journaling וארכוב

Journaling מעתיק דואר לארכיון תאימות לשמירה ולחיפוש משפטי.

  1. משתמשים לעיתים לא רואים את עותק ה-journal.
  2. נעלו ארכיונים היטב. יש בהם דואר עסקי רגיש וראיות פישינג.

פישינג מול זיוף מול BEC

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

  1. פישינג משתמש בקישורים, קבצים או מסכי התחברות מטעים.
  2. זיוף מזייף From או שמות תצוגה. DMARC חוסם זיופי דומיין ישירים רבים.
  3. BEC לעיתים מגיע מתיבה אמיתית שנפרצה, ולכן אימות עדיין יכול לעבור.

כותרות ופורנזיקה

Authentication-Results

Authentication-Results מתעד SPF, DKIM, DMARC, ARC ולעיתים CompAuth בגבול הקבלה.

  1. סמכו על תוצאות רק מהקצה שלכם או מקפיצה שאתם שולטים בה.
  2. תוקפים יכולים להוסיף כותרות אימות מזויפות מוקדם יותר בשרשרת.
  3. בדקו את authserv-id כדי לראות מי קבע את התוצאה.

שרשרת כותרות Received

כל קפיצת שרת מוסיפה שורת Received. החדשה ביותר בדרך כלל למעלה.

  1. התחילו מהקצה המהימן שלכם. שורות נמוכות יותר עלולות להיות מזויפות.
  2. שימו לב ל-IP, שמות מארח, הערות TLS ועיכובים מוזרים.
  3. השוו IP חשודים מול SPF ונתוני מוניטין.

Reply-To מול From

Reply-To קובע לאן יגיעו תשובות. From הוא הזהות שמוצגת בתיבה.

  1. פישרים לעיתים מתחזים למותג ב-From ואוספים תשובות במקום אחר.
  2. From מהימן עם Reply-To מדומיין לא קשור דורש מבט שני.
  3. גם מערכות כרטוס אמיתיות משתמשות ב-Reply-To. ההקשר חשוב.

Message-ID

Message-ID הוא מזהה ייחודי להודעה אחת. צוותים משתמשים בו לחיבור יומנים בין מערכות.

  1. תעדו אותו מוקדם באירוע.
  2. מזהים חסרים או מוזרים הם רמז חלש. הם לא הוכחה לבדם.