Guide ServeurWeb

PREMIER MINISTRE
Secrtariat gnral de la dfense nationale
Issy les Moulineaux, le n /SGDN/DCSSI/SDO/BAS
Direction centrale de la scurit des systmes dinformation
Recommandations de scurisation serveur Web
Informations
Nombre de pages du document : 47
Evolution du document : Version 0.1 Rdaction C. Mercier - N. Moreau Validation DCSSI Philippe Brandt Date 18 septembre 2002
N /SGDN/DCSSI/SDO/BAS
Page 2 sur 47
Table des matires

1 Introduction 1.1 1.2 1.3 1.4 2 3 Objectifs des recommandations . . . . . . . qui sont destines ces recommandations Structure de ce document . . . . . . . . . . Prsentation des recommandations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 7 7 7 7 8 9 9 9 10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 10 10 10 11 12 12 12 13 15 15 15 15 15 15 16 17 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 17 17 18 18 18 18 18 19 19 20 20 20 20
Avertissements Pr-requis 3.1 3.2 Connaissances ncessaires . . . . . . . . . . . . . . . . . . . . . . . . . . . Dnition des rles et tches . . . . . . . . . . . . . . . . . . . . . . . . .
Principaux risques du serveur Web 4.1 4.2 4.3 4.4 Modication de contenu . . Arrt ou dysfonctionnement Rvlation dinformation . . Servir de base dattaque . . . . du . . . . . . . . . . . . service Web . . . . . . . . . . . . . . . .
5 6
Politique gnrale de la scurit des systmes dinformation Principes fondamentaux de la SSI 6.1 Dvelopper et implmenter une dfense en profondeur . . . . . . . . . . 6.1.1 La scurit des locaux et la sret de fonctionnement . . . . . . . . . . . . . 6.1.1.1 Ce quil faut prendre en compte prioritairement sur les lots techniques 6.1.2 La dfense au niveau du rseau . . . . . . . . . . . . . . . . . . . . . . . . . 6.1.2.1 Utilisation de commutateurs . . . . . . . . . . . . . . . . . . . . . 6.1.2.2 Mise en place doutils de dtection dintrusion . . . . . . . . . . . 6.1.3 La dfense au niveau des htes . . . . . . . . . . . . . . . . . . . . . . . . . 6.1.4 La dfense au niveau des applications . . . . . . . . . . . . . . . . . . . . . 6.1.5 La dfense au niveau des donnes . . . . . . . . . . . . . . . . . . . . . . . . 6.2 Principe du moindre privilge . . . . . . . . . . . . . . . . . . . . . . . . . Scuriser : mesures gnrales 7.1 7.2 Relev de conguration . . . . . . . . . . . . . . . . . . Pralables de linstallation . . . . . . . . . . . . . . . . 7.2.1 Vrication du systme sous-jacent . . . . . . . . . . . 7.2.2 Version du serveur Web installer . . . . . . . . . . . 7.2.3 Vrication des sources dinstallation . . . . . . . . . . 7.2.3.1 Mdia physique . . . . . . . . . . . . . . . . 7.2.3.2 Installation dun applicatif tlcharg . . . . 7.2.3.3 Installation directe depuis un rseau externe 7.3 Installation . . . . . . . . . . . . . . . . . . . . . . . . . 7.4 Emploi de mots de passe complexes . . . . . . . . . . 7.5 Administration du systme . . . . . . . . . . . . . . . . 7.5.1 Administration locale . . . . . . . . . . . . . . . . . . 7.5.2 Administration distante . . . . . . . . . . . . . . . . . 7.5.2.1 Terminal Services . . . . . . . . . . . . . . .
Page 3 sur 47
7.5.2.2 7.5.2.3 8
SNMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Tlmaintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21 21 22 22 22 22 22 22 22 23 23 23 23 23 24 24 24 25 25 25 25 26 26 27 27 27 28 28 28 29 29 29 30 30 30 31 31 31 31 32 32 32 34 36 37 38 39 41 42 43 43
Scuriser : mesures spcifiques 8.1 Scuriser les systmes dexploitation . . . . . . . . . . . . . . . . . . . . . 8.1.1 Installation du systme dexploitation . . . . . . . . . . . . . . . . . . . . . 8.1.2 Conguration du systme dexploitation . . . . . . . . . . . . . . . . . . . . 8.1.3 Anti-virus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.2 Scuriser lenvironnement rseau . . . . . . . . . . . . . . . . . . . . . . . 8.2.1 Adapter et contrler la conguration du pare-feu . . . . . . . . . . . . . . . 8.3 Scuriser le serveur Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.3.1 Mesures gnriques de scurisation dun serveur Web . . . . . . . . . . . . . 8.3.1.1 Gestion des utilisateurs . . . . . . . . . . . . . . . . . . . . . . . . 8.3.1.2 Procdures de validation des modications ou mises jour . . . . 8.3.1.3 Procdures de mise jour du contenu du site . . . . . . . . . . . . 8.3.1.4 Restrictions de droits . . . . . . . . . . . . . . . . . . . . . . . . . 8.3.1.5 Organisation adquate du contenu . . . . . . . . . . . . . . . . . . 8.3.1.6 Activation du chirement SSL . . . . . . . . . . . . . . . . . . . . 8.3.1.7 Banalisation du serveur . . . . . . . . . . . . . . . . . . . . . . . . 8.3.1.8 Limitation des fonctionnalits du site au stricte ncessaire . . . . . 8.3.1.9 Scurisation de ladministration distance . . . . . . . . . . . . . 8.3.2 Scuriser le serveur IIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.3.2.1 Limiter linstallation au minimum de services . . . . . . . . . . . . 8.3.2.2 Mthode dauthentication . . . . . . . . . . . . . . . . . . . . . . 8.3.2.3 Positionner les droits sur les rpertoires virtuels du serveur . . . . 8.3.2.4 Dnir les droits sur les chiers journaux . . . . . . . . . . . . . . 8.3.2.5 Activer et congurer les journaux du serveur Web . . . . . . . . . 8.3.2.6 Restriction daccs par adresses IP ou nom DNS . . . . . . . . . . 8.3.2.7 Supprimer les tiers de conance de la conguration Internet . . . 8.3.2.8 Les pages denregistrement de Certicate Server . . . . . . . . . . 8.3.2.9 Le service dindexation . . . . . . . . . . . . . . . . . . . . . . . . 8.3.2.10 Supprimer toutes les documentations, pages et applications dexemples 8.3.2.11 Supprimer tous les liaisons inutiles . . . . . . . . . . . . . . . . . . 8.3.2.12 Supprimer le support RDS . . . . . . . . . . . . . . . . . . . . . . 8.3.2.13 Contrle du contenu des champs de formulaire . . . . . . . . . . . 8.3.2.14 Dsactiver lachage de contenu de rpertoire . . . . . . . . . . . 8.3.2.15 Editer toutes les pages derreurs . . . . . . . . . . . . . . . . . . . 8.3.2.16 Invalider lutilisation du rpertoire parent . . . . . . . . . . . . . . 8.3.2.17 Dsactiver lappel au shell de commande avec #exec . . . . . . . . 8.3.2.18 Dsactiver ladresse IP dans lentte (Content-Location) . . . . . . 8.3.2.19 Mettre en place un ltrage des requtes, scurisation globale dIIS 8.3.3 Scuriser le serveur Apache . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.3.3.1 Les utilisateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.3.3.2 Les chiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.3.3.3 Modication des droits par les rdacteurs : le chier .htaccess . . . 8.3.3.4 Dmarrer le service . . . . . . . . . . . . . . . . . . . . . . . . . . 8.3.3.5 Suppression des traces permettant didentier le serveur Apache . 8.3.3.6 Les modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.3.3.7 Les CGI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.3.3.8 Les liens symboliques . . . . . . . . . . . . . . . . . . . . . . . . . Maintenir le niveau de scurit : mesures gnrales 9.1 Rgles dexploitation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Page 4 sur 47
9.1.1 Gestion des correctifs de scurit (serveurs et clients) . 9.1.2 Ralisation de ches rexes pour grer les alertes . . 9.1.3 Formation . . . . . . . . . . . . . . . . . . . . . . . . . 9.1.4 Gestion des comptes et des mots de passe . . . . . . . 9.1.5 Serveur de secours et de test . . . . . . . . . . . . . . 9.1.6 Gestion des sauvegardes . . . . . . . . . . . . . . . . . 9.1.7 Gestion des lments temporaires . . . . . . . . . . . . 9.2 Mise jour de la PSSI . . . . . . . . . . . . . . . . . . 9.3 Audits de scurit . . . . . . . . . . . . . . . . . . . . . 10
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
43 43 43 43 44 44 44 44 44 45 45 45 45 46 47
Maintenir le niveau de scurit : mesures spcifiques 10.1 Exploitation des journaux . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.2 Raliser une veille technologique sur les lments du rseau . . . . . . 10.3 Autres paragraphes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Glossaire Index
Page 5 sur 47
Table des figures

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 analyse de /etc/passwd . . . . . . . . . . . . . . . . . . . . . . analyse de /etc/group . . . . . . . . . . . . . . . . . . . . . . . rsultat de la commande PS (serveur Web dmarrer) . . . . . . analyse de /etc/shadow . . . . . . . . . . . . . . . . . . . . . . Droits sur le chier httpd.conf et le rpertoire apache . . . . . . Conguration dans httpd.conf du nom du chier de rednition Choix du rpertoire contenant les donnes du serveur Web. . . Droits sur les chiers et repertoires du serveur Web. . . . . . . Choix du rpertoire contenant les CGI. . . . . . . . . . . . . . . Droits daccs aux CGI. . . . . . . . . . . . . . . . . . . . . . . Balise de journalisation . . . . . . . . . . . . . . . . . . . . . . Droits daccs aux journaux . . . . . . . . . . . . . . . . . . . . Protection des chiers en .ht . . . . . . . . . . . . . . . . . . . dnition du type de serveur . . . . . . . . . . . . . . . . . . . Message derreur par dfaut dun serveur Apache . . . . . . . . Modication des traces . . . . . . . . . . . . . . . . . . . . . . . Traces obtenues par telnet . . . . . . . . . . . . . . . . . . . . . Exemple dindex cr automatiquement par Apache . . . . . . rsultat de la requte http ://127.0.0.1/server-status . . . . . . Exemple daccs un rpertoire partag . . . . . . . . . . . . . Exemple de conguration de CGI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . des droits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 33 33 33 34 34 34 35 35 36 36 36 37 38 38 38 38 39 40 41 42
Page 6 sur 47
1
1.1
Introduction
Objectifs des recommandations
Ce guide a pour vocation daider scuriser le serveur Web laide de recommandations bases sur ltat de lart.
1.2
qui sont destines ces recommandations
Ces recommandations sont destines principalement aux administrateurs, responsables de la scurit des systmes dinformation et en gnral toute personne ou organisation voulant scuriser ou vrier la scurisation du serveur Web. En particulier ce guide nest pas un guide dadministration du serveur Web.
1.3
Structure de ce document
Ce document est scind en plusieurs parties : Partie 1 : introduction gnrale aux recommandations ; Partie 2 : mise en garde sur lapplication de ces recommandations ; Partie ?? : relev non exhaustif des principales vulnrabilits lies au serveur Web ; Partie 5 : rappel non technique sur lorganisation de la scurit dun systme dinformation ; Partie 6 : rappel des principes fondamentaux de la scurit dun systme dinformation ; Partie 7 : recommandations gnrales sur la scurisation dun systme dinformation et de serveurs ; Partie ?? : recommandations spciques la scurisation du serveur Web ne mettre en oeuvre quune fois, linstallation du systme ou lors de la premire mise en application de ce document ; Partie 9 : recommandations gnrales sur les oprations mener pour conserver un bon niveau de scurisation dans le temps ; Partie ?? : recommandations sur les oprations spciques au serveur Web destines conserver un bon niveau de scurisation dans le temps ; Partie ?? : lments techniques complmentaires, comme des listes de contrle.
1.4
Prsentation des recommandations
Les recommandations de scurisation sont scindes en deux phases : Scuriser (Partie 7 et Partie ??) : recommandations mettre en uvre une seule fois, linstallation du systme ou lors de la premire mise en application de ce document ; Maintenir la scurit (Partie 9 et Partie ??) : recommandations suivre tout au long de la vie du serveur Web pour sassurer que le niveau de scurit reste constant dans le temps. De plus, chacune de ces phases contient deux parties, ddies aux mesures gnrales et aux mesures spciques participant lobjectif nal.
Page 7 sur 47
Avertissements
La responsabilit du choix et de la mise en oeuvre des recommandations proposes dans ce document incombe au lecteur de ce guide. Il pourra sappuyer sur la politique de scurit du systme dinformation et sur les rsultats dune analyse des risques de la scurit des systmes dinformation pour dterminer les recommandations les plus pertinentes. Le lecteur devra galement raliser des tests exhaustifs an de vrier ladquation de ces recommandations avec son contexte particulier. Vu la nature volutive des systmes dinformation et des menaces portant sur ceux-ci, ce document prsente un savoir-faire un instant donn et a pour ambition dtre rgulirement amlior et complt. Vos commentaires sont les bienvenus. Vous pouvez les adresser ladresse postale suivante : Bureau Audits en SSI SGDN/DCSSI/SDO/BAS 51, boulevard de la Tour-Maubourg 75700 Paris 07 SP
Page 8 sur 47
Pr-requis
Ce guide sattache, de manire gnrique, la scurisation dun serveur Web indpendamment du systme ou type de serveur choisi. Cependant des informations dtailles seront donnes pour un serveur Apache sous Linux, ainsi que pour Internet Information Server 4.0 ou 5.0 (NT4 ou Windows 2000).
3.1
Connaissances ncessaires
Une bonne connaissance du systme dexploitation, du serveur Web et de leurs modes de conguration sont ncessaires pour lapplication des recommandations dtailles. Une connaissance du protocole HTTP1 est un plus.
3.2
Dnition des rles et tches
Pour lensemble de ce document nous considrerons une organisation qui semble adapte la gestion dun projet de serveur Web. Les dirents postes devraient tre les suivants : Administrateur systme : Le terme administrateur systme dsigne le responsable systme charg de la conguration et administration de la machine et du systme dexploitation sur lequel le serveur Web est install. Ce guide lui est destin pour tout ce qui concerne la conguration du systme hte ainsi que la dnition des droits des utilisateurs sur le systme et les rpertoires. Ladministrateur systme veille la qualit de service et la mise jour du systme. Cest par exemple lui qui contrlera les journaux systme ; Administrateur Web (Webmaster) : Il est responsable de la conguration du service Web. Il travaille le plus souvent en collaboration avec ladministrateur systme. L administrateur Web a la charge de dnir et congurer les services Web, compilateurs et autres modules ncessaires sur la plate-forme. Aprs sa validation il met jour le contenu du site Web. Il veille la qualit de service et la mise jour du service Web et des ventuels modules complmentaires lis au site. Cest par exemple lui qui contrlera les journaux du service Web, ditera les statistiques de consultation etc. ; diteurs : Le terme diteur regroupe lensemble des personnes qui participent la conception du site (programmeurs, dveloppeurs, auteurs, graphistes etc.). Ces personnes ne devraient normalement disposer daucun accs sur le serveur nal et travaillent sur un serveur de test. Une fois le contenu du site valid, ladministrateur Web sera charg de publier les modications sur le site dexploitation ; Visiteur : Les visiteurs sont les utilisateurs du site Web. Ils naviguent sur le site de manire anonyme le plus souvent. Ce guide intresse principalement les administrateurs systme et administrateurs Web.
1 Hyper
Text Transfer Protocol RFC 2068
Page 9 sur 47
Principaux risques du serveur Web

