Windows Firewall ואפליקציות עסקיות — רושמים inbound rule ב-installer

“במכונת הפיתוח רץ בלי בעיה, ואצל הלקוח ה-client לא מתחבר לשרת”, “בהפעלה הראשונה יצאה אזהרה כלשהי, ונראה שהאדם בשטח ביטל”, “ב-netstat הפורט מאזין, אבל מהמחשב ליד זה לא מגיע” — בשטח הטמעת אפליקציה עסקית, פניות “אי אפשר לתקשר” מהסוג הזה הן הקלאסיקה שבקלאסיקות. ומי שנשאר בראש הסיבות הוא Windows Firewall (Windows Defender Firewall).

הבעיה היא שבמכונת הפיתוח התקלה לא נראית. במכונת הפיתוח לחצתם בעצמכם על Allow בהרצת debug של Visual Studio, או שאתם עצמכם Administrators, ולכן יוצאים לשחרור בלי להבחין ב-inbound block כברירת מחדל. אצל הלקוח, מי שמפעיל הוא משתמש רגיל בלי הרשאות Administrator, והרשת מנוהלת ב-GPO. זה לא “מה שאמור לרוץ לא רץ”; המציאות היא ש“מכונת הפיתוח במקרה רצה”.

המאמר הזה מיועד למפתחי אפליקציות עסקיות שנתקלים ב-“אצל הלקוח אי אפשר לתקשר” באפליקציה שפיתחו, ולאנשי IT בעסקים קטנים ובינוניים שמקבלים את הפניות האלה. אחרי תפיסה מינימלית של פעולת ברירת המחדל של Windows Firewall ושל מנגנון הפרופילים, הוא מסדר לפי מקורות ראשוניים נכון לאוגוסט 2026 את תכנון ה-inbound rule, רישום ב-installer בפועל, הליך isolation, ונקודות זהירות תחת ניהול GPO/Intune.

1. קודם כל, המסקנות

• ברירת המחדל של Windows Firewall היא “inbound חסום, outbound מותר”. תעבורת inbound שאינה תשובה לבקשה נזרקת כל עוד אינה מתאימה לכלל.¹
• Inbound rule נחוץ רק לאפליקציה מסוג שרת שמאזינה בפורט. אפליקציית client שרק יוצאת להתחבר יכולה לתקשר כברירת מחדל. קודם חותכים כאן.¹
• יש שלושה פרופילים (Domain / Private / Public). Domain חל אוטומטית בזיהוי domain controller, ו-Public הוא ברירת המחדל לרשת לא מזוהה. הכלל נקבע כמופעל או מושבת לפי פרופיל.¹
• אסור להשאיר את דיאלוג “Windows Security Alert” ל-production. אם Administrator מבטל, נוצר block rule, ובמשתמש בלי הרשאות Administrator כל כפתור שיילחץ יוצר block rule. עד שמוחקים את הכלל שנוצר הדיאלוג לא יוצג שוב.²
• המסקנה: “inbound rule לאפליקציה עסקית רושמים ב-installer”. Microsoft עצמה ממליצה להציב כללים לפני ההפעלה הראשונה, ולהשבית התראות inbound.²
• מתכננים כללים ב-least privilege. ציר של program + protocol + port, מצמצמים פרופיל ל-Domain/Private, ומצמצמים remote IP לתת-הרשת הנחוצה. בנתיב program אין wildcards.²³
• ה-isolation הוא בסדר Test-NetConnection → Get-NetFirewallRule → pfirewall.log. יומן Firewall כברירת מחדל אינו נכתב; הוא מופיע רק אחרי שמפעילים רישום של מנות שנזרקו.⁴⁵⁶
• השבתה כוללת בעצירת שירות אינה נתמכת. תחת ניהול GPO/Intune “Merge local rules” עשוי להיות כבוי, ואז כלל מקומי לא חל. מגישים לצוות IT בקשת הפצה מרוכזת של הכלל.¹²

ב-diagram, solid line מציינת relation שתמיד מתקיים ו-dashed line מציינת relation מותנה (התנאים מופיעים בהסבר של כל relation ב-detail page). הרשימה המלאה של ה-relations (סה”כ 35, כולל evidence ו-certainty) וההגדרות של ה-concepts המרכזיים נמצאות ב-detail page של ה-knowledge map (ביפנית). Data: JSON-LD / Turtle

2. לתפוס במדויק את פעולת ברירת המחדל — inbound חסום כברירת מחדל, outbound מותר כברירת מחדל

