ברוב האתרים שמשתמשים באחסון משותף או נאיבי, יחסית קל לגלות את כתובת ה-IP של השרת שמאחסן את האתרים האלו. מדובר בעצם במחשב שמארח כמה וכמה אתרים וכתובת הדומיין מפנה אליו. על מנת לגלות את כתובת ה-IP שלו, כל מה שצריך זה להקליד ping ואת כתובת האתר ואז יש לנו את כתובת ה-IP של השרת. אם מדובר באתר קטן ואחסון שיתופי, לא אמורה להיות בעיה.
הבעיה מתחילה כשהאתר גדל ואז אנחנו בדרך כלל מתחילים לפזול החוצה לאחסון על ענן – כמו Lightsail למשל או ספקים אחרים ומתחילים לחשוב על שימוש בקלאודפלייר. ואז אנחנו מאחסנים את האתר שלנו בעצם מאחורי CDN כמו קלאודפלייר כדי שיאפשר לנו גם גמישות, נוחות וביצועים. עם קלאודפלייר למשל אני יכול להעביר את כתובת ה-IP של השרת שלי כרצוני ובמהירות עצומה – תחשבו על כל המקרים העצובים של לקוחות בוקס – אחסון אתרים שקרס באפריל 2020 ואז שוב באפריל 2022 – בעלי האתרים שם בעצם איבדו את האתרים מבלי שום יכולת לעשות משהו. אחרים שהיה להם גיבוי וקלאודפלייר פשוט התגברו על העניין בשניות. קלאודפלייר גם מאוד עוזר להגן על האתר מכל מיני התקפות של מרעין בישין – האתר הזה למשל חסום לגמרי למדינות עולם שלישי שהתל״ג שלהן נמוך מ-10,000 דולר לנפש. למה? כי עם כל הכבוד לגולשים מאינדונזיה, אפגניסטן, פקיסטן ושאר מדינות מלבבות ואיכותיות שמתעניינים בתוכן על תכנות בעברית, בסופו של דבר רוב התנועה לאתר מהמדינות האלו הם בוטים/סקאנרים/גורמים מרושעים – אין לי שום סיבה להכניס אותם לאתר הזה וקלאודפלייר מאפשרת לי לבלום אותם מייד.
הנה דוגמה של שימוש בקלאודפלייר שגם נמצאת בפוסט על קלאודפלייר שמומלץ לקרוא.
הבעיה האבטחתית
מה הבעיה עם התרחיש הזה? לכאורה שום דבר, אבל בואו ונניח שיש לנו האקר מרושע (או יותר נכון בוט או סקאנר) בשם מאלורי. מאלורי יכול לגשת ישירות אל שרת הווב המקורי ולתקוף אותו – למשל בהתקפת DDOS. או לנסות ולהתחבר אליו ב-SSH ולהריץ עליו איזו קריפטומיינר חביב. זה מאוד לא תיאורטי – זו חולשה שהיה קיימת גם על השרת הזה!
איך התוקף יודע מה כתובת השרת האמיתי? מן הסתם פינג פשוט לדומיין לא יביא לו את זה – אבל לא חסרות דוגמאות לכך שכתובת השרת האמיתית דולפת. לפעמים אנו עושים טעות ומכוונים סאב דומיין לכתובת ה-IP האמיתית (קורה בעיקר כאשר אנו מגדירים את המייל) או סריקה של גוגל כשהאתר היה בבניה או הגדרה אפליקטיבית לא טובה מספיק (למשל לא מעט פעמים יוצא לי לראות שהתמונות באתר וורדפרס יושבות מתחת לכתובת IP).
לפעמים זה אפילו לא בעיה שלנו. אם אנו מאחסנים על ענן, כתובות ה-IP של העננים השונים נסרקות כל הזמן על ידי בוטים שמנסים למצוא חולשות ולהניב לבעליהם כמה זוזים. קריפטומיינר על מכונה יכולה לגרום לאינדונזי שחי בביקתה פתאום להפוך להיות עשיר עצום (ואז להרשות לעצמו אפילו שירותים בתוך הבית!!!).
אם אנו מגבילים את הפורטים, זה חוסך את הבעיה – הבעיה היא שעדיין יש גישה לפורט 443 ופורצים מנסים לנצל אפליקטיבית את האתר. כלומר לנסות כל מיני פרצות על וורדפרס. הבעיה היא שלא מעט פעמים הם עוקפים את הגנת ה-CDN כי הם ניגשים ישירות למכונה.
למי שיש כוח ויש לו ידע לגשת ללוגים – או אפליקטיביים או על המכונה עצמה – מוזמן לראות, אם השרת שלו נמצא בענן, כמה פעמים מנסים לגשת ישירות לכתובת ה-IP של המכונה שלו – זה מאות ניסיונות לפעמים. פשוט בוטים שמנסים את מזלם לראות אם יש איזה פורט פתוח ולא מוגן. מעבר לזה שמדובר בסיכון אבטחה, זה גם מעצבן – כי מדובר תמיד בתנועה עוינת.
הפתרון: פיירוול
מה הפתרון? הפתרון הוא להשתמש בפיירוול שימנע גישה ישירה. מה זאת אומרת? אם אני משתמש ב-CDN כמו פיירוול – כל מי שלא מגיע ממנו? נחסם. הנה הדיאגרמה:
כמובן שברגע שאנו באים לממש את זה, זה טיפה יותר מורכב. בדרך כלל כי ספק ה-CDN שלנו לא כולל רק כתובת IP אחת אלא המון כתובות. אבל כל ספק CDN מספק את רשימת הכתובות שלו בדיוק לפיירוולים כאלו. ככה למשל הרשימה של קלאודפלייר נראית. כלומר במקום להגדיר לפיירוול רק כתובת IP אחת שמותר לקבל, צריך להגדיר לו כמה כתובות. שזה באמת טיפה יותר מורכב.
אבל איך מגדירים? האם זה מסובך? ממש לא. רוב ספקיות הענן תומכות בזה. למשל ב-Lightsail של אמזון, אנו יכולים להגדיר את זה בלשונית ה-network של ה-instance. מסמנים שרק פורט 443 יכול לגשת למכונה ואז מסמנים את ה-Restrict to IP address וממלאים את הפרטים ברשימה.
אחרי השמירה, זה נראה כך:
אם יש לכם שירותים אחרים שצריכים לגשת למכונה, כמו למשל שירותי מוניטורינג, אל תשכחו להוסיף אותם לרשימה.
אפשר לוודא שהכל עובד בקלות – ראשית האתר שלכם צריך להיות למעלה – סימן שה-CDN כן יכול לגשת אליו. שנית, אם אתם מקלידים את כתובת ה-IP ישירות, אתם תחסמו. בדיוק כמו כל מי שמנסה לסרוק.
גם אם אתם לא מאמינים שיתקפו אתכם ישירות, באמת מוטב לחסום סקאנרים שמנסים לסרוק את כתובת ה-IP שלכם.
ייזהר הקונה
אם יש לכם כמה שירותים על המכונה (שזו פרקטיקה מאוד לא משהו) שמתקשרים החוצה והם לאו דווקא שירותי ווב – זה יכול לסבך אתכם כי כל מה שתיארתי פה יוצא מנקודת הנחה שכל התנועה עוברת דרך CDN.
אם יש לכם אירוח שיתופי אז כמובן שזה לא עבורכם. היתרון הגדול באירוח שיתופי או שרתים מנוהלים הוא שכל התפעול הוא כאב הראש של מי שמנהל. כמובן שהשימוש ב-CDN כמו קלאודפלייר ודומיו הוא חשוב מאוד כי הוא מאפשר לכם לעבור שרת בקלות.
2 תגובות
שלום, כתבה מעולה ויישר כח שטרחת לעזור לאחרים.
לדעתי הפתרון שהצעת הוא טוב אך לא מספיק. כי לעיתים גם רשימת הכתובות של הCDN היא בעצמה דינמית ומשתנה מדי פעם לפעם.
פתרון טוב שראיתי במקום אחר הוא ליצור header עם תוכן רנדומלי מורכב מספיק כך שהCDN שולח את ההדר הזה לשרת/LOAD BALANCER והשרת עונה לפניות רק אם ההדר עם התוכן הנכון קיים. כך מי שמגיע שלא דרך הCDN לא יוכל לגשת לשרת כלל. פתרון זה פותר את הבעיה של ניהול רשימות IP
להלן לינק לכתבה עם פתרון זה:
https://aws.plainenglish.io/configuring-aws-alb-with-cloudfront-you-are-probably-doing-it-wrong-4f0cbf86030d