הפחתת התקפות DDoS מותאמת אישית עם הגנה על זרימה ניתנת לתכנות

Informatec Digital » משאבים » הפחתת התקפות DDoS מותאמות אישית עם הגנת זרימה ניתנת לתכנות

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

הופעתן של טכנולוגיות כמו Programmable Flow Protection for Magic Transit של Cloudflare , השימוש בלוגיקת C מותאמת אישית שנפרסה כ-eBPF, אינטגרציה עם עננים כמו AWS ו-Azure, ותמיכה משירותי הגנה מיוחדים שינו באופן קיצוני את הנוף. כעת ניתן לדמות מה נחשב לתעבורה "טובה" או "זדונית" ברמת החבילה, להתאים את אמצעי ההפחתה לפרוטוקולי UDP ספציפיים מאוד (כגון אלה המשמשים במשחקים מקוונים או VoIP), ולשלב זאת עם פתרונות בינה עסקית ובינה מלאכותית שלומדים מכל התקפה.

מהי מתקפת DDoS ומדוע היא הפכה לבעיה כה חמורה?

מתקפת מניעת שירות מבוזרת (DDoS) שואפת להציף את משאבי המערכת (שרתים, קישורים, יישומים או תשתית ביניים) על ידי שיגור שטף של תעבורה ממקורות מרובים בו זמנית. בניגוד למתקפת DoS קלאסית, שבה מקור יחיד מפעיל את ההתקפה, מתקפת DDoS כוללת אלפי או אפילו מיליוני מכשירים שנפגעו, המאורגנים ברשת בוטים.

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

בשנים האחרונות חלה עלייה מתמדת בתדירות ובעוצמה של התקפות אלו. דיווחים מספקי אבטחה גדולים מצביעים על צמיחה מתמשכת בהתקפות היפר-נפחיות (מעל 1 Tbps או מיליארד חבילות לשנייה), שלעתים קרובות מכוונות לתשתיות קריטיות כגון שירותים פיננסיים, תשתיות ותקשורת.

סוגי התקפות DDoS: מהרשת ועד לאפליקציה

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

התקפות שכבת רשת (L3/L4) מתמקדות בניצול פרוטוקולי רשת ותעבורה (IP, TCP, UDP, ICMP) כדי לרוקן משאבים מוגבלים מהשרת או מתשתית ביניים: CPU, זיכרון, טבלאות חומת אש, חיבורים ממתינים או מאגרים של רשת. דוגמאות קלאסיות כוללות הצפות SYN (הצפת השרת בבקשות חיבור TCP שלעולם לא משלימות את לחיצת היד), הצפות UDP לפורטים אקראיים והתקפות ICMP.

התקפות שכבת יישומים (L7) מכוונות לרוחב פס נמוך יותר ממשאבי יישום האינטרנט או ה-API עצמו. הן מייצרות כמות עצומה של בקשות HTTP (GET/POST), שאילתות מורכבות למנועי חיפוש פנימיים, קריאות ל-APIs כבדים, או אינטראקציות שלמרות שהן נראות לגיטימיות, מאלצות את ה-backend, מסד הנתונים או מערכות יצירת התוכן לעבוד בקצה גבול היכולת שלהן.

