Principes de fonctionnement

Le composant Dr.Web Firewall pour Linux assure le bon fonctionnement du composant SpIDer Gate en analysant les règles de routage définies pour NetFilter (composant système Linux) et en les modifiant de manière que les connexions établies soient redirigées vers SpIDer Gate, qui sert d’intermédiaire (proxy) entre l’application client et le serveur distant.

Dr.Web Firewall pour Linux peut gérer séparément les règles de redirection des connexions sortantes, entrantes et transitives. Pour affiner les règles d’autorisation ou de redirection des connexions, le composant peut utiliser à la fois les règles intégrées dans les paramètres et un script d’analyse écrit en langage Lua.

Pour intercepter les connexions, Dr.Web Firewall pour Linux utilise les tableaux de routage spécifiés dans la base de données des politiques de routage (voir man ip : ip route, ip rule), ainsi que l’interface nf_conntrack du composant système NetFilter. Les connexions interceptées et les paquets qui y transitent sont marqués par des bits afin d’être correctement routés, ce qui permet à Dr.Web Firewall pour Linux de prendre les bonnes décisions concernant la redirection des connexions et le traitement des paquets transmis à différentes étapes de leur passage dans les chaînes NetFilter (pour plus de détails, voir man iptables).

Dr.Web Firewall pour Linux utilise les actions suivantes dans les règles iptables :

•TPROXY : déterminer l’adresse de destination initiale de la connexion et rediriger le paquet de la chaîne PREROUTING NetFilter vers le socket réseau spécifié (<adresse IP>:<port>) sans modifier le contenu du paquet.

•NFQUEUE : transférer le paquet à analyser de la pile réseau du noyau vers le processus fonctionnant en dehors de l’espace du noyau. Dr.Web Firewall pour Linux se connecte à la file d’attente NFQUEUE avec le numéro spécifié via un socket spécial Netlink et reçoit les paquets pour lesquels il faut rendre des verdicts concernant leur traitement ultérieur (Dr.Web Firewall pour Linux doit communiquer à NetFilter l’un des verdicts suivants : DROP, ACCEPT, REPEAT).

Pour marquer les paquets, Dr.Web Firewall pour Linux utilise les trois bits suivants (sur les 32 bits disponibles) dans les marques des paquets et dans la marque de la connexion :

•Bit LDM (Local Delivery Mark) : indicateur de connexion locale. Les paquets dont la marque comporte ce bit sont acheminés vers l’hôte local à l’aide des règles de routage définies.

•Bit CPM (Client Packets Mark) : indicateur de connexion entre le client (initiateur de la connexion) et le proxy, c’est-à-dire Dr.Web Firewall pour Linux.

•Bit SPM (Server Packets Mark) : indicateur de connexion entre les proxys, c’est-à-dire Dr.Web Firewall pour Linux, et le serveur (récepteur de la connexion).

Les bits LDM, CPM et SPM peuvent être n’importe quels bits différents qui ne sont pas utilisés pour marquer les paquets par d’autres applications effectuant le routage des connexions. Avec les paramètres par défaut, Dr.Web Firewall pour Linux sélectionne automatiquement les bits appropriés (non utilisés par d’autres applications).

Pour un fonctionnement correct de Dr.Web Firewall pour Linux (dans n’importe quel mode d’analyse des connexions), la politique de routage ip rule utilisant le tableau de routage numéro 100 doit être configurée dans le système :

Cette politique de routage garantit que les paquets dont la marque contient le bit LDM sont toujours acheminés vers l’hôte local.

Ici et ci-après, l’expression <XXX> pour le bit XXX représente un nombre hexadécimal égal à 2N, où N est le numéro d’ordre du bit XXX dans la marque du paquet. Par exemple, si le bit le plus jeune (zéro) de la marque du paquet est sélectionné comme bit LDM, alors <LDM> = 20 = 0x1.

Pour un fonctionnement correct de Dr.Web Firewall pour Linux (dans n’importe quel mode d’analyse des connexions), les six règles suivantes (présentées au format de sortie de la commande iptables-save) doivent être présentes dans les tableaux nat et mangle des chaînes correspondantes du composant NetFilter :

*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 <adresse IP> --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>

Dans la description ci-dessous, ces règles sont numérotées de 0 à 5 (dans l’ordre dans lequel elles sont énumérées ici). L’expression <X+Y> désigne un nombre égal au « OU » bit à bit (somme) des nombres correspondants X et Y.

Les paramètres <adresse IP> et <port> dans la règle n° 2 indiquent le socket réseau sur lequel Dr.Web Firewall pour Linux contrôle les connexions interceptées.

En outre, lorsque le mode d’interception des connexions (sortantes, entrantes et transit) est activé dans les paramètres de Dr.Web Firewall pour Linux, es règles supplémentaires suivantes doivent être présentes dans les tableaux mangle des chaînes correspondantes (OUTPUT, INPUT, FORWARD) (une règle pour chaque mode) :

-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

Dans la description ci-dessous, ces règles sont numérotées 6, 7 et 8 (dans l’ordre dans lequel elles sont énumérées ici).

Ici, <ONum>, <INum> et <FNum> sont les numéros des files d’attente dans NFQUEUE, dans lesquelles Dr.Web Firewall pour Linux attend l’arrivée de paquets signalant l’établissement des connexions dans les directions correspondantes (il s’agit de paquets avec la case SYN activée, mais avec la case ACK désactivée).

