Configuration Parameters

Top  Previous  Next

The component uses configuration parameters which are specified in the [LinuxFirewall] section of the integrated configuration file of Dr.Web for UNIX Mail Servers.

The section contains the following parameters:

LogLevel

{logging level}

Logging level of the component.

If the parameter value is not specified, the DefaultLogLevel parameter value from the [Root] section is used.

Default value: Notice

Log

{log type}

Logging method

ExePath

{path to file}

Path to the executable file of the component.

Default value: <opt_dir>/bin/drweb-firewall

For Linux, Solaris: /opt/drweb.com/bin/drweb-firewall

For FreeBSD: /usr/local/libexec/drweb.com/bin/drweb-firewall

XtablesLockPath

{path to file}

Path to the iptables (NetFilter) table blocking file. If the parameter value is not specified, the /run/xtables.lock and /var/run/xtables.lock paths are checked. If the file is not found in the specified path or default paths, when launching the component, an error occurs.

Default value: (not set)

InspectHttp

{On | Off}

Instructs whether to check the data transferred over the HTTP protocol.

Real data scanning will be performed according to the indicated scanning rules (see below).

Default value: On

InspectSmtp

{On | Off}

Instructs whether to check data transferred over SMTP protocol (if installed, the Dr.Web MailD is used).

Real data scanning will be performed according to the indicated scanning rules (see below)..

Default value: Off

InspectPop3

{On | Off}

Instructs whether to check data transferred over POP3 protocol (if installed, the Dr.Web MailD is used).

Real data scanning will be performed according to the indicated scanning rules (see below)..

Default value: Off

InspectImap

{On | Off}

Instructs whether to check data transferred over IMAP protocol (if installed, the Dr.Web MailD is used).

Real data scanning will be performed according to the indicated scanning rules (see below)..

Default value: Off

InputDivert

{Off | Auto(interface:<i_name> protected:<p_list>)}

Defines the used method of diverting incoming connections (redirecting it to the SpIDer Gate checking component).

Allowed values:

Off—redirecting of incoming connections is disabled.

Auto(interface:<i_name> protected:<p_list>)—redirection of incoming connections in automatic mode. Rules are controlled by Dr.Web Firewall for Linux. Connections that comes via the specified network interface <i_name> into the <p_list> port list are monitored. Port numbers in the <p_list> list are separated by commas. For example, Auto(interface:eth0 protected:80,8080).

Default value: Off

OutputDivert

{Off | Auto}

Defines the used method of diverting outgoing connections (redirecting it to the SpIDer Gate checking component).

Allowed values:

Off—redirecting of outgoing connections is disabled.

Auto—redirection of outgoing connections in automatic mode. Dr.Web Firewall for Linux manages the rules.

Default value: Auto

ExcludedProc

{path to file}

The list of processes which can be used as the white list of processes, i.e. list of the processes whose network activity must not be monitored.

You can specify a list as the parameter value. The values in the list must be separated with commas (each value in the quotation marks). The parameter can be specified more than once in the section (in this case, all its values are combined into one list).

Example: Add to the list of processes wget and curl.

1.Adding of values to the configuration file.

Two values in one string

[LinuxFirewall]
ExcludedProc = "/usr/bin/wget", "/usr/bin/curl"

Two strings (one value per a string)

[LinuxFirewall]
ExcludedProc = /usr/bin/wget
ExcludedProc = /usr/bin/curl

2.Adding values via the command drweb-ctl cfset.

# drweb-ctl cfset LinuxFirewall.ExcludedProc -a /usr/bin/wget
# drweb-ctl cfset LinuxFirewall.ExcludedProc -a /usr/bin/curl

Note

Actual usage of the process list indicated in this parameter depends on the method of its usage in the scanning rules defined for Dr.Web Firewall for Linux.

The list of default rules (see below) guarantees that traffic of all processes from the list is allowed without any scanning.

Default value: (not set)

