In this section:
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).
Dr.Web Firewall for Linux uses the following actions in the iptables rules:
•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:
The following route must should be added to the table:
This routing policy guarantees that packets with the LDM bit in their marks are always sent to the local host.
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:
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.
•To intercept outgoing (output) connections:
•To intercept incoming (input) connections:
•To intercept transit (forward) connections:
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.
Simplified diagram of Dr.Web Firewall for Linux operation is given below.
Figure 13. Diagram of the components’ operation
The following steps for connection processing are marked by numbers:
1.Client attempts to connect to the server.
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.