The infamous "ERAC lies about the client's status" bug

Discussion in 'Other ESET Home Products' started by mauricev, Nov 3, 2009.

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

    mauricev Registered Member

    Joined:
    Apr 15, 2008
    Posts:
    43
    The clients window often lies about the state of the clients. The most notorious example occurs when a system hasn't checked in for some reason but ESET psychically knows the system is secure

    bogussystemissecure.jpg

    Most of the time, though not all, ERAC neglects to the list the last known threat on a system. For example, here's a threat in the threat log

    dermithreat.jpg

    but the main client window has no idea

    derminothreat.jpg
     
  2. SmackyTheFrog

    SmackyTheFrog Registered Member

    Joined:
    Nov 5, 2007
    Posts:
    767
    Location:
    Lansing, Michigan
    Uh, that's just the way the product works. Protection status is an alert to the kernel being running but certian components (real time scanner, email, whatever) not functioning correctly or in an inconsistent state. Its not like the console can report the status of the AV engine on a client that is powered down, and a computer being off is hardly an error condition in most all situations. The last threat alert column in the clients tab is only for threats that were unable to be cleaned automatically and likely require manual intervention.
     
  3. mauricev

    mauricev Registered Member

    Joined:
    Apr 15, 2008
    Posts:
    43
    Otherwise known as a bug. Untrue statements count as bugs in my book.:mad:

    Of course it can...
    Code:
    Protection Status is Unknown. Client hasn't checked in xx days
    See, that's not hard. :)

    Except ERAC doesn't know it's off, only that it hasn't checked in and therefore its protection status is unknown.

    Another bug. :( It could then say in the main client window

    Code:
    Last Unresolved Threat Alert
    Rather, it should probably give the last threat, resolved or not.

    but right now, it's says Last Threat Alert and it's blank, which makes it untrue and that makes it a bug. I think I mentioned that.
     
  4. SmackyTheFrog

    SmackyTheFrog Registered Member

    Joined:
    Nov 5, 2007
    Posts:
    767
    Location:
    Lansing, Michigan
    Oh boy.

    Bugs are features that do not function correctly. You can't just walk in to a product without reading the documentation on how it functions and declare everything you disagree with a "bug". That's asinine considering the function of each column and tab is outlined in the help file. Yes, there's room for GUI improvement and ESET does seem receptive to that kind of feedback but lets not go around changing the definition of words to suit our whims.

    As for report the state of the system, what you are proposing to resolve that is basically a "EVERYTHING IS FINE" alarm, which is a terrible idea. Clients voluntarily report in their status to the central server, their is no push-polling of clients except when you run a push deployment because network topologies can cause any number of issues with successfully reaching that client. As such, the console only has system state info as current as the last time the client reported in. Since this is security software, the idea would be to alert you to threats or error conditions that need to be addressed because they cannot be automatically corrected. Since a computer being powered off is a completely valid state, and as of the last system report it was secure, I see absolutely no reason why it should not continue to report as such until a real error condition is encountered. And its not like the last time the client reported its status isn't plastered all over the GUI in multiple locations. If you want something to report to you if a system is up or down and why, there are other tools that are correct for the job like hardware/OS SNMP monitoring.
     
  5. mauricev

    mauricev Registered Member

    Joined:
    Apr 15, 2008
    Posts:
    43
    Lying to the user does not qualify as functioning correctly.

    But it's not doing that. It's saying the system is fine now. The word "is" is present tense. Now I suspect the programmers know English and this bug is simply an oversight. But it's definitely a bug.

    No, I'm proposing they fix the bugs in the report to reflect the truth as best ERAC knows it.

    So they should correct the column title to state, "Last Unresolved Threat". Right now, it's say Last Threat. Those phrases have different meanings. One is true and the other is not.

    Of course, it's telling the truth. No bugs. :)
     
  6. mauricev

    mauricev Registered Member

    Joined:
    Apr 15, 2008
    Posts:
    43
    I found another place where ERAC lies.

    In the main window, the program tells the truth, the last check was, in fact, 20 minutes ago, but the protection status dialog, it has some nonsense referring to 9 days ago.

    boguscheckindate.jpg

    The protection features dialog is even more dishonest

    boguscheckindate2.jpg
     
  7. mauricev

    mauricev Registered Member

    Joined:
    Apr 15, 2008
    Posts:
    43
    This bug is still present in the 4.0.39. :(
     
  8. Marcos

    Marcos Eset Staff Account

    Joined:
    Nov 22, 2002
    Posts:
    14,374
    That's strange, my ERA (3) with ESS 4.2.22 beta connecting to it shows consistent information about the last connection at all places.
     
  9. mauricev

    mauricev Registered Member

    Joined:
    Apr 15, 2008
    Posts:
    43
    ERAC now tells the truth about the client's status

    You are right. I take it back. :oops: The bug was in the client and not the server, and it's been fixed.

    Great work, guys! :cool:
     
  10. mauricev

    mauricev Registered Member

    Joined:
    Apr 15, 2008
    Posts:
    43
    I had to install the client beta on a system that is talking to 3.1.11 of the ERAS/ERAC and it's lying about its status, so this is somewhat puzzling.

    stilllying.jpg

    Protection feature says three days.

    System information is 6 hours ago.
     
  11. techie007

    techie007 Registered Member

    Joined:
    Jan 2, 2008
    Posts:
    125
    Location:
    Ontario, Canada
    Howdy, I just happened across this thread looking for something else, and think I can offer some info on why you find these time stamps to be different.

    You are comparing three DIFFERENT dated events.

    The one showing in the "Last Connected" column of the RAC is the last time the client contacted the RA server to check in (not get updates, just check in with status).

    The number in the "Protection Status" tab is the date of the last time the protection status changed. Usually it's the last time the client computer was booted. OR the last time it changed from 'secure' to something else or from something else to 'secure'.

    The number in the "Protection Features" tab appears to be the last time the status of any of the protection features changed.

    Since they are time stamps on three different events, the stamps will be different.

    Hope that helps.
     
  12. mauricev

    mauricev Registered Member

    Joined:
    Apr 15, 2008
    Posts:
    43
    Thanks for your reply. You are incorrect, but you are still making a good point.

    I have no idea what it would mean the Protection Features to be dated. Once the software is installed, the features don't ever change.

    While the protection status can change, it never should. It would mean the system was somehow left unprotected, but unless NOD32 had gotten turned off, how can that occur?

    It would probably be better for ESET to remove the dates for these entities and avoid the confusion, especially since the dates given just appear to be random, anyway.
     
  13. techie007

    techie007 Registered Member

    Joined:
    Jan 2, 2008
    Posts:
    125
    Location:
    Ontario, Canada
    I'm not sure why you think I'm "incorrect"? Not that I'm an Eset expert, so if I'm wrong, perhaps you can explain how, so we can all learn?

    This is what I understand to be correct:

    The "protection features" can be changed via the advanced setup tree. If you go in there and un-check (for example) "Email client protection", then the next time it reports into the RAS the RAC shows "Email protection is currently disabled" and if you then look at the Properties-->Protection Features, the time stamp is changed to the time that is Email client protection was disabled at the client. When you re-enable it, and it checks in again, and the date will be updated again. So they can be changed after the software is installed and the time stamping is to help you track down when it happened.

    The "protection status" does change as well, during boot the system turns NOD32 (back) on, so the system becomes 'secure' again at boot, causing the "Protection Status" time stamp to update. It also gets changed when someone right-clicks the client icon and disables or enables the real-time protection.

    Again, these time stamps are good from an administration point of view when trying to determine why one of these statuses changed when, as you say, they probably shouldn't (depending on policies or configuration).
     
  14. mauricev

    mauricev Registered Member

    Joined:
    Apr 15, 2008
    Posts:
    43
    I admit you have found some explanation for the crazy dates ESET reports, but I don't agree they're telling us what the program is purporting them to and, in fact, you're bolstering my original assertion that ESET is lying to us.

    First, protection status is really reporting when the client has booted and not it's actual security status. Sure, while the system had been off, it could have surreptitiously been exposed to a virus by somehow being attached to a working, infected system. But that's an unlikely scenario to warrant making it a basis for updating this date.

    I further interpret that date as wrong because it's a date in the past and yet below it says it "System is secure." I don't know a contradiction that could be plainer than that.

    Second, on the protection features, it's really telling us when ESET has been installed. I have clients locked down, so how could it otherwise display anything? I do see a few where it tells me some other date, but I have no idea what it means. What changed and how did it change? And for how long had it been changed? And most importantly, what's there was any consequence of its being changed? Trying to interpret the few dates that don't reflect the installation time would drive me crazy and for the vast majority where all it tells me is the installation date, why do I care?

    I have submitted a request, 478713, to have these dates removed and to fix the lie about the system being secure when it's true status is indeterminate. I really hope ESET fixes this. :mad:
     
  15. techie007

    techie007 Registered Member

    Joined:
    Jan 2, 2008
    Posts:
    125
    Location:
    Ontario, Canada
    The dates are telling you the last time the status changed, not the last time the status was checked (to get that, you'd look at the timestamp of when the client last checked in).

    Maybe they should add that to the timestamp title (ie: "status last changed on: ") so you don't feel you're being 'lied to', but you're not really being lied to since it doesn't claim to be anything else.

    Is it goofy that the date is updated because the security was re-enabled after boot? Perhaps. :)

    Also keep in mind, that just because you lock down your users' abilities to change these settings doesn't mean everyone does. :) And are you SURE the few that don't report the install date have never had their features temporarily altered? I know mine update when I temporarily disable the features on the client(s), and then again when I re-enable them.

    Have you tried testing a client to see how the dates respond to changes? It might make it clearer to you.

    Personally I DON'T want these dates to be removed, as I'd like to know when these statuses changed. We also don't depend on manually looking at these dates to figure out if things are working, instead we use the RAS reporting (notification) and our network monitoring software for that. :)

    So again, the dates reflect what I've described (as far as I can tell, based on testing I've done), but not what you expect. For the most part it seems you're labeling things you don't understand, or that don't work how you'd like, as 'bugs', and expecting a fix for something that isn't broken (although, they could probably use some clarification).

    Perhaps you can lay out for us, point by point, what you'd like to see corrected? Because this thread is pretty muddied now, and a lot of what's left seem to just be cosmetic labeling that you're having trouble understanding, more so than functional bugs. :)
     
  16. mauricev

    mauricev Registered Member

    Joined:
    Apr 15, 2008
    Posts:
    43
    It's not claiming anything at all. So while it's not strictly lying; it isn't telling the whole story either. Protection status also changes when the system reboot which isn't quite accurate. However, when it says the "System is secure" and the system hasn't checked in in a while, then it is lying. How is it going to know the status of a system that hasn't checked in? Present tense means now. This is a functional bug.

    But these dates don't tell you that unless you're monitoring them 24/7 for every change. They only tell you when the status last changed and for the protection status, that date will usually reflect when the system had been rebooted, which really isn't a change in protection status.

    If I were designing ERAC, first, I wouldn't lie. When a system doesn't check in, all status dates should all change to "indeterminate."

    Now if I were displaying a protection status date, I would 1) indicate the status date and the word "since" but 2) not change it just because the system rebooted. For the protection features, it could simply indicate the status date "since." And again, these date all change to indeterminate when a system goes offline.
     
Thread Status:
Not open for further replies.