סביר להניח שהתשובה לכותרת הפוסט זה תהיה מאנשים רבים: ״חס ושלום!״, במיוחד לאנשים שמבינים בתשתיות, מערכות הפעלה, אבטחה וכו׳
אבל לפני הכל, הנה קליפ קצר (2 דקות) מדוע חשבתי על העניין:
מכיווון שאפשר לפרש את שאלתי להרבה כיוונים, אסביר: אינני מדברת על אירוח שרתי משחקים, שרותי סטרימינג מהבית או שרותים מסחריים. אני מדברת על לארח בלוג, או לארח דבר כלשהו שלא מצריך רוחב פס משמעותי.
הבעיה הגדולה ביותר שיש באירוח ״בחוץ״, בין אם זה אצל ספק הוסטינג ישראלי שיקים לך שרת וירטואלי עם ביצועי מעבד ורשת גרועים או אצל ספק ענן מכובד אחר בחו״ל (Hetzner, Linode ואחרים) – זה שאין לך שום שליטה על דברים שהם מעבר ל-VM שלך. בין אם ה״שכן״ שלך מריץ סקריפטים שפשוט ״טוחנים״ את המשאבים ובין אם משהו מוגדר באופן שגוי בוירטואליזציה או בדברים אחרים – אתה תסבול, ואם יש לך בעיות – זבש״ך, שלא לדבר על כך שמיגרציה מספק אחד לספק אחר היא כאב ראש לא קטן.
אז איך אפשר להימנע מהעניין, ועדיין להקים מכונה וירטואלית שתפנה לציבור, וגם לשמור על אבטחה כך שלא כל האקר יפרוץ לך לבית ויגרום נזק משמעותי? להלן מספר צעדים, חלקם כלליים וחלקם ספציפיים לתשתית (למען פוסט זה, אני מדברת על שימוש ב-Proxmox גירסאות 8/9, ומערכת הפעלה לינוקסית ב-VM, לא חשוב איזו הפצה)
נתחיל בדברים הכלליים:
- ראשית, אנחנו לא נאפשר שום גישה ישירה ל-VM. כל הגישה לאתר בשרת תתבצע דרך שרותי tunnels שונים שנבחר: Cloudflare Tunnels, Tailscale funnel ואחרים, מה שאומר שאם מישהו גולש אל האתר שלך מבחוץ, הוא קודם כל נבדק לפני שהוא מגיע. זה לא מונע בוטים ודברים אחרים, אבל לכך נתייחס בהמשך
- אנחנו לא נצטרך כתובת IP סטטית. ה-Tunnels חוסכים לנו גם הקמה ושימוש ב-Dyndns וגם מייתרים את הצורך בשימוש IP סטטי (אנחנו נגדיר בדומיין את ה-tunnel במקום זאת).
- אנחנו נוודא שכמה שיותר דברים יצאו ״סטטיים״ (כמו פוסטים, עמודים) כך שמערכות Cache ינגישו אותם במקום לפנות שוב ושוב לשרת שלנו. כנ״ל לגבי תכנים כמו וידאו או אודיו: אם אנחנו לא יכולים לארח אותם באתרים ציבוריים (יוטיוב וכו׳), אנחנו יכולים להשתמש בשרותים זולים כמו R2 של Cloudflare לאירוח התכנים (מחיר: $0.015 סנט לכל ג׳יגה מעבר ל-10 ג׳יגה הראשונים שניתנים בחינם, ואין עלויות שידור המידע. כך לדוגמא הקליפ למעלה מגיע משרות זה)
- להקשחה ולמניעת בוטים שונים, נוכל להשתמש בשרותי ה-WAF של cloudflare – על כך בהמשך.
מכאן נעבור לחלק הוירטואליזציה:
- הדבר הראשון שנעשה הוא להקים VM רגיל, עם מערכת הפעלה שנרצה, עם כל התוכנות, העדכונים וההגדרות שנצטרך, בדיוק כמו כל VM שתקימו אצל ספק ענן ונוודא שהכל פעיל.
- לאחר מכן נגדיר בוירטואליזציה Bridge. ה-Bridge יהיה עם כתובת IP יחודית (לשם הדוגמא בפוסט: 192.168.10.1/24) נקרא לגשר הזה vmbr2. חשוב לזכור לא לחבר אותו לשום כרטיס או פורט פיזי.
- את ה-VM שהקמנו נכבה ונחליף בהגדרות הרשת שלה שהמכונה תהיה מחוברת אך ורק ל-vmbr2.
- נפעיל את ה-VM ונגדיר את כתובת ה-VM לכתובת לדוגמא 192.168.10.10 עם subnet של 255.255.255.0 ו-GW של 192.168.10.1. מבחינת DNS נשים 1.1.1.1. נוודא שאנחנו יכולים לבצע ping אל ה-bridge (כלומר: 192.168.10.1). כרגע, שום נסיון לתקשר החוצה לעולם או לכל מקום אחר מעבר ל-bridge – לא יצלח.
- אנחנו נשתמש ב-Proxmox לשרותי ניתוב. הדבר הראשון שנעשה זה להפעיל IP Forward, כך שהוא ידע לנתב את התעבורה. אנחנו גם נגדיר דרך iptables לזרוק כל פאקט שמגיע מה-lan שלנו (נניח בדוגמא זו שה-LAN שלכם הוא 192.168.0/24) אך כן להעביר אלינו ומאיתנו פאקטים לאינטרנט.
- מכיוון שאת הרוב נצטרך להגדיר ידנית, הנה בלוק קוד לדוגמא שאמור לשבת בתוך קובץ etc/networking/interfaces/ ב-proxmox:
auto vmbr2
iface vmbr2 inet static
address 192.168.10.1/24
bridge-ports none
bridge-stp off
bridge-fd 0
post-up echo 1 > /proc/sys/net/ipv4/ip_forward
post-up iptables -A FORWARD -i vmbr2 -d 192.168.0.0/24 -j DROP
post-up iptables -t nat -A POSTROUTING -s 192.168.10.0/24 -o vmbr0 -j MASQUERADE
post-down iptables -D FORWARD -i vmbr2 -d 192.168.0.0/24 -j DROP
post-down iptables -t nat -D POSTROUTING -s 192.168.10.0/24 -o vmbr0 -j MASQUERADE
שימו לב: כש-proxmox מקים את ה-bridge בשבילנו, הוא מצמיד לו חוקים כפי שהסברתי לעיל, אבל הוא גם מוריד את החוקים אם אנחנו מורידים את ה-bridge.
- עכשיו ה-VM יוכל לגשת לרשת האינטרנט אך לא ל-LANֿ, מה שאומר שאין לנו דרך לעשות SSH או כל תקשורת רגילה דרך ה-LAN ל-VM (רמז: אל תנסו להגדיר spice כאמצעי גישה למכונה, זה יתקע). איך נבצע בעצם גישה? דרך גישה מוצפנת כמו zero tier או tailscale שנתקין על ה-VM. לאחר מכן נכנס אל ה-VM ונראה אם אפשר דרך ה-tailscale לגלוש אל האתר/פלטפורמה ב-VM עם כתובת IP של tailscale (או פשוט שם). הצלחנו? מעולה, נמשיך לשלב הבא.
- ניכנס לממשק cloudflare ונגדיר tunnel חדש. חשוב שנגדיר את ה-tunnel אל דומיין מסויים שרכשנו ורשמנו ב-cloudflare (ודרכו ננגיש את האתר לציבור). אם הגדרנו הכל כשורה, נוכל להיכנס דרך הדומיין אל האתר שלנו.
זהו. מעתה, כל גישה לאתר עצמו יכולה להתבצע אך ורק דרך ה-tunnels (אל תשכח להסיר כל הגדרת dynamic DNS מאותו דומיין), ולא ניתן להיכנס אליו דרך SSH
נקודה חשובה: יש צורך בשינוי הגדרות ב-virtualhost של שרת ה-web שלכם כדי שיכיר בכך שאתם משתמשים ב-cloudflare tunnels כך שתוכלו לראות את ה-IP האמיתיים והארצות שמגיעים אליכם. בלי השינוי, כל מה שתראו ב-לוגים זה 127.0.0.1.
סיימנו? זה כבר תלוי בכם. מכאן אפשר להגדיר WAF (בתוכנית החינמית זה מופעל אצלכם כברירת מחדל), אפשר להגדיר חוקי firewall ברמת ה-proxmox אם אתם רוצים לתת גישה לפורטים 80/443 אך ורק ל-cloudflare וכמובן לחסום פורטים אחרים, אבל תאורתית, מכיוון שהמכונה שלכם ״חבויה״, הדרך להיכנס אליה היא רק דרך ה-tunnels ואתם צריכים להגן טוב על הפלטפורמה או שרת ה-virtualhost שלכם.
להלן שאלות שבוודאי ישאלו ע״י הגולשים:
- ״למה לא השתמשת ב-VLAN?״ התשובה לכך פשוטה: בלא מעט מקרים למשתמשים אין ציוד שמכיר ב-VLAN רמה 3, או שהם לא מכירים איך להשתמש, ובכל מקרה שימוש ב-bridge ״יתום״ יתן פחות או יותר את אותה פונקציה של הפרדה.
- ״ספקי אינטרנט יכולים לחסום תעבורה או שהתעבורה יכולה להיות איטית, ולכן פתרון כזה אינו כדאי״. נכון, אבל שוב, כשהכל נמצא ב-cache רוחב הפס שנשתמש, הוא קטן מאוד, ושיחת וידאו לוקחת הרבה יותר רוחב פס מגישה לאתר סטטי ברובו.
- ״מה שהצעת לא מספיק מוגן״. יכול להיות, אבל מה שנחשב ״מוגן״ למישהו אחד, יכול להיחשב ״בלתי מספיק״ למישהו אחר. אין גבול לכך
- ״לא הגדרת שום דבר מבחינת תשתית הוירטואליזציה עצמה להגן עליה״. נכון, נסו לחשוב על כך – הדרך היחידה של פורץ היא להיכנס רק דרך ה-VM וגם אז רק דרך ה-web (אם הגדרת רק HTTP ב-tunnel), כך שגם אם הוא יקבל shell, אין לו דרך ״לדבר״ עם ה-lan כי אנחנו חוסמים זאת ברמה מעבר ל-VM. יש סיכון קטן של ״בריחה מה-VM״, אבל אז כבר מדובר בכשלי אבטחה בוירטואליזציה שמתוקנים די מהר בעדכונים השוטפים
- ״ניתן להפיץ נוזקות ותולעים עם גישה כזו״. אפשר לעשות אותו גם דרך Hosting רגיל ב-vm שמוכרים לך
לסיכום: מדובר פה ברעיון שיכול אולי לעזור פה ושם. כמו כל רעיון, לא מדובר פה בפתרון קצה, ומנהל ה-lab עדיין צריך לנטר את המערכות, לעדכן אותן ולוודא שהכל עובד כשורה. אם מישהו חושב שפתרון כזה הוא כמו ״שגר ושכח״ – הוא טועה.
אשמח לשמוע את דעתכם.
אם החלטתם לבנות עבורכם שרת 2U, בין אם בהקמה מ-אפס ובין אם רכשתם שרת משומש והחלפתם חלקים עבור המעבדה הביתית שלכם – חשוב לשים לב לנקודות שלא שמים לב אליהם: הדיסקים הקשיחים בקידמת השרת, והמעבדים