Operating Principles

The Dr.Web Firewall for Linux component ensures the correct operation of SpIDer Gate by analyzing routing rules adjusted for NetFilter (a system component of Linux) and modifies it so that the connections being established are redirected to SpIDer Gate, which functions as an intermediate (proxy) between a client application and a remote server.

Dr.Web Firewall for Linux can separately manage the rules for redirecting outgoing, incoming and transit connections. To configure the rules for passing or redirecting connections in detail, the component can use the rules incorporated in settings and a Lua script.

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 packets being transmitted are marked with bit marks to ensure proper routing thereby allowing Dr.Web Firewall for Linux to properly redirect connections and process packets being transmitted on various stages of passing NetFilter chains (for details, see man iptables).

•TPROXY—set an initial destination address of the connection and redirect packets from the PREROUTING NetFilter chain to a specified network socket (<IP address>:<port>) without changing contents of a packet.

•NFQUEUE—send a packet from the kernel network stack to a process that operates outside the kernel space for scanning. Dr.Web Firewall for Linux connects to the NFQUEUE queue with a specified number via a custom Netlink socket and receives packets for which a verdict on further processing must be reached (Dr.Web Firewall for Linux must inform NetFilter of one the following verdicts: DROP, ACCEPT or REPEAT).

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

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

•CPM bit (Client Packets Mark)—indicator of a connection between a client (a connection initiator) and a proxy, that is, Dr.Web Firewall for Linux.

•SPM bit (Server Packets Mark)—indicator of a connection between a proxy, that is, Dr.Web Firewall for Linux, and a server (a connection recipient).

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

To ensure correct operation of Dr.Web Firewall for Linux (in any connection scanning mode), the ip rule routing policy that uses routing table #100 must be configured on your system:

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

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

To ensure 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 corresponding chains of the NetFilter 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>

These rules are numbered 0–5 in the description below (in the order they are listed here). The expression <X+Y> means a number equal to bitwise “OR” (a sum) of the corresponding numbers X and Y.

Parameters <IP address> and <port> in rule #2 specify a network socket on which Dr.Web Firewall for Linux manages intercepted connections.

Furthermore, the following additional rules (per rule for each of the modes) must be present in mangle tables of the corresponding chains (OUTPUT, INPUT, FORWARD) when enabling the interception mode for outgoing, incoming and transit connections 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 INPUT -p tcp -m comment --comment drweb-firewall -m tcp --tcp-flags SYN,ACK SYN -m mark --mark 0x0/<CPM+SPM> -j NFQUEUE --queue-num <INum> --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

These rules are numbered 6, 7 and 8 in the description below (in the order they are listed here).

Here, <ONum>, <INum> and <FNum> are numbers of queues in NFQUEUE, in which Dr.Web Firewall for Linux is waiting for packets that indicate establishing connections with the corresponding directions (these are packets with a set SYN flag and an unset ACK flag).

In accordance with 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 queues 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 itself as intercepted, that is, a bit indicating the connection direction is set in the connection mark. This bit number matches the bit number in the packet mark. As the result, in accordance with rules 1, 2 and 5, Dr.Web Firewall for Linux will receive packets sent via this connection. Rule 0 is added on top of the POSTROUTING chain in the nat table, so that if NAT is configured, not to translate addresses for marked packets, because this will interfere with Dr.Web Firewall for Linux logic of connection interception and processing.

When a packet appears in one of the NFQUEUE queues, Dr.Web Firewall for Linux performs basic verification of the packet in the event invalid rules are set in NetFilter. Subsequently, Dr.Web Firewall for Linux attempts to connect on behalf of itself to the server from the socket marked with PSC. At that, rule 4 is triggered. Rule 5 for local delivery is not triggered, 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 an RST bit having replaced the pair <IP address>:<port> with the address of the network socket of the requested server. At that, the DROP verdict is sent to NFQUEUE. The socket used for sending the packet with the RST bit is marked as <CPM+SPM>, so none of the above rules is triggered, and this packet will be delivered to the client in accordance with standard 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 sent packet to the local network socket. Owing to the set LDM bit and in accordance with the specified routing rules, when selecting an output interface, the packet will be sent to the loopback interface and then to the NetFilter PREROUTING chain, where rule 2 will be triggered. Thus, the packet will be redirected to the network socket of Dr.Web Firewall for Linux unchanged. This method allows Dr.Web Firewall for Linux to preserve all four elements of the connection address (an IP address and a port of a packet sender, an IP address and a port of a packet recipient).

The IP_TRANSPARENT option and the <LDM+CPM> mark are set for the network socket on which Dr.Web Firewall for Linux receives intercepted connections in accordance with rule 2; therefore, packets sent by Dr.Web Firewall for Linux from this socket are not included in the NFQUEUE queues. When a client connects, search is performed for a paired socket using the preserved four-element address (the IP address and the port of the packet sender, the IP address and the port of the packet recipient). When the connection with the client and the server is established, it is scanned using a Lua procedure, as well as scanning rules specified in the Dr.Web Firewall for Linux settings. If the scans are successful and the connection should not be closed, the associated socket pair that connects the client and server sides of the established connection is passed to the SpIDer Gate component for analyzing the data transmitted over the connection. The further interaction of the client and the server is mediated by SpIDer Gate. In addition to the socket pair associated with the client and server sides of the connection, SpIDer Gate receives the parameters and rules for scanning the established connection from Dr.Web Firewall for Linux.

2.NetFilter redirects the connection being established to Dr.Web Firewall for Linux in accordance with the routing rules.

3.Dr.Web Firewall for Linux attempts to connect to the server on behalf of the client; the connection is scanned.

4.Socket pair associated with the client and server sides of the connection is passed to SpIDer Gate for processing the connection along with the parameters and rules for scanning it.

5.Server and the client exchange data via SpIDer Gate that serves as a mediator.

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