בעזרת Google Cloud Armor Enterprise, אתם יכולים להשתמש ב-Cloud Logging וב-Cloud Monitoring כדי לנתח מתקפות DDoS ואת המקורות שלהן.
Google Cloud Armor מזהה באופן אוטומטי מתקפות בשכבת הרשת (שכבה 3) ובשכבת התעבורה (שכבה 4) ומצמצם את ההשפעה שלהן. הוא מבצע את הפעולות האלה לפני שהוא אוכף את מדיניות האבטחה ומעריך רק בקשות תקינות בהתאם לכללי מדיניות האבטחה. לכן, תנועת גולשים שירדה כתוצאה מהגנה מפני DDoS בזמינות תמידית לא מופיעה בטלמטריה של מדיניות האבטחה או של שרתי הקצה.
במקום זאת, המדדים של Cloud Logging ו-Cloud Monitoring לאירועים של צמצום מתקפות DDoS הם חלק מהתכונה 'חשיפה למתקפות DDoS', שזמינה באופן בלעדי למנויי Google Cloud Armor Enterprise. בקטעים הבאים מוסבר איך להשתמש ב-Logging וב-Monitoring כדי לנתח מתקפות DDoS ואת המקורות שלהן. אפשר לראות את המתקפות מסוג DDoS בסוגים הבאים של איזון עומסים:
- מאזן עומסים גלובלי חיצוני של אפליקציות (ALB)
- מאזן עומסים קלאסי של אפליקציות (ALB)
אם אתם משתמשים בהפניה לשירותים בפרויקטים שונים, תוכלו לראות את נתוני הטלמטריה והרישום שמשויכים לזיהוי התקפות DDoS רק בפרויקט המארח או בפרויקט השירות שכולל את הקצה הקדמי של מאזן העומסים ואת מפת ה-URL. אי אפשר לראות את הטלמטריה והרישום בפרויקט השירות שכולל את שירותי ה-Backend.
כדי להבטיח רישום ודיווח תקינים, ל-Cloud Armor נדרשת גישה ליומנים הבאים. הם צריכים להיות מאוחסנים ב-Cloud Logging או להיות מנותבים אל קטגוריה של רישום ביומן שאפשר לגשת אליה ב-Cloud Armor.
networksecurity.googleapis.com/dos_attacknetworksecurity.googleapis.com/network_dos_attacknetworksecurity.googleapis.com/network_dos_attack_mitigations
יומני אירועים של צעדים לצמצום נזקים ממתקפות ב-Cloud Logging
כש-Cloud Armor מפחית מתקפות DDoS, הוא יוצר שלושה סוגים של רשומות ביומן האירועים. פורמטים של יומנים כוללים ניתוחים של כתובות IP של לקוחות ומיקומים גיאוגרפיים, כשזה אפשרי. בקטעים הבאים מופיעות דוגמאות לפורמט של יומן לכל סוג של יומן אירועים:
הטיפול התחיל
{
"id": "20220101_1235_mitigiation_1.2.3.4",
"mitigationType": "MITIGATION_STARTED",
"targetVip": "1.2.3.4",
"totalVolume": {
"pps": "1234000",
"bps": "9876000000"
},
"started": {
"totalAttackVolume": {
"pps": "1000000",
"bps": "9000000000"
},
"topSourceIp": [
{
"ipAddress": "1.2.3.4",
"volume": {
"pps": "10000",
"bps": "2000000"
}
},
{
"ipAddress": "2.3.4.5",
"volume": {
"pps": "5000",
"bps": "1000000"
}
}
],
"topSourceGeo": [
{
"geo": "US",
"volume": {
"pps": "100000",
"bps": "20000000"
}
}
]
}
}
הטיפול נמשך
{
"id": "20220101_1235_mitigiation_1.2.3.4",
"mitigationType": "MITIGATION_ONGOING",
"targetVip": "1.2.3.4",
"totalVolume": {
"pps": "1234000",
"bps": "9876000000"
},
"ongoing": {
"totalAttackVolume": {
"pps": "1000000",
"bps": "9000000000"
},
"topSourceIp": [
{
"ipAddress": "1.2.3.4",
"volume": {
"pps": "10000",
"bps": "2000000"
}
},
{
"ipAddress": "2.3.4.5",
"volume": {
"pps": "5000",
"bps": "1000000"
}
}
],
"topSourceGeo": [
{
"geo": "US",
"volume": {
"pps": "100000",
"bps": "20000000"
}
}
]
}
}
הטיפול הסתיים
{
"id": "20220101_1235_mitigiation_1.2.3.4",
"mitigationType": "MITIGATION_ENDED",
"targetVip": "1.2.3.4",
"totalVolume": {
"pps": "2314000",
"bps": "9768000000"
},
"ended": {
"attackDurationSeconds": 345
}
}
במסוף Google Cloud , עוברים לדף Logs Explorer ומציגים את המשאב ProtectedEndpoint.
אפשר גם לראות את network_dos_attack_mitigations שם היומן.
מדדים של Cloud Monitoring
מדדי טלמטריה של צעדים לצמצום השפעת התקפות DDoS מוצגים במשאב Protected Network Endpoint (ProtectedEndpoint), שזמין רק לכתובות IP וירטואליות בשכבת האפליקציות (שכבה 7) שרשומות ב-Google Cloud Armor Enterprise. אלה המדדים שזמינים:
- בייט של תעבורת נכנסת (
/dos/ingress_bytes) - מנות נכנסות (
/dos/ingress_packets)
אפשר לקבץ ולסנן את המדדים הקודמים לפי התוויות הבאות:
| תווית | ערך |
|---|---|
project_id |
מזהה הפרויקט שרשום ל-Cloud Armor Enterprise. |
location |
המיקום של נקודת הקצה המוגנת. |
vip |
כתובת ה-IP הווירטואלית של נקודת הקצה המוגנת. |
drop_status |
ערכים אפשריים:
|
נכנסים לדף Metrics Explorer במסוף Google Cloud .
הסבר על מדדי טלמטריה של כתובות IP וירטואליות עם נפחי תנועה נמוכים
לכתובות IP וירטואליות (VIP) שמקבלות פחות מ-100,000 מנות בשנייה, מומלץ להשתמש בחלון זמן ארוך יותר כדי להציג מדדים ב-Cloud Monitoring. לדוגמה, אם משתמש VIP עם נפח תנועה גבוה משתמש בערך ALIGN_RATE של דקה אחת, אנחנו ממליצים במקום זאת על ערך ALIGN_RATE של 10 דקות.
שימוש בחלון זמן ארוך יותר עוזר לצמצם את נפח הארטיפקטים שנובעים מיחס אות לרעש נמוך.
בנוסף, חלק מהרכיבים של קצב ההפלה של התנועה על ידי Cloud Armor (קצב ההפלה) מוסקים באמצעים סטטיסטיים, ויכול להיות שהם פחות מדויקים עבור כתובות VIP עם תנועה נמוכה. המשמעות היא שבמהלך מתקפת DDoS, שיעור ההשמטה שדווח על ידי Cloud Monitoring עשוי להיות נמוך מעט משיעור ההשמטה האמיתי. השיטה הזו מצמצמת את האפקטים הסטטיסטיים שיכולים להוביל להערכת יתר של נפח התנועה שנחסם, במיוחד עבור כתובות VIP שמקבלות נפח תנועה נמוך ולא נמצאות תחת מתקפה.