• System V d'Unix System Laboratory (USL) racheté par Novell puis abandonné avec UnixWare.
• BSD ou Berkeley Software Distribution version 4.4

• "guided media" où le signal est confiné à un espace défini : paire torsadée, câble coaxial, fibre optique
• "unguided media" où l’on utilise l’environnement existant pour diffuser de l’information par micro-ondes, rayons infrarouges, lumières, faisceau lumineux etc.

• la couverture géographique
• le taux de transfert
• le taux d'erreur

Nous verrons que la série de protocoles TCP/IP n’adhère pas totalement au modèle OSI et qu’il est même préférable de recourir à un modèle spécifique comme celui-ci :

TCP/IP est plus un modèle à cinq couches qu’un modèle à sept couches comme le modèle OSI. Les couches 1 et 2, caractérisées par des unités d’information de bits et de frames ne sont pas définies par des RFC puisque l’essence même du TCP/IP est d’être indépendant des couches hardware. La couche 3 est la couche de l’Internet Protocol et de ses datagrammes. L’Internet Control Message Protocol est un service normalement fourni au niveau de cette couche. La couche 3 a besoin des protocoles ARP (Address Resolution Protocol ) et RARP (Reverse Address Resolution Protocol ) pour associer adresses IP et adresses de la couche MAC. La couche 4 permet de recourir au choix au protocole TCP (Transmission Control Protocol) ou au protocole UDP (User Datagram Protocol). Enfin, la cinquième couche fournit différents services pour tout type d’applications désireuses de faire appel à des fonctions réseau. Ce serait par exemple le cas d’applications comme Telnet, FTP, du courrier électronique, un navigateur World Wide Web etc.

Il n’y a donc pas d’adéquation parfaite entre les modèles TCP/IP et OSI comme le montre la figure suivante :

TCP est avec UDP, l’un des deux protocoles relatifs à la couche de transport

TCP c’est le Transmission Control Protocol, le protocole chargé de l’intégrité de vos données. Il découpe votre information par paquets puis numérote ces paquets, en calcule un checksum, et les place dans une enveloppe TCP. L’enveloppe TCP est ensuite placée dans une enveloppe IP (Internet Protocol) où sont mentionnées les adresses de l’émetteur et du destinataire. Le bloc de données que TCP passe à IP consiste en une en-tête TCP et les données en provenance de la couche application. Ce bloc est appelé ‘segment’.

TCP se veut un protocole orienté-connexion, fiable incluant détection et correction d’erreur là où UDP se veut un protocole connectionless, sans surcharge. Il se charge d’établir un handshake entre deux hôtes. TCP est également chargé d’adresser un datagramme à la bonne application via un nombre de 16 bits appelé le port.

La fiabilité de la transmission est assurée par un mécanisme baptisé Positive Acknowledgement with Re-transmission (PAR). PAR envoie données sur données jusqu’à ce qu’il soit averti de la bonne arrivée des données.

Le handshake se fait en trois phases.

Une machine A initialise la connexion en envoyant un segment incluant un SYN ou Synchronize sequence numbers. La machine B lui répond par un segment où les drapeaux SYN et ACK (Acknowledgement) sont dressés. La machine A envoie alors les données en même temps que le flag ACK. Une même procédure en trois phases clôture une connexion via le flag FIN ou "No more data from sender".

Les différents champs de l’en-tête sont :

UDP donne à une application l’accès direct à un service de livraison de datagrammes. UDP fournit un service connectionless régulièrement utilisé pour des communications "one to many", comme les datagrammes broadcast ou multicast. Comme la livraison des datagrammes UDP n’est pas garantie, les applications recourant à l’UDP doivent gérer elles-mêmes les problèmes de fiabilité du transport.

UDP est par exemple utilisé pour la résolution d’adresses IP/DNS via le port 53

Penchons nous dans le TCP/IP, sur la partie IP, pour Internet Protocol, le protocole que doit respecter chaque machine pour être identifiée sur un réseau local TCP/IP ou sur Internet.

IP est un protocole connectionless. Cela signifie qu’il n’échange pas de contrôle d’information, de handshake avant d’établir une connexion point à point par opposition aux protocoles connection-oriented qui vérifient que le système distant est prêt à recevoir des données. IP ne contient aucune détection d’erreur et aucun mode de récupération de données.

Les protocoles TCP/IP ont été pensé pour transporter des données sur le réseau Arpanet architecturé comme réseau à commutation de paquets (packet switching network). Par paquet, nous entendons un bloc de données contenant des informations capables de le véhiculer à bon port. L’analogie la plus évidente est la lettre dont l’adresse est contenue sur l’enveloppe.

Le format de paquet adopté par IP est le datagramme. Un datagramme contient une en-tête de cinq ou six "words" stockant notamment l’adresse de destination d’un paquet. La taille par défaut de l’en-tête est de cinq words, le sixième étant optionnel.

• Le checksum ou champ de contrôle de l’en-tête ( 16 bits) contient le " complément à un " du total " en complément à un " de tous les mots de 16 bits de l’en-tête.
• L’adresse IP source est codée sur 32 bits
• L’adresse IP de destination est également codée sur 32 bits
• A la rubrique " Options ", sont stockées des demandes spéciales pour requérir un routage particulier pour certains paquets.
• Le champ " padding " est habituellement bourré de 0 de manière à aligner le début des données sur un multiple de 32 bits.

IP délivre un datagramme en vérifiant l’adresse de destination du word 5 du header. Si l’adresse de destination fait partie du réseau local, le paquet est remis directement sinon le paquet est transmis à un gateway. La décision d’emprunter tel ou tel gateway est appelée routage. On parle souvent abusivement de routeurs IP pour des gateways Internet parce qu’ils utilisent le protocole IP pour router des paquets entre réseaux. Dans l’acception TCP/IP, il n’y a que deux types de périphériques réseau : les hosts et les gateways. Les gateways transmettent des paquets entre réseaux, les hosts pas.

