Disaster Recovery. TER Master Pro ResTel. 24 novembre 2004 version 1.0. Benoit Bourdin, Nicolas Pradelles Enseignant: Michel Darracq

Transcription

1 Disaster Recovery TER Master Pro ResTel 24 novembre 2004 version 1.0 Benoit Bourdin, Nicolas Pradelles Enseignant: Michel Darracq

2 Table des matières Introduction 3 1 Audit de flux Présentation du contexte de l audit Le client Le réseau Audit technique Services Bande passante par service Service web (http/https) Service ssh Conclusions Services critiques Technique nécessaire Bilan technique et financier Routage sur internet Un exemple Couche application Couche IP DNS Routage Couches inférieures Routeur(s) Arrivée Le Routage Types de protocoles BGP Avantages de BGP Problèmes de BGP

3 3 Solutions proposées Approches Solution 1 : secours manuel Solution 2 : aliasing IP Application au cas de l audit Conclusion 22 2

4 Introduction Chaque entreprise possède maintenant son réseau informatique. Dans le cas d un grande entreprise, celui-ci est naturellement conséquent. Les moyens étant importants, l administrateur réseau se doit donc de prévoir des systèmes de sauvegarde pour pallier aux problèmes techniques pouvant se produire. Le cas le plus grave est le cas d une catastrophe naturelle. En effet, dans le cas d une inondation, d un incendie ou d un mouvement social, que reste-t-il du système informatique? Le travail de l ingénieur est ici de prévoir ces événements et de mettre en place une plate forme de secours. Ce travail est d autant plus important qu une panne de service peut coûter cher à l entreprise, surtout si cela concerne tout le système informatique. Typiquement, l entreprise aura un site de secours physiquement distant de son site principal, contenant un système informatique prêt à être démarré rapidement de manière sécurisée pour prendre le relai. Nous allons étudier ce problème en débutant par une étude de cas. Ensuite, nous apporterons quelques précisions techniques sur le routage. Enfin, nous finirons par proposer 2 solutions au problème posé. 3

5 Chapitre 1 Audit de flux Notre premier travail va être de se placer dans un exemple concret pour formuler une analyse la plus pertinente possible. Pour cela, nous avons réalisé un audit de flux sur un client possible. 1.1 Présentation du contexte de l audit Le client Pour notre exemple, nous avons choisi de prendre comme client potentiel une association : la fédération Aurore, regroupant les 4 associations de gestion de réseau informatique en chambre universitaire d Orsay (Flemnet, Cibynet, Pacatnet et BDI). Cette fédération regroupe donc des ressources communes aux 4 cités universitaires Le réseau Les 4 résidences, reliées entre elles, ont accès à quelques machines appartenant à Aurore, dont la machine anubis qui fait office de proxy (relai) pour l accès à Internet. Celle ci est donc à la fois reliée au réseau des résidences (via un routeur cisco) et au réseau Internet. Cependant, la machine ne possède qu une interface réseau. Les résidents des 4 cités universitaires passent donc par cette machine, ce qui représente en ordre d idée pas loin de 1000 utilisateurs. Physiquement, cette machine est située dans un local technique fermé, accessible à un nombre restreint d administrateurs. L accès se fait donc à distance par le réseau, sauf problème sérieux nécessitant une intervention. 4

6 1.2 Audit technique L objectif de cet audit est de distinguer et de quantifier les flux transitant par la machine en question Services Avant tout, l utilité de la machine est d être serveur des résidences, donc de fournir des services aux adhérents. Il nous fallait donc identifier les services offerts, en affichant la liste des ports ouverts sur la machine : TCP/UDP Port Nom Accès TCP ssh (22) Serveur SSH Ouvert TCP smtp (25) Serveur mail Uniquement en local TCP http (80) Serveur web Ouvert TCP https (443) Serveur web sécurisé Ouvert TCP 1100 Proxy mail POP (flopp) Ouvert TCP 8080 Proxy Ouvert Tab. 1.1 Ports ouverts sur la machine A ceci, il nous faut ajouter un certain nombre de remarques : Le serveur ssh permet l administration à distance, mais il fait aussi office de proxy ssh pour les adhérents. Les serveurs web (http et https) hébergent les sites web extranet des associations, ainsi qu un accès web (depuis l extérieur) pour tout les adhérents à leurs comptes mails. Le serveur mail local (smtp) n est juste accessible qu en local, donc seulement depuis la machine elle-même Bande passante par service Notre but ici va être de donner les quantités de données transitant sur la machine, service par service. On pourra ainsi déterminer quels seront les besoins en terme de puissance. Pour cette mesure, nous avons lancé un logiciel nommé ipband, sur une durée de 9h42mn, en soirée, ce qui devrait être représentatif pour des débits moyens. Nous n avons relevé que les requêtes (ainsi que leurs réponses en TCP) s adressant à la machine. 5

