Jump to content

Archived

This topic is now archived and is closed to further replies.

razorfancy

Eset Internet Security v11.0.159.9 update to v11.1.42

Recommended Posts

5 hours ago, Marcos said:

If you would like to install EIS 11.1.51 release candidate, you can download it from:
ESET Internet Security 32-bit
ESET Internet Security 64-bit

This version has passed QA testing and will be released very soon, probably as version 11.1.52. It addresses all known issues reported with v11.1.42.

@Marcos

Thanks for letting us know. v11.1.51 just works fine on my Windows 10 PC except of AMTSOs 'CloudCar Testfile' is not detected for some reasons. So far my Eset IS installation is on default settings.

Share this post


Link to post
Share on other sites
13 minutes ago, senna said:

@Marcos

Thanks for letting us know. v11.1.51 just works fine on my Windows 10 PC except of AMTSOs 'CloudCar Testfile' is not detected for some reasons. So far my Eset IS installation is on default settings.

It's it detected upon download ?

Share this post


Link to post
Share on other sites

@Marcos

No it's not. I can download it (8kb file) and can perform a manual scan but it's not detected as malicious

Share this post


Link to post
Share on other sites
5 hours ago, Marcos said:

If you would like to install EIS 11.1.51 release candidate, you can download it from:
ESET Internet Security 32-bit
ESET Internet Security 64-bit

This version has passed QA testing and will be released very soon, probably as version 11.1.52. It addresses all known issues reported with v11.1.42.

As far as the QA testing goes, appears the folks missed this one.

Now at boot and shutdown time, I am receiving the Windows Update messages not to turn off the PC while updating is occurring or that Windows updates are being applied.

Granted the displays are of short duration but this shouldn't be happening. Also if this behavior was intentional and to eliminate the registry key access denied event log issue, it is not working since that event log error is still appearing.

Share this post


Link to post
Share on other sites
40 minutes ago, senna said:

Thanks for letting us know. v11.1.51 just works fine on my Windows 10 PC except of AMTSOs 'CloudCar Testfile' is not detected for some reasons. So far my Eset IS installation is on default settings.

It worked fine for me and I visually verified that an upload/download was made to Eset tsmxx servers.

Now the behavior is the same as that for previous versions. Eset will alert and block. But in IE11 for example, you have to cancel or delete the IE11 download popup window. If you click "Save" from that window, the cloudcar test file will still download.

Share this post


Link to post
Share on other sites
15 minutes ago, itman said:

It worked fine for me and I visually verified that an upload/download was made to Eset tsmxx servers.

Now the behavior is the same as that for previous versions. Eset will alert and block. But in IE11 for example, you have to cancel or delete the IE11 download popup window. If you click "Save" from that window, the cloudcar test file will still download.

Yep. Using Microsoft Edge the tesfile is blocked. Using Firefox (v.59.0.2) it's still not working.

Share this post


Link to post
Share on other sites

@Marcos, another potential issue I noticed in regards to ver. 11.1.41.

Upon installation, I noticed it created network adapter connections for 6to4 and ISATAP. I have those IPv6 tunnels disabled by design on all IPv6 interfaces via DisabledComponents registry key setting. I need to know ASAP if Eset is sending LiveGrid updates using those tunnels. I don't know why it would be if IPv6 was set on for the network adapter and the ISP fully supported IPv6 as mine does.

Share this post


Link to post
Share on other sites
13 hours ago, itman said:

Now at boot and shutdown time, I am receiving the Windows Update messages not to turn off the PC while updating is occurring or that Windows updates are being applied.

This is highly unlikely related to ESET. We are pretty much sure that uninstalling ESET would have no effect on this.

Quote

Also if this behavior was intentional and to eliminate the registry key access denied event log issue, it is not working since that event log error is still appearing.

I have informed in the appropriate topic that the event will be eliminated as of the HIPS module 1316. It's not meant to be fixed in the product itself.

Share this post


Link to post
Share on other sites
13 hours ago, itman said:

Upon installation, I noticed it created network adapter connections for 6to4 and ISATAP.

We use whichever protocol is available. If IPv6 is not available, we communicate over IPv4. Nothing has changed in this regard for ages I would say.