קודם תופסים את הבסיס במדויק. Windows Firewall הוא host firewall שמופעל כברירת מחדל בכל המהדורות, ופעולת ברירת המחדל מסתכמת בשתי שורות.¹

• Inbound: הכול חסום אלא אם זו תשובה לבקשה (solicited) או שהיא מתאימה לכלל
• Outbound: הכול מותר אלא אם מתאים לכלל

משתי השורות האלה יוצא ה-isolation החשוב ביותר לאפליקציה עסקית. Inbound rule נחוץ רק ל”צד שמאזין”.

• אפליקציית client שרק יוצאת להתחבר לשרת web פנימי, שרת DB או מערכת ליבה → ככלל אין צורך בכלל. מנות החזרה של החיבור הן “תשובה לבקשה” ולכן עוברות כברירת מחדל.
• אפליקציה מסוג שרת או Windows service שפותחת פורט ומאזינה לחיבור ב-TCP, gRPC או פרוטוקול עצמי → inbound rule חובה.
• תצורה שמשתמשת ב-named pipe מרחוק היא חריג. named pipe מרחוק אינו פורט של האפליקציה עצמה אלא עובר ב-SMB (TCP 445), ולכן מה שנחוץ אינו כלל של האפליקציה אלא כלל בצד file sharing (SMB).
• החריג הוא סביבה מאובטחת מאוד ששינתה במפורש את ברירת המחדל של ה-outbound לחסימה. התצורה הזו קיימת רק בחלק מהארגונים, ואז גם לאפליקציית client נדרשת בקשה ל-outbound rule.²

flowchart TB
    accTitle: inbound rule נחוץ רק לצד שמאזין
    accDescr: חיבור כ-client בלבד אינו דורש ככלל inbound rule, וכשפותחים פורט ומאזינים רושמים inbound rule ב-installer
    APP["סופרים את התקשורת של האפליקציה"] --> Q{"האם פותחים פורט<br/>ומאזינים לחיבור"}
    Q -- "לא מאזינים<br/>(רק מתחברים כ-client)" --> C1["inbound rule ככלל מיותר<br/>החזרה של החיבור עוברת כ\"תשובה\""]
    Q -- "מאזינים<br/>(סוג שרת / קבלת callback)" --> S1["inbound rule חובה<br/>→ רישום ב-installer (פרק 5)"]
    C1 -.-> EX["חריג: בסביבה מאובטחת מאוד<br/>עם outbound block כברירת מחדל מבקשים outbound rule"]

איור 1: כשפותחים פורט ומאזינים נחוץ inbound rule; חיבור כ-client בלבד אינו דורש ככלל inbound rule.

מקרה שקל לפספס הוא “אפליקציה שאמורה להיות client ובפועל גם מאזינה” (קבלת callback של תוצאה, פתח לקבלת התראות מ-process אחר וכו’). אם לא ברור באיזה אופן תקשורת האפליקציה שלכם מאזינה, כסידור בשלב התכנון ראו גם “איך בוחרים תקשורת בין-תהליכית”.

2.1. פרופילים ו”מיקום הרשת”

כללים חלים לפי פרופיל רשת. יש שלושה פרופילים.¹

את הפרופיל שחל כעת מאשרים ב-Get-NetConnectionProfile, ומעבר Private/Public עושים ב-Set-NetConnectionProfile.¹ תקלה נפוצה בשטח היא שבסביבת workgroup אצל הלקוח הרשת נקבעה כ-“Public”, ו-inbound rule שנוצר מוגבל ל-Domain/Private אינו חל. כש”יש כלל אבל זה לא עובר”, חשדו בהתאמת הפרופיל לפני תוכן הכלל.

2.2. סדר העדיפות של כללים

כשיש כמה כללים, ההערכה אינה רשימת סדר משוקללת אלא העיקרון העקבי הבא.²

1. Allow rule מפורש גובר על block כברירת מחדל
2. Block rule מפורש גובר על allow rule מתנגש
3. בטווח שאינו סותר את 2, כלל ספציפי יותר גובר

המשמעות המעשית: “אם יש block rule אחד איפשהו, כמה allow rules שתוסיפו אחר כך לא ינצחו”. כפי שנראה בפרק הבא, בדיוק את ה-block rule הזה הדיאלוג יוצר בשקט.

3. זהות דיאלוג “Windows Security Alert” — למה אסור להשאיר לו

