0xDEADBEEF 43 Posted July 14, 2018 Share Posted July 14, 2018 (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 July 14, 2018 by 0xDEADBEEF Link to comment Share on other sites More sharing options...
Administrators Marcos 5,070 Posted July 14, 2018 Administrators Share Posted July 14, 2018 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. Link to comment Share on other sites More sharing options...
0xDEADBEEF 43 Posted July 14, 2018 Author Share Posted July 14, 2018 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. Link to comment Share on other sites More sharing options...
itman 1,659 Posted July 14, 2018 Share Posted July 14, 2018 (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 July 14, 2018 by itman Link to comment Share on other sites More sharing options...
0xDEADBEEF 43 Posted July 14, 2018 Author Share Posted July 14, 2018 (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 July 14, 2018 by 0xDEADBEEF Link to comment Share on other sites More sharing options...
itman 1,659 Posted July 14, 2018 Share Posted July 14, 2018 (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 July 14, 2018 by itman Link to comment Share on other sites More sharing options...
Recommended Posts