מערך הסייבר הלאומי: יום ירושלים האיראני (OpJerusalem) - המלצות להתגוננות
מאת: מערכת Telecom News, 28.4.21, 15:30

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

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

שיטות פעולה רווחות באירועים מסוג זה:

התקפות מניעת שירות (DoS/DDoS).
חדירה למאגרי נתונים והדלפת מידע.
הדבקה בנוזקות כופרה (Ransomware).
השחתת אתרי אינטרנט (Defacement).
פריצה לשרתי ארגונים וחברות.
 
כתבה זו מפרטת המלצות הגנה לשם הערכות לקראת קמפיין OpJerusalem והעלאת חוסן הגופים מפני איומי סייבר. חלק מההמלצות הן טכניות, לכן מומלץ לפנות לגורם מקצועי ומוסמך, שיוכל לסייע בהטמעתן.
 
המלצות להתגוננות:
נורמות והתנהגות
העלאת מודעות בקרב עובדים ולקוחות בנוגע לקמפיין.
העלאת מודעות בקרב עובדים בנוגע לניצול של תוקפים את משבר נגיף הקורונה.
ריענון התכנית הארגונית להתאוששות מאירוע סייבר.
שיתוף מידע והתעדכנות שוטפת באמצעות מערכת סייברנט.
 
גיבוי ויכולת התאוששות
גיבוי יומיומי של מידע בעל חשיבות, כגון אתר האינטרנט, בסיסי נתונים, קבצים אישיים חשובים וכיו"ב. את הגיבוי יש לבצע במדיה נפרדת, שאינה מחוברת באופן שוטף למחשב או לשרת המגובה.
הגדרת המיקום בו יבוצע הגיבוי: דיסק חיצוני נייד אותו יש לנתק לאחר הגיבוי ולשמור במיקום נפרד ומאובטח, שרת גיבוי או אחסון מבוסס ענן. במקרה זה חשוב לוודא, ששירות הענן מספק הצפנת נתונים ואימות דו שלבי.
ככלל, מומלץ לבצע גיבוי במספר ערוצים במקביל: שרותי ענן, DoK, קלטות גיבוי וכד'.
גיבוי תצורה לרכיבי תשתית ותקשורת, כגון נתבים, FW, מערכות אבטחה ועוד.
 
הגנה מפני תקיפת DDoS/DoS על אתר האינטרנט
הגדרת מערכת ה-WAF להפעלת Bot Mitigation, זיהוי חתימה ייחודית של התקיפה, חסימתה וכד'.
בהעדר יכולת ארגונית מתאימה, מומלץ לבחון שימוש בשירותים מנוהלים כגון WAF ו-Anti DDoS ע"י ספקית התקשורת.
בחינת האפשרות לביצוע פעולות כגון:
חסימת תעבורה ממדינות בעלות פוטנציאל סיכון (על בסיסGeo Location).
במקרים חריגים של תקיפה מחו"ל - חסימה גורפת של פניות מחו"ל.
חסימה ב-FireWall של כתובות הידועות כבעלות מוניטין בעייתי או עוין (על בסיס IP Reputation).
זיהוי וחסימת כתובות של שירותים כגון TOR או Anonymizer המאפשרים גלישה אנונימית.
העברת האתר לענן במידת הצורך.
 
