קטגוריה: אבטחת מידע

על Ransomware והתגוננות מפניהם

cryptolockerעדכון 1: כשהכופרה מעיפה את VSS (בסוף הפוסט)

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

עד לאחרונה מנהלי רשת רבים ידעו על הבעיה והם הסתפקו באנטי וירוס וחלקם אף הסביר לעובדים לגבי אי-פתיחת קבצים, בדיקה האם השולח מוכר לעובד וכו'. אחרי הכל, רוב הזמן הנוזקה הזו הגיעה באימייל, והורדות קבצים מוגנות (שוב, יחסית) עם חומת אש, IPS/IDS, פרוקסי וכו'.

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

  1. פריצה חמורה אירעה בשרתי צד ג' שנותנים שרותי פרסום לאתרים גדולים ודרך פירצה זו הופצו סקריפטים שרצים בדפדפן שמחפשים כל סוג פריצה שקיים לדפדפנים שונים, ל-Flash, ל-Java ו-JS ושאר דרכים – כדי להוריד אוטומטית Ransomware למשתמש וכדי לגרום לו להריץ אותו. כל מה שהמשתמש היה צריך לעשות זה פשוט לגלוש לאתרים הגדולים (כמו New York Times, BBC, AOL, MSN ועוד) והסקריפט שהיה נטען לדפדפן המשתמש היה כבר רץ ומחפש פירצה.
  2. עד כה רוב תוכנות ה-Ransomware היו משתמשות במפתח פרטי קבוע שהיה חלק מחבילת ה-Ransomware, ולאחר זמן מה יצרני האנטיוירוס ידעו לזהות את המפתח ולהציע ללקוחותיהם דרך לחילוץ הקבצים מבלי לשלם כופר. לאחרונה הדבר שונה ובחלק מתוכנות ה-Ransomware המפתח הפרטי נוצר כל פעם מחדש ומועלה מיד לשרת של התוקף ונמחק מהמחשב, כך שלא ניתן אם הותקן Ransomware כזה לחלץ את הקבצים משום שמדובר במפתח 256 ביט שכיום עדיין אף אחד לא פיצח (אולי ה-NSA הצליחו אבל הם לא מפרסמים כלום בנידון כמובן), כך שמחשב פרטי או מחשב בעסק שחוטף Ransomware כזה, הדרך היחידה לחלץ את המידע – היא לשלם את הכופר לתוקף..

בחברות הפתרון לבעיית הכופרה (Ransomware) הוא פתרון הגיבוי. אחרי הכל, בחברה שיש לה כמה מאות או אלפי מחשבים, ה-Winows לא הותקן ידנית בכל מחשב, אלא השתמשו בכלי Deployment להתקנה אוטומטית של Windows כך שבמקרה של התקפת כופרה על מחשב, מפרמטים ומתקינים דרך כלי ה-Deployment את ה-Windows והאפליקציות ואם יש צורך משחזרים דרך הגיבוי את קבצי התוכן.

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

