הפריצה ב-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 קניות מהאתר או שום רווח מהאתר כי הוא נפרץ. כדאי לזכור גם כי במקרים מסויימים שהאתר נפרץ, הוא הופך לעיתים גם ל"מחסן" לתוכנות ותכנים לא חוקיים, ולא יקח זמן רב עד שספק האחסון פשוט יחסום את החשבון והאתר עצמו.

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