Registering Via a Proxy

[linuxhitman 0]

Finally have some time to test eset with a proxy.  I set it up based on the instruction at https://help.eset.com/esmc_install/72/en-US/http_proxy_installation_linux.html.

I deactivated one of my test boxes in the "trusted" network from the console (https://eba.eset.com/ba/devices). I then tried to run /opt/eset/efs/sbin/lic to register it again but there does not appear to be an option to specify a proxy to handle the request.

$ sudo /opt/eset/efs/sbin/lic --help
Usage: lic [OPTIONS..]
ESET File Security License management utility

Options:
  -s, --status             Activation status
  -k, --key=VALUE          Activation using a License Key
  -f, --file=FILE          Activation using an offline license file
  -u, --username=USERNAME  Activation using ESET Business Account or ESET
                             License Administrator
  -i, --pool-id=VALUE      Pool Id
  -p, --public-id=VALUE    Public Id
Common options:
  -h, --help               show help and quit
  -v, --version            show version information and quit

Copyright © 1992-2021 ESET, spol. s r. o. All rights reserved.
To report issues, please visit hxxp://www.eset.com/support

I can register via a static one-to-one NAT but that is impractical except for a tiny number of machines. Even if I had that many public IPs to burn I certainly do not want the inside servers exposed to the Internet like that.

Can someone point me to a resource explaining how to get a server to register via a proxy?  If there is another path to solving the problem, I am listening.

 

[MartinK 378]

Have you actually tried to set HTTP proxy parameters to product configuration via WEB interface it provides? I have not verified it, but that is most probably standard way how to configure product, and I would expect it to use those settings also when performing activation via command line.

[linuxhitman 0]

3 hours ago, MartinK said:

Have you actually tried to set HTTP proxy parameters to product configuration via WEB interface it provides? I have not verified it, but that is most probably standard way how to configure product, and I would expect it to use those settings also when performing activation via command line.

I do not know what you mean by "WEB interface it provides".  These are headless Linux boxes.  There are no browsers available.

I cannot register directly using the general outgoing NAT IP because the registration server is located in Slovakia and we have a country level block on traffic from Slovakia.  That is highly unlikely to go away anytime soon.  Apparently, the Cisco Firepower cannot apply a whitelist to the NAT address to override the block.

I can register using a statically NATed IP and a whitelist but I do not have enough V4 IPs to provide one for each of several hundred internal servers. Even if I was willing to provide that level of exposure.  So the proxy is a compromise.  I can create a static NAT between a DMZ and a public IP which can then be whitelisted.

Otherwise, it is a chicken-or-egg problem.  I cannot set the proxy until I register but I cannot register without the proxy.

Thank you for your reply.

[MartinK 378]

5 hours ago, linuxhitman said:

I do not know what you mean by "WEB interface it provides".  These are headless Linux boxes.  There are no browsers available.

I was referring to web interface, which can be enabled also via terminal (see documentation). In case enabling it and accessing from remote device won't be possible, there might be another alternative to use command line interface for manipulating with (documentation).
But regardless of that, I just realized that this topic is in "Remote Management" sections, which probably means that you are using ESMC/PROTECT to manage this product -> if so, easiest and recommended way to configure product is to create configuration policy in management console with required HTTP proxy and assign it to devices. If product is managed, is there any reason why activation from local terminal is performed instead of remotely executed activation task?

[linuxhitman 0]

Thanks for all the help -- I actually got it to work --  but management has decided they want to go with Microsoft Defender for Endpoint.