Video Screencast Help

DLP Enforce and Detection servers limits

Created: 26 Jul 2012 • Updated: 28 Dec 2012 | 6 comments
Atif's picture
This issue has been solved. See solution.

Hi guys,

I need to know operational limit for the following.

1. What is the operational limit of DLP Enforce server. How many detection servers can it manage with single instance?

2. How many endpoints endpoint detection server handles?

3. How many scan targets a network discover and protect can manage?

4. How much volume of HTTP and SMTP respective Network Prevent can handle?

5. What is the traffic limit for one Network Monitor in Mbps?

Regards.

Discussion Filed Under:

Comments 6 CommentsJump to latest comment

stumunro's picture

Atif,

 

I am not sure if there is a hard number alot of it depends on the hardware speccs you have. If you look at the network sizing guide which i have attached it gives you guides lines. Also if you are talking faster networks with thru put you will prbally need endace cards. I know it has been discuassed here having multiple enforce servers but due to the DB setuup I believe this is not possible. If you want to send me a message i can go over more with you. I can say i have had success virtualizing the whole DLP enviroment except for network monitor, and they want to p2v that once they have a 10 gig infrastructure in place with the upgraded vmware.

 

 

AttachmentSize
Symantec_DLP_11.5_Network_Sizing_Guide.pdf 417.39 KB
ensweiler's picture

I believe Symantec is moving away from Endace, after DLP 11 support for 32 bit will not exist therefore Endance isn't a good long term solution.

stumunro's picture

satif

 

sorry let me also add it depends on linux vs windows and the native capture with out spending the money for endace, the sizing guide will go over all of that.

cemilebaşak's picture

Hi;

 

Problem Summary
 
  What is the maximum bandwidth that a DLP Network Monitor can manage?

 

 

Solution
 
 

The maximum amount of filtered traffic that a Network Monitor can handle is 40 Mbps.  This is a limitation on the FileReader.  We can handle higher amounts of traffic earlier in the process. 

The maximum incoming traffic is dependent on whether a NIC, Endace Card or a NIC with Linux Kernel tuning is being used.  The NIC itself can only handle the amount that the Packet Capture process can, which is 80 Mbps.  Beyond that, an Endace Card or  the Linux Kernel tuning is required.  With these, the amount of filtered traffic can not exceed 80 Mbps. 

PacketCapture is the process that takes the packets and reassembles them into a message.  It can handle about 80 Mbps total.  This is not per NIC, but the total traffic coming in from all NICs selected for capture.  If there is more than 80 Mbps, the Monitor will be dropping packets.  Those messages with dropped packets will not be processed.

The network monitor FileReader is our Detection process, which determines whether a violation occurred or not, and whether an incident needs to be created.  It can handle a maximum of about 40 Mbps of filtered traffic. That is the amount of traffic after PacketCapture has dropped all traffic that has not been selected for capture. If there is more than 40 Mbps, there will be long message wait times, but we will process messages at this point.

 

Adding a faster CPU does not speed the FileReader.

Taken from kb: https://kb-vontu.altiris.com/display/1/kb/article.asp?aid=50068&n=12&s=

 

 

 

Regards;

Cemile Denerel BAŞAK

Note: Please mark as solution if its help you.

SOLUTION
cemilebaşak's picture

 

Problem Summary
 
 

I am trying to figure out how many Endpoint Agents can connect to an Endpoint Server.  What are the factors involved?

 

 

Solution
 
 

The Endpoint Server keeps a persistent connection to the Endpoint Agent.  When there is too much traffic between the Endpoint Agents and the Endpoint Server, the Aggregator process on the Endpoint Server gets overwhelmed and communication failures can occur.  The more traffic between the Endpoint Agent and Endpoint Server, the fewer Endpoint Agents the Endpoint Server can handle.

The traffic is created by many different types of messages.  Some of these include:

Pushing policies to the agents.  When policies are pushed out, they are pushed to all the agents at the same time.  This is for a short time, but if the Aggregator is near saturation, this can be an issue. 
When Policies are Pushed out to the Endpoint Agent

Large numbers of incidents.  If policies are too vague and create large numbers of incidents, this will cause a large number of messages to be created.  Too many incidents are hard to remediate, so best to tune policies for fewer incidents.

Retaining Original Message.  All incidents will send the original message, this will increase the message size being sent to the Endpoint Server. Retaining Original Message on Endpoint Incident

IDM/EDM Policies - Indexed documents are evaluated on the Server, therefore all messages being evaluated will be sent to the server. Recommend to create a short circuit for any IDM/EDM policy using a Data Identifier or keyword.
Issues with running Endpoint that includes EDM/IDM policies

eDAR - Discover scan requests on the Endpoint are sent to every Endpoint Agent, even if filters are in place to limit the number of agents.  In that case, the request for the scan comes, the Endpoint Agent evaluates the request, sees that it is not included, and sends a completed message back to the server.
Also, Discover scans scan a large number of files, so the number of incidents may be greater than with Endpoint Prevent.

eDAR with IDM/EDM. For the reasons listed above, eDAR with Indexed Documents will cause all scanned files to be sent to the server.  A short circuit is required for this case.

Endpoint Server on VMWare - VMWare ESX 4.0 is supported on DLP 11.0 and above.  However, the Endpoint Server can handle half as many Endpoint Agents on VMWare as on Hardware.  See system requirements guide for more information.

 

Regards;

Cemile Denerel BAŞAK

Note: Please mark as solution if its help you.

Atif's picture

Wow... Glad to see so many useful responses here. Really appreciate all of you friends.

These explanations are good to have sizing done on any scale.