Support Formation Intranet - Internet

Services Réseaux
Prof. GOORE BI Tra

Département Mathématiques – Informatique
Institut National Polytechnique Félix Houphouët Boigny (INP-HB)
[email protected] / (+225) 58 50 13 04
Services réseaux
Objectifs
A l’issue de cette formation les participants seront

capables de:
- Expliquer le fonctionnement des principaux services
réseaux (DHCP, DNS, Web, Proxy, Mail)
- Configurer les différents services cités dans
l’environnement Linux
© 2021– Prof. GOORE BI Tra – Maître de Conférences- Département Mathématiques et Informatique – INPHB – Yamoussoukro - (+225) 07 58 50 13 04 - [email protected]
Services Réseaux
Points abordés
1. Généralités sur Internet
2. Configuration manuelle des interfaces réseau
3. DHCP
4. DNS
5. Web/Apache
6. Proxy (Squid)
7. Messagerie (Postfix)
3
Services Réseaux
Généralités sur Internet

Objectifs spécifiques Contenu
Cette session de cours est une introduction aux

services réseau. A l’issue de la session, les 1. Qu’est ce que Internet
participants seront capables de : 2. Les acteurs de l’Internet
- Comprendre les différents acteurs qui 3. Qu’est ce que l’intranet et l’Internet
interviennent dans la gestion de l’Internet
- Comprendre les éléments caractéristiques
d’un intranet et d’un extranet
Qu’est ce que l’Internet ?
 Qu’est ce que l’internet ?
 L’Internet (inter network ou « inter réseau ») est un réseau de réseaux
d’ordinateurs connectés entre eux à l’échelle mondiale
 Il est basé sur le protocole TCP/IP
 Il est né dans les années 1960, en plein milieu de la « guerre froide » entre
le bloc de l’est (l’Urss) et le bloc de l’ouest (l’Amérique et l’Europe).
 Il a été créé à partir d’une initiative du Ministère Américain de la Défense
pour limiter la vulnérabilité des réseaux informatiques en cas d’attaque.
5
Qu’est ce que l’Internet ?
 Les grandes dates de l’Internet
 1964: Début du projet ARPANET
 1989: Berners-Lee conçoit la base du World Wide Web.
 1990: Les chercheurs du centre d’étude et de recherche nucléaire de
Genève (CERN) inventent le concept de World Wide Web (WWW) et le
langage hypertexte associé (HTML).
 1993 : Apparition des navigateurs dont l’ancêtre fut MOSAIC inventé par
Marc Andreesen de l’université de l’Illinois,
 1995: Année de la vulgarisation publique de l’Internet. C’est véritablement à
partir de cette date que le terme « Internet » est entré dans le vocabulaire
quotidien. 6
6
Les acteurs de l’Internet
 ICANN (Internet corporation for assigned names and numbers)
 Organisme américain à but non lucratif en charge de la gestion de
ressources techniques essentielles de l’Internet
 Il coordonne les systèmes d’identifiants uniques d’Internet: Adresses IP,
registres, espace de domaines de premier niveau
 Organisme régulateur de l’Internet
 Composée de nombreuses commissions
7
Les acteurs de l’internet
 IANA (Internet Assigned Numbers Authority)
 Autorité chargée de la gestion de l'adressage sur Internet
 Les activités de l’IANA peuvent classées en 3 grandes catégories:
 Ressources de numéros
 L'IANA coordonne la base mondiale des adresses de protocoles Internet et des numéros
de systèmes autonomes, et les soumet aux registres Internet régionaux.
 Noms de domaine
 L'IANA gère la racine du système de noms de domaine, les domaines .int et .arpa, et
certaines ressources de noms de domaine internationalisés
 Affectation de protocole
 L'IANA gère les systèmes de numérotation des protocoles Internet avec les organes de
normalisation compétents
8
8
 ISOC (Internet Society)
 Association ayant pour but de promouvoir l’Internet en diffusant l’information
au public, de promouvoir la coopération mondiale et la coordination
d’Internet, de ses technologies inter réseaux et de ses applications
 Il assure le développement, l’évolution et l’utilisation ouverts dans l’intérêt de
tous de par le monde
 Elle intègre à la fois la gestion de problématiques techniques pointues au
travers de l’IETF, qui élabore les standards de l’internet, et les réflexions
nées d’échanges entre les utilisateurs de l’internet regroupés en « chapitres
» dans le monde entier.
9
9
 IETF
 Il conçoit et facilite une vaste gamme de normes internet relatives
notamment aux normes de la suite de protocole d’Internet
 IAB (Internet Architecture Board)
 Supervise le développement technique et d’ingénierie de l’IEFT et l’IRTF
 W3C
 Crée des normes pour le Word Wide Web.
 Les fournisseurs d’accès
 Fournisseur de service le plus visible de l’utilisateur de l’Internet
10
10
 Les RIR (Regional Internet Registries - Registres Internet
Régionaux)
 Sociétés sans but lucratif qui gèrent et enregistrent les adresses IP d’une
région
 Chaque RIR distribue des ressources de numéros d’Internet qui lui sont
allouées pour les opérateurs de réseau dans sa région selon l’affectation et
l’attribution des politiques définies par sa propre communauté régionale
(Registres Internet locaux (LIR) )
11
11
 Les RIR
 APNIC(Asia Pacific Network Information Center - 1993) : Région Asie-
Pacifique
 ARIN (American Registry for Internet Numbers - 1997): Amérique du nord
et certaines parties des caraibes
 LACNIC(Latin America and Caribbean Network Information Center - 1999):
Amérique centrale, du sud et certaines parties des Caraibes
 RIPE NCC (Réseaux IP Européens - 1992): Europe et moyen Orient
 AfricNIC(African Network Information Center - 2005): Afrique 12
12
 Les RIR
13
13
Intranet et Extranet
 Qu’est ce qu’un Intranet
 C’est un réseau interne à l’entreprise qui utilise la même technologie
qu’Internet
 Utilité de l’Intranet
 Mise à disposition de l’information de l’entreprise
 Echange de données entre collaborateurs en interne
 Favorise la communication au sein de l’entreprise et limite les erreurs dues à la
mauvaise circulation d’une information
 L’extranet
 Ouverture des données de l’entreprise à des acteurs extérieures
 Les données sont diffusées par un serveur Web et accessible après
14
authentification sécurisée.
© 2021– Prof. GOORE BI Tra – Maître de Conférences- Département Mathématiques et Informatique
14 – INPHB – Yamoussoukro - (+225) 07 58 50 13 04 - [email protected]
Services Réseaux
Configuration manuelle des interfaces réseau

A l’issue de cette session de formation, les 1. Principe de nommage des interfaces

participants seront capables de: réseaux
- Expliquer le principe de nommage des 2. Les commandes IP
interfaces réseaux sous Linux
3. L’outil netplan
- Utiliser les commandes IP
- Utiliser l’outil netplan pour configurer les
interfaces réseau sous Linux
Nommage des interface réseaux
 ancien principe de nommage
 Avant le noyau Linux 4.4, les noms des interfaces réseau étaient: eth0,
eth1, eth2, etc.
 Ces noms étaient définis, au démarrage, par le noyau suivant l’ordre de
détection de l’interface
 Cette manière de faire pose quelques problèmes
 Les interfaces eth0, eth1,... peuvent s'inverser au démarrage
 En cas d'ajout de matériel, les interfaces peuevnt se renuméroter
 En cas de remplacement d'une carte réseau défectueuse, la renumérotation des
interfaces peut se produire.
 Il est donc impossible de connaître le nom de l’interface à l’avance
16
© 2021– Prof. GOORE BI Tra – Maître de Conférences- Département Mathématiques et Informatique – INPHB – Yamoussoukro - (+225) 07 58 50 13 04 - [email protected] 16
 Nouveau principe de nommage (1)
 A partir du noyau Linux 4.4, les cartes réseaux sont nommées en fonction
de leur nature et de leur emplacement physique dans l’ordinateur.
 Il suit le principe suivant:
 Un préfixe de 2 lettres pour désigner la nature du réseau
 en: Ethernet
 wl: Wireless
 Un suite de caractères alphanumériques commençant par une lettre pour désigner
le périphérique
 o<index> : index du périphérique Onboard (carte intégrée à la carte mère)
 s<slot> : numéro du slot pour cartes branchées à chaud
 P<bus>s<slot>: numéro du bus et du slot PCI 17
 Etc.
 Nouveau principe de nommage (2)
 Exemple de nom d’interface
 eno1
 enp0s3
 wlp3s1
18
Les commandes ip
 Apports de la commande ip
 Elle remplace désormais la commande «ifconfig» devenue obsolète
depuis la version de Ubuntu 17.10
 La commande «ifconfig» n’est plus présente par défaut. Elle peut être
installée à partir du package «net‐tools»
 Elle apporte de nouvelles fonctionnalités dont :
 La possibilité d’attribuer plusieurs adresse IP à une même interface
 Le remplacement de plusieurs commandes réseau Linux qui en sont des options de
sa syntaxe: arp, ifconfig, netstat, route, Etc.
 La possibilité de modifier des paramètres réseau tels que:
 MTU
 Adresse MAC 19
Les commandes ip
 Syntaxe de la commande ip (1)
 Attribution d’adresse ip
ip address add «addresse/masque» dev «nom_interface»
ip address add 172.30.30.2/24 dev enp0s3
 Suppression d’une adresse IP d’une interface

ip address del «addresse/masque » dev «nom_interface»
ip address del 172.30.30.2/24 dev enp0s3
 Suppression de toutes les adresses attribuées à l’interface
ip address flush dev «nom_interface»
ip address flush dev enp0s3 20
Les commandes ip
 visualisation des adresses et propriétés des interfaces
ip address [ show [dev «nom_interface»] ]
ip address
ip address show
ip address show dev enp0s3
 Visualisation de l’état des interfaces réseaux
ip link [ show [dev «nom_interface»] ]
ip link show
ip link show enp0s3
21
Les commandes ip
 Activation/désactivation d’une interface
ip link set «nom_interface» up | down
ip link set enp0s3 up
ip link set enp0s3 down
22
L’outil netplan
 Principe
 La commande «ifconfig» étant devenue obsolète, le fichier de configuration
réseau «/etc/network/interfaces» n’est plus utilisé.
 Désormais c’est l’outil netplan qui est utilisé
 Netplan permet de créer une description de la configuration de l’interface
réseau dans un fichier au format YAML
 Les fichiers de configuration des interfaces se trouvent dans le répertoire
/etc/netplan
 Le fichier Yaml est soumis au gestionnaire de réseau tel que Network
manager (renderer)
23
L’outil netplan
 Configuration permanente des cartes réseau avec Netplan (2)
 Qu’est ce que YAML ?
 YAML
 Acronyme de Yet Another Markup Language dans sa version 1.01
 Acronyme récursif de YAML Ain't Markup Language (« YAML n’est pas un langage de
balisage ») à partir de sa version 1.12
 L'idée de YAML est que presque toute donnée peut être représentée par
combinaison de listes, tableaux associatifs et de données scalaires.
 L’extension des fichiers YAML est .yaml ou .yml
24
L’outil netplan
 Syntaxe de YAML
 Tableau associatif (Dictionnaire)
key1: value1
key2: value2 ou { key1: value1, key2: value2,
key3: value3 key3: value3}
 Imbrication de tableau
 La valeur d’une clé peut être à son tour un tableau
 Il suffit d’ajouter une indentation à un tableau ( des espaces et non des tabulations)
