Configuration Parameters

The component uses configuration parameters which can be found in the [LinuxFirewall] section of the unified configuration file of Dr.Web for UNIX Mail Servers.

Component Parameters.

Rules for Traffic Monitoring and Blocking of Access.

Component parameters

The section contains the following parameters:

Parameter

Description

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 of the component.

Default value: Auto

ExePath

{path to file}

Executable path to the component.

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

For GNU/Linux: /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 specified)

InspectFtp

{On | Off}

Scan the data transferred over the FTP protocol.

The data is scanned in accordance with the rules (see below).

Default value: On

InspectHttp

{On | Off}

Scan the data transferred over the HTTP protocol.

The data is scanned in accordance with the rules (see below).

Default value: On

InspectSmtp

{On | Off}

Scan data transferred over SMTP protocol (if installed, the Dr.Web MailD is used).

Real data scanning will be performed according to specified scan rules (see below).

Default value: On

InspectPop3

{On | Off}

Scan data transferred over POP3 protocol (if installed, the Dr.Web MailD is used).

Real data scanning will be performed according to specified scan rules (see below).

Default value: On

InspectImap

{On | Off}

Scan data transferred over IMAP protocol (if installed, the Dr.Web MailD is used).

Real data scanning will be performed according to specified scan rules (see below).

Default value: On

AutoconfigureIptables

{Yes | No}

Rules for configuring the NetFilter system component via the iptables interface.

Allowed values:

Yes—configure rules for NetFilter when launching the component and remove them when finishing its operation automatically (recommended);

No—do configure the rules automatically. The required rules must be added manually by the administrator before launching the component and removed after finishing its operation.

Note

If the automatic configuration of the rules for iptables is not allowed, it is necessary that the required rules for iptables are available before the component operation starts.

Default value: Yes

AutoconfigureRouting

{Yes | No}

The configuration mode for ip route and ip rule routing rules and policies.

Allowed values:

Yes—configure routing rules and policies for ip route and ip rule when launching the component and remove them when finishing its operation automatically (recommended);

No—do not perform configure rules automatically. Required rules are added manually by the administrator before launching the component and removed after finishing its operation.

Note

If the automatic configuration of the routing rules and policies is not allowed, it is necessary that the required rules for ip route and ip rule are available before the component operation starts.

Default value: Yes

LocalDeliveryMark

{integer | Auto}

The <LDM> mark for packets that are redirected to the Dr.Web Firewall for Linux network socket (specified in the TproxyListenAddress parameter, see below) to intercept the connection.

Allowed values:

<integer><LDM> mark for packets. Equals 2N, where N is an LDM bit number in the packet, 0 ≤ N ≤ 31;

Auto—allow Dr.Web Firewall for Linux to select the appropriate bit in the packet mark automatically (recommended).

Note

When assigning <LDM> number manually, make sure that the corresponding bit in the packet mark is not used by any other application that manage route connections and packets (including via NetFilter). If an invalid value is specified, the component launch will fail.

Specified <LDM> number should be used in routing rules that must be added manually, if AutoconfigureIptables = No and/or AutoconfigureRouting = No.

Default value: Auto

ClientPacketsMark

{integer | Auto}

The <CPM> mark for packets transferred between the client that initiates the connection and Dr.Web Firewall for Linux.

Allowed values:

<integer><СPM> mark for packets. Equals 2N, where N is a CPM bit number in the packet, 0 ≤ N ≤ 31;

Auto—allow Dr.Web Firewall for Linux to select the appropriate bit in the packet mark automatically (recommended).

Note

When assigning the <СPM> number manually, make sure that the corresponding bit in the packet mark is not used by any other application that manages route connections and packet (including via NetFilter). If an invalid value is specified, the component launch will fail.

Specified <СPM> number should be used in routing rules that must be added manually, if AutoconfigureIptables = No.

Default value: Auto

ServerPacketsMark

{integer | Auto}

<SPM> mark for packets transferred between Dr.Web Firewall for Linux and the server that receives the connection.

Allowed values:

<integer><SPM> mark for packets. Equals 2N, where N is a SPM bit number in the packet, 0 ≤ N ≤ 31;

