Jump to content

ESET HTTP Server service on Local computer started and then stopped


Go to solution Solved by AutomatiseringNBC,

Recommended Posts

I'm running Eser Remote Administrator with HTTP server.

Before the weekend it was working fine, the test client was getting his updates from the ESET server.

 

Now, after the weekend, the HTTP service doesn't want to start, nor does the client get his updates.

 

When I go to services.msc on the server and try to run the ESET HTTP Server service I get this message: "The ESET HTTP Server service on Local Computer started and then stopped. Some services stop automatically if they are not in use by other services or programs."

 

Any idea how this can be fixed?

Link to comment
Share on other sites

I reinstalled the Apache HTTP proxy and now updates are working fine, as long as the firewall on the server is off.

The updates used to work when the firewall was on, although now they don't.

 

My guess is that it's because of the Eset Remote Administrator Proxy or the Eset HTTP Server?

Anyone able to help me?

I already tried reinstalling the Eset Remote Administrator Proxy, but that did not help.

Edited by AutomatiseringNBC
Link to comment
Share on other sites

  • ESET Staff

In case you are using Apache HTTP Proxy with configuration distributed with ERA, have you opened port 3128 for incoming connections. How are you clients configured, using HTTP proxy for updates? In case you are using HTTP server as mirror, you may create updates profile without proxy so that updates are downloaded directly from HTTP server.

Link to comment
Share on other sites

In case you are using Apache HTTP Proxy with configuration distributed with ERA, have you opened port 3128 for incoming connections. How are you clients configured, using HTTP proxy for updates? In case you are using HTTP server as mirror, you may create updates profile without proxy so that updates are downloaded directly from HTTP server.

Hello Martin, first of all thanks for your fast response.

We use the Apache HTTP Proxy for updates, the port is open since it used to work until Saturday/Sunday.

I configured it using this article.

Link to comment
Share on other sites

  • ESET Staff

 

In case you are using Apache HTTP Proxy with configuration distributed with ERA, have you opened port 3128 for incoming connections. How are you clients configured, using HTTP proxy for updates? In case you are using HTTP server as mirror, you may create updates profile without proxy so that updates are downloaded directly from HTTP server.

Hello Martin, first of all thanks for your fast response.

We use the Apache HTTP Proxy for updates, the port is open since it used to work until Saturday/Sunday.

I configured it using this article.

 

 

ERA product are not manipulating firewall configuration in any way, so my guess is that Apache HTTP proxy was actually not running properly and therefore clients were not able to connect.

 

There was a bug in Apache HTTP proxy itself in previous versions that caused proxy to stop working after some time - could you please verify version of your proxy? It can be find in CHANGES.txt file located in installation directory.

Also there is "Logs" directory which may contain error log with more information. In case your Apache HTTP proxy is not of version 2.4.18 you may proceed with upgrade: more information can be found here: hxxp://help.eset.com/era_install/63/en-US/components_upgrade.htmbut do not forget to backup your currently installed proxy in case something goes wrong.

Link to comment
Share on other sites

 

 

In case you are using Apache HTTP Proxy with configuration distributed with ERA, have you opened port 3128 for incoming connections. How are you clients configured, using HTTP proxy for updates? In case you are using HTTP server as mirror, you may create updates profile without proxy so that updates are downloaded directly from HTTP server.

Hello Martin, first of all thanks for your fast response.

We use the Apache HTTP Proxy for updates, the port is open since it used to work until Saturday/Sunday.

I configured it using this article.

 

 

ERA product are not manipulating firewall configuration in any way, so my guess is that Apache HTTP proxy was actually not running properly and therefore clients were not able to connect.

 

There was a bug in Apache HTTP proxy itself in previous versions that caused proxy to stop working after some time - could you please verify version of your proxy? It can be find in CHANGES.txt file located in installation directory.

Also there is "Logs" directory which may contain error log with more information. In case your Apache HTTP proxy is not of version 2.4.18 you may proceed with upgrade: more information can be found here: hxxp://help.eset.com/era_install/63/en-US/components_upgrade.htmbut do not forget to backup your currently installed proxy in case something goes wrong.

 

 

I have version 2.4.18.

 

The problem I'm having now is that the client won't update it's definitions through the server if the Endpoint Security firewall is on, although it used to work before the weekend.

Link to comment
Share on other sites

  • ESET Staff

The problem I'm having now is that the client won't update it's definitions through the server if the Endpoint Security firewall is on, although it used to work before the weekend.

 

This is not exactly my domain, but what rules have you added to enable communication? Have you enabled both incoming connections client->proxy on port 3128 and also outgoing connections proxy->ESET? ESET uses IP/hostname based balancers and maybe endpoints started using different hostname that is not covered by firewall? There may be also related information in error log of Apache HTTP Proxy located in "Logs" sub-directory on installation - especially in case updates are sabotaged by this component.

 

What is error code / message of failing signature update available in clients's GUI?

Link to comment
Share on other sites

 

The problem I'm having now is that the client won't update it's definitions through the server if the Endpoint Security firewall is on, although it used to work before the weekend.

 

This is not exactly my domain, but what rules have you added to enable communication? Have you enabled both incoming connections client->proxy on port 3128 and also outgoing connections proxy->ESET? ESET uses IP/hostname based balancers and maybe endpoints started using different hostname that is not covered by firewall? There may be also related information in error log of Apache HTTP Proxy located in "Logs" sub-directory on installation - especially in case updates are sabotaged by this component.

 

What is error code / message of failing signature update available in clients's GUI?

 

 

Every client is behind a central proxy server that controls their internet access, then there's a central firewall that blocks everything apart from HTTP/HTTPS, Clients can't download files from the internet, unless they have a specific internal IP address. 

 

