Jump to content

steingat

Members
  • Posts

    10
  • Joined

  • Last visited

About steingat

  • Rank
    Newbie
    Newbie

Profile Information

  • Location
    USA
  1. Marcos, Sent you a PM with the logs collected from one of the problematic endpoints
  2. Hello Marcos, This is happening on multiple endpoints with multiple ISPs. However, our users do jump on/off a VPN connection on a regular basis, and at least today, 7 end points were affected, 4 were connected to a VPN connection at the time of the error, one was on wifi and a ethernet connection at the same time, 2 were directly connected to the internet via a network cable and not on a VPN/Proxy. We have Proxy auto detection turned off on all of our endpoints so these endpoints should not be using a proxy. I will attempt to gather the requested logs from at least one endpoint.
  3. We are running into this problem as well with multiple random endpoints. From my testing, rebooting the endpoint seems to resolve the issue at least temporality, but then the problem can re-occur on the same endpoint days later.
  4. Ya, Sure. One more item of information, If I run into this, I have also found that I can unplug the network cable and then plug in the network cable during the same boot provided that I do not switch networks and it seems to pick up on the correct profile. Note, All 4 images below are referring to the "USB 10/100/1000 LAN" interface Image1 - computer did not have USB NIC plugged in on boot, USB Nic was plugged in after logging into MacOS Image2 - Unplugged network cable, plugged network cable back in, on the same network as image1 (Work) Image3 - Unplugged network cable, plugged network cable back in On a different network then image 1, should be public Image4 - Unplugged network cable, plugged network cable back in, Same network as Image3, should be public
  5. Equipment: Macbook Air running Catalina and 6.10.300.1 with USB network adapters/docking stations We have a firewall profile called WORK. I have set the activators on this profile to be based on subnet. I have also tried IP range. If the USB network adapter is plugged in on restart or boot everything works fine and the correct profile, WORK is selected. If the network adapter is plugged into the machine after the machine is booted, then all we get is ??? for what profile has been selected and the profile seems to default to PUBLIC. For our application, setting the network profile by interface name is not workable as we do not want certain firewall setting to be enabled if they say go home and connect to their home network. Is there any solution to this other then to reboot the machine? We have had this issue with Macs since we started using Eset on macs 2 years ago so this is not something new with the latest version. However, we plan on deploying more then just a hand ful at this point.
  6. When the installs of this encryption product fail, they fail in a way that requires we completely decrypt the drive and completely remove the software from the machine. Then do a reinstall. These machine no longer serve as good test subjects as we are doing a new install and not a upgrade install, the new installs we use a local admin account to run, we do not use the remote deployment tool as the encryption software on the initial install needs to identify a primary user for logon purposes. But, from the systems I have tested, the ones that have had LG enabled have failed, the ones that have LG disabled do not fail even if all other policy items are the same and the machine model/update level (windows/eset) are the same. I have run out of in stock laptops at this point to do additional testing with to try leaving HIPS off and enabling LG. I might have one additional system to test this with in 24-48 hours as we are upgrading a users system due to a failed touch pad (mechanical issue, not software or electrical). If you would like me to generate logs/ a dump/etc please let me know what logging options you would like enabled. With that said, we would consider re-enabling LG across the org once we are done with deployment. One more item to note: Live grid was also submitting multiple temp files from our PDF product, Foxit PDF, the files would exist in c:\user\USERNAME\appdata\local\temp\foxImgSteam.tmp and be submitted to LG up to 50 times per day per user We had received some complaints from our users that PDF documents were being corrupted when saving to specific locations, I am not sure if this is related. From the documentation I saw, I did not see a way to create an exclusion for users %appdata%\temp\foxImgSteam.tmp as Eset runs with system creds and it does not appear that you can use wild card inside of path names such as c:\user\*\appdata\local\temp\foxImgSteam.tmp or just specify a filename such as foxImgSteam.tmp
  7. I have more data, Please see below: Before starting any of this, I had added performance exceptions for the final install location and the directory the installer was running out of under: Detection Engine>Exclusions>performance exclusions Detection Engine>Realtime fiule system protection>Processess exclusions - Whitelisted associated executables Computer 1 - Policy Defaults, enable ESET LiveGrid® feedback system Most likely on (Not locked down) - Update Failed Computer 2 - Policy Defaults, enable ESET LiveGrid® feedback system on (Not locked down) Saw Livegrid submit files of multiple securedoc files - Update Failed - At this point, ALL Eset files submitted to livegrid where whitelisted via hash for all computers Computer number 3 - Created Test policy group, moved laptop there, per eset paused real time protection, Unknown status of "enable ESET LiveGrid® feedback system" - Update successful Computer 4 - Policy Defaults, "enable ESET LiveGrid® feedback system" most likely off - Update successful Computer 5 - Trying multiple hibernate/sleep/power off cycles, Policy Defaults, "enable ESET LiveGrid® feedback system" most likely off - Update successful Computer 6 to 9 - Policy Defaults, "enable ESET LiveGrid® feedback system" most likely off, but inital status unknown - Update successful This is the point that I enforced "enable ESET LiveGrid® feedback system" to on via policy Computer 10 - Policy Defaults, "enable ESET LiveGrid® feedback system" is on and enforced via policy - Update Failed Computer 11 - Policy Defaults, "enable ESET LiveGrid® feedback system" is on and enforced via policy - Update Failed Went back into the policy, I enforced "enable ESET LiveGrid® feedback system" to OFF Computer 11-15 - Policy Defaults, "enable ESET LiveGrid® feedback system" is OFF and enforced via policy - Update successful Please note, we are content with just turning off the Eset live grid feedback system as a solution, I did not test adding anything to Detection Engine>Cloud Based protection>submission of samples>exclusions I will say that I am suprised to see this module cause issues even after we had added exclusions elsewhere in the system.
  8. Hmm, I'm not so sure about that, I did some more digging, found out that the "Livegrid" submission option was not locked down in our environment. Detection Engine>cloud based protection>enable ESET LiveGrid® feedback system. So some computers had this ON and some had this OFF. I Locked down the setting to ON. The next two computers I attempted to upgrade bombed in the middle of the install. Forced the setting OFF, so far only had a chance to test one system, but the install went through without a issue. Will try a few more with the setting in the OFF position. With that said, this application aggressively defends the files in its install folder, here are the patch notes from 1 minor revision ago: Patch notes from securedoc: SD-30091: Protection has been made stricter for the contents of the UserData folder, barring users from deleting, moving or renaming files from this folder required by SecureDoc Client software. In SecureDoc 8.5, permissions and file verification have been made stricter on all files in the userdata folder. Users are still allowed to create and modify files in that folder, but they will not be able to rename/move/delete them. In addition, modifications for SD configuration files are still restricted for users and optionally (based on settings) for admins per profile configuration. SD-31670: Some customers who are using the UEFI Boot "Patching" method (to patch windows boot manager in order to load preboot) reported that windows updates had the potential to overwrite the patch. Issue: SecureDoc has the ability to load pre-boot by patching windows boot manager, such that the bios will launch SecureDoc pre-boot authentication when it thinks it is launching windows. This method is normally used for devices where the alternate method of adjusting the bios boot order is not properly supported. It was found that when Windows updates the boot files, this patch could be removed and not restored before the system reboots. Normally, WinMagic SecureDoc implements additional protection at the BIOS level, however in some cases this protection is unavailable. Solution: WinMagic has developed additional protection at the windows level to protect the boot patch from being overwriting by a Windows update or upgrade process.
  9. Last night LiveGrid automatically submitted a bunch of the Securedoc encryption install files to Eset. Since this morning, I have tested 5 installs with the same settings as last night and so far no issues. There was also a modules update to the Eset server. I can only conclude that these items were added to the Eset models update in some way for the client/servers. I will post again If i continue to have issues.
  10. Hello, We use a enterprise encryption product called SecureDoc by Winmagic. Since version 7.2.2055 of Eset, whenever we attempt to remotely deploy updates to this product with our remote management tool we run into intermittent issues with Eset blocking the installs and crashing the application mid-way through the install. I have tried adding a bunch of performance exclusions and other exclusions to the policy for Eset. However this has not helped. The remote management tool runs the installer (MSI deployment) with SYSTEM permissions. Most of the time, If I login as a user with local admin rights, the installer runs without issue. I have also noticed that Eset has started to block certain types of registry edits. Such as if I use logmein or our remote management product to edit some keys such as hklm\software, but If I log onto the machine locally or using the windows "Remote registry" tool using the SAME Permissions then I am not denied access. The reason I suspect Eset is on these machines, if I completely uninstall eset I do not run into these issues. What I need to figure out is the following: 1. How do I find and generate logs to verify it is heuristics or the Machine learning that is trying to block this action? Does Eset log EVERY block? 2. How do I correctly whitelist this installer from EVERY module in Eset and every process spawned by it? The installer throws files into c:\windows\temp directory and needs to run these to verify the encryption currently on the drive as part of the install process. I have attempted to already add a performance exclusion for the programs install directory, its original execution directory, AND I excluded files sent to livegrid by hash, However, it seems Eset just ignores these exclusions on multiple machines. I do have the policy exclusions enforced.
×
×
  • Create New...