SniCheckAddress

{Boolean}

Instructs to check the SNI host to which you are trying to connect to the SSL handshake stage, "check is listed in the black list or belongs to the blocked categories, is performed without unwrapping the SSL.

Note

In the current realization, the value of this variable does not influence the processing of protected traffic. To control such processing, it is necessary to create a rule containing the sni_host in and sni_category in conditions (see below).

If you change the value of this parameter with the help of the cfset command of the drweb-ctl utility or with the help of the web interface, the affected dependent rules will adapt automatically.

Default value: No

UnwrapSsl

{Boolean}

Instructs to check encrypted traffic transferred via the SSL/TLS connections.

Note

In the current realization, the value if this variable does not influence processing of protected traffic. To control processing, it is necessary to create a rule containing the SET Unwrap_SSL = true/false action (see below).

If you change the value of this parameter with the help of the cfset command of the drweb-ctl utility or with the help of the web interface, the affected dependent rules will adapt automatically.

Default value: No

HttpSafeSearch

{Boolean}

Instructs to use the “Safe search” option for searching engines that support this mode.

Default value: No

BlockInfectionSource

{Boolean}

Instructs to block attempted connections to websites containing malicious software (included into the InfectionSource category).

For the blocking to work, you should check that within the settings there is also a rule that looks like this (see the details below):

url_category in "LinuxFirewall.BlockCategory" : BLOCK as _match

Default value: Yes

BlockNotRecommended

{Boolean}

Instructs to block attempts of connection to non-recommended websites (included into the NotRecommended category).

For the blocking to work, you should check that within the settings there is also a rule that looks like this (see the details below):

url_category in "LinuxFirewall.BlockCategory" : BLOCK as _match

Default value: Yes

BlockAdultContent

{Boolean}

Instructs to block attempts of connection to websites containing adult content (included into the AdultContent category).

For the blocking to work, you should check that within the settings there is also a rule that looks like this (see the details below):

url_category in "LinuxFirewall.BlockCategory" : BLOCK as _match

Default value: No

BlockViolence

{Boolean}

Instructs to block attempts of connection to websites containing graphic violence (included into the Violence category).

For the blocking to work, you should check that within the settings there is also a rule that looks like this (see the details below):

url_category in "LinuxFirewall.BlockCategory" : BLOCK as _match

Default value: No

BlockWeapons

{Boolean}

Instructs to block attempts of connection to websites dedicated to weapons (included into the Weapons category).

For the blocking to work, you should check that within the settings there is also a rule that looks like this (see the details below):

url_category in "LinuxFirewall.BlockCategory" : BLOCK as _match

Default value: No

BlockGambling

{Boolean}

Instructs to block attempts of connection to gambling websites (included into the Gambling category).

For the blocking to work, you should check that within the settings there is also a rule that looks like this (see the details below):

url_category in "LinuxFirewall.BlockCategory" : BLOCK as _match

Default value: No

BlockDrugs

{Boolean}

Instructs to block attempts of connection to websites dedicated to drugs (included into the Drugs category).

For the blocking to work, you should check that within the settings there is also a rule that looks like this (see the details below):

url_category in "LinuxFirewall.BlockCategory" : BLOCK as _match

Default value: No

BlockObsceneLanguage

{Boolean}

Instructs to block attempts of connection to websites containing obscene language (included into the ObsceneLanguage category).

For the blocking to work, you should check that within the settings there is also a rule that looks like this (see the details below):

url_category in "LinuxFirewall.BlockCategory" : BLOCK as _match

Default value: No

BlockChats

{Boolean}

Instructs to block attempts of connection to chat websites (included into the Chats category).

For the blocking to work, you should check that within the settings there is also a rule that looks like this (see the details below):

url_category in "LinuxFirewall.BlockCategory" : BLOCK as _match

Default value: No

BlockTerrorism

{Boolean}

Instructs to block attempts of connection to websites dedicated to terrorism (included into the Terrorism category).

