EndPoint Antivirus activation task failing

[Raymond 0]

Hi there, I am busy with a trial deployment of ESET.  I have installed ERA, created a GPO-based silent install of the agent using the MSI+MST, and a silent install of the Antivirus product using the INSTALLED_BY_ERA=1 MSI parameter to avoid the activation prompt after installation.  The client shows up in the dynamic "not activated security product" group in ERA.  I've created an activation task which is executing on the client but failing with "Activation was not successful: Could not reach activation server.".  Does this indicate that the ESET client is unable to talk to an internet-based activation server?  We use a proxy server on our LAN for internet access.  If i look in the ESET client's proxy settings, it is set to use the ESET server on port 3128.  This isn't something I configured.  

 

• Should i be disabling the proxy on the client?  I don't want each PC updating through our proxy - they should get updates from the ERA server
• I have not done anything special to set up a mirror on the ERA server - is there anything I need to do or will the ERA server automatically download updates and will clients automatically try and get them from the ERA server?

The documentation is very vague on the activation process, and the updating process.

[Marcos 5,070]

Did you use the all-in-one installer and selected "Apache HTTP Proxy"? If so, a policy with the proxy server pre-configured will be applied to agents and Endpoint by default. If you use a different proxy, you should use correct proxy settings in policies.

[Raymond 0]

Hi Marcos, thanks for the response.  Yes, i used the all-in-one and i included the Apache proxy.  To be clear, this is the ERA proxy role, right (i.e. nothing to do with Internet access - rather client<>ERA communication)?  If i look at the help text in the client it seems to imply that this is for internet connectivity.  

 

If we are already using a proxy server (for internet access) on our LAN, should i have excluded this option when i installed ERA?  I thought that this feature was a component of ERA, not a bundled proxy to provide internet access to clients?

 

I suspect i'm confused... please can you elaborate.  If you can also please confirm whether the clients need to be able to connect to ESET's public servers for activation or if the activation process is only between the Antivirus client/agent and the ERA server.  Thanks!

[Marcos 5,070]

The solution would be:

1, Configure agent's, client's and ERA proxy's policies to use correct proxy settings so that they all connect through the existing proxy server.

2, Uninstall Apache HTTP Proxy as you don't need it (don't confuse it with ERA Proxy which works as a mediator between the ERA Server and clients, e.g. if you have multiple networks).

[Raymond 0]

Thanks Marcos, I was confusing the two.  If i wanted to rather still use the bundled Apache proxy to minimize connections to our already over-burdened existing proxy, is there a way to tell the Apache proxy to use our existing proxy to reach the internet?

[Raymond 0]

Hi Marcos, I've done some more reading and from what i understand we can get the Apache proxy to use our Fortigate proxy using these changes to the httpd.conf:

 

ProxyRemote * hxxp://internalproxy.domain.com:8080

 

However there doesn't seem to be the ability to specify credentials for our existing proxy, so we'd need to see if we can allow unauthenticated access from the Apache proxy's IP.  But If anyone managed to get the password for the Apache proxy, they could then access the internet with no authentication (!)  Is the rule mentioned in this article correct for restricting the Apache proxy to request ESET-related websites (for both definition and product updates, and product activations)?  If this is correct, I'd feel far happier and we could skip using authentication for the Apache proxy altogether:

 

hxxp://help.eset.com/era/6/en-US/index.html?http_proxy_installation_linux.htm

 

Lastly, If we alternatively tried to use our own Fortigate proxy.... we are using Windows auth with this proxy.  Can i get the ESET Antivirus client to pass Windows credentials to our proxy using the "CONNECT TO LAN AS" settings?

[Raymond 0]

OK a bit of progress - i asked our network team to allow unauthenticated access from the ESET server's IP, so i'm using ProxyRemote to send requests to our internal proxy.  The activation/definition updates worked successfully for one of my test machines.  I then put the following into httpd.conf to try and restrict the Apache proxy to ESET destinations only and restarted Apache.  It breaks activation and I now see this in the Apache logs:

 

client denied by server configuration: proxy:edf.eset.com:443

 

Is one of the regular expressions in the list below wrong?  Or some other Apache syntax problem with the below?  I've been reading the Apache manual but haven't found the problem yet.  Guys it would be good to include this in a wizard somewhere... 

<Proxy *>
Deny from all
</Proxy>
<ProxyMatch ^[h,H][t,T][t,T][p,P][s,S]?://([^@/]*@)?([a-zA-Z0-9-]{0,63}\.)?[a-zA-Z0-9-]{0,63}\.[e,E][s,S][e,E][t,T]\.[c,C][o,O][m,M](:[0-9]+)?(/.*)?$>
Allow from all
</ProxyMatch>
<ProxyMatch ^[h,H][t,T][t,T][p,P][s,S]?://([^@/]*@)?([a-zA-Z0-9-]{0,63}\.)?[a-zA-Z0-9-]{0,63}\.[e,E][s,S][e,E][t,T]\.[e,E][u,U](:[0-9]+)?(/.*)?$>
Allow from all
</ProxyMatch>
<ProxyMatch ^[h,H][t,T][t,T][p,P][s,S]?://([^@/]*@)?(ds1-uk-rules-1.mailshell.net|ds1-uk-rules-2.mailshell.net|ds1-uk-rules-3.mailshell.net|fh-uk11.mailshell.net|edf-pcs.cloudapp.net|edf-pcs2.cloudapp.net|edfpcs.trafficmanager.net)(:[0-9]+)?(/.*)?$>
Allow from all
</ProxyMatch>
<ProxyMatch ^[h,H][t,T][t,T][p,P][s,S]?://([^@/]*@)?(87.106.247.14|209.157.66.250|209.157.66.253|212.227.134.125|212.227.134.126|212.227.134.128|212.227.134.130|212.227.134.131|212.227.134.132|212.227.134.133|212.227.134.158)(:[0-9]+)?(/.*)?$>
Allow from all
</ProxyMatch>

[Raymond 0]

In the end i used hxxp://kb.eset.com/esetkb/index?page=content&id=SOLN332to get a list of remote addresses for our deployment, and used <Proxy> rules instead of the above <ProxyMatch> rules.  My complete set of changes to httpd.conf (with proxy chaining to our existing corporate proxy and denial of non-ESET URLs) is now:

 

ProxyRequests On
ProxyVia On
ProxyRemote * hxxp://proxy.ourdomain.com:8080

<Proxy *>
Deny from all
</Proxy>
<Proxy "*.eset.com*>
Allow from all
</Proxy>
<Proxy "*.eset.eu*>
Allow from all
</Proxy>
<Proxy "*.trafficmanager.net*>
Allow from all
</Proxy>
<Proxy "*.cloudapp.net*>
Allow from all
</Proxy>

 

Hope this helps someone.

Edited July 31, 2015 by Raymond