Ce chapitre prsente les principaux risques et leurs consquences.
4.1
Modication de contenu
Un serveur mal scuris peut permettre la suppression, lajout ou la modication des donnes hberges sur le serveur. Il en rsulte une atteinte limage de marque de lentit, de la dsinformation, etc.
4.2
Arrt ou dysfonctionnement du service Web
Une des attaques principales contre le serveur est le dni de service. Saturer le serveur de requtes, arrter le service, bloquer les ports etc. sont autant de mthodes empchant le serveur de remplir ses fonctions. Il en rsulte souvent une atteinte limage de marque et la crdibilit de lentit. Les consquences sont dautant plus importantes que le serveur propose un service ou des informations consults rgulirement par un grand nombre de personnes.
4.3
Rvlation dinformation
Un serveur Web mal congur et trop bavard peut rvler des informations sur le systme lhbergeant et ainsi faciliter son attaque. Lintroduction de virus, vers et autres programmes malveillants sur la machine peuvent avoir des consquences physiques sur la machine (destruction de disques durs, eacement du systme,...).
4.4
Servir de base dattaque
Une compromission de la machine peut la transformer en plate-forme de rebond pour une autre attaque sur les rseaux interne ou externe. Une plate-forme de rebond ore deux avantages aux agresseurs, rendre la tache des enquteurs plus dicile si la machine compromise sert attaquer un autre site sur lInternet, ou, utiliser la machine compromise comme passerelle dattaque vers le resau interne de lentreprise. Un serveur situ en DMZ peut, par exemple, disposer de droits suprieurs sur lintranet par rapport aux machines situes sur linternet. Prendre le contrle de ce serveur permettra donc un attaquant potentiel de rebondir et attaquer le rseau interne, voire dutiliser le serveur pour attaquer dautres serveurs sur internet en cachant ainsi son adresse. Il ne faut pas oublier que dans un tel cas vous pouvez tre responsables des actions faites depuis votre machine.
Page 10 sur 47
Politique gnrale de la scurit des systmes dinformation
Un document, la politique de scurit dun SI (Systme dInformation) doit exister au sein de lorganisme mettant en uvre le SI. Parmi les rgles relatives la scurisation du serveur Web prsentes dans la PSSI, on doit retrouver au moins les lments ci-dessous : la fonctionnalit du composant au sein du SI ; la liste des comptes dadministration ainsi que les modalits de gestion de ces comptes dans le temps ; la liste des ux entrants/sortants vers/depuis le composant ; la liste des services lancs au dmarrage ; la liste des services audits et leurs chiers ; le suivi des mises jour des versions des logiciels utiliss ; une copie des chiers de conguration de tous les services et des chiers de dmarrage ; les mesures de scurit physique mises en place ; la liste des correctifs et des modications ralises sur le composant ; les oprations dexploitation mettre en uvre sur le composant. Les recommandations nonces dans tout ce document devraient galement trouver leur place dans les rgles de cette PSSI. Le lecteur pourra se reporter au document dit par la DCSSI Guide pour llaboration dune Politique de Scurit Interne (disponible sur le site internet de la DCSSI, www.ssi.gouv.fr) pour plus dinformations sur ltablissement dune PSSI.
Page 11 sur 47
6
6.1
Principes fondamentaux de la SSI

Dvelopper et implmenter une dfense en profondeur
Le principe de la dfense en profondeur est de multiplier les protections dune ressource (information, composant, service. . .), tous les niveaux o il est possible dagir. Ainsi, un agresseur devra passer outre plusieurs protections, de nature et de porte direntes, avant daccder la ressource. Ce principe doit tre appliqu tous les stades de la scurisation dune ressource quelle quen soit sa nature : une donne, une application, un systme, un rseau, voire mme le local hbergeant le systme dinformation. 6.1.1 La scurit des locaux et la sret de fonctionnement
Ce document na pas pour objectif de dtailler les mesures de scurit physique mettre en uvre pour lexploitation de systmes dinformations sensibles, les principaux points techniques ncessaires seront ici abords sous langle de leur scurisation, sans entrer dans le dtail technique de leur mise en uvre. En particulier, les dirents lots techniques, au sens btimentaire (incendie, climatisation, . . .) possdent un grand nombre de contraintes techniques, rglementaires, lgales ainsi que des interrelations qui ne seront pas dtailles dans ce document. Les rgles essentielles de scurit physique prendre en compte dans la conception ou lamnagement de locaux, en vue de linstallation de systmes dinformation plus ou moins complexes et sensibles, recouvrent plusieurs lments de nature dirente mais interdpendants. Ces rgles appliquer sur tout ou partie de ces lments doivent sinscrire en amont de toute autres actions, dont lobjectif est de garantir en premire instance, laccs physique, lintgrit et la disponibilit dun systme dinformation et de ses donnes. Les situations gographiques, les implantations et les natures des constructions et des quipements dun site sont importantes au regard des risques naturels, de lenvironnement et des techniques mises en uvre. On sattachera donc examiner les points suivants : Lenvironnement : La typologie des sols, magntisme naturel, nappes phratiques, rsistance aux eondrements, . . . ; Les zones inondables, lindice kraunique du lieu (impacts de foudre), les prcipitations, vents dominants (par rapport au voisinage pour les prises daration), . . . ; Lexistence de voies daccs au site et leur praticabilit ainsi que les dessertes V.R.D. (Viabilisation des Rseaux de Distribution) ; La nature de limplantation (zones urbaines, industrielles, . . .), la prise en compte du POS (Plan dOccupation des Sols) pour lemprise et les extensions btimentaires futures, la nature du voisinage (prsence, dindustries chimiques pouvant induire des pollutions importantes, daroports (crash), voies autoroutires ou transports suburbains (vibrations)), . . . ; Lemprise et les btiments : Lemprise avec son plan de masse indiquant la position, le type et la nature des cltures, les voies internes de circulation, les diverses accessibilits, lespace rserv aux parkings (personnels, visiteurs), . . . ; Le gros uvre, le type et la nature des btiments et des toitures (rsistance aux charges rsultantes des prcipitations et jets dobjets, . . .), coulements des eaux uses et pluviales, positionnement des diverses canalisations , . . . ; Les lots de second uvre et rpartitions des locaux, type et nature des cloisonnements, modularit, rpartition relative, issues (vitrages, portes, . . .), . . . ; Les lots techniques, gnralits (nergie, ventilation, climatisation, dtection/extinction incendie, . . .), implantation (usage ddi), type, nature, redondance (secours), renvois dalarmes sur dfaillance.
Page 12 sur 47
6.1.1.1
Ce quil faut prendre en compte prioritairement sur les lots techniques
Avant tout, les locaux accueillants les lots techniques doivent tre ddis, laccs ces derniers ou directement aux composants, ne doivent tre accessibles que par des personnels qualis, internes ou externes (maintenance), en rgime restrictif et contrls an dabaisser les risques potentiels (malveillances, fausses manuvres, . . .). Les agressions ou dfaillances sur des lments connexes au systme dinformation peuvent concourir son indisponibilit totale ou partielle. Pour cela, il y a ncessit de vrier les points suivants : 6.1.1.1.1 nergie lectrique
Le local accueillant le poste de transformation MT/BT (Moyenne Tension/Basse Tension) doit, si possible, tre implant sur le site tout en laissant un accs, sous contrle, au fournisseur (tte de cble). De mme, la dernire chambre de tirage avant transformation devra se situer sur le site. Dans le cas ou une seconde arrive serait mise place (secours), il sera ncessaire de ngocier avec le fournisseur un tirage de ligne, pour ce qui est hors site, empruntant un chemin physique dirent et venant dune sous station dirente ; Le TGBT (Tableau Gnral Basse Tension) lment sensible de la premire rpartition de lnergie au sein du site, fera lobjet dune attention dans sa localisation et son accessibilit. Par ailleurs, les locaux (ex : PABX (autocommutateur tlphonique), conception ancienne donduleurs, . . .) renfermant des batteries et dont la composition est base dacide, doivent tre ddis et isols physiquement des matriels auxquels il sont raccords. Ces locaux seront munis dune ventilation mcanique et amnags lectriquement en antidagrant. On vriera que les terres et masses (btiments, vrins supportant les faux planchers, matriels informatiques, PABX, . . .) sont conformes la rglementation (ex : terres informatiques < ou = 1 Ohm, . . .). Dans la mme optique, on sassurera que les divers revtements de sols ou muraux sont anti-statiques. On veillera ce que les divers ensembles lectriques primaires soient munis de parasurtenseurs ou parafoudre an de limiter les risques krauniques sur les matriels pouvant se rvler sensibles aux variations induites sur les dirents rseaux (PABX, serveurs, . . .). 6.1.1.1.2 Secours nergie lectrique
Selon limportance du site (au regard de son infrastructure et de ses installations), un secours par groupe lectrogne ddi ou partag peut tre envisag. Sa localisation est des plus importantes. En eet, on peut tre confront des problmes relatifs aux vibrations, ainsi quaux coups de blier ds aux ondes stationnaires (longueurs des tubes dchappements des gaz) si ce dernier se trouve en sous-sol ou rez-de-chausse. Par ailleurs, il faudra sassurer de la prsence dun bac de rtention de capacit suprieure celle de la cuve fuel de dmarrage avec une vacuation conforme lantipollution. Lensemble des matriels formant le systme dinformation (serveurs, terminaux, imprimantes, . . .) doivent tre raccords sur un circuit ondul (rgulation) avec une disponibilit dun minimum de 1/4 dheure an de permettre une extinction propre des systmes. ce sujet, limplantation de londuleur (intermdiaire tampon, en cas de rupture dnergie, entre le fournisseur dnergie et le dmarrage du groupe lectrogne) ainsi que ses caractristiques intrinsques, seront tudis de manire ce que toute extension de matriels rclamant une nergie ondule soit possible. Il est noter que pour ce qui concerne les PABX, le maintien des batteries en tampon doit tre au minimum de lordre de 48 heures. 6.1.1.1.3 Climatisations et ventilations
Les climatisations, quelles soient autonomes ou centralises, associes aux ventilations sont des lments dont limportance est vitale pour la vie des matriels (serveurs, PABX, ..) par nature
Page 13 sur 47
fortement exothermiques. En eet, elles permettent de les rguler en temprature et hygromtrie vitant ainsi les surchaues et diminuant par voie de consquence le risque incendie. On prendra soin pour les climatisations de relever le type, la nature, et la puissance de dissipation frigorique. Lexistence dune redondance, an dassurer une forte disponibilit, est fortement conseille. Pour produire du froid, llment rfrigrant doit tre compress partir de compresseurs euxmmes devant tre refroidis. Pour cela, des changeurs thermiques (arothermes) protgs en malveillance (blocage volontaire des pales de ventilation) devront tre installs et disposs de manire ce quils ne causent aucune nuisance sonore (vitesse des pales provocants des siements) ni vibratoire. Les VMC (Ventilation Mcanique Centralis) seront judicieusement positionnes en particulier les prises daration (au regard des pollutions de lenvironnement et des vents dominants). Les direntes conductions de ventilation (gaines, faux planchers/plafonds..) et les reprises dair doivent tre vries au moins une fois lan et les ltres changs selon lenvironnement deux quatre fois par an. Lensemble climatisation/ventilation se doit dtre asservi en arrt sur une dtection conrme dincendie, an de ne pas devenir un vecteur de propagation. 6.1.1.1.4 Incendie
Indpendamment des obligations lgales (IGH, (Immeubles de Grande Hauteur) . . .), il est ncessaire que les locaux accueillants les matriels du systme dinformation ou y contribuant (onduleurs, cellules climatisation, nergie, . . .) soient protgs contre lincendie. cet gard, on choisira la nature (ammes, tempratures, fumes, . . .) et le type de la dtection (statique, direntiel, vlocimtrique, . . .) an de lapproprier au risque le plus probable (une solution mixte peut tre envisage). Des solutions, manuelles (extincteurs appropris) ou automatiques (gaz non halogns, eau pulvrise, . . .), dextinction sont mettre en uvre pour complter et agir rapidement sur lextinction dun incendie. Les locaux ainsi que les gaines de ventilation, faux planchers/plafonds devront priodiquement faire lobjet dun dpoussirage an dviter ce vecteur complmentaire dincendie. Des alarmes sonores et lumineuses locales avec renvoi vers un poste de surveillance devront accompagner lactivation de ces dtections. On relvera la prsence des dlments combustibles (revtement des parois, , . . .), lieux de stockage (papier, . . .), disposition relative des locaux, an dagir sur ces lments pour abaisser le risque dincendie. Enn, il est indispensable davoir disposition des procdures et des consignes relatives lincendie tant en prvention quen action. 6.1.1.1.5 Dgts des eaux
Les locaux revtant un caractre sensible au regard du systme dinformation ou contribuant sa disponibilit doivent tre protgs contre le dgt des eaux (inondations, rupture de canalisation, . . .). Si en terme de condentialit le positionnement en sous-sols semble remporter la faveur, il est indispensable que ces locaux soient dots de faux planchers munis de dtecteurs dhumidit coupls des pompes de relevage et rendus tanches au regard des tages suprieurs, ou sinscrire dans des units totalement cuveles. 6.1.1.1.6 Contrles des accs anti-intrusion
Dans le cadre gnral, un premier niveau de contrle daccs (niveau de lenceinte du site), ainsi quun second niveau (accs aux btiments), doivent tre installs sparment ou confondus selon la nature du site, leur nature (contrle humain, lectronique, mixte...) et leur type (contrle visuel, portiques, badges, cartes lectronique...). Pour les locaux sensibles (serveurs, PABX, ...), un contrle daccs dans un rgime restrictif quel quen soit le type et la nature sera indpendant ou intgr aux autres contrles daccs.
Page 14 sur 47
Des systmes anti-intrusion, actifs ou passifs, dirents niveaux (enceinte, btiments, locaux sensibles...) doivent tre mis en uvre. Leur type et leur nature (grillage, barreaux, radars, infrarouge...) doivent tre choisis dune manire cohrente au regard de lenvironnement. Les alarmes, des contrles daccs et des dispositifs anti-intrusion, ainsi que leurs renvois intgrs ou non dans une unit de gestion centralise, doivent imprativement tre complments par des consignes et des procdures. Ces mesures organisationnelles doivent tre cohrentes entre elles ainsi quau regard de leur environnement. Une redondance minimum et une autonomie sont indispensables an de permettre une continuit a tous les niveaux des contrles daccs et des dispositifs anti-intrusion. AVERTISSEMENT Les alarmes techniques et celles concernant les contrles daccs/anti-intrusion sont de natures direntes. On sattachera ce quelles ne soient pas gres par les mmes personnes et quelles ne soient pas techniquement regroupes. 6.1.2 La dfense au niveau du rseau
Il faut comprendre ici la dfense des ux circulant sur le rseau (limiter les ux autoriss, les chirer (contre lcoute et le piratage de session), limiter lutilisation de logiciels dcoute 2 . . .), ainsi que des ux entrants ou sortants du primtre du rseau (mettre en place des moyens de ltrage, limiter les ux autoriss, limiter les connexions non contrles comme les modems). 6.1.2.1 Utilisation de commutateurs
La mise en place dun environnement rseau scuris passe par la mise en uvre de commutateurs bien administrs. En eet si lon se passe de commutateurs 3 et que lon utilise des concentrateurs 4 , tout le trac est dius sur la totalit du rseau local, sans contrle possible par lexpditeur ou le destinataire. Ainsi, si quelquun coute le trac local, il peut recevoir des informations qui ne lui sont pas destines. Lutilisation de commutateurs est dautant plus recommande que la grande majorit des protocoles utiliss par les applications classiques (messagerie lectronique, navigation Web, accs des chiers distants. . .) ne sont pas chirs. Cependant, il faut noter que la protection apporte par un commutateur nest pas parfaite, car sujette des attaques au niveau du protocole de rsolution dadresse (ARP), et doit tre complte par dautres mesures dcoulant du principe de dfense en profondeur. 6.1.2.2 6.1.3 Mise en place doutils de dtection dintrusion La dfense au niveau des htes
Elle consiste durcir le systme dexploitation dun composant, ainsi que ses relations avec les autres composants du SI. 6.1.4 La dfense au niveau des applications
La scurisation dune application sappuie sur des mcanismes propres lapplication, mais aussi sur la scurisation du systme dexploitation sans lequel elle ne peut exister. 6.1.5 La dfense au niveau des donnes
Les donnes, stockes comme transmises, sont particulirement vulnrables (mots de passe, contenu de chiers, de messages lectroniques. . .). Le chirement et/ou des mesures de contrle daccs discrtionnaires permettent de protger les donnes stockes. De mme, des donnes transmises sous forme chire seront moins vulnrables en cas dinterception.
2 galement 3 galement
appels sniers appels switchs 4 galement appels hubs
Page 15 sur 47
6.2
Principe du moindre privilge
Le principe du moindre privilge est de ne permettre que ce qui est strictement ncessaire la ralisation de la fonction recherche. Comme le principe de dfense en profondeur, il se dcline tous les niveaux dun SI. Il se traduit, par exemple, par la limitation des droits accords un utilisateur ceux ncessaires pour remplir sa mission (utilisation du systme, administration, gestion des sauvegardes. . .) et aucun autre.
Page 16 sur 47
7
7.1
Scuriser : mesures gnrales