7 Service Type (N de port) Traffic (Ko) Débit proxy tcp (8080) Ko/s ssh tcp (22) o/s auth tcp (113) o/s flopp tcp (1100) o/s http tcp (80) o/s https tcp (443) o/s icmp icmp o/s domain udp (53) o/s Total Ko/s Tab. 1.2 Quantité de requêtes reçues des utilisateurs Cependant, ce dernier tableau ne mesure que les requêtes envoyées des utilisateurs vers la machine. On pourrait alors arriver au tableau suivant estimant le débit total sur l interface réseau. Service Traffic (Ko) Débit proxy Ko/s ssh Ko/s auth o/s flopp o/s http o/s https o/s icmp o/s domain o/s Total Ko/s Tab. 1.3 Débit estimé sur l interface De la même manière, on peut observer sur la même période le nombre de connexions : A ceci, on peut préciser que toutes les connexions n aboutissent pas. En effet, les connexions sur les ports auth et domain, ainsi que les requêtes icmp, échouent, les ports en question n étant pas ouverts. Maintenant, nous allons détailler les requêtes utilisateurs, service par service. 6

8 Service Connexions Par minute proxy auth ssh icmp flopp http https domain total Tab. 1.4 Quantité de connexions sur la machine Service web (http/https) Les services http et https regroupant plusieurs applications, il est bon de détailler l utilisation. Pour cela, nous nous sommes basés sur l analyse des fichiers de journaux (log), sur une période de 22 jours, du 22 octobre à 04h01 au 13 novembre, 11h54. Dossier accédé Requêtes Par minute Description site externe Requêtes erronées /webmail Site d accès aux comptes mail /aurore Site de la fédération /flemnet Site de l association Flemnet /pacatnet Site de l association Pacatnet / Page d accueil /cibynet Site de l association Cibynet Tab. 1.5 Pages accédées les plus fréquemment On remarque d après ces résultats que la grande majorité des pages accédées concerne le site d accès au mail (webmail), mais que la plus grosse charge est consommée pour des requêtes erronées, provenant d une mauvaise éducation des utilisateurs qui utilisent le port 80 au lieu du port 8080 comme proxy. En examinant la source des requêtes, on relève que la majorité de cellesci proviennent de l interne, alors que le service web était plutôt destiné aux extérieurs, surtout pour l accès au mail. 7

9 Source Requêtes Résidences Extérieur localhost 665 Tab. 1.6 Source des requêtes web Nous n avons pas pu recouper les 2 derniers résultats, pour savoir si les requêtes internes sont bien majoritairement erronées. Cependant, nous supposerons que c est le cas et que le service web le plus critique est l accès au mail de l extérieur. Les autres applications sont plus informatives (sites web des associations) et sont donc moins vitales en terme de présence du service. De plus, en accédant nous-mêmes au service, nous avons constaté que l accès au mail se fait via le port https (443, sécurisé), alors que toutes les autres pages se font sur le port http (80). On se référera donc aux tableaux précédents pour avoir une idée du débit utilisé par cette application Service ssh De base, le service ssh est utilisé pour l administration à distance. Cependant, notre machine fait aussi office de proxy ssh, accessible en se connectant sur un compte donné. Pour cet audit, nous avons analysé les fichiers de journaux du serveur ssh, rassemblant les connexions sur une période de 13 jours, du 31 octobre 2h00 au 13 novembre midi. Compte utilisé Connexions Par jour Proxy Administrateurs 76 6 Comptes incorrects 64 5 Tab. 1.7 Comptes utilisés pour la connexion au service ssh La dernière ligne du tableau concerne les tentatives de connexions n ayant pas abouties. De la même manière, on peut déterminer la source des connexions. Remarque à ajouter à ce tableau : ici aussi, nous n avons pas pu recouper les 2 tableaux. Cependant, il faut savoir que le compte Proxy n est accessible que depuis les résidences. Les connexions de l extérieur ne concernent donc seulement que les administrateurs, et celles provenant des résidences concerne à la fois les administrateurs et les utilisateurs du proxy. Enfin, on précisera 8

