ICAP Server

In This Section: Introduction to ICAP ICAP Server Sample Workflow ICAP Server support for Threat Prevention Threat Prevention Settings and ICAP Server Related Configuration on the ICAP Client Use Case

Introduction to ICAP

The Internet Content Adaptation Protocol (ICAP) is a request and response protocol, similar to the HTTP/1.1 protocol, and allows a proxy (or other devices) to send HTTP traffic for inspection by a remote host. This frees up resources and standardizes the way in which new features are implemented. The remote host can allow, block, or modify the content. ICAP is an RFC protocol, which lets devices from different vendors communicate. Check Point devices can work with third party devices without changing the network topology.

ICAP is specified in RFC 3507 (for more information, see ICAP Specification). In addition, see the Draft RFC - ICAP Extensions.

ICAP server can work with multiple ICAP clients.

ICAP server is supported only on R80.20 GA gateways and above and supports only the Threat Emulation and Anti-Virus blades. For more information and updates, see sk123412.

ICAP packet structure

The ICAP message is encapsulated into the TCP

ICAP methods

Method	Description
REQMOD	Client Request Modification. The ICAP Client uses this method for an HTTP / HTTPS request modification.
RESPMOD	Server Response Modification. The ICAP Client uses this method for an HTTP / HTTPS response modification.
OPTIONS	The ICAP Client uses this method to retrieve configuration information from the ICAP Server.

ICAP server actions

The ICAP server has 2 possible actions:

ICAP Action	Description and Example
Block	ICAP sends an error to the Client. ICAP sends a block page to the Client. For example: A Check Point UserCheck page presented by the Threat Emulation or Anti-Virus Software Blades.
Continue / Not modified	A default gateway or a proxy server can forward the HTTP Request / Response to its original destination.

ICAP server response codes

These are the ICAP response codes that are different from their HTTP counterparts:

Category	Code	Description
1yz Informational codes	100	Continue after ICAP preview.
2yz Success codes	204	No Content. No modification is required.
	206	Partial Content.
4yz Client error codes	400	Bad request.
	404	ICAP Service not found.
	405	Method not allowed for service (for example, RESPMOD requested for service that supports only REQMOD).
	408	Request timeout. ICAP Server timed out waiting for a request from an ICAP Client.
	418	Bad composition. ICAP Server needs encapsulated sections different from those in the request.
5yz Server error codes	500	Server error. Error on the ICAP Server, such as "out of disk space".
	501	Method not implemented. This response is illegal for an OPTIONS request as implementation of OPTIONS is mandatory.
	502	Bad Gateway. This is an ICAP proxy error.
	503	Service overloaded. The ICAP server exceeded a maximum connection limit associated with this service. The ICAP Client should not exceed this limit in the future.
	505	ICAP version is not supported by server.

ICAP Server Sample Workflow

Item No.	Description
1	Client
2	Third party gateway or proxy
3	ICAP client
4	Web server
5	Check Point gateway
6	ICAP server

Workflow for working with Check Point ICAP server in RESPMOD:

1. The client sends a request to the third party gateway/proxy server to download a file.
2. The third party gateway/proxy sends the download request to the Web server.
3. The Web server sends the requested file to the third party gateway/proxy.
4. The ICAP client forwards the file to the ICAP server which is in the Check Point Threat Emulation gateway.
5. The ICAP server sends the file to the Threat Emulation engine.
6. The Threat Emulation checks the file:
   1. The Threat Emulation engine returns a verdict (block, modified or continue) to the ICAP server.
   2. The ICAP server sends the verdict to the ICAP client.
   3. The ICAP client sends the verdict to the client.

ICAP Server support for Threat Prevention

ICAP server is only supported with the Threat Emulation and Anti-Virus blades. Any other blades in a Threat Prevention profile are ignored. If you enable ICAP server on the gateway and not enable the Threat Emulation or the Anti-Virus blades, the ICAP server runs but without inspection.

ICAP server functionality is not supported in VSX mode.

If you enable the ICAP Server on a Check Point Cluster object:

• You must configure your ICAP Clients to communicate with the applicable Virtual IP Address of the Check Point Cluster.
• ICAP connections do not survive cluster failover.

To enable ICAP server support on the Check Point Security Gateway or cluster:

1. In SmartConsole, go to the Gateways & Servers view and double-click a Security Gateway or cluster.
2. Navigate to the ICAP Server page.
3. Select Enable ICAP Server.

   In Service, the default service is tcp ICAP which runs on port 1344.

4. Configure Fail Mode - In case of an error, configure if requests to the ICAP server are blocked or allowed.
5. You can configure an implied rule for ICAP in the Access Control policy.
6. Configure Advanced ICAP Server options.
7. Click OK.
8. Install policy.

You can create a new ICAP service and select it instead of the default service.

To create a new ICAP service:

1. Go to the objects bar and select New > More > Service > TCP.
2. Enter the object name and add a comment if necessary.
3. In General, do not select a protocol.
4. In Match By, select the Port you want the service to run on.
5. Optional: Configure the Advanced features. For a detailed explanation on the advanced service features, check the online help.
6. Click OK.

The new service now appears in the drop-down Service list.

When you enable ICAP server on the gateway object, an auto-generated rule is created in the Threat Prevention Rule Base. One rule is created for each gateway that has ICAP Server enabled. You can only configure the profile column in this rule. You can select a different profile for each ICAP rule. Unlike other Threat Prevention rules, you cannot create exceptions for an ICAP rule.

Note - ICAP Server supports only Anti-Virus deep-scan. Any additional functionality, such as MD5 hash, URL reputation, and signature-based protection, is not supported.

Advanced ICAP Server Configuration on the Gateway

The ICAP server (CICAP) uses processes to handle the requests it receives from the ICAP client. Each process generates multiple threads, and each thread handles one request from the ICAP client to the ICAP server.

The ICAP server supports dynamic scaling of the number of processes for optimal performance. The number of available threads increases or decreases as needed. The minimum number of processes is 3.

• The maximum allowed number of server processes is configured on the gateway. In addition, you can configure The number of threads per a child process.
• The maximum allowed number of server processes multiplied by The number of threads per a child process is the number of maximum concurrent connections that the ICAP server can handle.
• Start a new child process if the number of available threads is less than [x] - This option allows dynamic growth and lets you configure the number of new threads as needed. The ICAP server counts the total number of available (idle) threads. If this number is lower than the number configured in this field, it creates a new child process.
• End a child process if the number of available threads is more than [x] - This option allows dynamic reduction of the number of threads as needed. The ICAP server counts the total number of available (idle) threads. If this number is higher than the number configured in this field, it ends a child process.

Threat Prevention Settings and ICAP Server

The ICAP server operates according to the relevant settings defined for Threat Emulation and Anti-Virus in the selected Threat Prevention profile and engine settings.

Emulation Connection Handling Mode and ICAP Server

In the Threat Prevention default profiles (Basic, Optimized, and Strict), Threat Emulation is set to Background mode.

Background mode means that connections are allowed until emulation is complete.

In Hold mode, the connections are blocked until emulation handling is complete. You can create a new profile and change the mode to Hold mode, and apply the profile to the relevant gateways.

Related Configuration on the ICAP Client

When you work with Check Point ICAP server, make sure to set this configuration on your ICAP client:

• Direct the ICAP modification requests to the ICAP server sandblast service. For example: icap://<ip_address>:1344/sandblast.
• Set the ICAP client to send these headers, if possible: X-Client-IP, X-Server-IP, X-Authentication-User (the headers are used in the ICAP server logs).
• Make sure the operation timeout for the ICAP Client is equal or higher than the operation timeout for the ICAP server. Note that the sandblast service on the Check Point ICAP server, can take some time to respond.
• For HTTPS traffic, configure the ICAP client to send clear HTTP (decrypted HTTPS) traffic to the Check Point ICAP server. If this option is not available on your ICAP client, the ICAP server is not able to process the traffic.

Note - For a detailed explanation on how to configure a Check Point ICAP client, see the R80.30 Next Generation Security Gateway Administration Guide. For a detailed explanation on how to configure a third party ICAP client, see your vendor's documentation.

Use Case

You can use the ICAP technology to communicate HTTPS content.

You are a system administrator, who manages a network that includes a third party gateway/proxy and a Check Point gateway. The Check Point gateway enforces the Threat Emulation and Anti-Virus blades. The third party gateway/proxy has HTTPS inspection enabled, but the Check Point Security Gateway does not. With the ICAP client and Check Point ICAP server enabled and configured to work together, the ICAP client can send the decrypted traffic to the ICAP server for inspection. This way, the Check Point gateway can read the HTTPS content for the Threat Emulation and Anti-Virus blades, even if no HTTPS inspection is enabled on the gateway.

The workflow for ICAP technology in HTTPS inspection:

Item No.	Description
1	HTTPS client
2	Third party gateway or proxy
3	ICAP client
4	Check Point gateway
5	Check Point ICAP server
6	Web server

1. The HTTPS client initiates an HTTPS connection, which is sent to the proxy server.
2. Proxy server forwards the HTTPS connection to the Check Point gateway.
3. The Check Point gateway forwards the HTTPS connection to the web server.
4. The web server sends the requested data over HTTPS to the Check Point gateway.
5. The Check Point gateway forwards the HTTPS connection to the proxy server.
6. The ICAP client decrypts the HTTPS connection (the ICAP client is configured to work in RESPMOD).
7. The ICAP client sends the decrypted HTTPS content to the ICAP server for a verdict.
8. The ICAP server returns a verdict to the ICAP client.
9. Based on the verdict, the proxy server allows or blocks the requested HTTPS data.