Share this post


Link to post
Share on other sites
5 hours ago, Marcos said:

This is highly unlikely related to ESET. We are pretty much sure that uninstalling ESET would have no effect on this.

The issue mysteriously went away. I didn't see any new Win Updates installed as a result of the activity, so don't know what prompted it.

 

5 hours ago, Marcos said:

We use whichever protocol is available. If IPv6 is not available, we communicate over IPv4. Nothing has changed in this regard for ages I would say.

I finally got this resolved and it wasn't easy.

My ISP, AT&T, recent migrated IPv6 from 6rd tunneling, i.e. 6to4, to dual stack. In a dual stack configuration, both IPv4 and 6 connections are being sent. I have set my IPv6 connection to prefer IPv4 over 6 versus the default of preferring IPv6 over 4. I had also set the IP-HTTPS tunnel to disabled figuring it was no longer needed. Wrong!

Appears Eset sends LiveGrid updates via IPv4 using the IP-HTTPS tunnel. What I observed was LiveGrid connections being made but no data being sent or received w/IP-HTTPS tunnel disabled. What was strange was with diagnostic logging enabled, LiveGrid didn't indicate there was any issues? My recommendation is Eset develop a LiveGrid diagnostic utility that can/should be run to verify LiveGrid is fully functional. Also and BTW, the AMTSO Cloudcar test is not adequate since the connection to LiveGrid servers is made directly w/o secure tunneling delivery being employed. 

Share this post


Link to post
Share on other sites

Hi

Does anyone know why I was able to upgrade within the software from v11.0.159.9 to v11.1.42 on my Windows 10 32 bit PC, however on my Windows 10 64 bit PC, no updates are available to v11.1.42, and it is still stuck on v11.0.159.9 ?

Cheers

Share this post


Link to post
Share on other sites
37 minutes ago, psychopomp1 said:

Does anyone know why I was able to upgrade within the software from v11.0.159.9 to v11.1.42 on my Windows 10 32 bit PC, however on my Windows 10 64 bit PC, no updates are available to v11.1.42, and it is still stuck on v11.0.159.9 ?

Currently the latest available version is 11.0.159. We will resume updates to v11.1 (probably v11.1.52) soon. New v11.1 installers have passed QA tests and will be released within the next few days.

If you want to install v11.1 manually now, download it from the links posted above and install it over your current version.

Share this post


Link to post
Share on other sites

@Marcos, how often is LiveGrid supposed to update under ver. 11.1.51? What I am observing is an update every 10 - 15 mins.; at least so far this morning. Is Eset now pushing the LiveGrid updates from the LiveGrid servers as required; only when an update occurs to the white/black lists?

Share this post


Link to post
Share on other sites

The interval has been about 15-20 minutes for a quite long time already so it's nothing new in v11. Of course, the program may query LiveGrid servers for information about specific objects  as needed.

Share this post


Link to post
Share on other sites

@Marcos, there might be an issue with ver. 11.1.51 in regards to standby mode.

Prior to entering standby mode today, the only file to exist in the directory, C:\ProgramData\ESET\ESET Security\Charon, was CACHE.NBD. Upon resume from standby mode, a file is created in the same directory named FND0.NFI as shown in the below screen shot:

Eset_Charon.png.981021671c38dcec9f16b2149cff4602.png

Contents of this new file is:

Eset_FND0.thumb.png.59bf7b4e56f9f66ce9489c496b634142.png

Note that this file did not exist until resume from standby mode. With this new file creation, I am now observing four persistent LiveGrid server connections that were not present previously.

Is this the way LiveGrid is supposed to work in 11.1.51? Why was this behavior not displayed upon initial installation yesterday?

Share this post


Link to post
Share on other sites

I don't see anything wrong with that. As long as the LiveGrid feedback is enabled, it is normal that nfi files may be created in the charon folder. Please provide me with the nfi file for perusal.

Share this post


Link to post
Share on other sites
3 minutes ago, Marcos said:

I don't see anything wrong with that. As long as the LiveGrid feedback is enabled, it is normal that nfi files may be created in the charon folder. Please provide me with the nfi file for perusal.