10 Source Connexions Par jour Résidences Extérieur 52 4 Tab. 1.8 Source des connexions ssh aussi que les connexions en administrateurs, bien que peu nombreuses, ont une utilité vitale : elles sont le seul moyen de contrôler la machine, l accès physique de la machine étant difficile. Ainsi, pour notre étude, on dira que le service ssh est vital aux administrateurs, bien que ne consommant que peu de ressources. Le proxy ssh l est par contre beaucoup moins, n étant utilisé que par peu d utilisateurs. 1.3 Conclusions L audit ayant pour but de déterminer les services critiques et les moyens nécessaires aux solutions proposées, nous allons les énoncer dans cette partie Services critiques D après notre audit, on peut classer par indice critique les services hébergés sur la machine : Ordre Service 1 ssh (pour les administrateurs) 2 Proxy web 3 Proxy mail (flopp) 4 https (accès mail webmail) 5 Proxy ssh 6 http (serveur web) Tab. 1.9 Services les plus critiques Ce classement est basé premièrement sur notre connaissance des services critiques (par exemple le ssh pour les administrateurs) et ensuite sur l utilisation (le nombre de connexions). On pourra d ailleurs considérer que les 2 premiers services sont vraiment vitaux, les suivants seront plus optionnels. 9

11 1.3.2 Technique nécessaire Techniquement, chaque service a besoin d un certain débit pour fonctionner normalement. De plus, certains services ne sont utiles que depuis l extérieur. Pour cela, nous allons nous baser sur nos précédentes mesures. Service Débit nécessaire Liens nécessaires ssh 0.3 Ko/s Interne ou externe Proxy web Ko/s Interne+externe Proxy mail o/s Interne+externe https (webmail) 12.9 o/s Interne+externe Proxy ssh 0.6 Ko/s Interne+externe http 16.4 o/s externe Tab Débits et liens nécessaires aux services critiques Bilan technique et financier Au niveau technique, face à une catastrophe naturelle, on peut donc éventuellement se permettre de ne restaurer que les 2 services les plus critiques : ssh et le proxy web. Cependant, dans le cas présent, il n existe pas encore de parade à ce genre de catastrophe et les risques peuvent ne pas être négligeables. En effet, on peut estimer que le remplacement et la mise en fonction d une nouvelle machine peut prendre 4 jours. Ces associations ne garantissent pas le service à ses adhérents, mais si cela était le cas, elles devraient rembourser le montant correspondant des cotisations. Dans ce cas (4 jours d interruption de service), on peut estimer qu une catastrophe peut occasionner une perte de 1100 euros, hors coût de remplacement du matériel. Notre client n étant pas une entreprise, les sommes en question sont limitées. Si cela avait été le cas, il aurait fallu prendre en compte le salaire des administrateurs pour remettre en place le service, le salaire des employés n ayant plus de moyen de travail, voire même une certaine perte de clientèle. Pour éviter ces pertes, notre travail va être d apporter des solutions précises et techniques et d en estimer le coût. 10

12 Chapitre 2 Routage sur internet Avant d appréhender des solutions adaptées, il convient de bien maîtriser le fonctionnement du routage utilisé dans Internet. 2.1 Un exemple Supposons pour l exemple que nous partons d un utilisateur lambda voulant accéder au site web d un client, donc par exemple fr. Nous allons donc parcourir les couches TCP/IP pour notre requête en nous focalisant sur la couche IP, la plus intéressante dans notre cas Couche application La seule chose que l utilisateur entre, c est l adresse URL du site web. C est le navigateur web (habituellement Mozilla, Netscape ou IE) qui récupère l information. Il va construire une requête HTTP. Cette requête doit être encapsulée successivement dans un paquet TCP et IP Couche IP Pour remplir les champs d en-tête du paquet IP, notre navigateur doit connaître l adresse IP destination, ne connaissant que le nom Pour la connaître, il va d abord regarder dans son cache si jamais il en a un, puis son fichier hosts (hosts.txt ou /etc/hosts). Sinon, il va faire une requête DNS (en construisant un paquet UDP à envoyer à son serveur DNS favori). 11

13 Fig. 2.1 Exemple de requête HTTP 12