הגנה מפני השחתת אתר
עדכון גרסת CMS (Content Management Systems) כגון WordPress, Drupal ,Joomla וכד', ובפרט גרסות של תוספים (Plugins) בהם מצויות רוב החולשות.
הקשחת חיבור ל-CMS, אך ורק באמצעות חיבור TLS מאובטח והזדהות באמצעות שני אמצעי זיהוי (2FA).
הגבלת גישה לשרת ומערכת ניהול התוכן למספר כתובות ה-IP המינימליות הנדרשות.
בדיקת תקינותם של שדות הקלט באתר, ווידוא כי אינם מאפשרים הכנסת תווים שאינם נדרשים או תואמים את הערכים הצפויים.
הפעלת ניטור אבטחתי ללוגים על שרת ה-Web, לאיתור פניות חריגות וזיהוי תקיפות בדיעבד. כ"כ, הפעלת ניטור לוגים במערכת ההפעלה לאיתור וזיהוי פעילות חריגה.
הקשחת חוקי ה-FireWall והגבלת גישה בפרוטוקולים לגיטימיים בלבד.
במידת האפשר, ביצוע סריקת אבטחה לאיתור פעילות זדונית של גורמים חיצוניים, כגון Waterhole.
הכנת דף אינטרנט חלופי, שישמש להחלפת האתר נתקף בעת הצורך.
בחינת האפשרות לבצע ניתוב תעבורה דרך מסננים מובנים של חברת האחסון או ספקית התקשורת.
הגבלת שימוש PowerShell כמפורט בקישור.
הגבלת שימוש בהרשאות Local admin היכן שאין הכרח בהן.
 
מניעת התחזות לבעל דומיין ו"חטיפת" אתר
בדיקה מול ספקיות שרותי ה-DNS, כי ממשק העבודה מולן מוגן ע"י מנגנון אימות דו-שלבי. כ"כ, יש לדרוש מהן, שכל שינוי ב-Domain (שם המתחם), יחייב אישור פורמאלי ממנהל ה-Domain בארגון. לשם כך יש לוודא, שפרטיו העדכניים שמורים מראש במאגרי המידע של הספקית.
ע"מ למנוע התחזות מול הרשמים ( (Registrars, מומלץ לדרוש מהם לבצע פעולת Lock על ה-Domain. כך, שרק מנהל ה-Domain יוכל לבצע שינויים. כ"כ, יש למסד מנגנון אימות דו-שלבי גם מול הרשמים.
הטמעת טכנולוגית DNSSEC, דרך רשם כתובות המתחם (Registrar Domain). במקרה זה יש לבקש מהרשם כי תעבורת ה-DNS עבור כתובות בסיומת IL תתבצע תוך שימוש ב- DNSSEC. טכנולוגית ה-DNSSEC מאפשרת לשרת ה-DNS מולו עובד הארגון לוודא, שהתשובה אותה הוא מספק למשתמש אודות כתובת ה-IP של האתר או השירות אליו מבוצעת הגלישה, היא הכתובת הנכונה.
 
צמצום החשיפה לזליגת מידע ממאגרי נתונים
יישום תהליכי Tokenization באופן שיצמצם את כפילויות הנתונים במספר מסדי נתונים שונים.
הצפנת נתונים רגישים במסדי הנתונים.
יישום בקרות ואיתור אנומליות במסדי הנתונים הקיימים.
יישום מדיניות גישה מחמירה למסדי הנתונים הכוללת בין היתר:
הגבלת שימוש בחשבונות אדמיניסטרטיביים כגון SA/Root.
ניהול תהליך שוטף לשינוי סיסמאות לחשבונות אדמיניסטרטיביים כגון SA/ Root.
יישום הרשאות מינימליות נדרשות עבור יישומים המשתמשים במסדי הנתונים.
יישום הרשאות מינימליות נדרשות עבור משתמשים אדמיניסטרטיביים המפתחים, מתחזקים ותומכים במסדי הנתונים.
 
