how to block an app

[UnDocumented 0]

how can i block an app with antivirus endpoint 5 or ERA Server 5 ?

i want to prevent users from launching special application in program files

 

THNX in advance

[LocknetSSmith 6]

If you create this policy on an endpoint that has the app you want blocked installed, and then export the policy as an .xml, can you import that .xml to your ERAC so that, even if your ERAS doesn't have the app, it will still push the policy using an SID or something like that?

[Peter Randziak 1,168]

Hello,

 

You could accomplish this using a HIPS rule. I've included steps to do this in ERA and Endpoint Security/Antivirus below:

 

ERA: open Configuration Editor and expand Windows desktop > V5 > HIPS > Settings > Rules and advanced options. Click Edit to open the HIPS system settings management window and then click New. Type a name for your rule into the Name field and select Block from the Action drop-down menu. Click Add in the Target applications window, select "Start new application" operation, click Add, navigate to the .exe file for the application that you want to block and then click Open. Click OK to close the Add application path dialog and you should see the file displayed in the Source applications window. Click OK to close the Edit rule window. Your client workstations will receive the new rule the next time that they check in to ERA.

 

Endpoint Security/Antivirus: Press F5 to open Advanced setup. Expand Computer > HIPS. Click Configure rules to open the HIPS system settings management window. Click New. Type a name for your rule into the Name field and select Block from the Action drop-down menu. Click Add in the Target applications window, select "Start new application" operation, click Add, navigate to the .exe file for the application that you want to block and then click Open. Click OK to close the Add application path dialog and you should see the file displayed in the Over these applications window. Click OK to close the Edit rule window. Your new rules will be applied immediately on this client workstation.

 

You can apply this setting though ERA even though the application is not installed on the same server as ERA. The information is stored in the configuration .xml file.

[JAF1979 4]

I have this same question. I am using Endpoint Smart Security v5 for business.

 

I tried the suggestion, but unfortunately it does not work for certain types of applications that are not installed in the same directory across all systems. Applications such as Dropbox, which can be installed by a standard user, is installed under the user's profile (c:\users\username\AppData\Roaming\Dropbox\bin\dropbox.exe) and not the standard c:\Program Files\Dropbox etc.

 

I tried following the same steps and created a policy from ERA and instead replacing the actual username with %username% in hopes that it would automatically fill in the name of the user that is logged in, but that didnt work either.

 

Open to any other suggestions as this is something that I REALLY need to be able to implement in order to prevent my clients from using unauthorized software.

 

Thanks for your help!

 

[Chadh 45]

Hello Everyone,

 

In my previous response, I said HIPS will support wildcards in the middle of a directory path. This is not correct. HIPS rules do NOT support wildcards in the middle of a directory path. Wildcards are only supported for the end of the path (e.g. path\to\folder\*). The developers have been notified of this issue.

 

My previous statement that system variables are not allowed is still correct. The developers are also aware of this isue.

 

I'm sorry for any inconvenience.

 

Thank you,

ChadH

 

Hi JAF1979,

 

System variables are not allowed when creating an exclusion or HIPS rule with Remote Administrator. In your example, you can use the wildcard "*". The path you should use in a HIPS rule would be:

 

"c:\users\*\AppData\Roaming\Dropbox\bin\dropbox.exe"

 

This will apply a block rule for all directories in users which contains the rest of the path ("AppData\Roaming\Dropbox\bin\dropbox.exe"). For instance, it will block both "c:\users\Administrator\AppData\Roaming\Dropbox\bin\dropbox.exe" and "c:\users\Test123\AppData\Roaming\Dropbox\bin\dropbox.exe".

 

Hope this helps!

 

Thanks,

Chadh

Edited March 26, 2014 by Chadh

[JAF1979 4]

ChadH,

 

Sorry for the long delay in responding to your suggested workaround. Unfortunately, I never got a chance to reply back that it did not work, as you have indicated in the edited post above.

 

 

Is there any idea of when we will see a solution to this issue?

 

 

My users are currently running amuck installing these kinds of programs and I have to keep a constant eye on my logs to see who has what installed. They all claim ignorance to our policy against installing software and management is reluctant to discipline those who violate the policy. Sadly, all I can do is continue to ask my users to remove the software once it is discovered to be installed on their system.

 

I have executive-level users that have approval to use the site (Dropbox), so I can't block the site itself. They are just not allowed to install the app and being able block these types of applications through a global ESET policy would make life much easier for all IT admins!!

 

Thanks...

[Marcos 5,273]

What about using AppLocker to control what users are allowed to run?

[JAF1979 4]

From my understanding, Windows 7 Professional can be used to create AppLocker rules, but the rules cannot be enforced on computers running Windows 7 Professional. Only Win7 Ultimate and Enterprise.
hxxp://technet.microsoft.com/en-us/library/dd759131.aspx

All of our systems run Windows 7 Pro, so AppLocker does not seem like a viable option for me to use.

 

I migrated from Symantec Endpoint Protection, which allowed me to block applications through SEP rules (which IMHO was the only good thing about Symantec). I was hoping to use ESET in the same manner to block apps.

[Marcos 5,273]

One of the forthcoming builds of the HIPS module should add an option to use wildcards within the path which should be a solution to your issue. Also we're trying to find a way how to make the use of user variables possible in ESET's products as ekrn runs in the local system account by default and therefore user variables don't resolve.

[witty606 0]

This is a good topic. I like it. In Windows 7 ultimate and enterprise applock seems a good choice, but i'd tell you it's unstable sometimes. So, I try to find another way to solve this problem. I like ESET, I like a way based on Eset to achieve my goal. Many other HIPS software can do this easily, but i don't like that. I just like use Eset to solve my problem. And I'm happy to tell you that I have some good ways to accomplish this.

Reduce files write in c:\windows\system, many program can install any folder, but some of them must write c:\windows\system folder, this is a common place for this type software, you just need to block write.Some of files installed, we need to disable it run in the next boot, so you need to find in registry or other palce and disable it.

OK, that's it. A temp way to solve my problem, i hope eset can add wildcard support in the future.

[BobbyKearan 0]

One of the forthcoming builds of the HIPS module should add an option to use wildcards within the path which should be a solution to your issue. Also we're trying to find a way how to make the use of user variables possible in ESET's products as ekrn runs in the local system account by default and therefore user variables don't resolve.

 

How about blocking a filename?  I don't want anything named "PopularScreensavers.exe" to run on our systems no matter where it is in the folder structure.

or OffercastInstaller_*.exe or InboxSetup.exe or KnowTheBible.exe  ( wildcards are great! )

[JAF1979 4]

One of the forthcoming builds of the HIPS module should add an option to use wildcards within the path which should be a solution to your issue. Also we're trying to find a way how to make the use of user variables possible in ESET's products as ekrn runs in the local system account by default and therefore user variables don't resolve.

 

Any idea of when this "forthcoming" option might become available within ESET??

Edited January 5, 2015 by JAF1979

[JAF1979 4]

***BUMP***

 

Is the feature to use a wildcard now available within the HIPS module with the release of ESET 6?

Edited January 5, 2015 by JAF1979