14 2.1.3 DNS Le serveur DNS reçoit ensuite la requête, regarde dans sa configuration, inspecte pour savoir s il s agit d une zone DNS gérée par lui-même. Si c est le cas, il renvoie l IP de la machine demandée, sinon il renverra au client le serveur DNS à contacter (qui pourra être un des serveurs racines de l Internet). Auquel cas, notre client demandera lui-même au bon serveur DNS (cas où les requêtes se font de manière itérative) Routage Une fois l IP destination obtenue (l IP de la machine www dans le domaine u-psud.fr), le système client doit déterminer par quel chemin il doit passer pour atteindre la machine : il va utiliser le routage. Pour cela, il va regarder sa table de routage, et en déduire le chemin, 2 cas sont possibles : le lien est local, la machine demandée est sur notre réseau. Ce ne sera vraisemblablement pas le cas ici. le lien passe par un ou plusieurs routeurs. On enverra donc notre paquet au routeur demandé Couches inférieures Enfin, notre système va passer la main aux couches inférieures qui vont assurer l acheminement du paquet vers notre premier routeur Routeur(s) Lors de l arrivée du paquet sur un routeur, celui-ci va : 1. regarder dans son cache et, si jamais il trouve quelque chose, donner directement la route à poursuivre. 2. sinon, regarder dans sa table de routage et donner le prochain hôte à atteindre. Sa table de routage étant remplie via des algorithmes tels que RIP et OSPF, le routeur saura quelle route sera la bonne Arrivée Une fois notre paquet arrivé à l hôte destination (ici, le serveur web de l université), le système le fait remonter de couche en couche pour finale- 13

15 ment le délivrer à l application faisant office de serveur web, qui sera capable d envoyer une réponse. 2.2 Le Routage Revenons plus en détail sur notre dernier exemple, en particulier sur la partie routeur Types de protocoles On doit alors faire la différence entre 2 types de routages : le routage dans un réseau local, plus ou moins grand. le routage sur Internet. Dans notre 2ème cas, le problème n est plus le même : on ne peut pas se permettre par exemple de demander à chaque routeur de connaître tout l ensemble du réseau. C est difficilement imaginable, demanderait un espace mémoire énorme à chaque routeur, pour arriver à un temps de propagation très long BGP Ainsi a été inventé le protocole BGP (Border Gateway Protocol), dont le principe est de découper en petits sous-réseaux appartenant à une même zone : des systèmes autonomes. Ainsi, chaque système autonome peut être géré à sa façon (comme l université gère son routage interne à sa façon et wanadoo autrement), BGP assurant le lien entre chaque système autonome. Ainsi, chaque opérateur internet utilise en interne son IGP (Interior Gateway Protocol, par exemple RIP ou OSPF), et entre les opérateurs on utilise un EGP (Exterior Gateway Protocol, comme BGP) Avantages de BGP Tout d abord, l algorithme BGP est assez efficace : il propose une convergence rapide de l état des routes. Mais le vrai intérêt de BGP (surtout par rapport à OSPF que l on peut aussi utiliser en EGP) est de pouvoir définir les politiques de routage : par exemple dire que l on préfère passer par l université de Jussieu que par une liaison 9telecom plus chère. On peut définir 2 types de politiques : une politique d import : définit un choix dans les routes à accepter. une politique d export : choix dans les routes à proposer. 14

16 On aura ainsi un fonctionnement plutôt dynamique (capable de changer de route en cas de problème sur un routeur), mais aussi un peu statique (on peut imposer des contraintes). L algorithme fonctionne à base d échange de vecteurs de chemins. Chaque système autonome sera identifié par un entier et le vecteur de chemins sera une suite de ces entiers. La politique s applique donc à avoir des vecteurs que l on préfère à d autres Problèmes de BGP Cependant, si on fait dérouler l algorithme, on obtient dans certains cas des instabilités : à chaque tour de l algorithme, les routes changent. On peut même trouver des cas où la stabilité devient aléatoire. Pour remédier à ce problème, on impose des contraintes aux politiques données en entrée. On peut avoir 2 types de contraintes, à prendre au choix : condition locale : s applique au système autonome qu on configure. condition globale : s applique au graphe du réseau. Moyennant ces contraintes, on sera sur que notre routage fonctionnera dans tout les cas et convergera vers un état stable. Au final, BGP reste un algorithme assez adapté au routage entre opérateurs, mais nécessite beaucoup de configuration manuelle. 15

