problem with the new signature database and protocol filtering

[marcel.germann 0]

With one of the new signature database updates we discovered that a java application is not able anymore to communicate properly with the server over http. It looked like it was an performance problem, sometimes it worked but very slowly, sometimes it didn't work at all.

Sadly it didn't help to disable ESET Endpoint Antivirus, only an uninstall helped.
To satisfy our users, i rolled back temporary to an older signature database, which helped for the first moment.

Now i figured out it helped to exclude the server ip addresses in the "web and email" -> "protocol filtering".

 

1. What did you change in the signature database that the communication didn't work properly anymore?

2. Why isn't protocol filtering disabled, if i disable ESET Endpoint Antivirus for an hour?

3. How can i debug if protocol filtering is blocking? Is there a log i have to enable?

[MichalJ 434]

Hello Marcel,

I will try to get you and answer for the question 1, if there were any changes in VSDB / Protocol Filtering module, that might affect your application.

 

Concerning your other 2 questions:

• for question number 2, what was disabled? Web access protection ? Protocol Filtering? Note, if you disable real-time protection, it does not affect protocol filtering in any way. 
• to enable logging for protocol filtering, you have to: Log files > Filtered websites > Advanced setup > Tools > Diagnostics >  “Enable Protocol filtering advanced logging”

[MichalJ 434]

So, the response from the tech team is, that we are constantly doing modular changes, To be able to understand the problem in more detail, we would like to ask you to generate a dump from process according to the attached guide (if you are running Endpoint 5, please send me a private message, I will send you the mentioned configuration .xml).

Edited April 19, 2016 by MichalJ

[DThomann 0]

So, the response from the tech team is, that we are constantly doing modular changes, To be able to understand the problem in more detail, we would like to ask you to generate a dump from process according to the attached guide (if you are running Endpoint 5, please send me a private message, I will send you the mentioned configuration .xml).

Hey Michal

 

We have a similar Problem... our first customer had the Problem that we couldn't open a Java program - AppCrash. This was on the 11th April (using ESET EAV v5). A week later, on the 18th April, we had 5 customers (3x EAV v6, 2x EAV v5)with similar errors. One of the customers couldn't print at all from a Java program.

All errors were resolved as soon as we disabled the protocol filtering.

I'll add the dump as soon as I can.

[marcel.germann 0]

Thanks for your answer.

 

I tried to log the protocol filtering, sadly i couldn't reproduce the error. Maybe in the new signature database it's already fixed.

But anyway i want to analyse problems with protocol filtering. As i saw in the advanced logging generates two pcapng files, which i can open with Wireshark.
How can detect if ESET is blocking something?

 

 

If i press "Schutz vorübergehend deaktivieren" (temporarily disable protection) i expect ESET to stop working.

It is not satisfactory for me if certain services still continue and I do not know if ESET caused the problem i'm looking for or not.

What is the easiest and fastest way to disable ESET completely without uninstalling?

[Marcos 5,071]

How can detect if ESET is blocking something?

The pcapng files contain information for developers. They are not intended for analysis by users. 

 

If i press "Schutz vorübergehend deaktivieren" (temporarily disable protection) i expect ESET to stop working.

What is the easiest and fastest way to disable ESET completely without uninstalling?

You can try:

1, enabling pre-release updates

2, temporarily disabling protection

3, if it helps, enable it and disable particular protection modules, one at a time. Start with real-time protection and automatic real-time protection start (followed by a system restart).

4, if it doesn't help, disable protocol filtering

5, if it doesn't help, disable HIPS and restart the computer

6, if it doesn't help, rename C:\Windows\System32\drivers\eamonm.sys and ehdrv.sys in safe mode, one at a time.

Inform an ESET representative disabling which of the above options resolves the issue.

[cpetry 4]

This happened to us to the point where we had to UNINSTALL ESET on 4-5 of our SYSPRO user systems.  The program connects to an IIS6.0 server using http.  The user thinks adding port 5555 (which is what the app uses) to the ESET web filtering HTTP filter is how you fix such an issue.  I told him that makes no sense since that list of ports is what you WANT to scan not an exclusion list.  Also, there's a KB article describing that ESET will scan ANY HTTP traffic on ANY port for ANY application on Windows Vista and newer.  He insists that we need to add ports to that web filter though.  I wish ESET would take the option to add ports to the HTTP scanner OUT since we all know it has no effect (if the ESET KB article is correct).

 

ESET KB:

hxxp://help.eset.com/eea/6/en-US/index.html?idh_config_epfw_scan_http.htm

 

So, is your server using IIS6.0?  If so, check this out.  I haven't been able to try it because this user is preventing the infrastructure team from doing their jobs.

https://support.microsoft.com/en-us/kb/828726

 

So now I have this user and his 4-5 works masquerading around on my network with no AV protection.

 

Edit: BTW, it happened after the weekend of the 15th.   I was told everything was working on Friday, April 15th, and the following Monday, April 18th, half of the SYSPRO users using K3 ovr HTTP couldn't connect to the server.  The app was reporting error 400, bad verb, but UNINSTALLING ESET resolved the issue.  Disabling the web filter had no effect.  Also, we've tried using the ESETUnintaller.exe and installing the latest 5.X build of ESET.  That didn't work either.  So between the user not allowing us to troubleshoot further or take corrective action on the server we are left with "ESET did it..."

Edited April 29, 2016 by cpetry

[RvW 6]

@cpetry : why don't they install v6?

[cpetry 4]

I'd like to install version 6. If ERA 6 and Endpoint 6 didn't have their own issues that clearly trump the issues of version 5. You're making an assumption that version 6 fixed all of those issues.

[Marcos 5,071]

I'd suggest using pre-release updates on at least one or more non-critical computers in a corporate network. There are millions of system configurations and software working even in non-standard ways (ie. not adhering to RFC standards) so making a change to the Internet protocol module make break something at a particular customer who uses a custom application tailored to their needs even if the module works alright for everyone else.

With pre-release updates enabled, you could discover and report the issue before the module is provided to all users. After reporting it to us, you could switch from pre-release updates to regular updates which would fix the issue until it's addressed by a new module update.

[cpetry 4]

I'm trying to convince management to test Windows updates, let alone ESET updates.  It's amazing how much of a push back I'm getting on that.  They actually like having updates wide open so anyone can download whatever and install it, regardless of the consequences.  They think firmware updates are regular updates.  I've never heard of any IT department pushing out firmware updates as a regular thing, or allowing users to do it.  I blame Microsoft and their garbage Surfaces for that one.

 

If I can convince them to do testing, I'd like to create sub-OUs for each site and put maybe 5 people into each sub-OU for testing.  I can then assign Windows updates one week earlier than our automated patching.  I can use those same sub-OUs for an ESET policy for testing pre-release modules.  I would even create a DL and put both the sys admins and testers in it so we can use that to speed up communication in the event something breaks.  You normally find out something is broken the day it happens, 3 days at most if it's during/after a weekend.