ניתן לעומת זאת להשתמש בשיטה ותיקה שמיקרוסופט המציאה ממזמן (והורידה חלק מהפונקציונאליות בחלונות 8/8.1 אך החזירה ב-10) והיא ה-Volume Shadow Copy (בקיצור: VSS). בשיטה זו המערכת שומרת Snapshot על כל הקבצים המקומיים (לא ב-XP, שם יש שמירה על קבצי מערכת, לא על תכנים כמו מסמכים וכו')

במידה ובמחשבים מותקנים דיסקים קשיחים, ניתן ליצור Partition נוסף שעליו ישבו ה-snapshots (כדאי לעיין במאמר הזה כדי לבצע את הדברים) או שניתן לבצע Snapshot למערכת NAS (על כך בהמשך) וכך ניתן גם לשחזר קבצים את Snapshot של ה-Volume (עוד פרטים כיצד לבצע mount ל-snapshots ולחלץ מידע – ניתן לקרוא כאן).

אם התכנים נשמרים ב-SAN או NAS, כדאי להפעיל את תכונת ה-Snapshot ב-Storage עצמו (חפשו Volume shadow או VSS) ואז את השחזור ניתן לבצע ישירות מתחנת המשתמש (או ב-Storage, לפי הצרכים). יש לוודא ששרות ה-VSS נראה בתחנת המשתמש (בתחנות מבוססות חלונות 7 ובגרסאות חלונות 8 PRO וכו' אפשר להשתמש בכלי כמו Shadow Explorer לשם כך).

שרתי לינוקס שמשרתים תחנות Windows דרך SAMBA: אם הנכם משתמשים ב-LVM אז תוכלו לבצע Snapshots ולשקף אותם דרך smb.conf בשרת כך שניתן יהיה לשחזר קבצים. ניתן לראות איך לבצע זאת כאן. אם הינכם משתמשים בשרותי ZFS על לינוקס/BSD או סולאריס, אין שום בעיה להשתמש ב-Snapshots שמיוצרים ע"י ZFS ל-SAMBA ואפשר לקחת סקריפט מוכן עם הוראות בקישור כאן.

לסיכום: נזקי כופרה יכולים ליצור כאב ראש לא קטן, במיוחד שאין גיבוי עדכני, אז כמובן שצריך לוודא שגיבויים מבוצעים תדיר (ונבדקים תדיר – הדבר האחרון שאתם צריכים זה גיבוי לא קריא בעת חרום). מומלץ לבדוק ולהשתמש בשרות VSS. נכון, השרות די מוגבל (לא ניתן לבצע את גיבוי ה-VSS לרשת) אבל הוא יכול לשמש כפתרון זול על מנת למגר נזק מכופרות. אם אתם מציעים למשתמשים אחסון תוכן בכונני רשת, ודאו כי ל-storage יש snapshots שניתן לגשת אליהם דרך אפשרות ה-Restore to Previous Versions (אם אין, אפשר לתת למשתמשים Shadow Explorer או לכתוב סקריפט ב-PS שיאפשר שחזור).

כשהכופרה מעיפה את ה-VSS: כפי שציין הגולש גיא אדרי בפורום, רוב הכופרות עוצרות את שרות ה-VSS ומוחקות גיבויים (בהנחה וביטלתם את ה-UAC). במקרים כאלו מאוד מומלץ לחשוב לעבור לכונני רשת שיאחסנו את התכנים (לא את האפליקציות וכמובן לא את ה-SWAP). במידה ואין תקציב לסטורג' לדבר כזה, ניתן לבנות סטורג' זול שיארח כונני רשת (יש לדאוג ל-2 כונני SSD ב-RAID-1 שישמשו כ-Cache קריאה/כתיבה ל-RAID פנימי שיורכבי מדיסקים SATA או NL-SAS). אותו שרת יכול להריץ שרות SAMBA, להתחבר ל-AD ועל השרת הזה ניתן ליצור כונני רשת ולבצע Snapshots לכונני הרשת עם LVM או עם ZFS. במקרה התקפה של כופרה, היא לא יכולה למחוק את ה-Snapshots של כונני הרשת, ניתן גם לבצע Snapshots בתדירות גבוהה (עם ZFS בלינוקס או סולאריס או BSD אפשר גם כל 10-15 דקות וניתן להשאיר כמות גדולה של Snapshots מבלי לחשוש לבעיות ביצועים), כך שבסופו של דבר אם כופרה תוקפת, אפשר לשחזר את המחשב מ-IMAGE, למפות את כונן הרשת, ולשחזר מה-snapshot את כל התוכן אל ה-share של כונן הרשת.

האם חייבים להשקיע ב-DR כמו במערכת פרודקשן?

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

ההחלטה: להרים מערכת DR זהה מבחינת ברזלים ותוכנות – למערכת הפרודקשן.

מכיוון שיש אנשים שונים שמבינים את המושג "DR" במשמעויות שונות. המשמעות שאני מדבר עליה היא כדלקמן:

  • מערכת שהיא Active/Passive – כלומר מערכת הפרוקדשן נותנת שרות ומערכת ה-DR לא נותנת שרות בזמן שהיא "פאסיבית". אף אחד לא מתחבר אליה והחיבור היחיד שיש הוא בין המערכת DR למערכת הפרודקשן עם אפליקציית סינכרון מתמשכת שמעבירה כל ביט בין ה-Storage השונים (ה-Storage שבפרודקשן ל-Storage ב-DR), וסינכרונים נוספים רצים בין שרתים עצמאיים (Active Directory וכו').

הנה מערכת קטנה ופשוטה לדוגמא. יש לנו שרת קבצים גדול שאליו מחוברים עוד 2 JBOD (בתצורת RAID, אפשר לחשוב עליהם כמודולים המרחיבים את המקום הפנוי ב-Storage), נתב, חומת אש, ו-12 שרתים שמריצים מכונות וירטואליות שונות.

mind mapping software

האם אנו צריכים בדיוק אותו דבר למערכת DR?

לעניות דעתי, התשובה תהיה ברוב המקרים "לא". ברשותכם, אסביר:

מערכת DR באופן עקרוני, חוץ מלקבל נתונים מה-Storage ושרותים שונים, רוב הזמן כשמערכת הפרודקשן עובדת, היא לא עושה כמעט כלום. אם ניקח את המושג "DR" במובן הקלאסי, השרתים וה-Storage יושבים במיקום פיזי אחר, אולי בבניין אחר, אולי בעיר אחרת, בחוות שרתים שאינה החווה שלנו ואם נשתמש בה שם כ-Active/Active, החברה תצטרך לשלם לא מעט על רוחב פס, חשמל (מה לעשות, חוות שרתים גובות בערך 150-250% יותר מתעריפי חברת החשמל שאתם משלמים בבניין שלכם).

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

  • שרותי קבצים
  • שרותי גיבוי לצד ג' (אם הפרודקשן מושבת עקב הפסקת חשמל ממושכת, רעידת אדמה, אסון כלשהו וכו' – אין לך לאן לגבות את הנתונים)
  • שרותי אותנטיקציה למשתמשים
  • שרתי אפליקציה (SQL, Exchange, Sharepoint וכו')
  • חיבור אינטרנט

אז כשמקימים את ה-DR, אפשר להקים אותו ולחסוך כספים בדרכים הבאות:

  • לא חייבים לרכוש במיליוני שקלים שרת קבצים. זיכרו – שרת הקבצים ב-DR יתן שרותים לזמן קצר עד שהתקלה תטופל, כלומר זה יכול להיות למשך מספר שעות ובמצב אסון טבע – כמה ימים עד שבועות, לא חודשים עד שנים.
  • מבחינת שרת קבצים – אנחנו צריכים 2 (השני ישמש כגיבוי לראשון כי אין לנו במצב חרום קלטות). עם 2 השרתים אנחנו יכולים להשתמש ב-ZFS ובמקום להשתמש בדיסקים מבוססים SAS יקרים, אנחנו יכולים "להעמיס" דיסקים מבוססי SATA זולים וגדולים (הם זולים – בערך 200$ ל-4 טרהבייט ויש אחריות ל-5 שנים) ובשביל לקבל מהירות נוסיף בין 2-4 דיסקים מבוססי SSD שישמשו כ-Cache. ככל שנעמיס יותר דיסקים SATA על המערכת, מהירות הקריאה תהיה הרבה יותר גבוהה כי אנו ניצור RAID של ZFS עם יותר דיסקים מיכניים, כך שאפשר להגיע בקלות למהירות קריאה של בין 400 ל-800 מגהבייט לשניה (אם אתה משתמש בחיבורי 10 ג'יגה או שאתה מחבר מספר פורטים של 1 ג'יגה).
    שרת הגיבוי לעומת זאת, לא מצריך הרבה השקעה – שוב, אפשר נניח להכניס 10 דיסקים של 4 טרהבייט (SATA), ו-2 דיסקים SSD. רוב התעבורה אליו היא כתיבה ולכן ה-SSD יקבל באופן מהיר את הנתונים וברקע מערכת ה-ZFS תכתוב את הנתונים לדיסקים המכניים.
  • לא חייבים לשים שרתים מהדור האחרון, אפשר לשים שרתים מדור קודם או לפני כן במיוחד אם אתם שוכרים מקום לפי ארונות ולא לפי U בחוות שרתים. ה"סוד" הכי ידוע בוירטואליזציה זה זכרון – ואפשר להשיג בזול זכרון לשרתים מלפני 3-4 שנים.
  • אם לא נעביר את כל השרותים, יהיה לנו מקום "להתפרס" מבחינת השרותים, כך שכמות המכונות הוירטואליות שרצות פר שרת לא תהיה גדולה, וכך נוכל לתת את אותו שרות חרום – במהירות מיטבית.
  • גם מבחינת רוחב פס החוצה מהשרתים למשרדי החברה נצטרך לדאוג ל-Policy כלשהו ש"אין חגיגות" כי במצב חרום לא רק תעבורת אינטרנט מבחוץ עוברת, עכשיו גם כל ה-DATA מהשרתים מבחוץ עוברים על אותו רוחב פס, והדבר האחרון שאתם צריכים זה לא להצליח להיות מחוברים לשרתים בחוץ כי כמה עובדים החליטו שעכשיו בדיוק הזמן לצפות בשידורים חיים לגבי המצב. (פתרון למצב כזה שהרמתי בעבר: PC עם מודם 3G שמצד אחד מקבל שידורים דרך סקריפט, ומצד שני משדר אותם ב-LAN הפנימי דרך VLC תוך וידוא שאין אפשרות להתחבר למודם 3G מבחוץ).

במצב השורר כיום, הנהלות רבות מצפות מה-IT להקים פתרונות אך לחסוך בכספים (הטענה הקבועה: IT תמיד מוציאים כספים ולא מכניסים גרוש לחברה. מוכר לכם?). הנקודות לעיל יכולות לחסוך לא מעט כספים.

בפוסט הבא נדבר על מערכות Active/Active.

טיפים להגנה על האתרים שלך

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

זה לא משנה אם הדעות הפוליטיות שלך הן ימין, שמאל, או מרכז, כולנו יודעים שישראל היא מטרה להתקפות תדירות על כל פיפס שקורה במדינה ושקשור למצב בטחוני, מצב בשטחים וכו'. כל מיני "התקהלויות" שונות קובעים תאריכים כדי לתקוף אתרים שמתארחים בארץ (או בחו"ל) כל עוד יש להם קשר כלשהו לישראל, ולפעמים מספיק שיש לאתר דומיין עם סיומת co.il/org.il/net.il כדי שהאתר יהיה באיזו "רשימת מטרות" להתקפה.

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

אתרים רבים מתארכים באחת מ-2 חבילות עקריות לאירוח אתרים: אכסון משותף (Shared Hosting) ושרת יעודי (בין אם וירטואלי או פיזי). אתחיל באכסון המשותף.

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

אירוח אתר (או אתרים) בשרת פיזי או וירטואלי נותן יתרונות גדולים וברורים כגון:

  • רוחב פס יותר גדול לשרת את גולשי האתר
  • אפשרות לאחסן הרבה יותר אתרים ותתי-אתרים
  • אפשרות לקבוע אלו שרותים ירוצו
  • אתם קובעים את הגדרות האבטחה
  • ועוד ועוד

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

הנה כמה דברים שמומלץ לעשות על מנת למנוע כמה שיותר פריצות לשרתים כאלו:

  1. מומלץ להעביר את התוכן של האתר דרך ספק CDN כלשהו ודרכו בלבד. ישנם 2 ספקי CDN גדולים שאני יכול להמליץ עליהם:  Cloudflare ו-Incapsula. ל-Incapsula יש יתרון שיש להם שרת סופי (Edge) בישראל, אולם כמות הנתונים שהשרות נותן בחבילת החינם היא קטנה מאוד (50 ג'יגהבייט). ל-Cloudflare לעומת זאת, אין מגבלת תעבורת נתונים גם בחבילת החינם. אצל 2 הספקים החבילות המסחריות נותנות הגנה רצינית מאוד נגד סוגים רבים של התקפות כך שכל גלישה לאתרכם (ובמידה והתעבורה של האתר שלכם עוברת דרך אותו ספק CDN) – המערכת תבדוק מהיכן הגולש מגיע, האם זהו גולש אמיתי או סקריפט זדוני, האם זהו נסיון גלישה אמיתי או נסיון לפרוץ לכם את האתר וכו'. למי שיש אתר והאתר יוצר רווחים עבורו, אני ממליץ להתחבר לאחד מספקי ה-CDN כמה שיותר מהר.
    נקודה חשובה שרבים מתבלבלים בה – ספק CDN אינו מארח את האתר שלכם. הוא שומר חלקית עותק מקבצים מסויימים ובכך הוא מאיץ את מהירות הגשת חלק מהדפים לגולש, אך כשמגיעה בקשה לדף מסויים לדוגמא, הוא מעביר את הבקשה לשרת שלכם (למעט מקרים שהשרות מזהה שמדובר בסקריפט זדוני, במקרים כאלו הוא ינקוט צעדים שונים למנוע מהסקריפט לפרוץ).
  2. שרות Mail – שרתים וירטואליים רבים של לקוחות מריצים שרותי Mail כך שהאתר ישלח אימיילים ללקוחות וגם ישלח לבעל האתר הודעות אימייל שונות (אישורים לתגובות, אישורי רכישה מהאתר, הודעות מלקוחות וכו'). במקרים רבים שרות ה-Mail אינו מוגדר בצורה מיטבית או בצורה מאובטחת בצורה מספקת, כך שיכולים לקרות במקרים רבים בעיות של שליחה וקבלת הודעות מייל מכיוון שהשרת נחסם ע"י שרתים אחרים וההודעות שיוצאות מהשרת הוירטואלי יסומנו כ"זבל" (spam).
    אני ממליץ לבטל את שרות ה-Mail המתוקן בשרת ולהשתמש בשרות כמו של חברת Mailgun. החשבון החינמי שאותה חברה נותנת, מאפשר משלוח וקבלה של עד 10,000 אימיילים בחודש. האתר עצמו אינו מארח חשבונות אימייל, אלא משמש כ-redirect, כך שהשרות ישלח את המייל בשם האתר שלכם וכל מייל שיגיע אליכם, יופנה אוטומטית לחשבון מייל שיש לכם.
  3. התחברות דרך SSH: ישנם מאות אלפי סקריפטים שסורקים את רשת האינטרנט למצוא דרכים להיכנס לאתר שלכם, במיוחד דרך חיבור SSH (זהו החיבור שדרכו ניתן לבצע פעולות על השרת שלכם דרך מסוף [terminal]). יש לי 3 המלצות לגבי שרות זה (ההמלצות מיועדות למי שמתחזק את השרת):
    * להעביר את חיבור ה-SSH מכניסה 22 למספר פורט אחר (מעל 1024)
    * לחסום כניסת root ישירות (כך ששימוש ב-root יתאפשר ע"י sudo או su בלבד)
    * לעבור מכניסה של סיסמאות לכניסה עם מפתחות
    * לעבור להשתמש ב-Port Knocking.
  4. שימוש בפאנלים כמו WHM/cPanel או Direct Admin: פאנלים אלו הם פאנלים נוחים לעבודה למי שאינו מכיר לינוקס, אולם הבעיה המרכזית איתם שהם מוגבלים מדי לחסום הגדרות שבעל האתר עושה שיגרמו לכך שהשרת יהיה חשוף לפריצות.
    לכן, אם אתם מתעקשים לעבוד עם פאנל כלשהו, לכל הפחות מומלץ לגשת אל הפאנל מאחורי שרות VPN (כדי שהפאנל לא יהיה חשוף לנסיונות תקיפה). אם יש לכם הרבה אתרים והגדרות שונות שאתם צריכים תדיר, מומלץ במקום פאנל לקחת מישהו שמבין בלינוקס ובאבטחת מידע, כך שהשרת יהיה כמה שיותר מוגן.

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

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

על אבטחת מידע ופספוסים

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

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

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

phoneזהו מכשיר טלפון מבוסס אנדרואיד מתוצרת סינית של חברת Phicomm (עוד שם מדבקה). לטלפון הזה אין תכונות מיוחדות, חוץ מזה שהוא זול בארץ – 469 שקל (ויש לו 1 ג'יגה RAM), ונוסיף לזה עוד 40 שקלים עבור כרטיס מיקרו SD של 8 ג'יגהבייט. המכשיר כבר עם root כך שאין צורך אפילו לפרוץ אותו. כל מה שאני צריך לעשות זה להתקין עליו לינוקס (כ-chroot, כך שלא צריך לפרמט את המכשיר ולהתעסק עם 1001 דרייברים) עם אפליקציה כמו Complete Linux Installer, להוריד את הפצת הלינוקס החביבה עליי ולהתחבר לטלפון עם תוכנת SSH כלשהי (ואם אני ממש מתגעגע לגרפיקה – יש VNC עם האפליקציה).

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

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

אז איך אפרוץ? אני יכול להשתמש בשיטות phishing למיניהם, ואולי אצליח, אבל בשביל מה להתאמץ כל כך? כל מה שאני צריך לעשות זה קצת לעקוב היכן החברה יושבת והיכן אותו מנהל אוכל. אני יכול להגיע לאותה מסעדה, להזמין לי איזו ארוחה ולנצל את העניין שרוב הסועדים מתחברים ל-WIFI של המסעדה. אני יכול לנסות להפיל את הנתב אבל בשביל מה? אני פשוט יכול לקחת את אותו טלפון סיני זול שהזכרתי לעיל ולהכניס את כתובת ה-Gatway של הנתב במסעדה ככתובת IP בטלפון שלי. תודות ל-ARP עם מספר טריקים פשוטים, כל גלישת התעבורה תעבור דרך המכשיר שלי ואני יכול לתת לכולם חיבור אינטרנט.. עם "מתנה" קטנה – אני יכול לסרוק את כל המכשירים – טאבלטים, מחשבים, טלפונים, ולהשתמש בפריצות שיש להם במכשירים (כמובן, אם יש לי גישה ל- zero day exploits אני יכול גם לשתול כל מיני דברים באותם מכשירים). אני יכול "להתחכם" ולא להפעיל את המעקף הזה עד שאותו מנהל יתחיל להשתמש במכשיר שלו ולפי הגלישה שלו לזהות את המכשיר ועליו להפעיל סריקה ונסיונות פריצה, ושוב – לפרוץ למכשיר סלולרי מרחוק אינו דבר כזה מסובך. (תודות לרוב חברות הסלולר, עד שמגיעים עדכוני האבטחה אפשר "לחגוג" לא מעט). מכאן, לא יהיה מסובך למצוא דרך להיכנס למכשירו, להשתמש במגוון החורים כדי למצוא root ולהתקין אפליקציה שתתן לי שרותי טרמינל. באנדרואיד לדוגמא אני יכול להתקין בכלל אפליקציה בצורה מוסתרת כמו webkey (או Prompt ו-VNC ב-iOS) שלא רק נותנת לי טרמינל, אלא גם VNC מלא וכשאותו מנהל יקיש את סיסמתו (או יצייר את ה-Pattern) אני אראה הכל. מכאן, לא חשוב לאן אותו מנהל ילך, אני אוכל להתחבר אליו גם כשהוא בחיבור WIFI וגם בחיבור סלולרי.

לשם מה יש לי צורך להתחבר לסלולרי של אותו מנהל? כי אותו מנהל יתחבר עם Certificate וסיסמא (או רק סיסמא, תלוי במדיניות בחברה) במכשיר שלו, לי תהיה גישה לכל הרשת. כבונוס, לא חשוב מה החברה תריץ כדי לחפש פירצות, הם לא יאתרו מהר את הפריצה שלי כי ההנחה היא שיש וירוס/תולעת במחשב, לא בטלפון. מכאן עד פריצה מהסלולר ל-PC של אותו מנהל המרחק די קצר (ויהיה עוד יותר קצר אם אותו מנהל משתמש ב-USB בחיבור ל-PC שלו). כמה קשה לפרוץ Windows 7/8? לא ממש קשה (שוב, תלוי בגישה שלי ל-zero day). עכשיו אני אאחל הצלחה לאיש אבטחת המידע למצוא את הטראפיק שלי בין ה-PC של המנהל לשרתים ומשם לסלולרי של אותו מנהל (ואם אני ממש רוצה לסבך את איש אבטחת המידע, אני יכול ליצור מעין "Tunnel" בין ה-PC ל-IP של המכשיר הסלולרי של המנהל ומשם לשרת כלשהו שיושב בענן ומשם לפרוקסי ומשם אליי, אבל בסופו של דבר יש לי C&C לא רע בכלל…

עכשיו בואו נראה כמעט כל נציג של חברות עם SEC למיניהם מוצאים את זה. תהיו בטוחים שהרוב – לא ימצאו את זה אלא אם יקחו מישהו שממש ממש מבין לעומק, ורוב אנשי ה-SEC, מה לעשות, אינם כאלו.

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

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

  • שרתי WEB – לבדוק את ה-POST (לדוגמא) מהיכן מגיעים נתונים ב-upload ומה הנתונים.
  • קבצי security בהפצות לינוקס.

u2fוהנה עוד המלצה קטנה: תכירו את מפתחות U2F. זו השיטה החדשה לבצע אותנטיקציה כפולה ושיטה זו נתמכת ע"י מיקרוסופט, גוגל וחברות רבות אחרות (כן, כרגיל מי שחסר בתמיכה זה מוזילה..). בניגוד ל"כרטיסים חכמים" שיושבים במחשב הנייח בחיבור USB כאבן שאין לה הופכין, כאן חייבים גישה פיזית למפתח על מנת ללחוץ על העיגול כדי לבצע אותנטיקציה (בגירסה אחרת יותר זולה יש צורך בלהוציא את המפתח פיזית מה-USB ולהכניס מחדש), כך שמחשב עם אותנטיקציה כזו בלבד פשוט לא יאפשר כניסה מרחוק ללא מגע פיזי. הפתרון נתמך בכרום, Windows מק ולינוקס (בלינוקס יש צורך להוסיף שורה ב-UDEV על מנת שהוא יוכר).

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

כמה מילים על פירצת האבטחה של Bash

בימים האחרונים התגלה באג קריטי ב-BASH, באג שעקב בעיית Parsing של משתנים (Variables) מאפשר להריץ קוד זדוני דרך "כל שרות", כפי שתוכלו לראות כאן.

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

נתחיל מה-Web. אם האתר שלך רץ תחת מערכת CentOS או RedHat או SuSE, אז כן – אפשר לפרוץ אם לא תעדכן מיידית את חבילת ה-Bash (פעולת yum update תספיק). שמים לב למשהו? העדכון היחיד הוא ל-BASH, לא לשום אפליקציה אחרת וזאת מהסיבה שדרך BASH המערכת "מרימה" שרותים, וספציפית עם ההפצות הנ"ל מכיוון שבהן ה-Shell (כלומר SH) מקושר ישירות ל-BASH. בהפצות כמו אובונטו או דביאן ה-SH מקושר ל-DASH, כך שמבחינתן זה לא כל כך רלוונטי.

אז עד כאן – העדכון באמת חשוב ויש לבצע אותו.

אבל מכאן ולהיסטריה של Internet Meltdown – המרחק ענק, ברשותכם אסביר.

אם לדוגמא האתר שלך מוגש למשתמשים דרך CDN ואתה מנוי בתשלום ל-CDN כמו Cloudflare העסקי או Akamai או אחרים, הרי שהינך מקבל בחבילה דבר שנקרא WAF (ר"ת Web Application Firewall), ואותו WAF נכון להרגע מעודכן כבר להכיר את הטריק נסיון פריצה עם ה-BASH כך שכל מה שנותר לך לעשות זה להסתכל בפאנל של ספק ה-CDN ולראות איך בזמן אמת מנסים לפרוץ לך … ולגחך. (שימו לב – אני מדבר רק על 2 ספקי ה-CDN הללו. לגבי אחרים – תצטרכו ליצור קשר עם הספק CDN). אני לא טוען שאין צורך לעדכן את המערכת שלך, אלא שאין צורך להיכנס ללחץ.

עדכון החבילה צריך להיעשות על כל הפצת לינוקס. נכון, הפצות מבוססות Debian לא חלה עליהן הפריצה באופן של הפעלת שרות Apache, אבל יש לא מעט שרותים צד ג' שרצים דרך init והשם מפעילים bash בהתחלה (תסתכלו בשורה ראשונה של הסקריפט אם זה משהו שהבאתם מהפצה אחרת). משתמשי אובונטו מוזמנים להסתכל כאן, Debian כאן. אני ממליץ גם להסתכל כאן באתר של רד-האט איך לעדכן וגם איך ניתן לבצע workaround עם mod_security.

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

אז זהו. שלא.

נתבים ושאר ציודים שנותנים ממשק Web אינם משתמשים בד"כ בחבילות שנמצאות בהפצות לינוקס. אף נתב לא מגיע עם Apache אלא אפליקציה אחרת שמגישה דפים ובכל הקשור ל-BASH, בכל הקופסאות משתמשים באפליקציה שנקראת Busybox שמאפשרת לבצע פעולות shell, אך הפריצה הזו אינה חלה עם שום גירסת Busybox.

כך שאפשר קצת לנשום לרווחה.

לסיכום: כן, ישנה פירצה שמאפשרת לחדור דרך שרותים שונים, ואני ממליץ כמה שיותר מהר לסגור, אך יחד עם זאת כדאי לבצע את הדברים עם תכנון ובסבלנות. עדכנתם את החבילת BASH? ודאו שכל המשתמשים מבצעים logout (ומי שלא עושה – זרקו החוצה כדי שלא ישאר תהליך bash ישן) ואז שיכנסו מחדש אם הם צריכים. לחץ והיסטריה כתוצאה מכתבות מבהילות לא יוביל לתוצאות טובות.

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