Rien ne garantit qu’un paquet a bien été envoyé à partir de l’adresse source indiquée. Il faut passer par des couches OSI supérieures pour l’authentification de l’adresse source.

Lors de son routage d’un réseau physique à l’autre, un datagramme peut être fragmenté par un gateway en pièces plus petites. Chaque type de réseau a son propre MTU (Maximum Transmission Unit) qui définit la taille du plus large paquet qu’il peut transférer. Chaque fragment hérite du même format que le datagramme original.

Les fragments sont définis dans le word 2 de l’en-tête du datagramme. Identification permet de repérer à quel datagramme appartient un fragment, Fragmentation Offset détermine sa position dans le datagramme et Flags dispose d’un bit More Fragments qui permet de vérifier si le réassemblage est terminé ou non.

Cette taille variable des paquets est fonction du débit du réseau. Si le réseau est lent, des paquets trop longs génèrent des temps d’attente élevés. Voici à titre indicatif quelques valeurs MTU de différents supports :

réseau Ethernet de 10 Mbps 1536

FDDI 4096

IEE 802.3 1492

X.25 < 128

Token Ring 4000

L’Internet Control Message Protocol utilise les datagrammes IP pour transporter ses messages. C’est par son biais que sont réalisés

ICMP fournit d’intéressantes données pour le diagnostic d’opérations du réseau. ICMP utilise des datagrammes IP pour véhiculer des messages aller-retour entre noeuds concernés. Un message d’erreur ICMP est généré par une machine hôte réalisant qu’il y a un problème de transmission et renvoyé à l’adresse de départ du datagramme ayant provoqué le problème.

Une en-tête ICMP est codée sur 32 bits, 8 pour le type, 8 pour le code dont la signification dépend du type et 16 pour le contrôle/checksum.

0 Réponse d’écho

8 Echo request

9 Annonce de routeur

10 Sollicitation de routeur

11 TTL expiré

12 Problème de paramètre

13 Requête Horodatage

14 Réponse d’horodatage

15 Demande d’information

16 Réponse d’information

17 Requête de masque d’adresse

18 Réponse de masque d’adresse

Les messages ICMP les plus courants sont le couple de type 0 et 8 générés par le programme de test " ping ". Ping envoie un datagramme de type 8 (echo request) à un noeud dont il attend en retour un message de type 0 (echo reply) renvoyant les données incluses dans la requête.

Quand le " type " est par exemple 3 pour destination inaccessible, le " code " précise si c’est le réseau, l’hôte, le protocole ou le port qui sont inaccessibles.

0 Network unreachable

Un datagramme Source Quench est identique à celui du type Destination Unreachable. Il sert à contrôler un flux d’informations. Si un routeur détecte que son réseau ou son processeur ne peut suivre le débit d’une machine hôte émettrice, il envoie à celle ci un message ICMP incluant la cause du dépassement de capacité.

0 Redirect datagram to go to that network

Le datagramme Route change request est utilisé par les routeurs qui connaissent une meilleure route pour atteindre une destination particulière.

Le Router discovery protocol permet à un système d’être averti dynamiquement de la présence de tous les routeurs disponibles immédiatement sur un réseau LAN. Les messages de type 9, router advertisement, permettent à des routeurs de s’annoncer sur un réseau à intervalles de 7 à 10 minutes suite à un message de type 10, router sollicitation, émis par une machine hôte.

Le message Time exceeded for datagram utilise un datagramme identique à celui du type Destination Unreachable. Un routeur l’utilise pour signaler à la machine source que la valeur TTL (Time To Live) d’une en-tête IP a été décrémentée jusqu’à la valeur d’expiration 0, ce qui revient à dire que le paquet a été écarté probablement à cause d’une boucle infinie dans le routage.

Le message ICMP Parameter Problem indique qu’un argument invalide a été utilisé dans le champ Options d’une en-tête IP.

Le type ICMP 13 pour Time Stamp Request et 14 pour Time Stamp Reply sont utilisés pour interroger l’horloge d’un système distant afin de s’y synchroniser ou récolter des informations statistiques.

Les messages Information Request est envoyé pour obtenir l’adresse réseau d’une machine hôte donnée. C’est la méthode utilisée par le protocole SLIP (Serial Line IP) pour allouer une adresse IP à la machine appelante.

Les messages Address Mask Request sont utilisés parallèlement à l’adressage en sous réseau pour découvrir le masque de sous-réseau d’une machine hôte.

Chaque interface Internet est identifiable par une adresse Internet codée sur 32 bits. Une adresse Internet Protocol est constituée de quatre nombres de 0 à 255 et séparés par un point comme ceci : 194.78.19.132. Cela donne également 32 bits ou quatre octets qu’on représente quelquefois de manière hexadécimale comme suit 0x9A0B3CFF. Chaque machine reliée à Internet dispose d’une telle adresse unique. Dans cette adresse Internet, il faut encore distinguer deux parties, l’identifiant de réseau et le numéro d’hôte. Une adresse IP est composée de deux parties :

L’adresse IP doit être unique pour l’ensemble du réseau. Un ordinateur avec plus d’une connexion réseau doit disposer d’une adresse IP pour chacune de ces connexions. Une adresse IP ne donne aucune indication sur la position géographique des périphériques connectés. Il n’y a pas de découpage géographique comme dans la numérotation téléphonique ni de découpage hiérarchique comme dans la norme CCITT X.121.