Element :
item1:value1 {Element: {item1: value1, item2: value2}
25
item2:value2
L’outil netplan
 Syntaxe de YAML
 Séquence d’éléments (liste)
‐ element1
‐ element2 ou [element1, element2, element3]
‐ element3
26
L’outil netplan
 YAML: imbrication de dictionnaire dans une liste
‐ element1: ‐ element1: {key11: value11, key12: value12}
key11:value11 ‐ Element2:
key12:value12 ‐ element3: {key31:{key311:value311,
‐ element2: key312:value:312}, key32:[element321,
‐ Element3: ou
element322, element323]}
key31:
key311:value311
[{element1: {key11: value11,
key312:value312 key12: value12} },
key32: element2:,
‐ element321 {element3: {key31: {key311: value311,
key312: value312},
‐ element322
key32: [item321,
‐ element323 item322,
item323']}}]
27
L’outil netplan
 Exemple Configuration d’un client DHCP avec YAML
network:
version: 2
renderer: networkd
ethernets:
enp3s0:
dhcp4: true
28
L’outil netplan
 Exemple de configuration statique des interfaces avec YAML
network:
version: 2
renderer: networkd
ethernets:
enp3s0:
addresses:
‐ 192.168.0.2/24
‐ 192.168.0.3/24
29
L’outil netplan
 Exemple de configuration statique des interfaces avec YAML
network:
version: 2
renderer: networkd
ethernets:
enp3s0:
addresses:
‐ 192.168.2.2/24
gateway4: 192.168.1.1
nameservers:
search: [inphb.ci, larit.ci]
addresses: [213.136.96.7, 8.8.8.8] 30
L’outil netplan
 Les commandes Netplan
 netplan apply
 Génère la configuration du réseau pour les moteurs de rendu (renderer) et applique
toute la configuration, en les redémarrant si nécessaire.
 netplan generate
 génère la configuration du réseau pour les moteurs de rendu (renderer).
 Cette commande est invoquée par la commande apply ou au démarrage des
services réseau (service systemd‐networkd restart)
 netplan try
 Essaie d’applique la configuration et attend la confirmation de l’utilisateur.
31
Services Réseaux
Service DHCP
A l’issue de cette session de formation, les 1. Principe de fonctionnement d’un service

participants seront capables de: DHCP
- Expliquer le principe de fonctionnement d’un 2. Configuration d’un serveur DHCP
service DHCP 3. Configuration d’un client DHCP Linux
- Configurer un serveur DHCP sous Linux 4. Configuration d’un client DHCP Windows
- Configurer des clients DHCP sous Linux et
sous Windows
Introduction
 DHCP (Dynamic Host Configuration Protocol)
 Le protocole DHCP permet l'attribution automatique des paramètres IP à
des machines clientes à partir d’un serveur DHCP
 Adresse IP
 Masque de sous-réseau
 Adresse IP du serveur DNS
 Nom de domaine
 Passerelle par défaut
 Paramètres relatifs au DHCP tel que le bail
 Paramètres IP,TCP,ARP tels que MTU, TTL, la durée du cache ARP,
 Etc.
33
© 2021– Prof. GOORE BI Tra – Maître de Conférences- Département Mathématiques et Informatique – INPHB – Yamoussoukro - (+225) 07 58 50 13 04 -
[email protected] 33
Introduction
 Avantages
 Eviter les erreurs liées à la configuration manuelle des clients.
 Faciliter l’attribution des adresses IP dans un grand réseau
 Faciliter les modifications de configuration réseau comme le changement
d’adresse d’un routeur ou d’un serveur de noms.
 Modèle de fonctionnement
 Modèle client – serveur
 Port d’écoute du serveur: UDP 67
 Port d’écoute du client: UDP 68
34
Principe de fonctionnement
 principaux messages DHCP
1
DHCPDISCOVER (Broadcast)
Serveur Client
DHCP DHCP
2
DHCPOFFER (Broadcast)
SE
3
DHCPREQUEST (Broadcast)
4
DHCPPACK (Broadcast) 35
 Principaux messages DHCP

Message Source Destination Description
DHCPDISCOVER 0.0.0.0 255.255.255.255 Requête pour paramètre
DHCPOFFER IP Serveur 255.255.255.255 Proposition d’offre
DHCPREQUEST 0.0.0.0 255.255.255.255 Acceptation d’une offre
DHCPACK IP Serveur 255.255.255.255 Accusé de réception
DHCPRELEASE IP client IP serveur Abandon des paramètres

36
 Les messages DHCP
 DHCPNAK
 Il est envoyé par le serveur pour rejeter un message «request » de la part d’un
client à la suite d’une demande ne pouvant pas être satisfaite (par exemple un
temps de bail). Aucune adresse IP n’est envoyé au client ou que le bail a expiré
 DHCPINFORM
 Ce message est envoyé par le client pour demander d’autres options de
configuration, après avoir obtenu une adresse IP. Cette obtention peut être annuelle
ou automatique à partir d’un serveur DNS. Les autres options sont par exemple
l’adresse de la passerelle et du DNS.
 DHCPDECLINE
 Il est envoyé par le client pour notifier le serveur que l’adresse IP qu’il existe 37
déjà
dans le réseau.
 Format d’un message DHCP
1=requête Type d’adresse physique Longueur adresse Saut utilisé par les
2=réponse physique routeurs
XID: id de la transaction
Temps de depuis init client: 2 octets Indicateurs:2 octets
Adresse Ip client (ciaddr): 4 octets
Votre adresse Ip (yiaddr): 4 octets
Adresse Ip serveur (siaddr): 4 octets
Adresse Ip passerelle (giaddr): 4 octets
Adrese matérielle client (chaddr): 4 octets
Nom de serveyr (sname): 64 octets
Nom de fichier: 128k
Options: liste des paramètres supplémentaires affectés au client, ainsi que le type de
message (DISCOVER, REQUEST, etc.) taille vriable
38
 Trois modes d’attribution des adresses
 Attribution permanente
 Sur le serveur DHCP, l'administrateur pré-alloue les paramètres réseau au client et
DHCP se charge uniquement de lui communiquer. Il n’y a donc pas de bail.
 Attribution permanente automatique
 Le serveur DHCPv4 attribue automatiquement et définitivement les paramètres
réseau à un périphérique mais en sélectionnant l’adresse IP dans un pool
d'adresses disponibles. Il n’y a donc pas de bail.
 Attribution dynamique
 En plus des autres paramètres, le serveur DHCPv4 attribue dynamiquement une
adresse IPv4 à partir d'un pool d'adresses pendant une durée limitée définie
(période de bail). 39
 Renouvellement manuel du bail
 Sous Windows
 ipconfig /release : abandon des paramètres
 ipconfig /renew : renouvellement après abandon
 Activation et désactivation de la carte réseau
 sous Linux
 dhclient
40
 Renouvellement automatique du bail
 A 50% de l’utilisation du bail, le client envoie un message DHCPREQUEST
pour le renouvellement de son bail
 Si elle est accordée, le client continue avec un nouveau bail et
éventuellement de nouveaux paramètres.
 Si le serveur est absent, le bail reste donc valide
 A 87.5% du bail, si le serveur est indisponible, le client envoie un message
DHCPDISCOVER.
 A 100% du bail (le bail a expiré), la procédure d’obtention normale d’un bail
est lancée.
41
Configuration du serveur DHCP
/etc/dhcp/dhcpd.conf
 Installations du serveur (ubuntu)

apt install isc‐dhcp‐server
 Les fichiers de configuration

 configuration de l’interface d’écoute du serveur
 /etc/default/isc‐dhcp‐server
 fichier principal de configuration
 /etc/dhcp/dhcpd.conf
 Fichier des bails attribués

 /var/lib/dhcp/dhcpd.leases
42
 Les principaux paramètres de configuration
 Passerelle par défaut
 option routers «@IP[,@IP...]»
 Adresse de broadcast
 option brodcast‐address «@IP de diffusion»
 Nom de domaine
 option domain‐name «nom de domaine»
 Adresses de serveurs de noms par ordre de préférence.
 option domain‐name‐servers «@IP[,@IP...]»
43
 Les principaux paramètres de configuration
 Pool d’adresse à distribuer aux clients
 range «@ip1 @ip2»
 Durée de bail par défaut
 default‐lease‐time «temps en seconde»
 Durée de bail maximal
 max‐lease‐time «temps en seconde»
44
 Les principaux paramètres
 Exemple
option routers 193.145.10.11;
option subnet‐mask 193.145.10.240;
option domain‐name "inphb.ci";
option domain‐name‐servers 193.145.10.10;
range 193.145.10.20 193.145.10.254;
default‐lease‐time 7200;
max‐lease‐time 43200;
45
 Les déclarations
 Les déclarations permettent de limiter la portée des paramètres à:
 Réseau: subnet
 Ensemble de réseau: shared‐network
 Un hôte : host
 Ensemble d’hôtes et de réseau: group
 La définition d’un paramètre dans une déclaration est prioritaire à la
déclaration globale du même paramètre
46
 La déclaration « subnet »
 Elle permet de définir un ensemble de paramètres pour un sous réseau
auquel appartient l’interface physique d’écoute du serveur DHCP
subnet «ip réseau» netmask «masque»{
Paramètres spécifiques du sous réseau ;
}
47
 La déclaration « subnet »
 Exemple
subnet 193.145.10.0 netmask 255.255.255.240 {
option subnet‐mask 255.255.255.240;
option domain‐name "inphb.ci";
option domain‐name‐servers 193.145.10.10;
range 193.145.10.20 193.145.10.254;
default‐lease‐time 21600;
} 48
 Lancement du serveur
 Après avoir renseigné le fichier de configuration, le service peut être
lancé à l’aide de l’une des commandes ci-dessous
/etc/init.d/isc‐dhcp‐server start | restart | stop |status
ou
service isc‐dhcp‐server start | restart | stop |status
49
Configuration du client DHCP
 Configuration du client Linux (1)
 Configuration des interfaces dans un fichier netplan
network:
version: 2
renderer: networkd
ethernets:
enp3s0:
dhcp4: true
50
 Configuration du client Linux (1)
 Un client peut proposer des options de configuration au serveur
 Le fichier client est: /etc/dhclient.conf
 Quelques paramètres du client
 send dhcp‐lease‐time 3600;
 require subnet‐mask, domain‐name‐servers;
 Lancer le client dhcp

Exemple
dhclient [interface [‐v] [‐r] dhclient
dhclient ‐r
51
dhclient –v enp0s3
 Configuration du client Windows
 Dans les propriétés de TCP/IP, il suffit simplement de choisir
 « Obtenir une adresse » IP automatiquement,
 « Obtenir les adresses des serveurs DNS automatiquement
 Renouvellement de bail sous Windows

ipconfig /all : permet d’obtenir le détail des informations de configuration
ipconfig /release : supprime la configuration réseau
ipconfig /renew : renouvelle la configuration réseau
52
 Enregistrement des attributions dans le fichier « leases » (1=
 Les attributions d’adresses aux clients sont consignées dans un fichier de
bail du répertoire : /var/lib/dhcp/dhcpd.leases
 Exemple 1
lease 193.145.10.7 {
starts 1 2020/01/09 10:30:30;
ends 1 2020/01/10 16:30:30;
hardware ethernet 00:50:fc:24:14:82;
client‐hostname “cobra”
}
53
 Enregistrement des attributions dans le fichier « leases » (2)
 Exemple 2
lease 172.30.30.6 {
starts 6 2020/01/25 19:20:18;
ends 6 2020/01/25 19:30:18;
cltt 6 2020/01/25 19:20:18;
binding state active;
next binding state free;
rewind binding state free;
hardware ethernet 38:59:f9:3c:cf:f7;
uid "\0018Y\371<\317\367";
set vendor‐class‐identifier = "MSFT 5.0";
client‐hostname "PC‐SONAUDE";
}
54
 Enregistrement des attributions fichier « leases » (2)
 Exemple 3
lease 172.30.30.5 {
starts 6 2020/01/25 19:20:58;
ends 6 2020/01/25 19:30:58;
cltt 6 2020/01/25 19:20:58;
binding state active;
next binding state free;
rewind binding state free;
hardware ethernet 08:00:27:69:2a:79;
client‐hostname "Dauphin";
}
55
 Atelier 1
 Le réseaux concerné
 Chaque groupe de travail gère son réseau:
172.30.X.0 Web
 Autres données
Mail .4 .253
 Nom de domaine: stic.ci
 Bail par défaut: 24 heures .3 .254
 Bail maximum: 2 jours

Proxy .2
.1
DHCP
56
 Atelier 1 (suite)
Travail à faire
1. Dans le cadre d’une attribution dynamique, donner la configuration du
serveur DHCP conformément au réseau choisi et au schéma,
2. Configurer et lancer le serveur DHCP
3. Vérifier que le serveur DHCP est lancé et fonctionne correctement
4. Configurer un client Linux et vérifier que ce client reçoit bien les
paramètres du serveur
5. Répondre à la même question pour un client Windows
57
Configuration avancée du serveur DHCP
 La déclaration « shared-network »
 Elle permet de regrouper des sous réseaux partageant un même réseau
physique.
shared‐network «nom du réseau» {
«Paramètres spécifiques du réseau partagé»
subnet «IP réseau 1 » netmask « masque» {
Paramètres spécifiques du sous réseau
}
subnet «IP réseau 2» netmask «masque» {
Paramètres spécifiques du sous réseau
}
} 58
 La déclaration « shared-network »
 Elle permet de regrouper des sous réseaux partageant un même réseau
physique.
shared‐network mesReseau {
option routers 192.168.0.254
subnet 192.168.1.0 netmast 255.255.252.0 {
range 192.168.1.200 192.168.1.254;
}
subnet 192.168.2.0 netmast 255.255.252.0 {
range 192.168.2.200 192.168.2.254;
}
} 59
 La déclaration «host»
 Elle permet de définir des paramètres spécifiques à une machine
désignée par son adresse MAC
 Les paramètres sont attribués à la machine de manière définitive
host «nom_machine» {
«Paramètres spécifiques» ;
hardware «type LAN» «adresse Mac» ;
fixed‐address «adresse Ip » ;
}
60
 La déclaration «host» (suite)
 Exemple
host agouti {
hardware ethernet 00:50:FC:24:14:88;
fixed‐address 192.168.1.3;
}
61
 La déclaration «group »
 Elle permet de grouper des machines ou des sous réseau afin de leur
appliquer des paramètres communs.
group {
« Paramètres spécifiques» ;
host « hote1 » {
Paramètres spécifiques
}
subnet «@ip reseau» netmask « mask » {
Paramètres spécifiques}
} ; 62
 La déclaration «group » (2)
 Exempe
group {
host server01 {
hardware ethernet 00:14:3G:00:12:01;
fixed‐address 192.168.1.101;
}
subnet 192.168.1.0 netmast 255.255.252.0 {
range 192.168.1.200 192.168.1.254;
} ; 63
 Atelier 2
On considère la même configuration que dans l’atelier 1
1. Dans le cadre d’une configuration statique, compléter la configuration
de l’atelier 1 avec au moins une configurer statique
2. Tester cette configuration
64
Services Réseaux
Service DNS
1. Introduction
A l’issue de cette session de formation, les
participants seront capables de: 2. Architecture et composants du DNS
- Expliquer la notion de domaine, l’architecture 3. Principe de fonctionnement
et les composants du DNS 4. Mode de résolution de nom
- Expliquer le fonctionnement du DNS
- Configurer et tester un service DNS
5. La résolution inverse
6. Configuration
Introduction
 Problématique
 La technologie de base TCP/IP permet d’atteindre une machine ou tout
objet sur internet par son adresse IP
 Or il est difficile, voire impossible pour les utilisateurs de mémoriser les
adresses IP
 De plus les adresses IP ne sont pas stables
 Les noms sont plus faciles à mémoriser que les nombres
 Les noms sont relativement stables
 Des solutions ont donc été conçues pour la conversion des adresses IP
numériques en nom simple et explicite
66
Introduction
 Les première solution de conversion
 Un seul fichier de conversion «host.txt» maintenu par le SRI-NIC
(Standford Research Institute)
 Problèmes
 Trafic et charge impactés négativement par cette centralisation
 Maintenance difficile avec un seul gros fichier
 Mise à jour fastidieuse
 Collision de noms
 Etc.
67
Introduction
 solution locale du DNS : le fichier hosts
 La plupart des système d’exploitation dispose d’une base de données locale
 Unix: /etc/hosts
 Windows: C:\windows\System32\drivers\etc\hosts
 Syntaxe des fichiers hosts
@IP nom internet raccourci
192.168.2.30 agouti.inphb.ci agouti
 Inconvénients de fichiers hosts

 Mise à jour fastidieuse
 Recherche longue dans un fichier texte
68
Introduction
 Le service DNS (Domain Name System)
 Le DNS a été créé en 1983 par l’américain Paul Vixie Mockapetris
 Par la suite, il a été modifié, mis à jour et amélioré par plusieurs RFC.
 Il permet de trouver une ressource particulière à partir d’un identifiant, trouver
 Une adresse IP à partir de son nom
 Un nom à partir d’une adresse IP
 Un serveur de messagerie à partir d’un nom
 etc.
 Le DNS repose sur 3 composants essentiels
 L’espace de nommage (espace de nom de domaine)
 Le protocole DNS
 Les resolvers (clients) et le serveurs DNS 69
Domaine et zone DNS
 Structure de l’espace de nom de domaine
 L’espace de nommage des objets dans un système DNS est une structure
arborescente à la manière d’un système de fichiers
 Chaque nœud de l’arbre correspond à un domaine
 Chaque nœud porte une étiquette (label)
 La longueur maximale d’une étiquette est de 63 caractères
 Un nom de domaine est une suite d’étiquette de nœud depuis le nœud
correspondant jusqu’au nœud de premier niveau
 La longueur maximale d’un nom de domaine est de 255 caractères
 Les nœuds terminaux de l’arbre sont des noms de machine
 Les noms des domaines sont insensibles à la casse 70
Domaine et zone DNS
 Structure de l’espace de nom de domaine
Domaine racine
Domaine 1er Niveau net sn ci org org

TLD
Domaine 2ème Niveau inphb

esatic
SLD
samba
fromager
iroko
teck
71
Domaine et zone DNS
 Les types de domaine
 Le domaine de niveau racine (root domain) référencé par « . »
 Les domaine de 1er niveau (Top Level Domain-TLD)
 Domaines nationaux : ccTLD (country code TLD)
 ci, sn, cg, fr, etc.
 Domaines réservés
 arpa, edu, gov, int, mil
 Domaines génériques: gTLD (generic TLD
 com, org, net, biz, info, name, etc.
 Les domaine de 2ème niveau (Secondary Level domain – TLD)

 inphb, esatic, etc.
72
Domaine et zone DNS
 La notion de zone
 Une zone est une portion de l’espace de nom de domaine placée sous la
responsabilité d’un serveur de nom
 La zone recouvre au moins un domaine
 Lorsqu’une zone couvre plusieurs domaines,
 Les domaines sont nécessairement contigus dans l’arbre des noms de domaine
 Le nom de la zone est le nom du domaine racine
 Le serveur de nom de la zone contient la base de données des informations
de la zone, c’est-à-dire les correspondances entre les noms et les
ressources de la zone
73
Domaine et zone DNS
 La notion de zone
net sn ci org org
esatic inphb
samba
larit
fromager
iroko
La zone inphb.ci couvre les domaines teck 74
inphb.ci et larit.inphb.ci
Les serveurs DNS
 Principe Domaine @IP serveur DNS
ci 41.65.13.25
Chaque zone est gérée par un serveur sn 63.105.26.30

En considérant que chaque zone
couvre un seul domaine, le serveur
d’un niveau n contient les informations net sn ci
de correspondance des zones des org org
niveau n-1
Domaine @IP serveur DNS
inphb.ci 151.80.22.49
esatic inphb
esatic.ci 167.86.112.112
samba
hôte @IP hôte
fromager iroko.inphb.ci 210.130.130.1
iroko samba.inphb.ci 210.130.130.1

75
teck teck.inphb.ci 210.130.130.1
Les serveurs DNS
 Bases de données DNS (fichier de zone)
 Un serveur de nom gère la base de données DNS d’une zone
 Une base de données DNS contient des enregistrements de ressource
(Resource Records = RR)
 Les ressources sont les objets demandées à partir d’une requête (adresse
IP, nom de machine, adresse du serveur de messagerie, etc.)
 La base de données DNS est:
 Distribuée
 Évolutive
 Fiable
76
Les serveurs DNS
 Serveur autoritaire ou d’autorité sur une zone
 Un serveur est dit autoritaire sur une ou plusieurs zones s’il connaît les
correspondance de toutes les entités de ces zones
 Ainsi Il est capable de répondre aux requêtes sur ces zones à partir des
connaissances locales sans recourir à d’autres serveurs
 Les serveurs autoritaires comprennent
 Les serveurs primaires
 Un serveur primaire contient la base de données (fichier de zone) originale d’une zone
 Il est la source de transfert de zone pour un ou plusieurs serveurs secondaires
 Les serveurs secondaires
 Un serveur secondaire contient la copie de la base de données du serveur primaire
77
 Il utilise le transfert de zone pour restituer la zone
Les serveurs DNS
 Serveur autoritaire ou d’autorité sur une zone
 La notion de transfert de zone
 Un transfert de zone est l’acte d’un client qui demande une copie des données
d’une zone et d’un serveur d’autorité qui envoie les informations nécessaires
 Deux mécanismes de transfert de zone
 AXFR (transfert d’autorité): copie toutes la zone
 IXFR (Transfert incrémentale): copie seulement les parties de zone qui ont été modifiées
 Un serveur de nom peut être primaire pour une ou des zones et secondaire
pour d’autres.
78
Les serveurs DNS
 Serveur cache (serveur récursif)
 Il n’a d’autorité sur aucune zone
 Il stocke, localement les informations de résolutions de nom ou d’adresse
d’autres serveurs en réponse à des requêtes de ses clients
 Il permet de limiter le trafic entre clients et serveurs
 Les réponses sont obtenues des serveurs autoritaires
 Les réponses transférées aux clients sont marquées non autoritaires
 Serveur forwarder
 Il n’a d’autorité sur aucune zone
 Il oriente le client vers les serveurs ayant autorité sur la zone sollicitée
79
Les serveurs DNS
 Les serveurs racines (serveur root) (1)
 Ils ont autorité sur le domaine (zone) racine
 Ils disposent d’informations nécessaires pour atteindre les serveurs de
premier niveau
 Il y a 13 serveurs root dupliqués à travers le monde
 L’accès aux serveurs root se fait selon le mécanisme de «anycast »
 Les adresses des serveurs root sont fournies avec tout logiciel serveur DNS
80
Les serveurs DNS
 Les serveurs racines (2)
Désignation Adresses IP Organisation
a.root-servers.net 198.41.0.4, 2001:503:ba3e::2:30 VeriSign, Inc.
b.root-servers.net 192.228.79.201, 2001:500:200::b University of Southern California (ISI)
c.root-servers.net 192.33.4.12, 2001:500:2::c Cogent Communications
d.root-servers.net 199.7.91.13, 2001:500:2d::d University of Maryland
e.root-servers.net 192.203.230.10, 2001:500:a8::e NASA (Ames Research Center)
f.root-servers.net 192.5.5.241, 2001:500:2f::f Internet Systems Consortium, Inc.
g.root-servers.net 192.112.36.4, 2001:500:12::d0d US Department of Defense (NIC)
h.root-servers.net 198.97.190.53, 2001:500:1::53 US Army (Research Lab)
i.root-servers.net 192.36.148.17, 2001:7fe::53 Netnod
j.root-servers.net 192.58.128.30, 2001:503:c27::2:30 VeriSign, Inc.
k.root-servers.net 193.0.14.129, 2001:7fd::1 RIPE NCC
l.root-servers.net 199.7.83.42, 2001:500:9f::42 ICANN 81
m.root-servers.net 202.12.27.33, 2001:dc3::35 WIDE Project
La résolution DNS
 Objectif
 La résolution consiste à demander des ressources d’un certain type à un
serveur DNS, à partir d’un nom ou d’une adresse IP
 Elle est initiée par un résolveur
 La notion de resolver
 Unresolver est un logiciel qui formate une requête DNS dans un paquet
UDP, l'envoie à un serveur DNS , et décode la réponse
 Sous Unix, la configuration du resolver se fait dans les fichiers
 /etc/resolv.conf. permet de paramétrer les serveurs DNS à contacter
 /etc/host.conf. l’ordre de la résolution : order hosts, bind 82
La résolution DNS
 Les modes de résolution (1)
 Mode de résolution récursif
 Le serveur DNS adressé par le client renvoie soit une réponse complète à la
requête, soit une erreur. Au besoin, le client contacte un autre serveur
 Mode de résolution itératif
 Le serveur contacté renvoie une réponse complète ou une réponse partielle
 La réponse partielle permet alors au serveur initiateur de poursuive la résolution
 Mode de résolution basé sur le «Forwarding »
 Il consiste à transférer des requête reçues à un autre serveur
83
La résolution DNS
 Les mode de résolution (2)
Résolution récursive
et itérative
84
La résolution DNS
 La résolution inverse
 La résolution inverse consiste à trouver un nom de machine
(complètement qualifié) à partir de son adresse IP.
 Utilité
 Permettre à un serveur de s’assurer qu’un client qui se présente avec
une adresse IP appartient bien à un domaine autorisé et/ou est bien celui
qu’il prétend être (cas des serveurs de messagerie).
 Permettre à une station d’administration de réseau d’afficher les noms de
machine au lieu des adresses IP
85
La résolution DNS
 Mise en œuvre de la résolution inverse
 La résolution inverse utilise le domaine particulier in-addr.arpa (arpa =Address
and Routing Parameter Area)
 Les noms des sous-domaines sont des octets de l’adresse IP en ordre inverse
 Le domaine in-addr.arpa dispose de 256 sous domaines (0 à 255) au niveau 1
 Chacun des sous - domaines possède 256 sous domaines, et ainsi de suite
86
La résolution DNS
 Le domaine in-addr.arpa
87
Le protocole DNS
 Protocole DNS
 Le DNS est un protocole d’interrogation-réponse dont les messages ont le
même format dans les deux sens (requête et réponse)
 Le protocole DNS utilise le port 53
 Il est basé sur les protocoles UDP et TCP
 UDP pour les requête et réponse (taille <= 512 octets)
 TCP pour les transfert de fichier de zone
88
Protocole DNS
 Structure d’un message DNS (1)
Identificateur Drapeaux (flags)
Nombre de question Nombre de réponses RR Entête

12 octets
Nombre de RR d’Autorité Nombre de RR additionnels
Section Question
Section Réponse
Section Autorité
Section additionnelle
89
Protocole DNS
 Les éléments de l’entête
 Identificateur : identifiant de la requête (16 bits)
 Nombre de questions : Nombre d’entrée dans la section « Question » (16 bits)
 Nombre de RR de réponse: Nombre d’entrée dans la section «réponse (16 bits)
 Nombre de RR d’autorité : Nombre d’entrée dans la section autorité (16 bits)
 Nombre de RR additionnel: Nombre d’entrée dans la section additionnelle (16 bits)
 Flags (16 bits)
 Le corps du message DNS
 Section question: Type, la classe et le domaine sur lequel la requête a été exécutée.
 Section réponse: RR correspondant à la réponse de la requête
 Section autorité : RR correspondant aux serveurs d’autorité sur le domaine
 Section additionnelle : RR des informations supplémentaires 90
Protocole DNS
 Les flags
 Qr : 0 pour reqête et 1 pour réponse
 Opcode : type de requête (4 bits) :
 0 : Requête standard (Query),
 1 : Requête inverse (IQuery),
 2 : Statut du serveur (Status),
 3-15 : Réservé pour utilisation future
 Aa : Authoritative Answer (1 bit)
 Tc : Le message a été tronqué.
 Rd : demande ou non de récursivité en le mettant à 1 (1 bit).
 Ra : La récursivité est autorisée (1 bit).
91
Protocole DNS
 Les flags
 Rcode : Type de réponse (4 bits) :
 0: Pas d’erreur,
 1: Erreur de format dans la requête,
 2: Problème sur serveur,
 3: Le nom n’existe pas,
 4: Non implémenté,
 5: Refus, 6
 -15: Réservés.
92
Les acteurs du DNS
 Registre (registry)
 c’est une fonction administrative d’une zone qui permet l’enregistrement des
noms de domaine au sein de cette zone
 Les registres sont responsables de chaque TLD
 Ils peuvent déléguer la responsabilité des sous domaines à d’autres
organisations qui peuvent elles-mêmes déléguer, etc.
 Registrant (propriétaire du nom)
 Organisation individuelle au nom de laquelle un nom de domaine est
enregistré dans une zone par le registr
93
Les acteurs du DNS
 Registraire ou bureau d’enregistrement (registrar)
 Fournisseur de service qui agit comme intermédiaire entre registrant et
registres.
 Tous les enregistrements ne nécessitent pas un registraire
 Les hébergeurs de domaine

 Un hébergeur de domaine est un organisme qui dispose de serveurs de
domaine ayant autorité sur les domaines qu’il héberge
 Toute requête au sujet d’une ressource d’enregistrement du domaine
hébergé reçoit une réponse des serveurs DNS de l’hébergeur
 Exemple: OVH, LWS, hostingers etc.
94
95
Configuration du DNS
1 – mm
96
Les fichiers de zone
86400
 Qu’est ce qu’un fichier de zone

 C’est un simple fichier texte qui sert de base de données du serveur DNS.
 Il contient les informations relatives à une zone ou plusieurs zones gérées
par le serveur DNS.
 Structure générale d’un fichier de zone
 Un fichier de zone contient deux types de déclarations:
 Les directives spécifiques
 Elles donnent des indications générales au serveur
 Elles sont facultatives
 Les enregistrements de ressources (Resource Records = RR)

 Les ressources désignent les ressources sollicitées par les clients DNS 97
86400
 Les directives spécifiques

 $TTL: définit un TTL par défaut
$TTL 86400
 $ORIGIN: définit le domaine par défaut

$ORIGIN inphb.ci.
 $INCLUDE: inclut un fichier

$INCLUDE /etc/bind9/zone2.txt
98
 Les enregistrements de ressource (1)
 Format d’un enregistrement de resource
[nom] [TTL] «classe» <type> <données>
 nom
 Nom de l’objet référencé: nom de machine, nom de domaine, alias, etc.,
 Nom relatif au domaine par défaut qui le complète implicitement à moins que le
nom inclut le domaine root « » .
 S’il est vide, le nom de la ressource précédente est considérée
 TTL: Durée de vie dans le cache du client demandeur
 classe: classe de réseau (Ex. IN pour Ressource Internet)
 type: Type de la ressource (SOA, A, NS, MX, CNAME, PTR, etc.) 99
 données: la ressource
 Les enregistrements de ressources
 Format d’un RR dans un message DNS
Nom Type Classe TTL Longueur Donnée
En‐tête du RR
Codage du type Codage classe

A 01 IN (Internet) 01
NS 02 CS (Class Csnet) 02
CNAME 05 Ch (Chaos) 03
SOA 06 Hs (Hsiod) 04
PTR 12 100
MX 15
 Exemples d’enregistrement de ressource
inphb.ci. 86400 IN NS 213.136.80.2
nom TTL Classe Type ressource
www 86400 IN CNAME Samba.inphb.ci.
101
Les types d’enregistrements de ressource
 Le type SOA (Start of Authority)
 Il indique le début de la description du fichier de zone
@|«nom‐domaine » IN SOA «nom‐serveur‐primaire » «email‐

administrateur» (
•«numéro‐série selon un format défini par l’administrateur»
•«Périodicité de consultation par le serveur secondaire»
•«Périodicité de relance de la consultation»
•«délai pour l’abandon des relances »
•«TTL‐Durée de vie pour une réponse négative» )
102
 Le type SOA (Start of Authority) (2)
inphb.ci. IN SOA iroko.inphb.ci. admin.iroko.inphb.ci.(
17120501 ; Numéro de série au format AAMMJJVV)
43200 ; Consultation du serveur toutes les 12 heures
3600 ; réessayer toutes les heures
3600000 ; Abandonner les réessaies après 1000heures
2419200 ; TTL de réponse négative d’un mois )
 Autres unité du temps

 H(heure): 2H
 D(jour): 10D
 W(semaine) : 1W 103
 M(mois): 4M
 Le type NS (Name server)
 Il identifie les serveurs faisant autorité sur la zone
 Il indique où trouver les informations d’une zone donnée
«domaine» [TTL] IN NS «nom_serveur»
inphb.ci. IN NS iroko.inphb.ci.
 Type A (Address)
 Il établit la correspondance entre un nom de machine et une adresse IP
« nom‐machine » [TTL] IN A « adresse‐IP»

iroko.inphb.ci. IN A 213.136.80.2 104
 Type CNAME
 Il fournit un surnom/alias à un nom
« alias » [TTL] IN CNAME « nom‐original»
www IN CNAME samba
 Le type MX (mail Exchangeer)

 Ilidentifie le serveur de messagerie à qui le courrier reçu pour le domaine
indiqué doit être transmis pour livraison dans la boite Email de l’utilisateur
 Plusieurs serveurs de messagerie avec priorité peuvent être indiqués .
«domaine» [TTL] IN MX «priorité»
«nom‐serveur‐email»
105
inphb.ci. IN MX 10 baobab.inphb.ci.
 Le type PTR
 Permet de réaliser la résolution inverse, c’est-à-dire de trouver le nom d’une
machine à partir de son adresse IP.
«adresse IP» [TTL] IN PTR «nom‐machine»
4 IN PTR baobab.inphb.ci.
106
 Exemple de contenu du fichier de zone pour résolution normale
$ORIGIN inphb.ci.
$TTL 86400
@ IN SOA iroko.inphb.ci. admin.iroko.inphb.ci. (
11090901
28800
14400
604800
86400 )
IN NS iroko.inphb.ci.
iroko IN A 213.136.80.2
samba IN A 213.136.80.3
baobab IN A 213.136.80.4
www IN CNAME samba
mail IN CNAME baobab 107
inphb.ci. IN MX 10 baobab
 Exemple de contenu du fichier de zone pour résolution inverse
$TTL 86400
80.136.213.in‐addr.arpa. IN SOA iroko.inphb.ci. admin.iroko.inphb.ci.(
11090901
28800
14400
604800
86400 )
2 IN PTR iroko.inphb.ci.
3 IN PTR samba.inphb.ci.
4 IN PTR baobab.inphb.ci.
108
109
Introduction
 Les serveurs logiciels DNS
 Bind (libre et supporté par BSD, Linux) – plus de caractérisés
 PowerDNS (Libre, BSD, Linux, Mac OS)
 NSD (Libre, BSD, Linux, Mac OS)
 Microsoft DNS (propriétaire)
 Simple DNS plus (Commercial, Windows)
 Posadis (BSD, Linux, MacOS, Windows)
 etc.
110
Introduction
 Serveur Bind 9 (Berkeley Internet Name Daemon / Domain)
 La première version a été créée dans les années 1980 à l’Université de
Berkeley
 BIND est actuellement développé par l’Internet Systems Consortium (ISC),
organisme californien à but non lucratif
 Plus de 70% des serveurs DNS installés dans le monde utilisent BIND
 La version 9 ajoute notamment DNSSEC, une extension pour la sécurité
DNS.
111
Introduction
 Les fichiers de configuration de BIND (1)
 Installation du logiciel Bind9 (Ubuntu 18 et plus)
apt update (éventuellement)
apt install bind9
 Les différents éléments installés

 Le logiciel serveur DNS (daemon) est : /etc/init.d/named.d
 Les principaux fichiers de configuration se trouvent dans le répertoire /etc/bind
 named.conf
 named.conf.local
 named.conf.options
 Named.default‐zones
 Etc.
112
Les fichiers de configurations du serveur
 Les fichiers pré-renseignés
 zones.rfc
 C’est le fichier de déclarations des zones pour la résolution inverse pour les réseau
privés (10.0.0.0, 172.16.0.0 à 172.31.0.0, 192.168.0.0 à 192.168.255.0)
 Le fichier de zone pour ces zones est : db.empty
 named.conf.default‐zones
 C’est le fichier de déclaration des zone root, localhost pour la résolution normale, et
pour la résolution inverse pour les réseau 127.0.0.0, 0.0.0.0, 255.255.255.255
 Les fichiers de zone sont respectivement /usr/share/dns/root.hints,
/etc/bind/db.local, /etc/bind/db.127, /etc/bind/db.127, /etc/bind/db.0, /etc/bind/db.255
113
 Le fichier principal de configuration: named.conf
 Ilcontient les paramètres de configuration du serveur, paramètres contenus
dans des déclarations
 Types de déclaration
 Les listes de contrôle d’accès
 Formulation d’autorisation ou d’interdiction de certaines actions
 Les inclusions
 L’instruction «include » permet d’inclure un fichier dans un autre
 Les options
 Définit les options générales de configuration du serveur
 Les déclarations de zone
 Indique principalement pour une zone donnée (pour résolution normale ou inverse)
114 le
fichier de zone associé
 Les options générale de configuration (1)
 Syntaxe
options {
option1;
option2;
......
};
 options directory
directory "répertoire de travail du serveur";
directory "/var/cache/bind"; 115
 Option listen‐on
 Elle spécifie l’interface réseau sur laquelle « bind9» écoute les requêtes.
 Par défaut, toutes les interfaces sont écoutées.
Listen‐on {adresses IP;}; listen‐on { 213.136.80.2;};
 Option forwarders
 Elle spécifie une liste d’adresses IP correspondant aux serveurs forwarders
forwarders {Liste adresses séparées par «;» };
forwarders {213.136.96.2;213.136.96.37;}; 116
 Option forward first | only
 Contrôle le comportement de la retransmission des requêtes lorsque l’option
forwarders est utilisée.
 forward first
 les serveurs forwarders spécifiés doivent être interrogés avant que le serveur ne tente de
résoudre la résolution lui-même
 forward only
 Même si la requête vers les forwarders échouent le serveur ne doit pas tenter de faire l la
résolution lui-même/
forward first | only
117
 Exemple 1
options {
directory "/var/cache/bind";
};
 Exemple 2
options {
directory "/var/cache/bind";
forwarders {
213.136.96.2;213.136.96.37;};
listen‐on { 172.30.30.1;};
};
118
 Les déclarations de zone
 Elles permettent de décrire des attributs relatifs à une zone donnée (zone
pour la résolution normale ou zone pour la résolution inverse)
 Syntaxe
zone "nom‐de‐la‐zone" {
attribut1;
attribut2;
...
};
zone "inphb.ci" {
notify no;
type master; 119
file "/etc/bind/inphb.ci.normal.db"; };
 Attributs des déclarations de zone (1)
 type master | slave | hint
 Il précise le type de la zone (zone maitre ou zone secondaire ou zone racine)
 master ;
 Indique que le serveur courant fait autorité sur la zone en question.
 slave ;
 Indique que le serveur courant est un serveur secondaire
 L’attributs masters doit être utilisée pour indiquer l’adresse du serveur primaire
 hint ;
 Indique qu’il s’agit de la zone racine
120
 Attributs des déclarations de zone (2)
 notify yes | no;
 Il détermine si le serveur primaire doit notifier les serveurs esclaves en cas de mise
à jour
 file «nom‐fichier»
 Il indique le nom du fichier de zone (bases de données de la zone)
 masters {adresses‐ip‐serveur‐primaire; }
 attributs nécessaire uniquement pour les serveurs secondaires
121
 Exemple de déclaration de zone
 Cas d’un serveur primaire
zone "inphb.ci" {
type master;
file "/etc/bind/inphb.ci.normal.db";
};
zone "10.30.172.in‐addr.arpa" {
type master;
file "/etc/bind/inphb.ci.inverse.db";
};
122
 Exemple de déclaration de zone
 Cas d’un serveur secondaire
zone “inphb.ci" {
type slave;
masters {213.136.80.2;};
file "inphb.ci.normal.slave.db"; };
zone “80.136.213.in‐addr.arpa" {
type slave;
masters {213.136.80.2;};
file "inphb.ci.normal.slave.inverse.db"; }; 123
 Résumé du contenu du fichier de configuration named.conf
 Il contient les déclarations suivantes
 Définitions des options
 Déclaration de zones
 Les déclarations des options sont définies dans le fichiers
/etc/bind/named.conf.options
 Les déclarations de zone sont définis dans le fichier
/etc/bind/named.local
 Le fichier /etc/bind/named.conf est un regroupement des 3 fichiers
include "/etc/bind/named.conf.options"
include "/etc/bind/named.conf.local" 124
include "/etc/bind/named.conf.default‐zones"
Configuration du serveur Bind
 Vérification de la syntaxe des fichiers de configuration
 Vérification du fichier named.conf
 En considérant être dans le même répertoire que named.conf
named‐checkconf [named.conf]
 Vérification des fichiers de zone

 En considérant être dans le même répertoire que les fichiers de zone
named‐checkzone «nom‐domaine» «nom‐fichier‐zone»
named‐checkzone inphb.ci /etc/bind/inphb.ci.normal.db
named‐checkzone 125
80.136.213.in‐addr.arpa /etc/bind/inphb.ci.inverse.db
Configuration du serveur Bind
 Atelier 1 (1)
 Environnement
 1 réseaux par groupe parmi: 172.30.10.0/24; 172.30.20.0/24; 172.30.30.0/24;
172.30.40.0/24; 172.30.50.0/24; 172.30.60.0/24; 172.30.70.0/24; etc….
 Le même domaine pour tout le groupe: stic.ci
 Nom administrateur DNS: nom d’un membre du groupe
Serveur Mail
Serveur DNS
Serveur Web
126
Configuration de base du serveur Bind
 Atelier 1 (2)
Nous souhaitons mettre place un serveur DNS pour le réseau indiqué
Travail à faire
1. Ecrire les déclarations de zone pour la résolution normale et pour la résolution inverse
2. Ecrire les deux fichiers de zone des deux zones indiquées au 1.
3. Créer les deux fichiers de zone dans le répertoire /etc/bind. Ils devront avoir des noms
expressifs. Ils peuvent être créés à partir des fichiers échantillons disponibles dans le
répertoire /etc/bind (ex db.empty, db.local). Utiliser la touche tabulation pour la séparation
des champs d’un enregistrement de ressource.
4. Renseigner les fichiers contenus dans le fichier named.conf
a) /etc/named.conf.options. Seule l’option directory sera déclarée
b) /etc/named.local. Ce fichier contiendra les déclarations des zones personnelles
pour la résolution normales et pour la résolution inverse
127
5. Tester la syntaxe des différents fichiers de configuration créés
Test du serveur DNS
 Configuration du client DNS (resolver)
 Sous Linux la configuration du resolver se fait dans le fichier: /etc/resolv.conf
 Les options du fichier /etc/resolv.conf
 domain «nom de domaine»
 Définit le nom du domaine par défaut.
 search «domaine1» «domaine2» «domaine3» «domaine n»

 Définit une liste de domaine par défaut potentiel
 NameServer <adresse IP>

 Identifie les serveurs de nom auxquels le resolver adresse les requêtes.
 Maximum 3 serveurs de nom
domain inphb.ci
128
nameserver 213.136.80.2
Test du serveur DNS
 Démarrage du serveur « bind9 »
/etc/init.d/bind9 start | stop | restart | reload | status
ou
Service bind9 start | stop | restart | reload | status
129
Test du serveur DNS
 Les utilitaires de test de fonctionnement du serveur DNS
 Ces utilitaires permettent d’interroger un serveur DNS
 Les requêtes envoyées au serveur peuvent concerner tout type de ressource
 A
 PTR,
 CNAME,
 MX
 ANY
 etc.
 Exemples d’utilitaires
 nslookup
 hosts
 dig 130
Test du serveur DNS
 nslookup (1)
 Utilisation en session non interactive
nslookup [‐option] [nom‐domaine] [nom‐hôte|@IP‐hôte]
 Quelques options
 [no]debug: Afficher les informations de débogage (infos détaillées sur les échanges)
 type=typeRR: définit le type de la requête (A, ANY, CNAME, MX, NX, PTR, SOA,etc.)
 all: Affiche les valeurs courantes de set
 [no]recurse : demande une résolution récursive
 domain=nomDomain : Spécifie le domaine par défaut
131
Test du serveur DNS
 nslookup (2)
 Utilisation en session non interactive
nslookup [‐option] [nom‐domaine] [nom‐hôte|@IP‐hôte]
 Obtention de tous les RR du domaine aviso.ci

a) nslookup –type=ANY aviso.ci
b) nslookup ‐type=ANY aviso.ci 213.136.96.2
 Obtention des RR de type MX du domaine aviso.ci

a) nslookup –type=MX aviso.ci
b) nslookup ‐type=MX aviso.ci 213.136.96.2
 Obtention du nom de la machine 213.136.96.2 132