Auto—allow Dr.Web Firewall for Linux to select the appropriate bit in the packet mark automatically (recommended).

Note

When assigning the <SPM> number manually, make sure that the corresponding bit in the packet mark is not used by any other application that manage route connections and packets (including via NetFilter). If an invalid value is specified, the component launch will fail.

The specified <SPM> number should be used in routing rules that must be added manually, if AutoconfigureIptables = No and/or AutoconfigureRouting = No.

Default value: Auto

TproxyListenAddress

{network socket}

Network socket (<IP address>:<port>) on which Dr.Web Firewall for Linux receives intercepted connections. If you specify port zero, it is selected automatically by the system.

Note

It is necessary to make sure that the corresponding socket is not used by any other application. If an invalid value is specified, the component launch will fail.

Specified IP address and port should be used in routing rules that must be added manually, if AutoconfigureIptables = No.

Default value: 127.0.0.1:0

OutputDivertEnable

{Yes | No}

Enable/disable interception mode for incoming connections (i.e. connections initiated by applications on the remote with connections on the local host).

Allowed values:

Yesintercept and process outgoing connections;

Nodo not intercept and process outgoing connections.

Note

This setting adds or removes routing rule number 5 that is added or removed manually, if AutoconfigureIptables = No.

Default value: No

OutputDivertNfqueueNumber

{integer | Auto}

Number of the queue NFQUEUE from which Dr.Web Firewall for Linux will retrieve SYN packages that initiate outgoing connections.

Allowed values:

<integer>—queue number <ONum> to monitor the SYN packages of intercepted outgoing connections in NFQUEUE;

Auto—allow Dr.Web Firewall for Linux to select an appropriate queue number automatically (recommended).

Note

When assigning <ONum> number manually, make sure that the corresponding queue number is not used by any other application that control connections and packages (including via the NetFilter rules). If an invalid is specified, the component launch will fail.

Specified <ONum> number should be used in routing rule number 5 that is added manually, if AutoconfigureIptables = No

Default value: Auto

OutputDivertConnectTransparently

{Yes | No}

Enable/disable the emulation mode for connecting to the recipient (server) using the IP address of the sender of an intercepted package (client) for outgoing connections.

Allowed values:

Yes—connect to the server using the address of the client that requested the connection instead of your own when intercepting the connection;

No—connect to the server from the Dr.Web Firewall for Linux address.

As client and Dr.Web Firewall for Linux addresses are usually the same in the outgoing connections interception mode, the default value is No.

Default value: No

InputDivertEnable

{Yes | No}

Enable/disable interception of incoming connections (i.e. connections initiated by applications on the remote host with connections on the local host).

Allowed values:

Yes— enable intercepting and processing incoming connections;

No—disable intercepting and processing incoming connections.

Note

This setting adds or removes routing rule number 6 that is added or removed manually, if AutoconfigureIptables = No. If the invalid value is specified, the component launch will fail.

Default value: No

InputDivertNfqueueNumber

{integer | Auto}

Number of the queue NFQUEUE from which Dr.Web Firewall for Linux will retrieve SYN packages that initiate incoming connections.

Allowed values:

<integer>—queue number <INum> to monitor the SYN packages of intercepted outgoing connections in NFQUEUE;

Auto—allow Dr.Web Firewall for Linux to select an appropriate queue number automatically (recommended).

Note

When assigning <INum> number manually, make sure that the corresponding queue number is not used by any other application that control connections and pack (including via the NetFilter rules). If an invalid is specified, the component launch will fail.

Specified <INum> number should be used in routing rule number 6 that is added manually, if AutoconfigureIptables = No

Default value: Auto

InputDivertConnectTransparently

{Yes | No}

Enable/disable emulation mode for connecting to the recipient (server) using the IP address of the sender of an intercepted package (client) for incoming connections.

Allowed values:

Yes—connect to the server using the address of the client that requested the connection instead of your own when intercepting the connection;

No—connection to the server from the Dr.Web Firewall for Linux address.

