Administration réseaux avancés

(ServicesR3)
 Préambule

➢ Plan du cours
➢ DNS
➢ Annuaires (LDAP)
➢ Messagerie (SMTP)

2
Partie I : DNS

3
 DNS
➢ Introduction
➢ Architecture
➢ Ressources
➢ Résolution
➢ Sécurité : DNSSEC

4
 Introduction
➢ Domain Name System (RFC 1034, 1035 et 1591) :
➢ Correspondance @ IP <-> Nom de domain
➢ Utilisateurs :
➢ Navigateurs web, Outils de messagerie, etc.
➢ Nécessité :
➢ Plus simple à retenir des noms
➢ Le fichier Hosts ne peut pas tout contenir
➢ Gestion distribuée : délégation

5
 Architecture
➢ Structure arborescente de noms de domaine
➢ Un FQDN (Fully Qualified Domain Name) est
unique sur le réseau internet
➢ Racine, domaines du niveau supérieur (com,
org, fr, ca, etc.), sous-domaines (u-clermont1.fr,
univ-bpclermont.fr, etc.), machine
➢ Exemple : iutweb.u-clermont1.fr

6
 Les niveaux
Racine .

Domaines supérieurs com fr org net ...

Sous-domaines google univ-bpclermont u-clermont1 ...

Hôtes www iutweb ...

7
 Les domaines
➢ Domaines génériques (.com, .gov, .net, .int, ...)
➢ Domaines par pays (.fr, .de, .us, .it, .es, ...)
➢ A chaque noeud ou feuille (entrée) dans l'arbre
est associé un ensemble de ressources
➢ Nom de domaine = la suite des noms à partir
d'une entrée dans l'arbre jusqu'à la racine :
www.u-clermont1.fr.
➢ Domaine = le sous-arbre dont l'origine est le
nom de domaine
8
 Constitution des noms de domaine
➢ Nom absolu = FQDN Fully Qualified Domain Name
➢ 255 caractères ASCII en tout
➢ Noms (longueur <= 63 caractères) séparés par des
points
➢ Pas de différence entre majuscule et minuscule
➢ 2009 : utilisation de caractères accentués, arabes,
chinois, cyrilliques... traduits en caractères ASCII pour
l'interrogation du DNS
exemples actifs depuis mai 2010 : ‫ ررص‏م‬. (TLD de
l'Egypte) .рф. (TLD de la Fédération Russe)
9
 Noms Top Level Domain (TLD)
➢ TLD en :
➢ .com : organisations commerciales
➢ .edu, .mil et .gov : organisations éducatives, militaires et
gouvernementales américaines
➢ .int, .net, .org : autre organisations
➢ Un domaine par pays
➢ De nouveaux domaines introduits : .biz, .info ...en 2001.
➢ « libéralisation » des noms de domaine en 2008
➢ Sous-domaine : domaine inclus dans un autre
domaine
10
 Les zones (1)
➢ Une zone d'autorité est un ensemble de
domaines géré par un seul serveur de noms
➢ Une zone contient au moins un domaine
➢ Peut contenir les sous-domaines du domaine
racine de la zone

11
 Les zones (2)
.

com fr org net ...

google univ-bpclermont u-clermont1 ...

Zone fr

www iutweb ...

Zone u-clermont1.fr

12
 La résolution inverse
➢ Un sous-domaine specifique chargé de faire la
résolution inverse : in-addr.arpa.
➢ Le domaine de niveau supérieur arpa. (Address
and Routing Parameter Area) possède 6 sous-
domaines dont un pour ipv4

13
 Architecture de in-addr.arpa
.

com arpa org net ...

ip6 urn in-addr ...

0 1 ... 190 ... 255

190.10.20.8 est hébergée dans

le domaine 20.10.190.in-addr.arpa.
0 1 ... 10 ... 255

0 1 ... 20 ... 255

14
 Les zones
➢ Une zone est administrée par un gérant :
➢ responsable de l'attribution des noms et de leur
unicité, ex :
➢ NIC (Network Information Center) au niveau mondial
➢ NIC délègue au RIPE-NCC (Réseaux IP Européens -
Network Coordination Centre) en Europe
➢ RIPE-NCC délègue l'administration à l'AFNIC
(Association Française pour le Nommage Internet en
Coopération) en France
➢ etc...

15
 Les serveurs (1)
➢ Un serveur de noms (name server) autoritaire
sur une zone :
➢ Stocke et met à jour les informations de sa zone
➢ Peut avoir autorité sur plusieurs zones
➢ Peut déléguer une sous-zone à un autre serveur :
dans ce cas, dispose d'un pointeur vers le serveur
de cette sous-zone (cette info est appelée glue
data, fournie dans la partie « additionnelle » de la
réponse)

16
 Les serveurs (2)
➢ Le serveur de noms : répond aux requêtes
➢ concernant les ressources de sa zone
➢ concernant des ressources en dehors de sa zone
(stockées dans un cache)
➢ Il connaît les adresses IP :
➢ des ressources de sa zone
➢ des serveurs de noms de ses sous-zones
➢ des serveurs racines (qui connaissent les adresses
des sous-zones fr, de, uk, com, edu...)

17
 Types de serveurs (1)
➢ Primaire (maître) : héberge les ressources d'une
zone et possède tout seul l'accès en écriture et
lecture sur les fichiers de cette zone
➢ Secondaire (esclave) : héberge une copie des
ressources d'une zone (ne possède pas le droit
de modifier ces données), décharge le serveur
primaire, accélère la procédure de resolution de
noms