nslookup ‐debug 213.136.96.2
Test du serveur DNS
 nslookup (3)
 Utilisation en session interactive
#nslookup
>commande
 Les principales commandes sont

 domaine|nom‐machine|@IP: Affiche les informations au sujet de l’entité
 server nomServeur: définit le serveur DNS d’interrogation par défaut
 set options
 Les options sont les mêmes que pour la session non interactive
 Exit: sort de la session interactive 133
Test du serveur DNS
 nslookup (3)
 Session interactive
#nslookup
>set type = ANY
>inphb.ci
>set type=MX
>inphb.ci
>set type=PTR
>213.136.80.2
134
Test du serveur DNS
 dig (domain internet gropher) (1)
 Syntaxe
dig [@serveur] [nom] [type] [options]
 Serveur
 L’adresse IP ou le nom du serveur à interroger.
 S’il est omis, c’est le serveur par défaut dans /etc/resolv.conf qui est interrogé.
 Nom
 Le nom de l’enregistrement à rechercher
 Type
 Le type de la requête: ANY, A, MX, NS, SOA, etc. 135
 Par défaut c’est le type A qui est utilisé
Test du serveur DNS
 dig (2)
 Exemple
dig iroko.inphb.ci A
dig @213.136.80.2 inphb.ci MX
dig inphb.ci ANY
dig –x 213.136.80.2
dig @8.8.8.8 –x 213.136.96.7 +short
dig @8.8.8.8 –x 213.136.96.7 +noshort
136
Test du serveur DNS
 dig (3)
 Quelques options
 ‐f nomFichier
 Permet d'opérer en mode batch en lisant une liste de recherche à traiter dans le fichier
