
|
This section is only applicable for the products containing components for monitoring network connections and mail (SpIDer Gate, Dr.Web MailD).
|
The rules are represented by production rules such as IF <condition> THEN <action>. At that, in the part <condition> the following scanning types are specified: “The variable value is (not) set” or “The variable value is (not) included in the specified set”. The part <action> contains ultimate resolution (skip or block traffic), or an action such as “Assign a value to the variable” or “Add specified value to the set of variable values”.
The <action> part of the rule is executed, only if the <condition> part evaluates to true. If the <condition> part evaluates to false, the action is not performed, and the program jumps to the next rule. The rules are considered downwardly until any of the ultimate resolutions is performed. After this, all lower rules are ignored.
Rule Format
Format of the rule production
[<condition>[, <condition>[, ...]]] : <action>
|
The conditional part of the rule (before ':') can be missing, in this case the <action> part 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 performs a role of a logical conjunction (that is, “and”), and the conditional part elevates to true, only if all its conditions are true. In the rules the register is not important for the key words, names of variables and configuration parameters.
Conditions
The following types of conditions can be use in the conditional part of the rules:
Condition
|
Meaning of the Condition
|
<variable> <value >
|
The value of the specified variable coincides with the set value.
Can be used only for those variables that can contain a set of values simultaneously.
|
<variable> [not] in <set of values>
|
The value of the specified 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 specified variable matches any regular expression listed in the specified set (for not—does not match any expression from the specified set).

