האתר שלך נופל. אתה בודק את לוח הבקרה של האחסון ולא רואה כלום - אין התראות, אין הסבר. כמה שעות אחר כך מגיע אימייל גנרי מהספק שמספר שהיה "אירוע רשת" ושהכל כבר חזר לסדר. מה שבאמת קרה היה מתקפת DDoS, והסביבה השיתופית שלך התמודדה איתה בצורה הגרועה ביותר האפשרית: בכך שלא עשתה כמעט כלום שמועיל לך באופן ספציפי.
זו לא סיפור נדיר. זה קורה כל הזמן לבעלי אתרים בתוכניות שיתופיות. והחלק המתסכל הוא שהרבה ספקים טכנית כן מציעים הגנה מ-DDoS. פשוט ההגנה הזו מתוכננת לטובת הספק, לא לטובתך.
מה "הגנה מ-DDoS" בעצם אומרת באחסון שיתופי
כשספק אחסון שיתופי מזכיר הגנה מ-DDoS בשיווק שלו, הוא בדרך כלל מתכוון לדבר אחד: יש לו סינון ברמת הרשת שמונע מהתשתית שלו לקרוס לגמרי. ההגנה הזו קיימת כדי לשמור על מרכז הנתונים שלו עובד עבור כל הלקוחות יחד.
זה לא אומר שהאתר הספציפי שלך מוגן. זה לא אומר שתעבורה זדונית שמכוונת לדומיין שלך מסוננת לפני שהיא צורכת את המשאבים שלך. וכמעט בוודאות זה לא אומר שיש כאן מיטיגציה חכמה ומודעת לרמת האפליקציה שפועלת בשבילך.
יש הבדל משמעותי בין הגנה על רשת לבין הגנה על אתר. ספקי אחסון שיתופי מתמקדים בראשונה.
הבעיה המרכזית: משאבים משותפים תחת מתקפה
בשרת שיתופי, אתה אחד ממאות אתרים שרצים על אותה מכונה. כל אתר חולק CPU, RAM ורוחב פס. כשתוקף מכוון לאתר שלך, כל תעבורת ההצפה מגיעה לשרת השיתופי ומתחילה לצרוך משאבים שמשותפים לכולם.
וכאן זה מחמיר. רוב ספקי האחסון השיתופי מגיבים למצב הזה על ידי הגבלה או השעיה מוחלטת של החשבון שלך. לא של התוקף. החשבון שלך. ההיגיון פשוט מנקודת מבטם - האתר שלך הוא זה שיוצר שימוש חריג במשאבים, אז הם מנתקים אותו כדי להגן על שאר הלקוחות על המכונה.
בפועל, זה אומר שהתוקף מצליח להפיל את האתר שלך, וה"הגנה" של הספק שלך עוזרת לו לעשות את זה מהר יותר.
למה סף נפח התעבורה לא עוזר
חלק מספקי האחסון השיתופי מיישמים הגבלת קצב בסיסית או מכסות תעבורה. זה נשמע מגן אבל נכשל בדרך ספציפית וצפויה. הצפה בנפח גבוה ברור שפורצת כל מכסה סבירה, אבל מתקפות ברמת האפליקציה - שבהן כל בקשה נראית כמו מבקר אמיתי - יכולות להפיל אתר שיתופי עם מספר מפתיע קטן של בקשות בשנייה, כי סביבת ה-PHP השיתופית פשוט לא מצליחה לעבד אותן מהר מספיק.
הרחבנו על ההבדל הזה במאמר מתקפות DDoS ברמת האפליקציה: למה קשה יותר לעצור אותן מאשר הצפות פשוטות. בקצרה, מתקפות חכמות לא צריכות נפח גבוה כדי להצליח בסביבות עם משאבים מוגבלים. אחסון שיתופי כמעט תמיד מוגבל במשאבים לכל אתר, בכוונה.
אפקט השכן: כשמתקפה על מישהו אחר הופכת לבעיה שלך
הסביבה השיתופית יוצרת סיכון נוסף שכמעט לא מדברים עליו: אתה יכול לחוות השבתה כי אתר אחר באותו שרת נמצא תחת מתקפה.
אם השכן שלך בשרת שיתופי מקבל מתקפת DDoS גדולה, תעבורת ההצפה צורכת רוחב פס וכוח עיבוד על המכונה המשותפת. האתר שלך נפגע או נופל למצב לא מקוון למרות שאף אחד לא כיוון אליך. אין לך שום שליטה על זה. לא עשית כלום לא בסדר. פשוט קרה שאתה על אותו שרת.
זו אחת הסיבות המשכנעות ביותר לכך שהגנה מ-DDoS באחסון ברצינות דורשת תשתית ייעודית או מבודדת, לא מאגר משאבים משותף.
איך נראית הגנה מ-DDoS באחסון באמת
מיטיגציה אמיתית של DDoS פועלת במספר שכבות, והיא חייבת לקרות הרבה לפני שתעבורת המתקפה מגיעה לשרת שלך. המרכיבים המרכזיים כוללים:
- פיזור רשת Anycast - תעבורת המתקפה נספגת ומתפזרת על פני רשת רחבה של נקודות סינון לפני שהיא מתרכזת בנקודה אחת.
- ניתוח תעבורה וזיהוי תבניות - דפוסי בקשות זדוניות מזוהים ונחסמים בזמן אמת, כולל מתקפות ברמת האפליקציה שאטיות ובנפח נמוך ושסינון נפח פשוט מפספס לגמרי.
- הגבלת קצב לפי IP ולפי נקודת קצה - מקורות חשודים מוגבלים מבלי לפגוע במבקרים לגיטימיים.
- שילוב WAF - WAF תופס מתקפות ברמת הבקשה שסינון נפח טהור לעולם לא רואה. תוכל לקרוא עוד על איך זה משתלב בתמונה הכוללת במאמר מהו Web Application Firewall ואם אתה באמת צריך אחד?
- משאבים ייעודיים - ה-CPU וה-RAM של השרת שלך שייכים לך. מתקפה על אתר אחר לא מרעיבה את האפליקציה שלך ממשאבים.
אף אחד מהדברים האלה אינו סטנדרטי בתוכניות אחסון שיתופי. הם דורשים השקעה בתשתית שלא הגיונית מבחינה כלכלית כשספק מחלק עלויות על פני מאות חשבונות לכל מכונה.
המחיר האמיתי של הגנה לא מספקת
השבתה במהלך מתקפה היא הנזק הברור. אבל ההשפעות המשניות לעיתים קרובות גרועות יותר:
- מנועי חיפוש שסורקים את האתר שלך בתקופת מתקפה עשויים לראות שגיאות שוב ושוב, מה שעלול לפגוע בדירוג שלך.
- לקוחות שמגיעים בזמן השבתה בדרך כלל לא חוזרים. רושם ראשוני קשה להתאושש ממנו.
- אם הספק שלך משעה את החשבון שלך במהלך מתקפה, שחזור הגישה יכול לקחת שעות - ובאותו זמן אין לך שום יכולת להגיב.
- השבתות חוזרות פוגעות באמון המבקרים החוזרים גם אם כל אירוע בפני עצמו קצר.
בחנו איך השבתה ואירועי אבטחה קשורים לאמון המשתמשים באופן רחב יותר במאמר איך אבטחת האתר משפיעה על הדירוג בגוגל ועל אמון המשתמשים. המסקנה היא שמתקפות הן לא רק בעיה טכנית - יש להן השלכות עסקיות ישירות.
מה לחפש כשבוחרים הגנה מ-DDoS באחסון
אם לאתר שלך יש תעבורה משמעותית, תלות בהכנסות, או מוניטין שצריך להגן עליו, אלה השאלות שכדאי לשאול לפני שמתחייבים לספק אחסון:
- האם מיטיגציה של DDoS מיושמת בשולי הרשת, לפני שהתעבורה מגיעה לשרת שלך?
- האם הספק מציע סינון ברמת האפליקציה, או רק הגנה מפני נפח תעבורה גבוה?
- מה קורה לחשבון שלך במהלך מתקפה? האם הוא מוגבל או מושעה?
- האם משאבי השרת שלך מבודדים, או משותפים עם לקוחות אחרים?
- האם WAF כלול, והאם הוא מוגדר לכל אתר בנפרד או מיושם כסט כללים גנרי?
באחסון VPS מנוהל עם הגנה מ-DDoS מובנית - כמו מה שאנחנו מספקים - ההגנה פועלת בו-זמנית ברמת הרשת וברמת האפליקציה. תעבורת המתקפה מסוננת במעלה הזרם לפני שהיא מגיעה לשרת שלך, וכללי WAF תופסים ניצול ברמת הבקשה שסינון נפח היה מפספס. המשאבים שלך מבודדים, כך שמתקפה על שכן לא נוגעת באתר שלך. קרא עוד על איך הגנה מ-DDoS רב-שכבתית עובדת כאן.
לצאת מהמלכודת של "מספיק טוב"
הכוח המושך של אחסון שיתופי הוא המחיר. זה לגמרי מובן. אבל "מספיק טוב עד שמשהו משתבש" הוא סטנדרט מסוכן להגנה. מתקפות DDoS כבר לא אירועים נדירים שמוגבלים למטרות בעלות פרופיל גבוה. כלי מתקפה אוטומטיים זולים להפעלה ומשמשים לעיתים קרובות נגד אתרים קטנים ובינוניים רגילים - לפעמים כבדיקות אקראיות, לפעמים כניסיונות סחיטה ממש.
אם האתר שלך מייצר הכנסות, משרת לקוחות, או מייצג את המוניטין המקצועי שלך, ההגנה שהספק שלך מספק במהלך מתקפה חשובה לא פחות מזמינות ביום רגיל. אחסון שיתופי לא תוכנן לספק את ההגנה הזו. זו לא כישלון של ספק כלשהו - זו מגבלה מבנית של המודל.
החדשות הטובות הן שהגנה מ-DDoS באחסון ייעודי כבר לא שמורה לתקציבים של ארגונים גדולים. תוכניות VPS מנוהל עם מיטיגציה אמיתית מובנית נגישות לעסקים קטנים ולבעלי אתרים עצמאיים. הקפיצה ברמת ההגנה משמעותית. הקפיצה בעלות בדרך כלל הרבה יותר קטנה ממה שרוב האנשים מצפים.
