Operating Principles

Dr.Web Firewall for Linux component ensures the correct SpIDer Gate operation. It analyzes the routing rules adjusted for NetFilter (GNU/Linux OS component) and modifies it so as the established connections are redirected to SpIDer Gate which performs a function of an intermediate (proxy) between a client application and a remote server.

Dr.Web Firewall for Linux can separately manage the rules of redirection of outgoing and incoming, as well as transit connections. To configure bypassing or redirecting rules accurately, the component can use rules that are built-in in settings as well as script, written in Lua.

To intercept connections, Dr.Web Firewall for Linux uses routing tables specified in the database of routing policies (see man ip: ip route, ip rule) and the nf_conntrack interface of the NetFilter system component. The intercepted connections and transmitted packets are marked with bit marks that allow Dr.Web Firewall for Linux to redirect connections and process transmitted packets correctly on different stages of the chain in NetFilter (for details, see man iptables).

•MARK. This action allows Dr.Web Firewall for Linux to set a specified numeric mark to a package.

•CONNMARK. This action allows Dr.Web Firewall for Linux to set a specified numeric mark to a connection.

•TPROXY. This action allows Dr.Web Firewall for Linux to redirect packages from the PREROUTING NetFilter chain to the specified network socket (<IP address>:<port>) without changing the contents of the package. The use of this action allows Dr.Web Firewall for Linux to determine the initial destination address of the connection.

•NFQUEUE This action allows to send the package from the network stack of the engine to a process that operates outside the kernel space for scanning. Thus, Dr.Web Firewall for Linux connects to the queue NFQUEUE with the specified number via a special Netlink socket and gets packages that are necessary to make verdicts on processing (Dr.Web Firewall for Linux must tell NetFilter one the following verdicts: DROP, ACCEPT, REPEAT).

To mark packets, Dr.Web Firewall for Linux uses the following three out of the available 32 bits in packet and connection marks.

•the LDM bit (Local Delivery Mark). Packets with this bit in the mark are sent to the local host using the set routing rules.

•the CPM bit (Client Packets Mark). Indicates the connection between a client (a connection initiator) and a proxy, i.e. Dr.Web Firewall for Linux.

•the SPM bit (Server Packets Mark). Indicates the connection between a proxy, i.e. Dr.Web Firewall for Linux, and a server (a connection recipient).

The LDM, CPM, and SPM bits can be any various bits, not used for marking packets by other applications that perform routing connections. By default, Dr.Web Firewall for Linux chooses the appropriate (not used by other applications) bits automatically.

For correct operation Dr.Web Firewall for Linux (in any of the connection scanning modes) the ip rule routing policy that uses the routing table with number 100 must be installed in the system:

This routing policy guarantees that packets with the LDM bit in their marks are always sent to the local host.

Hereinafter the <XXX> string for the XXX bit is a hexadecimal value that equals 2 N, where N is a ordinal number of the XXX bit in the packet mark. For example, if the smallest (zero) bit was selected as an LDM bit, then <LDM> = 20 = 0x1.

For the correct operation of Dr.Web Firewall for Linux (in any connection scanning mode), the following six rules (displayed in the iptables-save output command format) must be present in the nat and mangle tables of the appropriate chains of the NetFilter system component:

*nat

-A POSTROUTING -o lo -m comment --comment drweb-firewall -m mark --mark <LDM>/<LDM> -j ACCEPT

*mangle

-A PREROUTING -m comment --comment drweb-firewall -m mark --mark 0x0/<CPM+SPM> -m connmark --mark <SPM>/<CPM+SPM> -j MARK --set-xmark <LDM>/<LDM>
-A PREROUTING -p tcp -m comment --comment drweb-firewall -m mark ! --mark <CPM+SPM>/<CPM+SPM> -m connmark --mark <CPM>/<CPM+SPM> -j TPROXY --on-port <port> --on-ip <IP-address> --tproxy-mark <LDM>/<LDM>
-A OUTPUT -m comment --comment drweb-firewall -m mark --mark <CPM>/<CPM+SPM> -j CONNMARK --set-xmark <CPM>/0xffffffff
-A OUTPUT -m comment --comment drweb-firewall -m mark --mark <SPM>/<CPM+SPM> -j CONNMARK --set-xmark <SPM>/0xffffffff
-A OUTPUT -m comment --comment drweb-firewall -m mark --mark 0x0/<CPM+SPM> -m connmark ! --mark 0x0/<CPM+SPM> -j MARK --set-xmark <LDM>/<LDM>

In the description below, numbers 0–5 are assigned to these rules (in the order they are listed in the document). The expression <X+Y> means the bit number “OR” (the sum) of the respective numbers X and Y.

Parameters <IP address> and <port> in the rule number 2 indicate the network socket where Dr.Web Firewall for Linux controls intercepted connections.

