windows firewall will not block .exe on a mount point

Question

windows firewall will not block .exe on a mount point

jojothehumanmonkey 21

hello and thanks.

need to block .exe on a mount volume
the app is b:\mount\bl\keepass\KeePass.exe, which runs well.

now, i need to block network access for that .exe; windows firewall will not block it.

if i run keepass.exe from 'real' drive, then the firewall can block it.

so how do i block a .exe that is on a mount point.

here is the output of mountvol.exe

\?\Volume{220a8896-6984-11eb-9d63-482ae32ef6d1}\
B:\mount\bl\

thanks much,
jojo

Accepted answer

2 additional answers

Your answer

Answer 1

Hello @jojothehumanmonkey ,

I was hoping that using a program path like \.\Volume{220a8896-6984-11eb-9d63-482ae32ef6d1}\keepass\keepass.exe or \.\HarddiskVolumeX\keepass\keepass.exe would work - but unfortunately it doesn't; the syntax is accepted, but it creates a native path like \device\mup\HarddiskVolumeX\keepass\keepass.exe (which is not correct, this is the equivalent to a UNC path to the server HarddiskVolumeX and share keepass).

It is possible to block the connection by using the low-level WFP API (e.g. FwpmFilterAdd0) but this is a lot of work and the resulting rule cannot be managed via MMC or netsh.

Obviously, just assigning a drive letter to the second volume would work. I will continue to check if there is any way to create a manageable rule for a program on a volume that does not have its own drive letter assigned.

Gary

Answer 2

Anonymous

Hi ,

Did you mean putting the path of b:\mount\bl\keepass\KeePass.exe here and create the Firewall rule successfully, but the application still can access the internet?

If I have anything misunderstanding, please feel free to let me know. Please clarify more details to help us identify your issue.

Best Regards,

Candy

--------------------------------------------------------------

If the Answer is helpful, please click "Accept Answer" and upvote it.

Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

jojothehumanmonkey 21 Reputation points

2021-02-23T13:56:02.127+00:00

Hi and Thanks,

I can create the rule but the rule is not enforced.
Here are the rules,
The rule for keepass-mpoint does NOT block
The rule for keepass-zdrive does block

Here is the drive from Computer Management
Gary Nebbett 6,216 Reputation points

2021-02-23T16:48:53.717+00:00

Hello @jojothehumanmonkey ,

To better understand what is happening, you could try the following. First dump the state of the Windows Filtering Platform (WFP) with the command "netsh wfp show state file=block.xml". Then search "block.xml" with an editor, looking for "KeePass" - this should show the actual filter conditions used.

The paths used in the filters will have probably been translated into "native" paths like "\device\harddiskvolume3\windows\system32\mmc.exe" or "\device\mup..."; verify that the native path used for "b:\mount\bl\keepass\KeePass.exe" is plausible.

Gary
Reza-Ameri 17,341 Reputation points Volunteer Moderator

2021-02-23T16:52:10.647+00:00

I notice it is outbound rule, try block inbound rules and see if problem persist?
jojothehumanmonkey 21 Reputation points

2021-02-23T17:47:43.27+00:00

Hi and Thanks,

i started over.
deleted the mountpoint
deleted the firewall rule
created a new mountpoint pointing to a different folder.
created a new firewall rule.
same result, firewall will not block keepass.exe on the mountpoint.

here is the 'native' path from block.xml for keepass.exe mounted to a folder, for which the firewall rules does NOT work.
'\device\harddiskvolume6\mount\bltest\keepass\keepass.exe</asString>'
by way of comparison, here is the file path on keepass.exe on the z: drive, for which the firewall rule does work
'\device\harddiskvolume9\keepass\keepass.exe'

here is the file path
'B:\mount\bltest\keepass\KeePass.exe'

here is the computer management
c:\ex\firewall\compmang.PNG

here is the firewall rule
c:\ex\firewall\frule.PNG
jojothehumanmonkey 21 Reputation points

2021-02-23T20:52:15.89+00:00

Hi,

i was able to test an inbound block rule using this
https://nmap.org/ncat/guide/ncat-usage.html,

i ran that batch file at three locations.
i setup three inbound block rules, one inbound block rule for each location.
c:\ex\data\c\ncap\nmap\ncat.exe - the inbound rule blocked the app
z:\c\nmap\nmap.exe - the inbound rule blocked the app

but for this, the inbound block rule did NOT block nmap.exe on the mount point , EXACT same behavior as the outbound rule
b:\mount\bltest\data\c\nmap\nmap.exe

thanks,
jojo

Answer 3

Gary Nebbett 6,216

Hello @jojothehumanmonkey ,

