האם אירוח VPS הוא בטוח? כל מה שחשוב לדעת על אבטחה

האם אירוח VPS הוא בטוח? התשובה הקצרה

כן. אירוח VPS הוא בטוח עבור המשימות שעבורן רוב האנשים רוכשים אותו, והוא מהווה שיפור ממשי לעומת אירוח שיתופי. שרת VPS‏ (virtual private server) הוא מכונה וירטואלית בעלת ליבה (kernel), זיכרון, דיסק וחשבונות משתמש משלה, וה־hypervisor שמריץ אותה מונע מלקוחות אחרים גישה לכל ארבעת המשאבים הללו. האדם ששוכר את השרת הסמוך לשלך על אותה מכונה פיזית אינו יכול לקרוא את הקבצים שלך, להציג את התהליכים שלך, להתחבר לשרת שלך או לראות את תעבורת הרשת שלך.

לתשובה הכנה יש שני חלקים. הספק מחזיק בבעלות על החומרה ועל ה־hypervisor. אתה מחזיק בבעלות על כל מה שנמצא בתוך המכונה הווירטואלית שלך, ושם מתחילה כמעט כל פריצה ממשית. שרתים נפרצים דרך פורט פתוח, סיסמת SSH חלשה, חבילה שאף אחד לא עדכן, או סוד (secret) שנמצא בקובץ שפורסם בטעות. נדיר מאוד ששרתים נפרצים דרך ה־hypervisor.

מה ה־hypervisor באמת מפריד

ה־hypervisor הוא התוכנה שמריצה מכונות וירטואליות על מארח פיזי יחיד. ב־VPS מבוסס KVM (ראשי תיבות של kernel based virtual machine, הסטנדרט במארחי Linux), השרת שלכם הוא מכונה וירטואלית מלאה. הוא מאתחל kernel משלו. המארח מקצה לו אזור קבוע בזיכרון הפיזי, ויחידת ניהול הזיכרון של המעבד מונעת כל גישה מחוץ לאזור זה, כך שקוד שרץ ב־guest אחר אינו יכול לגשת ל־RAM שלכם כלל. אין מערכת קבצים משותפת ואין טבלת משתמשים משותפת, לכן הרשאות קבצים בשרת של שכן אינן רלוונטיות לשרת שלכם.

אחסון שיתופי (shared hosting) עובד אחרת. אתרים רבים חיים בתוך מערכת הפעלה אחת, תחת שרת אינטרנט אחד והתקנת PHP אחת, כחשבונות משתמש רגילים. הגבול היחיד הוא הרשאות קבצים. טעות בהרשאות, או תוסף פגיע שרץ כמשתמש בעל הרשאות קריאה נרחבות מדי, עלולים לפיכך להגיע לקבצים של חשבון אחר. זהו הפער ש-מעבר מאחסון שיתופי ל־VPS סוגר.

בדקו מה אתם קונים, כיוון שלא כל תוכנית שנמכרת כ־VPS היא אכן מכונה וירטואלית. תוכניות מבוססות מכולות (OpenVZ, LXC, Virtuozzo) משתפות את ה־kernel של המארח ומפרידות בין לקוחות באמצעות namespaces ו־cgroups במקום וירטואליזציה של חומרה. זהו גבול חלש יותר, כיוון שבאג ב־kernel של המארח הוא באג ב־kernel של השרת שלכם גם כן. כמו כן, לא ניתן לטעון מודולי kernel בתוכניות אלו, מה שפוסל תוכנות מסוימות. KVM היא ברירת המחדל הבטוחה יותר. בררו איזו טכנולוגיה אתם מקבלים לפני התשלום.

מה יכול לעולל לכם "שכן רועש"

שיתוף שרת פיזי עולה לכם במהירות, ומהירות היא המשאב היחיד שמושפע מכך. האורחים על אותה מכונה חולקים את ה-CPU הפיזי ואת הכוננים. כאשר ה-CPU עסוק במשימות של מישהו אחר, ה-CPU הווירטואלי שלכם ממתין, ו-Linux מדווחת על המתנה זו כ-steal time: השדה %st בתוך top ו-vmstat. ערך steal time שנמצא מעל אחוזים בודדים במשך שעות מעיד על כך שהשרת הפיזי עמוס מדי (oversubscribed). אין זה אומר שמישהו קורא את הנתונים שלכם. הפתרון הוא מעבר לתוכנית אחרת או לספק אחר, ותוכלו למדוד את ה-CPU והדיסק שקיבלתם בפועל לפני שתחליטו.

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

מה שכן עוין אינו יכול לעשות, והמקרה הנדיר שבו הוא כן יכול

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

פריצות מהיפרווייזר (Hypervisor escapes) הן דבר ממשי. באג בשכבת הווירטואליזציה עלול לאפשר לקוד בתוך אורח אחד להגיע למארח, ומהמארח להגיע לכל אורח אחר עליו. באגים אלו מתגלים, מתפרסמים עם מזהה CVE (ראשי תיבות של Common Vulnerabilities and Exposures) ומקבלים תיקון, וספקי אירוח מתקנים אותם במהירות כיוון שכל עסקיהם נשענים על שכבה זו. ניצול של באג כזה דורש exploit עובד עבור גרסת היפרווייזר ספציפית, וזהו משאב יקר מכדי לבזבז אותו על חשבון אירוח קטן.

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

היכן מסתיימת אחריות הספק והיכן מתחילה אחריותך

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

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

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