Si vous réclamez auprès d’une autorité nationale plusieurs adresses Internet, il vous sera demandé de quelle classe de réseau vous avez besoin. Les adresses les plus courantes sont divisées en classes de type A, B ou C. Un réseau de Classe A est identifié par le premier des quatre octets d’une adresse IP. Cela signifie qu’il reste trois octets ou 24 bits pour recenser toutes les adresses possibles sur ce réseau. Cela nous donne 256 fois 256 fois 256 soit 16.777.216 adresses réseau dont 16.777.214 sont disponibles puisque les adresses X.0.0.0 et X.255.255.255 sont réservées pour désigner respectivement un hôte inconnu du réseau X et tous les hôtes du réseau X. Vous vous douterez aisément qu’un réseau de classe A n’est vraiment nécessaire que pour quelques grosses multinationales ou institutions réclamant plus de 16 millions d’adresses. Viennent ensuite les réseaux de classe B utilisant deux octets pour la codification du réseau et deux autres pour la partie hôte. On obtient alors 256 fois 256 = 65536 - 2 = 65534 adresses disponibles. Enfin les réseaux de classes C n’utilisent qu’un seul octet pour la partie hôte et peuvent donc accueillir 256 - 2 = 254 adresses au sein du réseau.

Aux réseaux de classe A, on a réservé les adresses 1 à 126 (1^er bit à zéro), aux classes B les adresses 128 à 191 (2 premiers bits = 1 0) et aux classes C, les adresses 192 à 255 (trois premiers bits 1 1 0)

Les adresses 127.0.0.x sont un peu particulières puisqu’elles sont utilisées pour des loopback ou bouclage local. L’adresse de classe A 127 est utilisée pour tester localement le fonctionnement du protocole IP, pour une pseudo adresse IP quand une machine ne contient pas de carte réseau ou lorsque des paquets ne doivent pas quitter une machine hôte.

Les adresses au delà de 223 sont réservées pour d’autres extensions comme les adresses de classe D destinées à des réseaux multipoints ou de classe E pour réseaux expérimentaux. La classe D n’utilise pas des liaisons point-à-point mais multipoints. Elle est réservée à l’utilisation du Backbone Multipoint expérimental baptisé MBONE. Une autre application de la classe D est l’utilisation par des routeurs pour le monitoring des protocoles de routage.

Donc, les adresses normales de " host " Internet ne peuvent pas contenir de 0 (défaut ou inconnu) ou de 255 (broadcast). Les adresses ne peuvent jamais commencer par 0,127, ou > 223. Les personnes qui ne respectent pas ces règles sont appelées en jargon réseau des " martiens ".

Une adresse IP avec tous les bits host à zéro identifie le réseau lui-même. L’adresse 193.75.199.0 renvoie à toute l’adresse de classe C du réseau 193.75.199. Ces adresses contenant des zéros sont utilisées dans les tables de routage pour désigner des réseaux entiers. Des adresses avec des zéros peuvent être utilisées comme adresses source, jamais comme adresses de destinations.

Une adresse IP avec tous les bits host à un est une adresse broadcast ou à diffusion dirigée. Un datagramme envoyé à cette adresse est réexpédié à tous les membres de ce réseau. L’adresse broadcast du réseau 26 est 26.255.255.255. Une adresse broadcast est toujours une adresse de destination, jamais une adresse source.

Voici comment traduire en français toutes ces adresses un peu particulières :

0.0.0.0 Un hôte inconnu (source)

255.255.255.255 Tous les hôtes (destination)

193.75.199.3 Hôte 3 du réseau 193.75.199

193.75.199.0 Un hôte inconnu du réseau 193.75.199

193.75.199.255 Tous les hôtes du réseau 193.75.199

0.0.0.4 L’hôte 3 de ce réseau (source)

127.0.0.1 Cet hôte (local host)

Lorsque vous faîtes vos premiers essais, ne choisissez pas d’adresse au hasard car cela pourrait provoquer des catastrophes (imaginez par exemple que vous utilisiez une adresse de la CIA :-) ). Utilisez plutôt des adresses IP réservées à cette fin et qui ont la particularité de ne pas être routées si elles parviennent par erreur à une autre machine

10.0.0.0 à 10.255.255.255 soit 1 adresse de classe A

172. 16.0.0 à 172. 31.255.255 soit 255 adresses de classe B

192.168.0.0 à 192.168.255.255 soit 65536 adresses de classe C

L’Internet Assigned Numbers Authority (IANA) a réservé ces adresses pour les réseaux privés dans la recommandation RFC 1597. L’Internet Assigned Number Authority (IANA) est responsable de l’allocation des adresses IP (et de tous les identifiants uniques) dans l’Internet. Cet organisme a délégué cette responsabilité à des organismes régionaux comme NIC (Network Information Center) aux USA, RIPE ( Réseau IP Européen) NCC en Europe, et APNIC ( Asia Pacific Network Information Center) en Asie. Ces organismes délèguent à nouveau à d’autres organismes : les " local registries ".

Un " local registry " a la charge de recevoir les demandes d’adresses IP, de traiter ces demandes en allouant des réseaux et de mettre à jour les bases de données correspondantes.

Le fournisseur de service peut vous imposer de rendre les adresses IP qu’il vous a assigné en cas de rupture de contrat, tout en vous laissant la plupart du temps un délai pour cesser d’utiliser les adresses IP allouées par lui. Ces dispositions doivent apparaître dans votre contrat avec lui. Dans le cas contraire (cas général aujourd’hui), les adresses IP allouées restent votre propriété même si vous changez de prestataire.

Si vous changez de fournisseur de service, le nouveau fournisseur peut vous demander de renuméroter vos machines en utilisant des adresses IP allouées par lui, ou vous faire payer un supplément pour connecter des réseaux dont les numéros ne sont pas dans les plages qui lui sont attribuées (c’est aussi le cas si vos adresses officielles ont été obtenues auprès d’un last resort registry) .

Tout cela est une conséquence des méthodes de routages de l’Internet, et en particulier de Classless InterDomain Routing (CIDR).

Une organisation n’obtiendra une adresse de classe B que si elle fournit la preuve qu’elle doit connecter au moins 32 sous-réseaux et 4096 hôtes.

