Advanced Windows Firewall: Blocking Specific Application Executables

Windows Firewall can filter traffic by executable path, not just by port. This guide shows you how to block a specific application in Windows Firewall with PowerShell, how to allow only one program outbound, and how to confirm the rule is actually dropping traffic.

Program rules are useful when a port-based rule is too broad. If three services share TCP 443, you cannot block one of them by port. You can block it by executable.

Before you start

You need:

• A Windows VPS running Windows Server 2019–2025, with Administrator rights.
• An RDP session on TCP port 3389 (203.0.113.10:3389). Keep it open while you test.
• PowerShell opened as Administrator.

One important detail: Windows Firewall matches the file path, not the file hash. If an application updates into a new folder, the rule stops matching. Re-check paths after major updates.

Find the executable you want to block

Start by identifying the process behind the traffic. List listening ports with their owning process:

Get-NetTCPConnection -State Listen |
  Select-Object LocalAddress, LocalPort, OwningProcess,
    @{n='Process';e={(Get-Process -Id $_.OwningProcess).Path}} |
  Sort-Object LocalPort

Then list established outbound connections:

Get-NetTCPConnection -State Established |
  Select-Object RemoteAddress, RemotePort, OwningProcess,
    @{n='Process';e={(Get-Process -Id $_.OwningProcess).Path}}

Write down the full path, for example C:\Program Files\Contoso\sync.exe. If the Process column is empty, the process runs as SYSTEM inside a service host — see the service section below.

Block an application in Windows Firewall

To stop a program from making outbound connections:

New-NetFirewallRule -DisplayName "Block ContosoSync outbound" `
  -Direction Outbound `
  -Program "C:\Program Files\Contoso\sync.exe" `
  -Action Block -Profile Any

To stop a program from accepting inbound connections (a listener):

New-NetFirewallRule -DisplayName "Block devserver inbound" `
  -Direction Inbound `
  -Program "C:\Tools\devserver.exe" `
  -Action Block -Profile Any

Block rules take precedence over allow rules for the same traffic, so you do not need to remove an existing allow rule first.

Use a group name so you can find your own rules later:

New-NetFirewallRule -DisplayName "Block ContosoSync outbound" `
  -Group "App blocks" `
  -Direction Outbound `
  -Program "C:\Program Files\Contoso\sync.exe" `
  -Action Block -Profile Any

The same rule with the older netsh syntax:

netsh advfirewall firewall add rule name="Block ContosoSync outbound" dir=out program="C:\Program Files\Contoso\sync.exe" action=block enable=yes profile=any

Allow only one application outbound

A stricter design is default-deny outbound, with allow rules for the programs you trust. Set the outbound default first, then add allow rules:

Set-NetFirewallProfile -Profile Any -DefaultOutboundAction Block

New-NetFirewallRule -DisplayName "Allow ContosoSync outbound" `
  -Direction Outbound `
  -Program "C:\Program Files\Contoso\sync.exe" `
  -Action Allow -Profile Any

If something breaks, restore the default immediately:

Set-NetFirewallProfile -Profile Any -DefaultOutboundAction Allow

Block by service instead of by path

Many Windows components share svchost.exe, so a path rule cannot separate them. Use the service short name instead:

New-NetFirewallRule -DisplayName "Block LegacyAgent outbound" `
  -Direction Outbound `
  -Service "LegacyAgent" `
  -Action Block -Profile Any

Find the short name with:

Get-Service | Where-Object DisplayName -like "*Legacy*" |
  Select-Object Name, DisplayName, Status

Check it works

Confirm the rule exists and points at the right file:

Get-NetFirewallRule -DisplayName "Block ContosoSync outbound" |
  Get-NetFirewallApplicationFilter

Test connectivity from the server:

Test-NetConnection -ComputerName 203.0.113.10 -Port 443

Turn on firewall logging so you can see drops:

Set-NetFirewallProfile -Profile Any -LogBlocked True `
  -LogFileName "%systemroot%\system32\LogFiles\Firewall\pfirewall.log"

Get-Content "$env:systemroot\system32\LogFiles\Firewall\pfirewall.log" -Tail 40

Look for DROP lines that match the ports the application uses. Then confirm your RDP session still works on TCP 3389 — if it does, the rule did not touch the Remote Desktop listener.

Troubleshooting

• The application still connects. The rule path does not match the running executable. Updates often move binaries, and some apps run a copy from %LOCALAPPDATA%. Check (Get-Process -Id <pid>).Path and recreate the rule with the real path.
• RDP disconnects after adding a rule. You blocked a system process or the inbound rule for TCP 3389. Reconnect through the browser console in your VPS provider's control panel, then remove the rule with Remove-NetFirewallRule -DisplayName "Block ContosoSync outbound".
• The rule exists but nothing is blocked. The connection is on a network profile you did not include. Check Get-NetConnectionProfile and either use -Profile Any or add the missing profile.
• A service still talks to the internet. The traffic comes from a different service, or from a shared host process. Block by -Service instead of by path, or block the remote port.
• Windows Update, DNS or time sync fails. Default-deny outbound is too strict. Run Set-NetFirewallProfile -Profile Any -DefaultOutboundAction Allow and rebuild the rules more carefully.

Next steps

• Verify the Remote Desktop listener with Check the Windows Firewall rule for RDP port 3389.
• Tighten remote access in Secure Remote Desktop on Windows Server.
• Roll firewall rules out across the domain with Advanced Windows Server: Implementing Group Policy Objects (GPO) for security.
• Pair network rules with host protection in Microsoft Defender basics on Windows Server.