itman

Most Valued Members
  • Content count

    771
  • Joined

  • Last visited

  • Days Won

    23

itman last won the day on January 8

itman had the most liked content!

1 Follower

About itman

  • Rank
    N/A

Profile Information

  • Gender
    Male

Recent Profile Visitors

290 profile views
  1. Much better results. Kudos to Eset! https://www.av-test.org/en/antivirus/home-windows/windows-8/december-2016/eset-internet-security-10.0-164890/
  2. Are you running Emsisoft Internet Security or Antimalware? EIS and SS 10 is a non-no since they both contain firewalls. And there could also be problems with EAM and SS 10 because of possible conflicts with each realtime scanners and/or Eset's HIPS and EAM's behavior blocker. -EDIT- Also are you running any other security type software? Perhaps something that is performing web filtering? Even if installed in the past and then uninstalled, software remnants may exist. Also when you uninstalled Emsisoft did you run its cleaner to make sure all of it was uninstalled?
  3. If you do a Google search on this "Error code SSL-ERROR-BAD-MAC-ALERT," it is for the most part being generated by the targeted server during the SSL handshake process. Since you are receiving this error in all browsers, it leads me to believe that your ISP DNS servers are doing a bit more than just DNS address resolution. Appears to me that they are somehow detecting that Eset is proxying your SSL traffic. I would call your ISP provider and explain the situation. They might be able to shed some light on what is going on.
  4. Problem resolved ........ at least in regards to the Eset ELAM driver hash errors!!! After posting the previous reply, it caused me enough concern to get motivated. I uninstalled the previous .386 ver. that I had recently updated by means noted in this reply: https://forum.eset.com/topic/10722-ver-10-upgrade/#comment-54652 . I then downloaded and installed the full off-line installer ver. 386. Subsequent boots no longer show eelam.sys hash errors in the event log. All drivers in the off-line installer ver. showed update dates of 12/9/2016. However, file details of the eelam.sys driver still showed ver. 10.0.0.0, the same as what was previously installed, which is indeed a bit puzzling. Perhaps Eset forgot to update the revision number? I will check out the other concerns I posted in my previous reply when I get a chance.
  5. I am also questioning is Eset's ELAM driver is working properly. For reference: https://msdn.microsoft.com/en-us/windows/hardware/drivers/install/elam-driver-requirements . Of particular note is the following section: Malware Signatures The malware signature data is determined by the AM ISV, but should include, at a minimum, an approved list of driver hashes. The signature data is stored in the registry in a new “Early Launch Drivers” hive under HKLM that is loaded by Winload. Each AM driver has a unique key in which to store their signature binary large object (BLOB). The registry path and key has the format: HKLM\ELAM\\<VendorName>\ Within the key, the vendor is free to define and use any of the values. There are three defined binary blob values that are measured by Measured Boot, and the vendor may use each: •Measured •Policy •Config The ELAM hive is unloaded after its use by Early Launch Antimalware for performance. If a user mode service wants to update the signature data, it should mount the hive file from the file location \Windows\System32\config\ELAM. The storage and retrieval format of these data BLOBs is left up to the ISV, but the signature data must be signed so that the AM driver can verify the integrity of the data. This file, \Windows\System32\config\ELAM, has not been updated on my Win 10 home x64 system since I upgraded to ver. 1607 in early Oct., 2016. This indicates to me that Eset has not updated it with driver hashes to verify against? -EDIT- Also worth noting is: Defined Policy When the status of the drivers is returned (good, bad, unknown), system will decide whether load particular driver or not, based on the policy stored in: HKLM\SYSTEM\CurrentControlSet\Policies\EarlyLaunch\DriverLoadPolicy If the policy is not configured or disabled the boot drivers determined to be Good, Unknown, or Bad but Critical are initialized and the drivers determined to be Bad are skipped. I checked that registry key and Eset has established no load policy. This means that all drivers except bad are being allowed to load. I realize that the HIPS also monitors driver loading but based on my observations, it allows all drivers to load.
  6. Eset's ELAM driver is loading early as it should as shown by the below ntbtlog extract. So hash error is not affecting it, I believe. Note that this driver is used to verify other subsequent drivers as they load. Maybe I will try Process Monitor to see if it has any details if there are issues with Eset's ELAM driver. After all drivers load at boot time, the ELAM driver uninstalls itself. Microsoft (R) Windows (R) Version 10.0 (Build 14393) 1 18 2017 16:05:39.494 BOOTLOG_LOADED \SystemRoot\system32\ntoskrnl.exe BOOTLOG_LOADED \SystemRoot\system32\hal.dll BOOTLOG_LOADED \SystemRoot\system32\kd.dll BOOTLOG_LOADED \SystemRoot\system32\mcupdate_AuthenticAMD.dll BOOTLOG_LOADED \SystemRoot\System32\drivers\werkernel.sys BOOTLOG_LOADED \SystemRoot\System32\drivers\CLFS.SYS BOOTLOG_LOADED \SystemRoot\System32\drivers\tm.sys BOOTLOG_LOADED \SystemRoot\system32\PSHED.dll BOOTLOG_LOADED \SystemRoot\system32\BOOTVID.dll BOOTLOG_LOADED \SystemRoot\System32\drivers\FLTMGR.SYS BOOTLOG_LOADED \SystemRoot\System32\drivers\msrpc.sys BOOTLOG_LOADED \SystemRoot\System32\drivers\ksecdd.sys BOOTLOG_LOADED \SystemRoot\System32\drivers\clipsp.sys BOOTLOG_LOADED \SystemRoot\System32\drivers\cmimcext.sys BOOTLOG_LOADED \SystemRoot\System32\drivers\ntosext.sys BOOTLOG_LOADED \SystemRoot\system32\CI.dll BOOTLOG_LOADED \SystemRoot\System32\drivers\cng.sys BOOTLOG_LOADED \SystemRoot\system32\drivers\Wdf01000.sys BOOTLOG_LOADED \SystemRoot\system32\drivers\WDFLDR.SYS BOOTLOG_LOADED \SystemRoot\System32\Drivers\acpiex.sys BOOTLOG_LOADED \SystemRoot\System32\Drivers\WppRecorder.sys BOOTLOG_LOADED \SystemRoot\System32\drivers\ACPI.sys BOOTLOG_LOADED \SystemRoot\System32\drivers\WMILIB.SYS BOOTLOG_LOADED \SystemRoot\system32\DRIVERS\eelam.sys
  7. I am starting to believe this also could be HDD device related? It very well could be that the Eset ver. of the Win 10 ELAM driver just doesn't "play" well with older HDD hardware. My HDD where Win 10 is installed is a SATA II over 5 years old. The question now is if the driver is actually loading properly. That is if the driver is functioning as intended. It appears that it is based on prior postings since the Eset kernel is running as a Level 0 process.
  8. Are you using Win 10? My OS is Win 10 Home x64 ver. 1607.
  9. Based on this: http://info.opendns.com/rs/033-OMP-861/images/FB_How-Roaming-Client-Windows-Works.pdf it appears that OpenDNS is constantly changing DNS address. When that happens, Eset detects it as a new/changed network connection. You might have to disable Eset's unknown network detection which is not the safest thing to do.
  10. Check and see if the eelam.sys driver was updated on your PC. It was not updated on mine for the .386 upgrade. Whether that driver should have been updated is presently a point of contention.
  11. Eset online payment and protection feature does not work on Win XP x64: http://support.eset.com/kb5657/?locale=en_US
  12. Following up on the last posting, appears you have software on your PC that has established a localhost proxy. Software could be legit or malware. This proxy is filtering all inbound and outbound traffic from your PC and that it what the Eset firewall is detecting.
  13. Try this. Eset has a default firewall rule named "Allow all traffic within the computer." Enable logging for that rule as shown in the below screen shot. The log entries should show connections to/from both ::1 and 127.0.0.x. In other words, this is the Eset firewall rule that allows localhost connections. -EDIT- Also your last screen shot shows attempted browser connections from a localhost address. That is a no-no. Are you using a VPN? Do you have a proxy server setup?
  14. For starters, the screen shots you post are to small to read. And, I have a 25" monitor. I am beginning to believe your problems are not related to the Eset firewall but perhaps the Windows firewall. Do this as a test. Set the Eset firewall to "Automatic mode" but uncheck the option "Evaluate also rules from Windows firewall." If your localhost issues disappear, the problem lies in the application of existing Win firewall inbound rules and/or the Windows profile in effect.
  15. Before I get into this I will state that ever since I have been on ver. 10, I have not received one notification about a new network detection. This is the exact opposite behavior that occurred on ver. 8 and 9 that were "alerting" almost to a fault. I verified that the option to detect new networks was enabled. Also, this behavior persists whether the firewall is set to Interactive mode or the default Automatic w/inbound Win firewall rules applied. Note that I am currently using the Win firewall public profile. After I had installed ver. 386 recently, I checked the known networks setting and found what is posted in the below screen shot. Most disconcerting to me was that Eset created a duplicate entry for my Wi-Fi adapter connection and didn't even set the wireless security type correctly resulting in a totally insecure connection. Also I don't know why it created a connection for attlocal.net specifically referencing the DHCP server IP address on my gateway/router. Attlocal.net is the dns suffix used in the 2WIRE352 connection. Not sure the previous activity was directly related to the .386 upgrade since I had not checked the know network settings in a while but strongly suspect it.