Endpoint Protection

Hey Everyone,

I have SEP and I have quite a few different DMZ arms. I'd like to use a single management console, however I can only really do that if the content and policy update proceses are on a "push" delivery method from the management console. I plan on using an individual GUP for each arm of my DMZ (each arm has a different subnet) which covers the content but the policies and informational updates are something I can't quite find any info on. I know that the policies come directly from the SEPM and do not proxy off the GUP. 

IIRC from SEP 11 these are the client related ports:

• 80 - Client-Manager Comm
• 443 - Client-Manager Comm
• 2967 - Something related to the Update Providers
• 8014 - Client-Manager Comm

What I am specifically looking for, is information relating to the direction of the communication initiation. For example, if the clients attempt to update policy via port 80, this would not work for my company's audit regulations as an untrusted zone would be initiating communication back into a trusted zone. In this instance I would most likely have to create a seperate SEP in the DMZ arm. 

So quick summary, I have three basic questions:

1. GUP activity: Do the GUPs intitiate requests to the SEPM for content? 
2. Policy Activity: Do the clients initiate requests to the SEPM for policy?
3. If the clients initiate all conversations, is there a way to specify that the SEPM pushes the policies and content instead of the clients requesting the push?

Thanks in advance.

1. The GUP will check in and SEPM will tell it there is new content, and will download it.

2. Depends. In push mode, clients maintain a connection to the SEPM, once a policy change is made, it will be pushed to client. In pull mode, clients will check in at random intervals. If a new policy is available, the client will grab.

3. You can either use push or pull mode. In Pull mode, clients will do the checking. In Push mode, SEPM will initiate the update. However, in Push mode the client maitains a constant connection so this could cause bandwidth issues.

See this:

How the client computers get policy updates

https://www.symantec.com/business/support/index?page=content&id=HOWTO80782

Thanks Beee-ry. Helpful per usual. 

Hi,

I would like to answer your questions.

1. GUP activity: Do the GUPs intitiate requests to the SEPM for content? 

--> Yes

2. Policy Activity: Do the clients initiate requests to the SEPM for policy?

--> As per the policy.

3. If the clients initiate all conversations, is there a way to specify that the SEPM pushes the policies and content instead of the clients requesting the push?

--> It's possible with push mode however pull mode is recommended if using GUP in the environment.

Hi,

the key concept is that we are talking about a server-clients architecture.
The server is the Manager and it is listening on port 80 or 8014, HTTP protocol (or 443, HTTPS), for requests from the clients.
The clients are the SEP agents, they always initiate the communication (this is the principle of server-clients communication model), it can't be in the other way since they do not listen on any port; the difference between push and pull mode is if that communication must be kept always established or closed and re-opened at regular intervals, in any case and in any configuration the clients need to initiate the communication to port 80 or 8014 (and port 2967 to use the GUP). Once the HTTP channel is open, standart GET and POST commands are used to transfer the data (logs, policies, updates, etc.).

The GUP is acting as a client for the SEPM and as a server (listesting on port 2967) for the other clients.

Please, find below further details:

1) GUP activity: Do the GUPs intitiate requests to the SEPM for content?

It works like that:
1. the client asks for the new content to the SEPM (via port 80 or 8014)
2. the SEPM answers "Yes, there's X but go to your GUP to get it" and it will prepare X for the GUP
3. the client goes to the GUP and asks for X (via port 2967)
4. if the GUP already has X, it is sent to the client
5. if the GUP does not have X, it will get it from the SEPM (via port 80 or 8014), hence go to 4.

2) Policy Activity: Do the clients initiate requests to the SEPM for policy?

As explained above, it can't be in other way.

3) If the clients initiate all conversations, is there a way to specify that the SEPM pushes the policies and content instead of the clients requesting the push?

As explained above, the SEPM can't initiate any communication with the clients.

So, if this kind of architecture is not considered safe for you, you may consider to make it safer by using HTTPS instead of HTTP for the cliets-server communication (443 instead of 80 or 8014):

Enabling SSL in SEP 12.1:http://www.symantec.com/docs/S:TECH162326
 

In push mode... once a policy change is made, it will be pushed to client.

Not entirely true, in a hairsplitting sort of way. Push is not a true push. The SEPM prompts the clients to check in within 1-2 seconds to get the new content or policy. The persistent connection means the clients can begin the heartbeat process that quickly.

Be it Push or Pull Mode, the actual heartbeat process is always initiated by the client.

sandra

This probably won't work for us then. I think the obvious solution is to place a SEPM with subnets that make up the arms of the DMZ. I am much more comfortable allowing the SEPM console to call out to the web for an update and allowing the SEPM console to directly communicate with the servers on it's subnet or at the same security context level. License management may be a bear, but as long as we purchase what we use, it should be ok.

Hi,

Is there any update on this? If issue is resolved then mark this thread as a solved.

As Sandra said, communications are always initiated by the client ("Thumbs Up" ), even in PUSH mode.

You might want to consider setting up an additional/replicated SEP Site within the DMZ to manage your DMZ endpoints.

While this will not resolve the issue of DMZ -> Internal network traffic in general, you will be able to restrict it to just the DMZ-SEPM to Internal-SEPMs (rather than DMZ endpoints connecting to Internal-SEPM), thus mitigating the risk.

Clearly, it's up to you if this is sufficient.  If you do want to pursue this route, I'd recommend taking a look-see at the below articles:

http://www.symantec.com/docs/TECH178325

http://www.symantec.com/docs/TECH122858

Yes, I am sorry. I have marked a solution and dealt with the issue. Thanks for your assistance.