איך לקרוא חילופי IKE_SA_INIT חדשים בקובץ לכידה

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

ראשית, ודאו שהלכידה מתחילה בהתחלה

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

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

tcpdump -i any -n -s 0 -w fresh-ike.pcap 'udp port 500 or udp port 4500'

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

שנית, קראו את הכותרת לפני המטענים

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

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

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

שלישית, התאימו את הבקשה לתשובה שלה

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

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

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

רביעית, הפרידו את IKE מכל השאר בפורט 4500

פורט 4500 נושא שלושה דברים שנראים דומים בתצוגה מסוכמת: IKE מאחורי סמן non-ESP אפסי של ארבעה בתים, ESP עטוף שמיקום הסמן שלו מחזיק SPI שאינו אפס, ו-keepalive קצרים. הסמן הזה הוא מה שמפריד IKE מ-ESP עטוף, אז קראו את הבתים האלה לפני שתתייגו את התעבורה כ-IKE. תווית לכידה שקוראת 4500 היא מספר פורט, לא פרוטוקול.

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

עקבו אחרי שני הפורטים עבור אותו ניסיון, כי IKE יכול לעבור ל-4500 לאחר זיהוי NAT למרות שנפתח ב-500. עקבה שסוננה רק ב-500 נראית שקטה בדיוק כשהמשא ומתן הצליח ועבר מקום. הרחיבו את הסינון וקראו שוב את אותו חלון זמן לפני שתסיקו מסקנה מהיעדרות.

מה משמעות השקט בנקודת תצפית אחת

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

ICMP unreachable רלוונטי מוסיף ראיה, אבל קראו את החבילה המצוטטת שבתוכו וציינו את כתובת ההתקן ששלח אותו.

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