ike-scan אינו מקבל תשובה משער IPsec פעיל

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

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

שלב 1: קראו את ההצעה שהכלי שולח

המצב הראשי מתחיל במטען SA שמפרט את הטרנספורמציות שהיוזם יקבל, ו-ike-scan ממלא את הרשימה מתוך ברירת מחדל מהודרת. מערך ברירת המחדל ישן בכוונה: DES ו-3DES להצפנה, MD5 ו-SHA1 לגיבוב, קבוצות 1 ו-2 לחילופי המפתחות, מפתחות משותפים מראש לאימות. בלי AES, בלי SHA-2, בלי קבוצה 14. שער שמוגדר ל-AES-256 עם SHA-256 ו-modp2048 לא חולק איתו דבר.

יש מימושים שמשיבים לבדיקה לא תואמת באמצעות הודעת NO-PROPOSAL-CHOSEN. אחרים פשוט מפילים אותה, וזה נפוץ במכשירים שמתייחסים לעמיתים לא מוכרים כרעש. כך או כך הסריקה לא מדפיסה דבר, והאין הזה זהה למה שנראה UDP 500 מסונן מבחוץ, כפי שתיעוד פרויקט ike-scan מבהיר לגבי מערך ברירת המחדל.

שלב 2: הציעו הצעה מודרנית אחת

החליפו את מערך ברירת המחדל באפשרות --trans. צורת התכונות לוקחת את מספרי תכונות IKE ישירות: 1 להצפנה, 2 לגיבוב, 3 לאימות, 4 לקבוצה, ו-14 לאורך מפתח כשהאלגוריתם מקבל אחד. מה שיוצא הוא שורה שאפשר לקרוא בקול בסקירת שינוי.

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

ike-scan --trans="(1=7,14=256,2=5,3=1,4=14)" 203.0.113.10

הצעה אחת לכל חבילה איטית כשממנים, אז עברו על הערכים הסבירים: הצפנה 5, 7/128, 7/192, 7/256; גיבוב 1, 2, 5, 6, 7; קבוצות 1, 2, 5, 14, 15, 19, 20, 21; אימות 1 למפתח משותף מראש ו-3 לחתימות RSA. הדפיסו כל פקודה לפני הרצתה כדי שהתמלול יראה מה הוצע ובאיזה סדר.

שלב 3: פרשו תשובה

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

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

שלב 4: פרשו שתיקה

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

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

שלב 5: רשמו מה הוכחתם

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

בדיקה שמעולם לא השיבה בכל זאת השיבה משהו: היא מראה אילו הצעות המכשיר הזה מוכן לדון בהן, ואילו היה מעדיף להפיל על הרצפה.