רוב האנשים מדמיינים הגנה מפני DDoS כמו חומה ענקית אחת שחוסמת תעבורה זדונית. במציאות, זה יותר דומה לשורה של נקודות ביקורת, וכל אחת עושה עבודה אחרת. שתיים מהחשובות שבהן הן הגבלת קצב (rate limiting) וניקוי תעבורה (traffic scrubbing). אם תבינו איך הן פועלות יחד, תבינו למה הגנה מ-DDoS באחסון טובה באמת עוצרת התקפות, ולא רק מאטה אותן.
אף אחת מהשיטות לא עובדת טוב לבד. הגבלת קצב בלי ניקוי תעבורה מאפשרת להתקפות הצפה מתוחכמות לחמוק. ניקוי תעבורה בלי הגבלת קצב מבזבז משאבים על התקפות שאפשר היה לעצור מוקדם יותר ובזול יותר. יחד, הן יוצרות הגנה רב-שכבתית שתופסת סוגים שונים של התקפות בשלבים שונים.
מה הגבלת קצב באמת עושה
הגבלת קצב קובעת תקרה לכמות הבקשות שמקור בודד יכול לשלוח בפרק זמן נתון. תחשבו על זה כמו על סדרן שסופר כמה פעמים אותו אדם מנסה להיכנס דרך הדלת בדקה. אם הוא חורג מהמכסה, הוא נדחה, לפחות באופן זמני.
זה נשמע פשוט, אבל זה יעיל להפליא נגד חלק גדול מתעבורת ההתקפות. הרבה בוטים וסקריפטים מפציצים שרת בבקשות חוזרות מאותה כתובת IP או טווח IP קטן. הגבלת קצב בסיסית על דפי התחברות, טפסי חיפוש או נקודות קצה של API יכולה לעצור התקפות כאלה עוד לפני שהן צורכות משאבי שרת אמיתיים.
איפה הגבלת קצב נכשלת
הבעיה היא שהתקפות מודרניות כמעט אף פעם לא מגיעות מכתובת IP אחת. רשתות בוטים (botnets) מפזרות בקשות בין אלפי, לפעמים מיליוני, מכשירים שנפרצו. כל מקור בודד אולי שולח רק כמה בקשות ספורות, נשאר הרבה מתחת לכל הגבלת קצב סבירה, בעוד שהנפח הכולל מציף את השרת שלכם.
הגבלת קצב גם מתקשה עם עליות תעבורה לגיטימיות. מכירה מיוחדת או פוסט ויראלי ברשת חברתית יכולים ליצור דפוסי בקשות שנראים ממש כמו התקפה. אם הכללים שלכם קפדניים מדי, אתם עלולים לחסום לקוחות אמיתיים.
מה ניקוי התעבורה מוסיף לתמונה
ניקוי תעבורה פועל ברמה אחרת. במקום לספור בקשות לפי מקור, מרכזי ניקוי מנתחים את הצורה הכללית של התעבורה שמגיעה לרשת ומסננים את מה שלא שייך, עוד לפני שהיא בכלל מגיעה לשרת שלכם.
מרכזי ניקוי בודקים דברים כמו:
- חריגות בגודל ובמבנה של חבילות מידע בהשוואה לתעבורה רגילה
- הפרות פרוטוקול שלקוחות לגיטימיים לא היו יוצרים
- דפוסים גיאוגרפיים ודפוסי ASN שמרמזים על מקור מרשת בוטים
- חתימות התקפה ידועות שמותאמות מול מאגרי מודיעין איומים
מכיוון שהניקוי מתבצע במעלה הזרם, לרוב על פני רשת מבוזרת של מרכזי נתונים, הוא יכול לספוג הצפות נפחיות שאחרת היו מציפות לגמרי את רוחב הפס של שרת בודד. זו השכבה שמטפלת בהתקפות הכוח הגס העצומות שהגבלת קצב לבדה לעולם לא הייתה יכולה לגעת בהן. כיסינו את המנגנון של סינון ברמת הרשת הזו במאמר איך הגנת DDoS ברמת האחסון עוצרת התקפות לפני שהן מגיעות לשרת שלכם.
למה גם ניקוי תעבורה זקוק לעזרה
ניקוי תעבורה מצוין בזיהוי דפוסים על פני נפחים גדולים של תעבורה, אבל הוא לא תמיד מדויק ברמת הבקשה הבודדת. התקפות ברמת האפליקציה, מהסוג שמחקה התנהגות דפדפן אמיתית ומכוונות לנקודות קצה ספציפיות כמו טפסי התחברות או עמודי תשלום, יכולות להיראות כמעט זהות לתעבורה לגיטימית כשמסתכלים על התמונה הכוללת. זה בדיוק הפער שהגבלת קצב ממלאת. אם אתם רוצים הסבר מעמיק יותר על למה התקפות כאלה כל כך קשות לעצירה, פירטנו את זה במאמר התקפות DDoS ברמת האפליקציה: למה קשה יותר לעצור אותן מהצפות פשוטות.
איך שתי השכבות משתלבות בפועל
בהקמה טובה של הגנה מ-DDoS באחסון, התעבורה עוברת דרך שתי השכבות ברצף. ניקוי התעבורה מטפל תחילה ברעש ברמת הרשת, ומסיר זבל נפחי ברור וחבילות פגומות עוד לפני שהן מגיעות לתשתית שלכם. מה שעובר את זה נתקל אז בכללי הגבלת קצב שבוחנים התנהגות ברמה עדינה יותר, לפי IP, לפי סשן, לפי נקודת קצה.
חלוקת העבודה הזו חשובה כי כל שכבה מכוונת למה שהיא הכי טובה בו:
- ניקוי תעבורה תופס הצפות עצומות שנמדדות בגיגה-ביט או טרה-ביט לשנייה
- הגבלת קצב תופסת ניצול לרעה שנמדד בבקשות לשנייה ממקורות ספציפיים
- ניקוי תעבורה עובד על נתוני רשת ופרוטוקול גולמיים
- הגבלת קצב עובדת על הקשר ברמת האפליקציה, כמו איזו כתובת URL מותקפת שוב ושוב
כשששתי השכבות מוגדרות היטב, תוקף צריך לעבור שני סוגי סינון שונים מאוד שתוכננו על ידי שני תחומים שונים. זו בעיה הרבה יותר קשה לפתרון מאשר לנצח רק שכבה אחת.
דוגמה מהעולם האמיתי
נניח שתוקף משיק מתקפה מעורבת: הצפת UDP נפחית יחד עם הצפת HTTP איטית יותר שמכוונת לדף ההתחברות שלכם. שכבת הניקוי מזהה מיד את דפוסי החבילות החריגים של הצפת ה-UDP ומפילה אותה לפני שהיא משתמשת ברוחב הפס שלכם בכלל. במקביל, הצפת ה-HTTP, שנראית יותר כמו תעבורת דפדפן רגילה, נתפסת על ידי כללי הגבלת קצב שעוקבים אחרי כמות ניסיונות ההתחברות מכל סשן בחלון זמן קצר. אף אחת מהשכבות לבדה לא הייתה עוצרת את שתי ההתקפות. יחד, הן טיפלו בזה מבלי שהאפליקציה שלכם בכלל הרגישה.
מה זה אומר לגבי בחירת האחסון שלכם
כשאתם בודקים את הטענות של ספק אחסון לגבי הגנה מ-DDoS באחסון, כדאי לשאול ספציפית איך שתי השכבות האלה מיושמות, ולא רק אם "הגנת DDoS" מוזכרת בעמוד התמחור. ספק שמציע רק ניקוי תעבורה עלול לפספס ניצול לרעה ברמת האפליקציה. ספק שמציע רק הגבלת קצב יוצף ברגע שמגיעה התקפה נפחית אמיתית.
אנחנו מפעילים את שתי השכבות כחלק מסביבת ה-VPS המנוהלת שלנו: ניקוי תעבורה ברמת הרשת לספיגת הצפות גדולות, יחד עם כללי הגבלת קצב מכוונים לכל אתר לתפיסת ניצול לרעה ממוקד. תוכלו לקרוא עוד על איך החלקים משתלבים בעמוד הגנת DDoS שלנו, ואם אתם רוצים גם את הצד של חומת האש, סקירת ה-WAF שלנו מסבירה איך סינון בקשות משלים את שתי השכבות האלה.
שאלות שכדאי לשאול את הספק שלכם
לפני שאתם מתחייבים לתוכנית אחסון בהתבסס על שיווק האבטחה שלה, שאלו את השאלות האלה:
- האם הניקוי מתבצע ברמת הרשת, או רק כתגובה אחרי שהתקפה זוהתה?
- האם כללי הגבלת קצב ניתנים להתאמה לכל אתר, או קבועים בכל הפלטפורמה?
- מהו הזמן הטיפוסי להתמודדות עם התקפה מרגע שהיא מתחילה?
- האם הספק מפרסם נתוני אירועים אמיתיים או מקרי בוחן?
אם אתם לא בטוחים אם הטענות של הספק הנוכחי שלכם מחזיקות מים, עברנו על איך לבדוק את זה כראוי במאמר איך לדעת אם הגנת ה-DDoS של ספק האחסון שלכם אמיתית או רק שיווק.
לסיכום
הגבלת קצב וניקוי תעבורה הם לא שיטות מתחרות. הן שכבות משלימות שמכסות זו את הנקודות העיוורות של זו. ניקוי תעבורה מטפל בהצפה, הגבלת קצב מטפלת בהתקפות המתוחכמות שמצליחות לחמוק בחבילות קטנות וערמומיות יותר. אם האחסון שלכם כולל רק אחת מהשכבות האלה, אתם מוגנים רק חלקית. שאלו שאלות ספציפיות, לא רק אם קיימת הגנת DDoS, אלא איך היא באמת עובדת, לפני שאתם סומכים עליה עם זמן הפעילות שלכם.
