jdashn

1. Without a doubt! It would quite a bad job move to exclude *.doc files from scanning, typically i'd like to have zero exclusions, but some business critical software that we use does require exclusions, Citrix for instance has what i listed above just for one server type in their ecosystem. Several of our other products require various other db files or file types to be excluded from scanning on their servers, or even on the desktops. 2. Awesome, i was a little confused and was worried i was missing something, thanks for clarifying! 3. The files listed are put forth as files that cannot be scanned during the provisioning process in a citrix environment per Citrix. Additionally we do have several other pieces of software that also recommend that certain file types are excluded from scanning odd db files and other file types used by EHRs or Claims management software or HR systems. I'm not really going to be able to override the documentation they've provided - but i can say we did experience widespread oddities only in our production environment before these were in place, that we do not experience after (This though was only for our prod environment, under load - we were unable to replicate in test environments with few users, i can't replicate so i can't say it was eset for sure or not). So my concern is not if i should enter the exclusions as required by vendors, but how is the best way to ensure that files i'm directed to not allow scanning on, dont get scanned. I enter once for realtime, then once for on-demand scan, then for idle-state scan, then for startup scan (to be a bit more exact in what i'm talking about, when i say multiple places ). So that means that someone has to remember to hit all 4 of those spots, to enter the same information. i'm not trying to say ESET is bad or anything, i'm just trying to figure out if i'm seeing this wrong or if there is something i'm missing here? Or if there might be a way to keep from duplicating work? Thanks a ton for looking at this! Jason

Sorry i've been away from this thread! Thanks for this, but when you actually try to enter in a file type *.doc for example, in ESMC under File Exclusions you get an error. To exclude a file type it seems you need to go to the threatsense area for each scan type (Realtime, Malware, ( and each cleaning mode too?)) to exclude them in an ESMC policy. Infact i believe in v6 Console you could specify *.doc in the File/folder area, though i'm unsure now if it was working, or if there was just no error thrown to prevent me. 1 this is not for cleaning mode. This is asking why i've got to setup the file type exclusions separately from file exclusions and why i can't use a * in the middle of a path. It appears that for a citrix environment (in this one example, we have a few other Pieces Of Software that require some sort of file type exclusion) a provisioning server needs the following file types to be not scanned at all: *.vhd *.avhd *.vhdx *.avhdx *.pvp *.lok In order to achieve that it seems I would have to exclude them from realtime scanning, and specific scans like malware scans and what not (instead of the 1 spot i can exclude a Spesific file/folder hash or threat). I'm wondering if there is a single spot to enter so i don't have to enter it in multiple places. Generally we only use Strict cleaning. 2 I'm not sure this matters (as i use ESMC to manage these servers) but these particular machines aren't rebuilt daily, but some others with file type exclusions are. Realistically i'm just looking to see if there would be an easier way to setup an exclusion based on file type, instead of having to remember each spot that has a filetype exclusion parameter when we get a new piece of software or a software requirements are changed. This would reduce the possibility of human error, missing an exclusion, or forgetting to remove them in a spot when changes to these policies (or their initial creation) need to happen. As i said, maybe there is something i'm missing, or i'm not explaining this properly? Thanks a ton as always !!! Jdashn

Instead of editing a 3rd time with another question to add, i'll just add another question here: When excluding a file where one of the folders is unknown: C:\windows\ServiceProfiles\NetworkService\AppData\Roaming\Citrix\SubscriptionsStore\*\PersistentDictionary.edb This seems to be not possible with eset at all? Is there another notation i should be trying? I've seen some suggestion that \\ would work but would like to KNOW for sure before telling others this is in place and 'working'. Thanks as always!! Jdashn

It appears (and i could be wrong) that the only way i can exclude a file type ( .vhd for example) would be to enter that in under the Threatsense Parameters for Each scan type? Is there a way i can enter the file type under path like *.vhd or something? Does the setting for real-time protection also count for malware scans and the others? Is there a list of all the places i've got to add these extensions to be sure they're not scanned? it seems kind of goofy to have the file type exclusions in a different spot, and to have to enter it in multiple places when there is a single spot to exclude files, hashes, and threats. Is this really the only way? Out of curiosity, is there a reason i'm not seeing for this to be this way? Thanks, Jdashn

Have you tried disabling the xbox service on the device it's self then the traffic does not happen, and no need to try to get eset to ignore/not log it?

@MartinK Thanks! This seems to have worked without issue! Still doing some testing this morning, but my test machines are responding to commands on the new server - and they appear to use a certificate generated by server C. Thanks again!! Jdashn

We have two management servers (6.x) we're looking to consolidate down to 1 (7.x). To this end we followed these instructions to migrate one of the 6.x servers (server A) to the new server (server C). https://support.eset.com/kb6498/ https://support.eset.com/kb6490/ https://support.eset.com/kb6492/ This worked great for us, our endpoints started talking to the new server as we applied the policy to them (allowing us to move machines over before updating agent or endpoint). The issue comes when attempting to apply these instructions to the task of moving over the endpoints from the 2nd old server (server B). When i take the certificates from this server, and change the connection certificate on server C, all of the machines that currently connect to Server C no longer communicate until i change the certificate back to the original. In this situation is there a better method of moving over clients, or am i stuck reinstalling the agent on the endpoints reporting to server B to get them to connect to C? Will this change my ability to manage the endpoint software (mainly uninstall/upgrade/update) on these endpoints? Thanks a ton, in advance, for your consideration of this question!! Jdashn

@MichalJ Thanks for the update!! Jdashn

@MichalJ Any chance you were able to get a release date? Thanks!! Jdashn

I as well seem to be encountering this issue, with only select servers. Others seem to be able to grab the files just fine. Attempting to update eset file security from 6.5.12007.0 to 7.0.12014.0, using a manually created task, or the 'Update Eset Products' button. ~edit: I can get logs if needed, I can also be available for testing. We are located in USA, and can get external IP if needed as well.

I think the best solution would be the option to launch task after a task is completed, or task sequencing. This would allow for this current example, plus more complex tasking (install agent, reboot, install endpoint, reboot, full scan, run command (script) that sends email stating install tasks are completed -OR- runesetuninstaller.exe /nosafemode /force via cmd, reboot, runesetuninstaller.exe /nosafemode /force, reboot, runesetuninstaller.exe /nosafemode /force, reboot, install latest version of eset). I had thought this was going to be included in v7 of the product-- it was not.

Just curious, you're having the slowdown during the app-install script, or are you seeing slowdown using wsl in general? Jason

Not a malware writer, just a powershell guy, but.. the line you reference $pw = new-object System.IO.StreamWriter($p) is just writing information (Actually one of the faster, if not fastest ways to write to a file in PS), the $p = New-Object System.IO.Pipes.NamedPipeServerStream($pn,"InOut",100, "Byte", "None", 1024, 1024, $ps) line, and the others referencing System.IO.Pipes refer to making a pipe connection to another system which would be concerning. Doubt it's immediately helpful, but may assist when looking at other PS scripts for malicious intent. Jdashn

I'm not sure why it would not be that a simple undetected keylogger was run, credentials gained (thats the data they're looking to pilfer usually), and those creds used to disable eset and infect the computer with ransomware, instead of a brute force attempt on RDP. I understand that most of the bad actors seen by ESET come in via RDP, but if the keylogger is never detected one might reasonably assume the PW was brute-forced. Especially if the common wisdom/training aligns to suggest that it was RDP Brute-force? I would guess a bad actor who can get creds (either via rdp bruteforce, or keylogger or another exploit) will use them to whatever 'best effect' they can. If the company has CC#s to steal and the badguy can sell them they'll do that, if they can't find anything quickly i'd imagine they'd throw on some ransomware and move on to the next target. I would imagine most who are 'hacked' (keylogger, exploit, rdp bruteforce) aren't so much targeted for the data they have, as much as they are targeted for the low hanging fruit they are (they ran a keylogging script, they have rdp available over internet, other exploit). Then again, it's totally just a guess, and i'd hate to (in a situation of a breach especially) suggest that I know what caused this particular issue, but i would also think it's important to have all of the possibilities laid out.