spécifié
 ‐x addresse
 Indique une requête inverse
 Formule la requête pour le type PTR. Pour l’utilisation du type explicite PTR, il faut écrire
la requête avec le nom complet qui inclut le domaine in‐addr.arpa
 ‐q nom
 Définis le nom de la requête. utile pour distinguer le nom des autres arguments.
137
Test du serveur DNS
 dig (4)
 Quelques options de recherche
 +[no]short
 affiche ou non une réponse courte
 +[no]qr
 Affiche ou non la requête quand elle est envoyée.
 +[no]question
 Affiche ou non la section question d'une requête quand une réponse est retournée
 +[no]answer
 Affiche ou non la section réponse
 +[no]authority
 Affiche la section authority
138
Test du serveur DNS
 dig (5)
 Interprétation des résultats
 STATUS
 NOERROR: 0 ou plus d’ER est retourné
 NXDOMAIN: domaine inexistant
 SERVFAIL: le serveur cache ne peut pas localiser la réponse
 FLAGS
 AA: réponse de serveurs autoritaires (pas de serveur cache)
 QR: Query/Response ( 1 = Réponse)
 RD: Récursion Desired (récursion désirée)
 RA: Récursion Available (récursion disponible)
139
Test du serveur DNS
 dig (6)
 Interprétation des résultats
 Answer section:
 Réponse à la reqûete
 Chaque enregistrement a un temps de vie (TTL)
 Indique le temps de stockage dans le cache
 Authority section
 Indique les serveurs de nom qui sont autoritaires pour ce domaine (faisant autorité)
 Additional section
 Plus d’enregistrements (ER)
 Il s’agit typiquement des adresses IP pour les serveurs de nom autoritaire
 Total query time
 From 140
 Indique le serveur qui a donné la réponse
