Installation and Configuration Check Point Data Loss Prevention is a Software Blade. It needs connectivity to a Security Management Server and a SmartDashboard.
A Check Point gateway or a DLP-1 appliance is necessary for DLP. In a dedicated DLP gateway deployment, Check Point recommends that you have a protecting Security Gateway in front of the DLP gateway. The environment must include a DNS. Important - Before installing DLP, we recommend that you review the requirements and supported platforms for DLP in the.
Related Topics DLP Supported Platforms Before installing or configuring your DLP gateway, make sure that it agrees with the platform requirements for your deployment in the R76 Release Notes. Installing the DLP gateway For instructions on how to install and do the initial configuration of the DLP gateway, see the. DLP Software Blade Trial License The DLP Software Blade has a 30 day trial license. To activate the trial license:. Select the DLP Software Blade in SmartDashboard, in the gateway object. Install the policy on the DLP gateway. During the trial period, when you install a policy on the DLP gateway, a warning message shows how many days remain until the trial license expires.
After the trial period, you must install a full DLP Software Blade license. If you do not, the DLP Software Blade stops working, and a policy cannot be installed on the DLP gateway. You must unselect the DLP Software Blade, and then you can install a policy on the gateway.
If the Internal Mail Server is already defined as a Check Point network object, select it from the list. Otherwise, click New and define it as a Host. Configures the server to use. Description Manage Check Point system. - name of the Security Management Server - Date of the license.
SmartDashboard Toolbar You can use the SmartDashboard toolbar to do these actions: Icon Description Open the SmartDashboard menu. When instructed to select menu options, click this button to show the menu. For example, if you are instructed to select Manage Users and Administrators, click this button to open the Manage menu and then select the Users and Administrators option. Save current policy and all system objects. Open a policy package, which is a collection of Policies saved together with the same name. Refresh policy from the Security Management Server.
Open the Database Revision Control window. Change global properties. Verify Rule Base consistency. Install the policy on Security Gateways or VSX Gateways.
Open SmartConsoles. Configuring a DLP Gateway or Security Cluster You can enable the DLP Software Blade as one of the Software Blades on a Security Gateway. This is known as an integrated DLP deployment. In R75 and higher, you can also enable a DLP Software Blade on a ClusterXL in High Availability mode or Full High Availability mode on a UTM-1 appliance or 2012 Appliance models. In a dedicated DLP gateway, the Data Loss Prevention Software Blade is enabled on a gateway (or a ClusterXL Security Cluster) and no other Network Security Software Blade is enabled. Note - The DLP Software Blade (as a dedicated gateway or in an integrated Security Gateway) can work as part of a ClusterXL Load Sharing cluster only when the policy contains DLP rules that only use the. Other DLP actions are not supported for ClusterXL Load Sharing.
In version R75.20 and higher, you can also configure a ClusterXL High Availability cluster of dedicated DLP-1 appliances. Important - A dedicated DLP gateway does not enforce the Firewall Policy, Stateful Inspection, anti-spoofing or NAT. Check Point recommends that you place it behind a protecting Security Gateway or firewall. In a DLP gateway cluster, synchronization happens every two minutes. Therefore, if there is a failover, the new active member may not be aware of DLP incidents that happened in the two minutes since the failover.
To configure a DLP-1 appliance, see the DLP-1 Getting Started Guide. Configuring Integrated Deployments In an integrated deployment you can:. Enable the DLP blade on an existing Security Gateway or Security Cluster.
Configure a new Security Gateway or cluster and enable the DLP blade on it. To enable DLP on an existing Security Gateway or cluster:. Open SmartDashboard. Edit the Security Gateway or Security Cluster object. For a Security Cluster: In the ClusterXL page, select High Availability New mode or Load Sharing.
Note that you can use Load Sharing if the DLP rules only use the Detect action. In the General Properties page, in the Software Blades area, enable the Data Loss Prevention Software Blade. Note - On a Security Cluster, this enables the DLP blade on every cluster member.
The Data Loss Prevention Wizard opens. Complete the.
To configure a new DLP gateway or Security Cluster:. Open SmartDashboard. To configure a Security Gateway:. Open the General Properties page of the gateway. For a new gateway object only: Click Communication and initialize SIC. To configure a Security Cluster:.
Edit the Security Cluster object. Configure the Security Cluster. In the ClusterXL page, select High Availability New mode or Load Sharing. Note that you can use Load Sharing if the DLP rules only use the Detect action.
In the General Properties page, in the Platform area, select the Hardware, Version and OS. Make sure the selections comply with the platform requirements for your deployment in the R76 Release Notes.
In the Software Blades area, enable the Data Loss Prevention Software Blade. Note - On a Security Cluster, this enables the DLP blade on every cluster member. The Data Loss Prevention Wizard opens.
Complete the. Configuring Dedicated Deployments These are the configuration options in a dedicated deployment environment:. Dedicated DLP gateway or cluster on an existing Security Gateway or Security Cluster. Dedicated DLP gateway or cluster on a locally managed DLP-1 appliance. Dedicated DLP gateway or cluster on a centrally managed DLP-1 appliance. To configure a dedicated DLP gateway on an existing Security Gateway or Security Cluster:. Configure an existing Security Gateway or cluster as a DLP gateway or Security Cluster.
Deselect the Firewall Software Blade, if it is selected. When you clear the Firewall Software Blade, a warning message shows. You are about to turn off the Firewall blade, with only the DLP blade left on. Therefore, this Security Gateway will not enforce the security policy. It is recommended to place this Security Gateway behind a firewall.
Are you sure you want to continue? To configure a dedicated DLP gateway or cluster on a locally managed DLP-1 appliance:. Open SmartDashboard. For a locally managed gateway, the Data Loss Prevention Wizard opens.
For a locally managed cluster, the DLP-1 Cluster Wizard opens. Complete the. To configure a dedicated DLP gateway or cluster on a centrally managed DLP-1 appliance:. Open SmartDashboard on the Security Management Server that manages the DLP-1 appliance. Create a new DLP-1 Security Gateway or Security Cluster object from Network Objects Check Point DLP-1 Gateway or Cluster. Complete the wizard. DLP-1 Security Cluster Wizard Prerequisites Before you define a DLP Security Cluster:.
Make sure you have defined all of the network interfaces in use for each of the DLP-1 appliances. The interfaces must be defined within the same subnet. To make sure they are defined correctly, use the appliance WebUI. Make sure a cable is connected between the two SYNC ports on the appliances. It is not necessary to assign them IP addresses.
If you do assign IP addresses, make sure the SYNC interfaces use the same subnet. Make sure you have the activation key that was set for appliance defined as the secondary member during initial configuration.
This key is used to establish trust between the primary member and secondary member. Configuring a Locally Managed DLP-1 Security Cluster Use the Security Cluster wizard in SmartDashboard to create a cluster for two DLP-1 gateways. With the wizard you set the name of the cluster object, the name and IP address of the secondary cluster member and configure the topology for the gateways' interfaces. There is a Cluster Topology page for each of the network interfaces that have been configured for the cluster members. In this page you define whether a network interface participates in the cluster. If the interface is part of the cluster, you must define a virtual IP address for the cluster.
This IP address is visible to the network and makes sure that failover events are transparent to all hosts in the network. If the interface is not part of the cluster, the interface is a not-monitored private interface.
To configure a locally managed DLP-1 Security Cluster:. Log in to SmartDashboard using your Security Management credentials. The Security Cluster wizard opens.
Click Next. The Cluster General Properties page opens. Enter a name for the cluster. Click Next. The Cluster Secondary Member page opens.
In Secondary Member Name and Secondary Member IP Address, enter a name and the IP address of the appliance you configured as the secondary member. In Activation Key, enter the same activation key that was set for the secondary member in the configuration wizard and confirm it. The activation key is used by the primary member to establish initial trust with the secondary member. Once established, trust is based on security certificates.
To create a Security Cluster with only a primary member, select Define the Secondary Cluster member later. Click Next. The Cluster Topology page opens.
To set the interface to be part of the cluster, select Interface part of the cluster and enter a Virtual IP Address and Net Mask. If you do not want the interface to be part of the cluster, make sure the checkbox is cleared. Click Next.
Repeat steps 9-10 for each defined interface. In the Cluster Definition Wizard Complete page, click Finish. The Data Loss Prevention Wizard opens. Complete the. Data Loss Prevention Wizard DLP Blade Wizard Options. Email Domain in My Organization - Provide the domain of the organization, to allow the DLP gateway to distinguish between internal and external email addresses. Connect to Active Directory - Enable the DLP gateway to access the Active Directory server and automatically populate the users and user groups that make up the definition of My Organization and to validate users.
You can do this now or later. For instructions of how to do this, see. Activate DLP Portal for Self Incident Handling - Select to activate the port. The default URL is. Mail Relay - Select a mail server from the list of existing network objects, or click New and define a new mail server (SMTP). If the mail server requires the DLP gateway to authenticate itself, click the Authentication drop-down and provide the credentials of the mail server. If the Mail Server is a Microsoft Exchange server, set the Exchange server to be an SMTP Relay for this newly created DLP gateway.
My Organization Name - Enter different names and phrases used to identify your organization. These names are used by the DLP feature to accurately detect incidents of data loss. Protocols - Select protocols to which the DLP policy applies.
Completing the Wizard After you complete the wizard for a DLP gateway of any platform, enable the Software Blade and install the policy. Make sure that the Data Loss Prevention Software Blade is enabled. Review the topology of the DLP gateway. DLP by default scans traffic from internal networks to external networks, so you must properly define the DLP gateway interfaces as internal or external. You can do this when you define My Organization in the Data Loss Prevention tab of SmartDashboard.
Run Install Policy on the DLP gateway only:. From the menu of SmartDashboard, click Policy and select Install. In the Install Policy window, select the DLP Gateways.
On a dedicated DLP gateway, only the DLP Policy is installed. This is not a security policy. Make sure you have another Security Gateway in the environment to enforce the Security Policy. Configuring a DLP Gateway in Bridge Mode When setting up a dedicated DLP gateway, Check Point recommends that you configure the DLP gateway as a bridge, so that the DLP gateway is transparent to network routing. You can deploy DLP in bridge mode, with the requirements described in this section for routing, IP address, and VLAN trunks. Note the current limitations:. In an environment with more than one bridge interface, the DLP gateway must not see the same traffic twice on the different interfaces.
The traffic must not run from one bridged segment to another. Inter-bridge routing is not supported. This includes inter-VLAN routing.
If the bridge interface is connected to a VLAN trunk, all VLANs will be scanned by DLP. You cannot exclude specific VLANs. Routing from the bridge interface to a Layer3 interface, and from Layer3 interface to the bridge, is not supported. Traffic on the bridge interface must run through the bridge or be designated to the DLP gateway. From R76, the DLP gateway in bridge mode can be in a cluster, in High Availability mode. But the Ask User action and the UserCheck Agent are not supported. If the DLP gateway in bridge mode is behind a cluster, the cluster must be in High Availability mode.
Bond High Availability (HA) or Bond Load Sharing (LS) (including Link Aggregation) are not supported in combination with bridge interfaces. Required Routing in Bridge Mode There must be routes between the DLP gateway and the required servers:. Security Management Server. DNS server.
Mail server, if an SMTP Relay server is configured to work with the gateway. Active Directory or LDAP server, if configured to work with the gateway There must be a default route. If this is not a valid route, it must reach a server that answers ARP requests. If UserCheck is enabled, configure routing between the DLP gateway and the users network. Configuring Bridge IP Address The bridge interface can be configured without an IP address, if another interface is configured on the gateway that will be used to reach the UserCheck client and the DLP Portal. If you do add an IP address to the bridge interface after the Security Gateways are started, run the cpstop and cpstart commands to apply the change.
In Gaia, you must configure an IP address on the bridge interface. Required VLAN Trunk Interfaces.
A single bridge interface must be configured to bind the DLP gateway for a VLAN trunk. If an IP address is configured on the bridge, the IP address must not belong to any of the networks going through the bridge. Users must have routes that run traffic through the bridge interface of the DLP gateway. The gateway handles this traffic and answers to the same VLAN of the original traffic. In a VLAN trunk interface, another interface must be configured as the management interface for the required bridge routing. Configuring Active Directory and LDAP for DLP You can configure the DLP gateway to access a Microsoft Active Directory or LDAP server to:. Authenticate to the DLP Portal using Active Directory credentials.
Authenticate to UserCheck using Active Directory credentials. Define Active Directory or LDAP groups to be used in the DLP policy. Define the My Organization object If you run the wizard from a computer in the Active Directory domain, the Data Loss Prevention Wizard will ask for your Active Directory credentials to create the LDAP account unit automatically. To configure DLP to use Active Directory LDAP:. Create the DLP gateway object in SmartDashboard from a computer that is a member of the Active Directory domain. Enter your Active Directory credentials in the Active Directory page. You are not required to enter credentials with administrator privileges.
Turbo floor plan 3d home & landscape pro. We recommend that you create an Active Directory account that is dedicated for use by Check Point products to connect to Active Directory. When you complete the wizard, the LDAP account unit is created automatically. If you have multiple Active Directory servers:. Review the created account unit.
Remove unnecessary servers. Assign appropriate priorities to the remaining servers. The DLP Wizard will ask for Active Directory credentials only if no LDAP account unit exists. If you already have an LDAP account unit, the wizard will not ask for your credentials. To create the LDAP account unit from the DLP Wizard, delete the existing LDAP account unit and run the wizard again. Note - If you configure the LDAP Account Unit manually, with the username and password authentication method, you must set the Default Authentication Scheme to Check Point Password. If you need more LDAP account units, you can create the LDAP account unit manually.
Rerunning the Data Loss Prevention Wizard If you run the DLP Wizard from a computer that is not part of the Active Directory domain, you can run it again from a computer in the Active Directory domain to create the LDAP account unit. To run the Data Loss Prevention Wizard again:.
Open SmartDashboard. Edit the DLP gateway object.
In the General Properties page, deselect the Data Loss Prevention Software Blade. Select the Data Loss Prevention Software Blade. The Data Loss Prevention Wizard starts. Configuring a DLP Gateway for a Web Proxy You can use a Web Proxy server or servers for HTTP and HTTPS traffic.
If you want the DLP gateway to scan this traffic, you must configure the DLP gateway. Note - You can enable HTTPS Inspection on the gateway to scan. Configuring for a Web Proxy Use these procedures if the proxy or proxies are between the DLP gateway and the Internet, or in a DMZ. If a proxy is in a DMZ, we recommend that you use the DLP gateway to scan the HTTP traffic between the user network and the proxy in the DMZ. Configuring an R75 or higher DLP Gateway for Web Proxies If you have one Web proxy server between the DLP gateway and the Internet, use either Procedure 1 or Procedure 2. If you have more than one proxy between the DLP gateway and the Internet, use Procedure 2. If you configure both Procedure 1 and Procedure 2, the DLP gateway drops HTTP and HTTPS traffic sent to any web proxy that is not specified in Procedure 1.
Procedure 1. In SmartDashboard, edit the DLP gateway object and then open the Data Loss Prevention Protocols page. Select HTTP.
Either for the gateway, or on the default protocols. Select Use Proxy. In the Host IP field, enter the IP address of the Web proxy server. In the Port field, enter the listening port of the Web proxy server. DLP only scans traffic to the specified web proxy. Procedure 2.
In SmartDashboard, go to the Objects Tree and select the Services tab. Edit the TCP service: HTTPandHTTPSproxy.
Click Advanced. Select Protocol Type, and choose HTTP. In the DLP gateway object, select the Data Loss Prevention Protocols page. Select HTTP. Either for the gateway, or on the default protocols. Make sure that Use Proxy is not selected. Configuring a Pre-R75 DLP Gateway for a Web Proxy For a pre-R75 DLP gateway, if you have one Web proxy between the DLP gateway and the Internet, use Procedure 1.
If you have more than one Web proxy, put the DLP gateway between the proxies and the Internet. Configuring for an Internal Web Proxy If the DLP gateway is between the Web (HTTP) proxy server or servers and the Internet, use these procedures. Configuring the DLP Gateway for an Internal Web Proxy. In SmartDashboard, edit the DLP gateway object and open the Data Loss Prevention Protocols page. Select HTTP. Either for the gateway, or on the default protocols.
In the Data Loss Prevention tab, open the My Organization page. In the Networks section, make sure that the Web Proxy and the user networks are included in My Organization. Configuring the Proxy Server to Allow UserCheck Notifications If the DLP gateway is between the Web proxy server or servers and the Internet, all packets through the DLP gateway have the source IP address of the proxy server.
Therefore, the DLP gateway cannot know the real IP address of the client that opens the original connection to the proxy server. This means that the DLP gateway cannot identify the user, and therefore cannot:.
Send UserCheck client notifications to users about incidents. Log the source IP address of the user.
To make it possible for the DLP gateway to identify the user, you must configure the proxy server to reveal the IP address of the client. The proxy server does this by adding the x-forwarded-for header to the HTTP header. For details, see the proxy server vendor documentation. Configuring Proxy Settings After Management Upgrade For a Security Management server that is upgraded from R70 and lower, traffic that passes through a DLP gateway to a web proxy server contains the gateway's IP as the source address instead of the original client IP address. For new installations and for installations that were upgraded from R71, the original client IP address is used. If the traffic that contains the gateway's IP as source address reaches another Security Gateway which either logs traffic or enforces access based on identity, the source IP address does not represent the user's IP address.
To use the client's IP address as source address for the traffic leaving the DLP gateway:. On the SmartDashboard computer, run: C: Program Files CheckPoint SmartConsole R76 PROGRAM GuiDBedit.exe. Log in with your SmartDashboard credentials. In the left pane, select Table Network Objects networkobjects. In the right pane, select the DLP Gateway. In the bottom pane, in the Field Name column, select firewallsettings.
Change the httpunfoldproxyconns attribute to true. Mail Server Required Configuration DLP rules have different action settings. Action Description Detect The data transmission event is logged in SmartView Tracker. Administrators with permission can view the data that was sent. The traffic is passed. Inform User The transmission is passed, but the incident is logged and the user is notified. Ask User The transmission is held until the user verifies that it should be sent.
A notification, usually with a remediation link to the Self Incident Handling portal, is sent to the user. The user decides whether the transmission should be completed or not. The decision is logged and can be viewed under the User Actions category in SmartView Tracker.
Administrators that have full permissions or the View/Release/Discard DLP messages permission can also decide if to send or discard the message. Prevent The data transmission is blocked. Watermark Tracks outgoing Microsoft Office documents (Word, Excel, or PowerPoint files from Office 2007 and higher) by adding visible watermarks or invisible encrypted text. When you set Data Owners to be notified, a mail server becomes a required component of the DLP system. The DLP gateway sends mail notifications to users and Data Owners, therefore it is necessary for the gateway to access the mail server as a client. Important -. The mail server must be set to act as a mail relay.
This lets users or administrators with permissions to release (Send) emails that DLP captured and quarantined on Ask User rules. You must configure the mail server to trust anonymous SMTP connections from the DLP gateway. Alternatively, if your environment requires it, configure your mail relay server to trust authenticated SMTP connections from the DLP gateway. Configuring the Mail Relay Configuring the Mail Relay for Anonymous SMTP Connections. In SmartDashboard: Configure the mail server without authentication in the Data Loss Prevention Wizard.
Alternatively:. In the Data Loss Prevention tab, expand Additional Settings and click Mail Server. Select Send emails using this mail server.
Select the mail server. If the mail server object does not exist, create it. On the mail server itself: Configure the mail relay to accept anonymous connections from the DLP gateway.
For details, consult the vendor documentation. For example, on Microsoft Exchange Servers, configure the permissions of the default receive connector (or other relevant connector that handles SMTP traffic) for anonymous users. Configuring the Mail Server object for Authenticated SMTP Connections. In SmartDashboard: Configure the mail server with authentication in the Data Loss Prevention Wizard. Alternatively: In the Data Loss Prevention tab, expand Additional Settings and select Mail Server.
Select Send emails using this mail server. Select a mail server from the list.
If the mail server does not exist, create it. Click Mail Servers. Select the server from the list. Select Server Requires Authentication.
Enter the authentication credentials: user name and password. On the mail server itself: Configure the mail server to accept authenticated connections from the DLP gateway. For details, consult the vendor documentation. For example, on Microsoft Exchange Servers, configure the default receive connector (or other relevant connector that handles SMTP traffic) for basic authentication. Configuring a Dedicated DLP gateway and Relay on DMZ A specific configuration is required for a dedicated DLP gateway if these are all true:.
The DLP gateway and the mail relay that handles SMTP traffic leaving the organization are in the DMZ zone. Use of this mail relay is one of the following:. There is a mail server inside the internal network, such as Exchange, that relays its outgoing SMTP traffic through the mail relay. Users email clients are configured to work directly with the mail relay. The DLP Policy works only on SMTP.
If this is true, configure the DLP gateway to recognize the mail server as internal to My Organization and the relay in the DMZ as external. To configure the DLP and Relay in the DMZ:. Open the Data Loss Prevention tab in SmartDashboard. Open My Organization. In the Networks area, select These networks and hosts only and click Edit. The Networks and Hosts window opens.
If the Internal Mail Server is already defined as a Check Point network object, select it from the list. Otherwise, click New and define it as a Host. Repeat steps to add other Internal Mail Servers. If users email clients are configured to work directly with the mail relay that is located in the DMZ using SMTP, add their networks.
Select user networks from the list (or click New to define these networks) and then click OK. Run Install Policy on the DLP gateway. Recommended Deployment - DLP Gateway with Mail Relay In the recommended deployment of a DLP gateway with a mail relay, the DLP gateway scans mails once, as they are sent from an internal mail server (such as Microsoft Exchange) (1) to a mail relay in the DMZ (2). Make sure that the DLP gateway does not scan mails as they pass from the mail relay to the target mail server in the Internet. If you can deploy the internal mail relay behind a DMZ interface of the DLP gateway:.
Ensure that mails from the internal mail server (e.g. Microsoft Exchange) (1) arrive at the gateway via an internal Gateway interface: In the Topology page of the DLP gateway object, define the gateway interface that leads to the internal mail server as Internal. Deploy the internal mail relay (2) behind a DMZ interface of the DLP gateway: In the Topology page of the DLP gateway object, define the gateway interface that leads to the Mail relay as I nternal and also as Interface leads to DMZ. In the Networks section of the My Organization page:. Select Anything behind the internal interfaces of my DLP gateways. Do not select Anything behind interfaces which are marked as leading to the DMZ If you cannot deploy the internal mail relay behind a DMZ interface of the DLP gateway: If the DLP gateway interface leading to the internal mail relay is internal, and you cannot deploy the internal mail relay behind a DMZ interface of the DLP gateway:. In the Networks section of the My Organization page, select These networks and hosts only.
Select the networks that include the internal mail server, but not including the relay server. Workarounds for a Non-Recommended Mail Relay Deployment A non-recommended deployment is to have the DLP gateway scan mails as they are sent from an internal mail relay that is in My Organization to the target mail server in the Internet. In this deployment, the DLP gateway communicates with the target mail servers on behalf of the mail relay.
No Valid License Found Cubase
If the target mail server does not respond, some mail relays (such Mcafee IronMail, postfix 2.0 or earlier and qmail) will not try the next DNS MX record, and so will not try to resend the mail to another SMTP mail server in the same domain. The internal mail server (1) and the internal relay (2) are in My Organization. The internal mail server (1)(2) is in My Organization, and there is no other internal mail relay Why Some Mail Relays Will Not Resend Emails If the mail relay does not succeed in sending an email because the target mail server does not respond, the mail relay resends the email to another SMTP server in the same domain. The relay does this by sending the mail to the next DNS MX record. Most mail relays try the next MX record if the target is unreachable, or if the target server returns a 4xx SMTP error. However, other mail relays (such as Mcafee IronMail, postfix 2.0 or earlier and qmail) do not try the next MX if the target server returns a 4xx error. They will therefore not send the mail.
In these deployments, the DLP gateway communicates with mail servers in the internet on behalf of the mail relay. If the target mail server does not respond, the DLP gateway sends a 4xx response to the mail relay in behalf of the mail server. Therefore, if your mail relay does not try the next MX when the target server returns a 4xx error, the mail will not be sent. Workarounds for the Non-Recommended Deployments. Configure your internal mail relay to re-send when it receives a 4xx error from the target mail server.
If you cannot configure your mail relay in this way, deploy the DLP gateway between two internal mail servers. For example, put the. If you cannot apply these workarounds, see. Untrusted Mail Relays and Microsoft Outlook If Outlook does not trust the mail relay server, it fails to correctly render the Send and Discard buttons in the violation notification email. The buttons render correctly only after the mail relay is trusted and a new email sent.
To avoid this issue, instruct users to add the mail relay address to Outlook's safe senders list. TLS-Encrypted SMTP Connections TLS-encrypted SMTP connections are not scanned by the DLP Software Blade. If an Exchange Server uses TLS to encrypt emails, you can use the to inspect them. Configuring Incident Log Handling In version R75 and higher, DLP incident data is stored on the remote log server or Security Management Server that stores the DLP gateway logs. DLP incidents are only stored permanently (that is, until they expire) on the DLP gateway if no log server or Security Management Server is configured for the DLP gateway. Incidents are stored at $FWDIR log blob.
Because DLP incident data is stored on the log server, Check Point recommends that you tune your log server disk management setting for DLP incidents. To configure disk management for DLP incidents:. In SmartDashboard, edit the Log server or Security Management Server that manages DLP logs. In the Logs and Masters page, select Required Free Disk Space and enter a value. This setting applies to DLP incidents and logs, and to all other logs. The default setting is 45 MBytes or 15%. When the free disk space becomes less than this limit, old DLP incidents and logs, and other logs are deleted to free up disk space.
Open GuiDBedit:. On the SmartDashboard computer, run C: Program Files CheckPoint SmartConsole R76 PROGRAM GuiDBedit.exe.
Log in with your SmartDashboard credentials. In the left pane, select Table Network Objects networkobjects. In the right pane, select the Log server or Security Management Server that manages DLP logs.
In the bottom pane, in the Field Name column, find logpolicy. Configure these fields: Field Name Description Default value dlpblobdeleteabovevaluepercentage The maximum% of disk space that incidents are allowed to occupy. 20% dlpblobdeleteonabove Whether or not to delete incidents if the incidents take up more disk space than dlpblobdeleteabovevaluepercentage. true — Delete incidents. However, logs that are associated with the incidents are not deleted.
false —Do not delete incidents. Incidents are only deleted if free disk space becomes less than the Required Free Disk Space that is configured in SmartDashboard, in the Logs and Masters page of the Log server or Security Management Server that manages DLP logs.
False dlpblobdeleteonrunscript Whether or not to run a script before deleting incidents. For example, to copy the logs to a different computer before they are deleted. true — Run the script that is defined in SmartDashboard, in the or Security Management Server that manages DLP logs, in the Logs and Masters Advanced page. false — Do not run a script. False Configuring the Exchange Security Agent Internal emails between Microsoft Exchange clients use a proprietary protocol for Exchange communication.
This protocol is not supported by the DLP gateway. To scan internal emails between Microsoft Exchange clients, you must install an Exchange Security Agent on the Exchange Server. The agent sends emails to the DLP gateway for inspection using the SMTP protocol encrypted with TLS. This requires connectivity between the Exchange server and the DLP gateway. An Exchange Security Agent must be installed on each Exchange Server that passes traffic to the DLP gateway. Each agent is centrally managed through SmartDashboard and can only send emails to one DLP gateway. If your organization uses Exchange servers for all of its emails, you can also use this setup for scanning all emails.
To use the Exchange Security Agent it is necessary to configure settings in SmartDashboard and on the Exchange server. For more about using the Exchange Security Agent to examine internal emails, see some.
SmartDashboard Configuration SmartDashboard configuration includes:. Defining the Exchange Security Agent object in SmartDashboard. Using a wizard to:. Set a one-time password that will be used to initiate trusted communication between the DLP gateway and the Exchange Security Agent.
Set the users/groups for which to send emails. Preparing and installing the securing policy. To define the Exchange Security Agent:. In SmartDashboard, open the Data Loss Prevention tab.
Click Gateways. Click New Exchange Agent.
The Check Point Exchange Agent wizard opens. Click Next. There are four pages in the wizard:. General. Trusted Communication. Inspection Scope. Configuration Summary Exchange Security Agent - General Use the General page to enter information for the Exchange Security Agent.
Name - Enter a name for the Exchange Security Agent. Inspected Exchange Server - Select the host object that represents the Exchange server on which the Exchange Security Agent is installed. If necessary, click New to create one. Exchange contact person (optional) - You can select the user object that represents the Exchange server administrator. Enforcing DLP gateway - Select the DLP gateway object that the Exchange Security Agent will send emails to for inspection.
If you use a name to represent the DLP gateway in the Exchange Security Agent on the Exchange server, make sure to use the same name as this object. Exchange Security Agent - Trusted Communication Use the Trusted Communication page to enter the one-time password used to initialize SIC (Secure Internal Communication) between the Exchange Security Agent and the enforcing DLP gateway. This step creates a security certificate that is then used by the Exchange Security Agent.
One-time password - Enter the one-time password and confirm it. Make sure that the same one-time password is entered in the Trusted Communication window of the Exchange Security Agent snap-in on the Exchange server. Exchange Security Agent - Inspection Scope Use the Inspection Scope window to define which emails to send for inspection. You can select all users or only specified users or user groups.
It is recommended to start with specified users or user groups before inspecting all emails. Inspect emails sent only by these users or user groups - Define the Active directory, internal or LDAP users whose emails will be inspected. Note - You can define users or groups for whom emails will not be sent for inspection in an Exceptions list. You can also set a percentage of emails to inspect for the rest of the organization.
This lets you gradually increase the inspection coverage of your organization's emails. To define these options, edit the Exchange Security Agent in SmartDashboard and open the Inspection Scope page.
Inspect all emails - All emails will be sent from the Exchange Security Agent to the enforcing DLP gateway for inspection. Exchange Security Agent - Configuration Summary The Exchange Agent Wizard is Completed window opens. The next steps include:. Installing the policy on the DLP gateway.
Installing and configuring the Exchange Security Agent on the Exchange server. You can download the MSI for installing the agent from this window. Exchange Server Configuration After the Exchange Security Agent has been installed on the Exchange server, you must:. Initialize trusted communication between the Check Point Exchange Security Agent and the Security Gateway. Start or stop the Exchange Security Agent that runs as an extension of the Microsoft Exchange Transport service.
See Exchange Security Agent statistics. Monitor message status with the Message Tracking log.
Configure when to bypass inspection of messages. Initializing Trusted Communication There are two possible communication states:. Uninitialized is where trusted communication has not been established.
Trust established is where the Exchange Security Agent has received the security certificate and can receive data securely from the Security Gateway. To initialize trusted communication:.
On the Exchange server, open the Exchange Security Agent: Start Check Point Check Point Exchange Agent Configure Check Point Exchange Agent. In the Navigation pane, click Check Point Exchange Agent. Click Communication. The Trusted Communication window opens. Enter information in these fields:.
Gateway name or IP - The same name or IP that is given to the DLP Security Gateway in SmartDashboard. Exchange agent object name - The same name that is set for the Exchange agent object in SmartDashboard. One time password - Used only for establishing the initial trust. When trust is established, trust is based on security certificates. This password must be the same as the one time password defined for the Exchange Security Agent in SmartDashboard. Click Initialize to start the trusted communication procedure.
Starting the Exchange Security Agent The Exchange Security Agent runs as an extension of the Microsoft Exchange Transport service. When you start or stop the agent. Each time you start or stop the agent, you restart the Microsoft Exchange Transport service.
After you click Start, messages are sent to the Security Gateway for DLP inspection. The messages sent are based on the users or groups. To start the Exchange Security Agent:. In the Check Point Exchange Agent window, click Start. Statistics The Statistics page in the Exchange Security Agent shows performance statistics and the number of emails it handles and sends to the Security Gateway.
The graph you see in the window is the Windows Performance Monitor graph. It shows some of the Windows counters plus the CPExchangeAgent counters. Alternatively, you can use the Windows Performance Monitor and add the CPExchangeAgent counters. Statistics shown:.
Latency per any message - The average latency in seconds of all email messages that go through the Exchange Security Agent. Latency per scanned message - The average latency in seconds of all email messages that go through the Exchange Security Agent and are then sent to the Security Gateway for inspection. Message queue length - Then number of emails that are currently being handled by the Exchange Security Agent. Total messages - Total number of emails handled by the Exchange Security Agent. Scanned messages - Total number of emails inspected by the DLP policy (includes dropped and allowed messages).
Dropped messages - Emails dropped after being inspected by the DLP policy. Message Tracking In the Message Tracking window you can see logs for each message that goes through the Exchange Security Agent.
You can do a search on all of the fields in the log and refresh the log. You can see these values in the Event Id column:. Receive - The message has been received by the Exchange Security Agent. The Reason column for this entry is always blank.
Release - The message has been inspected by DLP and has been sent to its destination. Drop - The message has been dropped by DLP and has not been sent to its destination. Bypass - The Exchange Security Agent has not sent the message to DLP for inspection.
The message is sent to its destination. This table describes the possible reasons for each of the event IDs. Event ID Reason Receive Empty - indicates that the message is being handled by the Exchange Security Agent Release Tap mode - when all of the rules in the Rule Base are detect or inform, the Exchange Security Agent automatically sends the message to its destination.
. Make sure that the Security Management server is running and the client is able to communicate with the Security Management server, either trace route or ping the interface. If they cannot, then there is a communication issue that needs to be addressed, such as routing issue or there is a Firewall installed on the Security Management server (this would be true if it is a standalone configuration). See if the user can SSH into the Security Management server or a do a remote session to the Windows box running the Security Management server. If there should not be a Firewall and Security Management server, check for the FWD process in Windows Task Manager. Above is an Image of a Windows Security Management server with CP Firewall installed - FWD is the firewall daemon. If the Security Management server is a standalone box, run fw unloadlocal (this command can be run on Windows, Linux and SecurePlatform), this will remove the local policy if a firewall is installed on the Security Management server.
If there is no firewall installed, it will say 'Local host is not a Firewall -1 module' If everything is OK, move to step 2. Run cpconfig on the Security Management server, either through SSH connection or through command line from Windows. Check the GUI clients list. See if the clients IP address is listed or if the word 'any' is used. Also check and see if the Admin account being used is listed under admins list. Remove and recreate the Admin account or reset its password. If all of this seems good, move step 3.
Use the output of top to check the CPU usage of the fwm process. Take note of fwm's PID. If CPU is 100, fwm may stall out. Consider killing and restarting the process. # top. # kill -9. # cpstart.
Backup and remove the following files from $FWDIR/conf or C: windows fw1 version fw1 conf:. applications.C. applications.C.backup. CPMILinksMgr.db. CPMILinksMgr.db.private After the files are backed up and removed, run a cpstop and then cpstart. Try to connect to the Security Management server. If the same problem occurs move to step 5.
It is possible that the GUI clients file is corrupted. On the Security Management server, look for a file called gui-clients (located in $FWDIR/conf or C:/windows/fw1/version/fw1/conf) Once you find the file, run cpstop, backup and then remove the gui-clients file. Run cpstart on the box. Run cpconfig and add new clients or the word 'any' to the GUI clients list If this does not work, go to step 6.
Verify that the FWM or CPD process is up and running. On Windows, check the Task Manager for FWM.exe and CPD.exe On SecurePlatform run ps -aux to view the active process. Also for SecurePlatform and Windows you can run cpwdadmin list, it shows the process started by Watchdog and how many times process was started and if it has been terminated. CMD from Windows: Command ran on SecurePlatform: If the FWM or CPD is not running, debugging will be needed. Run FWM -d or CPD -d and examine the info.
That is presented when attempting to force the FWM to start. If the FWM process is running, move to step 7. When the client tries to connect, if the connection error pops up instantly then the issue will be with the SIC certificate for the SmartDashboard on the Security Management server. Confirm that the SIC certificate is still valid. On the Security Management Server run the cpcaclient lscert -stat Valid -kind SIC command. If it does not show a certificate for ' CN=cpmgmt.'
Proceed with the steps below. In this case you need to revoke the client's certificate Procedure for revoking and creating new certificate to the Security Management server:. Switch directories by running cd $CPDIR/conf or for Windows, C:/program files/checkpoint/cpshared/Rxx/conf. Backup and then remove the siccert.p12 file.
Run: cp siccert.p12 siccert.p12old and then run: rm siccert.p12. Run the following command to revoke the certificate from the Security Management server Objects file: cpcaclient revokecert -n 'CN=cpmgmt'. Recreate a brand new SIC certificate for the Security Management server: cpcaclient createcert -n 'CN=cpmgmt' -f siccert.p12. Once the new certificate is created run: cpstop; cpstart. Try to connect to the Security Management server.
If an issue still occurs move to step 8.