File is attached. My main question is why did it take a day after installation for this behavior to exhibit?

FND0.NFI.txt

Share this post


Link to post
Share on other sites

Or are you stating this is a suspicious file awaiting Eset LiveGrid analysis? If so, why did it appear upon resume from standby mode?

Share this post


Link to post
Share on other sites

@Marcos, there is definitely a problem with Eset LiveGrid statistical submission option in ver. 11.1.xx.

I did some more testing and each time I enter standby mode via manual Win 10 standby option, a new FNDx.NFI file is created. Each new file creation results in 4 new LiveGrid  connections being established. This explains my previous forum comments about my LiveGrid connections mysteriously increasing. For example, four standby events results in four FNDx.NFI files and 16 LiveGrid connections!

Again my motherboard with is a bit dated and only supports S4 power saving mode. In this mode, the PC is actually powered down in standby mode.

It goes w/o saying that LiveGrid statistical submission stays off in my Eset installation.

In regards to my dual stack IPv4 and IPv6 network configuration, the issue appears to be related to the IPHelper service. When that service is active, a loopback; i.e. 127.0.0.0 connection, is established for it. At this point, Eset goes "bonkers."  Since I have all the IPv6 tunnels disabled, the IPHelper service is not needed. As such, disabling the IPHelper service resolved the conflict with Eset.

Share this post


Link to post
Share on other sites

@Marcos, another FYI. Same behavior I posted above in regards to return from standby mode is occurring if the LiveGrid option to submit detected malware is enabled. This one is a bit more predictable. Appears if LiveGrid detects anything in Quarantine, it triggers the continuous LiveGrid port scanning that never ends:

Eset_Quarantine.thumb.png.41a8782085b7fa43bfe3d2c285e01e9b.png

A FND1.NFI file is created. A bit ludicrous to say the least. Since Eset already detected the malware by signature, there is no reason to upload it again to LiveGrid for further analysis.

So it goes without saying, LiveGrid detected malware option is also now disabled. 

Share this post


Link to post
Share on other sites

Another possibility is there might be an issue with how LiveGrid is detecting Quarantined files in ver. 11.1. I forgot to mention that I had multiple files previously in Quarantine. All those files were test malware files from places like AMTSO and Wicar.org. As such, they were all detected originally by positive signature detection.

Share this post


Link to post
Share on other sites

If a file is detected doesn't mean that it won't be submitted. Even in the LiveGrid feedback submission setup, you can set actions separately for infected and suspicious files. And even if an nfi file is created, it may be refused by LiveGrid servers and would be subsequently deleted, e.g. if somebody else has already submitted it.

Another question is if the nfi file was really related to the above mentioned detection. If you would like me to check, provide the nfi file.

Share this post


Link to post
Share on other sites
7 hours ago, Marcos said:

And even if an nfi file is created, it may be refused by LiveGrid servers and would be subsequently deleted, e.g. if somebody else has already submitted it.

That's the problem as I see it; the NFI file never gets deleted. Hence the constant LiveGrid polling activity.

7 hours ago, Marcos said:

If you would like me to check, provide the nfi file

Here it is:

FND0.NFI.txt

Share this post


Link to post
Share on other sites

@Marcos, actually here's what occurs since I was monitoring this activity.

1. Eset immediately detects the wicar malware upon execution.

2. Eset and native SmartScreen alerts are displayed. I have "strict cleaning" set in Realtime scan options. As such, file is immediately deleted and placed in Quarantine.

3. At this point, no FNDx.NFI file exists. So I assume that the processing you described took place; submitted to LiveGrid, rejected since already detected, and any associated FNDx file deleted. I also visually verified at this point no NFDx file exists.

4. PC later enters sleep mode due to inactivity.

5. Upon resume from sleep mode, FNDx file exists and never ending LiveGrid connection looping starts.

Share this post


Link to post
Share on other sites
31 minutes ago, itman said:

That's the problem as I see it; the NFI file never gets deleted. Hence the constant LiveGrid polling activity.

Is such small nfi file created even several times a day every time the system wakes up from hibernation? Do you run scans with Windows Defender?

Share this post


Link to post
Share on other sites

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...