17 Chapitre 3 Solutions proposées Face aux problèmes énoncés dans les parties précédentes, et connaissant maintenant les détails techniques sur le routage, nous allons proposer 2 solutions possibles pour y remédier. 3.1 Approches Tout d abord, nous n allons proposer que des solutions de secours à froid, c est à dire que lorsque le site principal subit une catastrophe, il faudra une petite opération manuelle pour basculer sur le site secondaire. On oppose ce type de solutions au secours à chaud, où le basculement se fait de manière automatique. De plus, notre 2ème impératif a été de faire des solutions sécurisées. Nous préciserons donc les droits minimum nécessaires à chaque procédure de basculement. Enfin, nos solutions concernerons le réseau donné en sujet (voir ci-dessous), nous ajouterons les détails nécessaires à l application des solutions au réseau audité. Le sujet donne en exemple un réseau client, avec un site principal concernant l entreprise, et un backbone (que l on contrôlera) reliant ce site au réseau Internet. Le but est ici d assurer qu un client potentiel de l entreprise (donc accédant via Internet) puisse accéder au site principal. La configuration du routeur cisco situé dans le backbone est donnée ci-dessous (extrait) : interface Serial1/0/0.105 point-to-point description TEST bandwith 128 ip address no cdp enable 16

18 frame-relay interface-dlci 105! interface Serial1/0/3 no ip address shutdown serial restart-delay 0 no cdp enable On ne rappelle ici qu un extrait de la configuration, le reste concerne le routeur en lui-même et n aura pas à être modifié. Pour chaque solution, on donnera donc une configuration du cisco (IOS) à appliquer. On rappelle ainsi que pour appliquer une configuration, une fois connecté sur le routeur, il suffit de taper : routeur>en Password: router#conf t Enter configuration commands, one per line. routeur(config)# End with CNTL/Z. Une fois la configuration tapée, pour l appliquer et l enregistrer, il suffit de taper : routeur(config)#^z routeur#wr Building configuration... [OK] routeur# Toutes les informations de configuration sont tirées de la documentation fournie et ont toutes été vérifiées sur un routeur Cisco 2700 (sur des interfaces FastEthernet). Pour l entreprise, les solutions proposées auront toutes le même coût : celui d un nouveau site (le site de secours), équivalent à l achat de matériel nécessaire au système d information, et au raccordement au backbone. A cela il faudra rajouter éventuellement le coût de montage ou de location d un backbone, plus les coûts nécessaires à l administration réseau du total. 3.2 Solution 1 : secours manuel Le principe de cette première solution est une modification manuelle du routeur de sortie du client. Nous prenons donc comme configuration notre 17

19 routeur possédant au moins 2 interfaces réseau en sortie, l une connectée au site principal, l autre au site de secours. Le principe du basculement est ici de couper l interface principale et d activer l interface de secours. La configuration IOS ci-dessous permettent d effectuer cette opération : interface Serial 1/0/0 shutdown interface Serial 1/0/3.105 point-to-point ip address frame-relay interface-dlci 105 no shutdown Cette modification réaffecte l adresse IP de l interface 1 vers l interface 2. Ainsi, dans tout les cas, on aura l adresse IP qui sera valide (attribuée à l une des 2 interfaces). Un client potentiel pourra donc accéder par la suite à cette IP de manière transparente, que ce soit le site principal ou de secours qui soit activé. Dans ce cas, la manipulation nécessite juste des droits d administrateur sur le routeur du backbone. 3.3 Solution 2 : aliasing IP La solution suivante permet d éviter de modifier l un des routeurs du backbone, action assez sensible. On imaginera alors dans notre cas que chaque site (normal et de secours) possède en entrée un routeur cisco. Le principe dans ce cas présent est d effectuer un aliasing de l adresse IP du site principal sur le site de secours. Ainsi, chaque lien pourra être actif en temps normal. En cas de problème, on ajoutera juste l IP du site principal sur l interface du routeur du site de secours. Grâce à cette configuration particulière du site de secours, lors de la désactivation du site principal et l activation du site de secours, le(s) routeur(s) du backbone mettent automatiquement leur(s) table(s) à jour pour rediriger le trafic du site principal vers celui de secours. En temps normal, le routeur du backbone aura par exemple la configuration suivante : interface Serial1/0/0.105 point-to-point description lien site principal bandwith

20 ip address no cdp enable frame-relay interface-dlci 105! interface Serial1/0/3 description lien site backup bandwith 128 ip address serial restart-delay 0 no cdp enable Le routeur du site principal possède la configuration suivante : interface FastEthernet0/0 description routeur_principal, lien vers backbone ip address Le routeur du site de secours possède la configuration suivante : interface FastEthernet0/0 description routeur_secours, lien vers backbone ip address On rappelle donc que les 2 liens pourront être actifs, ce qui peut permettre à l entreprise de répartir la charge. En cas de catastrophe sur le site principal, son routeur sera donc inaccessible ou détruit. On pourra alors basculer sur le lien de secours en rajoutant la configuration suivante au routeur du site de secours : interface FastEthernet0/0 ip address ip address secondary Si jamais l interface n était pas activée, il faudra aussi rajouter : no shutdown On remarquera dans ce cas, que les seuls droits nécessaires sont les droits d administrateur sur le routeur du site de secours. 19