כשאפליקציה מתחילה לראשונה להאזין (listen) בפורט, ואם אין allow rule לאפליקציה ואין כלל שהגדיר Administrator, Windows מציג את דיאלוג “Windows Security Alert” המוכר, “Windows Defender Firewall has blocked some features of this app”. המפרט של ההתנהגות ברור.²

• כשמוצג למשתמש עם הרשאות Administrator: “Allow access” יוצר allow rule. אבל לחיצה על “Cancel” יוצרת block rule. בדרך כלל שניים, ל-TCP ול-UDP.
• כשמוצג למשתמש בלי הרשאות Administrator: כל אפשרות שתיבחר יוצרת block rule.
• בשני המקרים, כל עוד לא מוחקים את הכלל שנוצר הדיאלוג לא יוצג שוב, והתקשורת ממשיכה להיחסם.

flowchart TB
    accTitle: פיצול דיאלוג "Windows Security Alert"
    accDescr: כשאין כלל והתראת inbound מופעלת מוצג הדיאלוג, וביטול או פעולת משתמש רגיל יוצרים block rule והדיאלוג לא יוצג שוב
    L["האפליקציה מתחילה להאזין בפורט"] --> Q1{"יש כלל שמתאים<br/>לאפליקציה"}
    Q1 -- "יש" --> R1["פועלים לפי הכלל<br/>(הדיאלוג לא יוצא)"]
    Q1 -- "אין" --> Q2{"התראת inbound<br/>מופעלת"}
    Q2 -- "כבויה" --> R2["חוסמים בשקט<br/>(כלל לא נוצר)"]
    Q2 -- "מופעלת" --> DLG["דיאלוג \"Windows Security Alert\""]
    DLG -- "Administrator \"Allow access\"" --> OK["נוצר allow rule"]
    DLG -- "Administrator \"Cancel\"" --> NG1["נוצר block rule"]
    DLG -- "משתמש בלי הרשאות Administrator<br/>(בכל פעולה)" --> NG2["נוצר block rule"]
    NG1 --> NEVER["עד שמחיקת הכלל<br/>הדיאלוג לא יוצג שוב"]
    NG2 --> NEVER

איור 2: ביטול הדיאלוג או פעולת משתמש בלי הרשאות Administrator יוצרים block rule; בלי מחיקה הדיאלוג לא יוצג שוב.

כלומר הדיאלוג נראה כ-“מנגנון שמבקש היתר מהמשתמש”, ובשטח אפליקציה עסקית הוא פועל כ-“מנגנון שצורך block rule ברגע שמשתמש רגיל נוגע”. אם אחראי ההטמעה מפעיל לראשונה בחשבון Administrator ומתיר בדיאלוג, ה-allow rule שנוצר חל על כל המחשב, ולכן גם המשתמש הרגיל ממחרת יכול לתקשר בינתיים. ועדיין נשארות תקלות — כשמשתמש רגיל דורך לראשונה על האזנה שלא נדרכה באישור בהטמעה, כשפרופיל הרשת שחל שונה מזה שבהטמעה, וכשנתיב ה-exe משתנה בעדכון (פרקים 4 ו-5).

גם Microsoft עצמה מציינת במפורש את שיטות העבודה המומלצות הבאות למכשירים שמשתמשים בהם מי שאינם Administrators.²

1. להציב את הכללים הנחוצים לפני ההפעלה הראשונה של האפליקציה (installer או הפצה מצד הניהול)
2. להשבית התראות inbound (כיבוי התראה מבטל את עצם יצירת הכלל האוטומטית בזמן ריצה)

השבתת התראה אפשרית ב-Set-NetFirewallProfile -NotifyOnListen False, או ב-Group Policy.⁷ “כשהדיאלוג יוצא, נבקש מהאדם בשטח ללחוץ Allow” אינו נוהל תפעול; זו הזמנה לתקלה. Inbound rule רושמים בהתקנה — זו מסקנת המאמר, והיא גם תואמת את המלצת Microsoft.

4. תכנון inbound rule — ציון program, ציון פורט, ציון service

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

מעל זה משלבים צמצום היקף. גם המלצת התכנון של Microsoft היא “inbound rule ספציפי ככל האפשר”.²

• צמצום פרופיל: inbound rule לאפליקציה עסקית שמשמשת רק בפנים מצמצמים ל-Domain/Private, ואינם מפעילים ב-Public. כך נמנעת תקלה שבה ברגע שמחשב נייד מתחבר ל-Wi-Fi חיצוני פורט האזנה נפתח לעולם.
• צמצום remote IP: אם מקור החיבור קבוע, מצמצמים -RemoteAddress לתת-הרשת הזו. לרשת ביתית או משרד קטן מומלץ צמצום במפתח LocalSubnet.²³
• כיוון ומספר: אם ההאזנה היא TCP בלבד, די בכלל TCP אחד. לא ליצור מתוך אינרציה כללי TCP ו-UDP כמו שהדיאלוג יוצר אוטומטית.

