  IP Personality
  Gal Roualland - Jean-Marc Saffroy
  $Id: ippersonality.sgml,v 1.27 2001/07/23 22:19:36 g_roual
  land Exp $

  Documentation IP Personality (List : ippersonality-devel@lists.source
  forge.net)
  ______________________________________________________________________

  Table des matires


  1. Introduction

  2. Problmes

  3. IP Personality

     3.1 Fonctionnalits
     3.2 Trajet d'un paquet dans PERS
        3.2.1 Cas d'un paquet TCP
        3.2.2 Cas d'un paquet UDP
        3.2.3 Partie commune des packets IP

  4. Configuration

     4.1 Options en ligne de commande
     4.2 Fichier de configuration
        4.2.1 Identification
        4.2.2 Paramtres gnriques TCP
        4.2.3 Paramtres de gnrateur de numros de squence
        4.2.4 Paramtres de gnrateur d'Identifiants IP
        4.2.5 Paramtres de rordonnancement des options
        4.2.6 Paramtres du leurre TCP
        4.2.7 Paramtres du leurre UDP
     4.3 Langage

  5. Exemple

     5.1 Fichier de configuration
     5.2 Rseau de test

  6. Pseudo Code

     6.1 Gnralits
     6.2 Instructions
        6.2.1 TEST
        6.2.2 JMP
        6.2.3 PUT
        6.2.4 SET
        6.2.5 RET
     6.3 Options TCP

  7. Outils de dveloppement

     7.1 Debogage
     7.2 Osdet
     7.3 Perscc

  8. Bibliographie



  ______________________________________________________________________


  11..  IInnttrroodduuccttiioonn


  En dehors des comportements specifis par les  RFC, chaque pile TCP/IP
  possde ses propres spcificits (choix d'implmentation, bugs,
  amliorations, ...) en particulier concernant la manire de ragir
  face aux paquets anormaux, c'est  dire ne respectant pas les RFC.

  Ces spcificits sont exploites par des logiciels afin de deviner, 
  distance via le rseau, quel systme d'exploitation tourne sur une
  machine donne. Ils fonctionnent en mettant des paquets anormaux (en
  jouant notamment sur la fragmentation, les flags TCP, les champs
  inutiliss, la taille des paquets, ...)  destination des machines
  cibles, et analysent les rponses en les comparant  une base de
  comportements connus des diffrents systmes d'exploitation.

  Ces logiciels sont utiliss par les administrateurs rseau pour
  recenser leurs parcs htrognes de machines, mais aussi par les
  pirates qui cherchent  apprendre le maximum d'informations sur une
  machine ou un rseau de machines pour adapter leurs attaques et
  maximiser leurs chances de russite.

  _I_P _P_e_r_s_o_n_a_l_i_t_y est un module pour _n_e_t_f_i_l_t_e_r dont l'objectif est de
  pouvoir muler diffrentes "personalits" rseau, en changeant les
  caractristiques du traffic rseau, selon diffrents paramtres. En
  particulier cela permet de tromper de tels outils en faisant passer un
  systme pour un autre, afin par exemple de masquer ou de protger des
  systmes autrement vulnrables, ou encore pour mettre en place des
  "pots de miel" (honey pots).



























  22..  PPrroobbllmmeess


  L'examen des tests effectus par nmap montre qu'ils s'appuient sur des
  paquets sinon anormaux, du moins tranges. Ceux-ci sont donc
  facilement dtectables et peuvent dclencher des actions appropries.

  Ainsi on peut aisment envisager de modifier les rponses d'une
  machine locale lorsque l'on reoit de tels paquets. Mais ces
  modifications ne sont pas sans consquences :
    certaines caractristiques d'OS sont des  l'architecture sur
     laquelle ils fonctionnent, par exemple les tailles de page mmoire
     sur diffrents processeurs, ce qui peut ventuellement poser des
     problmes de performances ;



    certaines des modifications reposent sur des choix "politiques"
     lors de l'implmentation de la pile IP (choix des numros de
     squence, taille des fentres, options IP supportes). Les modifier
     permet de tromper le dtecteur mais peut poser problme lors de
     communication lgitimes, en dtriorant les capacits de la pile IP
     ou en affaiblissant sa scurit, par exemple si la qualit gnrale
     de la pile IP du systme mul (conformit avec la RFC, robustesse)
     est infrieure  celle de la machine l'mulant.






  Malgr tout, ces modifications sont ralisables dans la plupart des
  cas pour la machine locale. En revanche, il n'en est pas de mme pour
  les machines routes, en effet :




    tous les tests ne peuvent tre grs par la machine locale, celle-
     ci ne connaissant pas l'tat prcis de la pile IP des machines
     routes, ncessaire pour gnrer les rponses adquates ;



    les dcisions prises par les machines routes ne peuvent tre que
     partiellement modifies par la machine locale et ce de manire
     permanente, la machine locale n'ayant pas de moyen de communiquer
     ses modifications aux machines routes ;



    toute information perdue par les machines routes ne pourra tre
     restitue par la machine locale ( moins de conserver tout le
     traffic, ce qui n'est pas ralisable) ;



    la machine locale ne doit pas inventer des informations. Par
     exemple, si l'on prend le cadre d'un test auquel les machines ne
     donnent aucune rponse, l'envoi d'une rponse par la machine locale
     en lieu et place de la machine route permettrait ventuellemnt de
     rpondre pour une machine inexistante.





  33..  IIPP PPeerrssoonnaalliittyy



  Au vu des contraintes prcdentes, nous avons donc opt pour une
  solution base sur _n_e_t_f_i_l_t_e_r et _i_p_t_a_b_l_e_s  : en effet, l'architecte
  d'_i_p_t_a_b_l_e_s a prvu une table mangle, justement prvue pour les
  manipulations de paquets (par opposition aux tables filter et nat,
  prvues pour le filtrage et la translation d'adresse, respectivement).
  Nous avons donc cr une nouvelle target PERS (pour IP Personality),
  qui effectue certaines oprations de rcriture sur les paquets qu'on
  lui passe. Le systme des rgles permet de laisser  _i_p_t_a_b_l_e_s le soin
  de slectionner les paquets IP en fonction de leurs adresses et ports
  source et destination, et les paramtres passs  la target PERS lui
  donnent un comportement variable, rglable par l'administrateur, qui
  peut ainsi dfinir quel type de rcriture il veut voir appliquer 
  une catgorie de paquets.
















  33..11..  FFoonnccttiioonnnnaalliittss



  Une fois install et configur correctement, IP Personality offre la
  possibilit de leurrer nmap, et de lui faire croire que la machine
  hte fait tourner un systme librement spcifi par l'administrateur.
  Les paquets de test qu'envoie nmap sont pour la plupart anormaux, et
  ceux qui ne le sont pas sont envoys  des ports ferms, donc ils
  n'influencent pas l'tat de la pile TCP/IP locale : nous pouvons donc
  les dtourner sans scrupule, et mettre les rponses qui nous
  conviennent. Le systme de configuration de PERS permet de couvrir
  tout l'ventail des possibilits de rponses, et ainsi nous pouvons
  renvoyer  nmap des paquets caractristiques de n'importe quel systme
  dcrit dans sa base de signatures.














  Certaines des oprations effectues pour leurrer nmap (pas toutes
  hlas) peuvent galement tre excutes sur des paquets routs par
  notre machine. Si nous perdons la capacit de tromper compltement
  nmap, nos manipulations sont suffisamment efficaces pour l'empcher de
  dtecter le systme utilis sur sa cible. Les oprations possibles sur
  des paquets routs sont la rcriture des numros de squence et des
  options TCP.






  Au passage, nous gagnons galement en robustesse dans le cas de
  certaines rcritures. En particulier, les machines dont les
  gnrateurs d'ISN trop simplistes les rendent vulnrables  des
  attaques par prdiction de numros de squence peuvent ainsi tre
  protges par notre target, qui leur offre un ISN parfaitement
  alatoire. De plus, grce  la souplesse qu'offre la syntaxe du
  fichier de configuration, les possibilits d'mulations ne sont pas
  limites aux outils de prise d'empreintes rseau existants : il
  devient trs facile sinon de tromper, du moins de perturber n'importe
  quel outil raisonnant sur les mmes bases que nmap, puisque nous avons
  le contrle des lments caractristiques d'un paquet.














  Pour tenir compte des nombreuses possibilits de comportement d'une
  pile IP, la configuration s'effectue via un fichier de configuration
  complet dtaillant les valeurs de diffrents paramtres. Ce fichier
  est interprt et charg dans l'espace noyau via une extension au
  programe de configuration de _n_e_t_f_i_l_t_e_r, _i_p_t_a_b_l_e_s.  En particulier,
  pour les cas de rcritures complexes dpendant de nombreux
  paramtres, le fichier contient deux sections de "code" qui sont
  interprts dans le noyau (sous forme de pseudo code) pour analyser
  plus finement les paquets selon des algorithmes analogues aux systmes
  muls.














  33..22..  TTrraajjeett dd''uunn ppaaqquueett ddaannss PPEERRSS
















                               +----->---->---+----+--->---->-----+
                               | +---<----<---| VM |---<----<---+ |
                               | |            +----+            | |
                            +--+-+--+                           | |
                        +->-| Decoy |->-+                       | |
                        |   +-------+   | +-----+   +-----+   +-+-+-+
                  +-->--+->--->--->--->-+-| SEQ |->-| WIN |->-| OPT |-+
  +-----------+   | TCP                   +-----+   +-----+   +-----+ |
  | IP Tables |->-+                                                   |--+
  +-----------+   | UDP         +---------+                           |  |
       |          +-->---->-----| Unreach |------>------>-------------+  |
       |                        +---------+                              |
       +-------<---------<--------<---------<----------<----------<------+

                <==================== IP Personality ====================>





  La cible PERS peut modifier les paquets qui lui sont passs par
  l'architecture _n_e_t_f_i_l_t_e_r. Aussi, il est logique de l'utiliser au sein
  de la table mangle spcialise dans la modification des paquets.








  Cette table accde  deux des points d'entre de _n_e_t_f_i_l_t_e_r,
  PRE_ROUTING et LOCAL_OUT. Afin de pouvoir rcrire 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 rgles configures de manire identique
  mais dont les critres sources et destinations sont symtriques. Pour
  les paquets routs, les deux rgles doivent se situer au le point
  d'entre PRE_ROUTING, puisque les paquets des deux directions sont
  d'origine extrieure  la machine locale. En revanche en ce qui
  concerne les communications avec la machine locale, si les paquets qui
  lui sont envoys passent bien par le point d'entre PRE_ROUTING, il
  n'en est pas de mme pour les paquets qu'elle met, ceux ci passant
  par LOCAL_OUT.













  Pour chacune des rgles utilises pour rcrire un type de
  communication, on prcise au module si l'on souhaite protger la
  destination de la rgle ou sa source  l'aide d'une option. En effet
  selon le sens du paquet, certaines rcritures ne sont pas faites de
  la mme manire.









  33..22..11..  CCaass dd''uunn ppaaqquueett TTCCPP



  Si le paquet est destin  la machine locale (c'est une option de la
  target), on commence par l'envoyer dans le code de gnration des
  leurres : l le pseudo-code de la section tcp_decoy du fichier de
  config dtermine si le paquet peut continuer tel quel, ou sinon
  (c'est--dire si le paquet a t identifi comme tant pathologique),
  s'il faut rpondre, avec un leurre construit en fonction du paquet.











  Si le paquet continue, il peut tre modifi de plusieurs faons. En
  particulier, le sens de circulation, qu'on peut dterminer grce aux
  informations du module conntrack d'_i_p_t_a_b_l_e_s et aux paramtres de la
  rgle en cours, dfinit le sens de la rcriture. Les altrations
  possibles sont :










     llaa rrccrriittuurree ddeess nnuummrrooss ddee ssqquueennccee :: si l'on veut pouvoir
     simuler des gnrateurs de numros de squence initiaux, on veut
     aussi que ce qui suit l'tablissement d'une connexion fonctionne
     convenablement. Il faut donc rcrire les numros de squence et
     d'acquittement de tous les paquets d'une connexion dont on a chang
     l'ISN. La premire rcriture se fait au moment du choix de l'ISN
     par l'un des gnrateurs de PERS (le fichier de configuration
     dtermine lequel et avec quels paramtres) :  ce moment, on
     sauvegarde la diffrence entre l'ISN original et celui choisi par
     PERS.  Cette diffrence entre les numros de squence utiliss par
     les deux parties restant constante, il suffit de l'ajouter aux
     numros de squence dans un sens et de la soustraire aux
     acquittements dans l'autre ;



     llaa rrccrriittuurree ddeess ttaaiilllleess ddee ffeennttrree :: la taille de fentre
     initiale tant un lment caractristique, nous voulons pouvoir la
     contrler. Mais comme dans le cas des numros de squence, il faut
     ensuite assumer ce choix et limiter la taille de fentre en
     consquence ;








     llaa rrccrriittuurree ddeess ooppttiioonnss :: lorsqu'une connexion est tablie, les
     piles TCP changent des informations utiles par le biais
     d'options : ce sont des champs optionnels de l'en-tte TCP, placs
     entre l'en-tte normale et les donnes. Le type des options
     utilises et leur ordre est un lment caractristique que nous
     pouvons modifier : c'est ce qui est fait en interprtant le pseudo-
     code de la section tcp_options. Ce code effectue des tests sur le
     type et la valeur des options, ainsi que sur les flags du paquet
     TCP, pour construire un nouveau bloc d'options qui remplace
     l'ancien dans le paquet TCP.













  33..22..22..  CCaass dd''uunn ppaaqquueett UUDDPP



  Les paquets UDP qui sont simplement routs sont ignors. Ceux qui sont
  destins  la machine locale sont examins pour vrifier qu'ils sont
  bien destins  un port UDP ouvert : si c'est bien le cas, ils
  continuent leur chemin tels quels ; dans le cas contraire, ils sont
  dtruits et PERS prend en charge l'mission d'un message ICMP de type
  "Port Unreachable", car nmap examine les caractristiques de ce
  message.










  Ce genre de message est un paquet IP contenant une en-tte ICMP suivie
  du dbut du paquet IP ayant provoqu l'erreur. Le fichier de
  configuration permet de contrler chacun des lments du paquet
  utiliss par nmap pour identifier un systme.





  33..22..33..  PPaarrttiiee ccoommmmuunnee ddeess ppaacckkeettss IIPP



  Aprs la rcriture potentielle des paquets UDP/TCP, l'ensemble des
  paquets IP peuvent galement tre modifs. Une seule modification est
  apporte pour le moment et consiste  modifier l'identifiant du paquet
  (IP ID) pour une valeur gnre selon un modle prdfini (de manire
  analogue aux numros de squences TCP).









  44..  CCoonnffiigguurraattiioonn



  La configuration de PERS s'effectue en espace utilisateur  l'aide de
  la commande _i_p_t_a_b_l_e_s et d'une bibliothque dynamique associe
  permettant de lui  passer tous ses paramtres spcifiques. Cette
  bibliothque ajoute  _i_p_t_a_b_l_e_s de nouvelles options applicables 
  chaque rgle dont la cible est PERS ; l'une de ces options permet
  l'utilisation d'un fichier de configuration  dtaill regroupant
  l'ensemble des paramtres ncessaires  l'mulation d'un systme
  d'exploitation particulier. Via l'utilisation de fichiers de
  configuration diffrents pour chaque rgle diffrente on peut donc
  trs librement choisir d'muler un systme particulier en fonction
  d'adresses sources et destinations, de l'interface, et autres critres
  de slection dans les rgles.













  44..11..  OOppttiioonnss eenn lliiggnnee ddee ccoommmmaannddee


  Les options de la ligne commande sont passes  la cible lors de
  l'ajout d'une rgle l'utilisant par exemple avec une syntaxe du type :




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

  [Se rfrer  la documentation d'_i_p_t_a_b_l_e_s pour plus de dtails sur la
  syntaxe globale]



  Les options reconnues par la bibliothque sont :


    _-_t_w_e_a_k _{_s_r_c_|_d_s_t_}  : Cette option permet de spcifier le sens de
     rcriture pour la rgle considre. Si elle vaut src cela signifie
     que l'on souhaite protger la source des paquets (et ainsi on va
     par exemple rcrire les numros de squence des paquets d'une
     connexion). Si elle vaut dst, alors on souhaite protger la
     destination de la rgle (et ainsi on rcrirait par exemple les
     acquittements de la connexion).





    _-_l_o_c_a_l  : Cete option spcifie que la source ou la destination de
     la rgle (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
     dfinis dans le fichier de configuration) permettant ainsi de
     tromper compltement des outils de type nmap en local.




    _-_c_o_n_f _<_f_i_c_h_i_e_r_> : Cette option permet de spcifier le fichier de
     configuration  utiliser pour le systme mul au sein de cette
     rgle (cf ci aprs).



  44..22..  FFiicchhiieerr ddee ccoonnffiigguurraattiioonn



  Les paramtres concernant l'mulation d'un systme particulier se
  dfinissent au sein d'un fichier. Ce fichier utilise une syntaxe
  proche de named.conf, inspire du langage C. Les options de
  configuration sont regroupes dans des blocs (dlimits par des { et
  }) et chaque bloc de configuration correspond  un type de rcriture
  diffrent. Chaque option est constitue d'un identifiant suivi d'un ou
  plusieurs arguments et termine par un symbole ;.  Les options et les
  blocs peuvent tre spcifis dans n'importe quel ordre.












  44..22..11..  IIddeennttiiffiiccaattiioonn



  Le premier lment d'un fichier de configuration est une
  identification du systme qu'il dcrit. Il s'agit d'une chane d'au
  plus 20 caractres dcrivant le systme. La syntaxe est la suivante :








   id "FakeOS";





  44..22..22..  PPaarraammttrreess ggnnrriiqquueess TTCCPP



  Ces paramtres sont regroups au sein d'une section nomme _t_c_p.
  Exemple :








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




  Le paramtre _i_n_c_o_m_i_n_g dfinit si l'on souhaite activer les
  modifications oprant sur des connexions TCP (ISN, taille de fentre,
  et Options) pour les connexions entrantes vers la zone protge. Il
  peut prendre les valeurs _y_e_s ou _n_o.





  Le paramtre _o_u_t_g_o_i_n_g est analogue pour les connexions sortantes de la
  zone protge.



  Le paramtre _m_a_x_-_w_i_n_d_o_w contrle la rcriture de la taille de fentre
  sur les paquets TCP des connexions correpondant aux rglages
  prcdents. Si il est dfini  une valeur non nulle, alors pour toute
  nouvelle connexion dont la taille de fentre lui est suprieure, un
  dcalage est calcul et la taille de fentre est ramene  une valeur
  infrieure  ce paramtre sur toute la dure de la connexion.








  44..22..33..  PPaarraammttrreess ddee ggnnrraatteeuurr ddee nnuummrrooss ddee ssqquueennccee


  Ces paramtres sont regroups au sein d'une section nomme _t_c_p___i_s_n.
  Exemple :




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




  Le paramtre _t_y_p_e dcrit le type de gnrateur  muler ainsi qu'une
  ventuelle option de cet mulation. Les types suivants sont
  implments :




    _f_i_x_e_d_-_i_n_c _<_n_u_m_b_e_r_>  : Il s'agit du gnrateur le plus simple. Le
     numro de squence initial de chaque connexion est tout simplement
     incrment d'une valeur constante (passe en argument)  chaque
     nouvelle connexion. L'utilisation de la valeur 0 comme incrment
     permet d'muler les systmes utilisant des numros de squence
     initiaux constants.




    _r_a_n_d_o_m_-_i_n_c _<_n_u_m_b_e_r_>  : Il s'agit d'un gnrateur semi-alatoire. A
     chaque nouvelle connexion le numro de squence initial est
     incrment d'une valeur alatoire entre 0 et le paramtre fourni.
     C'est le type de gnrateur utilis sur les systmes Linux,
     FreeBSD, etc... La robustesse d'un tel gnrateur est dtermin par
     la taille du paramtre.





    _t_r_u_e_-_r_a_n_d_o_m  : Il s'agit d'un gnrateur compltement alatoire. A
     chaque nouvelle connexion, le numro de squence est gnr de
     manire purement alatoire (en utilisant le gnrateur alatoire 
     entropie variable du noyau).



    _b_u_i_l_t_i_n  : Il s'agit du gnrateur de base du systme courant. Sous
     Linux il s'agit donc d'un grrateur  incrments alatoires.


    _t_i_m_e_-_d_e_p _<_n_u_m_b_e_r_>  : Il s'agit d'un gnrateur dpendant du temps.
     Le nombre pass en paramtre indique la frquence de progression du
     gnrateur (en Hz). Par exemple, une valeur de 25000 permet
     d'implmenter le gnrateur dcrit dans la RFC 793 : le numro de
     squence initial est alors incrment de 1 toutes les 4 micro-
     secondes. (la granularit du gnrateur dpend toutefois de la
     prcsion des "ticks" du systme, 100 Hz par dfaut sous linux/x86)






  Le paramtre _i_n_i_t_i_a_l_-_v_a_l_u_e dcrit la valeur initiale  utiliser pour
  le gnrateur de numro de squence. Il peut s'agir d'une valeur
  numrique ou bien du mot-cl _r_a_n_d_o_m qui choisira une valeur alatoire
  lors de l'insertion de la rgle.  Ce paramtre a peu d'importance pour
  les types de gnrateurs peu prdictibles.

  44..22..44..  PPaarraammttrreess ddee ggnnrraatteeuurr dd''IIddeennttiiffiiaannttss IIPP


  Ces paramtres sont regroups au sein d'une section nomme _i_p___i_d.
  Exemple :







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




  Le paramtre _t_y_p_e dcrit le type de gnrateur  muler ainsi qu'une
  ventuelle option de cet mulation. Les mme types que pour les
  gnrateurs de numros de squences sont accepts, et un choix
  supplmentaire, _b_r_o_k_e_n_-_i_n_c _n_u_m_b_e_r est disponible : il s'agit d'un
  compteur incrment de la valeur spcifie  chaque utilisation, mais
  dont le rsultat est stoqu dans le paquet au format "little endian",
  au lieu de l'ordre rseau.








  44..22..55..  PPaarraammttrreess ddee rroorrddoonnnnaanncceemmeenntt ddeess ooppttiioonnss


  Ces paramtres sont regroups au sein d'une section nomme
  _t_c_p___o_p_t_i_o_n_s.  Exemple :







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




  Cette section dfinit comment les options TCP d'un paquet doivent tre
  rcrites. La sous-section _c_o_d_e contient un programme dans un langage
  proche du C (dcrit par la suite) qui est compil par le module
  _l_i_b_i_p_t___P_E_R_S_._s_o. Ce code est pass  la machine virtuelle qui remplit
  le buffer d'options constituant son tat au fer et  mesure de
  l'excution. Lorsque l'excution est acheve, le buffer d'options
  rsultant est utilis pour remplacer les options initiales du paquet.








  Le paramtre _k_e_e_p_-_u_n_k_n_o_w_n spcifie si les options "inconnues"
  prsentes dans le paquet initial, et donc non manipulables par le
  programme de rcriture, doivent tre rajoutes  la fin du buffer
  final afin d'tre prsentes dans le paquet final. Ce paramtre peut
  prendre les valeurs _y_e_s ou _n_o.





  Le paramtre _k_e_e_p_-_u_n_u_s_e_d spcifie si les options du paquet original
  qui n'ont pas t utilises (testes ou recopies) pendant l'excution
  du programme doivent tre recopies  la fin du buffer afin d'tre
  prsentes dans le paquet final. Ce paramtre peut prendre les valeurs
  _y_e_s ou _n_o. Ceci permet d'utiliser un code assez simple pour rordonner
  seulement quelques options tout en conservant toutes les options du
  paquet original.







  Le paramtre _i_s_o_l_a_t_e_d_-_p_a_c_k_e_t_s spcifie si la rcriture des options
  doit tre applique aux paquets n'appartenant  aucune connexion
  connue. Ce paramtre peut prendre les valeurs _y_e_s ou _n_o (valeur par
  dfaut).





  Le paramtre _t_i_m_e_s_t_a_m_p_-_s_c_a_l_e spcifie si l'on souhaite changer la
  valeur des "timestamp" TCP dans les paquets communiquant avec la
  machine locale. Il prend en argument la frquence  utiliser pour les
  nouveaux "timestamp". (si la valeur est nulle ou gale  la frquence
  nominale, l'option est ignore).






  44..22..66..  PPaarraammttrreess dduu lleeuurrrree TTCCPP


  Ces paramtres sont regroups au sein d'une section nomme _t_c_p___d_e_c_o_y.
  Exemple :








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




  Cette section se rsume  une sous-section _c_o_d_e analogue  celle de la
  section prcdente, qui dfinit un certain nombre de tests  effectuer
  sur le paquet initial afin de reconnatre des paquets caractristiques
  d'outils de dtection et de rpondre en consquence. Le langage
  utilis est le mme que prcdemment (dcrit ci aprs).






  44..22..77..  PPaarraammttrreess dduu lleeuurrrree UUDDPP


  Ces paramtres sont regroups au sein d'une section nomme
  _u_d_p___u_n_r_e_a_c_h.  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 paramtre _r_e_p_l_y dtermine si l'on souhaite mettre un message ICMP
  de type "port unreachable" lorsque l'on reoit un message UDP pour un
  port non ouvert localement. Il peut tre dfini  _y_e_s ou  _n_o. Les
  autres paramtres de cette section s'appliquent si il est activ.





  Le paramtre _d_f spcifie si le bit "Don't Fragment" de l'entte IP du
  paquet ICMP doit tre activ ou non.



  Le paramtre _m_a_x_-_l_e_n spcifie la longueur maximum du message ICMP
  gnr en rponse.
  Le paramtre _t_o_s spcifie la valeur du champ "Type Of service" dans
  l'entte IP du paquet ICMP retourn.



  Lors de l'envoi d'un message ICMP de type "port unreachable", une
  portion du paquet initial est retourne dans le message. La section
  _m_a_n_g_l_e_-_o_r_i_g_i_n_a_l permet de dfinir des modifications de cette portion
  du message initial. Elle comprend les paramtres suivants :






    _i_p_-_l_e_n _{_s_a_m_e_|_<_n_u_m_b_e_r_>_}  : dfinit les modifications  apporter au
     champ longueur de l'entte IP du paquet initial. Peut valoir _s_a_m_e
     (dans ce cas la valeur est inchange) ou une valeur numrique (dans
     ce cas elle remplace la valeur initiale).



    _i_p_-_i_d _{_s_a_m_e_|_m_a_n_g_l_e_|_z_e_r_o_}  : dfinit les modifications  apporter au
     champ id de l'entte IP du paquet initial. Peut valoir _s_a_m_e, _z_e_r_o
     (la valeur est mise  zro), _m_a_n_g_l_e (la valeur est change pour une
     valeur diffrente).





    _i_p_-_c_s_u_m _{_s_a_m_e_|_m_a_n_g_l_e_|_z_e_r_o_}  : dfinit les modifications  apporter
     au champ checksum de l'entte IP du paquet initial. Peut valoir
     _s_a_m_e, _z_e_r_o, _m_a_n_g_l_e.



    _u_d_p_-_l_e_n _{_s_a_m_e_|_<_n_u_m_b_e_r_>_}  : dfinit les modifications  apporter au
     champ longueur de l'entte UDP du paquet initial. Peut valoir _s_a_m_e
     ou une valeur numrique.



    _u_d_p_-_c_s_u_m _{_s_a_m_e_|_m_a_n_g_l_e_|_z_e_r_o_}  : dfinit les modifications  apporter
     au champ checksum de l'entte UDP du paquet initial. Peut valoir
     _s_a_m_e, _z_e_r_o, _m_a_n_g_l_e.




    _u_d_p_-_d_a_t_a _{_s_a_m_e_|_m_a_n_g_l_e_|_z_e_r_o_}  : dfinit les modifications  apporter
     au premier octet de la zone de donne du paquet UDP initial. Peut
     valoir _s_a_m_e, _z_e_r_o, _m_a_n_g_l_e.





  44..33..  LLaannggaaggee


  Les sections _t_c_p___o_p_t_i_o_n_s et _t_c_p___d_e_c_o_y possdent toutes deux un
  paramtre code pouvant contenir un programme. Comme vu prcdemment,
  ce programme est compil par la bibliothque dynamique de _i_p_t_a_b_l_e_s
  dans un pseudo-code interpt au sein du module noyau par une machine
  virtuelle simple. Celle-ci opre sur un paquet TCP en entre et gre
  un tat interne. Son tat est compos de :









    Un buffer de stockage d'options TCP

    Plusieurs "registres" : _f_l_a_g_s, _m_s_s, _w_s_c_a_l_e, _w_i_n, _a_c_k et _d_f
     correspondants aux champs TCP du mme nom pour un ventuel paquet
     de rponse.



  Le code de la section _t_c_p___o_p_t_i_o_n_s 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 _t_c_p___d_e_c_o_y 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 dcrits avec un langage de syntaxe proche
  du C. Des test conditionnels peuvent tre effectus sur le paquet
  initial afin de grer le comportement en fonction de son contenu.




  Un test a l'allure gnrale suivante :



         if (test) {
           <action>
         }




  ou






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




  Un test est constitu d'une ou plusieurs conditions, spares par les
  oprateurs && et ||, et groupes par des parenthses si besoin. Les
  conditions reconnues par le langage sont :





    _o_p_t_i_o_n_(_o_p_t_)  : Vrai si l'option _o_p_t est prsente dans le paquet
     initial.

    _f_l_a_g_s_(_f_l_a_g_)  : Vrai si _f_l_a_g est activ dans le paquet initial.

    _f_l_a_g_s_(_f_l_a_g_1_&_f_l_a_g_2_&_._._._)   : Vrai si tous les flags spcifis sont
     activs dans le paquet initial.

    _f_l_a_g_s_(_f_l_a_g_1_|_f_l_a_g_2_|_._._._)   : Vrai si au moins un des flags spcifis
     est activ dans le paquet initial.


    _a_c_k_(_v_a_l_)  : Vrai si le champ acquittement de l'entte TCP du paquet
     initial vaut _v_a_l.

    _l_i_s_t_e_n  : 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 :




    _c_o_p_y_(_o_p_t_)  : Ceci provoque la copie de l'option _o_p_t 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.



    _i_n_s_e_r_t_(_o_p_t_, _v_a_l_)  : Ceci permet d'insrer une option dans le buffer
     d'tat en spcifiant sa valeur prcisement. Une valeur numrique
     peut tre passe, ou alors une expression de type _t_h_i_s _+ _<_n_u_m_b_e_r_>
     qui aura pour effet de donner  l'option la valeur qu'elle a dans
     le paquet initial ajoute  la valeur spcifie.  Cette instruction
     ne supporte que les options _m_s_s, _w_s_c_a_l_e et _t_i_m_e_s_t_a_m_p (dans ce cas
     la valeur "this" correspond  la valeur courante utilisable pour le
     timestamp local).







    _i_n_s_e_r_t_(_o_p_t_)  : quivalent  _i_n_s_e_r_t_(_o_p_t_, _t_h_i_s_).


    _s_e_t_(_a_r_g_, _v_a_l_)  : Ceci permet de dfinir un des registres internes
     de la machine virtuelle. Les registres utilisables sont _f_l_a_g_s, _d_f,
     _w_i_n et _a_c_k. Pour le registre _f_l_a_g_s, l'argument doit tre une
     combinaison valide de flags TCP comme pour les tests. Les arguments
     _d_f et _w_i_n peuvent avoir leur valeur dfinie relativement  leur
     valeur dans le paquet initial en utilisant la construction _t_h_i_s _+
     _<_n_u_m_b_e_r_> vue prcdemment.  Cette construction est galement
     valable pour le paramtre _a_c_k mais dans ce cas la valeur finale est
     relative au numro de squence initial (et non  son numro
     d'acquitement).









    _d_r_o_p, _a_c_c_e_p_t, et _r_e_p_l_y : Ces instructions provoquent l'arrt 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 rponse construite  partir de l'tat de la machine
     virtuelle. L'action par dfaut en fin de programme est _a_c_c_e_p_t.





  Ce langage permet donc simplement de dfinir les comportements pour
  rordonnancer les options ainsi que pour gnrer des rponses sur
  mesure  des tests pathologiques pour tromper les outils de dtection
  de systmes d'exploitation.




  On peut faire les remarques suivantes :



    Compte tenu que le code de la section _t_c_p___o_p_t_i_o_n n'agit que sur les
     options afin de le rordonner, seul le buffer d'option de l'tat de
     la machine virtuelle est utilis suite  l'excution du code. En
     consquence les tests _l_i_s_t_e_n et _a_c_k, et les instructions _i_n_s_e_r_t,
     _s_e_t, _d_r_o_p, _r_e_p_l_y, bien que valides, y ont peu d'intret.





    Les options supportes par les diffrents tests et conditions sont
     tires des diffrentes RFC les dtaillant ; en voivi les noms :



     _e_o_l, _n_o_p, _m_s_s, _w_s_c_a_l_e, _s_a_c_k_O_K, _s_a_c_k, _e_c_h_o, _e_c_h_o_r_e_p_l_y, _t_i_m_e_s_t_a_m_p,
     _p_o_c_O_K, _p_o_c_S_P, _C_C, _C_C_._N_E_W, _C_C_._E_C_H_O, _a_c_r_e_q, _a_c_d_a_t_a.

    Les flags TCP supports par les diffrents tests englobent la
     totalit des 12 bits utilisables et sont reprsents par les noms
     suivants (du bit de poids faible au bit de poids fort) :



     _f_i_n, _s_y_n, _r_s_t, _p_u_s_h, _a_c_k, _u_r_g, _e_c_e, _c_w_r, _b_o_g_1, _b_o_g_2, _b_o_g_3, _b_o_g_4.
  55..  EExxeemmppllee



  55..11..  FFiicchhiieerr ddee ccoonnffiigguurraattiioonn


  Supposons que l'on souhaite raliser un fichier de configuration pour
  muler un AmigaOS. Pour cela, on dispose de la signature nmap suivante
  (se rfrer  la documentation de nmap pour plus de dtails) :






         Fingerprint AmigaOS AmiTCP/IP 4.3
         TSeq(Class=64K)
         T1(DF=N%W=1F0E%ACK=S++%Flags=AS%Ops=M)
         T2(Resp=N)
         T3(Resp=Y%DF=N%W=1F0E%ACK=O%Flags=A%Ops=)
         T4(DF=N%W=2000%ACK=O%Flags=R%Ops=)
         T5(DF=N%W=0%ACK=S++%Flags=AR%Ops=)
         T6(DF=N%W=0%ACK=O%Flags=R%Ops=)
         T7(DF=N%W=0%ACK=S%Flags=AR%Ops=)
         PU(DF=N%TOS=0%IPLEN=38%RIPTL=15C%RID=E%RIPCK=0%UCK=0%ULEN=134%DAT=E)




  Nous devons commencer la configuration par la dfinition d'un
  identifiant, comme suit :





         id "AmigaOS";




  On souhaite rcrire les connexions TCP entrantes dans un premier
  temps, et ne pas agir sur les tailles de fentres (simplement tromper
  nmap), aussi utilise-t-on des valeurs gnriques pour la section _t_c_p.






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




  La ligne _T_S_e_q de la signature nmap dfinit le type de gnrateur de
  numro de squence initial utiliser. Le paramtre important en est la
  classe du gnrateur. On peut rencontrer les classes suivantes :



    _C_l_a_s_s_=_C  : Gnrateur constant, correspondant  _f_i_x_e_d_-_i_n_c _0.

    _C_l_a_s_s_=_T_D  : Gnrateur dpendant du temps. On peut l'muler avec un
     gnrateur  incrment fixe faible de manire  satisfaire les
     paramtres _g_c_d et _s_i. Il n'y a pas d'heuristiques particulire pour
     cela, il faut donc essayer plusieurs valeurs diffrentes.



    _C_l_a_s_s_=_R_I  : Gnrateur  incrments alatoires. Ce gnrateur est
     mul avec le mode _r_a_n_d_o_m_-_i_n_c. L'intervalle de recherche alatoire
     est dtermin par la difficult retourne par nmap (_g_c_d et _s_i).
     Mme restrictions que prcdemment.



    _C_l_a_s_s_=_T_R  : Gnrateur parfaitement alatoire. mul par _t_r_u_e_-
     _r_a_n_d_o_m.

    _C_l_a_s_s_=_i_8_0_0, _C_l_a_s_s_=_6_4_K  : Incrmentation fixes, respectivement de
     multiples de 800 et de 64000.

  Ici on utilisera donc :




         tcp_isn {
           type fixed-inc 64000;
           initial-value random;
         }




  Ensuite on trouve l'ensemble des tests TCP effectus par nmap au sein
  des lignes _T_x. La syntaxe de ces lignes est toujours la mme et dcrit
  l'ventuelle rponse reue par nmap  son test.






         Tx(Resp=Y%DF=Y%W=XXXX%ACK=S++%Flags=AS%Ops=M)




  La signification des diffrents champs est la suivante :



    _R_e_s_p  : _Y si une rponse a t reue, _N sinon.

    _D_F  : Indique si le bit "Don't Fragment" est positionn dans la
     rponse

    _W  : Indique la ou les tailles de fentres (spares par des "|")
     attendues dans la rponse.


    _A_C_K  : Indique la valeur attendue pour l'acquittement dans la
     rponse. Peut valoir une valeur numrique ou _S pour indiquer le
     numro de squence du test, ou _S_+_+ pour indiquer le numro de
     squence du test plus un.
    _F_l_a_g_s  : Contient les flags TCP activs dans la rponse, sous la
     forme de leurs initiales repectives (_A pour _A_c_k, _S pour _S_y_n, ...).



    _O_p_s  : Contient la liste des options prsentes suivant leur ordre
     au sein de la rponse, sous forme de leurs initiales repectives (_M
     pour _M_S_S, _N pour _N_O_P, ...) sauf pour _E qui signifie que l'option
     prcdente est de la mme valeur que dans le paquet de test.




  Si l'on souhaite muler le systme prcisment, il faut dduire des
  diffrents rsultats l'ordre des options  partir des rponses que
  nmap reoit et des paquets initiaux auxquels elles correspondent. Ici,
  on n'a qu'une option donc la section correspondante est assez simple :







         tcp_options {
           keep-unknown yes;
           keep-unused no;
           isolated-packets yes;
           code {
             copy(mss);
           }
         }




  A ce stade le systme ressemble un peu  celui mul. En revanche sur
  les tests trs prcis, nos rponses ne statisferont pas nmap. Afin de
  le tromper compltement en local, on peut dduire des rsultats aux
  tests TCP les rponses  lui retourner au sein du mode _d_e_c_o_y.  Pour ce
  faire on utilise un "squelette" de code adapt aux tests de nmap que
  l'on complte afin de gnrer les rponses attendues :
























    tcp_decoy {
      code {
        if (option(mss)) {
          if (listen) {
            if (flags(syn&ece)) {
              /* nmap test 1 */
            }
            if (flags(null)) {
              /* nmap test 2 */
            }
            if (flags(syn&fin&urg&push)) {
              /* nmap test 3 */
            }
            if (ack(0) && flags(ack) && !flags(syn|push|urg|rst)) {
              /* nmap test 4 *
            }
          } else {
            if (flags(syn) && !flags(ack)) {
              /* nmap test 5 */
            }
            if (ack(0) && flags(ack) && !flags(syn|push|urg|rst)) {
              /* nmap test 6 *
            }
            if (flags(fin&push&urg)) {
              /* nmap test 7 */
            }
          }
        }
      }
    }




  Et il n'y a plus qu' crire le code pour chaque test, par exemple
  pour le premier





         set(df, 0);
         set(win, 0x1F0E);
         set(ack, this + 1);
         set(flags, ack|syn);
         insert(mss, this+1);
         reply;




  ou pour le second (pas de rponse) :




         drop;




  Enfin on peut galement ragir localement (au sein de la section
  _u_d_p___d_e_c_o_y) au dernier test de nmap, le test UDP port-unreach (_P_U), qui
  a la syntaxe suivante :


         PU(DF=N%TOS=0%IPLEN=38%RIPTL=15C%RID=E%RIPCK=0%UCK=0%ULEN=134%DAT=E)




  La signification des diffrents champs est la suivante :


    _R_e_s_p  : Comme prcdemment, correspond  l'option _r_e_p_l_y.

    _D_F  : Comme prcdemment, correspond  l'option _d_f.

    _T_O_S  : Type Of Service, correspond  l'option _t_o_s.

    _I_P_L_E_N  : longueur du paquet ICMP. Peut-tre dfinie via l'option
     _m_a_x_-_l_e_n.


     La rponse ICMP gnre contient le dbut du paquet original
     (comportement recommand par les RFC). Nmap essaie de dterminer si
     certaines portions en ont t changes au cours du traitement via
     les paramtres suivants, correspondants  ceux de la section
     _m_a_n_g_l_e_-_o_r_i_g_i_n_a_l.




    _R_I_D_, _R_I_P_C_K_, _U_C_K_, _D_A_T  : Ces paramtres dfinissent les
     modifications apportes  (respectivement) l'ID IP original, le
     checksum IP original, le checksum UDP original, les donnes
     originales. Chacun de ces paramtres peut avoir une des trois
     valeurs suivantes : _0 (mis  zro), _F ("fucked", valeur change), _E
     (gal). Ces paramtres correspondent aux options suivantes (mme
     ordre) _i_p_-_i_d, _i_p_-_c_s_u_m, _u_d_p_-_c_s_u_m, _u_d_p_-_d_a_t_a qui peuvent prendre une
     des valeurs suivantes :







     _z_e_r_o, _m_a_n_g_l_e, _s_a_m_e.

    _R_I_P_L_E_N_, _U_L_E_N  : Ces paramtres dcrivent les longeurs initiales des
     paquets IP et UDP, correspondant aux options _i_p_-_l_e_n et _u_d_p_-_l_e_n.
     Elles peuvent tre dfinies  une valeur quelconque ou  _s_a_m_e pour
     conserver les valeurs originales.



  Ici, on pourrait donc utiliser ce qui suit :














    udp_unreach {
      reply yes;
      df no;
      max-len 56;
      tos 0;

      mangle-original {
        ip-len 348;
        ip-id same;
        ip-csum zero;
        udp-len 308;
        udp-csum zero;
        udp-data same;
      }
    }




  Il n'y a plus qu' tester ! Un tel fichier peut par la suite tre
  amlior et optimis afin d'tre  la fois plus fiable (le
  rordonnancement d'option et le gnrateur de numros de squence
  initiaux ne sont pas simples  "deviner") et plus performant
  (regrouper les tests, etc.).





  55..22..  RRsseeaauu ddee tteesstt


  Afin de dmontrer quelques unes des capacits du module IP
  Personality, plaons nous dans le cadre de deux rseaux rduits  une
  machine, relis via une machine routeur o tourne le module. La
  configuration esr la suivante :







       +---------+           +---------+           +---------+
       | suskind |<--------->|   dse2  |<--------->|   dse1  |
       +---------+           +---------+           +---------+




  Les systmes d'exploitation utiliss pour les tests sont sur chacune
  des machines :



    suskind : FreeBSD-2.2.8-RELEASE.

    dse1 : Linux 2.2.14.

    dse2 : Linux 2.3.99pre6 (ippersonality).

  On peut tout de suite vrifier que ces OS sont mutuellement
  dtectables  l'aide de nmap par exemple,  partir de chacune des
  machines. (on a laiss les dtails afin de voir en quoi ils changent
  par la suite).

  Si l'on effectue un nmap de suskind vers dse2 :




         TCP Sequence Prediction: Class=random positive increments
                                  Difficulty=2119945 (Good luck!)

         Sequence numbers: 59CEAA9C 5987D082 59CC67D4 59598903 5983CC3D 5971B98C
         Remote OS guesses: Linux 2.3.49 x86, Linux 2.3.99-pre2 x86
         OS Fingerprint:
         TSeq(Class=RI%gcd=1%SI=205909)
         T1(Resp=Y%DF=Y%W=7C70%ACK=S++%Flags=AS%Ops=MNNTNW)
         T2(Resp=N)
         T3(Resp=Y%DF=Y%W=7C70%ACK=S++%Flags=AS%Ops=MNNTNW)
         T4(Resp=Y%DF=Y%W=0%ACK=O%Flags=R%Ops=)
         T5(Resp=Y%DF=Y%W=0%ACK=S++%Flags=AR%Ops=)
         T6(Resp=Y%DF=Y%W=0%ACK=O%Flags=R%Ops=)
         T7(Resp=Y%DF=Y%W=0%ACK=S++%Flags=AR%Ops=)
         PU(Resp=Y%DF=Y%TOS=C0%IPLEN=164%RIPTL=148%RID=E%RIPCK=E%UCK=E%ULEN=134%DAT=E)




  On observe le mme rsultat avec un nmap de dse1 vers dse2.


  Si l'on effectue un nmap de dse1 vers suskind :




         TCP Sequence Prediction: Class=random positive increments
                                  Difficulty=9819 (Worthy challenge)

         Sequence numbers: 3B1E1359 3B1F0409 3B1F9BAB 3B201E56 3B20B8D2 3B217357
         Remote operating system guess: FreeBSD 2.2.1 - 3.2
         OS Fingerprint:
         TSeq(Class=RI%gcd=1%SI=265B)
         T1(Resp=Y%DF=Y%W=403D%ACK=S++%Flags=AS%Ops=MNWNNT)
         T2(Resp=N)
         T3(Resp=Y%DF=Y%W=403D%ACK=S++%Flags=AS%Ops=MNWNNT)
         T4(Resp=Y%DF=N%W=4000%ACK=O%Flags=R%Ops=)
         T5(Resp=Y%DF=N%W=0%ACK=S++%Flags=AR%Ops=)
         T6(Resp=Y%DF=N%W=0%ACK=O%Flags=R%Ops=)
         T7(Resp=Y%DF=N%W=0%ACK=S%Flags=AR%Ops=)
         PU(Resp=Y%DF=N%TOS=0%IPLEN=38%RIPTL=148%RID=F%RIPCK=F%UCK=0%ULEN=134%DAT=E)




  On se donne maintenant 3 fichiers d'mulation de systmes
  d'exploitation, soit _a_m_i_g_a_o_s_._c_o_n_f, _l_i_n_u_x_._c_o_n_f, et _w_i_n_9_x_._c_o_n_f.




  On dcide de faire passer dse2 pour une machine windows auprs de
  suskind. Il suffit d'utiliser les deux ligne suivantes (sur dse2) :







    iptables -t mangle -A PREROUTING -s suskind -d dse2 -j PERS --tweak dst \
      --local --conf win9x.conf
    iptables -t mangle -A OUTPUT -s dse2 -d suskind -j PERS --tweak src \
      --local --conf win9x.conf




  On dcide ensuite de faire passer dse2 pour une machine amiga auprs
  de dse1. Il suffit de rajouter les deux lignes suivantes :





         iptables -t mangle -A PREROUTING -s dse1 -d dse2 -j PERS --tweak dst \
           --local --conf amigaos.conf
         iptables -t mangle -A OUTPUT -s dse2 -d dse1 -j PERS --tweak src \
           --local --conf amigaos.conf




  Pour utiliser le rle de routeur de la machine on veut galement
  modifier la manire dont dse1 voit suskind, en faisant passer suskind
  pour une machine sous Linux.





         iptables -t mangle -A PREROUTING -s suskind -d dse1 -j PERS --tweak src \
           --conf linux.conf
         iptables -t mangle -A PREROUTING -s dse1 -d suskind -j PERS --tweak dst \
           --conf linux.conf




  Voyons maintenant ce que donnent les mme tests que prcdemment (avec
  nmap).


  Si l'on effectue un nmap de suskind vers dse2 :




         TCP Sequence Prediction: Class=trivial time dependency
                                  Difficulty=0 (Trivial joke)

         Sequence numbers: A97ECB1D A97ECB1F A97ECB21 A97ECB23 A97ECB25 A97ECB27
         Remote operating system guess: Windows NT4 / Win95 / Win98
         OS Fingerprint:
         TSeq(Class=TD%gcd=2%SI=0)
         T1(Resp=Y%DF=Y%W=2017%ACK=S++%Flags=AS%Ops=M)
         T2(Resp=Y%DF=N%W=0%ACK=S%Flags=AR%Ops=)
         T3(Resp=Y%DF=Y%W=2017%ACK=S++%Flags=AS%Ops=M)
         T4(Resp=Y%DF=N%W=0%ACK=S++%Flags=R%Ops=)
         T5(Resp=Y%DF=N%W=0%ACK=S++%Flags=AR%Ops=)
         T6(Resp=Y%DF=N%W=0%ACK=S++%Flags=R%Ops=)
         T7(Resp=Y%DF=N%W=0%ACK=S++%Flags=AR%Ops=)
         PU(Resp=N)



  Si l'on effectue un nmap de dse1 vers dse2 :




         TCP Sequence Prediction: Class=64K rule
                                  Difficulty=1 (Trivial joke)

         Sequence numbers: D997B378 D998AD78 D999A778 D99AA178 D99B9B78 D99C9578
         Remote operating system guess: AmigaOS AmiTCP/IP 4.3
         OS Fingerprint:
         TSeq(Class=64K)
         T1(Resp=Y%DF=N%W=1F0E%ACK=S++%Flags=AS%Ops=M)
         T2(Resp=N)
         T3(Resp=Y%DF=N%W=1F0E%ACK=O%Flags=A%Ops=)
         T4(Resp=Y%DF=N%W=2000%ACK=O%Flags=R%Ops=)
         T5(Resp=Y%DF=N%W=0%ACK=S++%Flags=AR%Ops=)
         T6(Resp=Y%DF=N%W=0%ACK=O%Flags=R%Ops=)
         T7(Resp=Y%DF=N%W=0%ACK=S%Flags=AR%Ops=)
         PU(Resp=Y%DF=N%TOS=0%IPLEN=38%RIPTL=15C%RID=E%RIPCK=0%UCK=0%ULEN=134%DAT=E)




  Si l'on effectue un nmap de dse1 vers suskind :



         TCP Sequence Prediction: Class=random positive increments
                                  Difficulty=188907 (Good luck!)

         Sequence numbers: 32BD32 393D33 3B87EE 3FE6A3 4AC5E7 4F9533
         No OS matches for host (If you know what OS is running on it,
         see http://www.insecure.org/cgi-bin/nmap-submit.cgi).
         TCP/IP fingerprint:
         TSeq(Class=RI%gcd=1%SI=2EF4C)
         TSeq(Class=RI%gcd=1%SI=2EF18)
         TSeq(Class=RI%gcd=1%SI=2E1EB)
         T1(Resp=Y%DF=Y%W=403D%ACK=S++%Flags=AS%Ops=MNNTNW)
         T2(Resp=N)
         T3(Resp=Y%DF=Y%W=403D%ACK=S++%Flags=AS%Ops=MNNTNW)
         T4(Resp=Y%DF=N%W=4000%ACK=O%Flags=R%Ops=)
         T5(Resp=Y%DF=N%W=0%ACK=S++%Flags=AR%Ops=)
         T6(Resp=Y%DF=N%W=0%ACK=O%Flags=R%Ops=)
         T7(Resp=Y%DF=N%W=0%ACK=S%Flags=AR%Ops=)
         PU(Resp=Y%DF=N%TOS=0%IPLEN=38%RIPTL=148%RID=F%RIPCK=F%UCK=0%ULEN=134%DAT=E)




  On constate bien que dans le cas de la machine locale dse2 on peut
  compltement tromper nmap. En revanche en mode "routeur", les
  paramtres sur lesquels on joue le perturbent, mais ne suffisent pas 
  lui faire dtecter un autre systme.






  66..  PPsseeuuddoo CCooddee

  66..11..  GGnnrraalliittss



  Nous avons implment une machine virtuelle simple au sein du noyau.
  Celle-ci opre sur un paquet TCP en entre et gre un tat interne.
  Son tat est compos de :




    Un pointeur d'instruction dans le code.

    Un buffer de stockage d'options TCP.

    Plusieurs "registres" :

     _f_l_a_g_s, _m_s_s, _w_s_c_a_l_e, _w_i_n, _a_c_k et _d_f correspondants aux champs TCP du
     mme nom pour un ventuel paquet de rponse.


  Le code execut par la machine virtuelle est compos d'instructions
  sur 32 bits (en ordre de la machine) regroupant un mnmonique (sur 8
  bits), une option (sur 4 bits) et un oprande (sur 20 bits), comme
  visible ci aprs.






       0              7 8     11 12                                    31
       +---------------+--------+---------------------------------------+
       |    Mnemonic   | Option |              Operand                  |
       +---------------+--------+---------------------------------------+





  66..22..  IInnssttrruuccttiioonnss



  66..22..11..  TTEESSTT


  CCooddee :: 01

  Effectue un test sur l'objet dfini par l'option. Si le test est vrai,
  le pointeur d'instruction passe de l'instruction _i  l'instruction
  _i_+_2. Si le test est faux, l'excution se continue  l'instruction _i_+_1.





  Les options des tests sont les suivantes :



    _T_C_P _O_p_t_i_o_n (0)  : Vrai si l'option TCP dont le code est pass en
     oprande est dfini dans le paquet initial.



    _A_n_y _T_C_P _F_l_a_g_s (1)  : Vrai si un des flags TCP passs en oprande
     est activ dans les flags TCP du paquet initial.


    _A_l_l _T_C_P _F_l_a_g_s (2)  : Vrai si tous les flags TCP passs en oprande
     sont activs dans les flags TCP du paquet initial.



    _A_c_k (3)  : Vrai si la valeur de l'acquittement du paquet initial
     vaut l'oprande.


    _L_i_s_t_e_n (4)  : Vrai si le port destination du paquet initial est
     ouvert sur la machine locale.



  66..22..22..  JJMMPP


  CCooddee :: 02

  Continue l'excution  l'instruction dont le numro est l'oprande.



  66..22..33..  PPUUTT


  CCooddee :: 03

  Insre une option TCP dans le buffer d'options TCP. L'option TCP
  insre est l'oprande, sa source est dtermine par l'option de
  l'instruction.




  Les options sont les suivantes :



    _C_o_p_y (0)  : L'option insre est copie  partir du paquet initial
     si elle y est dfinie.


    _I_n_s_e_r_t (1)  : L'option insre est copie  partir des registres de
     la machine virtuelle. Uniquement valable pour les options _m_s_s,
     _w_s_c_a_l_e and _t_i_m_e_s_t_a_m_p.





  66..22..44..  SSEETT


  CCooddee :: 04

  Dfinit la valeur d'un registre de la machine virtuelle. Le registre
  concern et le type d'affectation sont dtermins par l'option. La
  valeur utilise est l'oprande.




  Les options acceptes sont les suivantes :


    _f_l_a_g_s (0)  : Dfinit le registre _f_l_a_g_s  la valeur de l'oprande.


    _a_c_k (1)  : Dfinit le registre _a_c_k (acquittement)  la valeur de
     l'oprande.


    _d_f (2)  : Dfinit le registre _d_f (bit "Don't Fragment" de l'entte
     IP)  la valeur de l'oprande.


    _w_i_n (3)  : Dfinit le registre _w_i_n (taille de fentre)  la valeur
     de l'oprande.


    _m_s_s (4)  : Dfinit le registre _m_s_s (taille de segment TCP maximale)
      la valeur de l'oprande.


    _w_s_c_a_l_e (5)  : Dfinit le registre _w_s_c_a_l_e (mise  l'chelle de la
     fentre)  la valeur de l'oprande.


    _t_i_m_e_s_t_a_m_p (6)  : Dfinit le registre _t_i_m_e_s_t_a_m_p (valeur locale du
     timestamp)  la valeur de l'oprande.


    _r_e_l_a_t_i_v_e _a_c_k (9)  : Dfinit le registre _a_c_k (acquittement)  la
     valeur de l'oprande ajoute au numro de squence du paquet
     initial.



    _r_e_l_a_t_i_v_e _d_f (10)  : Dfinit le registre _d_f (bit "Don't Fragment" de
     l'entte IP)  la valeur de l'oprande ajoute  celle de la valeur
     de ce champ dans le paquet initial.



    _r_e_l_a_t_i_v_e _w_i_n (11)  : Dfinit le registre _w_i_n (taille de fentre) 
     la valeur de l'oprande ajoute  la taille de fentre du paquet
     initial.



    _r_e_l_a_t_i_v_e _m_s_s (12)  : Dfinit le registre _m_s_s (taille de segment TCP
     maximale)  la valeur de l'oprande ajoute  la valeur mss du
     paquet initial (si dfinie).



    _r_e_l_a_t_i_v_e _w_s_c_a_l_e (13)  : Dfinit le registre wscale (mise 
     l'chelle de la fentre)  la valeur de l'oprande ajoute  la
     valeur wscale du paquet initial (si dfinie).



    _r_e_l_a_t_i_v_e _t_i_m_e_s_t_a_m_p (14)  : Dfinit le registre _t_i_m_e_s_t_a_m_p (valeur
     locale du timestamp)  la valeur de l'oprande ajoute  la valeur
     courante utilisable pour le timestamp.






  66..22..55..  RREETT


  CCooddee :: 05

  Termine l'excution du programme en retournant l'oprande.


  Les oprandes accepts sont les suivants :



    _A_c_c_e_p_t (1)  : Termine l'excution et demande l'acceptation du
     paquet pour continuer son traitement.


    _D_r_o_p (2)  : Termine l'excution et demande l'abandon du paquet.


    _R_e_p_l_y (3)  : Termine l'excution et demande l'envoi d'une rponse
     base sur l'tat de la machine virtuelle.




  66..33..  OOppttiioonnss TTCCPP


  Pour les diffrentes instructions acceptant des options TCP, les
  options suivantes sont reconnues :




    _e_o_l (0)

    _n_o_p (1)

    _m_s_s (2)

    _w_s_c_a_l_e (3)

    _s_a_c_k_O_K (4)

    _s_a_c_k (5)

    _e_c_h_o (6)

    _e_c_h_o_r_e_p_l_y (7)

    _t_i_m_e_s_t_a_m_p (8)

    _p_o_c_O_K (9)

    _p_o_c_S_P (10)

    _C_C (11)

    _C_C_._N_E_W (12)

    _C_C_._E_C_H_O (13)

    _a_c_r_e_q (14)

    _a_c_d_a_t_a (15)

  77..  OOuuttiillss ddee ddvveellooppppeemmeenntt



  77..11..  DDeebbooggaaggee


  Afin de pouvoir suivre le fonctionnement du module, un certain nombre
  d'informations de debogage peuvent tre imprimes dans le buffer de
  messages du noyau au fer et  mesure de l'analyse et de la
  modification des paquets. Par dfaut les messages de debogage sont
  dsactivs, mais peuvent tre activs par un sysctl, via le fichier
  _/_p_r_o_c_/_s_y_s_/_n_e_t_/_i_p_v_4_/_i_p___p_e_r_s_o_n_a_l_i_t_y___d_e_b_u_g.






  Le niveau de debogage est rgl par la valeur numrique associe  ce
  paramtre : Chaque bit correspond  un des sous modules ce qui permet
  de slectionner finement les messages  afficher en combinant les bits
  voulus comme ci aprs :





    _1  : Moteur central de la cible

    _2  : Modifications de numros de squence

    _4  : Modifications des options

    _8  : Modifications des fentres

    _1_6  : Leurres TCP locaux

    _3_2  : Machine virtuelle

    _6_4  : Leurres UDP locaux

    _1_2_8  : Modifications des identifiants IP

  Exemple :




         echo 35 > /proc/sys/net/ipv4/ip_personality_debug





  77..22..  OOssddeett


  Osdet est un outil de test tentant de dcouvrir le systme
  d'exploitation utilis. Il a t dvelopp  partir des sources de
  nmap. Il effectue les mmes tests que nmap, mais ce de manire
  squentielle en affichant pour chaque test le paquet envoy et la
  rponse ventuelle reue (code adapt de tcpdump). Ceci permet
  d'analyser finemement le comportement de la pile IP et de constater le
  bon fonctionnement ou non du code noyau produit.

  Exemple d'utilisation :

































































  dse1:~# osdet -h
  usage: osdet [-t n[-N],...] [-p port] [-P port] [-S ip] [-h] host
    -p port    Sets openport (defaults to 23 (telnet)).
    -P port    Sets closedport (defaults to a random high port).
    -S ip      Sets source Ip for scans if multihomed.
    -t ...     Selects a subset of tests to perform.

  dse1:~# osdet -p 23 -P 234 dse2
  OSDET v0.3 [using nmap backend version 2.53]

  Trying to detect remote os of dse2 [172.20.30.2].
  (assuming port 23 is open and port 234 is closed)
  Using pcap filter: (icmp and dst host 172.20.30.1) or
   (tcp and src host 172.20.30.2 and dst host 172.20.30.1)

  * Test 1 (TCP to open port, SYN and BOGUS)
    Sending packet... ok:
      172.20.30.1.50925 > 172.20.30.2.23: S 26F7D60A:26F7D60A(0) win 3072
       <wscale 10,nop,mss 265,timestamp 3F3F3F3F 0,eol> (ttl 54, id 36252)
    Waiting for answer... ok:
      172.20.30.2.23 > 172.20.30.1.50925: S 6ECE0057:6ECE0057(0) ack 26F7D60B
      win 7950 <mss 266> (ttl 255, id 59900)

  * Test 2 (TCP to open port, NULL)
    Sending packet... ok:
      172.20.30.1.50926 > 172.20.30.2.23: . win 3072 <wscale 10,nop,mss
      265, timestamp 3F3F3F3F 0,eol> (ttl 54, id 27188)
    Waiting for answer... no reply.

  * Test 3 (TCP to open port, SYN, FIN, URG and PUSH)
    Sending packet... ok:
      172.20.30.1.50927 > 172.20.30.2.23: SFP 26F7D60A:26F7D60A(0) win
      3072 urg 0 <wscale 10,nop,mss 265,timestamp 3F3F3F3F 0,eol> (ttl 54, id 28956)
    Waiting for answer... ok:
      172.20.30.2.23 > 172.20.30.1.50927: . ack 2 win 7950 (ttl 255, id 60156)

  * Test 4 (TCP to open port, ACK 0)
    Sending packet... ok:
      172.20.30.1.50928 > 172.20.30.2.23: . ack 0 win 3072 <wscale
      10,nop,mss 265,timestamp 3F3F3F3F 0,eol> (ttl 54, id 7360)
    Waiting for answer... ok:
      172.20.30.2.23 > 172.20.30.1.50928: R 0:0(0) win 8192 (ttl 255, id 60412)

  * Test 5 (TCP to closed port, SYN)
    Sending packet... ok:
      172.20.30.1.50929 > 172.20.30.2.234: S 26F7D60A:26F7D60A(0) win
      3072 <wscale 10,nop,mss 265,timestamp 3F3F3F3F 0,eol> (ttl 54, id 49268)
    Waiting for answer... ok:
      172.20.30.2.234 > 172.20.30.1.50929: R 0:0(0) ack 26F7D60B win 0 (ttl 255, id 60668)

  * Test 6 (TCP to closed port, ACK 0)
    Sending packet... ok:
      172.20.30.1.50930 > 172.20.30.2.234: . ack 0 win 3072 <wscale
      10,nop,mss 265,timestamp 3F3F3F3F 0,eol> (ttl 54, id 53356)
    Waiting for answer... ok:
      172.20.30.2.234 > 172.20.30.1.50930: R 0:0(0) win 0 (ttl 255, id 60924)

  * Test 7 (TCP to closed port, FIN, PUSH and URG)
    Sending packet... ok:
      172.20.30.1.50931 > 172.20.30.2.234: FP 26F7D60A:26F7D60A(0) win
      3072 urg 0 <wscale 10,nop,mss 265,timestamp 3F3F3F3F 0,eol> (ttl 54, id 60119)
    Waiting for answer... ok:
      172.20.30.2.234 > 172.20.30.1.50931: R 0:0(0) ack 26F7D60A win 0 (ttl 255, id 61180)

  * Test 8 (UDP to closed port, expecting ICMP unreach)
    Sending packet... ok:
      172.20.30.1.50932 > 172.20.30.2.234: udp 300 (ttl 60, id 36334)
    Waiting for answer... ok:
      172.20.30.2 > 172.20.30.1: icmp: 172.20.30.2 udp port 234 unreachable (ttl 255, id 61436)

  * Test 9 (Initial Sequence Number)
    Sending paquets... 26F7D60B 26F7D60C 26F7D60D 26F7D60E 26F7D60F 26F7D610; last is:
      172.20.30.1.50939 > 172.20.30.2.23: S 26F7D610:26F7D610(0) win 3072 (ttl 54, id 777)
    Waiting for answers... 9D128940[1] 9D138340[2] 9D147D40[3] 9D157740[4] 9D167140[5]
      9D176B40[6]; last is:
      172.20.30.2.23 > 172.20.30.1.50939: S 9D176B40:9D176B40(0) ack
      26F7D611 win 32120 <mss 1460> (DF) (ttl 64, id 0)

  * Nmap OS Fingerprint:
    TSeq(Class=64K)
    T1(Resp=Y%DF=N%W=1F0E%ACK=S++%Flags=AS%Ops=M)
    T2(Resp=N)
    T3(Resp=Y%DF=N%W=1F0E%ACK=O%Flags=A%Ops=)
    T4(Resp=Y%DF=N%W=2000%ACK=O%Flags=R%Ops=)
    T5(Resp=Y%DF=N%W=0%ACK=S++%Flags=AR%Ops=)
    T6(Resp=Y%DF=N%W=0%ACK=O%Flags=R%Ops=)
    T7(Resp=Y%DF=N%W=0%ACK=S%Flags=AR%Ops=)
    PU(Resp=Y%DF=N%TOS=0%IPLEN=38%RIPTL=15C%RID=E%RIPCK=0%UCK=0%ULEN=134%DAT=E)

    TCP Sequence Prediction: Class=64K rule
    Difficulty=1 (Trivial joke)

  * Remote OS Guess: AmigaOS AmiTCP/IP 4.3





  77..33..  PPeerrsscccc


  La bibliothque dynamique qui s'ajoute  iptables ralise l'analyse du
  fichier de configuration et la compilation du code en pseudo-code pour
  la machine virtuelle. Afin d'tre sr que l'interprtation de la
  configuration du code, et que le code gnr tait correct, nous avons
  ralis un interprteur de fichier de configuration et un
  compilateur/dsassembleur de code. Cet outil peut galement tre
  utilis pour simplement vrifier la bonne syntaxe d'un fichier de
  configuration ou tester la longueur d'un code compil.






  Exemple d'utilisation :
















  dse2:~# percc example.conf
  === config ===
  id: Example
  isn initialized: yes, value=877764155
  isn type: true-random
  rewrite way: ingoing outgoing
  keep unknown options: yes
  keep unused options: yes
  max window: 0
  change options for isolated packets: yes
  udp-unreach:
    reply: yes
    df: yes
    max-len: 500
    tos: 0
    ip-len: 0
    ip-id: same
    ip-csum: same
    udp-len: 0
    udp-csum: same
    udp-data: mangle

  === interpreted code #0 ===
  if (flags(syn)) {
    if (option(sackOK)) {
      copy(sackOK);
    } else {
      copy(nop);
      copy(nop);
    }
    copy(timestamp);
    copy(mss);
  } else {
    if (option(sack)) {
      copy(sack);
    } else {
      copy(nop);
      copy(nop);
    }
    copy(timestamp);
  }
  code: 15 instructions.

  === compiled code #0 ===
  0000:  [01100002]  TEST    tcp_flags, syn
  0001:  [0200000B]  JMP     000B
  0002:  [01000004]  TEST    tcp_option, sackOK
  0003:  [02000006]  JMP     0006
  0004:  [03000004]  PUT     sackOK (copy)
  0005:  [02000008]  JMP     0008
  0006:  [03000001]  PUT     nop (copy)
  0007:  [03000001]  PUT     nop (copy)
  0008:  [03000008]  PUT     timestamp (copy)
  0009:  [03000002]  PUT     mss (copy)
  000A:  [02000012]  JMP     0012
  000B:  [01000005]  TEST    tcp_option, sack
  000C:  [0200000F]  JMP     000F
  000D:  [03000005]  PUT     sack (copy)
  000E:  [02000011]  JMP     0011
  000F:  [03000001]  PUT     nop (copy)
  0010:  [03000001]  PUT     nop (copy)
  0011:  [03000008]  PUT     timestamp (copy)
  asm: 18 instructions.

  === interpreted code #1 ===
  if (option(mss)) {
    set(df, 0);
    if (listen) {
      if (flags(syn&ece)) {
        set(win, 7950);
        set(ack, this + 1);
        set(flags, syn|ack);
        insert(mss, this + 1);
        reply;
      }
      if (flags(null)) {
        drop;
      }
      if (flags(fin&syn&urg&push)) {
        set(win, 7950);
        set(ack, 2);
        set(flags, ack);
        reply;
      }
      if ((ack(0) && flags(ack)) && !flags(syn|urg|push|rst)) {
        set(win, 8192);
        set(ack, 2);
        set(flags, rst);
        reply;
      }
    } else {
      set(win, 0);
      if (flags(syn) && !flags(ack)) {
        set(ack, this + 1);
        set(flags, ack|rst);
        reply;
      }
      if ((ack(0) && flags(ack)) && !flags(syn|urg|push|rst)) {
        set(ack, 2);
        set(flags, rst);
        reply;
      }
      if (flags(fin&urg&push)) {
        set(ack, this + 0);
        set(flags, ack|rst);
        reply;
      }
    }
  }
  code: 53 instructions.

  === compiled code #1 ===
  0000:  [01000002]  TEST    tcp_option, mss
  0001:  [0200003A]  JMP     003A
  0002:  [04200000]  SET     df, 0
  0003:  [01400000]  TEST    listen
  0004:  [02000022]  JMP     0022
  0005:  [01200042]  TEST    tcp_flags, syn&ece
  0006:  [0200000D]  JMP     000D
  0007:  [04301F0E]  SET     win, 7950
  0008:  [04900001]  SET     ack, this + 1
  0009:  [04000012]  SET     flags, syn|ack
  000A:  [04C00001]  SET     mss, this + 1
  000B:  [03100002]  PUT     mss (insert)
  000C:  [05000003]  RET     reply
  000D:  [01100000]  TEST    tcp_flags, null
  000E:  [02000010]  JMP     0010
  000F:  [05000002]  RET     drop
  0010:  [0120002B]  TEST    tcp_flags, fin&syn&urg&push
  0011:  [02000016]  JMP     0016
  0012:  [04301F0E]  SET     win, 7950
  0013:  [04100002]  SET     ack, 2
  0014:  [04000010]  SET     flags, ack
  0015:  [05000003]  RET     reply
  0016:  [01300000]  TEST    ack, 0
  0017:  [0200003A]  JMP     003A
  0018:  [01100010]  TEST    tcp_flags, ack
  0019:  [0200003A]  JMP     003A
  001A:  [0110002E]  TEST    tcp_flags, syn|urg|push|rst
  001B:  [0200001D]  JMP     001D
  001C:  [0200003A]  JMP     003A
  001D:  [04302000]  SET     win, 8192
  001E:  [04100002]  SET     ack, 2
  001F:  [04000004]  SET     flags, rst
  0020:  [05000003]  RET     reply
  0021:  [0200003A]  JMP     003A
  0022:  [04300000]  SET     win, 0
  0023:  [01100002]  TEST    tcp_flags, syn
  0024:  [0200002B]  JMP     002B
  0025:  [01100010]  TEST    tcp_flags, ack
  0026:  [02000028]  JMP     0028
  0027:  [0200002B]  JMP     002B
  0028:  [04900001]  SET     ack, this + 1
  0029:  [04000014]  SET     flags, ack|rst
  002A:  [05000003]  RET     reply
  002B:  [01300000]  TEST    ack, 0
  002C:  [02000035]  JMP     0035
  002D:  [01100010]  TEST    tcp_flags, ack
  002E:  [02000035]  JMP     0035
  002F:  [0110002E]  TEST    tcp_flags, syn|urg|push|rst
  0030:  [02000032]  JMP     0032
  0031:  [02000035]  JMP     0035
  0032:  [04100002]  SET     ack, 2
  0033:  [04000004]  SET     flags, rst
  0034:  [05000003]  RET     reply
  0035:  [01200029]  TEST    tcp_flags, fin&urg&push
  0036:  [0200003A]  JMP     003A
  0037:  [04900000]  SET     ack, this + 0
  0038:  [04000014]  SET     flags, ack|rst
  0039:  [05000003]  RET     reply
  asm: 58 instructions.





  88..  BBiibblliiooggrraapphhiiee



    J. Postel. _I_n_t_e_r_n_e_t _P_r_o_t_o_c_o_l, Request for Comments 791. Network
     Working Group, 09/1981.

    J. Postel. _I_n_t_e_r_n_e_t _C_o_n_t_r_o_l _M_e_s_s_a_g_e _P_r_o_t_o_c_o_l, Request for Comments
     792. Network Working Group, 09/1981.

    J. Postel. _T_r_a_n_s_m_i_s_s_i_o_n _C_o_n_t_r_o_l _P_r_o_t_o_c_o_l, Request for Comments 793.
     Network Working Group, 09/1981.

    V. Jacobson, R. Braden. _T_C_P _E_x_t_e_n_s_i_o_n_s _f_o_r _L_o_n_g_-_D_e_l_a_y _P_a_t_h_s,
     Request for Comments 1072. Network Working Group, 10/1988.

    J. Zweig, C. Partridge. _T_C_P _A_l_t_e_r_n_a_t_e _C_h_e_c_k_s_u_m _O_p_t_i_o_n_s, Request for
     Comments 1146. Network Working Group, 04/1990.

    V. Jacobson, R. Braden, D. Borman. _T_C_P _E_x_t_e_n_s_i_o_n_s _f_o_r _H_i_g_h
     _P_e_r_f_o_r_m_a_n_c_e, Request for Comments 1323. Network Working Group,
     05/1992.
    T. Connolly, P. Amer, P. Conrad. _A_n _E_x_t_e_n_s_i_o_n _t_o _T_C_P _: _P_a_r_t_i_a_l
     _O_r_d_e_r _S_e_r_v_i_c_e, Request for Comments 1693. Network Working Group,
     11/1994.

    "Fyodor". _R_e_m_o_t_e _O_S _d_e_t_e_c_t_i_o_n _v_i_a _T_C_P_/_I_P _S_t_a_c_k _F_i_n_g_e_r_P_r_i_n_t_i_n_g,
     Phrack Magazine Volume 8, Issue 54, 12/1998.

    R. Russel. _L_i_n_u_x _n_e_t_f_i_l_t_e_r _H_a_c_k_i_n_g _H_O_W_T_O, Linux Documentation
     Project, 05/2000.

























































