הגנה מפני הפצצות זימברה ודואר

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

תכונה חשובה של מתקפת סייבר זו היא שכמעט בלתי אפשרי להשתמש בה למטרות רווח. ובכן, התוקף שלח גל של מיילים לאחת מתיבות הדואר, ובכן, הוא לא אפשר לאדם להשתמש בדוא"ל כרגיל, ובכן, התוקף פרץ למייל הארגוני של מישהו והחל לשלוח אלפי מכתבים ברחבי ה-GAL, כלומר מדוע השרת קרס או התחיל להאט כך שהפך בלתי אפשרי להשתמש בו, ומה הלאה? כמעט בלתי אפשרי להמיר פשע סייבר כזה לכסף אמיתי, אז פשוט הפצצת דואר היא כיום אירוע די נדיר ומנהלי מערכת, בעת תכנון תשתית, עשויים פשוט לא לזכור את הצורך בהגנה מפני מתקפת סייבר כזו.

עם זאת, בעוד שהפצצת דואר אלקטרוני בעצמה היא תרגיל די חסר טעם מנקודת מבט מסחרית, היא לרוב חלק ממתקפות סייבר אחרות, מורכבות יותר ורב-שלביות. לדוגמה, כאשר פורצים דואר ומשתמשים בו כדי לחטוף חשבון בשירות ציבורי כלשהו, ​​תוקפים לעתים קרובות "מפציצים" את תיבת הדואר של הקורבן עם מכתבים חסרי משמעות, כך שמכתב האישור הולך לאיבוד בזרם שלהם ולא מורגש. הפצצת דואר יכולה לשמש גם כאמצעי ללחץ כלכלי על מיזם. לפיכך, הפצצה אקטיבית של תיבת דואר ציבורית של מיזם, המקבלת פניות מלקוחות, עלולה לסבך את העבודה מולם בצורה רצינית, וכתוצאה מכך להוביל להשבתת ציוד, הזמנות שלא מומשו, כמו גם אובדן מוניטין ואובדן רווחים.

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

Zimbra מבוססת על Postfix, אחד מסוכני העברת הדואר הפתוח האמינים והפונקציונליים ביותר הקיימים כיום. ואחד היתרונות העיקריים של הפתיחות שלו הוא שהוא תומך במגוון רחב של פתרונות צד שלישי להרחבת הפונקציונליות. בפרט, Postfix תומך באופן מלא ב-cbpolicyd, כלי עזר מתקדם להבטחת אבטחת סייבר של שרת הדואר. בנוסף להגנה נגד דואר זבל ויצירת רשימות הלבנות, רשימות שחורות ורשימות אפורות, cbpolicyd מאפשרת למנהל Zimbra להגדיר אימות חתימת SPF, כמו גם להגדיר הגבלות על קבלה ושליחה של מיילים או נתונים. הן יכולות לספק הגנה אמינה מפני דואר זבל ודיוג, והן להגן על השרת מפני הפצצות דוא"ל.

הדבר הראשון שנדרש ממנהל המערכת הוא להפעיל את מודול cbpolicyd, המותקן מראש ב-Zimbra Collaboration Suite OSE בשרת MTA התשתית. זה נעשה באמצעות הפקודה zmprov ms `zmhostname` +zimbraServiceEnabled cbpolicyd. לאחר מכן, תצטרך להפעיל את ממשק האינטרנט על מנת שתוכל לנהל בנוחות את cbpolicyd. לשם כך, עליך לאפשר חיבורים ביציאת אינטרנט מספר 7780, צור קישור סמלי באמצעות הפקודה ln -s /opt/zimbra/common/share/webui /opt/zimbra/data/httpd/htdocs/webui, ולאחר מכן ערוך את קובץ ההגדרות באמצעות הפקודה nano /opt/zimbra/data/httpd/htdocs/webui/includes/config.php, שבו עליך לכתוב את השורות הבאות:

$DB_DSN="sqlite:/opt/zimbra/data/cbpolicyd/db/cbpolicyd.sqlitedb";
$DB_USER="root";
$DB_TABLE_PREFIX="";

לאחר מכן, כל מה שנותר הוא להפעיל מחדש את שירותי Zimbra ו-Zimbra Apache באמצעות הפקודות zmcontrol restart ו-zmapachectl restart. לאחר מכן, תהיה לך גישה לממשק האינטרנט בכתובת example.com:7780/webui/index.php. הניואנס העיקרי הוא שהכניסה לממשק האינטרנט הזה עדיין לא מוגנת בשום אופן וכדי למנוע מאנשים לא מורשים להיכנס אליו, ניתן פשוט לסגור חיבורים בפורט 7780 לאחר כל כניסה לממשק האינטרנט.

אתה יכול להגן על עצמך מפני מבול המיילים המגיעים מהרשת הפנימית על ידי שימוש במכסות לשליחת מיילים, שניתן להגדיר הודות ל-cbpolicyd. מכסות כאלה מאפשרות להגביל את המספר המרבי של מכתבים שניתן לשלוח מתיבת דואר אחת ביחידת זמן אחת. לדוגמה, אם מנהלי העסק שלך שולחים בממוצע 60-80 מיילים לשעה, אז אתה יכול להגדיר מכסה של 100 מיילים לשעה, תוך התחשבות במרווח קטן. על מנת להגיע למכסה זו, מנהלים יצטרכו לשלוח מייל אחד כל 36 שניות. מצד אחד, זה מספיק כדי לעבוד בצורה מלאה, ומצד שני, עם מכסה כזו, תוקפים שקיבלו גישה לדואר של אחד המנהלים שלך לא יפתחו בהפצצת דואר או מתקפת ספאם מאסיבית על הארגון.

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

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

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

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

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

אתה יכול גם להפעיל רישום אפור בממשק האינטרנט cbpolicyd. כדי שהכל יעבוד, עליך ליצור מדיניות שתכלול את כל המכתבים הנכנסים הממוענים למשתמשים בשרת שלנו, ולאחר מכן, בהתבסס על מדיניות זו, ליצור כלל Greylisting, שבו תוכל להגדיר את המרווח שבמהלכו cbpolicyd ימתין לתגובה חוזרת משולח אדם לא ידוע. בדרך כלל זה 4-5 דקות. יחד עם זאת, ניתן להגדיר רשימות אפורות כך שכל הניסיונות המוצלחים והלא מוצלחים להעברת מכתבים משולחים שונים יילקחו בחשבון ועל סמך מספרם מתקבלת החלטה להוסיף את השולח באופן אוטומטי לרשימה הלבנה או השחורה.

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

בנוסף, הוספת בדיקות SPF, DMARC ו-DKIM יכולה לסייע בהגנה מפני הפצצות דוא"ל. לעתים קרובות מכתבים המגיעים בתהליך של הפצצת דואר אינם עוברים בדיקות כאלה. דנו כיצד לעשות זאת באחד מהמאמרים הקודמים שלנו.

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

מקור: www.habr.com