“רק מהעמית הנחוץ, רק לפורט הנחוץ, רק ל-program הנחוץ” — תכנון inbound rule מסתכם במשפט least privilege הזה.

5. רישום ב-installer בפועל — netsh ו-New-NetFirewallRule

5.1. הנחה: נדרשות הרשאות Administrator

הוספה ומחיקה של כללי Firewall הן שינוי הגדרה לכל המחשב, ולכן צריך להריץ ב-process עם הרשאות Administrator (elevated).⁸ ה-installer בדרך כלל כבר רץ בהרשאות Administrator, ולכן הגיוני לשים את רישום הכלל בתוך הליך ההתקנה. זה אינו נימוק להריץ את גוף האפליקציה כ-Administrator. את החשיבה של קו ההפרדה הזה מטפל בפירוט “מתי נחוצות הרשאות Administrator”.

5.2. רישום ב-netsh advfirewall

קלאסי, וקל לקרוא מכל installer, הוא netsh advfirewall firewall add rule.⁸

rem add rule מוסיף גם אם יש כלל באותו שם, ולכן לקראת הרצה חוזרת
rem בהתקנה מחדש, תיקון ועדכון מוחקים כלל באותו שם ואז רושמים מחדש
netsh advfirewall firewall delete rule name="MyCompany OrderServer"

rem allow rule inbound עם ציון program + ציון פורט + צמצום פרופיל
netsh advfirewall firewall add rule name="MyCompany OrderServer" dir=in action=allow program="C:\Program Files\MyCompany\OrderServer\OrderServer.exe" protocol=TCP localport=50051 profile=domain enable=yes

rem בהסרת התקנה: מחיקה לפי שם
netsh advfirewall firewall delete rule name="MyCompany OrderServer"

add rule אינו מחליף כלל קיים באותו שם אלא מוסיף באותו שם, ולכן בלי delete rule קודם הכלל מתרבה בכל הרצה, ואחרי עדכון ששינה נתיב או היקף ה-allow rule הישן שורד (בהרצה הראשונה ה-delete rule שבראש מחזיר ש”אין כלל מתאים”, אבל הביצוע של האצווה ממשיך, ולכן הסדר הזה תקין. אם ה-installer קובע הצלחה לפי exit code, הסתכלו בתוצאת add rule שבסוף). אפשר גם לצמצם מקור חיבור כמו remoteip=157.60.0.1,172.16.0.0/16,LocalSubnet.⁸ מחיקה מוחקת יחד כללים שמתאימים לשם, ולכן שם הכלל ייחודי עם קידומת של החברה הוא הבטוח.

5.3. רישום ב-PowerShell (New-NetFirewallRule)

לשליטה דקה יותר משתמשים במודול NetSecurity. -DisplayName חובה, ו--Profile יכול לקבל כמה ערכים מופרדים בפסיק (בלי רווח).³

