The component uses configuration parameters which are specified in the [LinuxFirewall] section of the integrated configuration file of Dr.Web for UNIX.
The section contains the following parameters:
LogLevel = {logging level}
|
Logging level.
If the parameter value is not specified, the DefaultLogLevel parameter value from the [Root] section is used.
Default value:
LogLevel = Notice
|
Log = {log type}
|
Logging method.
Default value:
Log = Auto
|
ExePath = {path to file}
|
Path to the executable file of the component.
Default value:
ExePath = <opt_dir>/bin/drweb-firewall
•For Linux: ExePath = /opt/drweb.com/bin/drweb-firewall
•For FreeBSD: ExePath = /usr/local/libexec/drweb.com/bin/drweb-firewall
•For Solaris: ExePath = /opt/drweb.com/bin/drweb-firewall
|
InspectHttp = {On | Off}
|
Instructs whether to check the data transferred over the HTTP protocol.
Default value:
InspectHttp = On
|
InspectSmtp = {On | Off}
|
Instructs whether to check data transferred over SMTP protocol (if installed, the Dr.Web MailD component is used).
Default value:
InspectSmtp = Off
|
InspectPop3 = {On | Off}
|
Instructs whether to check the data transferred over the POP3 protocol (if installed, the Dr.Web MailD component is used).
Default value:
InspectPop3 = Off
|
InspectImap = {On | Off}
|
Instructs whether to check data transferred over IMAP protocol (if installed, the Dr.Web MailD component is used).
Default value:
InspectImap = Off
|
InputDivert = {Off | Auto(interface:<i_name> protected:<p_list>)}
|
Defines the used method of diverting incoming connections (redirecting it to the SpIDer Gate checking component).
Allowed values:
•Off—redirecting of incoming connections is disabled. •Auto(interface:<i_name> protected:<p_list>)—redirection of incoming connections in automatic mode. Rules are controlled by Dr.Web Firewall for Linux. Connections that comes via the specified network interface <i_name> into the <p_list> port list are monitored. Port numbers in the <p_list> list are separated by commas. For example, Auto(interface:eth0 protected:80,8080). Default value:
InputDivert = Off
|
OutputDivert = {Off | Auto}
|
Defines the used method of diverting outgoing connections (redirecting it to the SpIDer Gate checking component).
Allowed values:
•Off—redirecting of outgoing connections is disabled. •Auto—redirection of outgoing connections in automatic mode. Dr.Web Firewall for Linux manages the rules. Default value:
OutputDivert = Auto
|
ExcludedProc = {path to file}
|
The list of processes whose network activity must not be monitored.
You can specify a list as the parameter value. The values in the list must be separated with commas. The parameter can be specified more than once in the section (in this case, all its values are combined into one list).
To block verification of the connections established bu trusted applications, you should check that within the settings there is also a rule that looks like (see the details below):
proc in "LinuxFirewall.ExcludedProc" : PASS
|
If there is no such rules, the activity of the listed processes is monitored.
Default value:
ExcludedProc =
|
SniCheckAddress = {boolean}
|
If set to true, during the SSL Handshake stage, performs a check of the SNI host to which you are trying to connect, to see if this host is listed in the black list or belongs to the blocked category. The check is performed without unwrapping the SSL.
In the current realization, the value of this variable does not influence the processing of protected traffic. To control such processing, it is necessary to create a rule containing the sni_host in and sni_category in conditions (see below).
If you change the value of this parameter with the help of the cfsetcommand of the drweb-ctl utility or with the help of the web interface, the affected dependent rules will adapt automatically.
Default value:
SniCheckAddress = No
|
UnwrapSsl = {Boolean}
|
Instructs to check encrypted traffic transferred via the SSL/TLS connections.
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 cfsetcommand of the drweb-ctl utility or with the help of the web interface, the affected dependent rules will adapt automatically.
Default value:
UnwrapSsl = No
|
HttpSafeSearch = {Boolean}
|
Instructs to use the “Safe search” option for searching engines that support this mode.
Default value:
HttpSafeSearch = No
|
BlockInfectionSource = {Boolean}
|
Instructs to block attempted connections to websites containing malicious software (included into the InfectionSource category).
For the blocking to work, you should check that within the settings there is also a rule that looks like (see the details below):
url_category in "LinuxFirewall.BlockCategory" : BLOCK as _match
|
Default value:
BlockInfectionSource = Yes
|
BlockNotRecommended = {Boolean}
|
Instructs to block attempts of connection to non-recommended websites (included into the NotRecommended category).
For the blocking to work, you should check that within the settings there is also a rule that looks like (see the details below):
url_category in "LinuxFirewall.BlockCategory" : BLOCK as _match
|
Default value:
BlockNotRecommended = Yes
|
BlockAdultContent = {Boolean}
|
Instructs to block attempts of connection to websites containing adult content (included into the AdultContent category).
For the blocking to work, you should check that within the settings there is also a rule that looks like (see the details below):
url_category in "LinuxFirewall.BlockCategory" : BLOCK as _match
|
Default value:
BlockAdultContent = No
|
BlockViolence = {Boolean}
|
Instructs to block attempts of connection to websites containing graphic violence (included into the Violence category).
For the blocking to work, you should check that within the settings there is also a rule that looks like (see the details below):
url_category in "LinuxFirewall.BlockCategory" : BLOCK as _match
|
Default value:
BlockViolence = No
|
BlockWeapons = {Boolean}
|
Instructs to block attempts of connection to websites dedicated to weapons (included into the Weapons category).
For the blocking to work, you should check that within the settings there is also a rule that looks like (see the details below):
url_category in "LinuxFirewall.BlockCategory" : BLOCK as _match
|
Default value:
BlockWeapons = No
|
BlockGambling = {Boolean}
|
Instructs to block attempts of connection to gambling websites (included into the Gambling category).
For the blocking to work, you should check that within the settings there is also a rule that looks like (see the details below):
url_category in "LinuxFirewall.BlockCategory" : BLOCK as _match
|
Default value:
BlockGambling = No
|
BlockDrugs = {Boolean}
|
Instructs to block attempts of connection to websites dedicated to drugs (included into the Drugs category).
For the blocking to work, you should check that within the settings there is also a rule that looks like (see the details below):
url_category in "LinuxFirewall.BlockCategory" : BLOCK as _match
|
Default value:
BlockDrugs = No
|
BlockObsceneLanguage = {Boolean}
|
Instructs to block attempts of connection to websites containing obscene language (included into the ObsceneLanguage category).
For the blocking to work, you should check that within the settings there is also a rule that looks like (see the details below):
url_category in "LinuxFirewall.BlockCategory" : BLOCK as _match
|
Default value:
BlockObsceneLanguage = No
|
BlockChats = {Boolean}
|
Instructs to block attempts of connection to chat websites (included into the Chats category).
For the blocking to work, you should check that within the settings there is also a rule that looks like (see the details below):
url_category in "LinuxFirewall.BlockCategory" : BLOCK as _match
|
Default value:
BlockChats = No
|
BlockTerrorism = {Boolean}
|
Instructs to block attempts of connection to websites dedicated to terrorism (included into the Terrorism category).
For the blocking to work, you should check that within the settings there is also a rule that looks like (see the details below):
url_category in "LinuxFirewall.BlockCategory" : BLOCK as _match
|
Default value:
BlockTerrorism = No
|
BlockFreeEmail = {Boolean}
|
Instructs to block attempts of connection to websites of free email services (included into the FreeEmail category).
For the blocking to work, you should check that within the settings there is also a rule that looks like (see the details below):
url_category in "LinuxFirewall.BlockCategory" : BLOCK as _match
|
Default value:
BlockFreeEmail = No
|
BlockSocialNetworks = {Boolean}
|
Instructs to block attempts of connection to social networking websites (included into the SocialNetworks category).
For the blocking to work, you should check that within the settings there is also a rule that looks like (see the details below):
url_category in "LinuxFirewall.BlockCategory" : BLOCK as _match
|
Default value:
BlockSocialNetworks = No
|
BlockDueToCopyrightNotice = {Boolean}
|
Instructs to block attempts of connection to websites that were added according to copyright holder requests (included into the DueToCopyrightNotice category).
For the blocking to work, you should check that within the settings there is also a rule that looks like (see the details below):
url_category in "LinuxFirewall.BlockCategory" : BLOCK as _match
|
Default value:
BlockDueToCopyrightNotice = No
|
Whitelist = {domain list}
|
White list of domains. Users can access the domain included into this list even if it is included into blocked categories. Access to all sub-domains of such domains is also allowed.
To allow access to the specified domains, you should check that within the settings there is also a rule that looks like (see the details below):
url_host in "LinuxFirewall.Whitelist" : PASS
|
Default value:
Whitelist =
|
Blacklist = {domain list}
|
Black list of domains. Users cannot access any domain included into this list even if it does not fall into any of the blocked categories. Access to all sub-domains of these domains is also forbidden.
To block specified domains, you should check that within the settings there is also a rule that looks like (see the details below):
url_host in "LinuxFirewall.Blacklist" : BLOCK as BlackList
|
If a host belongs to both the black list and the white list simultaneously, then access to this host will be either blocked or allowed depending on which rule (the blocking or the allowing one) appears higher (closer to the beginning) in the rules list (the rule closer to the beginning has priority).
Default value:
Blacklist =
|
ScanTimeout = {time interval}
|
Timeout for scanning one file initiated by SpIDer Gate.
A value in the range from 1s to 1h can be specified
Default value:
ScanTimeout = 30s
|
HeuristicAnalysis = {On | Off}
|
Indicates whether heuristic analysis is used for detection of unknown threats during file scanning initiated by SpIDer Gate. Heuristic analysis provides higher detection reliability but, at the same time, it increases time of virus scanning.
Action applied to threats detected by the heuristic analyzer is specified as the BlockSuspicious parameter value.
Allowed values:
•On—instructs to use heuristic analysis when scanning. •Off—instructs not to use heuristic analysis. Default value:
HeuristicAnalysis = On
|
PackerMaxLevel = {integer}
|
Maximum nesting level when scanning packed objects. All objects at a deeper nesting level are skipped during file scanning initiated by SpIDer Gate.
A value in the range from 0 to 60 can be specified. If the value is set to 0, nested objects are not scanned.
Default value:
PackerMaxLevel = 8
|
ArchiveMaxLevel = {integer}
|
Maximum nesting level when scanning archives. All objects at a deeper nesting level are skipped during file scanning initiated by SpIDer Gate.
A value in the range from 0 to 60 can be specified. If the value is set to 0, nested objects are not scanned.
Default value:
ArchiveMaxLevel = 8
|
MailMaxLevel = {integer}
|
Maximum nesting level when scanning email messages and mailboxes. All objects at a deeper nesting level are skipped during file scanning initiated by SpIDer Gate.
A value in the range from 0 to 60 can be specified. If the value is set to 0, nested objects are not scanned.
Default value:
MailMaxLevel = 8
|
ContainerMaxLevel = {integer}
|
Maximum nesting level when scanning other containers (for example, HTML pages). All objects at a deeper nesting level are skipped during file scanning initiated by SpIDer Gate.
A value in the range from 0 to 60 can be specified. If the value is set to 0, nested objects are not scanned.
Default value:
ContainerMaxLevel = 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:
MaxCompressionRatio = 500
|
BlockKnownVirus = {Boolean}
|
Instructs to block the receiving or the sending of data if it contains any known threat.
For the blocking to work, you should check that within the settings there is also a rule that looks like (see the details below):
threat_category in "LinuxFirewall.BlockThreat" : BLOCK as _match
|
Default value:
BlockKnownVirus = Yes
|
BlockSuspicious = {Boolean}
|
Instructs to block receiving or sending data if it contains any unknown threat detected by the heuristic analyzer.
For the blocking to work, you should check that within the settings there is also a rule that looks like (see the details below):
threat_category in "LinuxFirewall.BlockThreat" : BLOCK as _match
|
Default value:
BlockSuspicious = Yes
|
BlockAdware = {Boolean}
|
Instructs to block the receiving or the sending of data if it contains adware.
For the blocking to work, you should check that within the settings there is also a rule that looks like (see the details below):
threat_category in "LinuxFirewall.BlockThreat" : BLOCK as _match
|
Default value:
BlockAdware = Yes
|
BlockDialers = {Boolean}
|
Instructs to block the receiving or the sending of data if it contains a dialer program.
For the blocking to work, you should check that within the settings there is also a rule that looks like (see the details below):
threat_category in "LinuxFirewall.BlockThreat" : BLOCK as _match
|
Default value:
BlockDialers = Yes
|
BlockJokes = {Boolean}
|
Instructs to block the receiving or the sending of data if it contains joke program.
For the blocking to work, you should check that within the settings there is also a rule that looks like (see the details below):
threat_category in "LinuxFirewall.BlockThreat" : BLOCK as _match
|
Default value:
BlockJokes = No
|
BlockRiskware = {Boolean}
|
Instructs to block the receiving or the sending of data if it contains riskware.
For the blocking to work, you should check that within the settings there is also a rule that looks like (see the details below):
threat_category in "LinuxFirewall.BlockThreat" : BLOCK as _match
|
Default value:
BlockRiskware = No
|
BlockHacktools = {Boolean}
|
Instructs to block the receiving or the sending of data if it contains a hacktool.
For the blocking to work, you should check that within the settings there is also a rule that looks like (see the details below):
threat_category in "LinuxFirewall.BlockThreat" : BLOCK as _match
|
Default value:
BlockHacktools = No
|
BlockUnchecked = {Boolean}
|
Instructs to block the receiving or the sending of data if it cannot be checked.
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:
BlockUnchecked = No
|

