4. Configuration

La configuration de PERS s'effectue en espace utilisateur à l'aide de la commande iptables et d'une bibliothèque dynamique associée permettant de lui passer tous ses paramètres spécifiques. Cette bibliothèque ajoute à iptables de nouvelles options applicables à chaque règle dont la cible est PERS ; l'une de ces options permet l'utilisation d'un fichier de configuration détaillé regroupant l'ensemble des paramètres nécessaires à l'émulation d'un système d'exploitation particulier. Via l'utilisation de fichiers de configuration différents pour chaque règle différente on peut donc très librement choisir d'émuler un système particulier en fonction d'adresses sources et destinations, de l'interface, et autres critères de sélection dans les règles.

4.1 Options en ligne de commande

Les options de la ligne commande sont passées à la cible lors de l'ajout d'une règle l'utilisant par exemple avec une syntaxe du type :

iptables -A <chaine> -s <source> -d <destination> -j PERS <options>

[Se référer à la documentation d'iptables pour plus de détails sur la syntaxe globale]

Les options reconnues par la bibliothèque sont :

• -tweak {src|dst}  : Cette option permet de spécifier le sens de réécriture pour la règle considérée. Si elle vaut src cela signifie que l'on souhaite protéger la source des paquets (et ainsi on va par exemple réécrire les numéros de séquence des paquets d'une connexion). Si elle vaut dst, alors on souhaite protéger la destination de la règle (et ainsi on réécrirait par exemple les acquittements de la connexion).
• -local  : Cete option spécifie que la source ou la destination de la règle (selon la valeur de l'option tweak) est locale, ce qui a pour effet d'activer les modules "decoy" et "udp" (si ceux-ci sont définis dans le fichier de configuration) permettant ainsi de tromper complètement des outils de type nmap en local.
• -conf <fichier> : Cette option permet de spécifier le fichier de configuration à utiliser pour le système émulé au sein de cette règle (cf ci après).

4.2 Fichier de configuration

Les paramètres concernant l'émulation d'un système particulier se définissent au sein d'un fichier. Ce fichier utilise une syntaxe proche de named.conf, inspirée du langage C. Les options de configuration sont regroupées dans des blocs (délimités par des { et }) et chaque bloc de configuration correspond à un type de réécriture différent. Chaque option est constituée d'un identifiant suivi d'un ou plusieurs arguments et terminée par un symbole ;. Les options et les blocs peuvent être spécifiés dans n'importe quel ordre.

Identification

Le premier élément d'un fichier de configuration est une identification du système qu'il décrit. Il s'agit d'une chaîne d'au plus 20 caractères décrivant le système. La syntaxe est la suivante :

 id "FakeOS";

Paramètres génériques TCP

Ces paramètres sont regroupés au sein d'une section nommée tcp. Exemple :

  tcp {
    incoming yes;
    outgoing no;
    max-window 65536;
  }

Le paramètre incoming définit si l'on souhaite activer les modifications opérant sur des connexions TCP (ISN, taille de fenêtre, et Options) pour les connexions entrantes vers la zone protégée. Il peut prendre les valeurs yes ou no.

Le paramètre outgoing est analogue pour les connexions sortantes de la zone protégée.

Le paramètre max-window contrôle la réécriture de la taille de fenêtre sur les paquets TCP des connexions correpondant aux réglages précédents. Si il est défini à une valeur non nulle, alors pour toute nouvelle connexion dont la taille de fenêtre lui est supérieure, un décalage est calculé et la taille de fenêtre est ramenée à une valeur inférieure à ce paramètre sur toute la durée de la connexion.

Paramètres de générateur de numéros de séquence

Ces paramètres sont regroupés au sein d'une section nommée tcp_isn. Exemple :

  tcp_isn {
    type random-inc 10000;
    initial-value 2600;
  }

Le paramètre type décrit le type de générateur à émuler ainsi qu'une éventuelle option de cet émulation. Les types suivants sont implémentés :

• fixed-inc <number>  : Il s'agit du générateur le plus simple. Le numéro de séquence initial de chaque connexion est tout simplement incrémenté d'une valeur constante (passée en argument) à chaque nouvelle connexion. L'utilisation de la valeur 0 comme incrément permet d'émuler les systèmes utilisant des numéros de séquence initiaux constants.
• random-inc <number>  : Il s'agit d'un générateur semi-aléatoire. A chaque nouvelle connexion le numéro de séquence initial est incrémenté d'une valeur aléatoire entre 0 et le paramètre fourni. C'est le type de générateur utilisé sur les systèmes Linux, FreeBSD, etc... La robustesse d'un tel générateur est déterminé par la taille du paramètre.
• true-random  : Il s'agit d'un générateur complètement aléatoire. A chaque nouvelle connexion, le numéro de séquence est généré de manière purement aléatoire (en utilisant le générateur aléatoire à entropie variable du noyau).
• builtin  : Il s'agit du générateur de base du système courant. Sous Linux il s'agit donc d'un gérérateur à incréments aléatoires.
• time-dep <number>  : Il s'agit d'un générateur dépendant du temps. Le nombre passé en paramètre indique la fréquence de progression du générateur (en Hz). Par exemple, une valeur de 25000 permet d'implémenter le générateur décrit dans la RFC 793 : le numéro de séquence initial est alors incrémenté de 1 toutes les 4 micro-secondes. (la granularité du générateur dépend toutefois de la précsion des "ticks" du système, 100 Hz par défaut sous linux/x86)

Le paramètre initial-value décrit la valeur initiale à utiliser pour le générateur de numéro de séquence. Il peut s'agir d'une valeur numérique ou bien du mot-clé random qui choisira une valeur aléatoire lors de l'insertion de la règle. Ce paramètre a peu d'importance pour les types de générateurs peu prédictibles.

Paramètres de générateur d'Identifiants IP

Ces paramètres sont regroupés au sein d'une section nommée ip_id. Exemple :

  ip_id {
    type broken-inc 1;
    initial-value 2600;
  }

Le paramètre type décrit le type de générateur à émuler ainsi qu'une éventuelle option de cet émulation. Les même types que pour les générateurs de numéros de séquences sont acceptés, et un choix supplémentaire, broken-inc number est disponible : il s'agit d'un compteur incrémenté de la valeur spécifiée à chaque utilisation, mais dont le résultat est stoqué dans le paquet au format "little endian", au lieu de l'ordre réseau.

Paramètres de rééordonnancement des options

Ces paramètres sont regroupés au sein d'une section nommée tcp_options. Exemple :

  tcp_options {
    keep-unknown yes;
    keep-unused no;
    isolated-packets yes;
    timestamp-scale 100;
    code {
      <code...>
    }
  }

Cette section définit comment les options TCP d'un paquet doivent être réécrites. La sous-section code contient un programme dans un langage proche du C (décrit par la suite) qui est compilé par le module libipt_PERS.so. Ce code est passé à la machine virtuelle qui remplit le buffer d'options constituant son état au fer et à mesure de l'exécution. Lorsque l'exécution est achevée, le buffer d'options résultant est utilisé pour remplacer les options initiales du paquet.

Le paramètre keep-unknown spécifie si les options "inconnues" présentes dans le paquet initial, et donc non manipulables par le programme de réécriture, doivent être rajoutées à la fin du buffer final afin d'être présentes dans le paquet final. Ce paramètre peut prendre les valeurs yes ou no.

Le paramètre keep-unused spécifie si les options du paquet original qui n'ont pas été utilisées (testées ou recopiées) pendant l'exécution du programme doivent être recopiées à la fin du buffer afin d'être présentes dans le paquet final. Ce paramètre peut prendre les valeurs yes ou no. Ceci permet d'utiliser un code assez simple pour réordonner seulement quelques options tout en conservant toutes les options du paquet original.

Le paramètre isolated-packets spécifie si la réécriture des options doit être appliquée aux paquets n'appartenant à aucune connexion connue. Ce paramètre peut prendre les valeurs yes ou no (valeur par défaut).

Le paramètre timestamp-scale spécifie si l'on souhaite changer la valeur des "timestamp" TCP dans les paquets communiquant avec la machine locale. Il prend en argument la fréquence à utiliser pour les nouveaux "timestamp". (si la valeur est nulle ou égale à la fréquence nominale, l'option est ignorée).