Relev de conguration
Il est recommand dtablir et de tenir jour un relev de conguration des serveurs en distinguant les dirents types de serveurs et leur localisation dans larchitecture globale du systme dinformation. Pour chacun de ces types, un document dcrira les choix de conguration raliss, et la liste des mesures particulires ces systmes comme, par exemple : les choix raliss lors de linstallation, en terme de partitions, de paramtrages du BIOS. . . les procdures lies lidentication/authentication des utilisateurs et des administrateurs ; la liste des applications installes et leur version ; la liste des services installs, leur proprit (dmarrage automatique, manuel. . .), la liste des services dsinstalls ; le niveau de mise jour appliqu, en dtaillant les mises jour principales, comme les Service Packs de Windows, les correctifs cumulatifs, postrieurs aux Service Packs, tels que les Rollup Patches de Windows et les correctifs individuels, postrieurs aux Rollup Patches, appels Hotxes dans les environnements Windows ; les rgles de contrle daccs aux ressources, et les droits positionns sur les cls de registre, rpertoires et chiers ; les rgles daudit et de journalisation ; les mesures de chirement et dempreintes des chiers critiques contenus sur les serveurs. Les aspects lis lorganisation doivent galement tre dcrits. Ce document devra en particulier tre utilis pour toute nouvelle installation de serveurs de mme type. Un volet exploitation devra prciser les tches lies la scurit devant tre assures. On pourra pour cela sinspirer de la structure du prsent document. Lobjectif de ce document est multiple : assurer une continuit de service en cas dabsence de ladministrateur charg de linstallation du systme ; faciliter la constitution dannexes techniques la PSSI ; savoir sur quels composants assurer une veille technologique. Ce relev de conguration papier du serveur contient des informations permettant daccder aux paramtrages du serveur, didentier les versions du systme, des applications, des services, etc. Il doit donc tre identi comme condentiel et stock dans un endroit protg (local ferm cl par exemple). Dune faon pratique, ce relev de conguration peut tre constitu en consignant les choix raliss lors de lapplication des direntes parties de ce document. Ce relev devra bien videment faire lobjet de mises jour aussi souvent que ncessaire, comme indiqu au paragraphe 9.1.1 page 43.
7.2
7.2.1
Pralables de linstallation
Vrication du systme sous-jacent
Avant toute installation dun logiciel, il convient de vrier que le systme, au sens large (systme dexploitation ou applicatif) a t install dans les mmes conditions que celles dcrites ultrieurement et quil a fait lobjet dune scurisation en se rfrant, par exemple, au guide DCSSI ad hoc. Cette partie complte les pr-requis voqus au dbut de ce document, partie ??. Dautre part, le systme devrait tre install partir dune nouvelle version, et il ne devrait pas tre install partir dune mise jour dune ancienne version.
Page 17 sur 47
7.2.2
Version du serveur Web installer
Il pourrait paratre naturel dinstaller la version franaise du serveur Web. Cependant, un des principes de base de la scurisation est de maintenir le serveur Web au dernier niveau de mise jour disponible. Sachant que lexprience montre quil existe un dcalage de plusieurs jours, voire plusieurs semaines, entre la publication du correctif dans le langage de lditeur et leur version francise, il est recommand dinstaller le serveur Web dans sa version originale, trs souvent en amricain ou en anglais, plutt que sa version francise. 7.2.3 Vrication des sources dinstallation
Lors de linstallation dun lment logiciel (systme dexploitation ou applicatif) sur une machine, plusieurs mthodes sont disponibles : installation depuis un mdia physique commercial (disquette, CD-ROM, . . .) ; installation partir dune archive pralablement tlcharge sur un rseau externe lentit ; installation directe au travers dun rseau externe lentit. 7.2.3.1 Mdia physique
Il sagit certainement du mode dinstallation le plus sr bien quun certain nombre de prcautions restent ncessaires. Il convient tout dabord de sassurer que le mdia propos nest pas une contrefaon mais quil mane bien directement de lditeur. Ensuite, il convient dexaminer le contenu de ce mdia avec un anti-virus et ce quelque soit sa provenance. En eet, il se peut que des personnes indlicates aient introduit des programmes malicieux (virus, chevaux de Troie, etc. . .) au cours du processus dlaboration du mdia. Si les chiers prsents sur le mdia ont fait lobjet dune signature numrique par lditeur, il convient de vrier la validit de cette signature en utilisant la cl publique de lditeur et les outils adquats. Ceci ne constitue cependant pas une preuve irrfutable de lexemption de contenu malicieux qui aurait pu tre introduit linsu de lditeur avant quil ne signe le contenu du mdia. De plus, la signature lectronique ne peut qutre un lment de preuve de lidentit de lmetteur suivant de nombreux paramtres (dispositif cryptographique employ, mode de rcupration de la cl publique, soin apport par lditeur dans la gestion de ses cls prives, etc. . .). Il convient donc de bien comprendre les ventuels mcanismes cryptographiques mis en jeu avant de donner une conance aveugle une signature lectronique. 7.2.3.2 Installation dun applicatif tlcharg
La problmatique reste la mme que pour un support physique. Il convient toujours deectuer une analyse antivirale avant installation. Le problme supplmentaire pos ici rside dans le mode de rcupration des sources qui ne peut tre considr comme sr. Les mcanismes cryptographiques peuvent permettre de scuriser ce canal de rcupration mais certains problmes peuvent subsister. On pourra se rfrer la note dinformation n CERTA-2001-INF-004 mise par le CERTA traitant du sujet Acquisition des correctifs dont la problmatique est proche. 7.2.3.3 Installation directe depuis un rseau externe
Cette approche est proscrire absolument car il ne vous est laiss aucune possibilit de personnaliser le processus de vrication des sources avant installation si ce processus existe. Il convient donc de sparer ces deux tches dautant plus que linstallation directe depuis Internet suppose que vous interconnectiez une machine que vous navez pas encore scuris ce qui serait une grave erreur.
Page 18 sur 47
7.3
Installation
Dans la mesure du possible, un serveur devrait tre ddi une seule fonction (par exemple, la messagerie). Le principe de moindre privilge (cf. 6.2) doit guider toute installation. Il se traduit par la limitation des fonctionnalits et des services installs au strict minimum requis par la fonction du serveur. Il sagit de limiter les vulnrabilits potentielles qui peuvent apparatre dans les applications, les services, les options systme, les couches rseau. . . Aprs avoir install le systme, il est ncessaire dappliquer les derniers correctifs fournis par lditeur. Toutefois la mise en place de tels correctifs ncessite toujours une vrication pralable de leur bon fonctionnement sur le serveur de test an dviter dventuels eets de bords des mises jour, observs le plus souvent au niveau des applicatifs. Ladresse internet suivante permet daccder aux articles dits par Microsoft sur la parution de nouveaux correctifs : http://www.microsoft.com/TechNet/security/default.asp Microsoft met la disposition du public un outil permettant de contrler la mise jour du systme : hfnetchk.exe (Hotx Network Checker). Cet outil excut en ligne de commande sur le serveur avec les droits administrateur contrle lensemble des mises jour appliques au systme et aux applicatifs principaux de Windows, comme Internet Explorer, Outlook. . .. Il ncessite de disposer dune base de signatures jour. Il est donc recommand de lancer tout dabord loutil sur une machine connecte Internet an quil tlcharge la dernire base de signatures, puis de transfrer loutil et sa base sur le serveur. Microsoft propose galement un second outil MBSA (Microsoft Baseline Security Analyser), graphique, qui reprend les fonctions de hfnetchk.exe v3.81, et qui eectue des tests complmentaires sur le systme, comme la vrication du nombre de comptes administrateur prsents sur la machine, lexistence de leur mot de passe, ainsi que sur les applicatifs suivants : Internet Information Server (IIS 4.0 et 5.0), serveur Microsoft SQL (7.0 et 2000), serveur Exchange (5.5 et 2000), Windows MediaPlayer (6.4 et postrieurs), et Internet Explorer (5.01 et postrieurs). Ces deux outils permettent donc didentier les mises jour qui nont pas t appliques pour ensuite y remdier. MBSA permet en outre didentier des vulnrabilits critiques du systme dexploitation et des principales applications dites par Microsoft. Enn, il est ncessaire de crer une disquette de dmarrage Windows, une disquette de rparation durgence (ERD), et de conserver tous ces mdias dinstallation dans un lieu protg.
7.4
Emploi de mots de passe complexes
Les mots de passe sont souvent la seule et unique protection dun systme dinformation contre lintrusion logique. Une bonne politique de choix et de gestion des mots de passe est donc le passage oblig pour scuriser une machine, voire un systme dinformation tout entier. An dtre robuste aux attaques, un mot de passe doit tre complexe. Si lenvironnement dans lequel il est utilis le permet, un mot de passe complexe doit avoir les proprits suivantes : il se compose dun nombre susant de caractres : au moins sept pour un utilisateur et plus de quatorze pour un administrateur pour les environnements sous Windows, huit caractres pour les systmes de type Unix/Linux ; il comporte au moins un caractre de chaque catgorie : caractre alphabtique minuscule ; caractre alphabtique majuscule ; chire ; caractre spcial (disponible sur le clavier, hors des trois premires catgorie). Pour un scuriser un compte avec des privilges tendus sur une application, sur un systme ou sur un composant (compte administrateur, communaut SNMP avec droits en criture. . .), on peut galement envisager lutilisation dun caractre ASCII non imprimable, obtenu en appuyant sur ALT et NB, o NB est un nombre compris entre 1 et 255 pour les environnements Windows.
Page 19 sur 47
il nexiste dans aucune langue ni aucun dictionnaire ; il est remis dans une enveloppe cachete locier de scurit qui la stocke dans un lieu adquat. Lutilisation de tels mots de passe ne saurait tre ecace sans une complte acceptation par les utilisateurs et les administrateurs des contraintes associes. En eet, il est primordial de sensibiliser et dinformer les utilisateurs aux risques lis lutilisation hasardeuse des mots de passe : mots de passe triviaux ; mots de passe partags entre plusieurs utilisateurs ; mme mot de passe utilis pour scuriser laccs deux ressources direntes. Cette pratique est particulirement dangereuse lorsque un mme mot de passe est utilis dans une application qui le transmet en clair sur le rseau (par exemple, la messagerie lectronique), o il peut tre facilement cout, et comme authentication dune ressource critique (par exemple, lauthentication systme). puis de les former des comportements scuriss. Ainsi, on peut aider les utilisateurs choisir un mot de passe complexe, en utilisant par exemple des aides mnmotechniques, expliquer la ncessit dun changement rgulier des mots de passe, sensibiliser leur condentialit (ne pas partager son mot de passe avec dautres utilisateurs, ne pas communiquer son mot de passe sauf locier de scurit, etc. . .). In ne, les utilisateurs doivent pouvoir choisir des mots de passe mmorisables ou pouvant tre regnrs simplement chaque utilisation. Dans le cas inverse, cette protection sera rendue inecace par des comportements inadapts (mots de passe marqus sur un post-it. . .). Enn, une recrudesence dutilisateurs ayant bloqu leur compte ou ne se souvenant plus de leur mot de passe doit tre perue positivement, comme la manifestation de leort quils font pour choisir des mots de passe complexes. Il convient galement de garder lesprit les solutions techniques existantes pour se passer des contraintes inhrentes aux mots de passe : utilisation de systmes didentication et dauthentication forte (carte puce, cl USB, biomtrie, etc. . .), allis des dispositifs dits Single Sign On , cest--dire permettant une identication et authentication forte unique pour toute une session (connexion une machine, accs des ressources locales ou distantes. . .).
7.5
7.5.1
Administration du systme
Administration locale
Il est recommand dadministrer un serveur localement, cest dire partir de sa console. Pour ces activits, ladministrateur utilisera ponctuellement un compte ddi avec les privilges adquats. Pour les tches ne ncessitant pas de tels privilges, ladministrateur prendra soin dutiliser un autre compte, avec des droits restreints. 7.5.2 Administration distante
Nanmoins, si une administration distante du serveur est requise, elle ne devrait pas pouvoir tre ralise depuis nimporte quel poste du rseau interne. Il est donc ncessaire de limiter cette fonctionnalit aux seuls postes des administrateurs, en particulier au niveau de leur adresse IP. Toutefois, lutilisation de stations dans un rle dadministration impose que le niveau de scurisation de la station dadministration distance soit au moins quivalent celui du serveur (scurit physique et logique). Sil est ncessaire de se connecter travers le rseau sur le serveur, il est prfrable dutiliser des outils dadministration chirs, fournis avec le systme ou tiers en raison des possibilits dcoute. 7.5.2.1 Terminal Services
Une solution est dutiliser un client Terminal Services pour se connecter distance sur le serveur administrer, si celui-ci met en uvre un systme dexploitation de la famille Windows. Il existe de tels clients pour un grand nombre de systmes dexploitation, mme non Windows. Un administrateur peut donc grer un serveur distance. Il est recommand dutiliser les fonctions de chirement
Page 20 sur 47
oertes par le composant Terminal Services (chirement lev ), an de protger les donnes circulant sur le rseau. Si le service Terminal Services Web est utilis sur le serveur, on prendra soin de modier la page web par dfaut (/TSWeb/default.htm). Attention toutefois, car ce service requiert linstallation dun serveur web, ce qui augmente sensiblement la charge dadministration et de scurisation du Terminal Services Web. Le seul moyen didentication et dauthentication tant ici la fourniture dun nom dutilisateur et dun mot de passe, il est particulirement important que celui-ci soit complexe. 7.5.2.2 SNMP
SNMP est une couche rseau connue pour ses failles intrinsques. Elle ne devrait pas tre active ou dfaut ne pas tre accessible depuis un rseau non sr. Si SNMP est active, les noms de communaut utiliss ne doivent pas tre triviaux (public, private, nom_dentit, etc. . .) et rpondre aux mmes contraintes de complexit que les mots de passe (cf. 7.4). 7.5.2.3 Tlmaintenance
Si elle existe, la liaison de tlmaintenance du serveur ne devrait pas tre active en permanence. Le modem donnant accs cette fonctionnalit devrait tre dbranch en fonctionnement normal. Il ne devrait tre rebranch que lorsquune tlmaintenance est ncessaire, et aprs que la demande en ait t faite par un intervenant identi. Plusieurs mcanismes de scurisation du modem peuvent tre mis en place : modem acceptant des mthodes dauthentications fortes ; modem assurant un rappel automatique dun numro pr-dni (call-back) ; modem acceptant le chirement. Il est recommand dutiliser ces trois mcanismes conjointement. Si tout ou partie de la tlmaintenance est ralise par des prestataires externes, il convient dimposer des rgles trs strictes de gestion des moyens didentication/authentication, et de contrle du personnel en charge de la prestation. En particulier, les mots de passe ne devraient pas tre triviaux, ni partags entre les dirents intervenants du prestataire et changs rgulirement, mme si cela peut tre lourd grer par le prestataire.
Page 21 sur 47
8
8.1
Scuriser : mesures spcifiques

