Eset NOD32 Antivirus and Eset Smart Security version 9

Came across this 20 min. review of ver. 9: https://www.youtube.com/watch?v=rhyf0R4f6oc

Usual bag of limited malware testing, etc.. What was interesting was author has a Cryptolocker link he ran. Eset didn't prevent it from running but video showed no damage done. Author was satisfied that Eset had contained it. However, a comment posted noted that Cryptolocker is VM aware and will not run payload when VM detected. Also author did not reboot to verify that it was not run at boot time.

 

AV-C too ? I know AV-Test is testing that, didn't know AV-C had started as well, but that's good.

And keep posting your findings, cons and pros, I am sure @Marcos is reading what is posted here too.

 

Oops! Your correct. It is AV-Test.

 

I guess it should also be mentioned that people using WIN 7, as I am, are having the most issues with ver. 9 as noted in the Eset forum.

This makes "Eset" sense to me. With both a new release of ver. 9 and WIN 10 in progress at the same time, Eset concentrated their resources and attention on making ver. 9 work on WIN 10. I also strongly suspect that Eset will not correct the current problems with WIN 7 and ver. 9 since they believe it will be absolete in less than a year when most are upgraded to WIN 10.

So probably best to forget upgrading to ver. 9 if you're using WIN 7.

 

Well, like a dope, I installed version 9 of NOD32 on my 4 Windows 7 computers and THEN I discovered all of the problems I had with it.
To identify Version 9 as the cause I simply disabled 9 and the problem went away.

Well, all computers are back to version 8 but what gets me is that Version 9 was in beta for quite a long time so why so many problems after release? I recall running the beta of Version 8 and it seemed to run fine right from the beginning.

 

Another feature missing in ver 9: https://forum.eset.com/topic/6477-e...-incompatibility-with-eset-8-firewall-config/

 

Lack of participation. Everyone wants to wait for the final and the bugs that were never discovered are then found. Beta testing is not for everyone, but if nobody is reporting these issues in beta they won't get found until release. I ran the beta on Windows 10 and thought it was quite good, until I tried to uninstall and had much difficulty. I never tried it on Windows 7. I doubt the people that have no complaints are rushing here to report that. As someone that works for a software company, I know what it's like to release something and have people screaming "How did it get released with these bugs!?", but we did not encounter them and nobody else reported them. It's frustrating and embarrassing but until someone else finds the issue(s) it is difficult to impossible to resolve the them. Different machines, with different configurations, different usage patterns, different needs and expectations.... it is impossible to anticipate it all in advance.

 

What are the bugs that u have?
I have a desktop pc with lot of steam games and with a lot of movies and editing programs windows 10 x64 no problem.
A laptop dell d620 windows 10 x32 for browsing no problem.
And a dell mini 910 with vista x32 no problem again.

 

Good Afternoon! Itman...I'm in complete accord with your observation...that's V9 is Pro Windows 10...from a Sales and Mktg perspective...pure and simple. As stated by many individuals...go too Eset's Website and all will be revealed...it wasn't meant for Windows 7 users. So I have aligned myself with NIS 2016...and so far I'm very pleased with it's performance on my system. So like a lot of Windows 7 users...if Eset can provide a stable release...I might reconsider at a later date. Still no rush to migrate to Windows 10. Sincerely...Securon

 

You have a valid point. However, some of the issues raised to date on border on negligence.

Take the HIPS rule issue. No one at Eset noticed that ver. 9 rule ordering was totally different than that in ver. 8? In ver. 8, all user created allow rules are executed prior all block rules. In ver. 9, your existing rules end up a jumbled mess with block rules interspersed with allow rules when ver. 9 is installed over ver. 8. BTW - this is the only option you have if you want to maintain your existing rules since Eset changed their internal formatting of the rules. An import of ver. 8 settings will fail because of this. Anyone who know how a HIPS functions realizes rule positioning is of absolute importance. The same applies for newly created rules in ver. 9. All rules are added at the bottom of existing rules. My own opinion on this issue is Eset didn't care about existing users and just modified the HIPS to suit their own needs.

Then there are the SSL protocol scanning issues which BTW were fully pointed out in the beta testing by people. Worse, Eset made that feature mandatory in ver. 9. If you disable it, Eset status display will indicate you're not fully protected.

There are memory leaks in ekrn.exe that still exist that were reported in the beta testing. I suspect this is why the release runs "heavy" on many systems.

And the list goes one ...........................

 

After reading all responses it looks like staying with v.8 is wise in Windows 7 OS. I didn't get an offer to upgrade on my family computer yet. Will see if that ever happens (in years of using ESET I've never saw it upgrade automatically).

 

All the issues raised should be fixed. I'm guessing there are problems with the HIPS since few people use this. Were the HIPS problems discussed during the Beta period?

 

There is also a few choice tidbits about the ver. 9 firewall people should be aware of.

Eset went to lengths in ver. 8 to indicate that the firewall uses the Windows Filtering Platform(WFP). The implication being that it is fully WFP compliant. Well, it isn't. An integral part of WFP is Windows Service Hardening(WSH). The best way to explain WSH is for you to look at the default Microsoft rules present for the WIN 7/8 firewall. Explore the rules dealing with svchost.exe. What you will observe is they all have a specific OS service specified. This is the only secure way of coding svchost.exe rules for a firewall. Now look at the svhost.exe rules created for the Eset ver. 8 firewall. You will observe that there is no provision present to associate a particular service for a svchost.exe rule. In other words, ver. 8 is not WSH compliant.

