Quarantine in AMON

How do I enable quarantine as a choice for AMON when it catches a virus? I want to enable this in the configuration of AMON and I don't think it is possible. Why not?

When I click on "HELP" in AMON, and then index/quarantine, I am sent to AMON "Setup/actions" which says absolutely nothing about quarantine. It tells me to go to the "Security" tab. There I find a discussion about the other actions that are offered when AMON catches a virus, but again nothing is said about quarantine. Why?

Just now, AMON caught a trojan that I knew was in a file I downloaded and was testing to see if adv. heuristics would catch it... not a peep...very disappointing as McAfee and KAV caught it before it was unzipped but NOD doesn't. AMON catches it after unzipping, but doesn't have a name for it and it is not a new trojan.

Anyhow, when AMON caught it, I saw the option to quarantine on the screen but, of course, the option was not checked because there is no way, as far as I can see, to check it when configuring AMON. I should be able to check quarantine in the configuration of AMON. I want AMON to automatically quarantine and not ask me what to do. It should quarantine automatically, if I have the quarantine box checked in configuration. Then I should be able to go to quarantine and decide what I want to do there or I should be able to just leave it in quarantine and take no further action. But then quarantine is not a real quarantine when it comes to NOD...oh no... NOD doesn't ever quarantine anything. It merely copies the file and leaves the original where it was! I don't want to deal with it when AMON catches it. I want AMON to send the file to quarantine. Poof! It disappears from where ever it was and then I can choose then or later to deal with it in quarantine. Or I choose to leave it forever in quarantine and never deal with it. THIS is how it should work.

Quarantine really needs a lot of fixing. .Quarantine is one of the most important functions of an av and NOD handles it so poorly and in a very misleading, and thus potentially highly dangerous, manner.

 

Hello,
-AMON don't use advanced heuristic.
-There aren't need to detect compressed viruses before you try to decompress the viruses, because before decompressed some thing, this action isn't dangerous.
-When AMON detect some thing, you can select Quarantine, later some option like Delete and the file will be quarantined.

 

I know that AMON doesn't use adv. heuristics. I was scanning the downloaded file using Paolo's adv. heuristics via command line scanning. NOD should have detected then. I should not have to go to all the trouble of unzipping so that AMON can detect. Bah humbug! Other av would have detected on initial scan. I ALWAYS scan any file downloaded first via adv. heurisitics command line scanning. What point is there to command line scanning if zipped files can't be examined this way?

I also realize that the files are not dangeous until decompressed. But why have to go to all that trouble just to find that the file is infected? The infection should be found earlier before decompression so as to save the user the time and effort in decompressing files that can't be utilized because they are infected. I used not to feel this way but I do now. I used to think the way you do.

I already know that I can select quarantine AFTER AMON detects it. I don't want to do that. I should be able to select quarantine when setting up AMON so that all infected files will automatically be sent to quarantine and no infected file will be left in place which is what is currently the case with AMON.

 

As you know, that's always been a sort of bone of contention between various folks regarding when and how an AV should detect malware, when it's idle and "safe" or when it's decompressed and/or attempts to execute. I'm suspecting in AV land as things get more interesting the consensus among mass consumers likely eventually will go in favor of the earliest detection and disposition, rather than waiting until something is decompressed and/or run. (Which, if I understand correctly, could be dangerous with run-time packers.)

In the meantime, I've got AMON freaking out over Steve Gibson's DCOMbobulator utility when I simply mouse over the freakin' shortcut icon. Go figure.

As for quarantine, I think as we earlier discussed most people think that means the badguy is removed and put in a harmless holding pen for further disposition, not just copied to a so called "quarantine" folder. That could really trip up a casual user used to NAV for example who has not scrutinized the NOD help file to learn that ESET means and does something quite different when it puts a file in quarantine.

 

Is that not simply a matter of the settings for the relevant scanning profile?
I have runtime packers and archives selected under "Objects to Diagnose" in the Setup tab for NOD32, under the Profile for scanning objects from within the context menu. When I right select a zip file or a folder containing a zip file using either Paolo's advanced heuristics or the standard scan, NOD scans inside the zip files.

 

Yes, you are entirely correct. What happened is that a bug in NOD32 for XP SP1, has been causing my profile for adv. heuristics command line scanning to change without my changing it. I also get a box after using the command line scanner that asks me if I want to save the changes made to my profile. Well, I haven't made any! All I have done is scan a file. So, I have said "no" as I don't want to save changes I haven't made. However, changes have been made due to the bug and those changes revert my choices in scanning back to default! Default does not include scanning runtime packers or archives. This bug also reverts my choice for heuristics from "deep" back to the default of "standard". It also unchecks the box I have checked to "scan all file types".

