eab 25 Posted November 15, 2023 Posted November 15, 2023 Google Chrome Browser performance degradation With WAP enabled in the 'ESET Endpoint for Linux (V7+)' policy, results in the browser performance being unbearably slow. Websites take anywhere from 2-5 times as long to load as with WAP disabled. Multiple scand processes can be seen at the top of CPU usage whenever a website is loaded. We have tested this on multiple Linux PCs over the course of the last 4 weeks or so. We have also tried to disable some of the WAP features in the profile - no improvements were found. We also tested in Firefox, and the performance degradation is not as severe. localhost, 127.0.0.1, 0.0.0.0 and ::6 blocked This problem we have been struggling with since months with ESET support. Now I am turning here to the forum community. Our software developers need to be able to access these addresses in the browser. We have tried everything we could think of in the WAP settings - excluding the IPs from WAP scans, adding the IPs and localhost under URL List Management - and nothing solves the issue. Due to these unresolved problems we have had to resort to disabling WAP completely in the profile.
Administrators Marcos 5,451 Posted November 16, 2023 Administrators Posted November 16, 2023 There will be always certain overhead when it comes to scanning or http(s) filtering, however, it should not be that big. I would recommend raising a support ticket for help with troubleshooting the issue and finding the root cause on your system. In our tests we didn't experience such a big performance drop.
ESET Staff kurco 25 Posted November 16, 2023 ESET Staff Posted November 16, 2023 (edited) Hi, could you please specify in more detail issue from point 2? I'm not sure, if I understand it correctly. You are running some services locally, which are listening on some ports and you can't access it via browser? Regards, Kurco Edited November 16, 2023 by kurco
eab 25 Posted November 16, 2023 Author Posted November 16, 2023 2 hours ago, kurco said: Hi, could you please specify in more detail issue from point 2? I'm not sure, if I understand it correctly. You are running some services locally, which are listening on some ports and you can't access it via browser? Regards, Kurco Yes, the devs are serving some website services from, for example, a docker container, and they cannot access the website via Chrome/Firefox because WAP is blocking it.
eab 25 Posted November 17, 2023 Author Posted November 17, 2023 (edited) @Marcos @kurco These are the results of our most recent tests (regarding problem #2): The policy settings are being successfully implemented on the client devices WAP is "blocking" the IP address of the docker container - in this case 172.18.0.3 Excluding the docker container's IP address allows the served website to be loaded in both Chrome and Firefox Questions: Why does WAP not seem to actually block access to the docker container's IP address Instead the web browser returns a blank page and the browser dev-tool shows a '200 OK' status, but there are 0 bytes of data returned. Which differs from when the web browser shows a 'Site not reachable', or ESET's 'This site is blocked', page. The site also remains reachable via the curl command in the terminal Why does WAP interfere at all with this internal IP address? Edited November 17, 2023 by eab
eab 25 Posted November 17, 2023 Author Posted November 17, 2023 Regarding problem #1 - from our testing we have determined that the performance degradation is not noticeable on Windows clients.
ESET Staff kurco 25 Posted November 20, 2023 ESET Staff Posted November 20, 2023 Hi eab, we will still need further details about your issues, so please raise a support ticket and we will allocate resources to investigate what is really going on. Thanks.
eab 25 Posted November 20, 2023 Author Posted November 20, 2023 @kurco we already have a ticket open with our local ESET supplier. We are preparing the necessary logs they requested. Will keep you posted ... kurco 1
abyss02 0 Posted January 9 Posted January 9 I just added brave to the list "excluded apps" in "policies" - i just added "/opt/brave.com/brave/brave" and "/usr/bin/brave-browser" ....
eab 25 Posted January 9 Author Posted January 9 53 minutes ago, abyss02 said: I just added brave to the list "excluded apps" in "policies" - i just added "/opt/brave.com/brave/brave" and "/usr/bin/brave-browser" .... OK, but this defeats the purpose of have WAP enabled in the first place. ESET support was able to identify the problem and acknowledged that this is not how it should be working. They will hopefully be fixing it in one of the next releases. 🤞
EjEm 1 Posted January 18 Posted January 18 Hello, how did you solve the issue ? I have the same, unable to access localhost resources. Should I whitelist localhost addresses ?
eab 25 Posted January 18 Author Posted January 18 17 minutes ago, EjEm said: Hello, how did you solve the issue ? I have the same, unable to access localhost resources. Should I whitelist localhost addresses ? We didn't. Still waiting on ESET to fix the bug.
EjEm 1 Posted January 18 Posted January 18 9 minutes ago, eab said: We didn't. Still waiting on ESET to fix the bug. So only "fix" is to disable Web protection ?
eab 25 Posted January 18 Author Posted January 18 34 minutes ago, EjEm said: So only "fix" is to disable Web protection ? Pretty much. 😕
eab 25 Posted February 15 Author Posted February 15 @Marcos do you know where the progress is on this problem? When can we expect a fix?
Administrators Marcos 5,451 Posted February 15 Administrators Posted February 15 Please provide your support ticket number or contact the distributor whom you reported the issue for an update.
eab 25 Posted February 15 Author Posted February 15 (edited) 13 minutes ago, Marcos said: Please provide your support ticket number or contact the distributor whom you reported the issue for an update. I believe this is the correct ticket info: #CASE_00668931 - Google Chrome Browser performance degradation The last person to be in touch with me about it was: Christian Schwalb I'll add to this that the performance degradation has created numerous problems in my company and is not limited to performance in the web browser. We have this performance degradation with a myriad of tasks related to software development, such as docker containers and python scripts - I guess anything communicating over https. As we use Atlassian's online products, the performance when simply opening tickets, or even posting comments, is painfully slow compared to not having WAP enabled. And every time performance is degraded, there is a spike in CPU activity with the scand process being at the top. Edited February 15 by eab
Administrators Marcos 5,451 Posted February 15 Administrators Posted February 15 Please ask for an update in the ticket since there's no note of the related ticket to ESET HQ. I've asked the person from ESET DE support for more information.
eab 25 Posted February 15 Author Posted February 15 7 minutes ago, Marcos said: Please ask for an update in the ticket since there's no note of the related ticket to ESET HQ. I've asked the person from ESET DE support for more information. Thank you for reaching out to ESET DE Support. I'm surprised, and a bit disappointed, that the info didn't reach ESET HQ.
Administrators Marcos 5,451 Posted February 15 Administrators Posted February 15 46 minutes ago, eab said: Thank you for reaching out to ESET DE Support. I'm surprised, and a bit disappointed, that the info didn't reach ESET HQ. I've eventually received the ticket ID from our DE support. In the ticket a developer replied: We plan to investigate the problem in much greater detail in the future and optimize the product to provide a better performance in a next version. As the problem is easily replicated by accessing the website from a default installation of our product, we don't expect the need further data from the client. Peter Randziak 1
eab 25 Posted February 15 Author Posted February 15 17 minutes ago, Marcos said: I've eventually received the ticket ID from our DE support. In the ticket a developer replied: We plan to investigate the problem in much greater detail in the future and optimize the product to provide a better performance in a next version. As the problem is easily replicated by accessing the website from a default installation of our product, we don't expect the need further data from the client. Yes, that's the last reply I received from Mr. Schwalb on the 13.12.23. It doesn't say anything other than "we have reproduced the issue and will fix it at some point in time". As a business using ESET for PC security, I expect a bit more in the way of a timeline of this problem being fixed - a problem which is so severe it makes WAP harmful to productivity (for Linux users), where it really should not. And for that kind of problem I expect something a lot more concrete from the developer of the software. BigBob and DKet 2
Administrators Marcos 5,451 Posted February 16 Administrators Posted February 16 18 hours ago, eab said: As a business using ESET for PC security, I expect a bit more in the way of a timeline of this problem being fixed - a problem which is so severe it makes WAP harmful to productivity (for Linux users), where it really should not. And for that kind of problem I expect something a lot more concrete from the developer of the software. I've reached out to the product manager with a reference to this topic and asked to look into it with higher priority, if possible. eab, Peter Randziak and DKet 3
eab 25 Posted February 16 Author Posted February 16 20 minutes ago, Marcos said: I've reached out to the product manager with a reference to this topic and asked to look into it with higher priority, if possible. Thank you kindly.
BigBob 2 Posted February 20 Posted February 20 Look like here at my company, we are affected by the same exact behavior @eab described in this thread... Like @eab, as an enterprise customer, I am very surprised that problem stay in « backlog », since to be able to use services listening on « localhost » for all of our developer's, it imply to disable completely the WAP security on all of our Linux clients running the product... I am now following this topic, thanks to @eab for the detailed behavior described here... eab and DKet 2
Recommended Posts