Paramètres du leurre TCP

Ces paramètres sont regroupés au sein d'une section nommée tcp_decoy. Exemple :

  tcp_decoy {
    code {
      <code...>
    }
  }

Cette section se résume à une sous-section code analogue à celle de la section précédente, qui définit un certain nombre de tests à effectuer sur le paquet initial afin de reconnaître des paquets caractéristiques d'outils de détection et de répondre en conséquence. Le langage utilisé est le même que précédemment (décrit ci après).

Paramètres du leurre UDP

Ces paramètres sont regroupés au sein d'une section nommée udp_unreach. Exemple :

  udp_unreach {
    reply yes;
    df no;
    max-len 56;
    tos 0;
  
    mangle-original {
      ip-len 21;
      ip-id same;
      ip-csum zero;
      udp-len 308;
      udp-csum zero;
      udp-data same;
    }
  }

Le paramètre reply détermine si l'on souhaite émettre un message ICMP de type "port unreachable" lorsque l'on reçoit un message UDP pour un port non ouvert localement. Il peut être défini à yes ou à no. Les autres paramètres de cette section s'appliquent si il est activé.

Le paramètre df spécifie si le bit "Don't Fragment" de l'entête IP du paquet ICMP doit être activé ou non.

Le paramètre max-len spécifie la longueur maximum du message ICMP généré en réponse.