In the incoming connections interception mode, all traffic goes through Dr.Web Firewall for Linux, and it is possibly to connect safely to the server using the fraudulent client’s addresses. This is why the default value is Yes.

Default value: Yes

ForwardDivertEnable

{Yes | No}

Enable/disable the interception of transit connections (i.e. connections initiated by applications on one remote host with connections on the other remote host).

Allowed values:

Yes—enable intercepting and processing transit connections;

Nodisable intercepting and processing transit connections.

Note

This setting adds or removes routing rule number 7 that is added or removed manually, if AutoconfigureIptables = No.

Default value: No

ForwardDivertNfqueueNumber

{integer | Auto}

The number of the queue NFQUEUE from which Dr.Web Firewall for Linux will retrieve SYN packages that initiate transit connections.

Allowed values:

<integer>—queue number <FNum> to monitor the SYN packages of intercepted transit connections in NFQUEUE;

Auto—allow Dr.Web Firewall for Linux to select an appropriate queue number automatically (recommended).

Note

When assigning <FNum> number manually, make sure that the corresponding queue number is not used by any other application that control connections and pack (including via the NetFilter rules). If an invalid is specified, the component launch will fail.

Specified <FNum> number should be used in routing rule number 7 that is added manually, if AutoconfigureIptables = No

Default value: Auto

ForwardDivertConnectTransparently

{Yes | No}

Emulation mode for connecting to the recipient (server) using the IP address of the sender of an intercepted package (client) for transit connections.

Allowed values:

Yes—connect to the server using the address of the client that requested the connection instead of your own when intercepting the connection;

No—connect to the server from the Dr.Web Firewall for Linux address.

As there is no guarantee that in the transit connections interception mode all the traffic goes through the same host (router) on which have Dr.Web Firewall for Linux is installed, the default value is No for the correct operation. If the network configuration guarantees that protected applications are use same router, the parameter can be set to Yes, and in this case, Dr.Web Firewall for Linux will always evaluate connection to client’s addresses when connecting to servers.

Default value: No

ExcludedProc

{path to file}