Test du serveur DNS
 Host
 Cet utilitaire permet une interrogation assez simple d’un serveur DNS
 Syntaxe simplifiée
host [‐options] [‐c class] [‐t type] hostname [server]
 La commande host permet d’avoir la syntaxe complète, ainsi que les options
 Informations du domaine inphb.ci
host inphb.ci
host –v inphb.ci
host 151.80.22.49
host –t ns inphb.ci
host –t SOA inphb.ci 141
Test du serveur DNS
 Atelier 2
Après avoir lancé le serveur DNS, utiliser les outils outils pour un test de bon
fonctionnement:
nslookup
dig
host
142
Test du serveur DNS
 Atelier 3: Configuration du serveur secondaire
L’objectif de ce atelier est de mettre en œuvre le serveur secondaire du
serveur primaire réalisé dans l’atelier 1
1. Faire les configurations nécessaires. Les fichiers de zone normale et de
zone inverse déclarés dans «named.conf.local» ne doivent pas être
créés. Ils seront créés automatiquement par named (bind) dès son
démarrage dans son répertoire de travail (/var/cache/bind)
2. Lancer le serveur bind et vérifier si les fichiers de zone ont été créés
automatiquement sur le serveur secondaire dans le répertoire de travail de
named (/var/cache/bind)
143
La délégation de zone
 Principe (1)
 Une zone parente peut déléguer une partie de l'arbre des noms de domaine
à une autre entité.
 Il s’agit de déléguer la gestion des sous-domaine d’un domaine donné à
d’autres serveurs DNS
 Elle est réalisée par l’ajout d’un ensemble d'enregistrements NS pointant
vers les serveurs des zones filles
144
Délégation de zone
 Principe (2)
Par exemple nous souhaitons déléguer la

gestion des sous domaines larit.inphb.ci et
larima.inphb.ci aux serveurs DNS respectifs
yakro.larima.inph.ci et abidjan.larit.inphb.ci
Lorsqu’on voudra atteindre une machine de

ces domaine, la résolution commencera par le
domaine inphb.ci enregistré auprès de NIC-CI
pour aboutir au domaine ciblé.
145
 Principe de mise en œuvre de la délégation
 Mettre en place le ou les serveurs DNS des domaines délégués
 larit.inph.ci
 larima.inphb.ci
 Configurer la délégation sur le serveur DNS du domaine principal (inphb.ci)
 La délégation consiste à ajouter les lignes ci-dessous dans le fichier de zone du
domaine inphb.ci
larima.inphb.ci. IN NS yakro.larima.inphb.ci.
larit.inphb.ci. IN NS abidjan.larit.inphb.ci.
146
 Configuration de la délégation de zone
$ORIGIN inphb.ci.
$TTL 86400
@ IN SOA iroko.inphb.ci. admin.iroko.inphb.ci. (
11090901
28800
14400
604800
86400 )
larima.inphb.ci. IN NS yakro.larima.inphb.ci.
larit.inphb.ci. IN NS abidjan.larit.inphb.ci.
yakro.larima.inphb.ci. IN A 213.136.100.25
abidjan.larit.inphb.ci. IN A 193.220.020.040 147
 Atelier 4
Ce atelier vise à mettre en œuvre pratique l’exemple de délégation décrit
précédemment.
1) Configurer le serveur DNS du domaine larima.inphb.ci sur le deuxième
serveur, celui qui était utilisé comme serveur secondaire
2) S’assurer que le serveur configuré fonctionne correctement
3) Configurer la délégation comme indiqué précédemment sur le premier
serveur (serveur primaire)
4) Après avoir lancé le service Bind sur le serveur primaire, vérifier à l’aide de
la commande « ping » que les résolutions des machines figurant dans le
fichier de zone du serveur délégué fonctionnent bien 148
Compléments
 Déclaration des ACL (Access Control List) (1)
 Elle définit des «motifs» pour représenter un hôte ou un groupe d’hôtes
qu’il faudra par la suite autoriser ou refuser à faire une action sur le
serveur de nom
 Définition d’un ACL
acl «nom‐acl » {
motif‐de correspondance;
};
149
Compléments
 Déclaration des ACL (2)
 Exemples
acl hotesConfiants {
172.30.30.1;
172.30.30.254;
};
acl reseauAutorises {
192.168.1.0/24;
192.168.2.0/24;
Localhost;
};
150
Compléments
 Déclaration des ACL (3)
 Quelques motifs prédéfinis
 any: correspond à toutes les adresses IP.
 none: ne correspond à aucune adresse IP.
 localhost: correspond à toute adresse IP utilisée par le système interne. Il
s’agit des réseau 127.0.0.0
 localnets: correspond aux adresses IP des réseaux auxquels le serveur
local est connecté
151
Compléments
 Application des ACL dans les options et attributs (1)
 allow‐query {nom‐acl;}
 Spécifie les hôtes autorisés à interroger le serveur de noms. Par défaut tous les
hôtes sont autorisés.
 allow‐recursion {nom‐acl ;}
 semblable à allow-query, mais s’applique à des demandes récursives.
 Par défaut, tous les hôtes sont autorisés à faire des demandes récursives.
 blackhole {nom‐acl ;}
 spécifie les hôtes qui ne sont pas autorisés à interroger le serveur de nom.
 allow‐transfer {nom‐acl;}
 spécifie les serveurs esclaves qui sont autorisés à demander un transfert
d’informations de zone. Par défaut tous les serveurs sont autorisés 152
Compléments
 Exemple
acl blackList {
acl whiteList {
10.0.2.0/24;
10.0.1.0/24;
192.168.0.0/24;
};
};
options {
blackhole { blackList; };
allow‐query { whiteList; };
allow‐recursion {whiteList; };
} 153
Compléments
 Les règles ACL peuvent sont appliquées selon deux stratégies
 Application au serveur DNS dans l’ensemble
 Elles sont déclarées dans le fichier des options
 Application selon les zones
 Elles sont déclarées comme attribut dans la déclaration de zone
154
Services Réseaux
Serveur Web: Apache

A l’issue de cette session de formation, les 1. Principe de configuration du serveur web

apprenants seront capables de: Apache
2. Configuration des sites web virtuel
- Expliquer le fonctionnement d’un serveur
3. Protection d’un répertoire de publication de
web
pages web
- Configurer le serveur web Apache 4. Accès à un site web par authentification
Introduction
 Notion de site Web et de serveur Web
 Un site web est un ensemble de pages Web relatif à une entité morale ou
physique.
 Un serveur web est un logiciel qui héberge un ou plusieurs sites Web et qui
permet à des logiciels clients (Internet Explorer, Netscape Navigator, etc.)
d’accéder à ces sites à l’aide du protocole HTTP.
 Plusieurs serveurs web existent sur le marché
 Serveur web Apache
 Serveur web nginx
 Serveur web Microsoft IIS
 Serveur web Google Web Server (GWS)
156
 Lighttpd
Introduction
 Serveur web Microsoft IIS
 Le serveur IIS (Microsoft Internet Information Service) est propriétaire et
exploité exclusivement sur les plateformes Windows Server.
 Serveur web lighttpd
 Serveur web libre dédié aux sites à forte charge
 Serveur web Google Web Server (GWS)

 Serveur web créé et utilisé par Google pour le développement de son
réseau de sites.
157
Introduction
 Serveur web nginx (Nginx Plus version commerciale)
 Développé par l’unique développeur russe, nginx est à la fois un serveur
web, un proxy web et un proxy mail disponible sous licence libre.
 C’est un serveur très performant en raison de sa faible utilisation de
ressource et sa grande vitesse d’exécution.
 Serveur web Apache
 Serveur web disponible en licence libre sous de nombreuses plateformes
dont Linux, Windows, MAC OS X.
 Serveur web le plus utilisé sur Internet, avec plus de 50% des parts de
marché des serveurs web. 158
Introduction
 Serveur Apache
 Avantages
 Logiciel Open-source et gratuit
 Logiciel fiable et stable.
 Contient des modules d’interprétation de plusieurs langages : Perl, PHP, Python,
Ruby
 Mise à jour régulière, correctifs de sécurité réguliers.
 Flexible grâce à sa structure basée sur des modules.
 Facile à configurer
 Grande communauté et support disponible en cas de problème.
 Inconvénients :
 Problèmes de performances sur les sites web avec un énorme trafic.
 Trop d’options de configuration peuvent mener à la vulnérabilité de la sécurité.159
L’hébergement virtuel
 Principe (1)
 Apache est basé sur la technique de l’hébergement virtuel, une technique
permettant d’héberger plusieurs sites Web sur un seul même serveur Web.
 Chacun des sites web est désignés par son URL. Par exemple:
 www.inphb.ci, www.esatic.ci, www.goservices.net , etc.
 Les requêtes en direction du serveur web pour les sites sont différencié en
se basant sur l’un des 3 éléments suivants :
 Le nom de domaine
 L’adresse IP
 Le port
160
 Principe (2)
 Plusieurs techniques sont utilisées pour réaliser les hébergements virtuels.
 Les hôtes virtuels par adresse IP
 Chaque hôte virtuel dispose de sa propre adresse IP et répond aux requêtes à
destination de cette adresse
 Les hôtes virtuels par nom
 Le champ «host » dans l’entête du protocole HTTP permet d’identifier l’hôte virtuel
concerné par la requête donnée.
 Les hôtes virtuels par port
 Chaque hôte virtuel dispose d’un port d’écoute qui lui est propre et répond alors aux
requêtes à destination de ce port. Cette solution est rarement utilisée
161
 Déclaration d’un hôte virtuel (1)
<VirtualHost «@IP‐cible »[:«port‐écoute»]>
« liste de paramètres de l’hôte virtuel»
</VirtualHost>
 L’adresse cible ou le port d’écoute du serveur virtuel peut être:

 * pour désigner toute adresse ou tout port
 Une adresse ou un port spécifique
 Une liste d’adresses ou de ports séparés par des espaces.
162
 Les paramètres de base d’un hôte virtuel
 DocumentRoot
 Répertoire d’hébergement du site web de l’hôte virtuel
DocumentRoot /var/www/html
 DirectoryIndex
 Liste de pages d’accueil par défaut. Le parcours se fait dans l’ordre de déclaration. La
première page existante dans le répertoire de DocumentRoot est la page par défaut
DirectoryIndex index.html index.phb default.htm
 ServerName
 C’est le nom du serveur web virtuel. Ce paramètre est nécessaire dans le cas de
l’hébergement par nom 163
ServerName larit.ci
 Exemples
<VirtualHost 192.168.8.8>
DirectoryIndex index.html accueil.php
DocumentRoot /var/www/html/site1
</VirtualHost>
<VirtualHost 172.30.30.1 172.30.30.2>
</VirtualHost>
164
 Exemple
<VirtualHost *:80>
</VirtualHost>
<VirtualHost *:*>
</VirtualHost> 165
Les fichiers de configuration de Apache
 Organisation des fichiers de configuration (1)
 Fichiers de base de la configuration
 /etc/apache2/apache2.conf
 Fichier principal de configuration d’Apache.
 Il contient les paramètres généraux et communs à tous les hôtes virtuels et inclut
plusieurs autres fichiers
 /etc/apache2/ports.conf
 Fichier contenant les ports d’écoute d’Apache 2.
port 80
Listen 172.30.30.1:80
166
 Fichiers de configuration des modules
 /etc/apache2/mods-available
 contient les fichiers de configuration des modules disponibles
 /etc/apache2/mods-enable
 contient les fichiers de configuration des modules activés
 Il s’agit de liens symboliques des fichiers du répertoire mods-available
 Fichiers de configuration des hôtes virtuels

 /etc/apache2/sites-available
 contient les fichiers de configuration des hôtes virtuels disponibles
 /etc/apache2/ sites-enabled
 contient les fichiers de configuration des hôtes virtuels activés 167
 Fichiers des configurations standards
 /etc/apache2/conf-available
 /etc/apache2/conf-enable
168
Activation des composants de Apache
 Principe
 La modification du comportement du serveur web apache est basée sur
l’activation ou la désactivation de composants dont les :
 Hôtes virtuels
 Modules
 Configuration
 Chaque élément à activer est disponible dans un répertoire prédéfini de