This has happened at least four times in the two weeks I have had NOD32 installed on this new XP box. This has been very confusing to me as this bug doesn't exist on my W98 box that also had NOD32. So, when I scanned that zipped file with the virus using adv. heuristics, NOD32 did not alert because unknown to me this bug had again reverted my choices for scanning back to default!

Marcos just instructed me to download the 2.000.9 version from the website and he says that will fix my problem.

 

Mele20,

I have never been able to duplicate your problem with Quarantine, and I have tested fairly thoroughly:

http://www.wilderssecurity.com/showthread.php?t=20783

I just re-tested and I get the same results, taking the following into consideration:

1. If we all agree that AMON cannot scan inside archives (disregarding whether this is a good or bad philosophy), QUARANTINE functions as expected.

2. Since ESET regards QUARANTINE as a "sub-Action" (my term) in that it cannot be selected unless some other Action is selected first (i.e., DELETE, RENAME, etc.), QUARANTINE functions as expected.

Results:

Upon extraction from archive, AMON reacts, prompts for Action (as set by me to be prompted), DELETES the EXTRACTED infected file and QUARANTINES the file. The infected file inside the archive is left untouched, obviously, because AMON never even sees that file inside the archive.

When detecting a non-archive file, AMON DELETES the file and QUARANTINES it. No file is left on my PC except for specially formatted QUARANTINE file.

I saw no behavior in which AMON simply copies the file to QUARANTINE, unless you are referring to the infected file in the archive as the "original" and the QUARANTINE"d file as the "copy". We have already agreed that, rightly or wrongly, AMON doesn't scan inside archives, and as such this behavior is entirely consistent with that.

Restoring the file from QUARANTINE even works.

I did note one minor quirk with QUARANTINE in the above referenced thread regarding time stamps, but it does not impact functionality.

 

