הקשחת VPN ב-Windows: תקנו את האימות לפני המנהרה
MS-CHAPv2 אינו בדיקת סיסמה ששווה לסמוך עליה, ומפתח משותף מראש ארוך אינו אימות משתמש. סדרו את התיקונים לפי מה שתוקף יכול להשמיע מחדש.
שרת ה-VPN שלכם ב-Windows מבקש שם משתמש וסיסמה, ואותה תיבת דו-שיח אחת מסתירה שלושה תפקידים לא קשורים. אחד מוכיח מי האדם, אחד מונע ממי שצופה בקו להשמיע שוב את ההוכחה הזו, ואחד מחליט לאילו כתובות מותר לו להגיע לאחר מכן. רוב הפריסות הקטנות מקשות קודם את המנהרה ומשאירות את שני התפקידים הראשונים בערכי ברירת המחדל, וזה הסדר השגוי.
עבדו בסדר שבו פועל התוקף. תחילה מה שאפשר ללכוד מהקו. אחר כך מה שאפשר להשמיע מחדש מאוחר יותר עם אותה הקלטה. לבסוף, למה תוקף מאומת יכול להגיע כשהוא כבר בפנים.
שלושה תפקידים, תיבת דו-שיח אחת
זהות היא החלק שאנשים חושבים עליו, והוא רק שליש מהבעיה. הוכחת הזהות חייבת לשרוד צופה שמקליט את ההחלפה ומנסה שוב מאוחר יותר. הרשאה היא החלטה נפרדת שהשרת מקבל לאחר שהזהות נקבעה, ו-Windows שומר אותה בשירות אחר מזה שמאמת את פרטי הכניסה.
כשכל השלושה חיים בדלי מנטלי אחד, התוצאה הרגילה היא שרת שמאמת בחוזקה ואז מתיר למשתמש להגיע להכול. לתקן זאת מאוחר יותר קשה יותר מלהחליט על המדיניות עכשיו, כי עד אז פרופיל חומת האש, מאגר הכתובות והמסלולים כולם מקודדים את ההנחה הישנה.
הפרידו את השלושה בהערות שלכם לפני שאתם נוגעים בהגדרה, ואז תקנו אותם מהחוליה החלשה כלפי מעלה.
למה MS-CHAPv2 לא שורד מבחן השמעה חוזרת
אם השרת עדיין מקבל PPTP עם MS-CHAPv2, המנהרה לא מגנה על הסיסמה בשום מובן מהותי. אפשר ללכוד את האתגר והתגובה ולתקוף אותם ללא קו, ובשנת 2012 שירות פיצוח ציבורי הדגים שחזור מלחיצת יד כזו בכמעט יום אחד לסיסמה טיפוסית. סיסמה ארוכה ומורכבת יותר מייקרת את העלות; היא אינה מסלקת את החומר שהתוקף צריך מהרשת.
התכונה שאתם רוצים היא אישור שלא ניתן להשמיע מחדש. EAP-TLS עם אישורי לקוח נותן לכל התקן זהות משלו ומאפשר לכם לבטל בדיוק התקן אחד.
פריסת אישורים היא עבודה אמיתית: רשות אישורים פרטית, נתיב ביטול שהלקוחות בודקים, ותוכנית חידוש ששורדת תחלופת עובדים. התייחסו לעבודה הזו כאל הפרויקט ולא כאל מכשול ביניכם לבין מנהרה עובדת. תקצבו אותה כמו שהייתם מתקצבים החלפת חומת אש. סיסמה משותפת זולה יותר רק עד הביטול הראשון.
מפתח משותף מראש מאמת את הזוג, לא את האדם
L2TP/IPsec עם מפתח משותף מראש מוכיח ששתי שערים יודעים את אותו סוד. הוא לא אומר דבר על איזה אדם מתחבר, והוא לא יכול להבדיל בין עובד אחד לאחר בשכבה הזו. השתמשו בערך אקראי ארוך, הרבה מעבר לעשרת התווים שחלק מהמדריכים מציעים, כי כל מי שלוכד את לחיצת היד יכול לתקוף את המפתח ללא קו.
כל לקוח בפרופיל הזה חולק את הסוד, ולכן הסרת אדם אחד משמעה חלוקה מחדש לכל מי שנשאר. החזיקו שלב אימות משתמש נפרד מעל הסוד ברמת המכונה, ועברו לאישורים ככל שאוכלוסיית הלקוחות גדלה. מפתח משותף מראש בשילוב עם MS-CHAPv2 הם שתי שכבות חלשות, והשנייה מבטלת את הראשונה.
ההרשאה שייכת ל-Network Policy Server
NPS ב-Windows מחליט מי רשאי להתחבר, והוא עושה זאת לאחר שהאימות כבר הצליח. ההפרדה הזו היא בקרת ההקשחה השימושית ביותר במוצר, ופריסות רבות משאירות אותה ללא נגיעה.
השתמשו בתנאי מדיניות שמשקפים אילוצים אמיתיים: חברות בקבוצה, חלון הזמן שבו יש תמיכה מאוישת, ומצב ההתקן מבדיקת בריאות. הוסיפו גורם שני היכן שהנתונים מצדיקים את החיכוך, וזכרו שהמדיניות נבדקת בכל ניסיון התחברות, מה שהופך אותה לבקרה חיה ולא למסמך.
רישום RADIUS נותן לכם גם רשומה אחת של מי התחבר ומתי. היומן הזה הוא ההבדל בין סקירת אירוע לבין ניחוש, והוא קיים בין אם מישהו קורא בו ובין אם לא.
הגבילו לאן כניסה מוצלחת יכולה להגיע
מתאם ה-VPN צריך לנחות בפרופיל חומת אש שמתיר את השירותים שהתפקיד שלו צריך ולא את כל תת-הרשת. שאלת הניתוב נפרדת מהסינון. מנהרה מלאה מגנה על התקן הלקוח ודוחפת כל בית דרך הקישור העולה שלכם, ואילו מנהרה מפוצלת משאירה תעבורה מקומית מקומית וחושפת את ההתקן לכל רשת שבה הוא נמצא.
אף אחת משתי האפשרויות אינה ברירת מחדל אבטחתית. את שתיהן צריך לרשום לצד פרופיל חומת האש שהן מניחות.
אמתו את נתיבי הכשל
בדקו מה אמור להישבר: סיסמה שגויה, אישור שפג, התקן שבוטל, משתמש מחוץ לקבוצה. כל אחד אמור להיכשל בנקודה אחרת, והיומן אמור לומר איזה מהם היה. הריצו את הסט קודם בחשבון בדיקה ואז חזרו עליו עם משתמש אמיתי. דחייה שמגיעה ליומן האירועים בלי סיבה שווה תיקון הרבה לפני שתצטרכו את הרשומה.
לאחר מכן אשרו אילו פורטים מפורסמים ולמה. PPTP צריך TCP 1723 ו-GRE כפרוטוקול IP ולא כפורט, IKEv2 צריך UDP 500 ו-4500, ו-L2TP צריך UDP 1701 בתוספת IPsec. חשיפת ממשק ניהול כדי שלקוח יתחבר אינה תיקון, היא אירוע שני שממתין להתגלות.
לבסוף, החליטו מה השרת רושם ולכמה זמן. נקודת קצה בלי היסטוריית אימות לא יכולה לענות על השאלה הראשונה אחרי אירוע, כלומר אם הניסיון היה אי פעם מורשה.