ESSBE Feature requests

I'd like to request two new features in ESSBE. The first is of much more value to me.

The firewall would be of far more value if, when building rules sets either interactively (when prompted, in interactive mode) or directly in set up if there were an option that would allow the target application to be included in application defination for svchost.exe, rundll.exe, and rundll32.exe.

This way, "C:\windows\system32\svchost.exe{LocalService}" could be permissioned appropriated, without also permissioning "c:\windows\system32\svchost.exe{SomeMalware}" to allow traffic to the same destination port - which is especially problematic because the valid destinations to some required services (such as Automatic Updates) are nearly impossible to determine beforehand and must therefore be opened to "all", and uses the most common of destination ports (i.e. 80).

Similarly, "C:\WINDOWS\system32\RUNDLL32.EXE{C:\WINDOWS\system32\ValidApp.dll} could be permissioned without simultanously permissioning "C:\WINDOWS\system32\RUNDLL32.EXE{C:\temp\MalWare.dll}

As it is now, in a business environment where not every user can effectively manage their traffic, the firewall must be left open to allow desired service/rundll-based traffic, which opens the system more than is desirable for malware traffic.

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

The second request would be for an administrative option on the Interactive mode, which would allow the administrator to specify the defaults for how much of the current traffic violation are included in the new rule - as it is now, in interactive mode the average user in short order permissions themselves into a state where the firewall is not blocking much of anything.

As well, there should be an option that allows the administrator to disable the creation of new rules entirely, permitting end users only "Temporily Allow".

This significantly decreases the risk of inadvertant permissioning which is too permissive, and would better allow the administrator to sift through and condense the traffic into reasonable rulesets.

Thanks you for your time,

K12RS

 

Users should not be able to decide (even temporary allowing something could be a huge mistake) . That is why Policy-based mode is the best for business environment . If your settings are password-protected and if you use Policy-based mode , no end user can create firewall rules. v4 (currently in beta1 stage) introduces self-protection and uninstallation password-protection which will make the firewall stronger (I mean evil end users will need force to destroy the protection).

 

Agreed - in a perfect world where I could apply best practices without fail, I would dictate that the end user could not change their own permission set, because they would never need to - I would have complete and accurate foreknowledge of the traffic pattern and installation path of every application or applet used by my users, and adequate, complete and timely notification of any changes, such that I could permission the rule sets ahead of time for them and the firewall would never impact their ability to use the tools they need.

However, I need to solve a real world problem, in which there are limits on what I know and can know, as well as limits on the amount of time I can focus on this one aspect, and the changes requested would allow me to better solve the real world problem at hand - which is namely to how to effectively incorporate ESET's local firewall to provide another layer of defense in depth to our systems, without making it so draconian that it consumes all available resources, and so open that it's not worth doing.

The tools requested would allow for some middle ground between Policy based mode (which is not always practical, even though it's highly desirable) and Interactive mode (which requires too much of the user to properly implement).

One thing I forgot to add to the request is something that's been asked for by many people, and that would be better logging of what's been temporarily allowed so that I could determine what's been permissioned by the user and either add or deny it to the rule set.

Take care,

K12RS