הגדירו מה נפגע ובאיזה חלון זמן
רשמו אם התקלה היא בכל האתר, בנתיב מסוים או רק בפעולה עסקית. ציינו זמן ואזור זמן, משך, אזורים שבהם דווחה ותוצאה שנצפתה. בדקו אם היה קמפיין, שינוי רכיב, משימה כבדה או תקלה אצל ספק. נקודת השוואה רגילה צריכה להתאים לאותו תהליך ככל האפשר.
לא מודדים את האתר באמצעות יצירת עומס נוסף בזמן הבירור. אפשר להתחיל במידע קיים, בדיקות תפקוד מצומצמות וגורמי התפעול המורשים. חוסר נתונים הוא פער לאבחון, לא סיבה להכריז על מתקפה רק מפני שאין הסבר אחר.
חברו אותות בלי להפוך סימן יחיד להוכחה
הטבלה היא מסגרת אבחון מקורית. היא אינה מערכת לזיהוי תוקפים ולא סף אוטומטי לאירוע. לכל הסבר מחפשים ראיה תומכת וגם ראיה שיכולה להחליש אותו. ייתכן שילוב של תעבורה עוינת וחולשת קיבולת, ולא תמיד תהיה סיבה יחידה.
| תצפית | הסבר אפשרי נוסף | מידע להמשך בירור |
|---|---|---|
| מספר בקשות עלה | קמפיין או סריקה לגיטימית | נתיבים, קצב והקשר |
| CPU או מסד עמוסים | שאילתה או משימה לא יעילה | תהליך, זמן ושינוי אחרון |
| שגיאות רק בקופה | תלות תשלום או קוד | לוגים ותפקוד רכיב |
| הרבה חסימות בקצה | מנגנון הגנה פעיל | כמה הגיע למקור ומה נפגע |
| המקור עמוס בלי קפיצה בקצה | נתיב אחר או בעיית יישום | כיסוי, רשת ותהליכי מארח |
| בדיקה אחת נכשלת | בעיה במסלול הבדיקה | מידע ממקורות נוספים |
הבחינו בין נתוני קצה לנתוני המקור
Cloudflare מתעדת הגנות וניתוח DDoS בשכבות שונות. נתון בקצה מתאר את מה שהמנגנון ראה בהיקף שלו; הוא אינו בהכרח מודד את כל המשאבים והתהליכים במארח. השוו זמנים, תעבורה שטופלה, תנועה שהגיעה למקור וזמינות עסקית. אל תחברו מספרים מלוחות שונים כאילו הם אותו מדד.
בדקו גם כיסוי של שירותים ונתיבים, לפי התצורה בפועל. מידע מדוגם או מוגבל לתוכנית צריך להישאר מסומן כך. רשימת מדינות או כתובות אינה לבדה הוכחה לכוונה עוינת, וכתובת שנראית ברישום אינה תמיד זהות המשתמש המקורי בלי הבנת שרשרת הרשת.
צמצום חייב להתאים לשכבה ולשמור תפקוד מותר
לפני שינוי קובעים מי מאשר ומהי המטרה: צמצום תנועה מסוימת, הגנת רכיב או טיפול בתלות. חסימה, הגבלת קצב ואתגר אינטראקטיבי אינם אותו מנגנון, ולא מתאימים אוטומטית לכל לקוח או חיבור שרת. לא מפעילים אוסף כללים מחמיר בלי בדיקת ההשפעה.
תעדו תנאי שינוי, דרך חזרה ומה לא נבדק. אם הבעיה היא משאב או שאילתה, תוספת סינון אינה בהכרח פותרת את המקור. אם יש תעבורה עוינת, הגדלת שרת לבדה אינה הוכחה שהאירוע הוכל. התאמת צמצום נעשית עם ספקי התשתית והגורם המורשה.
דוגמה: עומס בקופה הופיע אחרי שינוי רכיב
התרחיש להמחשה בלבד. החנות מציגה זמני תגובה ארוכים ומנהל חושד ב-DDoS. ציר הזמן מראה שינוי רכיב, והעומס מתרכז בתהליך מסוים גם בלי קפיצה מקבילה בתעבורה. הצוות בודק את ההסבר הזה לצד נתוני ההגנה, ולא מסיק שכל בעיית עומס היא תקיפה.
בתרחיש אחר מופיעים דפוסי תעבורה חריגים יחד עם השפעה על המקור. גם אז נדרשות ראיות והחלטת צמצום עם בדיקת תפקוד. אין להשתמש בתרחיש כדוח מתקפה אמיתי או כהוכחה ליכולת לייחס אירוע לגורם מסוים.
סגרו בירור לפי מה שנמדד ומה שנשאר פתוח
המסירה כוללת חלון זמן, מקורות נתונים, השערות, פעולות ותוצאות בתנאים שנבדקו. ירידה בכמות בקשות אינה בהכרח חזרה של כל התהליכים. בדקו גם לקוחות וחיבורים מותרים לפי ההיקף, ורשמו מגבלה אם לא ניתן היה לאמת חלק מהכיסוי.
ב-CyberFixCrew אפשר לברר Cloudflare, Linux ותפקוד אתר לפי השירותים הקיימים. אין כאן שירות חדש לניסוי DDoS, הבטחת חסינות או זמן תגובה קבוע. אם מדובר בפגיעה פעילה, מתאמים ערוצי טיפול וסמכויות במקום להמשיך בניסויי תעבורה עצמאיים.
