הוספת כלל אישור ל-RDP אינה מצמצמת את גישת ה-VPN שלך

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

הכלל שאתה מוסיף אינו הכלל שמשנה

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

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

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

גלה איזו כתובת השרת רואה

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

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

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

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

שנה את הבעלים של הכלל האפקטיבי

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

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

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

Get-NetFirewallRule -PolicyStore ActiveStore -Direction Inbound | Where-Object DisplayName -match RDP
Get-NetFirewallAddressFilter -AssociatedNetFirewallRule (Get-NetFirewallRule -Name Reviewed-RDP-TCP)
Set-NetFirewallRule -Name Reviewed-RDP-TCP -RemoteAddress 10.63.4.17 -WhatIf

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

קודם לחסום ואז להתיר הוא מודל אחר

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

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

הוכח זאת עם מקור שני

בדוק מהלקוח המורשה וממקור שאמור להיכשל כעת. חיבור מוצלח אחד מוכיח רק שהנתיב המורשה עובד; הוא אינו אומר דבר על ההחרגה שיצרת זה עתה.

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

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