Zimbra מקבל דואר מהאינטרנט: מי בודק את השרת לפני שהתקלה מגיעה לתיבה?

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

ב-21 באוגוסט 2026 הופיעה בקטלוג החולשות המנוצלות של CISA חולשת הזרקת פקודות ב-Zimbra Collaboration Suite. לפי התיאור שפורסם, תוקף שאינו מזוהה עלול לשלוח בקשות SMTP שהוכנו במיוחד ולהריץ פקודות במערכת. SMTP הוא הפרוטוקול שמעביר דואר בין שרתים. מבחינת עסק קטן, זה אומר שרכיב שחייב לדבר עם העולם עלול לדרוש תגובה מהירה, בלי הכפתור הנוח של "ננתק אותו עד מחר".

קודם מבררים אם Zimbra בכלל נמצא בתמונה

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

בקשו מספק ה-IT תשובה כתובה לארבע שאלות:

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

אל תסתפקו בתשובה "הכול בענן". ענן הוא מקום אירוח, לא שם של אחראי. לפעמים השרת הראשי עודכן, אבל שרת מעבר שנשכח ממשיך לקבל SMTP כאילו השנה עדיין 2019.

בודקים חשיפה לפני שנוגעים במערכת

המקור הראשון לבדיקה הוא קטלוג Known Exploited Vulnerabilities של CISA, שמרכז חולשות שיש לגביהן עדות לניצול. פרטי החולשה הספציפית זמינים גם ב-רשומת CVE-2026-73570 ב-NVD. שני הקישורים עוזרים לזהות את המוצר והסיכון, אך את הוראות התיקון והגרסאות הרלוונטיות צריך לאמת מול הודעת היצרן וספק התחזוקה לפני שינוי.

כעת בונים תמונת מצב קצרה:

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

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

עדכון אבטחה בלי לאבד את יום העבודה

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

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

לאחר העדכון בודקים בפועל:

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

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

הדואר הוא גם תהליך עסקי

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

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

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

שאלות נפוצות

האם כל עסק שמשתמש ב-Outlook מפעיל Zimbra

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

האם התקנת העדכון מספיקה

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

האם אפשר פשוט לחסום SMTP מהאינטרנט

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

מה מבקשים מספק ה-IT עוד היום

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

אם אין לכם תמונה ברורה של שרת הדואר, לימי פתרונות מחשוב יכולה לסייע במיפוי החשיפה, בתכנון עדכון ובבדיקות לאחר הטיפול. אפשר ליצור קשר בטלפון 0542395928 או במייל gallev@limitech.co.il.