White list of processes (process for which the network activity is not 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 values to the configuration file.

Two values in a line:

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

Two lines (a value per line):

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

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

# 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)

UnwrapSsl

{Boolean}

Scan 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

BlockInfectionSource

{Boolean}

Block connection attempts to websites containing malicious software (included into the InfectionSource category).

To activate blocking, the following rule should be added to the settings (see the details below):

url_category in "LinuxFirewall.BlockCategory" : Block as _match

Default value: Yes

BlockNotRecommended

{Boolean}

Block connection attempts to non-recommended websites (included into the NotRecommended category).

To activate blocking, the following rule should be added to the settings (see the details below):

url_category in "LinuxFirewall.BlockCategory" : Block as _match

Default value: Yes

BlockAdultContent

{Boolean}

Block connection attempts to websites containing adult content (included into the AdultContent category).

To activate blocking, the following rule should be added to the settings (see the details below):

url_category in "LinuxFirewall.BlockCategory" : Block as _match

Default value: No

BlockViolence

{Boolean}

Block connection attempts to websites containing graphic violence (included into the Violence category).

To activate blocking, the following rule should be added to the settings (see the details below):

url_category in "LinuxFirewall.BlockCategory" : Block as _match

Default value: No

BlockWeapons

{Boolean}

Block connection attempts to websites dedicated to weapons (included into the Weapons category).

To activate blocking, the following rule should be added to the settings (see the details below):

url_category in "LinuxFirewall.BlockCategory" : Block as _match

Default value: No

BlockGambling

{Boolean}

Block connection attempts to gambling websites (included into the Gambling category).

To activate blocking, the following rule should be added to the settings (see the details below):

url_category in "LinuxFirewall.BlockCategory" : Block as _match

Default value: No

BlockDrugs

{Boolean}

Block connection attempts to websites dedicated to drugs (included into the Drugs category).

To activate blocking, the following rule should be added to the settings (see the details below):

url_category in "LinuxFirewall.BlockCategory" : Block as _match

Default value: No

BlockObsceneLanguage

{Boolean}

Block connection attempts to websites containing obscene language (included into the ObsceneLanguage category).

To activate blocking, the following rule should be added to the settings (see the details below):

url_category in "LinuxFirewall.BlockCategory" : Block as _match

Default value: No

BlockChats

{Boolean}

Block connection attempts to chat websites (included into the Chats category).

To activate blocking, the following rule should be added to the settings (see the details below):

url_category in "LinuxFirewall.BlockCategory" : Block as _match

Default value: No

BlockTerrorism

{Boolean}

Block connection attempts to websites dedicated to terrorism (included into the Terrorism category).

To activate blocking, the following rule should be added to the settings (see the details below):

url_category in "LinuxFirewall.BlockCategory" : Block as _match

Default value: No

BlockFreeEmail

{Boolean}

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

To activate blocking, the following rule should be added to the settings (see the details below):

url_category in "LinuxFirewall.BlockCategory" : Block as _match

Default value: No

BlockSocialNetworks

{Boolean}

Block connection attempts to social networking websites (included into the SocialNetworks category).

To activate blocking, the following rule should be added to the settings (see the details below):

url_category in "LinuxFirewall.BlockCategory" : Block as _match

Default value: No

BlockDueToCopyrightNotice

{Boolean}

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

To activate blocking, the following rule should be added to the settings (see the details below):

url_category in "LinuxFirewall.BlockCategory" : Block as _match

Default value: No

BlockOnlineGames

{Boolean}

Block connection attempts to Online games websites (included into OnlineGames category).

To activate blocking, the following rule should be added to the settings (see the details below):

url_category in "LinuxFirewall.BlockCategory" : Block as _match

Default value: No

BlockAnonymizers

{Boolean}

Block connection attempts to anonymizers websites (included into Anonymizers category).

To activate blocking, the following rule should be added to the settings (see the details below):

url_category in "LinuxFirewall.BlockCategory" : Block as _match

Default value: No

BlockCryptocurrencyMiningPools

{Boolean}

Block connection attempts to websites provide an access to common services for cryptocurrencies mining (included into CryptocurrencyMiningPool category).

To activate blocking, the following rule should be added to the settings (see the details below):

url_category in "LinuxFirewall.BlockCategory" : Block as _match

Default value: No

BlockJobs

{Boolean}

Block connection attempts to job search websites (included into Jobs category).

To activate blocking, the following rule should be added to the settings (see the details below):

url_category in "LinuxFirewall.BlockCategory" : Block as _match

Default value: No

Whitelist

{domain list}

White list of domains (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 drweb-ctl cfset command:

# 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 scanned 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 drweb-ctl cfset command:

# 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}

Time-out for scanning one file initiated by SpIDer Gate.

Acceptable values: from 1 second (1s) to 1 hour (1h).

Default value: 30s

HeuristicAnalysis

{On | Off}

Enable/disable heuristic analysis for detection of known threats. 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—enable heuristic analysis when scanning;

Off—disable heuristic analysis.

Default value: On

PackerMaxLevel

{integer}

Maximum nesting level for packed objects. A packed object is executable code compressed with special software (UPX, PELock, PECompact, Petite, ASPack, Morphine and so on). Such objects may include other packed objects which may also include packed objects. etc. he value of this parameter specifies the nesting limit beyond which packed objects inside other packed objects will not be scanned.

The nesting level is not limited. If the value is set to 0, nested objects are not scanned.

Default value: 8

ArchiveMaxLevel

{integer}

Maximum nesting level for archives (zip, rar, and so on) in which other archives may be enclosed (and these archives may also include other archives, and so on). The value of this parameter specifies the nesting limit beyond which archives enclosed in other archives will not be scanned.

The nesting level is not limited. If the value is set to 0, nested objects are not scanned.

Default value: 8

MailMaxLevel

{integer}

Maximum nesting level for files of mailers (pst, tbb and so on) in which other files may be enclosed (and these files may also include other files and so on). The value of this parameter specifies the nesting limit beyond which objects inside other objects will not be scanned.

The nesting level is not limited. If the value is set to 0, nested objects are not scanned.

Default value: 8

ContainerMaxLevel

{integer}

Maximum nesting for other types objects inside which other objects are enclosed (HTML pages, jar-files, etc.). The value of this parameter specifies the nesting limit beyond which objects inside other objects will not be scanned.

The nesting level is not limited.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}

Block either incoming or outgoing data containing known threats.

To activate blocking, the following rule should be added to the settings (see the details below):

threat_category in "LinuxFirewall.BlockThreat" : Block as _match

Default value: Yes

BlockSuspicious

{Boolean}

Block either incoming or outgoing data containing unknown threats detected by the heuristic analyzer.

To activate blocking, the following rule should be added to the settings (see the details below):

threat_category in "LinuxFirewall.BlockThreat" : Block as _match

Default value: Yes

BlockAdware

{Boolean}

Block either incoming or outgoing data containing adware.

To activate blocking, the following rule should be added to the settings (see the details below):

threat_category in "LinuxFirewall.BlockThreat" : Block as _match

Default value: Yes

BlockDialers

{Boolean}

Block either incoming or outgoing data containing dialer programs.

To activate blocking, the following rule should be added to the settings (see the details below):

threat_category in "LinuxFirewall.BlockThreat" : Block as _match

Default value: Yes

BlockJokes

{Boolean}

Block either incoming or outgoing data containing joke programs.

To activate blocking, the following rule should be added to the settings (see the details below):

threat_category in "LinuxFirewall.BlockThreat" : Block as _match

Default value: No

BlockRiskware

{Boolean}

Block either incoming or outgoing data containing riskware.

To activate blocking, the following rule should be added to the settings (see the details below):

threat_category in "LinuxFirewall.BlockThreat" : Block as _match

Default value: No

BlockHacktools

{Boolean}

Block either incoming or outgoing data containing hacktools.

To activate blocking, the following rule should be added to the settings (see the details below):

threat_category in "LinuxFirewall.BlockThreat" : Block as _match

Default value: No

BlockUnchecked

{Boolean}

Block the traffic that cannot be scanned.

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

InterceptHook

{path to file | Lua function}

Script for processing connections in Lua or path to the file containing the script (see the Processing connections in Lua section).

If unavailable file is specified, an error appears when loading the component.

Default value:

local dwl = require 'drweb.lookup'

function intercept_hook(ctx)

 -- do not check if group == Root.TrustedGroup
 if ctx.divert == "output" and ctx.group == "drweb"
 then
     return "pass"
 end

 -- do not check connections from privileged ports
 -- except FTP active mode
 if ctx.src.port >= 0 and ctx.src.port <= 1024
     and ctx.src.port ~= 20
 then
     return "pass"
 end

 return "check"
end

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 all rules are checked in the ascending order, until the rule containing the ultimate resolution is found. The gaps in the rule list are ignored.

Viewing and editing of rules

For easy editing of the rules list gaps are left, i.e. RuleSet<i> sets that do not contain rules (<i>RuleSet rule set number). Note that you cannot add the items other than RuleSet<i>, 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 management interface (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 Dr.Web for UNIX Mail Servers. To do that, use the drweb-ctl reload command.

Use the drweb-ctl cfshow command 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”, log the chain of rules 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 for blocking 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 regulate the processing of the outgoing HTTP connections:

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

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

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

4.If the response received from a remote host includes threats via HTTP contains a threat belonging to the blocked categories, the connection is blocked because the threat was detected. Other scans 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 scans are not performed.

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

The following six rules that are specified in the RuleSet9 control the scanning of the data sent and received via email protocols (over SMTP, POP3 or IMAP protocol); these rules are activated in the following cases:

the transmitted email message contains attachments;

the transmitted email message contains URLs belonging to unwanted categories;

the transmitted email message is qualified as spam (with the spam index not less than 0.8).

If the email message 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 Anti-Spam 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 the examination of transmitted email messages for malware attachments and signs of spam. 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.

Examples of Rules for Traffic Monitoring and Blocking of Access

1.Allow users with IP addresses in 10.10.0.0–10.10.0.254 range an HTTP access to 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 the 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.