עדכונים בנושאי וירטואליזציה ו-VDI

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

אתחיל בנושא VDI.

תודות לחברת CRG שהשאילה לי כרטיס AMD S7150 לצרכי בדיקות VDI – התחלתי לבדוק את הנושא. לצערי הכרטיס הזה לא ממש עובד על מעבדי Xeon ישנים (סידרה V1-V2). הזמנתי לוחות אם של Supermicro יד שניה מסוחר ישראלי ו… גיליתי להפתעתי שהלוחות פגומים (פגומים במובן שכאילו מישהו העביר פטיש על תושבות המעבדים ועיקם את רוב הפינים!). מכיוון ששילמתי ב-Paypal, הצלחתי להחזיר את הלוחות ולקבל את הכסף בחזרה, כך שלא יכלתי להתקדם הרבה עם הכרטיס והחלטתי להחזיר אותו ל-CRG.

לא הרמתי ידיים, החלטתי לבצע בדיקות סימולציות משתמשי דסקטופ (כלי מצוין לכך: LoginVSI, יש גירסת התנסות בחינם) במובנים הבסיסיים לצרכי רואה חשבון ועורכי דין שמדי פעם גם צופים פה ושם בוידאו. התברר לי שכשמדובר בכמות קטנה (5-8 תחנות) של משתמשים, ואם משתמשים ב-RDP בלבד – לא יהיה צורך בכרטיס GPU לצרכי VDI. המעבדים בשרת מודרני יכולים לעמוד יפה בעומס. (אני ביצעתי את הניסויים על מעבד דסקטופ AMD Ryzen 7 2700X, כך שמעבדי Xeon יכולים לעשות זאת בקלות).

מכאן נעבור לברזלים: אני ממליץ על שרת בתצורת TOWER מהסיבה הפשוטה שלרבים אין מקום להכניס שרת 1U/2U רגילים מבלי לרכוש ארון תקשורת בעומק 80 ס"מ, מה גם שהוא מרעיש. שרת במארז Tower בדרך כלל הרבה יותר שקט והאיוורור בו הרבה יותר טוב ויעיל.

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

מבחינת תקשורת: אני ממליץ  חיבור 10 ג'יגהביט בין השרת ל-Switch (לרוב המתגים יש Uplink של 10 ג'יגה בחיבור +SFP) – אם כל המשתמשים צופים בוידאו – קידוד ה-RDP + קידוד H.264 + תעבורה של הדסקטופ לוקחים לא מעט.

אסכם את הנושא כך: עם ESXI חינמי, עם מכונה בתצורת Tower שכוללת 2 מעבדים של 8 ליבות כל אחד, 128 ג'יגהבייט זכרון, דיסקים מקומיים, NAS של Synology ומתג נורמלי – אפשר לייצר "סביבת VDI". הפתרון, כמובן, לא VDI כמו Horizon או Terminal Services והוא גם לא מתיימר לכך, הוא בסך הכל נועד להעביר כמות קטנה של מכונות פיזיות ישנות ולהמירן ל-VM ולעבוד עליהן. אם מדובר על עשרות של מכונות פיזיות וכו' – אז כדאי בהחלט לחשוב על פתרון VDI מלא.

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

ומכאן – לוירטואליזציה (אצלי לפחות): עד היום עבדתי הן עם KVM והן עם oVirt/RHV (שמבוסס על KVM). ברמת המאקרו – הפתרון הזה הוא פתרון מעולה לוירטואליזציה, אבל ברמת המיקרו, יש כמה באגים וחוסרים קטנים שיכולים לשגע פילים: נסיון הוספה של Nodes שאינם מבוססים על מעבדי Intel מפיל את התהליך, כי התהליך לא יודע לזהות מעבדים אחרים ויש צורך להגדיר הכל ידנית ועוד כל מיני דברים קטנים. אפשר כמובן לדווח על באגים, אולם כל עוד אינך לקוח משלם – אולי תזכה ליחס ואולי לא. מכיוון שאני צריך להריץ על מספר מכונות כאשכולות, אני צריך פתרון רציני ולכן אני חוזר ל-vSphere, עם כל הצער שבכך.

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

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

סקירה: מיקרו שרת של HPE דור 10

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

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