18
 Types de serveurs (2)
➢ Root : il y en a que 13 dans le monde, très
sollicités !
➢ Cache : ne possède pas d'autorité sur des
zones, il sauvegarde des réponses déjà
résolues
➢ Forwarder : ne contient pas de ressources, il fait
le relais entre les clients et les serveurs

19
 Les ressources
➢ Les informations gérées par les serveurs sont
nommées Resource Record (RR)
➢ Une RR contient les informations suivantes :
➢ Name, Type, Class, TTL, RD length, RData

20
 Contenu des RR (1)
➢ Name : spécifie le nom du domaine ou une
partie de l'@ IP
➢ Type :
➢ A : FQDN --> @ IP
➢ PTR : @ IP --> FQDN
➢ CNAME (Canonical Name) : alias du FQDN
➢ MX : hôte qui héberge le serveur mail
➢ NS : nom du serveur de noms de la zone
➢ SOA : Start Of Authority
21
 Contenu des RR (2)
➢ Class : IN pour internet
➢ TTL : indique la durée de validité de la RR, utile
pour les serveurs caches, secondaires et
utilisateurs
➢ RD length : la longueur de la donnée

22
 Contenu des RR (3)
➢ RDATA : la donnée
➢ A : une adresse IP sur 32 bits
➢ CNAME : un nom de domaine
➢ MX : une valeur de priorité sur 16 bits, suivi d'un
nom d'hôte
➢ NS : un nom d'hôte
➢ PTR : un nom de domaine
➢ SOA : serveur de noms primaire

23
 Les RRSets
➢ Les RRs sont regroupés en RRSets
➢ Ces RRs possèdent les mêmes valeurs pour
les champs : Name, Type et Class
➢ Exemple :
➢ exemple.com. IN NS ns1.exemple.com.
➢ exemple.com. IN NS ns2.exemple.com.
➢ exemple.com. IN NS ns3.exemple.com.

24
 Un client
➢ Dispose d'une librairie de fonctions lui
permettant de solliciter un serveur : resolver
➢ Un client <=> Resolver
➢ Chaque resolver dispose d'une liste de serveurs
de noms

25
 Processus de résolution
L'interrogation d'un serveur de noms se fait par
l'intermédiaire d'un resolver
But : alléger la charge des serveurs de noms
requête requête
Serveur
Utilisateur Resolver de noms
réponse réponse

question,
mise à jour références

Cache

local distant
26
 Exemple de déroulement de
résolution
http://cassiope.u-clermont1.fr

Config IP du PC :
@IP : 192.168.118.27
Masque : 255.255.255.0 PC Client
...
DNS : 193.49.118.2

Serveur DNS : 193.49.118.2

Requête
Name : cassiope.u-clermont1.fr
Type : A
Class : IN
Fichier ua.db
Réponse
Name : cassiope.u-clermont1.fr...
Type : A cassiope.u-clermont1.fr. 86400 IN A 193.49.118.248
...
Class : IN
TTL : 86400 27 27
Addr : 193.49.118.248
 Exemples de RR (1)
Exemples (extraits du fichier de configuration ua.db) :
➢ Exemple 1 :
cassiope.u-clermont1.fr. 86400 IN A 193.49.118.248

durée de vie(TTL en secondes) Internet Type adresse IP de cassiope.u-

clermont1.fr
➢ Exemple 2 :
iutweb.u-clermont1.fr. 86400 IN CNAME cassiope.u-clermont1.fr.

Ce nom de domaine
devrait pointé vers
alias pour cassiope.u-clermont1.fr. un autre nom ou
bien une adresse IP
28
 Exemples de RR (2)
➢ Exemple 3 (serveurs de mail) :
u-clermont1.fr. 86400 IN MX 0 unames.u-clermont1.fr.
86400 IN MX 100 linua.u-clermont1.fr.

unames.u-clermont1.fr. est le serveur de courrier prioritaire par

rapport à linua.u-clermont1.fr. pour la domaine u-clermont1.fr

➢ Exemple 4 (serveur de nom du domaine) :

u-clermont1.fr. 86400 IN NS iutsux01.u-clermont1.fr.

29
 Exemple de RR (3)
