ESS vs Standalone NOD32 v3

Discussion in 'ESET Smart Security' started by sakin, Dec 16, 2008.

Thread Status:
Not open for further replies.
  1. sakin

    sakin Registered Member

    Joined:
    Jan 12, 2008
    Posts:
    19
    There are many threads that explain how ESS is a complex unit that uses all it's modules to create a strong barrier against viruses and such, for example the firewall adds an extra layer to the virus protection through its integration to actively scanning (I assume, or something like scanning) and sharing its information with the girth of the AV-sided parts. (correct me if I'm wrong)

    As many firewall testing sites rate just the firewall without all modules enabled and give ESS firewall scores fairly low compared to other standalone firewalls, however I do realize that this is not how this suite was designed to work, and receives the highest marks when used correctly and not running "half power" with things not enabled. I say this only to transition away from just solely talking about the firewalls standalone abilities but rather the reverse, the firewalls added and necessary use in providing the complete AV protection within ESS and a comparison of whether or not ESS is a more solid and complete protection compared to no32 v3, if not why would ESET provide a suite in which the AV wares in both are of equal levels in protection but with the suite you must enable a insufficient firewall to reach the same level of protection as nod32 v3 (assuming that the ESS and nod32 v3 AV are equal in their stopping strength).

    Switching gears and with what I have said I wanted to know if ESS has a superior AV protection compared to its NOD32 v3 counterpart keeping in mind ESS will use the firewall and antispam modules integrated into the AV side of things instead of just the ordinary or "classic" view of what a firewalls function is (as replied to do so by many admins that ESS NEEDS to have all enabled), to block things simply put. With ESS do we get a more complete protection in it's "use all or none" design or is it a flaw in which NOD32 v3 is free of, as a whole I realize its a great product and works for me and I love it, however I just felt that all the responses to a lot of posts shrug off important questions in this matter and is a interesting one at that and I would like to know.
     
  2. sakin

    sakin Registered Member

    Joined:
    Jan 12, 2008
    Posts:
    19
    I guess it my post is more of a discussion type post more than anything, if you have any insight please join in, or if you have your own opinion. Remember its not about having a substandard firewall but, does the AV need to use the firewall in order to fulfill its role. And if it does, will this provide more protection than NOD32 v3. If it is not needed why even put time and money and energy into creating something that NOD32 v3 already covers.
     
  3. ASpace

    ASpace Guest

    Many questions have you posted but ... NOD32 doesn't cover everything. ESET Smart Security doesn't have superiour AV detection - it uses the same kernel as NOD32 itself .

    The additional functions may be useful to some and may not be . That is why you have the choice .

    What I find useful in ESS and the reason I recommend it over NOD32+Windows Firewall (for e.g.) is :
    1) the fact that the firewall does SPI
    2) the firewall can be run in Policy-based mode (to have precise control of what application goes out/in) - useful in enterprise environment
    3) the firewall settings can't be manipulated like the WF ones in XP with Admin account . ESS v4 is (password-) protected from being stopped/uninstalled/killed . Even v3 is better protected than WF . I find this useful for some clients/situations


    The better protection with its firewall may come for you when the firewall has stopped a downloader or RAT (missed by the AV module) that tries to download mal code .
     
  4. sakin

    sakin Registered Member

    Joined:
    Jan 12, 2008
    Posts:
    19
    Thanks for the reply, I agree with you on the three points you posted but that can (in general) be applied to all firewalls. I understand the need for a firewall, I just wanted to clear up my question of whether or not the additional and required use of the firewall increases the AV detection in ESS.

    I guess my post does sound like the numerous "firewall is insufficient" posts, which is what I wanted to avoid, and direct that type of skepticism to the AV side of things and not the firewall and its performance side.

    (from a mere AV detection rate point of view) Seeing that you said ESS and nod32v3 use the same AV kernel it would be safe to say neither has the advantage there, but saying that they are the same also diminishes the integrated design of the firewall into the AV detection, how could ESS not have better detection by design.
     
  5. pbw3

    pbw3 Registered Member

    Joined:
    Nov 12, 2007
    Posts:
    113
    Location:
    UK
    I may not be following as clearly as I should, but my simplistic understanding is:
    NOD32 is simply an AV (alongside which you are already currently running a separate firewall).
    ESS is an AV plus firewall etc, ie ESS is intended to replace 1) NOD32; and 2) your existing firewall, whatever that firewall is.

    Hence, logically, I am not sure why there would be any reason that ESS should specifically improve NOD32's AV protection. It is simply adding a firewall, not extra AV protection in any way. I am interested to know what you might have learned that has led you to believe that ESS improves the AV detection side compared to NOD32 standalone? I am personally struggling to see how that works but would be keen to understand...

    There is a separate issue, being that of other firewalls needing to be configured with NOD32 to ensure that outbound monitoring is not compromised by the NOD proxy. There are a bucket load of posts elsewhere describing that in detail, but I am not sure that is what you are alluding to here - as that relates to AV plus other (non ESS) firewall being potentially less than the sum of their parts, rather than what you suggesting which is that AV plus ESS firewall being greater than sum of parts and specifically greater in the area of AV protection (rather than other aspects of protection)??

    Peter
     
  6. sakin

    sakin Registered Member

    Joined:
    Jan 12, 2008
    Posts:
    19
    Nothing that I am trying to understand and have asked about, is/has been proven or dis proven, but I am referring to posts and replies within "ESS Firewall is not good"-type threads in which people test the ESS firewall and find they get poor scores, such as these:

    https://www.wilderssecurity.com/showthread.php?t=223274&highlight=firewall
    https://www.wilderssecurity.com/showthread.php?t=226624&highlight=firewall
    https://www.wilderssecurity.com/showthread.php?t=216399&highlight=matousec

    In the first link HiTech_boy suggests that there will be less protection if the OP were to disable the firewall in his ESS. Although that is obvious since he will not have a firewall, it is not the core of my question. What I am trying to get at is why disabling modules for the firewall will bring such vulnerability (if one exists) aside from the fact he will be open to things firewalls provide protection from.

    I am probably misunderstanding his words, as he probably was thinking of the posters safety without a firewall and not thinking what I am thinking. Which is, the firewall needs all modules in order to work (shown in the third link), does the AV work like this too and need the firewall module? If it does than wouldn't you think ESS has an extra level of protection in the AV aspect as there is now a firewall module in the AV detection process? Or the opposite, which would be worse, would the AV detection be hurt if the firewall's module were to shut down and fail to share its information in the AV detection process? Will the AV side of ESS be less efficient because the firewall modules are supposed to work in unison with the AV kernel and now are not? If disabling the firewall module poses no threat to the AV detection as a whole, why would you suggest making a rule to allow all traffic instead of just disabling the firewall's module? And if that last question were to be true that it poses no threat to disable it, why bundle a suite with a poorly performing firewall (in a standalone aspect).

    The second link was just to show that this user has the same sense that I am trying to understand. He says, "my score was only 10/340 running ESET firewall in automatic mode and with ALL the modules enabled." He must have heard the same thing that I have about how the firewall needed to be tested with "ALL modules enabled" because ESS is designed that way. And I'm not using his post to show poor scores, just the fact that he too knew ESS works collectively.

    I hope I am making a little sense because I dont know how to better word my theory. I guess my question could lie in my lack of knowledge of how ESS's AV kernel and firewall modules interact with each other to allow "maximum protection".

    From HiTech_boy's response here saying nod32v3's av kernel is the same as ESS's, makes the replies saying "to ensure full functional protection everything needs to be enabled" and his reply here saying they are the same (as in nod32 users will have the same exact protection on an AV level as those who use ESS) seem contradictory as you don't need all modules to get the same AV detection. Do you need everything enabled, or will we get the same protection regardless of what is or isnt enabled so long as the AV kernel is running?

    Well I could make a bad guess and say that maybe the way the ESS AV kernel and modules interact with one another could be different from how the NOD32v3 AV kernel works, but to the same end and level of protection. That would explain why the firewall in ESS needs to be enabled, because it is a "step" in the process of AV detection in ESS. This would be assuming HiTech_boy's reply here saying the AV kernels are the same also means they provide the same level of detection.
     
    Last edited: Dec 17, 2008
  7. pbw3

    pbw3 Registered Member

    Joined:
    Nov 12, 2007
    Posts:
    113
    Location:
    UK
    The problem of disabling the F/W in ESS should not be one of reducing the effectiveness of the AV, but simply of running without a F/W - which (for me personally) is a far more significant reduction in security than running without AV.

    Re second link, I am not an ESS user, but isn't auto mode on the F/W letting outbound traffic run without interruption - in which case the leak tests will leak (unless the AV separately caught them as malicious code on the way in). Ie interactive or rules mode on the F/W would be needed to reduce the effect of the outbound leak tests?

    Quote - "From HiTech_boy's response here saying nod32v3's av kernel is the same as ESS's, makes the replies saying "to ensure full functional protection everything needs to be enabled" and his reply here saying they are the same (as in nod32 users will have the same exact protection on an AV level as those who use ESS) seem contradictory as you don't need all modules to get the same AV detection."

    Because "Full protection within ESS" also includes firewall protection etc, I am not sure that he means extra AV protection. With NOD V3 instead of ESS, you would be running a separate firewall.

    Again, apologies if I am looking at this simplistically. I just can't see how the ESS firewall (or other features within the suite) separately improves the performance of the AV module - hence the AV module in NOD V3 should be the same as the AV module in the ESS suite - the suite should simply gives additional (non AV) security features.

    If anyone knowledgeable can contradict, would be interested to understand better...

    Peter
     
    Last edited: Dec 17, 2008
  8. Football

    Football Registered Member

    Joined:
    Nov 29, 2008
    Posts:
    96
    Location:
    Greece
    I have also heard that ESS is designed that way and that the firewall should be tested with all the modules enabled. Of course, sakin, in the documentations of ESET, in their forum and in their website, they try to convince us of buying their product. This is very normal and not only ESET but also all other AV vendors do it. It is time for ESET to proove that ESS is designed that way with proofs and not only with words. Over all these years it has prooved that it is an excellent AV (being the antivirus of the year 2006 and 2007). It should also do the same with its firewall.
     
    Last edited: Dec 17, 2008
  9. sakin

    sakin Registered Member

    Joined:
    Jan 12, 2008
    Posts:
    19
    I guess I can see how the av detection would be the exact same due to the suite and nod32 using the same kernel, but I had been trying to think deeper into why Eset decided to integrate firewall and other modules to work collectively instead of running separately from one another, as nod32 (or other suites work) probably works though it does not have a firewall or antispam. Again though, I don't have a deep knowledge and that is the reason for my posting.

    I had pondered if there was a better detection with this design vs the standalone nod32v3 whether it be quicker detection as the firewall might pick up on threats first and inform other modules, but then again the AV kernel is the deepest embedded barrier (most likely) and therefore would dis prove this. This is why I wanted to compare ESS and nod32v3 because they share this similarity and only after HiTech_boys post confirmed they were the same Kernel allowed me to continue on my search for this question on an interesting perspective (atleast in my mind interesting).

    To Football, I see how you may be sharing a common need for a proven firewall with many users, but I did not intent my posts to focus on firewall imperfections but rather I took information from threads that revolved around firewall faults because within them ESET admins post how ESS modules need to be used, and could factor their posts as true knowledge of the product and thus as fact.

    To pbw3, you responded to the second link also in the manner I was not trying to focus on. Although thats true if you allow a leaktest to send its outbound info its basically failing the test, what I was thinking was even though it was leaking outbound traffic it would still have read the info and the AV detection would be triggered through the integrated design on the firewall.
     
  10. pbw3

    pbw3 Registered Member

    Joined:
    Nov 12, 2007
    Posts:
    113
    Location:
    UK
    I completely agree with you... Apols, I was not attempting to focus on any weakness in the F/W.

    If I have understood the "collectively" part properly, Marcos (I think it was) complained that Matousec tested the F/W with the other modules disconnected. I understood him to be arguing that if the AV is capable (through signature or heuristics) of detecting the code within the leaktest executable, then the job is done. The F/W does not need to contain that individual threat with outbound control because the suite "as a whole" is capable of stopping the threat, in this case through AV detection and hence before it even gets a chance to execute and try to "dial out". Hence, by testing the whole suite with all modules enabled, one understands how well the individual parts complement each other, and hence how effective the suite is in total - which is the ultimate test (particularly as the ESS F/W is not intended to be standalone).

    Peter
     
  11. agoretsky

    agoretsky Eset Staff Account

    Joined:
    Apr 4, 2006
    Posts:
    4,033
    Location:
    California
    Hello,

    The various modules (anti-malware, firewall, antispam and so forth) have the ability to communicate with each other within the ESET Smart Security framework, but additional operations rarely get triggered as a result due to a desire to avoid potential performance issues and false positive alarms.

    Regards,

    Aryeh Goretsky
     
Thread Status:
Not open for further replies.
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.