5.2.1. Le fichier /etc/hosts

Le fichier hosts donne un moyen d'assurer la résolution de noms

Exemple de fichier host

127.0.0.1  localhost localhost.localdomain
192.168.1.1  uranus.foo.org uranus

5.2.2. Le fichier /etc/networks

Il permet d'affecter un nom logique à un réseau

localnet   127.0.0.0
foo-net 192.168.1.0

Cette option permet par exemple d'adresser un réseau sur son nom, plutôt que sur son adresse.

route add foo-net au lieu de route add -net 192.168.1.0.

5.2.3. Le fichier /etc/host.conf

Il donne l'ordre dans lequel le processus de résolution de noms est effectué. Voici un exemple de ce que l'on peut trouver dans ce fichier :

order hosts,bind

La résolution est effectuée d'abord avec le fichier host, en cas d'échec avec le DNS.

5.2.4. Le fichier /etc/resolv.conf

Il permet d'affecter les serveurs de noms.

Exemple

Nameserver 192.168.1.1
Nameserver 192.168.1.2
Nameserver 192.168.1.3

Ici le fichier déclare le nom de domaine et 3 machines chargées de la résolution de noms.

5.2.5. Les fichiers de configuration des interfaces réseau

Vous trouverez ces fichiers dans /etc/network/interfaces. Voici un exemple qui contient 3 interfaces.

# /etc/network/interfaces -- configuration file for ifup(8), ifdown(8)
# The loopback interface
# automatically added when upgrading

auto lo eth0 eth1

iface lo inet loopback

iface eth0 inet static
        address 192.168.90.1
        netmask 255.255.255.0
        network 192.168.90.0
        broadcast 192.168.90.255
        gateway 192.168.90.1

iface eth1 inet static
        address 192.168.0.1
        netmask 255.255.255.0
        network 192.168.0.0
        broadcast 192.168.0.255

5.3.1. La commande ifconfig

La commande ifconfig permet la configuration locale ou à distance des interfaces réseau de tous types d'équipements (unité centrale, switch, routeur). La ligne de commande est :

ifconfig interface adresse [parametres].

Exemple : ifconfig eth0 192.168.1.2 (affecte l'adresse 192.168.1.2 à la première interface physique.

Voici les principaux arguments utilisés :

interface logique ou physique, il est obligatoire,

up active l'interface

down désactive l'interface

mtu définit l'unité de transfert des paquets

netmask affecter un masque de sous-réseau

broadcast définit l'adresse de broadcast

arp ou -arp activer ou désactiver l'utilisation du cache arp de l'interface

metric paramètre utilisé pour l'établissement des routes dynamiques, et déterminer le " coût " (nombre de sauts ou " hops ") d'un chemin par le protocole RIP.

multicast active ou non la communication avec des machines qui sont hors du réseau.

promisc ou -promisc activer ou désactiver le mode promiscuité de l'interface. En mode promiscuous, tous les paquets qui transitent sur le réseau sont reçus également par l'interface. Cela permet de mettre en place un analyseur de trame ou de protocole.

Description du résultat de la commande ifconfig eth0 :

1. eth0 Link encap:Ethernet HWaddr 00:80:C8:32:C8:1E

2. inet addr:192.168.1.1 Bcast:192.168.1.255 Mask:255.255.255.0

3. UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1

4. RX packets:864 errors:0 dropped:0 overruns:0 frame:0

5. TX packets:654 errors:0 dropped:0 overruns:0 carrier:0

6. collisions:0

7. Interrupt:10 Base address:0x6100

Explications :

Ligne 1: l'interface est de type Ethernet. La commande nous donne l'adresse MAC de l'interface.

Ligne 2 : on a l'adresse IP celle de broadcast, celle du masque de sous-réseau

Ligne 3 : l'interface est active (UP), les modes broadcast et multicast le sont également, le MTU est de 1500 octets, le Metric de 1

Ligne 4 et 5 : RX (paquets reçus), TX (transmis), erreurs, suppressions, engorgements, collision

Mode d'utilisation :

Ce paragraphe décrit une suite de manipulation de la commande ifconfig.

Ouvrez une session en mode console sur une machine.

1 - Relevez les paramètres de votre machine à l'aide de la commande ifconfig. Si votre machine n'a qu'une interface physique, vous devriez avoir quelque chose d'équivalent à cela.

 Lo  Link encap:Local Loopback 
 inet addr:127.0.0.1  Bcast:127.255.255.255  Mask:255.0.0.0 
 UP BROADCAST LOOPBACK RUNNING  MTU:3584  Metric:1 
 RX packets:146 errors:0 dropped:0 overruns:0 frame:0 
 TX packets:146 errors:0 dropped:0 overruns:0 carrier:0 
 collisions:0 

 eth0 Link encap:Ethernet  HWaddr 00:80:C8:32:C8:1E 
 inet addr:192.168.1.1  Bcast:192.168.1.255  Mask:255.255.255.0 
 UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1 
 RX packets:864 errors:0 dropped:0 overruns:0 frame:0 
 TX packets:654 errors:0 dropped:0 overruns:0 carrier:0 
 collisions:0 

 Interrupt:10 Base address:0x6100 

2 - Désactivez les 2 interfaces lo et eth0

ifconfig lo down

ifconfig eth0 down

3 - Taper les commandes suivantes :

ping localhost

ping 192.168.1.1

telnet localhost

Aucune commande ne fonctionne, car même si la configuration IP est correcte, les interfaces sont désactivées.

4 - Activez l'interface de loopback et tapez les commandes suivantes :

ifconfig lo up /* activation de l'interface de loopback */

ping localhost ou telnet localhost /* ça ne marche toujours pas */

route add 127.0.0.1 /* on ajoute une route sur l'interface de loopback */

ping localhost ou telnet localhost /* maintenant ça marche */

ping 192.168.1.1 /* ça ne marche pas car il manque encore une route*/

On peut déduire que :

• - pour chaque interface il faudra indiquer une route au protocole.

• - dans la configuration actuelle, aucun paquet ne va jusqu'à la carte, donc ne sort sur le réseau.

Voici le rôle de l'interface loopback. Elle permet de tester un programme utilisant le protocole IP sans envoyer de paquets sur le réseau. Si vous voulez écrire une application réseau, (telnet, ftp, ou autre), vous pouvez la tester de cette façon.

5 - Activez l'interface eth0 et tapez les commandes suivantes :

ifconfig eth0 up /* activation de l'interface */

route add 192.168.1.1

ifconfig /* l'information Tx/Rx de l'interface eth0 vaut 0 */

/* Aucun paquet n'est encore passé par la carte.*/

ping 127.0.0.1

ifconfig /* on voit que l'information Tx/Rx de lo est modifiée */

/* pas celle de eth0, on en déduit que les paquets */

/* à destination de lo ne descendent pas jusqu'à l'interface physique */

ping 192.168.1.1 /* test d'une adresse locale */

ifconfig /* Ici on peut faire la même remarque. Les paquets ICMP */

/* sur une interface locale, ne sortent pas sur le réseau */

/* mais ceux de l'interface lo sont modifiés*/

ping 192.168.1.2 /* test d'une adresse distante */

ifconfig /* Ici les paquets sont bien sortis. Les registres TX/RX de eth0 */

/* sont modifiés, mais pas ceux de lo */

6 -Réalisez les manipulations suivantes, nous allons voir le comportement de la commande ping sur les interfaces.

Sur la machine tapez la commande

192.168.1.1 ifconfig /* relevez les valeurs des registres TX/RX */

192.168.1.2 ping 192.168.1.1

192.168.1.1 ifconfig /* relevez les nouvelles valeurs des registres TX/RX */

/* il y a bien eu échange Réception et envoi de paquets*/

192.168.1.2 ping 192.168.1.3

192.168.1.1 ifconfig /* On voit que le registre Rx est modifié mais */

/* le registre Tx n'est pas modifié. La machine a bien reçu*/

/* paquet mais n'a rien renvoyé */

192.168.1.2 ping 192.168.1.2

192.168.1.2 ifconfig /* aucun registre n'est modifié, donc les paquets */

/* ne circulent pas jusqu'à l'interface physique avec un .*/

/* ping sur l'interface locale */

7 - le MTU (Message Transfert Unit) détermine l'unité de transfert des paquets.

Vous allez, sur la machine 192.168.1.1 modifier le MTU par défaut à 1500, pour le mettre à 300, avec la commande :

ifconfig eth0 mtu 300

Sur la machine d'adresse 192.168.1.2, vous allez ouvrir une session ftp et chronométrer le temps de transfert d'un fichier de 30 MO. Relevez le temps et le nombre de paquets transmis ou reçus (commande ifconfig, flags TX/RX).

Restaurez le paramètre par défaut sur la première machine.

Refaites le même transfert et comparez les chiffres. La différence n'est pas énorme sur le temps car le volume de données est peu important. Par contre la différence sur le nombre de paquets, elle, est importante.

5.3.2. La commande arp

Description de la commande

La commande arp permet de visualiser ou modifier la table du cache de l'interface. Cette table peut être statique et (ou) dynamique. Elle donne la correspondance entre une adresse IP et une adresse Ethernet.

À chaque nouvelle requête, le cache ARP de l'interface est mis à jour. Il y a un nouvel enregistrement. Cet enregistrement à une durée de vie (ttl ou Time To Leave).

Voici un exemple de cache ARP obtenu avec la commande arp -va :

? (192.168.1.2) at 00:40:33:2D:B5:DD [ether] on eth0
>Entries: 1      Skipped: 0      Found: 1

On voit l'adresse IP et l'adresse MAC correspondante. Il n'y a qu'une entrée dans la table. Voici les principales options de la commande arp :

arp -s (ajouter une entrée statique), exemple : arp -s 192.168.1.2 00:40:33:2D:B5:DD

arp -d (supprimer une entrée), exemple : arp -d 192.168.1.2

Voir la page man pour les autres options.

La table ARP et le fonctionnement d'un proxy ARP.

Cela est réalisé par la configuration de tables ARP statiques.

Le proxy est une machine qui est en interface entre un réseau et l'accès à Internet. Il fait office de passerelle et de cache à la fois.

• Passerelle, parce que tous les accès à Internet passent par le Proxy,

• Cache, parce que le Proxy conserve en mémoire cache (sur disque), une copie des pages consultées par les utilisateurs du réseau. Cela évite de télécharger à nouveau la même page sur le site d'origine, si un utilisateur revient fréquemment dessus.

Si un hôte du réseau demande l'adresse d'un noeud distant situé sur un autre réseau, et que cet hôte passe par un proxy, le proxy va renvoyer à l'hôte sa propre adresse Ethernet. Une fois cette opération réalisée, tous les paquets envoyés par l'hôte seront à destination de l'adresse Ethernet du proxy. Le proxy aura en charge de transmettre ces paquets à l'adresse effective du noeud distant.

Pour les réponses, un processus identique est mis en place. Le site consulté, ne retourne les réponses qu'au serveur proxy. Le serveur proxy se charge de ventiler les pages au bon destinataire du réseau local.

Voir, pour le fonctionnement des serveurs cache et la configuration des navigateurs avec ce type de serveur, le document sur le W3 et les scripts CGI.

Mode d'utilisation :

Attention à certaines interprétations de ce paragraphe. Il dépend de votre configuration. Soit vous êtes en réseau local avec une plage d'adresse déclarée, soit vous utilisez une carte d'accès distant.

Première partie :

1. Affichez le contenu de la table ARP avec la commande arp -a,

2. Supprimez chaque ligne avec la commande arp -d @ip, où @ip est l'adresse IP de chaque hôte apparaissant dans la table,

3. La commande arp -a ne devrait plus afficher de ligne,

4. Faites un ping, sur une station du réseau local,

5. arp -a, affiche la nouvelle entrée de la table,

6. Ouvrez une session sur Internet, puis ouvrez une session ftp anonyme sur un serveur distant en utilisant le nom, par exemple ftp.cdrom.com. Utilisez une adresse que vous n'avez jamais utilisée, supprimez également tout gestionnaire de cache.

7. Affichez le nouveau contenu de la table avec arp -a. Le cache ARP ne contient pas l'adresse Ethernet du site distant, mais celle de la passerelle par défaut. Cela signifie que le client n'a pas à connaître les adresses Ethernet des hôtes étrangers au réseau local, mais uniquement l'adresse de la passerelle. Les paquets sont ensuite pris en charge par les routeurs.

8. Refaites une tentative sur le site choisi précédemment. Le temps d'ouverture de session est normalement plus court. Cela est justifié, car les serveurs de noms ont maintenant dans leur cache la correspondance entre le nom et l'adresse IP.

Deuxième partie :

La commande arp permet de diagnostiquer un dysfonctionnement quand une machine prend l'adresse IP d'une autre machine.

1. Sur la machine 192.168.1.1, faites un ping sur 2 hôtes du réseau 192.168.1.2 et 192.168.1.3,

2. À l'aide de la commande arp, relevez les adresses MAC de ces noeuds,

3. Modifiez l'adresse IP de la machine 192.168.1.2 en 192.168.1.3

4. relancez les 2 machines en vous arrangeant pour que la machine dont vous avez modifié l'adresse ait redémarré la première,

5. Sur la machine d'adresse 192.168.1.1, remettez à jour les tables ARP.

6. Quel est le contenu, après cela de la table ARP ?

Conclusion : vous allez avoir un conflit d'adresses. Vous allez pouvoir le détecter avec la commande arp. Autre problème, si vous faites un telnet sur 192.168.1.3, il y a de fortes chances pour que ce soit la machine qui était d'adresse 192.168.1.2, qui vous ouvre la session. Nous sommes (par une action volontaire bien sûr) arrivés à mettre la pagaille sur un réseau de 3 postes. Cette pagaille pourrait tourner vite au chaos sur un grand réseau, d'où la nécessité pour un administrateur de faire preuve d'une grande rigueur.

Où en suis-je ?

Exercice 1 :

Vous êtes sur un réseau d'adresse 192.168.1.0 avec une interface d'adresse MAC 00:40:33:2D:B5:DD,

Vous n'avez aucun fichier host sur votre machine,

Il n'y a pas de DNS

La passerelle par défaut est 192.168.1.9

Vous faites un ping 195.6.2.3 qui a une interface d'adresse MAC 00:45:2D:33:C2 est localisée sur Internet

Le réseau fonctionne parfaitement et tout est parfaitement configuré

Cochez la bonne réponse:

A - On a dans la table arp ? (192.168.1.2) at 00:40:33:2D:B5:DD [ether] on eth0

B - On a dans la table arp ? (192.168.1.2) at 00:45:2D:33:C2 [ether] on eth0

C - On a dans la table arp ? (195.6.2.3) at 00:40:33:2D:B5:DD [ether] on eth0

D - On a dans la table arp ? (195.6.2.3) at 00: 00:45:2D:33:C2 [ether] on eth0

E - Il faut un fichier host, ou DNS pour réaliser l'opération ping demandée

F - Il n'est pas possible dans la configuration actuelle d'atteindre l'hôte 195.6.2.3

Réponse F, car la plage d'adresse 192.168.1.1 à 192.168.1.254 n'est pas routée sur l'Internet, sinon vous auriez l'adresse de la passerelle par défaut dans le cache ARP.

Exercice 2 :

Vous êtes sur un réseau d'adresse 192.5.1.0 avec une interface d'adresse MAC 00:40:33:2D:B5:DD,

Vous n'avez aucun fichier host sur votre machine,

Il n'y a pas de DNS,

La passerelle par défaut est 192.5.1.9

Vous faites un ping www.existe.org dont l'adresse IP est 195.6.2.3, et qui a une interface d'adresse MAC 00:45:2D:33:C2

Le réseau fonctionne parfaitement et tout est parfaitement configuré

Cochez la bonne réponse:

A - On a dans la table arp ? (192.5.1.0) at 00:40:33:2D:B5:DD [ether] on eth0

B - On a dans la table arp ? (192.5.1.0) at 00:45:2D:33:C2 [ether] on eth0

C - On a dans la table arp ? (195.6.2.3) at 00:40:33:2D:B5:DD [ether] on eth0

D - On a dans la table arp ? (195.6.2.3) at 00: 00:45:2D:33:C2 [ether] on eth0

E - Il faut un fichier host, ou DNS pour réaliser l'opération ping demandée

F - Il n'est pas possible dans la configuration actuelle d'atteindre l'hôte 195.6.2.3

Réponse E, car la résolution de noms ne peut être effectuée

Exercice 3 :

Vous êtes sur un réseau d'adresse 192.5.1.0, sur une machine d'adresse 192.5.1.1, et une interface d'adresse MAC 00:40:33:2D:B5:DD,

Vous n'avez aucun fichier host sur votre machine,

Il n'y a pas de DNS

La passerelle par défaut est 192.5.1.9, d'adresse MAC 09:44:3C:DA:3C:04

Vous faites un ping 195.6.2.3, et qui a une interface d'adresse MAC 00:45:2D:33:C2

Le réseau fonctionne parfaitement et tout est parfaitement configuré

Cochez la bonne réponse: 

A - On a dans la table arp ? (192.5.1.0) at 00:40:33:2D:B5:DD [ether] on eth0

B - On a dans la table arp ? (192.5.1.0) at 00:45:2D:33:C2 [ether] on eth0

C - On a dans la table arp ? (195.6.2.3) at 00:40:33:2D:B5:DD [ether] on eth0

D - On a dans la table arp ? (192.5.1.9) at 09:44:3C:DA:3C:04 [ether] on eth0

E - Il faut un fichier host, ou DNS pour réaliser l'opération ping demandée

F - Il n'est pas possible dans la configuration actuelle d'atteindre l'hôte 195.6.2.3

Réponse D, l'hôte a bien été trouvé, la table ARP a été mise à jour avec l'adresse IP de la passerelle par défaut et son adresse Ethernet.

5.3.3. La commande route

La commande route a déjà été entrevue un peu plus haut, avec la commande ifconfig. Le routage définit le chemin emprunté par les paquets entre son point de départ et son point d'arrivée. Cette commande permet également la configuration de pc, de switchs de routeurs.

Il existe 2 types de routages :

- le routage statique

- le routage dynamique.

Le routage statique consiste à imposer aux paquets la route à suivre.

Le routage dynamique met en oeuvre des algorithmes, qui permettent aux routeurs d'ajuster les tables de routage en fonction de leur connaissance de la topologie du réseau. Cette actualisation est réalisée par la réception des messages reçus des noeuds (routeurs) adjacents.

Le routage dynamique permet d'avoir des routes toujours optimisées, en fonction de l'état du réseau (nouveaux routeurs, engorgements, pannes)

On combine en général le routage statique sur les réseaux locaux au routage dynamique sur les réseaux importants ou étendus.

Un administrateur qui dispose par exemple de 2 routeurs sur un réseau, peut équilibrer la charge en répartissant un partie du flux sur un port avec une route, et une autre partie sur le deuxième routeur.

Exemple de table de routage :

Kernel IP routing table
Destination 	Gateway 	Genmask  	Flags  Metric  Ref Use  Iface
192.168.1.0 	*  		255.255.255.	0U     0       0   2    eth0
127.0.0.0 	*  		255.0.0.0   	U      0       0   2    lo
default  	192.168.1.9 	0.0.0.0   	UG     0       0   10   eth0

Commentaire généraux :

Destination : adresse de destination de la route

Gateway : adresse IP de la passerelle pour atteindre la route, * sinon

Genmask : masque à utiliser.

Flags : indicateur d'état (U - Up, H - Host - G - Gateway, D - Dynamic, M - Modified)

Metric : coût métrique de la route (0 par défaut)

Ref : nombre de routes qui dépendent de celle-ci

Use : nombre d'utilisation dans la table de routage

Iface : interface eth0, eth1, lo

Commentaire sur la 3ème ligne :

Cette ligne signifie que pour atteindre tous les réseaux inconnus, la route par défaut porte l'adresse 192.168.1.9. C'est la passerelle par défaut, d'où le sigle UG, G pour gateway.

Ajout ou suppression d'une route :

route add [net | host] addr [gw passerelle] [métric coût] [ netmask masque] [dev interface]

- net ou host indique l'adresse de réseau ou de l'hôte pour lequel on établit une route,

- adresse de destination,

- adresse de la passerelle,

- valeur métrique de la route,

- masque de la route à ajouter,

- interface réseau à qui on associe la route.

Exemples :

route add 127.0.0.1 lo /* ajoute une route pour l'adresse 127.0.0.1 sur l'interface lo */

route add -net 192.168.2.0 eth0 /* ajoute une route pour le réseau 192.168.2.0 sur l'interface eth0 */

route add saturne.foo.org /* ajoute une route pour la machine machin sur l'interface eth0 */

route add default gw ariane /* ajoute ariane comme route par défaut pour la machine locale */

/* ariane est le nom d'hôte d'un routeur ou d'une passerelle */

/* gw est un mot réservé */

route add duschmoll netmask 255.255.255.192

/* Encore un qui a créé des sous réseaux., Il s'agit ici d'une classe c */

/* avec 2 sous réseaux, il faut indiquer le masque. */

Suppression d'une route :

route del -net 192.168.1.0

route del -net toutbet-net

Attention, si on utilise des noms de réseau ou des noms d'hôtes, il faut qu'à ces noms soient associés les adresses de réseau ou des adresses IP dans le fichier /etc/networks pour les réseaux, et /etc/hosts ou DNS pour les noms d'hôtes.

Vous pouvez également voir l'atelier sur la mise en place d'un routeur logiciel.

Petite étude de cas :

Première partie - réalisation d'une maquette

On dispose de 2 réseaux (A et B) reliés par une passerelle. Le réseau A est également relié à Internet par un routeur. Le réseau A dispose d'un serveur de noms. Chaque réseau a deux machines.

Réseau 	Nom du réseau	Machine		Nom des machines
A	metaux-net	192.3.2.2	platine
			192.3.2.3	uranium
			192.3.2.4  	mercure	(serveur de noms)
B	roches-net	130.2.0.2	quartz
			130.2.0.3	silex

La passerelle entre le réseau A et B à 2 interfaces :

- eth0 192.3.2.1

- eth1 130.2.0.1

Le réseau A, a une passerelle par défaut pour Internet 130.2.0.9, qui est l'interface d'un autre routeur.

On veut :

- que les stations de chaque réseau puissent accéder à Internet,

- que les stations de chaque réseau puissent communiquer entre-elles,

- que les stations du réseau B, utilisent le serveur de noms le moins possible.

On demande :

1 - d'expliquer comment seront configurés les postes du réseau B,

2 - de donner la configuration des fichiers suivants pour chaque machine (hosts, resolv.conf, fichier de configuration de carte).

3 - de donner la liste des routes à mettre :

- sur les postes du réseau B,

- sur les postes du réseau A,

- sur la passerelle qui relie les 2 réseaux,

- sur le routeur du réseau A.

5.3.4. La commande netstat

La commande netstat, permet de tester la configuration du réseau, visualiser l'état des connexions, établir des statistiques, notamment pour surveiller les serveurs.

Liste des paramètres utilisables avec netstat :

Sans argument, donne l'état des connexions,

-a afficher toutes les informations sur l'état des connexions,

-i affichage des statistiques,

-c rafraîchissement périodique de l'état du réseau,

-n affichage des informations en mode numérique sur l'état des connexions,

-r affichage des tables de routage,

-t informations sur les sockets TCP

-u informations sur les sockets UDP.

État des connexions réseau avec netstat, dont voici un exemple :

 Proto  Recv-Q 	Send-Q 	Local Address  		Foreign Address  State 
 Tcp 	0  	126  	uranus.planete.n:telnet 192.168.1.2:1037 ESTABLISHED 
 Udp    0       0       uranus.plan:netbios-dgm  *:* 
 Udp    0       0       uranus.plane:netbios-ns  *:* 

Active UNIX domain sockets (w/o servers) 
 Proto  RefCnt  Flags        Type        State         I-Node Path 
 unix   2       [ ]          STREAM      1990     /dev/log 
 unix   2       [ ]          STREAM CONNECTED 1989 
 unix   1       [ ]          DGRAM        1955 

Explications sur la première partie qui affiche l'état des connexions :

Proto : Protocole utilisé

Recv-q : nbre de bits en réception pour ce socket

Send-q : nbre de bits envoyés

LocalAdress : nom d'hôte local et port

ForeignAdress : nom d'hôte distant et port

State : état de la connexion

Le champ state peut prendre les valeurs suivantes:

Established : connexion établie

Syn snet : le socket essaie de se connecter

Syn recv : le socket a été fermé

Fin wait2 : la connexion a été fermée

Closed : le socket n'est pas utilisé

Close wait : l'hôte distant a fermé la connexion; Fermeture locale en attente.

Last ack : attente de confirmation de la fermeture de la connexion distante

Listen : écoute en attendant une connexion externe.

Unknown : état du socket inconnu

Explications sur la deuxième partie qui affiche l'état des sockets (IPC - Inter Processus Communication) actifs :

Proto : Protocole, en général UNIX,

Refcnt : Nombre de processus associés au socket

Type : Mode d'accès datagramme (DGRAM), flux orienté connexion (STREAM), brut (RAW), livraison fiable des messages (RDM)

State : Free, Listening, Unconnected, connecting, disconnecting, unknown

Path : Chemin utilisé par les processus pour utiliser le socket.

Affichage et état des tables de routage avec netstat : netstat -nr ou netstat -r

Kernel IP routing table
Destination   Gateway   Genmask         Flags   MSS    Window  irtt  Iface
192.168.1.0   *         255.255.255.0   U       1500   0       0     eth0
127.0.0.0     *         255.0.0.0       U       3584   0       0     lo

Explications sur la commande netstat -r

Destination : adresse vers laquelle sont destinés les paquets

Gateway : passerelle utilisée, * sinon

Flags : G la route utilise une passerelle, U l'interface est active, H on ne peut joindre qu'un simple hôte par cette route)