Well, Eset corrected the above deficiency in the ver. 9 firewall; you now can specify a particular service for svchost.exe. A good thing - right? Yes and no. For starters if you ran the firewall interactively in ver. 8 and installed on top of ver. 8 to maintain those rules, you're going to get a lot of outbound alerts about svchost.exe. None of the old "global" svchost.exe rules are applicable anymore. Then there is the issue of requiring a service to be specified for every svchost.exe rule created. I have never seen a vendor firewall or 3rd party WIN firewall add-on product pull it off successfully. The reason? The OS uses "hidden" services for some outbound connections. These are not services listed under the Admin services snap-in display. So I expect a number of issues in this area with ver. 9.

-EDIT-

To be 100% technically correct, WFP is an interface to the WIN 7 and above Windows firewall. WSH is a feature of the Windows firewall itself.

 

As for the HIPS rules if I recall correctly they were originally telling people that they were different and recommended not saving your old config. They probably gave in later and told people what they wanted to hear. That will suck for some but I always start fresh with a new product.

The SSL issues need work. Based on their previous record, it will take a while.

The memory leaks are probably difficult to find and likely do not affect everyone. I expect that one to drag on for a while, and they have had that problem with previous versions (7, I think?). Someone having the problem will have to help them identify it or it's just not going to get fixed.

That said, I am not currently running their product, but would like to be if they get it fixed. Everyone can choose their own level of tolerance on the issues they are having, but it will take them some time to deal with any of them. Report what you have, expect that they are reading this whether they reply or not, and know that they will eventually fix this stuff, at some point.

 

Interesting reading the posts.

I am back to Version 8. I'm happy with it as I was before, so end of case.

 

I don't think that is the case, V9 supports XP SP3 and later. If an XP user buys the product and get some kind of problem, they have the right to product support from ESET like every other user, even if the OS itself is unsupported by its maker MS. And quite often problems can be fixed via module updates - they may not even need to release a new build of the product that users has to download.

So I don't believe that they are going to leave any problem alone on any OS platform older than Win10 because they expect everyone to upgrade to Win10 ASAP, that's not how it works. Especially when far from everyone likes or wants to use Win10 - And I think ESET knows that too.

It doesn't matter if you have problems using latest V9 or upcoming V10 with Win7, as I can't see ESET drop support for Win7 before the extended support period ends in 2020.
http://windows.microsoft.com/en-us/windows/lifecycle

Basically the product should work fine on the Win OS's that the product supports, including Win7.

 

Basically the product should work fine on the Win OS's that the product supports, including Win7.

Wouldn't that be nice?

 

Appears problems on WIN 10 with ver. 9 are in some ways worse than those that have occurred on prior OS versions. The HIPS enabling issue that was well noted in beta testing still appears to exist for some. Also some are having issues getting the firewall to enable.

An interesting comment from Eset in their forum about the issue I posted in reply #31. According to Eset, the feature used and missing was one "few people used" and therefore not tested. It sheds light upon Eset test procedures; or more accurately lack thereof. When you test application software, the vendor is responsible for testing that every feature works as designed. This is not free version software and the retail price is on the high end range of like products. As such, the customer has every right to expect that the product is 100% functional. It might be acceptable that a few minor glitches exist, but not for the scope that has emerged to date.

Finally there is the wasted time and overall hassle of reverting back to security software release because the latest release is deficient.

 

Yes, that's what everyone expects, and would prefer if that was the case for every single user.

@itman

I don't know if it was due to lack of internal testing or something else that is the reason behind that, but I agree with your point of course.

I am not a fan of rapid release schedules in general (not including patches and security improvements of course), and if MS (not sure what the latest from MS is) aims to release new versions of Windows more often, like every year, my feeling is that little (or bigger) quirks and bugs will always be a problem - as when the vendor has fixed all reported problems so it is supposed to work good for everyone - it's time for a new OS and new product version - and so it starts all over again, unless the user decide to stay with the older OS & product version.

 

I'm afraid that you are right about the problems that will appear after each new treshold or major OS update. I guess that instability is something we will have to get used to while using Windows.

 

GUI is fine here with SSL scanning disabled.(Win7)

 

Appears they removed the mandatory use of SSL protocol scanning in the final release. Probably because they couldn't fix its erratic behavior. I only started using it in ver. 8 after I read a few articles on the high incidence of malware on HTTPS web sites. Basically, a "lessor of two evils" decision on my part.

I assume you have no custom HIPS rules if you're using ver. 9?

 

Though I think they should rather make LiveGrid less dependent on protocol scanning. The way I understand it, LiveGrid is strongly connected to protocol scanning. Hence if malware is not checked by protocol scanning, detection by LiveGrid will be severely limited. Other vendors don't make their cloud so dependent on protocol scanning, so ESET should do the same instead of screwing with https.

 

I agree with you. Regular file scanning should use LiveGrid's full potential also.

 

LiveGrid per se is not directly affected by SSL protocol settings. However, exploit protection and memory protection is since that protection exists in Eset's network filter. If SSL protocol scanning is turned off and the exploit exists on a HTTPS web site, it will not be caught since it is encrypted and any subsequent LiveGrid analysis will never be performed.

Exploit Blocker
Exploit Blocker is designed to fortify applications on users’ systems that are often exploited, such as web browsers, PDF readers, email clients or MS Office components. It adds another layer of protection, one step closer to attackers, by using a technology that is completely different to those that focus on detection of malicious files themselves.

Instead, it monitors the behavior of processes and looks out for suspicious activities that are typical for exploits. When triggered, the behavior of the process is analyzed and, if considered suspicious, the threat may be blocked immediately on the machine, with further metadata about the attack sent to our LiveGrid cloud system. This information is further processed and correlated, which enables us to spot previously unknown threats, so-called zero-day attacks, and provides our lab with valuable threat intelligence.