Basic packet filter for Sandboxie+

Recently I was looking into adding a basic packet filter to sandboxie using WFP

As you may know the old sbie has this BlockPort feature https://sandboxie-plus.com/sandboxie/BlockPort/
This is not enforced by the driver i.e. any malicious application can work around this quite easily.

So for once we need to do that properly using WFP and it would be nice to also be able to block IP's etc..

So yes we are talking about a sort of basic sbie firewall.

Now on a technical side this is quite strait forwards to do, but on the config side, I'm not sure how to best implement this.

The issue is with contradicting rules, and redundant rules.
We would for example want to allow only ports x and y or we would like to block
all ports but x and y.
So we would have an option BlockPorts=123,456
but also an option AllowPorts=80,443
effectively meaning if any AllowPorts is specified all the AllowPorts accumulate and the BlockPorts are irrelevant as everything but the allowed ports is blocked anyways.

Ok but what if we want to block all 80,443 communication except to a specified IP something like

NetworkRule=Block;Port=80,443;
NetworkRule=Allowort=80,443;IP=111.222.333.444

in that case we would want the more detailed rule to overwrite less specific once

NetworkRule=Block;Port=80,443;IP=0.0.0.0-255.255.255.255
NetworkRule=Allowort=80,443;IP=111.222.333.444

also here a specified IP overrules a IP range,

Ok what about other rules

NetworkRule=Block;Port=80,443;Protocol=TCP
NetworkRule=Allowort=80,443;IP=111.222.333.444

What now which specification wins the protocol or the IP

or this case

NetworkRule=Block;Port=80,443
NetworkRule=chrome.exe,Allowort=80,443

what does this mean chrome is excepted from the blocade

as you see there are quite a few levels of priorities and the result must be comprehensible to the user,
we don't want people setting up nonsensical rules that sounds ok to them just to wonder why nothing behaves as expected.


And should we allow for a rule like
NetworkRule=Block
that would block all internet access for all processes in the box instead of having a dedicated setting like "AllowNetworkAccess=n"
thats overwriten by mor specific values like
"AllowNetworkAccess=<InternetAccess>,y"

we could keep everything rule based
NetworkRule=Block
NetworkRule=<InternetAccess>,Allow
NetworkRule=Block;Port=80,443
NetworkRule=chrome.exe,Allowort=80,443

but what with
NetworkRule=Allow;Port=80,443
that would overwrite the blanked block rule NetworkRule=Block



The attributes we have at our disposal are:
Program=program.exe
Action=Allow|Block
Port=80,443,1000-2000
IP=111.222.333.444, 0.0.0.0-255.255.255.255
Protocol=TCP|UDP

So what should be the priority of the attributes
1. A rule with a program trumps a rule with all programs but x, trumps a rule for all programs
2. a rule with a Port or IP trumps a rule without, sounds reasonable
2a. a rule with ip and port trums a rule with ip or port only
2b. a rule with one ip trumps a rule with an ip range that is besides that on the same level
3. block rules trump allow rules except for 2
3a. an allow rule means block implicitly everything else at the current rule's specificity level
4. a rule without a protocol means all protocols, a rule with a protocol trumps a rule without if its the only difference



Does that sound useful.... the normal windows firewall is quite dumb, it simply says a block rule trumps all and that's is

but we want to be better

 

I already use something that deals with default Windows firewall (H_C Firewall Hardening) plus I have some custom rules but it's an intriguing idea.

However, if you choose not to pursue this, I would be OK with that. Sandboxie Plus already works wonderfully well for its intended purpose, and any additional feature presents a potential for things to go wrong. So, if it's implemented, I would suggest a means to disable it.

 

no firewall feature, please. not sure about others but i already have a decent firewall and sandboxie already has a allow/deny option for web-access, it dont need more granular filtering, even not based on WFP.

In short: No!

 

I agree that a firewall is not needed. If you did decide to implement this, I would also like to have the option to turn it off.

 

PLAIN tag

Code:

[PLAIN] [/PLAIN]

=Block;Port=80,443;
NetworkRule=Allow:port=80,443;IP=111.222.333.444

in that case we would want the more detailed rule to overwrite less specific once

NetworkRule=Block;Port=80,443;IP=0.0.0.0-255.255.255.255
NetworkRule=Allow:port=80,443;IP=111.222.333.444

also here a specified IP overrules a IP range,

Ok what about other rules

NetworkRule=Block;Port=80,443;Protocol=TCP
NetworkRule=Allow:port=80,443;IP=111.222.333.444

What now which specification wins the protocol or the IP

or this case

NetworkRule=Block;Port=80,443
NetworkRule=chrome.exe,Allow:port=80,443

 

If you can implement something that makes Sandboxie protect better, then I say why not. If it's something that has the potential to break stuff, then having an ability to turn it off would be good. I am just using Windows firewall myself.

 

Please don't make sandboxie to "advanced for casuals". New users are already often confused how to restrict stuff in sandboxie at all (like internet access or folders or ...)

From the people that use sandboxie the amount of people using different "tightend" sandboxes will be small. The amount of people able to understand this firewall rules will be even smaller. // No number to prove just me guessing. It's above my firewall skills I wouldn't need it. (H_C recomended blocking here)
If you do it please give us an option to disable it.

 