Rassurez-vous, la plupart du temps, ce sera votre fournisseur d’accès Internet qui vous communiquera votre adresse de classe X. Si vous utilisez Internet via des accès modems de type SLIP ( Serial Line Internet Protocol ) ou PPP ( Point to Point Protocol ), l’allocation de l’adresse IP sera dynamique c’est-à-dire qu’elle sera définie au moment de la connexion au serveur. Dans ce cas, il vous suffira de mentionner l’adresse 0.0.0.0 comme adresse IP provisoire dans le panneau de configuration. Sous Windows 95 par exemple, vous devrez donc simplement spécifier dans le panneau de configuration réseau si l’obtention de l’adresse IP est automatique ou s’il est nécessaire de recourir à une adresse fixe.

Il est impossible à des périphériques disposant de numéros de réseaux différents de communiquer directement : ils doivent passer par les services d’un routeur. C’est ainsi que des stations de travail séparés uniquement par un bridge ou un répéteur auront la même classe d’adresses tandis que des stations de travail séparés par un routeur auront des numéros réseau différents.

Le programme le plus populaire pour tester une configuration TCP/IP est PING, Packet INternet Groper, qui envoie une demande d’écho ICMP à une autre station et attend une réponse. Cela permet de tester l’accessibilité d’une machine distante. Ce petit programme est indispensable pour diagnostiquer si votre connexion est opérationnelle. Accessoirement, Ping vous informe aussi du nombre de millisecondes qu’il a fallu à ce paquet pour atteindre l’appareil distant.

Reply from 192.92.130.1: bytes=32 time=761ms TTL=250

Reply from 192.92.130.1: bytes=32 time=658ms TTL=250

Les paquets Ping ont la même en-tête que les paquets ICMP : 8 bits de type, 8 bits de code, 16 de checksum suivis de 16 bits pour l’identifiant et 16 pour le numéro de séquence.

Network Address Netmask Gateway Address Interface Metric

0.0.0.0 0.0.0.0 199.199.40.1 199.199.40.123 1

127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1

199.199.40.0 255.255.255.0 199.199.40.123 199.199.40.123 1

199.199.40.123 255.255.255.255 127.0.0.1 127.0.0. 1

199.199.40.255 255.255.255.255 199.199.40.123 199.199.40.123 1

224.0.0. 224.0.0.0 199.199.40.123 199.199.40.123 1

255.255.255.255 199.199.40.123 199.199.40.123 1

La table de routage ci-dessus est relative à l’adresse de classe C 199.199.40.123. Elle contient 7 entrées signifiant ceci :

Imaginons qu’un paquet soit envoyé à l’adresse 199.199.40.122, la table est d’abord balayée pour retrouver l’adresse hôte (il n’y en a pas dans ce cas-ci) puis une route pour le sous-réseau ( il n’y en a pas non plus ici) puis une route réseau. Le paquet ici est donc envoyé vers l’interface locale 199.199.40.123. Si un autre paquet est envoyé vers une adresse 193.75.186.23 par exemple, le même ordre de recherche est utilisé. Une route hôte, sous-réseau ou réseau ne pouvant être trouvée, le paquet est expédié vers l’adresse gateway en insérant l’adresse MAC du gateway dans l’adresse de destination du datagramme.

La table de routage est maintenue automatiquement mais on peut également utiliser la commande route pour la modifier manuellement.

NSLookup est un progrmme qui permet à l’utilisateur d’examiner les informations contenues dans un Domain Name Server. Il essaie de réconcilier adresse IP et nom de domaine. Le serveur répond à une requête d’un client en affichant le nom du serveur de nom de domaine configuré par défaut puis une invite de commande.

"nslookup

nslookup version 95.02.28. Copyright 1995 John A. Junod

Server: 192.153.156.22

>

193.75.199.2

>193.75.199.3

3.199.75.193.in-addr.arpa.

host = linux.netline.be.

Par défaut, les requêtes NSLookup portent sur les champs DNS appelés " A Records " qui établissent une correspondance entre noms de domaine et adresses IP. D’autres types d’interrogations peuvent être émises sur d’autres champs DNS en utilisant la commande set type = <query> où <query> a une des valeurs suivantes :

En interrogeant le MX ou Mail Exchanger, on obtient des informations sur la machine gérant le courrier électronique d’un réseau.

10, linux.netline.be.

Tracert ou Traceroute est un utilitaire pour analyser la route empruntée par un paquet pour atteindre sa destination finale. Tracert fonctionne en envoyant des requêtes d’écho ICMP vers une adresse IP en incrémentant le champ TTL (Time To Live) de l’en-tête IP d’unité en unité et en examinant les messages d’erreur ICMP renvoyés par les machines sur le chemin.

Traceroute émet des paquets IP normaux vers un port UDP non utilisé du système distant. Trois datagrammes sont émis avec une valeur de TTL à 1. Cette valeur TTL à 1 provoque un " timeout " dès que le paquet atteint le premier routeur du chemin qui va émettre un message ICMP TEM " Time Exceeded Message ". Trois datagrammes UP sont ensuite envoyés avec un TTL de 2. Le TTL est incrémenté jusqu’à ce que soit atteinte la destination finale. Puisque les datagrmmes sont adressés à un port invalide de la destination finale, le message ICMP "  Destination Unreachable " est généré et signale au programme Traceroute que son but est atteint.

traceroute to liege.rtfm.be (194.78.19.132), 30 hops max, 40 byte packets

1 ng-gate2 (193.74.190.62) 2 ms 2 ms 2 ms

2 ng-gate-lay.riv.be (193.74.190.162) 4 ms 4 ms 4 ms

3 cisco-tr.riv.be (193.74.190.130) 9 ms 20 ms 10 ms

La commande Netstat affiche des statistiques relatives à la connexion courante. Elle affiche des statistiques sur chaque protocole et chaque connexion TCP/IP. Netstat varie d’un système d’exploitation à l’autre mais généralement Netstat -a renseigne sur toutes les connexions en cours, netstat -r affiche la table de routage, le switch -n spécifiant qu’il n’est pas nécessaire de convertir adresses IP et numéro de port en noms plus parlants.

C:\>netstat -e

Received Sent

Bytes 3995837940 47224622

Unicast packets 120099 131015

Non-unicast packets 7579544 3823

