למה tcpdump מציג טקסט גלוי של IPsec רק בכיוון אחד

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

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

נקודת הלכידה קובעת מה תראו

בממשק רגיל, שקע AF_PACKET יושב קרוב לשכבת ההתקן. חבילות שעוזבות את המארח עוברות תחילה בעיבוד היציאה של IPsec, שהופך מקטע TCP פנימי לדאטגרם ESP או UDP-4500, ורק אחר כך מגיעות לשכבה הזו. חבילות שמגיעות מועתקות לשקע כשהן יוצאות מהכבל, עדיין מוצפנות, והתוצאה המפוענחת נראית מאוחר יותר כשהמחסנית מוסרת אותה מקומית או מעבירה אותה הלאה.

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

התאימו את המסנן לשכבה שהתכוונתם אליה

ביטוי כמו tcp port 443 בוחר חיבור TCP פנימי. ביציאה, החיבור הזה כבר הפך ל-ESP עד שמתייעצים עם השקע, ולכן המסנן אינו מתאים דבר. אם אתם רוצים לספור תעבורה מוגנת, סננו לפי הצורה החיצונית במקום: פרוטוקול 50 ל-ESP גולמי, או פורט UDP 4500 כשיש חציית NAT. שני המסננים מפיקים מספר חבילות שאפשר להשוות בין שני העמיתים, וזו בדרך כלל הסיבה לספירה מלכתחילה. אף אחד מהם לא אומר לכם אם הבקשה הפנימית נענתה.

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

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

צפו לפני הטרנספורמציה, לא אחריה

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

התאמת המדיניות מגבילה את הכלל לתעבורה שעומדת להיכנס למנהרה. -m policy --pol ipsec --dir out הוא מה שהופך את הכלל לספציפי במקום לתעד כל חבילה שהקופסה שולחת. אחר כך קראו את קבוצת היומן בלכידה מוגבלת: מספר תמונות קטן ומגבלת גודל מונעים מהאבחון להפוך לארכיון תעבורה. לכידה מוגבלת גם קלה יותר למסירה לסוקר בלי לגרור מטען לא רלוונטי. החליטו על המספר לפני שמתחילים, לא אחרי שראיתם כמה הגיע.

iptables -I OUTPUT 1 -d 10.83.0.44/32 -p tcp --dport 8443 -m policy --pol ipsec --dir out -j NFLOG --nflog-group 5
tcpdump -ni nflog:5 -s 128 -c 20 'host 10.83.0.44 and tcp port 8443'

בחרו את הוו שמתאים לזרימה. OUTPUT מכסה תעבורה שהשער עצמו מייצר; מעבר מלקוח LAN עובר במקום דרך שרשרת FORWARD, וכלל ב-OUTPUT לעולם לא יראה אותו. הכתובת והפורט שלמעלה הם ממלאי מקום ליעד בדיקה מאושר.

מה התצפית מוכיחה

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

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

עוד מלכודת: «טקסט גלוי» בהקשר הזה פירושו מחוץ לשכבת ההצפנה של IPsec. הפעלה פנימית של HTTPS עדיין יש לה TLS משלה. לכידת החבילה המפוענחת אינה מפענחת את ה-TLS של היישום, ולראות שם HTTP קריא פירושו שהיישום מעולם לא השתמש ב-HTTPS.

נקו והשוו את שני הקצוות

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

iptables -D OUTPUT -d 10.83.0.44/32 -p tcp --dport 8443 -m policy --pol ipsec --dir out -j NFLOG --nflog-group 5

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