➢ Exemple 5 (Ressource SOA) :
u-clermont1.fr. 86400 IN SOA uadmin.u-clermont1.fr.
postmaster.linua.u-clermont1.fr. (
2004100801 21600 3600 604800 10800 )
le domaine u-clermont1.fr. :
➢
a pour serveur DNS primaire uadmin.u-clermont1.fr.
➢
son administrateur a pour e-mail postmaster@linua.u-clermont1.fr
➢ le numéro de version de ces infos est 2004100801 sous la forme yyyymmddss
(aaaammjjss) yyyy = année, mm = mois, dd = jour, ss = un numéro de séquence si
le contenu a été mis à jour plusieurs fois le même jour (si ce numéro change, le
serveur secondaire fera une demande de transfert de zone)
➢ les réponses négatives peuvent rester dans un cache 10800s = 3h
➢ les serveurs secondaires doivent vérifier les infos toutes les 21600s (6h), si pas de
réponse nouvelle tentative au bout de 3600s, la validité des informations étant de
604800s = 7 jours 30
 Serveurs racines
Fichier ua.ca : liste des serveurs racines
; formerly NS.INTERNIC.NET
. 3600000 IN NS A.ROOT-SERVERS.NET.
A.ROOT-SERVERS.NET. 3600000 A 198.41.0.4
; formerly NS1.ISI.EDU
. 3600000 NS B.ROOT-SERVERS.NET.
B.ROOT-SERVERS.NET. 3600000 A 128.9.0.107
etc jusqu'à
. 3600000 NS I.ROOT-SERVERS.NET.
I.ROOT-SERVERS.NET. 3600000 A 192.36.148.17
; End of File

31
 Modes de fonctionnement
(spécifié dans la requête)
➢ Itératif : le serveur retourne soit la réponse, soit
le nom du serveur susceptible d'avoir la réponse

➢ Récursif : le serveur retourne soit la réponse s'il