composants disponibles (available).
 L’activation du composant consiste à créer un lien symbolique du composant
disponible dans le répertoire des composants activés (enabled)
169
 Activation des composants de Apache (2)
 Exemples
 Un hôte virtuel sera créé dans le répertoire /etc/apache2/sites-available et activé en
créant un lien symbolique de cet hôte dans /etc/apache2/sites-enabled
 Il en est de même pour d’autres composants
 Modules php
 Module d’authentification
 Module de définition des pages d’accueil possibles (dir.conf)
170
 Création de lien symbolique (1)
 Pour un composant à activer, il s’agit de créer un lien symbolique du fichier
correspondant présent dans le répertoire «/etc/apache2/xxxx-available»
(xxx=mods,conf, sites)
 Le lien symbolique est créé dans le répertoire «/etc/apache2/xxxx-enabled»
 Exemple
ln –s /etc/apache2/mods‐available/dir.conf
/etc/apache2/mods‐enabled/dir.conf
 La désactivation consiste à supprimer le ficher de lien symbolique

171
 Il existe des scripts de création et de suppression de lien pour chaque type
de fichier:
 Pour les modules
a2enmod «nom‐lien‐symbolique»
a2dismod «nom‐lien‐symbolique»
 Pour les sites
a2ensite «nom‐lien‐symbolique»
a2dissite «nom‐lien‐symbolique»
 Pour les configuration
a2enconf «nom‐lien‐symbolique»
a2disconf «nom‐lien‐symbolique» 172
Exemples
a2enmod userdir
a2dismod userdir
a2ensite site1
a2dissite site1
173
Service web: Apache
 Atelier 1 (1)
Cet atelier a pour objectif d’installer le serveur Apache et d’examiner sa
configuration par défaut
1) Installer le serveur apache 2
apt‐get install apache2
2) Vérifier l’existence du répertoire de configuration /etc/apache2
3) Vérifier l’existence de la déclaration d’un hôte virtuel
4) Quel est le nom du fichier de l’hôte virtuel par défaut ?
5) Décrire les éléments de l’hôte virtuel
6) Quel est le port d’écoute par défaut du serveur apache ?
7) Quel est le répertoire de publication du site virtuel par défaut ?
174
8) Donner la liste des pages d’accueil par défaut ?
Service web: Apache
 Atelier 1 (2)
1) Installer le navigateur en ligne de commande lynx
apt‐get install lynx
2) Connecter au site web web local à l’aide du navigateur lynx

lynx @IP‐machine
175
Service web: Apache
 Atelier 2
L’objectif de cet atelier est d’apporter des modification à hôte virtuel par
défaut fourni par Apache 2, puis de créer un hôte virtuel personnalisé.
1) On suppose que le répertoire de publication du site par défaut est
/var/www/siteDefaut et la page d’accueil par défaut est nommé accueil.html.
Apporter les modification nécessaires à l’hôte virtuel par défaut
2) Relancer apache 2, puis accéder au site web local : lynx @IP‐machine
3) Créer et activer un hôte virtuel personnalisé nommé 000‐amonsite.conf avec
quelques paramètres de base et l’activer. Le répertoire de publication du site web est
/var/www/monsite et au moins un fichier html nommé page1.html qui en est la
page d’accueil par défaut
4) Relancer apache 2, puis accéder au site web local: lynx @IP‐machine 176
Hébergement de plusieurs sites web
 Utilisation de la technique d’hôte virtuel par adresse (1)
 Il y aura autant de définition d’hôte virtuels qu’il y a de site web (avec des
domaines différents)
 Chaque hôte virtuel sera rattaché à une adresse IP
 Les dernières version de Ubuntu via la commande ip ou l’outil netplan
permettent d’associer plusieurs adresses IP à une même interface.
 Le paramètre globale Listen sera mis à 80 pour toutes les adresses IP
 Exemple
 Le premier hôte virtuel sera accessible par l’adresse 172.30.30.100
 Le second hôte virtuel sera accessible par l’adresse 172.30.30.200
177
 Exemple: cas de l’hébergement des sites webs:
www.inphb. ci ( résolu par le DNS en 172.30.20.100 )
www.miage.ci (résolu par le DNS en 172.30.20.200)
DocumentRoot /var/www/site1
</VirtualHost>
</VirtualHost>
178
Travaux Pratiques
 Atelier 4 (1)
Dans cet atelier, on se propose d’héberger deux sites web sur le même serveur
physique en utilisant l’hébergement virtuel basé sur les adresses IP. Les deux sites
seront bien sûr accédés par des URL différents. Les deux sites virtuels seront désignés
par: www.inphb.ci et www.miage.ci.
Les deux domaines inphb.ci et www.miage.ci sont hébergés sur la même
machine, avec des fichiers différents (fichier de zone normal, fichier /etc/named.conf).
Le fichier de zone inverse est commun aux deux domaines, puisqu’il s’agit du même
réseau. Les domaines sont supportés par des adresses ip différents. Tout fonctionne
comme s’il y avait deux serveurs différents. On suppose que l’adresse IP du serveur du
domaine inphb.ci est 172.30.20.100 et celle du domaine miage.ci est
172.30.20.200 179
Travaux Pratiques
 Atelier 7 (2)
Pour ce atelier les deux installations de Linux seront utilisées. L’un servant de
serveur et l’autre servant de client.
Travail à faire
1) Configurer tous les fichiers DNS des deux domaines
2) Après tous les tests, lancer le serveur Bind9
3) Le répertoire d’hébergement du site de l’inphb est «/var/www/inphb» et celui du
site de miage est «/var/www/miage»
4) Configurer et activer les deux sites virtuels par adresse
5) Lancer le serveur apache et faire les tests de bon fonctionnement
180
 Utilisation de la technique d’hôte virtuel par port
 Le même principe de l’hébergement par adresse est utilisé
 Chaque site est désigné par un numéro de port qui lui est propre
 Exemple
<VirtualHost *:80>
DocumentRoot /var/www/vhost1
</VirtualHost>
<VirtualHost *:8080>
</VirtualHost>
181
Travaux Pratiques
 Atelier 5
Les données de l’atelier précédent (atelier 4) restent les mêmes. Chaque site web
sera accédé en utilisant un numéro de port différent. Par exemple
http://www.inphb.ci:8080 pour l’accès au site de l’INPHB
http://www.miage.ci:3000 pour l’accès au site de MIAGE
Travail à faire
1) Configurer les ports d’accès dans le fichier ports.conf
Listen 8080
Listen 3000
2) Configurer les fichier d’hôte virtuels correspondant
3) Activer les hôtes virtuels
4) Lancer apache et tester 182
 Utilisation de la technique d’hôte virtuel par nom (1)
 Il suffit de définir autant d’hôte virtuel qu’il y a de site web
 L’option host de l’entête du protocole http permet de cibler le bon hôte
virtuel en fonction de la valeur du paramètre ServerName
 Exemple <VirtualHost 172.30.20.20>
ServerName www.inphb.ci
</VirtualHost>
<VirtualHost 172.30.20.20 >
ServerName www.larima.inphb.ci
</VirtualHost> 183
Travaux Pratiques
 Atelier 7 (1)
Dans cet atelier, on se propose d’héberger deux sites web sur le même
serveur physique en utilisant l’hébergement virtuel basé sur les noms
(hébergement nommé). Les deux sites seront bien sûr accédés par des URL
différents. Par exemple: www.larima.inphb.ci pour le premier site et
www.larit.inphb.ci pour le deuxième site.
Les deux domaines ont donc besoin d’être hébergés sur la même machine,
avec des fichiers différents (fichier de zone normal, fichier de zone inverse,
fichier /etc/named.conf). Néanmoins les domaines sont supportés par des
adresses ip différents. La command «ip » permet d’affecter plusieurs adresses
à une seule interface réseau. 184
Travaux Pratiques
 Atelier 7 (2)
Travail à faire
3) Le répertoire d’hébergement du premier site est «/var/www/larima» et celui
du deuxième site est «/var/www/larit»
4) Configurer les deux sites virtuels et faire les tests de bon fonctionnement
185
Les conteneurs de systèmes de fichiers
 Les conteneurs de section de configuration (2)
 Ce sont des balises qui décrivent la portée des paramètres de configuration.
 Elles s’appliquent généralement aux répertoires et aux fichiers
 Les principaux containeurs de système de fichiers sont:
 <Directory> </Directory>
 <Files> </Files>
186
Les conteneurs de systèmes de fichier
 Le conteneur «Directory» (1)
 Ilcontient des paramètres qui s’appliquent au répertoire spécifié, ainsi aussi
à tous ses sous répertoires et fichiers qu’il contient
 Syntaxe de déclaration de la balise «Directory»
<Directory «Nom_Repertoire» >
«liste des paramètres »
</Directory>
<Directory ~ "expression régulière" >
«liste des paramètres »
</Directory> 187
 Le conteneur «Directory» (2)
 Une expression régulière est un motif pour désigner soit un nom de
répertoire ou un ensemble de nom de répertoires ayant des éléments en
commun
 Exemple
<Directory /var/www/monsite>
.......
</Directory>
<Directory ~ "^Sup">
« liste de directives »
</Directory> 188
 Les paramètres du conteneur «Directory» (1)
 Exemple
<Directory /var/www/monsite> Les fichiers et répertoires

Options ‐Indexes ne seront pas listés au cas
</Directory> où la page par défaut est
absente
<Directory />
Options +Indexes
AllowOverride None
Require all denied
</Directory>
189
 Atelier 3
Ce atelier a pour objectif la manipulation du conteneur <Directory>
1) Créer un répertoire «save» dans le répertoire de publication
« /var/www/html/monsite» créé précédemment
2) Déplacer tous les fichiers de ce répertoire dans le répertoire save
3) Créer le conteneur suivant <Directory> ….</Directory> dans le fichier
/etc/apache2,conf.conf, avec Options +Indexes,
4) Lancer apache 2, puis lynx @IP
5) mettre Options à –Indexes puis tester à nouveau
190
 Le containeur de fichier « Files »
 Les paramètres contenus dans une balise <Files> s'appliquent à tout fichier
correspondant nom spécifié
<Files "*.html">
Require all denied
</Files>
 Lorsque la balise «Files» est incluses dans une balise Directory, ses
paramètres s’appliquent aux fichiers contenus dans l’arborescence du
répertoire spécifié <Directory "/var/www/html">
<Files "*.html">
Require all denied
</Files> 191
</Directory>
 Le container «LIMIT»
 Ellepermet de restreindre la portée des contrôles d'accès à certaines
méthodes HTTP: GET, POST, PUT, CONNECT, TRACE, etc.
 Syntaxe de déclaration
<Limit «methode1» «methode2»>
« liste de balise »
</Limit>
<Limit POST GET>
Require valid‐user
</Limit>
192
 Imbrications des containers
<Directory ……… >
<Files …… >
<LIMIT ….. >
</LIMIT>
</Files>
</Directory>
193
Sécurité des fichiers et répertoires
 Principe
 Apache permet de sécuriser un répertoire en autorisant ou en refusant
l'accès à ce répertoire ou à des fichiers de ce répertoire.
 Il existe deux types de protection des répertoires ou fichiers
 Protection en fonction du domaine, du nom d’hôtes ou de l’adresse IP
 Elle permet de définir des droits d'accès en fonction des domaines ou adresses ou noms
de machines.
 Protection par authentification de l’utilisateur
 Elle permet de protéger l’accès à un répertoire par nom d'utilisateur et mot de passe.
194
 Le contrôle d’accès par la clause «Require»
 La clause «require» permet de contrôler l’accès à une ressource, en
l’occurrence un répertoire ou un fichier
 Elle permet d’accorder ou de refuser l’accès à la ressource
 Elle peut être utilisé dans un container (Directory, Files, LIMIT, etc.)
 Exemple
Require no ip 192.168.205
Require host stic.ci stic1.stic.ci
</Directory>
195
 Syntaxe de la clause Require (1)
 Require all granted | denied
 Accès ou interdiction à une ressource sans condition
 Require [not] method «http‐method [http‐method]…»
 Accès autorisé ou non aux méthodes http indiquées
 Require [not] user «id‐utilisateur [id‐utilisateur] ...»
 Accès ou non aux utilisateur spécifiés (dans la base des utilisateurs).
 Require [not] group «nom groupe [nom groupe] ...»

 contrôle d’accès pour les utilisateurs des groupes spécifiés
196
 Syntaxe de la clause Require (2)
 Require [not] ip « @IP [@IP] ... »
 contrôle d’accès pour les adresses IP indiquées .
 Require [not] host «nom‐hote|nom‐domain [nom‐hote|domain] ...»
 contrôle d’accès pour les noms d’hôte ou noms de domaines indiqués
 Require [not] valid‐user
 contrôle d’accès pour les utilisateurs valides (présents dans une base de données)
197
 La clause Require (3)
 Exemple
Require ip 20.1.2.3
Require ip 192.168.1.104 192.168.1.205
Require ip 172.30
Require ip 10 172.20 192.168.2
Require ip 10.1.0.0/255.255.0.0
Require ip 10.1.0.0/16
Require host inphb.ci

Require host .ci larima.inphb.ci
198
 Le containeur «RequireAny »
 Il permet de regrouper un ensemble de règle de correspondance «require»
 Dès que les données d’une requête satisfont l’une des règles, l’accès à la
ressource est accordé.
 La directive « RequireNone»
 Pour que l’accès à la ressource soit accordé, les données de la requête ne
doivent satisfaire aucune des règles
 La directive « RequireAll»
 Pour que l’accès à la ressource soit accordée, les données de la requête
doivent satisfaire l’ensemble des règles 199
 Exemple d’utilisation des règles «Require»
<RequireAll>
<RequireAny>
Require user admin
. <RequireAll>
Require group mis A quelle condition l’accès
Require host stic.ci
</RequireAll>
est accordé au client ?
</RequireAny>
<RequireNone>
Require group labo
Require host larima.ci
</RequireNone>
</RequireAll> 200
</Directory
 Atelier 4
L’objectif de cet atelier est de tester la clause de contrôle d’accès «Require »
1) On considère les données de l’atelier 4. Il faut interdire l’accès au site web
à l’une de machines clientes.
<RequireAll>
require all granded
require not ip 172.30.30.2
</RequireAll>
</Directory>
2) Tester 201
Authentification de l’accès à un répertoire
 Principe (1)
 Apache permet d’authentifier l’accès à un répertoire, de telle sorte que cet
