4.2 Security rules

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

  • 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

images/download/attachments/26167910/icap_filters_logical.png

A filter may consist of three parts:

  1. Host IP/Domain conditions

  2. Client IP conditions

  3. Generic conditions

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

Host IP/Domain conditions

Header name

Match type

Host

Wildcard 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 name

Match type

X-Client-IP

Wildcard 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 pattern

Matches

Does not match

127.0.0.*

127.0.0.1, 127.0.0.150

127.0.100.1, 127.5.0.1

www.example.co?

www.example.com

www.example.co

[ab]cd

acd, bcd

cd, ecd

abc

abc

cba, xyz

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

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. Analysis workflow configuration and 3.6.4. Security 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.

images/download/thumbnails/26167910/icap_policy_order.png
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 default security rule 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.

images/download/attachments/26167910/screencapture-localhost-8048-2018-04-21-14_59_53.png

Default security rule

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

Name

Request filters

Allow scan

Applied core rule

Advanced

Default

none

Yes

Automatic

none

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:

$ 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

images/download/attachments/26167910/icap_policy_eg_1.1_new.png

images/download/attachments/26167910/icap_policy_eg_1.2_new.png

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]