parvient à la trouver (en sollicitant itérativement
d'autres serveurs), soit un message d'erreur.
Les serveurs locaux sont configurés avec la
liste des 13 serveurs de noms racines.

32
Exemple de résolution récursive
Recherche de l'@ IP de iutweb.u-clermont1.fr par une
machine située à Strasbourg. Le serveur de nom local
fera les étapes suivantes :
Question Serveur Réponse

@ IP iutweb.u- Serveur “.“ Demander au NS de .fr

clermont1.fr. ?

@ IP iutweb.u- NS de “.fr.“ Demander au NS de u-

clermont1.fr. ? clermont1.fr

@ IP iutweb.u- NS de “u-clermont1.fr.“ 193.49.118.248

clermont1.fr. ?

33
 Format d'un message DNS
➢ Header|Question|Answer|Authority|Additional
➢ Header : ID, Q ou A, récursive ou itérative, ...
➢ Question : la requête
➢ Answer : RR en réponse
➢ Authority : SOA ou NS
➢ Additional : informations supplémentaires (@IP du
hôte MX, par exemple)

34
 Exemple de configuration
➢ Serveur le plus courant sous linux : named (Bind9)
➢ Au lancement, le fichier consulté est named.conf. Il
contient des redirections vers des fichiers contenant :
➢ les définitions des zones sur lesquelles il a autorité en tant
que :
➢ maître, est alors indiqué le nom du fichier contenant les Ressources
Records
➢ esclave, sont indiqués :
➢ le nom du fichier contenant les Resource Records
➢ l'adresse IP du serveur maître
➢ le nom du fichier contenant les références des serveurs
racines
➢ des options 35
 Fichier named.conf (1)
; zone contenant des résolutions directes

zone "u-clermont1.fr" {
type slave; dépend d'un autre serveur
file "ua.db"; fichier contenant les ressources récupérées
masters {
193.49.118.253; adresse du serveur auprès duquel il faut récupérer les RR
};
};

; zone contenant des résolutions inverses

zone "117.49.193.in-addr.arpa" {
type slave;
file "ua117.rev";
masters {
193.49.118.253;
};
};
36
 Fichier named.conf (2)
zone "106.168.192.in-addr.arpa" {
type master; le serveur possède les RR dans ses fichiers locaux
file "uan106.rev";
};

zone "0.0.127.in-addr.arpa" {
type master;
file "ua.local";
};

zone "." {
type hint;
file "ua.ca"; fichier contenant le cache
};

37
 Fichier named.conf (3)
➢ Contenu des fichiers définissant les zones sous la
responsabilité du serveur, les RRs nécessaires sont :
➢ une RR de type SOA
➢ une RR de type NS (rappel du nom du serveur de nom
de la zone)
➢ les autres RRs de la zone :
➢ ; est suivi d'un commentaire
➢ @ remplace le nom de la zone
➢ " " espace reprend la même valeur de la ligne précédente
➢ $ORIGIN domain_name : les noms de domaines qui suivent dans le
fichier seront postfixés par domain_name quand ils ne se terminent pas
par un "."

38
 Exemple d'un fichier de zone
$TTL 86400 ; 24 heures (24h ou bien 1d)
$origine exemple.com.
@ 1D IN SOA ns1.exemple.com. admin.exemple.com. (
2010112903 ; numéro de série (aaaammjj#)
8H ; refresh
20 ; retry
4W ; expiration
1D ; durée de mise en cache
)
IN NS ns1.exemple.com.
IN MX 1 serveurMX.exemple.com.
ns1 IN A 192.168.2.10
serveurMX IN A 192.168.2.11
www IN A 192.168.2.20
ftp IN CNAME w w w.exemple.com.
post1 IN A 192.168.2.5
passerelle IN A 192.168.2.1
39
 Vulnérabilité et DNSSEC
➢ Le processus de résolution recursive permet de
lancer des attaques d'empoisonnement de
cache : insertion de ressources falsifiées dans
les caches des serveurs DNS

➢ Solution : DNSSEC qui permet d'authentifier les

serveurs et de garantir l'intégrité des
ressources

40
Partie II : LDAP

41
 LDAP
➢ Lightweight Directory Access Protocol une
norme IETF (Internet Engineering Task Force)
➢ Conçu par l'université de Michigan comme étant
une version indépendante et plus légère que
X.500 DAP (Directory Access Protocol) et
adaptée au protocole TCP/IP
➢ Première apparition commerciale en 1996

42
 Contenu d'un annuaire
➢ Annuaire contient tout type d'informations :
➢ Noms, prénoms
➢ Numéros de téléphone
➢ Adresses
➢ Postes, machines, systèmes
➢ Classes, groupes
➢ Services,
➢ Etc.

43
 LDAP
➢ Définit le protcole d'échanges basé sur des
requêtes/réponses pour dialoguer entre client-
serveur :
➢ Se connecter, lire, rechercher, créer, modifier,
supprimer
➢ et entre serveur-serveur :
➢ Échanger le contenu et le fusionner

44
 LDAP et BDR
➢ Un annuaire est prévu pour
➢ Être plus sollicité en lecture qu'en écriture
➢ Stocker les données de manière hiérarchique
➢ Optimiser la recherche d'une donnée
➢ Échanger entre annuaire-annuaire
➢ Gérer l'authentification des utilisateurs et les ACL

45
 LDAP spécifie plusieurs modèles
➢ Modèle d'information : le type d'information
contenu dans l'annuaire
➢ Modèle de nommage : la façon dont
l'information est organisée et référencée
➢ Modèle fonctionnel : l'accès à l'information
➢ Modèle de sécurité : la protection des données
et de l'accès
➢ Modèle de duplication : la gestion de la
répartition entre serveurs
46
 Modèle d'information
➢ Spécifie le type de données stockées dans
l'annuaire
➢ Structure arborescente selon le modèle X.500
➢ Un annuaire est un arbre d'entrées
➢ Une entrée est constituée d'un ensemble
d'attributs
➢ Un attribut possède un nom, un type et une ou
plusieurs valeurs
➢ Les attributs sont définis dans des schémas
47
 Une entrée
➢ Chaque entrée correspond à un objet (une
personne, une machine, une entreprise, ...)
➢ Un objet est une instance d'une classe d'objets
➢ Une classe d'objets est constituée d'attributs
➢ La définition d'objets et des attributs est gérée
par des règles (notion de schéma)

48
 Une classe d'objets
➢ Elle est constituée de :
➢ Nom
➢ OID
➢ Attributs obligatoires
➢ Attributs optionnels
➢ Type :
➢ Classe structurelle : objets basiques (personne,
organisation, etc)
➢ Classe auxiliaire : objets qui possèdent des informations
complémentaires (augmenter les attributs d'une classe)
➢ Classe abstraite : les classes de base non instantiables
(top) 49
 Un attribut
➢ Il est constitué de :
➢ Nom
➢ OID
➢ Mono ou multi-valué
➢ Syntaxe et règles de comparaison
➢ Format ou limite de taille de valeur

50
 Règles de comparaison
LDAP X.500 description

cis caseIgnoreMatch texte, la casse n’est pas prise en compte

ces caseExactMach texte, la casse intervient
tel telephoneNumberMatch texte représentant un numéro de tel
int integerMatch nombre entier, comparaison numérique
dn distinguishedNameMatch nom d’entrée, règles spécifiques
bin octetStringMatch données binaires, comparaison byte/byte

51
 Héritage de classe d'objets
➢ Les classes abstraites sont des classes non
instanciables. La classe d'objets de plus haut
niveau est la classe "top"
➢ Les classes structurelles sont des classes
instanciables. Une entrée doit appartenir à au
moins une classe structurelle
➢ Les classes auxiliaires sont des classes
permettant d'ajouter des attributs facultatifs à
des classes structurelles, complètent les
classes structurelles
52
 Les schémas
➢ Un schéma définit l'ensemble des classes
objets et leurs attributs qu'un annuaire peut
gérer, en précisant leurs syntaxes
➢ Ceci permet de contrôler les entrées
renseignées dans LDAP (Schema Checking)

53
 Exemples de schémas LDAPv3
attributeType ( 2.5.4.41 NAME 'name'

DESC 'name(s) associated with the object'

EQUALITY caseIgnoreMatch

SUBSTR caseIgnoreSubstringsMatch

SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} )

attributeType ( 2.5.4.3 NAME ( 'cn' 'commonName' )

DESC 'common name(s) assciated with the object'

SUP name )

Objectclass ( 2.5.6.6 NAME 'person'

DESC 'standard person'

SUP 'top'

MUST (objectclass $ sn $ cn )

MAY ( description $ seealso $ telephonenumber $ userpassword ))

54
 OID : Object ID
http://www.oid-info.com
➢ Chaque élément dans un schéma est identifié
par un OID
➢ Une société peut réserver sa propre plage de
OID auprès de l'IANA (Internet Assigned
Numbers Authority)
➢ Il commencera par : 1.3.6.1.4.1
➢ OpenLDAP : 1.3.6.1.4.1.4203

55
 Syntaxe (type)
Nom OID Description

Boolean 1.3.6.1.4.1.1466.115.121.1.7 booléen

DirectoryString 1.3.6.1.4.1.1466.115.121.1.15 Unicode (UTF-8) string

distinguishedName 1.3.6.1.4.1.1466.115.121.1.12 LDAP DN

integer 1.3.6.1.4.1.1466.115.121.1.27 entier

NumericString 1.3.6.1.4.1.1466.115.121.1.36 chaîne numérique

OID 1.3.6.1.4.1.1466.115.121.1.38 object identifier

octetString 1.3.6.1.4.1.1466.115.121.1.40 octets

56
 Modèle de nommage

Domain Component dc=IUT

ou=Aubiere ou=Blagnac
Organisational Unit
ou=R&T ou=Info ou=Bio ou=R&T ou=Info

Common Name cn=DUT cn=Licence

57
 Distinguished Name
➢ L'arbre hiérarchique est appelé DIT (Directory
Information Tree)
➢ Chaque entrée dans l'arbre est appelée DSE
(Directory Service Entry)
➢ La racine de l'arbre s'appelle suffix ou BaseDN
➢ Les objets dans un DIT sont identifiés par le dn
(équivalent d'une clé primaire dans un SGBDR)

58
 Exemple de DN
➢ Le dn de DUT est :
● cn=DUT,ou=R&T,ou=Aubiere,dc=IUT
➢ Le rdn de DUT est :
➢ cn=DUT

59
 Format LDIF
➢ LDAP Data Interchange Format
➢ Possibilité d'importer et d'exporter une base de
données LDAP
➢ Fichier texte de la forme :
dn: <distinguished name>
<attrdesc>: <attrvalue>
<attrdesc>: <attrvalue>
...
➢ Attrdesc est le nom de l'attribut ou bien son OID

60
Exemple d'un fichier LDIF avec 2
entrées
# entrée Paul Pogba
dn: cn=Paul Pogba,ou=Juventus,dc=IT
cn: Paul
Pogba
cn: P P
objectClass: person
sn: Pogba
# photo JPEG dans un fichier
jpegPhoto:< file://chemin/vers/fichier.jpeg

# entrée Steve Harris

dn: cn=Steve Harris,ou=Maiden,dc=UK
cn: Steve Harris
objectClass: person
sn: Harris
# toute donnée non ASCII est codée en Base64
jpegPhoto:: /9j/4AAQSkZJRgABGGGTAQABAAD/2wBDABALD
A4MCEETQ4SERATGCgaFTRWGDEjJR0oOjM9PDkzODdASFxOQ
FEXRTd5UG1RV19iZ2hnPk1xeXBkeFxlZ2P/2wBDARESEhgVG
61
 Modèle fonctionel
➢ Définit les opérations suivantes :
➢ Interrogation
➢ Comparaison
➢ Mise à jour
➢ Authentification et contrôle

62
 Types de requêtes
➢ Connexion :
➢ Bind : le serveur authentifie le dn de l'utilisateur
avec un mot de passe (attribut userPassword), ou
bien bind anonyme
➢ StartTLS : pour éviter l'échange de mot de passe en
claire, par exemple. TLS assure la confidentialité et
l'intégrité
➢ Mise à jour et interrogation :
➢ Search, Add, Delete, Modify, ...

63
 Interrogation
➢ Pour lire une entrée il faut effectuer une requête
qui pointe sur cette entrée
➢ Cette requête peut couvrir l'entrée uniquement,
le niveau inférieur ou bien le sous-arbre complet
(search scope)
➢ Filtre de recherche :
(<operator>(<search operation>)(<search operation>)...))