For the blocking to work, you should check that within the settings there is also a rule that looks like this (see the details below):

url_category in "LinuxFirewall.BlockCategory" : BLOCK as _match

Default value: No

BlockFreeEmail

{Boolean}

Instructs to block attempts of connection to websites of free email services (included into the FreeEmail category).

For the blocking to work, you should check that within the settings there is also a rule that looks like this (see the details below):

url_category in "LinuxFirewall.BlockCategory" : BLOCK as _match

Default value: No

BlockSocialNetworks

{Boolean}

Instructs to block attempts of connection to social networking websites (included into the SocialNetworks category).

For the blocking to work, you should check that within the settings there is also a rule that looks like this (see the details below):

url_category in "LinuxFirewall.BlockCategory" : BLOCK as _match

Default value: No

BlockDueToCopyrightNotice

{Boolean}

Instructs to block attempts of connection to websites that were added according to copyright holder requests (included into the DueToCopyrightNotice category).

For the blocking to work, you should check that within the settings there is also a rule that looks like this (see the details below):

url_category in "LinuxFirewall.BlockCategory" : BLOCK as _match

Default value: No

Whitelist

{domain list}

List of domains that can be used as the white list (i.e. list of domains allowed for connection for users, even if these domains are included into blocked categories. In addition, user access will be allowed to all sub-domains of domains indicated in this list.)

The values in the list must be separated with commas (each value in the quotation marks). The parameter can be specified more than once in the section (in this case, all its values are combined into one list).

Example: Add to the list of domains example.com and example.net.

1.Adding of values to the configuration file.

Two values in one string

[LinuxFirewall]
Whitelist = "example.com", "example.net"

Two strings (one value per a string)

[LinuxFirewall]
Whitelist = example.com
Whitelist = example.net

2.Adding values via the command drweb-ctl cfset.

# drweb-ctl cfset LinuxFirewall.Whitelist -a example.com
# drweb-ctl cfset LinuxFirewall.Whitelist -a example.net

Note

Actual usage of the domain list indicated in this parameter depends on the method of its usage in the scanning rules defined for Dr.Web Firewall for Linux.

The list of default rules (see below) guarantees that access to domains (and their sub domains) from this list will be provided even if it contains domains from the list of blocked web source categories but only in case of a request to a server via the HTTP protocol. Besides, this default set of rules guarantees that data downloaded from the white list domains will be checked for threats (due to the fact that data is returned in a response, and a variable direction has a value response).

Default value: (not set)

Blacklist

{domain list}

List of domains that can be used as the black list (i.e. list of domains forbidden for connection for users, even if these domains are not included into blocked categories. In addition, user access will be forbidden to all sub-domains of domains indicated in this list.)

The values in the list must be separated with commas (each value in the quotation marks). The parameter can be specified more than once in the section (in this case, all its values are combined into one list).

Example: Add to the list of domains example.com and example.net.

1.Adding of values to the configuration file.

Two values in one string

[LinuxFirewall]
Blacklist = "example.com", "example.net"

Two strings (one value per a string)

[LinuxFirewall]
Blacklist = example.com
Blacklist = example.net

2.Adding values via the command drweb-ctl cfset.

# drweb-ctl cfset LinuxFirewall.Blacklist -a example.com
# drweb-ctl cfset LinuxFirewall.Blacklist -a example.net

Note

Actual usage of the domain list indicated in this parameter depends on the method of its usage in the scanning rules defined for Dr.Web Firewall for Linux.

The list of default rules (see below) guarantees that access to domains (and their sub-domains) from this list will be always forbidden over the HTTP protocol. If this domain is simultaneously added to the lists Whitelist and Blacklist, the default rules guarantee that user access to it will be blocked.

Default value: (not set)

ScanTimeout

{time interval}

Timeout for scanning one file initiated by SpIDer Gate.

A value in the range from 1s to 1h can be specified

Default value: 30s