|
Changes made to the settings of the connection scanning do not influence the scanning of connections that have already been established by the applications before making changes.
|
The configuration section also contains a set of rules RuleSet* (by default, RuleSet0, …, RuleSet10) which control directly blocking of access of the users to web resources and blocking downloading content from the Internet. For some values in the rule conditions (for example, IP adresses ranges, web resource category names, white and black list of websites, etc.), loading values from a text file or from external data sources via the LDAP (Dr.Web LookupD component is used) is allowed. For more information, refer to “Rules for Traffic Monitoring” in the Appendix D of the Administrator Manual..
By default, the following sets of rules are specified:
RuleSet0 =
RuleSet1 = divert output : set HttpTemplatesDir = "output"
RuleSet1 = divert output : set MailTemplatesDir = "firewall"
RuleSet1 = divert input : set HttpTemplatesDir = "input"
RuleSet1 = divert input : set MailTemplatesDir = "server"
RuleSet1 = proc in "LinuxFirewall.ExcludedProc" : PASS
RuleSet1 = : set Unwrap_SSL = false
RuleSet2 =
RuleSet3 =
RuleSet4 =
RuleSet5 = protocol in (Http), direction request, url_host in "LinuxFirewall.Blacklist" : BLOCK as BlackList
RuleSet5 = protocol in (Http), direction request, url_host in "LinuxFirewall.Whitelist" : PASS
RuleSet6 =
RuleSet7 = protocol in (Http), direction request, url_category in "LinuxFirewall.BlockCategory" : BLOCK as _match
RuleSet8 =
RuleSet9 = protocol in (Http), divert input, direction request, threat_category in "LinuxFirewall.BlockThreat" : BLOCK as _match
RuleSet9 = protocol in (Http), direction response, threat_category in "LinuxFirewall.BlockThreat" : BLOCK as _match
RuleSet9 = protocol in (Smtp), threat_category in "LinuxFirewall.BlockThreat" : REJECT
RuleSet9 = protocol in (Smtp), url_category in "LinuxFirewall.BlockCategory" : REJECT
RuleSet9 = protocol in (Smtp), total_spam_score gt 0.80 : REJECT
RuleSet9 = protocol in (Pop3, Imap), threat_category in "LinuxFirewall.BlockThreat" : REPACK as _match
RuleSet9 = protocol in (Pop3, Imap), url_category in "LinuxFirewall.BlockCategory" : REPACK as _match
RuleSet9 = protocol in (Pop3, Imap), total_spam_score gt 0.80 : REPACK as _match
RuleSet10 =
|
When processing connections, the whole list of rules is checked downwardly, until the rule containing the ultimate resolution is found. The gaps in the rule list are ignored. They serve for quick and convenient editing of the list by adding any necessary rules in these gaps and deleting the rules, if necessary. Note that you cannot add your own RuleSets to the provided RuleSet* list, but you can add any rule into any RuleSet (using the following commands:
# drweb-сtl cfset LinuxFirewall.RuleSet<i> "<rule>"
|
and
# drweb-сtl cfset LinuxFirewall.RuleSet<i> -a "<rule>"
|
where <i> is the number of the RuleSet, and <rule> is the text of your added rule. When you use the drweb-ctl tool to edit the list of rules, enclose the text of your added rule into 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.
The first rule indicates that if the connection is established by the process specified in the ExcludedProc parameter (see above), the connection is skipped without checking any other conditions. The next rule (is executed without any condition) blocks unwrapping of protected connections. This rule and all those that are situated below are considered only if a connection is not bound with the excluded process. Moreover, as all subsequent rules depend on the protocol, if unwrapping of protected connections is disabled, the rules are not executed because it is impossible to define whether the conditions evaluate to true.
The following rules are dedicated to the processing of the outgoing HTTP connections:
1.If a host with which a connection is established is included in a black list, the connection is blocked because the host is in the black list. Other checks are not performed. 2.If the host is included in a white list, the connection is skipped, and other check are not performed. 3.If the URL requested by the client is in the categories of web resources marked as unwanted for access, the connection is blocked due to the detection of a threat. Other checks are not performed. 4.If the response received from a remote host has threats via HTTP contains a threat belonging to the blocked categories, the connection is blocked because the threat was detected. Other checks are not performed. 5.If the data transferred from the local host to a remote host contains a threat belonging to the blocked categories, the connection is blocked because the threat was detected. Other checks are not performed. These five rules will work only if On is specified in the InspectHttp parameter. Otherwise, none of these rules work.
The following six rules that are specified in the RuleSet9 control the scanning of the data that is sent and received via email protocols; these rules are activated if it is detected that a transmitted email (over SMTP, POP3 or IMAP protocol) contains attachments belonging to the categories that should be blocked or qualified as spam (with the reliability rating not less than 0,8). If an email is transmitted over the SMTP protocol, the transmission (i.e. sending or receipt) of the email will be blocked, whereas for the IMAP and POP3 protocols the email will be processed to remove malicious content from its contents (“repackaging”).

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

|
Note that the set of default rules can change automatically if the values of the SniCheckAddress and UnwrapSsl parameters are changed.
|
Examples of Rules for Traffic Monitoring and Blocking of Access
1.Allow users with the following IP addresses 10.10.0.0 – 10.10.0.254 to access websites of all categories, except Chats:
protocol in (HTTP), src_ip in (10.10.0.0/24), url_category not in (Chats) : PASS
|
Note that if the rule
protocol in (HTTP), url_host in "LinuxFirewall.Blacklist" : BLOCK as BlackList
|
is allocated in the list of rules above the indicated rule, then access to domains from the black list, i.e. domains listed in the parameter LinuxFirewall.Blacklist, will also be blocked for users with the range of IP addresses 10.10.0.0 – 10.10.0.254. And if this rule is allocated below, users with the range of IP addresses 10.10.0.0 – 10.10.0.254 will get access also to websites from the black list.
Due to the fact that resolution PASS is terminal, no more rules are checked, therefore scanning of the downloaded data for viruses is not performed either. To grant users with the range of IP addresses 10.10.0.0 – 10.10.0.254 access to websites of all categories, except Chats if they are not in the black list, and to block download of threats at the same time, use the following rule:
protocol in (HTTP), url_category not in (Chats), url_host not in "LinuxFirewall.Blacklist", threat_category not in "LinuxFirewall.BlockCategory" : PASS
|
2.Do not perform scanning of contents of video files (i.e. data with the MIME type “video/*”, where * is any type of the MIME class video):
direction response, content_type in ("video/*") : PASS
|
Note that files that are uploaded from a local host (including files with MIME type “video/*”) will be scanned because they are transmitted via the requests, but not via the responses, i.e. for them the direction variable has the value request.
|