64
 Exemples de filtres
(cn=Del Piero) égalité Nom = "Del Piero"

(cn=*Pier*) sous-chaîne Nom contient "Pier"

(cn~=piero) approximation Nom sonne comme "piero"

(employeenumber>=150) comparaison Numéro supérieur à 150

(sn=*) existance Tous les noms propres

(&(sn=Del Piero)(ou=Turin)) ET Nom = "Del Piero" ET se trouve à Turin

(|(ou=Turin)(ou=Sydney)) OU ou = Turin OU Sydney

(!(tel=*)) NON Toutes les entrées sans attribut téléphone

(&) VRAI Toujours vrai

(|) FAUX Toujours faux

65
 Comparaison
➢ Vérifie si l'attribut d'une entrée contient une
valeur donnée
➢ Renvoie Vrai ou Faux

66
 Mise à jour
➢ Ajouter une entrée (add) : les attributs doivent
être conformes au schéma
➢ Supprimer une entrée (delete) : ne doit pas
avoir un enfant
➢ Changer le rdn d'une entrée, ou bien changer la
position dans l'arbre d'une entrée (le dn), faire
les 2 dernières à la fois (rename)

67
 Nécessité de la sécurité
➢ Parmi les différents types de données stockées
dans un annuaire, il y en a qui sont très
critiques et doivent être protégés comme les
mots de passe
➢ Ainsi que les informations concernant le
système d'exploitation de chaque machine d'un
réseau, les numéros de téléphones privés, les
adresses personnelles, etc.