Iface : interface sur laquelle est positionnée la route.

Affichage de statistiques avec netstat -i

Iface MTU  Met RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flags
Lo    3584 0   89    0      0      0      89    0      0      0      BLRU
eth0  1500 0   215   0      0      0      210   0      0      0      BRU

Explications sur la commande netstat -i

RX-OK et TX-OK rendent compte du nombre de paquets reçus ou émis,

RX-ERR ou TX-ERR nombre de paquets reçus ou transmis avec erreur,

RX-DRP ou TX-DRP nombre de paquets éliminés,

RX-OVR ou TX-OVR recouvrement, donc perdus à cause d'un débit trop important.

Les Flags (B adresse de diffusion, L interface de loopback, M tous les paquets sont reçus, O arp est hors service, P connexion point à point, R interface en fonctionnement, U interface en service)

Exercices :

On donne les résultats de 3 commandes netstat ci-dessous, extraites de la même machine :

$ netstat -nr

Kernel IP routing table

Destination Gateway Genmask Flags MSS Window irtt Iface

198.5.203.0 0.0.0.0 255.255.255.0 U 1500 0 0 eth0

127.0.0.0 0.0.0.0 255.0.0.0 U 3584 0 0 lo

0.0.0.0 198.5.203.3 0.0.0.0 UG 1500 0 0 eth0

$ netstat

Active Internet connections (w/o servers)

Proto Recv-Q Send-Q Local Address Foreign Address State

Tcp 0 127 uranus.toutbet:telnet 194.206.6.143:1027 ESTABLISHED

$ netstat -i

Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flags

Lo 3584 0 764 0 0 764 89 0 0 0 BLRU

eth0 1500 0 410856 0 0 33286 210 0 0 0 BRU

On demande :

1. Quels sont les noms et adresse de la machine consultée ?

2. Quel type de session est-elle en train de supporter ?

3. À quoi correspond l'adresse 198.5.203.3 ?

4. Pourquoi une interface porte-t-elle les Flags BLRU et l'autre BRU ?

5. Quelle est la taille des paquets utilisée par la passerelle par défaut ?

5.3.5. La commande traceroute

La commande traceroute permet d'afficher le chemin parcouru par un paquet pour arriver à destination. Cette commande est importante, car elle permet d'équilibrer la charge d'un réseau, en optimisant les routes.

Voici le résultat de la commande traceroute www.nat.fr, tapée depuis ma machine.

 traceroute to sancy.nat.fr (212.208.83.2), 30 hops max, 40 byte packets 
  1  195.5.203.9 (195.5.203.9)  1.363 ms  1.259 ms  1.270 ms 
  2  194.79.184.33 (194.79.184.33)  25.078 ms  25.120 ms  25.085 ms 
  3  194.79.128.21 (194.79.128.21)  88.915 ms  101.191 ms  88.571 ms 
  4  cisco-eth0.frontal-gw.internext.fr (194.79.190.126)  124.796 ms[]
  5  sfinx-paris.remote-gw.internext.fr (194.79.190.250)  100.180 ms[]
  6  Internetway.gix-paris.ft.NET (194.68.129.236)  98.471 ms       []
  7  513.HSSI0-513.BACK1.PAR1.inetway.NET (194.98.1.214)  137.196 ms[]
  8  602.HSSI6-602.BACK1.NAN1.inetway.NET (194.98.1.194)  101.129 ms[]
  9  FE6-0.BORD1.NAN1.inetway.NET (194.53.76.228)  105.110 ms       []
 10  194.98.81.21 (194.98.81.21)  175.933 ms  152.779 ms  128.618 ms[] 
 11  sancy.nat.fr (212.208.83.2)  211.387 ms  162.559 ms  151.385 ms[] 

Explications :

Ligne 0 : le programme signale qu'il n'affichera que les 30 premiers sauts, et que la machine www du domaine nat.fr, porte le nom effectif de sancy, dans la base d'annuaire du DNS du domaine nat.fr. Cette machine porte l'adresse IP 212.208.83.2. Pour chaque tronçon, on a également le temps maximum, moyen et minimum de parcours du tronçon.

Ensuite, on a pour chaque ligne, l'adresse du routeur que le paquet a traversé pour passer sur le réseau suivant.

Ligne 4 et 5, le paquet a traversé 2 routeurs sur le même réseau 194.79.190.

Ligne 4, 5, 6, 7, 8, 9, 11, on voit que les routeurs ont un enregistrement de type A dans les serveurs de noms, puisqu'on voit les noms affichés.

Conclusion : depuis ma machine, chaque requête HTTP passe par 11 routeurs pour accéder au serveur www.nat.fr.

L'accès sur cet exemple est réalisé sur Internet. Un administrateur, responsable d'un réseau d'entreprise sur lequel il y a de nombreux routeurs, peut, avec cet outil, diagnostiquer les routes et temps de routage. Il peut ainsi optimiser les trajets et temps de réponse.

5.3.6. La commande dig

La commande dig remplace ce qui était la commande nslookup. Cette commande sert à diagnostiquer des dysfonctionnements dans la résolution de nom. (Service DNS).

Utilisation simple de dig :

$ dig any freenix.org
; <<>> DiG 9.2.2 <<>> any freenix.org
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21163
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 3, ADDITIONAL: 3

;; QUESTION SECTION:
;freenix.org.                   IN      ANY

;; ANSWER SECTION:
freenix.org.            92341   IN      SOA     ns2.freenix.org.\
                                         hostmaster.freenix.org.\ 
                                                      2003042501\ 
                                                           21600\ 
                                                            7200\ 
                                                         3600000\ 
                                                          259200\

freenix.org.            117930  IN      NS      ns2.freenix.fr.
freenix.org.            117930  IN      NS      ns.frmug.org.
freenix.org.            117930  IN      NS      ns6.gandi.net.

;; AUTHORITY SECTION:
freenix.org.            117930  IN      NS      ns2.freenix.fr.
freenix.org.            117930  IN      NS      ns.frmug.org.
freenix.org.            117930  IN      NS      ns6.gandi.net.

;; ADDITIONAL SECTION:
ns2.freenix.fr.         16778   IN      A       194.117.194.82
ns.frmug.org.           40974   IN      A       193.56.58.113
ns6.gandi.net.          259119  IN      A       80.67.173.196

;; Query time: 197 msec
;; SERVER: 213.36.80.1#53(213.36.80.1)
;; WHEN: Tue May 27 15:16:23 2003
;; MSG SIZE  rcvd: 248