HeuristicAnalysis

{On | Off}

Indicates whether heuristic analysis is used for detection of unknown threats during file scanning initiated by SpIDer Gate. Heuristic analysis provides higher detection reliability but, at the same time, it increases time of virus scanning.

Action applied to threats detected by the heuristic analyzer is specified as the BlockSuspicious parameter value.

Allowed values:

On—instructs to use heuristic analysis when scanning.

Off—instructs not to use heuristic analysis.

Default value: On

PackerMaxLevel

{integer}

Maximum nesting level when scanning packed objects. All objects at a deeper nesting level are skipped during file scanning initiated by SpIDer Guard.

A value in the range from 0 to 60 can be specified. If the value is set to 0, nested objects are not scanned.

Default value: 8

ArchiveMaxLevel

{integer}

Maximum nesting level when scanning archives. All objects at a deeper nesting level are skipped during file scanning initiated by SpIDer Gate.

A value in the range from 0 to 60 can be specified. If the value is set to 0, nested objects are not scanned.

Default value: 8

MailMaxLevel

{integer}

Maximum nesting level when scanning email messages and mailboxes. All objects at a deeper nesting level are skipped during file scanning initiated by SpIDer Gate.

A value in the range from 0 to 60 can be specified. If the value is set to 0, nested objects are not scanned.

Default value: 8

ContainerMaxLevel

{integer}

Maximum nesting level when scanning other containers (for example, HTML pages). All objects at a deeper nesting level are skipped during file scanning initiated by SpIDer Gate.

A value in the range from 0 to 60 can be specified. If the value is set to 0, nested objects are not scanned.

Default value: 8

MaxCompressionRatio

{integer}

Maximum compression ratio of compressed/packed objects (ratio between the uncompressed size and the compressed size). If the ratio of an object exceeds the limit, this object will be skipped during file scanning procedures initiated by SpIDer Gate.

The compression ratio must not be smaller than 2.

Default value: 500

BlockKnownVirus

{Boolean}

Instructs to block the receiving or the sending of data if it contains any known threat.

For the blocking to work, you should check that within the settings there is also a rule that looks like this (see the details below):

threat_category in "LinuxFirewall.BlockThreat" : BLOCK as _match

Default value: Yes

BlockSuspicious

{Boolean}

Instructs to block receiving or sending data if it contains any unknown threat detected by the heuristic analyzer.

For the blocking to work, you should check that within the settings there is also a rule that looks like this (see the details below):

threat_category in "LinuxFirewall.BlockThreat" : BLOCK as _match

Default value: Yes

BlockAdware

{Boolean}

Instructs to block the receiving or the sending of data if it contains adware.

For the blocking to work, you should check that within the settings there is also a rule that looks like this (see the details below):

threat_category in "LinuxFirewall.BlockThreat" : BLOCK as _match

Default value: Yes

BlockDialers

{Boolean}

Instructs to block the receiving or the sending of data if it contains a dialer program.

For the blocking to work, you should check that within the settings there is also a rule that looks like this (see the details below):

threat_category in "LinuxFirewall.BlockThreat" : BLOCK as _match

Default value: Yes

BlockJokes

{Boolean}

Instructs to block the receiving or the sending of data if it contains joke program.

For the blocking to work, you should check that within the settings there is also a rule that looks like this (see the details below):

threat_category in "LinuxFirewall.BlockThreat" : BLOCK as _match

Default value: No

BlockRiskware

{Boolean}

Instructs to block the receiving or the sending of data if it contains riskware.

For the blocking to work, you should check that within the settings there is also a rule that looks like this (see the details below):

threat_category in "LinuxFirewall.BlockThreat" : BLOCK as _match

Default value: No

BlockHacktools

{Boolean}

Instructs to block the receiving or the sending of data if it contains a hacktool.

For the blocking to work, you should check that within the settings there is also a rule that looks like this (see the details below):

