In this section
•Categories of Unwanted Websites and Threats
•Configuration Parameters Used in Rule Conditions
•Aspects of Writing Rules to the Configuration File
The rules are represented by such constructs as IF <conditional part> THEN <action part>. The following condition types are specified in the conditional part: “The variable value is (not) set” or “The variable value is (not) included in the specified set”. The action part contains a set of actions (at least one action), whereas each of them is a final resolution (skip or block a scanned object) or a modifying action such as “Change properties of the scanned object”, “Set the indicated variable to the specified value” or “Add the specified value to a set of values of the indicated variable”.
The actions specified in a rule are performed 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 goes to the next rule. The rules are processed from top to bottom until a final resolution is triggered. After this, all rules below (if there are any) are ignored.
|
When a rule is triggered, the actions in the action part are performed from left to right in order in which they are specified, and if there is a final resolution in the chain of actions that interrupts the rule processing, the actions following it are not performed. |
The rules have the following format:
[<condition>[, <condition>[, …]]] : <action>[, <action>[, …]] |
The conditional part of the rule (before the “:” character) can be absent, in this case the action part is performed without any condition. If the conditional part of the rule is absent, 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, logical “AND”): the conditional part is 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 a final resolution, which interrupts the rule handling, is reached. Key words, names of variables and configuration parameters used in the rules are case-insensitive.
The following types of conditions can be used in the rules:
Condition |
Comment |
||
|---|---|---|---|
<variable> <value> |
The variable value matches the specified one. Can be used only for variables that do not accept a set of values. |
||
<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 a regular expression from 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 specified value. Can be used only for variables that have a single numerical value. |
||
<variable> [not] lt <value> |
The value of the variable is (not) less than the specified value. Can be used only for variables that have a single numerical value. |
*) The optional key word not means negation.
The part <set of values> to which the variable is compared can be specified in the following ways:
Syntax |
Meaning |
|||
|---|---|---|---|---|
(<value 1>[, <value 2>[, …]]) |
A set of values to check against (no less than one value) is listed directly in the parentheses. In case there is only one value and the in condition is used, you can omit the parentheses (and you will end up with <variable> <value>). |
|||
"<section>.<parameter>" |
A set of configuration parameters, where a parameter whose value (or a set of values) is to be checked is put in quotation marks (a section to which the parameter belongs is also specified). Lists of parameters that can be used in a condition depend on the component for which the rules are set and are provided below. |
|||
file("<file name>") |
A list of values is read from a text file <file name> (one line per a list item, leading and trailing spaces in strings are ignored). A path to the file must be absolute. If the <file name> contains quotation marks and apostrophes, they must be escaped with a backslash ('\').
|
|||
<LOOKUP_query_type>@<tag>[@<value>] |
A set of values is queried via Dr.Web LookupD from an external data source, where <LOOKUP_query_type> is a type of the source, <tag> is a name of the section describing a connection for checked parameter sampling, and optional <value> is a value that must be in the set of the values retrieved from the data source.
|
|||
dnsxl(<DNSxL server 1>[: [mask] <IP>][, …]) |
The brackets contain a list of DNSxL servers (DNSBL and so on) that must check whether their lists of IP addresses include an IP address or FQDN (resolved to the IP address in advance). If the IP address in check is included in the lists of one of the DNSxL servers put in brackets, the response of this server contains one or more DNS records of type A; furthermore, a fake IP address returned by the server can contain a reason why the IP address in check was included in the lists of the server (generally, a type of the reason is determined by a value of the last octet of the returned fake IP address). For each DNSxL server in the list, it is possible to assign check of the expected returned value of the fake IP address. The check is specified after the colon as follows: •<DNSxL server>: <IP address> •<DNSxL server>: mask <IP address> The first case requires the fake IP address returned by the server <DNSxL server> to exactly match the specified address <IP address>. The second case requires the fake IP address returned by the server <DNSxL server> to exactly match the specified mask in its nonnull octets. If the check parameters are not specified, the condition is triggered if <DNSxL server> returns any fake IP address as a response to the request. Examples: <IP> in dnsxl("dnsxl.server.org")—for the IP address contained in the <IP> variable, the server must return any fake IP address;
|
If a variable is multiple-valued, the condition <variable> in <set of values> is true, if an intersection of the set of current values of the specified variable <variable> with the indicated set <set of values> is not empty. Otherwise, the condition not in is true.
For example, suppose X is a variable whose current value is a set containing values a, b and c. Then:
•X in (a, b) is true, because values а and b are present in both sets;
•X in (a, d, e) is true, because value а is present in both sets;
•X in (d, e) is false, because none of the values of variable (a, b, c) is in set (d, e);
•X in () is false, because the set of variable values is not empty;
•X not in () is true, because the set of variable values is not empty;
•X not in (d, e) is true, because none of the values of variable (a, b, c) is in set (d, e);
•X not in (a, d, e) is false because value а is present in both sets.
The description of each variable below indicates whether it accepts a set of values.
Actions are grouped into final resolutions, which determine whether to allow or deny passing an object, and actions changing variable values, which can be used when checking conditions in further rules.
Final resolutions
Resolution |
Description (meaning) |
|---|---|
General resolutions |
|
PASS |
Pass the traffic (allow establishing a connection and sending the object to the recipient). The further rules (if there are any) are not used. |
BLOCK as <reason> |
Block the traffic (deny establishing a connection and sending the object to the recipient). Further rules (if there are any) are not used. The reason <reason> for blocking is logged. The same reason is used to determine which page with the notification should be displayed to the user in a browser. Two common reasons can be used as <reason> for BLOCK: •BlackList—the data is blocked because it has been blacklisted by the user. •_match—blocking occurs because a web resource or a file containing a threat belongs to a category that triggers a rule (for conditions *_category in (...)). The _match variable contains a list of blocked categories for which a match has been found. |
Aspects of processing final resolutions:
•BLOCK as BlackList is always processed as “is blacklisted” (irrespective of the condition specified in the rule with this resolution).
•BLOCK as _match, if _match is not empty, is processed as “belongs to the _match category(-ies)”.
•BLOCK as _match, if _match is empty, is processed as “is blacklisted” (irrespective of a condition specified in a rule with this resolution).
•If all rules have been processed, and none of the rules with the resolution has triggered (or the rules do not have resolutions), this is equivalent to applying the PASS action to the connection.
Changing a variable value
To change a variable value, use the following instruction:
SET <variable> = ([<value 1>[, <value 2>[, …]]]) |
If there are no values in parentheses, the list of the variable values will be cleared:
SET <variable> = () |
If the variable has only one value, the parentheses are not used:
SET <variable> = <value> |
When indicating variables in the rules, the character case is ignored. Multiword variables can be named with or without an underscore to separate words. Thus, a variable can be named variable_name, VariableName or variablename. In this section, all variables contain the underscore (that is, the variable_name variant is used).
Variable |
Description |
Can be used in |
|
|---|---|---|---|
condition |
action (SET) |
||
protocol |
Network protocol type used by the connection. The variable accepts multiple values. Allowed values: HTTP, SMTP, IMAP and POP3. Usage Aspects •The variable value is defined only if SSL/TLS is not used or SSL scanning is enabled. •Dr.Web ICAPD rules accept only HTTP as its value. •A set of values for checking the variable value can be read from a file. Examples: protocol in (HTTP, SMTP) |
Yes |
No |
sni_host |
SNI (address) of the host to which the connection is established via SSL/TLS. Usage Aspects •If SSL is not used, the variable value is not defined; therefore, the condition is false. •Dr.Web ICAPD rules do not use this variable (this component does not process SSL; therefore, the condition is always false). •A set of values for checking the variable value can be read from a 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 |
List of categories (AdultContent and so on) to which the host (identified by SNI) belongs in accordance with the databases of web resource categories; the connection to the host is established via SSL/TLS. The variable accepts multiple values. Usage Aspects •If SSL is not used, the variable value is not defined; therefore, the condition is false. •There is no point in using the variable in Dr.Web ICAPD rules (this component does not process SSL, so the condition is always false). •A condition with not in is true in the rules used by Dr.Web ICAPD, even if the host does not belong to any of the predetermined categories (“safe” host). The condition is false in this case for Dr.Web Firewall for Linux (SpIDer Gate) rules. •If databases of web resource categories are not installed, do not use the variable in the rules (attempts to check if a condition in the rule is true will cause error x112). •A set of values for checking the variable value can be read from a file. Examples: sni_category not in (AdultContent, Chats) |
Yes |
No |
url |
URL requested by the client. Can be compared with a string or a regular expression. Usage Aspects •Can be used only in Dr.Web ICAPD rules. •You can use Dr.Web LookupD to check the value of this variable. •A set of values for checking the variable value can be read from a 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 or host to which the connection is established. Usage Aspects •The variable value is defined only if SSL/TLS is not used or SSL scanning is enabled. •You can use Dr.Web LookupD to check the value of this variable. •A set of values for checking the variable value can be read from a file. Examples: url_host in ('vk.com', 'ya.ru') |
Yes |
No |
url_category |
List of categories to which the URL or the host to which the connection is established belongs (in accordance with the databases of web resource categories or the Dr.Web Cloud response). The variable accepts multiple values. Usage Aspects •The variable value is defined only if SSL/TLS is not used or SSL scanning is enabled. •A condition with not in is true in the rules used by Dr.Web ICAPD, even if the URL or the host does not belong to any of the predetermined categories (“safe” URL or host). The condition is false in this case for Dr.Web Firewall for Linux (SpIDer Gate) rules. •If databases of web resource categories are not installed, do not use the variable in the rules (attempts to check if a condition in the rule is true will cause error x112). •A set of values for checking the variable value can be read from a file. Examples: url_category not in (AdultContent, Chats) |
Yes |
No |
threat_category |
List of categories to which a threat found in transmitted data is related in accordance with the virus databases. The variable accepts multiple values. Usage Aspects •The variable value is defined only if SSL/TLS is not used or SSL scanning is enabled. •A condition with not in is true for the rules used by Dr.Web ICAPD, even if the object does not contain threats from any of the predetermined categories (“safe” object). The condition is false in this case for Dr.Web Firewall for Linux (SpIDer Gate) rules. •A set of values for checking the variable value can be read from a file. Examples: threat_category in "LinuxFirewall.BlockThreat" |
Yes |
No |
user |
User on behalf of whom a process for sending (or receiving) traffic is started. Usage Aspects •In the Dr.Web ICAPD rules, the name of the user who has authenticated on a proxy server is implied (if the proxy server supports authentication). If the proxy server does not support user authentication, the variable has an empty value. •You can use Dr.Web LookupD to check the value of this variable. If you need to find out whether a user belongs to a certain group, use an LDAP or Active Directory data source that returns a list of groups. The query must also contain a condition for comparing the name of the group that includes the user with the required group name (use the following format: <type of the LookupD source>@<source of groups>@<required group>). Queries to Active Directory (AD@) return only lists of groups; therefore, it is mandatory to use the @<required group> part for these queries. •A set of values for checking the variable value can be read from a file. Examples: user in ('user1', 'user2') |
Yes |
No |
src_ip |
IP address of the 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 the variable value can be read from a file. Examples: src_ip not in (127.0.0.1, 10.20.30.41, 198.126.10.0/24) |
Yes |
No |
proc |
Process establishing the connection (the full executable path). Usage Aspects •There is no point in using this variable in Dr.Web ICAPD rules (this component does not have information about processes, so the condition is always false). •A set of values for checking the variable value can be read from a 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 |
Connection traffic type. Allowed values: request (client request), response (server response). This variable does not accept multiple values; conditions of the match and in type cannot be applied. Examples: direction request |
Yes |
No |
divert |
Connection direction. Allowed values: input (incoming—created or initiated outside of the local host), output (outgoing—created or initiated on the local host). This variable does not accept multiple values; conditions of the match and in type cannot be applied. Examples: divert input |
Yes |
No |
content_type |
MIME type of data transmitted via connection. Usage Aspects •The variable value is defined only if SSL/TLS is not used or SSL scanning is enabled. •The expression “*/*” matches data of any MIME type and HTTP responses without the Content-Type header. •You can use Dr.Web LookupD to check the value of this variable. •A set of values for checking the 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 a type of the network activity and can accept one of the following values: •sni_host—SNI (address) of the host to which the connection is established via SSL/TLS (see above); •url—URL requested by a client (see above); •dst_address—network address (<IP address>:<port>) at which the process establishes the connection. Usage Aspects •Used 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>. •There is no point in using this variable in Dr.Web ICAPD rules (this component does not have information about processes, so the condition is always false). Examples: (proc, url) match ({"/usr/bin/wget", "www\.ya\.*"}) |
Yes |
No |
|
unwrap_ssl |
Scan or do not scan secure traffic passing via SSL/TLS. Allowed values: true, false. Usage Aspects •The value of the variable cannot be empty. The instruction SET unwrap_ssl = () is illegal. •The variable cannot be used in conditions and is necessary only to manage SSL scanning (for example, to display a webpage containing notification about blocking). •There is no point in using this variable in Dr.Web ICAPD rules (this component does not process SSL, changing the variable value does not influence rule processing). Examples: SET unwrap_ssl = TRUE |
No |
Yes |
http_templates_dir |
Path to the directory storing block page templates. If the path starts with the “/” character, it is an absolute path; if it starts with any other character, it is a relative path. In the latter case, the root directory is defined by a path specified in the TemplatesDir parameter. Usage Aspects •Can be used only for HTTP(S). 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 and url_category)
Convention |
Website category |
|---|---|
InfectionSource |
Websites containing malware (“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 and so on |
Gambling |
Websites that provide access to gambling, online 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 obscene language (in section titles, articles and so on) |
Chats |
Websites that offer real-time exchange of text messages |
Terrorism |
Websites that contain aggressive and propaganda materials or description of terrorist attacks and so on |
FreeEmail |
Websites that offer free email registration |
SocialNetworks |
Various social networking services: general, professional, corporate, interest-based; special dating websites |
DueToCopyrightNotice |
Websites, links to which are provided by copyright holders of some copyrighted work (movies, music and so on) |
OnlineGames |
Websites that provide access to games using permanent internet connection |
Anonymizers |
Websites that allow the user to hide personal information and grant access to blocked web resources |
CryptocurrencyMiningPool |
Websites that grant access to services uniting users to mine cryptocurrencies |
Jobs |
Job search websites |
As values of the variables sni_category and url_category, you can also use names of the parameters that control blocking (see below).
2.Threat categories (for the threat_category variable)
Convention |
Threat categories |
|---|---|
KnownVirus |
Known threat |
VirusModification |
Modification of a known threat |
UnknownVirus |
Unknown threat, suspicious object |
Adware |
Adware |
Dialer |
Dialer |
Joke |
Joke program |
Riskware |
Riskware |
Hacktool |
Hacktool |
As a value of the threat_category variable, you can also use names of the parameters that control blocking (see below).
Configuration Parameters Used in Rule Conditions
Parameters used in the Dr.Web Firewall for Linux component rules and indicated with the LinuxFirewall. prefix:
Parameter |
Description and usage example |
|---|---|
Whitelist |
White list, i.e. a list of domains the access to which is allowed, even if these domains are included in the database of web resource categories. Examples: sni_host in "LinuxFirewall.Whitelist" : PASS |
Blacklist |
Black list contains a 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 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 |
List of trusted processes whose traffic must be excluded from scanning. Examples: proc in "LinuxFirewall.ExcludedProc" : PASS |
Parameters used in the Dr.Web ICAPD component rules and indicated with the ICAPD. prefix:
Parameter |
Description and usage example |
|---|---|
Whitelist |
White list contains a list of domains the access to which is allowed, even if these domains are included in the database of web resource categories. Examples: url_host not in "ICAPD.Whitelist" : BLOCK as BlackList |
Blacklist |
Black list contains a 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 cover advertising websites. The list is defined by the user or the administrator. Examples: url match "ICAPD.Adlist" : BLOCK as BlackList |
BlockCategory |
“Metaparameter”: a list of categories (Chats, AdultContent and so on) 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 |
Aspects of Writing Rules to the Configuration File
•The rules are stored in the configuration file, in the settings sections of components that use rules, in such variables as RuleSet, each of them is a set (sequence) of an unlimited number of rules. In addition, rules in each set are processed sequentially (from top to bottom) until the final resolution is reached.
•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 that does not contain a conditional part and consists only of an action:
BLOCK as _match |
will be written to the configuration file as follows:
: BLOCK as _match |
•When writing a rule whose action part contains a 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 the sequence of two rules:
user in ('user1', 'user2') : SET http_templates_dir = "/etc/mytemplates" |
•Since the rule structure does not provide for a disjunction (logical “OR”) of conditions in the conditional part, in order to implement logical “OR”, write a chain of rules with each rule having a single disjunctive condition in its condition.
For example, the following two rules are equal to the rule “Block upon detection of a malicious object of the KnownVirus type or a URL from the Terrorism category”:
threat_category in (KnownVirus) : BLOCK as _match |
since the following records are logically equivalent: (a → x, b → x); ((a → x) ∧ (b → x)); ((a ∨ b) → x).
As for any configuration parameter, values of parameters of the RuleSet type (i.e. rules) can be viewed and changed using the cfshow and cfset commands of the Dr.Web Ctl management tool (the drweb-ctl module). For further information about the syntax of these commands, refer to the Dr.Web Ctl section.