"הר" פתרונות האבטחה שאינו רלוונטי כל כך

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

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

המציאות פשוטה: גם אם תקים "הר" של Appliances לצרכי אבטחת מידע בכדי להגן על חדירה מבחוץ, הפורצים יכולים לעקוף את כל ההגנות הללו עם פעילות Phishing וכניסה למערכת עם פרטים גנובים. חשוב לזכור: הנקודה הכי חלשה ברוב הארגונים – היא המשתמשים, ולא יעזרו חידודי נהלים לא לפתוח לינקים, לא להוריד/להריץ קבצים במייל וכו' מהסיבה הפשוטה ביותר: אם משתמש קיבל מייל Phishing והוא הזין בו פרטי חיבור אמיתיים, ברוב המקרים הוא לא ירוץ למחלקת IT או אבט"מ לספר על כך. אחרי הכל, מדוע לו לחטוף על הראש? עדיף להפעיל ראש קטן ולהתעלם מכך.

הנקודה הכי חשובה בכל הסתכלות על אבטחת מידע היא Zero Trust. לא לתת שום Trust בין אם מדובר בתקשורת מבחוץ פנימה או בין שרתים או בין מכונות דסקטופ לשרתים. אחרי הכל, אם מאן דהוא הצליח להשיג פרטי גישת VPN למערכת שלכם, מהרגע שהוא מתחבר, הוא נמצא בתוך התשתית של החברה, גם אם יש לו הרשאות מוגבלות (גם עם הרשאות מוגבלות אפשר ליצור נזקים גדולים). יקח לחברה זמן להבין שהפורץ משתמש בפרטי גישת VPN שנגנבו בפעולות Phishing ממשתמש לגטימי, ומאותו רגע שהפורץ מחובר, גרימת הנזק היא פנימית, ה-Firewall וה-WAF שלך לא עוזרים במאומה באותו זמן – וכאן, כדאי לזכור, פורץ חכם לא יחפש לגרום מיידית נזק, אלא יחפש בתשתית נקודות חולשה או תשתית "צדדית" שעליה הוא יכול להתקין את ה-Payload ורק לאחר מספר ימים להפעיל זאת ולהתחיל לגרום נזק/להצפין תוכן או להעביר תכנים.

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

  • להיפטר מסיסמאות: סיסמאות היו ויהיו – מקור לאחד מכאבי הראש הגדולים, כולל כל ה-Policies ליצור אותם, החלפתם וכו'. גם במיקרוסופט ובחברות תוכנה אחרות הבינו זאת מזמן והם מציעים פתרונות שונים המבוססים על טביעת אצבע, Windows Hello, מפתחות כמו Yubikey של Yubico (או Tian של גוגל, ויש גם מפתחות המבוססים בכלל על קוד פתוח כמו Solokeys). בנוסף, שימוש במפתחות מאפשר להשתמש בהצפנות שונות (נתמכות בעיקר ב-Yubikey) ויחסית די קל להטמיע את הפתרונות בכל מערכות ההפעלה.
  • הצפנת תכנים: הסיוט הכי גדול לחברות מבחינת אבטחת מידע, הוא גניבה ו/או הצפנה באמצעות כופרה של המידע, וארגונים גדולים מאוד (חברות כמו קאנון, אוניברסיטאות, בתי חולים ועוד) חוו את הסיוט ונזק משמעותי נגרם לאותם ארגונים. אחד הפתרונות שניתן לבצע הוא הצפנה של רוב התכנים החשובים, וביצוע Decryption דרך Gateway שאליו מחוברים מספר מצומצם של משתמשים. ניתן לדוגמא לבצע זאת בעזרת הקמת LUN שיחובר למערכת לינוקס וירטואלית. מערכת הלינוקס תבצע encryption/decryption עם כלי כמו LUKS-2 או בכלים אחרים, ושיתוף (לאחר decryption) עם SAMBA. אפשר להתגונן נגד כופרה תוך שימוש ב-snapshots (במכונת הלינוקס בשימוש LVM).
  • ביצוע Snapshots – באופן עקרוני, Snapshots ברמת File systems לא אמורים לצרוך כמות משאבים גדולה ליצירה ולכן מומלץ ליצור Snapshots בפתרון האחסון ל-File systems בצורה תכופה מאוד (כל שעה לדוגמא, ובמקרים חשובים כמו הנח"ש – כל מחצית שעה). כך, אם ישנה התקפת כופרה, ניתן לשחזר מה-Snapshot במהירות במקום לשחזר מקלטות.
  • Pen testing הוא פתרון חלקי שלדעתי אינו מספק: לצערי לא מעט ארגונים וחברות שוכרים מישהו מחברה שיבצע בדיקות (Penetration testing), ורובם גם משתמשים באותם כלים וב-Kali Linux (מתי אנשים יבינו ששימוש ב-Kali Linux הוא "אות קין" שלמשתמש אין הבנה רצינית בלינוקס? כל הפצת לינוקס כוללת את כל הכלים הדרושים!) כדי לבצע את הבדיקות, ובמתודה זו הבדיקות והסריקות פשוט אינן מספקות את התשובה המלאה.
    בדיקות הקשחה וחדירה זה לא רק שימוש בכלים כמו nmap, nessus ו-1001 כלים נוספים, אלא לימוד כל המערכת ועבודה בצוות כדי לחשוב על נסיונות חדירה מכל מערכת שרצה בארגון, חולשות שקיימות לכל שרת, לכל Appliance ולכל ציוד (במיוחד ציוד ישן שאין לו עדכונים כבר מספר שנים – ציוד כזה מומלץ להחליף כמה שיותר מוקדם), מי הם האנשים בחברה שפעולות Phishing עליהם יכולות לגרום נזק מהותי, היכן ניתן לעצור או להאט דליפת מידע אם גורם כלשהו הצליח לפרוץ, האם יש עצירה אוטומטית של תעבורת Upload ל-IP שאינו white listed לאחר כמה מאות מגהבייט לדוגמא (כשהפורץ מנסה לגנוב כמה שיותר קבצים), ובקיצור – הכלים הם רק חלק קטן מהעבודה, ודרוש צוות רציני כדי לנסות לפרוץ (מבלי להגביל את הצוות, אבל עם הנחיה לגבות את הכל ולרשום כל גילוי ושינוי) ולא מישהו שהקים Kali Linux על מכונה וירטואלית ומכיר כמה כלים.
  • "קמצנות כרונית" של הרשאות: תופעה שקיימת בכל ארגון – עודף הרשאות שניתנו למשתמשים שונים, הרשאות שנפתחו "זמנית" ונשארו פתוחות או הרשאות שנפתחו ברמת worldwide (בלינוקס/יוניקס זה מוכר כ-777) בגלל שמישהו התעצל לחפש בגוגל ולקרוא איך מגדירים הרשאות בלינוקס. מאוד מומלץ לבצע אחת לחודש או לתקופה לעבור על כל ההרשאות (גם הרשאות מקומיות!) ולצמצם את ההרשאות. אם רוצים להשתמש לדוגמא ב-passwordless ssh, יש להגביל את החיבוריות להרצת פקודות מסויימות, כניסה מכתובות IP מסויימות, ועוד.
  • עדכוני תוכנה ללא תאריכון: אחת הבעיות שכתבתי לגביה שוב ושוב בבלוג זה – מנמ"ר מחליט שעדכונים יהיו אחת ל-X חודשים ותו לא. לך תסביר לאותו מנמ"ר שחולשות אבטחה מתגלות כל הזמן ויש לא מעט מקרים שיש צורך דחוף בהתקנת עדכונים, אחרת התשתית חשופה. דוגמא פשוטה: אם אתם משתמשים ב-vSphere, האם עדכנתם את הטלאי הדחוף הזה?

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

הדרך לפרוץ לתשתית הפנימית שלכם

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

כפרילאנסר, אני במקרים רבים צריך לבקר בחברות לצרכי ישיבות בנושאים שונים. באותם מקרים, אין כמובן גישה ל-LAN של החברה בתוך חדר ישיבות ואם אתה רוצה חיבור לאינטרנט, יש WIFI מיוחד ל"אורחים". אתה מתחבר לאותה נקודת WIFI, מקבל מסך EULA, מסכים לתנאים ואז יש לך גישה לאינטרנט ללא גישה לאינטרה-נט של החברה. (לא תמיד. מדהים לגלות כמה אנשי IT משתמשים באותו DNS פנימי גם ל-WIFI שהוא GUEST, ואז כשמראים להם מה ניתן לגלות בעזרת פקודת dig פשוטה – הם המומים).

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

וכאן מתחיל הפספוס הגדול.

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

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

אז מה ניתן לעשות? להלן כמה רעיונות:

  • Whitelist לכל כתובות ה-Mac Address של המכונות בחברה. כן, זה תהליך ארוך ומייגע (אם כי יש כלים ושיטות לאסוף כתובות MAC ולהזין אותם למתגים/נתבים) ולאפשר התחברות אך ורק ל-MAC "מולבן".
  • שימוש ב-Disk On Key. אם האיש המקצועי רוצה להעתיק קבצים לדוגמא, ובדיקת הקבצים לאחר ההעתקה לפני הטמעתם.
  • שימוש בתוכנת Guacamole עם 2FA: אם מקבלים עזרה מבחוץ, זה כלי שבהחלט יכול לעזור. בשיטה זו התקשורת מוצפנת ואינה עוברת באופן "טבעי" (כך שאם יש פריצה לדוגמא ב-RDP, זה לא ממש משנה, כי הכלי בתוך Guacamole אינו חלק מ-Windows), ואם השרת שצריך לתקן הוא Windows, עדיף להשתמש ב-VNC ולחבר אותו ל-Guacamole, כך שתוכלו לראות מה בדיוק נעשה. שימו לב: עניין ה-2FA מאוד חשוב.
  • השתדלו להימנע מלהשתמש בכלי שליטה מרחוק מקומיים (Any desk, Team viewer) – בחברות רבות כלים אלו מותקנים ואינם מעודכנים כלל וכלל, מה שיכול לאפשר פריצה מרחוק "בשקט".
  • אם מישהו צריך להתחבר ב-SSH, תנו לו רק לאחר שתריצו את screen או tmux, כך תוכלו לדעת מה הוא עושה.
  • אל תשתמשו בתוכנות מאתרים ישראליים. במקרים רבים התוכנות שם ישנות ויש להן פריצות. במיוחד לא תוכנות כמו ammyy admin!
  • הנהלת-IT/מנמ"ר/CTO – דאגו להורות כי כל חיבור מחשב חיצוני יחובר רק לאחר שמחלקת אבטחת מידע מאשרת, רק אם אין ברירה ובזמן החיבור שיהיה ניטור LAN מאותה כתובת IP.

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

על פריצות "מבפנים" ועל דרכים להקשות זאת

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

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

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

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

בדרך כלל, לפני פריצה כזו, הם יבצעו תחקיר בסיוע כל דבר אפשרי (ריגול דרך האינטרנט ברשתות חברתיות, ריגול "קלאסי" תוך שימוש בסוכנים שנמצאים בארץ) כדי למצוא מי האנשים שאותם הם הולכים לתקוף במובן הסייבר. הם יחפשו אנשי IT ואם אפשר – אנשים שיש להם כמה שפחות ידע/נסיון בתחום ה-IT אך שיש להם גישה פנימית למערכות, אחד כזה שלמחשב שלו בעבודה יש חיבור לאינטרנט ול-LAN הפנימי, והוא לא ממש שם לב לשינוי בין URL כמו secure.iec.co.il ל-secure.iec.co.il.info (דוגמא פיקטיבית, אין לי מושג ירוק בתשתית של חברת חשמל). נניח שהראשון מפנה ל-ADFS או משהו חשוב אחר. ה-URL השני שנתתי הוא מזויף והפורצים הקימו אותו (כולל העתקה של גרפיקה עד לביט האחרון) כך שאותו איש IT לא יחוש בסכנה ויכניס את פרטיו האמיתיים להיכנס למערכת. (אגב, טריק ששמעתי שמשתמשים בו אחרי הכנסת שם משתמש וסיסמא הוא להציג הודעה של שם משתמש/סיסמא שגויים כדי "לשאוב" שמות משתמש וסיסמאות נוספות מאותו איש IT).

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

מהרגע שאותו קובץ פועל, לפורצים יש בעצם גישה. סביר להניח שהם יפתחו איזו מערכת C&C (ר"ת Command & Control) כדי לראות איך לגשת אל המערכת, ומכיוון שמשתמשי IT רבים משתמשים בתוכנות כמו SecureCRT ותוכנות אחרות המאפשרות גישה במקביל לשרתים, יש עכשיו לפורצים דרך להיכנס למערכות האחרות עם ההרשאות של אותו איש IT ומהמחשב שלו, כך שסביר להניח ששום מערכת מניעה לא ממש תזהה פעילות חריגה. תזכרו – בשלבים הראשונים, הפורצים לא משנים קבצים וקונפיגורציות, הם לומדים.

אז … מה ניתן לעשות כדי להקשות?

יהיו כאלו שיציעו להשתמש ב-Smart Card. רעיון לא טוב, מכיוון שבד"כ ה-Smart Card נמצא בתוך המחשב ולא מוציאים אותו ואת ה-PIN אפשר לתפוס עם key logger. אז הפתרון הזה עף החוצה.

פתרונות אחרים שיכולים לעזור, הם פתרונות שבעצם מבוססים על אימות כפול, תוך שימוש בטביעת אצבע עם ציוד בחיבור USB או באמצעות TOTP (ר"ת Time Based One Time Password) שמותקן על הטלפון הסלולרי. אפליקציה פופולרית לכך (שנמצאת ב-Repo של כל הפצת אינטרנט) היא Google Authenticator (האפליקציה לא מצריכה חיבור אינטרנט).

איך מיישמים זאת? בכמה צעדים, תלוי במערכת:

  • מערכות לינוקס רחוקות עם כניסת SSH: אם נחליט על TOTP עם שימוש באפליקציה כמו ה-Google Authenticator (יש אפליקציות אחרות ויש גם את המפתחות RSA המפורסמים, כולם עושים את אותה עבודה), נוכל לעקוב אחר ההוראות כאן כדי להתקין זאת. משהו שצריך לקחת בחשבון – תצטרכו להעיף מפתחות SSH מקובץ ה-authorized_keys על מנת שה-TOTP יפעל. כך שתנסו להיכנס לאפליקציה, המערכת תבקש ממכם קוד וידוא שיופיע לכם באפליקציה בטלפון (או במפתח RSA הפיזי).
  • מערכות לינוקס/Windows מרוחקות עם כרטיס Yubikey (גוגל בקרוב מוציאה מוצר מתחרה שנקרא Google Titan, גם הוא פתרון מבוסס FIDO2) – בדרך זו יש לחבר ל-USB מפתח ובכל פעם להעביר את האצבע כשיש צורך לבצע אותנטיקציה. השיטה הזו יותר מאובטחת משיטות שימוש בקורא טביעות אצבע שמובנה במחשב). גם כאן, תצטרכו לבצע תהליך התקנה, רק שכאן יש גם שימוש ב-OpenPGP. כל הפרטים נמצאים כאן.
  • מערכות Windows (תוך שימוש ב-RDP): פתרון חינמי אין למיטב ידיעתי, יש פתרון מסחרי שתומך גם ב-TOTP וגם ב-FIDO2, יש פתרון של חברת ROHOS כאן.

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

הפריצה ב-Equifax והבעיות ב-Enterprise

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

מקור הפריצה גם ידוע: בחברה השתמשו בפלטפורמת פיתוח Apache Struts המאפשרת פיתוח אפליקציות WEB ב-JAVA בקלות. חור האבטחה התגלה וטלאי תיקון שוחרר במרץ, אבל ב-Equifax לא ממש טרחו להטמיע את הטלאי, מה שנוצל בחודש מאי כדי לפרוץ ולגנוב את הררי המידע.

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

וכאן בדיוק מתחילה הבעיה..

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

אבל ישנם 2 בעיות בסיסיות ששום טכנולוגיה כמו FW/IPS/WAF וכו' לא ממש יכולות לפתור.

נתחיל בבעיה היותר קלה לפתרון שרובם כלל לא מיישמים. אני קורא לה "סימוכין עיוור" – שורת שרתי אפליקציה פנימיים מתחברים ל-SQL כלשהו ושולפים מידע. בד"כ אתר מבוסס Web או אפליקצייה וובית או אפליקציית מובייל – יעבירו בקשות מהאפליקציה או מהשרתי Front End לשרתי Back End, שרתי ה-Back End יתשאלו את ה-SQL, יבצעו סינון/סידור פלט ויעבירו את הנתונים בחזרה לשרתי Front End או אפליקציה. עד פה הכל טוב ויפה, וכאן יש לנו "סימוכין עיוור" – מכיוון שכל השרתי Back End ושרת ה-SQL נמצאים בכתובות פנימיות, אין שום מגבלה לכמות השאילתות (ובמקרים מסויימים גם אין סינון שאילתות) ששרתי ה-Back End יכולים לשלוח אל ה-SQL ולהעביר הלאה את המידע. שאילתה אחת או מיליון – זה אותו דבר. ה-IPS או ה-WAF יכולים להגן נגד שאילתות רחבות (ה-*), וכך בדיוק נגנב המידע מ-Equifax (מבלי להיכנס לכל הפרטים הטכניים של הפריצה).

הבה נדגים זאת: חברת תקשורת סלולרית מפעילה מוקד שרות לקוחות. מחשבי פקידי השרות לקוחות מריצים אפליקציות ווביות שמתשאלים ה-SQL נון סטופ לגבי פרטים על הלקוחות והפקידים גם מבצעים שינויים בפרטים (שינוי חבילה, חסימת מספר, שינוי פרטי לקוח ועוד ועוד). האם יש איזו מגבלה של כמות שאילתות פר PC? סביר מאוד להניח שלא וסביר להניח שגם לא נמצא מגבלה כזו גם באפליקציה הסלולרית או באתר החברה, וכך יוצא מצב שאם מאן דהוא פורץ ואני מוצא פריצה בספריה שהחברה משתמשת כדי לבנות את האפליקציית Web – אני יכול להקים מספר מכונות VM אצל ספקי ענן שונים (או יותר גרוע – כמה עשרות קונטיינרים פר VM) – הפורץ יכול לתשאל דרך החור שהוא מוצא את ה-SQL שאלות ובעזרת סקריפט שהוא יכול לבנות – הוא יכול לשאוב את המידע מה-SQL, ועד שהחברה תעלה על כך – הפורץ כבר יעלם לו (אחרי הכל, כשפתוחים חשבון אצל ספקי ענן, ספק הענן אינו מחטט בציציות הלקוח – כל עוד יש ללקוח כרטיס אשראי כלשהו [גם אם מדובר בכרטיס חד פעמי או אפילו קרדיט שהתקבל מביקור בכנס]), אף אחד לא יעצור את אותו פורץ לעשות כרצונו, ואם הוא רוצה – הוא יכול לעשות את הכל דרך VPN או הקמת VPN על ספק הוסטינג נידח כלשהו. בהצלחה במציאת הפורץ.

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

כיום רוב העולם כבר למד לעבוד עם תוכנות/ספריות/פלטפורמות חיצוניות שמדיניות עדכוני האבטחה שלהם לא תמיד ברורה והם אינם כלולים באיזה Repository של הפצת לינוקס. יש כיום את Github שבמקרים רבים יכול להציל מפתחים ואנשי IT עם פרויקטים שאנשים כתבו והעלו ורבים משתמשים בכך כדי לפתור בעיות וכדי לממש דברים שונים, אולם כלי ה-IPS לדוגמא לא ממש מגלים חורי אבטחה וכלי סריקה לא ימצאו את החורים כי לפעמים אין CVE לחור אבטחה לכלי שמישהו פיתח, העלה ל-github ושכח בכלל מהפרויקט לאחר זמן מה. יותר מכך – במקרים רבים ההטמעה עצמה מוטמעת עם הרשאות שגויות (ברמת Administrator או root), עם הרשאות קבצים שגויות, או שפתחו יוזר ב-SQL ברמת "הכל כלול" (רוצים דוגמא? לכו תבדקו בחברה אלו הרשאות ה-Jenkins מותקן ורץ. הוא לא אמור לרוץ כ-root).

אני מתאר לעצמי שעתה יבואו אנשים ויאמרו "מה זה משנה, זה רץ רק פנימית, לאיש אין גישה מבחוץ" וכאן הטעות הגדולה ביותר שיש שבגינה עדיין חברות מריצות פנימית (או חיצונית) שרתי FTP לדוגמא: לא חשוב כמה תסגרו דברים ותשימו רק דברים מסויימים ב-DMZ לשרות מוגבל החוצה ללקוחות, תהיה דרך לגשת לדברים שרצים פנימה שאינם ב-DMZ. כל מה שפורץ מתוחכם צריך היום בשביל לגשת למשאבים הפנימיים שלכם זה לשתול תוכנת שליטה (פרי פיתוח עצמי או משהו מתקדם) על אחד מהלאפטופים של המפתחים או אנשי IT (לדוגמא) וברגע שאותו עובד חברה מתחבר לחברה פנימית (בעבודה) או VPN – לפורץ יש גישה למשאבים הפנימיים ואם אתם סומכים על האנטי וירוס/אנטי Malware שלכם, דעו שאת אותו טריק אפשר לבצע על הסמארטפון, הפורץ פשוט צריך לעשות שיעורי בית ואם אתם חברה גדולה מאוד עם מתחרים מעבר לים – יש סיכוי לא רע שהמתחרים יעשו זאת לכם.

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

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

על אבטחת מידע ללקוחות בעלי אתרים

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

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

אז נתחיל לעשות סדר בבלאגן.

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

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

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

עוד מספר נקודות:

  1. ספק האחסון אינו יכול לעשות קסמים ולהפוך את כל הנתונים למוצפנים, זו אחריותו של המתכנת להצפין את הנתונים לפני ההכנסה/עריכת נתונים קיימים בין אם דרך שפת התכנות, ספריית תכנות או שימוש בפונקציות ששרת ה-SQL נותן (לדוגמא: encrypt ב-MySQL וכאן אפשר למצוא יותר מידע). האחריות של הספק היא לחסום כניסה לא מורשת ל-MySQL (לדוגמא) ברמה של כניסה מבחוץ ומניעת אפשרות למשתמש לראות את כל בסיסי הנתונים בתוך ה-DB עצמו (למעט מה ששייך לאותו חשבון). כמו כן הספק צריך לאסור באחסון משותף (לדוגמא) אפשרות להתחבר ל-SQL מבחוץ (גם כשבונה האתר מאוד אוהב כלי GUI חיצוניים ורוצה להתחבר ישירות לשרת איתם).
    ככלל, ספק צריך לברר עם הלקוח מה הוא מאחסן ולעדכן את החוזה בין הספק ללקוח לגבי אחריות על המידע, עניינים משפטיים וכו' (ואני ממליץ לקחת את שרותיו של עו"ד קלינגר לעניינים אלו, הוא מומחה בזה).
  2. בוני האתרים: מאחריותכם להסביר ללקוחות לגבי עניין האבטחת מידע ולבקש ממנו שימצא איש אבטחת מידע שישב איתכם ויבדוק את האתר וימליץ לכם מה לעשות מבחינת קוד, פרוצדורות וכו'. אם לקוח רוצה לחסוך או לשחק אותה "ראש קטן", אתם תהיו המטרה של רמו"ט על עבירת אי רישום מאגר מידע (ואני די בטוח שהם ימצאו עוד סעיפים להאשים אתכם), ואם מחר חס ושלום יפרצו לאותו אתר ויפיצו את המידע, הנפגעים יכולים לתבוע אותו תביעה אזרחית ותנחשו את מי הוא יגרור אל התביעה הזו..
    לכן אם לקוח מתעקש לא לקחת איש אבטחת מידע, ואתם לוקחים את הפרוייקט, תצטרכו להחתים את הלקוח על מסמך שהוא זה שמבקש אתר ללא אבטחת מידע כפי שנדרש בחוק והוא לוקח את כל האחריות עליו ופוטר אתכם מאחריות (לא יודע כמה מסמך כזה הוא לגטימי, עדיף להתייעץ עם עו"ד).
  3. לקוחות שיש להם אתרי חנויות או כל אתר שאוסף מידע מגולשים: בלי אבטחת מידע גם הרמו"ט יכולה לתבוע אתכם ואם נפרץ האתר שלכם – אלו שזלג המידע שלהם החוצה יכולים לתבוע אתכם תביעה אזרחית על אי-הגנה על מאגר מידע ושלל סעיפים נוספים, לכן מומלץ להשקיע את הסכומים הנוספים ברישום ובאבטחה על מנת להימנע מהכאב ראש הזה.

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

אחסון משותף וחשיבות תחזוקה שוטפת

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

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

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

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

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

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

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

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

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

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

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

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

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