נתחיל במפרט הטכני:

  • מעבדים – AMD Opteron (קיימים 3 דגמים: X3216, X3418, X3421). הדגם שמיובא לארץ הוא הדגם הנמוך עם מעבד X3216 עם 2 ליבות, 1 מגה זכרון מטמון, APU מובנה, ומבחינת כח – הוא הכי נמוך עם הספק של 12-15 וואט). שאר הדגמים הם עם 4 ליבות, 2 מגה זכרון מטמון, כח גרפי מעט יותר חזק, והספק של 12-35 וואט.
  • זכרון – עד 32 ג'יגהבייט (ECC).
  • אחסון: 4 דיסקים קשיחים בגודל 3.5 אינטש ללא תמיכה להחלפה חמה, ואפשרות להוסיף דיסק 2.5 אינטש בחיבור SATA (לצרכים של Boot או Cache עם SSD).
  • חיבור PCIe: ישנם 2 תושבות, הראשונה היא PCIe X8 והשניה היא PCIe X1 בחיבור של PCIe X4.
  • חיבורי רשת – 2 חיבורים של 1 ג'יגה עם LOM
  • חיבורי תצוגה – 2 חיבורי Display Port כולל תמיכה ברזולוציית 4K.
  • חיבורי USB – כ-2 חיבורי USB 2.0 ו-2 חיבורי USB 3.0.

נתחיל בקהל היעד: קהל היעד למכונה זו (בשימוש כ-NAS) הם אלו שמעוניינים ליצור לעצמם גיבויים – הן מבחינת תכנים שקיימים להם, גיבוי מכונות Windows או לינוקס. HPE רשמית ממליצה על מערכת הפעלה ClearOS שמתאימה ל-SMB/SOHO אבל כמובן כל מערכת הפעלה מודרנית תרוץ ללא בעיות על מכונה כזו. (שימו לב: המערכות שנמכרות בארץ עם X3216 יהיו איטיות בהרבה מ-2 האופציות האחרות ש-HPE מוכרת ולכן לא כדאי "להשתולל" עם התקנת שרותים רבים על המכונה).

למי שמעוניין להקים LAB קטן לעצמו ורוצה את המכונה הזו כשרת NFS או iSCSI או SMB/CIFS – כדאי שיקח בחשבון שהביצועים שהמערכת שנמכרת בארץ, מנפיקה ביצועים די איטיים, כך שאם אתה רוצה להרים מספר דו ספרתי של VM, אולי עדיף שתחפש פתרון אחר או … תצטייד בסבלנות (או שתכניס כרטיסי 10 ג'יגהביט ו-SSD ל-NAS וכרטיסי 10 ג'יגה לשרתים האחרים שלך).

