Security Rules Policy

MetaDefender ICAP Server security rules can be configured under Policy > Security rules.

Security rules overview

Security rules help to assign security policies to specific requests.

A security rule 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.

If a header with the referred header name does not exist in the request, then this condition won't 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

There is AND relation among the above parts of the filter.

Host IP/Domain conditions

Header nameMatch type
HostWildcard matching (glob)

The Host header usually contains the requested URI.

There is OR relation among entries in Host IP/Domain conditions.

Client IP conditions

Header nameMatch type
X-Client-IPWildcard matching (glob)

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

There is OR relation among the Client IP conditions.

Wildcard matching examples

Example patternMatchesDoes not match
127.0.0.*127.0.0.1, 127.0.0.150127.0.100.1, 127.5.0.1
www.example.co?www.example.comwww.example.co
[ab]cdacd, bcdcd, ecd
abcabccba, xyz

Please note the difference between the Client IP conditions and the ICAP client IP conditions: the client IP is the node from whom the original request is sent, while the ICAP client is the network element that is in direct connection with the ICAP Server (e.g. proxy).

ICAP client IP conditions

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

The match type is wildcard matching (glob).

There is OR relation among the ICAP client address conditions.

Please note the difference between the Client IP conditions and the ICAP client IP conditions: the client IP is the node from whom the original request is sent, while the ICAP client is the network element that is in direct connection with the ICAP Server (e.g. proxy).

Generic conditions

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

As an example Host IP/Domain and Client IP conditions could also be set up as generic conditions.

There is AND relation among the generic conditions.

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

  • 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.

Security policy

A security policy consists of the SCAN, DATA TRICKLING and the ADVANCED 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.

When scanning is disabled, all requests will be accepted.

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.

Risk of potential threats allowed

WARNING!

Given by the nature of the thing, enabling data trickling may cause the ICAP Server to release potentially malicious content.

Always enable data trickling with care; only if you know what you are doing, if you are aware of the risk, and if you accept this risk.

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.

Risk of releasing malicious object

If ENABLE TO WITHHOLD is not set, and the end of the file is reached any time during the trickling, then the whole original, potentially malicious content has been already released.

Always set ENABLE TO WITHHOLD, except only if you know what you are doing, if you are aware of the risk, and if you accept this risk.

1. Size: Size of withheld data in kilobytes.

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 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 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.

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.

Deleting all security rules from the system results all requests being blocked.

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:

NameRequest filtersAllow scanApplied core ruleAdvanced
DefaultnoneYesAutomaticnone

The Default security rule matches any request. It will enforce scanning with automatically selected Core rule. It does not override any default advanced setting.

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:

Copy

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:

Copy
Type to search, ESC to discard
Type to search, ESC to discard
Type to search, ESC to discard
Next to read:
FILEMOD
On This Page
Security Rules PolicySecurity rules overviewRequest filterFilter partsHost IP/Domain conditionsClient IP conditionsWildcard matching examplesICAP client IP conditionsGeneric conditionsHeader referencesSecurity policyScan settingsData tricklingAdvanced settingsRule orderFirst match policyNo match policySecurity Rule ManagementDefault security ruleFunctionsUse case examplesEnable anti-malware test site for test clientsFilters:Scan Settings: