ESET VA: install tasks do not provide options for Endpoint Security

[carmik 0]

I have a 8.0.x (latest) ESET VA running for some time now without any issues. Today, I tried to run an ESET Endpoint Security task that I had pre-configured and ran successfully over the last weeks, but the operation failed.

Editing the task showed that it does not display any endpoint security products for install, only file server products etc. I double-checked the task filtering options (in case I was excluding the options) but they seem ok.

Any idea on what to try to fix this? I had this issue a year ago but at that time it seemed to be an intermittent ESET repository issue.

[Marcos 5,074]

Couldn't it be that you previously created the installer with an older version of Endpoint v8 or v7 than what is currently available in the repository?

[carmik 0]

Thank you for your fast reply. I am not deploying an installer. I'm using a task for this purpose. All Endpoint Security/Antivirus are missing.

[Marcos 5,074]

Please post information about the installed version of the ESET Proxy server, just in case. Does the EP server connect directly to the Internet or through a proxy server?

[carmik 0]

I believe I'm not using the ESET proxy (IIRC that was a product to mirror ESMC server installations). I'm using the bundled Apache HTTP proxy:

# rpm -qa |grep htt
httpd-2.4.6-97.el7.centos.x86_64
httpd-tools-2.4.6-97.el7.centos.x86_64
httpd-tools-2.4.6-93.el7.centos.x86_64

From the logs (/var/log/httpd/access_log) it seems it is running normally.

Apache connects directly to the internet (no upstream proxy).

 

Edited March 29, 2021 by carmik

[Marcos 5,074]

I mean this information from the console:

[carmik 0]

[Marcos 5,074]

The version is latest.

I'd recommend enabling trace logging verbosity in the EP server setup and then:
- run "service eraserver stop"
- start logging with tcpdump
- run "service eraserver start"
- reproduce the issue
- stop logging
- set standard logging verbosity
- open a support ticket and provide the pcap log as well as the EP Server log for perusal.

[carmik 0]

7 minutes ago, Marcos said:

- open a support ticket and provide the pcap log as well as the EP Server log for perusal.

1) Which pcap log are you referring to? Should I get a tcpdump on the network interface of the VA?

2) Should the ticket be opened with ESET local (national) support?

[carmik 0]

@Marcos please disregard my question about pcap, did not notice that you've mentioned tcpdump in the process.

I do have a number of questions regarding the log files I should submit. Specifically at https://help.eset.com/esmc_install/70/en-US/log_file.html three files are listed for v7 of ESMC: /root/appliance-configuration-log.txt, /var/log/eset/RemoteAdministrator/EraServerInstaller.log and /var/log/httpd (which is a directory).

I have ESET Protect (v8) as a virtual appliance (updated from ERA -> ESMC -> ESET Protect) installed, therefore I do not know if the files/directories above are valid or not. Questions:

1) Are the 3 files above sufficient? Or do you need the entire /var/log/eset/RemoteAdministrator and /var/log/httpd directories?

2) Do you need all access_log files from /var/log/httpd or is the latest access_log and error_log sufficient?

3) How do I turn extended logging on ESET Protect?

TIA,

M.-

[carmik 0]

Never mind, issue solved. It was a misconfiguration after the re-numbering of our ip range, which although it happened 3 weeks ago, eset protect just now complained...

Case solved, thanks again for your help.

[carmik 0]

Regretfully, the issue re-appeared.

In the first place, the cause was my fault: after the network changes I neglected to change server settings on the eset protect web console to direct the server to fetch updates from the new network proxy (essentially the apache proxy running on the same VA). I updated the settings, setting protect to point to new ip and I started seeing again the ESET Endpoint Security repositories. It all went fine for a day or two.

Today I tried to run the same task, but my eset endpoint install tasks failed with a unable to find repository message. Editing the task I see that again endpoint security packages were not listed, whereas other products (safetica, ESET file security and others) were.

In addition to that problem, all my endpoint systems report that program updates have failed!

@MarcosI have no other option but to open a ticket. However, you've not responded to my previous queries on how I should enable extended logging and which exact files I should send from my VA installation (see two posts above).

Please get back to me as soon as possible, I want to have this reported today if possible.

[Marcos 5,074]