threat_category in "LinuxFirewall.BlockThreat" : BLOCK as _match

Default value: No

BlockUnchecked

{Boolean}

Instructs to block the receiving or the sending of data if it cannot be checked.

Note

The value of this parameter influences processing of the rules that are impossible to evaluate to true or false because of an error. If No is specified, the rule is skipped as the rule that has not been executed. If Yes is specified, the BLOCK as BlackList action is performed.

Default value: No

Changes made to the settings of the connection scanning do not influence the scanning of connections that have already been established by the applications before making changes. If it is required to apply them to already running applications, it is necessary to force them to disconnect and then connect again, for example, by rebooting these applications.

Rules for Traffic Monitoring and Blocking of Access

In addition to the parameters listed above, section also contains eleven sets of rules RuleSet* (RuleSet0, …, RuleSet10) which control directly traffic scanning and blocking of access of the users to web resources and blocking downloading content from the Internet. For some values in conditions (for example, IP address ranges, lists of website categories, black and white lists of web sources, etc.), there is a substitution of values loaded from text files and also extracted from external data sources via LDAP (Dr.Web LookupD component is used). When configuring connections the whole list of rules is checked in the ascending order, until the rule containing the ultimate resolution is found. The gaps in the rule list are ignored.

The rules are described in detail in section Rules for Traffic Monitoring of Appendix D.

Viewing and editing of rules

For easy editing of the rules list gaps are left, i.e. RuleSet<i> sets that do not contain the rules. Note that you cannot add the items other than RuleSet0, …, RuleSet6, but you can add and to remove any rule in any element of RuleSet<i>. Viewing and editing rules can be performed in any of the following ways:

by viewing and editing the configuration file configuration file (in any text editor) (note that this file stores only those parameters which value is different from the default ones);

via the web interface of the product management (if installed).

via the command-line-based interface—Dr.Web Ctl (drweb-ctl cfshow and drweb-ctl cfset commands).

If you edited the rules and made changes in the configuration file, in order to apply these changes, restart the program. To do that, use the drweb-ctl reload command.

Use of the command drweb-ctl cfshow to view rules.

To view the contents of the rules set LinuxFirewall.RuleSet1, use the command

# drweb-ctl cfshow LinuxFirewall.RuleSet1

The use of the drweb-ctl cfset command to edit the rules (hereinafter the <rule>—text of the rule).

Replacing all the rules in a set LinuxFirewall.RuleSet1 with a new rule:

# drweb-ctl cfset LinuxFirewall.RuleSet1 '<rule>'

Adding a new rule to the rule set LinuxFirewall.RuleSet1:

# drweb-ctl cfset -a LinuxFirewall.RuleSet1 '<rule>'

Removing a specific rule from the set LinuxFirewall.RuleSet1:

# drweb-ctl cfset -e LinuxFirewall.RuleSet1 '<rule>'

Reset the rule set LinuxFirewall.RuleSet1 to the default state:

# drweb-ctl cfset -r LinuxFirewall.RuleSet1

