VPS – עמוד 2 – הבלוג של חץ ביז

בחירת ספק VPS: אמזון מתאים לכולם?

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

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

השרותים של אמזון מתאימים מאוד לחברות תוכנה שמציעות שרותים למשתמשים רבים מאוד ברשת, ושיש ברשותם מתכנתים שיכולים להשתמש ב-API של אמזון כדי להקים ולהרוג מכונות, להשתמש בשרות ה-Load Balancing, ב-S3 וב-Storage שלהם. באתר של אמזון ניתן למצוא מגוון מדריכים לשימוש בשפות שונות כדי להשתמש ב-API, יש קהילה ערה שדנה בכל נושא, וחברות רבות ומפורסמות (כמו Twitter ואחרות) משתמשות בשרותים אלו.

אך האם הפתרונות של אמזון מתאימים לכל אחד שמעוניין בשרת VPS? לאו דווקא.

אתן לכם דוגמא אישית פשוטה: לעבדכם הנאמן יש שרת VPS באמזון (חבילת ה-Micro) שמשמש אך ורק כשרת DNS משני (Slave) ו-rsync פשוט לשמירת ה-Zones. אין בשרת שום שרות אחר שרץ. אמזון מציעים את השרות חינם בשנה ראשונה וזו השנה השניה שאני משתמש בשרות הזה. נכון לחודש זה, החשבונית שקיבלתי מאמזון על שרת זה: 19 דולר וקצת עודף.

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

אבל האם עדיין לי, כאדם פרטי עם שרת VPS בודד, שווה לקחת את ההצעה הזו?

לא תמיד.

הנה מספר סיטואציות שיכולות לקרות לכל אחד:

שינית הרשאות קבצים ותיקיות "ביד נדיבה" (בלינוקס לדוגמא עם פרמטר כוכבית או R-)
הכנסת Kernel חדש למערכת אולם ביצעת שינוי "מינורי" ב-GRUB והשינוי היה שגוי
מודול מסויים נופל ומפיל דברים אחרים, מה שלא מאפשר לך לבצע SSH.
(תקלה מוכרת שחוזרת במקרים רבים): ישנו שיבוש ברמת ה-File system והמערכת ממתינה שתכניס סיסמא
כל תקלה אחרת שמונעת מהמערכת לסיים את ה-Boot
שינוי הגדרות רשת וכתוצאה מכך הרשת אינה עולה ב-VPS
במקרה של Windows – תקלת STOP

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

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

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

טכנולוגיות וירטואליזציה מבוססות מעבד

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

