הכל רע מאוד או סוג חדש של יירוט תנועה

13 במרץ לקבוצת העבודה RIPE נגד התעללות התקבלה הצעה רואים בחטיפת BGP (hjjack) כהפרה של מדיניות RIPE. אם ההצעה תתקבל, לספק האינטרנט המותקף באמצעות יירוט תעבורה תהיה הזדמנות לשלוח בקשה מיוחדת לחשיפת התוקף. אם צוות הביקורת יאסוף מספיק ראיות תומכות, ה-LIR שהיה המקור ליירוט ה-BGP ייחשב כפולש וניתן לשלול ממנו את סטטוס ה-LIR שלו. היו גם כמה ויכוחים נגד זה שינויים.

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

במהלך השנים האחרונות, רק קונפליקטים כמו MOAS (מערכת אוטונומית מרובת מוצא) כוסו בעיתונות בתור יירוט BGP. MOAS הוא מקרה מיוחד שבו שתי מערכות אוטונומיות שונות מפרסמות קידומות מתנגשות עם ASNs מתואמים ב-AS_PATH (ה-ASN הראשון ב-AS_PATH, להלן ASN מקור). עם זאת, אנו יכולים למנות לפחות 3 סוגים נוספים יירוט תנועה, המאפשר לתוקף לתפעל את התכונה AS_PATH למטרות שונות, כולל עקיפת גישות מודרניות לסינון וניטור. סוג התקפה ידוע פילוסובה-קאפלי - הסוג האחרון של יירוט כזה, אבל בכלל לא בחשיבותו. בהחלט ייתכן שזהו בדיוק סוג הפיגועים שראינו בשבועות האחרונים. לאירוע כזה יש אופי מובן והשלכות חמורות למדי.

מי שמחפש את גרסת TL;DR יכול לגלול אל הכתובית "מתקפה מושלמת".

רקע רשת

(כדי לעזור לך להבין טוב יותר את התהליכים המעורבים באירוע זה)

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

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

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

תַקרִית

לפני מספר שבועות קיבלנו תלונה מאחד המשתמשים שלנו. ראינו מסלולים עם קידומות המקור שלו ASN ו-/25, בעוד המשתמש טען שהוא לא פרסם אותם.

TABLE_DUMP2|1554076803|B|xxx|265466|78.163.7.0/25|265466 262761 263444 22356 3491 2914 9121|INCOMPLETE|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.163.7.128/25|265466 262761 263444 22356 3491 2914 9121|INCOMPLETE|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.163.18.0/25|265466 262761 263444 6762 2914 9121|INCOMPLETE|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.163.18.128/25|265466 262761 263444 6762 2914 9121|INCOMPLETE|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.163.226.0/25|265466 262761 263444 22356 3491 2914 9121|INCOMPLETE|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.163.226.128/25|265466 262761 263444 22356 3491 2914 9121|INCOMPLETE|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.164.7.0/25|265466 262761 263444 6762 2914 9121|INCOMPLETE|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.164.7.128/25|265466 262761 263444 6762 2914 9121|INCOMPLETE|xxx|0|0||NAG||
דוגמאות להודעות לתחילת אפריל 2019

NTT בנתיב עבור הקידומת /25 הופך אותו לחשוד במיוחד. LG NTT לא היה מודע למסלול זה בזמן התקרית. אז כן, אופרטור כלשהו יוצר AS_PATH שלם עבור הקידומות האלה! בדיקה של נתבים אחרים מגלה ASN אחד מסוים: AS263444. לאחר שבדקנו מסלולים אחרים עם מערכת אוטונומית זו, נתקלנו במצב הבא:

TABLE_DUMP2|1554076800|B|xxx|265466|1.6.36.0/23|265466 262761 263444 52320 9583|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.6.38.0/23|265466 262761 263444 52320 9583|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.23.143.0/25|265466 262761 263444 22356 6762 9498 9730 45528|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.23.143.128/25|265466 262761 263444 22356 6762 9498 9730 45528|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.24.0.0/17|265466 262761 263444 6762 4837|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.24.128.0/17|265466 262761 263444 6762 4837|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.26.0.0/17|265466 262761 263444 6762 4837|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.26.128.0/17|265466 262761 263444 6762 4837|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.64.96.0/20|265466 262761 263444 6762 3491 4760|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.64.112.0/20|265466 262761 263444 6762 3491 4760|IGP|xxx|0|0||NAG||
נסה לנחש מה לא בסדר כאן

נראה שמישהו לקח את הקידומת מהמסלול, חילק אותה לשני חלקים ופרסם את המסלול עם אותו AS_PATH עבור שתי הקידומות הללו.

