מדוע PPP CHAP לבדו אינו יכול למלא דרישת MPPE

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

שתי משא ומתן מתנהלות בתוך חיבור PPTP אחד

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

CHAP רגיל הוא חילופי אתגר-תגובה ב-RFC 1994, הבנויים על סוד משותף ושום דבר אחר. MS-CHAPv2 הוא חילוף אחר עם הודעות אחרות ופלט אחר, תקני ב-RFC 2759. המילה המשותפת בשני השמות היא הדבר היחיד שמשותף להם על החוט. אף אחד מהשמות אינו אומר מה החילוף מייצר, וזה החלק היחיד שחשוב.

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

התאימו את השיטה הנדרשת למפתחות שהיא יכולה לייצר

מפתחות MPPE אינם תכונה של PPP בכלל. עבור משפחת Microsoft CHAP הגזירה מוגדרת ב-RFC 3079, והיא מקבלת כקלט את הפלט של חילוף MS-CHAP ולא סוד משותף. שיטות EAP מגיעות לאותו מקום בדרך אחרת, כששרת האימות מחזיר את המפתחות כמאפיינים MS-MPPE-Recv-Key ו-MS-MPPE-Send-Key. CHAP רגיל אינו מופיע באף אחד משני המסלולים, וזו כל הסיבה לאי-ההתאמה.

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

הכלל שנובע מכך קצר: אם הפרופיל דורש MPPE, השיטה חייבת להיות וריאנט של MS-CHAP או שיטת EAP שהשרת מחזיר את מפתחותיה. דחיית MS-CHAPv2 בלבד אינה כופה זאת, משום ש-MS-CHAPv1 גם גוזר מפתחות ונשאר זמין אלא אם דוחים אותו בנפרד; דחיית שניהם מותירה CHAP רגיל ו-PAP, שאינם גוזרים דבר והופכים את הדרישה לבלתי ניתנת למילוי. נקבו בשם השיטה המתקבלת במפורש במקום לפרט את אלה שאינכם אוהבים. ויתור על דרישת ההצפנה כדי שלקוח יתחבר הוא הורדה בדרגה, לא תיקון.

קראו את אפשרויות השרת לפני עריכת לקוח

רוב אי-ההתאמות האלה גלויות בשרת בשני קבצים, וקריאתם עולה פחות מבנייה מחדש של לקוח. בנקודת קצה של PPTP בלינוקס ההגדרות הרלוונטיות חיות בקובץ האפשרויות של pppd ש-pptpd מעביר. הריצו אותו בשרת, לא ממסך מצב של לקוח. התחילו בשורות שדורשות, דוחות או מכנות מצב הגנה:

sudo grep -nE 'require-|refuse-|mppe|mschap' /etc/ppp/options.pptpd

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

sudo sed -n '1,20p' /etc/ppp/chap-secrets
sudo pppd --version

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

אתרו את הכשל לפי שלב PPP

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

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

sudo journalctl -b --no-pager | grep -iE 'pppd|pptpd|mppe|chap' | tail -40

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

תכננו את היציאה לפני כיבוי נקודת הקצה הישנה

MPPE הוא מנגנון היסטורי להגנת קישור, ונוכחותו אינה הופכת את PPTP לבחירה הגיונית לפריסה חדשה. הנחיות Microsoft הנוכחיות כבר ממליצות נגד PPTP ונגד L2TP/IPsec עם מפתח משותף מראש לפריסות גישה מרחוק חדשות. החזקת נקודת קצה ישנה בחיים היא החלטה על שירות קיים, לא תבנית לזו הבאה.

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

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