Trace or debug logging can be enabled in the server setup:

[MartinK 378]

In the meantime, I would recommend to check configuration of firewall, http proxies or other similar tools, that might possibly block HTTP requests. As an example, repository requests might be redirected to public CDN server which might be blocked, by your infrastructure, and it would explain why it work randomly.

[carmik 0]

I've sent the details at noon, containing a link to this thread, hope I'll be hearing soon.

As for the network itself, your concern is well-founded, however there are another 6 LANs like my own, all in the same corporate WAN, that (AFAIK) are fetching updates without any issues. An array of network-transparent proxies performing layer 7 filtering intercepts all outgoing traffic, affecting all LANs. This is not under my control though. Of course something might have gone bad there and my colleagues at the other installations have not noticed it yet...

Is there some tool I could use from a windows/linux shell to test whether anything eset-visible-infrastructure-related is ok from my side? That would help isolate a networking issue pretty fast.

[carmik 0]

An update on the case. We had a thorough, multi-hour troubleshooting session with ESET local support and isolated the issue to be possibly located to the array of the network-transparent proxies. I've opened a ticket with them and anticipating a resolution hopefully by tomorrow.

It really helped that a colleague of the ESET bloke I was discussing with had a similar problem from another organization within the same WAN, indicating some sort of network issue.

Oil's well, will update when the thing is fully resolved.

[MartinK 378]

In case it wont helps, I would check EP's trace.log for errors indicating failure with repository synchronization. That might be the first step to confirm it is indeed some network related issue - synchronization is performed every hour, so there should be quite a lot of errors in case it is the case.

It network-related problem is indicated by trace.log, one might use tools like wireshark to capture network traffic (communication with ESET repository servers performs quite a lot of standard HTTP downloads), but in case problem happens outside of monitored device (i.e. on proxy, firewall or even outside of your network), it won't provide much more details. We have seen issues where firewalls were even modifying transferred files, but it was case of much larger and executable files, where in this case, not even much smaller metadata files are not transferred correctly according to symptoms.
Also there are some hints in ESET KB6749, especially the one using ESET repository servers not accessing public CDN servers might be useful in case there will be suspicion that certain public IP addresses are blocked or not whitelisted.

[carmik 0]

@MartinKthe issue is that trying to wget something from hxxp://repositorycdn.eset.com gets a zero sized reply (502 or 503 http error IIRC) from our WAN proxy array... Access to repository.eset.com is ok, and that is why we can "see" some products in the task, whereas others do not appear.

[MartinK 378]

1 hour ago, carmik said:

@MartinKthe issue is that trying to wget something from hxxp://repositorycdn.eset.com gets a zero sized reply (502 or 503 http error IIRC) from our WAN proxy array... Access to repository.eset.com is ok, and that is why we can "see" some products in the task, whereas others do not appear.

Actually it is mentioned also in referenced KB that you should be testing download either directly on specific installer, or at least on metadata file:

http://repository.eset.com/v1/info.meta
http://repositorynocdn.eset.com/v1/info.meta

or even this ones are failing?
Metadata file for each product is downloaded separately, so it is possible that only certain requests do fail and thus only specific products are missing.

[carmik 0]

Access to repository.eset.com is ok, whereas repositorycdn.eset.com fails. We are still waiting for resolution.

[carmik 0]

@MartinKsome more comments. First, I believe that  the KB relevant for our case is kb7811, since we are using ESET Protect 8 and not 7.

Now, after reading that KB article it would seem that if we are able to access hxxp://repository.eset.com/v1/info.meta we should be ok (considering our server was set to AUTOSELECT), but although we download the info.meta from this link successfully, we still do not see all the products available for inclusion for a ESMC task.

My understanding of what is meant by KB7811 is that we should be ok and we should look no further? Perhaps the article should be rephrased a bit to have a more clearer workflow, especially if the first step succeeds. Ie: should one try to undertake the steps mentioned in steps II onwards or not in that case?

Haven't had my first zip of coffee so I might not be reading some fine print correctly here.

Edited April 9, 2021 by carmik

[carmik 0]

It was a network/proxy issue after all. It was resolved today and I my tasks are operating just fine now (ie I can assign all products). Consider the case solved. And thank you for your help.