מבחינת המעבד עצמו, HPE ו-AMD עשו בסופו של דבר עיסקה לא רעה בכלל: ל-AMD יש מלאי רציני של מעבדי Opteron ישנים שהם רוצים להיפטר מהם (לטובת ה-Ryzen V1000 ו-EPYC Embedded), ו-HP חיפשו מעבדים לשרתים בקצה הנמוך מאוד ובמחיר זול מאוד. AMD, לפי השמועות, מוכרים את המעבדים בכחמישית מהמחיר שאינטל מבקשת על אותו מפרט וה-Opteron (לפחות ה-X3421) נותן פייט די רציני למעבדי ה-Atom C3000 של אינטל. התוצאה: הלקוח מקבל מכונה עם ביצועים די מכובדים כ-NAS (שוב, לא הגירסה שנמכרת בארץ) במחיר מאוד נמוך של כמה מאות דולרים. אגב, אחד השימושים הכי מעניינים שיצא לי לשמוע עליו בשימוש מכונות כאלו, אגב, הם מקומות עם תקציב די קטן שמריצים קונטיינרים. לפחות מ-2 מקומות (בחו"ל) שמעתי שהם מרוצים מהתוצאות.

מבחינתי, הבעיה המרכזית במכונות הללו היא התכנון שלהם. ב-HPE יכלו לדוגמא לוותר על יציאת Display Port אחת ולהחליף את חיבורי הרשת הקבועים בחיבור של מודול, כך שהלקוח היה יכול להחליף בין 2 חיבורי 1 ג'יגה ל-2 חיבורי 10 ג'יגה, ובנוסף הם יכלו להוסיף ללוח האם כניסת M.2 PCIe X4. הוספת 2 הדברים הללו היו יכולים לשדרג מכונה כזו לביצועי NAS מכובדים מאוד, לשמש כ-Storage למספר קטן של מכונות פיזיות המריצות וירטואליזציה ועוד, אבל כנראה ש-HPE מעדיפים שאם אתה רוצה משהו עם ביצועים קצת יותר גבוהים – תכיר את המכונות שלנו שמבוססות Xeon SP או AMD EPYC – שהן כמובן הרבה הרבה יותר יקרות.

לסיכום: האם הייתי ממליץ לאחרים לרכוש את המכונה הזו? כן, אם הצרכים שלהם הם מה שציינתי לעיל. אם הם צריכים משהו יותר חזק, אז עדיף שיחפשו את הגירסה עם מעבד X3421 או שיחפש פתרון NAS אחר או שיבנה לעצמו NAS. אישית, אני מקווה בזמן הקרוב לבחון לוח אם חדש (שעדיין לא יצא – מחברת ASRock Rack) המבוסס על מעבד EPYC Embedded ושתומך בהרבה יותר דיסקים קשיחים, יש בו כניסת M.2, תושבת PCIe X16 ו-2 כניסות 10 ג'יגהביט מובנות – ואת זה להכניס למארז 2U.

על תשתיות IT והקמת פרויקטים מבוססי לינוקס ב-Enterprise

נניח שאתם שוכרים את שרותי להקמת שרת אפליקציה לינוקסי כלשהו. לא חשוב מהי האפליקציה. סביר להניח שאקבל מכונת VM כלשהי עם הפצת לינוקס שאתם עובדים עליה. ברוב המקרים, סביר להניח שאני אצטרך חיבור אינטרנט כדי להוריד חבילות נוספות מעבר למה שקיים ב-ISO image של הפצת הלינוקס שבחרתם. לפעמים זה חבילה או 2 ולפעמים – מאות חבילות. לבקש שיורידו לי חבילה X זה לא פתרון כי לכל חבילה יש חבילות שכנות שנקראות "תלויות" (Dependencies), כך שלשם ביצוע המשימה, אני צריך את החיבור לאינטרנט, ולפעמים גם ביטול זמני של DLM ודברים כאלו שלא מאפשרים לחבילות בלינוקס לרדת.

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

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

בלינוקס, ולא חשוב איזו הפצת לינוקס, עניין החבילות שונה לחלוטין מ-Windows (אם כי ב-Windows השינויים בחבילות גם נכנסים לאט, כמו חבילות שמתקינים עם Powershell). מאגרי חבילות לדוגמא במקרים רבים לא יורדים מאיזה שרת ספציפי מסוים בחו"ל. במקרים רבים, פקודת ההורדה (yum ב-CentOS או Red Hat לדוגמא) דוגמת מהירת גישה ממספר שרתים שונים באינטרנט וגם במהלך ההורדה, אם לדוגמא חבילה מסויימת לא קיימת בשרת מסוים, ההתקנה אוטומטית "קופצת" לשרת אחר (בכתובת שונה) ומורידה את החבילות משם. אם תרצו לאחר יותר מיומיים שוב להוריד חבילות, מערכת ההתקנה שוב תדגום מהירות של מספר שרתים ויכול להיות שתבחר שרת mirror אחר כדי להוריד, כך שפתיחה ב-Firewall לכתובת URL אחת לא תסייע, מה עוד שבמקרים רבים כתובת ה-URL משתנה עם redirect ואז שוב ה-Firewall חוסם.

אז כן, הפצות לינוקס ו-Firewall בכל הקשור להתקנת חבילות – הם לא החברים הכי טובים.

מה ניתן לעשות?

ההמלצה שלי לחברות גדולות זה להקים שרת (אפשר גם שרת ישן וגם דסקטופ עם מעבד i3 יספיק עם 4 ג'יגהבייט זכרון, כל עוד מדובר על עשרות מכונות VM שיקבלו את החבילות) עם 2-3 דיסקים גדולים (SATA פשוטים של 4-8 טרהבייט, לא צריך Enterprise) ב-RAID 1 ועם 2 חיבורי רשת, רגל אחת תהיה מחוברת החוצה ורגל אחת פנימה. השרת שנקים יהיה בעצם שרת Mirror פנימי לחברה עצמה, ובשרת נריץ מספר סקריפטים שיתחברו אחת ליום לכל מיני מאגרי חבילות ויקבלו את כל החבילות של אותה הפצת לינוקס לגרסאותיה השונות. השרת מתעדכן מדי יום (לעיתים פעמיים ביום) בחבילות וכל החבילות של ההפצות יורדות ומסונכרנות עם שרת Mirror אחר או שרת Master.

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

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

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

מבוך מבלבל בהבטחות

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

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

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

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

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

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

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

בהצלחה

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

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

נבדיל בין 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 ועוד. כך אתה יכול להגן על עצמך בצורה הכי טובה ובתקציב נמוך.