הדברים החשובים בהטמעת פתרון קוד פתוח בארגון

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

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

להלן מספר נקודות:

  • תכיפות שינויי קוד: חברות כמו רד-האט מפתחות את מוצריהן בצורה פתוחה וזמינה לכולם ב-github, ומכיוון שהפיתוח נעשה בצורה פתוחה וציבורית, מבוצעים שינויי קוד רבים, במקרים רבים – שינויים יומיים, וברוב המקרים, גם אם מוכרזת גירסה של הפתרון/ספריה/פלטפורמה – הגירסה אינה כוללת עדכוני אבטחה, בדיקות יציבות ותיקונים אחרים שקיימים בגרסאות המסחריות. מעבר לכך – אם המוצר קורס או גיליתם באגים – תהיה לכם בעיה לקבל סיוע, והכל יהיה תלוי בליבם הטוב של מתנדבים או עובדים (וגם על זה לא מומלץ לבנות, הואיל וחברות כמו סוזה, רד-האט, קנוניקל ואחרים – מקבלים הוראה לתעדף תיקוני באגים לאלו שרכשו גרסאות מסחריות או לאלו שמשלמים על חוזי שרות ליצרן התוכנה).
  • גרסאות תכופות – פתרונות כמו OpenStack, Kubernetes, Ceph, Gluster ופתרונות רבים אחרים משוחררים בתדירות די תכופה ע"י הקבוצות המפתחות אותם עבור יצרניות הפצת לינוקס. הן לוקחות את הקוד, מבצעות שינויים ותיקונים, מוסיפות עדכוני אבטחה (שיחזרו לקוד ה-Upstream יותר מאוחר), כותבות תיעוד ספציפי ועוד ועוד – ואז משחררות אותו במסגרת Life Cycle רשמי עם תמיכה רשמית ועוד, ומוציאות זאת כמוצר מסחרי, ובמילים אחרות – אותם מוצרים שיוצאים כגרסאות תכופות אינם מיועדים לפרודקשן.
  • האם יש לך צוות לינוקס בחברה? אם יש לך צוות In House שמבין היטב בלינוקס ויכול "לשחות" בתוך קוד של אחרים במקרה של תקלה במוצר/ספריה/פלטפורמה – במקרים כאלו קל יותר להטמיע פתרונות בקוד פתוח שעדיין לא יציבים כפרודקשן, ולכן כדאי להסתכל על הנקודה הבאה…
  • אבטחה – פתרונות קוד פתוח שלא מגיעים מיצרן כלשהו, בחלק גדול מהמקרים לא כוללים עדכוני אבטחה, ולכן אם החלטתם בכל זאת להטמיע את הפתרון בחברה, מומלץ כי אחת לחודש הצוות הפנימי בארגון יבדוק את הפתרון המותקן מול הפתרון שנמצא ב-github לדוגמא, ובמיוחד יבדוק אם ישנם תיקוני/עדכוני אבטחה שפורסמו בנפרד (כ-PR או במקומות אחרים) או גרסאות minor בהשוואה למה שמותקן פנימית – ויבצע עדכון ידני. ארגונים שאין ברשותם אנשי לינוקס, מומלץ מאוד יהיה לעבוד עם הגירסה המסחרית ולקבל את העדכונים מהיצרן.

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

כמה מילים על קונטיינרים "מבחוץ"

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

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

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

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

הפצות לינוקס כמו רד-האט, CentOS, SuSE, אורקל לינוקס, דביאן, אובונטו וכו' – נבנית בכל פעם מאפס על ידי הידור קוד של חבילות שונות עד שנבנית הפצה בסיסית לחלוטין. להפצה הזו המערכת תעשה Boot, ומשם היא תמשיך להדר את הקוד של כל החבילות שונות (ב-רד-האט, או כל הפצה מבוססת RPM יש חבילות מיוחדות שנקראות SRPM שמכילות קוד מקור + טלאים וסקריפטים כדי לקמפל אותה). ההפצה כוללת חבילות שונות מבחוץ שעברו בתוך יצרן ההפצה בדיקת קוד וברוב המקרים גם שינויים על מנת לרוץ על אותה הפצת לינוקס ספציפית.

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

