INSA – 5° R.T. Sujet d’examen 21 janvier 2011
Sécurité des systèmes informatiques 2ème partie Exer Ex erci cicce 1 (3 points) Le protoc protocole ole HTTPS HTTPS (HTTP (HTTP sur sur SSL/TL SSL/TLS) S) est est couram couramme ment nt utilis utilisé pour pour sécuris curiser er les commu communic nicati ations ons entre entre un serve serveur ur Web et un navig navigate ateur. ur. Pour Pour cela, cela, une sessi session on HTTPS HTTPS s'ap s'appu puie ie sur sur un certi certifi fica catt diff diffus usé par par le serv serveu eurr perm permet etta tant nt d'ef d'effe fect ctue uerr une une sess sessio ion n d'authentification initiale et ensuite un chiffrement du canal de communication dans lequel transite l'échange HTTP. 1. Lors Lors de l'auth l'authent entifi ificat cation ion,, le protocol protocolee utilis utilisee une une clef clef publiq publique ue contenu contenu dans un certificat que le serveur d étient et diffuse au client à l' établissement de la connexion. Quelles sont les protections offertes par cette utilisation d'un certificat serveur ? 2. Comm Commen entt l'ut l'util ilis isat ateu eurr du navi naviga gate teur ur peut peut-i -ill être assur assuré que cette cette clef clef publiq publique ue correspond bien à l'organisme auquel il souhaite acc éder ? 3. Pourquoi Pourquoi de nombreu nombreux x services services Web, utilisa utilisant nt pourtant pourtant HTTPS, HTTPS, demandent demandent-ils -ils en plus à l'utilisateur de fournir un nom de compte et un mot de passe pour compl éter l'ouverture de session ? 4. Il est possi possible ble d'util d'utilise iserr un certifi certificat cat clien clientt stock stock é sur le navigateur pour l'échange HTTPS HTTPS.. Quel Quel est est l'effe l'effett de l'utili l'utilisa sation tion d'un d'un certi certific ficat at clien clientt sur sur la protec protectio tion n de l'ensemble du service ? 5. Avec un certif rtific icaat clien lient, t, l'ut l'util ilis isat ateeur doit oit quand uand même parf parfoi oiss four fourni nirr une une « passphrase »: de quel mot de passe s'agit-il ? 6. Pens Pensez ez-v -vou ouss qu'il qu'il y ait ait une une « passphase » utilisateur sur la partie priv ée du certificat certificat serveur ? Pourquoi ? Corrigé 1. Le protoc protocole ole SSL avec un certi certific ficat at serveu serveurr offre offre d'abord d'abord une authenti authentific ficati ation on du é par une v é rification étient partenaire accé d dé rification que ce serveur d é t ient bien la clef privé e ée, correspondant à la clef publique diffus é e. e. Ensuite, la communication communication est chiffr é e , on a égrit rit é é de donc des garanties sur la confidentialit é des des é changes changes ainsi que sur l'int é g de la ée. communication communication pendant toute sa dur é e . 2. Le certifi certificat cat n'inclu n'inclutt pas seulem seulement ent la clef clef publiqu publique, e, mais mais é galement galement une signature de cette cette clef clef publiq publique ue par par un autre autre certif certifica icat. t. (Ce (Celui lui-ci -ci pouvan pouvantt é galement galement être un certifica certificatt interm intermé diaire diaire.) .) La racine racine de cette cette chaî ne ne de certif certifica icatio tion n doit doit être un é-install é pendamment éalable lable à la certificat pr é - installé sur sur le navigateur (ou obtenu ind é en pr é a communic communication ation). ). L'utilisate L'utilisateur ur peut alors alors être sûr que que le certi certific ficat at diffus diffusé par le serveur appartient bien à l'organisme indiqu é s'il s'il vé rifie rifie la chaine de certification, s'il a confiance dans le certificat racine et s'il a confiance dans les organismes d é tenteurs tenteurs des certificats interm é diaires diaires pour avoir fait les v é rifications rifications né cessaire cessairess avant de é riv signer les certificats d é rivé s. s. (Il s'agit alors de tiers de confiance ou d'autorit é s de certification.)
3. Le certificat serveur n'offre qu'une authentification du serveur. Si le service acc é dé gère une base de comptes utilisateurs, ceux-ci doivent donc é g alement en plus s'authentifier. Cette authentification du client peut é ventuellement s'effectuer via un nom d'utilisateur et un mot de passe. Cette m é thode est moins forte qu'une technique faisant appel à des algorithmes de cryptographie asym é triques, mais elle est bé né ficie né anmoins via HTTPS de la protection offerte par le canal chiffr é et signé de SSL. 4. Dans ce cas, l'authentification du client, appuy é e sur un certificat et une authentification à clef privé e/clef publique offre des garanties bien plus importantes en terme de s é curit é . Par contre, il faut alors g é rer une proc é dure de d él ivrance de ces certificats clients (incluant leur signature par un tiers de confiance, apr ès vé rification de l'identit é du demandeur par exemple). 5. La clef privé e associé e à un certificat ne doit être que tr ès rarement stock ée en clair é e par un chiffrement sym é trique dont la (notamment sur disque). Elle est prot ég « passphrase » constitue la clef. C'est donc un mot de passe permettant de er la clef privé e de l'utilisateur en cas d év errouiller l'usage du certificat et de prot ég de vol (par exemple afin de lui laisser le temps de d ét ecter le vol et de r év oquer son certificat). 6. Si une passphrase est aussi utilisé e sur le serveur, à chaque lancement du service Web, il sera né cessaire de la fournir au programme afin qu'il puisse acc é der à la clef privé e du certificat serveur. Il est peu probable que ceci soit effectu é de manière arrage...). Il est plus probable qu'en pratique, soit la clef interactive (à chaque red ém privé e est effectivement stock ée en clair sur le serveur, soit la passphrase en question est stock ée dans les param ètres de configuration du serveur (ce qui n'est pas mieux). Ce faisant, les administrateurs Web/syst ème d ér ogent vis à vis du certificat serveur aux r ègles de protection qu'ils recommandent à leurs utilisateurs pour les certificats clients. À mé diter...
Exercice 2 (7 points) On étudie l'architecture de protection r éseau suivante : Internet
Serveur DNS
.
ni m d a Z M D
DMZ
Server Web public Firewall
Admin. et traces
1
Proxy HTTP
firewall (1&2)
Firewall Poste de
Poste de
travail
travail
2
salle serveurs
Controleur de
Serveur de
domaine AD
fichiers
SGBD
Question 1 (2 poin ts) : Compte tenu du mode de fonctionnement suggéré par le schéma, présentez les diff érentes zones de s écurité associées à l'architecture de protection réseau et leurs niveaux de s écurité respectifs. Question 2 (1 poin )t : Commentez les rôles respectifs du serveur DNS situé en DMZ d'administration et du contrôleur de domaine AD vis à vis du service DNS offert globalement par le système d'information aux utilisateurs internes et externes. Question 3 (2 poin ts) : On a ici une architecture de protection faisant appel à deux équipements distincts, l'un tourn é vers Internet et l'autre vers les syst èmes 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 r éseaux à traiter (nature, débit, etc.). (Mettez notamment en évidence les diff érences.) Question 4 (1 poin )t : 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 poin )t : Quel avantage et quel inconv énient pourrait-il y avoir au fait d'avoir deux firewall de technologies diff érentes au lieu de deux équipements similaires?
Corrigé Question 1: La DMZ Admin est une zone d'administration des é quipements de sé curit é. Elle contient un serveur de gestion des firewall qui stocke é g alement 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 sé curit é. Ce serveur DNS est alors probablement le serveur principal des zones attribué es à l'entreprise ou l'organisme concerné . La DMZ contient un serveur Web accessible de l'ext ér ieur. Elle contient é galement un relais HTTP, qui doit servir à relayer les accès internes vers Internet. La zone « salle serveurs » est elle aussi placé e dans une zone de sé curit é spé cifique. Ainsi, l'ensemble des serveurs sont logiquement isolé s au niveau du r és eau des postes de travail et des autres zones de sé curit é. Question 2: On peut supposer que le serveur DNS de la DMZ Admin. correspond au serveur DNS visible sur Internet qui gère en propre la zone DNS de l'entreprise. Par contre, le serveur DNS associ é au serveur AD situé en interne gère é galement des zones de nommage (via le DNS) mais qui sont associé es 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'accé der simultané ment aux deux zones de nommage et la configuration respective des deux serveurs sera à é tudier plus pr éc isé ment (notamment si on souhaite é viter que tous les clients n'aient à essayer la r é solution de leurs noms aupr ès 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 d é fense pour les é lé ments de l'organisme ayant tr ès probablement le plus de valeur dans le syst ème d'information: ses serveurs internes. C'est certainement positif du point de vue de la sé curit é si les firewall sont gé r és correctement. Un point d'administration central est é galement pr év u, qui semble donc ainsi offrir des fonctions de gestion unifié e des 2 é quipements afin de faciliter leur configuration. Toutefois, on imagine d é jà que cette configuration sera plus compliqué e qu'avec un seul é quipement faisant face seulement à des flux à la frontière avec Internet. Le firewall externe est exposé à l'ensemble d'Internet. Il est donc susceptible de faire face à des menaces extr êmement varié es. Par contre, les protocoles qui le traversent sont probablement peu nombreux et relativement faciles à pr éc iser et maitriser. C'est finalement un cas assez classique d'utilisation de ce genre d' éq uipement. 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 r éu ssie sur les postes de travail). Or, en interne au LAN, les flux r é seaux sont parfois tr ès varié s (impression, partage de fichiers, etc.) et la configuration de ce firewall va sans doute être difficile à affiner pr é cisé ment. On sera même surement amené à faire des compromis sur cette configuration afin d' év iter des dysfonctionnements. Par ailleurs, la volumé t rie des flux r és eaux concerné s 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 sé curit é dans l'architecture. Il aurait peut-être é t é plus logique dans ce cas de la faire elle aussi b é né ficier du double niveau de protection r és eau (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, apr ès que le firewall tourné vers Internet ait é té d é ployé ? Question 5: Si les deux firewall sont identiques, on note d é jà un risque en cas de faille de s é curit é sur l' éq uipement en question. L'avantage d'avoir deux firewall diff ér ents, c'est que même en cas de vulné rabilit é 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 tr ès difficile de disposer d'un moyen de configuration unifié des deux é q uipements. On aura donc un inconvé nient (probablement important) vis à vis de la facilit é d'administration de l'architecture.
