Print Download PDF Send Feedback

Previous

Next

ICAP Server

In This Section:

Introduction to ICAP

ICAP Server Sample Workflow

ICAP Server support for Threat Prevention

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

ICAP Server

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.

Any Security Gateway can function as an ICAP server.

ICAP server functionality is not supported in VSX mode.

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

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.

    The gateway object window opens.

  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. Configure Advanced ICAP Server options.
  6. Click OK.
  7. Install policy.

You can create a new ICAP service which runs on a port different than 1344 and select it

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, there is no option to create exceptions for an ICAP rule.

Currently, there is no implied rule for ICAP server in the Access Control policy. Make sure that the ICAP port (service) is open in the Access Control policy on all relevant gateway targets.

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.

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:

Note - For a detailed explanation on how to configure a Check Point ICAP client, see the R80.20 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:

ICAP Server_use_case

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.