Architechture Tcpip

http://www.linux-france.org/~amascret/prj/edu/archinet/systeme/index.
html
Tutoriel sur les serveurs

Next
Tutoriel sur les serveurs

Version 1.1
Copyright © 2004 L'équipe Freeduc-Sup
Permission est accordée de copier, distribuer et/ou modifier ce document selon les termes de la
Licence de Documentation Libre GNU (GNU Free Documentation License), version 1.1 ou toute
version ultérieure publiée par la Free Software Foundation sans section invariante, sans texte de
première de couverture, ni texte de quatrième de couverture. Une copie de la licence est fournie
dans la section intitulée "GNU Free Documentation License".
Revision History
Revision 1.0 Septembre 2007
Abstract
Ensemble de documents réalisés pour la freeduc-sup.
Table of Contents
1. Eléments de cours sur TCP/IP

Présentation de TCP/IP
OSI et TCP/IP
La suite de protocoles TCP / IP
IP (Internet Protocol, Protocole Internet)
TCP (Transmission Control Protocol,Protocole de contrôle de la transmission)
UDP (User Datagram Protocol)
ICMP (Internet Control Message Protocol)
RIP (Routing Information Protocol)
ARP (Address Resolution Protocol
Fonctionnement général
Les applications TCP-IP
Modèle client/serveur
L'adressage des applicatifs : les ports
Les ports prédéfinis à connaître
Par NGUELE Paul Alain avril 2009 1

2. Eléments de cours sur l'adressage IP
Adresses physiques (MAC) et adresses logiques (IP)
Notion d'adresse Physique et de trames
Notion d'adresse logique et de paquets
Résolution d'adresses logiques en adresses physiques
Attribution d'une adresse IP Internet
Adressage IP
Structure des adresses IP
Classes d'adresses
Identification du réseau
Adresses réservées
Les sous-réseaux
Pourquoi créer des sous réseaux ?
Masque de sous-réseau
Sous-réseaux
Adressage de sur-réseaux
3. Fichiers de configuration du réseau et commandes de base
Présentation du document : les outils de l'administrateur réseau
Les fichiers de configuration
Le fichier /etc/hosts
Le fichier /etc/networks
Le fichier /etc/host.conf
Le fichier /etc/resolv.conf
Les fichiers de configuration des interfaces réseau
Les outils de l'administrateur réseau
La commande ifconfig
La commande arp
La commande route
La commande netstat
La commande traceroute
La commande dig
La commande host
4. Eléments de cours sur ARP
Le protocole ARP
Processus de recherche de l'adresse physique
5. La résolution d'adresses physiques - Travaux Pratiques
Tester la présence d'un poste sur le réseau avec la commande ping
Interface couche 3 / couche 2 , IP / ethernet : utilisation du protocole ARP
Le cache ARP

La commande ARP
Tromper ARP avec une adresse inexistante
Tromper ARP avec une adresse Ethernet existante mais mal associée
Utilisation de l'analyseur de trames Ethereal
examen de paquets ARP
6. Le routage
Principe
Acheminement des paquets TCP-IP
Les tables de routage
Acheminement Internet
Domaine d'acheminement
Principe du choix d'une voie d'acheminement
Routage dynamique
7. Le protocole IPv6
Fonctionnalités d'IPv6
Principales caractéristiques d'IPv6
Allocation de l'espace d'adressage
Représentation des adresses IPv6
Représentation des adresses IPv6 : forme préférée
Représentation des adresses IPv6 : forme abrégée
Représentation des adresses IPv6 : forme mixte
Représentation des Masques de sous-réseaux
Types d'adresses
Portée des adresses
8. Les commandes et fonctionnalités IPv6
Les principales commandes IPv6
Le protocole de découverte des voisins
L'autoconfiguration
9. Les tunnels IPv4/IPv6
Comment se relier au réseau IPv6 ?
Configuration d'un tunnel IPv6/IPv4
Configuration d'un routeur IPv6
10. Installation d'un serveur Telnet et FTP
Description et objectifs de la séquence
Présentation des concepts importants
Extrait de /etc/services :
Extrait de /etc/inetd.conf
Configuration avec xinetd
TCP-Wrapper

Eléments de configuration
TCP Wrapper
Extrait de /etc/syslog.conf
Extrait de /var/log/syslog
Consignes pour le processus d'installation et de configuration
Procédure de tests
Problèmes que vous pourrez rencontrer
11. TP Unix - Gestion des Utilisateurs
Gestion des Utilisateurs
Documentation technique
Exercices
Amélioration du bash
Exercices
/etc/skel (profil par défaut)
Exercice
Droits par défaut
Exercice
Ajout de comptes
Exercices
Droits d'accès, et multigroupes
Exercice
12. Travaux pratiques : Telnet et FTP
Quelques remarques
Configuration de telnet
Configuration de TCP-Wrapper
Test de l'accès ftp authentifié
Configuration d'un service ftp anonyme
Test de l'accès ftp et sécurisation du service
telnet, ftp et la sécurité
13. scp, sftp et les tunnels avec ssh
Présentation
Mode de fonctionnement de SSH
Mode de fonctionnement de la couche transport SSH
Fichiers de configuration d'OpenSSH
Configurer et utiliser SSH
Premiers pas
Utiliser un agent ssh
Automatisation dans X

Comprendre la redirection de port (Port Forwarding)
Redirection locale de port (-L Local)
Redirection distante de ports (-R Remote)
Schéma de redirection distante de ports
Exemple de cas d'utilisation
X and Port Forwarding
Automatisation de tâches SSH
Scénario d'utilisation d'un proxy ssh
Proxy HTTP
Autres scénarios
Utilisation de rsync
Utilisation de SCP et de SFTP
Utilisation de scp
Utilisation de sftp
Références
14. Mettre en place un VPN avec PPP et SSH
Présentation
Le protocole PPP
Configuration et installation du VPN
Première étape : configuration de SSH
Test de la connexion
Explication sur le fonctionnement de la maquette
L'analyse de trame
Les services pop, imap et smtp
Les services HTTP(s) et FTP
Conclusion
Références et annexes
15. Les fichiers hosts
Présentation
Avant de démarrer
Fiche de cours
Travaux Pratiques
Questions
16. Installation d'un serveur HTTP
Résumé
Installation et présentation du serveur Apache 2
Installation du serveur Apache 2
Présentation de l'environnement
Installation d'un service minimum

Sécurisation des accès
Un serveur WEB personnel pour chaque utilisateur
Activation du serveur (Rappel)
Test de la configuration
Questions
17. TP 1 : installation d'un serveur HTTP
Résumé
Installation d'un serveur Web
Introduction
Configuration du serveur
Activation du serveur
Auto-évaluation sur le premier TP
18. TP 2 : création de pages Web
Résumé
Vérification de la configuration
Installation d'un site Web
Développement d'un site
Test de vos pages
Utilisation des alias
Auto évaluation sur le deuxième TP
19. TP 3 : configuration des répertoires personnels
Configurer le compte personnel
Développer un site personnel
Tester l'accès au site personnel
Auto-évaluation sur le troisième TP
20. TP 4 : mise en place d'un accès sécurisé
Déployer un site d'accès en ligne
Sécuriser l'accès à ce site par un mot de passe
Tester la configuration.
Les fichiers .htaccess
Auto-évaluation sur le quatrième TP
21. TP 5 : Utilisation de scripts CGI
Etudier les sources fournies en annexe
Développer un formulaire et adapter les scripts
Tester le fonctionnement de votre script.
Auto-évaluation sur le cinquième TP
22. TP 6 : Serveurs webs virtuels et redirection
Avant de commencer sur les serveurs web virtuels

Serveur web virtuel basé sur les adresses ip
Serveur Web virtuel basé sur le nom
Application sur la redirection
Annexe pour le "web-hosting"
23. Le chiffrement
Qu'est-ce que le chiffrement ?
Les mécanismes de chiffrement
Le chiffrement symétrique
Le chiffrement asymétrique
Que permet de faire le chiffrement ?
Garantir la confidentialité d'un message
Authentifier l'émetteur d'un message
La signature électronique
Mise en oeuvre
Les certificats
L'utilité d'un certificat
Qu'est-ce qu'un certificat x509 ?
Le protocole SSL
Principes du protocole SSL
Exemple de fonctionnement du protocole SSL avec un serveur WEB
24. TP sur le serveur WEB sécurisé
Présentation du TP
Les paquets à installer
Etape 1 : La création des certificats
Création du certificat serveur
Création du certificat de l'autorité de certification
La signature du certificat serveur par le CA (Certificate Autority)
Installation du certificat d'autorité de certification
Etape 2 : configuration d'Apache2
Activation du module ssl
Configuration du port
Configuration du virtual host
25. Le service SAMBA
Introduction
Eléments d'installation et de configuration de SAMBA
Le fichier de configuration sous Linux
Les étapes de la configuration du serveur
Première étape - Configuration du fichier smb.conf
Deuxième étape - Déclarer les ressources partagées

Fichier de configuration d'un serveur SAMBA :
Création d'utilisateurs Samba
Accès depuis un poste client Linux
Accès depuis un poste client Windows
Serveur Samba en tant que contrôleur de domaine
26. Travaux pratiques : installation d'un serveur SAMBA
Déroulement des opérations
Configuration du fichier smb.conf et démarrage des services
Création de comptes utilisateurs
Vérification de la configuration sur le serveur SAMBA
Procédure de test à partir d'un client Linux
Procédure de test à partir d'un client Windows
Configuration d'un contrôleur de domaine.
Automatisation de création de comptes.
Administration graphique
27. Eléments de cours sur le service DHCP
Résumé
Rôle d'un service DHCP
Pourquoi mettre en place un réseau TCP/IP avec des adresses IP dynamiques
Protocole DHCP(Dynamic Host Configuration Protocol)
Fonctionnement de DHCP
Attribution d'une adresse DHCP
Renouvellement de bail IP
Configuration d'un serveur DHCP
Mise en oeuvre d'un client DHCP
Rôle de l'agent de relais DHCP
28. Travaux pratiques : installation d'un serveur DHCP
Indications pour la réalisation du TP
Installation du serveur
Installation des clients
Procédure de test
Réalisation du TP
29. Travaux pratiques : installation d'un agent relais DHCP
Routeur et agent relais DHCP (RFC 1542)
La maquette
Installation
30. Installation d'un serveur DNS

Qu'est ce que le service de résolution de noms de domaine
Présentation des concepts
Notion de domaine, de zone et de délégation
le domaine in-addr.arpa
Fichiers, structure et contenus
Principaux types d'enregistrements
Structure des enregistrements
La délégation
Serveur primaire et serveur secondaire
Le cache
Installation et configuration d'un serveur DNS
Fichiers déjà installés
rndc, le fichier de configuration, le fichier de clé
Procédure de configuration du serveur
Configurer les fichiers
Configuration du DNS manuellement
Le fichier named.conf
Le fichier db.foo.org
Le fichier db.foo.org.rev
Compléments pratiques
Démarrer ou arrêter le service
Finaliser la configuration
Procédure de configuration des clients
Avec windows
Avec GNU/Linux
Procédure de tests
Vérifier la résolution de noms :
Dépannage et outils
Les erreurs de chargement de bind
nslookup, dig
Le cache du DNS
Les journaux
Remarques
Annexes
Annexe 1 - extraits de fichiers de configuration
Annexe 2 - Serveur primaire et serveur secondaire
Annexe 3 - Mise en place d'une délégation de zone
Annexe 3 - Outils de diagnostic et de contrôle
31. Travaux dirigés : installation du service DNS

Présentation - le contexte
32. Travaux pratiques : installation du service DNS
Présentation
Préparation de votre environnement réseau client et serveur
Installation du serveur de noms primaire
Configuration du service serveur DNS manuellement
Configuration du service client manuellement
Configuration de la zone reverse
Installation du serveur de noms secondaire
Procédure de test du serveur secondaire
Test de l'enregistrement SOA
33. Installation d'un serveur NFS
Résumé
Installation des produits clients et serveurs
Les fichiers de configuration du serveur NFS
Les fichiers de configuration du client NFS
Exemple Unix de montage NFS
Configuration et utilisation du client Unix/Linux
34. Travaux pratiques : partages NFS
Première partie
Deuxième partie
Troisième partie
35. Installation d'un service de messagerie
Le service de messagerie électronique
Terminologie
MHS, MTA, UA, DUA
Historique et évolution de sendmail
MIME
Pourquoi Postfix
Buts premiers : un nouveau MTA sous Unix
L'Auteur
Architecture de postfix
La réception des messages (entrées)
Délivrer les messages
Une fonction / un programme
Apports en termes de sécurité :
Communication interprocessus par sockets Unix ou file (FIFO)
Semi résidence

Files d'attente multiples
Configuration et fichiers de configuration de Postfix
Configuration - extrait du fichier /etc/postfix/master.cf
Le fichier de configuration /etc/postfix/main.cf
Le fichier de configuration des aliases /etc/aliases
Surveillance et maintenance de postfix
Structure des messages
Le dialogue entre le client et le serveur
PostOFFICE
IMAP (Internet Message Access Protocol)
Remarques sur pop3 et imap
36. Travaux pratiques : configuration d'un système de messagerie
Installation de postfix
DNS - préparation préalable
Configuration du serveur postifx.
Installation du serveur SMTP
Test de la configuration du serveur SMTP
Installation du serveur PostOFFICE Pop3
Test du serveur Pop3
Utilisation des listes
La gestion des erreurs
Mise en place du service IMAP sur le serveur
Plus loin dans le décryptage
Mise en place du client IMAP
Le relayage
Autres techniques de filtrage et autres services de postfix
37. Installation d'un serveur DDNS avec bind et DHCP
Résumé
Eléments sur le service DDNS
Les aspects sur la sécurité
38. Travaux pratiques : DDNS
Réalisation
Le fichier de zone directe
Le fichier de zone in-addr.arpa
Le fichier rndc.conf
Le fichier de clé partagée

Le fichier dhcpd.conf
Procédure de tests des services
Intégration des services
Générer un nom dynamiquement pour les clients DHCP
39. Installation d'un service Web-mail
Présentation
Architecture générale du service
Installation et configuration OpenWebmail
Préparation de la machine
Installation d'OpenWebmail
Configuration de l'application OpenWebmail
Test de l'environnement
Configuration de l'environnement utilisateur
Test et environnement OpenWebmail
Application
40. Installation d'un service mandataire (Proxy SQUID)
Installer Squid
Configuration de squid
Initialisation de Squid
Les options de démarrage de Squid
Contrôler les accès
Contrôler les accès par authentification
Interface web de Squid et produits complémentaires
La journalisation
Configurer les clients
Forcer le passage par Squid (Proxy transparent)
Le redirecteur SquidGuard
Les applications non prises en charge par un service proxy
41. Travaux pratiques : installation de SQUID
Application
Préparation de la maquette
Installation et configuration du service proxy
Configuration du client
Mise en place d'une ACL simple
Utilisation de fichiers pour stocker les règles des ACL
Configuration des messages d'erreurs
Automatisation de la configuration des clients.
Installation et configuration du service proxy Squid transparent.
Mise en place de l'authentification

Liens
Annexes
Fichier squid.conf - testé avec Squid 2.5
Exemples d'ACLs Squid 2.2
ACL par authentification Squid 2.2
ACL sur des plages horaires Squid 2.2
42. Installation d'un serveur PostgreSQL avec Apache
Avant de démarrer
Les ressources sur PostgreSQL
Accès aux archives
Présentation
Présentation de PostgreSQL
Mode de fonctionnement de PostgreSQL
Langage de commande pour PostgreSQL
Présentation de PHP
Mode de fonctionnement de PHP
Le langage PHP
Dialogue client et serveurs PHP, Apache et PostgreSQL
Exemple de code
43. Travaux pratiques : PostgreSQL
Présentation
PostgreSQL
Test de la base
Serveur Apache et PHP
Serveur PostgreSQL/Apache et PHP
TP de synthèse
44. Surveillance, continuité de service
Principe de fonctionnement
Le matériel
Assurer la surveillance entre machines du cluster
Le logiciel
les pré-requis
L'installation
les fichiers de configuration
Mise en route
Exercices
45. Lilo : Linux Loader
Objectifs
Présentation de Lilo

Lilo
Documentation
Avant de commencer
Linux SGF
Les partitions
Disque IDE ou EIDE
Disques E(i)DE et CDROM
Disques E(i)DE et SCSI
Disques SCSI
Restriction du BIOS
Installation
MBR et PBR
Installer Lilo
Dos ou Windows 9.x
Windows NT
Exemple avec 3 systèmes
Avec d'autres systèmes
Lilo
Exécution de Lilo
Options de configuration
Outils de configuration
Exemple de fichier de configuration /etc/lilo.conf
Désinstaller Lilo
Choix du système
Autres solutions sans Lilo
Loadlin
rdev
initrd
Modules
initrd (suite)
Conclusion
46. Travaux pratiques : Kernel et Noyau
Objectifs
Quelques remarques
Compilation
Installation et activation de module
make-kpkg pour les modules
Utilisation de Grub
Librairies

47. Init : Initialisation du système sous Linux
Documentation
5 phases:
Premières explications:
Le processus de BOOT
Lilo
Init
Le répertoire /etc/rc.d
Séquences du programme init
Le niveaux d'exécution (runlevels)
Le niveau d'exécution par défaut
Le fichier /etc/inittab
Contenu d'un répertoire rcx.d
Comment choisir un mode d'exécution
Utilitaires de configuration
Arrêter ou démarrer un service
Ajout ou suppression d'un service
Placer une commande au démarrage du système
Arrêt du système
La commande shutdown
La disquette de BOOT
Création des disquettes
Dépannage
Mot de passe de root oublié
Démarrer en "single user"
Conclusion
48. TP : Sytème de gestion de fichiers
Swap
ext
loop
Alternative permettant de choisir le device loop
loop encrypté
loop iso9660
Fin du TP
49. CVS : Concurrent Version System
Présentation
Horloge système et synchronisation
Le dépôt (repository)
Initialisation du dépôt

Configuration du serveur CVS
Accès au dépôt
Modules
Les commandes principales de CVS
50. Travaux pratiques : Concurrent Version System
Objectifs
Installer et configurer CVS
Gestion d'un projet en mode non connecté
Gestion d'un projet en mode connecté
51. L'annuaire LDAP
Introduction
Présentation de LDAP
Le protocole
Le modèle de données
Les méthodes d'accès
Le langage de commande
Concevoir un annuaire
Déterminer les besoins, les données, le schéma
Créer une base de données
Installer, configurer et Administrer LDAP
Installer les packages sur le serveur
Les fichiers de configuration du serveur
Ressources
52. TP 1- Installer, configurer et Administrer LDAP
Installer les packages sur le serveur
Les fichiers de configuration du serveur
53. Installation d'un annuaire LDAP et utilisation du langage de commande
Environnement
Configuration du fichier slapd.conf
Création de l'annuaire
Création de l'annuaire
Enrichissement de l'annuaire
Le langage de commande
54. L'annuaire LDAP
Authentification système LDAP sur un système GNU/Linux
Configuration de l'environnement pour l'authentification système
Premiers tests de l'annuaire
Vérification du fonctionnement de l'annuaire.

55. L'annuaire LDAP avec PHP
Utilisation de PHP avec LDAP
Les principales fonctions
Accès anonyme pour une recherche
Accès authentifié pour une recherche
56. Annexes à la séquence sur LDAP
Exemple de fichier LDIF
L'annuaire ldap vu de konqueror
L'annuaire ldap vu de gq
Le schéma vu de gq
Authentification avec php sur LDAP
57. Planification prévisionnelle des séquences LDAP
Prévision des séquences
58. Synchroniser ses machines avec NTP
Introduction à ntpdate et ntpd
ntpdate
Installation de ntpdate
Configuration de ntpdate
ntpd
Installation de ntpd
Configuration de ntpd
Conclusion
Liens utiles
59. Eléments de cours sur le routage et le filtrage de paquets IP
Routage, Filtrage sur les paquets IP
Technique de masquage et de traduction d'adresse
Masquerading et Forwarding
60. ICMP
ICMP et le filtrage de paquets
61. Ipchains
Langage d'Ipchains
62. Iptables
Langage d'Iptables
Exemples d'utilisation d'iptables
La traduction d'adresse - NAT
Le DNAT ou NAT Destination
Le SNAT ou NAT Source
L'IP Masquerade
Exemple sur un réseau privé

63. Application sur le routage et le filtrage de paquets IP
Introduction
Fonctions de filtrage
TD
Schéma de la maquette pour le TP
Première partie : installation et configuration du routage
Règles de filtrage simples
Règles de filtrage par adresse, port et protocoles
64. Outils et ressources complémentaires pour les TP
Iptraf
Documentations complémentaires
65. Concepts généraux sur le routage
Présentation
Jargon réseau sur le routage
Notion de système autonome (SA)
Choix d'une route et métrique
Les protocoles de routages IGP's
Les algorithmes Vector-Distance
Algorithme Link State (Etat de Liens)
Les techniques hybrides
Les protocoles de routages extérieurs EGP
66. Initiation au routage
Initiation au routage
Les principes du routage
Place à la pratique
Conclusion
67. Le routage dynamique avec RIP
Introduction
Pourquoi le routage dynamique ?
Le protocole RIP
Conclusion
68. Le routage dynamique avec OSPF
Introduction
Rappels sur les éléments vus
Les grands principes
Le fonctionnement d'OSPF un peu plus en détail
Conclusion

69. Le routage dynamique avec BGP
Introduction
Les grands principes
Cohabitation entre BGP et les IGP
Conclusion
70. TP sur le routage statique avec Zebra
Introduction
Architecture de Zebra
Topologie de travail
Mise en place
Démarrage du démon zebra
Connexion au démon zebra
Prise en main de Zebra (principe)
Prise en main de Zebra (mise en pratique)
Problèmes rencontrés
71. Multi-router looking glass
Présentation
72. Annexe sur le langage de commande de Zebra
Annexe sur le langage de commande de Zebra
73. Remerciements et licence
Copyright
List of Figures
1.1. OSI et TCP/IP

1.2. datagramme IP
1.3. Protocoles TCP/IP et OSI
1.4. Exemple Telnet
1.5. Modèle client/serveur
1.6. Ports applicatifs
2.1. Classes d'adresses
2.2. Classes d'adresses
2.3. Récapitulatif Classes d'adresses
4.1. Adresses d'une trame Ethernet contenant une requête ARP Request
4.2. Trame Ethernet contenant une requête ARP
4.3. Trame Ethernet contenant une réponse ARP
5.1. Schéma du réseau utilisé
6.1. routeurs interconnectés

6.2. schéma de routage
6.3. schéma de réseau 1
6.4. schéma de réseau 2
7.1. Adressage agrégé
8.1. Capture de trames avec ethereal
8.2. Capture de trames avec ethereal
9.1. Détails de votre tunnel
9.2. Exemple de traceroute6 sur le site Hurricane
9.3. Affichage du site kame.net
9.4. Obtention d'un adresse 64 bits
9.5. Test du site www.kame.net
9.6. Test du site www6.tahi.org
13.1. Schéma maquette
13.2. Schéma du fonctionnement
13.3. Schéma du fonctionnement
13.4. Tunnel HTTP
14.1. Schéma maquette
14.2. Schéma du dialogue
14.3. Encapsulation des trames
16.1. Accés sécurisé sur un répertoire par Apache
23.1. Chiffrement symétrique
23.2. Confidentialité
23.3. Authentification
23.4. Signature électronique
23.5. Certificat
23.6. Le protocole SSL
23.7. HTTP over SSL
25.1. Accès à un serveur SAMBA à partir d'un client Linux par méthode graphique.
25.2. Accès à un serveur SAMBA à partir d'un client Linux par commande manuelle.
25.3. Accès à votre groupe de travail à partir d'un client Windows.
25.4. Accès à votre serveur Samba à partir d'un client Windows.
26.1. Accès à un serveur SAMBA à partir d'un client Linux
27.1. Client DHCP sous Windows XP
27.2. WinIPCFG sous Windows 9x
27.3. Agent de relais DHCP dans un réseau routé
29.1. Dialogue client DHCP, agent de relai DHCPet serveur DHCP
29.2. Maquette agent relais DHCP

30.1. Les domaines
30.2. Les zones
30.3. La délégation
30.4. La résolution inverse
35.1. Message Handler System
35.2. Architecture de Postfix
35.3. Réception des messages
35.4. Traitement des messages
39.1. Architecture globale d'un service Web-mail
39.2. Ouverture de session sur un Web-mail
39.3. Configuration de l'environnement utilisateur
39.4. Voir ses messages
39.5. Le calendrier
39.6. L'aide en ligne
41.1. Configuration du client
41.2. Configuration du client
41.3. Authentification SQUID
42.1. Formulaire de saisie
42.2. Résultat de la requête
43.1. Interrogation de PHP
43.2. Formulaire insert.html
51.1. LDAP : le DIT Directory Information Tree
51.2. LDAP : ls scope
56.1. LDAP sous konqueror
56.2. LDAP sous gq
56.3. Schéma LDAP sous gq
59.1. Squelette de trame IP
59.2. Capture de trame sur le port 80
59.3. Routage pris en charge par le noyau
62.1. Compilation du noyau pour netfilter
63.1. Schéma maquette TD
63.2. Réseau simple
63.3. Réseau intégré
64.1. iptraf
65.1. Système Autonomes
66.1. Internet
66.2. Datagramme
66.3. Topologie 1
66.4. Topologie pratique

67.1. Topologie du réseau
67.2. Topologie de travail
67.3. Architecture de Zebra
68.1. Exemple de topologie
68.2. Le réseau vu de R1
68.3. Le réseau vu de R5
68.4. Un réseau découpé en trois zones
68.5. Topologie de travail
69.1. Un système autonome constitué de réseaux
69.2. Un AS découpé en zones OSPF
69.3. Réseaux d'AS
69.4. Topologie
70.1. Architecture de Zebra
70.2. Topologie 1
70.3. Topologie 1
71.1. MRLG - Multi-Router Looking Glass
List of Examples
44.1. le cluster
44.2. Après avoir connecté le NULL MODEM
44.3. le cluster en réseau doublé
44.4. haresources pour tous
44.5. authkeys
Chapter 1. Eléments de cours sur TCP/IP
La suite de protocoles TCP/IP
Revision History
Revision 0.2 1 Octobre 2005
Table of Contents
OSI et TCP/IP

Abstract
Le document présente la suite de protocoles TCP/IP.
Ce document sert d'introduction à l'ensemble des cours et TP sur les différents protocoles
TCP/IP est l'abréviation de Transmission Control Protocol/Internet Protocol. Ce protocole a été

développé, en environnement UNIX, à la fin des années 1970 à l'issue d'un projet de recherche
sur les interconnexions de réseaux mené par la DARPA (Defense Advanced Research Projects
Agency) dépendant du DoD (Department of Defense) Américain.
TCP/IP ,devenu standard de fait, est actuellement la famille de protocoles réseaux qui gère le
routage la plus répandue sur les systèmes informatiques (Unix/Linux, Windows, Netware...) et
surtout, c'est le protocole de l'Internet.
Plusieurs facteurs ont contribué à sa popularité :
Maturité, Ouverture, Absence de propriétaire, Richesse (il fournit un vaste ensemble de

fonctionnalités), Compatibilité (différents systèmes d'exploitation et différentes architectures
matérielles), et le développement important d'Internet.
La famille des protocoles TCP/IP est appelée protocoles Internet, et a donné son nom au réseau
du même nom. Leurs spécifications sont définies dans des documents du domaine public appelés
RFC (Request For Comments - Appels à commentaires). Ils sont produits par l'IETF ( Internet
Engineering Task Force) au sein de l'IAB (Internet Architecture Board).
La RFC 826, par exemple, définit le protocole ARP.
OSI et TCP/IP
Bien que le protocole TCP/IP ait été développé bien avant que le modèle OSI apparaisse, ils ne
sont pas totalement incompatibles. L'architecture OSI est définie plus rigoureusement, mais ils
disposent tous deux d'une architecture en couches.
Les protocoles TCP et IP ne sont que deux des membres de la suite de protocoles TCP/IP qui
constituent le modèle DOD (modèle en 4 couches). Chaque couche du modèle TCP/IP

correspond à une ou plusieurs couches du modèle OSI (Open Systems Interconnection) défini par
l'ISO (International Standards Organization) :
Figure 1.1. OSI et TCP/IP
Des relations étroites peuvent être établies entre la couche réseau et IP, et la couche transport et
TCP.
TCP/IP peut utiliser une grande variété de protocoles en couche de niveau inférieur, notamment
X.25, Ethernet et Token Ring. En fait, TCP/IP a été explicitement conçu sans spécification de
couche physique ou de liaison de données car le but était de faire un protocole adaptable à la
plupart des supports.
Les protocoles TCP/IP se situent dans un modèle souvent nommé "famille de protocoles TCP/IP".
Les protocoles TCP et IP ne sont que deux des membres de la suite de protocoles IP.
IP est un protocole qui se charge de l'acheminement des paquets pour tous les autres
protocoles de la famille TCP/IP. Il fournit un système de remise de données optimisé sans
connexion. Le terme « optimisé » souligne le fait qu'il ne garantit pas que les paquets transportés
parviennent à leur destination, ni qu'ils soient reçus dans leur ordre d'envoi. La fonctionnalité de
somme de contrôle du protocole ne confirme que l'intégrité de l'en-tête IP. Ainsi, seuls les
protocoles de niveau supérieur sont responsables des données contenues dans les paquets IP (et
de leur ordre de réception).
Le protocole IP travaille en mode non connecté, c'est-à-dire que les paquets émis par le niveau
3 sont acheminés de manière autonome (datagrammes), sans garantie de livraison.
Le datagramme correspond au format de paquet défini par le protocole Internet. Les cinq ou six
(sixième facultatif) premier mots de 32 bits représentent les informations de contrôle appelées en-
tête.
Figure 1.2. datagramme IP

La longueur théorique maximale d'un datagramme IP est de 65535 octets. En pratique la taille
maximale du datagramme est limitée par la longueur maximale des trames transportées sur le
réseau physique. La fragmentation du datagramme (définie dans le 2ème mot de 32 bits) devient
alors nécessaire dès que sa taille ne lui permet plus d'être directement transporté dans une seule
trame physique. Les modules internet des équipements prennent en charge le découpage et le
réassemblage des datagrammes.
Le protocole Internet transmet le datagramme en utilisant l'adresse de destination contenue dans

le cinquième mot de l'en-tête. L'adresse de destination est une adresse IP standard de 32 bits
permettant d'identifier le réseau de destination et la machine hôte connectée à ce réseau.
Dans un réseau TCP/IP, on assigne généralement une adresse IP à 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 également un nom
d'hôte, s'ils ont une adresse IP.
TCP est probablement le protocole IP de niveau supérieur le plus répandu. TCP fournit un
service sécurisé de remise des paquets. TCP fournit un protocole fiable, orienté connexion, au-
dessus d'IP (ou encapsulé à l'intérieur d'IP). TCP garantit l'ordre et la remise des paquets, il
vérifie l'intégrité de l'en-tête des paquets et des données qu'ils contiennent. TCP est responsable
de la retransmission des paquets altérés ou perdus par le réseau lors de leur transmission. Cette
fiabilité fait de TCP/IP un protocole bien adapté pour la transmission de données basée sur la
session, les applications client-serveur et les services critiques tels que le courrier électronique.
La fiabilité de TCP a son prix. Les en-têtes TCP requièrent l'utilisation de bits supplémentaires
pour effectuer correctement la mise en séquence des informations, ainsi qu'un total de contrôle
obligatoire pour assurer la fiabilité non seulement de l'en-tête TCP, mais aussi des données
contenues dans le paquet. Pour garantir la réussite de la livraison des données, ce protocole
exige également que le destinataire accuse réception des données.
Ces accusés de réception (ACK) génèrent une activité réseau supplémentaire qui diminue le débit
de la transmission des données au profit de la fiabilité. Pour limiter l'impact de cette contrainte sur
la performance, la plupart des hôtes n'envoient un accusé de réception que pour un segment sur
deux ou lorsque le délai imparti pour un ACK expire.
Sur une connexion TCP entre deux machines du réseau, les messages (ou paquets TCP) sont
acquittés et délivrés en séquence.

UDP est un complément du protocole TCP qui offre un service de datagrammes sans connexion
qui ne garantit ni la remise ni l'ordre des paquets délivrés. Les sommes de contrôle des données
sont facultatives dans le protocole UDP. Ceci permet d'échanger des données sur des réseaux à
fiabilité élevée sans utiliser inutilement des ressources réseau ou du temps de traitement. Les
messages (ou paquets UDP) sont transmis de manière autonome (sans garantie de livraison.).
Le protocole UDP prend également en charge l'envoi de données d'un unique expéditeur vers
plusieurs destinataires.
Ex: TFTP(trivial FTP) s'appuie sur UDP, DHCP également, Windows utilise UDP pour les
Broadcast en TCP-IP
ICMP est un protocole de maintenance utilisé pour les tests et les diagnostics, qui véhicule des
messages de contrôle. Il permet à deux systèmes d'un réseau IP de partager des informations
d'état et d'erreur.
La commande ping utilise les paquets ICMP de demande d'écho et de réponse à un écho afin de
déterminer si un système IP donné d'un réseau fonctionne. C'est pourquoi l'utilitaire ping est
utilisé pour diagnostiquer les défaillances au niveau d'un réseau IP ou des routeurs.
RIP est un protocole de routage dynamique qui permet l'échange d'informations de routage sur un
inter-réseau. Chaque routeur fonctionnant avec RIP échange les identificateurs des réseaux qu'il
peut atteindre, ainsi que la distance qui le sépare de ce réseau (nb de sauts=nb de routeurs à
traverser). Ainsi chacun dispose de la liste des réseaux et peut proposer le meilleur chemin.
Le protocole ARP permet de déterminer l'adresse physique (ou MAC) d'un noeud à partir de son
adresse IP en effectuant une diffusion du type "qui est X2.X2.X2.X2 ? "
Figure 1.3. Protocoles TCP/IP et OSI

Pour désigner les informations transmises et leur enveloppe, selon le niveau concerné, on parle
de message(ou de flux) entre applications, de datagramme (ou segment) au niveau TCP, de
paquet au niveau IP, et enfin, de trames au niveau de l'interface réseau (Ethernet ou Token
Ring).
Les protocoles du niveau application les plus connus sont :
 HTTP (Hyper Text Transfer Protocol) permet l'accès aux documents HTML et le transfert
de fichiers depuis un site WWW
 FTP (File Transfer Protocol) pour le transfert de fichiers s'appuie sur TCP et établit une
connexion sur un serveur FTP
 Telnet pour la connexion à distance en émulation terminal, à un hôte Unix/Linux.
 SMTP (Simple Mail Transfer Protocol) pour la messagerie électronique (UDP et TCP)
 SNMP (Simple Network Management Protocol) pour l'administration du réseau
 NFS (Network File System) pour le partage des fichiers Unix/Linux.
Les applications réseaux fonctionnent sur le modèle client/serveur. Sur la machine serveur un
processus serveur (daemon) traite les requêtes des clients. Client et serveur dialoguent en
échangeant des messages qui contiennent des requêtes et des réponses.
Prenons par exemple telnet.

Figure 1.4. Exemple Telnet
Figure 1.5. Modèle client/serveur
Une fois le datagramme transmis à l'hôte destinataire, il doit parvenir à l'utilisateur (si le système
est multi-utilisateur) et à l'application visée (si le système est multi-tâches).
 sur la machine cliente, l'utilisateur (usager ou programme) effectue une requête vers une
machine IP serveur sur le réseau. (par exemple telnet host ou ftp host ). Cela se traduit par

la réservation d'un port de sortie TCP ou UDP et l'envoi d'un paquet IP à la machine
serveur. Ce paquet contient un message TCP ou UDP avec un numéro de port
correspondant à l'application demandée sur le serveur.
 sur le serveur, la requête est réceptionnée par le pilote IP, aiguillée vers TCP ou UDP puis
vers le port demandé. Le processus serveur correspondant est à l'écoute des appels sur ce
port (par ex: le daemon telnetd traite les requêtes telnet, le daemon ftpd traite les requêtes
ftp).
 processus client et processus serveur échangent ensuite des messages.
Des numéros de port (entre 0 et 1023) sont réservés pour les applications « standards : les ports
« bien connus » (Well Known Ports), ils ont été assignés par l'IANA. Sur la plupart des systèmes
ils peuvent être seulement employés par des processus du système (ou root) ou par des
programmes exécutés par les utilisateurs privilégiés (liste complète :
http://www.iana.org/assignments/port-numbers ou dans le fichier /etc/services y compris sous
Windows).
D'autres numéros de port sont disponibles pour les applications développées par les utilisateurs
(1024 à 65535).
Figure 1.6. Ports applicatifs
On identifie le protocole de communication entre applications par un numéro de protocole

etl'application par un numéro de port.
Par exemple, les serveurs HTTP dialoguent de manière traditionnelle par le port 80 :
http ://www.sncf.com/index.htm <=> http :// www.sncf.com:80/index.htm
Les numéros de protocole et de port sont inclus dans le datagramme.

Une fois la connexion établie entre le client et le serveur, ceux-ci peuvent s'échanger des
informations selon un protocole défini selon l'applicatif. Le client soumet des requêtes auxquelles
répondra le serveur.
Ce mode de communication s'appuie sur la couche "socket". Cette couche est une interface entre
la couche présentation et transport. Elle permet la mise en place du canal de communication entre
le client et le serveur. On peut schématiquement dire qu'un socket fournit un ensemble de
fonctions. Ces fonctions permettent à une application client/serveur d'établir un canal de
communication entre 2 ou plusieurs machines, qui utilisent un protocole de transport (TCP ou
UDP) et un port de communication.
Service réseau N° de Port Type Commentaire
ICMP 7 TCP/UDP Commandes Ping
Netstat 15 TCP/UDP Etat du réseau
FTP 21 TCP Transfert de fichiers
SSH 22 TCP/UDP SSH Remote Login Protocol
Telnet 23 TCP Connexion via terminal réseau
SMTP 25 TCP Envoi de courrier
DNS 53 TCP/UDP Serveurs de noms de domaine
HTTP 80 TCP Serveur Web
Pop3 110 TCP Réception de courrier
nntp 119 TCP Service de news
ntp 123 UDP Protocole temps réseau
nbname 137 TCP/UDP Service de Nom Netbios
netbios-ssn 139 TCP/UDP Service de Session Netbios
imap 143 TCP/UDP Protocole d'accès messagerie Internet
SNMP 161 UDP Administration de réseau

Chapter 2. Eléments de cours sur l'adressage IP
Revision History
Table of Contents

Adressage IP
Classes d'adresses
Les sous-réseaux
Sous-réseaux
Abstract
Le document présente l'adressage IP sur un réseau local et en environnement routé
Ce document sert d'introduction à l'ensemble des cours et TP sur les différents protocoles
Mots clés : Adresse physique (MAC), Adresse IP, masque, sous-réseau, sur-réseau, CIDR
Deux cartes réseaux qui communiquent s'échangent des messages (suite de bits) appelés trames
(frame). Tous les postes connectés au même câble reçoivent le message, mais seul celui à qui il
est destiné le lit.
Comment sait-il que cette trame lui est adressée ?
Car il reconnaît l'adresse de destination, contenue dans la trame comme étant la sienne.
Comment sait il qui lui a envoyé la trame ?
Car la trame contient aussi l'adresse de l'émetteur.

Au niveau de la couche liaison, les noeuds utilisent une adresse dite « physique » pour
communiquer. L'adresse correspond à l'adresse de la carte réseau. On parle d'adresse
physique, d'adresse MAC (Medium Access Control) ou d'adresse de couche 2 (référence au
modèle OSI).
Cette adresse est identique pour les réseaux Ethernet, Token Ring et FDDI. Sa longueur est de
48 bits soit six octets (par exemple : 08-00-14-57-69-69) définie par le constructeur de la carte.
Une adresse universelle sur 3 octets est attribuée par l'IEEE à chaque constructeur de matériel
réseau. Sur les réseaux CCITT X.25, c'est la norme X.121 qui est utilisée pour les adresses
physiques, qui consistent en un nombre de 14 chiffres.
L'adresse MAC identifie de manière unique un noeud dans le monde. Elle est physiquement
liée au matériel (écrite sur la PROM), c'est à dire à la carte réseau.
L'adresse d'une carte réseau correspond à l'adresse d'un poste et d'un seul. Or les postes sont
généralement regroupés en réseau.
Comment identifier le réseau auquel appartient le poste ?
Il faut une adresse logique qui soit indépendante de l'adresse physique.
C'est ce que propose le protocole IP et le protocole IPX.
Pourquoi identifier le réseau ?
Pour permettre à 2 postes qui ne sont pas connectés au même réseau de communiquer.
Cela est impossible avec une adresse MAC, il faut une adresse de niveau supérieur, comme nous
le verrons un peu plus loin et surtout avec le routage IP.
Le message véhiculé par la trame va contenir une autre adresse destinataire dont un des objectifs
sera de définir le réseau destinataire du message. On appelle le message contenu dans une
trame un paquet.
Ce qu'il nous faut savoir à ce stade, c'est qu'une machine sait que le paquet n'est pas destiné au
réseau si l'adresse réseau de destination est différente de la sienne, dans ce cas elle envoie le
paquet à une machine spéciale (la passerelle ou routeur) dont le rôle est d'acheminer les paquets
qui sortent du réseau.
Cette adresse dite logique du noeud (car elle est attribuée par logiciel à un hôte, plus
précisément à une carte réseau) contenue dans le paquet est l'adresse IP, est définie
indépendamment de toute topologie d'ordinateur ou de réseau. Son format reste identique quel
que soit le support utilisé.
Les machines (hôtes) d'un réseau TCP/IP sont identifiées par leur adresse IP.
Toute machine sur un réseau IP a donc 2 adresses, une adresse MAC et une adresse IP.

Les processus de niveaux supérieurs utilisent toujours l'adresse IP et donc lorsqu'un processus
communique avec un autre processus, il lui envoie un message dont l'adresse destinataire est
une adresse IP, mais pour pouvoir atteindre la carte réseau du destinataire, il faut connaître son
adresse MAC. Le rôle du protocole ARP (Adress Resolution Protocol) est d'assurer la
correspondance entre l'adresse IP et l'adresse MAC.
Les réseaux connectés au réseau Internet mondial doivent obtenir un identificateur de réseau
officiel auprès du bureau de l'Icann de l'Inter-NIC (Network Information Center) afin que soit
garantie l'unicité des identificateurs de réseau IP sur toute la planète. Une adresse est attribuée
au réseau privé dont l'administrateur en fait la demande auprès du NIC (http://www.nic.fr).
Après réception de l'identificateur de réseau, l'administrateur de réseau local doit attribuer des
identificateurs d'hôte uniques aux ordinateurs connectés au réseau local. Les réseaux privés qui
ne sont pas connectés à Internet peuvent parfaitement utiliser leur propre identificateur de réseau.
Toutefois, l'obtention d'un identificateur de réseau valide de la part du centre InterNIC leur permet
de se connecter ultérieurement à Internet sans avoir à changer les adresses des équipements en
place.
Chaque noeud (interface réseau) relié à l'Internet doit posséder une adresse IP unique.
Adressage IP
Les adresses IP sont des nombres de 32 bits qui contiennent 2 champs :
 Un identificateur de réseau (NET-ID): tous les systèmes du même réseau physique

doivent posséder le même identificateur de réseau, lequel doit être unique sur l'ensemble
des réseaux gérés.
 Un identificateur d'hôte (HOST-ID): un noeud sur un réseau TCP/IP est appelé hôte, il
identifie une station de travail, un serveur, un routeur ou tout autre périphérique TCP/IP au
sein du réseau.
La concaténation de ces deux champs constitue une adresse IP unique sur le réseau.
Pour éviter d'avoir à manipuler des nombres binaires trop longs, les adresses 32 bits sont divisées
en 4 octets. Ce format est appelé la notation décimale pointée, cette notation consiste à
découper une adresse en quatre blocs de huit bits. Chaque bloc est ensuite converti en un
nombre décimal.
Chacun des octets peut être représenté par un nombre de 0 à 255.
Ex : 130.150.0.1
Exemple :
L'adresse IP 10010110110010000000101000000001 est d'abord découpée en quatre blocs :

10010110.11001000.00001010.00000001 puis, chaque bloc est converti en un nombre décimal
pour obtenir finalement 150.200.10.1
= >4 nombres entiers (entre 0 et 255) séparés par des points.
= >4 octets
L'écriture avec les points est une convention, le codage en machine est binaire.
Classes d'adresses
La communauté Internet a défini trois classes d'adresses appropriées à des réseaux de

différentes tailles. Il y a, a priori, peu de réseaux de grande taille (classe A), il y a plus de réseaux
de taille moyenne (classe B) et beaucoup de réseaux de petite taille (classe C). La taille du réseau
est exprimée en nombre d'hôtes potentiellement connectés.
Le premier octet d'une adresse IP permet de déterminer la classe de cette adresse.
Les adresses disponibles (de 0.0.0.0 à 255.255.255.255) ont donc été découpées en plages
réservées à plusieurs catégories de réseaux.
Pour éviter d'avoir recours aux organismes NIC à chaque connexion d'un nouveau poste, chaque
société se voit attribuer une plage d'adresse pour son réseau. Le nombre d'adresses disponibles
dans chaque plage dépend de la taille du réseau de la société. Les grands réseaux sont dits de
classe A (IBM, Xerox , DEC, Hewlett-Packard), les réseaux de taille moyenne sont de classe B
(Microsoft en fait partie !), et les autres sont de classe C.
Figure 2.1. Classes d'adresses
Par exemple, l'adresse d'un poste appartenant à un réseau de classe A est donc de la forme :
0AAAAAAA.xxxxxxxx.xxxxxxxx.xxxxxxxx, avec A fixé par le NIC et x quelconque.
Exemple
IBM a obtenu l'adresse 9 (en fait, on devrait dire 9.X.X.X, mais il est plus rapide de n'utiliser que la
valeur du premier octet). 9 est bien de classe A car 9d=00001001b
Cela signifie que chaque adresse IP du type 00001001.xxxxxxxx.xxxxxxxx.xxxxxxxx, avec x

prenant la valeur 0 ou 1, fait partie du réseau d'IBM.

Malgré ces possibilités d'adressage, la capacité initialement prévue est insuffisante et sera mise à
défaut d'ici quelques années. L'IPNG (Internet Protocol Next Generation) ou Ipv6 devrait
permettre de résoudre ces difficultés en utilisant un adressage sur 16 octets noté en héxadécimal.
L'adresse IP se décompose, comme vu précédemment, en un numéro de réseau et un numéro de

noeud au sein du réseau.
Afin de s'adapter aux différents besoins des utilisateurs, la taille de ces 2 champs peut varier.
On définit ainsi les 5 classes d'adresses notées A à E:
Figure 2.2. Classes d'adresses
ex. : Soit l'adresse IP suivante : 142.62.149.4
142 en décimal = 100011102 en binaire
Le mot binaire commence par les bits 102 donc il s'agit d'une adresse de classe B. Ou, plus
simple : 142 est compris entre 128 et 191.
S'agissant d'une adresse de classe B, les deux premiers octets (a et b) identifient le réseau. Le
numéro de réseau est donc : 142.62.0.0
Les deux derniers octets (c et d) identifient l'équipement hôte sur le réseau.
Finalement, cette adresse désigne l'équipement numéro 149.4 sur le réseau 142.62.
Les adresses réservées ne peuvent désigner une machine TCP/IP sur un réseau.
L'adresse d'acheminement par défaut (route par défaut.) est de type 0.X.X.X. Tous les paquets
destinés à un réseau non connu, seront dirigés vers l'interface désignée par 0.0.0.0.
NB : 0.0.0.0 est également l'adresse utilisée par une machine pour connaître son adresse IP
durant une procédure d'initialisation (DHCP).

L'adresse de bouclage(loopback): l'adresse de réseau 127 n'est pas attribuée à une société, elle
est utilisée comme adresse de bouclage dans tous les réseaux. Cette adresse sert à tester le
fonctionnement de votre carte réseau. Un ping 127.0.0.1 doit retourner un message correct. Le
paquet envoyé avec cette adresse revient à l'émetteur.
Toutes les adresses de type 127.X.X.X ne peuvent pas être utilisées pour des hôtes. La valeur de
'x' est indifférente. On utilise généralement 127.0.0.1
L'adresse de réseau est une adresse dont tous les bits d'hôte sont positionnés à 0 (ex 128.10.0.0
adresse de réseau du réseau 128.10 de classe B). Elle est utilisée pour désigner tous les postes
du réseau. On utilise cette adresse dans les tables de routage.
Les noms de réseaux de type :
 X.Y.Z.0 (de 192.0.0.0 à 223.255.255.0) sont dits de classe C

 X.Y.0.0 (de 128.0.0.0 à 191.255.0.0) sont dits de classe B
 X.0.0.0. (de 1.0.0.0 à 126.255.255.254) sont dits de classe A
L'adresse de diffusion est une adresse dont tous les bits d'hôte sont positionnés à 1 (ex :
128.10.255.255 adresse de diffusion du réseau 128 de classe B).
Elle est utilisée pour envoyer un message à tous les postes du réseau.
Les adresses "privées"
Les adresses suivantes (RFC 1918) peuvent également être librement utilisées pour monter un
réseau privé :
A 10.0.0.0 255.0.0.0
B 172.16.0.0 à 172.31.255.255 255.240.0.0
C 192.168.0.0 à 192.168.255.255 255.255.0.0
Aucun paquet provenant de ces réseaux ou à destination de ces réseaux, ne sera routé sur
l'Internet (ces adresses sont néanmoins « routables » sur le réseau local).
Figure 2.3. Récapitulatif Classes d'adresses

Le rôle du masque de réseau (netmask) est d'identifier précisément les bits qui concernent le N°
de réseau d'une adresse (il "masque" la partie hôte de l'adresse).
Un bit à 1 dans le masque précise que le bit correspondant dans l'adresse IP fait partie du N° de
réseau ; à l'inverse, un bit à 0 spécifie un bit utilisé pour coder le N° d'hôte.
Ainsi, on a un masque dit "par défaut" qui correspond à la classe de ce réseau.
Exemple: dans un réseau de classe A sans sous-réseau, le premier octet correspond à l'adresse
du réseau donc le netmask commence par 11111111 suivi de zéros soit 255.0.0.0.
D'où le tableau suivant :
Classe Netmask
A 255.0.0.0
B 255.255.0.0
C 255.255.255.0
Ex : Si mon adresse IP est 149.127.1.110 alors je travaille avec une adresse de classe B. Mon N°
de réseau est 149.127.0.0 et mon masque 255.255.0.0.
Les sous-réseaux
Les avantages de la segmentation en sous-réseau sont les suivants :
1. Utilisation de plusieurs media (câbles, supports physiques). La connexion de tous les

noeuds à un seul support de réseau peut s'avérer impossible, difficile ou coûteuse lorsque

les noeuds sont trop éloignés les uns des autres ou qu'ils sont déjà connectés à un autre
media.
2. Réduction de l'encombrement. Le trafic entre les noeuds répartis sur un réseau unique
utilise la largeur de bande du réseau. Par conséquent, plus les noeuds sont nombreux, plus
la largeur de bande requise est importante. La répartition des noeuds sur des réseaux
séparés permet de réduire le nombre de noeuds par réseau. Si les noeuds d'un réseau de
petite taille communiquent principalement avec d'autres noeuds du même réseau,
l'encombrement global est réduit.
3. Economise les temps de calcul. Les diffusions (paquet adressé à tous) sur un réseau
obligent chacun des noeuds du réseau à réagir avant de l'accepter ou de la rejeter.
4. Isolation d'un réseau. La division d'un grand réseau en plusieurs réseaux de taille
inférieure permet de limiter l'impact d'éventuelles défaillances sur le réseau concerné. Il
peut s'agir d'une erreur matérielle du réseau (une connexion
5. Renforcement de la sécurité. Sur un support de diffusion du réseau comme Ethernet,

tous les noeuds ont accès aux paquets envoyés sur ce réseau. Si le trafic sensible n'est
autorisé que sur un réseau, les autres hôtes du réseau n'y ont pas accès.
6. Optimisation de l'espace réservé à une adresse IP. Si un numéro de réseau de classe A

ou B vous est assigné et que vous disposez de plusieurs petits réseaux physiques, vous
pouvez répartir l'espace de l'adresse IP en multiples sous-réseaux IP et les assigner à des
réseaux physiques spécifiques. Cette méthode permet d'éviter l'utilisation de numéros de
réseau IP supplémentaires pour chaque réseau physique.
Les masques de sous-réseaux (subnet mask) permettent de segmenter un réseau en plusieurs

sous-réseaux. On utilise alors une partie des bits de l'adresse d'hôte pour identifier des sous-
réseaux.
L'adressage de sous-réseau permet de définir des organisations internes de réseaux qui ne sont
pas visibles à l'extérieur de l'organisation. Cet adressage permet par exemple l'utilisation d'un
routeur externe qui fournit alors une seule connexion Internet.
Toutes les machines appartenant à un sous-réseau possèdent le même numéro de réseau.
On utilise le même principe que pour le masque par défaut sur l'octet de la partie hôte auquel on
va prendre des bits. Ainsi, le masque de sous-réseau d'une adresse de classe B commencera
toujours par 255.255.xx.xx
Pour connaître l'adresse du sous-réseau auquel une machine appartient, on effectue en réalité un
ET logique entre l'adresse de la machine et le masque.
Adresse : 200.100.40.33 11001000.01100100.00101000.00100001
Masque : 255.255.255.224 11111111.11111111.11111111.11100000
Opération ET 11001000.01100100.00101000.00100000
=> La machine appartient au sous-réseau : 200.100.40.32

Nous voyons dans ce deuxième exemple que nous avons pris 2 bits sur le dernier octet de notre
adresse. Ces 2 bits vont nous permettre de construire plusieurs sous-réseaux:
Ex : adresse : 192.0.0.131
Masque : 255.255.255.192
Conversion de l'adresse en binaire : 11000000 00000000 00000000 10000011
Conversion du masque en binaire : 11111111 11111111 11111111 11000000
Décomposition de l'adresse (R,H) : 11000000 00000000 00000000 10000011
La machine appartient au sous-réseau 192.0.0.128 et a l'adresse 3(11 en binaire)
Pour des raisons de commodité, on préférera réserver un octet entier pour coder le numéro de
sous réseau. De même la théorie ne nous oblige pas à prendre les bits contigus d'un masque,
même si c'est ce que nous utiliserons en pratique.
Important : pour parer à d'éventuels problèmes de routage et d'adressage, tous les ordinateurs
d'un réseau logique doivent utiliser le même masque de sous-réseau et le même identificateur de
réseau.
Sous-réseaux
Nombre de sous-réseaux
Le nombre théorique de sous-réseaux est égal à 2^n, n étant le nombre de bits à 1 du masque,
utilisés pour coder les sous-réseaux.
Exemple :
Adresse de réseau : 200.100.40.0
Masque : 255.255.255.224
224 = 11100000 donc 3 bits pour le N° de sous-réseau et 5 bits pour l'hôte.
Le nombre de sous-réseaux est donc de : 23 =8.
Remarque : la RFC 1860 (remplacée par la RFC 1878) stipulait qu'un numéro de sous réseau ne
peut être composé de bits tous positionnés à zéro ou tous positionnés à un.
Autrement dit, dans notre exemple, on ne pouvait pas utiliser le sous-réseau 0 et le sous-réseau
224. Le premier nous donnant une adresse de sous-réseau équivalente à l'adresse du réseau soit
200.100.40.0. Le deuxième nous donnant une adresse de sous-réseau dont l'adresse de diffusion
se confondrait avec l'adresse de diffusion du réseau. Le nombre de sous-réseaux aurait alors été
de seulement : 2^3-2 =6.
Il est donc important de savoir quelle RFC est utilisée par votre matériel pour savoir si les
adresses de sous-réseau composées de bits tous positionnés à zéro ou tous positionnés à un
sont prises en compte ou non.

Adresse des sous-réseaux
Il faut donc maintenant trouver les adresses des sous-réseaux valides en utilisant les bits à 1 du
masque.
Pour l'exemple précédent, il faut utiliser les 3 premiers bits:
000 00000 = 0
001 00000 = 32
010 00000 = 64
011 00000 = 96
100 00000 = 128
101 00000 = 160
110 00000 = 192
111 00000 = 224
On constate que le pas entre 2 adresses de sous-réseau est de 32 = 25 correspondant au nombre

théorique d'hôtes par sous-réseau.
Adresse de diffusion d'un sous-réseau
Il faut mettre tous les bits de la partie hôte à 1.
Cherchons l'adresse de diffusion des sous réseaux précédents.
 Avec le masque 255.255.255.224
Pour le sous-réseau 200.100.40.32
32 = 001 00000 donc l'adresse de diffusion est 001 11111 = 63.
L'adresse de diffusion complète est donc 200.100.40.63
Pour le sous-réseau 200.100.40.64 l'adresse de diffusion est 200.100.40.95
...ETC ...
Avec le masque 255.255.255.129
Pourquoi 254 et pas 255 car avec 255 le dernier bit serait à 1 donc on serait dans le sous-réseau
10000001 , en décimal 129.

Nombre de postes d'un sous-réseau
Le nombre de postes est égal à 2n, n étant le nombre de bits à 0 du masque permettant de coder
l'hôte. A ce chiffre il faut enlever 2 numéros réservés :
 tous les bits à zéro qui identifie le sous-réseau lui-même.
 tous les bits à 1 qui est l'adresse de diffusion pour le sous-réseau.
Exemples :
Soit le masque 255.255.255.224
224 = 11100000 donc 3 bits pour le N° de sous-réseau et 5 bits pour l'hôte
le nombre de poste est donc de : 2^5 -2 =30 postes.
De même, avec le masque non contigu 255.255.255.129 le nombre de postes sera de 2^6-2 = 62
postes
En 1992 la moitié des classes B étaient allouées, et si le rythme avait continué, au début de 1994
il n'y aurait plus eu de classe B disponible et l'Internet aurait bien pu mourir par asphyxie ! Pour
éviter la diminution des identificateurs de réseau, et la saturation des routeurs (nombre de routes
trop important) les autorités d'lnternet ont conçu un schéma appelé adressage de sur-réseaux
( ou super-réseaux).
L'adressage de sur-réseaux par opposition à la segmentation en sous-réseaux, emprunte des bits

de l'identificateur de réseau pour les attribuer aux identificateurs d'hôtes afin d'optimiser le
routage.
Par exemple, au lieu d'allouer un identificateur de réseau de classe B, dans une entreprise
comportant 2000 hôtes, InterNic alloue une plage séquentielle de 8 identificateurs de réseau de
classe C. Chaque identificateur de réseau de classe C gère 254 hôtes pour un total de 2 032
identificateurs d'hôte.
Alors que cette technique permet de conserver des identificateurs de réseau de classe B, elle crée
un nouveau problème.
En utilisant des techniques de routage conventionnelles, les routeurs d'lnternet doivent désormais
comporter huit entrées (en RAM) dans leurs tables de routage pour acheminer les paquets IP vers
l'entreprise. La technique appelée CIDR (Classless Inter-Domain Routing) permet de réduire les
huit entrées utilisées dans l'exemple précédent à une seule entrée correspondant à tous les
identificateurs de réseau de classe C utilisés par cette entreprise.
Soit les huit identificateurs de réseau de classe C commençant par l'identificateur de réseau
220.78.168.0 et se terminant par l'identificateur de réseau 220.78.175.0, l'entrée de la table de
routage des routeurs d'lnternet devient :
Identificateur Masque de Masque de sous réseau

de réseau sous réseau (en binaire)
220.78.168.0 255.255.248.0 11111111 11111111 11111000 00000000
En effet 168 en binaire donne : 10101000
et 175 donne : 10101111
la partie commune porte bien sur les 5 1ers bits
d'où le masque : 11111000
Dans l'adressage de sur-réseaux, la destination d'un paquet est déterminée en faisant un ET

logique entre l'adresse IP de destination et le masque de sous-réseau de l'entrée de routage. En
cas de correspondance avec l'identificateur de réseau, la route est utilisée. Cette procédure est
identique à celle définie pour l'adressage de sous-réseaux.
La notation CIDR définit une convention d'écriture qui spécifie le nombre de bits utilisés pour
identifier la partie réseau (les bits à 1 du masque).
Les adresses IP sont alors données sous la forme :
142.12.42.145 / 24 <=> 142.12.42.145 255.255.255.0
153.121.219.14 / 20<=> 153.121.219.14 255.255.240.0
Dans cette écriture les nombres 24 et 20 représentent le nombre de bits consacrés à la

codification du réseau (et sous réseau).
Remarque : Les RFC 1518 et 1519 définissent le CIDR (Classless Inter-Domain Routing).
Chapter 3. Fichiers de configuration du réseau et commandes de base
Table of Contents

La commande arp

La commande route
La commande netstat
La commande dig
La commande host
Abstract
Présentation des principaux fichiers de configuration du réseau et des commandes

d'administration système et réseau.
Ce document présente les principaux fichiers de configuration d'une machine en réseau, et les
commandes d'administration réseau.
Il est composé de 6 parties:
1. Les fichiers de configuration réseau

2. La commande ifconfig
3. La commande arp
4. La commande route
5. La commande netstat
6. La commande traceroute
Le fichier hosts donne un moyen d'assurer la résolution de noms, de donner un nom FQDN à un
hôte
Exemple de fichier hosts
127.0.0.1 localhost localhost.localdomain

192.168.1.1 uranus.foo.org uranus
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.
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 hosts, en cas d'échec avec le DNS.
Il permet d'affecter les serveurs de noms.
Exemple
Nameserver 192.168.1.1
Ici le fichier déclare le nom de domaine et les 3 machines chargées de la résolution de noms.
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

La commande ifconfig permet la configuration locale ou à distance des interfaces réseau de tous
types d'équipements (unité centrale, routeur). Sans paramètres, la commande ifconfig permet
d'afficher les paramètres réseau des interfaces.
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
metricparamè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
collisions:0
Interrupt:10 Base address:0x6100
2 - Désactivez les 2 interfaces lo et eth0
ifconfig lo down
ifconfig eth0 down
3 - Tapez 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*/
/* le 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.
La commande arp
Description de la commande
La commande arp permet de visualiser ou modifier la table du cache arp de l'interface. Cette table
peut être statique et (ou) dynamique. Elle donne la correspondance entre une adresse IP et une
adresse MAC (Ethernet).
A 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 Live).

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 du cache ARP.
Cela est réalisé par la configuration de tables ARP statiques.
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. A 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,
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
D - On a dans la table arp ? (195.6.2.3) at 00: 00:45:2D:33:C2 [ether] on eth0
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,
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

D - On a dans la table arp ? (192.5.1.9) at 09:44:3C:DA:3C:04 [ether] on eth0
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.
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.0 U 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
Warning
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 a 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.
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.
Etat 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

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
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. A 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 ?
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.
La commande dig
La commande dig remplace ce qui était la commande nslookup. Cette commande sert à
diagnostiquer des dysfonctionnements dans la résolution de noms (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
retourne les informations sur le domaine concerné.
Il est ensuite possible d'intérroger sur tout type d'enregistrement : SOA, MX, A, CNAME, PTR...
La commande host
La commande host interroge les serveurs de noms. 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.
Chapter 4. Eléments de cours sur ARP

Revision History
Table of Contents
Le protocole ARP

Abstract
Résumé sur ARP - RFC 826
Le protocole ARP
Chaque carte réseau possède une adresse physique MAC unique sur 48 bits (6 octets) . La
communication entre machines ne peut donc avoir lieu que lorsque celles-ci connaissent leurs
adresses MAC. Pour envoyer les paquets IP vers les autres noeuds du réseau, les noeuds qui
utilisent les protocoles TCP/IP traduisent les adresses IP de destination en adresses MAC.
Ainsi, lorsqu'un noeud N1 du réseau TCP/IP X1.X1.X1.X1 veut émettre un paquet TCP/IP (dans
une trame Ethernet) vers une machine N2 d'adresse IP (X2.X2.X2.X2), il faut qu'il connaisse
l'adresse Ethernet de N2 (E2.E2.E2.E2.E2.E2). L'application émettrice ajoute son adresse IP au
paquet et l'application réceptrice peut utiliser cette adresse IP pour répondre.
Sur les réseaux à diffusion, tels qu'Ethernet et Token-Ring, le protocole IP nommé ARP (Address
Resolution Protocol) fait le lien entre les adresses IP et les adresses physiques (ou MAC).
Pour réaliser l'association @ip / @ Ethernet l'émetteur N1 utilise le protocole ARP dont le principe
est le suivant :
L'émetteur envoie une trame Ethernet de diffusion (broadcast), c'est-à-dire où @destinataire : tous
à 1 soit FFFFFFFFFFFF contenant un message ARP demandant
qui est X2.X2.X2.X2 ?
Figure 4.1. Adresses d'une trame Ethernet contenant une requête ARP Request
Figure 4.2. Trame Ethernet contenant une requête ARP

Toutes les machines IP du réseau local reçoivent la requête. N2 qui a l'adresse X2.X2.X2.X2 se
reconnaît, et elle répond à N1 ie X1.X1.X1.X1 (dans une trame destinée à E1.E1.E1.E1.E1.E1)
Figure 4.3. Trame Ethernet contenant une réponse ARP
Pour accélérer la transmission des paquets et réduire le nombre de requêtes de diffusion ARP,
chaque noeud dispose d'un cache ARP de résolution d'adresse. Chaque fois que le noeud
diffuse une requête ARP et reçoit une réponse, il crée une entrée dans une table de
correspondance stockée en mémoire cache (@ip / @ Ethernet).
Lorsque le noeud envoie un autre paquet IP, il cherche d'abord l'adresse IP dans son cache. S'il la
trouve, il utilise alors l'adresse physique correspondante pour son paquet.
Quand un poste cherche l'adresse physique correspondant à une adresse IP qu'il connaît, le
protocole ARP se met en oeuvre et réalise donc les tâches suivantes :
1. recherche dans le cache ARP de la machine si l'adresse IP du destinataire y figure, s'il la

trouve, il ajoute alors l'adresse physique correspondante dans l'en-tête de la trame à
émettre.
2. réalisation d'un broadcast (ARP request) sur le réseau en demandant à qui correspond
l'adresse IP à résoudre : il diffuse un paquet ARP qui contient l'adresse IP du destinataire

3. les machines du réseau comparent l'adresse demandée à leur adresse et le noeud
correspondant renvoie son adresse physique au noeud qui a émis la requête (ARP reply) .
4. stockage de l'adresse physique lorsque le destinataire répond dans le cache ARP de la

machine
Remarque : chaque entrée de la table à une durée de vie limitée (2 minutes mini sous Windows).
Voici pour exemple ce que donne le programme tcpdump avec la commande ping 192.168.1.2 à
partir de la machine uranus alors que la table ARP de l'hôte uranus est vide :
13:17:14.490500 arp who-has 192.168.1.2 tell uranus.planete.net

13:17:14.490500 arp reply 192.168.1.2 is-at 0:40:33:2d:b5:dd
13:17:14.490500 uranus.planete.net > 192.168.1.2: icmp: echo request
13:17:14.490500 192.168.1.2 > uranus.planete.net: icmp: echo reply
13:17:15.500500 uranus.planete.net > 192.168.1.2: icmp: echo request
13:17:15.500500 192.168.1.2 > uranus.planete.net: icmp: echo reply
Explications :
Ligne 1, uranus demande qui est 192.168.1.2 (requête ARP) Le paquet est diffusé à tous les hôtes
du réseau.
Ligne 2 réponse ARP : je suis à l'adresse Ethernet 00:40:33:2d:b5:dd
Lignes 3 à 6 : échanges de paquets ICMP entre les 2 hôtes.
Chapter 5. La résolution d'adresses physiques - Travaux Pratiques

Revision History
Table of Contents

Le cache ARP
La commande ARP
Conditions de réalisation
Ce TP nécessite des machines Windows ou Linux reliées par un réseau Ethernet et TCP/IP, et
disposant d'un routeur connecté à internet. L'adresse du réseau utilisé par ce TP est 10.69.0.0,

mais peut être modifiée sans problème. Il faut disposer d'un analyseur de trames, les exemples
utilisent Ethereal (http://www.ethereal.com/).
Figure 5.1. Schéma du réseau utilisé
Ces tests peuvent être réalisés à partir d'un poste de travail Linux ou Windows
 à partir de votre poste, ouvrez une fenêtre d'invite de commandes

 quelle commande utilisez-vous pour afficher les informations concernant votre carte réseau
?
 testez l'adresse IP de loopback pour vérifier que les liaisons définies par TCP/IP sont
correctes : ping 127.0.0.1
 testez avec l'adresse IP de votre poste
 testez avec l'adresse du poste d'un voisin
 testez avec l'adresse du réseau : 10.69.0.0 (notez le résultat)
Que signifient les réponses ?
 testez avec l'adresse de broadcast sur ce réseau : 10.69.255.255 (notez le résultat)
Que signifient les réponses ?
 testez une adresse IP non utilisée sur le réseau par exemple 10.69.0.99 (idem)
Que peut-on déduire de la réponse ? Le poste existe t-il ? Le poste n'est pas actif ?
 testez l'adresse de la passerelle : 10.69.0.254

 testez une adresse existante au delà de votre passerelle : 192.168.0.n (idem)
Comment expliquez vous votre résultat ? Pourquoi ce poste répond-il alors que son adresse
réseau est différente de la vôtre ?

 testez une adresse au hasard ne faisant pas partie du réseau : 200.110.20.37 (idem)
Que pouvez vous déduire du résultat ?
2 stations pour dialoguer doivent utiliser les adresses MAC, il faut donc un moyen pour passer de
l'adresse IP à l'adresse MAC et vice versa. IP fournit pour cela le protocole ARP (Adress
Resolution Protocol) et RARP (Reverse Adress Resolution Protocol)
Le cache ARP
 Affichez le cache ARP : tapez la commande arp -aàl'invite de commandes

 Notez le résultat
 faites un ping sur une autre station
 Affichez de nouveau le cache arp (notez le résultat)
Que contient le cache ARP à l'issue du PING ?
 faites un ping sur l'adresse interne de votre passerelle internet (192.168.0.254)

 affichez le cache arp (notez le résultat)
Que contient le cache ? Expliquez le résultat. Cela confirme-t-il vos hypothèses précédentes
(question 1) ?
 Décrivez les entrées du cache ARP
La commande ARP
Utilisez les commandes pour obtenir de l'aide sur la commande arp : arp /? ou arp --help et man
arp sous Liniux
 videz le cache arp (notez l'instruction qu'il faut utiliser)

 Sous Linux reprenez les opérations du paragraphe précédent, afin de mettre des
informations en cache. Pour vider le cache vous utiliserez les instructions suivantes :
ifconfig eth0 down

arp -a /* vous constaterez qu'il n'y a plus rien en cache */
ifconfig eth0 up
 A l'aide de la commande « man ifconfig », expliquez ce que font les commandes ifconfig
eth0 down et ifconfig eth0 up.
Reprenons les manipulations une fois le cache vidé
 notez l'adresse ethernet du poste voisin

 ajoutez manuellement cette entrée arp dans la cache (donnez l'instruction qu'il faut passer)

 affichez votre cache arp pour vérifier.
Quel est le type de l'entrée ?
 testez cette entrée avec ping
Quelles sont les différentes possibilités de la commande ARP ?
 utiliser la commande arp permettant de modifier l'adresse matérielle de la passerelle par

défaut (donnez l'instruction qu'il faut utiliser)
(donnez lui par exemple 08-00-02-22-22-20 qui est une fausse adresse)
 faites un ping sur votre passerelle (notez le résultat)
expliquez-le
 faites un ping au delà de votre passerelle (notez le résultat)
expliquez-le
 supprimez cette entrée incorrecte
quelle est l'instruction ?
 prenez l'adresse ethernet d'un poste

 prenez l'adresse ip d'un autre poste
 affectez avec arp l'adresse ip à l'adresse ethernet
 testez l'adresse ip avec ping
Notez le résultat et expliquez-le
 Lancer ethereal et au besoin sélectionnez la carte réseau sur laquelle vous souhaitez
capturer le trafic (vérifiez son adresse Mac)
 Démarrer la capture : Capture/Start,activez le rafraîchissement temps réel et OK
 générer du trafic réseau
- ouvrez une fenêtre d'invite de commande xterm
- faites un ping sur l'adresse ip de votre voisin

 arrêter la capture des données réseau. Revenez au moniteur réseau « stop »
 Analyser les données capturées
Le moniteur réseau vous affiche trois fenêtres.
Décrivez les types d'informations que vous obtenez dans chacune de ces fenêtres.
 Mettre en évidence des données capturées


o Menu Display/Colorize Display.
o Ajouter une option name : NomName, filter : icmp
o Choisissez les couleurs de fond et de texte et validez.
 Afficher le détail des trames ICMP
 dans la première fenêtre sélectionnez une trame ICMP dont la colonne de description
contient l'entrée « REQUEST ».
 dans la fenêtre de détails, cliquez sur le signe + devant ICMP (le contenu du paquet ICMP
est mis en évidence et affiché selon la notation hexadécimale dans la fenêtre du bas)
 dans la fenêtre détail, cliquez sur ICMP: Packet type = request
Quel nombre hexadécimal correspond à ICMP: packet type =request ?
 cliquez sur identifier (notez sa valeur)

 cliquez sur sequence number (notez sa valeur)
 cliquez sur data
Les données reçues dans le message d'écho ( echo-request)doivent être renvoyées dans le
message de réponse d'écho ( echo-reply).
Vérifiez-le.
 dans le menu affichage, cliquez sur cherchez la trame suivante qui doit être une trame
reply
 sur la trame suivante notez le packet type, l'identifier et lesequence number comparez
avec les valeurs précédentes, qu'en déduisez-vous ?
 enregistrer la capture à des fins d'analyse ultérieure (File / Save As)
 pour imprimer (File / Print)
 démarrez une capture réseau

 générez un flux réseau (avec ping)

 arrêtez la capture
 mettez en évidence les trames comportant le protocole ARP_RARP
 Affichez le détail des trames ARP:request
- détail de frame : taille de la trame de base
- détail Ethernet : adresse destination
- l'adresse de destination est-elle l'adresse physique(MAC d'une machine ?
- quelle est la partie constructeur de l'adresse physique?
- quelle est l'adresse source ?
- quel est le type de trame ethernet ?
- combien d'octets contient la trame ?
- A quoi servent les 14 premiers octets ?
 détail ARP_RARP
- adresse matérielle de l'expéditeur ?
- adresse IP de l'expéditeur ?
- adresse matérielle de la cible ?
- adresse IP de la cible ?
- pourquoi l'adresse matérielle de la cible contient-elle des FF ?
 Affichez le détail de la trame ARP:Reply
- répétez les opérations précédentes et comparez
- expliquez le fonctionnement du protocole ARP.
Chapter 6. Le routage
Revision History
Table of Contents
Principe

Routage dynamique
Abstract
Le document présente le routage IP sur un réseau local et en inter-réseau
Mots clés : routage, table de routage
Principe
Le routage dans Internet est similaire au mécanisme d'adressage du courrier.
Si vous adressez une lettre à un destinataire aux USA, à Los Angeles, dans l'état de Californie. Le
bureau de poste de Belfort reconnaîtra que cette adresse n'est pas locale et transmettra le
courrier au bureau français des PTT qui le remettra au service du mail US. Celui-ci s'en remettra à
son bureau de la Californie, qui le transmettra au bureau de Los Angeles, qui connaît la
localisation qui correspond à l'adresse dans la ville.
Avantages du système :
1. le bureau de poste local n'a pas à connaître toutes les adresses du monde
2. le chemin suivi peut être variable : chaque opérateur sait juste à qui remettre le courrier.
Le routage dans un réseau est identique :
Internet en entier est composé de réseaux autonomes qui s'occupent en interne de l'adressage
entre leurs hôtes. Ainsi, tout datagramme arrivant sur un hôte quelconque du réseau destination
sera acheminé à bon port par ce réseau seul.
Quand tous les hôtes participent au même réseau, chacun d'eux peut adresser des paquets aux
autres sans difficulté. Par contre, si le destinataire est situé sur un autre réseau, le problème est
de savoir où et à qui adresser le paquet puisque l'hôte expéditeur ne « voit » pas le destinataire.
On appelle passerelle (dans la terminologie TCP/IP) ou routeur un équipement qui fait le lien
entre différents réseaux ou entre sous-réseaux. Ex de passerelle: un ordinateur équipé de
plusieurs adaptateurs réseau peut être relié avec chacune d'elle à un réseau physiquement
séparé.
Les paquets d'un réseau qui sont adressés à l'autre réseau doivent passer par la passerelle. D'où
la nécessité pour chaque hôte de connaître, sur son réseau, l'adresse IP d'un ou de plusieurs
routeurs qui servent de passage vers le ou les réseaux qu'ils ne connaît pas.
Mettre en place le routage consiste à configurer chaque hôte du réseau de façon à ce qu'il sache
vers quelle adresse de son propre réseau il doit adresser un paquet qui concerne un autre réseau
(ou sous-réseau). Ces destinataires intermédiaires sont des routeurs qui prennent en charge le
paquet.

Les hôtes pouvant être nombreux, bien souvent chacun ne connaît que l'adresse d'une passerelle
(routeur) par défaut et ce sera cette passerelle qui « connaîtra » les adresses des autres routeurs.
Comment faire transiter des paquets entre 2 machines séparées par plusieurs routeurs?
Simplement chaque routeur doit connaître l'adresse du routeur suivant que doit emprunter le
paquet pour arriver à destination. Ainsi le paquet arrive en sautant de routeur en routeur jusqu'à
destination.
Mais concrètement comment ça se passe ?
Voici comment un hôte expéditeur se comporte pour adresser un paquet à un destinataire :
1. Il extrait l'adresse de réseau, voire de sous réseau de l'adresse du destinataire et la

compare à sa propre adresse de réseau ou de sous réseau. S'il s'agit du même réseau, le
paquet est expédié directement au destinataire en mettant en oeuvre ARP.
2. S'il ne s'agit pas du même réseau, l'expéditeur cherche dans sa table de routage une
correspondance destinataire final / destinataire intermédiaire (routeur). Il cherche, en
quelque sorte, sur son réseau, un hôte capable de servir de facteur vers un autre réseau.
3. L'expéditeur cherche d'abord à trouver dans sa table de routage locale l'adresse IP

complète du destinataire,
4. s'il ne la trouve pas il cherche l'adresse du sous réseau du destinataire,
5. s'il ne la trouve pas, il cherche enfin l'adresse du réseau,
6. s'il ne trouve aucune correspondance, l'expéditeur cherche dans sa table l'adresse d'une
passerelle à utiliser par défaut, (route 0.0.0.0)
7. s'il échoue là encore, le paquet, décidément bien encombrant, est supprimé.
Si l'une de ces recherches aboutit, la machine émettrice construit le paquet avec l'adresse IP du
destinataire hors réseau. Elle l'encapsule dans une trame ayant comme adresse MAC de
destination l'adresse MAC du routeur. La couche 2 du routeur lit la trame qui lui est adressée et
la transmet à la couche 3 IP. Celle-ci récupère le paquet et s'aperçoit que le paquet ne lui est pas
adressé, elle consulte sa table de routage, décide sur quelle nouvelle interface réseau le paquet
doit être transmis, encapsule le paquet dans une nouvelle trame, et ainsi de suite de passerelle en
passerelle jusqu'à destination.
Les réseaux IP sont interconnectés par des routeurs IP de niveau 3 (appelés abusivement en
terminologie IP des gateways ou passerelles).

Figure 6.1. routeurs interconnectés
Chaque hôte IP doit connaître le routeur par lequel il faut sortir pour pouvoir atteindre un réseau
extérieur, c'est-à-dire avoir en mémoire une table des réseaux et des routeurs. Pour cela il
contient une table de routage locale.
Dans une configuration de routage statique, une table de correspondance entre adresses de
destination et adresses de routeurs intermédiaires est complétée « à la main » par
l'administrateur, on parle de table de routage.
Figure 6.2. schéma de routage
La table de routage d'un routeur comporte les adresses des réseaux de destination, le masque,
les adresses des passerelles (routeurs intermédiaires) permettant de les atteindre, l'adresse de la
carte réseau (interface) par laquelle le paquet doit sortir du routeur.
La commande Route permet d'afficher et de manipuler le contenu de la table de routage.

Considérons le schéma de réseau suivant :
Figure 6.3. schéma de réseau 1
La table de routage du routeur sera :
Masque de Sous Interface

Destination Passerelle
réseau
sortie de la passerelle vers le

192.168.10.0 255.255.255.0 192.168.10.99 192.168.10.99
sous-réseau 10

192.168.20.0 255.255.255.0 192.168.20.99 192.168.20.99
sous-réseau 20

192.168.30.0 255.255.255.0 192.168.30.99 192.168.30.99
sous-réseau 30
Ce réseau local est maintenant relié via un autre routeur à un 4ème réseau, le schéma devient :
Figure 6.4. schéma de réseau 2
La nouvelle entrée à ajouter dans la table de routage du routeur R1 sera :
Masque de Sous Interface

Destination Passerelle
réseau

192.168.40.0 255.255.255.0 192.168.30.254 192.168.30.99 sous-réseau 40 via le routeur
192.168.30.254
Les échanges entre passerelles de chaque domaine de routage font l'objet de protocoles
particuliers : EGP (Exterior Gateway Protocol) et BGP (Border Gateway Protocol) plus récent. Ces
protocoles envoient les paquets vers des destinations en dehors du réseau local vers des réseaux
externes (Internet, Extranet...).
1. Si l'hôte de destination se trouve sur le réseau local, les données sont transmises à l'hôte
destination
2. Si l'hôte destination se trouve sur un réseau à distance, les données sont expédiées vers
une passerelle locale qui route le paquet vers une autre passerelle et ainsi de suite de
passerelle en passerelle jusqu'à destination.
La commande Tracert permet de suivre à la trace le passage de routeur en routeur pour atteindre
un hôte sur le réseau. La commande Ping permet de vérifier la fiabilité d'une route donnée.
Routage dynamique
Les protocoles d'échange dynamique des tables de routage IP sur un réseau local sont RIP
(Routing Information Protocol) et le protocole OSPF (Open Shortest Path First). Dans une
configuration de routage dynamique, un protocole (RIP ou OSPF) est mis en oeuvre pour
construire dynamiquement les chemins entre routeurs.
Le protocole RIP permet à un routeur d'échanger des informations de routage avec les routeurs
avoisinants. Dès qu'un routeur est informé d'une modification quelconque de la configuration sur
les réseaux (telle que l'arrêt d'un routeur), il transmet ces informations aux routeurs avoisinants.
Les routeurs envoient également des paquets de diffusion générale RIP périodiques contenant
toutes les informations de routage dont ils disposent. Ces diffusions générales assurent la
synchronisation entre tous les routeurs.
Avec un protocole comme RIP, on peut considérer que les tables de routages des routeurs et
passerelles sont constituées et mises à jour automatiquement.

Chapter 7. Le protocole IPv6
Revision History
Revision 0.3 6 Novembre 2005
Table of Contents
Types d'adresses
Abstract
L'adressage IPv4 sur 32 bits se révélant insuffisant (saturation prévue pour 2010) avec le développement
d'Internet, l'IETF a proposé une nouvelle version du protocole IP en 1995 (RFC 1883) puis le standard IPv6
en 1998 (ou Ipng - ng pour "Next Generation", RFC 2460), afin de permettre l'adressage d'au moins un
milliard de réseaux, soit quatre fois plus qu'IPv4.Pour permettre le déploiement d'IPv6 de la manière la plus
flexible possible, la compatibilité avec IPv4 est garantie.Pour un point sur IPv6, vous pouvez consulter cet
article :http://www.vnunet.fr/actualite/reseau/technologie/20051222008.
IPv6 apporte un certain nombre de nouvelles fonctionnalités :
 Un plus grand espace d'adressage

 Un entête simplifié et efficace
 L'autoconfiguration
 Le support de la mobilité

Un plus grand espace d'adressage , c'est la plus flagrante évolution mise en avant lorsqu'on parle d'IPv6. Il
permettra de déployer de nouvelles applications nécessitant des communications de bout en bout (téléphonie
mobile, vidéoconférence, applications en temps réel).
Un entête simplifié et efficace : l'entête IPv6 est de taille fixe. Les options de l'entête IPv4 ont disparues,
elles sont remplacées par les extensions d'entête IPv6. Alors que les options d'entête IPv4 étaient examinées
par tous les noeuds intermédiaires d'une communication, les extensions IPv6 ne seront gérées que par les
équipements terminaux. Les équipements intermédiaires sont donc déchargés d'une partie des traitements.
La gestion des paquets erronés est déléguée aux équipements d'extrémité et aux couches supérieures telles
TCP ou UDP.
L'autoconfiguration : elle met en oeuvre un certain nombre de nouveaux protocoles associés à IPv6
(protocole de découverte des voisins, nouvelle version d'ICMP ...). L'autoconfiguration permet à un
équipement de devenir complètement "plug and play". Il suffit de connecter physiquement la machine pour
qu'elle acquière une adresse IPv6 et une route par défaut.
Le support de la mobilité : il a été introduit dès la conception d'IPv6. Cela se caractérise par le fait d'être
connecté et de disposer de son environnement tout en se déplaçant et ce, sans interruption de service tout en
conservant la même adresse IPv6. En pratique les données destinées à une machine qui a été déplacée sont
automatiquement retransmises vers sa nouvelle position, son nouveau lieu de connexion, à l'échelle
planétaire. Cela s'appliquera aux téléphones et ordinateurs portables, assistants personnels .., les utilisateurs
pourront se connecter dans le train, la voiture... lors de leurs missions extérieures.
A noter : en 1996, un réseau expérimental a été créé pour tester le déploiement d'IPv6. Il s'agit du 6bone qui
s'étend en Asie, Europe , Amérique et Australie. Depuis 1998 , les adresses distribuées par le 6bone avaient
comme préfixe commun "3ffe" , depuis Janvier 2004 , ce sont des adresses dont le préfixe est "2001" qui
sont distribuées.
En résumé : IPv6 possède un nouveau format d'en-tête IP, une infrastructure de routage plus efficace, et un
espace d'adressage plus important. Pour permettre le déploiement d'IPv6 de la manière la plus flexible
possible, la compatibilité avec IPv4 est garantie.
- les adresses IPv6 sont codées sur 128 bits (1 milliard de réseaux).
- le principe des numéros de réseaux et des numéros d'hôtes est maintenu.
- IPv6 est conçu pour interopérer avec les systèmes IPv4 (transition douce prévue sur 20 ans).
L'adresse IPv6 peut contenir une adresse IPv4 : on place les 32 bits de IPv4 dans les bits de
poids faibles et on ajoute un préfixe de 96 bits ( 80 bits à 0 suivis de 16 bits à 0 ou 1)
- IPv6 utilise un adressage hiérarchique (identification des différents réseaux de chaque niveau)
ce qui permet un routage plus efficace.
- IPv6 est prévu pour les systèmes mobiles : auto-configuration, notion de voisinage (neighbor).
- IPv6 permet l'authentification et le chiffrement dans l'en-tête des paquets, ce qui permet de
sécuriser les échanges. En effet IP v.6 intègre IPSec (protocole de création de tunnel IP avec
chiffrement), qui garantit un contexte sécurisé par défaut.

- IPv6 intègre la qualité de service : introduction de flux étiquetés (avec des priorités)
- IPv6 prend mieux en charge le trafic en temps réel (garantie sur le délai maximal de transmission
de datagrammes sur le réseau).
L'adressage IPv6 est structuré en plusieurs niveaux selon un modèle hiérarchique dit "agrégé".
Cette composition devrait permettre une meilleure agrégation des routes et une diminution de la
taille des tables de routage.
Un plan d'adressage hiérarchisé en trois niveaux a été défini pour les adresses IPv6 :
Figure 7.1. Adressage agrégé
1. le niveau "public" (Global Routing prefix) utilise 48 bits décomposés comme suit :
- L'international: TLA (Top Level Aggregator) utilise les 16 premiers bits, ce préfixe est
délivré aux grands opérateurs internationaux, par exemple RICE-NCC (Renater, Nerim ...)
a la classe 2001:600/13
- Le National: Sub-TLA utilise les 13 bits suivants, il permet aux opérateurs internationaux
de fournir des adresses aux opérateurs nationaux, par exemple 2001:660::/35 correspond à
Renater.
- Les 6 bits suivants sont réservés pour des utilisations futures.
- Le NLA (Next Level Aggregator) utilise les 13 bits suivants, il permet aux opérateurs de
délivrer des adresses à leurs clients, par exemple Renater a donné l'adresse
2001:0660:7701::/48 à l'université de Caen.
2. le niveau "site" SLA (Site Level Aggregator) utilise les 16 bits suivants, ils sont sous la
responsabilité du site et permettent de créer des sous-réseaux (donc 65534 sous-réseaux
possibles par site).
3. le niveau "interface" utilise 64 bits, ils correspondent à l'identifiant unique de l'interface sur
le réseau. Sur les réseaux Ethernet, ils sont généralement fabriqués à partir de l'identifiant
unique de l'interface : l'adresse MAC, mais ils peuvent également être générés
aléatoirement pour des raisons de confidentialité.
Les adresses IPv6 sont codées sur 128 bits.

Les 128 bits de l'adresse sont divisés en 8 groupes de 16 bits représentés par 4 chiffres
hexadécimaux et séparés par ":" .
Exemple d'adresse : 5800:10C3:E3C3:F1AA:48E3:D923:D494:AAFF
Dans IPv6 les masques sont exprimés en notation CIDR.
Il y a plusieurs façons de représenter les adresses IPv6.
Notation : "x:x:x:x:x:x:x:x" où x représente les valeurs hexadécimales des 8 portions de 16 bits

de l'adresse.
A noter : les lettres peuvent être écrites aussi bien en majuscules qu'en minuscules.
Exemples d'adresse :
2001:0660:7401:0200:0000:0000:0edf:bdd7
3ffe:0104:0103:00a0:0a00:20ff:fe0a:3ff7
Notation : les zéros à gauche de chaque groupe peuvent être omis, un ou plusieurs groupes de
zéros consécutifs se notent "::".
La séquence "::" ne peut apparaître qu'une seule fois dans une adresse.
L'adresse donnée en exemple peut donc s'écrire :
2001:660:7401:200::edf:bdd7
 L'adresse IPv6 compatible IPv4
Elle est utilisée dans un contexte particulier : les tunnels 6 to 4 permettant de relier des
réseaux IPv4 à des réseaux IPv6.
Soit une adresse IPv4 notée a.b.c.d , son équivalent IPv6 se notera :
0:0:0:0:0:0:0:a.b.c.d/96
ou en forme abrégée : ::a.b.c.d/96
Exemple :
::132.64.16.25
 L'adresse IPv4 mappée

Un hôte IPv6 étant capable de communiquer aussi bien avec un hôte IPv4 qu'avec un hôte
IPv6, il utilise des adresses IPv4 mappées pour communiquer avec les autres machines
IPv4 et utilise des adresses IPv6 normale pour communiquer avec les autres machines
IPv6. Ces adresses sont de la forme ::ffff:a.b.c.d .
Exemple :
:: ffff : 132.64.16.25
 L'adresse de bouclage qui correspond à 127.0.0.1 en IPv4
0000:0000:0000:0000:0000:0000:0000:0001
L'adresse de bouclage ou localhost se note en abrégé :
::1
 L'adresse indéterminée qui correspond à 0.0.0.0 en IPv4.
Elle caractérise l'absence d'adresse. Elle est utilisée lors de certaines phases
d'initialisation. C'est une adresse transitoire. Elle se note 0:0:0:0:0:0:0:0 ou ::
Leur notation classique comme en IPV4 est impossible avec 128 bits, c'est donc la notation CIDR,
plus simplement appelée notation "slash" qui est utilisée.
Exemple l'adresse fe80::20d:61ff:fe22:3476/64 a un masque de 64 bits , masque par défaut pour

une adresse de type lien-local.
Types d'adresses
IPv6 supporte 3 types d'adresses: Unicast, Multicast et Anycast.
 Les adresses unicast :
Elles désignent une et une seule machine.
Elles comportent une partie réseau "préfixe" et une partie hôte "suffixe":
La partie réseau ou préfixe est codée sur 64 bits : les 48 bits publics "Global Routing
Prefix" et les 16 bits de site définissant le sous-réseau
La partie hôte ou suffixe est codée aussi sur 64 bits, fabriquée à partir de l'adresse MAC
de l'interface, elle permet d'identifier la machine dans un réseau donné.
Prenons par exemple cette adresse fe80::20d:61ff:fe22:3476
fe80:: ,en réalité fe80:0000:0000:0000 correspond au préfixe ou partie réseau

20d:61ff:fe22:3476 correspond au suffixe ou partie hôte
 Les adresses multicast :
Le protocole IPv6 généralise l'utilisation des adresses multicast qui remplacent les
adresses de type "broadcast" (diffusion) qui n'existent plus en IPv6. La raison de cette
disparition est que l'émission d'un paquet broadcast était très pénalisante pour toutes les
machines se trouvant sur un même lien.
Une adresse multicast est une adresse désignant un groupe d'interfaces donné. Une
interface est libre de s'abonner à un groupe ou de le quitter à tout moment, c'est donc
moins pénalisant qu'en IPv4.
Le format des adresses multicast est le suivant :
ff01 : noeud local, les paquets ne quittent pas l'interface.
ff02 : lien local, les paquets ne quittent pas le lien .
ff05 : site local, les paquets ne quittent pas le site .
Voici un exemple intéressant d'utilisation d'adresse multicast qui vous permet de détecter
les hôtes actifs sur le lien local :
# ping6 -I eth0 ff02::1

PING ff02::1(ff02::1) from fe80::20e:35ff:fe8f:6c99 eth2: 56 data bytes
64 bytes from ::1: icmp_seq=1 ttl=64 time=0.048 ms
64 bytes from fe80::20d:61ff:fe22:3476: icmp_seq=1 ttl=64 time=9.05 ms (DUP!)
64 bytes from fe80::20d:61ff:fe22:3476: icmp_seq=2 ttl=64 time=3.33 ms (DUP!)
Vous pouvez identifier 2 hôtes actifs fe80::20e:35ff:fe8f:6c99 (celui d'où est passée la
commande) et fe80::20d:61ff:fe22:3476 (qui correspond à un autre poste du réseau local).
 Les adresses anycast :
Anycast est un nouveau type d'adressage. Il identifie qu'un noeud, parmi un groupe de
noeuds, doit recevoir l'information.
Une adresse anycast, comme une adresse multicast, désigne un groupe d'interfaces, à la
différence qu'un paquet émis avec comme destinataire une adresse anycast ne sera remis
qu'à un seul membre du groupe, par exemple le plus proche au sens de la métrique des
protocoles de routage, même si plusieurs interfaces ont répondu au message. L'interface
de destination doit spécifiquement être configurée pour savoir qu'elle est anycast.
Pour l'instant, une seule adresse anycast est utilisée, elle est réservée au routeur mais
dans l'avenir, d'autres pourraient être définies.
La portée ou "scope" des adresses, est une nouvelle notion qui n'existait pas en IPv4.

En fait une interface ne possède pas une seule adresse IPv6 mais peut en avoir plusieurs.
Les quatre portées d'adresses sont :
 Noeud-local : il s'agit de l'adresse de loopback . Elle est notée ::1/128.

 Lien-local : adressage commun aux machines d'un même lien physique reliées entre elles
sans routeur intermédiaire .Ces adresses ont comme préfixe fe80::/64. Seuls les
équipements de la couche 2 du modèle OSI peuvent utiliser ces adresses pour
communiquer entre eux. Cette adresse est obtenue par autoconfiguration "sans état".
 Site-local : adressage commun des machines d'un même site.Par exemple, un site qui
n'est pas encore relié à Internet peut utiliser ce type d'adresse. C'est un peu le concept des
adresses privées en IPv4 (192.168.x.x ou 10.x.x.x). Une adresse site local a comme préfixe
fec0::/48 suivi d'un champ de 16 bits permettant de définir des sous-réseaux.
 Globale : ce sont des adresses dont le routage est effectué sans restriction. Leur préfixe
est 2000::/3 , ce qui signifie qu'elles commencent par 001 en binaire. Concrètement, on
utilise 2xxx ou 3xxx.
Par exemple 2001:7a8:4b09:1bff:feb1:defa est une adresse globale.
Le type d'adresse IPv6 est indiqué par les premiers bits de l'adresse qui sont appelés le "Préfixe de
Format" (Format Prefix). L'allocation initiale de ces préfixes est la suivante :
Allocation Préfixe Usage

Adresses dont le routage est effectué sans restriction,
Adresses Unicast globales 010 utilisables sur Internet.
Adresses Unicast
001
expérimentales
1111 1110 Adresses d'un même lien physique,obtenues par

Adresses "Lien local"
1000 autoconfiguration
1111 1110
Adresses "Site Local" Adresses d'un même site
1100
Elles remplacent les adresses "broadcast" d'IPv4
Adresses Multicast 1111 1111
15 % de l'espace d'adressage est actuellement alloué. Les 85% restants sont réservés pour des
usages futurs. En réalité sur les 128 bits, seulement 64 sont utilisés pour les hôtes (Interface ID).
Chapter 8. Les commandes et fonctionnalités IPv6

Revision History

Table of Contents

L'autoconfiguration
 ping6
Ce programme est inclus dans le paquet "iputils", normalement déjà installé.
Exemples d'utilisation:
ping6 -I eth0 ::1 # ping de l'adresse de bouclage

ping6 -I eth0 ff02::1 # permet de voir tous les hôtes actifs sur le lien
ping6 -I eth0 fe80::20e:35ff:fe8f:6c99 #ping de l'adresse IPv6 d'un autre poste
 Afficher l'adresse IPv6
- La commande ifconfig peut être utilisée:
ifconfig
ifconfig |grep inet6 # affiche uniquement les adresse IPv6
- La commande "ip -6 addr show" qui affiche uniquement les paramètres IPv6
# ip -6 addr show [dev interface ]

# ip -6 addr show
1: lo: LOOPBACK,UP mtu 16436
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
3: eth0: BROADCAST,MULTICAST,UP mtu 1500 qlen 1000
inet6 2002:c000:201::1/64 scope global
inet6 fe80::20d:61ff:fe22:3476/64 scope link
 Montage et démontage des interfaces
# ip link set dev interface up

# ip link set dev interface down
Exemple:
# ip link set dev eth0 up
La commande ifconfig peut également être utilisée :
# ifconfig eth0 up
 Configurer manuellement une adresse IPv6
Il peut être utile de configurer manuellement des adresses IPv6 , par exemple pour des
routeurs ou des serveurs, pour les postes clients , l'autoconfiguration est préférable.

On peut utiliser les commandes "ifconfig" ou "ip -6"
# ifconfig eth0 inet6 add 3ffe:ffff:0:f101::1/64

# ip -6 add 3ffe:ffff:0:f101::1/64 dev eth0
A noter : pour enlever une adresse ip, remplacer simplement add par del , dans les 2
commandes.
Afin de rendre votre nouvelle adresse IPv6 permanente, vous devez ajouter la configuration
IPv6 de votre interface dans le fichier
/etc/network/interfaces
en ajoutant par exemple :
iface eth0 inet6 static

address 3ffe:ffff:0:f101::1
netmask 64
Le paramètre gateway peut également être précisé dans le fichier interfaces.
 Afficher la table de routage
# ip -6 route show [dev peripherique]

# ip -6 route show
# route -A inet6
# route -A inet6 |grep eth0 # pour afficher seulement ce qui concerne
l'interface eth0
~$ sudo route -A inet6
Table de routage IPv6 du noyau
Destination Prochain Hop Indic Metric Ref
Utilis. Iface
::1/128 :: U 0 0 2 lo
::/96 :: U 256 0 0 sit0
2002:c000:201:0:20e:35ff:fe8f:6c99/128 :: U 0 0 2 lo
2002:c000:201::/64 :: UA 256 0 0 eth2
fe80::20e:35ff:fe8f:6c99/128 :: U 0 11 2 lo
fe80::/64 :: U 256 0 0 eth2
::/0 fe80::20d:61ff:fe22:3476 1 eth2
la ligne ::/0 désigne la route par défaut, ici il s'agit de l'adresse du routeur d'annonce (cf
chapitre sur l'autoconfiguration).
la ligne 2002:c000:201::/64 désigne la route de l'interface de portée globale.
la ligne ff00::/8 désigne la route pour le trafic multicast.
la ligne fe80::/64 désigne la route de l'interface de portée lien-local
 Ajouter une route
# route -A inet6 add reseauipv6/longueurprefixe gw adresseipv6 [dev peripherique]

# route -A inet6 add 2000::/3 gw 3ffe:ffff:0:f101::1 dev eth0
# ajoute une route pour toutes les adresses globales actuelles (2000::/3)
# ip -6 route add 2000::/3 via 3ffe:ffff::0:f101::1 dev eth0
# ajoute une route pour toutes les adresses globales actuelles (2000::/3)
# ip -6 route add 2000::/3 via 3ffe:ffff::0:f101::1 dev eth0
#ajout de cette route avec la commande ip -6

Pour supprimer une route , syntaxe identique pour les 2 commandes , remplacer
simplement "add" par "del".
 Commande traceroute6
Ce programme est inclus dans le paquet iputils-tracepath qu'il faudra éventuellement

installer.
Son fonctionnement est similaire au traceroute d'IPv4 , par exemple :
# traceroute6 www.6bone.net
# traceroute6 2001:5c0:0:2::24
 Commande tracepath6
Ce programme est également inclus dans le paquet iputils-tracepath
Son fonctionnement est similaire à traceroute6.
Le protocole de découverte des voisins (Neighbor Discovery) permet à un équipement de

s'intégrer dans l'environnement de réseau local, c'est à dire le lien sur lequel sont physiquement
transmis les paquets IPv6.La découverte des voisins ne consiste pas à établir une liste exhaustive
de tous les équipements connectés au lien mais de gérer uniquement ceux avec lesquels il
dialogue.
Fonctionnalités du protocole :
 Résolution d'adresses
Le principe est très proche du protocole ARP d'IPv4. La principale différence vient de
l'emploi de messages standards ICMP6 à la place de la définition d'un autre protocole.
Comme pour ARP, une table de correspondance entre les adresses physiques et les
adresses IPv6 est construite. Une requête de résolution d'adresse est une "sollicitation de
voisin" véhiculée par un paquet ICMP6 dont l'adresse de destination est une adresse
multicast.
 Fonction d'inaccessibilité des voisins
Cette fonction appelée aussi "NUD" (Neighbor Unreachability Detection) n'existe pas en
IPv4. Elle permet d'effacer dans le cache des voisins les entrées correspondants aux
voisins inaccessibles (panne, changement d'adresse ...).
Si un routeur devient inaccessible, la table de routage peut être modifiée dynamiquement

pour prendre en compte un autre routeur.
 La configuration automatique
Le protocole de découverte des voisins est le successeur de l'ARP d'IPv4. Il participe à

l'autoconfiguration , véritable atout d'IPv6.

- Découverte des routeurs : Elle permet aux équipements de découvrir les routeurs qui sont
sur leur lien physique.
- Découverte des préfixes : L'équipement apprend le(s) préfixe(s) utilisé(s) sur le réseau en
fonction des annonces faites par les routeurs et en y ajoutant l'identificateur d'interface de
l'équipement, il construit son adresse IPv6. C'est le principe vu précédemment avec
l'autoconfiguration.
- Detection des adresses dupliquées : Comme les adresses sont construites

automatiquement, il existe des risques de duplication d'adresses. Un entête permet à
l'interface de s'assurer qu'elle est la seule à posséder l'adresse qui lui a été attribuée.
 Afficher le voisinage
ip -6 neigh show [dev péripherique]
Lorsque vous ne disposez que d'une interface réseau, inutile de la préciser. Voici un
exemple de commande :
morph@ns1:~$ ip -6 neigh show

morph@ns1:~$ ping6 -I eth2 fe80::20d:61ff:fe22:3476
PING fe80::20d:61ff:fe22:3476(fe80::20d:61ff:fe22:3476) from
fe80::20e:35ff:fe8f:6c99 eth2: 56 data bytes
64 bytes from fe80::20d:61ff:fe22:3476: icmp_seq=1 ttl=64 time=6.08 ms
--- fe80::20d:61ff:fe22:3476 ping statistics ---
morph@ns1:~$ ip -6 neigh show
fe80::20d:61ff:fe22:3476 dev eth2 lladdr 00:0d:61:22:34:76 router nud stale
On peut constater que le cache de voisinage est vide avant l'exécution du ping6 sur un
autre poste. Le comportement de cette commande est donc très proche de la commande
arp d'IPv4.
Pour afficher les autres possibilités :
ip -6 neigh help
 Les messages du protocole
- Sollicitation du voisin ou Neighbor solicitation : ce message permet d'obtenir des

informations d'un voisin, c'est-à-dire situé sur le même lien physique. Le message peut être
envoyé au voisin soit explicitement (en unicast) soit vers l'adresse multicast associée à ce
voisin. Dans le cas de la détermination d'adresse physique, il correspond à la requête ARP
du protocole IPv4.
- Annonce du voisin ou Neighbor advertisement : ce message est émis en réponse à une

sollicitation.
Vous pouvez visualiser l'échange des messages du protocole en faisant une capture de
trames avec ethereal lors d'une commande "ping6" par exemple .
Figure 8.1. Capture de trames avec ethereal

L'autoconfiguration
Il existe 3 types d'autoconfiguration :
 L'autoconfiguration sans état ou "stateless" où seul le préfixe est donné à l'équipement

qui aura la charge de générer le suffixe de l'adresse.
Dès qu'une interface est activée (démarrage de la machine par exemple) une adresse de
type lien-local est automatiquement générée à partir de l'adresse MAC de l'interface
Exemple : une carte réseau d'adresse MAC 00:0D:61:22:34:76 aura l'adresse IPv6
suivante fe80::20d:61ff:fe22:3476
Le préfixe est fe80::, donc l'adresse est de type "lien-local".
Le suffixe est généré à partir de l'adresse MAC de la machine.
C'est ce type d'adresse qui est généré sur votre machine si vous avez le module IPv6
comme c'est le cas sous Linux avec le noyau 2.6 .
Vous pouvez vérifier si le module IPv6 est chargé simplement en faisant la commande:
#ifconfig |grep inet6

adr inet6: fe80::20d:61ff:fe22:3476/64 Scope:Lien
adr inet6: ::1/128 Scope:Hôte
Vous pouvez voir que l'interface eth0 possède bien une adresse IPv6
fe80::20d:61ff:fe22:3476/64 qui correspond à une adresse de type lien-local et vous
pouvez remarquer que la partie suffixe est bien dérivée de son adresses MAC.
L'interface de loopback possède également une adresse IPv6 ::1/128
Ce type d'adresse lien-local peut suffire pour les premiers tests.
 L'autoconfiguration avec état ou "stateful" dans laquelle l'adresse est fournie par le
démon Annonce du routeur .

Le démon radvd permet d'autoconfigurer toutes les interfaces du réseau avec un autre
préfixe (par exemple celui qui vous aura été fourni par votre FAI ou celui que vous aurez
choisi pour vos tests) en utilisant un routeur IPv6 où le démon "radvd" ou "Router
Advertisement demon" est installé.
Ce démon doit être installé sur un des postes de votre réseau , celui qui servira plus tard de
passerelle IPv6.
Pour installer radvd :
# apt-get install radvd
Vous devez ensuite créer le fichier
/etc/radvd.conf
En y mettant le préfixe que vous souhaitez donner aux interfaces du réseau , voici un
exemple de fichier radvd.conf :
interface eth0
{
AdvSendAdvert on;
prefix 2002:c000:201::1/64
{
};
};
Ici , le préfixe sera 2002:c000:201::1/64 .
Vous devez ensuite redémarrer le démon radvd en faisant:
# invoke-rc.d radvd restart
Ajoutez ensuite la configuration IPv6 de votre interface dans le fichier
/etc/network/interfaces
iface eth0 inet6 static

address 2002:c000:201::1
netmask 64
Relancer ensuite le service networking.
Le démon radvd émet ensuite des annonces afin que les interfaces du lien
s'autoconfigurent avec le préfixe reçu et le routeur pas défaut.
ifconfig |grep inet6

adr inet6: 2002:c000:201::1/64 Scope:Global
Le routeur d'annonce a désormais une adresse IPv6 localhost ::1 ,une adresse lien local
fe80::20d:61ff:fe22:3476/64 et une adresse globale 2002:c000:201::1/64 .

Pour la configuration des autres postes du réseau, il suffit de lancer la commande "dhclient
ethx" sur cet autre poste pour récupérer les nouveaux paramètres.
En effectuant une capture de trames avec ethereal lors de l'exécution de la commande

dhclient ,vous pourrez remarquer les différents messages du protocole :
Figure 8.2. Capture de trames avec ethereal
- "Router solicitation" ou sollicitation du routeur: ce message est émis par un équipement

au démarrage ou lors d'un renouvellement d'adresse avec "dhclient" pour recevoir plus
rapidement des informations du routeur. Ce message est émis vers l'adresse IPv6 de
multicast réservée aux routeurs du même lien ff02::2. Il est émis par l'adresse lien-local de
l'équipement.
- "Router advertisement" ou annonce du routeur : ce message est émis périodiquement par

les routeurs ou en réponse à un message de sollicitation du routeur. L'adresse source est
celle du poste sur lequel le démon "radvd" a été configuré : par exemple notre routeur
d'annonce fe80::20d:61ff:fe22:3476, l'adresse de destination est ff02::1 ce qui correspond
à l'adresse multicast de sollicitation de lien-local.
Voici la configuration obtenue par le poste client après l'exécution de la commande

"dhclient" .
$ sudo ifconfig |grep inet6
adr inet6: 2002:c000:201:0:20e:35ff:fe8f:6c99/64 Scope:Global

adr inet6: fe80::20e:35ff:fe8f:6c99/64 Scope:Lien

Vous pouvez constater que ce poste a desormais également 3 adresses IPv6 (au lieu de 2
auparavant) car c'est le routeur d'annonce qui lui a envoyé le préfixe de son adresse
globale, le suffixe étant calculé à partir de son adresse MAC :
2002:c000:201:0:20e:35ff:fe8f:6c99/64
Si le préfixe vous a été attribué par un FAI (ex Nérim qui fournit des adresses IPv6 natives)
ou un "tunnelbroker" (par exemple Freenet6 , Sixxs )qui fournit des passerelles gratuites
IPv6 via un tunnel, votre poste possède donc sa propre adresse IPv6 globale unique (avec
la partie suffixe dérivée de l'adresse MAC) ,utilisable sur Internet.
Ce concept d'autoconfiguration peut donc vous permettre de paramétrer tout un réseau en

ne configurant que le routeur d'annonce, les postes clients obtenant automatiquement leur
propre configuration.
 L'autoconfiguration avec DHCP6
Ce type de configuration dynamique, moins utile avec IPv6, ne sera pas détaillé pour
l'instant.
Chapter 9. Les tunnels IPv4/IPv6

Revision History
Revision 0.1 20 Février 2006
Table of Contents

 Par un fournisseur d'accès :
Pour l'instant en France (début 2006) seul Nerim fournit des adresses ipv6 natives
http://www.nerim.fr/connectiviteenipv6.php
Toutefois une expérimentation est en cours depuis Juin 2005 pour les abonnés de
Wanadoo : http://www.ipv6.wanadoo.fr/mxBB/.
Une pétition est en cours afin que le FAI free donne des adresses IPv6 natives à ses
abonnés: http://ipv6pourtous.free.fr/faq/.
 Utiliser une connexion via un tunnel 6to4
Un tunnel "6to4" permet de relier un réseau Ipv4 au réseau IPv6.

Du côté du réseau IPv4 , les trames IPv6 sont encapsulées dans des trames IPv4 et sont
envoyées vers le relais 6to4 qui est chargé d'en extraire les trames IPv6 et de les envoyer
vers le réseau IPv6.
Les principaux fournisseurs de tunnels 6to4 sont :
-Hurricane Electric http://www.tunnelbroker.net
-Freenet6 http://www.hexago.com
-Sixxs http://www.sixxs.net
 Se relier à une passerelle ipv6
Contrairement aux tunnels "6to4", vous ne vous enregistrez pas auprès d'un fournisseur qui
redirigera pour vous tout le trafic IPv6 encapsulé dans des trames IPv4. Votre adresse IPv6
est calculée d'après votre adresse IPv4 publique, les trames IPv6 seront dirigées vers une
passerelle "6to4". Pour connaitre les passerelles disponibles :
http://www.6bone.net/6bone_6to4.html
Nous prendrons comme exemple une configuration avec Hurricane Electric
 Vous devez d'abord faire une demande d'enregistrement auprès

http://www.tunnelbroker.net
Vous recevrez rapidement par e-mail un compte et un mot de passe.Votre tunnel sera
utilisable environ 24 heures après.
 Voici un exemple de tunnel :
Figure 9.1. Détails de votre tunnel

Vous y verrez notamment l'adresse du serveur IPv4: Server IPv4 address: 64.71.128.83
L'adresse client IPv4 correspond à votre adresse IPv4 publique.
Vous pouvez y voir aussi l'adresse IPv6 cliente qui vous a été attribuée et celle du serveur.
Vous pouvez également tester la connectivité IPv6 directement sur le site de Hurricane.
Figure 9.2. Exemple de traceroute6 sur le site Hurricane
 Configuration de votre poste
Vous devez commencer par configurer les interfaces virtuelle sit0 et sit1
L'interface sit0 correspond au serveur (fin du tunnel).
L'interface sit1 correspond à votre poste (début du tunnel).

fds@poste:~$ sudo ifconfig sit0 up
fds@poste:~$ sudo ifconfig sit0 inet6 tunnel ::64.71.128.83
fds@poste:~$ sudo ifconfig sit1 up
fds@poste:~$ sudo ifconfig sit1 inet6 add 2001:470:1F01:FFFF::E21/127
Vous vérifiez ensuite votre configuration :
fds@poste:~$ sudo ifconfig

eth0 Lien encap:Ethernet HWaddr 00:0D:61:22:34:76
inet adr:192.168.1.80 Bcast:192.168.1.255 Masque:255.255.255.0
collisions:0 lg file transmission:1000
RX bytes:19902751 (18.9 MiB) TX bytes:7892805 (7.5 MiB)
lo Lien encap:Boucle locale

inet adr:127.0.0.1 Masque:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
sit0 Lien encap:IPv6-dans-IPv4

adr inet6: ::127.0.0.1/96 Scope:Inconnu
adr inet6: ::192.168.1.80/96 Scope:Compat
UP RUNNING NOARP MTU:1480 Metric:1
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
sit1 Lien encap:IPv6-dans-IPv4

adr inet6: fe80::c0a8:150/64 Scope:Lien
adr inet6: 2001:470:1f01:ffff::e21/127 Scope:Global
UP POINTOPOINT RUNNING NOARP MTU:1480 Metric:1
RX bytes:9312 (9.0 KiB) TX bytes:6454 (6.3 KiB)
Vous pouvez vérifier les adresses attribuées à sit0 et sit1.
Vous devez ajouter ensuite une route pour le trafic IPv6 :
fds@poste:~$ sudo route -A inet6 add ::/0 dev sit1
 Si vous passez par un routeur pour accéder à Internet:
Le trafic via un tunnel IPv4/IPv6 utilise le port 41.
Il vous faudra faire sur votre routeur une redirection du port 41 vers votre poste.
Si vous utilisez un firewall, vous devrez également autoriser le trafic pour le port 41.
Si cela ne suffit pas, déclarez votre poste en "DMZ Server" sur votre routeur.

 Vérification de la connectivité IPv6
Faire un ping6 sur votre adresse cliente IPv6 et l'adresse du serveur IPv6 attribuées par le
fournisseur.
fds@poste:~$ ping6 2001:470:1F01:FFFF::E21

PING 2001:470:1F01:FFFF::E21(2001:470:1f01:ffff::e21) 56 data bytes
64 bytes from 2001:470:1f01:ffff::e21: icmp_seq=1 ttl=64 time=0.036 ms
--- 2001:470:1F01:FFFF::E21 ping statistics ---

3 packets transmitted, 3 received, 0% packet loss, time 1999ms
rtt min/avg/max/mdev = 0.036/0.039/0.042/0.005 ms
fds@poste:~$ ping6 2001:470:1F01:FFFF::E20

PING 2001:470:1F01:FFFF::E20(2001:470:1f01:ffff::e20) 56 data bytes
64 bytes from 2001:470:1f01:ffff::e20: icmp_seq=1 ttl=64 time=282 ms
--- 2001:470:1F01:FFFF::E20 ping statistics ---

4 packets transmitted, 3 received, 25% packet loss, time 3002ms
rtt min/avg/max/mdev = 175.542/211.539/282.909/50.466 ms
Test avec un traceroute6:
fds@poste:~$ traceroute6 www.kame.net

traceroute to www.kame.net (2001:200:0:8002:203:47ff:fea5:3085) from
2001:470:1f01:ffff::e21, 30 hops max, 16 byte packets
1 2001:470:1f01:ffff::e20 (2001:470:1f01:ffff::e20) 178.21 ms 175.007 ms
175.476 ms
2 2001:470:1fff:2::26 (2001:470:1fff:2::26) 175.572 ms 175.387 ms 174.403 ms
3 3ffe:81d0:ffff:1::1 (3ffe:81d0:ffff:1::1) 177.057 ms 176.618 ms 176.773 ms
4 3ffe:80a::e (3ffe:80a::e) 177.253 ms 177.553 ms 177.583 ms
5 2001:2a0:0:bb0a::1 (2001:2a0:0:bb0a::1) 281.696 ms 281.596 ms 282.318 ms
6 2001:2a0:0:bb04::6 (2001:2a0:0:bb04::6) 282.771 ms 282.251 ms 282.777 ms
7 hitachi1.otemachi.wide.ad.jp (2001:200:0:1800::9c4:2) 368.275 ms 368.134 ms
377.678 ms
8 2001:200:0:1c04:230:13ff:feae:5b (2001:200:0:1c04:230:13ff:feae:5b) 379.844
ms 380.374 ms 379.987 ms
9 2001:200:0:4800::7800:1 (2001:200:0:4800::7800:1) 370.923 ms 371.113 ms
370.943 ms
10 orange.kame.net (2001:200:0:8002:203:47ff:fea5:3085) 368.135 ms 377.356 ms
378.27 ms
Quelques sites à tester: http://www.kame.net, http://www.tahi.org.
Test du site www.kame.net avec Mozilla, si vous voyez la tortue bouger, vous êtes bien en
IPv6 :-).
Figure 9.3. Affichage du site kame.net

Allez ensuite sur le site www.tahi.org qui vous permettra de surfer en www6 sur
http://www6.tahi.org/ et de vérifier que votre connexion IPv6 est bien active.
 Vous pouvez obtenir auprès de votre fournisseur de tunnel Hurricane une adresse 64 bits
qui vous permettra de configurer automatiquement les postes de votre réseau local en IPv6
en utilisant de démon radvd.
Les 64 bits fournis correspondront à la partie réseau de l'adresse, la partie hôte de

l'adresse sera fournie automatiquement au poste client grâce au service radvd.
Figure 9.4. Obtention d'un adresse 64 bits
Dans l'exemple ci-dessus, l'adresse obtenue est 2001:470:1F01:1908::/64

 Il faut ensuite activer le routage IPv6, cette commande doit être effectuée en root.
root@poste:# echo 1 >/proc/sys/net/ipv6/conf/all/forwarding
 Ajout de l'adresse /64 à votre interface eth0
A noter: si votre poste dispose de 2 interfaces eth0 et eth1, on peut reserver l'interface eth0
pour la connexion internet et eth1 pour la connexion au réseau local, dans ce cas il vous
faudra configurer l'interface eth1 pour le routage IPv6.
root@poste:# ip -6 addr add 2001:470:1F01:1908::/64 dev eth0
Normalement votre poste/routeur a une nouvelle adresse IPv6:
root@poste:# ifconfig |grep inet6

adr inet6: 2001:470:1f01:1908::/64 Scope:Global
 Configurer le démon radvd.
Si vous n'avez pas encore installé "radvd" sur votre poste qui fera office de routeur, il faut
faire "apt-get install radvd".
Creéz ou modifiez le fichier /etc/radvd.conf en y mettant l'adresse 64 bits qui vous a été
fournie (A noter : le fichier radvd.conf n'est pas créé lors de l'installation du paquet radvd):
interface eth0
{
AdvSendAdvert on;
prefix 2001:470:1F01:1908::/64
{
AdvOnLink on;
AdvAutonomous on;
};
};
Relancer le demon radvd:
root@poste:# invoke-rc.d radvd restart
Votre routeur est maintenant configuré.
 Test sur un poste client de votre réseau local.
Aucune configuration n'est à faire sur les postes clients, c'est le principal atout d'IPv6 avec
le concept d'auto-configuration.
Au démarrage, votre poste client doit avoir récupéré une nouvelle adresse IPv6 :
joelle@ns1:~$ ifconfig |grep inet6

adr inet6: 2001:470:1f01:1908:20e:35ff:fe8f:6c99/64 Scope:Global
adr inet6: fe80::20e:35ff:fe8f:6c99/64 Scope:Lien
Vous pouvez y remarquer l'adresse 2001:470:1f01:1908:20e:35ff:fe8f:6c99/64, les 64

premiers bits (partie réseau) correspondent à l'adresse fournie par votre routeur, les 64 bits
suivants (partie hôte) sont dérivés de l'adresse MAC de la carte réseau du poste client.

Si votre poste était déjà démarré, la commande dhclient ethx vous permettra également de
récupérer la nouvelle adresse IPv6.
Vous pouvez normalement effectuer des ping6 sur votre routeur et sur des sites distants:
joelle@ns1:~$ ping6 2001:470:1f01:ffff::e21

PING 2001:470:1f01:ffff::e21(2001:470:1f01:ffff::e21) 56 data bytes
joelle@ns1:~$ ping6 2001:470:1f01:ffff::e20

PING 2001:470:1f01:ffff::e20(2001:470:1f01:ffff::e20) 56 data bytes
64 bytes from 2001:470:1f01:1908::: icmp_seq=1 ttl=64 time=3.02 ms
64 bytes from 2001:470:1f01:1908::: icmp_seq=2 ttl=64 time=3.01 ms
joelle@ns1:~$ ping6 www.kame.net

PING www.kame.net(orange.kame.net) 56 data bytes
64 bytes from orange.kame.net: icmp_seq=1 ttl=54 time=391 ms
64 bytes from orange.kame.net: icmp_seq=2 ttl=55 time=387 ms
joelle@ns1:~$ traceroute6 www.kame.net

traceroute to www.kame.net (2001:200:0:8002:203:47ff:fea5:3085) from
2001:470:1f01:1908:20e:35ff:fe8f:6c99, 30 hops max, 16 byte packets
1 2001:470:1f01:1908:: (2001:470:1f01:1908::) 6.333 ms 2.986 ms 2.962 ms
2 2001:470:1f01:ffff::e20 (2001:470:1f01:ffff::e20) 178.608 ms 193.581 ms
178.45 ms
Nous avons ici effectué un ping6 sur l'adresse de début de tunnel , de fin de tunnel, sur le
site www.kame.net.
Si les ping6 fonctionnent bien, alors on peut considérer que votre poste client est bien
configuré pour se relier au réseau IPv6.
 Test de Mozilla sur votre poste client:
Figure 9.5. Test du site www.kame.net
A la fin de la page affichée sur ce site, vous pouvez vérifier que votre client est bien
connecté sur ce site avec l'adresse 2001:470:1f01:1908:20e:35ff:fe8f:6c99/64.
Autre site à tester :
Figure 9.6. Test du site www6.tahi.org

Votre configuration Ipv6 est bien opérationnelle et le sera automatiquement pour tous les
postes de votre réseau local.
Bien d'autres services pourront être testés comme dns pour IPv6 , ip6tables...
Chapter 10. Installation d'un serveur Telnet et FTP
Emulation VTx et transfert de fichier.
Table of Contents

TCP-Wrapper
TCP Wrapper
Procédure de tests
Le document décrit l'installation d'un service de transfert de fichiers, la configuration du service

inetd et quelques premiers aspects touchant à la sécurité des services sous GNU/Linux.
Mots clés : Telnet, FTP, ssh, sftp, scp, TCP-Wrapper

Vous devriez à la fin pouvoir :
 utiliser le service FTP du serveur à partir d'un client quelconque du réseau

 bénéficier du service ftp anonyme ou authentifié,
 pouvoir filtrer l'accès provenant de tout ou partie du réseau avec TCP-Wrapper.
1) Telnet:
Telnet est un protocole qui permet l'émulation de terminal VTx à distance sur un serveur
Unix/Linux.
2) FTP:
FTP est un protocole de communication qui permet le transfert de fichiers entre plusieurs
machines.
3) Le daemon inetd:
Toute application fonctionnant sous TCP/IP est basée sur le modèle client/serveur. Par exemple
quelqu'un se connectant via telnet à un hôte distant « active » chez l'hôte le service serveur
telnetd.
Chaque serveur est sur une machine en attente d'une connexion sur un port particulier. Dans les
premières versions d'Unix-TCP/IP chaque application (telnet, ftp,...) avait son propre serveur qui
était lancé au démarrage de chaque machine comme un "daemon". Cette stratégie encombrait
inutilement la table des processus (autant de serveurs que de services). Ces services sont dits
fonctionnant en mode « autonome » ou « standalone ».
Le daemon INETD est un « super » serveur, à l'écoute sur plusieurs ports et qui se charge de
recevoir les demandes de connexion de plusieurs clients (telnet, ftp,...) et de lancer le serveur
correspondant à la demande. A son démarrage il consulte les fichiers:
- /etc/services qui contient la liste générale des services TCP/IP avec leur numéro de port et le
protocole de transport associé.
- /etc/inetd.conf qui contient la liste des services activés sur une machine donnée
Dans les distributions récentes (Mandrake 10.x, RedHat 9.x...), inetd a été remplacé par xinetd. Le
principe est très similaire, à la seule différence que, dans /etc/etc/xinetd.d, chaque service (telnet,
ftp, pop3...) dispose de son propre fichier de configuration.
Certains services utilisables avec inetd ou xinetd comme telnet, ftp, pop3... sont difficilement
sécurisables car les mots de passe transitent en clair sur le réseau. Ce problème sera vu
ultérieurement avec les TPs sur la métrologie. Si ces services sont utilisables en l'état sur des
petits réseaux isolés, il faudra éviter de les utiliser sur des réseaux reliés à Internet ou dans des

environnements peu sûrs. Cependant, la tendance est au cryptage de ces services, grâce à SSL
notamment. Il existe une version sécurisée de telnet, nommée telnet-ssl.
/etc/services :
ftp 21/tcp
telnet 23/tcp
smtp 25/tcp mail
pop3 110/tcp # Post Office
etc...
ftp stream tcp nowait root /usr/sbin/ftpd ftpd
#shell stream tcp nowait root /usr/sbin/rshd rshd
#login stream tcp nowait root /usr/sbin/rlogind rlogind
#exec stream tcp nowait root /usr/sbin/rexecd rexecd
Ici, il n'y a que le service ftp qui est activé par le serveur inetd. Les autres lignes sont en
commentaires.
Ces services sont dits fonctionnant en mode « parallèle ».
Le principe est similaire, à la différence que vous avez un fichier de configuration global
"/etc/xinetd.conf", et un fichier de configuration par service, en général dans le répertoire
"/etc/xinetd.d/".
#
# Le fichier xinetd.conf
#
# Some defaults, and include /etc/xinetd.d/
defaults
{
instances = 60
log_type = SYSLOG authpriv
log_on_success = HOST PID
log_on_failure = HOST
cps = 25 30
}
includedir /etc/xinetd.d

Le fichier /etc/xinetd.d/wu-ftpd
# default: on
# description: The wu-ftpd FTP server serves FTP connections. It uses \
# normal, unencrypted usernames and passwords for authentication.
service ftp
{
disable = no
socket_type = stream
wait = no
user = root
server = /usr/sbin/in.ftpd
server_args = -l -a
log_on_success += DURATION USERID
log_on_failure += USERID
nice = 10
}
Le paramètre "disable", permet d'activer/désactiver le service.
le programme "in.ftpd", indique bien que le service est pris en charge par TCPWrapper (C'est le in
qui l'indique, sinon, le binaire s'appellerait ftpd).
Les commentaires en haut du fichier indiquent que ce service ne prend pas en charge
l'encryptage des mots de passe.
TCP-Wrapper
TCP-Wrapper est un outil de sécurité réseau qui permet de contrôler les accès, les tentatives de
connexion sur une machine donnée. Il permet à tout instant de savoir (par journalisation syslogd)
qui essaie d'accéder sur un ordinateur mais également de filtrer les accès. On peut par exemple
sur une machine A interdire les connexions telnet venant d'une machine B tout en autorisant les
connexions FTP venant de cette même machine B.
Principe de fonctionnement:
Exemple: Si inetd reçoit une demande de connexion sur le port 23 il va lancer telnetd.
Tcpwrapper sert d'enveloppe. Il vient « s'intercaler » entre le daemon inetd et le serveur à

démarrer. Quand une demande de service TCP/IP (en réalité TCP ou UDP) arrive sur un port
donné, inetd va lancer TCPD (daemon correspondant à Tcpwrapper) au lieu d'activer directement
le service demandé (telnetd, ftpd, pop3...).
Tcpd prend en charge la requête et met en place ses mécanismes de contrôle. Il peut par
exemple vérifier que les accès depuis la machine cliente sont autorisés. Une fois le traitement
terminé il va (s'il y a autorisation) lancer son propre service in.telnetd, in.ftpd, in.imapd....
Sous Linux, tcpd est installé par défaut. On peut voir en consultant le fichier /etc/inetd.conf
comment inetd active tcpd.

ftp stream tcp nowait root /usr/sbin/tcpd in.ftpd -l -a
telnet stream tcp nowait root /usr/sbin/tcpd in.telnetd
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.
# Log anything (except mail) of level info or higher.
# Don't log private authentication messages
# The authpriv file has restricted access.

authpriv.* /var/log/auth.log
auth,authpriv.none; /var/log/syslog
Feb 3 18:02:52 ns1 ftpd[1051]: FTP session closed

Feb 3 18:03:31 ns1 syslogd 1.3-3: restart.
Feb 3 18:07:34 ns1 in.ftpd[1057]: refused connect from cli1.archinet.edu
Feb 3 18:07:46 ns1 in.ftpd[1058]: connect from ns1.archinet.edu
Feb 3 18:10:57 ns1 login[1063]: LOGIN ON ttyp3 BY mlx FROM puce
Remarques:
La commande kill -HUP pid de sysklogd permet de redémarrer ce processus avec prise en
compte des paramètres se trouvant dans /etc/syslog.conf. Il est aussi possible d'invoquer le script
de lancement du service en lui passant l'argument restart : /etc/init.d/syslogd restart
Ouvrez le fichier /etc/inetd.conf, vérifiez que les lignes qui activent les démons telnet et ftp sont
décommentées.
Vérifier qu'il n'y a aucune règle active dans les fichiers /etc/hosts.allow et /etc/hosts.deny (mettez
les règles éventuelles en commentaire)
Pour l'activer manuellement utilisez la commande : /etc/init.d/inetd stop | start
Procédure de tests
1 - Créez un compte d'utilisateur.
2 - Sur la console, ouvrez une session sous le compte root.
3 - Vous devez pouvoir utiliser les commandes :
«#> ftp localhost » ou « ftp `hostname` » en vous authentifiant avec le compte que vous
avez créé
«#> telnet localhost » ou « telnet `hostname` » en utilisant le compte que vous avez
créé.
où `hostname` indique le nom d'hôte de votre machine.
Si ces commandes fonctionnent sur le serveur, réaliser les opérations à partir d'un client distant.
Vous pouvez vérifier le fonctionnement de « tcpwraper »
1 - Interdisez tout dans le fichier /etc/hosts.deny (mettre ALL:ALL à la fin du fichier). Attention,
mettez plusieurs retours chariots (CR/LF) à la fin du fichier sinon la dernière ligne n'est pas lue.
Vous avez des exemples dans "man 5 hosts_access" ou man "hosts.allow".
2 - Vérifiez que l'accès ftp est maintenant refusé, vérifiez les messages dans /var/log/syslog et
/var/log/auth.log
Vous devriez voir, dans les fichiers de log (journaux) les demandes ftp rejetées par TCPWrapper.

Remettez le fichier hosts.deny dans son état initial.
Q - je ne peux pas accéder au serveur en utilisant le compte root.
R - Vous pouvez réaliser cette opération sur la console, mais par mesure de sécurité cette
opération n'est pas possible à distance. Avec telnet, ouvrez une session sur un compte
d'utilisateur standard, puis la commande « su ».
Q - Je n'arrive pas ouvrir de session Telnet ou FTP.
R - Vérifier le fichier de configuration « /etc/inetd.conf », puis que le serveur inet est bien lancé.
Q - J'ai modifié les fichiers host.allow et host.deny. Les modifications n'ont pas l'air d'être prises en
compte.
R - Vérifiez la syntaxe des instructions utilisées dans ces fichiers, normalement la modification des
règles est prise en compte dynamiquement sans avoir besoin de relancer le service. Insérez
quelques lignes vides à la fin de ces fichiers.
Attention : les services telnet et ftp n'offrent aucune solution de sécurité sur les réseaux
(transmission des données en clair). Sur un réseau qui n'est pas sûr vous ne devrez pas utiliser
ces services.
Il y a d'autres fichiers de configuration qui permettent de sécuriser le service FTP. Ces fichiers,
dans /etc, sont indépendants de TCP Wrapper. Regardez ftpaccess, ftpgroup, ftphosts, ftpusers et
leurs pages de manuel. Avec ftpusers, vous pouvez autoriser/interdire l'accès pour un compte en
particulier.
Sources de documentation complémentaires
Les pages du manuel de TCPWrapper. man syslog.conf ou man syslogd pour plus de
renseignements.
Chapter 11. TP Unix - Gestion des Utilisateurs
Table of Contents

Exercices
Exercices

Exercice
Droits par défaut
Exercice
Ajout de comptes
Exercices
Exercice
Abstract
Mode d'utilisation du serveur Unix/Linux. Environnement BTS Informatique deuxième année.
Objectif : Mettre à disposition un environnement à des utilisateurs, gérer les accès aux fichiers, les
droits, l'environnement de travail, gérer les groupes..
Contexte : pour cet exercice, on imagine que l'on travaille dans une entreprise dont deux services
sont connectés au réseau : le service Commercial, et le service Comptable. L'ambiance au sein
du service de comptabilité est assez conviviale, et bien que toutes les informations traitées soient
absolument secrètes (et donc interdites en accès à toute autre personne qu'un comptable), ces
personnes ont l'habitude de partager leurs données. Concernant les commerciaux, au contraire,
tous leurs travaux sont absolument secrets (échanges commerciaux, ristournes et remise, chiffre
d'affaires, arrangements divers...)
Pré-requis : Documentation et exercice de Jean Gourdin : Document sur la site linux-keops.com
La séquence de log : lorsqu'un utilisateur se logue, tout est géré par le programme login. Ce
programme va obéir aux PAM (Pluggable Authentification Module), qui vont lui indiquer une suite
d'étapes à valider. Ce point, même si il est très intéressant, ne sera pas étudié ici. Disons
simplement que le fichier /etc/passwd sera certainement lu (si on utilise une authentification
standard et locale, et pas du NIS, ou du LDAP), et que diverses informations concernant
l'utilisateur seront ainsi récupérées : son nom, son répertoire home, son programme de
connexion.
Le contenu du fichier /etc/profile sera exécuté (réglages génériques pour tous les utilisateurs).
Selon le shell de connexion, d'autres scripts seront utilisés : si il s'agit d'un shell de login, et que le
shell est bash, alors ~/.bash_profile ou ~/.bash_login ou ~/.profile seront lus. A la
déconnexion, ~/.bash_logout sera exécuté.
Si il s'agit d'une connexion distante, d'un sous-shell, ou d'un xterm, alors /etc/bash.bashrc puis
~/.bashrc seront exécutés.

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 ?
Peut être avez vous remarqué le fichier /etc/bash_completion.
Vous connaissez la complétion, mais celle-ci est encore supérieure : vous le découvrirez dans
l'exercice suivant
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...
Extension de ces réglages à tous les nouveaux utilisateurs (ou 'du bon usage de /etc/skel')
Dans le répertoire /etc/skel, vous trouverez le squelette de tous les nouveaux comptes : tout ce
qui y est présent sera recopié par défaut dans le répertoire de chaque nouvel utilisateur

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.
Droits par défaut
Gestion des droits : Vous avez certainement remarqué la commande umask. Cette commande
définit les droits standards dont seront affublés vos fichiers. Les droits normaux sont 666 pour un
fichier, et 777 pour un répertoire. Umask vient en soustraction pour le calcul des droits. L'emploi
d'umask seul permet d'afficher la valeur d'umask, et umask XXXX permet de définir l'umask à
XXXX.
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.
Ajout de comptes
Dans le contexte décrit, on peut proposer de résoudre le problème par la création de deux
groupes (commerciaux et comptables). Il semble préférable de créer le home de chaque
utilisateur dans /home/NomDuGroupe, dans un souci de bonne gestion.
Le comportement par défaut de création des comptes est piloté par /etc/adduser.conf.
Selon la taille de la population d'utilisateurs à gérer, on pourra modifier ce fichier pour adapter la
gestion à nos besoins. Dans notre cas, on utilisera des groupes : on créera des groupes, et on
créera des utilisateurs dans ces groupes.
Modification du fichier /etc/adduser.conf

Ce fichier définit le fonctionnement par défaut, il est suffisamment documenté pour que vous
puissiez vous débrouiller seul. On peut y définir le shell de connexion proposé par défaut, le nom
du répertoire contenant les home directories, l'endroit des squelettes, etc...
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)
Les commandes chmod, chown et chgrp permettent d'attribuer, de modifier des droits sur les
objets du file system (fichiers et répertoires)
(faire un man)
D'autre part, un utilisateur peut appartenir à plusieurs groupes (un groupe principal, et d'autres
additionnels)
Cela permet une certaine souplesse dans les droits, bien que seule l'utilisation des ACLs puisse
permettre de tout gérer (au prix d'une dangereuse complexité).
Pour ajouter un utilisateur dans un groupe additionnel, utilisez adduser user groupAdditionnel.
Vous pourrez alors donner des droits à ce groupe, et l'OS évaluera les droits de chaque utilisateur
par rapport à l'ensemble de ses groupes
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.

Chapter 12. Travaux pratiques : Telnet et FTP
Table of Contents
Quelques remarques
Quelques remarques
 Relevez dans /etc/services les ports utilisés par les services telnet, ftp, pop3, dns, smtp,
http.
 Installez et testez les services telnet et ftp à partir de votre poste puis à partir d'un autre
poste. Utilisez les traces dans les journaux pour identifier les problèmes.
tail -f /var/log/syslog
 Utilisez TcpWrapper pour autoriser/interdire le service telnet, le service ftp, tous les
services. Vous testerez l'accès à partir de votre poste, d'un autre poste.
Attention : Pensez à relancer un service serveur chaque fois que vous avez modifié son fichier de
configuration, ceci est vrai pour tous les services et ne sera plus répété. En général utilisez la
manipulation suivante "/etc/init.d/NomDuService start | stop | status | restart"
Il est possible que le client ftp soit remplacé par un autre programme comme "lftp" par exemple.
C'est ce programme qui sera utilisé dans le TP, vous adapterez si vous utilisez autre chose.
Fondamentalement ça ne changera rien, mais lftp est beaucoup plus riche fonctionnellement que
les clients ftp standard. Il supporte 6 méthodes d'accès ftp, ftps, http, https, hftp et fish.
La freeduc-sup est configurée pour ne pas supporter les transactions et protocoles "non-sûrs". Si
vous utilisez un client autre comme une knoppix par exemple,vous devrez installer le support ssl.
apt-get install telnetd-ssl
1. Relevez le port utilisé par telnet dans le fichier /etc/services

2. Décommentez la ligne qui concerne telnet dans /etc/inetd.conf et relancez le service.
3. Vérifiez que le port est bien ouvert avec la commande netstat :
4. #> netstat -atup | grep LISTEN

5. Vérifiez que rien dans TCP-Wrapper n'interdit l'accès au service telnet.

6. # Mettre dans /etc/hosts.allow
7. ALL:ALL
Testez l'accès au service telnet.
1. Interdisez tous les accès dans TCP-Wrapper, testez.

2. # Commentez toutes les lignes dans /etc/hosts.allow
3. # Mettez dans /etc/hosts.deny
4. ALL:ALL
5. En vous aidant des exemples donnés dans "man hosts.allow", autorisez l'accès pour une
machine du réseau sur le service telnet, interdisez-le pour toutes les autres, testez.
L'accès authentifié est simple à mettre en oeuvre.
1. Relevez les ports utilisés par ftp dans /etc/services.

2. Activez le service dans inetd.conf et lancez le service.
3. Vérifiez que le port est bien ouvert avec la commande netstat
4. Vérifiez que rien n'interdit l'accès au service ftp dans les fichiers hosts.allow et hosts.deny
5. Faites un test en utilisant un compte système existant, par exemple "lftp localhost -u util" si
util est votre compte.
Normalement c'est terminé, tout doit fonctionner. Si cela ne fonctionne pas, vérifiez que vous
n'avez rien oublié, vérifiez aussi les fichiers de log (/var/log/daemon, /var/log/syslog,
/var/log/messages)
La mise en place d'un service ftp anonyme demande plus de manipulations. Vous allez mettre
l'environnement dans /home.
1. Vérifiez que le fichier /etc/passwd dispose bien d'un compte ftp :

2. knoppix@master:~/tmp$ grep ftp /etc/passwd
3. ftp:x:1003:1003:Compte ftp anonyme:/home/ftp:/bin/true
sinon modifie les fichier "/etc/passwd" pour ajouter la ligne. Attention, prenez un "UID" libre.
4. Créez un compte de groupe dans le fichier /etc/group :

5. knoppix@master:~/tmp$ grep ftp /etc/group
6. ftp:x:1003:

7. Utilisez la commande "pwconv" pour mettre à jour le fichier shadow.
8. Remarque si vous avez des problèmes d'accès sur le serveur

9. ftp anonyme par la suite :
10. Il s'agit peut être d'un problème de définition du compte
11. dans le fichier "/etc/shadow". Vous pouvez pour cela utiliser
12. plusieurs options :
13. A) Première option
14. 1 - taper "pwunconv"
15. 2 - modifier le fichier "/etc/passwd" comme indiqué ci-dessus
16. 3 - taper "pwconv" pour "recacher" les mots de passe.
17.
18. B) Deuxième option
19. 1 - utiliser la commande "adduser ftp" qui va mettre les fichiers
20. "/etc/passwd" et "/etc/shadow" à jour. Mettez un mot de passe bidon.
21. 2 - taper "pwunconv" et supprimer le mot de passe du compte dans
22. "/etc/passwd" (mettre "*" par exemple)
23. 3 - remplacer aussi le shell "/bin/bash" par "/bin/true", enregistrer.
24. 4 - taper "pwconv" pour "recacher" les mots de passe.
25. 5 - supprimer /home/ftp (rm -rf /home/ftp)
26. 6 - continuer la procédure ci-dessous.
27. Sous le compte root vous allez créer l'environnement pour le service ftp :
28. cd /home && mkdir -p ftp/lib ftp/bin ftp/pub ftp/incoming ftp/etc
On copie le programme ls dans ~ftp/bin. Vous pouvez en mettre d'autres, mais soyez
prudent.
cp /bin/ls ftp/bin
Il reste à créer les comptes dans un fichier local passwd et group. On y met juste les
comptes nécessaires pour l'utilisation des programmes mis dans ~ftp/bin.
root@master:/home# grep ftp /etc/group > ftp/etc/group

root@master:/home# grep root /etc/passwd > ftp/etc/passwd
root@master:/home# grep ftp /etc/passwd > ftp/etc/passwd
Vérifiez que vous avez bien les informations dans les fichiers ftp/passwd et ftp/group.
On change les permissions
chmod -R 111 ftp/bin ; chmod 111 ftp/etc; chmod 444 ftp/etc/*;\

chmod 555 ftp/pub; chmod 1733 ftp/incoming
On rajoute dans ~ftp/lib les librairies utilisées par les programmes mis dans ~ftp/bin. Vous
avez, vous le programme "ls". Les librairies utilisées par le programme ls sont visibles avec
la commande "ldd".
Si vous ajoutez d'autres programmes, il faudra y mettre également les bonnes librairies.
root@master:/home# ldd /bin/ls

librt.so.1 => /lib/librt.so.1 (0x4001f000)
libc.so.6 => /lib/libc.so.6 (0x40031000)
libpthread.so.0 => /lib/libpthread.so.0 (0x40141000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
Il faut donc copier toutes ces librairies dans ~ftp/lib.
cp /lib/librt.so.1 /lib/libc.so.6 /lib/libpthread.so.0 /lib/ld-linux.so.2 ftp/lib

Voici donc ce que vous devriez avoir à la fin:
root@master:/home# ls -alR ftp

root@mr:/home# ls -alR ftp
ftp:
total 28
drwxr-sr-x 7 root root 4096 2003-09-19 12:19 .
drwxrwsr-x 7 root root 4096 2003-09-19 12:21 ..
d--x--x--x 2 root root 4096 2003-09-19 12:22 bin
d--x--x--x 2 root root 4096 2003-09-19 12:19 etc
drwx-wx-wt 2 root root 4096 2003-09-19 12:19 incoming
drwxr-sr-x 2 root root 4096 2003-09-19 12:21 lib
dr-xr-xr-x 2 root root 4096 2003-09-19 12:19 pub
ftp/bin:
total 76
d--x--x--x 2 root root 4096 2003-09-19 12:22 .
drwxr-sr-x 7 root root 4096 2003-09-19 12:19 ..
---x--x--x 1 root root 64428 2003-09-19 12:22 ls
ftp/etc:
total 16
d--x--x--x 2 root root 4096 2003-09-19 12:19 .
-r--r--r-- 1 root root 12 2003-09-19 12:19 group
-r--r--r-- 1 root root 87 2003-09-19 12:19 passwd
ftp/incoming:
total 8
drwx-wx-wt 2 root root 4096 2003-09-19 12:19 .
ftp/lib:
total 1296
drwxr-sr-x 2 root root 4096 2003-09-19 12:21 .
-rwxr-xr-x 1 root root 82456 2003-09-19 12:22 ld-linux.so.2
-rwxr-xr-x 1 root root 1104040 2003-09-19 12:22 libc.so.6
-rw-r--r-- 1 root root 81959 2003-09-19 12:22 libpthread.so.0
-rw-r--r-- 1 root root 26592 2003-09-19 12:22 librt.so.1
ftp/pub:
total 8
dr-xr-xr-x 2 root root 4096 2003-09-19 12:19 .
29. C'est normalement terminé.
1. Activez le service dans inetd.conf et lancez le service inetd si ce n'est pas déjà fait.
2. Vérifiez que le port est bien ouvert avec la commande netstat
3. root@mr:/home# netstat -atup | grep LISTEN

4. tcp 0 0 *:ftp *:* LISTEN
879/inetd
5. Vérifiez que rien n'interdit l'accès au service ftp dans les fichiers hosts.allow et hosts.deny
6. Commentez le fichier /etc/ftpusers comme ci-dessous :

7. # /etc/ftpusers: list of users disallowed ftp access. See ftpusers(5).
8. root
9. #ftp
10. #anonymous
11. Testez et vérifiez le bon fonctionnement de l'accès ftp anonyme (en utilisant le compte "ftp"
ou "anonymous" avec la commande :
12. lftp localhost -u anonymous

13. ou
14. lftp localhost -u ftp
Si la configuration est correcte, vous devriez avoir le résultat suivant :
root@master:/home# lftp localhost -u ftp

Mot de passe: #Il n'y a pas de mot de passe, faites ENTREE
lftp ftp@localhost:~> ls
total 20
d--x--x--x 2 0 0 4096 May 5 03:35 bin
d--x--x--x 2 0 0 4096 May 5 03:35 etc
drwx-wx-wt 2 0 0 4096 May 5 03:04 incoming
dr-xr-xr-x 2 0 0 4096 May 5 03:32 lib
dr-xr-xr-x 2 0 0 4096 May 5 03:04 pub
15. Commentez la ligne anonymous dans le fichier /etc/ftpusers et refaites un essai de

connexion.
16. Faites un test en utilisant un compte système existant, par exemple "lftp localhost -u util" si
util est votre compte.
17. Restaurez l'état initial du fichier /etc/ftpusers.
18. Interdisez l'accès ftp avec TCP-Wrapper. Testez avec l'accès anonyme et en utilisant un
compte authentifié.
19. Que peut-on conclure des deux méthodes de protection ?
On désactive en général ces services sauf cas très particulier, car les transactions ne sont pas
cryptées. On préfère utiliser les services ssh, scp et sftp. Vous devez avoir un service sshd actif
sur le serveur.
Exemple d'utilisation ssh :
[root@uranus etc]# grep ssh /etc/services

ssh 22/tcp # SSH Remote Login Protocol
ssh 22/udp # SSH Remote Login Protocol
ssh -l NomUtilisateur Machine
ssh -l mlx localhost
Remarque : Sur la version Live-On-CD, vous devez lancer le démon, car il n'est pas actif par
défaut : /etc/init.d/sshd start. Le lancement de ce serveur permet l'utilisation de ssh et de scp à
partir de clients.
Exemple d'utilisation de sftp :

[root@uranus etc]# grep sftp /etc/services
sftp 115/tcp
sftp 115/udp
[root@uranus etc]# sftp

usage: sftp [-1vC] [-b batchfile] [-osshopt=value] [user@]host[:file [file]]
[root@uranus etc]# sftp mlx@localhost
Connecting to localhost...
mlx@localhost's password:
Vous pouvez ensuite envoyer ou récupérer des fichiers entre les 2 machines.
Exemple d'utilisation de scp :
SYNOPSIS
scp [-pqrvC46] [-S program] [-P port] [-c cipher] [-i identity_file]
[-o option] [[user@]host1:]file1 [...] [[user@]host2:]file2
# Exporte le fichier "unfichierlocal"

scp -S ssh unfichierlocal mlx@hotedistant:/un/chemin/distant/unfichierdistant
# Importe de "hotedistant", le fichier distant "unfichierdistant"
scp -S ssh mlx@hotedistant:/un/chemin/distant/unfichierdistant unfichierlocal
La première ligne exporte un fichier, la deuxième importe. Le compte utilisé est mlx. La transaction
est encryptée avec ssh.
Chapter 13. scp, sftp et les tunnels avec ssh

Revision History
Table of Contents
Présentation
Premiers pas

Proxy HTTP
Autres scénarios
Utilisation de scp
Utilisation de sftp
Références
Abstract
Approche de ssh, des tunnels et des services mandataires
Présentation
Un des principaux risques sur les réseaux provient de "l'écoute" possible puisque toutes les
données transitent, si rien n'est fait, en clair sur les résaeux. C'est à dire qu'elles ne sont pas
cryptées.
Il est ainsi possible de récupérer sans difficulté les mots de passe des personnes utilisant le
réseau, leur messages, et d'espionner toutes leurs transactions, y compris celles passées sur des
serveurs HTTP. Ceci est lié à la méthode d'accès des réseaux. Le principe de la commutation par
switch permet de limiter un peu les risques mais n'est pas imparable.
Il existe des solutions permettant de sécuriser un minimum les transactions. Nous allons voir
rapidement quelques modes d'utilisation de ssh et de logiciels comme scp, sftp, unisson et rsync
afin de voir comment évoluer dans un environnement plus sûr.
Il sera fait référence à la maquette suivante :
Figure 13.1. Schéma maquette
Qu'est ce que ssh ?

En fait ssh ou Secure SHell, propose un shell sécurisé pour les connexions à distance et se
présente dans ce domaine comme le standard "de fait". Mais ce n'est pas que cela. Nous allons
essayer de voir quelques modes d'utilisation de ce produit.
Dans une transaction traditionnelle, un client (personne ou programme) émet une requête TCP
vers un serveur. Il y a un processus serveur utilisant un port et un processus client utilisant
également un port. Par exemple pop3. Il y a donc un processus serveur et un processus client.
Avec ssh, il sera possible d'établir un tunnel crypté (ou chiffré) entre le client et le serveur.
Il faut bien comprendre ce dont il s'agit et les processus mis en oeuvre.
Sur la machine serveur vous allez avoir 2 processus serveurs. Le serveur pop3 et le serveur SSH.
Sur le client, vous allez également avoir 2 processus. Le client pop3 et le client ssh. Le client pop3
se connecte au tunnel (le client ssh local). Le serveur pop3, est relié au serveur ssh distant. Les
transactions passent dans le tunnel.
Le client ssh devient un serveur mandataire (proxy) pour le protocole tunnelé. Le serveur ssh
devient le client proxy pour le serveur.
Figure 13.2. Schéma du fonctionnement
Sur le diagramme, le canal entre le port tcp de l'application cliente et le port client du tunnel n'est
pas chiffré. Il en est de même entre le port tcp de l'application serveur et le port serveur du tunnel.
Seul, le canal entre les 2 ports du tunnel est chiffré.
L'application cliente n'utilise plus le port par défaut qu'écoute normalement le serveur.
L'utilisation d'un tunnel ssh impose des contraintes. Par exemple, dans l'exemple ci-dessus, si
vous voulez utiliser l'application cliente avec un autre serveur, il faudra recréer un autre tunnel et
reconfigurer le client. Vous pouvez créer deux tunnels différents, mais vous devrez avoir deux
applications clientes utilisant des ports différents. Tout cela convient bien sur des environnements
simples, mais reste un peu contraignant si l'environnement est complexe.
Pour tunneler un réseau ou de multiples clients, le mieux est d'installer un serveur ssh capable de
recevoir plusieurs connexions et servant ainsi de serveur proxy aux clients du réseau pour un
service donné et routant les requêtes dans un tunnel sécurisé vers le serveur d'application
concerné.

L'objectif est de pouvoir supprimer d'un serveur toute application utilisant des protocoles "non
sûrs" (ftp, telnet, rsh...), pour les remplacer par des applications plus sûres, ou alors, s'il n'est pas
possible de les désactiver, de les faire passer dans un tunnel crypté.
Des programmes de la même famille comme "scp" ou "sftp" remplacent les commandes ftp ou
rcp.
Avec ssh la totalité de la transaction entre un client et le serveur est cryptée. Le client a la
possibilité d'utiliser des applications X distantes (X11 forwarding) à partir d'une invite shell dans un
environnement sécurisé. On se sert également de SSH pour sécuriser des transactions non sûres
comme pop3 ou imap par exemple. De plus en plus, ces applications supportent maintenant SSL
aussi bien pour les clients que pour les serveurs.
SSH sur GNU/Linux est généralement composé de 3 packages :
OpenSSH général, (openssh),

le serveur OpenSSH (openssh-server)
le client (openssh-clients).
Les packages OpenSSH requièrent le paquetage OpenSSL (openssl).
Chaque fois que cela est possible vous devez utiliser une solution qui chiffre vos transactions.
L'établissement du dialogue entre le client et le serveur suit un protocole particulier :
1. établissement d'une couche transport sécurisée
2. chiffrement des données à l'aide de clefs symétriques pendant la transaction
Le client peut s'authentifier en toute sécurité, et accéder aux applications conformes aux
spécifications du protocole.
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à une 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. A 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.
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
ssh_host_rsa_key clé RSA privée utilisée par sshd pour la
ssh_host_rsa_key.pub clé RSA publique utilisée par sshd pour la
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
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
Nous allons faire nos premières expérences avec ssh. Il vous faut un client et un serveur. C'est
mieux.
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. A 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 crypté.
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
Cette commande a généré une clé DSA par défaut de 1024 bits. La clé privée sera stockée dans
~/.ssh/id_dsa et la clé publique dans ~/.ssh/id_dsa.pub.
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):
Your identification has been saved with the new passphrase.
Attention, il ne faut pas oublier la "passphrase", elle vous sera redemandée. 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 poste 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:
Le système demande votre mot de passe.
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
Le système distant ne demande plus le mot de passe, par contre il 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
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
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.
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 sessions X, si vous lancez l'interface graphique manuellement, cela
deviendra par exemple :
M0:$ ssh-agent xinit

ou
M0:$ ssh-agent startx
Dans tous les cas, il est nécessaire que les variables d'environnement soient définies avant le
lancement du serveur X, qui les exportera par défaut à l'ensemble de vos applications graphiques
(lancées sous X).
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
Ainsi, au prochain lancement d'un serveur X, vous n'aurez plus qu'à ouvrir une fenêtre xterm et
taper la commande: ssh-add
Une autre solution consiste à mettre dans son .xinit ou .xsession :
/usr/local/bin/ssh-add $HOME/.ssh/id_dsa < /dev/null

La commande ssh-add demande la passphrase
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
Avant d'aller plus loin il est important de bien comprendre ce qu'est le "port forwarding".
Nous avons vu qu'il y avait en jeu :
1. - l'application cliente
2. - l'application serveur
3. - le client ssh
4. - le serveur ssh
Nous allons voir la redirection locale '-L' et distante '-R'. La différence vient du sens de la
connexion. Dans le relayage local, le client tcp et le client ssh sont sur la même machine. Dans le
relayage distant ou "remote", le client ssh est sur la même machine que le serveur tcp.
Dans la démarche qui suit, on utilise un client M0 et deux serveurs M1 et M2. On considère que
sur chaque serveur fonctionne un serveur ssh. On considère aussi que sur chaque machine on
dispose d'un compte d'accès sur chaque machine identique avec les clés publiques installées.
Cela évite une authentification à chaque commande ou l'utilisation de l'option '-l' pour préciser le
compte à utiliser sur le serveur.
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
la commande est passée sur M0.
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
Ici localhost indique l'adresse de loopback de la machine distante, c'est à dire ici M1 et sur
laquelle tourne le serveur sshd. C'est donc M0:1234 qui est tunnélé vers le port M1:80 en utilisant
le service M1:22.
Si HOSTNAME est M1 :
M0:$ ssh -L 1234:M1:80 M1 :-/
La connexion est identique mais utilisera l'adresse de la M1 (interface réseau ) plutôt que
l'interface lo.
M0:$ ssh -L 1234:M0:80 M1
La commande connecte M1 sur M0:80.
M0:$ ssh -L 1234:M2:80 M1
Il y aura une connexion (un tunnel créé) entre M0 et M1 mais la redirection est effectuée entre
M1:1234 et M2:80 en utilisant M1:22. Les transactions sont chiffrées entre M0 et M1, mais pas
entre M1 et M2, sauf si un second tunnel ssh est créé entre M1 et M2.
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
les requêtes locales passées sur M1:1234 sont redirigées vers M1:80, mais des requêtes passées
d'autres machines sur M0:1234 ne seront pas, par défaut redirigées.
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.
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

Le port distant est donc sur la machine distante (remote)
On reprend les mêmes machines que précédemment :
M0:$ ssh -R 1234:HOSTNAME:80 M1
Ici M0 à le serveur TCP, il sert donc de relais entre une connexion M1:1234 et HOSTNAME:80. La
connexion est chiffrée entre M1 et M0. Le chiffrement entre M0 et HOSTNAME dépend de la
liaison mise en place.
Si HOSTNAME est localhost, alors on a :
M0:$ ssh -R 1234:localhost:80 M1
Cela ouvre une connexion depuis M1:1234 vers M0:80 car localhost correspond, ici, à M0. Si un
utilisateur passe une requête sur M1:1234, elle sera redirigée vers M0:80.
Si HOSTNAME est M2, on a :
M0:$ ssh -R 1234:M2:80 M1
Cela ouvre une connexion entre M0 et M1:22, mais les requêtes allant de M1:1234 sont redirigés
sur M2:80. Le canal est chiffré entre M1 et M0, mais pas entre M0 et M2.
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.
Figure 13.3. Schéma du fonctionnement
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
Ici on utilise (précise) que le compte utilisé sur la machine distante sera M1.foo.org. Vous devez
faire cela si le nom du compte que vous utilisez sur le client diffère de celui que vous utilisez sur le
serveur.
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
Figure 13.4. Tunnel HTTP
On peut également sans risque aller sur sa zone public_html en toute sécurité.
lynx http://localhost:2038/~mlx
La connexion se fait sur la machine locale et sur le port forwardé. Ni le compte utilisateur utilisé, ni
le mot de passe ne transitent en clair.
Avec la machine sur lequel le test est réalisé, les commandes :

et
M0:$ ssh -N -f -L 2038:localhost:80 mlx@foo.org
ne produisent pas la même chose.
En effet :
fait référence à une adresse IP qui est redirigée par un Vhost Apache.

M0:$ ssh -N -f -L 2038:localhost:80 mlx@foo.org
fait référence à l'adresse de loopback, ici c'est le serveur par défaut (typiquement sur une
debian /var/www/) qui est consulté. Si vous avez plusieurs Vhosts, il vous faudra créer un tunnel
par Vhost.
De la même façon, on peut l'utiliser pour une session ftp.

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.
Attention, dans ce dernier exemple, il n'y a que l'authentification qui est chiffrée car le port 20 (ftp-
data) n'est pas forwardé.
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
Voyons comment utiliser une application graphique distante :
M0:$ ssh -C mlx@M1.foo.org

Enter passphrase for key '/home/mlx/.ssh/id_dsa':
M0:$ xclock &
[1] 7771
L'horloge distante s'affiche. L'option "-C", active la compression.
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
Notez le prompt, ici l'ouverture de session a été effectuée en tâche de fond (-f). Pour fermer le
canal ssh, il suffit de fermer l'application.
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
avec u pouvant varier de 0 à 5, suivant que vous voulez avoir la session graphique sur F7...F12.
Pour le système vc7 que vous utilisez par défaut avec CTRL ALT F7 correspond au premier
"display" :0.
Maintenant que nous y voyons plus clair, voici deux scénarios d'utilisation d'un proxy ssh.
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
Il ne reste plus qu'à configurer votre navigateur pour qu'il utilise le proxy local "localhost:3128" et
le tour est joué. Vous pouvez naviguer en toute sécurité, si vos requêtes sont espionnées au
niveau du firewall de votre boîte, elle ne pourront plus être lues.
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

L'option "-g" va transformer votre machine en passerelle pour le tunnel. Les autres n'auront plus
qu'à mettre comme proxy, le nom ou l'adresse de votre machine et le port 3128.
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...
Ici on a créé sur le proxy 2 ports, 3130 et 3131 qui redirigent vers le port 3128. Il suffit ensuite à
partir des machines distantes (réseaux distants) de créer les tunnels vers ces ports.
MY$ ssh -g -N -f -L 3128:localhost:3130 mlx@M1

MZ$ ssh -g -N -f -L 3128:localhost:3130 mlx@M1
et d'utiliser les redirections comme cela a été expliqué plus haut.
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
où SITEWEB est l'url du site web que vous souhaitez atteindre (typiquement un webmail). Ici, la
configuration du navigateur ne change pas. Le proxy est le même. Vous évitez juste l'utilisation
d'un squid si vous n'en avez pas.
Remarque, dans le navigateur vous pouvez taper tout ce que vous voulez (yahoo, wanadoo,
google...) vous arriverez toujours sur SITEWEB.
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.
rsync est un outil largement utilisé pour la synchronisation de répertoires sur la même machine ou
sur des machines distantes. (création de miroirs distants).
rsync est intéressant car il ne mettra à jour sur le "repository" qui reçoit uniquement les fichiers qui
ont été créés ou modifiés. Cela procure un gain non négligeable par rapport à une simple
"recopie" de toute l'arborescence dans le cas ou peu de fichiers sont modifiés.
rsync et rsyncd, associés à des scripts et à la crontab, est une option remarquable pour la
réplication de disques entre 2 ou plusieurs machines.

Si vous souhaitez "mirorrer" un disque local vers un répertoire que vous avez sur une autre
machine sur internet, il vous faudra également passer par une procédure d'authentification. Si
vous avez exporté votre clé publique sur la machine distante, vous allez pouvoir synchroniser les
disques dans un tunnel sécurisé avec ssh et sans avoir à entrer votre mot de passe. Par exemple,
la commande :
cd & & rsync -e ssh -valptz * mlx@M1.foo.org
synchronisera votre $HOME local, sur le $HOME de la machine distante.
Il existe bien sûr des applications graphiques basées sur le concept rsync.
Une autre option pour la synchronisation de disques distants est "unison". unison est un produit
particulièrement performant :
http://www.cis.upenn.edu/~bcpierce/unison/index.html
unison permet l'utilisation en mode commande (scripts) mais propose aussi une interface
graphique.
L'utilisation de ces commandes est relativement simple. SCP permet de faire de la copie de
fichiers. SFTP est utilisable en mode intéractif ou en mode batch et ressemble plus au FTP.
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"
donne la liste des fichiers distants qui sont dans le répertoire "psionic". Pour copier ces fichiers
localement dans un répertoire psionic on va utiliser :
cd && mkdir psionic

scp mlx@M1.foo.org:/home/mlx/psionic/* ~/psionic
Ou pour envoyer les fichiers du répertoire local psionic, vers le répertoire tmp qui est dans
/home/mlx de la machine M1.foo.org :
scp ~/psionic/* mlx@foo.org:/home/mlx/tmp

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
Références
Voir les pages de manuels de ssh et aussi :
1. openssh
2. miscmag
Un article de Jean-Philippe Gaulier sur SSH en Français:-)
Chapter 14. Mettre en place un VPN avec PPP et SSH

Revision History

Table of Contents
Présentation
Le protocole PPP
L'analyse de trame
Conclusion
Abstract
Approche de SSH, de PPP, des VPN et des services mandataires
Présentation
Nous allons voir comment mettre en place un réseau virtuel privé qui s'appuie sur le protocole
PPP dans un tunnel SSH. Cette solution va permettre de mettre en place sur les clients tout type
de service mandataire (proxy) pour accéder en toute sécurité à des services serveurs, dans une
liaison point à point, et ainsi utiliser des protocoles en toute sécurité, que ceux-ci soient chiffrés ou
non.
Si vous ne connaissez pas SSH, je vous recommande de commencer par le document qui aborde
le fonctionnement de ce protocole et la mise en place de tunnels sécurisés avec ce produit.
Certains aspects qui sont abordés ne seront pas repris ici.
Il sera fait référence à la maquette suivante :
Figure 14.1. Schéma maquette
La machine cliente est sur un réseau privé ou public. Peu importe. Il dispose des applications
clientes SSH, PPP, d'un UA (client de messsagerie) et éventuellement un serveur SMTP pour les
besoins de la démonstration.
Le serveur est sur une adresse publique. Mettre le serveur sur une adresse privée n'est pas
compliqué, mais nécessite de mettre en place des tables de translation d'adresses sur les
routeurs. Nous ferons donc sans cela pour ne pas multiplier les problèmes, mais dans la réalité

les VPN servent surtout à relier deux ou plusieurs réseaux privés distants, relié par un réseau
public ou "non sûr"..
Le serveur dispose de tous les services (dns, smtp, pop3, imap, proxy http(s) et ftp ...) qui
serviront aux tests, d'un serveur sshd et d'un serveur pppd pour la création du VPN et du tunnel.
Les routeurs relient deux segments distants via internet ou tout autre type de liaison. Ils peuvent
être des pare-feu.
Voici les adresses ethernet affectées aux machines, et les adresses PPP qui seront utilisées pour
le VPN :
Client Serveur
eth0 192.168.90.2 195.115.88.38
ppp0 192.168.0.2 192.168.0.1
Le protocole PPP
Sans trop entrer dans les détails, nous allons faire un petit tour du protocole PPP puisqu'il en est
question dans ce document.
Le protocole PPP (Point to Point Protocol) est un protocole de niveau 2. Il supporte des liaisons
point-à point synchrones ou asynchrones.
PPP est composé de trois grandes entités :
1. Un protocole qui servira à l'encapsulation des paquets avant dépôt sur le média physique :
HDLC. HDLC est un protocole de liaison de données.
2. LCP (Link Control Protocol) qui sert à établir (ou rompre) la liaison, qui permet de la tester
et de la configurer.
3. NCP (Network Control Protocol) qui sert d'interface pour les protocoles de niveau 3. Il n'y a
pas un (1) protocole NCP, mais "n". En effet, chaque protocole de niveau 3 dispose de sa
propre interface particulière. Sur ip, l'implémentation NCP se nomme IPCP (IP Control
Protocol).
Un paquet PPP peut véhiculer plusieurs protocoles de niveau 2 ayant chacun un rôle, ou des
paquets contenant des données de niveau 3. Voici quelques exemples avec les numéros de
protocoles.
1. 0021, indique un transport de données IP

2. 8021, IPCP. Ce protocole permet de déterminer les adresses de la liaison point à point
entre les deux noeuds distants. Affectation statique ou dynamique des adresses,
compression des entêtes IP...
3. C021, paquet contenant des données LCP
4. C023, paquets de type PAP, Password Authentification Protocole
5. C223, paquet sde type CHAP, Challenge Handshake Authentification.

Les numéros de protocoles sont stockés dans un champ "contrôle" du paquet PPP. PAP et CHAP
servent à l'authentification des utilisateurs.
Préparation du client et du serveur.
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
On donne le droit à cet utilisateur de lancer pppd. Il faut rajouter une ligne dans le fichier.
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):
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".
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 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
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
fonctionnent. Le routage est donc bien actif entre ces interfaces, nous allons pouvoir faire
fonctionner des applications clientes et serveur sur ce canal.

Figure 14.2. Schéma du dialogue
Sur le client, les applications sont configurées pour utiliser l'adresse ip affectée à ppp0. Le
dialogue peut être effectué sans chiffrement. Le paquet est délégué à SSH qui va chiffrer puis
déposer le paquet sur eth0.
Sur le serveur les paquets arrivent chiffrés sur eth0. Ils sont déchiffrés par SSH et routés sur
l'interface ppp0 du serveur qui les délivre au service serveur.
Cela présente bien sûr un inconvénient:celui de charger les processeurs et la bande passante
bien que PPP supporte la compression des données. Il n'est pas toujours facile de trouver un bon
compromis entre des options de sécurité par chiffrement tout en tenant compte des coûts que cela
induit.
Figure 14.3. Encapsulation des trames
Le schéma montre que chaque paquet subit deux traitements de plus que s'il était traité
normalement pour l'émission, ce qui en génère également deux de plus lors de la réception.
L'analyse de trame
L'objet de cette manipulation est de vérifier simplement le bon fonctionnement du vpn à l'aide
d'une requête DNS (dig www.yahoo.fr) entre le client et le serveur. La capture intercepte ce qui se
passe sur eth0 et ppp0.

Le fichier resolv.conf est configuré pour utiliser le serveur de nom :
[client]# more /etc/resolv.conf

nameserver 195.115.88.38
Les requêtes passent dans ce cas par eth0.
Sur ppp0 rien ne passe, sur eth0 par contre, il y a du traffic.
[client]# ettercap -T -i eth0

Listening on eth0... (Ethernet)
eth0 -> 00:90:F5:28:D5:06 192.168.90.2 255.255.255.0
Mon Nov 22 10:11:59 2004
UDP 192.168.90.2:32885 --> 195.115.88.38:53 |
.}...........www.yahoo.com.....
Il s'agit bien d'une requête UDP qui est passée sur ETH0, en utilisant comme source
192.168.90.2:32885 et à destination de 195.115.88.38:53. Le trafic n'est pas chiffré.
On va modifier le resolv.conf afin que les requêtes passent par le VPN.
Et on lance la capture sur ppp0 :
[client]# ettercap -T -i ppp0

ppp0 -> 00:00:00:00:00:00 192.168.0.2 255.255.255.255
Mon Nov 22 10:24:04 2004

UDP 192.168.0.2:32885 --> 192.168.0.1:53 |
iF...........www.yahoo.com.....
Mon Nov 22 10:24:04 2004
UDP 192.168.0.1:53 --> 192.168.0.2:32885 |
Maintenant on a bien un trafic sur ppp0. Noter qu'elle n'a pas d'adresse MAC car c'est une
interface logique. Il s'agit bien d'une requête UDP de l'hôte source 192.168.0.2:3288 vers l'hôte
destination 192.168.0.1:53. Ici le trafic n'est pas chiffré.
On la lance également sur eth0 :
[client]# ettercap -T -i eth0

Listening on eth0... (Ethernet)
eth0 -> 00:90:F5:28:D5:06 192.168.90.2 255.255.255.0
Mon Nov 22 10:20:39 2004

TCP 195.115.88.38:22 --> 192.168.90.2:33102 | AP
..!..O.R$.[NP...<G.O._uRH?O."..M36<.Gd.?.. ..Vx.
Mon Nov 22 10:20:39 2004
TCP 192.168.90.2:33102 --> 195.115.88.38:22 | AP
8..1.xV....]....D..q.7:3y.%.&.J..2..8.Qp%.*.."..
Là le dialogue n'est plus dirigé vers de l'UDP/53 mais vers du TCP/22. Il s'agit bien de SSH et plus
rien n'est lisible.
La maquette fonctionne parfaitement, le service mis en place est le premier service proxy actif. Il
s'agit d'un service proxy DNS.

Pour les services pop et imap il n'y a aucun difficulté. Il suffit de configurer le client pour qu'il
relève les courriers sur 192.168.0.1.
En ce qui concerne SMTP il y a deux scénarios posibles :
1. utiliser directement le serveur smtp qui est sur le serveur,
2. utiliser un serveur smtp qui est sur sa propre machine comme cela se fait fréquemment.
Dans le premier cas, la procédure est assez simple. Dans la configuration de votre client de
messagerie (paramètre envoi de message), vous mettez 192.168.0.1, c'est à dire l'adresse du
serveur.
Si vous utilisez votre propre serveur SMTP local sur le client, il faut mettre l'adresse du client :
192.168.0.2.
Mais cela ne suffit pas. Par défaut, si vous ne précisez rien, un serveur SMTP envoie le message
directement au destinataire. C'est la fonction de routage du service SMTP qui assure cela. Il se
base sur l'enregistrement MX de la zone destinataire. Pour faire cela, il faut configurer le serveur
SMTP pour qu'il utilise l'interface eth0 et non pas ppp0. La configuration du client de messagerie
contient, dans ce cas, l'adresse ip de eth0, mais en faisant cela, on utilise plus du tout le VPN.
Pour utiliser le VPN mis en place, il faut indiquer au serveur SMTP local de ne pas envoyer
directement les messages sur internet vers le destinataire, mais de les faire relayer par le serveur
smtp du serveur.
Comment configurer cela ?
On va prendre comme exemple Postfix.
Sur le client, il faut ajouter un paramètre dans /etc/postfix/main.cf :
relayhost = 192.168.0.1 # On demande au serveur de relayer
pour indiquer au serveur smtp local, que les messages seront relayés par le serveur d'adresse
192.168.0.1.
Maintenant le serveur. Il faut lui indiquer qu'il doit accepter et traiter les paquets provenant de
l'adresse 192.168.0.2, voire carrément d'un réseau 192.168.0.0/24 car postfix est généralement
configuré pour ne pas relayer les messages qui ne proviennent pas de son réseau.
Sur le client il faut rajouter un paramètre dans /etc/postfix/main.cf, et ajouter à la variable

"mynetworks", l'adresse du VPN :
# Vous pouvez en avoir d'autres.

mynetworks = 127.0.0.1/32, 192.168.0.0/24
à partir de ce moment, il est possible d'utiliser son service SMTP local pour ne pas changer ses
habitudes, cela, en toute sécurité quel que soit l'endroit où on se trouvons. (Du moins entre les
deux points du VPN) et avec l'énorme avantage d'utiliser un serveur SMTP déclaré ou officiel qui
répond aux contraintes de plus en plus draconniennes que mettent en place les FAI et les
administrateurs systèmes.

La mise en place d'un service proxy squid, ne pose pas non plus de difficulté une fois le VPN
installé. Il doit falloir moins de 3 minutes pour installer Squid sur une debian. Ensuite il faut juste
lui indiquer les machines dont il doit traiter les requêtes.
Comme le service sera installé sur un serveur public, on fera attention aux autorisations données
afin de limiter les risques. Cela se passe dans le fichier de configuration "/etc/squid.conf" et dans
le paragraphe qui décrit les ACL.
On déclare une nouvelle ACL, et on autorise les machines qui répondent à ce critère :
acl vpn src 192.168.0.0/255.255.255.0

http_access allow vpn
Pour le serveur c'est terminé.
Il ne reste plus qu'à configurer les clients d'accès (navigateur) pour qu'ils utilisent le proxy :
192.168.0.1.
Là encore toutes les transactions entre le client et le serveur seront chiffrées, et on bénéficie en
plus d'un serveur de cache.
Conclusion
Cette solution est assez simple à mettre en place. Elle est particulièrement intéressante pour les
clients nomades. Ils peuvent, quelque soit l'endroit où ils se trouvent, mettre en place un VPN
entre le client et un serveur, sans avoir à se soucier de l'état du réseau sur lequel ils se trouvent,
et peuvent utiliser quasiment tous les services réseau sans se préoccuper des règles installées
sur les pare-feux, puisque tous les services sont routés dans le même tunnel.
1. nst
2. tldp.org
3. linux_network
4. linuxsecurity

Chapter 15. Les fichiers hosts
Résolution de noms et adressage statique
Table of Contents
Présentation
Avant de démarrer
Fiche de cours
Travaux Pratiques
Questions
Abstract
Mettre en place et comprendre la résolution de noms d'hôtes.
Présentation
L'atelier présente la résolution de noms d'hôtes sur un petit réseau à l'aide d'un fichier hosts.
Vous utiliserez la commande ping pour diagnostiquer le fonctionnement du réseau.
Il est en 3 parties :
 une présentation de la résolution de nom sur un réseau local,

 un TP,
 un questionnaire.
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.
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.
Note
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
Travaux Pratiques
Vous utiliserez un éditeur joe ou emacs afin de modifier le fichier /etc/hosts. Utilisez l'algorithme
suivant pour créer / modifier votre fichier :
Pour chaque hôte du réseau faire
mettre un enregistrement
Fin pour
Les enregistrements ont la structure suivante : AdresseIP Nom1 [...NomN]
Exemple : 195.115.88.35 foo foo.foo.org becassine
Consultez également la commande man hosts
 Etablissez la nomenclature des machines du réseau. Configurez le fichier host avec la

nomenclature. Testez la résolution de nom avec la commande ping, puis en utilisant les
services telnet et ftp.
 Modifiez la correspondance Nom / Adresse d'une des machines que vous avez dans votre
fichier host et accédez-y avec telnet. Que se passe-t-il ?
 Débranchez la jarretière de votre carte réseau, et réutilisez les commandes ping

localhost, ping 127.0.0.1, ping UneMachineDistante. Que se passe-t-il et que peut-on en
déduire ?
Attention, plus tard nous verrons la résolution de nom par un autre service DNS. Les deux
solutions (DNS et Hosts) ne sont pas exclusives, par contre on peut jouer sur l'ordre qui doit être
appliqué. Cela est traité par le fichier de configuration /etc/host.conf.
$ more /etc/host.conf

order hosts,bind
Il faut bien se souvenir de ça, car dans l'exemple donné ci-dessus, le fichier hosts est prioritaire
sur DNS.
Questions
 Quelle est la commande qui permet d'obtenir le nom d'hôte de la machine locale ?
 Quelles sont les informations que donne la commande ifconfig ?
 Donnez la commande qui permet de n'envoyer qu'un seul ping à une machine distante (voir
man ping)
 Quelle est la taille d'un paquet envoyé par la commande ping ?
 Quelle est la commande qui permet d'envoyer des paquets de 1500 octets ?
 Quelle est la commande ping qui permet d'envoyer des paquets en flot ininterrompu ?
 Quel protocole utilise la commande ping ?
Chapter 16. Installation d'un serveur HTTP
Les services web - Fiche de cours
Table of Contents
Résumé

Questions
Abstract
Configuration d'un serveur Apache 2 et mise en place de services web
Résumé
Installation et configuration d'un serveur HTTP avec Apache 2.
Mots clés “Serveur Web”, “Serveur HTTP”, “Apache 2”
Le document doit vous permettre de mettre en place un serveur Apache supportant :
 des accès anonymes,

 des accès authentifiés par Apache,
 un accès à des pages personnelles,
 des scripts CGI,
 des serveurs web virtuels.
Ce chapitre donne un aperçu des fonctions et de l'environnement du serveur Apache 2. Vous

pourrez retrouver tous les aspects développés dans la documentation (en partie en français) du
produit à l'adresse suivante apache.org.
Apache 2 a très certainement été installé par défaut lors de l'installation de votre Debian. Pour le
vérifier : dpkg -l | grep apache2
ii apache2
ii apache2-common
ii apache2-mpm-prefork
ii apache2-utils
ii libapache2-mod-perl2
ii libapache2-mod-php4 (ou libapache2-mod-php5)
Si Apache2 n'est pas installé, la commande : apt-get install apache2 installera le serveur web
avec ses dépendances.
Vous aurez certainement besoin par la suite du module php alors autant l'installer tout de suite :
apt-get install libapache2-mod-php4 (ou apt-get install libapache2-mod-php5)
Si vous voulez installer la documentation en local : apt-get install apache2-doc

Le serveur HTTP Apache2 est un programme modulaire. Mise à part quelques modules
directement intégrés dans le programme binaire httpd, l'administrateur peut choisir les
fonctionnalités qu'il souhaite en activant des modules.
De même, il existe plusieurs fichiers de configuration tous présents dans /etc/apache2/.
 Le fichier de configuration principal est /etc/apache2/apache2.conf Il contient les

paramètres généraux et communs à tous les serveurs et plusieurs "Include" vers les autres
fichiers.
 Le fichier de configuration /etc/apache2/ports.conf contient la liste des ports en écoute.
 On trouve tous les fichiers concernant les modules dans le répertoire /etc/apache2/mods-
available/.
On y trouve deux catégories de fichiers : *.load et *.conf
Les fichiers avec l'extension load charge effectivement les modules dynamiques :
cat /etc/apache2/mods-available/userdir.load
LoadModule userdir_module /usr/lib/apache2/modules/mod_userdir.so
Les fichiers avec l'extension conf sont les fichiers de configuration des modules :
cat /etc/apache2/mods-available/userdir.conf
<IfModule mod_userdir.c>
UserDir public_html
UserDir disabled root
<Directory /home/*/public_html>
AllowOverride FileInfo AuthConfig Limit
Options MultiViews Indexes SymLinksIfOwnerMatch IncludesNoExec
</Directory>
</IfModule>
On trouve les fichiers concernant les modules activés dans le répertoire

/etc/apache2/mods-enabled/ : ce sont uniquement ces fichiers qui sont inclus dans le
fichier de configuration principal par les directives :
Include /etc/apache2/mods-enabled/*.load
Include /etc/apache2/mods-enabled/*.conf
Et ces fichiers sont en fait des liens qui pointent vers les fichiers de /etc/apache2/mods-
available
Pour activer un module (ce qui revient donc à créer le lien), il est pratique d'utiliser la
commande suivante : a2enmod mod_userdir. Mais on peut bien évidemment créer le lien
"à la main".
 On trouve tous les fichiers de configuration des serveurs web /etc/apache2/sites-

available/

On trouve les fichiers de configuration des sites web activés dans le répertoire
/etc/apache2/sites-enabled/ : ce sont uniquement ces fichiers qui sont inclus dans le
fichier de configuration principal par la directive :
Include /etc/apache2/sites-enabled/[^.#]*
Et ces fichiers sont en fait des liens qui pointent vers les fichiers de /etc/apache2/sites-
available
De même que pour les modules, pour activer un site, il existe une commande : a2ensite
fichier_conf. "fichier_conf" étant un fichier de configuration présent dans
/etc/apache2/sites-available/
La documentation est dans /usr/share/doc.
Les journaux sont dans /var/log/apache2/.
Le script de lancement du service serveur est dans /etc/init.d
Pour que le serveur Web puisse répondre à une demande d'un client, il doit être démarré :
/etc/init.d/apache2 start.
Apache2 ne fonctionne qu'en standalone (la directive ServerType n'est donc plus reconnu).
Ce paragraphe décrit les principaux paramètres pour mettre en place un service HTTP minimum.
Prenez la peine de faire une sauvegarde des fichiers de configuration avant de procéder à toutes
modifications (par exemple : cp -rp /etc/apache2 /etc/apache2.init).
Les modifications ne seront prises en compte que si les fichiers de configurations sont relus
/etc/init.d/apache2 reload ou si le service est redémarré /etc/init.d/apache2 restart.
Vous pouvez vérifier la syntaxe des fichiers de configuration par la commande : apache2 -t
Comment retrouver rapidement le fichier dans lequel se trouve une directive ? :
grep -ni "documentroot" /etc/apache2/*

ne renvoie rien...
grep -ni « documentroot » /etc/apache/*/*
sites-available/default:5: DocumentRoot /var/www
sites-enabled/000-default:5: DocumentRoot /var/www
L'option « ni » permet de chercher sans tenir compte de la casse et de renvoyer aussi le numéro
de la ligne. L'astérisque peut être remplacé par un nom de fichier.
Dans le fichier /etc/apache2/ports.conf
 Listen 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 (Listen 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.

Dans le fichier /etc/apache2/apache2.conf
 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 www-data). Ce compte doit pouvoir lire les fichiers de
configuration et ceux de la racine du serveur HTTP (attention donc aux droits sur les pages
web desservies). D'autres distributions utilisent le compte “nobody” ou “apache”
 ServerRoot /etc/apache2, 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.
 PidFile /var/run/apache2.pid, indique le fichier où le serveur en exécution stocke son

numéro de processus (PID).
 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.
Il est fréquent d'héberger plusieurs serveurs web sur un même poste aussi la déclaration et le
paramétrage des différents serveurs est déportée dans des fichiers à placer dans
/etc/apache2/sites-available/. Le fichier default y est déjà présent pour assurer le paramétrage
du site principal par défaut dont la racine se trouve, toujours par défaut à /var/www/.
Le site par défaut est déjà activé ; on retrouve donc un lien vers ce fichier dans /etc/apache2/sites-
enabled.
Sinon, le principe est le suivant :
 On crée un fichier de configuration (appellé conf_site) pour un site web spécifique dans
/etc/apache2/sites-available/.
 On active ce fichier de configuration par la commande : a2ensite conf_site ; cette
commande a pour effet de créer un lien dans /etc/apache2/sites-enabled/ qui pointe vers
/etc/apache2/sites-available/conf_site.
De plus, il est aussi possible de faire exécuter plusieurs instances d'Apache en spécifiant un
fichier de configuration particulier par une commande du style : apache -f fichier_config où
fichier_config est le nom du fichier de configuration, en chemin absolu (sinon il est considéré
comme situé relativement à la directive ServerRoot, c'est-à-dire /etc/apache2, par défaut).
Les directives qui suivent correspondent à des serveurs spécifiques et sont donc incluses dans les
fichiers de configuration présents dans /etc/apache2/sites-available/ , notamment celui par
défaut /etc/apache2/sites-available/default.
 ServerAdmin webmaster@localhost, précise quel est le compte qui reçoit les messages.
Par défaut un compte spécifique administrateur de site web (à modifier pour une adresse
comme root@MonDomaine.edu).
 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. Ce nom doit correspondre à une adresse IP, donc être renseigné
dans un serveur DNS (ou dans un premier temps mais à éviter en production dans un
fichier hosts sur le cient). S'il n'est pas défini, alors le serveur tentera de le résoudre à partir
de sa propre adresse IP. 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 /var/ww/index.html sauf si le répertoire est pointé par une
directive tel que Alias (voir ci-après).
 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 (défini par la directive
précédente DocumentRoot) 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/
 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.
 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.
On peut activer ou non (activée par défaut) l'option "Indexes" au niveau d'un répertoire (voir
la partie suivante concernant la sécurisation des accès) de manière à ce que si une URL
pointe sur un répertoire, et aucun fichier défini par DirectoryIndex n'existe dans ce dernier,
alors le serveur retourne une liste du contenu du répertoire. Si l'indexation n'est pas activée
(ce qui est plus sécurisé), on obtient une page d'erreur 403 ("You don't have permission to
access /repertoire on this server").
 Chaque répertoire dont le contenu doit être géré par Apache2 peut être configuré
spécifiquement.
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".
 Quelques options :
 <Directory UnRépertoire>
 Options Indexes FollowSymLinks ExecCGI
 ...
 </Directory>

Indexes : autorise l'affichage du contenu d'un répertoire (si un fichier par défaut n'y est pas
trouvé).
FollowSymLinks: le serveur est autorisé à suivre les liens symboliques dans ce répertoire.
ExecCGI : l'exécution de scripts CGI est autorisé.
Pour désactiver les options (par exemple Indexes)
<Directory UnRépertoire>
Options -Indexes FollowSymLinks ExecCGI
...
</Directory>
 Sécuriser un répertoire en autorisant/refusant l'accès
On peut réglementer pour chaque répertoire le droit d'accéder aux pages contenues dans
ce répertoire, en fonction de la machine cliente et/ou de l'utilisateur qui se connecte. Le
fichier dans lequel ce paramétrage s'effectue est un fichier de configuration présent dans
/etc/apache2/sites-available/.
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 16.1. Accés sécurisé sur un répertoire par Apache
La déclaration d'un accès authentifié sur un répertoire peut être faite dans le fichier de
configuration correspondant, comme nous venons de le voir, ou 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. Ainsi, il est possible de délocaliser
la gestion de la configuration, au moyen de fichiers spéciaux appelés par défaut .htaccess. Ce
dernier paramètre est modifiable.
Le ".htaccess" correspondant à l'exemple précédent contient les directives suivantes :
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>
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.
Quelques remarques :
 Les fichiers .htaccess sont lus dynamiquement au moment de chaque requête qui concerne
son répertoire : toute modification de ces fichiers prend donc effet immédiatement sans qu'il
soit nécessaire au service de relire la configuration.
 La directive AllowOverride None, permet de désactiver l'utilisation des fichiers .htaccess
(attention, elle est à "None" par défaut). Pour qu'Apache lise ce fichier il lui faut mettre la
directive : AllowOverride AuthConfig
 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.
Une directive particulière Userdir public_html permet de gérer pour chaque utilisateur (c'est à dire
chaque possesseur d'un compte) des pages personnelles.
Dans apache2, cette directive est en fait associé à un module non activé par défaut. Il suffit donc
d'activer le module correspondant par la commande a2enmod mod_userdir, ce qui aura pour
effet de créer deux liens vers les fichiers correspondants userdir.conf et userdir.load.
Dans userdir.conf, on trouve par défaut les directives suivantes :
 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.
Par défaut :
AllowOverride FileInfo AuthConfig Limit
Options MultiViews Indexes SymLinksIfOwnerMatch IncludesNoExec
</Directory>
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.
 UserDir disabled root, ce paramètre, par mesure de sécurité ne permet pas à l'utilisateur
"root" de mettre en ligne un web personnel.
 La configuration par défaut n'est pas très sécurisée car elle oblige à mettre les droits de
lecture à tout le monde (755) sur le répertoire personnel. Il vous est possible de changer la
variable Userdir par exemple :
UserDir /home/web
Pensez à changer la valeur de Directory.
Utilisez les commandes suivantes pour activer, désactiver le serveur:
/etc/init.d/apache start
/etc/init.d/apache stop
Pour relire le fichier de configuration alors qu'apache est déjà lancé, utilisez :
/etc/init.d/apache reload

Pour activer et desactiver un module, utilisez :
a2enmod nomModule
a2dismod nomModule
nomModule est le nom d'un module présent dans /etc/apaches2/mods-available
Pour activer et desactiver un site WEB, utilisez
a2ensite nomSite
a2dissite nomSite
nomSite est le nom d'un fichier de configuration du site présent dans /etc/apaches2/sites-
available
Pensez dans tous les cas à consulter les journaux afin de détecter les dysfonctionnements.
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.
Questions
 Quel protocole et quel port par défaut utilise le serveur Apache2 ?

 Comment se nomme le principal fichier de configuration d'Apache2, et où se trouve-t-il ?
 Dans quel répertoire sont situées les pages du serveur ?
 Vous modifiez le port d'utilisation du serveur et vous faites un essai à partir d'un client.
L'accès ne fonctionne pas. Donnez au moins deux raisons possibles et les moyens de
remédier à ce problème.
 Quel est le paramètre qui permet l'utilisation de répertoires personnels pour les utilisateurs
afin de déployer leurs sites WEB personnels ?
 Vous activez le paramètre du répertoire personnel dans Apache2 et relancez le serveur.

Vous essayez l'accès sur votre compte or il est refusé. Que se passe-t-il et comment
corriger le problème ?
 Dans quels répertoires se trouvent les fichiers log d'Apache et comment se nomment ces
fichiers ?

Chapter 17. TP 1 : installation d'un serveur HTTP
Table of Contents
Résumé
Introduction
Résumé
Installation d'un serveur WEB - TP(s)
La séquence est bâtie pour des travaux réalisés avec plusieurs machines. Certaines parties
pourront être réalisées sur votre propre machine, celle-ci servant de client et de serveur.
Vous devez avoir un navigateur d'installé, par exemple mozilla, firefox, konqueror, galeon...
La résolution de noms doit fonctionner.
Attention : Les paramètres peuvent différer d'une version à l'autre de Linux ou d'une distribution à
l'autre. J'utilise dans ce document des variables, vous devrez y substituer les valeurs réelles de
votre environnement.
 $APACHE_HOME, répertoire dans lequel sont stockées les pages du serveur.

 $APACHE_CONF, répertoire dans lequel sont stockés les fichiers de configuration.
 $APACHE_USER, compte utilisateur sous lequel fonctionne Apache.
 $APACHE_GROUP, groupe auquel est rattaché le compte $APACHE_USER.
 D'autres variables peuvent être définies au besoin dans l'ensemble des TP.
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.
Vous allez réaliser une configuration de base du serveur. Vous allez donc modifier les fichiers de
configuration qui vous ont été présentés dans la fiche de cours. 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 de la fiche de cours et des commentaires (pensez
à enregistrer vos modifications) :
 ServerName, nom pleinement qualifié de votre serveur (FQDN)

 Listen 80
 User $APACHE_USER
 Group $APACHE_GROUP
 ServerAdmin webmaster@localhost
 ServerRoot /etc/apache2
 DocumentRoot $APACHE_HOME
 UserDir public_html
 DirectoryIndex index.html index.shtml index.cgi
 AccessFileName .htaccess
 Alias /icons/ $APACHE_ICONS/icons/
 ScriptAlias /cgi-bin/ $APACHE_CGI/cgi-bin/
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.
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.
 Quels sont les fichiers de base pour la configuration du serveur apache2 et dans quels
répertoires sont-ils situés ?
 Comment active-t-on un site ?
 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 ?
 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 ?
Chapter 18. TP 2 : création de pages Web
Table of Contents
Résumé
Test de vos pages

Résumé
Vous allez réaliser les opérations suivantes
 Vérifier que la configuration de votre machine est correcte,

 Développer quelques pages HTML puis les déployer,
 Tester les nouvelles pages à partir d'un client Linux et Windows.
Vous utiliserez les archives qui vous sont fournies. Ces archives sont composées des quelques
pages html qui vous serviront de site web et de scripts cgi.
Installez le service serveur et vérifiez qu'il est bien configuré et actif.
Pour tester la configuration de votre serveur, vous pouvez également utiliser la procédure suivante
à partir de l'hôte local ou d'un hôte distant.
Lancez la commande suivante "$ telnet @IP du PC 80" (exemple : telnet 192.168.1.1 80 si cette
adresse est celle de votre machine)
Cette commande crée une connexion au serveur httpd (port 80). Ce dernier invoque un agent.
Identifiez la connexion réseau dans une autre fenêtre xterm et avec la commande :
netstat -atup | grep ESTABLISHED

root@mr:/home# netstat -atup | grep ESTABLISHED
#Vous devriez obtenir quelque chose comme :
tcp 0 0 mr:33073 mr:www ESTABLISHED 1513/telnet
Ensuite, transmettez à l'agent la ligne (commande) suivante : "GET /index.html"
Vérifiez que l'agent transmet de manière transparente le document HTML, et qu'il coupe
automatiquement la connexion.
Vous allez utiliser les documents HTML fournis en annexe. Vous allez procéder de la façon
suivante:
 Créez un répertoire $APACHE_HOME/journal pour y mettre toutes les pages html

 Copiez les images dans $APACHE_ICONS/icons (normalement /usr/share/apache2/icons)
 Copiez le script cgi compilé "prog" dans $APACHE_CGI/cgi-bin (normalement /usr/lib/cgi-

bin)

Testez le site à partir d'un navigateur avec la commande http://@URLDuServeur/journal/
Le site est maintenant déployé, testez l'enchaînement des pages, l'affichage des images.
Le formulaire ne fonctionne pas encore. Vous avez copié le script compilé "prog" dans "/usr/lib/cgi-
bin". Vérifiez quel est le nom du script que le formulaire "form.html" essaie de lancer sur le
serveur.
Modifiez le nom du script ou le formulaire en conséquence.
Testez le fonctionnement du formulaire dans un navigateur.
Si vous rencontrez des difficultés sur l'exécution du script, vérifiez dans le fichier adéquat de
configuration d'apache que vous avez bien :
ScriptAlias /cgi-bin/ "/usr/lib/cgi-bin/"

et
<Directory "/usr/lib/cgi-bin">
AllowOverride None
Options None
Order allow,deny
Allow from all
</Directory>
Réalisez sous LINUX votre curriculum vitae en langage HTML. Celui-ci devra être composé de
plusieurs documents reliés par des liens (ancres). Il sera installé dans $APACHE_HOME/cv et les
images dans le répertoire référencé par l'alias /icons/.
 - 1 page d'accueil de présentation avec les liens sur les autres pages,
 - 1 page pour la formation initiale,
 - 1 page pour les expériences professionnelles,
 - 1 page pour les loisirs, passions...
Chaque page doit vous permettre de revenir à la page d'accueil.
Mettez les pages dans le répertoire qui était prévu $APACHE_HOME/cv
Test de vos pages
Vous allez vous connecter à votre site à partir d'un client distant. Utilisez de préférence les
adresses URL. Corrigez les erreurs si l'accès n'est pas réalisé.

Afin de comprendre le fonctionnement des alias vous allez maintenant réaliser quelques
manipulations. Vous allez déplacer le répertoire qui contient les images de
"$APACHE_HOME/icons" vers "/tmp/httpd/icons.
 Réalisez l'opération de déplacement du répertoire vers /tmp/httpd/icons,

 Apportez les modifications nécessaires aux fichiers de configuration d'Apache
 Vérifiez le résultat.
Vous constatez ainsi qu'il est possible de déplacer un répertoire sur un serveur, sans qu'il soit
nécessaire pour autant de modifier toutes les pages utilisant ce répertoire.
 Quel est le nom de la page par défaut qui est ouverte par le navigateur dans un répertoire
du serveur HTTP.
 Quel intérêt procure l'utilisation des alias ?
 Dans quels répertoires sont, par défaut, installés les pages HTML, scripts CGI, images et
comment se nomment les alias ?
 On crée un répertoire $APACHE_HOME/html/journal pour y stocker des pages HTML. Il

n'est pas possible d'y accéder alors que pour les autres sites tout fonctionne. Voici le
message renvoyé par le navigateur. Aucune mesure de sécurité n'a été mise en oeuvre.
 Forbidden
 you don't have permission to access / on this server
Quelle est la cause du problème et comment y remédier ?
Chapter 19. TP 3 : configuration des répertoires personnels
Table of Contents

Vous allez mettre en place un accès pour les utilisateurs du système. Ceux-ci auront la possibilité
de mettre leurs pages personnelles dans leur répertoire privé.

 Configurer le compte personnel,
 Développer un site personnel,
 Tester l'accès au site personnel.
Relevez dans le fichier de configuration d'Apache2 adéquat le nom du répertoire dans lequel
doivent être stockées les pages personnelles.
 Créez un compte d'utilisateur. Je vais utiliser, pour la description des opérations le compte
"mlx",
 Allez dans le répertoire personnel /home/mlx,
 Créez le répertoire du site Web personnel ,
 Dans ce répertoire vous allez créer un répertoire pour les pages, un pour les images, un
pour les scripts CGI avec la commande mkdir.
Vous allez utiliser les pages HTML fournies en annexes. Utilisez les documents du TP précédent si vous en
avez besoin.
Installez les fichiers fournis en annexe dans les répertoires adéquats.
Modifiez les pages HTML à l'aide d'un éditeur pour qu'elles utilisent les images de votre répertoire
personnel "~/public_html/images" et le script CGI de votre répertoire personnel "~/public-html/cgi-bin" et
pas ceux qui sont dans "$APACHE_HOME/cgi-bin".
Pour autoriser l'utilisation de scripts CGI dans un répertoire, vous devez le déclarer. Voici trois exemples :
<Directory /home/*/public_html/cgi-bin>
Options ExecCGI
SetHandler cgi-script
</Directory>
Options +ExecCGI
</Directory>
<Directory /var/www/journal>
Options +ExecCGI
</Directory>
Recherchez également la ligne suivante dans le fichier apache2.conf :
AddHandler cgi-script .cgi .sh .pl
Décommentez là ou ajoutez la si elle n'y est pas.
Copiez le script dans le répertoire que vous réservez pour les scripts. Vérifiez si c'est un programme "C"
compilé qu'il porte bien l'extension ".cgi", au besoin renommez-le.

Vous pouvez maintenant tester votre site personnel. A l'aide d'un navigateur utilisez l'URL
"http//localhost/~mlx", (remarquez l'utilisation du "~" pour définir le répertoire personnel.)
Corrigez toutes les erreurs que vous pouvez rencontrer (problèmes d'alias, page principale, page
de liens, problèmes de scripts, permissions d'accès au répertoire...)
Faites le test avec les sites personnels situés sur les autres machines.
 Quel avantage présente l'utilisation des répertoires personnels pour le développement de

sites Web ?
 Vous installez votre site personnel et vos pages. Vous tentez de réaliser un test or vous
n'arrivez pas à accéder à vos pages. Quels peuvent être les problèmes et comment y
remédier ?
 Vous rencontrez un problème de configuration. Vous apportez les corrections dans les
fichiers de configuration, or la modification n'est toujours pas prise en compte sur le client.
Que se passe-t-il et comment corriger le problème ?
 Comment avez vous fait pour que les scripts personnels soient chargés et exécutés de
/home/mlx/public_html/cgi-bin
 Pour l'utilisateur mlx, sur la machine saturne et le domaine toutbet.edu, donnez:
1. l'adresse URL de son site personnel,
2. l'emplacement physique de son répertoire personnel sur la machine,
3. le nom (et chemin complet) du fichier qui est activé quand on accède à son site.
Chapter 20. TP 4 : mise en place d'un accès sécurisé
Table of Contents


 1 - Déployer un site d'accès en ligne

 2 - Sécuriser l'accès à ce site par un mot de passe
 3 - Tester la configuration.
Vous allez utiliser les pages fournies en annexe.
Créez un répertoire sur votre machine. "mkdir $APACHE_HOME/protege"
Copiez les pages dans ce répertoire.
Dans un premier temps vous allez interdire l'accès à tout le monde. Pour cela vous allez modifier
le fichier de configuration d'Apache2 adéquat et y mettre les lignes suivantes :
<Directory $APACHE_HOME/protege>
order deny,allow
deny from all
</Directory>
Arrêtez puis relancez le serveur et faites un test à partir d'un navigateur. Notez le message qui
apparaît. Plus personne n'a accès au site.
Pour mettre un accès sécurisé par mot de passe il manque 2 éléments:
 Modifiez la configuration d'accès au répertoire,
 Créez le mot de passe crypté.
Modifiez la configuration d'accès au répertoire
<Directory $APACHE_HOME/protege>
AuthName Protected
AuthType basic
AuthUserFile $APACHE_CONF/users # fichier de mots de passe
<Limit GET POST>
require valid-user # ici on demande une authentification
</Limit>
</Directory>
Créez le mot de passe crypté.
Le mot de passe est un fichier texte à deux champs séparés par un "deux points" (:). Le premier
champ contient le compte d'utilisateur, le deuxième contient le mot de passe crypté.
Pour créer ce fichier, les comptes et les mots de passe, utilisez la commande "htpasswd".

Ouvrez une session à l'aide d'un navigateur et ouvrez l'URL "http://localhost/protege"
Une fenêtre d'authentification doit s'ouvrir, entrez le nom d'utilisateur et le mot de passe.
Réalisez les opérations à partir de machines distantes.
Dépannage:
 Vérifiez le nom du répertoire que vous avez créé et la déclaration dans le fichierde
configuration,
 Vérifiez le nom et la structure du fichier dans lequel vous avez mis les mots de passe.
 Si vous faites plusieurs tests, quittez puis relancez le navigateur après chaque session
ouverte ou refusée,
 Vérifiez que le répertoire soit bien en mode 755 (chmod)
 Si cela ne fonctionne toujours pas reprenez le processus au début:
- affectez toutes les permissions à tout le monde,
- supprimez toutes les permissions à tout le monde,
- affectez les restrictions.
 Utilisez un compte sans mot de passe. Le fichier $APACHE_CONF/users va contenir

uniquement la chaîne: mlx, mais il n'y a pas le mot de passe.
Si cela fonctionne alors le problème vient du cryptage du mot de passe.
Une fois que vous avez été authentifié, quittez et relancez le navigateur si vous voulez refaire le
test d'accès à la ressource protégée.
En vous basant sur ce que vous venez de faire, sécurisez l'accès à un autre répertoire en utilisant
un fichier .htaccess.
 Dans quel cas un accès sécurisé peut-il être utilisé ?

 Vous affectez un mot de passe à un utilisateur distant. Vous faites un test sur votre
machine tout semble fonctionner. Il vous appelle pour vous dire que ses requêtes sur le site
protégé sont toujours rejetées. Que se passe-t-il ?
 Si on utilise les possibilités du système, quelle autre solution peut-on utiliser pour interdire
l'accès à un répertoire.
Chapter 21. TP 5 : Utilisation de scripts CGI
Table of Contents

Il existe deux méthodes qui permettent de faire communiquer un formulaire html avec un script
CGI. La méthode POST et la méthode GET. Nous utiliserons ici la méthode POST.
Ce TP doit vous permettre de développer un formulaire et un script CGI en C. Vous devez savoir
compiler un programme.
 Etudier les sources fournies en annexe.

 Développer un formulaire et adaptez les scripts,
 Tester le fonctionnement des scripts.
Transférez les programmes C, les .h et le makefile dans votre répertoire personnel. Etudiez
attentivement les sources. Testez le fonctionnement du script.
A partir de l'exemple fourni, développez les pages HTML d'un site commercial qui doit permettre la
prise de commande à distance de pizzas. Il doit y avoir au moins 3 pages:
 une page principale,

 une page de description des produits,
 une page (formulaire) pour passer commande contenant tous les types de champs qui
existent dans le formulaire form.html. (liste déroulante, bouton radio, zone de texte)

Exemple :
 Zone de texte (Nom du client)

 Liste déroulante (Calzone, Margarita, Quatre-saisons)
 Bouton radio (Grande, Moyenne, Petite)
 Case à cocher (Avec des anchois)
 Vous afficherez au client le résultat de sa commande.
Adaptez le script CGI qui vous est fourni, à votre formulaire.
Pour tester le script:
 ouvrez la page principale de votre site à l'aide d'un navigateur,

 passez des commandes,
 vérifiez les résultats retournés par le script. (réponse).
 Que signifie CGI ?

 Quel intérêt présente l'utilisation de scripts CGI ?
 Quelle est la différence entre la méthode GET et POST ?
 Comment se nomment les variables d'environnement qui contiennent la chaîne

(paramètres) du formulaire ?
 Comment est structurée cette chaîne ?
 Quel est le caractère de concaténation des chaînes ?
 Pourquoi la réponse contient dans l'entête la chaîne Content-type: text/html ?
 A quoi correspondent ces 2 paramètres text et html ?
Chapter 22. TP 6 : Serveurs webs virtuels et redirection
Table of Contents

Il est préférable d'avoir réalisé les TP sur les serveurs de noms avant de réaliser celui-ci.
Pour réaliser ce TP, vous devrez avoir un serveur de noms qui fonctionne.
La mise en place de serveurs webs virtuels, permet de faire cohabiter plusieurs serveurs sur un
même hôte. Nous verrons qu'il y a plusieurs techniques pour faire cela.
On ajoutera, dans un premier temps le paramétrage des sites virtuels dans le fichier de
configuration spécifique situé dans /etc/apache2/sites-available/default mais il est tout à fait
possible de créer dans ce même répertoire un fichier pour chaque serveur virtuel.
 Les serveurs virtuels basés sur le nom, dans ce cas, vous devrez désigner pour une
adresse IP sur la machine (et si possible le port), quel est le nom utilisé (directive
ServerName), et quelle est la racine du site (directive DocumentRoot).
Le nom de serveur (ServerName) et la racine web (DocumentRoot) doivent exactement

correspondre respectivement au nom sous lequel le serveur virtuel sera nommé dans les
URL clientes et au chemin du répertoire d'accueil des documents du site.
# Ici toutes les adresses ip sont utilisées, on peut mettre *
NameVirtualHost *
# Toutes les requêtes sur http://www.domain.tld/

# pointeront sur /www/domain
<VirtualHost *>
ServerName www.domain.tld
DocumentRoot /www/domain
</VirtualHost>
# Toutes les requêtes sur http://www.otherdomain.tld/

# pointeront sur /www/otherdomain
<VirtualHost *>
ServerName www.otherdomain.tld
DocumentRoot /www/otherdomain
</VirtualHost>
# Ici on utilise une adresse en particulier

# Toutes les requêtes sur http://www.domain.tld/domain
# pointeront sur /web/domain
NameVirtualHost 111.22.33.44
<VirtualHost 111.22.33.44>
ServerName www.domain.tld
ServerPath /domain
DocumentRoot /web/domain
</VirtualHost>

 Dès lors que l'on a des serveurs virtuels qui "tournent" sur des ports différents, il est
obligatoire de préciser pour chaque serveur virtuel son port :
 NameVirtualHost * devient NameVirtualHost *:80
<VirtualHost *> devient <VirtualHost *:80>
Nous le verrons avec le TP sur SSL.
 Les serveurs virtuels basés sur des adresses IP. Dans ce cas, chaque serveur aura sa
propre adresse IP. Vous devrez également avoir un serveur de noms sur lequel toutes les
zones et serveurs sont déclarés, car c'est ce dernier qui assurera la correspondance
"adresse ip <-> nom du serveur" :
 # Chaque serveur peut avoir son propre administrateur, ses
 # propres fichiers de logs.
 # Tous fonctionnent avec la même instance d'Apache.
 # Il est possible de lancer plusieurs instances d'apache
 # mais sur des ports différents

 <VirtualHost www.smallco.com>
 ServerAdmin webmaster@mail.smallco.com
 DocumentRoot /groups/smallco/www
 ServerName www.smallco.com
 ErrorLog /groups/smallco/logs/error_log
 TransferLog /groups/smallco/logs/access_log
 </VirtualHost>

 <VirtualHost www.baygroup.org>
 ServerAdmin webmaster@mail.baygroup.org
 DocumentRoot /groups/baygroup/www
 ServerName www.baygroup.org
 ErrorLog /groups/baygroup/logs/error_log
 TransferLog /groups/baygroup/logs/access_log
 </VirtualHost>

La redirection est un service un peu particulier, qui diffère de celui des services web virtuels. Il
permet de rediriger une partie du site web à un autre endroit du disque physique. La encore on
utilisera une des fonctions d'Apache qui permet de définir des alias.
Prenons par exemple un site installé physiquement sur "/var/www" et accessible par l'url
"http://FQDN". L'url "http://FQDN/unREP" devrait correspondre normalement à l'emplacement
physique "/var/www/unREP". La redirection va permettre de rediriger physiquement vers un autre
répertoire.
Cette technique est largement utilisée par des applications ou pour la création d'espaces
documentaires.
L'URL "http://FQDN/compta", pourra pointer physiquement dans "/usr/lib/compta" au lieu de

"/var/www/compta".
Dans cet atelier, vous allez réaliser les opérations suivantes:
1. Installer un service de serveurs web virtuels par adresse et par nom,
2. Mettre en place un service de redirection par alias.

Configurez votre serveur de noms si ce n'est pas fait. Vous pouvez vous aider de l'annexe sur le
"web-hosting" ci-dessous.
Pour créer des alias dynamiquement à votre interface réseau, utilisez la commande suivante:
ifconfig eth0:0 192.168.0.1

ifconfig eth0:1 192.168.1.1
ifconfig
eth0 Lien encap:Ethernet HWaddr 00:D0:59:82:2B:86
Interruption:11 Adresse de base:0x3000
eth0:0 Lien encap:Ethernet HWaddr 00:D0:59:82:2B:86

eth0:1 Lien encap:Ethernet HWaddr 00:D0:59:82:2B:86

lo Lien encap:Boucle locale

inet adr:127.0.0.1 Masque:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
Créez votre serveur de noms pour deux domaines par exemple (domain1.org et domain2.org),
adaptez la configuration du fichier "/etc/resolv.conf", vérifiez le bon fonctionnement de la résolution
de noms sur les CNAME (www.domain1.org et www.domain2.org).
D'abord les déclarations dans le fichier de configuration :
# Web hosting ip based

DocumentRoot /home/web/domain1
ServerName www.domain1.org
</VirtualHost>
DocumentRoot /home/web/domain2

ServerName www.domain2.org
</VirtualHost>
Préparation des sites webs (sans trop se casser la tête) :
# mkdir -p /home/web/domain1 /home/web/domain2

# echo "<H1>Salut domain1 </H1>" > /home/web/domain1/index.html
# echo "<H1>Salut domain2 </H1>" > /home/web/domain2/index.html
On relance Apache :
/etc/init.d/apache2 restart
C'est terminé, les requêtes sur "http://ww.domain1.org", "http://www.domain2.org", doivent fonctionner et

vous renvoyer la bonne page.
On va utiliser l'adresse ip de ns1.domain1.org pour les url w3.domain1.org et wiki.domain1.org.

w3 et wiki sont deux zones de déploiement de site web différentes, sur un même serveur HTTP.
Modification du fichier de configuration :
# Web hosting name based (basé sur le nom)

#Site secondaire de domain1
ServerName w3.domain1.org
DocumentRoot /home/web/w3
</VirtualHost>
ServerName wiki.domain1.org
DocumentRoot /home/web/wiki
</VirtualHost>
Relisez la configuration d'Apache2.
Création des sites web :
# mkdir -p /home/web/wiki /home/web/w3

# echo "<H1>Salut w3 </H1>" > /home/web/w3/index.html
# echo "<H1>Salut wiki </H1>" > /home/web/wiki/index.html
Mettez les droits nécessaires.
C'est terminé, les requêtes sur :
http://w3.domain1.org
http://wiki.domain1.org
doivent retourner les bonnes pages.

Nous allons créer un espace documentaire pour le domain "domain1.org". Il sera accessible par
l'url "http://www.domain1.org/mesdocs", mais il sera localisé dans "/etc/domain1doc".
Créez un répertoire "domain1doc" dans /etc pour ce nouveau projet et mettez-y le fichier
"apache.conf" ci-dessous:
# Création du répertoire
mkdir /etc/domain1doc
# Création du fichier /etc/domain1doc/apache.conf

Alias /mesdocs /etc/domain1doc/
<Directory /etc/domain1doc>
Options FollowSymLinks
AllowOverride None
order allow,deny
allow from all
</Directory>
Faites une inclusion de ce fichier dans le fichier de configuration d'Apache et relancez le service
Apache.
C'est terminé, toutes les requêtes sur "http://www.domain1.org/mesdocs", ouvriront les pages qui
sont dans "/etc/domain1doc".
=== A rajouter dans /etc/bind/named.conf
zone "domain1.org" {
type master;
file "/etc/bind/domain1.org.hosts";
};
zone "domain2.org" {
type master;
file "/etc/bind/domain2.org.hosts";
};
=== fichiers de zone

root@freeduc-sup:/etc/bind# more domain1.org.hosts
$ttl 38400
@ IN SOA domain1.org. hostmaster.domain1.org. (
2004052604
10800
3600
604800
38400 )
@ IN NS ns1.domain1.org.
ns1 IN A 192.168.0.1
www IN CNAME ns1

wiki IN CNAME ns1
w3 IN CNAME ns1
root@freeduc-sup:/etc/bind# more domain2.org.hosts

$ttl 38400
@ IN SOA domain2.org. hostmaster.domain2.org. (
2004052604
10800
3600
604800
38400 )
@ IN NS ns1.domain2.org.
ns1 IN A 192.168.1.1
www IN CNAME ns1
Le chiffrement
Apollonie Raffalli
<apo.raffalli@wanadoo.fr>
Revision History
Table of Contents

Mise en oeuvre
Les certificats
Le protocole SSL
Abstract
Ce cours se propose de définir les concepts de base du chiffrement et surtout ses objectifs :

 Définition du chiffrement ;
 Les deux méthodes de chiffrement (chiffrement symétrique et chiffrement asymétrique) ;
 Les objectifs du chiffrement (confidentialité, authentification, intégrité, signature

électronique) ;
 La notion de certificat ;
 La mise en oeuvre avec le protocole SSL.
Le chiffrement consiste à rendre illisible un message en brouillant ses éléments de telle sorte
qu'il soit très difficile de reconstituer l'original si l'on ne connaît pas la transformation appliquée.
Le chiffrement est basé sur deux éléments : une clé et un algorithme .
 La clé est une chaîne de nombres binaires (0 et 1).

 L'algorithme est une fonction mathématique souvent complexe qui va combiner la clé et le
texte à crypter pour rendre ce texte illisible.
Pour "casser" un chiffrement, il n'existe que deux solutions :
 Il faut essayer toutes les clés, ce qui devient impossible actuellement compte tenu de la
longueur de celles-ci ;
 "Casser" l'algorithme (qui est, en général, connu par tous), c'est-à-dire rechercher une faille
dans la fonction mathématique ou dans son implémentation permettant de trouver la clé
plus rapidement.
Le choix d'un algorithme dépend donc de :
 La fiabilité de ce dernier (savoir s'il existe des failles importantes) ;

 La longueur de clé qu'il gère ;
 De ce que l'on va en faire : on sera plus vigilant pour un serveur RADIUS permettant
l'accès au réseau WIFI de la NASA que pour notre messagerie personnelle...
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.

Figure 23.1. 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 !
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.
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é :
Figure 23.2. Confidentialité

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 :
Figure 23.3. 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.
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.

Figure 23.4. 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.
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.vie-privee/
 http://www.gnupg.org/gph/fr/manual.html
 Il vous suffit ensuite de chercher dans un moteur de recherche une documentation

permettant de gérer pgp ou gpg à partir de votre logiciel de courrier électronique (kmail,
thundebird, etc...).
Vous avez tous l'adresse électronique de votre professeur qui a déposé sa clé publique relative à
cette adresse sur un serveur de clés (par exemple http://www.keyserver.net/) ou qui vous a fourni
sa clé publique par un autre moyen.
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 rôle des certificats.
Les certificats
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.
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 100 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.
Figure 23.5. Certificat
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).
Le 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.
Figure 23.6. Le protocole SSL
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 :
Figure 23.7. HTTP over SSL

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.
Trois 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.
Chapter 24. TP sur le serveur WEB sécurisé
Apollonie Raffalli
<apo.raffalli@wanadoo.fr>
Revision History

Table of Contents
Présentation du TP
Abstract
L'objectif de ce TP est de développer une sécurité concernant l'authentification d'un serveur HTTP
(le navigateur doit être certain de se connecter au "bon" serveur et les données qui transitent
doivent être cryptées).
Préalable :
 apache2 est installé et le service démarre sans problème ;

 vous avez lu le cours sur les notions de base du chiffrement ;
 vous avez fait les 6 TP sur le serveur HTTP et notamment le dernier concernant les
serveurs virtuels.
Présentation du TP
L'accès à un serveur web utilise le protocole http via le réseau Internet. Il est tout à fait possible à
un pirate d'intercepter vos requêtes (votre code de carte bleue) et les réponses faites par le
serveur car les informations circulent "en clair" sur le réseau.
De plus, il n'est pas certain que vous soyez en cours de consultation du site que vous croyez
(aucun mécanisme d'authentification des parties n'est mis en oeuvre au niveau du protocole
HTTP).
Le protocole HTTPS (HTTP over SSL) permet de remédier à ces deux inconvénients :
 les échanges sont cryptés (la requête resterait illisible pour le pirate) ;
 l'authentification SSL du serveur est mis en oeuvre : on est assuré que le serveur auquel
on accède est bien celui que l'on croit.
HTTPS offre d'autres possibilités qui ne sont pas abordées ici (par exemple, authentifier la
personne qui accède au serveur).

Au cours de ce TP, vous allez mettre en place le protocole SSL sur votre serveur WEB.
Dans le TP6, vous avez configuré un serveur virtuel auquel l'on accède avec l'url
"http://wiki.domain1.org" ; c'est ce serveur que l'on va sécuriser.
Nous supposons que vous êtes sur une distribution debian. Sinon, il faudra peut-être légèrement
adapter ce qui suit notamment en ce qui concerne les noms de paquets à installer et
l'emplacement des fichiers de configuration.
Les paquetages suivants supplémentaires doivent être installés (les numéros de version peuvent
être différents):
 openssl ;
 libssl0.9.8 ;
 Et en option ssl-cert ;
OpenSSL fournit notamment une application pour créer des certificats.
Le paquetage ssl-cert fournit une interface debconf à openssl pour créer les certificats mais nous
ne nous en servirons pas dans ce TP.
Remarque : dans l'ancienne version d'apache2-common , il existait une commande ( apache2-

ssl-certificate) permettant de créer des certificats pour Apache très rapidement et
automatiquement ; cette commande n'existe plus dans la nouvelle version apache2.2-common.
Il sera ensuite nécessaire d'activer le module ssl d'apache2 (voir étape 2) qui implémente https.
Le serveur https écoute par défaut sur le port 443 au lieu de 80 et correspond à un virtual host
configuré par des directives spécifiques.
Connectez-vous sous root et allez dans le répertoire de configuration de votre serveur Apache2
/etc/apache2 (on peut évidemment choisir un autre répertoire) et créez un répertoire appelé ssl.
Vous vous placerez dans ce répertoire afin que les clés et les certificats soient créés à l'intérieur
avant d'effectuer les manipulations.
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ée 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 le certificat.
Ce dernier choix a notre préférence...
Pour signer un certificat, vous devez devenir votre propre autorité de certification, cela implique
donc de réaliser une clé et un certificat auto-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.
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
L'option CAcreateserial n'est nécessaire que la première fois.
Il faut saisir la passphrase...
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 ce dernier qui va valider le certificat reçu par le client lors de la requête https://.
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, clé usb, ftp,
ssh, répertoire partagé...)
 Sous Windows, un clic droit ou double-clic 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 ensuite que le certificat s'y trouve bien sous le nom
de "cert_CA".
 sur Mozilla :
o Edition/préférence/Confidentialité et Sécurité/Certificats

o Bouton de commande : gestion des certificats
o Onglet : autorité
o Bouton de commande : importer
o etc...
Il ne reste plus maintenant qu'à configurer apache2.
Il est nécessaire dans un premier temps d'activer le module ssl :
a2enmod ssl
Module ssl installed; run /etc/init.d/apache2 force-reload to enable
Comme on vous le demande, relisez la configuration du serveur.
La commande ls /etc/apache2/mods-enabled/ donne partiellement ceci :
ssl.conf
ssl.load
Ajoutez au fichier /etc/apache2/ports.conf la ligne suivante :
Listen 443
Nous allons faire fonctionner sur notre serveur simultanément des virtualhost fonctionnant sous
HTTP (sur le port 80) et des virtualhost fonctionnant sous HTTPS (sur le port 443). Dès lors que
l'on a des serveurs virtuels qui "tournent" sur des ports différents, il est obligatoire de préciser pour
chaque serveur virtuel son port . Aussi, dans le fichier /etc/apache2/site-available/default , il
faut modifier :
NameVirtualHost * devient NameVirtualHost *:80

<VirtualHost *> devient <VirtualHost *:80> pour chaque virtualhost
<VirtualHost adr_IP> devient <VirtualHost adr_IP:80> pour chaque virtualhost
Profitez-en pour effacer le virtualhost correspondant au ServerName : wiki.domain1.org puisque

c'est celui que l'on va configurer en HTTPS.
Il est possible de rajouter la configuration du virtualhost devant fonctionner sous ssl dans le fichier
/etc/apache2/site-available/default, mais nous allons garder l'esprit modulaire et créer un
fichier de conf spécifique /etc/apache2/site-available/default-ssl.

Voici ce que vous devez trouvez au minimum dans le fichier
/etc/apache2/site-available/default-ssl (les commentaires et/ou explications éventuelles
précèdent les directives)
#La déclaration du virtualhost.

#Attention : mettre bien une "*" et NON une adresse IP car
#on ne peut trouver qu'une seule fois la directive
#NameVirtualHost adresseIP :Port et nous l'avons déjà dans
#le fichier "default".
NameVirtualHost *:443
#Du coup : mettre aussi ici une "*" car sinon vous allez
#avoir le warning suivant très horripilant :
#NameVirtualHost *:443 has no VirtualHosts
<VirtualHost *:443>
ServerName wiki.domain1.org
DocumentRoot /home/web/wiki
#Les directives pour les certificats
SSLEngine On
SSLCertificateFile /etc/apache2/ssl/servwiki.crt
SSLCertificateKeyFile /etc/apache2/ssl/servwiki.key
#Les directives qui suivent ne sont pas obligatoires mais

#aident au débugage
#On isole les erreurs relatives à http
#Attention : il faut créer le fichier "error_ssl.log"
ErrorLog /var/log/apache2/error_ssl.log
LogLevel warn
</VirtualHost>
Il est nécessaire maintenant d'activer le site : a2ensite default-ssl
Attention : ne pas oublier de relire ensuite la configuration de même qu'à chaque modification
ultérieure du fichier.
Vous pouvez maintenant "passer" à la phase de test...
A partir d'un navigateur sur votre poste client :
https://wiki.domain1.org
Votre page devrait s'afficher normalement.
Si vous avez une alerte de sécurité, c'est que vous avez mal réalisé une étape. Selon l'alerte,
reprenez l'étape correspondante.
Si ça ne fonctionne pas vous pouvez même mettre le LogLevel à "debug" ou "info" à la place de
"warn" puis dans une console : "tail -f /var/log/apache2/error_ssl.log" pour voir quels sont les
problèmes qui surviennent quand vous rechargez la lecture de la configuration.
Une autre commande peut vous aiguiller sur une éventuelle erreur : openssl s_client -connect
prof.btsinfo.fr:443

Vous pouvez maintenant revoir, dans la partie cours, le schéma concernant le protocole SSL et
l'application HTTP (fig 1.7).
Chapter 25. Le service SAMBA

Revision History
Revision 0.2 26 Decembre2006
Table of Contents
Introduction
Abstract
Partage de ressources sous GNU/Linux pour les clients GNU/Linux ou Windows avec le protocole
SMB.
Introduction
Avec SAMBA vous allez mettre en place un service de partage de disque pour des clients réseau.
Ceux-ci peuvent être sous Linux ou sous Windows. Nous verrons surtout la configuration du
service serveur sous Linux, et la configuration des clients sous Windows.
Samba est un produit assez populaire. Il existe de plus en plus d'outils de configuration en
environnement graphique qui simplifient les tâches sur un serveur en exploitation (partage de
ressources, création de comptes utilisateurs). Comme nous n'en sommes pas là, nous allons
réaliser les opérations manuellement.
Vous devez savoir ce qu'est un domaine Microsoft, un groupe de travail, comment fonctionne la
résolution de nom NetBIOS avec le protocole NetBIOS, ce qu'est un serveur WINS, un serveur
d'authentification (contrôleur de domaine).

SAMBA est installé avec le paquet fds-network sur Kubuntu Dapper. Si vous n'utilisez pas le
paquet fds-network, installez les paquets manuellement. 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_HOTE par le nom d'hôte de votre machine
qui servira également de nom NetBIOS.
Voici le fichier de configuration qui nous servira de base de travail. Il va permettre de :
 définir NomDuServeur comme serveur Samba,

 mettre en place l'authentification des utilisateurs,
 partager des disques et une imprimante pour un client Windows,
 partager le 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.

Nous allons réaliser les opérations suivantes :
 Vérifier et valider le fichier de configuration,

 Déclarer les ressources partagées,
 Créer des comptes utilisateurs 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.
Configurer l'environnement de samba par le fichier /etc/samba/smb.conf et demarrez le service

avec la commande /etc/init.d/samba start ou restart. 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.
Cette opération est réalisée dans la partie Share Definitions du fichier smb.conf. Chaque fois
que vous ajoutez ou modifiez une ressource, relancez le service serveur.
Exemple de fichier de configuration de Samba (pour un serveur simple) :

Vous trouverez de nombreuses autres options dans la documentation.
===============================================================================
[global]
## Browsing/Identification ###
workgroup = workgroup //à remplacer par le nom de votre groupe de travail

netbios name = NomDuServeur //à remplacer par le nom du serveur Samba
server string = %h server (Samba %v)
; wins support = no
; wins server = w.x.y.z
dns proxy = no

; name resolve order = lmhosts host wins bcast
#### Debugging/Accounting ####

log file = /var/log/samba/log.%m
# Put a capping on the size of the log files (in Kb).

max log size = 1000
syslog = 0
# Do something sensible when Samba crashes: mail the admin a backtrace

panic action = /usr/share/samba/panic-action %d
####### Authentication #######

security = user //nécessite une authentification pour accéder aux ressources
encrypt passwords = true

passdb backend = tdbsam guest
obey pam restrictions = yes

invalid users = root
passwd program = /usr/bin/passwd %u
passwd chat = *Enter\snew\sUNIX\spassword:* %n\n *Retype\snew\sUNIX\spassword:* %n\n
.
socket options = TCP_NODELAY
#===================== Share Definitions =======================
[homes]
#permet de partager le répertoire personnel de chaque utilisateur

comment = Home Directories
browseable = no
writable = yes
create mask = 0755
directory mask = 0755
[partage]
comment = Ressource partagée
#le répertoire /home/partage doit exister dans l'arborescence linux
path=/home/partage
browseable = yes
writable = yes
create mask = 0777
[printers]
comment = All Printers
browseable = no
path = /tmp
printable = yes
public = no
writable = no
create mode = 0700
# Windows clients look for this share name as a source of downloadable

# printer drivers
[print$]
comment = Printer Drivers
path = /var/lib/samba/printers
browseable = yes
read > guest ok = no
===============================================================================

Rappel: les comptes doivent déjà être créés sous linux avec la commande adduser .
Pour créer les comptes Samba, il faut utiliser la commande:
smbpasswd -a MonCompte MonMotdePasse
Cette commande ajoute le compte SAMBA MonCompte avec le mot de passe MonMotDePasse.
Il est possible ensuite dans la section "Share définitions" d'ajouter des partages accessibles
seulement à certains utilisateurs par exemple pour le répertoire /home/administration :
[administration]
path=/home/administration
public = no
valid users = pierre @admin
writable = yes
create mask = 0770
Le paramètre @admin permet de donner des droits aux membres du groupe système admin.
Le répertoire /home/administration doit être créé sous linux avec les droits adéquats , par
exemple:
mkdir /home/administration
chown pierre:admin /home/administration
chmod 770 /home/administration
Un problème à éviter:
Le compte utilisateur SAMBA dispose de moins de privilèges que le compte root. Si vous partagez
un répertoire 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.Les
droits SAMBA ne peuvent pas outrepasse les droits Linux, cf exemple ci-dessus pour donner des
droits.
Voir man smbpasswd ou smbpasswd --help pour le mode d'utilisation de la commande.
Remarques :
 Les manipulations peuvent paraître fastidieuses si vous avez un grand nombre de comptes
utilisateurs à créer.
 Si vous disposez de nombreux comptes d'utilisateurs sur votre système Linux, il est
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 (voir à la fin du TP Samba).
Toutes les indications sont dans la documentation de SAMBA.

Il est possible d'y accéder graphiquement avec le navigateur konqueror et le protocole smb en
utilisant l'url suivante : smb://@ip-du-serveur/nom-partage ou smb://@ip-du-serveur/
Figure 25.1. Accès à un serveur SAMBA à partir d'un client Linux par méthode graphique.
Accès en mode commande en utilisant la commande smbclient:
Pour visualiser tous les partages d'un serveur.
smbclient -L //@ip-du-serveur -U NomdeCompte

entrez ensuite le mot de passe Samba du compte
Vous pouvez également mettre le nom du serveur à la place de l'adresse IP du serveur
smbclient -L //NomDuServeur -U NomdeCompte

entrez ensuite le mot de passe Samba du compte
Figure 25.2. Accès à un serveur SAMBA à partir d'un client Linux par commande manuelle.

Cette autre commande vous permettra une fois connecté sur votre répertoire partagé d'envoyer
ou de recevoir des fichiers avec un shell du même type que ftp. Vous pouvez afficher la liste des
commandes disponibles en tapant help au prompt smb: .
#smbclient //@ipduserveur/partage -U NomdeCompte

Password:
Domain=[NS1] OS={Unix] Server=[Samba 3.0.22 ]
smb: \>help
D'autres possibilités existent pour accéder à des ressources d'un serveur Samba à partir d'un
poste linux avec des logiciels comme Smb4k, Komba2pass ou swat.
La configuration du client Windows ne doit pas poser de difficulté.
Le compte sur lequel vous êtes connecté sous Windows XP n'a pas d'importance.
Vérifiez la configuration du protocole TCP/IP, la machine cliente Windows doit se trouver dans le
même réseau IP que le serveur Samba.
Cliquez sur "favoris réseaux", puis sur "Voir les ordinateurs de votre groupe de travail" ensuite sur
"Réseaux Microsoft Windows", normalement vous allez trouver votre groupe de travail (ici "ja"):
Figure 25.3. Accès à votre groupe de travail à partir d'un client Windows.

En cliquant sur votre groupe de travail, vous voyez votre serveur Samba (ici Ns1):
Figure 25.4. Accès à votre serveur Samba à partir d'un client Windows.
En cliquant sur le serveur, vous devrez entrer un login (ici fds) et un mot de passe valides pour
accéder aux partages du serveur SAMBA :

Vous avez ensuite accès aux partages définis dans le fichier smb.conf, dans l'exemple le
répertoire personnel de l'utilisateur et le répertoire partage:
Toutes les commandes manuelles net use, net share vous permettent d'accéder aux ressources
du serveur (disques partagés, imprimantes, disque personnels).
A noter: pour vous connecter sous un autre login sur votre serveur Samba à partir du poste
Windows XP, vous devrez fermer et réouvrir votre session sous XP.
Jusqu'à présent le serveur Samba ne gérait que ses propres partages mais aucune
authentification de machines.

 Pour devenir contrôleur de domaine, c'est à dire l'équivalent d'un serveur Windows
2000/2003, il faut tout d'abord modifier la section globale du fichier smb.conf:

 [global]

 workgroup = mondomaine //à remplacer par votre nom de domaine
 netbios name = nom_serveur // à remplacer par votre nom de serveur

 # paramètres samba
 logon drive = U:
 logon home = \\serveur\%U
 logon path = \\serveur\profiles\%U
 logon script = logon.cmd //ce script devra être créé et stocké dans le
répertoire Netlogon


 # Controle de domaine
 os level = 65
 domain logons = yes
 domain master = yes
 local master = yes
 preferred master = yes
 wins support = yes

 # Base de comptes
 passdb backend = tdbsam:/var/lib/samba/mypassdb.tdb, guest
 # server string is the equivalent of the NT Description field
 server string = %h server (Samba %v)

 wins support = yes

 # la suite de cette section est la même que dans le premier exemple
 La section "Share definitions"
Il faut y créer des partages spécifiques "homes" qui contiendra les répertoires spécifiques
des utilisateurs, "netlogon" qui contiendra les scripts de connexion exécutés par les
machines clientes à chaque connexion d'un utilisateur, "profiles" qui permet de stocker de
manière centralisée la configuration du bureau etc ... de chaque utilisateur du domaine.
#===================== Share Definitions =======================
[homes]
path = /data/samba/home/%u
comment = Home Directories
valid users = %S
guest ok = no
browseable = no
writable = yes
create mask = 0700
[netlogon]
comment = Partage Netlogon
path = /data/samba/netlogon
guestok = no
readonly = yes
browseable = no
writable = no
valid users = @sambausers
create mask = 0777

[profiles]
path = /data/samba/profiles
comment = Repertoires Profiles
guest ok = no
writable = yes
create mode = 0700
browsable = no
valid users = @sambausers
[banc2]
path = /home/banc2
public = no
valid users = @banc2
writable = yes
create mask = 0640
[printers]
comment = All Printers
browseable = no
path = /tmp
printable = yes
public = no
writable = no
create mode = 0700
[print$]
comment = Printer Drivers
path = /var/lib/samba/printers
browseable = yes
read > guest ok = no
 Créer un groupe sambausers:
Ce groupe doit être créé avec le RID 513 pour être en conformité avec la terminologie
Windows.
#groupadd -g 513 sambausers
Ajouter dans ce groupe les utilisateurs linux du domaine. Il faut également créér des
comptes Samba pour chacun de ces utilisateurs grâce à la commande smbpasswd vue
précédemment.
Ne pas oublier d'ajouter le compte "root" au groupe "sambausers", celui-ci sera le super-
utilisateur samba.
#smbpasswd -a root MotDePasse
 Créer le groupe sambamachines:
Ce groupe doit être créé avec le RID 515.
#groupadd -g 515 sambamachines
Les comptes machines du domaine doivent être créés avec un $ à la fin du nom
netbios,voici un extrait du fichier "/etc/passwd" avec comme exemple 2 machines labo et
postexp :
labo$:x:1003:515::/dev/null:/dev/null
postexp$:x:1004:515::/dev/null:/dev/null

Créez également un compte Samba pour chaque machine:
#smbpasswd -a -m NomMachine (sans le $)
 Création des 3 nouveaux répertoires partagés

 #mkdir -p /data/samba/home
 #mkdir -p /data/samba/netlogon
 #mkdir -p /data/samba/profiles
Attribution des droits:
#chown root:sambausers /data/samba/home

#chown root:sambausers /data/samba/netlogon
#chown root:sambausers /data/samba/profiles
 Extrait du fichier /etc/group

 sambausers:x:513:root,bird
 sambamachines:x:515:labo$,postexp$
 Exemple de script exécuté au démarrage logon.cmd
 @echo off
 NET USE H: \\NomServeur\Nompartage
 @echo on
Chapter 26. Travaux pratiques : installation d'un serveur SAMBA
Table of Contents

Abstract
Partage de ressources sous GNU/Linux pour les clients GNU/Linux ou Windows avec le protocole
SMB.
Ce document décrit comment utiliser un serveur samba d'abord comme serveur simple puis
comme serveur d'identification et d'authentification pour des clients Windows (le serveur simule un
contrôleur de domaine NT4, 2000 ou 2003).
Vous utiliserez 2 postes en réseau. Le premier est sous Linux, le second sous Windows. On
désire installer et configurer le service de partage de fichiers SAMBA sous Linux. Le client

Windows doit permettre l'identification des utilisateurs sur le serveur en utilisant les mots de passe
cryptés.
Cet atelier permet la mise en oeuvre du protocole SMB. Il permet également d'envisager la mise
en place du partage de fichiers et d'imprimantes.
Les opérations vont se dérouler en 6 étapes :
 Configuration du fichier /etc/smb.conf et démarrage des services.

 Création de comptes utilisateurs.
 Création de ressources disques partagées en lecture et en lecture/écriture.
 Configuration du client Windows XP.
 Procédure de test.
 Configuration d'un contrôleur de domaine Samba.
 Procédure de test.
Le fichier de configuration smb.conf est dans le répertoire /etc/samba. Faites une copie de
sauvegarde de ce fichier puis ouvrez l'original avec un éditeur. Modifiez-le afin que les utilisateurs
puissent accéder au répertoire /tmp du serveur en rw et à leur répertoire personnel en rw
également.
Vous utiliserez et adapterez l'exemple donné dans la fiche de cours.
Vous allez tout d'abord :
 créer le compte linux

 créer le compte samba.
Créez un compte système à l'aide de la commande adduser.
Pour ce compte système vous créerez un compte samba à l'aide de la commande smbpasswd.

Démarrez le service. Vous pouvez utiliser la commande testparm pour valider la configuration du
serveur. Vérifiez également la table des processus et les traces dans le fichier log.
Le fichier diagnosis.html de la documentation de samba, donne une procédure en 10 points pour

vérifier que tout fonctionne. Localisez ce fichier, (en général dans /usr/share/doc/samba) ouvrez-
le avec un navigateur et réalisez la procédure de test qui y est décrite.
Si le serveur fonctionne correctement et que vous utilisez une Freeduc-Sup , vous pouvez utiliser
le plugin smb directement à partir de konqueror.
Lancez konqueror à partir d'un autre client linux et utilisez l'url suivante :
smb://@IP_Du_Serveur/un_partage_Samba_public ou smb://loginname@Nom_Du_Serveur/. Vous
devriez avoir une fenêtre équivalente à celle donnée ci-dessous.
Figure 26.1. Accès à un serveur SAMBA à partir d'un client Linux
En ligne de commande (man smbmount smbclient mount), il est fortement déconseillé de mettre le
mot de passe en clair, car outre le fait qu'il soit visible lors de sa saisie sur la console, il apparaitra
en clair dans la liste des processus avec un simple ps. Pour un montage automatique du système
de fichiers partagés dans fstab par exemple, on utilisera un fichier avec l'option du même nom et
on veillera à positionner les droits minimum.
#mkdir -p /mnt/samba
# smbmount //@ipduserveur/partage /mnt/smbmnt -o username=fds
Password:
Concernant la dernière commande, après le prompt smb, vous pouvez ensuite taper help pour
obtenir l'aide.

Exemple d'utilisation de tar avec les partages de fichiers samba :
smbclient //monpc/monpartage "" -N -Tc sauvegarde.tar users/docs
La procédure de test sera réalisée à partir d'un client XP. Pour d'autres types de clients, il sera
peut être nécessaire de créer des comptes d'ordinateurs, ou adapter la configuration du serveur
SAMBA. Il faudra se référer à la documentation située en général dans /usr/share/doc/samba.
Configurez votre client Windows pour qu'il puisse faire partie de votre domaine NT (mettre une
adresse IP dans le même réseau que le serveur Samba) déclaré sur votre serveur Linux.
Au démarrage du PC, vous pouvez vous authentifier avec un compte propre au poste XP.
Une fois la session ouverte vous utilisez la procédure décrite dans le cours:
 Favoris réseaux,
 Voir les ordinateur du groupe de travail,
 Réseaux Microsoft Windows
 Sélectionnez le nom de votre domaine Samba, puis cliquez sur votre serveur
 Vous devrez alors vous identifier avec un des utilisateurs définis sur votre serveur Samba.
 Vérifiez les accès en lecture / écriture sur les espaces disques partagés.
Modification de l'environnement serveur
Créez sur le serveur les espaces supplémentaires /mnt/apps et /mnt/partage. Le premier est en
lecture uniquement, le deuxième en lecture / écriture. Donnez des droits à certains utilisateurs
seulement. Modifiez smb.conf, relancez le service serveur, testez les accès.
Modifiez le fichier smb.conf suivant l'exemple donné dans le cours.
L'authentification sur un poste client Windows XP sera différente, vous pourrez dès l'ouverture de
session entrer un compte utilisateur Samba.
On donne, dans un fichier texte “ personnes ”, une liste de personnes. Le fichier a la structure
suivante :

login motdepasse
par exemple :
tux1 tux1
tux2 tux2
...
En général un fichier d'importation n'est pas aussi simple car on peut avoir des noms comprenant
des “ espaces ”. Les champs sont distingués par des séparateurs comme un point-virgule par
exemple. Il faudra dans ce cas traiter différement le fichier.
Le principe est simple :
 On crée un script qui va créer automatiquement les comptes systèmes,

 Le compte est représenté par la 1ère colonne du fichier "persons"
 Le mot de passe est représenté par la 2ème colonne du fichier
 Les groupes sont préalablement créés.
Testez et vérifiez le fonctionnement du script. Modifiez le script pour qu'il crée également les
comptes SAMBA.
Version pour Kubuntu
cat persons | while true

do
read ligne
if [ "$ligne" == "" ]
then
echo "fin du fichier"
break
fi
set -- $ligne
login=$1
pass=$2
if [ -d "/home/$1" ]
then
echo "le compte $1 existe déjà"
else
echo "création du compte $login"
useradd -m $login -G $1 -s /bin/bash
echo $login:$pass | chpasswd
(echo $pass ; echo $pass) | smbpasswd -s -a $login
chown $login:$groupe /home/$login
chmod 711 /home/$login
chown -R $login:$login /home/$login
done
echo "fin du script"
Vous pouvez utiliser des outils graphiques d'administration de SAMBA comme swatSmb4k . Pour
utilisez swat, décommentez la ligne dans /etc/inetd.conf :

swat stream tcp nowait root \
/usr/sbin/tcpd /usr/sbin/swat
Activez les services apache et inetd. Ouvrez le navigateur et saisissez :
http://localhost:901
Ouvrez une session avec le compte root.
Chapter 27. Eléments de cours sur le service DHCP
L'adressage IP dynamique - Fiche de cours
Revision History
Table of Contents
Résumé
Abstract
Eléments de cours sur le service DHCP
Résumé
Présentation, installation et configuration d'un serveur DHCP
Mots clés : “ Serveur DHCP ”, “ Agent relais DHCP ”
L'atelier propose
 d'installer un serveur DHCP sous Linux,

 d'installer un client DHCP sous Linux

 d'installer un client DHCP sous Windows
 de réaliser une phase de test avec les commandes winipcfg et ipconfig de Windows
Les éléments sur l'analyse de trame, notamment les trames bootp, seront retraités lors des TP sur
la métrologie.
Un serveur DHCP (Dynamic Host Configuration Protocol) a pour rôle de distribuer des adresses
IP à des clients pour une durée déterminée.
Au lieu d'affecter manuellement à chaque hôte une adresse statique, ainsi que tous les
paramètres tels que (serveur de noms, passerelle par défaut, nom du réseau), un serveur DHCP
alloue à un client, un bail d'accès au réseau, pour une durée déterminée (durée du bail). Le
serveur passe en paramètres au client toutes les informations dont il a besoin.
Tous les noeuds critiques du réseau (serveur de nom primaire et secondaire, passerelle par
défaut) ont une adresse IP statique ; en effet, si celle-ci variait, ce processus ne serait plus
réalisable.
Ce processus est mis en oeuvre quand vous ouvrez une session chez un fournisseur d'accès
Internet par modem. Le fournisseur d'accès, vous alloue une adresse IP de son réseau le temps
de la liaison. Cette adresse est libérée, donc de nouveau disponible, lors de la fermeture de la
session.
L'affectation et la mise à jour d'informations relatives aux adresses IP fixes peuvent représenter
une lourde tâche. Afin de faciliter ce travail et de simplifier la distribution des adresses IP, le
protocole DHCP offre une configuration dynamique des adresses IP et des informations
associées.
Avantages de DHCP dans l'administration d'un réseau ?
1. Le protocole DHCP offre une configuration de réseau TCP/IP fiable et simple, empêche les
conflits d'adresses et permet de contrôler l'utilisation des adresses IP de façon
centralisée. Ainsi, si un paramètre change au niveau du réseau, comme, par exemple
l'adresse de la passerelle par défaut, il suffit de changer la valeur du paramètre au niveau
du serveur DHCP, pour que toutes les stations aient une prise en compte du nouveau
paramètre dès que le bail sera renouvelé. Dans le cas de l'adressage statique, il faudrait
manuellement reconfigurer toutes les machines.
2. économie d'adresse : ce protocole est presque toujours utilisé par les fournisseurs
d'accès Internet qui disposent d'un nombre d'adresses limité. Ainsi grâce à DHCP, seules
les machines connectées en ligne ont une adresse IP. En effet, imaginons un fournisseur
d'accès qui a plus de 1000 clients. Il lui faudrait 5 réseaux de classe C, s'il voulait donner à
chaque client une adresse IP particulière. S'il se dit que chaque client utilise en moyenne
un temps de connexion de 10 mn par jour, il peut s'en sortir avec une seule classe C, en
attribuant, ce que l'on pourrait appeler des "jetons d'accès" en fonction des besoins des
clients.

3. Les postes itinérants sont plus faciles à gérer
4. Le changement de plan d'adressage se trouve facilité par le dynamisme d'attribution.
Avec DHCP, il suffit d'attribuer une adresse au serveur. Lorsqu'un ordinateur client
DHCPdemande l'accès au réseau en TCP-IP son adresse est allouée dynamiquement à l'intérieur
d'une plage d'adresses définie sur le serveur .
L'administrateur de réseau contrôle le mode d'attribution des adresses IP en spécifiant une durée
de bail qui indique combien de temps l'hôte peut utiliser une configuration IP attribuée, avant de
devoir solliciter le renouvellement du bail auprès du serveur DHCP.
L'adresse IP est libérée automatiquement, à l'expiration du bail, pour un ordinateur client

DHCP retiré d'un sous-réseau, et une nouvelle adresse est automatiquement définie pour ce
dernier, lorsque cet ordinateur est reconnecté à un autre sous-réseau. Ni l'utilisateur ni
l'administrateur de réseau n'ont besoin de fournir de nouvelles informations relatives à la
configuration. Cette fonctionnalité est non négligeable, tant pour les utilisateurs de portables fixés
ou non à différentes stations d'accueil que pour les ordinateurs fréquemment déplacés.
L'inconvénient :
Le client utilise des trames de broadcast pour rechercher un serveur DHCP sur le réseau, cela
charge le réseau. Si vous avez une entreprise avec plusieurs centaines de personnes qui ouvrent
leur session le matin à 8 h ou l'après midi à 14 h, il peut s'en suivre de graves goulets
d'étranglement sur le réseau. L'administrateur devra donc réfléchir sérieusement à l'organisation
de son réseau.
Le protocole DHCP (Dynamic Host Configuration Protocol) (RFC 1533 1534) est une extension de
BOOTP (RFC 1532), il fournit une configuration dynamique des adresses IP et des informations
associées aux ordinateurs configurés pour l'utiliser (clients DHCP). Ainsi chaque hôte du réseau
obtient une configuration IP dynamiquement au moment du démarrage, auprès du serveur
DHCP. Le serveur DHCP lui attribuera notamment une adresse IP, un masque et éventuellement
l'adresse d'une passerelle par défaut. Il peut attribuer beaucoup d'autres paramètres IP
notamment en matière de noms (l'adresse des serveurs DNS, l'adresse des serveurs WINS)
Un client DHCP est un ordinateur qui demande une adresse IP à un serveur DHCP.
Comment, alors, un client DHCP, qui utilise le protocole TCP/IP mais qui n'a pas encore obtenu
d'adresse IP par le serveur, peut-il communiquer sur le réseau ?
Lorsqu'un client DHCP initialise un accès à un réseau TCP/IP, le processus d'obtention du bail IP
se déroule en 4 phases :

1 - Le client émet un message de demande de bail IP (DHCPDISCOVER) qui est envoyé sous
forme d'une diffusion sur le réseau avec adresse IP source 0.0.0.0 et adresse IP destination
255.255.255.255 et adresse MAC.
2 - Les serveurs DHCP répondent en proposant une adresse IP avec une durée de bail et
l'adresse IP du serveur DHCP (DHCOFFER)
3 - Le client sélectionne la première adresse IP (s'il y a plusieurs serveurs DHCP) reçue et envoie
une demande d'utilisation de cette adresse au serveur DHCP (DHCPREQUEST). Son message
envoyé par diffusion comporte l'identification du serveur sélectionné qui est informé que son offre
a été retenue ; tous les autres serveurs DHCP retirent leur offre et les adresses proposée
redeviennent disponibles.
4 - Le serveur DHCP accuse réception de la demande et accorde l'adresse en bail (DHCPACK),

les autres serveurs retirent leur proposition.
Enfin le client utilise l'adresse pour se connecter au réseau.
Vous trouverez des éléments très précis sur le protocole DHCP dans les pages du manuel de
Linux. (dhcp3d, dhcpd.conf et dhclient.conf).
Lorsqu'un client redémarre, il tente d'obtenir un bail pour la même adresse avec le serveur DHCP
d'origine, en émettant un DHCPREQUEST. Si la tentative se solde par un échec, le client continue
à utiliser la même adresse IP s'il lui reste du temps sur son bail.
Les clients DHCP d'un serveur DHCP Windows (NT/2000) tentent de renouveler leur bail lorsqu'ils
ont atteint 50% de sa durée par un DHCPREQUEST. Si le serveur DHCP est disponible il envoie
un DHCPACK avec la nouvelle durée et éventuellement les mises à jour des paramètres de
configuration.
Si à 50% le bail n'a pu être renouvelé, le client tente de contacter l'ensemble des serveurs DHCP
(diffusion) lorsqu'il atteint 87,5% de son bail, avec un DHCPREQUEST, les serveurs répondent
soit par DHCPACK soit par DHCPNACK (adresse inutilisable, étendue désactivée...).
Lorsque le bail expire ou qu'un message DHCPNACK est reçu le client doit cesser d'utiliser
l'adresse IP et et demander un nouveau bail (retour au processus de souscription). Lorsque le bail
expire et que le client n'obtient pas d'autre adresse la communication TCP/IP s'interrompt.
Remarque : Si la demande n'aboutit pas et que le bail n'est pas expiré, le client continue à utiliser
ses paramètres IP.
Définir une plage d'adresses qui peuvent être louées à des hôtes qui en font la demande.
En général, on donne :
 Une adresse de début (la première qui sera attribuée)

 Une adresse de fin (la dernière)
 Une ou plusieurs plages d'adresses à exclure de la location (ceci permet de faire cohabiter
un modèle de configuration IP dynamique avec un modèle statique)
 Un masque de sous-réseau
Tous ces éléments sont attribués pour une durée de bail à fixer. Si, au bout de cette durée, l'hôte
ne sollicite pas à nouveau une adresse au serveur, cette adresse est jugée disponible pour un
autre hôte.
Il est possible de connaître les baux actifs (les locations en cours), on voit alors à quelle adresse
MAC est attribuée une adresse IP.
Les clients DHCP doivent être configurés seulement après la configuration du serveur. Etant
donné qu'un ordinateur ne peut fonctionner simultanément comme client et serveur DHCP,
l'ordinateur fonctionnant comme serveur DHCP doit être configuré avec une adresse IP fixe.
Lors de la configuration du client DHCP, il faut cocher la case « Obtenir une adresse IP depuis un
serveur DHCP » dans la fenêtre des propriétés de Microsoft TCP/IP. Il n'est pas nécessaire alors
de préciser une adresse IP ou un masque de sous-réseau.
Voici, par exemple, la configuration TCP/IP d'un ordinateur Windows XP qui sollicite une
configuration IP auprès d'un serveur DHCP :
Figure 27.1. Client DHCP sous Windows XP

Les commandes IPCONFIG (Windows NT/200x) et Winipcfg (Windows 9x) permettent de
visualiser la configuration IP complète du poste de travail :
Figure 27.2. WinIPCFG sous Windows 9x

IPCONFIG
ipconfig /all : affiche les paramètres IP complets, cela va nous permettre de vérifier la bonne
affectation d'adresse.
ipconfig /renew : déclenche l'envoi d'un message DHCPREQUEST vers le serveur DHCP pour
obtenir des options de mise à jour
ipconfig /release : déclenche l'envoi d'un message DHCPRELEASE pour abandonner le bail.
Commande utile lorsque le client change de réseau.
Comme les clients contactent les serveurs DHCP à l'aide d'une diffusion, dans un inter-réseau,
vous devrez théoriquement installer un serveur DHCP par sous-réseau. Si votre routeur prend en
charge la RFC 1542, il peut faire office d'agent de relais DHCP, et ainsi relayer les diffusions de
demande d'adresse IP des clients DHCP dans chaque sous-réseau.
Si votre routeur ne prend pas en charge la RFC 1542, une machine serveur peut être configurée
comme agent de relais DHCP, il suffira de lui spécifier l'adresse du serveur DHCP. Les demandes
des clients DHCP seront relayées vers le serveur DHCP par l'agent de relais DHCP qui
transmettra les offres aux clients.
Figure 27.3. Agent de relais DHCP dans un réseau routé

Chapter 28. Travaux pratiques : installation d'un serveur DHCP
Table of Contents

Procédure de test
Réalisation du TP
L'atelier propose
 d'installer un serveur DHCP sous Linux,

 d'installer un client DHCP sous Linux
 d'installer un client DHCP sous Windows
 de réaliser une phase de test avec les commandes winipcfg et ipconfig de Windows
Matériel nécessaire :
Deux machines en dual boot Linux / Windows en réseau.
Les éléments sur l'analyse de trame, notamment les trames bootp, seront retraités lors des TP sur
la métrologie.
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;
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.
Le fichier de configuration dhcpd.conf
On n'abordera pas tous les paramètres. Vous trouverez un exemple de fichier commenté qui
permet de réaliser cet atelier. Vous pouvez créer ce fichier avec un éditeur.
$>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
Création d'un fichier d'inscription
Ce fichier doit parfois être créé, sans quoi le serveur DHCP ne pourra pas démarrer. Il suffit de
créer un fichier vide. Pour cela, saisissez la commande touch /var/lib/dhcp3/dhcpd.leases. Le
fichier est créé. Voici ce qu'il peut contenir après l'inscription du premier client :
[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";
On distingue les informations suivantes : Début du bail, Fin du bail, adresse MAC du client, le nom
d'hôte du client. Attention ce nom est différent du nom Netbios utilisé sur les réseaux Microsoft.
Le serveur est configuré, il n'y a plus qu'à le mettre en route. Utilisez la commande suivante pour
arrêter ou activer le service : /etc/init.d/dhcpd3 start | stop.
Le script lance le serveur en mode daemon. Vous pouvez le lancer en avant plan avec la
commande dhcpd3 -d. Cela permet de voir les messages et déterminer s'il y a des
dysfonctionnement éventuels.
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
CTRL C pour arrêter.
Le client sous Windows
L'installation est assez simple si vous avez déjà une carte réseau et le protocole TCP/IP installé.
Utilisez les commandes suivantes: Panneau de configuration/Réseau/Protocole TCP
IP/Propriétés/Onglet "adresse ip"/ Cochez Obtenir automatiquement une adresse IP
La configuration est terminée, vous pouvez relancer la machine. Le client interrogera un serveur
DHCP pour qu'il lui délivre un bail (sorte d'autorisation de séjour sur le réseau) contenant au
minimum une adresse Ip et le masque correspondant .
Le client sous Linux
Vous allez réaliser une configuration manuelle
Allez dans le répertoire /etc/network, ouvrez le fichier interfaces. C'est ici qu'est la configuration
des cartes installées sur la machine. Remplacez static par dhcp dans la configuration de
l'interface eth0. Mettez tous les paramètres de cette interface (address, netmask, network....) en
commentaire.
La configuration de la carte est terminée, vous pouvez tester en relançant le service réseau.
Vous pouvez egalement tester dynamiquement en ligne de commande:
root@m1:# dhclient eth0
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.

Réalisation du TP
1. Installez un serveur DHCP minimal sous Linux et vérifiez le bon démarrage du service
2. Installez un client DHCP sous Linux, vérifiez le bon démarrage du service réseau et
l'inscription dans le fichier dhcp.leases du serveur. Testez le renouvellement du bail. Il suffit
de relancer le service réseau.
3. Installez un client DHCP sous Windows, vérifiez le bon démarrage du service réseau et
l'inscription dans le fichier dhcp.leases du serveur. Testez le renouvellement du bail.
4. Modifiez l'étendue du serveur. Vérifiez le bon fonctionnement de la distribution d'adresses

aux clients.
5. Modifiez la configuration du serveur afin qu'il distribue également l'adresse de la passerelle

par défaut, l'adresse du serveur de nom. Testez la configuration.
6. Modifiez la configuration du serveur DHCP afin de réserver une adresse au client, vérifiez
que le processus a bien fonctionné.
Chapter 29. Travaux pratiques : installation d'un agent relais DHCP
Table of Contents

La maquette
Installation
Les trames arp, bootp ne traversent pas les routeurs. Sur un réseau segmenté par des routeurs il
est donc impossible de servir tous les segments avec le même serveur DHCP. Il faut donc mettre
un serveur DHCP sur chaque segment, ou alors utiliser un agent de relais DHCP.
Un agent relais DHCP relaie les messages DHCP échangés entre un client et un serveur DHCP
situés sur des sous-réseaux différents.
Il est généralement installé sur un routeur pour pouvoir diriger les messages vers le serveur
DHCP, mais ce n'est pas obligatoire. L'agent doit connaître l'adresse du serveur DHCP mais ne
peut pas être lui-même client DHCP.
Serveur DHCP et agent de relais ont des adresses ip statiques. Le dialogue traverse le routeur et
se fait en unicast.
Figure 29.1. Dialogue client DHCP, agent de relai DHCPet serveur DHCP

Après avoir envoyé une trame de broadcast, le client DHCP dialoque avec l'agent de relai DHCP
en unicast (1). L'agent demande une adresse au serveur DHCP dont il connaît l'adresse (2). Le
serveur retourne à l'agent une adresse (3) qui est donnée au client DHCP par l'agent (4).
Le principal problème du service DHCP est la mise à jour des serveurs de noms d'hôtes. Bind
sous Linux permet la mise à jour dynamique (RFC 2136) grâce à un serveur "updater" qui peut
ajouter ou supprimer dynamiquement des enregistrements de ressources. Il faut pour corriger cela
installer un serveur DNS dynamique ( DDNS) qui accepte les inscriptions des clients DHCP.
La maquette
Construisez une maquette en adaptant le schéma ci-dessous :
Figure 29.2. Maquette agent relais DHCP
Configurez les interfaces réseau de chaque machine, vérifiez que le routeur est opérationnel et
que les paquets traversent bien.
Installation
Les packages : vous avez normalement les paquets sur la distribution Linux (client, serveur et
agent de relais) :

Vous allez devoir installer ces produits pour les configurer et disposer de la documentation de ces
produits.
Description:
Sous Linux il existe un agent relais DHCP (dhcprelay). Ce produit de l'ISC (Internet Software
Consortium) permet de router des requêtes BOOTP et DHCP provenant de clients d'un réseau sur
lequel il n'y a pas de serveur DHCP vers un autre segment sur lequel un serveur pourra répondre.
Mode de fonctionnement :
L'agent relais DHCP écoute les requêtes et les réponses BOOTP et DHCP. Quand une requête
arrive, l'agent route la requête vers la liste de serveurs spécifiée sur la ligne de commande. Quand
une réponse arrive d'un serveur, l'agent transmet la réponse (broadcast ou unicast cela dépend
de la réponse) sur le segment d'où provenait la requête (broadcast) ou directement vers le client
(unicast).
Ligne de commande :
dhcrelay3 [-p port] [-d] [-q] [-i if0 [... -i ifN ] ]server0 [ ...serverN ]
L'agent
- écoute sur toutes les interfaces à moins que certaines
soient spécifiées avec l'option -i,
- utilise, comme le protocole Bootp, le port 67 par défaut
(voir /etc/services ) modifiable avec l'option -p,
- fonctionne en avant-plan avec l'option -d (option debug),
sinon en arrière-plan,
- n'affiche pas les informations de démarrage avec l'option -q,
- utilise les serveurs spécifiés sur la ligne de commande
server0, ...serveurN.
Vous allez installer le service serveur DHCP. Inspirez vous de l'exemple ci-dessous :
authoritative;
log-facility local7;
subnet 172.16.11.0 netmask 255.255.255.0 {
range 172.16.11.2 172.16.11.253;
#option domain-name-servers 192.168.90.77;
#option domain-name "pat107.org";
subnet 172.16.12.0 netmask 255.255.255.0 {

range 172.16.12.2 172.16.12.253;
}
Vous adapterez le fichier de configuration du serveur afin qu'il puisse délivrer des adresses pour
les deux étendues d'adresses. Chaque segment représentant une étendue.

Vérifiez que le serveur démarre sans erreurs ni warning avec l'option "-d" (debug). Ne le lancez
pas en mode daemon.
roo:~# dhcpd3 -d
Internet Systems Consortium DHCP Server V3.0.1rc14
Copyright 2004 Internet Systems Consortium.
For info, please visit http://www.isc.org/sw/dhcp/
Wrote 0 deleted host decls to leases file.
Wrote 0 new dynamic host decls to leases file.
Listening on LPF/eth0/00:08:c7:19:25:75/172.16.11.0/24
Sending on LPF/eth0/00:08:c7:19:25:75/172.16.11.0/24
Vérifiez égalemement que le service est actif et que le port est bien ouvert avec la commande
netstat :
Proto Recv-Q Send-Q Adresse locale Adresse distante Etat PID/Program name
udp 64232 0 0.0.0.0:67 0.0.0.0:* 2093/dhcpd3
Installer l'agent relais DHCP et activer le service, toujours en mode debug. La commande "dpkg-
reconfigure " peut également vous permettre de configurer l'agent et indiquer à quel serveur
l'agent doit passer les requêtes.
Sur la ligne de commande, on indique à quel serveur doit s'adresser l'agent :
root@PAT109:~# dhcrelay3 172.16.11.1 -d

Internet Systems Consortium DHCP Relay Agent V3.0.1rc14
Copyright 2004 Internet Systems Consortium.
For info, please visit http://www.isc.org/sw/dhcp/
Listening on LPF/eth0/00:03:0d:08:63:bf
Sending on LPF/eth0/00:03:0d:08:63:bf
Sending on Socket/fallback
regardez, avec la commande netstat sur quel port par défaut l'agent attend les requêtes.
Démarrez le poste client et regardez le dialogue sur les consoles du serveur et de l'agent. Le
client doit obtenir une adresse ip.
Voici un extrait du dialogue sur l'agent :
# Transmission de la requête cliente au serveur

forwarded BOOTREQUEST for 00:0a:e4:4e:64:4e to 172.16.11.1
# Transmission de l'adresse reçu du serveur au client
forwarded BOOTREPLY for 00:0a:e4:4e:64:4e to 172.16.12.10
Voici un extrait du dialogue sur le serveur :
# Le serveur reçoit une requête de l'agent

DHCPREQUEST for 172.16.12.10 from 00:0a:e4:4e:64:4e via 172.16.12.1
# Il fournit une adresse ip et la valide
DHCPACK on 172.16.12.10 to 00:0a:e4:4e:64:4e via 172.16.12.1
Réalisez une capture de trame du dialogue agent/serveur sur le routeur.

Analysez la capture
Entre le relais DHCP et le serveur DHCP a-t-on utilisé des adresses de diffusion MAC ?
Comment le serveur DHCP sait-il dans quelle plage d'adresse (étendue) il doit puiser l'adresse ?
Fixez un bail à 1 mn et étudiez le mécanisme de renouvellement automatique en examinant une

capture de 3 minutes.
Modifiez la configuration du serveur afin de faire de la réservation d'adresse pour le client. Vérifiez
le fonctionnement.
Une fois que tout fonctionne, activez tous les services en mode daemon et vérifiez le
fonctionnement de la maquette.
Chapter 30. Installation d'un serveur DNS
La résolution de noms - Fiche de cours
Table of Contents

La délégation
Le cache

Avec windows
Avec GNU/Linux
Procédure de tests
nslookup, dig
Le cache du DNS
Les journaux
Remarques
Annexes
Abstract
Ce document décrit la procédure d'installation et de configuration d'un serveur de noms sous

GNU/Linux
Avant d'installer un service quel qu'il soit, il faut s'assurer du bon fonctionnement de la résolution
de noms sur le réseau. Pour cela vous avez le choix entre l'utilisation des fichiers hosts ou du
service DNS. C'est ce dernier qui sera utilisé. Vous devez être familiarisé avec l'installation de
GNU/Linux.
Le service de résolution de noms d'hôtes DNS (Domain Name Services), permet d'adresser un
hôte par un nom, plutôt que de l'adresser par une adresse IP. Quelle est la structure d'un nom
d'hôte?
Nom_d_hôte ou bien Nom_d_hôte.NomDomaine

Exemple : ns1 ou bien ns1.foo.org
Le nom de domaine identifie une organisation dans l'internet, comme, par exemple, yahoo.com,
wanadoo.fr, eu.org. Dans les exemples, nous utiliserons un domaine que l'on considère fictif :
“ foo.org ”. Chaque organisation dispose d'un ou plusieurs réseaux. Ces réseaux sont composés
de noeuds, ces noeuds (postes, serveurs, routeurs, imprimantes) pouvant être adressés.

Par exemple, la commande ping ns1.foo.org, permet d'adresser la machine qui porte le nom
d'hôte ns1, dans le domaine (organisation) foo.org.
Quelle différence entre la résolution de noms d'hôtes avec un serveur DNS et les fichiers hosts ?
Avec les fichiers hosts, chaque machine dispose de sa propre base de données de noms. Sur des
réseaux importants, cette base de données dupliquée n'est pas simple à maintenir.
Avec un service de résolution de noms, la base de données est localisée sur un serveur. Un client
qui désire adresser un hôte regarde dans son cache local, s'il en connaît l'adresse. S'il ne la
connaît pas il va interroger le serveur de noms.
Tous les grands réseaux sous TCP/IP, et internet fonctionnent (schématiquement) sur ce principe.
Avec un serveur DNS, un administrateur n'a plus qu'une seule base de données à maintenir. Il
suffit qu'il indique sur chaque hôte, quelle est l'adresse de ce serveur. Ici il y a 2 cas de figures
possibles :
 soit les hôtes (clients) sont des clients DHCP (Dynamic Host Configuration Protocol), cette
solution est particulière et n'est pas abordée ici. Cette technique est l'objet d'un autre
chapitre.
 soit les clients disposent d'une adresse IP statique. La configuration des clients est
détaillée dans ce document.
Normalement un service DNS nécessite au minimum deux serveurs afin d'assurer un minimum de
redondance. Les bases de données des services sont synchronisées. La configuration d'un
serveur de noms secondaire sera expliquée. Nous verrons également en TP le fonctionnement de
la réplication des bases de données (bases d'enregistrements de ressources). On peut parler de
bases de données réparties et synchronisées.
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.
Figure 30.1. Les domaines

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.
Figure 30.2. 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.
Figure 30.3. 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.
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.
Figure 30.4. 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)
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.
Les enregistrements ont une structure et un rôle que nous verrons. Le daemon se nomme named,
prononcer “ naime dé ”.
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.
Ces enregistrements caractérisent des informations de type IN - INternet. Voir l'annexe pour avoir
un fichier exemple.
Structure d'un enregistrement SOA : chaque fichier de ressource de zone commence par un
enregistrement de type SOA. Voici un exemple d'enregistrement SOA :

$TTL 38400
foo.org. IN SOA ns1.foo.org. hostmaster.foo.org. (
20001210011 ; numéro de série
10800 ; rafraîchissement
3600 ; nouvel essai
604800 ; Obsolescence après une semaine
86400 ) ; TTL minimal de 1 jour
Caractéristiques des différentes informations :
SOA Start Of Authority, enregistrement qui contient les informations de synchronisation des
différents serveurs de nom.
foo.org, donne le nom de la zone. Le nom de la zone, ici "foo.org", peut être remplacé par "l'@",
arobase.
hostmaster.foo.org : la personne qui est responsable de la zone. Le premier point sera remplacé
par l'arobase (@) pour envoyer un courrier électronique. Cela deviendra hostmaster@foo.org. En
général postmaster, est un alias de messagerie électronique vers l'administrateur du DNS.
1. Numéro de série sous la forme AAAAMMJJNN, sert à identifier la dernière modification sur
le serveur de noms maître. Ce numéro sera utilisé par les serveurs de nom secondaires
pour synchroniser leurs bases. Si le numéro de série du serveur de noms primaire est
supérieur à celui des serveurs de noms secondaire, alors le processus de synchronisation
suppose que l'administrateur a apporté une modification sur le serveur maître et les bases
seront synchronisées.
2. Rafraîchissement : Intervalle de temps donné en seconde pour indiquer au serveur la
périodicité de la synchronisation.
3. Retry : intervalle de temps avant réitération si l'essai précédent n'a pas fonctionné.
4. Expire : temps au bout duquel le serveur ne remplit plus sa mission s'il n'a pu contacter le
serveur maître pour mettre à jour ses données.
5. TTL : Time To Live, durée de vie des enregistrements. Plus la durée de vie est courte, plus
l'administrateur est susceptible de considérer que ses bases sont à jour, par contre cela
augmente le trafic sur le réseau.
Enregistrement de type NS pour le domaine foo.org :
foo.org. IN NS ns1.foo.org. ; noter le point final "."

foo.org. IN NS ns2.foo.org. ; foo.org peut être remplacé par "@"
; IN signifie enregistrement de type INternet
Le “.” final signifie que le nom est pleinement qualifié. On aurait pu mettre :
@ IN NS ns1
IN NS ns2
"@" signifie "foo.org" et pour le serveur de nom, comme "ns1" n'est pas pleinement qualifié, cela
équivaut à "ns1.foo.org".
Enregistrements de type A : nous devons décrire la correspondance Nom / Adresse
ns1.foo.org. IN A 192.168.0.1
ns2.foo.org. IN A 192.168.0.2

localhost.foo.org. IN A 127.0.0.1
S'il y avait d'autres hôtes sur la zone, il faudrait les définir ici.
Enregistrements de type CNAME : Ce sont les alias (Canonical Name). Une requête du type
http://www.foo.org sera adressée à ns1.foo.org, puisque www est un alias de ns1.
www IN CNAME ns1.foo.org.

ftp IN CNAME ns1.foo.org.
Enregistrement de type PTR : il serviront à la résolution de noms inverse.
1.0.168.192.in-addr.arpa. IN PTR ns1.foo.org.

2.0.168.192.in-addr.arpa. IN PTR ns2.foo.org.
La délégation
La délégation consiste à donner l'administration d'une partie du domaine à une autre organisation.
Il y a transfert de responsabilité pour l'administration d'une zone. Les serveurs de la zone auront
autorité sur la zone et auront en charge la responsabilité de la résolution de noms sur la zone. Les
serveurs ayant autorité sur le domaine auront des pointeurs vers les serveurs de noms ayant
autorité sur chaque zone du domaine.
Le serveur maître (primaire) dispose d'un fichier d'information sur la zone. Le ou les serveurs
esclaves (secondaires) obtiennent les informations à partir d'un serveur primaire ou d'un autre
serveur esclave. Il y a " transfert de zone". Les serveurs maîtres et esclaves ont autorité sur la
zone.
Le cache
L'organisation d'internet est assez hiérarchique. Chaque domaine dispose de ses propres
serveurs de noms. Les serveurs peuvent être sur le réseau physique dont ils assurent la
résolution de nom ou sur un autre réseau. Chaque zone de niveau supérieur (edu, org, fr...)
dispose également de serveurs de nom de niveau supérieur. L'installation du service DNS, installe
une liste de serveurs de noms de niveaux supérieurs. Cette liste permet au serveur de résoudre
les noms qui sont extérieurs à sa zone. Le serveur enrichit son cache avec tous les noms résolus.
Si votre réseau réseau n'est pas relié à internet, vous n'avez pas besoin d'activer cette liste.
Ce fichier est un peu particulier. Il est fourni avec les distributions. Il est utilisé par le serveur de
noms à l'initialisation de sa mémoire cache. Si vos serveurs sont raccordés à internet, vous
pourrez utiliser une liste officielle des serveurs de la racine (ftp.rs.internic.net).
Processus de configuration
L'application est déjà installée. Pour mettre en place le service de résolution de noms sur un
serveur GNU/Linux, on va procéder successivement aux opérations suivantes :

1. vérifier les fichiers déjà installés,
2. configurer les fichiers des zones administrées,
3. configurer les fichiers de transaction sécurisée pour rndc,
4. démarrer et tester le service serveur.
Vous devez normalement avoir déjà les fichiers suivants :
1. /etc/bind/named.conf, fichier de déclaration des fichiers de ressources

2. /etc/bind/db.127, zone locale reverse
3. /etc/bind/db.0, zone locale de broadcast
4. /etc/bind/db.255, zone locale de broadcast
5. db.local, zone directe locale
6. db.root, fichiers des serveurs racine
Le contenu de tous ces fichiers et commentaires se trouve en annexe.
Vous avez également des fichiers particuliers : rndc.key, rndc.conf. rndc, est un outil qui permet
de passer des commandes à distance à un serveur de nom. Nous porterons une attention toute
particulière à ces fichiers, à leur rôles et à l'utilité de rndc.
Il va suffire de rajouter les fichiers manquants à la zone administrée.
rndc est un outil qui permet de réaliser des transactions sécurisées avec un serveur de nom. Le
mode de fonctionnement est dit à "clé partagée", c'est à dire que le client rndc et le serveur bind
doivent avoir la même clé. Vous devrez donc configurer le fichier de configuration de rndc et le
fichier named.conf avec les mêmes paramètres.
Ces fichiers et exemples sont également fournis en annexe. La clé doit être strictement identique
dans les 2 fichiers. Si vous avez un message d'erreur à l'utilisation de rndc, vérifiez bien ces
paramètres.
rndc supporte plusieurs paramètres pour passer des commandes au serveur de nom (halt,
querylog, refresh, reload, stat...). Utilisez la commande "man rndc" pour en savoir plus.
Dans le fichier rndc, vous allez avoir besoin d'au moins 3 paramètres. rndc utilisera ces
paramètres si rien n'est spécifié sur la ligne de commande. Dans les autres cas, vous pouvez
passer les paramètres sur la ligne de commande.
Note : vous pouvez vous passer du système de clé mais ce n'est pas conseillé. Commentez tout
ce qu'il y a dans le fichier named.conf et qui concerne la clé s'il y a déjà des choses. Renommez
le fichier rndc.conf en rndc.conf.orig, ça devrait fonctionner. Vous pouvez tester cela en faisant un
/etc/init.d/bind restart. Vous ne devriez pas avoir de message d'erreur.

#Description du serveur et de la clé utilisés par défaut.
#Ici on utilise par défaut le serveur local, avec la clé key-name
options {
default-server localhost;
default-key "<key-name>";
};
Il est possible de dire quelle clé utiliser en fonction d'un serveur donné.
server localhost {
key "<key-name>";
};
Enfin il reste à définir la ou les clés avec leur noms et leurs valeurs.
key "<key-name>" {
algorithm hmac-md5;
secret "<key-value>";
};
Pour créer une nouvelle clé, utilisez la commande :
dnssec-keygen -a hmac-md5 -b <bit-length> -n HOST <key-file-name>
#Ici on génère une clé de 512 bits dans un fichier maCLE

dnssec-keygen -a hmac-md5 -b 512 -n HOST maCLE
Le fichier named.conf doit connaître la clé utilisée par le client,
// secret must be the same as in /etc/rndc.conf

key "key" {
algorithm hmac-md5;
secret
"c3Ryb25nIGVub3VnaCBmb3IgYSBtYW4gYnV0IG1hZGUgZm9yIGEgd29tYW4K";
};
mais doit également comprendre les paramètres qui définissent les machines clientes autorisées
à passer des commandes avec une directive controls.
controls {
inet 127.0.0.1 allow { localhost; } keys { <key-name>; };
};
# Ici on peut passer des commandes à partir de n'importe quelle machine

controls {
inet 127.0.0.1 allow { any; } keys { "key"; };
};
# Ici on peut passer des commandes localement

controls {
inet 127.0.0.1 allow { localhost; } keys { "key"; };
};
L'installation a copié les fichiers. Sur une configuration simple vous allez avoir 3 fichiers à créer ou
à modifier sur le serveur primaire :

 /etc/bind/named.conf (fichier de configuration globale du service DNS du serveur de noms
primaire),
 /etc/bind/db.foo.org qui contiendra la description de la correspondance nom-adresse de
toutes les machines du réseau
 /etc/bind/db.foo.org.rev qui contiendra la correspondance inverse adresse-nom (pour la

résolution inverse de nom in-addr.arpa).
Vous pouvez configurer le serveur manuellement, c'est à dire créer les fichiers à l'aide d'un éditeur
de texte ou à l'aide d'un outil de configuration graphique. En général on n'installe jamais
d'interface graphique sur un serveur pour des questions de sécurité. Nous allons donc créer les
fichiers complètement. La configuration est réalisable également à distance avec des requêtes
HTTP grâce à des outils comme webmin.
Le fichier racine pour la configuration du serveur de noms est le fichier /etc/bind/named.conf. Ce

fichier est lu au démarrage du service et donne la liste des fichiers qui définissent la base de
données pour la zone.
Voir annexe.
Voir annexe.
Le paramètre @, signifie qu'il s'agit du domaine "foo.org" (le nom tapé après le mot " zone " dans
le fichier de configuration named.conf). Le paramètre "IN", signifie qu'il s'agit d'un enregistrement
de type internet. Notez la présence d'un point (.) après le nom des machines pleinement qualifiés.
Sans celui-ci, le nom serait " étendu ". Par exemple, ns1.foo.org (sans point) serait compris
comme ns1.foo.org.foo.org (on rajoute le nom de domaine en l'absence du point terminal). Le
point (.) terminal permet de signifier que le nom est pleinement qualifié.
Voir annexe.
Le service (daemon) qui active la résolution de noms s'appelle named prononcer “ naime dé ”,
mais le script s'appelle bind, ou sur certaines distributions bind9. Je noterai ici bind.

Si vous voulez l'arrêter ou le redémarrer dynamiquement vous pouvez utiliser les commandes
suivantes :
# La commande stop utilise souvent rndc.

# rndc doit donc être préalablement configuré.
/etc/init.d/bind stop
/etc/init.d/bind start
Relancer le service serveur de cette façon peut parfois poser problème. En effet cette procédure
régénère le cache du serveur. Le service prend également un nouveau PID. Si vous voulez éviter
cela, ce qui est généralement le cas, préférez la commande kill -HUP PID de Named. Vous
trouverez le PID de named dans /var/run.
Les fichiers de configuration sont créés. Il ne reste plus qu'à tester. Il faut au préalable configurer
le serveur pour que tous les processus clients utilisent le service de résolution de nom. Il vous faut
modifier le fichier /etc/resolv.conf :
# nameserver AdresseIpDuServeurDeNom
# Exemple
Vous pouvez également configurer d'autres clients pour qu'ils utilisent votre serveur de nom.
La description de la configuration de tous les clients possibles n'est pas détaillée. Vous trouverez
ci-dessous des éléments pour un client windows 9x et pour un client GNU/Linux.
Avec windows
Il s'agit d'un client windows. Chaque client dispose du protocole TCP/IP, d'une adresse IP. Il faut
configurer le client pour lui signifier quel est le serveur de noms qu'il doit consulter. Pour cela il
faut aller dans : panneau de configuration - réseau - tcp/ip - Onglet “Configuration DNS”. Vous
allez pouvoir définir les paramètres suivants :
 le nom d'hôte de la machine locale dans le réseau

 le nom de domaine auquel appartient l'hôte (dans cet exemple c'est foo.org)
Ces 2 paramètres sont facultatifs dans l'atelier qui nous intéresse. Par contre le paramètre “Ordre
de recherche DNS” est important. Mettez dessous :
 L'adresse IP du serveur de noms que vous avez configuré,

 Cliquez sur ajouter
 Entrez l'adresse IP du serveur de noms
 Validez puis relancer la machine
Ce paramètre, définit à la machine locale, l'adresse de l'hôte de destination qui est chargé de la
résolution des noms d'hôtes dans le réseau. Cela permet de dire qu'un serveur de noms doit avoir
une adresse IP statique sur le réseau.

Avec GNU/Linux
Vous pouvez modifier (en tant que root) le fichier de configuration du “resolver”
(/etc/resolv.conf). Exemple (ça tient en deux lignes) :
# Fichier /etc/resolv.conf
search foo.org
nameserver 192.168.1.1 # mettre votre DNS
Procédure de tests
Attention au fichier hosts et au fichier host.conf. Prenez le temps de regarder ce qu'il y a dedans.
Faites une copie de sauvegarde de ces fichiers et renommez les. Vérifiez au besoin leur utilité
avec les commandes man host.conf et man hosts.
Vous pouvez tester votre configuration avant même d'avoir configuré un client. Sur la même
machine vous allez utiliser un service client du serveur (commande ping) qui utilisera un service
serveur (DNS).
Test sur le serveur de noms : Tapez la commande ping ftp.foo.org. Si la commande répond, le
serveur fonctionne. En effet ftp est un alias de ns1 dans la zone foo.org.
Test sur le client : Avant de lancer une commande, vous devez vérifier que vous n'avez pas de
fichier hosts local, sinon vous devez le supprimer.
Pourquoi ? L'utilisation de fichiers hosts et d'un serveur de noms n'est pas exclusif. Dans bien des
environnements, le fichier hosts est consulté avant le serveur de noms (notamment windows,
GNU/Linux à moins que ce ne soit précisé). Si vous avez un fichier hosts sur la machine, vous
pouvez avoir des résultats qui ne sont pas ceux attendus.
Pensez à bien vérifier le nom d'hôte de votre machine avec la commande hostname, au besoin,
sous root, modifiez ce nom, toujours avec cette commande. Fermez les sessions et rouvrez les,
vous aurez le bon nom d'hôte qui s'affichera sur votre console.
Mettons que le réseau soit configuré de la façon suivante :
Nom d'hôte Alias (CNAME) Adresse IP Serveur

ns1 www
ftp
mail
ns1 192.68.1.1
Client 1 Cli1 192.68.1.2
Pour vérifier le fonctionnement de la résolution de noms à partir du client cli1, vous pouvez utiliser
les commandes suivantes :
- ping ns1
- ping cli1
Vous pouvez également tester la résolution des alias (CNAME) avec les commandes :

ping mail.foo.org
ping www.foo.org
ping ftp.foo.org
ping ns1.foo.org
C'est bien la même adresse IP (voir le cache arp) qui répond, la machine a donc bien plusieurs
noms.
Si vous voulez vérifier que c'est bien le serveur de noms qui réalise la résolution, il existe plusieurs
solutions. La plus simple est d'arrêter le service serveur avec la commande /etc/init.d/bind
stop, puis de refaire les manipulations. Aucune machine n'est atteignable en utilisant son nom,
mais cela est toujours possible en utilisant l'adresse IP.
Les sources de dysfonctionnement des services de noms peuvent être nombreuses et parfois
complexes à résoudre. Voici quelques outils et méthodes qui peuvent être utilisées.
Si vous avez une erreur similaire à celle-ci :
Problème de clés entre named et rndc

root@knoppix:/etc/bind# /etc/init.d/bind9 stop
Stopping domain name service: namedrndc: connection to remote host closed
This may indicate that the remote server is using an older version of
the command protocol, this host is not authorized to connect,
or the key is invalid.
Le problème est lié à rndc, et souvent à des clés qui sont différentes ou mal définies entre
named.conf et rndc.conf. Vérifiez donc bien tous les paramètres.
Vérifiez dans les journaux (en général /var/log/daemon) qu'il n'y a pas d'erreur de chargement de
named. Voici un exemple de log.
# Log après chargement des zones

Apr 8 23:12:46 knoppix named[1066]: starting BIND 9.2.1
Apr 8 23:12:46 knoppix named[1066]: using 1 CPU
Apr 8 23:12:46 knoppix []
named[1068]: loading configuration from '/etc/bind/named.conf'

named[1068]: no IPv6 interfaces found
named[1068]: listening on IPv4 interface lo, 127.0.0.1#53
named[1068]: listening on IPv4 interface eth0, 192.168.90.100#53
named[1068]: command channel listening on 127.0.0.1#953
named[1068]: zone 0.in-addr.arpa/IN: loaded serial 1
named[1068]: zone localhost/IN: loaded serial 1
named[1068]: zone foo.org/IN: loaded serial 2003040101
Apr 8 23:12:46 knoppix named[1068]: running
Ou encore avec la commande ps :
root:# ps aux | grep named

root 1066 0.0 1.6 10312 2136 ? S 23:12 0:00 /usr/sbin/named
Vous pouvez également faire des tests successifs pour tester la résolution de nom.
#Vérification avec des ping
root@ns1:~# ping -c1 ns1.foo.org

PING ns1.foo.org (192.168.90.100): 56 data bytes
64 bytes from 192.168.90.100: icmp_seq=0 ttl=64 time=0.1 ms
--- ns1.foo.org ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 0.1/0.1/0.1 ms
root@ns1:~# ping -c1 www.foo.org

PING ns1.foo.org (192.168.90.100): 56 data bytes
64 bytes from 192.168.90.100: icmp_seq=0 ttl=64 time=0.1 ms
--- ns1.foo.org ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 0.1/0.1/0.1 ms
nslookup, dig
La commande nslookup est de moins en moins utilisée, nous la verrons donc pas. Nous allons
voir l'utilisation de dig.
Ces commandes sont très largement utilisées par les administrateurs de réseau pour résoudre les
problèmes liés aux services de résolution de noms.
Tests avec dig :
# Test sur une zone

root@knoppix:/etc/bind# dig any foo.org
; <<>> DiG 9.2.1 <<>> any foo.org
;; Got answer:
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;foo.org. IN ANY
;; ANSWER SECTION:
foo.org. 604800 IN SOA ns1.foo.org. \

root.ns1.foo.org. 2003040102 604800 86400 2419200 604800
foo.org. 604800 IN NS ns1.foo.org.
ns1.foo.org. 604800 IN A 192.168.90.100

;; SERVER: 192.168.90.100#53(192.168.90.100)
;; WHEN: Tue Apr 8 23:30:05 2003

# Récupération de l'enregistrement SOA d'une zone
root@knoppix:/etc/bind# dig soa foo.org
; <<>> DiG 9.2.1 <<>> soa foo.org

;; Got answer:
;; flags: qr aa rd ra; QUERY:1, ANSWER:1, AUTHORITY:1, ADDITIONAL:1
;foo.org. IN SOA
;; ANSWER SECTION:
foo.org. 604800 IN SOA ns1.foo.org. \

root.ns1.foo.org. 2003040102 604800 86400 2419200 604800
ns1.foo.org. 604800 IN A 192.168.90.100

;; SERVER: 192.168.90.100#53(192.168.90.100)
;; WHEN: Tue Apr 8 23:30:43 2003
#Vérification de la résolution de nom sur www.foo.org
root@knoppix:/etc/bind# dig www.foo.org
; <<>> DiG 9.2.1 <<>> www.foo.org

;; Got answer:
;www.foo.org. IN A
;; ANSWER SECTION:
www.foo.org. 604800 IN CNAME ns1.foo.org.
ns1.foo.org. 604800 IN A 192.168.90.100

;; SERVER: 192.168.90.100#53(192.168.90.100)
;; WHEN: Tue Apr 8 23:31:49 2003
# Vérification de la résolution de nom inverse.
root@ns1:/etc/bind# dig ptr 100.90.168.192.in-addr.arpa

; <<>> DiG 9.2.1 <<>> ptr 100.90.168.192.in-addr.arpa

;; Got answer:
;100.90.168.192.in-addr.arpa. IN PTR
;; ANSWER SECTION:
100.90.168.192.in-addr.arpa. \
604800 IN PTR ns1.90.168.192.in-addr.arpa.
90.168.192.in-addr.arpa. \
604800 IN NS ns1.90.168.192.in-addr.arpa.

;; SERVER: 192.168.90.100#53(192.168.90.100)
;; WHEN: Tue Apr 8 23:45:39 2003
Le cache du DNS
Le cache permet également de détecter certaines causes d'erreurs. Le problème est qu'il est en
mémoire. Pour le récupérer sous la forme d'un fichier utilisez la commande kill -INT PID de
named. Vous récupérez un fichier /var/named/named_dump.db que vous pouvez exploiter.
Les journaux
Si vous êtes en phase de configuration, pensez (ce doit être un réflexe) à consulter les fichiers de
journalisation, notamment /var/log/messages. Cette opération permet dans bien des cas de
corriger des erreurs qui se trouvent dans les fichiers de configuration. Voici comment procéder :
 Arrêt du serveur
 Nettoyage du fichier > /var/log/messages
 Démarrage du serveur
 Consultation des logs : cat /var/log/daemon.log | more
Pour les fichiers logs, utilisez, si le fichier est trop gros la commande tail :
# tail -N NomFichier
# Affiche les N dernières lignes d'un fichier
# Par exemple, affiche les 250 dernières lignes d'un fichiers
# tail -n 250 /var/log/daemon.log | more
Remarques
Si vous désirez mettre en place la résolution de noms sur un réseau local, il n'y a pas grand chose de plus à
réaliser. Il faut rajouter les enregistrements de type MX pour la messagerie, cette opération sera réalisée
pendant la configuration du service de messagerie. Il faut également mettre en place un service de
synchronisation des bases de données avec un serveur secondaire pour assurer le service d'un serveur de
noms de backup.

Si vous désirez vous relier sur internet, le processus est plus complexe. Il faudra approfondir la description
des enregistrements et la structure des fichiers.
Par convention, on considère que chaque domaine dispose d'au moins 1 serveur de noms primaire et un
serveur de noms secondaire afin d'assurer une redondance en cas de panne d'un serveur. Les clients réseau
seront configurés pour utiliser indifféremment le serveur de noms primaire ou les serveurs de nom
secondaires. Il en résulte une duplication de la base de données du DNS primaire sur les serveurs
secondaires. La base de données est rafraîchie en fonction des paramètres de l'enregistrement SOA. Ce
procédé met en oeuvre un principe de base de données répartie. Vous trouverez quelques éléments dans les
annexes qui suivent.
Annexes
Les extraits ci-dessous d'une zone fictive foo.org peuvent servir d'exemple pour bâtir une zone.
Si on respecte les conventions utilisées sur internet, voici ce que l'on devrait avoir :
 le serveur ftp est accessible par l'adresse ftp.foo.org

 le serveur http par l'adresse www.foo.org
 le serveur de noms primaire par ns1.foo.org
 le serveur de messagerie mail.foo.org
 le serveur de news news.foo.org, etc.
ftp, www, mail sont des alias (canonical name ou CNAME) de la machine ns1 dans le domaine
foo.org
Nous aurons donc sur le serveur de noms 5 enregistrements dans la zone foo.org qui concernent
la machine ns1.foo.org : un enregistrement de type A pour déclarer ns1 quatre enregistrements
de type CNAME pour la machine ns1.
Nous aurons également, dans la zone reverse in-addr.arpa, 1 enregistrement de type pointeur
(PTR) pour chaque enregistrement de type A dans la zone directe. Enfin, pour le serveur de
messagerie, il faut également un enregistrement de type MX.
Tous les fichiers concernant la zone locale, et un fichier named.conf sont déjà installés sur votre
machine.
; db.local
; Résolution directe pour la zone locale
; BIND data file for local loopback interface
;
$TTL 604800
@ IN SOA localhost. root.localhost. (
1 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire

604800 ) ; Negative Cache TTL
;
@ IN NS localhost.
@ IN A 127.0.0.1
; db.127
; Résolution inverse pour l'adresse de loopback
; BIND reverse data file for local loopback interface
;
$TTL 604800
1 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
;
@ IN NS localhost.
1.0.0 IN PTR localhost.
; db.0
; Résolution inverse pour la zone de broadcast
; BIND reverse data file for broadcast zone
;
$TTL 604800
1 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
;
@ IN NS localhost.
; db.255
; Résolution inverse pour la zone de broadcast;
; BIND reverse data file for broadcast zone
;
$TTL 604800
1 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
;
@ IN NS localhost.
; db.root
; fichier des serveurs de noms de l'internet
; vous pouvez le consulter sur votre disque.

; db.foo.org
; fichier directe pour la zone foo.org
;
$TTL 604800
@ IN SOA ns1 root.ns1 (
2003040102 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
;
@ IN NS ns1
ns1 IN A 192.168.90.100 ; @ ip du serveur de nom
www IN CNAME ns1
ftp IN CNAME ns1
; db.foo.org.rev
; fichier de résolution inverse pour la zone foo
;
$TTL 604800
@ IN SOA ns1 root.ns1 (
2003040102 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
;
@ IN NS ns1
100 IN PTR ns1
; fichier named.conf du serveur primaire

// C'est le fichier principal de configuration des DNS
// C'est ici que sont réalisées, pour chaque zone, les déclarations
// des fichiers de ressources.
options {
directory "/var/cache/bind";
// Serveurs à prévenir pour les transferts de zone
forwarders {0.0.0.0;};
};
// Ici les paramètres pour les clés rndc

// Les paramètres doivent être strictement identiques à celui
// du fichier rndc.key ou rndc.conf
// Si vous avez des messages d'erreur à l'utilisation
// de cette commande, vérifier le contenu des fichiers.
key "rndc-key" {
algorithm hmac-md5;
secret "c3Ryb25nIGVub3VnaCBmb3IgYSBtYW4gYnV0IG1hZGUgZm9yIGEgd29tYW4K";
};
# Autorisations rndc sur la machine.

controls {
inet 127.0.0.1 allow {localhost;} keys {"rndc-key";};
};

// Indication pour les serveurs racines
zone "." {
type hint;
file "/etc/bind/db.root";
};
// be authoritative for the localhost forward

// and reverse zones, and for
// broadcast zones as per RFC 1912
zone "localhost" {
type master;
file "/etc/bind/db.local";
};
zone "127.in-addr.arpa" {
type master;
file "/etc/bind/db.127";
};
type master;
};
type master;
};
//zone directe de foo

zone "foo.org" {
type master;
file "/etc/bind/db.foo.org";
};
//Zone reverse pour 192.168.90.

zone "90.168.192.in-addr.arpa" {
type master;
file "/etc/bind/db.foo.org.rev";
};
; fichier name.conf du serveur secondaire

; L'entête de bouge pas
; Tout ce qui concerne localhost non plus car chaque DNS
; est primaire pour les zones locales
; on ajoute la déclaration des autres zones, le fichier
; de stockage et l'adresse IP du serveur primaire pour
; pouvoir réaliser les transferts de zone.
; Déclaration de la zone foo.org
zone "foo.org" {
type slave;
file "/etc/bind/db.foo.org";
masters {192.168.90.1;};
};
type slave;

file "/etc/bind/db.foo.org.rev";
masters {192.168.90.1;};
};
; fichier rndc.conf
/* $Id: cours-dns.xml,v 1.10 2004/12/29 18:55:06 jaazzouz Exp $ */
/*
* Exemple de fichier de rndc.conf, pris pour les TP
*/
options {
default-key "rndc-key";
};
server localhost {
key "rndc-key";
};
key "rndc-key" {
algorithm hmac-md5;
secret "c3Ryb25nIGVub3VnaCBmb3IgYSBtYW4gYnV0IG1hZGUgZm9yIGEgd29tYW4K";
};
; fichier rndc.key
key "rndc-key" {
algorithm hmac-md5;
secret "49khYQyHfO4AqYO9K7by6Q==";
};
Pour configurer le serveur secondaire, vous n'avez pas grand chose à faire. Copiez le fichier
named.conf du primaire sur le secondaire. Voyez l'exemple ci-dessus. Le dns secondaire
téléchargera (processus de transfert de zone) les fichiers de ressources du dns primaire.
Attention, le dns secondaire pour une zone est toujours dns primaire pour la zone locale
localhost.
On remplace la définition masters par slave sauf pour la zone locale et les fichiers db.local et
db.127 qui sont lus localement. Ensuite vous avez rajouté l'adresse du serveur à partir duquel le
transfert de zone doit s'effectuer.
Activer les serveurs de noms et analyser les traces (log) sur les 2 serveurs. Corrigez toutes les
erreurs jusqu'à ce que cela fonctionne. Vous devriez obtenir la trace selon laquelle il y a eu un
transfert de zone entre le serveur maître et le serveur esclave. Exemple :
Apr 6 plibre named[8821]: send AXFR query 0 to 195.115.88.38
Expérience 1 :Vous pouvez expérimenter un échange entre un serveur de noms primaire et un

serveur esclave. Modifiez sur le serveur primaire le N° de série comme si vous aviez modifié les
fichiers de ressources de ns1 et relancez le service. Vérifiez le transfert de zone a mis à jour la
base de données répartie.

Expérience 2 : Vous pouvez expérimenter une autre procédure d'échange, mais cette fois sans
relancer le serveur de noms secondaire. Modifiez d'abord sur les deux serveurs le délai de
rafraîchissement et mettez le à 2 ou 3 minute. Relancez les services. Modifiez sur le serveur
primaire le N° de série dans l'enregistrement SOA, comme si vous aviez modifié les fichiers de
ressources de ns1 et relancez le service. Si vous attendez, vous verrez la synchronisation
s'opérer (trace dans les fichiers de logs). Vous découvrez ainsi le mode de fonctionnement de
synchronisation des serveurs de noms sur internet.
Remarque : si vous voulez, sur ces serveurs assurer la gestion de plusieurs domaines, il suffit de
rajouter les définitions de ressources pour ces domaines, puis de déclarer ces zones dans
/etc/named.conf.
Notez également que la notion d'autorité est différente de la notion de serveur maître ou serveur
esclave. En effet si vous avez en charge la gestion de deux zones (Z1 et Z2), vous pouvez mettre
deux serveurs ayant autorité sur ces zones (ns1 et ns2), par contre ns1 peut être serveur maître
pour Z1 et secondaire pour Z2, et ns2 peut être serveur maître pour Z2 et esclave pour Z1.
Prenons l'exemple d'une zone sd d'adresse 192.168.254.0, rattachée à foo.org. Nous allons
mettre en place une délégation de zone pour sd. La résolution des noms de la zone sd.foo.org
est prise en charge par les serveurs de noms de la zone sd, nous n'avons donc pas à nous en
occuper. Par contre nous devons déclarer ces serveurs afin de maintenir la cohérence de la
hiérarchie.
Configuration de la délégation : sur le serveur de noms de la zone foo.org il faut rajouter les
enregistrements qui décrivent les serveurs de noms de la zone sd.foo.org dans le fichier de zone
db.foo.org.
sd 86400 NS ns1.sd.foo.org.
86400 NS ns2.sd.foo.org.
Et les enregistrements qui déterminent les adresses de ces serveurs de noms.
ns1.sd.foo.org. IN A 192.168.254.1
ns2.sd.foo.org. IN A 192.168.254.2
La délégation de la zone in-addr.arpa : Dans la pratique, cette délégation est différente car la zone
inverse ne dépend pas de la zone supérieure, mais d'une autre entité (in-addr). Le processus est
donc un peu différent.
Pourquoi ? parce que cette zone reverse est gérée par l'entité qui gère l'espace 192.168.0 à
192.168.255 et il est fort probable que ce n'est pas la zone foo qui assure la résolution inverse
pour tous les réseaux compris entre 192.168.0 et 192.168.255.
Ceci dit, cela n'empêche pas de réaliser cela sur une maquette. Il est possible de mettre en place
cette résolution inverse. Nous allons donc considérer que la zone foo.org assure la résolution de
noms inverse du réseau 192.168.254. Ce reviendrait à considérer que dans la réalité, la zone sd
serait un sous domaine de foo. La configuration ici est simple, les masques de sous-réseaux
utilisés ici sont ceux par défaut (255.255.255.0) pour la classe C. Le principe pour la zone inverse
est identique à celui de la zone directe. Il suffit de rajouter dans le fichier db.0.168.192 les
enregistrements suivants :
sd.foo.org. IN NS ns1.sd.foo.org.

IN NS ns2.sd.foo.org.
1.0.168.192.in-addr.arpa 86400 IN PTR ns1.sd.foo.org.
2.0.168.192.in-addr.arpa 86400 IN PTR ns2.sd.foo.org.
http://www.dnsreport.com/tools/dnsreport.ch Le plus complet pour les tests. Il explique assez bien

les problèmes et les modifications à faire pour les résoudre. Avec le serveur eclis, on peut arriver
à n'avoir que 2 warnings: "Multiple MX records" et "Mail server host name in greeting" qui
correspondent respectivement au fait que l'on a pas de serveur de mail de secours et que l'on fait
du virtual hosting. Note: ce test utilise un des root name serveur au hasard. Il faut faire le test
plusieurs fois pour avoir un aperçu complet de la situation.
http://www.zonecut.net/dns/ Affiche la situation vue depuis un root name serveur pris au hasard et
ce avec une jolie représentation graphique. Là aussi il faut tester plusieurs fois pour avoir un
aperçu complet. Les quelques lignes de résumé à la fin sont intéressantes.
http://www.squish.net/dnscheck/dnscheck.cgi Le seul qui fait un test exhaustif de tout les root

name serveur et qui fait un résumé pertinent à la fin. Il est un peut lent mais ça va finalement plus
vite que de tester 10 fois les autres outils pour passer en revue tout les root name serveurs... ça
démontre bien, avec des probabilités en pouces, pourquoi on obtient pas toujours les mêmes
résultats quand il y a un problème avec les DNS.
Chapter 31. Travaux dirigés : installation du service DNS
Table of Contents
Vous utilisez deux machines M1 et M2.
M1 sera serveur primaire de votre zone, il est également serveur HTTP, serveur FTP, serveur de
messagerie et serveur de news.
M2 sera client de M1 pour les trois premières parties du TP et serveur secondaire pour la
quatrième partie.
Vous prendrez l'adresse de réseau 192.168.x.0. x est variable pour chacun des binômes du
groupe. La valeur sera donnée par votre enseignant. Vous remplacerez x par la valeur fournie tout
au long de ce document (TD et TP).
Votre domaine est couleur ou couleur est une variable que vous donnera votre enseignant.
Couleur prendra une des valeurs rouge, vert, bleu...
On considère que M1 est serveur web, serveur ftp, serveur de messagerie et serveur de news.
Voici les noms qui sont assignés :

 Serveur de noms primaire : ns1
 Serveur HTTP : www
 Serveur ftp : ftp
 Serveur de noms secondaire : ns2
 Serveur de mail : mail
 Serveur de news : news
Rédigez les éléments des fichiers named.conf des serveurs primaires et secondaires de votre
zone. Vous rédigerez également les fichiers de ressources de la zone couleur.org.
Vous utiliserez les documents fournis dans la fiche de cours et en annexe.
Chapter 32. Travaux pratiques : installation du service DNS
Table of Contents
Présentation
Présentation
Vous utilisez deux machines M1 et M2. Le TP comporte quatre parties.
1. Première partie : préparation de votre environnement réseau client et serveur

2. Deuxième partie : configuration de la résolution de noms pour la zone directe :
M1 sera serveur de noms
M2 sera client de M1
Test de la configuration à l'aide des commandes ping, et de requêtes ftp, http
3. Troisième partie : configuration de la résolution de noms pour la zone reverse
Test de la configuration à l'aide de dig

4. Quatrième partie : mise en place du serveur secondaire, modification de l'enregistrement
SOA du serveur primaire
5. Test du transfert de zone
Vous utiliserez les documents réalisés en TD.
Ouvrez une session et passez administrateur
Renommez sur les deux machines les fichiers /etc/hosts (mv /etc/hosts /etc/hosts.original)
afin d'éviter les effets de bords sur la résolution de noms.
Vérifiez que vous avez bien les fichiers de configuration de la zone locale, sinon vous devez
commencer par là. Vous compléterez ensuite la configuration pour votre zone. Faites une copie
de sauvegarde de ces fichiers.
 /etc/bind/named.conf (fichier de configuration du serveur de noms primaire),

 /etc/bind/db.couleur.org qui contiendra la description de la correspondance nom-
adresse de toutes les machines de votre zone.
 /var/db.couleur.org.rev qui contiendra la correspondance inverse adresse-nom (pour la

résolution inverse de nom in-addr.arpa).
Vérifiez et validez la configuration des clés de rndc.conf et named.conf.
Faites la configuration du serveur (fichiers named.conf, ressources, rndc).
Démarrer le serveur.
Vérifier le bon fonctionnement (traces dans les journaux, processus) de named et rndc.
Corrigez tant qu'il y a des erreurs.
 Les services clients de M1 et M2 doivent être configurés pour utiliser le service de

résolution de noms.
 Modifiez sur les deux machines le fichier /etc/resolv.conf.

 Relancez le service réseau.
 Testez la configuration
 Vérifiez que la résolution de noms fonctionne sur :
www.couleur.org
ftp.couleur.org
mail.couleur.org ....
 Corrigez tant que cela ne fonctionne pas.

 Vérifiez à 'aide la commande ping, de requêtes FTP ou HTTP à partir d'un client, que le
serveur de noms retourne bien les enregistrements.
Vérifiez à l'aide la commande dig, que le serveur répond bien sur différents types de
requêtes (dig any, dig www, dig soa).
Configurez à l'aide des fichiers fournis en annexe, la zone inverse (reverse). Ceci consiste à
rajouter une déclaration dans le fichier named.conf. Créez le fichier de ressource correspondant.
Relancez le service named, vérifiez les journaux, corrigez les éventuelles erreurs.
Vérifiez à l'aide de dig que les requêtes de type dig ptr fonctionnent.
Sur M2 vérifiez que vous avez bine les fichiers de déclaration pour la zone locale. Ajoutez et
déclarez les zones directe et inverses pour votre zone.
Activez le serveur secondaire, vérifiez que le service est actif et vérifiez également dans les
journaux qu'il n'y a pas d'erreurs.
Vous devez avoir dans /var/log/daemon, une trace qui confirme le transfert de zone.
N'allez pas plus loin tant que cela n'est pas en parfait état de fonctionnement.
Arrêtez sur le serveur primaire le service named.
Configurez un client pour qu'il puisse utiliser aussi bien le serveur primaire que le serveur
secondaire. Ajouter pour cela un enregistrement de déclaration du serveur secondaire sur le
client.

Testez le fonctionnement du serveur secondaire, à partir d'un client, en utilisant des requêtes sur
www.couleur.org ou ftp.couleur.org.
C'est le serveur secondaire qui doit répondre, le serveur primaire étant inactif.
Vérifier cela avec la commande dig.
Modifiez au minimum le temps de rafraîchissement des enregistrements du serveur Primaire. (2

ou 3 mn). Modifiez également le N° de série. Relancez le serveur primaire et vérifiez dans les logs
que le transfert de zone s'effectue bien.
Faites une modification sur votre fichier de ressources db.couleur.org et modifiez le N° de série.
Attendez quelques minutes, vous devriez trouver une trace de synchronisation des bases de
données des serveurs, sans avoir eu besoin de relancer aucun serveur.
Chapter 33. Installation d'un serveur NFS
Le partage de fichiers pour les clients Unix
Table of Contents
Résumé
Résumé
Pourquoi un service NFS alors que celui-ci est très peu utilisé sur les environnements Windows et
qu'il n'existe à ma connaissance pas de produits libres client ou serveur pour Windows. Pour deux
raisons :
La première est que le service NFS est très largement employé dans les environnement
Unix/Linux. Si vous avez des machines sous Linux vous utiliserez NFS. Il est donc nécessaire de
connaître les procédures de configuration et d'utilisation de ce service.
La deuxième concerne Windows. Vous aurez sans doute un jour envie ou besoin d'installer le
produit Windows Services For Unix (WSFU) de Microsoft. Ce produit disponible déjà sous

Windows NT4 Server et mis à jour pour Windows 2000, offre de nombreux outils d'administration
de type Unix pour Windows, dont un service NFS.
Nous allons voir, dans un environnement Linux, comment utiliser le service NFS.
Sur une debian, et donc sur la Freeduc-Sup, vous pouvez installer les outils nécessaires sur un
serveur grâce à apt-get.
Sur le serveur, il faut installer portmap, nfs-common, et nfs-kernel-server.
apt-get install portmap nfs-common nfs-kernel-server
Sur le client, il est faut installer nfs-common et portmat.
apt-get install portmap nfs-common
En ce qui concerne les sécurités, sachez que NFS utilise le wrapper tcp (tcpd). Il est possible de
configurer la sécurité via les fichiers /etc/hosts.allow et /etc/hosts.deny. Les protocoles à
ouvrir sur le serveur sont statd, nfsd, lockd, rquotad et mountd. Sur le client, il faut permettre à
statd d'accèder à localhost.
Vous pouvez activer NFS par la commande /etc/init.d/nfs-kernel-server start. Il vous

faudra au préalable avoir défini les ressources à partager (exporter).
Les programmes sur lequel s'appuie le service NFS utilisent les RPC (Remote Procedure Call). Ils
s'inscrivent donc auprès du service portmap qui met à jour sa table de service rpc. Voici un extrait
de ce que donne la commande rpcinfo -p
program vers proto port

100000 2 tcp 111 portmapper
100000 2 udp 111 portmapper
100003 2 udp 2049 nfs
100003 3 udp 2049 nfs
100003 2 tcp 2049 nfs
100003 3 tcp 2049 nfs
100021 1 udp 33065 nlockmgr
100021 1 tcp 38399 nlockmgr
100005 1 udp 967 mountd
100005 1 tcp 970 mountd
100005 2 udp 967 mountd
100005 2 tcp 970 mountd
100005 3 udp 967 mountd
100005 3 tcp 970 mountd
Voici maintenant les processus qui doivent être actifs sur le serveur NFS.
portmap gére le catalogue des programmes RPC,

mountd est chargé des opérations de montage/démontage d'arborescence,
nfsd exécute les primitives d'accès aux fichiers - requêtes émanant des clients.
/etc/exports décrit ce que le serveur exporte, vers quelles machines le serveur exporte, avec
quelles autorisations. Il s'agit d'un fichier texte, qui est éditable avec n'importe quel éditeur. Il
centralise la liste de l'ensemble des ressources offertes par cette machine. Notez cependant que
le nom de partage est automatiquement celui de la ressource (on ne peut pas partager sous un
autre nom), et qu'enfin, on peut ponctuellement partager une ressource sans passer par ce fichier
(à la volée : voir exportfs).
Exemple de fichier /etc/exports :
# Ressource Options Liste_de_Clients

# Exporte /tmp vers la machine "cli" avec possibilité Read Write (rw)
# rw est l'option par défaut
/tmp cli(rw)
#Exporte "/tmp" en lecture seule vers toutes les machines du réseau
/tmp *(ro)
Il n'y a pas de fichier particulier. Il suffit que les programmes soient installés (portmap et nfs-
common). Pensez à lancer le portmap, sinon le montage restera en attente.
/etc/init.d/portmap start
Les répertoires exportés par un serveur peuvent être “ montés ” manuellement ou à la demande.
Nous verrons comment configurer un fichier sur le poste client, afin qu'un dossier soit “ monté ”
automatiquement au démarrage du client. Il s'agit dans ce cas de l'utilisation permanente de la
ressource.
Prenons la configuration précédente ( fichier /etc/exports ci-dessus)
Le client cli1 monte (importe) /tmp de ns1 sur le répertoire local /tempo en utilisant la commande
suivante
$mount -t nfs ns1:/tmp /tempo. -t indique le type de SGF - arborescence NFS -
Une fois montée, l'accès à la ressource est transparent.
En fin d'utilisation, le client démonte l'arborescence /tmp en utilisant la commande $umount /tempo
A chaque opération de montage ou démontage, le fichier local /etc/mtab est mis à jour. Il contient
la liste des systèmes de fichiers montés (arborescence NFS ou non).
Attention : NFS utilise un cache. Si vous ne voulez pas perdre de données, utiliser une procédure
de “ démontage ” des disques ou alors un “ shutdown ” du poste client. Dans les autres cas, vous
risquez de perdre les informations logées en cache.

Vérifiez que le noyau supporte le système de fichiers nfs:
Utilisez la commande more /proc/filesystems, voici ce que vous pouvez obtenir.
nodev pipefs
ext2
nodev ramfs
msdos
vfat
iso9660
nodev usbfs
nodev nfs
Le système de fichiers nfs doit apparaître. S'il n'apparaît pas, c'est que le système n'est pas
compilé avec le support de NFS, ou alors il est compilé pour le charger comme un module. Si c'est
le cas, vous pouvez charger le module avec la commande :
insmod nfs
ou encore
modprobe nfs
Le module doit apparaître avec la commande lsmod, et le fichier /proc/filesystems est

normalemnt modifié (insmod force l'insertion d'un module dans le noyau, un module pouvant étre
un pilote de périphérique par exemple, ou des fonctionnalités de la machine. Modprobe insert le
module avec autodétection, afin de vous rendre compte de son bon fonctionnement, ou en
donnant les bons paramètres. Lsmod liste les modules présents dans votre noyau, et rmmod
permet la suppression d'un module présent dans le noyau).
Le fichier /etc/exports
Ce fichier est utilisé par les daemons pour déterminer les volumes qui seront exportés
(accessibles), et quels seront les permissions à accorder sur ces volumes. Il existe autant de
lignes que de points de montage. La structure d'une ligne est de la forme :
PointDeMontage client1(option) clientn(option)
- PointDeMontage est le volume local à exporter,
- Client1 ... Clientn définissent les ordinateurs qui ont le droit d'accéder au volume exporté,
- Option: définit le type d'accès et les permissions.
Exemple de fichier avec la commande more /etc/exports
/tmp *.archinet.edu(rw)
/usr/local/man *.archinet.edu(ro)
Le dossier /tmp est exporté en lecture et écriture pour tous les ordinateurs du domaine
archinet.edu. Le dossier /usr/local/man en lecture uniquement.
Voici quelques options de montage, utiliser man exports pour avoir la liste exhaustive :

Secure : requiert une authentification
Insecure : ne requiert pas d'authentification
ro | rw : lecture uniquement ou lecture écriture
Noaccess : permet d'exclure une partie de l'arborescence pour des clients donnés
Voici un extrait de la page de manuel :
Exemple
# fichier /etc/exports d'exemple

/ maître(rw) confiance(rw,no_root_squash)
/projects proj*.local.domain(rw)
/usr *.local.domain(ro) @trusted(rw)
/home/joe pc001(rw,all_squash,anonuid=150,anongid=100)
/pub (ro,insecure,all_squash)
Commentaire :
La première ligne exporte l'ensemble du système de fichiers vers les machines maître et
confiance. En plus des droits d'écriture, toute conversion d'UID est abandonnée pour l'hôte
confiance.
La deuxième et la troisième ligne montrent des exemples de noms d'hôtes génériques, et de

sous-réseaux (`@trusted').
La quatrième ligne montre une entrée pour le client PC/NFS présenté plus haut.
La dernière ligne exporte un répertoire public de FTP, à tous les hôtes dans le monde, en
effectuant les requêtes sous le compte anonyme. L'option insecure permet l'accès aux clients
dont l'implémentation NFS n'utilise pas un port réservé.
L'identité des utilisateurs
Un des problèmes de NFS va être la gestion des utilisateurs et de leurs droits. Le serveur NFS va
tenter d'identifier les users de la machine cliente par rapport au système habituel d'authentification
de la machine. Tant que le client et le serveur ne se mettent pas d'accord sur une base commune
d'identification, les confusions, voire les attaques, sont possibles. En effet, comment gérer les
droits de l'utilisateur Pierre qui vient de la machine client Pluton si notre serveur ne connait aucun
utilisateur Pierre ? Et d'abord, comment sait on quel utilisateur est connecté ?
La réponse est simple : par son id. Or, si on a deux systèmes d'authentification différents et
autonomes (par exemple, par /etc/passswd, sur chacune des machines), qui dit que l'id de Pierre
sur la machine cliente ne sera pas celle de Paul sur la machine serveur ?
En fait, c'est encore pire : Si on ne met pas un système commun d'identification (et pour être sur,
d'authentification), on est certain de confondre les utilisateurs. DE MANIERE GENERAL, IL VAUT
MIEUX UTILISER NFS DANS UN ENVIRONNEMENT DE CONFIANCE
NFS offre de commandes qui permettent de manipuler les identifiants des utilisateurs afin de plier
ceux-ci à notre système de sécurité (contrôle et modification des identifiants donnés par les
clients).

Programmes client
Comme vu plus haut, n'oubiez pas d'avoir portmap actif sur votre client. Les programmes clients
à utiliser sont : mount et showmount
Le fichier /etc/fstab
Ce fichier contient une table des volumes montés sur le système. Il est utilisé par les daemons
mount, umount, fsck. Les volumes déclarés sont montés au démarrage du système. Voici un
extrait de fichier :
Exemple
/dev/hda1 / ext2 defaults 1 1

/dev/hda2 swap swap defaults 0 0
/dev/fd0 /mnt/floppy ext2 noauto 0 0
/dev/cdrom /mnt/cdrom iso9660 user,noauto,ro 0 0
ns1:/usr/local/man /doc nfs rsize=8192,wsize=8192,timeo=14,intr
La dernière ligne indique que le volume /usr/local/man, situé sur le serveur ns1, et qui contient
les pages du manuel est un volume nfs, monté sous le nom de local de /doc.
Ce fichier évite d'avoir à “ monter ” manuellement des systèmes de fichiers ou d'avoir à indiquer
les points de montage, bien que cela puisse s'avérer parfois nécessaire (utilisation ponctuelle
d'une ressource...). L'option auto permet de préciser si le montage doit etre fait automatiquement
au démarrage de la machine. L'option noauto permet d'indiquer le montage tel qu'il doit être fait,
lors d'une demande manuelle de montage (pratique pour les disquettes, CD et autres lecteurs
amovibles).
Montage manuel de système de fichiers
La commande souvent utilisée est de la forme mount -t TypeDeSGF NomDeMontage VolumeMonté.
Vous pourrez avoir toutes les options avec la commande man mount ou une aide plus brève avec
mount --help.
Exemple de montage : mount -t nfs ns1:/usr/local/man /doc.
La forme standard de la commande mount est mount -t type périphérique répertoire avec :
Type : type de sgf (fat, vfat, nfs, ext2, minix....) pour nous c'est nfs
Périphérique : nom du fichier exporté sous la forme NomServeur:NomDossierExporté
Répertoire : nom du répertoire local de montage/
Le type de fichier que vous montez est de type nfs, vous utiliserez l'exemple de la commande ci-
dessous :
mount -t nfs serveurNFS:/usr/share/doc /mnt/doc

Commentaire : la ligne de commande monte le répertoire exporté /usr/share/doc du serveur
serveurNFS, sur le répertoire local du client /mnt/doc.
Le mtab est modifié chaque fois que l'utilisateur “ monte ” ou “ démonte ” un système de fichiers.
Le système tient à jour une table des volumes montés.
Attention, l'accès à la commande mount n'est, par défaut, autorisée que pour root.
Il faut rajouter l'option user dans le fichier /etc/fstab, afin qu'un autre utilisateur puisse accéder à
cette commande.
Exemple : /dev/cdrom /mnt/cdrom iso9660 noauto,ro
devient /dev/cdrom /mnt/cdrom iso9660 user,noauto,ro
La prise en compte des modifications est dynamique.
La commande mount sans paramètres donne la liste des volumes montés. La commande
consulte la table maintenue à jour dans le fichier mtab.
La commande showmount
Cette commande permet d'interroger un hôte distant sur les services NFS qu'il offre, et notamment
les volumes qu'il exporte.
showmount -e AdresseIP_ou_NomIP lancée à partir d'un client nous affichera la liste des
ressources offertes par sAdresseIP_ou_NomIP (=serveur).
Sur le serveur, showmount -a nous affichera la liste des clients connectés sur chacune de nos
ressources.
De même, sur le serveur, la command showmount -e affiche le liste des partages en cours.
Autres commandes d'administration
rpcinfo : (par exemple rpcinfo -p consulte le catalogue des applications RPC (nfsd, mountd sont
des applicatifs RPC parmi d'autres).
nfsstat : fournit des statistiques d'utilisation de NFS.
La commande exportfs permet elle aussi d'obtenir la liste des partages en cours, de relancer le
service (pour la prise en compte d'éventuelles modifications du fichier /etc/exports, voir même
d'effectuer un partage à la volée (sans passer par /etc/exports).
exportfs -v affiche les partages en cours.
exportfs -r active les changements fait dans le fichier de configuration de partage NFS (il fait
relire le fichier /etc/exports par le programme serveur).
exportfs machine:/repertoire offre à la volée à machine (qui peut être aussi bien un nom de
machine qu'étoile, ou un réseau) le partage /repertoire. On peut passer des options avec -o.

Exemple
#exportfs -v
/tmp pluton(rw,root_squash)
#exportfs -o rw,no_root_squash 192.168.*:/opt/sav
#exportfs -v
/tmp pluton(rw,root_squash)
/opt/sav 192.168.*(rw,no_root_squash)
Chapter 34. Travaux pratiques : partages NFS
Table of Contents
Première partie
Deuxième partie
Troisième partie
Première partie
Vous allez configurer un service de partage de disque pour un client Unix. Vous serez, au cours
du TP, serveur pour un autre binôme puis client du serveur d'un autre binôme. Vous allez créer
deux répertoires partagés qui seront accessibles par le client :
 /tmp sur le serveur sera accessible en lecture/écriture

 /usr/share/doc sur le serveur sera accessible en lecture pour le client.
Ces répertoires seront montés respectivement sur les répertoires locaux /mnt/tempo et /mnt/doc
Vous pourrez utiliser les commandes man exports, man mount, man showmount, man fstab, man
rpcinfo.
1. Créez sur le serveur le fichier /etc/exports, et déclarez les répertoires exportés.
Activez le service portmap. Vérifiez qu'il est bien actif.
Voici un exemple de ce que vous pouvez obtenir avec rpcinfo -p :
program no_version protocole no_port

100000 2 tcp 111 portmapper
100000 2 udp 111 portmapper
100011 1 udp 725 rquotad
100011 2 udp 725 rquotad
100003 2 udp 2049 nfs
100005 1 udp 1026 mountd
100005 1 tcp 1047 mountd
100005 2 udp 1026 mountd
100005 2 tcp 1047 mountd
2. Vérifiez sur le serveur les fichiers exportés avec la commande showmount -e
Attention, si vous montez une arborescence sur un répertoire local, et que ce répertoire
contenait des fichiers, ces derniers seront masqués le temps du montage.

3. Créez sur le client les points de montage, montez les dossiers exportés du serveur et
testez les accès à partir du client.
4. Vérifiez les permissions d'accès lecture et lecture/écriture.
5. A partir du client, créez un fichier sur le fs (file system) accessible en écriture.
6. Ouvrez une autre session sur le serveur dans un autre terminal et essayez de démonter les
répertoire montés. Que se passe t-il, pourquoi ?
7. Vérifiez sur le serveur les fichiers exportés avec la commande showmount -a.
8. Démontez les systèmes de fichiers.
Deuxième partie
Le fichier /etc/fstab permet de déclarer tous les points de montage.
1. Editez et modifiez le fichier sur le client afin d'inclure les systèmes de fichiers nfs exportés
par le serveur. Utilisez l'exemple que vous avez dans /etc/fstab.
2. Rajoutez les lignes nécessaires en vous servant de l'exemple ci-dessous.
serveurNFS:/usr/share/doc /mnt/doc nfs user
3. Vérifiez que les modifications que vous avez apportées dans le fichier fstab fonctionnent.
4. Supprimez l'option user sur les lignes que vous avez mises dans le fichier fstab,
enregistrez. Essayez ensuite de monter l'arborescence en utilisant un compte autre que
“ root ”. Que se passe-t-il ?
5. Restaurez l'environnement.
Troisième partie
1. Créez un utilisateur Linus sur la machine client, et donnez lui l'UID 1100. Créez un
utilisateur Larry sur le serveur (UID 1100).
2. Réalisez un partage de /tmp sur le serveur, que le client montera dans /mnt.
3. Sur le client, Linus crée un fichier dans /mnt. Vérifiez son propriétaire
4. Sur le serveur, vérifiez le contenu du répertoire /tmp. A qui appartient le fichier crée ?
5. De façon théorique, pour quel utilisateur cela est il encore plus dangereux ? Quels sont les
UIDs que vous connaissez tous à l'avance ?
Consultez la page de man de exports (c'est un fichier de configuration, donc dans le

chapitre 5 : man 5 exports, et plus largement man man).

6. Dans un environnement de grande confiance, vous voulez donner le droit à un root distant
d'être reconnu comme root sur le partage. Comment faire ? Testez.
7. Interdisez ensuite seulement à root d'être confondu avec le root local, mais laissez les
autres utilisateurs être eux mêmes. Testezxi. (Ceci est le comportement par défaut).
8. Sachant que l'UID de l'utilisateur nobody, qui existe certainement sur votre machine, est
certainement 65534, trouvez une solution pour donner à toute personne se connectant
l'identité de nobody. Créez un nouvel utilisateur BillG sur votre client, en vérifiant bien que
son UID n'existe pas dans la sécurité locale du serveur.
9. Montez le répertoire partagé à partir du client, et testez la création et l'accès aux fichiers
avec les utilisateurs BillG,Linus, et root. Que remarquez vous ?
10. Comment faire pour que tous les utilisateurs soient transformés en nobody ? Testez.
11. Vous devez maintenant offrir un partage de /tmp, mais chaque machine qui se connectera
sur ce partage doit être différenciée (peu importe l'utilisateur de cette machine). On vous
propose de créer sur le serveur des utilisateurs client1, client2 et client3. Chaque machine
qui se connectera se verra affublée de chacun de ces comptes (tout utilisateur de la
machine client PC1 sera l'utilisateur client1 sur le serveur, tout utilisateur du pc client PC2
sera reconnu comme utilisateur client2 sur le serveur, et ainsi de suite. Créez le fichier
/etc/exports correspondant à ces contraintes. Testez, et validez votre solution.
Chapter 35. Installation d'un service de messagerie
Les protocoles SMTP, POP et IMAP - Fiche de cours
Table of Contents

Terminologie
MHS, MTA, UA, DUA
MIME
Pourquoi Postfix
L'Auteur
Semi résidence

PostOFFICE
Abstract
Comment installer un serveur SMTP, un client IMAP et un client POP3
La messagerie électronique est une application très importante et des plus utiles des réseaux.
Plus rapide et moins onéreuse que la plupart des autres moyens de communication (télécopie,
téléphone, courrier postal, coursier...) la messagerie électronique est un vecteur de plus en plus
important dans la communication aussi bien interne qu'externe. Dans l'univers des réseaux
TCP/IP, la messagerie SMTP (Simple Mail Transport Protocol) est de loin la plus utilisée,
notamment avec sendmail qui est le standard en matière de serveur SMTP sur les machines Unix.
Le logiciel libre Postfix est un gestionnaire de messagerie simple à configurer et conçu pour une
sécurité optimale. De plus il est peu gourmand en ressources système et constitue donc une
véritable alternative à Sendmail. Le choix de Postfix est légitime tant pour le traitement de flux
importants de messages que pour de petites installations.
L'objectif de ce cours est de préparer l'installation et la mise en exploitation de Postfix en lieu et

place de Sendmail.
Terminologie
MHS, MTA, UA, DUA
Le MHS (Message Handler System) est le système global de messagerie,
Le MTA (Message Transfert Agent est composé d'agents. Un agent de routage (sendmail, MS
eXchange...) et un agent de transport (SMTP, UUCP).
L'agent de routage a pour but d'acheminer le message, en fonction de l'adresse vers son
destinataire. Pour nous, avec l'environnement Linux, l'agent de routage est sendmail. L'agent de
transport reçoit un message et une direction. Il ne prend aucune décision sur la route à utiliser.
Pour nous, protocole de transport peut être SMTP ou UUCP. Le logiciel Sendmail assure les deux
fonctions de transport et de routage.

L'UA ou MUA, Message User Agent, est le programme utilisé par le client pour composer, envoyer
et recevoir les messages. Pour la composition et l'envoi des messages il existe des programmes
comme mail sous Linux. D'autres programmes sont utilisés comme Eudora, Netscape, kmail... On
appelle souvent l'UA un “ mailer local ” si on utilise des outils comme Eudora, Oulook, Mutt, Kmail,
ou un “ web mail ” si on utilise un navigateur comme Mozilla, Netscape ou Internet explorer pour
consulter sa messagerie. Ces outils utilisent des protocoles différents. Les protocoles utilisés sont
SMTP ou UUCP pour envoyer, et POP3, IMAP, POP3s, IMAPs pour recevoir.
Il existe également un agent (DUA - Delivery User Agent) pour la remise physique du courrier
entrant dans la boîte aux lettres de l'utilisateur (BAL). Sur Linux nous utilisons procmail. Cette
remise locale (local delivery) est réalisé par un agent (mail, procmail...) dans des boîtes aux lettres
(mailbox) pour mémorisation, (/var/mail/dupont, /var/spool/mail/dupond).
Figure 35.1. Message Handler System
Sendmail est le routeur de courrier depuis 1982. Il répond aux préconisations de la RFC 822. En
1993, né le standard MIME - RFC 1521 (Multipurpose Internet Mail Extensions), puis en 1994 les
extensions du service SMTP (RFC 1652, 1869) pour le transfert caractères 8 bits.

MIME
Le but de MIME est de standardiser les méthodes de transfert de données 8 bits, structurer le
corps du message en contenus (body-parts), standardiser les différents contenus possibles. Un
en-tête est rajouté à ceux définis dans le RFC 822 : Mime-version:1.0
Le standard MIME
MIME supporte plusieurs type d'encodage comme :
1. Texte 7 bits, US-ASCII

2. Quoted-Printable (Caractère non US-ASCII remplacé par une séquence =XY, XY étant le
code hexadécimal du caractère.)
3. Base 64 (Texte, image, son)
4. 8Bits (les lignes sont composées de caractères 8 bits, il faut préciser l'alphabet : iso-latin1)
5. Binary
La strucure d'un message MIME est standardisée par des en-têtes supplémentaires qui décrivent
la structure et le type de contenu (format des données) du message.
Exemple de déclaration décrivant la structure :
1. Multipart/mixed
2. Multipart/parallel (plusieurs parties avec affichage en parallèle.)
3. Multipart/digest (d'autres messages inclus dans le message)
4. Multipart/alternative (partie du message affichée suivant l'environnement du

correspondant.)
Exemple de déclaration décrivant le format des données
1. Text/plain : charset=iso-8859-1
2. Text/richtext
3. Image/gif
4. Image/jpeg
5. Audio/basic
6. Video/mpeg
7. Application/octet-stream : exemple word
8. Application/postscript
Exemple de message
From mascret Mon Mar 19 08:02:46 2001
Return-Path: <Marcel.Giry@unilim.fr>

Delivered-To: alix.mascret@beaupeyrat.com
Received: from limdns2.unilim.fr (limdns2.unilim.fr [164.81.1.5])
by pegase.beaupeyrat.com (Postfix) with ESMTP id AC04237B05
for <salvaco@beaupeyrat.com>; Mon, 19 Mar 2001 08:02:44 +0100 (CET)
Received: from pctest (modem8.unilim.fr [164.81.1.208])
by limdns2.unilim.fr (8.9.1a/jtpda-5.3.2) with ESMTP id IAA04253
; Mon, 19 Mar 2001 08:02:39 +0100
Message-Id: <4.2.0.58.20010319080303.00950a70@pop.unilim.fr>
X-Sender: xalan@pop.unilim.fr (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58
Date: Mon, 19 Mar 2001 08:05:13 +0100
To: salvaco@beaupeyrat.com,
xalan@univlim.fr
From: Ximian Alan <xalan@univlim.fr>
Subject: Controle IUT2
Mime-Version: 1.0
Content-Type: multipart/mixed;
boundary="=====================_811307==_"
Status: RO
X-Status: A
L'importance d'un bon UA
MIME permet l'utilisation de plusieurs types de données (text, audion compressés...) et plusieurs
format (rtf, doc, gz, zip...). Il est important de posséder un UA de bonne qualité.
1. Reconnaître et afficher du texte US-ASCII,

2. Reconnaître les autres jeux de caractères et permettre de sauvegarder les contenus non
reconnus dans un fichier pour traitement ultérieur
3. Reconnaître et afficher les contenus de type message/RFC822
4. Reconnaître le type Multipart/mixed
5. Reconnaître le type Multipart/alternative
6. Traiter les Multipart non reconnus comme Multipart/mixed
7. Décoder les contenus de Application/* si l'encodage quoted-printable ou base64 est utilisé,

puis offrir de sauver le résultat dans un fichier.
Pourquoi Postfix
Le serveur de messagerie standard sur les systèmes Unix est le serveur Sendmail. Sendmail a
fait ses preuves. L'inconvénient est son mode de configuration. Toutes les fonctions de
messagerie sont réalisées par un seul programme. Sa structure est dite monolithique et la
configuration (fichier sendmail.cf) en est d'autant plus compliquée. Ce phénomène s'accroit avec
l'amplification de l'utilisation du service de messagerie (augmentation de fréquence/volume) et
avec l'exposition aux tentatives de piratage des serveurs de messagerie. Il existe d'autres
serveurs de messagerie sur Unix (QMail, Z-mailer...) tous présentent des inconvénients au niveau
utilisation de la bande passante, inter-opérabilté, respect des RFC, facilité de configuration,
sécurité...
L'objectif de postfix est d'apporter une solution à ces différents problèmes.

1. bénéficier de l'expérience de sendmail

2. facile à administrer : ce qui est facile à comprendre est plus facile à sécuriser.
3. rapide et évolutif : le trafic SMTP de 1999 n'est pas celui de 1980. Il faut pouvoir faire un
logiciel supportant les sites énormes (ISP, Accès des grosses entreprises, ...)
4. compatibilité sendmail maximale
Il assure égalemetn un compatibilité et le support :
1. des MUA existants (pine,mutt,mail...)

2. des gestionnaires de liste (majordomo, sympa...)
3. des formats de boîte aux lettres (mh, mbox, qmail-dir, ...)
4. des agents d'acheminement local (procmail, deliver, cyrus...)
5. des configurations (UUCP, réécriture, mailertable, ...)
6. des utilisateurs (alias, .forward, ...)
7. des RFCs
L'Auteur
L'Auteur - Wietse Venema - est connu pour ses contributions à la sécurité et aux logiciels libres. Il
est également auteur de TCP_Wrapper et d'un portmap sécurisé. Il est co-auteur avec D. Farmer
de SATAN. Il travaille au Watson Research Center d'IBM.
Postfix est un logiciel libre. Le site officiel est www.postfix.org.
Postfix (voir bigpicture.gif) est architecturé autour d'un module de réception des messages (voir
inbound.gif) et de celui qui permet de délivrer ces messages (voir outbound.gif).
Figure 35.2. Architecture de Postfix
Figure 35.3. Réception des messages

Figure 35.4. Traitement des messages
Quand un message doit être traité par un système Postfix, le passage obligé est la file incoming.
Si le message est posté localement, il est déposé dans un répertoire en accès “ écriture possible
pour tout le monde ”. Le démon pickup le traitera à partir de là. Ce démon procède à une première
phase d'analyse des couriers (headers) afin de protéger le reste du système.
Si le message provient d'un réseau, le message est traité par un serveur SMTP. Certaines règles
de sécurité et de contrôles sont déjà effectuées.
Les messages peuvent être générés par Postfix lui même ou par un robot afin de prévénir
l'administrateur des erreurs, adresses introuvables, tentatives de violations des règles, problèmes
de protocoles...
Les messages peuvent être redistribués par des entrées dans les fichiers d'alias ou des fichiers
.forward.
Le démon cleanup représente la période finale de traitement d'un message, notamment la

vérification de l'entête du message (complétude user@fqdn), la réécriture d'adresse, le dépôt du
message dans la file incoming, l'avertissement du gestionnaire de liste.

Quand un message est arrivé dans la file incoming, l'étape suivante consiste à le délivrer. Ceci est
pris en charge par le gestionnaire de file qui est le coeur du système de Postfix. Il contacte un
agent (local, smtp, lmtp, pipe) chargé de délivrer les messages en lui communiquant des
paramètres (localisation du message, nom/adresse de l'emetteur, nom(s)/adresse(s) du/des
destinataires, machine hôte de destination...
Le gestionnaire de liste maintient une liste séparée pour les courriers ne pouvant être délivrés
immédiatement (deferred).
Les messages ne pouvant être définitivement délivrés (bounces) génèrent une trace d'information
dans les journaux.
Sur Linux, l'agent de traitement local des messages est le plus souvent procmail. Il doit pouvoir
traiter des structures de boîtes aux lettres conformes au standard Unix, utiliser les aliases, les
redirections .forward...
L'agent de traitement pour l'acheminement distant des messages s'appuie sur le protocole SMTP
et utilise le port 25.
Les différents démons sont activés “ à la demande ” par un super serveur (master daemon) un
peu à la façon d'inetd.
Chaque grande fonction de postfix est prise en charge par un programme indépendant.
1. Lecture des messages locaux

2. Réception SMTP
3. Réécriture d'adresse
4. Envoi SMTP
5. Délivrance locale
6. Traitement des erreurs (bounces)
7. Gestion des files
Cette option présente plusieurs avantages.
1. Décomposition = programmes plus petits et plus lisibles

2. Plus difficile à casser ou circonvenir
3. Chroot plus facile
4. Les programmes ne se font pas confiance : isolation de chaque fonction

1. Portabilité aisée
2. Messages courts dans les sockets
3. Ne pas faire confiance aux données
Semi résidence
1. Les démons sont réutilisés et contrôlés par un super démon “ master ” qui les crée à la
demande.
2. Nombre maximum pour chaque fonction : contrôle précis du fonctionnement, sécurité
contre le “ déni de service ” (DOS)
3. Temps d'inactivité paramétrable
1. maildrop : messages locaux postés par sendmail

2. incoming : messages en cours de réécriture et de nettoyage
3. active : messages en cours ou en attente de transport
4. deferred : messages en attente
5. defer : arborescence d'attente (hachée pour éviter les trop gros répertoires -- problème
dans Sendmail)
Les outils d'administration et de maintenance sont dans /usr/sbin. Voici les principaux.
1. postalias sert à maintenir la base de données des alias

2. newaliases (/usr/bin) assure la compatibilité avec sendmail pour la base de donnes des
alias
3. postcat affiche le contenu des files d'attentes.
4. postconf affiche les paramètres de Postfix contenus dans fichier main.cf
5. postlog, sert à gérer les logs (réalisation de scripts)
6. postqueue, permet de gérer et administrer les files d'attentes.
Les journaux (logs) sont dans /var/log
Il définit les démons à lancer, leur nombre et les “ transports ”

# ===================================================================
# service type private unpriv chroot wakeup maxproc command args
# (yes) (yes) (yes) (never) (50)
# ===================================================================
smtp inet n - y - - smtpd
smtps inet n - y - - smtpd \
-o smtpd_tls_wrappermode=yes -o smtpd_sasl_auth_enable=yes
submission inet n - y - - smtpd \
-o smtpd_enforce_tls=yes -o smtpd_sasl_auth_enable=yes
pickup fifo n n y 60 1 pickup
cleanup unix - - y - 0 cleanup
qmgr fifo n - y 300 1 qmgr
#qmgr fifo n - y 300 1 nqmgr
tlsmgr fifo - - y 300 1 tlsmgr
rewrite unix - - y - - trivial-rewrite
bounce unix - - y - 0 bounce
defer unix - - y - 0 bounce
flush unix - - y 1000? 0 flush
smtp unix - - y - - smtp
showq unix n - y - - showq
error unix - - y - - error
local unix - n n - - local
virtual unix - n n - - virtual
lmtp unix - - n - - lmtp
[...]
Si postfix n'a pas été préalablement configuré, vous n'avez pas de fichier de configuration
main.cf. Vous pouvez utiliser la commande :
dpkg-reconfigure postfix
Utilisez les paramètres suivants pour une configuration minimale :
#$NOM_MACHINE est le nom d'hôte de votre machine

local only
$NOM_MACHINE
Append Domain no
Destination $NOM_MACHINE
Local Network 127.0.0.0/8
Use Procmail Yes
Siez Mail Box 0
Char Def Local Adress +
Le fichier main.cf contient tous les paramètres de postfix. Ceux-ci peuvent être affichés avec la
commande postconf.
Voici un exmple de main.cf que vous pourrez réutiliser pour les TP
# Vous avez un fichier complet et commenté

# /usr/share/postfix/main.cf.dist
command_directory = /usr/sbin
daemon_directory = /usr/lib/postfix
program_directory = /usr/lib/postfix
smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)

setgid_group = postdrop
biff = no
2bounce_notice_recipient = postmaster

# appending .domain is the MUA's job.
append_dot_mydomain = no
myhostname = NomHote.foo.org
mydomain = foo.org
mydestination = $myhostname, localhost.$mydomain $mydomain
myhostname = NomHote.foo.org
myorigin = $mydomain
myorigin = /etc/mailname
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
# /etc/mailname contient l'équivalent de $MYHOSTNAME
mynetworks = 127.0.0.0/8 192.168.0.0/24

mailbox_command = procmail -a "$EXTENSION"
mailbox_size_limit = 0
recipient_delimiter = +
relay_domains = $mydestination
relayhost = $mydomain
smtpd_recipient_restrictions = permit_mynetworks,check_relay_domains
Pour une configuration initiale remplir myhostname, mydomain, myorigin, mydestination,

relayhost.
Il sert à la création des aliases, par exemple jean.dudognon sera l'alias du compte système jddgn.
Le courrier sera adressé à jean.dudognon@domaine.dom, mais sera délivré dans la boîte du
compte jddgn, c'est à dire physiquement dans /var/spool/mail/jddgn.
Le fichier /etc/postfix/aliases est de type texte. C'est celui-ci que vous modifiez. Après chaque
modification du fichier source utiliser la commande newaliases ou postaliases
hash:/etc/postfix/aliases qui met à jour le fichier de bases de données
/etc/postfix/aliases.db.
La maintenance est réalisée à l'aide des commandes externes. Autrement les transactions sont
journalisées par le démon syslogd.
Oct 31 11:23:26 uranus postfix/master[2745]: daemon started
uranus postfix/smtpd[2753]: connect from unknown[192.168.1.1]

uranus postfix/smtpd[2753]: 82BF05769B: client=unknown[192.168.1.1]
uranus postfix/cleanup[2754]: 82BF05769B:
message-id=<20011031102453.82BF05769B@uranus.foo.org>
uranus postfix/qmgr[2749]: 82BF05769B:
from=<mlx@foo.org>, size=318, nrcpt=1 (queue active)
uranus postfix/local[2756]: 82BF05769B:
to=<mlx@foo.org>, relay=local, delay=94,
status=sent ("|/usr/bin/procmail /etc/procmail.rc")
uranus postfix/smtpd[2753]: disconnect from unknown[192.168.1.1]

Un messages est schématiquement composé de deux parties, une entête et un corps. Ces deux
parties sont séparées par une ligne blanche.
L'entête est découpée ainsi :

FROM: expéditeur
TO: destinaire(s)
CC: copie à
BCC: copie aveugle
REPLY-TO: adresse de réponse
ERROR-TO: adresse en cas d 'erreurs
DATE: date expédition
RECEIVED informations de transferts
MESSAGE-ID: identificateur unique de msg
SUBJECT: sujet
Le dialogue est défini par le protocole SMTP selon un schéma client/serveur. Sur le client, un
démon (programme sendmail ou smtpd par exemple) attend les requêtes TCP sur le port 25 d'un
client (le programme mail par exemple).Le dialogue est en ASCII. Pour tester utilisez la
commande telnet Serveur_SMTP 25 ou encore sendmail -v -bs.
Exemple de dialogue : la chaîne “ >>> ” n'apparaît pas, c'est juste pour distinguer les commandes
client.
[mlx@uranus mlx]$ telnet localhost 25

Trying 127.0.0.1...
Connected to localhost.localdomain (127.0.0.1).
Escape character is '^]'.
220 uranus.foo.org ESMTP Postfix
>>> EHLO uranus
250-uranus.foo.org
250-PIPELINING
250-SIZE 10240000
250-ETRN
250 8BITMIME
>>> MAIL FROM:<mlx@uranus.foo.org>
250 Ok
>>> RCPT TO:<mlx@foo.org>
250 Ok
>>>DATA
354 End data with <CR><LF>.<CR><LF>
Message de test
.
250 Ok: queued as C21B15769B
>>> QUIT
221 Bye
Connection closed by foreign host.
You have new mail in /var/spool/mail/mlx

PostOFFICE
Le service POP - Postoffice Protocole est utilisé par les logiciels clients (netscape, Eudora,
Outlook...) pour relever le courrier sur les serveurs de messagerie. Le client pop utilise un couple
Nom d'utilisateur/mot de passe pour la phase identification/authentification par le serveur. Le
service pop3d reste en écoute sur le port 110. Il est généralemnt lancé par le démon inetd ou
xinetd. Pour activer le service pop3 il suffit de décommenter la ligne correspondante dans le fichier
/etc/inetd.conf. Voici des exemples de lignes que vous pouvez avoir dans votre fichier
inetd.conf :
#:MAIL: Mail, news and uucp services.

imap2 stream tcp nowait root /usr/sbin/tcpd /usr/sbin/imapd
imaps stream tcp nowait root /usr/sbin/tcpd /usr/sbin/imapd
pop3 stream tcp nowait root /usr/sbin/tcpd /usr/sbin/ipop3d
pop3s stream tcp nowait root /usr/sbin/tcpd /usr/sbin/ipop3d
#imaps stream tcp nowait root /usr/sbin/tcpd \
/usr/sbin/sslwrap -nocert -addr 127.0.0.1 -port 143
#pop3s stream tcp nowait root /usr/sbin/tcpd \
/usr/sbin/sslwrap -nocert -addr 127.0.0.1 -port 110
ou d'activer le service “ disable = no ” dans /etc/xinetd.d/pop3, si vous utilisez xinetd.d.
Pop a été conçu pour la consultation “ hors ligne ”, (off line). IMAP permet la consultation hors
ligne, mais également “ en ligne ”, selon un processus interactif entre le client et le serveur. Les
messages ne sont plus rapatriés sur le client. Ils restent en dépôt sur le serveur jusqu'à ce que
l'utilisateur demande explicitement la suppression ou le transfert.
Ce procédé est particulièrement interessant pour les utilisateurs mobiles. Ils peuvent consulter
leur messages à partir de machines ou de lieux non définis à l'avance.
Comme la connexion au serveur est permanente pendant la durée du traitement, il présente

l'inconvénient d'un surcoût financier du à la liaison téléphonique.
Ces services utilisent des protocoles/ports différents. Ils peuvent cohabiter simultanément sur le
même serveur. Un utilisateur peut utiliser selon ses besoins l'un ou l'autre des services POP ou
IMAP.
Vous devrez installer et configurer sur les postes clients, un client IMAP (Netscape messenger,
Kmail...).
Des logiciels d'interface sur le serveur comme IMP (www.imp.org), permettent de transformer le
serveur IMAP en serveur “ webmail ”. Les clients pourront alors utiliser n'importe quel navigateur
pour consulter leur boîte aux lettres. Le CRU, (Comité Réseau des Universités - www.cru.fr), a fait
une étude sur les principaux produits qui pouvaient être utilisés.

Les ports utilisés par les services pop3, pop3s, imap, impas, sont déclarés dans le fichiers
/etc/services. Voici ce que donne le lancement d'inetd :
root@knoppix:/home/knoppix# netstat -atup | grep LISTEN

tcp 0 0 *:imaps *:* LISTEN 376/inetd
tcp 0 0 *:pop3s *:* LISTEN 376/inetd
tcp 0 0 *:pop3 *:* LISTEN 376/inetd
tcp 0 0 *:imap2 *:* LISTEN 376/inetd
Dans un soucis de sécurité, les applications récentes ne supportent plus les transactions “ en
clair ” sur le réseau. Cela signifie que les applications sont compilées pour utiliser les protocoles
d'encryptage TLS/SSL. Vous devrez en tenir compte dans la configuration de vos clients et vous
utiliserez pop3s et imaps.
Pour en savoir plus, vous pouvez consulter :
/usr/share/doc/ipopd/README.Debian
/usr/share/doc/libc-client2003debian/README.Debian
/usr/share/doc/libc-client2003debian/md5.
/usr/share/doc/libc-client2002/md5.txt
/usr/share/doc/libc-client2003debian/imaprc.txt
Chapter 36. Travaux pratiques : configuration d'un système de messagerie
Les protocoles SMTP, POP et IMAP - TP
Table of Contents
Le relayage
Abstract

Comment installer un serveur SMTP, un client IMAP et un client POP3
Vous allez installer successivement :
1. le serveur de messagerie postifx puis tester son fonctionnement,

2. un serveur de remise de courrier pop3 et imap
3. un client pop3 et imap puis tester son fonctionnement,
Pour imap on utilisera uw-imapd/uw-imapd-ssl, pour pop3, on utilisera ipopd. Pour les
préconfigurer vous utiliserez les commandes :
dpkg-reconfigure uw-imapd
dpkg-reconfigure ipopd
Vous sélectionnerez pop3 et pop3/ssl, imap4 et imap/ssl. Attention pour imap4, c'est imap2 qu'il
faut sélectionner. C'est bizarre mais c'est comme ça ;-) imap3 est devenu obsolète.
La procédure de configuration, génère des certificats dans /etc/ssl/certs/
Vous allez déjà préparer votre serveur de nom. Le serveur de nom primaire sera également
serveur SMTP (enregistrement MX - Mail eXchanger). Si votre serveur de nom s'appelle ns1,
rajouter les enregistrements suivants dans le fichier de configuration de votre zone :
# On définit la machine qui achemine le courrier pour

# user@ns1.VotreDomaine.Dom
@ IN MX 10 ns1.VotreDomaine.Dom
#On définit un alias pour le courrier envoyé à
mail IN CNAME ns1
#On définit un alias pour le courrier envoyé à partir de
smtp IN CNAME ns1
#On définit un alias pour le serveur pop et pour imap
pop IN CNAME ns1
imap IN CNAME ns1
Relancer le service dns. Les commandes suivantes doivent fonctionner à partir d'un client du
domaine :
ping ns1.VotreDomaine.Dom
ping smtp.VotreDomaine.Dom
ping mail.VotreDomaine.Dom
ping pop.VotreDomaine.Dom
ping imap.VotreDomaine.Dom

Vous allez successivement configurer un serveur SMTP Postifx, tester la configuration, installer
les serveur pop et imap, tester le fonctionnemnt de l'ensemble.
Configurer votre machine pour un service minimum (pas de liste, pas de réécriture d'adresse...).
Utilisez l'exemple de configuration de main.cf et la liste des variables à configurer donnés dans la
fiche de cours, afin de mettre en place un service minimum.
Activez le service avec la commande /etc/init.d/postfix start. Vérifiez le bon démarrage du

serveur dans le fichier de log et dans la table des processus (ps axf). Vous devriez obtenir
quelque chose comme :
2745 ? S 0:00 /usr/lib/postfix/master

2748 ? S 0:00 \_ pickup -l -t fifo -c
2749 ? S 0:00 \_ qmgr -l -t fifo -u -c
2750 ? S 0:00 \_ tlsmgr -l -t fifo -u -c
Vérifiez également les traces dans le fichier de journalisation.
Créez sur la machine locale deux comptes systèmes pour les tests. cpt1 et cpt2 par exemple.
Ouvrez une session sous le compte cpt1 afin de réaliser un envoi de mail pour cpt2.
Lancez une transaction telnet VotreServeur 25, et réalisez un dialogue similaire à celui décrit en
TD. Le message doit être délivré dans la boîte de cpt2. Utilisez la commande ps axf pour voir le
chargement des différents démons.
Rélisez l'opération à l'aide du programme mail. Vérifiez que le message est bien délivré.
Avant de terminer la transaction, identifiez la session avec la commande netstat :
netstat -atup | grep ESTABLISHED
La configuration du service pop est des plus simple. Il est même possible qu'il soit déjà actif.
Décommentez la ligne dans le fichier /etc/inetd.conf ou utilisez dpkg-reconfigure.
Vérifier le fichier /etc/inetd.conf, relancez au besoin le service inetd.
# Pop and imap mail services
Avec xinet, la configuration est dans /etc/xinetd.d. Editez les fichiers correspondant aux
différents services. Par exemple le fichier /etc/xinetd.d/pop3s.
# default: off
# The POP3S service allows remote users to access their mail \

# using an POP3 client with SSL support such as fetchmail.
service pop3s
{
socket_type = stream
wait = no
user = root
server = /usr/sbin/ipop3d
log_on_success += USERID
log_on_failure += USERID
disable = no
}
Dans inetd.conf, décommentez la ligne. Dans xinetd, mettez la variable disable à no.
Relancer le service inetd ou xinetd, vérifiez l'ouverture des ports avec la commande netstat.
Identifiez les numéros de ports des services dans le fichier /etc/services.
Vous allez réaliser l'opération à partir de la machine locale et d'une machine distante. La
résolution de nom doit fonctionner, sinon utilisez les adresses IP. Vous utiliserez kmail ou le client
de messagerie de Mozilla.
1. Sur la machine locale qui est votre serveur SMTP et serveur POP3, configurez le client de
messagerie avec les paramètres suivants :
2. Serveur smtp : Nom de votre serveur
3. Serveur POP : Nom de votre serveur POP
4. Votre compte d'utilisateur
5. Votre mot de passe
Testez l'envoi et la réception de message.
Renseignez bien le numéro de port. Dans kmail, l'onglet extras vous donne accès à un
bouton tester ce que le serveur peut gérer, et va vous renseigner sur le support de ssl ou
tls du serveur.
Avec un client pop, les messages sont, par défaut, téléchargés depuis le serveur sur le
client. La procédure supprime les fichiers téléchargés sur le serveur. Cette option est
configurable sur la majorité des clients.
Vérifiez que les fichiers sont bien supprimés sur le serveur.
Réitérez l'envoi de message en mettant un fichier attaché (par exemple un fichier xls).
Vérifier et relevez la description MIME du message.
6. Sur un client configurez Nestcape Messenger avec les paramètres suivants :

7. Serveur smtp : Nom de votre serveur (Machine distante)
8. Serveur POP : Nom de votre serveur POP3 (Machine distante)
9. Votre compte d'utilisateur
10. Votre mot de passe
Testez l'envoi et la réception de message.

Identifiez les transactions dans le fichier de log.
Créez un compte utilisateur pn,
Créez un alias prenom.nom pour ce compte système dans le fichier /etc/aliases.
Mettez à jour le fichier /etc/aliases/db.
Vérifiez que les messages envoyés à :
pn@votredomaine ou prenom.nom@votredomaine doivent tous être correctement délivrés.
Ouvrez à l'aide d'un éditeur le fichier /etc/aliases
Créez une liste de la façon suivante :
maliste: cpt1, cpt2
Enregistrez et régénérez le fichier aliases.db
Envoyez un message à maliste@foo.org, vérifiez que tous les membres de la liste ont bien reçu le
message.
Certaines erreurs “ systèmes ” sont gérés par un compte particulier “ MAILER_DAEMON ”. Ce

compte est en général un alias vers postmaster, qui, lui même redirige sur le compte de
l'administrateur en fonction. Il agit commem un “ robot ” notamment quand un message ne peut
être délivré.
Procédure de test
Envoyez un message à QuiNexistePas@foo.org
Relevez vos nouveau messages. Normalement, vous êtes averti que votre message n'a pas pu
être délivré.
La mise en oeuvre est identique à celle du service Pop3. Configurer le fichier inetd.conf ou le
fichier /etc/xinetd.d/imap. Relancer le service serveur (inetd ou xinetd).
Vous allez tester le bon fonctionnement de votre serveur : la commande ps aux | grep imap ne
donne rien car le serveur imap est lancé “ à la demande ” par le serveur inetd ou xinetd.
Par contre la commande netstat -a | grep LISTEN | grep imap montre bien qu'un port est bien
ouvert en “ écoute ”.

tcp 0 0 *:imap *:* LISTEN
Saisissez la commande telnet DeVotreServeurImap 143 pour activer le service imap. Le serveur
doit répondre :
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
* OK [CAPABILITY IMAP4 IMAP4REV1 STARTTLS LOGIN-REFERRALS AUTH=LOGIN]\
uranus.foo.org IMAP4rev1 2000.287rh at Sat, 17 Nov 2001 14:14:42 +0100 (CET)
Dans une autre session xterm, la commande ps aux | grep imap montre mainetant que le
service est maintenant bien dans la liste des processus :
root 11551 0.0 1.1 3664 1448 ? S 14:14 0:00 imapd
et la commande ps axf
231 ? S 0:00 /usr/sbin/inetd

315 ? S 0:00 \_ imapd
montre bien que le processus imapd dépend (est fils de) inetd.
La commande netstat a | grep imap donne l'état d'une connexion établie entre un client et le
serveur.Socket client TCP sur le port 1024
tcp 0 0 *:imaps *:* LISTEN

tcp 0 0 *:imap2 *:* LISTEN
tcp 0 0 knoppix:imap2 knoppix:1025 ESTABLISHED
tcp 0 0 knoppix:1025 knoppix:imap2 ESTABLISHED
La commande fuser 1025/tcp utilise le pseudo-système de fichiers d'informations sur les

processus /proc pour identifier “ QUI ” utilise la connexion tcp sur le port 1025.
root@knoppix:/home/knoppix# fuser 1025/tcp

1025/tcp: 364
La commande ls -l /proc/364 donne les indications sur le programme qui utilise cette connexion
et montre que c'est une commande telnet qui a déclenché le processus.
root@knoppix:/home/knoppix# ls -al /proc/364

total 0
dr-xr-xr-x 3 knoppix knoppix 0 2003-04-16 15:06 .
dr-xr-xr-x 49 root root 0 2003-04-16 16:52 ..
-r--r--r-- 1 knoppix knoppix 0 2003-04-16 15:06 cmdline
-r--r--r-- 1 knoppix knoppix 0 2003-04-16 15:06 cpu
lrwxrwxrwx 1 knoppix knoppix 0 2003-04-16 15:06 cwd -> /home/knoppix
-r-------- 1 knoppix knoppix 0 2003-04-16 15:06 environ
lrwxrwxrwx 1 knoppix knoppix 0 2003-04-16 15:06 \
exe -> /usr/bin/telnet-ssl
dr-x------ 2 knoppix knoppix 0 2003-04-16 15:06 fd
-r--r--r-- 1 knoppix knoppix 0 2003-04-16 15:06 maps
-rw------- 1 knoppix knoppix 0 2003-04-16 15:06 mem
-r--r--r-- 1 knoppix knoppix 0 2003-04-16 15:06 mounts
lrwxrwxrwx 1 knoppix knoppix 0 2003-04-16 15:06 root -> /
-r--r--r-- 1 knoppix knoppix 0 2003-04-16 15:06 stat
-r--r--r-- 1 knoppix knoppix 0 2003-04-16 15:06 statm

-r--r--r-- 1 knoppix knoppix 0 2003-04-16 15:06 status
et voir la commande qui a activé cette connexion more /proc/364/cmdline qui retourne telnet
localhost 143.
Utilisez Mail & NewsGroup de Mozilla ou kmail par exemple. Dans Mail & News Group, allez dans
le menu de configuration (Edit) et ajoutez un compte. Prenez un compte imap.
Complétez la configuration de votre client de messagerie
Ouvrez l'application Messenger, testez l'utilisation du client IMAP.
Le relayage
Utiliser le “ relayage ” consiste pour un client A à utiliser le service serveur SMTP d'un domaine B
pour inonder de messages (spammer) des boîtes aux lettres. Les serveurs sont généralement
configurés pour empêcher le relayage. Dans Postifx, cette option est configurée par défaut.
Le relayage pose plusieurs problèmes. Remplissage des boîtes aux lettres sans l'accord des
destinataires, utilisation des ressources disques et CPU à l'insu des sociétés qui relaient les
courriers...
Afin de combattre un peu le phénomène, une société qui relai les messages peut se voir “ black
listée ”, c'est-à-dire inscrite dans une liste noire référencée. Il existe plusieurs sites référençant ces
listes noires. Certains de ces messages ne seront plus distribués. Voir pour cela, http://mail-
abuse.org/rbl/, page principale de MAPS (Mail Abuse Prevention System LLC) RBLSM (Realtime
Blackhole List).
Il est possible d'utiliser ces bases de données pour empêcher le relayage, ou refuser de délivrer
les messages d'un site “ black listé ”.
maps_rbl_domains = rbl.maps.vix.com
maps_rbl_reject_code = 554
reject_maps_rbl
Vous allez activer la fonction de relayage sur votre serveur et tester son comportement. Modifiez
la ligne :
relay_domains = $mydestination
par
relay_domains = $mydestination, domaine1.dom, domaine2.dom...
où domaine1.dom, domaine2.dom... représentent les différents domaines de votre salle de TP.

Relancer les services serveurs.
Vous pouvez maintenant à partir d'un client, utiliser le serveur smtp d'un autre domaine pour vous
en servir comme “ agent de relai ” et envoyer des messages aux utilisateurs des autres domaines.

Le fichier de configuration main.cf, permet de filtrer sur les entêtes de messages (grep) sous sur
le contenu (body). Ces outils permettent dans certains cas de limiter le spam.
Le serveur postfix.org tient à jour des produits complémentaires qui permettent de mettre en place
des antivirus, des outils de filtrage de spam ou des outils de type web-mail.
Chapter 37. Installation d'un serveur DDNS avec bind et DHCP
Le DNS dynamique
Table of Contents
Résumé
Résumé
DHCP offre la possibilité de mettre à jour dynamiquement le système de résolution de nom.
Il s'agit, dans cette application, de faire cohabiter et faire fonctionner ensemble le service de
résolution de nom bind et le service dhcp.
L'environnement a été testé sur une distribution debian, avec bind9 et dhcp3.
Vous devez savoir configurer un serveur DHCP, un serveur de nom, avoir compris le
fonctionnement de rndc et des clés partagées, de dig.
Pour les amateurs d'ASCII-art, voici un schéma qui décrit les processus mis en oeuvre.
_______
| |_____________
| DHCP |_________ |
| | |3 |4
------- \|/ \|/
/|\| /|\| _______
| | | | | |
| | | | | DNS |
1|2| 5|6| | |
| | | | -------
|\|/ |\|/
_______
| |
|Client |
| |
-------

(1) DHCPDISCOVER from 00:08:c7:25:bf:5a (saturne) via eth0
(2) DHCPOFFER on 192.168.0.195 to 00:08:c7:25:bf:5a (saturne) via eth0
(3) Added new forward map from saturne.freeduc-sup.org to 192.168.0.195
Ajout de l'enregistrement de type A
(4) added reverse map from 195.0.168.192.in-addr.arpa to saturne.freeduc-sup.org
Ajout de l'enregistrement de type PTR
(5) DHCPREQUEST for 192.168.0.195 (192.168.0.1) from 00:08:c7:25:bf:5a (saturne) via
eth0
(6) DHCPACK on 192.168.0.195 to 00:08:c7:25:bf:5a (saturne) via eth0
Les opérations 1, 2, 5, 6 ont déjà été vues lors de l'étude du service DHCP. On voit en étudiant le
“ log ” ci-dessus, que l'inscription dans le DNS d'un client se fait avant l'acceptation du bail et
l'inscription finale de ce client (DHCPACK).
Dans cette application, vous installerez successivement le serveur de nom, le serveur dhcp, puis
vous ferez les manipulations qui permettent l'intégration.
Tout est décrit dans las pages de man de dhcpd.conf.
Deux façons de faire sont décrites (ad-hoc et interim) et une troisième est en cours d'élaboration.
La méthode ad-hoc n'est semble t-il plus supportée par les paquets, du moins elle ne l'est pas
avec le paquet dhcp3 de debian que j'utilise car considérée comme obsolète.
Le processus utilisé est défini par la variable ddns-updates-style. Si la mise à jour n'est pas
dynamique, la variable prend la valeur none, nous, nous utiliserons interim.
La méthode “ ad-hoc ” ne prend pas en charge le protocole failover des DHCP. C'est à dire
qu'avec cette méthode vous ne pourrez pas avoir 2 serveurs DHCP assurant un système
redondant et mettant à jour un même ensemble d'enregistrements DNS.
Le serveur détermine le nom du client en regardant d'abord dans les options de configuration des
noms (ddns-hostname). Il est possible de générer dynamiquement un nom pour le client en
concaténant des chaînes “ dyn+N°+NomDeDomaine ”. S'il ne trouve rien, il regarde si le client lui
a fait parvenir un nom d'hôte. Si aucun nom n'est obtenu, la mise à jour du DNS n'a pas lieu.
Pour déterminer le nom FQDN, le serveur concatène le nom de domaine au nom d'hôte du client.
Le nom du domaine lui, est défini uniquement sur le serveur DHCP.
Actuellement le processus ne prend pas en charge les clients ayant plusieurs interfaces réseau
mais cela est prévu. Le serveur met à jour le DNS avec un enregistrement de type A et un
enregistrement de type PTR pour la zone reverse. Nous verrons qu'un enregistrement de type
TXT est également généré.
Quand un nouveau bail est alloué, le serveur crée un enregistrement de type TXT qui est une clé
MD5 pour le client DHCP (DHCID).
La méthode interim est le standard. Le client peut demander au serveur DHCP de mettre à jour
le serveur DNS en lui passant ses propres paramètres (nom FQDN). Dans ce cas le serveur est

configuré pour honorer ou pas la demande du client. Ceci se fait avec le paramètre ignore
client-updates ou allow client-updates.
Par exemple, si un client jschmoe.radish.org demande à être inscrit dans le domaine

exemple.org et que le serveur DHCP est configuré pour, le serveur ajoutera un enregistrement
PTR pour l'adresse IP mais pas d'enregistrement A. Si l'option ignore client-updates est
configurée, il y aura un enregistrement de type A pour jschmoe.exemple.org.
Le serveur DNS doit être configuré pour pouvoir être mis à jour par le serveur DHCP. La méthode
la plus sûre utilise les signatures TSIG, basées sur une clé partagée comme pour le programme
d'administration des serveurs de nom rndc.
Vous devrez en créer une. Pour cela utiliser les éléments fournis dans la partie traitant de bind.
Ces aspects y ont déjà été abordés.
Par exemple dans le fichier named.conf, le serveur DHCP disposant de la clé DHCP_UPDATER,
pourra mettre à jour la zone directe et la zone reverse pour lesquelles la déclaration allow-update
existe.
Description du fichiers named.conf :
key DHCP_UPDATER {
algorithm HMAC-MD5.SIG-ALG.REG.INT;
secret pRP5FapFoJ95JEL06sv4PQ==;
};
zone "example.org" {
type master;
file "example.org.db";
allow-update { key DHCP_UPDATER; };
};
type master;
file "10.10.17.db";
allow-update { key DHCP_UPDATER; };
};
Dans le fichier de configuration du serveur DHCP vous pourrez mettre :
key DHCP_UPDATER {
algorithm HMAC-MD5.SIG-ALG.REG.INT;
secret pRP5FapFoJ95JEL06sv4PQ==;
};
zone EXAMPLE.ORG. {
primary 127.0.0.1; # Adresse du serveur de noms primaire
key DHCP_UPDATER;
}
zone 17.127.10.in-addr.arpa. {
primary 127.0.0.1; # Adresse du serveur de noms primaire
key DHCP_UPDATER;

}
La clé DHCP_UPDATER déclarée pour une zone dans le fichier dhcpd.conf est utilisée pour modifier
la zone si la clé correspond dans le fichier named.conf.
Les déclarations de zone doivent correspondre aux enregistrement SOA des fichiers de
ressources des zones.
Normalement il n'est pas obligatoire d'indiquer l'adresse du serveur de nom primaire, mais cela
peut ralentir le processus d'inscription des enregistrements, voire même ne pas fonctionner, si le
serveur de nom n'a pas répondu assez vite.
Chapter 38. Travaux pratiques : DDNS
Table of Contents
Réalisation
Réalisation
Vous allez réaliser l'opération avec un client windows 2000 serveur et un client Linux. Le serveur
Linux sera également serveur de nom.
Vous pouvez utiliser les exemples de fichiers fournis. Vosu aurez bien sûr à les adapter à votre
configuration. Voici comment vont se dérouler les étapes :
1. Installation du serveur de nom et test

2. Installation du serveur DHCP et test
3. Intégration des deux services
Nous verrons à la fin comment générer des noms dynamiquement pour les clients.

Dans les fichiers il y a des lignes qui sont en commentaires avec ###, elles seront décommentées
pour la phase d'intégration des services
// Pour journaliser, les fichiers doivent créés
logging {
channel update_debug {
file "/var/log/log-update-debug.log";
severity debug 3;
print-category yes;
print-severity yes;
print-time yes;
};
channel security_info {
file "/var/log/log-named-auth.info";
severity info;
print-category yes;
print-severity yes;
print-time yes;
};
category update { update_debug; };

category security { security_info; };
};
// clé partagée entre bind, rndc et dhcp

include "/etc/bind/mykey";
options {
directory "/var/cache/bind";
query-source address * port 53;
auth-nxdomain yes; # conform to RFC1035
forwarders { 127.0.0.1; 192.168.0.1;};
};
// Autorisations rndc sur la machine.

controls {
inet 127.0.0.1 allow {any;} keys {mykey;};
inet 192.168.0.0 allow {any;} keys {mykey;};
};
zone "." {
type hint;
file "/etc/bind/db.root";
};
zone "localhost" {
type master;
file "/etc/bind/db.local";
};
type master;
};
type master;

};
type master;
};
zone "freeduc-sup.org" {
type master;
file "/etc/bind/freeduc-sup.org.hosts";
// Sert à la mise à jour par DHCP
// Sera décommenté lors de l'intégration des services
### allow-update { key mykey; };
};
type master;
file "/etc/bind/freeduc-sup.org.hosts.rev";
// Sert à la mise à jour par DHCP
// Sera décommenté lors de l'intégration des services
### allow-update { key mykey; };
};

$ORIGIN .
$TTL 86400 ; 1 day
freeduc-sup.org IN SOA master.freeduc-sup.org. root.freeduc-sup.org. (
2004050103 ; serial
10800 ; refresh (3 hours)
3600 ; retry (1 hour)
604800 ; expire (1 week)
38400 ; minimum (10 hours 40 minutes)
)
NS master.freeduc-sup.org.
MX 10 master.freeduc-sup.org.
$ORIGIN freeduc-sup.org.
master A 192.168.0.1
www CNAME master

$ORIGIN .
$TTL 86400 ; 1 day
0.168.192.in-addr.arpa IN SOA master.freeduc-sup.org. root.freeduc-sup.org. (
2004050103 ; serial
10800 ; refresh (3 hours)
3600 ; retry (1 hour)
604800 ; expire (1 week)
38400 ; minimum (10 hours 40 minutes)
)
NS master.freeduc-sup.org.
$ORIGIN 0.168.192.in-addr.arpa.
1 PTR master.freeduc-sup.org.
include "/etc/bind/mykey";
options {
default-key "mykey";
};
server localhost {
key "mykey";
};

Ici il est nommé mykey.
key "mykey" {
algorithm hmac-md5;
secret
"X/ErbPNOiXuC8MIgTX6iRcaq/1OFCEDIlxrmnfPgdqYIOY3U6lsgDMq15jnxXEXmdGvv1g/
ayYtAA73bUQvWBw==";
};
### ddns-update-style interim;
### deny client-updates;
### ddns-updates on;
### ddns-domainname "freeduc-sup.org";
### ddns-rev-domainname "in-addr.arpa";
authoritative;
subnet 192.168.0.0 netmask 255.255.255.0 {

option domain-name "freeduc-sup.org";
option domain-name-servers 192.168.0.1;
range 192.168.0.100 192.168.0.195;
# Instructions pour la mise à jour des zones

### include "/etc/bind/mykey";
### zone freeduc-sup.org. {

### primary 192.168.0.1;
### key mykey;
### }
### zone 0.168.192.in-addr.arpa. {

### primary 192.168.0.1;
### key mykey;
### }
Vous allez pouvoir tester. A partir de maintenant vous devrez consulter les fichiers de logs si vous
rencontrez des problèmes de fonctionnement, les tables de processus... bref tout ce qui pourra
vous permettre de déterminer la ou les sources possibles des dysfonctionnements si vous en
constatez.
Lancez le service bind et tester son fonctionnement avec rndc.
root@master:/home/knoppix# rndc status

number of zones: 8

debug level: 0
xfers running: 0
xfers deferred: 0
soa queries in progress: 0
query logging is OFF
server is up and running
root@master:/home/knoppix#
Cela permet de vérifier que la clé est bien reconnue.
Vérifiez le fonctionnement du serveur à l'aide de la commande dig.
root@master:/home/knoppix/tmp# dig @127.0.0.1 freeduc-sup.org axfr

; <<>> DiG 9.2.2 <<>> @127.0.0.1 freeduc-sup.org axfr
freeduc-sup.org. 86400 IN SOA master.freeduc-sup.org. root.freeduc-
sup.org. 2004050107 10800 3600 604800 38400
freeduc-sup.org. 86400 IN NS master.freeduc-sup.org.
freeduc-sup.org. 86400 IN MX 10 master.freeduc-sup.org.
argo.freeduc-sup.org. 86400 IN A 192.168.0.253
master.freeduc-sup.org. 86400 IN A 192.168.0.1
www.freeduc-sup.org. 86400 IN CNAME master.freeduc-sup.org.
sup.org. 2004050107 10800 3600 604800 38400
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue May 6 19:15:38 2003
;; XFR size: 8 records
Vérifier de la même façon le fonctionnement de la zone reverse.
Vérifiez la strucure du fichier dhcp.
root@master:/home/knoppix# dhcpd3 -t
Cela permet de vérifier qu'il n'y a pas d'erreur de syntaxe dans le fichier.
Testez le fonctionnement traditionnel de votre serveur DHCP à partir d'un client Linux et windows.
Faites des renouvellement de baux.
Par défaut les client Linux ne transmettent pas leur nom d'hôte comme c'est le cas pour les clients
windows. Modifiez sur le client Linux le fichier /etc/dhclient.conf de la façon suivante, nous
verrons plus loin comment générer un nom dynamiquement :
[root@bestof mlx]# more /etc/dhclient.conf

send host-name "bestof";
Décommentez dans les fichiers named.conf et dhcpd.conf les lignes commentées par ###.
Supprimez dans le dhcpd.conf la ligne :

Relancez le service DNS et testez sont bon fonctionnement
Vérifiez le fichier dhcpd.conf avec la commande dhcpd3 -t.
Lancez dhcp en mode foreground dhcpd3 -d, voici ce que vous devriez obtenir :
root@master:/etc/dhcp3# dhcpd3 -d
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
Demandez un bail à partir du client windows (ici windows 2000 Server), voici ce qui devrait se
passer :
DHCPDISCOVER from 00:08:c7:25:bf:5a (saturne) via eth0

DHCPOFFER on 192.168.0.195 to 00:08:c7:25:bf:5a (saturne) via eth0
Added new forward map from saturne.freeduc-sup.org to 192.168.0.195
added reverse map from 195.0.168.192.in-addr.arpa to saturne.freeduc-sup.org
DHCPREQUEST for 192.168.0.195 (192.168.0.1) from 00:08:c7:25:bf:5a (saturne) via eth0
DHCPACK on 192.168.0.195 to 00:08:c7:25:bf:5a (saturne) via eth0
Demandez un bail à partir du client Linux, voici ce qui devrait se passer :
DHCPDISCOVER from 00:08:c7:25:ca:7c via eth0

DHCPOFFER on 192.168.0.194 to 00:08:c7:25:ca:7c (bestof) via eth0
Added new forward map from bestof.freeduc-sup.org to 192.168.0.194
added reverse map from 194.0.168.192.in-addr.arpa to bestof.freeduc-sup.org
DHCPREQUEST for 192.168.0.194 (192.168.0.1) from 00:08:c7:25:ca:7c (bestof) via eth0
DHCPACK on 192.168.0.194 to 00:08:c7:25:ca:7c (bestof) via eth0
Voici le contenu du fichier de journalisation de bind :
Log de Bind log-update-debug.log

root@master:/var/log# more log-update-debug.log
May 06 07:49:50.457 update: info: client 192.168.0.1#32846: updating zone 'freeduc-
sup.org/IN': adding an RR
May 06 07:49:50.512 update: info: client 192.168.0.1#32846: updating zone
'0.168.192.in-addr.arpa/IN': deleting an rrse
t
'0.168.192.in-addr.arpa/IN': adding an RR
'0.168.192.in-addr.arpa/IN': deleting an rrse
t
'0.168.192.in-addr.arpa/IN': adding an RR
root@master:/var/log#

Voici le contenu du fichier de déclaration de zone avec les nouveaux enregistrements
root@master:/var/log# dig @127.0.0.1 freeduc-sup.org axfr

sup.org. 2004050103 10800 3600 604800 38400
bestof.freeduc-sup.org. 300 IN TXT "00e31b2921cd30bfad552ca434b61bda02"
bestof.freeduc-sup.org. 300 IN A 192.168.0.194
saturne.freeduc-sup.org. 300 IN TXT "310e43cfc20efbe1c96798d48672bc76aa"
saturne.freeduc-sup.org. 300 IN A 192.168.0.195
sup.org. 2004050103 10800 3600 604800 38400
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue May 6 07:56:43 2003
Cela est possible en modifiant le fichier de configuration de DHCP. Vous pourrez retrouver tous
les éléments dans la page de manuel.
Par exemple rajoutez dans le fichier la ligne ci-dessous pour adapter le nom à partir de l'adresse
MAC du client :
#ddns-hostname = binary-to-ascii (16, 8, "-",substring (hardware, 1, 12));
Ou celle-ci pour localiser le client :
ddns-hostname = concat ("dhcp-a-limoges","-",binary-to-ascii(10,8,"-",leased-address));
Avec cette dernière, voici les enregistrements ajoutés :
Added new forward map from dhcp-a-limoges-192-168-0-194.freeduc-sup.org to

192.168.0.194
added reverse map from 194.0.168.192.in-addr.arpa to dhcp-a-limoges-192-168-0-
194.freeduc-sup.org
DHCPREQUEST for 192.168.0.194 from 00:08:c7:25:ca:7c via eth0
DHCPACK on 192.168.0.194 to 00:08:c7:25:ca:7c (bestof) via eth0
Le fichier des incriptions :
root@master:/home/knoppix# more /var/lib/dhcp3/dhcpd.leases

lease 192.168.0.194 {
starts 2 2003/05/06 17:38:38;
ends 2 2003/05/06 17:48:38;
binding state active;
next binding state free;
hardware ethernet 00:08:c7:25:ca:7c;
set ddns-rev-name = "194.0.168.192.in-addr.arpa";
set ddns-txt = "00e31b2921cd30bfad552ca434b61bda02";

set ddns-fwd-name = "dhcp-192-168-0-194.freeduc-sup.org";
client-hostname "bestof";
}
Les transferts de zones directes et inverses :
root@master:/home/knoppix/tmp# dig @127.0.0.1 freeduc-sup.org axfr

sup.org. 2004050116 10800 3600 604800 38400
0-8-c7-25-ca-7c.freeduc-sup.org. 300 IN TXT "00e31b2921cd30bfad552ca434b61bda02"
0-8-c7-25-ca-7c.freeduc-sup.org. 300 IN A 192.168.0.194
dhcp-192-168-0-194.freeduc-sup.org. 300 IN TXT "00e31b2921cd30bfad552ca434b61bda02"
dhcp-192-168-0-194.freeduc-sup.org. 300 IN A 192.168.0.194
dhcp-a-limoges-192-168-0-194.freeduc-sup.org. 300 IN TXT
"00e31b2921cd30bfad552ca434b61bda02"
dhcp-a-limoges-192-168-0-194.freeduc-sup.org. 300 IN A 192.168.0.194
sup.org. 2004050116 10800 3600 604800 38400
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue May 6 19:39:08 2003
La zone reverse :
root@master:/home/knoppix/tmp# dig @127.0.0.1 0.168.92.in-addr.arpa axfr
; <<>> DiG 9.2.2 <<>> @127.0.0.1 0.168.92.in-addr.arpa axfr

; Transfer failed.
root@master:/home/knoppix/tmp# dig @127.0.0.1 0.168.192.in-addr.arpa axfr
; <<>> DiG 9.2.2 <<>> @127.0.0.1 0.168.192.in-addr.arpa axfr

0.168.192.in-addr.arpa. 86400 IN SOA master.freeduc-sup.org. root.freeduc-
sup.org. 2004050113 10800 3600 604800 38400
0.168.192.in-addr.arpa. 86400 IN NS master.freeduc-sup.org.
1.0.168.192.in-addr.arpa. 86400 IN PTR master.freeduc-sup.org.
194.0.168.192.in-addr.arpa. 300 IN PTR dhcp-192-168-0-194.freeduc-sup.org.
3.0.168.192.in-addr.arpa. 86400 IN PTR argo.freeduc-sup.org.
0.168.192.in-addr.arpa. 86400 IN SOA master.freeduc-sup.org. root.freeduc-
sup.org. 2004050113 10800 3600 604800 38400
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue May 6 19:40:08 2003
Chapter 39. Installation d'un service Web-mail
Agent Utilisateurs de Messagerie basés sur HTTP
Table of Contents

Présentation
Application
Présentation
Il est préférable d'avoir réalisé les ateliers sur les serveurs HTTP, SMTP et DNS avant de
commencer celui-ci.
Le service Web-mail permet l'utilisation d'un service de messagerie à partir d'un client Web
comme mozilla. Cette interface est intéressante, car contrairement à un client pop3 standard qui
serait configuré pour rapatrier les courriers sur la machine locale, ceux-ci, vont rester sur le
serveur. Vous pouvez les consulter à partir de n'importe quel poste pourvu qu'il dispose d'un
navigateur. Vous aurez ensuite tout le loisir de les récupérer avec votre client de messagerie
préféré si vous en utilisez un.
Il existe un très grand nombre de serveur Web-mail, et écris dans des langages très différents.
Une étude a été réalisée par le CRU http://www.cru.fr/http-mail/, mais parmi les principaux on peut
citer IMP écris en PHP et qui s'appuie sur la librairie horde. Il existe aussi OpenWebmail qui lui est
écris en Perl. Ces deux produits existent en paquets Debian, on utilisera pour le TP
OpenWebmail, mais ces deux outils comportent chacun de nombreuses qualités, le choix devra
se faire en fonction du degré d'intégration que vous souhaiterez obtenir avec vos autres
applications.
Figure 39.1. Architecture globale d'un service Web-mail

1. En 1 et 2, le client passe par une phase préalable d'authentification, il faut donc un service
correspondant sur le serveur. Cela peut être pris directement en charge par le service Web-
mail ou par un service extérieur (pam, ldap par exemple). (Nous utiliserons l'authentification
pam).
2. En 3 et 4, le dialogue s'effectue en un navigateur et un serveur HTTP. Le dialogue peut
s'effectuer dans un canal SSL ou TLS. Le suivi de session peut être réalisé à l'aide de
cookie par exemple. (Nous utiliserons Apache comme serveur HTTP).
3. En A et B, le service Web-mail utilise une base de données pour les boîtes aux lettres des
utilisateurs, pour les dossiers (inbox, outbox, trash...) et la conservation des courriers.
Certains Web-mail s'appuient sur des bases de type MySQL, PostgreSQL... ou simplement
sur une arborescence de répertoires dans le HOME_DIRECTORY de l'utilisateur. (Nous
n'utiliserons pas de SGBD/R).
4. Sur le serveur, il faut activer un protocole de traitement du courrier (pop3, pop3s, imap,
imaps...). Nous utiliserons imap et pop3.
5. Vous aurez également besoin d'un service SMTP pour le traitement des courriers sortants
(nous utiliserons postfix) et d'un service de livraison (DUA) (nous utiliserons procmail) pour
délivrer les courriers entrants.
Vous allez installer OpenWebmail mais auparavant il est nécessaire de s'assurer du bon
fonctionnement de certains services. (smtp, mail, procmail, apache...)
Suivez la procédure ci-dessous pour préparer la machine.

Configuration générale
On considère la configuration suivante, vous adapterez les noms, adresses IP et autres

paramètres à votre configuration. Il n'y a pas de DNS.
Nom d'hôte : freeduc-sup ($NAME)

Nom FQDN de la machine : freeduc-sup.foo.org ($FQDN)
Adresse de réseau : 192.168.0.0
Adresse de la machine : 192.168.0.2
Adresse de la passerelle par défaut : 192.168.0.254
Test de la résolution de nom
Vérifier que la résolution de nom fonctionne parfaitement. Les commandes : ping $NAME et ping
$FQDN doivent répondre correctement.
# Exemple de fichier /etc/hosts

127.0.0.1 freeduc-sup freeduc-sup.foo.org localhost localhost.localdomain
192.168.0.2 freeduc-sup freeduc-sup.foo.or
Le service Apache
Activez le service apache. Il ne doit pas y avoir de message d'erreur au lancement, notamment
sur la résolution de nom. Vérifiez également le bon fonctionnement avec une requête sur :
http://localhost
Le service SMTP (Postfix)
Pour configurer postfix, utilisez la commande dpkg-reconfigure postfix, vous prendrez site
internet. Les valeurs par défaut doivent normalement fonctionner.
Ouvrez le fichier /etc/postfix/main.cf, vérifiez qu'il correspond à celui-ci, au besoin modifiez le :
# Fichier de configuration de Postfix

# Adaptez vos noms d'hôtes et vos noms de machines
# see /usr/share/postfix/main.cf.dist for a commented, fuller

# version of this file.
# Do not change these directory settings - they are critical to Postfix

# operation.
command_directory = /usr/sbin
daemon_directory = /usr/lib/postfix
program_directory = /usr/lib/postfix
smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)

setgid_group = postdrop
biff = no
myhostname = freeduc-sup.foo.org
mydomain = foo.org
myorigin = $myhostname
inet_interfaces = all
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
mydestination = $myhostname, localhost.$mydomain
relayhost =
mailbox_command = procmail -a "$EXTENSION"
mailbox_size_limit = 0

recipient_delimiter = +
Une fois cela réalisé, activez ou relancez le service.
/etc/init.d/postfix start
/etc/init.d/postfix reload
Activation des services imap
Cela s'effectue dans le fichier inet.conf. Il faudra adapter si vous utilisez xinetd. Cela dépend de
la distribution de GNU/Linux que vous utilisez. Vous pouvez également utiliser la commande
dpkg-reconfigure uw-imapd. Dans ce cas, prenez imap2 (qui correspond à imap4 (? ;-))) et
imaps.
Extrait d'un exemple de configuration de inetd.conf :
#:MAIL: Mail, news and uucp services.

imap2 stream tcp nowait root /usr/sbin/tcpd /usr/sbin/imapd
Adaptez votre fichier de configuration, puis relancer inetd avec la commande :
/etc/init.d/inetd restart
Vérifiez que les ports sont bien ouverts avec la commande netstat. Vous devez avoir les ports 25
(pop3)si vous l'avez activé et 143 (imap) ouverts.
netstat -atup | grep LISTEN

tcp 0 0 *:netbios-ssn *:* LISTEN 269/smbd
tcp 0 0 *:imap2 *:* LISTEN 263/inetd
tcp 0 0 *:sunrpc *:* LISTEN 151/portmap
tcp 0 0 *:ssh *:* LISTEN 278/sshd
tcp 0 0 *:ipp *:* LISTEN 290/cupsd
tcp 0 0 *:smtp *:* LISTEN 899/master
Nous voyons imap2, ligne 2, pris en charge par inetd.
root@freeduc-sup:/home/mlx# netstat -natup | grep LISTEN

tcp 0 0 0.0.0.0:139 0.0.0.0:* LISTEN 269/smbd
tcp 0 0 0.0.0.0:143 0.0.0.0:* LISTEN 263/inetd
tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN 151/portmap
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 278/sshd
tcp 0 0 0.0.0.0:631 0.0.0.0:* LISTEN 290/cupsd
tcp 0 0 0.0.0.0:25 0.0.0.0:* LISTEN 899/master
Ici l'option -n de netstat nous indique les numéros de ports utilisés.
Remarque : si vous souhaitez utiliser un client pop, vous devrez activer également le protocole
pop.
Test des services
A ce stade, il nous est possible de tester complètement le service de messagerie. Vous pouvez
indifféremment utiliser un client comme kmail ou Mozilla. Le plus simple est d'utiliser le client mail.
Suivez la procédure ci-dessous :

1. Créez deux comptes utilisateurs alpha et beta qui serviront pour les tests avec la
commande adduser.
2. Testez avec la commande mail que l'envoie de courrier se déroule correctement. Les
commandes :
3. mail alpha
4. mail alpha@freeeduc-sup
5. mail alpha@freeduc-sup.foo.org
doivent fonctionner correctement.
Si vous utilisez la freeduc-sup, OpenWebmail n'est pas installé. Utilisez la commande :
apt-get install openwebmail
La commande installera également 3 paquets supplémentaires qui correspondent aux

dépendances puis lancera la procédure de configuration.
Vous pouvez à tout moment reconfigurer l'application avec dpkg-reconfigure openwebmail.

Prenez comme option :
authentification -> auth_pam.pl

langage -> fr
Pour tester l'environnement vous avez deux liens :
http://localhost/openwebmail
qui vous place sur un espace documentaire
http://localhost/cgi-bin/openwebmail/openwebmail.pl
qui lance l'application proprement dite et vous amène sur la première fenêtre de login
Figure 39.2. Ouverture de session sur un Web-mail

Il vous sera possible de créer un serveur Web virtuel pour avoir par exemple :
“ openwebmail.freeduc-sup.org ”.
A la première session, la personne reçoit une invite lui permettant de configurer son
environnement et ses paramètres particuliers, comme son adresse de réponse, modifier son mot
de passe... Ces paramètres sont modifiables à tout moment.
Figure 39.3. Configuration de l'environnement utilisateur

A partir de ce moment, l'environnement complet est disponible. L'utilisateur dispose également

d'un calendrier et d'une documentation en ligne.
Figure 39.4. Voir ses messages

Figure 39.5. Le calendrier
Figure 39.6. L'aide en ligne

Application
1. Configurez et vérifiez le bon fonctionnement des services de résolution de nom, apache, postfix.
2. Installez et configurez OpenWebmail.
3. Testez le fonctionnement OpenWebmail.
Chapter 40. Installation d'un service mandataire (Proxy SQUID)
Serveur mandataire et serveur de cache - Fiche de cours
Table of Contents
Installer Squid
La journalisation

Le serveur mandataire (proxy) est une machine souvent physiquement située entre un réseau et
son accès à Internet. Il fait office à la fois de passerelle pour l'accès à Internet et de cache de
pages web.
 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 srevice 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.
Squid est un service serveur proxy-cache sous linux. Les objets consultés par les clients sur
internet, sont stockés en cache disque par le serveur. A partir du deuxième accès, la lecture se
fera en cache, au lieu d'être réalisée sur le serveur d'origine. De ce fait il permet “ d'accélérer ” vos
connexions à l'internet en plaçant en cache les documents les plus consultés. On peut aussi
utiliser la technique du service serveur mandataire pour effectuer des contrôles d'accès aux sites.
Les services proxy peuvent être organisés de façon hiérarchique :
________
|serveur |
|national|
|________|
|
________|________
| |
___|____ ___|____
|serveur | |serveur |
|régional| |régional|
|________| |________|
|
______|______
| |
____|___ ____|___
|serveur | |serveur |
| local | | local |
|________| |________|
Les serveurs peuvent être paramétrés pour les autorisations d'accès et les synchronisations.

Les postes clients sont souvent configurés pour utiliser un serveur proxy. Le client s'adresse au
serveur proxy, et c'est ce dernier qui traite la requête sur internet. Un fois la réponse reçue, le
serveur met en cache la réponse et la retourne au client interne. Le service proxy est
fréquemment configuré sur un routeur qui remplit aussi le service de translation d'adresse ou
translation de port, mais toutes ces fonctions sont bien différentes.
Dans certains cas, on peut ne pas souhaiter que la configuration soit réalisée au niveau du client.
On souhaite que celle-ci soit faite au niveau du serveur. Cela peut arriver par exemple si vous
avez plusieurs centaines de postes à configurer ou bien si vous ne souhaitez pas que les
utilisateurs puissent modifier ou avoir accès à cette partie de la configuration. On parlera de
“ service proxy transparent ”. Le service serveur proxy peut être sur le routeur d'accès à l'internet
ou sur une autre machine.
Service proxy tranparent :

La configuration des navigateurs, sur les postes clients, n'est pas concernée.
Vers internet
/|\ /|\
| |
___|____ ____|____ ________
|routeur | | | (3) | |
| proxy | | routeur | <----- | proxy |
|________| |_________| ------> |________|
| /|\ (2)
______|______ |
| | | (1)
____|___ ____|___ ____|____
| | | | | |
| client | | client | | client |
|________| |________| |_________|
<----------------------> <----------------------------->
Figure 1 Figure 2
Sur la Figure 1, le service proxy est installé sur le routeur.
Sur la figure 2, les requêtes du client (1), sont redirigées vers le proxy par le routeur (2), qui
retourne au client la réponse ou redirige vers le routeur (3) pour un envoi sur l'extérieur.
Installer Squid
Sur debian apt-get install squid.
Squid comporte de très nombreux paramètres. L'optimisation n'en est pas toujours simple. Nous
allons voir uniquement quelques options permettant un fonctionnement du service. Il sera
nécessaire, pour un site en production, de se référer à la documentation officielle.
Pour démarrer une configuration simple, il est possible d'utiliser le fichier de configuration
/etc/squid.conf, dont chaque paramètre est documenté.

Toute la configuration de Squid se trouve dans le fichier squid.conf. La plupart des options par
défaut du fichier ne sont pas à changer (vous pouvez alors laisser le # pour conserver les options
en commentaire.)
http_port : le port que vous souhaitez utiliser. Le plus fréquent est 8080. Il faut donc changer
cette valeur car par défaut Squid utilise 3128.
icp_port :conserver le port 3130. Ceci vous permet de communiquer avec des proxy-cache
parents ou voisins.
cache_mem : correspond au cache mémoire, la valeur dépend de votre système. Par défaut squid
utilise 8 Mo. Cette taille doit être la plus grande possible afin d'améliorer les performances
(Considérez 1/3 de la mémoire que vous réservez à Squid). Il faut avec cache_mem régler
cache_mem_low et cache_mem_high qui sont les valeurs limites de remplissage du cache
mémoire. Par défaut les valeurs sont 75 % et 90 %. Lorsque la valeur de 90 % est atteinte le
cache mémoire se vide jusqu'à 75 %. Les valeurs par défaut sont correctes dans la plupart des
cas.
cache_swap : correspond à la taille de votre cache disque. Si la taille du disque le permet, et en

fonction de la taille de votre établissement (nombre de clients qui utilisent le cache), mais aussi de
la durée de rafraîchissement de votre cache et du débit de votre ligne, vous devez mettre la valeur
qui vous semble correspondre à votre situation.
acl QUERY urlpath_regex cgi-bin \? \.cgi \.pl \.php3 \.asp : Type de page à ne pas garder
dans le cache afin de pas avoir les données d'un formulaire par exemple.
maximum_object_size : taille maximale de l'objet qui sera sauvegardé sur le disque. On peut
garder la valeur par défaut.
cache_dir : Vous indiquez ici le volume de votre cache. Si vous avez plusieurs disques, utilisez
plusieurs fois cette ligne. Si squid ne fonctionne pas bien ou s'arrête parfois sans raison
apparente, vérifiez que vous avez un cache assez important ou bien configuré.
cache_dir ufs /cache1 100 16 256 (cache de 100 Mb)

cache_dir ufs /cache2 200 16 256 (cache de 200 Mb)
Les valeurs 16 et 256, indiquent le nombre de sous-répertoires créés respectivement dans le

premier niveau et suivants pour le stockage des données du cache.
cache_access_log ; cache_log ; cache_store_log : Indique l'endroit où se trouve les logs (fichiers

de journalisation). Si vous ne souhaitez pas avoir de log (par exemple des objets
cache_store_log) indiquer cache_store_log none.
debug_options ALL,1 : niveau de debug. Indiquer 9 pour avoir toutes les traces à la place de 1.
Attention cela donne de gros fichiers.
dns_children : par défaut le nombre de processus simultanés dns est de 5. Il peut être nécessaire
d'augmenter ce nombre afin que Squid ne se trouve pas bloqué. Attention de ne pas trop
l'augmenter cela peut poser des problèmes de performance à votre machine (indiquer 10 ou 15).

request_size : taille maximale des requêtes. Conserver la valeur par défaut, concerne les
requêtes de type GET, POST...
refresh_pattern : permet de configurer la durée de mise à jour du cache. Utiliser -i pour ne pas
tenir compte des minuscules ou des majuscules. (voir le fichier squid.conf). Les valeurs Min et
Max sont indiquées en minutes. Exemple :
# refresh_pattern ^ftp: 1440 20% 10080
visible_hostname : indiquer ici le nom de votre serveur proxy.
logfile_rotate : pour faire tourner vos logs et garder un nombre de copies. par défaut 10.
attention si votre cache est très utilisé , il peut générer un grand volume de logs, pensez donc à
réduire ce nombre.
error_directory : Pour avoir les messages d'erreurs en français (indiquer le répertoire où ils se
trouvent). Exemple :
#error_directory /etc/squid/errors
#Créer un lien vers le répertoire où sont logés les messages en Français.
Cela n'est réalisé que la première fois afin de générer le cache.
squid -z
On peut démarrer Squid en lui passant des commandes sur la ligne de commande. Différents
paramètres peuvent être passés sur la ligne de commande. Les options passées de cette façon
remplacent les paramètres du fichier de configuration de Squid squid.conf.
-h :
Pour obtenir les options possibles
-a :
Pour indiquer un port particulier
-f :
pour utiliser un autre fichier de conf au lieu de squid.conf
-u :
spécifie un port pour les requêtes ICP. (3110 par défaut)
-v :
pour indiquer la version de Squid
-z :
Pour initialiser le disque cache.
-k :
Pour envoyer des instructions à Squid pendant son fonctionnement.
Il faut faire suivre -k d'une instruction
(rotate|reconfigure|shutdown|interrupt|kill|debug|check).
-D : pour démarrer squid lorsque vous n'êtes pas connecté en
permanence à internet (évite de vérifier si le serveur DNS répond).

Pour contrôler tout ce qui passe par votre serveur proxy, vous pouvez utiliser ce que l'on appelle
les ACL (Access Control List). Les ACL sont des règles que le serveur applique. Cela permet par
exemple d'autoriser ou d'interdire certaines transactions.
On peut autoriser ou interdire en fonction du domaine, du protocole, de l'adresse IP, du numéro

de port, d'un mot, on peut aussi limiter sur des plages horaires.
La syntaxe d'une ACL est la suivante :
acl aclname acltype string[string2]

http_access allow|deny [!]aclname
acltype peut prendre comme valeur :
src (pour la source) : indication de l'adresse IP du client sous la

forme adresse/masque. On peut aussi donner une plage d'adresses
sous la forme adresse_IP_debut-adresse_IP_fin
dst (pour la destination) : idem que pour src, mais on vise
l'adresse IP de l'ordinateur cible.
srcdomain : Le domaine du client
dstdomain : Le domaine de destination.
url_regex : Une chaîne contenu dans l'URL
(on peut utiliser les jokers ou un fichier).
urlpath_regex : Une chaîne comparée avec le chemin de l'URL
(on peut utiliser les jokers).
proto : Pour le protocole.
Exemple 1 : Interdire l'accès à un domaine : supposons que nous souhaitions interdire l'accès à
un domaine (par exemple le domaine pas_beau.fr). On a donc
acl veuxpas dstdomain pas_beau.fr

http_access deny veuxpas
http_access allow all # On accepte tout
La dernière ligne ne doit exister qu'une fois dans le fichier squid.conf.
Exemple 2 : interdire l'accès aux pages contenant le mot jeu.
acl jeu url_regex jeu

http_access deny jeu
http_access allow all
Attention url_regex est sensible aux majuscules/minuscules. Pour interdire JEU, il faut aussi
ajouter JEU dans votre ACL. Il n'est pas besoin de réécrire toute l'ACL. On peut ajouter JEU
derrière jeu en laissant un blanc comme séparation (cela correspond à l'opérateur logique OU).
On peut placer un nom de fichier à la place d'une série de mots ou d'adresses, pour cela donner
le nom de fichier entre guillemets. Chaque ligne de ce fichier doit contenir une entrée.
Exemple 3 : utilisation d'un fichier
# URL interdites
acl url_interdites url_regex "/etc/squid/denied_url"
http_access deny url_interdites

Des produits associés à Squid (redirecteurs) permettent un contrôle plus simple. SquidGuard, par
exemple, permet d'interdire des milliers de sites. Le site d'information est référencé plus loin dans
la rubrique “ liens ”. Pensez, si vous utilisez SquidGuard, à configurer la ligne suivante dans le
fichier squid.conf :
redirect_program /usr/local/squid/bin/SquidGuard
Exemple 4 : pour contrôler qui a le droit d'utiliser votre cache, créez une ACL du type :
acl si_OK src 192.168.0.0/255.255.0.0

http_access allow localhost
http_access allow site_OK
http_access deny all
Parmi les demandes qui reviennent le plus souvent, la question de l'utilisation de Squid pour
contrôler qui a le droit d'aller sur internet, est l'une des plus fréquentes.
On peut imaginer deux solutions :
La première consiste à contrôler les accès par salle et par horaires, en fonction d'un plan
d'adressage de votre établissement. Le travail de l'académie de Grenoble avec ls projet SLIS
permet de faire cela. On l'administre avec une interface Web. Ce n'est alors pas Squid qui est
utilisé pour cela mais les fonctions de filtrage du routeur (netfilter par exemple). Construire des
ACL directement dans Squid est faisable, mais cela n'est pas toujours simple à mettre en oeuvre.
La deuxième solution est de contrôler en fonction des individus. Squid permet de faire cela, à
partir de plusieurs façons (APM, LDAP, NCSA auth, SMB...). Les différentes techniques sont
décrites dans la FAQ de Squid sur le site officiel. Squid
Si vous utilisez un annuaire LDAP, vous devez avoir dans le fichier squid.conf les lignes
suivantes :
acl identification proxy_auth REQUIRED

http_access allow identification
authentificate_program /usr/lib/squid/squid_ldap_auth \
-b $LDAP_USER -u uid SERVEUR_LDAP
LDAP_USER est l'ou (organizational unit) dans laquelle se trouve les clients
(par exemple ou=people, ou= ac-limoges, ou=education, ou=gouv, c=fr).
Si vous n'avez pas de serveur LDAP, une méthode simple à mettre en oeuvre, consiste à utiliser
une méthode similaire au fichier .htaccess d'Apache.
Exemple de configuration avec NCSA_auth
authenticate_program /usr/lib/ncsa_auth /etc/squid/passwd

acl foo proxy_auth REQUIRED
acl all src 0/0
http_access allow foo

Squid dispose en standard de quelques outils, mais sinon vous pouvez utiliser webmin. Vous
trouverez également, sur le site officiel de squid, une liste de produits supplémentaires pouvant
être interfacés avec Squid.
La journalisation
Squid journalise les transactions dans un fichier access.log. Ce fichier donne les informations sur
les requêtes qui ont transité par Squid. Le fichier cache.log informe sur l'état du serveur lors de
son démarrage. Le fichier store.log informe sur les objets stockés dans le cache.
Les dates indiquées dans le fichier access.log indique le temps en secondes depuis le 1 janvier
1970 (format epoch), ce qui n'est pas très facile à lire. Un petit script en perl, permet de recoder
les dates :
#! /usr/bin/perl -p
s/^\d+\.\d+/localtime $&/e;
Pour configurer les clients, on peut utiliser la configuration manuelle ou la configuration

automatique avec des fichiers .pac ou des fichiers .reg que l'on place dans le script de connexion
des clients.
Configuration manuelle des clients
Configuration automatique
Il existe plusieurs solutions :
Configurer votre navigateur avec le bon proxy ou en utilisant le fichier de configuration

automatique et le rendre impossible à changer. Mais cela nécessite que vous contrôliez les clients
ce qui n'est pas toujours le cas.
Intercepter les requêtes sur le port 80 du routeur pour les rediriger sur Squid.
Vous devez alors avoir dans votre fichier squid.conf :
# Configuration de traitement des requêtes du client

httpd_accel_host virtual
httpd_accel_port 80
httpd_accel_with_proxy on

httpd_accel_uses_host_header on
httpd_accel_single_host off
Puis ajouter la règle pour netfilter de redirection des requêtes sur le port 80
iptables -t nat -F PREROUTING
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 \

-j REDIRECT --to-port 8080
# Les clients peuvent envoyer leurs requêtes sur le port 80 du proxy
# Le service NAT du routeur les redirige sur le port 8080
Squid dispose d'une fonctionnalité qui permet de passer une URL (requête entrante) à une
application externe. Cela présente l'avantage de pouvoir bénéficier des services d'applications
spécialisées. C'est par exemple le cas pour le redirecteur SquidGuard, largement utilisé pour
protéger les accès sur des sites déclarés comme “ impropres ”. Une base de données de ces sites
est tenue à jour. C'est cette dernière qui est utilisée pour filtrer les accès.
Certaines applications ne sont pas prises en charge par Squid (https, smtp, pop, ftp...). Les
raisons peuvent être diverses. Soit le service n'est pas pris en charge (pop, smtp...), soit il n'est
pas conseillé de stocker en cache certaines informations d'authentification par exemple (https).
Pour les applications ou services non pris en charge par un service proxy, vous devrez utiliser
l'ipmasquerade, un service de translation d'adresse ou utiliser une autre technologie.
Chapter 41. Travaux pratiques : installation de SQUID
Table of Contents
Application

Liens
Annexes
Application
Vous devez maîtriser les techniques de routage avec netfilter.
Vous allez installer un service proxy minimal, configurer les clients puis tester le fonctionnement
de l'accès à internet à partir des clients.
Vous configurerez des ACLs permettant un contrôle d'accès aux données externes, vous ferez
ensuite évoluer cette configuration vers un service mandataire transparent.
Le service proxy sera installé sur le routeur.
Utilisez les éléments de ce document, ainsi que les exemples de fichiers de configuration donnés
en annexe. Vous pourrez également vous référer au document sur netfilter.
Vous avez un routeur qui vous relie au réseau de l'établissement et un client qui représente un
segment de réseau privé. L'ensemble doit fonctionner (accès à internet, résolution de nom,
masquage d'adresse.
iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -j MASQUERADE

# si 192.168.0.0 est le réseau privé
Vérifier que le routeur fonctionne. Faites un test à partir du client. Supprimez au besoin toutes les
règles iptables et activez l'ipmasquerade.
Mettez une règle qui interdise toute requête à destination d'une application HTTP (port 80).
Vérifier que les clients ne peuvent plus sortir.
# Ici on bloque tout, c'est brutal, mais on va faire avec.

iptables -P FORWARD DROP
Faites une sauvegarde de votre fichier de configuration original (/etc/squid.conf). Modifiez le

fichier de configuration de squid en vous appuyant sur celui donné ci-dessous.
http_port 3128
#We recommend you to use the following two lines.
acl QUERY urlpath_regex cgi-bin \?
no_cache deny QUERY
cache_mem 8 MBM
maximum_object_size_in_memory 8 KB

cache_dir ufs /var/spool/squid 100 16 256
cache_access_log /var/log/squid/access.log
cache_log /var/log/squid/cache.log
cache_store_log /var/log/squid/store.log
# Put your FQDN here

visible_hostname freeduc-sup.foo.org
pid_filename /var/run/squid.pid
#Recommended minimum configuration:

acl all src 0.0.0.0/0.0.0.0
acl manager proto cache_object
acl localhost src 127.0.0.1/255.255.255.255

http_access allow manager localhost
http_access allow all
Initialisez l'espace disque pour le cache.
# Vérifiez que le FQDN de votre serveur est renseigné

# et que la résolution de nom locale fonctionne (fichier hosts ou DNS).
# initialisation de la zone de cache
squid -z
# Lancement de squid
/etc/init.d/squid start | restart
Démarrer et vérifier le bon fonctionnement de Squid. Consultez également les journaux.
$>ps aux | grep squid

root 2984 0.0 0.4 4048 1124 ? S 15:22 0:00 \
/usr/sbin/squid -D -sYC
proxy 2987 2.1 1.6 6148 4068 ? S 15:22 0:00 (squid) -D -sYC
Vérifier que le port d'écoute est correct.
mlx@uranus:~$ netstat -atup | grep LISTEN

(Tous les processus ne peuvent être identifiés, les infos sur
les processus non possédés ne seront pas affichées, vous devez
être root pour les voir toutes.)
tcp 0 0 *:3128 *:* LISTEN -
Identifiez l'endroit de stockage du cache sur le disque.
Configurer le client pour qu'il utilise le service proxy sur les requêtes HTTP, vérifier le bon
fonctionnement.
Figure 41.1. Configuration du client

Identifiez les traces dans les journaux.
root@uranus:/home/mlx# more /var/log/squid/access.log

1053864320.437 1741 192.168.0.2 TCP_MISS/200 5552 \
GET http://www.cru.fr/documents/ - DIRECT/195.220.94.166 text/html
1053864320.837 1096 192.168.0.2 TCP_MISS/304 331 \
GET http://www.cru.fr/styles/default.css - DIRECT/195.220.94.166 -
1053864321.257 420 192.168.0.2 TCP_MISS/304 331 \
GET http://www.cru.fr/logos/logo-cru-150x53.gif - DIRECT/195.220.94
1053864321.587 696 192.168.0.2 TCP_MISS/304 331 \
GET http://www.cru.fr/icons-cru/mailto.gif - DIRECT/195.220.94.166
1053864550.537 1461 192.168.0.2 TCP_MISS/200 5552 \
GET http://www.cru.fr/documents/ - DIRECT/195.220.94.166 text/htm
Interdisez tous les accès avec la règle :
Vérifiez le fonctionnement.
Interdisez l'accès à un serveur (google.fr) par exemple. Vérifiez le fonctionnement.
acl google dstdomain .google.fr

http_access deny google
Construisez deux fichiers, l'un qui permettra de stocker des adresses IP, l'autre des mots clés.
Construisez une ACL qui interdit l'accès en sortie aux machines qui ont les adresses IP
déterminées dans le premier fichier, et une ACL qui empêche l'accès aux URL qui contiennent les
mots clés stockés dans le second fichier.
# Exemple de ce que le fichier "adresse_ip" contient :

# Mettez dans la liste des adresses celle de votre client pour tester
192.168.0.2
192.168.0.10
# Exemple de ce que le fichier "mot_cle" contient :

jeu
game
# Exemple d'ACL
acl porn url_regex "/etc/squid/mot_cle"

acl salleTP_PAS_OK src "/etc/squid/adresse_ip"
http_access deny porn
http_access deny salleTP_PAS_OK
Tester le fonctionnement de ces deux ACL. (Utiliser comme url de destination par exemple
http://games.yahoo.com/)
Configurez Squid pour qu'il affiche des pages (messages d'erreur) en Français. Vérifiez le
fonctionnement.
error_directory /usr/share/squid/errors/French
Identifiez la page qui est retournée lors d'un refus d'accès. Modifiez la page et le message
retourné, puis vérifiez le fonctionnement.
Créez un fichier .pac pour la configuration des clients Mozilla. Vous en avez un complet dans la
FAQ de squid. Celui-ci fait le minimum.
function FindProxyForURL(url, host)

{
return "PROXY 192.168.0.1:3128; DIRECT";
}
Mettez le fichier sur votre routeur dans /var/www/mozilla.pac et vérifiez que le serveur apache
est bien démarré. Si la résolution de nom fonctionne, vous pouvez mettre le nom du serveur de
configuration plutôt que l'adresse IP.
Configurez le client :
Figure 41.2. Configuration du client

Testez le bon fonctionnement du client.
Remettez la configuration du client dans sa situation initiale.
Modifier la configuration du client et du serveur, afin que la configuration globale devienne celle
d'un proxy tranparent.
Vous allez modifier le fichier de configuration de squid et configurer votre routeur avec les règles
suivantes si le service proxy est sur le routeur :
# A mettre dans le fichier de configuration de suid

# Relancer le service après
httpd_accel_port 80
# Les règles iptables

# On nettoie la table nat
# On utilise le port 3128, par utilisé par défaut sous Squid.
iptables -t nat -F PREROUTING
# ou toutes les tables nat si besoin

iptables -t nat -F
# On laisse passer (masque) les requêtes autres que sur le port 80

iptables -t nat -A POSTROUTING -j MASQUERADE
# On redirige les requêtes sur le port 80

iptables -t nat -A PREROUTING -j DNAT -i eth1 -p TCP --dport 80 \
--to-destination 192.168.0.1:3128

Supprimer toute configuration de proxy sur le client. Vérifier le bon fonctionnement du client.
Arrêtez les service proxy, vérifiez que les requêtes HTTP des clients ne sortent plus.
Il est possible de séparer les services du routage et proxy sur 2 machines différentes. Le principe
est identique, seules les règles sur le routeur changent un peu. Vous trouverez la description
d'une telle configuration dans :
# Transparent proxy with Linux and Squid mini HOWTO

http://www.tldp.org/HOWTO/mini/TransparentProxy.html
# Lire aussi sur netfilter

http://www.netfilter.org/documentation/HOWTO/fr/NAT-HOWTO.txt
http://www.cgsecurity.org/Articles/netfilter.html
Mettez en place une ACL pour déclarer l'authentification des personnes.
# Ici on utilise le module ncsa_auth

auth_param basic program /usr/lib/squid/ncsa_auth /etc/squid/users
auth_param basic realm Squid proxy-caching web serve
auth_param basic children 5
Créez les fichiers de compte et de mots de passe avec un compte utilisateur.
htpasswd -c /etc/squid/users unUTILISATEUR

# mettez ensuite son mot de passe.
# Testez le fonctionnement du fichier et du module

# Vous passez en paramètre le nom du fichier de comptes
# Vous mettez le compte et le mot de passe, le module retourne OK
# En cas d'erreur il retourne ERR
root@uranus:/etc# /usr/lib/squid/ncsa_auth /etc/squid/users
mlx password
OK
mlx mauvais
ERR
Figure 41.3. Authentification SQUID

Il y a pas mal de différences entre les paramètres des versions de Squid 1, squid 2 et Squid 2.5. Il
est important de consulter les fichiers de documentation fournis avec le produit.
L'authentification ne fonctionne pas avec la configuration d'un proxy transparent.
Liens
1. Squid
2. Le CRU
3. SquidGuard - Université de Toulouse
4. Les HOWTOs
Annexes
Fichier minimal pour Squid
http_port 3128
#Ne pas "cacher" les données des formulaires

acl QUERY urlpath_regex cgi-bin \?
no_cache deny QUERY
cache_mem 8 MBM
maximum_object_size_in_memory 8 KB
cache_dir ufs /var/spool/squid 100 16 256
cache_access_log /var/log/squid/access.log
cache_log /var/log/squid/cache.log
cache_store_log /var/log/squid/store.log
# Ici mettez le nom de votre machine

visible_hostname uranus.freeduc-sup.org
pid_filename /var/run/squid.pid

acl all src 0.0.0.0/0.0.0.0
acl manager proto cache_object
acl localhost src 127.0.0.1/255.255.255.255
# Test des fichiers @ip et mots clés

acl porn url_regex "/etc/squid/mot_cle"
acl salleTP_PAS_OK src "/etc/squid/adresse_ip"
http_access deny porn
http_access deny salleTP_PAS_OK
# Authentification
auth_param basic program /usr/lib/squid/ncsa_auth /etc/squid/users
auth_param basic realm Squid proxy-caching web serve
auth_param basic children 5
#Default:
#http_access deny all
#Messages d'erreurs en FR
error_directory /usr/share/squid/errors/French
# Pour le proxy cache transparent

httpd_accel_port 80
Utiliser des fichiers externes pour la déclaration d'adresses ou de mots clés.
acl salleTP_OK src "/etc/squid/salleTP_OK.txt"

acl porn url_regex "/etc/squid/porn.txt"
acl salleTP_PAS_OK src "/etc/squid/salleTP_PAS_OK.txt"
http access salleTP_OK
http access porn
http deny salleTP_PAS_OK

Utilisation d'une authentification simple similaire à celle mise en oeuvre dans les .htaccess. Créer
le fichier par script ou manuellement avec htpasswd.
authenticate_program /usr/bin/ncsa_auth /etc/squid/users

authenticate_children 5
acl_authenticate_users REQUIRED
http_access authenticate_users
Combinaison par “ ET ” logique des plages horaire et des salles. Mettre la machine à l'heure avec
ntpdate par exemple.
# Interdire les accès en dehors des plages horaires 8h-12h et 14h-18h

S Sunday M Monday T Tuesday W Wednesday H Thrusday F Friday A Saturday
acl am time MTWHF 08:00-12:00
acl PM time MTWHF 14:00-18:00
http_access allow am salleTP_PAS_OK
http_access allow pm salleTP_PAS_OK
Chapter 42. Installation d'un serveur PostgreSQL avec Apache
>Serveur WEB dynamique avec PostgreSQL et PHP
Table of Contents
Avant de démarrer
Accès aux archives
Présentation
Le langage PHP
Exemple de code
Abstract
Création d'un site web dynamique avec PostgreSQL et Apache. Pour PostgreSQL vous pouvez
aussi utiliser la ressource Linux-France.org qui détaille de façon assez complète un mode
d'utilisation de ce serveur de bases de données.

Avant de démarrer
Si vous utilisez la Freeduc-Sup rc3, un bogue empêche PostgreSQL de se lancer. Vous devez
avoir un message d'erreur dans "/var/log/postgres" qui vous indique qu'il n'arrive pas à trouver un
fichier "pg_control".
Voici comment corriger cela : sous le compte root taper
mv /var/lib/postgres/data /var/lig/postgres/data.old
dpkg-reconfigure postgresql
OK
OK
Yes
OK
fr_FR@euro
OK
LATIN1
OK
ISO
European
OK
NO
#C'est terminé, vous pourrez lancer PostgreSQL normalement.
Cela sera corrigé sur la prochaine version.
Vous avez un support de cours, TD et TP assez complet sur Linux-Francequi décrit bien le mode
d'utilisation de PostgreSQL.
Accès aux archives
Vous pourrez récupérer les documents nécessaires sous forme d'archive sur le serveur de linux-
france. Pour cela voir la page d'introduction du document.
Présentation
Accès à une base de données PostgreSQL à partir d'un client WEB (Mozilla ou autres)
On veut à partir d'un client "Web" comme Mozilla (ou autres) interroger une base de données
PostgreSQL. Le client HTTP passe (via des formulaires) des requêtes SQL à un serveur Web
sous Linux (Apache). Celui-ci dispose d'une interface "PHP" qui lui permet d'interroger la base de
données. En fait Apache va "lancer" l'exécution de "scripts PHP" et éventuellement récupérer et
retourner les résultats d'exécution au client.

Les processus mis en jeu côté serveur sont les suivants :
HTTPD qui va permettre les accès via le Web (Gestion des formulaires)
Postmaster qui est le daemon gérant tous les accès à la base.
Le serveur disposera également des documents HTML et des scripts PHP
 Le travail à réaliser en TP consistera donc à :

 - Créer une base de données Postgres
 - Démarrer le daemon postmaster permettant sa gestion
 - Démarrer le daemon HTTPD
 - Accéder à la base de données (via httpd) à l'aide de scripts PHP.
PostgreSQL est un système de gestion de base de données, développé à l'origine par l'université
de Berkeley. Il s'appuie sur les modèles relationnels mais apporte des extensions objet comme :
 les classes,
 l'héritage,
 les types de données utilisateurs (tableaux, structures, listes..),
 les fonctions,
 supporte complètement SQL,
 portable sur plus de 20 environnements depuis la version 6.4.
Cela permet de qualifier PostgreSQL de système de gestion de base de données "relationnel-

objet" (ORDBMS), à ne pas confondre avec les bases de données orientées objets qui ne
supportent pas SQL, mais OQL (Object Query Language).
PostgreSQL est diffusé avec ses sources (licence libre).
Les trois composantes majeures sont :
 un processus de supervision (daemon) qui prend en charge les connexions des clients :
postmaster,
 les applications clientes comme psql, qui permettent de passer des requêtes SQL,
 le ou les serveurs de bases de données (agents). Processus d'ouverture de session : (voir

le schéma d'ouverture de session.)

Description du processus d'ouverture de session
1. Le client passe une requête au daemon postmaster via un socket. Par défaut sur le port
5432. La requête contient le nom de l'utilisateur, le nom de la base de données. Le
daemon, peut à ce moment utiliser une procédure d'authentification de l'utilisateur. Pour
cela il utilise le catalogue de la base de données, dans lequel sont définis les utilisateurs.
2. Le daemon crée un alors un agent pour le client. Le processus serveur répond
favorablement ou non en cas d'échec du démarrage du processus. (exemple : nom de
base de données invalide).
3. Le processus client se connecte sur le processus agent. Quand le client veut clore la
session, il transmet un paquet approprié au processus agent et ferme la connexion sans
attendre la réponse.
4. Plusieurs processus agents peuvent être initialisés pour un même client.
Le dictionnaire :
Comme pour la plupart des systèmes de gestion de données, toutes les informations système
sont stockées dans des tables qui forment le dictionnaire (catalogue ou repository en Anglais).
Utiliser le cataloque est essentiel pour les administrateurs et les développeurs. Vous pouvez voir
la structure et le contenu de ces tables système.
PostgreSQL fournit :
un langage d'administration (création de base, d'utilisateurs)
un langage d'interrogation de données basé conforme à SQL
des extensions C, C++, perl, php, python...
Les comptes utilisateurs :
Le compte administrateur de la base est par défaut " postgres "
il faut créer les comptes utilisateurs
Voir le TP sur HTTP pour obtenir le compte système qui est utilisé par Apache pour les requêtes
http. Sur la freeduc-sup c'est "www-data". Dans la suite du document on utilisera
$COMPTE_HTTP pour parler de ce compte système.
Voici quelques commandes d'administration de base :
Création d'une base de données : createdb
createdb [ dbname ]
createdb [ -h host ] [ -p port ] [ -D datadir ] [ -u ] [ dbname ]
Exemple : createdb -h uranus -p 5432 -D PGDATA -u demo

ou encore createdb demo
Suppression d'une base de données
dropdb [ dbname ]
Exemple dropdb demo
Créer un utilisateur :
createuser [ username ]
createuser [ -h host ] [ -p port ] [ -i userid ] [ -d | -D ] [ -u | -U ] [ username ]
-d | -D permet ou interdit la création de base à l'utilisateur
-u | -U permet ou interdit la création d'autres comptes à l'utilisateur.
Crée un compte dans pg_user ou pg_shadow. (tables système)
Si la base est accessible par Internet (exemple avec PHP), l'accès est réalisé par le compte
" $COMPTE_HTTP ".
Utiliser la commande "select * from pg_user;" pour avoir la liste des utilisateurs.
Supprimer un utilisateur
drop user [ username ]
Accéder à une base:
psql [ dbname ]
psql -A [ -c query ] [ -d dbname ] -e [ -f filename ] [ -F separator ] [ -h hostname ] [ -o filename ] [ -p

port ] -qsSt ]
[ -T table_options ] -ux [ dbname ]
mlx@mr:~$ psql template1

Welcome to psql, the PostgreSQL interactive terminal.
Type: \copyright for distribution terms

\h for help with SQL commands
\? for help on internal slash commands
\g or terminate with semicolon to execute query
\q to quit
template1=#
PHP, (Personal Home Page) est un langage de programmation complet, assez proche du C. Il
fournit :

 des structures de données,
 des structures de contrôle,
 des instructions de gestion des entrées/sorties.
Il est diffusé également sous licence libre. Il permet la création de pages web dynamiques.
Il est considéré comme une alternative à CGI, Perl, ASP (Active Server Page de Microsoft);
Développé à l'origine pour Linux, il est maintenant portable sur plusieurs environnements
( Windows 9.x, NT).
Il fournit des API pour les bases de données Oracle, PostgreSQL, MySQL, DB2 ;, et est conforme
aux standards ODBC et ISAPI
Il fonctionne avec de nombreux serveurs HTTP comme Apache ou IIS (Internet Information
Server) de MS.
PHP peut être utilisé seul ou combiné avec des bases de données et un serveur HTTP (Objet du
TP).
Simple à mettre en oeuvre, documenté, sécurisé et fiable, de nombreux sites (FAI) comme
libertysurf, free mettent cet outil à la disposition des clients.
Sur Linux, PHP est compilé comme un module dynamique ou directement intégré à Apache, ce
qui accroît les performances.
Le code PHP peut être intégré directement dans une page HTML comme vb-script ou à l'extérieur
sous forme de fonctions (comme CGI).
Le code est logé entre deux balises < ? Ici le code ?>. Il est possible que pour assurer la
compatibilité avec XML, les balises deviennent : <php et ?>
L'extension généralement utilisée pour les documents PHP est .php. Voir ci-dessous l'exemple
" test.php " qui permet de vérifier le support de PHP par votre environnement.
Listing : test.php
<?
echo (" Test du module PHP ");
phpinfo();
?>
Le langage PHP
Le guide utilisateur et ses extensions comprennent plus de 300 pages (voir les sources de
documentations plus bas). La description ci-dessous donne les principales instructions pour les
accès à une base de données PostgreSQL.
pg_Connect : Connexion à une base de données :

int pg_connect(string host, string port, string options, string tty, string dbname);
Retourne faux si la connexion échoue, un index dans l'autre cas. Il peut y avoir plusieurs
connexions.
Exemple : $conn = $conn = pg_Connect("localhost", "5432","","", "template1");
Ou : $conn = pg_connect("dbname=marliese port=5432");
pg_Close : Fermer une connexion
bool pg_close(int connection);
pg_cmdTuples : Donne le nombre de tuples affectés par une commande insert,
update ou delete. Renvoie 0 sinon.
int pg_cmdtuples(int result_id);
Exemple :
<?php
$result = pg_exec($conn, "INSERT INTO verlag VALUES ('Autor')");
$cmdtuples = pg_cmdtuples($result);
echo $cmdtuples . " affectés.";
?>
string pg_dbname(int connection);
Donne le nom de la base de données.
Exemple $NomBase = pg_Dbaname ($conn);
pg_ErrorMessage :
string pg_errormessage(int connection);
Message d'erreur renvoyé par le serveur
pg_Exec : int pg_exec(int connection, string query);
Exécute une requête.
$UneChaineSQL = "Select * from UneTable");
Exemple : $result = pg_exec($conn, $UneChaineSQL);
pg_FieldName : string pg_fieldname(int result_id, int field_number);
Renvoie le nom du champ d'indice field_number ;

Exemple :
indice = 0
While (indice [lt ] NombreDeChamp)
$NomChamp = pg_fieldname($result, indice)
echo $NomChamp
indice ++;
pg_FieldNum : int pg_fieldnum(int result_id, string field_name);
Donne l'indice pour un nom de champ.
pg_Host : string pg_host(int connection_id);
Donne le nom du Host
pg_NumFields : int pg_numfields(int result_id);
Renvoie le nombre de champs de la requête.
Exemple : $numF = pg_Numfields($result);
pg_NumRows : int pg_numrows(int result_id);
Renvoie le nombre de tuples (enregistrements) de la requête.
Exemple : $numR = pg_NumRows ($result);
if ($numR == 0)
echo "Aucun enregistrement retourné. ";
exit;
pg_Result : mixed pg_result(int result_id, int row_number, mixed fieldname);
Renvoie la valeur d'un champ, pour un n° d'enregistrement donné et un résultat de requête. Les
numéros d'enregistrement et de champ commencent à 0.
Exemple avec $i - indice d'enregistrement et $j - indice de champ :
$Valeur = pg_result ($conn, $i, $j)

pg_Options : pg_Options (int connection_id);
Renvoie une chaîne contenant les options de connexion à la base.
pg_FreeResult : int pg_freeresult(int result_id);
Libérer la mémoire.
Autres fonctions de base :
pg_Fetch_Array, pg_Fetch_Object, pg_Fetch_Row, pg_FieldsNull, pg_PrtLen,
pg_FieldSize, pg_FieldType, pg_GetLastOid, pg_port, pg_tty.
Vous trouverez la documentation de ces commandes dans celle de PHP.
 Une requête SQL est passée par un formulaire HTML ou autre et via le protocole HTTP
 Le serveur Apache reçoit la requête HTTP
 Le module PHP exécute la requête sur la base PostgreSQL en utilisant les API
 Le code PHP met en forme le résultat de la requête
 La page est remise au serveur Apache
 Le serveur Apache retourne le résultat au client.
Vous avez deux méthodes pour passer les paramètres au serveur : la méthode "GET" et al
méthode "POST".
Exemple de code
Voici un exemple de formulaire html et le script PHP associé.
Le formulaire : formsql.html
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">

<html>
<head>
</head>
<body>
Lancement d'un formulaire de requête SQL via un serveur HTTP
Utilise une base Demo
<br>
Entrez une chaîne sql valide - Exemple :
<form action="resultsql.php" METHOD=post> // Ici le script qui sera exécuté

<textarea cols="50" rows="5"
name="c_SQL">Select * from phonebook ;</textarea></p>
<br>
<INPUT TYPE="submit" VALUE="Search!">
</form>
</body>
</html>
Figure 42.1. Formulaire de saisie
Le script associé : Page resultsql.php
'Solution qui permet de s'affranchir du nombre de champs.

<?
/* Test de la connexion à la base */
if($c_SQL != "")
{
echo $c_SQL ;
$conn = pg_Connect("localhost","5432","","","demo");
if (! $conn)
{
echo "Erreur de connection à la base. \n";
exit;
}
/* teste le résultat de la requête */

$result = pg_Exec($conn, $c_SQL);
if (! $result)
{
echo "Erreur d'accès aux tables. \n";
exit;
}
/* teste le nombre de tuples retournées */

$numR = pg_NumRows ($result);
if ($numR == 0)
{
echo "Aucun enregistrement retourné. \n";
exit;
}
/* Compte le nombre de champs */

$numF = pg_Numfields($result);
/* mise en forme du résultat sous forme tabulaire */

/* lignes (tuples), colonnes (champ) */
echo "<table border = 1>";
$i = 0;
while ($i < $numR) {

echo "<tr>";
$j = 0;
while ($j < $numF) {
$nc=pg_result($result,$i,$j);
echo "<td>"; echo $nc; echo "</td>"; $j++;
}
echo "</tr> \n";
$i++;
}
echo "</table> \n";
/* Libère la mémoire */
pg_FreeResult;
/* Ferme la connection */
pg_Close($conn);
}
?>
Figure 42.2. Résultat de la requête
Chapter 43. Travaux pratiques : PostgreSQL
Table of Contents
Présentation
PostgreSQL
Test de la base
TP de synthèse

Présentation
Accès à une base de données PostgreSQL à partir d'un serveur Apache. Utilisation du langage
PHP.
La maquette terminée devrait permettre, à partir d'un client HTTP comme Netscape de passer des
requêtes SQL à un serveur Apache. Le serveur Apache dispose d'une interface PHP, qui lui
permet d'échanger avec une base de données PostgreSQL .
Vous devrez récupérer pour le TP les documents suivants :
1. Le script de création de la base de démo "formdemo.sql"

2. le document HTML "formsql.html"
3. le document php "resultsql.php"
PostgreSQL
Connectez-vous en tant que root.
1 Préparation de la configuration
Installez les packages correspondant à PostgreSQL et à PHP s'ils ne sont pas déjà installés.
2 Configuration de Postgres
2.1 Postgres est installé. Le script de lancement est dans "/etc/init.d"
Editez ce script et relevez l'emplacement où sont stockées les bases de données.
Recherchez le port et les protocoles de transports utilisés par PostgreSQL avec la commande
"grep postgres /etc/services"
Vérifiez que le fichier "/etc/postgresql/postmaster.conf" comporte bien la ligne

"POSTMASTER_OPTIONS="-i -p 5432". Cela permet de définir le numéro de port, et d'inquer à
PostgreSQL de supporter les sessions sockets (-i).
Vous allez configurer les options de sécurité permettant au serveur de recevoir des requêtes.
Ouvrez le fichier "/var/lib/postgres/data/pg_hba.conf". Recherchez les lignes ci-dessous :
# Put your actual configuration here
# ----------------------------------
host all 127.0.0.1 255.0.0.0 ident sameuser
host all 0.0.0.0 0.0.0.0 reject
Modifiez ces lignes après avoir fait une copie de sauvegarde de ce fichier, de la façon suivante :

host all 127.0.0.1 255.0.0.0 trust
host all x.y.z.t x'.y'.z'.t' trust
Vous adapterez "x.y.z.t" à l'adresse de votre réseau et "x'.y'.z'.t'" au masque de votre réseau.
2.2 Il s'agit maintenant d'activer le service. Utilisez les commandes :
/etc/init.d/postgresql stop
/etc/init.d/postgresql start
Vérifiez le chargement de postgres dans la table des processus : "ps aux | grep post"
Vérifiez dans les journaux les messages d'erreurs si le serveur ne démarre pas.
Vérifiez également :
- qu' un service n'est pas déjà actif,
- que les variables sont bien déclarées. En général les messages de Postgres sont assez clairs et
donnent la marche à suivre pour corriger. N'allez pas plus loin tant que tout cela ne fonctionne pas
parfaitement.
3 Tester la configuration
La procédure précédente à créé un modèle de base de données "template1", qui sert de modèle
pour la création d'autres bases, et a créé un compte d'administrateur de base de données
"Postgres". Toujours en mode commande et en tant qu'utilisateur postgres (su postgres), vous
allez utiliser la commande suivante :
psql template1
Attention, il n'y a qu'un seul compte de base de données, celui de l'administrateur "postgres".
Vous allez ouvrir une session sous le compte "root" puis passer sous le compte "postgres" avec la
commande "su postgres".
Vous devriez obtenir ceci :
# su postgres
sh-2.05b$ psql template1
Welcome to psql, the PostgreSQL interactive terminal.
Type: \copyright for distribution terms
\h for help with SQL commands
\? for help on internal slash commands

\g or terminate with semicolon to execute query
\q to quit
template1=#
Le caractère "=>" est le prompt du mode commande. Vous pouvez désormais taper des
commandes.
Retenez "\q" pour quitter.
Pour avoir de l'aide sur l'interpréteur de postgres : template1=> \?
Pour avoir de l'aide sur les commandes SQL : template1=> \h
Si l'aide s'affiche, c'est que tout fonctionne. Par contre vous ne pouvez pas faire grand chose, la
base et vide. Vous pouvez le vérifier avec la commande "\dt".
template1=>\dt
Couldn't find any tables!
template1=\q
Tout autre message, signifie qu'il y a un problème de configuration. Si c'est le cas vérifiez
soigneusement tous les paramètres.
4 Conclusion
Votre environnement fonctionne et est bien configuré. La prochaine étape consiste à se

familiariser avec les premières commandes d'administration et d'utilisation.
Test de la base
1 Créer une base de données
1 - Création de la base :
Vous devez avoir récupéré le script de création de la base "formdemo.sql"
su postgres (Vous devez être administrateur de la base)
createdb demo (création d'une base de données s'appelant demo)
2 - Création des tables de la base demo :
psql demo < formdemo.sql
2 Test de la base de données

Vous allez, au préalable, tester le fonctionnement de tout cela à partir du compte Administrateur
"postgres". Pour cela utilisez les commandes suivantes :
psql demo
# Pour afficher les tables
=> \dt
# consultez la table phonebook. Vous devriez avoir le résultat.
=>select * from phonebook; (Ne pas oublier ;)
#quitter
=> \q
3 Créer un compte d'utilisateur de base de données
Vous allez créer et utiliser deux comptes utilisateurs de bases de données. "$COMPTE_HTTP"
qui est utilisé pour les accès HTTP, "TP1 " que vous utiliserez comme compte local. Vous leur
affecterez pour l'instant les droits minimums.
3.1 Normalement le compte système$COMPTE_HTTP existe déjà, vous pouvez vérifier avec
"grep $COMPTE_HTTP /etc/passwd". Si ce n'est pas le cas, vous devrez créer un compte
système pour $COMPTE_HTTP.
3.2 Création du compte système "TP1"
# Création du compte
adduser TP1
# affectation d'un mot de passe.
passwd TP1
3.3 Vous allez créer les comptes de base de données pour $COMPTE_HTTP et TP1. Attention
aux réponses que vous mettrez car $COMPTE_HTTP ne doit pas avoir la possibilité de créer des
tables, ni créer d'autres comptes de bases de données.
3.3.1 Création du compte anonyme $COMPTE_HTTP
#passer en DBA (Data Base Administrator)
su postgres
$ createuser $COMPTE_HTTP
Enter user's postgres ID or RETURN to use unix user ID: 99 ->
Is user "$COMPTE_HTTP" allowed to create databases (y/n) n
Is user "$COMPTE_HTTP" allowed to add users? (y/n) n

createuser: $COMPTE_HTTP was successfully added
#c'est terminé, voilà le résultat :
demo=# \q
sh-2.05b$ createuser www-data
Shall the new user be allowed to create databases? (y/n) n
Shall the new user be allowed to create more new users? (y/n) n
CREATE USER
sh-2.05b$
3.3.2 Création d'un compte DBA TP1
#passer en DBA (Data Base Administrator)
su postgres
$createuser TP1
Enter user's postgres ID or RETURN to use unix user ID: 501 ->
Is user "TP1" allowed to create databases (y/n) y
Is user "TP1" allowed to add users? (y/n) y
createuser: TP1 was successfully added
#c'est terminé
3.3.3 $COMPTE_HTTP n'a aucune permission sur les bases de données. Vous allez lui donner la
permission de faire des "select".
Utilisez les commandes suivantes :
psql demo
grant select on phonebook to $COMPTE_HTTP ;
demo=# grant select on phonebook to "www-data";
GRANT
demo=#
\q
4 Tester l'accès des comptes

Ouvrez une session avec le compte TP1 que vous avez créé.
psql demo
# Pour afficher les tables
=> \dt
# consultez la table phonebook. Vous devriez avoir le résultat.
=>select * from phonebook; (Ne pas oublier le ;)
#quitter
=> \q
Démarrez le serveur Apache : /etc/init.d/apache restart
Vérifiez que le serveur est bien actif et opérationnel.
Cherchez et relevez l'emplacement de stockage (Home Directory) des pages html d'Apache.
Vérification de la prise en charge de php par apache :
Normalement il n'y a plus rien à faire. Il s'agit de vérifier que le module PHP est bien pris en
charge par Apache. Voici comment procéder:
1 - Créer dans Home Directory d'Apache le document testphp.php suivant:
<? echo ("Test du module PHP");
phpinfo();
?>
2 - Lancez un navigateur (à partir de votre poste ou d'une autre machine) et tapez l'url "http://@IP
de votre PC/testphp.php » .
Deux solutions :
 soit le résultat est bon, la fonction "phpinfo()" vous retourne des informations sur le module
et sur Apache. Dans ce cas vous pourrez continuer,
Figure 43.1. Interrogation de PHP

 soit ce n'est pas le cas, il faut revoir la configuration.
Le serveur HTTP et le client fonctionnent, php est pris en charge par le serveur Apache.
Maintenant, nous allons créer un formulaire qui permet de passer des requêtes SQL sur la base et
un script qui exécute ces requêtes.
1 Test de la demo
1.1 En fait il s'agit de deux documents (formsql.html et resultsql.php) :
 le premier est une page HTML qui permet de saisir et "passer" des requêtes SQL,
 le deuxième au format PHP, met en forme le résultat de la requête.
1.2 Installez les pages fournies dans le répertoire d'Apache.
Lancez ensuite un navigateur. Tapez l'url http://@IP du PC/formsql.html. Vous pouvez saisir une
chaîne sql et "envoyer" le formulaire.
2 Modifications
a) Copier insert.html dans le répertoire d'Apache, modifiez les permissions du compte

$COMPTE_HTTP afin de lui donner la possibilité d'insérer des tuples dans la base de données.
Modifiez le document resultsql.php afin de pouvoir réaliser des insertions dans la base. Les
enregistrements à insérer seront saisis dans insert.html.
Figure 43.2. Formulaire insert.html

TP de synthèse
Durée de réalisation 20h en binômes
Vous allez créer une base de données conforme au schéma relationnel suivant :
cours (cours_no, cours_lib)
etudiant (etu_no, etu_nom)
inscrit(cours_no, etu_no)
On demande de développer l'interface web qui permet de :
1. ajouter nouveau cours

2. supprimer un cours
3. modifier le libellé d'un cours
4. ajouter un étudiant à un cours
Chapter 44. Surveillance, continuité de service
Sylvain Cherrier
Table of Contents
Le matériel

Le logiciel
les pré-requis
L'installation
Mise en route
Exercices
Abstract
Heartbeat, logiciel de gestion de cluster pour la haute disponibilité (d'après Linux Magazine Hors
Série 18 - Haute Disponibilité)
La continuité de service consiste à garantir la disponibilité de votre service. Si le serveur qui est
chargé d'offrir ce service tombe en panne, il faut être capable de basculer rapidement sur une
machine de secours. De même, il faudra gérer la remise en service du serveur principal. C'est le
rôle de HEARTBEAT que je vous propose d'installer ici...
Afin de garantir la continuité de service, nous devonsons utiliser des machines strictement
identiques au niveau du contenu et des services offerts. Le rôle de hearbeat, c'est la surveillance
de la machine principale par la (ou les) machine(s) de secours, et son activation en cas de
défaillance du serveur principal. La synchronisation des contenus et des réglages n'est pas
assurée par Heartbeat (pensez y notamment pour les contenus dynamiques, tels que les bases
de données. Il faudra trouver une solution pour copier les contenus). Ces machines fonctionneront
en cluster, c'est à dire qu'elles formeront à elles toutes UNE PSEUDO MACHINE.
Ainsi, définissons notre pseudo machine : 192.168.1.100.
Nos deux machines réelles auront pour adresses respectives 192.168.1.1, et 192.168.1.2.
Example 44.1. le cluster
le cluster (virtuel) www : 192.168.1.100
la première machine srv-principal : 192.168.1.1
la deuxième machine srv-secours : 192.168.1.2
C'est le cluster qui sera visible pour les clients. Ainsi, vous mettez à disposition la machine www
(192.168.1.100). On décidera par exemple que c'est réellement la machine srv-principal
(192.168.1.1) qui assure ce service, secondée par srv-secours (192.168.1.2).
Si d'aventure srv-principal tombait, alors très rapidement srv-secours le détectera, se donnera

l'adresse IP de www (192.168.1.100), lancera des services selon sa configuration.
Au retour de srv-principal , on pourra, selon le fichier de configuration, continuer le service sur le

serveur de secours, ou redonner la charge au serveur principal. Là encore, si il y a transfert
d'identité, les scripts seront exécutés à nouveau (arrêt sur srv-secours, et lancement sur srv-
principal).

Le matériel
Plusieurs solutions :
 Soit utiliser le réseau existant entre les machines, mais alors l'ensemble du réseau risque
d'être pollué par des messages UDP,
 Soit utiliser de nouvelles cartes réseaux pour relier les différents noeuds du cluster (leur
propre réseau de surveillance),
 Soit utiliser un câble NULL MODEM pour relier les deux noeuds du cluster par l'interface
série (pour seulement deux machines).
Il est preferable de privilégier une communication spécifique entre les noeuds du cluster, afin de
ne pas polluer le réseau avec les diffusions UDP associées au service Heartbeat. Ce faisant, on
rencontre le problème suivant : On ne teste pas la rupture du câble réseau, ou un problème de
carte réseau. Seul l'arrêt complet de la machine est testé (plus de signal sur le port série).
La surveillance sur le réseau de production
Cette méthode a l'inconvénient de polluer le réseau, et de modifier les éventuelles règles du

firewall, car Heartbeat utilise des trames UDP sur le port 694 (configurable). Cet inconvénient est
compensé par la surveillance de la rupture du câble, ou d'une défaillance quelconque du réseau
en lui-même.
Le NULL-MODEM sur le port série
Le câble NULL MODEM permet d'échanger des données sur les prises séries de deux machines.
Sous Linux, le port série est accessible (/dev/ttyS0 ) comme tout périphérique. Pour le tester,
envoyez des données par une redirection :
Example 44.2. Après avoir connecté le NULL MODEM
Sur la première machine, lire le port série :
cat /dev/ttyS0
Sur l'autre machine, envoyer des données dans le port série :
echo "test" > /dev/ttyS0
Sur la première machine, le mot test devrait apparaître...
Le réseau de surveillance
Vous pouvez choisir de monter un réseau spécifique chargé de faire circuler les informations de
contrôle des différents noeuds. Grâce à des cartes réseaux et un hub ou un switch (voir un simple
câble croisé si il n'y a que deux noeuds). Dans ce cas, vous pouvez choisir par exemple
d'adresser ce réseau en 10.0.0.0, et de construire la structure suivante :

Example 44.3. le cluster en réseau doublé
le cluster (virtuel) www : 192.168.1.100
la première machine srv-principal :
 eth0 : 192.168.1.1
 eth1 : 10.0.0.1
la deuxième machine srv-secours
 eth0 : 192.168.1.2
 eth1 : 10.0.0.2
Ici, le contrôle du fonctionnement de votre réseau de surveillance se fera par les outils habituels
tel que ping,nmap,iptraf, comme pour le réseau de production.
Le logiciel
les pré-requis
Il est impératif de contrôler les points suivants :
 Le nom que vous utiliserez pour désigner votre machine doit bien être celui donné par la
commande uname -n. Sinon, le logiciel le refusera. (Pour définir le nom d'une machine, il
faut renseigner le fichier /etc/hostname.
 De même, les noms utilisés pour désigner les autres noeuds (machines) de votre cluster
doivent être connus par chaque machine, soit par l'utilisation d'un dns, soit par le fichier
/etc/hosts.
L'installation
Sur une debian stable, l'installation se fait par la méthode standard :
apt-get install heartbeat
Debconf va ensuite vous aider à configurer ce service (pas sur sarge). J'ai preferé construire mes
fichiers de configuration manuellement.
Il y a trois fichiers de configuration principaux :
 ha.cf contient les réglages de la machine réelle.

 haresources contient les réglages du cluster (la machine à simuler).
 authkeys contient les modes d'authentification (utile si on utilise le réseau de production).

Il est important de noter qu'haresources décrit le cluster tel qu'il doit être vu (notamment la 'fausse'
adresse IP), tandis qu'ha.cf décrit le fonctionnement du noeud réel. Ainsi, ha.cf pourra varier selon
les machines (nom de la carte réseau différent, logs réglés différemment) alors que haresources
est lui PARTOUT IDENTIQUE (tous les noeuds doivent être d'accord sur le cluster à simuler).
Le fichier ha.cf
petit tour du propriétaire :
 choix de médium de surveillance
la carte réseau
bcast eth0
le câble NULL MODEM
baud 19200
serial /dev/ttyS0
 logs
Les pépins
debugfile /var/log/hda-debug
Les évènements
logfile /var/log/hda-log
la facility (la sémantique des messages, voir le cours sur syslog)
logfacility local0
 délais de réaction (en secondes)
délai entre deux 'pouls'
keepalive 2
durée du silence avant de déclarer un noeud 'mort'
deadtime 10
durée du silence avant de déclencher une alerte
warntime 8
temporisation lors du lancement du service (si un noeud est lent)
initdead 30
 réglages generaux
port UDP pour le 'pouls'

udpport 694
liste des noeuds participants au cluster (Attention, tous les participants doivent connaitre la
liste exhaustive des noeuds concernés)
node srv-principal
node srv-secours
le serveur principal reprend la main lors de son retour
nice_failback on
La première partie permet de définir le mode d'écoute du logiciel de surveillance. Il semble que
l'emploi du port série implique de bien définir les bauds avant. Vous pouvez combiner plusieurs
modes d'écoute, c'est alors le silence sur tous ces médias qui entraînera les actions d'heartbeat .
La partie sur les logs permet de bien contrôler le fonctionnement du logiciel et valider les
échanges entre les différents noeuds. Vous pouvez choisir les noms de fichiers que vous désirez,
ainsi que la facility (pour le traitement par le démon syslogd).
La gestion de temps de réaction peut être donnée en millisecondes (par défaut, elle est en
seconde) en ajoutant le suffixe ms (keepalive 200ms). Attention au initdead qui permet de gérer
un noeud un peu lent à démarrer, et ainsi éviter de l'exclure immédiatement du cluster. La
documentation préconise de doubler au minimum ce temps par rapport au deadtime.
Enfin, partie TRES IMPORTANT, la liste des noeuds qui participent au cluster. Lorsque tous les
noeuds seront actifs, alors heartbeat activera le cluster et les services qui lui sont associés (les
services démarreront à ce moment là, sur la machine qui est porteuse de l'adresse ip du cluster).
Ce fichier peut legerement différer selon les noeuds, dans les deux premières parties uniquement
(puisque ce fichier définit les caractéristiques techniques sécifiques à ce noeud).
exemple de fichier ha.cf
On écoute sur le port série, les deux noeuds s'appellent hypérion et endymyon, et on ne loggue
rien.
baud 19200
serial /dev/ttyS0
keepalive 2
deadtime 10
warntime 8
initdead 30
node hyperion
node endymion
On a maintenant un cluster de trois machines ubik, slans et fundation. La surveillance se fait via
un réseau spécifique (sur la deuxième carte réseau), et on veut logger les informations, identifiées
comme informations de programmes serveurs.
bcast eth1
udpport 694
logfile /var/log/heartbeat.log
logfacility daemon
keepalive 2
deadtime 10
warntime 8

initdead 30
node ubik
node slans
node fundation
Le fichier haresources
Fichier de description du cluster a simuler. IL DOIT ETRE IDENTIQUE SUR TOUS LES NOEUDS
!. Ce fichier décrit la machine maître parmi tous les noeuds du cluster, la ou les adresses IP à
simuler, et les services à assurer sur ce cluster.
Dans notre exemple, si on veut que notre cluster www ait l'adresse IP 192.168.1.100, que srv-
principal soit la machine qui assure prioritairement ce rôle, et que www soit un serveur Web et
mysql, alors tous les noeuds auront le fichier haresources suivant :
Example 44.4. haresources pour tous
srv-principal 192.168.1.100 apache mysql
Avec un tel fichier, automatiquement, dès la mise en route du cluster, (c'est à dire quand toutes
les machines qui participent au cluster auront démarrées) le service Web et le serveur de base de
données seront automatiquement activés. Si le serveur principal tombe, alors le serveur de
secours prend le relais, lance le Web et Mysql, se donne la bonne adresse IP, fait un broadcast
ARP pour avertir le réseau...
En cas de problème (unable to find an interface for ip), on peut etre plus précis sur l'adresse IP du
cluster. Ainsi, on peut indiquer le nombre de bits du masque, et même la carte réseau qui doit
porter l'alias (En théorie, cela devrait être résolu automatiquement... Vous remarquerez que, dans
ce cas, les fichiers diffèrent légèrement sur chaque machine).
Exemple, dans lequel c'est hyperion qui doit être le maître, en prenant l'adresse 192.168.4.200 sur
sa carte eth1
hyperion 192.168.4.200/24/eth1 apache postfix
Le fichier authkeys
Ce fichier détermine le niveau de securite des échanges entre les différents noeuds du cluster. Si
vous êtes sur un médium fiable, vous pouvez utiliser le niveau le plus bas de sécurité (crc =
simple contrôle de contenu, par l'utilisation d'une somme de contrôle, aucun cryptage). Il est
possible d'utiliser des systèmes plus puissant (crypté avec md5 ou mieux encore (mais plus
gourmand en temps processeur) sha). Dans les deux derniers cas, il faut fournir une clé... Cette
clé (ou plutot ce fichier authkeys sera présent et identique sur chacun des noeuds.
Example 44.5. authkeys
auth 1
1 md5 "cluster cluster password"
2 crc
3 sha "conquistador"
Dans cet exemple, les trois modes sont prêts à fonctionner, avec les clés associées aux services,
et c'est le md5 qui est choisi (auth est à 1). Ces clés doivent bien sur être les mêmes sur
l'ensemble des noeuds participant au cluster.

Attention aux droits sur ce fichier de sécurité (600).
Autre exemple de fichier authkeys
auth 1
1 crc
Mise en route
Tous les fichiers de configuration mis en place sur tous les noeuds, vous pouvez alors lancer le
service (pour les recopies, vous pouvez éventuellement vous aider de scp). le lancement du
service se fait de la façon habituelle.
/etc/init.d/heartbeat start
Des que le cluster est constitue (tous les noeuds sont actifs), alors srv-principal héritera d'une
nouvelle adresse IP (en ip-aliasing) 192.168.1.100, et les services apache et mysql seront alors
lancés (si ce n'était déjà fait). Les scripts de lancement apache et mysql sont ceux trouvés à
l'endroit habituel (/etc/init.d). Le cluster fonctionne, et les clients peuvent s'y connecter.
Vous pouvez (VOUS DEVEZ !!) surveiller les fichiers de logs (grâce à tail -f /var/log/ha-log), et
faire joujou en coupant brutalement le courant sur le serveur principal. Testez le nice_failback, la
mise en route de différents services, ainsi que le réseau (ifconfig sur les noeuds, et sniff du réseau
pour voir les broadcast ARP lors des changements de serveurs...
Exercices
1. Montez deux machines qui formeront le cluster, connectées à un réseau qui comporte
aussi un client. Le client aura l'adresse IP 192.168.1.1, les deux serveurs 192.168.1.100 et
101. Le cluster aura l'adresse 192.168.1.200.
2. Connectez le câble NULL MODEM. Vérifiez son bon fonctionnement.
3. installez Heartbeat. Configurez le simplement, avec le 'pouls' sur le port série. Pour le
moment, on ignore les différents services, seule l'adresse IP doit être gérée par le cluster.
4. Sur le premier serveur, lancer heartbeat. Visualisez en continu le fichier de logs. Contrôlez
les informations réseaux.
5. Sur le second serveur, lancer heartbeat. Visualisez en continu le fichier de logs.
6. Contrôlez le premier serveur : fichier de logs, et paramètres réseaux. Que remarquez

vous ?. Faites des pings du cluster (192.168.1.200), et des deux serveurs. Contrôlez le
contenu du cache arp (arp -a). Que remarquez vous ?
7. Eteignez violemment le serveur principal. Consultez les logs du serveur secondaire. Que
s'est il passé ? Affichez les informations réseaux. Que remarquez vous ? Affichez le cache
arp du client. Que remarquez vous (bien que vous n'ayez lancé aucune demande de
résolution arp) ?
8. Heartbeat émet un 'flood' de réponses ARP (bien que personne n'ait posé de questions
ARP) afin de forcer la mise à jour des caches ARP de tous les clients, le plus rapidement

possible. Essayez de visualiser ces réponses ARP, en sniffant le réseau à partir du client,
et en relançant le serveur principal. Vérifiez grâce aux logs, à ifconfig, et à votre sniff
réseau l'ensemble des caractéristiques du logiciel.
9. Modifiez la configuration sur l'ensemble des noeuds afin de créer un cluster dont l'adresse
est 192.168.1.210, et qui assure le fonctionnement d'un serveur Web et d'une base de
données MySql. Le pouls sera émis sur le port série et sur la carte réseau. Enfin, la remise
en route du serveur principal ne déclenchera pas sa promotion, le serveur de secours
restant le support du service jusqu'à sa défaillance. Vérifiez bien que les deux services à
assurer ne sont pas lancés lors de l'init de la machine.
10. Lancez le service heartbeat sur le premier serveur. Apache et MySql se lancent ils ?
11. Lancez le service heartbeat sur le second serveur. Apache et MySql se lancent ils ?
12. Testez le service à partir du client. Sniffez le réseau.
13. Eteignez le premier serveur. Que se passe t'il sur le second ? Vérifiez si tous les services
sont bien lancés. Arrêtez le sniff réseau du client. Retrouvez le 'pouls', l'arrêt de celui-ci,
puis le flood de réponse ARP.
Chapter 45. Lilo : Linux Loader
Table of Contents
Objectifs
Lilo
Documentation
Avant de commencer
Linux SGF
Les partitions
Disque IDE ou EIDE
Disques SCSI
Restriction du BIOS
Installation
MBR et PBR
Installer Lilo
Dos ou Windows 9.x
Windows NT

Lilo
Exécution de Lilo
Désinstaller Lilo
Choix du système
Loadlin
rdev
initrd
Modules
initrd (suite)
Conclusion
Abstract
Desciption des mécanismes de boot avec lilo
Le démarrage de votre système GNU/Linux ou d'autres systèmes, c'est le rôle de LILO
Objectifs
 Comprendre le fonctionnement de Lilo

 Adopter une stratégie d'installation de Linux
 En particulier : Lilo est un chargeur de Linux, LInux LOader
 En général : Lilo est un chargeur de systèmes d'exploitation
Lilo permet de charger sur une machine:
 plusieurs systèmes d'exploitation différents (multi boot)
 plusieurs noyaux différents de Linux (ex: pour des tests)
Lilo
Prend en charge :
 les différentes partitions d'amorçage

 le chargement de Linux (disquette ou disque dur)

 la cohabitation d'autres systèmes (ex: Windows, *BSD, NT, ...)
D'autres systèmes ont des chargeurs de systèmes. Si Lilo est le principal chargeur des systèmes
il est :
 le chargeur principal, sinon il est
 le chargeur secondaire
« Lilo est limité à 1024 cylindres. » FAUX !
Les versions récentes de lilo utilisées depuis Debian Potato supportent lba32. Si le BIOS de la
carte mère est assez récent pour supporter lba32, lilo devrait être capable de charger au-delà de
la vieille limite des 1024 cylindres. Assurez-vous simplement d'ajouter la ligne « lba32 » vers le
début de votre fichier /etc/lilo.conf si vous avez gardé une ancienne version de ce fichier.
Documentation
 la documentation de lilo : en général dans /usr/share/doc/kernel-doc-(version) ou

/usr/doc/kernel-doc-(version)
 les pages de manuels : man lilo lilo.conf
 la documentation de votre distribution
 le guide du ROOTard
Avant de commencer
Lilo a besoin d'informations pour accéder au répertoire /boot Ce répertoire est normalement sur la
partition principale appelée / ou racine (root). quelques rappels et précisions sur :
 le système de gestion de fichiers (sgf) de Linux,
 les systèmes de partitions des disques.
Linux SGF
Exemple de partitionnement qu'il faudra adapter à votre environnement.
/ (root) Fichiers de démarrage (/ + /boot + /bin + /sbin) (min 50MB)

/boot Partition contenant les images du noyau (Kernel) (Min 16MB)
/tmp Fichiers temporaires du système et des utilisateurs (min 100MB)
/var Journaux, spool (/var/log, /var/spool) (min 100MB)
/home Fichiers utilisateurs (min 100MB)
/usr Applications (min 300MB à 700MB avec X)
/usr/local Applications (en général hors distribution) (100MB)
/usr/src Sources des packages et du noyau

swap Fichier d'échange, à adapter en fonction de la RAM (en général 2 ois la
taille de la RAM)
Lignes directrices pour la mémoire
Ce qui suit sont des indications grossières pour la mémoire.
4 Mo : Minimum suffisant pour faire fonctionner le noyau Linux.

16 Mo : Minimum pour un usage du système en mode console.
64 Mo : Minimum pour un système X simple.
128 Mo : Minimum pour le système X avec GNOME/KDE.
256+Mo : Confortable pour le système X avec GNOME/KDE.
L'option de boot mem=4m (ou lilo append="mem=4m") montrera comment le système se

comporterait en ayant 4Mo de mémoire installée. Un paramètre de démarrage pour lilo est requis
pour un système ayant plus de 64Mo de mémoire avec un vieux BIOS.
En fonction de la destination du serveur (impression, mail, news, ...), il faudra prévoir une partition
ou un disque pour les sous-systèmes.
Les partitions
 Un système de disque comporte un disque système ou une partition système, c'est le

disque ou la partition de BOOT
 Un disque peut comporter plusieurs partitions primaires dites d'amorçage. Une partition
d'amorçage est une partition sur laquelle il est possible d'amorcer un système
d'exploitation. Ces partitions sont appelées partitions primaires.
 Sous Linux chaque disque peut comporter 4 partitions. 3 partitions primaires et une
partition étendue, ou bien 4 partitions primaires par exemple.
 Un disque peut supporter jusqu'à 16 partitions. Exemple : 3 partitions primaires plus 12

partitions logiques sur une partition étendue.
Disque IDE ou EIDE
Si vous avez 2 bus IDE1 et IDE2 avec 2 disques chacun vous pouvez:
 installer Linux (/boot) sur n'importe quelle partition primaire d'un des disques,
 installer Lilo sur le MBR du disque système si Lilo est le chargeur primaire,
 installer Lilo sur le PBR de la partition de Linux s'il y a un autre chargeur.
Si vous avez un lecteur CDROM en deuxième lecteur sur le bus IDE1 vous devrez:
 installer Linux (/boot) sur n'importe quelle partition primaire du premier disque du bus IDE1,

Si vous avez un bus SCSI et un bus IDE vous pourrez:
 installer Linux (/boot) sur n'importe quelle partition primaire du premier disque du bus IDE1,
 installer Linux (/boot) sur n'importe quelle partition primaire du disque d'id0 sur le bus SCSI,
(les autres id ne fonctionnent pas),
 installer Lilo sur le MBR du disque système su Lilo est le chargeur primaire,
Disques SCSI
Si vous avez 2 disques SCSI, vous pourrez:
 installer Linux (/boot) sur le disque d'id0 ou id1 (les autres id ne fonctionneront pas),
Attention avec les Bus SCSI
 connectez le lecteur de CDROM sur le connecteur le plus proche du processeur,

 affectez-lui un id supérieur à celui du dernier disque,
 vérifiez la terminaison physique et logique du Bus.
Restriction du BIOS
 Certains BIOS ne supportent pas de partitions d'amorçage au dessus du cylindre 1023,

 Attention si vous utilisez des outils comme fips.
 Ne créez pas de partition au-dessus de cette étendue avec un BIOS incompatible.
Installation
MBR et PBR
Installez Lilo
 sur le MBR (Master Boot Record), si vous n'avez pas d'autres chargeurs de système. Le
MBR contient un enregistrement qui est chargé à chaque démarrage de la machine.
 sur le PBR (Partition boot Record) si vous utilisez un autre chargeur de système comme
celui d'OS/2 ou Windows NT.

Installer Lilo
Quand ?
 Pendant l'installation de Linux.

 Après l'installation de Linux.
Où ?
 Sur une partition du disque dur. Dans ce cas il faudra bien choisir cette partition
 Sur le MBR si Lilo est le chargeur primaire
 Sur un PBR si Lilo est le chargeur secondaire (dans ce cas le chargement des systèmes
est pris en charge par un autre chargeur)
 Linux doit être installé sur une partition primaire (ne pas utiliser de partition étendue)
 On peut modifier la partition de chargement en modifiant le fichier de configuration de Lilo

(/etc/lilo.conf)
Attention: Si vous installez Lilo sur un MBR, alors qu'il y a déjà un chargeur, vous supprimerez le
chargeur installé.
Dos ou Windows 9.x
 Créez une partition pour Windows, installez Windows,

 Créez les partitions pour Linux, installez Linux,
 Installez Lilo sur le MBR
Pour lancer ou relancer lilo après une modification de configuration : /sbin/lilo
Attention : Linux ne lit pas naturellement les Fat 32 bits.
Windows NT
Windows NT propose son chargeur.
 Créez les partitions pour Windows NT et installez NT.

 Créez les partitions pour Linux et installez Linux.
 Installez Lilo sur le PBR de sa partition d'amorçage.
 Ajoutez Linux dans la table des partitions d'amorçage de NT (avec un utilitaire comme
bootpart par exemple).
Le chargeur de NT permettra le chargement de Linux
Avec Windows 9.x et NT:

 créez les partitions appropriées,
 installez Windows 9.x,
 installez Windows NT et son chargeur,
 installez Linux sans mettre Lilo sur le MBR.
Attention aux systèmes de fichiers Fat, Fat 32, NTFS, ext2fs.
 voyez la documentation du système,

 les FAQs et HOWTOs,
 les forums de discussions.
Lilo
 Lilo crée une copie de sauvegarde du secteur de Boot (MBR) dans le répertoire /boot.
o avec un disque IDE /boot/boot.0300
o avec un disque SCSI /boot/boot.0800
 il est possible de restaurer ce secteur de boot:
o dd if=/boot/boot.0300 of=/dev/hda bs=446 count=1
Explication On restaure le secteur de boot d'une partition primaire sur /dev/hda (disque IDE).
Seuls les 446 premiers octets des secteurs sont nécessaires, les autres contiennent des
informations sur les tables des partitions.
Attention il y a un risque, faire au préalable une disquette de démarrage.
Exécution de Lilo
Pour s'exécuter correctement, Lilo a besoin:
 d'information sur le système (type de disques, contrôleurs, ...)
 d'un fichier de configuration (option d'exécution, partition d'amorçage, ...).
 boot partition qui contient le secteur de boot

 delay durée en 1/10 de seconde pendant laquelle le chargeur attend
 map emplacement du fichier de carte du noyau ou sinon /boot/map
 prompt affiche une invite au démarrage afin que l'utilisateur entre un choix

 image indique, pour la section, quelle image charger
 label alias permet de choisir entre plusieurs systèmes.
 append append permet de passer des paramètres au noyau, par exemple pour activer un
peripherique specifique (graveur ide en SCSI).
 disk et bios disk et bios remplace le mapping entre nom de disque et l'ordre des disques
dans le BIOS. A utiliser avec precaution.
 manuellement pour la création des fichiers et l'installation de Lilo,

 utilisation de l'environnement graphique (linuxconf ou webmin par exemple).

# Support des disques de grande taille
lba32
#
#disk=/dev/hde
# bios=0x81
#disk=/dev/sda
# bios=0x80
boot=/dev/hda
map=/boot/map
install=/boot/boot.b
vga=normal
default="linux"
keytable=/boot/fr_CH-latin1.klt
prompt
nowarn
timeout=100
message=/boot/message
menu-scheme=wb:bw:wb:bw
root=/dev/hda1
image=/boot/vmlinuz
label="linux"
initrd=/boot/initrd.img
append="devfs=mount hdc=ide-scsi acpi=ht resume=/dev/hda1 splash=silent"
vga=788
read-only
image=/boot/vmlinuz-old
label="old"
initrd=/boot/initrd.img-old
append="devfs=mount hdc=ide-scsi acpi=ht resume=/dev/hda1 splash=silent"
vga=788
read-only
image=/boot/vmlinuz-suze
label="suse"
root=/dev/hda2
initrd=/boot/initrd.img
read-only
other=/dev/hda3
label="win2k"
image=/boot/memtest-1.11.bin

label="memtest-1.11"
Ici, il y a 4 images, et 4 systèmes différents
Désinstaller Lilo
 si on veut installer un autre système sur la machine

 si Lilo est installé sur le MBR et doit être déplacé sur un PBR
Utilisez la commande "fdisk /mbr" sous Windows ou "/sbin/lilo -u sous Linux"
Choix du système
 Au démarrage du système utilisez les touches CTRL ou SHIFT. Les touches CTRL et
SHIFT vont temporiser le système, pour permettre à l'utilisateur d'entrer une commande
 Au prompt "boot:" utilisez la touche TAB pour voir la liste des différents systèmes. La
touche TAB affichera la liste des systèmes (champ "label" de /etc/lilo.conf).
 Démarrer Linux avec la disquette de démarrage (si on ne désire pas modifier la

configuration d'une machine)
 utiliser d'autres chargeurs commerciaux,
 utiliser loadlin, (pour charger Linux à partir de Windows)
 syslinux, chboot
Loadlin
loadlin permet de charger Linux à partir d'un prompt MS-DOS
 Exemple : Linux est installé sur la partition /dev/sda2

 Commande : loadlin NomDuNoyau root=/dev/sda2
rdev
 si Lilo n'est pas installé, les valeurs codées dans le noyau sont prises en compte.
 ces valeurs sont codées avec la commande rdev.
La commande rdev permet de voir quelle est la partition d'amorçage.

initrd
initrd est un fichier spécial (disque RAM), initialisé par Lilo, avant de charger le noyau,
Il permet de "pré-charger" les modules contenu dans /etc/modules.conf,
L'appel à initrd est configuré dans /etc/lilo.conf
Pour en savoir plus : man initrd mkinitrd mknod
Modules
Les modules pour les pilotes de périphériques sont configurés lors de l'installation initiale.
modconf permet de configurer les modules ensuite au travers d'une interface utilisant des menus.
Ce programme est utile lorsque des modules ont été oubliés lors de l'installation ou lorsqu'un
nouveau noyau est installé.
Le nom des modules à précharger est listé dans /etc/modules. Utilisez lsmod et depmod pour
les contrôler manuellement.
/etc/modules.conf
above snd-via82xx snd-pcm-oss

probeall scsi_hostadapter aic7xxx ide-scsi
alias ieee1394-controller ohci1394
probeall usb-interface usb-uhci ehci-hcd
alias sound-slot-0 snd-via82xx
alias eth0 tulip
alias autofs autofs4
alias eth1 via-rhine
initrd (suite)
Exemple de mise à jour, suite à la modification de /etc/modules.conf:
 Modification de /etc/modules.conf
alias scsi_hostadapter buslogic
 Création de la nouvelle image /sbin/mkinitrd -o /boot/NouveauNomInitrd.img

numero_version_kernel
Conclusion
Vous avez vu :
 comment s'effectue le chargement de Linux,

 le rôle de lilo,

 comment installer et configurer Lilo,
 comment désinstaller lilo,
 adopter une stratégie pour installer plusieurs systèmes d'exploitation sur une machine
Linux.
Chapter 46. Travaux pratiques : Kernel et Noyau
Table of Contents
Objectifs
Quelques remarques
Compilation
Utilisation de Grub
Librairies
Abstract
Mise en oeuvre des mécanismes de boot et d'optimisation du noyau.
Le but de ce TP est de savoir gérer le chargement du système, de la phase de boot à celle du

chargement du noyau et de ses modules, init et les niveaux d'exécution seront abordés dans un
autre TP.
Objectifs
 Utiliser Lilo
 Utiliser Grub
 Dé/Chargement de modules
 Librairies
 Installation d'un noyau standard
 Installation d'un noyau à partir des sources
Quelques remarques
 Durant l'installation, on sera interrogé sur le matériel ou les puces. Parfois, ces informations
ne sont pas toujours faciles à trouver. Voici une méthode :

o Ouvrez le PC et inspectez l'intérieur.
o Notez les codes produits qui sont sur les grandes puces de la carte graphique, de la
carte réseau, sur la puce à côté des ports série et la puce à côté des ports IDE.
o Notez les noms imprimés au dos des cartes PCI et ISA.
 Relevez dans /etc/lilo.conf, la configuration initiale et effectuez une copie de ce fichier avant
toute modification.
 Relevez à l'aide de fdisk ou cfdisk le mapping de votre disque dur.
 Relevez à l'aide des commandes ci-dessous, les caractéristiques matérielles de votre poste
de travail.
 $ lspci -v |less
 $ pager /proc/pci
 $ pager /proc/interrupts
 $ pager /proc/ioports
 $ pager /proc/bus/usb/devices
Compilation
A partir d'une distribution Debian GNU/Linux
 Lisez attentivement ce document une première fois sans lancer les commandes.
 Lisez également les pages de manuel des commandes avec man et info
Notez la version actuelle de votre noyau :
uname -a
ls -l /boot/
ls -l /lib/modules/
ls -l /usr/src/
ou
cat /proc/version
Affichez les modules chargés et repérez celui chargé du support de la carte réseau
lsmod
lancez la commande ci-dessous, choisissez la dernière version du noyau en relançant à nouveau

la commande avec le nom + version
apt-get install debhelper modutils kernel-package libncurses5-dev

apt-get install kernel-source-[2.4.26] # utilisez la dernière version
apt-get install fakeroot
entrez votre nom et adresse électronique

vi /etc/kernel-pkg.conf
déplacez vous dans le répertoire où se trouvent les sources
cd /usr/src
décompactez l'archive
tar xjvf kernel-source-(nouvelle-version).tar.bz2
supprimez le lien symbolique linux qui pointe sur la dernière version du noyau, s'il existe.
rm /usr/src/linux
créez un lien symbolique vers votre nouvelle version
ln -s /usr/src/kernel-source-(nouvelle-version) /usr/src/linux
déplacez vous dans les sources
cd /usr/src/linux
consultez les fichiers avec ,par exemple, mc
Documentation/*
README
README.debian
Makefile
lancez l'interface de configuration du noyau afin de constater que par défaut la sélection des
modules du noyau ne correspond pas à celle que vous avez, c'est normal car à ce stade vous
n'avez pas récupéré votre ancienne configuration (fichier .config dans les sources).
! pour le TP quitter sans sauver ! Si vous avez lu trop tard, lancer les commandes suivantes afin
de purger vos sources
make mrproper
pour l'interface sous X
make xconfig
en mode console texte et ultra-basique
make menuconfig
make config
vérifiez la présence des modules réseau, video, ... de votre machine
less /boot/config-(version-actuelle)
vérifiez également leur présence dans /lib/modules/kernel-(version-actuelle)/...
Vous pouvez également constater leur chargement dans le système et dans le fichier de
chargement

lsmod
cat /etc/modules
copiez le fichier de config par defaut
cp /boot/config-(version-actuelle) /usr/src/linux/.config
alternative sous Suse : make cloneconfig
démarrez la configuration de votre nouveau noyau
make menuconfig
enlevez le module de votre carte réseau
au cours d'une autre manipulation , vous pourrez refaire ce TP en retirant tout support qui ne
concerne pas votre architecture matérielle, afin d'obtenir un noyau optimisé à vos besoins,
attention toutefois à ne pas retirer les modules nécessaires au fonctionnement de votre
environnement.
help sur un module vous donne son label que vous retrouvez dans .config
quittez et sauvez les modifications
regardez vos modifications par rapport au fichier d'origine
pour voir vos modifications
diff /boot/.config-(version-actuelle) .config
éditez le fichier Makefile et mettez votre EXTRAVERSION personelle
profitez-en pour parcourir ce fichier et voir ce que font les différentes cibles (dep, clean,
bzImage, ...)
copiez votre /usr/src/linux/.config dans /boot
cp .config /boot/config-(nouvelle-version)
lancez les commandes de compilation suivantes:
make dep
make clean
make bzImage
make modules
Vous pourriez également enchaîner les traitements en une seule commande : make clean
bzImage modules
Attention ! A ce point si vous recompiliez la même version de kernel, vous devez déplacer
/lib/modules/kernel-(version-actuelle), afin de ne pas génerer, dans ce dernier, les modules
issus de votre nouvelle compilation
mv /lib/modules/kernel-(version-actuelle) /lib/modules/kernel-version-actuelle-old
continuez ensuite par installer les modules

make modules_install
ls -l /lib/modules/ # Vous permet de constater la création du répertoire contenant les
modules de kernel-(version-actuelle)
copiez les fichiers (noyau et System.map) créés par la compilation dans /boot
cp arch/i386/boot/bzImage /boot/vmlinuz-(nouvelle-version)
cp System.map /boot/Sytem.map-(nouvelle-version)
Si /boot/System.map existe et est un lien symbolique, vous devez le supprimer pour établir un lien
avec le nouveau fichier.
rm /boot/System.map
ln -s /boot/Sytem.map-(nouvelle-version) /boot/Sytem.map
Supprimer /vmlinuz.old s'il existe, ou renommer le
rm /vmlinuz.old
permutez le lien symbolique /vmlinuz
mv /vmlinuz /vmlinuz.old
créez un lien symbolique pointant sur la nouvelle image du noyau
ln -s /boot/vmlinuz-(nouvelle-version) /vmlinuz
Editer lilo.conf et activer la section vmlinuz.old (si ce n'est pas fait) et valider vos changements
lilo -v
rebooter
shutdown -r now ou reboot
Extras, à faire plus tard
il est possible de rendre totalement automatique l'installation du noyau en lançant la commande

(ne l'utilisez pas pour le TP)
cd /usr/src/linux
make modules_install install
Fabriquer un noyau « debianisé » en simple utilisateur: récupérer les sources du kernel et de

pcmcia dans votre répertoire
$ cd ~/kernel-source-(nouvelle-version)
$ make menuconfig
$ make-kpkg clean
# N'utilisez pas --initrd, initrd n'est pas utilisé dans notre cas.
$ fakeroot make-kpkg --append_to_version -486 --initrd \
--revision=rev.01 kernel_image \
modules_image # modules_image pour pcmcia-cs* etc.
$ cd ..
# dpkg -i kernel-image*.deb pcmcia-cs*.deb # installation en tant que root
En réalité, make-kpkg kernel_image lance make oldconfig et make dep.

Si vous voulez les modules de pcmcia-cs, ou pas de support pcmcia, sélectionnez dans make
menuconfig « General setup » dans « PCMCIA/CardBus support » et le déselectionner (càd
décocher la case).
Sur une machine SMP, configurez CONCURRENCY_LEVEL selon kernel-pkg.conf(5).
Autre possibilité
cd /usr/src/linux
make-kpkg -revision debidon.2.4.26 kernel_image
après cette commande un noyau debianisé est créé dans /usr/src/
un utilisateur peut faire un package de kernel en utilisant fakeroot pour l'installer ensuite sur une
autre machine, ou encore le stocker dans un repertoire dont le sources.list d'apt pointerait dessus.
fakeroot make-kpkg -revision debidon.2.4.26 kernel_image
root peut ensuite l'installer en lançant la commande
dpkg -i kernel_image-2.4.26_debidon.2.4.26_i386.deb
regardez les commandes mkboot et installkernel
Affichez la liste des modules chargés et constatez que le module réseau n'est plus la, ni l'interface
lsmod
ifconfig -a
déplacez-vous dans les sources
cd /usr/src/linux
make menuconfig # (sélection du module de la carte réseau comme module)
quittez et sauvez
make dep
make modules modules_install
contrôlez les dépendences des modules
depmod -a
charger à chaud le module dans le système
modprobe nom_module
ou (ie remplacer alias par dans notre cas eth0) (voir /etc/modules.conf)
modprobe alias

contrôlez la présence du module
lsmod
réactivez le réseau
/etc/init.d/networking restart
NB: pour charger/décharger les modules du noyau.
modconf
si modules.dep ne se trouve pas dans /lib/modules/(version-encours)
depmod -a
pour prendre en compte un module au chargement, ajouter-le dans /etc/modules
man modules.conf
exemple pcmcia-cs + pcmcia-sources
cd /usr/src
récupérer sur http://pcmcia-cs.sourceforge.net/ et décompresser les sources pcmcia dans le

repertoire modules après install du noyau
cd /usr/src/modules/pcmcia-cs
make clean
make config
cd /usr/src/linux
make-kpkg --revision=custom.1.0 modules_image
cd /usr/src/
dpkg -i pcmcia-modules*.*.deb
Pour plus d'informations sur la compilation http://www.debian.org/doc/manuals/reference/ch-

kernel.fr.html
Utilisation de Grub
Le nouveau gestionnaire de démarrage grub du projet GNU Hurd peut être installé sur un système
Debian Woody
# apt-get update
# apt-get install grub-doc
# mc /usr/share/doc/grub-doc/html/
... lisez le contenu
# apt-get install grub
# pager /usr/share/doc/grub/README.Debian
... à lire
Comment configurer les paramètres de démarrage de GRUB

GRUB est un nouveau gestionnaire de démarrage issu du projet Hurd et est beaucoup plus
flexible que Lilo mais a une manière différente de gérer les paramètres de démarrage.
# grub
grub> find /vmlinuz
grub> root (hd0,2)
grub> kernel /vmlinuz root=/dev/hda3
grub> initrd /initrd # ne pas utiliser dans notre cas
grub> boot
Là, vous devez connaître les noms de périphériques de Hurd :
the Hurd/GRUB Linux MSDOS/Windows

(fd0) /dev/fd0 A:
(hd0,0) /dev/hda1 C: (habituellement)
(hd0,3) /dev/hda4 F: (habituellement)
(hd1,3) /dev/hdb4 ?
Voir /usr/share/doc/grub/README.Debian et /usr/share/doc/grub-doc/html/ pour les détails.
Pour modifier le menu de GRUB, éditez /boot/grub/menu.lst. Voir Comment configurer les
paramètres de démarrage de GRUB, pour la configuration des paramètres de démarrage car la
syntaxe est différente de celle de lilo.
Librairies
Il faut distinguer les librairies statiques des librairies dynamiques.
Les librairies statiques possèdent l'extension ".a". Ces librairies sont liées statiquement avec le
binaire (programme). C'est à dire que durant la phase de linkage (édition des liens lors de la
compilation) le compilateur va prendre le code des fonctions nécessaires de la librairie et les
mettres en dur dans le binaire.
Les librairies dynamiques possèdent l'extension ".so". Ces librairies sont liées dynamiquement
avec le binaire. Dans ce cas, le code des fonctions utilisées par le programme ne se trouve pas
dans le binaire. Mais lorsque ce bout de code est requis par le programme, il va charger ce code
dynamiquement (durant l'exécution du programme).
Un programme lié statiquement avec une librairie sera plus gros en taille que pour une libriaire
dynamique.
Pour les libriaires dynamiques, voici le fichier à configurer qui donne les chemins où se trouvent
les librairies dynamiques /etc/ld.so.conf
La commande ldconfig parcours les chemins spécifiés dans le fichier de configuration et construit
un cache. Ce cache est utilisé par le "run-time linker" (chargeur de librairies durant l'éxecution d'un
programme).
Consulter les man page de la commande ldconfig pour plus de précision sur les arguments... elle
s'utilise en général de manière très simple sans argument (doit être executée en root). Cette
commande doit être exécutée après l'installation de nouvelles librairies (généralement cela est
effectué automatiquement lors de l'installation des packages).

Consulter également les man page de la commande ldd et ld

Architechture Tcpip

Transféré par

Droits d'auteur :

Formats disponibles

Architechture Tcpip

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Architechture Tcpip

Transféré par

Droits d'auteur :

Formats disponibles

http://www.linux-france.org/~amascret/prj/edu/archinet/systeme/index.

Tutoriel sur les serveurs

Tutoriel sur les serveurs

Copyright © 2004 L'équipe Freeduc-Sup

Revision 1.0 Septembre 2007

Ensemble de documents réalisés pour la freeduc-sup.

1. Eléments de cours sur TCP/IP

Par NGUELE Paul Alain avril 2009 1

Par NGUELE Paul Alain avril 2009 2

Par NGUELE Paul Alain avril 2009 3

Par NGUELE Paul Alain avril 2009 4

Par NGUELE Paul Alain avril 2009 5

Par NGUELE Paul Alain avril 2009 6

Par NGUELE Paul Alain avril 2009 7

Par NGUELE Paul Alain avril 2009 8

Par NGUELE Paul Alain avril 2009 9

Par NGUELE Paul Alain avril 2009 10

Par NGUELE Paul Alain avril 2009 11

Par NGUELE Paul Alain avril 2009 12

Par NGUELE Paul Alain avril 2009 13

Par NGUELE Paul Alain avril 2009 14

Par NGUELE Paul Alain avril 2009 15

Par NGUELE Paul Alain avril 2009 16

Par NGUELE Paul Alain avril 2009 17

Par NGUELE Paul Alain avril 2009 18

1.1. OSI et TCP/IP

Par NGUELE Paul Alain avril 2009 19

Par NGUELE Paul Alain avril 2009 20

Par NGUELE Paul Alain avril 2009 21

Chapter 1. Eléments de cours sur TCP/IP

La suite de protocoles TCP/IP

Revision 0.2 1 Octobre 2005

Par NGUELE Paul Alain avril 2009 22

Le document présente la suite de protocoles TCP/IP.

TCP/IP est l'abréviation de Transmission Control Protocol/Internet Protocol. Ce protocole a été

Plusieurs facteurs ont contribué à sa popularité :

Maturité, Ouverture, Absence de propriétaire, Richesse (il fournit un vaste ensemble de

La RFC 826, par exemple, définit le protocole ARP.

Par NGUELE Paul Alain avril 2009 23

La suite de protocoles TCP / IP

IP (Internet Protocol, Protocole Internet)

Par NGUELE Paul Alain avril 2009 24

Le protocole Internet transmet le datagramme en utilisant l'adresse de destination contenue dans

TCP (Transmission Control Protocol,Protocole de contrôle de la transmission)

Par NGUELE Paul Alain avril 2009 25

ICMP (Internet Control Message Protocol)

RIP (Routing Information Protocol)

ARP (Address Resolution Protocol

Figure 1.3. Protocoles TCP/IP et OSI

Par NGUELE Paul Alain avril 2009 26

Les protocoles du niveau application les plus connus sont :

 Telnet pour la connexion à distance en émulation terminal, à un hôte Unix/Linux.

 SNMP (Simple Network Management Protocol) pour l'administration du réseau

 NFS (Network File System) pour le partage des fichiers Unix/Linux.

Les applications TCP-IP

Prenons par exemple telnet.

Par NGUELE Paul Alain avril 2009 27

L'adressage des applicatifs : les ports

Par NGUELE Paul Alain avril 2009 28