Could it have been a keystroke logger not detected, and not an RDP brute force that was the cause of the breach? I know there have been discussions in the past about how certain processes that can be used to create a keylogger are not blocked?

Just doing the uninstall blindly I'd imagine you'll run into HIPS issues (self protection). I'd also imagine that the scripts are there to be run by the ERA Agent, likely kept in a way that is unusable otherwise (that'd be my guess). I have a tool that will do an uninstall for the windows version (they have the tool available on their web page), i know for the current windows version of the tool it requires safe mode to operate.. but all that can be scripted if needed. Would the instructions here help? https://support.eset.com/kb3244/

Thanks @Marcos There are several legal requirements we've got to consider when sending logs externally, especially if they could potentially contain PHI (which could include email subject lines, body), just was hoping you'd be able to tell me that the logs wouldn't include this sort of information, but i'm guessing by your answer it does?

@foneil we moved from 4.5 to 6.x so we had to uninstall then re-install so i had to re-place settings manually (which is also how i realized there are many missing features between the two) i replicated as many of the settings as i could. @filips Thanks! i've got our firewall guys looking into if any of that is currently being blocked. @Marcos Yes a hub transport role, if i enable these logs and send over, what information will it capture (we deal with a lot of PHI... will i have to sanitize?)? This is starting to become a big deal as the CIO has noticed a significant increase in spam, and some of it is certainly malicious (phishing attempts, etc). Is there a standard set of settings i should be looking to make sure i've got setup? Thanks to all three of you for your help with this issue so far! Jdashn