accès soit autorisé à une ou plusieurs personnes (groupes de personnes).
 Chaque personne devra donc s’authentifier à l’aide d’un compte utilisateur
 Une balise <Directory> doit être définie avec certains paramètres
 Les paramètres nécessaires de la balise
 AuthName
 définit le texte affiché dans le menu d’authentification d’un utilisateur
 AuthType
 définit le mode d'authentification et d'encryptage (basic, digest (MD5), etc.)
202
 Principe (2)
 Les paramètres nécessaires de la balise
 AuthUserFile
 Définit le fichier des comptes utilisateurs crée à l’aide de la commande « htpasswd »
d’Apache. Si le chemin d’accès ne commence pas par un « / », il est relatif au répertoire
de publication du site.
 require valid‐user
 accorde l'accès au client qui fournira l'un des noms figurant dans le fichier des comptes.
 <Limit méthodes HTTP>

 permet d’indiquer les mthodes http autorisées ou non.
203
 Exemple
AuthName "Authentification"
AuthType basic
AuthUserFile /etc/apache2/Utilisateurs
<Limit GET POST>
require valid‐user
</Limit>
</Directory>
204
 Création de la base de données des utilisateurs
htpasswd [options] fichier_utilisateur nom_utilisateur
L’option –c est utilisé pour créer le fichier des utilisateurs au cas où ce fichier n’existe
pas déjà.
htpasswd –c /etc/apache2/Utilisateurs gaoussou
htpasswd /etc/apache2/Utilisateurs kone
205
Protection des répertoires avec .htaccess
 Atelier 5
Dans cet atelier, nous souhaitons protéger notre site web par le
mécanisme d’authentification. Tout utilisateur désirant accéder au site web
devra préalablement être authentifié à partir de son «login» et son «mot de
passe».
Reprendre la configuration de l’atelier 4 et mettre en œuvre la protection par
authentification. Le répertoire de publication est: /var/www/monsite
206
 Gestion des fichiers .htaccess (1)
 Elle consiste à mettre les paramètres de protection dans un fichier nommé
«.htaccess» et placer ce fichier dans le répertoire à protéger
 La configuration s'applique au répertoire parent et à tous les sous-
répertoires, qui n'ont pas de tel fichier à l'intérieur.
 Les fichiers «.htaccess » peuvent être modifiés à tout moment même
lorsque le serveur est en cours d'exécution
 L’option «allowOverride» dans la balise «Directory» du répertoire à
protéger gère la prise en charge des fichiers «.htaccess» dans ce
répertoire et ses sous répertoires.
207
 Option allowOverride
 All : les fichiers .htaccess sont prise en compte
 None : les fichiers .htaccess sont ignorés
 Exemple de contenu du fichier .htaccess

AuthName "Authentification"
AuthType basic
AuthUserFile /etc/apache2/Utilisateurs
<Limit GET POST>
require valid‐user
</Limit> 208
 Le nom du fichier de protection peut être modifié dans le fichier principal de
configuration de apache
AccessFileName «nouveau nom»
AccessFileName ht.access
209
 Atelier 6
Ce atelier reprend le même type de protection que l’atelier précédent
(Atelier 5) avec l’utilisation des fichiers fichiers « .htaccess »
210
 Il y aura autant de définition d’hôte virtuels qu’il y a de site web (avec des
domaines différents)
 Chaque hôte virtuel sera rattaché à une adresse IP
 Les dernières version de Ubuntu via la commande ip ou l’outil netplan
permettent d’associer plusieurs adresses IP à une même interface.
 Le paramètre globale Listen sera mis à 80 pour toutes les adresses IP
 Exemple
 Le premier hôte virtuel sera accessible par l’adresse 172.30.30.100
 Le second hôte virtuel sera accessible par l’adresse 172.30.30.200
211
 Exemple: cas de l’hébergement des sites webs:
www.larit.inphb. ci ( résolu par le DNS en 172.30.30.100 )
www.larima.inphb.ci (résolu par le DNS en 172.30.30.200)
</VirtualHost>
</VirtualHost>
212
 Utilisation de la technique d’hôte virtuel par port
 Le même principe de l’hébergement par adresse est utilisé
 Les différents ports sont spécifiés par le paramètre Listen
Listen 80
Listen 8080
<VirtualHost *:80>
</VirtualHost>
<VirtualHost *:8080>
</VirtualHost>
213
 Utilisation de la technique d’hôte virtuel par nom (1)
 Il suffit de définir autant d’hôte virtuel qu’il y a de site web
 L’option host de l’entête du protocole http permet de cibler le bon hôte
virtuel en fonction de la valeur du paramètre ServerName
 Exemple <VirtualHost 172.30.30.30>
ServerName www.larit.inphb.ci
</VirtualHost>
<VirtualHost 172.30.30.30 >
ServerName www.larima.inphb.ci
</VirtualHost> 214
Travaux Pratiques
 Atelier 7 (1)
Dans cet atelier, on se propose d’héberger deux sites web sur le même
serveur physique en utilisant l’hébergement virtuel basé sur les noms
(hébergement nommé). Les deux sites seront bien sûr accédés par des URL
différents. Par exemple: www.larima.inphb.ci pour le premier site et
www.larit.inphb.ci pour le deuxième site.
Les deux domaines ont donc besoin d’être hébergés sur la même machine,
avec des fichiers différents (fichier de zone normal, fichier de zone inverse,
fichier /etc/named.conf). Néanmoins les domaines sont supportés par des
adresses ip différents. La command «ip » permet d’affecter plusieurs adresses
à une seule interface réseau. 215
Travaux Pratiques
 Atelier 7 (2)
Travail à faire
3) Le répertoire d’hébergement du premier site est «/var/www/larima» et celui
du deuxième site est «/var/www/larit»
4) Configurer les deux sites virtuels et faire les tests de bon fonctionnement
216
Services Réseaux
Le service mandataire web (proxy)

1. Fonctions d’un serveur proxy

A la fin de cette session de formation les 2. Principe de fonctionnement d’un serveur
participants de: proxy
3. Principaux paramètres de configuration d’un
- Explique le fonctionnement d’un serveur serveur proxy
proxy
4. Authentification des utilisateurs
- Configurer le serveur proxy squid
5. Affichage personnalisé des messages
d’erreur
Introduction
 Qu’est ce qu’un serveur mandataire web ?
 Un serveur mandataire relaie les requêtes des clients vers le serveur Web
 Il accepte, analyse et fait suivre les requêtes des clients à leur destination (vers le
serveur Web de destination).
 Selon la stratégie en vigueur les requêtes peuvent être acceptées, refusées ou
logués et même modifiées avant d'être envoyées à leur destination.
 Serveur mandataire en en tant que cache
 Ilstocke les objets récemment téléchargés du Web dans une mémoire cache, ce qui
permet une éventuelle réutilisation plus tard.
 Les requêtes ultérieures concernant ces objets sont alors directement soumises au
cache local, ce qui évite l’accès au serveur d'origine (distant).
218
Introduction
 Serveur mandataire en tant que « proxy » inverse
 Un proxy inverse permet à un utilisateur externe au réseau local (par
exemple à partir d’internet) d’accéder à des serveurs internes.
 Cette fonctionnalité permet de sécuriser des serveurs locaux dans la
mesure où ils ne sont accessibles directement.
 Protocoles supportés
 FTP
 HTTP
 SSL
 Etc. 219
Introduction
 Avantages d’un serveur proxy
 Filtrer les requêtes web et assurer l’anonymat
 Améliorer les performances d’accès Web.
 Économiser la bande passante de la connexion Internet
 Réduire le temps de chargement des pages statiques
 Protéger les hôtes du réseau privé en agissant comme mandataire pour leur
trafic Web
 Collecter des statistiques sur l'utilisation du Web (journalisation = log)
 Etc.
220
Introduction
 Les niveaux de cache d’un navigateur
 Cache local
 Tout navigateur dispose d’un cache local dont la taille peut être réglée par
l’utilisateur
 A tout moment l’utilisateur peut vider le contenu de ce cache
 Cache externe
 Le navigateur peut avoir recours à un cache externe tel que le cache squid
221
Introduction
 Schémas de déploiement d’un serveur cache
Serveur
Proxy
Serveur
Proxy
222
Introduction
 Proxy squid
 Squid est un serveur mandataire entièrement libre et très performant.
 Il est très utilisé dans les entreprises et administrations
 Un serveur Squid est à la fois
 Un serveur cache
 Un serveur mandataire (proxy)
 Un serveur mandataire inverse (reverse proxy)
223
Configuration de Squid
 Les principaux paramètres (1)
 Le fichier de configuration de squid sous Linux Ubuntu est
/etc/squid3/squid.conf. Il contient les paramètres suivants:
 http_port «[adresse‐ip |nomServeur:] port d’ecoute»

 Port d'écoute de Squid. La valeur par défaut est : 3128.
http_port 8080
 cache_mem «taille»
 Modification de la langue d’affichage des erreursvaleur en Mo de la mémoire cache
cache_mem 1000
 error_directory «fichier des erreurs ».
error_directory /usr/share/squid3/errors/French 224
 Les principaux paramètres (1)
 cache_dir «type-fichier» «répertoire-cache» «taille-cache» «nb1-partition» «nb2-partition»
 Espace disque pour la mémoire cache. Le type de système de fichier est ufs (unix file
system) ou aufs(asynchronous ufs) ou diskd (disk daemon).
 Les deux derniers paramètres précisent le nombre de sous répertoire dans les deux
premiers niveaux de l’arborescence.
cache_dir ufs /squid/cache 2000 16 256
 dns_nameservers «@IP-serveur1» «@IP-serveur2» …………

 Par défaut le nom indiqué dans /etc/resolv.conf est utilisé par squid.
 Dans le cas contraire c’est cette valeur qui est utilisée.
dns_nameservers 172.30.30.4
225
 Atelier 1
L’objectif de cet atelier est de permettre à l’apprenant de se familiariser avec le proxy Squid.
1) Installer le serveur squid (Linux ubuntu 18 et plus)
apt install squid3
2) Démarrer le serveur proxy squid (service squid restart | stop | start | status)
3) Un navigateur web sur le système d’exploitation hôte sera renseigné avec les paramètres du
serveur Proxy (adresse et port d’écoute)
a) A l’aide de «ping» s’assurer que le serveur Proxy est joignable par le système hôte
b) En gardant les paramètres de configuration par défaut, configurer les paramètres proxy
du navigateur, puis essayer d’accéder à un site web local de la machine où se trouve le
serveur Proxy, par sont adresse. Commenter
c) Essayer d’accéder à un site web quelconque. Commenter
226
NB: La configuration des navigateurs sont présentée dans les pages qui suivent.
Configuration de client Squid
 Configuration dans un navigateur: cas de Firefox Mozilla (1)
 Dans les options du navigateur
227
Configuration de client Squid
 Configuration dans un navigateur: cas de Firefox Mozilla (2)
 Dans les options du navigateur
228
Liste de contrôle d’accès
 Les ACLs ( Access Control List)
 Les ACL sont des outils de sécurité qui permettent le filtrage des paquets
transitant par le proxy sur la base de critères
 Ils permettent d’autoriser au d’interdire le transit de données via un proxy
 Principaux éléments de filtrage des ACL

 Adresse ip
 Protocole
 Numéro de port
 Domaine
 Expression contenu dans l’url de la page
 Période de temps donnée. 229
 Etc.
 Déclaration d’un l’ACL
 La déclaration d’un ACL consiste à définir un motif de correspondance
nommé (le nom de l’acl )
acl «nom‐acl» «type» «Listes de paramètres»
Exemple
acl monreseau src 172.30.30.0/24
L’acl nommé monreseau correspond à tout paquet devant

transiter par le proxy et dont l’adresse source est
dans le réseau 172.30.30.0/24 230
 Les types d’ACL
 Le type de l’acl désigne le type de correspondance dans le motif
 Les principaux types ACL
 src
 dest,
 srcdomain,
 dstdomain,
 time,
 url_regex,
 urpath_regex,
 port,
 proto
231
 Déclaration des ACL basés sur les adresses IP
acl «nom» src|dst «liste d’adresse IP» | fichier
acl reseauInterdit dst 192.168.8.0/24
acl hotes src 172.30.30.1 172.30.30.2 172.30.30.3
acl hotes src 172.30.30.100‐172.30.30.150/255.255.255.0
Acl acl sitesInterdits dst "/etc/squid/sitesInterdits.txt"
192.168.3.100
192.168.3.5-192.168.3.10 232
192.168.3.6
 Déclaration des ACL basés sur les ports et les protocoles
acl «nom» port liste de ports»
acl mesports port 80 70 21‐50
acl <nom> proto «liste de protocoles»

acl mesprtos proto http ftp
acl <nom> methode «méthodes http»

acl statutreq method GET POST
233
 Déclaration des ACL basés sur le temps
acl <nom_acl> time [MTWHFAS] [h1 :m1–h2 :m2]
M : lundi F : Vendredi
T : mardi A : Samedi
W : Mercredi S : Dimanche
H : Jeudi D : tous les jours de la semaine M‐F
Exemple
acl matin time MTWHF 08:00‐12:00
acl soir time MTWHF 14:00‐18:00 234
Liste de Contrôle d’accès
 Déclaration des ACL basés sur les expressions régulières
 Une expression régulière est un motif qui décrit un ensemble de chaine de
caractères
Expression signification
. Un caractère quelconque
? Représente un seul caractère
* 0 ou plusieurs occurrences du caractère précédent
\x Opte la signification spéciale de x
^x Ligne commençant par x
x$ Ligne se terminant par x
[^x] Tout caractère sauf x
Intervalle de caractère
[a‐z ] 235
[xXyYzZ] Classe de caractère
 Déclaration des ACL basés sur les expressions régulières
acl «nom» url_regex «expression régulières»
acl «nom» url_regex «fichier des expressions régulières»
url_regex : URL entier

urlpath_regex : partie droite de l’URL sans le protocole et le nom du serveur
dstdom_regex : nom du serveur
acl sites1 url_regex ^http://www.lari
acl sites2 url_regex larima
acl sites3 url_regex "/etc/squid/liste.txt"
acl pages1 urlpath_regex ‐i \.gif$
 La procédure permettant l’examen des expressions est sensible à236

la
casse. Pour la rendre insensible on ajoute l’option –i
 Définition de règle de filtrage ACL (1)
 Forme simple
«type_Traffic» allow|deny «nom_acl»
 Il peut s’agir d’un trafic http, https, ftp, été.
 Exemple pour le trafic http (dont il est question)

