Au vu des contraintes précédentes, nous avons donc opté pour une solution basée sur netfilter et iptables : en effet, l'architecte d'iptables a prévu une table mangle, justement prévue pour les manipulations de paquets (par opposition aux tables filter et nat, prévues pour le filtrage et la translation d'adresse, respectivement). Nous avons donc créé une nouvelle target PERS (pour IP Personality), qui effectue certaines opérations de réécriture sur les paquets qu'on lui passe. Le système des règles permet de laisser à iptables le soin de sélectionner les paquets IP en fonction de leurs adresses et ports source et destination, et les paramètres passés à la target PERS lui donnent un comportement variable, réglable par l'administrateur, qui peut ainsi définir quel type de réécriture il veut voir appliquer à une catégorie de paquets.
Une fois installé et configuré correctement, IP Personality offre la possibilité de leurrer nmap, et de lui faire croire que la machine hôte fait tourner un système librement spécifié par l'administrateur. Les paquets de test qu'envoie nmap sont pour la plupart anormaux, et ceux qui ne le sont pas sont envoyés à des ports fermés, donc ils n'influencent pas l'état de la pile TCP/IP locale : nous pouvons donc les détourner sans scrupule, et émettre les réponses qui nous conviennent. Le système de configuration de PERS permet de couvrir tout l'éventail des possibilités de réponses, et ainsi nous pouvons renvoyer à nmap des paquets caractéristiques de n'importe quel système décrit dans sa base de signatures.
Certaines des opérations effectuées pour leurrer nmap (pas toutes hélas) peuvent également être exécutées sur des paquets routés par notre machine. Si nous perdons la capacité de tromper complètement nmap, nos manipulations sont suffisamment efficaces pour l'empêcher de détecter le système utilisé sur sa cible. Les opérations possibles sur des paquets routés sont la réécriture des numéros de séquence et des options TCP.
Au passage, nous gagnons également en robustesse dans le cas de certaines réécritures. En particulier, les machines dont les générateurs d'ISN trop simplistes les rendent vulnérables à des attaques par prédiction de numéros de séquence peuvent ainsi être protégées par notre target, qui leur offre un ISN parfaitement aléatoire. De plus, grâce à la souplesse qu'offre la syntaxe du fichier de configuration, les possibilités d'émulations ne sont pas limitées aux outils de prise d'empreintes réseau existants : il devient très facile sinon de tromper, du moins de perturber n'importe quel outil raisonnant sur les mêmes bases que nmap, puisque nous avons le contrôle des éléments caractéristiques d'un paquet.
Pour tenir compte des nombreuses possibilités de comportement d'une pile IP, la configuration s'effectue via un fichier de configuration complet détaillant les valeurs de différents paramètres. Ce fichier est interprété et chargé dans l'espace noyau via une extension au programe de configuration de netfilter, iptables. En particulier, pour les cas de réécritures complexes dépendant de nombreux paramètres, le fichier contient deux sections de "code" qui sont interprétés dans le noyau (sous forme de pseudo code) pour analyser plus finement les paquets selon des algorithmes analogues aux systèmes émulés.
+----->---->---+----+--->---->-----+
| +---<----<---| VM |---<----<---+ |
| | +----+ | |
+--+-+--+ | |
+->-| Decoy |->-+ | |
| +-------+ | +-----+ +-----+ +-+-+-+
+-->--+->--->--->--->-+-| SEQ |->-| WIN |->-| OPT |-+
+-----------+ | TCP +-----+ +-----+ +-----+ |
| IP Tables |->-+ |--+
+-----------+ | UDP +---------+ | |
| +-->---->-----| Unreach |------>------>-------------+ |
| +---------+ |
+-------<---------<--------<---------<----------<----------<------+
<==================== IP Personality ====================>
La cible PERS peut modifier les paquets qui lui sont passés par l'architecture netfilter. Aussi, il est logique de l'utiliser au sein de la table mangle spécialisée dans la modification des paquets.
Cette table accède à deux des points d'entrée de netfilter, PRE_ROUTING et LOCAL_OUT. Afin de pouvoir réécrire correctement les connexions, le module PERS a besoin de voir les deux sens d'une connexion (nous verrons pourquoi par la suite).
Pour ce faire, on utilise deux règles configurées de manière identique mais dont les critères sources et destinations sont symétriques. Pour les paquets routés, les deux règles doivent se situer au le point d'entrée PRE_ROUTING, puisque les paquets des deux directions sont d'origine extérieure à la machine locale. En revanche en ce qui concerne les communications avec la machine locale, si les paquets qui lui sont envoyés passent bien par le point d'entrée PRE_ROUTING, il n'en est pas de même pour les paquets qu'elle émet, ceux ci passant par LOCAL_OUT.
Pour chacune des règles utilisées pour réécrire un type de communication, on précise au module si l'on souhaite protéger la destination de la règle ou sa source à l'aide d'une option. En effet selon le sens du paquet, certaines réécritures ne sont pas faites de la même manière.
Si le paquet est destiné à la machine locale (c'est une option de la target), on commence par l'envoyer dans le code de génération des leurres : là le pseudo-code de la section tcp_decoy du fichier de config détermine si le paquet peut continuer tel quel, ou sinon (c'est-à-dire si le paquet a été identifié comme étant pathologique), s'il faut répondre, avec un leurre construit en fonction du paquet.
Si le paquet continue, il peut être modifié de plusieurs façons. En particulier, le sens de circulation, qu'on peut déterminer grâce aux informations du module conntrack d'iptables et aux paramètres de la règle en cours, définit le sens de la réécriture. Les altérations possibles sont :
Les paquets UDP qui sont simplement routés sont ignorés. Ceux qui sont destinés à la machine locale sont examinés pour vérifier qu'ils sont bien destinés à un port UDP ouvert : si c'est bien le cas, ils continuent leur chemin tels quels ; dans le cas contraire, ils sont détruits et PERS prend en charge l'émission d'un message ICMP de type "Port Unreachable", car nmap examine les caractéristiques de ce message.
Ce genre de message est un paquet IP contenant une en-tête ICMP suivie du début du paquet IP ayant provoqué l'erreur. Le fichier de configuration permet de contrôler chacun des éléments du paquet utilisés par nmap pour identifier un système.
Après la réécriture potentielle des paquets UDP/TCP, l'ensemble des paquets IP peuvent également être modifés. Une seule modification est apportée pour le moment et consiste à modifier l'identifiant du paquet (IP ID) pour une valeur générée selon un modèle prédéfini (de manière analogue aux numéros de séquences TCP).