|
|
|
In This Section: |
Check Point Data Loss Prevention is a Software Blade. It needs connectivity to a Security Management Server and a SmartConsole. A Check Point gateway or a DLP-1 appliance is necessary for DLP.
Best Practice - 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 R80.10 Release Notes.
|
|
|
For instructions on how to install and do the initial configuration of the DLP gateway, see the R80.10 Installation and Upgrade Guide.
The DLP Software Blade has a 30 day trial license.
To activate the trial license:
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.
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 use the Detect, Inform, or Prevent actions. The Ask DLP action is 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.
In an integrated deployment you can:
To enable DLP on an existing Security Gateway or cluster:
The gateway window opens and shows the General Properties page.
You can use Load Sharing if the DLP rules use the Detect, Prevent, or Inform actions.
Note - On a Security Cluster, this enables the DLP blade on every cluster member.
The Data Loss Prevention Wizard opens.
These are the configuration options in a dedicated deployment environment:
To configure a dedicated DLP gateway on an existing Security Gateway or Security Cluster:
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:
For a locally managed gateway, the Data Loss Prevention Wizard opens.
For a locally managed cluster, the DLP-1 Cluster Wizard opens.
To configure a dedicated DLP gateway or cluster on a centrally managed DLP-1 appliance:
Before you define a DLP Security Cluster:
Use the Security Cluster wizard in SmartConsole 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:
The Security Cluster wizard opens.
The Cluster General Properties page opens.
The Cluster Secondary Member page opens.
The Cluster Topology page opens.
The Data Loss Prevention Wizard opens.
If the Mail Server is a Microsoft Exchange server, set the Exchange server to be an SMTP Relay for this newly created DLP gateway.
After you complete the wizard for a DLP gateway of any platform, enable the Software Blade and Install Policy.
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 SmartConsole.
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.
Best Practice - When you set 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:
There must be routes between the DLP gateway and the required servers:
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 network.
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 cpstart
You can configure the DLP gateway to access a Microsoft Active Directory or LDAP server to:
If you run the wizard from a computer in the Active Directory domain, the Data Loss Prevention Wizard asks for your Active Directory credentials to create the LDAP account unit automatically. You can run the wizard again from a computer in the Active Directory domain to create the LDAP account unit.
To configure DLP to use Active Directory LDAP:
You are not required to enter credentials with administrator privileges.
Best Practice - Create an Active Directory account that is dedicated for use by Check Point products to connect to Active Directory.
If you have multiple Active Directory servers:
The DLP Wizard asks for Active Directory credentials only if no LDAP account unit exists. If you already have an LDAP account unit, the wizard does 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. See the R80.10 Security Management Administration Guide.
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:
The gateway window opens and shows the General Properties page.
The Data Loss Prevention Wizard starts.
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 HTTPS connections.
Use these procedures if the proxy or proxies are between the DLP gateway and the Internet, or in a DMZ.
Best Practice - If a proxy is in a DMZ, 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.
To configure DLP for Procedure 1:
The gateway window opens and shows the General Properties page.
DLP only scans traffic to the specified web proxy.
Procedure 2
The gateway window opens and shows the General Properties page.
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.
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
SmartConsole opens and shows the DLP tab.
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:
C:\Program Files\CheckPoint\SmartConsole\R80.10\PROGRAM\GuiDBedit.exe
http_unfold_proxy_connstrueDLP rules have different action settings.
Action |
Description |
|---|---|
Detect |
The data transmission event is logged in the Logs & Monitor view. 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 Response category in a log entry. Administrators with full permissions or the View, Release, or Discard DLP messages permission can 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 -
You can use the Data Loss Prevention Wizard to configure the settings for the mail relay. Use these procedures to configure these settings without the Wizard.
To open the DLP tab in SmartDashboard:
SmartConsole opens and shows the DLP tab.
To configure the mail relay for anonymous SMTP connections:
If the mail server object does not exist, create it.
To configure the mail server object for authenticated SMTP connections:
The Mail Server window opens.
To complete configuring the Mail Relay:
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.
To configure the DLP and mail relay in the DMZ:
SmartConsole opens and shows the DLP tab.
The Networks and Hosts window opens.
Otherwise, click New > Host.
Item |
Description |
|---|---|
1 |
Internal mail server |
2 |
DLP gateway |
3 |
Mail relay in the DMZ |
Make sure that the DLP gateway does NOT scan emails as they pass from the mail relay to the target mail server in the Internet.
To deploy the internal mail relay behind a DMZ interface of the DLP gateway:
The gateway window opens and shows the General Properties page.
In the Topology page of the DLP gateway object, define the gateway interface that leads to the Mail relay as Internal and also as Interface leads to DMZ.
To configure the internal mail relay that is not behind a DMZ interface of the DLP gateway:
Note - 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.
SmartDashboard opens and shows the DLP tab.
A non-recommended deployment is to have the DLP gateway scan emails 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. 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 email to another SMTP mail server in the same domain.
Item |
Description |
|---|---|
1 |
Internal mail server |
2 |
Internal mail relay |
3 |
DLP gateway |
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 email.
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 email will not be sent.
Workarounds for the Non-Recommended Deployments
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 are not scanned by the DLP Software Blade. If an Exchange Server uses TLS to encrypt emails, you can use the Exchange Security Agent to inspect them.
To configure disk management for DLP incidents:
The server window opens and shows the General Properties page.
This setting applies to DLP incidents and logs, and to all other logs. The default setting is 5000 MBytes. 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.
C:\Program Files\CheckPoint\SmartConsole\R80.10\PROGRAM\GuiDBedit.exe Field Name |
Description |
Default value |
|---|---|---|
|
The maximum % of disk space that incidents are allowed to occupy. |
20% |
|
Whether or not to delete incidents if the incidents take up more disk space than
|
|
|
Whether or not to run a script before deleting incidents. For example, to copy the logs to a different computer before they are deleted.
|
|
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 SmartConsole 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 SmartConsole and on the Exchange server.
For more about using the Exchange Security Agent to examine internal emails, see some scenarios.
To define the Exchange Security Agent:
SmartDashboard opens and shows the DLP tab.
The Check Point Exchange Agent wizard opens.
Use the General page to enter information for the Exchange Security Agent.
Click Next.
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.
Click Next.
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.
|
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 SmartConsole 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.
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 SmartConsole and open the Inspection Scope page.
Click Next.
The Exchange Agent Wizard is Completed window opens.
The next steps include:
To install the Exchange Security Agent:
After the Exchange Security Agent has been installed on the Exchange server, you can:
There are two possible communication states:
To initialize trusted communication:
The Trusted Communication window opens.
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 defined for inspection.
To start the Exchange Security Agent:
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:
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:
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. The agent does not receive a response from the Security Gateway |
Scanned by gateway |
|
Timeout |
|
Drop |
Dropped by gateway - after Security Gateway inspection the message matched an ask or prevent rule |
Bypass
|
DLP scanning is disabled - when DLP inspection is not enabled on the Security Gateway |
Fail open active - if one of the bypass settings in the Advanced window is matched |
|
Message is too big |
|
Incoming message scanning is disabled |
|
Internal message scanning is disabled |
|
Incoming message scanning from other domains is disabled |
|
Sender is included in the Inspection Scope exceptions |
|
Sender is not included in Inspection Scope settings |
In the Advanced window you can configure log parameters and when not to send emails to the Security Gateway for DLP inspection.
The available options:
Email inspection is bypassed in these situations:
In Mirror Port Mode, the DLP gateway scans SMTP and HTTP traffic for possible violations. The DLP gateway connects to the SPAN port of a switch and monitors traffic without enforcing a policy. Mirror Port Mode lets you run a full data leak assessment of all outgoing SMTP/HTTP traffic with minimal deployment risk.
When the DLP Security Gateway is connected to a SPAN port of the switch, the gateway gets a copy of all packets passing through the switch. The DLP tap mechanism builds TCP streams of SMTP and HTTP traffic. These streams are scanned by the DLP engine for possible violations of the policy.
Before enabling Mirror Port Mode scanning, you must prepare the gateway.
Monitor Mode lets the gateway listen to traffic from a Mirror port or Span port on a switch. To configure Monitor Mode on the Gaia operating system, see: sk70900.
Note - For R77.10 and higher, Mirror Port Mode scanning is enabled by default when one of the interfaces is configured as monitor mode or tap. For R77 and below, you must manually enable mirror port mode.
To enable Mirror Port Mode (for R77 and below):
Use the dlp_smtp_mirror_port
Description |
Enables SMTP Mirror Port Mode |
Syntax |
|
Parameters
Parameter |
Description |
||||
status |
Shows the status, whether mirror port mode is enabled or disabled. |
||||
enable |
Enables Mirror Port Mode |
||||
disable |
Disables Mirror Port Mode |
||||
Example |
|
||||
Output |
|
|
|||
Comments |
SMTP mirror mode remains enabled after a gateway reboot. |
||||
HTTPS Internet traffic uses the SSL (Secure Sockets Layer) protocol and is encrypted to give data privacy and integrity. However, HTTPS traffic has a possible security risk and can hide illegal user activity and malicious traffic. Security Gateways cannot inspect HTTPS traffic because it is encrypted. You can enable the HTTPS Inspection feature to let the Security Gateways create new SSL connections with the external site or server. The Security Gateways are then able to decrypt and inspect HTTPS traffic that uses the new SSL connections.
There are two types of HTTPS Inspection:
A Security Gateway uses certificates and becomes an intermediary between the client computer and the secure web site. All data is kept private in HTTPS Inspection logs. Only administrators with HTTPS Inspection permissions can see all the fields in such a log.
Outbound connections are HTTPS connections that arrive from an internal client and connect to the Internet. The Security Gateway compares the HTTPS request to the rules in the HTTPS Inspection Rule Base. If the request does not match any rule, the packet is not inspected and the connection is allowed.
If the request matches an HTTPS Inspection rule, the Security Gateway validates the certificate from the server (on the Internet). The Security Gateway validates the certificate using the Online Certificate Status Protocol (OCSP) standard. OCSP is faster and uses much less memory than CRL Validation, which is used for certificate validation in releases lower than R80.10. For a new HTTPS connection to the server, the Security Gateway creates and uses a new certificate. There are two HTTPS connections, one to the internal client and one to the external server. It can then decrypt and inspect the packets according to the security policy. The packets are encrypted again and sent to the destination.
|
|
|
|
Connection is not inspected |
|
|
|
|
|
|
|
|
|
HTTPS request |
|
Firewall inspects request |
|
Matches a rule? |
Yes |
Firewall validates certificate |
|
|
|
|
|
|
|
|
|
Firewall inspects unencrypted connection and then encrypts it |
|
Decrypts the connection |
|
Creates new certificate for client and server |
Inbound connections are HTTPS connections that arrive from an external client and connect to a server in the DMZ or the internal network. The Security Gateway compares the HTTPS request to the rules in the HTTPS Inspection Rule Base. If the request does not match any rule, the packet is not inspected and the connection is allowed.
If the request matches an HTTPS Inspection rule, the Security Gateway uses the certificate for the internal server to create an HTTPS connection with the external client. The Security Gateway creates a new HTTPS connection with the internal server. Since the Security Gateway has a secure connection with the external client, it can decrypt the HTTPS traffic. The decrypted traffic is inspected according to the security policy.
|
|
|
|
Connection is not inspected |
|
|
|
|
|
|
|
|
|
HTTPS request |
|
Firewall inspects request |
|
Matches a rule? |
Yes |
Uses server certificate and connects to the client |
|
|
|
|
|
|
|
|
|
Firewall inspects unencrypted connection |
|
Decrypts the connection |
|
Creates a new connection to server |
This section gives an example of how to configure a Gateways to inspect outbound and inbound HTTPS traffic.
Workflow overview
You must enable HTTPS inspection on each Security Gateway.
To enable HTTPS Inspection on a Security Gateway:
The first time you enable HTTPS inspection on one of the Security Gateways, you must create an outbound CA certificate for HTTPS inspection or import a CA certificate already deployed in your organization. This outbound certificate is used by all Security Gateways managed on the Security Management Server.
The outbound CA certificate is saved with a P12 file extension and uses a password to encrypt the private key of the file. The Security Gateways use this password to sign certificates for the sites accessed. You must keep the password because it is also used by other Security Management Servers that import the CA certificate to decrypt the file.
After you create an outbound CA certificate, you must export it so it can be distributed to clients. If you do not deploy the generated outbound CA certificate on clients, users will receive SSL error messages in their browsers when connecting to HTTPS sites. You can configure a troubleshooting option that logs such connections.
After you create the outbound CA certificate, a certificate object named Outbound Certificate is created. Use this object in rules that inspect outbound HTTPS traffic in the HTTPS inspection Rule Base.
To create an outbound CA certificate:
The Gateway Properties window opens.
The Create window opens.
You can import a CA certificate that is already deployed in your organization or import a CA certificate created on one Security Management Server to use on another Security Management Server.
Best Practice - Use private CA Certificates.
For each Security Management Server that has Security Gateways enabled with HTTPS inspection, you must:
To import a CA certificate:
The Gateway Properties window opens.
The Import Outbound Certificate window opens.
If you use more than one Security Management Server in your organization, you must first export the CA certificate with the export_https_cert
Command syntax:
export_https_cert [-local] | [-s server] [-f certificate file name under FWDIR/tmp][-help]
To export the CA certificate:
On the Security Management Server, run this command:
$FWDIR/bin/export_https_cert -local -f [certificate file name under FWDIR/tmp]
Example
$FWDIR/bin/export_https_cert -local -f mycompany.p12
To prevent users from getting warnings about the generated CA certificates that HTTPS inspection uses, install the generated CA certificate used by HTTPS inspection as a trusted CA. You can distribute the CA with different distribution mechanisms such as Windows GPO. This adds the generated CA to the trusted root certificates repository on client computers.
When users run standard updates, the generated CA will be in the CA list and they will not receive browser certificate warnings.
To distribute a certificate with a GPO:
Note - Make sure that the CA certificate is pushed to the client computer organizational unit.
You can use this procedure to deploy a certificate to multiple client machines with Active Directory Domain Services and a Group Policy Object (GPO). A GPO can contain multiple configuration options, and is applied to all computers in the scope of the GPO.
Membership in the local Administrators group, or equivalent, is necessary to complete this procedure.
To deploy a certificate using Group Policy:
The Group Policy Management Editor opens and shows the contents of the policy object.
Configure the Security Gateway for inbound HTTPS Inspection.
To enable inbound HTTPS traffic inspection:
Add the server certificates to the Security Gateway. This creates a server certificate object
When a client from outside the organization initiates an HTTPS connection to an internal server, the Security Gateway intercepts the traffic. The Security Gateway inspects the inbound traffic and creates a new HTTPS connection from the gateway to the internal server. To allow HTTPS inspection, the Security Gateway must use the original server certificate and private key. The Security Gateway uses this certificate and the private key for SSL connections to the internal servers.
After you import a server certificate (with a P12 file extension) to the Security Gateway, add the object to the HTTPS Inspection Policy.
Do this procedure for all servers that receive connection requests from clients outside of the organization.
To add a server certificate for inbound HTTPS inspection:
SmartConsole opens.
The Import Inbound Certificate window opens.
The Successful Import window opens the first time you import a server certificate. It shows you where to add the object in the HTTPS Inspection Rule Base. Click Don't show this again if you do not want to see the window each time you import a server certificate and Close.
The HTTPS Inspection rules define how the Security Gateways inspect HTTPS traffic. The HTTPS Inspection rules can use the URL Filtering categories to identify traffic for different websites and applications. For example, to protect the privacy of your users, you can use a rule to ignore HTTPS traffic to banks and financial institutions.
The HTTPS Inspection rules are applied to all the Software Blades that have HTTPS Inspection enabled. These are the Software Blades that support HTTPS Inspection:
To open the HTTP Inspection Policy
HTTPS Inspection rules in SmartConsole
These are the fields that manage the rules for the HTTPS Inspection security policy.
Field |
Description |
|---|---|
No. |
Rule number in the HTTPS Inspection Rule Base. |
Name |
Name that the system administrator gives this rule. |
Source |
Network object that defines where the traffic starts. |
Destination |
Network object that defines the destination of the traffic. |
Services |
The network services that are inspected or bypassed. By default, the services |
Site Category |
Categories for applications or web sites that are inspected or bypassed. |
Action |
Action that is done when HTTPS traffic matches the rule. The traffic is inspected or ignored (Bypass). |
Track |
Tracking and logging action that is done when traffic matches the rule. |
Install On |
Network objects that will get the HTTPS Inspection rule. You can only select Security Gateways that have HTTPS Inspection enabled. |
Certificate |
The certificate that is used for this rule.
|
Comment |
An optional field that lets you summarize the rule. |
Create different HTTPS Inspection rules for outbound and inbound traffic.
The outbound rules use the certificate that was generated for the Security Gateway.
The inbound rules use a different certificate for each internal server.
You can also create bypass rules for traffic that is sensitive and is not inspected. Make sure that the bypass rules are at the top of the HTTPS Inspection Rule Base.
After creating the rules, install the Access Control Policy.
Sample HTTPS Inspection Rule Base
This table shows a sample HTTPS Inspection Rule Base for a typical policy. (The Track and Install On columns are not shown. Track is set to None and Install On is set to Any.)
No |
Name |
Source |
Destination |
Services |
Site Category |
Action |
Blade |
Certificate |
|---|---|---|---|---|---|---|---|---|
1 |
Inbound traffic |
Any |
WebCalendar Server |
HTTPS |
Any |
Inspect |
Any |
WebCalendarServer CA |
2 |
Financial sites |
Any |
Internet |
HTTPS HTTP_HTTPS_proxy |
Financial Services |
Bypass |
Any |
Outbound CA |
3 |
Outbound traffic |
Any |
Internet |
HTTPS HTTP_HTTPS_proxy |
Any |
Inspect |
Any |
Outbound CA |
Check Point dynamically updates a list of approved domain names of services from which content is always allowed. This option makes sure that Check Point updates or other 3rd party software updates are not blocked. For example, updates from Microsoft, Java, and Adobe.
To bypass HTTPS inspection for software updates:
The Gateways pane lists the gateways with HTTPS Inspection enabled. Select a gateway and click Edit to edit the gateway properties.
In the CA Certificate section, you can renew the certificate validity date range if necessary and export it for distribution to the organization client machines.
If the Security Management Server which manages the selected Security Gateway does not have a generated CA certificate installed on it, you can add it with Import certificate from file.
When a client initiates an HTTPS connection to a web site server, the Security Gateway intercepts the connection. The Security Gateway inspects the traffic and creates a new HTTPS connection from the Security Gateway to the designated server.
When the Security Gateway establishes a secure connection (an SSL tunnel) to the designated web site, it must validate the site server certificate.
HTTPS Inspection comes with a preconfigured list of trusted CAs. This list is updated by Check Point when necessary and is automatically downloaded to the Security Gateway. The system is configured by default to notify you when a Trusted CA update file is ready for installation. The notification in SmartConsole shows as a pop-up notification or in the Trusted CAs window in the Automatic Updates section. After you install the update, make sure to install the policy. You can select to disable the automatic update option and manually update the Trusted CA list.
If the Security Gateway receives a non-trusted server certificate from a site, by default the user gets a self-signed certificate and not the generated certificate. A page notifies the user that there is a problem with the website security certificate, but lets the user continue to the website.
You can change the default setting to block untrusted server certificates.
You can save a selected certificate in the trusted CAs list to the local file system.
To export a CA certificate:
A CER file is created.
In the HTTPS Validation page of SmartConsole you can set options for
To learn more about these options, see the Help. Click ? in the HTTPS Validation page.
The predefined log query for HTTPS Inspection shows all HTTPS traffic that matched the HTTPS Inspection policy, and was configured to be logged.
To see HTTPS Inspection Logs:
The logs includes an HTTP Inspection Action field. The field value can be inspect or bypass. If HTTPS Inspection was not done on the traffic, this field does not show in the log.
No