Discards 0 0

Errors 0 0

Unknown protocols 363054211

C:\>netstat -a

Proto Local Address Foreign Address State

TCP davemac1:1572 10.57.13.152:nbsession ESTABLISHED

TCP davemac1:1589 10.57.9.147:nbsession ESTABLISHED

TCP davemac1:1606 11.1.105.245:nbsession ESTABLISHED

TCP davemac1:1632 10.57.9.213:nbsession ESTABLISHED

TCP davemac1:1659 10.55.86.169:nbsession ESTABLISHED

TCP davemac1:1714 10.55.80.203:nbsession ESTABLISHED

TCP davemac1:1719 10.54.67.36:nbsession ESTABLISHED

TCP davemac1:1241 10.57.9.101:nbsession ESTABLISHED

UDP davemac1:1025 :

UDP davemac1:snmp :

UDP davemac1:nbname :

C:\>netstat -s

Packets Received = 5378528

Received Header Errors = 738854

Received Address Errors = 23150

Datagrams Forwarded = 0

Unknown Protocols Received = 0

Received Packets Discarded = 0

Received Packets Delivered = 4616524

Output Requests = 132702

Routing Discards = 157

Discarded Output Packets = 0

Output Packet No Route = 0

Reassembly Required = 0

Reassembly Successful = 0

Reassembly Failures = 0

Datagrams Failing Fragmentation = 0

Fragments Created = 0

Received Sent

Messages 693 4

Errors 0 0

Destination Unreachable 685 0

Time Exceeded 0 0

Parameter Problems 0 0

Source Quenchs 0 0

Redirects 0 0

Echos 4 0

Echo Replies 0 4

Timestamps 0 0

Timestamp Replies 0 0

Address Masks 0 0

Address Mask Replies 0 0

Active Opens = 597

Passive Opens = 135

Failed Connection Attempts = 107

Reset Connections = 91

Current Connections = 8

Segments Received = 106770

Segments Sent = 118431

Segments Retransmitted = 461

Datagrams Received = 4157136

No Ports = 351928

Receive Errors = 2

Datagrams Sent = 13809

Sous Linux, netstat -r vous indiquera la table de routage du kernel comme la commande route

C:\>netstat -r

Destination Gateway Genmask Flags Metric Ref Use Iface

127.0.0.1 * 255.255.255.255 UH 1 0 50 lo

193.75.199.0 * 255.255.255.0 U 1 0 478 eth0

Pour chaque ligne de réponse de netstat -r,

Tcpdump vous permet de mesurer l’activité du réseau en interceptant tous les datagrammes transitant par une machine pour en examiner l’en-tête.

La première colonne renvoyée par tcpdump est l’heure d’interception du paquet, la suite est dépendante du type de datagramme.

Icmpinfo travaille à la manière de tcpdump en interceptant tous les datagrammes ICMP émis sur une portion de réseau.

Les commandes r - pour Remote - sont des commandes du monde Unix pour l’établissement de connexion entre machines de même type. Ces commandes partent du principe que les utilisateurs qui y ont accès ont déjà passé une autre épreuve d’authentification. Elles ne sont donc pas des plus sûres. On dénombre :

Pour pouvoir exécuter une commande r sur une machine hôte, il faut simplement disposer d’une adresse IP et d’un nom repris dans un des deux fichiers de la machine hôte .rhosts ou rhosts.equiv

va essayer de connecter l’utilisateur usereric à la machine machinex. Le fichier hosts.equiv de machinex ressemble à ceci :

La première ligne permet à Eric de se logger à partir de la machine linux.netline.be tandis que la seconde autorise lucien à accéder au compte d’Eric à partir de la machine mail.netline.be.

Ces commandes r font appel à un mécanisme pour applications client-serveur baptisé RPC ou Remote Procedure Call. RPC a été développé par Sun Microsystems et est à la base de l’architecture des produits NFS ( Network File System ) et NIS ( Network Information System ). RPC est devenu une voie royale pour accéder à la programmation distribuée.

Un serveur RPC est une collection de procédures que peuvent appeler des machines clients par une requête RPC. De façon à être le plus indépendant possible d’une machine spécifique, la réponse du serveur est traduite dans un format baptisé XDR pour eXternal Data Representation Format Le serveur RPC se configure à travers un fichier /etc/rpc qui contient une liste de programmes uniquement identifiable par un numéro de service.

#

# /etc/rpc

#

portmapper 100000 portmap sunrpc

rstatd 100001 rstat rstat-svc rup perfmeter

ruserd 100002 rusers

nfs 100003 nfsprog

ypserv 100004 ypprog

mountd 100005 mount showmount

ypbind 100007

walld 100008 rwall shutdown

yppasswdd 100009 yppasswdd

sprayd 100012

rexd 100017

lockd 100021

bootparam 100026

ypupdated 100028 ypupdate

Le mot NFS désigne une famille complète de produits bien que leur concepteur, Sun Microsystems Inc préfère l’appeler Open Network Computing ou ONC. Les spécifications de la plupart des composants NFS sont passés dans le domaine public sous forme de RFC. Sun a également développé un autre ensemble logiciel, PC-NFS, permettant à des PC d’utiliser NFS.

NFS est constitué de trois couches :

On retrouve donc trois nouvelles couches au dessus des couches TCP/IP ce qui donne sept couches comme dans le modèle OSI.

NFS est basé sur le protocole de transport UDP. Client et serveur s’échangent donc des transactions sans conserver une connexion continue. L’utilisation de NFS est plus adaptée sur les petits réseaux LAN

NFS ou Network File System est le plus populaire des programmes recourant à RPC. Il permet d’accéder à des fichiers distants de la même manière que s’il s’agissait de fichiers locaux.

NFS travaille avec des datagrammes UDP de 8192 octets et le port 2049

Traditionnellement, un client introduit une requête pour " monter " un répertoire d’une machine distante sur un répertoire local comme il le ferait pour un disque dur local. avec une commande de type