צמצום החשיפה לשיבוש מידע במאגרי נתונים
יישום ותרגול תכנית הגיבויים אל מול תרחיש שיבוש נתונים.
יישום תכנית DR הערוכה למתן מענה לתרחיש של שיבוש נתונים:
מיפוי מסדי נתונים קריטיים.
ניתוח משמעויות השיבוש.
אפיון מענה מדורג להתאוששות.
התייחסות ליעדי השירות.
התייחסות להערכות ארגונית (עובדים, מנהלות וכיו"ב).
 
צמצום החשיפה לחדירה בערוץ הדוא"ל
בחינת מדיניות קבלת סוגי קבצים בערוץ הדוא"ל, כמו גם בהורדת קבצים באינטרנט. מומלץ להגביל סוגי קבצים המורשים בכניסה לארגון למינימום הנדרש מבחינה עסקית, ולחסום את כניסת שאר סוגי הקבצים.
פתיחת מסמכים תחת נטרול מאקרו וב-Protected view.
שימוש בטכנולוגיות "ארגז חול" (Sandbox) In-line, מנועי AV ומערכות הלבנה עבור צרופות המגיעות בדוא"ל בהתאם לניהול סיכונים.
מניעת ריצה של קבצי הרצה לא מוכרים או מאושרים בתחנות קצה.
הטמעה שוטפת של עדכוני אבטחה בתחנות קצה הנגישות לרשת האינטרנט ולדוא"ל חיצוני.
יישום פתרונות מתקדמים בתחנות קצה של משתמשים בעלי פוטנציאל סיכון גבוה למימוש תקיפה בערוץ הדוא"ל (כדוגמת קיבוע תצורה, הרצת קוד חתום בלבד, עבודה ממערכת הפעלה בתצורת Read Only בלבד וכיו"ב).
ניטור אנומאליות בהזדהות לתיבות דוא"ל של הארגון, הכוללים, בין היתר, ניסיונות הזדהות כושלים, מדינות מהם מבוצעת הזדהות, מספר עמדות קצה או מכשירים מחוברים וסוגים, שעות התחברות.
מימוש הזדהות חזקה לתיבות דוא"ל ומתן גישה רק באמצעות עמדות קצה/Mobile המוחלת עליהן מדיניות וכלי האבטחה והבקרה של הגוף.
אם הארגון מאפשר גישה מרחוק לשרת הדוא"ל, מומלץ להגבילה באמצעות שירות VPN, ולמנוע חשיפת השרת לרשת האינטרנט.
יישום תקן ה-DMARC.
 
צמצום החשיפה להתפשטות נוזקה ברשת
מניעת פעילות שוטפת עם הרשאות גבוהות ע"י מנהלנים (כדוגמת שימוש בחשבון נפרד לפעולות מנהלתיות הדורשות הרשאות גבוהות).
יישום כלים לזיהוי ומניעת ניצול חולשות בתווך התקשורת.
בידול וסגמנטציה במערכות המידע.
 
הגנה מפני תקיפות Web Shell
ווידוא כי מערכת ההפעלה המותקנת על השרתים, ותוכנת שרת ה-WEB, מעודכנות בעדכוני האבטחה האחרונים של היצרן.
עדכון גרסת CMS (Content Management System) כגון ,WordPress Drupal ,Joomla וכו', ובפרט גרסאות התוספים (,(Plugins בהם מצויות רוב החולשות.
הקשחת שרת ה-WEB בהתאם להנחיות היצרן ועל פי העיקרון של Least Privilege. מומלץ לוודא, שלא הופעלו שירותים (Services) שאינם נחוצים.
שימוש בתוכנה מסוג File Integrity Monitoring לזיהוי שינויים בקבצים על השרת.
העלאת תוכן וקבצים לשרת עשויה להוות נקודת כשל אשר התוקף עלול לנצל לטובת השגת נגישות ראשונית. מומלץ להקפיד על:
שימוש במערכת הלבנה בעת העלאת קבצים.
אפשרות העלאת תוכן או כתיבה ע"י משתמשים אך ורק לספרייה ייעודית, שהמשתמש יכול לכתוב אליה אך לא לקרוא ממנה.
וידוא כי סוגי הקבצים אשר ניתנים להעלאה מוגבלים על פי הדרישות העסקיות בלבד. מומלץ להימנע ככל האפשר (אלא אם יש צורך עסקי מהותי) מהעלאת קבצים המאפשרים הרצת קוד.
הקשחת הזדהות ל-CMS (Content Management System), שתבוצע רק באמצעות חיבור TLS מאובטח (1.2 ומעלה בלבד) והזדהות באמצעות 2 אמצעי זיהוי (2FA). מומלץ לבחון אם ניתן להגביל גישת הניהול לכתובות IP ידועות מראש.
מניעת גישה חופשית של שרת ה-WEB למשאבים רשתיים. יש לנטר גישה אל השרת וממנו ולוודא כי גישת משתמשים נעשית אך ורק בפרוטוקולים ופורטים מתאימים–HTTPS .
 