When you use the drweb-ctl tool to edit the list of rules, enclose the text of your added rule into single or double quotes, and use backward slashes ('\') as escape characters before any double quotes within the text of the rule—if the text of the rule itself happens to contain double quotes.

It is important to remember the following storage features of rules in RuleSet<i> variables of the configuration:

The conditional part and colon can be omitted when adding unconditional rules. However, such rules are always stored in the list of rules as a string “ : <action>”;

When adding rules that contain several actions (such rules as '<condition> : <action 1><action 2>'), such rules will be modified into a chain of elementary rules '<condition> : <action 1>' and '<condition> : <action 2>'.

The logging or rules does not allow for disjunction (logical “OR”) of conditions in the conditional part, so, in order to implement the logical “OR”, the chain of rules should be logged with each rule having a disjunct-condition in its condition.

To add an unconditional rule for skipping the connections (the PASS action) to the LinuxFirewall.RuleSet1 set, you only need to execute the following command:

# drweb-ctl cfset -a LinuxFirewall.RuleSet1 'PASS'

However, to remove this rule from the specified rule set, it is required to execute the following command:

# drweb-ctl cfset -e LinuxFirewall.RuleSet1 ' : PASS'

To add the LinuxFirewall.RuleSet1 rule to the rule set that changes a path to standard templates for connections from unresolved addresses and performs blocking, it is necessary to execute the following command:

# drweb-ctl cfset -a LinuxFirewall.RuleSet1 'src_ip not in file("/etc/trusted_ip") : set http_template_dir = "mytemplates", BLOCK'

However, this command will add two rules to the specified set, so, in order to remove them from the set of rules, you need to execute two following commands:

# drweb-ctl cfset -e LinuxFirewall.RuleSet1 'src_ip not in file("/etc/trusted_ip") : set http_template_dir = "mytemplates"'
# drweb-ctl cfset -e LinuxFirewall.RuleSet1 'src_ip not in file("/etc/trusted_ip") : BLOCK'

To add to the LinuxFirewall.RuleSet1 rule set such rule as “Block if a malicious object KnownVirus or URL from the category Terrorism are detected”, it is necessary to add the following two rules to this rule set:

# drweb-ctl cfset -a LinuxFirewall.RuleSet1 'threat_category in (KnownVirus) : BLOCK as _match'
# drweb-ctl cfset -a LinuxFirewall.RuleSet1 'url_category in (Terrorism) : BLOCK as _match'

To remove them from the set of rules, you also need to execute two commands, as it is shown in the example above.

Default set of rules

By default, the following sets of rules are specified:

RuleSet0 =
RuleSet1 = divert output : set HttpTemplatesDir = "output"
RuleSet1 = divert output : set MailTemplatesDir = "firewall"
RuleSet1 = divert input : set HttpTemplatesDir = "input"
RuleSet1 = divert input : set MailTemplatesDir = "server"
RuleSet1 = proc in "LinuxFirewall.ExcludedProc" : PASS
RuleSet1 =  : set Unwrap_SSL = false
RuleSet2 =
RuleSet3 =
RuleSet4 =
RuleSet5 = protocol in (Http), direction request, url_host in "LinuxFirewall.Blacklist" : BLOCK as BlackList
RuleSet5 = protocol in (Http), direction request, url_host in "LinuxFirewall.Whitelist" : PASS
RuleSet6 =
RuleSet7 = protocol in (Http), direction request, url_category in "LinuxFirewall.BlockCategory" : BLOCK as _match
RuleSet8 =
RuleSet9 = protocol in (Http), divert input, direction request, threat_category in "LinuxFirewall.BlockThreat" : BLOCK as _match
RuleSet9 = protocol in (Http), direction response, threat_category in "LinuxFirewall.BlockThreat" : BLOCK as _match
RuleSet9 = protocol in (Smtp), threat_category in "LinuxFirewall.BlockThreat" : REJECT
RuleSet9 = protocol in (Smtp), url_category in "LinuxFirewall.BlockCategory" : REJECT
RuleSet9 = protocol in (Smtp), total_spam_score gt 0.80 : REJECT
RuleSet9 = protocol in (Pop3, Imap), threat_category in "LinuxFirewall.BlockThreat" : REPACK as _match
RuleSet9 = protocol in (Pop3, Imap), url_category in "LinuxFirewall.BlockCategory" : REPACK as _match
RuleSet9 = protocol in (Pop3, Imap), total_spam_score gt 0.80 : REPACK as _match
RuleSet10 =

The first rule indicates that if the connection is established by the process specified in the ExcludedProc parameter (see above), the connection is skipped without checking any other conditions. The next rule (is executed without any condition) blocks unwrapping of protected connections. This rule and all those that are situated below are considered only if a connection is not bound with the excluded process. Moreover, as all subsequent rules depend on the protocol, if unwrapping of protected connections is disabled, the rules are not executed because it is impossible to define whether the conditions evaluate to true.

The following rules are dedicated to the processing of the outgoing HTTP connections:

1.If a host with which a connection is established is included in a black list, the connection is blocked because the host is in the black list. Other checks are not performed.

2.If the host is included in a white list, the connection is skipped, and other check are not performed.

3.If the URL requested by the client is in the categories of web resources marked as unwanted for access, the connection is blocked due to the detection of a threat. Other checks are not performed.

4.If the response received from a remote host has threats via HTTP contains a threat belonging to the blocked categories, the connection is blocked because the threat was detected. Other checks are not performed.

5.If the data transferred from the local host to a remote host contains a threat belonging to the blocked categories, the connection is blocked because the threat was detected. Other checks are not performed.

These five rules will work only if On is specified in the InspectHttp parameter. Otherwise, none of these rules work.

The following six rules that are specified in the RuleSet9 control the scanning of the data that is sent and received via email protocols; these rules are activated if it is detected that a transmitted email (over SMTP, POP3 or IMAP protocol) contains attachments or URLs belonging to the categories that should be blocked or qualified as spam (with the reliability rating not less than 0,8). If an email is transmitted over the SMTP protocol, the transmission (i.e. sending or receipt) of the email will be blocked, whereas for the IMAP and POP3 protocols the email will be processed to remove malicious content from its contents (“repackaging”).

If the component for email message scanning for signs of spam Dr.Web ASE is unavailable, then email message scanning for signs of spam is not performed. In this case, rules that contain scanning of spam level (value total_spam_score) are unavailable.

Note that email processing rules are executed only if On is specified for the corresponding Inspect<EmailProtocol> parameters. Otherwise, none of these rules are executed. Moreover, the Dr.Web MailD component for email scanning should be installed for examination of a transmitted email for malware attachments. If the component is not installed, transmitted email will be blocked because of the error “Unable to check”. To allow transmitting messages that cannot be checked, set the BlockUnchecked = No parameter (see above). Moreover, if the email scanning component is not installed, it is recommended to specify No for the InspectSmtp, InspectPop3, and InspectImap parameters.

Note that the set of default rules can change automatically if the values of the SniCheckAddress and UnwrapSsl parameters are changed.

Examples of Rules for Traffic Monitoring and Blocking of Access

1.Allow users with the following IP addresses 10.10.0.0 – 10.10.0.254 to access via HTTP websites of all categories, except Chats:

protocol in (HTTP), src_ip in (10.10.0.0/24), url_category not in (Chats) : PASS

Note that if the rule

protocol in (HTTP), url_host in "LinuxFirewall.Blacklist" : BLOCK as BlackList

is allocated in the list of rules above the indicated rule, then access to domains from the black list, i.e. domains listed in the parameter LinuxFirewall.Blacklist, will also be blocked for users with the range of IP addresses 10.10.0.0 – 10.10.0.254. And if this rule is allocated below, users with the range of IP addresses 10.10.0.0 – 10.10.0.254 will get access also to websites from the black list.

Due to the fact that resolution PASS is terminal, no more rules are checked, therefore scanning of the downloaded data for viruses is not performed either. To grant users with the range of IP addresses 10.10.0.0 – 10.10.0.254 access to websites of all categories, except Chats if they are not in the black list, and to block download of threats at the same time, use the following rule:

protocol in (HTTP), url_category not in (Chats), url_host not in "LinuxFirewall.Blacklist", threat_category not in "LinuxFirewall.BlockCategory" : PASS

2.Do not perform scanning of contents of video files downloaded from the Internet (i.e. data with the type MIME “video/*”, where * is any type of the MIME class video):

direction response, content_type in ("video/*") : PASS

Note that files loaded from the local computer (including those with the MIME type 'video/*‘) will be scanned because they are sent in requests, not in responses, i.e. for them a variable direction has a value request.