mount -t nfs linux:/home /users

pour monter le répertoire /home de la machine linux sur le répertoire local /users. Le programme mount essaie alors de se connecter au démon mountd sur la machine linux via RPC. Les fonctions client et serveurs NFS sont implémentés en standard dans la plupart des kernels Unix : nfsd ou NFS Daemon côté serveur, biod ou Block I/O Daemon côté client.

Chaque programme du serveur a besoin de son propre port UDP. Plutôt que de réserver un nombre important de ports pour chaque type d’applications, Open Network Computing utilise un process particulier appelé portmapper près duquel doivent s’enregistrer les processus RPC au démarrage. Quand un programme veut accéder à une procédure RPC d’une machine distante, il doit faire appel au portmapper de cette machine. Portmapper utilise le port 111. En utilisant les procédures d’appel au portmapper, une application peut retrouver le port sur lequel un programme particulier s’est enregistré et communiquer directement avec ce programme.

Avec showmount, on peut facilement trouver une cible facile. Exemple d’un utilisateur qui a oublié que son disque était exporté par NFS:

/cdrom (everyone)

/ (everyone)

Depuis la version de SUN Os 3.0, NFS est doté de mécanismes de file locking pour empêcher plus d’un utilisateur d’écrire sur un fichier au même moment et de record locking pour la mise à jour de fichiers enregistrement par enregistrement. Lock Daemon ou lockd est le programme RPC qui gère le " locking " des fichiers et des enregistrements.

Nfsping est une version remodelée de ping. Il s’agit d’un programme client RPC qui tente d’obtenir une réponse d’un serveur NFS en envoyant une requête RPC avec la procédure 0 ‘null routine’

Rpcinfo affiche le numéro de programme et les versions de chaque programme RPC tournant sur une machine hôte

[program, version, protocol, port ] :

100003, 2, 17, 2049

100004, 2, 17, 1027

100004 2, 6, 1029

100004, 1, 17, 1027

100004, 1, 6, 1029

100012, 1, 17, 1050

100005, 1, 17, 1051

Les services RPC sur la machine linux sont dans l’exemple ci-dessus:

Nfsstat est la version NFS de netstat.

Il renvoie une série d’informations sur les appels aux RPC :

Ensuite sont détaillés l’ensemble des appels RPC procédure par procédure.

Spray Daemon envoie des requêtes RPC sans attendre de réponses de manière à générer un trafic important pour vérifier si un serveur est capable de fournir le débit qu’un client est en droit d’attendre.

NIS est le Network Information System développé par Sun. Il s’agit d’une sorte de bases de donnée servant à distribuer sur un réseau l’information contenue dans des fichiers comme passwd ou groups. NIS peut également être utilisé pour répandre sur le réseau les informations de /etc/hosts. Originellement, NIS s’appelait Yellow Pages en violation flagrante avec un copyright détenu par British Telecom. Cela explique que tant de services NIS commencent par le préfixe yp comme ypserv, ypbind etc... Les informations de NIS sont conservées dans ce qui est appelé un map, un map étant généralement créé à partir d’un fichier matrice comme /etc/hosts ou /etc/passwd. Contrairement à NFS, XDR et RPC, les spécifications NIS n’ont pas fait l’objet d’une RFC et sortent donc du champ d’application de cet ouvrage.

Telnet est une commande vous permettant de vous connecter sur d’autres ordinateurs distants et d’y lancer des programmes. Telnet recourt au protocole de transport TCP. Une fois connecté, c’est comme si votre clavier était physiquement connecté à la machine distante. Tous les caractères que vous tapez sont envoyés à cette machine à l’exception du caractère ESC qui sert de caractère de contrôle. Avec Telnet, vous pouvez accéder à tous les services qui sont proposés par l’ordinateur hôte : exécuter des commandes Unix, consulter des catalogues, lancer des programmes comme archie ou wais. La commande n’est pas bien compliquée : telnet nom_de_la_machine_à_contacter.

Supposons que vous disposiez d’un compte à l’ULB et y accédiez par

Telnet utilise un caractère spécial qu’il insère dans le flux de données pour indiquer qu’il envoie des séquences spéciales de contrôle. Ce caractère est le code ASCII 255 ( 0xFF en hexadécimal). Ce caractère est appelé IAC pour " Interpret As Command ". Le caractère IAC est suivi d’une autre commande. par exemple, l’envoi d’une séquence break se découpe en une séquence IAC, BRK ( codes 255 puis 243 ) insérée dans un segment TCP.

En utilisant Telnet sur d’autres ports, on peut aisément débugger d’autres protocoles. Un exemple avec SMTP sur le port 25 :

RED 220 RED.RUTGERS.EDU SMTP Service at 29 Jun 87 05:17:18 EDT

TOPAZ .

FTP désigne à la fois un programme et le protocole qu’il utilise, le File Transfer Protocol. Son rôle est de transférer des fichiers d’un ordinateur à l’autre. Il existe des centaines d’applications FTP en mode texte ou en mode graphique. Toutes respectent à peu près les mêmes conventions.

La première opération est d’ouvrir une connexion avec un site distant en précisant son nom ou son adresse IP. La façon la plus simple est de faire passer ce nom dans la ligne de commande :

Ou bien de lancer le programme FTP et à l’invite de commande, taper la commande :

ftp> open cm.riv.be

La deuxième étape consistera à communiquer votre nom et votre mot de passe à la machine distante.

Si vous disposez d’un compte sur la machine, laissez votre nom d’utilisateur et votre mot de passe pour disposer de droits plus importants. Sinon vous pourrez toujours vous connecter sous le nom "anonymous" et laisser votre adresse email comme mot de passe.

Pour recommencer la procédure de login, vous pouvez utiliser la commande user suivie du nom d’utilisateur.

Pour transférer les fichiers, deux commandes sont à retenir : get pour downloader ou rapatrier un fichier vers votre machine, put pour uploader ou envoyer un fichier vers le site distant.