A little while ago we moved from EMSX 4.5 to the latest version, because of the pending (already happened?) anti-spam support ending. When we moved to the latest version we noticed most settings were different, and there were FAR FAR fewer options - though we figured that they went away because they did little, or they were turned on by default... or some such... Assuming protection would be stronger with a more recent version. This seems to not be the case, we have been getting very consistent reporting from users stating that they are getting e-mails into their inbox that used to go to spam, enough reports that it cannot be a coincidence (additionally these staff reporting were not aware a change took place, so they weren't looking for problems). I'm wondering what we could do to get back the protection it seems we have lost with the upgrade? Are there settings I may be missing? Any assistance would be appreciated in this matter! Thanks Jdashn

Filips, Thanks a ton for the info! any chance we can have a feature that says block tmp files unless they're inside an office container? (totally understand if not!) Thanks again, Jdashn

I'm finding that one of my Exchange mail protection Rules to block potentially harmful extensions is blocking certain Docx and other Office files, but not all. I was able to narrow it down to the rule that attempts to block the *.tmp extension. Is there anyone who my know why eset would be blocking some Office documents sent via outlook under a rule to block sending of *.tmp files? Thanks Jdashn

Ended up contacting support. Was told that the way to do this is to enable Text Logging (Setup, Tools, Log files, Enable text Log) from there you can set a file type (csv is easily human and machine readable, text and eventlogs were also offered) and then point to a network location if needed. All of the logs then populated, inlcuding those for Device Control, Grey List, Hips, MailServer, Virus, and warnings. Additional folders were created for eScan and ServerOnDeman as well! I hope this helps anyone else in their transitions or if looking to gather this information centrally to process. Jason

I know in previous versions (Eset mail 4.5, ERA 5x) we were able to see greylist logging from the ERA console. Is this available in the current version of the products? I'm looking around and can only see this logging available on the individual machines only, i'm guessing i'm just not seeing it? If it's available to be seen via ERA (6x) would it be possible to let me know how? or if there is a way to automate the saving of the local greylist logs somewhere else for processing? thanks a ton! Jdashn

https://techcrunch.com/2016/05/26/facebook-starts-selling-offsite-ads-targeting-non-users-too/ https://betanews.com/2018/02/19/facebook-tracking-users/ Beacons,cookies,ads,'sharewithfacebook' buttons,etc..

@TomFace Sad to say, user or not facebook is likely watching you, and selling your info. I think if you're in the EU you've got some additional protections.. but not much, really.