By the way, IMON is the only module that can actually manipulate infected files within archives (at least up to version 2.000.8...haven't tried 2.000.9).

- AMON can't scan inside archives nor manipulate files inside them (they must be extracted first)
- NOD32 (on-demand) can scan inside archives but can do nothing to the infected files inside archives once found (they must be extracted first)

Considering the quirky things that IMON does to archives when manipulating files within the archive (including trashing the archive and any non-infected file(s) therein), it's probably a good thing that ESET has held off on adding this "feature" to their other modules. Until they can come up with an implementation that doesn't destroy the archive, they should just leave things as they are (and this is probably why they left things as they are as opposed to it being a "philosophy"). Why they can't figure out how to manipulate infected files inside archives without doing further collateral damage to the archive and other uninfected files is a good question, though.

See my thread:

http://www.wilderssecurity.com/showthread.php?t=20783

to read about other strange behavior of IMON when manipulating archives. The thread is long, but laid out in such a way (hopefully) that you can navigate to the parts you are interested in fairly easily.

P.S.

Mele20,

I believe you consistantly state that you don't use IMON, but this information is perhaps useful in understanding ESET's lack of archive ACTION support in AMON and NOD32...they simply don't implement it very well when they do attempt to implement it, apparently.

 

Hi NEwNOD,

Yes, I do not use IMON. I will read that thread you mention later when I have some time. One thing I am curious about now that I got version 2.000.9 of NOD32 is why the IMON module still shows version 2.000.8 while NOD32 and AMON show version 2.000.9.

Even without reading that thread yet, I see your point that Eset, for some reason, has problems with getting AMON or NOD32 to properly work inside an archive. I am not surprised that IMON does odd things either. Generally though, I want the infected file or entire archive which holds an infected file, moved to quarantine and then I will go to quarantine and deal with it there or just leave it there forever.

You said:
>2. Since ESET regards QUARANTINE as a "sub-Action" (my term) in that it cannot be selected unless some other Action is selected first (i.e., DELETE, RENAME, etc.), QUARANTINE functions as expected.

This is not true. Quarantine is NOT a "sub-action". It CAN be selected without selecting another action first. On my box it doesn't matter if AMON is reacting to an archived file which I have just unzipped or not, it always leaves the file intact and simply copies the file to quarantine. No other av does this that I know of. When AMON alerts and gives me a choice of actions, I choose to check the box "quarantine" then I close AMON. Now AMON should move the infected file to quarantine, but it doesn't. I told AMON to move it. Instead, AMON copies the infected file and puts the copy in quarantine and leaves the original, still infected file. If I then, upon seeing that the infected file is still sitting there, right click and choose "delete" AMON alerts again and I get an error message that the file cannot be deleted. If the infected file is inside a folder where there are other non infected files, I can right click the folder and delete. However, in this case, I wouldn't do this because I think the file was moved to quarantine. It is only upon opening the folder that I see the infected file is still there! So, I right click on it to delete it and AMON alerts again and I choose quarantine and the file is again copied and the copy is placed in quarantine. The original file still sits there infected! To confuse me further as to exactly what AMON has done and not done, when I go to quarantine, I see the file there. If I highlight it and right click on it, it says restore, delete, etc. I see the word "restore" and that says to me that AMON moved the original file to quarantine and if I want to restore it now, I can do so. Why do I have the choice to restore a file that AMON has left in its original location? Why would I restore something that hasn't been lost or deleted? I wouldn't.

Yes, I could choose "delete" in the AMON alert box, but I don't want to delete it! I want it MOVED to quarantine. I don't want some special copy made and put in quarantine. I want the original file moved there. It is illogical to delete the original, but then go to the trouble to make a copy and put the copy instead of the original in quarantine. The logical thing is to move the original file to quarantine. That is what I choose when I choose quarantine on the AMON alert box. Why would I also choose delete? It is being moved to quarantine and that "deletes" it from anywhere on my computer except in the special quarantined area. This is how it works with other av's. To also choose delete is to choose a redundant action that cannot occur....except with NOD32.

Any one coming to NOD32 from most any other AV would assume that when the action "quarantine" is chosen that is what happens. Now, most other av automatically quarantine (and I believe that NOD should also do this automatically) and none, that I have used, consider quarantine to mean "copy" and also leave the original file intact in its original location on the computer. That is not what the word quarantine means. Eset chooses something and then makes it totally different from what others have more or less agreed that something means. Now, this is not necessarily bad if the user is clearly informed about these weird quirks of NOD32. However, I haven't seen anything that tells a new user that quarantine to Eset does not mean what it means to most of the rest of the av world or to most users. This is potentially dangerous.

 

Mele20,

Yes, I see several of your points regarding QUARANTINE (I won't quote all of them again).

However, I still say that ESET considers QUARANTINE a "sub-action". This is borne out by the design of the interfaces by which one interacts with QUARANTINE and further "proven" by the odd nature of what occurs when you select the QUARANTINE checkbox and then simply close the ALERT. The issue is that the implementation was not refined to the point of disallowing selection of QUARANTINE without the "main" ACTION or disallowing closing of the ALERT box without warning that the original infected file will be left in place.

The "proof" provided by the design of the GUI, as I see it, is this:

- On the ACTIONS tab under NOD32 (on-demand scanner), a heirarchy of ACTIONS is set up for different combinations of "OBJECTS" and "ACTIONS". Each of the main ACTIONS is selected with a bullet. QUARANTINE can be selected (or not selected) in addition to the various ACTIONS via a checkbox (as opposed to a bullet). I chose to include NOD32's options GUI in my argument about the philosophy behind QUARANTINE because the set-up illustrates the subordinate position of QUARANTINE to the other ACTIONS. And while AMON doesn't have this same detailed ACTIONS tab:

-The ALERT for AMON (and IMON and NOD32) supports the above in that the bulleted selections appear as BUTTONS while QUARANTINE appears as a "minor" checkbox. Logically for me, this means, "Select a BUTTON ACTION with QUARANTINE" or "Select a BUTTON ACTION without QUARANTINE", but it does not make me think to "Select QUARANTINE by iteslf and then close the ALERT". If the latter was intended, QUARANTINE would be a BUTTON like the other ACTIONS. The layout of the ALERT GUI along with how NOD32 preferences are set logically leads me to conclude that ESET was shooting for the flexibility of allowing a "main-action" alone [via Button] or in combination with the "sub-action" [checkbox]. I guess I can see how some might be confused, but my only complaint would be that selection of QUARANTINE alone is not precluded and / or that no warning is given, e.g. "Selecting QUARANTINE without selecting an ACTION (DELETE, RENAME, etc.) will copy the file to QUARANTINE but will leave the original file in place. Continue / Cancel".

Moving QUARANTINE up in the ACTION heirarchy to the same level as DELETE, RENAME, etc. (i.e. giving QUARANTINE it's own BUTTON) would limit the options available to the user (essentially relegating QUARANTINE to a forced combination of "DELETE-then-QUARANTINE"). Whether that is important or not is a matter of preference. I always prefer more options than fewer.

As far as QUARANTINE converting the infected file that it retains into a special format, I like that idea. It prevents AV scanners from giving alerts when scanning the QUARANTINE folder and prevents accidental mishandling of the "live" infection. Since the restore function of QUARANTINE seems to work, I have no problem with it storing the special format as one can always "restore" the file so it can be used for testing, etc.

To conclude, I am not so much defending the implemenation so much as I am defending my contention that ESET intended QUARANTINE to work in conjunction with another ACTION as opposed to having it be a stand-alone ACTION.

The implemenation is not the cleanest, as is true for a lot of things we have all discussed here about NOD32, but I can't say QUARANTINE is so far off in functionality that it can't be made less confusing by adding a message box explaining what it's about to do. Or as you seem to prefer, completely change the functionality so that it has it's own BUTTON (thereby limiting the possible combinations of ACTION plus "sub-ACTION").