Like the way how Florian deals with the allowlist and blocklist.

Code:

Priority rules are rules, that can overwrite any other classic Bouncer rules whether they are on the white- or blacklist. Although Bouncer supports a very powerful rules engine right now, we think that priority rules will provide more flexibility and result in better protection rules.

A priority rule can be set by adding "!" at the beginning of a rule's line, e.g.:

[WHITELIST]
!C:\Windows\Temp\AVUpdaterXy0001.exe
C:\Windows\*
C:\Program Files\*
C:\ProgramData\Microsoft\*
...
[BLACKLIST]
C:\Windows\Temp\*
...
In the example from above we declared C:\Windows\Temp\* to be on the blacklist. For good reasons you shall limit access to this folder, but it often happens that legit applications need to write and execute from C:\Windows\Temp\, hence you cannot block the folder without having issues afterwards. With priority rules you can define rules that will overwrite other rules, so in our example the whitelist rule

!C:\Windows\Temp\AVUpdaterXy0001.exe
will overwrite the blacklist rule

C:\Windows\Temp\*
Hence in this example the AVUpdater can execute from C:\Windows\Temp\ but other applications started from C:\Windows\Temp\ will still be blocked. Additional note: If you have set priority rules in both sections [WHITELIST] and [BLACKLIST], then the priority rule from [BLACKLIST] will always overwrite the priority rules from the [WHITELIST].

Please note, that the order of rules matters. If you have a whitelist rule C:\Windows\* you shall set the priority rule !C:\Windows\Temp\SomeUpdater.exe before C:\Windows\*, otherwise the rules engine will find C:\Windows\* first and this rule will then be blocked (because it is no priority rule) by the blacklist rule C:\Windows\Temp\*.

 

Better: make it opt-in, means disabled by default because no one probably need it.

 

@Brummelchen what is that decent firewall?
I havn't seen one in a long time, except some fringe once like simplewall, WFC, or what i added to priv 10
imho they all are quite limited by what windows allows without going into spinning up an own driver.

 

Wouldn't a plug-in be even better so that it stays almost independent from the core code base of Sandboxie?

 

The thing is I can eider make it sbie specific and than I woudl need to put it in the sbie driver.
Or I could make it an entirely independent tool, but than its much more work and I feal like there are firewalls out there so may be its not the best use of my time to reinvent one of those from scratch.

 

What about a plugin-in driver loaded on demand? Is your certificate for signing the Sandboxie driver usable for another driver?

 

Do it this way. I'm willing to learn a new smart useful feature. Do it.

 

If you do pursue this new feature in Sandboxie Plus, my preference would also be opt-in, or at minimum, the ability to disable.

I prefer mixing and matching separate s/w of choice for specific functions / objectives, rather than one all-in-one s/w (that may become too complex - or bloated).

 

Yes, I agree with this.

It seems the dev. really, REALLY wants to pursue this. Could he consider a branch off of the Plus/Classic builds? That way, you can choose whether to run Sbie with the firewall module...or completely without it.

 

I use the latest Windows 10 Firewall Control from sphinxsoft. Because it's the only current one which is very similar to Outpost Firewall which was abandoned after Kaspersky bought Agnitum. And yes, it has a driver, but Widows Firewall is also active but it wont bother me - and W10FC is showing events cause by WFP.

For Windows 10 Windows Firewall is mandatory. You really should leave it alone. The nearest firewall to WF is indeed WFC from (ex)binisoft. no doubt.

 

Well I kind of would love to but I also see that its quite redundant for anyone with a decent firewall.
I mean if people are fine with an unreliable BlockPort option that fine with me LOL

Anyhow if i would add this it would be
1.) entirely switchable that is globally the entire WFP driver part could be disabled
2.) in any box the user could specify which method should be used i.e. some apps could be blocked hard core, others only using WFP

That said as seemingly most people don't want this I will put it of for later.

 

I also don't think that such a thing is needed in Sandboxie. We can already block process execution and network traffic. This stuff may cause bugs and Sandboxie should be about isolation.

 

A important part of isolation is to manage network connectivity, so I think such a feature is needed, and as its optional it does nto need to be used



The next build will include a network firewall, its doubly implemented once in kernel mode using the windows filtering platform that's the mode to be used for optimal rule enforcement.
when WFP is not enabled with the driver the same rules are being applied in user mode with hooks on the winsock2 api. Of cause when WFP is enabled the user mode implementation is turned of.

The reason for implementing it twice is quite mundane debugging user mode code is 1000x easier than debugging a driver and the little code for the ws2 hooks was not so much work given that it was already partially there for the BlockPort=... function
Now the new mechanism replaces the "BlockPort=..." ini options and as one can see on the screenshot is much more flexible.

 

Great job David

 

OK, as long as it's optional, as you say it will be.

 

what should be the name for the new firewall settings in the ini
"NetworkAccess" "NetworkAccessRule", "NetworkRule", "NetworkFirewallRule", "FirewallRule"?

 

This one

 

or this one!

"NetworkFirewallRule"