התקפות נפחיות: כאן, המטרה היא להציף את הקישור עד שהוא הופך לבלתי שמיש. כמויות אדירות של תעבורה נשלחות, תוך ניצול טכניקות הגברה והשתקפות על שירותי UDP שתצורתם שגויה, כגון שרתי DNS ציבוריים (DNS, NTP, Memcached, CLDAP, SNMP, SSDP, Chargen, SLP וכו'), כך שחבילת בקשה קטנה מייצרת תגובה גדולה בהרבה המופנית לקורבן המתחזה.

התקפות מרובות וקטורים הן כיום המורכבות ביותר. הן משלבות מספר שיטות (נפחיות, פרוטוקוליות ואפליקציות) ומשנות אסטרטגיה בזמן אמת כשהן מזהות שההגנה מצליחה. מתקפה בודדת יכולה להתחיל כהצפה של UDP, לאחר מכן לעבור להצפה של SYN, ובהמשך להסתובב להתקפת HTTP בשכבה 7, מה שמאלץ את הקורבן לפרוס הגנות מקיפות ומתואמות.

התפתחות אמיתית של מתקפות DDoS: מ-Mirai להיפר-מתקפות Tbps

התיאוריה בסדר, אבל גודל הבעיה האמיתי מתברר במקרים מהעולם האמיתי. בעשור האחרון עברנו מהתקפות של מאות ג'יגה-ביט לשנייה לאירועים שעולים בקלות על כמה טרה-ביט לשנייה (Tbps) , עם קצבי חבילות המגיעים למיליארדים לשנייה.

בשנת 2016, מתקפה נגד Dyn - ספק DNS מרכזי - הגיעה לכ-1,2 Tbps והשביתה זמנית אתרים כמו טוויטר, GitHub, PayPal ונטפליקס. רשת הבוטים Mirai, שגייסה למעלה מ-600.000 מכשירי IoT (נתבים, מצלמות ו-DVR עם פרטי גישה כברירת מחדל), שימשה ליצירת תעבורה מסיבית לשרתי ה-DNS של Dyn, ככל הנראה באמצעות שילוב של טכניקות הצפת UDP והגברה.

באותה שנה, בלוג האבטחה KrebsOnSecurity ספג מתקפה של כ -623 ג'יגה-ביט לשנייה , גם היא מופעלת על ידי Mirai. במשך כמעט ארבעה ימים, חבילות UDP גדולות שוגרו בעיקר לפורטים אקראיים, מה שהצית את הקישורים ואילץ ניתוב מחדש של התעבורה לשירותי הפחתת פגיעה מיוחדים כמו Akamai Prolexic, שהפעילו סינון חתימות והתנהגות.

בשנת 2018, GitHub היה יעד למתקפה של 1,35 Tbps המבוססת על הגברת Memcached. התוקפים שלחו בקשות UDP קטנות לשרתי Memcached שנחשפו בפורט 11211, תוך שימוש בכתובת IP מזויפת של GitHub. כל בקשה זעירה גרמה לתגובות גדולות פי 50-100 שהופנו למערכות של GitHub, אשר נאלצו להפנות את התעבורה למרכזי ניקוי שם סוננו תגובות Memcached לפי דפוסיהן הספציפיים.

בשנת 2020, דיווחה אמזון כי AWS Shield הצליחה לבלום מתקפה של 2,3 Tbps שהסתמכה על השתקפות CLDAP (UDP 389). וקטור ההתקפה כלל הפצצת שרתי LDAP חסרי מדינה בשאילתות שיצרו תגובות בנפח גבוה לקורבן. AWS פיזרה את התעבורה ברחבי הרשת הגלובלית שלה והפעילה כללי סינון עבור דפוס CLDAP ספציפי זה.

לאחרונה, צצו רשתות בוט (botnets) כמו Mēris , המנצלות פגיעויות בנתבים של MikroTik. בשנת 2021 נרשמו שיאים של 21,8 מיליון בקשות לשנייה (RPS), ובשנת 2022, אלה הגיעו ל-46 מיליון RPS כנגד התשתית של גוגל, עם נפחים משוערים של 1,3 Tbps. מאמצי הפחתת הסיכון כללו תיקון המוני של מכשירים, סגירת פורטים כמו 5678 , ויישום כללי סינון ספציפיים עבור חתימת Mēris ברשתות כמו Cloudflare ו-Akamai.

באפריל 2025, Cloudflare דיווחה על מתקפת היפר של כ-6,5 Tbps וכמה מיליארדי חבילות לשנייה. על פי הניתוח שלהם, מדובר היה בבוטנט לא מיוחס עם מאפיינים דומים ל-Mēris ו-Aisuru, שהשתמשו בעיקר בהצפות UDP ישירות ממכשירי IoT ושרתים בעלי תצורה שגויה, מבלי לדרוש הגברה מסורתית. ההגנות הסתמכו על רשת Anycast הגלובלית של Cloudflare, הפחתת XDP/eBPF בקצה, ניקוי דינמי והגבלת קצב לכל IP ולכל אזור.

ובמאי 2025, KrebsOnSecurity עלתה שוב לכותרות לאחר שעמדה בפני מתקפה של כ -6,3 Tbps שהופעלה על ידי רשת הבוטים Aisuru. במקרה זה, נוצרו כ-585 מיליון חבילות UDP בשנייה במשך כ-40-45 שניות. גוגל פרויקט שילד, שהגנה על האתר, הפעילה מיד מדיניות סינון אגרסיבית עבור UDP לא רצוי והפנתה את התעבורה למרכזי ניקוי הפרוסים ברחבי הרשת הגלובלית שלה, כך שההשפעה על השירות הייתה כמעט בלתי מורגשת.

משאבים וטכניקות של תוקפים: רשתות בוט, הגברה והתחמקות

כדי להשיג את המספרים המדהימים הללו, תוקפים משתמשים במגוון משאבים, ומשלבים אותם בהתאם למטרתם. בוטנטים ענקיים הם הבסיס: רשתות של מכשירים פרוצים ברחבי העולם, שגויסו על ידי ניצול פגיעויות ידועות, סיסמאות ברירת מחדל או שירותי ניהול חשופים. Mirai, Mēris ו-Aisuru הם שמות משפחה, אך קיימות אינספור וריאציות, המכוונות ליצרנים או שירותים שונים.

הפגיעות העיקרית השנייה היא שרתים בעלי תצורה שגויה הפועלים כמשקפי רשת. כל שירות UDP לא מאומת שמגיב עם יותר נתונים ממה שהוא מקבל הוא מועמד: DNS (פורט 53), NTP (123), Memcached (11211), CLDAP (389), SNMP (161), SSDP, Chargen, SLP, TFTP, Portmap, שירותי P2P, או אפילו פרוטוקולי משחקי וידאו. התוקף שולח בקשות קטנות המזייפות את כתובת ה-IP של הקורבן, והשרתים מגבירים ומחזירים את התגובה ליעד בפועל.

ב-DNS, לדוגמה, שאילתת ANY לפתרון פתוח יכולה להכפיל את גודל הבקשה פי 28 בערך. ב-NTP, פקודת MONLIST הישנה הגיעה ליחסי הגברה של פי 50-500. Memcached היא מקרה קיצוני: בקשה זעירה יכולה להחזיר מאות קילובייטים, ולהגיע ליחסי הגברה של עשרות אלפי. CLDAP פועלת בגורמים של פי 56-70, בעוד ש-SLP שימשה עם ערכים העולים על פי 2000.

יתר על כן, תוקפים משכללים את טכניקות ההתחמקות שלהם. זיוף IP נותר שיטה קלאסית להסתרת המקור האמיתי ולניצול השתקפות. שיטות אחרות כוללות וקטורי התקפה מתחלפים ללא הרף, ערבוב תעבורה מוצפנת כדי לכפות עומסי עיבוד גבוהים יותר על המגן, שימוש בטכניקות "נמוכות ואיטיות" (צריכה הדרגתית של משאבים ללא קפיצות ברורות), או קירוב התעבורה לשכבת האפליקציה, שם היא דומה הרבה יותר לתעבורה לגיטימית.

בשלב טרום-המתקפה, כלי סריקה המונית כמו masscan או zmap משמשים לאיתור שירותים פגיעים, יחד עם ערכות פרצות שתוכננו במיוחד עבור IoT או שרתים. במהלך המתקפה, נעשה שימוש במחוללי תעבורה כגון hping3, LOIC/HOIC, או סקריפטים אופטימליים של C/Python, בעוד שלניתוח לאחר המתקפה, התוקפים עצמם עשויים להשתמש ב-Wireshark, tcpdump ופלטפורמות ניטור.

שלבי מתקפת DDoS והצורך בהגנה אדפטיבית

למרות שלעתים קרובות נתפסות כהתפרצויות כאוטיות של תעבורה, התקפות DDoS מתוחכמות עוברות מספר שלבים נפרדים . ראשית, שלב הסיור, שבו התוקף בוחן את המשטח החשוף, מזהה דומיינים, כתובות IP, שירותים פתוחים, רשתות CDN או ספקי הפחתה קיימים, ומחפש פגיעויות.

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

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

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

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

הפחתה מסורתית: מרכזי ניקוי, CDN, חומות אש ו-WAF

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

חברות כמו Netscout/Arbor, Akamai/Prolexic, Cloudflare, Radware, Imperva ו-AWS Shield מנהלות רשתות גלובליות עם נקודות נוכחות מרובות. כאשר מתגלה מתקפה, תעבורה המיועדת לארגון הקורבן מנותבת (באמצעות שינויי BGP או עדכוני DNS) למרכזים אלה, שם מוחלים מסננים על סמך חתימות, התנהגות, רשימות שחורות, ניתוח סטטיסטי וכללים מותאמים אישית.

במקביל, ארגונים רבים פורסים מערכות אנטי-DDoS מקומיות במרכזי הנתונים שלהם או של ספקי האינטרנט שלהם. מכשירים כגון Arbor TMS, Radware DefensePro, FortiDDoS או פתרונות F5 מסוימים אחראים על זיהוי וטיפול בהתקפות עד למגבלת קיבולת מסוימת. מקובל לשלב מערכות מקומיות אלו עם פתרון ניקוי מבוסס ענן עבור התקפות החורגות מהקיבולת שלהם.

ארכיטקטורות CDN וארכיטקטורות Anycast - כמו אלו של Cloudflare, Akamai, Fastly או Google Cloud CDN - מוסיפות שכבת הגנה נוספת על ידי פיזור העומס גיאוגרפית. על ידי פרסום שירות מאחורי CDN, התעבורה מתפזרת על פני צמתים מרובים, והתקפות נפחיות מדוללות בכך שאינן מרוכזות בנקודה אחת. יתר על כן, הן בדרך כלל משלבות חומות אש של יישומי אינטרנט (WAFs) ומדיניות הגבלת קצב ברמת HTTP.

לבסוף, חומות אש ברשת (Cisco, Palo Alto, iptables בלינוקס וכו') ו-WAFs ייעודיים (ModSecurity, Cloudflare WAF, AWS WAF) מאפשרים לך לסנן תעבורה לפי כתובת IP, פורט, דגלים ודפוסי יישומים . אמנם הם לבדם לא יעצרו מתקפת Tbps ברמת עמוד השדרה, אך הם חיוניים לחסימת וקטורי תקיפה ידועים, הגבלת חיבורים חשודים והגנה על שכבות 6 ו-7 של המחסנית.

הגנת זרימה ניתנת לתכנות וטיפול מותאם אישית עם Magic Transit

בהקשר זה של התקפות מורכבות יותר ויותר ופרוטוקולים ספציפיים יותר ויותר, צצים פתרונות כמו Programmable Flow Protection for Magic Transit של Cloudflare , המסמנים קפיצת מדרגה איכותית: הם מאפשרים לחברות לכתוב לוגיקת הפחתה משלהן ולפרוס אותה ישירות ברשת של ספק גלובלי.

הרעיון פשוט אך עוצמתי: לקוחות Magic Transit יכולים לטעון תוכניות עיבוד חבילות בעלות מצב שנכתבו ב-C. Cloudflare מאמת, קומפיל והופך את התוכניות הללו ל-eBPF, ומפעיל אותן במרחב המשתמש בתוך התשתית הגלובלית שלה. זה מאפשר להם לבדוק את תעבורת UDP של יישומים באופן מודע לפרוטוקול: הבנת כותרות ספציפיות למשחק מקוון, מערכת מסחר בתדר גבוה, שירותי VoIP או פלטפורמות סטרימינג, והחלטה, חבילה אחר חבילה, מה לאפשר ומה לחסום.

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

המסר המרכזי כאן הוא שאנחנו כבר לא מסתמכים אך ורק על חתימות ספקים גנריות והיוריסטיקה. חברת משחקי וידאו, לדוגמה, יכולה להגדיר בבירור את הזרימה הלגיטימית של פרוטוקול UDP הקנייני שלה (לחיצת יד, הודעות מיקום, שמירה על נוכחות וכו') ואילו דפוסים אופייניים להתקפה. לוגיקה זו מורכבת ונפרסת בכל נקודות הנוכחות של Cloudflare, מה שמקרב את קבלת ההחלטות לקצה הרשת.

עבור סביבות עם פרוטוקולים מותאמים אישית או יישומים עם דרישות השהייה גבוהות מאוד, אפשרות זו להפחתת התקפות DDoS עם הגנה על זרימה ניתנת לתכנות משנה את כללי המשחק: היא מוסיפה שכבה של בינה ספציפית לעסקים על גבי הגנות סטנדרטיות. וכאשר היא משולבת עם שירותי ענן כמו AWS או Azure, ועם פתרונות תוכנה מותאמים אישית (כגון אלה שפותחו על ידי חברות המתמחות בבינה מלאכותית ואנליטיקה, כמו Q2BSTUDIO), היא מאפשרת אוטומציה גדולה עוד יותר של זיהוי כללים ועדכונים על סמך איומים מתעוררים.

מדוע ספקי אינטרנט וארגונים זקוקים להגנה מתקדמת מפני DDoS

ספקי שירותי אינטרנט (ISP) וארגונים גדולים נמצאים בחזית. מתקפה גדולה מספיק יכולה להציף לא רק לקוח בודד, אלא מקטע שלם ברשת של המפעיל, ולגרום להפסקות מדורגות המשפיעות על אלפי משתמשים. לכן, מניעת פגיעה ב-DDoS הפכה לדרישה חיונית, לא לתוספת אופציונלית.

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

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

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

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

טכניקות הפחתה ספציפיות: מהגבלת קצב ועד לחור שחור

מעבר לבלוקים הטכנולוגיים העיקריים, ישנן מספר טכניקות ספציפיות המיושמות מדי יום כדי להילחם בסוגים שונים של התקפות. אחת הבסיסיות ביותר היא סינון היקפי באמצעות חומות אש ורשימות בקרת גישה (ACL) על נתבים ומתגים, וחסימת חבילות על סמך כתובת IP של המקור, כתובת IP של היעד, פורטים, דגלי TCP או גודל.

רכיב קלאסי נוסף הוא הגבלת קצב (rate limit) , הן בשכבות 3/4 והן ב-HTTP. במערכות לינוקס, iptables מציע מודולים כמו hashlimit או SYNPROXY כדי לשלוט במספר החיבורים או החבילות לשנייה המתקבלות מכתובת IP אחת. ברמת האפליקציה, פרוקסי כמו Nginx או HAProxy יכולים לקבוע מגבלות על בקשות לכל לקוח או לכל נתיב.

עבור התקפות שכבה 7, יישום אתגרים או אימות נוסף הוא שימושי מאוד . CAPTCHAs, אתגרי JavaScript ומנגנונים דומים מאפשרים הבחנה טובה יותר בין דפדפנים אמיתיים לבוטים אוטומטיים, ובכך מפחיתים את העומס על האפליקציה בפועל. ב-TCP, טכניקות כמו קובצי Cookie של SYN עוזרות לשרת להימנע מהצורך לאחסן מצב עבור כל ניסיון חיבור עד להשלמת לחיצת היד.

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

שירותי ניקוי ענן - כמו אלה המוצעים על ידי Cloudflare, Akamai, AWS Shield, Google Project Shield, Radware ואחרים - מאפשרים לך לנתב את כל התעבורה למרכזי הנתונים שלהם ולנקות אותה שם, תוך יישום כללים ספציפיים עבור וקטורים כמו הגברת Memcached, CLDAP, DNS, NTP, הצפות UDP לא מוגברות וכן הלאה. כל התקפה חסומה מזינה מודלים של למידת מכונה ומסדי נתונים של חתימות המשמשים במאמצי הפחתה עתידיים.

שיטות עבודה מומלצות ולקחים שנלמדו לנוכח מתקפות DDoS הנוכחיות

ניתן ללמוד מספר לקחים ברורים מהאירועים הגדולים של השנים האחרונות. הראשון הוא שאבטחת מכשירי IoT היא קריטית: חלק ניכר מהכוח של בוטנטים כמו Mirai, Mēris או Aisuru מגיע מנתבים ביתיים, מצלמות ומכשירים אחרים עם קושחה מיושנת וסיסמאות ברירת מחדל של היצרן.

השני הוא שעלינו לחסל וקטורי הגברה בתוך הרשתות שלנו: להשבית שירותי UDP מיותרים, לסנן תעבורה יוצאת של NTP, DNS או Memcached, להחיל כללי חומת אש המאפשרים שאילתות רק מטווחים מורשים, ולבדוק מעת לעת פורטים חשופים. כל שרת שתצורתו אינה נכונה יכולה להפוך למגבר עבור תוקף.

גילוי מוקדם של אנומליות הוא גם חיוני . כלים כגון NetFlow, sFlow, IDS/IPS (Snort, Suricata), פלטפורמות ניתוח יומנים או SIEM צריכים להיות מוגדרים להתריע ברגע שמופיעים קפיצות תנועה חריגות, שינויים פתאומיים בדפוסי חיבור או חתימות התקפה ידועות. ככל שהתגובה מופעלת מוקדם יותר, כך יש פחות זמן להסלמה של ההתקפה.

בסביבות אינטרנט, כמעט חובה להשתמש ב-WAFs מעודכנים, CAPTCHAs כאשר הם מתאימים לחוויית המשתמש, ובמטמונים או CDNs כדי לספוג חלק מהעומס. ברמת המערכת, הפעלת קובצי Cookie של SYN, התאמת ספי חיבור בו-זמני וסגירת כל שירות שאינו חיוני מפחיתים את משטח התקיפה.

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

המגמה מצביעה על התקפות מהירות, אינטנסיביות ואדפטיביות יותר ויותר, אך גם על הגנות חכמות וניתנות להתאמה אישית יותר. מינוף היכולות של פתרונות כמו Programmable Flow Protection, בשילוב עם ניטור תעבורה מתמיד, שיטות עבודה מומלצות לתצורה וארכיטקטורות ענן יתירות, מאפשר לחברות להמשיך לפעול כרגיל גם בעיצומה של סערת חבילות, תוך הגנה לא רק על הנתונים שלהן אלא גם על המוניטין שלהן ואמון הלקוחות שלהן.