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

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

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

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

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

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

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

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

ה"משחק באש" שאני מדבר עליו, אם מסתכלים על הפתרונות המוצעים כ-Image או כברזל, היא לאו דווקא התוכנה שאותה חברה כתבה, אלא הפלטפורמה או הספריות שהתוכנה משתמשת (ושאותם החברה לא כתבה). מה תעשה אותה חברת יצרנית התוכנה אם מתגלה באג קריטי בפלטפורמה או באחת מהספריות ואין עדיין תיקון לאותו באג? אפשר לפנות לאתר המארח את ה-REPO של אותה תוכנה/פלטפורמה (נניח Github) ולפתוח issue, וכאן נמצאת הבעיה הכי גדולה: אין אפשרות לדעת אם יתייחסו, אם יתקנו ומתי מישהו יתקן את הבאג. יכול להיות שבאג מאוד קריטי יתוקן במהירה, אבל באגים אחרים – יקח זמן עד שיתקנו זאת, והלקוחות של המוצר הסופי לא ממש אוהבים זאת.

אני רוצה לתת דוגמא מעולם ה-appliance שאני בונה ללקוחות לפעמים. לקוח פוטנציאלי פונה אליי, מציין שהם מפתחים תוכנה XYZ והם מעוניינים שאפתח להם פתרון "סגור" – כלומר קופסא (או Image, או שניהם) שיריצו את התוכנה, שהפתרון שלי יכלול הפצת לינוקס מינימלית כולל כל מה שהם צריכים, סקריפטים לעדכון (אוטומטי או ידני), ותמיכה מלאה בכל הפונקציונאליות של הקופסא (מספר חיבורי רשת, SNMP וכו').

בדרך כלל ההסכם שלי מול חברות כאלו הוא פשוט:

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

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

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

לפני רכישה – כדאי לחשוב קדימה

כאן בארץ, לא חסרים ארגונים ועסקים שההתמחות שלהם היא בשיווק מוצרים לעסקים וחברות בכל מה שקשור ל-IT – בין אם מדובר בתוכנה, חומרה, שרותי אינטגרציה, תמיכה וכו'. זה הביזנס שלהם ומרביתם יכולים למכור לך כמעט כל מה שתרצה – בין אם זה כונן דיסקטים 5.25" ועד Mainframe – כולל שילוב ואינטגרציה של מה שהם מוכרים. לגטימי? בהחלט.

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

המקרה הראשון התרחש לפני מס' חודשים: קורא נאמן של הבלוג פנה אל עבדכם הנאמן בשאלה פשוטה: החברה הגדולה שהוא עובד שם מתכננים לרכוש 4 דיסקים Optane של אינטל מסוג P4800X דרך יצרן השרתים של החברה. הסיבה לרכישת הדיסקים האלו? מצגת שהראתה להם שבביצועי SQL – הדיסקים הללו יהיו מעולים לצרכיהם, הרבה יותר מכל סטורג' שהם יחברו (בקטע הזה המצגת צודקת. דגם ה-Optane הזה בהחלט מתאים ונותן ביצועים מטורפים!). הדיסקים האלו יכנסו לתוך שרת R740 של DELL, ימופו לתוך VM שיריץ שרת Windows Server 2016 ו-SQL Server. אמרתי לו שלדעתי תהיה בעיית ביצועים, אבל אם הם מעוניינים, אשמח לבדוק להם את העניין – בתשלום. החברה הסכימה. (בכל זאת, 2500$ פר SSD, כלומר $10000 דולר במחירי ארה"ב…)

תודות לכמה יבואנים הצלחתי להשיג את הציוד להשאלה אליי ל-LAB. השרת פורק, חיברתי את ה-backplane עם כניסות U.2, הצמדתי לדיסקים חיישני חום, הפעלתי והתחלתי להריץ בדיקות עומסים שונים. לקח 10 דקות עד שאחד ה-SSD הגיע ל-95 מעלות חום. כמה דקות אחרי זה שאר ה-SSD הגיעו בערך לאותו חום – והביצועים החלו לצלול. סיכום הדו"ח שלי ללקוח הצביע על הבעיה הפשוטה: הן שרתי ה-R740 (וגם כל שרת 2U של HPE או לנובו לצורך העניין) אינם מתאימים בתצורה זו ל-SSD מבוסס Optane של אינטל. הדיסקים הללו מפיקים הרבה יותר חום מדיסקים מכניים או SSD מתחרים. הדרך היחידה להכניס 4 כרטיסים כאלו היא לרכוש 4 SSD כאלו בתצורת AIC (כלומר כרטיס PCIe) ואז למפות אותם. עדיף במקום שרת 2U להשתמש בשרת 3U (אבל אז גם מחיר השרת מטפס הואיל ומה ש-DELL מוכרת בגירסת 3U זה שרת עם 4 מעבדים).

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

  • אבטחה – עם כל הכבוד ל-Kubernetes, הפלטפורמה עדיין אינה מאובטחת כמו OpenShift (תודות ל-SELinux ועוד מספר רכיבים).
  • Auditing, Compliance – בחברות גדולות ומשרדים ממשלתיים מאוד רוצים את זה.
  • מיגרציה בהמשך – תחשבו 4 שנים קדימה, אם Kubernetes עדיין תהיה קיימת, יהיה קשה מאוד להעביר אליה דברים שבנינו השנה לגירסה שתצא אז. במוצר כמו OpenShift היצרן מציע כלים לבצע מיגרציה.

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

המקרה השלישי קשור יותר ל"התלהבות" הולכת וגודלת לכל ה-Hyper Converge בוירטואליזציה (למי שלא מכיר: מערכות כמו vSAN, Simplivity, Nutanix מציעות להקים שרתים שיתנו את כל השרותים הכוללים Storage, Network, Compute – ללא צורך בסטורג' מאסיבי, סוויצ'ים יקרים וכו').

כמו תמיד, חברות כמו VMWare ואחרות לא המציאו מאפס את עניין ה-Scale Out הזה. מערכות File System ל-Scale Out קיימות זמן רב, כמו Lustre FS, מערכת Open Vswitch לצרכי Network, ופתרונות וירטואליזציה שונים הציעו זאת בסביבת HPC כבר זמן רב.  החולשה שיש ב-HPC קיימת בדיוק אותו דבר גם בפתרונות וירטואליזציה Scale Out: אם אתה צריך כמות IOPS מאסיבית של 7 ספרות ומעלה, תצטרך או לרכוש סטורג' יעודי או לרכוש הרבה יותר שרתים פיזיים מכפי שאתה צריך עבור Compute. אם אין לך צרכים כאלו, אז כן, פתרון Hyper Converge יכול להיות פתרון טוב.

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

על בעיה X ופתרון Y

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

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

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

  • מה הפונקציונאליות שהוא מחפש
  • מה הפונקציונאליות שמאוד חשובה לו, ומה הפונקציונאליות שבשבילו זה יהיה "נחמד" אם קיים אך אותה פונקציונאליות אינה קריטית.
  • האם הוא מחפש פתרון Scale Up או Scale Out
  • האם הוא מחפש פתרון שישולב כ-Hyper Converge או שהוא מחפש פתרון של ברזלים נפרדים
  • ויש עוד לא מעט שאלות…

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

  • אינטגריטי – אם מישהו יבוא אליי ויבקש לדוגמא פתרון סטורג' Scale Out והדבר הכי חשוב לו זה iSCSI לדוגמא, אז אני אומר לו בפשטות שכרגע אין פתרון Scale Out בקוד פתוח (גם כמוצר מסחרי) שיש לו פתרון iSCSI ל-Scale Out בצורה טובה והוא יצטרך פתרון קנייני.
  • על מה הפתרון אמור לענות? לקוח רוצה X על מנת לפתור את בעיית Y. נעזוב לרגע את X, ונשמע מהלקוח מהו אותו Y. אין ספק, דרישותיו של הלקוח הן חשובות, אולם ברגע שמספרים לי מהו אותו Y, אז ניתן להעלות מספר פתרונות שיכולים לענות על Y וגם להתחשב בצרכי הלקוח.
    לדוגמא: ללקוח יש 20 מכונות VM שמשמשות לפיתוח והלקוח רוצה פתרון סטורג' עבורם Scale Up. במקרה כזה אני יכול להציע לדוגמא פתרונות מבוססים ZFS, בין אם כקוד פתוח נטו או מוצרים מסחריים ובהצעה שאגיש לו יוסבר מדוע הפתרון הזה טוב ויוצעו ללקוח מספר פתרונות מבוססים ZFS, כך שבסופו של דבר ה-Y הם אותם 20 מכונות VM וה-X יהיה פתרון מבוסס ZFS.

וכאן בעצם מגיעה השאלה המרכזית שלי…

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

ההבדל העצום בין VPS אמיתי ל-VPS “כאילו”

היום ב-6 בבוקר קיבלתי צלצול מ-חבר שיש לו VPS אצל ספק ידוע בחו”ל. הבעיה? כל החומר שלו נעלם וגם כששיחזרו לו את החומר והוא לא מפעיל את האתר – מישהו מצליח להיכנס ולמחוק לו את התוכן. לאחר שבדקתי קצת את המערכת, הצלחתי להבין שהפריצה לא מגיעה מהחשבון של אותו בחור, אלא שמישהו מצליח להיכנס דרך חור ישן בשרת Apache והצליח ליצור יוזר, לעשות אסקלציית הרשאות ל-root ואותו פורץ יכול להיכנס לכל חשבון באותו שרת ולעשות כרצונו.

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

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

המושג VPS “נמתח” על ידי כל מיני ספקים לכאן ולכאן, וחלק מאותה “מתיחה” היא בעצם מתיחה, בלוף. כאשר ספק כמו Dreamhost מציע VPS, אותה הצעה היא לא יותר מאשר אחסון משותף עם Shell. אומרים לך שיש לך root access אבל אין לך באמת גישת root. נסה להתקין חבילות RPM או DEB על הפצת הלינוקס שם ותמצא מהר מאוד שהמערכת לא מאפשרת לך זאת. אותו root כביכול שיש לך מוגבל אך ורק לתיקיה שלך, אתה לא יכול להגיע לתיקיות בתוך var/ (שם מאוחסנים קבצי ה-RPM וה-DB של כל החבילות), וזה בדיוק המצב בחבילת אחסון משותפת, רק ששם לא עובדים עליך עם root מזויף.

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

חברות רבות מציעות בארה”ב ובאירופה VPS בזול, כי הם רוכשים Virtuozzo ואז מקבלים פאנל ללקוחות בחינם, אבל ה”זול” הזה הוא בדיוק הדבר שיכול לעלות לך ביוקר, במיוחד שיש צורך להתקין עדכוני מערכת דחופים וספקים לא עושים זאת כי יש צורך ב-Reboot של השרתים הפיזיים וזה הדבר האחרון שהם מחפשים לעשות, אז דוחים ואז מגיעים פורצים שמנסים לפרוץ עם אותם חורים – ואז יש “שמחה וששון” ובעברית – הבלאגן מתחיל.

לכן, כאשר מסתכלים על חבילות שרתי VPS, חשוב מאוד לבדוק מהי הוירטואליזציה שרצה שם. אם הנציג אומר SolusVM, OpenVZ, Virtuozzo או Proxmoxx (עם OpenVZ כוירטואליזציה) מומלץ לחפש ספק אחר. זו שיטת וירטואליזציה ישנה שגם לא תמיד תואמת אפליקציות, עם אבטחה גרועה, וחוסר אפשרות הפרדת ביצועים בין לקוח אחד למישנהו (ובעברית: כשלקוח אחד מנצל 100% מעבד, השאר סובלים).

אלו וירטואליזציות כן מומלצות? Xen, KVM, או VMWare. כל הוירטואליזציות הנ”ל בנויות עם לקחים מהוירטואליזציות הקודמות, והן הרבה יותר מתקדמות. איזו וירטואליזציה לא הזכרתי? Hyper-V של מיקרוסופט. הסיבה? הוירטואליזציה א-י-ט-י-ת בהשוואה לשלושת הפתרונות הנ”ל.

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

על שרתים וירטואליים (VPS) והתקפות

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

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

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

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

מצב ממש לא נעים.

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

התקפות קטנות (מאות עד אלפים בודדים)

  • אתם רואים שהשרת שלכם בקושי מגיב וכל החיבורים של שרת ה-Web שלכם תפוסים (אפשר לראות זאת בלינוקס דרך SSH עם הפקודה: server httpd status או service httpd fullstatus – ב-CentOS/RHEL/Fedora. להפצות אחרות יש שינוי קטן מבחינת פקודות). הדבר הראשון שניתן לעשות הוא לגבות את קובץ httpd.conf (אם יש לכם cPanel לדוגמא, הוא נמצא ב- usr/local/apache/conf/httpd.conf ואם זה הגירסה שמגיעה עם CentOS/RHEL/Fedora אז המקום הוא etc/httpd/conf.d/httpd.conf/) ולשנות אותו בהתאם להוראות שמופיעות כאן. שימו לב: מומלץ לאחר ההתקפה להחזיר את המצב לקדמותו. מומלץ לאחר ביצוע השינויים להתחיל את השרת עם פקודת restart ולא עם reload.
  • אם יש לך חומת אש פנימית בשרת מבוסס Linux, מומלץ להתקין חומת אש חינמית כמו CSF ואז ניתן להשתמש בהגדרות כמו שמופיעות כאן כדי להפחית ולחסום התקפות אם הן קטנות עד בינוניות (תלוי בכמות המתקיפים, גודל שרת VPS, כמות זכרון, רוחב פס וכו')
  • התקנת מודול ב-Apache שנקרא Mod_Evasive. מודול זה יודע להבין בצורה לא רעה שהשרת Apache מותקף והוא יודע לנהוג בהתאם. מומלץ לקרוא את ההוראות איתו (למשתמשי cPanel החיים קלים, פשוט תעקבו אחרי ההוראות כאן).
  • ניתן באמצעות פקודה כמו הפקודה בשורה הבאה כדי לקבל מעין טבלה עם 2 קבוצות מספרים. מצד שמאל יהיה בסדר עולה כמות הבקשות ומצד ימין כתובת ה-IP ששולחת את הבקשות לשרת שלכם. כל מה שצריך לעשות זה לכתוב חוק דינמי (עם CSF זה csf -d ip כאשר ip זו הכתובת שרוצים לחסום) לחסום את הכתובות עם הכי הרבה בקשות, רק שימו לב שלא לחסום את עצמכם בטעות אם רצות אפליקציות שלכם פנימית בשרת:
netstat -anp |grep 'tcp|udp' | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -n

 התקפות בינוניות עד מאסיביות

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

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

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

  • קובץ robots.txt שיודיע לגוגל לא לסרוק בכלל את האתר שלך ( /  :Disallow ). הדבר האחרון שאתה רוצה שגוגל יאנדקס את הדף בסעיף הבא. (מקדמי אתרים אינם ממליצים זאת).
  • שינוי קובץ httpd.conf בשרת ה-Apache לפי ההוראות מעלה
  • קובץ index.html (לא PHP ולא בשום שפה אחרת שמכריחה את השרת Apache/NGINX לפנות למודולים שונים כדי ליצור את הקובץ) ובו יהיה הסבר קצרצר על כך שיש התקפה נגדך, ולינק ל-VPS השני שלך (בלי redirect, בלי קוד 301, בלי הפניה אוטומטית, אתה לא רוצה לקחת את ההתקפה איתך ל-VPS השני). כך הלקוח עדיין יוכל לקבל ממך שרות.

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

ישנם גם פתרונות אחרים נגד התקפות DDoS ו-DoS הכוללים קופסאות שבעצם יודעות לנטר את הרשת ולהבחין בנקל בהתקפה ו"להרוג" חלק לא קטן ממנה, אבל כל קופסא כזו עולה בסביבות ה-10,000 דולר ומעלה (כמו של IntruGuard). יש גם פתרונות מבוססי מכונות וירטואליות כמו של Sophos אבל במקרים רבים הם פתרונות ברמה של ספק קטן או ללקוח שיש לו כמה שרתים. בכל מקרה, כיום גם עם מכונת Linux רגילה ניתן למנוע התקפות שונות.