Scuriser les systmes dexploitation
Les informations dcrites dans ce chapitre sont absolument ncessaires une bonne scurisation du serveur mais elles ne susent pas congurer correctement le systme dexploitation. Il est impratif de se reporter aux recommandations de scurisation du systme concern, ralis par la DCSSI. 8.1.1 Installation du systme dexploitation
installer le serveur du serveur Web sur une machine ddie ; ninstaller que les services requis sur le serveur ; utiliser un disque physique ddi ou au moins une partition dirente pour le contenu du ou des sites Web ; supprimer toute la documentation fournie sur le serveur ; appliquer les stratgies de scurit appropries. 8.1.2 Conguration du systme dexploitation
On veillera galement limiter laccs du serveur Web un certain nombre de chiers. bien grer les droits et permissions des utilisateurs (Si lon est sous un systme de type Unix, on installera le serveur dans une arborescence conne 5 .) ; placer les rpertoires qui contiendront les chiers journaux dans un espace de taille susante. 8.1.3 Anti-virus
On veillera ce quun anti-virus soit install sur le serveur, congur de manire analyser rgulirement les chiers sur le serveur. Cet anti-virus devra avoir une base de signatures actualise le plus souvent possible (une fois par jour minimum). De plus, sil est prvu de mettre en place sur le serveur des fonctions denvoi ou dept de chiers (au travers de formulaires ou de ftp etc.) veillez bien inclure une procdure de contrle antiviral lors de lenvoi ou le dept.
8.2
Scuriser lenvironnement rseau
Lorsquon possde une interconnexion avec lextrieur(Internet ou intranet), il est ncessaire de mettre en place une architecture scurise an de ne pas laisser de portes dentre un attaquant potentiel. Le serveur devrait tre positionn au niveau dune zone dmilitarise (DMZ). Dautre part, le serveur devrait tre redond par une machine de backup (en plus du serveur de test) pour empcher une interruption de service, intentionnelle ou accidentelle, et permettre la maintenance. La amchine de backup devra avoir les mmes caractristiques que le serveur principal (conguration et mises a jours). On veillera galement scuriser les lments annexes du rseau ncessaires un bon fonctionnement du serveur. 8.2.1 Adapter et contrler la conguration du pare-feu
Il faudra bien videmment veiller congurer les pare-feu en prenant garde nautoriser que les ux ncessaires et bien identis. On fera pour cela un tableau des ux passant travers les pare-feu et on congurera les pare-feu en fonction de ces ux. HTTP (TCP port 80), HTTPS(TCP port 443) mais aussi les dirents ux utiliss par les applications identis comme ncessaire et installes.
5 galement
appel chroot
Page 22 sur 47
8.3
8.3.1
Scuriser le serveur Web

