Workflow Management

MetaDefender ICAP Server's workflows can be configured under Workflow Management

Workflow Management overview

Workflow help to assign security policies to specific requests.

A Workflow consists of two parts:

• Request filter
• Security policy definition

Request filter

Based on header values or source address, request filters select requests on which the assigned security policy will be applied. Request filters can be set up on the Request filters tab while creating or editing a security rule.

Filtering can be based on source address, ICAP, HTTP or custom headers. The following parameters must be provided to create a filter condition:

• Header name: name of the header to look up.
• ICAP client address: address of the ICAP client
• Match type: the value of the referred header must be equal to, contain, start with, or end with the provided value.
• Value: the value to match.

Filter parts

A filter may consist of four parts:

1. Host IP/Domain conditions
2. Client IP conditions
3. ICAP client address
4. Generic conditions

Host IP/Domain conditions

The Host header usually contains the requested URI.

Client IP conditions

The X-Client-IP header usually contains the IP of the machine from which the request was originally sent.

Wildcard matching examples

ICAP client IP conditions

The ICAP client address is the address from where the ICAP request is originated (for example a proxy server).

Generic conditions

Using generic conditions, filters can be set up to any headers.

Header references

Filtering can be based on ICAP, HTTP or even custom headers. For an incomplete reference of possible headers consult the following sources:

• HTTP

  • IANA
  • Wikipedia

• ICAP: IETF

• Custom: Initially, it was recommended to begin naming custom headers with X- , however, according to RFC 6648 , this recommendation has since been deprecated.

Workflow policy

A Workflow policy consists of the SCAN, DATA TRICKLING, ADVANCED and the SOAP/JSON (support since v5.3.0) settings.

Scan settings

The scan policy can be set up on the Scan tab while creating or editing a security rule.

The following options are available:

1. ALLOW SCAN: enable or disable scanning of requests. Default is enabled.
   1. METADEFENDER CORE: MetaDefender Core type server profile to which requests are sent for scanning. Default is None .
   2. SCAN TIMEOUT: ICAP Server will try to get the scan results for the timeout defined here. If the timeout elaplses then the request gets blocked. Default is 0.
      1. Valid range: 0 .. 86400
      2. 0 (zero) means that there is no timeout: ICAP Server will wait for the results for any long time.

Data trickling

Data trickling preferences can be set on the Data trickling tab while creating or editing a security rule. For further details about data trickling see 4.7 Data trickling.

The following options are available:

1. ENABLE DATA TRICKLING: enable releasing drips of the original contents even before the scanning completes.

1. FIRST DRIP: settings related to the first drip of the original content

1. DELAY: Delay of the first drip –after the contents have been submitted for scanning– in seconds.

2. SIZE: Size of the first drip –after the contents have been submitted for scanning– in kilobytes.

2. ADDITIONAL DRIPS

1. DELAY: Delay of each consecutive drips –after the first, or any other previous drip– in seconds.

2. SIZE: Size of each consecutive drips –after the first, or any other previous drip– in kilobytes.

3. ENABLE TO WITHHOLD: Whether to allow or not to withhold the last portion of the original contents from being dripped before the scanning completes.

1. Size: Size of withheld data in kilobytes.

Allow list

Support since ICAP v5.9.0, the FileType engine has already integrated to MD ICAP Server and supported set the Allow List for each workflow.

When the file type in Allow List is checked then the files with corresponding file type will not be send to MD Core backend for scanning

Block Page

refer to Replacing the default block page

Advanced settings

Some default security behaviors of the system can be modified on the Advanced tab while creating or editing a security rule.

The following options are available:

1. OVERRIDE SCAN RESULTS CLASSIFIED AS ALLOWED: enable or disable overriding the following default security behaviors all together.

   1. MULTIPART PARSING ERROR: Requests with multipart content are parsed for boundary and control header correctness. By default requests with mutlipart parsing error are rejected by MetaDefender ICAP Server. Enabling this option will accept such requests. (For further details about multipart content see RFC 1341 and RFC 2388.)
   2. CORE BUSY: By default MetaDefender ICAP Server rejects requests when none of the Cores of the applied server profile can accept the scan requests due to overload. Enabling this option scanning will be skipped and the request will be accepted when all Cores are busy.
   3. CORE RULE FILE SIZE LIMIT EXCEEDED: By default MetaDefender Core blocks a file that exceeds the file size limit configured for the Core rule (see 3.6.2. Workflow template configuration and 3.6.4. Workflow rule configuration chapters in MetaDefender Core v4 User Guide) applied for the ICAP Server security rule. Enabling this option results the oversized request to bypass scanning.
   4. SCAN TIMEOUT: By enabling this option MetaDefender ICAP Server will allow requests whose scan timed out.
   5. CORE SERVER ERROR: By enabling this option MetaDefender ICAP Server will allow requests which had a general MetaDefender Core error during their processing. This means every error where MetaDefender Core responded with the status code 500 and is not listed above as a specific case.

