In this section
•Categories of unwanted websites and threats
•Configuration parameters that can be used in rule conditions
•Features of saving rules to the configuration file
The rules are represented by such constructions as IF <conditional_part> THEN <action_part>. At that, in the conditional part the following scanning types are specified: “The variable value is (not) set” or “The variable value is (not) included in the specified set”. The action part contains a set of (at least one) actions, and each of these actions is an ultimate resolution (skip or block a scanned object), or a modifying action which looks as “Change features of the scanned object”, “Assign the set value to the specified variable” or “Add the set value to the array of values of the specified variable”.
The actions specified in a rule are executed only if the conditional part is true. If the conditional part is false, the actions specified in this rule are not performed, and the program jumps to the next rule. The rules are processed from the top down until an ultimate resolution is performed. After this, all rules below (if there are any) are ignored. When a rule is executed, it is important that actions in the action part be performed in order in which they are specified from left to right, and if there is an ultimate resolution in the chain of actions that interrupts the rule processing, the rest of the actions specified in the action part is not performed.
The rules have the format:
[<condition>[, <condition>[, …]]] : <action>[, <action>[, …]] |
The conditional part of the rule (before ':') can be missing, in this case a part of the actions is executed without any condition. If the conditional part of the rule is missing, the ':' separator can be omitted. The comma between conditions in the conditional part and actions in the action part performs a role of a logical conjunction (that is, “and”): the conditional part elevates to true, only if all its conditions are true, and all actions specified in the action part are performed in order of their specification from left to right until an ultimate resolution which interrupts the rule handling. Key words, names of variables and configuration parameters used in the rules are not case-sensitive.
The following types of conditions can be used in the rules:
Condition |
Comment |
||
|---|---|---|---|
<variable> <value > |
The value of the variable coincides with that specified in the rule. Can be used only for variables that can contain a set of values simultaneously. |
||
<variable> [not] in <set of values> |
The value of the variable is contained in the specified set of values (for not—does not match any value from the specified set). |
||
<variable> [not] match <set of values> |
The value of the variable matches any regular expression listed in the specified set (for not—does not match any expression from the specified set).
|
||
<variable> [not] gt <value> |
The value of the variable is (not) greater than the value specified. Can be used only for those variables that can have a single value. |
||
<variable> [not] lt <value> |
The value of the variable is (not) less than the value specified. Can be used only for variables that have a single value. |
*) The optional key word not means negation.
Part <set of values> to which a variable is compared can be specified in the following ways:
Syntax |
Meaning |
|||
|---|---|---|---|---|
(<value 1>[, <value 2>[, …]]) |
In brackets the values to check against are listed (the minimum number must not be less than one). In case there is only one value and the in condition is used, you can omit the brackets (and you will end up with a case <variable> <value>). |
|||
"<section>.<parameter>" |
The set of values currently assigned to a configuration parameter; the name of a configuration parameter whose value (or set of values) must be checked in quotation marks (note that you also need to specify the name of the section to which the parameter belongs). The lists of the parameters that can be used as conditions dependы on the component for which the rules are set. The lists are provided below. |
|||
file("<file name>") |
Path to the text file <file name> with the list of values. Each string in the file corresponds to a list item. Leading and trailing spaces are ignored.
|
|||
<type_of_LOOKUP_request>@<tag>[@<value>] |
A value array is requested via Dr.Web LookupD from an external data source, where <LOOKUP_query_type> is the type of source; <tag> is the name of the section describing the connection for checked parameter sampling, and optional <value> is the value that must be in values array, extracted from data source.
|
If a variable is multiple-valued, the condition <variable> in <set of values> is true, if intersection of the set of current values of the specified variable <variable> with the indicated set <set of values> is not empty.
The condition not in is true in the opposite case. For example, suppose X is a variable, which the current value is a set with values a, b, c. Then:
•X in (a, b) is true because values a and b are encountered in both sets;
•X in (a, d, e) is true because value a is encountered in both sets;
•X in (d, e) is false because there is no value of the variable (a, b, c) in the set (d, e);
•X in () is false as array of variable values is not empty;
•X not in () is true, the array of variable values is not empty;
•X not in (d, e) is true because there is no value of the variable (a, b, c) in the set (d, e);
•X not in (a, d, e) is false because value a is encountered in both sets.
In the description of the variables below, there is an indication for each variable whether it can adopt a set of values.
Actions are divided into final resolutions, which determine whether to permit passing an object and actions that change the values of some variable, which can be used when checking conditions in the subsequent rules.
Ultimate Resolutions
Resolution |
Description (Meaning) |
|---|---|
Common Resolutions |
|
Pass |
Let the traffic pass (allow to create a connection, send an object to the recipient). The further rules (if there are any) are not used. |
Block as <reason> |
Block the traffic (prohibit to create a connection or send an object to a recipient). The further rules (if there are any) are not used. The<reason> for blocking is recorded in the log. The same reason is displayed in the browser notification shown to the user. The reasons for Block are the following: •BlackList—the data is blocked because it has been blacklisted by the user; •_match—the block happens because a web resource or file containing threat belongs to a category that triggers rule executing (for conditions *_category in (?)). The _match variable contains the list of blocked categories which matched. |
Features of handling ultimate resolutions:
•Block as BlackList, always processes as “is included in a black list” (without considering the condition specified in the rules with this resolution);
•Block as _match, if _match is not empty, processes as “belongs to the _match category”;
•Block as _match, if _match is empty, processes as “is included in a black list” (without considering the condition specified in the rules with this resolution);
•If all rules have been considered, and none of the rules with resolutions performs (or the rules do not have resolutions), this situation is the same as Pass action.
Changing Value of a Variable
To change the variable value, the following instruction is used:
SET <variable> = ([<value 1>[, <value 2>[, …]]]) |
If there are no values in brackets, the list of the variable values will be cleared:
SET <переменная> = () |
If the variable has only one value, the brackets are not used:
SET <переменная> = <значение> |
The variables are not case-sensitive. If the name of the variable is compound, you can write it either with our without an underscore. Thus, the names variable_name, VariableName, and variablename are actually the actually the equivalent variations of the same name. In the table below the names of all variables are written with an underscore.
Common variables
Variable |
Description |
Can be used in |
|
|---|---|---|---|
conditions |
actions (SET) |
||
protocol |
Network protocol used by the connection. The variable can take multiple values. Allowed values: HTTP, SMTP, IMAP, POP3. Usage Aspects •The variable value can be defined only if SSL/TLS is not used or it was allowed to unwrap SSL. •The only possible value of the variable in the rules for Dr.Web ICAPD is HTTP. •A set of values for checking the variable value is can be read from a text file. Examples: protocol in (HTTP, SMTP) |
Yes |
No |
sni_host |
SNI host (address) to which the connection is established via SSL/TLS. Usage Aspects •If SSL is not used, the condition is false as the value of the variable is not defined. •You cannot the variable in the rules for Dr.Web ICAPD (it does not process SSL, so the condition always evaluates to false). •A set of values for checking a variable value can be read from a text file. •You can use this variable together with the proc variable (see below). Examples: sni_host not in ('vk.com', 'ya.ru') |
Yes |
No |
sni_category |
The list of categories (AdultContent, and so on) which the host (that is identified from the SNI-header) belongs to (according to the databases of web resource categories), for hosts to which your computer is attempting to connect over SSL/TLS. The variable can take multiple values. Usage Aspects •If SSL is not used, the value of a variable is not defined and the condition evaluates to false. •You cannot use the variable in the rules for Dr.Web ICAPD (it does not process SSL, for that reason the condition always evaluates to false). •In the rules for Dr.Web ICAPD, a condition with not in will be true, even if the host does not belong to any of the predetermined categories (“safe” host). •If databases of web resource categories are not installed, it is impossible to use the variable in the rules (attempts to check if a condition in the rule is true will lead to the error x112). •A set of values for checking the variable value is can be read from a text file. Examples: sni_category not in (AdultContent, Chats) |
Yes |
No |
url |
URL requested by the client. Can be compared with the specified string or with a regular expression. Usage Aspects •You can use this variable only in rules for Dr.Web ICAPD. •You can use Dr.Web LookupD to check the value of this variable. •A set of values for checking the value of the variable can be read from the file. •You can use this variable together with the proc variable (see below). Examples: url match ("drweb.com", "example\..*", "aaa\.ru/") |
Yes |
No |
url_host |
URL/host to which the connection is established. Usage Aspects •You can set a value for this variable only if SSL/TLS is not used for connection or if SSL unwrapping is allowed. •You can use Dr.Web LookupD can to check the value of this variable. •A set of values for checking the variable value is can be read from a text file. Examples: url_host in ('vk.com', 'ya.ru') |
Yes |
No |
url_category |
The list of categories to which the URL/host belongs. The information is based according to the database of categories or Dr.Web Cloud replies. The variable can take multiple values. Usage Aspects •You can set a value for this variable only if SSL/TLS is not used for connection or if SSL unwrapping is allowed. •In the rules Dr.Web ICAPD, a condition with not in will be true, even if the URL/host does not belong to any of the predetermined categories (“safe” URL/host). In the rules for Dr.Web Firewall for Linux (SpIDer Gate), the condition in this case will be false. •If databases of web resource categories are not installed, it is impossible to use the variable in the rules (attempts to check if a condition in the rule is true will lead to the error x112). •A set of values for checking a variable value can be read from a text file. Examples: url_category not in (AdultContent, Chats) |
Yes |
No |
threat_category |
The list of categories the threat belongs to, which is found in the transferred data (according to information from virus databases). The variable can simultaneously contain a set of values. Usage Aspects •You can set a value for this variable only if SSL/TLS is not used for connection or if SSL unwrapping is allowed. •In the rules for Dr.Web ICAPD, a condition with not in will be true, even if the object does not contain threats from any of the predetermined categories (“safe” object). In the rules for Dr.Web Firewall for Linux (SpIDer Gate), the condition in this case will be false. •A set of values for checking a variable value can be read from a text file. Examples: threat_category in "LinuxFirewall.BlockThreat" |
Yes |
No |
user |
The user on whose behalf the process sending (or receiving) the traffic has been launched. Usage Aspects •In the rules for Dr.Web ICAPD the name of the user who has authenticated on the proxy server is set as the value of the variable. If the proxy server does not support user authentication, the value of the variable is empty. •You can use Dr.Web LookupD to check the value of this variable. If you need to find out whether the user belongs to a certain user group, use an LDAP or an Active Directory data source that returns a list of groups and specify the name of the required group (for which you want to know whether the user is its member or not). Use the following format: <type of the source for LookupD>@<source of groups>@<required group>. Requests to Active Directory (AD@) return only lists of groups, therefore for these requests it is mandatory to use the @<required group> part. •A set of values for checking a variable value can be read from a text file. Examples: user in ('user1', 'user2') |
Yes |
No |
src_ip |
The IP address of a host establishing the connection. Usage Aspects •You can use Dr.Web LookupD to check the value of this variable. •A set of values for checking a variable value can be read from a text file. Examples: src_ip not in (127.0.0.1, 10.20.30.41, 198.126.10.0/24) |
Yes |
No |
proc |
The process establishing the connection (the full executable path). Usage Aspects •You cannot use the variable in the rules for Dr.Web ICAPD(the component does not contain information about processes, for that reason the condition always evaluates to false). •A set of values for checking a variable value can be read from a text file. •You can use this variable together with sni_host, url, and dst_address (see below). Examples: proc in ('/usr/bin/ls') |
Yes |
No |
direction |
The type of message sent via the connection. Allowed values: request (client request), response (server reply). This variable cannot take multiple values; conditions of the match and in type cannot be applied. Examples: direction request |
Yes |
No |
divert |
The direction of the connection. Allowed values: input (incoming—created/initiated from outside the local host), output (outgoing—created/initiated on the local host). This variable cannot take multiple values; conditions of the match and in type cannot be applied. Examples: divert input |
Yes |
No |
content_type |
MIME type of data transferred via connection. Usage Aspects •You can set a value for this variable only if SSL/TLS is not used for connection or if SSL unwrapping is allowed. •The expression “*/*” matches data of any MIME type and HTTP replies without the header Content-Type. •You can use Dr.Web LookupD can be used to check the value of this variable. •A set of values for checking a variable value can be read from a file. Examples: content_type in ("multipart/byteranges", "application/octet-stream") |
Yes |
No |
Network activity of the process, where proc is the full process executable path (see above), and <variable> defines type of the activity and can be one of the following values: •sni_host—SNI host (address), with which the connection is established via SSL/TLS; •url—URL requested by a client (see above); •dst_address—network address (<IP address>:<port>), with which the process establishes the connection. Usage Aspects •Using only with the condition match ({<Proc_reg>, <Var_reg>}[, …]), where <Proc_reg> is a regular expression for proc, and <Var_reg> is a regular expression for <variable>. •You canno use the variable in th rules for Dr.Web ICAPD (the component does not contain information about processes, for that reason the condition always evaluates to false). Examples: (proc, url) match ({"/usr/bin/wget", "www\.ya\.*"}) |
Yes |
No |
|
unwrap_ssl |
Indicates whether the traffic transferred via SSL/TLS is unwrapped. Allowed values: true, false. Usage Aspects •The value of the variable cannot be empty. The instruction SET unwrap_ssl = () is impossible. •You cannot use this variable in the condition. It is necessary only to control SSL unwrapping (for example, to display a webpage containing notification about blocking triggered by our side). •You cannot use the variable in the rules for Dr.Web ICAPD (it does not process SSL, changing of the variable does not influence rule processing). Examples: SET unwrap_ssl = TRUE |
No |
Yes |
http_templates_dir |
The path to the directory where the block pages templates are stored. If a path starts with a / (forward slash), it is an absolute path; if it starts with any other symbol, it is a relative path. In the latter case it is given relative to the directory specified in the TemplatesDir parameter. Usage Aspects •Can be used for the HTTP(S) protocol. Examples: SET http_templates_dir = "/etc/mytemplates" |
No |
Yes |
Categories of unwanted websites and threats
1.Categories of unwanted websites (for the variables sni_category, url_category)
Convention |
Website category |
|---|---|
InfectionSource |
Websites containing malicious software (“infection sources”) |
NotRecommended |
Fraudulent websites (that use “social engineering”) visiting which is not recommended |
AdultContent |
Websites that contain pornographic or erotic materials, dating sites, and so on |
Violence |
Websites that encourage violence or contain materials about various fatal accidents, and so on |
Weapons |
Websites that describe weapons and explosives or provide information on their manufacturing |
Gambling |
Websites that provide access to online games of chance, casinos, auctions, including sites for placing bets, and so on |
Drugs |
Websites that promote use, production or distribution of drugs, and so on |
ObsceneLanguage |
Websites that contain the obscene language (in titles, articles, and so on) |
Chats |
Websites that offer a real-time transmission of text messages |
Terrorism |
Websites that contain aggressive and propaganda materials or terroristic attacks descriptions, and so on. |
FreeEmail |
Websites that offer the possibility of free registration of an email box |
SocialNetworks |
Different social networking services: general, professional, corporate, interest-based; thematic dating websites |
DueToCopyrightNotice |
Websites, links to which are defined by the copyright holders of some copyrighted work (movies, music, and so on) |
OnlineGames |
Websites that provide access to games using the permanent internet connection |
Anonymizers |
Websites that allow the user to hide personal information and providing the access to the blocked web resources |
CryptocurrencyMiningPool |
Websites that provide an access to common services for cryptocurrencies mining |
Jobs |
Job search websites |
As values of the variables sni_category and url_category, it is also possible to use names of the parameters that control blocking (see below).
2.Threat categories (for the threat_category variable)
Convention |
Threat categories |
|---|---|
KnownVirus |
Known threat (virus) |
VirusModification |
Modification of the known threat (virus) |
UnknownVirus |
Unknown threat, suspicious object |
Adware |
Adware |
Dialer |
Dialer |
Joke |
Joke |
Riskware |
Riskware |
Hacktool |
Hacktool |
As a value of the variable threat_category, it is also possible to use names of the parameters that control blocking (see below).
Configuration parameters used in rule conditions
Parameters, used in the component rules of Dr.Web Firewall for Linux (indicated with the LinuxFirewall. prefix):
Parameter |
Description and Usage Example |
|---|---|
Whitelist |
White list, i.e. the list of domains the access to which is allowed, even if these domains are included in the database of categories. Examples: sni_host in "LinuxFirewall.Whitelist" : Pass |
Blacklist |
Black list, i.e. the list of domains the access to which is blocked by the user (or the administrator). Examples: sni_host in "LinuxFirewall.Blacklist" : SET Unwrap_SSL = FALSE |
BlockCategory |
“Metaparameter”: a list of names of web resource categories (Chats, AdultContent, and so on) for which the Block* parameters in the [LinuxFirewall] section are set to Yes. Examples: url_category in "LinuxFirewall.BlockCategory" : Block as _match |
BlockThreat |
“Metaparameter”: a list of names of threat types (KnownVirus, Joke, and so on) for which the Block* parameters in the [LinuxFirewall] section are set to Yes. Examples: threat_category in "LinuxFirewall.BlockThreat" : Block as _match |
ExcludedProc |
The list of trusted processes, whose traffic must be excluded from scanning. Examples: proc in "LinuxFirewall.ExcludedProc" : Pass |
Parameters, used in the component rules of Dr.Web ICAPD (indicated with the ICAPD. prefix):
Parameter |
Description and Usage Example |
|---|---|
Whitelist |
White list contains the list of domains, the access to which is allowed, even if these domains are included in the database of categories. Examples: url_host not in "ICAPD.Whitelist" : Block as BlackList |
Blacklist |
Black list contains the list of domains, the access to which is blocked by the user (or the administrator). Examples: url_host in "ICAPD.Blacklist" : Block as BlackList |
Adlist |
Advertisement list. Contains a list of regular expressions that describe advertising websites. The list is defined by the user (or administrator). Examples: url match "ICAPD.Adlist" : Block as BlackList |
BlockCategory |
“Metaparameter”: a list of names o web resource categories (Chats, AdultContent, etc.) for which the Block* parameters in the [ICAPD] section are set to Yes. Examples: url_category in "ICAPD.BlockCategory" : Block as _match |
BlockThreat |
“Metaparameter”: a list of names of threat types (KnownVirus, Joke, etc.) for which the Block* parameters in the [ICAPD] section are set to Yes. Examples: threat_category in "ICAPD.BlockThreat" : Block as _match |
Features of saving rules to the configuration file
•In the configuration file, in the settings sections of components that use rules, the rules are stored in such variables as RuleSet, each of them is a set (sequence) of unlimited number of rules. In addition, rules in each set are considered sequentially (vertically down) until the ultimate resolution is met.
•When writing an unconditional rule (rule that contains only actions without a conditional part) to the configuration file, an empty conditional part and a separator ':' will be added to it.
For example, the rule, which does not contain a conditional part and consisting only of the action:
Block as _match |
will be written to the configuration file as follows:
: Block as _match |
•When writing a rule, which contains in the action part the set of multiple actions, to the configuration file, it will be written as a sequence of rules with the same conditional part and one action in the action part in the same order as the actions are listed.
For example, the rule that contains two actions in the action part:
user in ('user1', 'user2') : SET http_templates_dir = "/etc/mytemplates", Block as _match |
will be written to the configuration file as sequences of two rules:
user in ('user1', 'user2') : SET http_templates_dir = "/etc/mytemplates" |
•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 an only disjunct-condition in its condition.
For example, the following two rules are equal to the rule “Block if a malicious object KnownVirus or URL from the category Terrorism are detected”:
threat_category in (KnownVirus) : Block as _match |
as the following records are equivalent: (a → x, b → x); ((a → x) ∧ (b → x)); ((a ∨ b) → x).
As for any configuration parameter, values of such parameters as RuleSet (i.e. rules) can be viewed and modified using the commands cfshow and cfset of the management tool Dr.Web Ctl (module drweb-ctl). For further information about the cfshow and cfsetcommand syntax of the command-line management tool Dr.Web Ctl (the drweb-ctl module), refer to the section Dr.Web Ctl.