בחברות גדולות (כמו בנקים וכו') בדרך כלל לא פותחים את חומת האש להורדת חבילות מיצרן ההפצה באופן ישיר ומשתמשים בתוכנת-אמצע (Middleware) כמו Red Hat Satellite כדי להתקין את ההפצות ועדכונים על שרתים ומחשבים נוספים. ברוב המקומות האחרים שאינם עובדים ישירות מול רד-האט או עובדים עם הפצות אחרות, יש כלי אחר חינמי ובקוד פתוח כמו SpaceWalk שמאפשר להפיץ פנימית בשרתי החברה (ובחשבון הפרטי בענן הציבורי של החברה) עדכוני תוכנה בצורה מאובטחת ומוצפנת (אפשר לשלב בתוך הכלי גם את ה-CA של החברה).

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

איך? די פשוט. כמעט בכל קונטיינר שמופיע ב-Repository ציבורי (כמו Docker Hub) אנחנו נמצא קישור ל-Github שמכיל את קוד ה-Dockerfile. נוריד את קבצי ה-Dockerfile ואחרים מה-git (פקודת git checkout) ואז פשוט נבנה את הקונטיינר מחדש. היתרון הגדול בבניית הקונטיינר מחדש הוא בכך שחבילות רבות מקבלות עדכוני אבטחה וקונטיינרים הזמינים ב-repo ציבורי לא תמיד מעודכנים, וכך נוכל לבנות אותם עם הגרסאות המעודכנות עם תיקוני אבטחה ומה שיותר חשוב – החבילות מגיעות ממקום ידוע (אם משתמשים ב-spacewalk – אז הם מגיעים משרת פנימי בחברה שהוריד את החבילות ממקור בטוח), ואפשר כמובן לאחסן את אותם קונטיינרים ב-Registry פרטי פנימי (הנה הוראות איך להקים אחד באובונטו).

במקרים מסויימים ה-Dockerfile כולל פקודת COPY וקבצי המקור אינם נמצאים ב-repo באותו git. התייחסו במשנה זהירות לקונטיינרים מסוג זה, ובמקרים כאלו אם אתם ממש צריכים את הקונטיינר הספציפי, אולי כדאי להריץ עליו סריקה עם אחד הכלים שהזכרתי לעיל.

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

על בנייה ואבטחת מערכות משובצות

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

עם כניסת ה-Raspberry Pi ושלל החיקויים שלו, יותר ויותר אנשים החלו לגלות את עולם ה-SBC (כלומר Single Board Computer – לוח אחד שעליו נמצא הכל, כולל מעבד, זכרון, אחסון ושלל חיבורים לעולם החיצון) ושוק המערכות המשובצות החל לקבל "ניעור" רציני. חברות המייצרות פתרונות הכוללות מערכות משובצות ראו שניתן לרכוש בכמה עשרות דולרים מערכות SBC ל-Embedded, מה שגרם למתחרים הותיקים להוריד מחירים. למי שאינו מכיר – הכרטיסון בתמונה הוא מחשב Raspberry Pi Zero שכולל כל מה שצריך (למעט חיבור רשת קווית שאפשר להוסיף במספר דרכים). העלות? 5 דולר, וזו סתם דוגמא ל-SBC זול שיכול לבצע פרויקטים שונים.

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

  • עצמאית או C/S? אחד הדברים הראשונים החשובים הוא להחליט איך המערכת תרוץ בעצם. האם מדובר במערכת עצמאית שאין לה תקשורת לשום שרת (עצמאית) או C/S (כלומר Client Server)? אם מדובר במערכת עצמאית, אז נצטרך להתקין עליה את כל האפליקציות (תיכף ארחיב על כך), ולדאוג לכך שהיא תפעל כמעט בכל מצב אפשרי, כולל מצב חרום שבו היא יכולה להציג למפעיל אם יש תקלה, מה התקלה ומה קוד התקלה כדי שיצרן הפתרון יוכל לטפל בכך.
    אם מדובר ב-C/S לעומת זאת, אז יהיה כדאי לבנות מערכת כמה שיותר רזה (לא להתקין הפצת לינוקס על המערכת אלא להשתמש ב-Yocto לדוגמא) וכל אפליקציה נחוצה תרוץ על השרת וביניהם התקשורת תעבור ב-TCP/IP, שימוש ב-Web Sockets וכו'.
    אם מדובר במערכת שיש לה תקשורת לשרת אך התקשורת אינה קבועה (אחת לשעה, אחת ליום וכו') אז כדאי יהיה לבנות אותה למצב אחסון זמני כך שברגע שהתקשורת מבוצעת, כל הנתונים מועברים לשרת, מתבצעת בדיקה שהנתונים נשמרו על השרת באופן תקני (אפשר להשתמש במגוון שיטות checksum) ולאחר מכן הנתונים ימחקו מהמערכת המשובצת. מבחינת אפליקציות להתקנה, נצטרך למצוא מה ניתן עדיין להריץ על השרת הרחוק ומה צריך לרוץ מקומית.
  • לא לדסקטופ: יש לא מעט מפתחי מערכות משובצות, שברגע שהם מקבלים מערכת משובצת עם 4 ליבות, 1-4 ג'יגהבייט זכרון ו-64 ג'יגה אחסון eMMC – בונים מערכת כאילו זה לינוקס דסקטופ. זה לא רעיון טוב הואיל וכל מעבד PC פשוט עוקף בסיבוב כל מעבד של מערכת משובצת. בנוסף, מערכות משובצות בקושי מקבלות עדכונים אם בכלל כך שיש סיכוי לא קטן שמערכת כזו בסופו של דבר תיפרץ ומכיוון שמערכות כאלו לא מעודכנות כמעט, הפורץ יכול להיכנס ולהשתמש ברשת הפנימית ובמערכת המשובצת כפי שירצה.
  • דיאטה: מערכת צריכה להיות כמה שיותר קטנה על מנת להקטין את וקטור התקיפה ולאפשר תחזוקה (אם צריך) קלה, ולכן לא מומלץ להתקין עליה מערכות אפליקציות שרת רגילות. צריכים לדוגמא SQL? תכירו את SQLite. צריכים שרת HTTP? יש מספר אפשרויות שמתאימות למערכות משובצות או httpd שמגיע כחלק מ-BusyBox או שימוש בשרת Web מובנה שקיים בפייתון/GO.
  • שפות כתיבת קוד: אם הפתרון הולך לרוץ כ-C/S, אז אתם יכולים לכתוב באיזו שפה שבא לכם ולהריץ את הקוד על השרת. אם זו מערכת עצמאית, אז אני ממליץ לכתוב בפייתון, Go או PERL (לוותיקים שביניכם) וסקריפטים ניתן ב-Bash או Python. יהיו כמובן חברות שירצו לכתוב קוד ב-JAVA או DOT NET (אפשר להריץ Dot Net Core על לינוקס), אבל חשוב לזכור שאם המערכת מבוססת על ARM ותרוץ עצמאית, אפליקציות כמו Wildfly או runtime של Dot Net Core לוקחות לא מעט משאבים ובלא מעט מקרים גורמות למערכת להגיב בצורה איטית.
    חשוב: לא לכתוב קוד אסמבלר יעודי למעבד. נכון, קוד אסמבלר זה נחמד ונותן מהירות (היום זה פחות רלוונטי, GCC מוציא קוד אסמבלי מעולה!) אבל פעם הבאה שהחברה תחליט להחליף מעבד, מישהו יצטרך לשכתב המון קוד אסמבלר מחדש ולכן אני ממליץ לא להיכנס לביצה הזו.
  • רדו מ-Windows: אתם בוודאי נתקלתם בזה בעבר – כספומטים שמגיבים באיטיות, מערכות מידע שלא מגיבות או שפשוט תקועות, קופות רושמות שנתקעות באמצע העברת מוצרים אצל הקופאית ועוד ועוד. מדוע ישנם הרבה פתרונות מבוססי Windows? כי מיקרוסופט מספרת כמה ה-Windows (כולל גירסת ה-Embedded) "יציבה", חברות גדולות עד לפני מס' שנים כתבו קוד שרץ רק על Windows, בנו "פתרון" שמורכב על PC פשוט והרי לכם מערכת שגם עם מיטב המומחים עדיין מצליחה להיות בלתי יציבה ואיטית פתאום.
    כיום ניתן לבנות מערכת משובצת מבוססת לינוקס שלא תתפוס יותר מ-80 מגהבייט אחסון (בערך) ותרוץ יפה על 1 ג'יגהבייט זכרון והמערכת תכלול דפדפן ותמיכה במסך מגע וכל המערכת תעלה מרגע החיבור לחשמל תוך 8-12 שניות עם הצגת לוגו לקוח בשניה הראשונה ולאחר 10-12 שניות הלקוח האנושי יכול להשתמש במערכת בתוך דפדפן סגור (כך שניתן להציג גרפיקה, OpenGL, אנימציה וכו' וגם לחבר את המערכת לציודים אחרים אם צריך).
    מדוע לא עוברים למערכת כזו? בחלק מהמקרים יהיה צורך לכתוב קוד חדש (במקרים כמו קופות), בחלק מהמקרים מדובר בחששות לא מבוססים, ובחלק מהמקרים עקב אי ידיעה או אי הכרת הדברים. אני מקווה בקרוב לקבל כמה מערכות משובצות, לבנות כמה מערכות דמה ולהוציא קליפים להדגמה ביוטיוב..
  • אבטחת מידע: זוכרים שאמרתי שלא כדאי להתקין הפצת לינוקס על מערכת משובצת? זה אחד הדברים הראשונים שפורץ ינסה להשתמש לטובתו, ולכן מומלץ לעבוד עם Busy Box סופר מצומצם במכונה שיכלול אך ורק פקודות הכרחיות, לצמצם הרשאות, לא להריץ הכל כ-root, ואם אפשר – לעבוד עם מפתחות והצפנה, בשביל זה כמעט כל מערכת משובצת מכילה רכיב TPM (לחובבי Raspberry Pi – יש חלק שניתן לרכוש, להרכיב ולהשתמש מבלי להלחים חוטים). אם המכשיר הולך להיבנות בסין, קחו בחשבון שינסו לגנוב לכם את הקוד ולכן הצפנה היא מאוד חשובה.
  • פשוט זה חכםתכירו את אחד החתולים הביתיים שלי – זהו נימי. מדוע אני מציג אותו? כי רמת המשכל של נימי שווה בערך לרמת המשכל של חלק מהאנשים בסין שיבנו ויקימו את המערכת ללקוח ובחלק מהמקרים – זו גם תהיה רמת המשכל של אלו שישתמשו במערכת (כבר ראיתי מישהו שמנסה להכניס בכח את כרטיס האשראי שלו לחור ממנו יוצאת הפתקית בכספומט!).
    לכן – אם המערכת שלכם כוללת אחסון (eMMC, SSD, לא מומלץ דיסק קשיח מכני, SSD הרבה יותר אמין) ואתם צריכים להקים Installer שירוץ על PC ויתקין את המערכת שלכם על הלוח SBC, תשתמשו בכמה שיותר אוטומציה ותנסו לצפות ולפתור כל תקלה אפשרית. אם המערכת נמסרה וישנה תקלה במערכת, תעלו אותה מחדש אוטומטית כך שברגע שהמשתמש יכנס דרך הדפדפן, התקלה תוצג והלקוח יוכל לשלוח לכם צילום מסך שלה.
    חשוב לנסות (אם התקציב מאפשר) לבנות מערכת Dual Boot (מערכת u-boot תומכת בכך) כך שניתן יהיה לשדרג מרחוק את המערכת עם Image תקין, ואפשר להשתמש בגירסת SystemD האחרונה כדי לעלות למערכת חרום אם המערכת הנוכחית לא עולה (אפשר לקרוא על כך כאן).
  • דלת אחורית/כניסה מרחוק: לא תמיד אתם יודעים היכן המערכת תרוץ ואתם לא יודעים מתי ומאיפה תקבלו בקשת תמיכה, ולכן חשוב לבנות זאת כחלק מהמערכת. אל תצפו ממשתמש קצה להקיש פקודות או שתקבלו בלא מעט מקרים – תוצאות מביכות.

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

הבאג הקריטי במעבדי אינטל – עדכונים

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

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

בפעם שעברה דיברתי על הנחתה בביצועים בין 5 ל-30%, וכאן יש לעדכן: זה תלוי במעבדים בשרתים. מעבדים עד 5 שנים אחורה. מעבדים כמו Xeon E3/E5/E7 V3 ומעלה יש בתוכם פונקציונאליות שעוזרת למגר את הנחתת הביצועים כך שלא תהיה הנחתה משמעותית בביצועים, אולי אחוזים בודדים.

במעבדים היותר ישנים (שרתים כמו DELL דור 11 ומטה, HPE דור 7 ומטה, לנובו/IBM דור M3 ומטה) עדיין יורגשו הנחתות בביצועים במקרים מסויימים. המקרה הכי נפוץ שמצאתי הוא שכשמריצים שרתים כאלו כ-Hypervisor (כמו Hyper-V או ESXi) ומריצים את המכונות דרך Datastore שעובד על דיסקים מקומיים. מכיוון שלשרתים אלו אין אפשרות להיות משודרגים למעבדים מדור 3 ו-4 (טוב, למעט SuperMicro ששם אתה יכול להחליף לוח אם, בנוסף למעבדים, ובנוסף גם זכרון..) – האפשרויות שישנם הינן:

  • להקים מכונת VM שמחוברת לבקר דיסקים ולהריץ עליה מערכת שרות קבצים NFS/iSCSI.
  • להקים פתרון כמו שתיארתי לעיל אבל בתצורה פיזית.
  • לקנות פתרון סטורג' כלשהו.

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

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

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

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

לסיכום: מכיוון שרוב החברות הגדולות כבר לא מחזיקות בשרתים ישנים – אז הבעיה אינה כל כך חמורה בכל הקשור ל-Meltdown. בנוגע ל-Spectre בגירסה הראשונה, העדכון לא מוריד ביצועים (והתיקונים לגירסה השניה יעשו הן ע"י יצרניות מערכות הפעלה והן ע"י יצרניות אפליקציות). עדיין נשארו בעיות בכל הקשור ל-Spectre על טלפונים מבוססי אנדרואיד ועדכונים יצאו ע"י יצרני הטלפונים (ואם יש לכם מכשירים ישנים, אולי כדאי להחליף להם ROM למשהו כמו LineageOS). מבחינת ספקי ענן – כולם משתמשים בציוד די חדיש וכולם מעדכנים את כל השרתים שלהם, יכול להיות שתקבלו הודעה מנומסת מהן לעשות Reboot ל-Instances שלכם. מבחינת מחשבי Desktop, לאפטופים – ההנחתה בביצועים כמעט ולא קיימת. מה שהכי חשוב – יש לעדכן את כל השרתים ולבצע לאחר מכן Reboot לאותם שרתים.

על איומי סייבר וסחטנות דיגיטלית

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

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

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

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

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

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

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

… עד שמהנדס כלשהו בסימנטק החליט לגלות לכל העולם ואחותו בפוסט בבלוג של סימנטק שהמפתח נשאר במחשב וגם היכן הוא נמצא. גם אותה כנופיה קראה את הפוסט וב-1/4 הם שחררו גירסה מעודכנת של הנוזקה שמוחקת את המפתח. תודה לסימנטק!

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

מה ניתן לעשות? כמה דברים:

  • כרגיל, אנטי וירוס יעיל יכול לעזור בעצירה של הנוזקה מלהיכנס אל המחשב שלך.
  • גיבוי – אם הינך מגבה לדיסק אחר שמחובר למחשב שלך או לתיקיה אחרת, זה לא מספיק. נוזקה כזו יודעת להיכנס גם לגיבוי כזה ולהשמיד אותו. לפיכך מומלץ לגבות לענן לשרות כמו DropBox או Google Drive שנותנים כמה ג'יגהבייט בחינם, אך הפתרון הכי טוב הוא גיבוי שאינו זמין כ"כונן" במחשב – פתרון כמו של Backblaze יכול להיות טוב למרות שהוא אינו חינמי (5$ לחודש ללא הגבלת מקום). כעקרון – גם גיבויים למקומות אחרים טובים, כל עוד השרות אינו ממופה כ"כונן".
  • קצת מחשבה – מכיר מי שלח לך? אם לא, אל תפתח. אתה סקרן ולא בטוח? שמור את הקובץ ואל תריץ, סרוק אותו באנטי וירוס שלך או בשרות החינמי Virus Total.
  • מאוד מומלץ לעבור משימוש מתוכנות מייל שמותקנות על המחשב למייל מבוסס רשת כמו GMail, Outlook.com, Yahoo Mail. שרותים אלו סורקים כל הצמדה ומונעים הורדה.
  • אם גיבוי – אז גיבוי מלא: ודא שלפחות אחת לחודש יש לך גיבוי של Full Backup ולא רק Incremental.
  • אם הנוזקה הזו דפקה את המחשב שלך, אל תשחזר מגיבויים לפני שהנוזקה מוסרת ממחשבך, אחרת גם השחזור יוצפן.

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

הגנה פשוטה נגד Defacement – לבעלי VPS

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

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

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

הטריק שאנחנו הולכים להשתמש, הוא טריק שמשנה הרשאות ברמת ה-File system אך לא ברמת ה-UNIX אלא ברמה של ה-EXT2/3/4, כלומר ברמה של הקבצים ב-Partition. שם ההרשאות הן שונות מרמת הלינוקס הרגילה שאנחנו מכירים וניתן לעשות דברים רבים עם זה. אפשר לקרוא על כך עוד כאן.

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

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

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

chatter +i index.php

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

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

chatter -i index.php

עכשיו תוכלו לעדכן.

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

השיטה הזו אינה מגינה 100%. אם פורץ הצליח לקבל הרשאות root ע"י שימוש ב-exploit כלשהו, הוא יגיע לקבצים ואם הוא יודע קצת לינוקס, הוא יוכל לשנות עם פקודת chattr, אבל גם בלי זה, אם האתר שלכם נפרץ, אז יש מצב שהפורץ יעלה לשם קבצים או שישנה לכם את ה-DB, ולכן אם אכפת לכם מהאתרים, מומלץ מדי פעם להציץ ב-DB לראות שהכל תקין, שאתם יכולים להיכנס ל-wp-admin (אם זה וורדפרס) או administrator (אם זה ג'ומלה), ובדקו שאין בתיקיית האתר קבצים שלא אתם הוספתם. כבר ראיתי מקרים שמישהו הגן על האתר שלו אבל הצצה לתיקיית ה-public_html שלו הראתה ערימות של קבצי פריצה רק מחכים לשימוש.

 

מה לבקש מבוני אתרים?

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

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

להלן ההמלצות:

  • לעבוד תמיד עם פלטפורמות ידועות ומוכרות ולא להתפתות לכל מיני פלטפורמות נישה שהיום הם כאן ומחר אף אחד לא יודע מה קורה איתן. הפלטפורמות המוכרות הן: WordPress, Joomla, Drupal. הפלטפורמות הנ”ל מפותחות ומתעדכנות תדיר, ובעיות אבטחה בהן נסגרות במהירות, והן מספיק גמישות לתת פתרונות מבוססי תוכן החל מאתר קטן ועד לבלוגים ענקיים (CNN לדוגמא משתמשים בוורדפרס לבלוגים שלהם).
  • להשתמש רק בגרסאות האחרונות היציבותשל הפלטפורמה. לא מעט בוני אתרים מנסים לחסוך זמן בכך שהם מעתיקים ממערכת אחרת שהם בנו, וכך הלקוח יקבל גירסה ישנה עם חורי אבטחה שינוצלו על ידי כל מיני ילדים ופורצים למיניהם. נכון להיום הגרסאות האחרונות של הפלטפורמות הנ”ל הן:
    • ב-Joomla נכון לכתיבת שורות אלו הגירסה היציבה האחרונה היא 2.5.7
    • ב-Wordpress נכון לכתיבת שורות אלו הגירסה היציבה האחרונה היא: 3.4.2
    • ב-Drupal נכון לכתיבת שורות אלו הגירסה היציבה האחרונה היא: 7.16
  • יש לציין בהסכם בין הלקוח לבוני האתר כי אסור שבוני האתר ישנה קוד בפלטפורמה. לצערי רבים מבוני האתרים מנסים “לחתוך פינות” ולשנות קוד בתוך הפלטפורמה. הבעיה? שדרוג גירסה (דבר שצריך לבצע לפחות אחת לחודש או חודשיים) יגרום לאתר לא לעבוד. בונה האתר, אם יש לו צורך בשינוי, צריך לכתוב או להשתמש במודולים חיצוניים ש”מתלבשים” על הפלטפורמה. אותו הדבר לגבי עיצובים – אם יש צורך בשינוי בעיצוב, השינוי צריך להיות בקוד העיצוב בלבד ולא בפלטפורמה.
  • בכל הנוגע לעיצובים, ההמלצה שלי היא לרכוש עיצוב מאתרים בחו”לולשלם לבונה האתר על תרגום/”גיור” העיצוב לעברית/ימין-שמאל. הסיבה לכך היא שלצערי לא מעט מבוני אתרים משתמשים בעיצובים שהם השיגו בעבר (בין בצורה חוקית ובין שלא) ובאותם עיצובים יש חורי אבטחה. כאשר רוכשים עיצוב מאתרים גדולים בחו”ל (בד”כ הסכום הוא בסביבות כמה עשרות דולרים), מקבלים חינם שנה של עדכונים לעיצוב, ובאתרים רבים, ניתן באותו מחיר לקבל מספר עיצובים, כך שאם אתם הלקוחות יש לכם מספר אתרים, תוכלו להוריד עיצוב שונה לכל אתר.
    • אם הזכרתי כבר עיצובים, כדאי לבחור עיצובים שתומכים בשפות נוספות (רבים מהעיצובים תומכים בכך, חלקם גם תומכים באתרים עם ימין-שמאל כמו עברית, ערבית, פרסית וכו’), כך שמתרגם העיצוב יצטרך לכתוב קובץ תרגום פשוט, וקובץ CSS למיצוב/עיצוב אלמנטים. במקרה ויהיה צורך בעדכון, ניתן יהיה לעדכן בקלות ויהיה צורך רק בהחלפת קובץ CSS לאחר העדכון.
  • בכל הקשור לחנויות, תוכנת OsCommerce כבר מזמן “מתה” (גירסה 2.3 לא עודכנה זמן רב וקיימות לה פריצות רבות, גירסה 3.0 נמצאת בפיתוח זמן רב והם לא ממליצים להכניס אותה לשימוש בחנויות פעילות או חדשות). יש פלטפורמה בשם Magnto בגירסה חופשית או מסחרית, אולם כיום ישנם תוספים רבים שיודעים להתלבש על הפלטפורמות שהזכרתי לעיל שנותנות פונקציונאליות זהה. לא מומלץ להשתמש בפתרונות קנייניים שבונה האתר כתב לדוגמא, הואיל ושימוש בפתרון כזה “כולא” אותך עם הפתרון הנ”ל ללא אפשרות לבחור פתרון אחר.
  • הסכם עדכונים: מומלץ לסגור בהסכם עם בונה האתרים כי אחת לחודש הוא יכנס לחשבונכם אצל הספק בו הינכם מאחסנים את האתר שלכם כדי לעדכן את כל מה שצריך עדכון: פלטפורמה, תוספים/מודולים,חבילת עיצוב. ללא הסכם כזה, אתם חשופים לפריצות שיתגלו בהמשך הדרך ולהפסד לקוחות והכנסות אם האתר יפרץ (שחזור של הספק אינו מהווה פתרון, ושום ספק אינו מקבל על עצמו לבצע עדכונים אלו ללקוח).
  • בחרו רק בונה אתרים שנותן להם באחריות אבטחה: ב-99% מהמקרים שאתר נפרץ, הבעיה אינה נמצאת בתשתית של הספק אלא ב-חורי אבטחה שהתגלו לאותה פלטפורמה שהאתר שלכם משתמש. לצערי לא מעט בוני אתרים מנסים להתחמק בכך שהם מאשימים את הספק וכל העולם, אך אינם בודקים את הקוד שלהם (או שהם אינם מבינים מספיק בקוד או באבטחת קוד). ראיתי מקרים בעבר שבונה אתרים המליץ ללקוחותיו להשתמש בכל מיני פתרונות CDN (טכנולוגיה שמפיצה את האתר שלך בשרתים אחרים בעולם הקרובים גיאוגרפית למשתמשים) כפתרון אבטחה, אולם פתרון זה ברוב המקרים כלל לא עוזר אם יש חורי אבטחה בקוד הפלטפורמה/מודולים/תוספים/עיצוב.

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

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

חנות באינטרנט

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

זו שיטה נחמדה, אבל בעייתית מכמה סיבות.

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

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

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

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

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

  1. מצא לך בונה אתרים מקצועי (אחד שיש לו כמה שנות ותק ונסיון עשיר) ותאר לו מה אתה רוצה להקים, איך זה יראה, מה הדברים שיהיו בו ועוד. בונה האתרים יוכל לאמר לך מה תצטרך, מה העלויות וסביר להניח שהוא גם יקשר אותך לגרפיקאי שיבצע עבורך את העיצוב (ניתן לרכוש גם עיצובים בחו"ל ובונה האתר יוכל "לגייר" אותם בתשלום לעברית)
  2. מצא לך אחסון אתרים אמין (יש מספר ספקים גדול בארץ שמספק זאת. אם אינך מבין באחסון אתרים, תוכל לשאול את בונה האתרים על כך והוא יוכל להמליץ לך על ספק זה או אחר) וסגור חבילה עם הספק, ותן את הפרטים הטכניים לבונה האתר שלך (הסיבה שעדיף לך לעשות זאת בעצמך ולא עם בונה האתרים היא פשוטה: עדיף שהשליטה בנושא אחסון האתר תהיה שלך, אתה בסופו של דבר הלקוח).
  3. אם יש לך המון (מאות או אלפי פריטים), אתה רוצה להחזיק מאגר לקוח, לעשות סליקת כרטיסים מאובטחת, כדאי לך לקחת במקום חבילת אחסון אתרים, שרת וירטואלי (VPS). המחיר הוא יותר גבוה בהשוואה לאחסון אתרים, אולם ב-VPS יש לך שליטה מלאה ומי שינהל לך את האתר והשרת יוכל לדאוג למקסימום אבטחה.
  4. במרבית המקרים בונה האתרים יקח פלטפורמה לניהול תוכן כדי להקים את אתר המכירות שלך, בקש ממנו שיוודא כי הגירסה של התוכנות תהיה עדכנית.
  5. לקראת סיום הבניה, ודא כי האתר שלך עולה ונראה טוב בכל הדפדפנים הסטנדרטיים כמו פיירפוקס, כרום, אופרה ואקספלורר, ומומלץ לוודא כי האתר עולה ונראה טוב גם באייפון או טלפונים כמו גלקסי.
  6. ודא כי החוזה בינך לבין בונה האתר כולל: תחזוקה חודשית ועדכוני תוכנה, ותמיכה. סביר להניח שזה יוסיף מעט למחיר, אך זה שווה את הסכום: הדבר האחרון שתרצה לראות שקורה לאתר שלך שהוא נהפך מחנות לאתר עם דגל פלסטין וקללות.

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

בהצלחה

על אבטחת מידע ללקוחות – מצד הספקים

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

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

תקיפת שרת

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

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

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

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

פריצה לשרת

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

שיטה זו עדיין בשימוש היום על ידי סקריפטים שפורצים רבים מריצים. הסקריפט לוקח טווח כתובות מסויים ומנסה למצוא בפורטים מסויימים אפשרות לפרוץ, כך לדוגמא אחד הפורטים הפופולריים הוא פורט 22 שמשמש בשרתי יוניקס/לינוקס כחיבור לשרת (SSH). סקריפט כזה שמוצא את הפורט הזה, ינסה לעשות login דרך משתמשים כמו root, admin וכו' ועל כל משתמש הוא ינסה להריץ סידרה של סיסמאות ידועות כמו מספרים, מספרים ואותיות רציפות על מקלדת (1q2w3e4r) ועוד כל מיני סיסמאות. אם השרת נמצא עם סיסמא כזו, הסקריפט יצור יוזר נוסף עם הרשאות root וידווח בחזרה למפעיל הסקריפט שיש לו עוד שרת פתוח לשימושו. אותו דבר קורה עם פורטים כמו 25 (SMTP), ועוד פורטים.

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

אבל רוב הפריצות אינן פריצות פורטים, אלא פריצת אפליקציות.

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

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

אז מה ספק אחסון טוב צריך שיהיה וצריך לעשות? כמה דברים:

  1. הטמעת חומת אש רצינית עם חוקים קשיחים: סיסקו, צ'ק-פוינט, פורטינט, ג'וניפר – כולם מייצרים קופסאות חומות אש מספיק רציניות כדי להגן על משתמשים. ספק רציני יודע לקחת קופסא כזו ולהגדיר מי יכול להיכנס ברזולוציה של כתובת IP, איזה פורטים לפתוח עבור הלקוח ואיזה פורטים לסגור. ספק רציני גם יתקין ללקוח חומת אש פנימית עם חסימת פורטים פנימה והחוצה לפי הצורך.
  2. לא לאפשר לעובדים שלו להיכנס למערכות של הספק עם סיסמאות אלא עם מפתחות הצפנה בלבד וכל כניסה נרשמת ומתועדת.
  3. ספק טוב מפריד לחלוטין בין רשת השרתים של הלקוחות לרשת שלו עצמו. כך לדוגמא כל עניין ניהול הלקוחות, פרטי הלקוחות, סיסמאות וכו' צריכים לשבת ברשת נפרדת, עם גישה מאוד מפוקחת לסקריפט ששולף נתונים ועדיף שהנתונים יועברו בהצפנה. (אצלנו לדוגמא כל רישום הלקוחות נמצא בכלל בעיר אחרת אצל ספק אחר).
  4. אם מדובר בספק שסולק כרטיסי אשראי, אז הספק צריך להקים רשת פיזית אחרת (לא להסתפק במכונה וירטואלית וחיבור VLAN נפרד) ולהציג אישור שעבר PCI (שימו לב: ישנו סולק שלא אציין את שמו שמציג לוגו של PCI באתר שלו אך הוא לא עבר PCI ולכן חשוב לבקש לראות הוכחה שהספק עבר תקן PCI ושהתעודה מראה את השנה הקלנדרית הנוכחית (בדיקת תקינות ל-PCI צריך לעבור כל שנה).
  5. ספק טוב שומר בשרתי אחסון שיתופי שלו לפחות חודש רישומים של כניסות לשרת הן דרך WEB וגם SSH, רישומים אלו אמורים להישמר בגיבוי.
  6. עדכונים – כל השרתים (למעט VPS שאינם מנוהלים על ידי הספק) צריכים להיות אחת לשבוע מעודכנים בכל הטלאים האחרונים שיצאו לאותה הפצה.
  7. פאנלים – חובה שיהיו מעודכנים לגירסה האחרונה.

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

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

ועוד משהו אחד: בחשבון משותף עם גישת SSH אפשר לבדוק את חלק מהדברים. לדוגמא אם תקישו את הפקודה uname -a תוכלו לראות שגירסת הליבה (אם זו מערכת CentOS מעודכנת) היא 2.6.18-274 (לקוחות שלנו יראו 374, הוספנו כמה דברים לליבה). אם המספר פחות מ-274, זה אומר שהשרת אינו מעודכן, ובמקרים כאלו אתם חשופים לחורי אבטחה.

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

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

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

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

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

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

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

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

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

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

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

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