כשזה מגיע לרכישת מחשב אישי, חשוב מאוד לפני שרוכשים לבדוק האם במעבד שיהיה במחשב החדש ישנה תמיכת וירטואליזציה. אינטל קוראים לזה Intel-VT ו-AMD קוראים לזה AMD-V. רבים נוטים לחשוב כי אם הטכנולוגיה ותיקה (היא קיימת משנת 2005), היא נמצאת על כל מעבד חדש שיוצר לאחרונה, אולם אין הדבר כך. אדרבא, במקרים רבים (במיוחד במעבדים של אינטל) המחיר הזול של המעבד כולל גם "הפתעה" קטנה: אין תמיכת VT במעבד, לכן כשאתם נמצאים בחנות לרכוש מחשב, בדקו איזה דגם המעבד, והריצו חיפוש בגוגל (בד"כ התוצאה הראשונה תהיה דף המפרט הטכני באתר של אינטל). כנסו לדף זה, והסתכלו כמעט בסוף הדף: האם קיימת תמיכת VT? (זה יופיע כ-Yes או No).

אם יש תמיכת VT, אז כל פתרונות הוירטואליזציה יעבדו. אם אין, רק VMWare Workstation יעבוד וגם אז במהירות מוערכת של חצי ממה שהמעבד שלכם מסוגל להנפיק. פתרונות תוכנה כמו VirtualBox, או פתרונות של מיקרוסופט (Hyper-V) לא יעבדו.

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

אם אתם הולכים לרכוש שרת שתהיה בו עבודה רבה של תקשורת (בין אם מדובר בתקשורת בין המכונות הוירטואליות בשרת עצמו או בין שרתים פיזיים אחרים), כדאי לבדוק אם המעבדים שאתם רוכשים לשרת כוללים תמיכה של VT-C, או בשם המפוצץ שאינטל נתנה לכך: Intel® Ethernet Virtualization Technology for Connectivity. טכנולוגיה זו משפרת (במקרים מסויימים במעט, במקרים מסויימים בצורה רבה) את התקשורת Ethernet.

יש עוד טכנולוגיה שנקראת VT-D (מסמך PDF). הטכנולוגיה הזו מאפשרת לעשות משהו מעניין והוא למפות כרטיס PCI אל מכונה וירטואלית. כך לדוגמא, אם אתם מריצים שרת SQL עצבני שאוכל דיסקים כאילו אין מחר, אפשר למפות אליו מערך דיסקים+כרטיס RAID, ושאר המכונות הוירטואליות יהיו מחוברות לדיסקים הרגילים שבשרת (או ל-NFS, iSCSI, NAS וכו'). היתרון העצום? מערכת ההפעלה הוירטואלית תקבל אקסלוסיביות לציוד הנ"ל מבלי שמערכות אחרות או הוירטואליזציה "תפריע באמצע".

אבל.. ל-VT-D יש בעיה קטנה הקשורה יותר להחלטות של חברות טכנולוגיה. אינטל כוללת VT-d רק בחלק קטן מהמעבדים, וגם אם יש לך במעבד תמיכת VT-d, יש סיכוי לא קטן שב-BIOS בלוח האם אין תמיכה לזה (הבעיה הזו קיימת עוד מ-2006!), כך שאם החברה שלכם חושבת להשתמש בטכנולוגיה זו, יש לבדוק עם המשווק שיש תמיכה גם במעבד וגם בלוח האם.

יש תמיכה ב-VT-d גם במעבד וגם בלוח? מצוין. עוד לא סיימנו עם הבעיות…

איזו טכנולוגיית וירטואליזציה אתה הולך להשתמש בחברה? Hyper-V של מיקרוסופט? סורי, אין תמיכה. ל-ESX/I של VMWare, ל-KVM של רד-האט, ל-Xen של Citrix יש תמיכה, אולם לעיתים היא חלקית (כמו במקרה של Xen), לכן מומלץ לבדוק לגבי הוירטואליזציה שאתה הולך להשתמש אם יש תמיכה ל-VT-d.

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

VPS בארץ או בחו"ל?

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

השאלה הראשונה שצריכה להיענות היא: מהיכן מגיעים הגולשים שלך?

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

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

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

לאירופה יש, ויש ספקים שיכולים להציע זאת… (אההממ… גם אנחנו)

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

רוחב הפס האירופאי מאפשר להעביר קבצים גדולים במהירות של עשרות ומאות מגהביט גם בלי לשלם אלפי יורו נוספים מדי חודש. לעומת זאת, קחו שרת VPS ממוצע בארה"ב ותנסו לזרוק קבצים של ג'יגות מארה"ב לאירופה, תוך שניות ספורות תראו את המהירות… או חוסר מהירות. הסיבה לכך? ספקים רבים בארה"ב מפעילים QoS ברמת הראוטר שמאיט את קצב העברת הנתונים. לא מאיטים כמו בישראל, אבל יש האטה, אפשר לראות זאת באמזון, Rackspace, Softlayer ועוד.

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

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

בהצלחה

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

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

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

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

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

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

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

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

בהצלחה

איך מגינים על שרת וירטואלי?

אנשים לוקחים לצרכיהם שרתים וירטואלים, בין אם בארץ או בחו"ל (יותר מוכר בארץ כ-שרתי VPS בחו"ל זה יותר מוכר כ-Virtual Hosting או Virtual Server) כדי להריץ על השרת כל מיני דברים, בין אם אתר בינוני עד גדול, אפליקציות וכו'. טכנולוגיית הויטוראליזציה עצמה אינה משנה לתוכן פוסט זה, בין אם זה KVM, Hyper-V, Virtuozzo, Xen, OpenVZ או VMWare.

העניין הוא שרבים לחסוך ולחתוך מחירים, ובד"כ הם מוותרים על שרותי סיסטם מצד הספק. אחרי הכל "כמה זה כבר מסובך לנהל אבטחה של Linux או Windows? יש לי כזה בבית שרץ על VMWare / VirtualBox ולא קרתה שום בעיה עם מה שאני מתקין ועושה". כך אמר לי לדוגמא אדם אחד שרצה לשכור את שרותי הפרילנס שלי לטפל ב"תקלה קטנה". מהות התקלה? שום דבר מיוחד, הוא בטעות מחק את תיקיות sbin, /bin, /usr/ והוא התפלא למה המערכת לא עולה.

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

לא לעבוד כ-root! הנה טעות שרבים עושים – מתקינים מכונת Linux (או מקבלים התקנה מוכנה מהספק) עם שם וסיסמא ומשאירים את המצב כך. חובה להגדיר משתמש רגיל ולעבוד אך ורק איתו ולא כ-root. איך עושים פעולות של root עם משתמש רגיל? אם אתה משתמש ב-CentOS אז תוכל לקרוא כאן איך להשתמש ב-sudo. בהפצות כמו אובונטו, שם המשתמש הראשון שמוגדר בעת ההתקנה יש לו הרשאות sudo.
לבטל כניסת משתמש root – סקריפטים רבים שמנסים לפרוץ לשרתים (יש המון כאלו) בודקים קודם כל אם יש כניסה למשתמש root עם כל מיני סיסמאות, ולכן מומלץ לבטל אפשרות כניסת root ע"י שינוי קובץ etc/ssh/sshd_config/ השינוי: חפש את PermitRootLogin Yes – תמצא בהתחלה סולמית (#) ליידו, מחק את הסולמית ושנה את ה-Yes ל-No, ולאחר מכן הפעל את שרות ה-ssh מחדש (פקודת: service sshd restart). הדבר אינו פוגע בכניסת משתמש root דרך הקונסולה (לא דרך SSH) אם ספק השרות נותן לך קונסולה. מומלץ באותה הזדמנות לשנות את כניסת (פורט) SSH מ-22 למשהו אחר (נניח 1340 או מספר אחר מעל 1024).
אם הינך משתמש ב-MySQL והשרת שלך הוא התקנה חדשה, הרץ (עם sudo) את פקודת mysql_secure_installation והזן את הפרטים שהתוכנה מבקשת ממך. לאחר הזנת הפרטים, המערכת תסגור כניסות ותמחק משתמשים מיותרים.
אם יש לך מספר אתרים שמתארחים על השרת, פתח לכל אחד שם משתמש וקבוצה משלו (UID, GID) והשתמש בדברים כמו mod_suphp (ניתן להתקין את זה בפקודת yum install suphp על Centos או apt-get install suphp באובונטו/Debian). כאן תוכל למצוא הוראות איך להשתמש ב-suphp עם CentOS וכאן עם דביאן/אובונטו. בשיטה זו, תוכל לראות בקלות איזה אתר משתמש במשאבים ובכמה.
תוכנות כמו Putty ב-Windows או תוכנות טרמינל במק ובלינוקס מאפשרות בקלות ליצור ולהשתמש במפתחות על מנת להיכנס (Login) לשרות. מומלץ להשתמש בשרות זה במקום סיסמאות, כך תוכל להגן על השרת שלך הרבה יותר, מכיוון שאף אחד לא יוכל לנסות לעשות Login לשרת שלך. איך עושים זאת? עוקבים אחר ההוראות כאן (ההוראות מתאימות לכל ההפצות).
אל תפתח סתם פורטים: רבים אוהבים את השימוש בתוכנות גרפיות כדי לנהל דברים כמו MySQL עם Client שמותקן על המחשב בבית ולשם כך הם פותחים את פורט 3306. זו שגיאה נפוצה כי פורצים יכולים להאזין למידע ומשם לפרוץ בקלות לשרת שלך. אם אתה רוצה כלי וובי טוב לנהל בקלות MySQL, כדאי להשתמש ב- phpmyadmin (שימו לב להגדיר את האבטחה שבו, כי גם תוכנה זו פופולרית מאוד בקרב הסקריפטים המנסים לפרוץ לשרתים).
סגור שרותים שאינך צריך: אצל ספקים שונים, הלינוקס מותקן כמו שהוא ללא שום הגדרות אבטחה מסויימות וללא ביטול שרותים שאינם נחוצים (מתי לאחרונה השתמשת בשרות Bluetooth על שרת?). ב-CentOS תוכל להשתמש בפקודה chkconfig ובדביאן/אובונטו תוכל להשתמש בפקודות שמופיעות כאן כדי להגדיר מה יפעל ומה לא. אם אינך יודע מהו כל שרות, גוגל יכול לסייע לך.
ודא כי כל הסיסמאות הן סיסמאות חזקות, הווה אומר לפחות 3 מספרים ו-5 אותיות (גדולות וקטנות) מוגדרות לכל בסיס נתונים, שם משתמש וכו'.
אל תסמוך על חומת האש של הספק! לקוחות רבים שומעים מאנשי מכירות כמה הספק השקיע בתשתית ויש חומת אש אכזרית של צ'ק פוינט/סיסקו שעולה מליוניםם ושהיא הודפת התקפות בקלות ושלל מעשיות נוספות, אבל גם חומת אש הכי יקרה בעולם יכולה לשמש כאבן שאין לה הופכים אם יש איש סיסטם מטומטם שמגדיר חוקים עם ANY ANY לכל הכתובות, לכן חשוב להגדיר את חומת האשהפנימית בשרת שלך שתגן על המכונה שלך.
גיבויים – שוב, ספקים רבים מבטיחים גיבוי, אבל מי ערב לך שהגיבוי עובד ותקין ולא מוזנח (כי לאנשי הסיסטם יש משימות אחרות והם לא טיפלו חודשים רבים בגיבוי… ראיתי כבר ספקים עם המצב הנ"ל) וביום פקודה זה לא יעבוד? לכן חשוב מאוד לעשות גיבוי משלך למקום אחר (עדיף לאחסן את הגיבוי מחוץ לתשתית המקומית של הספק, או להשתמש באחסון חיצוני כמו S3 של אמזון).
כשזה מגיע לבסיסי נתונים, תהיה מקורי בשמות בסיסי הנתונים. אם יש לך בלוג וורדפרס לדוגמא, בסיס נתונים עבורו בשם wpdb זה רעיון לא טוב! חשוב ליצור שמות מקוריים ויחודיים על מנת שלא לעשות חיים קלים לאלו הפורצים אתרים. זכור גם להכניס סיסמאות מסובכות (צריך שרות ליצירת סיסמאות מסובכות? קבל)
הכר את נושא ה-Cross Site Scripting (נקרא גם XSS) – זו אחת השיטות הידועות ביותר לפרוץ לאתרים ורוב האתרים המסחריים בארץ חשופים לשיטה זו, לכן אם הנתונים חשובים לך, אז יש צורך בעדיפות עליונה להגן על האתר שלך נגד שיטת פריצה זו. אם אתה משתמש בדפדפן Firefox לדוגמא, אז תוסף XSS-ME יכול לבדוק את האתר שלך אם אתה פרוץ או לא בכל מיני מקומות באתרים שלך.
עדכונים – חשוב תמיד לעדכן את המערכת שלך בעדכוני האבטחה האחרונים. עדכוני מערכת ניתן לעדכן בקלות בעזרת פקודת yum update (ב-CentOS) או apt-get upgrade בדביאן/אובונטו.
לעקוב אחרי ה-Logs – בדרך כלל ניתן לראות היכן מתחילות הבעיות – ברישומי לוגים. אנשים עם מכונות אובונטו/דביאן מוזמנים לקרוא בנושא כאן. ב-CentOS יש פרק שלם על כך כאן.

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

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

על שרתים וירטואליים (VPS) ו-DNS

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

מטבע הדברים, לכל אתר מגיעים עם שם הדומיין. היכן מוגדר שם הדומיין כדי שיוכר בעולם? ב-DNS כמובן, ומטבע הדברים, אלו שמשכירים שרתים וירטואליים ברוב המקרים מגדירים את השרת גם להיות שרת ה-DNS, ומכיון שבשביל DNS יש צורך ב-2 שרתים, כמעט כולם מגדירים את שרת ה-DNS שישמש כ"אדון" (Master) ו-Slave ("עבד").

כאן מתחילה הבעיה (והיא לא קשורה לספק כלשהו אלא בכלל).

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

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

כלומר הפתרון של לאחסן את רישומי ושרות ה-DNS בתוך שרת ה-VPS שלך אינו רעיון טוב.

מה עושים? אני מציע 3 פתרונות, שוב, ללא קשר לספק, את הפתרונות האלו כמעט כל ספק יכול למכור לך.

אם יש לך מספר קטן של דומיינים (נניח כמה עשרות דומיינים) מספיקה חבילת אחסון משותף (נקראת גם "אחסון אתרים" או "אכסון אתרים") בתצורת "ריסלר" (ישנם ספקים שקוראים לזה שמות אחרים, אתה צריך לבקש חבילה שאתה יכול לרשום בה דומיינים דרך הפאנל). חשוב לוודא שלאותו ספק שרתי ה-DNS שלו מופרדים (מומלץ שיהיו מופרדים ברמה הפיזית כך שכל שרת DNS ישב בשרת פיזי אחר). עם חבילה זו תוכל לרשום את הדומיינים שלך אצל אותו ספק ולהפנות את ה- A record לכתובת ה-IP של שרת ה-VPS שלך (אפשר גם רישומים אחרים כמו MX, CNAME ועוד, ועל כך מומלץ להתייעץ עם הספק או עם מישהו מקצועי שמבין ב-DNS ובהתאם לצרכים). ודא עם הספק שהרישומים שיצרת מסונכרנים אוטומטית עם שרת ה-DNS השני שלו. במקביל, כשרשמת בחבילה את הדומיינים, הספק יתן לך 2 רישומים (או יותר) של Name Servers שאלו בד"כ שמות שרתי ה-DNS שלו. את הרישומים האלו אתה צריך להכניס אצל רשם הדומיינים, היכן שרכשת את הדומיינים.
אם יש לך כמות גדולה של דומיינים (מאות ומעלה), מומלץ לשכור מספק אחר שרת VPS מאוד קטן (256 מגהבייט זכרון, דיסק קשיח וירטואלי קטן, עוצמת השרת אינה חשובה), ולהרים עליו שרת DNS. אם הינך משתמש בשרת ה-VPS העיקרי שלך עם cPanel, אז הנה חדשות טובות: אתה יכול להוריד ולהתקין ללא תשלום בשרת ה-VPS הקטן את cPanel DNS Only ולעקוב אחר ההוראות שם. תוכל להגדיר דומיינים בשרת ה-VPS העיקרי שלך והוא יסנכרן את הרישומים אוטומטית עם שרת ה-VPS הקטן שלך. (אגב, הסיבה לספק אחר נעוצה בעניין שאם יש תקלה כלשהי אצל הספק העיקרי שלך, שרותי DNS עדיין יוכלו לזהות את הדומיינים שלך בעולם).
אפשרות שלישית (והכי זולה, אם כי לא תמיד אפשרית): להשאיר את ניהול ה-DNS אצל רשם הדומיינים שלך. רובם מציעים פאנל כלשהו לשינוי ה-A record וכו' בקלות, וכך גם אם השרת הוירטואלי שלך נופל, שרתי ה-DNS בעולם עדיין ידעו לגבי הדומיינים שלך. החסרון בשיטה זו: אצל רוב הרשמי דומיינים הישראליים, העדכון עצמו מתרחש רק לאחר 24 שעות ועד אז לוקח עוד 24 שעות עד שזה מתעדכן בארץ (בהשוואה לחו"ל שזה עניין של שניות). לצערי, בנושאי DNS, "תודות" לספקי האינטרנט הגדולים ולאיגוד האינטרנט (ולכל תהליך רישומי דומיינים מקומיים), אנחנו עדיין "תקועים" בשנות ה-90.

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

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

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

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

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

תקיפת שרת

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

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

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

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

פריצה לשרת

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

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

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

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

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

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

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

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

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

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

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

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

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

מיתוס: מחשוב ענן בישראל

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

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

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

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

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

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

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

נקודות למחשבה לסטארטאפיסט

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

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

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

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

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

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

לכן, כשמתחילים צריך לקחת שרת וירטואלי (עדיין לא יעודי, המחיר של יעודי יקפיץ בעוד כמה מאות דולרים לחודש) טוב עם ליבה אחת (מומלץ 2 אם אפשרי מבחינת תקציב) וזכרון של לפחות 1-2 ג'יגה (אם מדובר בשרת Linux) או 2-3 ג'יגה (אם מדובר בשרת Windows. מה לעשות, Windows שותה זכרון עם צינור). מבחינת רוחב פס, ודא כי הספק נותן לך לפחות 5-10 מגהביט סימטרי (לא "מתפרץ", שזה בעצם טריק שיווקי למכור שליש מוצר במחיר של מוצר) ומתחייב על כך בחוזה. מבחינת דיסק, כדאי שיהיו כמה עשרות ג'יגהבייט בתור התחלה. ודא שיש לך אפשרות לקבל קונסולה אם במקרה נעלת את עצמך בטעות (כמו במקרה של טעות בהגדרות SSH או חוק שגוי בחומת האש הפנימית) מבלי להתחנן לתמיכה שיפתחו לך.

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

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

Cache חובה: לא חשוב כמה האתרים שלכם דינמי, חלקים רבים בתוכו הם סטטיים – תמונות, סקריפטים, תכנים, דף פתיחה ועוד, וכל החלקים האלו אפשר ליצור להם קבצים סטטיים שיוגשו לגולש ואפליקציית Cache תייצר אותן תוך מעקב מה בתוקף ומה לא. אם אתם משתמשים באפליקציות CMS, אז ברוב המקרים זה רק עניין של התקנת תוסף פשוט שיתן לכם את זה. שימוש חכם ב-Cache יכול לחסוך את רוב העבודה שהשרת צריך לעשות כדי לתת תכנים מותאמים לגולש.
אופטימיזציית SQL – זה משהו אחד שיש לך 2 שרתי SQL מאסיביים שרצים עם סינכרון/רפליקציות עם תקציב שנתי רצינית, וזה משהו אחר שאתה סטארט אפ ויש לך תקציב ששווה לתקציב הקופה-הקטנה של גוגל. שרת ה-SQL שלך צריך לעבוד בצורה אופטימלית וחזקה. אם אתה משתמש לדוגמא ב-MySQL, אז יש כאן לדוגמא מדריך איך לעשות זאת, וכל שרת SQL מכובד כולל אתר שלם איך לעשות אופטימיזציות, החל בבחירת מנוע נכון (InnoDB, MyISAM וכו'), הגדרת כמות חיבורים בהתאם לכמות הזכרון והצורך, ועד ל-Queries בלתי אופטימליים (דבר שגורם "מריבות" בין מפתחים שונים, גם את זה ראיתי).
שרת WEB טוב: הנה עובדה – שרת Apache על VPS כמו שפירטתי מקודם שמוגדר טוב (עם כל ה-MPM, מודולים וכו') יכול לשרת כמה אלפי אנשים סימולטנית מבלי לחנוק את הליבה של ה-VPS ומבלי לגרום ל-Load היסטרי. גם שרת NGINX יכול לבצע את העבודה הזו מבלי לחנוק משאבים, כל מה שצריך זה תכנון ובדיקה (לא חסרים כלים להעמיס שרתים). אם פעם אחת יושבים ומגדירים את זה בצורה טובה, אז יהיו לכם לילות ללא יקיצה בגלל שרת קורס. חשוב להגדיר בשרת Cache לדברים שלא הולכים להשתנות כל דקה (לדוגמא: קבצי Header ו-Footer).
אבטחה: יודעים מי ינסה לבדוק כמה האתר שלכם מאובטח? המתחרים שלכם, ובמקרים רבים המתחרים שלכם מכאן בארץ. חושבים שלא ינסו לבדוק SQL Injection וכל חור אפשרי? הם בהחלט ינסו, כי זו השיטה הכי טובה לגלות סודות מסחריים שלכם (במיוחד דפים וקבצים נסתרים שמיועדים ללקוחות Beta סגור). לכן כדאי לבדוק את כל הרכיבים כולל אלו שלא תהיה להם גישה מבחוץ. נסו לסרוק את השרת שלכם עם nmap, או SNORT (לא, הוא עוד לא מת) וכלים אחרים, חפשו כלים אחרים, בדקו XSS, נסו לבצע SQL Injection ותקנו את כל החורים.
עבדו עם גירסאות יציבות של מערכות הפעלה. ב-Windows זה Non issue, משתמשים ב-2008 R2, בלינוקס לעומת זאת מומלץ שלא להשתמש בגרסאות שמשתנות כל הזמן כמו Ubuntu הרגיל (קח את Ubuntu LTS) או Fedora (קחו CentOS 6 או Scientific Linux 6.1) והקפידו להריץ עדכון לפחות אחת לשבוע.
צרו גיבוי מרוחק – כל ספק יכול להבטיח שהגיבוי שלו סוף הדרך, שזה נחמד, אבל עדיף שיהיה לכם לפחות אחת לחודש גיבוי של האתר וה-DB אצלכם בידיים או בשרת מרוחק אחר (זה לא מסובך: mysqldump לבסיס הנתונים, rsync לשאר, להריץ הכל ב-cron ונגמר העניין).

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

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

רק הצלחה!