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

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

שלב ראשון: מה הלכידה באמת ראתה

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

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

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

שלב שני: מה רישום ההפלה קובע

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

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

# what did the firewall actually drop, and when?
Get-NetFirewallProfile -PolicyStore ActiveStore | Select-Object Name, LogAllowed, LogBlocked
Get-Content "$env:systemroot\System32\LogFiles\Firewall\pfirewall.log" | Select-String 'DROP'

# correlate with a listening service on the same port
Get-NetTCPConnection -LocalPort 3389 -State Listen | Select-Object LocalAddress, OwningProcess

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

שלב שלישי: מה אירוע האימות מוכיח

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

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

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

דגימה מתואמת אחת מנצחת לוח בקרה

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

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

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

מאמרים קשורים