קצת לפני שמכריזים על זוכה במכרז

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

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

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

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

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

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

  • לא לרכוש את השרות כ-SAAS (שימו לב: אני לא מדבר על מחיר). כשספק ענן ציבורי מציע שרות כ-SAAS, אתם יודעים שאותו ספק יהיה קיים ב-3-5 השנים הקרובות ולכן שרותי ענן שונים בתצורת SAAS אין בעיה לשכור אותם, אולם כשחברה בונה לך פתרון ומנגישה לך אותו כ-SAAS, אותה משרד/חברה מכניסה את עצמה למצב של "בת ערובה" אם בהמשך אין הסכמה על מחירים, או אם המשרד/גוף לא מרוצים מהביצועים, לדוגמא.
    אני רוצה לסייג: אם אתם צריכים לרכוש Firewall או כל אפליקציה שכוללת OS לינוקסאי דרך ה-Market של ספק הענן זה בסדר, אבל אם זה משהו שמפותח עבורכם – בקשו שיתקינו את הדברים על התשתית הוירטואלית שלכם, מקומית או בחשבון ענן שלכם.
  • על מה זה רץ? ברוב המקרים כיום הפיתוח של פתרון עבורכם יבוצע תוך שימוש בפלטרפורמה כזו או אחרת. חשוב מאוד לבדוק איזו פלטפורמה ואיזו גירסה, האם יש בה שימוש כיום, האם יש קליפים או עדויות לגבי אותה פלטפורמה? מתי עדכנו אותה לאחרונה? הדבר האחרון שאתם רוצים זה שספק מציע ישתמש במשהו ישן שכבר כמעט מת – בשביל לבנות עבורכם את מה שהנכם מבקשים.
  • חישובי ענן ציבורי. אם השרות שאתם רוצים צריך לרוץ על ספק ענן ציבורי, עדיף שהחברה/גוף המבקש הצעות יבקש הקמה על התשתית בחשבון הענן שלו ועדיף לבדוק היטב מה יש בסעיפי התמיכה. כך לדוגמא, רבים כשעוברים לענן מחפשים לקחת את שרותי התמיכה היקרים ביותר (24/7 פלטינום או כל שם אחר) מבלי להבין שבמקרה ויש תקלה והיא קיימת לא רק בחשבון החברה אלא גם אצל אחרים – לא תקבלו שרות יותר מהיר ותצטרכו לחכות לפתרון התקלה כמו כולם.
  • אם כבר מדברים על חישובי ענן ציבורי: שרותים. ספקי ענן ציבורי מציעים שרותים שונים שהם אבולוציוניים, כלומר – בהתחלה הוצעה שרות בשם X, לאחר זמן מה הוצע שרות Y שהוא בעצם "אבולוציה" של שרות X וכו'. במקרים רבים יש גם הפרשי מחיר ניכרים בין השרותים וגם הבדלי ביצועים רציניים, אך הבעיה היא שמציעים גדולים לא ממש טורחים (לא ממש באשמתם כש-AWS מציעים כמעט כל יום שרותים חדשים) להכיר את השרותים השונים ולכן כדאי לראות מה יש בהצעה ולהחליף בשרותים מודרניים יותר או במקרים מסוימים אם יש את הידע – להקים את הדברים עצמאית בתשתית הענן.
  • גישה לקוד מקור ותיעודו: כיום כשמפתחים לענן ציבורי ומשתמשים בפלטפורמות/ספריות שונות, ברוב המקרים הקוד עצמו פתוח וזמין וכדאי להחיל זאת גם לדברים שמפותחים עבור משרדים/גופים/חברות – המציע הולך לפתח עבורך משהו? דרוש את קוד המקור ותיעוד API ודברים שונים ששונו.
  • אבטחה: תמיד חשוב לזכור – ענן ציבורי נותן אפס אבטחה. אפשר לשכור שרותים שונים ולבצע הגדרות שונות כדי לקבל אבטחה ברמה טובה, אבל זה לא מגיע כברירת מחדל ולא בחינם. כדאי שגוף חיצוני (לא מטעם המציע) יבדוק את המערכת, ואם יש תקציב – לבצע Code Auditing.

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

בקשר למחירי שרתים

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

בסופו של דבר מישהו מאותה חברה יצר קשר עם עבדכם הנאמן. אני שאלתי רק שאלה אחת: האם במקרה המעבד הוא Xeon מהסידרה Silver, Gold או Platinum? התשובה היתה חיובית. הסברתי לבחור שלצערי ב-2 הדורות האחרונים של Xeon Scalable באינטל פשוט התעצלו לבנות מנגנון אחיזה (Retension) רציני למעבד והפעם צריך להסתדר עם ברגים בלבד, כאשר אם יש תנועה של אפילו חצי מילימטר – מקבלים את התופעות שהם מקבלים, ובקיצור – צריך לחזור לשולחן התכנונים, לחשוב על מעבד אחר ולשנות עוד כמה דברים.

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

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

נניח לשם הדוגמא שבמקום אותה חברה לעיל, פונה חברת משאיות אמריקאית שמבקשת ממני לבנות מערכת כזו. לאחר שתכננתי ובניתי את ה-POC, הייתי יכול להיכנס לאתר של אחד מיצרניות השרתים, לבצע custom ובסופו של דבר האתר מציג לי מחיר רשמי, גם אם ה-fulfillment יבוצע ע"י חברות אחרות כמו CDW – המחיר שמופיע זה מה שאני צריך רשמית לשלם. אני כמובן מכאן יכול ליצור קשר ולהוריד את המחיר אם מדובר בכמות שרתים, או בגלל דברים אחרים שאני רוצה מאותה חברה ובתנאי שמחיר הברזלים ירד. הדבר החשוב ביותר לי: יש לי מחיר התחלה לשם מו"מ.

בישראל לעומת זאת, ככל שזה מגיע לשרתים, מחשבים אישיים וכו' – אין חיה כזו. שום יבואן רשמי לא מוכן לפרסם את המחיר הרשמי ללקוח הסופי. אני יכול לפנות לדוגמא ל CData, One, CDLog, הראל ואחרים ולקבל עבור אותו מפרט הצעות מחיר שונות (וכמובן בדרך לחכות בין יומיים לחודש וחצי להצעת מחיר!) עם הבדלים של אלפי (או עשרות אלפי – תלוי במפרט) שקלים בין הצעה אחת לאחרת. במילים אחרות: אם לדוגמא שרת DELL עם מפרט משלי עולה בארה"ב 10,000 דולר ובארץ אותו שרת עם אותו מפרט היה עולה 17,000 דולר מחיר רשמי, לא תהיה לי בעיה עם זה (זה לא אני זה שמשלם את המחיר, זה הלקוח), אבל כשאני רואה שתי הצעות מחיר שונות עם הבדל של 6000 שקל לדוגמא, אני פשוט תוהה – על מה ההבדל? על זה שנציג מכירות הוציא כמה אימיילים וישב 5 דקות מול אקסל? (כי למעט המשלוח השרת ללקוח וההתקנה הסופר ראשונית – הכל נעשה ע"י היצרן בכלל).

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

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

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