INSA 5 R.T.

Sujet dexamen
21 janvier 2011
Scurit des systmes informatiques
2
me
partie
Exercice 1 (3 points)
Le protocole HTTPS (HTTP sur SSL/TLS) est couramment utilis pour scuriser les
communications entre un serveur Web et un navigateur. Pour cela, une session HTTPS
s'appuie sur un certificat diffus par le serveur permettant d'effectuer une session
d'authentification initiale et ensuite un chiffrement du canal de communication dans lequel
transite l'change HTTP.
1. Lors de l'authentification, le protocole utilise une clef publique contenu dans un
certificat que le serveur dtient et diffuse au client l'tablissement de la connexion.
Quelles sont les protections offertes par cette utilisation d'un certificat serveur ?
2. Comment l'utilisateur du navigateur peut-il tre assur que cette clef publique
correspond bien l'organisme auquel il souhaite accder ?
3. Pourquoi de nombreux services Web, utilisant pourtant HTTPS, demandent-ils en plus
l'utilisateur de fournir un nom de compte et un mot de passe pour complter
l'ouverture de session ?
4. Il est possible d'utiliser un certificat client stock sur le navigateur pour l'change
HTTPS. Quel est l'effet de l'utilisation d'un certificat client sur la protection de
l'ensemble du service ?
5. Avec un certificat client, l'utilisateur doit quand mme parfois fournir une
passphrase : de quel mot de passe s'agit-il ?
6. Pensez-vous qu'il y ait une passphase utilisateur sur la partie prive du certificat
serveur ? Pourquoi ?
Corrig
1. Le protocole SSL avec un certificat serveur offre d'abord une authentification du
partenaire accd par une vrification que ce serveur dtient bien la clef prive
correspondant la clef publique diffuse. Ensuite, la communication est chiffre, on a
donc des garanties sur la confidentialit des changes ainsi que sur l'intgrit de la
communication pendant toute sa dure.
2. Le certificat n'inclut pas seulement la clef publique, mais galement une signature de
cette clef publique par un autre certificat. (Celui-ci pouvant galement tre un
certificat intermdiaire.) La racine de cette chane de certification doit tre un
certificat pr-install sur le navigateur (ou obtenu indpendamment en pralable la
communication). L'utilisateur peut alors tre sr que le certificat diffus par le
serveur appartient bien l'organisme indiqu s'il vrifie la chaine de certification, s'il
a confiance dans le certificat racine et s'il a confiance dans les organismes dtenteurs
des certificats intermdiaires pour avoir fait les vrifications ncessaires avant de
signer les certificats drivs. (Il s'agit alors de tiers de confiance ou d'autorits de
certification.)
3. Le certificat serveur n'offre qu'une authentification du serveur. Si le service accd
gre une base de comptes utilisateurs, ceux-ci doivent donc galement en plus
s'authentifier. Cette authentification du client peut ventuellement s'effectuer via un
nom d'utilisateur et un mot de passe. Cette mthode est moins forte qu'une technique
faisant appel des algorithmes de cryptographie asymtriques, mais elle est bnficie
nanmoins via HTTPS de la protection offerte par le canal chiffr et sign de SSL.
4. Dans ce cas, l'authentification du client, appuye sur un certificat et une
authentification clef prive/clef publique offre des garanties bien plus importantes
en terme de scurit. Par contre, il faut alors grer une procdure de dlivrance de
ces certificats clients (incluant leur signature par un tiers de confiance, aprs
vrification de l'identit du demandeur par exemple).
5. La clef prive associe un certificat ne doit tre que trs rarement stocke en clair
(notamment sur disque). Elle est protge par un chiffrement symtrique dont la
passphrase constitue la clef. C'est donc un mot de passe permettant de
dverrouiller l'usage du certificat et de protger la clef prive de l'utilisateur en cas
de vol (par exemple afin de lui laisser le temps de dtecter le vol et de rvoquer son
certificat).
6. Si une passphrase est aussi utilise sur le serveur, chaque lancement du service
Web, il sera ncessaire de la fournir au programme afin qu'il puisse accder la clef
prive du certificat serveur. Il est peu probable que ceci soit effectu de manire
interactive ( chaque redmarrage...). Il est plus probable qu'en pratique, soit la clef
prive est effectivement stocke en clair sur le serveur, soit la passphrase en question
est stocke dans les paramtres de configuration du serveur (ce qui n'est pas mieux).
Ce faisant, les administrateurs Web/systme drogent vis vis du certificat serveur
aux rgles de protection qu'ils recommandent leurs utilisateurs pour les certificats
clients. mditer...
Exercice 2 (7 points)
On tudie l'architecture de protection rseau suivante :
Firewall
1
Poste de
travail
Poste de
travail
Server Web
public
salle
serveurs
Internet
DMZ
D
M
Z

a
d
m
i
n
.
Serveur DNS
Proxy HTTP
Admin. et traces
firewall (1&2)
Controleur de
domaine AD
Serveur de
fichiers
SGBD
Firewall
2
Question 1 (2 points) : Compte tenu du mode de fonctionnement suggr par le schma,
prsentez les diffrentes zones de scurit associes l'architecture de protection rseau et
leurs niveaux de scurit respectifs.
Question 2 (1 point ) : Commentez les rles respectifs du serveur DNS situ en DMZ
d'administration et du contrleur de domaine AD vis vis du service DNS offert globalement
par le systme d'information aux utilisateurs internes et externes.
Question 3 (2 points) : On a ici une architecture de protection faisant appel deux
quipements distincts, l'un tourn vers Internet et l'autre vers les systmes serveurs.
Que pensez-vous de ce choix d'architecture en terme de protection, de configuration ?
Quelles seront votre avis les contraintes de fonctionnement respectives de chacun des deux
quipements, en particulier du point de vue des flux rseaux traiter (nature, dbit, etc.).
(Mettez notamment en vidence les diffrences.)
Question 4 (1 point ) : On suppose que les deux firewall sont de technologie identique et que le
serveur d'administration et de gestion des traces est unique pour les deux. Commentez cet
aspect vis vis de l'administration et du positionnement de la DMZ d'administration.
Question 5 (1 point ) : Quel avantage et quel inconvnient pourrait-il y avoir au fait d'avoir
deux firewall de technologies diffrentes au lieu de deux quipements similaires?
Corrig
Question 1:
La DMZ Admin est une zone d'administration des quipements de scurit. Elle contient un
serveur de gestion des firewall qui stocke galement les traces que ces quipements
collectent. On trouve galement dans cette zone un serveur DNS, probablement plac l car
il s'agit d'une zone de haut niveau de scurit. Ce serveur DNS est alors probablement le
serveur principal des zones attribues l'entreprise ou l'organisme concern.
La DMZ contient un serveur Web accessible de l'extrieur. Elle contient galement un relais
HTTP, qui doit servir relayer les accs internes vers Internet.
La zone salle serveurs est elle aussi place dans une zone de scurit spcifique. Ainsi,
l'ensemble des serveurs sont logiquement isols au niveau du rseau des postes de travail et
des autres zones de scurit.
Question 2:
On peut supposer que le serveur DNS de la DMZ Admin. correspond au serveur DNS visible sur
Internet qui gre en propre la zone DNS de l'entreprise. Par contre, le serveur DNS associ au
serveur AD situ en interne gre galement des zones de nommage (via le DNS) mais qui sont
associes aux machines internes du LAN (noms de machines Windows, noms de domaines, etc.). Cette
zone n'est a priori pas visible depuis Internet.
Par contre, on entrevoit l une difficult de fonctionnement. En effet, les postes de travail peuvent
avoir besoin d'accder simultanment aux deux zones de nommage et la configuration respective des
deux serveurs sera tudier plus prcisment (notamment si on souhaite viter que tous les clients
n'aient essayer la rsolution de leurs noms auprs des deux serveurs tour tour, ce qui n'est pas
vraiment optimal).
Question 3:
En terme de protection, on dispose ici de deux lignes de dfense pour les lments de l'organisme
ayant trs probablement le plus de valeur dans le systme d'information: ses serveurs internes. C'est
certainement positif du point de vue de la scurit si les firewall sont grs correctement.
Un point d'administration central est galement prvu, qui semble donc ainsi offrir des fonctions de
gestion unifie des 2 quipements afin de faciliter leur configuration. Toutefois, on imagine dj que
cette configuration sera plus complique qu'avec un seul quipement faisant face seulement des flux
la frontire avec Internet.
Le firewall externe est expos l'ensemble d'Internet. Il est donc susceptible de faire face des
menaces extrmement varies. Par contre, les protocoles qui le traversent sont probablement peu
nombreux et relativement faciles prciser et maitriser. C'est finalement un cas assez classique
d'utilisation de ce genre d'quipement.
Le firewall interne est essentiellement destin assurer une protection des serveurs vis vis des
utilisateurs internes (ou en 2 ligne de protection pour une intrusion externe russie sur les postes de
travail). Or, en interne au LAN, les flux rseaux sont parfois trs varis (impression, partage de
fichiers, etc.) et la configuration de ce firewall va sans doute tre difficile affiner prcisment. On
sera mme surement amen faire des compromis sur cette configuration afin d'viter des
dysfonctionnements. Par ailleurs, la volumtrie des flux rseaux concerns sera certainement
beaucoup plus importante sur le LAN au niveau du firewall interne que vis vis d'Internet. La
performance de cet quipement sera donc surveiller.
Question 4:
La DMZ d'administration peut tre vue comme la zone de plus haut niveau de scurit dans
l'architecture. Il aurait peut-tre t plus logique dans ce cas de la faire elle aussi bnficier du
double niveau de protection rseau (tout comme les serveurs). On aurait donc pu raccorder cette
DMZ d'administration sur le 2 firewall interne au lieu de la connecter directement au 1 firewall.
(Par contre, dans ce cas, le positionnement du serveur DNS serait r-tudier.)
Peut-tre le firewall interne a t'il t install dans un 2 temps, aprs que le firewall tourn vers
Internet ait t dploy ?
Question 5:
Si les deux firewall sont identiques, on note dj un risque en cas de faille de scurit sur
l'quipement en question. L'avantage d'avoir deux firewall diffrents, c'est que mme en cas de
vulnrabilit grave affectant le firewall en contact avec Internet, le 2 quipement interne pourra
assurer une protection des principaux serveurs.
Par contre, en terme de configuration, il sera alors certainement trs difficile de disposer d'un moyen
de configuration unifi des deux quipements. On aura donc un inconvnient (probablement
important) vis vis de la facilit d'administration de l'architecture.