68
Partie III : SMTP

69
 Services de messagerie
➢ But : envoyer des courriers électroniques
(email)
➢ Deux schémas :
➢ standard : celui utilisé historiquement
➢ Webmail : de plus en plus répandu (Hotmail, Gmail,
udamail, ...)

70
 Services de messagerie : SMTP
➢ SMTP : Simple Mail Transfer Protocol
➢ Destiné à l'envoi et à l'acheminement des
messages
➢ Envoi des messages
➢ par un MUA : Message User Agent (logiciel de
messagerie type Mozilla Thunderbird, Eudora, Microsoft
Live Mail, Outlook Express...)
➢ vers un MTA : Message Transfer Agent
➢ Puis, transfert de MTA en MTA jusqu'au MTA
destinataire
➢ La route d'un MTA au suivant est tracée grâce au
DNS 71
 Schéma général : standard

Côté Émetteur Côté Récepteur

MUA MUA
POP ou
SMTP IMAP
MDA
MTA MTA
MTA
SMTP

72
 Schéma général : Webmail

Côté Émetteur Côté Récepteur

Navigateur Web Navigateur Web

HTTP HTTP

Serveur Webmail Serveur Webmail

POP ou
SMTP
IMAP
MTA MTA MTA
SMTP

73
 Deux schémas
➢ Les deux schémas ne sont pas exclusifs
➢ Exemples :
➢ côté émetteur suivant le schéma standard et côté
récepteur suivant le schéma Webmail
➢ côte récepteur : le serveur Webmail peut aussi être
interrogé via POP3 ou IMAP

74
 SMTP
➢ Échanges par des requêtes (port 25)/réponses
➢ Quelques commandes :
➢ Ouverture : HELO, fermeture : QUIT
➢ Émission du courrier avec successivement :
➢ MAIL : transmission de l'adresse de l'émetteur
➢ RCPT : adresse(s) du ou des destinataire(s)
➢ DATA : pour le corps du message
➢ Le récepteur répond par un code :
➢ 220 : prêt, 250 : OK, 550 : destinataire inconnu, etc.

75
 SMTP
Exemple de dialogue entre 2 MTA
iut.u-clermont1.fr sancy.univ-bpclermont.fr

Établissement connexion TCP

en précisant le port 25

220 sancy.univ-bpclermont.fr
EHLO iut.u-clermon
t1.fr
250-sancy.univ-bpclermont.fr
MAIL From: <xy@iu
t.u-clermont1.fr>
250 Ok
RCPT To: <zz@sanc
y.univ-bpclermont.fr>
250 Ok
Message Body
...
Message Body
Message Body (= « .
»)
250 Ok : queued as 4A46622 (→ id)
QUIT
221 Bye

76
Exemple de dialogue entre MUA et MTA
Client iut.u-clermont1.fr
Établissement
connexion TCP
en précisant le port 25
220 iut.u-clermont1.fr
EHLO 192.168.xx.yy
500 unrecognized command SMTP et non pas ESMTP
HELO 192.168.xx.yy
250-iut.u-clermont.fr
MAIL From: <xy@iut.u-clermon
t1.fr>
250 Ok
RCPT To: <zz@sancy.univ-bpcle Enveloppe
rmont.fr>
250 Ok
DATA
354 Enter Mail, end with «.» on a line by itself
Message Body
...
Message Body
Message Body (= «.»)
250 Ok : queued as 4A46622
QUIT
77
221 Bye
 Code des réponses du serveur
➢ Le premier chiffre est le plus imporant :
➢ 2xx : tout est OK
➢ 4xx : problème temporaire, réessayez plus tard
➢ 5xx : problème permanent, pas la peine de
réessayer

78
 Forme des adresses
➢ Adresses conformes aux règles du DNS
➢ Exemples :
➢ Forme classique : gerard.chalhoub@udamail.fr
➢ gerard.chalhoub@udamail.fr (commentaire) : entre
( ) ce sont des commentaires
➢ "super user"@udamail.fr : "super user" doit être
interprété comme un seul mot
➢ Gérard Chalhoub <gerard.chalhoub@udamail.fr> :
seule doit être interprétée la partie entre < >

79
 DNS et contenu d'un message
➢ Un MUA possède l'adresse du MTA dans sa
configuration
➢ Le premier MTA interroge le DNS pour
connaître l'adresse IP du serveur SMTP du
destinataire :
➢ Ressource MX dans le DNS
➢ Le «message body» SMTP comporte 2 parties :
➢ Entête avec «Received», «To», «From», «Subject»
➢ Une ligne blanche
➢ Corps du message 80
 Format de l'entête
