that's because it's not possible to create universal security templates that will work on every system. each system, with its own hw and sw environment and the attack vectors it's vulnerable to, is unique and needs different mitigations. it takes a certain level of experitse to apply those mitigations, years of experience. if sw vendors created such "universal" templates, then too many systems would fail to boot up due to misconfigured os's. it's not heuristic level or fw setup that @guest and @itman are referring to. rather, application control, srp and applocker policies, etc.
Does that mean that there are absolutely, positively, NO security tweeks of ESET's default settings that would be *safe* & valuable to (say) 90% of systems? No tweeks? None? Not even 1? Zero? OR is it a case that the 90% of users (assumption for sake of discussion) are less secure due to dumbing-down for the sake of the 10% with unusual &/or ill-structured systems?
no, it doesn't. the simplest thing you could do is choose the highest/max security level template for your product, but i doubt it would make any difference. if you'd like to go even further and tighten it to the highest level, the way @guest said, then you need to learn how to configure your sw by yourself and that needs some time and experience. neither @guest nor @itman could tell you how to tweak your av/fw/iss's application control component.
I have no argument with that posit. But that is a generalization. Does it specifically apply, 100%, to tweeks of ESET's default settings? Are you saying that no one who isn't a full-on security/computer expert should ever try to make any tweek whatsoever to ESET's default settings?
no, i'm not saying that. oc anybody could tweak eset's settings via its interface. i'm saying it takes a certain level of expertise to configure any security sw, be it eset or any other sw, the way and to the level @guest said. because he's not referring to tweaking av/fw components, but to application control and srp mitigations.
@guest posted, "If you learn to tighten ESET, you need nothing else." The plain sense of "tighten ESET" is that it involves tweeking ESET's settings via the interface and NOT other tweeks separate & apart from ESET. But guest is guest (and that is a praise, not a criticism), so you could be right. Further Affiant Sayeth Naught.
@bellgamin come to think of it, here's a simple explanation and example to what i'm saying. now, we all know that apple has very strict policies when it comes to ios security, right? it doesn't allow any 3rd party app to be available on the appstore unless it's verified and strictly in compliance with apple's security and privacy policies. and it doesn't allow any 3rd party security app to interfere with ios at kernel level. that's why security sw vendors do not release ios versions of their products. this way, apple can make sure that their os's are always stable and secure and can be tweaked via "universal" templates. but things are different with android. it's a jungle on google play. every device needs its own tweaks and configs. and there are always stability, performance and security issues. and that's how things are with windows.
exactly. i'm not talking about separate / other tweaks apart from eset, either. eset has application control component. and that's the key component to apply those mitigations. you need to "learn to tighten eset via its application control component's interface", not the av or heuristic component. you can tighten eset, if you know how to use gpedit and secpol to tighten your os. it's the same thing.
Back to the thread's topic -- As to Comodo FW, ESET offers all that Comodo offers, and more (& it's waaay more user-friendly, as well). In point of fact: ESET is the go-to AV/FW that I recommend to all my friends, and even to my enemies (Mt 5:44).
I suppose "MT" refers to malwaretips.com. Is THIS the thread you had reference to? @daveiw -- in case shmu26 doesn't reply right away, I call your attention to this link -- it likely is the 1 shmu26 had in mind. By the way, I always make an image of my C drive before installing &/or setting-up any security app. You might want to do the same thing. Good luck!
ESET and most of the other vendors release their soft at default level which they assume is safe enough while assuring best compatibility during installation. Obviously it is not the best protection mode possible, it is why i recommend people to learn how to tighten their soft. It is mandatory to me. "Safe enough" isn't enough to me. I used to not use/ditch most software that don't allow me to tweak them to the core. It is even more true when like ESET or some others, they have HIPS/BB/Application control module which must be tweaked to fit the system they are installed on. Getting expertise with your chosen soft has more value in term of security than stockpiling 5+ apps.
Good morning, Yes, MT is Malwaretips. I didn't want to make it sound as if I am hyping or promoting another forum, so I made the mention as low-key as possible. I haven't been following the ESET discussion over there so closely, but here's another hot thread over there that I noticed: https://malwaretips.com/threads/configure-eset-as-default-deny-bye-ransomware.91105/
@bellgamin the key posts on the thread @shmu26 linked to: post #44: and post #52 (in reply to blackice's post #44) :
True, configuring ESET for advanced protection is not for the fainthearted, but numerous blocks from Powershell and Windows Script Host is not going to happen to most people. There are very few common programs that use those interpreters. Many people block Powershell and Windows Script Host and still sleep well at night.
Generally speaking, most of my Eset customizations are duplication of what is found in SysHardner(firewall) and OSArmor(HIPS). I haven't used OSArmor since I didn't want to risk conflicts with Eset. The rest of the customizations involve blocking process modification activities against targeted Win system processes such as explorer.exe, svchost.exe, etc.. Obviously and in regards to these processes, you will most certainly bork your OS if you don't know what you are doing. -EDIT- The biggest problem is the Eset HIPS is it's "not user friendly" by Eset design. It was designed for Eset internal use and Eset has done nothing in recent history to change that. As such, don't expect much help from Eset itself when it comes to user rule creation. Also you won't find many guides or "here is my great configuration" examples on the web about the HIPS. I have never published my rule sets simply because I don't want to get involved with people applying them and borking their installations. Almost forgot my biggest "pet pevee" with the HIPS. It is in regards to the "out of the HIPS stone age" snytax capability it has. Eset has been promising *.exe wildcard capabilty for years and has yet to provide it. And I am referring to the fact you can't do so at the lowest full path specification level.
It's a shame that one of the pretty-good, super-light AVs (such as K7) doesn't license OSArmor & build it into their AV as an industrial strength, user-friendly BB (Behavior Blocker). IMO, doing so would catapult K7 (or just about any other second tier AV) into top tier. And if Windows Defender grabbed OSArmor AND incorporated it, katie bar the door!!!
there is no replacing of the default deny auto sandboxing of Comodo. nothing that i considered acceptable that is.
K7 or MS don't need to license OSA, MS has already default-deny protection built in pro and enterprise version, it is SRP and Applocker, doing more or less what OSA does. Anti-exe mechanisms isn't proprietary, anyone can make one.
But default-deny is in the same ball park as an anti-executable, right? Whereas OSArmor is a behavior blocker, right?
