האתר שלך נופל. זמני התגובה קופצים מ-80ms ל-30 שניות. ואז שקט מוחלט. רוב האנשים מניחים שמשהו התקלקל. במציאות, ייתכן שמישהו פשוט הציף את השרת שלך בגל של תנועה עד שהוא קרס תחת העומס.
מתקפות DDoS נפחיות הן הסוג הנפוץ ביותר של מתקפות מניעת שירות מבוזרות — וגם הכי פחות מובנות. כשאנשים שומעים "DDoS" הם מדמיינים האקרים מסתוריים. המציאות מכנית יותר, ובמובן מסוים, משעממת יותר. הכל בעצם מסתכם בדבר אחד: למלא את הצינור.
הבנה של מה שקורה בפועל ברמת הרשת עוזרת לך לקבל החלטות חכמות יותר לגבי סביבת האחסון שלך. אז בואו נפרק את זה.
מה מתקפה נפחית מנסה לעשות
לכל שרת יש כמות קבועה של רוחב פס — הכמות המקסימלית של נתונים שהוא יכול לשלוח ולקבל בשנייה. מתקפת DDoS נפחית מנסה לרוות את רוחב הפס הזה לחלוטין. כשהצינור מלא, תנועה לגיטימית לא יכולה לעבור. האתר שלך לא רק מאט — הוא הופך לבלתי נגיש.
תחשוב על זה כמו כביש עם ארבעה נתיבים. בתנועה רגילה הכל זורם. עכשיו דמיין 50,000 מכוניות שמנסות להיכנס בו-זמנית. שום דבר לא זז. זה המודל — ריקון מוחלט של הקיבולת.
המספרים כאן אינם קטנים. מתקפות נפחיות מודרניות מגיעות באופן קבוע למאות ג'יגה-ביט לשנייה. הגדולות ביותר שתועדו עברו את רף ה-1 Tbps. שרת אחסון משותף טיפוסי יושב על קו של 1 Gbps. אפשר להבין בקלות עד כמה זה הופך לבעייתי במהירות.
שלושה וקטורי מתקפה נפחיים נפוצים
UDP Flood
UDP (User Datagram Protocol) הוא פרוטוקול ללא חיבור — אפשר לשלוח חבילות לכל IP ופורט מבלי לבסס חיבור מראש. התוקפים מנצלים זאת על ידי הצפת היעד בכמויות עצומות של חבילות UDP. השרת מנסה לעבד כל חבילה, לא מוצא שום תהליך שמאזין על אותו פורט, ושולח בחזרה הודעת ICMP "יעד לא נגיש". כפל זאת במיליוני חבילות לשנייה — ורוחב הפס הנכנס והיוצא מוכה בו-זמנית.
ICMP (Ping) Flood
חבילות Ping קטנות — בדרך כלל 64 בייט. אבל שלח מספיק מהן מהר מספיק והן מצטברות. הצפות ICMP מציפות את מחסנית הרשת בשרת עצמו. השרת שורף מחזורי CPU בעיבוד כל בקשה נכנסת ובהפקת תשובות, ולא נשאר כמעט כלום לעבודה האמיתית.
מתקפות הגברה
אלו המתקפות הנפחיות המסוכנות ביותר, כי הן מאפשרות לתוקפים להשיג השפעה הרבה גדולה מכוחם האמיתי. המנגנון הבסיסי עובד כך:
- התוקף שולח בקשה קטנה לשרת פתוח (DNS, NTP, Memcached וכו') עם כתובת ה-IP שלך מזויפת כמקור
- השרת הפתוח שולח תגובה הרבה יותר גדולה בחזרה לכתובת ה-IP שלך
- התוקף עושה זאת אלפי פעמים במקביל
הגברת DNS יכולה להגיע לפקטור הגברה של פי 28 עד פי 54. הגברת NTP יכולה להגיע לפי 556. הגברת Memcached נמדדה ביותר מפי 51,000 במתקפות אמיתיות. עם רשת בוט אפילו בגודל צנוע, זה מאפשר לתוקפים לייצר מאות ג'יגה-ביט של תנועה המכוונת למטרה אחת.
איך נראית התנועה הזו על הרשת
מהנדסי רשת יכולים לזהות מתקפות נפחיות במהירות כשהם בוחנים לכידות תנועה. כמה סימנים מובהקים:
- אחידות גודל חבילות: תנועת מתקפה מורכבת לעתים קרובות מחבילות שכולן כמעט באותו גודל. תנועת גלישה אמיתית מעורבת — שאילתות DNS קטנות, תגובות HTML בינוניות, הורדות תמונות גדולות יותר. דפוס אחיד הוא דגל אדום.
- ריכוז בפורט אחד: תנועה שמכה בפורט 53 או פורט 80 בלבד, ללא שום דבר אחר, נראית לא טבעית.
- כתובות IP מקוריות מזויפות: מתקפות הגברה משתמשות בכתובות מקור מזויפות. תראה תנועה שמגיעה מ-resolvers פתוחים ידועים ברחבי העולם — אלפי כתובות IP שונות, אבל כולן שולחות חבילות בגודל דומה בקצבים חריגים.
- ריכוז גיאוגרפי: הצפות מבוססות botnet מראות לעתים קרובות ריכוז כבד ממדינות או ASNs ספציפיים, במיוחד כאלה הידועים כמארחים תשתית פגועה.
- יחסי פרוטוקולים: בשרת רשת רגיל, תנועת UDP אמורה להיות חלק קטן מ-TCP. אם UDP מייצג פתאום 95% מהחבילות הנכנסות, משהו השתבש.
למה השרת שלך פשוט לא יכול לספוג את זה
תפיסה שגויה נפוצה היא שאתה פשוט צריך שרת חזק מספיק. CPU ו-RAM פחות חשובים ממה שאתה חושב במהלך מתקפה נפחית. צוואר הבקבוק הוא כמעט תמיד קו הרשת עצמו.
גם אם ה-CPU של השרת שלך מתעלם מכל חבילה זדונית, החבילות עדיין צריכות להגיע לכרטיס הרשת לפני שניתן לבטל אותן. מתקפה של 10 Gbps נגד שרת של 1 Gbps לא צריכה להיות מעובדת — היא רק צריכה להתקיים. הצינור מתמלא ללא קשר למה שהשרת עושה פנימית. לא ניתן להתגבר על מתקפה נפחית באמצעות חומרה ברמת השרת.
זו הסיבה שההגנה האמיתית היחידה מתרחשת במעלה הזרם, לפני שהתנועה מגיעה לשרת שלך כלל. סיקרנו את זה בפירוט ב-הסבר על מתקפות DDoS: מה הן ואיך הגנה מ-DDoS באחסון עובדת בפועל.
איפה הגנה מ-DDoS באחסון נכנסת לתמונה
הגנה מ-DDoS באחסון אפקטיבית עובדת על ידי סינון תנועה במעלה הזרם בשולי הרשת — בנקודה בתשתית שיש לה הרבה יותר קיבולת מכל שרת בודד. כשמתקפה מזוהה, התנועה מנותבת מחדש דרך מרכזי סינון שיכולים לעבד מאות ג'יגה-ביט לשנייה, לסנן את החבילות הזדוניות, ולהעביר רק תנועה נקייה במורד הזרם לשרת שלך.
השלבים הטכניים המרכזיים נראים בערך כך:
- זיהוי: נקבעות קווי בסיס לתנועה. חריגות — עליות פתאומיות ב-UDP, התפלגויות גודל חבילות חריגות, הגעה למגבלות קצב — מפעילות התראה.
- סיווג: תנועת המתקפה מקבלת טביעת אצבע. האם זו מתקפת השתקפות? הצפת UDP? אילו פורטים, אילו פרוטוקולים, אילו דפוסי מקור?
- סינון: כללים מיושמים כדי לבטל תנועה תואמת לפני שהיא מגיעה לשרת המקור. תנועה נקייה ממשיכה. תנועה זדונית נזרקת.
- ניטור: פרופיל המתקפה לעתים קרובות משתנה כשהתוקפים מבינים שההצפה שלהם מנוטרלת. ניתוח מתמשך מתאים את הפילטרים בזמן אמת.
הגנה מ-DDoS באחסון טובה פועלת בקיבולת רשת שהופכת אפילו מתקפות גדולות לניהולות — כי שכבת הסינון סופגת את הנפח לפני שהשרת שלך רואה אותו בכלל. זה מה שאנחנו עושים כאן, וזו הסיבה שההגנה חייבת להיות ברמת תשתית האחסון ולא על השרת עצמו.
לסקירה של איך זה משתלב באסטרטגיית אבטחה רחבה יותר, כדאי לקרוא את ערימת האבטחה לאתרים שכל בעל אתר צריך להכיר ב-2025.
מה עם מתקפות ברמת האפליקציה?
מתקפות נפחיות מכוונות לרוחב הפס. אבל יש קטגוריה קשורה — מתקפות Layer 7 או ברמת האפליקציה — שמכוונות במקום לקיבולת העיבוד של שרת האינטרנט שלך. אלו שולחות בקשות שנראות כמו HTTP רגיל אבל מתוכננות לרוקן את משאבי השרת (חיבורי מסד נתונים, זיכרון סשן, CPU).
מתקפות אלו משתמשות בהרבה פחות רוחב פס וקשות יותר לזיהוי דרך ניתוח חבילות בלבד. כאן נכנס חומת האש לאפליקציות רשת (WAF) — הוא בוחן את תוכן הבקשות, לא רק את הנפח. שתי ההגנות משלימות זו את זו, ולא ניתן להחליף אחת בשנייה. מה זה WAF ואם אתה באמת צריך אחד? מסביר איך שכבה זו עובדת בפועל.
אתה יכול גם לבחון את הפרטים הטכניים של איך אנחנו מטפלים בשני סוגי האיומים בסקירת ה-DDoS mitigation ותיעוד ה-WAF שלנו.
המסקנה המעשית
מתקפות DDoS נפחיות הן בעיית רוחב פס, לא בעיית תוכנה. שום כמות של הקשחת שרת, תוספי WordPress, או הגדרות ברמת האפליקציה לא יצילו אותך כשהצפה של כמה ג'יגה-ביט פוגעת בקו שלך. ההגנה חייבת לקרות במעלה הזרם, ברמת הרשת, עם מספיק קיבולת לספוג או לסנן את תנועת המתקפה לפני שהיא מגיעה אליך.
אם תוכנית האחסון שלך לא כוללת הגנה מ-DDoS באחסון ברמת התשתית, אתה מסתמך על כך שהשרת שלך ישרוד משהו שמבחינה מבנית הוא לא יכול לשרוד לבד. זה החלק שכדאי להבין — וכדאי לבדוק לפני המתקפה הבאה, לא אחריה.
