Soutenance mémoire
L’architecture du réseau
On distingue généralement deux types de réseaux informatiques bien différents : les réseaux poste à poste (peer to peer/ égal à égal), et les réseaux organisés autour de serveurs (Client/Serveur). Un serveur est un « logiciel serveur » programmé pour offrir des services, un client c’est celui qui en demande un service, et il doit avoir le « logiciel client » adéquat. Dans une architecture d’égal à égal, il n’y a pas de serveur dédié. Chaque ordinateur dans un tel réseau est un peu serveur et un peu client. De nombreuses applications fonctionnent selon un environnement client/serveur, notamment le réseau local (LAN) et surtout l’Internet, dans lequel des machines clientes contactent un serveur, une machine généralement très puissante en terme de capacités d’entrée-sortie, qui leur fournit des services. Ces services sont des programmes fournissant des données telles que des pages web, des fichiers, du courrier électronique, et bien d’autres.
L’architecture 2-tiers
L’architecture à 2 niveaux caractérise les systèmes client/serveur dans laquelle le client demande une ressource et le serveur la lui fournit directement. Cela signifie que le serveur ne fait pas appel à une autre application pour fournir le service. C’est donc une architecture dans laquelle le serveur est polyvalent, vu sa capacité de fournir directement l’ensemble des ressources demandées par le client.
Le seul problème majeur avec cette architecture c’est que si le serveur doit faire de l’acquisition des données ou des recherches dans sa base de données, on imagine que dès qu’il rencontre un problème, les clients sont handicapés car ils ne peuvent plus avoir accès à l’information.
L’architecture 3-tiers
Dans une architecture à 3 niveaux, on distingue:
♦ le client: le demandeur de ressources
♦ le serveur d’application (appelé aussi Middleware): le serveur chargé de fournir la ressource mais faisant appel à un autre serveur
♦ le serveur secondaire (généralement un serveur de base de données) fournissant un service au premier serveur.
Le comportement du ou des clients du tiers 1 est identique à celui dans l’architecture 2-tiers. Mais au niveau du tiers 2, on trouve une application de type serveur et client spécialisée qui n’a pas accès directement aux données qu’elle va fournir au client du tiers 1. En tant que serveur, le Middleware reçoit des requêtes de manière classique. Ceci dit, afin d’élaborer le contenu de la réponse, la partie «client » du tiers 2 fait appel à un autre serveur (tiers 3). Aussitôt reçues les données du tiers 3, il compose une réponse qu’il envoie finalement au tiers N°1.
Cette architecture présente l’avantage majeure du point de vue performance, car les taches sont partagées (mais encore faut-il que ce soit une question de coût) mais aussi du point de vue sécurité, car « personne » d’autre que le middleware ne peut accéder directement au tiers 3.
Le modèle client/serveur web et le protocole http
Un serveur web est un logiciel permettant à des clients d’accéder à des pages web, c’est-à-dire en réalité des fichiers au format HTML à partir d’un navigateur web (ou browser) installé sur leurs ordinateurs. Le client est de ce fait celui qui demande les ressources via son navigateur web (par exemple Internet Explorer pour Microsoft ou Mozilla pour Linux) Un serveur web (par exemple Apache) est donc un logiciel capable d’interpréter les requêtes HTTP arrivant sur le port associé au protocole HTTP, par défaut le port 80, et de fournir une réponse avec ce même protocole.
Une page web est le contenu d’un site web (accessible via un serveur web) et est écrite dans le format de langage HTML, et qui met en pratique le principe du lien hypertexte.
Le protocole http
Le protocole HTTP est le protocole le plus utilisé sur Internet depuis 1990. Son but est dans un premier temps, de permettre un accès à des fichiers (essentiellement au format HTML) localisés grâce à une chaîne de caractères appelée URL entre un navigateur (le client) et un serveur Web, et puis dans un second de les télécharger (downloader) si besoin.
Fonctionnement interne du processus:
Le dialogue entre le client et le serveur web se compose de requêtes émises par le client et de réponses données par le serveur via le protocole HTTP.
♦ le navigateur effectue une requête HTTP
♦ le serveur traite la requête puis envoie une réponse HTTP .
Le déroulement d’une session HTTP ressemble à ceci:
La CONNEXION se fait, à travers une connexion TCP-IP, en mentionnant le nom du domaine ou son adresse IP, ainsi que le numéro de port donné dans l’adresse. Dans le cas où ce dernier n’est pas spécifié, le nombre 80 est mis par défaut. Puis le client envoie une REQUETE de document qui consiste en un ensemble de lignes écrites en caractères ASCII regroupant la précision sur le type du document demandé, la version du protocole utilisé et la commande pour demander le fichier. Les requêtes sont mises en forme par le navigateur, puis transmises au serveur. C’est après que le serveur envoie la REPONSE à la requête : une réponse HTTP est un ensemble de lignes envoyées par le serveur au navigateur comprenant le document demandé ou éventuellement un message d’erreur (404 par exemple). Après l’envoi du document, la connexion TCP-IP est coupée par le serveur quand tout le document a été transmis. C’est la DECONNEXION.
Traitement des requêtes côté serveur
Une requête venant du client peut concerner des informations stockées dans une base de données, ou bien d’autres qui correspondent à des extensions (.asp ou.php) : le serveur web envoie une demande de l’exécution du programme par un autre serveur (de base de données), en affiche par la suite les résultats pour les renvoyer au client. C’est pourquoi cet environnement se présente généralement sous la forme d’une architecture 3-tiers. Etant donné que les pages web « classiques » sont écrites en simple code HTML, il se peut que d’autres contiennent des scripts (tels que CGI ou ASP) intégrés au sein de la page Web en HTML à l’aide de balises spéciales, dans le but de les rendre plus dynamiques et interactives. Les scripts sont des programmes écrits pour interagir avec des bases de données. Mais leurs exécutions se font du côté du serveur qui se charge de l’affichage des données traitées.
Traitement des réponses côté client
Le client est le navigateur, mais un navigateur Web (browser) est un logiciel «client» (comme Internet Explorer pour Windows® ou Mozilla pour Linux) installé sur la machine de l’utilisateur pour pouvoir communiquer avec le logiciel «serveur» HTTP. Les navigateurs web doivent accepter les extensions (Plug-In) pour permettre d’étendre leurs capacités afin de pouvoir interpréter certains types de ressources comme le PDF par exemple, ou bien pour permettre d’exécuter les langages évolués comme JAVA ou Javascript. Et cette exécution se fait dans le navigateur du client.
|
Table des matières
Introduction
Chapitre 1 : Généralités sur le système client/serveur
1.1. L’architecture du réseau
a. L’architecture 2-tiers
b. L’architecture 3-tiers
1.2. Le modèle client/serveur web et le protocole http
a. Introduction
b. Le protocole http
b.1. Fonctionnement interne du processus
i. Traitement des requêtes coté serveur
ii. Traitement des réponses coté client
b.2. Le déroulement du processus HTTP avec un navigateur web
1.3. Le modèle client/serveur ftp et le protocole ftp
a. Introduction au protocole FTP
b. Le modèle FTP
c. Le déroulement du processus FTP en ligne de commande
c.1. Établissement d’une session
c.2. Authentification
c.3. Exécution de transfert
c.4. Ouverture et fermeture de session FTP
d. Le déroulement du processus FTP avec un navigateur
d.1. Établissement d’une session
d.2. Authentification
d.3. Exécution de transfert
e. Le déroulement du processus FTP avec un logiciel client FTP
Chapitre 2 : Le SSL (Secure Socket Layer)
2.1. Définition
2.2. Positionnement du protocole sur la couche
2.3. Service offert par SSL
a. Confidentialité
b. Intégrité
c. Authentification
2.4. Systèmes de sécurisation utilisés par SSL
a. Système de chiffrement asymétrique
b. Système de chiffrement symétrique
c. Système de signature cryptographique
d. Les certificats
d.1. Définition
d.2. Types de certificats
d.3. Type de certificat suivant la signature
i. Le certificat signé par le fournisseur de certification
ii. Le certificat autographe
d.4. Les utilisateurs de certificats SSL
2.5. Fonctionnement d’un protocole sécurisé
a. Authentification du serveur
b. Authentification du client
c. Chiffrement des données
2.6. Mode de fonctionnement de SSL
a. L’encodage dans SSL
b. La négociation dans SSL
b.1. Mécanisme
b.2. Authentification
Chapitre 3 : Mise en place du serveur Web et FTP sécurisé sous Linux
3.1. Mise en place du serveur Web Apache sécurisé
a. Présentation d’Apache
a.1. Apache
a.2. Pourquoi Apache est-il devenu un standard ?
a.3. Système requis
i. Logiciel
ii. Materiel
a.4. Installation et configuration d’Apache
i. Distribution de sources
ii. Distribution sous forme d’archive binaire
a.5. Protocoles
a.6. Arrêter et redémarrer Apache
a.7.Configuration de base du serveur web
a.8.Configuration avancée du serveur web
i. Les hôtes virtuels
ii. Protection d’une page
b. Mise en œuvre du serveur Web Apache sécurisé avec SSL
b.1. Les paquetages à installer
i. Apache
ii. Apache-SSL ou Mod_SSL
iii. OpenSSL
b.2.Génération de clés privées et de certificats SSL
b.3. Test
b.4. Comment savoir qu’un site Web utilise un certificat?
3.2. Mise en place du serveur FTP sécurisé
a. Présentation du serveur FTP (vsFTPd)
b. Installation
c. Configuration des utilisateurs
c.1. Configuration de l’utilisateur anonyme
c.2. Configuration des utilisateurs virtuels
c.3. Configuration de l’utilisateur local
d. Sécurisation du serveur avec SSL
d.1. Le pourquoi du SSL
d.2. Installation de l’utilitaire SSL
d.3. Génération du certificat SSL
d.4. Configuration du serveur pour SSL
e. Conséquences directes
f. Application
Conclusion
Annexe
