הגנה מפני DDoS: להבדיל בין גל תעבורה לניסיון לחנוק אתכם

מאת צוות מדיה דיל · 03.07.2026 · אבטחת מידע · 5 דק׳

Volumetric Attack, Application Layer Attack, Reflection Amplification, Rate Limiting, רשת Anycast, ותפקיד CDN כשכבת ספיגה.

מתקפת DDoS יכולה להיראות כמו שני דברים שונים לגמרי בהתאם למטרתה: הצפה גולמית שמנסה לחנוק את צינור הרשת שלכם עם טרהביט של תעבורה חסרת משמעות, או זרם עדין הרבה יותר של בקשות שנראות לגיטימיות אבל מכוונות בדיוק לנקודה היקרה ביותר באפליקציה - endpoint שמריץ שאילתת דאטהבייס כבדה, למשל. ההבדל הזה קריטי כי הפתרון שונה לחלוטין: מה שעוצר הצפת נפח לא עוצר מתקפת שכבת אפליקציה, ולהפך. הגנה אמיתית דורשת הבנה של שתי הקטגוריות ובניית שכבות מתאימות לכל אחת מהן.

Volumetric Attacks - כשהמטרה היא פשוט לסתום את הצינור

מתקפת נפח מנצלת בדרך כלל reflection amplification - שליחת בקשה קטנה לשרת DNS או NTP פתוח עם כתובת מקור מזויפת (spoofed) של הקורבן, כך שהתשובה, גדולה פי עשרות עד מאות מהבקשה, נשלחת ישירות לקורבן. עם מספיק שרתים פגיעים ברשת, תוקף יכול לייצר תעבורה של מאות ג'יגה-ביט לשנייה כלפי יעד יחיד, ולסתום פשוט את ה-bandwidth הזמין לפני שהבקשות בכלל מגיעות לשרת האפליקציה. הגנה מפני זה חייבת לקרות לפני שהתעבורה נכנסת לתשתית שלכם, לא אחרי.

Application Layer Attacks - נפח נמוך, נזק גבוה

מתקפת Layer 7 לא צריכה נפח עצום כדי להזיק - כמה אלפי בקשות לשנייה שמכוונות ל-endpoint שמבצע חישוב כבד, חיפוש מורכב או קריאה חוזרת ל-API חיצוני, מספיקות לרוקן את משאבי השרת ולגרום ל-timeout למשתמשים אמיתיים. הבקשות האלה נראות תמימות לחלוטין ברמת הרשת - כל אחת היא בקשת HTTP חוקית עם TCP handshake תקין - מה שהופך אותן לקשות הרבה יותר לזיהוי מאשר הצפת נפח גולמית, ולעיתים קרובות דורש ניתוח התנהגותי ולא רק ספירת בקשות.

Rate Limiting - קו ההגנה הראשון בשכבת האפליקציה

הגנה בסיסית וזולה יחסית מגבילה כמה בקשות מותר לכתובת IP, טוקן API או session בודד לבצע בחלון זמן נתון, וחוסמת או מאטה (throttle) חריגה מהמכסה. rate limiting אפקטיבי צריך להיות מדורג - endpoint רגיש כמו login מקבל מכסה נמוכה מאוד, ואילו endpoint קריאה סטנדרטי מקבל מכסה גבוהה יותר - ולרוב משולב עם WAF שיכול לזהות גם דפוסי בקשה חשודים מעבר לספירה גולמית.

Anycast - איך מפזרים התקפה על פני אלפי נקודות במקביל

ברשת Anycast, אותה כתובת IP מוכרזת בו-זמנית ממספר רב של data centers גיאוגרפיים, וניתוב BGP דואג שכל מבקש יגיע אוטומטית לנקודת הנוכחות הקרובה אליו גיאוגרפית. המשמעות בזמן מתקפת DDoS היא שהתעבורה הזדונית מתפזרת אוטומטית בין עשרות עד מאות נקודות במקום להתרכז כולה בנקודת כניסה אחת - כל data center סופג רק חלק קטן מההתקפה, וקיבולת האבסורפציה הכוללת של הרשת גבוהה בהרבה מכל נקודה בודדת.

CDN כשכבת הגנה ראשונה, לא רק כמאיץ תוכן

מעבר לתפקידו הרגיל בהאצת תוכן סטטי, CDN שיושב לפני האפליקציה שלכם משמש כשכבת ספיגה טבעית - רוב הבקשות הזדוניות לעולם לא מגיעות לשרת המקור (origin) בכלל, כי הן נעצרות או נענות ברמת הקצה. ספקי CDN גדולים מחזיקים קיבולת רשת שגדולה בסדרי גודל מהתשתית של רוב הארגונים, ולכן יכולים לספוג מתקפות volumetric שהיו מפילות origin server רגיל תוך שניות.

מה עושים כשההתקפה כבר בעיצומה

הכנה מראש חשובה יותר מתגובה - runbook מוגדר צריך לכלול escalation path ברור מול ספק ה-CDN או ה-DDoS mitigation, יכולת לשנות DNS TTL נמוך מראש כדי לאפשר reroute מהיר, ו-monitoring שמבדיל בין עלייה לגיטימית בתעבורה (viral traffic) לבין מתקפה. הצוות צריך לדעת מראש מי מחזיק הרשאות לשנות rate limits ב-production בלי לחכות לאישורים, כי בזמן מתקפה אמיתית כל דקה של דיליי בתגובה שווה לקוחות אמיתיים שנופלים יחד עם התוקפים.

רוצים לבדוק שהתשתית שלכם באמת עומדת מול גל תעבורה בלתי צפוי? נשמח לעזור לכם בוואטסאפ.

תגיות: DDoS · Volumetric Attack · Rate Limiting · Anycast · CDN · Application Layer Attack

← חזרה לבלוג · צור קשר