Il est ensuite possible d'intérroger sur tout type d'enregistrement : SOA, MX, A, CNAME, PTR...

5.3.7. La commande host

La commande host interroge les serveurs de coms. Elle peut par exemple être utilisée pour détecter des dysfonctionnement sur un réseau (serveurs hors services). Attention, n'utilisez pas cette commande sur des réseaux dont vous n'avez pas l'administration.

6.7.1. Extrait de /etc/inetd.conf

ftp     stream  tcp     nowait  root    /usr/sbin/tcpd  in.ftpd -l -a
telnet  stream  tcp     nowait  root    /usr/sbin/tcpd  in.telnetd

6.7.2. TCP Wrapper

L'administrateur réseau va pouvoir utiliser 2 fichiers: /etc/hosts.allow et /etc/hosts.deny pour filtrer les accès à sa machine.

/etc/hosts.deny: on indique dans ce fichier les services et les hôtes pour lesquels l'accès est interdit.

/etc/hosts.allow: on indique dans ce fichier les services et les hôtes pour lesquels l'accès est autorisé.

Exemple:

# Fichier /etc/hosts.deny
# interdit tous les accès ftp à la machine
in.ftpd:ALL	

# Fichier /etc/hosts.allow
# autorise les accès ftp venant de cli1
in.ftpd :cli1.archinet.edu

TCP-Wrapper utilise l'algorithme suivant :

Si une règle est applicable dans hosts.allow, alors cette règle est appliquée, sinon, Si une règle est applicable dans hosts.deny alors cette règle est appliquée, sinon, l'accès est autorisé.

Ce mode de fonctionnement induit la stratégie de sécurité à adopter :

1. décrire toutes les règles pour les couples (services/clients) qui sont autorisés,

2. interdire systématiquement tout le reste. Mettre par défaut ALL:ALL dans hosts.deny.

Les tentatives d'accès depuis des machines extérieures sont toutes enregistrées dans des fichiers particuliers. Ces enregistrements sont effectués par le processus syslogd qui, à son démarrage, lit le fichier /etc/syslog.conf pour trouver dans quel(s) fichier(s) il doit enregistrer les différentes tentatives d'accès.

7.2.1. Exercices

Créez un schéma explicatif des fichiers lus, dans les 2 cas de figures suivants : connexion bash en local, et connexion bash autres (distantes, xterm, etc).

Décodez le contenu de ces fichiers sur votre machine.

Expliquez pourquoi la Debian n'offre pas la visualisation en couleurs des fichiers (ls). Dans votre bash, lancez un nouveau bash. Testez le ls.. Que se passe-t-il ?

7.3.1. Exercices