TABLE_DUMP2|1554076800|B|xxx|263444|1.6.36.0/23|263444 52320 9583|IGP|xxx|0|0|32:12595 52320:21311 65444:20000|NAG||
TABLE_DUMP2|1554076800|B|xxx|263444|1.6.38.0/23|263444 52320 9583|IGP|xxx|0|0|32:12595 52320:21311 65444:20000|NAG||
TABLE_DUMP2|1554076800|B|xxx|61775|1.6.36.0/23|61775 262761 263444 52320 9583|IGP|xxx|0|0|32:12595 52320:21311 65444:20000|NAG||
TABLE_DUMP2|1554076800|B|xxx|61775|1.6.38.0/23|61775 262761 263444 52320 9583|IGP|xxx|0|0|32:12595 52320:21311 65444:20000|NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.6.36.0/23|265466 262761 263444 52320 9583|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.6.38.0/23|265466 262761 263444 52320 9583|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|28172|1.6.36.0/23|28172 52531 263444 52320 9583|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|28172|1.6.38.0/23|28172 52531 263444 52320 9583|IGP|xxx|0|0||NAG||
מסלולים לדוגמה עבור אחד מצמדי הקידומת המפוצלים

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

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

דרך הכישלון

קודם כל. כיצד נוכל לקבוע אילו נתבים קיבלו מסלולים מיורטים כאלה ומי ניתן לנתב את התנועה שלהם כיום? חשבנו שנתחיל עם /25 קידומות מכיוון ש"פשוט לא יכולות להיות להן הפצה גלובלית". כפי שאתה יכול לנחש, טעינו מאוד. המדד הזה התברר כרועש מדי ומסלולים עם קידומות כאלה יכולים להופיע אפילו ממפעילי Tier-1. לדוגמה, ל-NTT יש כ-50 קידומות כאלה, אותן היא מפיצה ללקוחותיה. מצד שני, המדד הזה גרוע מכיוון שניתן לסנן קידומות כאלה אם האופרטור משתמש סינון קידומות קטנות, בכל הכיוונים. לכן, שיטה זו אינה מתאימה לאיתור כל המפעילים שהתנועה שלהם הופנתה בעקבות אירוע כזה.

עוד רעיון טוב שחשבנו היה להסתכל עליו POV. במיוחד עבור מסלולים שמפרים את כלל maxLength של ה-ROA המתאים. בדרך זו נוכל למצוא את מספר ה-ASN של המקור השונים עם הסטטוס לא חוקי שהיו גלויים ל-AS נתון. עם זאת, יש בעיה "קטנה". הממוצע (חציון ומצב) של מספר זה (מספר ה-ASN של מקורים שונים) הוא בערך 150, וגם אם נסנן קידומות קטנות, הוא נשאר מעל 70. למצב עניינים זה יש הסבר פשוט מאוד: יש רק מעט מפעילים שכבר משתמשים במסנני ROA עם מדיניות "איפוס מסלולים לא חוקיים" בנקודות כניסה, כך שבכל מקום שבו מופיע מסלול עם הפרת ROA בעולם האמיתי, הוא יכול להתפשט לכל הכיוונים.

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

• הקידומת לא נראתה בשום מקום קודם לכן;
• מקור ASN (תזכורת: ASN ראשון ב-AS_PATH) חוקי;
• ה-ASN האחרון ב-AS_PATH הוא ה-ASN של התוקף (במקרה שהשכן בודק את ה-ASN של השכן בכל המסלולים הנכנסים);
• מקור ההתקפה מספק יחיד.

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

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

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

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

BGP4MP|1554905421|A|xxx|263444|178.248.236.0/24|263444 6762 197068|IGP|xxx|0|0|13106:12832 22356:6453 65444:20000|NAG||
BGP4MP|1554905421|A|xxx|263444|178.248.237.0/24|263444 6762 197068|IGP|xxx|0|0|13106:12832 22356:6453 65444:20000|NAG||
דוגמה עדכנית לניסיון ליירט את מרחב הכתובות שלנו

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

התקפה מושלמת

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

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

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

אז יש לנו רווח ברור לתוקף וחוסר אבטחה. שילוב נהדר!

מה עלי לעשות?

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

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

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

הגישה השנייה היא להעניש את התוקף ואת מי שהוא מהווה עבורם נקודה קריטית (עבור מסלולים טובים) על ידי ניתוק הגישה של המסלולים שלך לתוקף. ניתן לעשות זאת על ידי הוספת ה-ASN של התוקף ל-AS_PATH של המסלולים הישנים שלך ובכך לאלץ אותם להימנע מאותו AS באמצעות מנגנון זיהוי הלולאה המובנה ב-BGP לטובתך.

מקור: www.habr.com