Another idea is to use Event Tracing for Windows (ETW) to trace what happens when b:\mount\bl\keepass\KeePass.exe tries to initiate a connection. The most useful provider to trace is "TCPIP Service Trace" and I would also suggest including Microsoft-Windows-TCPIP for additional context. The trace should show the path name that is used when classifying the connect request. Here is a brief example of what the trace data might show:

You probably won't have access to the tools/metadata needed to view the trace comfortably, but if you can just search the trace results for Unicode (UTF-16) strings including "keepass.exe" (case insensitively) then you should see the path that is being considered by the filtering platform. Given that information, it should be possible to work backwards and determine what path to use in the "block" rule.

Gary

jojothehumanmonkey 21 Reputation points

2021-02-24T14:34:55.72+00:00

sorry, i am confused.

when the firewall rule is created, the software changes b:\mount\bl\keepass\KeePass.exe to \device\harddiskvolume6\mount\bltest\keepass\keepass.exe, as shown in the output of netsh wfp show state file=block.xml

so not sure what is the point of ETW tracing?
thanks,
Gary Nebbett 6,216 Reputation points

2021-02-24T16:31:32.777+00:00

Hello @jojothehumanmonkey ,

There are two things that need to coincide: the path in the filter and the path passed to the filter by the operating system when the process tries to open a connection. The "netsh wfp show state" command gives us the first part but we don't yet know (for certain) the second part.

Gary
Gary Nebbett 6,216 Reputation points

2021-02-25T13:12:54.977+00:00

Hello @jojothehumanmonkey ,

I just tried constructing a similar configuration and testing it myself. As suspected, there is a mismatch between the path stored in the filter and the path presented to the filter by Windows when the program actually tries to create a connection.

The path stored in the filter seems to be created from the "Windows" filename (e.g. B:\mount\bl\keepass\KeePass.exe) by replacing the drive letter (e.g. B:) with the mapping for the drive letter (e.g. B: -> \device\harddiskvolume6).

Mount Points are a specific example of Reparse Points (with a reparse tag of IO_REPARSE_TAG_MOUNT_POINT) and reparse points can have an impact on the resulting name presented to an OS component (e.g. a WFP filter).

In my test, the path which is compared against WFP filters is the path after modification by the reparse point.

In your case, \?\Volume{220a8896-6984-11eb-9d63-482ae32ef6d1} is a symbolic link to something like \Device\HarddiskVolumeX and the path compared against the filters will be \Device\HarddiskVolumeX\keepass\keepass.exe.

So in the rule, one would need to use the drive letter assigned to \Device\HarddiskVolumeX followed by \keepass\keepass.exe.

I had assumed that you had two different copies of keepass.exe: one on the Z: drive and one somewhere else. I now suspect that there is just one copy, reachable via two paths. If that is correct, the rule for Z:\keepass\keepass.exe should also block access when the program is invoked by its alternative name of B:\mount\bl\keepass\keepass.exe.

Gary
jojothehumanmonkey 21 Reputation points

2021-02-25T15:30:05.687+00:00

thanks for testing,

i guess this is some kind of a bug, as the firewall should just figure out on its own what to do

about the test setup

one usb drive with two volumes.

two independent copies of keepass.exe; each running on its own volume

z: was a drive letter mount point for one volume. where the firewall rule worked.

B:\mount\bl was a mount point for the second volume. where the firewall rule did not work
jojothehumanmonkey 21 Reputation points

2021-02-25T16:47:36.51+00:00

in the end, i will have to mount to a drive letter.

i was i work on a lot of computers, often remotely, never knowing if a drive letter is already in use, perhaps as a net share.
i rely on the mounting to a folder.
all my scripts use that.

thanks much,
david
Gary Nebbett 6,216 Reputation points

2021-02-26T14:24:27.673+00:00

Hello @jojothehumanmonkey ,

I checked as far as I could, and the program path in a rule can only be the special value "SYSTEM" or a UNC path or a Windows path starting with a drive letter - there is no support for paths starting with "\?\" or "\.\".

There is no easy work-around in general, other than assigning a drive letter to the volume containing the program. I have some ideas about elaborate workarounds, but they are not proportionate to your problem.

If there is something "particular" to your use case for the blocking rule then that could perhaps be exploited. The idea of using FwpmFilterAdd0 turns out to be not so difficult, but the filter/rule so created does not persist across system restarts and cannot be managed/viewed like other firewall rules. If you only need the blocking rule during one logon session, then this could be an option.

Gary
jojothehumanmonkey 21 Reputation points

2021-02-26T18:18:50.91+00:00

thanks much

Share via

windows firewall will not block .exe on a mount point

2 additional answers

Your answer