ERA 6 not pushing updates via Apache HTTP proxy

[Aabed 0]

hello everyone,

 

i'll make this short, we upgraded ERA 5.x to 6.x recently, i know there have been too many frustration over the new ERA but i managed to get my way through looking around the forums for similar issues.

 

my bumper right now is obviously the updates which is a huge concern (over 340 clients with outdated DB). here's what was done:

 

• Apache HTTP proxy was installed with the all-in-one installer
• Apache HTTP proxy was configured as per the article here
• did not set a password for Apache access
• webpage access test for Apache installation (hxxp://localhost:3128/index.html) is accessible successfully
• policy was made to set update server as per the same article above
• clients being tested have agent installed
• clients being tested are using EAV v 5.x

 

in the EAV client:

• when i enter the update server as 200.200.200.25:3128 > apply > try updating. i get bad link to update server

p.s.: 200.200.200.25 is ERA's server

 

i checked the Apache error log and found this not so helpful log:

•  AH01797: client denied by server configuration: proxy:hxxp://200.200.200.25:3128/update.ver

 

i double checked the httpd.conf file just to make sure i applied the configuration as illustrated in the article, while doing so, i did set the logging to debug and under <Proxy *>

i changed deny from all to allow from all

• restarted Apache service
• tried update on client again, it failed again

i checked Apache error log again and got the below logs:

 

most notably the 

• File does not exist: C:/Program Files/Apache HTTP Proxy/htdocs/update.ver
• mod_cache.c(717): (OS 5)Access is denied.  : [client 200.200.200.180:63461] AH00765: cache: Cache provider's store_body failed for URI hxxp://update.eset.com/v5-rel-sta/mod_023_pegasus_7229/em023_32_l0.nup

 

appreciate your help guys

 

here's some of the last line in the log file:

 

[Thu Nov 26 13:59:10.813126 2015] [authz_core:debug] [pid 4728:tid 1332] mod_authz_core.c(834): [client 200.200.200.180:63461] AH01628: authorization result: granted (no directives)

[Thu Nov 26 13:59:10.813126 2015] [cache:debug] [pid 4728:tid 1332] mod_cache.c(505): [client 200.200.200.180:63461] AH00757: Adding CACHE_SAVE filter for hxxp://update.eset.com/v5-rel-sta/mod_023_pegasus_7229/em023_32_l0.nup

[Thu Nov 26 13:59:10.813126 2015] [cache:debug] [pid 4728:tid 1332] mod_cache.c(539): [client 200.200.200.180:63461] AH00759: Adding CACHE_REMOVE_URL filter for hxxp://update.eset.com/v5-rel-sta/mod_023_pegasus_7229/em023_32_l0.nup

[Thu Nov 26 13:59:10.813126 2015] [proxy:debug] [pid 4728:tid 1332] mod_proxy.c(1157): [client 200.200.200.180:63461] AH01143: Running scheme http handler (attempt 0)

[Thu Nov 26 13:59:10.813126 2015] [proxy:debug] [pid 4728:tid 1332] proxy_util.c(2145): AH00942: HTTP: has acquired connection for (*)

[Thu Nov 26 13:59:10.813126 2015] [proxy:debug] [pid 4728:tid 1332] proxy_util.c(2199): [client 200.200.200.180:63461] AH00944: connecting hxxp://update.eset.com/v5-rel-sta/mod_023_pegasus_7229/em023_32_l0.nupto update.eset.com:80

[Thu Nov 26 13:59:10.828751 2015] [proxy:debug] [pid 4728:tid 1332] proxy_util.c(2408): [client 200.200.200.180:63461] AH00947: connected /v5-rel-sta/mod_023_pegasus_7229/em023_32_l0.nup to update.eset.com:80

[Thu Nov 26 13:59:10.875626 2015] [proxy:debug] [pid 4728:tid 1332] proxy_util.c(2782): AH02824: HTTP: connection established with 38.90.226.39:80 (*)

[Thu Nov 26 13:59:10.875626 2015] [proxy:debug] [pid 4728:tid 1332] proxy_util.c(2936): AH00962: HTTP: connection complete to 38.90.226.39:80 (update.eset.com)

[Thu Nov 26 13:59:12.219376 2015] [proxy:debug] [pid 4728:tid 1332] proxy_util.c(2160): AH00943: *: has released connection for (*)

[Thu Nov 26 13:59:12.219376 2015] [proxy:debug] [pid 4728:tid 1332] proxy_util.c(2878): [remote 38.90.226.39:80] AH02642: proxy: connection shutdown

[Thu Nov 26 13:59:12.219376 2015] [cache:debug] [pid 4728:tid 1332] cache_storage.c(664): [client 200.200.200.180:63461] AH00698: cache: Key for entity hxxp://update.eset.com/v5-rel-sta/mod_023_pegasus_7229/em023_32_l0.nup?(null)is hxxp://update.eset.com:80hxxp://update.eset.com/v5-rel-sta/mod_023_pegasus_7229/em023_32_l0.nup?

[Thu Nov 26 13:59:12.219376 2015] [cache:debug] [pid 4728:tid 1332] mod_cache.c(1333): [client 200.200.200.180:63461] AH00769: cache: Caching url: hxxp://update.eset.com/v5-rel-sta/mod_023_pegasus_7229/em023_32_l0.nup

[Thu Nov 26 13:59:12.219376 2015] [cache:debug] [pid 4728:tid 1332] mod_cache.c(1339): [client 200.200.200.180:63461] AH00770: cache: Removing CACHE_REMOVE_URL filter.

[Thu Nov 26 13:59:12.219376 2015] [cache:debug] [pid 4728:tid 1332] mod_cache.c(717): (OS 5)Access is denied.  : [client 200.200.200.180:63461] AH00765: cache: Cache provider's store_body failed for URI hxxp://update.eset.com/v5-rel-sta/mod_023_pegasus_7229/em023_32_l0.nup

[Thu Nov 26 13:59:12.250626 2015] [authz_core:debug] [pid 4728:tid 1332] mod_authz_core.c(834): [client 200.200.200.180:63471] AH01628: authorization result: granted (no directives)

[Thu Nov 26 13:59:12.250626 2015] [cache:debug] [pid 4728:tid 1332] mod_cache.c(505): [client 200.200.200.180:63471] AH00757: Adding CACHE_SAVE filter for hxxp://update.eset.com/v5-rel-sta/mod_023_pegasus_7229/em023_32_l0.nup

[Thu Nov 26 13:59:12.250626 2015] [cache:debug] [pid 4728:tid 1332] mod_cache.c(539): [client 200.200.200.180:63471] AH00759: Adding CACHE_REMOVE_URL filter for hxxp://update.eset.com/v5-rel-sta/mod_023_pegasus_7229/em023_32_l0.nup

[Thu Nov 26 13:59:12.250626 2015] [proxy:debug] [pid 4728:tid 1332] mod_proxy.c(1157): [client 200.200.200.180:63471] AH01143: Running scheme http handler (attempt 0)

[Thu Nov 26 13:59:12.250626 2015] [proxy:debug] [pid 4728:tid 1332] proxy_util.c(2145): AH00942: HTTP: has acquired connection for (*)

[Thu Nov 26 13:59:12.250626 2015] [proxy:debug] [pid 4728:tid 1332] proxy_util.c(2199): [client 200.200.200.180:63471] AH00944: connecting hxxp://update.eset.com/v5-rel-sta/mod_023_pegasus_7229/em023_32_l0.nupto update.eset.com:80

[Thu Nov 26 13:59:12.250626 2015] [proxy:debug] [pid 4728:tid 1332] proxy_util.c(2408): [client 200.200.200.180:63471] AH00947: connected /v5-rel-sta/mod_023_pegasus_7229/em023_32_l0.nup to update.eset.com:80

[Thu Nov 26 13:59:12.391251 2015] [proxy:debug] [pid 4728:tid 1332] proxy_util.c(2782): AH02824: HTTP: connection established with 38.90.226.39:80 (*)

[Thu Nov 26 13:59:12.391251 2015] [proxy:debug] [pid 4728:tid 1332] proxy_util.c(2936): AH00962: HTTP: connection complete to 38.90.226.39:80 (update.eset.com)

[Thu Nov 26 13:59:12.610001 2015] [cache:debug] [pid 4728:tid 1332] cache_storage.c(664): [client 200.200.200.180:63471] AH00698: cache: Key for entity hxxp://update.eset.com/v5-rel-sta/mod_023_pegasus_7229/em023_32_l0.nup?(null)is hxxp://update.eset.com:80hxxp://update.eset.com/v5-rel-sta/mod_023_pegasus_7229/em023_32_l0.nup?

[Thu Nov 26 13:59:12.610001 2015] [cache:debug] [pid 4728:tid 1332] mod_cache.c(1333): [client 200.200.200.180:63471] AH00769: cache: Caching url: hxxp://update.eset.com/v5-rel-sta/mod_023_pegasus_7229/em023_32_l0.nup

[Thu Nov 26 13:59:12.610001 2015] [cache:debug] [pid 4728:tid 1332] mod_cache.c(1339): [client 200.200.200.180:63471] AH00770: cache: Removing CACHE_REMOVE_URL filter.

[Thu Nov 26 13:59:12.610001 2015] [cache:debug] [pid 4728:tid 1332] mod_cache.c(717): (OS 5)Access is denied.  : [client 200.200.200.180:63471] AH00765: cache: Cache provider's store_body failed for URI hxxp://update.eset.com/v5-rel-sta/mod_023_pegasus_7229/em023_32_l0.nup

[Thu Nov 26 13:59:39.797501 2015] [authz_core:debug] [pid 4728:tid 1340] mod_authz_core.c(834): [client 192.168.50.44:54297] AH01628: authorization result: granted (no directives)

[Thu Nov 26 13:59:39.797501 2015] [proxy:debug] [pid 4728:tid 1340] mod_proxy.c(1157): [client 192.168.50.44:54297] AH01143: Running scheme http handler (attempt 0)

[Thu Nov 26 13:59:39.797501 2015] [proxy:debug] [pid 4728:tid 1340] proxy_util.c(2145): AH00942: HTTP: has acquired connection for (*)

[Thu Nov 26 13:59:39.797501 2015] [proxy:debug] [pid 4728:tid 1340] proxy_util.c(2199): [client 192.168.50.44:54297] AH00944: connecting hxxp://200.200.200.25:3128/update.verto 200.200.200.25:3128

[Thu Nov 26 13:59:39.797501 2015] [proxy:debug] [pid 4728:tid 1340] proxy_util.c(2408): [client 192.168.50.44:54297] AH00947: connected /update.ver to 200.200.200.25:3128

[Thu Nov 26 13:59:39.797501 2015] [proxy:debug] [pid 4728:tid 1340] proxy_util.c(2782): AH02824: HTTP: connection established with 200.200.200.25:3128 (*)

[Thu Nov 26 13:59:39.797501 2015] [proxy:debug] [pid 4728:tid 1340] proxy_util.c(2936): AH00962: HTTP: connection complete to 200.200.200.25:3128 (200.200.200.25)

[Thu Nov 26 13:59:39.797501 2015] [authz_core:debug] [pid 4728:tid 1348] mod_authz_core.c(806): [client 200.200.200.25:2722] AH01626: authorization result of Require all granted: granted

[Thu Nov 26 13:59:39.797501 2015] [authz_core:debug] [pid 4728:tid 1348] mod_authz_core.c(806): [client 200.200.200.25:2722] AH01626: authorization result of <RequireAny>: granted

[Thu Nov 26 13:59:39.797501 2015] [core:info] [pid 4728:tid 1348] [client 200.200.200.25:2722] AH00128: File does not exist: C:/Program Files/Apache HTTP Proxy/htdocs/update.ver

[Thu Nov 26 13:59:39.797501 2015] [proxy:debug] [pid 4728:tid 1340] proxy_util.c(2160): AH00943: *: has released connection for (*)

[Thu Nov 26 13:59:39.797501 2015] [proxy:debug] [pid 4728:tid 1340] proxy_util.c(2878): [remote 200.200.200.25:3128] AH02642: proxy: connection shutdown

[Thu Nov 26 14:00:19.063126 2015] [authz_core:debug] [pid 4728:tid 1340] mod_authz_core.c(834): [client 192.168.50.46:52218] AH01628: authorization result: granted (no directives)

[Thu Nov 26 14:00:19.063126 2015] [proxy:debug] [pid 4728:tid 1340] mod_proxy.c(1157): [client 192.168.50.46:52218] AH01143: Running scheme http handler (attempt 0)

[Thu Nov 26 14:00:19.063126 2015] [proxy:debug] [pid 4728:tid 1340] proxy_util.c(2145): AH00942: HTTP: has acquired connection for (*)

[Thu Nov 26 14:00:19.063126 2015] [proxy:debug] [pid 4728:tid 1340] proxy_util.c(2199): [client 192.168.50.46:52218] AH00944: connecting hxxp://200.200.200.25:3128/update.verto 200.200.200.25:3128

[Thu Nov 26 14:00:19.063126 2015] [proxy:debug] [pid 4728:tid 1340] proxy_util.c(2408): [client 192.168.50.46:52218] AH00947: connected /update.ver to 200.200.200.25:3128

[Thu Nov 26 14:00:19.063126 2015] [proxy:debug] [pid 4728:tid 1340] proxy_util.c(2782): AH02824: HTTP: connection established with 200.200.200.25:3128 (*)

[Thu Nov 26 14:00:19.063126 2015] [proxy:debug] [pid 4728:tid 1340] proxy_util.c(2936): AH00962: HTTP: connection complete to 200.200.200.25:3128 (200.200.200.25)

[Thu Nov 26 14:00:19.063126 2015] [authz_core:debug] [pid 4728:tid 1348] mod_authz_core.c(806): [client 200.200.200.25:2736] AH01626: authorization result of Require all granted: granted

[Thu Nov 26 14:00:19.063126 2015] [authz_core:debug] [pid 4728:tid 1348] mod_authz_core.c(806): [client 200.200.200.25:2736] AH01626: authorization result of <RequireAny>: granted

[Thu Nov 26 14:00:19.063126 2015] [core:info] [pid 4728:tid 1348] [client 200.200.200.25:2736] AH00128: File does not exist: C:/Program Files/Apache HTTP Proxy/htdocs/update.ver

[Thu Nov 26 14:00:19.063126 2015] [proxy:debug] [pid 4728:tid 1340] proxy_util.c(2160): AH00943: *: has released connection for (*)

[Thu Nov 26 14:00:19.063126 2015] [proxy:debug] [pid 4728:tid 1340] proxy_util.c(2878): [remote 200.200.200.25:3128] AH02642: proxy: connection shutdown

 

 

 

 

[Marcos 5,072]

You shouldn't set the proxy as an update server. Leave the update server set to AUTOSELECT and configure the proxy under Tools -> Proxy server in the policy applied on clients.

[Aabed 0]

hi Marcos,

 

thank you for your reply.

 

i did set the proxy to ERA's Apache server and set the update server to AUTOSELECT, i tried updating my clients then, 2/5 did update! so you're right about this, i'm wondering why only 2 updated.

 

just one thing though, you said Proxy under Tools, which i did, but what about proxy server under Updates?

i have this one set to Apache proxy.

 

additionally, how would i know that clients are updating from Apache's cache or updates.eset.com, i need to verify this before going forward deploying agents.

 

thanks for your help, appreciate it!

Edited November 27, 2015 by Aabed

[Aabed 0]

i tried updating locally (from eav) for clients that were failing to update through pushing update from ERA.

 

when i click update from their EAV, it prompts for a user name and password!

 

my proxy server has no user name/password set! any idea what this could be?

[MartinK 378]

Hello,

 

even when using HTTP proxy, authentication with ESET update servers is required (HTTP Proxy is forwarding them to ESET servers). Are those endpoints activated? Have you tried to update those clients directly (i.e. without using HTTP Proxy)?

[Aabed 0]

Hello,

 

even when using HTTP proxy, authentication with ESET update servers is required (HTTP Proxy is forwarding them to ESET servers). Are those endpoints activated? Have you tried to update those clients directly (i.e. without using HTTP Proxy)?

Hello Marin,

 

i activated the clients from ERA successfully, those clients seemed to be having a conflict in their policy, i removed all policies leaving two with the below settings:

UPDATE:

update server: autoselect

proxy server: Apache proxy

no user\pwd required

TOOLS:

proxy server: Apache proxy

no user\pwd required

 

however, for the troublesome users, when request their configuration from ERA i find there's a password set for the apache proxy with no username, even though it's not configured in the policy (p.s. i triple checked, there's no additional policies applied)

 

this update issue is driving me nuts!

 

have a look at this server in the below logs, it has the same policies and i couldnt update it as well, when i activated it through ERA it registered the EAV-username and password in its client automatically but i dont think its updating via proxy, any idea what's going on??

proxy_log.txt

[Marcos 5,072]

The log shows attempts to update from v4 update servers. Do you manage both v4 Business Edition products and v6 Endpoint via ERA 6? I'd strongly recommend to upgrade v4 to v6 as soon as possible as the older version does not provide sufficient protection from newly emerging threats.

[Aabed 0]

The log shows attempts to update from v4 update servers. Do you manage both v4 Business Edition products and v6 Endpoint via ERA 6? I'd strongly recommend to upgrade v4 to v6 as soon as possible as the older version does not provide sufficient protection from newly emerging threats.

 

we're planning to upgrade clients to v6 eventually, but this will happen gradually. our main concern right now is updates as all clients have been outdated for over a week!

 

for now, i've managed to apply policies for all clients, i just figured out that the server's version "File Security" applies only the policy File Security for Windows Server - HTTP Proxy Usage, after pushing this policy those clients were configured correctly (update server set to automatic and proxy set to Apache Cache) but none was updating with the error user and password not set, i added the user and password in the policy and updates were flowing.

 

my question is does setting the user and password still updates through cache server?

 

how can i be certain that clients are updating from cache server and not ESET? i'd really like to confirm this as it would create an enormous traffic if updating from ESET, causing a major network issue.

 

hopefully this would be our last issue with the updates!

[MartinK 378]

Hello,

 

you can use third-party network minitoring tools like Wireshark to check where is ESET Endpoint connecting. In case you want to be absolutely sure it is not downloading updates directly, you can configure you firewall (local, or maybe even company-wide) to block communication with ESET download servers except for computer with HTTP Proxy installed. List of download servers with they hostnames/IPs can be found here: hxxp://support.eset.com/kb332/

[MartinK 378]

 

Hello,

 

even when using HTTP proxy, authentication with ESET update servers is required (HTTP Proxy is forwarding them to ESET servers). Are those endpoints activated? Have you tried to update those clients directly (i.e. without using HTTP Proxy)?

Hello Marin,

 

i activated the clients from ERA successfully, those clients seemed to be having a conflict in their policy, i removed all policies leaving two with the below settings:

UPDATE:

update server: autoselect

proxy server: Apache proxy

no user\pwd required

TOOLS:

proxy server: Apache proxy

no user\pwd required

 

however, for the troublesome users, when request their configuration from ERA i find there's a password set for the apache proxy with no username, even though it's not configured in the policy (p.s. i triple checked, there's no additional policies applied)

 

this update issue is driving me nuts!

 

have a look at this server in the below logs, it has the same policies and i couldnt update it as well, when i activated it through ERA it registered the EAV-username and password in its client automatically but i dont think its updating via proxy, any idea what's going on??

 

 

Not sure it is your case, but a quiet a common misunderstanding is that once you remove or disconnect ERA configuration policy, client will restore previous settings. Imagine this scenario:

1. manually configure client setting "Updates user name" to some value "X".
2. create and apply policy setting "Updates user name" to some different value "Y".
3. remove this policy (and other policies "applying" or "forcing" the same setting)

after policy removal, client will be still configured to use value "Y" applied from step "2" and not value "X" that was present before. New policy explicitly resetting mentioned configuration value to "X" is required (original value "X" not preserved)  ... could be your issue? In this specific case once policies overriding credentials were removed, re-activation would probably fix this issue.

[Palps 3]

Hello,

 

I have basically the same problem. I want to be sure, that my clients are receiving their updates from the Apache HTTP Proxy and not from the internet.

In general my clients are updating, I just want to know from where.

I set the update server to AUTOSELECT and set my Apache HTTP Proxy as proxy server. With this settings the client is requesting the update at our proxy server, so this seems to be correct.

 

When I now capture the traffic at my proxy server I can see that the proxy server is connecting to the ESET servers in the internet. Now the question is, is this request just for authentication or is the proxy downloading the update files every time a client is running an update?

 

When I look at the Apache cache directory, then I can see that there are many cached files. So it seems that the proxy is caching the update files correctly. How do I know that the client is using the cached files instead of just be redirected through the proxy to the ESET update servers?

 

Attached you can find two Wireshark captures, one of the client (ip 10.51.13.23) and one of the Apache proxy (ip 10.51.13.17) and the log-file of the Apache proxy server.

 

Maybe everything is correctly setup already, I just want to be sure, that the clients are using the cached update files instead of downloading it from the internet.

 

Thank you in advance

 

proxy_log.txt

[Marcos 5,072]

As you can see in the log, only update.ver is requested (this one is intentionally not cached). However, Endpoint itself contains a mechanism to prevent the same update.ver from being downloaded so basically only very little amount data is transmitted.

[MartinK 378]

When I now capture the traffic at my proxy server I can see that the proxy server is connecting to the ESET servers in the internet. Now the question is, is this request just for authentication or is the proxy downloading the update files every time a client is running an update?

 

It is both for authentication and also check for file changes. In case file has not changed, data should not be re-downloaded if available in local cache.

 

You can also enable more detailed logging of cache operations that will report cache-misses as described in section Cache Status and Logging of https://httpd.apache.org/docs/2.4/mod/mod_cache.html#status

Edited February 3, 2016 by MartinK

[Palps 3]

Thank you for your prompt answer. This helped me a lot!

[Gamtat 1]

On 2/2/2016 at 6:33 AM, MartinK said:

You can also enable more detailed logging of cache operations that will report cache-misses as described in section Cache Status and Logging of https://httpd.apache.org/docs/2.4/mod/mod_cache.html#status

Any idea how to configure this on Windows?  I broke my golden rule to never run Apache on Windows after installing the ESET proxy.  It seems no matter what I change in the httpd.conf the only log file that gets created/updated is C:/Program Files/Apache HTTP Proxy/logs/error.log.  I run apache on debian a bunch and am stumped as to why I can't get this working.

[MartinK 378]

18 hours ago, Gamtat said:

Any idea how to configure this on Windows?  I broke my golden rule to never run Apache on Windows after installing the ESET proxy.  It seems no matter what I change in the httpd.conf the only log file that gets created/updated is C:/Program Files/Apache HTTP Proxy/logs/error.log.  I run apache on debian a bunch and am stumped as to why I can't get this working.

Make sure that apache module "log_config_module" is loaded using statement:

LoadModule log_config_module modules/mod_log_config.dll

and make sure path to custom logs directory is accessible by Apache process. In my case, following configuration worked:

CustomLog "logs/cached-requests.log" common env=cache-hit
CustomLog "logs/uncached-requests.log" common env=cache-miss
CustomLog "logs/revalidated-requests.log" common env=cache-revalidate
CustomLog "logs/invalidated-requests.log" common env=cache-invalidate  

which redirected those logs to standard logs directory where error.log is located. It is also possible to increase logging verbosity by modifying:

#
# LogLevel: Control the number of messages logged to the error_log.
# Possible values include: debug, info, notice, warn, error, crit,
# alert, emerg.
#
LogLevel warn

according to description, but that would most probably affect only main log, by default named error.log.

[Gamtat 1]

That's exactly what I did.  Still, the only log that gets written to is the error.log.  I can increase the log level to debug and can see some cache-related entries in there but don't get any distinct cache logs created.

I've added CustomLog "logs/access.log" common and see a bunch of..

10.10.10.92 - - [20/Sep/2017:13:20:31 -0500] "POST hxxp://c.eset.com:80/ HTTP/1.1" 200 58
10.10.10.92 - - [20/Sep/2017:13:20:31 -0500] "POST hxxp://c.eset.com:80/ HTTP/1.1" 200 58
10.10.10.82 - - [20/Sep/2017:13:20:16 -0500] "HEAD hxxp://update.eset.com/eset_upd/era6/update.ver HTTP/1.1" 503 -
10.10.10.82 - - [20/Sep/2017:13:20:37 -0500] "HEAD hxxp://38.90.226.37/eset_upd/era6/update.ver HTTP/1.1" 200 -

.. so with that and the error.log changes I know apache can write to the log directory. 

 

Edited September 20, 2017 by Gamtat

[Gamtat 1]

Config was fine.  Logs are working now.  This is why I don't like messing with these things on Windows: CRLF is not the same as LF.  Thanks, Notepad!  Now I just have to figure out why some things aren't being cached but that's for another thread.

Edited September 20, 2017 by Gamtat