Conformément à une des règles n° 6, 7 et 8, les paquets signalant le début d’une nouvelle connexion réseau dans la direction correspondante, s’ils ne sont pas marqués simultanément par les bits CPM et SPM, sont placés par NetFilter dans les files d’attente correspondantes NFQUEUE, d’où ils seront lus par Dr.Web Firewall pour Linux via l’interface nf_conntrack. Les règles n° 3 et 4 marquent la connexion elle-même comme interceptable, c’est-à-dire qu’un bit indiquant la direction de la connexion est spécifié dans la marque de connexion. Le numéro de ce bit dans la marque de connexion correspond au numéro du bit dans la marque du paquet. En conséquence, les paquets envoyés sur cette connexion seront reçus par Dr.Web Firewall pour Linux grâce aux règles n° 1, 2 et 5. La règle n° 0 est ajoutée au début de la chaîne POSTROUTING du tableau nat afin que, dans le cas d’un NAT configuré, les adresses des paquets marqués ne soient pas traduites, car cela perturberait la logique d’interception et de traitement des connexions de Dr.Web Firewall pour Linux.

Lorsqu’un paquet apparaît dans l’une des files d’attente NFQUEUE de Dr.Web Firewall pour Linux, il effectue une vérification de base de la validité du paquet au cas où des règles incorrectes seraient définies dans NetFilter. Ensuite, Dr.Web Firewall pour Linux tente de se connecter au serveur à son nom depuis le socket marqué PSC. La règle n° 4 s’applique alors. La règle de livraison locale n° 5 ne s’applique pas, car le paquet porte la marque SPM, et cette règle ne s’applique qu’aux paquets portant la marque <CPM+SPM>.

•Si la connexion au serveur a échoué, Dr.Web Firewall pour Linux forme pour le client un paquet avec le bit RST spécifié, en remplaçant dans le paquet la paire <adresse IP>:<port> par l’adresse du socket réseau du serveur demandé. Dans NFQUEUE, le verdict DROP est alors envoyé. Sur le socket depuis lequel le paquet avec le bit RST sera envoyé, la marque <CPM+SPM> est défini, de sorte qu’aucune des règles ci-dessus ne s’applique et que ce paquet sera livré au client selon les règles de routage habituelles.

•Si la connexion au serveur distant a été établie, Dr.Web Firewall pour Linux copie le paquet SYN intercepté et le renvoie depuis le socket marqué <LDM+CPM> afin que le paquet envoyé soit redirigé vers le socket réseau local. Grâce au bit LDM activé, lors de la sélection de l’interface de sortie, conformément aux règles de routage définies, le paquet envoyé sera acheminé vers l’interface loopback, d’où il sera transféré vers la chaîne NetFilter PREROUTING, où la règle n° 2 s’appliquera. Ainsi, le paquet envoyé sera redirigé tel quel vers le socket réseau Dr.Web Firewall pour Linux. Cette technique permet à Dr.Web Firewall pour Linux de conserver l’adresse complète pour la connexion (adresse IP et port de l’expéditeur du paquet, adresse IP et port du destinataire du paquet).

Pour le socket réseau sur lequel Dr.Web Firewall pour Linux accepte les connexions interceptées conformément à la règle n° 2, l’option IP_TRANSPARENT et la marque <LDM+CPM> sont spécifiées, ce qui permet aux paquets envoyés par Dr.Web Firewall pour Linux depuis cette socket de ne pas être placés dans la file d’attente NFQUEUE. Lors de la connexion du client, une recherche de socket paire est effectuée à partir de l’adresse enregistrée (adresse IP et port de l’expéditeur, adresse IP et port du destinataire). Une fois la connexion avec le client et le serveur établie, la procédure de vérification s’applique définie sous forme de procédure en langage Lua, ainsi que les règles de vérification définies dans les paramètres de Dr.Web Firewall pour Linux. Si les vérifications sont réussies et que la connexion ne doit pas être interrompue, la paire de sockets appariés qui relie le côté client et le côté serveur de la connexion établie, est transmise au composant SpIDer Gate pour analyse des données transmises via la connexion. L’interaction ultérieure entre le client et le serveur s’effectue par l’intermédiaire de SpIDer Gate. Outre la paire de sockets associée aux côtés client et serveur de la connexion, SpIDer Gate reçoit de Dr.Web Firewall pour Linux les paramètres et les règles de vérification de la connexion établie.

Le schéma simplifié du fonctionnement de Dr.Web Firewall pour Linux est représenté dans la figure ci-dessous.

2.Redirection par NetFilter de la connexion établie vers Dr.Web Firewall pour Linux conformément aux règles de routage.

3.Tentative de Dr.Web Firewall pour Linux d’établir une connexion avec le serveur au nom du client et analyse de la connexion.

4.Transmission d’une paire de sockets associés aux côtés client et serveur de la connexion par SpIDer Gate pour la gestion de la connexion, ainsi que des paramètres et des règles de vérification.

5.Échange de données entre le serveur et le client via SpIDer Gate en tant qu’intermédiaire.

Pour que le composant Dr.Web Firewall pour Linux fonctionne correctement, les règles spécifiées doivent être présentes dans les tableaux de routage avec les numéros de bits de marque, les files d’attente NFQUEUE et l’adresse du socket réseau corrects pour l’interception des connexions. Avec les paramètres par défaut, le composant configure automatiquement les règles appropriées. Si la configuration automatique des connexions par le composant est désactivée dans ses paramètres, vous devez vous assurer manuellement que les règles nécessaires sont présentes au démarrage du composant.