Jump to content

Recommended Posts

Posted (edited)

I noticed that the HIPS rule sanity check (the mechanism that remind the user that "the created rule is too generic and may crash the system") only applies when both source apps and target app files are set to "all" AND when all application operations are enabled.

Shouldn't this check be effective as long as the source and target are both set to "all"? I am asking this because I saw someone locked himself out by accidentally adding a rule that only blocks the application start and with src and target set to "all". In this case the sanity check doesn't notify the user of the danger of such rule and the computer will crash in the subsequent boot.

Edited by 0xDEADBEEF

Share this post


Link to post
Share on other sites

I for one don't think that having a rule with no source and target applications selected but limited to specific operations should be considered too general.

Share this post


Link to post
Share on other sites
5 hours ago, Marcos said:

I for one don't think that having a rule with no source and target applications selected but limited to specific operations should be considered too general.

My view is that enabling one or several operations with all src and target monitored (block or ask) will have the potential to prevent the system from working correctly. Of course one may feel that customizing HIPS rule is for pros and then it is their responsibility to make it right. I, however, suggest to also add a warning at least when adding such rule because it is easy to make such mistake and it just happened to a user yesterday.

Share this post


Link to post
Share on other sites
Posted (edited)

Hum …..…. this one had me "scratching my head."

I guess if the rule was set to "ask" mode, it would function as a global rule to monitor for selected activity. Versus, the "hassle" of running in interactive mode and having to set multiple allow rules for everything.

Note that "ask" mode will revert to "allow" mode if not responded to within the timeout period. This would prevent any "borks" at boot time.

Edited by itman

Share this post


Link to post
Share on other sites
Posted (edited)
1 hour ago, itman said:

Hum …..…. this one had me "scratching my head."

I guess if the rule was set to "ask" mode, it would function as a global rule to monitor for selected activity. Versus, the "hassle" of running in interactive mode and having to set multiple allow rules for everything.

Note that "ask" mode will revert to "allow" mode if not responded to within the timeout period. This would prevent any "borks" at boot time.

yes, but waiting for each ask prompt to timeout generally makes the system unusable upon a boot. Therefore I hope ESET can add such reminder for rules of this type. 

Edited by 0xDEADBEEF

Share this post


Link to post
Share on other sites
Posted (edited)
1 hour ago, 0xDEADBEEF said:

yes, but waiting for each ask prompt to timeout generally makes the system unusable upon a boot.

An alternative and better approach when creating a wide impacting generalize rule like this is to create it in "allow" mode with logging enabled. You could use the log as a guide in creating corresponding process rules. Then a "block/ask" could be created for the monitored activity. Remember that allow rules are executed prior to any other mode rules. Also I would favor use of "ask" rules over "block" ones unless one is 100% certain over what the impact of blocking process activity would be.

Edited by itman

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

  • Recently Browsing   0 members

    No registered users viewing this page.

×