הגדרת DDoS protection: מה נשבר ללא הגנת פרימטר
זינוק שיא בבקשות רק לעיתים נדירות נראה כמו תקיפה בלוגים: הערוץ נסתם במנויים, תור החיבורים במאזן העומסים גדל, והאפליקציה מתחילה להשיב לפי שאריות המשאבים. עומס יתר של הערוץ בבקשות אוכל את מרווח הביטחון שהוקצה למבצע מכירות או לשיא הבוקר, — הכשל מגיע לפני שהניטור מספיק לספק אות ברור.
מכאן פועל אפקט הדומינו: חוסר הזמינות של השירות תחת עומס פוגע דווקא בלקוחות שמביאים הכנסה, — בתשלום, בביצוע הזמנה, באזור האישי. תורן המשמרת באותו רגע מכבה את התוצאה: מפעיל מחדש צמתים, מרחיב את המאגר, מכוונן מגבלות. הסיבה — תעבורה מזיקה שהגיעה לאפליקציה — נשארת במקום וחוזרת בשיא הבא.
מסננים מאולתרים על רקע זה עלולים להיות מסוכנים יותר מהתקיפה עצמה: התראות שווא של המסנן חוסמות משתמשים אמיתיים לפי מיקום גיאוגרפי או לפי התנהגות, ויחד עם האשפה הולכות לאיבוד הזמנות אמיתיות.
הגנת פרימטר — למשל על Cloudflare — בנויה אחרת: תעבורה מזיקה נחסמת בגבול, לפני שהיא תופסת את הערוץ ואת התור של האפליקציה.
הגדרת ddos protection היא לא תיבת סימון מסומנת, אלא סט של ספים, מצבים וכללים בהתאמה לפרופיל התעבורה שלכם: היכן להפעיל בדיקה, אילו מקורות להיחשב מהימנים, באילו רמות להעלות את הרגישות כדי לא לפגוע בשלכם. בהמשך נפרט כיצד זה נסגר — מתרשים הסינון ועד סדר הפעולות ברגע התקיפה.
מה משתנה לאחר הפעלת הסינון: חמישה אפקטים מדידים
סינון תעבורה אינו מתג של «הפעל ושכח»: האפקט מתבטא במדדים שתורן המשמרת בוחן כל בוקר. להלן חמישה מדדים שמשתנים באופן צפוי אם כללי הסינון והספים הוגדרו בהתאם לפרופיל התעבורה שלכם, ולא הושארו בברירת המחדל.
זמינות תחת עומס שיא
בקשות אשפה נחסמות בפריפריה ואינן מגיעות לאפליקציות — השירות מפסיק לקרוס בשעות השיא. במקום דקות של חוסר זמינות נשארת בגרף מדף שטוח, ואין עוד צורך להרחיב את המאגר בכל זינוק. אנחנו בודקים זאת במטח סינתטי מנקודות חיצוניות, ולא לפי הדוחות של המסנן עצמו.
זמן התאוששות לאחר זינוק
התקיפה נעצרת בכניסה, שירותים פנימיים אינם צוברים תור ואינם מאבדים חיבורים. זמן ההתאוששות נמדד בעשרות שניות במקום דקות של מיתוג ידני, ובמרבית המקרים התורן לומד על הניסיון רק לאחר שנהדף — מתוך היומן.
שיעור תעבורת האשפה שנחסמה
חתימות מוגדרות וכללים התנהגותיים מסירים את עיקר העומס הטפילי — לבקאנד מגיעה רק תעבורה עם בקשות בעלות משמעות. ההבדל ניכר במספר הפניות לאפליקציה בנפח זהה של זרם נכנס: התשתית הפנימית מפסיקה להיות צוואר בקבוק.
סוג התקלות שהוסר
נעלם סוג שלם של תקלות, שסיבתן היא מיצוי חיבורים או הצפת תור תחת שטף בוטים. אירועים מסוג זה פשוט מפסיקים להיפתח, והניתוח נעשה לא לפי «למה זה נפל» אלא לפי «כמה נהדף». זה משנה גם את אופי התורנות: קריאות לילה מסיבה אחידה נעלמות.
העומס על משמרת התורנות
היקף הניתוחים הידניים מפסיק לגדול יחד עם מספר הניסיונות: תרחישים טיפוסיים סגורים בכללים, ולא בתגובה של מהנדס. המשמרת משקיעה זמן בכיול ספים ובניתוח אנומליות, ולא בכיבוי אותה תקלה שוב ושוב.
בנפרד אנו בודקים ששיאים לגיטימיים — מבצעי מכירות, קמפיינים, אינטגרציות שותפים — עוברים ללא חסימות שווא. את תרשים ההגנה אנו בונים על Cloudflare או באמצעים המובנים של הענן — הבחירה תלויה בהיכן יושבת התעבורה ומי אחראי לכללים.
השוואה בין מצבי הגנת פרימטר: מתי כל אחד מתאים
מצב ההגנה נבחר לא לפי עוצמת השירות, אלא לפי סוג התקיפות ולפי מה שקורה לתעבורה בשגרה. מכאן שלוש נקודות הסתעפות: באיזו שכבה מתקבלת ההחלטה על השלכת מנות, היכן פיזית נמצא המסנן, וכמה מהר מתבצע מיתוג המסלול בעת תקיפה.
| אפשרות | מתי מתאים | מגבלות |
|---|---|---|
| הגנה מובנית של ספק הענן | השירות יושב בענן, התקיפות הן ברשת ובנפח | סינון בשכבת האפליקציה מוגבל לתבניות, לוגיקה מדויקת לפרוטוקול שלכם אינה זמינה |
| מסנן חיצוני בפרימטר | נדרשים כללים לאפליקציה שלכם ונקודה אחודה למספר אתרים | התעבורה עוברת דרך צד שלישי: השהיה, הצפנה, היבט משפטי |
| מסנן מקומי באתר שלכם | קיימת רשת וערוץ משלכם, חשובה ריבונות הנתונים | רוחב הפס של הערוץ הוא התקרה: בהצפה התקיפה נופלת על האפלינק |
| היברידי עם מיתוג חירום | נדרש מסנן קבוע בתוספת קו תורנות לתקיפות שיא | שני סטים של כללים, ספים מתואמים, תרגולים סדירים למיתוג |
מסנן קבוע מול מצב תורנות
מסנן קבוע מעביר את התעבורה דרך קו ההגנה תמיד: הכללים נבחנו, ההתנהגות צפויה, אך השהיה מתווספת לכל בקשה. מצב התורנות מופעל רק בעת תקיפה — במיתוג DNS עם TTL קצר או בהכרזת כתובות, — ובשאר הזמן התעבורה עוברת ישירות.
ספי מצב התורנות מוגדרים לפי פרופיל התעבורה הרגיל ומורצים בתרגולים: אחרת, ברגע התקיפה מתברר שחלק מהכללים חוסמים לקוחות לגיטימיים. המגבלה של כל מצב אינה עוצמת המסנן, אלא דיוק הכללים: איסור רחב מדי פוגע בזמינות חזק יותר מהתקיפה עצמה.
סדר היישום: מביקורת תעבורה ועד מסירה לתפעול
העבודה מתנהלת כך שההגנה תופעל בלי לעצור את השירות ובלי לחסום תעבורה חיה: תחילה מתעדים כיצד הבקשות מגיעות לאפליקציה, אחר כך בוחרים את נקודת הפעלת המסנן, ורק לאחר מכן מגדירים את הספים.
ביקורת ותרשים תעבורה
אוספים מפה: דומיינים, מקורות בקשה אמיתיים, מאזני עומסים, פרוקסי, שירותים חיצוניים לפי קריאות חוזרות. בנפרד בודקים אם כתובת הלקוח נשמרת לאורך כל המסלול — מכך תלוי אם המסנן יבחין בין בוט לאדם ואם לא יחסום מבקרים תמימים.
- מתעדים את תרשים מעבר התעבורה — מנקודת הכניסה ועד האפליקציה, בציון איזה צומת מקבל מה והיכן נראות כתובות הלקוח האמיתיות.
- בוחרים את נקודת הפעלת המסנן: פרימטר ניקוי חיצוני (Cloudflare, AWS Shield, Cloud Armor), מאזן עומסים או קטע לפני שירות מסוים. מתעדים מה מסונן תמיד ומה — לפי לוח זמנים.
- מגדירים ספי הפעלה וכללים: קו בסיס של בקשות למשתמש, מגבלות קצב, סימני אנומליות, חריגים לניטור ולאינטגרציות שותפים.
- בודקים את ההגנה בתקיפת תרגול — זינוק מבוקר מקו בדיקה: אילו כללים הופעלו והאם תעבורה רגילה נכנסה לחסימה.
- מכשירים את המשמרת: כיצד לקרוא את הפאנל, מה לעשות בעת הפעלה, כיצד להחליש זמנית את המסנן בלי לפתוח את הפרימטר כולו.
- מכניסים את ההגנה לתפעול: מפעילים מצב חסימה, מקבעים את נוהל התורנות ואת נקודת השחזור המהיר.
בדיקה בזינוק תרגול
הזינוק מראה באיזה פרופיל עומס מופעל הכלל ובכמה זמן מתחדשת העבודה הרגילה של השירות. לפי התוצאות מכיילים את הספים: מסירים חסימות מיותרות ומחמירים את מה שהחמיץ עומס. בסיום ההגנה מופעלת, נבדקה ונמסרת למשמרת — עם נוהל ונקודת שחזור.
מסמכים ותוצרים שאנו מוסרים לאחר היישום
יישום ההגנה מסתיים לא בהפעלת הסינון, אלא במסירת ערכה שלפיה הצוות שלכם ממשיך לעבוד בלעדינו: מתמצא בתרשים, משנה ספים, מכשיר תורן. להלן מה שנשאר בידיכם.
- תרשים מעבר התעבורה — מסלול הבקשה מהקו החיצוני ועד מאזן העומסים והאפליקציות, נקודות הסינון, קטעים שההגנה אינה מכסה.
- קונפיגורציה של כללי הסינון והספים: חתימות, מגבלות קצב בקשות, רשימות חריגים, מצב תצפית לכללים חדשים.
- מדיניות גישה לפאנל הניהול — חשבונות נפרדים במקום חשבון משותף, אימות דו-שלבי חובה, גבולות הרשאות לפי תפקידים.
- יומן שינויי הגדרות — מה, מתי ולמה תוקן, מי אישר, כיצד לשחזר: בלעדיו ניתוח האירוע הופך לניחושים.
- הנחיות לתיקון עצמאי של ספים — היכן הגבול הבטוח והיכן מתחילות חסימות של לקוחות חיים.
- רשימת בדיקה לאחר שינויים — סט בקשות ותרחישים שבאמצעותם התורן מוודא שתעבורה לגיטימית עוברת.
נוהל פעולות בעת תקיפה
זהו מסמך בן עמוד-שניים שקוראים ברגע האירוע, ולא ביום שגרתי. בו — סימני התקיפה וספי ההפעלה, סדר ההסלמה עם שמות וערוצי קשר, הפעולות הראשונות של משמרת התורנות, קריטריונים למעבר לפרופיל הגנה מוגבר ולחזרה לרגיל. בנפרד — מה לתעד ביומן לאחר מכן.
מקרה בוחן: כיצד הסרנו זינוקים של תקלות בשיא העומס
הלקוח — שירות עם שיא יומי מובהק: שעות הערב ותחילת מבצעי המכירות הביאו גידול כפול ומכופל בפניות, ואיתן הגיעה תעבורת אשפה — סורקים, בוטים, חזרות על בקשות לעמודים דינמיים. הפרימטר העביר הכול ללא הבחנה, והאפליקציה נתקלה בתקרה לפני שהגיע העומס האמיתי.
מה היה קודם
השיא נמשך 40–60 דקות. שיעור הבקשות שהגיעו לאפליקציה ירד עד 55% — השאר אבד בהמתנה לתשובה. זמן אי-הזמינות בשיא הגיע עד 12 דקות בערב: חלק מהמשתמשים ראו שגיאות ועזבו. המהנדסים טיפלו ב-5–7 אירועי לילה בחודש, כל אחד — עם הרחבה ידנית של יכולות וניתוח יומנים.
מה קרה לאחר מכן
הגנת הפרימטר הוקמה על Cloudflare והכללים פוזרו לפי שכבות: תחילה סינון לפי התנהגות ומוניטין כתובות, אחר כך הגבלת קצב למסלולים רגישים, ורק לאחר מכן — התור לאפליקציה. שיעור האשפה שנהדפה — כ-30% מהזרם הנכנס, ושיעור הבקשות המועילות שהגיעו לאפליקציה עלה ל-97%.
במהלך חודש של תצפית לא נרשמה אי-זמינות בשיא, והשגיאות בכניסה נעלמו מהדוחות. ניתוחי הלילה הוחלפו בניתוח אנומליות מתוכנן אחת לשבוע. הסטטי והמטמון מוגשים מהפרימטר, ולכן גידול השיא הפסיק לעבור לאפליקציה.
במה שונה סינון DDoS ברשת מהגנת האפליקציה
מסנן רשת עובד עם הזרם, ולא עם תוכן הבקשה: הוא מעריך נפח, כתובת מקור, קצב חיבורים חדשים והתפלגות לפי פורטים. מסנן כזה מדכא זינוקים בנפח — הגברות, SYN-flood, רשתות בוטים — לפני שהתעבורה תופסת את הערוץ עד לשרתים. אבל הוא אינו מבחין בין בקשה מזיקה למועילה, אם זו נראית כרגילה.
הגנת האפליקציה מסתכלת לתוך הבקשה: מסלול, כותרות, גוף, קצב פניות לטופס מסוים, התנהגות הסשן. כאן נהדפות תקיפות ממוקדות — זינוק על עמוד ההזדהות, ניסויי ניחוש פרטי חשבון, בקשות איטיות שמחזיקות חיבור פתוח וכמעט אינן ניכרות בנפח.
| שכבה | מה נהדף | מה נשאר לא מכוסה |
|---|---|---|
| רשת ותעבורה | זרמים בנפח, הגברות, SYN-flood | תקיפות איטיות ותעבורה «לגיטימית» עם צורת בקשה מועילה |
| אפליקציה | זינוקים על מסלול מסוים, ניסויי ניחוש, אנומליות סשן | נפח שסותם את הערוץ עוד לפני ניתוח הבקשה |
| תרשים משולב | נפח בכניסה בתוספת אנומליות לפי משמעות ביציאה | דורש ספים מתואמים, אחרת נחתכת תעבורה מועילה |
אף שכבה אינה מספקת בפני עצמה. בלי רשת, הערוץ ומאזן העומסים נתקלים בתקרה לפני שכללי האפליקציה פועלים, והבקשה פשוט אינה מגיעה אליהם. בלי אפליקציה, כל מה שנראה כמו פנייה תקינה עובר ישר — המסנן רואה זרם אחיד ואינו מגיב.
כלים כמו Cloudflare נותנים את שני המישורים בקו אחד: תחילה מופעלים כללי הרשת, אחר כך כללי האפליקציה עם ספים בהתאם לפרופיל התעבורה האמיתי. שילוב השכבות הוא התרשים העובד — המסנן מחזיק את הנפח, האפליקציה חותכת אנומליות, והספים מוגדרים לפי הנתונים בשטח, ולא לפי העין.
ספקות טכניים: התראות שווא, השהיות, עקיפות
התראות שווא אינן תכונה של ההגנה, אלא תוצאה של ספים שהוגדרו לפי העין. לכן הכללים עוברים תחילה במצב תצפית: צוברים לוגים, מנתחים לפי נקודות קצה, מוסיפים חריגים לקריאות חוזרות של מערכות תשלום, לקוחות ניידים ובדיקות זמינות. החסימה מופעלת רק כשבהלוג לא נותרו פגיעות שווא.
את ההשהיה קובע לא הסינון, אלא מקום הבדיקה. בדיקת בוטים מוצבת על תשובות ניתנות למטמון בקצה, כדי שהתעבורה המסוננת תגיע לשרתים; ל-API משאירים ניתוח התנהגותי ללא challenge. זמן התגובה באחוזון ה-95 נמדד לפני ואחרי — ההפרש בדרך כלל בתוך שיעור הטעות.
מה לעשות בעת שינוי תרשים הפריסה?
את הכללים אנחנו מצמידים לשמות ולתגיות, ולא לכתובות, ולכן בעת מעבר או הוספת מאזן עומסים משתנה רק נקודת קליטת התעבורה. את הסדר מקבעים מראש: מקימים קו חדש, בודקים את הסינון על זרם בדיקה, ואז מבצעים מיתוג של הפעיל.
האם ההגנה מפריעה לערוץ מאובטח?
לא: הניתוח מתבצע לפי מטא-נתונים של החיבור, והתוכן מנותח לאחר טרמינציה. קריאות פנימיות משאירים על אימות הדדי — המסנן אינו חוסם תעבורה מהימנה ואינו מניח להחלפה.
מי אחראי לספים לאחר המסירה?
את ההגדרות מוסרים עם תיעוד: מהו הכלל, על איזה מדד הוא מגיב, מה קורה בעת הפעלה וכיצד לשחזר. מכאן הספים מנוהלים אצל הצוות שלכם, ואנחנו נשארים בתמיכה ובוחנים מחדש את הכללים עם גידול העומס.
נדון במשימה שלכם: מה לשלוח להערכה ולתוכנית
כדי שההערכה ותוכנית היישום יתבססו על התשתית שלכם, ולא על שיקולים כלליים, די בכמה נתוני רקע. לפיהם אנחנו קובעים את נקודת סינון התעבורה, את מצבי עבודת ההגנה ואת סדר ההפעלה ללא השבתה.
- תרשים מעבר התעבורה. היכן נמצא מאזן העומסים, היכן מתבצע הפענוח של התעבורה, אילו ערוצים ונקודות כניסה חיצוניות מעורבים. מכך תלוי אם ההגנה מוצבת לפני מאזן העומסים או אחריו.
- רשימת השירותים בפרימטר. אילו אפליקציות ופורטים פונים החוצה, מה קריטי ומה ניתן לסגור זמנית במהלך תקיפה.
- היסטוריית אירועים. מה כבר קרה: זינוקים בערוץ, הצפה בשכבת האפליקציה, ניסיונות למצות חיבורים. תקיפות קודמות מתארות את פרופיל התעבורה בדיוק רב יותר מכל שאלון.
- דרישות זמינות. זמן תגובה מותר, התנהגות בעת התראות שווא, אילו מקורות לגיטימיים אסור לחסום — אינטגרציות שותפים, לקוחות ניידים, רשתות משרד.
- פרופיל עומס צפוי. בכמה מונים עולה השיא על התעבורה הרגילה, האם יש זינוקים עונתיים ואירועים חד-פעמיים שאליהם נערכים מראש.
- אחראים בצד שלכם. מי נותן הרשאות לפאנל ניהול ההגנה ולרשומות הדומיין, מי מאשר את חלון העבודה ועם מי אנחנו מסלימים בלילה במהלך תקיפה.
עם סט כזה אנחנו חוזרים עם הערכה ותוכנית יישום: היכן מוצבת ההגנה, אילו ספים אנו קובעים, כיצד בודקים את הכללים על תעבורה חיה וכיצד משחזרים בתיקון אחד. תארו את משימת ההגנה — בהמשך נבהיר את הפרטים בשאלות.