Mesures gnriques de scurisation dun serveur Web
Cette partie regroupe lensemble des procdures que lon cherchera appliquer sur tout serveur Web an de le scuriser. Les parties suivantes dtailleront leur application sur les serveurs IIS et apache ainsi que les mesures spciques propres ces serveurs. 8.3.1.1 Gestion des utilisateurs
La gestion des utilisateurs comprend la manire dont les utilisateurs sont perus par le serveur, les mthodes didentication etc. Il est prfrable de ne pas grer les utilisateurs du serveur Web en les associant des comptes au niveau du systme dexploitation. En eet, cela ne fait que compliquer la tche de ladministrateur systme qui devrait modier rgulirement les comptes utilisateur, leurs permissions etc. De plus crer des comptes utilisateur sur le systme peut tre la source de nouvelles failles de scurit qui permettraient lutilisateur de se connecter au systme directement puis utiliser des failles lui permettant daugmenter ses droits et attaquer le systme. Dans le cas o une identication de lutilisateur est ncessaire sur le serveur Web (en raison de services ou fonctionnalits rservs ou personnaliss) plusieurs solutions sont envisageables : besoin minime de condentialit mais personnalisation du service (forums de discussion, gestion de prols utilisateurs . . .) : Il sera alors prfrable de stocker au niveau du module concern les direntes informations (login, mots de passe . . .). Attention : la gestion et le stockage dinformations nominatives exigent une dclaration de la base ou du chier auprs de la CNIL. Il sera prfrable de veiller au chirement du mot de passe sur la base de donnes ; besoin moyen / fort de condentialit, avec ou sans personnalisation de service : mettre en place un certicat sur le serveur Web an dactiver le chirement SSL ; besoin moyen / fort de condentialit ET besoin didentication fort du client : Mettre en place un certicat sur le serveur Web et exiger lutilisation de certicats personnels par le client. Bien entendu il faudra aussi contrler les certicats utilisateurs, dnir ceux accepter, les procdures de mise jour etc. Cette solution est la plus lourde mais aussi la plus sre en cas de besoin fort de condentialit et identication. Cela implique la mise en place dune solution dIGC6 (PKI7 ) ; 8.3.1.2 Procdures de validation des modications ou mises jour
Toute modication du serveur doit dabord tre faite sur un serveur de test dont la conguration est en tout point identique au serveur de production. Ceci sapplique aussi bien aux correctifs systmes que logiciels ou aux mises jour de contenu, ajout de modules etc. Il convient gnralement dappliquer la mise jour au serveur de test et de le laisser fonctionner au moins 24 heures pour contrler le bon droulement de lensemble des tches journalires (sauvegarde, transfert de journaux etc.). La seule exception cette rgle concerne la mise jour des signatures de lantivirus qui, elle, doit se faire le plus rapidement possible. 8.3.1.3 Procdures de mise jour du contenu du site
Aprs validation de la nouvelle version du site, ou des ajouts / modications, ladministrateur Web (et lui seul) pourra transfrer les nouvelles informations, installer les nouveaux composants etc. Un cahier de maintenance du site devra rpertorier de manire prcise les oprations faites sur le serveur (systme et applicatif). Il permettra davoir une trace crite de lvolution du serveur. Il est judicieux de faire une sauvegarde de lensemble de la machine dexploitation avant lapplication de toute mise jour importante.
6 Infrastructure 7 Public
de Gestion de Cls Key Infrastructure
Page 23 sur 47
Cette mise jour est faire de prfrence en priode creuse de consultation (se rfrer aux statistiques de consultation si ncessaire pour dterminer la priode la plus propice, noccasionnant quun minimum de gne pour lutilisateur). Larrt du service Web tant peu accept par lusager, prvoir une redirection momentane sur une page indiquant que pour raison de maintenance le site est temporairement indisponible. Indiquer une heure de reprise est un plus trs apprci par lutilisateur. Ceci peut necessiter la mise en place momentane dune machine si le service doit tre intgralement arrt ou interrompu. Pour ce qui est du procd utilis pour la mise jour du contenu, la copie des chiers sur disquette ou CD puis leur mise en place sur le serveur est prfrable des solutions de mise jour distance. Dans le cas contraire, la communication devra tre scurise avec prcaution (voir administration distante). 8.3.1.4 Restrictions de droits
Le visiteur du site devra tre identi par le systme comme un compte utilisateur dont les droits de consultation ne devront en aucun cas stendre lextrieur des rpertoires de donnes du site. Il peut tre ncessaire dtendre ces droits lcriture et/ou lexcution, pour par exemple permettre lutilisateur de dposer des chiers sur le serveur ou excuter des scripts. Attention ne jamais gnraliser cette extension de droits lensemble du site. Do lintrt dune organisation propre du contenu (voir organisation adquate du contenu ci-aprs) an de limiter les droits au strict ncessaire. Rien ne justie quun compte autre quadministrateur, administrateur Web et utilisateur Web aient un privilge quelconque sur les arborescences et chiers du site. 8.3.1.5 Organisation adquate du contenu
Les dveloppeurs, concepteurs etc. du site devront veiller ce qui la structure des chiers du site soit propre et organise, non seulement de manire prenniser la maintenance et la gestion du site, mais aussi et surtout an de permettre une dnition au plus juste des droits. Ils veilleront particulirement sparer images, pages statiques, pages dynamiques, scripts etc. On remarque cependant une tendance de plus en plus marque des sites tre quasi exclusivement dynamiques. On sparera alors dicilement les pages statiques des pages dynamiques et lensemble de leurs rpertoires auront alors un droit dexcution pour le visiteur. Attention toujours veiller la restriction des droits sur les zones denvoi de chiers etc. En aucun cas lutilisateur ne doit disposer de droits dcriture et dexcution en mme tant sur un rpertoire du serveur. 8.3.1.6
8
Activation du chirement SSL
Lutilisation du SSL permet le chirement des informations changes entre le client et le serveur. Lactivation du chirement SSL est fortement recommande pour tout besoin de condentialit de linformation change. Attention cependant, lopration de chirement/dchirement de linformation peut savrer gourmande en ressource pour les machines. Actuellement la plupart des sites Web nactivent le chirement que pour les pages didentication ou lors de la communication de numro de cartes bancaires etc. Dans le cas ou des informations changes savrent sensibles, lutilisation de solutions de chiffrement telles que les botiers de chirement peut tre prfrable au SSL. Le problme qui se pose concerne alors le dploiement de la solution de chirement et sa maintenance.
8 Secure
Socket Layer
Page 24 sur 47
Un autre inconvnient du SSL (et de tout chirement de bout en bout) peut rsider dans le fait que nombre dIDS9 ne contrlent pas le code contenu dans les ux SSL, laissant ainsi ventuellement passer des attaques au travers du port SSL qui auraient t identies en temps normal sur le ux HTTP standard. 8.3.1.7 Banalisation du serveur
Chaque systme, chaque applicatif peut avoir des failles de scurit. Permettre un individu de connatre le systme, lapplicatif et leur version au travers de la simple consultation de votre page daccueil, cest aussi lui indiquer o chercher des failles de scurit et lui faire gagner un temps trs important quil aurait pu passer tenter de dcouvrir ces informations et qui aurait pu le dcourager. Il convient donc de rendre le serveur et son systme, si possible (administrateur systme), le moins bavard possible. La plupart des serveurs Web permettent en eet de modier leur signature, dautre ncessitent une dition manuelle de chiers, de chiers systme voire de la base de registre pour les systmes sous Windows. 8.3.1.8 Limitation des fonctionnalits du site au stricte ncessaire
Comme il a dj t dit dans ce document, plus le serveur a de fonctions, plus il a de failles potentielles. Restreindre les fonctionnalits du serveur au strict minimum et najouter ces dernires quau fur et mesure que le besoin sen fait sentir est de loin la meilleure solution. Veillez faire linventaire de tous les menus dadministration du serveur et supprimez ou dsactivez tout ce qui nest pas indispensable. 8.3.1.9 Scurisation de ladministration distance
De manire gnrale, il est prfrable dviter les solutions dadministration / dition / mise jour distance. Ces systmes vous permettent de travailler sur le site distance mais peuvent aussi tre considrs par un ventuel attaquant comme une voie dattaque de votre serveur. Si, pour des raisons organisationnelles ou gographiques, cette solution est ncessaire, il est important de veiller plusieurs points : au chirement de la communication ; lidentication ncessaire, mot de passe fort ; un systme de connexion activ la demande (non persistance du modem) ; la journalisation de lactivit de la solution distante et son contrle mticuleux journalier ; au contrle des tentatives daccs ; ... 8.3.2 Scuriser le serveur IIS
Les serveurs Internet Information Server se rencontrent sous 2 versions principales (4 et 5). Considrant que les systmes dexploitation sont jour la scurisation de serveur Web antrieur la version 4 ne sera pas dcrite dans ce document. Le serveur IIS4 est la version courante pour tout systme Windows NT4 depuis le service pack 4, ou tout du moins Option pack 1. Le serveur IIS 5 se rencontre quant lui sur des systmes sous Windows 2000 ou Windows XP. Avant daborder la scurisation de ces deux versions du serveur Web de Microsoft, il est souhaitable que ladministrateur systme ai au pralable appliqu les recommandations de scurisation du systme correspondant.
9 Intrusion Dtection System : programmes de dtection dintrusion qui surveillent les paquets passant sur le rseau an de dtecter dventuelles attaques en analysant les requtes etc.
Page 25 sur 47
8.3.2.1
Limiter linstallation au minimum de services
Il serait prfrable de limiter linstallation un nombre minimum de services et options, limitant par la mme occasion le nombre de failles possibles et les possibilits dattaques. Les services inutiles devraient tre dsactivs, arrts, voire dsinstalls si le systme le permet. Le serveur IIS ncessite lexcution des services suivants pour fonctionner : event log , le journal dvnements License Logging Service Windows NTLM Security support Provider Service dauthentication NTLM Service RPC (Remote Procedure Call) Windows NT serveur ou Workstation IIS admin service Service dadministration IIS MSDTC World Wide Web publishing service Service de publication WWW Protected Storage 8.3.2.2 Mthode dauthentication
Par dfaut IIS propose 4 solutions didentication : Anonyme : Dans ce cas lutilisateur navigant sur le serveur est identi par le compte anonyme congur (proprit du serveur/ identication). Le compte par dfaut qui est utilis et cr lors de linstallation du serveur est de la forme IUSR_Nom-du-serveur .Il peut savrer judicieux de renommer ce compte et den changer le mot de passe, le mot de passe original tant cr alatoirement linstallation. Changer le nom du compte vite aussi que lutilisateur connaisse ventuellement le nom de la machine par le nom dutilisateur anonyme. Basique : Dans ce cas, lutilisateur est identi par un compte et mot de passe existant dans la base utilisateurs du serveur. Des informations transitent sur le rseau en clair, y compris et surtout le compte et le mot de passe utiliss lors de lidentication. Identication de type Windows : Dans ce cas lidentication se fait au travers du challenge Windows douverture de session, le mot de passe ne passe pas en clair, mais ncessite souvent louverture de ports supplmentaires pour permettre lidentication. De plus, il est souvent ncessaire de spcier le nom du domaine ou de la machine sur lequel se trouve le compte ce qui complique singulirement lauthentication. Certicats client : Le systme dexploitation Windows permet aussi lutilisation de certicats client. Il est possible de refuser, accepter ou exiger des certicats clients. Refus : les certicats client (lorsquil y en a) sont ignors ; Acceptation : un utilisateur ayant un certicat client install sur sa machine (logiciel, carte puce etc.) se verra demander la cl de son certicat puis pourra lutiliser ; Certicat exig : lutilisateur ne sera pas accept sans certicat. Attention cependant, par dfaut le serveur ne fait que demander le challenge de certicat, rien nempche lutilisateur de se faire lui mme un certicat logiciel et de lutiliser pour entrer. Dans le cas dutilisation de certicats, ladministrateur devra faire linventaire des certicats quil acceptera et utiliser loption de liaison des certicats qui lui permet dassocier des certicats des comptes ou groupes dutilisateurs. Lauthentication de lutilisateur na dintrt que dans le cadre de serveurs contenus interactifs ou participatifs (forums de discussion, . . .) , et de serveur avec un besoin de condentialit ou de restriction daccs.
Page 26 sur 47
Ds lors quun besoin de condentialit se fait sentir, la mise en place dun certicat sur le serveur est un minimum. Il permettra le chirement SSL de lensemble des changes entre le serveur et le visiteur. La limitation de laccs au serveur peut ensuite se faire au travers de lutilisation didentiants et mots de passe. Sil sagit dun besoin de restriction daccs plus que dauthentication forte, lutilisation didentiants et mots de passe lintrieur de lapplication ou dune base de donnes sut. Il est prfrable dviter lutilisation didentiants et mots de passe systme, non seulement cause des risques ventuels de connexion illicite au serveur, mais aussi et surtout pour des raisons dadministration de ces identiants et mots de passe. Dans le cas o il y a un besoin didentication forte (pour des besoins de traabilit, imputabilit, de signature lectronique, . . .) lutilisation de certicats clients simpose. Attention, il sagit dune structure imposante, complexe mettre en oeuvre et grer quil convient de ne pas prendre la lgre. 8.3.2.3 Positionner les droits sur les rpertoires virtuels du serveur
Comme il a t expliqu prcdemment au chapitre 8.3.1.5, page 24 (Organisation adquate du contenu), il convient de regrouper les chiers dun site Web en fonction de leur type an de positionner de manire plus sre les droits, il est alors ais de positionner un droit dexcution tout le monde sur les rpertoires de scripts et dinclude, et de lecture seule sur les rpertoires de contenu statique et dimages. 8.3.2.4 Dnir les droits sur les chiers journaux
les chiers journaux (log) du serveur IIS (%systemroot%\system32\Logles ) doivent avoir les ACL10 suivantes : contrle total : administrateurs et systme ; cration, lecture, criture : tout le monde ; Cette mesure a pour but dviter quun ventuel attaquant ne vienne eacer les traces de ses actions sur le serveur. 8.3.2.5 Activer et congurer les journaux du serveur Web
An de pouvoir tracer toute tentative dattaque sur le serveur Web il est ncessaire dactiver les journaux de ce dernier. Le format de chier utiliser est W3C tendu11 . Activation des logs W3C tendu : A partir de la fentre dadministration du service WEB, clic droit sur le site Web / Proprits / Site Web / activer les logs - Mode W3C tendu - , puis activer les options suivantes en cochant les cases correspondantes : Adresse Ip du client ; Nom dutilisateur ; Mthode ; URI stem ; Etat HTTP ; Erreur WIN32 ; User Agent ; Adresse IP serveur ; Port Serveur .
10 Access Control List : table informant le systmes des droits des utilisateurs (ou groupe dutilisateur) sur un objet particulier du systme, tel quun chier ou un rpertoire. 11 Format ASCII paramtrable disposant de divers champs. Possibilit dinclure les champs qui semblent importants et limiter la taille du chier en supprimant ceux jugs non ncessaires. Les champs sont spars par des espaces. Lheure est enregistre en temps UTC(GMT)
Page 27 sur 47
8.3.2.6
Restriction daccs par adresses IP ou nom DNS
Cette option peut savrer utile dans le cadre dun intranet ou les adresses IP ne sont pas dynamiques ou pour un serveur Internet dont ladresse des clients ne change jamais. Attention cependant, lusurpation dadresse IP permettant de se faire passer pour une autre machine, ce systme est loin dtre absolument sr. Cela reste cependant une mesure de scurit supplmentaire dans le cas o, par exemple, lon dispose dans la DMZ du serveur Web et de la base de donne sur deux machines distinctes. Relier alors le serveur Web la base de donnes par une carte rseau ddie et nautoriser que ladresse du serveur de base de donnes sur cette carte ddie et uniquement ladresse du serveur Web sur la carte du serveur de base de donnes est dj une mesure de scurit supplmentaire. Il conviendra aussi de changer le rseau de cette connexion pour encore plus de scurit. 8.3.2.7 Supprimer les tiers de conance de la conguration Internet
Lors de son installation Internet Explorer installe plusieurs autorits de certication en les dnissant de conance. Dans le cadre o lon utilise le chirement SSL, et que lon accepte les certicats il est important de supprimer lensemble de ces certicats racine. Attention, la majorit des services pack ou correctifs de scurit mettent jour ou rinstallent ces certicats racine. Il conviendrait de contrler la liste des certicats de conance aprs chaque mise jour du systme. En fonction de votre navigateur la mthode de suppression de ces autorits de certication dire. Lutilisation de Internet Explorer 5 (ou dune version ultrieure) est fortement recommande en raison des direntes failles de scurit dIE 4. IE4 : la suppression des certicats racine nest pas possible, il est ncessaire de les dnir comme ntant plus de conance. Pour ce faire on ditera la base de registre pour dnir toutes les entres inconnues de la ruche HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\ Control\SecurityProviders\SCHANNEL\CerticationAuthorities 0x0. Il est inutile de supprimer les entres, la DLL SCHANNEL.DLL qui gre ces certicats les recrerait automatiquement. IE5+ : la suppression des autorits de certication se fait directement depuis le navigateur. Outils / Options Internet / Contenu / Certicats / Autorits principales de conance puis supprimez toutes les autorits non reconnues. Procder de mme avec les autorits intermdiaires. Aprs avoir chang les autorits de certication larrt et le redmarrage du serveur sont ncessaires. 8.3.2.8 Les pages denregistrement de Certicate Server
Lors de la conguration de Certicate Server12 , des pages ASP13 denregistrement sont installes par dfaut. Ces pages ne sont pas scurises. Il est conseill de supprimer ces pages ou den restreindre laccs au minimum. Ces pages se trouvent dans le rpertoire %systemroot%/certsrv. Les ACL devraient tre positionnes comme suit : groupe ADMINISTRATEURS (contrle total) ; groupe Grants Certicats (contrle total) ; compte SYSTEME (contrle total). Note : dans le cas ou lon envisage dutiliser Certicat Server uniquement pour chirer la communication, un certicat autosign par le serveur laide de certicate server peut sure. En revanche ds lors que lon envisage lusage de certicats clients il nest pas recommand dutiliser la mme machine pour la cration/gestion des cls et pour le serveur Web ou lapplicatif quel quil soit. En dehors de toute considration de qualit ou services proposs par lapplication de gestion de cls, il est recommand de sparer physiquement les deux activits.
12 serveur 13 Active
de cration/gestion de certicats de Microsoft Server Pages : pages dynamiques en .ASP contenant des scripts interprts cot serveur
Page 28 sur 47
8.3.2.9
Le service dindexation
Lutilisation de toute application supplmentaire sur le serveur Web est dconseille (limitation des services au minimum), lindexation du serveur reste cependant une fonction considre comme minimum sur un site WEB. Il est prfrable dutiliser une machine ddie lindexation du ou des serveurs Web. Dans le cas ou lon souhaite utiliser Index Server14 , il est important de prter attention plusieurs choses : Aspect scurit : Mises jour : Le moteur de recherche tant une application disposant de privilges, il est recommand de veiller ce que toute mise jour de scurit concernant Index Server soit applique. Certaines attaques en dni de service ou escalade de privilges peuvent en eet viser les failles du service dindexation. Les rpertoires indexs : Si vous utilisez le service dindexation Microsoft il est primordial de bien contrler les rpertoires que vous indexez. Veillez bien nindexer que les rpertoires dont le contenu est public, sans quoi lensemble de vos scripts, chiers de paramtrage et commentaires pourraient aussi tre indexs. Aspect organisationnel : Taille de lindex : Un index occupera en gnral un peu plus dun tiers du volume des pages indexes. Temps de rponse : Le fait dinstaller un service dindexation sur le serveur peut entraner une augmentation du temps de rponse. Pour un site assez important ou forte consultation, ou encore plusieurs sites, il sera prfrable dutiliser un serveur ddi cette tche. 8.3.2.10 Supprimer toutes les documentations, pages et applications dexemples
De nombreux exemples de codes et dapplications sont intgrs lors de linstallation par dfaut du serveur IIS. Il est recommand de dsactiver le serveur par dfaut et de recrer un serveur dans un autre emplacement du disque (de prfrence dans une autre partition que le systme comme indiqu auparavant). Il est cependant souhaitable de supprimer le rpertoire des serveurs Web et FTP par dfaut en enlevant le rpertoire c :\inetpub . Supprimer auparavant le site Web par dfaut de la console dadministration an dviter tout message derreur. Le rpertoire comprend non seulement un site dexemple, mais aussi les chiers du SDK15 (c :\inetpub\iissamples\sdk ), mais aussi des scripts dadministration distante (c :\inetpub\AdminScripts). Il est galement ncessaire de supprimer les exemples daccs aux donnes (c :\Program Files\Common Files\System\msadc\ Samples). 8.3.2.11 Supprimer tous les liaisons inutiles
Par dfaut IIS est congur pour grer plusieurs extensions communes dont certaines peuvent savrer dangereuses. Lextension .htr par exemple permet la r-initialisation de mot de passe. En fonction de ces extensions, le systme fait appel des DLL16 . Lexploitation de failles dans ces DLL est alors possible. Il convient donc de limiter la conguration dextensions au strict minimum requis pour lutilisation du site. Par dfaut il est recommand de supprimer la conguration de toute extension inconnue. Grer les extensions : depuis la console dadministration IIS, clic droit sur serveur WEB / Proprits / Master Properties / WWW service / edit / Rpertoire racine. Ci aprs les extensions installes par dfaut supprimer : .htr : cette extension est utilise pour la rinitialisations de mot de passe ; .ida : extension dIndex Server, supprimer si vous ne lutilisez pas ;
14 moteur
dindexation / recherche des pages du serveur Web intgr de Microsoft Dveloppent Kit 16 dynamic Link Library
15 Software
Page 29 sur 47
.idc : connecteur de base de donnes internet (Internet Database Connector), prsent les bases de donnes utilisent des connecteurs ADO17 . .shtm, .stm, .shtml : inclusion cot serveur. Tout chier dont lextension nest pas congure sera envoy au visiteur tel quel, comme un tlchargement de chier. 8.3.2.12
18
Supprimer le support RDS
Il est primordial de supprimer le support de service distant. Lattaque au travers des DLL MSADC est une des attaques les plus courantes, elle entrane au minimum le dni de service, au pire la prise de contrle total de la machine. Pour supprimer les fonctionnalits RDS, supprimez le rpertoire /msadc de la racine du site par dfaut (au cas o vous nauriez pas encore supprim ce site) puis supprimez les cls de registre suivantes : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W3SVC\Parameters\ADCLaunch\ RDSServer.DataFactory ; HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W3SVC\Parameters\ADCLaunch\ AdvancedDataFactory ; HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W3SVC\Parameters\ADCLaunch\ VbBusObj.VbBusObjCls ; Dans le cas o lutilisation de RDS est ncessaire, linstallation de la dernire version de MDAC19 et sa conguration pour fonctionner en safe mode seront ncessaires. Pour plus dinformation sur ce point particulier, consulter le site Technet de Microsoft, en particulier le bulletin de scurit MS99_025 (http ://www.microsoft.com/technet/security/bulletin/fq99-025.asp) Il convient aussi de surveiller rgulirement le journal dvnement de votre serveur pour identier ce type dattaques en recherchant des lignes ressemblant ceci : 2001-08-02 18:23:12 - POST /msadc/msadcs.dll ... vous pouvez aussi faire la recherche plus facilement en cherchant directement "msadcs" dans le/les chier(s) journaux. 8.3.2.13 Contrle du contenu des champs de formulaire
Une attaque courante sur les serveurs ayant des formulaires rside dans lenvoi de code malicieux au travers des champs de formulaires, ceci an de dstabiliser le systme, injecter du code dans la base de donnes ou prendre le contrle de la machine. Il est donc important de sensibiliser des dveloppeurs du site Web au contrle des dirents champs retourns par lutilisateur au travers des formulaires. Il est primordial de traiter tous les champs retourns par le visiteur avant de les utiliser dans un quelconque procd. Il sera protable de mettre en place sur le serveur un module ddi au contrle des caractres utiliss. Le seul champ pour lequel certains caractres spciaux peuvent sembler ncessaires est le champ de mot de passe. 8.3.2.14 Dsactiver lachage de contenu de rpertoire
Le site Web dispose de pages par dfaut (default.htm, default.html, default.asp,. . .), ainsi lorsquun utilisateur appelle un rpertoire quelconque du site sans prciser le nom dun chier acher, cest lune de ces pages que le serveur cherchera acher. En absence de lune de ces pages, le site achera une erreur ou le contenu du rpertoire. Il est primordial de contrler que la conguration du site ne montre pas le contenu du rpertoire dans un tel cas. Pour ce faire on dcochera loption acher le contenu du rpertoire dans le menu dadministration du site.
17 ActiveX 18 Remote
Data Object Data Service 19 Microsoft Data Access Component
Page 30 sur 47
Une deuxime scurit consiste positionner dans chaque rpertoire une page de redirection la racine ou encore diter la page derreur correspondante, comme expliqu ci-aprs. 8.3.2.15 Editer toutes les pages derreurs
il est possible dditer chacune des pages derreur standard du site web. Il serait prfrable que lensemble des pages derreur du site soient identiques, ne permettant ainsi pas lutilisateur de deviner le problme rencontr lors du traitement de sa requte. Cette page derreur devrait tre dite la charte graphique du site et proposer un lien vers la page dacceuil du serveur ainsi quun liens vers une adresse de messagerie de ladministrateur du site auquel lutilisateur aurait la possibilit dcrire pour expliquer dans quelles conditions il a rencontr un problme en navigant. De plus, il est recommand de veiller ce que les dirents scripts ou programme tiers ajouts au serveur traitent leurs messages derreur de manire interne, et ne remontent au serveur que des pages banalises. Les developpeurs devront veiller a utiliser un moyen de traitement de lerreur et non se contenter dun achage sur la fentre de navigation. En eet, saisir des informations errones ou non conformes an de provoquer volontairement une erreur lors du deroulement du code est une mthode simple de dcouvrir en autre le chemin physique des pages de code, le nom de la base de donnes, le nom de lutilisateur par dfaut etc. etc. 8.3.2.16 Invalider lutilisation du rpertoire parent
Par dfaut IIS permet lutilisateur dutiliser .. lintrieur de ladresse saisie pour remonter au sein de larborescence du site. Il est impratif de dsactiver cette option pour viter que le visiteur puisse remonter du site la racine du disque puis redescendre dans les rpertoires systmes et excuter des commandes, mme si ceci est normalement impossible en raison du positionnement des ACL sur le systme. On dsactivera cette fonction dans la console dadministration du service Internet : clic droit sur la racine du site Web, Proprits / Rpertoire racine / Conguration / option dapplication et dcochez rpertoire racine. 8.3.2.17 Dsactiver lappel au shell de commande avec #exec
Cette commande pouvant tre utilise pour excuter un code arbitraire sur le serveur partir de pages HTML, il est important de contrler que son utilisation est bien dsactive, sachant quelle lest par dfaut lors de linstallation dIIS. Il faudra contrler que la cl de registre suivante est bien zro. \HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W3SVC\Parameters \SSIEnableCmdDirective 8.3.2.18 Dsactiver ladresse IP dans lentte (Content-Location)
Par dfaut, lors de lenvoi dune page statique (telle que Defaut.htm), linformation ContentLocation est ajoute lentte de la page envoye. Cette information contient par dfaut ladresse IP de la machine et non son nom DNS. Cette information contenue dans lentte permet un attaquant de connatre ladresse relle de votre machine dans le cas o la vritable adresse du serveur est masque derrire un pare-feu ou tout autre systme oprant une translation dadresse. Dans ce cas lentte de la page peut ressembler ceci : HTTP/1.1 200 OK Server: Microsoft-IIS/4.0 Content-Location: http://10.1.1.1/Default.htm Date: Thu, 18 Feb 1999 14:03:52 GMT Content-Type: text/html Accept-Ranges: bytes Last-Modified: Wed, 06 Jan 1999 18:56:06 GMT ETag: "067d136a639be1:15b6" Content-Length: 4325
Page 31 sur 47
lentte ntant pas modie par le pare-feu ou les systmes de mandataires(proxy), elle expose lextrieur une partie du plan dadressage interne de lentit. Une valeur doit tre corrige dans la metabase dIIS, pour changer ladresse IP par le nom DNS de machine, ceci grce Adsutil.vbs. Pour ce faire, il faudra ouvrir une fentre de commande, aller dans le rpertoire winnt\system32\ inetsrv\adminsamples puis taper la commande : adsutil set w3svc/UseHostName true lentte deviendra ainsi : HTTP/1.1 200 OK Server: Microsoft-IIS/4.0 or Microsoft-IIS/5.0 Content-Location: http://www.ceakikiledomaine.com/Default.htm Date: Thu, 18 Feb 1999 15:08:44 GMT Content-Type: text/html Accept-Ranges: bytes Last-Modified: Mon, 30 Nov 1998 15:40:15 GMT ETag: "f07f84b9771cbe1:3068" Content-Length: 4739 8.3.2.19 Mettre en place un ltrage des requtes, scurisation globale dIIS
Certains attaquants contournent linterdiction de remonter les rpertoires en glissant des caractres spciaux dans ladresse de leur requte. Le serveur ne reconnat pas immdiatement ces caractres comme tant des accs aux rpertoires parents et laisse passer la requte qui une fois interprte permet de remonter dans larborescence, en dehors du site Web an datteindre et excuter des commandes systme. Le fait davoir mont le site Web sur une partition ddie est dj un bon moyen de restreindre lattaque. Cependant il est plus quintressant de pouvoir bloquer et identier ce type dattaque. Pour ce faire, Microsoft propose des outils de scurisation tels que IIS Lockdown Tool (http ://www.microsoft.com/technet/security/tools/tools/locktool.asp) et Urlscan Security Tool (http ://www.microsoft.com/technet/security/tools/tools/urlscan.asp). Le premier contrle plusieurs points de scurit du serveur et se rvle un outils incontournable de scurisation globale dIIS. Le second contrle les requtes passes au serveur, les dernires versions dIIS Lockdown Tool intgrent prsent Urlscan. 8.3.3 Scuriser le serveur Apache
Apache (http ://httpd.apache.org) apparu en avril 1996 est un des serveurs les plus riches en fonctionnalit. Le tout est de connatre celles dont vous avez rellement besoin, les risques quelles incluent et dsactiver les autres. Un grand point de la scurit dun serveur Web : les rdacteurs du site Web reprsentent un risque. Lgalement il est du devoir de ladministrateur dviter que lon puisse utiliser ses serveurs comme base dattaque. Pour ce faire il serait bon de se prmunir contre les failles que pourraient introduire, intentionnellement ou non, toute personne pouvant intervenir sur le site Web. Les dirents chemins des chiers donns en exemple sont valables sur Debian (Gnu/Linux). 8.3.3.1 Les utilisateurs
Une conguration par dfaut du serveur Apache nutilise, en plus du compte root, quun seul compte www-data (sur Debian GNU / Linux) aux droits trs restreints. Il est utilis par le serveur Apache pour accder aux donnes mises sa disposition. Cette conguration ncessite que toute modication du serveur ou des donnes soit faite par un utilisateur disposant des droits administrateur. Il serait prfrable dutiliser la conguration suivante, an de diminuer les consquences dune erreur humaine et de mieux tracer les modications apportes par chaque intervenant. Nanmoins lapplication des autres recommandation reste primordial pour un serveur nutilisant que les comptes par dfaut. Trois types de compte, hormis lutilisateur root, existent sur le serveur Apache (cf. gure 1) :
Page 32 sur 47
le ou les comptes du ou des administrateurs Web. Ils auront accs la conguration du serveur et devront donc tre capables, entre autres, dditer le chier httpd.conf (webadmin dans les exemples) ; les comptes des rdacteurs qui nauront accs en criture qu larborescence du serveur Web (/var/www ) et en seront les propritaires. Laccs au rpertoire des CGIs demande une politique particulire de validation du contenu (par ladministrateur Web) webpublisher dans les exemples ; Le compte utilis, uniquement par le serveur, pour rpondre aux demandes de connexion ( User www-data). Attention ce compte doit avoir le droit de lecture et de parcours sur larborescence des chiers Web. Les trois comptes appartiennent au groupe apache (cf. gure 2). cat /etc/passwd www-data:x:33:1001:www-data:/var/www:/bin/false webadmin:x:1001:1001:,,,:/home/webadmin:/bin/bash webpublisher:x:1002:1001:,,,:/home/webpublisher:/bin/bash cat /etc/group apache:x:1001:www-data,webpublisher,webadmin
Fig. 1 analyse de /etc/passwd
cat /etc/group | grep apache apache:x:1001:www-data,webpublisher,webadmin
Fig. 2 analyse de /etc/group La commande "ps" permet vrier quel est le compte utilis par le serveur Apache pour accder aux chier la demande de lutilisateur. On constate que seul le processus pre (251) est root. Les demandes des utilisateurs connects seront traites avec le compte www-data(cf. gure 3). ps -ef | root www-data grep apache 251 1 0 09:22 ? 484 251 0 09:29 ?
00:00:00 /usr/sbin/apache 00:00:00 /usr/sbin/apache
Fig. 3 rsultat de la commande PS (serveur Web dmarrer) Ce compte, aux droits les plus restrictifs possibles, ne devrait, normalement, pas servir. Il ne devrait donc pas tre ncessaire que www-data dispose dun interprteur de commande (shell). Cela se vrie dans le chier /etc/passwd (cf. gure 1). Le /bin/false en n de ligne dmontre que le compte www-data ne dispose daucun shell . Il serait aussi plus scuritaire de bloquer ce compte en mettant, par exemple une toile la place du mot de passe dans /etc/shadow (cf. gure 4). cat /etc/shadow www-data:*:11939:0:99999:7::: webadmin:Bx:11991:0:99999:7::: webpublisher:By:11991:0:99999:7:::
Fig. 4 analyse de /etc/shadow
Page 33 sur 47
8.3.3.2
Les chiers
Les exemples sont prsents pour une conguration avec les trois comptes. La vrication des droits daccs des chiers et rpertoires est tout aussi importante si la conguration utilise la conguration des comptes par dfaut. 8.3.3.2.1 Les chiers de conguration
Apache nutilise plus quun seul chier pour sa conguration : httpd.conf (/etc/apache/httpd.conf ). #ls -al /etc/apache | grep httpd.conf -rw------1 webadmin root 35281 Oct 22 15:22 httpd.conf # ls -l /etc | grep apache drwxr-xr-x 2 root root 4096 Oct 31 15:16 apache
Fig. 5 Droits sur le chier httpd.conf et le rpertoire apache Ce chier ne doit tre accessible en lecture comme en criture que par root ou ladministrateur du site Web. Il devra contenir tous les commentaires ncssairent sa bonne comrhension. Le rpertoire contenant ce chier ne doit orir de droit en criture qu root (cf. gure 5). Attention seul root peut dmarrer arrter ou relancer le serveur. Une utilisation, par exemple, de sudo (http ://www.sudo.ws)est envisageable pour tendre les droits de webadmin et ainsi lui permettre de faire prendre en compte les modications de httpd.conf sans intervention de root. Certaines variables de conguration peuvent cependant tre modies par les rdacteurs laide du chier (nomm par dfaut) .htaccess positionn dans larborescence du serveur. Dans le chier httpd.conf on trouve le nom de ce chier avec la balise AccessFileName. # # AccessFileName: The name of the file to look for in each directory # for access control information. # AccessFileName .htaccess Fig. 6 Conguration dans httpd.conf du nom du chier de rednition des droits Lutilisation de ce chier (cf. gure 6) sera explicite plus loin dans ce document. 8.3.3.2.2 Les droits daccs systme aux chiers de larborescence du serveur
Les droits de lutilisateur Apache (www-data) devraient tre minimum pour limiter les possibilits dattaque en cas de faille sur le serveur. Le dfaut est souvent rwxr-xr-x. Pour une bonne scurit le repositionnement de ces droits devrait absolument tre mise en uvre. Le rpertoire contenant les chiers mis disposition des visiteurs par le serveur Web est dni dans le chier httpd.conf par DocumentRoot (cf. gure 7). La racinde du serveur Web ne devrait jamais etre la racine du serveur20 . DocumentRoot /var/www
Fig. 7 Choix du rpertoire contenant les donnes du serveur Web.

20 (DocumentRoot
/)
Page 34 sur 47
Le positionnement des droits prsents ici concerne le serveur Web (www-data, du groupe apache). Pour les rpertoires R : permet de lister le contenu dun rpertoire. Ce droit nest utile que pour la cration dindex automatique et ne devrait donc pas tre positionn par dfaut ; W : Il permet la cration ou la suppression de chier. Ce droit, dangereux pour la scurit, ne devrait pas tre positionn par dfaut ; X : Il permet de traverser un rpertoire et est donc ncessaire pour lutilisateur du serveur Web. Pour les chiers R : Il permet daccder au contenu et est donc ncessaire pour lutilisateur du serveur Web ; W : Il permet ldition de chier. Ce droit, dangereux pour la scurit, ne devrait pas tre positionn par dfaut ; X : Il permet un chier dtre excuter. Ce droit, dangereux pour la scurit, ne devrait tre positionn que pour le ou les chiers excutables (CGI) et uniquement dans le rpertoires qui leur est explicitement rservs. Lappartenance de larborescence au rdacteur (cf. gure 8) lui permettra de mettre jour les pages Web sans autre intervention et de garder lautorisation de lister le contenu des rpertoires. Laccs en lecture seule au groupe apache laisse la possibilit au serveur Web (www-data fait parti de ce groupe) de lire et den acher les pages. /var# ls -l | grep www drwx--xr-4 webpublisher apache /var/www# ls -l total 24 drwx--x--2 webpublisher apache -rwxr----1 webpublisher apache -rwxr----1 webpublisher apache
4096 Oct 31 14:41 www
4096 Oct 31 10:58 ficdir 21 Oct 31 10:57 fictest.html 4110 Aug 13 06:31 index.html
Fig. 8 Droits sur les chiers et repertoires du serveur Web.
8.3.3.2.3
Le rpertoire des CGI
Le rpertoire contenant les CGI est dni dans le chier httpd.conf par ScriptAlias (cf. gure 9) . ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/
Fig. 9 Choix du rpertoire contenant les CGI. Ce rpertoire, comme il sera rappel plus loin dans ce document, est lunique endroit o le serveur Web devrais pouvoir excuter du code. Pour limiter la possibilit dintroduction de faille, volontairement ou non, par les rdacteurs, il est conseill que seul ladministrateur du site Web puisse dposer, lire ou lister les chiers dans ce rpertoire. Il est par contre ncessaire pour le bon fonctionnement du serveur que www-data (le serveur Web) puisse excuter les programmes qui sy trouvent. Cela se fait en donnant au groupe apache les droits en excution sur le rpertoire et les chiers qui sy trouvent (cf. gure 10) .
Page 35 sur 47
# ls -l /usr/lib | grep cgi drwx--x--2 webadmin apache /usr/lib/cgi-bin# ls -l total 60 -rwx--x--1 webadmin apache
4096 Oct
4 15:42 cgi-bin
52604 Nov
7 14:03 cgi_de_test
Fig. 10 Droits daccs aux CGI. Rappel : Il est trs fortement dconseill de choisir un rpertoire pour les CGI dans larborescence du serveur (/var/www ). 8.3.3.2.4 Les journaux
Les balises dnissant les chiers de journalisation ( /var/log/apache/ ) dans httpd.conf sont : CustomLog et ErrorLog (cf. gure11). CustomLog /var/log/apache/access.log combined ErrorLog /var/log/apache/error.log LogLevel warn Fig. 11 Balise de journalisation Warn (cf. gure11) est le niveau minimum conseiller pour les journaux. Le niveau de journalisation est adapter aux moyens humains mis en uvre pour les analyser. Un niveau trop lev pourrait, sans attention particulire, remplir les journaux et endommager le bon fonctionnement du serveur. Il est conseill de limiter laccs aux journaux ladministrateur du site Web (cf. gure12). /var/log/apache# ls -l total 24 --wx-----1 webadmin --wx-----1 webadmin
apache apache
5982 2002-10-24 16:05 access.log 14337 2002-10-25 09:33 error.log
Fig. 12 Droits daccs aux journaux Rappel : Les journaux contiennent des donnes sensibles concernant le serveur et les visiteurs (exemple : les REFERER21 ). Ils ne devraient jamais accessible depuis le Web. 8.3.3.3 Modication des droits par les rdacteurs : le chier .htaccess
Le serveur Apache permet au rdacteur de rednir la conguration, sans redmarrer le serveur, laide dun chier situ dans le rpertoire dont le rdacteur veut modier les possibilits. Ce chier est frquemment utilis pour positionner une limitation daccs par utilisateur. Avec des droits mal positionns dans le httpd.conf il permettrait par exemple un rdacteur (ou un pirate parvenant dposer un chier) de changer le chier de mot de passe utilis par le serveur ou dautoriser lutilisation de lien symbolique vers dautres chiers du disque.
21 Par dfaut les navigateurs envoient, lorsquun lien est cliqu, non seulemement la demande de la page mais aussi, la totalit de la requte prcdente qui peut, par exemple, contenir lidentiant mail dun visiteur en provenance de sa boite aux lettres
Page 36 sur 47
8.3.3.3.1
La directive AllowOverride
La directive AllowOverride fait partie dApache. Cette capacit ne peut donc pas tre dsactive. Il est important davoir bien compris la porte des directives selon leur placement par rapport aux dirents blocs22 du chier de conguration. Elle peut avoir comme valeur : All : Avec cette valeur presque toute la conguration peut tre modie (suivis des liens symboliques...). Dangereuse pour la scurit, elle ne devrait pas tre utilise ; None : Lutilisation de cette valeur devrait tre systmatiquement utilise la racine du serveur Web. Elle interdis toute modication utilisant .htaccess ; AuthCong : Cette valeur permet la modication des autorisations. Elle ne devrait tre positionne qu la demande des rdacteurs, dans les blocs dnissant les rpertoires ou un contrle daccs sera ncessaire ; FileInfo : Cette valeur permet de modier les dirents types de chiers utiliser par le serveur (ex : ErrorDocument). Elle ne devrait tre utilise quavec un grand contrle ; Indexes : Cette valeur permet de piloter lindexation des rpertoires mais aussi de changer le nom du chier recherch par dfaut (index.html). Elle ne devrait tre positionne, qu la demande des rdacteurs, dans les blocs o lachage du contenu du rpertoire sera ncessaire et contrl ; Limit : Cette valeur est ncessaire pour grer les droits arant aux autorisations. Elle devrait tre positionne la demande des rdacteurs. Options :Cette valeur permettrait de positionner nimporte quelle option du serveur comme active comme par exemple : lexcution de CGI et lutilisation de liens symboliques. Dangereuse pour la scurit, elle ne devrait pas tre utilise. 8.3.3.3.2 Le chier .htaccess
Le nom, par dfaut, de ce chier est .htaccess. Il est dni par la directive : AccessFileName .htaccess Il est trs important que laccs en soit interdit pour les utilisateurs du serveur Web. Dautre part, ladresse (http ://servername/RepertoireProtg/.htaccess) ne doit pas retourner le chier. Pour cela on utilise la directive Files tel que le montre lexemple. Une modication du nom de chier par dfaut .htaccess pour accrotre la scurit devrait saccompagner dune adaptation de la directive Files si son nouveau nom le require (cf. gure 13). Remarque : Cet exemple protge aussi contre la divulgation dun chier .htpasswd <Files ~ "^\.ht"> Order allow,deny Deny from all </Files>
Fig. 13 Protection des chiers en .ht 8.3.3.4 Dmarrer le service
Le serveur Apache peut tre dmarr en stand-alone, cest dire quil est lanc systmatiquement et reste lcoute en permanence. Il peut galement tre lanc par le biais du dmon inetd ce qui correspond un lancement la demande du client du serveur. Pour des raisons de scurit et de performance un serveur Apache ddi devrait toujours tre lanc en stand-alone. Ce mode est utilis en gnral par dfaut. On le vrie dans httpd.conf (cf. gure 14). :
22 exemple : <Directory /> </Directory> constitue le bloc contenant les commandes valides, sauf rednition, pour larborescence du site Web depuis la racine
Page 37 sur 47
# # ServerType is either inetd, or standalone. # Inetd mode is only supported on Unix platforms. # ServerType standalone Fig. 14 dnition du type de serveur 8.3.3.5 Suppression des traces permettant didentier le serveur Apache
Lors de la cration dune page derreur le serveur Apache dcline gnralement son identit et sa version installe (cf. gure 15).
Fig. 15 Message derreur par dfaut dun serveur Apache La suppression de cette trace prsente par dfaut se fait par modication, dans httpd.conf (cf. gure 16). # Set to one of: On | Off | EMail # ServerSignature Off Fig. 16 Modication des traces Cette modication ne sut pas, on peut aussi obtenir des informations en utilisant un telnet sur le port 80 (ou le port utilis par le serveur Web) (cf. gure 17). telnet nicolasaudit.internet 80 Trying nicolasaudit.internet... Connected to adr.ip.server.web Escape character is ^]. HEAD / HTTP/1.0 HTTP/1.1 400 Bad Request Date: Tue, 22 Oct 2002 12:26:48 GMT Server: Apache/1.3.26 (Unix) Debian GNU/Linux Connection: close Fig. 17 Traces obtenues par telnet
Page 38 sur 47
La gure 17 laisse clairement apparatre que le serveur Web est un Server : Apache/1.3.26 (Unix) Debian GNU/Linux. La suppression partielle de cette trace, prsente par dfaut, se fait, par modication, dans httpd.conf. ServerTokens Prod ATTENTION Cette ligne nexiste, en gnral, pas dans le httpd.conf par dfaut, il faut la crer ; Cette directive ne fonctionne que sur les serveurs Apache de version suprieure au 1.3.12 (ServerTokens existe depuis la 1.3 mais sans loption Prod) ; Cette directive retire la version du produit mais il reste le nom : Apache. La seule possibilit denlever compltement cette trace est la recompilation du serveur partir des sources en enlevant les signatures dans include/httpd.h. #define SERVER_BASEVENDOR " " #define SERVER_BASEPRODUCT " " #define SERVER_BASEREVISION " " 8.3.3.6 Les modules
Le chier httpd.conf est souvent livr avec un grand nombre de modules actifs par dfaut. Mettre un # devant la commande LoadModule permet de dsactiver les fonctionnalits non ncessaires. Les modules prsents ci-aprs ncessitent une attention toute particulire. autoindex_module cre automatiquement la liste des chiers prsents dans un rpertoire en labsence dun des chiers par dfaut, tel que index.html.
Fig. 18 Exemple dindex cr automatiquement par Apache Comme voqu au 8.3.3.3.1 lindexation automatique pourrait permettre un attaquant potentiel de rcuprer des informations auxquelles il naurait pas d avoir accs ;
Page 39 sur 47
status_module permet dacher des informations sur le serveur. Le module est actif par dfaut. Les lignes mettant en place le lien http ://servername/server-status sont, en gnral, commentes ou inexistantes. Laisser le module actif, sil est inutilis ne prsente aucun intrt (cf. gure 19). Apache Server Status for nicolasaudit.internet Server Version: Apache/1.3.26 (Unix) Debian GNU/Linux Server Built: Aug 13 2002 04:37:24 Current Time: Tuesday, 22-Oct-2002 15:22:53 CEST Restart Time: Tuesday, 22-Oct-2002 15:22:51 CEST Parent Server Generation: 0 Server uptime: 2 seconds Total accesses: 0 - Total Traffic: 0 kB CPU Usage: u0 s0 cu0 cs0 0 requests/sec - 0 B/second 1 requests currently being processed, 4 idle servers Scoreboard Key: http://127.0.0.1/server-status "_" Waiting for Connection, "S" Starting up, "R" Reading Request, "W" Sending Reply, "K" Keepalive (read), "D" DNS Lookup, "L" Logging, "G" Gracefully finishing, "." Open slot with no current process Srv PID Acc M CPU SS Req Conn Child Slot Client VHost Request 0-0 1120 0/0/0 W 0.00 1 0 0.0 0.00 0.00 127.0.0.1 nicolasaudit.internet GET /server-status HTTP/1.1 Srv Child Server number - generation PID OS process ID Acc Number of accesses this connection / this child / this slot M Mode of operation CPU CPU usage, number of seconds SS Seconds since beginning of most recent request Req Milliseconds required to process most recent request Conn Kilobytes transferred this connection Child Megabytes transferred this child Slot Total megabytes transferred this slot Apache/1.3.26 Server at nicolasaudit.internet Port 80
Fig. 19 rsultat de la requte http ://127.0.0.1/server-status Les informations prsentes dans la gure 19 faciliteraient grandement lattaque dun pirate. userdir_module permet chaque utilisateur de la machine davoir accs tout ou partie de son rpertoire personnel (UserDir public_html par dfaut) au travers du serveur Web en utilisant une adresse du type(cf g. 20) http ://servername/ser. Le nombre dutilisateurs devant tre u rduit au minimum, sur un serveur Web ddi, ce module ne devrait pas rester actif ;
Page 40 sur 47
Fig. 20 Exemple daccs un rpertoire partag cgi_module permet lexcution de scripts sur le serveur. Un paragraphe traite des CGI ultrieurement dans ce document (8.3.3.7) ; auth_module fournit le systme dauthentication de base dApache. Lorsque ce module est utilis les identiants et mots de passe sont stocks et circule en clair. Il est prfrable dutiliser mod_auth_digest. 8.3.3.7 Les CGI
Les CGI sont des programmes excuts par le serveur. A ce titre ils doivent tre lobjet de toutes les attentions. Si lon ne peut sen passer il faudrait Retirer tous les CGI livrs en exemple ; Les stocker hors de larborescence des chiers Web ; Nautoriser lexcution de programme que dans ce rpertoire ; Interdire toute modication de droit Apache dans ce rpertoire ; Interdire toute modication de droit correspondant lexcution de cgi sur la totalit de larborescence ; Mettre en place une procdure de contrle et validation de CGI avant leur mise en place sur le serveur Web (plus particulierement sur le ltrage des paramtres transmis par les utilisateurs du site). La gure 21 prsente le chargement du module cgi, son rpertoire dexploitation, les contraintes et restrictions mises sur ce rpertoire ainsi que la suppression (par mise en commentaire) des associations23 dangereuses.
23 handler
Page 41 sur 47
LoadModule cgi_module /usr/lib/apache/1.3/mod_cgi.so ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/ <Directory /usr/lib/cgi-bin/> AllowOverride None Options ExecCGI Order allow,deny Allow from all </Directory> #AddHandler cgi-script .cgi .sh .pl
Fig. 21 Exemple de conguration de CGI 8.3.3.8 Les liens symboliques
Les liens symboliques permettent de rendre visible depuis le serveur Web des chiers nen faisant normalement pas partie. Cette fonctionnalit fait partie intgrante dApache et nest donc pas dpendante du chargement dun module. Il est recommand de la dsactiver : Options None Loption "None", dsactivant dautres fonctionnalits en mme temps, est en gnral conseille pour la conguration globale. Il est possible de ne dsactiver que les liens symboliques par : Options -FollowSymbLinks
Page 42 sur 47
9
9.1
Maintenir le niveau de scurit : mesures gnrales

Rgles dexploitation
Les rgles dexploitation prsentes ci-dessous doivent tre mises en uvre pour le serveur Web et tendues tous les systmes et composants faisant partie de lenvironnement du serveur Web 9.1.1 Gestion des correctifs de scurit (serveurs et clients)
Quand une mise jour de scurit concernant le serveur Web est publie, les correctifs devraient tre identis, tests dans un environnement adquat puis installs sur le systme de production si les rsultats des tests sont satisfaisants. Un composant devrait toujours tre la dernire version stable de son systme dexploitation et de ses logiciels. Cependant, linstallation des derniers correctifs ncessite souvent lutilisation de la dernire version de logiciel ou de systme dexploitation. Cette version ntant pas forcment compatible avec les logiciels utiliss sur les composants, la recherche dune solution stable et scurise est donc parfois complexe. Il est parfois plus sr, mais aussi plus long, dinstaller la dernire version stable dun logiciel que dessayer dappliquer un correctif sur lancienne version existant. 9.1.2 Ralisation de ches rexes pour grer les alertes
Ces ches rexes devraient prciser, pour chaque incident possible, les tches devant tre ralises. Elles permettent une raction rapide et pertinente des administrateurs une situation durgence. Chacune des tches unitaires doit tre dcrite et son droulement prcis. Du personnel, entran leur utilisation, doit tre en astreinte pour permettre une raction rapide en cas dalerte. Ces ches doivent prciser : les modalits de dclenchement dune alerte ; les gestes durgence faire ou ne pas faire (ex : en cas de compromission, il faut dbrancher la machine incrimine du rseau mais ne pas lteindre ) ; les personnes contacter avec une liste de numro de tlphone tenue jour ; la graduation ventuelle des alertes (alarme interne, alerte du FSSI et du HFD, alerte des forces de lordre, etc. . .) ; quelles informations doivent tre fournies dans une alarme pour sa prise en compte (date, heure, constat, adresse IP, modalit de lattaque, rsultat constat, etc. . .) ; une ventuelle chane descalade en cas de dcision importante. De plus amples informations sont disponibles dans lavis du CERTA CERTA-2002-INF-002. 9.1.3 Formation
Le personnel devrait tre form ladministration de son serveur et/ou des applications sa charge. De plus, un clairage particulier devrait tre apport sur la scurit, au niveau du rseau comme au niveau systme. En eet, chaque systme ou application a ses propres fonctionnalits de scurit. Une mauvaise conguration dune de ces fonctionnalits peut compromettre la scurit de tout le systme et par extension du rseau. Une volution des produits utiliss ncessite une nouvelle formation des administrateurs. Plusieurs personnes doivent tre formes pour garantir une disponibilit adquate. 9.1.4 Gestion des comptes et des mots de passe
Des procdures claires devraient exister concernant : la cration de nouveaux comptes ; la suppression ou la dsactivation de ceux rendus inutiles par le dpart dun utilisateur ; la modication de tous les mots de passe connus par un administrateur lors de son dpart, dun changement de fonction, . . .
Page 43 sur 47
la vrication rgulire des comptes prsents sur le systme, et de leur privilges. intervalles rguliers, ladministrateur devrait vrier la qualit des mots de passe utiliss, sil y est autoris par la politique de scurit du SI, grce des outils spcialiss (John The Ripper par exemple). 9.1.5 Serveur de secours et de test
En cas de dysfonctionnement du serveur de production, une solution de secours devrait exister en fonction des besoins de disponibilit du systme. Pour un serveur, la solution la plus classique consiste disposer de matriel de remplacement. Ce matriel doit voluer de la mme manire que le composant quil est cens remplacer (mme version de systme dexploitation, composants internes cohrents comme mmoire, carte vido, capacit disque, logiciels, etc. . .). Une pice modie sur le serveur doit galement tre change au plus vite sur le secours. Cette machine de secours doit disposer des mmes contrats de maintenance que celle de production et tre teste priodiquement. 9.1.6 Gestion des sauvegardes
Des procdures de sauvegarde et de rcupration des donnes devraient tre formalises. Les congurations des serveurs devraient tre sauvegardes et les sauvegardes tre stockes dans un core ignifug, plac dans des locaux dirents de ceux accueillant les serveurs an dviter une destruction de tous les jeux de sauvegarde et du serveur de production en cas dincendie. Elles doivent bien entendu tre mises jour chaque modication du serveur. Elles doivent galement tre priodiquement vries et des restaurations ralises pour sassurer du bon fonctionnement des mdias de stockage. Elles doivent comporter des sauvegardes des lments de conguration comme la base de registre. 9.1.7 Gestion des lments temporaires
Des informations sensibles peuvent avoir t crites par dirents processus dans un rpertoire temporaire. Aprs utilisation, ces informations ne devraient pas pouvoir tre exploites par dautres processus, et devraient tre supprimes. Les rpertoires temporaires doivent donc tre apurs priodiquement. Cette opration peut tre ralise au moyen dun outil comme " at ".
9.2
Mise jour de la PSSI
La politique de scurit dcrivant les mesures de scurit et dadministration du serveur doit tre maintenue jour. Linstallation dun nouveau service doit tre prcde dune mise jour de la PSSI et la cration de ches rexes pour tous les incidents pouvant en dcouler.
9.3
Audits de scurit
La ralisation daudits rguliers de la scurit permet de vrier ladquation entre le niveau de scurit attendu et celui eectivement ralis. Ces audits permettent galement lanalyse des vulnrabilits rsiduelles dun systme dinformation, car la conguration des quipements volue, et des failles apparaissent. Mme si la maintenance du rseau est ralise, elle peut laisser passer un paramtre dangereux, une faille qui ne paraissait pas dangereuse car trop complexe, ou encore une rinstallation de logiciel sans rinstaller les correctifs. . . Un audit priodique permet donc de prendre du recul et de contrler le maintien du niveau de scurit : audits rguliers du systme via une entit interne ou externe (Bureau Audits en SSI de la DCSSI par exemple) ; audits rguliers du systme via des scanners de vulnrabilits (exemple : Nessus, ISS. . .) ; mise en place dun systme de contrle dintgrit (exemple : tripwire, . . .).
Page 44 sur 47
10
10.1
Maintenir la scurit : mesures spcifiques

Exploitation des journaux
Une procdure doit expliciter les tches devant tre ralises en terme dexploitation des journaux. Chacune des tches unitaires doit tre dcrite et son droulement prcis. Cette procdure doit prciser, pour chaque systme et application : la priodicit de lanalyse des journaux et ses modalits (qui fait quoi, quand, etc. . .) ; o trouver les journaux analyser (serveur, station de travail etc. . .) ; quelles informations doivent tre recherches (accs successifs refuss, utilisation inhabituelle dun serveur, journaux des antivirus, des caches HTTP, FTP, etc. . .). noter quil existe des produits permettant une analyse semi-automatise de tels journaux simpliant grandement leur dpouillement ; Lusage de chiers journaux tournants24 est dun grand intrt pour la disponibilit du serveur. Il nest, en eet, pas ncessaire dans ce cas de grer la saturation du disque o sont stocks les journaux, disque ddi de prfrence, et les exceptions qui en dcoulent. Ce dispositif est par contre attaquable par saturation : les traces relles de lattaque pourront tre masques par des messages sans valeur. Il convient donc de sauvegarder les journaux avant de les r-craser.
10.2
Raliser une veille technologique sur les lments du rseau
Tous les composants techniques ont eu, parfois ont encore, et auront des failles. Il importe donc dtre lcoute dorganismes comme le CERTA qui alertent lors de lapparition de nouvelles failles25 : www.certa.ssi.gouv.fr ; www.cert.org et www.cert.org/current/current_activity.html. Il est bon de rappeler que le maintien du niveau de scurit du serveur Web est dpendant du maintien de niveau de scurit de son contenu. La correction rapide des failles des applications et un contrle constant du contenu du serveur est ncessaire mais non susant la scurit du serveur. Microsoft propose deux utilitaires permettant de vrier quune ou un ensemble de machines possdent bien les dernires mises jour : HFNetCheck (ligne de commande) : (http ://www.microsoft.com/downloads/release.asp ?release=31154) ; Microsoft Baseline Security Analyser (interface graphique) De plus, un autre outil (QFEcheck) permet de dterminer les correctifs eectivement appliqus une machine. Le CERTA(http ://www.certa.ssi.gouv.fr/index.html) propose ses avis sur les vulnrabilits Apache (en Franais) ainsi que le lien sur lavis de scurit Apache (en Anglais). Le site Web dApache (http ://httpd.apache.org) propose un suivit des vulnrabilits (en Anglais) : http ://httpd.apache.org/security_report.html Le lien download depuis laccueil du site permet daccder aux patchs (http ://www.apache.org/dist/httpd/patches/) (utiliss seulement pour les bugs mineurs Attention ces patchs ne sont que des patchs appliquer aux sources et ncessitent donc une recompilation du serveur) et la dernire version stable sous forme excutable.
10.3
Autres paragraphes . . .
chier journal a toujours la mme taille et sauto-crase si ncessaire. serait souhaitable daviser pralablement le CERTA des choix de conguration qui ont t faits en terme de systme dexploitation, logiciels, etc., pour que le CERTA puisse cibler sa veille en fonction des produits les plus reprsentatifs.
25 Il
24 Le
Page 45 sur 47
Glossaire
CERTA : Centre dExpertise gouvernemental de Rponse et de Traitement des Attaques informatiques DCSSI : Direction Centrale de la Scurit des Systmes dInformation FSSI : Fonctionnaire de la Scurit des Systmes dInformation FTP : File Transfer Protocol HFD : Haut Fonctionnaire de Dfense HTTP : HyperText Transfer Protocol PSSI : Politique de Scurit des Systmes dInformation SGDN : Secrtariat Gnral de la Dfense Nationale SI :Systme dInformation ,
Page 46 sur 47
Index
.htaccess, 32 access.log, 34 administration, 41 alerte, 41 applicatif tlcharg, 16 applications, 13 Arrt ou dysfonctionnement du service Web, 8 audits, 42 avertissements, 6 backup, 42 cgi-bin, 33 commentaires, 6 commutateur, 13 comptes, 41 concentrateur, 13 conguration, 20 correctifs, 41 dtection dintrusion, 13 donnes, 13 droits daccs, 32 error.log, 33, 34 exploitation, 41 che rexe, 41 chiers, 32 chiers de conguration, 32 rewall, 20 formation, 41 hfnetchk, 43 htes, 13 hotx, 41 httpd.conf, 32 hub, 13 IDS, 13 installation, 15, 20 introduction, 5 journaux, 33, 34, 43 locaux, 10 logs, 43 mdia physique, 16 maintenance, 41 maintenir le niveau de scurit : mesures gnrales, 41 maintenir le niveau de scurit : mesures spciques, 43 Modication de contenu, 8 mots de passe, 41 objectifs, 5 OS, 20 pare-feu, 20 patch, 41 politique de scurit, 9 ppes, 10 prsentation, 5 pr-requis, 7 pralables de linstallation, 15 dfense en profondeur, 10 Principe du moindre privilge, 14 PSSI, 9, 42 Rvlation dinformation, 8 Relev de conguration, 15 rseau, 13, 20 risques, 8 Scuriser le serveur Apache, 30 scuriser : mesures gnrales, 15 scuriser : mesures spciques, 20 scurit physique, 10 sauvegardes, 42 secours, 42 Servir de base dattaque, 8 sondes, 13 sources, 16 switch, 13 systmes dexploitation, 20 test, 42 utilisateurs, 30 veille technologique, 43 warn, 34
47

Guide ServeurWeb

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Guide ServeurWeb

Hochgeladen von

Copyright:

Verfügbare Formate

PREMIER MINISTRE

Secrtariat gnral de la dfense nationale

Issy les Moulineaux, le n /SGDN/DCSSI/SDO/BAS

Direction centrale de la scurit des systmes dinformation

Recommandations de scurisation serveur Web

Recommandations de scurisation serveur Web

Nombre de pages du document : 47

Recommandations de scurisation serveur Web

Table des matires

Recommandations de scurisation serveur Web

Recommandations de scurisation serveur Web

Recommandations de scurisation serveur Web

Table des figures

Recommandations de scurisation serveur Web

qui sont destines ces recommandations

Prsentation des recommandations

Recommandations de scurisation serveur Web

Recommandations de scurisation serveur Web

Dnition des rles et tches

Text Transfer Protocol RFC 2068

Recommandations de scurisation serveur Web

Principaux risques du serveur Web

Arrt ou dysfonctionnement du service Web

Servir de base dattaque

Recommandations de scurisation serveur Web

Politique gnrale de la scurit des systmes dinformation

Recommandations de scurisation serveur Web

Principes fondamentaux de la SSI

Recommandations de scurisation serveur Web

Ce quil faut prendre en compte prioritairement sur les lots techniques

Recommandations de scurisation serveur Web

Recommandations de scurisation serveur Web

appels sniers appels switchs 4 galement appels hubs

Recommandations de scurisation serveur Web

Principe du moindre privilge

Recommandations de scurisation serveur Web

Scuriser : mesures gnrales

Recommandations de scurisation serveur Web

Version du serveur Web installer

Recommandations de scurisation serveur Web

Emploi de mots de passe complexes

Recommandations de scurisation serveur Web

Recommandations de scurisation serveur Web

Recommandations de scurisation serveur Web

Scuriser : mesures spcifiques

Scuriser lenvironnement rseau

Recommandations de scurisation serveur Web

Scuriser le serveur Web

de Gestion de Cls Key Infrastructure

Recommandations de scurisation serveur Web

Activation du chirement SSL

Recommandations de scurisation serveur Web

Recommandations de scurisation serveur Web

Limiter linstallation au minimum de services

Recommandations de scurisation serveur Web

Recommandations de scurisation serveur Web

Restriction daccs par adresses IP ou nom DNS

Recommandations de scurisation serveur Web

Recommandations de scurisation serveur Web

Supprimer le support RDS

Data Object Data Service 19 Microsoft Data Access Component

Recommandations de scurisation serveur Web

Recommandations de scurisation serveur Web

Recommandations de scurisation serveur Web