eshrugged
-
Posts
27 -
Joined
-
Last visited
Posts posted by eshrugged
-
-
I ask because the Anti-Phishing descriptor on ESET's Technology page (hxxp://www.eset.com/us/home/whyeset/technology/) doesn't include Nod32 in 'Related products'. I hadn't noticed that before.
Yes it should be listed. Your link goes to the .com/us/... tech site.
For the sake of it I checked the .com/int/...tech site (link in my signature) and NOD32 is not listed under Anti-Phi there either.
hxxp://www.eset.com/int/about/technology/
Thanks for further verifying, SweX. Don't know if its omission is intentional because there's a difference in the modules or if it's marketing.
Also this statement on both sites is surely not correct:
The Anti-phishing database is updated by ESET regularly (users’ computers receive data about new phishing threats every 20 minutes)
AFAIK this isn't possible, because the VSD, which includes these detections, is updated every 60 minutes by default.
Good catch, rugk. I'm not positive that the Anti-Phishing updates are pushed in the VSD updates. Is the 20 minute claim marketing?
I'd like to hear definitive answers from ESET.
-
It was probably an omission on the Technology page as both Nod and ESS are discussed in the same KB article. ( hxxp://kb.eset.com/esetkb/index?page=content&id=SOLN3100&actp=search&viewlocale=en_US&searchid=1428355242332).
But, can't hurt to make sure there's no difference.
-
Is there a difference with Anti-Phishing in Nod32 and ESS?
I ask because the Anti-Phishing descriptor on ESET's Technology page (hxxp://www.eset.com/us/home/whyeset/technology/) doesn't include Nod32 in 'Related products'. I hadn't noticed that before.
Anti-Phishing is, of course, listed on Nod32's product page (hxxp://www.eset.com/us/home/products/antivirus/).
-
@Scott--
From Stephen Sinofsky, MSDN, W7 engineering blog post dedicated to defrag :
...In Windows XP, any file that is split into more than one piece is considered fragmented. Not so in Windows Vista if the fragments are large enough – the defragmentation algorithm was changed (from Windows XP) to ignore pieces of a file that are larger than 64MB. As a result, defrag in XP and defrag in Vista will report different amounts of fragmentation on a volume. So, which one is correct? Well, before the question can be answered we must understand why defrag in Vista was changed. In Vista, we analyzed the impact of defragmentation and determined that the most significant performance gains from defrag are when pieces of files are combined into sufficiently large chunks such that the impact of disk-seek latency is not significant relative to the latency associated with sequentially reading the file. This means that there is a point after which combining fragmented pieces of files has no discernible benefit. In fact, there are actually negative consequences of doing so. For example, for defrag to combine fragments that are 64MB or larger requires significant amounts of disk I/O, which is against the principle of minimizing I/O that we discussed earlier (since it decreases total available disk bandwidth for user initiated I/O), and puts more pressure on the system to find large, contiguous blocks of free space. Here is a scenario where a certainly amount of fragmentation of data is just fine – doing nothing to decrease this fragmentation turns out to be the right answer!.....
Sinofsky's entire post is worth reading.
-
I can only speak to Nod32 with any certainty.
W7sp1x64, Nod32 8.0.304.0
Box #1 drivers -- eamonm; edevmon; ehdrv; epfwwfpr
Box #2 has the same plus in the directory @system32 is epfwlwf. This was left over from a past ESS installation. [box #1, it was removed as explained in post#4.]
What was temporarily confusing to me was that each driver is listed in their individual properties window as >> Details -- Product name - ESET Smart Security. I thought that all/some drivers were leftover from the previous ESS install/uninstall. That's not the case. I don't know how the name is generated for that field in properties but it tricked my simple self.
-
Thank you for answering my nonexistent posts. :-)
I removed them because after I posted I realized they were mistaken or incomplete. I was mostly confused because of the dates associated with particular drivers and because after checking their -- Properties >> Details -- they were/are listed as belonging to -- Product name : ESET Smart Security.
I formerly had ESS installed so I thought they were left over from when I had removed it. Since then I've looked into the Nod32 inf files and realize all are part of the Nod32 install except for, AFAIK, EpfwLWF.
On one machine I uninstalled (safe mode + Eset removal tool) and reinstalled Nod32. I no longer see EpfwLWF in the directory. I haven't done the other machine as I'm considering reinstalling ESS.
Anyway, thank you for replying rugk. Maybe I should have left my original posts as they were. Please let me know if removing them was a breach of etiquette. If it was, I apologize to the community.
-
Then maybe this should be changed so that ESET also scans this files in realtime-protection. And additionally also files from external devices should be checked against ESET LiveGrid.
No, we will not make anything that could potentially cause serious troubles to our users or have noticeable impact on system performance. Our aim is to provide state-of-the-art protection to our users that they can depend on and we will never go in the wrong direction. I'm saying this because I see things behind the scene although I realize that for users things may look differrently and thus they may come up with easy ideas that are not safe to implement, however.
QA tests before updates are extremely important and there's no way to skip them without jeopardizing our users' computers and systems. We will always strive for keeping false positives away which was proven both by tests and users' experience.
Post#12 here : https://forum.eset.com/topic/3100-small-question-eset-livegrid-file-reputation/?hl=%2Bsystem+%2Bfiles+%2Bfalse+%2Bpositive#entry18031
That entire thread is a good read in regards to LiveGrid/file-reputation along with Marcos touching upon the false positive issue a few times.
I've been nervous about system eating FPs in any signature based product for quite awhile. While that will never go away, I think ESET's current, strong commitment to avoiding them is genuine. It's a necessary intellectual/financial expense.
Keep up the good work everyone.
-
removed by op
-
removed by op
-
I did some testing on this. I used an eicar file saved in a text doc. I used the default parameters as set by installation for custom scan. I didn't change the Profile Setup options.
From Nod32 console :
1) Computer Scan >> Custom Scan >> chose Computer >> clicked Scan at bottom of window >> chose Open scan in a new window... log files show and scroll
2) Did the same as above EXCEPT >> clicked Scan as Administrator >> chose Open scan in a new window.... log files do not show, same as Silklandscape.
In both cases (multiple tries) after the scan, the complete log was available at Console >> Computer scan >> Scan logs.
ETA: Nod32 8.0.304.0, W7 HP SP1 x64
-
I'm not going to advise you on your specifics. Wait for someone more qualified. I'm just another user.
Just wanted to point out -- your screenshot indicates that you're also running MSE. If that's so, prepare yourself before real help arrives by reading this -- hxxp://kb.eset.com/esetkb/index?page=content&id=SOLN146&actp=s
Two real-time AVs running concurrently is a no-no. This might not be causing the behavior you're describing but it does need attention. Someone will advise as to the best course of action for you.
Good luck.
-
I did some brief testing of real-time protection with cleaning set to -- No cleaning.
It's important to note that I used the eicar test tool. It's easily contained. A self-replicating malware, on the other hand, is not. So, to be clear, I'm not advocating for or encouraging anyone to set their cleaning parameter to -- No cleaning. I tested it because there might be circumstantial usefulness to me. The default -- Standard cleaning -- imo, is the best option for most, to all, including myself.
Machine is W7 SP1 x64 (I use process explorer instead of task manager and it's set to always be on top).
First test was opening the eicar file in notepad. I left the Nod32 alert up for about 30 minutes. Brief notes:
1) Alert window stays on top of all windows, including windows opened post alert, except for process explorer. Alert window can be moved but you cannot copy and paste its contents. At the end of and during the 30 minutes I had no problems with my PC and at conclusion Nod32 allowed me to choose to clean or take no action.
2) I could open other programs, including browsers, from the desktop, taskbar, start menu , etc, during the alert.
3) Nod32 auto-updated (scheduled) mid-test.
The second test had an eicar file directly on the desktop. I left Nod32's alert in place for about 20 minutes. Brief notes:
1) Same as note #1 above except test length.
2) I could not open any desktop programs (or use their context menus). I could open programs, including browsers, in the taskbar and in the start menu.
1rst test --
2nd test --
Thanks to everyone who added to this thread.
Regards.
-
By default, dialogs requiring user intervention are closed after 120 seconds and I left the alert window open much longer. That confirms my assumption that alerts are an exception to the setting.
Thanks Marcos. In the near future I'll try contacting ESET to see if they've tested and have publically available results for my scenario. I'll report back. I don't have a test environment set up.
I wrote that I had tested it. So asking someone else to conduct the very same test is redundant. No special test environment is needed, just use the eicar test file to trigger an alert.
It wouldn't be redundant.
A scenario for my original question :
I'm the admin. Cleaning is set to -- No cleaning. I'm away for X hours. A household member who's less capable than I of making an informed decision for an alert will call me. My answer to him/her could take many minutes.
I know I can test with eicar or otherwise (and might end up doing so) but I wanted to avoid potentially doing an unnecessary, hard shut down.
-
By default, dialogs requiring user intervention are closed after 120 seconds and I left the alert window open much longer. That confirms my assumption that alerts are an exception to the setting.
Thanks Marcos. In the near future I'll try contacting ESET to see if they've tested and have publically available results for my scenario. I'll report back. I don't have a test environment set up.
-
Hi rugk.
rugk, on 01 Mar 2015 - 11:43 AM, said :
Surely 3 days...
hehee
Thank you for the info regarding the forum. It's good to know. I understand getting an answer for my initial question (and follow ups) could take some time. I appreciate Marcos' earlier 'take the bull by the horns' testing. Until I find out a more definitive answer, I'll be satisfied with using the default parameter.
My choice would be :
Upon detection, if I'd previously moved the parameter slider to -- No cleaning -- I prefer that Nod32 notify, then do nothing unless and until I choose which action to take.
-
Hi Marcos.
Thank you very much for taking the time to test this on your own. How long did your test run?
I thought ESET would have data available from their own development tests. Is this forum the proper place to ask for that type of data? If not here, do you know where I should ask?
-
Hi.
My question concerns each Nod 32 scanner.
If I have the cleaning parameter set to -- No cleaning -- Nod 32's behavior as described in the GUI help file is :
No cleaning – Infected files will not be cleaned automatically. The program will display a warning window and allow the user to choose an action. This level is designed for more advanced users who know which steps to take in the event of an infiltration.In the past I've used security products that had this option for no auto-clean. They did have a catch, however. Upon infiltration you'd be presented with action options but if you didn't respond to the prompt within X seconds the programs would either take the matter out of your hands and choose its own coded action or if the security program process was called by the OS shell, Windows Explorer, the computer would become unresponsive and you'd be forced to do a hard shutdown.
How long will Nod 32's, infiltration prompt for action wait for user action? Minutes, hours, infinity?
-
Hello and thank you, TomFace.
-
CB530,
It does help. Thank you.
-
My current license of ESS/Nod 32 was a box purchase.
Questions about ordering from the ESET store :
1) From what I've gathered, if I wish to change the number of users for the license I could accomplish this by contacting ESET through the GUI, ESET contact link. Correct?
2) Since my license is from a boxed version, would the ESET store, renewal discount be applicable?
3) What form of payment does the ESET store accept?
4) Where are the transaction records held?
5) Is the transaction set up as a recurring one?
-
I hope they do NOT dumb down the program like Kaspersky did theirs.
I buy ESET because of its configurability.
DrT
I haven't looked at that program in some time but as a generality I agree with the --- 'don't dumb things down'.
As it stands, ESET's GUI has a nice balance with an ease of use 'front face', default configuration for the less able or willing in the household and a password protected (if enabled), advanced section for the admin type. And for everyone -- accessible, readable, useful help files. Whatever they're paying the writer(s) has been well spent. I hope that never changes.
-
Thank you for the feedback SweX.
1. I hope the new GUI and program retain the current's simplicity/ non-busyness. I much prefer it that way. But the current font size is barely readable for me. (It was the same for me in ESS.)
2. Will do, thanks for the link.
-
Please increase the GUI font size or make it possible for the user to manipulate it.
Please make it possible for the user to update via the sys tray icon menu.
-
Thank you, SweX for chiming in, and, Marcos for confirming.
Have a good W/E.
Anti-Phishing in Nod32 vs ESS
in ESET NOD32 Antivirus
Posted
Thank you, foneil.