21 3.4 Application au cas de l audit Dans le cas des cités étudiantes de l Université, nous pouvons envisager la mise en place d un système de secours à froid. Dans ce cas, on rappelle qu on avait un serveur proxy (que l on a audité) qui fait le lien entre les résidences (via un routeur) et Internet. On peut reprendre ce schéma, considérer le routeur des résidences comme un backbone et appliquer notre 2ème solution. Pour cela, un deuxième serveur proxy peut être installé en miroir du premier. Ce nouveau serveur devra être physiquement distant du premier et avoir si possible une connexion à Internet différente du premier. Connecté sur le backbone des cités Universitaires, on peut alors affecter une adresse IP par serveur, par exemple pour le proxy normal et pour l autre. Comme dans les exemples précédents, on donnera la configuration initiale et celle à appliquer. Les configurations sont celles de machines sous un système Unix, ici en particulier FreeBSD. Ainsi, dans le cas normal, on aura en configuration sur la machine principale : root@anubis# ifconfig xl0: flags=8843<up,broadcast,running,simplex,multicast> mtu 1500 options=3<rxcsum,txcsum> inet netmask 0xfffffffc broadcast inet6 fe80::204:76ff:fe0f:ea3%xl0 prefixlen 64 scopeid 0x1 ether 00:04:76:0F:0E:A3 media: Ethernet autoselect (100baseTX <full-duplex>) status: active De la même manière, on aura sur la machine de secours : root@kheops# ifconfig xl0: flags=8843<up,broadcast,running,simplex,multicast> mtu 1500 options=b<rxcsum,txcsum,vlan_mtu> inet netmask 0xfffffffc broadcast inet6 fe80::250:daff:fe64:7ef5%xl0 prefixlen 64 scopeid 0x1 ether 00:50:da:64:7e:f5 media: Ethernet autoselect (100baseTX <full-duplex>) status: active On considère ici aussi que les 2 liens sont activés en permanence. En cas de problème sur notre proxy classique, il ne sera plus accessible. La procédure est la même que dans le cas précédent (rajouter une IP sur l interface), donc appliquer la configuration suivante sur le proxy de secours par la commande : 20

22 ifconfig xl0 inet netmask alias On obtient la configuration suivante : root@kheops# ifconfig xl0: flags=8843<up,broadcast,running,simplex,multicast> mtu 1500 options=b<rxcsum,txcsum,vlan_mtu> inet netmask 0xfffffffc broadcast inet netmask 0xfffffffc broadcast inet6 fe80::250:daff:fe64:7ef5%xl0 prefixlen 64 scopeid 0x1 ether 00:50:da:64:7e:f5 media: Ethernet autoselect (100baseTX <full-duplex>) status: active Les droits nécessaires seront ici uniquement les droits d administrateur sur la machine de secours. Dans le cas de notre client, on estimera le coût de notre solution au coût d une nouvelle machine capable de supporter la charge du proxy. Si on se réfère à notre audit, on peut estimer le coût à approximativement 300 euros, prix vraiment variable en fonction des besoins et des goûts des administrateurs. Le système et les logiciels installés sur la machine sont libres, donc le coût des licences sera nul. Enfin, notre client étant une association, le coût de montage de la machine est nul, le travail étant bénévole. 21

23 Conclusion Ayant analysé les besoins et solutions possibles de notre client, nous pouvons tirer un bilan sur cette expérience. Tout d abord, l approche était tout à fait originale. En effet, peu d administrateurs réseau prévoient des cas de catastrophe naturelle. Grâce à ce projet, nous nous sommes un peu plus familiarisés à cette problématique. Naturellement, toute entreprise ne peut se permettre de monter un site de secours, mais il existe des solutions intermédiaires à moindre coût. De plus, l audit de notre client a été très intéressant, tant de notre coté pour fournir un exemple concret, que du coté du client qui a tiré plusieurs conclusions de notre études. Par ailleurs, il a d ores et déjà commencé à monter une machine de secours. Cependant, il ne pourra pas appliquer totalement notre solution, n ayant pas des moyens simples de mettre cette machine physiquement loin de l autre, et surtout d avoir un autre fournisseur d accès à Internet. 22