הגנה מפני ניצול המעבר לעבודה מרחוק
בחינת הענקת הרשאות גישה מרחוק לתיקיות מחשוב. מומלץ להתיר גישה לתיקיות חיוניות בלבד.
הפרדה בין גישה לדוא"ל לבין גישה לשרת, תיקיות ונכסים רגישים. אם הגישה לאחרונים נחוצה מומלץ לפתוח את הגישה לפרק הזמן הנדרש בלבד באמצעות איש המחשוב הארגוני.
הסרת הרשאות גישה של העובדים למערכות ארגוניות/ממשקים שאינם חיוניים.
הגדרת מדיניות אכיפת הגדרת סיסמאות מורכבות וקשות לניחוש באמצעות מנגנון ניהול המשתמשים (כגון GPO במיקרוסופט), ואילוץ המשתמש להחליף סיסמה באופן עיתי, במידת האפשר גם הגדרת OTP- one time password כאמצעי זיהוי נוסף.
הגדרת חוקים בחוקת ה- FireWall (הארגוני והמקומי) המאפשרים גישה מרחוק. כך, שגישה זו תצומצם למינימום וכן כי מתקבלים לוגים לתיעוד ההתחברות. בנוסף, מומלץ להגדיר מדינות ואזורים המורשים להתחבר לארגון. לטיוב החוקה ב-FireWall המקומי מבוסס מערכת ההפעלה של Microsoft, היכנסו.
במחשב נייח/נייד - הגבלת הגישה לשורת פקודה (דוגמת PowerShell), כך, שלא יהיה ניתן להריץ סקריפטים, שמקורם לא ידוע או שמקורם ממחשב אחר.
התחברות של עובדים דרך ממשק מאובטח כגון שירות VPN מרכזי עם הצפנה והזדהות חזקה מתאימה.
הקלטת ה-session ושמירת ההקלטה לפרק זמן קבוע (חודשים/שבועות).
 
פגיעויות וחולשות, שפורסמו בשנים האחרונות - קיים חשש לניצולן במסגרת הקמפיין.
המלצות נוספות ופירוט נוסף לגבי כלל הפגיעויות במוצרי החברות השונות, התמודדות עם תקיפות WebShell, עדכוני אבטחה ועוד - כאן.

עדכון 2.5.21: האקרים איראנים הפעילו נוזקה המכונה N3tw0rm וטוענים, שגנבו במתקפת פישינג כמות גדולה של מידע מחברת הלוגיסטיקה הישראלית וריטס (בשבוע החולף) וכעת מחברת H&M ישראל, אותו יפרסמו אם לא יקבלו את סכום הכופר שדרשו. הנוזקה המכונה N3tw0rm איננה מוכרת והיא פועלת בשיטה דומה לקמפיין תקיפה, שמיוחס לאיראן, שמכונה Pay2Key. הנוזקה מתנהגת כמו כופר, אבל היא משמידה מידע. נראה, שהותקפו עוד ארגונים ישראלים. מערך הסייבר הלאומי פרסם הודעה תחת הכותרת "התרעה דחופה" ובה נאמר: "לאחרונה זוהתה מתקפת כופרה נגד ארגונים שונים בישראל. ייתכן כי הגורם האחראי לתקיפות אלו אחראי גם לתקיפות קודמות בקמפיין המזוהה עם Pay2key" - כאן.
עדכון 3.5.21: למערכת טלקום ניוז הגיע המסר המאיים הבא: עדכון 4.5.21: היום הודיעה קבוצת ההאקרים N3tw0rm, שפרצה גם לחברת אקולוג הנדסה מרחובות.
עדכון 5.5.21: קבוצת הסייבר האיראנית מימשה הבוקר את איומיה על חברת H&M והפיצה את מסמכיה (300,000 מסמכים).
עדכון 19.5.21: קבוצת ההאקרים הנ"ל הודיעה על קורבן נוסף: חב' Eitan Medical, שמספקת מוצרים ושירותים רפואיים.