|
Regular expressions are specified using either the POSIX syntax (BRE, ERE) or the Perl syntax (PCRE, PCRE2).
|
|
<variable> [not] gt <value>
|
The value of the specified variable is (not) greater than the set value.
Can be used only for those variables that can have a single value.
|
<variable> [not] lt <value>
|
The value of the specified variable is (not) less than the set value.
Can be used only for those variables that can have a single value.
|
*) An 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 the parentheses you directly list the set of values to check against (not less then one value). In case there is only one value and the incontition is used, you can omit the parentheses (and you will end up with a case <variable> <value>).
|
"<section>.<parameter>"
|
The set of values currently assigned to a certain configuration parameter; here between the quotation marks you should specify the name of a configuration parameter whose value (or set of values) must be checked (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>")
|
The set of values is loaded from the specified text file <file name> (one string of the file is one item of the set; leading and trailing spaces are ignored). Path to the file must be absolute. Quotation marks in the <file name> must be escaped by the slash character '\'.

|
Size of the file cannot be great than 64 MB.
File contents is loaded and inserted into the rules only one time – during the configuration file is loaded. If the specified file is unavailable or exceeded the size limit, the x102 error will occur.
If the file contents is changed during the product operating, in order to apply changes you need to restart the program after saving the file. To do that, use the command drweb-ctl reload.
Not all variables allow the set of values from a file. For each of the variables below, it is specified whether you can use a file to determine the set of values.
|
|
<type_of_LOOKUP_request>@<tag>[@<value>]
|
A set of values is requested via Dr.Web LookupD from an external data source (LDAP, ActiveDirectory), where <LOOKUP_request_type> is the type of the data source used (LDAP or AD); <tag> is a section name describing the connection that is used to sample the data, and <value> (optional) is a value that must be contained in the set of values retrieved from the data source.

|
Not all variables can be defined with Dr.Web LookupD and use the condition <check>.
For each of the variables below, it is specified whether you can determine the value of the variable by retrieving the value with the help of Dr.Web LookupD.
|
|
dnsxl(<DNSxL-сервер 1>[: [mask] <IP>][, ...])
|
In the parentheses you list the DNSxL-servers (DNSBL, etc.) that must check the inclusion of an IP address or FQDN (resolved to IP addresses in advance) in their lists of IP addresses.
If the checked IP address is registered in lists of one of the DNSxL servers listed in the parentheses, the response of this server contains one or more DNS logs of type A, and a fictitious IP address returned by the server could contain a reason, why the checked IP address was included in the lists of the server (generally, a type of the reason is defined by the value of the last octet of the returned fictitious IP address). For each DNSxL server in the list, it is possible to assign check of the expected returned value of the fictitious IP address. Check is indicated after the colon in the following way:
•<DNSxL server>: <IP address> •<DNSxL server>: mask <IP address> In the first case, the indicated requirement states that the fictitious IP address returned by the server <DNSxL server> must exactly match the indicated address <IP address>. In the second case, the indicated requirement states that the fictitious IP address returned by the server <DNSxL server> must be equal to the indicated mask in its nonnull octets. If the check parameters are not indicated, the condition works if <DNSxL server> returns any fictitious IP address as a response to the request.
Examples:
<IP> in dnsxl("dnsxl.server.org") – for IP address in the variable <IP>, the server must return any fictitious IP address;
<IP> in dnsxl("dnsxl.server.org": 127.0.0.2)—for IP address in the variable <IP>, the server must return fictitious IP address 127.0.0.2;
<IP> in dnsxl("dnsxl.server1.org": mask 0.0.0.8, "dnsxl.server2.org": 127.0.0.3, "dnsxl.server3.org")—for IP address contained in the variable <IP>, or the first server will return the fictitious IP address with the low octet 8, or the second—fictitious IP address 127.0.0.3, or the third—any fictitious IP address.

|
Use of the check instruction <variable> in dnsxl(<server list>) is allowed only if <variable> is an IP address or a domain name that could be resolved by the DNS service to IP address (FQDN).
Thus, only the following variables could be used as a variable for this condition: src_ip, url_host (see further).
|
|
Actions
The actions can be divided into ultimate resolutions, defining whether the traffic is blocked or allowed and whether the value of any of the variables can be changed, which can be used to check the downward conditions.
Ultimate Resolutions
Resolution
|
Description (Meaning)
|
Common Resolutions
|
PASS
|
Skip traffic (allow creating connection). The downward rules (if there are any) are ignored.
For the rules of mail processing, there is merit in a command that allows a message to be transmitted to a recipient after all collected changes have been applied to it (i. e. all executed actionsREPACK, ADD_HEADER, CHANGE_HEADER, see below).
|
BLOCK as <reason>
|
Block traffic (block creating connection). The downwards rules (if there are any) are ignored.
A blocking <reason> is recorded in the log. The same reason is used to define a browser notification to be shown to a user. Two standard reasons can be used as <reason> for BLOCK:
•BlackList—the data is blocked because it is included in user’s black list. •_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 for which the correspondence has been executed. For the rules of mail processing, this action is synonymous to the action REJECT. The reason for blocking is <reason>, and it is ignored.
|
Special resolutions for rules of mail processing
|
REJECT ["<description>"]
|
Discard an email (prevent its receiving or sending).
While working with data transfered via SMTP protocol, form response code SMTP 541 (class of permanent errors). If an optional parameter <description> is indicated, it will be used as a response. When scanning an email message received from MTA via the Spamd/Rspamd interface, <description> will be used as the value of the header “Message”, which is added to the email after the message with scanning results.
|
TEMPFAIL ["<description>"]
|
Send to the sender as a “temporary error”.
While working with data transfered via SMTP protocol, form response code SMTP 451 (class of temporary errors). If an optional parameter <description> is indicated, it will be used as a response. When scanning an email message received from MTA via the Spamd/Rspamd interface, <description> will be used as the value of the header “Message”, which is added to the email after the message with scanning results.
|
DISCARD
|
Reject an email message, i.e. accept it without return of the error code to the sender, but delete it instead of sending to the recipient.
|
Modifying Resolutions
Modifying resolutions do not interrupt the scanning of rules but fix the actions that should be applied to the scanned data after reaching the permissive resolution PASS.
Resolution
|
Description (Meaning)
|
REPACK [<reason>]
|
Repack the email message, i.e. create (on the basis of one of the predetermined templates) a new email message that contains the contents of the old one and some text with information to the recipient on threats. The removed unwanted contents are placed in the archive protected with password. This archive will be added to the email message sent to the recipient as an attachment. Proceed with the scanning of the email message until the resolution PASS. There are the following predetermined templates for repacking:
1.The email message is spam; 2.One or more threats in the email message; 3.One or more malicious/unwanted URLs in the email message; 4.Violation of the security policy established by the administrator. A REJECT <reason> is recorded in the log. The same reason is used to define which one of four templates was used to generate a notification email to the recipient. As a <reason> for REPACK, the following reasons could be used:
•as _match—the repacking happens if an email message is considered to be spam or if it contains a web source or file with a threat that belong to a category that triggers the rule (for conditions *_category in (...)). The _match variable contains the list of unwanted categories for which the correspondence has been executed. For repacking, template 1, 2 or 3 (see above) is chosen depending on the contents detected in the email message. ▫if the email message is spam, template 1 is chosen; ▫if at least one threat is detected, template 2 is chosen; ▫if at least one malicious/unwanted URL is detected, template 3 is chosen; ▫if threats are not detected, template 4 is chosen. •“text message”—email message was repacked due to triggering of settings of an administrator, and the message indicates an arbitrary message from the administrator. For example: REPACK "Virus found!". For repacking, template 4 will be chosen. |
ADD_HEADER("<Name>", "<Value>")
|
Add the header <Name> to the email message with the value <Value> and continue scanning until the resolution PASS.For example: ADD_HEADER ("X-SPAM", "Virus found!").
The value will be recoded to ASCII according to RFC 2047.
|
CHANGE_HEADER("<Name>", "<Value>" | _value [+ "<Value>" | _value [+ ...]])
|
Replace the value of the first found header with the name <Name>. New value—concatenation of values after the comma separated by the “+” symbol. Each value could be either a string literal in quotation marks, or a special variable _value that is replaced with the initial value of the modified header. Continue scanning of the email message until the PASS resolution .
|
Aspects of Resolution Processing:
•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.

|
For SpIDer Gate’s rules that process non-mail-related connections (i.e. when the previous condition says that the traffic must be HTTP traffic), the triggering of a mail-related resolution is treated as equivalent to the triggering of a BLOCK as BlackList resolution (additionally, a message about applying an unknown action is recorded into the log).
In the rules for Dr.Web ICAPD, mail-related resolutions have no meaning and no effect: the rules that contain mail-related resolutions are ignored without any reaction to them.
|
Changing Value of a Variable
To change the variable value, the following instruction is used:
SET<variable> = ([<value 1>[, <value 2>[, ...]]])
|
If nothing is enclosed in brackets, the list of variable values is cleared. If there is only one value, the brackets should be omitted, that is, the following syntaxes should be used:
SET <variable> = <value >
|
Variables used in the rules
When indicating variables in the rules, the register of symbols is not considered. The variables with compound names could be saved using underscore for spacing or without it. Thus, records variable_name, VariableName and variablename represent the same variable. In this section, all variables are saved using underscore (i.e. variable_name).
General purpose variables
Variable
|
Description
|
Can be used in
|
conditional part
|
action part (SET)
|
protocol
|
Network protocol type, used by the connection.
The variable can simultaneously contain a set of 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. •It does not make sense to specify any other value exceptHTTP for the Dr.Web ICAPD rules: only HTTP can be specified for Dr.Web ICAPD. •You can use a file to determine the set of values. Examples:
protocol in (HTTP, SMTP)
protocol in (POP3)
protocol in file("/etc/file")
|
Yes
|
No
|
sni_host
|
SNI host (address), with which the connection is established via SSL/TLS.
Usage Aspects:
•If SSL is not used, the value of a variable is not defined, the condition evaluates to false. •It does not make sense to use it for the Dr.Web ICAPD rules (it does not process SSL, for that reason the condition always evaluates to false). •You can use a file to determine the set of values Examples:
sni_host not in ('vk.com', 'ya.ru')
sni_host in "LinuxFirewall.BlackList"
sni_host in file("/etc/file")
|
Yes
|
No
|
sni_category
|
The list of categories (AdultContent, etc.) 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 simultaneously contain a set of values.
Usage Aspects:
•If SSL is not used, the value of a variable is not defined, the condition evaluates to false. •It does not make sense to use it for the Dr.Web ICAPD rules (it does not process SSL, for that reason the condition always evaluates to false). •For rules used by Dr.Web MailD and Dr.Web ICAPD, condition with not in will be true, even if according to the scanning results, the host does not belong to any of the predetermined categories (“safe” host). For rules of Dr.Web Firewall for Linux (SpIDer Gate), the condition in this case will be false. •You can use a file to determine the set of values Examples:
sni_category not in (AdultContent, Chats)
sni_category in "LinuxFirewall.BlockCategory"
sni_category in (FreeEmail)
sni_category not in file("/etc/file")
|
Yes
|
No
|
url
|
URL requested by the client. Can be compared with the specified string or with a regular expression.
Usage Aspects:
•Can be used only in rules for Dr.Web ICAPD. •Dr.Web LookupD can be used to check the value of this variable. •You can use a file to determine the set of values. Examples:
url match ("drweb.com", "example\..*", "aaa\.ru/")
url match "ICAPD.Adlist"
url not match LDAP@BadURLs
url match file("/etc/file")
|
Yes
|
No
|
url_host
|
URL/host with which the connection is established.
Usage Aspects:
•The variable value can be defined only if SSL/TLS is not used or it was allowed to unwrap SSL. •Dr.Web LookupD can be used to check the value of this variable. •This variable could be checked for inclusion in black lists of DNSxL (DNSBL, etc.). •You can use a file to determine the set of values. Examples:
url_host in ('vk.com', 'ya.ru')
url_host not in "ICAPD.Whitelist"
url_host in LDAP@hosts
url_host not in file("/etc/file")
url_host not in dnsxl("multi.surbl.org": 127.0.0.2, "multi2.surbl.org")
|
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 simultaneously contain a set of values.
Usage Aspects:
•The variable value can be defined only if SSL/TLS is not used or it was allowed to unwrap SSL. •For rules used by Dr.Web MailD and Dr.Web ICAPD, condition with not in will be true, even if according to the scanning results, URL/host does not belong to any of the predetermined categories (“safe” URL/host). For rules of Dr.Web Firewall for Linux (SpIDer Gate), the condition in this case will be false. •You can use a file to determine the set of values. Examples:
url_category not in (AdultContent, Chats)
url_category in "LinuxFirewall.BlockCategory"
url_category in (FreeEmail)
url_category in file("/etc/file")
|
Yes
|
No
|
threat_category
|
The list of categories to which the threat belongs, which is found in the transferred data (according to our databases).
The variable can simultaneously contain a set of values.
Usage Aspects:
•The variable value can be defined only if SSL/TLS is not used or it was allowed to unwrap SSL. •For rules used by Dr.Web MailD and Dr.Web ICAPD, condition with not in will be true, even if according to the scanning results, the object does not contain threats from any of the predetermined categories (“safe” object). For rules of Dr.Web Firewall for Linux (SpIDer Gate), the condition in this case will be false. •You can use a file to determine the set of values. Examples:
threat_category in "LinuxFirewall.BlockThreat"
threat_category not in (Jokes)
threat_category in file("/etc/file")
|
Yes
|
No
|
user
|
The name of the user with whose privileges the process that is sending (or receiving) the traffic has been launched.
Usage Aspects:
•In the Dr.Web ICAPD rules, the name of that user is implied who has authenticated on the proxy server (if the proxy server supports authentication). If the proxy server does not support user authentication, the variable has an empty value. •Dr.Web LookupD can be used 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. •You can use a file to determine the set of values. Examples:
user in ('user1', 'user2')
user in AD@Winusergroups@Admins
user in LDAP@AllowedUsers
user not in file("/etc/file")
|
Yes
|
No
|
src_ip
|
The IP address of a host establishing the connection.
Usage Aspects:
•Dr.Web LookupD can be used to check the value of this variable. •This variable cannot be used in rules of Dr.Web MailD for the interface Spamd: this protocol does not provide information about the email message sender. •This variable could be checked for inclusion in black lists of DNSxL (DNSBL, etc.). •You can use a file to determine the set of values. Examples:
src_ip not in (127.0.0.1, 10.20.30.41, 198.126.10.0/24)
src_ip in LDAP@AllowedAddresses
src_ip not in file("/etc/file")
src_ip in dnsxl("zen.spamhouse.org": mask 0.0.0.2, "zen2.spamhouse.org")
|
Yes
|
No
|
proc
|
The process establishing the connection (the full path to the executable file).
Usage Aspects:
•It does not make any sense to use it for the Dr.Web ICAPD rules (the component does not contain information about processes, for that reason the condition always evaluates to false). •You can use a file to determine the set of values. Examples:
proc in ('/usr/bin/ls')
proc not in ('/home/user/myapp', '/bin/bin1')
proc in "LinuxFirewall.ExcludedProc"
proc in file("/etc/file")
|
Yes
|
No
|
direction
|
The type of traffic on the connection.
Allowed values: request (client request), response (server reply).
This variable cannot simultaneously contain a set of values; conditions of the match and in type cannot be applied.
Examples:
direction request
direction not response
|
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 simultaneously contain a set of values; conditions of the match and in type cannot be applied.
Examples:
divert input
divert not output
|
Yes
|
No
|
content_type
|
MIME type of data transferred during connection.
Usage Aspects:
•Can be defined if only SSL/TLS is not used or it was allowed to unwrap SSL. •The expression “*/*” matches data of any MIME type and HTTP replies without the header Content-Type. •Dr.Web LookupD can be used to check the value of this variable. •You can use a file to determine the set of values. Examples:
content_type in ("multipart/byteranges", "application/octet-stream")
content_type not in ("text/*", "image/*")
content_type not in ("audio/*")
content_type in ("*/*")
content_type in LDAP@BlockedContent
content_type not in file("/etc/file")
|
Yes
|
No
|
unwrap_ssl
|
Whether the traffic transferred via SSL/TLS is unwrapped.
Allowed values: true, false.
Usage Aspects:
•The variable always has any value. The instruction SET unwrap_ssl = () is impossible. •The variable cannot be used as a condition. It is necessary only to control SSL unwrapping (for example, to display a webpage containing notification about blocking triggered by our side). •It does not make sense to use it for the Dr.Web ICAPD rules (it does not process SSL, changing of the variable does not influence rule processing). Examples:
SET unwrap_ssl = TRUE
set Unwrap_SSL = false
|
No
|
Yes
|
http_templates_dir
|
The path to the directory where the notification page template on blocking HTTP request is stored.
If the path starts with a / (forward slash), it is an absolute path; if it starts with any other symbol, then it is a relative path. In the latter case it is given relative to the directory specified in the TemplatesDirparameter.
Usage Aspects:
•It is useful only for the HTTP(S) protocol. Examples:
SET http_templates_dir = "/etc/mytemplates"
set http_templates_dir = "templates_for_my_site"
|
No
|
Yes
|
Variables used in the rules of mail processing
Variable
|
Description
|
Can be used in
|
conditional part
|
action part (SET)
|
header
|
Contents of email message headers.
Usage Aspects:
•Used for comparison of header areas with the list of specified templates (regular expressions are used). •Any of the headers represented in the email message could be checked. •Comparison is not case-sensitive, Unicode could be used. •You can use a file to determine the set of values. Examples:
header match ("su..ect: sp.m", "From: sales.*@.*")
Header not match ("Subject: .*buy.*")
header match file("/etc/file")
|
Yes
|
No
|
body
|
Text contents of the email message body.
Usage Aspects:
•Used for comparison of email message body with the list of specified templates (regular expressions are used). •Any text part of the email message could be checked. •Comparison is not case-sensitive, Unicode could be used. •You can use a file to determine the set of values. Examples:
body match (“e.ternit[y] ")
body not match file("/etc/file")
|
Yes
|
No
|
body_part_header
|
Headers of the parts of the email message body (MIME part).
Usage Aspects:
•Used for comparison of headers in sections of the email message body with the list of specified templates (regular expressions are used). •Any header of any part in the email message body could be checked. •Comparison is not case-sensitive, Unicode could be used. •You can use a file to determine the set of values. Examples:
body_part_header match ('Content-Disposition: attachment; .*filename=”virus.exe"')
BodyPartHeader not match ("Content-Disposition: attachment; .*")
body_part_header match file("/etc/file")
|
Yes
|
No
|
attachment_name
|
Name of attached files.
Usage Aspects:
•Used for comparison of names of files (Content-Disposition: attachment), attached to an email with a list of specified templates (regular expressions are used). •Comparison is not case-sensitive, Unicode could be used. •You can use a file to determine the set of values. Examples:
attachment_name match ("\.ex.$", "\.js$", "^virus.*")
attachment_name not match ("\.txt$", "\.rtf$")
attachment_name not match file("/etc/file")
|
Yes
|
No
|
total_spam_score
|
Normalized rating of an email message as spam (from 0 to 100) received from Dr.Web ASE.
Normalization of spam scoring received from Dr.Web ASE is performed according to the following rules:
1.0 points and less—0.0; 2.100 points—0.8; 3.1000 points and more—1.0. In the indicated intervals normalized scoring increases.
Usage Aspects:
•Numerical variable always has one value and could be used only with the conditions of the following types: lt and gt. •If Dr.Web ASE is not installed, scanning of email messages for spam is not performed, and the variable total_spam_score could not be used in rules (attempts to check if a condition in the rule is true will lead to the error “Dr.Web ASE is unavailable”. Example:
total_spam_score gt 0.32
total_spam_score gt 0.5, total_spam_score lt 0.95
|
Yes
|
No
|
smtp_mail_from
|
Address of the sender sent withing the SMTP sessions by the command MAIL FROM.
Usage Aspects:
•Used for comparison of the name of the sender indicated within an SMTP session with the list of specified templates (regular expressions are used). •Comparison is not case-sensitive. •This variable cannot be used in rules of the interface Spamd: this protocol does not provide information about the email message sender. •You can use a file to determine the set of values. Examples:
smtp_mail_from match ("^john@.*", ".*@domain.com$")
smtp_mail_from not match ("^user@domain.com$")
smtp_mail_from match file("/etc/file")
|
Yes
|
No
|
smtp_rcpt_to
|
List of addresses of the email message recipients sent withing the SMTP sessions by the command RCPT TO.
Usage Aspects:
•Used for comparison of the recepeint names indicated within an SMTP session with the list of specified templates (regular expressions are used). •Comparison is not case-sensitive. •This variable cannot be used in rules of the interface Spamd: this protocol does not provide information about the email message recipient. •If before match there is all, then the condition with this variable will be true only in case of the match of all values from the list with the indicated templates. •You can use a file to determine the set of values. Examples:
smtp_rcpt_to match ("^user1@domain.com$", ".*@domain2.com$")
smtp_rcpt_to all match ("^john@.*", ".*@domain.com$")
smtp_rcpt_to match file("/etc/file")
|
Yes
|
No
|
maild_templates_dir
|
The path to the directory with a template used for repacking of email messages.
If the path starts with a / (forward slash), it is an absolute path; if it starts with any other symbol, then it is a relative path. In the latter case it is given relative to the directory specified in the TemplatesDirparameter in the [MailD] section.
Usage Aspects:
•It is useful only for mail protocols (POP3, IMAP, SMTP) and for MTA interfaces (Milter, Spamd, Rspamd). Examples:
SET maild_templates_dir = "/etc/my_mail_templates"
set MaildTemplatesDir = "templates_for_my_MTA"
|
No
|
Yes
|
Configuration parameters that can be used in rule conditions
Parameters used in the component rules ofDr.Web Firewall for Linux (indicated with the prefix LinuxFirewall.):
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:
sni_host in "LinuxFirewall.Whitelist" : PASS
url_host not in "LinuxFirewall.Whitelist" : BLOCK as _match
|
Blacklist
|
Black list contains 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
url_host in "LinuxFirewall.Blacklist" : BLOCK as BlackList
|
BlockCategory
|
“Meta-parameter”: its value is a list that contains the names of those web resourse categories (Chats, AdultContent, etc.) for which the corresponding Block* parameters in the [LinuxFirewall] section are set to Yes.
Examples:
url_category in "LinuxFirewall.BlockCategory" : BLOCK as _match
sni_category in "LinuxFirewall.BlockCategory" : BLOCK as BlackList
|
BlockThreat
|
“Meta-parameter”: its value is a list that contains the names of those threat types (KnownViruses, Jokes, etc.) for which the corresponding 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 skipped from checking.
Examples:
proc in "LinuxFirewall.ExcludedProc" : PASS
|
|