Connectez-vous sur deux sessions (afin de comparer la différence), et sur l'une d'elles, activez la complétion étendue (tapez . /etc/bash_completion . Attention au point tout seul : très important pour que le script demandé s'exécute dans l'environnement courant, et non dans un fils (les réglages seraient alors perdus).

Testez la complétion étendue avec cd (tab), avec des commandes (apt-get i(tab)), ssh (tab), man ls(tab).

Que remarquez -vous ?

Comment faire pour bénéficier de tout ceci ?

Consultez vos propres fichiers de connexion (.bash_profile, et .bashrc). Modifiez .bash_profile afin qu'il exécute .bashrc (ainsi, .bashrc est exécuté toujours, en shell de login ou autre). Puis, dans .bashrc, dé commentez l'accès à /etc/bash_completion.

Testez...

7.4.1. Exercice

Quel est le contenu de ce répertoire ?

Modifiez le contenu de /etc/skel comme vous venez de le faire pour vous. Créez un nouvel utilisateur (adduser toto). Connectez vous avec toto, et vérifiez ses réglages.

Imaginons maintenant que nous voulons que tous les nouveaux utilisateurs se retrouvent avec une structure de home standard (par exemple, avec un fichier 'mode d'emploi du réseau' et un sous répertoire public_html déjà prêt pour la publication de pages web :

Créez ce répertoire et un texte 'mode_d_emploi_du_reseau.txt' dans le répertoire /etc/skel.

Créez deux nouveaux utilisateurs (foo et bar)

Observez leurs homes.

7.5.1. Exercice

Définissez votre umask à 0000 : créez des fichiers et des répertoires et vérifiez les droits obtenus. Définissez votre umask pour être le seul à pouvoir voir vos fichiers et répertoires... Vérifiez.

7.6.1. Exercices

Expliquez ce que sont les LETTERHOMES, le rôle des directives commençant par FIRST. Comment faire pour que les homes soient créées dans un sous-répertoire de home portant le nom du groupe ? (tous les homes des comptables dans un sous répertoire /home/comptables)

L'ajout de groupes et d'utilisateurs se fait respectivement par les commandes addgroup et adduser. Consultez le man de ces commandes. Faites le réglage du adduser.conf correspondant, et testez l'ajout de deux groupes (testprofs et testetudiants), puis de quelques utilisateurs (profs et étudiants)

Testez ensuite le bon fonctionnement, en vous connectant en tant que certains de ces utilisateurs.

Supprimez ensuite tous ces utilisateurs, ainsi que leurs répertoires (man userdel)

7.7.1. Exercice

Créez l'ensemble des comptes selon les régles définies en début de cet exercice : Les commerciaux (Bill, Bob, Carlos, Richard, Laura) et les comptables (Raymond, Georgette, Carlotta, Paula).

Ces utilisateurs peuvent avoir un site web (pensez à créer le public_html). Le système de gestion de courrier demande à avoir un répertoire MailDir dans chacun des homes.

Les chefs de services (Bill et Raymond) ont la possibilité d'alimenter le site web (création de pages...) tandis que les utilisateurs ne peuvent que consulter.

9.2.1. Mode de fonctionnement de la couche transport SSH

La couche transport assure le chiffrement et le déchiffrement des données. Elle assure également la compression pour améliorer le transfert. Le client et le serveur négocient plusieurs éléments afin que la session puisse s'établir.

1. l'échange des clés

2. l'algorithme de clé publique à utiliser

3. l'algorithme de chiffrement symétrique à utiliser

4. l'algorithme d'authentification de message à utiliser

5. l'algorithme repère (hash) à utiliser

Lors du premier échange, le client ne connaît pas le serveur. Le serveur propose alors une clé hôte qui servira par la suite au client de moyen d'identification du serveur.

M0:$ ssh -l mlx M1.foo.org
Warning: Permanently added 'M1,x.y.z.t' (DSA) to the list of known hosts.
mlx@M1.foo.org's password:
Last login: Sat Nov  2 11:37:32 2002 from 212.47.248.114
Linux 2.2.19.
mlx@M1.foo.org:$

Voilà un idée de ce que cela donne :

freeduc-sup.alt.eu.org,144.85.15.72 ssh-rsa AAAAB3NzaC1y (...)
pegase,195.115.88.38 ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIE (...)
freeduc-sup.eu.org,137.194.161.2 ssh-dss AAAAB3NzaC1kc3M (...)
(...)

Le risque de ce processus, vient donc surtout de la première transaction, où le client n'a pas le moyen d'identifier de façon fiable le serveur avec qui il communique. Un pirate peut dans certains cas, tenter de détourner cette opération. Au cours d'un échange, le client et le serveur modifient régulièrement leurs clés. À chaque opération de renouvellement de clé, un pirate qui aurait réussi à décrypter les clés, devrait refaire toute l'opération.

Authentification :

Une fois le tunnel sécurisé mis en place, le serveur envoie au client les différentes méthodes d'authentification qu'il supporte. Dans le cadre d'une authentification par mot de passe, celui-ci peut être envoyé en toute sécurité puisqu'il est chiffré.

Connexion :

Une fois l'authentification réalisée, le tunnel SSH peut multiplexer plusieurs canaux en délégant la tâche à des agents.

[mlx@M1 X11]$ pstree -l 24245
sshd---bash-+-drakfw
            |-pstree
            |-2*[xclock]
            `-xlogo

Ici on voit dans la même session ssh, 2 canaux pour xclock, 1 pour xlogo et 1 pour la commande pstree. Chaque canal est numéroté. Le client peut fermer un canal sans pour autant fermer toute la session.

9.2.2. Fichiers de configuration d'OpenSSH

OpenSSH est constitué de deux ensembles de fichiers de configuration, comme c'est en général le cas sur les services sous linux (ldap, samba..). Il y a un fichier de configuration pour les programmes clients (ssh, scp et sftp) et l'autre pour le service serveur(sshd). Les informations de configuration SSH qui s'appliquent à l'ensemble du système sont stockées dans le répertoire /etc/ssh : Voici les principaux fichiers de configuration.

ssh_config               fichier de configuration client SSH pour l'ensemble 
                         du système. Il est écrasé si un même fichier est
                         présent dans le répertoire personnel de
                         l'utilisateur 
                         (~/.ssh/config). 
sshd_config              fichier de configuration pour sshd. 
ssh_host_dsa_key         clé DSA privée utilisée par sshd. 
ssh_host_dsa_key.pub     clé DSA publique utilisée par sshd. 
ssh_host_key             clé RSA privée utilisée par sshd pour la 
                         version 1 du protocole SSH. 
ssh_host_key.pub         clé RSA publique utilisée par sshd pour la 
                         version 1 du protocole SSH. 
ssh_host_rsa_key         clé RSA privée utilisée par sshd pour la 
                         version 2 du protocole SSH. 
ssh_host_rsa_key.pub     clé RSA publique utilisée par sshd pour la 
                         version 2 du protocole SSH. 

Les informations spécifiques à un utilisateur sont stockées dans son répertoire personnel à l'intérieur du répertoire ~/.ssh/:

authorized_keys ou parfois   authorized_keys2
                           ce fichier contient une liste de clés
                           publiques "autorisées". Si un utilisateur
                           se connecte et prouve qu'il connaît la clé
                           privée correspondant à l'une de ces clés, 
                           il obtient l'authentification. Notez qu'il
                           ne s'agit que d'une méthode d'authentification 
                           facultative. 

id_dsa                     contient l'identité d'authentification 
                           DSA de l'utilisateur. 
id_dsa.pub                 la clé DSA publique de l'utilisateur. 
id_rsa                     la clé RSA publique utilisée par sshd pour
                           la version 2 du protocole SSH. 
identity                   la clé RSA privée utilisée par sshd pour la 
                           version 1 du protocole SSH. 
known_hosts                ce fichier contient les clés hôte DSA des
                           serveurs SSH auxquels l'utilisateur s'est connecté. 

Exemple sur une machine :

mlx@M1:~$ ls -al .ssh/
total 16
drwx------   2 mlx mlx     4096 Jan 16  2004 ./
drwxr-xr-x   5 mlx mlx     4096 Oct 18 16:12 ../
-rw-------   1 mlx mlx     1192 Mar 11  2004 authorized_keys2
-rw-------   1 mlx mlx      240 Jan 16  2004 known_hosts

9.3.1. Premiers pas

L'idée est de mettre en place une procédure entre un client et un serveur qui garantit des transactions sécurisées. À la fin, vous pourrez utiliser les ressources du serveur distant dans un tunnel, sans avoir à vous authentifier à chaque fois.

Pour ceux qui ont déjà utilisé les commandes rlogin, rsh, rcp... et les fichiers .rhosts, le principe est identique. La différence fondamentale est que, avec ssh, tout est encrypté.

Pour cela vous devez mettre en place les clés qui serviront à ssh pour vous authentifier. Concrètement cela consiste à définir une paire de clés, une publique que vous mettrez sur le serveur distant, une privée que vous conserverez sur votre machine.

La première chose à faire est de vous créer une clé. Voyons comment réaliser cela.

Tout d'abord allez dans votre répertoire personnel.

$ cd
$ ssh-keygen -t dsa
$ ssh-keygen -t dsa
Generating public/private dsa key pair.
Enter file in which to save the key (/home/mlx/.ssh/id_dsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/mlx/.ssh/id_dsa.
Your public key has been saved in /home/mlx/.ssh/id_dsa.pub.
The key fingerprint is:
5c:d9:d8:c5:3d:8d:0b:10:33:42:9c:83:45:a1:d0:61 mlx@neptune.foo.org

Vérification de .ssh Attention il y a un "." devant ssh

[mlx@neptune mlx]$ ls -alR .ssh
.ssh:
total 20
drwx------    2 mlx      mlx          4096 nov 11 18:19 ./
drwx--x--x   37 mlx      mlx          4096 nov 11 18:09 ../
-rw-------    1 mlx      mlx           736 nov 11 18:19 id_dsa
-rw-r--r--    1 mlx      mlx           616 nov 11 18:19 id_dsa.pub
-rw-r--r--    1 mlx      mlx          1956 nov 10 19:38 known_hosts

Si vous voulez générer une clé RSA2, utilisez l'option "-t rsa" et pour du RSA1 "-t rsa1". Vous devrez entrer une "passphrase". Entre 10 et 30 caractères. Mélangez majuscules, minuscules et chiffres. La clé privée doit ensuite être mise en lecture seule pour le propriétaire et aucun accès pour les autres.

Pour modifier votre "passphrase" sur une clé privée DSA, utilisez la commande :

M0:$ ssh-keygen -p -f ~/.ssh/id_dsa
Enter old passphrase:
Key has comment '/home/mlx/.ssh/id_dsa'
Enter new passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved with the new passphrase.

Attention, on oublie pas une "passphrase". Il va falloir maintenant copier la clé publique vers le ou les serveurs distants. Il est préférable que vous ayez un compte, sinon vous devrez demander à l'administrateur distant de réaliser la procédure.

La clé publique, doit être copiée sur le serveur distant dans ~/.ssh/authorized_keys. La clé privée reste sur votre client. Vous pouvez mettre plusieurs clés publiques sur le serveur, si vous le souhaitez ou si vous accédez au serveur avec plusieurs comptes d'accès différents.

Copiez la clé avec scp sur le compte que vous avez sur le serveur :

MO:$ cat .ssh/id_dsa.pub | ssh mlx@M1.foo.org \
                   "cat - >>.ssh/authorized_keys[2]"
# Attention, sur certaines machines, le fichier se nomme
# authorized_keys, sur d'autres authorized_keys2
# Dasn l'exemple qui est donné, le répertoire .ssh doit exister.

Warning: Permanently added 'M1.foo.org' (RSA) to the list of known hosts.
mlx@M1.foo.org's password:

Elle est transférée. On doit pouvoir maintenant réaliser des opérations (commandes) comme scp sur le serveur distant, sans avoir à saisir de mot de passe. Ici on va faire un "ls", sans ouvrir de session sur la machine distante.

M0:$ ssh mlx@M1.foo.org ls
Enter passphrase for key '/home/mlx/.ssh/id_dsa':
d1
d2
d3
d4

Ça marche, le système distant ne me demande plus mon mot de passe, par contre il me demande la "passphrase". Il va falloir aussi essayer de se passer de ça, car s'il est fastidieux de saisir son mot de passe, il est encore plus embêtant de saisir une "passphrase". Nous verrons comment se passer de ça avec un agent.

Remarque : Envoyer une clé par mail n'est pas un système sûr, et même chiffré et signé cela ne garantit pas au destinataire que vous en êtes l'émetteur s'il ne vous a jamais vu. L'administrateur distant peut demander à ce que l'envoyeur justifie qu'il est bien celui qui a envoyé la clé. Il suffit pour cela de téléphoner à l'administrateur et de communiquer "la signature ou empreinte" (finger print) de la clé (ou par sms). On utilise le même procédé pour identifier et vérifier la validité des clés gpg.

Pour obtenir le "finger print" d'une clé utiliser la commande :

M0:$ ssh-keygen -l
Enter file in which the key is (/home/mlx/.ssh/id_rsa): .ssh/id_dsa
1024 5c:d9:d8:c5:3d:8d:0b:10:33:42:9c:83:45:a1:d0:61 .ssh/id_dsa.pub
M0:$ ssh-keygen -l
Enter file in which the key is (/home/mlx/.ssh/id_rsa): .ssh/id_dsa.pub
1024 5c:d9:d8:c5:3d:8d:0b:10:33:42:9c:83:45:a1:d0:61 .ssh/id_dsa.pub

9.3.2. Utiliser un agent ssh

L'utilisation d'un agent, évite d'avoir à retaper la "passphrase" à chaque fois que l'on sollicite l'utilisation de la clé privée. Un agent stocke en mémoire les clés privées. Voici comment activer un agent :

M0:$ ssh-agent

La commande met sur la sortie standard des variables environnement à déclarer et à exporter. Faites le.

M0:$ SSH_AUTH_SOCK=/tmp/ssh-XXXB76f4/agent.2888; export SSH_AUTH_SOCK;
M0:$ SSH_AGENT_PID=2889; export SSH_AGENT_PID;
M0:$ echo Agent pid 2889;

On va maintenant exporter les clés. Cela consiste à les mettre dans le cache de l'agent avec la commande ssh-add. La commande demandera la "passphrase"..

M0:$ ssh-add
Enter passphrase for /home/mlx/.ssh/id_dsa:
Identity added: /home/mlx/.ssh/id_dsa (/home/mlx/.ssh/id_dsa)

On vérifie maintenant la connexion.

M0:$ ssh mlx@M1.foo.org ls
d1
d2
d3
d4

Ça marche, nous n'avons plus besoin de taper le mot de passe, ni la "passphrase". Pour supprimer une clé (ici RSA) de l'agent, utilisez l'option "-d"

M0:$ ssh-add -d ~/.ssh/id_rsa

Utilisez l'option -D pour supprimer toutes les clés de l'agent.
Utilisez l'option -l pour savoir quelles clés sont chargées par l'agent.

9.3.3. Automatisation dans X

Cela peut être automatisé dans un script.

"ssh-agent" est un daemon dont le but est d'intercepter la clé publique lorsque le programme "ssh-add" la lit après avoir demandé la passphrase. "ssh-agent" doit ensuite transmettre la clé aux processus dont il est le "père" du point de vue du système. "ssh-agent" fait bénéficier les processus fils (fork) de ses propriétés.

Pour étendre cela aux session X, si vous lancez l'interface graphique manuellement, cela deviendra par exemple :

M0:$ ssh-agent xinit
ou 
M0:$ ssh-agent startx

Cela peut aussi être fait dans le fichier startx ou bien ~/.xinitrc ou bien ~/.xsession, en résumé avant le lancement de votre gestionnaire de fenêtres. Par exemple, si c'est le fichier ~/.xinitrc qui lance le gestionnaire de fenêtres, il ressemblera à ceci:

#!/bin/sh

ssh-agent -s > /tmp/ssh.keys    # pour y mettre les variables environnement
.  /tmp/ssh.keys                # Exporter les variables
rm  /tmp/ssh.keys               # Faire le ménage après
startx	

Une autre solution consiste à mettre dans son .xinit ou .xsession :

/usr/local/bin/ssh-add $HOME/.ssh/id_dsa < /dev/null

Pour les sessions xdm par exemple, modifier les fichiers de démarrage :

#Au début de /etc/X11/Xsession: 
AGENT=$(type -p ssh-agent)
if [ -x "$AGENT" -a -z "$SSH_AUTH_SOCK" ]; then
    if [ -r $HOME/.ssh/identity -o -r $HOME/.ssh2/identification \
            -o -r $HOME/.ssh/id_dsa -o -r $HOME/.ssh/id_rsa ]; then
        SSH_AGENT="$AGENT --"
    fi
fi

9.4.1. Redirection locale de port (-L Local)

Si on considère ces 3 machines : M0, la machine cliente, M1 et M2, des serveurs. La syntaxe de la commande est la suivante :

ssh -L port-local:HOSTNAME:port-distant machine-distante

M0:$ ssh -L 1234:HOSTNAME:80 M1

La commande ouvre une connexion entre le M0:1234 vers HOSTNAME:80 en utilisant le serveur sshd M1:22 (actif sur M1 et sur le port 22). Tout dépend de la valeur que va prendre HOSTNAME. HOSTNAME indique la machine distante sur lequel s'opére la connexion.

Si HOSTNAME est localhost :

M0:$ ssh -L 1234:localhost:80 M1

Si HOSTNAME est M1 :

M0:$ ssh -L 1234:M1:80 M1 :-/

Si HOSTNAME est M0 :

M0:$ ssh -L 1234:M0:80 M1

Si HOSTNAME est M2 :

M0:$ ssh -L 1234:M2:80 M1

Les redirections de ports ne sont accessibles en théorie que pour les processus locaux (localhost) (pour nous M0). Si la redirection était possible pour des clients (MX ou MY) ou des requêtes distantes qui viendraient se connecter su rM0:1234 dans notre exemple, ces clients pourraient être surpris de se voir re-routés. (Sans parler de risques pour la sécurité car cela signifie que d'autres personnes pourraient utiliser à notre insu le tunnel que nous venons de créer. Prenons un exemple :

MO$ ssh -L 1234:M1:80 M1

Il est possible toutefois de passer outre avec l'option '-g' qui autorise des clients distants à se connecter à des ports locaux redirigés.

MO$ ssh -g -L 1234:M2:80 M1

La commande "lynx http://M0:1234" lancé à partir d'une machine tierce (MX ou MY) redirigera vers M2:80.

Une utilisation de cette fonction sera vue en application un peu plus loin.

9.4.2. Redirection distante de ports (-R Remote)

Ici le client ssh et le serveur TCP sont du même côté. La syntaxe de la commande est la suivante :

ssh -R port-distant:HOSTNAME:port-local  machine-distante

On reprend les mêmes machines que précédemment :

M0:$ ssh -R 1234:HOSTNAME:80 M1

Si HOSTNAME est localhost, alors on a :

M0:$ ssh -R 1234:localhost:80 M1

Si HOSTNAME est M2, on a :

M0:$ ssh -R 1234:M2:80 M1

Enfin dernière remarque, il est possible de passer en paramètre le compte à utiliser sur le serveur qui fait tourner le serveur sshd.

Cette option permet par exemple de donner, à des machines distantes, un accès à un service sur une machine inaccessible autrement.

9.4.3. Schéma de redirection distante de ports

9.4.4. Exemple de cas d'utilisation

SSH permet de "tunneler" des protocoles applicatifs via la retransmission de port. Lorsque vous utilisez cette technique, le serveur SSH devient un conduit crypté vers le client SSH.

Cela représente un des plus importants intérêt de SSH. Permettre la création de tunnels "sûrs" pour des protocoles de transports "non sûrs". Ce principe est utilisé pour des applications comme pop, imap, mais également pour des applications X Window.

La retransmission de port mappe (redirige) un port local du client vers un port distant du serveur. SSH permet de mapper (rediriger) tous les ports du serveur vers tous les ports du client.

Pour créer un canal de retransmission de port TCP/IP entre 2 machines qui attend les connexions sur l'hôte local, on utilise la commande suivante :

ssh -L port-local:HOSTNAME:port-distant nomutilisateur@nomhôte

Une fois que le canal de retransmission de port est en place entre les deux ordinateurs, vous pouvez diriger votre client (POP par exemple) pour qu'il utilise le port local redirigé et non plus vers le port distant avec une transmission en clair.

Nous avons bien vu les options '-L' et '-R'. De nombreuses autres options sont utilisables, par exemple :

-L     # Forwarder un port local vers un port distant sur une machine  distante
-R     # Forwarder un port distant vers un port local sur la machine locale
-N     # Ne pas exécuter de commande distante
-f     # Excute le programme en tâche de fond
-l     # Passer en paramètre le login de connexion
-g     # Autoriser des machines distantes à se connecter 
       # sur des ports locaux exportés

Voyons comment créer un tunnel pour le service d'émulation VT par exemple. On va utiliser un port local compris entre 1024 et 65535 qui sont réservés pour des applications utilisateurs. On va prendre par exemple le port local 1025. Pour créer un tunnel on va utiliser la commande :

M0:$  ssh -L 1025:localhost:23 mlx@M1.foo.org

On crée ici un tunnel entre le port local 1025 et le port distant 23. Le tunnel étant créé il ne reste plus qu'à utiliser le port local 1025 avec un telnet adresse_de_la_machine 1025

Le fait de quitter ssh ferme la session tunnelée.

Il est également possible d'ouvrir une session temporaire pour un temps donné. Cela évite d'avoir à fermer les connexions. Dans la commande :

M0:$  ssh -f  -L 1025:localhost:23 mlx@M1.foo.org sleep 10

L'option -f, met ssh en tâche de fond. La session sera fermée automatiquement au bout du temps déterminé, seulement si aucun processus n'utilise le canal à ce moment.

Le principe peut être appliqué à d'autres services. Voici comment utiliser un canal sécurisé vers une application (ici un webmail) qui ne l'est pas. (En fait dans la réalité, je vous rassure, l'application présentée sur l'image offre toutes les options de connexion en mode sécurisé. L'exemple donné est pris pour illustrer le propos.

# On crée un tunnel entre le port local et le webmail en utilisant 
# le compte mlx@foo.org
M0:$ ssh  -N -f -L 2038:M1:80 mlx@foo.org

On peut également sans risque aller sur sa zone public_html en toute sécurité.

lynx http://localhost:2038/~mlx

Avec la machine sur lequel le test est réalisé, les commandes :

M0:$ ssh  -N -f -L 2038:M1:80 mlx@foo.org
et 
M0:$ ssh  -N -f -L 2038:localhost:80 mlx@foo.org

En effet :

M0:$ ssh  -N -f -L 2038:M1:80 mlx@foo.org

M0:$ ssh  -N -f -L 2038:localhost:80 mlx@foo.org

De la même façon, on peut l'utiliser pour une session ftp.

M0:$ ssh  -N -f -L 2039:M1:21 mlx@foo.org
M0:$ ftp localhost 2039
Connected to localhost.
220 ProFTPD 1.2.5rc1 Server (Debian) [M1]
Name (localhost:mlx): mlx
331 Password required for mlx.
Password:
230 User mlx logged in.
Remote system type is UNIX.
Using binary mode to transfer files.

9.4.5. X and Port Forwarding

Le déport d'application graphique fonctionne sur le même principe. Le client (/etc/ssh/ssh_config), doit avoir l'option "X11Forward" activée pour les systèmes distants. Le serveur (/etc/ssh/sshd_config), doit avoir l'option "X11Forwarding" d'activée. Il est possible de tunneler des applications graphiques dans ssh.

# Sur le client /etc/ssh/ssh_config
ForwardX11 yes

# Sur le serveur /etc/ssh/sshd_config
X11Forwarding yes

M0:$  ssh -C  mlx@M1.foo.org
Enter passphrase for key '/home/mlx/.ssh/id_dsa':
M0:$ xclock &
[1] 7771

Vous pouvez tout mettre sur la même ligne de commande, avec l'option "-f", qui "fork" l'application demandée.

M0:$  ssh -C -f  mlx@M1.foo.org xclock

9.4.6. Automatisation de tâches SSH

Dans la mesure où il est possible de passer des commandes à distances sur un serveur, sans avoir à saisir de mot de passe ou de "passphrase", on peut envisager l'automatisation de tâches entre machines et dans des tunnels, comme par exemple les sauvegardes ou la synchronisation de fichiers. Il suffira pour cela de créer un compte associé à la tâche, lui créer une clé privée et exporter sa clé publique sur les différentes machines.

Attention toutefois, les manipulations sur les serveurs requièrent un accès root. Cela signifie que votre compte opérateur, devra avoir un accès root sur le serveur ce qui n'est jamais très bon.

Vous aurez intérêt à réfléchir à la façon de réaliser le traitement sans que ce compte opérateur ait besoin du compte "super utilisateur".

Si vous avez un serveur ayant un dm (Desktop Manager) comme gdm par exemple, disponible sur le réseau vous pouvez lancer les émulations X Window des clients en appelant le serveur. Par exemple sur le client faire :

X -query x.y.z.t :u
ou encore 
X -broadcast :u

9.5.1. Proxy HTTP

Vous êtes sur un réseau avec un accès extérieur limité. Pas d'accès http :-(

Vous devez disposer d'une machine à l'extérieur sur laquelle tourne un serveur ssh et un proxy Squid par exemple.

Par défaut Squid utilise le port 3128. On met tout d'abord les autorisations à Squid afin qu'il accepte nos requêtes, sinon elles seront rejetées. (Voir les ACL du fichier /etc/squid.conf). Si vous êtes pressés un "http_access allow all" est brutal, mais ça marche ;-) Nous allons créer un tunnel vers ce service de la machine locale vers la machine distante sur le port 3128.

ssh  -N -f -L 3128:M1:3128 mlx@M1

Cette configuration présente une limitation. Vous ne pouvez utiliser le proxy qu'à partir de la machine sur laquelle vous avez créé le tunnel (M0).

Si vous êtes mobile dans votre entreprise et que vous souhaitez accéder à l'extérieur à partir d'autres machines, ou encore que vous voulez laisser cet accès à des amis qui utilisent le même réseau que vous, il faut procéder autrement.

ssh  -g -N -f -L 3128:M1:3128 mlx@M1

Si vous souhaitez par contre ouvrir le service de votre proxy à d'autres amis mais pouvant être dans d'autres boîtes ou sur d'autres réseaux, cela se complique un peu, car chacun d'eux doit pouvoir créer un tunnel vers votre proxy. Il faut donc, sur votre proxy créer plusieurs ports d'écoute pour les tunnels et rediriger tout ça vers votre proxy.

ssh -N -f -g -L 3130:localhost:3128 mlx@localhost
ssh -N -f -g -L 3131:localhost:3128 mlx@localhost
etc... etc...

MY$ ssh  -g -N -f -L 3128:localhost:3130 mlx@M1
MZ$ ssh  -g -N -f -L 3128:localhost:3130 mlx@M1

Si vous ne souhaitez rediriger les requêtes que pour une machine (site web) en particulier vous pouvez créer un tunnel de la façon suivante :

M0:$ ssh  -N -f -L 3128:SITEWEB:3128 mlx@M1

Remarque, dans le navigateur vous pouvez taper tout ce que vous voulez (yahoo, wanadoo, google...) vous arriverez toujours sur SITEWEB.

9.5.2. Autres scénarios

Si vous avez compris le principe pour le processus décrit ci-dessus, vous pouvez l'appliquer pour tous les autres services (messagerie pop ou imap, news, cvs, vnc ...).

Si un admin faisait trop de rétorsion, ne dites plus rien, vous savez maintenant comment vous y prendre.

9.7.1. Utilisation de scp

La commande

M0:$ ssh mlx@M1.foo.org "ls -al psionic"

-rw-r--r--    1 root     root        64562 Nov 23 23:05 hostsentry-0.02-4.noarch.rpm
-rw-r--r--    1 root     root        26955 Nov 23 23:05 logsentry-1.1.1-1.i386.rpm
-rw-r--r--    1 root     root        48804 Nov 23 23:06 portsentry-1.1-fr7.i386.rpm
-rw-r--r--    1 root     root        48804 Nov 23 23:13 portsentry-1.1-fr7.i386.rpm.1

La commande :

ssh mlx@M1.foo.org "ls -al"

cd && mkdir psionic 
scp mlx@M1.foo.org:/home/mlx/psionic/* ~/psionic

scp ~/psionic/* mlx@foo.org:/home/mlx/tmp

9.7.2. Utilisation de sftp

sftp peut être utilisé pour du transfert de fichiers en mode sécurisé.

sftp  mlx@M1.foo.org
sftp> 

On obtient un prompt, ici le système ne m'a pas demandé de m'authentifier. Pour avoir une liste des commandes, utiliser "help".

sftp> help
Available commands:
cd path	                    Change remote directory to 'path'
lcd path                    Change local directory to 'path'
chgrp grp path              Change group of file 'path' to 'grp'
chmod mode path             Change permissions of file 'path' to 'mode'
chown own path              Change owner of file 'path' to 'own'
help                        Display this help text
get remote-path [local-path]Download file
lls [ls-options [path]]     Display local directory listing
ln oldpath newpath          Symlink remote file
lmkdir path                 Create local directory
lpwd                        Print local working directory
ls [path]                   Display remote directory listing
lumask umask                Set local umask to 'umask'
mkdir path                  Create remote directory
put local-path [remote-path]Upload file
pwd                         Display remote working directory
exit                        Quit sftp
quit                        Quit sftp
rename oldpath newpath      Rename remote file
rmdir path                  Remove remote directory
rm path                     Delete remote file
symlink oldpath newpath     Symlink remote file
version	                    Show SFTP version
!command                    Execute 'command' in local shell
!                           Escape to local shell
?                           Synonym for help

10.3.1. Première étape : configuration de SSH

La première chose à faire est de mettre en place un moyen de lancer le daemon pppd chaque fois que vous voudrez mettre en place un VPN entre votre client et le serveur. Il y deux solutions. Soit vous créez un compte spécifique sur le serveur (ce que nous allons faire), et qui aura en charge de lancer le daemon, soit vous utilisez votre propre compte. Dans un cas comme dans l'autre, la procédure est très similaire.

Sur le serveur, créez un compte VPN :

adduser --disabled-password vpn

serveur# visudo /etc/sudoers
# Ajoutez la ligne suivante
vpn     ALL=NOPASSWD:/usr/sbin/pppd

Comme la liaison sera chiffrée dans un tunnel SSH, il est nécessaire de mettre également un moyen qui permette cela le plus simplement possible. Cela est réalisé par un système de clé publique et privée. Si vous n'en avez pas vous pouvez vous en créer une. Ne mettez pas de mot de passphrase (vous faites entrée, ce n'est pas vraiment utile. Vous êtes sur le client :

[client]$ ssh-keygen -t dsa
Generating public/private dsa key pair.
Enter file in which to save the key (/client/.ssh/id_dsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /client/.ssh/id_dsa.
Your public key has been saved in /client/.ssh/id_dsa.pub.
The key fingerprint is:
c5:a5:90:b2:19:9d:bf:3a:0b:c9:64:f7:98:1e:e0:dc client@mr

Vous avez la clé publique et la clé privée sur le client, dans votre répertoire personnel et dans le sous-répertoire ".ssh". Il vous faut copier la clé publique sur le serveur.

scp .ssh/id_dsa.pub VotreCompteSurLeServeur@serveur:

Maintenant il ne reste plus qu'à déclarer cette clé publique comme valide et utilisable par le compte "VPN". Vous êtes sur le serveur.

serveur# mkdir -p /home/vpn/.ssh
serveur# cat /home/VotreCompteSurLeServeur/id_dsa.pub >> \
         /home/vpn/.ssh/authorized_keys2
serveur# chmod 700 /home/vpn/.ssh &&  chmod 600 /home/vpn/.ssh/authorized_keys2

Normalement vous devriez pouvoir vous connecter à partir du client sur le serveur en utilisant le compte VPN sans entrer de mot de passe.

[client]$ ssh -l vpn serveur

Si cela ne fonctionne pas, et que le serveur sshd est actif, vérifiez que vous n'avez pas commis d'erreur de manipulation. Reprenez bien la procédure.

Si le serveur vous demande un mot de passe et que l'accès fonctionne en mettant un mot de passe, c'est que vous avez saisi une "passphrase". Utilisez ssh-agent et ssh-add pour ne plus avoir à sasir de mot de passe.

Si tout fonctionne, c'est terminé.

Si d'autres personnes veulent mettre en place des VPN sur le serveur, il suffit de rajouter leurs clés publique dans le fichier authorized_keys2.

Si vous ne voulez pas utiliser de compte "VPN" ou autre mais le vôtre, il suffit de modifier le fichier sudoers en mettant votre compte à la place de "vpn".

10.3.2. Test de la connexion

Il faut maintenant pouvoir activer et/ou désactiver le VPN à la demande. Nous allons pour cela, utiliser un script que vous pourrez adapter.

#!/bin/sh
# /usr/local/bin/vpn-pppssh
#
# This script initiates a ppp-ssh vpn connection.
# see the VPN PPP-SSH HOWTO on http://www.linuxdoc.org for more information.
#
# revision history:
# 1.6 11-Nov-1996 miquels@cistron.nl
# 1.7 20-Dec-1999 bart@jukie.net
# 2.0 16-May-2001 bronson@trestle.com


#
# You will need to change these variables...
#


# The host name or IP address of the SSH server that we are
# sending the connection request to:
SERVER_HOSTNAME=serveur.votredomaine.org

# The username on the VPN server that will run the tunnel.
# For security reasons, this should NOT be root.  (Any user
# that can use PPP can intitiate the connection on the client)
SERVER_USERNAME=vpn

# The VPN network interface on the server should use this address:
SERVER_IFIPADDR=192.168.0.1

# ...and on the client, this address:
CLIENT_IFIPADDR=192.168.0.2


# This tells SSH to use unprivileged high ports, even though it's
# running as root.  This way, you don't have to punch custom holes
# through your firewall.
LOCAL_SSH_OPTS="-P"


#
# The rest of this file should not need to be changed.
#



PATH=/usr/local/sbin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/bin/X11/:

#
# required commands...
#

PPPD=/usr/sbin/pppd
SSH=/usr/bin/ssh

if ! test -f $PPPD  ; then echo "can't find $PPPD";  exit 3; fi
if ! test -f $SSH   ; then echo "can't find $SSH";   exit 4; fi


case "$1" in
  start)
    echo -n "Starting vpn to $SERVER_HOSTNAME: "
# Modifier les 3 lignes ci-dessous afin d'ôter les \ et les CR/LF
    ${PPPD} updetach noauth passive pty "${SSH} ${LOCAL_SSH_OPTS}\
    ${SERVER_HOSTNAME} -l${SERVER_USERNAME} sudo ${PPPD} nodetach\
    notty noauth" ipparam vpn ${CLIENT_IFIPADDR}:${SERVER_IFIPADDR}
    echo "connected."
    ;;

  stop)
        # echo -n "Stopping vpn to $SERVER_HOSTNAME: "
# Modifier les 2 lignes ci-dessous afin d'ôter les \ et les CR/LF
        PID=`ps ax | grep "${SSH} ${LOCAL_SSH_OPTS}  ${SERVER_HOSTNAME}\
            -l${SERVER_USERNAME}"| grep -v ' passive ' | grep -v 'grep '\
            | awk '{print $1}'`
        if [ "${PID}" != "" ]; then
          kill $PID
          echo "Kill $PID, disconnected."
        else
          echo "Failed to find PID for the connection"
        fi
    ;;

  config)
    echo "SERVER_HOSTNAME=$SERVER_HOSTNAME"
    echo "SERVER_USERNAME=$SERVER_USERNAME"
    echo "SERVER_IFIPADDR=$SERVER_IFIPADDR"
    echo "CLIENT_IFIPADDR=$CLIENT_IFIPADDR"
  ;;

  *)
    echo "Usage: vpn {start|stop|config}"
    exit 1
    ;;
esac

exit 0

Pour l'utiliser, il suffit de faire un "./vpn start". Si vous obtenez quelque chose proche de cela, c'est que votre vpn est bien créé.

[root]# ./vpn-pppssh start
Starting vpn to serveur: Using interface ppp0
Connect: ppp0 <--> /dev/pts/1
Looking for secret in /etc/ppp/pap-secrets for client mr server (null)
Looking for secret in /etc/ppp/chap-secrets for client mr server (null)
Deflate (15) compression enabled
local  IP address 192.168.0.2
remote IP address 192.168.0.1
connected.

Sur le client et sur le serveur, les interfaces ppp0 doivent être actives :

# Sur le client, ifconfig
ppp0      Lien encap:Protocole Point-à-Point
          inet adr:192.168.0.2  P-t-P:192.168.0.1  Masque:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:126 errors:0 dropped:0 overruns:0 frame:0
          TX packets:102 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 lg file transmission:3
          RX bytes:10139 (9.9 Kb)  TX bytes:9029 (8.8 Kb)

# Sur le serveur, ifconfig
ppp0      Lien encap:Protocole Point-à-Point
          inet adr:192.168.0.1  P-t-P:192.168.0.2  Masque:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:102 errors:0 dropped:0 overruns:0 frame:0
          TX packets:126 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 lg file transmission:3
          RX bytes:9029 (8.8 KiB)  TX bytes:10139 (9.9 KiB)

Le protocole a installé les routes de ces interfaces et qui viennent compléter celles déjà existantes :

# Sur le client :
[Client]# route -n
Table de routage IP du noyau
Destination     Passerelle      Genmask         Indic Metric Ref    Use Iface
192.168.0.1     0.0.0.0         255.255.255.255 UH    0      0      0 ppp0



# Sur le serveur
Table de routage IP du noyau
Destination     Passerelle      Genmask         Indic Metric Ref    Use Iface
192.168.0.2     0.0.0.0         255.255.255.255 UH    0      0       0 ppp0

Sur le client, les commandes :

ping 192.168.0.1
ping 192.168.0.2

11.1.1. Avant de démarrer

Vous devez connaître la classe d'adresse de votre réseau. Vous devez connaître également les adresses des hôtes que vous voulez adresser ainsi que leurs noms d'hôtes.

11.1.2. Fiche de cours

Dans un réseau, on assigne généralement un nom à chaque hôte. Le terme d'hôte est pris dans son sens large, c'est à dire un " noeud de réseau ". Une imprimante, un routeur, un serveur, un poste de travail sont des noeuds qui peuvent avoir un nom d'hôte, s'ils ont une adresse IP.

On parle de " nom d'hôte " sur les réseaux qui utilisent le protocole TCP/IP. Ne pas confondre le " nom d'hôte " avec le " nom Netbios " qui est utilisé sur les réseaux Microsoft™ ou IBM.

Le nom d'hôte est assigné à un noeud qui est configuré avec une adresse IP. Le nom permet d'adresser le noeud, autrement qu'avec l'adresse IP. Par exemple, si le réseau est équipé d'un serveur d'adresse 192.68.0.100 et dont le nom d'hôte est srv1, il sera alors possible de saisir les commandes suivantes :

telnet 192.68.0.100 ou bien

telnet srv1

Le nom sert de mnémonique, qui évite de retenir toutes les adresses IP du réseau. Le protocole TCP/IP se charge de la résolution des noms d'hôtes, ensuite le protocole ARP, se charge de la résolution des adresses IP en adresses MAC (Ethernet le plus souvent).

Pour que la résolution de nom fonctionne, il faut déclarer dans un fichier tous les noms d'hôtes, et pour chaque nom, son adresse IP. Cette déclaration est réalisée dans le fichier /etc/hosts.

Le processus de résolution équivalent peut être mis en oeuvre sur des réseaux qui utilisent Windows 9x, Windows NT Server, Windows NT Workstation. Vous devrez alors créer les fichiers respectivement dans les répertoires Windows et winnt\system32\drivers\etc. Vous trouverez dans ces répertoires, si TCP/IP est installé un fichier host.sam qui peut vous servir d'exemple

12.2.1. Présentation de l'environnement

• le binaire apachectl est dans /usr/sbin,

• les fichiers de configuration sont dans /etc/apache/

• la documentation est dans /usr/share/doc

• Le script de lancement du service serveur dans /etc/init.d

• Les journaux sont dans /var/log/apache/

Faites une copie de sauvegarde des fichiers de configuration avant toute manipulation.

12.2.2. Installation d'un service minimum

Ce paragraphe décrit les principaux paramètres pour mettre en place un service HTTP minimum, avant de lancer le service serveur. Vous utiliserez le fichier de configuration d'Apache httpd.conf.

• port 80, indique quel est le port utilisé par le service (par défaut 80). Il est possible d'utiliser un autre port, par contre vous devrez spécifier au navigateur quel est le port utilisé par le serveur. Si vous configurez par exemple le port 8080 sur une machine www.MonDomaine.edu, vous devrez spécifier dans le navigateur www.MonDomaine.edu:8080, pour que le serveur reçoive et traite votre requête.

• user www-data et group www-data, spécifient le compte anonyme utilisé par le serveur une fois qu'il est lancé. En effet, pour accéder aux ports inférieurs à 1024, le serveur utilise un compte administrateur, ce qui présente des dangers. Une fois le processus actif, il utilisera l'UID d'un autre compte (ici nobody). Ce compte doit pouvoir lire les fichiers de configuration et ceux de la racine du serveur HTTP. D'autres distributions utilisent le compte " nobody " ou " apache "

• ServerAdmin root@localhost, précise quel est le compte qui reçoit les messages. Par défaut le compte administrateur sur la machine locale (à modifier pour une adresse comme root@MonDomaine.edu).

• ServerRoot /etc/apache, indique l'adresse du répertoire racine du serveur, où sont stockés les fichiers de configuration du serveur HTTP. Cette adresse peut être modifiée.

• ErrorLog, fichier error_log, journalisation des erreurs. L'adresse est calculée à partir de ServerRoot. Si ServerRoot est /etc/httpd et ErrorLog logs/error_log, le chemin complet est /var/log/apache/logs/error_log.

• ServerName www.MonDomaine.edu, indique le nom ou l'alias avec lequel la machine est désignée. Par exemple, l'hôte ns1.MonDomaine.edu, peut avoir le nom d'alias www.MonDomaine.edu. Voir la résolution de nom avec un DNS.

• DocumentRoot /var/www, indique l'emplacement par défaut des pages HTML quand une requête accède au serveur. (exemple : la requête http://www.MonDomaine.edu/index.html pointe en fait sur le fichier local /home/httpd/html/index.html).

• ScriptAlias  /cgi-bin/ /usr/lib/cgi-bin, de la forme "ScriptAlias FakeName RealName", indique où sont physiquement situés les scripts sur le disque, ainsi que l'alias utilisé par les développeurs pour le développement des scripts et des pages. Un développeur utilisera un lien (exemple : /cgi-bin/NomDuScript où /cgi-bin/ est un alias sur /home/httpd/cgi-bin/), et c'est le script /home/httpd/cgi-bin/NomDuScript qui sera effectivement exécuté. La mise en place d'alias permet de restructurer ou déplacer un serveur sans avoir à modifier toutes les pages développées.

• UserDir public_html, ce paramètre décrit le processus utilisé pour accéder aux pages personnelles d'une personne, si ces pages sont stockées dans son répertoire personnel. Supposons que vous êtes l'utilisateur "bestof" du réseau et que vous ayez des pages personnelles. Il sera possible d'accéder à vos pages, avec l'adresse suivante:  www.MonDomaine.edu/~bestof/index.html. Le (tilde "~") permet d'accéder à votre répertoire personnel. La requête sera réellement exécutée sur "/home/bestof/public_html/index.html.

  Attention, vérifier que le répertoire personnel ne soit pas en mode 700, car personne ne pourrait accéder aux pages personnelles.

• Alias /CheminVu/ /CheminRéel/, par exemple : "/icons/ /usr/share/apache/icons/", ce paramètre permet de renommer, à la manière d'un lien logique, un emplacement physique avec un nom logique.

  Exemple: vous voulez que www.MonDomaine.edu/test/index.html, ne corresponde pas physiquement à un répertoire sur la racine du serveur HTTP mais à un emplacement qui serait /usr/local/essai. Vous pouvez mettre dans le fichier de configuration d'Apache un alias de la forme: alias /test/ /usr/local/essai/

• DirectoryIndex donne le ou les noms des fichiers que le serveur doit rechercher si le navigateur passe une requête sur un répertoire. Par exemple sur une requête http://www.MonDomaine.edu, le serveur va rechercher dans l'ordre s'il trouve un fichier index.html, index.stml, index.cgi... en fonction des paramètres de cette variable.

• Les fichiers .htaccess : Apache permet de sécuriser les accès répertoire par répertoire. Il est possible de définir, le nom du fichier qui contiendra les possibilités d'accès par un utilisateur à un répertoire donné. Par défaut la valeur est .htaccess. Ce paramètre est modifiable.

• Limitations de la sécurité par répertoire: ce procédé alourdit la charge du serveur. En effet, si une requête est passée sur www.MonDomaine.edu/rep1/rep2/index.html, le serveur va vérifier dans chaque répertoire rep1, rep2... l'existence d'un fichier .htaccess. Ce sont les règles du dernier fichier qui seront appliquées. Ce processus est mis en oeuvre pour chaque accès. Cette directive est donc à utiliser avec beaucoup de parcimonie car elle crée une surcharge pour le serveur.

  La directive AllowOverride None, permet de désactiver l'utilisation des fichiers .htaccess dans les niveaux inférieurs. La directive AllowOverride peut être utilisée avec d'autres options par exemple: AuthConfig.

  Les fichiers .htaccess peuvent, s'ils sont présents spécifier leurs propres directives d'authentification,

  La directive ExecCGI, permet l'exécution de scripts cgi dans ce répertoire.

• Sécuriser un répertoire en autorisant/refusant l'accès

  Pour chaque répertoire "UnRépertoire", sur lequel on désire avoir une action, on utilisera la procédure suivante:

  <Directory UnRépertoire>
  ...Ici mettre les actions...
  </Directory>
  

  Tout ce qui est entre les balises s'applique au répertoire "UnRépertoire".

  Exemple: On désire autoriser l'accès du répertoire "/intranet" aux machines du réseau d'adresse 192.168.1.0/24 et de nom de domaine MonDomaine.edu, et l'interdire à tous les autres.

  <Directory /intranet>
  #Ordre de lecture des règles
  order allow,deny 
  deny from all 
  allow from 192.168.1 #ou encore allow from .MonDomaine.edu
  </Directory>
  

  Il importe de préciser dans quel ordre les règles de restriction vont être appliquées. Cet ordre est indiqué par le mot réservé " order ", par exemple " order deny,allow " (On refuse puis on alloue l'accès à quelques adresses, c'est à dire que toutes les régles deny vont être lues d'abord, puis ce sera le tour de toutes les règles allow) ou " order allow,deny " (on accepte généralement les accès mais il sont refusés pour quelques adresses : ici, on prend en compte en premier lieu toutes les règles allow dans l'ordre trouvé, puis ensuite toutes les règles deny).

  Exemple: On désire que l'accès soit majoritairement accepté, sauf pour un ou quelques sites.

  <directory /home/httpd/html>
  AllowOverride none
  Order deny,allow
  deny from pirate.com badboy.com cochon.com
  allow from all
  </directory>
  

• Authentifier l'accès à un répertoire : ce procédé va permettre de sécuriser l'accès à un répertoire ou à des fichiers. L'accès sera autorisé à une ou plusieurs personnes ou encore à un ou plusieurs groupes de personnes.

  AuthName, définit ce qui sera affiché au client pour lui demander son nom et son mot de passe,

  AuthType, définit le mode d'authentification et d'encryptage " basic " avec HTTP/0 ou " MD5 " par exemple avec HTTP/1.

  AuthUserFile, définit le fichier qui contient la liste des utilisateurs et des mots de passe. Ce fichier contient deux champs (Nom d'utilisateur, Mot de passe crypté). Vous pouvez créer ce fichier à partir du fichier /etc/passwd (attention ! faille de sécurité. Il n'est pas forcément avisé d'avoir le même mot de passe pour accéder à Linux et pour accéder à un dossier Web) ou avec la commande "htpasswd" d'Apache.

  Exemple du mode d'utilisation de la commande "htpasswd" :

  root@mr:/home# htpasswd --help
          htpasswd [-cmdps] passwordfile username
   -c  Create a new file.
  
  #> htpasswd -c /etc/apache/users mlx
  Ici on crée le fichier /etc/apache/users et on ajoute un compte.
  N'utiliser l'option "-c" que la première fois.
  

  AuthGroupFile définit le fichier qui contient la liste des groupes et la liste des membres de chaque groupe,

  Require permet de définir quelles personnes, groupes ou listes de groupes ont une permission d'accès.

  Exemple de fichier AuthUserFile :

  doudou:zrag FmlkSsSjhaz
  didon:PsddKfdqhgf.fLTER
  

  Exemple de fichier AuthGroupFile :

  users: tintin milou haddock dupond dupont tournesol
  tournesol dupont
  

  Exemple d'autorisation :

  require user tintin dupond /* tintin et dupond ont un accès */
  require group users /* le groupe users à un accès */
  require valid-user /* toute personne existant dans AuthUserFile */
  

  Exemple d'accès sécurisé sur un répertoire :

  <Directory /home/httpd/html/intranet/>
  AuthName PatteBlanche
  AuthType basic
  AuthUserFile /etc/httpd/conf/users
  AutGroupFile /etc/httpd/conf/group
       <Limit GET POST>#Ici il faudra un mot de passe 
  	require valid-user 
       </Limit>
  </Directory>
  

  Voici la fenêtre sécurisée que propose Netscape sur l'URL http://localhost/essai:

  Figure 12-1. Accés sécurisé sur un répertoire par Apache

  

La déclaration d'un accès authentifié sur un répertoire est faite dans le fichier de configuration d'Apache, ou alors en créant un fichier ".htaccess" dans le répertoire que l'on souhaite sécuriser. Le fichier ".htaccess" contient les mêmes directives que celles qui auraient été déclarées dans le fichier httpd.conf.

Attention :

Si vous mettez les clauses d'accès restreint pour un 
répertoire dans le fichier de configuration d'Apache, les clauses
seront incluses entre 2 balises :
<Directory ...>
</Directory ...>

Si vous mettez les clauses de restriction dans un fichier ".htaccess",
vous n'avez pas besoin de mettre ces balises.

12.2.3. Activation du serveur

Utilisez les commandes suivantes pour activer, désactiver le serveur:

/etc/init.d/apache start

/etc/init.d/apache stop

/etc/rc.d/init.d/apache status

Pour relire le fichier de configuration alors qu'apache est déjà lancé, utilisez :

/etc/init.d/apache reload

Pensez dans tous les cas à consulter les journaux afin de détecter les dysfonctionnements.

12.2.4. Test de la configuration

Lancez le navigateur et tapez l'url http://localhost. Vous devriez pouvoir utiliser indifféremment l'adresse IP ou le nom d'hôte de votre machine. Vous devez également pouvoir accéder à partir des autres machines de la salle.

13.2.1. Introduction

Vous allez réaliser les opérations suivantes:

• configurer le serveur HTTP pour qu'il soit activé en mode standalone

• activer le serveur HTTP,

• tester le fonctionnement du serveur

A la fin vous devriez pouvoir accéder sur toutes les machines (serveurs HTTP) du réseau à partir du navigateur client.

Attention Vous utiliserez les éléments donnés dans la fiche de cours.

13.2.2. Configuration du serveur

Vous allez réaliser une configuration de base du serveur. Vous allez donc modifier le fichier httpd.conf. Avant toute modification, faites une copie de sauvegarde des fichiers.

Ouvrez le fichier à l'aide d'un éditeur, relevez et vérifiez les paramètres suivants. Pour chacun de ces paramètres vous noterez leurs rôles à partir des commentaires donnés par les fichiers httpd.conf (pensez à enregistrer vos modifications) :

• ServerName, nom pleinement qualifié de votre serveur (FQDN)

• ServerType standalone

• Port 80

• User $APACHE_USER

• Group $APACHE_GROUP

• ServerAdmin root@localhost

• ServerRoot /etc/apache

• DocumentRoot $APACHE_HOME/html

• UserDir public_html

• DirectoryIndex index.html index.shtml index.cgi

• AccessFileName .htaccess

• Alias /icons/ $APACHE_HOME/icons/

• ScriptAlias /cgi-bin/ $APACHE_HOME/cgi-bin/

13.2.3. Activation du serveur

Regardez dans la fiche de cours les commandes de lancement du service serveur et la procédure de test. Regardez dans les fichiers de log et dans la table de processus si le service est bien démarré. Vérifier avec la commande netstat que le port 80 est bien ouvert.

Notez toutes les commandes que vous utilisez.

13.2.4. Test de la configuration

A ce stade le serveur est configuré et fonctionne. Il ne reste plus qu'à réaliser les tests. Vous devez pour cela activer le navigateur.

Faites les tests à partir de la machine locale et d'une machine distante. Utilisez les adresses localhost, 127.0.0.1, les adresses IP et les noms d'hôtes.

Si tout fonctionne vous êtes en mesure de déployer votre site. Il suffira pour cela de l'installer dans l'arborescence $APACHE_HOME.

Dépannage: si cela ne fonctionne pas, procédez par élimination.

• 1 - Essayez avec les adresses IP des machines. Si ça fonctionne c'est que la résolution de noms n'est pas en place.

• 2 - Vérifiez que votre serveur est bien actif.

• 3 - Vérifiez que la configuration du serveur est correcte. Si vous apportez des modifications vous devez réinitialiser le serveur HTTP.

13.2.5. Auto-évaluation sur le premier TP

• Quels sont le/les fichiers de base pour la configuration du serveur apache et dans quels répertoires sont-ils situés ?

• Comment se nomme le compte d'utilisateur qui utilise le serveur http ?

• Quels sont les permissions d'accès par défaut sur le site principal du serveur ?

• Dans quel répertoire sont installés par défaut les pages HTML du site ?

• Quels sont les deux modes de lancement du serveur ?

• Dans quel fichier détermine-t-on ce mode de fonctionnement ?

• Dans quel répertoire par défaut sont stockés les scripts CGI et quel en est l'alias ?

• Quel est le principal rôle des alias ?

• Quelle(s) procédure(s) peut-on utiliser pour déterminer l'état du serveur et son bon fonctionnement ?

• Vous installez un serveur Apache sur une machine d'adresse 192.168.90.1 et de nom foo.foo.org. Lors des tests sur la machine locale, les commandes http://localhost, http://127.0.0.1, http://192.168.90.1 fonctionnent et http://foo.foo.org ne fonctionne pas. Lors des tests à partir d'une machine distante les commandes http://192.168.90.1 et http://foo.foo.org fonctionnent.

  Que peut-on en déduire et comment résoudre le problème ?

19.2.1. Le chiffrement symétrique

La même clé est utilisée pour coder et décoder et doit bien évidemment rester secrète.

Un algorithme répandu consiste à effectuer des substitutions et des transpositions en cascade sur les lettres du message. Par exemple : MICROAPPLICATION devient IRMCAPOPIALCINTO si l'on fixe comme clé le principe suivant : "la première lettre sera la troisième, la seconde sera la première, la troisième sera la quatrième et la quatrième sera la seconde".

La figure suivante illustre le principe du chiffrement symétrique.

Quelques algorithmes couramment utilisés (liste non exhaustive) :

• Data Encryption Standard (DES) est une invention du National Bureau of Standards (NSB) américain, qui date de 1977 : c'est le premier algorithme de chiffrement publique gratuit. Les données sont découpées en blocs de 64 bits et codées grâce à la clé secrète de 56 bits propre à un couple d´utilisateurs

• RC2, RC4 et RC5 sont des algorithmes créés à partir de 1989 par Ronald Rivest pour la RSA Security. L'acronyme "RC" signifie "Ron's Code" ou "Rivest's Cipher". Ce procédé permet aux utilisateurs la possibilité de choisir la grandeur de la clé (jusqu'à 1024 bits).

• Advanced Encryption Standard (AES) est un standard approuvé par le ministère américain du commerce en 2001 et vise à remplacer le DES ; il est placé dans le domaine public et accepte des clés d'une taille de 128, 192 ou 266 bits.

Les inconvénients de ce système de chiffrement sont les suivants :

• il faut autant de paires de clés que de couples de correspondants ;

• la non-répudiation n´est pas assurée. Mon correspondant possédant la même clé que moi, il peut fabriquer un message en usurpant mon identité ;

• il faut pouvoir se transmettre la clé au départ sans avoir à utiliser le média à sécuriser !

19.2.2. Le chiffrement asymétrique

C'est une approche radicalement différente apparue en 1976 : la clé qui sert à coder est différente de celle qui peut déchiffrer.

La grande nouveauté introduite par cette famille de méthodes, c'est que la clé chiffrante est publique. Cette notion de cryptographie à clé publique résulte d'un défi mathématique lancé par Witfield Diffie et Martin Hellman. Trois mathématiciens américains (Ronald Rivest, Adi Shamir et Leonard Adleman) ont réussi à l'époque à trouver une solution, aujourd'hui employée sous le nom de RSA.

La méthode repose sur un constat très simple : il est facile d'effectuer la multiplication de deux nombres premiers, mais il est très difficile de retrouver les facteurs quand le résultat est grand.

La clé publique est donc constituée du produit n de deux nombres premiers p et q, choisis très grands. La clé secrète dépend directement de p et q et ne peut donc etre déduite de la clé publique.

En résumé, chacun dispose d´une clé privée qui est gardée secrète et d´une clé publique qui est destinée à être divulguée. Ces clés sont liées entre elles. Un document encrypté avec l´une ne peut être décodée qu´avec l´autre. Toutefois, la possession de l´une des clés ne permet pas d´en déduire l´autre.

Un autre algorithme utilisant le système de chiffrage asymétrique largement utilisé est le DSA (Digital Signature Algorithm).

Ce système a réellement permit d'assurer des fonctions essentielles telles que la confidentialité et l'authentification.

19.3.1. Garantir la confidentialité d'un message

Le message ne doit être pouvoir lu que par le destinataire.

Pour ce faire, il suffit de récupérer la clé publique P du destinataire (sur le serveur de clé http://www.keyserver.net/ par exemple) puis de crypter le message avec cette clé publique et d´envoyer le résultat au destinataire.

Le destinataire n´a lui, qu´à décoder le message à l´aide de sa clé privée S. Seule la clé privée S correspondant à la clé publique P peut décoder un message encrypté avec cette clé publique P. Comme le destinataire est seul à posséder cette clé privée (secrète), on est sûr de la confidentialité du message.

La figure suivante illustre le principe de confidentialité :

19.3.2. Authentifier l'émetteur d'un message

le chiffrement asymétrique permet de garantir que l´émetteur d´un message est bien celui que l´on croit. 

L´émetteur va encrypter le message avec sa clé privée. Le destinataire pourra alors vérifier l´identité de l´émetteur en décryptant le message avec la clé publique de l´émetteur. Comme seul le détenteur de la clé privée est capable de crypter un message déchiffrable par la clé publique, on est sûr de l´identité de l´émetteur.

La figure suivante illustre le principe d'authentification :

En pratique, on évite de crypter tout le message. On crypte une forme abrégée du message. Cette forme est obtenue à l´aide d´une fonction mathématique complexe appelée fonction de hachage à sens unique.

C'est ce que l'on apelle la signature électronique.

19.3.3. La signature électronique

La signature électronique permet non seulement d'authentifier l'emetteur d'un message mais aussi de vérifier l'intégrité de ce dernier (c'est à dire qu'il n'a pas été modifié).

Techniquement, la signature électronique correspond au chiffrement de l'empreinte d'un document via la clé privée du signataire.

Selon le glossaire du CNRS (Centre National de la Recherche Scientifique) http://www.dr15.cnrs.fr/Delegation/STI/Signature/glo-empreinte.html : "L'empreinte électronique est à un document ce que l'empreinte digitale ou génétique est à un individu. L'empreinte d'un document a des propriétés très intéressantes :

• si on change, ne serait-ce qu'une virgule, dans un document, son empreinte change ;

• la probabilité que deux documents aient la même empreinte est à peu près nulle ;

• il n'est pas possible de refabriquer le document à partir de son empreinte.

Techniquement, l'empreinte d'un document est le résultat d'un calcul effectué à l'aide d'un algorithme de hachage approprié (SHA (Secure Hash Algorithm) ou MD5 (Message Digest) sont les plus courants). Il génère pour chaque document un nombre de 128 ou 168 bits, que les anglo-saxons appellent "digest" et qu'en français, on appelle parfois résumé..."

Le schéma suivant illustre le mécanisme de la signature électronique.

Si les deux opérations donnent le même résultat, alors on est sûr de l'identité du signataire et on est sûr que le document n'a pas été modifié depuis que l'émetteur l'a signé.

Bien entendu, l'ensemble de ces vérifications se font à l'aide de logiciels dédiés qui effectuent ces opérations très rapidement et de façon très assistée.

19.3.4. Mise en oeuvre

La mise en oeuvre de ces principes dans le cadre d'une messagerie électronique.

Voici des adresses de site sur lequel vous trouverez des documentations complètes très pédagogiques sur l'utilisation du célèbre logiciel PGP et de son pendant libre openpgp (ou GnuGP) ; logiciel très utilisé pour le chiffrement et l'établissement de signature numérique lors d'envoi de mèl. :

• http://www.securiteinfo.com/crypto/pgp.shtml

• http://www.openpgp.fr.st/

• http://www.gnupg.org/gph/fr/manual.html

• Et une documentation complémentaire pour gérer pgp ou gpg à partir de Kmail sous Linux : http://docs.kde.org/fr/HEAD/kdenetwork/kmail/pgp.html

Vous avez tous l'adresse électronique de votre professeur qui a déposé sa clé publique relative à cette adresse sur le serveur de clés (en anglais) http://www.keyserver.net/.

Vous devez la récupérer et envoyer à votre professeur un... gentil... message chiffré et signé par votre propre clé privée ; signature que votre professeur doit pouvoir vérifier...

Votre professeur vous répondra à tous un message chiffré et signé...

Mais un autre problème peut se poser : tout est basé sur la confiance que l'on accorde à la clé publique or comment contrôler que la clé publique appartient bien à celui qui le prétend ?

C'est le role des certificats.

19.4.1. L'utilité d'un certificat

Pour être sûr que la clé publique provient bien de celui que l'on croit, on utilise une autorité tierce (appelé le tiers de confiance). Cette autorité est celle qui va générer une clé publique certifiée par exemple pour un serveur Web, puis c'est ensuite elle qui garantira à tout demandeur (par exemple le client web) que la clé publique envoyée appartient bien à celui qui le prétend (au serveur Web).

La garantie qu'une clé publique provient bien de l'émetteur qu'il prétend être, s'effectue donc via un certificat d'authenticité émanant d'une autorité de certification (AC), le tiers de confiance.

19.4.2. Qu'est-ce qu'un certificat x509 ?

x509 définit la forme d'un certificat (simple fichier informatique) délivré par une autorité de certification qui contient :

• la clé publique de son détenteur et des informations sur son identité ;

• le nom distinctif de l'autorité de certification ;

• la signature électronique (chiffrement de l'empreinte par clé privée) de l'autorité de certification.

Pour obtenir plus de précisions sur le certificat x509, vous pouvez consulter la page suivante http://interpki.sourceforge.net/index.php?/x509.html

Comment obtenir un certificat ?

On peut acheter un certificat SSL 128 bits à un prix raisonnable aux alentours de 50 EUR HT /an. (Voir par exemple à cette adresse http://www.netenligne.com/ecommerce/ssl1.asp et http://www.netenligne.com/ecommerce/ssl2.asp pour le tableau comparatif des prix).

Voilà ce que l'on peut lire en ligne : "Pour obtenir un certificat, il faut fournir des données d'identification. Tout propriétaire d'un nom de domaine et du site correspondant peut obtenir un certificat SSL, qu'il s'agisse d'une personne physique, d'une entreprise, d'une association ou d'une administration.

S'il n'y a pas de problème concernant l'identification du demandeur et son droit à obtenir un certificat SSL pour son site, le délai d'obtention est de 1 à 2 jours ouvrés"

Pour un usage interne, on peut se "fabriquer", avec quelques outils logiciels nos propres certificats. C'est d'ailleurs ce que l'on va faire dans le prochain TP.

Comment vérifier un certificat ?

C'est exactement la même méthode que celle utilisée lors de la vérification de la signature électronique d'un document.

La figure suivante illustre un exemple de certificat émis pour un serveur WEB.

Bien sûr, vous devez "détenir" le certificat contenant la clé publique de l'autorité de certification.

Lorsque vous devez vérifier le certificat d'un serveur WEB, c'est votre navigateur qui s'en charge ; Lors de l'installation d'un navigateur récent, un certain nombre de certificats d'AC sont chargés automatiquement. Si le certificat du site que vous consultez a été validé par une de ces AC, vous n'aurez pas de fenêtres d'alertes... (Voir le TP pour plus de précisions).

Des protocoles, utilisant ces techniques, ont été développés pour sécuriser des services (WEB, telnet, POP, SMTP, etc.).

En particulier, le protocole SSL (Secure Socket Layer), initialement proposé par la société Netscape est aujourd'hui adopté par l'ensemble de la communauté informatique pour l'authentification et le chiffrement des données entre clients et serveurs.

Il existe actuellement un nouveau standard basé sur SSL, TLS (Transaction Layer Security) normalisé par l´IETF (Internet Engineering Task Force).

19.5.1. Principes du protocole SSL

Conçu par Netscape, SSL est un protocole se plaçant entre la couche application et la couche transport permettant d´assurer la confidentialité, l´authentification et l´intégrité des données lors des communications.

Il peut être appliqué à des applications comme HTTP, POP, FTP,...

Sous Linux, vous pouvez aller consulter le fichier /etc/services pour connaître les numéros de port correspondants aux nouvelles implémentation de ces services au dessus de SSL.

19.5.2. Exemple de fonctionnement du protocole SSL avec un serveur WEB

En ce qui concerne le HTTP, il a été nécessaire de définir une nouvelle méthode d´accès dans les URL baptisée HTTPS pour se connecter au port d´un serveur utilisant le SSL qui porte par défaut le numéro 443.

Le mécanisme est illustré par la figure suivante :

1 - le navigateur fait une demande de transaction sécurisée au serveur en envoyant sa requête HTTPS://, il demande donc le certificat garantissant la clé publique du serveur.

2 - le serveur lui envoie son certificat d'authentification délivré par une autorité de certification (normalement organisme officiel). Ce certificat comporte une clé publique.

3 - Le navigateur s'assure tout d'abord que le certificat délivré est valide puis il envoie au serveur une clé secrète codée issue de la clé publique (de 56 ou 128 bits). Seul le serveur sera donc capable de décoder cette clé secrète car il détient la clé privée. Cette clé secrète ainsi créée sera utilisée pour encoder les messages (cryptographie symétrique). L'algorithme à clé secrète utilisé (ex : DES, RC4) est négocié entre le serveur et le client.

4 - Le serveur et le client possède maintenant une clé secrète partagée (la clé de session) et les échanges sont faits par l'intermédiaire de cette clé. Pour assurer l'intégrité des données, on utilise un algorithme de hash (ex : MD5, SHA). S'il y a déconnexion, une nouvelle clé de session sera négociée.

3 remarques et le supplice est terminé puisque vous allez passer à la mise en oeuvre à travers le TP sur HTTPS :

• On voit bien que ce mécanisme permet d'assurer la confidentialité (mécanisme de chiffrement), l'intégrité (algorithme de hash) et l'authentification (certificats).

• Dans le schéma présenté, et à des fins de simplification, il n'a pas été pris en compte l'authentification du client. Cela est possible avec le protocole SSL même si seule l'authentification du serveur est implémentée par défaut.

• Le chiffrement asymétrique ne sert finalement qu'à l'authentification et à transmettre la clé de session de manière sécurisée ; c'est ensuite, cette clé de session (symétrique) qui sert à chiffrer les échanges. En effet, le chiffrement symétrique est beaucoup plus rapide que le chiffrement asymétrique.

20.3.1. Création du certificat serveur

Génération de la clé privée

On génère la clef privée avec la commande suivante en définissant un nom de fichier :

openssl genrsa 1024 > servwiki.key

La sortie attendue est la suivante :

Generating RSA private key, 1024 bit long modulus
	..................++++++
	.................................................................++++++
	e is 65537 (0x10001)

Si vous souhaitez que cette clé ait un mot de passe (qui vous sera demandé à chaque démarrage d'apache, donc à éviter !), ajoutez "-des3" après "genrsa".

Ceci a pour effet de créer une clé SSL (fichier servwiki.key), ne la perdez pas... c'est votre clé privée... (ni éventuellement le mot de passe) !

Vous pouvez observer son contenu : less servwiki.key

-----BEGIN RSA PRIVATE KEY-----
MIICXgIBAAKBgQDQG9wvnuLC4aqzaJCAWGA1AxFzg00hjPObhq1mukzsGyuuWBFG
vj/k9vFNYX55DHctb/4cXtsZRWWvgcjtYnCVwRu+DAjFsk//kOMfhplmiv9xQ+ZL
8w/Xrnm8JWdSS+S4LCMnsuIiQtLbhMrQnUV02hAtbIZiSM3k6OjShEZhDQIDAQAB
AoGAHi0cBW+1k+qjFPbBlUq7UJSMUEKmyYmlvVSPCklTZB0gfVxZzPdDTpEcNks/
yo+rLFSD9Vsvy/9LGmLoXruadWlK67PCUnpM5/oRRGgy8t73YKrxflAU5Gtymjvc
ZCf0CAs6wBft3yLU31Qc4WqVM2vTyUH76jebVhxEw8k63OUCQQD/1OmAXV+TxBPG
ZTPFbzUeAE5rQqqOW4aoMNvM61Yn/19h6SzY2MfSQvF1BNns/efCRrqOMeyvPWUG
g1okfogTAkEA0D7pDf/D2Yu5msbOAGF4QBU1erLzpi/s6Rv6VEPYCGnHQlo3jbg9
FZbjHJ4UcYyYaA8jIrkY+FIJM88YlGbWXwJBAILEdvJ5R/CFCkKf2j2yIWmLaIol
En8fw43XI5L0PB7Hxx6KDLVu4XzVYQyahTZBdqR0eMlUNZJBhJE2tO3wi2cCQQCp
JkCFd3es0BrNxqfzlThozRFofcz88za7TldydL0YcFtC4Sb4vWsYizwktZ6jcPEm
rQz8Gl9W7MO+ynwLptB/AkEA1tsnFXoYzI71enmTdugGxbv0RqAd5iQpDYQkDSdn
2LImp/3YnXNJ9qpY91j87tKthh/Oetu6SHlmLg1LOYNIdw==
-----END RSA PRIVATE KEY-----

Protégez votre fichier en faisant : chmod 400 servwiki.key

De multiples autres options sont possibles mais il est inutile d'alourdir le sujet (à creuser pour une éventuelle PTI...)

A partir de votre clé, vous allez maintenant créer un fichier de demande de signature de certificat (CSR Certificate Signing Request).

On génère la demande de certificat avec la commande suivante :

openssl req -new -key servwiki.key > servwiki.csr

Le système va vous demander de saisir des champs ; remplissez-les en adaptant sauf le champ "Common Name" qui doit être identique au nom d'hôte de votre serveur virtuel :

Country Name (2 letter code) [AU]:FR
State or Province Name (full name) [Some-State]:CORSE
Locality Name (eg, city) []:Ajaccio
Organization Name (eg, company) [Internet Widgits Pty Ltd]:LLB
Organizational Unit Name (eg, section) []:BTSINFO
Common Name (eg, YOUR name) []:wiki.domain1.org
Email Address []:

Ce n'est pas la peine de saisir d'autres "extra attributes"...

Ceci a pour effet de créer le formulaire de demande de certificat (fichier servwiki.csr) à partir de notre clé privé préalablement créée.

Ce fichier contient la clé publique à certifier. Un less servwiki.csr nous donne :

-----BEGIN CERTIFICATE REQUEST-----
MIIBsTCCARoCAQAwcTELMAkGA1UEBhMCRlIxFTATBgNVBAgTDENvcnNlIGR1IFN1
ZDEQMA4GA1UEBxMHQWphY2NpbzEMMAoGA1UEChMDTExCMREwDwYDVQQLEwhCVFMg
SU5GTzEYMBYGA1UEAxMPcHJvZi5idHNpbmZvLmZyMIGfMA0GCSqGSIb3DQEBAQUA
A4GNADCBiQKBgQDSUagxPSv3LtgDV5sygt12kSbN/NWP0QUiPlksOkF2NkPfwW/m
f55dD1hSndlOM/5kLbSBo5ieE3TgikF0IktjBWm5xSqewM5QDYzXFt031DrPX63F
vo+tCKTQoVItdEuJPMahVsXnDyYHeUURRWLWwc0BzEgFZGGw7wiMF6wt5QIDAQAB
oAAwDQYJKoZIhvcNAQEEBQADgYEAwwI4UvkfhBvyRrUXtjrLfZXLxZlF9o+URmHJ
ysvrLKfesVBEzdA9mqk1OwIwLfe8Fw2fhip2LGqvcCPxDMoIE/0cDkqGRg9iKp7D
DMuy69lPTEB6UtpVKO/1eage0oug6VqdfGAYMMSGyWFuO9FE4UE6HspVodb20wGV
4H8qZuk=
-----END CERTIFICATE REQUEST-----

Maintenant, deux choix s'offrent à vous :

• envoyer le fichier servwiki.csr à un organisme (le tiers de confiance ou l'autorité de certification (CA)) et ainsi obtenir le certificat dûment signé par la clé privée de l'organisme (après avoir payé),

• ou bien signer vous-même notre certificat.

20.3.2. Création du certificat de l'autorité de certification

Pour signer un certificat, vous devez devenir votre propre autorité de certification, cela implique donc de réaliser une clé et un certificat signé.

La création de la clé privée de l'autorité de certification se fait comme précédemment :

openssl genrsa -des3 1024 > ca.key

Ce qui a pour effet de créer la clé privée de l'autorité de certification. Dans ce cas, il vaut mieux rajouter l'option -des3 qui introduit l'usage d'une "passphrase" (mot de passe long qui peut même contenir du blanc) car c'est cette clé privée qui signera tous les certificats que l'on emettra ; cette "passphrase" sera donc demandée à chaque utilisation de la clé.

Ensuite, à partir de la clé privée, on crée un certificat x509 pour une durée de validité d'un an auto-signé :

openssl req -new -x509 -days 365 -key ca.key > ca.crt

Il faut saisir la passphrase... puisqu'on utilise "ca.key" que l'on a protégé. Et on donne les renseignements concernant cette fois-ci l'autorité de certification (c'est à dire nous-même).

Attention : le nom de "Common Name" doit être différent de celui qui a été donné pour la clé.

Country Name (2 letter code) [AU]:FR
State or Province Name (full name) [Some-State]:CORSE
Locality Name (eg, city) []:Ajaccio
Organization Name (eg, company) [Internet Widgits Pty Ltd]:LLB
Organizational Unit Name (eg, section) []:BTSINFO
Common Name (eg, YOUR name) []:cert_CA
Email Address []:

C'est notre certificat d'autorité de certification qui va permettre de signer les certificats créés.

20.3.3. La signature du certificat serveur par le CA (Certificate Autority)

La commande qui signe la demande de certificat est la suivante :

openssl x509 -req -in servwiki.csr -out servwiki.crt -CA ca.crt -CAkey ca.key\
-CAcreateserial -CAserial ca.srl

Le certificat signé est le fichier "servwiki.crt". La sortie de la commande attendue est la suivante :

Signature ok
subject=/C=FR/ST=CORSE/L=Ajaccio/O=LLB/OU=BTSINFO/CN=wiki.domain1.org
Getting CA Private Key
Enter pass phrase for ca.key:

Vous avez maintenant un certificat pour votre serveur se nommant servwiki.crt.

less servwiki.crt

-----BEGIN CERTIFICATE-----
MIICVDCCAb0CAQEwDQYJKoZIhvcNAQEEBQAwdDELMAkGA1UEBhMCRlIxFTATBgNV
BAgTDENvcnNlIGR1IFN1ZDEQMA4GA1UEBxMHQWphY2NpbzEMMAoGA1UEChMDTExC
MREwDwYDVQQLEwhCVFMgSU5GTzEbMBkGA1UEAxMSc2VydmV1ci5idHNpbmZvLmZy
MB4XDTA0MDIwODE2MjQyNloXDTA0MDMwOTE2MjQyNlowcTELMAkGA1UEBhMCRlIx
FTATBgNVBAgTDENvcnNlIGR1IFN1ZDEQMA4GA1UEBxMHQWphY2NpbzEMMAoGA1UE
ChMDTExCMREwDwYDVQQLEwhCVFMgSU5GTzEYMBYGA1UEAxMPcHJvZi5idHNpbmZv
LmZyMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDSUagxPSv3LtgDV5sygt12
kSbN/NWP0QUiPlksOkF2NkPfwW/mf55dD1hSndlOM/5kLbSBo5ieE3TgikF0Iktj
BWm5xSqewM5QDYzXFt031DrPX63Fvo+tCKTQoVItdEuJPMahVsXnDyYHeUURRWLW
wc0BzEgFZGGw7wiMF6wt5QIDAQABMA0GCSqGSIb3DQEBBAUAA4GBALD640iwKPMf
pqdYtfvmLnA7CiEuao60i/pzVJE2LIXXXbwYjNAM+7Lov+dFT+b5FcOUGqLymSG3
kSK6OOauBHItgiGI7C87u4EJaHDvGIUxHxQQGsUM0SCIIVGK7Lwm+8e9I2X0G2GP
9t/rrbdGzXXOCl3up99naL5XAzCIp6r5
-----END CERTIFICATE-----

Il faut maintenant installer le certificat de l'autorité de certification dans chaque navigateur client. C'est lui qui va valider le certificat reçu par le client lors de la requête https://.

20.3.4. Installation du certificat d'autorité de certification

Pour installer sur votre navigateur le certificat de l´autorité de certification (fichier ca.crt) :

• "Arrangez-vous" pour avoir le certificat disponible à partir du client (disquette, ftp, ssh, répertoire partagé...)

• Sous Windows, un clic droit sur le fichier devrait vous permettre de lancer l'assistant d'installation du certificat dans Internet Explorer. Vous devez l'installer en tant qu'autorité de certification.Vérifiez en suite que le certificat s'y trouve bien sous le nom de "cert_CA".

• sur Mozilla :

  • Edition/préférence/Confidentialité et Sécurité/Certificats

  • Bouton de commande : gestion des certificats

  • Onglet : autorité

  • Bouton de commande : importer

  • etc...

Il ne reste plus maintenant qu'à configurer apache.

21.2.1. Environnement de SAMBA

SAMBA est installé sur la Freeduc-sup. Si vous n'utilisez pas cette distribution, installez les paquets. Il ne devrait normalement pas y avoir de problèmes de dépendances.

Le paquet installe principalement samba et samba-common :

• le programme nmbd qui assure la résolution de nom NetBIOS et smbd qui assure le partage de ressource SMB/CIFS dans /usr/sbin,

• le script d'initialisation dans /etc/init.d,

• un fichier de configuration /etc/samba/smb.conf,

• une documentation complète dans /usr/share/doc,

• le service de journalisation (log) dans /var/log/samba,

• des outils comme smbpasswd pour la création des comptes samba et nmblookup pour vérifier le fonctionnement de la résolution de noms NetBIOS.

La commande dpkg-reconfigure samba vous demande si samba doit être lancé en mode autonome, choisissez « oui », si un fichier /etc/samba/smbpasswd doit être créé, choisissez également « oui ». La dernière option vous permet d'avoir une base de données de compte créée automatiquement à partir de la base de compte du fichier /etc/passwd.

Faites tout de suite une sauvegarde du fichier /etc/smb.conf.

Dans la suite du document, vous remplacerez $NOM_HÔTE par le nom d'hôte de votre machine qui servira également de nom NetBIOS.

21.2.2. Le fichier de configuration sous Linux

Voici le fichier de configuration qui nous servira de base de travail. Il va permettre de :

• définir $NOM_HÔTE comme contrôleur de domaine,

• mettre en place l'authentification des utilisateurs,

• partager des disques et une imprimante pour un client Windows,

• partager du dossier personnel d'un utilisateur sous Linux comme étant son répertoire personnel sous Windows.

Le fichier de configuration comprend essentiellement deux parties :

• une partie " générale " qui définit le comportement général du serveur et la stratégie adoptée pour les services communs (CPD, mode d'authentification, service WINS),

• une partie share, qui définit les ressources partagées et les permissions d'accès.

21.2.3. Les étapes de la configuration du serveur

Nous allons réaliser les opérations suivantes :

• Vérifier et valider le fichier de configuration,

• Déclarer les ressources partagées,

• Créer un compte d'utilisateur pour SAMBA.

Il n'y aura plus qu'à tester la configuration à partir d'un client.

Attention, un compte système n'est pas un compte SAMBA. Faites bien la distinction entre les deux.

21.2.4. Première étape - Installer le fichier de configuration

Configurer l'environnement de samba par le fichier /etc/samba/smb.conf et activez le service avec la commande /etc/init.d/samba start. Cette opération doit être réalisée chaque fois que le fichier de configuration est modifié. Vérifiez la configuration à l'aide de la commande testparm | more.

Corrigez les erreurs éventuelles de configuration.

21.2.5. Deuxième étape - Déclarer les ressources partagées

Cette opération est réalisée dans la partie share du fichier smb.conf. Chaque fois que vous ajoutez ou modifiez une ressource, relancez le service serveur.

Pour l'authentification sur un domaine, vous devez créer un répertoire netlogon, par exemple :

mkdir -p /home/samba/netlogon

21.2.6. Troisième étape - Créer un compte d'utilisateur autorisé

La création d'un compte d'utilisateur SAMBA et de son mot de passe est réalisée à l'aide de la commande smbpasswd.

smbpasswd -a MonCompte MonMotDePasse

Voir man smbpasswd ou smbpasswd --help pour le mode d'utilisation de la commande. Le compte système doit être préalablement créé avec la commande unix adduser.

Trois remarques :

• Les manipulations peuvent paraître fastidieuses si vous avez un grand nombre de comptes utilisateurs.

• Si vous disposez de nombreux comptes d'utilisateurs sur votre système Linux, vous disposez d'un script qui permet de créer automatiquement les comptes SAMBA à partir du fichier /etc/passwd. Voir man mksmbpasswd pour le mode d'utilisation de la commande. Il est également possible de créer sans difficulté un script qui, a partir d'un fichier texte crée les comptes systèmes et les comptes SAMBA.

Toutes les indications sont dans la documentation de SAMBA.

21.2.7. La configuration d'un client Windows

La configuration du client Windows ne doit pas poser de difficulté.

Configurez le client pour les réseaux Microsoft afin que l'utilisateur soit authentifié par le serveur de votre domaine. Ici le contrôleur de domaine est le serveur SAMBA. Vérifiez la configuration du protocole TCP/IP, relancez la machine. Vous pourrez vous authentifier sur le serveur SAMBA.

Toutes les commandes net use, net share ou les outils comme le voisinage réseau vous permettent d'accéder aux ressources du serveur (disques partagés, imprimantes, disque personnels).

Un problème à éviter :

Le compte utilisateur SAMBA dispose de moins de privilèges que le compte root. Si vous partagez un disque et que vous faites les manipulations sous le compte root, faites attention aux droits, car si root est propriétaire (chmod 700), le client SAMBA ne pourra pas accéder au disque.

24.1.1. Installation du serveur

Les paquets sont déjà installés.

Attention : vous pouvez avoir sur votre distribution, plusieurs serveurs DHCP.

dhcpxd est conforme à la RFC 2131. Il fournit un exemple de configuration assez détaillé.

dhcp3, intègre l'inscription auprès d'un DNS Dynamique. C'est ce package que nous allons utiliser dans le TP. Par contre si vous n'avez pas de DNS dynamique sur le réseau, vous devrez mettre en entête du fichier dhcpd.conf, la ligne :

ddns-update-style none;

24.1.2. Configuration du serveur

La configuration consiste à créer 2 fichiers :

• /etc/dhcp3/dhcpd.conf, ce fichier sert à la configuration même du serveur (plage d'adresses, paramètres distribués),

• /var/lib/dhcp3/dhcpd.leases, ce fichier va servir à l'inscription des clients. Chaque client DHCP, génère l'écriture d'un enregistrement dans ce fichier. Cela permet le suivi, les statistiques de l'activité du serveur.

$>more dhcpd.conf

# ici il s'agit du réseau 192.168.0.0
subnet 192.168.0.0 netmask 255.255.255.0 {

#La plage d'adresse disponible pour les clients
range 192.168.0.10 192.168.0.20;

# Les clients auront cette adresse comme passerelle par défaut
option routers    192.168.0.254;

# Ici c'est le serveur de noms, on peut en mettre plusieurs
option domain-name-servers   192.168.0.1;

# Enfin on leur donne le nom du domaine
option domain-name   "freeduc-sup.org";

# Et l'adresse utilisée pour la diffusion
option broadcast-address 192.168.0.255;

# Le bail à une durée de 86400 s par défaut, soit 24 h
# On peut configurer les clients pour qu'ils puissent demander 
# une durée de bail spécifique
default-lease-time  86400;

# On le laisse avec un maximum de 7 jours
max-lease-time 604800;

#Ici on désire réserver des adresses à des machines
group {
#use-host-decl-names indique que toutes les machines dans l'instruction « group »
# auront comme nom, celui déclaré dans l'instruction host.
use-host-decl-names true ;

# ici définir les machines 
host m1 {
hardware ethernet 00:80:23:a8:a7:24;
fixed-address 192.168.0.125;
} # End m1
 
host m2 {
hardware ethernet a0:81:24:a8:e8:3b;
fixed-address 192.168.0.126;
} # End m2

    } # End Group
}     # End dhcp.conf

[root@master /etc]# more  /var/lib/dhcp3/dhcpd.leases

lease 192.168.0.10 {

 starts 1 2002/12/14 18:33:45;

 ends 1 2002/12/14 18:34:22;

 hardware ethernet 00:40:33:2d:b5:dd;

 uid 01:00:40:33:2d:b5:dd;

 client-hostname "CHA100";

}

root@master:/etc/dhcp3# dhcpd3 -d

Internet Software Consortium DHCP Server V3.0.1rc9

Copyright 1995-2001 Internet Software Consortium.

All rights reserved.

For info, please visit http://www.isc.org/products/DHCP

Wrote 1 leases to leases file.

Listening on LPF/eth0/00:d0:59:82:2b:86/192.168.0.0/24

Sending on   LPF/eth0/00:d0:59:82:2b:86/192.168.0.0/24

Sending on   Socket/fallback/fallback-net

24.1.3. Installation des clients

root@m1:# dhclient eth0

24.1.4. Procédure de test

Sur Windows vous allez pouvoir utiliser (selon les versions) les commandes IPCONFIG et Winipcfg.

Utilisez ipconfig /? pour voir comment utiliser la commande

Vous pouvez utiliser l'interface graphique winipcfg sous Windows 9x uniquement. Allez dans Démarrer puis Exécuter et saisissez winipcfg. Une fois la fenêtre activée vous pouvez utiliser les fonctions de libération et de renouvellement de bail. Si vous avez plusieurs cartes sur la station, la liste déroulante " Cartes Ethernet Informations " vous permet d'en sélectionner une.

26.3.1. Notion de domaine, de zone et de délégation

Un " domaine " est un sous-arbre de l'espace de nommage. Par exemple .com est un domaine, il contient toute la partie hiérarchique inférieure de l'arbre sous jacente au noeud .com.

Un domaine peut être organisé en sous domaines. .pirlouit.com est un sous domaine du domaine .com. Un domaine peut être assimilé à une partie ou sous-partie de l'organisation de l'espace de nommage. Voir la diapositive sur les Domaines, zones et délégations.

Une "zone" est une organisation logique (ou pour être plus précis, une organisation administrative) des domaines. Le rôle d'une zone est principalement de simplifier l'administration des domaines. Le domaine ".com" peut être découpé en plusieurs zones, z1.com, z2.com...zn.com. L'administration des zones sera déléguée afin de simplifier la gestion globale du domaine. Voir la diapositive sur les zones.

La délégation consiste à déléguer l'administration d'une zone (ou une sous-zone) aux administrateurs de cette zone. Voir la diapositive sur la délégation.

Attention à ces quelques remarques :

• Un domaine est une organisation de l'espace de nommage. Il peut être attaché à un domaine parent, et/ou peut avoir un ou plusieurs sous-domaines enfants.

• Les zones correspondent à des organisations administratives des domaines. Un domaine peut être administré par plusieurs zones administratives, mais il est possible aussi qu'une zone serve à l'administration de plusieurs domaines. Prenons l'exemple d'un domaine "MonEntreprise.fr", membre de ".fr". Il peut être composé de trois sous-domaines France.MonEntreprise.fr, Italie.MonEntreprise.fr, Espagne.MonEntreprise.fr et de deux zones d'administration. Une en France pour les sous-domaines France.MonEntreprise.fr, Italie.MonEntreprise.fr (il n'y a pas de délégation), et une pour Espagne.MonEntreprise.fr, il y a délégation.

• L'adressage IP correspond à une organisation physique des noeuds sur un réseau IP.

• L'organisation de l'espace de nommage est complètement indépendante de l'implantation géographique d'un réseau ou de son organisation physique. L'organisation physique est gérée par des routes (tables de routage). L'espace de nommage indique pour un nom de domaine N, quelles sont les serveurs de noms qui ont autorité sur cette zone. Elles ne donnent pas la façon d'arriver à ces machines.

• Les seules machines connues au niveau de l'espace de nommage, sont les serveurs de nom "déclarés". Ces informations sont accessibles par des bases de données "whois".

• La cohérence (le service de résolution de noms) entre l'organisation de l'espace de nommage global et les organisations internes des réseaux sur internet est réalisée par les serveurs de noms.

26.3.2. le domaine in-addr.arpa

Le principe de la résolution de noms, consiste à affecter un nom d'hôte une adresse IP. On parle de résolution de noms directe. Le processus inverse doit pouvoir également être mis en oeuvre. On parle de résolution de noms inverse ou reverse. Le processus doit fournir, pour une adresse IP, le nom correspondant. Pour cela il y a une zone particulière, in-addr.arpa, qui permet la résolution inverse d'adresse IP. Voir la diapositive sur la résolution inverse.

Par exemple, pour le réseau 192.168.1.0, on créera une zone inverse dans le domaine in-addr.arpa. La zone de recherche inverse dans le domaine deviendra : 1.168.192.in-addr.arpa. Cette zone devra répondre pour toutes les adresses déclarées dans la tranche 192.168.1.0 à 192.168.1.254.

On inscrira dans cette zone tous les noeuds du réseau pour lesquels on désire que la résolution inverse fonctionne. Un serveur de noms peut, pratiquement, fonctionner sans la définition de cette zone tant que le réseau n'est pas relié à l'internet. Si cela était le cas, il faudrait déclarer cette zone, sans quoi, des services comme la messagerie électronique, ne pourrait fonctionner correctement, notamment à causes des règles anti-spam. (Voir www.nic.fr)

26.3.3. Fichiers, structure et contenus

Sur linux nous allons utiliser deux types de fichiers :

• le fichier /etc/bind/named.conf, qui décrit la configuration générale du serveur DNS,

• les fichiers qui contiennent les enregistrements de ressources pour la zone dans /etc/bind. On crée, en général, un fichier pour la résolution directe d'une zone, et un fichier pour la résolution inverse.

26.3.4. Principaux types d'enregistrements

Les types d'enregistrements qui enrichissent une base de données DNS sont de plusieurs types, dont voici les principaux :

• Enregistrement de type SOA (Start Of Authority) : indique l'autorité sur la zone. Ces enregistrements contiennent toutes les informations sur le domaine. Par exemple le délai de mise à jour des bases de données entre serveurs de noms primaires et secondaires, le nom du responsable du site

• Enregistrements de type NS (Name Server) : ces enregistrements donnent les adresses des serveurs de noms pour le domaine.

• Enregistrement de type A (Adresse) : ces enregistrements permettent de définir les noeuds fixes du réseau (ceux qui ont des adresses IP statiques). Serveurs, routeurs, switchs ...

• Enregistrements de type MX (Mail eXchanger) : ils servent pour déclarer les serveurs de messagerie. Il faudra déclarer une enregistrement de type MX pour la réalisation du TP sur la messagerie.

• Enregistrements de type CNAME (Canonical Name) : ils permettent de définir des alias sur des noeuds existants. Par exemple www.foo.org peut être la même machine que web.foo.org. Dans ce cas, " www " est un alias (CNAME) de " web ". Cela permet de différencier le nommage des machines des standards de nommages des services (www, ftp, news, smtp, mail, pop...).

• Enregistrement de type PTR (Pointeur) : ils permettent la résolution de noms inverse dans le domaine in-addr.arpa.