➢ mot_clé : argument (tous ne sont pas
obligatoires)
➢ From : nom de l’expéditeur ayant rédigé l’email
➢ Sender : nom de l’expéditeur qui a envoyé l'email
➢ Reply-To : précise une adresse de réponse
➢ Return-Path : adresse de retour de l’enveloppe (cas
d'erreurs)
➢ To : liste des destinataires principaux
➢ Cc : liste des destinataires en Carbon Copy
➢ Bcc : liste des destinataires en Blind Carbon Copy
81
 Format de l'entête (suite)
➢ Subject : précise le sujet
➢ In-Reply-To : référence du courrier auquel on répond
➢ Message-Id : Identificateur unique du message,
permet d'éviter les bouclages
➢ Date : date de l'envoi
➢ Received : indique des informations relatives aux MTA
utilisés (indique le chemin suivi)
➢ ...
➢ X-... : autre indication – non normalisé

82
 Exemple d'échange
Return-Path: <capaller@iut.u-clermont1.fr>
Received: from CapalleraP ([192.168.xx.yy])
by iut.u-clermont1.fr (8.12.11/jtpda-5.3.3) with SMTP id
j0L9fRU0016701
; Fri, 21 Jan 2005 10:41:27 +0100
From: "Florence Capallera" <capaller@iut.u-clermont1.fr>
To: =?iso-8859-1?Q?TOUSSAINT_Jo=EBl?= <Joel.Toussaint@iut.u-
clermont1.fr>,
"Antonio R. de Freitas" <freitas@sancy.univ-bpclermont.fr>
Subject: =?iso-8859-1?Q?D=E9coupage_pour_les_=E9tudiants?=
Date: Fri, 21 Jan 2005 10:41:26 +0100
Message-ID: <AKEHJBBNDBGHJNOKBGCCCEGICCAA.capaller@iut.u-
clermont1.fr>
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="----=_NextPart_000_000B_01C4FFA5.C1DA6A60"
83
 Exemple d'échange (suite)
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
In-Reply-To: <41EFB036.8030400@sancy.univ-bpclermont.fr>
X-Virus-Scanned: ClamAV 0.80/640/Thu Dec 23 19:48:27 2004
clamav-milter version 0.80j
on quicksilver
X-Virus-Status: Clean
X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on
quicksilver.u-clermont1.fr
X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED
autolearn=disabled version=3.0.2
X-Spam-Level: ...

84
 MTA intermédiaires

Exemple d'entête avec 2 MTA intermédiaires

Received: from mail.libertysurf.net (webmail-out.tiscali.fr

[213.36.80.105])
by iut.u-clermont1.fr (8.12.11/jtpda-5.3.3) with SMTP id
j01GnOih012780
for <toussaint@iutsux01.u-clermont1.fr>; Sat, 1 Jan 2005
17:49:25 +0100
Received: from tiscali.fr (192.168.10.57) by mail.libertysurf.net
(7.1.026)
id 41A46CD900135843; Sat, 1 Jan 2005 17:45:15 +0100

85
 Notion d'enveloppe
➢ La liste des destinataires n'est pas modifiée au
cours du transfert. Or au cours de ce transfert,
certains destinataires auront été desservis.
Comment un MTA va-t-il savoir quels
destinataires restent à desservir ?
➢ Solution :
➢ mettre le message dans une enveloppe précisant la
liste des destinataires,
➢ on ôte un destinataire de l'enveloppe lorsque le
message lui est parvenu,
➢ l'enveloppe passe au MTA suivant si nécessaire 86
 ESMTP et MIME
➢ Conçu par des anglos-saxons => codage en
ASCII sur 7bits d'où pas d'accents...
➢ Solutions :
➢ ESMTP : Extended SMTP (transmission en ASCII
sur 8bits)
➢ MIME : Multipurpose Internet Mail Extensions (cf
plus loin)

87
 POP et IMAP
➢ Protocoles permettant à un UA (logiciel de
messagerie) de récupérer les messages reçus
sur le serveur MTA
➢ POP : transfert des messages (dans leur
intégralité) sur le client
➢ IMAP : permet de gérer le courrier qui reste sur
le serveur (pratique pour des lectures via
liaisons bas-débit) :
➢ récupération sur le client de la seule entête
➢ gestion de boîtes aux lettres sur le serveur
88
 POP3
➢ Post Office Protocol version 3 le + répandu
(TCP port 110), quelques commandes :
➢ USER puis PASS : autorisation d'accès au serveur (en clair)
➢ APOP : autorisation d'accès, nom et mot de passe crypté
➢ STAT : donne le nombre et la taille totale des messages
➢ LIST nombre : demande de la taille du message n°nombre
➢ RETR : copie du serveur vers le client du message n°nombre
➢ DELE : suppression sur le serveur du message n°nombre
➢ TOP message n : récupération des n premières lignes du
message
➢ QUIT : pour quitter
➢ réponse par +OK ou -ERR 89
POP3 : diagramme d'échanges
Client iut.u-clermont1.fr

Établissement
connexion TCP

+OK
AUTH
+OK
CAPA
+OK Capability list follows
USER chalhoub

+OK Password required

PASS xxyyzz
ets
+OK chalhoub has 2 messages in 8010 oct
STAT
+OK 2 8010

90
POP3 : diagramme d'échanges
(suite)
client iut.u-clermont1.fr
LIST
2 8010
+OK...
1 5983 2 2027
RETR 1

+OK 5983 octets

Continuation
...
Continuation
DELE 1
+OK Message 1 deleted
QUIT
+OK

91
 IMAP
➢ Internet Message Access Protocol (TCP port
143), exemples de commandes :
➢ APPEND : ajout d'un message dans une boite aux lettres
➢ SEARCH : recherche de messages
➢ FETCH : récupération de l'entête, du message, ou d'une
partie MIME
➢ STORE : modification des flags des messages sur le
serveur
➢ COPY : copie d'un message dans une boîte aux lettre
➢ LOGOUT : on quitte
➢ ...
92
 Webmail

Navigateur Web

HTTP
Serveur Web Base de données
(interpréteur PHP/ASP)
POP ou
SMTP
IMAP
MTA
SMTP ...

93
 MIME
➢ Multipurpose Internet Mail Extensions
➢ Extension de SMTP
➢ Code toutes les données en ASCII avant de les
transmettre
➢ Dans l'entête : indication
➢ de la version de MIME utilisée : MIME-Version: 1.0
➢ du type des données transmises
➢ de la technique de codage

94
 Types de base prédéfinis
type de base sous-type
➢ Text
➢ Content-Type: text/plain; charset="iso-8859-1";
format=flowed
➢ Audio, Image, Vidéo
➢ message (message réexpédié inclus dans un
autre message)
➢ application (exemple : Fichier attaché) destiné à
un programme donné
➢ Content-Type: application/octet-stream; name="LicenceSem5.xls"
➢ Content-Transfer-Encoding: base64
➢ Content-Disposition: attachment; filename="LicenceSem5.xls" 95
 MIME : exemple
➢ Multipart : message constitué de plusieurs
parties différentes codées de façon distincte par
MIME indique la valeur
du séparateur entre les
MIME-Version: 1.0 différentes parties
Content-Type: multipart/mixed;
boundary="----=_NextPart_000_000B_01C4FFA5.C1DA6A60"
...
------=_NextPart_000_000B_01C4FFA5.C1DA6A60
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 8bit

Bonjour à tous,
...
96
 MIME : exemple (suite)

...
A+
------=_NextPart_000_000B_01C4FFA5.C1DA6A60
Content-Type: application/vnd.ms-excel;
name="DescriptionEtudiants.xls"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="DescriptionEtudiants.xls"

0M8R4KGx
...
ABAAAAAAAAA=

------=_NextPart_000_000B_01C4FFA5.C1DA6A60--
97
 S/MIME
➢ Version sécurisée S/MIME avec chiffrement des
données et algorithme à clé publique

98
 SPAM
➢ Réception de courriers non sollicités, émis en
masse
➢ Moyens de lutte : des filtres
➢ Au niveau du client final (filtres personnels)
➢ Au niveau de la distribution finale
➢ Au niveau des MTA : élimination des messages
➢ Avec adresse source fantaisiste (nom de domaine
inexistant => se servir du DNS)
➢ En provenance de serveurs connus pour relayer des
SPAMs (utilisation de la RBL : RealTime Blackhole List)
➢ Note : tout faire (soigneusement configurer) pour éviter que son
MTA apparaisse dans cette RBL ! 99
 Adresse de diffusion, ex :
enseignants_rt@udamail.fr

Spool des Client MTA

messages pour l'envoi distant
UA émettant sortant via connexion
du courrier TCP
Expansion des alias,
Interface réexpédition
UA recevant
du courrier Spool des Serveur
messages pour la réception
entrant via connexion MTA
TCP distant

100
 Quelques outils
➢ Serveurs SMTP : les MTA
➢ sendmail (Unix et Windows, le plus répandu mais
en perte de vitesse, très délicat à configurer),
➢ Exchange (Windows)
➢ Postfix
➢ Clients : les MUA
➢ (Mozilla) Thunderbird, Netscape (Unix et Windows)
➢ (x)mail, elm,
➢ Outlook, Eudora (Windows)
101
 Outils Webmail
➢ Webmail : SquirrelMail, Outlook Web Access...
➢ Outil anti-Spam :
➢ sur serveur : SpamAssassin...
➢ Sur client : intégré à Thunderbird...
➢ Outils de filtrage des virus
➢ Des utilitaires de :
➢ Tri automatique à la réception
➢ Renvoi automatique de réponse (ex : en cas
d'absence)
➢ ... 102
 Quelques RFC
➢ RFC
➢ RFC 821 : SMTP
➢ RFC 2822 : format des messages
➢ RFC 974 : Courrier et DNS
➢ RFC 1521 : MIME
➢ RFC 1652, 1869 : SMTP Extensions
➢ RFC 1939 : POP3
➢ RFC 2060 : IMAP4
➢ ...
103