Jump to content

Archived

This topic is now archived and is closed to further replies.

Recommended Posts

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.

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

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.

Share this post


Link to post
Share on other sites
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. 

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

  • Recently Browsing   0 members

    No registered users viewing this page.

×