האם ספק האחסון יכול לראות את הנתונים שלכם?

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

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

מה באמת פורץ לשרת VPS

שירות המאזין לכל ממשקי הרשת. מסדי נתונים, מטמונים (caches), תורי הודעות ולוחות בקרה מנהלתיים נוטים כברירת מחדל לבצע bind לכתובת 0.0.0.0, מה שאומר שהם מאזינים לכל ממשק רשת, כולל הממשק הציבורי. סריקות ברחבי האינטרנט מתבצעות באופן קבוע ואוטומטי, כך שכתובת IP חדשה מקבלת את הבדיקה הלא-מבוקשת הראשונה שלה דקות ספורות לאחר העלייה לאוויר. Redis ללא סיסמה, צומת Elasticsearch ללא אימות, ממשק Docker API פתוח בפורט 2375 ולוח בקרה שעדיין משתמש בפרטי ההתחברות המקוריים – כולם מתגלים בדרך זו על ידי סורק שכלל לא יודע מי אתם. בצעו bind של שירות לכתובת 127.0.0.1 כאשר רק המכונה המקומית זקוקה לו, וחסמו את השאר באמצעות ה-firewall.

Docker שעוקף את ה-firewall שלכם. פרסום פורט של מכולה (container) כותב חוקי NAT (Network Address Translation) שמתועדפים לפני החוקים של ufw (Uncomplicated Firewall), לכן מכולה עלולה להיות נגישה מהאינטרנט גם כאשר ufw status מדווח שהפורט חסום. זהו מכשול נפוץ עבור מי שביצעו את כל שאר הפעולות בצורה נכונה. כדאי לקרוא את הסיבה לכך שפורט של Docker מתעלם מ-ufw לפני שמפרסמים פורט של מכולה.

SSH עם סיסמאות מופעלות. קראו את /var/log/auth.log בכל שרת ציבורי ותמצאו שורות כמו Failed password for root from 203.0.113.10 port 54312 ssh2, אלפים מהן, יום ולילה. בוטים עוברים על שמות משתמש וסיסמאות נפוצים. התחברות באמצעות סיסמה יחד עם חשבון root שמאפשר כניסה הם כל מה שתוקף צריך. שימוש במפתחות בלבד, עם ביטול כניסת root, הופך את התעבורה הזו לרעש רקע שניתן להתעלם ממנו.

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

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

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

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

החלק שלך בעבודה

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

• בצע את השעה הראשונה כראוי: עשר הדקות הראשונות ב-VPS חדש מכסה יצירת משתמש שאינו root והגדרת firewall.
• הגבל גישה מרחוק: הקשחת SSH ב-VPS.
• סגור פורטים שאינך משתמש בהם: יסודות ה-firewall ב-ufw.
• תן לכל שירות רק את הגישה לה הוא זקוק: משתמשים בעלי הרשאות מינימליות ב-VPS.
• האט ניסיונות התחברות בכוח גס (brute force): fail2ban ב-Ubuntu 24.04.
• שמור גיבוי ששחזרת לפחות פעם אחת: גיבויים עם restic עבור VPS.

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

FAQ

האם לקוח אחר על אותו שרת פיזי יכול לקרוא את הקבצים שלי?

לא, לא בשרת KVM VPS. השרת שלך הוא מכונה וירטואלית בעלת ליבה (kernel) משלה ודיסק וירטואלי משלה, בתוספת אזור בזיכרון הפיזי שהמארח מקצה לה, והמעבד חוסם כל גישה מחוץ לאזור זה. אין מערכת קבצים משותפת בין הלקוחות, לכן להרשאות קבצים בשרת של שכן אין כל משמעות בשרת שלך. תוכניות מבוססות מכולות (containers) כגון OpenVZ ו־LXC חולקות את ליבת המארח ומספקות גבול הפרדה חלש יותר, לכן בדקו איזה סוג אתם רוכשים.

האם VPS בטוח יותר מאחסון שיתופי?

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

האם ספק האחסון שלי יכול לקרוא את הנתונים שלי?

עקרונית כן, ושום מוצר VPS לא משנה זאת. דמות הדיסק (disk image) מאוחסנת על החומרה של הספק, ה־console מספק גישה ברמת המסך למכונה הפועלת, ו־rescue mode יכול להעלות מערכת אחרת כשהדיסק שלכם מחובר אליה. אם נתונים מסוימים חייבים להישאר בלתי קריאים עבור המארח, הצפינו אותם ביישום שלכם לפני הכתיבה. הצפנת דיסק בתוך ה־guest עדיין משאירה את המפתח בזיכרון בזמן שהשרת פועל, לכן היא לא מוציאה את הספק ממעגל האמון.

מהי הדרך הנפוצה ביותר לפריצה ל־VPS?

שירות חשוף או התחברות SSH חלשה, בפער ניכר. סורקים אוטומטיים בודקים כל כתובת IP ציבורית ללא הפסקה, לכן מסד נתונים שמאזין ל־0.0.0.0 ללא סיסמה, או לוח ניהול שהושאר עם פרטי ברירת המחדל שלו, יתגלו בתוך דקות ולא חודשים. /var/log/auth.log בכל שרת ציבורי מציג את הצד של ה־SSH: שורות Failed password for root חוזרות ונשנות מכתובות בכל רחבי העולם. קיימות פריצות ברמת ה־hypervisor, אך הן עבודה ברמה מחקרית המכוונת למטרות בעלות ערך גבוה, ולא הסיבה לפריצות רגילות.