Endpoint Protection

Hello,

We've done some research into making SEPM available over the internet, including review of multiple other forum posts and KB articles:

https://support.symantec.com/en_US/article.TECH93033.html

https://support.symantec.com/en_US/article.TECH178325.html

Based on this reading and those postings, we're considering the following to allow clients to communicate both on- and off-network, as we have systems that come and go, some that are always on the company network, and others that are almost never connected to the company network. Our goal is to allow clients to continue to communicate as they come and go. We've considered setting up an instance in the DMZ and configuring replication, but I think there's a better way to go about it.

Configure internal and external DNS entries for sep.company.com or similar. Those DNS entries will point to the internal address for SEPM for internal DNS and the external IP (to be NATed) for the external DNS entry. 8014 would be open for that one public IP. Clients would be left in push mode (is there a reason that pull is recommended for this?) as they should be able to reach the server as long as they have an internet connection; this would require a change in sylink for clients, which could be done remotely with other tools. None of the management and reporting ports would be open to the internet. Has anyone architected similar with success or gone about tackling this problem in a different way that they would recommend?

Once. Using both articles you've already linked. Had no issues with it.

Technically, what you are proposing would work, but it would be in breach of security best practices (i.e. exposing a device on the internal network to the internet, and sending device details and threat detection logs over the interwebs in clear-text).

With regard to push vs pull mode, push can generate a lot of traffic, which is why pull mode is is typically recommended.  I only ever see companies use push mode on systems that require immediate response to policy changes.

Hope this helps!

Thanks for the feedback, and agreed that it generally goes against best practices. Many other companies offer options to have your main in-network and a second, less-featured instance for the DMZ which is limited in functionality (no management interface, reads from the server on the inside, and sends back log data, but no more). It looks like there isn't such an option here with SEP. Looking for the best, most-secure way to do this. Any new openings increase our attack surface, and we'll have to look at whether or not the additional risk there is worth having clients which can communicate back at any time.

Is there a recommended way to do this? Or any insight into removing certain functionality from a replication partner? Looks like GUPs won't work as they'll only provide updates to clients, not collect logs as far as I can tell.

Hi David, I also have a same requirement where I need to manage remote users over the internet. 

I hope Symantec will come up like McAfee Agent handler equivalent to manage remote users over internet since many customers are now looking for this feature.

Currently, the recommended method is to follow the second of the articles you've already found (i.e. stick a second SEPM in the DMZ as a replication partner, and lock it down using SEP's System Lockdown, or with DCS:SA), and lockdown the FW ports (only allow agents comms port from internet to DMZ SEPM, and only allow replication ports from DMZ SEPM to Internal SEPM, etc. etc.)

Beyond this, I'd also recommend restricting the replication of SEPM logs so that it only flows from DMZ SEPM to internal SEPM.  This minimises the exposure of details of your estate, should the DMZ SEPM ever get breached.

Obviously, use HTTPS for agent comms as well (which is the default nowadays), and location awareness to ensure

• clients use the right (externally resolvable) name to contact the DMZ SEPM,
• to tell them to update directly from Symantec,
• and to apply more stringent securty policies (especially a tighter FW policy), ...

...when outside the corp network (http://www.symantec.com/docs/TECH97369)

However instead of the externally resolvable hostname if we use the public IP of the DMZ SEPM would it make any difference? 

Very nicely put in SML. I am impressed :)

All an externally resolvable name is going to resolve to, is an IP address anyway, so all good.  A public IP would work fine, if that's your preference.

At this point it's more a networking question than something specifically to do with SEP.  As long as the perimeter FW is configured for it, it'll work.