Besides, the following additional rules must be present in the mangle tables of the corresponding chains (OUTPUT, INPUT, FORWARD) when enabling the interception connection mode (outgoing, incoming, and transit) in the Dr.Web Firewall for Linux settings.

-A OUTPUT -p tcp -m comment --comment drweb-firewall -m tcp --tcp-flags SYN,ACK SYN -m mark --mark 0x0/<CPM+SPM> -j NFQUEUE --queue-num <ONum> --queue-bypass

-A FORWARD -p tcp -m comment --comment drweb-firewall -m tcp --tcp-flags SYN,ACK SYN -m mark --mark 0x0/<CPM+SPM> -j NFQUEUE --queue-num <FNum> --queue-bypass

In the description below, numbers 6, 7, and 8 are assigned to these rules (in the order they are listed in the document).

Here <ONum>, <INum> and <FNum> are the numbers of queues in NFQUEUE where Dr.Web Firewall for Linux is waiting for packages that indicate the installation of the corresponding connections (these packages with a set SYN flag, but without the ACK flag).

According to any of rules 6, 7, and 8, packets indicating a new network connection of the corresponding direction, if not marked by both CPM and SPM bits, are put in the corresponding NFQUEUE queue by NetFilter, where they will be read by Dr.Web Firewall for Linux via the nf_conntrack interface. Rules 3 and 4 mark the connection as intercepted, that is, a bit indicating the connection direction is set in the connection mark; this bit number coincides with the bit number in the packet mark. As a result, according to rules 1, 2, and 5, packets sent via this connection will be delivered by Dr.Web Firewall for Linux. Rule 0 is added on the top of the POSTROUTING chain in the nat table, so that if NAT is configured, addresses for marked packets are not transmitted (because it will interfere with the Dr.Web Firewall for Linux logic of interception and connection processing).

When a packet appears in one of the NFQUEUE queues, Dr.Web Firewall for Linux performs basic processing of the packet, in case incorrect rules are set in NetFilter. Then Dr.Web Firewall for Linux attempts to connect with the server using its own name and the socket marked PSC in accordance with rule 4. Rule 5 for local delivery will not apply, because the packet is marked with SPM and this rule is only applicable to packets marked with <CPM+SPM>.

•If the connection to the server fails, Dr.Web Firewall for Linux generates a client packet with the RST bit, replacing the pair <IP address>:<port> with the address of a network socket of the requested server. The DROP verdict is sent to NFQUEUE as well. The socket, used for sending the packet with the RST bit, is marked as <CPM+SPM>, so that none of the above rules will apply, so that the packet will be delivered to the client according to the usual routing rules.

•If an attempt to connect to a remote server is successful, Dr.Web Firewall for Linux copies the intercepted SYN packet and resends it from the socket marked as <LDM+CPM> to redirect the packet to the local network socket. Thanks to the set LDM bit and according to the specified routing rules, when selecting the output interface, the packet will be added to the loopback interface, and then to the NetFilter PREROUTING chain, where rule 2 will be applied. Thus, the packet will be redirected to the network socket Dr.Web Firewall for Linux unchanged. This feature allows Dr.Web Firewall for Linux to save all four elements of the connection address (IP address and port of the packet sender, IP address and port of the packet recipient).

For the network socket, where Dr.Web Firewall for Linux receives the intercepted connections according to rule 2, IP_TRANSPARENT option and the <LDM+CPM> mark are set, preventing packets sent by Dr.Web Firewall for Linux from this socket from falling into the NFQUEUE queues. When a client connects, search is performed for a paired socket, using the saved four-element address (IP address and port of the packet sender, IP address and port of the packet recipient). When the connection with the client and the server is established, it is scanned in accordance with a procedure in Lua, as well as scanning rules, specified in the Dr.Web Firewall for Linux settings. If the scans are successful and the connection is stable, the associated socket pair that connects the client and server sides is transferred to the SpIDer Gate component for analysis on the transferred data. The following interaction between clients and servers is established via a mediator, SpIDer Gate. In addition to the socket pair, associated with the client and server sides, Dr.Web Firewall for Linux sends SpIDer Gate the parameters and rules for scanning the established connection.

2.Redirecting NetFilter of the connection to Dr.Web Firewall for Linux according to the routing rules.

3.Attempt of Dr.Web Firewall for Linux to connect to the server using the client’s name and connection scanning.

4.Transmission of socket pair associated with the client and server side of the connection, SpIDer Gate for connection processing, and settings and rules for the scanning.

5.Data exchange between the server and the client via SpIDer Gate as a mediator.

For the correct operation of Dr.Web Firewall for Linux, these rules in routing tables with correct numbers of bit marks, the NFQUEUE queues and network socket addresses for connection interception are necessary. By default settings, the component performs the necessary configuration of rules automatically. If automatic configuration of connections is disabled in the settings, it is necessary to provide the required rules manually when launching the component.