# רישום (מריצים elevated מה-installer). -Name הוא מזהה ייחודי, ולכן
# בהרצה חוזרת בהתקנה מחדש, תיקון ועדכון יצירת כלל באותו שם
# תיכשל. עושים idempotency במחיקת כלל קיים באותו שם ואז יצירה מחדש
Remove-NetFirewallRule -Name "MyCompany-OrderServer-In" -ErrorAction SilentlyContinue
New-NetFirewallRule -Name "MyCompany-OrderServer-In" `
    -DisplayName "MyCompany OrderServer (inbound TCP 50051)" `
    -Direction Inbound -Action Allow `
    -Program "C:\Program Files\MyCompany\OrderServer\OrderServer.exe" `
    -Protocol TCP -LocalPort 50051 `
    -Profile Domain,Private -RemoteAddress LocalSubnet

# בהסרת התקנה: לא נכשלים גם אם אינו קיים
Remove-NetFirewallRule -Name "MyCompany-OrderServer-In" -ErrorAction SilentlyContinue

יש סיבה לציין כאן -Name במפורש. -Name הוא מזהה ייחודי של הכלל, ואם משמיטים מוקצה ערך אקראי. שם התצוגה (-DisplayName) עשוי להשתנות לפי locale, ולכן המפתח לזיהוי כלל מסקריפט הוא -Name, לפי הנחיית Microsoft.³ גם כדי ש-uninstaller ימחק בוודאות רק את הכלל שלו, קיבוע -Name נחשב לחובה.

5.4. כשנתיב ה-exe משתנה בעדכון

כלל בציון program מקבע יעד בנתיב מלא. כלומר, אם יעד ההתקנה או שם ה-exe משתנים בעדכון, הכלל נשאר אבל מאבד את היעד, וההאזנה נחסמת שוב. בנקודה זו ה-exe בנתיב החדש מטופל כ-“אפליקציה בלי כלל”, ולכן בסביבה שהתראה מופעלת דיאלוג פרק 3 מופיע שוב, ואם משתמש רגיל נוגע נוצר block rule. בסביבה שהשביתה התראה כמו המומלץ בפרק 3, זה נכשל בשקט בלי דיאלוג. התקלה קלה במיוחד בשיטת הצבה בתיקייה עם מספר גרסה, או בשיטה שבה self-update מזיז את מקום ההצבה.

flowchart TB
    accTitle: עדכון שמשנה נתיב exe מנתק את הכלל
    accDescr: כלל בציון program מקבע נתיב מלא, ולכן שינוי מקום ההצבה מאבד את היעד, ולפי התראה הדיאלוג מוצג שוב או שיש חסימה בשקט
    V1["הטמעת v1.0<br/>הכלל מצביע על exe בתיקיית v1.0"] --> UP["בעדכון הצבה בתיקיית v1.1<br/>נתיב ה-exe שרץ משתנה"]
    UP --> MISS["הכלל בנתיב הישן מאבד את היעד<br/>(הכלל נשאר אבל לא חל)"]
    MISS --> Q{"התראת inbound<br/>מופעלת"}
    Q -- "מופעלת" --> DLG["הדיאלוג מוצג שוב<br/>נגיעת משתמש רגיל = block rule"]
    Q -- "כבויה" --> SILENT["בלי דיאלוג,<br/>חסימה בשקט"]
    MISS -.->|"טיפול"| FIX["מקבעים נתיב מעבר לעדכונים<br/>או בעדכון מוחקים כלל ישן ורושמים מחדש"]

איור 3: אם עדכון משנה את נתיב ה-exe, הכלל הישן מאבד את היעד; מקבעים נתיב יציב או רושמים מחדש בעדכון.

הטיפול פשוט, אחת מאלה:

• מקבעים יעד התקנה כך שהנתיב המלא של ה-exe לא משתנה מעבר לעדכונים
• בעדכון שמשנה נתיב, ה-updater מוחק את הכלל הישן ורושם מחדש בנתיב החדש (מריצים גם בעדכון את הפקודות של 5.2/5.3)

ב-MSI הרישום של הכלל הוא custom action שרצה אחרי הצבת הקבצים (ובהסרת התקנה custom action בצד המחיקה) — זה הדפוס. בערכות כלים כמו WiX יש גם הרחבות שמתארות כללי Firewall באופן הצהרתי. מקום המימוש משתנה לפי שיטת ההפצה שנבחרה, ולכן ראו גם “איך בוחרים שיטת הפצה לאפליקציית Windows”. ועוד תקלה קלאסית בהרחבה אצל לקוח — false positive של antivirus — מטופלת ב”טיפול ב-false positive של Microsoft Defender”.

6. Troubleshooting — זרימת isolation של “אי אפשר לתקשר”

מקבעים את הסדר כשמקבלים פנייה. הזרימה הכללית:

flowchart TB
    accTitle: isolation של "אי אפשר לתקשר"
    accDescr: מאשרים לפי הסדר האזנה בשרת, הגעה מהלקוח, התאמת פרופיל, כללים ב-ActiveStore, וזריקה DROP ביומן
    S["\"אי אפשר לתקשר מהלקוח\""] --> N["בצד השרת: netstat -ano"]
    N -- "לא מאזין" --> APP["בעיה לפני ה-Firewall<br/>חוקרים אפליקציה / service"]
    N -- "LISTENING" --> T["בצד הלקוח: Test-NetConnection"]
    T -- "TcpTestSucceeded=True" --> OTHER["ההגעה תקינה<br/>חוקרים שכבת אפליקציה (אימות / protocol)"]
    T -- "False" --> P["בצד השרת: Get-NetConnectionProfile<br/>מאשרים פרופיל חל"]
    P -- "לא תואם ליעד הכלל" --> FIXP["בודקים מחדש את ציון הפרופיל בכלל"]
    P -- "תואם" --> R["Get-NetFirewallRule -PolicyStore ActiveStore<br/>מאשרים קיום allow rule וערבוב block rule"]
    R --> LOGCHK["מדידת זריקה (DROP) ב-pfirewall.log"]

איור 4: isolation מכני: netstat → Test-NetConnection → פרופיל → כללים ב-ActiveStore → pfirewall.log.

השלמה לשלב 4. תנאי פורט ו-program אינם בגוף הכלל אלא בצד אובייקט ה-filter, ולכן כדי לחפש כלל לאחור מפורט שואלים דרך ה-filter.⁵⁷

# חיפוש לאחור של כללים שקשורים לפורט 50051
Get-NetFirewallPortFilter | Where-Object { $_.LocalPort -eq 50051 } | Get-NetFirewallRule

# מעקב אחרי מקור הכלל (מקומי או GPO)
Get-NetFirewallRule -PolicyStore ActiveStore -TracePolicyStore |
    Select-Object Name, DisplayName, PolicyStoreSourceType, PolicyStoreSource

יומן Firewall (pfirewall.log) בשלב 5 כברירת מחדל אינו רושם דבר. הנתיב כברירת מחדל הוא %windir%\system32\logfiles\firewall\pfirewall.log, הגודל המרבי כברירת מחדל 4,096KB, והכתיבה מתחילה רק אחרי שמפעילים “Log dropped packets” או “Log successful connections”.⁶ במחשב בודד אפשר להפעיל כך:⁶

netsh advfirewall set allprofiles logging droppedconnections enable
netsh advfirewall set allprofiles logging allowedconnections enable

היומן הוא קובץ טקסט, וכל שורה רושמת זריקה (DROP) או היתר (ALLOW), protocol, וכתובות ופורטים של מקור/יעד, ולכן כאן קובעים “האם SYN מהלקוח הגיע ונזרק, או כלל לא הגיע”. בסביבה שהיומן מוגדר במדיניות לפעמים חסרות הרשאות כתיבה לתיקיית היומן (FullControl ל-service mpssvc) והקובץ לא נוצר; אז נדרשות יצירת תיקייה והענקת ACL.⁶

להעמקה נוספת, הפעלת ה-audit policy “Filtering Platform Packet Drop” רושמת security event 5152 בכל זריקה. אבל כמות האירועים גדולה מאוד, ולכן Microsoft ממליצה על event 5157 (Filtering Platform Connection) שנרשם לפי חיבור. זה כלי שמפעילים רק למשך ה-isolation, לא לשימוש יומיומי.⁹

ולבסוף מבהירים isolation שאסור לעשות. השבתה גורפת בעצירת שירות Firewall (MpsSvc) אינה נתמכת, והיא גורמת לבעיות בצד מערכת ההפעלה כמו תפריט התחלה שלא זז וכשל בעדכון Store apps. אם בכל זאת רוצים להשבית כדי לאשר, משאירים את השירות רץ ומשביתים פרופיל ב-Set-NetFirewallProfile -Profile Domain,Public,Private -Enabled False, ומחזירים מיד אחרי האישור.¹⁷ ואחרי שקבעתם שהסיבה היא ה-Firewall, הטיפול אינו להנציח השבתה אלא להוסיף כלל נכון אחד.

7. זהירות תחת ניהול ארגוני — סביבה שכלל מקומי לא חל בה, ואופן הבקשה

יש סביבות שגם אחרי שה-installer רושם כלל, הוא לא חל. בארגון שמנהל Firewall במרוכז ב-GPO או Intune (CSP) אפשר להשבית לפי פרופיל את “Merge local rules” (AllowLocalPolicyMerge). כשההגדרה כבויה, כללים ש-Administrator מקומי (כולל ה-installer) יצר אינם חלים, וכללי אפליקציות שדורשות חיבור inbound חייבים הפצה מרוכזת מ-GPO/CSP.²

flowchart TB
    accTitle: כש-Merge local rules כבוי, רישום ה-installer אינו חל
    accDescr: בסביבה ש-AllowLocalPolicyMerge כבוי בה הכלל המקומי קיים אבל אינו חל, ועוברים להפצה מרוכזת ב-GPO או ב-CSP
    GPOR["כללים שהופצו ב-GPO/Intune"] --> EFF["קבוצת הכללים שחלים בפועל<br/>(ActiveStore)"]
    LOCAL["כללים שנוצרו מקומית<br/>(כולל רישום ה-installer)"] --> Q{"Merge local rules<br/>(AllowLocalPolicyMerge)"}
    Q -- "מופעל (ברירת מחדל)" --> EFF
    Q -- "כבוי" --> DROP["הכלל קיים אבל אינו חל<br/>→ עוברים להפצה מרוכזת ב-GPO/CSP"]

איור 5: כש-Merge local rules כבוי, כללי ה-installer אינם חלים; נדרשת הפצה מרוכזת ב-GPO/CSP.

ההכנה המציאותית מצד הפיתוח ומצד ההטמעה:

• רישום הכלל ב-installer מתוכנן כ-“לא נכשל” (הרישום עצמו מצליח, ולכן אי אפשר לזהות בשגיאה. כוללים בנוהל אישור קישוריות אחרי ההטמעה)
• בשלב 4 בפרק 6 (-TracePolicyStore) מאשרים אם מקור הכלל שחל הוא מקומי או GPO⁵
• כשמבינים שכלל מקומי לא חל, עוברים לבקשת הפצת כלל לצוות IT

בבקשה מעבירים את המידע הבא כמכלול. כלל Firewall אפשר ליצור רק כשיש כיוון, program, פורט והיקף, ולכן זה הופך כמו שהוא ל-“מפרט הרשת של האפליקציה העסקית”.

גם מצד צוות IT, בקשה עם הטבלה הזו ובלי הטבלה הזו שונות לגמרי בכמות העבודה. ולהפך, “תפתחו” עם מספר פורט בלבד נוטה ל-over-permission, כפי שראינו בפרק 4. ודרישות תקשורת סביב file sharing ואימות בסביבת domain משתנות גם בלחצים אחרים מלבד Firewall (חובת signing וכו’). ראו גם “SMB signing ו-LDAP channel binding”.

8. סיכום

• ברירת המחדל של Windows Firewall היא inbound חסום ו-outbound מותר. Inbound rule נחוץ רק לאפליקציה מסוג שרת שמאזינה, וככלל מיותר אם רק מתחברים כ-client.
• כללים חלים לפי פרופיל (Domain / Private / Public). החשוד הראשון ב-“יש כלל אבל זה לא עובר” הוא אי-התאמת פרופיל.
• דיאלוג “Windows Security Alert” יוצר block rule בביטול או בפעולת משתמש בלי הרשאות, ומכאן ואילך אינו מוצג שוב. אסור להשאיר תפעול production לדיאלוג הזה.
• Inbound rule לאפליקציה עסקית רושמים ב-installer — זה העיקרון היחיד. הרישום בהרשאות Administrator, ועם -Name מקובע כולל מחיקה.
• הכלל סביב program + protocol + port, ומצמצמים בפרופיל וב-remote IP. אם נתיב ה-exe משתנה בעדכון, לא שוכחים לרשום מחדש את הכלל.
• ה-isolation מכני: netstat → Test-NetConnection → אישור פרופיל → Get-NetFirewallRule (ActiveStore) → pfirewall.log. השבתה בעצירת שירות אינה נתמכת.
• תחת ניהול GPO/Intune Merge local rules עשוי להיות כבוי. אז מגישים לצוות IT הפצה עם שם כלל, כיוון, program, פורט, remote IP ופרופיל.

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

• איך בוחרים תקשורת בין-תהליכית ב-Windows — טבלת החלטה named pipes / TCP / gRPC / shared memory / COM
• איך בוחרים שיטת הפצה לאפליקציית Windows - MSI/MSIX/ClickOnce/xcopy/self-update
• מתי באמת נדרשות הרשאות Administrator ב-Windows - UAC, אזורים מוגנים, ואיך מבחינים בתכנון
• כשאפליקציית Windows שפיתחתם מטופלת כווירוס — טיפול ב-false positive של Microsoft Defender, והיחס להשפעה על ביצועים
• SMB signing ו-LDAP channel binding — לסגור בשטח את “החצי שנשאר” בטיפול ב-NTLM
• איך בונים ומפעילים Windows service — מהבחירה מול Task Scheduler עד הפיכת BackgroundService ל-service

תחומי ייעוץ קשורים

KomuraSoft LLC מטפלת בתכנון installer לאפליקציה עסקית מסוג שרת (כולל רישום ומחיקה של כללי Firewall), בחקירת הסיבה ל-“אי אפשר לתקשר” בסביבת לקוח, ובארגון דרישות רשת לקראת הרחבה תחת ניהול GPO. אפשר להתחיל מ-isolation “במכונת הפיתוח רץ ואצל הלקוח לא”.

• פיתוח אפליקציות Windows
• חקירת תקלות ואיתור גורמים
• ייעוץ טכני וסקירת תכנון
• יצירת קשר

מקורות

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

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

נושאים קשורים

העמודים האלה ממקמים את הנושא בהקשר רחב יותר של שירותים והחלטות.

שירותים הקשורים לנושא הזה

המאמר קשור ישירות לשירותים הבאים.

שאלות נפוצות

שאלות נפוצות בפניות בנושא המאמר.

גם לאפליקציה שהיא רק client שמתחבר לשרת נחוץ כלל Firewall?

ככלל לא. ברירת המחדל של Windows Firewall היא "inbound חסום, outbound מותר", ולכן אפליקציית client שרק יוצאת להתחבר יכולה לתקשר כברירת מחדל. inbound rule נחוץ רק לצד שמאזין בפורט, כלומר לאפליקציה מסוג שרת. אבל יש שני חריגים. בסביבה מאובטחת מאוד גם ה-outbound עשוי להיות מוגדר לחסימה כברירת מחדל, ואז נדרשת בקשה ל-outbound rule. וגם אפליקציית client, אם היא מתוכננת להאזין בעצמה בפורט כפתח לקבלת התראות תוצאה, צריכה inbound rule לחלק הזה.

אי אפשר פשוט ללחוץ "Allow access" בדיאלוג "Windows Security Alert"?

במקום זה מספיק, אבל אי אפשר להשאיר את זה לתפעול production. אם משתמש עם הרשאות Administrator לוחץ Cancel, נוצר block rule. ואם המשתמש בלי הרשאות Administrator, **כל כפתור שיילחץ יוצר block rule**. כל עוד לא מוחקים את הכלל שנוצר, הדיאלוג לא יוצג שוב, והתקשורת ממשיכה להיכשל. באפליקציה עסקית שמפעיל בשטח משתמש רגיל, קל מאוד להגיע למצב "מישהו ביטל פעם אחת, ומאז אי אפשר לתקשר". גם Microsoft ממליצה להציב כללים לפני ההפעלה הראשונה של האפליקציה.

Inbound rule — לפי פורט או לפי program?

הבסיס הוא לשלב, לא לבד. ציון program מצמצם לפי נתיב מלא של exe, אבל אם הנתיב משתנה בעדכון הכלל מאבד את היעד (אין wildcards). ציון פורט מבהיר את הבקשה לצוות IT, אבל מעביר גם process אחר שמאזין באותו פורט. באפליקציה עסקית ב-production הציר הוא "program + protocol + port", מצמצמים פרופיל ל-Domain/Private, ומצמצמים remote IP לתת-הרשת שבה יושבים הלקוחות — זה דפוס least privilege. רק כשהפורט דינמי משתמשים בציון program לבד.

נראה שהכלל שה-installer רשם לא חל במחשב אצל הלקוח. למה?

סביר שה-Firewall אצל הלקוח מנוהל במרוכז ב-GPO או Intune, ו-"Merge local rules" (AllowLocalPolicyMerge) כבוי. כשההגדרה כבויה, כלל שנוצר מקומית קיים בפרופיל אבל אינו חל, ואין ברירה אלא להפיץ את הכלל במרוכז מצד GPO/CSP. מאשרים את הכללים התקפים ב-Get-NetFirewallRule -PolicyStore ActiveStore, ומגישים בקשת הפצה לצוות IT. בבקשה מעבירים בבת אחת שם כלל, כיוון, נתיב program, protocol ופורט, טווח remote IP ופרופיל — וזה עובר בפעם אחת.

מותר להשבית זמנית את ה-Firewall לצורך isolation של תקשורת?

השבתה בעצירת השירות (MpsSvc) אסורה בהחלט. זו פעולה שאינה נתמכת בידי Microsoft, והיא גורמת לבעיות בצד מערכת ההפעלה כמו תפריט התחלה שלא זז וכשל בעדכון Store apps. אם בכל זאת רוצים להשבית לצורך isolation, הדרך הנכונה היא להשאיר את השירות רץ ולהשבית פרופיל ב-Set-NetFirewallProfile -Enabled False. גם זה מוגבל לשימוש של כמה דקות כדי לאשר "האם הסיבה היא ה-Firewall", ומחזירים מיד אחרי האישור. תפעול שמשאיר מושבת מחליף בעיה שאפשר לפתור בכלל אחד בחוסר הגנה על כל המחשב.

פרופיל הכותב

עמוד היכרות עם כותב המאמר.

Go Komura

מנהל KomuraSoft LLC

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