This is in the Apache HTTP proxy error.log: 

[Tue Mar 01 11:22:06.678432 2016] [cache_disk:error] [pid 3368:tid 900] [client X] AH00703: Cannot cache files to disk without a CacheRoot specified.

The error message on the client is: "Could not connect to server.", but that only happens when the ESET firewall on the server is enabled. If I disable it in Endpoint Security the updates work.

Link to comment
Share on other sites

  • ESET Staff

 

 

The problem I'm having now is that the client won't update it's definitions through the server if the Endpoint Security firewall is on, although it used to work before the weekend.

 

This is not exactly my domain, but what rules have you added to enable communication? Have you enabled both incoming connections client->proxy on port 3128 and also outgoing connections proxy->ESET? ESET uses IP/hostname based balancers and maybe endpoints started using different hostname that is not covered by firewall? There may be also related information in error log of Apache HTTP Proxy located in "Logs" sub-directory on installation - especially in case updates are sabotaged by this component.

 

What is error code / message of failing signature update available in clients's GUI?

 

 

Every client is behind a central proxy server that controls their internet access, then there's a central firewall that blocks everything apart from HTTP/HTTPS, Clients can't download files from the internet, unless they have a specific internal IP address. 

 

This is in the Apache HTTP proxy error.log: 

[Tue Mar 01 11:22:06.678432 2016] [cache_disk:error] [pid 3368:tid 900] [client X] AH00703: Cannot cache files to disk without a CacheRoot specified.

The error message on the client is: "Could not connect to server.", but that only happens when the ESET firewall on the server is enabled. If I disable it in Endpoint Security the updates work.

 

 

To the first issue - please verify that CacheRoot is correctly set in httpd.conf - it should point to existing directory where cached files will be stored - now it looks like caching does not work's for you and Apache HTTP Proxy operates more like gateway. What were you installation steps in case mentioned value is not correctly set?

 

Second issue seems to be definitely related to firewall. Is there any chance to find in firewall logs details about reason why this communication was blocked? Maybe there is bad port selected in rule, or rule is not properly applied for clients.

Link to comment
Share on other sites

 

 

 

The problem I'm having now is that the client won't update it's definitions through the server if the Endpoint Security firewall is on, although it used to work before the weekend.

 

This is not exactly my domain, but what rules have you added to enable communication? Have you enabled both incoming connections client->proxy on port 3128 and also outgoing connections proxy->ESET? ESET uses IP/hostname based balancers and maybe endpoints started using different hostname that is not covered by firewall? There may be also related information in error log of Apache HTTP Proxy located in "Logs" sub-directory on installation - especially in case updates are sabotaged by this component.

 

What is error code / message of failing signature update available in clients's GUI?

 

 

Every client is behind a central proxy server that controls their internet access, then there's a central firewall that blocks everything apart from HTTP/HTTPS, Clients can't download files from the internet, unless they have a specific internal IP address. 

 

This is in the Apache HTTP proxy error.log: 

[Tue Mar 01 11:22:06.678432 2016] [cache_disk:error] [pid 3368:tid 900] [client X] AH00703: Cannot cache files to disk without a CacheRoot specified.

The error message on the client is: "Could not connect to server.", but that only happens when the ESET firewall on the server is enabled. If I disable it in Endpoint Security the updates work.

 

 

To the first issue - please verify that CacheRoot is correctly set in httpd.conf - it should point to existing directory where cached files will be stored - now it looks like caching does not work's for you and Apache HTTP Proxy operates more like gateway. What were you installation steps in case mentioned value is not correctly set?

 

Second issue seems to be definitely related to firewall. Is there any chance to find in firewall logs details about reason why this communication was blocked? Maybe there is bad port selected in rule, or rule is not properly applied for clients.

 

 

This is how I installed the proxy: hxxp://support.eset.com/kb3637/

I didn't do anything else, although I'll change the cacheroot settings.

 

Edit: the httpd.conf has this line it by default: #CacheRoot   c:/Apache24/cache.

I added 

ServerRoot "C:\Program Files\Apache HTTP Proxy"
DocumentRoot "C:\Program Files\Apache HTTP Proxy\htdocs"
<Directory "C:\Program Files\Apache HTTP Proxy\htdocs">
 Options Indexes FollowSymLinks
 AllowOverride None
 Require all granted
</Directory>
CacheRoot "C:\Program Files\Apache HTTP Proxy\cache"

Which has this line in it: CacheRoot "C:\Program Files\Apache HTTP Proxy\cache", so you tell me it's enabled or not, since the code above was added as part of the Knowledge Base article.

 

The second issue is caused by the ESET Endpoint security firewall on the server, when I turn it off it allows the client to connect and get his updates.

Edited by AutomatiseringNBC
Link to comment
Share on other sites

  • Solution

Updates are now working while the Endpoint security Firewall is enabled on the server.

 

I turned on the interactive mode and tried updating again, I then went back to the server and it asked for permission, I allowed it and created a rule for the Apache HTTP Server. 

After that I turned back on Automatic mode and now updates keep working while the firewall is on.

 

Thanks for your help Martin!

Link to comment
Share on other sites

  • ESET Staff

Updates are now working while the Endpoint security Firewall is enabled on the server.

 

I turned on the interactive mode and tried updating again, I then went back to the server and it asked for permission, I allowed it and created a rule for the Apache HTTP Server. 

After that I turned back on Automatic mode and now updates keep working while the firewall is on.

 

Thanks for your help Martin!

 

I'd be grateful if you could described required firewall rules here for future reference.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...