Le paramètre tos spécifie la valeur du champ "Type Of service" dans l'entête IP du paquet ICMP retourné.

Lors de l'envoi d'un message ICMP de type "port unreachable", une portion du paquet initial est retournée dans le message. La section mangle-original permet de définir des modifications de cette portion du message initial. Elle comprend les paramètres suivants :

• ip-len {same|<number>}  : définit les modifications à apporter au champ longueur de l'entête IP du paquet initial. Peut valoir same (dans ce cas la valeur est inchangée) ou une valeur numérique (dans ce cas elle remplace la valeur initiale).
• ip-id {same|mangle|zero}  : définit les modifications à apporter au champ id de l'entête IP du paquet initial. Peut valoir same, zero (la valeur est mise à zéro), mangle (la valeur est changée pour une valeur différente).
• ip-csum {same|mangle|zero}  : définit les modifications à apporter au champ checksum de l'entête IP du paquet initial. Peut valoir same, zero, mangle.
• udp-len {same|<number>}  : définit les modifications à apporter au champ longueur de l'entête UDP du paquet initial. Peut valoir same ou une valeur numérique.
• udp-csum {same|mangle|zero}  : définit les modifications à apporter au champ checksum de l'entête UDP du paquet initial. Peut valoir same, zero, mangle.
• udp-data {same|mangle|zero}  : définit les modifications à apporter au premier octet de la zone de donnée du paquet UDP initial. Peut valoir same, zero, mangle.

4.3 Langage

Les sections tcp_options et tcp_decoy possèdent toutes deux un paramètre code pouvant contenir un programme. Comme vu précédemment, ce programme est compilé par la bibliothèque dynamique de iptables dans un pseudo-code interpété au sein du module noyau par une machine virtuelle simple. Celle-ci opère sur un paquet TCP en entrée et gère un état interne. Son état est composé de :

• Un buffer de stockage d'options TCP
• Plusieurs "registres" : flags, mss, wscale, win, ack et df correspondants aux champs TCP du même nom pour un éventuel paquet de réponse.

Le code de la section tcp_options est appliqué à un paquet TCP entrant, et en fin de programme, le buffer d'options dans l'état de la machine virtuelle est utilisé comme nouvelle liste d'options TCP pour le paquet.

