על בעיה 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 רגילה ניתן למנוע התקפות שונות.