הרבה ספקי אחסון אומרים שהם כוללים הגנה מ-DDoS. זה מודפס בדף התכונות, מוזכר במיילים של אנשי המכירות, ורשום ממש ליד "99.9% זמינות" כאילו הכל מובטח באותה מידה. אבל כשמתקפה אמיתית מגיעה, הפער בין הגנה אמיתית לבין סימון בתיבה שיווקית הופך ברור מאוד, מהר מאוד.
אז איך מבדילים בין השניים לפני שאתם באמצע תקלה? הנה מה שכדאי לבדוק.
איך נראית הגנה מ-DDoS אמיתית ברמת האחסון
הגנה מ-DDoS אמיתית פועלת במעלה הרשת, לפני שתעבורה זדונית בכלל מגיעה לשרת שלך. היא עובדת על ידי בדיקת תעבורה בקצה הרשת, זיהוי דפוסי מתקפה, וסינון פקטות רעות תוך מעבר של תעבורה נקייה.
השאלה המרכזית היא: איפה ההגנה בעצם יושבת? אם ההגנה של ספק קיימת רק על השרת עצמו, כבר מאוחר מדי. עד שתעבורת המתקפה מגיעה לממשק הרשת של השרת, רוחב הפס שלך כבר נצרך. השרת מנסה לעבד זבל שלא היה צריך לראות מלכתחילה.
אחסון עם הגנה מ-DDoS טובה מנתב את התעבורה דרך שכבת סינון לפני שהיא מגיעה לשרת. זה יכול להיות מרכזי סינון פנימיים, סינון במעלה הרשת ברמת מרכז הנתונים, או שילוב עם רשת הגנה ייעודית. הפרטים משתנים, אבל העיקרון זהה: עצור את המתקפה מוקדם ככל האפשר.
שאלות לשאול כל ספק אחסון
דפי השיווק לא יגידו לך את מה שצריך לדעת. השאלות האלה כן.
מה הקיבולת הכוללת של ההגנה?
מתקפות נפחיות מודרניות יכולות לעלות על 1 Tbps. אם ספק לא יכול לומר לך את קיבולת ההגנה שלו במספרים קונקרטיים, זה סימן אזהרה. ביטויים כמו "הגנה ברמה ארגונית" בלי פרטים לא אומרים כלום. חפשו ספקים שמציינים נתוני תפוקה אמיתיים, גם אם הם בטווח של מאות Gbps.
ההגנה תמיד פעילה, או שהיא מופעלת רק אחרי זיהוי?
חלק מהספקים משתמשים בהגנה "ריאקטיבית", שבה ההגנה נכנסת לפעולה רק אחרי שמתקפה מזוהה. חלון הזיהוי הזה, גם אם הוא רק כמה דקות, יכול להספיק כדי להפיל אתר. סינון שפועל כל הזמן הוא אמין הרבה יותר. שאלו ישירות: האם התעבורה נבדקת כל הזמן, או רק במהלך מתקפה פעילה?
מה קורה לתעבורה לגיטימית במהלך ההגנה?
חלק מהפתרונות להגנה מ-DDoS הם גסים מדי. הם חוסמים טווחי IP שלמים או מדינות שלמות כדי לעצור מתקפה, ובכך מחסלים גם משתמשים אמיתיים. שאלו האם ההגנה שלהם מבדילה בין תעבורת מתקפה לבין מבקרים אמיתיים, ואיך.
האם ההגנה מכסה גם Layer 7 ולא רק Layer 3/4?
מתקפות נפחיות (ברמת הרשת) הן הסוג הנפוץ ביותר, אבל מתקפות ברמת האפליקציה קשות יותר לעצירה ונפוצות יותר ויותר. הסברנו את הסיבה לכך בפירוט במאמר מתקפות DDoS ברמת האפליקציה: למה הן קשות יותר לעצירה מאשר מבולים פשוטים. אם ספק מזכיר רק מגבלות רוחב פס או פקטות לשנייה, ייתכן שהוא לא מוכן להתמודד עם HTTP floods שמכוונות ללוגיקת האפליקציה שלך.
שפת השיווק שכדאי להיזהר ממנה
הנה כמה ביטויים שנשמעים מרגיעים אבל לא אומרים הרבה:
- "הגנה מ-DDoS כלולה" - כלולה איך? באיזו קיבולת? באיזו שכבה?
- "אנחנו מנטרים מתקפות DDoS 24/7" - ניטור זה לא אותו דבר כמו הגנה. לדעת שאתה תחת מתקפה לא עוצר אותה.
- "מוגן על ידי תשתית ארגונית" - זה לא אומר כלום בלי פרטים.
- "השרת שלך מוגן מ-DDoS" - אם ההגנה קיימת רק ברמת השרת, היא כמעט חסרת תועלת מול מתקפות בקנה מידה גדול.
- "מעולם לא חווינו תקלת DDoS משמעותית" - זה אולי אומר שיש להם הגנה מצוינת. זה גם אולי אומר שעדיין לא היו מטרה.
איך לאמת הגנה בלי לחכות למתקפה
בדקו את ספקי הרשת של מרכז הנתונים
ספק אחסון מוגן רק באותה מידה כמו הרשת שמעליו. בדקו עם מי הם עובדים ואם שותפי מרכז הנתונים שלהם פרסמו יכולות הגנה מ-DDoS. ספקים שמשתמשים בספקי Tier 1 או ברשתות סינון ידועות כמו אלה של Cloudflare, Akamai, או Radware נמצאים בדרך כלל במצב טוב יותר מאשר אלה שמנתבים דרך רשתות אזוריות קטנות יותר.
בדקו את ניסוח ה-SLA
ספק שלוקח הגנה מ-DDoS ברצינות יכלול אותה בהסכם רמת השירות שלו, לא רק בדף השיווק. אם ה-SLA לא אומר כלום על הגנה מפני מתקפות, או אם הוא במפורש מוציא DDoS כסיבה מכוסה לתקלה, קחו את זה ברצינות. זה מגלה איפה האחריות האמיתית יושבת.
שאלו על מדיניות null-routing
ספקים רבים מגיבים למתקפות DDoS גדולות על ידי null-routing של ה-IP הממוקד, כלומר הם בעצם מורידים את האתר שלך כדי להגן על שאר התשתית שלהם. זו שיטה לגיטימית ברמה מסוימת, אבל חשוב מאוד מתי ואיך זה קורה. שאלו: באיזה נפח מתקפה אתם עושים null-route? לכמה זמן? האם יש נתיב חלופי לתעבורה לגיטימית בזמן הזה?
חפשו תקריות היסטוריות
בדקו את היסטוריית דף הסטטוס של הספק, פורומי הקהילה שלו, ואתרי ביקורות אחסון עצמאיים. חפשו פוסטים על תקלות DDoS. ספק עם הגנה אמיתית יהיה לו אירועים, אבל הם יפתרו מהר. ספק שמסתמך על null-routing יראה תקלות ממושכות בכל פעם שלקוח שלו מותקף.
איך הגנה מ-DDoS משתלבת במערך האבטחה הכולל שלך
גם הגנה מ-DDoS מצוינת ברמת האחסון לא מחליפה שכבות אבטחה אחרות. חומת אש לאפליקציות (WAF) מטפלת באיומים שונים, כמו SQL injection ו-credential stuffing, שפתרון DDoS לא נועד לתפוס. לפרטים על איך שתי השכבות האלה עובדות יחד, ראו למה אבטחת אתרים בשכבות מנצחת כל כלי יחיד בכל פעם.
המטרה של הגנה מ-DDoS באחסון היא לשמור על האתר שלך נגיש במהלך מבול תעבורה. ה-WAF מטפל בבקשות זדוניות שעוברות. גיבויים וניטור מכסים את ההתאוששות אם משהו כן משתבש. אלה לא כלים מתחרים - הם משלימים זה את זה.
כשאנחנו מגדירים הגנה מ-DDoS לשרתים כאן, היא פועלת במעלה הרשת ברמת הרשת כך שתעבורת המתקפה מסוננת לפני שהיא מגיעה לרוחב הפס של השרת. אנחנו גם משלבים את זה עם סינון ברמת האפליקציה כדי ש-HTTP floods ממוקדים בנפח נמוך לא יחמקו. תוכלו לקרוא עוד על איך הארכיטקטורה הזו עובדת בדף סקירת הגנה מ-DDoS שלנו.
השורה התחתונה
אל תקבלו את "הגנה מ-DDoS כלולה" כערך נקוב. ההבדל בין ספק שחוסם מתקפות לבין אחד שרק מסתכל עליהן יכול להיות שעות של השבתה, הפסד הכנסות, ופגיעה במוניטין.
שאלו שאלות ספציפיות. קראו את ה-SLA. בדקו את רשת ספקי מרכז הנתונים. והסתכלו על מה שבאמת קורה כשלקוח מותקף, לא על מה שדף השיווק מבטיח שיקרה.
הגנה אמיתית ניתנת לאימות. אם ספק לא יכול לתת לכם תשובות ישירות על קיבולת ההגנה שלו, הארכיטקטורה, ומדיניות ה-null-routing, זה אומר משהו חשוב.
