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

מדוע הגנת DDoS מפספסת תקיפות התנהגותיות

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

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

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

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

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

מה נותן מיתון תעבורה אדפטיבי

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

זמן האיתור וההפעלה האוטומטית

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

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

חסימות שווא של משתמשים אמיתיים

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

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

מצבי הגנת DDoS: קבוע, לפי דרישה, היברידי

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

מצב קבוע ומצב לפי דרישה

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

מתי סכמה היברידית מוצדקת

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

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

שלבי הטמעת ניתוח התנהגותי של תעבורה

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

ביקורת תעבורה ובניית קו בסיס

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

1. ביקורת תעבורה — מלאי של נקודות הכניסה, ניתוח היסטוריית הפניות והתקריות, זיהוי השירותים שבהם השבתה אינה נסבלת.
2. סכמת ההפעלה — תחילה מצב תצפית עם שיקוף הזרימה; החסימה נדלקת בשלב נפרד, לאחר בדיקה.
3. אימון המודל על התעבורה שלכם — הפרופילים נבנים על נתוני הלקוח, כולל מבצעים וזינוקים עונתיים, ולא רק על תבניות תקיפה טיפוסיות.
4. כיוונון ספים — בוחרים רגישות כך שהזינוק נתפס מהר, ולקוחות לגיטימיים אינם נכנסים לחסימה.
5. בדיקת ההגנה תחת עומס — משחזרים תרחישים על זרימת בדיקה, מודדים את שיעור התראות השווא ואת זמן התגובה.
6. מסירה — נהלי תורנות, לוחות ניטור, ניתוח תקריות והדרכת המשמרת.

כיוונון ספים ובדיקה תחת עומס אמיתי

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

סכמות סינון, נהלים ומסירה לצוות

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

מה כולל חבילת המסמכים הנמסרת

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

את המסמכים אנחנו מנהלים במעגל שלכם ובשפת התיאורים שלכם — לאחר המסירה דבר אינו נשאר «בראש» של הספק. בנפרד אנחנו מעבירים את ההגדרות לצוות: מנתחים הפעלות אמיתיות על הנתונים שלכם, מראים כיצד כלל משתנה וכיצד בודקים את התוצאה.

מקרה בוחן: צמצום חסימות שווא בתקיפות שיא

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

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

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

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

מדדים לפני ואחרי ההטמעה

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

במה ניתוח התנהגותי שונה מניתוח חתימות?

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

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

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

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

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

ספקות טכניים לפני ההטמעה

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

כמה נתונים דרושים כדי שהמודל ילמד?

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

האם זמן התגובה של השירות יגדל?

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

מה יצטרך להשתנות בארכיטקטורה?

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

כיצד להוציא את ההגנה מכלל פעולה בלי השבתה?

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

מה לדון בו בניתוח המשימה הראשון

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

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

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