Feature Request - Restricted Network Access and Execution Control

Started by HJLBX, September 27, 2016, 01:09:33 PM

Previous topic - Next topic

HJLBX

Feature request:

Limit network access for an isolated environment to only the program for which an isolated environment was created.

For example, allow network access for Cyberfox and its plugin container.

If any other processes attempt to access the network from within the Cyberfox isolated environment, then those connection attempts will be denied.

Provide user with ability to control network access on per-application\process basis.

aDVll

Sure this is not a bad idea and sandboxie advanced users will find it useful and familiar.
In my opinion a proper firewall deals with this issue and I would prefer the devs to focus on the features a firewall can't solve. Obviously i am not the one deciding on new features implementation but just my view.

fixer

At first network filtering was application-based. But later we decided to move it to environment-based. As if some isolated program can access network, other programs running in the same isolated environment can use this program (injecting in it, for example) and access network through it. So it's not 100% safe to use application-filtering. But we'll think about it, maybe we'll add application filtering as another blocking factor along with environment filtering.

HJLBX

Quote from: fixer on September 27, 2016, 01:49:13 PM
At first network filtering was application-based. But later we decided to move it to environment-based. As if some isolated program can access network, other programs running in the same isolated environment can use this program (injecting in it, for example) and access network through it. So it's not 100% safe to use application-filtering. But we'll think about it, maybe we'll add application filtering as another blocking factor along with environment filtering.

Injection into another process is a valid argument - hollow process\code injection.  That is one of the few scenarios where outbound application-based network filtering is not effective protection.

During malware testing more commonly I see malware abuse a trusted Windows process - e.g. rundll32, regsvr32, msiexec, RegAsm, cscript, wscript, powershell, cmd, etc - to connect out and download malware - or the malware just uses its own process to do the same.

So, in other words, malware testing - at least from what I see - its about 9:1 - Windows process abuse\own malware process:some form of injection involving outbound connections.

Consequently you might want to consider resurrecting the application-based network filtering.  It would be an additional protection - not one that is 100 % - but nevertheless certainly a worthwhile feature.

Sandboxie users will love you for it...

fixer

We've got it in our TODO list. I think we'll have both environment and program filtering. And only if both allow, application will be allowed to access network.

Mr.X

Quote from: HJLBX on September 28, 2016, 08:02:19 AM
Sandboxie users will love you for it...
Quote from: fixer on September 28, 2016, 11:34:09 AM
We've got it in our TODO list. I think we'll have both environment and program filtering. And only if both allow, application will be allowed to access network.
And I love both of you guys for that!  ;D (j/k)
Seriously, with environment/program filtering + checkbox to automatically recreate isolated environment upon isolated program termination, ReHIPS will rule.