La syntaxe est identique dans les deux cas : put/get fichier_source fichier_destination. Avant de transférer un fichier, il vous faudra préciser à votre machine si le transfert doit s’opérer en mode texte ou en mode binaire. Pour cela, utilisez les commandes ASCII et BINARY.

Pour naviguer dans le répertoire arborescent de fichiers, vous disposez des commandes dir et ls pour afficher le contenu du répertoire courant. Pour obtenir un catalogue complet et récursif des fichiers ainsi que leurs attributs, utilisez la commande ls -LR. Le passage d’un répertoire à l’autre s’opère comme sur MS-DOS ou Unix avec la commande cd.

La liste des commandes envoyées par le programme client FTP au serveur FTP sont les suivantes :

Le serveur FTP répond à ces requêtes par des séquences de nombres de trois chiffres et leur signification sous forme de texte, comme suit

Nous noterons au passage que le serveur FTP utilise deux ports, 21 pour le contrôle des données et 20 pour le transfert de ces mêmes données. En cas de requête de transfert d’informations, un message de contrôle est envoyé sur le port 21 tandis qu’une connexion logique séparée est construite sur le port 20.

Chaque logiciel client FTP dispose de son propre jeu de commandes propriétaire. Seules les quelques fonctions de base gardent leur nom original ( ls, dir, get, put, ascii, binary ). Voici par exemple la liste des commandes du client FTP inclus dans Windows 95.

! delete literal prompt send

? debug ls put status

append dir mdelete pwd trace

ascii disconnect mdir quit type

bell get mget quote user

binary glob mkdir recv verbose

bye hash mls remotehelp

cd help mput rename

close lcd open rmdir

Certains serveurs FTP peuvent aussi exécuter des commandes qui peuvent parfois être détournées au profit des pirates. Refusez l’accès anonymous sur votre serveur FTP ou, si ce n’est pas possible, placez le serveur FTP sur une machine avec un acompte root accessible uniquement depuis la console.

Voici un exemple de bug très dangereux:

220 tucows FTP server (Version wu-2.4(1) Sat Feb 18 13:40:36 CST 1995) ready.

Password:

Cela a pour effet de supprimer, purement et simplement, le password root. Ca marche extrêmement bien sur certaines machines!

Le Trivial File Transfer Protocol est un programme aux fonctionnalités réduites désigné pour être aisément implémenté dans des mémoires permanentes telles les EPROM. Il est principalement utilisé pour permettre à des stations sans disque dur de télécharger sur le réseau la portion initiale d’un système d’exploitation. Il est alors utilisé en conjonction avec un protocole de boot comme BOOTP. TFTP est également utilisé sur les routeurs lorsqu’il faut y télécharger une version plus récente d’une couche logicielle.

TFTP n’utilise pas TCP mais UDP. Il doit donc gérer son propre mécanisme de correction d’erreurs. Pour celà, il utilise un simple protocole d’acknowledgement basé sur un time out. Si un datagramme s’égare, l’émetteur reçoit un time out et réémet. Un datagramme à la sauce TFTP est de 512 octets. S’il est plus petit que 512 octets, c’est qu’il s’agit du dernier paquet de la transmission d’un fichier.

La requête initiale d’un client TFTP est émise sur le port 69 qui va renvoyer une nouvelle adresse de port pour la suite des transactions.

La principale fonction de TFTP est d’agir comme protocole " bootstrap ". Ses exigences mémoire minimales, son emploi d’UDP en font un programme idéal pour charger sur des EPROMS de cartes réseau. Au démarrage d’une machine avec une telle EPROM, le protocole TFTP est automatiquement initialisé pour se connecter à un serveur et y télécharger les programmes nécessaires à son exploitation.

BOOTP permet à une machine incapable de stocker sa propre adresse IP ou les couches TCP/IP nécessaires à sa connexion réseau d’envoyer un message broadcast sur le réseau et d’obtenir ces informations manquantes d’un serveur BOOTP. Un serveur BOOTP est à l’écoute des requêtes BOOTP et renvoie des réponses à partir d’une table de configuration ( bootptab) reprenant l’ensemble des caractéristiques des machines clients BOOTP du réseau.

Les en-têtes de datagrammes BOOTP sont envoyés sous forme de datagramme UDP du port 68 d’un client vers le port 67 du serveur.

Un client BOOTP doit juste être capable de compléter le champ d’en-tête mentionnant son adresse MAC

Les requêtes client BOOTP sont émises avec une adresse source 0.0.0.0 et une adresse de destination fixée à 255.255.255.255 ce qui permet au TCP/IP d’émettre un broadcast du datagramme BOOTP sur tout le réseau local. Soit un serveur BOOTP est présent sur cette portion de câble et il répond à la requête, soit un routeur décide de faire passer ces requêtes vers l’extérieur ou non.

BOOTP a ses inconvénients par exemple de réclamer une configuration manuelle de tables de configurations sur le serveur. Si une machine avec une adresse MAC x est transférée sur une autre portion de réseau, la table de correspondance adresse MAC - adresse IP doit être modifiée sur la machine serveur.

DHCP est une amélioration du système BOOTP. Il pallie les limites de BOOTP en permettant l’allocation dynamique et centralisée d’une adresse IP à toutes les machines d’un réseau TCP/IP. Le serveur DHCP dispose d’une série d’adresses prédéfinies qu’il peut allouer aux clients en cours de connexion. Il dispose même d’une compatibilité descendante avec le protocole BOOTP.

Le client et le serveur DHCP sont des applications à la norme Windows Sockets permettant la configuration automatique de différents protocoles TCP/IP. On confie au serveur une fourchette d’adresses IP disponibles et quelques paramètres comme la passerelle par défaut, le serveur DNS, le NetBIOS Name Server etc.

Lorsqu’un client DHCP est activé pour la première fois, il envoie un message broadcast DHCP Discover à l’ensemble du réseau local. Tout serveur DHCP recevant ce paquet renvoie une réponse DHCP Offer contenant les paramètres de configuration suggérés. Le client évalue la proposition et répond avec un message DHCP Request. Le serveur termine la transaction par un message DHCP Acknowledgement.