acl monreseau src 172.30.30.0/24
http_access allow monreseau
http_access deny matin 237
 Types de trafic
 http_access: filtrage des requêtes http
 http_reply_access: filtrage des réponses aux requêtes
 cache: filtrage des réponses qui peuvent être mise dans un cache.
 snmp_access: filtrages des clients snmp.
 log Access: filtrage des requêtes aux logs
 etc,
238
 Forme complexe
«type_Traffic» allow|deny [!]«critere_acl1» [!]«critere_acl2»……
acl hote1 src 172.16.0.1

acl soir time MTWHF 14:00‐18:00
http_access allow hote1 matin
http_access allow hote2 soir
 Tous les critères d'une règle sont associés par un «ET» . 239
 Principe de vérification des règles ACL
A la réception d’un paquet, le serveur PROXY, consulte son entête afin de
vérifier les paramètres de l’acl (adresse, numéro de port, etc. )
 Les règles d’un même type de trafic sont vérifiées dans l'ordre où elles ont
été écrites et se terminent dès qu'une correspondance a été établie.
 Il est recommandé de terminer les règles par une règle d’interdiction
explicite
 En sécurité, tout ce qui n’est pas autorisé explicitement est interdit
http_access allow poste1 matin
http_access allow poste2 soir
http_access deny all 240
 Atelier 2
Ce atelier est consacré à la modification de certains fichiers de configuration et à manipulation
des Listes de contrôle d’accès.
1) Examiner le répertoire /var/spool/squid. Commenter
2) Modifier le disque cache à 2Go (paramètre cache_dir). Relancer squid et réexaminer le
répertoire précédent. Commenter
3) Modifier le port d’écoute à 8080 (paramètre http_port), l’adresse DNS à 8.8.8.8 (paramètre
dns_nameservers)
4) Ecrire une déclaration acl qui désigne les paquets dont l’adresse source (ou de destination) est le
réseau auquel appartient le serveur Proxy
5) Ecrire une règle d’autorisation correspondante et tester ( à partir du navigateur du système hôte)
6) Ecrire une déclaration acl qui désigne tout paquet transitant par le serveur Proxy
7) Ecrire une règle d’autorisation correspondante et tester ( à partir du navigateur du système 241
hôte
Authentification des utilisateurs
 Principe
 Les acl permettent de faire appel à l’authentification pour autoriser l’accès
au web en passant par le serveur proxy
 Cette possibilité est mis en œuvre par des modules extérieurs
d’authentification, parmi lesquels :
 ncsa_auth: utilise un fichier d’utilisateurs local
 smb_auth: permet d’utiliser un contrôleur de domaine Windows NT
 ldap_auth: permet d'authentifier les utilisateurs depuis un annuaire LDAP
 Dans la suite, la base de données locale sera utilisée
242
 Création et remplissage de la base de données locale
touch /etc/squid/utilisateurs
htpasswd ‐b «fichier utilisateur» «nom de l'utilisateur» «mot de passe»
Htpasswd –b /etc/squid/utilisateurs moussa pass123
 Test du module externe d’authentification

«nom_module» «fichier des utilisateur» «login» «password»
#/usr/lib/squid/basic_ncsa_auth /etc/squid3/Utilisateurs moussa pass123
OK
243
 Création de l’acl des utilisateurs passant par le proxy
acl «nomAcl» proxy_auth REQUIRED
acl authentification proxy_auth REQUIRED
 Configuration de l’authentification dans «squid.conf»
auth_param basic program «module authentification» «fichier utilisateurs»
auth_param basic program /usr/lib/squid3/basic_ncsa_auth
/etc/squid/utilisateurs
244
 Atelier 3
Ce atelier est consacré au test de l’authentification des utilisateurs
1) Sur le serveur Proxy:
a) Créer la base de données locale des utilisateurs avec au moins deux
utilisateurs
b) Tester le module externe d’authentification:
#/usr/lib/squid/basic_ncsa_auth
c) Configurer l’authentification des utilisateurs
d) Relancer le serveur
2) Tester l’accès à n’importe quel site web par authentification
245
Journalisation du serveur Proxy
 La journalisation (1)
 Les transactions http vias le serveur proxy sont journalisés dans un fichier
/var/log/access.log.
 Ce fichier donne des informations sur la façon dont les requêtes http ont
été traitées au niveau du serveur Proxy Squid.
 Les informations sont généralement des
 Codes de statut renvoyés par le serveur Proxy
 Des codes liés aux requêtes HTTP
 La journalisation permet de
 Faire des statistiques sur les accès aux sites web
 Dépanner un serveur proxy
246
 La journalisation (2)
 Plusieurs outils d’analyse des log squid existent
 sarg
 Awstats
 Sawmil
 Scalaire
 Calamaris
 modlogan
247
 Principaux codes de statut proxy
Indicateurs Signification
TCP_HIT / UDP_HIT Une copie valide de l'objet demandé a été trouvée dans le cache.
TCP_MISS / UDP_MISS L'objet demandé n'a pas été trouvé dans le cache.
L'objet demandé a été trouvé dans le cache mais est considéré comme
TCP_ REFRESH_HIT périmé. La requête IMS a renvoyé un code « 304-Not Modified » et la
ressource mise en cache est retournée.
L'objet demandé a été trouvé dans le cache mais est considéré comme
TCP_REFRESH_FAIL_HIT périmé. La requête IMS a échoué et le contenu périmé a été délivré au
client.
L'objet demandé a été trouvé dans le cache mais est considéré
TCP_REFRESH_MISS
comme périmé. La requête IMS a retourné le nouvel objet.
TCP_DENIED/UDP_DENIED L'accès a été refusé pour cette demande
UDP_INVALID Une requête invalide a été reçue.
248
 Codes HTTP courants
code Description
200 OK Requête traitée avec succès.
Requête traitée avec succès avec création
204 Created
d'un document.
301 Moved Permanently Document déplacé de façon permanente.
302 Moved Temporarily Document déplacé de façon temporaire.
Document non modifié depuis la dernière
304 Not Modified
requête.
400 Bad request La syntaxe de la requête est erronée.
Une authentification est nécessaire pour
401 Unauthorized
accéder à la ressource.
303 Forbidden Accès interdit
249
 Principaux codes de statut proxy
Indicateurs Signification
TCP_IMS_MISS Le client demande une mise à jour. Squid forward la requête
Le client demande une mise à jour, et l'objet est dans le cache et
TCP_IMS_HIT
est récent. Squid ne forward pas la requête
Le client envoie une requête avec une demande de ne pas utiliser
TCP_CLIENT_REFRESH
le cache. Squid forward la requête.
250
 Atelier 3
Après consultation de site en passant par le serveur proxy, examiner le
fichier log de squid et commenter
251
La gestion du cache par le serveur Proxy
 Algorithme de la gestion du cache par le serveur proxy
 A la suite d’une requête http par un client, l’objet renvoyé par le serveur proxy
peut être l’objet conservé dans le cache ou l’objet provenant du serveur web
d’origine de l’objet
 Le choix de la localisation de l’objet retourné dépend de plusieurs directives:
 Options dans l’entête de la requête en direction du serveur proxy
 Options dans l’entête de la réponse du serveur d’origine de l’objet au serveur proxy
 Directives inscrites dans le fichier de configuration
 L’administrateur système peut agir sur la durée de conservation d’un objet
dans le cache
252
 Options de l’entête de requête
 If-Modified-Since (IMS)
 Cette option rend la réponse à la requête conditionnelle
 La réponse sera 200 si la ressource a été modifiée depuis la date indiquée
 La réponse sera 304, sans contenu si la ressource n’a pas été modifiée depuis
 Cache-Control: max-age
 Fournit l’âge maximum accepté pour que l’objet soit considéré comme valide (durée
à partir de la date de la requête)
 Cache-Control: max-stale
 Objet périmé accepté si cela ne dépasse pas la valeur fournie
 Cache-Control: no-cach
 Force le serveur proxy à recharger la page auprès du serveur d’origine. 253
 Options de l’entête de la réponse
 Expires
 Contient la date/heure après laquelle l’objet est considérée comme périmée.
 Age
 Indique le temps pendant lequel la ressource a été stockée dans un cache proxy.
 Cache-Control: max-age
 Indique la durée pendant laquelle la ressource doit être considérée comme valide
(durée à partir de la date de la réponse )
 Cache-Control: no-cache
254
 Les valeurs de durée de vie dans le cache
LM_AGE AGE
Dernière maj de l’objet Entrée de l’objet

sur le serveur d’origine dans le cache
 AGE
 Temps écoulée depuis l’entrée de la ressource dans le cache
 LM_AGE
 Temps écoulé entre la dernière modification de l’objet sur le serveur d’origine et son
entrée dans le cache
 LM_FACTOR
 255
apport AGE/LM_AGE. Plus il est grand, plus l’objet a des chances d’être périmée
 Les valeurs de durée de vie fixé dans le fichier de configuration
 MIN_AGE
 Durée pour laquelle un objet sans expiration explicite doit être conservé
 MAX_AGE
 Durée maximale dans le cache d’un objet sans expiration explicite
 LM_FACTOR
 Rapport entre AGE et LM_AGE. Plus il est grand, plus la ressource dans le cache a
des chances d’être périmée
 NB
 MAX_AGE envoyée par le client prévaut sur celui du fichier de configuration
 MIN_AGE est prioritaire à EXPIRES renvoyé par le serveur 256
 Algorithme de cache
 AGE > MAX_AGE
 La ressource en cache est déclarée comme périmée
 AGE <= MIN_AGE
 La ressource en cache est déclarée comme fraîche
 EXPIRE
 Lorsqu’elle est définie et dépassée, la ressource est périmée.
 Lorsqu’elle est définie, et non dépassée, la ressource est fraîche
 AGE compris entre MIN_AGE et MAX_AGE,
 La «fraicheur» de l’obtient est définie par le paramètre LM_FACTOR
 LM_FACTOR < PERCENT: La ressource est fraîche
257
Gestion du rafraichissement des ressources
 Définition des paramètre le fichier de configuration
 La directive refresh_pattern permet un contrôle beaucoup plus fin de
la validité des objets dans le cache
 Des options de cette directive vont permettre d’ignorer ou pas certains
valeurs des entêtes de requête ou de réponses vues précédemment
refresh_pattern [‐i] <url_regexp> MIN_AGE PERCENT MAX_AGE <options>
refresh_pattern ^ftp: 1440 20% 10080
refresh_pattern ^gopher: 1440 0% 1440
refresh_pattern . 0 20% 4320
258
[email protected]
258
 Les options de la directive refresh_pattern
 override-expire
 ignorer l’option Expire de l’entête de réponse du serveur web
 override-lastmod
 ignorer la date de dernière modification de l’entête de réponse du serveur web.
 ignore-reload
 ignorer le rechargement à partir du serveur d’origine.
 ignore-no-cache
 ignorer l’option no cache venant du serveur web
 ignore-auth
 Les objets d’authentification ne sont pas mis en cache. Cette option franchit la
259
limitation
 Les options de la directive refresh_pattern
 Exemple
refresh_pattern ‐i \.(iso|avi|wav|mp3|mp4|mpeg|swf|flv|x‐flv)$
43200 90% 432000 override‐expire ignore‐no‐cache
Ce reglage permet de conserver dans le cache les fichiers multimedia pendant

30 jours (432000 minutes)
260

Support Formation Intranet - Internet

Transféré par

Droits d'auteur :

Formats disponibles

Support Formation Intranet - Internet

Transféré par

Informations du document

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

Support Formation Intranet - Internet

Transféré par

Droits d'auteur :

Formats disponibles

Services Réseaux

Prof. GOORE BI Tra

A l’issue de cette formation les participants seront

Généralités sur Internet

Cette session de cours est une introduction aux

Configuration manuelle des interfaces réseau

A l’issue de cette session de formation, les 1. Principe de nommage des interfaces

 Suppression d’une adresse IP d’une interface

 Visualisation de l’état des interfaces réseaux

Objectifs spécifiques Contenu

A l’issue de cette session de formation, les 1. Principe de fonctionnement d’un service

 Principaux messages DHCP

DHCPDISCOVER 0.0.0.0 255.255.255.255 Requête pour paramètre

DHCPOFFER IP Serveur 255.255.255.255 Proposition d’offre

DHCPREQUEST 0.0.0.0 255.255.255.255 Acceptation d’une offre

DHCPACK IP Serveur 255.255.255.255 Accusé de réception

DHCPRELEASE IP client IP serveur Abandon des paramètres

 Installations du serveur (ubuntu)

 Les fichiers de configuration

 Fichier des bails attribués

subnet «ip réseau» netmask «masque»{

 Lancer le client dhcp

 Renouvellement de bail sous Windows

 Bail maximum: 2 jours

 Inconvénients de fichiers hosts

Domaine 1er Niveau net sn ci org org

Domaine 2ème Niveau inphb

 Les domaine de 2ème niveau (Secondary Level domain – TLD)

net sn ci org org

Chaque zone est gérée par un serveur sn 63.105.26.30

iroko samba.inphb.ci 210.130.130.1

Nombre de question Nombre de réponses RR Entête

 Les hébergeurs de domaine

 Qu’est ce qu’un fichier de zone

 Les enregistrements de ressources (Resource Records = RR)

 Les directives spécifiques

 $ORIGIN: définit le domaine par défaut

 $INCLUDE: inclut un fichier

Codage du type Codage classe

inphb.ci. 86400 IN NS 213.136.80.2

nom TTL Classe Type ressource

www 86400 IN CNAME Samba.inphb.ci.

@|«nom‐domaine » IN SOA «nom‐serveur‐primaire » «email‐

 Autres unité du temps

inphb.ci. IN NS iroko.inphb.ci.

« nom‐machine » [TTL] IN A « adresse‐IP»

 Le type MX (mail Exchangeer)

«adresse IP» [TTL] IN PTR «nom‐machine»

4 IN PTR baobab.inphb.ci.

 Les différents éléments installés

Listen‐on {adresses IP;}; listen‐on { 213.136.80.2;};

 Vérification des fichiers de zone

 search «domaine1» «domaine2» «domaine3» «domaine n»

 NameServer <adresse IP>

 Obtention de tous les RR du domaine aviso.ci

 Obtention des RR de type MX du domaine aviso.ci

 Les principales commandes sont

Par exemple nous souhaitons déléguer la

Lorsqu’on voudra atteindre une machine de

Serveur Web: Apache