2. ACTION FOR NOT SUPPORTED ENCODINGS: MetaDefender ICAP Server supports gzip, deflate, brotli, zstd and base64 encoding only. By default requests with any other encoding are rejected by default. Here you can select your preferred action for these kind of requests.

   1. BLOCK: Block the request. This is the default option.
   2. SCAN WITHOUT DECODING: Send the content without decoding towards MetaDefender Core for processing and continue serving the request based on the processing result.
   3. ALLOW: Allow the request without processing the content.

3. ACTION FOR DECODING ERRORS: MetaDefender ICAP Server supports gzip, deflate, brotli, zstd and base64 encoding of request contents. By default requests with encoding error are rejected. Here you can select your preferred action for these kind of requests.

   1. BLOCK: Block the request. This is the default option.
   2. SCAN WITHOUT DECODING: Send the content without decoding towards MetaDefender Core for processing and continue serving the request based on the processing result.
   3. ALLOW: Allow the request without processing the content.

4. Override Processing history (refer to Override the processing history)

5. Add header to Metadata (In MetaDefender Core): Support since ICAP v5.8.0, Allow to specific any header from ICAP header or HTTP header can be audited in MetaDefender Core backend server's corresponding JSON processing details in the metadata field (displayed in metadata column of Metadefender Core's Processing history)

Content encoded (SOAP/JSON/Form URLEncoded)

Enabling MetaDefender ICAP Server to parse SOAP / JSON formatted message, then extract and decode base64 data which is embedded in the message, before sending to MetaDefender Core for further threat analysis.

Node path configuration for SOAP message

Example:

Configuring MetaDefender ICAP Server to process the Base64 encoded data which is embedded in SOAP message with node api:FileBase64String

<?xml version="1.0" encoding="UTF-8"?>

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">

    <soapenv:Header xmlns:api="http://www.crmnext.com/api/"/>

    <soapenv:Body xmlns:api="http://www.crmnext.com/api/">

        <api:scan>

            <api:objects>

                <api:Description>Test data</api:Description>

                <api:FileBase64String><!--- Base64 encodded data here -->/</api:FileBase64String>

            </api:objects>

        </api:scan>

    </soapenv:Body>

</soapenv:Envelope>

Then the node path to scan FileBase64String is:

/soapenv:Envelope/soapenv:Body/api:scan/api:objects/api:FileBase64String

Node path configuration for JSON message

Example:

Configuring MetaDefender ICAP Server to process the Base64 encoded data which is embedded in JSON message with node api:FileBase64String

{

    "Envelope": {

        "Body": {

            "scan": {

                "objects" : {

                    "Description": "Test data",

                    "FileBase64String": "Base64 encodded data here"

                }

            }

        }

    }

}

Then the node path to scan FileBase64String is:

/Envelope/Body/scan/objects/FileBase64String

Node path configuration for Form URL Encoded

Example: configure Metadefender ICAP server to process base64 encoded data which is embedded in Form URL Encoded with

FileBase64String=base64data1&Filename=somefilename

Then the node path to scan with the file name specific

Rule Order

Several security rules can be created that may target different requests from different hosts going to different URL. However, care must be taken how these rules are set up and ordered, as there is a first match and a no match policy.

Specific rules should come first while generic rules should go at last.

Order of evaluation of security rules for a match

First match policy

If there are more matching rules in the system, then the request will be accepted or rejected according to the security policy of the first matching rule in the list.

No match policy

If there is no matching rule in the system (or no rule at all), then the request will be rejected.

The goal of the 147167977 is to have a rule in the system that matches in the end.

Security Rule Management

The Security Rule Management screen lists the existing security rules in the system.

Default security rule

After installation a default security rule is created with the following parameters:

Functions

Besides listing existing security rules the Security Rule Management screen provides the following functions:

• Add new security rule
• Clone an existing security rule
• Modify (and view) existing security rule's properties
• Delete existing security rules

Use case examples

Enable anti-malware test site for test clients

The site www.eicar.org is created to test anti-malware solutions. Under the URI http://www.eicar.org/download/eicar.com.txt there is a malware test file that is forbidden by MetaDefender ICAP Server by default:

$ wget http://www.eicar.org/download/eicar.com.txt

--2017-04-18 17:06:02--  http://www.eicar.org/download/eicar.com.txt

Connecting to 127.0.0.1:3128... connected.

Proxy request sent, awaiting response... 403 Forbidden

2017-04-18 17:06:03 ERROR 403: Forbidden.

Create the following rule (in the actual test the client browser, the proxy and the MetaDefender ICAP Server is on the same machine, that is the reason for the Client IP setting 127.0.0.1):

Filters:

Scan Settings:

Place it before the Default rule. Now the request is served:

$ wget http://www.eicar.org/download/eicar.com.txt

--2017-04-18 17:15:56--  http://www.eicar.org/download/eicar.com.txt

Connecting to 127.0.0.1:3128... connected.

Proxy request sent, awaiting response... 200 OK

Length: 68 [application/octet-stream]

Saving to: ‘eicar.com.txt.3’

100%[======================================>] 68          --.-K/s   in 0s

2017-04-18 17:15:56 (20.2 MB/s) - ‘eicar.com.txt.3’ saved [68/68]