DHCP a conservé le format des datagrammes BOOTP, le champ " vendor-specific " devenant un champ " option field " d’un minimum de 312 octets et débutant par un magic cookie 99.130.83.99

WINS est un Name Service pour NetBIOS. Un serveur WINS se charge de l’enregistrement d’un nom et de sa résolution Quand il faut convertir des noms NetBIOS en adresses IP, plutôt que d’utiliser un fichier statique LMHOSTS ou un DNS, il est nettement plus aisé de recourir à un serveur WINS qui sniffe, intercepte les paquets NBT passant sur le câble pour établir cette correspondance dynamiquement. Lorsqu’on utilise NetBIOS-on-TCP/IP ou NBT, les requêtes NBT sont adressées directement au serveur WINS plutôt que d’être diffusées par broadcast. avec comme résultat un gain de performance et une fiabilité accrue.

WINS côté client

WINS côté serveur

L’utilisation d’un serveur WINS réduit fortement le nombre de paquets broadcast IP utilisés par les programmes client Microsoft.

Internet Relay Chat, IRC en bref, est un service où des utilisateurs du monde entier peuvent échanger des conversations par clavier interposé.

Le concept de " network news " est né en 1979 avec deux étudiants, Tom Truscott et Jim Ellis, qui ont utilisé des connexions UUCP pour échanger des informations entre trois machines de caroline du Nord. La première version publique de leur logiciel a été baptisé A News. A News ne supportait que quelques messages par groupe et par jour. Il a été réécrit en 1982 pour devenir Bnews. CNews remonte à 1987.

Usenet est une collection de conférences et forums électroniques où les utilisateurs s’échangent des opinions, des informations sur les thèmes les plus divers. Il y a pour l’instant à peu près huit mille conférences. Vous vous en dotez, les plus populaires commencent par l’extension alt.sex.* et drainent plus de quatre cent mille lecteurs. Les thèmes de conférences sont classés de façon hiérarchique avec un système de noms séparés par des points. Les huit branches majeures sont :

Pour accéder à Usenet, tout ce que vous devez trouver est un autre site Usenet acceptant de vous " nourrir ". Les news sont distribuées sur le réseau via différents types de transport. Le médium de transport était traditionnellement UUCP. Via NNTP, l’algorithme de routage est appelé flooding : chaque site conserve un certain nombre de liens vers d’autres sites à qui un message est envoyé si le site en question n’est pas encore repris dans le champ Path:

UUCP, ou plutôt UNIX-to-UNIX Copy, est un mécanisme ancien de transferts d’informations entre machines Unix comme le courrier électronique, les articles de newsgroups et les fichiers. UUCP démarra comme un paquet de logiciels pour le transfert de fichiers sur port série. UUCP a vu le jour en 1977 aux Bell Laboratories sous la houlette de Mike Lesket reliait déjà 80 sites en 1978. L’inconvénient majeur de UUCP, sa faible largeur de bande, l’a rendu obsolète pour les connexions permanentes et rapides d’aujourd’hui. UUCP reste très populaire chez les hobbyistes, dans les pays du Sud et partout où se justifient des connexions intermittentes à faibles prix. Il reste deux versions d’UUCP en compétition : " Version 2 UUCP " remontant à 1977 et " BNU " ou " Basic Networking Utilities " de 1983.

Chaque transfert initialisé par UUCP est appelé un job. Un job est lui-même constitué d’une commande à exécuter sur la machine distante et d’une collection de fichiers à transférer entre sites. Chaque job dispose d’un grade, soit une valeur de 0 à 9, A à Z ou a à z en ordre décroissant indiquant un niveau de priorité.

Dans l’environnement UUCP original, l’adresse électronique d’un destinataire de message était sous la forme path!host!user, avec path décrivant la séquence d’hôtes à traverser avant d’atteindre la machine host. Ce type d’adresse est appelé la notation bang path à cause du point d’exclamation couramment appelé bang dans le monde réseau. La majorité des sites UUCP a désormais adopté le format d’adresses RFC 822.

NNTP utilise un protocole de transport TCP orienté connexion. cette connexion permet au client et au serveur de négocier le transfert d’articles sans délai.

SNMP pour Simple Network Management Protocol renvoie à une série de composants requis pour gérer un réseau.

Le programme finger permet de déterminer qui est connecté à une machine particulière ou d’obtenir des informations détaillées sur un utilisateur donné. Le Finger User Information Protocol est défini dans la RFC 1288.

Classiquement, la syntaxe de commande est :

finger <user>@host

Imaginons que je veuille savoir qui est connecté sur la machine thesite.thenet.be:

Login Name Tty Idle Login Time Office Office phone

manu manu p1 89d Oct 10 20:52 (192.168.2.2)

root root p0 1 Oct 10 20:51 (192.168.2.2)

On voit que l’utilisateur manu et l’utilisateur root sont tous deux connectés. On sait donc que le compte manu existe et on peu commencer à orienter ses recherche par là...

Cherchons quelques informations supplémentaires sur l’utilisateur manu de cette manière:

Login: manu Name: manu

Directory: /home/manu Shell: /bin/bash

On since Thu Oct 10 20:52 (EET) on ttyp1 from 192.168.2.2

0 days 5 hours idle

No mail.

No Plan.

Avant d’attaquer une machine, le pirate préfère savoir si quelqu’un travaille dessus. Si c’est ce cas, il préférera ne pas attaquer, de peur d’être repéré et de perdre ainsi tout le bénéfice de son " travail ".

Sans compter que Finger a été la source de nombreux bugs, pouvant rendre exécutable une partie des paramètres qu’on lui passait. Finger étant exécuté par root, les commandes pouvaient avoir de graves conséquences.

CIFS Common Internet File Systems

DOD Department Of Defense - Département de la Défense

FAT File Allocation Table - Table d'Allocation de Fichiers