Le code de la section tcp_decoy est également appliqué à un paquet TCP entrant, mais le paquet n'est pas modifié. En fonction du type de terminaison du programme, un nouveau paquet peut être construit à partir de l'état de la machine virtuelle et renvoyé à la source du paquet initial. Le paquet inital peut aussi être rejeté, ou continuer son cheminement normal au sein de la cible.

Ces programmes peuvent être décrits avec un langage de syntaxe proche du C. Des test conditionnels peuvent être effectués sur le paquet initial afin de gérer le comportement en fonction de son contenu.

Un test a l'allure générale suivante :

  if (test) {
    <action>
  }

  if (test) {
    <action>
  } else {
    <action>
  }

Un test est constitué d'une ou plusieurs conditions, séparées par les opérateurs && et ||, et groupées par des parenthèses si besoin. Les conditions reconnues par le langage sont :

• option(opt)  : Vrai si l'option opt est présente dans le paquet initial.
• flags(flag)  : Vrai si flag est activé dans le paquet initial.
• flags(flag1&flag2&...)  : Vrai si tous les flags spécifiés sont activés dans le paquet initial.
• flags(flag1|flag2|...)  : Vrai si au moins un des flags spécifiés est activé dans le paquet initial.
• ack(val)  : Vrai si le champ acquittement de l'entête TCP du paquet initial vaut val.
• listen  : Vrai si le port destination du paquet initial est ouvert sur la machine locale.

Le langage dispose de plusieurs instructions afin de manipuler l'état interne de la machine virtuelle :

• copy(opt)  : Ceci provoque la copie de l'option opt du paquet initial vers le buffer d'options de l'état interne de la machine virtuelle si une telle option est disponible dans le paquet initial.
• insert(opt, val)  : Ceci permet d'insérer une option dans le buffer d'état en spécifiant sa valeur précisement. Une valeur numérique peut être passée, ou alors une expression de type this + <number> qui aura pour effet de donner à l'option la valeur qu'elle a dans le paquet initial ajoutée à la valeur spécifiée. Cette instruction ne supporte que les options mss, wscale et timestamp (dans ce cas la valeur "this" correspond à la valeur courante utilisable pour le timestamp local).
• insert(opt)  : équivalent à insert(opt, this).
• set(arg, val)  : Ceci permet de définir un des registres internes de la machine virtuelle. Les registres utilisables sont flags, df, win et ack. Pour le registre flags, l'argument doit être une combinaison valide de flags TCP comme pour les tests. Les arguments df et win peuvent avoir leur valeur définie relativement à leur valeur dans le paquet initial en utilisant la construction this + <number> vue précédemment. Cette construction est également valable pour le paramètre ack mais dans ce cas la valeur finale est relative au numéro de séquence initial (et non à son numéro d'acquitement).
• drop, accept, et reply : Ces instructions provoquent l'arrêt du traitement du code en entrainant respectivement un abandon du paquet, une continuation de traitement au sein de la cible, et l'envoi d'une réponse construite à partir de l'état de la machine virtuelle. L'action par défaut en fin de programme est accept.

Ce langage permet donc simplement de définir les comportements pour réordonnancer les options ainsi que pour générer des réponses sur mesure à des tests pathologiques pour tromper les outils de détection de systèmes d'exploitation.

On peut faire les remarques suivantes :

• Compte tenu que le code de la section tcp_option n'agit que sur les options afin de le réordonner, seul le buffer d'option de l'état de la machine virtuelle est utilisé suite à l'exécution du code. En conséquence les tests listen et ack, et les instructions insert, set, drop, reply, bien que valides, y ont peu d'intêret.
• Les options supportées par les différents tests et conditions sont tirées des différentes RFC les détaillant ; en voivi les noms : eol, nop, mss, wscale, sackOK, sack, echo, echoreply, timestamp, pocOK, pocSP, CC, CC.NEW, CC.ECHO, acreq, acdata.
• Les flags TCP supportés par les différents tests englobent la totalité des 12 bits utilisables et sont représentés par les noms suivants (du bit de poids faible au bit de poids fort) : fin, syn, rst, push, ack, urg, ece, cwr, bog1, bog2, bog3, bog4.